FPGA vs ASIC area

I didn't say no verification, I would never go into the lab with a design that hadn't been verified. The difference is that you can spend a few weeks to a couple of months simulating an FPGA and then go into the lab and run it in a real system at the real clock speed and get the last bugs. In big systems the bit patterns should be loaded by the software not by serial proms, if a bug crops up you rev the software. Everyone expects software to be buggy so no one blinks an eye if there is a new software release, let the software guys take the blame. In my experience the software guys feel so guilty about bugs that it's hard to convince them that it's not their fault. If a system can't be field upgraded then you have to test the hell out of it but you do that on the real hardware. Either way you are in the lab a full 12 to 18 months earlier with an FPGA then you are with an ASIC.

Reply to
General Schvantzkoph
Loading thread data ...

There are hidden test structures. But they are not very significant at all. There is some extra goo that makes it cheaper/faster to test the chip and to hit full coverage of some circuitry. But that's about it.

Probably impossible (or too costly) with irregular ASICs. Not impossible with modern FPGAs (see USPO). We still use redundancy technology in our FPGAs, and it helps reduce our costs and improve our margins. The cost is some increased complexity and silicon area, but we pay this in exchange for repairability and thus enhanced yield. Depending on the incremental silicon cost, die size of the product, and assumed yield, the exact benefit of redundancy changes. But it is pretty tricky to reliably ship big (500 um^2?) devices or on brand-new processes without yield-enhancing technology.

As far as timing models go, any implication that redundancy affects quality of timing models is pure FUD. So long as the max and min delays reflected within the software are an upper-bound and lower-bound on the delay that can be seen in any repaired part, then everything's cool.

Regards,

Paul Leventis Altera Corp.

Reply to
Paul Leventis (at home)

How much trouble do you get from customers who are right at the edge and have a design that works most of the time but is flaky on chips which happen to use the redundancy path on a critical signal?

--
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.
Reply to
Hal Murray

Hi Hal,

None. I am responsible for timing modeling of all families from Stratix on (Stratix, Stratix II, Cyclone, Cyclone II, and Max II). I have not seen a single case of a design that has failed due to a core timing modeling bug, let alone a redundancy issue. We have seen a couple timing issues pop up in the past relating to PLL or I/O timing, usually due to our biggest nemisis... a C coding or data entry error.

One way of looking at things is that the worst-case is a critical path criss-crossing back and forth over the disabled logic. This is highly unlikely. And even if this does occur, we'd still get the delay right because we analyse each routing path so that even with a worst-case location of disabled logic, we are always slightly conservative. When we correlate and compare the predictions of the Quartus timing model to silicon, we see a bias towards overpredicting delay, particularly for resources that could be affected by redundancy. And these tests are performed on silicon at the hairy edge of the binning limits, with minimum voltage and maximum temperature.

Redundancy timing is a solved problem.

Regards,

Paul Leventis Altera Corp.

Reply to
Paul Leventis (at home)

That will only be a problem if the (emm, I guess the only word thats polite is) customers rely on empirical measurements rather than the static timing analysis.

--
Nicholas C. Weaver.  to reply email to "nweaver" at the domain
icsi.berkeley.edu
Reply to
Nicholas Weaver

You may be convinced, but that is not the same as having facts. The simple fact that you "reconfigure tens and hundreds of times" means you take a lot of time just loading your tests into the chip before you can run them on the chip. The test methods for ASIC testing has been around for a long time, it is the details of a particular test that is unique for a given ASIC. This is not a new science, it is well understood and largely automated.

Which question is meaningless and cute? I didn't ask a question. I was responding to *your* statements about total costs. I believe your point was about the silicon area not being the sole or possibly even the largest part of chip costs. Non-recurring costs can be large, but their per-unit cost depends on the volume. However, the testing and silicon per-unit costs are the same regardless of volume. So they are more important as the volume increases.

Peter Alfke wrote:

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX
Reply to
rickman

But as Peter pointed out, silicon cost is not the only variable cost. The longer testing adds to the unit cost just as larger silicon does.

