ADS Simulator Input Syntax

This topic provides information related to Advanced Design System's simulator (ADSsim). While this is not an all inclusive document with regards to ADSsim, the information provided here should help you accomplish tasks related to using the ADSsim in your development environment. The ADSsim is supported on the platforms specified in the installation documentation for your system, in the section "Check the System Requirements".

The simulator can be run from within the design environment, as well as from a command line. Before running the simulator, ensure that your system is ready to run the simulator by reviewing these topics:

• Setting Environment Variables
• Codewording and Security
• Running a Simulation from the Command Line

Setting Environment Variables

Before running the ADSsim, the following environment variables must be set:

Environment Variables Required for the ADS Simulator (ADSsim)

These environment variables tell your system the location of the ADS shared libraries/DLLs and device libraries. COMPL_DIR defines the location of component libraries. The COMPL_DIR variable typically uses the same value as HPEESOF_DIR unless the component libraries are located elsewhere. However, the majority of users should be able to set COMPL_DIR to the same value as HPEESOF_DIR.

To set the PC environment variables, use the following commands:

set HPEESOF_DIR =  <ADS_install_dir>
set COMPL_DIR   =  %HPEESOF_DIR%
set SIMARCH = win32       (for 64 bit PCs use win32_64)
set PATH = %HPEESOF_DIR%\bin;%HPEESOF_DIR%\bin\%SIMARCH%;%HPEESOF_DIR%\lib\%SIMARCH%;%HPEESOF_DIR%\adsptolemy\lib.%SIMARCH%;%PATH%

To set the UNIX environment variables using the Korn or Bourne Shells, add the following to your ~/.profile :

export HPEESOF_DIR =  <ADS_install_dir>
export COMPL_DIR = $HPEESOF_DIR
export SIMARCH = linux_x86  (for 64 bit machines use linux_x86_64)
export PATH = $HPEESOF_DIR/bin/$SIMARCH:$HPEESOF_DIR/bin:$PATH

To set the UNIX environment variables using the C Shell, add the following to your ~/.cshrc :

setenv HPEESOF_DIR  <ADS_install_dir>
setenv COMPL_DIR $HPEESOF_DIR
setenv SIMARCH linux_x86  (for 64 bit machines use linux_x86_64)
setenv PATH $PATH:$HPEESOF_DIR/bin/$SIMARCH:$HPEESOF_DIR/bin

Platform-Specific Variables

A platform-specific variable must also be set before running the ADS simulator. Be sure to set the variable to support the simulation mode you are using: 32-bit or 64-bit.

Red Hat Linux
32-bit:

export LD_LIBRARY_PATH="$HPEESOF_DIR/adsptolemy/lib.$SIMARCH:$LD_LIBRARY_PATH"
export LD_LIBRARY_PATH="$HPEESOF_DIR/lib/$SIMARCH:$LD_LIBRARY_PATH"

Where SIMARCH has been set equal to linux_x86 (see "To set the UNIX environment variables" above)

64-bit:

export LD_LIBRARY_PATH="$HPEESOF_DIR/adsptolemy/lib.$SIMARCH:$LD_LIBRARY_PATH"
export LD_LIBRARY_PATH="$HPEESOF_DIR/lib/$SIMARCH:$LD_LIBRARY_PATH"

Where SIMARCH has been set equal to linux_x86_64 (see "To set the UNIX environment variables" above)

Solaris 10
32-bit:

export LD_LIBRARY_PATH="$HPEESOF_DIR/adsptolemy/lib.$SIMARCH:$LD_LIBRARY_PATH"
export LD_LIBRARY_PATH="$HPEESOF_DIR/lib/$SIMARCH:$LD_LIBRARY_PATH"

Where SIMARCH has been set equal to sun58 (see "To set the UNIX environment variables" above)

64-bit:

export LD_LIBRARY_PATH="$HPEESOF_DIR/adsptolemy/lib.$SIMARCH:$LD_LIBRARY_PATH"
export LD_LIBRARY_PATH="$HPEESOF_DIR/lib/$SIMARCH:$LD_LIBRARY_PATH"

Where SIMARCH has been set equal to sun58_64 (see "To set the UNIX environment variables" above)

MS Windows
HPEESOF_DIR and PATH can be set using Control Panel > System > Advanced > Environment Variables, or by using a DOS batch file.
32-bit:

