Interface DRC Can Streamline Chip-Level Interface Physical Verification

In most design companies, the chip-level physical implementation teams responsible for design floorplanning in place and route (P&R) environments also manage top-level physical verification from the early floorplanning stages through tapeout. In early floorplanning stages, blocks placed in the chip-level floorplan are usually still under development. Merging these incomplete blocks with the chip-level interconnect for sign-off design rule checking (DRC) produces a massive number of errors from the block core and along the block boundary at the chip-level interface. While a few of these errors may be valid, sorting through all the error results to find them is a time-consuming process that provides little value.

While design flows and best-practice design methodologies vary from company to company (and often even between different teams within a single company), what is constant is everyone’s desire to meet aggressive tapeout schedules. Eliminating unnecessary activity like reviewing invalid DRC results certainly helps. An ideal solution would enable chip-level designers to validate the chip-level interconnect and block interfaces in their floorplan without generating a multitude of invalid DRC results.

One approach is to modify the chip-level sign-off verification flow to create an interim interface DRC flow that excludes rules and data that cannot be reliably checked when blocks are incomplete. A parallel design implementation flow can have multiple blocks in different stages of development at the same time. Of course, verifying blocks (each of which may be at a different stage of physical design) in the chip-level context is more complex than a simpler waterfall design methodology, where all blocks are completed before being placed at the chip level for verification. However, adapting the sign-off flow to support interface DRC checking also provides early validation of chip level designs, avoids costly rework associated with flows using multiple DRC applications, and affords an easy transition to full sign-off verification.

Chip-level interface verification
Sign-off DRC decks contain the complete set of rules (as defined by the foundry) required to validate full-chip data, blocks, and single cells. These decks also typically contain check groups and variables that help users simplify setup for running chip, block, or cell-level rules. For example, setting a cell or block-level option can exclude chip-level checks like density or antenna, which may not be required for cell and block verification. Chip-level check requirements, on the other hand, require both cell and block-level checks, as well as density and antenna checks, and other chip-level checks, to meet sign-off criteria. Interface DRC check requirements differ from both, lying somewhere between the two.

Sign-off verification flows assume the input design databases are complete. However, in a parallel design flow, block abstracts defined in the P&R chip-level floorplan are streamed out and replaced with their GDS or OASIS block counterparts, which contain physical design data developed by other teams. An interface DRC checking flow will not always have completed GDS or OASIS blocks, although the footprint, pin locations, and some interconnect will already exist. The block’s core may include placements or interconnect, depending on progress made on each individual block. Excluding the incomplete block cores while including the block periphery during interface DRC checking finds and reports any contextual violations to the chip-level designer, but avoids output from the core (which the designer cannot fix).

Interface checking simplifies the verification flow by selectively running chip-level checks only (which generate valid results on incomplete design data) and only checking the edges of incomplete blocks in their chip-level context. Block placements in P&R floorplans may include routing channels between blocks, abutted placements, or a mix of the two (Figure 1).

Figure 1: (Left) channel-based floorplan with over-the-cell routing; (Right) abutted floorplan with stitch routing.

Some design methodologies support over-the-cell routing, whereas others require routing that crosses a cell to be pushed into block placements. Due to these and other factors, individual requirements for an interface DRC flow may vary. The interface DRC solution presented here can be used by both floorplan methodologies, but is best suited for abutted placement with no over-the-cell routing.

The key elements required to implement an interface DRC flow are:

• to determine when to enable or disable specific chip-level checks
• to exclude data from incomplete blocks or cores from being included in DRC checking or results output

Selecting DRC checks
To simplify the process of choosing the correct set of checks to apply to cell, block, or chip level verification, foundries often define rule-check groups in the rule file (such as CELL or CHIP) that define the list of checks required for each design level. Designers working on cell development specify the CELL check group, whereas chip-level teams use the CHIP check group.

Chip-level verification requirements in a parallel implementation flow require the chip-level check group, but false errors due to incomplete blocks may hamper debugging efforts. Creating an INTERFACE group that contains a subset of the chip-level checks enables designers to target appropriate checks for different design stages and prevent time wasted debugging false chip-level violations (Table 1).

 Table 1: DRC Groups

However, integrating new check groups into an existing foundry deck may require modification to that deck, which is not always a viable option for design teams. An alternative method is to use the header rule file to specifically exclude the chip-level checks that should not be run, and include the unaltered foundry deck. For example, the following pseudocode example demonstrates how the sign-off rule variable is used to enable the chip-level checks for a Calibre signoff rule file. The DRC header file include achieves the same goal as using an INTERFACE check group. Checks that should not be run for interface DRC checking are removed by unselecting them by name.

<Exclude chip-level checks>
INCLUDE FILE “signoff_calibre.rules” // Include foundry Calibre sign-off rule file.
SET CHECK_LEVEL = ”CHIP” // Set chip-level check variable.
DRC DESELECT “Rule_4 Rule_6” // Un-select chip-level checks for interface DRC.

Excluding incomplete blocks
The second challenge in setting up a chip-level interface verification methodology for parallel design implementation flows is to clip out incomplete block cores, while retaining the block periphery for checking at chip-level placement interfaces. Later, as block layouts are completed, chip-level verification must include the entire block, not just the periphery (Figure 2).

Figure 2: Interface DRC checking applies interface checking to incomplete blocks, and permits complete block checking as they are completed. Full sign-off DRC verifies block layout after all blocks are completed.

Designers can exclude block cores from verification by defining check exclusion regions in the same rule file header used to set the interface-level checks. For example, Mentor’s Standard Verification Rule Format (SVRF) syntax can interpret these exclusion regions as layout “windows” of data that should not be checked. These regions can be quickly created (Figure 3) using a tool command language (TCL) script that performs the following steps:

1. Read only P&R boundary marker layer into the layout editor.
2. Find top-level block instances that are incomplete.
3. Expand each instance to promote P&R boundary to top-level.
4. Iterate through P&R boundary shapes in top level.
5. Undersize each shape by the halo value.
6. Export coordinates of the shape as an SVRF exclusion region.

Figure 3: A TCL script can quickly convert block placement boundaries (blue) to chip-level exclusion regions (red) and output to SVRF.

The undersized halo value must be large enough to include the block periphery that enables interface DRC checking, yet small enough to limit false errors along the edge of the exclusion regions. The exclusion regions may also be used to identify and waive unwanted results within block periphery. As blocks are completed, they should no longer require exclusion regions. In Figure 4, the undersized boundaries of incomplete placements (blocks A and B) are converted to SVRF region exclusion statements, which define design data to exclude from interface design checking. After block C is completed, only references of A and B should generate exclusion regions.

Figure 4: Incomplete placements (A and B) can be excluded from interface DRC checking.

The TCL script can add these regions to the rule file header that defines which interface checks to run. Combining the generated exclusion windows with the interface DRC selections provides the input rule file settings required to run chip-level verification, while blocks are defined in parallel with the chip top level. When block implementation nears completion, designers can easily transition to the production sign-off DRC flow.

Conclusion
Chip-level design teams seeking that extra edge to help them perform chip-level physical verification in a parallelized implementation flow can realize significant time savings by augmenting existing sign-off DRC flows with incremental interface DRC checking. The two primary challenges in modifying sign-off verification flows are defining which checks to include or exclude, and how to exclude incomplete block cores from DRC checking. Alternate solutions focused on differing design methodologies may require somewhat different strategies, but teams who adopt an interface DRC checking flow based on their sign-off methodology will shorten DRC runtime and debug sessions during block implementation and be confident that their design is being verified with the foundry-defined sign-off application.