JTAG circuit transferring data between devices on TMS terminals

The present disclosure describes using the JTAG Tap's TMS and/or TCK terminals as general purpose serial Input/Output (I/O) Manchester coded communication terminals. The Tap's TMS and/or TCK terminal can be used as a serial I/O communication channel between; (1) an IC and an external controller, (2) between a first and second IC, or (3) between a first and second core circuit within an IC. The use of the TMS and/or TCK terminal as serial I/O channels, as described, does not effect the standardized operation of the JTAG Tap, since the TMS and/or TCK I/O operations occur while the Tap is placed in a non-active steady state.

BACKGROUND OF THE DISCLOSURE

Field of the Disclosure

This disclosure relates in general to circuit designs, and in particular to an improvement in the design of IEEE 1149.1 Tap interfaces of ICs and core circuits for improved communication of test, debug, emulation, programming, and general purpose I/O operations.

Today's ICs may contain many embedded 1149.1 Tap architectures (Tap domains). Some of these TAP domains are associated with intellectual property (IP) core circuits within the IC, and serve as access interfaces to test, debug, emulation, and programming circuitry within the IP cores. Other TAP domains may exist in the IC which are not associated with cores but rather to circuitry in the IC external of the cores. Further, the IC itself will typically contain a TAP domain dedicated for operating the boundary scan register associated with the input and output terminals of the ICs, according to IEEE std 1149.1.

FIG. 1illustrates a simple example of an IEEE 1149.1 Tap domain102. The Tap domain includes a Tap controller104, an instruction register (IR)106, at least two data registers (DR)108, and multiplexer circuitry110. The Tap domain interface consists of a TDI input, a TCK input, a TMS input, a TRST input, and a TDO output. In response to TCK and TMS control inputs to Tap controller104, the Tap controller outputs control to capture data into and shift data through either the IR106from TDI to TDO or a selected DR108from TDI to TDO. The data shifted into IR106is updated and output on bus114to other circuits, and the data shifted into a DR108is updated and output on bus112to other circuits. DR108may also capture data from other circuits on bus112and IR106may capture data from other circuits on bus114. In response to a TRST input to the Tap controller104, the TAP controller, IR and DR are reset to known states. The structure and operation of IEEE 1149.1 Tap domain architectures like that ofFIG. 1are well known.

FIG. 2illustrates the state diagram of the Tap controller104. All IEEE 1149.1 standard Tap controllers operate according to this state diagram. State transitions occur in response to TMS input and are clocked by the TCK input. The IEEE 1149.1 Tap state diagram is well known.

FIG. 3illustrates an example system where a number of Tap domain102interfaces of ICs306-312or embedded cores306-312within ICs are connected together serially, via their TDI and TDO terminals, to form a scan path302from TDI304to TDO306. Each Tap domain102of the ICs/cores306-312are also commonly connected to TCK314, TMS316, and TRST318inputs. The scan path's TDI304, TDO306, TCK314, TMS316, and TRST318signals are coupled to a controller, which can serve as a test, debug, emulation, in-system-programming, and/or other application controller. While only four Tap domains102of ICs/cores306-312are shown, any number of IC/core Tap domains may exist in scan path302, as indicated by dotted line322. The scan path302arrangement of IC/core Tap domains is well known in the industry.

As seen inFIG. 3, if data is to be input to Tap domain102of IC/core312from controller320it must serially pass through all leading Tap domains of ICs/cores306-310. Further, if data is to be output from Tap domain102IC/core306to controller320it must pass through all trailing Tap domains of ICs/cores308-312. Thus a data input and output latency exists between Tap domains of ICs/cores in scan path302and controller320. As will be seen later, the present disclosure provides a way to eliminate this data input and output latency by making use of the direct TMS316and/or TCK314connections between the Tap Domains of ICs/cores306-312and controller320. Having a direct connection for data input and output between the controller320and the Tap domains102, via the TMS and/or TCK connections, provides improved data communication throughput during test, debug, emulation, in-circuit-programming, and/or other type of operations. Further, using the direct TCK and/or TMS connections for data input and output between controller320and Tap domains102only involves the controller and the targeted Tap domain. Non-targeted Tap domains are not aware of or affected by the direct TMS and/or TCK communication.

SUMMARY OF THE DISCLOSURE

The present disclosure provides a method and apparatus of communicating data between; (1) an IC in a scan path and a controller of the scan path using the standard direct TMS and/or TCK connections that exists between the IC and controller, (2) a first IC of a scan path and a second IC of the scan path using the direct TMS and/or TCK connections between the lOs, (3) a first core circuit of a scan path in an IC and second core circuit of the scan path of the IC using the direct TMS and/or TCK connections between the cores. The TMS and/or TCK data I/O communication occurs while the Tap controller of the Tap domains of the IC/core are in a non-active state. Thus the TMS and/or TCK I/O communication does not disturb or modify the state of Tap domains of the IC/core in a scan path. The TMS and/or TCK I/O communication is achieved by adding circuitry to the IC/core and coupling the circuitry to the TMS and/or TCK terminals of the IC's/core's Tap domain. When enabled by control output from the IC's/core's Tap domain, the added circuitry becomes operable to input data from the Tap domain's TMS and/or TCK terminal or output data onto the Tap domain's TMS and/or TCK terminal. Conventional controllers320coupled to the TMS and TCK signals are improved, according to the present disclosure, such that they can input data from a Tap domain's TMS and/or TCK terminal and output data to a Tap domain's TMS and/or TCK terminal.

DETAILED DESCRIPTION

FIG. 4illustrates a scan path system402of ICs/cores that include Tap domains plus additional TMS I/O circuitry. The combination of the Tap domain and TMS I/O circuitry is referred to as TAPIO416.FIG. 4is similar toFIG. 3in regard to the way the TDI, TDO, TCK, TMS, and TRST signals are coupled between the TAPIOs416and controller420. Controller420is different from controller320in that it has been improved according to the present disclosure to include the capability of communicating data to and from the TAPIOs416via the TMS connection. Controller420maintains the conventional ability of controller320to communicate the Tap domains of the TAPIOs416using the standard IEEE 1149.1 serial protocol. As seen, the TMS connection between controller420and TAPIOs416is shown as a bidirectional signal path, as opposed to the unidirectional signal path of the TMS connection inFIG. 3. When a TAPIO416is selected for sending data to the controller420according to the present disclosure, the TMS connection will become an output from the TAPIO and an input to the controller. When a TAPIO416is selected for receiving data from the controller420according to the present disclosure, the TMS connection will become an output from the controller and an input to the TAPIO. As can be seen inFIG. 4, data is transferred directly between a selected TAPIO416and controller420. Therefore the data latency problem mentioned in regard withFIG. 3does not exist inFIG. 4.

