GDPR, 2018: Please see the revised Pivacy Policy for this wiki: General Data Protection Regulation
Please Note: You must be logged in to edit this wiki and your account must be assigned "editor" rights (set by administrator).
Volume 1 - Overview Document
- 1 Context
- 2 Scope of SJTAG
- 3 Purpose of SJTAG
- 4 Primary Constraints
- 5 Relationship to Other Standards
- 5.1 IEEE Standards
- 5.1.1 IEEE Std 1149.1-2001, “IEEE Standard Test Access Port and Boundary Scan Architecture”
- 5.1.2 IEEE Std 1149.4-1999, “IEEE Standard for a Mixed-Signal Test Bus”
- 5.1.3 IEEE Std 1149.6-2003, “IEEE Standard for Boundary-Scan Testing of Advanced Digital Networks”
- 5.1.4 IEEE Std 1532-2002, “IEEE Standard for In-System Configuration of Programmable Devices”
- 5.2 Industry Standards
- 5.3 Standards in Development
- 5.3.1 IEEE P1149.7 “Standard for Reduced-pin and Enhanced-functionality Test Access Port and Boundary Scan Architecture”
- 5.3.2 IEEE P1581 “Static Component Interconnection Test Protocol and Architecture”
- 5.3.3 IEEE P1687 (IJTAG) “Standard for Access and Control of Instrumentation Embedded within a Semiconductor Device”
- 5.1 IEEE Standards
- 6 References
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”.
Readers seeking further information on specific topics are directed to the following volumes:
- Volume 2 – Use Cases
- Structural Test
- Software Debug
- Built-In Self Test
- Fault Injection
- Root Cause Analysis/Failure Mode Analysis
- Power-on Self Test
- Environmental Stress Test
- Device Versioning
- Volume 3 – Hardware Architectures
- Topic 1
- Volume 4 – Languages and Data Formats
- Topic 1
- Volume 5 – Business Case
- Topic 1
Scope of SJTAG
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.
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 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. 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.
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.
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 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”
IEEE Std 1532-2002, “IEEE Standard for In-System Configuration of Programmable Devices”
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”