Chain Count, Length & Balancing

Chapter 3 · Section 3.5 · Scan Architecture

Project thread — the counter's chain is tiny, but real designs have thousands of flops; here we decide how many balanced chains to build. 3.6 stitches the counter's chain end-to-end.

1. Why Should I Learn This?

Chain count, length, and balance are the direct levers on scan test time — and they set up why compression exists.

• Chains shift in parallel → shift cycles/pattern = longest chain length (not the sum).
• More chains → shorter chains → less test time (1.4).
• Scan pins cap the chain count → the reason for compression (Ch7).
• Balancing (equal-length chains) minimizes the max length so the longest doesn't waste cycles.

2. Real Silicon Story — the one long chain that blew the test budget

A design stitched almost all its flops into a single long scan chain — simple to build, minimal pins. Then the test-time model came back far over budget: with the chain thousands of flops long, every pattern paid thousands of shift cycles in and out, and across millions of dies the ATE cost was unacceptable (1.4).

The team first tried 'shift faster' — but the shift clock was already near its limit, and faster shift raises power. The real fix was architectural: split the flops into many balanced chains so the longest chain (which sets shift time) became much shorter — cutting shift cycles per pattern by roughly the chain count. When the pin budget ran out (not enough scan pins for enough chains), they added compression (Chapter 7) to feed many short internal chains from a few pins.

Lesson: test time is set by the longest chain, not the flop count — more, balanced chains (and, past the pin limit, compression) is how you control it, not a faster shift clock.

3. Factory Perspective — chain architecture through each lens

• What the test engineer sees: the scan chain report (chain count, lengths, balance) and the resulting shift cycles per pattern — the direct input to the test-time model (1.4).
• What the yield engineer sees: that shorter, more chains localize chain-integrity and diagnosis better (a fail is in a shorter chain), aiding failure analysis.
• What the RTL/DV engineer sees: that flop count and clock domains shape the chains — more flops / more domains → more/careful chains — and that synchronous design keeps chains clean.
• What management cares about: that chain architecture (and compression) is the lever on test cost (1.4) — a PPA/pins vs test-time trade with a direct line to the DPPM-at-acceptable-cost goal (1.5).

4. Concept — parallel shift, the pin cap, and balancing

Chains shift in parallel — the longest sets the time:

• Split F flops into K chains → each ~F/K long. All chains are clocked together.
• Shift cycles per pattern = length of the longest chain (every chain finishes when the longest does).
• So test time ≈ longest-chain-length × patterns (1.4). More chains → shorter longest chain → less time.

The pin budget caps chain count:

• Each chain needs a scan-in and a scan-out pin (sometimes shared with functional pins). Top-level pins are scarce.
• So K ≤ (available scan pins) — you can't just keep adding chains. This is the hard limit.
• Compression (Ch7) breaks it: a decompressor drives many short internal chains from few input pins, and a compactor merges their outputs to few output pins — decoupling internal chain count from pin count.

Balancing — equalize lengths to minimize the maximum:

• Since the longest chain sets the time and all chains shift for that many cycles, an unbalanced design (one long chain, several short) wastes cycles: the short chains finish early but must keep shifting (dummy bits) until the long one is done.
• Balanced chains (as equal-length as possible) minimize the maximum length for a given K → minimum shift time.

Other real constraints:

• Clock domains: flops on different clocks generally go in separate chains; if mixed within a chain, lock-up latches at domain crossings prevent shift race/hold problems.
• Chain ordering: the order flops are stitched affects routing wirelength and timing — a physical-design optimization (Chapter 4).
• Shift power: many flops toggling → segmentation/partial-shift techniques may cap peak shift power.

5. Mental Model — checkout lanes at a store

Picture F customers (flops) needing checkout, and K open lanes (chains) that all run at the same pace.