Additionally, according to the present disclosure, one TAPIO of an IC/core in the scan path may communicate to another TAPIO of an IC/core in the scan path via the common bidirectional TMS connection. To achieve this mode of operation, the controller420selects one TAPIO to transmit and another TAPIO to receive. The controller then disables its TMS output driver so that the transmitting TAPIO can output on its TMS terminal to send data to the TMS terminal of the receiving TAPIO. Again, the data is directly transferred between the TAPIOs without the aforementioned latency problem.

FIG. 5illustrates the TAPIO circuit416in more detail. As seen the TAPIO416consists of a Tap domain502, a TMS communication circuit514, And gates506-508, and a Clock Source circuit528. The Clock Source528can be a clock producing circuit within the IC or it can come from a pin of the IC. Tap domain502is similar to Tap domain102with the exception that it includes And gate504for detecting when the Tap controller104is in the Run Test/Idle (RTI) state202ofFIG. 2. The Tap controller104is a four bit state machine defining the 16 unique states shown inFIG. 2. Each of the 16 Tap states is defined by a unique one of the four bit state machine codes. While not shown, the four inputs of the And gate504are inverted or not inverted to allow the And gate to detect, with a logic high output, when the Tap controller is in the Run Test/Idle state. For example, if the Run Test/Idle state has a four bit code of 0101, then the “0” inputs to And gate504will be inverted such that the And gate will receive all “1's” at its inputs so that it outputs a logic one when the Tap controller is in the Run Test/Idle state. This will be the case throughout the remainder of this specification for all And gates that are described for use in detecting Tap controller states. Also while And gates are shown being used to detect Tap controller states, other gating circuits may be used as well.

Further, Tap domain502differs from Tap domain102in that it includes an Enable TMS Output signal510and an Enable TMS Input signal512. The Enable TMS Output signal is set whenever the TMS communication circuit514is to perform a data output operation on TMS. The Enable TMS Input signal is set whenever the TMS communication circuit514is to perform a data input operation on TMS. As seen, the Enable TMS Input or Enable TMS Output signals can come, by design choice, from either the IR106via bus114or from a DR108via bus112.

When Enable TMS Output is set high and when the Tap controller104is in the Run Test/Idle (RTI) state202, the output of And gate506will go high to enable the TMS communications circuit514to perform a TMS output operation. When Enable TMS Input is set high and when the Tap controller104is in the Run Test/Idle (RTI) state, the output of And gate508will go high to enable the TMS communications circuit514to perform a TMS input operation. During either TMS communication operation, the Tap controller104remains in the Run Test/Idle state202.

TMS communication circuit514consists of a Frame Counter516, And gate520, TMS I/O Circuit526, Data Source522, and Data Destination524. The Frame Counter516is a data register108that can be scanned via TDI and TDO by the Tap controller104to load a count of the number of data frames that are to be sent from the Data Source522during a TMS output operation. A data frame in this disclosure is defined by a fixed number of transmitted data bits. After being scanned, and when enabled by the output of And gate506, the Frame Counter operates as a counter to count the number of data frames output on TMS. After all data frames have been sent out on TMS, the count complete (CC) output from the Frame Counter will go low to halt the TMS output operation of TMS I/O Circuit526, via And gate520. And gate520is gated on and off by the Enable TMS Output signal being high and low respectively. When gated off, the CC output from the Frame Counter cannot inadvertently, say during an 1149.1 operation that passes through the Run Test/Idle state, enable the TMS I/O Circuit526. The Frame Counter receives IR & Tap Control input via bus530for scanning in the count, control input518from the TMS I/O Circuit526for knowing when to count a frame, and a clock input from the Clock Source circuit528.

When enabled for inputting data from TMS, the TMS I/O Circuit526receives the TMS data and transfers it to the Data Destination circuitry524. Data Destination circuitry524may be any circuitry within an IC including but not limited to; (1) an address bus, (2) a data bus, (3) a Ram memory, (4) a Cache memory, (5) a register file, (6) a FIFO, (7) a register, (8) a processor, (9) a peripheral circuit, or (10) a bus coupled to circuitry external to the IC.

When enabled for outputting data on TMS, the TMS I/O Circuit526receives data from the Data Source circuitry522and outputs the data on TMS. Data Source circuitry522may be any circuitry within an IC including but not limited to; (1) an address bus, (2) a data bus, (3) a Ram memory, (4) a Rom memory, (5) a Cache memory, (6) a register file, (7) a FIFO, (8) a register, (9) a processor, (10) a peripheral circuit, or (11) a bus coupled to circuitry external to the IC.

FIG. 6illustrates TMS I/O Circuit526in more detail. TMS I/O Circuit consists of a Data & Clock Decoder604, Input Register602, Data & Clock Encoder614, and Output Register612. As will be described in more detail later, the TMS communication is based on Manchester data communication whereby the clock and data signals are combined and transmitted together on TMS.

The function of the Data & Clock Decoder604is to receive a frame of Manchester encoded data on TMS terminal316, extract the data606and clock (CK)608components from the encoded data, and input the data606serially to Input Register602in response to the extract CK signal608. Enable (EN) signal628enables Input Register602to receive the data606. Input Register602, once filled with a complete serial data frame, outputs the data frame in parallel to Data Destination524via data bus622. CK signal608and Data In Ready control signal606controls the Data Destination to receive the parallel data from bus622. This process of receiving Manchester encoded serial data frames from TMS terminal316, decoding the serial data frames into parallel data patterns, and inputting the parallel data patterns to Data Destination524is repeated until the TMS input communication operation is completed.

