Automatic Environment For DRC Rule File Development And QA

The process of verifying DRC rule files is becoming more complicated as technologies of 90 nm and smaller are reached. A typical DRC rule file for the 90 nm technology node has around 1000 different rules that need to be verified using dedicated layout test patterns for each rule category. These test patterns are generated manually or using semi-automatic scripts that need to be called by the QA engineer with special parameters and are difficult to use and maintain. This job is extremely tedious and time consuming considering that thousands of shapes need to be created. In addition, the created shapes need to ensure coverage by considering as many cases as possible of the pass and fail situations of each DRC rule. Moreover, the results of the DRC run on test patterns need to be analyzed to ensure that the rule file developer has properly represented the design rule. Meeting these challenges calls for improved methodologies that make effective use of automation to enhance quality, reduce development cycle time, and improve productivity.

A key to effective automation is providing a generic rule format that enables description of design rules by process engineers in a standard and consistent way. Doing so will not only address the above problems but it will eliminate communication errors between process engineers and rule developers. It can also support further enhancements such as automatically generating the entire rule file.

One way to construct a generic rule format is based on special keywords. Each keyword can target one rule category (i.e., spacing, width …) and additional arguments should follow the keyword to give further insight about the rule like the layers involved, constraints and so on. There should be room as well for more advanced arguments to further describe complicated situations like orientation, projection, singularity, connectivity, etc. In general keywords should be generic and their number should be kept to a minimum. On the other hand, they should be capable of representing the design manual entirely.

Considering test pattern generation, the methodology should address important issues like rule coverage, layer mapping and layer derivation. It should provide a database of test patterns that are technology node independent. More importantly, the database must include test patterns that cover all violation scenarios considered by the DRC rules. The key to test pattern coverage is experience and continuous improvements, so the database must facilitate capturing new test pattern requirements that cover new or updated scenarios.

Considering rule file generation, a template has to be created with controllable switches to account for optional arguments in the generic rule format. It should consider also the best practices of the targeted DRC tool to provide optimized, high quality rules.

Mentor Consulting has devised a methodology that efficiently addresses these issues and challenges. A possible flow representing this methodology is shown in Figure 1. This methodology provides a means for automating DRC test pattern and rule file generation and QA reporting. This methodology not only saves time, improves productivity, ensures consistent and accurate QA, but it enables continuous improvement of test pattern coverage and rule quality.