What’s The Difference Between JTAG (IEEE 1149.1) And IJTAG (IEEE P1687)?

The JTAG (Joint Test Action Group) standard, known formally as IEEE 1149.1 boundary-scan, has been widely used for testing printed-circuit boards (PCBs) and integrated circuits (ICs) since at least 1990. The JTAG control port, called the test-access port (TAP), not only controls the boundary-scan logic and tests, it also has been used in a variety of ad-hoc manners to access embedded instruments such as built-in self-test (BIST) engines, complex I/O characterization, and embedded timing instruments. To standardize the protocols used to test, access, and control the growing use of embedded instruments, the industry is in the process of creating a new Internal JTAG, or IJTAG (IEEE P1687), standard. This article will detail the differences between the IEEE 1149.1 JTAG standard and the updated IEEE P1687 IJTAG standard.

JTAG Basics

JTAG has long been a standard for testing features embedded in a device, but a given JTAG configuration for testing embedded instruments remains a proprietary in-house solution with limited reusability. Third-party plug-in options are available for JTAG devices to facilitate board-level testing, but they are not available for embedded instruments within the devices.

IJTAG puts an end to the growing number of isolated, in-house proprietary solutions by defining a standard for how information is described and exchanged.^1,2,3 This allows for plug-and-play usability and higher automation.^4,5

JTAG is compatible with IJTAG. It can be modeled within the IJTAG standard. In fact, the JTAG port is used as the IJTAG primary top-level device interface. Thus, IJTAG access operates through the JTAG port to control a variety of embedded test features and other instruments.

IJTAG Basics

IJTAG is a reaction to the growing integration of functionality in the same die. With this trend comes the need to quickly integrate not only in-house intellectual property (IP), but also third-party IP. For design integration, such IP comes with a large, de-facto standard library, including layout views, simulation libraries, and design-rule checks.

IP test information usually is not part of this library. The method of delivery of test information is often an ad-hoc agreement between the different parties. The test view of the IP, in-house or purchased, might be provided “textually” as part of the documentation, for example, explaining how to execute logic BIST-based tests.

Furthermore, thorough testing becomes increasingly challenging with the numbers and types of instruments. Limited top-level access to each instrument due to pin limitations is an additional challenge. As device complexity increases in this way, the value of IJTAG becomes more apparent. Instead of replacing JTAG, it adds capabilities to allow more automation and reuse for embedded instruments (see the table). Additional capabilities added by IJTAG include:

Support for dynamic data-register configurations. This is especially useful with large numbers of internal instruments in an effort to reduce test-data volume and test time
The ability for IP providers to supply control and interface information with their instruments in a standardized exchange format
The ability for the test integrator to rely on automation for mapping embedded instruments and generating test patterns as defined by the IP providers

Table 1

About The JTAG TAP

The IEEE 1149.1 standard originally defined the JTAG TAP as part of a solution to control boundary scan during board-level testing. The JTAG TAP is a chip-level, five-pin, state-machine-controlled interface to access test registers and instructions (Fig. 1). It loads an instruction and then routes from the test-data-in (TDI) port through a register to the test-data-out (TDO) port. The particular register is selected based on the instruction that was loaded. This test port allows the user to implement custom instructions and registers.

Figure 1. Shown is a typical configuration of a JTAG-based test access to a user’s design, outlining the TAP controller, user-defined data registers, boundary scan cells and chains, and their connectivity. IJTAG makes use of all this commonly available test logic by incorporating JTAG access mechanisms into IJTAG.

The TAP has been used to access more and more embedded instruments and IP. Electronic design automation (EDA) tools support the creation and insertion of TAP controllers. Insertion of BIST often includes creating custom instructions and registers within the JTAG logic to control and observe the BIST logic. Many companies also developed proprietary solutions to access embedded instruments, including third-party IP, through the TAP. The portability and reuse of all these embedded instruments has grown increasingly difficult, and it’s proving to be a constant source of errors.

JTAG Standard Usage

JTAG was developed and standardized as part of IEEE 1149.1 to enable testing of board-level manufacturing defects through boundary scan. It defines a standard control and interface so a board-level test integrator, using minimal information without having to understand the functional operation of the device, can use each compliant device.

IEEE 1149.1 includes hardware design requirements and a boundary-scan descriptive language (BSDL) to describe the TAP instructions, device I/O boundary-scan configuration, and boundary-scan cells. The JTAG standard and BSDL enable device providers and integrators to use EDA tools for logic creation and test generation.

Users frequently rely on the convenient TAP interface for features beyond boundary-scan test. For example, one may add user-defined registers and instructions to control embedded instruments. EDA tools for JTAG creation and insertion support the addition of custom registers and instructions, but there is not a standard description of how to define and use them.

IJTAG Plug-And-Play Solution

To manage the complex requirements of testing a heterogeneous set of embedded instruments, the industry is developing IJTAG, which uses the JTAG TAP as the primary chip interface. It standardizes the instrument interface and how these instruments—test features, IP, or other embedded logic that can be individually controlled—must be connected to each other. It achieves definition of this standardization at a very high level, which leaves ample room to design an IJTAG-compliant solution that fits other design constraints.

To describe the instrument interface and the connection between the instruments, IEEE P1687 defines the Instrument Connectivity Language (ICL). ICL is an abstraction of the design description, focusing only on the information necessary to write to or to read from the instrument. It is not a remodeling of the RTL or gate-level description of the design. These read and write (or scan) operations can, for example, describe tests, manage a BIST controller, or read out a temperature sensor, among other operations.

