Order interrupt connections based on hart #2003
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related issue: riscv-boom/riscv-boom#278
Type of change: bug report
Impact: no functional change
Development Phase: implementation
Release Notes
When the first tile elaborated is not given
hartId == 0
then interrupts will be misnumbered in the CLINT/PLIC causing interrupts to go to the wrong tile and thus breaking the default bringup. This is not an issue when using theWithNSmallCores
mixin because theRocketTilesKey
is filled with tiles starting fromhartId == 0, 1, 2...
. However, if you end up assigning arbitraryhartId
s to tiles then this breaks since the elaborated tilehartId
may not match how the interrupts are connected (which expectshartId == 0
to be connected first, thenhartId == 1
, etc).An example of how this breaks is if the
hartId
ordering is swapped to start fromN-1
to0
. Another example of this issue showing up is when using something like https://github.com/riscv-boom/riscv-boom/blob/a8ca568f68d28ff34bc90ffecd3b5101b3c8d53f/src/main/scala/system/ConfigMixins.scala#L82-L90 to renumber thehartId
s.