5V I/O with 1.8V Core

[Jim Granville]

Following the recurring thread of 5V IO,
the loss thereof, and 'the price of progress', here are some
of the newest numbers from the uC industry :

Philips LPC2129 Spartan IIE
General 256KF/ARM Advanced FPGA

Vcore 1.8V 1.8V
Vio <5.5V <3.6V
Icctyp 10uA 10mA
IccMAX <500uA <200mA

Icc numbers are Static, ie represent standby power levels.
FPGA of similar core Vcc is chosen, and smallest IIe device is chosen
to avoid too much die-area skew effect.
-jg

 

[Symon]

"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:CXvwb.9478$ws.845858@news02.tsnz.net...

Following the recurring thread of 5V IO,
the loss thereof, and 'the price of progress', here are some
of the newest numbers from the uC industry :

Philips LPC2129 Spartan IIE
General 256KF/ARM Advanced FPGA

Vcore 1.8V 1.8V
Vio <5.5V <3.6V
Icctyp 10uA 10mA
IccMAX <500uA <200mA

Icc numbers are Static, ie represent standby power levels.
FPGA of similar core Vcc is chosen, and smallest IIe device is chosen
to avoid too much die-area skew effect.
-jg

Hi Jim,
I haven't used this Philips part but, just so I know you're not
comparing apple and oranges, this Philips part supports upteen different
I/O standards? From 3.3V LVTTL to 2.5V LVDS at 622M?
cheers, Syms

 

[Jim Granville]

"Symon" wrote

"Jim Granville" wrote
Following the recurring thread of 5V IO,
the loss thereof, and 'the price of progress', here are some
of the newest numbers from the uC industry :

Philips LPC2129 Spartan IIE
General 256KF/ARM Advanced FPGA

Vcore 1.8V 1.8V
Vio <5.5V <3.6V
Icctyp 10uA 10mA
IccMAX <500uA <200mA

Icc numbers are Static, ie represent standby power levels.
FPGA of similar core Vcc is chosen, and smallest IIe device is chosen
to avoid too much die-area skew effect.
-jg

Hi Jim,
I haven't used this Philips part but, just so I know you're not
comparing apple and oranges, this Philips part supports upteen different
I/O standards? From 3.3V LVTTL to 2.5V LVDS at 622M?
cheers, Syms

Sorry if this was not clear - this is from the uC industry, so it is
comparing
'like process' capability (~ 0.18u) - what the silicon DOES is, of course,
quite different.
However, the fundamentals like IO and leakage are a bit more portable and
it's
good to compare real numbers when a vendor claims some 'spec erosion' is
the 'price of progress' - implication: 'We couldn't do anything about
that'.

-jg

 

[Austin Lesea]

The SIIE is a .15u process shrink.

Austin

Jim Granville wrote:

"Symon" wrote

"Jim Granville" wrote

Following the recurring thread of 5V IO,
the loss thereof, and 'the price of progress', here are some
of the newest numbers from the uC industry :

Philips LPC2129 Spartan IIE
General 256KF/ARM Advanced FPGA

Vcore 1.8V 1.8V
Vio <5.5V <3.6V
Icctyp 10uA 10mA
IccMAX <500uA <200mA

Icc numbers are Static, ie represent standby power levels.
FPGA of similar core Vcc is chosen, and smallest IIe device is chosen
to avoid too much die-area skew effect.
-jg

Hi Jim,
I haven't used this Philips part but, just so I know you're not
comparing apple and oranges, this Philips part supports upteen different
I/O standards? From 3.3V LVTTL to 2.5V LVDS at 622M?
cheers, Syms


Sorry if this was not clear - this is from the uC industry, so it is
comparing
'like process' capability (~ 0.18u) - what the silicon DOES is, of course,
quite different.
However, the fundamentals like IO and leakage are a bit more portable and
it's
good to compare real numbers when a vendor claims some 'spec erosion' is
the 'price of progress' - implication: 'We couldn't do anything about
that'.

-jg

 

[Nicholas C. Weaver]

