28

Can you actually break an FPGA by programming it incorrectly?

I'm a software guy really. It's no secret that if your software is wrong, you could destroy all sorts of important data, and perhaps even crash the whole machine. But it's really difficult to physically damage a computer just by programming it.

(There are endless rumous of a Halt-And-Catch-Fire instruction, or being able to reflash the system firmware to brick the motherboard, or programming incorrect values into the graphics card to fry your monitor. But these all seem to be exactly that: rumours. And all about long-obsolete hardware. It seems really, really hard to break modern computer equipment with bad programming.)

With an FPGA, you are (at least nominally) wiring individual circuits together. It seems completely plausible that physical damage might occur in case of a mistake.

For example, you could write some VHDL requesting that two outputs get tied together. If they output different logic levels, I imagine that would probably fry something. (I would hope that your synthesis tool would scream at you to not do this... but I don't know if such tools actually implement that level of error checking.)

It also seems quite possible to accidentally pick the wrong model of FPGA in the synthesis tool, and thus ending up trying to program your chip with a bitstream intended for some totally different model. I don't know what that would do, but I suspect it would be "bad".

For that matter, you could definitely connect the FPGA chip to the rest of the circuit incorrectly. E.g., if you mess up the pin numbers, you might end up with the board trying to drive an I/O pin that the FPGA itself is also trying to drive. Do the I/O pins typically have any "protection" against such a mistake? Or will the chip just fry?

MathematicalOrchid
  • 1,701
  • 2
  • 18
  • 23
  • 3
    Some FPGAs have security features that only allow loading encrypted and signed bitstream from external memory. The keys are kept in the FPGA and programmable only once. If you enable such a feature by accident or loose the keys you have essentially a "bricked" FPGA. – filo Jun 26 '19 at 06:33
  • 2
    "But it's really difficult to physically damage a computer just by programming it." you think so? Once upon a time it was up to the driver to control the hard disk heads - meaning a virus could play happy birthday on your hard disks. The BIOS controls fans - allowing it to cause damage by overheating (there might be some protection built in, but if you heat it fast enough then it can't be saved). The BIOS can even decide to try to put 20V into your CPU.... Software can very easily be responsible for damaging computers if you know which software to fiddle with. – UKMonkey Jun 26 '19 at 09:38
  • 1
    @JoL related :) https://retrocomputing.stackexchange.com/questions/6614/can-the-wrong-sync-frequency-really-destroy-a-crt-monitor – UKMonkey Jun 26 '19 at 15:34
  • *For that matter, you could definitely connect the FPGA chip to the rest of the circuit incorrectly...* And how is this different to any other chip? A regular micro will have the same problems with that too. Back in the day, many hobbyists tied simple circuits to PC parallel ports, and it was very easy to fry the port if you set it up wrong. And when you start working with microcontrollers (a more relevant comparison) it's not at all uncommon to lose a few during early circuit development whilst you iron out the interfacing bugs. – Graham Jun 26 '19 at 16:59
  • 2
    @UKMonkey https://www.youtube.com/watch?v=CsQd2n99zS4 – Joshua Jun 26 '19 at 17:42
  • 1
    It depends what software you're writing. A webserver backend in Java? Yeah, you probably won't physically destroy anything vital. Video card drivers? Set the thermal profile wrong and you could literally melt it. Literally any embedded computing device? Probably hooked up directly to something physical that could break things if you did it wrong enough. For that matter, if you build an IDE for FPGAs that sends the wrong bitstream, you could physically break the associated hardware. – Nic Jun 26 '19 at 19:39
  • 2
    @UKMonkey Depending on how your system is set up, I'm fairly sure you can melt any CPU with enough effort. _Most_ computers -- AFAIK anything not purely passively cooled -- will have a way to control the cooling system. You can disable thermal throttling, another line of defense, through the BIOS, which implies it can be done programmatically by the kernel. In that specific case, it'd have to be intentional, but it's very definitely possible. – Nic Jun 26 '19 at 19:42
  • They are definitely not rumours. [HCF is a documented instruction on the MC6800](http://bytecollector.com/archive/digital_group/documentation/hardware/dg_systems/system_cards/6800_cpu_card/6800_Instruction_Set.PDF). – OrangeDog Jun 27 '19 at 10:21
  • *being able to reflash the system firmware to brick the motherboard* - No rumour, I guarantee you. Yes, it's much harder and more uncommon than standard malware and exploitations written in higher level languages, for, dare I say, obvious reasons. But it does exist and I'seen it happen. With *modern* hardware. Although, all such bricked motherboard can most often be brought back to life by reflashing the correct BIOS again. – Marc.2377 Jun 28 '19 at 17:07
  • @OrangeDog Yes, but it doesn't actually catch fire. It simply halts the system, requiring a physical restart. – Marc.2377 Jun 28 '19 at 19:23
  • 1
    Possible duplicate of [VHDL that can damage FPGA](https://electronics.stackexchange.com/questions/293915/vhdl-that-can-damage-fpga) – Dmitry Grigoryev Jul 02 '19 at 10:13

4 Answers4

32

It also seems quite possible to accidentally pick the wrong model of FPGA in the synthesis tool, and thus ending up trying to program your chip with a bitstream intended for some totally different model.

Typically the programming software will query the part being programmed for its part number, and refuse to program in a bitstream meant for a different model of FPGA.

The part itself will also generally refuse to start up if programmed with a bitstream that isn't exactly the correct length (and it's very uncommon for bitstreams for different chips to be the same length).

you could definitely connect the FPGA chip to the rest of the circuit incorrectly. E.g., if you mess up the pin numbers, you might end up with the board trying to drive an I/O pin that the FPGA itself is also trying to drive.

This is the most likely way to damage an FPGA with wrong programming.

Another way could be to program a very resource intensive design and run it at a high frequency (so that a high power is consumed), and then run it on an FPGA without an adequate heat sink.

Do the I/O pins typically have any "protection" against such a mistake? Or will the chip just fry?

Output pins will "often" survive a short circuit condition for a few seconds or even minutes. But nothing is guaranteed.

The Photon
  • 126,425
  • 3
  • 159
  • 304
  • 1
    Interesting. Is it usual for FPGAs to need active cooling? Oh, I suppose that's an entire question in its own right. (And I guess the answer depends on many things — such as whether you bought a £15 or a £15,000 FPGA!) – MathematicalOrchid Jun 25 '19 at 18:44
  • 4
    @MathematicalOrchid, Not necessarily active cooling, but heatsinks and forced air are pretty common. The FPGA vendors usually provide a very complex spreadsheet to help determine (based on the part, the design, the clock frequency, etc) how big a heat sink and how big a fan are needed. – The Photon Jun 25 '19 at 18:46
  • 3
    @MathematicalOrchid I've used an FPGA as a frequency counter for measuring square waves up to 250 MHz. It *required* cooling as I measured a 220 MHz clock, but instead of setting up proper cooling I just made sure to not measure longer than 5 seconds. It consumed 5 W @ 220Mhz and the IC was about 2 cm^2. It got very hot very fast. – Harry Svensson Jun 26 '19 at 06:25
  • @HarrySvensson That seems like a crazy amount of heat for a frequency counter. – user253751 Jun 26 '19 at 22:17
  • @immibis Well, it was actually a CPLD with just 64 macrocells or whatever they are called, 28 were used as an async counter (chained DFF), once every second the async counter moved all its bits (and reset itself) to a 28 bit shift register that I just read off with an arduino. - Not super professional. But it worked at the time and solved my problem I had at hand. – Harry Svensson Jun 26 '19 at 22:44
  • 1
    @HarrySvensson It's still crazy that that should take 5 watts. – user253751 Jun 26 '19 at 22:59
  • @immibis I agree. – Harry Svensson Jun 26 '19 at 23:10
21

With a few noted exceptions, tools don't generally give you access to the actual silicon primitives, so it's hard for an end-user engineer to load an electrically invalid design* into an SRAM-based FPGA, except perhaps by inadvertently discovering a tool bug.

Flash based FPGAs might conceivably have their re-programmability damaged by certain invalid loads. OTP FPGAs implicitly are "damaged" by even a valid configuration load, as it can never be changed.

Ultimately what comes closest to what you are seeming to ask, and to your HCF example, would be a configuration which produced intolerable thermal stress. Power consumption is quite directly driven by clock rate and volume * activity of utilized logic, so if you can trick the tools into uselessly toggling most of the flip flops on the chip at maximum clock (there are ways...) then you can produce a pretty effective heater that would exceed most cooling systems for ordinary usage. Then it's just a question if something protectively shuts it down before it cooks. And of course there are power estimation models in the tools, which are likely reasonably predictive if you're not lying to them about the clock signal provided.

(* There is one interesting class of not-a-bug electrical issue you can cause by lying to the tools, that is not necessarily physically destructive, but still surprising. If you feed a clock different than you said you would or simply unstable, you can violate address setup timing on the synchronous block RAM cells, and do something along the lines of shorting them and corrupting their contents - so you can for example see the contents of something designated a ROM in the design actually change at runtime just by trying to read it with a bad clock. But I don't believe this is physically destructive)

Chris Stratton
  • 33,282
  • 3
  • 43
  • 89
  • 2
    You can chain every flop together with an inverter in between and generate a lot of heat. Do any FPGAs have protection circuits to modulate the clock if they get too hot? The clock tree is often outside their control. – Ben Jackson Jun 26 '19 at 04:48
  • @BenJackson: Isn’t the clock tree more or less hard wired, with each Logic Element able to select among a few different trees? The clock source itself can be outside of their control, but they could simply turn off the clock tree buffers if it gets too hot. Or I guess they could turn off supply. – Michael Jun 26 '19 at 07:07
6

The most likely thing is violating the current rating on GPIO's by driving a pin that is already being driven. Some FPGA's have settable current limits or changeable output drivers, so this can either help/hurt you if you don't get your port map done right. You should be double checking your port list anyway before programming as mistakes like swapping pins can take hours to resolve, it's best to get ahead of the mistakes and know exactly what the firmware was intended to do. (unless you like the thrill of finding an error)

HDL's by themselves usually don't let you connect two output's to the same wire and will stop synthesizing and make you fix your mistake if you do have code that does that.

One place that could cause problems is bi-directional ports, but you should have current limiting resistors on those.

Voltage Spike
  • 75,799
  • 36
  • 80
  • 208
  • Re “_connect two output's to the same wire_”: Can't you connect the outputs of two three-state buffers together if you promise the synthesis tool to never enable both at the same time? Can the tool check you hold your promise even if the logic driving the “enable” of the buffers is very convoluted? – Edgar Bonet Jun 27 '19 at 08:02
  • @EdgarBonet yup you can cause conflicts this way. There is no requirement to logically force output enables to be mutually exclusive, if some logic (which could include statefull logic and/or hardware / software external to the FPGA) causes two conflicting OEs to come active, there is nothing to stop it unless the logic for the OEs has been explicitly coded to prevent that. – Rodney Jun 27 '19 at 16:00
  • @EdgarBonet You can, but typically threestate wires are external to the FPGA as you need a driver/transceiver and those are found on GPIO's. I've never designed with threestate in an FPGA and I don't think hardware in an FPGA supports three state. You can turn two buffers on at the same time, the physical design should prevent you from burning them up. – Voltage Spike Jun 27 '19 at 16:05
4

As with microcontrollers, you can always exceed the maximum total current per IO bank by drawing a maximum current (or more) from each pin. Unless the FPGA has built-in protection against such situation, this may result in damage.

Another possibility is making a combinatorial loop which either periodically goes meta-stable, or oscillates at a far higher frequency than the FPGA fabric is designed to handle (several GHz). That will cause a very localised overheating which may do physical damage before the chip-wide thermal protection kicks in. That is, assuming there is such a protection: if over-temperature doesn't lead to shutdown, you can simply come up with a very power-hungry circuit and let it run with insufficient cooling.

Dynamic reconfiguration can also work around protections against invalid configuration of internal primitives which may be enforced by the development tools in case of a static configuration. For example, you could configure a PLL in a way that exceeds its maximum internal frequency, or feed the same interconnect line by two sources at once, or force a pin from a high-voltage IO bank to use its low-voltage transceiver like LVDS.

Dmitry Grigoryev
  • 25,576
  • 5
  • 45
  • 106