Planning scan test without losing the system context

The starting problem

A hypothetical digital subsystem is preparing for scan insertion. It contains several clock domains, memories and logic that may be powered down in normal use. The first question is whether the proposed test architecture can control and observe the relevant logic safely. A list of scan chains is not yet a complete test strategy.

This example discusses planning and review. It does not claim an achieved coverage percentage, an implemented compression ratio or a production yield result. Those quantities depend on actual design data, fault models, constraints and tester conditions. Keeping the study qualitative avoids suggesting that a result from one design can be transferred to another.

Map test modes to real resources

Inventory clocks, resets, power domains, memories, analog boundaries and external access pins. Identify which resources are available during shift and capture and which controls must be overridden. Review whether a clock can be stopped, selected or pulsed in test mode without creating unintended activity elsewhere.

A test-mode table should distinguish scan shifting, capture, memory test and any boundary-test functions. Show the required power state and reset state for each. Where infrastructure is supplied by another team, record ownership and the evidence expected at integration. Test access that exists only in a block diagram is not enough if package or board constraints make it unavailable later.

Review controllability and unknown values

Uncontrolled memories, analog outputs and asynchronous interfaces can introduce unknown values into test responses. Identify those sources and decide how they will be isolated, constrained or observed. Every masking choice should have a reason because it can also reduce what a test can detect.

Structural checks should examine scan connectivity, clock and reset control, and rule violations appropriate to the chosen flow. Resolve the cause of a violation rather than simply suppressing its report. If a waiver is required, document its scope and effect on the test plan. A quiet log is not equivalent to a justified architecture.

Interpret ATPG evidence carefully

Coverage numbers require a denominator and a fault model. Review detected, untestable, aborted and excluded fault categories separately, using the terminology of the actual tool and project. A change in constraints can alter the reported number without improving the testability of the hardware.

For a problematic region, trace representative faults back to missing control, observation limits or legitimate functional constraints. Compare candidate fixes against area, timing, routing and test-power consequences. Pattern count, shift cycles and capture requirements also affect test time. The engineering decision is a balance of test quality and implementation feasibility, not a race to a context-free percentage.

Connect the design to the tester

Production handoff needs more than generated patterns. Agree pin mapping, timing conventions, initialization, expected responses and any required sequencing. Review the relationship between simulation conditions and the intended tester environment. Where practical, preserve a small diagnostic pattern set that can help distinguish access problems from failures in the tested logic.

At bring-up, unexpected results can arise from the device, package, board, tester setup or pattern translation. A disciplined handoff records enough context to investigate those possibilities. The responsibilities of design, DFT, product engineering and the external test partner should be explicit before the first silicon arrives.

A useful architecture-review exercise

Choose one clock domain and walk through the complete test sequence: entry into test mode, reset setup, shift, capture and exit. Ask which controls are generated on chip, which come from external access and which depend on another domain remaining powered. Repeat the exercise for a memory-test operation and identify shared resources. A conflict is easier to resolve in this sequence review than after the pattern infrastructure has been built.

Next, select a representative unknown-value source and follow its effect to an observation point. Determine whether the proposed handling removes only invalid data or also hides useful response information. Record the reasoning and any additional test required. The aim is to understand the tradeoff rather than automatically maximizing masking or constraining every difficult signal.

Finally, ask the downstream test owner to describe how the sequence will be applied and diagnosed. Compare the assumptions on both sides of the handoff. If the tester cannot provide a required control or the package does not expose a planned access path, the architecture needs revision. This exercise produces concrete interface questions before the team commits to a large implementation or pattern-generation campaign.

A reviewable outcome

The illustrative outcome is a test-architecture package with mode tables, rule-check findings, coverage analysis and an open-issue register. Acceptance would require project-specific reports and the agreed functional and implementation checks. Any remaining coverage limitation should be described in terms a receiving engineer can investigate.

The case shows why DFT starts with system constraints and continues through implementation and handoff. It does not replace a manufacturing test programme or guarantee detection of every defect. A focused architecture review can establish which inputs and experiments are needed before committing to a broader test implementation.

What to bring. What to review.

Questions before you begin.