Earlier SoC Design Exploration And Verification Gets Better Designs To Tapeout Faster

By Nermeen Hossam and John Ferguson

Between the complexity of advanced node design verification and the competition to be first to the market, system-on-chip (SoC) designers no longer have the luxury of waiting until each sub-block of a chip is DRC-clean to start their chip assembly and verification. Today’s SoC designers typically start chip integration in parallel with block development. As shown in figure 1, different blocks are at different stages of development, but none of the blocks is complete as SoC designers begin the initial floorplanning phase; they are only completed as SoC designers move through the design flow.

Fig. 1: Although individual blocks may not be complete, designers need to begin physical verification as early as possible.

At each stage of the design flow, designers run different physical verification iterations, including design rule checking (DRC), to capture design rule violations and fix them. However, parallel implementation and physical verification of block and chip-level designs that contain incomplete or “dirty” data present many challenges. In very early floorplanning phases, the number of reported violations in the unfinished blocks is typically huge, and it is no trivial task to differentiate between block-level violations and top-level routings violations. In addition, systematic issues are often widely distributed across the design, leading to an enormous number of DRC errors. Running full DRC on incomplete designs not only results in long DRC runtimes, but also generates a gigantic DRC results database file that is difficult to open using results viewing tools. Lastly, because there is no way to distinguish between real layout errors and errors caused by the incomplete state of the layout, designers must also review all violations, resulting in time-consuming and complex debugging and error fixing, much of which is pointless in early-stage layouts.

Ideally, designers want to capture and fix real violations as early as possible in the design cycle to reduce the time to market and avoid last minutes surprises. SoC designers would like to push block violations to the block owners to fix, so they can focus their time and efforts on fixing integration and systemic violations. Designers also want to minimize both the number of DRC iterations and the runtime of each iteration. One way to achieve that goal is to enable designers to focus only on violations that are relevant to each stage. By limiting early design rule checking (DRC) to selected rule checks and geometries, designers can not only reduce the time required to debug and fix violations, but also improve the debugging process by ensuring their time and effort are only spent analyzing and fixing violations that are both real and relevant in early design stages.

Improving dirty block/chip-level early-stage verification

To enable designers to run relevant and efficient early-stage design exploration and verification, they need a way to filter out those checks that are only relevant to complete designs. They also need the ability to efficiently handle some of the complex design issues that can be difficult to resolve accurately in early design stages. To provide design companies with automated early-stage verification, Siemens EDA introduced the Calibre nmDRC Recon tool, which contains multiple functions to help designers accelerate early design exploration and verification even when the different components are still immature or incomplete. To ensure ease of use, the Calibre nmDRC Recon tool uses existing foundry rule decks, without the need for modification, and designers can invoke the tool by applying a simple switch in the invocation command. While each function can be run independently, design companies will find it useful to combine them to get better and more meaningful results.

Reduced check selection

The Calibre nmDRC Recon check selection tool automatically deselects checks that are runtime-intensive and/or unlikely to provide actionable results in early design phases. Examples include design issues like connectivity checks, delta V, or multi-patterning checks that are not significant or relevant in early design development. These types of checks tend to flatten the layout hierarchy, resulting in poor scaling and concomitant long runtimes. In addition, even a minor issue may result in hundreds of violations at different locations across the chip.

Automatic check deselection reduces overall DRC runtime by up to 14x, while still checking ~50% of the total DRC set. The subset of rules effectively identifies relevant 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. To address any specific requirements, designers can also add or remove checks from the Calibre nmDRC Recon run.

While the total number of reported violations is reduced to about 70% of the error set generated by a full signoff Calibre nmDRC run, these violations are more meaningful to the targeted implementation stage, which facilitates efficient analysis and debugging of real systematic and design issues. Figure 2 illustrates the results of running reduced checksets on a variety of designs across a range of process nodes.

Fig. 2: Calibre nmDRC Recon performance and results compared to batch signoff Calibre nmDRC runs.

Gray Box exclusion

The Calibre Auto-Waiver “gray box” function enables designers to exclude polygons in the core of any unfinished blocks from being checked in the Calibre nmDRC Recon run, while still enabling the interface region of these blocks to be considered in the Calibre nmDRC Recon run. This option allows the SoC designer to capture integration violations and work on fixing them in parallel with block development, while also reducing runtime and decreasing the number of reported violations. Designers also have the flexibility to define the interface region that should be considered in the Calibre nmDRC Recon run. As shown in figure 3, the white regions in cells A and B are excluded from the DRC run, while the solid color regions are included.

