Sign In
Forgot Password?
Sign In | | Create Account

To Waive Or Not To Waive?

That is the question!

If you read my colleague John’s most recent posting “Waive of the future?”, you will understand the question. I was equally shocked as John to find that almost no one tapes out DRC clean anymore. I would add one other reason to John’s list as to why this has happened. I think the traditional DRC rules are broken. Please read my first post “Are Design Rules Broken?” for my stance on this one.

I can understand it from the standpoint of recommended rule violation as no one expects you to always follow the recommended rule but to follow them as often as possible without giving up area. Being so focused on yield over my career, I have focused my EDA tool development on finding better ways to encourage people to follow recommended rules and made the assumption they always followed the design rules. In the process I missed the biggest new problem in physical verification. People just want to know which rules (design or recommended) they can ignore. Deciding which violations to allow is a bigger problem to design teams than deciding which ones to fix! When I think about it from a human behavior standpoint I guess it makes sense. Most people are more interested in identifying work they can “get out of ” as opposed to extra credit work they can “volunteer to do”:P 

The key to deciding which violations to waive rests on the same manufacturing reality that nothing is black and white. All violations are not created equally. Design (recommended) rule checking must evolve beyond the pass/fail approach. All violations should be assessed on the grounds of yield, reliability or circuit performance risk. You should always attempt to fix the violations in order of risk until you have the smallest set of lowest risk violations you can. Then the fab engineers or design management team and evaluate the remaining risk to make an informed decision about whether to allow the remaining violations as waivers. It was in this revelation that the new Calibre functionality like Equation-Based DRC (eqDRC) and Critical Feature Analysis (CFA) was born.

EqDRC allows the rule writer to not only check that a feature meets a minimum requirement, but to mathematically grade the violation in reference to the design rule and/or recommended rule requirement. The “grade” could be as simple as a delta from required value or a more elaborate measure of actual risk based on failure probability or performance loss, etc. The benefit is best captured in the following picture:

graded-violations

Admit it we are all engineers at least at heart, so it is much easier to convince someone to “let” you waive a violation if you can show them data. By looking at the histogram the reviewer could quickly focus on the worst of the errors. If they are comfortable with those then they might readily waive the entire set. There is also less chance that they miss looking at an important error that they should not let you waive. Waiving does you no good if the chip doesn’t yield.

The Critical Feature Analysis functionality that is supported in Calibre YieldAnalyzer takes this idea to the next level. It enables statistical roll-ups of impact, interactive and batch reporting of charts, tables, etc. In the case of recommended rules for instance you could calculate a cumulative impact of each of the graded violations and if the “score” is less than some threshold then it is ok to tape out. It is also nice to generate batch html reports of the final statistical scores for management review and historical records.

Are you facing these types of issues in your designs? I would love to hear what you think about this issue and if you think these type of things would help. By the way I am giving various presentations at DAC on eqDRC. There is a presentation in the Mentor Booth each morning at 9am. I am also presenting in the DAC Theater in North Hall, Booth 4359 at 2:20pm on Tuesday of DAC on the subject. I would love to have you come by and give me some feedback face-to-face. Just don’t slap me:P

IC Verification, IC Design, Design Quality, Design for Manufacturing, Design Rules, DRC, Physical Verification, Design Rule Checking

More Blog Posts

About David Abercrombie

David AbercrombieI am the Advanced Physical Verification Methodology Program Manager at Mentor Graphics in Wilsonville, Oregon. For the last five years at Mentor I have been driving the roadmap for developing EDA tools to solve the growing issues in design to process interactions (DFM) that are creating ever increasing yield problems in advanced semiconductor manufacturing. For the previous 15 years I drove yield enhancement programs in Semiconductor manufacturing at LSI Logic, Motorola, Harris and General Electric. I also led software development teams in delivering yield enhancement and data mining solutions to semiconductor manufacturing. I hope you will read my publications and patents on semiconductor processing, yield enhancement and EDA verification solutions. I received my BSEE from Clemson University in 1987 and my MSEE from North Carolina State University in 1988. I love to play the guitar, explore the great outdoors, and watch a great science fiction show. Visit David Abercrombie’s Blog

More Posts by David Abercrombie

Comments 2

Post a Comment
We were waiving DRC violations back in 1978 at Intel while doing DRAM designs. Owning the fab meant that we had some leeway with DRC rules and just talked it over with our buddies running the fab.

Daniel Payne
12:35 AM Jul 3, 2009

Hi Daniel! You are correct about memory designs. We have been pushing those past design rules for many years. However, in those cases we usually hand crafted the layout with alot of mfg input and then ran them separately on test chips to silicon verify them before we used them in product. We can't afford silicon validation of everything today. Also, with the everyone going fabless it gets more difficult to just talk it over.

David Abercrombie
4:54 AM Jul 6, 2009

Add Your Comment

Please complete the following information to comment or sign in.

(Your email will not be published)

Archives

Tags

 
Online Chat