lxEvalCDFCallbacks

layoutXL lxEvalCDFCallbacks boolean { t | nil }

Description

Causes all SKILL callbacks defined on Common Description Format (CDF) parameters to be evaluated by default when you run the following Layout XL commands. Callbacks defined on buttons are never evaluated.

Generate All From Source
Generate Selected From Source
Generate Folded Devices
Update Components And Nets
Update Layout Parameters
Update Schematic Parameters
Back Annotate (Dummy backannotation)

The default is nil.

Irrespective of the value of the lxEvalCDFCallbacks environment variable, the following callbacks are always evaluated:

Width parameter callback for Generate Folded Devices
fingers parameter callback for Split Fingered Devices
m parameter callback, if changing the mfactor for backannotation
Width or fingers parameter callback or both the callbacks for Generate All From Source with folding and finger split enabled.

The callbacks are evaluated in the order in which they are listed in the CDF, so it is important that you set the appropriate callback at the appropriate place in the list. For more information, see Additional Information and Defining Parameters in the Component Description Format User Guide.

To prevent any CDF parameters on generated instances from getting evaluated in the schematic, set the parameters as the ones to be ignored for generation. You can use the LAM file, the paramsToIgnore environment variable, or the Connectivity Form form to do this.

Enabling this environment variable can adversely impact performance, especially on large designs with many callbacks.

GUI Equivalent

Command:

Options – Connectivity (Parameters tab)

Field:

Evaluate CDF callbacks during generation and update

(Connectivity Form)

Examples

envGetVal("layoutXL" "lxEvalCDFCallbacks")

envSetVal("layoutXL" "lxEvalCDFCallbacks" 'boolean t)

envSetVal("layoutXL" "lxEvalCDFCallbacks" 'boolean nil)

Additional Information

CDF callbacks are SKILL expressions that are triggered when the value of a parameter is set in any of these forms—the Add Instance form, the Create Path Form form, the Property Editor assistant, or the Edit Properties form.

If the PDK you are using has callbacks that edit the old Property Editor form or the Add Instance or Create Instance forms, Cadence recommends updating the PDK to remove such form-dependencies that can cause unexpected callback behavior.

If used in batch mode, CDF callbacks cannot allow dialog boxes to display to invite user interaction and may cause Virtuoso to malfunction. CDF callbacks can be designed for interactive use with the Property Editor form but such callbacks are not compatible with batch evaluation.

The layoutXL environment variable lxEvalCDFCallbacks fires CDF callbacks in the following order:

For the changed parameters, filters out any parameters, if defined in lxCDFCallbackParams, or calls the callbacks on all the changed parameters in the order they appear in the Edit CDF form.
Fires all the other CDF callbacks in the order they appear in the Edit CDF form, apart from the button CDF parameters. If lxCDFCallbackParams is defined, only parameters in this list have their callbacks fired.

Note:

lxCDFCallbackParams can be defined as both a global environment variable and as a CDF parameter itself, so you can customize it for a given cell.
Even if lxEvalCDFCallbacks is set to nil, the w callback is triggered during folding, fingers callback is triggered for fingersplit, the w or fingers parameter callback or both the callbacks are triggered during layout generation, and the m callback is triggered for dummy backannotation, if using the m-factor model.
The CDF initProc is always called before the CDF callbacks.
When CDF callbacks are triggered, the CDF doneProc is called after all the parameters are set on the instance.
Because the order of the callbacks depends on the order they appear, it is recommended to have simple CDF parameters appear first and derived parameters appear after these.
For example, it is recommended to define fw (finger width) before total width (finger width * fingers). If the total width callback is called before the finger width callback, the finger width is not changed and the calculation is based on the previous value. If the finger width callback is called first, fw is set so that the callback uses the new value and is set correctly.
Cadence advises against the use of CDF callbacks to compute the value of derived parameters. This is to avoid anomalies that are likely in automatic computation of the derived parameters. For more information, see Why Callbacks are not Advised for Deriving Parameter Values.

You can optionally set the lxCDFCallbackParams environment variable to list the callbacks you want to trigger. Some PDK set ups have callbacks that update all the CDF parameters. Therefore, triggering only a few callbacks may be required.
If you use AEL expressions in CDF, such as iPar() or pPar(), you need to set the shell environment variable, CDS_Netlisting_Mode to Analog for Layout XL to evaluate the expressions in the schematic context.
- The CDF parseAsCEL for the parameter should be set to yes. If you want a string, say “2u” to be a number, say, 2e-6 for Layout XL, you need to set parseAsNumber = yes.
  It is possible that even when CDS_Netlisting_Mode is set to Analog and parseAsCEL is set to yes, you may still not get an accurate layout. This is likely when the design uses callbacks with pPar(). Manually triggering the callbacks by setting lxEvalCDFCallbacks to t might help. See Issues when pPar and Callbacks are Used in a Design when Generating a Layout. But, Cadence advises against the combined use of CDF parameters with pPar() (AEL expressions) and CDF callbacks. This is meant to prevent getting an incorrect parameter value because the value of the expression is not known at the time the callback is fired.
If the PDK is golden, you can override the CDF by using User CDF, though the User CDF will need to be loaded every time.

Why Callbacks are not Advised for Deriving Parameter Values

Triggering callbacks to derive the values of other parameters is not advised for the following reasons:

Using callbacks to derive parameter values can prevent parameterization of the source parameters

For situations where a source parameter is meant to derive the value of another parameter, the source parameter itself cannot be controlled by a variable or an expression, such as pPar() or iPar().

For example, you might want to use the pPar() or iPar() expressions to control the value of a source parameter such that the parameter can be passed down the hierarchy. But, when the source parameter is being used to determine the value of a derived parameter, it can change depending on the value of pPar() at the time when the parameter value is being changed in Property Editor. Therefore, it is important to know the value of pPar() at the time of changing the parameter value to compute the derived parameter accurately. But, knowing the value of pPar() at the time of the parameter change is not possible. Therefore, to avoid having an inaccurate derived parameter, you might need to avoid using a source parameter that depends on pPar() (or iPar()).

Cadence recommends that for parameter values that need to be derived, the value must be computed by the application by using the source parameter at the time of usage. This may require computing the derived parameter value at the time of simulation, physical verification, or at the Pcell level. When computing the derived parameter at the Pcell level, the computation can be done in the Pcell SKILL code instead of requiring a CDF callback to be triggered.

Impossible to determine the correct order for firing multiple callbacks

When multiple parameters are changed, multiple callbacks need to be triggered. This makes it impossible to predict the correct order in which the callbacks must be fired for a parameter value to be determined accurately.

For example, if you were to change the cell name on the Edit Properties form, all the derived parameters can lose their correspondence. So, you may need to trigger a callback for each derived parameter. But, to determine the correct order in which the callbacks must be fired is not simple, and can potentially cause inaccurate derived parameter values. Therefore, using callbacks to determine the value of derived parameters is not recommended.

Example

Let us assume that the Edit CDF form has the following parameters defined: w, l, fingers, totalW

If we change w and fingers, the order of the callbacks will be: w, fingers, l, totalW
If we just change fingers, the order of the callbacks will be: fingers, w, l, totalW
If we now set lxCDFCallbackParams to “w l” and then:
- Change w and fingers, the order of the callbacks will be: w, l
- Change fingers, the order of the callbacks will be: w, l
- Change l, the order of the callbacks will be: l, w

Virtuoso Layout Suite XL: Connectivity Driven Editing User Guide
Product Version IC23.1, November 2023