Power Reduction Strategy

I have a design on a Spartan 3 2000. It uses nearly all slices, two thirds of the FF and LUTs. Also all BlockRam and all BlockMultiplier are used. The design uses three clock. A 40 Mhz clock for configuration and registers, 80 Mhz for data processing, and 160 Mhz for internal processing in certain blocks.

The problem is that the device becomes hot, so hot, that you can burn your fingers. I measured up to 104 =B0C on the FPGA Ituses nearly 1.3 W. I have alredy implemeted ClockEnables everywhere possible. Also on RAMs. I have already sythesized with Power Reduction option.

The Device can't have a active cooling, like a fan.

Does anybody have some advice how to further reduce the power ? 25 % would be great.

Reply to
tgschwind
Loading thread data ...

Try using the enabled clock buffers to create a safe, gated clock if you have a large quantity of registers using the same enable.

Also, how are you generating your separate clocks? Try using fewer DCMs, by manually dividing clocks (i.e. selectively disabling some enabled clock buffers, etc.)

As always, look for opportunities to shut off (disable clock) on anything that is not used all the time.

What does your IO look like? Can you soften your drive strengths, and/ or reduce slew rates?

Do you have any opportunities to use distributed rams instead of flops? I once had a design with a bunch of simple UARTs. I modified the design to TDM the UARTs using distributed ram, and reduced logic and power consumption drastically.

Andy

Reply to
Andy

Your post got me thinking about dynamically reconfiguring an FPGA to save power. I wonder how much power you can save by reconfiguring an FPGA so that an unused block is not there as compared to just turning off the clock to that block. Is the static power consumption of an empty slice the same as the static power consumption of a configured slice with static inputs?

/Andreas

Reply to
Andreas Ehliar

A lot depends on the design. Careful floorplanning can reduce power by

20% or more by reducing the complexity and length of routing.

If your logic has multiple levels of LUTs between flip-flops, adding pipeline stages to reduce the number of levels of logic can reduce power by a bit. This is counter-intuitive. It works because a good percentage of an FPGA's power dissipation comes from propagation of glitch energy through combinatorial logic. Adding flip-flops stops the propagation of a glitch. There was a paper at FPGA, probably around

2002 that talked about this and claimed as much as 25% reduction of power by using deep pipelining. The example used, as I recall was rather extreme, but I think the idea is still valid. Again, most of the dissipation is in the routing channels, not in the lut logic, so adding the flip-flops is outweighed by the reduced dissipation in the routing channels.

You can use the BUFGMUXs to gate your clocks if needed, however most designs need the clocks running, and gating clocks brings its own set of problems.

You can time multiplex one instance of logic over multiple "channels" if that can be done with relatively little multiplex/de-multiplex logic to get a smaller gate count at the expense of running at a higher frequency. This often reduces power because routing complexity is reduced and because you only take one hit on the static dissipation instead of an added hit for each channel. There will be no savings in teh dynamic dissipation, as that is proportional to toggle rate. The dynamic power may even be a little bit higher because of capacitive effects on the clock distribution.

Of these, the most effective will be careful floorplanning.

You might also be able to reduce the voltages a bit if you can still make tim> I have a design on a Spartan 3 2000. It uses nearly all slices, two

Reply to
Ray Andraka

How much energy/heat does that save? You aren't changing the toggle rate or the size of the external cap, just the rise/fall times.

--
These are my opinions, not necessarily my employer's.  I hate spam.
Reply to
Hal Murray

The answer is YES (same static power) IMHO. Peter Alfke

Reply to
Peter Alfke

Where is that power reduction option?

I'm working on a design which is heating a Spartan 3 FPGA a bit too much (not so extreme as your design, I can still keep my finger on the chip but it is not comfortable). I would like some power savings. According to XPower, it saves quite some power when the drive strength of outputs is reduced.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Reply to
Nico Coesel

I think unconfigured logic has the same static dissipation as configured logic that has all the inputs held static, so reconfiguring to take logic out isn't going to save you anything. On top of that, reconfiguration takes a considerable amount of power so you'd end up with a greater net power. Now if you were to reconfigure so that unused logic gets replaced with new logic that wouldn't have fit otherwise, then you'll likely get some savings as long as the reconfiguration is done infrequently enough for the power overhead of doing the reconfiguraiton doesn't overshadow the savings. Basically, if reconfiguration lets you get into a smaller device, then it might be a win for power. If it doesn't shrink the device size, then you aren't going to realize any power saving.

Reply to
Ray Andraka

OK, you got me there. It saves peak power, but not average (thermal) power. If you could redesign the board, you might be able to make the power supply run cooler, and thus not heat up the FPGA, but that's probably out of scope.

