Parasitics can impact a circuit in many ways. This page is a list of pointers to get you going in the right direction.
A netlist with parasitic elements built into device models is said to use Device Wrappers. An example would be a diode on the substrate pin of a MOSFET, or series resistor on MOSFET source or drain. If these parasitic elements are contained inside a device wrapper .subckt, the wrapper will be simplified as the intended primitive device, when the netlist is loaded. Cases like this can be complicated, with additional ports, re-ordered ports, and multiple nested layers. For more information, please see the Users Manual sections on loading netlists.
A netlist that includes ideal capacitors on nets is said to use Load Model Estimation. These capacitance values would normally represent the expected external loads that lie outside the scope of the given netlist. The capacitance values may be included or excluded, selectively, while running Fanout checks. For more information, please see the Users Manual sections on Fanout ERC.
Note that all MOSFETs have inherent capacitance values such as C.gate, C.edge. These values are always used in Fanout and Loading calculations. For more information, please see the Users Manual sections on setup of device parameters, and the white papers available on the same topics.
A netlist with inserted ideal capacitors and possibly ideal resistors in series with nets is said to be an Extracted Parasitic Netlist. These netlists can exist as
- Lumped C only values.
- Cross coupled C between nets.
- Cross coupled C and series R with split nets.
Examples supported are SPF, SPEF, DSPF. Please note that it is very important to choose the right way to load and use these netlists, as described further down on this page. For more information, please see the Users Manual section on loading netlists.
Fanout calculations do include parasitics, but we have to stay clear on what, exactly, is meant by the terms Fanout and Parasitic. Otherwise, the expectations of Fanout become blurry...
Textbook Fanout is based on C.in and C.out of MOSFETs. The Insight Analyzer supports these considerations inherently. Further, C load values on nets also fit well into these calculations because it's apples-to-apples. That means lumped C values to ground are considered.
Fanout calculations also consider cross coupled C matrix between nets, but must do this as a lumped value in order to remain true to the term Fanout.
Fanout calculations do not consider R.ds.on or series resistance. To do so would be to deviate from the term Fanout, and any numbers would very quickly stop making sense.
For more information, please see the Users Manual sections on Fanout ERC and fanout calculation script commands, and white papers covering calculations.
Delay calculations pick up where Fanout leaves off, when series resistance is encountered. The Path Delays ERC module gives fanout values, but in addition, also estimates delay.
You have the choice to run either Fanout ERC, or Path Delays ERC. If your circuit includes series resistance, you probably want to be running Path Delays ERC.
For more information, please see the Users Manual section on Path Delays ERC.
When using the Insight Analyzer, you will always begin with loading a netlist. In most cases, this will be the ideal netlist, without parasitics.
Ideal Netlist with Device Wrappers
You may decide that the one netlist you load has Parasitic Device Wrappers. In this scenario, the wrappers will be simplified to become basic primitives. You may prevent the simplification of wrappers, but the best is to allow simplification because that supports subgraph recognition and just makes the whole workflow more straightforward.
Ideal Netlist plus Parasitics
In this scenario, you would load first the ideal netlist, and then overlay an extracted netlist for the annotation of parasitic values. The benefit of doing this is to add the parasitic values but still have the ideal circuit for correspondence with any reported violations. For including parasitics in Fanout ERC and Path Delays ERC, this should be the most common choice.
The parasitic netlist in this scenario must have C values, may have R values, and does not need an INSTANCES section.
Extracted Netlist Only
In this scenario, you have only an extracted netlist; You do not load an ideal netlist. This is not recommended, for it will probably slow things down due to the lack of hierarchy.
In cases like this, the Insight Analyzer will detect that your only netlist is an extracted netlist, and will re-create the hierarchy as a way to chunk down the problem solving. It's generally not a good idea to rely on this however, because original cell names are not available in the extracted netlist, and circuit functions are not always apparent due to hard-grounded inputs, etc.
Such netlist must have an INSTANCES section, which is not always present in an extracted netlist. The Insight Analyzer combines the instances and parasitic sections from the netlist in this scenario, to arrive at the final circuit.
For more information on using the extracted netlist by itself, please see the Users Manual section on loading netlists, and in particular, the file located in config/FileTypeMap.config.