Synopsys IC Validator approach could save many physical design spins

Synopsys today announced IC Validator—actually a pair of tools intended to pull forward much of the back-end physical verification and design-for-manufacturing work that now happens after routing. By speeding design-rule checks and metal-fill insertion, making them incremental, and linking them into IC Compiler, Synopsys hopes to avoid the painful sign-off failure-to-physical-redesign iterations that are increasingly common below 90 nm.

The problem, according to Synopsys director of marketing Sanjay Bali, is that by 45 nm, design-rule decks have simply grown out of control. "It’s usual to have over a thousand rules for a 45 nm digital process," Bali said, "and some of those rules can be highly complex." At the same time, a particular DfM subset of the problem, metal fill, is also getting out of hand. Now there are not just different kinds of rules for metal fill, there are prescriptive requirements, such as staggering, for laying out the fill, and by 45 nm the impact of fill on parasitic capacitance–and hence timing–is significant to timing closure. Also, new processes are starting to require fill at the contact layer as well, not just on interconnect metal levels.

Faster, cleverer, parallelized design-rule checkers and metal-fill tools can cope with the complexity. But the problem is that in the traditional flow the checker won’t get run until physical design is nominally completed. It will only tell you that you are wrong, and that you have to go back and alter the routing or, worse, the placement. As the odds of producing a first-time-correct routing get smaller, you really need to know about the problems much earlier than that.

Hence IC Validator. The key component of the new tool is a fast, incremental design-rule checker that is easily called from IC Compiler and is intended to be used, block-by-block, as pieces of the design are routed. To this end, Bali points to three aspects of the tool.

First, the DRC tool has been parallelized for use on multicore servers. ICV employs a load-balancing scheme to dispatch tasks, exploiting both data parallelism—performing the same checks on different portions of the design—and runset parallelism—running different checks on different CPU cores. Taking advantage of both forms of parallelism gives almost-linear performance scaling up to about eight CPUs, according to Synopsys.

Also greatly influencing runtimes, ICV is designed to be incremental. Users can run ICV incrementally on either a particular rule, on a particular layer, or in a window. Incremental runs can make an enormous difference in execution time. Synopsys shows one example, a digital chip with 1.6 million instances, where the full-chip runtime with traditional DRC is about 5.5 hours. Running a single layer in ICV requires less than two hours, while running a single rule or a small window requires only about five minutes. Thus in incremental mode, it is entirely possible to use ICV in consort with the IC Compiler, checking your work as you go. Bali emphasized that the high speed does not mean shortcuts in quality. He said that the checks are sign-off quality, so there should be no surprises when the final sign-off DRC runs are done.

A final change, which apparently was necessary to achieve the speed and flexibility ICV needs, may be less welcome to experienced physical-verification teams. ICV does not use a conventional language for expressing design rules. Instead, it introduces a new proprietary language called Programmable Extensible Language, or PXL, to express the rules. PXL is intended to handle situations that baffle today’s rule languages, such as combinations of edge- and polygon-based rules. Bali claims that PXL, which is similar in grammar to C or C++, will have a short learning curve and can express a given set of rules in 10 to 50 percent of the space required by traditional languages. "Less code means fewer human errors in coding," Bali said. Of course using a proprietary language also means checking to make sure that your foundry has already done the coding for you, if possible.

Along with the incremental DRC tool ICV includes, as mentioned, a new metal-fill tool. The high point here is that the fill tool is timing-driven, so that putting in the fill is not likely to break a carefully-won preliminary timing closure. And the tool does not rely on a track-based algorithm, resulting, the company claims, in significantly more efficient fill patterns.

So how will all this change back-end design? For designers working above 45 nm, it won’t. Synopsys will only provide ICV for 45 nm or more advanced designs. For teams working on these advanced nodes, Bali suggests that teams will probably use ICV to check some key lithography rules, such as halo rules and well-connections, during placement. Then during routing, the team will run all the metal rules and do a trial fill insertion. This should spot most violations and fill problems while the block is still being routed, saving hugely expensive iterations. This applies to digital blocks, of course. Analog blocks will probably not be checked until sign-off approaches, since ICV does not link to analog physical-design tools.

"We are early in seeing how teams will use ICV today," said director of marketing Saleem Haider, "but what we will probably see is that teams will do individual blocks one by one, up to the channels that separate them. Then they will check the area between the blocks during the full-chip DRC at sign-off." Designs that use abutted-block structures, such as consumer chips that must save every millimeter of space, may require a more complex approach to avoid leaving serious violations at the boundaries of blocks to be discovered at the last minute.

The tool is already deployed at "a couple of IDMs" according to Bali, and is now ready for general availability.