Integrated data download

A bitstream having a plurality of data sets is provided to an integrated circuit device such as an FPGA having test circuitry capable of routing data to the device's internal resources, with each data set including configuration information and a trigger signal. Successive data sets of the bitstream are sequentially processed by the test circuitry in response to the trigger signals to sequentially initialize the device's resources to various states. For some embodiments, each data set includes configuration data to configure one or more configurable elements of the device to implement a desired design and includes soft data for use by a processor embedded within the device. For one embodiment, control logic is provided to selectively wait for a predetermined time period before processing a next data set.

FIELD OF INVENTION

The present invention relates generally to integrated circuits, and more specifically to configuring programmable logic devices.

DESCRIPTION OF RELATED ART

A programmable logic device (PLD) is a well-known general-purpose device that can be programmed by a user to implement a variety of selected functions. PLDs are becoming increasingly popular with circuit designers because they are less expensive, more flexible, and require less time to implement than custom-designed integrated circuits such as Application Specific Integrated Circuits (ASICs).

There are many types of PLDs such as Field Programmable Gate Arrays (FPGAs) and complex PLDs (CPLDs). For example, an FPGA typically includes an array of configurable logic blocks (CLBs) and block RAM surrounded by a plurality of input/output blocks (IOBs). The CLBs are individually programmable and can be configured to perform a variety of logic functions. The IOBs are selectively connected to various I/O pins of the FPGA, and can be configured as either input buffers or output buffers. The block RAM can store data during operation of the FPGA and/or can be configured to implement various functions such as FIFO memories and state machines. The CLBs, IOBs, and block RAM are selectively connected to each other to implement more complex logic functions by a programmable interconnect structure. Further, some FPGAs also include an embedded microprocessor to provide additional functionality. The embedded processor typically includes well-known components such as CPU execution units, fetch and decode units, instruction units, cache memory, architectural registers, bus systems, test and debug circuitry, and the like. Typically, the embedded processor can retrieve firmware code, instructions, and other software, as well as data, from the block RAM. Further, the embedded processor in some FPGAs has access to external memory connected to the FPGA. For example, the Virtex-II Pro™ family of FPGAs from Xilinx, Inc. includes one or more PowerPC processor cores available from IBM Corporation that can communicate information with either block RAM or with an external memory.

To configure an FPGA having an embedded processor, a configuration file including configuration data and soft data is loaded into the FPGA using well-known configuration techniques. The configuration data typically includes data to be loaded into the configuration memory cells that control the states of various configurable elements (e.g., switches, multiplexers, and the like) within the CLBs, IOBs, and the interconnect structure to implement one or more desired functions, and the soft data typically includes firmware code, software programs, and other instructions executable by the embedded processor. The soft data may be loaded into block RAM, into memory elements (e.g., cache memory) within the embedded processor, and/or into external memory accessible by the embedded processor. The configuration file is typically stored in an external non-volatile memory such as a Programmable Read Only Memory (PROM), an Electrically Erasable PROM (EEPROM), or a Flash memory.

FPGAs are typically configured from external memory using dedicated configuration I/O pins and well-known configuration circuitry. However, many FPGAs may also be configured from an external source using test circuitry embedded within the FPGA. For example, the Virtex-II Pro™ FPGAs support configuration using boundary-scan test circuitry such as that developed by the Joint Test Action Group (JTAG) and embodied by IEEE Standard 1149.1. The JTAG test circuitry includes a four-pin serial interface, a 16-state test access port (TAP) controller, and a boundary-scan architecture. The boundary-scan architecture, which includes a chain of registers placed around the periphery of the FPGA, is connected to the dedicated JTAG I/O pins via the TAP controller, which in turn controls operation of the boundary-scan architecture using well-known JTAG signals provided on the dedicated JTAG I/O pins. As known in the art, the JTAG test circuitry can be used to configure the FPGA and to access and/or control the internal resources of the FPGA's embedded processor during configuration of the FPGA. In addition, the JTAG test circuitry can be used to implement various test procedures such as device functional tests, self-tests, diagnostics, and the like, as is generally known in the art.

It is sometimes desirable to sequentially configure an FPGA with different loads of configuration data and soft data. For example, it may be desirable to initially configure the FPGA with first configuration data (e.g., to implement testing operations) and then configure the FPGA with second configuration data (e.g., to implement a user-specified design). Prior techniques typically require separate configuration operations to implement multiple data loads to the FPGA, which can be a time consuming and relatively inefficient process.

Thus, there is a need for providing multiple data loads to an FPGA in a single configuration operation.

SUMMARY

