Skip to content
STIMSMITH

ReOrder Buffer (ROB)

Concept WIKI v2 · 5/28/2026

A ReOrder Buffer (ROB) is a processor microarchitectural structure used in superscalar out-of-order designs to hold execution results until instructions can retire in program order. In the provided RISC-V superscalar processor evidence, the ROB is a cyclic buffer that accepts up to two renamed instructions per cycle, tracks completion from functional units, commits the oldest ready entries in order, and helps make store instructions non-speculative only when they reach the ROB head. It is also a practical observation and perturbation point in processor verification co-simulation and logic fuzzing.

Overview

A ReOrder Buffer (ROB, also written as Reorder Buffer or Re-Order Buffer) is a microarchitectural structure in the back end / write-back portion of an out-of-order processor. In the provided two-way RISC-V superscalar out-of-order processor, execution results are temporarily stored in the ROB until their instructions can commit or retire. The ROB maintains correct program order during retirement even though execution may complete out of order, and it supports speculative execution beyond branches. [C1]

Operation in a two-way superscalar out-of-order core

In the described RISC-V design, the ROB is characterized as a typical cyclic buffer with additional functionality. Each cycle it can receive at most two requests to store new data, corresponding to instructions that have just been renamed in the register-renaming stage. Each newly issued instruction reserves a ROB entry; because the core can issue up to two instructions per cycle, the ROB can reserve up to two entries per cycle. [C2]

The ROB also checks the two oldest entries each cycle to determine whether they are ready to commit. Although execution can finish out of order, commits occur only in order. When the oldest instructions satisfy the commit requirements, they are retired. [C3]

Completion information from functional units is written back into the ROB. Each cycle, the design checks functional-unit outputs; when execution has finished, the result is saved into the proper ROB entry using the ticket associated with the request, and the entry's pending bit is deasserted to indicate completed execution. [C4]

Speculation and memory ordering role

The ROB serves as a tracker for resolving speculative instructions. In the provided design, this is specifically used for store instructions: stores are not allowed to modify cache contents until they are non-speculative, which occurs when they are at the ROB head. The load-store unit also checks for possible forwarding from the ROB when processing loads. [C5]

In the same processor overview, up to two instructions can commit per clock cycle, writing results into the register file or, for store instructions, into the data cache. [C1]

Verification relevance

The ROB is treated as a major verification target in the provided RISC-V superscalar processor thesis, which lists Instruction Fetch, Register Renaming, Issue, and ReOrder Buffer among the verified units. [C6]

The MICRO 2021 Logic Fuzzer / Dromajo co-simulation evidence shows another verification use: when integrating Dromajo into BOOM, simple monitor logic can be implemented in the Reorder Buffer module. If the instruction at the head of the buffer is valid and ready to commit, the DPI step() function is called; Dromajo commits one instruction on its side, compares the communicated program counter, instruction, and store data, and returns a non-zero code on mismatch. [C7]

The same work uses ROB control behavior as an example of correctness-preserving logic fuzzing. It states that the ROB may assert a full or stall signal even when it is not full, changing the number of cycles without corrupting functionality or program order. In a BOOM experiment, a congestor was inserted at the ROB ready signal and randomly pulled it low when the ROB was actually ready; this caused additional toggle activity in frontend, core, and load-store-unit signals. [C8]

Security and modeling context

Public research context also identifies ROB size as relevant to transient execution. The SPECRUN paper summary states that SPECRUN exploits unresolved branch prediction during runahead execution and eliminates the limitation on the number of transient instructions posed by reorder-buffer size. [C9]

Another public summary on instantaneous instruction execution for memory models lists the ROB among microarchitectural details—together with partial and speculative execution and instruction replay—that make processor memory-model specifications complicated for reasoning about program behavior and compiler verification. [C10]

Relationship to superscalar out-of-order processors

The ROB is part of the processor back end in the provided two-way superscalar out-of-order RISC-V design. Its role is to reconcile out-of-order completion with in-order architectural retirement, making it a central structure in a [[Superscalar Out-of-Order Processor]]. [C1]

LINKED ENTITIES

1 links
Superscalar Out-of-Order Processor PART_OF

CITATIONS

10 sources
10 citations
[1] The ROB temporarily stores execution results until commit/retirement, maintains correct program order during retirement despite out-of-order execution, supports speculative execution beyond branches, and up to two instructions can commit per cycle in the described two-way RISC-V processor. [PDF] UVM-based verification of RISC-V superscalar processors
[2] In the described design, the ROB is a cyclic buffer that can receive up to two new data-store requests per cycle from renamed instructions and can reserve up to two entries per cycle. [PDF] UVM-based verification of RISC-V superscalar processors
[3] The ROB checks the two oldest entries each cycle, and commits happen in order even though execution can complete out of order. [PDF] UVM-based verification of RISC-V superscalar processors
[4] Functional-unit completion data is written into the selected ROB entry using a ticket, and the pending bit is deasserted when execution is complete. [PDF] UVM-based verification of RISC-V superscalar processors
[5] The ROB tracks speculative instructions; stores may modify cache contents only after becoming non-speculative at the ROB head, and loads can check for forwarding from the ROB. [PDF] UVM-based verification of RISC-V superscalar processors
[6] Instruction Fetch, Register Renaming, Issue, and ReOrder Buffer are listed as verified units in the RISC-V superscalar processor verification work. [PDF] UVM-based verification of RISC-V superscalar processors
[7] For BOOM-Dromajo co-simulation, monitor logic in the Reorder Buffer can call Dromajo's DPI step function when the ROB head instruction is valid and ready to commit; Dromajo then commits one instruction and compares communicated data. [PDF] Effective Processor Verification with Logic Fuzzer Enhanced Co ...
[8] Logic Fuzzer can perturb ROB full, stall, or ready behavior without corrupting functionality or program order; a BOOM ready-signal congestor produced additional frontend, core, and load-store-unit toggle activity. [PDF] Effective Processor Verification with Logic Fuzzer Enhanced Co ...
[9] The SPECRUN public summary states that the attack eliminates the limitation on the number of transient instructions posed by reorder-buffer size. SPECRUN: The Danger of Speculative Runahead Execution in Processors
[10] The public summary of the I2E memory-model paper identifies the reorder buffer as a microarchitectural detail, along with partial/speculative execution and instruction replay, that complicates formal memory-model reasoning. An Operational Framework for Specifying Memory Models using Instantaneous Instruction Execution

VERSION HISTORY

v2 · 5/28/2026 · gpt-5.5 (current)
v1 · 5/27/2026 · gpt-5.5