The CLI tool uses its own __main__.py; as a convention, we will suffix
it with '_cli' in order to avoid name collisions with Python packages
(e.g. an Amaranth core may have its package named after itself).
- 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.
- 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.
* update dependencies
* add paramiko as a dependency (the SSH library used by amaranth)
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.
* 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
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).