In article <CXvwb.9478$ws.845858@news02.tsnz.net>,
Jim Granville <no.spam@designtools.co.nz> wrote:

Following the recurring thread of 5V IO,
the loss thereof, and 'the price of progress', here are some
of the newest numbers from the uC industry :

Philips LPC2129 Spartan IIE
General 256KF/ARM Advanced FPGA

Vcore 1.8V 1.8V
Vio <5.5V <3.6V
Icctyp 10uA 10mA
IccMAX <500uA <200mA

Icc numbers are Static, ie represent standby power levels.
FPGA of similar core Vcc is chosen, and smallest IIe device is chosen
to avoid too much die-area skew effect.

A: Even a small FPGA has so many config bits and active gates that
static leakage becomes vastly significant, while the Phillips part has
only 16KB of SRAM (most of the storage is flash).

B: There is a tradeoff between static leakage and performance. A
4-stage CPU pipeline with a max frequency of 60 MHz is incredibly
biased towards low power & very low leakage, not high performance.
Heck, the LEON sparc core in the .25 micron FPGAs will run at ~30+
MHz, and thats a fully synthesized, no optimization at all design!

C: Biasing towards lower leakage also allows higher Vio, as now you
have thicker oxide layers.
--
Nicholas C. Weaver nweaver@cs.berkeley.edu

 

[Jim Granville]

"Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message
news:bq01k6$29db$1@agate.berkeley.edu...

In article <CXvwb.9478$ws.845858@news02.tsnz.net>,
Jim Granville <no.spam@designtools.co.nz> wrote:
Following the recurring thread of 5V IO,
the loss thereof, and 'the price of progress', here are some
of the newest numbers from the uC industry :

Philips LPC2129 Spartan IIE
General 256KF/ARM Advanced FPGA

Vcore 1.8V 1.8V
Vio <5.5V <3.6V
Icctyp 10uA 10mA
IccMAX <500uA <200mA

Icc numbers are Static, ie represent standby power levels.
FPGA of similar core Vcc is chosen, and smallest IIe device is chosen
to avoid too much die-area skew effect.

A: Even a small FPGA has so many config bits and active gates that
static leakage becomes vastly significant, while the Phillips part has
only 16KB of SRAM (most of the storage is flash).

Not sure I follow this. Are you saying only SRAM determines leakage ?
I would have expected the total CMOS P-N pairs to determine leakage,
and that should be largely die area proportional (with possible factors
of Vcc disable of whole blocks, if that is done )

B: There is a tradeoff between static leakage and performance. A
4-stage CPU pipeline with a max frequency of 60 MHz is incredibly
biased towards low power & very low leakage, not high performance.
Heck, the LEON sparc core in the .25 micron FPGAs will run at ~30+
MHz, and thats a fully synthesized, no optimization at all design!

I think the 60MHz is dictated primarily by FLASH access, and that
speed, inclusive of flash, is at the 'high performance' end for uC.

C: Biasing towards lower leakage also allows higher Vio, as now you
have thicker oxide layers.

To say it is a trade-off is correct.
It it becomming is more common to see variable oxide process offered
- it could well be being done now, in FPGAs to give 3.6IO on 1V cores.

The point I am illustrating is that FPGAs have made impressive strides
in Speed, and features/dollar over the last 5 years, but that has come at
some other performance cost and compromise.
If they really want FPGAs to replace ASICs, or FPGA cores to expand
markets, that will be the next focus.

Intel is a putting a LOT of R&D into leakage control, as they realise it is
restricting their expansion and deployment.

Seems a natural 'next step' for (eg) Xilinx to take their 90nm Spartan-3
devices,
and tune for leakage first, and speed second.
Same tools, very largely the same mask sets, but new customers - those who
would look at 200mA max, 10mA typ and say 'pity, could have used that..'

-jg

 

[Austin Lesea]

Jim,

The big question is: "would anyone want to pay for a FPGA that is 1/2
the speed but 1/10 the leakage?"

As for Intel, great PR, but they have absolutely no way that they have
announced to reduce drain source leakage. That big PR splash was for
"gate leakage" which is a small problem today. THE problem today
however is drain source leakage.

