Uvm_hdl_read gives Incorrect value

UVM
1

Hi All,

RTL increases value of register TAIL_PTR, 4ns after handshake on Write Response channel ( i.e when BValid & BResp are both asserted )

In our Tb UVC’s monitor has analysis_port which broadcasts when this handshake occurs

function void write_bresp( axi_resp resp);
         bit [7:0] awlen;

 awlen = BResp_Awlen_q.pop_front(); // Queue populated based on handshake on AW Channel

 for( int i = 0; i <= awlen ; i++ ) begin
      config_h.tail_ptr++;
      if( config_h.tail_ptr == 32'd1024 ) // 1K depth
          config_h.tail_ptr = 0;  
 end
`uvm_info("FW_BRESP",$sformatf("Tail_PTR incremented to 'd%0d",config_h.tail_ptr),UVM_LOW)

 fork
   begin
      automatic int unsigned tail_ptr = config_h.tail_ptr;
      automatic bit [31:0] rd_data;

      #4ns;
      if( !( uvm_hdl_read("tb_top.<RTL_Hierarchy_of_TAIL_PTR>",rd_data) )
        `uvm_error("FW_BESP",$sformatf("Unable to Read"))

      if( rd_data != tail_ptr )
      `uvm_error("FW_BRESP",$sformatf("TAIL_PTR mismatch"))
   end 
 join_none
endfunction

Here is an interesting observation in my simulation

In the waveform RTL increases value of TAIL_PTR at 679.502ns from 0x17D to 0x17E

The write function is called at 676ns.

After 4ns at 680ns ( approx 0.5ns after RTL increments ) delay Tb performs uvm_hdl_read

However rd_data fetches the value as 0x17D giving a mismatch error

When I check at 680ns I observe that RTL has incremented TAIL_PTR to 0x17E, yet I observe the mismatch error

Any suggestions ? Won’t the uvm_hdl_read consume 0-simulation time ?

Pls note that the Tb is performing RAL based Frontdoor / Backdoor activities via different sequences. Could RAL based Backdoor read cause any possible conflicts ?

Thanks

2

According to the documentation, it should consume zero simulation time (C-code):

image
image619×137 3.63 KB

This aligns with the definition of backdoor access.

As a general practice, I recommend avoiding ‘wait’ statements such as the example below:

A better approach is to wait for an event to occur.
You can trigger an event on a TAIL_PTR register value change and then validate the new value after the event.
This requires understanding the precise RTL behavior of the register.
Using this method helps keep your verification code independent of clock, cycle, or time accuracy

3

Hi Michael,

The 4ns delay is due to a repeater b/w UVC and the IP/ RTL ( repeater takes 4ns fixed delay )

The write_bresp gets called via Monitor’s Analsys Port when it sees a handshake on B channel from UVC’s perspective.

It would take another 4ns for the handshake to reflect b/w repeater and RTL

The RTL would increment the value of TAIL_PTR register on seeing this handshake

4

I’m unclear about the structure of your testbench.

Could you please include a block diagram showing your UVC, repeater, and IP/RTL components?
Is there additional RTL logic between “BValid & BResp are both asserted” (which is on the IP/RTL interface) and the “TAIL_PTR increment logic” (which is probably inside the RTL module)?

Additionally, please indicate on the diagram: where the Analysis Port writes the monitored transaction.