SYSTEM AND METHOD FOR SHARING A COMMUNICATIONS LINK BETWEEN MULTIPLE COMMUNICATIONS PROTOCOLS

BACKGROUND

As electronic circuits and devices have become more complex, testing of these devices has become increasingly difficult. Test standards have been developed to address at least some of these testing difficulties. One such standard, written by the Joint Test Action Group (“JTAG”), is IEEE standard number 1149.1, which describes the Standard Test Access Port and Boundary-Scan Architecture. Boundary scan is a methodology that allows controllability and observability of the boundary pins in a JTAG compatible device via software control. This capability allows testing of circuit boards that otherwise might not be practical or possible given the trace pitch and multi-layering of printed circuit boards today. Testing is accomplished through a series of registers, accessible through a serial bus, which allow the pins of JTAG compatible devices to be temporarily isolated from their respective devices. The pin on one isolated JTAG compatible device may be set to a known test state while the pin on another isolated JTAG compatible device is monitored to confirm that it is in the same known state. In this way individual traces on a printed circuit board may be tested. This type of testing has generally represented the limits of the testing capabilities of the JTAG architecture.

SUMMARY

The present disclosure describes an adapter system and method for sharing a communications link between multiple communications protocols, such as debug and test.

BRIEF DESCRIPTION OF THE DRAWINGS

For a detailed description of the preferred embodiments of the invention, reference will now be made to the accompanying drawings in which:

FIG. 1 illustrates the signals of a link between a debug test system and a target system of a cJTAG capable system in accordance with at least some preferred embodiments;

FIG. 1A illustrates a detailed block diagram of the debug and test system of FIG. 1 in accordance with at least some preferred embodiments;

FIG. 2A illustrates star and series configurations that are possible within a cJTAG capable system in accordance with at least some preferred embodiments;

FIG. 2B illustrates series, narrow star and wide star configurations that are possible within a cJTAG capable system in accordance with at least some preferred embodiments;

FIG. 2C illustrates a series and a wide star cJTAG capable system configured, both configured to operate as narrow star configurations in accordance with at least some preferred embodiments;

FIG. 3 illustrates a block diagram overview of a cJTAG capable system in accordance with at least some preferred embodiments;

FIG. 4 illustrates the state transition diagram for a TAP state machine within a cJTAG capable system in accordance with at least some preferred embodiments;

FIG. 5 illustrates a high-level schematic of a JTAG target system in accordance with at least some preferred embodiments;

FIG. 6A illustrates a first example of an inert JTAG data scan sequence usable to enter into an advanced mode of operation in accordance with at least some preferred embodiments;

FIG. 6B illustrates a second example of an inert JTAG data scan sequence usable to enter into an advanced mode of operation in accordance with at least some preferred embodiments;

FIG. 6C illustrates a simplified version of FIGS. 6A and 6B in accordance with at least some preferred embodiments;

FIG. 7 illustrates the format of an advanced mode command window in accordance with at least some preferred embodiments;

FIG. 8A illustrates an example of an assignment of various functions to specific command levels in accordance with at least some preferred embodiments;

FIG. 8B illustrates an example of specific scan counts associated with specific advanced mode commands in accordance with at least some preferred embodiments;

FIG. 9 illustrates a simplified state transition diagram showing the transitions between IEEE mode and standard mode in accordance with at least some preferred embodiments;

FIGS. 10A and 10B illustrate a state transition diagram for a cJTAG adapter in accordance with at least some preferred embodiments;

FIG. 11 illustrates the format for an optimized scan message in accordance with at least some preferred embodiments;

FIGS. 12A and 12B illustrate examples of several different optimized scan message formats in accordance with at least some preferred embodiments;

FIG. 13 illustrates the timing diagram for an example of an optimized scan without a scan stall in accordance with at least some preferred embodiments;

FIG. 14 illustrates the timing diagram for an example of an optimized scan with a scan stall in accordance with at least some preferred embodiments;

FIG. 15A illustrates the timing diagram of a fixed delay between scan messages in accordance with at least some preferred embodiments;

FIG. 15B illustrates an example of delay control register bit settings in accordance with at least some preferred embodiments;

FIG. 16A illustrates the timing diagram for a variable delay between scan messages in accordance with at least some preferred embodiments;

FIG. 16B illustrates the state transition diagram for extending a delay between scan messages in accordance with at least some preferred embodiments;

FIG. 17 illustrates the timing diagram for several escape sequences in accordance with at least some preferred embodiments;

FIG. 18 illustrates a cJTAG target system implementing a global bypass bit in accordance with at least some preferred embodiments;

FIG. 19 illustrates a method for assigning link IDs within a cJTAG enabled system in accordance with at least some preferred embodiments;

FIG. 20 illustrates an example of a multi-device scan message format in accordance with at least some preferred embodiments;

FIG. 21 illustrates a circuit used to allow target system isolation for later link ID assignment in accordance with at least some preferred embodiments;

FIG. 22A illustrates a method implemented in a debug test system for assigning link IDs in accordance with at least some preferred embodiments;

FIG. 22B illustrates a method implemented in a target system for assigning link IDs in accordance with at least some preferred embodiments;

FIG. 23 illustrates an example of a format for a unique cJTAG isolation pattern in accordance with at least some preferred embodiments;

FIG. 24 illustrates an example of a burst background data transfer message format in accordance with at least some preferred embodiments;

FIG. 25 illustrates an example of a burst background data transfer message header in accordance with at least some preferred embodiments;

FIG. 26 illustrates an example of a continuous background data transfer message format in accordance with at least some preferred embodiments;

FIG. 27 illustrates an example of a continuous background data transfer message payload format in accordance with at least some preferred embodiments;

FIG. 28 illustrates an example of a burst custom data transfer message format in accordance with at least some preferred embodiments;

FIG. 29 illustrates an example of a continuous custom data transfer message format in accordance with at least some preferred embodiments;

FIG. 30 illustrates an example of power down modes;

FIG. 31 is a timing diagram illustrating an affirmative response power down;

FIG. 32 illustrates an example of non-response power down.

FIG. 33 is a block diagram of a standard IEEE 1149.1 emulator with an external cJTAG Adapter;

FIG. 34 is a block diagram of a cJTAG capable emulator;

FIG. 35 is a block diagram of a DTS and TS link interface

FIG. 36 is a DTS Adapter block diagram;

FIG. 37 is a table of DTS Adapter Signals;

FIG. 38 is a Target System Adapter block diagram;

FIG. 39 is a TS Adapter block diagram;

FIG. 40 is a table of TS Adapter Signals;

FIG. 41 is a table of TAP State Machine State Encoding;

FIG. 42 is a diagram of CSM, IOSM, and XSM TMSC Control Sharing;

FIG. 43 is a diagram of Command Sequence State Machine;

FIG. 44 is a CSEQ State table;

FIG. 45 is a diagram of Command Sequence State Machine Implementation;

FIG. 46 is a chart of state encoding;

FIG. 47 is a diagram of state encoding;

FIGS. 48A, 48B, 49A, and 49B are timing diagrams of ZBS and Command Window Relationships;

FIG. 50 is a block diagram of TCK Sources;

FIG. 51 is a table of DTS vs. TS TCK Source Comparison;

FIG. 52 is a table of Drive Characteristics;

FIG. 53 is a timing diagram of TS TMSC Drive;

FIG. 54 is a timing diagram of DTS TMSC Drive Only When TCK Low;

FIG. 55 is a timing diagram of DTS TMSC Drive over Multiple Bit Periods;

FIG. 56 is a table of Timing Parameters;

FIG. 57 is a timing diagram of No Drive Overlap when DTS Drives Followed by the TS Driving;

FIG. 58 is a timing diagram of No Drive Overlap when TS Drives Followed by the DTS Driving;

FIG. 59 is a timing diagram of TS Setup Time When DTS Drives;

FIG. 60 is a timing diagram of DTS Setup Time when TS Drives;

FIG. 61 is a timing diagram of Standard to Advanced Mode Change Implications;

FIG. 62 is a timing diagram of Advanced to Standard Mode Change Implications;

FIG. 63 is a block diagram of Multi-Port DTS;

FIG. 64 is a diagram of Power-Down Modes;

FIG. 65 is a diagram of AR Power-Down Model Operation;

FIG. 66 is a table of Power-Down Options;

FIG. 67 is a block diagram of Power Control Interface;

FIG. 68 is a table of Escape Sequences;

FIG. 69 is a timing diagram of End-of-Transfer Escape Sequence Imposed on TS Output;

FIG. 70 is a timing diagram of Hard-Reset Escape Sequence While TCK is High;

FIG. 71 is a table of Registers;

FIG. 72 is a table of Commands and Options;

FIG. 73 is a table of Link Control (LINK_CNTL) Register Format;

FIG. 74 is a table of Scan Control (SCAN_CNTL) Register Format;

FIG. 75 is a table of Transport Control (XPORT_CNTL) Register Format;

FIG. 76 is a table of Link Control Register Field Definitions;

FIG. 77 is a table of Scan Control Register Field Definitions;

FIG. 78 is a table of Transport Control Register Field Definitions;

FIG. 79 is a table of Extended Command Page;

FIG. 80 is a table of Link ID Encoding;

FIG. 81 is a diagram of cJTAG Capabilities;

FIG. 82 is a flowchart of Choosing a Format;

FIG. 83 is a table of Scan Formats Summary;

FIG. 84 is a diagram of JScan Capabilities;

FIG. 85 is a table of JScan Formats;

FIG. 86 is a diagram of Standard 4-pin Scan Topographies;

FIG. 87 is a diagram of MScan Capabilities;

FIG. 88 is a table of MScan Packet RDY Definition;

FIG. 89 is a diagram of Variable Delay Construction;

FIG. 90 is a diagram of a Delay Segment;

FIG. 91 is a diagram of Variable Delay Extension;

FIG. 92 is a diagram of Variable Delay Completion;

FIG. 93 is a diagram of Variable Delay Timeout;

FIG. 94 is a timing diagram of MScan Packet and TS TAP State Association;

FIG. 95 is a diagram of Interrupt Interaction with an MScan Packet Sequence;

FIG. 96 is a diagram of OScan Capabilities;

FIG. 97 is a table of OScan RDY Definition;

FIG. 98 is a table of OScan Transaction Type Characteristics;

FIG. 99 is a table of OScan Packet Optimizations;

FIG. 100 is a table of OScan Packet Payloads;

FIG. 101 is a table of OScan Format Link-to-Tap State Minimum Clock Ratios;

FIG. 102 is a timing diagram of OScan4 through OScan7 Packet Payloads and Transitions;

FIG. 103 is a timing diagram of OScan0 through OScan3 Packet Payloads and Transitions;

FIG. 104 is a timing diagram of OScan1 Shift Length Dependencies;

FIG. 105 is a timing diagram of OScan7 Transaction;

FIG. 106 is a timing diagram of OScan6 Transaction;

FIG. 107 is a timing diagram of OScan5 Transaction;

FIG. 108 is a timing diagram of OScan4 Transaction;

FIG. 109 is a timing diagram of OScan3 Transaction;

FIG. 110 is a timing diagram of OScan2 Transaction;

FIG. 111 is a timing diagram of OScan1 Transaction;

FIG. 112 is a timing diagram of OScan0 Transaction;

FIG. 113 is a timing diagram of OScan Packet and TS TAP State Association;

FIG. 114 is a diagram of Interrupt and an OScan Packet Sequence;

FIG. 115 is a diagram of SScan Capabilities;

FIG. 116 is a diagram of SScan Transactions

FIG. 117 is a table of SScan2 and SScan0 Packet Payloads;

FIG. 118 is a diagram of SScan Packet Template;

FIG. 119 is a diagram of Header Insertion;

FIG. 120 is a table of Header Decode;

FIG. 121 is a table of Transaction Type;

FIG. 122 is a diagram of Input/Output Pacing;

FIG. 123 is a diagram of Buffered Scan Transactions;

FIG. 124 is a diagram of Accelerated Scan Transactions;

FIG. 125 is a table of Supporting Hardware for the Use of Stalls;

FIG. 126 is a table of Transaction Types by Format;

FIG. 127 is a table of SScan3 and SScan1 Packet Payloads;

FIG. 128 is a table of SScan2 and SScan0 Packet Payloads;

FIG. 129 is a timing diagram of End-of-Transfer Escape Sequence Position and Effect;

FIG. 130 is a timing diagram of End Bit Position and Effect;

FIG. 131 is a table of HDR[2] Stall Influence;

FIG. 132 is a timing diagram of SScan3 Transaction Template;

FIG. 133 is a timing diagram of SScan3 Segment Transitions;

FIG. 134 is timing diagram of SScan3 Format with CDX Activation;

FIG. 135 is a timing diagram of SScan3 Transaction, Type 2, with Segment Stall;

FIG. 136 is a timing diagram of SScan3 Transaction, Type 2, All Data Segments;

FIG. 137 is a timing diagram of SScan3 Transaction, Type 3, All Data Segments;

FIG. 138 is a timing diagram of SScan2 Transaction Template;

FIG. 139 is a timing diagram of SScan2 Segment Transitions;

FIG. 140 is a timing diagram of SScan2 Format with CDX Activation;

FIG. 141 is a timing diagram of SScan2 Transaction, Type 0 with Shift Entry from Exit State;

FIG. 142 is a timing diagram of SScan2 Transaction, Type 1 with Shift Entry from Exit State;

FIG. 143 is a timing diagram of SScan2 Transaction, Type 0, All Data Segments, 1 and 2 Bits;

FIG. 144 is a timing diagram of SScan1 Transaction Template;

FIG. 145 is a timing diagram of SScan1 Segment Transitions;

FIG. 146 is a timing diagram of SScan1 Format with CDX Activation;

FIG. 147 is a timing diagram of SScan1 Transaction, Type 2, with Segment Stall;

FIG. 148 is a timing diagram of SScan1 Transaction, Type 2, All Data Segments;

FIG. 149 is a timing diagram of SScan1 Transaction, Type 3, All Data Segments;

FIG. 150 is a timing diagram of SScan0 Transaction Template;

FIG. 151 is a timing diagram of SScan0 Segment Transitions;

FIG. 152 is a timing diagram of v SScan0 Format with CDX Activation;

FIG. 153 is a timing diagram of SScan0 Transaction, Type 0 with Shift Entry from Exit State;

FIG. 154 is a timing diagram of SScan0 Transaction, Type 1 with Shift Entry from Exit State;

FIG. 155 is a timing diagram of SScan0 Transaction, Type 0, All Data Segments, 1 and 2 Bits;

FIG. 156 is a table of SScan Format Minimum Link to TAP State Clock Ratios;

FIG. 157 is a table of Segment Overhead in Clocks for SScan2 and SScan0 Formats;

FIG. 158 is a table of TCK Count per Segment;

FIG. 159 is a diagram of Interrupt and an SScan Packet Sequence;

FIG. 160 is a diagram of BDX Capabilities;

FIG. 161 is a diagram of Header Content;

FIG. 162 is a diagram of Data Content;

FIG. 163 is a diagram of Transfer Characteristics;

FIG. 164 is a timing diagram of Activating BDX with the MScan Format;

FIG. 165 is a timing diagram of Activating BDX with the OScan7 Format;

FIG. 166 is a timing diagram of Activating BDX with the OScan3 Format;

FIG. 167 is a timing diagram of Activating BDX with OScan Formats 2 and 6;

FIG. 168 is a timing diagram of Activating BDX with OScan0, 1, 4, 5 and SScan0 and 2;

FIG. 169 is a timing diagram of Activating BDX with the SScan3 Format;

FIG. 170 is a timing diagram of Activating BDX with the SScan1 Format;

FIG. 171 is a block diagram of BDX Interrupt Interaction with an MScan Packet Sequence;

FIG. 172 is a timing diagram of Deactivating BDX with the OScan7 Format;

FIG. 173 is a timing diagram of Headers;

FIG. 174 is a diagram of BDX Burst Transfer with OScan7;

FIG. 175 is a diagram of BDX Burst Transfer with OScan2 or OScan6;

FIG. 176 is a diagram of BDX Burst Transfer with OScan0, 1, 4, 5, SScan0, 1, or 2;

FIG. 177 is a diagram of BDX Burst Transfer with OScan3;

FIG. 178 is a diagram of BDX Burst Transfer with SScan3;

FIG. 179 is a diagram of BDX Continuous Transfer with OScan3;

FIG. 180 is a diagram of BDX Continuous Transfer with OScan2;

FIG. 181 is a diagram of BDX Continuous Transfer with OScan0, 1, SScan0 or 1;

FIG. 182 is a block diagram of BDX Interface;

FIG. 183 is a diagram of Conceptual Adapter BDX Input Section;

FIG. 184 is a timing diagram of BDX Input Timing;

FIG. 185 is a diagram of Conceptual BDX Output Section;

FIG. 186 is a timing diagram of Adapter BDX Output Timing;

FIG. 187 is a diagram of CDX Capabilities;

FIG. 188 is a diagram of Data Content;

FIG. 189 is a timing diagram of Activating CDX with the OScan7 Format;

FIG. 190 is a timing diagram of Activating CDX with the OScan3 Format;

FIG. 191 is a timing diagram of Activating CDX with the OScan Formats 2 and 6;

FIG. 192 is a timing diagram of Activating CDX with the OScan0, 1, 4, 5 and SScan0 and 2;

FIG. 193 is a timing diagram of Activating CDX with the SScan3 Format;

FIG. 194 is a timing diagram of Activating CDX with the SScan1 Format;

FIG. 195 is a timing diagram of Deactivating CDX with the OScan7 Format;

FIG. 196 is a diagram of Key to Special Treatment of States;

FIG. 197 is a timing diagram of CDX Burst Transfer with OScan7;

FIG. 198 is a timing diagram of CDX Burst Transfer with OScan2 or OScan6;

FIG. 199 is a timing diagram of CDX Burst Transfer with OScan0, 1, 4, 5;

FIG. 200 is a timing diagram of CDX Burst Transfer with OScan3;

FIG. 201 is a timing diagram of CDX Burst Transfer with SScan3;

FIG. 202 is a timing diagram of CDX Burst Transfer with SScan2;

FIG. 203 is a timing diagram of CDX Burst Transfer with SScan1 and SScan0;

FIG. 204 is a timing diagram of Continuous Transfer with OScan3;

FIG. 205 is a timing diagram of Continuous Transfer with OScan2;

FIG. 206 is a timing diagram of Continuous Transfer with OScan0, 1;

FIG. 207 is a timing diagram of CDX Continuous Transfer with SScan1 and SScan0;

FIG. 208 is a block diagram of CDX Interface;

FIG. 209 is a diagram of Conceptual Adapter CDX Input Section;

FIG. 210 is a diagram of Conceptual Adapter CDX Output Section;

FIG. 211 is a timing diagram of Adapter CDX Output Timing;

FIG. 212 is a diagram of Register Writes and Interrupts;

FIG. 213 is a flowchart of Change Packet Operation;

FIG. 214 is a diagram of Change Packet Template;

FIG. 215 is a timing diagram of Minimum Length Change Packet;

FIG. 216 is a table of Switch Packet Initiation;

FIG. 217 is a timing diagram of Adapter Goes Offline in Advanced Mode;

FIG. 218 is a timing diagram of Adapter Goes Offline in Standard to Advanced Mode Change;

FIG. 219 is a timing diagram of Soft Reset and an Online Adapter;

FIG. 220 is a timing diagram of Soft Reset and an Offline Adapter;

FIG. 221 is a timing diagram of MScan Transaction with a Reg. Write Interrupt;

FIG. 222 is a timing diagram of Register-Write Interrupt with OScan7 Transactions;

FIG. 223 is a timing diagram of Register-Write Interrupt with OScan3 Transactions;

FIG. 224 is a timing diagram of Register-Write Interrupt with OScan6 or OScan2 Transaction;

FIG. 225 is a timing diagram of OScan5, OScan4, OScan1, OScan0 Transactions;

FIG. 226 is a timing diagram of Register-Write Interrupt with SScan3, New Segment;

FIG. 227 is a timing diagram of Register-Write Interrupt with SScan3, Mid Segment;

FIG. 228 is a timing diagram of Register-Write Interrupt with SScan2;

FIG. 229 is a timing diagram of Register-Write Interrupt with SScan1, New Segment;

FIG. 230 is a timing diagram of Register-Write Interrupt with SScan1, Mid Segment;

FIG. 231 is a timing diagram of Register-Write Interrupt with SScan0;

FIG. 232 is a timing diagram of TLR Followed By IDLE, No Disconnect, OScan6;

FIG. 233 is a timing diagram of TLR Followed By Disconnect, OScan6;

FIG. 234 is a timing diagram of Immediate Disconnect, OScan6;

FIG. 235 is a diagram of Conceptual Reset Logic;

FIG. 236 is a table of Read Status Format;

FIG. 237 is a table of Port Connectivity;

FIG. 238 is a diagram of Adapter Flexibility;

FIG. 239 is a diagram of View of cJTAG Scan Paths;

FIG. 240 is a diagram of Scan Paths for JScan0, JScan1, and Other JScan Formats;

FIG. 241 is a diagram of Scan Paths for OScan or SScan Formats;

FIG. 242 is a diagram of System Scan Path Examples;

FIG. 243 is a diagram of Series Port Scan Paths;

FIG. 244 is a diagram of Wide-Star Port Scan Path, One Adapter Selected;

FIG. 245 is a diagram of Wide-Star Port Scan Path, More than One Adapter Selected;

FIG. 246 is a diagram of Narrow-Star Port Scan Path, One Adapter Selected;

FIG. 247 is a diagram of Wide-Star Port Scan Path, Other than One Adapter Selected;

FIG. 248 is a timing diagram of Adapter and System TAP State Synchronization;

FIG. 249 is a table of Isolation Pattern;

FIG. 250 is a table of Link ID Assignment Action Summary;

FIG. 251 is a diagram of Star vs. Serial Scan Selection Conceptual View;

FIG. 252 is a timing diagram of Another JScan0 to JScan1 Format Change, Idle After Register-Write;

FIG. 253 is a timing diagram of JScan1 to Another JScan0 Format Change, Idle After Reg. Write;

FIG. 254 is a timing diagram of Another JScan0 to JScan1 Format Change, Delayed Idle State;

FIG. 255 is a timing diagram of JScan1 to Another JScan0 Format Change, Delayed Idle State;

FIG. 256 is a timing diagram of Series Selection Change, Immediate Use;

FIG. 257 is a timing diagram of Series Selection Change, Delayed Use;

FIG. 258 is a table of Pre-Selection and Commands;

FIG. 259 is a table of Pre Scan Status and Commands;

FIG. 260 is a timing diagram of Star Pre-Selection Change, Immediate Use;

FIG. 261 is a timing diagram of Star Pre-Selection, Delayed Use;

FIG. 262 is a timing diagram of Star De-Selection, Immediate Use;

FIG. 263 is a timing diagram of Star De-Selection, Delayed Use;

FIG. 264 is a timing diagram of MTS Command, Update Followed by Idle;

FIG. 265 is a timing diagram of MTS Command, Update Followed by Select_DR;

FIG. 266 is a timing diagram of SCA Command, Update Followed by Idle;

FIG. 267 is a timing diagram of SCA Command, Update Followed by Select_DR;

FIG. 268 is a block diagram of Four Adapters with Two Selected;

FIG. 269 is a block diagram of Four Adapters with One Selected, OScan7 Format;

FIG. 270 is a block diagram of Four Adapters with One Selected, OScan0 Format;

FIG. 271 is a block diagram of Four Adapters with One Selected, Paced Transaction;

FIG. 272 is a block diagram of Four Adapters with One Selected, Non Paced Transaction;

FIG. 273 is a table of DTS/TS Compatibility;

FIG. 274 is a block diagram of Series Port—Mixing Wide and Narrow Interfaces;

FIG. 275 is a block diagram of A Narrow Port—Mixing Wide and Narrow Interfaces;

FIG. 276 is a block diagram of A Hybrid Port with cJTAG Devices;

FIG. 277 is a block diagram of Narrow Port—Single Device;

FIG. 278 is a block diagram of Narrow Port—Multi-device;

FIG. 279 is a block diagram of Multiple Narrow Ports, No Shared Signaling;

FIG. 280 is a block diagram of Multiple Narrow Ports, Separate TCK and Shared TMS;

FIG. 281 is a block diagram of Multiple Narrow Ports, Shared TCK and Separate TMSC;

FIG. 282 is a block diagram of Series and Narrow Ports with a Shared TCK (A);

FIG. 283 is a block diagram of Series and Narrow Ports with a Shared TCK (B);

FIG. 284 is a block diagram of Series and Narrow Ports with Separate TCK (A);

FIG. 285 is a block diagram of Series and Narrow Ports with Separate TCK (B);

FIG. 286 is a block diagram of Series and Narrow Ports with Separate TMSCs; and

FIG. 287 is a table of Robustness and Usability Features.

NOTATION AND NOMENCLATURE

Certain terms are used throughout the following discussion and claims to refer to particular system components. This document does not intend to distinguish between components that differ in name but not function. In the following discussion and in the claims, the terms “including” and “comprising” are used in an open-ended fashion, and thus should be interpreted to mean “including but not limited to . . . .” Also, the term “couple” or “couples” is intended to mean either an indirect or direct electrical connection. Thus, if a first device couples to a second device, that connection may be through a direct electrical connection, or through an indirect electrical connection via other devices and connections. Additionally, the term “system” refers to a collection of two or more parts and may be used to refer to a computer system or a portion of a computer system. Further, the term “software” includes any executable code capable of running on a processor, regardless of the media used to store the software. Thus, code stored in non-volatile memory, and sometimes referred to as “embedded firmware,” is included within the definition of software.

DETAILED DESCRIPTION

The following discussion is directed to various embodiments of the invention. Although one or more of these embodiments may be preferred, the embodiments disclosed should not be interpreted, or otherwise used, as limiting the scope of the disclosure, including the claims, unless otherwise specified. The discussion of any embodiment is meant only to be illustrative of that embodiment, and not intended to intimate that the scope of the disclosure, including the claims, is limited to that embodiment. “Compact JTAG (cJTAG)”, revision 0.9, dated Nov. 20, 2005 is incorporated herein by reference. Similarly, “Compact JTAG (cJTAG)”, revision 0.9, which provides a detailed specification for the compact JTAG (“cJTAG”) architecture, is also meant to describe an illustrative embodiment and is not intended to limit the present disclosure to the cJTAG architecture described.

