System verilog systemverilog比较两种方式等待信号；1） @（时钟iff条件），2）而（！条件）@（时钟）；

我希望对systemverilog方法有一些直观的了解，即等待接口上的某个信号，以便1）在监视器中捕获事务，或2）根据DUT的某个信号驱动事务。让我们假设DUT正在断言就绪信号，并且驱动程序在断言有效信号时必须背靠背地驱动两个数据拍（值1和2），以便DUT知道何时捕获数据

据我所知，有两种方法可以等待DUT发出的就绪信号；1） 一个是iff条件时钟事件，另一个是2）在某些信号不真实（例如就绪低）时消耗时钟。可以找到testbench代码

第一种方法是使用

@（posedge dut_vif.clock iff（dut_vif.ready==1））
第二种方法是使用
while（！dut_vif.ready）@（posedge dut_vif.clock）并且两种方法之间存在单时钟差异，如波形所示。我最大的理解是--

@（posedge dut_vif.clock iff（dut_vif.ready==1））

此方法正在等待就绪==1的“条件”下的时钟上升事件。因此，数据和有效数据在25ns上被驱动到高位

while（！dut vif.ready）@（posedge dut vif.clock）

另一方面，这句话意味着模拟应该在就绪时间较低时消耗时钟。然而，这种解释和systemverilog的实际行为是非常不同的。在15ns时，就绪信号变高，有效和数据以相同的周期驱动。我的理解是，在15ns时，测试台仍应将就绪状态捕获为低，模拟应消耗一个时钟。因此，第二种方法的行为应该与第一种方法相同

我能解释一下如何理解这种差异吗

我在这里

问题是因为调用
获取下一个项目（）
时隐藏了增量延迟，即使时间仍然是15，
计数器
，因此
就绪
现在在从调用返回后有了新的值。使用
iff
可以更清晰地对时钟边缘的值进行采样。它还避免了
时出现的问题！ready
为
x
，因为其计算结果为false

@(event iff (expression));

相当于

do @event; while (!expression);

不是

正如戴夫在会上提到的，也许他忘了。这就是为什么您错过了一个时钟周期。
对于
而（！dut_vif.ready）@（posedge dut_vif.clock）
case，看起来ready的检查在@（posedge时钟）之前。然而，实际的操作顺序可能是这样的；1） 首先从@（posedge dut_vif.clock）唤醒进程，该进程在上一个循环中被阻止，2）执行dut_vif.ready检查。在@（posedge dut_vif.时钟）之后的15ns，就绪为高电平，它使进程退出while循环，并在同一周期内驱动有效的高电平。你觉得戴夫怎么样？@dave_59我还可以想象它会稍微快一点，因为它只有在准备好的时候才会醒来。Specman是通过回调工作的，您可能希望最小化HDL模拟器和Specman之间的切换量。我可以想象SV模拟器的工作原理与此类似。不过，切换的成本可能更低，因为它是同一个引擎。@rosepark222您可以在第一次进入循环时看到差异。首先检查，
ready
已为1。因此，不必等待时钟。@TudorTimi SystemVerilog中HDL和测试台之间没有切换。这是其背后动机的一部分。
while (!expression); @event;