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
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.
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: Static Current Drawn in Contention-Free Mode
||< 1 mA
||< 1 mA
||< 1 mA
||< 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.
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.
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
||< 1 mA
||< 1 mA
||100 mA @ 1.73V
||< 1 mA
||< 1 mA
||100 mA @ 1.63V
||< 1 mA
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
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.
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.
We would like to thank Jaro Pristupa for his help setting up and
maintaining the test equipment.