A method and apparatus are disclosed that allow multiple data loads integrated into a single bitstream to be provided to an IC device such as an FPGA in a single operation. In accordance with the present invention, an integrated bitstream having a plurality of data sets is provided to the device, with each data set including configuration information and a trigger signal. Successive data sets of the bitstream are sequentially processed by test circuitry within the device in response to the trigger signals to sequentially initialize the device's resources to different states. For example, each data set may include configuration data that configures one or more configurable elements to implement a desired design, and may also include soft data such as firmware code for use by a processor embedded within the device. For embodiments having an embedded processor, each data set may also include a stop instruction and a commence instruction. The test circuitry may instruct the processor to stop operation in response to the stop instruction, and may instruct the processor to commence operation in response to the commence instruction.

For some embodiments, the test circuitry is JTAG-compliant and includes a boundary-scan architecture and a test access port controller. For such embodiments, the integrated bitstream is constructed as a series of JTAG command sets and provided to the device via dedicated JTAG pins.

For some embodiments, control logic is provided that instructs the test circuitry to wait for a predetermined time period before processing a next data set. For one embodiment, one or more data sets may include a wait signal used by the control logic to instruct the test circuitry to wait for the predetermined time period. For other embodiments, the bitstream may include routing instructions that instruct the control logic how to route data to the device's resources.

DETAILED DESCRIPTION

Embodiments of the present invention are described below with respect to an exemplary FPGA architecture that is generally representative of the Virtex-II Pro™ FPGAs from Xilinx, Inc. for simplicity only. It is to be understood that embodiments of the present invention are equally applicable to other FPGA architectures and to other integrated circuits (ICs), including programmable logic devices such as complex PLDs. One example of another FPGA architecture is described in co-pending U.S. patent application Ser. No. 10/683,944, entitled “Columnar Architecture” by Young, filed on Oct. 10, 2003, which is incorporated herein in its entirety. In the following description, for purposes of explanation, specific nomenclature is set forth to provide a thorough understanding of the present invention. For example, as used herein, configuration data generally refers to data that controls the configuration state of various configurable elements such as CLBs, IOBs, and programmable routing structures, and soft data generally refers to data such as firmware code, software, and other executable instructions, as well as related data, that can be loaded into memory resources available to the device's processor and thereafter used (e.g., executed) by the processor. In other instances, well-known circuits and devices are shown in block diagram form to avoid obscuring the present invention. Further, the logic levels assigned to various signals in the description below are arbitrary and, thus, can be modified (e.g., reversed polarity) as desired. Accordingly, the present invention is not to be construed as limited to specific examples described herein but rather includes within its scope all embodiments defined by the appended claims.

FIG. 1illustrates the general layout of an FPGA100that is generally representative and consistent with the Virtex-II Pro™ devices from Xilinx, Inc. FPGA100is shown to include a plurality of IOBs110, CLBs120, block RAMs (BRAMS)130, corner blocks140, processor (uP) cores150, and JTAG test circuitry160. IOBs110are well-known, and may be located around the perimeter of FPGA100. CLBs120are well-known, and may be arranged in columns in FPGA100. BRAMs130are well-known, and may be arranged in columns between adjacent CLB columns. Corner blocks140are well-known, and may contain configuration circuitry and/or may be used to provide additional routing resources. Processor cores150, which are well-known and are depicted inFIG. 1within corresponding BRAM columns, have direct access to adjoining BRAMs130and CLBs150. A well-known general interconnect circuitry (not shown for simplicity) is provided to programmably connect the IOBs110, CLBs120, block RAMs130, corner blocks140, and processor cores150. For some embodiments, the general interconnect circuitry also facilitates communication between processor cores150and external memory (not shown for simplicity) that stores information (e.g., data, instructions, and the like) for use by processor cores150. JTAG test circuitry160is well-known and, as explained in more detail below, may be used to configure FPGA100and to implement various testing operations for FPGA100.

The IOBs110, CLBs120, block RAM130, corner blocks140, and interconnect structure each contain one or more configurable elements (not shown inFIG. 1for simplicity) that configure FPGA100to implement a desired function in response to configuration data stored in associated configuration memory cells (not shown inFIG. 1for simplicity). Other well-known components of FPGA100are not shown inFIG. 1for simplicity.

Further, although a particular FPGA layout is illustrated inFIG. 1, it is to be understood that many other FPGA layouts are possible, and are considered to fall within the scope of the present invention. For example, other embodiments can have other numbers of IOBs110, CLBs120, block RAMs130, and processor cores150, and can have other types of blocks. A more detailed description of the general operation of FPGA100is provided in “The Programmable Logic Databook 1998” pp. 4–1 to 4–40, which is available from Xilinx, Inc. of San Jose, Calif., and incorporated by reference herein.