The IEEE 1149.1 standard (also known as the JTAG architecture) was originally developed for board-level interconnect testing (sometimes referred to as “boundary testing”). Standard JTAG implementations do not permit debug and testing of the individual JTAG compatible components that are mounted on a printed circuit board. Such component test and debug can be accomplished, however, through extensions and variations of the JTAG architecture, in accordance with at least some preferred embodiments, while still keeping the debug and test system (“DTS”) that controls the test sequence, as well as the target system (“TS”) comprising the components that are being tested, compatible with the underlying JTAG architecture and communication protocol.

FIG. 1 illustrates a system 1000 constructed in accordance with at least some preferred embodiments, comprising a debug test system (“DTS”) 1100 and a target system (“TS”) 1200, coupled to each other by link 1300. The debug test system 1100 may comprise a DTS cJTAG adapter 1110, a DTS IEEE 1149.1 bus (“DTS bus”) 1120, and non-IEEE data and control signals 1140. The term “cJTAG” refers to “compact JTAG,” which is an extension of the JTAG standard that uses fewer communications signals, as will be described below. The DTS cJTAG adapter 1110 provides the logic necessary to convert the standard JTAG signals present on DTS bus 1120 into the signals and message formats defined for cJTAG operation. The DTS bus 1120 couples to a DTS test access port (“TAP”) controller 1130, which provides the standard JTAG functionality of the debug test system 1100. The non-IEEE data and control signals 1140 couple to other logic 1141 within the debug test system that provides extended functionality beyond that provided by the DTS TAP controller.

Similarly, the target system (“TS”) 1200 may comprise a TS cJTAG adapter 1210, a TS IEEE 1149.1 bus (“TS bus”) 1220, and non-IEEE data and control signals 1240. The TS cJTAG adapter provides the logic necessary to convert the standard JTAG signals present on TS bus 1220 into the signals and message formats defined for cJTAG operation. The TS bus 1220 couples to a TS test access port (“TAP”) 1230, which provides the standard JTAG functionality of the target system 1200. The non-IEEE data and control signals 1240 couple to other logic 1241 within the target system that provides extended functionality beyond that provided by the TS TAP.

Debug test system 1100 is capable of sending test and debug sequences via link 1300 to target system 1200. These sequences allow debug test system 1100 to configure target system 1200 for a test, execute the test, and read back the results of the test. The debug test system 1100 may be configured to couple to the target system 1120 using a four or five wire implementation of link 1300 as defined under the JTAG architecture. The link 1300 includes signals TCK (clock), TMSC (mode select), TDI (data in), TDO (data out), and optionally RTCK (return clock). As shown, at least the TCK, TMSC, TDI and TDO signals can be used when the debug test system 1100 communicates with the target system 1210 according to the JTAG protocol. In this mode of operation, the signals from the DTS IEEE 1149.1 bus 1120 and the TS IEEE 1149.1 bus (“TS bus”) 1220 are passed by DTS cJTAG adapter 1110 and TS cJTAG adapter 1210 without modification across link 1300.

The system 1000 also incorporates a variation of the JTAG architecture that provides an alternative physical interface that is designed to reduce the pin count of the interface between the debug test system 1100 and the target system 1200. This alternative configuration of the link 1300 allows the debug test system 1110 to communicate with the target system 1210 using only the TCK and TMSC signals of link 1300. In this mode of operation the TDI and TDO data are serialized together with the TMSC data and sent across the TMSC signal of link 1300 as a multi-bit serial message packet. Each packet may be either a control packet that is used to configure a component within the system 1000, or a data packet used to transfer data from one component to another. Although the TMSC signal is used for transferring the serial packet data in the preferred embodiment of FIG. 1, other signals (e.g., TDI and TDO) may be used and the present disclosure is intended to encompass all such embodiments.

FIG. 2A illustrates the two basic interconnect configurations for both JTAG and cJTAG systems. In the Star configuration, each target system may be accessed directly by the debug test system, while in the Series configuration the debug test system can only send data to, or receive data from, a target system through any and all intervening target systems. FIG. 2B illustrates how each of the two physical interfaces described above may used to couple a debug test system to one or more target systems. The Series configuration is allowed under both the JTAG architecture and permits mixing JTAG and cJTAG target systems. The Narrow Star and Wide Star configurations are only valid within the cJTAG architecture. The Narrow Star configuration includes the use, in at least one preferred embodiment, of only the TCK and TMSC signals. Both signals are shared by all of the target systems. cJTAG target systems that have a wide physical interface, and which are coupled to each other in either a Series or Wide Star configuration, may optionally operate as if configured to operate in a Narrow Star mode, as shown in FIG. 2C.

It should be noted that throughout this disclosure a distinction is made between the TMS bit that is defined in the IEEE standard and the TMSC signal of the link 1300. When operating the system according to the standard JTAG protocol, the TMS bit is the only bit transmitted using the TMSC signal. But when the system is operating according to the cJTAG protocol, the TMS bit is just one of several bits that may be transferred across the link 1300 using the TMSC signal. Thus, to differentiate between the two, the bit is referred to as the TMS bit, while the signal of the link is referred to as the TMSC signal.

Referring again to FIG. 1, both DTS cJTAG adapter 1110 and TS cJTAG adapter 1210 appear to continue to operate according to the standard four or five wire JTAG protocol when viewed from either the DTS bus 1120 or the TS bus 1220. The cJTAG adapters 1110 and 1210, together with link 1300, thus provide an abstraction layer or bridge that hides the underlying 2-wire cJTAG physical interface. This bridge can operate according to the JTAG protocol. (“IEEE mode”), or can alternatively operate according to the cJTAG protocol (“advanced mode”) in a manner that is transparent to DTS bus 1120, TS bus 1220 and other portions of the debug test system and target systems that operate exclusively in IEEE mode. When operating in advanced mode, data and control information may be exchanged with the DTS cJTAG adapter 1110 via either DTS bus 1120 or non-IEEE data and control signals 1140. Likewise, data and control information may be exchanged with TS cJTAG adapter 1210 via either TS bus 1220 or non-IEEE data and control signals 1240 when operating in advanced mode.

The ability to select between multiple modes of operation is illustrated by the preferred embodiment of FIG. 1A, which shows a more detailed view of debug and test system 1100. DTS IEEE bus 1120 couples to both select multiplexer/demultiplexer (Select Mux/Demux) 1104 and serializer 1102. When the debug and test system 1100 is configured to operate in IEEE mode, select multiplexer/demultiplexer 1104 selects IEEE bus 1120, and the signals from IEEE bus 1120 drive the corresponding signals on the link 1300. The selection is controlled by the state of format select register 1108, which couples to the selection control input of multiplexer/demultiplexer 1104. If the debug and test system 1100 is configured to operate in a mode other than IEEE mode (e.g., advanced mode), then the output of serializer 1102, which couples to select multiplexer/demultiplexer 1104 via data and clock signal bus 1106, is selected via a corresponding state of format select register 1108, and the TMS and TCK signals from IEEE bus 1120 drive the TMSC and TCK signals, respectively, of the link 1300.

The TDI and TDO signals of the link 1300 may also be driven by signals originating from a source other than the IEEE bus 1120 or serializer 1102. Serializer 1102 may serially encode the signals from IEEE bus 1120 (e.g., TDI, TDO and TMS), as well other IEEE bus signals and non-IEEE signals, depending upon the configuration of serializer 1102. Further, these same signals may also be routed unserialized through the serialized 1102 and the select multiplexer/demultiplexer 1104 to either the TDI or TDO signals (or both) of the link 1300. Other modes beyond IEEE and advanced mode, as well as other combinations of serialized and non-serialized signals, may become apparent to those skilled in the art, and all such modes and combinations of signals are intended to be within the scope of the present disclosure.

Throughout the present disclosure, the preferred embodiments described include one or more protocols (e.g., cJTAG) in addition to the JTAG protocol, wherein the JTAG protocol is the default protocol at power-on/reset (POR). However, other embodiments are possible in which a protocol other than the JTAG protocol operates by default after a power-on/reset, and in yet other embodiments the protocol that operates by default after a power-on/reset may be programmable. All such embodiments are intended to be within the scope of the present disclosure. Further, although one protocol is designated the default protocol, each protocol operates independent of the other protocol. When one protocol is operating, all of the other protocols are in an inactive state. Each of the other protocols are maintained in an inactive state by designing each protocol such that operations by one protocol are seen as no-operations (No-Ops) or “inert” operations by the other protocols. In the preferred embodiments described in the present application, this is accomplished by designing all of the protocols around the JTAG TAP state machine (shown in FIG. 4), and selecting states, groups of states, state transitions, and/or state sequences that define operations within one protocol, but that are seen as inert operations by the other protocols.

As already noted, each protocol of the preferred embodiments described operates independent of the other, functioning in a peer-level configuration rather than a parent-child configuration. Each protocol transmits and receives messages through the physical interface coupling the debug and test systems 1100 of FIG. 1 to one or more target systems, such as target system 1200. Messages are exchanged under one protocol without intervention by the other protocols (e.g., without encapsulation of one protocol by another). The physical interface is thus time-shared by the protocols, with each protocol being separately selected for operation by the debug and test system 1100 as needed. Protocol selection is performed without giving any single protocol or group of protocols preferential access to the physical interface (i.e., link 1300).

Transitions between protocols may be triggered either by a power-on/reset, or by a software controlled selection sequence that is recognized by all protocols. Further, transitions by the system 1000 from one protocol to another are done without requiring that the system 1000 first return or transition through a reference or top-level protocol (a prioritized configuration), without requiring that the system 1000 return to a protocol previously selected after completing operations under a currently selected protocol (a nested configuration), and without an intervening hardware or software generated reset. It should be noted that although prioritized protocol configurations, nested protocol configurations, and resets are not required for operation of the preferred embodiments disclosed, embodiments that incorporate such protocol configurations and resets are not precluded, and are thus also within the scope of the present disclosure.

As will be described below, a number of different message formats are possible within each protocol. These message formats are defined by the bits that are included within the message, and the TAP state machine states (FIG. 4) used to transmit and/or receive a message so formatted. It is noted that the present disclosure, while describing certain specific formats, is not intended to be limited to such formats. Also, selection of a format in at least some of the preferred embodiments may be performed dynamically without the need to reset the test and debug system 1100, the target system 1200, or the link 1300. Message formats may also be selected based on the characteristics of a specific target system, and may be changed dynamically as different target systems are each selected.

FIG. 3 provides an alternative illustration of the system 1000 that includes DTS IEEE 1149.1 TAP controller (“DTS TAP controller”) 1130 and TS IEEE 1149.1 TAP (“TS TAP”) 1230. DTS TAP controller 1130 couples to DTS cJTAG adapter 1110 via DTS bus 1120, and TS TAP 1230 couples to TS cJTAG adapter 1210 via TS bus 1220. The system 1000 of FIG. 3 can select between IEEE mode and advanced mode in one of at least two ways. First, the operational mode of the system 1000 can be selected when the system is first powered up. Upon initial power-up, the system 1000 asserts a power-on-reset signal that sets all components within the system to a known default state. The cJTAG adapters 1110 and 1210 both initially default to IEEE mode. In the preferred embodiment of FIG. 1, the TMS bit is held at a zero state while the TDO bit is sequenced through a pattern that causes the cJTAG adapters, which monitor the TDO bit, to transition into advanced mode. In at least some of the preferred embodiments, this is the same pattern that would cause a transition into advanced mode if presented on the TMS bit during normal operation of the system 1000.

FIG. 4 shows the state transition diagram implemented by the state machine of TS TAP 1230 in accordance with IEEE standard number 1149.1. Sixteen states are shown and transitions from one state to another are effectuated by transitions of the TMS bit. When the TAP 1230 first reaches the Test-Logic-Reset state, the instruction register is loaded with either an IDCODE or BYPASS opcode. As can be seen in FIG. 4, holding the TMS bit to a binary zero causes the TS TAP 1230 to transition from the Test-Logic-Reset state to the Run-Test/Idle state, where it stays as long as the TMS bit is held to a logical zero. To transition the system 1000 to the advanced mode of operation upon a power-on reset, the TDO bit is sequenced through a predetermined sequence of bit patterns while the TMS bit continues to be held at a zero state. When the TS cJTAG adapter 1210 detects this sequence, the TS cJTAG adapter 1210 begins operating in the advanced mode. This pattern for the TDO bit will cause the state machine of the TS TAP 1230 to transition through the states of the state machine without passing through either the shift_DR or shift_IR states. By avoiding these states, data is not moved in or out of any of the standard JTAG data or instruction registers, which freezes the JTAG configuration of the target system 1200. Thus, activating advance mode operation of the TS cJTAG adapter 1210 has no effect on the TS TAP 1230.

The second way in which the system 1000 of FIG. 3 can select between IEEE mode and advanced mode is through the use of “inert” JTAG data scan sequences after the system is past power-on reset and is operational. Inert data scans are JTAG data scan sequences that do not do anything useful and thus are not normally used. Normally a JTAG data scan sequence includes a fixed series of operations designed to accomplish a useful function, such as reading or loading a JTAG data register within the target system 1200. FIG. 5 illustrates at least some of the data registers within the target system 1200 that are accessible by the TS TAP 1230, in accordance with at least some preferred embodiments. These include the ID register 5010, the bypass register 5020, and a collection of input cell, output cell and enable cell registers 5110 through 5150. To load a register, for example, the register type (data or instruction) is first selected, and the current contents of the destination register (e.g., the bypass register) are then moved to the output shift register of register output multiplexer 5050 though a capture operation. Next, a series of shift operations are performed wherein new data is shifted into the input shift register of register input demultiplexer 5040 from the TDI input 5210 and old data is simultaneously shifted out the TDO output 5220. Finally, an update operation is performed to transfer the new data from the input shift register of register input demultiplexer 5040 to the actual register to which the data is destined.

FIGS. 6A and 6B illustrate how inert JTAG data scan sequences may be used to transition through the TAP state transition diagram without actually loading a value. As can be seen, all of the operations that would normally take place in, for example, a JTAG data scan sequence to load a register take place, except for the sequence of shift operations. In FIG. 6A, the sequence of states (shown shaded) includes the Capture_DR state, the Exit1_DR state, and the Update_DR state. Similarly, in FIG. 6B the sequence of states include the Capture_DR state, the Exit1_DR state, the Pause_DR state, the Exit2_DR state, and the Update_DR state.

In each of the sequences of FIGS. 6A and 6B, the capture operation causes the current value of the destination register to be transferred to the output shift register of register output multiplexer 5050, and the update operation causes the value in the input shift register of register input demultiplexer 5040 to be loaded into the destination register. But without intervening shifts, all of the registers can end up containing the same value in at least some situations, which is the value that was already in the input shift register of register input demultiplexer 5040 and the destination register. As a result, no data is transferred in or out of the target system 1200, and the contents of the destination register remain unaltered in at least some cases. Because no data bits are shifted in or out of the target system 1200, the inert JTAG data scan sequences are referred to as “zero-bit” scans (“ZBS”). When a zero-bit scan is preceded by some action that loads a BYPASS instruction or a read-only instruction (e.g., the IDCODE instruction), the operation performed has no consequences since the register bit changed is either the bypass bit or a bit that is not writeable (e.g., the read-only identification bits). FIG. 6C summarizes the relevant TAP states that together each define an example of a zero-bit scan. Although two examples are shown, many others are possible and all such sequences of states that define a zero-bit scan are intended to be within the scope of this disclosure. Because zero-bit scans do not corrupt the contents of JTAG registers other than that specified by the inert instruction (e.g., bypass), these scans, either independently or in conjunction with other scan activity following the zero-bit scan, can be used to change the behavior of the DTS and TS cJTAG adapters without other consequences.

Because a zero-bit scan is essentially a no operation (no-op) to the DTS TAP controller 1130 and the TS TAP 1230, any number of zero-bit scans may be executed one after the other. The ability to send any number of consecutive zero-bit scans allows multiple tiers of capabilities or “control levels” to be defined. Each control level corresponds to the number of consecutive zero-bit scans, and each control level enables a different set of capabilities. A control level is thus synonymous with a command window, wherein opening a command window represents entry into a new control level. FIG. 7 illustrates an example of a command window in which two, zero-bit scan sequences open the command window. The two zero-bit scans that are used to open the window are also used to designate the control level as control level 2. FIG. 8A shows an example, in accordance with at least some preferred embodiments, of different capabilities being allocated to each control level. The example shows that control levels 1-5 are allocated to the cJTAG protocol (with control levels 4 and 5 being reserved). Control level 0 represents IEEE mode (JTAG protocol), and control levels 6 and above are user defined levels available for extended capabilities beyond those defined for the cJTAG protocol of the preferred embodiments described herein. Other extended capabilities and control levels, defined through the use of zero-bit scans as a control event, will become apparent to those skilled in the art, and the present disclosure is intended to encompass all such capabilities and control levels.

Referring again to FIG. 4, in at least some preferred embodiments a control level is established when a Shift_DR TAP state is entered by the TAP state machine following one or more zero-bit scans, but without an intervening Select_IR or test logic reset (TLR) state. Such scans (referred to as DR-Scans) may each be associated with a specific control level thus established. The zero-bit scans define control levels above level 0 and do not require the use of the TDI and TDO signals, since data is not transferred using these signals during a zero-bit scan. Such operation thus allows the use of configurations such as the two-wire narrow star configuration previously described. Other mechanisms not requiring the TDI and TDO signals, and other TAP states (e.g., the Pause_DR state) may be used to implement at least some of the preferred embodiments, and all such mechanisms and states are intended to be within the scope of the present disclosure.

In control levels above level 0 (i.e., within a command window), the number of TAP states (i.e., the number of clock cycles that advance the TAP state machine) spent in the Shift_DR state are counted (though as already noted, states other than the Shift_DR state could also be used for this purpose). The count is saved as data in a temporary register if the count is greater than 16. A count of less than 16 is interpreted as a command and is combined with the previously saved count to specify the particular command desired. One such command, for example, may be to change to a protocol other than the protocol being used to communicate over the TMSC signal. FIG. 8B illustrates an example of counts used to define advanced mode commands in this manner. Although the example shown in FIG. 8B uses a 5-bit data width, any number of bits may be encoded in this manner and the present disclosure is intended to encompass all bit widths. Further, data may be specified using techniques other than counts (e.g., by the order of the transitions through states within the TAP state machine), or in combination with counts, and all such techniques and combinations of techniques are also intended to be within the scope of the present disclosure.

In at least some preferred embodiments, control levels above 0 may be used to set a state that remains defined outside of the command window through the use of an extended command register (not shown) within both the debug and test system and the target system of FIG. 1. Bits within this register can be set or cleared using the zero-bit scan count as described above, or using a combination of zero-bit scans and other TAP state activity following the zero-bit scans. In this manner, the register bit settings are retained after the command window has closed, allowing the system to operate according to a protocol defined for a particular control level outside of the command window, or to define any other function controllable by the bits that survive the closing of a command window. The effects of such bits may begin when the bits initially change state within the command window, or after the command window is closed. Similar zero-bit scan sequences may subsequently be used to clear the register bits to exit the selected control level. Other variations to the use of zero-bit scan sequences, counts, and TAP state sequence as a means to define values that survive the closing of a command window may become apparent to those skilled in the art, and all such variations are intended to be within the scope of the present disclosure.

In at least some preferred embodiments, a command window is closed when an instruction register select operation is performed, or when the test logic reset TAP state is entered. Other TAP state sequences may be defined that cause a command window to close, and all such sequences are intended to be within the scope of the present application. Once a command window is closed, the actions enabled by the open command window cease to be available.

The command windows of the preferred embodiments provide the capability of altering the behavior of the link 1300 of FIG. 3. Switching to advanced mode is an example of such a use of a command window. Once in the advanced mode of operation, the debug test controller 1100 of FIG. 3 no longer bypasses the DTS cJTAG adapter 1110, instead communicating through the DTS cJTAG adapter 1110 with the DTS TAP controller 1130. Similarly, cJTAG sequences received by the target system 1200 are passed through the TS cJTAG adapter 1210, which would be bypassed if the target system 1200 were operating in IEEE mode. Operation of the DTS and TS cJTAG adapters 1110 and 1210 in advanced mode continues until an event that terminates the current sequence of operations and transitions the DTS and TS cJTAG adapters 1110 and 1210 back to IEEE mode. In the preferred embodiment of FIG. 3, termination of advanced mode is accomplished by a zero-bit scan sequence that opens a command window, within which bits are set that indicate that IEEE mode operation is desired.

Command windows are thus managed using clear entry and exit sequences. A cJTAG command window is defined that starts with, for example, one or more zero-bit scans, followed by cJTAG sequences (data register scans are used in the preferred embodiment of FIG. 3), and ending, for example, with an instruction register scan. The structure of such a scan cJTAG sequence and the resulting command window are illustrated in FIG. 7. Such sequences may be used within the preferred embodiments described in the present disclosure to manage a variety of functions, including those that enable and disable advanced mode.

It should be noted that although command windows are used to transition between modes of operation, these modes do not depend upon whether a command window is open or closed, and whether the command window remains open or closed does not depend upon the mode of operation of the system. Command windows may be opened or closed at any time through appropriately executed state sequences, and are thus dependent upon the state of the TAP state machine, not the mode of operation of the system. Likewise, the mode of operation depends upon the setting of the format select register (FIG. 1A), and does not depend upon the state of the TAP state machine.

Command windows as described above may be used to access and modify a variety of control registers within both the debug and test system and the target system. Some of the registers may perform functions common to both systems, and indeed may be set to common values. In at least some of the preferred embodiments, a single write to a common or “shared” control register within the debug and test system will automatically result in the same value being written to the corresponding register of a target system adapter. In some preferred embodiments, a single write to the register within the target system will result in a write of the same value to the corresponding register in only those target systems that are selected to respond to the write.

As already noted, the preferred embodiment of FIG. 3 is capable of multiple modes of operation. Each mode defines what protocol is used to communicate across the link 1300, and the overall behavior of the interface at the message packet level. FIG. 9 illustrates a simplified scan state diagram 2000 that shows the modes of operation of the state machine implemented within the DTS and TS cJTAG adapters 1110 and 1210 of the system 1000 (FIG. 3), in accordance with at least some preferred embodiments. Two modes are defined: standard (IEEE) mode 2100 and advanced mode 2200. The system starts up with the state machines of the cJTAG adapters in the power down (“PD”) state 2110 and after powering up in IEEE mode is capable of performing standard (IEEE) JTAG operations within standard scan (“SS”) state 2120. The cJTAG adapters change modes by transitioning to the configuration change (“CC”) state 2210 whenever the format select register (FIG. 1A) is updated while in standard mode 2100 and a non-IEEE mode is selected. After entering the advanced mode 2200, basic cJTAG operations may be performed within advanced scan (“AS”) state 2220.

Once in advanced mode 2200, any write to a register will trigger a transition to configuration change state 2210. If the write is to the format select register and results in a selection of IEEE mode, a transition back to the standard scan state takes place. Otherwise a transition back to advance scan state 2120 takes place. Other extended operations may be added to the basic cJTAG operations, and two such extended operational states are shown (background data transfer or “BDX” state 2230, and custom data transfer or “CDX” state 2240). The cJTAG adapters may be powered down after the state machines transition through the configuration state 2210 and the standard scan state 2120 and back to the power down state 2110. Further, additional modes beyond the standard and advanced modes of the preferred embodiment described may be defined, with transitions to and from these additional modes through change state 2210 implemented as described, and embodiments incorporating such additional modes are intended to be within the scope of this disclosure.

The configuration change state 2210 of FIG. 9 provides the hardware with extra time for the change in configuration necessary to support a new mode of operation to propagate and take effect. The configuration change state 2210 also provides a single, known transition point between the various modes. Although represented in FIG. 9 as single states, the states shown in FIG. 9 each represents specific transitions through multiple states of the TAP state diagram of FIG. 4. The states of FIG. 9 thus represent the overall system state, while the states of FIG. 4 represent the state of an individual TAP state machine.

The configuration change state 2210, however, is distinct from the other states of FIG. 9 in that the TAP state machine state sequences used to define configuration change state 2210 are the same regardless of the mode of operation of the system (e.g., standard mode and advanced mode). All other state transitions sequences are interpreted to indicate particular system states other than the configuration change state 2210 based not only upon the sequence through the state diagram of FIG. 4 (and thus of the TAP state machine), but based also on the mode of operation selected. Thus, a data scan that takes place in advanced mode (defined by specific state transitions of the TAP state machine as shown in FIG. 4) will result in transitions through one particular set of states within FIG. 9, but that same data scan (defined by the same specific state transitions of the TAP state machine) will result in transitions through a different set of state within FIG. 9.

FIGS. 10A and 10B illustrate a more detailed cJTAG adapter scan state diagram 3000, in accordance with at least some preferred embodiments. Referring to FIG. 10A, the state machines of the TS cJTAG adapter 1220, for example, starts up in the power down (“PD”) state 3110, transitioning to the standard mode idle (“IEEE”) state 3120 after completing a power-on reset. When the TS cJTAG adapter 1220 receives a packet 3121 while in standard mode, the packet 3131 (i.e., information exchanged during one TAP state while in IEEE state) is forwarded to the TS TAP 1230 without modification by the TS cJTAG adapter 1220, and the state machine remains in IEEE state 3120. The zero-bit scans that open a command window are performed while in IEEE state 3120. Scan operations within the command window are also performed while in IEEE state 3120. If an operation specifies a change from IEEE mode to advanced mode, the interface operation must change. The packet initiating a change in interface operation from IEEE mode to advanced mode causes a transition from IEEE state 3120 to DISP state 3130, transitioning through change update (“CUPD”) state 3150, wait state 3140 and dispatch state 3130, and into the advanced mode idle (“IN0”) state 3160, where advance mode processing begins. This transition does not close the command window, instead only changing the operating mode. The command window is closed by TAP state activity that results from the processing of advanced mode packets.

