Академический Документы
Профессиональный Документы
Культура Документы
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.
100
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.
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.
102