set PATH=%HPEESOF_DIR%\bin;%HPEESOF_DIR%\bin\%SIMARCH%;%HPEESOF_DIR%\lib\%SIMARCH%;%HPEESOF_DIR%\adsptolemy\lib.%SIMARCH%;%PATH%

Where SIMARCH has been set to win32 (see "To set the PC environment variables" above)

64-bit:

set PATH=%HPEESOF_DIR%\bin;%HPEESOF_DIR%\bin\%SIMARCH%;%HPEESOF_DIR%\lib\%SIMARCH%;%HPEESOF_DIR%\adsptolemy\lib.%SIMARCH%;%PATH%

Where SIMARCH has been set to win32_64 (see "To set the PC environment variables" above)

Codewording and Security

The ADSsim is a secured program that requires, at a minimum, a license for the E8881 Linear Simulator to run. Depending on the type of simulation, additional licenses may be required. Also, the license file location may require defining the variable AGILEESOFD_LICENSE_FILE. For more information on codewording and security, see the topic on setting up licenses in the installation documentation for your platform.

Running a Simulation from the Command Line

Besides using the design environment's user interface to run a simulation, you can also run a simulation from a command line using the hpeesofsim command. Before using this command, ensure your system is ready to run the simulator by reviewing these topics:

• Setting Environment Variables
• Codewording and Security

The ADSsim can be invoked using the following syntax:

hpeesofsim [-r output_rawfile_name] [netlist_inputfile_name]

A list of available options can be generated using the following command:

hpeesofsim -o

The netlist that ADSsim generates can be reviewed and modified.
ADS generates a netlist, every time you run a simulation. That netlist is named $HOME\<Project_name>\netlist.log.
So you can enter your design using the Schematic window, and create a netlist by running the simulation once (if you stop it before completion, the netlist will still be created) or by using the command line (ADS main window\Tools\Command Line). Enter the command:

de_netlist("your _design_name");

Note that the AEL command de_netlist needs that the name of the schematic be listed between quotes, inside parenthesis and with a semi-colon at the end of the line.

Another way to create a netlist is to open the schematic, select the menu "Dynamic Link" and choose "Top-Level Design Netlist". This will open a text editor window with the netlist entries listed. You can save the text and/or edit it. The Netlist doesn't need to be called netlist.log, you can use any other name, one matching the schematic it represents is recommended.

The following example is a netlist generated for a resistive PI pad:

Options ResourceUsage=yes UseNutmegFormat=no
TopDesignName="C:\apps\ads2005a\arf_0705_prj\networks\PI_pad"

R:R3 _net28 _net27 R=16 Ohm Noise=yes
R:R2 _net28 0 R=80 Ohm Noise=yes
R:R1 _net27 0 R=80 Ohm Noise=yes

S_Param:SP1 CalcS=yes CalcY=no CalcZ=no GroupDelayAperture=1e-4 FreqConversion=no
FreqConversionPort=1 StatusLevel=2 CalcNoise=no SortNoise=0 BandwidthForNoise=1.0 Hz

DevOpPtLevel=0 \
 SweepVar="freq" SweepPlan="SP1_stim" OutputPlan="SP1_Output"
 SweepPlan: SP1_stim Start=1.0 GHz Stop=10.0 GHz Step=0.1 GHz
 OutputPlan:SP1_Output \
 Type="Output" \
 UseEquationNestLevel=yes \
 EquationNestLevel=2 \
 UseSavedEquationNestLevel=yes \
 SavedEquationNestLevel=2

 Port:Term1 _net27 0 Num=1 Z=50 Ohm Noise=yes
 Port:Term2 _net28 0 Num=2 Z=50 Ohm Noise=yes

If the option -r output_rawfile_name is not given in the command, simulation results will be written to the spectra.raw file. Simulation results can be written to both a readable raw file and a binary dataset file. To create a readable raw file, you may need to modify the options listed at the beginning of the netlist. For example, if a netlist contains the options shown in this example:

Options ResourceUsage=yes UseNutmegFormat=no
TopDesignName="C:\my_projects\DataAccess_prj\networks\test.ds"

change the options line to:

Options ResourceUsage=yes UseNutmegFormat=no ASCII_Rawfile=yes
TopDesignName="C:\my_projects\DataAccess_prj\networks\test.ds"