While in advanced mode, the packet content that is expected is determined by operations performed within the command window. When a cJTAG adapter receives an advanced mode packet 3161, the state machine may transition to one of a variety of states depending on the type of packet expected, and on the TAP state associated with the expected packet. The state machine transitions through at least some of states 3170-3230 in a manner that depends on the advanced scan format specified in combination, in some cases, with the TAP state. In at least some of the preferred embodiments, the same packet format is used for all TAP states, while in at least some other preferred embodiments the packet content changes based upon the TAP state (e.g., less information is required to describe non-shift state activity, as compared to shift state activity). These scan types and their relationships to the state diagram are described in more detail below. If the packet is either a compressed export (CXPORT) packet 3162 or an uncompressed export (UXPORT) packet 3163, the state machine transitions through at least some of states 3240-3310 (FIG. 10B). These data export operations and their relationships to the state diagram are described in more detail below. If the packet is a change packet 3151 (e.g., the end of a command window indicating a change from advanced mode back to IEEE mode), the change packet is processed, transitioning again through change update state 3150, wait state 3140 and dispatch state 3130, and back to the IEEE mode idle state 3120.

As already noted, the 2-wire physical interface provided under the cJTAG architecture requires that the data transferred across 4 or more wires be sent across the interface in the form of a serialized message packet. Data that would be sent across these wires under the JTAG architecture is instead sent as individual data bits within a cJTAG message packet. An example of such a serialized message packet is shown in FIG. 11. The packet shown includes bits representing the TDI, TDO and TMS signals of the JTAG interface, as well as additional bits used to implement additional features such as interlocked communications and delays. Not all operations require all of the bits shown in FIG. 11. To avoid sending bits that are not needed for a particular operation, at least some of the preferred embodiments define a plurality of scan types, each with different packet contents depending on what bits are to be used. By varying the bits included in the packet, different levels of optimization are possible.

FIGS. 12A and 12B illustrate several examples of optimized scans (“OScans”), in accordance with at least some preferred embodiments. Each of the OScans shown provides different combinations of bits, and thus different levels of optimization. For each Oscan, the chart indicates whether the clock is sourced by the debug test system or the target system, which bits are eliminated when not needed, and what the resulting control and data packets look like as a result of the optimization. The decision of when to omit a bit and utilize a particular OScan is based upon the JTAG standard, which specifies which bits are needed for particular operations defined by the TAG state diagram (FIG. 4). Thus, the states through which the TAP state machine transitions for a given OScan type will depend upon the data content defined for that OScan type.

OScan7 preferably provides no optimization and includes bits representing all of the signals of the JTAG architecture, plus a “ready” bit and one or more optional delay bits. This accounts for JTAG implementations that may not have followed the JTAG architecture as defined within the IEEE standard by, for example, transferring data on TDO or TDI during operations when the standard specifies that these signals are not used. Thus, OScan7 is provided for compatibility purposes, and not to result in any actual optimization.

Each of the remaining OScans results in a reduction in the number of bits transferred. In each case a given bit can be omitted because it is not needed for a given type of transaction. If, for example, data only needs to be transferred from a target system to the debug test system, there is no need to include the TDI bit which is used to transfer data from the debug test system to the target system. Similarly, the TDO bit is not needed for transfers from the debug test system to a target system. Ready bits (described below) are not needed if the target system is fast enough to keep up with the debug test system at the full TCK clock rate. TMS is not needed for long data transfers where an end of transfer escape sequence can be used (described below).

Referring again to FIGS. 12A and 12B, Oscan6 omits the TDI and ready bits from control packets and the ready bit from data packets. OScan5 omits all but the TMS bit from control packets and the ready bit from data packets. OScan4 omits all but the TMS bit from control packets and omits the TDO and ready bits from data packets. OScan3 omits the TDI bit from control packets and the TMS bit from data packets. OScan2 omits the TDI and ready bits from control packets and the TMS and ready bits from data packets. Oscan1 omits all but the TMS bit from control packets and omits the TMS and ready bits from the data packets. OScan0 omits all but the TMS bit from control packets and all but the TDI bit from data packets. The delay bits are optional for all of these packets. Although some of the formats described may be capable of one bit per data packet, two bits per data packet is a preferred configuration, as it permits maintaining a 2-to-1 ratio between cJTAG link clock and the JTAG clock on the IEEE busses (see FIG. 1). This permits the link to continue to operate at relatively high clock rates even when the debug test system, the target system, or both are slower, legacy systems.

The OScans of the preferred embodiments also provide additional capabilities beyond the base JTAG architecture through the use of a ready bit. Because the data transferred between the debug test system and the target system in the cJTAG architecture is a serialized version of the signals defined in the JTAG architecture, it may be desirable to clock the serialized data at a higher clock rate to offset the effect of the serialization. But some target systems may not be fast enough to keep up with the higher clocking rates of the cJTAG architecture or may have limitations because of other factors, even when the interface is operated in a modified IEEE mode with a return TCK (RTCK) added to the four-wire IEEE interface. The ready bit provides a means for the target system to hold off the debug and test system and keeping it from sampling the TDO bit until the target system is ready and the TDO bit from the target system is valid. As shown in FIG. 13, if the ready bit is set, the next bit sent is the TDO bit from the target system. FIG. 14 illustrates the case where the target still stalls the debug test system. The ready bit indicates the packet may proceed, and the next bit sent is a repeat of the ready bit rather than the TDO bit. The ready bit continues to be repeatedly sent until the ready bit is cleared, at which point the TDO bit is sent from the target system to the debug test system.

In at least some preferred embodiments, the ready bit may be implemented in at least two different configurations. In the first configuration, two or more target systems may assert the ready bit. In this configuration, the TMSC signal is pre-charged by the debug and test system during the bit cycle preceding the bit cycle assigned to the ready bit. If any one of the target systems is not ready to output its TDO, that target system pulls the TMSC signal low during the ready bit time period, indicating that a stall is needed (ready not asserted). This operation of the ready bit is shown in the scan state transition diagram of the preferred embodiment of FIG. 10A. When a scan packet that includes a ready bit is received in advanced mode the state machine of a cJTAG adapter receiving the packet transitions from advanced mode idle state (“IN0”) 3160, where it process the first packet bit, to the first MScan pre-charge state (PC0) 3210. The state machine then transitions to MScan ready state (RDY1) 3220, and subsequently to the second MScan pre-charge state (PC1) 3230. If the TMSC signal has been pulled low during the ready bit time period (ready not asserted), the debug and test system again pre-charges the TMSC signal and the state machine returns to MScan ready state 3220. This process repeats until the ready bit is asserted by a target system (not pulled low), causing the state machine to transition to the TDO processing state 3190, where the TDO bit is sampled and received by the debug and test system.

In the second configuration, only a single selected device is involved in the data exchange, precluding the need for a pre-charge/discharge configuration. Instead, the targets system simply drives the ready bit to the desired state. Referring again to the preferred embodiment of FIG. 10A, when a scan packet 3161 that includes a ready bit is received in advanced mode the state machine of a cJTAG adapter receiving the packet can transition from advanced mode idle state (“IN0”) 3160, where it process the first packet bit, to either input/output processing state (“IN1”) 3170, where it would process the second packet bit if included, or to OScan ready state (“RDY0”) 3180. If there is no second packet bit prior to the ready bit, the state machine can transition directly from the advanced mode idle state 3160 to the OScan ready state 3180. If the ready bit is not set, the state machine-will hold in the OScan ready state 3180. Once the ready bit is set, the state machine then transitions to the TDO processing state (“TDO”) 3190, where the TDO bit is sampled and received by the debug and test system. It should be noted that because each target system of the preferred embodiments controls its own ready bit, the duration of the stall for each target system is determined by that target system, and thus each target system may stall the debug and test system for a duration of time specific to that target system (or no stall at all) without regard to the stall requirements of any other target system coupled to the debug and test system.

The OScans of the preferred embodiments may also provide for additional transmission delays through the use of delays between packets. Either a fixed or variable number of delay cycles may be introduced between the end of one packet and the beginning of another packet. FIG. 15A illustrates the transmission of a fixed delay. In the example shown, a fixed delay of two clock cycles (TCK cycles) is introduced between two scan packets. In at least some of the preferred embodiments, the duration of the clock cycles is determined by programming two bits within a cJTAG delay control register within the cJTAG adapter of the debug test system. A delay of 0, 1, and 2 clock cycles may be selected by setting the delay control bits, for example, to the binary values 00, 01, and 10 respectively, as shown in the table of FIG. 15B. Each value corresponds to the addition of 0, 1, or 2 clock cycles of delay. Thus, in the example show in FIG. 15A, the delay control register was set to a binary value of 10 (decimal 2), resulting in the two additional delay periods shown.

FIG. 16A illustrates how delays between packets that are of variable length may also be provided. In at least some of the preferred embodiments, loading a binary value of 11 into the a cJTAG register control registers enables variable delays and configures the delays between packets to be controlled by the state of the TMS bit. The sequence of events is shown in FIG. 16B, which is a simplified partial state transition diagram derived from the scan state transition diagram of FIG. 10. After the initial delay state (“DLY”) 3200 is reached, the state machine of the cJTAG adapter transitions to wait state (“WAIT”) 3140. As long as the TMS bit is set, the state machine will remain in wait state 3140. When the TMS bit is cleared, the state machine will transition to the dispatch state 3130 and the cJTAG adapter will then resume processing advanced mode scan packets if the TMS bit remains cleared.

In the preferred embodiments illustrated in FIGS. 15A and 16A, the data driven on the TMSC signal is the data last driven during the previous scan cycle. During the delay (fixed or variable) this data is treated as “don't care” data. In at least some preferred embodiments this data may instead be affirmatively driven by either the debug and test system or the target system with other useful information. Additional JTAG signals such as, for example, the boundary check enable (BCE) signal and the test reset (TRST) signal may be driven by the debug and test system. Other data that can be driven onto the TMSC signal during delay periods may become apparent to those skilled in the art, and all such data is intended to be within the scope of the present disclosure.

In at least some of the preferred embodiments a timeout mechanism is included that forces the state machine of FIG. 16B to reset all cJTAG control registers to their power-on reset values and return the cJTAG state machine to IEEE mode. The criteria for triggering this timeout is based on a predetermined number of consecutive clock cycles (e.g., 64 clock cycles) during which the TMS bit remains a one. If the TMS bit stops transitioning at least one of the cJTAG adapters is presumed to have stopped operating properly, warranting a reset of the cJTAG interface. As described above, variable delays are achieved by holding the TMS bit to a one. The timeout mechanism thus limits a variable delay cycle to less than the timeout clock count.

To extend the delay times that are possible, at least some of the preferred embodiments implement a delay extension mechanism, which is also shown in FIG. 16B. Assuming, for example, a timeout above 64 consecutive clock cycles, if the TMS bit is held high for no more than 64 clock cycles, thus transitioning the state machine from the wait state 3140 to the dispatch state 3130 on the 65.sup.th clock cycle, the TMS cycle may be set to a one again, sending the state machine back to wait state 3140. No timeout will occur and the delay has now been extended for up to another 64 clock cycles. This extension sequence may be repeated as many times as necessary. In at least some preferred embodiments, the timeout is set to expire above 2 clock cycles, and the TMS bit alternates between a one and a zero. Referring to the state machine of FIG. 16B, this causes successive transitions between wait state 3140 and dispatch state 3130. But because the timeout is set to expire above 2 clock cycles, a timeout will occur within one clock cycle of a failure by the TMS to transition. This allows for relatively long, and even indefinite, delay periods, while also providing a relatively quick timeout response. Other configurations may become apparent to those skilled in the art, and all such configurations are intended to be within the scope of the present disclosure.

As already noted, the purpose of the OScans is to provide a way for transmitting only that data that is needed and omitting bits of data that are not needed for a particular transaction. For bits like TDI and TDO this means not including the information within the packet. But unlike the TDI and TDO bits, the TMS bit is used to determine the state transitions that occur in both the TAP and cJTAG state machines. For OScans packets that move data (i.e., packets associated with shift states), and that include the TMS bit, the TMS bit is low in each packet until the end of the transfer, and then set high within the last packet. For OScans where the TMS bit is excluded, at least some of the preferred embodiments use an alternative mechanism that signals the end of the transfer without using the TMS bit.

FIG. 17 illustrates how the TCK and TMS signals are used to create an end-of-transfer escape sequence that is detectable by a cJTAG adapter but has no effect on a JTAG TAP state machine. In the preferred embodiment of FIG. 17, serialized data is transferred between the debug test system and the target system using the TMS signal and clocked between the systems using the TCK signal. At the end of an OScan that omits the TMS bit within the packet transferred, the TCK signal is held high by the DTS cJTAG adapter, which keeps any TPA state machine that is coupled to the TMS and TCK signals from transitioning states. The TMS signal is then subsequently set to the inverse of its last state by the DTS cJTAG adapter, and then pulsed while the TCK signal continues to be held high. A TS cJTAG adapter coupled to the TMS and TCK signals counts the pulses. After the pulsing completes, the TMS signal is returned to its initial value at the start of the escape sequence and the clock is restarted. One clock cycle later, the escape sequence takes effect. Although the escape sequence of the preferred embodiment described uses the TMS signal for transferring data, any other non-TCK signal may be used, as well as any other combination of signals other than TMS and TCK, and the present disclosure is intended to encompass all such embodiments.

As illustrated in FIG. 17, the escape sequences of the preferred embodiments can be used for purposes other than just an end-of-transfer indication. Both a soft reset and a hard reset are shown. Each uses a different number of pulses to indicate which function is desired. Further, the hard reset sequence does not require that the clock resume, allowing a full reset of the cJTAG link even after a failure of the clock to resume. Many other functions can be added by adding additional pulse counts, and the present disclosure is intended to encompass all such functions. Within at least some of the preferred embodiments, any additional functions would be implemented with a lower pulse count than soft and hard reset. In this way hard reset always requires the highest pulse count and would be triggered without having to restart the clock and also would be triggered if the TMS signal gets stuck in a continuous toggle.

As described above, both soft and hard reset escape sequences are implemented in at least some of the preferred embodiments. A soft reset escape sequence is used to place an offline cJTAG adapter back online. The soft reset escape sequence is ignored unless the cJTAG adapter is operating in advanced mode and is in a state that allows a soft reset. A soft reset escape sequence is allowed immediately after a register write while in advanced mode, and anytime if the cJTAG adapter has been placed offline by enabling an unsupported feature. The soft reset places the cJTAG adapter into IEEE mode, deselects the cJTAG adapter, and closes any open command windows, but does all this without re-initializing any other part of the cJTAG adapter. A hard reset escape sequence provides the same functionality as a JTAG test reset or a JTAG boundary compliance enable. A hard reset asynchronously changes the system state in either IEEE mode or advanced mode. A hard reset may be generated independent of the cJTAG adapter state. In at least some preferred embodiments, a hard reset is never ignored.

As illustrated in FIGS. 12A and 12B, different OScans are used depending on the source of the clock signal used for the cJTAG link. OScans 0-3, for example, are not allowed if the target system sources the clock. This is due to the fact that the data packets for these OScans do not include the TMS bit, and thus require the use of an end of transfer escape sequence. In order for the debug test system to signal the end of transfer, the debug test system must control the clock. In at least some of the preferred embodiments the DTS cJTAG adapter can check a register within the cJTAG adapter to determine the currently configured clock source. The contents of this register are determined upon initial power up of the system. Upon power-on reset, the debug and test system initially maintains the TCK and TMSC signals tri-stated. Thus, until these signal are enabled, any activity on the part of the debug and test system does not affect any target systems to which the debug and test system is coupled. This allows the debug and test system to sequence through any states required for to determine its own configuration and to properly initialize itself. Once properly initialized, the debug and test system can selectively enable the TCK and/or TMSC signals to determine if there are target systems driving the clock signal, thus allowing the debug and test system to store in the register the clock source configuration. If an OScan is requested that requires that the debug test system source the clock, but the target system is configured to source the clock (based on the detected and saved configuration), a compatible OScan will be used instead (i.e., one of OScans 4-7), regardless of the OScan that is requested. It should be noted that although the above preferred embodiments are described from the perspective of the data and test system, the target system of at least some preferred embodiments is also capable of making such a determination of the clock configuration and of adjusting the OScan format used according to the source of the clock.

The debug and test system of at least some preferred embodiments may also selectively enable other signals, such as TDI and TDO, and based upon the response of one or more target systems, as detected by the debug and test system, the topography of the system (e.g., series, wide star, or narrow star) can be determined. For example, if the debug and test system leaves TDI tri-stated, but detects that it is at a logical 0 level (pulled low) then system is in a two-wire configuration which means that there are not JTAG devices (i.e., two-wire narrow star configuration). A variety of bit sequences may be output by the debug and test system on the various signals of the link 1300 coupling the debug and test system 1100 and one or more target system (e.g., target system 1200) of the preferred embodiment of FIG. 1. The response by the target systems, as detected by the debug and test system eventually allow a determination of the topology of the system. Sequences may be selected such that a response corresponding to each configuration is expected. If an expected response is not received to a bit sequence corresponding to one configuration, another sequence corresponding to another configuration is attempted. This process is repeated until the configuration is identified. If no matching configuration is identified, the interface is declared inoperative. Many different bit sequences and signal selections are possible to this end, and all such sequences and selections are intended to be within the scope of the present disclosure.

Another extension to the JTAG architecture added by the cJTAG architecture of at least some of the preferred embodiments is the ability to select and de-select cJTAG systems without affecting JTAG target systems that are also present in the system. A cJTAG target system can be de-selected by placing the target system in global bypass mode. In global bypass mode the cJTAG adapter halts the clock provided to the target system TAP, which prevents the TAP state machine from changing state until re-selected. The cJTAG global bypass mode is similar to the JTAG bypass mode in that all data is routed through the 1-bit global bypass register, as show in FIG. 18, until it is again selected. But unlike the JTAG bypass mode, global bypass mode also results in all instructions being routed through the 1-bit global bypass register as well.

Selection of a cJTAG target system is a two-step process that includes a pre-selection of the desired cJTAG target systems, followed by activation of the pre-selections 1 clock cycle after entry by the target system TAP into the run-test/idle state (see FIG. 6A). As previously noted, de-selection of a target system blocks the clock signal to the target system TAP. The TAP, which is left in the run-test/idle state after de-selection, does not sequence any further after de-selection because it is no longer receiving a clock signal. By splitting the selection into a pre-selection that blocks the clock, followed by activation of the pre-selections which re-enable the clock, multiple target systems may be pre-selected in sequence, followed by a single activation that triggers all the pre-selects together. The pre-selects will all go into effect 1 clock cycle after the activation. The effect is to create a global selection of multiple target systems coupled to a single port of the test data system. Although the above description is in the context of a global selection, this same process may be used to implement a variety of global commands, and all such global commands are intended to be within the scope of the present disclosure.

Global selection of multiple target system can be expanded to operate across multiple ports. In at least some preferred embodiments, the debug test system may have multiple cJTAG ports that each couple to multiple target systems. In such preferred embodiments, the ports may be enabled and disabled through a single control register within the debug test system. After the target systems of a port are de-selected, the port itself is disabled. Each port is then enabled in sequence, and while enabled the above described pre-select sequences are performed on one or more target systems. After pre-selects of the desired target systems have been performed on one port, but before activation, the port is disabled as a second port is enabled. The pre-selection process is then repeated for target systems coupled to the second port, and then again for each successive port. Once all ports have been processed and all the desired target systems on all ports are pre-selected, the ports are all enabled together and all of the target systems are activated at once. The effect is to create a global selection of multiple target systems coupled to multiple ports of the debug test system. As before, although the above description is in the context of a global selection, this same process may be used to implement a variety of global commands, and all such global commands are intended to be within the scope of the present disclosure.

In at least some of the preferred embodiments, as previously noted, a debug test system may be coupled to one or more target systems in either a serial or star configuration. In the series configuration shown in FIG. 2B, both JTAG and cJTAG target systems may be present. The commands used to select a cJTAG target system (pre-selection and activation) in a series configuration are advanced mode commands that are ignored by JTAG target systems as no-ops. Advanced mode commands may also be used to perform a global select of the cJTAG target systems. This is accomplished by designating one of the advanced mode commands for this purpose, which when received by a cJTAG target system causes it to treat the next advanced mode command as selection information, even if the cJTAG target system is in a bypass or global bypass mode. The information thus provided determines with cJTAG target systems are selected, and which are not selected.

In the star configurations shown in FIG. 2B, all of the target systems must be cJTAG target systems. In order to address cJTAG target systems in a star configuration, each cJTAG target system must have a unique adapter ID that allows it to be accessed exclusively at a given point in time. To accomplish this, at least some of the preferred embodiments utilize a 4-bit link identifier which is dynamically assigned by the debug test system to each target system. FIG. 19 illustrates how an ID is assigned to each cJTAG target system. The assignment method 7000 begins with either a power-on reset or a reset of the link coupling the debug test system and target systems to each other (see Wide Star configuration, FIG. 2B), as shown in block 7010. In this state each target system defaults to a link ID of 0, blocks link ID assignment by setting its individual scan status to zero, forces the use of Multi-device Scans (“MScans”), and becomes de-selected. If there is only one target system coupled to the debug test system (block 7020), no ID assignment is necessary and the ID assignment method 7000 is done (block 7060). Operation may begin by selecting the target system with ID zero, and by using MScans (described below) to access the target system.

If there is more than one target system (block 7020) then all of the target systems are de-selected (block 7020) and the link IDs of all of the target systems are invalidated by setting the scan status of each target system to one (block 7030). In at least some of the preferred embodiments the de-selection and invalidation blocks are implemented with advanced mode command sequences that use commands such as those listed in FIG. 8B. Referring again to FIG. 19A, once de-selection and invalidation are complete, ID assignment can proceed (block 7050), completing the method 7000 (block 7060).

As already noted the target systems initially are forced to use MScans. FIG. 20 illustrates the basic data format for an MScan message. Though very similar to the previously described OScan7 message format, the MScan has two additional bits, pre-charge bits 0 and 1 (“PC0” and “PC1”). The ready and TDO bits of at least some of the preferred embodiments are driven by the target systems. But in the star configuration, with multiple target systems coupled to a single debug test system, it is possible for multiple target systems to sometimes attempt to output the ready (“RDY”) or TDO bits at the same time, creating a signal conflict on the TMS signal line. To prevent this conflict, the target systems drive the TMS signal line with the ready and TDO bit information using a pre-charge/discharge signal drive configuration, together with bus-keeper latches, when using MScans.

FIG. 21 illustrates the hardware configuration used to prevent bus conflicts on the TMS signal line 1320 together with the MScan format. Referring to both FIGS. 20 and 21, the pre-charge one (“PC1”) bit, which is always a binary one, is output by the DTS TMS driver 1160 and loaded into keeper latch 1370. A keeper latch is a latch with an output driver that is significantly weaker than other output drivers coupled to the same signal as the input and output of the keeper latch 1370. When DTS TMS driver 1160 outputs a signal, it will overcome the drive of the keeper latch 1370, if they are driving opposite states, and keeper latch 1370 will change state accordingly. In the absence of any drive on the TMS signal line 1320 output driver 1160, keeper latch 1370 will maintain or “keep” the latched bit driven on the signal line. During the TDO bit cycle time, if either target system 1 (“TS 1”) or target system 2 (“TS 2”) outputs a TDO value of zero, the corresponding pull-down gate (1450 or 1550) will drive the TMS signal line 1320 low, causing keeper latch 1370 to also change to a zero. If neither target system drives TMS signal 1320 to a zero, it will remain in the kept state, which is the logical one driven onto TMS signal 1320 during the PC1 bit cycle. This same mechanism is also used with the ready bit, in combination with the pre-charge zero (“PC0”) bit.

By taking advantage of the “wire-OR” configuration of TMS signal 1320 and the MScan format, individual target systems may be isolated and subsequently assigned a unique link ID. FIG. 22A illustrates a debug test system ID assignment method 7100, in accordance with at least some preferred embodiments. After sending an advanced mode command sequence to all coupled target systems to initiate an assignment cycle (block 7110), the debug test system begins initiating a series of MScans (block 7115) in which one or more of the target systems output bits from a unique isolation pattern. An isolation pattern is a unique identification number associated with each target system. FIG. 23 illustrates an example of an isolation pattern, in accordance with at least some preferred embodiments, comprising a node ID, a part number, a manufacturer's ID, and a zero for the last bit. The part number combined with the manufacturer's ID and the last bit (set to zero) is a 28-bit identifier that is sometimes referred to as the JTAG ID. The 4-bit node ID provides a means for identifying a target system when two target systems have the same JTAG ID. Other techniques for generating unique isolation patterns for each target system will become apparent to those skilled in the art, and the present disclosure is intended to encompass all such techniques.

The debug test system waits for the last MScan bit of the isolation pattern to complete (block 7120) and then checks to see if all bits including the last bit are a one (block 7130). If all bits are a one, the pre-charge has not been pulled down by any of the target systems, all have been assigned a link ID, and the assignment method 7100 has completed (block 7190). Otherwise a target system has pulled down the pre-charge of at least one bit, has been isolated, and the debug test systems assigns a link ID to the isolated target system (block 7140). The debug test system then increments the link ID (block 7150) and checks to see if the link ID equals or exceeds 16 (block 7160). If so, more than 16 link IDs have been assigned. The debug test system then checks to see if it is configured to continue to isolate the additional target systems coupled to the debug test system (block 7170). If more than 16 target systems are coupled to the debug test system, it may become necessary for at least some of the target systems to share link IDs. If the debug test system is configured to share IDs, the extra target systems may optionally be isolated as well so that additional processing may be performed later to share link IDs between two or more target systems (described below).

FIG. 22B illustrates a target system ID assignment method 7200 corresponding to the debug test system assignment method 7100, and in accordance with at least some preferred embodiments. After an assignment cycle has been started (block 7210) and MScans are being generated, the target system begins outputting each bit of its assigned isolation pattern during the TDO bit period of each MScan. If the target system detects a discrepancy between the TDO bit value output by the target system and the binary value present on the TMS signal line (block 7120) for any given bit of the isolation pattern, the target system will exit (block 7250) and cease participating in the current ID assignment cycle. If the binary value present on the TMS signal line matches the TDO bit value output by the target system, the target system checks to see if the current bit is the last bit of the isolation pattern (block 7230). If the current bit is the last bit, then the target system has been isolated and is assigned a link ID (block 7135), and the current assignment cycle ends (block 7250). Otherwise the next bit is output (block 7240) and the process is repeated for each bit (e.g., 32 bits in at least some preferred embodiments).

