Creating New Component Definitions

The program learns about new components through component definitions in AEL files. An example of a new component definition is shown below. The example is a definition of a microstrip bend component that has five parameters.

New Component Definition Example

The example definition uses the AEL functions create_item() and create_parm().

The create_item() function creates a component definition with a specific name, associated parameters and other characteristics.

The create_parm() function creates and returns a parameter definition and is used to create parameter definitions for create_item(), where the create_parm() function return values become pass parameters for create_item(), with each use of create_parm() defining a parameter for the component.

The function prm() creates and returns a parameter value and is used to generate a default value where the form of the value is something other than a normal number or string. The forms of a parameter value are explained more completely in the section Creating and Using Custom Forms.

For details on these functions, see Component Definition Functions.

Form Sets

When components and commands are defined with their associated parameters, the allowable forms for each parameter are specified through a named form set. A form set describes the types of values a parameter can take.

A form set is composed of one or more forms, each representing a value option for a parameter. Several forms are associated together in sets for use with a parameter, where a parameter value can assume any of the forms in the set. To be valid, the parameter definitions must specify the name of a defined form set. In some cases, this can require the definition of a form set of one form.

For example, the Parameter Entry Mode menu in the Component Parameters dialog box is configured by the form set for the selected parameter. The name of the form is used to configure the standard Component Parameters dialog box.

Forms and form sets are all defined using these AEL functions:

create_form_set()
create_text_form()
create_constant_form()
create_compound_form()

The following example defines a form set:

create_form_set("StdFileFormSet", "StdForm", "FileBasedForm");

Certain primitive forms are pre-defined and do not need to be created explicitly. Some of the pre-defined forms are:

StdFormSet
StdFileFormSet
ReadFileFormSet
StringAndReferenceFormSet
SingleTextLineFormSet
SingleTextLineIntegerFormSet
SingleTextLineDoubleFormSet

The files stdforms.ael, stditems.ael, and pde_gemini.ael contain many of the standard form and component definitions used by the program. These files can be found in the <$HPEESOF_DIR>/de/ael directory.

For details on forms and form set functions, see Component Definition Functions.

Creating and Using Custom Forms

In some cases a non-standard form is required to support unique syntax or to limit the options presented in a dialog box. Some of the necessary forms are unique to a simulator or to a particular design type. The program provides the ability to define new forms and their characteristics.

The characteristics of a form govern its handling in a Component Parameters dialog box, on-screen editing in the schematic and in the netlist. The form contains the instructions for formatting an instance parameter value for use in the display annotation and in the netlist. It also contains information to generate a list of value options for selection from a list in a Component Parameters dialog box. Also, the form can check the typed input for validity using the validate function.

Forms come in several classes that are provided with the program. A new form can be defined using one of these classes, where the new definition gives the form characteristics specific to the simulator/syntax requirements. The following built-in classes are characterized.

Constant Class

Used where the value is a constant and cannot be changed. Examples of this class are the forms for the SinE parameter of the LPF_RaisedCos component, where the allowed values are YES and NO. Two forms would be created, one for each of the possible values, and a form set would be created that referenced both forms. The definition for the SquareRoot parameter of the LPF_RaisedCosineTimed component would reference the form set defined. Selection would be made between the two allowed forms from an option menu in a dialog box, with no typing allowed.

Compound Class

Used to define a hierarchical parameter, where the parameter value is defined by several sub parameter values combined. Examples of this class are VarFormStdForm and DACForm. For this class, parameters are defined for the form using create_parm(), each of which references a form set. Since this form is indirectly referenced through another parameter definition, it creates a recursive definition (only one level deep). The parameter's value is composed of the multiple fields set in the form's parameter values.

Text Class

Used where a text value is required, but an arbitrary string is not appropriate. This occurs for parameters where a list of possible values should be generated at run time and presented in a dialog box, or where additional verification must be performed on the typed response in the dialog box. An example of this class is the msub parameter of the mlin element, where the text required is the instance name of an msub element. Optionally, a dialog box would provide a list of msub components available, and the selection could be made from the list or a name could be entered. In this case, checking would not be necessary, but a check function could be applied to verify that the entry was indeed a valid msub name. Although not supported by the user interface anymore, most parameters in the program are using this class of form.

Two rules should be applied to the naming of a form:

The AEL functions that create new forms are create_constant_form(), create_compound_form(), and create_text_form().

The forms created by create_constant_form() represent a fixed value, which is selected from a list of the possible values (normally from an option box) but does not edit textually. An example of this might be the definition of the Yes form:

create_constant_form("Yes", "YES", 0, "yes", "yes");

The forms created by create_compound_form() represent values that contain one or more parameters, some of which represent a value more complicated than a string. Each parameter has its own set of forms for the values it can accept. For example:

