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.

30 March, 2010

In both my last post, and in John Ferguson’s posts, the reasons, challenges and costs associated with “waivers” for DRC were discussed.  As we have both pointed out, this is a growing problem as the IC industry increases its use of 3rd party IP while simultaneously the number of waivers within that IP is also increasing – resulting in a sea of waivers to deal with. 

As we have deployed our Calibre Auto-Waiver solution, we have seen it can be used to form a closed loop communication system for waivers throughout their lifecycle.  As we first deployed we were focused on automatically managing the sea of waiver (or waiver information) flowing between the: 1) IP provider and the foundry/fab and 2) IP provider and the Fabless designer.  What we learned is that there is also a third waiver communication channel between the designer and the foundry/fab that could also be addressed – creating a closed loop system. 


Communication Channel #1: IP Provider to/from the Foundry/FabWaiver Lifecycle

Before an automated solution was available, this channel relied on text documents, emails and telephone calls to: 1) request what waivers might be approved by the foundry/fab and 2) communicate which ones actually are.  Approved waivers are a function of the technology/process of the IP library AND the version of the physical verification deck.  Both of these will change as a given technology node matures.  This ensures that there is a sea of waiver requests / approvals flowing back and forth between the IP provider and the Foundry/Fab today.


Communication Channel #2: IP Provider to the Designer

Again, without an automated solution this channel also relied on text errata sheets, emails and telephone calls to communicate what IP waivers have been approved by the foundry/fab.  We have seen three big issues with this current communication channel: 

1.      Development and use of errata sheets, etc. is very slow, inefficient and tedious for both the IP Provider to create and for the end designer to try and use. 

2.      The errata sheets, etc. used to communicate waivers are more often than not created and then rarely/never updated for that technology node – hence they are incomplete and out of date.  Also, we have seen many IP Providers charge end users big bucks for updates…

3.      The IP library is created and waivers are defined at the very beginning of a technology node.  The process, design rule manual and the DRC deck are immature at this point in time and will evolve significantly over time.  What this means is that the waivers documented in the errata sheets are often very different than what a design team actually sees on their screen – hence not very useful. 


Communication Channel #3: Designer to/from the Foundry/Fab

At advanced technology nodes, every design taped out includes waivers that are approved from the foundry/fab.  Until an automated solution was in place, this channel relied on text documents, emails and telephone calls.  Poor communication within this channel on waivers can be the difference between a design that will yield and one that won’t.  This is especially a concern when companies use error markers over entire cells as a waiver mechanism.  This commonly used methodology will also waive real errors if that cell improperly interacts with other elements within the design.  Such a methodology can easily result in real errors slipping through and not being found or found very late during manufacturing – resulting in (best case) huge schedule delays and (worst case) bad chips.  It was one of our lighthouse deployment customers who raised our awareness of how our current Auto-Waiver solution could also be used to address this final leg of the waiver lifecycle – creating a closed-loop system.


What Does “Nirvana” Look Like?

The system we created allows us to capture and communicate waiver information without new data types or additional files, and in such a way that the waivers are associated with  specific layout structures.  This implementation allowed us to avoid the need for additional files that the designer would have to manage, ensure that the waivers and the IP remain in sync, and to avoid the risky use of marker layers as waivers (that waive all results both waived and real DRC errors).    

We found that same Auto-Waiver system can be used to streamline communication between the: 1) IP provider and the foundry/fab, 2) IP provider and the Fabless designer and 3) the designer and the foundry/fab.  All of the parties in this lifecycle benefit by spending less time managing and communicating waivers and there is a far lower risk of miscommunication than what they all endured using manually created text documents, errata sheets, emails and telephone calls.   

One further benefit we hope to see in the future is better synchronization (and regular update) of IP libraries and the associated waivers through as the process matures.  With the simplification in the creation, management, and communication of waivers we have delivered – this ought to be more easily achieved by the IP Providers and Foundries but only time will tell.  I will save this topic for a future blog.


Want to learn more about waivers and how to reduce their impact, see http://blogs.mentor.com/johnferguson/blog/2009/07/21/waive-bye-bye/.

, , , , , , , ,

28 January, 2010

Design rule checking (DRC) or physical verification used to be easy.  For example, run some 1-D width and spacing checks to ensure things will resolve and won’t short and you are good to go.  These checks were simple to write, fast to run and understandable, and quick to debug.  Today is a new world order, where none of these attributes are true anymore.  An increasing number of checks are 2-D, very complex to write, slower to run and increasing difficult to debug.  Pattern matching has the potential to be a game changer by simplifying advanced checks, making it easier to develop/maintain them, produce smaller DRC decks that run faster, and make debug simpler: maybe not a complete solution for world hunger but certainly is a real win for today’s IC designer – enabling the designer to go from a dirty design to tape-out faster.

 Why is DRC Becoming So Hard?

