Stop Paying the DRC Waiver Productivity Tax

Historically, design rule checking (DRC) was a black or white proposition—either you passed all your DRC’s or you fixed the errors until you did pass.  Fast forward to today where much/most of the IP you use is from 3rd parties and/or your product has an increasing percentage of memory content and your design is never DRC clean at tape out.  Your design team is now constantly waiving over and over and over the DRC results in known-good IP or memory.  Your design team pays this productivity tax for every DRC iteration of your design at the cell, block and full chip levels.  For advanced design teams this can mean one of two things: 1) your team is either waiving tens of thousands of DRC results for every design or 2) your team has cobbled together a flow that attempts to waive DRC results but is likely also putting your design at risk by waiving real DRC errors in the process.  Neither of these situations should be tolerated if there is an automated solution that manages removal of DRC results in known-good IP without the risk of waiving real DRC errors.

 

Why Are Waivers A Growing Problem? 

DRC waivers are increasing due to the trend towards larger SoC designs that incorporate a growing amount of custom and 3rd IP, or memory. This IP may have been designed during different versions of the target foundry’s design rule manual, or for slightly different processes, resulting in current errors even though the design had been proven out in previous silicon.  Another significant factor is the increase in foundry second-sourcing. Each foundry has different design rules, but competes for the same designs. To win business, a foundry is often willing to accept a design or piece of IP that does not meet its own design rules. Finally, in advanced technology nodes, the design rules are getting so numerous and complex that it has become impossible to meet all of them and still satisfy the performance and time-to-market requirements.

 

How Waivers Impede the Verification Process

Handling waivers is a weak point in many IC design flows. Typically, when IP with waivers is provided to another team for incorporation into their designs, the waiver information is neither transferred in a consistent manner, nor in a format that allows for easy identification of the waived errors by the DRC process of the receiving design team.

The lack of standardization and automation of IP waiver processing means that previously waived IP errors usually reappear at the end-user of the IP. Without any indication of their waived status — they just look like new DRC violations.

 

Everyone Pays the Waiver Productivity Tax

Today, everyone in the IC design and manufacturing food chain needlessly pays this productivity tax – over and over and over. 

IP Creator and Fab/Foundry:  To be competitive and create the most compact IP possible, IP creators push the limits of DRC constraints.  They work with the fab or foundry to validate that their designs are manufacturable.  When their IP fails DRC checks, the IP creator and the fab/foundry agree on waivers.  As noted above, these approved waivers are not effectively communicated forward to the designer who just sees these DRC results as more DRC errors to be debugged.  During the entire lifetime of the IP’s use, the IP provider and fab/foundry continue to pay the waiver productivity tax by having to repeatedly explain to every design team how and why these results are waived.  This is a significant customer support and product engineering burden.  This is a tax that these companies (or organizations) need not pay if waiver information was effectively communicated forward the first time. 

IC Designer:  The reappearance of waived errors creates two productivity taxes for the designer. First, because waived errors are indistinguishable from other DRC violations, the designer spends the same amount of time and energy debugging an already-waived error as for a true error. Second, when IP DRC errors are identified during full chip DRC, the designer has no choice but to contact the IP provider and/or fab/foundry, which usually results in time-consuming discussions between the integration designer, the IP provider and the fab/foundry, just to validate the waiver again and again and again.  Some companies also pay a third tax.  They cobble together flows using blocking layers over known-good IP as a way to reduce the number of DRC waivers that needed to be waived over and over.  This tax is measured in the engineering labor dedicated to the creation and maintenance of these partial waiver flows.  The dirty little secret is that such partial waiver methodologies also waive REAL DRC errors created when the IP is instantiated in a real design or when other geometries interact with the IP.  So not only are you paying the waiver productivity tax, you are also releasing designs to production with potentially design-killing errors.

 

Why is this Productivity Tax So High?

The waiver productivity tax is so high because you keep paying the tax over and over and over.  Consider the illustrative example below where a design is comprised of thousands of instantiations of Standard cells, tens of Small Functional blocks, tens of Large Functional Blocks for one Full Chip. 