Fig. 3: The gray box feature allows designers to exclude block components from the DRC run while enabling checking of interface regions.

However, excluding polygons in block cores can lead to some introduced false violations in the result database. To ensure they don’t waste time debugging these false errors, design teams can use the Calibre Auto-Waivers tool in parallel with the gray box feature to generate a waiver layer around the excluded area that waives these false violations.

Figure 4 demonstrates how the number of reported violations is significantly decreased when some unfinished blocks are excluded. The bar chart displays the time savings achieved by both Calibre nmDRC Recon run and a Calibre nmDRC Recon with the Calibre Auto-Waivers gray box function enabled, compared to a full Calibre nmDRC signoff run.

Fig. 4: Adding the gray box function to a Calibre nmDRC Recon run provides an even-tighter focus on verification of critical interface and routing issues in early design phases.

By isolating unfinished blocks from the Calibre nmDRC Recon run, designers not only reduce runtimes, but also reduce the number of reported violations, enhancing the debugging process and allowing SoC designers to focus primarily on fixing integration violations.

Error results debugging & analysis

Any efforts to reduce design cycle time using early-stage design verification must include a more efficient debugging flow that enables designers to easily understand the root cause of errors and provide them with fix guidance. To facilitate debugging and fixing of early-stage DRC violations, Siemens EDA enhanced the functionality of the Calibre Auto-Waivers tool to support the analysis and correction of some challenging design issues commonly encountered in early-stage verification.

Antenna debugging

Antenna checks often require multiple scenarios for the same check, which can make debugging antenna errors quite difficult. Because designers don’t always know which scenario is applicable to the error they are debugging, they can’t accurately identify the equation that must be used to understand the failure and calculate the diode area required to correct the error.

The Calibre Auto-Waivers infrastructure can be used to report additional error detail that helps designers debug antenna errors and identify the equation used in failure calculation. In addition, a fixing hint is provided that represents the area of the diode that should be added to fix this failure.

Figure 5 displays the antenna output file generated from running this debugging flow. Different debugging properties are reported on the failed net, including total area of the different layers, the accumulated damage, the value of the conditional constructs for the different scenarios in the check, and the diode areas required to fix the issue.

Fig. 5: Antenna check debugging is simplified with the additional error information provided by the Calibre Auto-Waivers functionality.

Waiving curvilinear error results

Curvilinear structures in OASIS or GDSII are treated as piecewise linear approximations (figure 6). Skew edges are common, and off-grid vertices are snapped to a linear grid. As a result, verification of curvilinear structures using traditional DRC flags thousands of false errors.

Fig. 6: Traditional DRC verification of curvilinear structures results in a massive number of errors, due to linear approximations.

The Calibre Auto-Waivers infrastructure is leveraged in a post-processing step to automatically filter out false spacing check violations in curvilinear structures (figure 7), so only real violations are reported in the DRC results database file. Designers no longer have to edit the Calibre nmDRC foundry rule deck to add equation-based DRC (eqDRC) operations for each curvilinear structure spacing check to filter out these false violations. The filtered errors are reported in a separate results database for review as needed, to ensure accountability at all stages of design verification. This approach to curvilinear structure verification saves the foundries the time and effort needed to implement and support special code for curvilinear structures verification.

Fig. 7: Calibre Auto-Waivers infrastructure can be used to filter false curvilinear DRC errors from the results database to save design teams from wasting debug time and effort.

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

Early design verification can not only reduce the time needed to get to tapeout, but it can help design companies improve design quality. However, those benefits can only be realized if early design verification allows designers to focus their time and effort on issues that are relevant and critical to incomplete designs. Automated EDA solutions like the Calibre nmDRC Recon functionality enable SoC designers to find and resolve integration issues quickly and easily early in the design cycle using foundry/IDM signoff design kits. The support of functions like automatic check selection, gray box exclusion, and targeted error results analysis allow design teams to narrow their focus to those issues that can and should be corrected before signoff verification begins. By eliminating these issues in early design stages, designers can reduce total DRC iterations and runtime, accelerate design closure, and deliver high-quality, high-yield designs.

John Ferguson is the product management director for Calibre DRC applications at Siemens Digital Industries Software. 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.