You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For example, a block has a mix of 1B and 2B registers, all specifying a "minimum access width" of one byte, the current code infers an 8b-bit data width. But this seems to contradict the first statement above, that the data with will be of the largest register in the design: 16 bits. The larger size allows "atomic" access to larger registers.
In this example, if the RDL is changed to specify "accesswidth=16" for the larger registers, other limitations come into play:
lose sub-register access capability
tool limitation on alignment of smaller registers
The first quote about should be clarified with current behavior, if intentional. But beyond that, I'm trying to understand whether this is a SystemRDL semantics problem, or a tool mistake, or a tool limitation, etc.
The text was updated successfully, but these errors were encountered:
Depending on intent, the other option I can think of is to provide a "user data width" property to specify a minimum data width for the cpuif. That bypasses extracting it from SystemRDL semantics, if that's not otherwise clear at this time.
https://peakrdl-regblock.readthedocs.io/en/latest/cpuif/internal_protocol.html#read-response
But the code looks at largest minimum access width:
https://github.com/SystemRDL/PeakRDL-regblock/blob/main/src/peakrdl_regblock/scan_design.py#L93
For example, a block has a mix of 1B and 2B registers, all specifying a "minimum access width" of one byte, the current code infers an 8b-bit data width. But this seems to contradict the first statement above, that the data with will be of the largest register in the design: 16 bits. The larger size allows "atomic" access to larger registers.
In this example, if the RDL is changed to specify "accesswidth=16" for the larger registers, other limitations come into play:
The first quote about should be clarified with current behavior, if intentional. But beyond that, I'm trying to understand whether this is a SystemRDL semantics problem, or a tool mistake, or a tool limitation, etc.
The text was updated successfully, but these errors were encountered: