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
    • Valid-Only Streams
    • Wait States and Stretching
    • The Valid/Ready Handshake
    • The Valid/Ready Rules
    • Request/Acknowledge: Two-Phase and Four-Phase
    • Push and Pull
    • Global Stall or Elastic Pipeline
    • Register Slices
    • Skid Buffers
    • Bubbles and Half Throughput
    • Latency-Insensitive Design
    • Protocols Compared: Handshakes
    • Drills: Handshakes
  • 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
  • Part 14: Security and Isolation7
  • Part 15: Specifying and Verifying11
  • Part 16: Protocols Dissected17
  • Part 17: Capstones5
  • Part 18: Interview Preparation6
Loading lesson

‹Part 3: Handshakes
  1. Topics
  2. First Principles of Hardware Protocols
  3. Part 3: Handshakes
  4. Global Stall or Elastic Pipeline

Part 3 · Handshakes · Working (W)

Global Stall or Elastic Pipeline

One stall signal fanned out to a whole pipeline, or a valid/ready handshake between every stage: why the first stops scaling and what the second costs.

On this page

    Note

    Level: Working (W) · Answers: Is the receiver ready?

    Before this: The Valid/Ready Handshake

    A four-stage pipeline stalls with one signal: when the output is blocked, stall goes high and every register in every stage holds its value. It is simple and it works. The pipeline grows to sixteen stages, each 256 bits wide, and the stall net becomes the slowest path in the block. No amount of logic optimisation fixes it, because the problem is not logic.

    Why does a single stall signal stop scaling, and what replaces it?

    The obvious answer, and why it breaks

    A global stall is the obvious way to add back-pressure to a pipeline: one signal, computed where the blockage is, drives the enable of every pipeline register. Its problem is physical. Within one clock period it must travel back across the whole pipeline and fan out to every flip-flop of every stage: thousands of loads, needing a tree of buffers whose depth grows with the fan-out, plus wire across the full length. Add stages or width and the path gets longer, while the clock period does not.

    The idea: let each stage decide locally

    An elastic pipeline replaces the single stall with a valid/ready handshake between every pair of stages. Each stage decides only for itself: "I can take a word if I am empty, or if the stage after me is taking mine". A blockage at the output then spreads backwards one stage per cycle rather than everywhere in one cycle. Each decision depends only on neighbours, so its timing path is short and stays the same length however deep the pipeline grows.

    Top: the output's blockage feeds stall logic, whose one stall net fans out to every stage. Bottom: an elastic pipeline, where ready travels one stage at a time.

    Build it: how the two paths grow

    The model estimates, with illustrative delays, how long the global stall path is for pipelines of 2 to 32 stages, each 256 bits wide, against the fixed path of one stage's local ready logic.

    example.py
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    """Why one global stall signal stops scaling (illustrative numbers).
    
    A global stall is computed at the end of a pipeline and must reach the enable of
    every register in every stage within one clock period. Its fan-out grows with
    depth x width, so it needs a buffer tree whose depth grows with the log of the
    fan-out, plus wire delay across the pipeline. An elastic pipeline instead gives each
    stage its own local ready, so the path length stays the same however deep it is.
    """
    import math
    
    T_DETECT = 0.20      # ns: logic that decides to stall
    T_BUFFER = 0.06      # ns per level of a fan-out-of-4 buffer tree
    T_WIRE_STAGE = 0.05  # ns of wire per stage the stall must travel back across
    T_LOCAL = 0.35       # ns: one stage's local ready logic (elastic)
    WIDTH = 256          # register bits per stage
    
    print("stages  global stall path  elastic path")
    rows = []
    for depth in (2, 4, 8, 16, 32):
        fanout = depth * WIDTH
        levels = math.ceil(math.log(fanout, 4))
        t_global = T_DETECT + levels * T_BUFFER + depth * T_WIRE_STAGE
        rows.append((depth, t_global))
        print(f"{depth:6d}  {t_global:12.2f} ns  {T_LOCAL:9.2f} ns")
    assert all(a[1] < b[1] for a, b in zip(rows, rows[1:]))
    print("PASS: the global stall path grows with depth; the elastic path does not")

    It prints:

    Diagram
    stages  global stall path  elastic path
         2          0.60 ns       0.35 ns
         4          0.70 ns       0.35 ns
         8          0.96 ns       0.35 ns
        16          1.36 ns       0.35 ns
        32          2.22 ns       0.35 ns
    PASS: the global stall path grows with depth; the elastic path does not

    The global path nearly quadruples from 2 to 32 stages, and past a few stages it is longer than one stage's whole logic budget. The elastic path does not change at all. That is the whole case for elastic pipelines: they turn a path that grows with the design into one that does not.

    What elastic costs

    • More logic per stage: each stage needs a valid bit and a small handshake.

    • Throughput needs care: a stage that cannot accept a word in the same cycle it hands one on halves the throughput (lesson 3.10).

    • The ready chain can still be long: if every stage's ready is combinational from the next one's, ready ripples through all stages in one cycle and the global-stall problem returns in disguise. Register slices and skid buffers break the chain (lessons 3.8 and 3.9).

    The design space

    Approach

    What it costs

    When it wins

    Global stall

    One net with huge fan-out; slows with depth and width

    Short, narrow pipelines

    Elastic, ready combinational through each stage

    Ready chain as long as the pipeline

    Short pipelines that need per-stage valid bits

    Elastic with registered ready every few stages (skid buffers)

    One spare entry per registered boundary

    Deep or wide pipelines; long on-chip routes

    Credits instead of ready (Part 4)

    A counter and buffers sized to the round trip

    Very long paths

    How real designs chose

    Where

    Choice

    On-chip interfaces such as AXI

    Per-channel valid/ready, so long routes can be pipelined with register slices without a global stall.

    Processor pipelines

    Often a mix: local stalls within a few stages, decoupling buffers between groups of stages.

    What breaks

    A team converts a global-stall pipeline to valid/ready but makes every stage's ready combinational from the next (illustrative). Functionally it is now elastic; for timing, the ready signal from the output ripples through all sixteen stages in one cycle, and the path is as long as the old stall net. Inserting a skid buffer every four stages cut the chain into short pieces and closed timing, at the cost of one spare entry per boundary.

    Why this matters

    Senior lens. Look for any signal whose fan-out or reach grows with the size of the design: global stalls, global enables, chained combinational readies. Each is a timing problem waiting for the next generation's bigger pipeline. Elastic design does not remove back-pressure; it makes it local, and register boundaries in the ready path are where you choose to pay a cycle of latency to keep every path short.

    Interview

    Asked: "Why not just stall the whole pipeline?"

    Weak answer: Because it is slow.

    Strong answer: A global stall must reach every register of every stage within one clock period. Its fan-out grows with depth times width, so it needs a deep buffer tree and wire across the whole pipeline, and past a few stages it becomes the critical path. An elastic pipeline uses a valid/ready handshake between neighbouring stages instead, so back-pressure moves one stage per cycle and every path stays short. The catch is that a chain of combinational readies recreates the problem, so you register ready at intervals with skid buffers.

    Follow-ups: (1) What does a chain of combinational readies do to timing? (2) How does an elastic stage keep full throughput?

    Check yourself In the model, what makes the global stall path grow?

    Its fan-out (depth × width) needs more buffer-tree levels, and it must travel back across more stages of wire. Both grow with the pipeline.

    Check yourself How fast does a blockage at the output reach the input of an elastic pipeline?

    One stage per cycle, if each stage's ready is registered or local; in one cycle if readies are chained combinationally.

    Check yourself Why is a fully combinational ready chain "the global stall in disguise"?

    Ready from the output passes through every stage's logic in one cycle, so its path grows with the pipeline exactly as the stall net did.

    Key takeaways

    • A global stall must reach every register in one cycle; its path grows with depth and width until it limits the clock.

    • Elastic pipelines use a handshake between neighbouring stages, so back-pressure travels one stage per cycle and paths stay short.

    • A chain of combinational readies recreates the problem; break it with registered boundaries (skid buffers).

    Keep going

    Next: Lesson 3.8, Register Slices. How to cut a long valid/ready path with a register, and what each kind of slice costs.

    Related topics

    • Part 3 overview: Handshakes

    • RTL course: Skid Buffer and Pipeline Stages

    Previous

    44 / 234

    Next: Register Slices

    Up next

    Up nextRegister Slices

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Valid-Only Streams
    • Wait States and Stretching
    • The Valid/Ready Handshake