We have a board that tends to blow up.

It has a couple of isolated dc/dc converters, gate driver chips and
big mosfet full-bridges driving transformers. The gate drivers get
their inputs from an FPGA.

The probelm is that the +48 volts to the h-bridges comes up at power
turn-on, but the FPGA is configured some minutes later, after Linux
boots up. And I don't entirely trust the FPGA outputs meanwhile.
Possibly never.

After designing many complex fixes, a simple fix is to precharge the
module's +48 rail gently, and slam it on hard after everything is
verified stable.

https://www.dropbox.com/scl/fi/i7mgvnad9h1itxf8p0t76/P941_942_Precharge_1.jpg?rlkey=tv3rh3kzlw40th20oes6hlhr2&raw=1

The one-shot gets its I'M OK trigger from the FPGA, which can only
happen if the FPGA is working, I hope.

On Sun, 24 Mar 2024 12:14:57 -0700, John Larkin
<jjlarkin@highlandtechnology.com> wrote:

>
>We have a board that tends to blow up.
>
>It has a couple of isolated dc/dc converters, gate driver chips and
>big mosfet full-bridges driving transformers. The gate drivers get
>their inputs from an FPGA.
>
>The probelm is that the +48 volts to the h-bridges comes up at power
>turn-on, but the FPGA is configured some minutes later, after Linux
>boots up. And I don't entirely trust the FPGA outputs meanwhile.
>Possibly never.
>
>After designing many complex fixes, a simple fix is to precharge the
>module's +48 rail gently, and slam it on hard after everything is
>verified stable.
>
>
><https://www.dropbox.com/scl/fi/i7mgvnad9h1itxf8p0t76/P941_942_Precharge_1.jpg?rlkey=tv3rh3kzlw40th20oes6hlhr2&raw=1>
>
>
>The one-shot gets its I'M OK trigger from the FPGA, which can only
>happen if the FPGA is working, I hope.

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

Joe Gwinn

Joe Gwinn <joegwinn@comcast.net> wrote:
> On Sun, 24 Mar 2024 12:14:57 -0700, John Larkin
> <jjlarkin@highlandtechnology.com> wrote:
>
>>
>> We have a board that tends to blow up.
>>
>> It has a couple of isolated dc/dc converters, gate driver chips and
>> big mosfet full-bridges driving transformers. The gate drivers get
>> their inputs from an FPGA.
>>
>> The probelm is that the +48 volts to the h-bridges comes up at power
>> turn-on, but the FPGA is configured some minutes later, after Linux
>> boots up. And I don't entirely trust the FPGA outputs meanwhile.
>> Possibly never.
>>
>> After designing many complex fixes, a simple fix is to precharge the
>> module's +48 rail gently, and slam it on hard after everything is
>> verified stable.
>>
>>
>> <https://www.dropbox.com/scl/fi/i7mgvnad9h1itxf8p0t76/P941_942_Precharge_1.jpg?rlkey=tv3rh3kzlw40th20oes6hlhr2&raw=1>
>>
>>
>> The one-shot gets its I'M OK trigger from the FPGA, which can only
>> happen if the FPGA is working, I hope.
>
> 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

--
Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC /
Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics

On Sun, 24 Mar 2024 20:58:22 -0000 (UTC), Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

>Joe Gwinn <joegwinn@comcast.net> wrote:
>> On Sun, 24 Mar 2024 12:14:57 -0700, John Larkin
>> <jjlarkin@highlandtechnology.com> wrote:
>>
>>>
>>> We have a board that tends to blow up.
>>>
>>> It has a couple of isolated dc/dc converters, gate driver chips and
>>> big mosfet full-bridges driving transformers. The gate drivers get
>>> their inputs from an FPGA.
>>>
>>> The probelm is that the +48 volts to the h-bridges comes up at power
>>> turn-on, but the FPGA is configured some minutes later, after Linux
>>> boots up. And I don't entirely trust the FPGA outputs meanwhile.
>>> Possibly never.
>>>
>>> After designing many complex fixes, a simple fix is to precharge the
>>> module's +48 rail gently, and slam it on hard after everything is
>>> verified stable.
>>>
>>>
>>> <https://www.dropbox.com/scl/fi/i7mgvnad9h1itxf8p0t76/P941_942_Precharge_1.jpg?rlkey=tv3rh3kzlw40th20oes6hlhr2&raw=1>
>>>
>>>
>>> The one-shot gets its I'M OK trigger from the FPGA, which can only
>>> happen if the FPGA is working, I hope.
>>
>> 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.

