- 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).
