FPGA vs ASIC area

SG,

I agree with you. Since IBM and Xilinx wrote the paper together, we both had to agree on what is in there. Since IBM is #1 in ASIC's, I would not argue with them, either.

Just remember that the PPC, MGT, DCM, EMAC, DSP48, etc. are all 'hard cores' and do not 'suffer' from the same 10:1 disadvantages in speed and power as plain old interconnect and logic.

Not mentioned here is that ASICs suffer a 10:1 disadvantage in single event upsets. Every single upset in an ASIC is a functional failure (plus they are a lot more sensitive being the smallest structure possible). Only 1:10 SEUs in a FPGA cause a functional failure. The two factors cancel out. We take 10X more to do the same job, but have

1/10 the upset rate, so we come back to parity on hardness against cosmic ray neutron showers. Many folks erroniously believe that ASICs are better with respect to SEUs (or conversely FPGAs are worse than ASICs): they are not.

Page 7 of 8 details the comment I made about how incorporation of a FPGA core into an ASIC might offer benefits in test coverage.

Since I did not know this had been published, I was unable to disclose it here (basically this is IBM's property).

Since it is published, go read it and decide.

An interesting thought: is a hybrid ASIC/FPGA a better choice than an ASIC alone?

Is our FPGA becoming a big programmable fabric with little ASIC bits in it?

Is IBM's ASIC becoming a bunch of ASIC stuff connected by little programmable fabric bits?

You decide. If you do not go with our FPGA, then by all means go with IBM's ASIC/FPGA hybrid.....

Austin

SG wrote:

Reply to
Austin Lesea
Loading thread data ...

Austin Lesea wrote

Could you explain, why only 1 out of 10 SEU in a Xilinx Fpga will be a functional failure? Are there inplicit redundancies inside a Xilinx fpga? And are there possibilities, that an SEU changes the function of the fpga in that whay that e.g. a OR changes to an AND?

bye Thomas

Reply to
Thomas Stanka

Google and I respectfully disagree with you.

Taking just the most recent thread as an example:

formatting link

You and Steve were both quick to discount the possiblity of a parallel DCI startup transient triggering the S3 VCCO ESD circuit; yet when I rephrased my original post to be less ambiguous, there was no response.

Outstanding questions from that thread:

- Why is there no SSO data for VQ/PQ/TQ packages in the S3 datasheet?

- Why did the blank column for said SSO data dissapear?

- Has Xilinx considered, tested, or characterized the possibility of triggering the Spartan3 VCCO ESD circuit with an internal VCCO rail collapse induced by the SSO-like effects of the parallel DCI terminator startup current in the leaded packages?

I haven't completed an S3 DCI design yet, so I haven't actually witnessed this (hypothetical) problem, but past experience coupled with the description of the VCCO ramp problem led me to ask the question.

Brian

Reply to
Brian Davis

Only if you use them. Otherwise, they contribute even more to the area disadvantage of FPGAs over ASICs. *Usually*, there will always be some of hard blocks in a FPGA that you will not use for your application (the FPGA device having been chosen for cost, fitting your design, etc reasons).

This is firstly not germane to the discussion of FPGA area vs ASIC area, but more importantly an unsubstantiated claim. The only devices that have been recalled from the market due to SEU errors are Xilinx FPGAs. Besides as was the case with Xilinx, this is a problem that packaging can fix to some extent (at a cost of course).

Since we are discussing all the other issues of ASIC vs FPGAs, we should also pay attention to the severe power/energy consumption disadvantage of FPGAs. Since 65% of the power dissipated by a FPGA is by its interconnect, this is an inherent problem with FPGAs (there are several papers that have studied the power breakdown of FPGAs). Soon, we will need heat sinks and other passive and active cooling for FPGAs as the number of gates and the speed at which they operate is increased. I have already heard from some folks that they are on the border of using cooling for the larger, faster FPGAs. The inherent disadvantage of FPGAs over ASIC implementations lies in the interconnect and configuration memory. Interconnect comprises about 60% of a FPGA fabric, configuration memory is about 30%, and only about 10% is the actual LUTs. This assumes no hard macros, just a pure sea of LUTs. Again these figures are well-known and published by multiple sources (search for Andre DeHon's thesis and papers for one).

Even out of the 10% LUTs, the utilization of each LUT is low. This means, that even though every single LUT in a FPGA may be used, not each LUT is used to 100% capacity. For example, a LUT could be used to implement something as simple as an AND gate (highly likely, but possible) or much more complex 4-input functions (if its a 4-LUT). So, if you take what the percentage of each LUT is utilized into account, overall logic/LUT utilization is reasonably low (again something that I have seen figures around 30-50% before - probably from Jonathan Rose's work).

Like I said before, these area, performance power, cost disadvantages of FPGAs all have to be measured against NRE cost, die cost, back-end tool costs, and volume of ASICs to determine whether you want to do a FPGA or an ASIC or a structured ASIC. Clearly, FPGAs come out on top a lot of times (and thus the large market for them). Sumit

Reply to
SG

Xilinx never said anything of this kind. We are not megalomaniacs. But we want to nibble away at the fringes of the ASIC market. If we can take those 10% that can benefit from the known FPGA advantages and do not care so much about some of the known ASIC advantages, then we double our sales, which keep us happy for a year or two. :-) ASICs really do us a favor when they create a world-wide appetite for complex electronic solutions, and tickle the system designers' imagination. Then, when some of them are disappointed that they cannot afford the ASIC for reasons of NRE, time or flexibility, we come in and explain our capabilties. We may be not as fast, not as big, not as low power, not as cheap in high volume, but instead we are more flexible, changeable, dynamically reconfigurable, without any NRE, faster to market, and easier (and more fun) to design with, since FPGAs allow unlimited design variations, modifications and, heaven forbid, even error fixes. We can live with ASICs, they are our big neighbor. Peter Alfke

Reply to
Peter Alfke

Brian,

An oversight on my part. I apologize.

Please let me know if there are any questions left unanswered.

See below,

Aust> Aust>

Spartan 3 belongs to the General Product Group here at Xilinx. I am employed by the Advanced Products Group. I do not know the answer, but I will ask Steve Knapp to reply.

Again, a Spartan issue, so I will let Steve reply.

To the best of my knowledge, yes, this was simulated, as well as tested. The mechanism causing this is an active ESD clamp using transistors, so as such, its behavior is completely different when power is ramping, as opposed to after power has ramped ON.

Perfectly valid questions.

Reply to
Austin Lesea

SG,

Comments below,

Aust> Aust>

You get to choose if you want to use them, yes.

'Germane' is how a FPGA compares to an ASIC. SEU hardness is a factor. Perhaps a very important one.

The alpha package contamination issue was not caused by cosmic rays, but by contaminated solder (alpha particles). Do not confuse the issue. We are not the first company to have that problem. Although, we are the first FPGA company to have that problem. I am supposing that ASIC vendors would not be likely to stand up and admit they have ever had that problem, but I am sure that they do (as we were not the only part that received that bad lot of material).

The Rosetta experiments have proven the claim. Go ask you favorite ASIC vendor what their FIT/Mb is in their latest 90nm ASIC. Go ask what the MTBF is from cosmic ray neutron showers at sea level for their 10M gate part.

Oh, and ask them how they know. Probably the most important question. With LANSCE (Los Alamos) closed due to security concerns, no one can do beam testing right now. And if you do beam testing, how does that correlate. Does it? Prove it. We have.

And who has atmospheric test data? We do. 7400 device years and counting on .15u, .13u and 90nm.

Make sure you ask your vendor for their data.

It is not rocket science (to design for soft errors): if I make every single circuit as small as I possibly can, and load each cell with as small a load as possible, I have just made a neutron detector in 90nm. Oh, I just described an ASIC!

If I have to connect everything to everything, and control it with memory bits, and run slower, and not use all of the transistors, then I have just described the common techniques used to improve hardness to neutron induced upsets. I have also described a FPGA.

A radical statement, yet one I believe is true, is that FPGAs may be the only safe way to design in the future due to soft errors. Only if ASICs dedicate more area and have less speed and create rad hard cells will they be able to compete for basic reliability below 90nm.

In 20 years, we maximum power of the FPGA has not changed. When they ran at 20 MHz, they could dissipate 10 - 15 watts, and today at 500 MHz, they can dissipate 10 - 15 watts. Again, for what we do, we have done it better, every single time we introduce a product. We are not a uP, with 100W heatsink solutions, and at the end of the line for further improvements.

Yes, many customers use cooling on their FPGAs. Always have, and probably always will, when they run at high frequencies in the larger parts.

I also see heat sinks on ASICs.

I will concede that an ASIC will always draw less power to do the same job as a FPGA. No argument there. But we do improve, and the hardened bits are just as good as an ASIC.

OK. Don't disagree with the numbers. "Inherent disadvatage" is a value judgement. If I can change it (reprogrammability), and if I am better able to deal with SEUs, than I claim that we have an inherent advantage.

Yes. That was my point as well why we are at parity (or better) for an ASIC for SEU. You are making my argument for me. Thank you.

Reply to
Austin Lesea

Well, your posts often read that way, and I believe you work for Xilinx :-)

And of course in some cases we couldn't live without FPGAs, otherwise people couldn't build prototype systems to convince their CEOs/CTOs/customers to cough up for the (ever-increasing) cost of making an ASIC :-)

