- Testcases are translated to JSON by the OPV 'parsetst' script.
- A behavioral model of a single-threaded core is implemented by
coupling PowerFV instruction specs to an execution context (i.e.
registers, memory).
- Testcase traces are reproduced in simulation by the model, and
results are compared to detect compliance bugs.
Before this commit, instructions were defined by a sequence of Const
for fixed fields (e.g. PO/XO) and AnyConst for others (e.g. operands).
This approach restricted their use to BMC use-cases, and prevented them
from appearing in VCD traces.
After this commit, an instruction encoding is defined by a Record. As
fields can now be set to arbitrary values, the corresponding InsnSpec
will only assert `pfv.stb` if `pfv.insn` matches a valid encoding (i.e.
fixed fields have correct values). On the other side, BMC testbenches
will drive `pfv.insn` with an AnyConst, and assume `pfv.stb` is high.
The Amaranth build system already supports remote builds over SSH.
This commit integrates it to the 'build' command.
Also:
* update dependencies
* add paramiko as a dependency (the SSH library used by amaranth)
The `pfv.skip` signal is used to handle cases where the DUT does not
actually execute an instruction (e.g. a no-op), which may prevent some
side-effects (e.g. GPR accesses) from being observable.
This check is implemented in two parts:
- an implementation-dependant DataStorageModel, which is connected to
the DUT and emulates bus accesses to a r/w memory.
- a DataStorageTestbench, which checks that a load from a given address
returns the last value that was stored to it.
Also:
* update dependencies.
* add amaranth-soc as a dependency, in order to reuse its bus
interfaces (e.g. Wishbone).
* add a `prog` argument to PowerFVSession that overrides the name of
its CLI.
* A PowerFVSession class provides a REPL interface. Functionality is
split into commands (e.g. add checks, build) which can be provided
interactively or from a file.
See cores/microwatt for an example of its integration.
* Instruction specifications are now separated from verification
testbenches.
An InsnSpec class provides a behavioral model using the same PowerFV
interface as a core. This interface is output-only for a core, but
bidirectional for the InsnSpec:
- fields related to context (e.g. read data) are inputs,
- fields related to side-effects (e.g. write strobes) are outputs.
The testbench is responsible for driving inputs to the same values
as the core, then check outputs for equivalence. This decoupling
provides a path towards using PowerFV in simulation.
* Instruction encodings are now defined by their fields, not their
format (which was problematic e.g. X-form has dozens of variants).
Field declarations can be preset to a value, or left undefined. In
the latter case, they are implicitly cast to AnyConst (which is
useful for arbitrary values like immediates).
* Use bitmasks to describe SPR accesses at the field granularity.
* Use separate checks for each SPR, instead of covering them all at
once. Users may run them in the same batch, and know which SPR passes
or fails its check.
We don't use it currently; we just assume the sync domain is under
reset at the beginning of the BMC.
Also, fix a regression in the cycle counter introduced by 9ea58a47.
* Checks are now split in two modules: checks.cons for consistency
checks, checks.insn for instructions.
* Checks are derived from PowerFVCheck and have a shorthand (e.g.
"insn_b"). PowerFVCheck holds a mapping between its subclasses and
their shorthands.
* Instruction checks definitions have been simplified to one-liners,
and grouped into a single file.
* A Trigger class has been added to define testbench triggers.
