+48 precharge

Can you require significant net charge transfer on a short period of time from the FPGA before the one-shot will trigger?

Joe Gwinn

There are any number of ways to reject FPGA zombie behavior. The retriggerable one-shot is pretty simple.

Another fairly simple one would be making the processor wait to receive a specific message from the FPGA, e.g. “Tranquility Base here. The Eagle has landed.”

Cheers

Phil Hobbs

The Efinix FPGAs are primitive, which is usually good, but their i/o's can do tricky things.

I want a tiny SPI-interfaced chip that outputs a 1 when the proper

32-bit code is entered. Or 256.

The retriggerable one-shot is 1 microsecond, and the FPGA (once it's alive and well) will clock it at 2 MHz. No clock, no hard +48.

We'll have seconds available to charge the filter caps, before we make the I'M_OK signal to enable stuff. It a Linux system!

You could at least requre a few logic outputs from the FPGA to have different specific states (you could even have it drive relays with the NO or NC contacts in series!), or feed the logic output from the FPGA into a LC filter so that it has to toggle at a specific frequency to turn on the MOSFET, or make the output of the FPGA drive a Cockcroft-Walton multiplier that has to overcome the breakdown voltage of a 5V zener to turn on the MOSFET so that you at least know it is toggling. At the very least put a pulldown resistor so the mosfet's gate can't float high!

A frequency-selective circuit could require one FPGA pin to output some specific frequency. 5 little parts maybe.

My FPGA kids have suggested that a simple pullup or pulldown on one FPGA pin may not be 100% reliable as an indication that the FPGA is configured and operating correctly. Or at least they are blaming some failures on that.

I note that when something fails in the field, some people blame the customer first, then shipping damage, then bad solder joints or bad parts, anything but a possible design mistake.

The FPGA will have a defined state during startup, and your gatedrivers have UVLO, so during boot the FPGAs are defined as high-z, and you use a pull-down resistor to pull the outputs low during boot. Normally you would use a delay for the VDD for the gatedrivers, so both ramping VCC and controlled VDD start makes sure there are no conflict.

I am currently working on a 3MW converter. We are controlling it directly from a FPGA, like described above.

When I worked at Vestas doing 6MW wind turbine, we did it the same way.

Cheers

Klaus

This app note from Lattice describes the state of the pins during startup:

It exits UVLO at 2.5V, so you just need to have the UVLO of the gatedriver to be higher than that.

But, yes, your idea to apply the 48V last is a good idea. In a turbine that is really not an option.

The scary stuff about 1000V/2000A is that an error occurs, busbar can spray molten copper in all directions, and your literally toast. Safety is really important on high power stuff.

UCC27712 is a good choice, the Texas/Unitrode guys knows how to make good gatedrivers :-)

That sounds really worrying.

One of the major reasons for selecting a FPGA in a power design is that it behaves close to a HW solution, no funny hickups as with a microcontroller.