ASA-EMulatR Reference Guide > Introduction > Architecture Overview > Chapter 6 - Serialization and Stall Model

6.5.1 How Barriers Stall the Pipeline

When a barrier instruction reaches the Execute (EX) stage, its grain calls the appropriate CBox method (executeMB, executeWMB, executeTRAPB, or executeEXCB). The barrier then:

1.Sets slot.stalled = true

2.Records slot.serializeType (Barrier_MB, Barrier_TRAP, Barrier_WRITE, or Barrier_EXC)

3.Sets slot.needsMemoryBarrier and/or slot.needsWriteBufferDrain flags

4.Prevents frontend fetch — no new instructions enter the pipeline

5.Prevents advancement of younger instructions — stages before the barrier freeze

6.Allows older instructions to continue draining through MEM and WB

The stall is checked in stage_MEM(), which evaluates the barrier flags each cycle:

// stage_MEM() stall check

if (slot.needsMemoryBarrier && !slot.memoryBarrierCompleted) {

slot.stalled = true;

return;

}

if (slot.needsWriteBufferDrain && !slot.writeBufferDrained) {

slot.stalled = true;

return;

}

6.5.2 What Continues During a Stall

While a barrier is stalled, the pipeline is not frozen — only the barrier slot and younger stages are held. Older stages continue to execute:

•Earlier pipeline slots (MEM, WB) continue to advance and retire

•Write buffers may drain — CBox::drainWriteBuffers() commits buffered writes to GuestMemory

•Exceptions may be delivered from older instructions in WB

•Interrupts may be sampled (but not taken unless safe)

No new speculative instructions are fetched until the barrier releases.

6.5 Pipeline-Level Behavior

6.5 Pipeline-Level Behavior

6.5.1 How Barriers Stall the Pipeline

6.5.2 What Continues During a Stall