Nonsense. There are design techniques to measure testability to allow as high testing coverage as is required by improving the test. If there is no way to determine a fault in a node, then by definition, it won't affect the operation of the chip! Any fault that makes a difference in chip operation is observable, the only question is how to stimulate the chip to detect it. That is a well understood problem.

Yes, but that does not mean excess test development time. Much of this process is automated.

No, by definition an FPGA has extra area for BIST, that is what makes it an FPGA, all the *extra* stuff in it!!! What is the area overhead for an FPGA vs. an ASIC; 10X, 20X? Even if you build an ASIC that is two generations back such as 150 nm vs. 90 nm, the ASIC will be smaller, faster and therefore cheaper.

How is using the "latest and greatest technologies" an advantage when it comes with a 10X area premium???

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX
Reply to
rickman

What you say it true, but the reduction in yield in the case of good yield numbers will be very small while the improvement in yield in the case of poor yield can be significant.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX
Reply to
rickman

For a glimpse of one approach to FPGA -> StructuredASIC, see

formatting link

A couple of interesting points here :

** they take a TSMC 0.15u sub-metal wafer, and add the metal themselves. [Metal layers are normally more relaxed rules] ( could give rise to interesting yield discussions between the two companies :)

** They offer dual port, initialisable memory. [Not clear if this is from a ROM, or from a serial loader ]

They target $20-$100 / 10K chip sales.

Also claim this "Cost reduction and time-to-market are the basis of XPA-II's existence offering customers 0.15µm technology at one quarter of the NRE cost of a cell-based ASIC and one-third the cost of an FPGA in production. Prototypes can be shipped in as little as 21 days compared to standard cell ASIC lead times of 50-60 days."

These structured Metal-only ASICs are really MASK FPGAs. The test will be how much revenue this segment can generate.

-jg

Reply to
Jim Granville

Thanks. (Sorry if my post seemed insulting.)

I think I understand how to do it in the normal design flow. I was fishing for things around the edge that might not have worked as expected.

Maybe I've been looking at too many "typical" columns in the data sheets.

Could a customer write code that would detect when a redundant section was used? I'm thinking of something like measuring the "typical" prop times on a part and see if some section is way out of line.

--
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.
Reply to
Hal Murray

Rick,

Bad hair day?

Answers below,

Aust> Aust>

Completely different costs. You can not change silicon every week, but you can change BIST patterns. Patterns can be improved continually, which drives down costs.

So 98% is as good as you get in an ASIC, and we can get an arbritrariy higher coverage with no silicon area penalty. Then we can take our time to improve the patterns till they take very little time to run.

What does "unobservable" error have to do with this? I am talking about that last 2% of errors that ASICs do not catch, and could be observable (if they took infinite time, and infinite resources).

True, but then you have to see what the automation missed.

Unfair. ASICs do have fewer transistors to do the same job, but do not then use the fact that FPGAs have more to justify that ASICs have a better approach to testing: they do not.

A certain very lasge ASIC manufacturer might be adding FPGA cores to their ASICs, not for any direct customer benefit, but because it might be easier and cheaper with more coverage to test them that way.

Well, first off, the ppc, mgt, etc have no area (or cost) premium. In fact some would consider them free.

And the 'premium' you claim for FPGAs must not be much, as we keep selling them for less $$, and have more features with each generation.

Reply to
austin

Rick,

Configuration of a test pattern can make efficient use of our partial reconfiguration capabilities. I can not say how many seconds an FPGA spends in the tester, but it is less that an ASIC does. There also may be much faster ways to configure that we can use, but do not offer to customers.

Why can we do 1,000's of BIST patterns faster? Well one obvious reason is that a BIST pattern in a FPGA can run at the speed of the FPGA, which is often 10X to 100X faster than the tester. It might have to run for

1000 clocks to finish, and then go on to the next test, which might be different by the contents of a few LUTs.

If you are really curious of how we perform this magic, you can research all of our BIST patents and think about what you would do if you faced such a problem.

Again, Peter is right.

Aust> You may be convinced, but that is not the same as having facts. The

Reply to
austin

GS,

You are correct. FPGA devekopment can be done just as poorly as software code, and often is.

