Architectural Simulator
An architectural simulator is a reference simulation model for a processor architecture. In the cited functional-verification methodology, it describes the behavior of any microprocessor implementation of the given architecture as the architecture is specified in the architectural manual, and it is used as the reference machine when checking RTL behavior. [C1] It is part of a broader code-generation and analysis tool set used in simulation-based verification of high-performance microprocessors, alongside verifiers such as SBVer, BRVer, MPVer, MPAV, Theo, the Profiler, and the diagnostic database (DDB). [C7]
Role in functional verification
In the described microprocessor verification flow, diagnostic programs are compiled and provided as input to two simulators. The architectural simulator is used as a reference machine and is characterized as fast and inexpensive to run. The RTL simulator represents the particular microprocessor implementation and is much slower and much more expensive to use. [C2]
The two executions produce traces:
- the architectural trace, which captures how the architecturally visible state changes as a result of executing the instructions in the diagnostic, and
- the RTL trace, which captures how the microprocessor's state changes as a result of executing the same instruction sequence. [C3]
Because state-of-the-art microprocessors contain many advanced implementation features, the two traces may not be the same in form. A conversion tool (called the streamer) transforms the RTL trace into a trace representing the changes in the architectural state as deduced from the RTL trace. An architectural comparator (refdif) then compares the converted RTL-derived architectural trace with the trace produced by the architectural simulator. If the traces differ, the model does not behave correctly, and the diagnostic has identified a flaw in the microprocessor's implementation. [C3] The paper frames the goal of functional verification as ensuring that the RTL model exhibits the same behavior as an architectural simulator would when executing the same instruction sequence. [C2]
Role during test generation in Genesys-Pro
In Genesys-Pro, the architectural simulator is used during test generation, not only after a full program has been built. After formulating a CSP for the next instruction, the generation engine solves it with a dedicated CSP engine. After generating each instruction, Genesys-Pro sends it to an architectural simulator for simulation. This lets the generator maintain an accurate view of architectural resources, which is essential for resolving subsequent constraints and for producing expected results for each resource involved in the test. [C4]
The generated test program then passes to a design simulation environment, which runs the program and looks for mismatches between the expected results specified in the test and the actual results produced by the design simulator. [C4]
Why it matters
Across the provided evidence, the architectural simulator serves as the architectural point of truth in two complementary ways:
- Reference for correctness checking: it provides the expected architectural behavior of an instruction sequence so that RTL behavior can be compared against it, and disagreement indicates an implementation flaw. [C2][C3]
- Reference for generation-time state tracking: it updates architectural state as instructions are generated, enabling later constraints and expected-result computation. [C4]
Architectural simulator versus RTL simulator
| Component | Function in the cited flows |
|---|---|
| Architectural simulator | Reference machine modeling architecture-level behavior, as specified in the architectural manual; produces the architectural trace and supplies expected results. [C1][C3][C4] |
| RTL simulator | Implementation-specific simulator used to run the design model and produce an RTL trace that is converted into an architectural-state trace for comparison. [C2][C3] |
Context in diagnostic evaluation
The 1996 methodology embeds the architectural simulator in a broader diagnostic-evaluation process. Each time a diagnostic program is simulated, a Profiler-based analysis code is executed on the trace file representing that simulation. The analysis extracts information about the interesting cases covered during the run, such as cache hits and misses, types of exceptions, and queue sizes. These results are expressed as a prespecified, common set of attribute values and stored in the Diagnostic Database (DDB) for later retrieval, test-evaluation, and feedback into the code-generation tools. The architectural simulator is one of the two simulators feeding this process. [C5]
The Profiler library itself, which underpins this analysis, is an object-oriented interface that allows stepping forward and backward through simulation cycles in a trace file and retrieving the value of any variable in the machine state, so the same code can be reused across trace formats and across tasks such as transition-coverage checking, trace comparison, and illegal-condition detection. [C5]