Reply-To: "Jim Granville" From: "Jim Granville" Newsgroups: comp.arch.fpga Subject: 5V I/O with 1.8V Core Lines: 19 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: Date: Tue, 25 Nov 2003 11:52:32 +1300 NNTP-Posting-Host: 218.101.47.173 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1069714274 218.101.47.173 (Tue, 25 Nov 2003 11:51:14 NZDT) NNTP-Posting-Date: Tue, 25 Nov 2003 11:51:14 NZDT Organization: TelstraClear Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.media.kyoto-u.ac.jp!newsfeed01.tsnz.net!news02.tsnz.net!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:35991 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 ###### From: "Symon" Newsgroups: comp.arch.fpga Subject: Re: 5V I/O with 1.8V Core Date: Mon, 24 Nov 2003 16:04:58 -0800 Lines: 30 Message-ID: References: NNTP-Posting-Host: 67.121.165.33 X-Trace: news.uni-berlin.de 1069719038 64152997 67.121.165.33 (16 [212844]) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeeder.edisontel.com!fu-berlin.de!uni-berlin.de!67.121.165.33!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:35995 "Jim Granville" 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-To: "Jim Granville" From: "Jim Granville" Newsgroups: comp.arch.fpga References: Subject: Re: 5V I/O with 1.8V Core Lines: 40 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: Date: Tue, 25 Nov 2003 14:21:58 +1300 NNTP-Posting-Host: 218.101.47.172 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1069723239 218.101.47.172 (Tue, 25 Nov 2003 14:20:39 NZDT) NNTP-Posting-Date: Tue, 25 Nov 2003 14:20:39 NZDT Organization: TelstraClear Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.media.kyoto-u.ac.jp!newsfeed01.tsnz.net!news02.tsnz.net!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:35997 "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 ###### From: Austin Lesea Newsgroups: comp.arch.fpga Subject: Re: 5V I/O with 1.8V Core Date: Tue, 25 Nov 2003 08:04:43 -0800 Organization: Xilinx,Inc Lines: 47 Message-ID: References: NNTP-Posting-Host: 149.199.53.89 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en In-Reply-To: Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.media.kyoto-u.ac.jp!ctu-gate!news.nctu.edu.tw!feeder.seed.net.tw!attdv1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36026 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 > > ###### From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Newsgroups: comp.arch.fpga Subject: Re: 5V I/O with 1.8V Core Date: Tue, 25 Nov 2003 16:56:38 +0000 (UTC) Organization: University of California, Berkeley, EECS Department Lines: 32 Message-ID: References: NNTP-Posting-Host: ribbit.cs.berkeley.edu X-Trace: agate.berkeley.edu 1069779398 75179 128.32.112.203 (25 Nov 2003 16:56:38 GMT) X-Complaints-To: usenet@agate.berkeley.edu NNTP-Posting-Date: Tue, 25 Nov 2003 16:56:38 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newshosting.com!news-xfer2.atl.newshosting.com!216.166.71.118.MISMATCH!small1.nntp.aus1.giganews.com!border1.nntp.aus1.giganews.com!nntp.giganews.com!cyclone-sf.pbi.net!128.32.206.55!newsfeed.berkeley.edu!ucberkeley!agate.berkeley.edu!agate!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36034 In article , 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. 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-To: "Jim Granville" From: "Jim Granville" Newsgroups: comp.arch.fpga References: Subject: Re: 5V I/O with 1.8V Core Lines: 67 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: <4SPwb.9639$ws.864267@news02.tsnz.net> Date: Wed, 26 Nov 2003 10:32:00 +1300 NNTP-Posting-Host: 218.101.47.150 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1069795840 218.101.47.150 (Wed, 26 Nov 2003 10:30:40 NZDT) NNTP-Posting-Date: Wed, 26 Nov 2003 10:30:40 NZDT Organization: TelstraClear Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!enews.sgi.com!news.xtra.co.nz!newsfeed01.tsnz.net!news02.tsnz.net!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36043 "Nicholas C. Weaver" wrote in message news:bq01k6$29db$1@agate.berkeley.edu... > In article , > 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. > > 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 ###### From: Austin Lesea Newsgroups: comp.arch.fpga Subject: Re: 5V I/O with 1.8V Core Date: Tue, 25 Nov 2003 14:04:23 -0800 Organization: Xilinx,Inc Lines: 87 Message-ID: References: <4SPwb.9639$ws.864267@news02.tsnz.net> NNTP-Posting-Host: 149.199.53.89 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en In-Reply-To: <4SPwb.9639$ws.864267@news02.tsnz.net> Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!enews.sgi.com!sdd.hp.com!news.usc.edu!attla2!attla1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36046 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" wrote in message > news:bq01k6$29db$1@agate.berkeley.edu... > >>In article , >>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. >> >>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-To: "Jim Granville" From: "Jim Granville" Newsgroups: comp.arch.fpga References: <4SPwb.9639$ws.864267@news02.tsnz.net> Subject: Re: 5V I/O with 1.8V Core Lines: 36 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: Date: Wed, 26 Nov 2003 11:49:13 +1300 NNTP-Posting-Host: 218.101.47.150 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1069800474 218.101.47.150 (Wed, 26 Nov 2003 11:47:54 NZDT) NNTP-Posting-Date: Wed, 26 Nov 2003 11:47:54 NZDT Organization: TelstraClear Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!enews.sgi.com!news.xtra.co.nz!newsfeed01.tsnz.net!news02.tsnz.net!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36048 "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 ###### From: Austin Lesea Newsgroups: comp.arch.fpga Subject: Re: 5V I/O with 1.8V Core Date: Tue, 25 Nov 2003 15:20:52 -0800 Organization: Xilinx,Inc Lines: 54 Message-ID: References: <4SPwb.9639$ws.864267@news02.tsnz.net> NNTP-Posting-Host: 149.199.53.89 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en In-Reply-To: Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!news.algonet.se!algonet!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed.media.kyoto-u.ac.jp!ctu-gate!news.nctu.edu.tw!feeder.seed.net.tw!attdv1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36049 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-To: "Jim Granville" From: "Jim Granville" Newsgroups: comp.arch.fpga References: <4SPwb.9639$ws.864267@news02.tsnz.net> Subject: Re: 5V I/O with 1.8V Core Lines: 36 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: Date: Wed, 26 Nov 2003 13:06:06 +1300 NNTP-Posting-Host: 218.101.47.150 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1069805086 218.101.47.150 (Wed, 26 Nov 2003 13:04:46 NZDT) NNTP-Posting-Date: Wed, 26 Nov 2003 13:04:46 NZDT Organization: TelstraClear Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!enews.sgi.com!news.xtra.co.nz!newsfeed01.tsnz.net!news02.tsnz.net!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36051 "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 ###### From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Newsgroups: comp.arch.fpga Subject: Re: 5V I/O with 1.8V Core Date: Wed, 26 Nov 2003 00:14:43 +0000 (UTC) Organization: University of California, Berkeley, EECS Department Lines: 47 Message-ID: References: <4SPwb.9639$ws.864267@news02.tsnz.net> NNTP-Posting-Host: ribbit.cs.berkeley.edu X-Trace: agate.berkeley.edu 1069805683 84256 128.32.112.203 (26 Nov 2003 00:14:43 GMT) X-Complaints-To: usenet@agate.berkeley.edu NNTP-Posting-Date: Wed, 26 Nov 2003 00:14:43 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!logbridge.uoregon.edu!newsfeed.stanford.edu!newsfeed.berkeley.edu!ucberkeley!agate.berkeley.edu!agate!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36052 In article <4SPwb.9639$ws.864267@news02.tsnz.net>, Jim Granville 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 ###### From: Tullio Grassi Newsgroups: comp.arch.fpga Subject: Re: 5V I/O with 1.8V Core Date: Wed, 26 Nov 2003 06:30:01 +0100 Organization: CERN - European Laboratory for Particle Physics Lines: 11 Message-ID: References: <4SPwb.9639$ws.864267@news02.tsnz.net> NNTP-Posting-Host: lxplus064.cern.ch Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sunnews.cern.ch 1069824605 21462 (None) 137.138.4.125 X-Complaints-To: news@sunnews.cern.ch X-X-Sender: tgrassi@lxplus064.cern.ch In-Reply-To: Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!cern.ch!lxplus064.cern.ch!tgrassi Xref: redlance.franklin.ch comp.arch.fpga:36064 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 ###### From: Austin Lesea Newsgroups: comp.arch.fpga Subject: Re: 5V I/O with 1.8V Core Date: Wed, 26 Nov 2003 07:36:30 -0800 Organization: Xilinx,Inc Lines: 49 Message-ID: References: <4SPwb.9639$ws.864267@news02.tsnz.net> NNTP-Posting-Host: 149.199.53.89 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en In-Reply-To: Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!logbridge.uoregon.edu!nntp-server.caltech.edu!attla2!attla1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36075 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 > > ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: 5V I/O with 1.8V Core Date: Wed, 26 Nov 2003 11:21:16 -0800 Organization: Xilinx,Inc Lines: 26 Message-ID: <3FC4FD2B.FC876146@xilinx.com> References: <4SPwb.9639$ws.864267@news02.tsnz.net> NNTP-Posting-Host: peter.xilinx.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en To: Tullio Grassi Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.icl.net!newsfeed.fjserv.net!newshosting.com!news-xfer1.atl.newshosting.com!news-out.superfeed.net!propagator2-maxim!news-in-maxim.spamkiller.net!news.usc.edu!attla2!attla1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36086 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 ###### From: John Williams Newsgroups: comp.arch.fpga Subject: Re: 5V I/O with 1.8V Core Date: Thu, 27 Nov 2003 08:48:09 +1000 Organization: ITEE, University of Queensland Lines: 17 Message-ID: References: <4SPwb.9639$ws.864267@news02.tsnz.net> <3FC4FD2B.FC876146@xilinx.com> Reply-To: jwilliams@itee.uq.edu.au NNTP-Posting-Host: g435-9029.itee.uq.edu.au Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: bunyip.cc.uq.edu.au 1069886720 31515 130.102.66.250 (26 Nov 2003 22:45:20 GMT) X-Complaints-To: news@uq.edu.au NNTP-Posting-Date: 26 Nov 2003 22:45:20 GMT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en In-Reply-To: <3FC4FD2B.FC876146@xilinx.com> Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!news.maxwell.syr.edu!news.mel.connect.com.au!news.syd.connect.com.au!news.bri.connect.com.au!bunyip.cc.uq.edu.au!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36093 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 ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: 5V I/O with 1.8V Core Date: Wed, 26 Nov 2003 16:13:58 -0800 Organization: Xilinx,Inc Lines: 24 Message-ID: <3FC541C5.D7EB206B@xilinx.com> References: <4SPwb.9639$ws.864267@news02.tsnz.net> <3FC4FD2B.FC876146@xilinx.com> NNTP-Posting-Host: peter.xilinx.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en To: jwilliams@itee.uq.edu.au Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!logbridge.uoregon.edu!nntp-server.caltech.edu!attla2!attla1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36095 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 ###### Reply-To: "Jim Granville" From: "Jim Granville" Newsgroups: comp.arch.fpga References: <4SPwb.9639$ws.864267@news02.tsnz.net> <3FC4FD2B.FC876146@xilinx.com> <3FC541C5.D7EB206B@xilinx.com> Subject: Re: 5V I/O with 1.8V Core Lines: 32 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: Date: Thu, 27 Nov 2003 13:45:31 +1300 NNTP-Posting-Host: 218.101.47.92 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1069893851 218.101.47.92 (Thu, 27 Nov 2003 13:44:11 NZDT) NNTP-Posting-Date: Thu, 27 Nov 2003 13:44:11 NZDT Organization: TelstraClear Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.media.kyoto-u.ac.jp!newsfeed01.tsnz.net!news02.tsnz.net!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36096 "Peter Alfke" 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 ###### From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Newsgroups: comp.arch.fpga Subject: Re: 5V I/O with 1.8V Core Date: Thu, 27 Nov 2003 19:32:55 +0000 (UTC) Organization: University of California, Berkeley, EECS Department Lines: 14 Message-ID: References: <3FC4FD2B.FC876146@xilinx.com> <3FC541C5.D7EB206B@xilinx.com> NNTP-Posting-Host: ribbit.cs.berkeley.edu X-Trace: agate.berkeley.edu 1069961575 27136 128.32.112.203 (27 Nov 2003 19:32:55 GMT) X-Complaints-To: usenet@agate.berkeley.edu NNTP-Posting-Date: Thu, 27 Nov 2003 19:32:55 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!eusc.inter.net!priapus.visi.com!news-out.visi.com!petbe.visi.com!newsfeed.berkeley.edu!ucberkeley!agate.berkeley.edu!agate!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36126 In article <3FC541C5.D7EB206B@xilinx.com>, Peter Alfke 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 ###### From: hmurray@suespammers.org (Hal Murray) Newsgroups: comp.arch.fpga Subject: Re: 5V I/O with 1.8V Core Date: Thu, 27 Nov 2003 19:53:47 -0000 Message-ID: X-Newsreader: xrn 9.02 Sender: murray@glypnod (Hal Murray) References: <3FC4FD2B.FC876146@xilinx.com> <3FC541C5.D7EB206B@xilinx.com> X-Complaints-To: abuse@supernews.com Lines: 24 Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeeder.edisontel.com!tiscali!newsfeed1.ip.tiscali.net!news.tele.dk!news.tele.dk!small.news.tele.dk!sn-xit-02!sn-xit-04!sn-xit-06!sn-post-02!sn-post-01!supernews.com!corp.supernews.com!glypnod!hmurray Xref: redlance.franklin.ch comp.arch.fpga:36127 >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. ###### From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Newsgroups: comp.arch.fpga Subject: Re: 5V I/O with 1.8V Core Date: Thu, 27 Nov 2003 20:10:43 +0000 (UTC) Organization: University of California, Berkeley, EECS Department Lines: 36 Message-ID: References: <3FC541C5.D7EB206B@xilinx.com> NNTP-Posting-Host: ribbit.cs.berkeley.edu X-Trace: agate.berkeley.edu 1069963843 27825 128.32.112.203 (27 Nov 2003 20:10:43 GMT) X-Complaints-To: usenet@agate.berkeley.edu NNTP-Posting-Date: Thu, 27 Nov 2003 20:10:43 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!logbridge.uoregon.edu!nntp-relay.ihug.net!ihug.co.nz!newsfeed.berkeley.edu!ucberkeley!agate.berkeley.edu!agate!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36130 In article , Hal Murray 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 ###### Reply-To: "Jim Granville" From: "Jim Granville" Newsgroups: comp.arch.fpga References: <3FC541C5.D7EB206B@xilinx.com> Subject: Re: 5V I/O with 1.8V Core Lines: 42 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: Date: Fri, 28 Nov 2003 12:41:15 +1300 NNTP-Posting-Host: 218.101.47.177 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1069976395 218.101.47.177 (Fri, 28 Nov 2003 12:39:55 NZDT) NNTP-Posting-Date: Fri, 28 Nov 2003 12:39:55 NZDT Organization: TelstraClear Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!enews.sgi.com!news.xtra.co.nz!newsfeed01.tsnz.net!news02.tsnz.net!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36138 "Nicholas C. Weaver" > In article , > Hal Murray wrote: > >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 believe foundries offer this already. Maybe Austin L could confirm if Xilinx are using this ? In noise immunity topics, we've seen the point made that the CONFIG cells have significantly different, and better, noise immunity ( so config corruption is less likely than logic corruption). > > 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. Why ? Sure, more steps will be needed - but spacing ? There would be a case for really pushing the Speed rules for LOGIC, but going for MAX Yield (ie slightly relaxed geometries) on the CONFIG cells (lots more of them, _and_ they are not 'picosecond paranoid' ). There would be some trade off on CONFIG time, and leakage Current in a variable threshold design. I think this could be checked experimentally - drop Vcc, and LoadCLK, and plot Config verify fail Vcc/Freq curve. Then create a LOGIC fabric shifter, and do the same for it. -jg ###### From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Newsgroups: comp.arch.fpga Subject: Re: 5V I/O with 1.8V Core Date: Fri, 28 Nov 2003 16:57:01 +0000 (UTC) Organization: University of California, Berkeley, EECS Department Lines: 18 Message-ID: References: NNTP-Posting-Host: ribbit.cs.berkeley.edu X-Trace: agate.berkeley.edu 1070038621 45888 128.32.112.203 (28 Nov 2003 16:57:01 GMT) X-Complaints-To: usenet@agate.berkeley.edu NNTP-Posting-Date: Fri, 28 Nov 2003 16:57:01 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!enews.sgi.com!newsfeed.berkeley.edu!ucberkeley!agate.berkeley.edu!agate!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36150 In article , Jim Granville wrote: >> Any processing rule which had two Vts for the different transistors >> would probably require a fairly substantial spacing between the two >> types. > >Why ? Sure, more steps will be needed - but spacing ? I'ts just an observation that anything special tends to require greater spacing as well as greater steps. I don't have/haven't seen any actual design rules with multiple Vt threshholds, but the most sophisticated I've delt with is .18 micron. Additionally, for all but FPGA, mixing high Vt and low Vt transistors very close would not be a huge benefit compared with just having the two. -- Nicholas C. Weaver nweaver@cs.berkeley.edu ###### From: Austin Lesea Newsgroups: comp.arch.fpga Subject: Re: 5V I/O with 1.8V Core Date: Mon, 01 Dec 2003 07:51:44 -0800 Organization: Xilinx,Inc Lines: 61 Message-ID: References: <3FC541C5.D7EB206B@xilinx.com> NNTP-Posting-Host: 149.199.53.89 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en In-Reply-To: Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!npeer.de.kpn-eurorings.net!newsfeed.media.kyoto-u.ac.jp!ctu-gate!news.nctu.edu.tw!feeder.seed.net.tw!attdv1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36179 Jim, Been there, done that. Still doing that, and more. It is very favorable to do special things with the cmos configuration cells (we call them CCC's) rather than SRAM memory for configuration. Our CCC's are 20X or more robust than SRAM to SEUs, and all for good reasons. Austin Jim Granville wrote: > "Nicholas C. Weaver" > >>In article , >>Hal Murray wrote: > > > >>>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 believe foundries offer this already. > > Maybe Austin L could confirm if Xilinx are using this ? > > In noise immunity topics, we've seen the point made that > the CONFIG cells have significantly different, and better, noise > immunity ( so config corruption is less likely than logic corruption). > > >>>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. > > > Why ? Sure, more steps will be needed - but spacing ? > > There would be a case for really pushing the Speed rules for LOGIC, > but going for MAX Yield (ie slightly relaxed geometries) on the CONFIG > cells (lots more of them, _and_ they are not 'picosecond paranoid' ). > There would be some trade off on CONFIG time, and leakage Current in > a variable threshold design. > > I think this could be checked experimentally - drop Vcc, and LoadCLK, > and plot Config verify fail Vcc/Freq curve. > Then create a LOGIC fabric shifter, and do the same for it. > > -jg > >