Scan and compression

The engineering objective

Implement scan access with controlled chain balancing and compression.

The work starts from netlist, scan cells, clock definitions and chain 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

Compression trades tester data volume against on-chip overhead and unknown-value handling.

The review centres on chain continuity, lockup handling, balance and unknown propagation. 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: check scan eligibility; insert chains and compression; connect test control; validate shift operation. 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 scan netlist, chain definitions, constraints and insertion reports. 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.