As already noted, it is possible to have more target systems coupled to the debug test system in a star configuration than can be accommodated directly by the bit-width of the assigned link IDs. In at least some of the preferred embodiments, default link IDs may be assigned at power-on reset up to the maximum available, or may be assigned after power-on reset through a link ID assignment process that allows for sharing of link IDs. Sharing is accomplished by determining the number of target systems coupled to the debug test system, invalidating the link IDs of, and selectively de-selecting, some target systems while expressly assigning link IDs to the remaining target systems, such that the total number of assigned link IDs never exceeds the maximum number of available link IDs. To accomplish such an express ID assignment, a command level is defined for at least some of the preferred embodiments wherein the target systems are blocked from outputting the TDO bit (e.g., command levels 3, FIG. 8A). During an assignment cycle, the debug test system acts as a surrogate for the target system expressly being assigned a link ID, and outputs the isolation pattern of behalf of the target system. By outputting the target system's isolation pattern, the desired target system will be the system remaining at the end of the ID assignment cycle, expressly forcing the assignment of the link ID to the desired target system.

As already noted once all the available IDs have been assigned, the debug test system can detect that there are still additional target systems requiring a link ID. By going through additional assignment cycles, the debug test system can count the number of target systems in excess of the available link IDs. Further, the isolation patterns for the “extra” adapters may be saved for future use in resolving the link ID shortage (e.g., by using the sharing scheme described above). In at least some of the preferred embodiments, a single link ID is used over and over again upon initial assignment, and all of the adapters share that common ID until the debug and test systems changes or invalidates the ID.

The cJTAG adapters of at least some preferred embodiments are also capable of supporting non-scan data transfers between the debug test system and one or more target systems. These background data transfers (BDX) take advantage of the time that the target system TAPs spend in one of several BDX-supporting states such as, for example, the run-test/idle, pause_DR, and pause_IR states (see FIG. 4). The transfer substitutes BDX information in lieu of the scan packet normally associated with a target system TAP state. A background data transfer may be enabled by a control register write performed after the target system has been in the BDX-supporting state for at least one scan packet cycle associated with the supporting TAP state. Once a background data transfer has started, the target system TAP state is advanced by each background data transfer. The selected target system transfers data while unselected target systems transition through the same states as the target system transferring data, but without actually participating in the transfer. This keeps the TAP states of the target systems synchronized. The background data transfer is terminated upon exit from the supporting state. Data may be transferred exclusively in one direction (to the target system, or to the debug test system), or alternately in both directions (bidirectional transfer). The bandwidth allocation of a bidirectional transfer in at least some of the preferred embodiments is 50/50, but other allocations are possible and all such allocations are intended to be within the scope of the present disclosure.

Two types of background data transfers, burst and continuous, are defined for at least some of the preferred embodiments. FIG. 24 illustrates the format of a burst background data transfer. As shown, the first burst packet of a newly activated transfer skips the header and begins with an abbreviated scan packet followed by burst data packets. Subsequent packets include the header, which is formatted depending on the scan format in effect prior to activating the background data transfer. FIG. 25 illustrates several different header configurations, in accordance with at least some preferred embodiments, as well as the association between the header configurations and the cJTAG scan formats. When scan formats that support the use of scan stalls or delays are in use, the background data transfer will also support such stalls and delays using the same mechanisms as those defined for the scan format. Although the burst data packets of the preferred embodiments are of fixed bit sizes (e.g., 8, 16, 32, or 64 bits), other bit widths may be used and the present disclosure is intended to encompass burst packet sizes of all such bit widths. Other preferred embodiments may insert advanced mode packets (e.g., MScans and OScans) instead of the headers illustrated in FIGS. 24 and 25.

It should be noted that the TMS bit of the burst background data transfer header is driven by the debug test system, while the bits associated with the ready check, are driven by the target system participating in the transfer. This is done in order to protect against a disconnect of the TMS signal between the debug test system and the target systems. Referring to FIG. 21, if such a disconnect occurs, the logic “1” driven by the active target system at the end of the ready check sequence of the BDX header will be maintained by keeper latch 1370. As a result, when the debug test system fails to drive the TMS bit to a logic “0,” TMS will be seen as a logical “1,” the target system TAP state machines of all the target systems will exit the BDX-supporting state, and the background data transfer will end. Further, because a logical “1” continues to be present on the TMS signal 1320, the target system TAP state machine of all the target systems will eventually sequence back to the test-reset/idle state (see FIG. 4), which causes the target system's TAP to revert to a known, stable state, thus providing TAP synchronization in the event of a disconnect. This will only happen, however, if the target system is sourcing the clock, or if the debug test system is sourcing the clock and has not also been disconnected from the target systems.

FIG. 26 illustrates the format of a continuous background data transfer. Unlike burst background data transfers, continuous background data transfers do not have any header information, and the data is simply a two-bit payload, although it is intended that the present disclosure encompass any size payload for continuous background data transfers. Continuous background data transfers are ended using the end of transfer escape sequence previously described. Because continuous background data transfers do not use headers, stalls and delays are not supported during these transfers. As a result, at least some of the preferred embodiments will force a selected continuous background data transfer to be executed as a burst background data transfer if the format in effect upon activation of the background data transfer requires scan stalls. Burst background data transfers will also be forced if the target system is the source of the clock, and also if the scan packets are configured with delays between packets.

The cJTAG adapters of at least some preferred embodiments are also capable of supporting non-scan data transfers between the debug test system and one or more target systems using non-cJTAG hardware and protocols incorporated into the cJTAG adapters. As shown in FIGS. 28 and 29, these custom data transfers (CDX) are similar to background data transfers, differing only by the inclusion of an extra bit preceding each of the burst payload packets and the first continuous payload packet. This extra bit is always a one and accounts for the case where neither the CDX hardware of the debug test system, nor of any the target systems, starts to transfer data after activation of the continuous data transfer. The system recovers in a manner similar to the TMS signal disconnect case described above for background data transfers. In all other respects continuous data transfers operate in the same manner as background data transfers. As with BDX transfers, other preferred embodiments of CDX transfers may use advanced mode packets (e.g., MScans and OScans) in place of the headers illustrated in FIG. 28.

The cJTAG architecture has the added capability of configuring parts of the cJTAG interface of the target system to be powered-down under selected conditions. FIG. 30 illustrates some of the conditions under which such a power-down is allowed by at least some of the preferred embodiments. Four power-down modes are defined and the power-down mode is selected either at power-on reset or after power-on reset by reprogramming the adapter using a software command. The four modes include not permitting a power-down when requested (mode 0) regardless of mode, permitting a power-down when requested if the state machine of the target system cJTAG TAP is in the test logic reset (“TLR”) state (mode 1) while in standard mode, permitting a power-down if the state machine of the target system cJTAG TAP is in the test logic reset state while in standard mode and there has been no link clock (TCK) activity for more than 1 millisecond (mode 2), and permitting a power-down based only on the lack of a link clock for more than 1 millisecond in both standard and advanced mode (mode 3). Although the preferred embodiment shown in FIG. 30 uses a 1 millisecond inactivity period, other inactivity periods are possible and are intended to be within the scope of the present disclosure.

Mode 0 and mode 1 operate in an “affirmative response” (“AR”) model. Both modes involve a requested operation while the link clock is up and running. The request originates from logic external to the TS cJTAG adapter and is referred to as the Power and Reset Controller (“PRC”). As shown in FIG. 31, the PRC asserts synchronized power-down request 8030 when the PRC is in mode 1 (power-down is not permitted in mode 0). After the TS TAP indicates that it has entered into the test logic reset state (TLR TAP state signal 8040 asserted) while in standard mode, and indicates that TMS has been asserted (TMS force 8050), the TS cJTAG adapter performs an orderly shutdown of the cJTAG interface (indicated by PD state 8060), halts the JTAG clock 8020, and acknowledges the power-down request (PD_ACK 8070).

Mode 2 and mode 3 operate in a “non-response” (“NR”) model. As shown in FIG. 32, in these modes of operation the PRC generates an event that may generate a power-down acknowledge. If a power-down acknowledge is generated, the TS cJTAG adapter must negate the power-down acknowledge within the inactivity period. In the preferred embodiment of FIG. 32, the TS cJTAG adapter periodically toggles the power-down acknowledge 8120 at an interval that is half the duration of the time base 8110. The time base has a period that is equal to the inactivity period. Periodically toggling the power-down acknowledge 8120 acts as a “keep alive” heartbeat that prevents the PRC from powering down the TS cJTAG adapter. If the acknowledge does not negate the state of the power-down acknowledge within the inactivity period, the sampled power-down acknowledge 8130 will remain at the same state for a period of time exceeding the inactivity timeout, and the power down will be allowed at that point if Mode 3 is enabled. In Mode 2 the power down will not be allowed unless the TS TAP has entered the test logic reset state while in standard mode. Thus, only Mode 3 is available to allow a power down while in advanced mode, which will occur if the power-down acknowledge stops sequencing for a period of time longer than the inactivity period. This may happen, for example, if the target systems becomes disconnected from the debug and test system (if the clock is driven by the debug and test system), which results in a return to the test logic reset state, where the TAP remains due to the TMSC signal (and as a result the TMS bit) being pulled up and held to a logical one. Once the TAP has remained in the test logic reset state for more than the inactivity period, the power down is allowed.

In at least some preferred embodiments, a distinction is made when a TAP state machine is in the test logic reset state of FIG. 4 while in advanced mode, as opposed to IEEE mode. In such preferred embodiments, it is desirable to sometimes prevent a reset and a transition to IEEE mode from occurring while holding the TAP state machine in the test logic reset state in advanced mode, while at other times allowing the transition to IEEE mode whenever the TAP state machine is held in the test logic reset state in advanced mode. To make such a selection of behavior possible, at least some preferred embodiments are configured to change behavior in this manner based upon a pre-selected sequence of TMS bits.

After reaching the test logic reset state, if the TMS bit is low in two successive packets in advanced mode while in the test logic reset state, the TAP state machine transitions to the run test idle state, where it then remains, still in advanced mode, as long as the TMS bit is low. If the TMS bit is high in one packet of a two packet set, and low in the other packet of the two packet set, the TAP state machine will remain in the test logic reset state for each test logic reset state where this conditions is true, also remaining in advanced mode. But if the TMS bit is held high for two successive packets, the sequence is treated as a special or abnormal sequence, causing a hard reset to be generated and forcing the system 1000 to revert to IEEE mode after completion of the reset.

Although two successive logical “1” values of the TMS bit are used in the preferred embodiment described, other values, bits, and sequences may become apparent to those skilled in the art, and all such values, bits, and sequences are intended to be within the scope of the present disclosure. Further, although the present disclosure describes a preferred embodiment that returns to the IEEE mode by default upon reset, other modes may be selected as a default mode as previously described with regard to configuring the system 1000 upon power-on reset, and all such default mode configurations are also intended to be within the scope of the present disclosure.

It is possible that system operation may be changed or corrupted by a make or break in the connection of a debug test system and target system. In accordance with at least some preferred embodiments of the invention, a “firewall” is implemented to reduce the chance that system operation is changed or corrupted by a make or break in the connection of a debug test system and target system in a mix of powered and un-powered configurations. The term firewall, as used in the present disclosure, is intended to refer to a mechanism by which a clock that drives a TAP state machine is gated by a control signal, allowing the state machine to be disabled and thus protected from bit transitions on other signals caused by the make or break in the connection as described above. When either a debug and test system or a target system is firewalled, the TAP machine is frozen and cannot transition from state-to-state. Although the clock signal is gated in the preferred embodiments described, other signal may also be gated by a control signal as part of a firewall implementations, and all such implementations are intended to be within the scope of the present disclosure.

A firewall between the debug test system and target system interfaces may be created at power-on reset (POR) or under the direction of the debug test system. As already noted, the firewall blocks the TCK signal to the target system TAPs attached to the cJTAG interface which prevents the TAP from advancing. The firewall may be raised and lowered within a command window. The firewall may easily be removed by standard scan sequences after POR prior to any determination of the configuration or topography of the system 1000 of FIG. 1. The firewall may also be removed prior to performing any other action such as obtaining the device ID with the IDCODE instruction created by the TLR TAP state. Commands within a command window change register values controlling the firewall. Changes in the state of the firewall take effect when the system TAP state reaches the IDLE state in at least some preferred embodiments. Other states or state sequences may be implemented to allow changes in the state of the firewall, and all such implementations are intended to be within the scope of the present disclosure.

Devices that implement a firewall are entirely compatible with those that do not implement a firewall as the firewall enables the global bypass provided by the global bypass bit in addition to disabling the clock that advances the state of the of the TAP state machine connected to the cJTAG interface. This is accomplished using a command window sequence, which is ignored by both JTAG devices, as well as cJTAG devices that do not implement a firewall. JTAG devices treat the command window as an inert state sequence and are not affected or modified by the sequence. JTAG or cJTAG devices that do not implement a firewall do not include the firewall control register being modified while the command window is open, and thus will also not be affected by the sequence. cJTAG devices that implement a firewall but have the firewall lowered at power-on reset are likewise unaffected by the sequence. This makes both firewalled and non-firewalled operation entirely compatible with systems using the JTAG protocol.

At least some of the preferred embodiments of the invention provide for orderly behavior in the event of a break in the electrical connection between the debug and test system and the target system (e.g., if the cable is disconnected). This behavior creates device operation like that created by a power-on reset. Two connection breaks are possible: supervised or intentional breaks, and unsupervised or unintentional breaks. A supervised break is preceded by a command issued by a user of the debug and test system to prepare the system for a supervised break. Upon receipt of this command, the system will place the system in a state similar to the state that results from a power-on reset. Once in that state, the user is notified that the system is ready, allowing the user to then disconnect the debug and test system from the target system.

An unsupervised break is one not anticipated by the user (e.g., an accidental disconnect). In this case, the response depends on whether the target system or the debug and test system is supplying the TCK signal. In at least some preferred embodiments if, for example, the target system is supplying the TCK signal, the target system's TAP state machine transitions to the test logic reset state (FIG. 4) and the cJTAG adapter then powers down. If the debug and test signal supplies the TCK signal, in at least some of the preferred embodiments, the cJTAG adapter freezes (due to the lack of a clock signal) and if power down mode with no TCK is used, the PRC executed a power-on reset after no TCK time limit is exceeded. The BCE pin, which has a pull down connection, also goes low, which resets all test logic.

In at least some preferred embodiments where the TCK signal is provided by the target system, the negative of the TDI (nTDI) signal is used when the TDI bit is transmitted across the link. The use of nTDI assures a TDO value of “1” in shift states (i.e., the TMSC signal will have a value of “1”). The control states generate a TDO bit value of “1” in non-shift state (i.e., the TMSC signal will again have a value of “1”). As a result of the TMSC signal (and thus the TMS bit) begin held at a logical value of “1,” the TAP state machine transitions to the test logic reset state. When at the test logic reset state, the cJTAG adapter detects two TMS bit values of “1” which, as previously described, then causes a reset. At this point, the cJTAG adapter is back in the IEEE mode with the TAP state machine state at test logic reset. The reset initializes the power down mode to the default power-on reset values for the cJTAG adapter and permits power down if the mode so allows.

System Architecture

cJTAG provides a bi-modal link between the DTS TS IEEE 1149.1 interfaces as shown in FIGS. 1, 35, 36 and 37. The bi-modal operation of the link refers to the two protocols used (JTAG and cJTAG) to exchange information between the DTS (Debug and Test System) and TS (Target System). The link may be implemented in two widths (narrow and wide). The narrow width utilizes only two of the 5 JTAG pins while the wide width utilizes either the 4 or 5 pin JTAG configuration. Non-JTAG standard systems with a return test clock (RTCK) are also accommodated.

JTAG protocol may be used to manage link capabilities with either width and communicate with test access ports (TAPs) connected to the TS adapter when the width is wide (4, 5, or 6 pins). cJTAG protocol may be used to manage link capabilities with either width and communicate with TAPs connected to the TS adapter with either debug port width. cJTAG is essentially a JTAG use case with some of the characteristics of a private instruction.

The adapter uses several aspects of JTAG state sequences to create a control hierarchy above that afforded by legacy JTAG. This control hierarchy is created using:

Inert JTAG instructions (BYPASS, IDCODE)

Zero bit DR Scans (ZBS)

cJTAG control data creation using the number of clocks spent in the Shift_DR TAP state

Special relationships between TCK and TMSC

Once an inert instruction is loaded into the JTAG instruction register, zero bit scans (Capture_DR then Update_DR without a Shift_DR TAP) are used to specify a control level. The control level is specified by the number of consecutive ZBSs without a Shift_DR TAP state. Once the control level is established, the cJTAG control registers are managed with DR Scans. The number of TAP states spent in the Shift_DR state is recorded with a 5-bit counter, with the counter value used as data when the Update_DR TAP state occurs. The 5-bit data value is used to create 4-bit data that is loaded into a temporary register and 4-bit commands that disposition this data. These simple capabilities are sufficient to manage the cJTAG interface and all the capabilities of the cJTAG adapter. Note that the TDI and TDO pins are not needed to implement the control mechanisms described above.

The link protocol includes:

Reset and Escape commands created with TCK high and multiple TMSC transitions

Standard JTAG

Packets of information in advanced modes

JTAG scan transactions are further serialized to create packets associated with a single TAP state. The information content of these packets is varied using optimizations that delete information that may be created in another way or is just not needed. This increases link efficiency. Verbose packets are provided to manage compatibility with all JTAG and modified JTAG (JTAG+RTCK). These packets move TMS, TDI and TDO between the DTS and TS, in addition to a RDY bit that allows stalling packet transmission. The RDY bit may be used to perform the stall function associated with RTCK. Other scan packet formats eliminate unnecessary information from the packet, increasing the packet efficiency. The packet optimizations used are changed depending on whether the TCK source is the DTS or TS. A TS TCK source prevents the use of the Reset and Escape link protocol described above, as the DTS cannot stop TCK when it does not source TCK.

Background Data Transfers (BDX) utilize unused Link bandwidth by assuming control of the Link when BDX is fully qualified, and an IDLE, Pause_DR, or Pause IR state is reached. A BDX packet is sent for each TAP state, following the first, spent in these states. Control of the Link is returned to scan and scan packets when the state supporting BDX is exited.

The cJTAG architecture provides for custom use of the Link. This type of Link use is called Custom Data Transfer (CDX). Control of the TMSC pin is passed to a unit external to the adapter when the CDX capability is fully qualified and the Shift_DR state is reached. This capability allows virtually any debug technology to share the cJTAG Link bandwidth, with cJTAG being the master of the link. The JTAG look and feel of the interface may be maintained while other capabilities share Link bandwidth.

Since the cJTAG capabilities are both manual and optional, the architecture provides for the coexistence of devices or adapters with different capability. When an unsupported capability is enabled, the adapter merely places itself offline until either a soft, hard escape sequence is detected, or adapter POR occurs.

The adapter literally connects and disconnects the TAPs connected to the adapter system interface when the adapter is selected and de-selected. Disconnecting the TAPs connected to the adapter merely turns off the TCK to these TAPs. The IDLE state is used to synchronize the application of selections made previously. Different selection mechanisms are provided for scan and BDX. Scan and CDX share a selection mechanism.

Part of the cJTAG command and register space is dedicated to uses other than those associated with the standard portfolio of cJTAG capabilities. This allows the addition of test and DTS capability, with these capabilities subject to the same programming constraints of normal cJTAG functions. A DTS designer may use the reserved commands as registers to control a multiple DTS port, determine the TCK source, manage its Link-interface mode, etc. Likewise, a chip developer may implement a control-collar around conventional chip terminals for testing or other control, using cJTAG commands and registers reserved for this or other custom purposes.

cJTAG extends the capabilities of the IEEE 1149.1 standard with a rich portfolio of capabilities as shown in. Simple uses such as programming a single component require simple solutions. Sophisticated systems such as debug of a system-on-a-chip (SOC) require more sophisticated solutions with an emphasis on debug performance.

These capabilities optimize target device pin count, link scan performance, and debug performance; three related yet different areas. Two data transport facilities are included; the first utilizing otherwise wasted link bandwidth for debug purposes and the second supporting custom debug extensions, each sharing link bandwidth with scan. The architecture is scalable, allowing implementation of varying degrees of capability. Each of these cJTAG capabilities is described in this specification.

The minimum link/TAP TCK ratio (Min. Link/TAP TCK ratio) represents the minimum number of Link TCKs needed before the TAP state is advanced. This ratio is 1/1 for JScan formats as they operate as JTAG does. With advanced scan formats, TMS, TDI, and TDO information is serialized over the TMSC pin making the number of Link TCKs needed for a TAP state change greater than one. This ratio represents the minimum number of TCKs a specific scan format needs to advance the TAP state. The number of Link TCKs may be greater than this ratio at times but never drops below this ratio. If the ratio is 2/1 for instance, a link TCK of 100 MHz will never cause the TAP state to advance faster than 50 MHz. If the ration is 3/1, a link TCK of 100 MHz will never cause the TAP state to advance faster than 33 MHz. When the maximum TAP state rate of legacy equipment is known, this ratio determines the maximum link TCK frequency for the format. The 6/1 ratio shown in FIG. 87 reveals TS equipment with a maximum TAP state rate of 10 MHz will allow a link TCK rate of 60 MHz.

Maintaining backwards compatibility with the IEEE 1149.1 standard is extremely important. Compatibility preserves the industry's investment in the test equipment, emulators, software, and silicon IP developed by those already using this standard. The cJTAG interface is specified to make the serial movement of control and data information across the adapter interface transparent to the DTS and TS components normally using JTAG. Relationships between modes/operations and TAP states must be enabled before they are used. No legacy hardware or software can create harmful situations.

This approach preserves: DTS Software—all existing JTAG drivers, DTS Hardware—debug and test equipment and using JTAG infrastructures, TS Silicon—all silicon intellectual property using JTAG, and DTS Software. Once an operating mode is selected (standard or advanced) and enabled, both the DTS and TS operate as though the interface between the two is IEEE 1149.1 compatible.

Other than the scan sequences needed for link setup and configuration management, the adapters are transparent to JTAG transactions between the DTS and TS. This allows: Deployment with existing JTAG software technology, Management of cJTAG protocol selection with normal JTAG sequences, and Easy addition of these sequences to existing infrastructure in a manner that does not require changes to functions already using the JTAG interface.

The DTS software's view of the TS interface appears as JTAG in both JTAG and cJTAG modes. DTS software drivers for TS components connected to a cJTAG interface are presented the appearance of a JTAG interface in both standard and advanced modes. This maintains the same view of the system from both the TS and DTS standpoint, preserving existing investments in both areas.

The software in the advanced mode is limited to Link setup and configuration management. Since the advanced mode serializes and then reconstructs JTAG transactions at each end of the Link, the DTS and TS equipment and software are virtually oblivious to its existence. The equipment and software exposure to the existence of the advanced mode is limited to Link setup and configuration management. Since these functions are generally relegated to Link start-up and topology management, drivers that are not affected by these attributes remain unchanged. Drivers may be made faster with modifications in cases where segmented scans offer a performance boost.

Deployment of the link leaves the existing JTAG infrastructure virtually undisturbed since: DTS adapters may be externally added to existing DTS equipment, DTS adapters may be incorporated into existing DTS equipment, and HW adapters convert JTAG protocols to advanced cJTAG protocols and back to JTAG protocols.

This means existing IEEE 1149.1-compliant DTS equipment may be upgraded by connecting a cJTAG adapter to an existing DTS JTAG interface. The adapter may be as simple as a dongle added to existing systems or it may be integrated into these systems to achieve better cost or performance. Without integration, the functionality of cJTAG is limited to a subset of JTAG features (e.g., no BDX or CDX). Software controlled interfaces may be reprogrammed.

The cJTAG adapter interfaces directly to a system TAP with no changes to its interface. From the device standpoint, the cJTAG architecture allows: addition of the cJTAG adapter in front of an existing IEEE 1149.1-compliant interface, transaction stalls allowing the TCK rate to exceed the transaction rate supported by certain on-chip components, components that do not support JTAG operation solely with TCK, and components that are made “not ready” by power-down, etc.

The cJTAG architecture is extensible on a number of fronts. It not only comprehends the use of custom debug protocols, it accommodates control register additions specific to cJTAG, Test, and DTS controllers. Public and private control register space is already allocated to these capabilities. The interface can also accommodate multi-port DTS operation and various system connection topologies.

A cJTAG interface is created by placing circuitry in series with DTS and TS JTAG interfaces. This circuitry (called the Bridge) provides DTS/TS communication using either standard (JTAG) or advanced (cJTAG) protocols. The DTS manages the Link with the same command sequences with both protocols using only the TCK and TMSC pins. Operating mode and/or signaling format changes are synchronized and occur concurrently in the DTS and TS. Transfers between the DTS and TS use either a TCK supplied by the TS or TCK supplied by the DTS. The TS supplied TCK may also be associated with other TS functionality and will be free-running, if this option is used.

A high-level block diagram of the Bridge circuitry is shown in FIG. 37. It highlights several views of DTS/TS connectivity. Mandatory cJTAG connectivity is shown in black (TCK and TMSC). Optional connectivity needed to fully support legacy JTAG is shown in gray (TDI and TDO). Additional optional connectivity, for some modified versions of legacy JTAG using the return TCK (RTCK), is shown in outline.

The DTS and TS JTAG interfaces are connected in a pass-through configuration when standard protocol is used. These interfaces are connected with serialization circuitry when advanced protocol is used. The advanced protocol serialization/de-serialization process converts standard protocol to advanced protocol and back to standard protocol. Serialization moves all TAP information between the DTS and TS using only the mandatory 2-pin TMSC and TCK interface.

The interface between the DTS and TS adapters is called the Link. The interface connecting TAPs to the TS Adapter is called the JTAG interface. Likewise, the interface connecting the DTS adapter to other equipment is also called the JTAG interface. If there is a need to describe interfaces with the same names on both sides of the bridge at the same time, or provide additional clarity, DTS and TS may be added as prefixes to the interface names. Both the TS and DTS JTAG interfaces are part of larger interfaces. This larger TS interface is called the System Interface (SI) throughout this document. The corresponding interface in the DTS is not referenced.

Up to 16 TS adapters may be connected in parallel to the DTS adapter, if Return Clock (RTCK) is not involved in the signaling. This creates, what is commonly called, the cJTAG Star configuration. This collection of interconnects is called a port.

Debug and Test System Adapter

A conceptual high-level block diagram of the minimal DTS adapter is shown in FIG. 38 with interface signals shown in FIG. 39. The interfaces for optional capabilities are not included as they do not alter the Link interface. Only the basic functionality is shown in this figure; optional signals are shaded gray. Note that after system boot-up, all JTAG capabilities are transparent.

