In short: An on-chip clock controller (OCC) is a small piece of DFT logic that lets slow, ATE-controlled scan shift clocks load a scan chain, then cleanly fires a precise burst of fast functional PLL pulses — usually two for launch-and-capture — so you can catch timing (delay) defects at the chip's real operating speed.
At advanced nodes, a huge share of silicon failures are not stuck-at opens or shorts but timing defects: a resistive via, a bridging fault, or a slow transistor that only misbehaves when the clock period is tight. You cannot find those at the few-MHz shift rate an automatic test equipment (ATE) delivers. You need to launch a transition and capture its result one functional clock period later. The on-chip clock controller is the circuit that makes that possible inside the die, and it is one of the most frequently probed topics in a DFT interview.
Why scan clocks cannot test at speed
In a standard scan-compression flow the tester drives a shift clock at perhaps 10–50 MHz. That is fine for loading and unloading scan chains, but a chip rated at, say, 1.25 GHz has a functional period of 800 ps. The board, the probe needle and the ATE channels simply cannot deliver a clean 800 ps edge to every flop. The clean high-frequency edges already exist inside the chip — they come from the PLL. The OCC's job is to borrow that PLL and gate out exactly the pulses ATPG asks for.
A typical at-speed test applies a 2-pulse window: pulse 1 (launch) changes a flop output, pulse 2 (capture) samples the result one functional period later. The gap between them is the defect detector.
Anatomy of an OCC
A classic OCC (the Synopsys DFTMAX / Tessent "clock controller" style) contains four things: a clock multiplexer that selects between the ATE shift clock and the PLL fast clock; a small shift register (the clock-chain) that is programmed during scan load to say how many fast pulses to emit; a synchronizer that re-times the asynchronous PLL domain against the scan-enable handshake; and gating logic that produces the final burst.
Launch-on-capture vs launch-on-shift
At-speed transition testing comes in two flavours, and the OCC supports both:
- Launch-on-capture (LOC), also called broadside. The scan chain is loaded, scan-enable de-asserts, and the OCC fires two fast pulses from one functional path. LOC gives the most realistic timing but ATPG must solve both launch and capture from loaded state, so coverage can be a few points lower.
- Launch-on-shift (LOS), also called skewed-load. The last shift edge launches the transition and the first capture edge samples it. LOS reaches higher coverage but needs a fast, timing-closed scan-enable, which is expensive to route to every flop.
On a large SoC, LOC transition patterns typically recover 85–92% transition coverage; adding a small LOS set can push combined transition coverage past 95%, which is why many teams run both.
The clock-chain: how you program the pulses
The OCC's shift register is stitched into a dedicated scan chain. During pattern generation the ATPG tool (Synopsys TestMAX/TetraMAX, Siemens Tessent, or Cadence Modus) writes a bit pattern into it — for a two-pulse LOC test it loads something like 0 1 1 0 so that exactly two consecutive PLL edges are enabled. Because the count is data, the same OCC can emit 1 pulse (stuck-at), 2 pulses (transition), or N pulses for path-delay or memory BIST without any hardware change. This is the real elegance of the design: timing behaviour becomes a scan-programmable choice.
Synchronization and glitch safety
The hardest part of an OCC is not the counter — it is crossing from the slow, tester-controlled scan-enable domain into the fast, free-running PLL domain without producing a runt or glitch clock. A glitch here can corrupt the capture and show a false failure that wastes days of silicon debug. Real OCCs use a two- or three-stage synchronizer on the PLL side and an AND-gate structure that only ever gates on clock low, guaranteeing whole pulses. Static timing with Synopsys PrimeTime must be run in a dedicated at-speed test mode so the launch-to-capture path is checked against the functional period, not the shift period.
OCC and multiple clock domains
Modern SoCs have many PLLs. Each independent clock domain usually gets its own OCC, and the ATPG tool must decide whether domains pulse simultaneously (more coverage, but cross-domain paths may give pessimistic timing) or staggered one domain at a time (clean timing, more patterns, more test time). Managing inter-clock skew and the resulting pattern count is a core trade-off DFT engineers negotiate with the STA and test teams.
| Mode | Pulses | Target defect | Clock source |
|---|---|---|---|
| Stuck-at | 1 | Opens / shorts | ATE or 1 PLL pulse |
| Transition (LOC) | 2 (broadside) | Slow-to-rise/fall | PLL burst |
| Transition (LOS) | 2 (skewed-load) | Slow-to-rise/fall | Shift edge + PLL |
| Path delay | 2–N | Critical paths | PLL burst |
If you want the companion picture of why these two edges catch a defect, read our deep dive on at-speed testing, and for the pattern-compression context that keeps OCC test time affordable see scan compression and EDT. Teams that design these controllers as part of a production tapeout often lean on specialist VLSI design and DFT services from Avecas to close timing on the launch-capture paths.
Want to build and debug an OCC in a real ATPG flow, with TestMAX and Tessent hands-on? Our DFT track on CourseTron courses walks you from scan insertion to at-speed pattern sign-off.
Frequently Asked Questions
Why does at-speed testing need exactly two pulses?
One pulse launches a logic transition at a flop output; the second pulse, one functional period later, captures the result. If a path is too slow, the new value has not arrived and the captured bit is wrong — that mismatch is the delay defect being detected.
What is the difference between LOC and LOS?
Launch-on-capture (broadside) launches from loaded scan state and is more timing-realistic but slightly lower coverage. Launch-on-shift (skewed-load) launches on the final shift edge, reaching higher coverage but demanding a timing-closed, fast scan-enable network.
Why not just drive the fast clock from the tester?
ATE channels, the load board and probe needles cannot deliver clean sub-nanosecond edges to millions of flops. The PLL already produces those edges on-die, so the OCC gates the existing clean clock instead.
What causes a false fail in an OCC-based test?
Almost always a glitch or runt pulse from a bad clock-domain handshake, or an STA run that checked the shift period instead of the functional period. Correct low-gating synchronizers and an at-speed timing mode prevent it.