here is a quick question: suppose we have a testbench code that is suspended by one of wait(signal); or @(posedge signal); statements, awaiting resuming from an async signal. Our DUT provides this signal, but the logic is built so, that there is a delta-glitch, i.e. the signal goes high and down inside the delta cycling.
With a simple test code I’ve identified that many simulators consider a posedge that occured in delta event as real event, and the simple testcode (AND2 gate with inputA: reg, inputB:not(reg)) can produce different results based on relative scheduling of update events (which may or may not produce that “delta glitch”).
So, shall a delta-cycle signal change event really trigger suspended testbench blocks?
Are there any SystemVerilog constructs that would allow to safely wait for a signal (i.e. evaluate from Observed or Reactive region?)
EDIT1: I understand, that “always @(posedge signal)” blocks shall be triggered, even if the event occured in delta cycle, but the question here relates to suspended processes that are in the testbench, i.e. code that is reactive to the processes in DUT which shall properly observe “true” signal values.
The simplest thing to do is put the signal through a continuous assignment with a delay larger than any glitch you want to filter. If it’s only 0-delay glitches you are concerned about then #1 will do. If you ever get into gate-level simulations, you may need a larger delay.
Another thing to consider is if a signal output from the DUT truly asynchronous coming from the perspective of an RTL simulation. Is there some clock you could use to sample it? Or is the some asynchronous event from the stimulus that you could use to sample the event?
There are probably a number of other solutions I could go into if this does not work for you.
Greetings all,
So, shall a delta-cycle signal change event really trigger suspended testbench blocks?
Are there any SystemVerilog constructs that would allow to safely wait for a signal (i.e. evaluate from Observed or Reactive region?)
Best Regards,
Since you asked and mentioned reactive region - in SV there is a construct called program block. Given this is MENT specific forum and there are some very strong opponents (valid reasons I must admit) of this construct in MENT, you may get different opinion.
Thanks, Dave. I must admit it was more or less a hypothetical “simulator-and-verilog” question. I agree, that there are numerous ways to avoid this behaviour, when it comes to the real issue (it was an easy fix, like you’ve said, with a delay), but I was more concerned about general idea: that standard verilog facilities do not provide a reliable way to sample signals for “reactive” (i.e. testbench) purposes and what to do about it.
I’ve taken a look at a program block and it seems to do what I was hoping to have. I’ll make some tests with delta glitches to see if it holds up. Thanks!
Could you please describe in a nutshell why there are opponents of this?