DFT verification

The engineering objective

Check inserted test structures and protocols before pattern release.

The work starts from pre/post-DFT design, test modes, protocols and pattern samples. 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

Test-only logic still affects functional paths and must be reviewed in both modes.

The review centres on scan operation, test resets, simulation mismatches and functional equivalence assumptions. 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: verify mode entry; simulate scan shifts; exercise capture; compare functional behaviour. 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 verification tests, waveforms, results and unresolved issues. 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.