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).

Volume 1

Revision as of 22:25, 6 July 2008 by Ian McIntosh (talk | contribs) (IEEE Std 1149.6-2003, “IEEE Standard for Boundary-Scan Testing of Advanced Digital Networks”)
Jump to: navigation, search

Volume 1 - Overview Document


About this Document

This document, Volume 1 of 5 volumes, provides an introductory overview of the objectives and defining principles of System-Level JTAG (SJTAG). The document is intended for those readers who are either either new to SJTAG or who only require a basic understanding of the application of SJTAG. It is assumed, however, that the reader has basic knowledge of the principles of JTAG Boundary Scan Test as described by IEEE 1149.1-2001, “IEEE Standard Test Access Port and Boundary Scan Architecture”.

Documentation Map

Readers seeking further information on specific topics are directed to the following volumes:

Scope of SJTAG

General Description

A “system”, for the purposes of SJTAG, is any hierarchical aggregation of inter-related and interconnected electronic circuits, the operation of which is sufficiently self-contained that it may be perceived as a single unit. From the end-user perspective, this means that a circuit board carrying a mezzanine daughter board may be considered a system, just as equally as the network of discrete electronic control modules within an automobile may be.

Since SJTAG is a development of JTAG (IEEE Std 1149.1), there is a presumption that the target system will have a significant digital content, and that the concept of applying JTAG at the individual circuit board level will already have been embraced.

By taking account of the special factors that arise when creating an assembly of circuit boards, and applying the corresponding SJTAG design principles to address those factors, then the underlying board level JTAG feature can be leveraged at the system level, creating a test access mechanism that extends the usefulness of JTAG throughout the entire product life-cycle: This is illustrated in the Venn Diagram of Figure 1: The SJTAG Universe.

File:SJTAG Universe.png
Figure 1: The SJTAG Universe

It is likely that users will identify additional applications areas for SJTAG not included in the diagram: The important point to take from Figure 1 is that the application potential of SJTAG extends significantly beyond the traditional board-level scope of structural test and device programming.


The SJTAG standard will develop a methodology for access to test, debug, instrument, and emulation features (but not the features themselves) of devices via the IEEE 1149.1 Test Access Port (TAP) for the board and system (multiple board) domains. The elements for this methodology include a description language describing the structure of the IEEE 1149.1 connections in the system; a description of data representation formats for test vectors, diagnostic analysis, and data logging; and software application programming interfaces (APIs) defining command primitives facilitating communications between functional command, control, and data modules of a Test Manager application.

Purpose of SJTAG

The JTAG Background

When the Joint Test Action Group was formed in the late 1980s, it was in response to concerns over the reduction in board test access offered by new device packaging options and board construction techniques: JTAG was born out of the necessity to recover the testability that was being lost due to the use of these higher density board designs.

However, system level test access has always been relatively poor, due to the “closed” nature of the system itself. Access is largely limited to only those signals that form the mission interfaces of the system or that have been explicitly brought out to test connectors by the designer. This limited test access has been accepted by manufacturers as “normal”: There was no apparent reduction in test access that paralleled the board test scenario to instigate an improvement initiative. As systems have grown more complex, diagnosis of faults, or indeed confirmation of functionality, has become increasingly reliant upon the built-in test features of the system and it's constituent boards.

SJTAG identifies that not only can system test access, and therefore diagnostic accuracy, be greatly improved, but once that access is provided, other potential applications become accessible, increasing the value that can be realized from the employment of JTAG within the system design.

The SJTAG Background

The System JTAG (SJTAG) effort has grown out of the grass roots effort of 14 people getting together to share ideas about the issues facing them to support boundary-scan at the system level. They met together, informally, presenting their ideas at the IEEE European Board Test Workshop held in Tallinn, Estonia, May 2005. They discussed a set of problems associated with the extended test and configuration use of the 1149.1 boundary-scan infrastructure within complex multi-board systems.

As a result of the Estonia meeting, an SJTAG initiative team was created to formally investigate whether standardization of these issues was possible. This initiative team worked together to provide an SJTAG white paper[1] detailing the overall system architectures and defining a common terminology for various functional aspects of the system testing methodology.

During 2006, the SJTAG initiative team voted to use the telecommunications system architecture as a baseline to analyze the problem space associated with system-level boundary-scan testing. Towards the end of 2006, Gunnar Carlsson, Vice Chairman of the SJTAG Initiative, proposed that the group needs to begin to define a library of use cases describing how people and tools use the boundary-scan infrastructure to accomplish specific tasks and functions within the system. His proposal grew out of his need to find a solution for efficiently applying test actions to 55 MBIST blocks within an ASIC simultaneously or at least as many as could feasibly run concurrently given the power limitations of the board design these ASICs resided on. This BIST testing was needed to be run in the system by the system diagnostic software. Gunnar submitted a draft of a use case white paper which detailed his problem space.

