Specific verification strategies can enable full-chip layout exploration and physical verification while many components are still immature.
By Nermeen Hossam and John Ferguson
Most advanced node system-on-chip (SoC) designs are very large, and very complex. They typically contain many blocks and intellectual property (IP) that perform specialized functions, such as computation, internal communications, and signal processing. These blocks are often built by separate teams or IP suppliers, and integrated into the SoC layout. However, market pressures mean SoC design teams usually don’t have the luxury of waiting until all these chip blocks are completely finished and verified to begin their chip assembly and verification. To minimize their time to market schedule, they must start the integration process in parallel with block development, and attempt to find and correct design rule checking (DRC) errors early in the design cycle. However, this approach typically results in a huge number of errors, due in large part to the unfinished blocks. Eliminating these errors in the early phases of chip assembly, and returning them to the block developers to fix, can help SoC designers reduce the number of full design rule checking (DRC) iterations needed to achieve tapeout.
Sounds like a logical approach…and it is. However, this early chip-level physical verification isn’t a walk in the park, by any measure. Not surprisingly, running physical verification on unfinished blocks during early floorplanning can be problematic. The default settings in foundry rule decks typically result in very long DRC runtimes, a massive number of DRC violations, and an equally large generated results database. Systematic errors are the largest single contributor to this error count (Figure 1). These errors can be caused by a variety of layout issues, including:
Unfortunately for the SoC designer, capturing systematic errors and differentiating between block-level violations and top-level routing violations at this early stage can be challenging, making the debugging process difficult and time-consuming.
Figure 1. Systematic errors contribute to the large number of violations identified in early chip-level physical verification.
Early in the design flow, SoC designers are focused on finding and fixing the relevant SoC violations, while minimizing the runtime and number of DRC iterations needed to get a DRC-clean layout. If they can separate out block-level violations during early floorplanning, they can send these violations back to the block owners to debug and correct, while they concentrate on debugging and fixing chip-level errors.
Improving dirty block/chip-level verification
Adopting specific verification strategies can enable SoC design teams to explore full chip design layouts and perform physical verification during very early stages of the design cycle, while many of the components are still immature. The ability to more easily identify and accurately fix early integration issues not only contributes to a faster time to market, but it also allows designers to construct a higher-quality product by focusing their time and expertise on real design issues. However, most of these techniques are not practical in a manually-controlled flow. Enabling automated application of these processes is the key to their success. We’ll look at some of these strategies of early chip-level verification, using the electronic design automation (EDA) Calibre Reconnaissance (Calibre Recon) tool to demonstrate how they can be implemented in an automated flow.
Check selection
Not all checks are equal. Some rule checks operate in a local context, while others (e.g., connectivity or multi-patterning) require a large context, meaning the results typically are not geographically close to the source of the error, making them less helpful when trying to quickly identify systematic errors. Deselecting these types of checks can significantly speed up DRC runtime, but knowing which checks to select can be tricky. Do you deselect the checks that contain many operations? Or perhaps you delete an entire category of checks, such as antenna or connectivity checks. Determining the “best” set of checks to include in an early DRC run can require a lot of analysis and expertise, as well as the knowledge and skill to properly edit a foundry rule deck.
The Calibre Recon tool automatically deselects checks that are not relevant to the current development stage, with the goal of providing adequate coverage, fast runtimes, and lower memory consumption. On average, the tool reduces the number of checks performed by about 50% (across a range of process nodes). The decision of which checks to exclude is based on the check type. In general, useful checks are those that have a local context. Rules that require a large context (like connectivity or multi-patterning) typically require much more time to run (due to their flat nature), and the results are usually not geographically close to the source of the error, making it difficult and time-consuming to identify any systematic cause of errors. The tool also automatically excludes any checks/categories manually deselected by the designer. All deselected checks/categories are reported in the transcript for future reference.
Automatic check deselection reduces overall DRC runtime by up to 14x, while still checking ~50% of the total DRC set. The subset of rules used effectively identify floorplan and sub-chip integration issues, providing fast, targeted feedback to the design team for proper corrective action and resulting in a significantly reduced total turnaround time. While the total number of reported violations is reduced to about 70% when compared to a full DRC run, these violations are more meaningful to the targeted implementation stage, which facilitates efficient analysis and debugging of real systematic issues. Figure 2 illustrates the results of running reduced checksets on a variety of designs across a range of process nodes.
Figure 2. Calibre Recon performance and results compared to full Calibre nmDRC runs.
Not only does check exclusion help SoC designers with early chip-level validation, it also supports early block verification. Because the block and chip designs are being completed in parallel, a block designer can run verification on the block layout. If systematic errors are found, the block designer can fix the issues. If the subsequent results are clean, the block can be passed to the chip for placement, while the block designer runs the full DRC ruleset in parallel on the block. Experiments shown in Figure 3 demonstrate that running the Calibre Recon tool on blocks (tiles) during initial routing can result in an 8x runtime reduction and a 4x memory usage reduction when compared to a full Calibre nmDRC run.
Figure 3. Comparison of Calibre Recon runs to full Calibre nmDRC runs for both blocks and full chip at different stages of development show significant reductions in runtimes and memory usage.
Gray box exclusion
Another exclusion strategy focuses on the layout from a design perspective. Theoretically, by ignoring, or gray boxing, some parts of the design (mainly immature blocks), SoC designers can focus on interface and routing violations, as well as decrease DRC runtimes. However, gray boxing, like rule exclusion, is impractical from a manual implementation point of view.
The gray box feature enables SoC designers to check top-level routing while ignoring cell details, by designating selected cells as gray boxes. The gray box designation removes data from within the specified cell without removing the geometries from the higher-up parent (Figure 4). Any routing violation over the specified cells is still captured. By specifying a certain halo around the excluded geometry (by sizing down the extent of the cell), designers can also capture interface violations between the gray boxed cells and their neighbors.
Figure 4. The gray box option enables SoC designers to exclude portions of the layout from DRC, while still allowing verification for interface or routing violations in those areas.
This gray box solution is equally applicable to both rectangular and non-rectangular cells, although designers may need to specify the layer that represents the extent of any non-rectangular cells (boundary layers can be used for this purpose).
The Calibre Recon gray box solution provides the SoC team with pointers to interface DRC errors that require correction. It also isolates integration and routing errors associated with assembly from the immature block violations. Even though gray-boxing can be run independently from the automatic rule check selection, combining these features further reduces runtime by focusing on selected violations reported for areas in the design that require more attention during a particular phase. By concentrating the verification on the most relevant checks, it helps design teams resolve more of the critical interface issues early in the cycle, and avoids unpleasant last-minute surprises (Figure 5).
Figure 5. Combining the gray box feature with automatic check selection helps focus verification on critical interface and routing issues in early design phases.
While the gray box feature improves runtime, it does come with some provisos. Removing the geometries from the selected cells may introduce new DRC violations that will require additional debugging. Designers must determine whether the errors are real violations, or were created when the geometries were removed. To eliminate this issue (and the need to edit the foundry rule deck to add the gray box specification statement), designers can opt to use the gray box feature in conjunction with the Calibre Auto-Waivers functionality. While the primary purpose of this combination is to reduce runtimes (by not checking geometries from incomplete blocks), it offers the secondary benefit of waiving any errors introduced by excluding regions from the selected cells (Figure 6). Removing these errors from the results enables designers to focus on the original (valid) DRC interface violations. All waived errors are saved to a separate waiver results database for later review, if needed.
Figure 6. Combining the gray box feature with Auto-Waiver functionality enables designers to focus on interface and top-level routing validation.
In general, designers should always enable automatic check selection when running Calibre Recon gray-boxing with Calibre Auto-Waivers. Removing interconnect geometries can cause connectivity errors, multi-patterning errors, and more. Running with automatic rule selection helps eliminate these errors from the results and reduce confusion during debugging.
Error results analysis
The ability to visualize and analyze error results is crucial to efficient design optimization. Recognizing patterns and trends in errors helps designer identify opportunities for quick enhancement of layout quality.
The DRC analyze function allows designers to draw different histograms (based on hierarchical cells or windows) for chip analysis, and specify custom scaling ranges for these histograms. Colormaps of the results can also be drawn, either on standalone windows or mapped on the design, to enable designers to probe down to see error details (per cell and per window), where the results are shown distributed across the design (Figure 7). Even better, they can use the foundry rule deck without any editing to perform all the required analysis. The overhead (an average 10% runtime increase and 20% memory use increase over an automatic check selection standalone run) is nominal compared to the value this analysis provides during debugging.
Figure 7. The DRC Analyze function enables fast, in-depth visualization and analysis of error results.
Conclusion
SoC design teams face huge DRC runtime and error debugging issues during early design phases. Designs are too immature at this stage to run full DRC without generating massive numbers of errors. However, it is not an easy task to manually identify a subset of rules that would identify relevant design problems, or to exclude dirty/incomplete blocks without having to edit foundry rule decks.
Automated EDA solutions like the Calibre Recon functionality enable SoC designers to quickly and easily find and resolve integration issues early in the design cycle, using foundry/IDM signoff design kits. With the support of features like automatic check selection, gray box exclusion, and results analysis, designers can reduce total DRC runtime, accelerate design closure, and deliver high-quality designs. While all of these features can be run independently, designers get better and more meaningful results by combining them.
For companies targeting demanding end-markets such as the Internet of Things, artificial intelligence, autonomous driving, and 5G communications spaces, these advantages can make the difference between just being in the market, and being a market leader.
For more information, download our whitepaper, Accelerate Early Design Exploration & Verification for Faster Time to Market.
John Ferguson is the product marketing director for Calibre DRC applications at Mentor, a Siemens Business. Ferguson has extensive experience in the area of physical design verification. He holds a B.Sc. degree in Physics from McGill University, an M.Sc. in Applied Physics from the University of Massachusetts, and a Ph.D. in Electrical Engineering from the Oregon Graduate Institute of Science and Technology.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Leave a Reply