Programmable Logic Devices (PLDs) are Integrated Circuits (ICs) that are user configurable and capable of implementing digital logic functions. There are several types of PLDS, including Field Programmable Gate Arrays (FPGAs) and Complex Programmable Logic Devices (CPLDs). CPLDs typically include several function blocks that are based on the well-known programmable logic array (PLA) architecture, and include a central interconnect matrix to transmit signals between the function blocks. Both the logic performed by the function blocks and the signal paths implemented by the interconnect matrix are controlled by configuration data stored in a configuration memory of the CPLD. FPGAs include configurable logic blocks (CLBs) arranged in rows and columns, and programmable interconnect lines that extend between the rows and columns of CLBs. Each CLB includes look-up tables and other configurable circuitry that is programmable to implement a portion of a larger logic function. Both the CLBs and interconnect lines are controlled by configuration data stored in a configuration memory of the FPGA.
PLDs are programmed (configured) using data generated by place-and-route software. The PLD programming process typically begins after the user enters his/her logic operation into a computer/workstation in which the place-and-route software is installed. The user then identifies a target PLD architecture and instructs the place-and-route software to generate configuration data which, when entered into the configuration data of the target PLD, programs the target PLD to implement the logic operation. The place-and-route software begins this process by accessing a stored description of the target PLD and the logic operation entered by the user. The place-and-route software then divides the logic operation into inter-related logic portions that can be implemented in the individual function blocks/CLBs of the target PLD, as identified in the PLD description. The place-and-route software then "places" (assigns) the logic portions to specific function blocks/CLBs associated with the target PLD. Routing data is then generated by identifying specific interconnect resources of the target PLD that can be linked to form the necessary signal paths between the inter-related logic portions assigned to the function blocks/CLBs. The placement and routing data is then combined to form configuration data that is converted into a bit map file that, when transmitted into the configuration memory of the target PLD, causes the target PLD to implement the logic function.
PLDs have become popular for implementing various functions in electronic systems that, in the recent past, were typically implemented by smaller (&lt;100,000 gates) application specific integrated circuits (ASICs). Such functions include glue logic, state machines, data bus logic, digital signal processors and protocol devices. Early PLDs often provided insufficient capacity to implement these functions, so the significant investment of time and money to design, layout and fabricate an ASIC for these functions was justified. However, recent advances in semiconductor and PLD technologies have produced PLDs with the necessary speed and capacity to implement these functions in most applications. Because PLDs are relatively inexpensive and can be programmed in as little time as a few seconds, the expense associated with the design, layout and fabrication of ASICs became harder to justify. Further, the reprogrammability of many PLDs makes them even more attractive than ASICs because it is possible to update (reconfigure) PLDs, whereas ASICs must be replaced. As such, there is a trend toward the use of PLDs in place of ASICS in electronic systems.
Most electronic systems include multiple ICs (such as PLDS, ASICs, memory devices and processors) mounted on a printed circuit board (PCB). Each PCB includes a pattern of printed metal lines (e.g., copper tracks) formed on a board of insulating material. The ICs are typically soldered to the copper tracks at specific locations on the PCB so that the copper tracks provide signal paths between the ICs that are necessary to form the desired electronic system.
After ICs are soldered to a PCB to form an electronic system, the system is typically tested to verify that all of the ICs are properly mounted (e.g., that the copper tracks provide all required IC-to-IC connections). Early electronic systems were tested using mechanical probes (e.g., bed-of-nails fixtures) that contacted the copper tracks of the PCBs and generated test signals for verifying the interconnections between the ICs. However, steady advances in semiconductor technologies have provided highly integrated ICs mounted in packages that have hundreds of contact points (e.g., pins) arranged at very small pitches. Further, trends toward smaller products have forced manufacturers to pack ICs more densely on PCBs. As a result, conventional PCB testing methods using mechanical probes (e.g., bed-of-nails fixtures) are greatly impeded for several reasons. First, to support these highly integrated ICs, modern PCBs must be formed with copper tracks having ever-narrower widths, thereby making conventional testing difficult because test nails having very small physical dimensions are required. Second, the increase in the number of device contact points requires an increase in the number of copper tracks per PCB, thereby requiring test equipment that is increasingly more expensive to purchase and operate. Third, the dense packing of ICs on each PCB leaves little room for probe contact. Moreover, recent PCB technologies in which surface mounted IC devices are mounted on both sides of each PCB make mechanical probing practically impossible because of the required simultaneous probe contact on both sides of a PCB.
IEEE Standard 1149.1 (Boundary-Scan) was developed to overcome the limitations of conventional mechanical PCB probe testing. IEEE Standard 1149.1 defines a four pin serial interface that drives a 16-state controller (state machine) formed in each compliant IC device. The four pins control transitions of the state machine and facilitate loading of instructions and data into the compliant IC device to accomplish pre-defined tasks. Originally, IEEE Standard 1149.1 was developed to perform Boundary-Scan Test procedures wherein the interconnections and IC device placement on PCBs are tested through the connection pins of the PCBs (i.e., without the need for a mechanical probe). Since its establishment, some implementations of Boundary-Scan have been extended to include additional test procedures such as device functional tests, self-tests and diagnostics. More recently, Boundary-Scan has been modified to provide In-System Programming, whereby configuration data is transmitted into a target PLD after the PLD is mounted onto a PCB.
FIG. 1 shows a simplified electronic system provided for the purpose of explaining the basic concepts of Boundary-Scan Test procedures. The simplified electronic system is formed on a PCB 100 and includes a first IC 110 and a second IC 120.
PCB 100 includes copper traces formed on a board of insulating material that provide signal paths between a PCB connector 101 and ICs 110 and 120, and between ICs 110 and 120. In addition to the copper traces that transmit normal operation signals (not shown), PCB 100 includes four traces for transmitting Boundary-Scan Test signals. These copper traces include a first trace 102 for transmitting test data-in (TDI) signals, a second trace 103 for transmitting test data-out (TDO) signals, a third trace 104 for transmitting test clock (TCK) signals, and a fourth trace 105 for transmitting test mode select (TMS) signals. Boundary-Scan data (TDI/TDO) signals are typically transmitted serially through each compliant device of a system. That is, TDI signals are transmitted on first trace 102 to first IC 110, TDO signals are transmitted from IC 110 and received as TDI signals by second IC 120 along a linking trace 106, and TDO signals are transmitted from IC 120 to PCB connector 101 on second trace 103. In contrast to the data signals, each compliant device receives the TCK and TMS signals in a parallel manner.
Each IC of an electronic system typically includes input and output terminals and core logic circuitry located between the input and output terminals. For example, first IC 110 includes input terminals 112 that transmit input signals via lines 114 through respective buffers to core logic 115, which in turn transmits output signals on lines 116 to output terminals 118 via respective buffers. Similarly, second IC 120 includes input terminals 122 that transmit input signals via lines 124 to core logic 125, which in turn transmits output signals on lines 126 to output terminals 128. Core logic 115 and 125 include, for example, the logic circuitry associated with an ASIC, or the programmable interconnect and logic circuitry associated with a PLD.
In addition to core logic and input/output circuitry, each IC device that complies with IEEE Standard 1149.1 includes dedicated pins and hardware elements (referred to below as the Boundary-Scan architecture) for implementing Boundary-Scan Test procedures.
The pins of the Boundary-Scan Test architecture are typically identical to other "normal" pins of an IC. Referring to FIG. 1, first IC 110 includes four pins 142(1) through 142(4) that are respectively connected to trace 102 (TDI), trace 105 (TMS), trace 104 (TCK) and trace 106 (TDO). Similarly, second IC 120 includes four pins 142(5) through 142(8) that are respectively connected to trace 106 (TDI), trace 104 (TCK), trace 105 (TMS) and trace 103 (TDO).
The data and test control circuitry of the Boundary-Scan architecture provided on each compliant device utilize the signals received on the four dedicated pins. Briefly described, the data circuitry of the Boundary-Scan architecture includes a series of data registers, each register associated with one of the input and output pins of the device, and the test control circuitry controls the operation of these registers. For example, the signal received at the TDI pin 142(1) is serially transmitted on a line 144 through a series of data registers 146 to TDO pin 142(4). Each data register 146 is connected to an input pin 112 or an output pin 118 of first IC 110. A similar Boundary-Scan architecture is provided on second IC 120. Test control circuitry 148(1) (which is described in additional detail below) is controlled by control signals transmitted on the TDI/TDO line, the TCK and TMS signals to direct data signal shifting through data registers 146 to facilitate Boundary-Scan Testing of first IC 110. Similar test control circuitry 148(2) is provided on second IC 120.
An example illustrating the operation of the Boundary-Scan architecture will now be described. To verify the connection between first IC 110 and second IC 120 on copper trace 108, test control circuitry 148(1) receives instructions to shift a first data value into a first data register 142(1) on first IC 110. At the same time, test control circuitry 148(2) on second IC 120 is instructed to shift a second data value into a second data register 146(2). Test control circuits 148(1) and 148(2) are then controlled to transmit the data value from first data register 146(1) and receive the data value in second data register 146(2) on trace 108. The data value stored in second data register 146(2) is then shifted out from second IC 120. If the shifted-out data value equals the first data value, then the connection between first IC 110 and second IC 120 on trace 108 is verified.
The simple example provided above illustrates how the Boundary-Scan architecture is utilized to perform a basic Boundary-Scan Test. As described in additional detail below, the Boundary-Scan architecture is particularly useful for performing diagnostic procedures and In-System Programming in IEEE Standard 1149.1 compliant PLDs.
In-System Programming (hereafter ISP) is made possible by recent advances in PLD technology that allow both programming and operation at system voltages (i.e., 3.3V or 5V). Before PLDs with system-level programming voltages were available, programming voltages of 12V or more were required, thereby limiting PLD programming to situations in which this high programming voltage was available. This often-required users to program their PLDs before mounting them onto system PCBs, thereby increasing the risk of handling fallout due to leads that were bent or broken during transportation. ISP reduces PLD handling fallout because it reduces the amount of handling required during programming and system installation.
ISP is also a powerful tool because it facilitates complete life cycle system development, test, debug and upgrade of systems incorporating IEEE Standard 1149.1 compliant PLDs that support ISP (hereafter "ISP compliant PLDs". That is, after assembly onto a system PCB, the software used to program ISP compliant PLDs can be developed and debugged during the system prototype development phase, programmed into large numbers of PLDs during manufacturing, and debugged (even remotely) in the field as part of maintenance operations. Further, because of ISP, a system can be upgraded virtually anywhere the system is located by reconfiguring (reprogramming) the systems ISP compliant PLDs.
A current problem with systems incorporating ISP compliant PLDs is that programming commands must be written in several software languages for each of the programming platforms utilized during the prototype, production and maintenance/upgrade phases of the system's product lifetime. For example, product development is typically performed by programming PLDs using special development software run on a PC or workstation. After development, mass production typically involves programming using large, high-speed sophisticated systems such as HP3070 automatic test equipment available from Hewlett Packard. Finally, when testing or reprogramming is done in the field, ISP is often performed by relatively simple platforms, such as hand-held diagnostic equipment using 8051 processors. Typically, three or more sets of programming commands are required for each of these platforms: a first set for the PC/workstation development platform, a second set for the mass production platform, and a third set for in-the-field test/reprogramming platform. As is well known in the art, the translation of such programming commands typically results in errors that can cause the system to malfunction.
Similar problems arise with respect to the translation of Boundary-Scan Test commands generated for ASICs and other ICs. That is, a Boundary-Scan Test procedure written for a first hardware platform (e.g., a PC or workstation) often must be translated before it can be utilized in a second hardware platform (e.g., field test equipment).
What is needed is method for generating ISP and other Boundary-Scan Test instructions for ISP compliant PLDs and ICs that can be implemented on any platform, thereby avoiding costly translation of the Boundary-Scan and ISP instructions into several languages and the potential problems associated with mistranslation.