Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
config:netlist [2022/05/19 08:51]
rajit [Transistor device names]
config:netlist [2023/05/16 10:14] (current)
rajit [Miscellaneous]
Line 10: Line 10:
 This is the scale factor used to convert to metric units from the dimensionless transistor sizes. This is the scale factor used to convert to metric units from the dimensionless transistor sizes.
  
-===== Transistor generation and parameters =====+===== Device generation and parameters =====
  
 <code> <code>
Line 45: Line 45:
 int fold_nfet_width 0 int fold_nfet_width 0
 </code> </code>
-This is used as a width threshold to trigger folding of transistors (0 = no folding). Extra fingers are automatically generated with this option. The parameter specifies a folding threshold F. Transistors with width larger than F are converted into multiple fingers.+This is used as a width threshold to trigger folding of transistors (0 = no auto folding). Extra fingers are automatically generated with this option. The parameter specifies a folding threshold F. Transistors with width larger than F are converted into multiple fingers.
 If a transistor has width W that is larger than the folding threshold F, then (W div F) transistors of width F are generated. If (W mod F) is smaller than the minimum width, then the extra width is added to the last of the (W div F) transistors; otherwise a transistor of size (W mod F) is generated as well. If a transistor has width W that is larger than the folding threshold F, then (W div F) transistors of width F are generated. If (W mod F) is smaller than the minimum width, then the extra width is added to the last of the (W div F) transistors; otherwise a transistor of size (W mod F) is generated as well.
  
Line 53: Line 53:
 int discrete_length 2 int discrete_length 2
 </code> </code>
-This specifies that all transistor lengths should be 2 lambda. In the scenario when the netlist requires a longer transistor (e.g. weak feedback in a staticizer), ''netgen'' will automatically break up the long transistor into a series chain of transistors that have the equivalent effective length (rounding up in case the required width is not a multiple of ''discrete_length'').+This specifies that all transistor lengths should be 2 lambda. In the scenario when the netlist requires a longer transistor (e.g. weak feedback in a staticizer), ''prs2net'' will automatically break up the long transistor into a series chain of transistors that have the equivalent effective length (rounding up in case the required width is not a multiple of ''discrete_length'').
  
 A technology may have only some length ranges that are valid for transistors. In this case, the ''fet_length_ranges'' parameter can be set. A technology may have only some length ranges that are valid for transistors. In this case, the ''fet_length_ranges'' parameter can be set.
Line 92: Line 92:
 </code> </code>
 If specified, this parameter is used to increase the length of minimum length transistors in the technology when the sizing directives or production rule body turn on this feature. This is used to reduce leakage in certain technologies where the minimum length devices are extremely leaky, and need to be drawn longer in some cases. If specified, this parameter is used to increase the length of minimum length transistors in the technology when the sizing directives or production rule body turn on this feature. This is used to reduce leakage in certain technologies where the minimum length devices are extremely leaky, and need to be drawn longer in some cases.
 +
  
 <code> <code>
-real delay 500e-12+real default_load_cap 0
 </code> </code>
-This parameter is used to convert delay units specified in timing constraints to actual time (in seconds).+This value (in fF) is added to a node whenever it appears on the RHS of a production rule (per subcircuit). This can be used to "pessimize" your spice simulations to account for wiring capacitance. This can be overridden with the "loadcap=value" attribute in the production rule itself.
  
 +<code>
 +real unit_cap 1e-15
 +</code>
 +This value is used to specify the size of the unit capacitor used for explicit capacitors specified in the ''prs'' sublanguage. If unspecified, it is taken to be 1fF.
 +
 +<code>
 +real delay 500e-12
 +</code>
 +This parameter is used to convert delay units specified in timing constraints to actual time (in seconds). If unspecified, this is taken to be ''lambda'' divided by thousand, which is the standard rule of thumb for FO4 delay (assuming that ''lambda'' is half the feature size).
  
 <code> <code>
