Standards

Managing Complex Boundary-Scan Operations

Bill Eklow Cisco Systems, Inc.

h THE

IEEE 1149.1 Standard for Test Access Port and Boundary-Scan Architecture was approved and released in 1990. Since that time, there have been two supplements and one revision to the standard. A second revision is currently in process. The 1149.1 standard was originally developed to address board level test access issues while at the same time enabling access to test logic inside the device. As technology has scaled over the last 20+ years, component and board level density and complexity have grown significantly. A new class of defects (Timing, Power, Signal Integrity) has also become more prevalent and much more difficult to detect. All of this has led to a preponderance of embedded test instruments which can augment ATE coverage and test time capabilities. These instruments include built-in memory, logic, and I/O test engines; temperature and voltage monitors; debug instruments such as: logic analyzers, scopes, and trace buffers; IP test wrappers to partition and provide direct test access to IP blocks. The 1149.1 Test Access Port has become much more prominent as THE access port to this preponderance of test instruments. Unfortunately, programming these test instruments through the test access port was/is an ad hoc process which was/is usually not well defined. Simple board level testing through the boundary register has become more complex as well. Resetting/Initializing components may now involve a series of operations that include: sequenced bring up of power domains, setting up PLLs and program-

ming of I/Os. The 1149.1 working group has also identified the need to safely transition between a functional mode and a test mode. Real life examples of damage done by blind transitions have been presented by Ken Parker at ITC 2011. These new complexities have led to the proposal of a new standard (IEEE P1687) and several enhancements to the current revision of the 1149.1 standard. Both drafts are scheduled to go to ballot later this year. The remainder of this column will address the hardware and software efforts of both working groups to deal with the complexity described earlier.

Efficient access to embedded test instruments

Given the multitude of embedded test instruments, it is critical that there be a standardized way to describe the logistical (how do I access that instrument?) and functional (how do I operate that instrument?) characteristics of each instrument so that tools providers can automate test development for these embedded instruments. The IEEE P1687 Standard for Access and Control of Instrumentation Embedded Within a Semiconductor Device proposes to provide a standardized architecture for accessing embedded test instruments. This architecture is comprised of three elements: an instrument interface specification consisting of standard signals (clocks, data, and control) used to control and observe P1687 instruments; a description language that documents how instruments are connected to the TAP controller (through a P1687 network); and a procedural language that documents the operation of the instruments.

Digital Object Identifier 10.1109/MDT.2012.2187859 Date of current version: 26 June 2012.

100

0740-7475/12/$31.00 B 2012 IEEE

Copublished by the IEEE CEDA, IEEE CASS, and IEEE SSCS

IEEE Design & Test of Computers

P1687 starts by defining an instrument as a black box with signals (ports) that are host facing (the host drives inputs and receives outputs). In its simplest form, this instrument could be an 1149.1 TDR, whose outputs are controlling the instrument and whose inputs are observing the instrument. The ports, in this case, would be the typical 1149.1 inputs/ outputs to the TDR from the TAP controller (TDI, Capture, Update, Shift . . .) and from the TDR to the TAP (TDO). An Instrument Connectivity Language(ICL) maps those ports back to the TAP controller through a series of configurable networks. In essence, describing the access path to the instrument. A Procedural Description Language (PDL) describes the sequence of operations that need to be performed on the ports in order to execute specific functions. The ICL and PDL allow for an instrument to be described functionally at an atomic level and then mapped through the component hierarchy to the component boundary. This remapping (retargeting) is a key component of the P1687 standard, allowing instrument operation to be remapped both inside the component and possibly at a higher level (board/ system). Functionality can be described as simple writes and reads, however, the working group is augmenting the PDL to allow for more complex operations which may be time bound or may require some decision-making as part of the function.

Some of the new features proposed in the revised standard include:

h

Enhanced board level, boundary-scan test capabilities

Evolving component level technology has imposed new requirements on boundary-scan (TAP) based testing, including: complex reset sequences; test initialization which may include configuring IO parameters; the ability to safely transition from test mode to functional mode; the ability to maintain the integrity of the boundary scan test logic in light of varying power requirements/availability; and component/die level traceability based on die ID. Its clear that the most significant changes to the 1149.1 standard are driven by the need to ensure that the test logic and functional logic are set to the correct (safe) state before, during, and after the execution of the boundary-scan test. Accomplishing this task is not as straightforward as in the past. Similar to IEEE P1687, 1149.1 addresses these requirements through a combination of hardware capabilities and a procedural language to document the more complex functions.

A new reset instruction which allows test logic to assert resets to the (nontest) functional logic through the TAP controller. This test initiated reset ensures that the functional logic on the device can be put into a safe state after testing has been completed, without the need to cycle power or activate an external reset. A Test-Mode Persistence Controller is added to block any unintended excursions from test mode to functional mode, again ensuring that the device can be kept in a safe state before, during and after testing. New instructions have also been added to activate and deactivate the Test-Mode Persistence Controller. A pair of optional instructions that enable initialization/configuration of the component prior to test. One instruction (INIT_SETUP) allows configuration data to be stored, while another instruction (INIT_RUN) applies the stored data to the corresponding logic (typically I/Os, but initialization data can be applied to any logic in the device in order to ensure correct and safe performance during test mode). New rules have been added which allow segmenting of Test Data Registers (TDR) and bypassing inactive segments. The segmenting and bypassing of inactive segments maintains the integrity of the TDR if parts of the TDR pass through a power domain which may be powered off during the loading/unloading of data into the TDR. Note that the new revision of 1149.1 also addresses control of power domains. An ECIDCODE instruction which enables storing and access to component Die ID information. The use of Die ID information is gaining relevance as traceability and data driven manufacturing are becoming more prominent through the supply chain.

My Comments: The new features described earlier go a long way in ensuring that test logic can operate in an efficient, deterministic, and nondestructive manner during testing, and while transitioning between test mode and functional mode. However, these solutions to complex problems involve a certain amount of complexity themselves. This complexity has been a significant and time

March/April 2012

101

Standards

consuming task for both working groups to overcome. The inclusion of a Procedural Description Language in both standards has also led to some work to ensure that there is consistency between the two standards on the intent, effect and syntax of the procedural descriptions. The result of the two standards should, however, be a comprehensive solution to component level and board level test and debug. Please note that several features in both standards were not covered in this column. For more information on the IEEE 1149.1 working group and new revision, please go to the following: http:// grouper.ieee.org/groups/1149/1, and for more information on the IEEE P1687 standard, please go to: http://grouper.ieee.org/groups/1687. It is also impor-

tant to note that both standards are intending to go to ballet before the end of this year. Finally, it is important to note that the IEEE 1500 and its programming language, IEEE 1450.6 (CTL) also have had a significant impact on managing test complexity at the embedded Core/IP level. They will be covered in a later column. h
Bill Eklow is a Distinguished Engineer at Cisco Systems.

h Direct questions and comments about this article

to Bill Eklow, Cisco Systems, Inc., 80 W. Tasman Drive, San Jose, CA 95134, USA; beklow@ cisco.com.

102

IEEE Design & Test of Computers