POWELL Testing


Tested by: Ian Kuon, Aaron Egier and Jonathan Rose (ikuon|aegier|jayar at eecg.utoronto.ca)
Update Date:
  February 15, 2005.

As part of the GILES project, we created an entire FPGA that was taped out March 24, 2004 and five packaged parts were received on November 22, 2004.  These packaged parts were to be tested to be tested to confirm the simulated functionality.  This document describes this testing process

Test Equipment

The packaged parts were tested on a VXI system composed of an HP9000/754i Controller connected to HP E1450A and HP E1451A Timing and Pattern modules.  The test equipment was controlled using HP VEE test program.  A CMC TH1000 test head was used for interfacing the packaged parts with the pattern modules.  An HP E3631A power supply, an HP 34401A multimeter and a Tektronix TDS 380 oscilloscope were also used as needed

Results

The testing was done in stages and the tests along with the results of each test are described below.  With each stage more of the functionality of the design was verified. Since the final tests were not successful, the attempts to debug the failure are also described.

Power-On Test

The fabricated device has many potential sources of contention if mis-configured. After power up, the SRAM initialize to an unknown state and, therefore, to avoid problems from contention, the FPGA design allows for a contention free state that can be used prior to programming. This mode of operation is used when the device is first powered up. Current measurements were taken in this mode to verify that the static current prior to programming is not excessively high. The success of this test indicates that this contention free mode functions correctly. An excessively high current could also suggest the presence of manufacturing defects. The results from this test are summarized in Table 1.

Table 1: Static Current Drawn in Contention-Free Mode

Device
Core Current
Ring Current
Device 1
18.9 mA
< 1 mA
Device 2
17.0 mA
< 1 mA
Device 3
19.0 mA
< 1 mA
Device 4
16.7 mA
< 1 mA
Device 5
21.1 mA
< 1 mA

The static current observed for all devices was around 20 mA. This is higher than anticipated but was still considered reasonable. Therefore, testing proceeded to the next stage.

Programmer Testing

One critical part of the device is the programmer controller. This controller handles the loading of the bitstream into each of the configuration SRAM bits in the design. Since all the configuration bits are set using this controller, its proper operation is essential. If functioning correctly, the controller should immediately indicate this to the user via an output pin that signals programming can commence.

Testing of the controller found it to be functional on all the packaged parts. Functionality was verified solely using a single output pin from the controller which does not provide full observability of the entire block. However, since the basic functionality was confirmed, this testing was considered sufficient for proceeding to the next stage.

Programming Test - Inverter

With the functionality of the basic infrastructure of the FPGA confirmed, the next test involved verifying the ability to correctly program the FPGA's configuration bits to implement an arbitrary circuit using the FPGA. For this first test, the FPGA was to be configured to implement a single inverter. The success of this test would demonstrate that most of the desired functionality operates correctly.

This test was unfortunately unsuccessful. After the programming was performed, the device was released from the contention-free mode since all the configuration bits should now be in the correct state.  However, as shown in Table 2, the static current is significantly higher than in contention free indicating that there is likely contention within the FPGA.  Furthermore, the FPGA did not correctly implement the inverter circuitry and, instead of performing inversion, a constant logic low (0V) was output.

Table 2: Static Current Drawn when FPGA is programmed for a Single Inverter

Device
Core Current
Ring Current
Device 1
80.6 mA
< 1 mA
Device 2
81.2 mA
< 1 mA
Device 3
100 mA @ 1.73V
< 1 mA
Device 4
68.0 mA
< 1 mA
Device 5
100 mA @ 1.63V
< 1 mA

Debugging

The failure of the simple inverter test indicated that either the configuration SRAM were not being appropriately configured or the path through the FPGA was not operating correctly.  To determine if the latter problem was the issue, other paths were attempted including paths that do not go through any logic elements.  The failure of those tests suggested an error in configuration was instead the reason for the failure.  Unfortunately, there were no on-chip resources dedicated to debugging such problems.  The decision to omit such features was made consciously because it was thought that minimizing complexity would increase the chance of a successful design. 

As a result, debugging attempts had to focus on the limited amount of available visibility.  The one directly observable portion of the design is the state of the user input/output pins.  All the user pins are physically input or output pins that are configured via the configuration SRAM.  A single SRAM bit gated by circuitry for a contention-free mode controls this state.  When the device is in normal mode (i.e. not in the pre-programming contention-free mode), the state of this bit can be checked by applying a voltage to the output pin and observing if any contention occurs.  If contention occurs that means the pin is configured as an output while if no contention occurs regardless of the applied voltage, the pin must be configured as an input.  With this limited amount of visibility, the status of at least some of the configuration bits can be monitored.

The devices were configured with various test bitstreams and the state of the pins was observed.  One configuration that was attempted was an all zeros configuration (i.e. all the SRAM bits set to '0').  The state of 20% of the user I/Os were observed and found to match with expectations.  As expected the inverse configuration of all ones led to each of the pins being in the inverse state.  (It is interesting to note that neither of these configurations sets the pins to all inputs or all outputs because one feature of the automated tools used to create the FPGA is that they swap the data and inverse data lines as appropriate to improve the quality of the placement and routing.  This is very different than more regular designs in which all inputs would be configured the same way).  The success of this test indicated that the configuration bits can change state.

While the ability to change the state of the individual SRAM bits suggests that it should be possible to configure the device properly, the failure of the single inverter test and other bitstreams indicated otherwise.  When these other configurations were loaded only some of the pins were configured correctly and the simple circuits connecting pins that functioned correctly did not behave as expected.  The specific pins that did get set correctly was also not consistent as on some devices a pin that was correctly programmed once would not be correctly set when programmed in the exact same manner.  These problems suggest that the issue lies in the setting of the word and bit lines used to configure the bits.  Attempts to determine the root cause of this failure were unsuccessful given the limited debug capabilities designed into the device.

Conclusions

Only partial functionality of the devices has been confirmed.  Power up contention-free protection circuitry and the programmer controller appear to function successfully.  Yet, the bitstream becomes corrupted and it is not possible to implement arbitrary circuits on the device.  It does appear possible to reliably toggle the configuration bits which confirms partial functionality of the programming infrastructure but the inability to set individual bits arbitrarily prevents implementing complete circuits on the device.

The inability to diagnose the problems encountered highlights some problems with the design methodology.  Simple changes such as allowing the output from the programming controller to be monitored off-chip would have greatly simplified debugging.  Simplifying the debug process and offering redundant solutions to critical portions of the design should be goals for future designs.

Acknowledgements

We would like to thank Jaro Pristupa for his help setting up and maintaining the test equipment.


Return to Jonathan Rose's Page Computer Group .