Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Course
  • Reading Path
  • Cache Coherency Glossary
  • The Shared Course Model
  • Cache Coherency Revision Sheet
  • Why Coherence Exists8
  • States and Protocols12
  • Transactions12
  • Races and Controller Design8
  • Progress and the Fabric16
  • Ordering and Synchronization12
    • Memory Models and Protocols
      • Coherence Is Not Consistency
      • SC, TSO and Store Buffers
      • Litmus Tests: SB and MP
      • Weak Models: Arm and RISC-V
    • Barriers, Fences and Completions
    • Speculation, Replay and Recovery
  • Performance and Scalability12
  • Real Protocols12
  • SoC Integration12
  • Power, Clocking and Reliability12
  • Verification12
  • Debug and Bring-up12
  • Interview and Design Review17
  • Capstone: A Coherent Model Lab5
Loading lesson

‹Memory Models and Protocols
  1. Topics
  2. Cache Coherency
  3. Ordering and Synchronization
  4. Memory Models and Protocols
  5. Weak Models: Arm and RISC-V

Part 6 · Ordering and Synchronization · All levels

Weak Models: Arm and RISC-V

Read architectural preserved-order rules without confusing a weak model with broken coherence.

On this page

    What must be named before calling an outcome legal?

    Name the architecture/model, instruction forms, memory type, initial values and ordering constructs. 'A weak CPU can reorder anything' is not a specification. Weak models preserve particular dependencies, same-location constraints and synchronization relationships; the exact rules matter.

    Published model

    Reference

    Question to ask

    Armv8-A AArch64 architectural memory model

    Arm Architecture Reference Manual for A-profile architecture (DDI 0487), chapter "The AArch64 Application Level Memory Model"

    Which loads/stores, dependencies and barriers constrain the execution?

    RISC-V RVWMO, version 2.0

    RISC-V Unprivileged ISA specification, chapter "RVWMO Memory Consistency Model"

    Which preserved-program-order, load-value and atomicity rules apply?

    RISC-V Ztso / RVTSO

    A separately selected stronger architectural contract

    Is the implementation actually claiming this extension rather than baseline RVWMO?

    These are architectural contracts, not vendor pipeline claims. Use the published formal model and a matching litmus tool to decide architecture-specific cases, and record its version and test encoding.

    SB and MP on the four models

    Reuse SB and MP from the previous lesson: X and Y in separate lines, X = Y = 0 initially, C0 and C1 using plain loads and stores.

    Model, X = Y = 0 initially, plain loads and stores, no fences or dependencies

    SB r1 = r2 = 0

    MP r1 = 1, r2 = 0

    SC

    Forbidden

    Forbidden

    TSO

    Allowed

    Forbidden

    Armv8-A

    Allowed

    Allowed

    RVWMO

    Allowed

    Allowed

    Under Armv8-A and RVWMO the writer's two stores to different addresses may become visible out of order, and the reader's two loads may be performed out of order. MP needs ordering on both sides. A shareability domain is the set of agents an ordering applies to; ISH, inner shareable, covers all the cores of a normal coherent system.

    MP side

    Armv8-A

    RVWMO

    Writer, between W(X) and W(Y)

    DMB ISH, or make W(Y) a store-release STLR

    FENCE w,w, or make W(Y) an amoswap with .rl

    Reader, between R(Y) and R(X)

    DMB ISH, LDAR for R(Y), or an address dependency from r1 to R(X)

    FENCE r,r, make R(Y) an LR or AMO with .aq (base loads carry no .aq bit), or an address dependency from r1 to R(X)

    Multi-copy atomicity and the protocol

    Armv8-A is other-multi-copy-atomic (since the 2017 revision of the Arm ARM): a store seen by one other core is seen by all others. The issuing core may see its own store early through forwarding from its store buffer. RVWMO is multi-copy atomic in the same sense. The invalidation protocol of this course provides that property directly: H collects every Inv-Ack before granting M, so once any core can read the new value from the M copy, no other cache can still return the old one. An update protocol, which pushes new values to sharers one at a time, or a store buffer shared between hardware threads of one core can break it. The IRIW litmus test (independent reads of independent writes) detects the difference: two readers that disagree about the order of two writes to different locations.

    Workflow identifies model, instructions and ordering rules before checking a candidate execution or hardware observation.
    Architecture-specific outcome claims need an exact test and model, not a guessed pipeline.

    Coherence invariants remain necessary underneath the architecture. A protocol that loses X's dirty value is not excused by weak ordering. Conversely, a weak-model-allowed observation is not proof that a cache supplied the wrong epoch value. A useful review keeps those two failure categories separate.

    Common pitfall

    Presenting a non-atomic C/C++ data race as a direct test of the hardware memory model. Compiler transformations and language semantics must be specified; the course uses abstract hardware operations unless it explicitly names a language mapping.

    Interview

    Ask for the instruction-level litmus before answering. State what the architecture promises, then distinguish that from one implementation's speculation or buffering choices.

    Check yourself Under RVWMO, does FENCE w,w on the writer alone forbid MP r1 = 1, r2 = 0?

    No. The reader's two loads may still be performed out of order. The reader also needs FENCE r,r, .aq on the flag load, or an address dependency from the flag value to the payload load.

    Related topics

    • Shared course model

    • Scope of the executable SC/TSO examples

    Previous

    65 / 167

    Next: Barriers, Fences and Completions

    Up next

    Up nextBarriers, Fences and Completions

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Coherence Is Not Consistency
    • SC, TSO and Store Buffers