Xilinx FPGAs in battery-powered scenarios

Manny schrieb:

I was considering V4 lately for portable battery powered gadget and did not see it feasible (different reasons).

for you it all depends

1) how much battery power you have 2) what else except FPGA takes power 3) required battery operation time 4) what FPGA is doing

the best for battery is V4-FX12 when used with PPC (less power than MB!) every other Virtex4 or Virtex5 means more static power to the extent that it drains the battery on static current only!

smallest power an V4FX12 based system takes is about 1W so if your battery has 3w/hr then it will operate 3 hours.

pricing - thumb guess ia that if you are would be able to get prices below 70USD you would not be asking. So expect pricing between 70 and

100

Antti

Manny, here would be my order of concern:

1. How much, and what type of, logic do I need
2. How fast should it run (can I time-division multiplex?)
3. What is the smallest and cheapest device that fits those requirements
4. How much power does it draw while working, and in stand-by
5. > Hey,

Keep in mind that non-nuclear submarines are run on batteries and they tend to use significantly more power than a Virtex-4. What you're willing to use for batteries will determine whether you can achieve your goals.

It seems that increasing battery technology has a practical upper limit for ultra-portables. If you have a battery-powered cell phone, running 60 watts through the device would make it unusuable because of the heat genereated in the confined footprint. If you're not going for ultra-portable or single AA-cell powered devices, your options are wide open. Consider that a small Virtex-4 has lower power requirements than the laptop's processor alone.

Manny,

Just one comment:

There has been no "in rush" or "bonus" current needed since Virtex II (V2, V2P, V4, V5 have no "inrush" for Vccint, the datasheet specifies the minimum Iccint required to power on and configure).

What you describe was common for Virtex E, and older families. However, we decided that was unacceptable, so we fixed it (a long time ago, now).

Aust> Hey,

Manny,

Further:

It seems that GD has selected V4 for a software defined radio, and it is portable (battery operated).

One nice thing about a radio application is that it is not operating continuously (as they are shooting at one another on the battlefield).

Another useful element of the JTRS SDR radio is that is does not even load the configuration for a particular modulator or demodulator until it receives, or wishes to transmit in that mode. Only one "waveform" is ever active at a time, and only as transmit, or as receive, and other than that, the FPGA is (probably) powered down and waiting.

(I profusely apologize for any marketing contained in this posting: any such marketing content should be considered as such, and treated accordingly.)

Austin

Manny wrote:

Thanks a lot guys, all comments are really useful and I'm definitely gonna reason much about them.

My application is definitely gonna be DSP intensive. The bad news is that it's basically a CDMA application so many things have to run in parallel in a multiple access system, the more things can run in parallel the more robust the model is and thus yielding in terms of performance. The good news is that we'r not talking about RF signals in here, so things doesn't need to run real fast. My major concern is that things are quite coupled at the moment i.e. lots of things depends on stuff that are yet to be fully characterized. As we might have settle for less perfect hardware (not talking digital in here), our model would grow more complicated as to accommodate for these imperfections. The online reconfigurability of the system is also highly desirable as functionality can change in time. So a CPLD won't do, not even a low-cost spartan although ultimately we might have to sacrafice reconfgurability. The only bright side in this mess is that I might be able to argue, once the system has been fully developed, that certain functionalities have to be ported to ASIC. I'm keen on having as much DSP power as possible as there are advanced issue on the agenda such as Doppler Effective and AOA estimation. So there is no doubt that I'll end up time sharing the available DSP slices. For prototyping, I think it always make sense to get a bit more than what you expect to use. Virtex-4 FX12 seems a reasonable start with the open possiblity to migrate to V-5 once the rest of the family is introduced.

Cheers,

-Manny

Austin Lesea schrieb:

Austin,

please check Xilinx publication EN049(v 1.3) page 2 for Virtex-5 power requirements during configuration

Antti

Antti,

We are still characterizing the parts and process, so we don't want to put anything in the data sheet for V5 until we are done.

But, there is no surge, or big Iccint that is required for V5...

Austin

Antti wrote:

You said Xilinx fpga, but maybe actel's eeprom (?) based fpgas will do better for battery applications?