The function of the Data & Clock Encoder614is to control the Output Register612, via Enable (EN)626, CK618and Data Output Ready616signals, to receive parallel data patterns from the Data Source522via bus624and output the data serially, via Data signal620, to the Data & Clock Encoder614. The Data & Clock Encoder614encodes the serial input data620with a clock from Clock Source528to produce a frame of serial Manchester encoded data to be output on TMS terminal316. This process of receiving a parallel data pattern from the Data Source522, converting the parallel data pattern into a frame of serial Manchester encoded data, and outputting the frame of serial Manchester encoded data onto TMS terminal316is repeated until all the parallel data patterns from Data Source522have been serially transmitted from TMS terminal316. As seen inFIG. 6, the Data Out Ready signal616, which controls the input of parallel data patterns from the Data Source to the Output Register is also input to Frame Counter516to control the frame count. The count value in the Frame Counter516controls the number of parallel data patterns that are output as encoded serial frames from TMS316. The Frame Counter516decrements once per each Data Out Ready signal. As seen inFIG. 5, when the frame count in Frame Counter516expires, the Frame Counter halts the TMS serial output operation by setting the count complete (CC) signal low.

FIG. 7illustrates a timing example of the Data & Clock Decoder circuit604receiving Manchester encoded data on TMS terminal316. Manchester encoding, is well known and operates by sending an encoded signal as a pair of opposite bits. In the timing diagram, each pair of opposite bits are shown within boxes708. Each box represents a Manchester encoded signal. In one example of Manchester encoding, an encoded logic one is represented by a logic zero bit followed by a logic one bit, and an encoded logic zero is represented by a logic one bit followed by a logic zero bit. An alternate Manchester encoding reverses the polarity of the bit pair for an encoded logic one and encoded logic zero.

As seen the Manchester Decoder circuit702in circuit604, when enabled by Input Enable, becomes operable to receive Start signals704, four logic ones in this example, from TMS316. More than two consecutive logic ones is an illegal Manchester bit encode, therefore more than two logic ones can be used as an indication to initialize the Manchester Decoder for receiving serial frames of encoded TMS data. While two Start signals, each comprising two logic ones, are shown in this example, more Start signals may be used if desired. After recognizing the Start signals, the Manchester Decoder receives frames 1-N of Manchester encoded serial data from TMS316. The Manchester Decoder extracts the Data and CK components from each Manchester encoded bit in the frame and shifts the extracted Data into the Serial Input Parallel Output (SIPO) Register602. The Enable output from the Manchester Decoder enable the SIPO Register602to receive data. After each frame is decoded and shifted into SIPO Register602, the Manchester Decoder outputs the Data In Ready signal to Data Destination524. In response to the Data In Ready signal the Data Destination receives (stores and/or processes) the parallel output of Register602. This process continues until the Manchester Decoder receives Stop signals706, four logic zeros in this example, from TMS316. More than two consecutive logic zeros is an illegal Manchester bit encode, therefore more than two logic zeros can be used as an indication to cause the Manchester Decoder to stop receiving serial frames of encoded TMS data. While two Stop signals, each comprising two logic zeroes, are shown in this example, more Stop signals may be used if desired.

FIG. 8Aillustrates a more detail example of Manchester Decoder circuit702. The Manchester Decoder702consists of a Manchester Decoder State Machine802and a Bit Counter806. The state machine802receives the TMS signal from TMS terminal316, a clock signal from Clock Source528, the Input Enable signal from And gate508, and a count complete (CC) signal from Bit Counter804. The state machine outputs a Data signal to SIPO Register602, a clock (CK) signal to SIPO Register602and Data Destination524, an Enable signal to SIPO Register602, the Data In Ready signal to Data Destination524, count control to Bit Counter804.

FIG. 8Billustrates the operation of state machine802. When the Input Enable signal is set high, the state machine begins sampling the TMS input for Start signals704. The frequency of the Clock Source is set sufficiently high to allow over-sampling of the TMS input signal. After Start signals are detected, the state machine begins sampling the TMS input to decode the Manchester encoded bit pairs708. Each time a bit pair is decoded, the appropriate Data value is clocked into SIPO Register602by the CK signal and the Bit Counter is clocked by counter control outputs. During the decode operation, the state machine monitors the CC input from the counter804. When a CC signal is detected, indicating that the number of bits received is equal to a full frame of bits, the state machine sets the Data In Ready signal high to enable the Data Destination to receive the full frame of bits from the parallel output from SIPO Register602. This process continues until the state machine receives the Stop signals706on the TMS signal, indicating the end of the transmission of Manchester encoded data frames. The state machine transitions to the Stop state and waits for the Input Enable signal to be set low by the Tap controller104exiting the Run Test/Idle state. A subsequent JTAG scan operation to either the DR108or the IR106register (i.e. the register from which it came) can set the Enable TMS input signal512low. When Input Enable goes low, the state machine802transitions back to the Input Enable state.

FIG. 9illustrates a timing example of the Data & Clock Encoder circuit614outputting Manchester encoded data on TMS terminal316. In the timing diagram, each Start704, Data708, and Stop706bit signals are again illustrated as they were inFIG. 7. As seen the Manchester Encoder circuit902in circuit614, when enabled by Output Enable, becomes operable to transmit Start signals704, four logic ones in this example, onto TMS316. Since the TMS terminal of an IC or Core is normally driven by a controller420, the controller must disable its drive of the TMS terminal to allow the TMS terminal of the IC or Core to become an output to drive the TMS of the controller during TMS output modes of operation. The disabling of the TMS controller output is indicated a “Z” in the timing diagram.