On Sun, 24 Mar 2024 16:10:25 -0400, Joe Gwinn <joegwinn@comcast.net>
wrote:

>On Sun, 24 Mar 2024 12:14:57 -0700, John Larkin
><jjlarkin@highlandtechnology.com> wrote:
>
>>
>>We have a board that tends to blow up.
>>
>>It has a couple of isolated dc/dc converters, gate driver chips and
>>big mosfet full-bridges driving transformers. The gate drivers get
>>their inputs from an FPGA.
>>
>>The probelm is that the +48 volts to the h-bridges comes up at power
>>turn-on, but the FPGA is configured some minutes later, after Linux
>>boots up. And I don't entirely trust the FPGA outputs meanwhile.
>>Possibly never.
>>
>>After designing many complex fixes, a simple fix is to precharge the
>>module's +48 rail gently, and slam it on hard after everything is
>>verified stable.
>>
>>
>><https://www.dropbox.com/scl/fi/i7mgvnad9h1itxf8p0t76/P941_942_Precharge_1.jpg?rlkey=tv3rh3kzlw40th20oes6hlhr2&raw=1>
>>
>>
>>The one-shot gets its I'M OK trigger from the FPGA, which can only
>>happen if the FPGA is working, I hope.
>
>Can you require significant net charge transfer on a short period of
>time from the FPGA before the one-shot will trigger?
>
>Joe Gwinn

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!

On 25/03/2024 9:09 am, John Larkin wrote:
> On Sun, 24 Mar 2024 20:58:22 -0000 (UTC), Phil Hobbs
> <pcdhSpamMeSenseless@electrooptical.net> wrote:
>
>> Joe Gwinn <joegwinn@comcast.net> wrote:
>>> On Sun, 24 Mar 2024 12:14:57 -0700, John Larkin
>>> <jjlarkin@highlandtechnology.com> wrote:
>>>
>>>>
>>>> We have a board that tends to blow up.
>>>>
>>>> It has a couple of isolated dc/dc converters, gate driver chips and
>>>> big mosfet full-bridges driving transformers. The gate drivers get
>>>> their inputs from an FPGA.
>>>>
>>>> The probelm is that the +48 volts to the h-bridges comes up at power
>>>> turn-on, but the FPGA is configured some minutes later, after Linux
>>>> boots up. And I don't entirely trust the FPGA outputs meanwhile.
>>>> Possibly never.
>>>>
>>>> After designing many complex fixes, a simple fix is to precharge the
>>>> module's +48 rail gently, and slam it on hard after everything is
>>>> verified stable.
>>>>
>>>>
>>>> <https://www.dropbox.com/scl/fi/i7mgvnad9h1itxf8p0t76/P941_942_Precharge_1.jpg?rlkey=tv3rh3kzlw40th20oes6hlhr2&raw=1>
>>>>
>>>>
>>>> The one-shot gets its I'M OK trigger from the FPGA, which can only
>>>> happen if the FPGA is working, I hope.
>>>
>>> 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.
>
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!

On Tue, 26 Mar 2024 11:14:01 +1100, Chris Jones
<lugnut808@spam.yahoo.com> wrote:

