A million to one may not be mainstream, but there is a lot of interest in low leakage parts where modest performance is adaquate.
Think of all those battery operated gizmos.
An AA cell is roughly 2800 mA hours. Suppose you use half the energy in idle current and the other half for real work, and want the system to run for a year on a battery. That's an idle current of 0.16 mA, for the whole system.
-- 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.
I am not arguing against Low Power. Yes, there would be a market for ultra-low-power battery-operated circuitry. But this requirement is, unfortunately, in conflict with the mainstream that cries for "cheaper, faster, and bigger (and earlier)". And the market is unmerciful... Peter Alfke ==================================
Hal,
My wife has a talking pedometer. Neat. Keeps track of distance walked or run, calories, steps, time of day. Runs on hearing aid coin cells. Batteries last about 6 months. Whoops! Bad design. Should have skipped talking feature -- too much power added to the budget.
I have a hand held radio. OK, standby current is 200 mA. Wow. Way too high. I like radios that need to be recharged less often than once a day. While transmitting, power can be as much as 2 amperes, but how much do you talk? Better design would have been an ultra low power receive mode, and leave all of the power for when you push to talk. Again, bad design.
My kids have music players. Neat. Plays music for a really long time, never worry about batteries. Good design.
Then we have a remote control (actually four of them). OK. Probably gets dropped too many times before the batteries go out. Good design.
And, of course, everyone has a cell phone. Great. In town, batteries last up to a week with occasional use. If in a rural area, the batteries drain much faster (need the RF power to get out). Good design and compromise.
Most folks have a digital camera. Varies tremendously with when you bought it. If it was one of the old ones, it ate batteries. Bad design. If it is one of the new ones, you almost do not care about batteries. Carrying around a spare battery is all you ever need, even on a week-long vacation. Good design.
All of the above devices use uPs, ASICs or ASSPs because a FPGA is not cost effective at all in these tasks (volume too large). Reprogrammability doesn't add any value to any of the products. All of these products use much older technology CMOS processes tweaked for low power (high Vt's).
So, what market even exists that needs reprogramability (as in FPGAs), AND also needs extremely low power?
It isn't that I do not believe that there are no low power applications out there, it is that I need to be told which ones they are if I am to help provide products for them.
Austin
Hal Murray wrote:
Austin, You have already given some good examples, and also undelined an important point
Here is another example of that :
Seems low power matters to Cypress, and their customers. Some small detail of saving a plug pack ?
There was another company offering a bin-selected low power device, as it seems they also have customers for whom low power matters. Who was it now ..... ah, yes, here it is ...
and it says
"While defining 'low power' is challenging, preliminary iSuppli estimates indicate that as much as $3 billion of the approximately $20 billion ASIC market could potentially shift to FPGAs if power consumption was reduced sufficiently."
Sounds plausible to me. Seems iSuppli reckons there is a $3B answer to your question above?
However it would seem there are two fundamentals against FPGAs in the chase for ASIC business. a) To compete the FPGA must be a couple of generations ahead b) They must compete on price/speed and power. Solving a) means they have moved the wrong way in leakage, so you can compete on price, and on speed, but fall rather behind on power efficency. Sure, 90nm ASICs are very expensive, but to compete with a 90nm FPGA, you do not need a 90nm ASIC. Costs at the 'back end' of 150-180nm could even drop, as flows mature, and the cost-recovery models follow the leading edge.
There are ways to balance this : eg multiple oxides are now appearing, plus a MASK variant can have many fewer transistors, and lower loading means you have spare speed to trade for power.
Also, a design can use another 'true low power' device and deploy complete power removal from the FPGA in sleep : then the comparison is [all in an ASIC] vs [PowerFrugaluC + FPGA]
This combination can make rational engineering sense, but might have problems with FPGA vendor's marketing depts, so do not expect to see it strongly promoted any time soon :)
-jg
There are several methods to reduce power by a factor of two, and there may be tricks to get if down an order of magnitude ( i.e. factor 10). But to satisfy the applications that Austin enumerated that's not enough... So something has to be sacrificed: speed, low cost, complexity, versatility, sales volume, profit (or all of the above?)
Peter Alfke ====================
Austin Lesea wrote: (snip of many low power applications)
If the logic isn't there, the applications won't be developed.
I remember being surprised some years ago when EPROMs started to be used in production devices. With the right price and convenience, they win out over masked ROMs. FPGA's have a similar advantage when the price and convenience are right.
They will be slower and smaller than the state of the art devices, but the applications will come.
-- glen
I think we are on the corner of reasonable life for many of todays toys. My digital camera with a second battery just lasts a week and is just light enough that I'm willing to carry it backpacking. Film is free. I take a lot of pictures. With a newer camera, I'd take the same number of pictures but they would have more pixels.
I should go read your marketing blurbs for a refresher. :) How many reasons aside from field reprogramability are there for using FPGAs?
How about time to market? Avoiding NRE for low and medium volumes?
Riding the bleeding edge of the technology curve probably doesn't apply if all low power chips are done with old process lines.
How old are they? What's the ballpark NRE for a design as compared to a modern process?
Is there much effort (investment) in tweaking lines for low power?
Is there a chicken-egg problem here? Of course nobody will use FPGAs in power critical applications if they all use a lot of power.
Are you still selling any 3000 or 4000 parts because they have very low idle current? How is CoolRunner doing?
If somebody put out a press release announcing a family of FPGAs emphasizing low power, I don't think I would be too surprised. I'm probably not smart enough to write it (or even an outline), but I'll bet I would recognize and go "yup" on most of the technical points. (Half would be the same old reasons for using FPGAs.)
I hang out with the ARM crowd. Lots of them in cameras and cell phones. Seems to fit well with low power applications. Ballpark is 1 mA per MIPS.
How is PowerPC for low power? Microblaze?
I could easily picture FPGAs being used next to existing uPs, either to fill out the IO options that aren't available in the normal menu or to add special IO devices.
--------
I had an interesting change of focus about a year ago. I shifted from working on a board with 3 CPUs each needing 15 amps to a battery powered board where idle current is critical. 45 amps to 45 uA. That's a factor of a million, not that it's the same problem domain as the "million" that started this discussion.
It was strange the first time I came out of the lab smiling because I had tracked down where 6 uA was going.
I used to look at data sheets and start with the nSec and MHz, then work out whatever it took to power the chips and keep them cool. Now I start looking at the leakage currents. Fingers are used to find floating inputs rather than check temperature.
That is exactly what he said, but it is not accurate.
That he did not say. Its an addition of yourself that changes the meaning of the statement quite significantly.
Please reread the post.
Peter omitted 60mA per Bank. A mistake that can happen. What I do not understand why you catagorize this as "acurate". In an idle small Spartan-3 this more than doubles the power consumption.
Kolja Sulimma
Yes, I made a mistake, and I admit it. I left out the 60 mA of current in the controller, because I did not know that. It shook me up. Honest mistake, I apologize. Peter Alfke
Pointing out the 200mW per bank DCI overhead wasn't inane before, and it's not silly now. "Small Spartan3 design" means a design that fits in a small Spartan3, not a trivial design intended to confound Austin's Nostradamus-like powers of engineering prediction.
Consulting WebPower 2.2.0, a 3S50 chock full of 50 MHz toggling flops and BRAMs with 'high' routing had an estimated total power of only 132 mW.
Also from WebPower, quiescent power for a configured FPGA in the smaller S3 family members is as follows: 3S50 : 14 mW 3S200 : 40 mW 3S400 : 67 mW 3S1000 : 99 mW
Compare those numbers to 200 mW for just one bank of DCI.
( And it's rather difficult to keep all DCI in one bank in, say, a VQ100 or TQ144 with only 6-15 I/O per bank. )
This DCI power hit is yet another reason the _DT differential terminators would have been useful in the S3 family.
Summary of errors and omissions in Austin's other post: (detailed version appended below)
Wrong.
Using FreezeDCI in the V2 affects both the behavior and repeatability (config-config & part-part) of static DCI power consumption, both for per-bank overhead, and particularly for per-input parallel terminators.
ROTFL'ingly wrong.
If it's so bloody solid, why is Xilinx STILL patching BITGEN for Virtex2 ???
Wrong, incomplete, and misleading.
Read where? In the two Answer Records that mention the bank-bank DC offset ?
And then only if their psychic powers prompted them to search the Answer Records for an obscure invented term like "FreezeDCI" before starting a design?
Brian
Detailed version:
( My references to documentation omissions are based on my last thorough search in Fall 2003; if Xilinx has updated any DCI related documents since then, feel free to point them out )
Wrong.
Using FreezeDCI in the V2 affects both the behavior and repeatability (config-config & part-part) of static DCI power consumption, both for per-bank overhead, and particularly for per-input parallel terminators power.
FreezeDCI waits long enough after configuration for each bank to have adjusted, then asynchronously halts the DCI bank logic in the midst of whatever it was doing.
As each bank has its' own independent CCLK type oscillator driving the tap adjustments, you end up with a random sampling of the possible DCI adjustment states for each bank.
Worst case for the per-bank overhead is when the bank adjust randomly stops at the R/2 setting, which burns the most power in the VRP/VRN circuit.
Worst case for the per-input parallel terminators is when a bank update stops during the active adjustment state for the parallel termination standard in use, during a 20% low adjustment excursion of the impedance tap setting (20% for 2R, 10% for R).
As the V2 control logic drags all the terminators in the bank along with it during its' bump up/bump down adjustment tests, this means that all the parallel input terminators in that bank are now 20% low, and burning 20% more power than usual.
Each configuration rolls the dice for each DCI bank, and sometimes more than one will come up on the worst case setting...
As I understood it, the newer devices having DCIUpdateMode were going to cleanly stop the DCI updates in all banks at a known state rather than randomly halting them as with FreezeDCI.
ROTFL'ingly wrong.
If it's so bloody solid, why is Xilinx STILL patching BITGEN for Virtex2 ???
When is Xilinx going to publish a detailed description of the DCI modulation problems, other than the passing mention in the "AM modulation" Answer Record #13012 ?
( News Flash: on August 5 2004, #13012 was updated with a brief description of the cause of the DCI modulation problem, along with two LVDS_25_DCI scope plots that look amazingly similar to the ones I sent to Xilinx way back in ~Dec 2002 )
Where is the characterization data bounding the worst case magnitude of the DCI impedance modulation for each standard ?
Has the peak magnitude of this impedance modulation been reduced in the V2Pro and S3 families when DCIUpdateMode=Continuous|AsNeeded ?
Where is the worst case power consumption data for V2 DCI when FreezeDCI (now automagically enabled in BITGEN 6.x) is turned on ?
Where is the complete list of FreezeDCI side effects ?
Wrong, incomplete, and misleading.
AFAIK, with FreezeDCI off, the DCI control logic continuously modulates the bank impedance for both series and parallel DCI termination, be they in one or several banks, although it's certainly easier to spot for the parallel terminators because of the readily visible modulation of the DC offset voltage.
It's important to note that the behavior of a random, asynchronous, high rate impedance modulation is completely different than that of a static impedance mismatch.
I'd hesitate to use the series terminated DCI for anything but low rate data lines with the DCI modulation present: an asynchronous series DCI impedance change coincident with an outgoing edge on a series terminated clock/strobe line could create a non-monotonic edge as well as a timing push-out.
On the other hand, with FreezeDCI on, the resulting random DC offset for the parallel terminators will probably cause problems for the single ended standards with accurate terminator VTT requirements (whether in one or multiple banks).
Does the 'clean halt' of the newer parts' DCIupdateMode=Quiet setting reduce the magnitude of the bank-bank DC offsets?
Read where? In the two Answer Records that mention the bank-bank DC offset ?
And then only if their pyschic powers prompted them to search the Answer Records for an obscure invented term like "FreezeDCI" before starting a design?
The only hint of DCI problems in the latest V2 user manual (UG002 v1.7) is this gem of understatement from page 201:
"If users do not want to have the second phase enabled, they should use the FreezeDCI option in BitGen"
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.