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
    • Transient States and Races
    • Controller Resources
  • 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

‹Cache Coherency
  1. Topics
  2. Cache Coherency
  3. Races and Controller Design

Part 4 · Races and Controller Design · All levels

Races and Controller Design

Resolve overlapping coherent requests and implement their obligations with finite protected resources.

  • 2topics
  • 8lessons

Topics in this section

  1. 1Transient States and Races4 lessons
    • Why Transient States Exist
    • Simultaneous Upgrades
    • Racing Requests at the Home
    • Eviction Versus Intervention
  2. 2Controller Resources4 lessons
    • MSHRs and Pending Entries
    • Ack Counting and Late Data
    • Retries, NACKs and Credits
    • A Controller Block Diagram

A legal serial transaction is not a complete controller design. Requests, evictions and responses can overlap, and data can leave a cache array before H has taken it over. This section chooses explicit policies for those overlaps, then maps the obligations into resources.

Learning sequence from transient facts and competing requests to eviction buffers and safe controller resource lifetimes.
Study the races before choosing the resources that must preserve them.

Eight lessons

Lesson

After it you can...

Why Transient States Exist

Name retained facts, missing facts and the event that completes a request.

Simultaneous Upgrades

Invalidate a losing upgrader while retaining its store intent.

Racing Requests at the Home

Explain why an ordered request does not imply delivered permission, and handle an Inv or Fwd that arrives before Data.

Eviction Versus Intervention

Resolve both arrival orders using protected data and matching releases.

MSHRs and Pending Entries

Separate core operation state from home transaction state.

Ack Counting and Late Data

Require both completed revocations and authoritative data.

Retries, NACKs and Credits

Distinguish interface capacity from acceptance and permission.

A Controller Block Diagram

Place retained obligations in explicit protected resources.

Suggested order: transient states and races first, controller resources second. Every race names who wins, who waits and which data remains protected.

Common pitfall

A controller that handles ordinary S-to-M upgrades may still fail when the requesting S copy is invalidated while waiting. Pending facts must change when incoming protocol events change the data and permissions.

Check yourself Why is 'the old tag is I' insufficient evidence that an intervention can return no data?

The controller may still hold the only current value in a writeback (WB) entry. An incoming Fwd must search the WB entries, not only the array tags.

Related topics

  • Shared model and completion assumptions

  • Prerequisite: Transactions

  • Start: transient states and races

PreviousNext: Transient States and Races

Up next

Up nextTransient States and Races

Sign in to save progress

Practice this lessonReport an error

See also

  • How to Use This Course
  • Reading Path
  • Cache Coherency Glossary