|
<< Click to Display Table of Contents >> Navigation: ASA-EMulatR Reference Guide > Introduction > Architecture Overview > Chapter 3 - Pipeline Architecture > 3.12 Stalls and Serialization |
A PipelineSlot may stall due to:
•Memory barriers (MB, WMB) — slot.needsMemoryBarrier set, waiting for completion
•Exception barriers (EXCB) — slot.needsWriteBufferDrain set, waiting for drain
•Trap barriers (TRAPB) — waiting for all prior traps to resolve
•Multi-cycle FP execution — FBox occupying EX synchronously
•Operand unavailability — source register not yet written by prior instruction
•Fault dispatch — fault detected, pipeline about to flush
•PAL entry/exit — CALL_PAL serializes pipeline, HW_REI restores
•Write buffer saturation — CBox write buffer full
Stalls propagate forward only. If stage N stalls, stage N-1 cannot advance, and earlier stages remain frozen. Later stages (N+1 and beyond) continue draining toward WB. This guarantees forward progress — older instructions always complete before younger ones.
Stalls are explicit and visible in pipeline state. The pipeline reports stalls via slot.stalled, and pipeline-wide stall status is queryable via isFrontendStalled() and isPipelineStalled().
Barrier instructions do not execute work — they enforce ordering. In the EX stage, the grain sets slot.stalled = true and the appropriate request flag (needsMemoryBarrier or needsWriteBufferDrain). The slot remains stalled until AlphaCPU confirms the release condition: pipeline drained, buffers flushed, or faults delivered.
See Also: Chapter 6 - Serialization and Stall Model (barrier mechanics); 2.5 Execution Progress and Stalls.