FIG. 2is a functional block diagram generally representative of FPGA100ofFIG. 1. FPGA200is shown to include one or more data configuration pins202(only one data pin202is shown inFIG. 2for simplicity), dedicated JTAG pins204, an embedded processor210, a configuration circuit220, block RAM230, configuration memory cells240, configurable elements250, and JTAG-compliant test circuitry160. Other well-known components of FPGA200are not shown inFIG. 2for simplicity. Configuration circuit220includes a data input to receive input data (DIN) such as configuration data and/or soft data from an external configuration memory (not shown for simplicity) via configuration pin202, and includes a data output connected to block RAM230and to configuration memory cells240. Configuration circuit220is well-known and, as known in the art, may be used to load configuration data received from configuration pin(s)202into configuration memory cells240and into block RAM230, and may be used to load soft data received from configuration pin(s)202into block RAM230. Block RAM230, which is generally representative of block RAMs130ofFIG. 1, stores data that can be accessed by configurable elements250and/or by processor210. Configuration memory cells240, which are well-known, typically store configuration data that controls the configuration states of configurable elements250. Configurable elements250are generally representative of various programmable components of FPGA100such as those associated with IOBs110, CLBs120, corner blocks140, and the general interconnect and routing structures of FPGA100ofFIG. 1.

Processor210may be any well-known microprocessor that includes JTAG-compliant test circuitry. For simplicity, only one processor210is shown inFIG. 2. For the Virtex-II Pro™ FPGAs, processor210is a well-known PowerPC processor core available from IBM Corporation. Processor210is shown inFIG. 2as including an FPGA interface unit211, a cache unit212, CPU execution units213, a memory controller unit214, and test unit215. Interface unit211is well-known, and facilitates communication between processor210and FPGA components such as block RAM230and configurable elements250. Cache unit212is well-known, and includes a cache memory that can store data and instructions frequently requested by execution units213. For some embodiments, cache unit212includes an instruction cache and a data cache. CPU execution units213are well-known, and typically include a plurality of general purpose registers, an architectural register, an arithmetic logic unit (ALU), a media access controller (MAC), fetch and decode logic, and other well-known CPU components. Memory controller unit214is well-known, and facilitates communication between processor210and an external memory device270, which may be any suitable memory device (e.g., DRAM, SRAM, EEPROM, flash memory, a hard-drive, and the like) that stores data and/or instructions to be executed by processor210. Test unit215, which is well-known and complies with the IEEE 1149.1 standard, provides basic JTAG chip testing and debug functionality and allows external control of processor210and its associated memory device270using well-known JTAG commands. More specifically, test unit215provides external access to CPU resources such as the general purpose and architectural registers, cache memory, and the CPU bus system. For example, test unit215may have read-write access to all registers, and may start the CPU core, step an instruction, freeze the timers, and set hardware or software breakpoints. Other well-known components of processor210such as the processor's switch fabric, clock signals, bus systems, and the like are not shown inFIG. 2for simplicity.

Further information regarding the general layout and operation of FPGA200can be found in the “Virtex-II Pro Platform FPGA Handbook 2002,” pages 27–68, which is available from Xilinx, Inc. and incorporated herein by reference.

Test circuitry160is a well-known test circuit that complies with IEEE standard 1149.1, and is shown to include a boundary-scan architecture161and a TAP controller162. Boundary-scan architecture161and TAP controller162are conventional and operate according to well-known JTAG protocols. TAP controller162includes three input connections for receiving the test clock input (TCK) signal, the test mode select (TMS) signal, and the test data input (TDI) signal from corresponding dedicated JTAG I/O pins204. The TMS signal is used to control the state of TAP controller162, as discussed below. The TDI signal is used for serial transmission of data or instruction bits, depending upon the state of TAP controller162. TAP controller162also includes an output connected to a corresponding JTAG pin204through which the test data out (TDO) signals are transmitted. Depending upon the state of TAP controller162, the TDO signal may be used to serially shift data out of JTAG test circuitry160. TAP controller162also includes three outputs to provide TDI, TCK, and TMS signals to corresponding inputs of processor210's JTAG test unit215, and includes an input to receive TDO from a corresponding output of the processor's JTAG test unit215.

FIG. 3is a state diagram for explaining the operation of TAP controller162. The basic function of TAP controller162is to generate clock and control signals required for the correct sequence of operations of the boundary-scan architecture161and processor210's test unit215. Specifically, TAP controller162generates control signals that facilitate loading of instructions and data into the boundary-scan architecture161and processor test unit215, and performing test actions such as capture, shift, and update test data. As known in the art, TAP controller162can be used to configure configurable elements250via the boundary-scan architecture161, and can also be used to access and/or control the internal resources of processor210and external memory270via the processor's test unit215.