Austin

Jim Granville wrote:

"Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message
news:bq01k6$29db$1@agate.berkeley.edu...

In article <CXvwb.9478$ws.845858@news02.tsnz.net>,
Jim Granville <no.spam@designtools.co.nz> wrote:

Following the recurring thread of 5V IO,
the loss thereof, and 'the price of progress', here are some
of the newest numbers from the uC industry :

Philips LPC2129 Spartan IIE
General 256KF/ARM Advanced FPGA

Vcore 1.8V 1.8V
Vio <5.5V <3.6V
Icctyp 10uA 10mA
IccMAX <500uA <200mA

Icc numbers are Static, ie represent standby power levels.
FPGA of similar core Vcc is chosen, and smallest IIe device is chosen
to avoid too much die-area skew effect.

A: Even a small FPGA has so many config bits and active gates that
static leakage becomes vastly significant, while the Phillips part has
only 16KB of SRAM (most of the storage is flash).


Not sure I follow this. Are you saying only SRAM determines leakage ?
I would have expected the total CMOS P-N pairs to determine leakage,
and that should be largely die area proportional (with possible factors
of Vcc disable of whole blocks, if that is done )


B: There is a tradeoff between static leakage and performance. A
4-stage CPU pipeline with a max frequency of 60 MHz is incredibly
biased towards low power & very low leakage, not high performance.
Heck, the LEON sparc core in the .25 micron FPGAs will run at ~30+
MHz, and thats a fully synthesized, no optimization at all design!


I think the 60MHz is dictated primarily by FLASH access, and that
speed, inclusive of flash, is at the 'high performance' end for uC.


C: Biasing towards lower leakage also allows higher Vio, as now you
have thicker oxide layers.


To say it is a trade-off is correct.
It it becomming is more common to see variable oxide process offered
- it could well be being done now, in FPGAs to give 3.6IO on 1V cores.

The point I am illustrating is that FPGAs have made impressive strides
in Speed, and features/dollar over the last 5 years, but that has come at
some other performance cost and compromise.
If they really want FPGAs to replace ASICs, or FPGA cores to expand
markets, that will be the next focus.

Intel is a putting a LOT of R&D into leakage control, as they realise it is
restricting their expansion and deployment.

Seems a natural 'next step' for (eg) Xilinx to take their 90nm Spartan-3
devices,
and tune for leakage first, and speed second.
Same tools, very largely the same mask sets, but new customers - those who
would look at 200mA max, 10mA typ and say 'pity, could have used that..'

-jg

 

[Jim Granville]

"Austin Lesea" wrote

Jim,

The big question is: "would anyone want to pay for a FPGA that is 1/2
the speed but 1/10 the leakage?"

Agreed.

If you can make it "a FPGA that is 1/2 speed, but 1/1000 leakage", it's a
better
question.
This brings it into line with ASIC, the uC example quoted, and even the
latest CPLDs

Or, you could ask "Would you like our next generation FPGA to be 2x faster,
or appx the same speed and 1/1000 of the standby current ?"

The typical customer will, of course, reply "I'd like both"

I can recall a time when FPGAs were chosen as the low static Icc prog.
logic solution, and CPLDs were the power-hogs - today that situation
seems to have reversed.

As for Intel, great PR, but they have absolutely no way that they have
announced to reduce drain source leakage. That big PR splash was for
"gate leakage" which is a small problem today. THE problem today
however is drain source leakage.

Some of the strained silicon plots I saw looked an improvement
- incremental, but a step in the right direction...

It's on the radar, so improvements will come....

-jg

 

[Austin Lesea]

Jim,

The strained silicon makes for a better Idsat, so they can then up the
Vt, to lower the leakage, or leave the Vt low, so they can get the speed
they want.

NO ONE has a clue how to solve the leakage issue. Not even close.
Massive "head in the sand" approach in the industry just now beginning
to shake folks up to where they are beginning to really look at it....

Austin

Jim Granville wrote:

