Backdoor access by better use of configure() or add_hdl_path()

[paul-demo]

There was some discussion of backdoor access in other threads, but at peakrdl-uvm==2.3.0, I don't see it doing what I would expect in the generated UVM file. I'm a design engineer but trying to help our DV team figure out what to do about this without writing code that walks every register (since PeakRDL already does this and knows them all better than our postprocessing would).

From uvm_reg.svh, the hdl_path needs to be provided as the third argument to configure() in order for the nice hierarchical structure of the UVM classes to be used to directly refer to the identical hierarchical structure of the field_storage struct in the generated RTL. Without this, the fact that the fully qualified RTL path name is identical to the fully qualified class/instance hierarchy name is of no use because there is no kind = "RTL" kind of path.

It seems the generator or the user of the generator need to call add_hdl_path_slice() on every reg/field to add the RTL path to access that reg field and allow it to be peeked/poked. Or, PeakRDL-UVM could provide the third argument to configure() which does this, and basically just return the same thing as get_full_name(). This is explained in the docstring here:

   // Function: set_backdoor
   //
   // Set a user-defined backdoor for this register
   //
   // By default, registers are accessed via the built-in string-based
   // DPI routines if an HDL path has been specified using the
   // <uvm_reg::configure()> or <uvm_reg::add_hdl_path()> method.
   //
   // If this default mechanism is not suitable (e.g. because
   // the register is not implemented in pure SystemVerilog)
   // a user-defined access
   // mechanism must be defined and associated with
   // the corresponding register abstraction class
   //
   // A user-defined backdoor is required if active update of the
   // mirror of this register abstraction class, based on observed
   // changes of the corresponding DUT register, is used.
   //
   extern function void set_backdoor(uvm_reg_backdoor bkdr,
                                     string          fname = "",
                                     int             lineno = 0);

Basically although some_field.get_full_name() returns the fully qualified path that we want -- assuming you set the top level to a suitable prefix like some_tb.some_dut.some_regfile.field_storage -- the generated UVM does not actually provide the third third argument hdl_path when calling configure(), and so the implementation of configure() (below) doesn't call add_hdl_path_slice(), and users basically have to iterate over all the registers and do that themselves.

function void uvm_reg::configure (uvm_reg_block blk_parent,
                                  uvm_reg_file regfile_parent=null,
                                  string hdl_path = "");
   if (blk_parent == null) begin
     `uvm_error("UVM/REG/CFG/NOBLK", {"uvm_reg::configure() called without a parent block for instance \"", get_name(), "\" of register type \"", get_type_name(), "\"."})
     return;
   end

   m_parent = blk_parent;
   m_parent.add_reg(this);
   m_regfile_parent = regfile_parent;
   if (hdl_path != "")
     add_hdl_path_slice(hdl_path, -1, -1);
endfunction: configure

Is there something we're missing? It seems like PeakRDL-UVM is 90% of the way there and small tweak to the generator could leverage its get_full_name() to do something more useful and it could basically provide backdoor access by default.