In operation, TAP controller162is initialized to the Test-Logic-Reset state. From the Test-Logic-Reset state, TAP controller162enters the Run-Test/Idle state when TMS is held low (e.g., TMS=0) for at least one TCK pulse. TAP controller162may be placed in this state, for example, while program, erase, blank, and verify operations are performed on block RAM230, configuration memory cells240, and/or configurable elements250via the boundary-scan architecture161and while such operations are performed within processor210via test unit215. During test procedures, TAP controller162either enters a data register (DR) branch of the state machine or an instruction register (IR) branch of the state machine.

When TAP controller162enters the DR branch of the state diagram, either a selected data register in the boundary-scan architecture161or in processor210is connected between TDI and TDO to load data therein. Specifically, the Capture-DR state is used to load data into the data register. The Shift-DR state is used to shift previously captured data toward the TDO connector in response to TCK pulses. The Exit1-DR state, Pause-DR state, and Exit2-DR state are used to switch between selected states and to temporarily halt a shifting process. TAP controller162remains in the Pause-DR state until TMS is held high (e.g., TMS=1), at which time it enters the Exit2-DR state. From the Exit2-DR state, TAP controller162either returns to the Shift-DR state or enters the Update-DR state. Once TAP controller162is in the Update-DR state, data shifting to/between the selected register is completed, and the data stored in the selected register(s) can be passed to the JTAG outputs. From the Update-DR state, TAP controller162either returns to the Run-Test/Idle state or to the Select-DR state.

The IR branch of the state machine is used to load instructions into the boundary-scan architecture161and/or processor210for subsequent test data operations. The states of the IR branch are similar to the states of the DR branch, and are therefore not discussed in further detail.

As known in the art, FPGA200can be configured using data supplied to the FPGA via configuration pin(s)202or via JTAG pins204. For example, to configure FPGA200and its processor210from an external storage device via configuration pin(s)202, the configuration data and any soft data for use by the processor210are first clocked into configuration circuit220through configuration pin202using any suitable configuration mode. For example, Virtex-II Pro™ devices from Xilinx, Inc. support several configuration modes including Master-Serial, Slave-Serial, and SelectMAP configuration modes. Configuration circuit220loads the configuration data into configuration memory cells240, and then loads the soft data into one or more selected portions of block RAM230. The configuration data configures the configurable elements250to implement a desired circuit design, and also maps the selected portion of block RAM230to processor210. After configurable elements250are configured, processor210can retrieve the soft data such as its firmware code from the selected portion of block RAM230and initialize itself in a well-known manner. Configuring FPGA200using configuration circuit220is well-known, and therefore is not described in further detail herein.

To configure FPGA200and its processor210via JTAG pins204, the configuration data and the soft data are clocked as a serial bitstream (TDI) into test circuitry160under the control of the TMS and TCK signals. TAP controller162uses the boundary-scan architecture161to load the configuration data into configuration memory cells240, and to load the soft data into block RAM230, external memory device270, and/or memory elements within processor210. Once loaded into one or more memory elements accessible by processor210, the soft data may be retrieved by processor210and used in a well-known manner to initialize processor210to a desired operational state. As known in the art, configuring FPGA200via JTAG pins204and test circuitry160may be advantageous for some applications because unlike configuration circuit220, test circuitry160has access to memory elements within processor210and to external memory device270before processor210is operational. The configuration of FPGA200using JTAG commands via test circuitry160is well-known, and therefore is not described in further detail herein.

As mentioned above, it is sometimes desirable to provide multiple data loads to an FPGA, for example, in a predetermined sequence. However, prior configuration techniques do not allow for a sequence of different data loads to be provided to an FPGA in a single configuration operation, but rather require multiple configuration operations. For example, to achieve acceptable fault coverage for an FPGA, the FPGA is typically tested in a variety of different test patterns because any given configuration pattern for the FPGA uses only a portion of the FPGA's resources. More specifically, during a typical fault testing operation of an FPGA, the FPGA is typically configured with a first test pattern during a first configuration operation, and then a first test operation is implemented in which a series of test vectors are applied to the FPGA to generate a first set of output vectors to be compared with expected results. The FPGA is then configured with a second test pattern during a second configuration operation, and then second test operation is implemented in which a series of test vectors are applied to the FPGA to generate a second set of output vectors to be compared with expected results. This process may be repeated until a sufficient number of FPGA test patterns have been applied to detect faults. Thereafter, the FPGA may be configured to implement a user-specified operational design in yet another configuration operation. Accordingly, to implement this exemplary testing operation using conventional configuration techniques, a plurality of different configuration operations are required, each temporally separated by the application and subsequent analysis of a number of test vectors. The ability to combine these different configuration operations into a single configuration operation would not only simplify such operations but may also reduce configuration times.

