I have a (VHDL) DUT which is a state machine that needs to talk to a peripheral, which we have a model for.

Our predictor (SystemC) also needs to access the peripheral model.  So we have two components which need access to a single model.

If the peripheral model is VHDL, I would let the DUT communicate with the peripheral model, and use a monitor hanging off the interface to synchronize to my predictor.

If the peripheral model is SystemC, I would let the predictor (which is also SystemC) talk directly to the model, and send a copy of the transaction to a FIFO in a synchronization component plugged in to the peripheral interface of the DUT.

Is this a typical scenario?  I've gotten both of these scenarios to work, I just wonder if there is a better way.

Hi,

I have following scenario :

1) There are backdoor writes without using RAL to some registers.

2) I want to run reset sequence.

Now for this first I want to update mirrored values of registers with backdoor values. Then check those values.

What is the method for this ?

What is correct way for testing in this scenario ?

Thanks.

Hello Folks, 

I am unable to get a response from the vsequencer to my register model sequence. I see that the register model sequence does generate the first transaction and when the response of this transaction comes back to the vsequencer the sequence hangs. I found on couple of forums that setting provides_responses bit to 1 in the adapter class should resolve this issue. However I am still not able to make this work.  

Here are the steps that I followed to Integrate uvm_reg model in my uvm environment.  

1. Generate the uvm_reg model using one iregGen/ralGen script

2. Instantiate the model in the uvm_env. 

3. Instantiate the adapter class in uvm_env 

4. Assign a sequencer and adapter class to the register model. 

I am running the basic built-in register model sequence uvm_reg_hw_reset_seq. 

*********************************************

AXI Adapter code

********************************************

Creating a UVM register block that is a sub-block of another UVM register block, when I call the configure function of the sub-block, I get this warning.

UVM_WARNING @ 0 ns: reporter [UVM/RSRC/NOREGEX] a resource with meta characters in the field name has been created "regs.foo_regs"

because of this implementation of configure from the UVM 1.2 source code

function void uvm_reg_block::configure(uvm_reg_block parent=null, string hdl_path="");

  this.parent = parent;

  if (parent != null)

    this.parent.add_block(this);

  add_hdl_path(hdl_path);

  uvm_resource_db#(uvm_reg_block)::set("uvm_reg::*", get_full_name(), this); endfunction

Because the full name for the sub-block includes the name of the parent block with a "." between it.

Am I missing something or doing something wrong?  Seems like this will always happen with nested register blocks.

I'm working on upgrading to UVM 1.2 (from 1.1d).

I am seeing a case where multiple sequences have called a sequencer's grab(), they are both blocked waiting on a grab() done by an earlier sequence, and when that earlier sequence calls ungrab(), both of the waiting sequences unblock and their grab() calls complete.

I thought this shouldn't happen.  My understanding was that the grab ensured that only one grabbing sequence would win that arbitration until it ungrabbed.

Instrumenting the UVM code, I can see the grant_queued_locks() function calling m_set_arbitration_completed() for two sequences in a foreach loop.

Am I misunderstanding grab/ungrab or doing something wrong?

Thanks.

Hello there,

As per Mentor's UVM guidelines 5.2 [1], reset_phase() will be obsolete in future releases.

During DVCon 2014, Cadence recommends to use run_phases() on slide 5 of [2].

With the release of UVM-1.2, I believed that the sub-phases of run_phase are now stable and clean.

Now with the recommendations above, it seems that the it's better to stick with run_phase() itself.

As UVM delelopers, what are your views about it ? What do you recommend ?

My intention is not to start a flame war of any kind. But to understand which route to opt in order that most of my UVM code would be compatible with UVM 1.3.

All in all, it appears that there is a miscommunication on the web.

[1]: https://verificationacademy.com/cookbook/UVM/Guidelines

[2]: http://proceedings.dvcon-europe.org/2014/presentations_and_papers/T5_3_presentation.pdf

regards,

Chitlesh

Hi All,

We have uvm_resource_db for setting and getting the resource. Uvm have "get_by_name", "get_by_type", "read_by_name", "read_by_type" functions for getting the resource.

please let me know why do we need multiple function for getting the resource or what are the scenarios where we need these different function for getting the resource.

Thanks,
Rahul Kumar

Hi,

I am having some trouble with creating a register model for my DUT.

It is intended for APB transactions.

I included an adapter and a predictor.

When i try to read or mirror a register i have written to i get a wrong value.

when looking at the waves i see that ALL my transactions are done properly - read and write.

also i noticed that the bus2reg function is called twice for each transaction, and in the write transactions both

calls to bus2reg function gives the same values but in the read transaction, the first call to bus2reg is good

