Designers may find the flow from the design rule specification tool to the design rule check tool to be surprising (spoiler: there is no design rule specification tool).
The cornerstone of physical verification is DRC (design rule checking): checking that the design adheres to the technology design rules. As we all know, DRC has become very challenging in advanced technologies, as there are thousands of rules and their complexity grows exponentially. As a result, programming and verifying the DRC check code becomes a very hard and challenging task.
Designers are very familiar with DRC tools. These tools have been around for more than 30 years, and each major EDA company offers one. What designers are less familiar with is how these checks are being constructed -- the flow from the design rule specification tool to the design rule check tool. What they may find to be really surprising is that actually there is no design rule specification tool.
The prevalent practice is to start programming DRC check code without such formal specification. This practice has held on for years, but -- with rules becoming so complex -- programming checks for them without a formal spec will be fraught with issues: the code writing takes a long time, and hand-programming is error prone and very tough to maintain and update. Errors or inaccuracies in the check code vs. the rule intent may result in too much slack in density in the better case and lower yield in the worst case. This practice is equivalent to writing complex code for a system or component right away without a specification of the system or the component behavior. It doesn't sound very reassuring, does it?
So, where do designers find design rule specification today and in what format? In the absence of one, they have only two possible design rule representations available to them:
- The DRM (design rule manual): This is the book that describes the rules for designers. The DRM is free-form description in English of the design rules. It is intended to allow designers to understand the geometrical constraints and to construct their physical design to abide by them. In the past, when rules were few and simple, you could argue that the DRM served as a "spec," although the rules descriptions are not written formally and there was no automated way to check a DRC implementation against them. But in the last few years, with the exponential increase in rule complexity, it has become too difficult to describe such complex rules in free format. This means that some of these descriptions can be hard to understand, ambiguous, and open to different interpretations. Furthermore, designers working on advanced node designs will tell you that -- in the early versions of a process technology -- there might be discrepancies between the DRM description (or their interpretation of it) and the DRC run results. When designers point out such discrepancies to the DRC code owners, the common suggestion is to "Ignore the DRM rule description since it is not a formal spec anyway."
- The DRC check code itself: The problem is that the DRC deck (sometimes called the DRC runset) is an implementation of checks that try to find design rule violations or deviations from the spec. It should be a derivative of the spec, but it is not the rule spec itself and it does not capture the rule intent. In addition, this implementation code is pretty obscure and hard to follow and figure out what the check exactly does, not to mention that parts of it are often encrypted. Considering the checks as the rule spec is, in fact, admitting that there is no rule spec.
The practice of implementing a DRC check without a formal spec, is wasteful, expensive, and risky. Since there is no spec to verify the check against, it is a slow iterative work of trial and error that ends with each rule check implementation being at most as good as the completeness of the design examples and tests thrown at it, which can be quite arbitrary.
Current method for handling design rules.
The consequences of the current state of affairs are as follows:
- The rule implementation might be too much constrained: i.e., it may flag design configurations that are not problematic and therefore leave silicon area on the table or make it harder to design.
- The checks may not cover all possible configurations: i.e., leave loopholes that designers may unwittingly use until these are later plugged after problems are detected by process simulation or bad silicon.
- Design rules, design checks, and the entire PDK that relies on them will be (already are, in many cases) very hard to maintain and change, causing delays in revisions and inconsistencies between different tech-files and/or rule representations.
- Cause a huge waste of time and effort. Time to design and process ramp in new nodes is extremely expensive, and the slow convergence caused by the current state of affairs will carry a huge (although arguably hidden) price tag.
How can we solve this problem?
The current methods are relying on 20-year old paradigms and cannot keep up with the growing complexities of advanced technologies. We need to develop a new methodology to manage design rules. The solution is a more structured system that incorporates the following few simple principles and capabilities:
- The design rules need to be captured and specified formally in a way that is both machine readable and clear for designers or any other users of the rules.
- The system should have mechanisms that enable automatic verification of DRC check implementations against the formal rule spec.
- Ultimately, the system should incorporate a mechanism to automatically generate DRC check code from spec, as well as include hooks to generate technology files for physical design implementation tools.
Using formal specification and automation.
This is not "pie in the sky." Some of these solutions already exist. EDA can provide the automation technology, so it's a matter of the foundries and IDMs working together with EDA providers to implement this vision and adopt the solution. The benefits are great and they will be shared by the entire semiconductor ecosystem, so what are we waiting for?
Coby Zelnik is the President and CEO of Sage Design Automation, which he founded in 2013. Prior to Sage, Zelnik was President and CEO of Sagantec from 2008 - 2013.
Join over 2,000 technical professionals and embedded systems hardware, software, and firmware developers at ESC Silicon Valley July 20-22, 2015 and learn about the latest techniques and tips for reducing time, cost, and complexity in the embedded development process.
Passes for the ESC Silicon Valley 2015 Technical Conference are available at the conference's official site with discounted advance pricing until July 17, 2015.
Make sure to follow updates about ESC Silicon Valley's talks, programs, and announcements via the Destination ESC blog on Embedded.com and social media accounts Twitter, Facebook, LinkedIn, and Google+.
The Embedded Systems Conference, EE Times, and Embedded.com are owned by UBM Canon.