Why DFT Affects Timing

Chapter 12 · Section 12.1 · DFT Constraints & Timing

Project thread — the mini-SoC's DFT (scan/boundary scan/BIST controls) is real silicon that must meet timing in functional and every test mode; 12.5 constrains each mode for STA.

1. Why Should I Learn This?

DFT is real hardware with timing — and it must meet timing in every mode, or you get a broken chip or escapes.

• Scan mux (3.2) → setup delay on functional paths (mission-mode hit).
• Scan Q→SI → new shift-path timing (a hold concern, 3.3/4.2); boundary cells → I/O delay (10.3).
• scan-enable/test-mode → high-fanout, timing-critical nets.
• Each mode has different timing (functional/shift/at-speed) → STA analyzes each — DFT is not free.

2. Real Silicon Story — functional-clean, tester-fail (one mode analyzed)

A chip closed functional timing cleanly and taped out — the team was confident. On the tester, it failed scan with shift errors: the scan chains couldn't reliably shift a known pattern on some dies.

The cause was a mode that was never analyzed. STA had closed functional (capture-path) timing thoroughly — but the shift path (Q → SI between adjacent scan cells) is a new set of paths that exist only in shift mode, and its hold timing had not been checked (adjacent cells clocked together + clock skew → hold violations on the shift path, 3.3/4.2). Functional timing passing said nothing about shift timing, because they're different modes with different paths.

The fix was multi-mode timing: analyze the shift mode's hold (and add lock-up latches where skew required, 4.2), the capture mode's setup, and the scan-mux penalty in functional — each mode with its own constraints. Lesson: DFT creates multiple timing modes, and closing one (functional) says nothing about the others (shift/capture) — each must be analyzed, or a functional-clean chip fails on the tester.

3. Factory Perspective — DFT timing through each lens

• What the STA/timing engineer sees: multiple modes to close — functional (with scan-mux penalty), shift (hold), capture/at-speed (setup) — each with its own clocks and constraints (12.5).
• What the CTS/physical engineer sees: the scan mux (setup penalty), the SE distribution (high-fanout, timing-critical), and the shift-path hold (lock-up latches) — physical timing tasks.
• What the RTL/DV engineer sees: that DFT costs functional timing (budget the scan-mux delay) and that their design must close in test modes too — DFT isn't a free add-on.
• What management cares about: that DFT timing is multi-mode — a functional-clean chip can still fail test if the test modes weren't timed — a schedule/quality risk if left late.

4. Concept — what DFT adds, and multi-mode timing

What DFT adds to timing:

• Scan mux (3.2): a 2:1 mux on each scan flop's D → setup delay on every functional path ending at a scan flop → a mission-mode timing penalty across the design.
• Shift path (3.3): the Q → SI connections → new timing paths that exist only in shift mode → primarily a hold concern (adjacent cells clocked together, clock skew, 4.2 lock-up latches).
• Boundary-scan cells (10.3): a cell per I/O → I/O-path delay.
• Control signals: scan-enable, test-mode → high-fanout, timing-critical nets (SE especially, 12.3).

Multi-mode timing (the crux):

• Each mode has different timing and different active paths:
  • Functional (mission): the functional paths (flop → logic → flop), plus the scan-mux penalty.
  • Shift: the shift path (cell → cell), a hold analysis, slow shift clock (setup easy).
  • Capture / at-speed: the functional capture path at the functional/at-speed clock — a setup analysis (12.4).
• STA must analyze each mode separately — with the right clocks, case analysis, and exceptions (12.5). Closing one says nothing about the others.

The key insight — DFT is real silicon that must meet timing:

• In functional mode: or the chip doesn't work (the scan-mux penalty is real delay).
• In test modes: or you get escapes or false fails (shift-path hold, capture setup, SE timing).
• So DFT is not free: budget the scan-mux delay, analyze the test modes, constrain the test controls.

5. Mental Model — a car that must pass several driving tests

DFT-added hardware is like modifications to a car that must pass several different driving tests, not just one.

• The scan mux is like adding a safety interlock in the throttle linkage — it works fine, but it adds a tiny lag to every acceleration (setup delay on every functional path). You must re-check the car's performance with the interlock in place (budget the penalty).
• The shift path is a special 'transport mode' — a way to tow the car in a convoy (scan chain) — with its own requirement: the cars must not roll into each other (a hold race between adjacent cells). This test doesn't exist in normal driving, so you must run it separately.
• Passing the normal driving test (functional timing) tells you nothing about the convoy test (shift) or the high-speed test (at-speed capture) — each is a different test with different rules.
• And the car must pass all of them: fail normal driving → it doesn't work; fail the convoy/high-speed test → it can't be inspected/certified (test escapes/false fails).

