At-Speed Test & Fast Capture

Chapter 12 · Section 12.4 · DFT Constraints & Timing

Project thread — the mini-SoC's OCC gates two fast functional-clock pulses for at-speed capture; 12.3 timed the SE that makes it valid, 12.5 constrains the capture-at-speed mode in STA.

1. Why Should I Learn This?

At-speed test is how you catch timing/delay defects that slow stuck-at test misses — and it's built on fast capture that STA must analyze.

• Slow stuck-at finds static defects; transition/delay defects (2.3) only show at functional speed → need at-speed.
• At-speed = launch + capture one functional period apart → a slow path misses the capture and fails.
• LOC (launch-off-capture, SE slow, common) vs LOS (launch-off-shift, SE fast/critical); an OCC makes the fast edge pair on-chip.
• At-speed paths are real STA paths (setup at the functional period); false at-speed fails from test-setup errors must be masked, not confused with real delay defects.

2. Real Silicon Story — the parts that passed slow but died fast

A chip passed stuck-at test cleanly but failed in the customer's system at functional frequency — a speed-path defect (a slightly slow gate, 2.3) that a slow capture simply couldn't see. The escape was expensive (2.3/1.5).

The fix was at-speed test. Instead of a slow capture, the flow launched a transition and captured one functional-period cycle later — so a too-slow path missed the capture and failed the test, exactly as it failed in the field. To get a clean fast edge pair, an OCC shifted patterns on a slow test clock, then gated in two fast functional-clock pulses (launch + capture) glitch-free — the ATE couldn't deliver those edges cleanly, so the OCC made them on-chip. They used LOC (launch-off-capture) so SE could settle slowly (12.3). And they had STA analyze the capture-at-speed mode so the at-speed paths were real, closed timing paths (12.5) — masking a few false at-speed fails (functional false paths tested as real). At-speed then caught the speed defects, and the escapes stopped. Lesson: slow test finds static defects; at-speed test — launch + capture one functional period apart, fast edges from an OCC — finds the timing/delay defects (2.3) that slow test misses, but its paths are real STA paths you must analyze and clean of false fails.

3. Factory Perspective — at-speed through each lens

• What the test engineer sees: transition/delay patterns with fast capture from the OCC, applied on the ATE — and false at-speed fails to mask.
• What the yield engineer sees: at-speed fallout that stuck-at didn't show — timing-defect yield loss (real delay defects vs false-fail noise).
• What the RTL/DV engineer sees: that at-speed paths are real timing paths (capture=setup at the functional period), so false paths/multicycles must be honored or they become false at-speed fails.
• What management cares about: that at-speed catches field-speed escapes (lower DPPM for speed-sensitive parts, 2.3/1.5) — worth the OCC/SE/STA effort it costs.

4. Concept — at-speed launch/capture, LOC vs LOS, OCC

Why slow test isn't enough:

• Stuck-at uses slow clocks → finds static defects (stuck nodes, 2.2). The multi-mode STA that validates the at-speed run is DFT constraints for STA; the shift-mode half is why DFT affects timing.
• Transition/delay defects (transition-delay faults) — a gate too slow, a path that doesn't settle in one functional cycle — only fail at functional speed, unlike stuck-at faults which slow test catches.
• So: launch a transition, capture one functional-period cycle later → a slow path misses the capture → fails (as it would in the field).

The at-speed event — two fast edges:

• A launch edge then a capture edge, separated by the functional period (not a slow test period).
• Two schemes to create the launch:
  • LOC (Launch-Off-Capture / broadside): launch from the capture edge — the functional logic launches the transition; then capture the next fast edge. SE can be slow (settles between load and the fast pair). Most common, SE-friendly.
  • LOS (Launch-Off-Shift): launch by one more shift (SE still 1 at launch), then SE must go 1→0 fast before capture. Higher coverage of some paths, but SE is timing-critical (the 12.3 race at its worst).

