RAL :: Does mirrored and desired both values are needed for prediction of register?

Hi,

While doing RAL classes study, i am confused with mirrored and desired value. I came to know that desired means “what we want to design have” and mirrored means “what we think to design have”. This statement is bit confusing.
I have following questions.

  1. If prediction can be done with only mirrored value, then what is need to desired one?
  2. What is the exact difference between these values?
  3. While doing analysis of update() method of uvm_reg, came to know that register write operation will perform with desired value only if desired value and mirrored value of that register are not same. can anyone explain the real time scenario, on which this can be needful?
  4. Can anyone please summarize at which method, which values are updated and how?

Thanks and Regards,
Mitesh Patel

In reply to mitesh.patel:

The mirrored value is the current state of DUT and desired value is the testbench part which contains value which testbench wants DUT to have by programming. (Similar to a monitor and driver respectively)
Mirrored value can get changed at run time inside DUT. Desired value is the value programmed or predicted by testbench.
Example: Writing “enable” to some register to enable some functionality changes the desired value. Checking the “status” bit of some register corresponds to checking the current status of DUT that can be checked by mirrored value which is last known state of DUT

Please refer code examples of RAL for further details

In reply to rajesh.deshpande:

Hi Rajesh,

Thanks for the response.
I am confused with sentence “Mirrored value can get changed at run time inside DUT. Desired value is the value programmed or predicted by testbench.”.
As per my knowledge, mirrored value is not inside DUT, it is part of uvm_reg_field. Can you please elaborate more about this sentence.

Apart from that, based on your reply, desired value is something which we programmed and we expect that, design register should have it. while mirrored value is updated based on the bus transaction.
Now, question is, whenever bus transaction is completed, uvm_reg will call the do_predict() method, which will update desired and mirrored value both. so, why both needs to update? ideally, only mirrored value should be updated, because our expected/programmed/desired value should not dependent on bus transaction.

Please provide your input on the same.

Thanks and Regards,
Mitesh Patel

In reply to mitesh.patel:

In reply to rajesh.deshpande:
Hi Rajesh,
Thanks for the response.
I am confused with sentence “Mirrored value can get changed at run time inside DUT. Desired value is the value programmed or predicted by testbench.”.
As per my knowledge, mirrored value is not inside DUT, it is part of uvm_reg_field. Can you please elaborate more about this sentence.
Apart from that, based on your reply, desired value is something which we programmed and we expect that, design register should have it. while mirrored value is updated based on the bus transaction.
Now, question is, whenever bus transaction is completed, uvm_reg will call the do_predict() method, which will update desired and mirrored value both. so, why both needs to update? ideally, only mirrored value should be updated, because our expected/programmed/desired value should not dependent on bus transaction.
Please provide your input on the same.
Thanks and Regards,
Mitesh Patel

Hi Mitesh,
The answer lies in different access policies defined (e.g. RW, W1C, RO, WC)
By definition, desired value is function of testbench set value, mirrored value and access policy. For RW policy, desired value is same as testbench set value i.e. mirrored value is irrelevant whereas for RO policy desired value is same as mirrored value i.e. testbench set value is irrelevant.
Every bus transaction changes the mirrored value and desired value is function of mirrored value so it must change.
Hope this answers your doubt.

Regards
Rajesh Deshpande

In reply to rajesh.deshpande:

Thanks Rajesh.
But my doubt is still same.

  1. Why two values are needed?
  2. At predict() what is need of updating desired value?
  3. What is the use case of update() method?
    Can you or anyone else, please explain in details?

Thanks in advance.

Regards,
Mitesh Patel

In reply to mitesh.patel:

This link should answer most of your questions.

The major use of update() is calling it on the entire register model after you’ve set() the individual desired register values. That optimizes the number of write transactions to only the registers whose mirrored and desired values are different.

In reply to dave_59:

oh okay Thanks @dave_59 for quick response,
Most of the questions are resolved, i think "use case point of view, mirrored is only predicted value, desired one is just to update the register fields, with the help of update() method. "

Please correct me if above statement is incorrect.

In reply to dave_59:

Hi Dave,

I’m relative “new” in using of RAL and some definitions related to its access methods are not clear for me. For e.g. mirror() documentation (in UVM 1.1d version)
The code of this method, is:
task uvm_reg::mirror(output uvm_status_e status,
input uvm_check_e check = UVM_NO_CHECK,
input uvm_path_e path = UVM_DEFAULT_PATH,
input uvm_reg_map map = null,
input uvm_sequence_base parent = null,
input int prior = -1,
input uvm_object extension = null,
input string fname = “”,
input int lineno = 0);
uvm_reg_data_t v;
uvm_reg_data_t exp;
uvm_reg_backdoor bkdr = get_backdoor();

XatomicX(1);
m_fname = fname;
m_lineno = lineno;

if (path == UVM_DEFAULT_PATH)
path = m_parent.get_default_path();

if (path == UVM_BACKDOOR && (bkdr != null || has_hdl_path()))
map = uvm_reg_map::backdoor();
else
map = get_local_map(map, “read()”);

if (map == null)
return;

// **Remember what we think the value is before it gets updated
** if (check == UVM_CHECK)
exp = get_mirrored_value();

XreadX(status, v, path, map, parent, prior, extension, fname, lineno);

if (status == UVM_NOT_OK) begin
XatomicX(0);
return;
end

if (check == UVM_CHECK) void’(do_check(exp, v, map));

XatomicX(0);
endtask: mirror

I have few questions here:

  1. According to "Remember what we think the value is before it gets updated
    ", and, if we are using (as it is recommended)set_auto_predict(0)
    then, a mirror() action will generate that UVM_ERROR from do_check() if there was a change in ACTUAL (DUT) register that we intended to read, right?

  2. What will be the (best) solution to avoid this error that comes when a mirror() is performed? a) set_auto_predict(1); b) set_compare(UVM_NO_CHECK); c) call a predict() before a mirror()?

  3. what we should do if the register of interest has volatile fields, but still we need to perform a mirror() with check.

Thank you in advance!
Alexandra