Modify the car and you must re-run every test it faces — normal, convoy, and high-speed — because each has its own rules; passing one doesn't pass the others.

6. Working Example — the DFT timing-impact list

Enumerate DFT's timing impacts and the modes to analyze:

# DFT timing-impact list + multi-mode analysis - REPRESENTATIVE, SIMPLIFIED, tool-neutral:
  IMPACT                         WHERE                          ANALYZE IN MODE
  scan mux setup delay           every functional path -> scan flop (3.2)   FUNCTIONAL (mission timing penalty)
  shift path (Q->SI) hold        adjacent scan cells (3.3/4.2)              SHIFT (hold; slow clock -> setup easy)
  capture-path setup             flop -> logic -> flop (functional paths)   CAPTURE / AT-SPEED (setup, 12.4)
  boundary-cell I/O delay        each I/O pin (10.3)                        FUNCTIONAL + board
  scan_enable timing             high-fanout SE -> capture edge (3.4/12.3)  CAPTURE (SE setup/hold, 12.3)
  clock muxing / OCC             clock selection + at-speed (11.2/2.3)      SHIFT + CAPTURE (glitch-free, at-speed)
# EACH MODE = different timing -> STA must analyze EACH (functional / shift / capture-at-speed). Closing one != closing all.
# DFT is REAL silicon: functional-timing miss -> chip doesn't work ; test-timing miss -> escapes / false fails.

7. Industry Flow — DFT adds hardware → multi-mode timing

DFT hardware creates timing that STA must close across all modes:

8. Debugging Session — closed functional, failed test (or vice versa)

9. Common Mistakes

• Analyzing only functional timing. DFT is multi-mode — shift and capture/at-speed have different timing.
• Not budgeting the scan-mux penalty. It's real setup delay on every functional path (3.2) — budget it.
• Ignoring the shift-path hold. New Q→SI paths are a hold concern (adjacent cells/skew, 4.2 lock-up latches).
• Treating scan-enable/test-mode as ordinary nets. They're high-fanout, timing-critical (12.3).
• Assuming functional-clean = test-clean. Closing one mode says nothing about the others.

10. Industry Best Practices

• Do multi-mode timing — close functional, shift, capture/at-speed each with its own constraints (12.5).
• Budget the scan-mux delay in functional timing (3.2).
• Analyze shift-path hold (adjacent cells/skew; lock-up latches, 4.2).
• Treat scan-enable as timing-critical (distribution + setup/hold, 12.3).
• Close all modes before signoff — a functional-clean chip can still fail test.

11. Senior Engineer Thinking

• Beginner: "Functional timing is clean — the chip's timing is done."
• Senior: "DFT is multi-mode timing. Functional-clean says nothing about shift-path hold (new Q→SI paths, adjacent-cell hold) or at-speed capture. I close functional (with the scan-mux penalty), shift (hold, lock-up latches), and capture/at-speed (setup, SE settled, OCC) — each with its own constraints. Closing one mode isn't closing all."

The senior treats DFT timing as multi-mode and closes every mode — never assumes functional-clean means test-clean.

12. Silicon Impact

'Why DFT affects timing' reframes DFT from a coverage topic into a timing-closure topic — because DFT is real hardware that STA must analyze, and it's not free. The direct costs are concrete: the scan mux puts setup delay on essentially every functional path (3.2) — a mission-mode penalty that must be budgeted or the chip misses timing and doesn't work; the scan Q→SI connections create entirely new shift-path timing (a hold problem, 3.3/4.2) that exists only in shift mode; boundary cells add I/O delay (10.3); and scan-enable/test-mode are high-fanout, timing-critical nets (12.3). But the defining insight is multi-mode timing: DFT introduces several modes (functional, shift, capture/at-speed), each with different active paths and different timing, so STA must analyze each mode separately — and closing one mode says nothing about the others. That's why a functional-clean chip can fail the tester (unanalyzed shift-path hold, the story) or a chip that passes slow scan can miss functional timing (un-budgeted scan-mux penalty, or un-analyzed at-speed) — failures that surface late (on the tester or in the field) precisely because the failing mode was never timed. The consequences differ by mode: a functional-timing miss means the chip doesn't work; a test-timing miss means escapes or false fails. For the STA/DFT engineer, this makes multi-mode timing analysis — with per-mode clocks, case analysis, and exceptions (12.5) — a first-class part of closure; for the CTS/physical engineer, the scan mux, SE distribution, shift-path hold, and clock/OCC are timing deliverables; and for the RTL/DV engineer, DFT's functional-timing penalty is a real cost to design for. This sets up the rest of Chapter 12 — the shift vs capture timing (12.2), scan-enable setup/hold (12.3), at-speed fast capture (12.4), and the STA constraints (12.5) that make each of the Chapter 11 modes actually timing-close in silicon.

