26
\$\begingroup\$

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?

\$\endgroup\$
  • 3
    \$\begingroup\$ 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. \$\endgroup\$ – filo Jun 26 at 6:33
  • 2
    \$\begingroup\$ "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. \$\endgroup\$ – UKMonkey Jun 26 at 9:38
  • 1
    \$\begingroup\$ @JoL related :) retrocomputing.stackexchange.com/questions/6614/… \$\endgroup\$ – UKMonkey Jun 26 at 15:34
  • 2
    \$\begingroup\$ @UKMonkey youtube.com/watch?v=CsQd2n99zS4 \$\endgroup\$ – Joshua Jun 26 at 17:42
  • 2
    \$\begingroup\$ @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. \$\endgroup\$ – Nic Hartley Jun 26 at 19:42
31
\$\begingroup\$

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.

\$\endgroup\$
  • 1
    \$\begingroup\$ 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!) \$\endgroup\$ – MathematicalOrchid Jun 25 at 18:44
  • 4
    \$\begingroup\$ @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. \$\endgroup\$ – The Photon Jun 25 at 18:46
  • 3
    \$\begingroup\$ @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. \$\endgroup\$ – Harry Svensson Jun 26 at 6:25
  • \$\begingroup\$ @HarrySvensson That seems like a crazy amount of heat for a frequency counter. \$\endgroup\$ – immibis Jun 26 at 22:17
  • 1
    \$\begingroup\$ @HarrySvensson It's still crazy that that should take 5 watts. \$\endgroup\$ – immibis Jun 26 at 22:59
20
\$\begingroup\$

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)

\$\endgroup\$
  • 2
    \$\begingroup\$ 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. \$\endgroup\$ – Ben Jackson Jun 26 at 4:48
  • \$\begingroup\$ @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. \$\endgroup\$ – Michael Jun 26 at 7:07
5
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ 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? \$\endgroup\$ – Edgar Bonet Jun 27 at 8:02
  • \$\begingroup\$ @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. \$\endgroup\$ – Rodney Jun 27 at 16:00
  • \$\begingroup\$ @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. \$\endgroup\$ – Voltage Spike Jun 27 at 16:05
4
\$\begingroup\$

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.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.