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. To login, you must have an account on the SJTAG Forums and have been granted membership of either the Core_WG or the Extended_WG usergroups on the forums. You may then login to the wiki using the same credentials* you use for the forums.

* In some rare cases, it may be necessary to assign a wiki username that is different to your forum username.

Volume 1

From SJTAG
Jump to: navigation, search

Volume 1 - Overview Document

Contents

Context

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:

  • Volume 1 – Overview
    • Scope of SJTAG
    • Purpose of SJTAG
    • Primary Constraints
    • Relationship to Other Standards
  • Volume 2 – Use Cases
    • Structural Test
    • Configuration/Tuning/Instrumentation
    • Software Debug
    • Built-In Self Test
    • Fault Injection
    • Programming/Updates
    • Root Cause Analysis/Failure Mode Analysis
    • Power-on Self Test
    • Environmental Stress Test
    • Device Versioning
  • Volume 3 – Hardware Architectures
    • Hardware Topologies
    • Device Under Test Connectivity Schemes
    • XBST - External BST
    • Built-in Self-Test
    • In-System Programming/Configuration (ISP/ISC)
    • EBST - Embedded BST
    • Tooling Requirements
    • Conformance Levels
  • Volume 4 – Languages and Data Formats
    • Language Mapping to Circuit Model
    • Role of Languages
    • Dynamic and Static Information
    • Implementation Issues
  • Volume 5 – Business Case
    • Topic 1
  • Abbreviations and Glossary

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. A typical example of the various kinds of SJTAG modules that need to be supported are shown in Figure 1.

Figure 1: The SJTAG Modules

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 2: The SJTAG Universe.

Figure 2: 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.

Objective

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

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.

Direction

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

SJTAG Development

Use Case Analysis

The initial Tallinn meeting primarily focussed on the already established BSCAN domains of structural test and device programming as applied to systems. However, it soon became apparent that the problem domain was potentially much larger, as noted in the General Description.

In response to this observation, Gunnar Carlsson of Ericsson and Vice-Chair of the SJTAG Initiative initiated a study of potential Use Cases for SJTAG, drafting a White Paper on the subject. This work has subsequently been extended and analysed in some detail by the SJTAG Working Group, in order to establish the validity of each Use Case and the existence (or absence) of viable alternatives to JTAG for these. The objective of this analysis was to establish a Value Proposition demonstrating the technical and financial arguments for the adoption of a JTAG based solution in each case.

These Use Cases and the summarized arguments are set out in Volume 2 - Use Cases.

Hardware Architecture

The selection of an appropriate scan chain topolgy for SJTAG is not a simple matter and can be influenced by specific factors relating to the detailed design of the system in question. However some topologies are clearly better choices than others in given circumstances, and from a tooling perspective it is obviously essential to limit the number of architectures that need to be considered and supported. The merits and demerits of a number of topologies are discussed in Volume 3 - Hardware Architectures. Also presented in this volume, are the arguments for using either embedded control or external control of the system BSCAN operations (EBST or XBST).

SJTAG Language

Language is the "glue" that binds all the elements of SJTAG together, providing the open descriptions that enable portability and re-use. While existing industry standards such as SVF and STAPL can offer a degree of portability, these often carry a penalty, such as the loss of diagnostics, and they lack the features necessary to describe the actions required to seamlessly integrate the contained operations into a system environment. The requirements and proposals for an SJTAG language are presented in Volume 4 - Languages.

Engineering and Economic benefits

This text to be developed... The engineering value of applying SJTAG may or may not be obvious, but in any case it is evident that the engineering arguments must also be backed by economic arguments. Refer to Volume 5 - Business Case.

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

STAPL provides an interchange format for data and test algorithms between test and programming generation tools and the system level application tools. The provision of flow control within the language allows the algorithm to dynamically alter the behavior of the application at run-time based on direct feedback from the circuit under test. This has a benefit to improve the performance and accuracy of programming jobs. SJTAG needs to support STAPL to leverage backward compatibility to legacy applications. STAPL, however, has proven to lack some necessary features required to support new system level features, such as concurrency and hierarchical structures. For more information on the languages supported by SJTAG, please review Volume 4 - Languages and Data Formats.

