When in the FLUSH state we cannot have `csr_pipe_flush` set as it
depends upon `instr_executing` being set (within `ibex_id_stage`) and
that is only set in the DECODE stage.
Co-authored-by: Greg Chadwick <gac@lowrisc.org>
* [rtl] Flush controller in PMP CSR write ops
As Greg pointed out:
When we have an instruction in ID/EX that writes a PMP register that
update gets written to the CSR the same cycle the next instruction
moves from IF to ID/EX with it's PMP check done with the old value.
The solution is to flush the pipeline when we get a PMP CSR write.
Signed-off-by: Canberk Topal <ctopal@lowrisc.org>
* [rtl] Flush pipe on MSECCFG CSR write
Without this an instruction executed immediately after the MSECCFG write
doesn't have the new MSECCFG setup applied to its execute permission.
---------
Signed-off-by: Canberk Topal <ctopal@lowrisc.org>
Co-authored-by: Canberk Topal <ctopal@lowrisc.org>
Co-authored-by: Greg Chadwick <gac@lowrisc.org>
* remove BranchTargetALU param.
Signed-off-by: Szymon Bieganski <szymon.bieganski@oss.nxp.com>
* remove references to the removed parameters from the documentation
Signed-off-by: Szymon Bieganski <szymon.bieganski@oss.nxp.com>
* remove references to the removed parameters from the example configurations
Signed-off-by: Szymon Bieganski <szymon.bieganski@oss.nxp.com>
* remove references to the removed parameters from examples
Signed-off-by: Szymon Bieganski <szymon.bieganski@oss.nxp.com>
* remove references to the removed parameters from compliance verification
Signed-off-by: Szymon Bieganski <szymon.bieganski@oss.nxp.com>
* remove references to the removed parameters from core lists
Signed-off-by: Szymon Bieganski <szymon.bieganski@oss.nxp.com>
* Remove references to the removed parameter(s) from Yosys framework configuration parser
Signed-off-by: Szymon Bieganski <szymon.bieganski@oss.nxp.com>
---------
Signed-off-by: Szymon Bieganski <szymon.bieganski@oss.nxp.com>
Co-authored-by: Szymon Bieganski <szymon.bieganski@oss.nxp.com>
Ibex has a top-level `fetch_enable_i` input. When set to on (noting it's a multi-bit signal for
security hardening though only the bottom bit is looked at for non secure ibex) Ibex executes
normally. When set to off Ibex will stop executing. Randomly toggling it should have no functional
effect on Ibex's behaviour.
The fetch enable sequence will randomly toggle the value of `fetch_enable_i` with a configurable
bias between the 'On' value and all other values.
This commit adds functionalty to the memory response agent to make delays more
configurable.
There are two delays
- Delay between req and gnt
- Delay between gnt and rvalid
For each of these delays we have three modes:
* Fully random delay
* Fixed delay
* Biased delay. Randomised delays but allow biasing towards 0 delay, to give a mix of runs with back
to back transfers with no delay and some with delays.
Signed-off-by: Prajwala Puttappa <prajwalaputtappa@lowrisc.org>
Added an independent base test with following capabilities:
* chooses between single run, multiples runs or infinite runs (existing sequence
does this via the `num_of_interations` variable).
* interval between runs can be fixed or random, with 0 delay between runs possible.
For random intervals there should be a way to bias them more towards 0 delay
(e.g. specify 75% of delays should 0 with the rest randomly chosen).
Added an interrupt sequence that inherits from the above base sequence.
It has following capabilities:
* chooses the number of interrupts to raise
* specifies the interval between interrupt being raised and dropped
* a mask to specify interrupts that shouldn't be raised.
Added a debug sequence with the only functionality to specify the interval between
the debug request being raised and dropped
Added a sequence to corrupt instruction and data memory.
Signed-off-by: Prajwala Puttappa <prajwalaputtappa@lowrisc.org>
This is triggered by the fact that if the ICache parameter is false
then we don't instantiate the ibex_icache module. For verilator
simulations, the module is then discarded entirely, which means that
its two DPI functions are not defined. That's unfortunate because
we're also compiling the code in scrambled_ecc32_mem_area.cc, which
expects the functions to be defined.
The obvious solution (don't include scrambled_ecc32_mem_area.cc if you
don't have an icache) isn't easy to do, because FuseSoc doesn't
currently allow us to use parameters to configure its dependency
tree (see fusesoc issue 438 for a discussion).
The super-clever solution that I came up with before(!) was to declare
these symbols as weak in the C++ code. That way, we can do a runtime
check to make sure that no-one is silly enough to call them without an
icache, but everything will still build properly either way.
Unfortunately, that doesn't work well with xcelium simulations.
Xcelium turns out to compile all the C++ code into one .so library and
generate functions for exported DPI functions in another. These two
solibs then get loaded at runtime with dlopen(). But this doesn't work
with weak symbols: in fact, it seems you end up with the C++ version
every time. Boo!
So let's be stupider about it and define (bogus) versions of the DPI
functions in this case. Fortunately, both of them are designed to
return zero on failure so we can just return zero and needn't worry
too much.
The idea is that when this lands, we can revert the OpenTitan change
that switched the C++ code to using weak symbols and Xcelium
simulations will start working.
Defining agent configuration for any agent is a standard UVM flow and is
a cleaner flow for defining delay between driving sequence items,
passing virtual interface etc.
Agent configuration has been added to the existing agent to make delay
configuration more flexible in the future.
Signed-off-by: Prajwala Puttappa <prajwalaputtappa@lowrisc.org>
When the icache is enabled and data independent timing is required
variable fetch latency due to cache hit or miss may introduce
undesirable timing behaviour. This adds explicit mention of this to the
documentation.
A sufficiently agressive optimiser may optimise these away as under
normal functioning they effectively don't do anything. They are purely
to detect the presence of induced faults.
We're going to want to make a couple more releases of Spike, cleaving
a bit closer to the upstream repository. Let's be explicit about which
version people should get.
This is to allow more consistent signalling in systems that integrate
Ibex (e.g. OpenTitan) so bus integrity errors external to Ibex and one's
detected within Ibex can be fed into the same alert whilst seperating
out Ibex's various internal alert causes.