In a nutshell, because the IC lithography industry has not delivered resolution improvements as fast as Moore’s law has shrunk design geometries, the EDA industry must now provide a larger fraction of the resolution improvement.  As ICs shrink, the range over which lithographic and electromechanical interactions occur expands in proportion to the size of individual physical features. In addition, with wafer steppers stuck with 193nm light sources, the distortions due to diffraction effects result in more numerous and subtle design-for-manufacturing issues. This makes design rules increasingly complex. Initially simple 1-D spacing, length and width measurements between immediately adjacent features (transistors or interconnect wires), IC design rules must now take into account many more complex, 2-D geometric measurements, and combined groups of measurements related by complex functions, in order to determine if a design is manufacturable at advanced process nodes.


DRC Check ExplosionAs a result, DRC is becoming exponentially more difficult to define and execute, which has many real-world implications for IC design and process engineers who have limited time and headcount, and IC executives who need to get advanced products to market quickly with high yield to stay competitive. Across industry, the number of DRC checks is growing at more than 20% node over node. Even more alarmingly, the number of individual operations required to execute each check is also growing—at more than 30% node over node. This explosion in size and complexity increases the difficulty of creating DRC decks, causes longer PV run times, and requires more time to debug DRC violations. The bottom line is that the current trend increases the time needed to achieve physical implementation closure. 

 Reversing the “Runaway DRC” Trend

How can we reverse the trend and maintain the PV cycle times required to remain competitive and drive industry growth? To get a perspective on a possible solution, consider that much of PV is really based on a simple concept: certain geometric shapes (from the perspective of a layout representing IC lithography masks) cannot be manufactured with a given process. Therefore, we can’t let designs use these shapes. 

Today when the failure analysis (FA) group determines a geometric configuration that cannot be manufactured, they write a specification for a new design rule. The new rule is then passed on to a different person who needs to interpret the rule and write a new DRC check using the PV scripting language, trying to accurately represent the original pattern and design rule. Some pattern configurations or variants of a single configuration are so complex they simply cannot be accurately (or practically) described with existing scripting languages, and errors in the checking process are the inevitable result. A lot of time and energy is expended trying to get congruence between the original intent of the design rule, and its implementation as a design rule check defined in the PV tool.

 How Pattern Matching Might Solve World Hunger

Imagine if you could use the original problematic pattern found by manufacturing to define the DRC’s, you dramatically simplify the communication of the problem from manufacturing to the designer, and you are now using a language (i.e. geometric pictures) that everyone can understand. By using visual patterns for the DRC’s you avoid having to convert the design rules into an abstraction in the scripting syntax.   

This is the concept of pattern matching for PV. Instead of using a scripting language to describe the relationship between geometries in a design, create and use a library of patterns. An IC design is then scanned using this library of patterns to find matches.  Once a match is found an error marker is produced at the site of the match. 

The library of patterns can be either hand drawn or created with the aid of EDA tools such as a pattern matching GUI environment where the user can create new patterns, specify edge constraints and manage their pattern library. The pattern matching GUI could also use an existing layout with error markers from a prior run to automatically clip patterns to create or add to a library. 

The Impact of Pattern Matching

Where historic 1-D DRC checks might have been written in one or two operations today’s 2-D checks takes tens if not hundreds of lines.  Many of these enormously complex checks are simply trying to describe 2-D patterns using syntax originally architected for doing 1-D checks.  These advanced checks could be collapsed from tens to hundreds of operations down to one operation pointing to a pattern.  This alone could dramatically slow the explosion in DRC deck size and complexity.  Smaller, simpler DRC decks are easier/quicker to create and maintain.  Smaller DRC decks run faster.  Simpler DRC checks are easier for your designer to debug.  The whole physical verification process gets simpler and moves faster getting your design to market faster. 

Pattern matching will not immediately replace traditional DRC but will provide a powerful tool to simplify the most complex checks.  Pattern matching may not quite solve world hunger but it does offer the promise of reversing the runaway DRC trend by providing an alternate, and far simpler, method of dealing with the most complex new checks required for advanced IC processes. 

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

15 January, 2010

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/


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

17 December, 2009

