DFT · Chapter 10 · Boundary Scan & JTAG

Boundary-Scan Cells & the Register

At each chip I/O pin sits a boundary-scan cell that can capture the pin's value and drive a value onto the pin under TAP control. A typical cell is a capture flop, an update flop, and a few multiplexers, and it runs in modes sequenced by the TAP state machine. In normal mode the functional signal passes straight through and the cell is transparent. Capture samples the pin, shift moves data serially from TDI through the cells to TDO, and update latches the shifted value so it drives the pin. Input pins observe, output pins drive, and bidirectional pins add an enable cell. Chaining all the cells from TDI to TDO forms the boundary-scan register, giving control and observation of every pin. Other registers reached through the TAP include a device ID register and a one-bit bypass, and the whole boundary scan is described to the tester by a BSDL file.

Intermediate13 min readDFTBoundary-Scan CellBoundary-Scan RegisterBSDLI/O

Chapter 10 · Section 10.3 · Boundary Scan & JTAG

Project thread — the mini-SoC's pins each get a boundary cell, chained into its BSR; 10.4's instructions operate it, 10.6 uses it to test a net.

1. Why Should I Learn This?

The boundary cell + BSR are what boundary scan actually is — the hardware that gives control/observe of every pin for interconnect test (10.1).

Cell = capture flop + update flop + muxes; modes: normal (transparent) / capture / shift / update.
Input pin → observe (capture); output pin → drive (update); bidir → both + enable.
Chained TDI→TDO = the boundary-scan register (BSR) → control/observe every pin.
Cost: a cell per I/O (area + I/O-path delay); BSDL describes it to the tester.

The five questions — boundary-scan cells & the register

1 — Why does it exist? To give a controllable/observable point at every I/O pin (10.1) — the electronic probe the TAP shifts.
2 — What manufacturing problem does it solve? It lets the tester drive and observe every pin to test the board interconnect (opens/shorts) — and reach on-chip registers (BIST/ISP/debug).
3 — What happens if it's omitted? No BSR → no boundary scan → the board interconnect is untestable on hidden-pin boards (10.1).
4 — Which team owns it? DFT (boundary cells, BSR, BSDL); library/IP (the cell); RTL (transparent normal mode / I/O timing).
5 — How does it connect up/down-stream? TAP (10.2) selects the BSR → the cells capture/drive pins (this lesson) → instructions operate them (10.4) → interconnect/board test (10.5/10.6).

2. Real Silicon Story — the boundary cell that stole timing

A team added boundary scan for board testability, and afterward a timing-critical I/O path started failing setup — and, in a separate case, a pin briefly misbehaved in normal operation. They suspected the boundary-scan insertion had corrupted the design.

Two distinct, understandable effects. First, the boundary cell sits in the I/O path — its mux adds propagation delay on the way to (or from) the pin, exactly like the scan mux in the functional path (3.2). On a thin-slack I/O, that delay was enough to fail setup — a timing issue, not corruption. Second, if the cell's normal-mode transparency is broken or mis-configured (the mux not truly passing the functional signal), it can alter the pin in mission mode.

