Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
config:netlist [2022/05/19 16:00] – rajitconfig:netlist [2025/05/24 13:27] (current) – [Device generation and parameters] rajit
Line 6: Line 6:
  
 <code> <code>
-real lambda 0.03e-6+real lambda 0.3e-6
 </code> </code>
-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. This is normally set to F/2, where F is the feature size. In this example, we are assuming a 0.6 micron feature size. 
- +===== Device generation and parameters =====
-===== Transistor generation and parameters =====+
  
 <code> <code>
Line 92: Line 91:
 </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. Since these capacitance values aren't explicit capacitors in the layout, it is convenient to be able to emit a netlist that omits these capacitance values entirely. To do so, the ''ignore_loadcap'' parameter can be set. 
 +<code> 
 +int ignore_loadcap 0 
 +</code> 
 +Setting it to one will omit the capacitance devices. This option is set by ''prs2net'' when the command-line option ''-l'' is used.
  
 +<code>
 +real unit_dev 1e-15
 +</code>
 +This value is used to specify the size of the unit device parameter used for explicit devices specified in the ''prs'' sublanguage. If unspecified, it is taken to be 10<sup>-15</sup>. This is normally used for capacitors.
 +
 +<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 105: Line 118:
 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.
  
-===== Transistor device names =====+<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 devices =====
  
  
Line 117: Line 144:
 string nfet_hvt  "nhvt" string nfet_hvt  "nhvt"
 </code> </code>
-The strings above are used for the device names for each transistor type. Note that the device type names are part of the technology-independent ACT configuration.+The strings above are used for the device names for each transistor type. Note that the device type names are part of the [[config:start#devices|technology-independent ACT configuration]]. 
 + 
 +There are a number of parameters that are passed to transistor models that determine the width and length of the device, among other parameters. These parameters have default values that are commonly used for most technologies, but they can be modified using configuration file options. The configuration file options to do so are shown below; in the example, the parameters are set to the default value. 
 + 
 +<code> 
 +begin fet_params 
 +   string width "W" 
 +   string length "L" 
 +   string fin "NFIN" 
 +   string area_src "AS" 
 +   string area_drain "AD" 
 +   string perim_src "PS" 
 +   string perim_drain "PD" 
 +end 
 +</code> 
 +For example, the width would be specified using ''W=value'' given the parameters above; changing the ''width'' string will change the parameter name passed to the device model. 
 +  * ''width'' : width of transistor 
 +  * ''length'' : length of transistor 
 +  * ''fin'' : number of fins (used for FinFET nodes) 
 +  * ''area_src'' : area of the source 
 +  * ''perim_src'' : perimeter of source 
 +  * ''area_drain'' : area of drain 
 +  * ''perim_drain'' : perimeter of drain
  
 If the FET devices being used are floating-body SOI devices, then their spice representation is not of type "M" (model), but of type "X" (subcircuit). The device has the usual source, gate, drain terminals, but the fourth terminal is no longer bulk, but instead the substrate. All substrate terminals are grounded (as opposed to bulk terminals that are connected to the appropriate supply), so this requires a modified netlist. To have the "svt" device correspond to an SOI-type, use the following: If the FET devices being used are floating-body SOI devices, then their spice representation is not of type "M" (model), but of type "X" (subcircuit). The device has the usual source, gate, drain terminals, but the fourth terminal is no longer bulk, but instead the substrate. All substrate terminals are grounded (as opposed to bulk terminals that are connected to the appropriate supply), so this requires a modified netlist. To have the "svt" device correspond to an SOI-type, use the following:
Line 125: Line 174:
 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 ''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". +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 148: Line 198:
 </code> </code>
 The default is blank, but it can be changed as necessary. The default is blank, but it can be changed as necessary.
 +
 +===== Other Devices =====
 +
 +Since ''prs'' bodies can have other two-terminal devices, the string to be used in the SPICE output for the device 
 +can be specified as:
 +<code>
 +string_table device "C"
 +</code>
 +This says the first device in the ''prs_device'' table is a capacitor (since ''C'' is the device string used by SPICE for capacitors).
 + 
  
 ===== Interactions with the layout editor Magic ===== ===== Interactions with the layout editor Magic =====
Line 158: Line 218:
 </code> </code>
 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]]. 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 198: Line 253:
 </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 253: Line 314:
 </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 264: Line 330:
 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"
 +</code>
 +This parameter is used to set the search path for ''.rect'' files (when ''rect_import'' is set to one).
 +
 +The layout generation tools create fresh rect files. This happens in two scenarios: (a) If rect files are not found, or the ''rect_import'' parameter is set to zero; or (b) When rect files are read in, their LEF bounding box is re-computed and the rectangles are shifted so as to be properly aligned. When saving the final rect files, it can be helpful to keep these two types of outputs separate.  The default output directory for rect files is the current directory.
 +<code>
 +string rect_outdir "outputrectdir"
 +</code>
 +If this parameter is set, then the output directories for (a) and (b) outputs are both set to the specified directory name.
 +<code>
 +string rect_outinitdir "out_init"
 +</code>
 +If this parameter is set, then //initial// rect outputs (i.e. those generated in case (a) above)  are saved to this directory. When both parameters are specified, outputs generated in case (a) are written to ''rect_outinitdir'', while those in case (b) are written to ''rect_outdir''.
 +
 +<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>
config/netlist.1652976016.txt.gz · Last modified: 2022/05/19 16:00 by rajit
Except where otherwise noted, content on this wiki is licensed under the following license: GNU Free Documentation License 1.3


  • Show page
  • Old revisions
  • Backlinks
  • Recent Changes
  • Media Manager
  • Sitemap