future of antifuse fpgas?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View

Does anybody have a general feel for whether or not Actel (or any
other vendor) is going to bring out a new generation of antifuse fpgas
on a newer process (90nm)?  Or has this device style basically been
shelved as only a specialty item for people who are ultra-sensitive to
soft errors above all other factors?

I'm mainly curious about whether or not the speed advantages will
continue on newer processes.  In theory, an antifuse should have less
capacitance than an SRAM-based pip, giving you lower propagation
delays and hence higher clock rates.  It looks like this was probably
true doing a 150nm-to-150nm comparison of the Axcellerator versus
FPGAs made on a similar generation of process technology.

However, I have to believe that the antifuse stuff requires a special
process/fab, and that fab isn't going to be doing anywhere close to
the volume that a strictly-CMOS fab would.  That in turn drives up
prices or else forces compromises that affect performance (in order to
bring down costs).

So, ultimately, I'm wondering how this will play out.  Obviously any
comments at this point are pure speculation, but I'd appreciate
speculation from somebody who knows more about this stuff than myself.

  - a

--
PGP/GPG: 5C9F F366 C9CF 2145 E770  B1B8 EFB1 462D A146 C380

Re: future of antifuse fpgas?
Adam,

I think you have it well understood.

I am sure there is work on better and smaller efuse technologies, as
even non-fuse based FPGAs may use fuses (for redundancy).  Also, ASICs
and ASSPs use fuses for redundancy, repair, and setting bias voltages.

A big fuse cell is a pain in the neck.  Smaller is better.

However, right now Actel has a bigger problem:  the issue of their fuses
blowing on their parts (see NASA/JPL advisory notice 'do not use') due
to SI issues (large overshoot/undershoot on IOs).  They have claimed
this is solved, and is not a problem on any family other than the one
affected, but it has had a huge sobering effect on the fuse FPGA
mil-aero community ("how can I ever trust these parts ever again? my
mission was scrapped ... I lost my job because the contract was
canceled" - heard in the hallways of JPL ...).

I love fuses, when they work.

Austin

Adam Megacz wrote:

Quoted text here. Click to load it

Re: future of antifuse fpgas?

Quoted text here. Click to load it

Yeah, although this is the part of the whole antifuse debate that
kinda annoys me.  Whenever the issue comes up, people only talk about
reliability and radiation.  Obviously those are important for a really
big market, but not for me.

Right now I'm interested in prototyping new/alternative fabrics for
FPGAs.  Short of doing a MOSIS run (which I will do eventually -- just
not yet), I'm trying to figure out the best way to do a mock-up
prototype.

All I care about is speed (aka propagation delay), size, and the
ability to map my "virtual CLBs" efficiently.  I only need to program
the device once.  Given those (admittedly unusual) constraints, I'm
trying to evaluate what's out there.  Additionally, most of my stuff
will be QDI self-timed, so clock distribution innovations aren't a big
feature for me.

Quoted text here. Click to load it

Now Austin, you wouldn't be FUDding us just a *leeetle* bit there now
would you? ;)

Thanks for the reply though!

  - a

Re: future of antifuse fpgas?
Quoted text here. Click to load it

And previously


There has never been a time that Anti-fuse based FPGAs have had a
speed advantage over "SRAM"* based FPGAs. Not from Actel, not from
Quicklogic, not from Crosspoint, and not from Xilinx. At any given
time, the underlying technology process node for Anti-fuse devices is
at least 1 generation and sometimes 2 generations behind the
tecnhology for the "SRAM" based parts. The only time performance
leadership has been claimed is in marketing material. When comparisons
have been made with similar process nodes, they represent product
availability that differs by a year or two. By the time Actel had a
150nm process that yielded, X and A were at 120nm or below.

The real speed killer for Anti-fuse is what they never talk about in
their comparisons. They always show the size of the Anti-fuse versus
the "SRAM" pass transistor (or pass gate) and say the far smaller
size leads to lower capacitance and therefore higher speed. This is
true. What they fail to mention is that to program the Anti-fuse
they need a pair of power transistors either side of the Anti-fuse
to sink enough current through the fuse to program it. They are big,
capacitive, at the end of long shared wires, and they are still there
after programming is done. The size of these transistors is so big,
that they kill most of the area advantage that came from the Anti-
fuses being small.

*:  I use quotes around "SRAM" because although the FPGAs are referred
    to as SRAM for their configuration memory, it would be far more
    accurate to call it an array of latches loaded from a shift register.

Quoted text here. Click to load it

The other big problem for the Anti-Fuse folks is that they have a
hard time getting the attention of the high volume leading edge
foundaries. They end up at second tier foundaries that are willing to
do the special stuff for Anti-fuse, but then the usually do not yet
have the leading process node available.

Quoted text here. Click to load it

Exactly right.


Although you say (up the top) that you only want to program the device
once, your project is architecture exploration. This is really helped
by being able to try lots of different things. I think I wrote about
this previously:  http://tinyurl.com/bvbvz


Philip Freidin 1992 in comp.arch  (on FPGA based algorithm accelerators)
Quoted text here. Click to load it
never
Quoted text here. Click to load it
outperform
Quoted text here. Click to load it
applications
Quoted text here. Click to load it



Philip Freidin
Crusader against Anti-Fuse FPGAs since 1989   :-)



Re: future of antifuse fpgas?

Quoted text here. Click to load it

Wow, thank you Philip; this was not only the information I was looking
for, but the little-known reason why it is so.

Thanks!

  - a

Re: future of antifuse fpgas?

Quoted text here. Click to load it

Is UMC considered a second tier foundry?  I note that Xilinx builds devices
there.

--
rk, Just an OldEngineer and not a process guy.
"These are highly complicated pieces of equipment almost as complicated as
We've slightly trimmed the long signature. Click to see the full one.
Re: future of antifuse fpgas?
rk,

Yes, UMC is a nice little foundry.  We have some wafers running there.

Seriously, a foundry is not just one process, or one line, but many.

At the 12" location of UMC, Tainan, in the south of Taiwan, there is a
whole lot of advanced process node production going on.  Most, perhaps
all, of their capital budget is spent on these processes.

It isn't so much your choice of foundry (I think UMC is a great choice),
but it is also your choice (if you have a choice) of process.

Austin

Re: future of antifuse fpgas?

Quoted text here. Click to load it

Agreed, of course, was just commenting on the one point that Philip brought
up.  

What you described is of course true at many foundries, nothing new, and not
all designs call for the most modern deep submicron process.




Philip Freidin wrote:

Quoted text here. Click to load it

Is UMC considered a second tier foundry?  I note that Xilinx builds devices
there.



--
rk, Just an OldEngineer
"These are highly complicated pieces of equipment almost as complicated as
We've slightly trimmed the long signature. Click to see the full one.
Re: future of antifuse fpgas?
Quoted text here. Click to load it

I've found notes saying 'the MODE pin must be grounded, and if you've
ever powered up a flight item with an Actel FPGA with the MODE pin
un-grounded you must replace all FPGAs on the board', dating from 1995;
haven't seen anything about this 'bigger problem'.

Though I'm a hobbyist, and wouldn't buy one-shot chips unless they
were a couple of orders of magnitude cheaper than equal-performance
reprogrammable equivalents.

Tom

Site Timeline