3BSE013177R1 设备模型不是测试驱动程序

更好的是，Verilog 的子集可以很好地建模可综合逻辑。这适用于异步和同步逻辑。然而，我在上面概述的分配延迟问题是由于在目标是创建硬件设备模型时尝试使用 Verilog 对逻辑和软件的混合进行建模而引起的。

因此，这里有一些在 Verilog 中使用延迟的技巧：

1. 尽可能编写可综合的模拟逻辑。

   这实际上只是测试平台或建模逻辑的问题。对于本来可以综合的逻辑来说，这并不是真正的问题。

   以可综合的方式编写测试平台逻辑的好消息是，您可能会获得在硬件中综合模型的能力，然后在其上更快地运行测试。然后，您还可以通过正式验证您的设备模型获得第二个好处——它会在以后运行集成仿真时为您节省很多时间。

   例如，比较以下两种验证测试芯片的方法：

   ASIC 测试芯片 #1：具有能够驱动内部寄存器的 SPI 端口。这实际上是一个非常好的主意，因为您可以减少连接到此类测试芯片所需的电线数量。然而，问题在于 SPI 驱动程序来自加密的供应商 IP。为什么这是个问题？当测试团队在硬件中实现后尝试连接到设备时，这就成了一个问题。他们试图将他们的 CPU 连接到同一个 SPI 端口来驱动它——但没有按照协议正确驱动它。

   测试 ASIC 测试芯片 #1 的结果？我接到一个客户的紧急电话，抱怨测试芯片的 SPI 接口不工作，并询问我是否可以找到其中的错误。

   ASIC 测试芯片 #2：还有一个用于读取和写入内部寄存器的 SPI 端口。然而，在这个芯片中，SPI 端口被正式验证为写入器和读取器的组合——如下图 7 所示。

我说“很像图 7 所示”，因为这个端口的验证不是通过使用 CPU 作为测试脚本的一部分来完成的。然而，由于 SPI 主机和 SPI 从机同时进行了验证，而且更好的是，它们在包含这两个组件的环境中进行了形式验证，因此测试团队可以使用经过验证的 RTL 接口开始工作。

您甚至可以更进一步，使用软核 CPU同时验证软件驱动程序。这是图 7 中显示的全部内容。正如我上面提到的，ASIC 测试芯片 #2 的形式验证在 SPI 主控的 AXI-lite 控制端口停止。当作为集成测试的一部分测试该芯片时，测试脚本用于驱动总线功能模型 (BFM)，而不是实际的 CPU 软件。但是，如果您只是阅读测试脚本对 BFM 的调用，您将获得构建经过验证的软件驱动程序所需的信息。

*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。