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.
The new structural description capabilities for both standards include a few standard building blocks. These building blocks are pre-defined in an 1149.1-2013 standard package or a P1687 ICL file and can be used to connect IP segments together to create a reconfigurable network that forms the test data register. A basic network can be built from three types of segments: always in-line segments, excludable segments, and selectable segments. The chip integrator can use the excludable segment building blocks to bypass a segment or not, or a selectable segment description to select one out of N segments to include. These basic switched segments can be combined and nested to form complex networks. This ability to document a reconfigurable network, or any network with a changing JTAG TDR length, was not supported in a standard prior to 1149.1-2013.
1149.1-2013 also supports specific controls for power-down domains during test. We will not dwell on this, or several other new capabilities of this revised standard in this series of articles.
P1687 is a proposed IEEE standard that will hopefully be approved and published very soon. P1687 has been created to address how to gain access to internal blocks of logic called “instruments”. An instrument can be almost any group of logic from a single gate to a huge block, sub blocks, or an entire sub-system. Examples could be IP such as DDR, CPUs, temp sensors, memories, sub-systems, etc. Basically any group of gates that you’d like to group together to have test stimulus applied internally within a chip can be described.
P1687 provides a modeling language, ICL, which is more robust than BSDL. This allows the description of the reconfigurable network, and even allows the description of combinational logic between a TDR segment and the instrument ports. Since the standard currently only uses the 1149.1 TAP as its access mechanism, the shift register cells of the TDR must still comply with that standard.
You can think of P1687 as providing a superset of the network description section of 1149.1-2013. P1687 has a lot of the same goals and shares most of the advantages of 1149.1-2013 for IP.
Steps Towards the IP Evolution
Leveraging these standards has many advantages to allow significant savings. The steps in the development process will also need to be changed slightly and the deliverables from step to step will change as well. The flow chart, figure #1, shows the major changes to traditional design and reuse.
IP Providers will have several advantages in utilizing 1149.1-2013 and P1687. Providers will have more control over the way their IP is being tested. This will lead to fewer customer issues and risk of support problems. The IP provider will need to develop the tests in the correct PDL format and create the BSDL package or ICL.
Chip integrators will then be able to “Plug and Play” the IP into the chip test network described from using either standard. The provided IP PDL can be called from the chip level PDL. There is no need to develop a new test access strategy and no need to try and develop test sequences based on the IP spec.
Chip level test verification test patterns can then be automatically generated (retargeted) based on the original IP PDL, chip level PDL, and integrated network description provided by the chip integrator (ICL or BSDL).
After the test patterns simulate without errors, the chip level manufacturing patterns can be generated from the simulation patterns along with any other formats to support board test, debug, or system test.
The retargeting step should ideally only occur once to ensure that the simulated patterns are used downstream in the target manufacturing platforms. This gives another level of quality assurance to the process and makes debug possible if issues need to be tracked back to simulation. It is almost guaranteed that retargeting with different tools will produce slightly different patterns and possibly different results. Since PDL is a high level procedure description language, how the data arrives, the number of serial frames needed, the order of tests, which tests are run in parallel, and more could vary between vendors. Analyzing the network and being efficient in the pattern generation process is important to reducing vector count and optimizing the overall solution.
1149.1 and P1687 Network Description
The simple 1149.1-2013 network above in the figure #2 shows three presumably different IP (shown in dark blue) connected into a complex network. The first (left) IP does not have an internal TDR segment, so a simple wrapper (shown in light blue) is provided to include the TDR segment with the IP. When this wrapper is supplied by the IP provider, then the IP provider can also supply 1149.1 PDL for this IP. 1149.1-2013 treats the wrapped IP as a single entity. In this network, the first IP may be bypassed, or “excluded” in the terms of the standard, with the selecting multiplexer controlled from a register cell, in red, that is outside the segment it controls. The two IP on the right are two of possibly many IP where only one will be selected for scanning. A TDR field that is outside the selectable segments, again in red, will control the selection, as shown. Both control cell fields can be anywhere in the TDRs of the chip, allowing full hierarchical nesting to any level, but must always be outside the segment controlled by that control cell.
The above P1687 network, figure #3, shows a similar network but illustrates the greater flexibility of the P1687 structural description. The first IP again has no built-in TDR segment, but no wrapper is needed. Similarly, the second IP (top right) not only has no built-in TDR segment, but has combinational logic between the TDR and the IP. In both of these cases, the PDL would write to and read from ports of the IP, and the retargeting process will convert the values at the ports to values in the register segment. In the last IP shown, the TDR segment is built-in and the IP provider would provide the ICL description of this TDR segment. Again, the two IP on the right represent two out of possibly many IP, only one of which may be selected at a time. Again, control cells are in red, and the structures may be nested in a hierarchy.
As shown in the figure, P1687 has the advantage of immediately supporting existing (or future) IP that do not have a test data register built-in or in a wrapper. For IP not having the TDR segment included, P1687 has the disadvantage of forcing every chip integration team using the IP to build a test data register within the network and to write the ICL that describes the network. This may increase the possibility of introducing errors. Furthermore, the P1687 retargeting tool will need to analyze and retarget the pattern through any logic, as illustrated above with the top right IP block, between the TDR and the ports of the instrument. If the TDR segment for accessing the IP is built-in, then the IP provider would supply the ICL as well as the PDL. The PDL could then be written to the register fields, and one source of possible integration errors would be eliminated.
The structural documentation of either standard can provide any desired level of detail of test data register fields or instrument ports. If a TDR segment is supplied, full documentation could include the number of bits and position of each appropriate field in a register segment, even if the bits are not contiguous. Fields or ports that are reserved for proprietary purposes can be listed as reserved or even left undocumented. Also, legal, illegal, and reserved values to be written to or read from the fields or ports can be defined and given names for convenience. Where desired, 1149.1-2013 also allows constraints. A constraint is checked by software prior to scanning a register to prevent illegal values or combinations of values from being scanned to a TDR, whereas P1687 has no such function.
With this type of fully described structural documentation, the procedural documentation becomes a matter of writing or reading named values to and from named fields or ports. It is not necessary for the PDL writer to know all the details of the register network, location of fields or ports within the network, or even the binary values being written and read. This makes it easier to think about the problem and define the proper solutions. This type of higher level test stimulus can then be applied with automated tools leveraging either of the new standards.
Alternatively, just the length of the register segment or the width of the ports in the IP can be documented, and the PDL can write and read binary values to and from specific bit ranges of the width. This style of PDL (commonly called bit-banging) is more difficult to write and debug, but does reduce even further the amount of information revealed by the IP supplier.
Improving Reuse, Reducing Cost, and Reducing Risk
These new structural and procedural descriptions define and limit what IP customers are expected to do with the IP, thus avoiding many problems of incorrect usage. 1149.1-2013 requires specific names of PDL procedures to be executed automatically during board test initialization. PDL procedures may be supplied to provide additional functional, verification, test, or debug capability. Such debug procedures can be used by the customer or by the IP supplier when necessary for support. The entire system is reasonably simple and straightforward, and eliminates multiple sources of error in the current design, verification, and test flow.
This new flow and methodology can remove much of the detail work involved in creating procedures requiring serial bit streams as previously used with the 1149.1 interface. It also enables integration of the IP into a chip without the integrator having to understand all the IP register segment details and without having to manually generate test procedures for the IP at the chip level. In fact, neither the chip integrator nor the downstream test engineers have to concern themselves with what the PDL is actually doing or how the test data registers or instrument ports are formatted.
Both standards also allow, for the first time, description and integration of the 1500 wrapper structure in an 1149.1 chip description. This allows PDL to access an IP with a 1500 wrapper at the same time it is accessing other IP.
All of this is intended to provide ease of use, maximize reuse, establish a documented verification and test methodology, and faster generation of tests while minimizing debug time.
Conclusions
It is clear that both of these standards will affect you and the entire industry in the next year or so if you are in the semiconductor industry doing IP or chip development. The results will be a significant advance in rigor and standardization of IP deliverables, significant improvements in the ability of an IP provider to control the use of their IP, and significant increases in the ease of use of IP. IP suppliers will be able to deliver IP with essentially turn-key integration with the rest of the chip, especially in the often mis-understood and even neglected areas of test.
1149.1-2013 has many other features that are new and not discussed in this article. Significant functionality with regards to power domains, segmenting the boundary scan register, chip initialization and more has been added.
While we have focused on IP test, today 1149.1 will be required for instrumentation that utilizes 1149.1-2013 or P1687.
Full Disclosure About SiliconAid Solutions Inc.
SiliconAid has contributing members in the following IEEE working groups: 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.)
Want to find more information on SiliconAid Solutions 1149.1-2013 and P1687 tool suite? ( www.siliconaid.com/)
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