Sage-DA: Automating rule checking

If ever there was a need for additional help in design, now is the time. As the industry marches down, node after node, the problems ramp up, node after node.

After my conversation with Mentor’s Joe Sawicki several weeks ago about all of the pros/cons of moving to the next node, it was good then to speak with Sage-DA CEO Coby Zelnik about how his company’s tools are designed to help solve the single most ferocious problem that arises once designers in the trenches are ordered to make that move – the explosion in number and complexity of design rules.

Given that you all know how design rules work, can you quote chapter and verse about how the numbers of rule operations increase in the DRC Manual with each progressive node? Zelnik included a slide in his presentation last week that laid out the nightmare. At 65 nanometers, it’s 3000 rules; at 40 nanometers, it’s 4000 rules; At 28, it’s 8000. But at 20 and 16, the number stands at a staggering 16,000. The sheer magnitude of those numbers is what made the conversation last week with Zelnik so interesting.

Sage-DA has a long track record dealing with the difficulties of design rules, but per Zelnik, “We are now announcing the first tool to verify that the design rules are all being checked correctly, the first to provide exhaustive coverage of all of the complex rules. It’s the biggest issue related to physical verification, and we have successfully addressed that issue. We’re calling the product DRVerify, and have added it into our existing tool suite: iDRM.

“As you know, the Design Rules Manuals are all internally developed at the foundries and are published in an attempt to help the designers. These manuals are basically ink-and-paper books,” Zelnik added, “or more accurately, PDF files that are securely delivered to the designers and contain proprietary information for each foundry.”

“Although clearly there are thousands of rules,” I asked, “can we take any comfort in knowing that some are more important than others?”

Zelnik said, “Actually, all of the rules are important, but that’s not to say they are all complex. The new rules are more complex, and become more so with each smaller process geometry, but complex or not, all rules need to be coded into the Design Rules Checker decks, by which designs are checked for sign-off.”

“Isn’t this a perfect use of automation, the coding of the design rules?  Has it ever been done?” I asked.

Zelnik said, “Yes and no. DRC decks have been with us for over 40 years, and they are low-level programs that have tried to find errors in the design. But with each new rule that comes up, somebody needs to write a program and check it within the context of each vendor’s tools – Mentor Graphics, Synopsys, or Cadence – because each company has its own language.

“You can consider the actual checking, which is running the DRC deck, as a form of automation, but the creation of the DRC deck is done manually, so there are no guarantees that the deck is correct and that the DRC tool actually checks the rule correctly and covers all possible corner cases.

“So, although it seems intuitive that automation could be applied to the effort, in fact it’s quite hard to code these rules and takes a lot of effort. Meanwhile, most of the rules have already been coded, and modifying them for the smaller nodes might be  just a matter of changing values. However, the rules strictly associated with the new nodes are increasing exponentially, and have yet to be coded – which is a big problem.”

I asked if it would be possible to wing it, to move forward with a design at a lower process node and just hope for the best without complete DRC verification.

Zelnik laughed, “Absolutely not. Designers have to verify that a design is correct-by-the-rules, that it’s laid out correctly, and that any chance of wrong spacing between lines and corners, etc., will not precipitate a failed chip.

“In order to check the quality and coverage of their DRC decks, people [in those organizations] are generating multiple pass and fail cases within the design rules they care about – does the end of this line have sufficient space from the next line over, etc. – and generating different values for their test cases in wanting to find all the possible DRC cases.

“DRVerify does this automatically, based on the design rule formal description, and covers all possible boundary values, both the ones that violate the design rule and the ones that obey it.”

[Click on image to see full resolution: DRVerify automatically generates exhaustive set of pass/fail test cases from a design rule definition.]

“Your customers then are the foundries who need help with coding and verifying their design rules, and not necessarily in that order?” I asked.

Zelnik said, “Yes, it’s useful to the people in the foundry who can visualize the rules they wrote, so in that case our customer is the foundry. By looking at what’s generated by our tools, they can see things they might not have otherwise thought of.

“But, we also provide a service to the designers. By animating the text of the rules, by creating a visual that ties to the constraints narrated in the rule, designers can actually ‘see’ when they have violated a rule in their design.

“So in that case, our product is for the people who are actually using the DRC decks. And, in the specific instance that you mentioned earlier our tool can be used as an analysis prior to targeting a next generation design at the next node.

“The number of design rules and their complexity have grown out of proportion in the last few years and yet we are still developing design rule manuals and design rule checks the same way as we did 20 and 30 years ago, only applying much more effort, sweat and time.”

“It’s about time that we stop using brute force to solve these things,” Zelnik concluded. “We need to use the technology to bring ourselves into the 21st century, when there is technology and so much smart engineering available instead.”

******************

Tags: Coby Zelnik, DRVerify, iDRM, Sage-DA

This entry was posted on Wednesday, March 26th, 2014 at 10:33 pm. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.