OTOH, if he's got SSO problems causing inputs (perhaps not observed at the time) to toggle excessively, then that could cause extra power to be consumed, which would be reduced/eliminated by slowing the outputs down. Admittedly, a bit of a reach though :)

Andy

Reply to
Andy

Has anyone measured this, to check it is the same ?

I have seen CPLDs where the Macrocell logic state did have a measurable effect on static Icc :) ( this was not the product term fuses, but the logic levels in a working device )

At a first look, CMOS is Vcc.Gnd level agnostic, but when you start adding all the complex leakages, and maybe level shifters, then you may find some variation. (it may not be much..)

-jg

Reply to
Jim Granville

Hi,

Hopefully I can be of assistance despite your use of an inferior part ;-p

You mention 1.3W of power @ 104C, presumably at room temperature (25C) and nominal (1.2V) voltage with still air and no heatsink, measured on the case (?). How are you arriving at 1.3W? Is this just the current draw off VccInt x 1.2V? Remember that there is also current drawn off VccAux (65 mA * 2.5V = 163mW according to XPE). And assuming you have I/Os in your chip, there will additional power drawn from your VccO (for all I/O standards) and off-chip Vtt rails (if using terminated standards) -- more on that later.

Assuming your 1.3W is correct, then you've got a ThetaCA (case-to- ambient thermal resistance) of (104-25) / 1.3 = 60 degrees per W!!! That seems unlikely, so I will assume that there is some additional source of power dissipation in your FPGA. With no air movement, I'd figure a thetaJA of ~15 deg/W is more reasonable (based on Cyclone III EPE). Assuming this is the case, you are burning somewhere in the neighbourhood of (104 - 25) / 15 = 5.3W in your FPGA (eek). I think you need to find that power source!

First, I would check to be 100% certain that your I/Os are not shorted or nothing else bad like that is happening. Shorted I/Os (for example, unused I/Os driving ground but hooked up to a signal or vcc on the board) can really burn a ton of power. Measure your device temperature with the clocks completely disabled so that the only contributors are static core and static I/O power -- what's the temperature? Then run with the I/Os clocked correctly, but disable as much core logic functionality as possible.

Even if your I/Os are not shorted, it would help to describe your I/O configuration. I/Os can burn a lot of power. Unterminated I/O standards (such as 3.3V LVTTL) will consume power to charge and discharge the (a) FPGA pin (b) PCB trace and (c) far-end load; all of this current draw is dissipated as heat inside the FPGA, and is irrespective of drive strength and slew rate (well, almost -- these will affect the short-circuit current, but unlikely to be more than a

10% impact).

Terminated I/O standards are a whole other beast. There is a static current drawn through the voltage-divider network formed by your I/O drive transistor, the series termination resistor, and the near/far- end parallel termination resistor to Vtt. This is true regardless of whether you are driving a 1 or a 0. Only some of that current draw is dissipated as heat within the FPGA -- the rest is dissipated in off- chip components. This means that your *thermal power* will depend on the drive strength of your SSTL I/O -- the higher the drive, the higher the *system power* consumption but the lower the *FPGA thermal power* will be.

You can download the Cyclone II or Cyclone III Early Power Estimator to play around with I/O standards and see how much power is dissipated on vs. off-chip for various configurations of I/O. All the data in that tool is from HSPICE simulations of our I/O buffer, and we've carefully seperated out on-chip power from system power/current draw. While Spartan-3 will have slightly different I/Os, they should behave similarly to first order so the trends/results should be good enough for your purposes. The tool is available at

formatting link

If you verify that indeed you aren't burning a ton of I/O power, next step is the core. This is trickier -- the best things you can do are to set clock enables on the global clocks, set clock enables on the FFs (which disables some local clocking), and only read/write to your RAMs when you really need the data. For example, don't be lazy with your FIFOs -- if you aren't using the read port on a given cycle, disable the read enable / clock enable on the block. You can also try area-driven synthesis (vs. speed or balanced mapping). This will result in smaller circuits which will tend to use less power (but not always).

Hopefully you'll respond with some more information on your design and your measurements. If all else fails and your design really is running at 104C, and you can't slap a heat sink on it (without fan), then I'd suggest taking the bluer road and migrate your design to Cyclone III :-)

Regards,

Paul Leventis Altera Corp.

Reply to
Paul Leventis

We epoxy pin-fin heatsinks to some of our Spartan chips. It cools them off and reduces prop delay creep. Makes them look very imposing, too, and hides the fact that they're just FPGAs.

If they're not bga's, you can also put a "power pad" under them, and dump some additional heat into a ground plane. Some sort of thermal interface gunk would help.

John

Reply to
John Larkin

Did you get the 104'C with an external temperature probe on the package top, or is that the calculated die temp, from measuring a thermal sense diode ?

-jg

Reply to
Jim Granville

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.