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 `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.
* 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).
Jean-François Nguyen