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
    • Shared Media and Topologies
    • Arbitration Policies
    • Fairness and Starvation
    • Priority Inversion
    • Arbitration Granularity
    • Distributed Arbitration
    • Quality of Service
    • Virtual Channels
    • Routing
    • Multicast and Broadcast
    • Protocols Compared: Sharing and Arbitration
    • Drills: Sharing and Arbitration
  • 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
  • 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 8: Sharing and Arbitration

Part 8 · Sharing and Arbitration · All levels

Part 8: Sharing and Arbitration

Who gets the wire? Design a round-robin arbiter and prove it cannot starve anyone.

  • 12topics
  • 12lessons
On this page

    Part 8 answers: Who gets the wire?

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

    As soon as two requesters share a wire, a port or a buffer, something must decide who goes first. That decision sets fairness, latency for the urgent, and whether anyone can starve.

    This part covers topologies, arbitration policies, fairness and starvation, priority inversion, arbitration granularity, distributed arbitration, quality of service, virtual channels, routing and broadcast.

    After this part you can

    • Design a round-robin arbiter and prove it cannot starve anyone.

    • Explain how two I2C masters resolve a collision.

    • Say what a virtual channel buys.

    Warm-up: three questions from Part 7

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

    Check yourself Give the data-then-flag problem in one sentence.

    If the write that sets a ready flag can overtake the write of the data, a consumer can see the flag and read stale data.

    Check yourself What does a fence do?

    It stops later operations from becoming visible before earlier ones have, forcing order where the protocol would otherwise allow overtaking.

    Check yourself Does a write response always mean the data reached its final destination?

    No. Many protocols allow an early response from a buffer on the way; what it promises depends on the protocol and the attributes of the write.

    Lessons

    #

    Lesson

    Level

    Status

    8.1

    Shared Media and Topologies

    W · Working

    Ready

    8.2

    Arbitration Policies

    F · Foundation

    Ready

    8.3

    Fairness and Starvation

    W · Working

    Ready

    8.4

    Priority Inversion

    S · Senior

    Ready

    8.5

    Arbitration Granularity

    W · Working

    Ready

    8.6

    Distributed Arbitration

    W · Working

    Ready

    8.7

    Quality of Service

    S · Senior

    Ready

    8.8

    Virtual Channels

    S · Senior

    Ready

    8.9

    Routing

    S · Senior

    Ready

    8.10

    Multicast and Broadcast

    P · Principal

    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.

    Tip

    DCLink in this part. Step 7: two requesters and a round-robin arbiter. DCLink is the small protocol you build across the course; see How to use this course.

    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.

    • RTL: Arbitration

    • Architecture: Arbitration Policies and QoS

    Related topics

    • Course hub

    • Previous: Part 7 · Ordering

    • Next: Part 9 · Deadlock and Liveness

    PreviousNext: Shared Media and Topologies

    Up next

    Up nextShared Media and Topologies

    Sign in to save progress

    Practice this lessonReport an error

    See also

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