Which is first?

Can anyone help me out with my doubt?

In Ral which register gets updated first? Either the Register database or the registers inside DUT?

In reply to Anjali Karkagari:

Ther is not only 1 answer. It depends which command you are using. You have a collection of commands: read, write, get, peek, poke, update, mirror …

In reply to chr_sue:

Can you please explain for some commands in what way it chooses and why it chooses?

And also what I thought is that if it is “AUTO prediction” 1st the RAL database is updated and then registers inside DUT. When it is “EXPLICIT prediciton” 1st the registers in DUT is updated and then the RAL database is updated.

Is it correct?

In reply to Anjali Karkagari:

In reply to chr_sue:
Can you please explain for some commands in what way it chooses and why it chooses?

Please see the UVM Refernce Manual which is delivered with the UVM base class library.

In reply to Anjali Karkagari:

You need to understand that for each REGISTER, there are THREE copies: Hardware(HDL), Mirrored, and Desired. Any one of them could be first depending on the type operation being performed and access type of REGISTER. For example, a read-only (RO) register must always be updated in hardware first.

Please see this link for more use models.

In reply to dave_59:

Thank you sir. Here the Hardware(HDL) is the DUT registers right?

In reply to Anjali Karkagari:

In reply to dave_59:
Thank you sir. Here the Hardware(HDL) is the DUT registers right?

yes

In RAL registers, can it updated with bus sequences?

In reply to Anjali Karkagari:

I think the answer depends if you use the uvm_reg_predictor (Explicit Register Predictor) or if your environment use the autopredict connection (see How Data gets updated to register model during auto-predict = 1 ? Confused how/who updates it !! | Verification Academy).

You can have information about the differences between the two methods here http://www.verilab.com/files/litterick_register_final.pdf.

In case you are using the uvm_reg_predictor connected to a monitor of a protocol VC, then the register model will be updated when the TLM port connected to the predictor is triggered by your monitor. Your monitor VC could trigger this at different time points. For example, it could be when the last data is written or when the response is sent. This could be important in complex protocols like AXI.
You do not know when the DUT will update its registers. You have to align with the designer of the DUT on which point will the register be updated internally. For example, in case of AXI, should be with the last data, the response? or on each beat? (it should be with the response).
The register model has a busy flag mechanism to lock the the register database in case the specific register is being accessed by the frontdoor. If you try to predict a register while you are reading or writing that register, the prediction will fail. You have to wait until the busy flag goes down and then write the prediction. If you are doing a read and a write in parallel (AXI is possible) and both events are connected to the same TLM port connected to the uvm_reg_predictor, the precedence or the order of each one, will depend on the time that the TLM port was trigered by the monitor VC, so it is again depending on the implementation of the VC and the DUT slave. If both are triggered on the same clock simultaenously, your VC monitor can also determines if READ goes before WRITE or otherwise.

The uvm_reg_predictor has also an export reg_update TLM port which is triggered after the register model database (m_mirrored,m_desired,value) is updated. You can use that TLM port in your scoreboard and detect register model updates from the scoreboard.

If you have in your scoreboard both the VC monitor TLM port and the reg_update TLM port, the VC TLM port monitor will be triggered before the reg_update TLM port if one register is written. Obviously, if a data area (not a register) is accessed only the VC TLM port monitor will be triggered.
I am not sure if that is what you wanted to know.
i hope it helps.