Patent Application
20070255990
The present disclosure generally relates to testing of electronic circuit components, and particularly relates to accessing and testing multiple electronic components in a system.
Common modern electronic systems comprise a plurality of electronic components, each component enabling a particular function or set of functions within a system. For example, conventional computer systems may comprise one or more electronic components such as microprocessors, Digital Signal Processors (DSPs), memory devices, graphics devices, input/output devices, physical access devices (PHYs), controllers and the like. Other systems may require additional or different components. For example, a wireless communication system may comprise analog-to-digital and digital-to-analog components as well as baseband and other signal processing components.
It is desirable that each electronic component contained in a modern electronic system be testable. Accordingly, each electronic component should be accessible, excitable and observable within a system. Isolating and testing components within a system presents unique and difficult challenges given the ever-evolving complexity, and increasing levels of integration of modern circuit design. Advancements in semiconductor processing technology further compound, these challenges, e.g., by allowing more transistors to be fabricated in smaller areas with increased performance and new functionality. Advancements in semiconductor processing technology have also enabled the integration of various semiconductor technologies on a single die or chip. For example, CMOS, bi-CMOS and/or bi-polar devices can be fabricated on the same die to produce Integrated Circuits (ICs) having mixed-signal capability.
The complexities associated with testing modern ICs are further increased when various electronic components are incorporated in a system. The ability to access and test a single component within a system is complex. One solution that has eased some of the complications associated with isolating and testing individual components included in a system is IEEE's boundary scan methodology (IEEE 1149.1). IEEE 1149.1 provides a methodology by which various electronic components integrated in a system can be interconnected via a serial boundary scan path. Information can be scanned into and out of components coupled to the boundary scan path. The IEEE 1149.1 standard reduces the number of signal I/Os needed for accessing, exciting and observing a particular component within a system.
In one example, the IEEE 1149.1 boundary scan methodology can be integrated into a wireless communication device for testing electronic components included in the wireless system such as a DSP. The DSP can be isolated from other system components and tested using the IEEE 1149.1 boundary scan methodology. The position of each component within the boundary scan path in addition to the length of each boundary scan instruction and data registers are needed to successfully access the DSP. As such, the exemplary DSP can be isolated and tested by shifting information through the other components until the information reaches the DSP. Results can be subsequently scanned out in a similar fashion. As a result, electronic components included in a system can be accessed and tested via a reduced-pin boundary scan test interface.
However, the serial scan path architecture associated with conventional boundary scan methodologies presents unique problems in low power applications, e.g., portable computing and wireless communication applications. In low power systems, power to one or more components forming part of a boundary scan path may be cycled off when not in use, thereby extending battery life of the system. However, when a component forming part of a boundary scan path is powered off, other components in the path cannot be reliably accessed because the serial scan path is disrupted or broken when a component in the path is not powered on. Conventional low-power systems that routinely cycle component power on and off can render the use of a serial boundary scan architecture for isolating and accessing a particular component sporadic at best.
Further, the serial scan path associated with conventional boundary scan architectures reduces test performance in that information must be loaded into and out of the boundary scan path serially through each component forming the scan path. Components in the scan path that are not being accessed may be bypassed, which conventionally involves selecting a one-bit bypass register in each non-active component so that serial information can be scanned through the boundary scan path via the one-bit bypass registers until it reaches the desired component. However, as the number of electronic components included in modern electronic systems increases, the efficiency associated with bypassing each component not under test can adversely impact performance. In addition, the number of bits required for instruction register scan operations corresponds to the total bit length of all instruction registers included in the system, thus further increasing test time as the number of components included in a system increases.
According to the methods and apparatus taught herein, a Test Access Port (TAP) switch provides a centralized serial test interface between an electronic system and a resource external to the electronic system. The electronic system in which the TAP switch is included comprises a plurality of electronic circuit components, each electronic circuit component having a TAP coupled to the TAP switch. The centralized architecture of the TAP switch enables the switch to receive serialized information from the external source, e.g., a test system, and to forward the information to a selected one of the TAPs included in the electronic system regardless of whether the non-selected TAPs are powered on or off. In one or more embodiments, the TAP switch comprises a first circuit configured to provide a clock signal to a selected one of the TAPs responsive to a selection code included in a serialized instruction. The TAP switch further comprises a second circuit comprising an instruction register (IR) configured to pass serialized instructions received by the TAP switch to the selected TAP and a third circuit configured to forward serialized data received from the selected TAP to an output of the TAP switch responsive to the selection code.
Thus, in at least one embodiment, the TAP switch controls access to the TAPs by providing a clock signal to a selected one of the TAPs responsive to the selection code, passes serialized instructions received by the TAP switch to the selected TAP and forwards serialized data received from the selected TAP to an output of the TAP switch responsive to the selection code. The TAP switch is further capable of selecting a different TAP by providing the clock signal to a newly selected one of the TAPs in response to a change in the selection code, thus enabling multiple TAPs to be selected during a single debug session.
Only minimal modifications to conventional boundary scan debugger programs are commonly used to make the TAP switch backward compatible with conventional programs. In one embodiment, a computer program product for controlling access to two or more TAPs in an electronic system comprises program code for causing the TAP switch to select one of the TAPs responsive to a selection code included in a serialized instruction and program code for including the selection code in subsequent instruction register-related instructions. The computer program product may further comprise program code for maintaining the TAP switch in an idle state for at least two test clock cycles after the selection code is scanned into the TAP switch.
Of course, the present disclosure is not limited to the above features. Those skilled in the art will recognize additional features upon reading the following detailed description, and upon viewing the accompanying drawings.
Each system IC 14-18 enables a particular function or set of functions associated with the system 10. For example, the ICs 14-18 may comprise one or more microprocessors, Digital Signal Processors (DSPs), memory devices, graphics devices, input/output devices, physical access devices (PHYs), controllers, analog-to-digital and digital-to-analog components, baseband and other signal processing components, and the like. The electronic system 10 is particularly adapted for low power applications such as mobile computing and wireless communication applications and can take form in one of several configurations. For example, the electronic system 10 may be formed by interconnecting the ICs 14-18 on a carrier such as a board or multi-chip module (MCM) or within a System-on-Chip (SoC) design, or some combination thereof. The ICs 14-18 may comprise separate chips to be mounted on a board, separate die to be mounted on an MCM, or separate cores within a SoC, or some combination thereof. Regardless of the particular functions supported by the ICs 14-18 and the application in which the electronic system 10 is utilized, a boundary scan path is used to facilitate communication with the ICs 14-18 after they have been interconnected within the system 10. Because the boundary scan interface between the TAP switch 12 and each of the system ICs 14-18 is a parallel one, a particular IC can be accessed, excited and observed regardless of the power-on status of the other ICs included in the system 10. That is, the TAP switch 12 can communicate with a selected one of the IC TAPs 20-24 regardless of the powered status of the other IC TAPs. Thus, disruptions in the use of a conventional ‘daisy-chain’ boundary scan configuration due to component power cycling are eliminated by using the TAP switch 12 as a centralized hub for accessing and communicating with selected components included in the system 10.
To facilitate selective communication with the IC TAPs 20-24, one embodiment of the TAP switch 12 comprises a selection circuit 38, a demultiplexer circuit 40 and a multiplexer circuit 42. The TAP switch 12 functions as a test interface for the electronic system 10 by receiving serial test information (DI), a mode select signal (MODE) and a test clock signal (CLK) from an external resource. Optionally, the TAP switch 12 may receive a test reset signal (RESET) that provides for an asynchronous reset of the switch 12. Further, the TAP switch 12 outputs serial test data (DO) received from a selected one of the IC TAPs 20-24 and an optional return clock signal (RCLK) used to synchronize one or more of the ICs 14-18 with a system clock during testing.
In response to an instruction received by the TAP switch 12 that indicates which IC TAP is to be selected, i.e., a select TAP instruction, the selection circuit 38 captures a selection code included in the select TAP instruction, e.g., a code appended or prepended to the instruction. The selection circuit 38 then stores the selection code and provides it to the demultiplexer and multiplexer circuits 40, 42 (SEL). The selection code causes the demultiplexer circuit 40 to provide a clock signal to a particular one of the IC TAPs 20-24, thus selecting that TAP. That is, the selection code uniquely identifies each testable IC 14-18 included in the system 10. In response to this unique code, the demultiplexer circuit 40 selects only one IC TAP to receive a test clock signal. For example, the demultiplexer circuit 40 provides a test clock signal (CLKA) to ICA 14 in response to a TAP select instruction having a selection code associated with ICA 14 included therein. The TAPs that do not receive an active test clock signal from the TAP switch 12 remain idle while the selected TAP is accessed (in this example, TAPs 22 and 24 of ICB 16 and ICC 18, respectively, are not clocked). The selection code also causes the multiplexer circuit 42 to forward an unaltered version of serialized data received from the selected TAP to the DO output of the TAP switch 12. Because each testable IC 14-18 is coupled to the TAP switch 12 in parallel, the TAP switch 12 allows an external test system to dynamically select and independently communicate with individual TAPs regardless of the power-on status of the other ICs included in the system 10.
The one-bit bypass DR 48 is selected in response to the state machine 44 detecting a bypass instruction. In response to a bypass instruction, serialized information received by the TAP switch 12 is diverted from the DI input to the DO output of the switch 12 via the multiplexer circuit 42. As such, the selected TAP does not receive any serialized information when the TAP switch 12 is in bypass mode. In one example, the selection code is set to all logic ones to indicate a bypass operation, e.g., ‘11’ in the present system illustration. When the ‘11’ selection code is provided to the multiplexer circuit 42, the circuit 42 couples the output of the one-bit bypass DR 48 to the DO output of the TAP switch 12, thus circumventing the selected TAP.
The two-bit IR 50 is selected in response to the state machine 44 detecting an instruction register instruction, e.g., IEEE 1149.1 compliant Select-IR, Capture-IR, Shift-IR, Exit-IR, Pause-IR, or Update-IR operation. In the present system illustration, the TAP switch IR 50 has a width of two bits. The two-bit IR 50 holds the selection code which is included in IR instructions. Generally, the bit width of the TAP switch IR 50 is a function of the number of testable ICs accessed by the TAP switch 12. For example, if the TAP switch IR 50 were three bits in width, up to seven IC TAPs could be uniquely identified and accessed by the TAP switch 12 while leaving one selection code state for indicating the bypass mode. The latch circuit 52 stores selection code values loaded into the two-bit ISR 50 and provides the selection codes (SEL) to the demultiplexer and multiplexer circuits 40, 42. In one embodiment, the latch circuit 52 comprises a register coupled to latch devices (not shown).
The state machine 44 causes the TAP switch 12 to transition from state-to-state in response to the current state of the switch 12, the mode select signal (MODE) and transitions in the test clock signal (CLK).
In response to the mode signal indicating an IR instruction, the state machine enters an IR state 206. For example, an IEEE 1149.1 Select-IR scan operation causes the state machine 44 to transition to the IR state 206. The state machine 44 causes the TAP switch 12 to remain in the IR state 206 so long as the mode signal indicates that IR instructions are being performed, e.g., IEEE 1149.1 Capture-IR, Shift-IR, Exit-IR, Pause-IR, or Update-IR operations. A subsequent select TAP instruction causes the state machine 44 to transition back to the select TAP state 202 while a reset causes a transition back to the reset state 200.
In response to the mode signal indicating a DR instruction, the state machine 44 transitions to a DR state 208. For example, an IEEE 1149.1 Select-DR scan operation causes the state machine 44 to transition to the DR state 208. The state machine 44 causes the TAP switch 12 to remain in the DR state 208 so long as the mode signal indicates that DR instructions are being performed, e.g., IEEE 1149.1 Capture-DR, Shift-DR, Exit-DR, Pause-DR, or Update-DR operations. A subsequent select TAP instruction causes the state machine 44 to return to the select TAP state 202 while a reset causes a transition back to the reset state 200. An idle instruction causes the state machine 44 to transition from either the IR or DR states 206, 208 to the idle state 204.
Regardless of the present state of the TAP switch 12, the state machine 44 causes the switch 12 to enter the select TAP state 202 when a select TAP instruction is recognized by the switch 12. As such, the TAP switch 12 is capable of selecting a different TAP in response to a change in the selection code, thus enabling the switch 12 to access multiple TAPs during a single debug session. As a result, debug performance is improved and complexity is reduced.
Only minimal modifications to preexisting debugger software programs are commonly used to make the TAP switch 12 backward compatible with preexisting programs. Conventional boundary scan debugger programs enable remote control of a system via one or more TAP interfaces. For example, conventional debugger programs enable downloading of programs to memory, starting and stopping execution of debug programs, setting of debug breakpoints and watchpoints, analyzing contents of registers and memory, and collecting real-time execution data.
A first modification to a conventional debugger program involves adding support for the select TAP instruction. The select TAP instruction is issued each time the TAP switch 12 transitions out of the reset state 200 or when a different IC TAP is selected for access during a debug session. To support the select TAP instruction, the debugger program is made aware of three variables: the bit length of the longest TAP IR included in the system, the bit length of the TAP switch IR 50, and the unique selection codes associated with each IC TAP 20-24 included in the system 10.
The debugger program processes the IR bit length information provided to the program to generate a select TAP instruction for initializing the TAP switch 12, thus causing the switch 12 to select one of the TAPs 20-24. The length of the longest TAP IR is used by the debugger program to ensure that all of the TAP IRs 20-24 included in the system 10 are loaded with a bypass code during a select TAP instruction sequence, thereby ensuring that no IC TAP performs an undesirable operation when the TAP switch 12 is selecting one of the TAPs 20-24. For illustrative purposes only, the TAP IR 26 associated with ICA 14 is four bits wide, the TAP IR 28 associated with ICB 16 is five bits wide and the TAP IR 30 associated with ICC 18 is four bits wide. As such, the longest TAP IR, that is the TAP IR 28 included in ICB 16, is always loaded with a bypass instruction during the select TAP instruction sequence.
The bit length of the TAP switch IR 50 is provided to the debugger program so that a selection code having a correct length is loaded into the TAP switch IR 50 during a select TAP operation. Finally, the unique selection code associated with each IC TAP 20-24 is provided to the debugger program so that the TAPs 20-24 can be uniquely identified by the TAP switch 12. As such, a select TAP instruction comprises the selection code included in a bypass instruction, e.g., <xxyyyyy> where xx=the selection code associated with the TAP to be selected and yyyyy=the bit sequence associated with a bypass instruction. In one example, xx=‘10’ and yyyyy=‘11111’ where ‘10’ indicates the TAP 24 associated with ICC 18 and ‘11111’ indicates the bypass instruction. Those skilled in the art will recognize that one or more leading logic one values will be dropped from those TAP IRs having a bit length shorter than the longest TAP IR included in the system, e.g., the TAP IRs 26, 30 associated with ICA 14 and ICC 18 in the present system 10. However, by ensuring that the bypass instruction has a bit width equal to the length of the longest TAP IR, all the TAP IRs 20-24 will be loaded with the bypass instruction. Thus, undesirable TAP operations are prevented in all of the IC TAPs 20-24 when the select TAP sequence is being executed by the TAP switch 12.
A second modification to a conventional debugger program involves maintaining the TAP switch 12 in the idle state 204 for a sufficient number of test clock cycles after the selection code is loaded into the TAP switch IR 50 during a select TAP instruction sequence. This provides the TAP switch 12 sufficient time to properly store the selection code in its latch circuit 52. For example, the TAP switch 12 is maintained in the IEEE 1149.1 compliant Run Test/Idle state for at least two clock cycles after the switch 12 recognizes a select TAP instruction. Maintaining the TAP switch 12 in the Run Test/Idle state also ensures that the newly selected TAP will be placed in the Run Test/Idle state in the event that it had previously entered a Test-Logic-Reset state as a result of power cycling.
A third modification to a conventional debugger program involves including the selection code in IR instructions issued subsequent to a select TAP instruction, thus accounting for the TAP switch IR 50 during IR operations. For example, the debugger is modified to append or prepend the selection code to IR instructions. Further, unlike the select TAP instruction which must account for the longest TAP IR included in the system 10, all subsequent IR instructions need only account for the length of the TAP IR associated with the presently selected TAP. As such, the architecture of the TAP switch 12 improves performance in that all subsequent IR instructions have a length equal to the bit length of the presently selected TAP IR plus the bit length of the TAP switch IR 50. Unlike conventional daisy-chain boundary scan configurations, the total length of all TAP IRs 26-30 included in the system 10 need not be accounted for during subsequent IR instructions.
With the above range of variations and applications in mind, it should be understood that the present disclosure is not limited by the foregoing description, nor is it limited by the accompanying drawings. Instead, the present disclosure is limited only by the following claims and their legal equivalents.
