DFT architecture

The engineering objective

Plan test modes and access before scan insertion.

The work starts from clock domains, memories, power states and ATE 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

Architecture decisions determine which faults can be observed and controlled downstream.

The review centres on testability gaps, mode isolation and shift/capture budgets. 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: map test targets; allocate access and control; plan compression and memory test; review integration. 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 DFT specification, access diagrams and implementation constraints. 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.