| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| config:netlist [2024/03/31 17:40] – [Transistor device names] rajit | config:netlist [2025/08/01 22:40] (current) – [Staticizer/keeper sizing] rajit |
|---|
| |
| <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 ===== | ===== Device generation and parameters ===== |
| | |
| | Production rules and transistors specified in the [[language:langs:prs|prs sublanguage]] need to be fully specified in terms of width, length, and other parameters. These are generated using a combination of user specified values and the netlist configuration file. |
| | |
| | ==== Width and length for transistors ==== |
| |
| <code> | <code> |
| The ''std'' parameters are used as default widths and lengths for production rules that do not have any sizes specified. | The ''std'' parameters are used as default widths and lengths for production rules that do not have any sizes specified. |
| |
| <code> | <block 75%:0:#FFFFCC;black;1px dotted black;auto/10ptrounded>**Tip:** For digital logic, the standard length is usually the minimum permitted by the technology (2 lambda). The minimum width is often 3 or 4 lambda, but normally the default width used is slightly larger. We use 5 lambda for nfets here, and double that for pfets (to have their delays be roughly the same).</block> |
| int stat_p_width 5 | |
| int stat_p_length 2 | |
| | |
| int stat_n_width 4 | |
| int stat_n_length 2 | |
| </code> | |
| The ''stat'' parameters are used to size any automatically generated non-feedback inverter in a staticizer. These parameters are also used for all transistors in any combinational feedback gate. | |
| |
| <code> | <code> |
| 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. |
| |
| | <block 75%:0:#FFFFCC;black;1px dotted black;auto/10ptrounded>**Tip:** Multi-figure devices can directly be specified in the prs body, so normally this setting is not needed and auto-folding is turned off. This can be used to bound the maximum single transistor width generated by the netlist generator. This can be useful to bound the cell height of a cell library.</block> |
| |
| Technologies sometimes insist that transistor lengths are fixed values. To support this, the ''discrete_length'' parameter can be set. | Technologies sometimes insist that transistor lengths are fixed values. To support this, the ''discrete_length'' parameter can be set. |
| </code> | </code> |
| This specifies that fet lengths must be in the range ''[2,8]'' or ''[10,16]''. The ranges are assumed to be sorted by length value. Transistors that fit into a valid length range are permitted; otherwise, a series chain of transistors are generated whose cumulative length is equal to the length specified. The largest length that is smaller than the one specified is used to discretize the length. | This specifies that fet lengths must be in the range ''[2,8]'' or ''[10,16]''. The ranges are assumed to be sorted by length value. Transistors that fit into a valid length range are permitted; otherwise, a series chain of transistors are generated whose cumulative length is equal to the length specified. The largest length that is smaller than the one specified is used to discretize the length. |
| | |
| |
| <code> | <code> |
| |
| These are used to estimate the source/drain area and perimeter in the transistors. The ''fet_spacing_diffonly'' is used for the spacing between two fets in the same diffusion stack that have no intervening diffusion contact. The ''fet_spacing_diffcontact'' is used when there is an internal contact (not used right now). The ''fet_diff_overhang'' parameter is used when the node is a primary output (used to model the edge of the stack; this also not fully utilized right now when a stack gets cut into multiple stacks). | These are used to estimate the source/drain area and perimeter in the transistors. The ''fet_spacing_diffonly'' is used for the spacing between two fets in the same diffusion stack that have no intervening diffusion contact. The ''fet_spacing_diffcontact'' is used when there is an internal contact (not used right now). The ''fet_diff_overhang'' parameter is used when the node is a primary output (used to model the edge of the stack; this also not fully utilized right now when a stack gets cut into multiple stacks). |
| | |
| | <code> |
| | real leakage_adjust 10e-9 |
| | </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. |
| | |
| | <block 75%:0:#FFFFCC;black;1px dotted black;auto/10ptrounded>**Tip:** This is rarely needed, and so by default it should be zero. In some technologies, minimum length devices are so leaky that two-input C elements don't work! Making the minimum length larger by one manufacturing grid often resolves the problem.</block> |
| | ==== Staticizer/keeper sizing ==== |
| | |
| | When a production rule is state-holding, the netlist generator will automatically generate a staticizer/keeper be default. The transistor sizes for the generated staticizer are determined by the following parameters. |
| | |
| | <code> |
| | int stat_p_width 5 |
| | int stat_p_length 2 |
| | |
| | int stat_n_width 4 |
| | int stat_n_length 2 |
| | </code> |
| | The ''stat'' parameters are used to size any automatically generated non-feedback inverter in a staticizer. These parameters are also used for all transistors in any combinational feedback gate. |
| | |
| | <block 75%:0:#FFFFCC;black;1px dotted black;auto/10ptrounded>**Tip:** The transistors used for the non-weak parts of an automatically generated keeper/staticizer just need to work, so they can be smaller than the default width to save area. If you make them too small, then the design rules for contacts dominate and the layout gets messier.</block> |
| |
| <code> | <code> |
| |
| The weak feedback inverter is generated by using this strength ratio. The inverter is weakened by using a minimum size inverter with a long series transistor whose gate is connected to a constant value (essentially a series resistor). The default signal used is the local power supply for the prs block. (When a local power supply is not specified, the default signal names used are ''Vdd'' and ''GND''.) | The weak feedback inverter is generated by using this strength ratio. The inverter is weakened by using a minimum size inverter with a long series transistor whose gate is connected to a constant value (essentially a series resistor). The default signal used is the local power supply for the prs block. (When a local power supply is not specified, the default signal names used are ''Vdd'' and ''GND''.) |
| | |
| | <block 75%:0:#FFFFCC;black;1px dotted black;auto/10ptrounded>**Tip:** The ''p_n_ratio'' parameter can be determined from the relative speed of p-type and n-type devices in the technology via SPICE simulations. The ''weak_to_strong_ratio'' is a trade-off between switching speed, energy, and noise robustness and is often determined by using SPICE simulations and sweeping the ratio.</block> |
| |
| |
| When set to 1, this option makes combinational feedback the default staticizer/keeper style. | When set to 1, this option makes combinational feedback the default staticizer/keeper style. |
| |
| | 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> | <code> |
| real leakage_adjust 10e-9 | int_table weak_sharing 2 8 |
| </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. | This specifies that the sharing count for a weak supply is between two and eight staticizers. |
| |
| | ==== SPICE output ==== |
| |
| <code> | <code> |
| real default_load_cap 0 | real default_load_cap 0 |
| </code> | </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. | 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> | <code> |
| real unit_cap 1e-15 | int ignore_loadcap 0 |
| </code> | </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. | Setting it to one will omit the capacitance devices. This option is set by ''prs2net'' when the command-line option ''-l'' is used. |
| |
| <code> | <code> |
| real delay 500e-12 | real unit_dev 1e-15 |
| </code> | </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). | 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> | <code> |
| 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. |
| | |
| | <block 75%:0:#FFFFCC;black;1px dotted black;auto/10ptrounded>**Tip:** The default open-source Skywater 130 SPICE models include a scale factor of 1e-6 within the SPICE model files. This means that the netlist generator in ACT has to scale up the output dimensions by 1e6 to compensate.</block> |
| |
| <code> | <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. | 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. |
| |
| | ===== Transistor devices ===== |
| | |
| 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 ===== | |
| |
| |
| 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:generic#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: |
| This says the first device in the ''prs_device'' table is a capacitor (since ''C'' is the device string used by SPICE for capacitors). | This says the first device in the ''prs_device'' table is a capacitor (since ''C'' is the device string used by SPICE for capacitors). |
| | |
| | |
| | ===== Cell generation and mapping ===== |
| | |
| | Netlists can also be generated after mapping a design to cells. The following controls the cell naming conventions. |
| | |
| | <code> |
| | string cell_namespace "cell" |
| | </code> |
| | During production rule to cell mapping, the cells are all assumed to reside in a single namespace. This parameter specifies the name of this namespace. |
| | |
| | <code> |
| | string_table cell_namemap "0n_0" "inv" \ |
| | "0n1na_01o" "nor2" \ |
| | "0n1no_01a" "nand2" \ |
| | "0n1na_01a" "celem2" |
| | </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. |
| | |
| | <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. |
| |
| ===== Interactions with the layout editor Magic ===== | ===== Interactions with the layout editor Magic ===== |
| string_table ext_map "nfet_svt" "pfet_svt" | string_table ext_map "nfet_svt" "pfet_svt" |
| </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_devices|technology-dependent transistor device names]]. |
| |
| ===== Miscellaneous ===== | ===== Miscellaneous ===== |
| This is used to determine the hierarchy separator when generating SPICE output. Different SPICE tools use different separators, so this can be used to customize SPICE file generation. | This is used to determine the hierarchy separator when generating SPICE output. Different SPICE tools use different separators, so this can be used to customize SPICE file generation. |
| |
| | <block 75%:0:#FFFFCC;black;1px dotted black;auto/10ptrounded>**Tip:** Xyce uses ":" as the hierarchy separator by default.</block> |
| |
| <code> | <code> |
| If the generated circuit has more than the specified number of series transistors, a warning is generated. If the configuration parameters are either omitted or set to zero, no warnings are generated. This check is only turned on for production rules---i.e. if you specify individual transistors, those are not checked. | If the generated circuit has more than the specified number of series transistors, a warning is generated. If the configuration parameters are either omitted or set to zero, no warnings are generated. This check is only turned on for production rules---i.e. if you specify individual transistors, those are not checked. |
| |
| <code> | |
| string cell_namespace "cell" | |
| </code> | |
| During production rule to cell mapping, the cells are all assumed to reside in a single namespace. This parameter specifies the name of this namespace. | |
| |
| <code> | <code> |
| string_table cell_namemap "0n_0" "inv" \ | real delay 500e-12 |
| "0n1na_01o" "nor2" \ | |
| "0n1no_01a" "nand2" \ | |
| "0n1na_01a" "celem2" | |
| </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. | 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> | |
| 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 ====== |
| |
| <code> | <code> |
| string rect_inpath "paths:tosearch/for/rect/files" | 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" | string rect_outdir "outputrectdir" |
| </code> | </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. | 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> | <code> |