FIG. 4is a functional block diagram of an FPGA architecture400in accordance with the present invention that allows multiple data loads integrated into a single bitstream to be provided to the FPGA in a single configuration operation. In addition, embodiments of the present invention may also provide pauses between successive data loads, for example, to allow completion of one or more internal operations (e.g., such as initialization of processor210) before processing subsequent data loads. As explained below, by providing an automated mechanism that allows multiple sets of data loads to be sequentially provided to an FPGA, embodiments of the present invention may be used to facilitate a variety of FPGA operations more efficiently that previously required a series of independent data loads and associated configuration operations.

The architecture of FPGA400, which is consistent with the Virtex-II Pro™ FPGA devices from Xilinx, Inc., is similar to and may include all the components of the FPGA architecture illustrated inFIG. 2. Thus, because the architecture and operation of processor210, configuration circuit220, block RAM230, configuration memory cells240, configurable elements250, and test circuitry160of FPGA400are well-known, a detailed description thereof is not repeated here. Further, although for some embodiments processor210is a PowerPC processor from IBM Corporation, other embodiments of FPGA400may use other processors that include JTAG-compliant test and debug circuitry. In other embodiments, other processors may have a non-JTAG interface for testing. In addition, although FPGA400is shown to include one processor210, for other embodiments, FPGA400may include multiple processors210. Further, for simplicity, connections between the boundary-scan architecture161and block RAM230, configuration memory240, and configurable elements250are not shown inFIG. 4. However, as known in the art, test circuitry160may be used to load configuration data received in a JTAG-compliant format via JTAG port204into block RAM230and configuration memory cells240via the boundary-scan architecture161under the control of TAP controller162. Further, test circuitry160may be used to access and/or control resources within or otherwise available to processor210using the boundary-scan architecture161and TAP controller162in a well-known manner.

FPGA400includes control logic410that monitors delivery of an integrated bitstream constructed in accordance with the present invention to test circuitry160via JTAG pins204to implement sequential data loads and/or instruction operations within FPGA400. Control logic410is shown to include inputs coupled to the TDI, TMS, and TCK inputs of FPGA400, and includes a first output coupled to boundary-scan architecture161and a second output coupled to configuration circuit220. For some embodiments, control logic410may be implemented as a state machine using existing FPGA resources such as block RAM230. For such embodiments, the resources that implement the state machine of control logic410may be re-configured as part of a user-specified design after the integrated bitstream is loaded into FPGA400, thereby conserving FPGA resources. For other embodiments, the state machine of control logic410may be implemented using dedicated circuitry that is not re-configured as part of the user-specified design. For still other embodiments, control logic410may be implemented using software, for example, that may be executed by processor210.

As described below, control logic410monitors an integrated bitstream provided to FPGA400via JTAG pins204for routing instructions, and in response thereto facilitates routing of the configuration data and soft data from the bitstream to various components within and/or associated with FPGA400. Further, control logic410may also monitor the integrated bitstream for a wait signal, and in response thereto pause processing of the next data load for a predetermined time period.

FIG. 5shows an exemplary integrated bitstream500in accordance with one embodiment of the present invention. Bitstream500includes a plurality of data sets510(1)–510(n), each including a header field511, a configuration data field512, a soft data field513, and an end field514. For other embodiments, one or more data sets510may not include a configuration data field512and/or a soft data field513, depending upon the particular function embodied by the corresponding data set510. Header field511, which identifies the beginning of the corresponding data set, may include configuration instructions and/or routing instructions for FPGA400. Header511may also include a stop instruction that instructs processor210to halt any currently executing operation. Configuration data field512may include configuration data for configuring configurable elements250to implement a desired design. Soft data field513may include soft data such as firmware code, software programs or routines, and other executable instructions for use by processor210. For some embodiments, soft data field513may include additional data, for example, to be applied to configurable elements250and/or for use by processor210. End field514, which identifies the end of the corresponding data set, and thus the boundary between adjacent data sets, may include a commence instruction, a trigger signal, and/or a wait signal. As explained below, the commence instruction may be used to commence operation of processor210, the trigger signal may be used to instruct test circuitry160to process the next data set, and the wait signal may be used to delay processing of the next data set for a predetermined time period, for example, to allow sufficient time for a procedure embodied in a previous data set to be completed. For some embodiments, the wait signal may indicate the predetermined time period. For other embodiments, the wait signal may be eliminated from end field514, and control logic410may automatically instruct test circuitry160to wait a predetermined time period after detection of the trigger signal before processing the next data set.