Since DAC we have heard a lot about physical verification tools claiming they can read the Calibre(R) SVRF/TVF syntax natively. This blog explores why competitive EDA companies are trying to use Calibre SVRF/TVF, the challenges involved, and the risks to customers.

Why Do Competing PV Products Want to Use Calibre SVRF?

Calibre is a primary sign-off standard at all the major foundries and IDMs, and the majority of fabless and “fab-lite” companies world wide. Calibre is usually the first physical verification (PV) tool used during process development at the foundries and IDMs, and consequently is the first deck available to customers. Because it is first down the learning curve, it invariably is the most mature and stable, and it generally serves as the reference for what “correct” means for other PV tools. Competing PV tools must convince the ecosystem to write upwards of tens of thousands of operations per deck in their native syntax, and then perform the tedious and error-prone operation of comparing that deck to the Calibre standard. This makes life tough for Calibre competitors. It would be “nirvana” if they could just read the Calibre deck directly—they wouldn’t be so far behind, and would have a better chance of getting the right answers. But is it really that simple?

Is SVRF Direct Read Viable?

This blog will not address the proprietary and confidential nature of Mentor’s IP in SVRF/TVF.  It is the Lawyers’ job to run that issue to ground.

Instead, let’s talk about the technical issues involved. Mentor’s SVRF/TVF syntaxes were developed with the Calibre platform in mind and the behavior and accuracy of the language is validated quarterly with over 12,400 test cases, which are constantly being extended and refined. This is extremely important because SVRF/TVF has very rich functionality with thousands of available operations and options. In addition, Calibre R&D regularly develops new functionality accessible via new SVRF/TVF operations for which there is no competing equivalent (Equation-Based DRC is an example that comes to mind). In order to read an SVRF/TVF deck, a competitor would have to create a “work around” capability using simpler and limited operations, which could produce inaccurate results. Given the rapidly expanding functionality of Calibre and the SVRF syntax, it is not realistic for a competitor to create, validate and maintain a comprehensive one-to-one mapping of SVRF/TVF. Since the accuracy of verification relies on Calibre decks that use its full functionality, a compromise solution will leave the user trying to figure out which checks are lacking, and how to code missing or inaccurate checks properly. Usually, the most difficult checks are the ones that use the latest Calibre functionality, so that puts customers in a pretty difficult position. Customers should be wary. Claims of comprehensive direct read and translation are just that—claims—unless they are supported and validated through the active participation of Mentor and the foundries.

What Do the Foundries Think?

As noted above, Calibre running SVRF/TVF is a standard defining what is correct for PV based upon multiple certification efforts at all the major foundries. Foundries validate the accuracy of decks defined in SVRF/TVF running Calibre software against their regression test suites and their IP. They do NOT validate the results or accuracy of other competitive EDA tools using Calibre SVRF/TVF decks, nor do they want their customers to use this un-certified combination. Major foundries have even added language in the Calibre deck header file that, among other things, states that Calibre decks are only to be used with Calibre software. Why? Because PV is the hand-off of responsibility from the customer to the foundry. The foundry needs to have complete assurance that all checks were made and dispositioned properly prior to accepting the design. Whether the claim is via direct read or a translator, trying to use Calibre SVRF/TVF decks with other PV software essentially means using an uncertified solution.

Is It Worth the Risk to Your Tape Outs?

If you have been convinced to use a PV tool other than Calibre that “reads” or “translates” SVRF/TVF, you might as well not run DRC at all, at least it would be easier to debug the PV errors! But seriously, what is your risk exposure? Can you truly trust the results? How can you quantify the risk of errors missed by an uncertified solution? Will the foundry take responsibility for incorrect verification results?

Even if the foundry has agreed to re-verify the design on their side with their sign-off tool (Calibre) prior to tape out, there is still a delay should an error be found.  In the worst case, if the chip has errors that prevent manufacture, you might completely miss a market window. Either way, it will be difficult to explain why you submitted a design that was not signed off per the procedures you contractually agreed to.

Moreover, will the PV tool supplier that convinced you to take a non-standard approach be there for you long term? The cost of developing, maintaining, and certifying Calibre decks for multiple process nodes at multiple fabs, is substantial for both Mentor and our foundry partners. We make this investment because we are committed to the long term success of our mutual customers. If a competitive supplier is not willing to make the same investment in their own language syntax and decks, do they have a business model that will enable them to be there for you in the future?

All this suggests that a strategy based on directly reading Calibre SVRF/TVF decks, or using a translator, is not an optimum PV solution for customers, is not supported by the industry, and is not worth the risk to your tape out.

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