FPGA as heater

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.

On Tue, 11 Apr 2017 09:29:03 -0700 (PDT), Kevin Neilson
<kevin.neilson@xilinx.com> wrote:

>On Monday, April 10, 2017 at 7:13:23 PM UTC-6, John Larkin 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.
>
>I'm confused by the concept.  Doesn't timing get *worse* as temp increases?

Prop delays get slower.

>  How would a higher temperature help? 

High temperature is an unfortunate fact of life some times. I'm after
constant temperature, to minimize delay variations as ambient temp and
logic power dissipations change.

> By "output pin timing variation" do you mean that there are combinatorial output paths?  I think the best best is to stay as cool as possible and keep all outputs registered. 

All our critical outputs are registered in the i/o cells. Xilinx tools
report almost a 3:1 delay range from clock to outputs, over the full
range of process, power supply, and temperature. Apparently the tools
assume the max specified Vcc and temperature spreads for the part and
don't let us tease out anything, or restrict the analysis to any
narrower ranges. 


> If you really need to control output delay you can use the IODELAY block, possibly along with a copper trace feedback line.


Our output data-valid window is predicted by the tools to be very
narrow relative to the clock period. We figure that controlling the
temperature (and maybe controlling Vcc-core vs temperature) will open
up the timing window. The final analysis will have to be experimental.

We can't crank in a constant delay to fix anything; the problem is the
predicted variation in delay.

>
>I have used precision oscillators with built-in heaters.  In that case, it's more important that the crystal stay at a constant temp than what the temp is.  By making that temperature above the highest possible ambient temp, the heater can keep the crystal temp constant.

That's the idea, keep the FPGA core near the max naturally-expected
temperature, heat it up as needed, and that will reduce actual timing
variations to below the worst-case predicted by the tools.

I expect that the tools are grossly pessimistic. I sure hope so.



-- 

John Larkin         Highland Technology, Inc

lunatic fringe electronics 

On 4/11/2017 12:31 PM, Kevin Neilson wrote:
>
>> https://dl.dropboxusercontent.com/u/53724080/Thermal/ESM_Ring_Oscillator.jpg
>>
>> The change in prop delay vs temp is fairly small.
>>
>
> That's more linear than I would've guessed.  Is that the ambient temperature or junction temp?

Even if it wasn't especially linear, the proportionality is based on 
degrees Kelvin.  So the non-linearity would not be terribly pronounced.

That was part of the reason for the inflate-gate thing a couple of years 
ago.  I remember that between the pressure being relative rather than 
absolute and the temperature being Celsius or Fahrenheit rather than 
Kevin, the people here took some time to figure out that the reported 
pressures were easily explained by the difference in temperature between 
the locker rooms and the playing field.

-- 

Rick C

On 4/11/2017 11:37 PM, John Larkin wrote:
> On Tue, 11 Apr 2017 09:29:03 -0700 (PDT), Kevin Neilson
> <kevin.neilson@xilinx.com> wrote:
>
>> On Monday, April 10, 2017 at 7:13:23 PM UTC-6, John Larkin 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.
>>
>> I'm confused by the concept.  Doesn't timing get *worse* as temp increases?
>
> Prop delays get slower.
>
>>  How would a higher temperature help?
>
> High temperature is an unfortunate fact of life some times. I'm after
> constant temperature, to minimize delay variations as ambient temp and
> logic power dissipations change.
>
>> By "output pin timing variation" do you mean that there are combinatorial output paths?  I think the best best is to stay as cool as possible and keep all outputs registered.
>
> All our critical outputs are registered in the i/o cells. Xilinx tools
> report almost a 3:1 delay range from clock to outputs, over the full
> range of process, power supply, and temperature. Apparently the tools
> assume the max specified Vcc and temperature spreads for the part and
> don't let us tease out anything, or restrict the analysis to any
> narrower ranges.
>
>
>> If you really need to control output delay you can use the IODELAY block, possibly along with a copper trace feedback line.
>
>
> Our output data-valid window is predicted by the tools to be very
> narrow relative to the clock period. We figure that controlling the
> temperature (and maybe controlling Vcc-core vs temperature) will open
> up the timing window. The final analysis will have to be experimental.
>
> We can't crank in a constant delay to fix anything; the problem is the
> predicted variation in delay.
>
>>
>> I have used precision oscillators with built-in heaters.  In that case, it's more important that the crystal stay at a constant temp than what the temp is.  By making that temperature above the highest possible ambient temp, the heater can keep the crystal temp constant.
>
> That's the idea, keep the FPGA core near the max naturally-expected
> temperature, heat it up as needed, and that will reduce actual timing
> variations to below the worst-case predicted by the tools.
>
> I expect that the tools are grossly pessimistic. I sure hope so.