As seen, a 3-state buffer904inside the Manchester Encoder902becomes enabled during TMS output operation to drive the TMS terminal of the IC or core. After transmitting the Start signals, the Manchester Encoder loads parallel data into the Parallel Input Serial Output (PISO) Register612from the Data Source522and starts shifting the PISO Register612. Each bit shifted from the PISO Register to the Manchester Encoder is appropriately encoded as a Manchester bit pair signal708and transmitted out of the IC or core via the TMS terminal316. As seen the transmission of the Manchester bit pairs begins following the last transmitted Start signal. The Manchester Encoder combines the data and clock components together such that a Manchester Decoder702in the receiving controller420or other IC/core can extract the components back into separate data and clock signals. The Enable output from the Manchester Encoder enables the PISO Register612to load and shift out data. The serial data shifted out from one parallel load of the PISO Register forms one serial bit frame. After each frame is shifted out of the PISO Register612, the Manchester Encoder outputs the Data Out Ready signal to PISO Register612and Data Source522. In response to the Data Out Ready signal the PISO Register612inputs parallel data from Data Source522to began the next serial output frame that is encoded and output on TMS316. This process continues until the Output Enable input to the Manchester Encoder goes low, at which time the Manchester Encoder outputs Stop signals706, four logic zeros in this example, onto TMS316and disables the output buffer904, ending the TMS output operation.

FIG. 10Aillustrates a more detail example of Manchester Encoder circuit902. The Manchester Encoder902consists of a Manchester Encoder State Machine1002, Bit Counter1004, TMS buffer904, and Clock Divider (CD)906. The state machine1002receives the Data output signal from PISO Register612, a clock signal from Clock Source528via Clock Divider906, the Output Enable signal from And gate520, and a count complete (CC) signal from Bit Counter1004. The state machine outputs a clock (CK) signal to PISO Register612and Data Source522, an Enable signal to PISO Register612, a Data Out Ready signal to PISO Register612and Data Source522, count control to Bit Counter1004, and encoded data to TMS316via buffer904.

FIG. 10Billustrates the operation of state machine1002. When the Output Enable signal is set high, the state machine enables the output buffer904and outputs Start signals704onto TMS316. Also the first parallel data pattern from Data Source522is loaded into PISO Register612. After sending the Start Bits, the state machine begins encoding the serial output data shifted from PISO Register612into Manchester encoded outputs on TMS316. The frequency of the CK output from the state machine1002is sufficiently less than the frequency of the clock output from the Clock Divider906to allow each data bit shifted out of PISO Register612to be encoded into the appropriate Manchester bit pair signal708. Each time an encoded bit pair is output on TMS316, the Bit Counter counts in response to control inputs from state machine1002. During the encoding operation, the state machine monitors the CC input from the Bit Counter1004. When a CC signal is detected, indicating that the last bit of the current bit frame is being shifted out of PISO Register612, the Data Out Ready signal is set to cause the next parallel data pattern from Data Source522to be loaded into PISO Register612to allow starting the next frame of data bit outputs from the Register612. Each data bit of each new frame of data loaded and shifted out of PISO Register612is encoded into Manchester bit pairs and output on TMS316. This process continues until the state machine1002detects the Output Enable signal going low, as a result of the count in Frame Counter516expiring and setting its frame count complete CC signal low, which in turn sets the Output Enable signal low via And gate520. When Output Enable is detected low, the state machine1002outputs the Stop signals706to indicate to controller420or other IC/core that the transmission of Manchester encoded data frames has come to an end. The state machine then disables output buffer904from driving the TMS terminal316and transitions to the Output Enable state of the diagram. When the TMS output operation is ended, the controller420enables its TMS output, transitions the Tap104from the Run Test/Idle state to set the Enable TMS Output signal low by a JTAG scan operation to either the DR108or the IR106register from whence it came.

Preferably the Clock Sources528in the transmitting and receiving devices (i.e. controller420, IC, or core) are of the same frequency. This would ensure that, by the use of Clock Divider906of Manchester Encoder902, the data encoded and output from a transmitting device's Manchester Encoder902will be at a bit rate easily over-sampled and decoded by the non-divided Clock Source528driving the Manchester Decoder702in a receiving device. A test that TMS data transmitted from Encoder902at the divided Clock Source rate is properly received by Decoder702at the full Clock Source rate can be achieved by simply enabling both circuits in the same device to operate simultaneously to transmit and receive data over their common TMS connection, then check that the data received in the Data Destination circuit524is correct.

As seen in the TMS Manchester communication timing diagrams ofFIGS. 7 and 9, the format of a TMS output operation is the same as the format a TMS input operation. Both formats include a header of at least two Start signals704followed by frames of Manchester data signals708followed by a trailer of at least two Stop signals706. This allows simple and standardized data communication between a TMS transmitting device (i.e. controller420, IC, or core) and a TMS receiving device (i.e. controller420, IC, or core). Other more complex formats may also be implemented as the need arises, such as formats that include frames for addressing and commanding operations to support more sophisticated communication needs.

FIG. 11illustrates how a TMS I/O operation is initiated by the Tap controller transitioning into the Run Test/Idle state202. Prior to transitioning into the Run Test/Idle state, a scan operation will have been performed to set the Enable TMS Output510or Enable TMS Input512signal high, depending upon whether an TMS input or TMS output is desired. Also if it is a TMS output operation, the Frame Counter516is loaded with the frame count value. Once this setup procedure is accomplished, the Tap controller104is transitioned into the Run Test/Idle state as shown inFIG. 11. Once in the Run Test/Idle state, the TCK clock is halted at a low logic level. The RTI signal is set which enables And Gates506and508to pass the Enable TMS Input or Output signals510and512to TMS communication circuit514. The selected TMS input or TMS output operation begins at time1102and is executed during time1104as shown inFIG. 11while the Tap is in the Run Test/Idle state with the TCK halted. When the TMS input or TMS output operation is competed at time1106, the TMS and TCK signal may once again be operated by the controller420to transition the Tap controller104through its states. As can be seen, with the Tap controller in the Run Test/Idle state and with the TCK halted, TMS input and TMS output operations are completely transparent to the Tap controller and all IEEE 1149.1 circuitry connected to the Tap controller. While this example halts the TCK at a low logic level, the TCK could be halted at a high logic level as well.

FIG. 12is provided to illustrate that other Tap controller states, other than Run Test/Idle, may be used to perform TMS input and TMS output operations. For example, the Shift-DR state1202, the Pause-DR state1204, the Shift-IR state1206, and the Pause-IR state1208all may be used in addition to the Run Test/Idle state for TMS input and output operation modes. To use these additional Tap controller states as states in which TMS input and output operations may be performed is simply a matter of providing And gates1210to decode when the Tap controller is in one of the states, as And gate504did for detecting the Run Test/Idle state, and providing an Or gate1212for indicating when any of the And gate1210outputs are high. The output of the Or gate1212would be substituted for the RTI output of And gate504inFIG. 5and input to And gates506and508. With this substitution made, the TCK could be halted in any one of these states to allow the TMS I/O operation to be started, executed, and stopped, as was shown and described in regard to the Run Test/Idle state ofFIG. 11. While And/Or gating is shown in this example, other gating circuitry types could be used as well to detect the other Tap states.

