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
    • Read and Write-Permission Flows
      • Cold Read Miss
      • Read of a Shared Line
      • Write Miss and Ownership
      • Upgrade from Shared
    • Forwarding Versus Memory Sourcing
    • Writeback, Eviction and Cleaning
  • Races and Controller Design8
  • Progress and the Fabric16
  • Ordering and Synchronization12
  • 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

‹Read and Write-Permission Flows
  1. Topics
  2. Cache Coherency
  3. Transactions
  4. Read and Write-Permission Flows
  5. Upgrade from Shared

Part 3 · Transactions · All levels

Upgrade from Shared

Distinguish retaining data from acquiring permission and identify the exact acknowledgement boundary.

On this page

    What is missing when the bytes already hit?

    A cache hit is not necessarily a writable hit. With S / 0, C0 can read X but cannot modify it while C1 also reads it. Here the question is which part of the miss service is absent: no data refill is needed.

    Trace: Epochs and Serialization. Same roles: from the MSI checkpoint C0 S / 0, C1 S / 0, H S{C0,C1}, memory = 0, C0 sends GetM and keeps its read-only value while waiting in SM^D (loads hit, stores stall). H sends Inv to C1, C1 answers Inv-Ack to H, and H grants M with permission-only Data. Four serial legs, because acks go to H, and memory is not involved.

    The step that matters here is the last one. The grant carries no line: it gives C0 write permission and dirty responsibility for bytes C0 already holds, even before a local store changes any bits.

    What an upgrade optimisation assumes

    The permission-only response is safe because C0's S copy stayed valid throughout this transaction. If C0 lost its copy while waiting, this no-refill path could not complete as drawn: the request would need data. That race is handled later in the course. Never assume the requester still holds data merely because its request was an upgrade.

    Fewer bytes is not fewer messages: removing the refill does not remove the invalidation round trip. Neither a fixed delay nor a shared value of 0 can replace the Inv-Ack.

    Common pitfall

    With acks collected at H (this course), H must not grant until the Inv-Ack arrives. The Primer instead sends Data with an ack count and the requester waits for the acks itself (SM^AD). Both are legal. Granting usable M before any ack is the bug.

    Interview

    Identify the optimisation narrowly: the retained copy avoids a refill. It does not remove the need to acquire exclusive permission or to collect every Inv-Ack.

    Check yourself If C0 loses its S copy before the grant (step 4 of the Part 1 trace) arrives, can permission-only Data recreate its value?

    No. A grant carries permission, not the missing bytes. The controller must notice that case and fetch the data or retry. This example excludes that race.

    Related topics

    • Shared course model

    • Trace: Epochs and Serialization

    • Compare: a write miss also needs data

    Previous

    29 / 167

    Next: Forwarding Versus Memory Sourcing

    Up next

    Up nextForwarding Versus Memory Sourcing

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Cold Read Miss
    • Read of a Shared Line