The nature of designing synchronous logic is that you want to know the 
worst case delay so you can design to a constant period clock cycle.  So 
the worst case is the design criteria.  The timing analysis tools are 
naturally "pessimistic" in that sense.  But that is intended so that the 
design process is a matter of getting all timing paths to meet the 
required timing rather than trying to compare delays on this path to 
delays on that path which would be a nightmare.

When you need better timing on the I/Os, as you have done, the signals 
can be clocked in the IOB FFs which give the lowest variation in timing 
as well as the shortest delays from clock input to signal output. 
Typically I/O timing also needs to be designed for worst case as well 
because the need is to meet setup timing while hold timing is typically 
guaranteed by the spec on the I/Os.  But if you are not doing 
synchronous design this may not be optimal.  If you are trying to get a 
specific timing of an output edge, you may have to reclock the signals 
through discrete logic.

-- 

Rick C

Our biggest box takes about a kilowatt, which includes 70W for the fans. We build enough of them, which run 24/7, to work out the total cost of ownership and running the box a little bit hotter reduces reliability a bit but saves enough electricity to make it worthwhile.

Colin

On Tue, 11 Apr 2017 09:31:20 -0700 (PDT), Kevin Neilson
<kevin.neilson@xilinx.com> wrote:

>
>> https://dl.dropboxusercontent.com/u/53724080/Thermal/ESM_Ring_Oscillator.jpg
>> 
>> The change in prop delay vs temp is fairly small.
>> 
>
>That's more linear than I would've guessed.  Is that the ambient temperature or junction temp?

Foil-sticky thermocouple on the top of the chip. It was an Altera
Cyclone 3, clocked internally at 250 MHz.

https://dl.dropboxusercontent.com/u/53724080/PCBs/ESM_rev_B.jpg

The ring oscillator was divided internally before we counted it, by 16
as I recall.

Newer chips tend to have an actual, fairly accurate, die temp sensor,
which opens up complex schemes to control die temp, or measure it and
tweak Vccint, or something.







-- 

John Larkin         Highland Technology, Inc

lunatic fringe electronics 

On 4/11/2017 12:29 PM, Kevin Neilson wrote:
> On Monday, April 10, 2017 at 7:13:23 PM UTC-6, John Larkin 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.
>
> I'm confused by the concept.  Doesn't timing get *worse* as temp increases?  How would a higher temperature help?  By "output pin timing variation" do you mean that there are combinatorial output paths?  I think the best best is to stay as cool as possible and keep all outputs registered.  If you really need to control output delay you can use the IODELAY block, possibly along with a copper trace feedback line.
>
> I have used precision oscillators with built-in heaters.  In that case, it's more important that the crystal stay at a constant temp than what the temp is.  By making that temperature above the highest possible ambient temp, the heater can keep the crystal temp constant.

That is exactly what John is talking about, except the heater will be on 
the FPGA itself.

-- 

Rick C

