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
5V I/O with 1.8V Core
Started by ●November 24, 2003
Reply by ●November 24, 20032003-11-24
"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
Reply by ●November 24, 20032003-11-24
"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, SymsSorry 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
Reply by ●November 25, 20032003-11-25
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 > >
Reply by ●November 25, 20032003-11-25
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
Reply by ●November 25, 20032003-11-25
"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
Reply by ●November 25, 20032003-11-25
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 > > > > >
Reply by ●November 25, 20032003-11-25
"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
Reply by ●November 25, 20032003-11-25
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 > >
Reply by ●November 25, 20032003-11-25
"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
