why we need the desired and mirror value in uvm ral ? when the write and read sequence of uvm ral was updated the both of desired and mirror value then why we consider the both desired and mirror value of ral ?
In reply to pavan_krishna:
In UVM RAL (Register Abstraction Layer), the concepts of “desired” and “mirror” values are used to represent the intended (desired) and actual (mirrored) values of a register after a sequence of register transactions.
Here’s a breakdown of the concepts:
Desired Value:
The desired value represents the value that the test writer intends to write into a register or registers.
It is set by the test sequence to specify the values that should be written to the registers during the execution of the sequence.
The desired value is typically set using the write method in UVM RAL sequences.
Mirror Value:
The mirror value represents the actual value that is observed or read from the DUT (Device Under Test) after the register transactions have been executed.
It is automatically updated by the RAL layer after register transactions like write and read operations.
The mirror value is used for comparison with the desired value to check whether the register transactions were successful.
Why Both Desired and Mirror Values?
Having both desired and mirror values serves a few purposes:
Verification:
The mirror value is compared against the desired value to verify whether the write and read transactions were successful.
This verification is a crucial step in ensuring that the registers in the DUT are behaving as expected.
Debugging:
In case of failures or discrepancies between the desired and mirror values, having both values allows for easier debugging.
Test writers can inspect the desired and mirror values to identify where the issues might be occurring.
Sequential Execution:
In a sequence of register transactions, a sequence item might set a desired value, perform a write operation, and then perform a read operation.
The mirror value, which gets updated after each transaction, reflects the actual state of the registers after each step in the sequence.
Here’s a simple example:
// UVM RAL Sequence
task main_phase(uvm_phase phase);
desired_value = 8'hA5;
// Set the desired value for a register
my_register.write(desired_value, .status(status));
// Perform a read operation to update the mirror value
my_register.read(.status(status));
// Compare the desired and mirror values
if (desired_value == my_register.get_mirror()) begin
`uvm_info("RAL_CHECK", "Register write and read successful", UVM_LOW)
end else begin
`uvm_error("RAL_CHECK", "Register write or read failed", UVM_LOW)
end
endtask
In summary, having both desired and mirror values in UVM RAL allows for effective verification, debugging, and validation of register transactions in a structured and systematic way.
rahulvala@gmail.com
Freelancer/verification engineer
https://www.linkedin.com/in/rahulvala/
In reply to Rahulvala:
In reply to pavan_krishna:
In UVM RAL (Register Abstraction Layer), the concepts of “desired” and “mirror” values are used to represent the intended (desired) and actual (mirrored) values of a register after a sequence of register transactions.
Here’s a breakdown of the concepts:
Desired Value:
The desired value represents the value that the test writer intends to write into a register or registers.
It is set by the test sequence to specify the values that should be written to the registers during the execution of the sequence.
The desired value is typically set using the write method in UVM RAL sequences.
Mirror Value:
The mirror value represents the actual value that is observed or read from the DUT (Device Under Test) after the register transactions have been executed.
It is automatically updated by the RAL layer after register transactions like write and read operations.
The mirror value is used for comparison with the desired value to check whether the register transactions were successful.
Why Both Desired and Mirror Values?
Having both desired and mirror values serves a few purposes:
Verification:
The mirror value is compared against the desired value to verify whether the write and read transactions were successful.
This verification is a crucial step in ensuring that the registers in the DUT are behaving as expected.
Debugging:
In case of failures or discrepancies between the desired and mirror values, having both values allows for easier debugging.
Test writers can inspect the desired and mirror values to identify where the issues might be occurring.
Sequential Execution:
In a sequence of register transactions, a sequence item might set a desired value, perform a write operation, and then perform a read operation.
The mirror value, which gets updated after each transaction, reflects the actual state of the registers after each step in the sequence.
Here’s a simple example:
// UVM RAL Sequence
task main_phase(uvm_phase phase);
desired_value = 8'hA5;
// Set the desired value for a register
my_register.write(desired_value, .status(status));
// Perform a read operation to update the mirror value
my_register.read(.status(status));
// Compare the desired and mirror values
if (desired_value == my_register.get_mirror()) begin
`uvm_info("RAL_CHECK", "Register write and read successful", UVM_LOW)
end else begin
`uvm_error("RAL_CHECK", "Register write or read failed", UVM_LOW)
end
endtask
In summary, having both desired and mirror values in UVM RAL allows for effective verification, debugging, and validation of register transactions in a structured and systematic way.
rahulvala@gmail.com
Freelancer/verification engineer
https://www.linkedin.com/in/rahulvala/
desired value is updated after write sequence but mirror value also updated what is need to update the mirror value in write operation?
same as operation happen in read operation, desired value is updated , what is need to update the desired in read operation?
in internal mirror value is update after write sequence and desired value is update after read sequence
In reply to pavan_krishna:
In UVM RAL (Register Abstraction Layer), the update of desired and mirror values after write and read sequences is handled by the RAL infrastructure. Let’s clarify the process:
Write Sequence:
When a write sequence is executed for a register, the write method in the sequence sets the desired value for that register. This desired value is the data that the test writer intends to write into the register.
After the write method is executed, the RAL layer initiates the actual write operation to the DUT, updating the mirror value of the register. The mirror value now reflects the actual content of the register after the write operation.
// UVM RAL Write Sequence
my_register.write(desired_value, .status(status));
Read Sequence:
When a read sequence is executed for a register, the read method in the sequence sets the desired value for that register. This desired value is typically a placeholder, as the actual data from the DUT will be read into the mirror value.
After the read method is executed, the RAL layer initiates the actual read operation from the DUT, updating the mirror value of the register. The mirror value now reflects the actual content of the register after the read operation.
// UVM RAL Read Sequence
my_register.read(.status(status));
Update Timing:
The update of the mirror value after a write or read sequence happens internally within the RAL layer.
Test writers do not need to explicitly update the mirror value in their sequences; it is handled by the infrastructure.
The desired value is updated immediately after a sequence method (e.g., write or read) is executed, reflecting the intended content for the next operation.
The reason for maintaining both desired and mirror values is to enable verification, debugging, and validation. The mirror value is compared against the desired value to ensure that the register transactions behave as expected. Debugging becomes more straightforward with the ability to inspect both values in case of discrepancies.
In summary, the RAL layer automatically manages the update of mirror values after each transaction, whether it’s a write or read operation, providing a structured and systematic approach to register verification in UVM.
rahulvala@gmail.com
Freelancer/verification engineer
https://www.linkedin.com/in/rahulvala/
1 Like