仿真和验证是开发任何高质量的基于 FPGA 的 RTL 编码过程的基础。在之前的文章中，我们介绍了面向实体/块的仿真以及如何在IP核中执行面向全局的仿真，即通过在每个输入信号上生成激励并验证 RTL 代码行为是否符合预期，对构成每个 IP 核的不同模块进行实体/块的仿真。而一旦不同的模块被单独验证，则意味着下一步将整个IP仿真为单个 UUT（被测试单元）。
尽管扩展的仿真计划提供了良好的可信度，但仍有许多corner的情况无法在虚拟环境中验证。对于这些情况，需要基于硬件的测试计划，这也是获得高质量结果的最后一步。在本篇文章中，我们将介绍如何在硬件平台上验证IP核。
硬件测试
硬件测试是为IP核产品执行高质量测试和验证计划的最后一步，主要可以分为以下几个阶段：
1. 测试准备：定义在产品开始测试之前必须完成的步骤
在这个阶段，定义了测试计划文档。在这个文档中，详细描述了必须在 DUT（被测设备）上执行的每一项测试。
2. 测试执行：执行上一个阶段中定义的测试用例
3. 问题报告：检查和报告在测试执行期间检测到的所有问题
可以使用问题电子表格来记录在测试阶段检测到的每个问题。每当注册新问题时，都会向开发团队报告，并且能够追踪哪些问题已解决，哪些问题仍有待审查。
4. 测试结束：确定测试阶段何时完成，并创建测试结果文档，其中将包含成功执行的测试的摘要以及有关测试的更多相关信息。
虹科SoC-e测试工具
为了优化测试执行过程，我们使用了虹科SoC-e测试工具，以进行自动化测试。该工具考虑了以下内容：
● DUT配置过程
● 流量注入和嗅探
● 记录从 DUT 返回的流量
● 验证保存的日志
● 将 DUT 设置为原始状态
SoC-e测试软件架构
该工具的第一步与DUT 配置的执行有关。这是通过名为 Platform.vars 的输入配置文件完成的。通过该文件，用户可以配置不同的参数，如 DUT SSH 参数、主机 PC 的 IP 地址或网络接口。
第二步，完成TS（测试站）和 DUT之间的流量注入和嗅探。我们有不同的第三方设备用作测试站，但最常用的设备之一是IXIA Novus One Plus。流量可以通过 IXIA 的 Python API 轻松发送。数据包操作是通过 Scapy Python 模块完成的。尽管 Scapy 允许传输该工具生成的所有流量，但它是使用不同的工具tcpreplay执行的。这使我们能够克服由 Scapy 引起的带宽和准确性方面的某些限制。在此步骤中，测试提供了自定义流量的灵活性，以验证不同的 DUT 功能。可扩展性不是问题，因为该工具支持添加额外的流量和测试端口。
第三步，该工具使用测试站或通过 Linux tcpdump 软件登记来自 DUT 的流量。
第四步，SoC-e 测试工具验证上一步中存储的信息（统计、寄存器转储（dump）等），以检查一切是否正常。通过这两个步骤，SoC-e 测试工具为测试用例的验证提供了一个很好的解决方案。
最后，第五步，也是最后一步。最后一步的主要目的是将 DUT 配置恢复到其原始状态，因为它可能在测试期间被修改。
