Low-power FPGAs?

Jim,

Vccaux is required, as is Vcco for the config bank.

There is the Power On Reset control circuit wired to these three supply sources. If the POR trips going low, then memory is zeroized when POR comes back up (On).

The static Icco is pretty low, I think less than 2 mA per bank (at 3.3V, less at a lower Vcco). Still gathering data on that for the data sheet.

The proposal I heard (from one engineer) was to run all LVDS IO, with a few 2.5 V 2 mA CMOS single ended IOs for things like LEDs, switches, slow peripherals (like the power controller).

Turns out that LVDS IOs are constant 4mA each (hi or lo), so single ended IOs would be much more efficient (but slower).

The idea was to also go to the abs min voltages allowed for the sleep mode (e.g 1.0V), and the recommended mins for operation.

If that did not do it, they wanted to know if we would consider a test program to verify even lower sleep and operating voltages.

Good news is that the V4 is the most CMOS'sy chip we have had in awhile

-- it really works well at lower voltages int eh interconnect, CLB and other simple functions. The complex functions (MGT, DCM, PPC) are not likely to be as forgiving if run out of spec.

As I said before, test programs are just money, so if it is worthwhile, then it is considered. We just need to be sure that we can yield reliably to the screen, and it makes business sense to do it. It would not do anyone any good if the screen suddenly stopped yielding any parts due to a small process shift. Such screens are never entered into lightly, and require a great deal of work (hence the reason why there is usually a large volume involved).

Often as we gain more data from a new part, we may change specifications (expand the operating ranges, speed up paths, etc.) so we will have to wait.

Austin

Jim Granville wrote:

Hi Simon, A few comments included below, but do we agree that saying "FPGA's by their very nature are low power.. provided you don't clock them fast." is somewhat misleading? Cheers, Syms.

The V2PRO I mentioned doesn't have a PowerPC, but anyway I'd question whether V2PRO is bleeding edge. (Bleeding irritating, maybe!) Anyway, even small plain old Virtex (50mA) and SpartanIIe (200mA) suffer from this Iccintq problem. I'll check out the A parts, thanks for the pointer.

uA

Sounds like a good solution.

down

So, if the CPLD/FPGA you're powering down has live inputs from other places, won't these inputs back power the part through the protection diodes? So, the inputs have to be off too?

You bad boy! I'd never do that. (= I'd never admit to doing that!) ;-)

What do you mean by better? Price? Also, Lion and NiMH have the same(ish) volumetric energy density. Are Lions better over temperature? Is self discharge better in Lions? (Sounds like a sticky mess in the Serengeti!)

side

I thought these special NiCds were high power cells, not high energy?

Which is why it has the same(ish) energy storage as a NiMH D cell! 6.5Ah @

1.2V.

cell.

they?

'max'

Power of VccAux ? Are you saying Non-config banks can be Vcco removed, if desired ? [eg a DRAM interface could de-power the DRAMS, and their Banks ?]

This is sounding a good direction, similar to Mobile Pentiums/Athlons. There are SMPS devices with quite wide binary control of Vout, designed for the CPU markets.

Also, devices like the new LTC6905

also has power-save promise, by clock-vary 17:170MHz at reasonably low power levels.

Most small micropower uC have clock-out options, that can also be used if some portion of the FPGA needs to 'tick-over' - I think from what you are saying, that the complex blocks, DLLs etc do not work as low as the logic fabric, and config SRAMs - so something like an LCD interface, or a keypad scan could run at < 1MHz at the lower Vccs ? [ that would allow users to choose between a really small uC, and some sytem IO in the FPGA, or a larger uC with more pins, and more agressive power-removals on the FPGA. ]

-jg

Jim,

Yes, if all you want to do is 'sleep', you can remove power from the Vcco banks other than the one with the POR circuit on it.

The intrinsic protection diodes are always there, so if other circuits are powered, you may end up powering the Vcco of the banks through the diodes.

Austin

Jim Granville wrote:

I probably am misleading some what... but experience for a typical design is FPGA's don't consume much. they are usually the lowest power consumer on my designs. but done right.... An FPGA will draw less power than a micro doing the same thing. the last card had a dynamic current in the FPGA of about 8 mA (excluding I/O) that's according the power calculator and the interface it connected to could draw 2amps. I don't think that's too bad.

And I usually do design to the spec... we rate our radios from -10C to +65C and aren't allowed more than 2 'noise' hits over a temperature cycle. But for a piece of test gear sitting on a bench.. I think you can go slightly wild and limit the temperature range... unless you going to sit it in a shed in a desert... which I doubt.

