Hello Verification Academy,
From your own experience, which kinds of RTL registers tests should I implement and run to completely verifying the registers functionality?
Few of the registers tests I have:
- Read default value of register after reset.
- Sequence of write some value and read from same register and see value is the same.
- WR with backdoor access, and read with front-door access.
Would appreciate if you can also provide the reasons you have added other kinds of registers tests? What should it test and why?
Thanks
In reply to Michael54:
My recommendation is:
(1) Checking the reset value will be very important. If this went wrong your design might not really configurable.
(2) Writing registers in random order with feasible values, read back the registers in a different order
(3) Check the access rights; writing RO registers using backdoor access and vice-versa.
(4) running pre-defined register sequences
Thank you very much Chris,
to what did you mean in “pre-defined register sequences”?
In reply to Michael54:
Hello, another one would be try to write some writable once register and check if those cannot be written again after and they are instead after issuing a reset.
Another tricky scenario is for accumulated registers (values ored) check if they accumulate.
Lastly, this is a corner case only, perform back to back access to see if target registers are reached each time. Back to back could be implemented as RWR, RRW, WWR and so on you can randomize the sequence order and run it with a reasonable number of time until all are covered. Regards
In reply to Michael54:
These are test sequences the UVM library is providing.
If you hace specific registers or special access there might be mor scenarios.
Thank you Rsignori92 and chr_sue!
What about accessing undefined addresses in the address space?
Of course we won’t have a register defined for this in the RAL… Should we test it as well. How can we issue a RD/WR to such address?
In reply to Michael54:
For holes, meaning register missing at that specific address you cannot use read write tasks from register model since you are strictly relying on mapped registers. On that cade i would recommend using custom sequences (not part of uvm reg standard) along with protocol specific sequences (such as apb wr rd cmd, ahb wr rd cmd and so on)
In reply to Michael54:
Thank you Rsignori92 and chr_sue!
What about accessing undefined addresses in the address space?
Of course we won’t have a register defined for this in the RAL… Should we test it as well. How can we issue a RD/WR to such address?
In the adapter you can do things like this
virtual function void bus2reg( uvm_sequence_item bus_item,
ref uvm_reg_bus_op rw);
my_transaction tr;
ok = $cast(tr, bus_item);
assert (ok) else `uvm_fatal("ADAPTER", "Not a legal transaction!")
if (tr.addr >= LEGAL_ADDR_REGION) begin
rw.kind = (tr.kind == my_transaction::BUS_READ) ? UVM_READ : UVM_WRITE;
.....
endfunction
In reply to chr_sue:
But usually the bus2reg and reg2bus will be called once the reg write or reg read are called
In reply to Rsignori92:
Correct. This is what should happen. If you have only 1 address illegal between legal addresses it will be detected.
In reply to chr_sue:
Hello,
How to verify RO type registers using RAL ?By hacking the code to allow the write happen in RO is good way ?
In reply to dddvlsique:
RO registers is a very common access type. You do not need to hack anything. Using backdoor access you can write any register without WR access. A common scenario for checking the access rights is to write registers through backdoor and reading frontdoor. If you have a WO register you have to go vica-versa.
In reply to chr_sue:
This means that is gonna work only in case of 1 word hole, instead sometimes you could have pages or even randomly distributed holes (more than 1 word in between) and this approach will not detect all of them, in this case I recommend using:
uvm_reg regs[$];
uvm_default_map.get_registers(regs);
// we loop through all the possible addresses in an address space
for(uvm_reg_addr_t at == BASE_ADDR; at <= END_ADDR; at+=INCREMENT) begin
// we could use uvm_default_map.get_reg_by_offset(at);
// alternatively we can leverage the map regs got before using a custom find register
if(findreg(at) == null)
// This is a hole
// ....
// then we issue the TRX using protocol sequences
end
sometimes in the bulk/json/rdl (whatever is used to describe the registers in IP) new registers are added at the bottom to avoid FW changing heavily. Having said that this will work assuming the RTL register wrapper logic doesn’t give you back an error in case of HOLE rd/wr/ if so an error would be checked in the code.
In reply to dddvlsique:
For RO registers again you could follows these steps but then it will be gain protocol based:
- Backdoor read the RO reg using backdoor or user defined backdoor as suggested by chr_sue
- Issue a write using protocol based sequences (if an error is expected because enabled in the RTL logic then check the error)
- Backdoor read the RO reg using backdoor or user defined backdoor as suggested by chr_sue
RO registers have their default values specified in the register descriptors so you can easily check it out. Regards
In reply to Rsignori92:
In reply to dddvlsique:
For RO registers again you could follows these steps but then it will be gain protocol based:
- Backdoor read the RO reg using backdoor or user defined backdoor as suggested by chr_sue
- Issue a write using protocol based sequences (if an error is expected because enabled in the RTL logic then check the error)
- Backdoor read the RO reg using backdoor or user defined backdoor as suggested by chr_sue
RO registers have their default values specified in the register descriptors so you can easily check it out. Regards
As suggested by Ch_sue above to verify RO ,write through backdoor and read through frontdoor
As suggested by you read through backdoor ,Its not cleared to me which is right
I have one more question let’s say DUT having bug writing data on Address A1 register ,while reading from Address A1 is not getting same data ,but while reading other address A3 at same time we able to read same data which we write on Address A1 register
So to verify this issue is it required to write on A1 and followed by read of all address to catch this issue ?
In reply to dddvlsique:
RO reg means you cannot write this reg using standard frontdoor access that means you should test that the write doesn’t go through or eventually returns an error response. Hence I suggested to read bkdoor and write frontdoor. The usage of bkdoor helps you to speed up sim since you do not wait for protocol cycles while reading
In reply to dddvlsique:
I had edited my answer because i misinterpreted the scenario sorry for that.
Let’s say so you have an issue with this reg A1, so you write data in A1 using reg write, but the data is lost or doesn’t go there due to a bug. But reading such address A3 you will find some data supposed to be written in A1. In this case what suggested by chr_sue will work perfectly since the order of the operation matters.
- You get all the regs from the map
- You shuffle them
- You do read after write on each reg
This test requires to be repeated few times to change access order. Regards
In reply to dddvlsique:
I have one more question let’s say DUT having bug writing data on Address A1 register ,while reading from Address A1 is not getting same data ,but while reading other address A3 at same time we able to read same data which we write on Address A1 register
So to verify this issue is it required to write on A1 and followed by read of all address to catch this issue ?
This requires to access all registers, writing first and reading back in different order.
But it is up to you tp identify this issue, because the sequence is not identifying such an error.