Develop the Core Front-End Components file:///gfs/ind/tcsnas01/eesof/build/apps/linux_x86/synopsys/customcompiler/U-2023.03/doc/help/col...

Develop the Core Front-End Components

After copying the cells from the analogLib library into your library, you need to
define the following components:
1. Parameter Definitions: Defines Interoperable Component Description
Format (iCDF) Parameters
2. Label Display and Netlist Info Section: Defines simulator-specific simulation
information (siminfo)
3. Property Bag Definitions: Defines the design rules that are not part of the
technology file

Note:
The iCDF parameters, simInfo, and property bag information can be
defined for either a library or for the cells in the library.
After you define the iCDFs, simInfo, property bags, you must source these files
from the Custom Compiler console window. The Custom Compiler tool
executes these files and loads the data into the OpenAccess database
(data.dm).

Syntax for Library-Level Definitions:

set dmd [oa::LibDMDataOpen $<libName> <mode w|r|a>]
oa::getAccess [oa::LibFind $libName] write 1
# Parameter definitions
...
# Label Display and Netlist Info Section
...
oa::save $dmd
oa::close $dmd
oa::releaseAccess [oa::LibFind $libName]

Syntax for Cell-Level Definitions:

set dmd [oa::CellDMDataOpen $<libName> $<cellName> <mode w|r|a>]
oa::getAccess [oa::LibFind $libName] write 1
# Parameter definitions
...
# Label Display and Netlist Info Section
...
oa::save $dmd
oa::close $dmd
oa::releaseAccess [oa::LibFind $libName]

Parameter Definitions
This section contains a list of associative arrays. Each array defines one
Interoperable Component Description Format (iCDF) parameter.

Note:
The CDFs should not have any vendor tool specific commands.

Syntax:
# Parameter definitions
db::createParamDef <string>
-data <dmCell|oaCell|oaCellDMData|
oaLib|oaLibDMData|oaStdViaDef|
oaTech> \
[-prompt <string>] \
[-defValue <string>] \
[-type <enum>] \
[-callback <string>] \
[-units <string>] \
[-choices <string>] \
[-parseAsNumber <boolean>] \
[-parseAsPEL <boolean>] \
[-editable <string>] \
[-display <string>] \
[-use <string>] \
[-storeDefault <boolean>] \
[-forceMaster <boolean>] \

Argument Description

string Name of the iCDF.

Note:
The lxComponentType iCDF can be specified only at the library level.
This iCDF is used for auto-chaining and auto-folding operations in
SDL.

-data Cell or library that contains the design manager data where the specified
Netlist Info is stored.

-prompt Identifier used in the Schematic Editor to identify the parameter.

-defValue Default value of the parameter. If no property exists on the instance,

then this is the parameter value.

1 of 4 2/21/25, 02:31
Develop the Core Front-End Components file:///gfs/ind/tcsnas01/eesof/build/apps/linux_x86/synopsys/customcompiler/U-2023.03/doc/help/col...

Argument Description

-type Data type the Parameter Definition Editor uses to manipulate the
parameter value. The default data type is “string”.
Valid data types are:
• bool | boolean
• button
• cyclic
• filePath
• float
• int | integer
• lpp
• netSet
• radio
• real
• string

-callback Callback for the parameter. This field is evaluated whenever an instance
parameter using this definition is modified.

-units International System of Units (SI) of measurement for the parameter.

-choices List of choices to use for the enumeration parameter types.

-parseAsNumber Determines whether the result of the evaluation should be treated as a

number or as a string literal. Default is “true”.

-parseAsPEL Controls whether instance parameters should use the PEL expression
evaluator. Default is “false”.

-editable This field indicates if the Property Editor allows direct editing of parame‐
ter instance values. This field is typically used when the value of the pa‐
rameter is meant to be set by another parameter’s change callback.
Default is “t”.

-display Sets the default visibility of the parameter. Default is “t”.

-use This field combined with the “display” field specifies if the parameter
should be displayed in the Property Editor. Default is “t”.

-storeDefault Upon instantiation, copies the defValue as a property on the instance.

Default is “false”.

-forceMaster Forces the create operation to create the iCDF in the master library and
ignore any overlay library. Default is “false”.

Example 1: Library-Level iCDF

db::createParamDef lxComponentType \
-data $dmd \
-prompt {Custom Compiler Component Types} \
-defValue {(("cells" ("n_3t" "na_3t" "nl_3t"
"nh_3t" "nm_3t" "n_4t"
"na_4t" "nl_4t" "nh_4t"
"nm_4t" "n25_3t" "na25_3t"
"n18_3t" "n33_3t" "na18_3t"
"na33_3t" "nm25_3t" "na25_4t"
"n18_4t" "n33_4t" "na18_4t"
"na33_4t" "nm25_4t"))
("type" "nmos")
("lxActiveLayer" "diff drawing")
("lxMOSDeviceType" "NMOS")
("lxDeviceWidth" "w")
("lxMaxWidth" 5u))} \
-type string \
-parseAsNumber no \
-parseAsPEL no \
-display {nil}

Example 2: Cell-Level iCDF

db::createParamDef model \
-data $data \
-prompt {Spice Model} \
-defValue {N} \
-type string \
-parseAsNumber 0 \
-parseAsPEL 1 \
-editable {nil} \
-display {t} \
-use {t} \
-storeDefault 0

Label Display and Netlist Info Section

