By John Ferguson and Jonathan Muirhead, Mentor Graphics
Ensuring a known level of quality
The increasing use of intellectual property (IP) in integrated circuit (IC) design creates its own set of verification challenges. IPs are usually purchased from other companies, or created by completely separate design teams inside an IC company. IPs are used to incorporate both standard and highly specialized functionality into an IC design. For example, SRAM memory blocks are a common type of IP. Using a commercial SRAM IP allows a design team to concentrate time and resources on those parts of the chip that create their market differentiation.
There’s another advantage to using IPs — design teams get a known level of quality. This is especially true for hard IP, which is provided with a full layout that has gone through the tapeout verification process and manufacturing assessment. Of course, like any other IC design, an IP may contain certain design rule checking (DRC) errors that have been deemed manufacturable (waived) by the target foundry. However, IP providers do not always provide a list of these waivers and this can cause unnecessary verification issues when IPs are placed in larger designs.
Dealing with DRC waivers for IP
Because IP design is proprietary and a competitive differentiator, IP providers (internal or external) want to prevent other design teams from making changes to their work. They typically place a large blocking marker layer on the IP block that prevents DRC within that block. Unfortunately, design teams can cause problems when using the IP, such as accidentally dropping a piece of metal on the layer inside an IP area. If a designer mistakenly places a polygon somewhere within an IP block, and cannot check for errors due to a blocking layer, the error will not be caught. This will cause a real manufacturing issue.
However without the blocking layer, the IP in a DRC run will inevitably generate a significant number of errors that, unknown to the designer, have actually been waived. Having to analyze and clear these errors wastes time and can lead to a significant delay in the tapeout schedule. Automated waiver management can help design teams eliminate waived IP errors while identifying genuine DRC errors. This is done by including information about the previously waived DRC violations along with the IP that can be used by the DRC tool during checking runs.
This approach works great for hard IP. But what about soft IP, where the layout is not fully realized until implemented in a design? Going back to our SRAM example, these IPs are not typically sold as hard IP, but as building blocks (bit cells, I/O cells, etc.) that can be configured by supporting compiler software to generate SRAMs of different sizes and configurations. In this case, the typical automated waiver approach fails because there is no predefined IP to which the waived errors can be assigned. For example, errors in a bit cell can easily be identified and waived wherever they occur in the compiled memory configuration. But, how do you waive errors between a polygon in one bit cell and a polygon in a neighboring bit cell? You do not have a predetermined, fixed parent containing those blocks. The same is true for bit-cell-to-I/O-cell errors and in many other instances.
Combining automated waiver management with pattern matching capabilities in a DRC tool can solve this challenge. Let’s consider a specific example that combines the automatic waiver management and pattern matching capabilities in the Calibre nmDRC tool.
Using pattern matching and auto waivers together
The pattern matching solution starts at the SRAM IP supplier. The IP design team selects patterns representing basic memory configurations, such as a 2×2 array of bit cells, or a pattern representing the expected interaction between an I/O cell and its neighboring bit cells, and so on. The IP design team then runs DRC on these representative SRAM patterns to identify any rule violations. The IP supplier and the foundry can then jointly agree which violations can be waived (this kind of collaboration has been underway for some time and is discussed in another Tech Design Forum paper, ‘Improving SoC productivity through automatic design rule waiver processing for legacy IP’).
For each waiver, a pattern representing the legal configuration is saved into a waiver pattern library. This library is then passed to the designer along with the IP blocks themselves. Error waivers are captured not as a hard IP cell, but as patterns corresponding to actual geometries that could be generated when configuring soft IP – i.e., created when the SRAM is compiled.
When the customer’s design team runs DRC on their generated SRAM configuration, they instruct the DRC tool to use the waived pattern library provided with the IP. During the DRC run, any errors resulting from patterns matching the waived patterns will not appear in the DRC error results. However, if a pattern that generates an error varies from the waived pattern by an amount specified by the designers, the associated error will be shown as a real violation.
Pattern matching in practice: 1
Let’s look at an example (Figure 1). Suppose we have a spacing violation between geometries in two neighboring hierarchy cells. Assume the foundry has determined that the design can be manufactured when the IP is configured correctly (i.e., the cells are placed side-by-side symmetrically) even though the strict spacing rule has been violated (Figure 1, top left). However, when the cells are misaligned (i.e., a cell placement has been shifted), the error must be corrected before tapeout (Figure 1, top right).
Figure 1 Pattern matching used to identify shapes that fail DRC but have been waived (Mentor Graphics)
To enable automatic waiver management, the IP supplier design team captures the aligned geometry as a pattern (Figure 1, bottom left, red shape), and adds it to the waiver pattern library shipped with the IP. The customer’s chip design team instructs the DRC tool to use the waiver library to exclude errors due to geometries that match the waived patterns. In this case, geometries that are generated by the memory compiler and are aligned will match the waived pattern (red) and be excluded from DRC results, while any misaligned geometries will not (Figure 1, bottom right, yellow). As a result, the design team can focus on debugging only the misaligned features.
There are other techniques that achieve the same result. Examples include providing a modified IP and using marker layers., But they are difficult to implement and entail some risk of missing real errors. Using waiver management and pattern matching together helps eliminate the risk of waiving a real error. Also, the process is automated, accurate, and fast.
Pattern matching in practice: 2
Waiving errors from soft IP is just one example of the power of pattern matching. Pattern matching can be used in a complementary manner as well. That is, pattern matching can be used to identify DRC errors (as opposed to waivers) not easily specified with standard DRC rules.
Consider again the example of the offset bit cell in an SRAM. If the placement is inadvertently offset by one nanometer, but in a way that the connecting geometries are still aligned, the feature would likely pass a conventional DRC: The designers would never know that they had a poorly generated IP block. Using pattern matching, an SRAM IP designer can identify legal bit cell-to-bit cell interactions as patterns, and write a DRC rule that flags any SRAM bit cells that do not match. If this rule is run on an SRAM block, or the full SRAM placed into a larger design context, the DRC tool will flag bit cells that are not properly placed with respect to their neighbors.
These pattern matching techniques help IP providers ensure that their IP can be integrated into larger designs efficiently and accurately. IP design teams that have built design flows using automated waiver management can incorporate pattern matching with only a small amount of additional effort.
IP customers that are already doing pattern matching checks with their own customized rule checks can switch to automated waiver management, eliminating the need to create and maintain modified rule decks and speeding their time-to-tapeout, while ensuring their designs comply with all foundry requirements.
John Ferguson is the Director of Marketing for Calibre DRC Applications at Mentor Graphics in Wilsonville, Oregon. He received a BS degree in Physics from McGill University in 1991, an MS in Applied Physics from the University of Massachusetts in 1993, and a PhD in Electrical Engineering from the Oregon Graduate Institute of Science and Technology in 2000. John has worked extensively in the area of physical design verification for the manufacture of leading edge ICs.
Jonathan Muirhead is a Product Marketing Manager for Calibre Pattern Matching in the Design to Silicon Division of Mentor Graphics. He has 10 years of experience working with Calibre and Mentor Graphics products. Jonathan received his BSc. in Computer Engineering from Washington State University.
This article was originally published on www.techdesignforums.com