create_compound_form("LinearStart", "LinearStart", 0,
"Start=%0s, Stop=%1s Step=%2s Lin=%3s",
"Start=%0s, Stop=%1s Step=%2s Lin=%3s"

create_parm("Start", "Start Value", 0 "FSTextForms",
FREQUENCY_UNIT, prm("FSTextForm", "0")),
create_parm("Stop", "Stop Value", 0 "FSTextForms",
FREQUENCY_UNIT, prm("FSTextForm", "0")),

create_parm("Step", "Step Value", 0 "FSTextForms",
FREQUENCY_UNIT, prm("FSTextForm", "0")),

create_parm("Lin", "Points in a Linear Sweep", 0 "FSTextForms",
UNITLESS_UNIT, prm("FSTextForm", "0")));

The forms created by create_text_form() represent values that accept a string, but not just any string will do. A dialog box to present options for the string and additional checking of the typed string can be specified. A data string can be provided for use in the option list generation and value verification. An example might be the definition of the SingleTextLineIntegerForm form, used to represent a value that is an integer.

The value stdforms_validate_integer specifies a function that checks a value typed in by the user. If the value is an integer, the function returns 1 and the user-value is acceptable. If the value is not an integer, the function returns 0 and the user-value is not acceptable.

create_text_form("SingleTextLineInteger", "Integer Value",
"SingleTextLine", 0, "%v", "%v", NULL, stdforms_validate_integer,
NULL);

For details on these functions, see Component Definition Functions.

Format Strings

Format strings are used by a number of functions to construct a single string out of a number of different components. They are modeled on the basic printf capability in the C programming language, but include a large number of additional conversion specifiers. These strings provide a flexible way to control the formatting of complex value strings. Format strings control the way component parameters are displayed on the schematic. A standard format string is used by most components. A standard format string, called ComponentNetlistFmt, is used for the formatting of a component's netlist line.

The basic form of these strings is a pair of quotation marks enclosing any number of strings and conversion specifiers. Conversion specifiers are preceded by the percent sign (%) and take the following form:

%nc

where n represents an optional integer value and c represents the instruction code. The default value of the optional integer value is 0.

Available Specifiers

The available specifiers are Loops, Conditionals, and Operators. The available specifiers and what each does (with optional integer after % and before the single letter instruction code) are listed in the following sections.

Loops

%b Begin parameter iteration loop, which shifts through each parameter in the list of parameters of a component instance or a compound form. The optional integer value (the n in %nc) indicates the initial parameter index, which sets the value of j counter. The j counter is incremented at the end of each parameter iteration.

%r Begin repeated parameter iteration loop, which checks if the current parameter (j counter) is a repeated parameter and iterates through each value in the list of values for the repeated parameter. The optional integer value (the n in %nc) indicates the initial repeat parameter index, which sets the value of i counter. The i counter is incremented at the end of each repeated parameter iteration. The value of a repeated parameter is stored as a list of values, where a normal parameter has a single value. For details on how to define a repeated parameter, refer to create_parm(). An example of a component with repeated parameters is SDD1P.

%h Begin hierarchical parameter iteration loop for compound form, where the parameter list is retrieved from the current parameter's compound form. The optional integer value (the n in %nc) indicates the initial parameter index, which sets the value of j counter for the hierarchical loop. The j counter for the hierarchical loop is incremented at the end of each hierarchical parameter iteration. If this is in a nested loop, the j counter value for the original parameter iteration loop (%b) is stored and retrieved as a top counter value.

%# Begin node iteration loop, which shifts through each node in the list of nodes of a component instance. The optional integer value (the n in %nc) indicates the initial node index, which sets the value of l counter. The l counter is incremented at the end of each node iteration.

%> Begin global node iteration loop, which shifts through each global node in the global node list for the design hierarchy. The optional integer value (the n in %nc) indicates the initial global node index, which sets the value of g counter. The g counter is incremented at the end of each global node iteration.

%i Transfer the sum of repeated parameter iteration index (current i counter value) and the optional integer value (the n in %nc), to the output string.

%j Transfer the sum of parameter iteration loop index (current j counter value) and the optional integer value (the n in %nc) to the output string.

%l Transfer the sum of node iteration loop index (current l counter value) and the optional integer value (the n in %nc) to the output string.

%e End the most recent iteration loop. The iteration loop ends when the iteration counter for the loop is the same as the optional integer value (the n in %nc), or when the end of the list being iterated on is reached. The appropriate iteration counter is modified depending on the type of loop in progress. In addition, the format string is modified to facilitate the next iteration of the current loop or to end the current loop. Loops can be nested.

Conditionals

%F Set the fieldIndx so the next %29? test will apply to that field. The optional integer value (the n in %nc) indicates the field number. %2F ... %29? Will test if 3rd field is an empty value. After %29? the fieldIndx is reset to -1.

%? Begin a conditional test, where the optional integer value (the n in %nc) indicates the type of test performed:

