SystemVerilog 程序块与传统测试台答案

【问题标题】：SystemVerilog program block vs. traditional testbenchSystemVerilog 程序块与传统测试台
【发布时间】：2013-08-23 15:03:15
【问题描述】：

程序块是否提供了其他方法无法复制的 SV 功能？

这个问题不太具体的版本是：我应该为验证而烦恼程序块吗？我正在从受限于 Verilog-95 的环境转移到支持 SV 的环境，我想知道我是否通过不使用程序块为自己创造了额外的工作。

【问题讨论】：

标签： unit-testing testing verilog system-verilog

【解决方案1】：

查看 IEEE Std 1800-2012 § 3.4 和 § 24。有关 program 块的完整说明。

在一个简短的、不完整的总结中，program 块：

不能包含always 过程、primitive 实例、module 实例、interface 实例（允许使用virtual interface 和端口interface）或其他program 实例。
指定 Reactive 区域中的调度。这可以防止出现竞争条件。
有一个额外的系统任务$exit，它会终止调用它的program 实例。
- 当所有program 实例退出时，模拟将终止。
除上述情况外，大多类似于module 块。

program 块的想法是在测试和设计之间建立明确的分离。在早期版本的 SystemVerilog（IEEE 1800 之前）中，class 的实例化通常仅限于 program 块。这强调了测试和设计的划分。它还使program 块对于想要在其流程中使用面向对象编程的验证工程师至关重要。从 IEEE 1800 开始，class 几乎可以在任何地方定义和实例化。结果，program 块变得不够充分。

今天，program 块的有用性意见存在分歧。从我参加的最近几次会议来看，趋势似乎倾向于放弃program 块。这是因为这些优点可以通过其他方法来实现。可以使用 clocking 块在 Reactive 区域中进行调度。 mailbox、队列（[$]）或关联数组（[*]）可用于智能处理模拟终止运行多个测试。就个人而言，我仍然喜欢使用program 块并在需要时使用initial forever 作为always 等效项。如果您打算使用 UVM，那么非program 块测试台可能更适合您。

最后，这实际上归结为方法偏好。最好自己评估和尝试。

【讨论】：

【解决方案2】：

我不建议使用程序块 - 改用模块。几年前，我为此写了detailed article。

【讨论】：