|
<< Click to Display Table of Contents >> Navigation: ASA-EMulatR Reference Guide > Introduction > Architecture Overview > Chapter 21 – Debugging, Tracing, and Determinism > 21.1 Determinism as a Design Goal |
Determinism in EMulatR means: given the same initial state, with the same inputs, and the same configuration, the emulator produces the same architectural outcomes every time. This includes instruction retirement order, exception delivery order, interrupt timing (relative to cycles), DMA visibility, and SMP interactions. Determinism is required for debugging, regression testing, architectural validation, and long-running SMP correctness.
EMulatR claims architectural correctness when: architectural state transitions match Alpha AXP rules, exceptions are precise and ordered, memory ordering semantics are preserved, SMP interactions are race-free and deterministic, and privileged boundaries are enforced. It does not claim cycle-exact microarchitectural modeling or hardware-accurate cache timing. This distinction is intentional — the emulator trades microarchitectural realism for deterministic correctness and debuggability.
Determinism is enforced through the per-cycle run loop with deterministic stage ordering, explicit barrier protocols, and no undefined behavior in cross-CPU interactions (all coordination via atomic operations or mutex-protected paths). The pipeline guarantees in-order retirement (m_instructionsRetired increments monotonically), one architectural commit per cycle, no speculative side effects (stores only commit in WB, registers only write in MEM via committed pending), and no privilege leakage. One iteration of the run loop corresponds to one hardware clock cycle, enabling deterministic replay and debugging.
Invariant: Host scheduling must never influence architectural outcome. All nondeterminism is intentional and observable.
See Also: Chapter 2 - Execution Model (cycle-based execution model); Chapter 13 – AlphaPipeline Implementation (pipeline determinism guarantees).