Back Of The Envelope Physics

Why Your Fancy Simulations Are Lying To You

I spent last Tuesday debugging a thermal runaway issue on a power supply design that had been simulated in SPICE for three days straight. The simulation said everything was fine. The math I scribbled on a receipt during the bus ride home said we were about to melt a $40 capacitor within forty seconds of load. Turns out the receipt was right and the simulation was wrong by a factor of eight. This is what Back Of The Envelope Physics actually is. It is not a shortcut you use when you are too lazy to run a proper analysis. It is a sanity check that catches the cases where your sophisticated models have silently ignored something important because nobody remembered to tell the model about it. Most engineers treat it as a preliminary step, something rough you do before getting to the real work. That is backwards. The real work is doing the envelope calculation after the simulation, because that is when you find out what the simulation missed.

Back Of The Envelope Physics: How To Actually Do It

The method itself is nearly trivial. You take the problem you are trying to solve, strip away every parameter that does not change the answer by an order of magnitude, and work with powers of ten rather than precise values. You are looking for the dominant term. Everything else is noise until you prove it is not. Take a concrete example. Say you need to figure out whether a copper trace on a PCB is going to overheat carrying 5 amps. A full thermal simulation might take two hours and require a mesh, boundary conditions, material properties, and someone who knows the solver well enough not to trust the output blindly. The envelope approach takes about four minutes. You need the trace dimensions. Let us say it is 2 oz copper, 20 mils wide, and 1 inch long. The cross sectional area is roughly 400 mils squared, or about 0.25 square millimeters. Copper's resistivity at room temperature is 1.7 times ten to the minus eight ohm meters. The resistance of that trace works out to roughly 0.07 ohms if you ignore temperature dependence, which you should not, but for a first pass it is fine. Power dissipation is I squared R, so 25 times 0.07, which is about 1.75 watts concentrated in a tiny volume.

Now you need to know if 1.75 watts in that geometry is a problem. Without a simulator, you estimate the surface area available for cooling. The trace is maybe 1 inch long and 20 mils wide on each face, plus the edges. Roughly 0.5 square centimeters of exposed copper. Natural convection from a flat surface in still air moves about 5 to 10 watts per square meter per kelvin. Half a square centimeter is 0.0005 square meters. At 7 watts per square meter per kelvin, that is 0.0035 watts per kelvin of temperature rise. Divide 1.75 watts by 0.0035 and you get roughly 500 kelvin temperature rise. That is way too hot. Even if every assumption in that chain was off by a factor of two in the favorable direction, you are still looking at a substantial temperature increase. The conclusion is immediate and unambiguous. That trace needs to be wider, shorter, or the current needs to drop. No simulation required. The envelope calculation told you in four minutes what a thermal FEM would tell you in four hours, and it told you without needing to verify that the mesh was adequate or that the boundary conditions made physical sense. Here is the part most people get wrong. The goal is not to get the right answer. The goal is to get an answer that is definitely wrong in the right direction, or definitely right within an order of magnitude. If your envelope calculation says a component will dissipate 3 watts and your simulation says it will dissipate 3.1 watts, you have not done anything useful. You have just wasted time confirming the simulation. Envelope calculations should either confirm the simulation qualitatively or reveal that the simulation is missing physics. Those are the only two outcomes that matter.

I ran into a particularly annoying case with a motor driver circuit a few years back. We were using a MOSFET to switch a 12-volt brushed DC motor at about 20 kilohertz. The datasheet specified a gate charge of 20 nanocoulombs, which seemed trivial. My first envelope calculation for the gate drive power was straightforward: charge times voltage times frequency. Twenty nanocoulombs times 12 volts times 20 kilohertz gives 4.8 microwatts. Completely negligible. So I did not think about the gate drive circuit at all. The board came back and the MOSFET was thermally shutting down, even though the conduction losses alone should have been fine. The simulation showed junction temperature at 65 degrees Celsius under full load. We tore the thing apart and found that the gate resistor was burning through. Not the MOSFET. The gate resistor. A 0805 package, rated at a quarter watt, running maybe ten times its power rating. The envelope calculation I had done ignored the resistive losses in the gate drive loop entirely. It only considered the energy to charge the gate capacitance, which is dissipated in the gate resistor on every switching cycle. The correct formula is also Q times V times frequency, but the result is the same because all that energy goes into the gate resistor, not into the gate capacitance storing useful energy. The MOSFET gate capacitance does not store the energy permanently. It charges up, then discharges through the resistor every cycle. So the 4.8 microwatts I calculated was actually correct for the total power dissipated in the gate loop, but the key insight was that this power goes entirely into the gate resistor, not into the MOSFET itself. And the resistor I chose was far too small for that power level in that orientation on the board.

The workaround was embarrassingly simple. I increased the gate resistor value to 10 ohms from whatever the reference design had suggested, which reduced the peak gate current and spread the dissipation, and I moved to a resistor package rated for at least half a watt with adequate copper pour for thermal relief. The MOSFET stayed cool. The gate resistor stayed intact. The total switching losses barely changed because the MOSFET was already slow enough that the slower gate drive did not affect efficiency meaningfully. I could have found this by running a gate drive simulation, but that would have taken an afternoon and still might not have made it obvious that the resistor was the failing component rather than the MOSFET. There are limitations to this approach that are worth stating plainly, because people who rely on envelope calculations too much tend to become overconfident and miss the cases where the approximations break down in subtle ways. The method fails completely when the answer depends on the interaction of multiple small effects that individually seem negligible but collectively dominate. This happens often in RF circuits, where parasitic inductance and capacitance interact in ways that are impossible to estimate with order-of-magnitude reasoning unless you already know exactly which parasitics matter. It also fails in deeply nonlinear systems where the operating point shifts dramatically with small parameter changes, because your linearized approximation around room temperature conditions may be nowhere near the actual operating point under load. Another common failure mode is when the dominant term is not obvious. You might spend five minutes calculating convective cooling and conclude it is negligible, only to discover later that you misidentified the heat transfer regime and radiation was actually dominant, or that forced convection from a fan you forgot to include was moving ten times more heat than natural convection. The envelope method amplifies whatever assumptions you make, so if your assumption is wrong, your answer is wrong in a confident way that is harder to detect than a wrong answer from a careful simulation.

The best use of Back Of The Envelope Physics is as a continuous companion to detailed analysis, not a replacement. Run the simulation. Then do the envelope calculation on the same problem. If they agree within an order of magnitude, proceed with confidence. If they disagree, investigate. The disagreement will almost always reveal something you did not model correctly, and finding that discrepancy is where the actual engineering insight lives. Most of my useful design decisions come from moments like that, not from the simulation outputs themselves. I keep a notebook where I write these calculations in the margins of datasheets and schematic printouts. They are messy, usually in pencil, and occasionally illegible. But they contain more engineering value than any simulation report I have ever written, because they record the moment when I understood what was actually happening rather than what the model predicted was happening.