B

---

Backannotation of dcOp / Transient Values for M-Factor Devices

---

This appendix looks at the backannotation of dcOp and transient values for multiple factor devices. It describes the process of schematic annotation of operational data associated with m-factor devices.

There are two alternatives open to you in achieving this:

1. Using the ?mfactorR and ?mfactorW qrcParameters when extracting a view. Here, you will instruct Cadence Quantus QRC Extraction to merge m-factor devices.
   For more information on this option see Grouping M-Factor Devices At Extraction Time.
2. Using opParamExprList to change the CDF of the cell to make use of the new parameters.
   For more information on this option see Using opParamExprList Functionality.
   
   This is the recommended option.

Identifying M-Factor Devices

When a backannotation has an m-factored device, and it only processes the first device, a “,..” will be added to the backannotated value and the following, once only, warning message will be issued in the CIW:

“WARNING* Labels with suffix ",.." are on devices which map to multiple devices. Only the value from one device is currently annotated. For more information on displaying alternative values, see the Backannotation of dcOp / Transient Values for M-Factor Devices section in Chapter 1 of the "Virtuoso Parasitic Aware Design User Guide"

Figure B-1 M-Factor Devices On A Schematic

Once the M-Factor devices have been identified on a schematic, you can choose to display the m-factor devices by Grouping M-Factor Devices At Extraction Time or Using opParamExprList Functionality.

Grouping M-Factor Devices At Extraction Time

This approach relies on the capabilities of Quantus QRC for merging m-factor devices at extraction time. It involves merging m-factor devices so that there would only be one extracted instance per schematic instance.

This means that when backannotation is used, only one value will be displayed, as no m-factor groups are found. You will therefore direct Quantus QRC extraction to merge m-factor devices, which will require the modification of the RSF file.

Modifying the RSF File

A run specification file (RSF) is used to direct the extraction of parasitics during a Quantus QRC extraction run.

In the RSF, you will find a qrcParameter section, which you can modify to provide ?mFactorR and/or ?mFactorW qrcParameters. These parameters are used to group m-factor devices as follows:

• ?mFactorR - reduces the number of MOS and LDD transistors in the output netlist by merging parallel transistors in the layout.
• ?mFactorW - changes the default behavior of ?mFactorR so that merged transistor devices are output to the netlist with widths summed, and no m-factor parameters added.

To modify the RSF file, with the new parameter settings, you edit the M Factor R and M Factor W options in the QRC Parasitic Extraction Run Form.

1. Select QRC – Setup QRC.
2. Click the Filtering Options tab.
   The Filtering Options tab has M Factor R(eduction) and M Factor W(idth) options that correspond to ?mFactorR and ?mFactorW.
3. Edit the M Factor R(eduction) and M Factor W(idth) options as required.
   M Factor R lets you reduce the number of MOS and LDD transistors in the output netlist by merging parallel transistors in the layout. The M-Factor is annotated to a transistor in schematic capture, and the resultant layout should contain “m” transistors laid out in parallel. These parallel transistors are designed so that the parasitics from gate-to-gate, source-to-source, and drain-to-drain are minimal. M Factor R uses a specified resistance value to merge all transistors in which the shortest path resistance between the source/drain/gate of adjacent devices is less than the value specified in the ?mFactorR value.
   Activating the M Factor W command will change the default behavior of M Factor R, in that width values will always be summed, regardless of their equivalence, and no M-Factor (m=n) parameter is output to the netlist.
   For more information, see the Filtering Options Tab section in the Quantus QRC Extraction Users Manual.

Limitations of the Edit RSF Approach

Editing the ?mFactorR and ?mFactorW parameters may not group m-factor devices as required.

This could be because:

• ?mFactorR only merges transistors that follow a set criteria, for example the transistors must be the same model type, or share the same source/drain/gate and so on.
• ?mFactorR only supports MOS/LDD transistors. However, m-factor can be found in other types of devices, for example CAP and RES. An alternative solution is therefore required in these cases, such as Using opParamExprList Functionality.

Using opParamExprList Functionality

This method of backannotating m-factor device values requires the use of opParamExprList, and involves you changing the CDF (Component Description Format) of the cell to make use of the new parameters. Here, we process the m-factor device’s parameter values, and provide a new value which summarizes their effect. This is done using a list that contains all of the values associated with the m-factor devices.

After doing this, re-running netlist and simulation again will display the m-factor devices value.

This cannot be an automatic function as the parameters do not have semantic information associated with them.

The following flowchart provides an overview of backannotation of m-factor devices using the opParamExprList functionality. As mentioned, this is the recommended approach.

Specifying Parameters to be Displayed

As mentioned, the function opParamExprList is a CDF parameter that allows you to save additional op information. For example, opParamExprList allows you to create a new parameter which sums the “id” of all the m-factor devices. This information can then be displayed using the calculator or layer display mechanism. It is the label display information that is of particular interest to us, as it allows you to display parameter values. The interpreted label cdsParam() allows you to display information about parameter values.

During automatic symbol generation, three cdsParam labels are usually generated. You can however define new labels if required.

To specify which parameter will be displayed in the cdsParam() labels, you will need to edit the CDF of the relevant library cell. To do this:

1. From the CIW, select Tools – CDF – Edit to display the Edit Component CDF form.
2. Browse to locate the cell whose parameters you want to specify for display.
3. Scroll down to the Interpreted Labels Information section in the Edit Component CDF Form.
   In this section you will see the op pointLabelSet field, which will list the parameters to be displayed if paramDisplayMode is set to op point. For example:
   You can see above that the op pointLabelSet only has two parameters: “id” which is the current of the cell, and “mFactorF” which is a new parameter defined in the opParamExprList. This new parameter takes into account the m-factor devices, and in this case adds the “id” values of all devices.
   
   Each label set is limited to the number of cdsParam labels in the symbol.
   Instead of creating a new parameter name “mFactorF”, the existent parameter name “id” could have been redefined in function of the opParamExprList. This has the advantage that the existent parameter will handle single devices as well as m-factor devices in a transparent manner.
4. You now need to define the new mFactorF parameter or, as mentioned above, redefine the existent parameter “id”. The parameter may be defined using one of the Functions Provided, or by creating your own function, which may be based on the provided functionality.
   The CDF description of the cell now needs to be modified.
5. In the Edit Component CDF form (accessible from the CIW by selecting Tools – CDF – Edit), scroll to the Simulation Information section and click the Edit button to display the Edit Simulation Information form.
   In the above screenshot, you can see that the parameter name “id” is defined by aelSumOPParam.
   
   Only spectre and csSpice simulators are supported.

Functions Provided

aelSumOPParam

Description	Returns a number which is the result of adding the values of the parameters specified by inst. This inst can be, for example, a schematic name which maps to multiple m-factor devices, one device, or a specific extracted name which will allow you to display specific m-factor devices values. To do this, aelSumOPParam creates a list with all the instances being considered. The instance may be a schematic instance (the result of inst()), or an extracted instance. For example “I0/M0_1_qrc”. If a schematic instance is given in out-of-context, then the mapped extracted instances are considered, for example if inst() is given, the instances considered could be (“/I0/M0” “/I0/M0_1_qrc” “/I0/M0_2_qrc” “/I0/M0_2_qrc” “I0/M0_3_qrc” “I0/M0_4_qrc”). Once the list is created, the “param” specified for each instance is added. This “param” can be any of the simulation parameters, but if not specified, is “id” by default.
Inputs	instName: A string that can be a schematic instance. The result of the method inst(), or an extracted instance name. simParam: Can be any simulation parameter, for example “id”. labelParam: An optional parameter that is required when the name of the label parameter defined by opParamExprList is different from the simulation parameter being processed. For example, if the label parameter is mFactorF and the simulation parameter being processed is id, then labelParam must be given with the value mFactorF. resname: Another optional string parameter used to select the type of results from a particular analysis, for example dcOpInfo-info. The type of results available can be obtained using the following command: results(?noAlias t). As a default, this input is set to the current type of results.
Outputs	A number which is the result of adding all of the “param” available in the specified “instName”, or nil if the instance fails to map.
Definition

sumOPParamV2

Description	As aelSumOPParam. This method is not provided, therefore you will have to introduce it by copy and pasting the code. This function does effectively the same as aelSumOPParam, but differs in the following: sumOPParamV2 requires that the label parameter name is different than the processed simulator name. For example it does not allow you to have a label parameter name “id” processing the simulator parameter “id”. Using this method is approximately 50% faster than using aelSumOPParam. You should not use aelSumOPParam and sumOPParamV2 at the same time, in the same library/cell.
Inputs	instName: A string that can be a schematic instance; the result of the method inst(), or an extracted name instance. simParam: A string that can be a simulation parameter, for example: id. labelParam: A string that is the label parameter defined by opParamList, for example mFactorF.
Outputs	A number which is the result of adding all of the “param” available in the specified “instName”, or nil if the instance fails to map.
Definition

aelDisplayOPParam

Description	This function returns a list whose elements are the “param” of each of the instances being processed. The instances being processed depend on the given “instName”. The function aelDisplayOPParam creates a list with all of the instances being considered. The instance may be a schematic instance (the result of inst()), or an extracted instance. For example “/I0/M0_1_qrc”. If a schematic instance is given in out-of-context, then the mapped extracted instances are considered, for example if inst() is given, the instances considered could be (“/I0/M0” “/I0/M0_1_qrc” “/I0/M0_2_qrc” “/I0/M0_2_qrc” “I0/M0_3_qrc” “I0/M0_4_qrc”). Once the list is created, the “param” specified for each instance is added to the return list. This “param” can be any of the simulation parameters and, if not specified, the default is “id”.
Inputs	instName: A string that can be a schematic instance. The result of the method inst(), or an extracted instance name. simParam: Can be any simulation parameter, for example “id”. labelParam: An optional parameter that is required when the name of the label parameter defined by opParamExprList is different than the simulation parameter being processed. For example, if the label parameter is mFactorF and the simulation parameter being processed is id, then labelParam must be given with the value mFactorF. resname: Another optional string parameter used to select the type of results from a particular analysis, for example dcOpInfo-info. The type of results available can be obtained using the following command: results(?noAlias t). As a default, this input is set to the current type of results.
Outputs	A string with a list of numbers separated by commas, or nil if the instance fails to map.
Definition