• Total time ≈ the busiest lane's length, because everyone leaves only when the longest line clears — that's shift cycles = longest chain.
• Open more lanes (more chains) → shorter lines → faster — until you run out of registers/staff (the scan pins).
• Balance the lines — don't put 4000 people in one lane and 300 in others; the store empties only when the giant lane clears, and the short lanes stand idle. Equal lines clear fastest.
• When you can't open more physical lanes (pin limit), you install a system that funnels many short internal lines through a few doors — that's compression (Ch7).
• Some customers need a special lane (a different clock domain) — you don't mix them into a general lane without care (lock-up latches).

Empty the store fastest by opening many, equal lanes — and when you're out of doors, funnel (compress).

6. Working Example — chain math on 5000 flops

Put numbers on chain count, length, and balance:

# Chain architecture math — REPRESENTATIVE, SIMPLIFIED, tool-neutral (F = 5000 flops):
  1 chain            : longest = 5000  -> 5000 shift cycles/pattern   (minimal pins, MAX test time)
  10 BALANCED chains : longest =  500  ->  500 shift cycles/pattern   (10x faster; needs ~10 scan-in + 10 scan-out pins)
  10 UNBALANCED      : one 4100 + nine ~100 -> longest = 4100 -> 4100 cycles (short chains WASTE ~4000 cycles each)
# shift cycles/pattern = LONGEST chain length (chains shift in parallel). Balance + more chains -> less test time (1.4).

# The pin cap and compression — REPRESENTATIVE:
  Want 100 chains of 50 -> 50 shift cycles/pattern (great!) BUT that needs ~100 scan-in + 100 scan-out pins -> NOT available.
  COMPRESSION (Ch7): a decompressor drives 100 short INTERNAL chains from ~5 input pins; a compactor merges to ~5 outputs
  -> get the 50-cycle shift of 100 chains using only a handful of pins. Pins no longer cap internal chain count.
# Clock domains: flops on clkA and clkB go in SEPARATE chains (or lock-up latches at the crossing).

7. Industry Flow — from pin budget to shift time

Chain architecture flows from pins to chain count to shift time, with compression relieving the cap:

8. Debugging Session — test time too high, one chain dominates

9. Common Mistakes

• Thinking shift time = flop count. It's the longest chain length — split flops into more, balanced chains.
• Leaving chains unbalanced. The longest chain sets time; short chains waste cycles — equalize lengths.
• Trying to 'shift faster' to cut test time. The clock is near its limit and it raises power — fix the structure.
• Adding chains past the pin budget. Pins cap chain count — that's what compression (Ch7) is for.
• Mixing clock domains in one chain carelessly. Use separate chains or lock-up latches at crossings.

10. Industry Best Practices

• Balance chains to equal length — minimize the maximum (which sets shift time).
• Use as many chains as pins allow; beyond that, compress (Ch7).
• Group by clock domain; insert lock-up latches where a chain crosses domains.
• Optimize chain ordering for routing/timing during stitching (physical, Ch4).
• Model test time from the longest chain (1.4); manage shift power (segmentation if needed).

11. Senior Engineer Thinking

• Beginner: "Test time is high — let's run the shift clock faster."
• Senior: "Shift time is the longest chain length × patterns — a faster clock barely helps and burns power. I balance the chains and add chains to shorten the longest one, and when pins run out, I compress — many short internal chains from few pins. Structure sets test time, not shift speed."

The senior attacks chain count and balance (then compression), never the shift clock, to cut test time.

12. Silicon Impact

Chain count, length, and balancing are the primary architectural levers on scan test cost, and they follow one clean rule: because chains shift in parallel, shift time per pattern equals the longest chain's length, so test time ≈ longest-chain-length × patterns (1.4). That single fact dictates the strategy — more chains and balanced (equal) lengths to minimize the maximum — and it explains why 'just shift faster' is the wrong lever (the shift clock is near its limit and faster shift raises peak power). The binding constraint is the scan pin budget: each top-level chain costs scan-in/scan-out pins, and pins are scarce, so chain count is capped — which is the direct, structural reason compression exists (Chapter 7), feeding many short internal chains from a few pins and thereby decoupling internal chain count from pin count. Real designs layer on clock-domain rules (separate chains or lock-up latches), chain-ordering for routing/timing (Chapter 4), and shift-power management. Getting this right buys back much of the test time that scan's shifting inherently costs, keeping the part's DPPM-at-acceptable-cost promise (1.5) affordable. For the RTL/DV engineer, the connection is that your flop count and clock domains shape the chains, and the scan chain report's longest-chain length is a number you should treat as a test-cost KPI — imbalance or a pin-limited chain count is the cue to balance and to plan for compression.

