On 11 Apr 2017 12:26:08 +0100 (BST), Theo Markettos <theom+news@chiark.greenend.org.uk> wrote:>In comp.arch.fpga Piotr Wyderski <peter.pan@neverland.mil> wrote: >> John Larkin wrote: >> >> > 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. > >We do that by controlling the fan speed: keeps the FPGA ~40C which is in the >middle of its timing range.We do have provision for adding a pin-fin heat sink and a fan directly over the chip. Like this: https://dl.dropboxusercontent.com/u/53724080/Thermal/Uzed_Fan_Side.JPG 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. https://dl.dropboxusercontent.com/u/53724080/Circuits/Power/Fan_Regulator.jpg -- John Larkin Highland Technology, Inc lunatic fringe electronics
FPGA as heater
Started by ●April 10, 2017
Reply by ●April 11, 20172017-04-11
Reply by ●April 11, 20172017-04-11
In comp.arch.fpga John Larkin <jjlarkin@highlandtechnology.com> wrote:> We do have provision for adding a pin-fin heat sink and a fan directly > over the chip. Like this: > > https://dl.dropboxusercontent.com/u/53724080/Thermal/Uzed_Fan_Side.JPG > > Just yesterday someone was harassing me to make the fan speed software > controllable, so maybe I will.FWIW, we have a simple hardware control loop of the fan PWM. This is the source: https://github.com/CTSRD-CHERI/beri/blob/master/cherilibs/trunk/peripherals/FanControl/FanControl.bsv Theo
Reply by ●April 11, 20172017-04-11
On 11 Apr 2017 16:28:03 +0100 (BST), Theo Markettos <theom+news@chiark.greenend.org.uk> wrote:>In comp.arch.fpga John Larkin <jjlarkin@highlandtechnology.com> wrote: >> We do have provision for adding a pin-fin heat sink and a fan directly >> over the chip. Like this: >> >> https://dl.dropboxusercontent.com/u/53724080/Thermal/Uzed_Fan_Side.JPG >> >> Just yesterday someone was harassing me to make the fan speed software >> controllable, so maybe I will. > >FWIW, we have a simple hardware control loop of the fan PWM. This is the >source: >https://github.com/CTSRD-CHERI/beri/blob/master/cherilibs/trunk/peripherals/FanControl/FanControl.bsv > >TheoLooks 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
Reply by ●April 11, 20172017-04-11
In comp.arch.fpga John Larkin <jjlarkin@highlandtechnology.com> wrote:> 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 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.> 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.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 by ●April 11, 20172017-04-11
John Larkin wrote...> >There will be an overall box fan, and it is speed controlled. > >https://dl.dropboxusercontent.com/u/53724080/Circuits/Power/Fan_Regulator.jpgHere's my fan speed controller. Quite serious. https://www.dropbox.com/s/7gsrmb9uci1wdb9/RIS-764Gb_fan-speed-controller.JPG?dl=0 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 by ●April 11, 20172017-04-11
On 11 Apr 2017 17:45:05 +0100 (BST), Theo Markettos <theom+news@chiark.greenend.org.uk> wrote:>In comp.arch.fpga John Larkin <jjlarkin@highlandtechnology.com> wrote: >> 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 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.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.> >> 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. > >Min-to-max slew taking minutes seems like a bug not a feature - unless the >junction temperature has a similar time constant.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.> >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.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.> >(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-- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
Reply by ●April 11, 20172017-04-11
On 11 Apr 2017 09:52:20 -0700, Winfield Hill <hill@rowland.harvard.edu> wrote:>John Larkin wrote... >> >>There will be an overall box fan, and it is speed controlled. >> >>https://dl.dropboxusercontent.com/u/53724080/Circuits/Power/Fan_Regulator.jpg > > Here's my fan speed controller. Quite serious. >https://www.dropbox.com/s/7gsrmb9uci1wdb9/RIS-764Gb_fan-speed-controller.JPG?dl=0 > > 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.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 jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
Reply by ●April 11, 20172017-04-11
On Mon, 10 Apr 2017 20:06:57 -0700, John Larkin <jjlarkin@highlandtechnology.com> wrote:>On Mon, 10 Apr 2017 22:15:50 -0400, krw@notreal.com wrote: > >>On Mon, 10 Apr 2017 18:13:13 -0700, John Larkin >><jjlarkin@highland_snip_technology.com> wrote: >> >>>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. >> >>Why not? Don't bother with the output frequency, just vary the number >>of flops wiggling. > >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.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.> >I'm thinking we could reduce the overall effect of ambient temp >changes by some healthy factor, 4:1 or 10:1 or something.Seems reasonable. IBM used to add heater chips for the same purpose (bipolar circuits run faster at high temperature).
Reply by ●April 11, 20172017-04-11
On Tue, 11 Apr 2017 21:09:52 -0400, krw@notreal.com wrote:>On Mon, 10 Apr 2017 20:06:57 -0700, John Larkin ><jjlarkin@highlandtechnology.com> wrote: > >>On Mon, 10 Apr 2017 22:15:50 -0400, krw@notreal.com wrote: >> >>>On Mon, 10 Apr 2017 18:13:13 -0700, John Larkin >>><jjlarkin@highland_snip_technology.com> wrote: >>> >>>>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. >>> >>>Why not? Don't bother with the output frequency, just vary the number >>>of flops wiggling. >> >>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. > >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. >> >>I'm thinking we could reduce the overall effect of ambient temp >>changes by some healthy factor, 4:1 or 10:1 or something. > >Seems reasonable. IBM used to add heater chips for the same purpose >(bipolar circuits run faster at high temperature).CMOS is slower at high temps. Somewhere between about 1000 and 3000 PPM/K prop delay. -- John Larkin Highland Technology, Inc lunatic fringe electronics
Reply by ●April 11, 20172017-04-11
On Tue, 11 Apr 2017 19:26:01 -0700, John Larkin <jjlarkin@highlandtechnology.com> wrote:>On Tue, 11 Apr 2017 21:09:52 -0400, krw@notreal.com wrote: > >>On Mon, 10 Apr 2017 20:06:57 -0700, John Larkin >><jjlarkin@highlandtechnology.com> wrote: >> >>>On Mon, 10 Apr 2017 22:15:50 -0400, krw@notreal.com wrote: >>> >>>>On Mon, 10 Apr 2017 18:13:13 -0700, John Larkin >>>><jjlarkin@highland_snip_technology.com> wrote: >>>> >>>>>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. >>>> >>>>Why not? Don't bother with the output frequency, just vary the number >>>>of flops wiggling. >>> >>>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. >> >>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. >>> >>>I'm thinking we could reduce the overall effect of ambient temp >>>changes by some healthy factor, 4:1 or 10:1 or something. >> >>Seems reasonable. IBM used to add heater chips for the same purpose >>(bipolar circuits run faster at high temperature). > >CMOS is slower at high temps. Somewhere between about 1000 and 3000 >PPM/K prop delay.I understand but my point was that regulating temperature to control speed has been done. It's not a strange idea at all.