Where the fast edges come from — the OCC:

• An On-Chip Clock controller (OCC): shift on a slow test clock, then gate in exactly two (or N) fast functional-clock pulses (launch + capture) glitch-free (11.2's glitch-free mux, 11.3's test clock).
• Why on-chip: the ATE can't deliver a clean fast edge pair at functional frequency — the OCC produces them from the on-chip PLL/functional clock.

At-speed paths are real timing paths:

• Launch → capture must meet setup at the functional period (12.2's capture=setup, now at-speed) → STA must analyze the capture mode at-speed (12.5).
• A genuinely too-slow path = a real transition-delay fail = the defect you want (lower DPPM).
• A path timing-clean functionally but wrongly in the at-speed test setup (a false path tested as real, a multicycle not honored, an OCC pulse mis-programmed) = a false at-speed fail → mask/constrain, don't confuse with a delay defect.

5. Mental Model — a stopwatch sprint, not a slow walk

At-speed test is a stopwatch sprint for each path; stuck-at is a slow walk that only checks the runner shows up.

• The slow walk (stuck-at) asks: can the runner get from A to B at all? (Is the node stuck?) A slightly slow runner still arrives — so the slow walk passes them.
• The stopwatch sprint (at-speed) fires a starting gun (launch) and a finish-line camera (capture) exactly one functional period apart. A runner who's a bit slow misses the finish photo → fails — which is exactly what you want, because in the real race (the field, functional speed) they'd lose too.
• You need a precise starting-gun/camera pair at race speed — the ATE's timing is too coarse, so an on-chip timer (OCC) fires both from the race clock.
• LOC = the runner launches themselves from the prior finish (functional logic launches, SE relaxed); LOS = a judge shoves them off the start by one extra step (an extra shift, SE must snap back fast).
• And you must make sure the course is legit: if you accidentally timed a shortcut (a false path) or set the wrong distance (OCC mis-programmed), a fast runner posts a false 'too slow' — a false fail to throw out, not a real defect.

A stopwatch sprint at race speed (launch gun + capture camera one functional period apart, fired by an on-chip timer) — a slow runner rightly fails, but check the course before trusting a 'too slow'.

6. Working Example — an at-speed LOC event, real vs false fail

Trace a LOC at-speed event and the real-vs-false-fail distinction:

# At-speed (transition) test - LOC scheme - REPRESENTATIVE, SIMPLIFIED, tool-neutral:
  1) SHIFT   : slow test clock loads the transition pattern into the chains (SE=1)  [SE can settle SLOWLY - LOC]
  2) OCC arms: switch to the FAST functional clock, glitch-free (11.2 mux / 11.3 test clock)
  3) LAUNCH  : fast edge #1 - functional logic launches a 0->1 (or 1->0) transition on the target path
  4) CAPTURE : fast edge #2, ONE FUNCTIONAL PERIOD later - sample the path's response
       fast path  : transition ARRIVES before capture -> correct value captured -> PASS
       slow path  : transition MISSES the capture (too slow) -> wrong value -> FAIL  = real transition/delay defect (2.3)
  5) SHIFT   : unload the captured responses on the slow test clock, compare
# LOS variant: launch by ONE MORE SHIFT (SE still 1 at launch) then SE 1->0 FAST before capture -> SE timing-critical (12.3)
# REAL fail  : a genuinely slow gate/path -> the defect you WANT to catch (lower DPPM)
# FALSE fail : a functional FALSE PATH / MULTICYCLE tested at-speed as a real single-cycle path, or a MIS-PROGRAMMED OCC
#              pulse pair -> the path was never meant to make it in one functional period -> MASK / false-path in STA (12.5)
# STA must analyze the CAPTURE-at-speed mode (12.2 capture=setup, at functional period) to tell REAL from FALSE.

The waveform shows the slow shift then the two fast OCC pulses:

