Refreshing the IEEE 1687 IJTAG family for today’s designs

In 1985, Madonna ruled the airwaves and everyone was disappointed by New Coke. But it wasn’t all bad, that’s also when the Joint Test Action Group (JTAG) formed with over 200 members across the world from the semiconductor ecosystem. Their goal was to create a standardized solution to the problems of board test. By 1990, the IEEE 1149.1 standard was finalized and for 30 years was a foundation of the design-for-test (DFT) community. This standardized approach to testing ICs and circuit boards helped reduce cost and increase quality.

As semiconductor designs began to incorporate more embedded IP, it was clear that the JTAG solutions would not scale well. Two things happened. The JTAG committee convened to refresh IEEE 1149.1 and a separate committee formed to define a new standard specifically designed to access and control embedded instruments. The 1149.1 refresh was published in 2013, and a year later, the new IEEE 1687 internal JTAG (IJTAG) followed. The two standards are not fully aligned, with small variations in the common pattern description language.

IJTAG revolutionized the embedded test world by standardizing communication interfaces between diverse IP (Figure 1). It gained industry acceptance very quickly and is now widely used with mature support from EDA companies. IJTAG draws from the pre-2013 JTAG and also IEEE 1500 so that any design that is compliant, would be describable with IJTAG.

Figure 1. Standardized communication interfaces like IJTAG enable faster integration, test and debug (Siemens EDA)

IJTAG had limitations though. These are being addressed in two proposed standards. P1687.1 provides a way to describe device interfaces that are not the common IEEE 1149.1 test access port (TAP). P1687.2 extends IJTAG to describe analog IP and analog networks.

Building on P1687.1, we also have a proposed standard, IEEE P2654, that will bring IJTAG to the system level. To describe test access for 3D devices, we now have IEEE 1838, which also has support from EDA providers and is compliant with IJTAG.

Refreshing IJTAG

Of course, the original IJTAG standard is also ready for a refresh, and that work started in 2022. The updated version is expected to be backwards compatible and remain a descriptive standard. The updates will expand IJTAG to include solutions for some of the reported problems with making IJTAG work on modern, complex designs. Here are a few of the topics being addressed:

• Pipelining and clock stretching for faster shift operation and support of large networks
• Sophisticated reset protocols (the IJTAG one is simplistic)
• The concept of bitfields
• Mapping instrument control language (ICL) to register transfer level (RTL)
• Revisiting call-back and call-back registers
• Revisiting broadcasting
• Overshifting scan registers
• Non-modeled inputs to the IJTAG network (for example, from a security IP)
• Bidirectional pins and ports

The update will also add new principles and methodologies, including topics for tool interaction and introspections. This includes more user control over the result of the IJTAG retargeting engine to influence which IJTAG network path to avoid or select. An example is defining a preferred input port of a data or scan mux. For the introspection part, it may allow dynamic PDL generation tailored, for example, to match the actual ICL instance parameters. Another set of topics expands this even further, asking for an API, morphing PDL into a programming language, or adding flow control to PDL (working title “PDL level 0.5”). Interestingly, IEEE P1687.2 already added parts of the latter.

This last point brings up the necessity for these working groups to cooperate closely. In the case of bidirectionals, all three 1687 standards will need to add wording that is mutually compatible. The 1687 refresh and P1687.1 will describe only the digital part of bidirectional pins and ports but needs to be worded in such a way that P1687.2 can expand from there, adding the analog aspect in a consistent manner.

It is challenging but essential to maintain a coherent approach across multiple standards that each have a unique feature set and language syntax and are being developed in parallel but on different time schedules. To see how it is being done, let’s take a quick tour through three of the related standards: P1687.1, P1687.2, and P2654.

P1687.1: interfaces and controllers

The original IJTAG anticipated connecting to an 1149.1 TAP and that there could be other device interfaces. But it left just a generic placeholder for those, expecting another standard to address the multiplicity of interfaces. That is exactly the scope of P1687.1, which is defining the mechanism for converting a stream of retargeted actions at the IJTAG network edge into a corresponding stream of actions which obey the protocol of the selected device interface (for example, SPI, MDIO, etc.).

There are four ways P1687.1 is being kept compatible with the rest of the 1687 family.

First, the grammar for the primitive operations at the IJTAG network edge is defined to match the actions allowed in 1687.

Second, the language in which the body of each transformation procedure is written is left to the provider, but the API to call the procedure is standardized so it can be called from many other languages, including Tcl (which is syntactically compatible with IEEE 1687 PDL).

Third, the invocation of these procedures is placed in a request-response messaging framework that is a subset of P2654.

Fourth, the ‘AccessLink Generic’ feature of 1687 is leveraged to point to the mechanisms described in 1687.1.

P1687.2: analog test access

The original 1687 is limited to digital circuits, but the real world is full of analog and mixed-signal circuitry. Providing those analog extensions is the purpose of P1687.2, which grows the procedure description language (PDL) with new commands to control and observe analog values in much the same way that the existing commands are used for digital values. It extends ICL to enable the description of analog instruments (ADCs, DACs, PMUs, etc.) and analog test access mechanisms (for example, analog test buses).

Most of the compatibility issues between P1687.2 and the rest of the 1687 family are trivial because P1687.2 is largely an augmentation of the existing feature set rather than an alteration of it. However, there is overlap between some changes being considered for the revision of 1687 and features that are planned for P1687.2 (bidirectional ports being the primary example).

P2654: system test access and management

The original 1687 is aimed at instruments embedded within a semiconductor device. However, as the semiconductor industry forges new paths to continue its exponential growth through the integration of chiplets into multi-die packages, it is getting harder to draw a crisp boundary between a device and a system. Instruments that used to be accessible from a device interface are now buried deep inside the hierarchy of another device. This is just one reason we need a system-level view of test access, and that is the goal of P2654.

P2654 can be thought of as a way to send test control and data in the form of serialized messages from one interface to another. It is a superset of the approach taken in P1687.1. Specifically, an IJTAG network is a target endpoint of a P2654 node tree, and the device interface in P1687.1 is the ‘last hop’ for P2654.

To ensure compatibility, the P2654 framework will guide the implementation of P1687.1, since the latter is a subset of the former. The other aspects of compatibility are being addressed primarily through language-neutral approaches for the transformation library.

The IEEE 1149.1 refresh

The JTAG standard is also undergoing revision. The goal of IEEE Std 1149.1 is still to detect and diagnose manufacturing defects on Printed Circuit Board Assemblies (PCBA), but previous updates extended it to device initialization, boundary-scan register (BSR) segmentation, power domain control, and access to chip-embedded instrumentation. It is still widely used and other standards rely on the TAP interface defined in 1149.1.

The updates currently underway will introduce some improvements, but no major changes are planned. Rectifying the slight discrepancy between 1149.1-2013 and 1687-2014 is also a cooperation target for both working groups.

A growing family of test standards

Figure 2. IEEE 1687 and IEEE 1149.1 family and friends (Siemens EDA)

Figure 2 shows the family tree of IEEE 1687. The important upgrades in store for 1687/IJTAG and the three proposed standards will ensure not just continued adoption of the IJTAG family but ensure the new requirements for state-of-the-art designs. Working on the IJTAG refresh in coordination with related standards also sets the stage for a more universal and coordinated JTAG world going forward.