FIG. 6shows an exemplary diagram600illustrating the basic steps performed when loading an integrated data file having a format of the type indicated inFIG. 5into FPGA400. First, for each data set510, a user specifies the design to be implemented within FPGA400, specifies software and/or other instructions corresponding to the design, and specifies whether the data set includes a wait signal (601). Then, the bitstream is constructed to include a plurality of data sets510, each having corresponding fields511–514that embody the user's specifications (602). Thus, each data set510forms a different data load to be provided to FPGA400in a single operation. For example, the configuration data in field512of each data set may embody a different user-specified design to be implemented by configurable elements250, the soft data in field513of a first data set may include firmware code to initialize processor210to an operational state, and the soft data in fields513of subsequent data sets may include software programs to be executed by FPGA400.

The integrated bitstream is then provided to FPGA400in a JTAG-compatible format via its JTAG pins204(603). For one embodiment, the bitstream is constructed using well-known JTAG command sets (e.g., as a series of TDI, TMS, and TCK signals). After the bitstream is received by test circuitry160and control logic410(604), successive data sets510in the bitstream are sequentially processed as follows. In response to the stop instruction contained in the header511of the first data set, test circuitry160instructs processor210to cease all current operations using well-known JTAG commands provided to processor210via its JTAG test unit215(605). Once the operation of processor210is halted, configuration data contained in configuration data field512is routed to and loaded within block RAM230and/or configuration memory cells240to configure FPGA400to implement the design specified by the configuration data (606). The configuration data may be routed to block RAM230and/or configuration memory cells240in a well-known manner using either test circuitry160or configuration circuit220.

For some embodiments, the data set (e.g., either header511or data field512) may include one or more configuration data routing instructions that specify whether configuration data contained in the data field512is to be loaded into block RAM230and/or configuration memory cells240using test circuitry160or configuration circuit220. For example, when in a first state, the configuration data routing instruction may instruct control logic410to intercept the configuration data from JTAG pins204and route the configuration data to configuration circuit220for loading into block RAM230and/or configuration memory cells240, and instruct test circuitry160to not process the configuration data. Conversely, when in a second state, the configuration data routing instruction may instruct control logic410to not intercept the configuration data, in which case test circuitry160routes the configuration data to block RAM230and/or configuration memory cells240using its boundary-scan architecture161.

Next, soft data (e.g., firmware code, software programs, and/or other instructions) contained in field513is routed to and loaded within various memory elements accessible by processor210(607). As mentioned above, the memory elements accessible by processor210may include block RAM230, memory elements within processor210such as cache unit212, and external memory270. The soft data may be loaded into block RAM230, external memory270, and/or memory elements within processor210using well-known JTAG commands via test circuitry160. The soft data may also be loaded into block RAM230using configuration circuit220.

For some embodiments, the data set (e.g., either header511or data field513) may include one or more soft data routing instructions that specify whether soft data contained in the data field513is to be loaded into block RAM230using test circuitry160or configuration circuit220. For example, when in a first state, the soft data routing instruction may instruct control logic410to intercept selected soft data from JTAG pins204and route the selected soft data to configuration circuit220for loading into block RAM230, and instruct test circuitry160to not process the selected soft data. Conversely, when in a second state, the soft data routing instruction may instruct control logic410not to intercept the soft data, in which case test circuitry160routes all soft data to designated memory elements accessible by processor210using its boundary-scan architecture161.

After the soft data is loaded into memory elements accessible by processor210, test circuitry160instructs processor210to commence operation using well-known JTAG commands in response to the commence instruction contained in the end field514(608). Thus, for embodiments in which processor210is executing code when instructed to cease operations at605, processor210resumes execution of the code at608. For embodiments in which processor210is not operational at605, processor210initializes itself using the recently loaded firmware code at608.

Thereafter, test circuitry160becomes idle (e.g., during which time test circuitry160does not route data or instructions to processor210), and awaits detection of the trigger signal, as tested at609. The trigger signal may be detected using either the well-known JTAG “SAMPLE” command or the well-known JTAG “EXTEST” command. As mentioned above, for some embodiments, the trigger signal may be accompanied by a wait signal that causes control logic410to halt operation of test circuitry160for a predetermined time period. The predetermined time period may be measured in a well-known manner using either a hardware timer or a software timer. The inclusion of the wait signal in the data set may be used to allow processor210sufficient time to complete specified tasks (e.g., to initialize itself or to complete execution of programs and other instructions contained in the preceding soft data field513) before test circuitry160begins processing information contained in the next data set of the bitstream. Thus, for some embodiments, processor210is performing one or more tasks during the predetermined time period.