0 = TRUE if inside a repeated parameter loop (%r)
1 = TRUE if form of current parameter value is tunable
2 = TRUE if form of current parameter value has sub parameters (compound form)
3 = TRUE if form of current parameter value has special attributes
5 = TRUE if form of current parameter value is an equation
6 = TRUE if nominal value of current parameter is non-zero
7 = TRUE if component instance is mirrored
8 = TRUE if parameter is netlistable
9 = TRUE if component instance has a layout location available
20 = TRUE if design is a network
24 = TRUE if form of current parameter value is binary
25 = TRUE if form of current parameter value is octal
26 = TRUE if form of current parameter value is hexadecimal
27 = TRUE if form of current parameter value is numeric
28 = TRUE if form of current parameter value is string
29 = TRUE if current parameter has no value
30 = TRUE if PARM_RIGHT_HAND_ONLY attribute is set for the parameter.
31 = TRUE if node name for the specified node index (l counter) exists in the node name list.
32 = TRUE if external port name for the specified external port index (k counter) exists in the external port name list.
33 = TRUE if global node name for the specified global node index (g counter) exists in the global node name list.
35 = TRUE if any global node exists in the design.
37 = TRUE if the number of parameters for the instance is not zero.
38 = TRUE if PARM_NO_PLOT attribute is set for the parameter.
39 = TRUE if the global parameter AllParams is set for the instance.
41 = TRUE if INST_SCOPE_LOCAL attribute is set for the instance.
42 = TRUE if INST_SCOPE_ NESTED attribute is set for the instance.
43 = TRUE if INST_SCOPE_GLOBAL attribute is set for the instance.
44 = TRUE if the node is a ground node (node number = 0)
45 = TRUE if the value string starts with ";"

The format string following a test is optionally interpreted depending on a TRUE result of the test. The %: and %; delimit the end of the conditional part of the format string.

%: End TRUE branch of conditional format begun with %? And begin FALSE branch.

%; End of conditional format begun with %?

Operators

%g Transfer the current design name to the output string. The optional integer value (the n in %nc) is ignored.

%n Transfer the component name to the output string. The optional integer value (the n in %nc) is ignored.

%t Transfer the instance name (formerly instance tag) to the output string. The optional integer value (the n in %nc) is ignored.

%x Transfer the instance location value to the output string. The optional integer value (the n in %nc) indicates:

0 = X coordinate
1 = Y coordinate
2 = Orientation angle (degrees)

%d Transfer the data string to the output string. Data string can be component netlist data ( netlistData argument in create_item() ) or an array of form data strings (dataValue argument in create_text_form() ). The optional integer value (the n in %nc) specifies the index into the array of form data. Index value other than 0 is invalid for netlist data. The default index value is 0.

%k Transfer the parameter name to the output string. The optional integer value (the n in %nc) indicates the desired parameter index relative to the current parameter index in the parameter list, with 0 for the current parameter. The current parameter index is determined by the value of j counter.

%p Transfer the parameter value, formatted using the netlistFormat string from the parameter's form definition, to the output string. This works like %s except that the netlistFormat is used. The optional integer value (the n in %nc) indicates the desired parameter index relative to the current parameter index in the parameter list, with 0 for the current parameter. The current parameter index is determined by the value of j counter.

%s Transfer the parameter value, formatted using the displayFormat string from the parameter's form definition, to the output string. This works like %p except that the displayFormat is used. The optional integer value (the n in %nc) indicates the desired parameter index relative to the current parameter index in the parameter list, with 0 for the current parameter. The current parameter index is determined by the value of j counter.

%v Transfer the current parameter value to the output string. The optional integer value (the n in %nc) indicates the field index for forms having more than one field, with 0 for the first field (see example later). For constant forms, special control over formatting may be exercised by calling the dataFunction specified in create_text_form(). This format is used only in netlistFormat string or displayFormat string of form definitions.

%o Transfer the nominal value of a parameter that can be optimized. The optional integer value (the n in %nc) indicates the desired parameter index relative to the current parameter index in the parameter list, with 0 for the current parameter. The current parameter index is determined by the value of j counter.

%q Transfer the nominal value, evaluating all variable references, of a parameter that can be optimized. This works like %o except that variable references are evaluated. The optional integer value (the n in %nc) indicates the desired parameter index relative to the current parameter index in the parameter list, with 0 for the current parameter. The current parameter index is determined by the value of j counter.

%f Transfer the parameter value form name to the output string. The optional integer value (the n in %nc) is ignored. (Use after %p or %s operators).

%u Transfer the parameter value unit name to the output string. The optional integer value (the n in %nc) indicates the desired parameter index relative to the current parameter index in the parameter list, with 0 for the current parameter. The current parameter index is determined by the value of j counter.

%z Transfer unit conversion factors, standard usage of optional integer value (the n in %nc):

