SoylentNews is people
SoylentNews
Last week, I compared Tesla design to Apple. Since then, it has become widely known that Elon Musk tried to sell Tesla to Apple in 2013. This has created considerable interest in Apple's autonomous vehicle project and Apple's progress with lithium batteries. However, it has not created considerable interest in Jony Ive's possible work for Ferrari nor in the progress of power transistors. I wrote about gallium LEDs and transistors in Dec 2017 and, specifically, GaNFET (Gallium Nitride Field Effect Transistor). I thought that it would be a good idea to check progress. Well, holy cr*p.
On Mon 9 Nov 2020, a Texas Instruments press release announced power transistors which can switch 4kW (more than 600V, more than 6A) at 2.2MHz and, due to the 30mΩ resistance, do this with 99% efficiency. Indeed, cables may warm more than the 12mm×12mm transistors which require, at most, 40W heatsink. My calculations may be wrong but a homebrew, all wheel drive, six wheel vehicle, with 16 phase electric motors and these 4kW GaNFETs, can do a standing start quarter mile (400m) in less than 10 seconds. By 1980s standards, this is supercar performance. And from 2021 Q1, it is now possible to make this at home or a local makerspace.
The price for these transistors is US$8.34 each for the lowest grade and US$14.68 each for the highest grade if purchased in quantities of 1000 or more. If you don't have US$8340 or so, there is an evaluation module for US$199.
I'm not sure of Moore's law applies to individual transistors but this is now the upper bound for 4kW power transistors. Unfortunately, many of the problems which I previously identified remain. Gate leakage is mitigated with an integrated driver, although (my estimate) leak of 30-50mW is probably not a huge concern when switching 4kW. The major problem is that the technology is in transition and therefore it still uses silicon as a substrate. The mismatched atom size is a hinderance to the efficiency of gallium nitride transistors and LEDs. Expect at least double improvement when this moves to a gallium nitride substrate. Therefore, expect 10kW switching at 5MHz or more.
Switching this amount of energy under software control is extremely dangerous and may cause equipment to not just smoke but spontaneously explode. I strongly recommend safeguards, such as hardware interlocks, watchdog timeouts, disallowing field firmware upgrades and control protocols which fail in a safe manner.
As I've previously noted, in less demanding applications, such as quadcopters, it is desirable to remove a heatsink entirely. This leads to a moderate step change because a subset of designs no longer expend energy to keep a heatsink aloft. This provides an otherwise unmodified design with more range and more flight time. The advantage is also compounding if a design is made smaller.
Anyhow, autonomous supercars, quadcopters and spontaneous explosions. What could possibly go wrong?
(Score: 0) by Anonymous Coward on Thursday December 31 2020, @12:05PM
Here's a better idea: Ditch software control entirely in favour of hardware control: A dedicated state machine on an FPGA. Far safer. One FPGA for less than the cost of one of these transistors, will handle all the transistors in your fancy multiphase drive, and do so without randomly glitching up and causing explosions.
You should generally assume any OS-laden chip will be hacked at some point, so make sure that FPGA firmware updates are properly secured by requiring simple physical access to enable. (tech pushing a button, or closing a jumper etc).
Also assume that whatever that OS device is, it could give stupid/wrong commands, and instead your FPGA design should do something sane and safe - like maybe shut down safely and refuse all further commands until reset.
Always assume the inevitable hacker is most likely some script kiddie who likely wants to see how much smoke and fire will come out if all your transistors go closed circuit at once!
Nowadays you could put a whole dedicated soft-core running forth (j1) in your FPGA, to live alongside the for-purpose state machines and do things like handle communications and decide if higher command has gone insane or not - all lives in (some of) the SRAM, so adds no gliches, and needs no OS.
Your embedded system can then just talk to it over serial. Or you could put a 'slave' SPI on the FPGA, so the embedded system can *think* it's in control. But you can set things up so even ddos attempts at that interface won't interfere with proper switch sequencing (except to the extent of triggering a boring 'safe-mode' shut down).
But the actual sequencing of turning off your high/low side before waiting just the right number of 100's ns before turning on the other transistor in the 'totem pole': that should be hardware timed by dedicated timers, with the switching sequenced by dedicated state machines for each totem-pole leg, ideally all themselves controlled in turn by a higher order state machines. (for those that don't know, it's normal that transistors turn 'on' much faster than they turn 'off', so you can't just send an inverted copy of the signal to each transistor - you'll get shoot-thru, which will blow up your transistors fairly quickly).
But not by anything for which watchdog timeouts apply! (ie, don't use a microcontroller for these things - splurge a whole another $5 and get an FPGA.).
Nowadays microcontrollers only win if either the cheapest possible or lowest power possible is needed - which apply to exactly two solutions: cheapest is whatever 4c micro you can get from china is - and lowest power is still those crazy greenarrays chips.
Any and every other microcontroller ought to be just replaced with an SoC, and an SoC is not a microcontroller. By the time you have an SoC, you may as well just bite the bullet and run an embedded OS on it. Just *also* provide an FPGA to do the real work.
So, I'm sorry, but whatever uC ISA you memorized, it is now obsolete. Either you'll be running a full OS, and therefore will have a compiler and proper tool chain, or you'll be working in an FPGA (and can just use verilog or swapforth).
Just look out for the power-on pin behaviour for your FPGA: be aware that if you use button inputs, you should wire those as pull-up when pressed, not the traditional (for uC) pull down when pressed. When modern FPGA's configure, they configure so fast that pins programmed as pull up, will seem to have been 'pressed' down, because they'll still be low after configure! Also don't use active-low reset inputs for this reason, or at least, use a timer to 'disable' such active-low input pins for a few ms after boot!
You also need to be sure that configure-time doesn't give your power transistors weak pull-ups - which may turn your transistors 'half on' which could also destroy them! Generally running outputs through optocouplers is safe - they usually require a fairly decent current to pass a logic-high signal, and this is often enough to stop this problem, and as an added bonus, lets you properly isolate the deadly high voltage part of your circuit from the safe/low voltage part!