If the trigger signal is detected, as tested at609, test circuitry160determines whether the bitstream includes additional data sets (610). If there are additional data sets, as tested at610, the next data set is enabled for processing at605. Otherwise, the configuration operation terminates at611. For other embodiments, control logic410may determine whether there are additional data sets and instruct test circuitry160accordingly.

Embodiments of the present invention may be utilized to implement a variety of configuration operations that require a sequence of multiple data and instruction loads. Specifically, for some embodiments, integrated bitstream500may be used to initially configure FPGA400for one or more non-operational tasks (e.g., such as a testing or diagnostic operation) and then used to configure FPGA400to implement a desired operational design. For example, embodiments of the present invention may be used to more efficiently implement fault testing of IC devices such as FPGAs than prior configuration techniques that require a plurality of separate configuration bitstreams and operations.

For one embodiment, fault testing of FPGA400using a plurality of test patterns may be implemented by constructing an integrated bitstream having a plurality of first data sets and a second data set, wherein each of the first data sets contains a test pattern, a plurality of associated test vectors, and corresponding configuration and/or testing instructions, and the second data set includes configuration data, soft data such as processor firmware code, and corresponding instructions to implement a user-specified operational design.

For example,FIG. 7shows an exemplary data set710of an integrated bitstream500in accordance with the present invention that may be used for fault testing FPGA400. Data set710includes a header511that contains a configuration instruction711, a configuration data field512that contains a test pattern712, a soft data field513that contains a test instruction713A and associated test vectors713B(1)–713B(n), and an end field514that contains a trigger signal714A and a wait signal714B.

An exemplary test operation for FPGA400using an integrated bitstream including a plurality of data sets710and an additional data set (not shown) that includes a user-specified operational design and corresponding configuration instruction is as follows. First, test instruction711and configuration test pattern712are received by test circuitry160and control logic410. In response to test instruction711, test circuitry160and/or control logic410configures FPGA400with test pattern712. Then, test circuitry160receives the test instruction713A and, in response thereto, applies subsequently received test vectors713B(1)–713B(n) to FPGA400to generate corresponding output vectors, which are then compared with expected results to determine whether there any faults in FPGA400. The application of test vectors713B(1)–713B(n) to FPGA, as well as the comparison of their generated output vectors to expected results, may be implemented in a well-known manner, and are therefore not described in detail herein.

For some embodiments, test instruction713A instructs test circuitry160to apply subsequently received data as test vectors to FPGA and indicates the length of (and thus the boundaries between) test vectors713B(1)–713B(n). For other embodiments, each test vector713B may be preceded by its own corresponding test instruction713A.

Thereafter, upon detection of the trigger signal714A, test circuitry160pauses for a predetermined time period as indicated by the corresponding wait signal714B, and then operates upon the next data set710of the integrated bitstream to apply a second group of test vectors to a second test pattern for FPGA400. This process is repeated until each of the plurality of test patterns contained in the integrated bitstream are applied to FPGA400to achieve a desired level of fault coverage. Thereafter, test circuitry160receives the operational configuration instruction and its corresponding configuration data and soft data and configures FPGA400to implement the operational design specified by the user.

For another embodiment of fault testing FPGA400, processor210may be used to compare the resultant output vectors with the expected results. For example, the integrated bitstream used for testing FPGA400may be modified to further include a test program to be used by processor210to compare each set of generated output vectors to an expected signature. For such embodiments, an additional data set including the test program and a number of expected signatures may be inserted within the integrated bitstream. In operation, test circuitry160receives and loads the test program and corresponding expected signatures into memory elements accessible by processor210, initializes processor210to an operational state, and instructs processor210to load the test program for execution. Then, in response to test instruction713A, test circuitry160applies each set of test vectors713B to FPGA210, and processor210executes the test program and compares the generated output vectors with the expected signatures.

For some embodiments, the test program loaded into and executed by processor210may also include suitable instructions that enable processor210to control the application of the test vectors to FPGA400to generate the resultant output vectors. For such embodiments, processor210may control the clocking of the test vectors into FPGA400as TDI/TMS bit pairs from the JTAG port204.

Embodiments of the present invention may also be used to configure FPGA400sequentially in a phased manner, where each configuration phase allows FPGA400to perform more complex functions and/or to access increasing portions of the FPGA's resources. For some embodiments, FPGA400may be implemented in a system that detects its configuration (e.g., resources) during a phased boot-up process. For one embodiment, FPGA400may be implemented as a hardware controller to sequentially detect and enable configuration of various resources connected to a personal computer system, and the integrated bitstream may be constructed to sequentially configure the FPGA to enable the computer system to operate with various predetermined levels of resources.

