Spartan 3 termination question (DCI)

[Hal Murray]

Modern high-performance sub-150 nm conventional CMOS technology has leakage
currents that make that goal unattainable (by a long shot).
Such a requirement is not mainstream...

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.

 

[Peter Alfke]

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

From: hmurray@suespammers.org (Hal Murray)
Newsgroups: comp.arch.fpga
Date: Tue, 20 Jul 2004 12:08:48 -0500
Subject: Re: Spartan 3 termination question (DCI)

Modern high-performance sub-150 nm conventional CMOS technology has leakage
currents that make that goal unattainable (by a long shot).
Such a requirement is not mainstream...

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.

 

[Austin Lesea]

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:

Modern high-performance sub-150 nm conventional CMOS technology has leakage
currents that make that goal unattainable (by a long shot).
Such a requirement is not mainstream...


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.

 

[Jim Granville]

Peter Alfke wrote:

Modern high-performance sub-150 nm conventional CMOS technology has
leakage currents that make that goal unattainable (by a long shot).
Such a requirement is not mainstream...
Austin Lesea wrote:
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

Austin,
You have already given some good examples, and also undelined an
important point
* First generation designs only have to work, second generation designs
need to work properly *

Here is another example of that :

http://www.cypress.com/aboutus/press_release.cfm?objectid=B02B0D86-03E0-4485-945E4304605236AE

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

http://www.xilinx.com/prs_rls/silicon_spart/0478s3lp.htm

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

 

[Peter Alfke]

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

From: Jim Granville <no.spam@designtools.co.nz
Organization: TelstraClear
Newsgroups: comp.arch.fpga
Date: Wed, 21 Jul 2004 10:26:14 +1200
Subject: Re: Low Power Applications - enumerate

Peter Alfke wrote:
Modern high-performance sub-150 nm conventional CMOS technology has
leakage currents that make that goal unattainable (by a long shot).
Such a requirement is not mainstream...
Austin Lesea wrote:
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

Austin,
You have already given some good examples, and also undelined an
important point
* First generation designs only have to work, second generation designs
need to work properly *

Here is another example of that :

http://www.cypress.com/aboutus/press_release.cfm?objectid=B02B0D86-03E0-4485-9
45E4304605236AE

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

http://www.xilinx.com/prs_rls/silicon_spart/0478s3lp.htm

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

 

[glen herrmannsfeldt]

Austin Lesea wrote:
(snip of many low power applications)

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.

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

 

[Hal Murray]

[good list of battery powered toys snipped]

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.

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?

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?

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.

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.

 

[Kolja Sulimma]

Austin Lesea <austin@xilinx.com> wrote in message news:<cd66h7$47j1@cliff.xsj.xilinx.com>...

Peter's comment is perfectly accurate: series terminations dissipate
virtually no power
That is exactly what he said, but it is not accurate.

in the series termination resistors.
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

 

[Peter Alfke]

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

From: news@sulimma.de (Kolja Sulimma)
Organization: http://groups.google.com
Newsgroups: comp.arch.fpga
Date: 21 Jul 2004 05:09:59 -0700
Subject: Re: Spartan 3 termination question (DCI)

Austin Lesea <austin@xilinx.com> wrote in message
news:<cd66h7$47j1@cliff.xsj.xilinx.com>...

Peter's comment is perfectly accurate: series terminations dissipate
virtually no power
That is exactly what he said, but it is not accurate.

in the series termination resistors.
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

 

[Brian Davis]

Austin "Sooooo much current" Lesea wrote:

But really, I was offended by the silly response, talking about
applications that have 'no power' where DCI is all of the power.

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.

In the absence of a VRP/VRN shutdown mechanism, disconnecting
the VRP/VRN resistors with a timed external analog switch after
configuration may work, depends upon whether the bank control
logic would be upset with the vanishing resistors in the
DCIUpdateMode=Quiet mode.

Earlier on in the thread, Austin wrote:

I would appreciate it if you did detail every single omission,
distortion, or mis-representation.

Summary of errors and omissions in Austin's other post:

(detailed version appended below)

Freeze DCI has nothing to do with it.

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.

From the first appearance of DCI in Virtex II, it has been a
solid feature in every device since.

ROTFL'ingly wrong.

If it's so bloody solid, why is Xilinx STILL patching BITGEN
for Virtex2 ???

DCI updating is only an issue when you cross between two banks,
and even then only with the parallel interfaces where it adds
some small amount of jitter.

Wrong, incomplete, and misleading.

Freezing the updates allowed customers who did not read that
they should not go across banks

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 )

Freeze DCI has nothing to do with it.

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.

From the first appearance of DCI in Virtex II, it has been a
solid feature in every device since.

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 ?

DCI updating is only an issue when you cross between two banks,
and even then only with the parallel interfaces where it adds
some small amount of jitter.

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?

Freezing the updates allowed customers who did not read that
they should not go across banks

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"