The Label Display Section (propList) and the Netlist info section of the
Interoperable Component Description Format (iCDF) file contain settings for
interpreted labels and also contain the Simulation Information (simInfo)
subsection. The interpreted label settings control how cdsParam() and
cdsName() labels are displayed in the Schematic Editor.

Syntax:

2 of 4 2/21/25, 02:31
Develop the Core Front-End Components file:///gfs/ind/tcsnas01/eesof/build/apps/linux_x86/synopsys/customcompiler/U-2023.03/doc/help/col...

# Label display section

db::setNetlistInfo <string> \
-data <dmCell|oaCell|oaCellDMData| \
oaLib|oaLibDMData> \
[-netlister <string>] \
[-info <string>] \
-value <string> \
[-type <enum>] \
[-section <enum>] \
[-clear
<bool>]
\
[-forceMaster <bool>]

Argument Description

string Name of the netlist info property.

Note:
The lxComponentType iCDF can be specified only at the library level.
This iCDF is used for auto-chaining and auto-folding operations in
SDL.

-data Cell or library that contains the design manager data where the specified
Netlist Info is stored.

-netlister Name of the netlister,

-info Netlist information. Default is “simInfo”,

-value Value to be associated with the specified netlist property.

-type Data type the Parameter Definition Editor uses to manipulate the
parameter value. The default data type is “symbol”.
Valid data types are:
• floating
• integer
• list
• real
• string
• symbol

-section Name of the iCDF section. The default is “netlist”.

Valid values are:
• display
• form
• netlist
See Table 1 for a detailed explanation of the -section attributes.

-clear When "true", clears the specified netlist property. This is useful before
creating a new property with the -value argument.
Default is "false".

-forceMaster Forces the create operation to create the iCDF in the master library and
ignore any overlay library. Default is “false”.

Table 1: -section Attributes

Value Attribute Description

display instNameType This field can either be set to “schematic”, or

“simulation”. If the value is set to “schematic” then
cdsName() evaluates to the name of the instance within
the schematic database. If the value is set to “simulation”
then cdsName() evaluates to the name of the instance
within the simulation netlist.

initDisplayMode This field can be set to either “cellName” or

“instanceName”. If the field is set to “cellName” then
cdsName() labels are displayed as the name of the
component. If the field is set to “instanceName” then the
instance's name attribute is displayed in cdsName()
labels.

modelLabelSet If the Interpreted Label Mode is set to “model” then this

list specifies the simulator computed device model val‐
ues to display with cdsParam().

opPointLabelSet If the Interpreted Label Mode is set to “oppoint” then this

list specifies the operating point values to display with
cdsParam().

paramLabelSet If the Interpreted Label Mode is set to “param” then this

list specifies the instance parameter values to display
with cdsParam().

form promptWidth Controls the width of the prompt column in the property
editor form.

fieldHeight Controls the height of the user input field in the property
editor form.

fieldWidth Control the width of the user input field in the property
editor form.

buttonFieldWidth Control the width of buttons associated with the display

of parameters.

formInitProc Used to register a callback to be triggered when the prop‐

erty editor commands are executed.

doneProc Used to register a callback to be triggered when you click

the OK or Apply button in the property editor.

3 of 4 2/21/25, 02:31
Develop the Core Front-End Components file:///gfs/ind/tcsnas01/eesof/build/apps/linux_x86/synopsys/customcompiler/U-2023.03/doc/help/col...

Value Attribute Description

netlist componentName The Custom Compiler netlist formatter uses the value of
this field to determine how to netlist the instance(s).

instParameters Used by the netlist formatter for properties that should

be written as “name = value” pairs.

modelName A variant of the model name to print. This takes prece‐

dence over the componentName.

namePrefix Used to specify the valid first character for this compo‐
nent.

netlistProcedure Used to determine the formatting procedure to call to

write instance lines for this component.

otherParameters Used by Spice netlist formatter for properties that should

be written as an ordered list as opposed to “name =
value” pairs.

permuteRule Used by the Custom Compiler tool to check what termi‐

nals may be permuted during modification.

propMapping Used to specify a mapping from component parameter

names to simulator-specific property names.

stringParameters Used to determine the parameters that support string val‐

ues.

termMapping Used to specify the mapping of terminals for a simulator.

termOrder Used to specify the order of terminals to be used in an in‐

stance line.

Property Bag Definitions

Property bags are used for storing design rules that are not part of the
technology file.
Typically common rules such as contact width and poly overlap of diffusion
are defined in the library-level property bags and cell-specific rules such as min,
max, and contact to gate spacing are defined in the cell-level property bags.
Property bags are accessed by both the callback procedures and the PCell
codes. The callback procedures use the property bags for verifying and
validating user inputs, while the PCell codes use the property bags to fetch
design rule values.

Syntax:
# Property Bags
oa::<variant> $<object> <name> <value>

Argument Description

variant Type of the property bag. “StringPropCreate” is the most commonly

used property bag declaration. Some of the frequently used property bag
declarations are:
• StringPropCreate
• DoublePropCreate
• IntPropCreate
• BooleanPropCreate

object Name of the OpenAccess database.

name Name of the property.

value Value of the property.

Example 3: Property Bag

oa::StringPropCreate $dmd dWidthEL {480n}
oa::DoublePropCreate $dmd M1CwEnc 0.005
oa::IntPropCreate $dmd nf 3
oa::DoublePropCreate $dmd DFM t

4 of 4 2/21/25, 02:31