TopDesignName is the name of the dataset file to be written, which is a binary file. You can use the dsdump command (located in $HPEESOF_DIR/bin) to view the dataset file as shown in this example:

dsdump test.ds

General Syntax

This topic uses the following typographical conventions:

Typographic Conventions

The ADS Simulator Syntax

The following sections outline the basic language rules. For details about restrictions concerning reserved names, see Reserved Names and Name Spaces.

Field Separators

A delimiter is one or more blanks or tabs.

Continuation Characters

A statement may be continued on the next line by ending the current line with a backslash and continuing on the next line.

Name Fields

A name may have any number of letters or digits in it but must not contain any delimiters or non alphanumeric characters. The name must begin with a letter or an underscore ( _ ).

Parameter Fields

A parameter field takes the form name = value, where name is a parameter keyword and value is either a numeric expression, the name of a device instance, the name of a model or a character string surrounded by double quotes. Some parameters can be indexed, in which case the name is followed by [i] , [i,j] , or [i,j,k] . i , j , and k must be integer constants or variables.

Node Names

A node name may have any number of letters or digits in it but must not contain any delimiters or non alphanumeric characters. If a node name begins with a digit, then it must consist only of digits.

Lower/Upper Case

The ADS Simulator is case sensitive.

Units and Scale Factors

The fundamental units for the ADS Simulator are shown in the following table. A parameter with a given dimension assumes its value has the corresponding units. For example, for a resistance, R=10 its assumed to be 10 ohms.

Fundamental Units in ADS

Recognizing Scale Factors

Variations on the fundamental units in ADS are referred to as scale factors . A scale factor is a single word that begins with a letter or an underscore character (_). The remaining characters, if any, consist of letters, digits, and underscores. The value of a scale factor is resolved using the following rules in the order shown:

1. If the scale factor exactly matches one of the predefined scale-factor words (see the following table), then use the numerical equivalent; otherwise, go to rule 2.

   Predefined Scale Factor Words

1. If the scale factor exactly matches one of the scale-factor units (see following table) except for m , then use the numerical equivalent; otherwise, go to rule 3.

   Scale Factor Units

1. If the first character of the scale factor is one of the legal scale-factor prefixes (see the following table), then use the numerical equivalent; otherwise, go to rule 4.

   Scale Factor Prefixes

1. The scale factor is not recognized.
   Important considerations include:
   • Scale factors are case sensitive.
   • A single m means milli , not meters .
   • A lower case f by itself means femto . An upper case F by itself means Farad .
   • A lower case a by itself means atto . An upper case A by itself means Ampere .
   • The imperial units ( mils , in , ft , mi , nmi ) do not accept prefixes.
   • The ADS simulator will report a warning if an unrecognized scale factor is encountered, and use a scale-factor value of 1.0.
   • It is not required that the characters following a scale-factor prefix match one of the scale-factor units.
   • There are no scale factors for dBm , dBW , or temperature. ADS functions are provided to convert these values to the corresponding fundamental units (Watts and Celsius).

Booleans

Many devices, models, and analyses have parameters that are boolean valued. Zero is used to represent false or no, whereas any number besides zero represents true or yes. The keywords yes and no can also be used.

Global Nodes

Global nodes are user-defined nodes which exist throughout the hierarchy. The global nodes must be defined on the first lines in the netlist. They must be defined before they are used.

General Form:

globalnode nodename1 [nodename2 ] [... nodenameN ]

Example:

globalnode sumnode my_internal_node

Device Pin Names

To support the schematic device pin names in a dataset, the device pin names are passed to the simulator through the netlist. For each unique device type in the design, the pin-mapping information is passed in the following format:

mapping {

pinMapping {

device-name pinMap pinMap

device-name pinMap pinMap

device-name pinMap pinMap

}

}

where pinMap is:

< integer >:"< pinName >"

Example:

mapping {
   pinMapping {
   R 1:"PLUS" 2:"MINUS"
   V_Source 1:"PLUS" 2:"MINUS"
   BJTM1 1:"c" 2:"b" 3:"e"
   C 1:"PLUS" 2:"MINUS"
   }
}

Additional information about mapping device pin names and the simulator syntax includes:

