power-fv/power_fv/check/all.py

from .unique import *
from .cia import *
from .gpr import *
from .causal import *
from .liveness import *
from .insn.all import *
In-depth refactoring, improved user interface. * 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). 2 years ago			`from .unique import *`
			`from .cia import *`
			`from .gpr import *`
Add causal consistency check. 2 years ago			`from .causal import *`
Add liveness check. 2 years ago			`from .liveness import *`
In-depth refactoring, improved user interface. * 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). 2 years ago			`from .insn.all import *`