deprecated code in uvm

[uvmcraft]

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 ?

 

[uwes]

hi,

 

the standard procedure is to review "deprecated" items with major releases such as 1.1 or 1.2. minor versions should be fully API compatible even if the release span of UVM11 was few years. There is no strict policy such as "deprecated for one major release then removal" or similar. technically speaking the standard doesnt have any "deprecated items", the reference implementation usually supports the latest standard (via UVM_NO_DEPRECATED) but also offers support for older API via (UVM_NO_DEPRECATED unset)

 

>Has the decision been made to delete the deprecated code from uvm (as stated) ?

depends upon the code and the VIPTSC decisions driven by member companies.

 

using the library in deprecated and non-deprecated mode in ONE simulation is not really an endorsed(or supported) use model. uvm_pkg expects to be a singleton in the simulation and can be then eitherin  UVM_NO_DEPRECATED mode or not. 

 

>This creates compatibility issues between components that uses deprecated and components that don't...I would say big issues.

normally "deprecated" API is purely additional. that means you can use the current variant of the API but in addition you can still use the old variant. it shouldnt be the an "either" that only one way works.

 

can you please provide an example

 

 

/uwe

[David Black]

Usually when features are deprecated because either (A) there is a safer/better way to do the same thing (i.e. the deprecated approach duplicates existing functionality), or ( the feature is deemed dangerous and has caused many problems. With this in mind, you can either: (A) stick with an older version of the standard, ( update the code to not use deprecated features, or © use both techniques, but use a version ifdef to choose between the two. Much C/C++ code takes the last approach © for compatibility, but over time this can lead to very hard to read code. Here is an example where the feature has been removed from versions after 1.1 and we need to write code that works in both:

 

`ifdef UVM_POST_VERSION_1_1

seq.set_starting_phase(phase);

`else

seq.starting_phase = phase;

`endif

[uvmcraft]

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.

[tudor.timi]

I don't see why you need to support both deprecated and non-deprecated. Usually when you're developing a testbench you choose a UVM version and stick with it. You can always change your code to only use non-deprecated constructs and ride with that. It only gets more complicated if you're developing VIP that's supposed to be used in multiple projects, but there the scope is more limited and focused and you won't get into such situations that you need to care about deprecated features (speaking as an internal VIP developer).

[uvmcraft]

"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