FPGA as heater

We have a ZYNQ whose predicted timing isn't meeting decent margins. And we don't want a lot of output pin timing variation in real life.

We can measure the chip temperature with the XADC thing. So, why not make an on-chip heater? Use a PLL to clock a bunch of flops, and vary the PLL output frequency to keep the chip temp roughly constant.

--
John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  
 Click to see the full signature
Reply to
John Larkin
Loading thread data ...

Why not? Don't bother with the output frequency, just vary the number of flops wiggling.

Reply to
krw

That would work too. Maybe have a 2-bit heat control word, to get coarse steps of power dissipation, 4 groups of flops. I suppose a single on-off bit could be a simple bang-bang thermostat.

The PLL thing would be elegant, proportional control of all the flops in the distributed heater array.

I'm thinking we could reduce the overall effect of ambient temp changes by some healthy factor, 4:1 or 10:1 or something.

--
John Larkin         Highland Technology, Inc 

lunatic fringe electronics
 Click to see the full signature
Reply to
John Larkin

Are the die temperature variations caused by ambient temp changes, or on chip heat generation changes?

--

Rick C
Reply to
rickman

Clever, and maybe patentable. Maybe you could servo a ring oscillator frequency to the clock by changing the dissipation and directly stabilize the timing.

--sp

--
Best regards,  
Spehro Pefhany
Reply to
Spehro Pefhany

That would work too. We'd have to persuade/fool the tools into letting us build a ring oscillator!

I've used ring oscillators to measure FPGA chip temp before:

formatting link

The change in prop delay vs temp is fairly small.

--
John Larkin         Highland Technology, Inc 

lunatic fringe electronics
 Click to see the full signature
Reply to
John Larkin

Reminds me my old idea of building domestic heaters out of Pentium4 chips. 20 chips with TDP of 135W make a decent heater and one can always sell the waste MIPS.

Best regards, Piotr

Reply to
Piotr Wyderski

We do that by controlling the fan speed: keeps the FPGA ~40C which is in the middle of its timing range.

BTDT. It's not as simple as that, because CPUs are point heat sources. To distribute the heat (and stop them melting) you need decent heatsinks and cooling. Servers, which do useful compute and emit waste heat, tend to be cooled assuming a high-velocity, high-noise environment. Domestic heating wants low-velocity, low-noise - which needs different enclosure and cooling arrangements. The system ends up being substantially custom by the end of it.

You can get a long way with a dual-socket server board (~400W) in a 'workstation' case, but it's quite space-inefficient. You can't pack CPUs too closely together, first for thermal reasons but also because RAM and IO take up board area. (Blade servers do that, but again they're designed for fast air cooling).

Unless you plan to put your 'furnace' in the basement with enough sound insulation to deaden the howling fans. Or watercool - needing most custom stuff.

Theo

Reply to
Theo Markettos

I sometimes use a monolithic quad to make a temperature-controlled diff pair. One diagonally opposite pair is the amp, and of the others, one is a diode temperature sensor and one is a heater. Works great.

Cheers

Phil Hobbs

Reply to
pcdhobbs

What a waste of Pentium chips. They make such excellent x-acto knife sharpeners.

--
John Larkin         Highland Technology, Inc 

lunatic fringe electronics
 Click to see the full signature
Reply to
John Larkin

We do have provision for adding a pin-fin heat sink and a fan directly over the chip. Like this:

formatting link

Just yesterday someone was harassing me to make the fan speed software controllable, so maybe I will.

I'd rather not have an FPGA fan, but it's pretty likely we'll need it. There will be an overall box fan, and it is speed controlled.

formatting link

--
John Larkin         Highland Technology, Inc 

lunatic fringe electronics
 Click to see the full signature
Reply to
John Larkin

FWIW, we have a simple hardware control loop of the fan PWM. This is the source:

formatting link

Theo

Reply to
Theo Markettos

Looks to me, as I can read the code, that the control algorithm is an up/down counter that controls fan speed, and it's incremented or decremented by the temp being below/above the setpoint. Is that right?

That's the algorithm that I have proposed. Fan speed changes will be slow and controlled, so there would be no acoustic drama. The min-to-max fan speed slew could take minutes. A cal table would include min fan voltage, max fan voltage, and the up/down increment, so tuning would be easy.

--
John Larkin         Highland Technology, Inc 

lunatic fringe electronics
 Click to see the full signature
Reply to
John Larkin

That's right. Note that it's better to drive fans by PWM than with a linear voltage - at low voltages they can stall, while the PWM is enough to kick them into spinning.

This also makes the whole system entirely digital (beyond the sensor), saving components. You just need one MOSFET.

Min-to-max slew taking minutes seems like a bug not a feature - unless the junction temperature has a similar time constant.

It is also worth reading the tach back from the fan. Fans die - and it's better for your system to shut down in a fault condition than continue melting because it hasn't noticed.

(On a three-wire fan the tach gets chopped by the PWM and creates erroneous readings - four wire fans avoid that, or you can do tricks with your FPGA)

Theo

Reply to
Theo Markettos

Here's my fan speed controller. Quite serious.

formatting link

First there's an LM35 TO-220-package temp sensor mounted to the heat sink, amplify and offset its 10mV/deg signal by 11x, to generate a fan-speed voltage, present to a TC647 fan-speed PWM chip, add optional MOSFET for when using a non-PWM fan. E.g., cool, fan runs at 0%, ramps its speed over a 30 to 40 degree range, thereafter runs at 100%. TC647 chip senses stalled fan, makes error signal.

--
 Thanks, 
    - Win
Reply to
Winfield Hill

We have a nice fan in stock, and it really didn't like direct PWM drive. So we'd need an inductor, maybe drive it from a synchronous switcher or something. The linear thing should work; we will have a minimum voltage, to keep the fan spinning. This 24V fan starts spinning at about 7 volts, so we'd always give it more.

We just want to avoid acoustic drama. The box fan can have a slow slew rate. If we have a separate FPGA fan, that can be faster, since it won't be very audible from outside the box. All the params will be in a writable cal table, so we can play with things without recompiling.

The fan that we have doesn't have a tach, so we'll just look at temperatures. We have a thermistor on the PCB, and both FPGAs can report their die temp.

--
John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  
 Click to see the full signature
Reply to
John Larkin

That TO220 LM35 is nice.

Our two FPGA die temps are only readable digitally. We have a thermistor on the PCB, digitized by the BIST analog mux thing. All the controls will be software.

--
John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  
 Click to see the full signature
Reply to
John Larkin

You can do the same thing with the flops. Use a shift register to enable flops in a "thermometer code" sort of thing. Too low - shift right. Wait. Still to low - shift right. Wait. Too high - shift left...

There are all sorts of algorithms that can be built into spare flops.

Seems reasonable. IBM used to add heater chips for the same purpose (bipolar circuits run faster at high temperature).

Reply to
krw

CMOS is slower at high temps. Somewhere between about 1000 and 3000 PPM/K prop delay.

--
John Larkin         Highland Technology, Inc 

lunatic fringe electronics
 Click to see the full signature
Reply to
John Larkin

I understand but my point was that regulating temperature to control speed has been done. It's not a strange idea at all.

Reply to
krw

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.