13. Engineering Checklist

• Balanced chains to equal length (minimized the maximum).
• Used as many chains as the pin budget allows; planned compression (Ch7) beyond it.
• Grouped flops by clock domain; added lock-up latches at any in-chain domain crossings.
• Modeled test time from the longest chain (1.4); managed shift power.
• Reviewed the scan chain report (count, lengths, balance, domains, pin mapping).

14. Try Yourself

1. For F=5000 flops, compute shift cycles/pattern for 1 chain, 10 balanced chains, and 10 unbalanced (one 4100 + nine ~100).
2. Confirm shift time tracks the longest chain, and that balancing 10 chains gives a 10× win over one chain.
3. Propose 100 chains of 50 and show it needs ~200 scan pins → hits the pin cap.
4. Describe how compression (Ch7) delivers the 50-cycle shift using only a handful of pins.
5. Split the flops across two clock domains and explain why they need separate chains (or lock-up latches).

The math is tool-neutral — a spreadsheet suffices. Real chain reports come from scan insertion (Chapter 4); compression from Chapter 7. No paid tool required.

15. Interview Perspective

• Weak: "More scan chains make testing faster."
• Good: "Chains shift in parallel, so shift time is the longest chain's length; more, balanced chains cut test time."
• Senior: "Total flops are fixed; you split them into K chains that shift in parallel, so shift cycles per pattern = the longest chain's length — hence more chains and balanced (equal) lengths cut test time (1.4), and 'shift faster' is the wrong lever (near the clock limit, more power). The cap is the scan pin budget — each chain costs scan-in/out pins — which is exactly why compression exists: a decompressor/compactor runs many short internal chains from a few pins, decoupling internal chain count from pins. Real designs also keep clock domains in separate chains (or use lock-up latches) and optimize chain ordering for routing/timing."

16. Interview / Review Questions

17. Key Takeaways

• The design's flop count is fixed; you split it into K chains (~F/K each). Because chains shift in parallel, shift cycles per pattern = the longest chain's length, so test time ≈ longest-chain-length × patterns (1.4).
• More chains → shorter chains → less test time — and balancing (equal-length chains) minimizes the maximum so the longest chain doesn't waste cycles on shorter ones.
• The scan pin budget caps the chain count (each chain needs scan-in/scan-out pins) — which is the structural reason compression exists (Chapter 7): many short internal chains from a few pins, decoupling internal chain count from pins.
• Clock domains usually require separate chains (or lock-up latches at crossings); chain ordering affects routing/timing (a physical-design task, Chapter 4); shift power may push toward segmentation.
• Don't 'shift faster' to cut test time — it's near the clock limit and raises power; fix the structure (more, balanced chains) and, past the pin cap, compress. Next: 3.6 — making the counter scannable, end to end.

18. Quick Revision

Chain count, length & balancing. F flops split into K chains (~F/K each); chains shift IN PARALLEL → shift cycles/pattern = LONGEST chain length → test time ≈ longest × patterns (1.4). More chains → shorter → faster. Balance (equal lengths) minimizes the max (unbalanced wastes cycles on short chains). Scan PINS cap K (each chain = scan-in + scan-out) → the reason COMPRESSION exists (Ch7: many short internal chains from few pins). Clock domains → separate chains (or lock-up latches); ordering = routing/timing (Ch4). Don't 'shift faster' (power, near-limit) — fix structure. Next: 3.6 — making the counter scannable.