TCK_SRC is connected to the TCK input of the TS cJTAG adapter when the DTS supplies the TS TCK. In this configuration, the DTS does not use the TCK_RET input. This input is left as a “no connection” as the DTS supplies TCK to itself in this configuration. When the TS supplies the TS TCK, TCK_SRC is not used (no connection) and the TS supplies the TCK input to the DTS via TCK_RET. The DTS signals are defined in FIG. 39.

Target System Adapter

The target system (TS) adapter provides a range of capabilities that include JTAG Extensions, Basic Advanced Scan (2-pin), a variety of performance optimized advanced (2-pin) scan formats, a number of capabilities supporting applications debug, and customizable facilities for chip use, and DTS use.

The mandatory cJTAG capabilities include JTAG extensions and basic advanced scan. With this mandatory feature set, any Debug and Test System (DTS) implementing the mandatory feature set is interoperable with any chip with one or more adapters that also implement the mandatory feature set. A chip architect may choose to add capabilities to the mandatory capability.

In FIG. 40, the adapter 1210 architecture partitions the functionality so that it may be specified through compilation switches. The partitioning corresponds roughly to the functionality discussed in this specification. Most, if not all, of the cJTAG Core is used in both the DTS and TS adapter as the state machines in both adapters track each other. The Link and System interfaces are different in the two adapters.

A high-level block diagram of the TS Adapter is shown in FIG. 41. This diagram emphasizes the mandatory aspects of the interface. The signal descriptions for the mandatory and optional aspects of Link Interface and mandatory aspects of system interfaces can be found in FIG. 42. The standard operating mode provides a direct connection between the Link and JTAG or System interfaces. The advanced mode uses the Link-interface TCK and TMSC to create the JTAG or System interface TCK, TMS and TDI signals, and to export the JTAG interface TDO via the Link interface. The adapter is shown in its basic form. The interfaces for optional BDX, CDX interface power control and the like are not included as they and the JTAG interface are part of a wider system interface. Optional signals are shown in gray.

The Link interface supports two optional reset signals: nTRST and BCE. These signals are shown shaded in light gray in FIG. 412. Either none, one, or both of these signals may be included in the Link Interface. The JTAG interface supports a RDY and RTCK signal. The RTCK signal is needed only if the interface supports operation in a modified JTAG mode. The RDY signal is needed if a TAP within the system may not be able to accept transfers at advanced rates, or if the TS desires to stall memory or other types of block-oriented transfers with advanced protocols tailored to these types of transactions.

Two JTAG extensions are included in the cJTAG architecture: Firewall, and Global selection of devices (a selection mechanism and a Super Bypass TM bit). Both of these extensions affect the operation of the physical interfaces. These capabilities are implemented in a way so as to be transparent to the IEEE 1149.1 standard. These extensions are enabled and disabled with command sequences. In addition, the firewall may be either enabled or disabled by power-on reset (POR). Although these additions seem small, they provide a significant boost to the Link capability without compromising IEEE 1149.1 compliance. These extensions are shaded in gray in FIG. 41. The adapter itself is not affected by the firewall or the selection mechanism.

A cJTAG-enabled device may be built with one of two interface configurations: Wide Interface (4/5-pin), with:

TCK, TMSC, TDI, TDO and (optional RTCK)

Standard protocols (JTAG control and data)

Advanced protocols

Switchable between standard and advanced protocols

Narrow Interface (2-pin), with:

TCK and TMSC

Standard protocols (control only—sufficient for cJTAG command sequences)

Advanced protocols

Switchable between standard and advanced protocols

Both configurations begin operation using standard protocol with control sequences requiring only TCK and. TMSC. This is sufficient to support all cJTAG command sequences and communicate with TS TAP transfer data using advanced protocols.

The Wide interface uses the TCK, TMSC, TDI and TDO pins. Provisions are made to accommodate RTCK, if it is present. Command sequences use TCK and TMSC, making cJTAG management the same for both narrow and wide interfaces. The wide interface supports dynamically switching between standard and advanced modes, with the 4-pin interface functions changed as follows in advanced modes. The TCK pin provides a clock controlling all transfers, and the TMS pin, now referred to as TMSC, becomes bi-directional and is used to transfer all standard TAP control and data information between the DTS and the TS. The TDI and TDO pins may be reassigned for other debug purposes when the wide interface operates in advanced mode.

The Narrow interface uses only the TCK and TMSC pins; hence, full JTAG operation is not supported in this mode. A device with a narrow interface is capable, however, of receiving commands with cJTAG control information conveyed solely via TMSC with the interface operating in either the standard or advanced mode. This is sufficient to specify interface operating characteristics and switch interface operating modes.

Since the TDI and TDO pins are not present with this interface, normal data transfers with standard protocol are not supported. It is recommended that TDI be tied off in a way that generates a one (1) during IR scans to deliver BYPASS instructions and a zero (0) during DR scans to generate zeroes (0s). Alternately TDO may be tied off to a one (1).

The Link Interface controls all pins associated with either a 2-pin or 4-pin interface. It allows the alternate use of the TDI and TDO pins with a 4-pin interface that is implemented but operated in 2-pin modes. It includes the super bypass bit used to create bypasses to instruction and scan data paths. The Link Interface function includes the following blocks: TMSC Input/Output, Super Bypass bit, Reset/Escape detection, Status generation, and Isolation logic used in assignment of Link IDs.

TMSC Input/Output is the control necessary to manage the JTAG and cJTAG use of the TMSC pin. The TMSC pin is used as an input in JTAG compatible modes but as an input and output in advanced mode. The Link interface uses directives generated by an JO state machine within the core to manage input and output.

The super bypass bit is a one-bit scan path that bypasses both the instruction and data scan paths when an adapter is not selected, and when the firewall is installed. The system TAPs are disconnected when the super bypass bit is the scan path.

The special relationships between TCK and TMSC creating Escapes, Soft Reset, and Hard Reset are detected by the Link interface. Escapes terminate Shift operations when TMS data has been deleted from shift state packets. Soft Reset allows an offline adapter to be placed online. Hard Reset initializes the Link, producing the same effects as adapter POR.

Status Information may be read when the link is operated in advanced mode. Status returns a byte amount of link state information followed by a byte identifying the adapter features supported, followed by custom information if desired.

Isolation information is used to identify the adapter that will be assigned a Link ID if Link ID assignment occurs. This information is output when no adapters are selected and the Link IDs assigned at adapter POR are invalidated by the debug software. The isolation process is the key to Link ID assignment. This process chooses a device for Link ID assignment using an approach similar to musical chairs. It uses a data register scan within the command window when no devices are selected to pick the winner of the isolation process. Initially the Capture_DR TAP state places all devices with an invalid Link ID in an “Invalid and Isolated” state, declaring all devices the winner of the contest for the Link ID. Each device is tasked with outputting a data pattern that is unique to it (isolation pattern). It does not matter what the data pattern is, it matters only that it be different than the pattern generated by other contestants.

The system interface is composed of: ID interface, A four-bit TAP State value, JTAG interface (TCK, TMS, TDI, TDO_D and TDO_OE), Reset Interface, Power Interface (optional), Ready Interface (optional), Test Interface (optional), BDX interface (optional), and CDX interface (optional).

The ID interface provides a means for the chip to inform the adapter of its JTAG device ID, less the revision number (27 bits) and a Node ID (4 bits). This information is used for Link ID assignment. The Node ID should be latched by chip POR from pin values and presented to the adapter.

The adapter exports a 4-bit TAP state of signals. The TAP state encoding is shown in FIG. 43.

The JTAG interface consists of TCK, TMS, TDI, TDO_D and TDO_OE. The adapter passes the pin values of TCK, TMSC, TDI, and TDO, if they exist, to the corresponding signals on the JTAG interface when the interface operates in standard mode. If TDI is not present on the Link interface, TDI is presented to the system as a one (1) during the Shift_IR TAP state and a zero at other times. The TDO_D and TDO_OE signals are either forwarded to the TDO pin if it exists or used to create TDO data embedded in advanced packets, depending on the interface operating mode. The TCK of the system interface occurs once for each Scan, BDX, or CDX packet. The TCK is held at a zero when an adapter is de-selected or a register write has caused a cJTAG interrupt upon entry, as a result of an interface mode change from standard to advanced or a register is being written while the interface mode is advanced.

The cJTAG adapter asserts the nTRST signal (not Test Logic Reset) to the system. This signal is connected to the nTRST signal of the system interface when nTRST is supported by the system interface.

The power interface allows a chip-level power and reset controller (PRC) to manage the adapter and Link Interface power requirements.

The ready interface provides a means for chip-level components to generate the stalls associated with advanced scan formats.

The test interface is provided to implement custom test capabilities using the extensibility provided by the adapter.

The Background Data Transfer (BDX) interface provides a connection to one or more BDX units external to the adapter.

The Custom Data Transfer (CDX) interface provides a connection to one or more CDX units external to the adapter.

The cJTAG core manages all aspects of the link. It is constructed from a number of state machines, counters, registers, register control, interrupt logic, and selection control. The major state machines within the adapter are: Command sequence state machine (CSEQ), Control state machine (CSM), Input/Output state machine (IOSM), and Transport state machine (XSM).

The command sequence state machine opens and closes command windows, detects Zero Bit Scan (ZBS) and determines the control level. This machine operates independent of the other machines, monitoring the TAP state to determine the control level. It awaits a ZBS when no control window is open. It then counts the number of ZBSs prior to a Shift_DR state to determine the control level. It closes the control window when the Select_IR or TLR state is encountered, or a certain command sequence occurs within the window. This machine provides control level information to the other three major machines.

The CSM, IOSM, and XSM jointly control the TMSC pin. They exchange control of the pin as the TMSC pin use changes. Only one machine controls the pin at any one point in time. Control is passed from machine to machine as shown in FIGS. 9 and 44. The CSM is an 8-state machine that manages: Power Down permissions, Operating mode, Interrupts generated by register writes, Online/Offline operation, and Delays between packets generated by the IOSM. The IOSM is a 32-state machine that manages: MScan formats, OScan formats, SScan formats, and Ready checks between transport packets needing ready checks

The XSM is an 8-state machine that manages: BDX packets, and CDX packets.

The CSM is the same for all cJTAG variations as it implements mandatory functionality. The IOSM is scaled depending on the scan formats supported. States are deleted as scan formats are not supported. The XSM and a small amount of additional logic (BDX in the figure) support the BDX function. The XSM and a small amount of additional logic (CDX in the figure) support the CDX function. The XSM is deleted if the CDX and BDX functions are not supported. The CDX and BDX logic is deleted if their respective functions are not supported.

The register control implements the control needed to manage the three standard adapter control registers: Link control, Scan control, and Transport control. The register storage is distributed throughout the consuming block so register bits associated with unsupported functions are deleted.

The select control implements a selection mechanism that can be used to choose one or more adapters for scan operations.

The cJTAG core includes several support functions: Shift_DR state counter, Clock counter, Not supported detect, TAP advance control, cJTAG interrupt, ID Assignment, and Shift_DR TAP State Counter.

The 5-bit Shift_DR TAP state counter is used to develop cJTAG control information. This information is derived from the number of TAP states spent in the Shift_DR TAP state since a Capture_DR TAP state occurred. This counter value is interpreted as STR and LTR commands when the Update_DR TAP state is reached. The 6-bit clock counter is used to detect interface timeouts and determine the length of one type of transport packet used by the BDX and CDX functions.

Not Supported Detect. This logic collects unsupported inputs from other blocks or acts as a surrogate for other blocks when these blocks are not implemented. This information is used to place the adapter offline when an unimplemented function is enabled by a register write.

TAP Advance Control. This logic determines when the system TAPs are issued a TCK, advancing their TAP state. The TAP advance is generated based on the actions taken by the IOSM, CSM, and XSM, as each reaches a point where the system and adapter TAP must be advanced one additional state. (A TCK is issued or equivalent thereof).

cJTAG Interrupt. Certain register writes (all in advanced mode and those changing the interface mode to advanced mode when it is in standard mode) stop the progression of Transport and Scan packets with the generation of an interrupt. This interrupt transfers control of the Link Interface to the CSM to manage link for a short period of time while interrupt processing completes.

ID Assignment. This logic determines when the Adapter's Device ID and Node ID have won the arbitration process associated with Link ID assignment. A link ID may be assigned to an adapter winning this arbitration. Once an adapter is assigned a Link ID, it no longer participates in the arbitration process, with another adapter winning the arbitration process. When the assignment process is repeated, all adapters have the opportunity to win the arbitration and subsequently be assigned a Link ID.

The Command Sequence (CSEQ) state machine conceptual view is shown in FIG. 45. The state progression of Closed Window (CW)>Potential Window (PW)>Detected Window (DW)>Active Window (AW) enables cJTAG command execution. The sequence can be terminated and the state forced to CW with either the Select_IR or TLR TAP state. The Shift_DR TAP state forces the state to CW when the state is PW. A STR command that is not preceded by a LTR command forces the state to CW when the state is AW. The Update_DR TAP state increments the control level in either the PW or DW state. cJTAG commands are decoded only in the AW state.

The CSEQ state machine is implemented with a Flip-Flop and a control level counter. It uses the state encoding shown in FIG. 46. The most significant bit (MSB) of the state encoding shown in FIG. 47 is derived from the control level counter value. A counter value other than zero represents a one while a counter value of zero represents a zero. The least significant bit (LSB) of the state encoding is represented by the Capture Last Flip-Flop state.

The TAP state sequences detected by the command sequence state machine as a ZBS are shown in FIGS. 6A and 6B. In the case where the Pause_DR state is included in the sequence, a stay in the Pause_DR state of any number of clocks is permissible. Note a command window, once opened, is closed when the Select-IR-Scan or Test-Logic-Reset TAP state is encountered. A command window, once opened, is allowed to remain open unless closed by a software controlled command sequence.

A ZBS may begin in one of three CSEQ state machine states (CW, DW, and AW).

When a ZBS begins in the CW state a command window is opened with the control level set to one (see FIGS. 48A, 48B, 49A, and 49B). When a ZBS begins in the DW state, the command window remains open and the control level is incremented if the control level has not reached its maximum value. When a ZBS begins in the AW state, the control window remains open, the control level remains the same, and the ZBS is interpreted as a cJTAG command.

The command sequence state machine opens and closes command windows, detecting ZBS and determining the control level. This machine operates independent of the other machines, monitoring the TAP state to determine the control level. It awaits a ZBS when no control window is open. It then counts the number of ZBSs prior to a Shift_DR state to determine the control level. It closes the control window when the Select_IR or TLR state is encountered, or a certain command sequence occurs within the window. This machine provides control level information to the other three major machines.

The machine notes a closed window, potential window, detection of the window, and activation of the window. cJTAG commands are enabled once the command window is activated. The window is closed when any of the close conditions occurs.

The signaling and electrical characteristics of the TCK pin are the same for the standard and advanced modes. This pin supports a pull-up and is used as the interface clock in both modes. There are two options for sourcing TCK. The TCK terminal may be: Supplied by the DTS to the TS, or Supplied by the TS to the DTS. These options are shown in FIG. 50. A system configuration with DTS-sourced TCK provides a transfer bandwidth as much as 50% larger than a configuration with a TS-sourced TCK. More link optimizations are available for use when the DTS supplies TCK. These configurations are compared in FIG. 51. The DTS treats cases (b) and (c) the same, as it cannot tell the difference between the two cases.

The Test Mode Select Compact (TMSC) pin functions as an input buffer, an output buffer, and a keeper. The TMSC pin is input only in standard mode, with the keeper forced to operate as a pull-up. The pin becomes bi-directional once the interface operating mode is changed to advanced, with the keeper maintaining the value last driven on the pin. Advanced protocols define the TMSC drive configuration on a clock-by-clock basis. The advanced mode uses four TMSC pin drive configurations:

An input—no drive with a keeper configured to maintain the last driven pin value

Drive high only—output buffer drives high, multiple sources may drive high, with a keeper

Drive low only—output buffer drives low, multiple sources may drive low, with a keeper

Drive high or low—output buffer drives high or low, single source may drive, with a keeper

These configurations are independent of the I/O voltage level. Drive high only and drive low only support simultaneous data output by multiple devices.

The Test Data In (TDI) and Test Data Out (TDO) pins are optional. They are included for a wide interface and deleted for a narrow interface. When a wide cJTAG interface operates in advanced mode, the TDI and TDO pins may be assigned to other debug functions. Reallocating these pins is important for maximizing the number of pins available for debug instrumentation and is especially important for chips that deploy pin-hungry debug functions such as Trace.

A Test Reset (nTRST) pin may be added to either the narrow or wide interface configurations. Since a TS holds its nTRST pin high with a pull-up, debug and test logic is not reset by this pin when the DTS is not connected to the system.

A boundary compliance enable (BCE) pin may be added to either the narrow or wide interface configurations. This pin provides failsafe operation, as test and debug logic is always held in test reset. Since a TS holds its BCE pin low with a pull-down, all TS TAPs are asynchronously forced to the TLR state when the DTS is not connected to the system. This pin may be viewed as having the functionality equivalent to the nTRST function, but with a low, true default value (on-chip pull-down when there is no connection to the chip). When devices with nTRST and BCE are used in a system, BCE and nTRST should not be directly connected unless they are continuously driven by an output.

Both the BCE and nTRST active states asynchronously initialize the TAP to the TLR state. Their assertion forces the interface operation to standard mode and creates the same state as a POR internally applied to the adapter. These signals have no affect if the interface is powered down.

The TCK and TMS drive characteristics are shown in FIG. 52.

The TS drive of the TMSC pin is shown in FIG. 53. Data is driven during the first half of the bit period (only when TCK is low) and held at the driven value by the keeper during the remainder of the bit period. This arrangement allows the overlap of data transmission and bus turnaround. These signaling characteristics maximize the Link bandwidth. The DTS may block the TS from driving TMSC by holding TCK high.

The DTS drive of the TMSC pin in advanced mode may use one of two drive options: Only when TCK is low (follows the same drive rules as the TS), and For the entire bit period when scheduled to drive the next bit period. Drive restricted to the only when TCK is low option is shown in FIG. 54. Drive using both options is shown in FIG. 55. This provides a means to force the interface standard operating mode by holding TCK high and toggling TMSC to reset the Link. It is permissible for the TS and DTS to drive the TMSC pin, provided they both drive the pin to the same value. This is called for by advanced protocol. For instance, the protocol allows the TMSC pin to be driven to a one (1) by both the TS and DTS when it is part of the MScan format.

The MScan format allows the TMSC pin to be driven by one or more sources. A single data value is transferred from the TS to the DTS using 2-bit periods. The TMSC pin is driven to a one (1) (pre-charged) by the DTS and TS during clock period n. During clock period n+1, the TMSC pin is driven to a zero (0) (discharged) only by those TS sources desiring a data value of zero (0). The DTS and TS sources that desire a data value of one (1) for this clock period do not drive the pin. The combination of the pre-charge, the keeper, and the discharge supports transfer of both ones (1s) and zeroes (0s) and the wire ORing of data from multiple TS sources. This is important for Link ID assignment. Should a single TMSC source be present, this mode can pass data to the DTS just as well as if TMSC was driven both high and low by the TS.

The TCK edge that samples TMSC input to the TS is programmable to either a rising or falling edge. POR sets the data sampling to rising edge. This assures the data is driven when it is sampled, but has the disadvantage of only allowing half a clock to propagate data between the DTS and TS. The sampling edge may be changed via the Link control register while the interface is operated in standard mode before there is a dependence on this setting (rising edge is always used in standard mode). Rising edge sampling improves Link Interface noise immunity while falling edge sampling substantially improves bandwidth. The debug software must comprehend the reduced operating frequency when rising edge sampling is used.

The link timing characteristics always allows the link operating frequency to be lowered to a point when the link becomes functional. The maximum operating frequency is governed by one of four factors:

Timing that provides no drive overlap when DTS drives followed by the TS driving

Timing that provides no drive overlap when TS drives followed by the DTS driving

Meeting setup and hold time when the DTS supplies data to the TS

Meeting setup and hold time when the TS supplies data to the DTS

The timing parameters associated with these factors are defined in FIGS. 56-60.

In summary, the maximum TCK period is the larger of the values generated by the following equations when the right half of the equation is positive.

Tperiod>=(TTS_D+TDTSsu)+2(Line Delay);

Tperiod>=(TDTS_D+TTSsu);

Tperiod>=2(TDTS_z−TTS_D);

Tperiod>=2(TTS_z−TDTS_D);

For instance, if DTSD and TSD are 6 ns, DTSsu and TSsu are 3 ns, and the line delay is 0.5 ns, Tperiod is 10 ns.

The use of the TDI and TDO pins for debug functions other than their JTAG functions is subject to a hardware interlock. This interlock takes effect when the Scan Control register indicates an impending change to the operating mode. The assignment of these pins to functions other than the TDI and TDO functions may take place after these pins are no longer performing their TDI and TDO functions. These pins are reallocated to their TDO and TDI functions before they begin performing their TDI and TDO function.

The change in pin function occurs when a mode change is specified by the scan control register. Since debug software takes control when these events occur, it notifies functions sharing these pins in the proper sequence. It shuts down functions using these pins before notifying cJTAG to change to a standard interface. It starts these functions after advanced mode has been entered.

A hardware interlock insures there is never a failure of basic debug communication or a drive conflict between the DTS and TS because of the alternate use of these pins. A failure of debug software to coordinate the secondary use of these pins with switches between standard and advanced modes, results in the failure of the alternate function assigned to the pin, but cannot cause a debug communication failure. These interlocks are shown in FIGS. 61 and 62.

Power Control

The cJTAG architecture supports power down of the majority of the cJTAG interface. Power down is controlled by logic external to the adapter. This logic is called the Power and Reset Controller (PRC) in this document.

The increased emphasis on minimizing power consumption is an important consideration for the cJTAG architecture as both board and chip power domains are included. In the extreme, devices' debug and test interfaces (DTI) may even be powered-down. It is expected that cJTAG-enabled devices may be deployed in systems that have some or all of the following power characteristics: Board power domains (all devices on board are not always powered), Devices sharing power domains, Devices in different power domains, and Mixes of power domains may be powered. The cJTAG system allows the debug of systems with these characteristics. Different I/O voltages cannot be connected and devices in different power domains may be turned off independently. Global control of debug actions requires the connection of devices in different power domains and with different I/O voltage levels to separate DTS ports as shown in FIG. 63.

The cJTAG architecture provides facilities to manage multiple ports and perform synchronized operations across these ports. The different DTS/TS configurations and characteristics are supported with four power-down modes. The TCK behavior (free running or gated) or TCK source (DTS or TS) play a role in the DTS selection of a power-down mode.

Four power-down modes are created from two power-down criteria: a test logic reset (TLR) TAP state with standard mode, and absence of a TCK falling edge within a one millisecond period. These four modes are listed below:

Mode 0—No power down allowed,

Mode 1—Allow power down in standard mode when the TLR state is reached and power down is requested,

Mode 2—Allow power down standard mode when TCK has remained high for a minimum of 1 millisecond, after reaching the TLR state, and

Mode 3—Allow power down in standard or advanced mode when TCK has remained high for a minimum of 1 millisecond in any TAP state.

A chip may implement one of four combinations of these modes as shown in FIG. 64.

The power-down behavior of the adapter is defined with the cJTAG control register. The implementation is very straightforward, as writes to the control register may only occur when none of the power-down criteria are met. An adapter reset that initializes the control register sets the power down mode to Mode 1. Specifying an unimplemented mode through the control register produces the same behavior as Mode 0.

Powering Up an Un-powered Adapter. A continuous low value on the TMSC pin notifies the PRC of the partial reconfiguration power requirement that the adapter and debug and test interface (DTI) must be powered. When the TMSC pin is asserted low for a minimum of 1 ms, the PRC is required to:

Power the DTI,

Reset the adapter with POR,

Remove the PRC power-down request to the adapter, and

Allow TCK to clock the adapter.

The cJTAG TAP becomes operational after these occur. Initialization of the interface places the TAP in the TLR state. Once the interface is released to operate, the TMSC input, already low, moves the TAP state to the IDLE state where it remains as long as TMSC remains low.

Power-Down Models. The adapter combines two power-down models; the first supporting Modes 0 and 1 and the second supporting Modes 2 and 3. The first, called the “affirmative response” model (AR), assumes TCK is running when a request to power down the adapter is made and possibly when power down occurs. The second, called “non-response” model (NR), assumes TCK is not running when power down occurs. With both of these modules the PRC must receive permission from the adapter before powering down the adapter or the Link Interface.

With the AR model, the PRC requests permission to power down the adapter. The adapter generates a power-down acknowledge when the power-down criterion are met. Before generating the acknowledge, the adapter performs an orderly shutdown of the JTAG interface, signaling the PRC when the shutdown is completed. Since the PRC requests permission to power down and the adapter generates the acknowledge when its response to the request is completes, the process is given the name AR.

When the TAP state reaches TLR and a synchronized power-down request is asserted (in either order), the following occurs:

TMS is set to a one (1) at the JTAG interface and the TMSC pin is ignored

One additional TCK occurs at the JTAG interface

The interface state moves to Power Down

pd_ack is asserted

A pictorial view of the AR model operation is shown in FIG. 65.

With the NR model, the PRC generates an event that may generate a power-down acknowledge (pd_ack). The adapter is responsible for generating a corresponding event to negate pd_ack within a fixed amount of time. This approach handles options 3 and 4, FIG. 66, where TCK is not running, as an adapter clock is required to negate pd_ack. In this model, the PRC sends a signal (time_base) to the adapter that toggles with a period that is ½ the TCK inactivity period (>=1 ms) needed to generate pd_ack. The adapter qualifies pd_ack using a delayed version of the time_base XORed with time_base.

The adapter changing the state of time_base may generate a pd_ack. The adapter has from one edge of time-base until almost the next edge of time_base to negate pd_ack. If the time_base signal changes without a corresponding change in the adapter's copy of the signal by the time the PRC is ready to change the state of time_base again. TCK has been inactive for a sufficient period of time to meet the power-down criteria for Modes two and three. The PRC merely samples acknowledge prior to changing the state of time_base, using this value as the adapter's acknowledge when this type of signaling is used.