Hi Manny, You may also want to consider the Virtex-4 SX25. The DSP slice burns just 2.3mW/100MHz dynamic power - so for a computation intensive low power application - this may be a good fit. The SX25 has 128 DSP slices where as the FX12 has 32. The SX25 has twice the logic cells and twice the static power as the FX12 though.

If you can tolerate the power - you then have a migration path to the Virtex-4 SX35 if you need more computation bandwidth later.

If you want to estimate the power consumption before you start your design, you can use the XPower Estimator spreadsheet located at:

This way you can get an idea of how Spartan-3E, Virtex4 and Virtex5 will compare for power for your particular application.

- Vic

Manny wrote:

Sounds like I have a similar application. I am trying to make a go of it with V4 FX12. My budget is 2W as we use camcorder batteries with ~30 Whr capacity in our system. I'd be interested in even lower power but it sounds like V5 is no help as the ads conspicuously stress lower DYNAMIC power. I think I burn 1W when the fpga is unconfigured, but I'm not sure that is all in the FPGA. I've put in provisions to shut down entirely until wakened by USB or serial activity but I've not integrated it yet.

If you get any reliable info on the V5 power situation, better batteries, or ways to improve the V4 consumption please post.

Thanks, Clark

That may be, but configuration takes a significant amount of time and energy to complete. This needs to be considered in any model that powers the parts down to conserve energy. The duration of the power down needs to be long enough to pay for the reconfiguration. Even some of the Flash based devices have this concern since they use internal Flash as a backup to an SRAM FPGA. Aren't the Coolrunner II parts like that as well? Although I am sure the CR II parts have a very low configuration energy.

Aust> Antti,

do better

Rick,

Configuration does not require a "significant amount of energy."

Not sure where you got that.

Austin

What exactly does "significant amount of energy" mean to you? In some contexts, the energy to configure certainly would be significant. If it takes 100 ms to configure and the running time is 10 ms, then configuration can clearly be very significant.

Of course, if once configured, the FPGA runs for an hour doing very power intensive work the configuration energy is not significant. But then that would not be likely running on a battery, would it?

I simply meant that the configuration engery is enough that you need to consider it in context, which I don't think you can argue with.

He means that during config, there are many clock-buffers active as the whole device configs. Thus config power is certainly likely to be higher than static power, and will also likely be higher than locally clocked functions, with Fclk 200MHz all the time!

eg I have a Flash-RAM CPLD here, that is appx 200x more Icc during Config load, than static icc. To me, that certainly IS significant.

Sure, config does not last long, but you still have to allow for it.

That is why you need to decide if (frequent) reloads are worth the gains.

Now, a vendor that usderstood this, would put this information in the datasheets, so their customers would be able to make the right design decisions.

-jg

Rick,

-snip-

In this case, if the minimum current required to configure is 200 mA, the current when doing nothing is 100 mA, and the design uses 1000 mA when running, then "significant" is pretty small (100 mA or less).

In some

Time, yes, but energy, perhaps not?

In my example above, it still doesn't matter.

Nope. No argument. It is all in the numbers.

Look at the quiescent current, and the min current to configure, and note the delta difference for the part. If that delta is a significant part of the current for the application, then you are correct. If it is not, then it is not an issue.

In

pages 5,6,7 the lx60 is 167 mA typical quiescent, and 300 mA typical to configure (actually, to completely power on, clean out and configure).

Re-configuration, while the rest of the device is running, should be even less than the min current required, so I am somewhat baffled that you think that this (300-167mA) represents a "significant" amount.

Now, if the design takes 200 mA after it is programmed, in addition to the quiescent, then you are absolutely correct: that would be "significant."

I suppose that if you have to size the battery, then any extra current could be "significant."

Austin

Thanks for recognizing this. If an engineer is considering a situation where a one-week runtime of continuous power-up, run, power-down is desired, every power number and duration in that sequence is part of the overall budget. This is, perhaps, where some engineers are more sensitive than others.

I love the idea of a keychain-type device that can do an interesting amount of RF work in tiny bursts but I haven't been brave enough to step into the power analysis to realize the system. I love FPGAs but I recognize there are some things I won't be able to accomplish with them given the realities of the task and silicon at hand.