0 = FREQUENCY_UNIT to MKS
1 = RESISTANCE_UNIT to MKS
2 = CONDUCTANCE_UNIT to MKS
3 = INDUCTANCE_UNIT to MKS
4 = CAPACITANCE_UNIT to MKS
5 = LENGTH_UNIT to MKS
6 = TIME_UNIT to MKS
7 = ANGLE_UNIT to MKS
8 = POWER_UNIT to MKS
9 = VOLTAGE_UNIT to MKS
10 = CURRENT_UNIT to MKS
11 = DISTANCE_UNIT to MKS
12 = UNIT length to layout database
13 = User length to layout database
20 = MKS to FREQUENCY_UNIT
21 = MKS to RESISTANCE_UNIT
22 = MKS to CONDUCTANCE_UNIT
23 = MKS to INDUCTANCE_UNIT
24 = MKS to CAPACITANCE_UNIT
25 = MKS to LENGTH_UNIT
26 = MKS to TIME_UNIT
27 = MKS to ANGLE_UNIT
28 = MKS to POWER_UNIT
29 = MKS to VOLTAGE_UNIT
30 = MKS to CURRENT_UNIT
31 = MKS to DISTANCE_UNIT
32 = Layout database to UNIT length
33 = Layout database to User length

%c Transfer the node number to the output string. The optional integer value (the n in %nc) indicates the desired node index relative to the current node index in the node number list for the instance, with 0 for the current node number. The current node index is determined by the value of l counter.

%C Transfer the node name to the output string. The optional integer value (the n in %nc) indicates the desired node index relative to the current node index in the node name list for the instance, with 0 for the current node name. The current node index is determined by the value of l counter.

%m Transfer the external port number to the output string. The optional integer value (the n in %nc) indicates the desired external port index relative to the current external port index in the external port number list for the design, with 0 for the current external port number. The current external port index is determined by the value of k counter.

%M Transfer the external port name to the output string. The optional integer value (the n in %nc) indicates the desired external port index relative to the current external port index in the external port name list for the design, with 0 for the current external port name. The current external port index is determined by the value of k counter.

%w Transfer the global node number to the output string. The optional integer value (the n in %nc) indicates the desired global node index relative to the current global node index in the global node number list for the design hierarchy, with 0 for the current global node number. The current global node index is determined by the value of g counter.

%W Transfer the global node name to the output string. The optional integer value (the n in %nc) indicates the desired global node index relative to the current global node index in the global node name list for the design hierarchy, with 0 for the current global node name. The current global node index is determined by the value of g counter.

%% Transfer a single % character to the output string, integer value (the n in %nc) ignored.

Netlist Format String Examples

These examples illustrate the use of netlist format string in components and forms.

Example 1: Simple format string

A Compound form netlist format string "Start=%0v Stop=%1v Step=%2v"

Can be interpreted as follows:

Transfer the string "Start=" to output string ( Start= )
Transfer the first field in parameter value to output string (%0v).
Transfer the string "Stop=" to output string ( Stop= )
Transfer the second field in parameter value to output string (%1v).
Transfer the string "Step=" to output string ( Step= )
Transfer the third field in parameter value to output string (%2v).

An example output string with this format string, for a compound form component parameter value list of 10, 20, 2 is:

"Start=10 Stop=20 Step=2"

Example 2: Simple iteration loop and conditionals

A node iteration loop format string %# %44?0%:%31?%C%:_net%c%;%;%e

Can be interpreted as follows:

