JTAG Communications model

https://en.wikipedia.org/wiki/Joint_Test_Action_Group

In JTAG, devices expose one or more test access ports (TAPs).

The picture above shows three TAPs, which might be individual chips or might be modules inside one chip.

A daisy chain of TAPs is called a scan chain, or (loosely) a target.

Scan chains can be arbitrarily long, but in practice twenty TAPs is unusually long.

To use JTAG, a host is connected to the target's JTAG signals (TMS, TCK, TDI, TDO, etc.) through some kind of JTAG adapter,

which may need to handle issues like level shifting and galvanic isolation.

The adapter connects to the host using some interface such as USB, PCI, Ethernet, and so forth.

Primitives

The host communicates with the TAPs by manipulating TMS and TDI in conjunction with TCK,

and reading results through TDO (which is the only standard host-side input).

TMS/TDI/TCK output transitions create the basic JTAG communication primitive on which higher layer protocols build:

• State switching ...
  All TAPs are in the same state, and that state changes on TCK transitions.
  This JTAG state machine is part of the JTAG spec, and includes sixteen states.
  There are six “stable states” where keeping TMS stable prevents the state from changing.
  In all other states, TCK always changes that state.

  In addition, asserting TRST forces entry to one of those stable states (Test_Logic_Reset),
  in a slightly quicker way than the alternative of holding TMS high and cycling TCK five times.

