# Need a Power Fairy? You Need Coordinated Electrical and Thermal Design!

Created on Mar 16, 2018 | 2:26 pm | Last Updated 1 year 2 months ago

A colleague of mine, a thermal design engineer, once made a comment that I’ll never forget. I was simulating a power electronics circuit and I placed a scope probe on a transistor model and plotted the power dissipation. Its value was of course changing over time, as the circuit’s operating state was varied during the simulated test scenario. He exclaimed: “You have a Power Fairy!”

He explained that in a typical thermal design process, he is handed some static values for the components’ power dissipation levels, and his job is come up with thermal mitigation strategies to keep them cool. The static data is usually worst case values for the parts, so he knows how to size the individual heat sinks for each of them, assuming some “ambient” temperature. But the circuit has many parts, and they all contribute heat to the enclosure or shared thermal environment. So should he assume that all the parts operate at full power simultaneously? Or guess at a “typical” distribution? He needed a Power Fairy, to give him power vs. time profiles, and SystemVision offered that!

But as you can see in the circuit above, we went a step further. We produced power electronics device models that compute their instantaneous power and provide it in the form of heat-flow output that can be connected to an external thermal network. That network can include not only the part’s local heat flow resistance and capacitance, but also the interconnection to all the other parts of the circuit, so their dynamic interaction can be simulated.

This example shows an AC LED lighting circuit with analog dimming. It is a "Live, Tunable" design, which means the user can modify the design parameters highlighted in blue (you may need to zoom in to see them). Then simply re-run the simulation by pressing the big green “play” button, and see the resulting performance changes in the waveforms.

The upper part of the schematic (with black "wires") shows the electrical aspects of the circuit. This includes the AC input with transformer voltage step-down, a full-wave diode bridge rectifier, and an adjustable linear regulator with a variable feedback resistor to provide a voltage proportional to the LED string current. Because the regulator current capability is too low to drive the LEDs at full brightness, a PNP bypass transistor is used to supply part of this load current.

The lower part of the schematic (with red "wires") shows the thermal aspects of the design. For the specific electronic devices, including the transistor, regulator and LEDs, the manufacture's datasheet provided not only the electrical characteristics for that part number, but also the junction-to-case "_jc_" thermal resistance. So those values are fixed. However, the user can modify the case-to-enclosure "_ce_" thermal resistances as part of the thermal design "tuning" process, as well as the enclosure-to-outside ambient thermal resistance.

One interesting and perhaps counter-intuitive characteristic of this design is that the regulator temperature has a higher value when the LEDs are dimmed, rather than operating a full brightness. This is due to load sharing with the transistor. At higher LED currents, the voltage across the "r_bypass" resistor increases, to turn on the PNP transistor. But this voltage increase also reduces the effective voltage drop across the regulator (see the light blue and magenta waveforms), and thereby reduces the regulator’s power dissipation!

You can try changing r_bypass and see its effect on the regulator and PNP transistor temperatures (orange and red waveforms, respectively). You can also vary many of the circuit operating conditions, such as the AC input voltage and frequency, the outside ambient temperature, and the LED current set-points using the variable sense resistor's "initial" and "pulse" settings.

We believe the ability to coordinate the electrical and thermal design in an integrated simulation context, will prevent both overdesign and unexpected interactions that frequently occur with separate design processes and static-data handoff.

For additional information on this, please see my previous blog on Getting the Heat Out!