and in the second call i get 0 in the data.

Any thoughts would be much appreciated...

my adapter:

Thx,

Assaf

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 ?

Let's say that I have a VHDL DUT which is a state machine driven by a 50MHz clock (20 ns period).

This state machine has 5 states which advance on every clock, and loops after the final state.

On the final state, it reads an external counter.

Now let's say I want to create a "golden reference" model for the DUT (using SystemC).

Ok so let's see, the only way this would work is if I code a looping thread, that simply waits 100 ns, then reads the counter, and repeats.  Agree?

Now fast forward a few months, and the DUT has grown exponentially; it's now a 2000-state state machine, it processes input messages, waits on interrupts, etc.

Yet somewhere buried in it's multi-branch state tree, it still needs to grab the contents of this counter.

Since I have to guarantee they grab the counter value at the same time, am I supposed to inject the actual delay values of the DUT's state machine branches into the reference model?

This sounds like the WRONG thing to do.  Thoughts?

I found that UVM register model use semaphore to avoid conflicts, and this may cause some problems:

(1) when one sequence is writing some registers, and at the mean time, a UVM_BACK_DOOR is reading some registers, conflict happened. I found that the uvm_back_door reading is stoped.( in m_atomic.get(1) )

(2)another scenario: when config the registers using uvm register model in one sequence, one on fly reset happened, so I need to kill the sequence. and then uvm_do_on this sequence again. One problem came up, the second sequence will stop at the same writing register as the first sequence. I guess it also because the semaphore problems.

I hope that someone will help me to solve this problems. Thanks.

Hi all,

First I apologize if I am using the wrong forum for the question.

Please, I would like to know whether someone here could give updates on uvm-sc status. When will a first public release be available ?

Regards

Hi,

I want to use the "uvm_debug" verbosity but i couldn't find it in uvm1.1/1.2 class reference user guide.

Thanks

Is there any particular reason why uvm_reg doesn't have an associated post_predict function or post_predict callbacks defined? A use model could be, for example, to check bus responses of register accesses. This is an aspect that applies to the whole register and not an individual field.

In the new function of uvm_component.svh, there is a message "[NEWCOMP] Creating" which gets printed while creating components.

if(uvm_report_enabled(UVM_MEDIUM+1, UVM_INFO, "NEWCOMP"))
    `uvm_info("NEWCOMP", {"Creating ",
      (parent==top?"uvm_top":parent.get_full_name()),".",name},UVM_MEDIUM+1)

With UVM_VERBOSITY=FULL, I am unable to print the above message. Please help to enable the printing of above message.

Also, `uvm_info already contains uvm_report_enabled, so is there a reason to again check for uvm_report_enabled.

`define uvm_info(ID,MSG,VERBOSITY) \
   begin \
     if (uvm_report_enabled(VERBOSITY,UVM_INFO,ID)) \
       uvm_report_info (ID, MSG, VERBOSITY, `uvm_file, `uvm_line); \
   end

We ran across an issue when updating registers containing W1C fields.  Specifically, if any field of the CSR requires an update, then calling the parent register's update() results in all W1C fields being written with 1.

Example:  register CTL has field GO with access type W1C in bit 31.  It has field CMD with access type RW in bits 3:0.  Both fields have reset value of 0.

So, coming out of reset, we do:
CTL.CMD.set(2);

CTL.update();

The actual transfer goes out with data of 32'h8000_0002.  Nobody asked for bit 31, but there it is.

The issue appears to be with uvm_reg_field method XupdateX.  For the W1C and W0S cases, it returns a value of "~m_desired".  So, desired is 0, it wants to write a 1, even if m_mirrored is already 0.

I'm not sure what I would consider the 'correct' behavior here.  I can see two possibilities for W1C.

What I would prefer is that if I set(1), update writes a 1.  But, I could also see having it such that XupdateX evaluates ~m_desired & m_mirrored.

In the UVM register model, if you create a register or a field which is wider than the bus width there is no way to control what order the multiple bus operations occur to update the register/field value. In my case I was using BIG_ENDIAN addressing and the register model would always write the largest address first. My design spec required that the largest address be written last. I searched in vain for a way to change this but ended up overriding the 'do_bus_write' function in 'uvm_reg_map'. If you've run into a similar issue, here's my workaround. 
 
reversed_reg_order_map.sv

`ifndef __REVERSED_REG_ORDER_MAP_SV__
 `define __REVERSED_REG_ORDER_MAP_SV__
  
class reversed_reg_order_map extends uvm_reg_map;
   `uvm_object_utils(reversed_reg_order_map)
   function new(string name="reversed_reg_order_map");
      super.new(name);
   endfunction

   extern virtual task do_write_bus_ops(uvm_reg_bus_op bus_ops[$],
                                        uvm_reg_item rw,
                                        uvm_sequencer_base sequencer,
                                        uvm_reg_adapter adapter);

   extern virtual task do_bus_write(uvm_reg_item rw,
                                    uvm_sequencer_base sequencer,
                                    uvm_reg_adapter adapter);
