Mfcttrf

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?

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.

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)

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.