Aust>> The place where FPGAs win big is NRE, an FPGA design

Reply to
austin

Followup to: By author: snipped-for-privacy@soda.csua.berkeley.edu (Nicholas Weaver) In newsgroup: comp.arch.fpga

Right, but at that point you're screwing yourself anyway because of PVT variations. PVT variations are considerable in modern high-density processes, and unless you do as extensive a set of characterizations as the vendors themselves then you don't have much of a hope to get a handle on that.

Thus, redundancy timings is just one of many variables that vary from chip to chip.

-hpa

Reply to
H. Peter Anvin

Followup to: By author: snipped-for-privacy@bluepal.net In newsgroup: comp.arch.fpga

.... after you cross some volume threshold, which these days can be quite large.

Because it otherwise would be 20-40x premium?

-hpa

Reply to
H. Peter Anvin

I find that very hard to believe. Do you have any references to back up that claim ?

Reply to
m

Austin, if you don't know how much time it takes to test your FPGAs, then how can you possibly say it is faster than an ASIC that you also don't know the test time for??? I think you and Peter are talking through your hats on this one. Much like the other arguments that FPGAs are better than ASICs that pretty much ignore the fact that an ASIC can be done using several generations older technology to get the same overall costs. Your 90nm chips may be very dense, but they are using the most expensive equipment around and automatically have a 10:1 hit in most areas of cost.

I am sure Peter is right about a lot of stuff. But you don't provide any information that shows he is right about this.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX
Reply to
rickman

Austin, Peter sends me private emails asking me to ignore your nonsense. He tells me you are a valuable asset to this group because you have significant knowledge. But your BS is enormous. This comment is the sort of thing that is not welcome in the group, at least by me. If you want to discuss the issues, then leave the crap at home. I find you to be a very unprofessional representative for Xilinx and I have even told my local sales people that. I don't know if this ever makes it back to your managers, but I sincerly hope that I never have to depend on you for any sort of support. In fact, you personally are one of the reasons that I keep looking at the solutions offered by Altera, and have ended up filling at least one of the sockets on our boards with an Altera part.

Your reply is a non-sequitur. No one is talking about changing silicon. The tests are data that are used to drive the signals to the chip and examine the outputs from the chip, be it an FPGA or an ASIC. The cost of silicon is the cost of making the chip which is a function of silicon area among other things. As has been pointed out, the silicon area gives ASICs a 10:1 advantage in cost that part of the cost.

Where did you come up with the 98% figure??? Test coverage is a function of the test, not of the chip or the technology used to make it.

Why would it take an "infinite" amount of time and resources? The only limiting factor is the cost of testing vs. the cost of missing a fault.

The software *measures* the coverage that the tests provide. What are we not communicating?

I have no idea what you are talking about. An ASIC has a 10:1 silicon area advantage over FPGAs. I never said they have a "better" approach to testing. I simply said that you only have to test an ASIC to the specific requirements it was designed to. An FPGA must be tested to assure that all the many different potential designs will work. I have also acknowledged that an FPGA can be custom tested to the specific ASIC-like design a given customer may have for it. But then you are doing the same tests that they do on the ASIC.

Does Xilinx consider them free? I doubt it.

So an FPGA sells for the same unit cost as an ASIC? Too bad my local sales office has not learned about this. They keep quoting me FPGA prices!

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX
Reply to
rickman

Whoa, Lighten up guys!

Austin may not be destined for a job in the diplomatic corps, but he does provide useful information.

I believe any discussion that tries to place ASIC and FPGA testing in the same pigenhole is going to founder. Yes, ASICs are smaller, but FPGAs can use their own fabric for testing. Sure, FPGAs use more expensive process, but does the end user care what process their chips use ?

FPGA vendors have a very stong impetus to get very good at test coverage, whilst to the average ASIC user, testing is not given the same engineering resource.

Thus it really is comparing apples and oranges.

-jg

Reply to
Jim Granville

Rick,

I can not say how long, because that is proprietary information.

I know exactly how long it takes to test the CLB, BRAM, DCM, PPC, MGT, etc.

Exactly.

Aust> aust>

Reply to
austin

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.