要实现一个复杂的信号处理功能，需要对这个信号在不同算法和行为下表现的特征有比较深入的理解。当涉及到这类设计的验证时，通常使用的方法是注入或实际激励和使用参考模型（通常使用C或MATLAB®生成），然后和预期的结果进行比较。但是如果要求设计遵循DO-254（机载电子硬件设计保证指南）标准，那么还要求设计的各项功能具有可追溯性，即电路问题可追溯到模块甚至元件。所以每个需求的完整验证还应当额外强调实体验证，即在实体设备上进行测试。

这篇文章——Complex Signal Processing Verification under DO-254 Constraints, 就是介绍了在DO-254标准的的规范下，一个复杂的信号处理系统芯片块的验证方法。文章使用了一个较为通用的方式描述这种测试平台，这样的话在不同的信号或数据处理的设计中都可以使用这种验证方法。

下图所示：一个典型的带复杂信号处理功能的DUT结构图

图中可以看到，除了这些复杂的信号处理功能模块，还需要一些专用块和控制逻辑用于确保系统与CPU的信息连接，这种连接一般经由中断、控制和状态寄存器以及两个AXI4接口来完成。在SoC级，核心CPU可以读取并解释信息交互结果，并采取相应的行动。

基于验证的覆盖率驱动要求

信号处理算法的每个子计算部分被描述为一个子要求，最终的验证和设计都要服从这些要求。

如下图所示：一个FIR滤波器的要求

在本例中，FIR滤波器函数要实现的不仅仅是一个简单的求和运算。它先要完成了一系列形如 A = ( a + j * b )的运算，其中j是虚数（即j*j=-1），然后对这些运算结果再求和。因此，验证分析需要覆盖几点：

• 在复杂的乘积运算中，使用了样本Xi的实部和虚部的最大值、最小值和0值进行验证吗？同时考虑到Ci实部和虚部取最大值、最小值和0的情况吗？

• 在每一个实数和虚数部分，是否都考虑到了最坏的运算情况下的验证，即每一项求和的进位都会传递到最终结果的情况？

•  一些其他相应的复杂问题

这些分析使我们能够清晰的明白哪些要求是要被准确的验证到的，这些验证的点当然也会很容易的就在功能覆盖率上得到体现。在我们的例子中，我们的testbench直接的监视了在设计要求中体现了的内部信号，并且基于所监视的信号建立了covergroups。

如下图所示：指定信号的灰盒监视器

基于设计要求的断言和检测器

尽管最终的验证结果是要与参考模型相比对的，但是DO-254准则要求设计需求和相应的验证是清晰可追溯的。即使用上面的testbench得到的覆盖率表明不同条件下的上述设计需求都被验证过了，也没有直接证据表明设计是符合每一条设计要求的。

因此，对于产品的每一条设计要求，要么需要建模，要么还是要依靠断言与预期的结果进行比对。进而，添加SVA断言，以及使用不同滤波器的小的功能性的SystemVerilog模型刚好符合这一思路。不过，虽然断言确实是可以验证产品要求的，但是也对验证环境和验证工具提出了更多的要求。

覆盖率、断言和测试

覆盖率用于记录我们的设计要求是否被验证过，断言可以验证产品设计要求，为了达到我们的覆盖率目标，也常常会需要一些更为复杂的测试。有许多不同的文章会建议，在DO-254标准规范下的工程中可以使用随机测试的方法。但是实际例子表明这种方法比较难以开发，而且这样的话，复杂信号处理模块的验证是相当费时间的。其实，我们可以使用MATLAB生成模型，使用这种模型来搭建我们的测试场景是比较方便的。

参考模型和要求

参考模型用于实现一个顶层的功能，这个功能是由通用的核心模块和所选用的硬件参数（滤波器、信号位宽等）配置出来的。在参考模型中添加参数，参考模型就可以产生测试输入经过处理后的预期结果。这样，我们就可以比对相同激励下RTL代码的仿真结果和参考模型的最终运算处理结果，进而验证设计的整体功能是否符合要求。

由于模型是已经使用相同的样本和参数验证过的，如果RTL代码的仿真结果和参考模型的最终运算处理结果是相同的，就可以说明设计也是遵循相同的算法。比起之前的基于覆盖率和断言的要求的验证检查，这个额外的验证检查将整个算法作为一个整体，保证了设计从整体算法层面上的正确性。

在我们的例子中，我们选择直接从这个MATLAB模型生成测试激励及其预期的结果。直接从Matlab的生成测试激励具有减少文件处理数量的优点，但需要一些额外的Matlab的脚本的努力。

其他可用的方法有：

• 把Matlab链接到模拟器上。但是这只能用在模拟仿真上，而不能用在实体设备。

• 使用不同的脚本语言解释Matlab的结果。但这将需要额外的环境条件。

无缝模块（SEAMLESS MODULE）验证

考虑到会在FPGA平台上重新进行RTL测试，生成C测试代码实际上是一个更合理的选择：

• 在模拟中，在主机计算机上运行C测试就是使用DPI接口控制AXI4 agents（显示器驱动器），连接到设计上。

• 在板级，该平台的CPU上运行C测试就是从相同的软件驱动直接访问硬件。 

如下图所示：全局的验证环境

SoC级实体复用

因为DO-254标准下要求工程项目要进行实体验证，所以SoC级的实体复用也变得很有必要。我们就可以将DPI寄存器读写、存储器访问和实际硬件的指针访问进行映射，因此相同的C可以在SoC级重用，并在实体硬件上裸机运行。

如下图：实体环境的SoC

在IP层次的模拟仿真验证和实体设备测试之间的主要差别在于延时，延时是由设备上实体核上软件的执行而引入的。另一个区别在于，实体设备测试缺乏可观测点，断言和功能覆盖率因此不能用于实体测试。但是实体测试是一种自检测试，这种自检本身就具有标志性，保证了实体设备也能达完成相同的功能，从而实体测试也同样的也能得到功能覆盖率。 

结论

这里介绍的方法结合了不同的验证方法。基于验证的要求它引入了覆盖率驱动验证，并且这种方法从IP层次仿真验证到SoC设备自检测试的垂直和水平的验证都能够复用。另外，它还保证了面向设计要求的功能覆盖和断言的可追溯性。所以这种方法可以被用于一些有特定安全要求（例如要遵循DO-254 和ISO 26262标准）的工程项目。

您可以在手机移动端同步关注订阅号“路科验证”。

如需转载请联系路科验证，并注明出处“路科验证”。