Start node iteration loop at node index 0 (%#)
(For each node iteration perform all of the following)
If the node is a ground node (%44?)
   Transfer "0" to output string ( 0 ) 
Else ( %: )
   If there is a node name entry for the node index ( %31? )
       Transfer the node name to output string ( %C ) 
   Else ( %: ) 
       Transfer the string "_net" and the node number to the output string (_net%c)
   End condition ( %; )
End condition ( %; )
End loop ( %e )

An example output string with this format string for a component with four nodes, one connected to the ground and another named "Vcc" is:

"0 _net2 Vcc _net4"

Example 3: Nested iteration loops

A simplified nested parameter iteration loop(%b) and repeated parameter loop(%r) format string " %b%r%k%?[%1i]%;=%p %e%e"

Can be interpreted as follows:

Start parameter iteration loop at parameter index 0 ( %b ) 
(For each parameter iteration, perform all of the following)
Start a repeated parameter iteration loop at repeated parameter index 0 ( %r ) 
(For each repeated parameter iteration perform all of the following)
   Transfer the parameter name to the output string ( %k )
   If the parameter is a repeated parameter ( %? )
        Transfer "[" string to the output string ( [ )
        Transfer the sum of 1 and the repeated parameter index to the output string (%1i)
        Transfer "]" string to the output string ( ] )
   End condition ( %; )
   Transfer the string "=" to output string ( = )
   Transfer the parameter value to the output string ( %p )
End loop ( %e )
End loop ( %e )

An example output string with this format string for a component with a repeated parameter S and another parameter Num is:

"S[1]=0 S[2]=1 Num=2"

Assigning Components to Groups

A new component must be assigned to a library group or palette group for placement. Library group and palette groups are associated with a particular type of design. The group definitions for each design type is distinct. Most likely, you will assign the new components you create to groups for the current network design, which are displayed in the schematic and layout windows in the program.

The functions used to assign components to groups are set_design_type(), library_group(), and de_define_palette_group(). For details on these functions, see Component Definition Functions.

An example of assignment of an component to a group is:

set_design_type(analogRFnet);
library_group("mstrip", "Microstrip components", "MLIN", "MBEND");

Two AEL functions are demonstrated in the example. The example assigns the components MLIN and MBEND to the library group mstrip and the library group is associated with analog/RF network designs.

Designing Component Schematic Symbols

Definition of a new component requires specification of a symbol to be used to represent the component when placed into a schematic. One of the standard symbols shipped with the product can be adequate for the new component. Usually, these are located in the application directories <installation directory>/circuit/symbols or <installation directory>/adsptolemy/symbols.

Often a new symbol must be created to properly represent the part. The symbol is constructed in the symbol view for the schematic, where the name of the design is used as the name of the symbol. For a parametric subnetwork design, the symbol view for the design itself can contain the desired symbol. After switching to the symbol view, the commands on the Drawing palette or Draw menu are used to create the symbol shape. Symbol pins representing Ports must be placed into the symbol, with the first pin located at the origin (0, 0).

Designing Component Palette Buttons

When new components are defined, a bitmap name can be specified to represent the component button in a palette. If the named icon does not exist, the component name is displayed on the button. To add a customized button to the component palette, a graphic to represent the component needs to be created, saved in the correct form, and placed in the appropriate directory.

On UNIX systems, any visual tool such as Icon Editor or xv will suffice and the bitmaps are saved as X bitmap files. On a PC, they can be created using any visual tool such as Paint or Microsoft Visual C++ and are saved in PC bitmap format. Regardless of the platform type or the tool used to create them, all bitmaps must have the following attributes:

The bitmap search path is defined at runtime by ADS via the environment variables XBMLANGPATH for UNIX platforms and WBMLANGPATH for PCs. Users can place bitmaps in predefined directories in the search path where they will be automatically found and displayed.
On UNIX platforms, the predefined directories are:

$HOME/hpeesof/custom/bitmaps - for individual user customization
$HPEESOF_DIR/custom/bitmaps - for site-wide customization
$HOME/hpeesof/circuit/bitmaps - for analog/RF customization
$HOME/hpeesof/de/bitmaps - for general PDE customization
$HOME/hpeesof/adsptolemy/bitmaps - for DSP related customization

On PCs the predefined directories are:

%HOME%\hpeesof\custom\bitmaps - for individual user customization
%HPEESOF_DIR%\custom\bitmaps - for site-wide customization
%HOME%\hpeesof\circuit\bitmaps - for analog/RF customization
%HOME%\hpeesof\de/bitmaps - for general PDE customization
%HOME%\hpeesof\adsptolemy\bitmaps - for DSP related customization

Developing Measured Component Libraries

A set of linear S-parameter measurement files can represent a library of parts for the simulator. This is accomplished by representing these as a library of parts that can be placed in a schematic. The complete set of S-parameter files would reside together in a directory. For example, the directory <home directory>/hpeesof/myparts/parts/circuit would hold a set of S-parameter files. In the same directory an AEL definition file, possibly named circuitcomponents, defines the components for the project environment, one component for each part, and the library group. The name of the directory is added to the AEL path for the SIMULATOR_AEL, directing the program to search and read the definition file when attaching to a project. The next time program is run, the new group name appears in the list of libraries in the schematic and layout windows. Any parts library would be handled in the same way.

The environment variable value for CIRCUIT_AEL is:

HOME_CIRCUIT_AEL={$HOME}/hpeesof/{%PROJECT1}/ael
where: PROJECT1=circuit and $HOME is your home directory on a UNIX platform.

Circuit components are defined in the file gemini.ael.

The circuit example, shown below, creates a library of S-parameter file components. The AEL definition file and the S-parameter files can be stored in the same directory and the directory is added to the CIRCUIT_AEL path. First, a message that the library is being loaded is displayed on the terminal window. Then a form set is created specifying that the value of the S-parameter component will be an S-parameter file name. Finally, a component definition is created for each S-parameter file. The standard EEFET1 symbol is used for the schematic symbol artwork. The component is presented to the simulator as an S2P element with the name of the S-parameter file as the value of the FILE parameter. The component description field is used to display the Vds and Ids values for the S-parameter file. This line, which clearly identifies these values, appears in the library list dialog box. The contents of the linear.ael file are shown below and the contents of the _d_0777.s2p_ file are shown in Measured Component Example Database.

Measured Component Library Example

Measured Component Example Database

Developing Discrete Valued Part Libraries

The Advanced System Design simulators have the capability of using discrete measurement data to simulate manufactured components with discrete values. Discrete measured data is provided in a Microwave Data Interchange Format (MDIF) file. The file organization allows the description of named sets of data, where each set represents a discrete value of a part. You can create a component definition in AEL that allows you to pick only valid discrete values for a part. For example, you can have measured data for a capacitor in the form of capacitance and series resistance for several nominal values of the capacitor, such as 20, 22, 24, 27, and 30 pf. These values are organized into a MDIF file, a subnetwork is created to model the physical part, and an AEL component definition is created that allows only the discrete values to be chosen for analysis in the subnetwork. Also, the simulator's discrete value optimizer uses only the valid discrete values.

To create a set of discrete values components for simulation:

Developing Discrete Valued Parts MDIF File

The values available for discrete valued parts are defined in a file using a subset of the Microwave Data Interchange Format (MDIF). This file format is used to define a variety of data for use by the simulators. The file to define discrete values contains a table of values, which are accessed by row index and column name. An example of a simple MDIF file format for discrete valued parts is:

REM This is an example file for discrete capacitors
BEGIN DSCRDATA
% PART C RS
20pF 20 2.1
22pF 22 1.9
24pF 24 1.75
27pF 27 1.56
30pF 30 1.4
END DSCRDATA

This example has five sets of values, where each set consists of two values. The REM line at the top of the file is an optional comment. The BEGIN DSCRDATA line marks the beginning of the data table and gives the table the required name DSCRDATA. The next line, beginning with a percent sign, names the columns in the data table. The name for the first column (PART) is not significant. This column contains the names for the rows used by the program when accessing a particular set of values. The names of the remaining columns are used to access the individual data values for a particular row. There must be at least one column of data values beyond the first column. The lines following define sets of data values, one row at a time, until the END DSCRDATA line ends the table. Only one data table is allowed in a file. For use by the local project, the MDIF file should be placed in the project's data subdirectory.

Designing a Discrete Valued Parts Parametric Subnetwork

The model for the discrete valued part is contained in a parametric subnetwork. The following figure shows the schematic for the discrete valued parts parametric subnetwork.

Discrete Valued Parts Parametric Subnetwork Schematic

Model components are placed and connected in the network in the usual way, except for the addition of references to the discrete data file. This involves adding a DataAccessComponent (DAC) and setting certain model component parameter values to refer to the DAC. One parameter for the subnetwork is used to represent the nominal value of the part.

Note
The units of the components placed in the schematic are assumed to be in SI units. To enter the value of capacitance in pF, you must edit the unit in the schematic and add pF to "file{DAC1, "C"}", as shown in the previous figure.

The basic requirements for designing a discrete valued parts parametric subnetwork are to define the subnetwork component, the symbol, and the subnetwork parameter for use as the nominal value.

  1. Create the subnetwork by placing and connecting the model components and the ports, as shown in in the previous figure. Save the design. In this example, chipcap is used as the design name.
  2. Select File > Design/Parameters and click General.
    • To save the new item in an existing custom library group, select the group from the Library Name list.
    • To save the new item in a new custom library group, select the Library Name field and enter the name. The default Library Name is "*", which indicates the current project. In this example, Sample Discrete Library Group is entered as the custom library.
  3. Select Parameters.
    • Select the Parameter Name field and enter the name. In this example C is entered as a parameter.
    • Set Parameter Type to Unitless.
    • The Value Type and Default Value are not important.
    • Save the AEL file by clicking Save AEL File. Then close the dialog by clicking OK.
  4. In the schematic window, place a DataAccessComponent (DAC) from the Data Items library. Open the Edit Component dialog by double-clicking on the DataAccessComponent (DAC) instance.
    • Set the File parameter to the name of the MDIF data file. Include the mdf extension.
    • Confirm that File Type = Discrete, to set the parameter values for certain components of the model which reference individual values from the data file. When this type is used, the instance name of the DataAccessComponent (DAC) and the name of the data column provide the link to the data file.
    • Confirm that InterpMode=Index Lookup and InterpDom=Rectangular.
    • Set the index parameter ( iVal1 ) to the subnetwork parameter used for the nominal value. When entering the Independent Variable Name or Cardinality value of iVar1, enter as @1 so that it will not appear in quotes.
  5. Open the Edit Component dialogs for components of the model and reference individual values from the data file, by selecting File Based Parameter Entry Mode and entering the appropriate Dependent Parameter Name, as shown in Discrete Valued Parts Parametric Subnetwork Schematic.
  6. Save the design.

After the parametric subnetwork has been created and saved, you must modify the AEL definition to make the part usable. When any design is saved, an AEL definition is created for the subnetwork so that it can be placed in another design. For parametric subnetworks that represent discrete parts, the AEL definition created above does not allow the part to be handled as a discrete valued part. You must modify the AEL definition each time the parameters for the network are modified. The modification is described in the section Discrete Valued Parts Required AEL Definitions.

Discrete Valued Parts Required AEL Definitions

The AEL component definition created when saving a parametric subnetwork must be modified in order for the network to be used as a discrete valued part. The following figure shows the modified AEL component definition for the subnetwork design in Designing a Discrete Valued Parts Parametric Subnetwork. In the figure, the lines you must modify are highlighted. In addition, you must remove the line:

library_group("*", "*", 1, "chipcap");

if you do not want the item to appear in the current project, but only to appear in the designated library group (in this example, Sample Discrete Library Group).


AEL Definition for Discrete Value Component

Supporting User-Defined Simulator Components

The Advanced Design System simulators support the capability for augmenting the built-in simulator element set with new components that you define by writing C language functions that are linked with the simulator object archive to produce a simulator executable.

Note
For details, refer to Building User-Compiled Analog Models in the User-Defined Models manual.

After the user-defined modules have been linked to the simulator, you need to create an AEL definition to place and use the element in a schematic. You accomplish this by creating a component for each user-defined element.

In AEL, user-defined components are described in the same way as built-in components. For each parameter of the element, a parameter definition is created using the create_parm() function. The parameters are added to the component using create_item(), along with the basic component definitions. Finally, the component is specified in a library group, or optionally, assigned to a palette group and given a bitmap.

An important consideration in describing the user-defined component is assuring the correct parameters. The parameters should match in order, name and type, between the AEL component description and those being used in the user-defined module. In particular the UserParamType array definition needs to match the parameters described by create_parm(). Also, the netlist string provided in the create_item() call needs to produce the proper simulator syntax. Unless the component has unusual parameters, the pre-defined standard_netlist string can be used.

Note
The netlist data string for all user-defined components should be either ELEMENT or DATA. ELEMENT should be used for user-defined components with one or more ports/pins, and DATA used for components with none.

In the following example, the standard U2PA element is defined. Only the definitions for the user-defined element are described here:

LOCAL UserParamType 
U2PA[] = 
{
    {"R1", REAL_data}, {"R2", REAL_data}, {"R3", REAL_data} 
};

LOCAL UserElemDef user_components[] = 
{
    {"U2PA", 2, sizeof(U2PA), U2PA, NULL, u2pa_y, thermal_n, NULL, NULL, NULL},
};

The corresponding AEL component definition for this element would be:

create_item( "U2PA", "User Defined Element", "I", NULL,NULL, "U2PA", 
      standard_dialog, "*", standard_netlist, "ELEMENT", standard_symbol, 
      "ARES", no_artwork, NULL, 
create_parm( "R1", "Resistance of R1", 0, "rvopt",1,1.000000), 
create_parm( "R2", "Resistance of R2", 0, "rvopt",1,1.000000), 
create_parm( "R3", "Resistance of R3", 0, "rvopt",1,1.000000),
));

