- 1 What are DRC, extraction and LVS?
- 2 What do all these extraction switches mean?
- 3 My layout has a filter capacitor - why didn't it extract?
- 4 I extracted my layout - why aren't there any parasitic capacitors?
- 5 I extracted my layout - why aren't there any resistors?
- 6 Ok, I did all that and still no resistors!
- 7 I can extract resistors, but the calculated value is always 1kOhm.
- 8 I know my layout and schematic are equivalent. So why does LVS say the netlists don't match?
- 9 When I run LVS, it fails, and the netlists contain lines like: No element format property found for element /M0. What's going on?
- 10 When I run LVS, it fails and I get the following error in the output log: *Error* Could not determine the node name for terminal 'progn(bn)'.... What's going on?
- 11 LVS passes, but I know some of my transistor sizes are mismatched. Why did it pass?
- 12 DRC/extraction sometimes fails with strange error messages, especially on big layouts. How can I fix this?
What are DRC, extraction and LVS?
- DRC stands for Design Rule Check. IC foundries have sets of design rules that ensure that designs can be manufactured reliably and repeatably. DRC checks to see if your layout violates any of these rules.
- Extraction gathers device (e.g. transistor, capacitor) and connectivity information from your layout; this information can be used to build a netlist.
- LVS stands for Layout Versus Schematic; it verifies that your layout and schematic are topologically equivalent, i.e. the netlists match.
What do all these extraction switches mean?
My layout has a filter capacitor - why didn't it extract?
The extractor should automatically extract a "designed" capacitor, as long as it meets one of the following criteria:
- it uses one of the process-optional "high-capacitance" layer
pairs, i.e. poly/polycap, metal6/metalcap, metal5/metalcap, poly/cwell or poly/elec
- it's marked with the cap_id marker layer (i.e. a
rectangle on the cap_id layer completely overlaps the rectangles that make up the capacitor)
If your capacitor meets at least one of the above criteria, and the extractor isn't extracting it properly, please send us a bug report.
I extracted my layout - why aren't there any parasitic capacitors?
There are three quick things to check:
- Make sure the Extract_parasitic_caps switch in the Extract form is on. (Click the "Set Switches" button, then click on Extract_parasitic_caps.)
- Check the value of NCSU_parasiticCapIgnoreThreshold (the default is 2fF). Capacitors below this value are filtered out. For example, to set this value to 10fF, type NCSU_parasiticCapIgnoreThreshold = 10e-15 in the CIW. (The default value for this variable is set in skill/globalData.il.)
- Check the "Parasitic Capacitances" section at the bottom of the file techfile/layerDefinitions.tf to make sure that parasitic values are defined for the process in which you're working.
I extracted my layout - why aren't there any resistors?
Check these things:
- Resistor extraction was introduced in CDK 0.99.6. Make sure your CDK version (specifically, the Diva rules files) is sufficiently up-to-date.
- Resistor extraction only works for poly, elec (poly2) and nwell resistors.
Also, keep in mind that the CDK does not (yet) currently support extraction of parasitic resistors.
Ok, I did all that and still no resistors!
Using the CDK extract rules, Diva will extract only the following structures as resistors:
- nwell overlapped by res_id
- poly overlapped by res_id
- poly overlapped by sblock
- elec overlapped by res_id
- elec overlapped by highres
Generically, your resistor should look something like this:
This layout shows a poly/sblock resistor. Although this example shows a single straight length of poly inside the sblock rectangle, it's OK if there are bends (i.e. serpentine resistors are fine) - the extractor applies a correction factor to the resistance value at the corners of the bends. However, note that the contacts must be outside the res_id/sblock/highres rectangle.
For the purposes of calculating resistance, only the poly/elec/nwell inside the res_id/sblock/highres rectangle is considered. For example, in the above figure, the resistance is calculated using a length of 4.2 microns and a width of 1.2 microns (i.e., 3.5 squares).
FYI, sblock and highres are "mask" layers that get turned into real physical masks. The res_id layer, on the other hand, is simply a "recognition" layer that tells Diva that you intend the poly/elec/nwell underneath it to be a resistor.
I can extract resistors, but the calculated value is always 1kOhm.
If you're working in a design library that was created before 0.99.6 was installed, the layer property sheetResistance (defined in techfile/layerDefinitions.tf), which is used to calculate the resistor value, almost certainly doesn't exist. See the doc covering resistor extraction for instructions on how to add the required properties to your technology library.
I know my layout and schematic are equivalent. So why does LVS say the netlists don't match?
In the LVS form, make sure the rules file and rules library are filled in with the name divaLVS.rul and the name of your technology library, respectively. (This should be handled automatically, but check just in case.) Otherwise Diva might not be applying all the appropriate LVS rules it should be. (Note that if you've modified the LVS rules using the "NCSU->Modify LVS Rules..." form, the LVS form will have your design library name in the rules library field. This is OK.)
When I run LVS, it fails, and the netlists contain lines like: No element format property found for element /M0. What's going on?
You probably need to set the shell environment variable CDS_Netlisting_Mode to Analog. For csh or tcsh, type setenv CDS_Netlisting_Mode Analog in the shell window before starting Cadence.
When I run LVS, it fails and I get the following error in the output log: *Error* Could not determine the node name for terminal 'progn(bn)'.... What's going on?
You usually see this in a schematic which contains three-terminal MOS symbols ([np]mos from NCSU_Analog_Parts) but has neither any digital gates (from NCSU_Digital_Parts) nor vdd!/gnd! nets. By default, the three terminal MOS devices have their bulk nodes connected to "vdd!" (pmos) or "gnd!" (nmos), so if the netlister can't find a net by that name it's going to complain. The digital gates already include vdd!/gnd! nets, which is why you don't see this error in a schematic which has any gate instances.
The simplest solution is to instantiate vdd! and gnd! symbols (from the Supply_Nets category of NCSU_Analog_Parts) in your schematic. You don't have to connect them to anything; the point is just to make nets with the required names.
Alternatively, you can change the bulk node connection directly. Edit the transistor properties (select the transistor and hit q) and simply type the desired net name in the "Bulk node connection" field.
LVS passes, but I know some of my transistor sizes are mismatched. Why did it pass?
Probably because you didn't tell it to check for transistor size mismatches. Select the "NCSU->Modify LVS Rules..." menu entry and check the "Compare FET parameters" check box if you want LVS to warn you of size mismatches. Take a look at all the LVS options you can set.
DRC/extraction sometimes fails with strange error messages, especially on big layouts. How can I fix this?
Diva creates lots of temporary files (by default in the current directory) and if it runs out of space it can fail. You can tell Diva where to store these files by setting the environment variable DRCTEMPDIR before starting Cadence. The (csh) syntax is setenv DRCTEMPDIR "dir1 [dir2] [dir3] [...]". The temp files are then stored in these directories.
--Slipa 12:06, 27 February 2006 (EST)