This fixes a couple of build warnings in litedram-wrapper-l2.vhdl
litedram/extras/litedram-wrapper-l2.vhdl:552:17⚠️ declaration of "i" hides constant "i" [-Whide]
for i in 0 to ROW_SIZE-1 loop
^
litedram/extras/litedram-wrapper-l2.vhdl:1129:9⚠️ declaration of "litedram_trace" hides generic "litedram_trace" [-Whide]
litedram_trace: litedram_trace_stub;
^
It also cleans up the runtime metavalue warnings
Signed-off-by: Michael Neuling <mikey@neuling.org>
We disabled --trace by default, so we need to stop linking verilated_vcd_c.o
as it doesn't exist in that case.
While at it, make a Makefile variable to enable/disable verilator tracing
and add a couple of generics to those test benches to control tracing
in the L2 and in litedram.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
The Antmicro Artix DC-SCM uses the following FTDI part:
0403:6011 Future Technology Devices International, Ltd FT4232H Quad HS USB-UART/FIFO IC
To use:
$ openocd/flash-arty -c antmicro-artix-dc-scm -f a100 -t bin -a 0x300000 ~/u-boot
Signed-off-by: Joel Stanley <joel@jms.id.au>
As with the DRAM configuration, the DC-SCM board uses the same PHY as
the Nexys Video and works with it's generated VHDL.
Signed-off-by: Joel Stanley <joel@jms.id.au>
This uses the exact same gateware as the nexys video, since the DRAM
connection is identical to the nexys video down to the pin assignments
on the FPGA. The only minor difference is that the DRAM chip on the
dc-scm is a MT41K256M16TW vs. a ...HA part on the nexys video.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
[joel: rebase and tweaks]
Signed-off-by: Joel Stanley <joel@jms.id.au>
works with:
fusesoc build --target=antmicro-artix-dc-scm microwatt --ram_init_file=../hello_world/hello_world.hex
Signed-off-by: Michael Neuling <mikey@neuling.org>
[joel: Fixes and updates]
Signed-off-by: Joel Stanley <joel@jms.id.au>
It also stores the dirty status so that's known.
This does some Makefile tricks so that we only rebuild when the git
hash changes. This avoids rebuilding the world every time we run
make.
Also adds fusesoc generator, so that should continue to work as
before.
Signed-off-by: Dan Horák <dan@danny.cz>
Signed-off-by: Michael Neuling <mikey@neuling.org>
Jacob Lifshay found a couple of issues with the PLRU implementation:
- The tree array is one bit too long. This is harmless as this bit is never
accessed and thus should be optimized out
- The PLRU read is using the wrong nodes when going down the tree, which leads
to incorrect results.
This fixes it and improves the test bench a bit. I have verified the expected
output using a hand-written tree states, observed the mismatch with the
current implementation and verified the fix.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
As in dcache, this changes most signals declared with integer type to
be unsigned bit vectors instead. Some code has been rearranged to do
to_integer() or equality comparisons only when the relevant signals
should be well defined. Non-fatal asserts have been sprinkled
throughout to assist with determining the cause of warnings from
library functions (primarily NUMERIC_STD.TO_INTEGER and
NUMERIC_STD."=").
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Among other changes, this makes the things that were previously
declared as signals of integer base type to be unsigned, since
unsigned can carry metavalues, and hence we can get the checking for
metavalues closer to the uses and therefore restrict the checking to
the situations where the signal really ought to be well defined.
We now have a couple more signals that indicate request validity to
help with that.
Non-fatal asserts have been sprinkled throughout to assist with
determining the cause of warnings from library functions (primarily
NUMERIC_STD.TO_INTEGER and NUMERIC_STD."=").
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This adds a "not HAS_FPU" condition in a few places to make it obvious
that logic to interface to the divide unit is not included when we
have an FPU.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Now that we have a 33 bit x 33 bit signed multiplier in execute1,
there is really no need for the 16 bit multiplier. The coremark
results are just as good without it as with it. This removes the
option for the sake of simplicity.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This fixes a bug in the BTC where entries created for a given address
when MSR[IR] = 0 are used when MSR[IR] = 1 and vice-versa. The fix is
to include r.virt_mode (which mirrors MSR[IR]) in the tag portion of
the BTC.
Fixes: 0fb207be60 ("fetch1: Implement a simple branch target cache", 2020-12-19)
Reported-by: Anton Blanchard <anton@linux.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This adds an 'is_signed' signal to MultiplyInputType to indicate
whether the data1 and data2 fields are to be interpreted as signed or
unsigned numbers.
The 'not_result' field is replaced by a 'subtract' field which
provides a more intuitive interface for requesting that the product be
subtracted from the addend rather than added, i.e. subtract = 1 gives
C - A * B, vs. subtract = 0 giving C + A * B. (Previously the users
of the multipliers got the same effect by complementing the addend and
setting not_result = 1.)
The is_32bit field is removed because it is no longer used now that we
have a separate 32-bit multiplier.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This rearranges the way that partial products are generated and summed
so that the partial products that could be negative in a signed
multiplier are now sign-extended. The inputs are still zero-extended,
however.
The overflow detection logic now only detects 64-bit overflow, since
32-bit multiplications are handled in a separate multiplier.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This adds a pipelined 33-bit by 33-bit signed multiplier with one
cycle latency to the execute pipeline, and uses it for the mullw,
mulhw and mulhwu instructions. Because it has one cycle of latency we
can assume that its result is available in the second execute stage
without needing to add busy logic to the second stage.
This adds both a generic version of the multiplier and a
Xilinx-specific version using four DSP slices of the Artix-7.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This adds comments to row_predecode_rom to aid understanding how the
columns in the second half of the table are allocated to different
primary opcodes, and to the insn_code values to assist in locating the
code with a given numeric value. No code change.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This expands the field in the log buffer that stores the instruction
fetched from the icache to 36 bits, so that we get the insn_code and
illegal instruction indication. To do this, we reclaim 3 unused bits
from execute1's portion and one other unused bit (previously just set
to 0 in core.vhdl).
This also alters the trigger behaviour to stop after one quarter of
the log buffer has been filled with samples after the trigger, or 256
entries, whichever is less. This is to ensure that the trigger event
doesn't get overwritten when the log buffer is small.
This updates fmt_log to the new log format. Valid instructions are
printed as a decimal insn_code value followed by the bottom 26 bits of
the instruction. Illegal instructions are printed as "ill" followed
by the full 32 bits of the instruction.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This rearranges the synchronous process here to avoid setting fields
of pred(i) to zero or INSN_illegal when valid_in is '0'.
Experimentally, on ECP5 this acts like an asynchronous reset rather
than a synchronous reset.
Instead, handle possible indeterminate input for simulation by making
the maj_predecode and row_predecode fields of predec_t be unsigned
rather than insn_code (an enumerated type), and setting them to X when
the input word is indeterminate.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This splits out the decoding done in the decode0 step into a separate
predecoder, used when writing instructions into the icache. The
icache now holds 36 bits per instruction rather than 32. For valid
instructions, those 36 bits comprise the bottom 26 bits of the
instruction word, a 9-bit insn_code value (which uniquely identifies
the instruction), and a zero in the MSB. For illegal instructions,
the MSB is one and the full instruction word is in the bottom 32 bits.
Having the full instruction word available for illegal instructions
means that it can be printed in the log when simulating, or in future
could be placed in the HEIR register.
If we don't have an FPU, then the floating-point instructions are
regarded as illegal. In that case, the insn_code values would fit
into 8 bits, which could be used in future to reduce the size of
decode_rom from 512 to 256 entries.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This changes code that previously looked at the primary opcode (bits
26 to 31) of the instruction to use other methods, in places other
than in stage0 of decode1.
* Extend rc_t to have a new value, RCOE, indicating that the
instruction has both Rc and OE bits.
* Decode2 now tells execute1 whether the instruction has a third
operand, used for distinguishing between multiply and multiply-add
instructions.
* The invert_a field of the decode ROM is overloaded for load/store
instructions to indicate cache-inhibited loads and stores.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This lets us compute r_out.reg_*_addr and r_out.read_2_enable values
without needing access to the primary opcode value. We also have that
non-FP instructions are < 256.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This reduces the block RAM requirements for instruction decoding by
splitting it into two steps. The first, in a new pipeline stage
called decode0 (implemented by code in decode1.vhdl) maps the
instruction to a 9-bit instruction code using major and row decode
ROMs. The second maps the 9-bit code to the final decode_rom_t (about
44 bits wide). Branch prediction done in decode is now done in
decode0 rather than decode1.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This combines the various decode arrays in decode1 into two, one
indexed by the major opcode (bits 31--26 of the instruction) together
with bits 4--0 of the instruction, and the other indexed mostly by the
minor opcode (bits 10--1), with some swizzles to accommodate the
relevant parts of the minor opcode space for opcodes 19, 31, 59 and 63
within a 2k entry ROM (11 address bits). These are called the "major"
and the "row" decode ROMs respectively. (Bits 10--6 of the
instruction are called the "row index", and bits 5--1, or 5--0 for
some opcodes, are called the "column index", because of the way the
opcode maps in the ISA are laid out.)
Both ROMs are looked up each cycle and the result from one or other,
or from an override in ri.override_decode, are selected after a clock
edge.
This uses quite a lot of BRAM resources. In future a predecode step
will reduce the BRAM usage substantially.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Instead of doing that in decode1. That lets us get rid of the
force_single and override_unit fields of reg_internal_t in decode1,
which will simplify following changes to decode1.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Anton Blanchard
