What's PR got to do with it?
Ed Lee has been around EDA since before it was called EDA. He cut his teeth doing Public Relations with Valid, Cadence, Mentor, ECAD, VLSI, AMI and a host of others. And he has introduced more than three dozen EDA startups, ranging from the first commercial IP company to the latest statistical … More »
Design Rule Manual Creation a Bottleneck?
June 24th, 2013 by Ed Lee
Sage Design Automation, Inc. announced its founding technology last month and created a lot of customer and media buzz at DAC’13 inAustin. I bet a lot of people were surprised that design rule manual creation and DRC deck implementation were manual, error-prone tasks – especially as we get into smaller process geometries – and that they can take years to put one together.
In a way, it’s a lot like writing a long paper on a typewriter, or even by hand. When you make an error, you use White Out (remember that?) or type back over the error with the erasing ribbon. There’s no way to correlate the paper’s index, spell check, grammar check or check for consistency.
So we accosted Sage-DA president and CEO Coby Zelnik to ask him about this problem, one that many of us assumed just took care of itself! Here’s what he had to say.
Coby: Yes! Definitely! Design rule manuals are 2” thick, have 600 pages, hold 5000 or more design rules and many more variables and conditions. And with each new technology node, design rules are growing in number and complexity.
Ed: Just to be on the same page as you, what are design rules?
Coby: Design rules represent the manufacturing process limitations and how they interact with physical design constraints. They are the critical interface between manufacturing and design; without design rules and the ability to check them correctly, no design can be fabricated and no semiconductor product can be made. In the latest process technologies – say 20nm, 16nm, 14nm and lower – it is becoming much more difficult to define these rules, understand them, design by them and check them.
Ed: So Coby, just to clarify, what takes years to complete? The manual, the deck development and debug or both?
Coby: The deck development takes years until it is stable and usable by designers. Of course during that time also the manual changes to reflect errors, process modifications and adjustments to the deck.
Ed: So the problem is the number of the design rules in the manual?
Coby: One problem is that these thousands of design rules are written manually in free-form language.
Ed: That’s a problem?
Coby: Yes! Many rule descriptions are incomplete, ambiguous and hard to understand. That is why we founded Sage…to give the design rule creators and users a way to define these rules easily, formally and clearly to avoid errors and wasted efforts.
The second problem is that the DRC (design rule check) deck is also programmed manually.
Ed: I bet many of us never thought about design rule manuals. That DRC just checked miraculously and automatically. You’re saying that the rules that govern DRC checks are becoming unreliable due to the number and complexity of rules? What’s the need?
Coby: As I said, today both design rule manuals and design rule decks are written manually. One of the biggest problems is that the DRC deck code is programmed manually based on subjective interpretation of the design rule description by the individual programmer. So you got both a duplicated effort and a double, compounded probability for errors.
There is a need to formalize and disambiguate the design rule descriptions and try to automate the DRC deck or at least ensure that the DRC deck implementation agrees with and accurately represents the design rule description.
Ed: How does this brand new product work? By the way, what is the product name?
Coby: The product is called iDRM. How does it work? You mean how does the user interact? The user uses the iDRM GUI to quickly draw each design rule physical topology, specify parameters or constraints (such as specific distances) and add logical or mathematical expressions that use the parameters in the drawing. It is a very visual and clear rule capture with no ambiguity.
Once a design rule is captured in iDRM, it becomes both a formal description and an executable check, and the user can use it to correlate and verify it against the fab test data, ensuring that the rule fully and accurately covers all the weak spots and thus captures the process limitations (the rule intent) on the manufacturing end.
At the DRC deck coding end, the PDK engineer can use the same rule capture to verify the respective DRC code, by automatic generation of automatically tagged pass/fail regression test cases and automatic comparison of the DRC run results against the iDRM rule results (representing the rule intent). So iDRM provides automatic and accelerated closure between process limitations, their design rule manual representations and the latter’s DRC deck implementation all the way from the foundry process engineer to the PDK development and to the final design rule check.
Ed: So just to be clear, iDRM isn’t a new DRC tool, right?
Coby: Absolutely not. We don’t need another DRC tool. iDRM works with current DRC tools by feeding in smarter, more accurate and complete information and by verifying their code, So better design rule decks are made available faster, enabling error-free and optimized designs to be fabricated in advanced technology sooner and with higher yield.
Lee PR does work for Sage