In the beginning of 2007, the PICMG Advanced Telecommunications Computing Architecture (ATCA) working group received a change request to provide support for boundary-scan testing at the system level. ATCAs sibling standard, MicroTCA, already supported boundary-scan from a previous adoption.[2] Realizing the opportunity for impacting the ATCA standard, the SJTAG initiative team began to act on the original proposal offered by Gunnar. In October 2007 a group of SJTAG members began to meet weekly to discuss the possible use cases that could be important for an ATCA-like system by leveraging cases from their own backgrounds. There were a few industries represented on this team from telecommunications, avionics, photo processing systems, boundary-scan tool vendors, and chip designers. The success of their work is presented in Volume 2 – Use Cases section of this document.


There is currently no defined, independent standard for this test technology. Each vendor is free in the way of implementing test hardware and software functionality on their boards. Without an independent standard, testability at the system level is reduced or impossible making the test technology in the system less useful for users integrating designs from multiple sources – limiting the ability to use the test technology in other facets of a product’s life cycle beyond manufacturing. In practice, the software used to perform test actions is written in an ad-hoc manner across the industry to access the IEEE 1149.1 features of the devices installed on the various boards of a system. Further, communications between remote and embedded hosts managing the tests applied to the system under test is non-existent or implemented using ad-hoc communications protocols. The purpose of the SJTAG initiative is to provide an extension of the IEEE 1149.1 standard specifically aimed at the configuration, control, management, and representation of the communications required at the hierarchical system and board level to perform operations on the IEEE 1149.1 Test Access Port (TAP) Controller of one or more devices, including multiple core devices, in a uniform way across all system modules.

Primary Constraints

Open Standard

Device Independence

There is no requirement that a designer needs to use parts from any specific vendor, however it must be recognised that the use of devices which are not compliant with IEEE std 1149.1-2001 may compromise the ability to achieve a successful SJTAG implementation.

While devices may be offerred by some vendors to ease the implementation of an SJTAG capable system, the underlyng protocols, methods and architectural features are all non-proprietary or rely on established international or industry standards.

The hardware aspects of SJTAG are more fully described in Volume 3 - Hardware Architectures.

Tool vendor independence

The principles behind SJTAG promote cross-vendor exchange of test description, execution and flow control, diagnostic data, etc. It is readily foreseeable that many users will, in fact, employ software tooling from a number of sources, for example using device vendor tools to develop programmable device contents and third party or custom tools to embody the programming actions within the system test facilities.

The interchange of data is based largely upon the use of established open standards and formats: Proprietary formats, protocols or coding schemes may be employed within a toolset or system implementation to improve performance, reduce memory requirements, etc., but will not be used for the exchange of data.

Further details may found in Volume 4 - Languages and Data Formats.

IEEE Std 1149.1 Based

SJTAG builds upon the foundation of 1149.1 JTAG protocols and architectures. Refer to the section on IEEE std 1149.1-2001 in "Relationship to Other Standards".

Relationship to Other Standards

IEEE Standards

IEEE Std 1149.1-2001, “IEEE Standard Test Access Port and Boundary Scan Architecture”

As a basic principle, SJTAG may be considered to be an application level extension to IEEE std 1149.1 and is dependant upon a TAP being implemented on each of the component circuit boards within the system. SJTAG does not impose any additional Boundary Scan requirements on functional/mission devices used within the design beyond existing support for 1149.1, although compliance with SJTAG conformance levels may mandate the employment of specific design features.

IEEE Std 1149.4-1999, “IEEE Standard for a Mixed-Signal Test Bus”

SJTAG supports the use of IEEE std 1149.4 compliant devices within the system design. Consequently, commercial tooling for SJTAG shall also, where appropriate, support the use of such devices.

IEEE Std 1149.6-2003, “IEEE Standard for Boundary-Scan Testing of Advanced Digital Networks”

The use of high-speed ac-coupled signals, for example SerDes and InfiniBand data links, is now increasingly common within systems, either as external, "mission" I/O or as backplane transport between boards. However, at this time only a few of the FPGAs, etc., that provide support for these interfaces also support IEEE Std 1149.6. Nevertheless, it is crucial that the JTAG infrastructure of a system should take account of the specific requirements for synchronisation of scan chains where there is a likelihood that 1149.6 compliant parts may be used.

For further information refer to Volume 3 – Hardware Architectures.

IEEE Std 1532-2002, “IEEE Standard for In-System Configuration of Programmable Devices”

SJTAG supports the use of IEEE std 1532 compliant programmable devices within the system design. Consequently, commercial tooling for SJTAG shall also, where appropriate, support the use of such devices.

This does not, however, preclude the use of non-1532 compliant devices within an SJTAG system.

Industry Standards

EIA/JEDEC STANDARD JESD71 “Standard Test and Programming Language (STAPL)”


“Serial Vector Format Specification”


Standards in Development

IEEE P1149.7 “Standard for Reduced-pin and Enhanced-functionality Test Access Port and Boundary Scan Architecture”


IEEE P1581 “Static Component Interconnection Test Protocol and Architecture”


IEEE P1687 (IJTAG) “Standard for Access and Control of Instrumentation Embedded within a Semiconductor Device”

Text Here.


  1. [1], SJTAG White Paper
  2. [2], Bradford Van Treuren and Adam Ley, BTW 2006