We used to just be writing the SCR anyway, but now that the SCR maps are
automatically defined VCS will detect the missing SCR and bail out when
compiling test harness code. This patch just doesn't write the HTIF SCR when
there isn't one.
We're building a chip with 8 memory channels. Since this will require a
complicated test setup we want to also be able to bring up the chip with fewer
memory channels. This commit adds a SCR that controls the number of active
memory channels on a chip. Toggling this SCR will scramble memory and drop
Nasti messages, so it's only possible to change while the chip is booting.
By default this just adds a 1-bit SCR, which essentially no extra logic.
When multiple memory channel configurations are enabled at elaboration time, a
NastiMemoryInterconnect is generated for each channel configuration. The
number of outstanding misses is increased to coorespond to the maximum number
of banks per memory channel (added as a parameter), which I believe is
necessary to avoid deadlock in the memory system.
A configuration is added that supports 8 memory channels but has only 1 enabled
by default.
This uses the new SCRFile changes to generate a header file containing a list
of all the SCRs in a core to remove the magic constant "63" (the HTIF clock
divider control register) and replace it with a generated number (which is
still 63).
Right now there's no way to ensure that SCR addresses don't conflict within
RocketChip. Since upstream only has one of them this isn't a big deal, but we
want to add a whole bunch more to control all the IP on Hurricane.
This patch adds some Scala code to allocate registers inside the SCR file,
ensure they don't conflict, to provide names for SCRs, attach registers to the
SCR file, and generate a C header file that contains the addresses of every SCR
on a chip.
With this patch we'll be able to get rid of that constant in the testbench.
This also allows us to kill one of the Raven diffs, which is does pretty much
the same thing (just in a second SCR file, and hacked in).
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().