Waiver Productivity TaxIn a typical design, your team will do tens of DRC iterations for each component.  Each component (i.e. Standard cell, Small Functional block, Large Functional Block and Full Chip) in your design may have as little as 1 or 2 waivers for small components to as much as hundreds of waivers at the Full Chip level.  Multiply this all out and for one design development program your team may be waiving tens of thousands of DRC errors.  For each error, the designer must spend time debugging the error to determine if it is real or if it can be waived.  Obvious errors may be waved in seconds but non-trivial ones may take minutes to tens of minutes.  With these huge numbers of waivers per design and a growing debug time per waiver, your design team is wasting huge resources on this tax without adding any value to your end product.  Further, all the back and forth between your designers, the IP provider and the fab/foundry slows down your development process.  Wouldn’t it be great is you could stop paying the waiver tax.

 

The Industry Requires an Effective Solution

The industry needs a better way to manage DRC waivers.  This is especially true with the growing predominance of the fabless model and increasing use of third party IP.  Unfortunately, prior attempts at solving the problem have been plagued by significant weaknesses and have not caught on. The key requirements for a complete solution include:

  • A simple way to capture and communicate the waiver information without requiring new data types or additional files that the designer would have to manage.
  • A simple way to associate the waivers with specific layout structures so the designer does not have to do outside “bookkeeping” to keep everything straight.
  • The ability to deal with design hierarchy and the subtle variations that occur when a physical structure is placed in different contexts within the full design. This requires the ability to set some error margins to discriminate against false positives.
  • An audit trail to support a quality control process, including a record of documented waivers that aren’t used. (It may just be that in context the structure is not an issue, but it also might indicate a problem.)
  • Minimal impact on DRC runtime.

 

The Foundries and IP Providers Must Also Participate

No matter how sophisticated the technology, however, a robust solution requires that the IP providers include waiver information into their IP datasets. This ensures that accurate information is included with the IP at the source and saves customers from having to do this task over and over on their own. The responsibility for this falls on the third party IP providers and foundries. If this is done up front when the IP is qualified for various manufacturing processes, it can save the design customers untold hours of wasted effort and delays.

A solution to this problem is now available.  IP providers have the opportunity to reduce their own workload with the manual/dysfunctional processes currently in use.  Further IP providers can differentiate themselves from their competitors by simplifying their end customer’s PV flows and dramatically reducing the time to market of their end customer’s designs.

As time to market becomes the gating factor that determines the market success and profitability of an IC, any process that reduces design verification time while simultaneously improving the quality of results is highly advantageous. The industry needs automated IP waiver management not only to eliminate time and effort that adds no value to the verification process, but also to ensure accurate processing of all waiver information on every DRC run. It’s time to stop paying the waiver productivity tax. 

Death to taxes!

 

Want to learn more about the solution?  Take a look at John Ferguson’s blogs at:

http://blogs.mentor.com/johnferguson/blog/2009/06/30/waive-of-the-future/ http://blogs.mentor.com/johnferguson/blog/2009/07/21/waive-bye-bye/

 

Post Author

Posted January 15th, 2010, by

Post Tags

, , , , , , , , , , , , , , , ,

Post Comments

3 Comments

About Michael White's Blog

Provides a vision into the future trends of physical verification (PV) and how innovations in PV can impact your company's competitiveness and bottom line. Michael White's Blog

Comments

3 comments on this post | ↓ Add Your Own

Commented on January 18, 2010 at 11:08 am
By Waive Bye-Bye « John Ferguson’s Blog

[...] my last post I and in Michael White’s reccent post discussed the reasons and challenges associated with “waivers” for DRC.  As discused, [...]

Commented on December 15, 2011 at 7:15 pm
By Rosario

Great article Mike. So true, especially now for ESD drc (extra special delay) rules!

Commented on February 25, 2013 at 6:21 am
By additional reading

My family members always say that I am wasting my time here at net, however I know I am getting know-how everyday by reading thes fastidious posts.| additional reading http://dlkfsldkflksdlk.co

Add Your Comment