5V I/O with 1.8V Core

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

"Symon" wrote

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

The SIIE is a .15u process shrink.

Aust> "Symon" 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).

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

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 )

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

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,

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.

Aust>

"Austin Lesea" wrote

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.

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,

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

Aust> "Austin Lesea" wrote

"Austin Lesea" wrote

- 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

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

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

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.

Aust> "Austin Lesea" wrote

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

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

:)

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

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

...

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.

Yeup. Leakage by the bucketload...

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