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).
• Transition/delay defects (2.3) — a gate too slow, a path that doesn't settle in one functional cycle — only fail at functional speed.
• 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:

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

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.