6b. The Timing Budget, Worked

"The transition must arrive before the capture edge" is the mechanism. This is the arithmetic, because until you can compute a slack number you cannot tell a real delay defect from a test-setup error — and they are the two things at-speed test exists to distinguish.

The setup check at capture

An at-speed capture is an ordinary setup check whose period is the functional period rather than the shift period. Two clock insertion delays appear, and their sign convention is the part that trips people:

  arrival  = T_insertion_launch  + T_clk2q + T_comb
  required = T_period + T_insertion_capture - T_setup - T_uncertainty
  slack    = required - arrival

Insertion delay is the clock-network delay from the clock source to that flop's clock pin. It appears with a plus on the launch side because the launch edge happens later at the flop than at the source, and with a plus on the capture side for the same reason — the capture deadline also moves later. What matters for the check is the difference: if the capture flop's clock arrives later than the launching flop's, the skew helps setup; if it arrives earlier, it eats into the budget.

Uncertainty covers jitter plus, for at-speed specifically, variation in the OCC-generated pulse pair. It is subtracted because it can only make things worse.

Case A — a healthy path

  T_period (functional, 1 GHz)     = 1.00 ns
  T_insertion_launch               = 0.30 ns
  T_insertion_capture              = 0.28 ns   <- capture clock 20 ps EARLY
  T_clk2q (launch flop)            = 0.09 ns
  T_comb (path under test)         = 0.55 ns
  T_setup (capture flop)           = 0.06 ns
  T_uncertainty (jitter + OCC)     = 0.05 ns
 
  arrival  = 0.30 + 0.09 + 0.55                = 0.94 ns
  required = 1.00 + 0.28 - 0.06 - 0.05         = 1.17 ns
  slack    = 1.17 - 0.94                       = +0.23 ns   -> PASS

Note the 20 ps of negative skew: the capture clock arriving early cost exactly 0.02 ns of budget. On a path with 0.23 ns of margin that is invisible; on a critical path it is the whole margin.

Case B — a real transition-delay defect

Same silicon, same setup, but a resistive via has slowed one gate on the path:

  T_comb (degraded)                = 0.85 ns   <- was 0.55 ns
 
  arrival  = 0.30 + 0.09 + 0.85                = 1.24 ns
  required = 1.17 ns  (unchanged)
  slack    = 1.17 - 1.24                       = -0.07 ns   -> FAIL

This is the defect at-speed test exists to catch. The part would pass every stuck-at pattern — the node is not stuck, it is slow — and it would fail in the field at rated frequency. Slack is negative by 70 ps, so the captured value is the pre-transition one and the pattern miscompares.

Case C — a false fail from a mis-programmed OCC

Now suppose the OCC was programmed to gate its pulse pair at the reference clock period (0.80 ns) instead of the functional period (1.00 ns). The silicon is healthy — T_comb is back to a good 0.60 ns — but the capture edge arrives 200 ps too early:

  T_period (as actually generated)  = 0.80 ns   <- WRONG: should be 1.00 ns
  T_comb (healthy path)             = 0.60 ns
 
  arrival  = 0.30 + 0.09 + 0.60                = 0.99 ns
  required = 0.80 + 0.28 - 0.06 - 0.05         = 0.97 ns
  slack    = 0.97 - 0.99                       = -0.02 ns   -> FAIL

Nothing is wrong with this part. The test asked it to complete a path in 0.80 ns that the design only ever promised to complete in 1.00 ns.

The three cases have the same symptom — a miscompare on a transition pattern — and completely different meanings. Case B is a part to scrap. Case C is a test program to fix, and scrapping parts because of it is the expensive mistake. Telling them apart is why the capture-at-speed mode has to be closed in STA at the functional period, and why the number the OCC actually generates has to be measured rather than assumed.

Constraining the capture run