"Austin Lesea" wrote

Jim,

The big question is: "would anyone want to pay for a FPGA that is 1/2
the speed but 1/10 the leakage?"


Agreed.

If you can make it "a FPGA that is 1/2 speed, but 1/1000 leakage", it's a
better
question.
This brings it into line with ASIC, the uC example quoted, and even the
latest CPLDs

Or, you could ask "Would you like our next generation FPGA to be 2x faster,
or appx the same speed and 1/1000 of the standby current ?"

The typical customer will, of course, reply "I'd like both"

I can recall a time when FPGAs were chosen as the low static Icc prog.
logic solution, and CPLDs were the power-hogs - today that situation
seems to have reversed.


As for Intel, great PR, but they have absolutely no way that they have
announced to reduce drain source leakage. That big PR splash was for
"gate leakage" which is a small problem today. THE problem today
however is drain source leakage.


Some of the strained silicon plots I saw looked an improvement
- incremental, but a step in the right direction...

It's on the radar, so improvements will come....

-jg

 

[Jim Granville]

"Austin Lesea" wrote

Jim,

The strained silicon makes for a better Idsat, so they can then up the
Vt, to lower the leakage, or leave the Vt low, so they can get the speed
they want.

NO ONE has a clue how to solve the leakage issue. Not even close.
Massive "head in the sand" approach in the industry just now beginning
to shake folks up to where they are beginning to really look at it....

- that's what makes it interesting to follow

The best solutions will 'retro-fit' onto the massive FAB equipment
investments,
but there are also design-time solutions.
Things like Power Route Switching (brute force), or variable oxide
and/or variable threshold across the die ( more finese, needs process
support )
etc..

In a FPGA, there could be future scope for standby style design, with a
LOGIC.Core
Vcc, and separate BitStreamLatches.Vcc, allowing the speed-tuned LOGIC to be
powered off, but the SRAM config info could be held.
Gives designers the choice of faster wakeup, from a very low power mode.

Meanwhile, designers could deploy the emerging larger FLASH, low power uC
devices (like my example LPC21xx ) as 'smart-loaders' - tasked to
power-remove,
and then re-load (compressed & secure) the FPGA info when needed.

-jg

 

[Nicholas C. Weaver]

In article <4SPwb.9639$ws.864267@news02.tsnz.net>,
Jim Granville <no.spam@designtools.co.nz> wrote:

A: Even a small FPGA has so many config bits and active gates that
static leakage becomes vastly significant, while the Phillips part has
only 16KB of SRAM (most of the storage is flash).

Not sure I follow this. Are you saying only SRAM determines leakage ?
I would have expected the total CMOS P-N pairs to determine leakage,
and that should be largely die area proportional (with possible factors
of Vcc disable of whole blocks, if that is done )

No, I'm just saying that the number of powered gates in even a "small"
FPGA is rather large, several hundred bits per CLB. There really is
no silicon area on an FPGA that isn't actively powered logic these
days, and densely placed actively-powered logic at that.

The point I am illustrating is that FPGAs have made impressive strides
in Speed, and features/dollar over the last 5 years, but that has come at
some other performance cost and compromise.
If they really want FPGAs to replace ASICs, or FPGA cores to expand
markets, that will be the next focus.

Intel is a putting a LOT of R&D into leakage control, as they realise it is
restricting their expansion and deployment.

Seems a natural 'next step' for (eg) Xilinx to take their 90nm Spartan-3
devices,
and tune for leakage first, and speed second.
Same tools, very largely the same mask sets, but new customers - those who
would look at 200mA max, 10mA typ and say 'pity, could have used that..'

The low power, especially low quiescent power, really can only be done
with non-SRAM config bits, as the config bits grossly dominate the
static power draw. EG, a flash or antifuse technology is vastly
better in the leakage department.

But with SRAM-based FPGAs, leaking transistors are always going to be
significant if the SIA roadmap holds, and the process games can't save
a factor of 10 without DRASTICALLY slowing things down or incredibly
boating the area.

