Authors: Carl Barnhart, Bill Bruce, Alan Bair, and Jim Johnson

Oct 7, 2014 -- Literally, IEEE Std. 1149.1 very well might have been your father’s JTAG, since it has been around since 1990. For now over 20 years, this standard has been in use throughout the world (BSDL wasn’t added until 1993). 1149.1 was revised in 2001 with only incremental improvements and no real major rewrites. That is until now. A new 1149.1-2013 and the upcoming release of IEEE Std. P1687, huge changes and unmistakable momentum are on the horizon promising to once again revolutionize the industry.

Overview

This is the first article in a series aimed at discovering a new approach to an old problem: “How to leverage reuse and automation on an industry scale to both save and make more money?” The series will focus on the newly revised IEEE Std. 1149.1 standard, as well as the proposed IEEE Std. P1687 standard. 

The new IEEE Std. 1149.1-2013 standard has more than doubled in size from the previous release and has many new features, including automated component initialization, complex and variable length user test data register structures with excludable (included or excluded) and selectable (one of n segments selected) register segments, new structural documentation, and a procedural language for describing the use of the test structures.  The documentation capabilities were also expanded to allow an Intellectual Property (IP) supplier to hierarchically document both the test structures built into the IP and the procedures for using those test structures. 

Under development now for several years, the IEEE working group’s P1687 is dedicated to defining access structures (control and observe) and documentation for internal chip “instruments.” It defines the structure and documentation of a potentially complex network of instruments whose access via the network can be reconfigured. Currently, the P1687 uses the 1149.1 TAP for access to the network, appearing to the 1149.1 TAP as a variable length user test data register. Both of these standards allow and support a hierarchical description of networks, allowing the chip integrator to utilize a hierarchical network to connect IP blocks supplied by IP providers. 

Later in the series, we’ll discuss how these two new standards will be used, who needs them, and how the industry in general may be changed in the coming years by their mutual existence.

A Little History behind IEEE 1149.1-2013

When the revision that became known as IEEE Std 1149.1-2013 was started, the only “big” issue was a long-standing need to provide some form of automated initialization for the newer complex I/O. Through investigation, it became clear that in order to accomplish this, two things would first need to be standardized:  a way to document the multiple fields of a Test Data Register (TDR); and a way to document the procedures needed to initialize a component on a board.

The ability to document the multiple fields of a TDR has been around forever, but not in a machine-readable form. Anyone with experience programming TDRs has used specification documents to find the parameters of registers, such as how the multiple fields are laid out, what each field does, and what legal values can be used for each field. It is now possible to document all those parameters  in the machine-readable BSDL description of a component. By assigning names for the fields, names (mnemonics) for the legal values, and associations of fields to an I/O, one can logically organize these field descriptions by grouping them into TDR segments. It is also possible to assemble previously described TDR segments, including segments defined by an IP provider, into larger segments or entire TDRs. 

As for documenting the procedures needed to initialize a component on a board, the 1149.1-2013 working group has adopted an initial IEEE Procedural Description Language (PDL) being developed as a starting point. This version of PDL was then modified to meet the needs of the 1149.1-2013 group. Due to the different requirements of 1149.1-2013 and P1687, each group developed their own flavor of PDL. Unfortunately, due to the many differences between the resulting PDLs in syntax and usage, they will need to be treated as two different languages with only a subset of syntax able to be shared between both PDL languages.

PDL is designed to document the procedures for stimulating and observing test data register fields for 1149.1-2013. In the case of P1687, the PDL documents the procedures for stimulating and observing data to an instrument. This is a subtle, but important difference between how the two standards for define the PDL interface. Both PDL languages are very flexible and can support the names of the register fields – including the names of the values (mnemonics) without regard to which bits of which register were being written or read. With restrictions, the PDL commands can be combined with TcL to provide even greater control and flexibility in stimulating and observing the registers and instruments.

This is when questions started popping up. Questions like:

• What about chips with multiple power domains, domains which might be de-powered during test?  To support that, the standard needed segments of TDRs (including the boundary-scan register) that could be excluded or not.  

• What about IEEE Std 1500 wrapper structures embedded in a TDR?  To support that, the standard needed the ability to select one of many segments for inclusion in a TDR.  

• What about all of the IP being used, much of it containing I/O and/or TDR segments?  To support IP, the IP supplier should be able to provide the documentation, so the BSDL Package and PDL were modified to allow hierarchical description of both the embedded TDR segments and necessary procedures.

All of these capabilities were generalized to make them useful in as many situations as was practical. By this time, the working group had developed documentation standards for complex TDRs and procedures, thus resulting in a very robust initialization capability!

In the meantime, the P1687 working group, often known as iJTAG (Internal JTAG), had been developing their own standard, which focuses on documenting the structural and procedural descriptions used for accessing a possibly complex network of internal “instruments” on the component.  

The network to access the register fields is described with BSDL extensions for 1149.1-2013 and a new language called Instrument Control Language (ICL) for P1687. While both of these can describe very complex networks, ICL modeling language can describe some networks that are beyond the capability of 1149.1-2013. These differences will be discussed in a future article.

As a result, there is considerable overlap between the capabilities of the two standards when they are used to document user-defined TDRs and procedures.  There is, in a sense, a continuity of capability from the simpler configuration to a more complex configuration. Test features usable for component or board test, in particular, may be simply added to the otherwise required 1149.1 BSDL. A more complex configuration with an extensive set of instruments, many intended for system performance monitoring rather than manufacturing tests, may be supported by either standard. Finally, some network configurations are not supported in 1149.1-2013 but are supported by P1687. These trade-offs will also be worked through in detail later in the series.

P1687 has a lot of BUZZ

For several years, IEEE Std. P1687 has created a lot of BUZZ around our industry. A great deal of work, over many years of development, has companies anticipating the release of this as a standard. However, time has marched on and many companies have already designed and implemented 1687-like structures into silicon; even before the standard has been published. EDA companies, like SiliconAid, have invested years of development in tools to support this upcoming standard. Some of these tools have even been released to the market and are available for purchase ahead of the standard.

P1687 started with a simple idea: define the interface and access to a piece of internal IP. Then things started to evolve. The development of enhancements, add-ons, feature-creep, and more; plus throw in some unique personalities and debates, and here we are. We’re still waiting (and hoping) to get P1687 released sooner than later. Nevertheless, there are obviously a lot of technical issues that have to be considered in the development of this standard.

The first version of P1687 supports the IEEE 1149.1 Test Access Port (TAP) standard test interface. Future possible versions may also support other popular interfaces.

Affects of these new upcoming Standards