Boundary scan and JTAG

The engineering objective

Enable controlled board and device test access through a documented test interface.

The work starts from pin list, TAP requirements, board chains and security restrictions. 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

Debug and test access need a deliberate lifecycle policy for development and deployed products.

The review centres on instruction decoding, reset state, chain length and functional isolation. 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: plan boundary cells; implement TAP connectivity; verify instructions; validate board-chain access. 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 boundary-scan description, test sequences 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.