>On 25/03/2024 9:09 am, John Larkin wrote:
>> On Sun, 24 Mar 2024 20:58:22 -0000 (UTC), Phil Hobbs
>> <pcdhSpamMeSenseless@electrooptical.net> wrote:
>>
>>> Joe Gwinn <joegwinn@comcast.net> wrote:
>>>> On Sun, 24 Mar 2024 12:14:57 -0700, John Larkin
>>>> <jjlarkin@highlandtechnology.com> wrote:
>>>>
>>>>>
>>>>> We have a board that tends to blow up.
>>>>>
>>>>> It has a couple of isolated dc/dc converters, gate driver chips and
>>>>> big mosfet full-bridges driving transformers. The gate drivers get
>>>>> their inputs from an FPGA.
>>>>>
>>>>> The probelm is that the +48 volts to the h-bridges comes up at power
>>>>> turn-on, but the FPGA is configured some minutes later, after Linux
>>>>> boots up. And I don't entirely trust the FPGA outputs meanwhile.
>>>>> Possibly never.
>>>>>
>>>>> After designing many complex fixes, a simple fix is to precharge the
>>>>> module's +48 rail gently, and slam it on hard after everything is
>>>>> verified stable.
>>>>>
>>>>>
>>>>> <https://www.dropbox.com/scl/fi/i7mgvnad9h1itxf8p0t76/P941_942_Precharge_1.jpg?rlkey=tv3rh3kzlw40th20oes6hlhr2&raw=1>
>>>>>
>>>>>
>>>>> The one-shot gets its I'M OK trigger from the FPGA, which can only
>>>>> happen if the FPGA is working, I hope.
>>>>
>>>> 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.
>>
>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.

On 24-03-2024 23:16, John Larkin wrote:
> On Sun, 24 Mar 2024 16:10:25 -0400, Joe Gwinn <joegwinn@comcast.net>
> wrote:
>
>> On Sun, 24 Mar 2024 12:14:57 -0700, John Larkin
>> <jjlarkin@highlandtechnology.com> wrote:
>>
>>>
>>> We have a board that tends to blow up.
>>>
>>> It has a couple of isolated dc/dc converters, gate driver chips and
>>> big mosfet full-bridges driving transformers. The gate drivers get
>>> their inputs from an FPGA.
>>>
>>> The probelm is that the +48 volts to the h-bridges comes up at power
>>> turn-on, but the FPGA is configured some minutes later, after Linux
>>> boots up. And I don't entirely trust the FPGA outputs meanwhile.
>>> Possibly never.
>>>
>>> After designing many complex fixes, a simple fix is to precharge the
>>> module's +48 rail gently, and slam it on hard after everything is
>>> verified stable.
>>>
>>>
>>> <https://www.dropbox.com/scl/fi/i7mgvnad9h1itxf8p0t76/P941_942_Precharge_1.jpg?rlkey=tv3rh3kzlw40th20oes6hlhr2&raw=1>
>>>
>>>
>>> The one-shot gets its I'M OK trigger from the FPGA, which can only
>>> happen if the FPGA is working, I hope.
>>
>> Can you require significant net charge transfer on a short period of
>> time from the FPGA before the one-shot will trigger?
>>
>> Joe Gwinn
>
> 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!
>
>
>
>
>

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

On Fri, 29 Mar 2024 11:54:02 +0100, Klaus Vestergaard Kragelund
<klauskvik@hotmail.com> wrote:

