This Isn't Your Father's JTAG Anymore

By Carl Barnhart, Bill Bruce, Alan Bair, and Jim Johnson (SiliconAid Solutions Inc.)

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

Let’s table the debate on comparing these standards a little while longer. Let’s discuss how these two standards might affect things in the future. Reuse, Automation, Time to Market, cost savings, higher quality, efficiency, all are terms usually used by sales and marketing types to try to entice you into buying their products. However, all of these terms can also be used to describe some of the real benefits gained by utilizing one or both of these standards.

In the design phase of a chip, IP typically comes from internally developed or 3^rd party IP providers. The IP is then integrated into the architecture to functionally perform the task needed by the end application. These can be complicated IP like DDR, Serdes, PLLs, memories, CPUs, etc. They can also be simple IP such as voltage monitors or temperature monitors to check the fab process. In a large customer chip or SOC, you can imagine dozens, or even hundreds, of pieces of IP sprinkled throughout the chip.

A huge task for any chip verification team is to develop all the tests and the testbench to verify all of these pieces of IP in the SOC. Typically, they would have to figure out how to stimulate these IP and then observe something to indicate if the IP works or not. This could be some type of functional test, Built In Self Test (BIST) or loopback test, CPU based test, etc. They’ll need knowledge of that specific chip architecture and how each IP should work. In many cases, these verification tests may need to be driven and observed from the chip pins in simulation so manufacturing tests can be developed from the resulting evcd file(s).

Certainly scan and BIST (Built In Self Test) based testing has helped significantly to make sure the manufactured digital logic is of good quality. However, you still have the big issue of how to connect to these structures, control them, and get failing data out, and how to control the start and stop of these tests.

For IP that might be timing sensitive or mixed signal, other types of verification and testing may still be needed in both the simulation and the ATE tester world.

Wouldn’t it be nice to reuse the original IP provider’s original verification and test suites to make sure all of your IP works and was manufactured correctly? Correct not only for simulation, but for ATE test, Board Test, System Test, and possibly in field testing as well. Now you’re talking about an entire eco-system from design to application.

Wouldn’t it also be nice to have a network that could be reconfigurable to get to and from all of these different pieces of IP in any order you like? This would allow you, for instance, to optimize which manufacturing tests are run, and in which order based on test time, power, etc. All while minimizing test time by not having to access every IP on every scan frame.

Furthermore, wouldn’t it be nice to not have to develop a testbench with all the simulation and have it auto-generated for you?

Still better, wouldn’t it be nice to get ATE patterns directly out of the same process without having to use additional tools to convert simulation to ATE patterns?

Finally, wouldn’t it be nice to be able to use this same common technique and methodology across different products within your company? A common test methodology would give the user the ability to standardize on a common test interface and common reusable test controllers to optimize flow, equipment, training, etc.

These issues and more can be addressed by using these two new standards.

The Bloody Crusades of Embedded IP TEST

Because there is overlap between the new 1149.1-2013 and the P1687 standards, the obvious question is, “Which one is superior?”. Though a better question could be, “Which standard better fits my goals and architectural requirements with the time and resources we have?”. IEEE 1149.1 is still the standard for traditional board test. Your board-mountable components will still rely upon it. However, the overlap between the two standards has a lot of people confused. If you take a step back, it becomes obvious that each can have a place in our new plug and play, automated, reusable world of embedded test capabilities. Both can also leverage integration, verification, ATE test, and validation within chips, within boards, and within systems.

Both standards have a few common basic ideas:

• Support of a reconfigurable network to access test capabilities
• Reuse of IP level patterns at chip, board, and system
• Standard JTAG test interface

It is important to remember that each standard has its own strengths, as well as slightly different input requirements. In future articles, we’ll discuss how you might decide which best fits your needs for a specific device and its goals.

Eventually, the industry will sort out which standard is most useful in which situations, but in the meantime, there is already a bit of a “religious” debate building around this question. Many IP and components may profit from supporting both standards until the debate is settled. The information to do so already exists, and in most cases, simply needs to be formatted in the languages specified by the two standards. We may indeed find that in the designs of tomorrow, we have a mix of IP from multiple sources and some are 1149.1-2013 based, some are P1687 based, and some will support either.

Conclusions

It is clear that both of these standards will affect you in the coming year or so if you are apart of the semiconductor industry. This is especially true of those of you who are in IP development, chip design, verification, integration, test, validation, board test, applications, or system development. Don’t wait around to get involved. Now is the time to get on board before this train leaves you behind!

Be watching for our next article in the series coming out soon!

Full Disclosure About SiliconAid Solutions Inc.

SiliconAid has contributing members in the following IEEE working group: 1149.1-2013, P1687, and IEEE 1149.6. SiliconAid provides a full suite of chip focused products to support P1687, 1149.1, and 1149.6 standards. (IE. We are not a board test focused company. We are a JTAG based standards chip focused company.)

SiliconAid Solutions, Inc. is recognized as a leading provider of Design for Test consulting services encompassing methods, implementation, as well as team augmentation and training. The Senior DFT Consulting Group has been recognized for comprehensive support of all standard EDA DFT solutions.

SiliconAid also delivers world class chip-focused JTAG software solutions to validate, verify, and utilize IEEE 1149.X and P1687 related industry standards. The exhaustive chip-level validation, verification, and debug of IEEE JTAG-compliant implementations is based on over 20 years of testing and thousands of designs from multiple satisfied worldwide semiconductor companies. SiliconAid has corporate headquarters located in Austin, Texas and was founded in 2001.