GDPR, 2018: Please see the revised Pivacy Policy for this wiki: General Data Protection Regulation
EU Cookie Directive: Please see the following note regarding opting in to the use of cookies for this wiki: EU Cookie Directive

Please Note: You must be logged in to edit this wiki and your account must be assigned "editor" rights (set by administrator).

System Architectures

Jump to: navigation, search

JTAG Chain Fundamentals

Figure 1 - The logic of a typical scan cell and its simplified form
Figure 2 - A chain of devices on a board

A JTAG device typically has a parallel IO boundary composed of a number of scan cells as illustrated in Figure 1. These cells are chained together and form a Data Register (DR) within the device. Output data can be clocked to these cells serially and then all pin states are updated synchronously. Similary, all input data can be be captured synchronously and then clocked out of the device serially.

Devices can be linked together, TDO to TDI (Figure 2), to form one or more chains, or scan paths, on a circuit board. In the early days of JTAG, it was common for a board to only feature a single chain, and this is still sometimes the case. Partitioning of the chains can come about for a number of reasons: Differing logic levels for sections of the design, phased power-up and power-down, or perhaps a need to isolate a particular device to aid programming or debug. In the simplest form, each of these chains may be brought separately to the board edge to present multiple TAPs at the "TAP Interface".

TAP Interface vs External Path
At this point we make an important point of nomenclature: The "TAP Interface" represents the point on the board boundary where control of the JTAG chain enters the board, while a point where control passes out of the board is termed an "External Path", so the External Path on a parent connects to the TAP Interface of a child.

Additionally, there may be a requirement to extend a chain off-board, to support a daughterboard or mezzanine. The problem we then encounter, even in a fault free condition, is that if no mezzanine is fitted then the chain is "broken" and if that chain includes components on the parent board, then the entire chain is rendered useless. It is possible to route the mezzanine's chain separately through the parent board, but often pins will be at a premium on the main connector, leading to a desire to resolve all the chains to a single TAP. This in turn raises the question of how we can select and manage multiple paths from a single TAP Interface.

Path Selection Principles

Figure 3 - Basic Primitives showing the logical construction and simplified forms
Figure 4 - The logic of a block that can either link in or bypass chain segment

Just as we started out building our scan chain from the basic scan cell, before getting too deep into path selection techniques we can describe some building block logic (Figure 3) that we can use to construct our path selector:

  • ISW - Input Switch, demultiplexes IN to OUTA or OUTB depending upon SELECT
  • OSW - Output Switch, multiplexes INA or INB to OUT depending uopn SELECT
  • DIST - Distributor, fans out IN to OUTA and OUTB with equal path delays
  • BUF - Buffer, trasparently buffers IN to OUT
  • PBUF - Pull-up Buffer, transparently buffers In to OUT with a weak pull on IN to keep it High if the driving input is open circuit or High-Z
  • GBUF - Gated Buffer, buffers IN to OUT if ENA is active, otherwise OUT is High-Z
  • SYNC - Synchronizer, transfer TDI to TDO on CLOCK

Having established these logic primitives, we can now assemble some of these to form an element that can either inculde or bypass a section of a scan chain. This will resolve the problem presented earlier by the missing mezzanine: The TAP Bypass Element shown in Figure 4 can be placed across the External Path to the mezzanine; when there is no requirement to include the mezzanine chain in the JTAG operation the TAP Bypass Element can be set to "short circuit" the External Path, thereby ensuring a complete chain.

Linkers vs Switches
It is quite common to consider that a switch (i.e. something that allows a single chain to be selected) is a more natural way to manage scan chains than a linker is, and that a linker's ability to "daisy chain" segments is unnecessary. However, while we do not present the evidence here, it can be shown that the logic to implement a switch is more complex than that required for a linker.

TAP Bypass Elements can be combined, with a little additional logic, to implement a Scan Chain Linker (Figure 5), which allows selective inclusion or exclusion of one or more scan chain segments. Since each TAP Bypass Element is individually controlled and are serially connected, it is possible to include any of the following permutations of secondary path:

a) Both SP1 and SP2 are excluded and TDI is routed directly to TDO on the Linker

b) Only SP1 is included between TDI and TDO; SP2 is bypassed

c) Only SP2 is included between TDI and TDO; SP1 is bypassed

d) Both SP1 and then SP2 are included between TDI and TDO

Figure 5 - Two-port Scan Chain Linker