Testbench input stimulus

[rogger201]

Hello,

I am writing a testbench in which I am giving the inputs to my module. These inputs include a clock, reset , data and shift_data value that go to my DUT.
I am trying to make use of

always begin 
#1 clock = ~clock;
end 

initial begin 
reset = 1'b0; //its a negedge triggered block
shift_reg = 8'b10000001;
repeat (2) @(posedge clock);

reset = 1'b1;
data = 8'b11111111;
sel = 2'b00;
repeat (2) @(posedge clock);

reset = 1'b1;
data = 8'b00001111;
sel = 2'b00;
repeat (2) @(posedge clock);

...... 
repeat (2) @(posedge clock);
$finish;
end

The first input of reset messes up my results. If I make

reset = 1'b1;
data = 8'b11111111;
sel = 2'b00;
repeat (2) @(posedge clock);

change to

reset = 1'b1;
data = 8'b11111111;
sel = 2'b00;
#2;

Then my simuation results seem to be fine. Also, when i change repeat(2) @(posedge clock) to repeat (1) @(posedge clock), the result is correct but it misses some data if its different. So how does repeat work? What value are we supposed to specify?

The fact that its changing every time, does that mean my DUT is not coded correctly?

 

[TrickyDicky]

Lets tackle these one at a time.
1. Repeat. It is exactly as you expect. repeat (2) means repeat the following statement 2 times. In your case,
repeat(2) @(posedge clock);

means wait for 2 clocks

2. Using #2 means you are waiting for a fixed period of time. The problem is you are not synchronised to the clock, so you are now likely setting the data/sel/reset just before a clock edge, and probably not quite behaving as you expect. I recommend sticking with the first form, waiting for explicit clock edges.

3. If its not working, then something needs to be fixed. You will need to study the waveform and explore the reason for the errors. Welcome to world of hdl debugging!

 

[rogger201]

Lets tackle these one at a time.
1. Repeat. It is exactly as you expect. repeat (2) means repeat the following statement 2 times. In your case,
repeat(2) @(posedge clock);

means wait for 2 clocks

2. Using #2 means you are waiting for a fixed period of time. The problem is you are not synchronised to the clock, so you are now likely setting the data/sel/reset just before a clock edge, and probably not quite behaving as you expect. I recommend sticking with the first form, waiting for explicit clock edges.

3. If its not working, then something needs to be fixed. You will need to study the waveform and explore the reason for the errors. Welcome to world of hdl debugging!

This was a really helpful response.
Although, it only works if i use #2 for reset and repeat(1) @(posedge clock) fro every data stimulus. And gives me the desired waveform.

 

[dave_59]

You may have race conditions if your module also has code that waits for @(posedge clock). The same rules apply between your testbench and module as well as module to module. Use non-clocking assignments or have your TB use the negedge.