Ian

Reply to
Ian Dedic

Thanks; were all your posts as cordial as that one, I don't think anyone would be complaining.

Brian

Reply to
Brian Davis

Brian,

You are welcome.

Aust> Aust>

Reply to
Austin Lesea

Did you look at these papers that gives some comparison of power consumption of FPGAs:

formatting link
formatting link

Sumit

Reply to
SG

Here is a viewpoint from Faraday, slightly biased, but the numbers are in the right ball park:

formatting link

The number of engineers, tool costs etc are incorrect. For the same complexity design, you typically require the same number of engineers and tools -- the only thing different is that ASIC requires back-end tools (which are very expensive) and the engineers to use these tools. However, for large, complex designs, even FPGAs & structured ASICs can be a pain to achieve timing/performance.

Here is a whole set of articles on choosing the right silicon:

formatting link

and another series of articles on FPGAs versus ASICs:

formatting link

Sorry for inundating everyone with pointers, but the articles at these links are useful for this discussion

Sumit

Reply to
SG

They only "contribute ... to the area disadvantage" if your target is a simple cost function - if you are minimising cost. Just as likely you are putting some weight on minimising risk. And a startup may be working on maximising the minimum profit or minimising the maximum calamity. If so, unused resources are the general's reserve troops.

Reply to
Tim

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.