DFT · Chapter 12 · DFT Constraints & Timing
Why DFT Affects Timing
DFT adds real hardware to the functional design, and that hardware has timing that static timing analysis must check. The scan mux on each scan flop adds setup delay on every functional path ending at that flop, a mission-mode timing hit across the whole design. The scan chain output-to-scan-input connections create new shift-path timing that does not exist functionally, mainly a hold concern. Boundary-scan cells add I/O delay, and control nets like scan-enable and test-mode are high-fanout and timing-critical. Because DFT introduces several modes, each with different timing, static timing analysis must analyze each mode on its own. The key idea is that DFT logic is real silicon that must meet timing in both functional and test modes, so it is never free in timing.
Foundation12 min readDFTTimingSTAScan MuxMulti-Mode
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.6b. The Constraints Themselves — three modes, three constraint sets
The impact list says which mode each item is analysed in. This is what "analysed in that mode" actually looks like. The commands are the tool-neutral SDC subset; the point is the shape — one clock definition, one case analysis that selects the mode, and the exceptions that follow from it.
# ─────────────────────────────────────────────────────────────────────────────
# MODE 1 — FUNCTIONAL (mission). Representative, simplified.
# ─────────────────────────────────────────────────────────────────────────────
create_clock -name clk_core -period 2.000 [get_ports CLK] ;# 500 MHz mission
# Case analysis selects the mode. With test_mode and scan_enable tied off,
# every scan mux presents its FUNCTIONAL input, and STA prunes the scan cone.
set_case_analysis 0 [get_ports test_mode]
set_case_analysis 0 [get_ports scan_enable]
# Note what is NOT excluded: the scan mux itself. It sits in the D path of every
# scan flop and is analysed as part of the functional path. That IS the penalty
# - there is no constraint that makes it go away, only budget that absorbs it.
# ─────────────────────────────────────────────────────────────────────────────
# MODE 2 — SHIFT. A different clock, a different set of active paths.
# ─────────────────────────────────────────────────────────────────────────────
create_clock -name clk_shift -period 100.000 [get_ports CLK] ;# 10 MHz tester
set_case_analysis 1 [get_ports test_mode]
set_case_analysis 1 [get_ports scan_enable] ;# SE high -> every mux takes SI
# With SE high the functional cone is dead and the chain is alive: the only
# paths that matter run cell -> cell along the stitched order.
#
# The 100 ns period makes SETUP on those paths trivial. It does nothing for
# HOLD, and that is the whole reason this mode gets its own analysis - see the
# Debug Lab below.
# ─────────────────────────────────────────────────────────────────────────────
# MODE 3 — CAPTURE / AT-SPEED. Functional paths, rated clock, SE low.
# ─────────────────────────────────────────────────────────────────────────────
create_clock -name clk_ref -period 2.000 [get_ports CLK]
# The on-chip clock controller gates the fast clock into a two-pulse burst.
create_generated_clock -name clk_occ -source [get_ports CLK] -divide_by 1 \
[get_pins u_occ/clk_out]
set_case_analysis 1 [get_ports test_mode]
# scan_enable is NOT a constant here: it falls between the last shift and the
# capture pulse, so it is a timed net, not a case-analysis value (12.3).
# Broadside / launch-on-capture: SE has a full cycle to settle before the
# second pulse, so the SE path is relaxed. Launch-off-shift would delete this
# exception - there SE must switch at the rated clock, which is what makes
# high-fanout SE distribution an at-speed problem (12.4).
set_multicycle_path -setup 2 -from [get_ports scan_enable]
set_multicycle_path -hold 1 -from [get_ports scan_enable]Read the three blocks side by side and the multi-mode claim stops being an
assertion and becomes an observation: the clock is different, the case analysis
is different, and therefore the set of paths STA even looks at is different.
A functional signoff never evaluated a single cell-to-cell shift path, because
set_case_analysis 0 [get_ports scan_enable] removed them from the graph.
The one fact that makes shift-path hold dangerous
Setup and hold are not symmetric, and the asymmetry is the reason a shift failure is a silicon problem rather than a tester-setup problem. Compare the two checks on adjacent scan cells A and B:
SETUP at B: T_launch + T_cq(A) + T_route(A->B) + T_setup(B) <= T_capture + PERIOD
HOLD at B: T_launch + T_cq(A) + T_route(A->B) >= T_capture + T_hold(B)The period appears in the setup inequality. It does not appear in the hold inequality. Hold is a race between two edges of the same clock event — the data launched by A racing the same edge arriving at B — so it is independent of clock frequency. Shifting at 10 MHz instead of 200 MHz buys enormous setup margin and exactly zero hold margin.
That is why the fix is structural, not procedural. A lock-up latch — a level-sensitive latch on the opposite clock phase, inserted between the two cells — delays the launched data by half a shift-clock cycle, which at a 100 ns period is 50 ns of tolerance against skew. It buys hold margin by construction, and it must be inserted before tapeout, because no tester setting can add it later. The underlying check is the ordinary one from setup and hold fundamentals; what changes in shift mode is only which paths are in the graph.
The tester was slowed from 20 MHz to 1 MHz and the scan chain still failed
HOLD IS FREQUENCY-INDEPENDENTScan chains on a new device shifted unreliably: a known pattern went in and a corrupted pattern came out, on roughly a fifth of dies, always in the same region of the same chain. The test engineer did the standard first experiment and reduced the shift frequency from 20 MHz to 1 MHz. The failure rate did not change at all. A further drop to 100 kHz also changed nothing. Because slowing the clock is the reflex fix for a timing failure and it had no effect, the team spent two weeks pursuing a power-delivery theory instead.
A hold violation on the shift path, which no shift frequency can fix. The failing region crossed a clock-domain boundary in the stitched chain order, where the skew between the two cells' clock arrivals exceeded the launching cell's clock-to-Q plus routing delay. Cell A's new value therefore reached cell B's scan input before the late-arriving edge at B had finished the hold requirement, and B captured the incoming bit instead of the one it was supposed to shift out.
The reason the frequency experiment was uninformative is the hold inequality above: the clock period is not a term in it. A hold check compares two paths launched by the same clock edge, so stretching the period moves both sides equally. The team's mental model — "slower clock means more timing margin" — is true for setup and false for hold, and the experiment that felt like a diagnosis was actually a null test.
Insert a lock-up latch at the chain's clock-domain crossings and re-run shift-mode hold analysis. The latch is transparent on the opposite phase, so it holds the launched data for half a shift-clock cycle before presenting it to the next cell, which converts the skew tolerance from picoseconds of routing delay into tens of nanoseconds of clock phase. Where a latch is not acceptable, the alternatives are reordering the chain so it does not cross the domain, or adding buffer delay on the data path — both of which are also pre-tapeout changes.
The process fix matters more than the instance fix: this failure existed because
shift mode was never given its own hold analysis. The functional signoff had
scan_enable tied to 0 by case analysis, which deleted every cell-to-cell path
from the timing graph before analysis began — so the report was clean not because
the paths passed, but because they were never examined.
And the debugging rule generalises well beyond scan: if slowing the clock does not change a failure, stop treating it as a setup problem. Frequency-independent failure is the signature of hold, and it points at skew, not at speed.
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)
A chip closes functional timing but fails scan on the tester (or passes test but the functional design misses timing), and the team is confused because timing was signed off; only one mode was analyzed -- the other mode's timing (shift-path hold, or the scan-mux setup penalty, or capture/at-speed setup) was never checked -- so the fix is multi-mode timing analysis, closing functional, shift, and capture/at-speed each with its own constraints
DFT IS MULTI-MODE TIMING — CLOSING ONE MODE SAYS NOTHING ABOUT THE OTHERSA chip closed functional timing and taped out, but fails scan on the tester (shift errors on some dies) — or the reverse, passes test but the functional design misses timing. Either way, the team is confused: timing was signed off.
Only one timing mode was analyzed, but DFT creates several modes with different active paths and different timing, so closing one mode says nothing about the others — the failing mode's timing was simply never checked. DFT's modes have distinct timing (Section 4): functional analyzes the functional paths (flop→logic→flop) plus the scan-mux setup penalty; shift analyzes a completely different set of paths — the Q→SI shift path between adjacent scan cells — which is primarily a hold problem (adjacent cells clocked together + clock skew, 3.3/4.2); capture/at-speed analyzes the functional paths at the rated clock (a setup problem, 12.4). These are different analyses on different paths, so a clean functional signoff guarantees nothing about shift-path hold or at-speed capture — a chip can pass functional and fail shift (the story: unanalyzed shift-path hold), or pass a slow scan test and miss functional timing (the scan-mux penalty not budgeted, or at-speed not analyzed). The error is treating DFT timing as single-mode when it is fundamentally multi-mode — each DFT addition (scan mux, shift path, boundary cells, SE, clocking) has timing that is active in specific modes, and only analyzing the mode it's active in catches it.
Do multi-mode timing analysis — close functional, shift, and capture/at-speed each with its own clocks and constraints — so every mode's DFT timing is checked. Set up STA to analyze each mode separately (12.5): functional (with the scan-mux penalty budgeted on mission paths, 3.2), shift (the shift-path hold between adjacent cells, with lock-up latches where skew requires, 4.2, on the slow shift clock), and capture/at-speed (the functional capture-path setup at the functional/at-speed clock, with SE settled and OCC, 12.3/12.4). Give each mode its correct clock definitions and case analysis (select the mode) and exceptions (12.5), so STA sees the right active paths per mode. Verify all modes close, not just functional. The principle to lock in: DFT adds real hardware to the design — a scan mux that puts setup delay on every functional path, scan Q-to-SI connections that create new shift-path (hold) timing, boundary cells that add I/O delay, and high-fanout test-control nets — and it introduces multiple modes (functional, shift, capture/at-speed) each with different active paths and different timing, so STA must analyze each mode separately: closing functional timing says nothing about shift-path hold or at-speed capture, so DFT is inherently multi-mode timing and a functional-clean chip can still fail the tester if the test modes were never timed. (Shift vs capture timing is 12.2; scan-enable timing is 12.3; at-speed is 12.4; the STA constraints per mode are 12.5.)
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
- List four DFT additions that affect timing (scan mux, shift path, boundary cells, control signals) and where.
- For each, name the mode(s) STA must analyze it in (functional / shift / capture-at-speed).
- Show why closing functional timing doesn't cover the shift-path hold (different mode, different paths).
- Explain the two failure consequences: functional miss (chip broken) vs test miss (escapes/false fails).
- 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
16b. Where This Is Specified
- Synopsys Design Constraints (SDC).
create_clock,create_generated_clock,set_case_analysis,set_false_path,set_multicycle_path— the tool-neutral constraint vocabulary every STA tool accepts, and the mechanism by which each mode selects its own active paths. - IEEE 1149.1-2013 — Standard for Test Access Port and Boundary-Scan Architecture. The boundary-scan cells whose insertion adds the I/O-path delay described in Section 4, and the TAP that controls them.
- IEEE 1500-2005 — Standard Testability Method for Embedded Core-based ICs. Core-level test wrappers, which introduce the same class of mode-dependent timing at core boundaries.
- IEEE 1687-2014 (IJTAG). Instrument access networks, whose reconfigurable scan paths add further modes that require their own timing analysis.
Scan-mux insertion, lock-up latch placement, and launch-off-shift versus broadside pattern generation are established engineering practice rather than standardised behaviour; they are implemented by the scan-insertion and ATPG tools and documented per tool.
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.
- Hold does not scale with the clock. The period is a term in the setup inequality and not in the hold inequality, so slowing the shift clock buys unlimited setup margin and zero hold margin. A shift failure that ignores frequency is a hold failure, and its fix — a lock-up latch, a reordered chain, added data-path delay — must be in the netlist before tapeout.
- 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.