FIG. 13illustrates an example of the TMS I/O operation of the present disclosure being performed between an IC1302of a scan path402and a controller420as shown inFIG. 4. If the controller is performing a TMS output operation, the IC will be performing a TMS input operation to receive the data from the controller via the TMS connection. If the IC is performing a TMS output operation, the controller will be performing a TMS input operation to receive the data from the IC via the TMS connection.

FIG. 14illustrates an example of the TMS I/O operation of the present disclosure being performed between a first1402and second1404IC of a scan path402. If IC1402is performing a TMS output operation, IC1404will be performing a TMS input operation to receive the data from IC1402via the TMS connection. If IC1404is performing a TMS output operation, IC1402will be performing a TMS input operation to receive the data from IC1404via the TMS connection. During these operations, the TMS output of controller420ofFIG. 4will need to be disabled to allow the TMS terminal of the outputting IC to drive the TMS connection between the lOs.

FIG. 15illustrates an example of the TMS I/O operation of the present disclosure being performed between a first1502and second1504core circuit within an IC of scan path402. If core1502is performing a TMS output operation, core1504will be performing a TMS input operation to receive the data from core1502via the TMS connection. If core1504is performing a TMS output operation, core1502will be performing a TMS input operation to receive the data from core1504via the TMS connection. During these operations, the TMS output of controller420ofFIG. 4, or the output of an internal buffer in the IC being driven by the TMS output of controller420will need to be disabled to allow the TMS terminal of the outputting core to drive the TMS connection between the cores.

In all of the examples inFIGS. 13-15, the TMS I/O data communication between the devices (IC and controller, IC and IC, core and core) is performed directly and without introducing any communication latency by having to pass the communicated data through any other devices. Further, devices not involved in the TMS I/O communication are not effected by the TMS I/O communication.

FIG. 16illustrates a scan path system1602of ICs/cores that include Tap domains plus additional TCK I/O circuitry. The combination of the Tap domain and TCK I/O circuitry is referred to as TAPIO1616.FIG. 16is similar toFIGS. 3 and 4in regard to the way the TDI, TDO, TCK, TMS, and TRST signals are coupled between the TAPIOs1616and controller1620.FIG. 16is different fromFIG. 4in that communication is provided between the controller1620and TAPIO1616via the TCK signal314instead of via the TMS signal316. Controller1620is different from controller420ofFIG. 4in that it has been improved according to the present disclosure to include the capability of communicating data to and from the TAPIOs1616via the TCK connection. As with controller420, controller1620maintains the conventional ability of controller320to communicate the Tap domains of the TAPIOs1616using the standard IEEE 1149.1 serial protocol. As seen, the TCK connection between controller1620and TAPIOs1616is shown as a bidirectional signal path, as opposed to the unidirectional signal path of the TCK connection inFIG. 3. When a TAPIO1616is selected for sending data to the controller1620according to the present disclosure, the TCK connection will become an output from the TAPIO and an input to the controller. When a TAPIO1616is selected for receiving data from the controller1620according to the present disclosure, the TCK connection will become an output from the controller and an input to the TAPIO. As can be seen inFIG. 16, data is transferred directly between a selected TAPIO1616and controller1620. Therefore the data latency problem mentioned in regard withFIG. 3does not exist inFIG. 16.

Additionally, according to the present disclosure, one TAPIO of an IC/core in the scan path may communicate to another TAPIO1616of an IC/core in the scan path via the common bidirectional TCK connection. To achieve this mode of operation, the controller1620selects one TAPIO to transmit and another TAPIO to receive. The controller then disables its TCK output driver so that the transmitting TAPIO can output on its TCK terminal to send data to the TCK terminal of the receiving TAPIO. Again, the data is directly transferred between the TAPIOs without the aforementioned latency problem.

FIG. 17illustrates the TAPIO circuit1616in more detail. As seen the TAPIO1616consists of a Tap domain502, a TCK communication circuit1714, And gates506-508, a Clock Source circuit528, and a D flip flop1702. The Clock Source528can be a clock producing circuit within the IC or it can come from a pin of the IC. Tap domain502is similar to Tap domain102with the exception that it includes the previously described And gate504for detecting when the Tap controller104is in the Run Test/Idle (RTI) state202ofFIG. 2, and that it includes an Enable TCK Output signal1710and an Enable TCK Input signal1712. D flip flop1702has a data (D) input and a reset (R) input coupled to the output of And gate504, an inverted clock input coupled to TCK314, and a data (Q) output (RTI) coupled to an input of And gates506and508. The Enable TCK Output signal is set whenever the TCK communication circuit1714is to perform a data output operation on TCK. The Enable TCK Input signal is set whenever the TCK communication circuit1714is to perform a data input operation on TCK. As seen, the Enable TCK Input or Enable TCK Output signals can come, by design choice, from either the IR106via bus114or from a DR108via bus112.

When the Tap controller104is in the Run Test/Idle state202the output of And gate504will be high, placing a logic one on the data input and the reset input of D flip flop1702. With the Tap controller in Run Test/idle, the RTI output of D flip flop1702will go high on the falling edge of TCK via the logic one output from And gate504. When the Tap controller exits from the Run Test/Idle state, the RTI output of And gate504goes low by the output of And gate504going low, which resets the RTI output of D flip flop1702to a logic zero.

When Enable TCK Output is set high and the RTI output of D flip flop1702is high, the output of And gate506will go high to enable the TCK communications circuit1714to perform a TCK output operation. When Enable TCK Input is set high and the RTI output of D flip flop1702is high, the output of And gate508will go high to enable the TCK communications circuit1714to perform a TCK input operation. During either TCK communication operation, the Tap controller104remains in the Run Test/Idle state202since the TMS signal316input from controller1620will be held low.

