🚀 go-pugleaf

In article <1993Jan11.142553.5103@ips.cs.tu-bs.de> koch@eis.cs.tu-bs.de (Andreas Koch) writes:
>Is it possible to physically destroy a Xilinx 3000 series LCA
>by programming only (meaning: outside electrical parameters
>are within valid bounds)? Since we are in the process of
>establishing FPGA design labs, we would like to know if
>we have to watch out for critical design flaws which would
>endanger our LCAs. Any hints are appreciated!
>
>Andreas Koch
>-- 
>Andreas Koch                                Email  : koch@eis.cs.tu-bs.de
>Institut f"ur theoretische Informatik       Phone  : x49-531-391-2384
>Abteilung Entwurf Integrierter Schaltungen  Phax   : x49-531-391-5840
>Gaussstr. 11                                Telex  : 95 25 26

Yes, it is possible to short a lot of nodes together with the wrong data programmed into
the LCA.  If you are using the Xilinx design software you don't have to worry about
it though.  The software will prevent you from programming it wrong.  

luoni@jasper.mlb.semi.harris.com (Perry Luoni) writes:

>In article <1993Jan11.142553.5103@ips.cs.tu-bs.de> koch@eis.cs.tu-bs.de (Andreas Koch) writes:
>>Is it possible to physically destroy a Xilinx 3000 series LCA
>>by programming only (meaning: outside electrical parameters
>>are within valid bounds)? Since we are in the process of
>>establishing FPGA design labs, we would like to know if
>>we have to watch out for critical design flaws which would
>>endanger our LCAs. Any hints are appreciated!
>>
>>Andreas Koch
>>-- 
>>Andreas Koch                                Email  : koch@eis.cs.tu-bs.de
>>Institut f"ur theoretische Informatik       Phone  : x49-531-391-2384
>>Abteilung Entwurf Integrierter Schaltungen  Phax   : x49-531-391-5840
>>Gaussstr. 11                                Telex  : 95 25 26

>Yes, it is possible to short a lot of nodes together with the wrong data programmed into
>the LCA.  If you are using the Xilinx design software you don't have to worry about
>it though.  The software will prevent you from programming it wrong.  


We are worried about this too.  We have been told that as long as the
configuration only causes internal drivers to clash with each other, the
device will survive, but if you cause pin drivers to clash with other
devices on your board, the device can be permanently damaged.

We are not totally convinced that this is good advice.  We have seen a device
get _very_ hot with only internal contention.


By the way, the problem is not doing this at the design stage.  If you are
building 200 units a week using an LCA in a pqfp package, you are going to
get a percentage of boards that will not correctly load the LCA config
from the prom.  (this is most likely when you use the parallel prom mode)
We see our prototype get very hot when it can't read the prom correctly
and we are worried that we will have the LCA destroyed on each board that
has a fault that stops the config prom from loading correctly.

-- 
Scott Colwell				Labtam Australia Pty. Ltd.
net:	scott@labtam.labtam.oz.au	41 Malcolm Rd., Braeside
phone:	+61-3-587-1444			Melbourne, Australia  3195

In <scott.726798144@labtam> scott@labtam.labtam.oz.au (Scott Colwell) writes:
>luoni@jasper.mlb.semi.harris.com (Perry Luoni) writes:

>>In article <1993Jan11.142553.5103@ips.cs.tu-bs.de> koch@eis.cs.tu-bs.de (Andreas Koch) writes:
>>>Is it possible to physically destroy a Xilinx 3000 series LCA
>>>by programming only (meaning: outside electrical parameters
>>>are within valid bounds)?

>>Yes, it is possible to short a lot of nodes together with the wrong data programmed into
>>the LCA.  If you are using the Xilinx design software you don't have to worry about
>>it though.  The software will prevent you from programming it wrong.  

>We are worried about this too.  We have been told that as long as the
>configuration only causes internal drivers to clash with each other, the
>device will survive, but if you cause pin drivers to clash with other
>devices on your board, the device can be permanently damaged.

>We are not totally convinced that this is good advice.  We have seen a device
>get _very_ hot with only internal contention.

