A seemingly simple question that comes up every now and then is "How do I properly handle reserved fields in UVM RAL?". The answer seems straightforward, right? You just don't model them. This is what the UVM guys tell you. While this does work in most cases, sometimes things aren't so simple. This may have been the intention of how it's supposed to work, but this is not what made it into the BCL implementation.
The volatile flag is meant to indicate that the field can be changed internally by the device (like when it has a status bit). Setting it to volatile turns off the checking because determining the “correct” value would be problematic by the register model. So even though setting the volatile bit gets you what you want, it may misdirect the casual reader into thinking that the value could or should change by itself. Typically reserved fields are modeled as “RO”, with a reset value of 0. Would it be more clear and self-documenting to model your special reserved field as a simple “RW” since that more closely matches the actual behavior of the register?
You do raise an interesting point, one I didn’t think about. A number of variations are possible here, but it also depends on the field’s behavior. It might be the case that the reserved bit is a status field and in that case you do need it to be volatile.
What would be nice is to have a one size fits all solution. Maybe the best thing here is to explicitly set it to UVM_NO_CHECK with an extra call to set_check(…), which might make the intent clearer, or?
The reason I say a one size solution would be nice is because register models are typically generated out of the specification by some script/tool and it would make the tool more complicated if it had to juggle variations on how to handle some reserved bits differently from others. This is basically why I would have liked it if non-modeled locations in a register are by default treated as “don’t care” and I hope this will make it into the BCL implementation eventually.
Typically locations that aren’t implemented should always return 0’s - as if they are reserved. I think the default sequences may be doing the right thing by checking for it.
You do have an interesting case that doesn’t quite fit inside the box - a reserved field that is writable. I wonder if a more appropriate name for it would be a “temp” field. But regardless, you could make a case that you found a “bug” in the RTL, that is, the designer specified that the field is reserved, but it doesn’t act like one. This could cause confusion by the end users of your device. I would push back on the designer and ask him to “fix” it or change the documentation.
I found a statement in the UVM user guide: “Reserved fields should be left unmodelled [sic] (where they will be
assumed to be RO fields filled with 0’s), modelled [sic] using an access policy that corresponds to their actual
hardware behavior or not be compared using uvm_reg_field::set_compare(0).”. I guess I kind of put my foot in my mouth with this post. Regardless, the Mantis item still exists and is marked as urgent, so there doesn’t seem to be any consensus within Accellera as to how this is supposed to work.
Hi Tudur ,
can u plz make a blog on frontdoor and backdoor access in uvm ral model with a clear example ?
Plz use the functions like set_backdoor() and get_backdoor()
am I wrong or this is still true as of today in 2023 and in UVM 1.2 still?
I have a register that gets bit fields between 3 and 0 and between 8 and 5 and some other locations too
and UVM reports a mismatch on a position that would be the bit 4 indeed…