Likewise, FPGAs will ALWAYS be ~10x greater in the dynamic power than
a comparable ASIC for "logic", as the cost of reconfigurable
interconnect is simply a lot more capacitence. Again, nothing can
really be done about this, it's just a Fact of Life.
--
Nicholas C. Weaver nweaver@cs.berkeley.edu

 

[Tullio Grassi]

On Tue, 25 Nov 2003, Austin Lesea wrote:

THE problem today however is drain source leakage.

Out of curiosity there is a design approach that completly kill
the Source-to-drain leakage; it's used in radiation environments.
Unfortunatly all other performances are greatly reduced.
It's published in Nucl. Instrum. Methods Phys. Res., A 439 (2000) 349-60

http://weblib.cern.ch/cgi-bin/ejournals?publication=Nucl.+Instrum.+Methods+Phys.+Res.,+A&volume=439&year=2000&page=349

 

[Austin Lesea]

Jim,

And what makes you think that we have not already done everything you
have mentioned?

Serious issue: no future solution on the horizon. Hope someone out
there is working on a solution right now.

Austin

Jim Granville wrote:

"Austin Lesea" wrote

Jim,

The strained silicon makes for a better Idsat, so they can then up the
Vt, to lower the leakage, or leave the Vt low, so they can get the speed
they want.

NO ONE has a clue how to solve the leakage issue. Not even close.
Massive "head in the sand" approach in the industry just now beginning
to shake folks up to where they are beginning to really look at it....


- that's what makes it interesting to follow

The best solutions will 'retro-fit' onto the massive FAB equipment
investments,
but there are also design-time solutions.
Things like Power Route Switching (brute force), or variable oxide
and/or variable threshold across the die ( more finese, needs process
support )
etc..

In a FPGA, there could be future scope for standby style design, with a
LOGIC.Core
Vcc, and separate BitStreamLatches.Vcc, allowing the speed-tuned LOGIC to be
powered off, but the SRAM config info could be held.
Gives designers the choice of faster wakeup, from a very low power mode.

Meanwhile, designers could deploy the emerging larger FLASH, low power uC
devices (like my example LPC21xx ) as 'smart-loaders' - tasked to
power-remove,
and then re-load (compressed & secure) the FPGA info when needed.

-jg

 

[Peter Alfke]

Source-to-drain leakage is caused byoff- transistors not completely
turned off.
This is caused by a Vcc/Vthreshold ratio that is not ideal.
Fundamentally, it is a trade-off between significantly higher leakage
current at significantly higher speed, vs. both of these parameters
significantly lower. There is no magic trick (at least not yet, and not
even on the horizon).

And for most (not all!) FPGA applications, speed is king, and leakage
current is whatever it is.
This may change one day...

Peter Alfke
========================
Tullio Grassi wrote:

On Tue, 25 Nov 2003, Austin Lesea wrote:

THE problem today however is drain source leakage.

Out of curiosity there is a design approach that completly kill
the Source-to-drain leakage; it's used in radiation environments.
Unfortunatly all other performances are greatly reduced.
It's published in Nucl. Instrum. Methods Phys. Res., A 439 (2000) 349-60

http://weblib.cern.ch/cgi-bin/ejournals?publication=Nucl.+Instrum.+Methods+Phys.+Res.,+A&volume=439&year=2000&page=349

 

[John Williams]

Hi Peter,

Peter Alfke wrote:

And for most (not all!) FPGA applications, speed is king, and leakage
current is whatever it is.

This may change one day...

I certainly hope so. There are lots of very interesting things that
FPGAs could do in handheld consumer multimedia applications, but power
consumption kills them in that market. That's what PACT and Quicksilver
are betting on...

Regards,

John

 

[Peter Alfke]

Agreed, and I am perhaps the strongest advocate of this point of view
inside Xilinx. But Sales and Marketing are always clamoring for highest
speed and lowest price. "That's what the customers want and need"...

Peter Alfke
===================================
John Williams wrote:

Hi Peter,

Peter Alfke wrote:
And for most (not all!) FPGA applications, speed is king, and leakage
current is whatever it is.

