There's a register that tracks what word within a Nasti transaction a
Smi response cooresponds to, since Smi itself doesn't have any
multi-word stuff. This breaks the single-word Nasti to Smi converter
due to what's essentially a 0-width wire bug: it ends up doing something
like
word_offset_into_nasti := nasti_address(3, 3)
when "word_offset_into_nasti" should really be a 0-bit register, but due
to some log2Up block size calculation logic it's actually a 1-bit
register. Thus, this expression ends up grabbing a bit of the address,
which causes odd addresses to get buffered incorrectly.
My fix is to just special-case the "Nasti bus width is the same as Smi
bus width" case.
When RocketChip has a single memory configuration I want to ensure no extra
hardware is being generated by only instantiating a NastiMemoryInterconnect
rather than a NastiMemorySelector, which I believe will insert a Mux with 0
when there is only one config (because there aren't any 0-width wires allowed).
On Hurricane we want to be able to support multiple memory channels but have a
fallback to fewer, since the full configuration is going to require a
complicated FPGA setup. This adds another sort of interconnect that can switch
between having different numbers of top-level memory channels active at chip
boot time.
This interconnect is a bit funny: changing the select input when there is
memory traffic is a bad idea. This is fine for this use case, since we really
only care about changing the memory configuration at boot time -- since it'll
scramble the memory of the machine it's not so useful, anyway.
The advantage is that we don't have to have a full 8x8 Nasti crossbar in our
chip, which would be fairly expensive. Changing the crossbar would garble
memory as well, so it's not like it would add any extra functionality.
Without this it's really hard to read the IllegalArgumentException that you get
if you subclass ParamaterizedBundle and don't define a matching cloneType().
Palmer DabbeltandPalmer Dabbelt