There are additional ways you can get the devices to fail in the field. The
parts are CMOS, so, for example, if you accidentally let internal nodes
float, the part may conduct more current, get real hot, and fail soft.
Any type of floating node is bad for CMOS, since even dinky little inverters
can draw lots of current when their inputs are floating. And, of course, this
is very lot dependent.

Another poster mentioned that the design software protects you, but that wasn't
always true in the past, and I'm not sure if it's 100% true now. Also, where I
used to work one of the engineers would do all his own routing, since he got
much higher utilization than the software could do. A floating node or two did
slip thru, though, which caused some soft failures out in the field. These
were easy to diagnose, since the Xilinxes did get real hot. We gave our
customers the choice of a new serial PROM with new configuration bits or to
return the product to the factory for replacement of the Xilinx itself.
(Those PQFPs are no fun to rework!) Most customers chose the PROM, and
invariably the overstressed Xilinxes worked fine and ran nice and cool with
the new PROMs. Of course they may well have longer term reliability problems.

In article <scott.726798144@labtam> scott@labtam.labtam.oz.au (Scott Colwell) writes:
>luoni@jasper.mlb.semi.harris.com (Perry Luoni) writes:
>
>>In article <1993Jan11.142553.5103@ips.cs.tu-bs.de> koch@eis.cs.tu-bs.de (Andreas Koch) writes:
>>>Is it possible to physically destroy a Xilinx 3000 series LCA
>>>by programming only (meaning: outside electrical parameters
>>>are within valid bounds)? Since we are in the process of
>>>establishing FPGA design labs, we would like to know if
>>>we have to watch out for critical design flaws which would
>>>endanger our LCAs. Any hints are appreciated!
>>>
>>>Andreas Koch
>>>-- 
>>>Andreas Koch                                Email  : koch@eis.cs.tu-bs.de
>>>Institut f"ur theoretische Informatik       Phone  : x49-531-391-2384
>>>Abteilung Entwurf Integrierter Schaltungen  Phax   : x49-531-391-5840
>>>Gaussstr. 11                                Telex  : 95 25 26
>
>>Yes, it is possible to short a lot of nodes together with the wrong data programmed into
>>the LCA.  If you are using the Xilinx design software you don't have to worry about
>>it though.  The software will prevent you from programming it wrong.  
>
>
>We are worried about this too.  We have been told that as long as the
>configuration only causes internal drivers to clash with each other, the
>device will survive, but if you cause pin drivers to clash with other
>devices on your board, the device can be permanently damaged.
>
>We are not totally convinced that this is good advice.  We have seen a device
>get _very_ hot with only internal contention.
>
>
>By the way, the problem is not doing this at the design stage.  If you are
>building 200 units a week using an LCA in a pqfp package, you are going to
>get a percentage of boards that will not correctly load the LCA config
>from the prom.  (this is most likely when you use the parallel prom mode)
>We see our prototype get very hot when it can't read the prom correctly
>and we are worried that we will have the LCA destroyed on each board that
>has a fault that stops the config prom from loading correctly.
>
One solution would be to current limit the supplies when you are testing the part.
There really isn't any way to eliminate the problem.  If you look at the schematics
to the 3000 series you will see you can pretty much connect anything with anything
or short damn near every node in the chip together.  If you want to try to burn one
out just for fun try programming every memory location to a one, I'm pretty sure
you will have a near worst case condition.   If you guys want to buy some radiation hardened
parts (3090) we will be selling them next year for about $3500.00 a piece.

I have blasted a XC3042 by misprograming it.  I was debugging
some C code to load the configuration from a microprocessor, and
apparently misprogrammed the device.  It got real hot, smelled real
bad, developed a crack on top (PQFP package), and oozed some kind
of oil out the crack.  It took be quite a while to perfect the code
and misprogrammed it many, many times but only once did it achieve 
meltdown.

I sent the part to Xilinx, they ripped it apart and told me I blew it 
up (duh). All the ground bonds were vaporized. I believe that it
was mainly due to misprogramming IO pads such that they were set
to logic low outputs. Causing the part to try to sink all the input
signals from other devices on the board.

The XC4000 series parts will prevent you from missprograming, they have
a checksum per line of data, and a CRC check that you can enable
for the whole file,  I've tried misprograming an XC4005 without success.




steve holmes                       BNR
email: sherlock@bnr.ca             Research Triangle Park, NC