Currently, the dual-core lockstep FI mitigation is enabled/disabled
using a single bit.
For transient bit-flips, this is not problematic, as one bit-flip
into this signal and one bit into the Ibex is required to threaten
the security of the system.
However, a permanent stuck-at-0 fault could disable the lockstep
completely by targeting this signal. Then, only a single, additional
fault (transient or permanent) is required.
This PR enhances the FI resilience of the Ibex lockstep by encoding
this single bit into a ibex_mubi_t signal, i.e., a 4-bit multi-bit
signal.
Signed-off-by: Pascal Nasahl <nasahlpa@lowrisc.org>
As described in #20715, a single fault-induced bit-flip inside the
register file could change which of the register file value is
provided to Ibex.
This PR fixes this issue by (i) encoding raddr_a/b to one-hot
encoded signals, (ii) checking these signals for faults, and
(iii) using an one-hot encoded MUX to select which register file
value is forwarded to rdata_a/b.
Area increases by ~1% (Yosys + Nangate45 synthesis).
I conducted a formal fault injection verification at the Yosys
netlist to ensure that the issue really is fixed.
Signed-off-by: Pascal Nasahl <nasahlpa@lowrisc.org>
With the latest versions of all python packages in
python-requirements.txt ibex_cmd.py was seeing a run-time type error.
Data from a YAML file that had previously always been a string could now
be an int as well. This alters the code to allow the int to work.
This shouldn't change the behaviour when it works. On a failure, we
now print out a bit more about what's going on.
When asked to do something impossible now, I think the output is a bit
clearer. For example, if you try to run riscv_bitmanip_full_test with
an OpenTitan configuration (which doesn't have full bitmanip), the
warning message is now:
WARNING:ibex_cmd:Rejecting test: riscv_bitmanip_full_test. It specifies rtl_params of ['ibex_pkg::RV32BFull'], which doesn't contain the expected 'ibex_pkg::RV32BOTEarlGrey'.
(The following stuff that appears is a bit messy, but at least the
first line is now clearer!)
This helps hit more coverage more reliably in particular for the
priv_mode_irq_cross cross coverage.
A better fix would adjust riscv_mem_intg_error_test to utilize U mode
more but it's a quick test for run so this suffices for now.
Not doing so causes VCS to spit out a warning message. The intention
seems to be that the initial call to $value$plusargs will evaluate to
true and will put the value that was assigned into the
disable_pmp_exception_handler variable, which then gets checked.
The previous version doesn't make sense if you read the classes in
exactly the order they are defined in the file. It turns out that this
is what VCS did: oops! Fortunately, the fix is pretty trivial: declare
the classes the other way around.
The previous code caused VCS to complain that the "with" clause didn't
use any of the constituent coverpoints. I *think* that VCS wasn't
understanding that cp_interrupt_taken[5:4] does indeed depend on
cp_interrupt_taken (concentrating on core_ibex_fcov_if for
concreteness).
Fortunately, the check is easy to express a different way. There, we
were just asking that the top two bits are zero. Another way to say
that is "if I shift everything else off the bottom, the result is
zero". So we say it that way.
This causes VCS to spit out an error because it's not technically
allowed in SystemVerilog. The only things that we needed to import
seems to have been the CSR_MHPMCOUNTER3* names. We can just refer to
them explicitly.
Other code tries to pick up things like DATA_WIDTH through this agent
package, that it imports. That doesn't seem unreasonable, but VCS
complains because we're not re-exporting it here.
It seems that typeguard now spots if env happens to be None. We can
just relax things: we're only using env by passing it through to
subprocess.run, which handles a None env in the expected way.
We ended up with the Unicode fix twice because of two colliding PR
merges. We only need one copy of the -CFLAGS argument, and VCS
generates a rather strange message about an unknown argument if you
use it twice. Fortunately, it's easy to fix once you've worked out how
to get the system to print out what it's doing.
Previously any changes in interrupt state or debug requests were
strictly associated with retired instructions. This causes cosim
mismatches where a lower priority interrupt occurs in time before a
higher priority interrupt or debug request but between instruction
fetches/retirements so both the low and high priority interrupts are
signalled with the instruction retirement.
This introduces a way for the RVFI to signal an interrupt has occurred
that isn't associated with an instruction retirement to allow the cosim
to see the seperation in time between different interrupts and debug
requests and hence model behaviour correctly.
An IRQ asserting then deasserting when not explictly cleared by an
interrupt handler can lead to RTL/cosim mismatches in some cases.
Increasing the delay here minimises those instances.
This commit introduces the use of a pydantic model to validate the
data used to define directed tests. 'pydantic' is a python data validation
and settings management library which allows for structured data to be
checked against 'pydantic models'. In this case, we define a 'model' for
how we expect the directed-test yaml to look, including fields and datatypes,
and then validate that the imported file matches this expectation.
In effect, it allows the checking of the data to be seperated from its use.
dv/uvm/core_ibex/scripts/directed_test_schema.py defines the pydantic model,
and provides a function 'import_model()' to check the file-contents and
return a valid dictionary of the structured data.
* First implementation of a directed_test framework, which aims to re-use as much
as possible from the existing riscvdv generation
* Fixed directed test flow to cleanly end the test
* clang-format is off for assembly header files