endclass


task reversed_reg_order_map::do_write_bus_ops(uvm_reg_bus_op bus_ops[$],
                                              uvm_reg_item rw,
                                              uvm_sequencer_base sequencer,
                                              uvm_reg_adapter adapter);
   foreach (bus_ops[i]) begin
      uvm_sequence_item bus_req;
      uvm_reg_bus_op    rw_access;
      
      adapter.m_set_item(rw);
      bus_req = adapter.reg2bus(bus_ops[i]);
      adapter.m_set_item(null);
      
      if (bus_req == null)
        `uvm_fatal("RegMem",{"adapter [",adapter.get_name(),"] didnt return a bus transaction"});
      
      bus_req.set_sequencer(sequencer);
      rw.parent.start_item(bus_req,rw.prior);

      if (rw.parent != null && i == 0)
        rw.parent.mid_do(rw);

      rw.parent.finish_item(bus_req);
      bus_req.end_event.wait_on();

      if (adapter.provides_responses) begin
         uvm_sequence_item bus_rsp;
         uvm_access_e op;
         // TODO: need to test for right trans type, if not put back in q
         rw.parent.get_base_response(bus_rsp);
         adapter.bus2reg(bus_rsp,rw_access);
      end
      else begin
         adapter.bus2reg(bus_req,rw_access);
      end

      if (rw.parent != null && i == bus_ops.size()-1)
        rw.parent.post_do(rw);

      rw.status = rw_access.status;

      `uvm_info(get_type_name(),
                $sformatf("Wrote 'h%0h at 'h%0h via map \"%s\": %s...",
                          bus_ops[i].data, bus_ops[i].addr, 
                          rw.map.get_full_name(), rw.status.name()), UVM_FULL)

      if (rw.status == UVM_NOT_OK)
        break;
   end
endtask 