13. Engineering Checklist

• Did multi-mode timing — functional, shift, capture/at-speed each analyzed with its own constraints (12.5).
• Budgeted the scan-mux setup delay on functional paths (3.2).
• Analyzed the shift-path hold (adjacent cells/skew; lock-up latches, 4.2).
• Treated scan-enable/test-mode as high-fanout, timing-critical (12.3).
• Confirmed all modes close before signoff — didn't assume functional-clean = test-clean.

14. Try Yourself

1. List four DFT additions that affect timing (scan mux, shift path, boundary cells, control signals) and where.
2. For each, name the mode(s) STA must analyze it in (functional / shift / capture-at-speed).
3. Show why closing functional timing doesn't cover the shift-path hold (different mode, different paths).
4. Explain the two failure consequences: functional miss (chip broken) vs test miss (escapes/false fails).
5. Set up a multi-mode analysis plan (functional + shift + capture/at-speed), each with its own clocks.

The concepts are tool-neutral; multi-mode timing is standard STA. No paid tool required to reason about DFT timing.

15. Interview Perspective

• Weak: "DFT adds a scan mux that costs a little timing."
• Good: "The scan mux adds functional-path delay, and the shift path adds new hold timing; you analyze both."
• Senior: "DFT is real hardware that affects timing in several ways: the scan mux adds setup delay on every functional path (3.2), the Q→SI shift path creates new hold timing between adjacent cells (3.3/4.2), boundary cells add I/O delay, and scan-enable/test-mode are high-fanout, timing-critical nets. Crucially, DFT introduces multiple modes — functional, shift, capture/at-speed — each with different active paths and timing, so STA must analyze each mode separately. Closing functional says nothing about shift-path hold or at-speed — which is why a functional-clean chip can fail scan on the tester. Functional-timing miss → the chip doesn't work; test-timing miss → escapes/false fails. So DFT is not free — I budget the scan-mux penalty, analyze shift hold, constrain SE, and close every mode."

16. Interview / Review Questions

17. Key Takeaways

• DFT adds real hardware whose timing STA must analyze — it is not free.
• The additions: the scan mux puts setup delay on every functional path (3.2, a mission-mode penalty); the scan Q→SI connections create new shift-path timing (a hold concern between adjacent cells, 3.3/4.2); boundary cells add I/O delay (10.3); scan-enable/test-mode are high-fanout, timing-critical nets.
• DFT introduces multiple modes — functional (mission + scan-mux penalty), shift (hold, slow clock), capture/at-speed (setup at rated clock) — each with different active paths and timing.
• STA must analyze each mode separately — closing one (functional) says nothing about the others (shift/capture) — so a functional-clean chip can still fail the tester if the test modes weren't timed.
• Consequences differ: a functional-timing miss means the chip doesn't work; a test-timing miss means escapes or false fails — so budget the scan-mux penalty, analyze the test modes, and constrain the test controls. Next: 12.2 — shift & capture timing.

18. Quick Revision

Why DFT affects timing (Ch12 opener). DFT = REAL hardware STA must analyze, NOT free. Additions: SCAN MUX (3.2) → setup delay on EVERY functional path (mission penalty); scan Q→SI shift path (3.3) → NEW paths, a HOLD concern (adjacent cells/skew → lock-up latches, 4.2); boundary cells → I/O delay (10.3); scan_enable/test_mode → high-fanout, timing-critical. MULTI-MODE: each mode (functional / shift / capture-at-speed) has DIFFERENT active paths + timing → STA must analyze EACH. Closing functional says NOTHING about shift-path hold or at-speed → a functional-clean chip can FAIL the tester. Functional miss → chip doesn't work; test miss → escapes/false fails. Budget the scan-mux penalty, analyze the test modes, constrain the controls. Next: 12.2 — shift & capture timing.