The Adapter's power control (PRC) interface is shown in FIG. 67. The power-down request (pd_req), power-down acknowledge (pd_ack), and time-base (time_base) signals need little further explanation. The PRC initializes the adapter with the power-on-reset (por) signal during and after power up. It may use por to hold the adapter in its initialized state. The power-down non-responsive (prc_pd_nr) signal informs the PRC whether pd_ack behavior is affirmative or non-responsive. Since the programming of the adapter power-down down mode occurs when power-down criteria are not met, changes in this signal occur when pd_ack is negated. Adapter resets cause the simultaneous assertion of pd_ack and negation of prc_pd_nr.

Examples of AR and NR sequences are shown in FIGS. 31 and 32. In the AR case, the interface operation moves to a special state called Power-Down (PD) coincident with the assertion of pd_ack. The adapter will remain in this state until the interface is powered down or synchronized when pd_req is de-asserted. The Chip Power and Reset Controller (PRC) is free to reset and power down the adapter once pd_ack is asserted. When PRC powers down the DTI, the TMSC buffer remains powered as it is used to request power-up. The TCK buffer may be powered down.

In the NR case, the JTAG interface TAP state may be TLR in the case of Mode 2 or any state in the case of Mode 3. The prc_pd_nr signal is a one (1) when either of these modes is used. The PRC cannot use pd_ack without sampling it just prior to changes in state of time_base.

PRC Responsibilities. The PRC may:

Implement no power-down facilities. In this case, the adapter and cJTAG interface will remain operable while any portion of the chip remains powered;

Implement only Option 1. In this case, the adapter and cJTAG interface:

- will tie off the time_base signal to either a one (1) or a zero (0),
- will implement pd_req and pd_ack,
- will make the adapter operable when TMSC is held low for the prescribed period,
- will keep the TMSC input buffer powered,
- may power down the TCK input buffer,
- may treat the pd_ack signal as always valid, and
- may ignore the pd_nr signal.

Implement only Options 2 and 3. In this case, the adapter and cJTAG interface:

- will tie off the pd_req signal to a zero (0),
- will implement time_base and pd_ack signals,
- will make the adapter operable when TMSC is held low for the prescribed period,
- will treat the pd_ack signal as valid just before it changes the state of time_base,
- will keep the TMSC input buffer powered,
- may power down the TCK input buffer, and
- may ignore the pd_nr signal.

Implement Options 1, 2, and 3. In this case, the adapter and cJTAG interface:

- will tie off the pd_req signal to a zero (0),
- will implement the pd_req, time_base, and pd_ack signals,
- will make the adapter operable when TMSC is held low for the prescribed period,
- will do one of the following:
  - Ignore the pd_nr signal and treat the pd_ack signal as valid just before it changes the state of time_base,
  - Use the pd_nr signal to define the behavior of the pd_ack signal;
    - If ‘1’, pd_ack is valid just before it changes the state of time_base, or
    - If ‘0’, pd_ack is valid any time it is asserted,
- will keep the TMSC input buffer powered, and
- may power down the TCK input buffer.

Link Protocols

Three protocols are used to manage cJTAG capabilities: Command sequences, Escape sequences, and Packet sequences. One or more of these protocols is used to deliver cJTAG capability.

Command Sequences. Data register scans are used to broadcast command sequences to the DTS and all TS adapters. The method used requires no knowledge of: Instructions supported by the chip TAPs (JTAG op-codes), DR or IR scan path lengths, Chip identification numbers, or Any other piece of scan topology information. These sequences control adapter operation in either standard or advanced modes using only the TCK and TMSC pins. Sequences are the same for all operating modes, wide and narrow interface configurations, and all scan formats.

Command sequences change the cJTAG operating characteristics by assigning cJTAG-specific functionality to DR Scans performed within command windows. Command windows are cJTAG control levels above the current JTAG instruction register/data register control level. Command windows are opened in an identical manner in either standard or advanced cJTAG modes. This approach makes cJTAG compatible with all JTAG conforming systems in place today.

A cJTAG control level is, in a hierarchal sense, above the instruction and data scans used to manage the TS state. It simultaneously broadcasts the cJTAG commands to the DTS adapter and its TS adapters, requires no knowledge of the connection topology on the DTS side of the TS adapter, requires no knowledge of the scan topology on the system side of the TS adapter, does not affect the TS state, and uses data register scans and inert instructions such as BYPASS.

Command windows (CWs) are opened with a novel use of the JTAG state diagram. Zero-bit, data register scans (ZBS) are used to set the control level. A ZBS is any TAP state sequence that starts with the Capture_DR state, ends with the Update_DR state and does not include the TLR or Shift_DR state. The number of consecutive ZBSs prior to Shift_DR TAP state entry defines a specific control level with the control level beginning at zero (0). Once the Shift_DR TAP state is entered, the control level is locked and additional ZBSs cannot change the control level while the CW is open as shown in FIG. 7. CWs are closed by the TLR and Select_IR TAP states. A CW is also closed by the various cJTAG resets or a command sequence designed to close the CW. The IR should be loaded with an inert instruction prior to setting the control level. This step may be deleted if beginning from a TLR state.

Once the control level is locked, DR Scan activity performs functions associated with the level. The functions at each level may be similar or different as shown in FIG. 8A. The number of control levels supported is up to the implementer but shall not be less than seven.

The first five control levels are allocated to cJTAG functions while all levels above these are private control levels. Unused private levels assign no functionality to DR Scans. Level 1 supports the use of DR Scans for CDX, if the advanced mode is being used and the CDX function has been previously enabled. Control Levels 2 and 3 support cJTAG control register changes. Level 2 permits cJTAG output while the Level 3 does not. In this case, TDO is HI-Zed in standard mode and the TS data is always a one in advanced mode. The function of chip adapters may be customized using private levels. The DTS may use any public or private control level not used by all adapters connected to the Link.

Private control levels may use DR Scans to convey information to the TS and return data to the DTS. It shall not alter the link state sequence being used at level zero (0). An enable bit shall be implemented in a cJTAG control register qualifying the use of a level by any chip function. This allows sharing of levels by many chips and prevents accidental activation of these functions. Private levels may be used in standard mode, advanced mode, both modes, or not used at all.

An inert op-code (e.g., BYPASS or IDCODE, etc.) must be placed in all instruction registers prior to opening a CW to ensure DR Scans within a CW are treated as no operations (NOPs) by the TAPs connected to the adapter JTAG interface. An inert op-code is placed in the instruction register by the TLR state or by an instruction register scan. The TLR case simplifies cJTAG management from startup, as a command window may be opened without an IR Scan. At other times, the DTS software must place an inert op-code in the JTAG instruction register of all TAPs connected to the adapter before it opens a CW.

cJTAG control registers manage all programmable cJTAG attributes. These registers are initialized by POR and subsequently accessed with data register scans in either standard or advanced modes. The Link operating characteristics are changed by writes to these registers once a command window enabling these writes is reached. The cJTAG control registers are changed concurrently in both the DTS and the TS.

A novel way of generating the cJTAG data used is to write cJTAG control registers that support broadcast of commands to multiple cJTAG interfaces, using the length of a data register scan to create data as opposed to actual scan data. A scan counter, zeroed by the Capture_DR state and incremented each Shift_DR state, determines the length of the data register scan. The five LSBs of the scan count are used as data. Since the length of the scan is conveyed solely by the TMS value, the DTS adapter and all TS adapters receive this information simultaneously, making command broadcast independent of the scan topology of the TS.

cJTAG control registers are read or written using the load temporary register (LTR), see FIG. 8B, and store temporary register (STR) commands. These commands use the 5-bits of data in combination with the Update_DR TAP state. Data values of 16 or greater generate a LTR command, while data values less than 16 generate an STR command. The LTR command loads a temporary register with the four LSBs of the count when the Update_DR state is reached. Data values less than 16 generate a STR command when the Update_DR state is reached, loading a cJTAG control register with the TEMP register value or performing another action. In this case, the four LSBs of the count specify the command or action as illustrated below:

embedded image

An STR command must be preceded by an LTR command for command execution for the STR command to occur. An STR command not preceded by an LTR command closes the command window with the STR command ignored.

A typical change of a single control register value is shown below:

ZBS(2)

LTR—Shift_DR (length=16+temp data)

STR—Shift_DR (length=command)

STR (ZBS)—closes command window, or close with the TLR or Select_IR TAP state.

The first two ZBSs set the control level. The first Shift_DR state of the LTR locks the control level at two. The LTR command loads the TEMP register. The STR command dispositions the TEMP register. The last STR or an IR_scan closes the command window. A ZBS can be used for the STR command.

The cJTAG commands also provide command sequences to read cJTAG status and other information. Additional commands are reserved for cJTAG expansion, test, and DTS use. Test commands provide a means to implement chip-specific test capabilities. Controller-specific functions such as basic link management (clock source determination, reading pin values, port selection, clock management and the like) totally within the cJTAG architecture may be implemented using DTS commands. Multiple DTS ports, and global commands sent to multiple chips or multiple DTS ports are all comprehended by this control mechanism. More sophisticated functionality, such as the DTS management of the power up and down of multiple TS cJTAG interface(s), is comprehended by this control mechanism.

Escape Sequences

Escape sequences, see FIG. 17, are DTS control information generated using a special relationship between the TCK and TMSC. The DTS may generate escape sequences, if and only if, it sources TCK while the TS detects and applies them.

All escape sequences are generated using the same protocol. The DTS generates an escape sequence by stopping TCK high and then creating a number of TMSC pairs. The number of times the TMSC pin is toggled (in pairs) while TCK is high determines the escape sequence. Zero or one edge is ignored. More than one edge generates one of the escape sequences shown in FIGS. 17 and 68.

The number of edges is n or n+1 because one edge may be generated by a normal TMSC transition while TCK is high. Since a normal TCK edge may or may not be generated for a specific TCK period, or may occur while TCK is low or TCK is high, this edge may or may not be counted. The edges created by the DTS after it has forced TCK will be counted. The adapter accounts for this uncertainty by assuming an even and odd edge count are equivalent.

The End-of-Transfer escape sequence is used to end certain scan, BDX, and CDX transfers. The most efficient transfer encoding uses End-of-Transfer escape sequences to terminate: Shift operations, Scan segments, BDX, or CDX transfers. An End-of-Transfer escape sequence is automatically generated by link activity terminating these cases. This escape sequence is ignored unless the adapter interface is operation in advanced mode and the adapter state expects it.

The Soft-Reset escape sequence is used to place an offline adapter online. This escape sequence is ignored unless the adapter interface is operating in advanced mode and is in a state that expects it. It places devices in the JTAG compliant mode, de-selects all adapters, and closes an open command window without initializing other aspects of its configuration. Soft-Reset escape sequences are accepted: Immediately after a register write, provided the operating mode is advanced, or Anytime, if the cJTAG adapter has been placed offline by enabling an unsupported feature.

The DTS shall generate a soft reset: With a register write to a DTS control register in advanced mode, While the operating mode is advanced, or Expecting an operating mode to change to advanced with JTAG compliant operation following the register write.

A Hard-Reset escape sequence provides a functional equivalent to nTRST or BCE. It asynchronously changes the system state in either the standard or advanced operating modes. This escape sequence is recognized and used if it is detected between any two TCK falling edges or from POR when TCK is always held high. This means it may be generated every bit period independent of the adapter state and whether a Hard Reset occurred during the prior bit period. It is never ignored.

An escape sequence is superimposed on TMSC activity. One or no TMSC edges may be generated by the TMSC value in a bit period bounded by two falling TCK edges by normal TMSC activity before the escape sequence generation begins. An edge generated by normal TMSC activity may occur while TCK is low or after TCK has gone high. This is the reason at least two edges must be detected while TCK is high and either an even number or odd number of edges are treated the same.

An escape sequence is generated when the DTS: Drives TCK low, Drives the TMSC pin with TCK low to the TMSC bit value for this period, Drives TCK high, Drives the TMSC pin to the inverted data value of the initial TMSC data no sooner than the edge would have been generated if it were the DTS value sourced for the next TCK period, Drives the TMSC pin to the initial data value no sooner than the edge would have been generated, if it were the DTS value sourced for the next TCK period, Two previous steps are repeated to create the proper escape type, if necessary, Drive of the TMSC pin is stopped, with the keeper holding the pin value, Leaves the TMSC pin value at this state for the required period (1 TCK period at Max. Freq.), and Restarts normal TCK and TMSC pin activity

The end-of-transfer and soft-reset escape sequences interact with the adapter in a synchronous manner. The hard-reset escape sequence interacts with the adapter in an asynchronous manner.

An escape sequence combined with TS output is shown in FIGS. 17 and 69. In this case the: Clock is driven low by the DTS, TS drives the TMSC pin with TCK low, Clock is driven high by the DTS, TS drive of the TMSC pin is stopped, with the keeper holding the pin value, DTS then reads the TMSC pin value, DTS drives the TMSC pin to the inverted data value it just read, DTS drives the TMSC pin to the non-inverted during the following period, Two previous steps are repeated to create the escape type, if necessary, DTS drive of the TMSC pin is stopped, with the keeper holding the pin value, DTS leaves the TMSC pin value at this state for the required period (1 TCK period at max. freq.), and DTS restarts normal TCK and TMSC pin activity.

Note that both the input and output escape sequences provide a one clock period where the last TMSC value is stable so that there are no setup-timing considerations for this operation. An escape sequence, when TCK is being held high, is shown in FIGS. 17 and 70.

The DTS will: Generate pairs of edges beginning from the signal level last driven on the TMSC pin, Return the TMSC pin to the level that was on the pin prior to generation of the escape sequence, Assure the TMSC pin is at the same level for the time equal to one TCK period of the maximum Link operating frequency before generating a TCK falling edge following the escape sequence.

Commands and Registers

Link operation is managed with the commands listed in FIG. 8 and the three control registers listed in FIG. 71. The control facilities are usable in either standard or advanced mode. Certain aspects of Link operation, such as the TCK source, are defined by the target system. The predefined commands manipulate various bits of the predefined registers (LINK_CNTL, SCAN_CNTL, and XPORT_CNTL).

Commands sequences are used to: Configure the Link, Specify the scan format, Specify the transport format, Select and de-select adapters whose IEEE 1149.1 interfaces are active, Select an adapter or BDX transfers, Enabling and disabling BDX and CDX transfers, Assignment of Link IDs, Invalidation of Link IDs, Defining the power attributes of the interface, Defining the data transfer characteristics of the interface, Implement custom chip functions, Implement DTS functions, and Broadcast and Targeted Commands. Most commands are broadcast to all adapters. Examples of this are commands specifying the scan and transport formats. Other commands such as those that select adapters are seen by all adapters but select an adapter of interest.

The LTR command part of the command sequence carries the Link ID of the adapter of interest when a command is intended to apply to a specific adapter. The STR part of the command sequence specifies the command action.

There are three command classes: Assigned, Reserved, and Extended. Assigned commands perform basic cJTAG functions and have fixed functionality. Reserved commands have no operations and may be defined in future cJTAG specifications. Extended commands provide customization of the cJTAG interface. Unimplemented command sequences are no operations.

The extended command provides customization for: Future cJTAG extensions, Adapter specific Test and Debug capability, and DTS capability.

Four extended commands (EXC0, EXC1, EXC2, and EXC3) are available along with sixteen command pages. The four commands apply to the extended command page specified by an extended command page register (LECP command). This provides a total of 64 commands.

Allocating extended commands resource to the DTS makes managing the host and target sides of the interface easy. They appear to share the same register space, with actions occurring precisely at the same time in each interface. This provides a means for a DTS to: Manage multiple ports, and Interrogate the interface characteristics at start-up. The cJTAG commands are further described in FIG. 72.

The formats for the Link Control, Scan Control, and Transport Control Registers are shown in FIGS. 73, 74, and 75. The control registers are write-only although the architecture provides for implementing reads as an unspecified option. These register may be written: When the link is operated in either standard or advanced mode, In the command window using the same command sequences in either interface mode, and In Both TS and DTS. Both the DTS and TS parts of the Bridge contain a set of common registers. These register are: Initialized at the same time, and Loaded at the same time. This provides synchronized DTS and TS operation. Additional registers may be implemented unique to each chip or in the DTS as the reserved register space permits.

In FIG. 73, the M stands for mandatory; the A stands for deleted if multi-drop communication is not supported; the B stands for may be deleted if interface always remains powered; the C stands for may be deleted; and the D stands for may be deleted. In FIG. 75, the M stands for mandatory; the A stands for deleted if no BDX or CDX; the B stands for deleted if no BDX; and the C stands for deleted if no CDX. If both BDX and CDX are not supported, the Transport Control Register is replaced with one bit that is loaded with Logical Or of both enables. This bit, when set, indicates a non-supported but enabled feature and causes the adapter to be placed offline.

The control registers are initialized following the assertion of: POR, BCE or nTRST low, CRES—Hard-Reset escape sequence, CTO—Link Timeout (failure to maintain an interface heartbeat during protocol stalls), and CDIS—Link Disconnect (TMS delivered as a one or two consecutive scan packets with advanced mode and TLR TAP state)

The Link Control register is detailed in FIG. 76. The Scan Control register is detailed in FIG. 77. The Transport Control register is detailed in FIG. 78.

Control Register initialization creates the following attributes: Standard operation with or without firewall, BDX is disabled and not selected, CDX is disabled, Initial configuration selects device based on firewall, Link ID set to 0x0 and valid, Data sampling is set to the TCK falling edge because CC[1:0] is reset to 00 at POR, and Debug interface powers down in TLR TAP state unless TMSC is held low.

Extended (private) registers may be added and referenced via the extended command page (ECP[3:0]). Extended commands are available to manage these registers. The control registers are programmed using the same sequences in standard and advanced modes. An inert instruction such as BYPASS must be placed in the instruction register before opening a scan window.

A command sequence materially affects the system configuration as viewed from the Link interface. A command or command sequence is used to cause a system action. Commands are constructed from a combination of an LTR command followed by an STR command. Single STR commands are not used as this does not provide failsafe hot-connect protection and would consume commands rapidly.

A command sequence is created with a LTR/STR command combination:

LTR Command—A data register scan of all ones (1s) or other data,

- n bits in length where n=0x10|(Payload & 0xF),
- Ending in the Pause_DR TAP state,
- Subsequent progression through the Update_DR TAP state (a completion sequence),
  - Without progression through the TLR TAP state,
  - Routinely created by the following command,
  - If SOA, the bit is not set,
- Temp register noted as loaded

STR Command—A data register scan of all ones (1s) or other data,

- n bits in length where n=Store command & 0xF,
- Ending in the Pause_DR TAP state,
- Subsequent progression through the Update_DR TAP state (a completion sequence),
  - Without progression through the TLR TAP state,
  - Routinely created by the following command or command activation,
  - Action occurs if preceded by LTR command, other-wise the command window is closed,

Commands are decoded for control level two or three. An LTR followed by an STR command causes an action. A few common actions are shown below:

Disable Firewall: IR_Scan with Bypass Instruction, ZBS, ZBS, LTR (DR_SCAN (JSCAN0+16) bits), STR (DR_SCAN (SSF command) bits), and IR_Scan (Bypass Instruction).

Change to OScan7 format: IR_Scan (Bypass Instruction), ZBS, ZBS, LTR (DR_SCAN (OSCAN7+16) bits), STR (DR_SCAN (SSF command) bits), and IR_Scan (Bypass Instruction).

More than one action can be generated within a command window as shown in the three action cases shown below:

IR_Scan (Bypass Instruction)

ZBS

LTR (DR_SCAN (Temp_data+16) bits)

STR (DR_SCAN (command) bits)

LTR (DR_SCAN (Temp_data+16) bits)

STR (DR_SCAN (command) bits)

LTR (DR_SCAN (Temp_data+16) bits)

LTR (DR_SCAN (command) bits)

IR_Scan (Bypass Instruction)

ZBS within Control Level

If the control level is non-zero, a ZBS is interpreted as a Store Control Action (SCA) command. The SCA command is used to: Clear all scan pre-selections (PS[1]=0), Clear the BDX transport selection (BS=0), Load the two-bit Clock Control (CC) field (CC[1:0]), Load the two-bit Power Control (PC) field (PC[1:0]), and Load the two-bit Delay field (DL[1:0]). The SCA command causes the above actions when the appropriate bits are set in the TEMP register.

A Make Scan Selection (MSS) command pre-selects a device for scan. The MSS command sets the PS[1] bit when the: LID field is valid, LID field equals the TEMP value, and TAP Update_DR state occurs. If the above conditions are not met, the PSS bit remains in its current state.

A Make Transport Selection (MTS) command selects a device for a BDX transfer. The MTS command sets BS when the: LID field is valid, LID field equals the TEMP value, and TAP Update_DR state occurs. If the above conditions are not met, the BS bit is cleared.

A Store Link ID (SLID) command assigns a Link ID to a device if the device is isolated, no devices are pre-selected, and the advanced mode is selected.

An Invalidate Link ID (ILID) command invalidates the Link ID if it either matches TEMP or (PSCS[1]=0). It also clears the PS[1] bit and sets PSCS[1:0] to “01”.

A Store Transport Format (STF) command moves TEMP[3:0] to TF[3:0].

A Store Scan Format (SSF) command moves TEMP[3:0] to SF[3:0].

A Read Status or Serial Selection (SRS) command performs two different functions depending on the interface operating mode: Standard—Designating the next data register scan as transferring serial pre-selection data, and Advanced—Reading the Node ID and other status data.

A Load Extended Command Page (LECP) command loads the extended command page. The four-bit command page is shown in FIG. 79. The four extended commands may store four 4-bit page specific values.

A Read Extended Command Page (RECP) operates like the SRS command. In advanced interface mode the RECP command causes the device whose Link ID matches TEMP to output the scan path specified by the extended command page. This path is serially scanned out, with the LSB output first.

