Sign In
Forgot Password?
Sign In | | Create Account

Closing the Waiver Communication Loophole

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/.

Waiver, Fab-lite, Fabless, Calibre, IC Design, Physical Verification, Foundries, Foundry

More Blog Posts

Comments

No one has commented yet on this post. Be the first to comment below.

Add Your Comment

Please complete the following information to comment or sign in.

(Your email will not be published)

Archives

Tags

 
Online Chat