ASA-EMulatR Reference Guide > Introduction > Architecture Overview > Chapter 22 – Testing, Validation, and Architectural Compliance

Validation is structured in five layers, each with a clear responsibility and escalating scope. Tests at each layer must pass before the next layer is meaningful.

22.2.1 Layer 1 — Unit Validation

Verifies correctness of individual components in isolation. Targets include instruction grains, register banks, floating-point operations, address translation helpers, and LL/SC reservation logic. Methods use deterministic inputs with expected architectural outputs and exhaustive edge-case coverage. Unit tests must be independent of pipeline timing — they test component semantics, not scheduling behavior.

22.2.2 Layer 2 — Instruction-Level Validation

Verifies instruction semantics in isolation. Targets cover all instruction categories: integer instructions, floating-point instructions, memory instructions, branch and control instructions, and PAL instructions. Validation criteria: correct result values, correct flag behavior, correct exception generation (each instruction that should fault does fault, each instruction that should not does not), and correct side effects (memory writes, register modifications, reservation changes). PAL instructions are validated separately for privileged and unprivileged function ranges.

22.2.3 Layer 3 — Pipeline and Ordering Validation

Verifies interaction between instructions within the pipeline. Targets include hazard handling (data hazards, structural hazards), stall and release behavior (correct stall cycles, correct release conditions), barrier enforcement (MB, WMB, EXCB, TRAPB serialization semantics), and exception precision (faulting instruction identified exactly, no younger instruction commits). Methods: synthetic instruction sequences designed to exercise specific pipeline states, forced stalls via deliberately constructed dependency chains, deliberate fault injection to test precise delivery, and barrier stress tests that interleave barriers with memory operations.

22.2.4 Layer 4 — SMP Validation

Verifies multi-CPU correctness. Targets: LL/SC behavior under contention (multiple CPUs contending on the same cache line), TLB shootdown correctness (no stale entries survive), inter-processor interrupt handling (delivery, acknowledgment, ordering), and memory visibility guarantees (store visibility across CPUs after barriers). Methods: deterministic SMP workloads with known expected outcomes, artificial contention patterns that exercise worst-case reservation behavior, and repeatable race scenarios using deterministic scheduling mode. SMP correctness is proven through repetition and determinism, not probability — a test that passes only "most of the time" is a failing test.

22.2.5 Layer 5 — System-Level Validation

Validates full-system behavior. Targets: PAL entry/exit correctness across all PalEntryReason paths, interrupt delivery through the complete IRQPendingState → checkInterrupts → PalService → HW_REI chain, device and DMA interaction (MMIO ordering, DMA completion visibility), and console services (CSERVE selector dispatch, SRM environment variables). Methods: controlled boot sequences (Phase 0 through SRM >>> prompt), diagnostic Alpha assembly programs (e.g., test_cserve_env.s), and long-running stress tests that exercise the full execution stack over millions of cycles.