Hi verification experts,
Please, assume we have a register A which cannot be predicted from outside but from an internal complex state. That is to say the register is volatile.
Now, i would like to check that the register value that is inside of the RTL is able to come out correctly by reading that register using the frontdoor.
I do not know if the UVM backdoor functions will solve this in a better way (not used yet), but what i have done is to spy directly the internal RTL register value using bind.
Then, at the scoreboard on each (@changeofregister_A) RTL change of the register A, i will execute a direct predict to update the register value in the register model in zero time.
Assume the rate of update of this internal RTL register is high, almost on each clock. On the other side, the front door access is slower and requires many clocks.
The problem i have is that when a frontdoor READ is performed on the register A, the busy flag of that register goes on. Because of the busy flag on a READ, UVM cannot perform the direct prediction and therefore there is always a mismatch.
If a wait until the read access finish and the busy goes down to do the prediction/(update of m_mirrored), then it is already too late because the frontdoor read value is taken in the last cycle of the frontdoor access.
My question is, is there any standard good way to do this?
My solution was to avoid the busy blocking mechanism in UVM by creating a quirky/custom register that stores the information in a custom register variable and ignore the “m_mirrored” UVM value. Instead of using “get_mirrored_value” i use my custom “get_my_custom_mirrored_value” and i write/update also on that custom variable.
Any other solutions?
Thanks
In reply to Jonathan_Alvarez:
The whole ‘busy’ mechanism is busted. The register model is poorly architected in this respect, because for some reason the developers decided to mix prediction with stimulus creation (accessing the registers).
Instead of rolling your own quirky register, you can just call ‘Xset_busyX(0)’ on the field before predicting it. It’s a “hidden” function, in that it’s not part of the standard, but it’s a more pragmatic approach.
In reply to Tudor Timi:
Nice solution i did not know and thought about forcing the internal ‘Xset_busyX(0)’. Thanks!
In reply to Jonathan_Alvarez:
To expand a little bit more about the busy flag not related to the original question.
It seems that the busy flag is set to 1 as soon as the sequencer receives the request from the stimuli sequence and switched down when the driver flags the end of the transaction response (need response). If the sequencer has a queue of request to be processed that were issued in parallel using fork, then the register will have several requests waiting for the busy to be free. e.g. AXI can perform a READ and a WRITE access in parallel to the same register. Or two different protocols/maps can access the same register update at the same time.
Is there any way to know which map (or register_item) is waiting to be served? probably there is a queue somewhere in the sequencer
For example, if AHB and APB collide writing the frontdoor at the same time (they start and they end a the same time) and the designer says that AHB has always preference in case they receive the response at the same time (its value wins and stay in the register), then how can you control which value remains in the register model, that the update that will remain will be the one of AHB?. How can you program that in a quirky register?
In other words, how can you control the order of the busy registers pending executions?.
is there any way to know how many and which reg item requests are being blocked at the same time by the busy flag in one register?
Maybe it is better to tell designer that the response of different protocols should not come at the same clock cycle because the end value cannot be known.