Ohh ! Ohhhh ! One Physical Register But Two Address Mapped to it ! How to Tackle Such Scenarios inside UVM Reg Model?

UVM
1

Hello Folks,

Have a typical scenario,

a. Wherein the Design has a physical register but two address mapped to it.
b. Lets say two address REGA-Address-0x02 and REGB-Address-0x04 mapped to the same physical register.
c. When you write to register address 0x02-REGA, then the value gets set to the corresponding bit in the physical register.
d. And When you read either 0x02-REGA or 0x04-REGB, you get the value set.
e. But then when you write to register address 0x04-REGB, then the value gets cleared in the corresponding bit in the physical register.

How to take care of such scenario inside the UVM register model ?
a. Do we need to have separate register inside the UVM reg model to satisfy this behavior or are there any other techniques ?

Had posted a similar kinda-of question in another post.
https://verificationacademy.com/forums/uvm/behavior-between-inter-dependent-registers-inside-uvm-register-model-how-solve-it-out

Kindly share in your ideas, suggestion etc !!

Regards,
Desperado

2

In reply to desperadorocks:

Hello Dave, UVM Enthusiasts, Experts Etc Etc…

It would be of great help if you can post your comments for my above query as I am stuck with the same. Kindly do the needful help.

Regards,
Desperado !!

3

A good place to start is always the UVM user guide. There you see that section 5.7.3 Aliased Registers shows how to implement this situation. In your case, the policies for the two registers’ fields will be different since accessing through one of the addresses sets and through the other one clears.

4

Hello Tudor,

Thanks for your response and pointers.

I tried the similar process as show below in the code, but somehow my simulation crashes when I tried to access my first register write. [Both in VCS and Incisive]

a. Build etc. are going through fine.
b. I was trying to write the register through register access process
i.e. reg_model.SET.write(); …
c. When the adapter tries to do the reg2bus & bus2reg transaction to update the register model the simulation is getting crashed in VCS and hangs in the Incisive.
d. I am clueless whats happening and stuck with the debug.

Any suggestions, ideas to overcome this ?? Appreciate your help.



class hello_F_cb extends uvm_reg_cbs;
   local static bit m_wpe = uvm_reg_field::define_access("RWW1C");
   local uvm_reg_field  m_toF;

   function new(uvm_reg_field toF, string access_type_config);
    m_toF = toF; 
    access_type = access_type_config;
   endfunction: new 
  
   virtual function void post_predict(
     input uvm_reg_field fld,
     input uvm_reg_data_t previous,
     inout uvm_reg_data_t value,
     input uvm_predict_e kind,
     input uvm_path_e path,
     input uvm_reg_map map);
   
     if (kind == UVM_PREDICT_WRITE) begin 
      if(access_type == access_type_cfg'(WPEA))begin 
        value = 1;
      end 
      else if(access_type == access_type_cfg'(WPEW1CA))begin 
        value = 0;
      end
     end 
     
     void'(m_toF.predict(value, -1, UVM_PREDICT_WRITE, path, map));
     
   endfunction: post_predict 
  endclass: hello_to_F_cb
  
  hello_to_F_cb WPE2F;
 
  CLR_reg CLR;
  SET_reg SET;
  
  ...... 
  
  WPE2F = new(this.CLR.D, WPEA);
  uvm_reg_field_cb::add(this.SET.D, WPE2F);
  
  WPE2F = new(this.SET.D, WPEW1CA);
  uvm_reg_field_cb::add(this.CLR.D, WPE2F);

Thanks,
Desperado !!

5

In reply to Tudor Timi:

My bad.
Deleting my comment, since the problem is exactly about sharing a register with multiple address in the same map.

6

In reply to desperadorocks:

I think the problem is with the call to predict(…). By calling it with UVM_PREDICT_WRITE as an argument you are calling the post_predict() callback on the other field, which will in turn call the post_predict() callback on the current field and so on, resulting in an endless loop. Try changing to UVM_PREDICT_DIRECT as that won’t trigger the post_predict() callbacks.

7

In reply to Tudor Timi:

Hello !!

Found the issue what was happening. It was the mistake in the directed write process i.e. instead of UVM_PREDICT_DIRECT I had called the UVM_PREDICT_WRITE and that made the process to hang.

@ Tudor : Oh… Cool… Thanks for your inputs as well. Appreciate your help.

Regards,
Desperado !!