• Shifting ...
  Most parts of the JTAG state machine support two stable states used to transfer data.
  Each TAP has aninstruction register (IR) and a data register (DR).
  The size of those registers varies between TAPs, and those registers are combined
  through TDI and TDO to form a large shift register.
  (The size of the DR is a function of the value in that TAP's current IR, and possibly of the value specified by a SCAN_N instruction.)
  There are three operations defined on that shift register:
  • Capturing a temporary value
    • Entry to the Shift_IR stable state goes via the Capture_IR state, loading the shift register with a partially fixed value (not the current instruction)
    • Entry to the Shift_DR stable state goes via the Capture_DR state, loading the value of the Data Register specified by the TAP's current IR.
  • Shifting that value bit-by-bit, in either the Shift_IR or Shift_DR stable state;
    TCK transitions shift the shift register one bit, from TDI towards TDO, exactly like a SPI mode 1 data transfer
    through a daisy chain of devices (with TMS=0 acting like the chip select signal, TDI as MOSI, etc.).
  • Updating IR or DR from the temporary value shifted in, on transition through the Update_IR or Update_DR state.
    Note that it is not possible to read (capture) a register without writing (updating) it, and vice versa.
    A common idiom adds flag bits to say whether the update should have side effects,
    or whether the hardware is ready to execute such side effects.

• Running ...
  One stable state is called Run_Test/Idle. The distinction is TAP-specific.
  Clocking TCK in the Idle state has no particular side effects, but clocking it in the Run_Test state may change system state.
  For example, some ARM9 cores support a debugging mode where TCK cycles in the Run_Test state drive the instruction pipeline.

So at a basic level, using JTAG involves reading and writing instructions and their associated data registers;
and sometimes involves running a number of test cycles.

Behind those registers is hardware that is not specified by JTAG,
and which has its own states that is affected by JTAG activities.

Most JTAG hosts use the shortest path between two states, perhaps constrained by quirks of the adapter.
(For example, one adapter^[which?] only handles paths whose lengths are multiples of seven bits.)

Some layers built on top of JTAG monitor the state transitions, and use uncommon paths to trigger higher level operations.

Some ARM cores use such sequences to enter and exit a two-wire (non-JTAG) SWD mode.

A Zero Bit Scan (ZBS) sequence is used in IEEE 1149.7^[7] to access advanced functionality
such as switching TAPs into and out of scan chains, power management, and a different two-wire mode.

JTAG IEEE Std 1149.1 (boundary scan) instructions

Instruction register sizes tend to be small, perhaps four or seven bits wide.

Except for BYPASS and EXTEST, all instruction opcodes are defined by the TAP implementor,

as are their associated data registers; undefined instruction codes should not be used. Two key instructions are:

• The BYPASS instruction, opcode all ones regardless of the TAP's instruction register size,
  must be supported by all TAPs. It is associated with a single bit data register (also called BYPASS) which always reads as zero.
• The optional IDCODE instruction, with an implementor-defined opcode.
  IDCODE is associated with a 32-bit register (IDCODE).
  Its data uses a standardized format that includes a manufacturer code (derived from the JEDEC Standard Manufacturer's Identification Code standard, JEP-106),
  a part number assigned by the manufacturer, and a part version code.
  IDCODE is widely, but not universally, supported.

On exit from the RESET state, the instruction register is preloaded with either BYPASS or IDCODE.
This allows JTAG hosts to identify the size and, at least partially, contents of the scan chain to which they are connected.

(They can enter the RESET state then scan the Data Register until they read back the data they wrote.
A BYPASS register has only a zero bit; while an IDCODE register is 32-bits and starts with a one.
So the bits not written by the host can easily be mapped to TAPs.)

Such identification is often used to sanity check manual configuration, since IDCODE is often unspecific.

It could for example identify an ARM Cortex-M3 based microcontroller, without specifying the microcontroller vendor or model;
or a particular FPGA, but not how it has been programmed.

A common idiom involves shifting BYPASS into the instruction registers of all TAPs except one,
which receives some other instruction. That way all TAPs except one expose a single bit data register,
and values can be selectively shifted into or out of that one TAP's data register without affecting any other TAP.

The IEEE 1149.1 (JTAG) standard describes a number of instructions to support boundary scan applications.
Some of these instructions are "mandatory", but TAPs used for debug instead of boundary scan testing
sometimes provide minimal or no support for these instructions.
Those "mandatory" instructions operate on the Boundary Scan Register (BSR) defined in theBSDL file, and include:

• EXTEST for external testing, such as using pins to probe board-level behaviors
• PRELOAD loading pin output values before EXTEST (sometimes combined with SAMPLE)
• SAMPLE reading pin values into the boundary scan register

IEEE-defined "Optional" instructions include:

• CLAMP a variant of BYPASS which drives the output pins using the PRELOADed values
• HIGHZ deactivates the outputs of all pins
• INTEST for internal testing, such as using pins to probe on-chip behaviors
• RUNBIST places the chip in a self-test mode
• USERCODE returns a user-defined code, for example to identify which FPGA image is active

Devices may define more instructions, and those definitions should be part of a BSDL file provided by the manufacturer.
They are often just be marked as PRIVATE.

Boundary scan register

Devices communicate to the world via a set of input and output pins.

By themselves, these pins provide limited visibility into the workings of the device.

However, devices that support boundary scan contain a shift-register cell for each signal pin of the device.

These registers are connected in a dedicated path around the device's boundary (hence the name).

The path creates a virtual access capability that circumvents the normal inputs and outputs,

providing direct control of the device and detailed visibility for signals.^[9]

The contents of the boundary scan register, including signal I/O capabilities,

are usually described by the manufacturer using a part-specific BSDL file.

These are used with design 'netlists' from CAD/EDA systems to develop tests used in board manufacturing.

Commercial test systems often cost several thousand dollars for a complete system,

and include diagnostic options to pinpoint faults such as open circuits and shorts.

They may also offer schematic or layout viewers to depict the fault in a graphical manner.

To enable boundary scanning, IC vendors add logic to each of their devices,

including scan cells for each of the signal pins.

These cells are then connected together to form the boundary scan shift register (BSR),

which is connected to a TAP controller.

These designs are parts of most Verilog or VHDL libraries.

Overhead for this additional logic is minimal, and generally is well worth the price to enable efficient testing at the board level.