I am working on an instrument that currently uses a 300 MHz TI dual- issue DSP + A/Ds + a micro. Under "normal" use, I can get a week out of the D-cell batteries the device uses. At the moment, I am considering replacing the DSP and other glue with an FPGA, but I don't see many low-power options. Any suggestions? Any low-power FPGA experiences to share? I asked an Altera FAE and he very rudely answered "Low-power Altera FPGAs aren't on the road map"...yeah and I bet low-power CPLDs (ala MaxII) weren't on the road map until CoolRunner started hurting sales... I'd like to stick with brand A or X since they offer soft core processors. John.
Low-power FPGAs?
A developer is seeking advice on migrating a battery-powered instrument from a DSP to a low-power FPGA while maintaining a week-long runtime. The discussion highlights the significant challenges of static leakage current in modern sub-100nm FPGA geometries compared to traditional microcontrollers and DSPs.
The consensus suggests that while FPGAs are highly efficient for dynamic power via parallelism, static power is the primary bottleneck for battery life. Recommendations include using older process nodes, implementing aggressive clock management, or utilizing a low-power CPLD to manage the power state of the main FPGA.
- FPGAs often have higher static leakage current than DSPs, making them difficult to use in high-uptime battery applications.
- Parallelizing algorithms to lower clock frequency can reduce dynamic power, though running a smaller part faster may minimize static leakage.
- Xilinx and Altera representatives suggest that 90nm and smaller nodes see exponential increases in leakage at higher temperatures.
- Techniques like lowering the core voltage (Vccint) during idle states can significantly reduce static power consumption.
- QuickLogic or older FPGA families (like Altera ACEX) are mentioned as potential alternatives for lower quiescent current.
Have a look at the new Spartan-3 variant when fuller details are released. News item here http://www.xilinx.com/prs_rls/silicon_spart/0478s3lp.htm . Depending on usage and the final figures for current consumption this may do what you want. It you can squeeze you requirements into a Coolrunner2 then it probably remains a better choice. John Adair Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development Board. http://www.enterpoint.co.uk "John" <localhost@localhost.com.com> wrote in message news:YO1fd.27349$Kl3.14348@twister.socal.rr.com...> I am working on an instrument that currently uses a 300 MHz TI dual- > issue DSP + A/Ds + a micro. Under "normal" use, I can get a week out of > the D-cell batteries the device uses. > > At the moment, I am considering replacing the DSP and other glue with an > FPGA, but I don't see many low-power options. > > Any suggestions? Any low-power FPGA experiences to share? > > I asked an Altera FAE and he very rudely answered "Low-power Altera > FPGAs aren't on the road map"...yeah and I bet low-power CPLDs (ala > MaxII) weren't on the road map until CoolRunner started hurting sales... > > I'd like to stick with brand A or X since they offer soft core > processors. > > John.
FPGA's by their very nature are low power.. provided you don't clock them fast. The idea would be to build something like Intel's Speed step into it.. so it slows down or even freezes when not needed. you will want a DPLL version that can have the clock multiplied by more than 2 for this. The DPLL can't be changed without stoppage.. but there are clock muxes too .. so you can clean switch while you change a DPLL. Ray or Austin might know better about doing this.. I've never tried it. Maybe even look at a device that uses quadrant clocks instead of global clocks.. but that would limit area to 1/4 of the device per clock. but a fast clock isn't spread over the entire device then (am not sure how much affect this would have on power). Maybe look at a small coolrunner to handle clock management / power control. Then start using slow clocks where you don't need speed.. and only fast where critical. You should find the power reduction impressive compared to a DSP. But as with anything.. the higher the clock... the higher the power.. so that's your biggest enemy. If you can't reduce the clock.. then IMO low power will never exist with current silicon. Next pick you interfaces wisely. Don't use high power interfaces unless absolutely nessassary. And even then revaluate first. Then pick you IO / CORE / AUX voltages If they are low then you can reduce power... I'm not sure if you can get them to all run of a single battery's voltage.. not using a regulator will save you big time on a power conscious design. failing that... use an ultra high efficient PSU to get your supply voltages from the battery. It will probably be one of the biggest looses power wise. The last thing is don't choose a device bigger than you need. Silicon area is equates to power. There is an entire science devoted to low power. And I'm sure I don't know much about it too :-) Simon "John" <localhost@localhost.com.com> wrote in message news:YO1fd.27349$Kl3.14348@twister.socal.rr.com...> I am working on an instrument that currently uses a 300 MHz TI dual- > issue DSP + A/Ds + a micro. Under "normal" use, I can get a week out of > the D-cell batteries the device uses. > > At the moment, I am considering replacing the DSP and other glue with an > FPGA, but I don't see many low-power options. > > Any suggestions? Any low-power FPGA experiences to share? > > I asked an Altera FAE and he very rudely answered "Low-power Altera > FPGAs aren't on the road map"...yeah and I bet low-power CPLDs (ala > MaxII) weren't on the road map until CoolRunner started hurting sales... > > I'd like to stick with brand A or X since they offer soft core > processors. > > John.
John, There are two issues here: while operating, what is the allowed power budget, and while idling what is the allowed power budget? Some devices just sit there more that 90% of the time doing nothing (like a software defined handheld radio). Other designs are running 100% of the time. FPGAs have more leakage current (static current) than a ASSP (like a DSP uC), and thus are not optimal for designs where you want long battery life. FPGAs are very efficient for doing the work (dynamic power), but high clock speeds means lots of power. Better to make the algorithm highly parallel, and lower the clock rate as much as possible. Typical ratios for DSP vs FPGA are 80:1 speed up possible if you use a FPGA instead of a DSP. You can use this in reverse, in other words, slow down the 300 MHz DSP clock by a factor of 80 when you implement the algorithm in a FPGA (3.75 MHz for the same 'work'). The LX25 Virtex 4 is ~ 40 mA static leakage at room temp at 1.2 volts. The DSP48 blocks (one 18X18 multiply-accumulate) are 3 to 9 mW/MHz (depending on how much interconnect you use to make your filters). Reconfiguration can be used to reprogram the device to do different jobs at different times, so a smaller part can do the job of a larger part, saving static power. Austin John wrote:> I am working on an instrument that currently uses a 300 MHz TI dual- > issue DSP + A/Ds + a micro. Under "normal" use, I can get a week out of > the D-cell batteries the device uses. > > At the moment, I am considering replacing the DSP and other glue with an > FPGA, but I don't see many low-power options. > > Any suggestions? Any low-power FPGA experiences to share? > > I asked an Altera FAE and he very rudely answered "Low-power Altera > FPGAs aren't on the road map"...yeah and I bet low-power CPLDs (ala > MaxII) weren't on the road map until CoolRunner started hurting sales... > > I'd like to stick with brand A or X since they offer soft core > processors. > > John.
>FPGAs are very efficient for doing the work (dynamic power), but high >clock speeds means lots of power. Better to make the algorithm highly >parallel, and lower the clock rate as much as possible.What's going on here? Classic reasoning says that 2 FFs at half speed will take the same power as 1 FF at full speed. (assuming same cap load...) Why not run faster so you can use a smaller part and get lower static power? -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.
Simon, I guess it's been a while since you checked out the quiescent supply currents for the latest parts? For example, worst case Iccintq for the smallest V2PRO (XC2VP2) is 300mA. That's about 20 hours on a NiMH D cell. Typical is 20mA, but no-one would design with typical figures, would they? BTW, anyone know why there's such a big difference from 'typical' to 'max' figures? Does it depend on the configuration used in the part? Cheers, Syms. "Simon Peacock" <nowhere@to.be.found> wrote in message news:417cd164@news.actrix.gen.nz...> FPGA's by their very nature are low power.. provided you don't clock them > fast. >
Hi Austin, Question. Why does a large slow machine use more power than a small fast one? Cheers, Syms. p.s. I think the algorithm uses more or less the same power whichever way you go, so I always go small and fast to use a smaller part. Product of size and speed and all. I guess that's not good for Xilinx's sales though? Just kidding! ;-) "Austin Lesea" <austin@xilinx.com> wrote in message news:clj446$qq3@cliff.xsj.xilinx.com...> FPGAs are very efficient for doing the work (dynamic power), but high > clock speeds means lots of power. Better to make the algorithm highly > parallel, and lower the clock rate as much as possible. >
Symon, The leakage current is not pattern dependent. Make sure you check the latest datasheet, as we used to state all leakages at 100C worst case (theoretical) silicon. We now state what we see from the process control sampling over all actual process corners. Austin Symon wrote:> Simon, > I guess it's been a while since you checked out the quiescent supply > currents for the latest parts? For example, worst case Iccintq for the > smallest V2PRO (XC2VP2) is 300mA. That's about 20 hours on a NiMH D cell. > Typical is 20mA, but no-one would design with typical figures, would they? > BTW, anyone know why there's such a big difference from 'typical' to 'max' > figures? Does it depend on the configuration used in the part? > Cheers, Syms. > > "Simon Peacock" <nowhere@to.be.found> wrote in message > news:417cd164@news.actrix.gen.nz... > >>FPGA's by their very nature are low power.. provided you don't clock them >>fast. >> > > > >
Hal, Let's see....P= CV^2F, and so for each node switching, the power scales with frequency. One node at F is equal to two nodes at 1/2F? Yes, it sure looks that way. I suppose the reason to run slower is to run cooler. But, you are right, run the smallest part as fast as needed to do the work. No reason to run it any faster than needed, however. One reason for the very low power for the DSP48 is that the capacitive loads are very small. Good catch. Thanks, Austin Hal Murray wrote:>>FPGAs are very efficient for doing the work (dynamic power), but high >>clock speeds means lots of power. Better to make the algorithm highly >>parallel, and lower the clock rate as much as possible. > > > What's going on here? Classic reasoning says that 2 FFs at half > speed will take the same power as 1 FF at full speed. (assuming > same cap load...) > > Why not run faster so you can use a smaller part and get lower > static power? >
Hi Austin, http://direct.xilinx.com/bvdocs/publications/ds083.pdf Page 73 of 425. I'm curious at the order of magnitude spread of values from Typical to Max., especially as it's not configuration dependent. Anyway, if you have some new leakage figures, could you let me know where to find them? Thanks, Symon. "Austin Lesea" <austin@xilinx.com> wrote in message news:cljagp$pkn1@cliff.xsj.xilinx.com...> Symon, > > The leakage current is not pattern dependent. > > Make sure you check the latest datasheet, as we used to state all > leakages at 100C worst case (theoretical) silicon. We now state what we > see from the process control sampling over all actual process corners. > > Austin >