Extended Commands (EXE#) (EXC0, EXC1, EXC2, and EXC3) are associated with a page and may be defined differently for each page. These commands afford the cJTAG user the opportunity to add customs test or debug functionality to the cJTAG interface.

TS reserved cJTAG commands are to be defined. These commands are treated as NOPs and may not be used by the DTS or TS conforming to this specification revision.

Assert TRST (ECP=0) & (EXC0) & Temp=0bxx01 De-assert if Temp !=0bxx01

Assert FLAT<=(ECP=0) & (EXC0) & Temp=0b10xx De-assert if Temp !=0b10xx

All reset events de-assert these signals.

An example of how test/debug commands could be implemented is shown below. This is merely an example and is not part of the cJTAG specification. The Test Commands require a specific 4-bit value and the extended command code to cause an action.

TRST Assert if (ECP=1) & (EXC0) & Temp=0bxx01 De-assert if Temp !=0bxx

TEST_SEL Assert if (ECP=1) & (EXC0) & Temp=0b10xx De-assert if Temp !=0b10xx

Test Func 2 Assert if (ECP=1) & (EXC1) & Temp=0bxx10 De-assert if Temp !=0bxx10

Test Func 3 Assert if (ECP=1) & (EXC1) & Temp=0b01xx De-assert if Temp !=0b01xx

All reset events de-activate these functions.

Extended Command Pages (ECP[3:0]) provide a means to extend cJTAG functionality in subsequent specification revisions and add custom chip and DTS registers and commands. Some extended command pages are pre-defined and others are reserved as shown in FIG. 79. The extended command page functions are disabled so as to not affect the operation of system TAPs, system test logic, or cJTAG interface after any reset event initializes the control registers. The only exceptions to this are test modes that change the chip operating mode to private operation where pin functions or other capabilities are modified. A POR shall always return chip operation to a state where cJTAG and the system to which it attaches are fully operable to perform each and every function available via the Link.

Link ID (LID[4:0]) is used to: Identify an adapter in a cJTAG Star configuration, Note that a Link ID has not been assigned to an adapter, and Identify an adapter that has been chosen for Link ID assignment. The Link ID encoding is shown in FIG. 80.

Clock Control (CC[1:0]) bits inform the adapter about the clock source (CC[0]) and TCK edge used to sample TMSC (CCM). The DTS determines the TCK source and then informs the adapter of its determination before switching to an advanced mode. The adapter takes actions to use scan formats compatible with a DTS supplied TCK, as the use of a TS supplied TCK prevents the use of escape sequences.

The sampling of the TMSC pin by the DTS and TS in advanced modes is controlled with CC[0]. Sampling may be programmed in the middle or end of the bit period. Sampling in the middle of the bit period assures the TS samples the TMSC pin while it is driven by the DTS for all advanced formats. The DTS and TS sample the TMSC pin while it is driven by the TS for scan formats other than MScan. The kept value of TS output is sampled by both the TS and DTS when the MScan format is used, independent of the CC[0] bit.

Power Control (PC[1:0]) bits determine the power-down criteria of the interface: Allow power down in TLR state, No interface power down, Allow power down in TLR if no TCK for 1 msec, and Loss of TCK power-down if no TCK for 1 msec.

After POR, the chip Power and Reset Controller (PRC) is allowed to power down the interface when the TAP state is TLR. Provided the TMSC input is a one (1). Once the TAP state is something other than TLR, the PRC may not power down the interface with this setting. The DTS may change the power control bits at this point. The three remaining modes provide different behavior suitable for debug, test, and detection no DTS (indicating the DTS/TS connection has been broken).

The JTAG TRST (JTRST) bit provides a means for the DTS to assert nTRST to System TAPs without an nTRST pin Link Interface pin. Setting this bit to a one asserts nTRST to system TAPs (not the adapter TAP).

The Flatten Scan Path (FLAT) bit provides a means for the DTS to place all TAPs within the IC system scan path in a manner where the scan path is operational. This may disturb system operation as it requires all modules to be powered and connected together so as to make all scan paths operational. The DTS will wait for 100 msec before accessing the system scan path to assure proper operation. This bit affects only the system scan path. If the firewall is enabled, the system scan path is not connected to the link even when the Flat bit is set.

The Scan Format (SF[3:0]) specifies four scan formats used with standard operating mode (JScan0-3) and twelve scan formats used with advanced interface operation (OScan0-7 and SScan0-3). The scan format is managed with the SSF command. An adapter is placed offline, i.e., it is disabled, if an unsupported scan format is specified by this field.

The SOA bit is controlled by the SRS command and the scan format. It is used to identify the broadcast of series selection information when the interface operates in standard mode and the output of status or extended command page information, when the interface operates in advanced mode. This bit is active from the point the SRS or RECP command occurs until it is discharged. When this bit is a one (1), it disables the decoding of a command block's filling of the TEMP register, as the DR_Scan following this bit being set conveys special output. Once set, the bit is cleared when the command window is closed or by an occurrence of the Update_DR TAP state.

The Delay (DL[1:0]) bits control the number of delay bits added to scan packets. The delay may be used to provide extra time between scan packets for the host adapter to interact with the IEEE 1149.1 interface.

Preliminary Scan Selection (PS[1:0]). There are two preliminary scan selection bits, star (PS[0]) and series (PS[1]). Each is managed separately, The PS[1] bit is managed with the MSS and SCA commands. The PS[0] bit is managed with the SRS command. Scan selection is double buffered as scan selections are made in a preliminary manner and then applied upon entry into the IDLE TAP state. Double buffering allows the pre-selection of one or more adapters and their selection can be delayed until the IDLE TAP state is reached. This facilitates the implementation of global commands affecting more than one link.

The Scan Selection (SS) bit is loaded upon entry into the TAP IDLE state. It is loaded differently depending on the scan format as follows: JScan0—One (1), JScan1—Zero (0), JScan3—PS[0], and Others—PS[1].

The Preliminary Scan Status bits (PSCS[1:0]) tracks the number of adapters selected for scan in addition to identifying whether Link IDs are assigned. The scan status is first calculated in a preliminary manner PSCS[1:0] just as with preliminary scan selection and then copied to the scan status (SCS[1:0] upon entry into the TAP IDLE state. The preliminary and scan status are encoded as follows: ‘00’—Link IDs initialized to zero, ‘01’—Link IDs assigned, no adapters selected for scan, ‘10’—Link IDs assigned, a single adapter selected for scan, and ‘11’—Link IDs assigned, more than one adapter selected for scan. A scan selection is defined as an MSS command. Two MSS commands selecting the same device qualifies as two scan selections. Scan status tracks commands rather than actual device selections. When the preliminary scan selection is “00” it remains this value until the ILID command invalidates Link IDs.

The Scan Status bits (SCS[1:0]) are double buffered for the same reasons as scan selection is double buffered. The PSCS field is copied to the SCS field upon entry into the IDLE TAP state with the same rules as those that govern PS[1:0] and SS bit behavior.

Scan Status Initialization. PSCS and SCS values of zero (0) are created by link initialization. Initialization status (SCS=“00”) identifies the initialized state. This state: Assigns a device a Link ID of zero (0) (valid ID), Provides an operable advanced interface for a single cJTAG enabled device connected to a DTS port (one device), Provides an operable standard interface, and Allows the creation of an operable advanced interface after initialization, if more than one cJTAG enabled device is connected to a DTS port in a star configuration.

This state forces the use of the MScan format in advanced interface mode. It allows standard transfers with system TAPs, provided the Firewall has been removed. It also allows command windows to be created that block TDO drive, providing assistance in determining the connectivity between adapters and the DTS. An ILID command followed by an IDLE Tap state moves preliminary scan status from initialization to no adapters selected (SCS=“01”). The ILID command invalidates Link IDs and clears PS[1] (star pre-selection bit).

When an IDLE state updates the scan selection and scan status following the ILID command: All devices connected to a DTS port are de-selected, Scan status indicates no devices selected, and The scan path used for device isolation is selected.

None, One, and More Than One Status. Assuming Link IDs are assigned, Scan Status tracks the number of devices selected. The number of devices is tracked as none (01), one (10), or more than one (11). An appropriate SCA command sets the status to none. Each qualified MSS command increments this status until it reaches more than one. It stays at more than one, if additional MSS commands occur. Both the system command action (SCA) command and invalidate link ID (ILID) commands set the scan status to none.

Transport Format (TF[3:0]) specifies: whether continuous or burst transport packets are used with BDX or CDX, the direction of the transfer in the case of BDX, and the length of the burst packet when burst packets are used.\

The BDX Enable (BE) bit enables BDX transactions if one (1). An adapter is disabled if this bit is set and BDX is not supported by the adapter. The CDX Enable (CE) bit enables CDX transactions if one (1). An adapter is disabled if this bit is set and CDX is not supported by the adapter. The BDX Selection (BS) bit is set or cleared with the MTS command and may be cleared with the SCA command. This bit selects the adapter that participates in a BDX transfer. If the BS bit is set to a one (1), this device participates in the BDX transfer provided the TF[3:0] field has turned BDX on. The bit takes effect immediately and affects the adapter participating in the BDX transfer that follows the register write. If this bit is a zero (0), the device follows transport packet activity but does not participate in a data exchange.

Packets and States

Packet sequences may include the following packet types:

Advanced Scan
Manage TAP activity

Change
Manage the cJTAG configuration

Transport
Move non-scan information between the TS and DTS

An advanced-scan packet represents the information associated with a single JTAG TAP state. This packet type moves the TDI, TMS, and TDO information associated with TAP states between the TS and DTS. A scan packet is created using a variety of compression techniques ranging from 1 to 6 clocks per bit, to serializing each packet. The content of scan packets is defined by a scan format defined with the control register, TAP state, and in some cases, information embedded in the packet traffic.

A change packet is generated by some writes to the cJTAG control register. This packet type suspends cJTAG activity. Change packets are inserted between scan packets when a register write in standard mode changes the link operating mode to advanced or when a register write occurs and the link operating mode is advanced. The content of change packets allows the extension of the packet length, detection of timeouts, and the ending of the packet with a return to either the SS or AS states.

Transport packets move CDX and BDX information between the DTS and TS. These packets are inserted between scan packets while a CDX or BDX transfer is active. The content of BDX transport packets is defined via the control register as bi-directional every other bit, unidirectional DTS to TS, or unidirectional DTS to TS. The content of CDX transfers is defined by DTS and TS customized protocol and is directed on a clock-by-clock basis during a CDX or BDX transfer by DTS and TS CDX units connected to the respective adapters. The BDX and CDX units that connect to the adapter are not covered by this specification.

The link mode control flow is shown in FIG. 9. At start-up, the interface is assumed to be in an unknown state with the TDI and TDO values being don't cares. The assertion of nTRST, BCE, a Hard-Reset escape sequence, a TMSC value of one (1), or POR forces the link operating mode to standard, depending of the link configuration.

At this point, the DTS and TS TAP states are synchronized. The TCK and TMSC pins may be used to: force interface power, change link operating modes, and specify the initial advanced mode operating characteristics. All of these may be supported only using JTAG TAP state sequences.

Any of the above mentioned resets is sufficient to cause the power down (PD) of the Link interface, if the TMSC input is held high and power down is supported. The initialization of the adapter control registers caused by these resets makes the criteria for power-down standard mode with a TLR TAP state. Since this is the state after one of these resets, the TMSC value determines whether the interface powers down as the DTS causes power up of the interface by holding the TMSC pin low for 1 ms or greater. This not only causes power up of the interface, it moves to the TAP IDLE state once the adapter is powered and reset is released. This assures the power-down criteria are no longer met. Once the adapter is powered, the state moves from PD to SS.

Standard-Scan (SS) State. JTAG scan packets manage the TAP state in the SS state. These packets are merely the TMSC, TDI, and TDO pin values exchanged each TCK. This state remains until the interface is powered down causing a move to the PD state or a control register write changes the operating mode to advanced causing a move to the CC state as the Update_DR state is exited. The interface continues operation in the standard mode with standard scan packets every TCK period otherwise, register writes, other than those changing the operating mode, do not cause state changes.

Configuration-Change (CC) State. Change packets are generated by configuration changes that change operating modes or when a register write occurs in the advanced operating mode. The change packet provides a period where the new configuration takes effect. When this packet completes, the state changes to either AS or SS depending on the operating mode specified by the control register. Since the change packet was caused by an operating mode change to advanced, the exit is to the AS state.

Advanced-Scan (AS) State. JTAG state progression is directed by serialized JTAG information (scan packets) in the AS state. The TAP state may change as often as every TCK but may change less frequently, depending on the serialization characteristics specified by the scan format, one of the control-register fields. The state remains AS, if no control-register writes occur and BDX and CDX transport remains disabled.

Any control-register write in state AS moves the state to CC, when a change packet occurs. If the write specifies supported features, the switch packet completes and the CC state moves to either the AS or SS state. If an unsupported feature is specified, the switch packet is extended until a soft-reset escape sequence occurs or the control register is initialized by a reset condition detectable by the adapter (nTRST, BCE, Hard Reset, POR).

Background Data Transport (BDX) and Custom Data Transport (CDX) States. Once BDX or CDX are enabled, these functions cause state changes to their respective states. These state transfers are related to specific TAP states. BDX transfers use Idle, Pause_DR, or Pause_IR states. CDX transfers use Shift_DR states. Scan uses Shift_DR and Shift_DR states when these states are not allocated to CDX transfers.

When a state supporting one of these transfer types is reached, a transfer is request if enabled via the control register and in the case of CDX, other qualifying criterion are met. The qualifying criterion for CDX is control level 1 or inline initiation via SS activity. This request causes the generation of a scan packet with TDO in it. This allows a state change to BDX or CDX, if their supporting TAP state is active. These transfers take place as long as the TAP supports their activation. They deactivate when the supporting TAP state is exited, moving the state to AS.

Scan Formats

Some system components impose unique constraints that reduce scan and debug performance. These constraints are not JTAG-friendly or they require a large amount of execution time or bandwidth. The more severe the constraint, the more system performance drops. Minimizing the impact of these constraints is a key objective of the architecture. Since there can be a number of different constraints, a number of different operating points are provided (shown as the dots on the curve in), each maximizing scan and debug performance to a different set of system constraints. System performance is increased when the link transactions are customized to decrease the link transaction information volume.

Scan formats provide specialized access mechanisms to access memory and system states. A scan format is defined as the bit protocol sent over the TCK/TMS/TDI/TDO lines to effect either; JTAG IEEE 1149.1 compliant operations, the cJTAG enhanced JTAG operations or the operations unique to cJTAG. They overcome scan performance issues created by components that are not JTAG standard, while involving another clock domain in scan transactions. These optimizations target use cases that are common in today's system designs, and take direct aim at raising performance to overcome system constraints.

A typical constraint is the input or output of data in JTAG states other than the two shift states. Another is scan-rate constrained transfers caused by interactions between the functional and scan clock. At the other end of the spectrum there are minimal constraints. For example, some debug or scan functions do not require both input and output data for each clock of a transfer, which allows a scan operation to be broken into segments of input only, output only, or both input and output.

The term “standard mode” used in this specification refers to the IEEE 1149.1 JTAG feature set (JScan0) plus the JTAG extensions provided by JScan1, JScan2 and JScan3. The scalable nature of the IEEE 1149.1 JTAG architecture provides a baseline capability and allows the addition of other cJTAG capabilities. Baseline and other capabilities are additive. In broad terms, the capabilities may be split into five formats:

JScan—legacy JTAG (IEEE 1149.1) scan improvements

MScan—multi-device communication

OScan—optimized scan

SScan—segmented scan

Transport—background data transfers (BDX) and custom data transfers (CDX)

cJTAG supports 17 scan formats. These are referred to as JScan0-3, SScan0-3, OScan0-7, and MScan. The formats use a variety of compression protocols ranging from 1 to 6 clocks-per-bit to serialize each packet.

A guide to selecting a format is shown FIG. 82. A summary of the scan formats is shown in FIG. 83. Standard formats (JScan formats) are shown in white. Advanced formats (MScan, OScan, and SScan) are shaded gray. The light gray text within a shaded area indicates the format is only used when the DTS sources TCK.

JScan

Legacy JTAG Scan Improvements (JScan), JScan scan formats, are used when a cJTAG enabled device is used with a JTAG scan topology. The JScan capabilities provide: Compliance with IEEE 1149.1, Link robustness, JTAG Series connectivity performance, and JTAG Star connectivity performance. Four scan formats (JScan0-3) provide IEEE 1149.1-compliant behavior or IEEE 1149.1-compatible behavior with additional capability. These formats target the areas shown in FIG. 84.

JTAG performance is improved by adding selection mechanisms that: bypass devices that are of no interest in a Series configuration (series selection), and select only a single device in a Star configuration (parallel selection).

The cJTAG adapter's “built in” parallel selection mechanism makes the JTAG Star scan topology practical, as no glue logic is needed. A firewall may be installed at Power On Reset (POR) or by scan sequences to prevent a change in system operation created by the physical connection or disconnection of powered DTS and TS.

The selection facilities used for advanced modes may be used to assign Link IDs to cJTAG-enabled devices connected in a JTAG Star configuration. Once this is done, JTAG protocols may be used to select and communicate with devices. Since the selection mechanism is built into the device, a glue less JTAG Star configuration results. The devices are addressable with the standard JTAG state sequences. These sequences appear “invisible” to TAPs connected to the adapter in any of these devices. This makes the JTAG star configuration a practical, low-cost, higher-performance alternative to low chip-count series configurations

Link operation in the standard mode is best viewed as legacy JTAG operation with robustness and performance extensions. Some extensions may be enabled by POR while all extensions may be enabled and disabled using command sequences.

The adapter operating mode is defined by a four-bit control register segment called the scan format SF[3:0]. See the Scan Control Register Format, FIG. 74. Each of the 16 register values specifies one of the operating modes and additional mode characteristics. The first four values (0-3) specify standard mode and are collectively called JScan formats. JScan formats use JTAG scan protocol in addition to enabling JTAG extensions supported by some formats. The remaining SF [3:0] values specify advanced mode.

JScan formats 0 to 3 are shown in FIG. 85. The 4-pin scan topologies supported by these formats are shown in FIG. 86. Each of these formats is either JTAG-compliant or JTAG-compatible. Each of these scan formats uses a Wide Interface for scan transfers to and from TAPs connected to the JTAG interface. The TCK and TMSC pins are sufficient to create the command sequences that manage the cJTAG mode and other characteristics.

The Star configuration requires all chips to be cJTAG enabled, while the Series configuration does not. Advanced formats may be used with the Star configuration but not with the Series configuration. The parallel-selection mechanism acts like a one-device scan path linker, allowing connection of the wide interface signals in parallel for the Star configuration. Command sequences select the device of interest with other devices remaining offline. In the series configuration, any cJTAG enabled device may be turned into a one-bit scan path using the series selection mechanism.

Compliant Formats. The JScan0 scan format specifies native JTAG operation. It dictates JTAG compliant operation with all extended JTAG capabilities being disabled. This format is one of two possible formats created by control register initialization, the other being JScan1.

Compatible Formats. The JScan1, JScan2, and JScan3 scan formats specify compatible JTAG operation. These formats utilize the following extensions to JTAG capability: Firewall, and Device Selection/SuperBypass. These extensions are managed solely through the TAP state transitions, making their use 100% compatible where a mix of legacy JTAG and cJTAG enabled devices are connected in a series or wide star configuration.

The cJTAG architecture extension called Firewall, see FIG. 41, provides a link robustness feature that provides an option to either enable or disable the firewall with power on reset (POR). An enabled firewall blocks the adapter's JTAG interface TCK. The DTS may enable the firewall with a command sequence to prevent disconnects. Enabling the firewall with POR minimizes the chance that system operation is changed or corrupted by the connection of a DTS and TS in a mix of powered and un-powered configurations. This option virtually assures the random interface activity created by the physical connection of the DTS and TS will not disturb the system state. The firewall may also be enabled or disabled by a command sequence. The sequence needed to write the SF[3:0] control register is sophisticated enough to avoid its accidental occurrence during the making or breaking of the DTS to TS physical connection.

The firewall may easily be removed by standard scan sequences after POR without knowing the system state or scan topology. When POR disables the firewall: A “wide” interface is JTAG compliant, and A “narrow” interface is compliant to protocols but data transfers are not supported. When POR enables the firewall: A “wide” interface is JTAG compatible, and A “narrow” interface is compatible but data transfers are not supported.

Devices with an enabled firewall are entirely compatible with those that do not have an enabled firewall. The firewall merely enables the global bypass provided by the SuperBypass bit, in addition to disabling the advance of the system TAPs connected to the JTAG interface.

The firewall is implemented in a manner that makes mixing firewalled cJTAG, non-firewalled cJTAG, and legacy JTAG devices very practical. The firewall is disabled using a command sequence that is a NOP to legacy JTAG devices. The firewall may be disabled prior to performing any other action such as obtaining the Device ID. When the command sequence disabling the firewall follows the TLR state, all other legacy device states are left intact. The sequence used to disable the firewall is treated as a NOP by legacy JTAG devices or cJTAG devices whose POR interface disables the firewall. Once the firewall is disabled, the TLR state may be reentered without affecting the firewall.

The natural characteristics of JTAG TAP operation make managing the firewall easy. Any event, asynchronously or synchronously causing the TAP TLR state, loads either a BYPASS or IDCODE instruction in the instruction register. A command sequence disabling the firewall may immediately follow this event, with this operation being ignored by non-firewalled TAPs. This makes the firewall deactivation after POR or the TLR state virtually invisible to the system and existing system software, requiring the addition of only a small amount of start-up software. Alternatively, a hardware controlled firewall disabling sequence could be included in the DTS or the DTS adapter. Both firewalled and non-firewalled operations are entirely compatible with legacy JTAG systems.

TAPs connected to this interface are isolated from activity at the cJTAG interface. This protects the system from random events generated by connecting or disconnecting a powered DTS and TS. The cJTAG architecture adds selection and de-selection of adapter devices to legacy JTAG capability. Two types of selection may be used: series or star. Series selection is used with standard mode and JTAG series configurations, while star selection is used with JTAG star configurations where all chips are cJTAG enabled. Star selection is also used with advanced modes. The selection type is specified with the scan format. Both selection types are disabled by control register initialization.

Selection is a two-step process: specify the pre-selections via one or more command sequences and activate these pre-selections upon entry into the IDLE TAP state. The selection mechanism blocks the JTAG interface TCK when the adapter is de-selected. Since all the selections and de-selections occur at a precise point in the TAP state sequence, adapters are disconnected and connected at precisely the same TAP state, all adapters remain synchronized through multiple select and de-select operations.

The adapter itself is not affected by de-selection. The SuperBypass bit is used as both the IR and DR scan path when a device is de-selected.

The JScan2 scan format allows the selection and de-selection of cJTAG devices when connected in a star scan topology. Star selection may only be used when all devices are cJTAG enabled. This mode combines star selection using the advanced mode with standard 4-pin scan transactions. Advanced mode is used to assign Link IDs (addresses) to adapters at start up, while standard mode (JScan2) uses these addresses to choose to communicate with the device of interest. If more than one device is selected, the TDO pin is kept HI-Z to avoid drive conflicts.

Star selection is a two-step process: pre-selection and selection. Pre-selection moves selection information to adapters without using it. It is used to select devices when entry into the IDLE TAP state occurs following delivery of the information provided the JScan2 scan format is specified at this point.

The selection information is conveyed to adapters within a command window using the adapter's Link ID. Since the adapter addresses are established using advanced protocols, all devices connected in the JTAG star scan topology must be cJTAG enabled devices. This can be determined using other advanced capabilities.

Once the select information is delivered to the star selection bit, it is used to select the adapter when all of the following occur: JScan2 scan format or any advanced format, A TLR TAP state has not been encountered since parallel selection information was delivered, cJTAG control registers have not been initialized since parallel selection information delivery, and IDLE TAP state occurs.

The JScan3 scan format allows the selection and de-selection of cJTAG devices when they are connected in a JTAG series scan topology. The series scan path may contain a mix of legacy JTAG and cJTAG devices. Selection operations are NOPs to legacy JTAG devices. Selection information is passed to adapters in cJTAG enabled devices via the SuperBypass bit.

Series selection is a two-step process: pre-selection and selection. Pre-selection moves selection information to adapters without using it. Entry into the Idle TAP state following pre-selection uses this information to select devices.

The selection information is broadcast to adapters within a command window. A special Status or Selection (SRS) command identifies the next DR Scan as containing selection information. This command causes the chip scan path of each cJTAG enabled device on the series scan path to make their chip scan path the one-bit SuperBypass path for the next DR scan. Legacy JTAG devices ignore this command. The DTS follows the SRS command with a DR scan delivering selection information. Each device in the series path presents a one-bit scan path. Legacy device paths are the Bypass bit while cJTAG device paths are the SuperBypass bit. The scan path appears as if it is the BYPASS scan configuration. When this scan occurs, series selection information is loaded into a series-selection bit when the Update_DR TAP state is reached.

A TLR state or any reset initializing the control register between the SRS command and the Update_DR state prevents the loading of the selection information and cancels the identification of the DR Scan as carrying selection information.

A data register scan loads series pre-selection data from the SuperBypass bit into the series pre-selection bit when all of the following occur: JScan3 scan format is present, SRS command occurred during the last Update_DR TAP state, A TLR TAP state has not been encountered since the SRS command, The cJTAG control register has not been initialized since the SRS command, Command window is open at level 2, and Update_DR TAP state occurs.

The SRS command is discharged once the next Update_DR state occurs. The data-register scan conveying the serial select information will not be interpreted as either an LTR or STR command. The TEMP register remains empty following this scan. The SRS command connects the SuperBypass bit between TDI and TDO and enables TDO during Shift_DR scan states, provided TDO output has not been blocked by a command window open at level 3.

Once the select information is delivered to the series selection bit, it is used to select the adapter when all of the following occur: JScan3 scan format, A TLR TAP state has not been encountered since series selection information was delivered, The cJTAG control register has not been initialized since series selection information delivery, and Idle TAP state occurs.

Selection occurs at the point the TAP IDLE state is entered. Connects and disconnects occur when the TAP state is IDLE, assuring the adapters associated with the link remain synchronized. Selection or de-selection caused by either enabling or disabling the firewall also follows these rules.

Selecting a device following disabling the firewall may create a situation where a newly selected TAP has a TAP state of TLR while the adapter TAP state is IDLE. This is easily remedied by assuring the adapter TAP stays in the IDLE state for at least two states when the firewall is disabled. This rule applies to the interface mode existing after the firewall is disabled.

Super Bypass provides a single-bit device bypass for instruction and data scans when the firewall is installed or the adapter is de-selected.

Debug software may use the Super Bypass function (series selection) as a scan path linker, bypassing devices of no interest when accessing a specific device. This can significantly reduce scan transaction overheads with the potential of improving debugger response and download speeds. The Super Bypass concept is shown in FIG. 18.

The Super Bypass scan path is selected when one of the following occurs: In the command window and the a scan format is not JScan0, and A device is de-selected.

MScan

MScan is used for simultaneous communication with multiple adapters and the TAPs connected to them. A DTS may communicate with multiple adapters within the TS, using a single DTS cJTAG port. This occurs when more than one device is selected by DTS software. When one device is selected, a more efficient OScan or SScan format is used. From 1 to 16 TS Link Interfaces connected in parallel may be supported by a single link and addressed by link IDs. This number of adapters supported by the link may be expanded beyond 16 when multiple adapters share a single link ID.

Devices may be assigned IDs to select a device of interest. More than one device may be selected at a time. This is commonly used to broadcast global commands, especially Debug, e.g., global run or halt.

This scan format uses a 6-bit packet to exchange information related to one TAP state. The format of the packet allows the drive of the test mode select control (TMSC) pin by multiple devices. It also provides a means for a selected device within the TS or DTS to stall a transaction. A stall indication is embedded in the packet mentioned above. The TS may extend the transaction indefinitely, returning a stall visible to the DTS and other devices. The TS may generate a stall when it cannot disposition DTS input or provide output to the DTS. This can typically be caused by power-save modes or component-clocking limitations, or on-chip scan buffering considerations. The stall slows the transaction rate so that the DTS and TS TAP states remain synchronized.

The MScan capabilities are summarized in FIG. 87. The MScan format uses MScan packets to exchange TAP state information between the DTS and TS. These packets: Carry the same information for all TAP states, Merge the output of selected adapters, and Have information (front end) and delay (backend) components. The MScan packet type is used to broadcast commands when multiple adapters are selected and when no adapters are selected. The SCS field of the Link Control register identifies these conditions.

An MScan packet contains:

nTDI—Inverted value of Test Data Input: The TDI TAP value associated with TAP state n,

TMS—Test Mode Select: The TMS TAP value associated with TAP state n,

PC0—Pre-charge zero: TMSC driven to a one (1),

RDY—Ready: An indication that identifies whether a frame transfer may proceed,

PC1—Pre-charge one: TMSC driven to a one (1),

TDO—Test Data Output: The TDO TAP value associated with TAP state n, and

DLYn—Delay: Zero to n delay bits, 0, 1, 2 fixed delays, 3 to n bit variable delay.

The MScan packet format is shown in FIG. 20. The first six bits are the front end delay while the delay is the backend 6-n bits. The backend is eliminated when the DL[1:0] field specifies no delay. The nTDI, TMS, and TDO bits represent the bits of the MScan packet at the cJTAG TMSC pin. These bits are transferred between the DTS (through the cJTAG Link) and the TS adapter's JTAG interface connected to the TAPs in the IC. Each “not ready” (nRDY) extends the packet front end by two clocks.

The information component of the MScan packet (front end) precedes the delay component (backend). It contains the data and control information related to a single TAP state. Additional stall information is included to accommodate transaction stalls.

The nTDI and TMS information is sourced by the DTS. The RDY bit provides a means for the DTS or any selected adapter sharing a DTS port to stall the transaction until it is ready to advance its TAP state. The TS sends the TDO information to the DTS with the TDO bit. All TS sources supply a one (1) during the PC0 and PC1 periods independent of whether or not they are selected. These bits are also be sourced as a one (1) by the DTS.

The TDI information supplied by the DTS is inverted. When the TS supplies TCK and the TAP state is one of the TAP shift states, this characteristic provides some failsafe protection as it prevents the TMSC pin from getting into a regenerating state of all zeroes (0s) after a break in the TS and DTS connection.

The RDY and TDO bits are handled in a manner that allows multiple devices to participate in their generation without causing TMSC drive conflicts. The DTS or one or more TS adapters may source these bits. A command level of three blocks the TS output of both of these bits.

RDY and TDO information is transferred over two TCK periods of which the first is the precharged period. During the first clock period, the DTS and all devices drive the pin to a one (1), independent of whether they are selected (pre-charging the pin to a one (1)) using states PC0 and PC1. During the second clock period, an adapter may only drive the TMSC pin to a zero (0) (discharging the pin) if it desires to output a zero (0). If the DTS and TS do not drive the pin during the RDY and TDO bit periods, the bus keeper extends the one driven on the pin the previous clock period by the PC0 and PC1 bits. This drive criteria, combined with the bus keeper (the bus-keeper optionally latches the signal in the last driven state holding it at a valid level with minimal power dissipation), holding a one (1) driven by the previous bit makes these bits the logical AND of the RDY and TDO of all selected adapters.

A RDY value of zero (0) causes the extension of an MScan packet until a RDY value of one (1) is returned. Each clock, where a “not ready” indication is returned (0-stall), extends the packet length by two bits as bits two and three are repeated after reaching bit three. This is summarized in FIG. 88.

A bit sequence with two “not ready” bits returned is nTDI, TMS, PC1, RDY, PC1, RDY, PC1, RDY, PC0, and TDO. Driving the TMSC pin by an adapter during the RDY bit period is permitted only when this adapter is selected.

The TDO value normally provides the TS TDO when an adapter is selected. It is also used to provide device ID information used in assigning Link IDs when no adapters are selected. The TDO bit is sourced by the TS and is associated with the same TAP state as the TDI and TMS value in the same scan packet. If the adapter is selected, the TMSC pin is driven during the TDO bit period if the data value is a zero (0). If any of these conditions are not met, the bit remains HI-Z in this bit period.

Driving the TMSC pin during the TDO bit period is also subject to the following criteria:

if (status is being read),

- if (read is from this adapter),

else if (extended command page information is being read),

- if (read is from this adapter),

else if (no adapters are selected),

else (more than one adapter is selected),

- if (this adapter is selected), and
- JTAG output enable indicates the bit would be driven.

During link assignment, chips without assigned Link IDs may also drive this bit.

Packet Separation/Delay. The MScan packet backend is a fixed (0, 1, or 2) or variable delay inserted between consecutive packet front ends. The delay component provides a means to:

Create TMS and TDI setup time between a DTS adapter and the DTS serializing the JTAG control and data information

Create TDO hold time between a DTS adapter and the DTS

Implement port selection

There are two delay classes, fixed and variable. Fixed delays provide three delay lengths:

No delay

One clock with TMSC remaining the same value as the previous bit period

Two clocks with TMSC remaining the same as the previous bit period

Variable delays provide a minimum delay of three TCK periods and may be extended indefinitely with the appropriate protocol activity.

Fixed delays do nothing except extend the time the last value generated by information component stays on the TMSC pin. Variable delays may also be used for port selection as this delay class has the ability of causing a transaction stall for extended periods, while also providing a means to realign a suspended transaction with an ongoing one when a port is re-selected. Using variable delays for port selection suspends all port activity including BDX transfers.

A fixed delay within a packet is shown in FIG. 15A. This delay class is typically used to customize the electrical characteristics of the DTS, adapter, and TS interface in the case where the DTS TDI/TMS information is not pipelined within the DTS adapter or DTS controller implementation. Up to two bits (DLY0 and DLY1) may be included in the scan packet with a fixed delay. Another MScan packet begins after the delay and the clock from the DTS adapter to the DTS may be adjusted within the delay period. Fixed delays are also applicable to both OScan and SScan formats and their packets. Fixed delays are specified using the DL[1:0] field of the Scan Control register as shown in FIG. 15B.

A variable delay, following the front end of an MScan packet, is shown in FIG. 16A. A variable delay, constructed from an initial delay one clock in duration followed by one or more delay segments 64 or less bits in length, is shown in FIG. 89. A delay segment is shown in FIG. 90. Variable delay is controlled by DL[1:0]=0b11.

A state machine operation representing variable delay operation is shown in FIG. 16. The states in this Figure have the following descriptions:

DLY—One clock initial delay,

WAIT—Waits for an exit generated by a TMSC value of zero (0) or a timeout, and

DISP—Dispatch to next operation.

The use of these states will become more apparent further in this section. A timeout is caused by 64 consecutive one (1) bits on the TMSC pin, while a variable delay is active.

A delay segment terminates in one of three ways: Extension, Completion, and Timeout. Extension initiates a new delay segment. Completion causes the start of the next packet sequence. A Timeout initializes the control registers with their POR initialization value, causing a return to standard operating mode.

Delay extension allows the creation of delays of up to 64 TCK periods. The DTS extends a variable delay with a zero (0) TMSC value within a 64 clock TCK window. A TMSC value of zero (0) within a window restarts a new window. Any number of ones (1s) less than 63, followed by a single zero (0), extends the delay period and initiates a new delay segment as shown in FIG. 91. A variable delay may be extended any number of times. The continual occurrence of a single one (1) is referred to as a “heart beat” to continue the delay.

A value of zero (0) on the TMSC pin during clock period m is sampled at the beginning of clock period m+1 directing the state to DISP state during clock period m+2. A one (1) following the zero (0) directs a move from the DISP state to the WAIT state. Two consecutive zeroes (0s) complete a delay segment and the delay, initiating a scan packet. This is shown in FIG. 92. The minimum variable delay is three TCK periods. This requires two TMSC values of zero (0) beginning with the DLY state.

Sixty-four consecutive ones (1s) cause a timeout and a return to standard mode, provided the adapter has not been placed offline by enabling an unsupported capability. The TMSC values during the DLY, WAIT, and DISP bits are included in this count. A timeout causes initialization of cJTAG registers and progression to the standard operating mode as shown in FIG. 93. Initialization of the Scan Control register specifies standard mode, the DISP state ignores the TMSCQ value and returns the interface to standard mode.

The association of an MScan Packet and the TS TAP state is shown in FIG. 94. All Selected TAPs are RDY in this example. Note the TAP state changes on the rising edge of TCK when TDO is being sent to the DTS. The point at which the TS changes the TAP state may be advanced or delayed by one clock. Delays may be inserted after TDO. In the case of a delay of one or two, the TDO value is merely extended by one or two clocks, respectively. Any change in the TAP state does not change the TMSC pin timing.

MScan packet transmissions are subject to being interrupted by a: Register write, or BDX transfer. The interrupt occurs after the first bit of a new packet, with this bit being discarded by the TS. When the interrupt processing is completed, the scan packet associated with the current TAP state is sent by the DTS with the scan transfer continuing from this point. This is shown in FIG. 95.

Oscan

Optimized Scans (OScan) formats emphasize compatibility with existing drivers and hardware. Optimizations take into account the TCK source, the need for scan transaction stalls by matching the state-rates of the Link Interface and DTS, and the need for unidirectional or bi-directional transfers. The OScan formats are shown in FIG. 96.

The four OScan format types are described below:

All Purpose
Stalls and TDI/TMS/TDO in each packet

Scan_2x
Link clock rate is always 2X the TAP clock rate

Scan_1X
Link clock rate is same as TAP clock rate

Download
Link clock rate is same as TAP clock rate, transfer to TS

only

Since scan transactions can be optimized further when the DTS sources TCK and the four OScan formats (shown above) are expanded to eight formats to obtain the best performance for both DTS sourced or TS sourced TCK. The formats compatible with a DTS sourced TCK are more efficient as they use special TCK/TMSC relationships to pass control information needed on an infrequent basis. One example of this is when to exit the shift state. The initial configuration assumes the TS is the clock source. The DTS tells the TS adapter that it is the TCK source. Formats on the right are remapped to formats on the left when the DTS specifies a format on the right without informing the TS that DTS is the TCK source.

The all-purpose format performs no optimizations, but supports any transaction with a native or modified JTAG interface. The other formats discard TDI in non-stable JTAG states before passing control information across the link bridge. When the DTS supplies TCK, other formats further increase link efficiency in JTAG shift states by discarding TMS information before passing control information across the bridge. An exit from a JTAG shift state is initiated with a special escape sequence created with TCK/TMSC relationships.

The Scan_2× type is friendly to current DTS equipment, as the link TCK can always be 2× the TAP TCK. For example, a 35 MHz DTS can support a 70 MHz link with this format. The Scan_1× type provides the same capability as the Scan_2× type but with the TAP and link TCK operating at the same frequency. For example, a 70 MHz DTS would support a 70 MHz link. Higher TAP state rates are achievable with this format. The Download type is primarily a debug format. The unidirectional transfer to the TS will achieve the highest frequency with a 70 MHz DTS generating a 70 Mbits/sec download rate.

The eight Optimized Scan (OScan) formats provide a mix of scan and debug performance improvements. They support basic and specialized scan transactions. OScan formats are used when all of the following are true: After Link IDs are assigned, When a single adapter is selected, When an OScan format is specified, and Packet Information.

The OScan formats use packets to exchange control and data information related to each TAP state. An OScan packet contains one or more of the following:

nTDI—Inverted value of Test Data Input: the TDI value associated with TAP state n

TMS—Test Mode Select: the TMS value associated with TAP state n

RDY—Ready: Control information that identifies whether the scan transfer may proceed

TDO—Test Data Output: The TDO value associated with TAP state n

DLYn—Delay: Zero to n delay bits, 0, 1, 2 fixed delays, 3 to n bit variable delay

The template for all OScan packets is shown in FIG. 11. Packet payloads are created by populating some of the template or the entire template, with different formats creating different payloads.

The inverted values of TDI followed by TMS are sent by the DTS to the TS when the packet includes these bits. One or both of these bits is included in each OScan scan packet.

The RDY bit is sent by the TS to the DTS when the packet includes this bit. It is driven by a selected adapter and not driven otherwise. The adapter may stall scan transactions using this bit. A zero (0) in this bit position extends the packet length one bit, with the RDY bit repeated the following bit period. This is summarized in FIG. 97.

The TDO bit period is sent by the TS to the DTS when the packet includes this bit. It is driven by a selected adapter and not driven otherwise. It is driven with: The data value generated by the adapter, if the adapter is the data source, The data value generated by the adapter's JTAG interface, if this interface is the data source and the JTAG interface indicates the TDO value should be driven, and A “1” data value, if the JTAG interface is the data source and the JTAG interface indicates the TDO is not driven.

The packet separation and delay for OScan formats is identical to that for MSCAN. The delay follows the packet information just as with MScan packets.

The packet payload for any specific TAP state is specified by a combination of the scan format and TAP state. These factors vary the information in OScan packets five different ways:

Stall (S)—Stalls are eliminated when not required

Data Input (I)—TDI is eliminated when not required

Data Output (O)—TDO is eliminated when not required

Control (C)—TMS is eliminated during shift states

Unidirectional (U)—All information is sent to the TS with no information sent to the DTS

These are collectively called packet optimizations.

Stall Optimization (S). The RDY bit is deleted when the TS is capable of always responding properly to the DTS transaction rate.

Data Input Optimization (I). The TDI bit is deleted from packets associated with non-shift TAP states as TDI is a “don't care” in these states.

Data Output Optimization (O). The TDO bit is deleted from packets associated with non-shift TAP states as TDO is a “don't care” in these states.

Control Optimization (C). The TMS bit is deleted from packets associated with shift states if the DTS sources TCK. An End-of-Transfer escape sequence, sent with data for the last shift state, replaces the TMS function.

Unidirectional Optimization (U). All TDO information may be deleted from packets if a scan transfer does not require TS output.

There are four OScan transaction types, each supporting a different set of requirements: The key characteristics of each transaction type are summarized in FIG. 98. The all purpose type supports any transaction that uses TDI or TDO in any JTAG state and systems where a component cannot support scan transaction rates at the same rate as the DTS. The Scan_2× and Scan_1× types support any transaction that uses TDI or TDO only in the TAP shift states, with the difference being the minimum Link/TAP clock ratio required for link operation. The Download type supports any transaction that uses only TDI in the TAP shift states.

Transaction types use the optimizations shown in FIGS. 12A and 12B. Two OScan formats support each of the transaction types, the first usable when either the DTS or TS sources TCK, and the second usable when the DTS sources TCK. This provides the best performance for both DTS sourced or TS sourced TCK. Optimizations are generally different for packets used for non-shift and shift TAP states. An all purpose transaction using the OScan7 format is the exception, as the same packet payload is used for both shift and non-shift TAP states.

OScan7 and OScan3 formats are all purpose transactions. This transaction type is compatible with most systems. Either of these formats supports the systems that have scan rate limitations, as both include stalls within each scan packet. OScan7 is the most versatile, exchanging TDI, TMS, and TDO with TAP state along with stall support. OScan3 deletes the TDI information from non-shift TAP states and deletes TMS information from packets associated with shift TAP states. The TMS values are recreated using the End-of-Transfer escape sequence for these packets.

This transaction type may be used for: Boundary scan, Testing, Non-standard use of TAP states (data transferred in non-shift states—OScan7), and Transfers controlling embedded processors.

A typical transfer would consist of:

OScan7

A series of 4-bit packets.

Packet content the same for all TAP states

OScan3

A series of 3-bit packets.

Packet content contains no TMS for shift TAP states, no TDI for non-shift TAP states

An End-of-Transfer escape sequence to exit TAP shift states

The OScan6 and OScan2 formats are Scan 2× transactions. This transaction type creates a Link-to-TAP clock ratio of 2 to 1 or greater.

This transaction type supports: Transactions that do not have scan-rate limitations, Transactions that do not require TDI in non-shift states, Boundary Scan, Testing, and Transfers controlling embedded processors.

A typical transfer would consist of:

OScan6

A series of 2-bit packets for non-shift states

A series of 3-bit packets for shift states

OScan2

A series of 2-bit packets for all TAP states

An End-of-Transfer escape sequence to exit TAP shift states

The OScan5 and OScan1 formats are Scan 1× transactions. This transaction type creates a Link-to-TAP clock ratio of 1 to 1 or greater. This transaction type supports: Transactions that do not have scan-rate limitations, Transactions that do not require TDI or TDO in non-shift states, Boundary Scan, Testing, and Transfers controlling embedded processors.

A typical transfer would consist of:

OScan5

A series of 1-bit packets for non-shift states

A series of 3-bit packets for shift states

OScan1

A series of 1-bit packets for non-shift states

A series of 2-bit packets for shift states

The OScan4 and OScan0 formats support Download transactions. This transaction type creates a Link-to-TAP clock ratio of 1 to 1 or greater. This transaction type supports:

Transactions that do not have scan-rate limitations, Transactions that do not require TDI or TDO in non-shift states, Boundary Scan, Testing, and Transfers controlling embedded processors.

A typical transfer would consist of:

OScan4

A series of 1-bit packets for non-shift TAP states

A series of 2-bit packets for shift TAP states

OScan0

A series of 1-bit packets all TAP states

Packet optimizations used by each OScan format are summarized in FIG. 99. The OScan optimizations create the packet payloads shown in FIG. 100. Formats other than OScan7 use different optimizations for non-shift and shift states. Delays occur after the last bit of the packet payload shown. The Link-to-Tap clock ratios are shown in FIG. 101.

The packet transitions between packets used for shift and non-shift states for OScan formats (OScan7-4) are shown in FIG. 102. The operation of the Link changes from pipelined to non-pipelined and vice-versa when a data packet contains a TDO bit and the control packet does not. This effect becomes apparent examining the position of the black dots indicating the point the TAP state changes. OScan7 and OScan6 are always non-pipelined. OScan5 switches from non-pipelined to pipelined operation and then back to pipelined operation. OScan4 is always pipelined. The term “pipelined” refers to the capability of handling TDO that is associated with a specific TAP shift state but arrives with a state subsequent to the state with which it is normally associated

The packet transitions between packets used for shift and non-shift states for OScan formats (OScan3-0) are shown in FIG. 103. OScan3 and OScan2 are always non-pipelined. OScan1 switches from non-pipelined to pipelined operation and then back to pipelined operation. OScan0 is always pipelined. The switch between pipelined and non-pipelined operation for the OScan1 format is detailed further in FIG. 104. The TDI bit, where an End-of-Transfer escape sequence occurs to end the shift state, is marked with a gray dot.

Pipelining effects created by the transition from control to data packets and visa versa cause specialized packet payloads to be created when the OScan1 format is used. The transition between pipelined operation in non-shift states and non-pipelined operation in shift states causes shift-length dependent operation for 1, 2, or n states. This is detailed in FIG. 104. Note that the bit sequence for the first two packets associated with TAP shift states are different from the packets associated with subsequent shift states. This is highlighted in FIG. 100.

Transactions using each of the OScan formats are shown in FIGS. 105-112. These transactions span multiple TAP states.

FIG. 105—Oscan 7 Transaction

FIG. 106—Oscan 6 Transaction

FIG. 107—Oscan 5 Transaction

FIG. 108—Oscan 4 Transaction

FIG. 109—Oscan 3 Transaction

FIG. 110—Oscan 2 Transaction

FIG. 111—Oscan 1 Transaction

FIG. 112—Oscan 0 Transaction

The relationship of an OScan Packet and its associated TS TAP state is shown in FIG. 113. Packets that do not contain a TDO value causes a TAP state change ½ TCK after the packet completes. Packets that contain a TDO value cause a TAP state change midway through the TDO bit (½ TCK before the packet ends).

The flow of OScan packets is altered by three interrupts: BDX, CDX, and Register write. The interrupt occurs after the first bit of a new packet, with this bit being discarded by the TS. When the interrupt processing is completed, the scan packet associated with the current TAP state is sent by the DTS with the scan transfer continuing from this point. See FIG. 114.

SScan

Segmented Scans (SScan). The serialization of scan transfers includes formats that allow the partitioning of a single scan operation into segments. This provides the opportunity to create specialized formats that are more efficient than OScan formats. These formats are optimized to support application debug and emphasize performance improvements attainable with modified drivers and hardware.

A transfer is treated as one or more following information types: Control only, Input only, Output only, and Input and output.

The DTS software may schedule segment types to gain extra efficiency, as this can limit the transfer of information to only that which is needed by the DTS and TS. For instance, the data portion of a scan may be constructed from a number of the specialized segments. This minimizes the number of clocks needed to complete a scan transfer. Control-only segments are automatically used in states other than TAP shift states. Within the shift states, the DTS defines a shift operation as a number of segments, defining the length and type of each segment. Segment boundaries are created automatically upon entry into and exit from TAP shift states.

In another instance, transfers to and from memory in an embedded system may be designed to incorporate “inlined” stalls when reading and writing data. This eliminates all software polling, and increases scan efficiency in systems where polling may take place with a conventional implementation. Scan transactions can be optimized further when the DTS is the TCK source, when two SScan use cases are expanded to formats to obtain the best performance for both DTS sourced, or when TS sources TCK (see FIG. 115).

The four Segmented Scan (SScan) formats provide for debug performance improvement by implementing specialized scan transactions that target common debug operations. These formats allow the partitioning of a scan transaction into control and data segments separated by headers. They use a variety of packets to exchange TAP state information between the DTS and TS. They are used when all of the following are true: After Link IDs are assigned, When a single adapter is selected, and When an SScan format is specified. Two examples of an SScan transaction are shown in FIG. 116.

SScan transactions may be used to accelerate: Scan transfers where the scan rate is limited arbitrarily by a component, and Transfers to and from memory, FIFOs, or registers. Performance is maximized when: A scan transaction may be split into different segment types, Segmentation provides efficiencies in excess of the overhead needed for using segments, and The DTS is the clock source.

SScan formats divide scan activity into control and data segments. A segment contains one or more packets, each related to a single TAP state. Segment lengths are determined entirely by the DTS as the protocol does not determine the length of a segment. Control segments are used in TAP states other than TAP shift states while data segments are used in shift TAP states. Entry into a TAP shift state ends a control segment and initiates a data segment. The DTS may, at its discretion, create additional data segments during the shift portion of the scan transaction. A control segment following a data segment causes an exit from the shift state. Control segment content is defined by the scan format.

A header separates adjacent segments when the one of the segments is a data segment. It describes the content of the segment following it as: Input only, Output only, Input and output, and Control.

SScan packets are very similar to OScan packets, but with additional payload types (see FIG. 117). A packet contains one or more of the following:

nTDI—Inverted value of Test Data Input: the TDI TAP value associated with TAP state n

TMS—Test Mode Select: the TMS TAP value associated with TAP state n

END—End of Segment: the last packet of a segment has occurred

RDY—Ready: An indication that identifies whether a frame transfer may proceed

TDO—Test Data Output: The TDO TAP value associated with TAP state n

DLYn—Delay: Zero to n delay bits, 0, 1, 2 fixed delays, 3 to n bit variable delay

The template for SScan packets is shown in FIG. 118. These packets may: Be from 1 to 4 bits in length, Carry different information for different TAP states, and Support output only. Including a RDY bit also requires the inclusion of a TDO bit. The delay is eliminated when the DL1[1:0] field specifies no delay. Since a single packet template is used, the underlying hardware merely populates the template for each TAP state. The packet content is defined by a combination of control register setting (scan format), header value, TAP state, and stalls that may extend the packet length. The nTDI, TMS, RDY, and TDO bits have the same characteristics as described in the section on OScan. END bits are inserted in the packet payload to indicate an end of segment when an SScan2 or SScan3 format is used. An END bit of one (1) indicates the last packet of the segment while a zero (0) indicates the packet contains at least one more packet. When an SScan0 or SScan1 format is used, the End-of-Transfer escape sequence is used to indicate an end of segment. The absence of an End-of-Transfer indicates the segment continues for at least one more packet.

Headers separate segments and perform the following functions: Select one of two transaction types available to a SScan format, Define the payload type (I, O, IO), and Allow initiation of a CDX transfer. The transaction type is specified once per Shift_DR state while the payload may be defined once per each data and control segment. A CDX transfer may be initiated following entry into the Shift_DR state.

Two header lengths are used to manage segments: Long (3-bit)—Following a control segment upon entry into a TAP shift state, and Short (2-bit)—Following a data segment. Headers precede data and control segments as shown in FIG. 119. There are no headers between consecutive control segments.

When a two-bit header follows a three-bit header, the newly transmitted HDR(0) and HDR(1) bits are concatenated with the HDR(2) bit sent by the previously transmitted 3-bit header to the 3-bit header. The resulting value is used to define segment characteristics. This is shown below:

embedded image

The transaction type is specified at the beginning of the shift state along with the payload of the first segment with a long header. Payloads of subsequent data segments are specified, without changing the transaction type, using a short header. This provides the DTS the means to use more than one specialized capability without changing the SScan format. A header does not affect the segment behavior outside the shift states except for causing an exit from the shift state and defining the next segment as a control segment. Control segment characteristics are defined entirely by the SScan format.

The 3-bit header value is decoded as shown in FIG. 120. The HDR(2) bit selects one of two SScan transaction types available to the format while the HDR(1) and HDR(0) bits specify the segment payload (I, O, or IO).

A header value of “011” or “111” is interpreted differently when this header follows a control segment as opposed to the header following a data segment. When either of these values follows a control segment, an input only segment is specified with the initiation of a CDX transfer permitted. When either of these values follows a data segment, the shift state is exited with the next segment a control segment. See FIG. 121 for a list of transaction types.

A CDX transfer may be activated following the first packet of the first segment when: The TAP state is Shift_DR, An“x11” header precedes a data segment following a control segment, and CDX has been previously enabled through the control register. When this procedure is used, a CDX operation is initiated in lieu of the first data segment following a control segment and continues until the Shift_DR state is exited as the TAP state is advanced within the CDX transfer.

The packet separation and delay for SScan formats is identical to that discussed in the MScan Section. The packet delay follows the packet information with the same delay options as with MScan packets.

SScan formats raise the scan transaction efficiency by combining three different optimizations in addition to segmentation: Paced (P)—selectively use scan transaction stalls to control segment progression, Buffered (B)—transfers between target TAPs and the adapter JTAG interface may be buffered, and Accelerated (A)—transfer segments with no TS output at TCK rate, others at TS rate.

Paced optimization is used to increase performance for debug operations such as memory reads or writes. It may also be used for other applications. Information needed to perform an operation is packaged as segments designed to perform a fixed amount of work within the TS. Paced optimization provides a means for the TS to stop scan progression at segment boundaries until the TS is ready to proceed. Scan progression may be managed one of two ways, stopping the transaction: At the beginning of segment n during the first packet of segment n, and After segment n during the first packet of segment n+1.

A stall is included in the first packet of each segment. The TS may delay an incoming transaction until the prior transaction has completed processing before or after accepting input. The TS may delay an outgoing transaction until it has data to supply to the transaction before or after generating output. This approach eliminates software polling of the TS. Scan transactions merely stall until the TS is ready to complete the transaction. The TS may incorporate a timeout as part of these operations, if there is a risk of transactions going “not ready” indefinitely. The payload is merely extended to include timeout status, if needed. Examples of IO pacing are shown in FIG. 122.

Buffered optimization is used in combination with paced optimization. It is used to increase scan performance in cases where scan transfers can buffer input and output. It can also be used with non-buffered transfers. The DTS creates control and data segments that are less than or equal to the size of the scan input buffer. Control-only segments fill the input buffer at the TCK rate. The buffer is emptied at the TS rate. The TS uses the stall in the first packet of the segment to delay the next segment until it has emptied the input buffer. Emptying the buffer occurs at a rate determined by the TS. All control and data segments are treated the same. Two examples of buffered scan transaction are shown in FIG. 123.

Acceleration optimization is used in combination with segmented, paced, and buffered optimizations. It is used to increase scan performance in cases where the scan rate is limited arbitrarily by a component (such as ARM9 and ARM11 cores). With accelerated optimization, data segments that contain TS output are treated differently than control segments and input only data segments. With these segments, input buffering is bypassed and transactions occur on a bit-by-bit basis. Each packet transferring TS output includes a stall, with the TS using the stall to delay output until it is ready to supply output. Two examples of accelerated scan transactions are shown in FIG. 124.

The SScan optimizations (P, B, and A) are used to create the four transaction types as shown in FIG. 33. Collectively, these transaction types incorporate differing degrees of optimization. Two transactions support input buffering and two do not. The transactions types that do not support buffering provide greater efficiency, as the DTS waits less on TS completion than on any other operation. There are two versions of each of these types, one supporting a TS-supplied TCK and the other supporting a DTS-supplied TCK. The use of specific transaction types requires the supporting hardware outlined in FIG. 125.

Type 0 transactions provide a simple way of reducing the transmission of unneeded scan information. This transaction type may be used where the Link and JTAG interfaces run at the TCK rate. There are no transaction stalls. Headers are the only overhead added to the scan. This transaction type supports: Boundary scan, Unidirectional scans, and Optimized transfers controlling embedded processors. This transaction type provides: TCK transaction rate, A single control segment, DTS definition of data segment size, and Segments of any length. A typical transfer would consist of: