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

‹Part 8: Sharing and Arbitration
  1. Topics
  2. First Principles of Hardware Protocols
  3. Part 8: Sharing and Arbitration
  4. Drills: Sharing and Arbitration

Part 8 · Sharing and Arbitration · All levels

Drills: Sharing and Arbitration

Interview questions, a whiteboard exercise and a ten-question checkpoint for Part 8.

On this page

    Answer each question out loud before opening it. If you miss more than three in the checkpoint, revisit the lessons linked at the end.

    Interview questions

    Check yourself When does a crossbar stop being sensible?

    When its N² crosspoints and die-spanning wires outrun area and timing, typically in the tens of ports; then a mesh or hierarchy wins.

    Check yourself Design a 4-way round-robin arbiter.

    Keep a pointer to the last winner; grant the first asking requester after it, wrapping; move the pointer to the winner.

    Check yourself Can fixed priority ever be fair?

    Only if higher-priority traffic is rate-bounded; otherwise lower requesters can starve.

    Check yourself How can a locked transfer starve the CPU?

    The CPU waits on the held resource, not on arbitration; if the holder is slow or preempted by medium traffic, the wait is unbounded.

    Check yourself Should the arbiter switch mid-burst?

    Per beat cuts waiting but needs interleaving; per burst is simpler, so cap burst length on shared links.

    Check yourself How do two I2C masters resolve a collision?

    Wired-AND SDA; each reads back every bit; driving 1 but reading 0 means lost, so it stops; the winner's bits are intact.

    Check yourself How would you guarantee display latency next to a GPU?

    Class plus priority with ageing, a token bucket on the GPU, reserved queue slots or a VC for the display, capped bursts, and a hop-by-hop latency budget.

    Check yourself Why is XY routing deadlock-free?

    It never turns from Y back to X, and every cycle in a mesh needs such a turn.

    Whiteboard exercise

    Task. Eight agents share a memory port: one display (2 GB/s, 1 µs worst latency), one GPU (bulk), and six CPU clusters (latency-sensitive, moderate bandwidth). The port moves 25 GB/s. Design the arbitration and QoS.

    Check yourself Open a model answer

    Three classes: real-time (display), latency-sensitive (CPUs), bulk (GPU). At the port: strict priority for real-time but with a token bucket at about 2.5 GB/s so it can never starve others; weighted round-robin between CPUs and GPU, CPUs weighted higher, with ageing so the GPU always progresses. Reserve a few queue slots for the display and for CPUs so neither waits behind queued GPU traffic. Regulate the GPU (say 18 GB/s average, bounded burst) to keep total demand below the memory's sustained bandwidth and its queues short. Cap bursts at 16 beats on the shared path so a grant cannot hold the port long. Budget the display's worst latency: one capped burst in progress plus the memory controller's latency at expected load, and verify with a saturating GPU and CPU load.

    Checkpoint: ten questions

    Check yourself 1. How do a crossbar's and a mesh's costs grow with agents?

    Crossbar N²; mesh N, with about √N hops.

    Check yourself 2. What two safety rules must every arbiter keep?

    At most one grant per resource per cycle, and only to requesters that ask.

    Check yourself 3. Round-robin among 6: worst wait in grants?

    5.

    Check yourself 4. What is priority inversion?

    A high-priority requester waits on a low-priority holder that is kept from finishing by medium-priority traffic.

    Check yourself 5. Worst wait under per-burst arbitration?

    Grants to others times the longest burst.

    Check yourself 6. In wired-AND arbitration, which value wins?

    The dominant value, 0.

    Check yourself 7. Why must high priority come with a rate limit?

    So a misbehaving high-priority source cannot starve everything else.

    Check yourself 8. What does a virtual channel cost?

    A buffer sized for its credit loop, a credit loop, arbitration and allocation, and a VC field.

    Check yourself 9. What turn does XY routing forbid?

    From Y back to X.

    Check yourself 10. Why does broadcast scale badly?

    N − 1 messages (often plus answers) per event, and events grow with N too.

    Revisit

    • 8.1 Shared Media and Topologies

    • 8.2 Arbitration Policies

    • 8.3 Fairness and Starvation

    • 8.4 Priority Inversion

    • 8.5 Arbitration Granularity

    • 8.6 Distributed Arbitration

    • 8.7 Quality of Service

    • 8.8 Virtual Channels

    • 8.9 Routing

    • 8.10 Multicast and Broadcast

    Keep going

    Next: Part 9: Deadlock and Liveness. Why can it hang, and how do you prove it won't?

    Previous

    128 / 234

    Next: Part 9: Deadlock and Liveness

    Up next

    Up nextPart 9: Deadlock and Liveness

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Shared Media and Topologies
    • Arbitration Policies
    • Fairness and Starvation