Since its adoption in 1990, IEEE 1149.1 has enjoyed great popularity. The standard was built on the work of an industry organization, the Joint Test Action Group (JTAG), formed in the mid-1980s to provide a pins-out view from one IC pad to another to help test engineers locate and discover faulty PCBs.
In 1994, a description of the boundary scan description language (BSDL) was added to the standard, and its official name—the Test Access Port (TAP) and Boundary Scan Architecture—was finalized. Since then, boundary scan and JTAG have become practically synonymous terms. Regardless of what terms engineers use to describe it, 1149.1 has been adopted by electronics companies around the world.
As the industry has evolved over the past two decades, 1149.1 also became widely used for two other purposes that were not part of the original intent:
•?Software debugging in which the JTAG ports are used as a back door into the system.
•?Testing ICs by accessing sub-blocks of chips and using BIST, a complementary technology.
As chips added more functionality and leading-edge subsystem designs evolved away from PCBs and toward multichip modules and stacked die packages, new challenges arose for JTAG, including:
•?Handling the pin-count requirements for SOC devices.
•?Accommodating multiple TAP controllers in SOC devices.
•?Testing multichip modules and stacked die configurations.
•?Improving debug performance.
•?Improving power-down of test and debug logic in low-power conditions.
•?Harmonizing deviations from 1149.1 by companies that required more functionality.
Industry groups such as the Mobile Industry Processor Interface (MIPI) standards body and the NEXUS 5001 Forum began working independently to solve the problems specific to their industries. Their work laid the foundation for IEEE 1149.7.
IEEE 1149.7 in Brief
IEEE 1149.7 is not meant as a replacement for 1149.1. To preserve the existing industry investment, it uses 1149.1 technology as a foundation and preserves backward compatibility. Most of the new features and capabilities are intended to add significant focused capability for applications debug, but retaining the test capabilities of 1149.1 was a high priority.
As a result, the goals of 1149.7 are to:
•?Provide compatibility for existing 1149.1 systems.
•?Operate with fewer pins.
•?Provide background instrumentation capability using the same pins.
•?Provide mechanisms for TAP power management.
•?Preserve gateways for debug of Si errors/defects.
•?Preserve investment of hardware, software IP, and existing debug and test tools.
•?Provide a framework for other debug pin protocols to gain access to the pins.
How the Standard Is Organized
The working group approached its task by thinking of 1149.7 as generally having two groups of capabilities. The first are very much oriented toward the test perspective and are extensions to 1149.1. At the same time, they provide techniques and methodologies making it possible to implement advanced operations that never were intended or anticipated in 1149.1. The second group of capabilities is focused on advanced two-pin operation.
Both groups are subdivided into operational classes with each class building upon the functions provided by the previous class. In total, there are six operational classes in 1149.7. The first four—T0 through to T3—implement the first group of capabilities and extend 1149.1. Classes T4 and T5 comprise the second group, which addresses two-pin operation.
Class T0
Class T0 sets up 1149.7 devices to make them act compatibly with 1149.1. These workaround techniques include the use of N-bit IR and 1-bit DR for bypass instruction, IDCODE is mandatory (32-bit path), and mandatory instructions should behave as specified in 1149.1.
After a test-logic reset is initiated, all multitap devices must conform to the mandatory 1149.1 instruction behavior and implement a 1-bit DR scan for the bypass instruction.
Class T1: Control Structure
Class T1 instantiates a control system for 1149.7 transparent to 1149.1-enabled devices. The control system becomes the foundation for the advanced functionality implemented in Class T1 through T5 and is established without changing or modifying the existing 1149.1 state machine.
The key innovation is the use of 1149.1-compatible TAP state sequences combined with the use of shift-state watching and, more specifically, counting the number of state shifts that happen but have no effect on the 1149.1 state machine, to create an 1149.7 control system.
The 1149.7 control system uses the BYPASS or IDCODE instructions combined with a series of 1149.1-compliant sequences. These sequences are called zero-bit DR scans (ZBSs).
Here’s how to implement a ZBS: The state sequence begins at the Select-DR-Scan state and proceeds to an Update-DR TAPC state without an intervening Shift-DR TAPC state (Figure 1).
The control system depends on counting the number of ZBSs. The allowable use of ZBSs can only begin after a Test-Logic-Reset because this state initializes the instruction registers with either the BYPASS or IDCODE instructions.
Beginning with a ZBS count of zero, the ZBS count is incremented with each consecutive occurrence of a ZBS without encountering a Shift-DR TAPC state. When a DR scan containing a Shift-DR occurs and the ZBS count is greater than zero, the ZBS count is locked. Additionally, any subsequent ZBSs do not affect the locked ZBS count.
Locking the ZBS count is equivalent to storing the count for subsequent use. This also activates a control level that is equal to the locked ZBS count 1-7.
A control level is exited when any of certain events occur. These events are the Select-IR-Scan controller state, the Test-Logic-Reset state, and certain controller commands and events that are meant to synchronize the operation of Class T4 and T5 controllers.
The use of control levels not only alters the function of the BYPASS/IDCODE instruction, it also may alter the scan path. In Figure 2, the term Overloaded Function describes the 1149.7 functionality beyond what is offered in 1149.1.
With the availability of control levels, a control hierarchy can be constructed with commands and registers. Controller commands are accepted at Control Level 2. These typically are 10-bit values and consist of two consecutive DR scans while the controller is locked at Level 2. Command Part 1 (CP1) provides a 5-bit operating code, and Command Part 2 (CP2) offers the immediate operand, which is the lower 5 bits of the command.
These two 5-bit values are created by counting the number of Shift-DR states (truncated at 5 bits) between the Capture-DR and Update-DR states of a DR Scan. The control hierarchy forms the basis for the two-pin operation with Classes T4 and T5. Command creation uses only state progressions, requiring only the test clock (TCK) and the test mode select (TMS) pins.
Engineers also can create a three-part command if they want to send/receive data values other than values embedded in CP2. This is done by appending a third DR scan after CP1 and CP2 and transports a data value, for example.
If the command is in two parts, the function specified by it is performed when command part 2 completes. If it is a three-part command, a DR Scan following CP2 performs the controller function designated by the 10-bit controller command.
The DR scan associated with a three-part command is called a control-register scan (CR Scan). It can be used to move data among the debug test system (DTS), the 1149.7 controller, and various scan paths. There are only three three-part commands, each having a special purpose.
In addition to creating a control system, Class T1 addresses the needs of power-sensitive devices. Four power-down modes are defined in 1149.7 to assist engineers during board test, chip testing, and applications debugging:
•?Allow power down if TCK is a logic value 1 for more than 1 ms.
•?Allow power down if TCK is a logic value 1 for more than 1 ms and in the Test-Logic-Reset TAP controller state.
•?Allow power down if the device is in the Test-Logic-Reset TAP controller state.
•?Always powered.
Class T2: Chip-Level Bypass
To achieve higher performance for engineers involved in testing high-chip-count applications, Class T2 offers a chip-level bypass mechanism to shorten scan chains. It also provides a mechanism with a hot-connect capability.
Class T2 adds three scan formats to implement these new features:
•?JSCAN0 —provides compliant 1149.1 operation.
•?JSCAN1—provides hot connection and disconnection protection. At power up, you can have the bypass as the default (JSCAN1 scan format). This protects TAPs from spurious signals and prevents core corruption during hot connections.
•?JSCAN2—implements bypass for improved performance for series connected devices. This mechanism also functions as a firewall, enabling access to chip TAPs only after a predetermined sequence is initiated. This security measure ensures that only a debug test system can access the system once a connection to a running, powered target has a stable electrical connection.
Class T3: Star Network Topology
Although provisions for boundary scan testing using a star topology are included in 1149.1, the standard does not provide enough detail to make this mode of testing viable. JSCAN3, a new scan format, is included in 1149.7 to correct this omission. A write-only register is used to specify the scan format, and a device address assignment for star configurations has been added to the new standard.
Star topologies are preferable for testing stacked die configurations. Both star and series topologies are supported by 1149.7. Figure 3a shows the series scan topology. The star configuration support in T3 is the Star-4 or wide star configuration as shown in Figure 3b.
Figure 3a. Series Scan Topology Using Scan Formats JSCAN0, JSCAN1, and JSCAN2
Figure 3b. Star Topology Using the JSCAN3 Format
1149.7 maintains compatibility with 1149.1 by creating a methodology that, from the boundary scan perspective, makes all operations appear to be series scans.
Scan operations in an 1149.7 star configuration are functionally equivalent to series scan operations when the Capture-xR and Update-zR TAP controller states among a group of selected 1149.7-enabled TAP controllers are synchronized. Scan data associated with this selected group of TAPs is exchanged between one TAP at a time between these states. In addition, the TAPs must be selected and then deselected without going into the Capture-xR and Update-xR states.
To operate in this mode, the chips in the star configuration must be assigned controller identification (CID) numbers. An iterative arbitration system is used to assign CIDs, and its operations are executed using Control Level 2. Here’s the process:
•?Chips that do not have a CID assigned participate. At the start, that is all the chips.
°?TDO output is Wire-ORed.
°?Each chip compares data on output to its desired output.
°?If the DTS-driven desired output is different than the combined output of all participating chips, the chip can see that on its TDO pin, and it is disqualified. It will not participate in the output of the next bit.
°?At the end of the 32-bit output, all chips are disqualified except for one chip.
°?This chip is assigned an identification number by the DTS.
•?Chips with a CID assigned do not drive TDO when no chips are selected, leaving the arbitration process to chips that do not have CIDs assigned.
•?Process repeats until all devices are assigned a CID.
Class T4
Class T4 adds scan formats to support transactions with two pins instead of four, resulting in fewer total pins being required on chip packages.
In brief, the key to two-pin operation is eliminating the original data lines, sending bidirectional serialized data over the TMS line which is renamed TMSC. To implement this capability, the glueless star configuration from Class T3 is used, this time without TDI and TDO. This is the Star-2 configuration shown in Figure 4.
In addition to reducing pin-count, Class T4 defines optimized download-specific scan modes. In these modes, only useful information is downloaded. To improve performance of reduced-pin operation, the clock rate also can be doubled. This, along with the optimized transactions, means there is no loss of performance, and in some cases, an improvement.
Class T5
Class T5 functionality is beneficial primarily to software designers using JTAG for debugging. It has two primary benefits:
•?It gives the test port the capability to concurrently perform debug and instrumentation operations, which reduces the number of pins dedicated to instrumentation. This becomes possible because instrumentation data is transferred during idle time.
•?Class T5 also provides for the use of the pins by custom protocols. Class T5 standardizes the process to access the pins.
Conclusion
Over the years since IEEE 1149.1 was created, issues arose that made it desirable to add functionality to the standard, which has been done through the introduction of 1149.7. The goals of the working groups were maintaining backward compatibility with 1149.1, reducing SOC pin-counts, providing power-down for low-power conditions, simplifying manufacturing and test for multichip modules and stacked die devices, and improving debug capabilities.
The new standard has achieved all those goals by cleverly using unused functionality in 1149.1, introducing a star configuration, and maintaining compatibility even with advanced new functionality with protocol adapters.
About the Author
Stephen Lau is the product manager for emulation technology at Texas Instruments. He established the first commercial IP license for debug technology at TI. Prior to joining the emulation team, Mr. Lau was in sales and marketing at TI. He holds a B.S. in electrical engineering from McMaster University. Texas Instruments, 12500 TI Blvd., Dallas, TX 75243, e-mail: [email protected]
July 2009