For example, upon system power-on, the FPGA may initially detect a first level of resources (e.g., a monitor, a keyboard, and a mouse) connected to the computer system, and if these resources are detected, the FPGA is configured to incorporate the functionalities of these first level resources into the computer system. Then, the FPGA may initiate detection of one or more second level resources (e.g., a printer) and, if the second resources are detected, the FPGA is configured to incorporate the functionality of the second resources into the computer system, and so on. In this manner, the FPGA may be incrementally configured to sequentially enable the computer system to operate with increasing numbers of resources.

Embodiments of the present invention may also be used in devices and/or systems including multiple processors to sequentially load firmware code for and/or initialize the processors in a given order using a single integrated bitstream. For purposes of discussion herein,FIG. 8shows a device800including a JTAG I/O port204, JTAG-compliant test circuitry160, control circuit410, and a plurality of processors802(1)–802(n). Device800may be any suitable semiconductor device such as an FPGA. For some embodiments, device800is an FPGA having an architecture similar to that shown inFIG. 4. Thus, for FPGA embodiments of device800, various well-known FPGA components such as configuration circuit220, block RAM230, configuration memory240, and configurable elements250are not shown for simplicity. Further, for FPGA embodiments of device800, processors802(1)–802(n) may be any suitable processor having test circuitry that can access and/or control internal processor resources and external memory devices available to the processor using well-known JTAG commands. For one such embodiment, device800is consistent with the Virtex-II Pro™ family of FPGAs available from Xilinx, Inc., and processors802(1)–802(n) are PowerPC cores available from IBM Corporation.

Configuration operations for device800are similar to those described above with respect to FPGA400ofFIG. 4. For example, for some embodiments, an integrated bitstream having a plurality of data sets such as data sets510ofFIG. 5may be provided to system800via its JTAG port204, with each data set510including configuration information (e.g., configuration instructions, configuration data, soft data, stop and commence instructions, trigger signals, and wait signals) for a corresponding processor802. Thereafter, control logic410and test circuitry160use the information in the data sets to sequentially configure processors802(1)–802(n). For some embodiments, the order in which processors802(1)–802(n) are configured may be controlled by one or more ordering instructions provided in the integrated bitstream. For other embodiments, the order in which processors802(1)–802(n) are configured may be predetermined.

Embodiments of the present invention may also be used for providing multiple data loads in a single operation to an FPGA that does not include an embedded processor. For example,FIG. 9shows an FPGA900in accordance with another embodiment of the present invention. Operation of FPGA900is similar to that of FPGA400ofFIG. 4, except that FPGA900does not include an embedded processor. Thus, multiple data loads may be provided to FPGA900in a single configuration operation in a manner similar to that described above with respect toFIGS. 4–6. Because FPGA900does not include a processor, stop instructions, commence instructions, and soft data fields513may be eliminated from the integrated bitstream provided to FPGA900. For the exemplary embodiment ofFIG. 9, the routing of signals from JTAG pins204to block RAM230and configuration memory cells240via boundary-scan architecture161is represented by signal bus901.

For example,FIG. 10shows an exemplary diagram1000illustrating one embodiment of a configuration operation for FPGA900. After a user specifies the designs, instructions, and wait signals, the bitstream is constructed to include a plurality of data sets, each having a header, a configuration data field, and an end field (1001). For some embodiments, the configuration data in each data set may embody a different user-specified design to be implemented by configurable elements250. The integrated bitstream is then provided to FPGA900in a JTAG-compatible format via its JTAG pins204(1002). After the bitstream is received by test circuitry160and control logic410(1003), configurable elements250of FPGA900are configured with the configuration data in the current data set (1004). Thereafter, test circuitry160becomes idle, and awaits detection of the trigger signal, as tested at1005. As mentioned above, for some embodiments, the trigger signal may be accompanied by a wait signal that causes control logic410to halt operation of test circuitry160for a predetermined time period. If the trigger signal is detected, as tested at1005, test circuitry160determines whether the bitstream includes additional data sets (1006). If there are additional data sets, as tested at1006, the next data set is enabled for processing at1004. Otherwise, the configuration operation terminates at1007. For other embodiments, control logic410may determine whether there are additional data sets and instruct test circuitry160accordingly.

While particular embodiments of the present invention have been shown and described, it will be obvious to those skilled in the art that changes and modifications may be made without departing from this invention in its broader aspects, and therefore, the appended claims are to encompass within their scope all such changes and modifications as fall within the true spirit and scope of this invention. For example, although present embodiments are described above in the context of JTAG-compliant test circuitry, embodiments of the present invention can be used with other suitable test architectures and standards.