T27.AI

Blog

BYPASS or a broken shift: two bits of the JTAG IR capture decide

2026-10-09 · 4 min read

[one rule from IEEE 1149.1; the IR value in the recording is typed, not read off a cable] Our JTAG decoder called every even data word BYPASS, whatever had happened on the wire. The standard already gave a way to tell: on Capture-IR every compliant chip loads 01 into the two lowest instruction-register cells. tdo_verdict.t27 now checks those two bits before it looks at bit 0 of the data word, with 8 tests and a mutant that fails 6 of them. A new widget runs the same five checks on any reading you type.

A JTAG decoder reads 32 bits out of a chip and has to say what they mean. A question on X put the weak spot of ours plainly: when the word that comes back has bit 0 clear, how does it tell BYPASS from a shift that is simply broken? Until today it did not. It read only the data word, and an even word looked like BYPASS whatever had happened on the wire.

The rule that was already in the standard

IEEE 1149.1 fixes one thing about every TAP: on Capture-IR, the instruction register loads binary 01 into its two lowest cells. So the first two bits out of TDO after an IR scan are 1, then 0, on every compliant chip. The bits above them are the vendor's. The Xilinx 7-series IR is 6 bits wide, and its BSDL files give the capture value as XXXX01, the upper four being status. We use 0x35 (binary 110101) as the example of that shape; it is not a value we read off a cable in this session.

That gives a check that needs no knowledge of the chip. If the IR capture does not end in 01, the shift is broken: the clock, the TMS sequence, or the TDO path. Then the data word means nothing yet, and calling it BYPASS would send someone to load an instruction on a link that cannot shift.

Five checks, in a fixed order

1. stuck high: the data word is all ones, so nothing drives TDO.
2. stuck low: the data word and the IR capture are both 0.
3. broken shift: the IR capture does not end in 01.
4. BYPASS: the IR capture ends in 01 and bit 0 of the data word is 0.
5. IDCODE: everything else. Only now is the word looked up as a chip ID.

The order is the point. Stuck lines are tested first because they are the narrower diagnosis: a TDO held high also reads the IR as 0x3F, which the IR test would only call a broken shift, without saying why. The IR rule comes before bit 0, so an even word is only called BYPASS once the link has proved it can shift.

Where the rule lives

The rule is a t27 spec: specs/port/tools/jtag/tdo_verdict.t27, with the mask 0x3, the expected value 0x1, and 8 tests over the cases above (gHashTag/t27#8032). The bench command tri fpga-jtag --decode WORD --ir CAPTURE prints the same verdict and exits 0 only for a real IDCODE. The recording below runs three verdicts, the self-test, the spec's own tests, and then a mutant: the capture check replaced by return true. The checker reports 6 failures for the mutant, so the tests do look at that line.

tri fpga-jtag --ir · the IR capture must end in 01

Try it on your own reading

The JTAG verdict widget at t27.ai/widgets/jtag-verdict/ runs the same five checks in the page. Type the IR capture and the data word your probe read, or pick one of the spec's seven test vectors, and it shows which check decided, the bits it looked at, and the tri command that prints the same answer. The values stay in the page; nothing is read from a cable. For a word that passes as an IDCODE, the widget links to the IDCODE decoder, which takes the 32 bits apart field by field.

What this does not show

• A clean verdict means the shift looks sane. It does not mean the chip is configured or the design is healthy.
• The IR value in the recording is typed, not read from our board in this session. The board's IDCODE, 0x13636093, is a real reading from 2026-10-04.
• The bench tri command lives in a local tools folder, not yet in a public repository; the spec and the widget are public.

Work with me

Need an FPGA/RTL problem taken to measured hardware?

I work contract and part-time on hardware-AI, FPGA/RTL and ML systems — from specification and open toolchains to reproducible measurements.

Discuss your projectSee how I work