Jump to content

uvmcraft

Members
  • Content Count

    6
  • Joined

  • Last visited

  1. "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
  2. 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
  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 oc
  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.
×
×
  • Create New...