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
    • Why Flow Control
    • On/Off Flow Control
    • Credit-Based Flow Control
    • Credit Initialisation
    • The Credit Loop and Buffer Sizing
    • Credit Classes and Pools
    • Credit Return Latency and Batching
    • Credit Bugs
    • Window Flow Control
    • Rate-Based Shaping
    • Hop-by-Hop or End-to-End
    • Lossless or Lossy
    • Switching Modes
    • Head-of-Line Blocking
    • Choosing Flow Control
    • Protocols Compared: Flow Control
    • Drills: Flow Control
  • 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
  • Part 14: Security and Isolation7
  • Part 15: Specifying and Verifying11
  • Part 16: Protocols Dissected17
  • Part 17: Capstones5
  • Part 18: Interview Preparation6
Loading lesson

‹Part 4: Flow Control
  1. Topics
  2. First Principles of Hardware Protocols
  3. Part 4: Flow Control
  4. Drills: Flow Control

Part 4 · Flow Control · All levels

Drills: Flow Control

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

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 Why not use valid/ready across a 10-cycle link?

    Ready would reach the sender ten cycles late, so up to a round trip of words would arrive after the receiver filled. Every stage would need a skid buffer. Credits let the sender know in advance how much room there is, with the buffer concentrated at the receiver.

    Check yourself Explain credit-based flow control in one minute.

    The receiver advertises its free slots as credits. The sender spends one per word and stops at zero; the receiver returns one each time a slot frees. The sender can never overflow the receiver. For full rate the receiver needs at least bandwidth × credit round trip of buffer.

    Check yourself Size the buffer: 1 flit per cycle, 6 cycles each way, 1 cycle at each end.

    RTT = 6 + 6 + 2 = 14 cycles, so at least 14 flits.

    Check yourself What is the credit conservation invariant?

    Credits at the sender + words in flight + words in the buffer + credits returning = the buffer size, every cycle.

    Check yourself Throughput decays over hours and a reset fixes it. What do you suspect?

    A credit leak, often a send and a credit return in the same cycle with only one applied. Assert conservation every cycle; in silicon, compare the idle credit count with the limit.

    Check yourself On/off or credits?

    On/off is simpler and needs headroom of about bandwidth × round trip above the off threshold, so it wastes buffer and can oscillate; credits are exact. On/off suits links where buffers are cheap or a stop must override everything (PAUSE); credits suit long or high-rate links.

    Check yourself Why separate credit pools per traffic class?

    So one class filling its buffers cannot stop another. A shared pool lets requests consume all credits and block the responses that would free them, which can deadlock.

    Check yourself Store-and-forward versus cut-through latency?

    H(r + L) against Hr + L: store-and-forward pays the packet's serialisation at every hop, cut-through once.

    Whiteboard exercise

    Task. A chip-to-chip link carries requests and responses at one 32-byte flit per cycle. The wire takes 12 cycles each way; each end adds 2 cycles. Responses must never be blocked by requests. Bit errors are possible. Design the flow control: mechanisms, classes and sizes.

    Check yourself Open a model answer

    Credits, because the stop arrives far too late for ready: RTT = 12 + 12 + 2 + 2 = 28 cycles. Two classes with separate pools, requests and responses, so requests can never consume the credits responses need; each pool needs at least 28 flits (896 bytes) for its class to reach full rate alone. Bit errors need a reliability layer: sequence numbers, a CRC per packet, a replay buffer and a window of at least bandwidth × ACK round trip, also about 28 flits plus the ACK's own delays. Credits return as running totals so a corrupted credit update is repaired by the next. Assert credit conservation per class in simulation, and check idle credit counts in silicon.

    Checkpoint: ten questions

    Check yourself 1. What does flow control prevent?

    A sender overrunning a receiver's buffer.

    Check yourself 2. On a credit link, when does the sender stop?

    When its credit count reaches zero.

    Check yourself 3. Why must both sides agree on the initial credit count?

    Too high and the sender can overflow the receiver; too low and throughput is wasted for ever. It is set by an initialisation exchange after reset.

    Check yourself 4. Batching credits in groups of K needs how much buffer for full rate?

    At least RTT + K − 1.

    Check yourself 5. What does a window count, and what frees it?

    Data sent but not yet acknowledged; acknowledgements free it.

    Check yourself 6. A token bucket has R = 0.5 per cycle and S = 10. At most how many units in 40 cycles?

    S + RT = 10 + 20 = 30.

    Check yourself 7. What does hop-by-hop control guarantee, and what not?

    No buffer overflows; it does not stop a slow endpoint's back-pressure from blocking unrelated traffic in shared buffers.

    Check yourself 8. Why can lossless networks deadlock?

    Full buffers make their upstreams wait; a cycle of waits never drains. Lossy networks drop instead, breaking the cycle.

    Check yourself 9. What limits a switch with one FIFO per input under uniform random traffic?

    Head-of-line blocking: about 58.6% throughput.

    Check yourself 10. What are the four questions for choosing flow control?

    How late the stop arrives; whether data can be lost; whether the resource is shared with protected traffic; whether the path is multi-hop.

    Revisit

    • 4.1 Why Flow Control

    • 4.2 On/Off Flow Control

    • 4.3 Credit-Based Flow Control

    • 4.4 Credit Initialisation

    • 4.5 The Credit Loop and Buffer Sizing

    • 4.6 Credit Classes and Pools

    • 4.7 Credit Return Latency and Batching

    • 4.8 Credit Bugs

    • 4.9 Window Flow Control

    • 4.10 Rate-Based Shaping

    • 4.11 Hop-by-Hop or End-to-End

    • 4.12 Lossless or Lossy

    • 4.13 Switching Modes

    • 4.14 Head-of-Line Blocking

    • 4.15 Choosing Flow Control

    Keep going

    Next: Part 5: Transactions. Above flow control sits meaning: reads, writes, addresses, bursts and responses.

    Previous

    67 / 234

    Next: Part 5: Transactions

    Up next

    Up nextPart 5: Transactions

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Why Flow Control
    • On/Off Flow Control
    • Credit-Based Flow Control