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

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

Part 3 · Transactions · All levels

Writeback, Eviction and Cleaning

Evict lines without losing data, compare notified and silent clean eviction, and define cache maintenance by its target.

  • 4topics
  • 4lessons

Freeing a cache-array entry does not end a line's obligations. A dirty value can outlive its array entry in a writeback (WB) entry, and H's directory must either be told about a clean eviction or accept a stale sharer bit. This topic follows each case value by value.

Eviction transient states

An evicting cache sends PutS, PutE or PutM and then waits for Put-Ack. While it waits it is in one of the states below (the Primer's names). The lessons in this topic use them in their tables.

State

Meaning

While waiting for Put-Ack

MI^A

Was M, wants I, waits for Put-Ack

The WB entry keeps the dirty data. Local loads and stores to X stall.

SI^A

Was S, wants I, waits for Put-Ack

Local loads and stores to X stall. Memory is current, so nothing is lost.

EI^A

Was E (MESI, MOESI), wants I, waits for Put-Ack

Local loads and stores to X stall. Memory is current because the line was E, not M.

II^A

Lost the line to a Fwd-GetM or Inv while waiting

No copy and no permission. The cache still waits for Put-Ack before X is free.

A cell such as MI^A / 3 (in WB) means C0 is in MI^A and its WB entry holds 3: the array entry is already free. A Put from a cache that H no longer records as a holder gets Put-Ack without changing the directory or memory. Generation tags that match a Put-Ack to one particular eviction are an optional implementation detail covered in Part 4.

Lesson

After it you can...

Dirty Writeback

Say where a dirty value lives at each step of PutM, memory write and Put-Ack.

Clean Eviction: Silent or Notified

Compare PutS and PutE with silent eviction and its stale sharer bit.

Writeback Buffers

Keep a WB entry until Put-Ack, and stall when none is free.

Cache Maintenance Operations

Distinguish clean, invalidate and clean-and-invalidate by target and completion.

Read in order after the request and sourcing topics. The maintenance lesson uses course-defined operations, not the instructions of a particular ISA.

Check yourself Can C0's cache array lose X while C0 still owes the data?

Yes. After an M line is evicted, C0 is in MI^A: the array entry is free, but the WB entry holds the dirty value and C0 must answer requests for X from it until Put-Ack arrives. Freeing the WB entry earlier can lose the only copy.

Related topics

  • Shared course model

  • Prerequisite: who may supply data

PreviousNext: Dirty Writeback

Up next

Up nextDirty Writeback

Sign in to save progress

Practice this lessonReport an error

See also

  • Read and Write-Permission Flows
  • Forwarding Versus Memory Sourcing