"frying" FPGAs

A bit of olive oil in a frying pan at high heat should do it. They are delicious, especially with Lattice!

Clyde Torres

Let me guess - are these Digilent 2SB boards, with the Spartan2E 200K FPGA? I work in a university also, and those are the boards that we got as a donation. 3 out of 5 are down, with the same symptoms... -Vadim

(snip)

As far as I know, the tools are supposed to generate files that don't do things that would internally fry the chip. In the days of tristate internal buses, I don't think they could stop you from turning on two drivers to the same bus line, but as I understand it that problem is gone. As far as contention on output buffers, it might be that you can burn out the output transistor.

If you manage to load random bits with a legal CRC, I suspect you could have some very strange effects.

-- glen

I got my Spartan 3s mighty toasty by outputing to a tristate data bus at the wrong time. This could happen if you have a memory device on the board. The Spatan 3s survived.

Hmm,

My first thought is that they are suffering from electrostatic discharge (ESD) damage, or perhaps problems with connecting the power supply such that the voltage regulator is getting damaged. Could be a series of bad bitstreams loaded, but I don't find that to be high on the likely candidate list. What do these boards have for a power supply? Is it possible the polarity is getting reversed? Is the on-board regulator sufficient for the designs the students are putting in to the FPGA? Are the boards being used in an environment where there is no ESD mitigation in place?

Another possibility is that the computer on the other end of the JTAG cable is not on the same ground system as the board. Both should be plugged into a common outlet to avoid possible problems. I recall an instance in a lab where I once worked where connecting an oscilloscope that was plugged in across the aisle to a board killed the board. Turned out there was a ground problem and the grounds on the two adjacent benches had a several hundred volt difference between them!!

--

--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.

"They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759

The classic way to toast any chip is contention on a tri-state bus. The stronger chip wins and the other chip tries real hard. The short-circuit current at the IO voltage turns into heat in the pad driver. (Old data sheets used to have a only-one-at-a-time warning on measuring the short curcuit current.)

The short circuit current on modern chips is pretty hefty. Multiply by 16 or 32 and you can get a lot of heat.

I've burned my thumb on an FPGA and cracked the case on a 16 bit bus driver. (Makes locating the bad chip simple.)

You can also turn a FPGA into a toaster by just toggling a lot of FFs at high speed. Play with one of the power estimator tools to get some numbers.

You can also make a chip very unhappy if you can get it to latch up. The usual way to do that is to inject too much current into a protection diode. What happens depends upon your power supply. If you have a big/beefy power supply, then your chip draws lots of power and gets real hot. It can turn to mush in a fraction of a second. If your power supply is just-right, it will shut down because of too much current. If it does that fast enough, your chip will recover.

My guess would be that your problem is caused by ESD. Maybe ESD triggering latchup.

They might be going into a 'latch-up' state. This can happen with CMOS, although manufacturers do a lot to prevent it happening. The Inmos transputer was prone to it if one touched the top of the package whilst it was running. The package lid wasn't grounded and a static charge on it could induce latch-up. They always recovered if they were switched off soon enough. With your systems it might be caused by connecting the JTAG with the unit powered up.

Leon

Hal Murray wrote: : >So here's my question: How do you fry an FPGA?? I guess running like : >50 volts through it would do the job, but I don't think the cause of : >these failures is a malicious user. Is there anyway to "accidentally" : >synthesize a design that causes an FPGA to destroy itself???

: The classic way to toast any chip is contention on a tri-state : bus. The stronger chip wins and the other chip tries real hard. : The short-circuit current at the IO voltage turns into heat in : the pad driver. (Old data sheets used to have a only-one-at-a-time : warning on measuring the short curcuit current.)

Using UCF to set the buffers to a weak drive strength might help in that situation ( people learning how to programm FPGA, not doing really timing dependant work...)

Also using a weaker regulator mmight be another option...

Bye

Do you have a signal generator or something like that attached into the board somewhere? Check what's its maximum voltage. We have here one which can generate voltage enough to fry DSP boards.

Hi, One of the boards I use expects a 3.3 regulated voltage. Unfortunately the plug for the board is also compatible with my laptop (~ 12V). I have killed one board this way.

In the lab we avoid this by connecting the board and the power cube before connecting the power cube to the power strip.

For all of our labs, we provide the UCF file for the project.

The boards cost about the same price of a text book. Perhaps the students should own the board.

Cheers, Jim

With my first attempt at VHDL about ten years ago, I inadvertantly instantiated two logic blocks to try to drive the same pin. I cooked two chips before finding the contention.

This, however, was with a very rudimentary VHDL compiler with very little sanity checking.

Keith

One way to blow up a device is to try to download a bitstream that is targeted to a different device, like loading a 2s50 bitstream into a

Not that likely in a strict design environment, but I could see it happening quite often in a classroom setting. Notice this is no longer an issue for Virtex-II(Spartan-3) and later devices.

HTH,

Mike

Mike,

Can the same thing happen if I use the correct device, but the device does not successfully program? I have a particularly high programming failure rate with XST 6.2.02i. The parallel port programming cable is thin and it is right next to the power cord on the laptop, so there may be some noise issues.

Regards, Jim

If the design downloaded is doing the nasty thing:

May be adding a simple fuse on the power (vcc) supply to the board could save the FPGA. I hope it is logical to assume that the power consumption increases heavily when the FPGA is ready to give up.

Also trying a power supply with current limitting circuitry could prevent it from burning.

One has to be careful about the jtag programming side though. Connecting diode protection to the supply line from the jtag may be necessary - if the protection of the FPGA is insufficient.

Any thoughts ?

Jim,

The configuration logic is such that the device only starts up if all the data is loaded correctly. In the case I mentioned, all the data is loaded correctly, the CRC check at the end of configuration is succesful, and the device starts up, meaning internal nodes are released from 3-state.

When you mistakenly load a bitstream targeted to another device for the architectures I mentioned before, the device will start up, but the mistargeted configuration could set internal nodes into a contention state, possibly destroying the device. In your case, if the device is properly targeted, only the correct data will enable the device to start up (otherwise the CRC will fail), which means no damage will occur. You will see evidence of a failed configuration with DONE being low and INIT being low as well.

HTH,

Mike

Jim Lewis wrote:

Yes!! They are D2SBs!! Okay, this is too much of a coincidence, any idea why THESE SPECIFIC boards are breaking all the time?

work in a university also, and those are the boards that we got as a donation. 3 out of 5 are down, with the same symptoms... -Vadim