January 29, 2008 -- Magma Design Automation, Inc. has announced Talus QDRC, a physical-design verification product that improves productivity and time to market for 65- and 45/40-nm designs by identifying and correcting design rule violations during implementation. Unlike prevailing DRC methods that require streaming data from an implementation database, resulting in missed errors that require design rework, lengthening the design cycle of today's complex devices significantly, Talus QDRC decreases overall design costs by addressing design rule check (DRC) problems before they delay design tapeout.

Talus QDRC operates systematically during implementation, reducing the post-implementation DRC sign-off effort and shortening the final physical-design verification stage of chip development. Talus QDRC has access to all layout layers with IP reference views to identify common problems that can affect final sign-off downstream in the flow, including LEF-versus-GDS mismatch; problems with metal fill; and open/ short detection. It also saves cycle time by eliminating the need to stream data out of and back into the implementation flow for DRC or layout versus schematic (LVS) analysis.

"Talus QDRC improves designers' productivity by eliminating DRC problems early in the flow. The design implementation teams using Magma have better visibility and control of their designs as they move to tapeout because potential DRC errors are eliminated during implementation," said Kevin Walsh, Vice President of Marketing for Magma's Physical Verification Business Unit. "Magma's unified data model and the power of Talus QDRC combine to give our users data abstractions of the right layers at key points in the flow that enable efficient and accurate DRCs during implementation.''

According to Magma, Talus QDRC is easy to implement in virtually any existing flow: the world's leading foundries support Talus QDRC with foundry-certified design rule runsets, and a runset translator lets users run Calibre rules during Talus implementation by reading and converting Calibre decks to produce Talus QDRC rules.

Speeding and minimizing costs of implementing DRC-clean designs

Talus QDRC helps minimize the time and costs of implementing DRC-clean designs. It lets designers run checks using foundry-certified design-rule runsets directly on blocks without having to stream out the data in GDSII format. Reference-level IP views of all GDS layers can be generated making debugging easy. A debugging user interface exposes DRC issues systematically. ECO changes are handled with a new incremental capability that uncovers DRC checks in minutes rather than hours or days, working on just the changed portion of the design. Talus QDRC's unique pipelined architecture scales linearly with the addition of more CPUs, shortening execution times without requiring costly machines.

"Typical 65-nm blocks range in size from one million to two million instances with physical GDSII file sizes ranging from 1.5 to 2.5 gigabytes, and the typical runtimes to check the design for rule violations can range from five to seven hours. These checks are run four or five times on each block. So you might have to spend up to 35 hours per block running checks," Walsh noted. "And that doesn't include the time it takes to back annotate the markers and make corrections in the implementation database. As the design approaches completion, the size can increase to more than 10 million instances with a GDSII file size of more than 7 gigabytes. This back-end checking flow can add weeks to the design cycle.

"The runtime and hardware cost at 45 or 40 nanometers will be even worse than at 65 nanometers," Walsh added. "Design size will increase to nearly 20 gigabytes. DRC processing times will explode and move beyond the single-day turnaround threshold. To meet this turnaround explosion, the DRC engines will respond by using multiple CPUs and threading the operations. But this will drive hardware costs up — because threading still requires a single processor to control and consolidate results, the runtimes do not scale linearly. And because the older engines require that the data model be memory resident to resolve the checks that are common at 65 nanometers and at 45 or 40 nanometers, this large memory footprint will dramatically increase the overhead project costs in order to deploy these costly machines."

Availability