Jump to content

Calling uvm run_test from a program block instead of a module


Recommended Posts

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!

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...