FPGA damage from bad bitstream

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

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

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.

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

snipped-for-privacy@gmail.com wrote:

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

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.

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.

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.

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:

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

jbnote,

See answers in line below,

Austin

-snip

Encryption is used for the "bitstream", but not for configuration commands. CRC32 check is a command. Startup is a command.

It is unlikely that an attacker can change what they want to cause a specific result, as CBC will corrupt the following block(s) as well. If they already knew the design, then they don't need to un-encrypt the bitstream, do they? If they just wish to break it, use a hammer. If they wish to insert their own program, NOTHING prevents that (we accept all bitstreams, a true equal opportunity employer).

Yes, you can just skip the CRC check, and startup anyway. Virtex 2 and later devices are unlikely to "burn up" but they may be some contention.

Oh, that would be nice, but no, the bits do nothing of the sort. If you wished, you could use those bits for a watermark, or some other reason. Just because we call them the frame syndrome bits doesn't really make them special (until you want to use the FRAME_ECC feature).

One totally unobvious one is:

Running without an MGT hooked up for 400 hours might cause it to permanently fail!

about 10 years ago i had a loaded one from a bad eeprom. blew little holes in the package.

Hi Austin,

Thank you for the heads up on bitstream encryption. I have one more concern about loading random garbage while looking closer at the bitstream format. I'm no electrical engineer, so this is purely from a software standpoint.

It seems every "standard" pip is controlled by a bit pattern of two bits over (4+4) bits in the bitstream, with one bit chosen in the first set and another chosen in the second set. I'm just guessing that this one-hot encoding means that there's no mux for this connexion. Couldn't you get electrical contention just by ANDing two valid bit patterns, such as:

(0,0,0,1, 1,0,0,0) and (1,0,0,0, 0,1,0,0) ?

This would considerably raise the chances of electrical problems.

Now I'm also left wondering why you aren't compressing the bitstream data by a factor of two by encoding the one-hot position in each set on only two bits (possibly "uncompressing" the bitstream on the fly to internal SRAM, but therefore disallowing invalid patterns from being loaded ?). But I guess that's another problem entirely.

JB

Hello friends,

I Have just started going through ethernet.my doubt is what is the main functionality of Ethernet MAC??? In switch controller implementation on FPGA does 4 tranceivers require 4 Ethernet MAC's???if so why??Because the source and the destination systems will have ethernet controller and MAC built in???please answer these questions.It's haunting me.

Thanks. Regards, Hema.

jbnote,

Sorry, but we do not discuss how our parts work. If you are curious, you may go to

As well, the view in FPGA Editor is a fiction: merely a convenience for the user to visualize the internal workings. FPGA Editor is a software representation - there is no hardware construction details that you should assume are there (they are not). The "pip" or programmable interconnect point, in fact, does not exist in reality.

Austin

Multi-Gigabit Transceiver?

Jon