“Waive” of the Future?

Many, many years ago, when I started in this business, I encountered something that I thought was surprising.  In my very first DRC benchmark, I was struggling with a particular rule.  The customer had given me a 0.25 micron layout, which they had successfully taped out.  My job was to write a rule file in the new tool to measure performance improvement.  My code matched the design rule manual and passed all the regression tests.  But, it seemed that no matter how I tweaked the coding of a paritcular rule, I kept flagging an error.

Finally, in frustration, I asked the layout designer to help explain what I was doing wrong.  That’s when he hit me with “Oh, don’t worry about those errors — we waived them with the foundry”!  I was flabbergasted.  You mean you are not really DRC clean, but you taped-out anyway??  And the chip actually worked??  How could this be?  I later came to find out that, although this was rare, it did happen from time to time.

Now fast forward a dozen years, and quite a few more gray hairs, to the present.  In the past 3-5 years, it seems I have not encountered a single full-chip layout design that does not have “waivers”.  Worse, it seems that some layouts can have hundreds, maybe even thousands of these waived results!  A” waiver” is a DRC violations that the design team negotiates with the foundry to accept anyway.  So what gives?  Does “DRC clean” actually exist anymore?  What really is required to tape-out successfully?

The first question is probably the easiest.  Why are there now so many results waived?  There are a couple of inter-related reasons.  First, there are many more rules than ever before.  As a result, in a congested layout, it is sometimes difficult to correct one violation without creating a different violation without a significant redesign, but this means a serious delay in time to market.

Secondly, and related, is the fact that the rules are now much, much more complex, with multiple layer and geometrical dependencies.     Just understanding the requirements is difficult.  Debugging can be a very time consuming process.  Again, it is difficult to make a correction without introducing a new violation.  What I find most interesting is that part of the reason for the complexity of rules in the first place is an attempt to weed out corner cases that might result in false violations in the first place!

Finally, a big reason for waivers is the advent of “recommended rules”.  These are DRC rules that are not required, but, as the name implies, recommended.  They often are standard DRC rules, but with a larger margin in measurement.  These were introduced to the world at 130 nm and have grown with each release.  The bane of many layout designer’s existance, recommended rules have caused lots of issues.  Why?  Because you often get lots of violations in cells that have already shown good results in silicon that you cannot edit, and because there is no enforcement of the rules.

Customers tend to handle recommended rules in one of two ways:  1) Ignore them altogehter or 2) Use these as their DRC constraints instead of the actual DRC constraints.  If you go with approach #2, then you are going to have tons and tons of violations.  Again, many of these will be associated with IP blocks that you know have worked in other designs in the past and which you cannot just edit.  So, what do you do?  You waive them!

So, now we know why there are so many waived DRC violations in nanometer processes.  It seems DRC clean really no longer exists, instead what we’re attempting is  “DRC clean enough”.   But, is it really clean enough?  Just how does the foundry determine if a particular result is uber dangerous or just marginally material?  If there is a way to determine this, why can’t the designer just make that determination independently of the foundry?  All good questions and fodder for a follow-on blog.  I’m going to tee up my buddy Abercrombie to lean into this pitch! :)  I’ll give you a hint, come see the Mentor Graphics DAC suite session or DAC workshop on eqDRC!

The next question is, assuming that the designer and foundry have negotiated and agreed that a certain violation can be waived, how do you safely capture and pass that information?  You certainly don’t want the poor layout designer doing full chip integration to have to look at every violation and decide on his or her own whether each one represents the agreed upon waiver.   But, you also don’t want to waive a result in IP that was created with version 0.1 of a rule file in version 2.0 of the rule file if the check requirements have changed.  This is also a topic for a future post.  And yes, you can also learn more about this at DAC by coming to the Mentor Graphics suite presentation on debug and waivers.

Yes, I’m using my blog post for gratuitous pitch to come to our sessions!!!  Hope its informative never the less.  Now I’ll “wave” good-bye.  Hopefully you are waiving back with more than one finger! 😛



Post Author

Posted June 30th, 2009, by

Post Tags

, , , , , , , ,

Post Comments

1 Comment

About John Ferguson's Blog

Will provide insight into the challenges and requirements of physical verification across multiple process nodes. We'll explore new requirements, solutions and challenges. John Ferguson's Blog