The present invention relates to the field of user programmable logic devices. More specifically, the present invention is directed to a method of testing application-specific functional blocks which are embedded in a user programmable fabric.
Reconfigurable devices/fabrics are commonly made up of multiple instances of a single user programmable logic block or tile; the fundamental building block of the system. This arrangement facilitates the use of an easily scalable configuration mechanism of equally regular structure.
The insertion of application-specific functional blocks embedded within the reconfigurable device/fabric is often used to enhance the performance of the device/fabric within specific application contexts.
The incorporation of application-specific functional blocks makes it necessary to provide a system and method of testing these devices in situ. Known methods of testing embedded application-specific functional blocks generally fall into three categories.
The first category consists of methods which make use of dedicated access mechanisms for testing the application-specific functional blocks. These methods require the physical presence of additional, separate interface means in the re-configurable device/fabric. An example of a device in this category is an embedded application-specific functional block which comprises a dedicated scan-chain that is fed through the reconfigurable device/fabric.
Devices in this first category have several disadvantages. For example, these devices require separate interface and protocol support access to the application-specific functional blocks. Moreover, the extra logic required to create the interfacing logic, as well as the actual dedicated scan-chain paths incur extra design costs.
The second category of methods for testing embedded application-specific functional blocks includes methods which in some way re-configure the user programmable section of the device/fabric to act as a virtual scan chain within the device/fabric. An example of such a method includes the steps of configuring the reconfigurable device/fabric to implement a virtual scan chain around the embedded device, with part of the virtual scan chain feeding scan data into the embedded device and part of the virtual scan chain receiving the results from the embedded device.
The methods in this category share several common disadvantages. For example, the methods require the use of interconnection logic between the reconfigurable device/fabric and the embedded application-specific functional blocks. This “gasket logic” (e.g. multiplexers) allows the device/fabric to be connected directly to the pins of the application-specific functional blocks. It also however significantly increases the cost and complexity of the resulting device.
Finally, the third category of solution sees the reconfiguration of the device/fabric to act in full, or in part, as a test mechanism for embedded application specific functional blocks. This solution involves implementing a number of different functions (e.g. bus monitoring, bus emulation, built-in self test and debugging) using the reconfigurable device/fabric. Some of the methods included in the third category involve implementing pattern generator logic to validate the results of a given test. A disadvantage with this method is that the reconfigurable device/fabric is connected to the application specific functional block via a BUS. Accordingly, the system will need to use BUS access protocols and will create traffic on the system BUS during testing.
Accordingly, there is a clear need for a system and method of testing embedded application-specific functional blocks which will not result in an undue increase in the cost and complexity of the reconfigurable device/fabric.
In order to solve the problems associated with the prior art, the present invention provides a method of testing an application-specific functional block embedded in a user programmable fabric, the user programmable fabric comprising configuration data control means having inputs and outputs and the application-specific functional block having inputs and outputs, the method comprises the steps of:
routing the outputs of the configuration data control means of the user programmable fabric to the inputs of the application-specific functional block;
sending configuration data to configure the application-specific functional block to the configuration control means of the user programmable fabric;
transferring the configuration data to the configuration memory means of the application-specific functional block;
sending test data to test the application-specific functional block to the configuration control means of the user programmable fabric;
routing the outputs of the configuration data control means of the user programmable fabric to the inputs of the application-specific functional block;
testing, using the test data, the application-specific functional block;
routing the outputs of the application-specific functional block to the inputs of the configuration data control means of the user programmable fabric; and
receiving the test output data from the configuration control means of the user programmable fabric.
The configuration control means may comprise a chain of registers and the step of sending configuration data and the step of sending test data further may comprise the step of:
shifting the data through a chain of registers.
The step of routing the outputs of the configuration data control means may comprise the step of:
enabling the input of the configuration memory means of the application-specific functional blocks.
The method may further comprise the step of:
generating the test data using the user programmable fabric.
The present invention also provides an apparatus for testing an application-specific functional block embedded in a user programmable fabric, the user programmable fabric comprising configuration data control means having inputs and outputs and the application-specific functional block having inputs and an outputs, the apparatus comprises:
routing means for routing the outputs of the configuration data control means of the user programmable fabric to the inputs of the application-specific functional block;
sending means for sending configuration data to configure the application-specific functional block to the configuration control means of the user programmable fabric;
transferring means for transferring the configuration data to the configuration memory means of the application-specific functional block;
sending means for sending test data to test the application-specific functional block to the configuration control means of the user programmable fabric;
routing means for routing the outputs of the configuration data control means of the user programmable fabric to the inputs of the application-specific functional block;
testing means for testing, using the test data, the application-specific functional block;
routing means for routing the outputs of the application-specific functional block to the inputs of the configuration data control means of the user programmable fabric; and
receiving means for receiving the test output data from the configuration control means of the user programmable fabric.
The configuration control means may comprise a chain of registers and the sending means for sending configuration data and the sending means for sending test data may further comprise:
shifting means for shifting the data through a chain of registers.
The routing means for routing the outputs of the configuration data control means may further comprise:
enabling means for enabling the input of the configuration memory means of the application-specific functional blocks.
The apparatus may further comprise:
generating means for generating test data using the user programmable fabric.
As will be appreciated by a person skilled in the art, the present invention provides several advantages over the prior art. For example, the invention facilitates the testing of embedded application specific functional blocks by reusing the same mechanism used to configure the user programmable logic blocks within the reconfigurable array.
An example of the present invention will now be described with reference to the accompanying drawings, in which:
In order to test an embedded application-specific functional block within a re-configurable device/fabric, the existing configuration mechanism used for the user programmable logic section is reused in a different way. This provides a common interface to both which is independent of the number, location and type of embedded application-specific functional blocks.
In order to better describe the invention, a detailed account of the configuration of a user programmable logic block of a system in accordance with the present invention will now be described.
Now, with reference to
If there is no adjacent application-specific functional block, then the additional control outputs and the existing configuration data paths that would have been used by the missing application-specific functional block will instead be connected into the adjacent user programmable logic block. If this is the case, the neighbouring block will ignore any configuration data on the existing routing network driven by its immediate neighbour while the device/fabric is in configuration mode. The additional control output supplied by the blocks of user programmable logic may or may not be used to facilitate more advanced configuration options.
Configuration chain based testing of embedded application-specific functional blocks is achieved by the following method. The first step consists of configuring the application specific functional block into a particular test state. To do this, predefined data is shifted into the configuration chains within the adjacent user programmable logic blocks 702, 703 using a series of shift operations.
The array is then switched out of configuration mode and into run mode and the array clock is enable for one cycle. This will cause the application specific functional block to start processing the data that is on its input ports.
Once this is done, the array is switched back into configuration mode and further data is written into the configuration chain, as required. As new input data is shifted into the chain, the application specific functional block output data from the previous clock cycle is shifted out of the end of the configuration chain at the same time.
The above sequence can be repeated as many times as required, with varying configuration data, until all operating modes of the application-specific functional block have been tested, and all results data compared against expected results.
When configuring application specific functional blocks, configuration chains located within user programmable logic on either side may need to be accessed together in a synchronised manner depending on the configuration chain topology.
Alternatively, data written into an application specific functional block may come from a configuration chain within a user programmable logic block on a first side whilst the results data may be read via a configuration chain within the user programmable logic block on a second side.
Now, with reference to
As shown in
The above chain structure then allows a number of operations to be performed in response to a specific value of the control input, examples of which are shown in the following table.
Using the above operations, it is possible to program the user configurable logic blocks. In this specific example, this is achieved by performing the following sequence of operations.
First, the address of the required configuration cell 601 location must be asserted to the address inputs. This is done at the beginning of the sequence to allow the address to propagate over the long distances of the fabric (the address bus is not registered in this example but may be in other architectures).
Secondly, the required data is shifted into the configuration chain(s) using the SHIFT operation. As shown in
The next step consists of performing a WRITE function using the data contained within the configuration chain registers 601. As shown in
As will be appreciated, application specific functional blocks can be anything from complex logic functions to RAM blocks. Accordingly, each application specific functional block will have different features or modes that need to be configured before use. These configuration settings will be stored in configuration registers within each application specific functional block. These configuration registers are only accessible via the application specific functional block input/output ports the application specific functional block is in configuration mode. When the application specific functional blocks are in non-configuration mode, the input/output ports are switched to connect to their internal logic functions and/or RAM for normal run-mode use.
Now, again with reference to
The first step in this method is to assert the address of the required configuration cell location to the address inputs. Then, one or more NOP operations are performed in order to allow the address to propagate over the long distances of the fabric. Again, although, in this example the address bus is not registered, it may be in other architectures.
The next step in the method is reading the data at the addressed configuration memory location within each block into the registers 601 on the configuration chain. This is done using the READ operation.
Then, the read data is shifted along the configuration chain, each data word emerging from the end (output) of the chain being stored. This is done using the SHIFT operation. This SHIFT operation is repeated until all read data has been output from the chain. The steps of the above method are then repeated until all configuration locations have been read.
Now, with reference to
This produces an indirect testing scheme where all control/data required to test the embedded application functional blocks 902 is treated as configuration data by the configuration mechanism and then transferred to the embedded functional blocks by existing data paths. It is then down to the embedded functional block 902 itself to interpret the control and data correctly while in configuration mode.
Thus, “reg_input_x” and “reg_output_x” signals are mapped to the inputs and outputs shown In
In order for the data on the signals shown in
In addition, the Configuration Control Output signal “config_control_output” from each user programmable logic block must also be input to each application-specific embedded functional block as well as being input to the next programmable logic block. During an EMBEDDED_ACCESS operation, only the embedded application-specific functional block is sensitive to the Configuration Control signal.
As shown in
In this example of the present invention, the method for configuring an embedded application-specific functional block 902 have the following steps.
First, using the SHIFT operation, control, address and configuration data is shifted into the associated configuration chain(s) in order for the application-specific functional blocks 902 to be written by the chains. In this example, the address of the memory location, the data to be written and the command to be performed, EB_WRITE are shifted from one register to the other. This last step is repeated until all the required configuration and control data has been shifted into the chain.
Then, one or more NOP operations are performed to allow the data outputs of each register on the configuration chain to propagate through the user programmable logic block. Again, this is a precautionary measure and may not be required in other examples of the present invention.
The next step in the method is to perform an EMBEDDED_ACCESS operation on the configuration chain triggering the application-specific functional blocks 902 to enable their configuration inputs and therefore, in this instance, perform the required EB_WRITE operation. Then, one or more NOP operations are performed in order to allow the embedded application-specific functional blocks 902 to complete the current operation (EB_WRITE). Finally, the above steps are repeated for each configuration address locations within the application-specific embedded blocks 902.
Now, the method of reading configuration data back from the application-specific embedded blocks will now be described.
First, a SHIFT operation is performed in order to shift the required control, address and configuration data into the associated configuration chain(s) for the application-specific functional blocks 902 to be read by the chain(s). In this case the address of the memory location, the data to be read and the command to be performed, EB_READ. This step is repeated until all the required configuration and control data has been shifted into the chain.
Then, one or more NOP operations are performed in order to allow the data outputs of each register on the configuration chain to propagate through the user programmable logic block. Again, this is merely a precautionary measure.
An EMBEDDED_ACCESS operation is then performed on the configuration chain triggering the application-specific functional blocks 902 to enable their inputs, and therefore perform the required operation, a EB_READ in this instance.
Then, one or more NOP operations are performed in order to allow the embedded application-specific functional blocks 902 to complete the current operation (EB_READ) and present the read data on their outputs.
Once this is done, an UPDATE_CHAIN operation on the configuration chain is performed. This is similar to a READ operation described earlier but data from the embedded functional block is routed to the register inputs on the configuration chain, as shown in by the bold data lines in
Then, the configuration chain is shifted using the SHIFT operation and the output data words are stored. This step is repeated until all data is read from the configuration chain(s). Finally, the steps of the above method are repeated for every address locations within the application-specific embedded blocks.
In order to test an application specific functional block, it is first configured in a particular mode, as described above. Then, it is switched into a NOP state. At that point, the user programmable logic block registers will have user programmable logic data shifted down them until the correct data is in the correct registers 601.
Then a WRITE command is issued to the user programmable logic blocks, which will enable the connections between the adjacent user programmable logic registers and the I/O ports of the application specific functional block under test. The user programmable logic blocks configuration registers will then have application specific functional block test-data shifted down them until the appropriate application specific functional block inputs are supplied with the correct test values from their associated registers 601, in the same way as initialisation data is fed through the chain above.
Then, the user programmable logic chains are switched to a NOP state in order to hold the appropriate test-data values on the appropriate application specific functional block inputs. The entire array is then switched from CONFIG to RUN-MODE for one or more clock cycles, and then switched back to CONFIG-MODE. After this, the application specific functional block is held in a NOP state to hold its results data on its output ports. The user programmable logic chains are then switched to SHIFT mode and a sequence of SHIFT operations enables the captured data to be shifted out of the array for analysis. As described above, in order to test a directly-connected application-specific functional block using the user programmable logic, the reconfigurable array is placed into configuration mode and a test application is shifted into the configuration chains.
The implementation of a Pattern Generator (PG) can vary depending on the nature and function of the application specific functional block. One implementation involves using a Linear-Feedback-Shift-Register (LFSR) to generate a pseudo-random sequence of inputs. The choice of LFSR equation can be made during simulation of the application specific functional block, in order to ensure that suitable test coverage is achieved.
Another implementation of the PG entails using a Finite State Machine (FSM) to produce a selected sequence of test inputs to the application specific functional block. This solution is reasonably compact for a small number of different input combinations.
A further implementation of the PG involves using a block-RAM embedded elsewhere within the reconfigurable array to store larger numbers of input test vectors. For this implementation, an FSM is used, possibly with counter logic, to generate address values to enable the FSM to read out the test vectors from the block-RAM and apply them in sequence to the application specific functional block.
The implementation of the Results Capture (RC) logic can vary depending on the nature and function of the application specific functional block. One implementation uses a Multiple-Input-Signature-Register (MISR) which is like a LFSR but which takes all the outputs from the application specific functional block and merges them into the MISR structure. Once the test has been run, for the required number of clock cycles, the output of the MISR is a binary sequence. This sequence is then compared against the sequence obtained from a simulated run of the test, and used to indicate whether the test is a pass or fail.
Another implementation of the RC entails using a Finite State Machine (FSM) to generate a defined sequence of outputs which simulation has shown the application specific functional block should produce. Then the output of the FSM and the application specific functional block can be compared on a clock-by-clock basis, or on selected clock cycles, as is appropriate for the test. If all the comparisons match, then the test is deemed to have passed. This solution is also reasonably compact for a small number of different output combinations.
A further implementation of the RC involves using a block-RAM embedded elsewhere within the reconfigurable array to store larger numbers of output test vectors. An FSM is used, possibly with counter logic to generate address values to enable the FSM to read out the output test vectors from the block-RAM and compare them in sequence with the output of the application specific functional block. If all the comparisons match, then the test is deemed to have passed.
Number | Date | Country | Kind |
---|---|---|---|
08163862.9 | Sep 2008 | EP | regional |