# ---- Capture-at-speed run. See /dft/dft-constraints-for-sta for why each
#      mode needs its own file and its own STA run.
set_case_analysis 1 [get_ports test_mode]
# scan_enable is NOT case-analysed here: in LOC it falls between the last shift
# and the launch pulse, so it is a timed net.
 
create_clock -name clk_ref -period 1.000 [get_ports pll_ref]
 
# The OCC gates the functional clock into the launch/capture pair. STA must see
# the generated pulses, not the free-running reference - and the period here is
# the FUNCTIONAL period. Deriving it from anything else is Case C.
create_generated_clock -name occ_cap -source [get_ports pll_ref] -divide_by 1 \
    [get_pins occ/cap_clk_out]
 
set_clock_uncertainty -setup 0.05 [get_clocks occ_cap]
 
# Honour functional exceptions in the at-speed run, or a path that was never
# meant to complete in one cycle reports as a delay defect.
set_false_path      -from [get_pins fp_src/Q]  -to [get_pins fp_dst/D]
set_multicycle_path 2 -setup -from [get_pins mc_src/Q] -to [get_pins mc_dst/D]
 
# LOC (broadside): SE has a full cycle to settle before the launch pulse.
set_multicycle_path -setup 2 -from [get_ports scan_enable]
set_multicycle_path -hold  1 -from [get_ports scan_enable]
# LOS would DELETE the two lines above - there SE must fall between launch and
# capture at the rated clock. Applying the LOC exception to LOS patterns hides
# the hardest path in the design.

  as designed  : required = 1.00 + 0.28 - 0.06 - 0.05 = 1.17 ns
  as generated : required = 0.80 + 0.28 - 0.06 - 0.05 = 0.97 ns
  budget lost                                          = 0.20 ns

# The at-speed capture period must equal the functional period, not the
# reference period. Compute it once, from the same source STA uses.
set FUNC_PERIOD 1.000
create_generated_clock -name occ_cap -source [get_ports pll_ref] \
    -multiply_by [expr {int(0.800 / $FUNC_PERIOD * 1000) / 1000.0}] \
    [get_pins occ/cap_clk_out]
 
# Fail the flow if the generated capture period is not the functional one.
set gen [get_attribute [get_clocks occ_cap] period]
if {abs($gen - $FUNC_PERIOD) > 0.001} {
  error "OCC capture period $gen ns != functional period $FUNC_PERIOD ns"
}

7. Industry Flow — shift slow, pulse fast, capture at period, close in STA

At-speed shifts slowly, pulses two fast edges from the OCC, captures at the functional period, and STA closes it:

8. Debugging Session — at-speed reports massive fails on a good die

9. Common Mistakes

• Relying on stuck-at for speed defects. Static test can't see transition/delay defects (2.3) — you need at-speed.
• Expecting the ATE to make the fast edge pair. It can't cleanly — use an OCC to gate the fast pulses on-chip.
• Not honoring false paths/multicycles at-speed. They become false at-speed fails — apply the exceptions in the at-speed STA (12.5).
• Confusing a false fail with a delay defect. Massive fails on a stuck-at-clean die (false/multicycle paths, wrong OCC) = test-setup noise.
• Using LOS without fast SE. LOS launches from shift → SE must be fast (12.3) or you corrupt the launch.

10. Industry Best Practices

• Use at-speed (transition) test for speed-sensitive parts — slow test misses delay defects (2.3).
• Gate the fast launch/capture pulses with an OCC (glitch-free, 11.2/11.3); don't rely on the ATE.
• Prefer LOC (SE-friendly) unless you need LOS coverage — then make SE fast (12.3).
• Analyze the capture-at-speed mode in STA (setup at the functional period) and apply false-path/multicycle exceptions (12.5).
• Distinguish real delay defects from false at-speed fails before scrapping dies.

11. Senior Engineer Thinking

