In short: Test-point selection uses SCOAP-style controllability and observability cost estimates (plus random-pattern detectability analysis) to rank the hardest-to-test nodes, then inserts control points at low-controllability nets and observe points at low-observability nets to push random-pattern fault coverage from the low-90s toward 99%+ while keeping area and timing overhead small.
Logic BIST designers live and die by random-pattern resistance. A handful of stubborn nodes, deep AND/OR trees, wide comparators, redundant-looking decode logic, can cap coverage at 92–94% no matter how many pseudo-random patterns the LFSR pumps in. The fix is not more patterns; it is a few dozen well-placed test points. This article explains how test-point selection algorithms actually decide where those points go, starting from SCOAP measures and ending at the cost-benefit heuristics inside Synopsys TestMAX, Siemens Tessent, and Cadence Modus.
Why random patterns stall: controllability and observability
A fault is detected only when a pattern (1) sets the faulty node to the opposite value (activation, a controllability problem) and (2) propagates that difference to a scan flop or primary output (observation, an observability problem). If either probability is tiny, the fault is "random-pattern resistant."
Consider an 8-input AND gate. Driving its output to 1 needs all eight inputs at 1 simultaneously — probability 1/256 under uniform random stimulus. Any stuck-at-0 on that output is activated only once every ~256 patterns, and that is before you account for the controllability of each input net upstream. Observability is the mirror image: a node buried under a long reconvergent cone may need a specific side-input assignment to create a sensitized path, so its signal rarely reaches a capture point.
SCOAP: putting numbers on "hard to test"
SCOAP (Sandia Controllability/Observability Analysis Program, Goldstein, 1979) assigns each net six integer costs, computed by a single topological pass. They are relative effort estimates, not exact probabilities, which is exactly why they are cheap enough to run on multimillion-gate designs.
- CC0 / CC1 — combinational controllability: relative effort to set a net to 0 / to 1.
- CO — combinational observability: effort to propagate the net's value to an output.
- SC0 / SC1 / SO — the sequential counterparts, counting clocked stages crossed.
The recurrences are simple and local. For a 2-input AND with inputs a, b: CC1(out) = CC1(a) + CC1(b) + 1 (both inputs must be 1), and CC0(out) = min(CC0(a), CC0(b)) + 1 (either input at 0 suffices). The "+1" charges one gate level of effort. Primary inputs start at CC0 = CC1 = 1, CO = 0. Observability flows backward: CO(a) = CO(out) + CC1(b) + 1 — to observe a through the AND, you must hold b at the non-controlling value 1, then observe the output.
A high CC1 means "expensive to drive to 1" (a candidate for a control-1 point); a high CO means "hard to see" (a candidate for an observe point). Test-point tools rank nodes by exactly these costs.
From costs to point placement
Two families of test points exist. Control points insert an OR gate (control-1, forces the node high when a dedicated test-enable is active), an AND gate (control-0, forces it low), or a mux driven by an extra scan flop. Observe points tap the node and route it to a dedicated observe scan flop or an XOR-compaction tree, so its value is captured without needing a full sensitized path.
The classic algorithm (Seiss/Trouborst-style and the COP-based cost model of Brglez) works as follows:
- Estimate per-node signal probability and detectability (COP: Controllability/Observability Program uses 0–1 probabilities rather than SCOAP integers).
- Compute each node's contribution to the design's overall fault detection probability.
- Greedily pick the single test point whose insertion most increases estimated coverage, re-score affected nodes, and repeat until a budget (point count or target coverage) is hit.
The greedy re-scoring matters: one well-placed observe point at the apex of a deep cone can "fix" hundreds of downstream-invisible faults at once, so inserting it changes the ranking of everything else. Modern tools from Siemens (Tessent LogicBIST) and Synopsys (TestMAX / DFTMAX LogicBIST) layer gradient-based and, increasingly, learning-guided scoring on top of this loop, but the SCOAP/COP foundation is unchanged.
A worked ranking example
| Net | CC1 | CO | Diagnosis | Point inserted |
|---|---|---|---|---|
| n_and8_out | 9 | 4 | Very hard to set to 1 | Control-1 (OR + TE) |
| n_cmp_eq | 6 | 11 | Buried under compare cone | Observe flop |
| n_decode[3] | 7 | 9 | Low ctrl + low obs | Control-0 + observe |
| n_fifo_full | 2 | 3 | Already easy | None |
Rule of thumb from production LBIST flows: roughly 1 test point per 1,000–3,000 gates lifts random-pattern coverage from ~90% to ~99%, with control/observe points split close to 50/50 and area overhead typically under 2%.
Cost, timing, and placement discipline
Every control point adds a gate in a functional path, so blind insertion can create new critical paths. Good flows exclude timing-critical nets from the candidate list, prefer observe points (which are off the functional path) when they buy comparable coverage, and share observe flops through XOR trees to limit flop count. You should also avoid inserting points inside already-tested, deterministically-covered logic — spend the budget where random patterns fail, which is what the SCOAP ranking tells you. For a deeper treatment of the physical gates and scan-flop wiring, see our companion piece on test points in DFT, and pair this with the fundamentals in scan chain architecture.
Teams building silicon-ready LBIST often validate these insertions against gate-level fault simulation before signoff. If you want hands-on design-for-test support on a real tapeout, the engineers at Avecas VLSI design services run these flows end to end.
Want to master SCOAP, LBIST, and test-point insertion with real tool labs? Explore the DFT track in the CourseTron course catalog and build an LBIST-ready block from scratch.
Frequently asked questions
Is SCOAP the same as actual fault-detection probability?
No. SCOAP gives integer effort estimates computed in one pass, so it is fast but approximate. Probability-based measures (COP) and random-pattern fault simulation give truer detectability but cost far more compute, so tools use SCOAP/COP to rank candidates and simulation to confirm.
When do I use a control point versus an observe point?
Use a control point when a node is hard to drive to a value (high CC0 or CC1) so you cannot activate the fault. Use an observe point when a node is hard to see (high CO) so an activated fault cannot propagate. Nodes bad on both get both.
How many test points is too many?
There is diminishing return: the greedy algorithm's coverage gain per point drops sharply after the worst nodes are fixed. Most flows cap at a few hundred to low-thousands of points for large blocks, watching area and the introduction of new critical paths.
Do test points hurt functional performance?
Control points sit in functional paths and can add delay, so timing-critical nets are excluded as candidates. Observe points tap the net without driving it, so they are far less intrusive and are preferred when they give comparable coverage.