- Add a major and minor alert output which can be used by the system to
react to fault injection attacks
Signed-off-by: Tom Roberts <tomroberts@lowrisc.org>
* Mention the need to install `libelf-dev`. Thanks to Bert Pieters for
reporting this.
* Guide users to install our Python dependencies, including fusesoc and
edalize, from `python-requirements.txt`, to ensure they have the
right version.
* Prefer ELF files for Verilator simulations. This makes it easier to
use existing ELF files from another software build system.
Fixes#1019
Use Xilinx-specific implementations for primitives, such as RAM and the
clock gate (which will now be implemented using a BUFGCE macro, and no
longer with a latch).
Verified in Vivado synthesis to pick up the Xilinx primitive now.
- The "PINCONNECTEMPTY" waiver is part of our normal waiver file, no need
to add it to the tool invocation.
- Recent versions of Verilator choose good defaults for MAKE_OPTS,
passing it explicitly overrides the settings.
- All Verilator code is now lint clean, we can remove `-Wno-fatal`.
- FST traces are not much slower then VCD traces any more in recent
Verilator versions, remove the respective comment.
- Align comment about the compile/sim time for tracing with other files
and OpenTitan.
This commit contains some final optimizations regarding the bit
manipulation extension as well as the parametrization into a balanced
version and a full performance version.
Balanced Version:
* Supports ZBB, ZBS, ZBF and ZBT extensions
* Dual cycle instructions:
ror[i], rol, cmov, cmix fsl, fsr[i]
* Everything else completes in a single cycle.
Full Version:
* Supports all 32b sub extensions.
* Dual cycle instructions:
ror[i], rol, cmov, cmix fsl, fsr[i], crc32[c], bext, bdep
* Everything else completes in a single cycle.
Notable Changes:
* bext/bdep are now multi-cycle: Sharing additional register
with multiplier module
* grev/gorc instructions are implemented in separate structures
rather than sharing the shifter or butterfly network.
* Speed up decision on using rs1 or rs3 for alu_operand_a by
introducing single-bit register, to identify ternary
instructions in their first cycle.
* Introduce enumerated parameter to chose bit manipulation
implementation
Signed-off-by: ganoam <gnoam@live.com>
Instead of using copies of primitives from OpenTitan, vendor the files
in directly from OpenTitan, and use them.
Benefits:
- Less potential for diverging code between OpenTitan and Ibex, causing
problems when importing Ibex into OT.
- Use of the abstract primitives instead of the generic ones. The
abstract primitives are replaced during synthesis time with
target-dependent implementations. For simulation, nothing changes. For
synthesis for a given target technology (e.g. a specific ASIC or FPGA
technology), the primitives system can be instructed to choose
optimized versions (if available).
This is most relevant for the icache, which hard-coded the generic
SRAM primitive before. This primitive is always implemented as
registers. By using the abstract primitive (prim_ram_1p) instead, the
RAMs can be replaced with memory-compiler-generated ones if necessary.
There are no real draw-backs, but a couple points to be aware of:
- Our ram_1p and ram_2p implementations are kept as wrapper around the
primitives, since their interface deviates slightly from the one in
prim_ram*. This also includes a rather unfortunate naming confusion
around rvalid, which means "read data valid" in the OpenTitan advanced
RAM primitives (prim_ram_1p_adv for example), but means "ack" in
PULP-derived IP and in our bus implementation.
- The core_ibex UVM DV doesn't use FuseSoC to generate its file list,
but uses a hard-coded list in `ibex_files.f` instead. Since the
dynamic primitives system requires the use of FuseSoC we need to
provide a stop-gap until this file is removed. Issue #893 tracks
progress on that.
- Dynamic primitives depend no a not-yet-merged feature of FuseSoC
(https://github.com/olofk/fusesoc/pull/391). We depend on the same
functionality in OpenTitan and have instructed users to use a patched
branch of FuseSoC for a long time through `python-requirements.txt`,
so no action is needed for users which are either successfully
interacting with the OpenTitan source code, or have followed our
instructions. All other users will see a reasonably descriptive error
message during a FuseSoC run.
- This commit is massive, but there are no good ways to split it into
bisectable, yet small, chunks. I'm sorry. Reviewers can safely ignore
all code in `vendor/lowrisc_ip`, it's an import from OpenTitan.
- The check_tool_requirements tooling isn't easily vendor-able from
OpenTitan at the moment. I've filed
https://github.com/lowRISC/opentitan/issues/2309 to get that sorted.
- The LFSR primitive doesn't have a own core file, forcing us to include
the catch-all `lowrisc:prim:all` core. I've filed
https://github.com/lowRISC/opentitan/issues/2310 to get that sorted.
DPI access is suggested and more generic than Verilator direct signal
access. This changes the access to the performance counters from the
Verilator testbench to use DPI instead of directly accessing the
array.
Signed-off-by: Stefan Wallentowitz <stefan.wallentowitz@hm.edu>
To allow other modules to reference the simple system, it must provide
default files. In particular this is useful in DV settings where bind
is used.
Signed-off-by: Stefan Wallentowitz <stefan.wallentowitz@hm.edu>
Change default to 4 rather than 0. Makes no difference when PMPEnable==0
and gets rid of lint failures due to 0 array referencing (0 is an
unsupported value for this parameter).
Signed-off-by: Tom Roberts <tomroberts@lowrisc.org>
As discussed in issue #845, this tells VCS to wait for signals to
settle in combinatorial blocks before checking uniqueness in
constructs like unique case.
Otherwise things like this can cause spurious warnings:
always_comb b = ~in;
always_comb c = in;
always_comb begin
unique case (1'b1)
b: x = 1;
c: x = 0;
default: x = 0; // not that it matters, but this won't happen
endcase
end
For example, on a falling edge of the in signal, if the processes are
executed in the order 1, 3, 2 then the unique case block will appear
to see both b and c true at the same time.
Fusesoc has an unfortunate bug[1] where a boolean parameter which has
default true can't be disabled. For now, just make all our boolean
parameters back into integers again. In the future, when that's fixed,
maybe we should switch things back.
[1] https://github.com/olofk/fusesoc/issues/392
- Add parameters and actual instantiation of icache
- Add a custom CSR in the M-mode custom RW range to enable the cache
- Wire up the cache invalidation signal to trigger on fence.i
Signed-off-by: Tom Roberts <tomroberts@lowrisc.org>
The third pipeline stage is a new writeback stage. Ibex can now be
configured as the original two stage design or the new three stage
design using the `WritebackStage` parameter in ibex_core. This defaults
to 0 (giving the original two stage design).
The three stage design is *EXPERIMENTAL*
In the three stage design all register write back occurs in the third,
final stage. This allows a cycle for responses to loads and stores so
when the memory system can respond in a single cycle there will be no
stall. This offers significant performance benefits.
Documentation of the three stage design is still to be written so
existing documentation applies to the two stage design only as various
aspects of Ibex behaviour will change in the three stage design.
Signed-off-by: Greg Chadwick <gac@lowrisc.org>
The main point of this is that it's somewhere we can store what it
calls "ss_opts": the options that we must pass to Spike to tell it the
memory layout of the simple_system environment.
While we're at it, I've tried to make this reasonably pleasant to use.
So you can do
spike-simple-system.sh <elf-file>
just to run the thing. To pass stuff to Spike without the
bash script getting in the way, use '--':
spike-simple-system.sh -- my option -h --here <elf-file>
If you just build simple_system a fusesoc line like
fusesoc --cores-root=. run --target=sim --setup \
--build lowrisc:ibex:ibex_simple_system
then the change to ibex_simple_system.sv suffices, but if you
explicitly set a parameter in fusesoc like this:
fusesoc --cores-root=. run --target=sim --setup \
--build lowrisc:ibex:ibex_simple_system \
--RV32M=1
then it overrides the default parameter with a literal 1. We declare
the parameter as an 'int', so I guess that's quite a reasonable
behaviour from fusesoc. Anyway, this check only triggers when a 1-bit
parameter is set with a literal 1, so should be safe. (If you do
something buggy like setting it to 2, it will still moan at you). This
patch adds a waiver file in examples/simple_system that silences the
warning.
This patch also makes the equivalent change to riscv_compliance,
adding a waiver file in dv/riscv_compliance/lint and fixing up the
default parameters.
This is part of work to run binaries created for the simple system
under Spike. Spike's default behaviour (after a weird 'rom' trampoline
at 0x1000) is to obey the entry point given in the ELF file. So let's
set it correctly.
This commit adds a separate memory ports for instruction and data
fetches to the Simple System example.
* Add Dual-Port RAM with 1 cycle read/write delay, 32 bit words.
* Introduce parametric signal width definitions for bus implementation
to work with a single host / device.
* Modify Simple System top module to instantiate the new dual-port RAM.
Two unused bits of device_err were only assigned in an initial block,
and it not in Verilator. They should have been tied off always to avoid
mixed blocking/nonblocking assignments to the same signal.