• Beginner: "At-speed reports tons of fails — the die is bad, scrap it."
• Senior: "It passes stuck-at, the fails are on known false/multicycle paths, and the OCC program is wrong — that's a test-setup problem, not a delay defect. I honor the false-path/multicycle exceptions in the at-speed STA and fix the OCC pulse spacing, then re-run. What's left failing is a real transition-delay defect — the thing I actually want at-speed to catch. At-speed paths are real STA paths; close them, then trust the fails."

The senior closes the at-speed mode in STA and separates real delay defects from false fails before judging a die.

12. Silicon Impact

At-speed test is what turns manufacturing test from a static check into a timing check — and it exists because a whole class of real defects is invisible to slow test. Stuck-at uses slow clocks and finds static defects (a node stuck, 2.2), but a gate that switches too slowly or a path that doesn't settle in one functional cycle — the transition/delay defects of 2.3 — only fail at functional speed. At-speed test recreates that condition: launch a transition and capture one functional-period cycle later, so a too-slow path misses the capture and fails, exactly as it would in the field — catching the speed-path escapes that pass stuck-at yet die in the customer's system, and thereby lowering DPPM for speed-sensitive parts (2.3/1.5). Making that work needs three things this chapter builds: a clean fast edge pair, which the ATE can't deliver, so an On-Chip Clock controller (OCC) shifts on a slow test clock then gates two fast functional-clock pulses glitch-free (11.2/11.3); a launch scheme — LOC (functional logic launches, SE can be slow — the common, SE-friendly choice) or LOS (an extra shift launches, SE must be fast — higher coverage but the 12.3 race at its worst); and — critically — the recognition that at-speed paths are real timing paths, so launch → capture must meet setup at the functional period (12.2's capture=setup, at-speed) and STA must analyze the capture-at-speed mode (12.5). That last point is where at-speed debug lives: a genuinely too-slow path is a real transition-delay fail (the defect you want), but a path timing-clean functionally yet wrongly treated in the at-speed setup — a false path tested as real, a multicycle not honored, an OCC pulse mis-programmed — is a false at-speed fail, a test-setup error you must mask/correct, never confuse with a delay defect, on pain of scrapping good dies. For the test engineer, at-speed is transition patterns + OCC + false-fail masking; for the yield engineer, it's a new fallout population (real delay defects vs test noise); for the STA/DFT engineer, it's a capture mode to close with the same false-path/multicycle exceptions as functional timing. At-speed is the culmination of the chapter's timing thread — it needs capture=setup (12.2), SE timing (12.3), and the SDC constraints (12.5) — and it's the reason functional-clean is not test-clean: a part can meet functional timing yet still carry a speed defect only at-speed test will find.

13. Engineering Checklist

• Used at-speed (transition) test for speed-sensitive logic (slow test misses delay defects, 2.3).
• Gated the fast launch/capture pulses with an OCC (glitch-free); did not rely on the ATE.
• Chose LOC (SE slow) or LOS (SE fast/critical, 12.3) deliberately.
• Analyzed the capture-at-speed mode in STA and applied false-path/multicycle exceptions (12.5).
• Separated real transition-delay defects from false at-speed fails before scrapping dies.

14. Try Yourself