In the component definition file, the component is defined as U2PA and the component ID prefix is I. The component uses the standard netlist format for components and the ARES symbol, which needs to be created. It has no associated artwork and has three optimizable parameters with the default value of 1.0.

Note
For details on creating a symbol, refer to Working with Symbols in the Schematic Capture and Layout manual.

Defining Artwork Creation Functions

If you have purchased the Layout option, you have the ability to define parameterized custom layout functions using AEL. The full power of the language is available, including artwork generation functions, math libraries, and data query functions.

Several AEL functions are especially useful for generating layout artwork:

db_factor()
de_ang_factor()
de_set_layer(n)
de_set_global_db_factor()
de_draw_rect(x, y, l, h)
de_draw_circ(x, y, r)
de_draw_text(f, x, y, h, a, string)
de_draw_port(x, y, a, n)
de_add_path()
de_add_polygon()
de_add_polyline()
de_end()
de_end_command()
de_draw_point(x, y)
de_draw_arc(x, y, a, f)

Artwork functions are assigned in the create_item() function. The name of the artwork function is set as the artwork data and the artwork type is set to artwork_macro or the integer 2.

Artwork functions use parameters passed into them to control the dimensions and features of the layout geometry. The basic requirement in all AEL artwork creation macros is that the parameters defined for the macro match the exact order of the parameters defined for the component. That is, the names of the parameters used in the macros defun statement do not need to match the component's, but the order of the parameters needs to match the order in which they are defined in the create_item() function. If W is defined before L in create_item(), then W is the first parameter passed in and L the second.

