Overview
The C++ Instruction Set Simulator is a generated instruction set simulator (ISS) whose source is derived from a complete, architectural-style property suite rather than from a manually reimplemented ISA model. In the described method, a formally verified property suite becomes a functionally equivalent architectural model of the verified processor design; the generated ISS is therefore equivalent to the design by construction after successful verification. [C1]
ISSs are used in processor and system design flows for pre-silicon software development, allowing software to be simulated before the target system is manufactured or even fully finished. The motivation for generating the C++ ISS is to avoid slow gate-level or cycle-accurate execution for software workloads while also avoiding a separate manual reimplementation of the ISA. [C2]
Generation model
The generation flow starts from an ISA description written in ITL. The next_state macro forms the core of the ISA: it takes the current architectural state and decoded instruction fields and returns the architectural state after executing the instruction. A decode macro decomposes an instruction word into fields stored in an instruction record, enabling reuse of decoded instruction information during simulation. [C3]
The generated simulator core is a C++ class named Sim. It contains the instruction-execution code and stores the architectural state. The translation from ITL to C++ includes generating public functions for next_state, decode, and interface macros; generating private functions for remaining macros; generating a member variable for architectural state; replacing ITL/HDL data types and operations with C++ equivalents; and replacing update expressions with direct array or structure overwrites in C++. [C4]
A full RTL/ISA equivalence proof is not required before generating the simulator. The ISA can be developed in ITL early in the design process and used to generate an ISS before verification starts. If the ISA changes, the ISS is regenerated; full confidence that the ISS complies with the design is obtained at the end of formal verification. [C5]
Runtime integration
The generated C++ class provides the core ISS functionality, but the user supplies a wrapper. The wrapper calls the generated public functions to execute individual instructions and connects the simulation core to peripheral components such as external memories or buses. The evidence also describes integration with commercial simulation and debugging tools in the experimental setup. [C6]
Code-generation optimizations
Several optimizations are applied during C++ generation to improve simulation performance:
- ITL/HDL values whose bit width fits the host system are mapped to native C++ data types such as unsigned integers.
- Basic integer arithmetic and simple logic operations are mapped to native C++ operations.
- Larger bit vectors and complex operations such as bit slicing or bit rotation use optimized library functions.
- Data dependencies in macro functions are analyzed to identify shared expressions, allowing member variables to cache temporary and intermediate results.
- Decoded instruction fields are cached so repeated decoding of the same instruction can be avoided, which is effective for common software locality patterns such as loops. [C7]
Experimental results
Two generated ISSs were evaluated. For a small pipelined processor with eight 16-bit registers, a special interrupt-return-vector register, a five-stage pipeline, and seven instructions, the generated property-suite ISS achieved 7 MIPS. In the same comparison, an interpretive commercial-tool ISS achieved 0.22 MIPS and a just-in-time compiled simulator achieved 14 MIPS. [C8]
For an industrial processor design with 64 32-bit registers across multiple hardware contexts, a seven-stage pipeline, memory and bus interfaces, and 88 DLX-based instructions, the generated ISS achieved 1.2 MIPS. The commercial just-in-time compiled simulator achieved 2.5 MIPS. The reported processor core was about 10,000 lines of VHDL, and the final reformulated property suite was about 2,000 lines of ITL. [C9]
The authors conclude that the generated C++ ISS performance is comparable to state-of-the-art commercial tools when the generation applies the described optimizations. They also note that commercial just-in-time compiled simulators remained faster, likely due to tool optimizations and because the generated properties reflected hardware and pipeline effects that may be absent from high-level ISA descriptions. [C10]
Design value
The main technical value of the artifact is that it uses the formal property suite as a single source for both verification and simulation. This supports automatic simulator adaptation when the design or specification changes late in the process and provides a practical way to obtain a proven-correct and efficient ISS for early software development. [C11]