1. Explain why slow stuck-at test can't see a transition/delay defect (2.3) and at-speed can.
2. Trace a LOC at-speed event: slow shift → OCC two fast pulses → launch → capture one functional period later.
3. Contrast LOC (SE slow, common) vs LOS (SE fast/critical) — why LOS needs a fast SE (12.3).
4. Explain why the OCC gates the fast pulses (the ATE can't make a clean fast edge pair).
5. Distinguish a real transition-delay fail from a false at-speed fail (false path/multicycle/OCC mistiming) → what you do about each.

The at-speed timing/scheme reasoning is tool-neutral; the OCC and transition patterns are DFT/ATPG, the analysis is STA (12.5). No paid tool required to reason about at-speed test.

15. Interview Perspective

• Weak: "At-speed test runs the chip at full speed."
• Good: "At-speed launches a transition and captures one fast cycle later, so slow paths fail; the fast edges come from an OCC."
• Senior: "Stuck-at uses slow clocks and finds static defects; transition/delay defects (2.3) only fail at functional speed, so at-speed test launches a transition and captures one functional period later — a too-slow path misses the capture and fails, catching field-speed escapes (lower DPPM). The fast launch/capture pair comes from an OCC (the ATE can't deliver clean fast edges) via LOC (functional logic launches, SE slow — common) or LOS (extra shift launches, SE fast/critical, 12.3). Crucially, at-speed paths are real STA paths — setup at the functional period — so I analyze the capture-at-speed mode and apply false-path/multicycle exceptions (12.5). A genuinely slow path is the real defect I want; a false path/multicycle tested as real or a mis-programmed OCC is a false at-speed fail — a test-setup error to mask, not a delay defect."

16. Interview / Review Questions

16b. Where This Is Specified

• Synopsys Design Constraints (SDC). create_clock, create_generated_clock for the OCC-gated pulse pair, set_clock_uncertainty, set_case_analysis for mode selection, and set_false_path / set_multicycle_path for the functional exceptions that must be honoured in the capture run.
• IEEE 1149.1-2013. The test access port through which OCC programming and test-mode control are typically delivered.
• IEEE 1500-2005. Core test wrappers, whose at-speed capture is constrained by the same launch/capture reasoning at core boundaries.

Transition-delay and path-delay fault models, launch-off-capture versus launch-off-shift pattern generation, and on-chip clock controller architecture are established engineering practice rather than standardised behaviour; they are implemented by the ATPG and scan-insertion tools and documented per tool and per library.

17. Key Takeaways

• Stuck-at uses slow clocks and finds static defects; transition/delay defects (2.3) only fail at functional speed, so at-speed test launches a transition and captures one functional-period cycle later — a too-slow path misses the capture and fails, catching field-speed escapes (lower DPPM, 1.5).
• The at-speed event is a launch edge and a capture edge separated by the functional period, created by LOC (launch-off-capture — functional logic launches, SE can be slow, most common) or LOS (launch-off-shift — extra shift launches, SE must be fast, higher coverage but timing-critical, 12.3).
• An On-Chip Clock controller (OCC) shifts on a slow test clock then gates the two fast functional-clock pulses (launch + capture) glitch-free (11.2/11.3) — because the ATE can't deliver a clean fast edge pair.
• At-speed paths are real timing paths: launch → capture must meet setup at the functional period (12.2's capture=setup, at-speed), so STA must analyze the capture-at-speed mode (12.5).
• A genuinely too-slow path is a real transition-delay fail (the defect you want); a path timing-clean functionally but wrongly in the at-speed setup (false path/multicycle tested as real, OCC mis-programmed) is a false at-speed fail — a test-setup error to mask, not a delay defect. Next: 12.5 — DFT constraints for STA.

18. Quick Revision

At-speed test & fast capture. Slow stuck-at finds static defects; transition/delay defects (2.3) only fail at functional speed → at-speed = LAUNCH a transition, CAPTURE one FUNCTIONAL PERIOD later → a too-slow path misses capture → FAILS (catches field-speed escapes, lower DPPM). Launch: LOC (launch-off-capture, functional logic launches, SE slow, common) vs LOS (launch-off-shift, extra shift launches, SE fast/critical, 12.3). An OCC gates the two fast pulses glitch-free on-chip (11.2/11.3) — the ATE can't make a clean fast edge pair. At-speed paths are REAL STA paths (setup at the functional period, 12.2 capture=setup) → STA the capture-at-speed mode (12.5). REAL too-slow path = the delay defect you want; FALSE at-speed fail (false path/multicycle tested as real, mis-programmed OCC) = a test-setup error to MASK, not a defect. Next: 12.5 — DFT constraints for STA.