Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[SOLVED] always block in testbench, any gotcha?

Status
Not open for further replies.

legendbb

Member level 1
Joined
Nov 16, 2013
Messages
34
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,286
Activity points
1,516
Just wondering if using always @(posedge clk) and nonblocking assignment for stimuli is at risk of any racing? dut sensitive on the same clock edge, tb:always block is the same as any part of synchronous design.

An example from Doulos shows using clock block with specified skew.
http://www.doulos.com/knowhow/sysverilog/tutorial/clocking/

http://www.testbench.in/TB_16_RACE_CONDITION.html
says if driving is done at posedge and reading in DUT at the same time, it's race (I think the author meant to this example with blocking statement).
Can we pretend TB to be part of DUT in synchronous design?

Also I've seen numbers of examples using specified delays. I used to use @(negedge clk) in initial block. I could have used always @(negedge clk), don't notice any difference in simulation.

Please comment,

:?:
 
Last edited:

Just wondering if using always @(posedge clk) and nonblocking assignment for stimuli is at risk of any racing? dut sensitive on the same clock edge, tb:always block is the same as any part of synchronous design.

An example from Doulos shows using clock block with specified skew.
http://www.doulos.com/knowhow/sysverilog/tutorial/clocking/

http://www.testbench.in/TB_16_RACE_CONDITION.html
says if driving is done at posedge and reading in DUT at the same time, it's race (I think the author meant to this example with blocking statement).
Can we pretend TB to be part of DUT in synchronous design?

Also I've seen numbers of examples using specified delays. I used to use @(negedge clk) in initial block. I could have used always @(negedge clk), don't notice any difference in simulation.

Please comment,

:?:

Using @(negedge clk) in an initial block or always @(negedge clk) in your testbench (or using posedge clk) is my preferred way of generating test data in a testbench. If implemented in this fashion it behaves just like any other synchronous element in your design, so there is no race condition. The problem with using #delays in the code is those are scheduled based on a delay (same as the clock) and the they can be done in any order (afaik from what the LRM states) i.e. if the clock edge in the clock generator specifies #5 and a signal transition is schedule for #5 then the order of the two is indeterminate.

Seems to me that SV has added features to compensate for the demands of the "bit-banging" testbench crowd.

I'd take the testbench site with a grain of salt, I'm not convinced the author of the site is an expert at Verilog/SV. I've run across things that seem to be to be bad recommendations. Looking at the about page shows 3+ years experience, most of the stuff I read is from people who either part of the committees that define the language or have 10-20+ years of Verilog experience.
 

Using @(negedge clk) in an initial block or always @(negedge clk) in your testbench (or using posedge clk) is my preferred way of generating test data in a testbench. If implemented in this fashion it behaves just like any other synchronous element in your design, so there is no race condition. The problem with using #delays in the code is those are scheduled based on a delay (same as the clock) and the they can be done in any order (afaik from what the LRM states) i.e. if the clock edge in the clock generator specifies #5 and a signal transition is schedule for #5 then the order of the two is indeterminate.

Seems to me that SV has added features to compensate for the demands of the "bit-banging" testbench crowd.

I'd take the testbench site with a grain of salt, I'm not convinced the author of the site is an expert at Verilog/SV. I've run across things that seem to be to be bad recommendations. Looking at the about page shows 3+ years experience, most of the stuff I read is from people who either part of the committees that define the language or have 10-20+ years of Verilog experience.
Thanks for detailed answer.
 
Last edited:

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top