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 Paths
  • Concept Map
  • How to Read the Diagrams
  • Part 0: What Is a Protocol?10
  • Part 1: Timing and Clocking11
  • Part 2: Encoding and Framing12
  • Part 3: Handshakes13
  • Part 4: Flow Control17
  • Part 5: Transactions19
  • Part 6: Concurrency and Performance17
  • Part 7: Ordering13
  • Part 8: Sharing and Arbitration12
  • Part 9: Deadlock and Liveness13
  • Part 10: Reliability and Recovery20
  • Part 11: Bring-Up and Link Management10
  • Part 12: Power8
  • Part 13: Shared State and Coherence9
    • Why Coherence
    • Invalidate or Update
    • MSI, MESI and MOESI
    • Snooping or Directory
    • Ownership and Forwarding
    • Coherence and Consistency
    • I/O Coherence and Cache Maintenance
    • Protocols Compared: Shared State and Coherence
    • Drills: Shared State and Coherence
  • Part 14: Security and Isolation7
  • Part 15: Specifying and Verifying11
  • Part 16: Protocols Dissected17
  • Part 17: Capstones5
  • Part 18: Interview Preparation6
Loading lesson

‹First Principles of Hardware Protocols
  1. Topics
  2. First Principles of Hardware Protocols
  3. Part 13: Shared State and Coherence

Part 13 · Shared State and Coherence · All levels

Part 13: Shared State and Coherence

What if there are several copies of one value? State the single-writer, multiple-reader invariant.

  • 9topics
  • 9lessons
On this page

    Part 13 answers: What if there are several copies of one value?

    Where Part 13 sits among the fifteen questions of the course.

    Caches make copies. Copies go stale. A coherence protocol is the set of messages that keeps every copy of a location consistent with the single-writer, many-readers rule. This part teaches the concepts; the Cache Coherency course holds the protocol detail.

    This part covers why coherence is needed, invalidate versus update, MSI to MOESI, snooping versus directories, ownership and forwarding, coherence versus consistency, and I/O coherence.

    After this part you can

    • State the single-writer, multiple-reader invariant.

    • Say what each MESI state adds.

    • Explain when snooping stops scaling.

    Warm-up: three questions from Part 12

    Answer each in your head before opening it. If two or more feel shaky, revisit Part 12: Power first.

    Check yourself What is break-even time?

    The shortest idle period for which entering a low-power state saves more energy than the entry and exit cost.

    Check yourself Why drain outstanding transactions before powering down?

    A transaction in flight when power goes away is lost or corrupted, and the side waiting for it may hang.

    Check yourself Why may a device deny a power-down request?

    It still has work in flight or is about to receive some; denying keeps the request from cutting it off mid-transaction.

    Lessons

    #

    Lesson

    Level

    Status

    13.1

    Why Coherence

    W · Working

    Ready

    13.2

    Invalidate or Update

    W · Working

    Ready

    13.3

    MSI, MESI and MOESI

    W · Working

    Ready

    13.4

    Snooping or Directory

    S · Senior

    Ready

    13.5

    Ownership and Forwarding

    S · Senior

    Ready

    13.6

    Coherence and Consistency

    S · Senior

    Ready

    13.7

    I/O Coherence and Cache Maintenance

    S · Senior

    Ready

    —

    Protocols compared

    all levels

    Ready

    —

    Drills and checkpoint

    all levels

    Ready

    Every lesson in this part is ready. Work through them in order: each one sets up the problem the next one solves.

    Where other courses go deeper

    This course teaches why protocols are designed the way they are. These lessons show how to build or sign off the same ideas, so this part links to them instead of repeating them.

    • Architecture: Memory Ordering Models

    Related topics

    • Course hub

    • Previous: Part 12 · Power

    • Next: Part 14 · Security and Isolation

    PreviousNext: Why Coherence

    Up next

    Up nextWhy Coherence

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • How to Use This Course
    • Reading Paths
    • Concept Map