Overview
An equivalence proof is a formal argument that two descriptions of a system agree on the behavior of interest. In the processor-verification example from Generating an Efficient Instruction Set Simulator from a Complete Property Suite, the equivalence proof relates a CPU implementation at the Register Transfer Level (RTL) to an instruction-set architecture (ISA) model.
RTL-to-ISA structure
In the cited approach, the proof uses an abstraction function, named vstate, that maps the implementation state of the CPU to the architectural ISA state. The intended commuting structure is:
- start from a CPU implementation state;
- map it to an ISA state using
vstate; - execute the ISA transition using
next_state; and - show that this corresponds to first applying the CPU transition relation
Tand then mapping the resulting CPU state back to the ISA state usingvstate.
The architectural proof obligation shown in the evidence has the form that, when the processor is ready to start an instruction, the ISA state at the next time step equals the result of applying next_state to the current ISA state and decoded instruction.
Supporting obligations
The RTL-to-ISA equivalence proof is not limited to the core state-transition diagram. The cited paper also states that it must be proved that interface signals behave as captured by interface macros, and that the implementation reset state complies with the defined architectural reset state.
Relationship to simulator generation
In the cited ISS-generation workflow, a full equivalence proof between ISA and RTL is not required before generating the instruction set simulator. The ISA can be developed early in ITL and used to generate an ISS; full confidence that the generated ISS complies with the design is obtained later, at the end of verification. The same evidence notes that finding appropriate mapping functions for the architectural state is one of the more sophisticated parts of verification, but those mapping functions are not needed to automatically generate the ISS.
Role of architectural state
The approach models architectural state explicitly, typically as a user-defined VHDL record combining elements such as the register file, status flags, and program counter. A next_state macro captures the effects of instructions and interrupts on this architectural state, and the resulting single property can serve as a formally checkable ISA description.