ajeetha.cvc

Then you are looking for "transaction recording" feature, check CDN documentation on how to enable the same. Usually testbench debug is more interactively done (while the sim is running) than in the post-process mode. Regards Ajeetha, CVC www.cvcblr.com/blog

Remove the following options/flags to VCS command: -ntb_opts uvm Add the following: <your_custom_uvm_1.1c_dir>/src/uvm_pkg.sv (Look for exact path) +incdir+<your_custom_uvm_1.1c_dir>/src That should be it. Make sure you use latest release of tool. Regards Ajeetha, CVC www.cvcblr.com/blog

My guess - you are looking at time-0 view. Run for 1 ns and then see. Recall that all SV class objects are created after time-0 in simulation. Ideally a "testbench view" in a debugger should pop-up after start_of_simulation_phase - any EDA vendor doing it automatically, anyone? Regards Ajeetha, CVC www.cvcblr.com/blog

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

Check if you have `uvm_component_utils macro inserted in your "abc" test. Ajeetha, CVC www.cvcblr.com/blog

Hello McPall, Inside your test add the following piece of "debug code": task apb_test_1::dbg_eot(uvm_phase phase); forever begin : fe #100; phase.phase_done.display_objections(); end : fe endtask : dbg_eot And fork off this task from main_phase. In Questa on a sample hang scenario I get: # The total objection count is 1 # --------------------------------------------------------- # Source Total # Count Count Object # --------------------------------------------------------- # 0 1 uvm_top # 0 1 uvm_test_top # 0 1 env_0 # 0 1 agent0 # 1 1 monitor # --------------------------------------------------------- HTH Ajeetha, CVC www.cvcblr.com/blog

A crude way would be to have a variable indicating the number of pending_reads in a "common" place (say in a package) and access ti both from monitor and driver. One could use uvm_config_db to keep it more scalable/reusable maybe - but I am not sure if these are good "architectural" level solutions, your problem may better be solved via better re-arch, though it can't be done via forums/email. HTH Ajeetha, CVC www.cvcblr.com/blog

Do you have a corresponding uvm_config_db#(virtual chpp_sigif)::set somewhere in your env/test? Ajeetha, CVC www.cvcblr.com/blog

Robert, If you don't need constraints on the payload/dynamic array contents, a better approach would be to use the simple $urandom as below: class test; bit [7:0] da[]; rand int unsigned len; constraint cst_len { len inside { 2, 4, 8 }; } function void post_randomize; da = new[this.len]; foreach (da ) da = $urandom; $display ("%p", this); $display ("da.size: %0d", da.size); endfunction : post_randomize endclass : test program p; test t0; initial begin : test t0 = new; a1: assert (t0.randomize); end : test endprogram : p HTH, Ajeetha, CVC www.cvcblr.com/blog

There are several ways: 1. Declare that shared-var in top class (you named it parent, but it will be little confusing with OOP parent/child relationship - though UVM uses it all along). Then pass that to c1, c2 via new() 2. In case of UVM one could use config_db for this 3. If your small_child and big_child have a common base class, then declare the shared-var in that base-class HTH Ajeetha, CVC www.cvcblr.com/blog

You may want to look at $VCS_HOME/etc/* dir for built-in UVM and see if this was indeed necessary for VCS. Other option is to ask vcs_support@synopsys.com Ajeetha, CVC www.cvcblr.com/blog

Have you tried: onbreak {resume} ? std.env.stop is the most modern way of doing this, but it will require beyond VHDL-1987. Ajeetha, CVC www.cvcblr.com/blog

Cliff, We use "irun" for even re-run cases without any change to src-code (say with new VERBOSITY) - it does fairly intelligent work to avoid re-compiles. Ajeetha, CVC www.cvcblr.com/blog

Same here - many of our customers use these macros and often don't buy into this performance argument. Especially if they come from Specman background they got used to these stuff built-in to the language. With all due respect to AdamE's excellent paper - why can't the VIP-TSC decide one way or the other for the benefit of large user base? Having something defined with > 1000 lines of code in base class and saying don't use - doesn't seem to go well - atleast with our customers here. On the original point/debate - interestingly we prefer ALL_ON to DEFAULT as it is more "explicit" in naming and one can make exceptions via: ALL_ON | NO_COPY for instance. With DEFAULT - it is possible that a newer version of UVM base code might change the definition of default, and one needs to update the code! Any other views please? Ajeetha, CVC www.cvcblr.com/blog

VMM (1.0/1.1) did precisely that for vmm_env::gen_cfg etc. and it was well accepted by the users. Yes it can be little messy/complicated for the developer(s), but it works well for end users. Ajeetha, CVC www.cvcblr.com/blog