Silicon Bring-up · All levels

JTAG and IEEE 1149.1 Boundary Scan: Worked Example

Worked Example for JTAG and IEEE 1149.1 Boundary Scan.

Worked example

Worked Example for JTAG and IEEE 1149.1 Boundary Scan is anchored on Board-level interconnect defect coverage, boundary-scan chain integrity rate, and mean time from first power-on to pin-level fault localization.. Convert observed behavior into mechanism-backed and owner-bound actions.

A release blocker appears in Board-level interconnect defect coverage, boundary-scan chain integrity rate, and mean time from first power-on to pin-level fault localization.. Strong closure isolates first failing boundary, proves mechanism, applies one reversible fix, and validates blast radius before signoff.

Execution lens

diagram
SILICON BRING-UP FLOW - JTAG and IEEE 1149.1 Boundary Scan

symptom intake and setup state freeze
      |
      v
dependency map: power/reset/clock/interface/firmware
      |
      v
instrumented experiment with one-variable branch
      |
      v
first failing boundary classification
      |
      v
bounded mitigation and replay validation
      |
      v
owner signoff with rollback criteria

Decision matrix

diagram
EVIDENCE MATRIX - JTAG and IEEE 1149.1 Boundary Scan

+-------------------------------+--------------------------------+--------------------------------+-----------------------------+
| Evidence                      | Tells you                      | Does not prove                 | Next action                 |
+-------------------------------+--------------------------------+--------------------------------+-----------------------------+
| rail/current timeline         | sequencing and power health    | firmware or protocol integrity | align with stage logs       |
| stage checkpoint logs         | failing transition boundary    | electrical root cause          | correlate with scope traces |
| interface trace/decode        | protocol behavior and timing   | global platform readiness      | replay under fixed setup    |
| shmoo/corner matrix           | margin-sensitive fail region   | exact failing mechanism        | isolate with targeted tests |
| before/after replay packet    | mitigation movement quality    | long-run stability             | run soak and corner matrix  |
+-------------------------------+--------------------------------+--------------------------------+-----------------------------+

Silicon bring-up deep dive

Debug interfaces are useful only when access paths are trusted, minimally intrusive, and synchronized to failure context.

Concept diagram

diagram
DEBUG ACCESS STACK

physical probes -> debug transport -> trace/scan capture -> correlated analysis

Metric graph

diagram
OBSERVABILITY MATURITY

access failures          ████
partial captures         █████
actionable captures      ███████

Metrics and artifacts to collect

  • JTAG/SWD access success rate

  • trace trigger hit coverage

  • scan dump decode turnaround time

  • observability gap backlog

Mini case study

A misdiagnosed silicon issue was cleared after TAP chain validation revealed a board-level debug domain assumption error.

Debug branches

  • Validate access-layer prerequisites before deep protocol decode.

  • Correlate trace timestamps with software checkpoints.

  • Treat missing evidence as an observability gap, not closure.

Senior review question

Ask: what is the first failing boundary, which artifact proves it, and who owns bounded closure?

Key takeaways

  • Tie every bring-up claim to one reproducible setup state and one proving artifact.

  • Prefer bounded fixes with clear owner and rollback trigger over broad multi-variable edits.

Common pitfalls

  • Running parallel uncontrolled experiments and losing causality.

  • Declaring closure without replaying across representative corners.

  • Escalating severity before bench/setup hypotheses are disproven.

Worked-example reasoning

Start with synchronized evidence rather than speculative fixes.

Keep mitigation reversible until recurrence risk is measured.