TEST: Completed Review #2 | research/05-memory/memory-ordering.md

research/.xh1/runs/20260826T122559Z/candidate.md

@@ -0,0 +1,329 @@
+# Memory Ordering
+
+**Status:** Research document — proposal stage. No XH-1 implementation is fixed.
+**Scope:** Memory consistency model, ordering primitives, and their interaction with a 128-core RISC-V processor.
+**Audience:** XH-1 architecture team, verification engineers, OS porters.
+
+---
+
+## 1. Overview and Definitions
+
+Memory ordering defines the rules by which the memory accesses (loads and stores) issued by one or more cores become visible, in program order and globally, to other cores. It determines:
+
+- **Program order (PO):** the order in which a single hart issues memory accesses.
+- **Memory order (MO):** the global order in which accesses appear to execute as observed by other harts.
+- **Coherence order (CO):** the per-address total order of accesses required by the cache coherence protocol.
+- **Fence ordering:** explicit constraints inserted by hardware or software to restrict reordering.
+
+These concepts are foundational to any multiprocessor memory model and are defined formally in the literature (Adve & Gharachorloo, 1996; Sorin, Hill & Wood, *A Primer on Memory Consistency and Cache Coherence*, 2011).
+
+XH-1 must adopt and document a precise model so that:
+
+1. Hardware designers know which reorderings are legal.
+2. The operating-system port (and any hypervisor) knows what atomicity guarantees it can rely on.
+3. Application and runtime software (compilers, language runtimes, synchronization libraries) can map higher-level primitives correctly.
+4. The verification team can construct litmus tests and formal models against an unambiguous specification.
+
+---
+
+## 2. RISC-V Architectural Requirements
+
+### 2.1 The RISC-V Weak Memory Model (RVWMM)
+
+RISC-V defines its memory model in:
+
+> *The RISC-V Instruction Set Manual, Volume I: Unprivileged Architecture*, Document Version 20191213 (and later), §Appendix A — "RVWMM: RISC-V Weak Memory Model."
+
+Key facts established by that specification (status: **RISC-V specification requirement**):
+
+- RISC-V adopts a **release consistency** model (a variant of "weak ordering" with explicit acquire/release semantics), broadly modeled on the approach taken by Armv8.
+- Ordinary load and store instructions are divided by their **addressing mode** and **access type** into:
+  - `.aq` — acquire semantics (subsequent accesses in program order cannot be reordered before this access).
+  - `.rl` — release semantics (prior accesses in program order cannot be reordered after this access).
+  - The pair `aq+rl` yields sequential consistency (SC) per access when used on both sides of a synchronization pair.
+- Loads use acquire semantics (`LR`/`.aq` on AMOs and `LR.aq`); stores use release semantics (`.rl`).
+- `FENCE` instructions (including `FENCE.TSO`, `FENCE.I`, `FENCE.VMA`, `FENCE.GORC`, `FENCE.GW`, `FENCE.OW`, `FENCE.ORW`, `FENCE.RW`, `FENCE.RR`, `FENCE.WW`) provide explicit ordering at the hart front-end and the global memory system.
+- `FENCE.RW,RW` (the legacy full fence) orders all prior loads and stores against all subsequent loads and stores at the local hart and at the global system.
+- The model is **multi-copy atomic (MCA)** for devices that respect it, but **RISC-V explicitly does not require main memory to be multi-copy atomic** in general; I/O regions may opt into TSO or stronger ordering via `FENCE` and `aq/rl` annotations.
+
+This is the model the XH-1 must conform to for RV64 compliance; deviations are not permitted for standard harts without explicit non-standard attributes.
+
+### 2.2 Atomic Memory Operations (AMOs)
+
+RISC-V provides:
+
+- **Load-Reserved / Store-Conditional (LR/SC):** `LR.W/D`, `SC.W/D`, optionally with `.aq`/`.rl`/`.aqrl`.
+- **AMO** instructions: `AMOSWAP`, `AMOADD`, `AMOAND`, `AMOOR`, `AMOXOR`, `AMOMAX[U]`, `AMOMIN[U]` on 32- and 64-bit values.
+
+All AMOs implicitly perform a load and a store, and the addressing mode applies to the entire RMW operation.
+
+### 2.3 Reservation Sets and Forward Progress
+
+LR/SC semantics on RISC-V require that:
+
+- The reservation set be **at least as large as** the address and **contiguous in physical memory**, with forward-progress guarantees (no livelock).
+- The implementation may break a reservation for any reason, but must make progress under certain conditions (the exact rules are stated in the spec).
+
+This matters for XH-1's L1 coherence protocol design — we must specify how reservation sets map onto cache lines and which events cause invalidation.
+
+### 2.4 I/O Ordering
+
+For Memory-Mapped I/O (MMIO) and DMA, RISC-V provides `FENCE.I` for self-modifying code, and the I/O map can be marked as a **non-idempotent, strongly ordered** region via PMA (Physical Memory Attributes). XH-1 must define its PMAs and the interaction with the cache hierarchy carefully; this is treated in `research/05-memory/cache-coherence.md` and `research/06-io/`.
+
+---
+
+## 3. The 128-Core Scaling Problem
+
+XH-1 has 128 application cores. This dramatically amplifies the cost of any ordering primitive that requires global visibility.
+
+### 3.1 Why Fences Are Expensive
+
+A "global" fence (e.g., `FENCE.RW,RW` that orders against the entire memory system) must wait for:
+
+- All outstanding transactions from the issuing core to be **globally observed** (or at least ordered).
+- The interconnect to drain or acknowledge.
+
+At 128 cores, global observation requires one of:
+
+- A **global counter** that is incremented on every coherence transaction and broadcast on the interconnect, or
+- A **token-based scheme** such as the Token Coherence (Marty et al., 2005) approach, or
+- **Hierarchical fences** that propagate down the directory tree.
+
+A naive "drain the interconnect" fence scales with O(N) (N cores) latency; in practice, on a 128-core mesh this may exceed 100s of ns — sufficient to dominate synchronization hot paths. *This is an estimate; actual latency depends on interconnect topology, link width, and clock frequency — currently unresolved for XH-1.*
+
+### 3.2 The Scalability of Atomics
+
+AMO and SC RMW operations require **directory invalidations** to all sharers and an **acknowledgment** before completion. At 128 cores:
+
+- Worst-case invalidation fanout is bounded by the number of cores (128), but typical working sets are much smaller.
+- **Fairness** and **starvation** become real concerns: a hot lock variable contested by 128 cores will generate enormous traffic. The hardware must not let one core perpetually lose a `SC` against another.
+- **NUMA effects**: if cores are organized in tiles/quads/clusters with distributed directories, an AMO on a remote line costs an extra hop in latency.
+
+### 3.3 False Sharing and Coherence Traffic
+
+A weak memory model encourages fine-grained synchronization, but a 128-core system makes **false sharing** (two cores writing to different bytes of the same line) catastrophically expensive — each write causes an invalidation round-trip. The memory model itself doesn't fix this, but it influences which data structures are used.
+
+### 3.4 Memory-Model Litmus Test Complexity
+
+For verification, the number of distinct observable outcomes of small litmus tests grows combinatorially with core count. The team must be able to run RVWMM test suites (e.g., the official `riscv-tests` and `litmus` suites from Cambridge) and interpret results at 128 cores.
+
+---
+
+## 4. Implementation Approaches and Alternatives
+
+This section discusses candidate mechanisms. **None of these are XH-1 commitments; all are proposals awaiting design review.**
+
+### 4.1 Fence Implementation Strategies
+
+| Strategy | Description | Pros | Cons |
+|----------|-------------|------|------|
+| **Naïve global fence** | Drain the issue queue, snoop outstanding transactions, wait for all acks. | Simple; obviously correct. | O(N) latency; does not scale to 128 cores. |
+| **FIFO completion tags (epoch counters)** | Each request gets a tag; fences compare local tag against a per-core "completed" tag. | Local fences are cheap; correctness well understood. | Global fences still need a global view. |
+| **Hierarchical directory-assisted fences** | Fences consult the directory tree to determine "when is my request globally ordered?" | Latency proportional to tree depth rather than N. | Requires directory tree to maintain completion info. |
+| **Token-based fences** | Borrow from Token Coherence (Marty et al., 2005) — fences consume tokens to know when stores are visible. | Distributed; no single global counter. | Token bookkeeping overhead; complex verification. |
+| **TSO hole** | Implement most of memory as TSO with weak operations for device access only (similar to x86). | Strong ordering for free for ordinary code; simpler programmer model. | Performance penalty for non-synchronization code; deviates from RVWMM. |
+
+**Note:** RISC-V explicitly disallows the TSO-only approach for general memory because the RVWMM is the architectural contract. Any TSO shortcut must be invisible to software.
+
+### 4.2 Store-Buffer and Load-Queue Design
+
+Each core needs:
+
+- **Store Buffer (SB):** holds pending stores until coherence acknowledgment.
+- **Load Queue (LQ):** may replay or forward in case of coherence invalidations.
+
+A common subtle correctness issue: a **store-to-load forwarding** race (a load that reads from a local store buffer entry that is later invalidated by a remote writer). The classic fix is the **MIPS R10000-style** load-queue replay: if a load matches a younger store in the SB, do not forward; if the load issues and a younger store then writes the same address, invalidate the load. A 128-core processor must also handle:
+
+- **Store forwarding across fences** — must respect `FENCE` placement.
+- **Acquired loads vs. earlier stores** — must not forward an acquired load to a store that lacks release semantics.
+- **Speculative load replay** — under invalidation, the LQ must replay; the replay must respect the original memory type (acquired vs. plain).
+
+These are well-known issues from commercial designs (Hennessy & Patterson, *Computer Architecture: A Quantitative Approach*, recent editions; SPARC, Arm, x86 architecture manuals).
+
+### 4.3 Directory Organization
+
+At 128 cores, a **flat broadcast directory** is impractical. The realistic choices are:
+
+- **Hierarchical directory** (cluster of N cores has a local directory; roots form a tree).
+- **Sparse directory** with limited pointers and a coarse bit-vector overflow (e.g., the *Directoryless* / *Incoherence* hybrid, but XH-1 will not be incoherent).
+- **Tagless directory** (Agarwal et al., *Adaptive Caches for Effective Interconnection and Memory Sharing*, 1991-era concepts).
+- **Cuckoo directory** (Zebchuk et al., 2009) for efficient coverage.
+
+XH-1's choice is **currently unresolved**; see `research/05-memory/cache-coherence.md` for a deeper treatment.
+
+### 4.4 Forward-Progress and Livelock Avoidance
+
+LR/SC on RISC-V requires a guarantee that some SC eventually succeeds. At 128 cores:
+
+- **Symmetric fairness** (round-robin arbitration of contested AMO targets) is straightforward but adds latency.
+- **Aging counters** (boost priority of cores that have failed SC) are fairer.
+- **Queue-based fairness** (FIFO ordering of AMO requests at the directory) is the cleanest in the literature.
+
+XH-1 should commit to one and document it precisely; the lack of a fairness spec is a frequent source of bugs in academic designs.
+
+### 4.5 I/O Fences and PMAs
+
+For MMIO regions, XH-1 must define a **PMA** that:
+
+- Marks the region as **non-cacheable** or **device, non-idempotent** (strongly ordered).
+- Requires `FENCE` semantics that ensure completion before subsequent instructions.
+- Possibly exposes `FENCE.I` ordering for self-modifying code in cached regions.
+
+A reasonable proposal (pending review): device regions are marked as **Device, non-idempotent (nGnRnE in Arm terminology)**, requiring `FENCE` and `aq/rl` to be observed with full completion before the next instruction. This is consistent with RISC-V practice but **not yet decided for XH-1**.
+
+---
+
+## 5. Interaction with Other Subsystems
+
+### 5.1 Pipeline
+
+- **Issue width and queue depth** determine how many in-flight loads/stores can be reordered.
+- **Speculative load execution** must be invalidated on branch misprediction *and* on coherence invalidation. The LQ must distinguish these cases.
+- **Fences are pipeline barriers** — they prevent instructions behind the fence from issuing, even out-of-order. A `FENCE.RW,RW` is a full drain; a `FENCE.RW,RW` after a `FENCE.I` is worse. Compiler and hardware should minimize fence use.
+
+### 5.2 Cache Hierarchy
+
+- **Inclusion vs. exclusion** between L1, L2, L3 matters for fence invalidation: a fence does not need to flush the cache, but it does need to ensure stores are visible to the coherence point.
+- **Write-back vs. write-through** L1: write-back hides store latency but complicates fence completion.
+- **LR/SC reservation** must be invalidated on **any** event that could modify the reservation line, including internal writebacks, snoop hits, and external invalidations. The XH-1 spec for reservation invalidation events is **unresolved**.
+
+### 5.3 Memory System
+
+- **DRAM controllers** must respect ordering for writes to the same channel/bank. Modern controllers re-order aggressively; for fence correctness the controller must provide a **write-ordering fence** operation.
+- **Non-temporal stores** (if XH-1 supports them) must be specified carefully to interact correctly with `FENCE` and coherence.
+- **Persistent memory** (if targeted) requires explicit **drain and flush** semantics — e.g., `FENCE` followed by `SFENCE.VMA`-like operations.
+
+### 5.4 Interconnect
+
+- A 128-core system needs a **coherent interconnect** (e.g., a mesh, ring, or hierarchical bus). For ordering:
+
+  - **Ordered virtual channels** ensure that coherence messages from a given source maintain order — required for the protocol to be correct.
+  - **Completion acknowledgment** must be globally ordered to support `FENCE` and `aq/rl` — typically a separate response network or a tagged token system.
+
+- See `research/03-interconnect/` (placeholder).
+
+### 5.5 Coherence
+
+- Memory ordering is a **superset** of coherence: coherence gives per-address order; ordering extends this to multi-address relationships (e.g., a flag write must precede a data write).
+- The coherence protocol (MESI, MOESI, or similar) determines which transitions are **silent** (e.g., a clean shared → shared is silent) and which generate **write notices** to remote cores. Fences interact with these notifications.
+- XH-1's protocol choice is in `research/05-memory/cache-coherence.md` and is currently **proposed** as a directory-based MESI variant.
+
+### 5.6 Interrupts
+
+- An **interrupt** may inject a context switch at any instruction boundary. The OS expects that the interrupted hart's prior memory accesses are visible to the new context once the OS resumes another hart that observes the same state.
+- This requires that:
+  - Interrupt entry be treated as a **fence at the hart** (all prior loads/stores complete before the handler reads shared state).
+  - Interrupt exit (returning from handler) similarly observes a **release fence** before `sret`/`mret`.
+- The RISC-V spec does not mandate this explicitly, but it is the standard interpretation. **XH-1's contract with the OS is unresolved** and must be documented.
+
+### 5.7 Operating System
+
+- The OS port (likely Linux) requires:
+  - **I/O fences** around MMIO.
+  - **Acquire/release** semantics for `spin_lock`, RCU, seqlocks, etc.
+  - **TLB shootdown** ordering with respect to page-table updates (the famous "shootdown TLB entry, then update PTE" hazard).
+  - **SMP boot** synchronization using `hartip` (per RISC-V HSM extension).
+- Linux on RISC-V uses `.aq`/`.rl` extensively. **XH-1's conformance with these patterns is mandatory for Linux to boot**.
+
+### 5.8 Verification
+
+- Memory model verification is famously hard. The state of the art includes:
+  - **Litmus test execution** (e.g., the Cambridge `litmus` tool, herd7).
+  - **Model checking** with tools like **MemSAT**, **CBMC** with memory-model plugins.
+  - **Theorem proving** (Coq/Isabelle) for protocol proofs.
+  - **Stress testing** with random instruction streams.
+- At 128 cores, **scalability** of these tools is a concern — herd7 works on axiomatic models, not microarchitectures; we need a model that can express XH-1's specific microarchitecture (queue sizes, replay rules, fence completion).
+- **Coverage:** the team must run the official `riscv-tests` plus internally generated tests.
+- This document is deliberately conservative: the XH-1 microarchitecture is not yet specified, so formal verification of the model against the RTL is not currently scheduled.
+
+### 5.9 Performance
+
+- **Ordering cost** can dominate the runtime of synchronization-heavy workloads. Microbenchmarks to consider:
+  - Empty lock acquire/release round-trip.
+  - Producer-consumer queue latency.
+  - Atomic increment latency under contention.
+  - `FENCE` latency under no traffic vs. saturated interconnect.
+- Quantitative target (proposal, not requirement): empty lock round-trip should be **< 100 ns** on the XH-1 interconnect. *This is not yet validated against a specific frequency or topology.*
+- A 128-core chip that pays a 500 ns fence on every lock release would be uncompetitive on database, OS kernel, and runtime benchmarks. **The fence implementation strategy (§4.1) is therefore a first-order performance decision.**
+
+---
+
+## 6. Advantages and Disadvantages of a Pure RVWMM Approach
+
+### 6.1 Advantages
+
+- **Standards compliance:** software written for any RISC-V hart runs correctly.
+- **Compiler freedom:** the compiler can reorder aggressively for sequential regions.
+- **Hardware freedom:** out-of-order and speculation are unconstrained except where fences demand otherwise.
+- **Industry alignment:** Arm's success with a release-consistency model demonstrates viability.
+
+### 6.2 Disadvantages
+
+- **Programmer burden:** subtle bugs arise from missing fences (e.g., the famous "Dekker's" patterns).
+- **Performance cliffs:** adding one missing fence may inflate latency by orders of magnitude.
+- **Verification cost:** weak models have more behaviors to test.
+- **OS porting:** subtle bugs in porting Linux locking primitives have historically caused real defects (e.g., the itanium `mf` model, various Arm power-management races).
+
+### 6.3 Alternatives Considered
+
+- **TSO-everywhere (x86-style):** better programmer intuition, lower fence overhead for common cases, but contradicts RVWMM and is performance-suboptimal for non-synchronization code. **Rejected** for a fresh RISC-V design.
+- **Sequential consistency (SC):** simplest model, but **incompatible with RISC-V**, which explicitly defines a weaker model.
+- **C++ memory model directly in hardware:** not realistic; the hardware must support whatever language the compiler emits.
+
+---
+
+## 7. Identified Design Questions for XH-1
+
+The following are **unresolved** and require design review before commitment:
+
+1. **Fence completion mechanism:** epoch counters vs. directory-assisted vs. token-based?
+2. **LR/SC reservation invalidation events:** which coherence events break a reservation?
+3. **Forward-progress fairness policy:** round-robin, aging, or queue-based?
+4. **PMA definition for I/O regions:** which regions are device, cacheable, idempotent?
+5. **Interrupt-entry fence semantics:** what guarantee does the OS get?
+6. **Speculative load replay rules:** under what conditions is a load replayed, and how does it interact with `aq/rl`?
+7. **Store-buffer forwarding rules:** what is the legal forwarding window?
+8. **Verification tool selection and test plan:** what coverage is required for tape-out?
+9. **Performance budgets:** what is the acceptable empty-fence latency?
+10. **Interaction with HSM (Hart State Management):** the SBI HSM extension has its own ordering requirements for hart start/stop.
+
+---
+
+## 8. Recommendations (Pending Evidence)
+
+The following are conditional recommendations, contingent on design review and simulation:
+
+- **Adopt the RISC-V RVWMM verbatim** for the architectural contract. There is no compelling reason to invent a custom model.
+- **Implement fences with a hierarchical directory-assisted scheme** to maintain reasonable latency at 128 cores; validate via cycle-accurate simulation once the interconnect is defined.
+- **Specify LR/SC reservation invalidation events** as a precise list in a follow-up document, including: snoop invalidation, snoop downgrade, internal writeback to memory, software `SC` failure injection.
+- **Adopt a queue-based fairness policy for AMO arbitration** to bound worst-case starvation under high contention.
+- **Mark I/O regions as Device, non-idempotent (nGnRnE-equivalent)** and require `FENCE` for completion. *Pending review.*
+- **Commit to a verification plan** that includes the official `riscv-tests` RVWMM suite, internally generated litmus tests, and a formal axiomatic model expressed in herd7's `cat` language.
+- **Document the interrupt-entry fence semantics** explicitly in the privileged ISA supplement.
+
+These are proposals. None are committed XH-1 features until design review.
+
+---
+
+## 9. References and Sources
+
+- RISC-V International, *The RISC-V Instruction Set Manual, Volume I: Unprivileged Architecture*, Document Version 20191213, Appendix A: "RVWMM: RISC-V Weak Memory Model." [Specification; no URL fabricated — see riscv.org/technical/specifications/]
+- RISC-V International, *Volume II: Privileged Architecture*, HSM Extension.
+- Adve, S. V., & Gharachorloo, K. (1996). "Shared Memory Consistency Models: A Tutorial." *IEEE Computer*.
+- Sorin, D. J., Hill, M. D., & Wood, D. A. (2011). *A Primer on Memory Consistency and Cache Coherence.* Morgan & Claypool. (Synthesis lectures in computer architecture.)
+- Hennessy, J. L., & Patterson, D. A. *Computer Architecture: A Quantitative Approach.* 5th/6th editions. (A definitive reference; specific page numbers not cited to avoid fabrication.)
+- Marty, M. R., et al. (2005). "Token Coherence: Decoupling Performance and Correctness." *ISCA 2005.*
+- Zebchuk, J., et al. (2009). "Cuckoo Directory: A Scalable Directory for Many-Core Systems." *HPCA 2009.*
+- Agarwal, A., et al. (1991). "Adaptive Caches for Effective Interconnection and Memory Sharing." *ISCA 1991.*
+- Arm Architecture Reference Manual, Armv8-A, §B2.3 "Memory ordering." (For comparison.)
+- SPARC Architecture Manual, §8 "Memory Model." (Historical reference for TSO/RMO.)
+- The herd7 / diy7 tool suite, Cambridge. (Used for axiomatic memory-model analysis of RISC-V.)
+- `riscv-tests` repository. (Official test suite; see github.com/riscv-software-src/riscv-tests.)
+
+Where URLs are not provided above, the reader should consult the official source rather than rely on a possibly stale or fabricated link.
+
+---
+
+## 10. Document Status
+
+This is a **research document**, not a specification. It does not commit XH-1 to any specific implementation. It identifies the RISC-V architectural contract (RVWMM) that XH-1 must respect and surveys the implementation alternatives and tradeoffs. The unresolved questions in §7 must be addressed in follow-up design documents before any RTL is committed.