Interface Design of the Joint Test Working Group for Field Programmable Gate Arrays
FPGA JTAG Interface Design: What the Joint Test Action Group Standard Actually Requires
The Joint Test Action Group (JTAG) interface is the backbone of board-level testing for any FPGA design. Whether you are validating a new board, running production tests, or debugging silicon in the field, the JTAG interface is the one path that never goes away. Get it wrong, and every downstream test fails. Get it right, and you unlock a reliable, repeatable test infrastructure that scales across your entire product line.
This article walks through the core design decisions you need to make when building a JTAG interface into an FPGA-based system, focusing on the parts that actually matter in practice.
Understanding the TAP Controller: The Heart of Every JTAG Interface
Everything in JTAG flows through the Test Access Port (TAP) controller. This is a 16-state finite state machine that governs how data moves in and out of the device. The TAP does not care what your design does functionally. It only cares about shifting bits through the instruction register and the data register.
The four mandatory signals are TDI (test data in), TDO (test data out), TCK (test clock), and TMS (test mode select). Optional but strongly recommended are TRST (test reset) and SRST (system reset tied to JTAG). Most designs include TRST because it gives you a clean way to force the TAP into a known state during power-up, which avoids the dreaded “TAP stuck in random state” problem that shows up in production test.
Why TAP State Machine Complexity Matters for Your Design
The TAP controller has states like Shift-IR, Shift-DR, Pause-IR, Pause-DR, Update-IR, and Update-DR. Each transition depends on TMS sampled at the rising edge of TCK. If your TCK signal has glitches or if TMS is not stable at the clock edge, the TAP can enter an undefined state. This is not a theoretical concern. In a production environment with long JTAG chains and marginal signal integrity, TAP lockup is one of the most common failure modes.
The fix is simple but often overlooked: add a pull-up on TMS and a pull-down on TRST (or vice versa depending on your reset polarity), and keep TCK clean with series termination close to the FPGA pin. These small choices prevent 80 percent of JTAG initialization failures.
Boundary Scan Architecture: How JTAG Actually Tests Your Board
Boundary scan is the original reason JTAG exists. The IEEE 1149.1 standard defines a set of boundary scan cells that sit between every I/O pin and the internal logic. Each cell can capture the pin state, drive a value onto the pin, or operate transparently. This lets you test interconnects between devices on a board without any physical test probes.
Designing the Boundary Scan Chain for Multi-Device Boards
When you have multiple FPGAs or mixed-device boards (FPGAs plus CPLDs plus microcontrollers), the boundary scan cells from each device get daisy-chained together. TDI of the first device connects to the JTAG host, TDO of the first device connects to TDI of the second, and so on, until TDO of the last device returns to the host.
The chain order matters more than people realize. If you place a device with a large instruction register early in the chain, it adds latency to every access of every device downstream. A practical rule: put devices with small instruction registers (like simple CPLDs) at the end of the chain, and devices you access most frequently (like the main FPGA) at the beginning. This keeps your test execution time low.
Also, pay attention to the TDO drive strength. The last device in the chain must drive TDO with enough strength to reach the host. If your board has long traces or multiple connectors between the last device and the JTAG connector, you may need a buffer on TDO. This is a real-world issue that shows up in system-level integration, not in simulation.
Instruction Register Design: Defining What Your JTAG Interface Can Do
The instruction register is what makes JTAG flexible. Each device in the chain loads an instruction that tells the boundary scan logic what to do. Common instructions include EXTEST (test interconnects), INTEST (test internal logic), SAMPLE (capture pin states), and USERCODE (read device ID).
The USERCODE Instruction and Why You Should Always Implement It
USERCODE returns a 32-bit device identification value. Every FPGA and CPLD should implement this. In a multi-device board, the test software reads the USERCODE from each device in the chain to verify that the right devices are present and in the right order. Skip this, and your test software has no way to validate the chain configuration automatically.
For FPGAs specifically, you can also add custom instructions that access internal debug cores, read configuration memory, or control on-chip test structures. The key is to reserve a range of instruction codes for vendor-specific use and document them clearly. When your test team writes scripts that depend on these custom instructions, undefined behavior costs days of debugging.
Signal Integrity Considerations for JTAG on Real Boards
JTAG runs at relatively low frequencies compared to the rest of your design, typically 1 to 20 MHz. But low frequency does not mean low sensitivity. The TAP controller is edge-triggered, and TMS must meet setup and hold times relative to TCK. If your TCK trace is 15 centimeters long with no termination, reflections can cause double-clocking of the TAP, which corrupts the state machine.
Keep TCK trace length under 10 centimeters where possible. Use series termination (22 to 33 ohms) at the driver pin. Do not route TCK near high-speed differential pairs. The crosstalk from a 5 Gbps SERDES lane can induce enough noise on TCK to cause intermittent TAP failures that are nearly impossible to reproduce in the lab.
For boards that connect to external test equipment through a connector, add ESD protection on all JTAG pins. The TDI and TMS pins are especially vulnerable because they are inputs that the test host drives. A single ESD event can damage the TAP controller permanently, and since the TAP is shared with configuration and debug functions, you lose more than just JTAG access.
Debug Access Port: The Hidden JTAG Interface Inside Every FPGA
Beyond boundary scan, every FPGA implements an internal Debug Access Port (DAP) that uses the same JTAG physical interface but operates through a completely different protocol. This is how you program the FPGA, read back configuration data, and access on-chip debug cores like logic analyzers.
The DAP typically sits behind the boundary scan chain. To reach it, you shift a specific instruction (often called IDCODE or a vendor-specific debug instruction) into the instruction register, then shift data through a separate data register. The exact sequence varies by architecture, but the principle is the same: JTAG is a shared bus, and the instruction register decides which logical device you are talking to.
Keeping Debug and Test Functions from Colliding
A common mistake is treating the JTAG interface as only a test interface or only a debug interface. In reality, both functions share the same four pins. Your test software must be aware of the debug core. When running a boundary scan test, the debug core should be idle. When running a debug session, the boundary scan chain should not interfere.
The cleanest approach is to use the TRST signal to reset both the TAP controller and the debug core simultaneously. This puts both subsystems into a known state before any operation. If TRST is not available, you need a well-defined initialization sequence in your test software that shifts known patterns through the chain to force both subsystems into a safe state.
Practical Checklist for JTAG Interface Design
Before you hand off your board to test, run through these items:
- TMS has a defined pull-up or pull-down so the TAP never floats.
- TRST is connected and tested. If you do not use it, tie it inactive and document why.
- The boundary scan chain order is documented, and the instruction register sizes of each device are known.
- USERCODE is implemented on every device in the chain.
- TCK has series termination and the trace is kept short.
- TDO from the last device reaches the JTAG connector with adequate signal integrity.
- Custom JTAG instructions are documented with their opcodes and expected behavior.
- The test software can initialize the chain, read USERCODE from every device, and shift data through the boundary scan registers without errors.
Skipping any of these will cost you time later. JTAG is one of those interfaces where the design takes ten minutes but the debug takes ten hours if something is wrong.
ChipApex is a global distributor of electronic components: ICs, semiconductors, passives & interconnects. Source active & obsolete parts with wholesale pricing, fast RFQ response, and worldwide delivery.Official website address:chipapex.com
