原创 编码越少，支持越多?

软硬件功能划分是现在的嵌入式系统设计中很常见也很关键的一个步骤。在MCU+FPGA的系统架构中，对配置灵活性要求高的功能用MCU来实现，对实时性有硬性要求的功能要用FPGA来实现。这样划分功能实现的嵌入式系统，其灵活性和实时性就能兼顾。这样做符合控制单元和数据通路分开设计的原则。

在一个项目中，从外部看来是一个功能点，在系统内部往往也要划分为软件和硬件两部分来实现。在我当前的项目中，系统需要实现的许多功能点都采用了这种划分方法。有的功能硬件实现的成分多，有的功能软件实现的比例大。

随着项目的进展，我参与的硬件设计基本完成，已经开始软硬件联调了。在支持软件工程师完成调试的过程中，我发现一个有趣的现象：一个功能点，硬件实现的比例越大，我们对软件工程师进行支持的工作量就越少；相反，硬件占的比重越小，我们需要和软件工程师进行交流和反复调整的工作量就越多。

从常识来看，编码越多，bug也就相应地越多。对于这一反常现象，可以从如下三个方面来解释：

1. 由于硬件实现的功能少，我们硬件工程师对这一部分功能重视不够，验证投入的工作少，验证得不充分，缺陷也就多。

2. 反过来说，由于需要更多功能在软件中实现，软件工程师在这一方面投入的编码和验证工作也就越多。编码多，bug多，这是软件出错误的地方；验证多，发现的bug也就多，这是软件工程师在验证过程中帮助硬件工程师发现的硬件错误。这两种错误，都需要软硬件配合调试，在硬件工程师看来，对软件开发的支持工作就多。

3. 在当前的项目中，有这样一个规律：硬件实现比重大的地方，功能越复杂，覆盖的功能点也越多。软件工程师倾向于按照系统的功能来进行测试，首先进行的测试是功能单一、验证量小的部分。由于前面的规律，这些最先得到测试的部分，硬件实现的比例是很小的。真正的大批量测试，即针对硬件实现比重大的部分的测试还没有开始。所以，在我看来，就成了“编码越少，bug越多；编码越多，bug越少”。其实，真正会出现bug的部分还没开始测呢！

随着项目的进展，随着主要由硬件来实现的功能得到更多的验证，更多深层的硬件bug就会逐步暴露出来，这一现象一定会逆转过来。