Race conditions and clocking block

SystemVerilog
1

Hi Dave and other experts,

While I was going through your paper “The missing link…” which gave some useful insights on methods of connecting the DUT and the testbench, I have the following questions. I am sure, many users would be looking for clarification on this aspects.

You mentioned:

A clocking block can address these race conditions even further by sampling on driving signals some number of units away from the clock edge

I am not sure I have understood this. Are you saying the it is due to “non-zero skews”. I have two follow-up questions on this. .

I read the following from LRM,

It is important to understand that simply sampling input signals (or setting nonzero skews on
clocking block inputs) does not eliminate the potential for races. Proper input sampling only addresses a
single clocking block. With multiple clocks, the arbitrary order in which overlapping or simultaneous clocks
are processed is still a potential source for races. The program construct addresses this issue by scheduling
its execution in the Reactive region, after all design events have been processed, including clocks driven by
nonblocking assignments.

and the following,

Together with clocking blocks, the program construct provides for race-free interaction between
the design and the testbench and enables cycle- and transaction-level abstractions

makes me think that we need program blocks or am I missing something ?

also in your paper you mentioned that

Using @ (posedge clk) or any other event will introduce race conditions. Can you please explain why this happens ?

Also Do we need a non-zero skew if the clocking blocks have to provide race-free interactions between DUT and Testbench. If yes, what is recommended way of adding a non-zero skew or #1 step is enough, when do you use what. It is quite confusing. Please explain.

I have another question (may be not related), Do we need “modports at all”. I read from LRM as “modports are used to restrict access…”. But in one of the forum questions, I think one user gives an example where this is not the case and Modport just mentions the direction with respect to Interface. Are there any situations where we may (or must) need modports?

To conclude if the experts could write a paper on these aspects if would help the verification community a lot.

Regards,
Madhu

2

Hi,

As per my understanding race condition doesn’t happen with raw RTL simulation since there is no timing information involved in that. It happens with netlist simulation.

Clocking block inserts one D-FF. So according to library information u need to specify sampling timing window(setup & hold) in order to avoid race condition.

Together program block and clocking help us to avoid racing condition in netlist simulation.

3

In reply to sivakrishna:

This is not correct. Race conditions happen as a result of:

  1. design flaws that you may or may not catch in RTL or GATE simulation by chance. Only detailed timing and/or formal analysis will catch these.
  2. Artifacts of simulation due to the absence of correct timing or modelling information.

Either one of these could occur in your testbench or design, and whether or not you choose to use a program block.

4

In reply to dave_59:

Hi Dave,

Thanks. Could you please try to address questions in my original post ?

Regards,
Madhu

5

I will try to answer your questions as per my understanding. Dave, please correct me if I am missing something.

  1. What if the skew is mentioned as # 0.
    Ans: If we mention the skew as zero, that would not cause any harm in terms of accessing the signals but would not be helping in any ways to avoiding race conditions. In those cases program block would be required.
  2. Do we need program blocks or just clocking blocks are enough to take care of race-free DUT to Testbench interaction ?
    Ans: Depends on the way you have designed the clocking blocks. As per my previous answer.
  3. Do we need a non-zero skew if the clocking blocks have to provide race-free interactions between DUT and Testbench.
    Ans: Non-zero skew would be a good way to make sure we avoid race-free interaction. But might not be enough all the time.

You can look at this paper for more info ;) This is a very old paper, but might help a bit to understanding things better.
SystemVerilog Event Regions, Race Avoidance & Guidelines