Hi All,
I have a few questions regarding the UVM RAL methods
(I) uvm_reg_map::create_map
(1) Cookbook mentions
The byte_addressing argument affects how the address is incremented in these consecutive accesses.
For example, if n_bytes=4 and byte_addressing=0, then an access to a register that is 64-bits wide
and at offset 0 will result in two bus accesses at addresses 0 and 1.
With byte_addressing=1, that same access will result in two bus accesses at addresses 0 and 4.
I am not clear on how the address is incremented in these consecutive accesses
Does the consecutive access need to be for the same register ( with width greater than interface width ) or does the consecutive access even cover scenarios where we access 2 registers one after another ( where both register’s width is equal to interface width )
Assume that n_bytes=4 and all registers have a width of 32-bits and reg_a ( ‘offset’ is 0 ) is accessed first followed by reg_b ::
(Q1) If byte_addressing=0 will the access to reg_a and reg_b result in bus access at address 0 and 1 respectively ?
(Q2) If byte_addressing=1 will the access to reg_a and reg_b result in bus access at address 0 and 4 respectively ?
(Q3) Is there a relation between argument ‘byte_addressing’ of function ‘create_map’ and argument ‘offset’ of function ‘add_reg’ ?
(2) LRM 1800.2 section 18.1.2.3 :: create_map
d) byte_addressing—specifies whether consecutive addresses are 1 byte apart (TRUE; the default) or n_bytes apart (FALSE)."
(Q4) Shouldn’t it be the opposite i.e ::
byte_addressing—specifies whether consecutive addresses are 1 byte apart (FALSE) or n_bytes apart(TRUE; the default)
(II) uvm_reg_map::add_reg
3rd argument to the function is :: string rights = “RW”
The rights specify the register’s accessibility via this map. Valid values are “RW”, “RO”, and “WO”
(Q5) Consider a case where a register consists of mixed access fields i.e some fields are “RW” , some are “RO” while others are “WO”.
These are passed to configure function within the build() function of the respective register.
When the register is added to the register map via add_reg , what should be the actual argument to rights ?
(III) uvm_reg::poke
Assume that a register has “RO” fields as well as “RW” access. On doing a poke to such a register would the “RO” fields be unchanged ?
(Q6) Does the backdoor write via poke consider the access policy of the register fields when performing poke operation ?
(IV) uvm_reg::peek
Assume that a register has “WO” fields as well as “RO” access. On doing a peek to such a register what would the value read for “WO” fields ?
(Q7) Similarly does the backdoor read via peek consider the access policy of the register fields when performing peek operation ?