Line 104: Line 114:
 In some process technologies, the foundry-provided model files include a global scale factor that applies to all width/length parameters. As a result, the netlist output generated for SPICE simulation have to be  In some process technologies, the foundry-provided model files include a global scale factor that applies to all width/length parameters. As a result, the netlist output generated for SPICE simulation have to be 
 scaled to counteract the global scale factor. ''output_scale_factor'' is used to scale the output of all width/length/area/perimeter values; the width and length are multiplied by this scale factor only when printing the SPICE output. scaled to counteract the global scale factor. ''output_scale_factor'' is used to scale the output of all width/length/area/perimeter values; the width and length are multiplied by this scale factor only when printing the SPICE output.
 +
 +<code>
 +int emit_parasitics 0
 +</code>
 +This option is used to generate parasitic source/drain area and perimeter values for transistors. For netlists suitable for running LVS checks, this setting should be off (0). Depending on how parasitics are extracted in a particular process technology (e.g. are source/drain caps part of the model, or are they explicitly extracted), this parameter should be set to 1 (turn on area/perimeter values) or 0.
 +
 +
 +
 +The netlist pass can be used to generate a [[https://csl.yale.edu/~rajit/ps/shared_stat_2020.pdf|shared staticizer]] structure. In this mode, one can specify that minimum and maximum number of staticizers that are permitted for a single shared weak power supply terminal.
 +<code>
 +int_table weak_sharing 2 8
 +</code>
 +This specifies that the sharing count for a weak supply is between two and eight staticizers.
 +
  
 ===== Transistor device names ===== ===== Transistor device names =====
Line 125: Line 149:
 string pfet_svt "soi:pfet" string pfet_svt "soi:pfet"
 </code> </code>
-Here the fet model names are "nfet" and "pfet", and the prefix "soi:" informs netgen that it should always tie the fourth terminal to ground. The ''use_subckt_models'' configuration file parameter is used to use "X" instead of "M"+Here the fet model names are "nfet" and "pfet", and the prefix "soi:" informs ''prs2net'' that it should always tie the fourth terminal to ground. 
  
 +The ''use_subckt_models'' configuration file parameter is used to use "X" instead of "M"
 <code> <code>
 int use_subckt_models 0 int use_subckt_models 0
Line 141: Line 166:
 int fin_width 4 int fin_width 4
 </code> </code>
-This specifies that the netlist is for a FinFET technology, and a individual fin is equivalent to 4 units of width. All widths will be snapped to an integer multiple of the ''fin_width'', and the transistor output will include ''NFIN=v'' that specifies the number of fins. The default is to assume a non-FinFET technology. If the value specified is zero or negative, ACT assumes a non-FinFET technology.+This specifies that the netlist is for a FinFET technology, and a individual fin is equivalent to 4 units of width. All widths will be snapped to an integer multiple of the ''fin_width'', and the transistor output will include ''NFIN=v'' that specifies the number of fins. The default is to assume a non-FinFET technology. If the value specified is zero or negative, ACT assumes a non-FinFET technology. When a FinFET technology is specified, the netlist generation process will round up all widths to be an integer multiple of ''fin_width.'' A warning will be generated if the standard and minimum widths are not an integer multiple of the ''fin_width'' since this indicates a configuration file inconsistency.
  
 Some DRC/LVS decks require some additional parameters for transistors in the spice file. To support this, the following string is appended to any transistor line in the spice file. Some DRC/LVS decks require some additional parameters for transistors in the spice file. To support this, the following string is appended to any transistor line in the spice file.
Line 148: Line 173:
 </code> </code>
 The default is blank, but it can be changed as necessary. The default is blank, but it can be changed as necessary.
 +
 +===== Interactions with the layout editor Magic =====
 +
 +We typically use [[http://opencircuitdesign.com/magic/index.html|magic]] as our layout editor. To obtain device and connectivity information from physical layout, ''magic'' includes an extraction module that emits ''.ext'' format files (details are in the magic documentation). These files contain a hierarchical representation of the design which includes connectivity information and device information extracted from the physical geometry. The ACT core tools include a translator from ''.ext'' to a standard SPICE format netlist. To do this correctly, we have to map magic layers to device types.
  
 <code> <code>
Line 153: Line 182:
 string_table ext_map "nfet_svt" "pfet_svt" string_table ext_map "nfet_svt" "pfet_svt"
 </code> </code>
-These tables are used for interpreting ''magic'' extract files. The first line maps the extract file device types to nfet or pfet (for n-type and p-type transistors). The order of this table should map the numbering of the transistors used by the ''magic'' extractor. Finally, the device names are translated into the appropriate device for mapping to a SPICE device name using the ''ext_map'' table.+The first line maps the extract file device types to nfet or pfet (for n-type and p-type transistors). The order of this table should match the numbering of the transistors used by the ''magic'' extractor. Finally, the device names are translated into the appropriate abstract ACT device name using the ''ext_map'' table. The actual SPICE device names are generated using the defined mapping between ACT device names and  [[config:netlist#Transistor device names|technology-dependent transistor device names]]. 
 ===== Miscellaneous ===== ===== Miscellaneous =====
- 
- 
-<code> 
-real default_load_cap 0 
-</code> 
-This value (in fF) is added to a node whenever it appears on the RHS of a production rule (per subcircuit). This can be used to "pessimize" your spice simulations to account for wiring capacitance. This can be overridden with the "loadcap=value" attribute in the production rule itself. 
  
 <code> <code>
Line 194: Line 218:
 </code> </code>
 When production rules are automatically mapped to cells by the cell mapping pass, cell names are generated based on the production rule expressions for the pull-up and pull-down network. These names can get very long, and be difficult to read. This table is used to translate a generated name into something that is more understandable. The table should have an even number of entries that alternate between the generated name and the mapped name. When production rules are automatically mapped to cells by the cell mapping pass, cell names are generated based on the production rule expressions for the pull-up and pull-down network. These names can get very long, and be difficult to read. This table is used to translate a generated name into something that is more understandable. The table should have an even number of entries that alternate between the generated name and the mapped name.
 +
 +<code> 
 +string cell_inport "in"
 +string cell_outport "out"
 +</code>
 +When cells are generated, their ports are called ''in'' and ''out''. This can be changed to any port name using these configuration file options.
 ====== Sizing configuration options ====== ====== Sizing configuration options ======
  
Line 214: Line 244:
 If this is turned on, this permits the use of long channel devices when applying the sizing body. This might be needed if the width/length ratio dictates that the width of the device should be smaller than the minimum width; in this case, the specified drive strength can be achieved by using a long channel transistor. If this is turned on, this permits the use of long channel devices when applying the sizing body. This might be needed if the width/length ratio dictates that the width of the device should be smaller than the minimum width; in this case, the specified drive strength can be achieved by using a long channel transistor.
  
- +===== Sizing limits =====
-====== Sizing limits ======+
  
 Internally, act maintains width and lengths of transistors as integer-valued variables that are a multiple of the manufacturing grid. Hence, if the ratio of lambda/manufacturing_grid is very large, then normal widths might overflow (based on the maximum integer on your system) and you might get unexpected errors. This should not be an issue in general; if the manufacturing grid is 1nm, then the maximum width and length cannot be more than 2 meters, a reasonable assumption at present. Internally, act maintains width and lengths of transistors as integer-valued variables that are a multiple of the manufacturing grid. Hence, if the ratio of lambda/manufacturing_grid is very large, then normal widths might overflow (based on the maximum integer on your system) and you might get unexpected errors. This should not be an issue in general; if the manufacturing grid is 1nm, then the maximum width and length cannot be more than 2 meters, a reasonable assumption at present.
Line 250: Line 279:
 </code> </code>
 This specifies which metal layer is horizontal versus vertical. If this is 1, then odd metal layers are horizontal (metal1, metal3, etc); otherwise even metal layers are horizontal (metal2, metal4, ...) This specifies which metal layer is horizontal versus vertical. If this is 1, then odd metal layers are horizontal (metal1, metal3, etc); otherwise even metal layers are horizontal (metal2, metal4, ...)
 +
 +<code>
 +int_table routing_metal 2 5
 +</code>
 +This specifies the metal layers to be used for routing, and is used to control this in the technology LEF that is generated from the layout configuration file. (Metal layers are numbered 1, 2, etc.)
  
 <code> <code>
Line 261: Line 295:
 If this is set to 1, and local ''.rect'' files are  found, then those files are read in to define cell geometry rather than the cell geometry being  generated. If this is set to 1, and local ''.rect'' files are  found, then those files are read in to define cell geometry rather than the cell geometry being  generated.
  
 +<code>
 +string rect_inpath "paths:tosearch/for/rect/files"
 +string rect_outdir "outputrectdir"
 +</code>
 +These two parameters are used to control the search path for ''.rect'' files (when ''rect_import'' is set to one) and the directory where the final output ''.rect'' files are saved, if ''.rect'' files are generated.
 +
 +<code>
 +int rect_wells 0
 +</code>
 +This flag is used to generate explicit wells in the ''.rect'' file output. This is useful for debugging, or for checking well connectivity/plugs in the magic VLSI layout editor.
 +
 +<code>
 +begin extra_tracks
 +  int top 0
 +  int bot 0
 +  int left 0
 +  int right 0
 +end
 +</code>
 +This parameter can be used to pad the generated cells on the top/bottom/left/right by some number of routing tracks. This can be useful for preliminary layout estimates where only a partially completed cell is available. Other uses include increasing the area used by a design to alleviate routing congestion.
  
 <code> <code>