• The keywords mapping , pinCurrent , and pinMapping are reserved. They cannot be used as names for instances, nodes, variables, etc.
• The mapping block appears at the top level of the netlist. A mapping block cannot exist at the sub-circuit level. The mapping block can exist anywhere within the top level, preferably at the bottom or top of the netlist.
• Currently only one mapping and one pinMapping block can exist in a circuit.

Comments

Comments are introduced into an ADS Simulator file with a semicolon; they terminate at the end of the line. Any text on a line that follows a semicolon is ignored. Also, all blank lines are ignored.

Statement Order

Models can appear anywhere in the netlist. They do not have to be defined before a model instance is defined.

Some parameters expect a device instance name as the parameter value. In these cases, the device instance must already have been defined before it is referenced. If not, the device instance name can be entered as a quoted string using double quotes (").

Naming Conventions

The full name for an instance parameter is of the form:

[pathName].instanceName.parameterName[index]

where pathName is a hierarchical name of the form

[pathName].subnetworkInstanceName

The same naming convention is used to reference nodes, variables, expressions, functions, device terminals, and device ports.

For device terminals, the terminal name can be either the terminal name given in the device description, or tn where n is the terminal number (the first terminal in the description is terminal 1, etc.). Device ports are referenced by using the name pm , where m is the port number (the first pair of terminals in the device description is port 1, etc.).

Note that t1 and p1 both correspond to the current flowing into the first terminal of a device, and that t2 corresponds to the current flowing into the second terminal. If terminals one and two define a port, then the current specified by t2 is equal and opposite to the current specified by t1 and p1 .

Currents

The only currents that can be accessed for simulation, optimization, or output purposes are the state currents.

State currents

Most devices are voltage controlled, that is, their terminal currents can be calculated given their terminal voltages. Circuits that contain only voltage-controlled devices can be solved using node analysis. Some devices, however, such as voltage sources, are not voltage controlled. Since the only unknowns in node analysis are the node voltages, circuits that contain non-voltage-controlled devices cannot be solved using node analysis. Instead, modified node analysis is used. In modified node analysis, the unknown vector is enlarged. It contains not only the node voltages but the branch currents of the non-voltage-controlled devices as well. The branch currents that appear in the vector of unknowns are called state currents. Since the ADS Simulator uses modified node analysis, the values of the state currents are available for output.

If the value of a particular current is desired but the current is not a state current, insert a short in series with the desired terminal. The short does not affect the behavior of the circuit but does create a state current corresponding to the desired current.

To reference a state current, use the device instance name followed by either a terminal or port name. If the terminal or port name is not specified, the state current defaults to the first state current of the specified device. Note that this does not correspond to the current through the first port of the device whenever the current through the first port is not a state current. For some applications, the positive state current must be referenced, so a terminal name of t1 or t3 is acceptable but not t2 . Using port names avoids this problem. The convention for current polarity is that positive current flows into the positive terminal.

Integer Formats for Simulator Input

There are notation rules for simulator input of hex, octal and binary integer constants.

• Integers starting with "0x"/"0X" are read in hexadecimal format.
• Integers starting with "0b"/"0B" are read in binary format.
• Integers starting with "0" and not followed by any of [X,x,B,b] are read in octal format.
• Integers starting with [1-9] are read in decimal format.

Real numbers are always read in decimal format.

Instance Statements

General Form:

type [ :name ] node1 ... nodeN [ [ param=value ] ... ]
type [ :name ] [ [ param=value] ... ]

Examples:

ua741:OpAmp in out out
C:C1 2 3 C=10pf
HB: Distortion1 Freq=10GHz

The instance statement is used to define to the ADS Simulator the information unique to a particular instance of a device or an analysis. The instance statement consists of the instance type descriptor and an optional name preceded by a colon. If it is a device instance with terminals, the nodes to which the terminals of the instance are connected come next. Then the parameter fields for the instance are defined. The parameters can be in any order. The nodes, though, must appear in the same order as in the device or subnetwork definition.

The type field may contain either the ADS Simulator instance type name, or a user-supplied model or subnetwork name. The name can be any valid name, which means it must begin with a letter, can contain any number of letters and digits, must not contain any delimiters or non alphanumeric characters, and must not conflict with other names including node names.

Model Statements

General Form:

model name type [ [param = value ] ... ]

Examples:

model NPNbjt bjt NPN=yes Bf=100 Js=0.1fa

Often characteristics of a particular type of element are common to a large number of instances. For example, the saturation current of a diode is a function of the process used to construct the diode and also of the area of the diode. Rather than describing the process on each diode instantiation, that description is done once in a model statement and many diode instances refer to it. The area, which may be different for each device, is included on each instance statement. Though it is possible to have several model statements for a particular type of device, each instance may only reference at most one model. Not all device types support model statements.

The name in the model statement becomes the type in the instance statement. The type field is the ADS Simulator-defined model name. Any parameter value not supplied will be set to the model's default value.

Most models, such as the diode or bjt models, can be instantiated with an instance statement. There are exceptions. For instance, the Substrate model cannot be instantiated. Its name, though, can be used as a parameter value for the Subst parameter of certain transmission line devices.

Subnetwork Definitions

General Form:

define subnetworkName ( node1 ... nodeN )

[parameters name1 = [value1] ... name n = [value n ] ]

.
.
.

elementStatements

.
.
.

end [subnetworkName ]

Examples:

define DoubleTuner (top bottom left right)
parameters vel=0.95 r=1.0 l1=.25 l2=.25
tline:tuner1 top bottom left left len=l1 vel=vel r=r
tline:tuner2 top bottom right right len=l2 vel=2*vel r=r
end DoubleTuner
DoubleTuner:InputTuner t1 b2 3 4 l1=0.5

A subnetwork is a named collection of instances connected in a particular way that can be instantiated as a group any number of times by subnetwork calls. The subnetwork call is in effect and form, an instance statement. Subnetwork definitions are simply circuit macros that can be expanded anywhere in the circuit any number of times. When an instance in the input file refers to a subnetwork definition, the instances specified within the subnetwork are inserted into the circuit. Subnetworks may be nested. Thus a subnetwork definition may contain other subnetworks. However, a subnetwork definition cannot contain another subnetwork definition. All the definitions must occur at the top level.

An instance statement that instantiates a subnetwork definition is referred to as a subnetwork call. The node names (or numbers) specified in the subnetwork call are substituted, in order, for the node names given in the subnetwork definition. All instances that refer to a subnetwork definition must have the same number of nodes as are specified in the subnetwork definition and in the same order. Node names inside the subnetwork definition are strictly local unless they are global nodes defined with a globalnode statement. A subnetwork definition with no nodes must still include the parentheses ( ) .

Parameter specification in subnetwork definitions is optional. Any parameters that are specified are referred to by name followed by an equals sign and then an optional default value. If, when making a subnetwork call in your input file, you do not specify a particular parameter, then this default value is used in that instance. Subnetwork parameters can be used in expressions within the subnetwork just as any other variable.

Subnetworks are a flexible and powerful way of developing and maintaining hierarchical circuits. Parameters can be used to modify one instance of a subnetwork from another. Names within a subnetwork can be assigned without worrying about conflicting with the same name in another subnetwork definition. The full name for a node or instance include its path name in addition to its instance name. For example, if the above subnetwork is included in subckt2 which is itself included in subckt1 , then the full path name of the length of the first transmission line is subckt1.subckt2.tuner1.len .

Only enough of the path name has to be specified to unambiguously identify the parameter. For example, an analysis inside subckt1 can reference the length by subckt2.tuner1.len since the name search starts from the current level in the hierarchy. If a reference to a name cannot be resolved in the local level of hierarchy, then the parent is searched for the name, and so on until the top level is searched. In this way, a sibling can either inherit its parent's attributes or define its own.

Expression Capability

The ADS Simulator has a powerful and flexible symbolic expression capability which enables you to define variables, functions, and expressions in the netlist. These can then be used to define other functions and expressions to specify device parameters and optimization goals, etc.

Variables are your basic building blocks. For example, declaring "var1 = 2.5" assigns the value "2.5" to the variable "var1." Functions are simply parameterized variables such as F(x) =x+x**2. You can combine variables, constants, functions, and operators to form expressions. An expression can be a simple or complex series of variables, operators, and functions that evaluates to a single value. For example, y = abs(0.3-j*0.3) returns a value of 3.015.

The names for variables, expressions, and functions follow the same hierarchy rules that instance and node names do. Thus, local variables in a subnetwork definition can assume values that differ from one instance of the subnetwork to the next.

Functions and expressions can be defined either globally or locally anywhere in the hierarchy. All variables are local by default. Local variables are known in the subnetwork in which they are defined, and all lower subnetworks; they are not known at higher levels. Variables defined at the root (the top level) are known everywhere within the circuit. To specify a global variable, the global keyword must precede the variable name. The global keyword causes the variable to be defined at the root of the hierarchy tree regardless of the lexical location.

Examples:

global var1 = 2.718

The expression capability includes the standard math operations of + - / * ^ in addition to parenthesis grouping. Scale factors are also allowed in general expressions and have higher precedence than any of the math operators. For more information about units and scale factors, see Units and Scale Factors.

For complete information about variables, constants, available functions, and using them to define simulator expressions, see the Simulator Expressions documentation.

C-Preprocessor

Before being interpreted by the ADS Simulator, all input files are run through a built-in preprocessor based upon a C preprocessor. This brings several useful features to the ADS Simulator, such as the ability to define macro constants and functions, to include the contents of another file, and to conditionally remove statements from the input. All C preprocessor statements begin with # as the first character.

Unfortunately, for reasons of backward compatibility, there is no way to specify include directories. The standard C preprocessor `` -I '' option is not supported; instead, `` -I '' is used to specify a file for inclusion into the netlist.

File Inclusion

Any source line of the form

#include "filename"

is replaced by the contents of the file filename . The file must be specified with an absolute path or must reside in either the current working directory or in /$HPEESOF_DIR/circuit/components/.

Library Inclusion

The C preprocessor automatically includes a library file if the -N command line option is not specified and if such a file exists. The first file found in the following list is included as the library:

$HPEESOF_DIR/circuit/components/gemlib
$EESOF_DIR/circuit/components/gemlib
$GEMLIB
.gemlib
~/.gemlib
~/gemini/gemlib

A library file is specified by the user using the -I filename command line option. More than one library may be specified. Specifying a library file prevents the ADS Simulator from including any of the above library files.

Macro Definitions

A macro definition has the form;

#define name replacement-text

It defines a macro substitution of the simplest kind--subsequent occurrences of the token name are replaced by replacement-text . The name consists of alphanumeric characters and underscores, but must not begin with a numeric character; the replacement text is arbitrary. Normally the replacement text is the rest of the line, but a long definition may be continued by placing a "\" at the end of each line to be continued. Substitutions do not occur within quoted strings. Names may be undefined with

#undef name

It is also possible to define macros with parameters. For example,

#define to_celcius(t) (((t)-32)/1.8)

is a macro with the formal parameter t that is replaced with the corresponding actual parameters when invoked. Thus the line

options temp=to_celcius(77)

is replaced by the line

options temp=(((77)-32)/1.8)

Macro functions may have more than one parameter, but the number of formal and actual parameters must match.

Macros may also be defined using the -D command line option.

Conditional Inclusion

It is possible to conditionally discard portions of the source file. The #if line evaluates a constant integer expression, and if the expression is non-zero, subsequent lines are retained until an #else or #endif line is found. If an #else line is found, any lines between it and the corresponding #endif are discarded. If the expression evaluates to zero, lines between the #if and #else are discarded, while those between the #else and #endif are retained. The conditional inclusion statements nest to an arbitrary level of hierarchy. The following operators and functions can be used in the constant expression;

The #ifdef and #ifndef lines are specialized forms of #if that test whether a name is defined.

Data Access Component

The Data Access Component provides a clean, unified way to access tabular data from within a simulation. The data may reside in either a text file of a supported, documented format (e.g. discrete MDIF, model MDIF, Touchstone, CITIfile), or a dataset. It provides a variety of access methods, including lookup by index/value, as well as linear, cubic spline and cubic interpolation modes, with support for derivatives.

The Data Access Component provides a "handle" with which one may access data from either a text file or dataset for use in a simulation. The DAC is implemented as a cktlib subnetwork fragment with internally known expressions names (e.g. DAC, _TREE) that are assigned via _VarEqn calls such as read_data() and access_all_data() . The accessed data can be used by other components (including models, devices, variables, subnetwork calls and other DAC instances) in the netlist, either by the specific file syntax or via the VarEqn function dep_data() .

The DAC can also be used to supply parameters to device and model components from text files and datasets. In this case, the AllParams device/model parameter is used to refer to a DAC component. The component's parameters will then be accessed from the DAC and supplied to the instance. Care is taken to ensure that only matching (between parameter names in the component definition and DAC dependent column names) data is used. Also, parameter data can be assigned "inline" - as is usually done - in which case the inline data takes precedence over the DAC data.

As the DAC component is composed of just a parameterized subnetwork, it allows alterations (sweep, tune, optimize, yield) of its parameters. Consequently any component that uses DAC data via file, dep_data() or AllParams will automatically be updated when a DAC parameter is altered. A caveat with sweeping over files using AllParams is that all the files must contain the same number of dependent columns of data.

Below is an example definition of a simple DAC component that accesses discrete values from a text file:

#uselib "ckt" , "DAC"
DAC: DAC1  File="C:\jeffm\ADS_testing\ADS13_test_prj/.\data\SweptData.ds"
Type="dataset" Block="S" InterpMode="linear" InterpDom="ri" iVar1="X"
iVal1=X iVar2="freq" iVal2=freq
S_Port:S2P1  _net1 0 _net6 0 S[1,1]=file{DAC1, "S[1,1]"}
S[1,2]=file{DAC1,"S[1,2]"} S[2,1]=1 S[2,2]=0 Recip=no

dindex = 1
DAC:atc1 File="vdcr.mdf" Type="dscr" \
InterpMode="index_lookup" iVar1=1 iVal1=dindex

And its use to provide the resistance value to a pair of circuit components:

R:R1 n1 0 R=file{atc1, "R"} kOhm
R:R2 n1 0 R=dep_data(atc1, "R") kOhm
Here, it provides the value to a variable:
V1 = file{atc1, "Vdc"}

V1 could be used elsewhere in the circuit, as expected.

In this example, a scaling factor applied to the result of a DAC access is shown:

File = "atc.mdf"
Type = "dscr"
Mode="index_lookup"
Cnom = "Cnom"
DAC:atc_s File=File Type=Type InterpMode=Mode iVar1=1 iVal1 = Cs_row
C:Cs n1 n2 C=file{atc_s, Cnom} Pf}}

