DFT drives yield improvement (continued)
A continuation of our interview with Robert Hum, VP & General Manager at Mentor Graphics, which appeared in the August 2005 Viewpoint column.
-- Test & Measurement World, 8/1/2005 2:00:00 AM
Click here to read the first part of the interview.
T&MW: Could you describe Mentor's product offerings in more detail?
Hum: When we talk about verification, we talk about design verification, and when we talk about test, we talk about manufacturing test. On the design-verification side, ModelSim and Questa are our functional-verification products. There are more copies of ModelSim in the market than of any other simulator. Questa is a new product that we just launched--it serves the System Verilog market, and it is a pretty spectacular upgrade to the ModelSim product.
Assertion-based verification products and static verification tools for things like clock domain crossing are in our 0-In line. We also have a series of analog products. My colleague Jue-Hsien Chern [VP and GM of Mentor's Deep Submicron Division] is in charge of products like Eldo, a fast Spice simulator, which we sell in conjunction with ModelSim and Questa. We also have a number one position in hardware-software coverification with a product called Seamless, which also works with ModelSim. So, if you're a designer who's designing an embedded system with something like an ARM processor or the [Texas Instruments] OMAP complex, you can verify your RTL with ModelSim while using Seamless to verify the embedded software you've written for it, allowing you to parallelize your software and hardware design, as well as improve full-system verification
We also offer a hardware product called VStation, which serves the emulation market and targets people who need to do huge 60 million to 150 million-gate simulations with ModelSim or Questa. As of January 1, we were the number one verification company in the world; we passed Synopsys in the fourth quarter of last year in terms of the breadth, depth, and volume of product we have out there.
On the test offerings, we also have the number one position. The test products we have are FastScan and TestKompress as well as BIST products for both logic and memory. We also offer a boundary-scan product called BSDArchitect, and we have a scan-insertion product and various debug products. And by the end of the year, we will be offering an advanced diagnostic product to help people do yield ramping and yield improvement.
T&MW: I've gone through design and verification and my first silicon doesn't work. How can Mentor tools help me?
Hum: If your first silicon doesn’t work, you have to figure out whether you have a physical problem--your layout has errors, the mask shop made a mistake, or you somehow got a library component that doesn't quite work--or a functional problem. On the physical side, you can use the Mentor design-for-test tools to verify whether or not the design does what you captured with your RTL. If you are using scan design or BIST, it's pretty straightforward to sit down at a tester and say, well, I'm testing my design and it passes all my tests, so therefore I have to assume that there must be some logical problem that I've introduced somewhere.
If you find out through the DFT tools that your design doesn't work--in other words, if you fail all your tests or some of your tests--then you have a layout problem, a mask problem, or your foundry or library vendor did something bad. We had a recent case with a large foundry and a large telecom company where 40% of all the failures failed on one test vector. They weren't using Mentor tools but did contact us and ask for help. We generated some very special test vectors, and in about an hour we were able to tell them there's a short between these two nets, and showed them where it was on the die. Sure enough, they went in with a scanning electron microscope and, behold, there was a short. That was an example of something going wrong during the mask-making process.
We have other customers who say, “It's not mask-making, it's something else.” Then you have to go back to your RTL and your design files and start hunting down exactly why your design doesn’t work. There are lots of diagnostic tools that we have that come with ModelSim, Questa, and 0-In, and, in fact, these days people are starting to use so-called embedded assertions to make their lives a lot easier in hunting these sorts of bugs down.
For dead-on-arrival parts, half the time if it's not a physical problem--it's some kind of clock-domain crossing problem. These days, chips have 50, 60, 70, 80 clock domains, and it's not trivial to get all your synchronizers working properly and all your clock-domain handoffs working properly. In the past, what people did was use simulators to try to find out whether all their domain crossings work out, but there are so many of them today, and it’s really hard to write enough test benches to check all these domain crossings. People do the best that they can, but it’s an overwhelming problem. So what happens is about half the functional failures we see are domain-crossing problems.
In the acquisition we did last year of 0-In, one of the tools we acquired that is very exciting is called CDC--for clock domain crossing--which is a static formal-analysis tool that doesn't need a test bench. Today, what designers can do is say, “well, rather than try to find these problems in simulation let me run this static clock-domain-crossing tool, and I'm guaranteed to find 100% of my domain-crossing issues in a few minutes.” It takes about five minutes per million gates to run a tool like this, whereas in simulation, you have to write a test bench, you have to make sure your test bench gives you the coverage you need, and then you have to run this at 10 to 20 cycles per second. You could be running for days and still not find the problem.
T&MW: What are the most common problems that require a mask re-spin? Are they OPC related?
Hum: On mask side, people just don’t omit running OPC. At certain geometries, you just have to run it. Usually what happens to you on a mask is, you re-spin because if you change a certain feature you will get more yield. Often, when the layout is almost complete, you decide you need slightly larger buffers here or to balance your clock tree there, and some of that you do with hand edits. Then you run a logic-to-schematic checker to make sure you haven't messed up the netlist, but every now and then problems creep in. It may be that you've messed up the connectivity, but usually what happens is you find out you have a timing problem. So you find out that, "well I've balanced my clock tree, I've done my layout, I've extracted all the parasitics, I've back annotated, I've run static timing tools, but when I got my silicon back the models weren’t quite accurate or the extractor kind of messed up a little bit, and I've got some skew here," and that leads to a hold problem or a setup problem.
So mask re-spins are generally due to some parametric problem. Usually you don't see real functional problems where you say, oh I wanted an AND gate and I stuck an OR gate down here. More likely, some parametric problem creeps in because the underlying silicon isn't modeled properly. In these modern processes you might find, for instance, that layer 6 metal may have slightly different characteristics than layer 5 metal. Even small changes from layer to layer will give you differential-capacitance effects and differential-delay effects, and some of these tools assume that, well, if metal 1 is slow then metal 2, 3, 4, 5, and 6 are too, but that just may not be the case. So you get skew and other issues creeping in that you may have to take care of.
T&MW: Can Mentor tools help with that?
Hum: Yes. For example, what makes Mentor’s Calibre tools interesting is that we've done a few things to make finding these types of problems easier. In the example I gave where the foundry was working with a customer and couldn’t find the source of defects for the part they were running, we correlated layout information with test information. From a customer point of view, what you really want is to be able to say, "I've got a layout, I've run Calibre on the layout, I've run OPC, I know what my mask is going to look like, and I know what my printed features look like. For some of the printed features, there's going to be a probability of having shorts and opens at certain sites. If I have two long wires that run parallel under certain geometry conditions, these wires have a high potential of shorting out. I need to be able to identify these locations and fix them.”
And in our DFT system when we generate test vectors, based on our analysis with Calibre, we can say if a short occurs it is likely to occur in this spot. We can generate a set of test vectors specifically to check whether or not a short has occurred. You can only do that if you can do the geometric analysis the way Calibre does and take that geometric analysis and feed it into your ATPG tools. So from the Mentor side, since we can interface these tools, we can help customers get better diagnostic resolution on where the issues are likely to be.
Once you use Calibre, you can decide you’re not happy that there's a high probability that a short is going to occur here, or that an open will occur there, so you can fix those before you go make a mask. What Calibre can do is show all the sites that could potentially have problems. And if you can do something about them before you invest a million bucks making a mask, you will go and do something about it.
T&MW: Who has responsibility for verification and test--separate teams, or is it a joint effort?
Hum: For a fabless semiconductor company people who do the layout run Calibre from a rules-checking point of view, and they are the ones responsible for OPC and RET [reticle enhancement technology] and so on. They don’t really get involved in the DFT side. They get rid of geometric problems by using via doubling or line spreading--everything they know how to do to get the best yield. They don’t need to talk to the DFT crowd.
The DFT crowd these days is part of the design crew. It's the designers who have to put in BIST and scan and compression and in general define the test strategy. When you put your part into production you get your first samples of silicon back, there is usually a product-engineering group that really understands how the tester actually tests things. This group understands what the test patterns are supposed to do and understands what designers have done in putting scan or BIST or compressed test into the part. They will get the first parts back and make sure that there is enough yield and so on.
In the very early stages the designers themselves get involved because everybody is so excited when you get your silicon back. Everybody wants to try it out, so you can bet that the designers are in the lab--they are playing with their parts. They are trying to understand whether they have done it completely right. When things fail, specialists show up and start hunting down what's going on.
This is when people with deep knowledge of how the scan system works come into play--people who can identify what's going on when for instance a part fails on vector 27 clock cycle 2314. These people will know what faults a particular vector was supposed to uncover and can run a diagnostic package and see whether there's a correlation between the geometric side of the design and the logical side of the design. In general, it's a distributed responsibility, but all the participants make up a pretty tightly knit team, from what we see at our customers.
T&MW: You mentioned the role of TestKompress on reducing test time. Can you elaborate?
Hum: A side effect of reducing test time is that TestKompress also gives you compressed vectors--it uses up far less memory on your tester. We get 80 to 100X compression, so we can reduce the functional test time by 100X. TestKompress is unique in that regard. Our competitors have compression products on the market that reduce the memory needed on the tester but have no impact on test time. So looking at vector compression is only one-tenth of the problem. The other nine-tenths of the problem is overall test time.
When people benchmark these tools they need to be careful that they are not just looking at compression, which is interesting because it does save you money on the tester, but if your test time is absolutely enormous you’re still tying up that tester for quite a long time. One of the reasons that the test-vector sets are so large these days is because of new emerging faults in low-k dielectric-based processes. In these processes you tend to get a lot more interlayer shorts, and you get a lot more intra-layer opens. In the old days we were quite fortunate--we could test almost everything with the SSA [single stuck at] fault model, and we could generate a set of test vectors and do fault simulation and find out we have 99.9% coverage. These days the problem is that if all you're testing for is SSA faults, you will not find all your bridging faults, you will not find all your opens, and you will, in fact, be shipping defective parts.
Today automatic test-pattern generators generate vectors that cover these new faults. If you have a look at a schematic and you say, “let me generate vectors for bridging faults,” you'll find that the number of bridging faults is absolutely enormous. However, if you look at the layout you can say, “well, these two wires never come close to each other so there can't possibly be a bridge here, so I'm not going to generate a vector for a bridging fault between these two signals. But, aha, these other two signals have a possibility of shorting because they run in parallel or they cross paths.” Once you look at the geometry of the layout you can then really pair down the list of what faults you actually go after. So we are doing things to give people the smallest possible test sets with the highest possible fault coverage.
T&MW: What are the prospects for logic BIST taking on functions that scan and compression now perform?
Hum: From the mid '80s to late '90s, BIST for logic was a promising technology, and the number 1 company in that field has been LogicVision. Curiously, the technology seed for LogicVision came from a lab I ran at the time at Bell Northern Research Northern Telecom in Canada. I knew [LogicVision founder] Vinod Agarwal, who was a professor at McGill University, and I helped him launch that business.
But there are windows of opportunity where a technology works well, and there are times when windows close. For example, pre-'91, event-based fault simulation was the way to go, but these days everybody does static timing analysis and RTL simulation--things change. As for BIST, it relies on pseudorandom patterns generated internally. Pseudorandom test vectors are pretty good for checking for SSA faults, but they are practically useless for checking things that need correlated patterns. If I want to find out whether two lines are shorted together, what I need to do is drive one line to logic one and the other to logic zero, and if I have a short, those two lines will have an intermediate value. If I use pseudorandom patterns that happen to charge both lines to one or discharge both lines to zero, I will never find a short between them. So at 130 nm and below, logic BIST no longer has the properties necessary to check and test for those faults that actually occur in manufacturing.
In about 2000 or 2001, the world started to turn its back on BIST because it no longer had the resolution necessary to test for kind of defects that were actually occurring. Of course, there are valid uses of BIST--my initial manufacturing test may be based on based on ATPG patterns, but then when I ship my product into field I would like to have a quick diagnostic that I can run to make sure my die is still okay. Reliability failures you get in the field have a different fault spectrum than the manufacturing defects you get in production. It may be that BIST does a reasonable job on the reliability-induced defects that happen post manufacturing, and some people have this two-tier approach.
The other reason to you might want to use BIST is that you are a smart-card manufacturer and you don't want to expose the card's internal logic to the outside world where people can hack it. You can use BIST to obscure everything. That said, if you are using compressed patterns with a product like TestKompress, there's enough obscuring that happens that it is almost impossible to hack through the pattern compressor to figure out what's going on inside.
The conclusion is that BIST fell by the wayside because of changes in the underlying manufacturing-defect spectrum. BIST does not have the resolution anymore to do what's needed. It was a promising technology that will now only serve niche areas. It is, for example, very effective for memory.
T&MW: How important is a unified, single-environment design flow?
Hum: What people look for is the ability to buy the best tool available to do the function they want while being able to interface to other tools. What's critical is that vendors support standards. What hurts customers, and I was a purchaser of EDA tools at Nortel, is when a vendor has a proprietary something or other and prevents other vendors from interfacing with it--that is the worst of all worlds. When faced with that at Nortel, we always felt we were being held hostage.
What Mentor does particularly well is support standards. For example, a person on our staff, Dennis Brophy, serves as chairman of Accellera [an organization that promotes standards for language-based design-automation processes]. In fact lots of my engineers serve on standards bodies. Vendors should stop trying to get locks on customers by maintaining proprietary formats and preventing people from buying best-in-class tools. I'm a believer that best-in-class tools that interface with other best-in-class tools through standards are the right way to do things. One thing driving System Verilog today on the verification side is that customers don’t want to be held hostage by e or Vera. System Verilog opens the standard up and says what is important is that your test bench is portable, your assertions are portable, and let us compete on the quality of our tools and the quality of our algorithms and the speed with which things execute. Quit trying to paint people into corners. The first chance they get, people are going to escape. I'm not a believer in buying everything from one vendor because it's an integrated environment. No one vendor is good at everything.
T&MW: Can you elaborate on your comments about test-bench languages like e and Vera?
Hum: Consider the company TSSI [which through a series of acquisitions became part of Credence Systems]. TSSI had come up with a way of writing functional test vectors for specific testers. Like e and Vera, TSSI helped people be more productive writing functional tests, but it didn't solve the underlying problem of functional test itself. What was really needed was structural testing, because the kind of defects occurring in manufacturing processes were physical defects that you could not find effectively with functional test patterns. That's when scan design came in. You don't write scan vectors, you generate them with ATPG. Scan changed the test industry fundamentally. It lead to higher fault coverage and other things that TSSI's test-vector-capturing language didn't do. So TSSI's approach is similar to e and Vera. They don't represent the paradigm shift we see today in verification, which is now based on embedded assertions and the use of static analysis tools that will let you verify your design without simulation.
T&MW: What are causing today's yield problems?
Hum: Processes at 130 nm and below have several new issues that limit yield. To mention two: electrical characteristics of the various metal layers do not track uniformly, and OPC calibration does not cover all corner cases.
We think you need to take volume production parts as they go through your fab line and collect data from these manufactured parts to understand where the systematic yield detractors are. In the foundry and customer example I cited earlier, 40% of failed parts failed on one vector. The root cause was one design rule that should have been there but wasn’t. The foundry never suspected that this particular kind of geometry could happen in the layout. There was no rule specifically preventing somebody from implementing that kind of geometry, because nobody thought of it.
You need to take manufacturing-volume parts and instrument them enough to extract data and then use a data-mining process to identify systematic issues. When parts come back and you find yield is not where you want it to be, you need to you have a way of performing diagnosis that doesn't take six to nine months. These days if you have a 40 million-gate chip, how do you know where to point your scanning electron microscope to look at the one or two defect areas that are giving you a yield problem? In the old days with a few layers of metal it was easier to see what was going on.
If you use scan design, for example, and we have access to a layout that Calibre can read, we can do things like very specifically generate test vectors to test for faults that are electrically, from a failure-analysis point of view, almost impossible to see because they are obscured though layers of metal. We will be able to point people to areas where these failures happen. Clearly, we can’t get at all failures because there will be things that may not be diagnosable through a scan system. Our hope is that if parts are being shipped and you can data-log test results for tens of thousands or hundreds of thousands of parts you can say, “look, 20% of failures result from a short or open right here”. And if you want you can say, “well we are going to do a little mask tweak here and fix this.” And then you can create a rule so that the next mask set you generate will check for that a priori so it doesn’t happen again. That's what we think will help.
T&MW: Could you elaborate on the next level in DFT and its applicability to yield enhancement?
Hum: Today, your failure-analysis lab can maybe do three or four parts per month to identify yield problems. The future of DFT is that you'll be able to diagnose hundreds of thousands parts per month to get at these yield limiters. The next level of DFT deals more with how you provide feedback to the front end of your process to make sure your yield goes up rather than just go/no-go testing. Of course, you'll still need go/no-go testing and vector compression and so on--these things will be the table stakes that get you in the game. Once you have that, you as a customer have invested in scan; you now have silicon area committed to doing things that are not part of the function of the design and that are there just for manufacturing test. We can help you get tremendous value out of that investment by using it to help drive yield. You will be able to use your embedded DFT and tools like Calibre to get several points of yield improvement. The key is that DFT starts playing with other parts of your design cycle and provides the feedback necessary to guide the changes necessary for better yield and quicker yield ramping.
Click here to read the first part of the interview.
No related content found.
- 0 rated items found.
Datasheets.com Electronic Parts & Inventory Search
185 million searchable parts
- Part Number
- Description
- Inventory
- Products
- Manufacturers
View All Webcasts
