Design Rule Management and Its Applications in 15nm FreePDK Technology Michiel Oostindie Sage Design Automation 2075 De La Cruz Blvd. #105 Santa Clara, CA USA +1 408 727-6234 [email protected]Coby Zelnik Sage Design Automation 2075 De La Cruz Blvd. #105 Santa Clara, CA, USA +1 408 727-6234 c.[email protected]Maarten Berkens Sage Design Automation 2075 De La Cruz Blvd. #105 Santa Clara, CA USA +1 408 727-6234 [email protected]ABSTRACT This paper reviews the industry practice of using the design rule manual (DRM) for documenting semiconductor manufacturing limitations and how these are translated to design rule check (DRC) decks. The fundamental flaws in the current paradigm are shown as well as the resulting negative impact on the industry. We will then describe a new paradigm to document and manage design rules that eliminates these flaws and closes the loop between design and manufacturing. We will illustrate the talk with application of the methodology for design rule management and checks performed during the development of the Open Cell Library (OCL) as part of the 15nm FreePDK technology. Categories and Subject Descriptors B7.1 [Integrated Circuits]: Types and Design Styles - advanced technologies, Standard cells. B7.2 [Integrated Circuits]: Design Aids - graphics, verification. General Terms Management, Documentation, Design, Experimentation, Verification. Keywords Integrated Circuits; Semiconductor Technology; Design Rules; Design Rule Check; Electronic Design Automation; Physical Design Verification. 1. INTRODUCTION: DESIGN RULES, DRM AND DRC Design Rules constitute the interface between semiconductor design and manufacturing [1] [2]. Design rules are defined by process technology engineers, as specific geometric constraints on the configuration and distances of the shapes within each layer or between shapes of multiple layers. These constraints reflect the physical fabrication limitations of the process, and keeping the physical design within these constraints ensures that it can be fabricated correctly at the expected yield rate. The foundry specifications of all its design rules are published in a book that is usually referred to as the Design Rule Manual (DRM). This specification is then being used by the design teams for all physical design and verification tasks. To verify that the design conforms to the rules, designers use Design Rule Check (DRC) tools [3] [4] [5] [6] [7]. These are software tools that run a process-specific program called DRC deck or DRC runset. Unlike the DRM which uses descriptive form to define each design rule, the DRC deck is composed of code in a proprietary tool language that manipulates the design shapes in search of rule violations. The use of such paradigm that separates DRM writing from the internal format to be used in DRC tools causes an overhead for the development of design rules (DRMs) for new design processes and the associated physical design kits (PDKs). For every new process technology, the process and design technologists get together and develop the Design Rule Manual (DRM), which implies these two teams have to perform co-development of the DRM [8] [9]. We propose a new paradigm address the development of design rules using a system that captures design rules formally and establishes a direct and verifiable interface between process limitations and design checks. Such a system will be most useful for agile development of technology process rules and PDK development tasks. This paper is organized as follows. Section 2 presents the currently used DRC/DRM paradigm, while the associated limitations are presented in Section 3. A new paradigm is presented in Section 4. Section 5 presents iDRM, a tool based on the newly proposed paradigm. The use of iDRM in the development of the 15nm FreePDK Open Cell library is discussed in Section 6. Finally, conclusions are presented in Section 7. 2. TRADITIONAL DRM/DRC PARADIGM The DRM/DRC pair paradigm has been used for decades, but over time it has exhibited the following inherent characteristics that negatively impact the time and effort it takes to develop process technologies and design enablement kits. 2.1 DRM is informal The DRM is a hardcopy book or a pdf file. Design rule definitions in the DRM are described using drawings and free-form human language that capture the geometric constraints. Since it uses free language, with no formal semantics and syntax, the rule descriptions might often be unclear, incomplete and ambiguous. 2.2 DRC is based on human interpretation This problem becomes even more severe as it propagates to the DRC deck. The deck is programmed manually based on the programmer’s interpretation of the DRM design rule description. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. ISPD’15, March 29–April 1, 2015, Monterey, CA, USA. Copyright is held by the owner/author(s). Publication rights licensed to ACM. ACM 978-1-4503-3399-3/15/03…$15.00. http://dx.doi.org/10.1145/2717764.2717784
Transcript
Design Rule Management and Its Applications in 15nm FreePDK Technology
ABSTRACT This paper reviews the industry practice of using the design rule manual (DRM) for documenting semiconductor manufacturing limitations and how these are translated to design rule check (DRC) decks. The fundamental flaws in the current paradigm are shown as well as the resulting negative impact on the industry. We will then describe a new paradigm to document and manage design rules that eliminates these flaws and closes the loop between design and manufacturing. We will illustrate the talk with application of the methodology for design rule management and checks performed during the development of the Open Cell Library (OCL) as part of the 15nm FreePDK technology.
Categories and Subject Descriptors B7.1 [Integrated Circuits]: Types and Design Styles - advanced technologies, Standard cells. B7.2 [Integrated Circuits]: Design Aids - graphics, verification.
General Terms Management, Documentation, Design, Experimentation, Verification.
1. INTRODUCTION: DESIGN RULES, DRM AND DRC Design Rules constitute the interface between semiconductor design and manufacturing [1] [2]. Design rules are defined by process technology engineers, as specific geometric constraints on the configuration and distances of the shapes within each layer or between shapes of multiple layers. These constraints reflect the physical fabrication limitations of the process, and keeping the physical design within these constraints ensures that it can be fabricated correctly at the expected yield rate.
The foundry specifications of all its design rules are published in a book that is usually referred to as the Design Rule Manual (DRM). This specification is then being used by the design teams for all physical design and verification tasks. To verify that the design conforms to the rules, designers use Design Rule Check (DRC) tools [3] [4] [5] [6] [7]. These are software tools that run a process-specific program called DRC deck or DRC runset. Unlike the DRM which uses descriptive form to define each design rule, the DRC deck is composed of code in a proprietary tool language that manipulates the design shapes in search of rule violations. The use of such paradigm that separates DRM writing from the internal format to be used in DRC tools causes an overhead for the development of design rules (DRMs) for new design processes and the associated physical design kits (PDKs). For every new process technology, the process and design technologists get together and develop the Design Rule Manual (DRM), which implies these two teams have to perform co-development of the DRM [8] [9]. We propose a new paradigm address the development of design rules using a system that captures design rules formally and establishes a direct and verifiable interface between process limitations and design checks. Such a system will be most useful for agile development of technology process rules and PDK development tasks.
This paper is organized as follows. Section 2 presents the currently used DRC/DRM paradigm, while the associated limitations are presented in Section 3. A new paradigm is presented in Section 4. Section 5 presents iDRM, a tool based on the newly proposed paradigm. The use of iDRM in the development of the 15nm FreePDK Open Cell library is discussed in Section 6. Finally, conclusions are presented in Section 7.
2. TRADITIONAL DRM/DRC PARADIGM The DRM/DRC pair paradigm has been used for decades, but over time it has exhibited the following inherent characteristics that negatively impact the time and effort it takes to develop process technologies and design enablement kits.
2.1 DRM is informal The DRM is a hardcopy book or a pdf file. Design rule definitions in the DRM are described using drawings and free-form human language that capture the geometric constraints. Since it uses free language, with no formal semantics and syntax, the rule descriptions might often be unclear, incomplete and ambiguous.
2.2 DRC is based on human interpretation This problem becomes even more severe as it propagates to the DRC deck. The deck is programmed manually based on the programmer’s interpretation of the DRM design rule description.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. ISPD’15, March 29–April 1, 2015, Monterey, CA, USA. Copyright is held by the owner/author(s). Publication rights licensed to ACM. ACM 978-1-4503-3399-3/15/03…$15.00. http://dx.doi.org/10.1145/2717764.2717784
Following that subjective interpretation, the programmer writes a sequence of low level geometry manipulations that attempt to identify design rule violations and flag them. Since many rules in the DRM are already unclear and ambiguous to begin with, adding subjective interpretation to it and then implementing a code compounds and exacerbates the problem.
2.3 DRC deck correctness and completeness Today there is no formal way to compare and verify that each piece of code in the DRC deck implementation fully and correctly represents the design rule intent it is supposed to check. It is a difficult problem, because the DRC deck coder has to think about all possible ways to violate the rule and make sure his check code covers them all. This mainly exhibits itself in early version implementations of the DRC deck for a new technology, which often suffer from errors and inaccuracies. Finding such errors and cleaning up the DRC deck code is done through an iterative trial and error process which takes a long time and effort, and even then few errors may remain after a DRC deck is released to designers.
2.4 Different roles and expertise domains The DRM and DRC deck represent two very different functions, view-points and expertise domains. The DRM is a rule specification written by process technology people for humans. It is descriptive in nature so that designers can understand what configurations and distances are legal and construct the physical design accordingly.
By contrast, the DRC code is a machine code that executes geometric operations on physical design. The DRC code has no notion of what is the allowed rule – it is focused on the negative side, i.e. rule violations, manipulating the design to generate error marker polygons in specific locations where the programmer thinks such errors will manifest themselves.
The DRC programmer is a CAD professional skilled in a specific DRC programming language that manipulates polygons. In most cases the programmer does not know the original design rule exact intent and therefore can misinterpret it or miss some aspects of it. Because of tool or human limitations, in some cases it may be hard to program a complete and accurate check for a specific rule description, and the DRC code may be constructed to check only an approximation of the rule, but not the exact rule intent. Such compromises are hard to detect.
2.5 Advanced node rule complexity With newer and more advanced process technologies. the above issues have become much more profound and with increasingly negative impact on process ramp-up and design enablement efforts. The number and complexity of design rules has grown exponentially with every technology node since the 40nm node [10]. Advanced lithography limitation, OPC requirements, double patterning, new materials, new layers, and new device structures and constraints have all added new types of rules and complexities that have not existed before. As a result, current commercial technologies use DRMs that hold thousands of design rules and each rule may have multiple variables and conditions. Understanding the exact intent of each and every rule and implementing them correctly in DRC decks have become a very laborious, difficult and error prone task.
3. LIMITATIONS OF CURRENT METHOD Due to the above mentioned characteristics, using the traditional paradigm has the following disadvantages and limitations. These limitations become more pronounced in the case of PDK and library development at the early stages of a new process offering.
3.1 Double work Each new rule requires creating both a DRM representation and a DRC deck implementation.
3.2 Consistency The DRC deck representation is independent of the DRM representation, and the current methodologies cannot ensure consistency between the two.
3.3 Iterations Due to the inconsistencies the current paradigm requires iterations between programming the DRC deck and the DRM specification.
3.4 No interaction or feedback The current system is not suitable for quick and interactive design rule exploration and for doing what/if analysis using changing design rules.
3.5 Collaboration The current system is not suitable for intra-group or inter-group collaboration. For example the library team needs to work closely with the design rule team exploring adding or modifying rules.
4. A NEW PARADIGM In order to overcome the limitations described in the previous Section, we propose a new paradigm: A system that captures design rules formally and establishes a direct and verifiable interface between process limitations and design checks. Such a system will be most useful for process development and PDK development tasks.
The new system should offer the following qualities and capabilities:
‐ Enable design rules to be entered and captured by process engineers that are not programmers.
‐ The captured description should be formal, complete and unambiguous.
‐ The captured description should be clear and interactive - allowing the user to query certain details and properties This will resolve any problems caused by communication issues between the two groups of DRM development and DRC deck development.
‐ Executable: The design rule description is machine readable and its representation can be used for a variety of automated tools and tasks. For example, the rule description could generate a correct-by-definition rule check, putting an end to subjective interpretation and error-prone programming. This allows rule developers to immediately try their rule definition on test layout and verify it against their mental intent. It shortens the iteration loop and since all is done by the same person, errors are avoided.
5. THE iDRM SYSTEM One commercial system that offers the above capabilities is the iDRM (integrated Design Rule Management) platform from Sage Design Automation. The iDRM system includes a graphical design rule editor where the user draws the pattern that describes the design rule, adds arrows marking proximities and distances between shapes, edges or corners, and assigns parameter names to them. e.g. spacing, width, gate-pitch, etc. The user can then add logical expressions and conditions, using these parameters as variables, to express statements that further qualify the patterns that are associated with a design rule.
Once a rule has been captured it serves not only as a clear visual description and documentation, but it also becomes an executable program. The user can run this rule definition on a physical design, and iDRM will scan the layout and will find all locations where a pattern matches the design rule description and for each instance will measure all the parameters used in that definition. Based on the logical expression in the rule, the tool will determine a pass or fail result for each instance. This is the equivalent of a DRC check although no DRC check has been programmed. iDRM takes this concept a step further with automatic physical design scan and analysis. For each rule instance it finds, the tool will take all the relevant measurements of the parameters that were used in the rule definition. The result of this scan is a complete list of all design rule instances, each with complete information of all the relevant measurements, orientations, etc. The scan & analysis function can be considered as a superset of a DRC check, where instead of a binary pass/fail result, it provides full resolution measurements and geometrical information for each use of a design rule in the layout. iDRM outputs the results in tables or various graph formats, and the integrated layout viewer provides a one-click hop from each such result entry to the layout location where this specific instance is found.
6. USING IDRM FOR DEVELOPMENT OF THE FREEPDK15 LIBRARY The FreePDK15 is an open source predictive process design kit for 15nm FinFET technology [11] [12]. It was developed mainly for educational and demonstration purposes, but it includes a set of design rules that were developed to represent the main types of rules seen in actual foundry 14/16nm FinFET technologies. While FreePDK15 technology is not a real process that is used for silicon fabrication in any specific foundry, it does exhibit some of the main innovations of this technology node, e.g. FinFETs, MOL (middle-of-line) interconnect layers, cut layers and double patterning layers.
Our team took part in creating the standard cell library for this PDK and making it design rule correct. We had to start working on the library very early on when the design rules were still being developed. Moreover, the cell and library architecture has also influenced some of the design rules, and so this was a dynamic co-development process. During this co-development process we needed a method to quickly try and explore different rules as well as check them and also add specific library architecture rule checks. We could not rely on traditional DRC decks, since these take longer time to code and verify, and were not fully released at the time of our library development work.
For developing the library we needed to consider the technology design rules of all the FEOL layers, MOL layers and up to M1 and Via1. We drew and defined the rules in iDRM and had immediate DRC checkers for our needs. Any rule modification was automatically turned into an updated and accurate DRC check.
In the next section we'll describe a few design rule implementation examples that illustrate the use of iDRM and this new methodology. The DRM reference for these rules is the FreePDK15 design rule development document published by NCSU [11] [12].
6.1 Rule Example: Enclosure of V0 by AIL2 Via0 (V0) is used to connect active local interconnect layer (AIL2) to Metal1 (M1A) layer. The V0.5 design rule defines the minimum enclosure of V0 by the AIL2 layer [11] [12].
6.1.1 DRM Design Rule Description Fig. 1 shows how this specific enclosure design rule is defined in the DRM.
Figure 1: V0.5 rule in the DRM [11]
6.1.2 IDRM Implementation The rule is captured in iDRM GUI by a similar drawing of the two layers and with similar arrows defining the enclosure distances, as illustrated by Fig. 2. In this implementation we chose to denote the horizontal enclosure distances as l (left) and r (right), and the vertical ones as t (top) and b (bottom). To make the rule definition more general, we used parameter names minHorExt and minVertExt that we can populate with any specific values (in this case -2nm and 20nm respectively). The DRCheck statement shown in the right hand section checks that all 4 distances are equal or greater than the respective values.
Once the design rule is captured the user can immediately run it on a physical design and the tool will find every instance of this drawn rule, and for each instance will measure the four distances l,r,t,b and will evaluate the DRCheck expression using these values and determine whether it adheres to the rule or violates it. The tool will highlight all these instances in its integrated viewer. In our case we used a layout consisting of standard cells under development. Fig. 3 shows a clip of the layout with V0.5 instances highlighted by iDRM. Note that all arrows are green indicating no design rule violation was found. This interactive feedback allows the user to immediately review and verify the rule definition and ensure it accurately represent its original intent.
Figure 2: Rule captured in iDRM
Figure 3: Design rule matches found and evaluated in iDRM
Using its data scan analysis function, iDRM can also provide complete numerical information on all such matches in the design.
Fig. 4 shows a result of using this function. In this case a table format was selected. Each table entry shows a different combination of values measured and their occurrence in the design. Each table entry is linked to its respective locations in the viewer for further review and analysis.
Figure 4: Results of using scan analysis function
6.2 Cell Architecture rules Not all design rules are related strictly to manufacturing. There are types of design rules that emanate from electrical requirements or physical architecture requirements. In the case of a standard cell library development, there is a need for library specific rules. These rules are in place to ensure standard height of all cells, clean abutment between cells, a certain width of the common supply bars, etc. We also used iDRM to define such rules and enforce them. The mechanism to define these rules is similar to the DRM rules and therefore we don't see a need to repeat it here in the same level of detail.
For illustration we have included a screen image of a high level representation of the rules in iDRM, which includes a few cell architecture rules grouped together by the user, as it is shown in Fig. 5. Each specific rule can be expanded upon selection of the hyperlink by the user.
Figure 5: A group of cell architecture rules in iDRM
7. CONCLUSIONS The current methodologies of defining, documenting and creating checks for design rules are still done manually, lacking automatic verification capabilities and slow to converge. This is particularly problematic during the early development phase of process technology and design enablement kits.
We suggested a new methodology that enables machine readable design rule capture and a single design rule representation for both documentation and check. This eliminates double and triple capturing of design rules and the inherent inconsistencies that are caused by it. It also speeds up the development process and facilitates easy design rule development and exploration.
The iDRM tool is a software platform that implements such new methodology, and we had the opportunity to use it for the development of the freePDK15 library [13] [14], enabling us to capture and use design rule checks when rules were still changing. We showed a few examples that illustrate the use of this methodology and its contribution to fast PDK development.
As a future suggested work, we highlight that iDRM has a distinct function (DRVerify) that generates an exhaustive set of test cases for each captured design rule, which is then used to verify DRC decks. The set includes both pass cases and fail (rule violation) cases that completely cover the design rule expression. We suggest the use of this function to generate test cases for the freePDK15 design rules, so that any commercial DRC deck made for these rules can use these test cases to verify its correctness.
8. ACKNOWLEDGMENTS We want to thank Prof. Andre Inacio Reis and his team from the Universidade Federal do Rio Grande do Sul, Brazil, for reviewing our work and for their significant contributions to this paper. We also thank Kirti Bhanushali and Prof. Rhett Davis from North Carolina State University for letting us use the FreePDK design rule examples.
9. REFERENCES [1] Carver Mead and Lynn Conway. Introduction to VLSI
[2] Neil Weste and David Harris. CMOS VLSI Design: A Circuits and Systems Perspective. Addison-Wesley; 4 edition, 2010
[3] Y. Z. Liao and C. K. Wong. 1983. An algorithm to compact a VLSI symbolic layout with mixed constraints. In
Proceedings of the 20th Design Automation Conference (DAC '83). IEEE Press, Piscataway, NJ, USA, 107-112.
[4] Losleben, P.; Thompson, K., "Topological Analysis for VLSI Circuits," Design Automation, 1979. 16th Conference on , vol., no., pp.461,473, 25-27 June 1979.
[5] Smith, R.; Joy, R., "Computer aided design tools for VLSI," Solid-State Circuits Conference. Digest of Technical Papers. 1980 IEEE International , vol.XXIII, no., pp.193,193, 13-15 Feb. 1980.
[6] Jin-Fuw Lee, "A new framework of design rules for compaction of VLSI layouts," Computer-Aided Design of Integrated Circuits and Systems, IEEE Transactions on , vol.7, no.11, pp.1195,1204, Nov 1988.
[7] McGrath, E.J.; Whitney, T., "Design Integrity and Immunity Checking: A New Look at Layout Verification and Design Rule Checking," Design Automation, 1980. 17th Conference on , vol., no., pp.263,268, 23-25 June 1980.
[8] Vito Dai ; Jie Yang ; Norma Rodriguez ; Luigi Capodieci; DRC Plus: augmenting standard DRC with pattern matching on 2D geometries. Proc. SPIE 6521, Design for Manufacturability through Design-Process Integration, 65210A (March 28, 2007).
[9] Raina, R.. What is dfm & dfy and why should i care? IEEE Test Conference, 2006. ITC'06, pp. 1-9.
[10] Rick Merritt, Synopsys bullish despite rising chip complexity Article, EETimes designlines March 26 2013 http://www.eetimes.com/document.asp?doc_id=1280659
[11] Kirti N Bhanushali. May 2014. Design Rule Development for FreePDK15: An Open Source Predictive Process Design Kit for 15nm FinFET Devices Thesis, North Carolina State University http://www.lib.ncsu.edu/resolver/1840.16/9519
[12] Kirti Bhanushali and Rhett Davis. “FreePDK15: An Open-Source Predictive Process Design Kit for 15nm FinFET Technology”, ISPD 2015.
[13] Mayler Martins, Jody Matos, Renato Ribas, Andre Reis, Guilherme Schlinker, Lucio Rech and Jens Michelsen. “Open Cell Library in 15nm FreePDK Technology”, ISPD 2015.
[14] Jody Matos, Augusto Neutzling, Renato Ribas and Andre Reis. “A Benchmark Suite to Jointly Consider Logic Synthesis and Physical Design”, ISPD 2015.
