arno

Fatal have always exited abruptly without running the other phases. So that's another issue. Going back to the timeout : a timeout can be regarded as a an error or not - it's up to the user to decide. But it shouldn't be defaulted to being a fatal in the BCL. It is unusable as it is now.

The new uvm-1.1c changed the timeout to be fatal rather than error. But ithis change has introduced the following issue : the final phases are no longer executed at the end of the simulation. By instance, I have a timeout, I need the check phase to run to tell what is causing it. With uvm-1.1c., it is no longer possible. I think this is a problem that should be fixed : end of sim phases should be run in any case, timeout or not.

Hi Dave, as of now, the virtual interface is the most adopted way of connecting the tb and dut, hard to avoid. Putting the abstract class on the side, what would your advice be on using clocking-blocks/modports versus NOT using them ? Some commercial VIPs use them, and I'd like to have your advice on this. Thanks, Arno

Actually you can. On use example : to send the transfers generated by the sequence to a scoreboard.

The code you gave looks all right. there must be something wrong somewhere else. Difficult to say just with what you sent.

"function void connect();" should be "virtual function void connect_phase(uvm_phase);"

There is a recent DVcon paper on migrating from RGM to UVM_REG, based on a case study - it is not an automated process : http://events.dvcon.org/events/proceedings.aspx?id=131-2-P the paper is : "2P.4 Registering the Standard: Migrating to the UVM_REG Code Base"

As a user, experience has shown that default sequences can turn into a maintenance headache. So is everything that relies on strings settings. eg. : uvm_config_db#(...)::set(this,"top_level_env.ubus_example_tb0.ubus0.masters[0].sequencer.main_phase","default_sequence", .... Now if there are many of these statements, the strings being potentially very long, any typo or instance name mismatch will not be spotted : it may takes ages to spot a problem ... or never spot it. Legacy code is difficult to maintain and to bring up. With seq.start(), an error is immediately noticed at compile time

Hi Kathleen, the command you are giving is incomplete if you use cadence tools in 3 steps (ncvlog/ncelab/ncsim). This is the problem that triggerred this post. Not irun. When upgrading from uvm-1.1 to uvm-1.1a you need to add the pli load "-loadpli ${CDS_INST_DIR}/tools/uvm/uvm_lib/uvm_sv/lib/libuvmpli.so:uvm_pli_boot" to ncelab otherwise the new Cadence-specific pli call added in uvm-1.1a will crash. This is not documented anywhere in the release and users need to figure it out by themselves. Note that all is fine for the other simulators. This one example shows that having U

Hi Uwe, in my view the preferred way to use UVM is to download the release and compile it oneself : .sv and pli code. This way a user can play with it. A while back one of the goals was to keep OVM SystemVerilog only. But all the pli calls introduced have prevented this. Too bad. You seem to advise, as a Cadence representative, to use mandatorily the UVM release and pre-compiled libraries in the cadence tools release and I would like to object to this. I think that the recommendation should be to use the release and compile it oneself : - the SystemVeirlog code - the pli calls That's

UVM doesn't implement a mechanism to select which fields to print / compare / ... What I do to handle repetitive compare/print is use a int as field selector. eg. : xx.set_file_selector(10'b01101_01011); s=xx.convert2string(); xx.set_file_selector(10'b1111_1011); s=xx.convert2string(); xx.set_file_selector(10'b1111_1011); c=xx.do_compare(yy); ... etc ... Not super elegant, but it saves a lot of coding. The automation macros could probably be modified to add this without too much trouble.

You could : 0) create the sequence 1) set whatever properites members you have in this sequence 2) then start the sequence on the related sequencer The "uvm_do" macros are shortcuts but limit the use of the sequences.

I don't agree 100% with all I am reading here. The export/analysis_fifo was and still is a sensible way to do things, and is how it was done in AVM back 5 yrs ago. OVM put forward the "imp" and added the "decl" macros. It still didn't provide the required functionality => hence this post. I would also add that is confuse new adopters. The subscriber indeed offers the same functionality. Connecting components should be straight forward and not require a post on this forum. I would suggest to no longer promote the use these "decl" macros.

You should rather start the sequences on the sequencer(s) in your test : class my_test extends uvm_test; ... etc ... virtual task run_phase(phase); // create the sequences ... // start the sequences seq1.start(sequencer,null); seq2.start(sequencer,null); ... etc ... endtask endclass

clone() returns a uvm_object, which you need to cast. Your code should be : $cast ( chk_pkt , rcv_pkt.clone())