I put in place an IP Verification Environment using the OVM methodology. I’m also using the uvm_reg to describe, access and verify my registers.
Everything was working perfectly until they had ghost registers inside the IP.
A ghost register is used for debug. Behavior of such a register is to keep the value while reading a clear-on-read register.
For instance you have a status register that is automatically cleared when you read it but you don’t want this clear to append when you read it from a debugger.
Our hardware solution is to decode all registers addresses only using ADDR_WIDTH - 1 bits for “standard registers” or using all ADDR_WIDTH bits for ghost registers.
Doing this we do not duplicate all registers but only the needed ones.
Do the uvm_reg package allows to easily take this into account?
Does someone succeed in modeling such a behavior using the uvm_reg?
Any ideas?
You have an example of what is referred to as a ‘Quirky’ register, which may need to be modeled in a special way.
From what you say, the debug access uses an extra address bit compared with the normal access, does that mean that if you do a bus access using the extra bit then you get the ghost register content? If so, then you can probably implement the ghost register part of the model by using field bits that are not cleared on read and mapping the ghost registers at their ghost address location. The ghost address mapping would most likely need a separate address map (uvm_reg_map) so that you can take the address interval into account.
If that doesn’t work, then you’d have to create a quirky register that has the ghost fields implemented in addition to the normal fields. You would have to modify the prediction method for the register to update the ghost fields as well as the normal fields whenever you do a read.