>On 24-03-2024 23:16, John Larkin wrote:
>> On Sun, 24 Mar 2024 16:10:25 -0400, Joe Gwinn <joegwinn@comcast.net>
>> wrote:
>>
>>> On Sun, 24 Mar 2024 12:14:57 -0700, John Larkin
>>> <jjlarkin@highlandtechnology.com> wrote:
>>>
>>>>
>>>> We have a board that tends to blow up.
>>>>
>>>> It has a couple of isolated dc/dc converters, gate driver chips and
>>>> big mosfet full-bridges driving transformers. The gate drivers get
>>>> their inputs from an FPGA.
>>>>
>>>> The probelm is that the +48 volts to the h-bridges comes up at power
>>>> turn-on, but the FPGA is configured some minutes later, after Linux
>>>> boots up. And I don't entirely trust the FPGA outputs meanwhile.
>>>> Possibly never.
>>>>
>>>> After designing many complex fixes, a simple fix is to precharge the
>>>> module's +48 rail gently, and slam it on hard after everything is
>>>> verified stable.
>>>>
>>>>
>>>> <https://www.dropbox.com/scl/fi/i7mgvnad9h1itxf8p0t76/P941_942_Precharge_1.jpg?rlkey=tv3rh3kzlw40th20oes6hlhr2&raw=1>
>>>>
>>>>
>>>> The one-shot gets its I'M OK trigger from the FPGA, which can only
>>>> happen if the FPGA is working, I hope.
>>>
>>> Can you require significant net charge transfer on a short period of
>>> time from the FPGA before the one-shot will trigger?
>>>
>>> Joe Gwinn
>>
>> 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!
>>
>>
>>
>>
>>
>
>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

We have blown up fets and drivers on this product, which is
embarassing, so we're doing everything reasonable to stop that.

We have been using LTC4444 gate drivers, which are one possible
villain. We're switching to the UCC27712 next rev. But it sure sounds
prudent to apply +48 to the bridges last thing in the startup
sequence, as opposed to a kilowatt of +48 first thing at powerup...
before even the logic supplies are up. About 15 important things
happen between powerup an steady-state operation, and there could be
lots of gotchas lurking.

I've thought about really high-power electronics, like the ends of a
megavolt DC transmission line. That's scary. Failures must be
spectaular. And expensive.

I prefer products that won't break your foot if you drop one.

On 29-03-2024 15:33, John Larkin wrote:
> On Fri, 29 Mar 2024 11:54:02 +0100, Klaus Vestergaard Kragelund
> <klauskvik@hotmail.com> wrote:
>
>> On 24-03-2024 23:16, John Larkin wrote:
>>> On Sun, 24 Mar 2024 16:10:25 -0400, Joe Gwinn <joegwinn@comcast.net>
>>> wrote:
>>>
>>>> On Sun, 24 Mar 2024 12:14:57 -0700, John Larkin
>>>> <jjlarkin@highlandtechnology.com> wrote:
>>>>
>>>>>
>>>>> We have a board that tends to blow up.
>>>>>
>>>>> It has a couple of isolated dc/dc converters, gate driver chips and
>>>>> big mosfet full-bridges driving transformers. The gate drivers get
>>>>> their inputs from an FPGA.
>>>>>
>>>>> The probelm is that the +48 volts to the h-bridges comes up at power
>>>>> turn-on, but the FPGA is configured some minutes later, after Linux
>>>>> boots up. And I don't entirely trust the FPGA outputs meanwhile.
>>>>> Possibly never.
>>>>>
>>>>> After designing many complex fixes, a simple fix is to precharge the
>>>>> module's +48 rail gently, and slam it on hard after everything is
>>>>> verified stable.
>>>>>
>>>>>
>>>>> <https://www.dropbox.com/scl/fi/i7mgvnad9h1itxf8p0t76/P941_942_Precharge_1.jpg?rlkey=tv3rh3kzlw40th20oes6hlhr2&raw=1>
>>>>>
>>>>>
>>>>> The one-shot gets its I'M OK trigger from the FPGA, which can only
>>>>> happen if the FPGA is working, I hope.
>>>>
>>>> Can you require significant net charge transfer on a short period of
>>>> time from the FPGA before the one-shot will trigger?
>>>>
>>>> Joe Gwinn
>>>
>>> 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!
>>>
>>>
>>>
>>>
>>>
>>
>> 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
>
> We have blown up fets and drivers on this product, which is
> embarassing, so we're doing everything reasonable to stop that.
>
> We have been using LTC4444 gate drivers, which are one possible
> villain. We're switching to the UCC27712 next rev. But it sure sounds
> prudent to apply +48 to the bridges last thing in the startup
> sequence, as opposed to a kilowatt of +48 first thing at powerup...
> before even the logic supplies are up. About 15 important things
> happen between powerup an steady-state operation, and there could be
> lots of gotchas lurking.
>
> I've thought about really high-power electronics, like the ends of a
> megavolt DC transmission line. That's scary. Failures must be
> spectaular. And expensive.
>
> I prefer products that won't break your foot if you drop one.
>
This app note from Lattice describes the state of the pins during startup:

