Does anyone know if it is possible to permanently
harm a Xilinx FPGA
internally through a bad (accidental or malicious) bitstream?

I realize the DRC would catch any problems, but DRC can be turned off
potentially permitting multiple drivers on the same long line or clock
net.

Thanks.
Stephen

"s...@gmail.com"
<s...@gmail.com> wrote:

>Does anyone know if it is possible to permanently harm a Xilinx FPGA
>internally through a bad (accidental or malicious) bitstream?

YES. Been there done that. I've cooked 2 Spartan2 fpgas that way when
developing JTAG download software.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Stephan,

In the past, before Virtex architecture, it was possible to create
contention in the bitstream (connect two outputs together).

With Virtex, and its new methods of interconnect (fully buffered, no
tristate), we had fewer and fewer places where contention could occur.

Now with Virtex 5, it is almost impossible to create intentional
contention.  There are still some structures where the wrong bits will
connect two outputs together, but these are very few, and do not amount
to a large heat load (device will not be damaged, the currents in the
metal does not even exceed the EM rules!).

The loading of a random bitstream does create some issues, as there are
other bits which are part of the stream that can, and do affect power.

For example, by turning ON all of the parallel DCI impedance matching
circuits, one could have 200 ohms from Vcco to ground, on every IO pin!
 Given 500 to 800 IO's, that is 200/500 ohms, or 200/800 ohms (0.25
ohms) from Vcco to ground.  At 3.3 volts, that is 13 amperes, or 40 watts!

If you intentionally made a 500 MHz clock, and then connected all the
CLB's in a shift register chain (including SRL32's in V5 or SRL16's in
V4), and shifted a 1,0 pattern, I am sure you could melt the solder of a
part!

The design rule check will check for an unsupported combination of bits,
but not an intentional set of connections:  the onus is on the user to
know what they are doing, and not exceed the junction temperature
specification.  SO an "attack" using DCI or a giant shift register would
succeed.

In that sense, a "denial of service" attack on an FPGA is much simpler
if you have physical access -- just hit it with a hammer and be done
with it!

If you hacked into a network management system, and knew that you could
download bitstreams to network elements, I would hope that there are
sufficient security protocols in place so that you could not destroy a
system remotely by downloading a pattern with all DCI turned ON.

For example, if bitstream encyption is used, if you do not know the key,
the bitstream is garbage, the CRC32 does not match, and the device never
starts up (DONE does not go high).

Unlike a microprocessor, there is no possibility of a single "halt and
catch fire" instruction.

Austin

s...@gmail.com wrote:

>Does anyone know if it is possible to permanently harm a Xilinx FPGA
>internally through a bad (accidental or malicious) bitstream?
>
>I realize the DRC would catch any problems, but DRC can be turned off
>potentially permitting multiple drivers on the same long line or clock
>net.
>
>  
>
Note that the bitstream is checked on-chip by CRC before the configuration
is alowed to take place.  So, unless the "bad" bitstream was carefully 
constructed
to have a valid checksum, it would just keep the chip disabled.

Jon

There was a Paper at FPL 1999 about destryoing
FPGAs by implementing
many internal ring oscillators.
http://www.springerlink.com/content/9wnbm5eqgpjvlcug/

They were using Altera FPGAs and the Xilinx crowd in the auditorium
burst into spontaneous applause.
But the speaker pointed out that the same would be possible with Xilinx
FPGAs.

Kolja Sulimma

s...@gmail.com wrote:
> Does anyone know if it is possible to permanently harm a Xilinx FPGA
> internally through a bad (accidental or malicious) bitstream?
>
> I realize the DRC would catch any problems, but DRC can be turned off
> potentially permitting multiple drivers on the same long line or clock
> net.
> 
> Thanks.
> Stephen

I agree in principle, but it sometimes gets a
little more complicated.

> Note that the bitstream is checked on-chip by CRC before the configuration
> is alowed to take place.  

Technically, the CRC is computed on a frame by frame basis, so errors 
might indeed prevent startup for a full bitstream, but for a partial 
active reconfiguration the frames that passed CRC would still be 
reconfigured.

> So, unless the "bad" bitstream was carefully constructed to have a
> valid checksum, it would just keep the chip disabled.

Yes, for a full bitstream that was corrupted by accident.  But 
recomputing the CRCs on a deliberately modified bitstream, or just 
disabling CRC checking altogether, is easy to do, even though Austin 
tells us it would be unlikely to harm the device.

My bad.  I was trying to respond to Jon Elson.

I agree in principle, but it sometimes gets a
little more complicated.

> Note that the bitstream is checked on-chip by CRC before the 
> configuration is alowed to take place.

Technically, the CRC is computed on a frame by frame basis, so errors 
might indeed prevent startup for a full bitstream, but for a partial 
active reconfiguration the frames that passed CRC would still be 
reconfigured.

> So, unless the "bad" bitstream was carefully constructed to have a 
> valid checksum, it would just keep the chip disabled.

Yes, for a full bitstream that was corrupted by accident.  But 
recomputing the CRCs on a deliberately modified bitstream, or just 
disabling CRC checking altogether, is easy to do, even though Austin 
tells us it would be unlikely to harm the device.

Oh, I get it.  I just don't know how to use my
news reader.

Hi Austin,

This raises intersting questions:

> For example, if bitstream encyption is used, if you do not know the key,
> the bitstream is garbage, the CRC32 does not match, and the device never
> starts up (DONE does not go high).

Sorry for not reading the docs, is encryption only used on frame data
in the bitstream?

- If encryption is for the full bitstream, then there's not even one
chance that the random garbage will make sense to the bitstream
microcontroller, so you're safe.

- If encryption is limited to the data stream, then on the virtex2,
it's very easy to disable CRC checking and load random garbage for
which I'd guess frying configurations on long lines would not be
uncommon (let's do the math !).

On virtex4 and virtex5, I'd expect that each frame's Hamming SECDED
code is checked by the loading state machine and encrypted, so random
garbage would be rejected ? Or does Hamming Code sits there for nothing
at load-time ?

JB