The structure and operation of TCK communication circuit1714is the same as TMS communication circuit514ofFIG. 5with the exception that TCK I/O Circuit1726has been substituted for TMS I/O Circuit526.

When enabled for inputting data from TCK, the TCK I/O Circuit1726receives the TCK data and transfers it to the Data Destination circuitry524. Data Destination circuitry524may be any circuitry within an IC including but not limited to; (1) an address bus, (2) a data bus, (3) a Ram memory, (4) a Cache memory, (5) a register file, (6) a FIFO, (7) a register, (8) a processor, (9) a peripheral circuit, or (10) a bus coupled to circuitry external to the IC.

When enabled for outputting data on TCK, the TCK I/O Circuit1726receives data from the Data Source circuitry522and outputs the data on TCK. Data Source circuitry522may be any circuitry within an IC including but not limited to; (1) an address bus, (2) a data bus, (3) a Ram memory, (4) a Rom memory, (5) a Cache memory, (6) a register file, (7) a FIFO, (8) a register, (9) a processor, (10) a peripheral circuit, or (11) a bus coupled to circuitry external to the IC.

FIG. 18illustrates TCK I/O Circuit1726in more detail. TCK I/O Circuit1726is the same as TMS I/O Circuit526ofFIG. 6with the exception that it uses the TCK signal314for communication instead of the TMS signal316.

As described previously in regard to TMS I/O Circuit526, the function of the Data & Clock Decoder604ofFIG. 18is to receive a frame of Manchester encoded data on TCK terminal314, extract the data and clock (CK) components from the encoded data, and input the data serially to Input Register602in response to the extract CK signal. Input Register602, once filled with a complete serial data frame, outputs the data frame in parallel to Data Destination524via data bus622. CK signal and Data In Ready control signal controls the Data Destination to receive the parallel data from bus622. This process of receiving Manchester encoded serial data frames from TCK terminal314, decoding the serial data frames into parallel data patterns, and inputting the parallel data patterns to Data Destination524is repeated until the TCK input communication operation is completed.

As described previously in regard to TMS I/O Circuit526, the function of the Data & Clock Encoder614ofFIG. 18is to control the Output Register612to receive parallel data patterns from the Data Source522via bus624and output the data serially to the Data & Clock Encoder614. The Data & Clock Encoder614encodes the serial input data620with a clock from Clock Source528to produce a frame of serial Manchester encoded data to be output on TCK terminal314. This process of receiving a parallel data pattern from the Data Source522, converting the parallel data pattern into a frame of serial Manchester encoded data, and outputting the frame of serial Manchester encoded data onto TCK terminal314is repeated until all the parallel data patterns from Data Source522have been serially transmitted from TCK terminal314. As seen inFIG. 18, the Data Out Ready signal616, which controls the input of parallel data patterns from the Data Source to the Output Register is also input to Frame Counter516to control the frame count. The count value in the Frame Counter516controls the number of parallel data patterns that are output as encoded serial frames from TCK316. The Frame Counter516decrements once per each Data Out Ready signal. As seen inFIG. 17, when the frame count in Frame Counter516expires, the Frame Counter halts the TCK serial output operation by setting the count complete (CC) signal to And gate520low.

