I read somewhere that bad VHDL code can lead to FPGA damage.
Is it even possible to damage a FPGA with VHDL code? What kind of conditions would cause this and what are the worst case scenarios?
\$\begingroup\$
\$\endgroup\$
4
-
2\$\begingroup\$ The only scenario I could think of is of a design where many, many FFs are clocked so to heat the FPGA. \$\endgroup\$– Claudio Avi ChamiCommented Mar 21, 2017 at 19:52
-
\$\begingroup\$ Well, it can be incorporated in a poorly designed circuit, which will run some currents around burning stuff if not programmed properly. \$\endgroup\$– Eugene Sh.Commented Mar 21, 2017 at 19:55
-
3\$\begingroup\$ worst case scenario probably is that the fpga is used for machine learning and creates a rogue AI that destroys the world and universe. more seriously, if you are using unchecked code in an fpga connected to computer, it may infect said computer. also if it's used to control high power devices, you can burn a building. \$\endgroup\$– satibelCommented Mar 22, 2017 at 9:03
-
\$\begingroup\$ @satibel: teamten.com/lawrence/writings/coding-machines \$\endgroup\$– i336_Commented Mar 23, 2017 at 3:01
Add a comment
|
4 Answers
\$\begingroup\$
\$\endgroup\$
3
Adding to @Anonymous's answer, there are designs you can build which can damage the fabric of an FPGA.
For starters if you build a very large design consisting of huge quantities of registers (e.g. 70% of the FPGA) all clocked at nearing the FPGAs maximum frequency, it is possible to heat the silicon considerably. Without sufficient cooling this can cause physical damage. We lost a $13k FPGA because it overheated due to the dev-kit having a terrible cooling system.
Another simpler case can be combinational loops. For example if you instantiate three not gates chained together in a ring, and disable or ignore the synthesizers warnings about such a structure, you can form something which is very bad for an FPGA. In this example you'd make a multi-GHz oscillator which could produce a lot of heat in a very small area, probably damaging the ALM and surrounding logic.
answered Mar 21, 2017 at 20:14
-
2\$\begingroup\$ Combinatorial loops are sometimes suggested as true-random-number-generators. I have no experience with ring oscillators, but I doubt only three gates will do any harm. Driving its output to many gates will probably do harm though. \$\endgroup\$– AndreasCommented Mar 21, 2017 at 21:05
-
8\$\begingroup\$ thx I have 2-3 boards now useless because of design mistakes with spartan 6 on them. I will give this a try :P \$\endgroup\$– ESDCommented Mar 21, 2017 at 23:25
-
1\$\begingroup\$ It is also possible to load a bitstream that prevents loading other bitstreams, or at least makes it quite difficult to do. \$\endgroup\$ Commented Mar 22, 2017 at 8:34
\$\begingroup\$
\$\endgroup\$
4
Code is not a right word in this context. While Verilog or VHDL look like program, the output of the compiler is a configuration which is loaded into the FPGA chip forming electronic circuit within it.
Two types come to my mind:
- physical damage: for example, several FPGA pins are connected together (or to another device) and start outputting different logical voltage at the same time. Current flows - might be excessive current - which eventually damages the gate(s);
- logical damage: circuit may handle flash chip, or configuration device improperly, and corrupt data image in it, this whole device eventually malfunctions.
-
5\$\begingroup\$ The topic of physical damage might be where the OP's quote came from. As a software developer, I've been told a general rule is that "software" should not be able to do physical harm to the device while "firmware" can cause damage, such as connecting two divers to each other. \$\endgroup\$ Commented Mar 21, 2017 at 20:48
-
3\$\begingroup\$ @CortAmmon "such as connecting two divers to each other" - What is this, an air-hose cross-connect switch? \$\endgroup\$ Commented Mar 22, 2017 at 0:43
-
3\$\begingroup\$ @immibis You got me! The actual rule was "do not rely on the software/squishyware in your buddy's head while buddy breathing, instead always have a firm grasp on your regulator." ;-) \$\endgroup\$ Commented Mar 22, 2017 at 0:56
-
\$\begingroup\$ @CortAmmon interest only. As a rather special case, decades ago I saw someone hand key in code to a pc and set a simple program running that wrote successive screens of white and black to the monitor in a manner which made the monitor electronics "complain" loudly at the load. Whether this was power supply or line oscillator misoperation or ??? I know not. I got the impression that the monitor would have been destroyed if this had been left running. Whether it was BASIC or machine language or ??? and how I also do not know. Maybe 1970s-1980s range. \$\endgroup\$– Russell McMahon ♦Commented Mar 1, 2022 at 7:53
\$\begingroup\$
\$\endgroup\$
3
Misconfiguring a block of input pins as outputs might do it if whatever else is driving them is stiff enough.
I don't know if configuring some pins for LVDS or one of the LVCMOS standards while the IO bank is powered from an overly high voltage (3.3V power with a 1.8V IO standard for example, or the opposite on an input) would do it?
Obviously thermal problems may be a possibility by doing something silly like instantiating many, many, ring oscillators.
-
\$\begingroup\$ The I/O standard given as constraints to the design is just for timing calculations. If the I/O bank is a 3.3 V bank and powered by 3.3V nothing happens if you chose a 1.8 V standard. \$\endgroup\$– PaebbelsCommented Apr 1, 2017 at 1:44
-
\$\begingroup\$ @Paebbels, not sure which tool you're using but usually when you set an I/O standard it controls the voltage of that I/O location. If an FPGA input pin is set to a much lower voltage than what the external device is driving into that pin, that FPGA input can be damaged. \$\endgroup\$– CianoCommented May 25, 2017 at 11:59
-
\$\begingroup\$ @Ciano that not correct. The pin voltage depends on the I/O bank voltage not on a constraint. \$\endgroup\$– PaebbelsCommented May 25, 2017 at 23:41
\$\begingroup\$
\$\endgroup\$
FPGAs can be reconfigured at runtime with a new (partial) bitstream. Normally, this stream is loaded from an external source, but you can also create it by your self in the FPGA (e.g. by an embedded softcore CPU). Using such a solution for e.g. dynamically relocating subdesigns, doesn't provide all the consistency checks as done by the vendor tools. So if your algorithm is broken, you might enable the false path transistors in an FPGA and burn them.
You could also chose false operations modes for FPGA primitives like PLLs or transceivers.
Dynamic reconfiguration is like self modifying code in software.
