Jump to content

uvmcraft

Members
  • Content count

    6
  • Joined

  • Last visited

  1. uvmcraft

    deprecated code in uvm

    "Usually when you're developing a testbench you choose a UVM version and stick with it." I wish this situation occured more often (at least once for me !). Reusability implies supporting various testbenches, IPs, VIPs, etc ... and juggling with some extra uvm switches definitely doesn't help. uvm developers tripped on this too : attached is a small code example that has been passing if compiled with +UVM_NO_DEPRECATED and failing without it, on all versions of uvm-1.1 - fixed in uvm-1.2 though. My last on this topic will be : the less switches we have, the more "UNIVERSAL" UVM will be and more easily deployed. // This tb works fine for // // uvm-1.1<a,b,c,d> +UVM_NO_DEPRECATED // but fails for // uvm-1.1<a,b,c,d> without +UVM_NO_DEPRECATED // // all OK for uvm-1.2 // `timescale 1ns/100ps module tb_top; import uvm_pkg::*; `include "uvm_macros.svh" class env_cfg extends uvm_object; int count=0; `uvm_object_utils_begin(env_cfg) `uvm_field_int(count,UVM_ALL_ON) `uvm_object_utils_end function new(string name=""); super.new(name); uvm_config_db#(uvm_bitstream_t)::get(null, get_name(),"count",count); endfunction endclass class tb_env extends uvm_env; env_cfg my_cfg; `uvm_component_utils(tb_env) function new(string name, uvm_component parent); super.new(name,parent); endfunction virtual function void build_phase(uvm_phase phase); my_cfg=env_cfg::type_id::create({get_full_name(),"_prop_cfg"}); endfunction endclass class tb_test extends uvm_test; tb_env top_env; `uvm_component_utils(tb_test) function new(string name, uvm_component parent); super.new(name,parent); endfunction virtual function void build_phase(uvm_phase phase); super.build_phase(phase); top_env=tb_env::type_id::create("tb_env0",this); endfunction task run_phase(uvm_phase phase); `uvm_info("TEST","starting ...",UVM_LOW) phase.raise_objection(this,"test starting"); #10ns; if (top_env.my_cfg.count==99) `uvm_info("TEST","cfg setting found in uvm cfg db : OK",0) else `uvm_error("TEST","cfg setting not found in uvm cfg db") phase.drop_objection(this,"test end"); endtask endclass initial begin uvm_config_db#(uvm_bitstream_t)::set(null,"uvm_test_top.tb_env0_prop_cfg","count",99); run_test(); end endmodule
  2. uvmcraft

    deprecated code in uvm

    Hi Uwes, and thanks for reply. I take that no decision is made concerning the deletion of the deprecated code. Concerning the examples you're asking, I guess you know that there a fair number of features encapsulated between UVM_NO_DEPRECATED in the uvm-1.2/src, and as DavidBlack mentions, users end up with the hassle of supporting deprecated and no_deprecated. I would say the earlier the deprecated goes away the better.
  3. I have a question concerning the use of deprecated code in the uvm. There are a number of features that are "deprecated", and the user can exclude them with UVM_NO_DEPRECATED. The library states that the deprecated features can/might/will be deleted in future releases. However, those have still be there for several releases now. This creates compatibility issues between components that uses deprecated and components that don't...I would say big issues. Has the decision been made to delete the deprecated code from uvm (as stated) ? If so, when ?
  4. Hi, with VCS, I am trying to register with the uvm factory an object which is embedded inside a SV interface, using the hierarchy name as a type name. But VCS won't compile, whereas this scheme works with Questa. Here is the code snippet : interface my_if(); import my_pkg::*; localparam string my_path=$sformatf("%m"); class my_c function new() .... typedef uvm_object_registry#(my_c,{"my_c",my_path}) type_id; ... etc ... endclass ... etc ... endinterface I may be wrong, but the LRM doesn't seem to specify if this is supposed to work at run/compile time. Would someone know how to make this functionality work with VCS ?
  5. When a driver returns a response to the sequence, it calls 'set_id_info()' to set the identifiers of the transactions returned. This way, the originating sequence can correlate the response and the originating transaction, by matching the 2 fields sequence_id and transaction_id. This has a couple of drawbacks : the sequence writer must set this field 'transaction_id' by hand the transanction_id may not be unique - a bug can be introduced (sequence/driver) and go unnnoticed when the wrong matching occurs - worst scenario is when a user simply forgets to set it, and the matching still occurs, but is wrong ! An improvement/fix to address these 2 issues would be to use field 'inst_id' (which is unique) instead of 'transaction_id' (user defined). It looks to me the original intention was to use this field rather than 'transaction_id'. The code change would be : function void set_id_info(uvm_sequence_item item); if (item == null) begin uvm_report_fatal(get_full_name(), "set_id_info called with null parameter", UVM_NONE); end /* this.set_transaction_id(item.get_transaction_id()); */ this.set_transaction_id(item.get_inst_id()); this.set_sequence_id(item.get_sequence_id()); endfunction
  6. Using a parametrized driver simplifies the design, bring up and debug of the driver and the sequences. The downside is that sequences have to pass the parameter(s) along and will be less easily reusable. This becomes a problem when the sequence library gets big and there's many parameters. Commercial VIPs use non parametrized classes. It's probably a good reason to use them...or maybe not.
×