Balancing Flexibility And Quality In SRAM Verification

Memory is an essential component of system-on-chip (SOC) designs, especially at advanced nodes. SoCs use a variety of memory block types, such as static random-access memory (SRAM) and dynamic RAM (DRAM), to perform computations. The SRAM blocks, which consist of an assembly of specialized calls that abut or overlap one another in a specific arrangement that complies with the circuit specifications (Figure 1), are typically used for operations requiring high-speed access to frequently used data. Because of these exacting requirements, most integrated circuit (IC) design companies prefer to use proven SRAM blocks provided by their foundries as intellectual property (IP) blocks, rather than spending time to create their own SRAM designs.

Figure 1: An SRAM block consists of multiple cells, and each cell includes multiple layers.

These SRAM blocks typically consume a large part of die area, meaning the SRAM design quality has a major impact on yield. However, while foundries ensure that the SRAM IPs they supply provide good yield, SoC designers must always perform some level of customization on the SRAM blocks they incorporate into their designs. As process margins get tighter with every node, foundries have less and less tolerance in their manufacturing processes to incorporate these intentional (or unintentional) modifications made to the SRAM blocks to avoid potential defects and yield impact.

Knowing that such SRAM modifications are inevitable, and keenly aware of the process limitations, foundries provide the most accurate and precise design rules possible to help SoC designers verify that their SRAM blocks are design rule compliant and robust in the SoC layout before tape-out. The challenge for the SoC designers is to find the balance point between their need for SRAM customization to obtain better performance, and the potential impact of such changes on yield.

SRAM verification challenges
So, what are these difficulties designers face in the verification and debugging of SRAM blocks in a SoC chip? The physical structure of a SRAM block is complicated, not only because it involves multiple layers and multiple cells, but also because it requires all cells to be placed in a specific configuration. Additionally, there are usually multiple types of SRAM blocks used in a SoC, and they may not all contain the same cells or use the same configurations. In general, a SRAM block is just too complicated to verify by using traditional design rule checking (DRC) alone. Figure 2 shows some of the common errors found in SRAM blocks.

Figure 2: Common errors in SRAM blocks after placement.

Debugging these errors presents yet another challenge for SoC designers and manufacturers. Since traditional DRC rules are unlikely to identify all the types of errors that can occur in a complicated 2D configuration layout, considering all involved layers and cells, they must also use supplementary verification and debugging techniques to ensure accurate correction.

Cell-based checking
Some designers use a supplementary cell-based checking method to determine if any contents inside the SRAM cells were modified, and use DRC rules to find errors at the top level. Together, these verification techniques can cover most known error types and identify any cell contents that have been modified. However, the cell-based method not only requires the foundry to include all possible cell layouts in the process design kit (PDK), but it can only identify which cells were modified, and where unmatched cells are found. Because it cannot identify exactly where or what the errors are, designers often spend a great deal of time locating errors (particularly errors created by unintentional changes), as shown in Figure 3. Typically, designers must then ask the foundries if these errors are valid, and/or how to fix the layout to correct them.

Figure 3: Error results reported by cell-based SRAM verification methods. Designers have no clues to help them identify error locations and involved layers.

This lack of location information for reported errors is not just a time-consuming annoyance for both designers and foundries. It’s the major obstacle to achieving that desired balance between design flexibility and block quality in SRAM verification. As previously discussed, a SRAM block contains multiple cells and involves multiple layers, and each SRAM type must follow a particular configuration in placement. The foundries typically don’t know which SRAM types are being used in a given layout, and by extension, which answer is needed to correctly verify a problematic SRAM block in a customer’s design. And, even when SoC designers know where those unmatched areas are, they must still spend a significant amount of time determining exactly where the errors are and how to fix them by examining multiple SRAM cell libraries and then checking every layer to find the differences.

Pattern matching verification
In an ideal SRAM verification flow, designers should be able to see what kind of errors occurred and what differences were found, providing them with the information they need to determine root cause. With this information, designers can then fix the errors in the layout immediately, or pass those identified differences back to the foundry for evaluation and further discussion. One solution might include adding those differences into the verification rules as allowed tolerances.

However, for this solution to work, those allowed tolerances must be precisely placed at the exact location of the original cells of that specific cell type 1) to prevent the SRAM block from influencing other cells or other types of SRAM blocks, and 2) to prevent real errors from being waived. For example, if an upper corner cell must be placed in the top of an SRAM block, it cannot be replaced with a lower corner cell, even if the space for the bottom corner is exactly the same, and even if the upper and lower corners look similar. However, when tolerances have been applied to both corner cells, the differences between the two may be too small to visualize.

But if they look so similar, how can designers determine if the correct cells have been placed correctly? Even worse, what if such similar cells have tolerances applied by the foundry in the SRAM layout, and are then modified by the designers in the full-chip layout? It will be nearly impossible for designers to identify true errors by comparing correct cells with problematic areas, due to the challenge of recognizing which cell is the correct cell to use for checking.

Pattern matching, in which geometries in a layout are automatically and precisely compared to a library of approved patterns by an electronic design automation (EDA) tool, is a proven verification technique that can be applied to SRAM verification. Patterns can be defined to require exact matches, or to allow certain tolerances. A basic verification and debugging process using pattern matching is shown in Figure 4.

Figure 4: A basic SRAM debugging process using pattern matching.

Using an EDA tool containing a pattern-based utility to perform SRAM verification and debugging also provides future benefits. Any differences found during similarity matching (XOR) can be analyzed and, as applicable, added back to the library patterns to improve precision for future verification jobs (Figure 5).

Figure 5: Ideal flow to incorporate new tolerances into SRAM verification rule deck.

For example, using a comprehensive pattern debugging kit like that provided in the Calibre toolsuite, designers can more quickly determine exactly where errors were found in various output formats, and either fix them right away or provide the details back to the foundry for inclusion into enhanced SRAM rules. Figure 6 shows how the Calibre Pattern Matching functionality can be used for enhanced SRAM debugging.

Figure 6: SRAM debugging using Calibre Pattern Matching functionality.

Conclusion
SRAM verification is a challenging, yet critical part of SoC tape-out. Finding and debugging SRAM modification errors efficiently requires designers to have access to the information that enables them to quickly and precisely locate an SRAM error and determine the correct fix. By enhancing their SRAM verification and debugging process with automated pattern matching and similarity checking processes, SRAM designers can find a better, more precise balance between the design flexibility they need and the yield that market success requires.

For more information on balancing flexibility and quality in SRAM verification, download our whitepaper “Finding a perfect balance between flexibility and quality in SRAM layouts.”