|
<< Click to Display Table of Contents >> Navigation: ASA-EMulatR Reference Guide > Introduction > Architecture Overview > Chapter 10 – Devices and Memory-Mapped I/O (MMIO) |
This chapter defines how EmulatR models devices and memory-mapped I/O (MMIO), and how device interactions integrate with:
•The AlphaCPU pipeline
•The memory system
•Interrupt delivery
•Serialization and ordering
•SMP execution
Devices are asynchronous entities, but MMIO access is synchronous and strongly ordered. This distinction is fundamental to correctness.
EmulatR follows real Alpha hardware principles:
1.MMIO is memory-mapped but not memory-like
2.MMIO accesses are strongly ordered
3.Device operations are asynchronous
4.Completion is signaled via interrupts
5.CPU execution never blocks on device work
6.PAL mediates privileged device control
This separation ensures correctness, debuggability, and architectural fidelity.
In EmulatR, a device is an object that:
•Owns one or more MMIO address ranges
•Exposes registers via MMIO
•Executes operations asynchronously
•Signals completion via interrupts
•May perform DMA into GuestMemory
Devices do not execute in the CPU pipeline.
Devices are:
•Created by the DeviceManager / {SCSIDeviceManager, ConsoleManager, NetworkManager, FibreDeviceManager, IDEDeviceManager, etc.}
•Registered with the MMIOManager
•Assigned physical address ranges
•Assigned interrupt lines
•Optionally bound to backing storage or network endpoints
Once registered, devices become visible to all CPUs via GuestMemory.
MMIO regions are distinguished from RAM by address range, not instruction type.
When a physical address resolves to:
•RAM → handled by SafeMemory
•MMIO → routed to a device handler
This distinction occurs after translation (VA → PA).
MMIO access flow:
CPU Instruction
↓
Address Translation (MBox)
↓
Physical Address
↓
GuestMemory
↓
MMIOManager
↓
Device Register Handler
SafeMemory is never involved in MMIO.
MMIO accesses are strongly ordered:
•No reordering
•No buffering
•No speculation
•No combining
•No deferral
Every MMIO read or write:
•Completes synchronously
•Is visible immediately
•Observes program order
This prevents device protocol violations.
MMIO access occurs during the EX stage.
Behavior:
•The instruction executes synchronously
•The pipeline may stall for the duration
•The result is returned immediately
•No write buffer is used
MMIO instructions retire only after the access completes.
Devices expose control and status registers via MMIO.
Typical registers:
•Command registers
•Status registers
•Data registers
•Interrupt control registers
•DMA descriptors
Reads and writes are performed using standard load/store instructions.
MMIO register access may have side effects:
•Writing a command register may start an operation
•Reading a status register may clear bits
•Writing a control bit may acknowledge an interrupt
These side effects occur during the MMIO access itself.
10.7.1 Device Execution Model
After receiving a command:
•The device begins work asynchronously
•CPU execution continues immediately
•The device may perform DMA
•Completion is deferred
The CPU never spins waiting for a device unless software explicitly polls.
DMA allows devices to:
•Read from GuestMemory
•Write to GuestMemory
•Bypass CPU caches (architecturally)
DMA is subject to:
•Address translation rules
•Access permissions
•Cache coherency rules (modeled)
DMA completion does not imply ordering unless enforced by barriers or interrupts.
Devices signal completion via interrupts.
Process:
1.Device completes work
2.Device asserts interrupt line
3.InterruptController records pending IRQ
4.CPU samples interrupt during pre-cycle phase
5.Interrupt is delivered through PAL
Interrupt acknowledgment typically occurs via MMIO:
•CPU reads or writes a device register
•Device clears interrupt condition
•Interrupt line is deasserted
PAL code often performs this acknowledgment.
MMIO accesses are implicitly serialized.
No explicit barrier is required to ensure:
•Ordering relative to other MMIO accesses
•Visibility to the device
However, ordering relative to normal memory may require barriers.
Common patterns:
MB before MMIO write - ensures prior memory writes are visible before device sees command.
MB after MMIO read - ensures device results are visible before CPU proceeds.
This mirrors real Alpha programming requirements.
Some device operations require PAL mode:
•Device initialization
•Interrupt routing configuration
•DMA enablement
•System-wide device control
Accessing these registers outside PAL faults.
All device interrupts ultimately enter PAL.
PAL code:
•Identifies interrupt source
•Acknowledges device
•Invokes OS handler
•Returns via HW_REI
This ensures controlled, serialized device interaction.
In SMP systems:
•Devices are globally visible
•MMIO ordering is global
•Interrupts may target specific CPUs
•DMA affects shared memory
Barriers may be required for cross-CPU coordination
Devices themselves are not CPU-affine unless explicitly configured.
MMIO access may generate faults:
•Access violation
•Alignment fault
•Device-specific errors
These faults:
•Are detected synchronously
•Are delivered precisely
•Enter PAL through normal exception flow
Device errors do not corrupt CPU state.
Recommended diagnostics:
•Log all MMIO reads/writes with CPUId
•Trace device command submission
•Trace interrupt assertion and acknowledgment
•Validate DMA address ranges
•Verify ordering with explicit barriers
MMIO bugs are ordering bugs until proven otherwise.
Key principles:
1.MMIO is strongly ordered
2.Devices are asynchronous
3.MMIO access is synchronous
4.Completion is interrupt-driven
5.DMA operates on GuestMemory
6.PAL mediates privileged control
7.SMP visibility is explicit
8.Barriers ensure correctness