ASSET-SVF-DOC, Revision E, 1999, “Serial Vector Format Specification”

The Serial Vector Format, commonly referred to as SVF, was jointly developed by Texas Instruments and Teradyne in 1991, although the specification is now maintained by ASSET InterTech. SVF is an ASCII format intended to provide a vendor-independent and transportable means of expressing the stimulus, expected response, and mask data for IEEE 1149.1-based operations. SVF is a de facto standard and not a formalized industry standard.

SVF is widely supported by tool vendors, although some ambiguities, particularly when older versions of the specification are used, can lead to unexpected behaviour.

It is likely that SJTAG will need to make provision for the use of SVF, although it may be necessary to limit conformance to only Revision E or later.

SVF represents an ordered set of vectors which may be applied to the unit under test in its entirety. Flow control is not directly supported by this language. For most test applications, however, SVF provides a deterministic flow of a test application, which yields an efficient support for fault dictionary or diagnostic lookup table supplemental diagnostics. SVF has already proven to be an efficient interchange format between tools and ad-hoc system test software implementations. SVF plays an important role for SJTAG by providing uniformity to test vector representation support. More language information is available in Volume 4 - Languages and Data Formats.

Hierarchical Scan Description Language (HSDL)

The Hierarchical Scan Description Language was originally developed by Texas Instruments to complement the Boundary Scan Description Language (BSDL) to describe additional attributes of IEEE 1149.1 devices and how these devices are connected at the board and system level. Primarily, HSDL describes modules as well as devices, where a module is any level of architecture above the device level, including boards, multi-chip modules, daughter boards, subsystems, and systems. This de facto specification is now maintained by ASSET InterTech. Over the years, there have been a number of issues raised about HSDL and what this specification does well and what it is lacking that the SJTAG working group needs to consider regarding the description of the components/modules comprising a system.

Boundary Scan Description Language (BSDL)

The Boundary Scan Description Language (BSDL) was originally defined as part of the IEEE Std 1149.1-1994 release and serves to describe the access to boundary scan registers within a devices as well as describe the boundary scan features applied to each port on the device. Further refinements have been added to the language to include the ability to add extensions to the definitions in the language to support sibling standard descriptions, such as 1149.4, 1149.6, and 1532. These languages target the description of the device level of the system hierarchy model. It is not the intent of the SJTAG standard to replace this language as the description of the boundary scan features of a device. It is also not the intent of the SJTAG standard to redefine this language to represent something other than its original inteded purpose in describing the device level module.

Standards in Development

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

Current emulation interfaces are difficult to support at the system level due to the need to manage additional signals, which are outside the scope of 1149.1. IEEE Std 1149.7 attempts to normalize the access interface to emulation features so a standard 1149.1 interface may be used as the access mechanism to these features. Building on the 1149.1 support, SJTAG will be able to access such features in devices from the system access point; both remotely and locally.

IEEE P1581 “Static Component Interconnection Test Protocol and Architecture”

P1581 provides an alternate deterministic test logic path for components that are difficult to test with traditional 1149.1 or do not support 1149.1 in its design. Interconnects to/from P1581 enabled devices may be tested using 1149.1 based cluster tests. As an 1149.1 enabled technology, P1581 support will be available from an SJTAG compliant interface.

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

The IEEE Std P1687 standard, commonly refered to as Internal JTAG or Instrument JTAG, manages the access to instrumentation features within devices. These instruments represent diagnostics, test activities, as well as functional tools required to configure, test, monitor, and control the activity of the system. As such, SJTAG must be able to provide access to these instrument features both from an external interface as well as from the system level software. Thus, there must be provisions within SJTAG to allow access to the functions of instruments to perform the necessary operations required to correctly influence the system's configuration.

References

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