Calling uvm run_test from a program block instead of a module

[rkovvuri]

Can the 'run_test' that starts off the UVM thread be issued inside a 'Program' ? or can it only be issued from a 'module'.

issuing the run_test from a program block seems to be causing a lot of race conditions between uvm blocks.

If someone has an explanation as to why either way, I would appreciate if you can share it.

Thanks!

[dave_59]

Calling run_test() from a program block or module is allowed. Most likely you have a race condition in your testbench, and by chance one method is just exposing the race and the other is not.

See http://go.mentor.com/programblocks

[rkovvuri]

Thanks Dave:

Yea thats what i am seeing, a race condition when run_test is called in a program block

I read your blog. I am trying to understand why i am having race conditions between a UVM driver and a separate UVM monitor, all inside the program block. The UVM monitor sees the signals 1 cycle late.

[ajeetha.cvc]

Show us your interface + clocking block code. Guess - driver is driving via if.cb.sig <= 1'b1 and your monitor is also sampling via if.cb.sig - in which case what you've described is indeed expected.

Ajeetha, CVC

www.cvcblr.com/blog

[rkovvuri]

I've been trying to understand the failure and i think i have an inkling on whats going on, but i 'd love to hear some feedback WRT to the System verilog scheduler.

To simplify the problem, I have a program and module thread. Both the threads generate clocks using a simple forever loop.

Now the program thread also has a clocking block that samples at the posedge of the program_clock. Like below.

clocking cb @(posedge program_clock)

output var1;

endclocking

Say i have a code in the program thread that is coded something like this.

@(posedge program_clock);

if (cb.var1) ...

Now in this code, i notice that cb.var1 is always 1 more value older than the previous value. However if i change this to :

@(cb);

if (cb.var1)...

Then everything is correct. The values are previous value at the clock edge.

I also noticed that if the clocking was written such that its clock came from a module, like this:

clocking cb @(posedge module_block.clock);

output var1;

endclocking

And my sampling code was:

@(posedge module_block.clock);

if (cb.var1)...

Then things are correct again.

So I guess i am trying to understand 2 things.

1: What is the difference between @(posedge prog_clock) versus @(cb). Both are the same. One is sampling event at the posedge of a clock. Other is a clocking block event. Somehow in terms of SV scheduler, they are treated differently as they provide different outcomes.

2: Why is that if we use a clock from a module thread and then use the sampling technique of @(posedge clock) rather than @(cb), then again things work correctly. Again, i am trying to understand how the SV scheduler schedules these events.

I'd love to hear any feedback on these.

Thanks!

[dave_59]

You should only use @(cb) with the signals defined in the clocking block for sampling or driving, otherwise you will get race with the behaviors inside the clocking block.

Do you have an IEEE LRM? It explains the races you are having. The Accellera 3.1 LRM was not very clear about this.

[rkovvuri]

Dave: Yup i have been seeing that i get race conditions if i don't use the clocking block event. But i'd like to know why ( i terms of the SV scheduler). Yup I have the IEEE 1800-2009 spec. Can you point me the section or chapter that describes this?. I could not find anything.

[dave_59]

Look at 14.13

Upon processing its specified clocking event, a clocking block shall update its sampled values before triggering

the event associated with the clocking block name. This event shall be triggered in the Observed

region. Thus, a process that waits for the clocking block itself is guaranteed to read the updated sampled values,

regardless of the scheduling region in which either the waiting or the triggering processes execute. For

example:

clocking cb @(negedge clk);

input v;

always @(cb) $display(cb.v);

always @(negedge clk) $display(cb.v);

The first always procedure above is guaranteed to display the updated sampled value of signal v. In contrast,

the second always exhibits a potential race, and may display the old or the newly updated sampled

value.

[rkovvuri]

Thats it!. Thanks so much Dave!

I read section 14.10 where it says that the clocking block event and the edge sampling are equivalent and stopped there.