https://www.latticesemi.com/~/media/8DFD1009E98E42C9B53C4BADE6D8B3E5.ashx

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 :-)

On Fri, 29 Mar 2024 21:31:21 +0100, Klaus Vestergaard Kragelund
<klauskvik@hotmail.com> wrote:

>On 29-03-2024 15:33, John Larkin wrote:
>> On Fri, 29 Mar 2024 11:54:02 +0100, Klaus Vestergaard Kragelund
>> <klauskvik@hotmail.com> wrote:
>>
>>> On 24-03-2024 23:16, John Larkin wrote:
>>>> On Sun, 24 Mar 2024 16:10:25 -0400, Joe Gwinn <joegwinn@comcast.net>
>>>> wrote:
>>>>
>>>>> On Sun, 24 Mar 2024 12:14:57 -0700, John Larkin
>>>>> <jjlarkin@highlandtechnology.com> wrote:
>>>>>
>>>>>>
>>>>>> We have a board that tends to blow up.
>>>>>>
>>>>>> It has a couple of isolated dc/dc converters, gate driver chips and
>>>>>> big mosfet full-bridges driving transformers. The gate drivers get
>>>>>> their inputs from an FPGA.
>>>>>>
>>>>>> The probelm is that the +48 volts to the h-bridges comes up at power
>>>>>> turn-on, but the FPGA is configured some minutes later, after Linux
>>>>>> boots up. And I don't entirely trust the FPGA outputs meanwhile.
>>>>>> Possibly never.
>>>>>>
>>>>>> After designing many complex fixes, a simple fix is to precharge the
>>>>>> module's +48 rail gently, and slam it on hard after everything is
>>>>>> verified stable.
>>>>>>
>>>>>>
>>>>>> <https://www.dropbox.com/scl/fi/i7mgvnad9h1itxf8p0t76/P941_942_Precharge_1.jpg?rlkey=tv3rh3kzlw40th20oes6hlhr2&raw=1>
>>>>>>
>>>>>>
>>>>>> The one-shot gets its I'M OK trigger from the FPGA, which can only
>>>>>> happen if the FPGA is working, I hope.
>>>>>
>>>>> Can you require significant net charge transfer on a short period of
>>>>> time from the FPGA before the one-shot will trigger?
>>>>>
>>>>> Joe Gwinn
>>>>
>>>> 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!
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> 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
>>
>> We have blown up fets and drivers on this product, which is
>> embarassing, so we're doing everything reasonable to stop that.
>>
>> We have been using LTC4444 gate drivers, which are one possible
>> villain. We're switching to the UCC27712 next rev. But it sure sounds
>> prudent to apply +48 to the bridges last thing in the startup
>> sequence, as opposed to a kilowatt of +48 first thing at powerup...
>> before even the logic supplies are up. About 15 important things
>> happen between powerup an steady-state operation, and there could be
>> lots of gotchas lurking.
>>
>> I've thought about really high-power electronics, like the ends of a
>> megavolt DC transmission line. That's scary. Failures must be
>> spectaular. And expensive.
>>
>> I prefer products that won't break your foot if you drop one.
>>
>This app note from Lattice describes the state of the pins during startup:
>
>https://www.latticesemi.com/~/media/8DFD1009E98E42C9B53C4BADE6D8B3E5.ashx
>
>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 :-)