I saw your battery... not bad... but usually higher voltages win out over higher amp-hour... at low voltages the switcher losses become silicon volt drop related. If you look at Maxium you will see they quite often invert the voltage and then switch up from the sum of the voltages to get the efficiency up when working with low voltages.

Am glad you like the Q FPGA. I came across it while helping design a satellite here. Its fuse link, no free tools, no free programmer... so I would defiantly prototype with something else until you can be assured of it working.

For driving a FPGA from a CPLD.. you might need an interface IC in between. There are a number of logic families that support hot-swap which should stop any current draw when the chip is in power down.. failing that.. 10k resisters are pretty good too :-) Or you could make sure all devices drive the FPGA with a low by default... then there is no power for the protection diodes to suck :-)

Simon

their

somewhat

part'

seem

cheated

250

coolrunner

you

places,

running

20C

that

bigger

Simon, I saw this article and thought of our musings about low power stuff!

"Royal Philips Electronics? Handshake Solutions and ARM today said they have jointly developed a clockless, compact ARM processor to addresses (sic) low power consumption" It's based on this stuff I wonder if self-timed circuits will come to the FPGA world soon? A whole new level of pain! Best, Syms.

Interesting - Philips have been doing Async logic for a while, including Async 80C51 variants, and have the important tools needed to design in this area.

Advantages are self-tracking of temp and Vcc, allowing wider operating tolerance. Power numbers I've seen for their earlier devices were good, but not stellar, but did improve rapidly as Vcc decreased. FPGAs could use this, with the right tools.

-jg

Hi Jim, Indeed, looks like some folks are thinking about this in FPGAs already. Check out

etc.... Cheers, Syms.

There is an art to reading between the lines on a data sheet. Or maybe knowing which lines you can read between.

If leakage current is critical, the difference between a warm room and 85C or 100C is huge. Consider the CPU in the remote control for your TV. What's its temperature? Are you going to compute battery life based on storing it in an oven?

If you are only buying a few chips, you can measure them yourself. If you are placing a big order, you can get lots of help from FAEs.

A few generations ago, it used to be common to fudge ratings by "correcting" for VCC and temperature. If you were willing to work a bit harder on your power supply, say promise it won't go below nominal, then you could pick up 5% on speed. Old Xilinx data books had a nice writeup. I'm pretty sure DEC did that with their high end Alphas.

Then the silicon wizards made things more complicated. I don't understand the details but I'll bet it's an interesting story.

I think the simple exponential temperature correction still holds for leakage current. Can anybody confirm that? (Any predictions on when that will break? Why?)

--
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 have thought about this a bit and I don't see how any of this is an advantage. If you are doing real time work, even if it is not demanding, you have to meet a timing schedule. Although the async sequential devices are self timed and won't stop working from failing to meet setup and/or hold times on the FFs, if the device slows down, it will fail to meet the requirements of the application. If you app can tolerate a slow down of X% which allows the async logic to work over temp, then you could likewise run the sync logic at a slower clock and still meet the same system requirements over temp and voltage.

So how is the async logic really better? You still have to make sure the device meets your timing constraints. The async logic just pushes it to a system timing problem rather than a low level timing problem.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Rick, I think the advantage is that the circuit goes as fast as it can for the given voltage/temperature conditions. So, for example, if you're running a cpu flatout to do some task, it'll finish faster if it's cooler. Like you, I'm struggling to see why it's necessarily lower power. Presumably the same number of nodes flip-flop during a logic algorithm in async or sync logic. Also, the clock distribution is saved, but replaced by a whole bunch of handshake lines. Just found this, some bloke at Intel doesn't think async design is a good idea:-

Cheers, Syms.

There are some FPGA examples at

You are broadly correct tho, no system is truly 'clockless', and so at some stage you need to know that your Async core _did_ complete the branch or thread or interrupt, within some system limit.

Where Async can help, is in being more generally spread spectrum, ( so improves EMI ), and in having an automatic IDLE mode: When the Sw completes, it can stop. Of course, a std uC can come close to the same with HW IDLE control, and there are now many Spread spectrum clock generators.

Downsides are: your core speed is now very elastic, and so cannot be used for software timing, plus faster clocked peripherals and interrupt type flags that can be dual port in nature (SW & HW access) must get very tricky to prove. On a system that had such a bug, it would be very enviroment sensitive.

The biggest gain I can see from Async, is it (should?) self-track Vcc/Temperature/Process. Of these, Wide Vcc operation is likely to give the most user benefit. In a Sync system you may have 50- >100% margin by the time you apply Voltage/Temp/Process corners : In an Async system, that margin is available for extended battery life.

-jg

I saw the same posting too..

