Verifying registers with RAL

UVM
1

Hi,
I have few ststus registers un my block (updated only by DUT).
I want to verify their value in my scoreboard. I don’t want to do it every cycle (as clocks doesn’t exist in scoreboard).
I want to use peek() function, but do it only when register changes.
What is the best way to do it?
Thanks

2

Hi,

I believe that there is no any event implemented under the uvm_reg_field. Say, even it exists, you are the one need to implement the mechanism in your environment to check the RTL value and update the register.

What you could do is, to read polling (use peek method) the register until the status matches in your scoreboard. It is something like below. Note! You need to have the hdl_path (backdoor path) of the register fields being set properly.


begin
   uvm_reg_data_t _data;
   uvm_status_e   _status;
   myral_h.my_reg.my_field.peek(_status, _data);
   while (_status == uvm_pkg::UVM_IS_OK && _data != <your desired status>)
   begin
      myral_h.my_reg.my_field.peek(_status, _data);
      //#<interval>ns; // This seems like totally un acceptable
      @ (posedge <interface pointer>.clock);
   end
end
<then do your desired action>

Hope this helps.

-Baser

3

You should not use any timing constructs (# delays) in your testbench code. UVM is designed so that the entire testbench (outside of the BFM functionality of the drivers) is transaction based and completely untimed. By adding these constructs, you are breaking this core tenet.

If you are waiting on your design to achieve a specific state based on an internal register value, I would recommend doing front door register accesses to poll until that value is reached. Doing the bus accesses won’t have any impact on simulation performance.

Also, scoreboards should be used as a component to compare transactions and verify that they are correct at the point they are monitored. Again, this is untimed and eliminates any need to check internal states of your design. If you want to check the internal functionality, bind in additional monitors or use the register back door function to check the values when desired, but don’t ‘wait’ on these register values in the scoreboard.

4

In reply to cgales:

I am not sure about your confidence on saying that doing polling using frontdoor will not cause any simulation run’s performance issue.
Say, for the case the same sequence to be re-used at higher level verification, and everyone on the sub-system doing the same, don’t you see how much it will impact the higher level simulation?
It will cause the unnecessary traffic on the frondoor busses. Hence, I believe peek and other backdoor capabilities are introduced.

-Baser