In this example, a use of AllParams is shown to enter model parameters from a text file:

File = "c:\gemini\vdcr.mdf"
Type = "dscr"
Mode="index_lookup"
DAC:dac1 File=File Type=Type InterpMode=Mode iVar1=1 iVal1 = ix
model rm1 R_Model R=0 AllParams = dac1._DAC
rm1:rm1i1 n3 0

Reserved Names and Name Spaces

When developing a netlist using the ADS simulator syntax, there are several different places in a netlist where names must be supplied, such as instance names and variable names. When selecting names, be sure that you do not use a reserved name (keyword).

There are six name categories: design/subnetwork, instance, parameter, model, variable, and node. These are known to the simulator as name spaces. Additionally, there are five reserved name groups. Each name space has one or more reserved name groups associated with it. This means that when choosing a name for a category such as a parameter name, you cannot use any of the names in the reserved name groups associated with the parameter name space.

When a user-entered name is parsed, it is checked to see that is not in the group of reserved names associated with the name space in which it is used. If the user-entered name matches a reserved name, the simulator will issue an error message and terminate. The simulator is case-sensitive, so the case of characters in a name must match, as well as the characters themselves.

The following tables provide details about the six name spaces, their associated reserved name groups, and lists of the individual reserved names. At the end of the section is a complete alphabetical listing of all reserved names. In addition to these lists, any built-in component name should not be used as a design/subnetwork name. Refer to the component catalogs for the built-in component names.

• For a list of the name spaces with descriptions, examples, and their associated reserved name groups, see the table ADS Simulator Namespaces and Associated Reserved Name Groups.
• For a list of reserved names composing each reserved name group, see these tables:
  • Parser Reserved Names Group
  • Reserved Names Group
  • Predefined Expression Reserved Names Group
  • Predefined Variable Reserved Names Group
  • Predefined Function Reserved Names Group
• For an alphabetical listing of reserved names, see the table ADS Reserved Words - Alphabetical List.

ADS Simulator Namespaces and Associated Reserved Name Groups

Parser Reserved Names Group

Reserved Names Group

Predefined Expression Reserved Names Group

Predefined Variable Reserved Names Group

Predefined Function Reserved Names Group

ADS Reserved Words - Alphabetical List