Test point insertion in DFT

In short: Test point insertion (TPI) adds dedicated control and observe points into a design so that ATPG can toggle and sense otherwise random-resistant nodes, trading a small amount of area, extra flops and minor timing margin for a large jump in stuck-at and especially LBIST coverage.

If you have ever watched a logic-BIST run stall at 92% stuck-at coverage no matter how many patterns you throw at it, you have met the problem that test points solve. Deeply embedded nodes behind wide AND/OR trees, long reconvergent fanout, or redundant-looking logic are simply hard to control (drive to a known value) and hard to observe (propagate to a scan flop). Test point insertion surgically breaks that bottleneck.

Controllability and observability — the two failure modes

Every testability problem reduces to one of two things. A node has poor controllability if a pattern generator struggles to force it to 0 or 1 — think of the output of a 16-input AND gate, which needs all inputs high to go to 1. A node has poor observability if, once a fault flips its value, that difference cannot reach a capture point. SCOAP (Sandia Controllability/Observability Analysis Program) metrics quantify both; EDA tools such as Synopsys TestMAX (DFTMAX/TetraMAX lineage), Siemens Tessent TestKompress, and Cadence Modus compute per-node numbers and rank candidates automatically.

Rule of thumb: a control point fixes a hard-to-control node; an observe point fixes a hard-to-observe node. Most random-pattern-resistant designs need far more control points than observe points.

What a control point actually looks like

A control point inserts a small mux (or AND/OR force gate) on a net. In functional mode the mux passes the original signal through untouched. In test mode a test-enable selects a forcing value driven by a dedicated flop. A control-0 point ANDs the net with a test signal to force 0; a control-1 point ORs it to force 1; a full control point uses a 2:1 mux so either value can be injected from a scan cell.

Observe points are cheaper structurally: they simply tap a net and route it to a new scan flop (or XOR it into an existing scan path / MISR in BIST), so the node's value is captured and shifted out. No functional path is cut, which is why observe points carry essentially zero functional-timing risk.

Why test points dramatically raise coverage

In deterministic ATPG, test points mostly help you hit the last stubborn few percent and shorten pattern count. In logic BIST, where pseudo-random patterns from an LFSR drive the logic, they are often the difference between shipping and not shipping. Random patterns rarely satisfy a 16-input AND; the probability of all inputs being 1 is 2⁻¹⁶. A single control-1 point on that node lets the LFSR reach it in one cycle.

Typical outcome: inserting ~1% extra flops as test points can lift LBIST stuck-at coverage from the low 90s to 98–99%, and cut deterministic pattern count by 20–40% on random-resistant blocks. The exact numbers depend on logic depth and reconvergence.

Here is the counter moving under random stimulus

The cost side of the ledger

Test points are not free. Every control point adds a mux in a functional path, which means extra gate delay — on a timing-critical net this can eat 30–80 ps and must be budgeted before placement. Each test point (control or observe) also needs a dedicated scan flop, adding area and to the scan-shift length. The table below summarizes the trade-offs engineers weigh.

Good tools let you blacklist timing-critical nets, cap the total test-point budget, and share driver/capture flops across many points to limit area. A common flow runs TPI after synthesis and scan stitching but before place-and-route hand-off, so delay impact can still be absorbed. Treat test points as part of your overall DFT flow; they interact with scan compression ratio and the logic BIST architecture you choose.

Practical guidance for insertion

• Run SCOAP analysis first; only insert where metrics flag a real bottleneck — blanket insertion wastes area.
• Prefer observe points when timing margin is tight; they carry no functional delay.
• Protect clock, reset, and high-speed critical nets with a no-touch list.
• Re-run ATPG after insertion to confirm the coverage gain actually materialised and pattern count dropped.
• Watch the scan chain length: too many points balloon test time and tester memory.

Teams building security or custom silicon often pair rigorous TPI with external design-services expertise — for instance Avecas VLSI design services when a block refuses to cross a coverage threshold on its own.

Want to run SCOAP, insert test points, and close coverage hands-on with TestMAX and Tessent? Explore the CourseTron DFT engineering track and build a tapeout-ready testability flow.

Frequently asked questions

Do test points change functional behaviour?

No. In functional mode the mux passes the original signal unchanged and observe taps are read-only. They only activate when the test-enable asserts, so the shipped chip behaves identically to the design without them.

How many test points is too many?

There is no fixed limit, but most teams cap TPI at roughly 1–3% of flop count. Beyond that, area, scan-shift time, and tester cost grow faster than the coverage you gain. Let SCOAP metrics, not a quota, drive placement.

Are test points needed if I already have scan compression?

Often yes. Compression shrinks pattern volume but does not make an uncontrollable node controllable. Test points attack the fundamental reachability problem, which is especially acute in pseudo-random LBIST.

Which tools insert test points automatically?

Synopsys TestMAX DFT, Siemens Tessent (TestKompress and LogicBIST), and Cadence Modus all compute testability metrics and insert control/observe points under user-defined budgets and exclusion lists.