Authors: Carl Barnhart, Alan Bair, Bill Bruce, and Jim Johnson
Oct 20, 2014 -- We’ll let you decide: “Is it an IP test evolution or revolution?” However, the way to develop test, supply test to others, reuse test, integrate test features, validate test, and target tests to manufacturing is changing. IP Providers, Chip integrators, verification and validation, Test and Product engineering, Failure Analysis, board test, and system testing will be affected by the new IEEE Std. 1149.1-2013 and IEEE Std. P1687.
Overview
This is the second article in a series of articles on a new approach to an old problem: “How to leverage reuse and automation on an industry scale to save/make more money?” This series of articles will focus on the newly revised standard IEEE Std. 1149.1 and a proposed IEEE Std. P1687 standard. In this series we’ll discuss the capabilities of the 1149.1-2013 and P1687 standards, how they will be used, who needs them, and how the industry in general may be changed in the coming years. This article will attempt to objectively compare and contrast the two standards. The next article will look at which standard might be best in different situations.
Both standards now provide the means to describe both the structure and the procedures needed to integrate and automatically use Intellectual Property (IP). This will change what IP suppliers will be expected to provide to their customers, and change how chip design and integration teams buy and use IP. These capabilities can now be accessed through the standard 4 or 5 pin interface of the 1149.1 Test Access Port (TAP.)
For many years, IP macros or on-chip instruments were relatively small, specialized pieces of logic. They could be integrated into a chip easily, and even when they contained I/O drivers or receivers, hooking up to the 1149.1 test structures on a chip was not a significant problem.
That has changed in the world of the modern SOC using multiple IPs, especially the large and complex high-performance IP such as CPU, communication (i.e. SerDes) or external memory interface (i.e. DDR) macros. Integration and test of these types of IP are much more difficult, which implies a higher risk of integration errors and higher support costs for the IP provider.
These large IP macros face many of the same problems that chips on a board faced prior to the introduction of IEEE Std. 1149.1, commonly referred to as JTAG. Prior to 1149.1, attempting to generate board tests required the full chip netlist, and resulted in massive test vector sets. The original 1149.1 provided a standard set of structures to control and observe all of the signals into and out of a chip without having a chip netlist, thereby protecting any proprietary design information while generating very reasonable sized test vector sets. These standard structures allowed the design of general tools that could provide high quality board tests automatically, and resulted in a positive transition in the design and use of digital systems.
The lack of a standardized way in the past to document internal IP or instrument test features in the past impacted what IP providers could deliver and support to their customers. IP suppliers had to balance how many test and other features they provided, including how they were documented. IP suppliers had to bear the risk that their IP would be used or tested in a way not intended thereby producing bad results. The increasing complexity and the lack of a standard test interface also created an increased risk for the integration team. The risk of errors and an open liability for support and assistance to the chip integration team could be expensive and difficult for the IP supplier to predict.
In fairness, we note that IEEE Std. 1500 provided a partial answer by defining a standard wrapper for an IP, similar to what is provided for the chip by 1149.1. This allowed testing the chip logic outside the wrapper, and separately, the application of pre-defined test patterns to the IP inside the wrapper. The language to define the wrapper and the testing of the IP is called Core Test Language (CTL). A full description of CTL can be found in IEEE Std. 1450.6. General tools are available for creating and using a 1500 wrapper, and for mapping IP test patterns to the wrapper. However, the access to this wrapper from the chip boundary is not defined, and the tools and tests for 1149.1 and 1500 were all separate instead of being an integrated set. This continues to burden the chip integrator with access details and makes an integrated approach to chip and board test more difficult, and possibly more error prone.
1149.1 and P1687 Support for Intellectual Property
Until the latest versions of the 1149.1-2013 and P1687 standards, there has not been a standard that addresses all the specific needs to document the connection of internal IP to an external chip interface for direct access. Certainly there are lots of interfaces like earlier 1149.1, I2C, PCIe, and others that define a pin interface that use a protocol to talk to internal structures. However, using these to talk with internal IP in a standard way was not defined. We have been using these interfaces for years in an ad hoc manner to get part of the job done. Larger companies that have many resources have developed internal tools and methods for a specific product or IP. While this was sometimes a good solution, it was typically costly to develop and even more costly to maintain and enhance. Third party EDA companies could not develop generic tools and have a more cost effective solution that could be available across the industry.
There has also been no assistance in any released standard for integrating IP containing chip I/O into the board test structures. IP have become more and more important with time. These large, complex, I/O IP are likely to contain programmable I/O. The programming may just support functional tuning for the specific board, or may support multiple I/O protocols, but there was no standard way to perform that programming. These I/O IP may also contain specific hardware for special chip or board tests, such as verifying the correct “eye” detection, “wrap-back” tests, or Bit Error Rate Test (BERT) of a high speed channel. These tests may be treated as either board or system tests, therefore falling within the scope of 1149.1. They can also be treated as “instruments” not restricted to a test situation, and therefore logically coming under either 1149.1-2013 or P1687.
It was a specific intention of the 1149.1-2013 working group to support the initialization of large I/O macros. It was a specific intention of the P1687 working group to support access to internal instrumentation. Both standards defined structural and procedural descriptions of internal structures. The needs of both led to parallel solutions that, when generalized, result in similar but not identical abilities to describe the access structures and procedures for IP and instruments.
Essentially, with either standard, the IP supplier can now document all of the structural and procedural details needed to access the features of their products in a standard machine-readable form. In the past, these details would have been relegated to a dusty specification document which is in turn open to misinterpretation and not readily available to the chip customers. Chip test, board designers, and board test, and all users downstream of the chip design will need this information. The structural documentation of an IP can now be simply included-by-reference in the chip structural documentation. Furthermore, the procedural descriptions supplied by the IP provider are included as part of the chip level procedural documentation. The chip integration team does not need to create these descriptions.
For 1149.1, the IP and chip providers supply two types of files: structural documentation in Boundary-Scan Description Language (BSDL) or BSDL “User Package” files using new attributes, and procedural documentation in a set of Procedural Description Language (PDL) procedures. For P1687, the IP and chip providers also supply two files: structural documentation in Instrument Connectivity Language (ICL), and procedural documentation in a set of PDL procedures. Due to differences in the intent of 1149.1-2013 and P1687, there are differences in the two flavors of PDL that prevent a single PDL language from supporting both standards, but they are similar.
You can think of PDL as defining the stimulus and reading the response directly to and from the ports of the instrument, for P1687, or to and from the fields of the test data register segment of the IP for either standard. Details of configuring the network for access and scanning the register are hidden from the PDL writer. You can think of the structural documentation sections of the BSDL or ICL file as a description of what switches are available to configure the network, what register fields or ports are available for writing and reading, and optionally what values are defined for a given register field or port. The underlying PDL compile, or “retargeting”, process will use the structural information to automatically access the correct register fields.