This may change one day...

I certainly hope so. There are lots of very interesting things that
FPGAs could do in handheld consumer multimedia applications, but power
consumption kills them in that market. That's what PACT and Quicksilver
are betting on...

Regards,

John

 

[Jim Granville]

"Peter Alfke" <peter@xilinx.com> wrote in message
news:3FC541C5.D7EB206B@xilinx.com...

Agreed, and I am perhaps the strongest advocate of this point of view
inside Xilinx. But Sales and Marketing are always clamoring for highest
speed and lowest price. "That's what the customers want and need"...

Good to hear - To help that advocacy, ask them about "full compliance with
ETSI specifications"
- marketing types love that style of phrase - Volts and uA have them glazing
over ...

This summary from a recent Infineon release (smart card sector) :

" 130nm process SLE88CFX4000P : 80 KBytes of "hidden" ROM, 400 KBytes of
EEPROM/Flash,
16 KBytes of RAM, 32 Bit CPU, crypto co-processor.
It operates at a voltage range of 1.62 to 5.5 V, in full compliance with
ETSI specifications. "

Strikes me that getting a 130nm device to operate 1.65-5.5V is not trivial,
but it must
have been important enough for them to make the effort.

Besides the process/ETSI tag point, this device would make a good secure
FPGA
Bootloader, if Infineon decided to package for that market.

-jg

 

[Hal Murray]

And there is the nasty reality that SRAM burns power, and there is a
LOT of config bits for each LUT, and that Reprogrammable interconnet
....

Why does SRAM have to burn power? I assume you are referring
to leakage since the config memory isn't flapping after
configuration.

Any reason somebody couldn't implement 2 types of logic on one
chip. Slow but low leakage for the config memory and fast but
more leakage for the active logic? I assume it doesn't work
easily with modern processing or people would be doing it already.
(Maybe they already are?) I'm fishing for more theory or long
term ideas.

[In the old days, lots of people used SRAM rather than DRAM because
it used less power - no refresh.]

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

 

[Nicholas C. Weaver]

In article <3FC541C5.D7EB206B@xilinx.com>,
Peter Alfke <peter@xilinx.com> wrote:

Agreed, and I am perhaps the strongest advocate of this point of view
inside Xilinx. But Sales and Marketing are always clamoring for highest
speed and lowest price. "That's what the customers want and need"...

And there is the nasty reality that SRAM burns power, and there is a
LOT of config bits for each LUT, and that Reprogrammable interconnet
really does cost 10x the power of fixed-function interconnect, simply
due to the excess capacitence on each switch point.

This will always hurt FPGAs in the every erg counts space.
--
Nicholas C. Weaver nweaver@cs.berkeley.edu

 

[Nicholas C. Weaver]

In article <vsclib1e0fi69b@corp.supernews.com>,
Hal Murray <hmurray@suespammers.org> wrote:

And there is the nasty reality that SRAM burns power, and there is a
LOT of config bits for each LUT, and that Reprogrammable interconnet
...

Why does SRAM have to burn power? I assume you are referring
to leakage since the config memory isn't flapping after
configuration.

Yeup. Leakage by the bucketload...

Any reason somebody couldn't implement 2 types of logic on one
chip. Slow but low leakage for the config memory and fast but
more leakage for the active logic? I assume it doesn't work
easily with modern processing or people would be doing it already.
(Maybe they already are?) I'm fishing for more theory or long
term ideas.

The problem is the FPGA places the SRAM cells (low leakage) right next
to active (must be high speed) switching transistors.

Any processing rule which had two Vts for the different transistors
would probably require a fairly substantial spacing between the two
types.

This would work very well for a low power processor, with low Vt
transistors (leaky but fast) in the CPU and with high Vt threshholds
(low leakage but slow) transistors in the caches.

EG, DRAM uses much higher threshhold (slower and less leaky)
transistors, but mixed DRAM/logic processes required a fair separation
between the DRAM blocks and other logic, and still resulted in slower
logic.
--
Nicholas C. Weaver nweaver@cs.berkeley.edu