An AEL artwork macro can use all available AEL commands, including file I/O, string manipulation, data base query, lists, math functions, and can also call other AEL artwork functions. If you are constructing a library of artwork generation routines, you can build a set of AEL utilities to simplify tasks that are repeated in more than one function.

The basic format of the artwork function is similar to any AEL function. It is composed of a declaration section ( defun, followed by a list of parameters), followed by the function body. The function body can contain any number of AEL statements and usually contains a call to a draw function, as well as calls to draw port to create the component's ports. The number of ports needs to match that of any schematic symbol defined for the component. Further, port 1 should always be placed at the 0,0 point.

When using the polygon or polyline command functions to draw complex shapes, follow these by two or more de_draw_point() functions. The de_draw_point() functions should always be terminated with a call to the de_end() function, followed by the de_end_command(). This example draws a simple polygon:

.
.
.
de_set_layer(iDrawLayer);
de_draw_rect(0, -fWidth * 0.5, fLength, fWidth * 0.5 );
de_draw_port(0, 0, -90.0);
de_draw_port(fLength, 0, 90.0);
.
.
.

The simple artwork macro shown next creates a microstrip transmission line. The function is passed in the width and length of the transmission line as the second and third arguments (note the order of the parameter's fWidth is the same as in the create_item() function for the MLIN). The width and length parameters are then used to create a rectangle and specify the port 2 location. A more complete version of this macro can be found for in the <installation directory>/circuit/ael/ckt_linear_art.ael file.

defun MLIN(w,l)
{
de_set_layer(1);
de_draw_rect(0,-w*.5,l,w*.5);
de_draw_port(0,0,-90.0);
de_draw_port(l,0,90.0);
}

Creating a Library of Artwork Objects

Typically, many users have developed a library of artwork to use in designs, such as simple shapes used for drill holes, cover alignment, and mask alignment or parts developed for resistors, capacitors, FETs and other components.

Often, the former are not part of the active circuitry and are not simulated; however, the latter are active components that need to be simulated. The AEL definitions for these two types of objects differ, and the method for creating the supporting AEL can differ as well.

AEL for Simulated Components with Artwork

Generally, you would create new components that can be simulated by following the directions in the Layout manual. The method outlined there involves creating a schematic to represent the simulation model for the artwork.

However, a number of components have a one-to-one correspondence between a single simulator element and the artwork for the element. This is especially true with FETs, but is often true with lumped components and others. In this case it is simpler to create a new component definition using AEL, than to create a schematic with just this one element placed in it.

The basic idea is to copy the AEL create_item() definition for the built-in simulator element, rename and modify the definition to associate it with a artwork file or AEL artwork generation macro. Though the create_item() definition for a simulated component can look imposing, you only need to modify a few fields. Then, you add your new AEL files to the appropriate AEL configuration variable so the new components can appear in the library.

An example of the create_item() definition for a capacitor is described in the next section, Example Artwork Creation Functions.

Note the changed parameters in create_item() : the name, label, artwork type and artwork name in the fixed artwork example, plus the addition of a new parameter in the macro example. The artwork types are fixed, macro and none, the type can be set with the pre-defined variables no_artwork, fixed_artwork or macro_artwork.

If the type is fixed or macro, you need to supply the design file name (minus the .dsn extension) or the macro function name. If the type is a macro, be sure that you load the AEL file containing the macro, or you can include it with the component definition, as is done here.

For details on creating artwork macros, refer to the Schematic Capture and Layout manual. Note that the macro's parameters are exactly the same as the capacitor's. The names do not have to match, but the position of each parameter (their order in the list) does. You can use this example parameter definition for all layout-only parameters you wish to add to an component. Most likely, you will only need to change the parameter name and default value.

Finally, a library_group statement is added to associate the new components with a new library group. You can associate new components with an existing group or name a new group. You can have any number of library groups. If you want the components to show up in a palette as well, you can use the de_define_palette_group function to define a similar group for palettes.

All existing AEL definitions for a simulator are stored in the install directory. You should not modify these files directly, but copy the information you need to a new file and add the new file to the AEL search path.

Example Artwork Creation Functions

This example is a more complex artwork generation function that creates the CAPP2_Pad1 component. A number of supporting routines are included to demonstrate the use of generalized utility functions when creating a library of components. This function and the supporting code for Analog/RF designs can be found in these files:

The sample code is shown in the following figures.

Artwork Generation Function Example (ckt_lumped_item.ael)

Artwork Generation Function Example (ckt_lumped_item.ael)

Artwork Generation Data Example (ckt_linear_art.ael)

Artwork Data Example (destdart.ael)

Modifying AEL Configuration Variables

After you have created AEL definitions for a new library, you must modify the appropriate configuration variables for the file with the new definitions to be loaded automatically. Which variable you modify depends on who will use the definitions.

Using Pointers to find variable addresses

It is possible to access the address of a variable through the "&" operator. To access the contents of an address of the variable, you must use the "*" operator. These operators are the same as C. "&" signifies the address of a variable, and "*" signifies the contents of the variable.

This is most useful when passing parameters to AEL functions. When the address is passed to a variable rather than the variable itself, you can modify that parameter in the function, and the parameter will remain modified after the function. This functionality is the same as in C.

Below is an example of using the "&" and "*" in both a parameter and in a global context. Using the "&" and "*" in the global context if you wish to manipulate addresses of variables. This will not be discussed here, but can be studied from a C manual

Example:
defun modify(addr) 
{ 
fprintf(stderr,"addr = %s\n",identify_value(addr));   // prints "addr = <word>
fprintf(stderr,"original value of addr = %s\n",*addr);// prints "value of addr = 100
*addr = *addr + 100;
} 
decl val = 100;
fprintf(stderr,"address of val = %s\n",identify_value(&val));   // prints "address of val = <word> 
fprintf(stderr,"original value of val = %s\n",*(&val));// prints "value of val = 100
modify(&val);
fprintf(stderr,"new value = %d\n",val); // prints "new value = 200"
 

Privacy Statement  | Terms of Use  | Legal | Contact Us  | © Agilent 2000-2008 

Contents
Additional Resources