CODEWITHSUNDEEP
system-veriloguvm
rosepark222
rosepark222

Reputation: 89

systemverilog comparing two ways to wait signal; 1) @( clock iff condition), 2) while( ! condition) @(clock);

I am looking for some intuitive understanding of systemverilog method of waiting for certain signal on the interface for 1) capturing transaction in a monitor, or 2) driving a transaction in response to some signal from DUT. Let's assume that DUT is asserting ready signal and driver has to drive two data beats (values of 1 and 2) back to back while asserting valid signal so that DUT would know when to capture data.

There are two methods of waiting for the ready single from the DUT that I know of; 1) one is iff conditioned clock event, and the other is 2) consuming clock while some signal is not true (e.g., ready is low). The testbench code can be found EDA playground (line 37 of my_driver.sv).

The first method is using @(posedge dut_vif.clock iff(dut_vif.ready == 1)); and the second method is using while( ! dut_vif.ready) @(posedge dut_vif.clock); and there is single clock difference between two methods as shown in the waveform. My best understanding is --

@(posedge dut_vif.clock iff(dut_vif.ready == 1));

This method is waiting for the clock rise event 'on the condition' of ready == 1. Therefore, data and valid are driven high on 25ns.

while( ! dut_vif.ready) @(posedge dut_vif.clock);

On the other hand, this statement means that simulation should consume clock while ready is low. However this interpretation and the actual behavior of systemverilog is very different. At 15ns, ready signal goes high and the valid and data are driven at the same cycle. My understanding is that at 15ns, the ready should be still captured as low by the testbench, and simulation should consume one clock. Therefore, the second method should behave just like the first method.

Can I get some interpretation on how to make sense of this difference?

I am attaching waveform here.

waveform comparison of two methods

Upvotes: 1

Views: 6822

Answers (2)

anpham
anpham

Reputation: 1

@(event iff (expression));

is equivalent to 

do @event; while (!expression);

not

while (!expression); @event;

as Dave mentioned at here, maybe he forget it. That's why you missed one clock cycle.

Upvotes: 0

dave_59
dave_59

Reputation: 42698

The issue is because of hidden delta delay inside the call to get_next_item() Even though the time is still at 15, counter and thus ready now have their new values after returning from the call. Using iff gives you a clearer sampling of values w.r.t the clock edge. It also avoids problems when !ready is x because that evaluates to false.

Upvotes: 1

Related Questions