Parasitic Extraction—My Head Hurts!

By Carey Robertson, Director of Product Marketing, Mentor Graphics

IC physical verification requires a number of different types of checking, the most familiar being design rule checking (DRC), layout vs. schematic (LVS) checking, and parasitic extraction combined with circuit simulation. Fundamentally, it does not matter whether you are designing an analog, digital or memory circuit, and it does not matter if you are at the cell, block or full-chip level, you still have to meet the manufacturing requirements for that particular process, and you still need to verify that your logical representation matches your physical design. While EDA vendors have been successful in providing DRC and LVS platforms that can address all these different design styles and flows, parasitic extraction, on the other hand, does not fit well into a “one size fits all” solution.

Because extraction is a “means to an end,” you first need to consider what “end” you are trying to address, which means understanding what circuit simulation task would you like to perform. That simulation goal may be timing, noise analysis, signal integrity, IR drop, clock tree analysis, or some other static or dynamic simulation. Next, you need to factor in the design style (memory, analog, RF, digital ASIC, custom digital, SoC, cell libraries, etc.) and the abstraction level (transistor-level, cell-level, block-level, full-chip). One additional point to consider is that extraction models also vary substantially by process node, because as critical dimensions drop below 65 nm, the underlying electrical characteristics are increasingly sensitive to the interactions among adjacent devices. Once all of those criteria are defined, then you are ready to set up the parasitic extraction tool.

But wait, there’s more! As with any engineering problem, there is the standard tradeoff between performance and accuracy. How accurate do your results need to be, and how long are you willing to wait to attain that level of accuracy? What CPU resources are you able to utilize? What frequency are you running at, and do you need to consider all RCLK parasitics or a subset? This accuracy/performance tradeoff applies to downstream simulation as well. A very accurate simulation may require a very detailed netlist. As the detail and complexity of the netlist increases, so will turnaround time (TAT) of the subsequent simulation. Therefore, understanding netlist size and what level of parasitic reduction to apply is critical.

Does your head hurt yet? Does this decision matrix seem a bit daunting?

As you can imagine, the industry has evolved to the point where we have different extraction tools, engines, flows, and sub-flows to address the specialized solutions for both extraction and simulation. The problem is that having so many specialized tools incurs designer overhead (aka headache): higher learning curve costs, more effort to set up tools for multiple scenarios, and various data and use model mismatches.

What extraction users need is a very flexible and intelligent extraction environment that can adapt to all of their requirements with minimum effort. While there may be different models, engines, and data formats “under the covers,” users would prefer to access these capabilities and options through a uniform, parameterized interface, with the ability to easily adjust tradeoffs (such as speed and accuracy) to give them the best overall solution for their immediate needs. Such an environment should not require users to duplicate setup work, such as creating multiple rule decks when switching from one design style or from one node to another. For example, designers might want to do a “quick and dirty” extraction run to check block interconnects, then later refine accuracy on specific critical nets. . Ideally, this would be accomplished without extra setup time or redefining inputs and outputs.

Imagine a set of golf clubs—that’s how extraction should perform. Good golfers tell me they swing each club the same way and let the club do the work (this doesn’t work for me, but that’s what I’m told). In golf, the golfer considers several variables, such as desired height, desired distance, ball position, etc. From there, a club selection is made to meet those requirements. Every club has the same user interface, so the golfer does not have to learn new techniques for each club, but simply employs the same tried and true methods to be successful (If you don’t believe me, it does work well on TV). That’s the use model we should strive for in parasitic extraction, where the user considers the desired outcome first, then selects the best engine or mode of extraction to match that outcome. It should not require learning several new tools.

Click here for more on parasitic extraction.

About the Author
Carey Robertson does a hit a golf ball from time to time. When he is not out losing golf balls, he is the Director of Product Marketing for Calibre’s Circuit Verification product line (LVS, PERC, and Parasitic Extraction products). He has been with Mentor Graphics for eleven years in various product and technical marketing roles. Prior to Mentor Graphics, Carey was a design engineer at Digital Equipment Corp., working on microprocessor development. Carey holds a BS from Stanford University and an MS from UC Berkeley.