FIG. 19illustrates a timing example of the Data & Clock Decoder circuit604receiving Manchester encoded data on TCK terminal314. The timing example is the same as that described previously inFIG. 7, with the exception that the TCK signal314is used for communication instead of the TMS signal316. Also it is seen that the Input Enable goes high on the falling edge1902of TCK314. Referring back toFIG. 17, the output of D flip flop1702is set high on the falling edge of TCK314when the Tap is in the RTI state202, which in turn sets the Input Enable output of And gate508high if Enable TCK Input1712is high. Use of the falling edge of TCK to initiate the TCK input operation allows the operation to start after TCK has transitioned to a low logic state which allows the Start signals704(four logic one's in this example) on TCK to be more easily recognized by the Data & Clock Decoder circuit604.

As seen the Manchester Decoder circuit702in circuit604, when enabled by Input Enable, becomes operable to receive Start signals704, four logic ones in this example, from TCK316. After recognizing the Start signals, the Manchester Decoder receives frames 1-N of Manchester encoded serial data from TCK314. The Manchester Decoder extracts the Data and CK components from each Manchester encoded bit708in the frame and shifts the extracted Data into the Serial Input Parallel Output (SIPO) Register602. The Enable output from the Manchester Decoder enable the SIPO Register602to receive data. After each frame is decoded and shifted into SIPO Register602, the Manchester Decoder outputs the Data In Ready signal to Data Destination524. In response to the Data In Ready signal the Data Destination receives (stores and/or processes) the parallel output of Register602. This process continues until the Manchester Decoder receives Stop signals706, four logic zeros in this example, from TCK314, to cause the Manchester Decoder to stop receiving serial frames of encoded TCK data.

FIG. 20Aillustrates a more detail example of Manchester Decoder circuit702, which is the same as that described inFIG. 8Awith the exception that the TCK signal314is substituted for the TMS316signal. The Manchester Decoder702consists of a Manchester Decoder State Machine802and a Bit Counter806. The state machine802receives the TCK signal from TCK terminal314, a clock signal from Clock Source528, the Input Enable signal from And gate508, and a count complete (CC) signal from Bit Counter804. The state machine outputs a Data signal to SIPO Register602, a clock (CK) signal to SIPO Register602and Data Destination524, an Enable signal to SIPO Register602, the Data In Ready signal to Data Destination524, count control to Bit Counter804.

FIG. 20Billustrates the operation of state machine802, which is the same as described previously in regard toFIG. 8B. When the Input Enable signal is set high, the state machine begins sampling the TCK input for Start signals704. The frequency of the Clock Source is set sufficiently high to allow over-sampling of the TCK input signal. After Start signals are detected, the state machine begins sampling the TCK input to decode the Manchester encoded bit pairs708. Each time a bit pair is decoded, the appropriate Data value is clocked into SIPO Register602by the CK signal and the Bit Counter is clocked by counter control outputs. During the decode operation, the state machine monitors the CC input from the counter804. When a CC signal is detected, indicating that the number of bits received is equal to a full frame of bits, the state machine sets the Data In Ready signal high to enable the Data Destination to receive the full frame of bits from the parallel output from SIPO Register602. This process continues until the state machine receives the Stop signals706on the TCK signal, indicating the end of the transmission of Manchester encoded data frames. The state machine transitions to the Stop state and waits for the Input Enable signal to be set low by the Tap controller104exiting the Run Test/Idle state. A subsequent JTAG scan operation to either the DR108or the IR106register (i.e. the register from which it came) can set the Enable TCK input signal1712low. When Input Enable goes low, the state machine802transitions back to the Input Enable state.

FIG. 21illustrates a timing example of the Data & Clock Encoder circuit614outputting Manchester encoded data on TCK terminal314. The timing example is the same as that described previously inFIG. 9, with the exception that the TCK signal314is used for communication instead of the TMS signal316. Also it is seen that the Output Enable goes high on the falling edge2102of TCK314. Referring back toFIG. 17, the output of D flip flop1702is set high on the falling edge of TCK314when the Tap is in the RTI state202, which in turn sets the Output Enable output of And gate506high if Enable TCK Output1710is high. Use of the falling edge of TCK to initiate the TCK output operation allows the operation to start after TCK has transitioned to a low logic state and the controller1620has disabled (“Z”) its TCK output driver.

In the timing diagram, the Start704, Data708(of frames 1-N), and Stop706signals are again illustrated as they were inFIG. 9. As seen, the Manchester Encoder circuit902in circuit614, when enabled by Output Enable, becomes operable to transmit Start signals704, four logic ones in this example, onto TCK314. As mentioned above, the controller1620will have disabled its TCK output driver to allow the output buffer904of the Manchester Encoder circuit902to drive the TCK314terminal.

After transmitting the Start signals, the Manchester Encoder loads parallel data into the Parallel Input Serial Output (PISO) Register612from the Data Source522and starts shifting the PISO Register612. Each bit shifted from the PISO Register to the Manchester Encoder is appropriately encoded as a Manchester bit pair signal708and transmitted out of the IC or core via the TCK terminal314. The Manchester Encoder combines the data and clock components together such that a Manchester Decoder702in the receiving controller420or other IC/core can extract the components back into separate data and clock signals. The Enable output from the Manchester Encoder enables the PISO Register612to load and shift out data. The serial data shifted out from one parallel load of the PISO Register forms one serial bit frame. After each frame is shifted out of the PISO Register612, the Manchester Encoder outputs the Data Out Ready signal to PISO Register612and Data Source522. In response to the Data Out Ready signal the PISO Register612inputs parallel data from Data Source522to began the next serial output frame that is encoded and output on TCK314. This process continues until the Output Enable input to the Manchester Encoder goes low, at which time the Manchester Encoder outputs Stop signals706, four logic zeros in this example, onto TCK314and disables the output buffer904, ending the TCK output operation.

FIG. 22Aillustrates a more detail example of Manchester Encoder circuit902, which is the same as that described inFIG. 10Awith the exception that the TCK signal314is substituted for the TMS316signal. The Manchester Encoder902consists of a Manchester Encoder State Machine1002, Bit Counter1004, TCK buffer904, and Clock Divider (CD)906. The state machine1002receives the Data output signal from PISO Register612, a clock signal from Clock Source528via Clock Divider906, the Output Enable signal from And gate520, and a count complete (CC) signal from Bit Counter1004. The state machine outputs a clock (CK) signal to PISO Register612and Data Source522, an Enable signal to PISO Register612, a Data Out Ready signal to PISO Register612and Data Source522, count control to Bit Counter1004, and encoded data to TCK314via buffer904.

FIG. 22Billustrates the operation of state machine1002. When the Output Enable signal is set high, the state machine enables the output buffer904and outputs Start signals704onto TCK314. Also the first parallel data pattern from Data Source522is loaded into PISO Register612. After sending the Start Bits, the state machine begins encoding the serial output data shifted from PISO Register612into Manchester encoded outputs on TCK314. The frequency of the CK output from the state machine1002is sufficiently less than the frequency of the clock output from the Clock Divider906to allow each data bit shifted out of PISO Register612to be encoded into the appropriate Manchester bit pair signal708. Each time an encoded bit pair is output on TCK314, the Bit Counter counts in response to control inputs from state machine1002. During the encoding operation, the state machine monitors the CC input from the Bit Counter1004. When a CC signal is detected, indicating that the last bit of the current bit frame is being shifted out of PISO Register612, the Data Out Ready signal is set to cause the next parallel data pattern from Data Source522to be loaded into PISO Register612to allow starting the next frame of data bit outputs from the Register612. Each data bit of each new frame of data loaded and shifted out of PISO Register612is encoded into Manchester bit pairs and output on TCK314. This process continues until the state machine1002detects the Output Enable signal going low, as a result of the count in Frame Counter516expiring and setting its frame count complete CC signal low, which in turn sets the Output Enable signal low via And gate520. When Output Enable is detected low, the state machine1002outputs the Stop signals706to indicate to controller1620or other IC/core that the transmission of Manchester encoded data frames has come to an end. The state machine then disables output buffer904from driving the TCK terminal314and transitions to the Output Enable state of the diagram. When the output operation is ended, the controller1620enables its TCK output and sets the Enable TCK Output signal low by a JTAG scan operation to either the DR108or the IR106register from whence it came.

As with the TMS I/O communication, it is preferable that the Clock Sources528in transmitting and receiving devices (i.e. controller1620, IC, or core) be at the same frequency. This would ensure that, by the use of Clock Divider906of Manchester Encoder902, the data encoded and output from a transmitting device's Manchester Encoder902will be at a bit rate easily over-sampled and decoded by the non-divided Clock Source528driving the Manchester Decoder702in a receiving device. A test that TCK data transmitted from Encoder902at the divided Clock Source rate is properly received by Decoder702at the full Clock Source rate can be achieved by performing the test previously describe with the TMS I/O communication.

As seen in the TCK Manchester communication timing diagrams ofFIGS. 19 and 21, the format of a TCK output operation is the same as the format a TCK input operation. Both formats include a header of Start signals704followed by frames of Manchester data signals708followed by a trailer of Stop signals706. This allows simple and standardized data communication between a TCK transmitting device (i.e. controller1620, IC, or core) and a TCK receiving device (i.e. controller1620, IC, or core). As with the previously described TMS communication ofFIGS. 7 and 9, TCK communication may be expanded to include other more complex formats as the need arises, such as formats that include frames for addressing and commanding operations.

FIG. 23illustrates how a TCK I/O operation is initiated by the Tap controller transitioning into the Run Test/Idle state202. Prior to transitioning into the Run Test/Idle state, a scan operation will have been performed to set the Enable TCK Output1710or Enable TCK Input1712signal high, depending upon whether a TCK input or TCK output is desired. Also if it is a TCK output operation, the Frame Counter516is scanned to load the frame count value. Once this setup procedure is accomplished, the Tap controller104is transitioned into the Run Test/Idle state as shown inFIG. 23. Once in the Run Test/Idle state, and after the RTI output of D flip flop1702goes high, the selected TCK input or output operation can begin.

The RTI signal is set high on the falling edge of TCK at time2302which enables And Gates506and508to pass the Enable TCK Input or Output signals1710and1712to TCK communication circuit1714. If a TCK output operation is to be performed, the controller1620will disable its TCK output driver after the falling edge of TCK at time2302and before time2304to allow a transmitting device to drive the TCK signal314. The selected TCK input or TCK output operation begins at time2304and is executed during time2306as shown inFIG. 23while the Tap is in the Run Test/Idle state. When the TCK input or TCK output operation is competed at time2308, the TCK signal may once again be driven by the controller1720to conventionally operate Tap controller104using IEEE 1149.1 protocols. As can be seen, with the Tap controller in the Run Test/Idle state with TMS held low, TCK input and TCK output operations are completely transparent to the Tap controllers and all IEEE 1149.1 circuitry connected to Tap controllers.

FIG. 24is provided to illustrate that other Tap controller states, other than Run Test/Idle, may be used to perform TCK input and TCK output operations. For example, the Pause-DR state1204or the Pause-IR state1208may be used in addition to the Run Test/Idle state202for TCK input and output operation modes. To use these additional Tap controller states as states in which TCK input and output operations may be performed is simply a matter of providing And gates2402to detect when the Tap controller is in one of the states, as And gate504did for detecting the Run Test/Idle state, and providing an Or gate2404for indicating when any of the And gate2402outputs are high. The output of the Or gate2404would be substituted for the output of And gate504inFIG. 17as input to D flip flop1702. The output of D flip flop1702, renamed “TCK I/O State” inFIG. 24, would maintain its connection to And gate506and508as shown inFIG. 17. With this substitution made, the Tap controller104could be transitioned into any one of these states, and held there by asserting a low on TMS, to allow a TCK I/O operation to be started, executed, and stopped, as was shown and described in regard to the Run Test/Idle state ofFIG. 23. While it is possible to also use the Shift-DR state1202and Shift-IR state1206for TCK input and output operations, as was shown and described in the TMS input and output operations ofFIG. 12, one must be aware that data will be shifting through the lOs/cores of scan path1602from TDI to TDO during the TCK input or output operations, since the TCK signal will be active. This may or may not be a desired situation and is therefore left up to the user of the disclosure to determined whether TCK input and output operations are also allowed in the Shift-DR and Shift-IR Tap states. If allowed, then additional And gates2402would be assigned to detect these additional Tap states and the Or gate2404would be equipped with additional inputs for receiving the outputs from the additional And gates2402.

FIG. 25illustrates an example of the TCK I/O operation of the present disclosure being performed between an IC2502of a scan path1602and a controller1620as shown inFIG. 16. If the controller is performing a TCK output operation, the IC will be performing a TCK input operation to receive the data from the controller via the TCK connection. If the IC is performing a TCK output operation, the controller will be performing a TCK input operation to receive the data from the IC via the TCK connection.

FIG. 26illustrates an example of the TCK I/O operation of the present disclosure being performed between a first2602and second2604IC of a scan path1602. If IC2602is performing a TCK output operation, IC2604will be performing a TCK input operation to receive the data from IC2602via the TCK connection. If IC2604is performing a TCK output operation, IC2602will be performing a TCK input operation to receive the data from IC2604via the TCK connection. During these operations, the TCK output of controller1620ofFIG. 16will need to be disabled to allow the TCK terminal of the outputting IC to drive the TCK connection between the lOs.

FIG. 27illustrates an example of the TCK I/O operation of the present disclosure being performed between a first2702and second2704core circuit within an IC of scan path1602. If core2702is performing a TCK output operation, core2704will be performing a TCK input operation to receive the data from core2702via the TCK connection. If core2704is performing a TCK output operation, core2702will be performing a TCK input operation to receive the data from core2704via the TCK connection. During these operations, the TCK output of controller1620ofFIG. 16, or the output of an internal buffer in the IC being driven by the TCK output of controller1620will need to be disabled to allow the TCK terminal of the outputting core to drive the TCK connection between the cores.

In all of the examples inFIGS. 25-27, the TCK I/O data communication between the devices (IC and controller, IC and IC, core and core) is performed directly and without introducing any communication latency by having to pass the communicated data through any other devices. Further, devices not involved in the TCK I/O communication are not effected by the TCK I/O communication.

While the Manchester encoding and decoding circuits described herein to achieve the TMS and TCK I/O communication have been described as being state machines operating synchronous to a clock source528, the disclosure is not limited to a particular type of Manchester encoding and decoding circuit. Indeed, other types of Manchester encoding and decoding circuits may be readily substituted for the example circuits shown herein and used to achieve the Manchester based TMS and TCK I/O communication objective of the present disclosure.

While the TMS and TCK I/O communication circuit examples were shown as residing in ICs and/or cores, it should be clear that similar TMS and TCK I/O communication circuits or software that can emulate the TMS and TCK I/O communication circuit functionality also resides in the controllers that connect to the ICs and/or cores to enable the controllers to communicate with the ICs and/or cores during TMS and TCK I/O communication operations.

Although the present disclosure has been described in detail, it should be understood that various changes, substitutions and alterations may be made without departing from the spirit and scope of the disclosure as defined by the appended claims.