A VIP moves from UVM 1.2 to a 1800.2 library. It compiles on the first try, the regression is green, and the team relaxes. Three months later a register test that used to fail on a slave error passes, and a sequence that used to report a response-queue overflow is silent. Nothing broke the compile; the library changed what the same code does. Which differences stop the compile, which change behaviour without a word, and how do you write code that cannot be caught by either?

Three things called UVM

UVM 1.2 (2014) is an Accellera library: code. IEEE 1800.2 (2017, revised 2020) is a standard: a document that defines the API and ships no code. Reference libraries implement the standard: Accellera's 2020.3 line, which this course runs (Accellera:1800.2:UVM:2020.3.2), and the libraries simulator vendors ship. The overview, with the history, is in UVM 1.2 vs IEEE 1800.2 at a glance; this lesson is the detailed table.

Think of a rulebook's new edition and a publisher's printing of it. The edition dropped some old rules. The publisher kept many of them in an appendix so old games still work, and marked them "for compatibility". If you learn from that printing, old habits keep working, until you play with someone who has a different printing. The 2020.3 library's appendix is large: its source carries 155 @uvm-compat marks, API kept for 1.2 or 1.1d code that the standard does not define.

The layers

The delta table

Every "2020.3 library" entry was checked in the library source, and the compile column by probe files compiled against it with Verilator.

Build it: code that compiles on both

Most portable code is simply code that avoids the left column. Where a call really differs, guard it with the version macros. Accellera 1800.2 libraries define UVM_VERSION_POST_2017 (and the 2020.3 library UVM_VERSION_POST_2020_2_0 and later); UVM 1.2 defines neither.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

// snippet: compiles on UVM 1.2 and IEEE 1800.2
class dma_cfg_seq extends uvm_sequence #(apb_item);
  `uvm_object_utils(dma_cfg_seq)
  function new(string name = "dma_cfg_seq");
    super.new(name);
    set_automatic_phase_objection(1);          // instead of starting_phase in pre_body
    set_response_queue_error_report_disabled(0); // 1.2 name; the 2020 library keeps it, so both report overflows
  endfunction
  task body();
    apb_item it = apb_item::type_id::create("it");
    start_item(it);                            // instead of the uvm_do_with family
    if (!it.randomize() with { addr == LEN; write == 1; })
      `uvm_fatal("RAND", "apb_item randomize failed")
    finish_item(it);
  endtask
endclass

// In a component: the root and the factory without globals
//   uvm_root::get().print_topology();
//   uvm_factory::get().print();
`ifdef UVM_VERSION_POST_2017
//   1800.2-only code goes here, for example a component that returns 0 from use_automatic_config()
`endif

Watch it run: the compile probes

Each line below is one small probe file compiled against the course's 2020.3.2 library. The probes that compile are the dangerous ones: they hide 1.2 habits that a stricter library would reject.

compiles   uvm_top.print_topology();
compiles   set_config_int("*", "x", 1);                         (in a component)
compiles   if (starting_phase != null) starting_phase.raise_objection(this);
compiles   `uvm_do_with(i, {a == 1;})
compiles   uvm_path_e p = UVM_DEFAULT_PATH;
compiles   e.add_callback(cb);
fails      factory.print();            Can't find definition of scope/variable: 'factory'
fails      uvm_test_done.raise_objection(null);  Can't find definition of scope/variable: 'uvm_test_done'
fails      global_stop_request();      Can't find definition of task/function: 'global_stop_request'
fails      uvm_sequence_base sb = new("sb");   Illegal to call 'new' using an abstract virtual class 'uvm_sequence_base'

Migration switches: what they do on which library

• UVM 1.2: +define+UVM_NO_DEPRECATED compiles the deprecated API out. Code that builds clean with it is on the path to 1800.2. This is the cheapest portability check you can run.

• Earlier 1800.2 reference releases (2017-1.x): +define+UVM_ENABLE_DEPRECATED_API brought some old API back. In the 2020.3 kit that define appears only in a readme (src/deprecated/readme.important): the compatibility API is compiled unconditionally and marked @uvm-compat. On 2020.3, a clean compile proves nothing about portability.

• The compatibility package, uvm_compat_pkg (shipped beside the 2020.3 library in compat/) supplies the 1.2 packer behaviour and a concrete proxy sequence for changes that could not coexist in uvm_pkg.

A migration plan that holds up: compile against UVM 1.2 with UVM_NO_DEPRECATED and against the target 1800.2 library; grep for the left column of the table; then run the same seeds on both libraries and diff the logs. The diff finds the behaviour rows, which no compiler will.

What breaks: the migration that deleted an error

Take the hook's response-queue symptom. A driver calls item_done(rsp) for every write, but the write sequence never calls get_response(). On UVM 1.2, the ninth write overflows the default queue of 8 and the library reports UVM_ERROR, which a team usually notices and fixes. On the 2020 reference library the same overflow is dropped silently, because the report flag starts disabled. Migrating did not fix the bug; it removed the only message that pointed at it. If a later sequence does call get_response() for its read data, it can receive a stale write response and read the wrong value.

The register row is the same kind of trap in reverse: a write that the slave answers with PSLVERR leaves the mirror changed on 1.2 and unchanged on 1800.2, so a mirror(UVM_CHECK) that failed on one library passes on the other. Both are on the fact sheet for a reason. The defence is the dual-library regression diff above, plus code that does not depend on either default: item_done() without an argument when the data travels in the request, and an explicit pre_predict filter when a bus error must not reach the mirror.

Next: the library is settled; now make it fast. Performance at scale measures where a UVM bench spends its time.

Related topics

• UVM 1.2 vs IEEE 1800.2 at a glance

• Sequences and objections

• Responses and pipelined drivers

• Prediction modes