Den onsdag den 12. april 2017 kl. 05.37.07 UTC+2 skrev John Larkin:
> On Tue, 11 Apr 2017 09:29:03 -0700 (PDT), Kevin Neilson
> <kevin.neilson@xilinx.com> wrote:
> 
> >On Monday, April 10, 2017 at 7:13:23 PM UTC-6, John Larkin 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.
> >
> >I'm confused by the concept.  Doesn't timing get *worse* as temp increases?
> 
> Prop delays get slower.
> 
> >  How would a higher temperature help? 
> 
> High temperature is an unfortunate fact of life some times. I'm after
> constant temperature, to minimize delay variations as ambient temp and
> logic power dissipations change.
> 
> > By "output pin timing variation" do you mean that there are combinatorial output paths?  I think the best best is to stay as cool as possible and keep all outputs registered. 
> 
> All our critical outputs are registered in the i/o cells. Xilinx tools
> report almost a 3:1 delay range from clock to outputs, over the full
> range of process, power supply, and temperature. Apparently the tools
> assume the max specified Vcc and temperature spreads for the part and
> don't let us tease out anything, or restrict the analysis to any
> narrower ranges. 
> 
> 
> > If you really need to control output delay you can use the IODELAY block, possibly along with a copper trace feedback line.
> 
> 
> Our output data-valid window is predicted by the tools to be very
> narrow relative to the clock period. We figure that controlling the
> temperature (and maybe controlling Vcc-core vs temperature) will open
> up the timing window. The final analysis will have to be experimental.
> 
> We can't crank in a constant delay to fix anything; the problem is the
> predicted variation in delay.
> 

that is basically what the IDELAY/ODELAY blocks are for, you instantiate an IDELAYCTRL and feed it a ~200MHz clock and it uses that a reference to 
reduce the effects of process, voltage, and temperature on the iodelay

> > If you really need to control output delay you can use the IODELAY bloc=
k, possibly along with a copper trace feedback line.
>=20
>=20
> Our output data-valid window is predicted by the tools to be very
> narrow relative to the clock period. We figure that controlling the
> temperature (and maybe controlling Vcc-core vs temperature) will open
> up the timing window. The final analysis will have to be experimental.
>=20
> We can't crank in a constant delay to fix anything; the problem is the
> predicted variation in delay.
>=20

I still think the IODELAY could help you.  The output goes through an adjus=
table IODELAY, then you route the output back in through a pin, adjust the =
input IODELAY to figure out where the incoming edge is, and then use a feed=
back loop to keep the output delay constant.  It's a technique used for des=
kewing DRAM data.  I think the main clock would also have to be deskewed wi=
th a BUFG so you have a good reference for the input.  Or, if you character=
ized the delay-vs-temp in the lab, you could run in open-loop mode by adjus=
ting the IODELAY tap based on the temperature you read.=20

Yes, the tools are definitely pessimistic.  They're only useful for worst-c=
ase.  I'm pretty sure you can put in the max temperature when doing PAR, so=
 you could isolate the effects of just that, but it will still probably be =
worse variation than in reality.

On Wed, 12 Apr 2017 12:37:59 -0700 (PDT), Kevin Neilson
<kevin.neilson@xilinx.com> wrote:

>> > If you really need to control output delay you can use the IODELAY block, possibly along with a copper trace feedback line.
>> 
>> 
>> Our output data-valid window is predicted by the tools to be very
>> narrow relative to the clock period. We figure that controlling the
>> temperature (and maybe controlling Vcc-core vs temperature) will open
>> up the timing window. The final analysis will have to be experimental.
>> 
>> We can't crank in a constant delay to fix anything; the problem is the
>> predicted variation in delay.
>> 
>
>I still think the IODELAY could help you.  The output goes through an adjustable IODELAY, then you route the output back in through a pin, adjust the input IODELAY to figure out where the incoming edge is, and then use a feedback loop to keep the output delay constant.  It's a technique used for deskewing DRAM data.  I think the main clock would also have to be deskewed with a BUFG so you have a good reference for the input.  Or, if you characterized the delay-vs-temp in the lab, you could run in open-loop mode by adjusting the IODELAY tap based on the temperature you read. 
>
>Yes, the tools are definitely pessimistic.  They're only useful for worst-case.  I'm pretty sure you can put in the max temperature when doing PAR, so you could isolate the effects of just that, but it will still probably be worse variation than in reality.

My FPGA guy says that the ZYNQ does not have adjustable delay after
the i/o block flops. We can vary drive strength in four steps, and we
may be able to do something with that.


-- 

John Larkin         Highland Technology, Inc
picosecond timing   precision measurement 

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com