We’ll let you decide: “Is it an IP test evolution or revolution?” Whatever the outcome, change is afoot on the way to develop test, supply test to others, reuse test, integrate test features, validate test, and target tests to manufacturing. 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.
This article is part two of a series on a new approach to an old problem: “How do you leverage reuse and automation on an industry scale to save/make more money?” It focuses on the newly revised standard IEEE Std. 1149.1 and a proposed IEEE Std. P1687 standard.
This file type includes high resolution graphics and schematics when applicable.
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 will look at which standard might be best in different situations.
Both standards now provide the means to describe the structure and procedures needed to integrate and automatically use intellectual property (IP). This will change what customers can expect from IP suppliers, and 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 a chip’s 1149.1 test structures was not a significant problem.
That has changed in the world of the modern system-on-chip (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 reasonably sized test-vector sets. These standard structures allowed for the design of general tools that could provide high-quality board tests automatically, which led to a positive transition in digital-system design and usage.
In the past, the lack of a standardized way to document internal IP or instrument test features affected what IP providers could deliver and support to their customers. IP suppliers had to balance how many test and other features they provided, including their documentation. IP suppliers were risking that their IP would be used or tested in a way not intended, thereby producing bad results. The increasing complexity and lack of a standard test interface also created greater risk for the integration team. The prospect 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’s provided for the chip by 1149.1. This allowed for chip-logic testing 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 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, 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 chip integrators with access details, making an integrated approach to chip and board test more difficult and possibly more error-prone.
1149.1 and P1687 Support for IP
Until the latest versions of the 1149.1-2013 and P1687 standards, no standard has addressed all of the specific needs to document the connection of internal IP to an external chip interface for direct access. Certainly, lots of interfaces like earlier 1149.1, I2C, PCIe, and others, define a pin interface that uses 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 with many resources 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.
In addition, no released standard has offered assistance for integrating IP containing chip I/O into the board test structures. IP has become more and more important with time. Large, complex I/O IP is likely to contain programmable I/O. The programming may just support functional tuning for the specific board, or 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, which logically puts them 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. And, 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 structural and procedural details needed to access the features of their products in a standard machine-readable form. In the past, these details would be relegated to a dusty specification document that, in turn, is 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 needn’t 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, differences exist 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.
Structural documentation sections of the BSDL or ICL file can be considered as descriptions 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 may use the excludable segment building blocks to bypass a segment or not, or a selectable segment description to select one out of N segments for inclusion. These basic switched segments can be combined and nested to form complex networks. The 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.
Specific controls for power-down domains during test are supported by 1149.1-2013, too. We will not dwell on this, or several other new capabilities of this revised standard, in this article series.
P1687 is a proposed IEEE standard that will hopefully be approved and published very soon. It was 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 subsystem. Examples could be IP such as DDR, CPUs, temp sensors, memories, subsystems, etc.—basically any group of gates that you’d like to internally apply test stimulus within a chip can be described.
P1687 provides a modeling language (ICL) that’s more robust than BSDL. This allows for the description of the reconfigurable network, and even 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 lots of the same goals and shares most of the advantages of 1149.1-2013 for IP.
Steps Toward the IP Evolution
Leveraging these standards has many advantages that lead to significant savings. However, the steps in the development process also need to change slightly, as do the deliverables from step to step. The flowchart shows the major changes to traditional design and reuse (Fig. 1).
Several advantages emerge when IP providers utilize 1149.1-2013 and P1687. Providers will have more control over the IP test methods, which will help reduce customer issues and risk of support problems. The IP provider will need to develop the tests in the correct PDL format, though, 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’s no need to develop a new test access strategy, nor 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, it’s possible to generate the chip-level manufacturing patterns 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.
Because PDL is a high-level procedure description language, a number of elements could vary between vendors, such as: how the data arrives; the number of serial frames needed; the order of tests; which tests are run in parallel; and others. 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
In one example of a simple 1149.1-2013 network, three presumably different IP (depicted in dark blue) are connected into a complex network (Fig. 2). The first (left) IP doesn’t have an internal TDR segment, so a simple wrapper (shown in light blue) is provided to include the TDR segment with the IP. When the IP provider supplies the wrapper, then it can also supply 1149.1 PDL for this IP. The wrapped IP is treated as a single entity in 1149.1-2013.
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’s outside the segment it controls. The two IP on the right are two of possibly many IP, of which only one will be selected for scanning. A TDR field outside the selectable segments (again in red) will control the selection. 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 P1687 network shows a similar network, but illustrates the greater flexibility of its structural description (Fig. 3). The first IP again has no built-in TDR segment, but it doesn’t require a wrapper. 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. Control cells are in red, and the structures may be nested in a hierarchy.
As shown in the figure, P1687 holds the advantage of immediately supporting existing (or future) IP lacking a test data register that’s built-in or in a wrapper. However, for IP with no TDR segment, P1687 forces every chip integration team to use the IP to build a test data register within the network and 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 with the top right IP block, between the TDR and the ports of the instrument (Fig. 3, again). If the TDR segment for accessing the IP is built-in, the IP provider would then supply the ICL as well as the PDL. Subsequently, the PDL could be written to the register fields, thus eliminating one source of possible integration errors.
Structural documentation of either standard can provide any desired level of detail for test-data-register fields or instrument ports. If there’s a TDR segment, 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 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. 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’s not necessary for the PDL writer to know every detail of the register network, location of fields or ports within the network, or even the writing and reading of binary values. This makes it easier to think about the problem and define the proper solutions. Such higher-level test stimulus can then be applied with automated tools leveraging either of the new standards.
Alternatively, it’s possible to document just the length of the register segment or width of the ports in the IP, 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 further reduce 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. With 1149.1-2013, specific names of PDL procedures must 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 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 that require serial bit streams, as previously used with the 1149.1 interface. It also enables IP integration into a chip without the integrator having to understand all of the IP register segment details or manually generate test procedures for the IP at the chip level. In fact, neither the chip integrator nor the downstream test engineers need concern themselves with the PDL’s actual function or test-data-register/instrument-port formats.
This file type includes high resolution graphics and schematics when applicable.
Both standards also allow, for the first time, description and integration of the 1500 wrapper structure in an 1149.1 chip description. Consequently, a PDL can access an IP with a 1500 wrapper while accessing other IP.
All of this is intended to provide ease of use, maximize reuse, establish a documented verification and test methodology, and accelerate generation of tests while minimizing debug time.
Conclusions
It’s clear that both of these standards will affect you and the entire industry in the next year or so, especially if you’re involved with IP or chip development in the semiconductor arena. The end result? Significant advances in rigor and standardization of IP deliverables, the ability of an IP provider to control the use of their IP, and ease of use of IP. IP suppliers will be able to deliver IP with essentially turnkey integration with the rest of the chip, especially in the often misunderstood and even neglected areas of test.
The 1149.1-2013 standard has many other new features not discussed in this article. Significant functionality with regard to power domains, segmenting the boundary-scan register, chip initialization, and more has been added. While we have focused on IP test, 1149.1 will be required for instrumentation that utilizes 1149.1-2013 or P1687.
SiliconAid (go to www.siliconaid.com) 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 (it’s a JTAG-standards chip-based, rather than board-test focused, company).