- 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>
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>
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>
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>
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 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.
Refactors performance counters so only flops that are required from the
given parameters are explicitly elaborated without relying on
optimization to remove unused flops.
Fixes#473
Simple system is a basic verilator top-level testbench for running
executables. It has functionality for outputting text to a log file
and for the software to terminate the simulation
