5V I/O with 1.8V Core

[Jim Granville]

"Nicholas C. Weaver"

In article <vsclib1e0fi69b@corp.supernews.com>,
Hal Murray <hmurray@suespammers.org> wrote:
snip
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

 

[Nicholas C. Weaver]

In article <fXvxb.10154$ws.902245@news02.tsnz.net>,
Jim Granville <no.spam@designtools.co.nz> 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

 

[Austin Lesea]

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 <vsclib1e0fi69b@corp.supernews.com>,
Hal Murray <hmurray@suespammers.org> wrote:

snip

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