比较仿真性能答案

【问题标题】：Comparing simulation performance比较仿真性能
【发布时间】：2016-04-13 06:53:52
【问题描述】：

其中哪些会阻碍我的测试台中的模拟性能以及原因（从系统 Verilog 编译器的角度寻找答案）：

task A;
wait(dut_if.a==1);
.
.
endtask

或

task A;
  forever @(posedge clk) begin 
    if(dut_if.a==1).. 
  end
endtask

PS：“a”是一个 dut 信号，它在仿真期间的某个时钟边缘被断言。假设这个任务只被调用一次。

【问题讨论】：

感谢您的 cmets。因此，据我了解，一旦转换为低级语言，永远永远阻塞实际上将是某种中断服务例程，而等待语句将类似于分支指令。如我错了请纠正我。如果您能指出一些从编译器角度讨论系统verilog的来源，那就太好了。

【解决方案1】：

两者在功能上并不等同。第一个 sn-p 等到 a 变高（即完全相同的周期），而第二个 sn-p 等到 a 在时钟周期“看到”为高：

       _   _   _   _   _
clk  _| |_| |_| |_| |_| |_
            ______________
a    ______|

           |  |
           1  2

数字会显示每个触发的时间。你真正想要的是：

@(posedge clk iff dut_if.a);

这在语义上等同于 sn-p 2。创建的 cmets @Coverify 也应该在这里应用（更快，因为没有上下文切换）。

【讨论】：

【解决方案2】：

第一个选项会有更好的性能。我假设在您的使用情况下，这两个选项在功能上都是正确的。

第二段代码在每个时钟上等待，然后检查条件。由于等待在永远循环中，因此此代码将导致在 clk 的每个 posedge 上进行上下文切换。另一方面，选项 1 中的代码只切换一次上下文。

【讨论】：

【解决方案3】：

这两个选项在功能上并不等效。

但在这种情况下，第二个选项在模拟性能上会比第一个选项更好。

因为，在第一个选项中，工具需要在每个选项上检查 a 的值并且每个时间步长，而在第二个选项中，工具将仅检查 posege，而不是每个时间步长。

【讨论】：

【解决方案4】：

哪个性能更好？这取决于模拟器的实现。在真正的事件基础模拟器中，案例 1 会具有更好的性能，因为评估代码不会在每个时钟沿唤醒。但是，我怀疑案例 2 在现实世界中会具有更好的性能，因为评估代码与时钟滴答非常一致。

如果您的代码没有对异步逻辑进行建模，我建议您坚持使用案例 2。代码更易于理解和理解。将一切与时钟对齐，让您的生活更轻松。

【讨论】：