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
    • Forwarding Versus Memory Sourcing
    • Writeback, Eviction and Cleaning
      • Dirty Writeback
      • Clean Eviction: Silent or Notified
      • Writeback Buffers
      • Cache Maintenance Operations
  • 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

‹Writeback, Eviction and Cleaning
  1. Topics
  2. Cache Coherency
  3. Transactions
  4. Writeback, Eviction and Cleaning
  5. Cache Maintenance Operations

Part 3 · Transactions · All levels

Cache Maintenance Operations

Define clean, invalidate and clean-and-invalidate by what happens to the data, the target level and completion.

On this page

    Why does software ever need to manage a coherent cache?

    Coherence keeps caches consistent with each other, but only for agents inside the coherence domain. A DMA device that does not snoop reads and writes memory directly, so software must clean dirty lines before the device reads a buffer and invalidate stale copies after the device writes it. Code written with ordinary stores must also reach the level that instruction fetch reads (instruction and data unification). Persistent memory adds a third reason: data must leave the volatile caches before it can be called durable.

    What does 'flush' actually promise?

    Nothing precise until you name the operation, its target level and its completion. Clean writes a dirty value to the target and may keep a copy. Invalidate removes the local copy. Clean-and-invalidate does both. None of them is a memory-ordering barrier. This lesson defines course operations, not ISA instructions.

    Target level (Arm names)

    Meaning

    Point of coherence

    The level where every agent that can access the location, all cores and DMA devices, sees the same copy.

    Point of unification

    The level where one core's instruction fetch, data accesses and translation table walks see the same copy.

    These are Arm's names. Other ISAs scope their maintenance operations differently. In this two-core model, memory serves as the target.

    Clean-and-invalidate of a dirty line

    Warm start (MSI): X started at 0, C0 acquired M and stored 6. C0 M / 6, C1 I / -, H exclusive(C0), memory = 0. Software asks C0 to clean-and-invalidate X to memory. C0 stops local access and evicts the line with PutM. H writes memory, then sends Put-Ack. For this maintenance operation the course chooses Put-Ack after memory has accepted the write, so Put-Ack is the completion C0 reports to software.

    C0 moves six into a WB entry and sends PutM. H writes six to memory, then acknowledges. C0 frees the WB entry and reports the operation complete.
    Clean-and-invalidate to memory: Put-Ack after the memory write is the completion C0 reports.

    Step

    C0 state / value

    C1 state / value

    H directory

    Memory

    Newest data

    0. Warm start

    M / 6

    I / -

    exclusive(C0)

    0

    C0: 6

    L. Clean-and-invalidate starts

    MI^A / 6 (in WB)

    I / -

    exclusive(C0)

    0

    C0 WB entry: 6, PutM(6) in flight to H

    1. PutM at H

    MI^A / 6 (in WB)

    I / -

    exclusive(C0), pend PutM C0

    0

    C0 WB entry and H buffer: 6

    H writes memory

    MI^A / 6 (in WB)

    I / -

    U

    6

    C0 WB entry and memory: 6

    2. Put-Ack at C0, complete

    I / -

    I / -

    U

    6

    memory: 6

    A real ISA defines how completion becomes visible to software, often through a barrier that waits for outstanding maintenance operations.

    Operation

    Effect on C0's copy

    What happens to the data

    Clean

    MSI: M / 6 becomes S / 6 and H records S{C0}, after memory = 6 (MESI may keep E)

    The dirty value is written to the target before the operation completes.

    Invalidate

    The copy becomes I / -

    On some architectures a plain invalidate of a dirty line may discard the data. Use clean-and-invalidate unless the buffer is known clean.

    Clean-and-invalidate

    M / 6 becomes I / -

    The value is written to the target (PutM, memory write, Put-Ack) before the operation completes.

    Barrier

    No state change

    On many architectures software issues a barrier after maintenance to wait for its completion before signalling a device (general guideline, the ISA defines it).

    A by-address clean or invalidate to the point of coherence must reach every holder in the domain. If C1 held M / 6, H would forward to C1 and collect its data before completing. Agents outside the coherence domain see the result only once the operation completes at the target.

    Common pitfall

    Reporting a maintenance operation complete when PutM is sent, or when the WB entry is merely reserved. In this trace completion is Put-Ack, which arrives only after memory holds 6.

    Interview

    Replace 'flush it' with a precise contract: which addresses, which copies, which target level, what tells software it is complete, and which barrier orders it before the device is signalled.

    Check yourself At step 1, may C0 tell software that memory contains 6?

    No. The table still shows memory = 0. Memory holds 6 only after H writes it, and C0 learns that only when Put-Ack arrives at step 2.

    Related topics

    • Shared course model

    • Eviction transient states

    • The PutM sequence

    Previous

    37 / 167

    Next: Races and Controller Design

    Up next

    Up nextRaces and Controller Design

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Dirty Writeback
    • Clean Eviction: Silent or Notified