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
I'm reporting this reggen-related issue here because it is not clear to me if it applies to upstream reggen from OpenTitan ([opentitan]/util/reggen/reg_top.sv.tpl) or only X-HEEP's version of the tool.
Scenario 1 (good):
Imagine you create an IP with 1 register (A), a 4-register window (B), and a 16-register window (C).
The address space is as follows:
0x00-0x03: A
0x04-0x0F: (unmapped)
0x10-0x1F: B
0x20-0x3F: (unmapped)
0x40-0x7F: C
Reggen will correctly handle this by implementing steering logic that detects if the requested address from the bus falls inside windows B or C, generating the reg_steer values 0 or 1, and otherwise generating 2, which corresponds to the register interface.
The register interface will then generate a bus error if you try to access an address that doesn't map to any register (if devmode_i is enabled), and ignore the access.
All is good.
Scenario 2 (bad):
Now imagine you don't have any registers.
In this case, the steering logic assigns the value 0 or 1, and if the accessed address doesn't match any window (e.g., a gap between windows), it will default to the last window instead of an additional value that doesn't correspond to any window.
As a result, invalid access requests in this scenario are always sent to the last window instead of being ignored, and an error signal is never generated.
The correct way to handle this, in my opinion, would be to always add an extra interface / reg_steer value, i.e., pretend there are always registers even when there are not, so that at the very least writing to an invalid address won't result in writing to a random window. This "dummy interface" would always respond immediately (ready=1), with error tied to 1 if devmode_i is enabled, so no extra logic is needed for this dummy interface.
For the time being, I suppose the easiest workaround is to always create at least one dummy register. (Or having the module developer ensure that the address is within the range of values of the window instead of just truncating the MSbits, but I think this is reggen's job.)
The text was updated successfully, but these errors were encountered:
Hi @cousteaulecommandant , thanks for reporting it! If I well understood, the best won't be adding a register into the hjson file but rather changing the template to fix this issue, isn't it?
Correct. Adding a register to the hjson file was my suggested workaround for those affected until this issue gets fixed.
The proper fix will probably involve leaving some of the register-related code that is currently being removed (in particular, still create an additional demux interface for "the registers" even if there are none, and always tie it to error=1).
PS: I also noticed some errors in the generated file when there are no registers that prevent it from compiling/simulating (can't remember which), so currently a module without registers doesn't work at all.
I'm reporting this reggen-related issue here because it is not clear to me if it applies to upstream reggen from OpenTitan ([opentitan]/util/reggen/reg_top.sv.tpl) or only X-HEEP's version of the tool.
Scenario 1 (good):
Imagine you create an IP with 1 register (A), a 4-register window (B), and a 16-register window (C).
The address space is as follows:
Reggen will correctly handle this by implementing steering logic that detects if the requested address from the bus falls inside windows B or C, generating the reg_steer values 0 or 1, and otherwise generating 2, which corresponds to the register interface.
The register interface will then generate a bus error if you try to access an address that doesn't map to any register (if devmode_i is enabled), and ignore the access.
All is good.
Scenario 2 (bad):
Now imagine you don't have any registers.
In this case, the steering logic assigns the value 0 or 1, and if the accessed address doesn't match any window (e.g., a gap between windows), it will default to the last window instead of an additional value that doesn't correspond to any window.
As a result, invalid access requests in this scenario are always sent to the last window instead of being ignored, and an error signal is never generated.
The correct way to handle this, in my opinion, would be to always add an extra interface / reg_steer value, i.e., pretend there are always registers even when there are not, so that at the very least writing to an invalid address won't result in writing to a random window. This "dummy interface" would always respond immediately (ready=1), with error tied to 1 if devmode_i is enabled, so no extra logic is needed for this dummy interface.
For the time being, I suppose the easiest workaround is to always create at least one dummy register. (Or having the module developer ensure that the address is within the range of values of the window instead of just truncating the MSbits, but I think this is reggen's job.)
The text was updated successfully, but these errors were encountered: