Five Rules For Correlating Rule-based And Field Solver Parasitic Extraction Results

There comes a time at every foundry and IC design company when it becomes necessary to run a correlation between a rule-based parasitic extraction (PEX) table and a field solver solution. And when that time arrives, there are a few (five, to be precise) details that will help ensure the correlation produces accurate results. But before we get to those, let’s do a quick refresh on PEX techniques.

Parasitic extraction
PEX is the process of identifying unintended (parasitic) resistance and capacitance that occurs in a design. The PEX flow is an important part of circuit verification, because even though they’re not a part of the designed circuitry, parasitic effects have very real impacts on circuit performance.

Obviously, actual silicon measurements are the ideal reference for determining parasitic circuits, since the physical layout creates the conditions that allow parasitic circuits to form. Foundries often use fabricated integrated circuits (ICs) that include many shapes and configurations, while design houses may actually fabricate a special test structures die just for this purpose. However, physical measurements are not always easy to come by, due either to a lack of measurement data, or because the structures under test are difficult to measure. Which is why many foundries and design companies use the next best thing—field solver calculations.

Field solver PEX
Field solver-based PEX tools provide a precise and complete mathematical solution for PEX by solving Maxwell’s equations. Because field solvers can handle complicated three-dimensional geometries, they generate highly-accurate extracted netlists (Figure 1). Field solvers are not restricted to a pre-defined model of the parasitic effects that may or may not arise in any given design, and they don’t require any calibration, because they work directly with the design layout.

Figure 1. Field solver PEX flow.

If field solvers are so accurate, why not use them all the time? Field solver PEX is used sparingly in real designs because it requires significant runtimes. In addition, field solvers can be difficult to set up for accurate construction of a three-dimensional description of the design layout containing all the physical parameters for each layer. While some electronic design automation (EDA) tools enable designers to run a field solver using the two-dimensional description of the design layout in the standard GDSII format, most design companies use rule-based PEX for the majority of their extraction needs because it is faster and easier.

Rule-based PEX
Rule-based parasitic extraction (PEX) engines use tables or equations that are based on a pre-defined set of structures. Development of a rule-based PEX flow begins with a process specification that describes what the set of layers (stack) in a given process technology looks like. For example, a stack specification starts by defining the height and properties of metal1, then the height and properties for metal2, and so on. The syntax format used for this stack specification file differs from one EDA tool supplier to another, but they all contain the necessary geometrical and electrical parameters for each layer in the stack.

A combination of these layers with specific widths and spaces is then used to construct a set of pre-defined structures selected by EDA companies. This pre-defined set of structures is usually chosen by modeling teams with extensive experience in both design and modeling techniques, and represents the structures they believe will be used in actual designs. The process stack is then used to generate model equations in the form of extraction rules that can be understood by rule-based PEX tools (Figure 2).

Figure 2. Rule-based PEX calibration and usage flow.

Calibrating rule-based PEX against field solver PEX
Both circuit designers and foundry modeling engineers encounter situations where they need to compare and validate their rule-based PEX results against a field solver solution to ensure the results are accurate in production. For example, during the qualification of a foundry rule deck, foundry modeling engineers use correlation to ensure the extraction rule decks they deliver will work correctly with EDA PEX tools for a given technology node. Design companies often run a PEX correlation in new technologies before creating real designs, by creating simple designs (such as a voltage-controlled oscillator or ring oscillator), then validating the extracted netlist obtained using rule-based PEX against the extracted netlist created by a field solver.

To ensure the results are being fairly evaluated, engineers must ensure an “apples to apples” comparison.  However, there are a number of common issues that may skew the results of the comparison, and they don’t have anything to do with the accuracy of the rule-based extraction engine. In general, to guarantee the correlation is equivalent, there are five adjustments or modifications engineers may need to make to ensure that the setup conditions of both engines are properly aligned.

1. DRC compliance
The design must be compliant with all design rule checks (DRC). Rule-based PEX tools rely on equations that are based upon some assumptions, giving them a limited range of validity. One of these fundamental assumptions is that the design is DRC-clean. For instance, extracting a design that contains dimensions smaller than the technology minimum features creates inaccuracies in the rule-based engine results. Although this same limitation does not apply to field solvers, because they solve Maxwell’s equations for whatever shapes are defined in the design, having a DRC-clean design during correlation is essential to obtain an accurate comparison of results.

2. Capacitance ignore
Some capacitance components are already accounted for in the SPICE models during simulation, and should be ignored during extraction to avoid double-counting. To avoid extracting these parasitics, most rule-based PEX tools can be set up to “ignore” specific parasitic components. Because the rule-based engine uses a separate equation for different capacitance components (like fringe, plate, near body intrinsic/coupling capacitance components), designating a capacitance ignore allows you to easily drop one of those components while keeping the others (Figure 3).

Figure 3: Typical capacitance components that can be removed individually from rule-based extraction using capacitance ignores.

While some field solvers can account for some of these capacitance ignores, ignoring a specific capacitance effect in a field solver is not as straightforward, because it calculates the capacitance as a lumped effect that can’t be easily broken down into such components.

To accurately correlate results, designers must either choose to remove all capacitance ignores from the rule-based PEX, or use de-embedding techniques to manually remove those components from the field solver PEX results.

3. In-die variation
Foundries usually use in-die variation data for interconnects to model post-fabrication variations in the process parameters, such as metal width, thickness, and resistivity. These variations depend on stack layer, layer width, spacing, and density. Foundry-qualified rule decks for rule-based PEX engines take this variation into account. However, not all field solvers can account for this kind of variation, so you may need to turn off in-die variation and/or layout magnification options in your rule-based PEX tool to ensure accurate comparisons. Alternatively, you can ensure the field solver input shapes use the actual post-fabrication layout dimensions in place of the drawn dimensions (Figure 4).

Figure 4: In-die variation accounts for differences between the drawn width of a shape and the actual size of the shape as manufactured.

4. Port-to-port resistance
Most rule-based engines model interconnect resistance in a single dimension. This approach enables port-to-port resistance calculation even when the port is defined by specific (x, y) coordinates in the layout, without having to worry about a current-spreading effect around these specific (x, y) coordinates on the interconnect. However, resistance calculations in field solvers are very much affected by current spreading, so when performing field solver PEX, regular ports must be replaced by region-based ports that are considered as infinite sources of charges regularly distributed along the interconnect width (Figure 5).

Figure 5: Pin ports must be replaced by region ports in field solver PEX to ensure accurate comparisons of port-to-port resistance.

5. Multiple layers
Multiple layers in the same physical location can cause inconsistency between rule-based and field solver PEX results. Rule-based engines usually calculate capacitance and resistance using pre-defined equations, even when they correspond to the same physical layer. If multiple layers correspond to the same physical layer, and none of them are ignored, this can cause double counting for rule-based results. A field solver can natively identify such duplicate geometries and treat them as one shape. Because this inconsistency can be caused by an incorrect setup for the rule-based PEX, it is essential to check the rule-based setup to ensure this double counting is eliminated.

Summary
Correlating a rule-based PEX engine against field solver PEX results is an important and critical process. Foundries and EDA vendors must ensure that the PEX rule decks they deliver will provide accurate extraction results when used in verification flows. Design companies need to ensure that moving to a new process node or implementing a new design does not affect the accuracy of their rule-based PEX tool. When correlating your rule-based and field solver PEX results, it may take multiple iterations to ensure the two extraction flows are performing extraction in a compatible manner. However, this validation process is essential if you want an accurate comparison of results. By being aware of these five issues, engineers and designers can modify the setup and use of both PEX processes to ensure the results can be fairly and accurately compared.

For more information, read our whitepaper “Validating rule-based parasitic extraction against a field solver solution.”