My FPGA folks say that we can't entirely trust the Efinix chip states.
With +48 up first, the FPGA is driving the fets before and during
config. Yikes.

Both the LTC and the TI gate divers claim to avoid fet-ON overlap no
matter what the inputs are, but the LTC sounds scarier.

On 30-03-2024 01:47, John Larkin wrote:
> On Fri, 29 Mar 2024 21:31:21 +0100, Klaus Vestergaard Kragelund
> <klauskvik@hotmail.com> wrote:
>
>> On 29-03-2024 15:33, John Larkin wrote:
>>> On Fri, 29 Mar 2024 11:54:02 +0100, Klaus Vestergaard Kragelund
>>> <klauskvik@hotmail.com> wrote:
>>>
>>>> On 24-03-2024 23:16, John Larkin wrote:
>>>>> On Sun, 24 Mar 2024 16:10:25 -0400, Joe Gwinn <joegwinn@comcast.net>
>>>>> wrote:
>>>>>
>>>>>> On Sun, 24 Mar 2024 12:14:57 -0700, John Larkin
>>>>>> <jjlarkin@highlandtechnology.com> wrote:
>>>>>>
>>>>>>>
>>>>>>> We have a board that tends to blow up.
>>>>>>>
>>>>>>> It has a couple of isolated dc/dc converters, gate driver chips and
>>>>>>> big mosfet full-bridges driving transformers. The gate drivers get
>>>>>>> their inputs from an FPGA.
>>>>>>>
>>>>>>> The probelm is that the +48 volts to the h-bridges comes up at power
>>>>>>> turn-on, but the FPGA is configured some minutes later, after Linux
>>>>>>> boots up. And I don't entirely trust the FPGA outputs meanwhile.
>>>>>>> Possibly never.
>>>>>>>
>>>>>>> After designing many complex fixes, a simple fix is to precharge the
>>>>>>> module's +48 rail gently, and slam it on hard after everything is
>>>>>>> verified stable.
>>>>>>>
>>>>>>>
>>>>>>> <https://www.dropbox.com/scl/fi/i7mgvnad9h1itxf8p0t76/P941_942_Precharge_1.jpg?rlkey=tv3rh3kzlw40th20oes6hlhr2&raw=1>
>>>>>>>
>>>>>>>
>>>>>>> The one-shot gets its I'M OK trigger from the FPGA, which can only
>>>>>>> happen if the FPGA is working, I hope.
>>>>>>
>>>>>> Can you require significant net charge transfer on a short period of
>>>>>> time from the FPGA before the one-shot will trigger?
>>>>>>
>>>>>> Joe Gwinn
>>>>>
>>>>> 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!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> 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
>>>
>>> We have blown up fets and drivers on this product, which is
>>> embarassing, so we're doing everything reasonable to stop that.
>>>
>>> We have been using LTC4444 gate drivers, which are one possible
>>> villain. We're switching to the UCC27712 next rev. But it sure sounds
>>> prudent to apply +48 to the bridges last thing in the startup
>>> sequence, as opposed to a kilowatt of +48 first thing at powerup...
>>> before even the logic supplies are up. About 15 important things
>>> happen between powerup an steady-state operation, and there could be
>>> lots of gotchas lurking.
>>>
>>> I've thought about really high-power electronics, like the ends of a
>>> megavolt DC transmission line. That's scary. Failures must be
>>> spectaular. And expensive.
>>>
>>> I prefer products that won't break your foot if you drop one.
>>>
>> This app note from Lattice describes the state of the pins during startup:
>>
>> https://www.latticesemi.com/~/media/8DFD1009E98E42C9B53C4BADE6D8B3E5.ashx
>>
>> 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 :-)
>
> My FPGA folks say that we can't entirely trust the Efinix chip states.
> With +48 up first, the FPGA is driving the fets before and during
> config. Yikes.
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.