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
Use chisel3.util.experimental.BitSet.fromRange and chisel3.util.experimental.decode.bitset to replace freechips.rocketchip.diplomacy.AddressDecoder
Type of issue: feature request
Impact: no functional change
Development Phase: proposal
What is the current behavior?
Years(literally) ago, I reviewed AddressDecoder in RC. It uses a heuristic algorithm to solve the address space, I think it might be less efficient than espresso.
Chisel adds these two APIs, chisel3.util.experimental.BitSet.fromRange and chisel3.util.experimental.decode.bitset in chipsalliance/chisel#2449 and chipsalliance/chisel#2211, which can use logic minimizer for routing logics.
However there are two tricky things:
For AddressDecoder, since the routing circuit(crossbar, ring, mesh) are routing a continues range, a better circuit should be "adder"-based logic, the generated circuit is "XOR"-based logic. However neither chisel3.util.experimental.decode.bitset nor freechips.rocketchip.diplomacy.AddressDecoder provides such functionality, which means the output circuit is somehow sub-optimal(in misaligned address, this impact is huge) But essentially we should fix this in Chisel.
RC AddressSet can be unknown width, as you can see from val Everything = AddressSet(0, -1) API, while chisel BitSet doesn't support.
This means: there should be a compatibility layer specifically designed for unknown width to bridge the RC and chisel3.
What is the use case for changing the behavior?
Improve the performance of freechips.rocketchip.diplomacy.AddressDecoder, dedup logic between RC and Chisel.
The text was updated successfully, but these errors were encountered:
Use
chisel3.util.experimental.BitSet.fromRange
andchisel3.util.experimental.decode.bitset
to replacefreechips.rocketchip.diplomacy.AddressDecoder
Type of issue: feature request
Impact: no functional change
Development Phase: proposal
What is the current behavior?
Years(literally) ago, I reviewed
AddressDecoder
in RC. It uses a heuristic algorithm to solve the address space, I think it might be less efficient than espresso.Chisel adds these two APIs,
chisel3.util.experimental.BitSet.fromRange
andchisel3.util.experimental.decode.bitset
in chipsalliance/chisel#2449 and chipsalliance/chisel#2211, which can use logic minimizer for routing logics.However there are two tricky things:
For AddressDecoder, since the routing circuit(crossbar, ring, mesh) are routing a continues range, a better circuit should be "adder"-based logic, the generated circuit is "XOR"-based logic. However neither
chisel3.util.experimental.decode.bitset
norfreechips.rocketchip.diplomacy.AddressDecoder
provides such functionality, which means the output circuit is somehow sub-optimal(in misaligned address, this impact is huge) But essentially we should fix this in Chisel.See std: add AddressSet from rocket-chip chisel#2434 (comment)
This means: there should be a compatibility layer specifically designed for unknown width to bridge the RC and chisel3.
What is the use case for changing the behavior?
Improve the performance of
freechips.rocketchip.diplomacy.AddressDecoder
, dedup logic between RC and Chisel.The text was updated successfully, but these errors were encountered: