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.
If you have multi-target rules that don't have %s in them, make
interprets that as "run this recipe multiple times, once to produce each
target". If you have %s in the rules, then make interprets it as "run
this recipe once to produce all targets". We want the second one.
Chisel 3 can't build the C++ emulator, so we currently can't have direct
support for testing RocketChip. We can at least test to see if the
Verilog builds when run through Chisel 3, which this patch does.
This allows users to specify if they want to build RocketChip against
Chisel 2 or 3. Since Chisel 3 is now open source we can add these
submodule pointers directly to avoid a fork of upstream.
This uses an reorder queue but doesn't check to ensure that the data it fetches
from the queue is actually in the queue before using it. It seems that during
correct operation this never breaks, but I'm trying to get the backup memory
port working again and this assertion fails with it enabled (without the
assertion the core just gets a bogus data beat dies).
Closes#16
It turns out the Chisel C++ backend can't emit correct initialization
code for a 128 bit wide NastiROM. Rather than trying to fix Chisel, I'm
just going to hack up the backup memory port Verilog harness a bit more
to make it work.
Note that the backup memory port Verilog already couldn't take arbitrary
parameters for MIF_*, so it's not like we're losing any flexibility
here.
The backup memory port doesn't work on multi-channel configurations, it
just screws up the Nasti tag bits. This patch always instantiates a
single-channel backup memory port, which relies on the memory channel
selector to only enable a single memory channel when the backup memory
port is enabled. There are some assertions to make sure this happens,
as otherwise memory gets silently corrupted.
While this is a bit of a hack, the backup memory port will be going away
soon so I don't want to spend a whole lot of time fixing it. The
generated hardware is actually very similar: we used to elaborate a
Nasti arbiter inside the backup memory support, now there's one outside
of it instead.
We need this to work for our chip, and it's not been tested in a long
time in upstream -- it didn't even used to build since the Nasti
conversion. This makes a few changes:
* Rather than calling the backup memory port parameters MEM_*, it calls
them MIF_* (to match the MIT* paramater objects). A new name was
necessary because the Nasti stuff is now dumped as MEM_*, which has
similar names but incompatible values.
* p(MIFDataBits) was changed back to 128, as otherwise the backup
memory port doesn't work (it only send half a TileLink transaction).
64 also causes readmemh to bail out, but changing the elf2hex parameters
works around that.
* A configuration was added that enabled the backup memory port in the
tester. While this is kind of an awkward way to do it, I want to
make sure I can start testing this regularly and this makes it easy to
integrate.
This was recently changed to write out physical addresses for SCR file entries,
but to bring up the chip we need SCR offsets so we can write the uncore SCR
file over HTIF. This changes the map generator to generate both.
Without this change things happened to work anyway because the high bits were
getting dropped by the SCR file.
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().
It looks like Chisel fails when I try to run it in parallel. This adds a lock
file to ensure that only a single Chisel instance is running at a time when
running the regressions.
make changed its priorties for resolving implicit rules, which causes different
behavior when running "make run-bmark-tests". This patch changes the hex file
rules to ensure they match between the two versions of make.
I've tried this with both make-3.81 and make-4.1, and they both work for me.
In order to have the buildbot support various types of failures it needs
to run different commands. Rather than modifying the regression script
to have a bunch of arguments I've just gone and made a makefile for
regressions instead.
This doesn't run torture right now because that's broken, but I'll add
support soon.
I want to be able to test the master of riscv-gnu-toolchain against the current
RTL as part of the buildbot. This flag takes a list of repositories (by their
submodule path) and updates those to the current master, which facilitates that
check.
This causes every command to be echo'd to stderr, and any failing
command will fail the whole script. Without this the regression
script will always pass.
It seems that the update process in the README is really out of date
(it refers to scala-2.8 and chisel-1.1). I've updated it to what I
believe to be correct, which now just consists of pulling the Chisel
submodule.
Note that I tried this myself, but when I did it I also ran an "sbt
package" in the Chisel submodule top-level directory (there's no "sbt"
directory in there any more). I believe it's not necessary to run
"sbt package", but I really know nothing about SBT...
I made a clean checkout of reference-chip yesterday and wasn't able to
build the debug emulator without first having built the non-debug
emulator. I just added a note to the README to say this.
Palmer DabbeltandPalmer Dabbelt