Self timed IC's tend to reduce power in several ways... for starts the peak is lower.. as nothing switches at the same time :-) second.. only the circuit active is running.. the next step is still idle the last step is now idle. The tend is to then be either idle or running.. not 'clocked and waiting'. Third.. the ripple effect... as each stage runs as fast as it wants/needs, things which would gobble time doing nothing, now take next to no time to do, so simple instructions process faster, and overall, the 'speed' can decrease.. or at least .. spend more time doing nothing as speed assumes a clock ;-)

That's suppose to be good for a 30 % power drop. That's according to the thesis I read a few months back. The problem is, of course, the more you get the chip to do.. the less the power saving. Look at a hyper threading P4 for example.. all that silicon not doing anything until you hyper thread.. and then consume another 10 watts

The classic example of this is a MOVE to register instruction in a processor... If a standard FPGA or processor, you would setup the address, read, write, allocate a bus, and on the next clock edge, execute a simultaneous read and write, now the whole chip sees this read and write.. and everything else decides its not for them. In an Async system, the MOVE sets up a async path between the register and the memory... everything else is still idle or doing something else (thru other async paths) and the memory and register do the data transfer between themselves nothing else knows / cares Sounds simple .. but they've been working on this for 10 years. I think because when things go wrong.. the system turns to custard, simulation requires specialist tools... you can't prototype in a FPGA either.

From what I understand... there are a few MP3 players (?) also using async clocks to reduce overall power wasted or at least in the process.

Simon

rid=1090846109

have

low

df

whole

Huh? Why does one use more battery than the other?

Power depends upon the work you do, not how fast you do it.

I'm assuming both systems go to sleep when the don't have anything to do. In the sync case, you picked the clock so that the work gets done in time (with some slop for adding features?) and designed the system so it runs that fast in worst case conditions.

With the async system, you figured out how many cycles you needed, added slop, then engineered the system so that it would get done soon enough when it was running hot and such. Same general worst-case idea, just turned inside out.

I admit I've never designed an async system. You need something like that in the data sheet in ordr to build auseful systems. Right?

--
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.

Yes, but the Async allows you to vary the Vcc, and the chip runs as fast as possible at that Vcc.Temp, then your P = K.F.V^2 works in your favour. Devices such as FLASH where the Active I/F curve does not pass thru the origin, also benefit from less ON time.

Armed with a full Speed/Vcc curve from a precise data sheet, plus on chip temperature sense, and variable supply, and you can get almost the same thing from a Sync design, and that's how many MobileCPUs work. However, they are more the exception, and most small uC, and FPGAs are not specified to that detail.

One could design a FPGA system for min possible power, using TempSense, Variable Vcc, and a small Async block whose task was to provide either the main clock, or a reality check of the scalable-clock.

-jg

But most sw never completes. The program typically runs in a loop waiting for something to do. The async CPU is no different. You can use a HALT or IDLE instruction, but that is what they do on sync logic CPUs.

See, great minds think alike... ;)

Now that is something I can understand. Right now the best you can do is reduce clock speed, which many power sensitive systems use. In the async system you can also cut voltage saving power by the square of voltage. But couldn't you do that in a sync system as well? A lot of the low power CPUs, PICs for one (or is that millions?) spec the chip to run at one range of speeds for a higher voltage and a lesser range of speeds at a lesser voltage. So these CPUs could also save power by cutting their own voltage and running slower.

Oh, the margin is no more available in async parts. They have to run a handshake clock between circuits that is assured to be slower than the logic path. Don't you think they put a lot of margin into that difference? In fact, when running hot at low voltage, I bet the margin is a lot less with sync parts.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Is the smily indicating a joke? That doesn't save power, right?

If you have separately clocked circuits, that is like pipelining. Why wouldn't you run them in parallel? If you take out the pipeline registers, you will not use any more power and you will make the circuit smaller.

In a sync design the circuits are balanced since they all run together. Of course this is never perfect. But this way things can run in parallel and stay in step. In an async circuit you would have to have traffic cops directing results based on availability at a very low level. That would add a lot of logic.

But logic that is not being used in a sync design may be clocked, but it uses far less power than if it were actually working. I still don't see the power savings. To some extent, this is comparing apples to oranges since the two methods will use very different design techniques. I think if you were designing a CPU from scratch you would not even have the same instruction sets for the two designs.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

peak

Well, I think he's trying to say the instantaneous power peak is less for async. In a sync circuit, most of the energy is consumed at the clock switching edge. So, the power during the tiny moment of that switch is enormous, compared to the average power. For async, the transitions are spread out, as they're delayed in time from one another. This also relates to the lower EMI thing mentioned in this thread. Cheers, Syms. p.s. Good points in the rest of your post, Rick.