Design for test

The engineering objective

Plan and implement test access so manufacturing defects can be targeted without compromising functional operation.

The work starts from test architecture, clock/reset definitions, memory inventory, power domains and tester limits. The team should identify the authoritative revision of each input and record any assumptions needed to proceed. This prevents a later result from being interpreted against a different specification or configuration.

What needs technical attention

Fault coverage is meaningful only with its fault model and exclusions; tester memory and power can limit usable patterns.

The review centres on scan connectivity, test clocks, unknown sources, coverage exclusions and shift/capture power. Each finding should identify the input revision, observed behaviour and supporting evidence. Distinguish a confirmed defect from a configuration issue, an unsupported case or an open engineering question before deciding how to resolve it.

How the work is reviewed

The practical sequence is: define test modes; insert scan and control logic; generate patterns; verify test-mode operation and review coverage. Intermediate reviews allow the client to resolve decisions while changes are still manageable. If an input changes, identify the affected activities and repeat the checks that depend on it.

The expected package comprises test architecture, scan collateral, pattern reports, test constraints and integration notes. Acceptance criteria should specify what the receiving team needs to reproduce, inspect or integrate these artifacts. Include known limitations and outstanding actions in that package, rather than assuming that delivery of a file implies acceptance.

Connect test intent to usable manufacturing patterns

Test logic has to work within the design’s clock, reset and power architecture. Identify which test modes are legal, how they are entered, which domains remain powered and how functional interfaces are isolated. Review the sources of unknown values and the controls needed to make scan shifting and capture deterministic. A test mode that works only under an undocumented assumption is difficult to transfer to another team.

Coverage discussions should name the fault model, denominator and classification of excluded or untestable faults. Pattern generation can expose design-rule issues, uncontrollable signals or protocol assumptions that require architecture changes. Separate those causes from faults that simply need better stimulus or additional ATPG effort. Preserve enough detail for a reviewer to understand why a target was or was not met.

Pattern count, tester memory, shift frequency and capture activity affect whether a pattern set is practical. Agree these constraints early and revisit them after integration. The handoff should connect patterns to the exact netlist, test protocol and configuration used to generate them. Simulation results, mode-entry checks and known restrictions should travel with the pattern package so downstream teams can reproduce the intended test conditions.

An illustrative review scenario

A memory output that is uncontrolled during scan capture can contaminate a compressed response. Review whether the correct solution is mode control, isolation, a justified mask or an architecture change. Check the resulting fault coverage and power implications rather than masking broadly to obtain a clean simulation. The example illustrates a diagnostic approach, not a universal test insertion recipe.