Thought I would do another drop of reg API features and also so that I have something to generate reg transactions for the patgen branch.
Some of the highlights:
Reg addressing is working, supporting resolution of a global address from all base addresses defined by the register's parent hierarchy
Added description parsing
Register dirty status and snapshots as described in #77
Transaction API as decribed in #32
Some low level hooks added to support creation of a dirty regs collection in future
Improved the regs collection returned by my_model.regs
Many more O1 register tests now implemented/passing
API changes:
Changed terminology to be write/verify register instead of write/read register based on some of the earlier discussions stating that this was clearer.
Write and verify have been changed to be external functions rather than register methods, for example, in O1 you would do this:
my_reg.write()
In O2 you do this:
from origen.registers.actions import *
# The argument here is any bit collection object
write(my_reg)
verify(dut.my_reg.my_bits)
# You can combine data setting into a single line, here to verify 5 in my_bits and
# don't care the others:
verify(dut.my_reg.my_bits.set_data(5))
This is also consitent with how transactions work e.g.:
with verify_transaction(dut.my_reg) as reg:
reg.my_field1.set_data(1)
reg.my_field2.set_data(2)
This O2 approach really helps with the implementation of the verify/write_register() handler lookup which is a purely application/Python concern, while all register methods are implemented in Rust.
It also feels fairly Pythonic and while the O1/method call approach is arguably nicer, I don't think the O2 API will feel out of place to anyone who is used to Python.
Thought I would do another drop of reg API features and also so that I have something to generate reg transactions for the patgen branch.
Some of the highlights:
my_model.regsAPI changes:
Changed terminology to be write/verify register instead of write/read register based on some of the earlier discussions stating that this was clearer.
Write and verify have been changed to be external functions rather than register methods, for example, in O1 you would do this:
In O2 you do this:
This is also consitent with how transactions work e.g.:
This O2 approach really helps with the implementation of the verify/write_register() handler lookup which is a purely application/Python concern, while all register methods are implemented in Rust.
It also feels fairly Pythonic and while the O1/method call approach is arguably nicer, I don't think the O2 API will feel out of place to anyone who is used to Python.