The Procedural Description Language (PDL) of IEEE P1687 defines the syntax and semantics of these read, write, or scan operations. The PDL may be written with respect to the instrument’s I/Os. It is then up to an EDA tool to “retarget” this PDL. Retargeting translates the operations from the instrument through hierarchical logic described in ICL up to the top level of the design.

This standardized description of the instruments’ I/Os, their interconnection, and their operation facilitates reuse and plug-and-play of any IEEE P1687-compliant instrument, regardless of its type, purpose, or origin. A process automated by EDA tools takes over the error-prone and difficult part of “translating” the IPs’ operation and test stimuli from a proprietary description to the top level of the design. The end user must only utilize the IJTAG logic-interface description and the IJTAG pattern description of an embedded instrument to interface to it from a higher level of assembly.

IJTAG Standard Usage

Let’s look at an example of controlling an embedded instrument using IJTAG. Consider a schematic of a top-level ICL module (Fig. 2). It contains an IEEE 1149.1-compatible TAP controller, two instances of a Segment Insertion Bit (SIB) module (more on these below), and one instance each of two modules named TDR1 and TDR2, respectively. Each module includes two instruments operated by a regular test-data register (TDR). “Operating” means writing care bits into the TDR or reading values from it. A PDL retargeter (EDA tool) automatically applies control signals such as capture, shift, or update enable as needed.

Figure 2. Shown is an ICL schematic of a top-level module and a closer view of the SIB. This figure aids in illustrating the ability of IJTAG to automatically and dynamically change the scan access network configuration as needed to achieve low scan data volume and fast test execution times.

In IJTAG, the ICL interconnection network and all non-leaf-level instrument modules in this interconnection network are universally addressed as the “ICL access network.” An interesting addition to this ICL access network is the use of SIB modules, which dynamically change the ICL access network configuration. (We will explain this in the next paragraph.) SIBs are not part of IEEE P1687, but their usage is recommended. Usually, a PDL-retargeting EDA tool automatically sets the access network’s configuration while it is computing a solution for sending the user’s care bits to an instrument. The user also can manipulate it explicitly.

Assume a user wants to write a care bit into TDR2. There is no need to shift through TDR1. Instead, the shorter shift path is to configure the first SIB to bypass TDR1 altogether so the shift path is from the TDI port, through the first SIB, into TDR2 and the second SIB’s side input, back through the TAP to TDO. The PDL-retargeting tool’s job is to figure this out. In IJTAG, the user only needs to express the intention to write a care bit into TDR2. This is the key difference with other JTAG-based usages, where it is up the user to configure the access network explicitly.

Let us look at an illustration, in more general terms, of the principle of PDL retargeting (Fig. 3). Usually, the PDL for the instrument is written with respect to the instrument boundaries. This PDL must be translated up the ICL hierarchy of the design. During this process, the care bits defined in the initial PDL are changed as needed, and additional bits are computed, for example, to configure a path to the instrument though the ICL access network. It might even be necessary to generate multiple top-level scan operations to guarantee application of the care bits described in the instrument’s PDL in proper sequence.

Figure 3. Shown is a diagram of PDL retargeting, illustrating how an EDA tool retargets the instrument-level PDL through the ICL hierarchy to generate a top-level PDL, which can then be translated into the common pattern formats. This retargeting is done automatically by the EDA tool, instead of through an error prone and slow, manual process.

This PDL retargeting is fully automated. Once the PDL has been retargeted to the top level of the design, it can be transformed into any of the common pattern formats, such as STIL, SVF, test bench, or a top-level PDL. The PDL and SVF formats are protocol-aware. This means that, for example, embedded in the PDL file is not only the read and write data, but also semantics. In fact, the retargeted top-level PDL is nothing more than the PDL view of the embedded instruments at the boundary of the chip. A system-level tool can pick up this PDL and retarget it to an even higher level, for instance, to generate tests between different die.

Summary

IJTAG may use the JTAG TAP as the primary chip interface, but goes well beyond it. It standardizes the interface description of instruments, the description of their operations, and their connectivity through the design hierarchy. Thus, IJTAG allows plug-and-play of in-house as well as third-party IP. It is the enabler of reuse of both IP and operation, as well as facilitated test automation of embedded instruments. Opportunities exist to use IJTAG for applications such as 3D device test or system-level test integration of multiple IEEE P1687-compatible die.

The promises IJTAG makes are substantial. Some EDA suppliers are already designing their BIST, DFT, and APTG infrastructures around the IEEE P1687 standard. IP providers, users, and test integrators can see the possible benefits of IJTAG, and they are starting to invest in IJTAG support.

References

The IEEE P1687 Working Group’s Web site is located at http://grouper.ieee.org/groups/1687/
J. Rearick, et al., “IJTAG (Internal JTAG): A Step Toward a DFT Standard,” International Test Conference, 2005.
K. Posse, et al., “IEEE P1687: Toward Standardized Access of Embedded Instrumentation,” International Test Conference, 2006.
B. Vermeulen, et al., “Overview of Debug Standardization Activities,” IEEE Design & Test of Computers, May/June 2008.
F. Ghani Zadegan, et al., “Reusing and Retargeting On-Chip Instrument Access Procedures in IEEE P1687,” to be published in Design & Test of Computers, IEEE.