task reversed_reg_order_map::do_bus_write (uvm_reg_item rw,
                                           uvm_sequencer_base sequencer,
                                           uvm_reg_adapter adapter);

  uvm_reg_addr_t     addrs[$];
  uvm_reg_map        system_map = get_root_map();
  int unsigned       bus_width  = get_n_bytes();
  uvm_reg_byte_en_t  byte_en    = -1;
  uvm_reg_map_info   map_info;
  int                n_bits;
  int                lsb;
  int                skip;
  int unsigned       curr_byte;
  int                n_access_extra, n_access;
  int                n_bits_init;
  uvm_reg_bus_op     bus_ops[$];
   

  Xget_bus_infoX(rw, map_info, n_bits_init, lsb, skip);
  addrs = map_info.addr;
  // `UVM_DA_TO_QUEUE(addrs,map_info.addr)

  // if a memory, adjust addresses based on offset
  if (rw.element_kind == UVM_MEM)
    foreach (addrs[i])
      addrs[i] = addrs[i] + map_info.mem_range.stride * rw.offset;

  foreach (rw.value[val_idx]) begin: foreach_value

     uvm_reg_data_t value = rw.value[val_idx];
     curr_byte = 0;
    /* calculate byte_enables */
    if (rw.element_kind == UVM_FIELD) begin
      int temp_be;
      int idx;
      n_access_extra = lsb%(bus_width*8);                
      n_access = n_access_extra + n_bits_init;
      temp_be = n_access_extra;
      value = value << n_access_extra;
      while(temp_be >= 8) begin
         byte_en[idx++] = 0;
         temp_be -= 8;
      end                        
      temp_be += n_bits_init;
      while(temp_be > 0) begin
         byte_en[idx++] = 1;
         temp_be -= 8;
      end
      byte_en &= (1<<idx)-1;
      for (int i=0; i<skip; i++)
        void'(addrs.pop_front());
      while (addrs.size() > (n_bits_init/(bus_width*8) + 1))
        void'(addrs.pop_back());
    end
    curr_byte=0;
    n_bits= n_bits_init;     
              
    foreach(addrs[i]) begin: foreach_addr
      uvm_reg_bus_op rw_access;
      uvm_reg_data_t data;

      data = (value >> (curr_byte*8)) & ((1'b1 << (bus_width * 8))-1);
      curr_byte += bus_width;
       
      `uvm_info(get_type_name(),
         $sformatf("Writing 'h%0h at 'h%0h via map \"%s\"...",
              data, addrs[i], rw.map.get_full_name()), UVM_FULL);

      if (rw.element_kind == UVM_FIELD) begin
        for (int z=0;z<bus_width;z++)
          rw_access.byte_en[z] = byte_en[curr_byte+z];
      end
                
      rw_access.kind    = rw.kind;
      rw_access.addr    = addrs[i];
      rw_access.data    = data;
      rw_access.n_bits  = (n_bits > bus_width*8) ? bus_width*8 : n_bits;
      rw_access.byte_en = byte_en;

      n_bits -= bus_width * 8;
       
      bus_ops.push_back(rw_access);

    end: foreach_addr

    foreach (addrs[i])
      addrs[i] = addrs[i] + map_info.mem_range.stride;

  end: foreach_value

   // reverse the write order
   begin
      uvm_reg_bus_op   reversed_bus_op_list[$];
      foreach (bus_ops[i])
        reversed_bus_op_list.push_front(bus_ops[i]);

      do_write_bus_ops(reversed_bus_op_list, rw, sequencer, adapter);
   end

endtask

`endif //  `ifndef __REVERSED_REG_ORDER_MAP_SV__

Then I used a factory type override:

set_type_override_by_type(uvm_reg_map::get_type(),
		          reversed_reg_order_map::get_type());

Hi,

While debugging a prediction error returned by "Bit Bashing Test Sequence", I came to read the uvm_reg_map::do_bus_read/do_bus_write methods which seems incorrect when it comes to computing the "byte enable" for the bus accesses (ie data member "byte_en" of the object of type uvm_bus_reg_op created by those functions)

I'm explain the issue that I think I found here-below, can you please give me your feedback (Am i wrong or not?)

My understanding about "uvm_reg_map::do_bus_read/do_bus_write" methods about is that

• 
  
• these methods are called when I request a frontdoor read/write access and  I don't supply a user frontdoor sequence.
• 
  
• these methods aimed at splitting the high level object uvm_reg_item into as many uvm_bus_reg_op as need on the real bus.
• 
  
• part of their role is to compute bus lane "byte enable" based on length and base address for a UVM_REG and length, base address and field offset in the reg for a UVM_FIELD
• 
  

task uvm_reg_map::do_bus_write (uvm_reg_item rw,
                                uvm_sequencer_base sequencer,
                                uvm_reg_adapter adapter);
  [...]
  uvm_reg_byte_en_t  byte_en    = -1; // <= here the default value of byte_en is set to 'all ones'
  [...]
  foreach (rw.value[val_idx]) begin: foreach_value
    [...]
    /* calculate byte_enables */
    if (rw.element_kind == UVM_FIELD) begin // <= here byte_en is re-computed for UVM_FIELD only, not for UVM_REG
        [...]
    end
    [...]
    foreach(addrs[i]) begin: foreach_addr
      [...]
      uvm_reg_bus_op rw_access;
      [...]
      if (rw.element_kind == UVM_FIELD) begin // <= here the slice of the computed byte_en corresponding to
                                              //    the current bus address is applied to the bus (rw_access.byte_en)
                                              //     for UVM_FIELD only, not for UVM_REG
        for (int z=0;z<bus_width;z++)
          rw_access.byte_en[z] = byte_en[curr_byte+z];
      end
      [...]
      rw_access.byte_en = byte_en; // <= here for UVM_REG, the default 'all ones' byte_en value is applied
                                   //    and  for UVM_REG, the correct value of rw_access.byte_en assigned above is
                                   //     erroneously overwritten
      [...]
    end: foreach_addr
    [...]
  end: foreach_value
endtask: do_bus_write

But the extract of code here-below shows two issues:

• 
  
• for a read/write to a UVM_REG, the byte_en is hard coded to "all ones" which seems incorrect to me in at least 2 cases:
  • 
    
  • if the bus is 4-Byte wide, a register R1 to write is 1-Byte wide and at address 1 and another register R0 is also 1-Byte wide and located at address 0, then trying to write R1, will also write R0.
  • 
    
  • if the bus is 4-Byte wide, a register R0 to write is 6-Byte wide and at address 0 and another register R1 is 1-Byte wide and located at address 6, then trying to write R0, will also write R1.
  • 
    
• 
  
• for a read/write to a UVM_FIELD, there's a complex computation of byte_en for the whole field , then another computation to extract the correct bus byte enable from the whole field byte_enable. Those 2 computations seems correct to me but the last assignemnt "rw_access.byte_en = byte_en;" breaks everything by systematically setting the same bus byte enables value. For a field spanning several bus addresses this is correct/acceptable for the first bus access but this incorrect for the other bus accesses.
• 
  

Any feedback welcome, thank you

Jordan