Full-chip level
Mentor Graphics
Historically, design-rule checking (DRC) was a black-or-white proposition—either designers passed all their DRC runs or fixed the errors until they passed. But these days, much of the IP used in SoC designs is from third parties and products are sporting more and more memory content. As a result, design teams are encountering DRC violations in known-good IP or memory and are forced to waive these violations over and over again. Essentially, design teams are paying a “productivity tax” for each DRC iteration of a design at the cell, block, and full-chip levels.
For advanced design teams this can mean one of two things: 1) they are either unnecessarily reviewing and fixing tens of thousands of DRC results for every design, or 2) they have cobbled together a flow that attempts to waive DRC results, but is likely also putting the design at risk by waiving real DRC errors in the process. Neither of these situations should be tolerated if there is an automated way of managing removal of waived DRC results in known-good IP without the risk of waiving real DRC errors.
Why Are DRC Waivers A Growing Problem?
DRC waivers are increasing due to the trend towards larger SoC designs that incorporate a growing amount of custom and third-party IP and embedded memory. This IP may have been designed using different versions of the target foundry’s design-rule manual, or targeted for slightly different processes; either way, the result is DRC errors even though the design has 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 fully meet its own design rules. Finally, at advanced technology nodes, the design rules have grown so numerous and complex that it has become impossible to meet all of them and still satisfy performance and time-to-market requirements.
Meanwhile, handling of waivers is a weakness in many IC design flows. Typically, when IP with waivers is provided to a design team for incorporation into their designs, the waiver information is not transferred in a consistent manner or 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 when the end user of the IP attempts verification. Without any indication of their waived status, these violations look just like new DRC errors. Making matters worse, they appear as DRC errors in a cell or block that the chip-level designer is not authorized to edit for correction!
What makes the “productivity tax” imposed by DRC waivers so high is because designers must pay the tax over and over and over. Consider the example of a design composed of thousands of instantiations of standard cells and many functional blocks for a full chip.
Continue on next page
In a typical design, a design team will do many DRC iterations for each component (i.e., standard cell, small functional block, large functional block and full chip). Each component may have one or two waivers, adding up to tens of thousands of waivers at the full-chip level (see Table 1). Mentor Graphics (see Table 2) recently polled some of the IC industry’s biggest fabless companies to find out how many waivers they waste time on with each and every DRC iteration.
Do the math: For one design development program a team may be waiving tens to hundreds 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 waived in seconds, but non-trivial ones may take much longer. With huge numbers of waivers per design and a growing debug time per waiver, a design team is wasting a lot of resources on this “productivity tax” without adding any value to the end product. The team is likely wasting hundreds of person hours for every design due to this tax. Further, all the back and forth between designers, the IP provider, and the fab or foundry slows down the development process. If this tax can be eliminated, the design gets to market weeks or months earlier.
What Would an Effective Solution Look Like?
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. There are various approaches on offer, but they vary widely in their effectiveness. What would an ideal solution look like? The key requirements for a complete solution include:
- A way to capture and communicate waiver information without new data types or additional files that the designer would have to manage.
- A way to associate the waivers with specific layout structures so the designers do not have to do outside “bookkeeping” to keep everything straight.
- A way to accommodate design hierarchy and subtle variations that occur when a physical structure is placed in different contexts within the full design.
- An audit trail to support a quality control process.
- Minimal impact on DRC runtime.
As time to market continues to be the gating factor that determines the market success and profitability of an IC, having an automated IP waiver management process that reduces design verification time while simultaneously improving the quality of results is highly advantageous. So, I say ‘Death to Taxes!’—at least to the waiver productivity tax.