dave_59

If you use start_item(req) - finish_item(req) instead of using the macros, you can achieve exactly what you want. You sequence will have req = my_sequence_item::type_id::create(_); start_item(req); // blocks until get_next_item() in driver //some late randomization here finish_item(req); // blocks until item_done() in driver. So don't call get_next_item() until the value in your driver has what you want it to have.

A virtual interface type is a valid type to pass as a parameter. It might help to show the actual error message you are getting. There are many tools issues with interfaces/virtual interfaces.

Answer posted here: https://forum.verificationacademy.com/forum/verification-methodology-discussion-forum/systemverilog-and-other-languages-forum/29709-range-must-be-bounded-constant-exp

Using abstract classes instead of virtual interfaces decouples the interface parameters from the class parameters. There have been a number of DVCon papers on this topic. Here is a link to the latest. Other techniques will be presented at this years DVCon. 1P.8 Deploying Parameterized Interface with UVM

See http://www.uvmworld.org/forums/showthread.php?364-set_report_default_file. There are many other options.

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.

Can you be more specific with what is not working (i.e. the behavior you are seeing versus what you expected to happen) What is the error message you are getting and on which line of code produces the message? What you have shown (minus the syntax errors, typos, and missing code fragments) looks fine to me.

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.

IT IS NOT RECOMMENDED TO USE UVM1.0P1 BE CAUSE IT IS BETA QUALITY.

I do not recommend that any one use uvm-1.0p1. I consider that version beta quality code, even though it was released with a production version of Questa. I also recommend that you do not use any example that require UVM 1.0p1. Questa 10.0c and later versions have uvm 1.1 built in. But even if you have an older version of Questa (at least 6.6d), you can compile the UVM yourself. See http://go.mentor.com/uvm1-0-questa. Just forget about UVM 1.0p1

I know what your problem is.

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

You are better off performance-wise wrapping many variables in one config class than setting/getting many individual variables. Yes, if you can get a handle to that component from an upper layer, you can replace 'this; with than handle.

s_obj is an associative array of sample handles, yet your config_db is parametrized by only a single sample handle. Try using a typedef typedef bit[3:0] addr_t; typedef sample s_obj_aa_t[addr_t]; s_obj_aa_t s_obj_aa; function build_phase(uvm_phase phase); super.new(phase); uvm_config_db#(s_obj_aa_t)::set(this,"*","s_obj_aa",s_obj_aa);

See the class uvm_cmdline_processor to get all of the command line options.

Look at the documentation for your simulator and install the GCC package that it recommends.

Please guide us into what kind of errors you are having. Better yet, why not ask on the systemverilog.in forum?

Did you remember to import the UVM package? There's no need to compile the UVM code. See http://go.mentor.com/uvm1-0-questa

swapnilm, It is possible you are looking at the Accellera SV 3.1a LRM which does not explain this topic very well. (It is hard for me to believe it is now 9 years old) It does not mention the relationship between virtual classes and pure virtual methods at all. The IEEE 1800-2005 LRM clarified this, and the 1800-2009 LRM is the most current, with the 1800-2012 LRM just about to be published.

Questa 6.4 is too old to run the UVM.

SV1800 LRM defines array manipulation methods to only work on unpacked arrays. One reason for this is when you have multidimensional array with a mixture of unpacked and packed array dimensions, the manipulation does not apply to the packed dimensions.

Streaming operator {<<{expression_to_reverse}}

You will not be able to run all examples with Modelsim; there is no randomization or function coverage in Modelsim See http://www.mentor.com/products/fv/modelsim/modelsim-distributors for Questa as well.

Unlike Modelsim, there is no trial version on Questa that you can download online without contacting a distributor or Mentor sales representative first.

You can use different uvm_comparer policy classes to control how individial fields are treated.