This mirrors a mistaken OpenTitan commit that I made in
December (4c89520 on the OT side), editing a vendored file. Oops!
Match that behaviour here, so that we can re-vendor without undoing
the change.
The prototype of this task has to match the one in dv_base_monitor,
which we are importing from OpenTitan (called "lowrisc_ip").
Unfortunately, OpenTitan imports Ibex, causing a circular reference
which makes it a bit fiddly to change any types.
This commit switches the tasks to match the new prototype we're going
to use in OpenTitan. We can't just apply it in Ibex
immediately (because it won't work with our vendored lowrisc_ip code),
but creating the commit *does* mean we can vendor in the changed Ibex
code at the OpenTitan end.
Once that's sorted, we can vendor OpenTitan back into Ibex and get
everything cleaned up properly.
In hindsight, we probably should have made sure our vendoring
structure was a DAG.
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>
The keys in this file get incorporated into the FlowCfg object that
represents a simulation or similar. Adding a spurious key won't cause
any problems, but we actually need it for the next commit, which grabs
the current version of dvsim from OpenTitan. That version of dvsim
expects the "book" key to have been set in common_project_cfg.hjson.
Splitting the two commits like this should make it a bit more obvious
where things have come from.
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.
