2. 软硬件协同设计基础
各位同学，今天我们来聊聊软硬件协同设计。说实话，这个概念我入行头三年都没真正搞明白。那时候做机器人控制器，软件团队写代码，硬件团队画板子，两边各干各的。结果呢？联调的时候天天吵架。后来我才意识到——软硬件必须从一开始就一起设计，这就是协同设计的核心。
2.1 什么是软硬件协同设计？
说白了，软硬件协同设计不是把软件和硬件拼在一起。而是从系统需求出发，同时考虑哪些功能用硬件实现，哪些用软件实现。我习惯叫它「软硬件一体化设计」。
你想想看，一个机器人控制器里，电机控制环路、传感器数据融合、通信协议栈——这些功能到底放哪边？放硬件里，速度快但改起来麻烦；放软件里，灵活但实时性可能不够。协同设计就是帮你做这个决策的。
核心思想：软硬件不是主从关系，而是合作伙伴。硬件提供性能底座，软件提供灵活性。两者在架构层面就深度融合。
我在项目中遇到过最典型的例子：一个六轴机械臂的轨迹规划。一开始全用软件做，CPU负载飙到85%。后来把逆运动学计算中的矩阵运算用FPGA加速，CPU负载降到30%，控制周期从2ms缩短到0.5ms。这就是协同设计的力量。
2.2 设计流程：从需求到实现
我总结了一套流程，这些年一直在用。一共五个阶段：
- 系统需求分析——搞清楚控制器要干什么。比如：控制周期多少？传感器接口类型？通信延迟要求？
- 功能划分——决定每个模块用软件还是硬件。这是最考验经验的一步。
- 接口定义——软硬件之间的通信协议、数据格式、时序约束。嗯，这里最容易出问题。
- 并行开发与验证——软硬件团队同步推进，定期联调。
- 系统集成与优化——把软硬件合在一起，跑全系统测试，做性能调优。
我曾经犯过一个错：在功能划分阶段，把IMU数据滤波全扔给了硬件。结果硬件资源不够，不得不重新划分。白白浪费了两周。所以我现在建议：功能划分至少做三轮评审，软硬件工程师坐在一起吵明白再动手。
2.3 设计方法学：三种主流思路
方法学这东西，听起来玄乎，其实就是「怎么干活」。我常用的有三种：
| 方法学 | 核心思想 | 适用场景 | 我的评价 |
|---|---|---|---|
| Y-Chart方法 | 将系统分解为功能、架构、映射三个维度 | 复杂SoC设计 | 适合大团队，文档化好 |
| 平台化设计 | 基于可配置的硬件平台，软件动态适配 | 产品系列化开发 | 我最喜欢，复用率高 |
| 模型驱动设计 | 用数学模型描述系统，自动生成软硬件 | 控制算法验证 | 适合原型验证，量产慎用 |
Y-Chart方法，说白了就是画三张图：功能图、架构图、映射图。我刚开始用的时候觉得麻烦，后来发现——图纸就是沟通语言。软硬件工程师各看各的图，但映射图是共同的，谁也别想甩锅。
平台化设计是我现在的主力方法。举个例子，我们做移动机器人控制器，硬件平台固定（ARM+FPGA），软件按功能模块化。不同型号的机器人，换传感器就换驱动模块，改运动学就改算法模块。硬件不用动，软件改改配置就行。效率提升很明显。
模型驱动设计，嗯，这个我持保留态度。它适合快速验证算法，但生成的代码效率往往不如手写。我在一个项目中试过，模型生成的硬件描述代码占用了两倍的逻辑资源。最后还是手写了关键部分。
我的建议：新手从平台化设计入手。先吃透一个硬件平台，把软件架构搭好。等经验够了，再尝试Y-Chart做复杂系统。模型驱动？当辅助工具用就好。
2.4 避坑指南：我踩过的三个坑
讲完理论，说点实在的。这些年我踩过的坑，你们能避就避：
- 坑一：接口定义不清晰。我曾经让软件团队和硬件团队各自定义通信协议。结果软件用SPI，硬件用I2C。联调那天，两个工程师面面相觑。后来我强制要求：接口文档必须双方签字，包括时序图、数据格式、错误处理。
- 坑二：忽视功耗约束。有个项目，硬件团队选了个高性能FPGA，软件团队写了个轮询循环。结果整机功耗超标，散热压不住。最后不得不降频运行。教训是：功能划分阶段就要把功耗预算算进去。
- 坑三：验证脱节。软硬件各自验证都通过了，一集成就崩。为什么？因为验证环境不一样。我现在要求：软硬件联调的测试用例，在项目启动时就定好。两边照着同一个用例验证，集成问题少很多。
特别注意：协同设计不是「先做硬件，再写软件」。也不是「软件先跑，硬件再调」。而是从第一天起，软硬件工程师就坐在一起。物理距离近了，沟通成本就低了。我现在的团队，软硬件工程师混坐，有问题扭头就问。
2.5 一个小例子：电机控制器的协同设计
最后，我拿一个直流电机控制器来演示协同设计的过程。这个例子我在多个项目中用过，很典型。
需求：控制周期100μs，电流环带宽5kHz，速度环带宽500Hz。
功能划分：
- 电流环（100μs周期）→ 硬件实现，用FPGA做PID计算和PWM生成
- 速度环（1ms周期）→ 软件实现，用ARM做速度估算和闭环控制
- 通信接口（CAN总线）→ 软件实现，但硬件提供CAN控制器
接口定义：
- FPGA输出：PWM占空比（16位寄存器）
- ARM写入：电流环目标值（32位浮点数，通过AXI总线）
- 共享内存：电机状态（转速、电流、温度，每100μs更新一次）
代码示例（接口定义头文件）：
// motor_interface.h
// 软硬件接口定义，双方共同维护
#define PWM_BASE_ADDR 0x40000000
#define CURRENT_TARGET_ADDR 0x40000004
#define MOTOR_STATUS_ADDR 0x40000010
typedef struct {
float current_target; // 电流环目标值，单位A
uint16_t pwm_duty; // PWM占空比，0-1000
uint8_t enable; // 使能标志
} motor_ctrl_t;
typedef struct {
float speed_rpm; // 当前转速
float current_a; // 当前电流
float temperature_c; // 温度
uint32_t timestamp_us; // 时间戳
} motor_status_t;你看，这个接口定义一出来，软硬件工程师各自的工作边界就清楚了。硬件负责实现PWM生成和电流采样，软件负责速度环和通信。两边照着同一个头文件开发，集成的时候基本没出过问题。
好了，这一章就到这里。下一章我们深入讲讲功能划分的具体方法，包括怎么评估软硬件实现的代价，怎么用表格做决策。到时候我会拿一个真实的机器人控制器案例来拆解。