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. Why Flow Control

Part 4 · Flow Control · Foundation (F)

Why Flow Control

Why a per-cycle ready stops working over long paths, and the three families of cure: stop and go, credits, and rate limits.

On this page

    Note

    Level: Foundation (F) · Answers: How much may I send before I hear back?

    Before this: Part 4 overview, Skid Buffers

    A valid/ready channel works beautifully between neighbouring blocks. Stretch it across a chip with ten pipeline stages each way and something breaks: by the time the receiver's "not ready" reaches the sender, the sender has already sent ten more words, and they are all on their way to a receiver that said it was full.

    When the receiver's answer arrives late, how much may the sender send before it hears back?

    The obvious answer, and why it breaks

    The obvious answer is to keep valid/ready and register both directions at every stage with skid buffers (lesson 3.9). That works, but each stage needs a spare entry, so a ten-stage path carries ten spare entries spread along it, and each adds latency. The deeper issue is the one skid buffers already showed in miniature: if the sender learns of a stall k cycles late, k extra words are already on their way, and someone must have room for them. Flow control is the general answer to that question: how does a sender know, in advance, that the receiver has room?

    The idea: three families of flow control

    Every flow-control scheme in every protocol belongs to one of three families:

    Family

    How the receiver limits the sender

    What the receiver must provide

    Examples in this part

    Stop and go (on/off)

    Tells the sender to stop when it is nearly full, and to resume when it has drained

    Spare room above the stop threshold for everything that arrives before "stop" takes effect

    Lesson 4.2

    Credits (and windows)

    Grants the sender permission in advance, one slot (or byte) at a time; the sender may never send more than it holds

    Buffers equal to the credits it grants; credits returned as space frees

    Lessons 4.3 to 4.9

    Rate limits

    Agrees a maximum average rate and burst size in advance; no feedback needed while the sender obeys

    Enough buffering for the agreed burst; a consumer that keeps up with the agreed rate

    Lesson 4.10

    Notice what all three have in common: the receiver's buffer must cover what can be sent before the receiver's information reaches the sender. They differ in when that information is sent: after the fact (stop), in advance (credits), or once for all time (rates).

    The problem every flow-control scheme solves: feedback crosses the same long path as the data, so it is always late.

    Worked numbers: how late is the feedback?

    With illustrative numbers, a channel between two corners of a large die:

    Diagram
    Route: 8 pipeline stages each way to close timing at 2 GHz
    Data takes 8 cycles to arrive; feedback takes 8 cycles to return.
    If the receiver says "full" now, the sender keeps sending for 8 cycles before it hears,
    and the words already in flight keep arriving for 8 more:
      up to 16 words arrive after the receiver decides it is full,
      so the receiver needs about 16 words of room beyond its "full" point (one round trip).

    That number, one round trip of data, appears in every scheme of this part. Credits make it explicit (lesson 4.5); stop-and-go hides it in the threshold (lesson 4.2); rate limits hide it in the agreed burst (lesson 4.10).

    The design space

    Family

    Strength

    Weakness

    Stop and go

    Simple; little state at the sender

    Room above the threshold is wasted most of the time; oscillates under heavy load

    Credits

    Exact: the receiver can never overflow; works at any distance

    Counters at both ends; buffers sized to the round trip; credit bugs (lesson 4.8)

    Rate limits

    No feedback loop at all

    Only as good as the agreement; wastes capacity when traffic is lighter than agreed

    How real protocols chose

    Protocol

    Family

    PCI Express

    Credits: separate credit types for posted, non-posted and completion traffic, each with header and data credits.

    Ethernet

    Lossy by default (frames may be dropped), with optional stop-and-go: IEEE 802.3x PAUSE frames, and per-priority PAUSE as priority flow control (802.1Qbb).

    AXI (on chip)

    valid/ready on each channel, with register slices for long routes, rather than credits.

    What breaks

    A design extends a valid/ready channel across a chip with simple flip-flops on ready, not skid buffers, because "ready changes rarely" (illustrative). Every time the receiver deasserts ready, the words already sent during the ready delay arrive at a full receiver and are lost. The fix is not more care with ready; it is choosing a scheme whose buffering covers the feedback delay by construction, which for a long path means credits.

    Why this matters

    Senior lens. Choosing flow control is choosing where the round trip's worth of buffering lives and who controls it. Ask three questions of any long channel: how many cycles does the receiver's information take to reach the sender, how much can the sender send in that time, and where is the room for it? If the answer to the last one is "we assume the receiver keeps up", the channel has no flow control, only a hope.

    Interview

    Asked: "What problem does flow control solve?"

    Weak answer: It stops the sender from going too fast.

    Strong answer: It keeps a receiver's buffer from overflowing when the sender learns about the receiver's state late. Whatever is sent during that feedback delay must fit somewhere. There are three families: stop-and-go (tell the sender to stop, with room above the threshold for what's in flight), credits (grant room in advance, so overflow is impossible), and rate limits (agree a rate and burst up front). All of them need about one round trip of buffering at full rate.

    Follow-ups: (1) Why does a per-cycle ready stop working over a long path? (2) Which family would you choose for a 20-cycle on-chip link?

    Check yourself A path has 5 stages each way and the sender sends one word per cycle. Roughly how much room must the receiver keep beyond its "full" point with stop-and-go?

    About one round trip of words: 5 cycles for "stop" to reach the sender plus 5 cycles of words already in flight, so about 10 words.

    Check yourself Which family can guarantee by construction that the receiver never overflows?

    Credits: the sender can only send what the receiver has already granted room for.

    Check yourself Why does a rate limit need no feedback at all?

    Both sides agree the rate and burst size in advance; as long as the sender obeys and the receiver is built to keep up, there is nothing to report.

    Key takeaways

    • Over a long path the receiver's feedback arrives late, and whatever is sent in the meantime must fit in its buffer.

    • Flow control comes in three families: stop and go, credits (and windows), and rate limits.

    • All of them need about one round trip of buffering at full rate; they differ in when the receiver's information is sent.

    Keep going

    Next: Lesson 4.2, On/Off Flow Control. The oldest scheme: tell the sender to stop when you are nearly full. Where to put the threshold.

    Related topics

    • Part 4 overview: Flow Control

    • Architecture course: Credit Flow Control and Buffers

    Previous

    51 / 234

    Next: On/Off Flow Control

    Up next

    Up nextOn/Off Flow Control

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Credit-Based Flow Control
    • Credit Initialisation
    • The Credit Loop and Buffer Sizing