The fixes were ordinary: budget the boundary-cell delay on the I/O path (or use a faster cell), and verify normal mode is truly transparent so the cell is functionally invisible in mission mode — not remove the cell (which would lose board testability, 10.1). Lesson: a boundary cell is functionally transparent in normal mode but adds a small I/O-path delay (like scan's mux) — budget the delay and ensure transparency, don't delete it.

3. Factory Perspective — the cell & BSR through each lens

What the board-test engineer sees: the BSR and the BSDL file — the map of which cell drives/observes which pin, in what order — to build the interconnect test (10.5).
What the DFT engineer sees: a boundary cell per I/O (area + I/O-path delay) chained into the BSR, plus the BYPASS/IDCODE/user registers.
What the RTL/DV engineer sees: that normal mode must be transparent (no functional impact) and the I/O timing must budget the cell delay — an integration requirement.
What the system engineer sees: that the BSR (control/observe every pin) plus user registers provide board test and the BIST/ISP/debug access doorway (9.5).

4. Concept — the cell, its modes, pin types, and the BSR

The boundary-scan cell (BC_1-style):

Capture flop (samples a value on capture), update flop (holds the value that drives the pin after update), and muxes to select normal vs test behavior and the shift path.
Modes (sequenced by the TAP FSM, 10.2):
- Normal: the functional signal passes through — the cell is transparent (no functional impact).
- Capture: sample the pin/signal into the capture flop (observe).
- Shift: serially shift data TDI → cell → TDO (read out old / shift in new).
- Update: latch the shifted value to the update flop → its output drives the pin (control).

Pin types — what the cell does:

Input pin: the cell captures the incoming value → observe (see what's arriving at the pin).
Output pin: the cell drives a value onto the pin → control (force what the pin outputs).
Bidirectional pin: both capture and drive, plus an output-enable cell to control direction.

The boundary-scan register (BSR):

Chain all the boundary cells, TDI → … → TDO → the BSR: a shift register around the chip's periphery.
Loading the BSR (via the TAP) sets every output pin's drive value; capturing + shifting out reads every input pin's value → control + observe of every pin.

Other data registers (reachable via the TAP, 10.4):

IDCODE — a (typically 32-bit) device-identification register.
BYPASS — a 1-bit register to skip the chip (shorten the chain).
The BSR — as above.
Optional user data registers — e.g. access to on-chip BIST (start/read — the 9.5 bridge), debug, config.

The cost, and BSDL:

A cell per I/O → area and a small delay on the I/O path (like scan's mux, 3.2) — budget it; keep normal mode transparent.
BSDL (Boundary Scan Description Language): a machine-readable file describing the cell order, pin mapping, and instructions — so any board-test tool can use the chip's boundary scan.

Figure 1 - a boundary-scan cell at an I/O pin (representative, BC_1-style). The cell = a CAPTURE flop + an UPDATE flop + MUXes. NORMAL mode: the functional signal passes straight through (transparent -- no functional impact). CAPTURE: sample the pin/signal into the capture flop. SHIFT: serial-shift TDI->cell->TDO. UPDATE: latch the shifted value to the update flop, whose output DRIVES the pin. For an INPUT pin the cell CAPTURES (observe); for an OUTPUT pin it DRIVES (control); a BIDIRECTIONAL pin does both + an output-ENABLE cell. Cost: a mux DELAY on the I/O path (like scan's mux, 3.2).

The cells chain around the chip into the boundary-scan register:

Figure 2 - the boundary-scan register (BSR) around the chip (representative). Every I/O pin has a boundary cell; the cells are CHAINED TDI -> cell(pin1) -> cell(pin2) -> ... -> cell(pinN) -> TDO, forming the BSR around the chip's periphery ('boundary'). Loading the BSR (via the TAP, 10.2) sets EVERY OUTPUT pin's drive value; capturing + shifting out reads EVERY INPUT pin -> control + observe of every pin. The BSR is one of several data registers the TAP can select (BYPASS 1-bit / IDCODE / BSR / user); a BSDL file describes the cell order + pin mapping to the tester.

5. Mental Model — a valve+sensor at every gate of a walled city

The BSR is like fitting every gate of a walled city with a remote-controlled valve and a sensor, all wired to one control room (the TAP).

Each gate is an I/O pin; each valve+sensor is a boundary cell. In peacetime (normal mode), the gate operates normally — the valve is wide open, transparent, traffic flows as usual.
In inspection mode, the control room can close a gate and force a signal out of it (drive an output pin — the update flop) or read what's arriving at a gate (capture an input pin).
All the sensors are wired in a single loop (TDI → … → TDO) so the control room can read every gate's sensor and set every gate's valve by shifting one long chain — that loop is the BSR.
There's a directory (BSDL) that tells the control room which position in the loop is which gate, and whether it's an in or out gate — so any operator can use the city's inspection system.
The cost: each valve adds a tiny delay as traffic crosses it (the I/O-path mux delay) — you budget for it, you don't rip the valves out (you'd lose inspection).

A valve+sensor at every gate, wired into one loop with a directory — that's the boundary-scan register: control/observe every pin from one serial port.

6. Working Example — the cell operating a pin

Trace a boundary cell driving an output and observing an input:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

# Boundary cell operation - REPRESENTATIVE, SIMPLIFIED, tool-neutral:
  NORMAL mode (mission): every cell TRANSPARENT -> functional signals pass through -> NO functional impact.
  DRIVE an OUTPUT pin (control):
    TAP: load an instruction that uses the BSR (e.g. EXTEST, 10.4) ; navigate to Shift-DR
    SHIFT a 1 into the cell for that output pin (through the BSR) ; UPDATE -> the update flop drives 1 onto the pin
  OBSERVE an INPUT pin (observe):
    CAPTURE -> the cell samples the value arriving at the input pin into its capture flop
    SHIFT the BSR out on TDO -> read the captured value for that pin
  BIDIRECTIONAL pin: the cell can drive OR observe, and an output-ENABLE cell sets the direction.
# Chaining all cells TDI->...->TDO = the BSR -> control+observe EVERY pin from the serial port (for interconnect test, 10.6).

7. Industry Flow — the BSR is one of the TAP's data registers

The BSR sits among the TAP's selectable data registers, described by BSDL:

Figure 3 - the boundary-scan register among the TAP's data registers (representative). The TAP (10.2) loads an INSTRUCTION into the IR, which SELECTS one DATA REGISTER between TDI/TDO: BYPASS (1-bit, skip the chip), IDCODE (device ID), the BOUNDARY-SCAN REGISTER (control/observe every pin), or an optional USER register (e.g. BIST access, 9.5). The chosen register is then shifted (Shift-DR). A BSDL file describes the boundary scan (cell order, pin map, instruction codes) so any board-test tool can use it. The BSR is the register that makes interconnect test (10.5/10.6) possible.

8. Debugging Session — an I/O path fails setup after boundary-scan insertion

After boundary-scan insertion a timing-critical I/O path fails setup (or a pin misbehaves in normal operation), and the team suspects insertion corrupted the design; the boundary cell sits in the I/O path and adds a mux delay like scan's mux, and if normal-mode transparency is broken it alters the pin -- so the fix is to budget the I/O-cell delay and verify normal mode is truly transparent, not to remove the cell (which loses board testability)

A BOUNDARY CELL IS TRANSPARENT IN NORMAL MODE BUT ADDS AN I/O-PATH DELAY — BUDGET IT

Symptom

After boundary-scan insertion, a timing-critical I/O path fails setup (and, separately, a pin misbehaves in normal operation). The team suspects the insertion corrupted the design and wants to remove the boundary cell.

Root Cause

The boundary-scan cell sits in the I/O path and adds a mux propagation delay (just like scan's mux), and if its normal-mode transparency is broken or mis-set it alters the pin — neither is corruption; both are known, expected properties of the cell. A boundary cell is inserted between the core logic and the pin (or between the pin and the core), so the functional signal now passes through the cell's mux on its way to/from the pin. That mux has real propagation delay — exactly analogous to the scan-cell mux delay in the functional path (3.2) — so on a thin-slack I/O path, the added delay can violate setup. This is a timing consequence, not logical corruption. Separately, the cell is supposed to be transparent in normal mode (the mux passes the functional signal so the cell is functionally invisible in mission mode); if that transparency is broken (a mis-configured mode control, a wrong mux select), the cell can alter the pin's value in normal operation — again a configuration issue, not 'corruption'. Removing the cell would 'fix' both — but at the cost of losing board testability for that pin (10.1), a bad trade, exactly like deleting a scan cell to pass timing (3.2).

Fix

Budget the boundary-cell I/O-path delay in timing closure, and verify normal mode is truly transparent — keep the cell. For the timing path: budget the boundary-cell delay in the I/O timing constraints from the start (or use a faster boundary cell), and close timing normally — the same way you handle the scan-cell mux delay (3.2). For the transparency issue: verify in simulation that in normal mode the cell passes the functional signal unchanged (the cell is functionally invisible in mission mode), and fix any mode-control / mux-select error. Do not remove the cell — that loses the pin's board testability (interconnect test, 10.1). The principle to lock in: a boundary-scan cell (capture flop + update flop + muxes) at each I/O pin captures the pin (observe) and drives it (control) under TAP control, and chained TDI-to-TDO the cells form the boundary-scan register that controls/observes every pin — but the cell sits in the I/O path, so like scan's mux it is functionally transparent in normal mode yet adds a small I/O-path delay that timing must budget; a setup failure or normal-mode misbehavior after boundary-scan insertion is therefore a timing/transparency issue to close and verify, not corruption, and never a reason to delete the cell and forfeit board testability. (The instructions that operate the BSR are 10.4; the TAP that shifts it is 10.2; scan's analogous mux delay is 3.2.)

9. Common Mistakes

Removing a boundary cell to fix timing. It adds an I/O-path delay (like scan's mux) — budget it, keep the cell.
Assuming the cell is timing-free. It's functionally transparent in normal mode but not delay-free (3.2 analogy).
Breaking normal-mode transparency. The cell must pass the functional signal in mission mode — verify it.
Forgetting the output-enable cell for bidir pins. Bidirectional pins need a cell to control direction.
Shipping without a correct BSDL. Board-test tools need the BSDL to use the boundary scan.

10. Industry Best Practices

Budget the boundary-cell I/O-path delay in timing (like scan's mux, 3.2); use faster cells where needed.
Verify normal-mode transparency — the cell is functionally invisible in mission mode.
Include an output-enable cell for bidirectional pins.
Provide an accurate BSDL — cell order, pin mapping, instructions — for board test.
Chain all I/O cells into the BSR; keep BYPASS/IDCODE/user registers for the full TAP register set.

11. Senior Engineer Thinking

Beginner: "Boundary-scan insertion broke my I/O timing — remove the cell."
Senior: "The boundary cell sits in the I/O path and adds a mux delay — just like the scan mux (3.2). I budget that delay (or use a faster cell) and close timing, and I verify normal mode is transparent so it's invisible in mission mode. I don't delete the cell — that loses board testability for the pin. Same discipline as scan cells."

The senior budgets the I/O-cell delay and verifies transparency — never deletes a boundary cell to pass timing.

12. Silicon Impact

The boundary-scan cell and register are the concrete hardware that turn the TAP's serial access (10.2) into the electronic probe at every pin (10.1). Each cell — a capture flop, an update flop, and muxes — gives a single pin both observability (capture) and controllability (drive), and chaining every I/O cell into the boundary-scan register (BSR) extends that to all pins at once, from one serial port — the exact control+observe needed to test board interconnect (drive one chip's pin, observe the connected chip's pin → opens/shorts) and to reach on-chip registers for BIST/ISP/debug (via user registers, the 9.5 bridge). The engineering discipline mirrors scan almost exactly: the cell is functionally transparent in normal mode (so mission behavior is unaffected), but it sits in the I/O path and therefore adds a small mux delay that timing must budget — a setup failure after insertion is a timing issue, not corruption, and deleting the cell to 'fix' it forfeits board testability, the same bad trade as deleting a scan cell (3.2). The BSDL file is an underappreciated but essential deliverable: it's the machine-readable map (cell order, pin mapping, instruction codes) that lets any board-test tool use the chip's boundary scan — without it, the hardware is inaccessible. For the DFT engineer, the BSR (plus BYPASS/IDCODE/user registers) is the register set the whole chapter operates on; for the RTL/DV engineer, the obligations are budget the I/O-cell delay and guarantee normal-mode transparency; and for the board/system engineer, the BSR + BSDL are what make interconnect test, in-system programming, BIST access, and debug possible on hidden-pin boards. This is the hardware the instructions (10.4) command and the board/in-system operations (10.5) and worked path (10.6) exercise.

13. Engineering Checklist

Placed a boundary-scan cell at each I/O pin; bidir pins have an output-enable cell.
Chained all cells TDI → … → TDO into the BSR; kept BYPASS/IDCODE/user registers.
Budgeted the boundary-cell I/O-path delay in timing (like scan's mux, 3.2).
Verified normal-mode transparency (cell functionally invisible in mission mode).
Produced an accurate BSDL (cell order, pin mapping, instructions) for board test.

14. Try Yourself

Draw a boundary cell (capture flop + update flop + muxes) and its modes (normal/capture/shift/update).
Show an output pin cell driving a value (update) and an input pin cell capturing a value.
Chain several cells TDI → … → TDO into the BSR — explain control/observe of every pin.
Explain why the cell is transparent in normal mode but adds an I/O-path delay (3.2 analogy).
Describe what a BSDL file provides (cell order, pin mapping, instructions) and why board test needs it.

The cell/BSR are IEEE 1149.1; BSDL is standard. No paid tool required to reason about the boundary scan.

15. Interview Perspective

Weak: "Boundary-scan cells let you read and write the pins."
Good: "Each cell can capture or drive its pin; chained together they form the boundary-scan register."
Senior: "A boundary-scan cell — a capture flop, update flop, and muxes — sits at each I/O pin. In normal mode it's transparent (functional signal passes through, no impact); in test it can capture the pin (observe) or drive it (control) via capture/shift/update under the TAP FSM. Input pins observe, output pins drive, bidirectional pins do both plus an output-enable cell. Chaining all cells TDI → … → TDO forms the boundary-scan register — control/observe of every pin — one of the TAP's data registers alongside BYPASS (1-bit), IDCODE, and user registers (BIST access). The cost is a cell per I/O: area + a small I/O-path delay (like scan's mux, 3.2), so I budget it and verify transparency — I never delete a cell to pass timing (I'd lose board testability). And I ship an accurate BSDL so tools can use it."

16. Interview / Review Questions

17. Key Takeaways

A boundary-scan cell (a capture flop + update flop + muxes) sits at each I/O pin and operates in normal (transparent — no functional impact), capture (observe), shift (TDI→cell→TDO), and update (drive the pin) modes under TAP control.
Input pins observe (capture the incoming value), output pins drive (control the pin), and bidirectional pins do both plus an output-enable cell for direction.
Chaining all boundary cells TDI → … → TDO forms the boundary-scan register (BSR) — control and observation of every pin from the serial port, the register interconnect test operates on.
The BSR is one of the TAP's data registers, alongside BYPASS (1-bit), IDCODE (device ID), and optional user registers (e.g. BIST access, the 9.5 bridge).
Cost: a cell per I/O → area + a small I/O-path delay (like scan's mux, 3.2) — budget the delay and keep normal mode transparent; a BSDL file describes the boundary scan so any tool can use it. Next: 10.4 — JTAG instructions (BYPASS, EXTEST, SAMPLE).

18. Quick Revision

Boundary-scan cells & the register. A boundary cell (capture flop + update flop + muxes) at EACH I/O pin: NORMAL = transparent (functional signal passes, no impact); CAPTURE = sample the pin (observe); SHIFT = TDI→cell→TDO; UPDATE = latch → drive the pin (control). Input pin = observe, output pin = drive, bidir = both + output-ENABLE cell. Chain ALL cells TDI→…→TDO = the BOUNDARY-SCAN REGISTER (BSR) → control/observe EVERY pin. One of the TAP's data registers: BYPASS (1-bit) / IDCODE / BSR / user (BIST access). Cost = a cell per I/O → area + a small I/O-path delay (like scan's mux, 3.2) → budget it, keep normal transparent (don't delete → lose board testability). BSDL = machine-readable map (cell order/pin map/instructions) so tools can use it. Next: 10.4 — JTAG instructions.