Hspice Netlister Example
This chapter provides an example for creating a custom dialect from the base netlist format shipped with Front End Flow. The HSpice netlist code configured in this example is shipped with Front End Flow. Many of the functions in Front End Flow are provided in source form to allow you to create your own netlist dialect by modifying some key functions.
To create a custom dialect, perform the following steps:
- Creating the New Dialect Directories and Files".
- Modifying the Configuration File as Needed".
- Modifying the Netlisting Functions as Needed".
- Creating Component Definitions".
- Verifying the Netlist".
Creating the New Dialect Directories and Files
The first step for making a new netlisting dialect is to create the directories so that Front End Flow recognizes the new dialect.
As was noted in Adding a Tool, Front End Flow checks the variable CNEX_COMPONENT_PATH to locate the Front End Flow tools. Adding in an HSpice directory in one of the component path directories allows Front End Flow to recognize the new HSpice dialect.
Adding a new dialect requires the following three items:
- The component definitions
This requires making a component definition directory. - Creating or overriding AEL definitions
This requires making a code directory to contain the AEL files. - Writing a configuration file
This requires making a new configuration file that sets global netlisting variables different from the default settings.
Making the Component Directory
While the test component definitions are under development, place them in a directory that will only be visible to the developer. To do this, put the definitions in {%CNEX_HOME_DIR}/components .
Once the definitions are finished, move them to another directory, such as {%CNEX_CUSTOM_DIR}/components , or a design kit directory. You could also add your own directory to CNEX_COMPONENT_PATH by editing the CNEX.cfg file. This allows you to development in your own directory, for example, $HOME/development/netlist_exp/components/{%CNEX_TOOL} .
For this example, an HSpice directory is created in $HOME/hpeesof/netlist_exp/components which corresponds to {%CNEX_HOME_DIR}/components . Place all of the test component definitions in this directory. When the development is finished, move them to an appropriate central directory.
Creating the Source Code Directory
In addition to creating component definitions, there are functions you must override to make the HSpice netlist dialect work. Put the AEL functions to override in a file in their appropriate home directory. The configuration variable CNEX_COMPONENT_PATH defines where Front End Flow will look for AEL files. That location is {%CNEX_HOME_DIR}/ael/{%CNEX_TOOL}. You are developing a CNEX_TOOL called HSpice . Therefore, you make a directory called HSpice at $HOME/hpeesof/netlist_exp/ael .
Creating the HSpice Configuration File
In addition to overriding functions and creating component definitions, you must also make a configuration file for HSpice. CNEX_COMPONENT_PATH searches for component files with the name type CNEX_config.{%CNEX_TOOL}. We have been using home directories to place our development files, so use {%CNEX_HOME_DIR}/config for the location for making the new configuration file.
It is easier to modify an existing configuration file than to write a completely new one. Use CNEX_config.dracula as the basis for the new HSpice configuration file because Dracula uses HSpice style netlists. Copy CNEX_config.dracula from {%LVS_INSTALL_DIR}/config to {%LVS_HOME_DIR}/config/CNEX_config.HSpice . This satisfies the need to have a configuration file with the name CNEX_config.{%CNEX_TOOL} so that CNEX_COMPONENT_PATH can find it.
Modifying the Configuration File as Needed
The netlisting configuration file is discussed in CNEX_config Configuration File. Compare each of the configuration variables with the with the documentation of the tool you are supporting to determine which, if any, of the configuration variables need to be modified.
Refer to Configuration Files and use the following example as a checklist for your custom dialect. This example uses HSpice as the custom dialect.
- Is HSpice dialect case sensitive?
No. Set CASE_INSENSITIVE_OUTPUT to TRUE . - Is a component instance separator needed?
No. Leave it blank. - Are there any nodes in ADS that should be set to equivalent nodes in HSpice?
No. Therefore do not add EQUIV lines to the file. - Are there any expressions in ADS that are different in HSpice?
Yes. you need to map the ADS expressions to the corresponding HSpice expressions. For example, the function ln is log in HSpice, so you map the expression as EXPRESSION_MAPPING = ln log . Also, the ADS function log is equivalent to HSpice's log10 . Map that expression as EXPRESSION_MAPPING = log log10 . Map any other expressions required by the tool you are using. - Does HSpice require an expression delimiter?
Yes. HSpice expressions are required to be enclosed in single quote marks. Set EXPRESSION_START to `, and also set EXPRESSION_END to `. - Does HSpice have a particular node that is ground?
Yes. Node 0 is always ground in HSpice. Set the variable GROUND to 0 . - What character is used to designate a comment line for HSpice?
HSpice uses the * character at the start of a line to designate the line as a comment. Set LINE_COMMENT to *. - What is the continuation character?
The continuation character in HSpice is + . It is placed at the beginning of the following line. Set the variable LINE_CONTINUATION_CHARACTER to +. Because the continuation character must be at the beginning of the following line, set LINE_CONTINUATION_MODE to 0 . - Does HSpice have a maximum line length?
HSpice input line can be a maximum of 1024 characters. Set MAX_LINE_LENGTH to 1024 . - Does HSpice allow numeric node names?
Yes. However, names that begin with a number ignore any alphabetic characters after the numbers. This is not true in ADS. Therefore, use numeric node names that are prefixed. Set the NUMERIC_NODE_PREFIX to _net in order to be consistent with ADS. - Does HSpice support engineering notation?
Yes. Since engineering format is easier to read, set SCALAR_TO_SCIENTIFIC to FALSE . - Do the HSpice engineering notations match the ADS engineering notations?
Not in all cases. HSpice does not list their scaling factors in the documentation. This is something that must be determined by experimentation.
Once all of the configuration variables are set, you have the basis for your custom netlist exporter. Next, you need to customize the functions so they will work properly for your tool.
Modifying the Netlisting Functions as Needed
A good approach to modifying the netlisting functions is to create one component definition file utilizing each function that you are going to modify. This will allow to test each function as you write it.
In Creating the Source Code Directory, we specified that {%CNEX_HOME_DIR}/ael/HSpice is the development directory. We will now make a new file, cnexNetlistFunctions.ael , in that directory. This serves as the customization file for netlisting functions. Once the file is created, it will always be loaded as long as HSpice is selected as the netlisting tool.
The modification process consists of the following steps:
To test your component definition file perform the following steps:
- With ADS running, place a component in the schematic.
- Create a Front End Flow netlist to test your function.
The function file is always reloaded each time a netlist is created. - Test the function as appropriate for the function, for example, review the netlist or simulate a circuit.
Modifying Instance Functions
Front End Flow provides eight instance netlisting functions.
To determine what the current function outputs and if modification is required, perform the following steps:
- Place ADS standard components on a schematic and netlist them with the Dracula tool selected.
- Check the output to determine if modification is required.
- Determine if the component configuration or the function requires modification.
Note
If you are not certain if the component or the function requires modification, modify the configuration first. It is easier to modify components.Before testing, start ADS and create a new project so that no pre-existing information is used. For the example in this chapter, a new project, HSpiceSetup_aprj , is created. Next, a new design is created with the name test1 .
The cnexNetlistInstance Function
The next step is to find out what the current function exports for a known device and what HSpice needs for that device. For simplicity, the following example uses a capacitor as the template component.
To get an initial HSpice definition for the component, copy the Dracula definition into the HSpice components directory.
- Place a capacitor, component C , in the ADS test1 schematic.
- Consult the HSpice documentation. According to the documentation, the following is the general format for an element:
elname <node1 node2 ... nodeN> <mname>
+ <pname1=val1> <pname2=val2> <M=val>
The following is the specific format for a capacitor:
Cxxx n1 n2 <mname> <C=>capacitance <<TC1=>val> <<TC2=>val>
+ <SCALE=val> <IC=val> <M=val> <W=val> <L=val>
+ <DTEMP=val> - Find out what the current function returns. Bring up netlisting dialog box, and select HSpice as the tool. Select the View netlist file when finished check box, and the create a new netlist by clicking OK . The resulting netlist line for the capacitor is as follows:
cc1 _net2 _net1 C=1pF
This matches the HSpice requirement.
You may want to use more complex components to verify more outputs. However, in this example, the cnexNetInstance function output is the same as that required by HSpice. Therefore, for the capacitor component, HSpice does not need an override of the cnexNetlistInstance function.
The cnexSubcircuitInstance Function
To test the outputs of this function, first make a subcircuit, then follow the procedure below.
| Note This example shows what to do if your first test case does not show needed parameter output information. |
Make a subcircuit by placing two ports in test1 design and connecting them to the capacitor that was placed to test the cnexNetlistInstance function.
- Create a symbol by using View > Create/Edit Schematic Symbol from a schematic window.
This creates a new two port symbol for the test1 component. - Save that design and then create a new design, test2 .
- Place one instance of test1 in the test2 design.
- Check the HSpice documentation for the definition of a subcircuit. According to the HSpice manual, the following is the definition for a subcircuit call:
Xyyy n1 <n2 n3 ...> subnam <parnam= val ...> <M= val >
The subcircuit does not have parameters; therefore, the test will not give you output information. You must add a parameter to the test. - Select File > Design Parameters from the schematic window.
The Design Parameters dialog will appear. - Select the Parameters tab, and create a new parameter called C with a default value of 1 p . Set the parameter type to Capacitance . Add the parameter and save the design.
- Go back to the top level, delete the instance of test1 and place it again on the schematic. It now has a parameter, C .
- Netlist the design. The result for the test1 instance is as follows:
xx1 _net1 _net2 test1 C=1p
This output matches the HSpice requirements, so you do not need to make any changes.
The cnexGlobalNodeInstance Function
To place a GlobalNodeInstance , select the menu option Insert > Global Node .
Add a new global node, g1 , to the global node list, and put a wire label on one of the pins of the test1 instance.
According to the HSpice manual, global nodes are designated in HSpice by outputting a .global directive. Thus, to netlist the GlobalNodeInstance correctly, it must create a .global option in the HSpice netlist.
After placing the global node and creating a new netlist, the result is as follows:
.global g1
This matches the HSpice requirement, so you do not need to add any changes for cnexGlobalNodelInstance in the custom cnexNetlistFunctions file for HSpice.
The cnexVariableInstance Function
- Place a variable instance by inserting a VAR component.
- Set up three variables in the VAR component: C1=2p , C2=3p , and C3=C1+C2 .
To create a parameter, the HSpice manual states to use the following syntax:
.PARAM <SimpleParam> = <value>
.PARAM <AlgebraicParam> = 'SimpleParam*8.2' - A netlist is created and gives the following results:
.param C1=2p
.param C2=3p
.param C3='C1+C2'
This is what HSpice expects. Again, the function does not have to be overridden.
The cnexShortInstance Function
Do not override this function.
It takes the output of multiple nodes and replaces all future occurrences of the nodes with one equivalent node, usually the first node of the component.
Use this function on tline components, if you want to use the HSpice transmission line component.
The cnexShortMultiportInstance Function
Do not override this function.
It will take the instance list, match the pairs of nodes to each other, and short-circuit the node pairs. The first node in the pair becomes the name used whenever the second node in the pair is encountered anywhere in the current subcircuit.
The cnexUnknownInstance Function
You do not need to override this function.
This function outputs a comment for a component that does not have an HSpice definition.
Modifying Header and Footer Functions
So far in the example none of the default instance netlisting functions were incorrect for the HSpice netlister. The cnexNetlistFunctions.ael file is still empty, except for the comment line that has been placed to indicate that this file is customization for HSpice.
Next are the header functions. These functions create the lines output at the beginning of the netlist, the beginning of the top cell, and the beginning of each subcircuit. The footer functions take care of what is output at the end of the netlist, the end of the top cell, and the end of each subcircuit definition.
The cnexOutputSubcircuitHeader Function
This function returns the subcircuit definition line.
The HSpice manual specifies that a proper definition as follows:
.SUBCKT subnam n1 < n2 n3 ...> < parnam=val ...>
The test2 circuit already has a subcircuit placed in it, test1 . The netlist you generated gives the following for the test1 subcircuit definition:
.subckt test1 _net3 _net1 C=1p
The output is correct for HSpice: the .subckt was output, the nodes are there, and the parameter definition is correct.
The cnexOutputSubcircuitFooter Function
This function outputs the end of a subcircuit definition.
The HSpice manual specifies the following end of a subcircuit definition:
.ENDS < _SUBNAM_ >
The netlist generated from testing using cnexOutputSubcircuitHeader , returns the following:
.ends test1
This is a proper subcircuit ending for HSpice. This function does not need to be changed.
The cnexOutputTopcellHeader Function
The top cell header appears at the beginning of the output for the top level circuit. In this example, test2 is the top cell. For HSpice, nothing needs to be set for a top cell. Components can be placed outside of a subcircuit definition, and HSpice recognizes them as being in the top cell.
To run a test, you need to have simulation directives in the top level. If you look at the netlist, you can see the following subcircuit definition for the top cell:
.subckt test2
This is valid for Dracula, but not for HSpice. This function needs to be changed so it works for HSpice.
Look in the file cnexNetlistFunctions.ael in {%LVS_INSTALL_DIR}/ael . The current function definition is as follows:
defun cnexOutputTopcellHeader(designName, dsnH)
{
return(cnexOutputSubcircuitHeader(designName, dsnH));
}
The Dracula code calls the cnexOutputSubcircuitHeader function so that it creates the top cell as if it were a subcircuit. HSpice does not want any top cell output, so write a new function in the custom cnexNetlistFunctions.ael file that looks like this:
defun cnexOutputTopcellHeader(designName, dsnH)
{
return("");
}
This function returns an empty string instead of a subcircuit top cell header.
The cnexOutputTopcellFooter Function
The top cell footer is output after all of the instance definitions for the top cell have been created. In the example, test2 subcircuit is the top cell. Checking the netlist file, you see that there is no top cell header for test2 because of the new cnexOutputTopcellHeader . However, there is still an end directive for test2 . The cnexOutputTopcellFooter function must be overridden so that there is no footer.
Examine the original code. The default definition is as follows:
defun cnexOutputTopcellFooter(designName, dsnH)
{
return(cnexOutputSubcircuitFooter(designName, dsnH));
}
For this example, put in spacing after the end of the top cell and no end subcircuit definition. To do this, the new function definition becomes the following:
defun cnexOutputTopcellFooter(designName, dsnH)
{
return("n");
}
This overrides the default function so that an empty new line is output at the end of the top cell instances.
The cnexExportNetlistHeader Function
The netlist header function outputs the first lines of the netlist. It takes care of outputting options, including files and includes any comments. The default of this option already supplies the correct output for HSpice. Therefore, you do not need to change it.
The cnexExportNetlistFooter Function
This function is called to output lines that appear at the end of the file. For HSpice, the netlist places an .end directive at the end of the file. Anything after the .end is treated as comments. The default cnexExportNetlistFooter function places an .end directive. Therefore, you do not need to change the function.
Creating Component Definitions
Now you should set up all of the components needed for your process and your simulation needs. This chapter deals with components that are delivered with ADS. Your foundry kit components should fall into these categories. Because ADS has hundreds of components. This chapter shows only one example in each component category.
Primitive Components
A primitive component is a component that is netlisted and uses one of the built-in simulator components. It has no hierarchy and does not need a model because the parameters of the component represent all of the information needed to define the component.
This example uses a capacitor as a primitive. Before you start, gather the following information:
- The simulator component used by the component in ADS
- The pin count and order used by the component in ADS
- The parameters that the component has in ADS, and whether they are netlisted or not
The Dracula definition is not identical to the HSpice definition.
You have the following information: - It netlists as a capacitor.
- The pins are 1 and 2, and the order is not important.
- The parameters are C , Temp , Tnom , TC1 , TC2 , wBV , InitCond , Model , Width , Length , and _M .
Consult the HSpice documentation to find the following capacitor primitive definition:
Cxxx n1 n2 <mname> <C=>capacitance <<TC1=>val> <<TC2=>val> \+ <SCALE=val> <IC=val> <M=val> <W=val> <L=val> \+ <DTEMP=val>
or
Cxxx n1 n2 <C=>'equation' <CTYPE=val> <above options...>
or a polynomial form:
Cxxx n1 n2 POLY c0 c1... <above options...>
The second and third definitions do not match the ADS ones. The ADS capacitor is set up to match the first definition.
Now that the target format is known, you can edit the definition. In Component Definitions, two ways of editing a component definition are discussed, using the GUI and editing the file directly. If you have many components to edit, it is easier to edit the text files directly. The GUI is best if you edit one component at a time.
This chapter uses the text editor approach. Open the file C.cnex in a text editor.
Modifying the Component Definition Parameters
Set up the function. For the example in this chapter, based on the functions available and the fact that this is not a subcircuit, cnexNetlistInstance is the right function to use.
In HSpice a capacitor device name must be prefixed with a C . The Component_Name field can also be left unchanged, because it is already set to C .
Because this is an ideal capacitor, it does not matter which terminal is negative or positive. Based on the ADS symbol, pin 1 is the negative terminal. If polarity is important, you must change the pin association.
Now, you must find out which parameters to netlist, how to map their names into the proper HSpice names, and if any value mapping needs to be done for the parameters. Base this on reading the manual and comparing the parameters for ADS and HSpice.
Additionally, you need to determine which parameters are important for your design. If temperature is not important, do not output them.
HSpice requires the parameters output in the following order:
Model, C, TC1, TC2, SCALE, IC, M, W, L, and dtemp
Of these parameters, all must be explicitly named, except for Model , which does not have a name, and C , where the name is optional.
ADS does not have an equivalent for the parameter SCALE . Discard that parameter. ADS has a parameter, wBV , which does not correspond to any HSpice parameter. Do not use it.
The parameter dtemp , the difference in component temperature from circuit temperature, is not the same as Temp , which is the absolute temperature of the component. You must write a function to output the dtemp parameter.
The ADS parameters InitCond , Width , Length , and _M have definitions that match HSpice parameters IC, W, L , and M, but have different names. You must map these names.
The new Parameters line is set to the following:
Parameters = Model C TC1 TC2 InitCond _M Width Length Temp
| Note The parameters line specifies the ADS parameter name, not the HSpice parameter name. |
The parameter Model should output without <param name>= for its value. To do this mapping, a the following parameter name-mapping line is placed:
Parameter_Name_Mapping = Model
Because there is only a single value, the name Model is mapped to an empty string. This means that the function will not output a left hand side for the value.
The parameters C , TC1 , and TC2 do not need to be mapped. There is nothing is put into the file for them.
The parameters InitCond , _M , Width , Length , and T emp need to be mapped. The following lines are added to handle these parameters:
Parameter_Name_Mapping = InitCond IC Parameter_Name_Mapping = _M M Parameter_Name_Mapping = Width W Parameter_Name_Mapping = Length L Parameter_Name_Mapping = Temp DTEMP
The ADS parameter Temp is mapped to dtemp , but their values are not identical. In Adding Value Mapping Functions, the process for writing a value mapping function is described. In this case, the following code returns the correct value for dtemp . The ADS parameter value contains the absolute value temperature value placed in ADS. The parameter -temper contains the circuit value. If you subtract -temper from value , you get the differential temperature, the value needed for the HSpice parameter dtemp . Set up the function to take the ADS parameter value , and return the appropriate HSpice value to go into dtemp : as follows
defun hspiceModifyTemp(value)
{
decl returnVal;
returnVal=strcat("'", value, "-temper'");
return(returnVal);
}
To make the Temp function use the value, enter the following line:
Parameter_Type_Mapping = Temp hspiceModifyTemp
The component must now be netlisted. Open test1 schematic, which already has a C component placed.
However, if a parameter does not have a value, it will not be output. Therefore, it is necessary to set values for all of the parameters so that they are netlisted correctly. So, C is set to 1.0pF, Temp is set to 27, TC1 is set to .1, TC2 is set to .01, InitCond is set to 1, Model is set to CTest, Width is set to 10u, Length is set to 10u, and _M is set to 2. Then a netlist is created as follows:
cc1 _net5 _net4 Ctest C=1pF TC1=0.1 TC2=0.01 IC=1 M=2 W=10um L=10um DTEMP='27-temper'
This matches what the output that HSpice requires.
Components that Access Models
Most active devices and some passive devices use components that contain additional parameters for the instance. These auxiliary parameters can be shared among all of the various instances that are similar. These auxiliary components are called models .
Some tools, such as ADS and Spectre, treat the model component as a user defined component. When the instance is netlisted, instead of using a component name, such as BJT , they use the model name.
Other tools, like HSpice, specify the component name the same as they do for a primitive. The model is just another parameter.
This is an example of setting up a tool for HSpice. Therefore there is no difference between a component that accesses a model and one that does not.
As another example, here is how to set the ADS BJT NPN component. As you would for a primitive, gather the following information:
- The simulator component used by the component in ADS
- The pin count and order used by the component in ADS
- The parameters that the component has in ADS, whether they are netlisted or not
If these devices netlist differently into your tool because of the model, you should also get the following information:
- The name of the model parameter
- The type of models that are valid for the component
For this example, you want to netlist BJT_NPN , and make it be a Gummel Poon BJT NPN device for HSpice.
According to the HSpice manual, the following is the format for the BJT:
Qxxx nc nb ne <ns> mname <area> <OFF> <IC = vbeval,vceval> + <M = val> <DTEMP = val>
or
Qxxx nc nb ne <ns> mname <AREA = area> <AREAB = val> + <AREAC = val> <OFF> <VBE = vbeval> <VCE = vceval> <M = val> + <DTEMP = val>
For HSpice, model is not a distinct element, its a parameter. This means that cnexNetlistInstance is fine. Netlist_Function is set to cnexNetlistInstance .
The component name for an HSpice BJT component is Q , whether it is NPN or PNP . The model designates the implanting type for the component. The Component_Name parameter is set to Q .
The HSpice pin order in this case is collector, base, emitter, with an optional substrate. The ADS symbol has three unnamed pins; 1, 2, and 3. The ADS symbol graphic shows that pin 1 is the collector, pin 2 is the base, and pin 3 is the emitter. Since we need HSpice's node order to be collector, base, emitter, the Terminal_Order variable is set to 1 2 3.
The ADS symbol has the parameters Model , Area , Region , Temp , Mode , Noise , and _M . Mode specifies whether the device is linear or non-linear. Noise specifies whether the device is a noise generation source. HSpice does not have an equivalent to either of these parameters, so they're both dropped.
The rest of the parameters do match HSpice parameters, so the parameters value is set to Model Area Region _M Temp to match the order that HSpice specifies in its manual.
In HSpice, the Model is output as a value only, so a line is put in to eliminate the parameter name, Parameter_Name_Mapping = Model .
The chapter example outputs the left hand side of the area value for readability. Since HSpice is not case sensitive nothing is needed for the area parameter.
Region is mapped to the HSpice parameter that designates whether the device is on or off for DC analysis. ADS allows four settings for this value, 0 means the device is off, 1 means the device is on, 2 means the device is reverse biased, and 3 means the device is saturated. The last two are meaningless to HSpice, so these values need to be mapped. Additionally, HSpice does not want integer values, it wants the value to be a text value on or off . We need a value mapping function for this parameter.
First, the parameter name is mapped so that it is not be output by creating a line as follows:
Parameter_Name_Mapping = Region
Next, a line is created for the value mapping by placing the following line:
Parameter_Type_Mapping = Region hspiceModifyRegion .
The function hspiceModifyRegion must now be created. Copy the value mapping function prototype into the file cnexNetlistFunctions.ael. The decision here is what to do with the extra values ADS supports. The default value is that the device is on for both ADS or HSpice. So if the value is empty or NULL, the function will return an empty string. For simplicity, set them so that if the Region is 1 , the function will return the value on . This yields the following function:
defun hspiceModifyRegion(value)
{
decl returnVal;
if(!value)
returnVal="";
else if(value == 1)
returnVal="on";
else
returnVal="off";
return(returnVal);
}
The _M parameter needs to be mapped to the parameter M . This is done with the following line:
Parameter_Name_Mapping = _M M
The Temp parameter is mapped to DTEMP , and a value mapping function is specified for Temp , hspiceModifyTemp . This time, the function has already been written, so it is a matter of adding the following lines to the file:
Parameter_Name_Mapping = Temp DTEMP Parameter_Type_Mapping = Temp hspiceModifyTemp
This completes the component definition. The circuit test3 has a BJT_NPN component and some basic biasing components around it, such as resistors and capacitors. After setting reasonable values for all of the parameters and netlisting, the instance line for the BJT_NPN component is as follows:
qbjt1 _net107 _net108 _net109 BJTM1 Area=1 off M=1 DTEMP='27-temper'
This is the correct output for HSpice.
Model Components
A model component is a schematic instance that, when netlisted, becomes a model device that other instances in the circuit can access. IC simulators often use model components. Those simulators also support netlist fragments, pieces of a netlist include in the final netlist which are available only through library calls or include statements.
The ADS simulator, which does not support netlist fragments.
If you use ADS model components in your circuit, the recommendation is to create netlists for HSpice that contain the models you need. Then set up all of the ADS model components so they netlist using the function cnexIgnoreInstance . In Setting Up Automatically Included Files, there is a description that shows how to get your netlist fragments included in the final netlist.
Simulation Components
It is usually better to include a file that contains the simulations you wish to perform in HSpice instead of an ADS simulation component. Many ADS simulation components do not map into other simulators.
However, for certain simulations, such as DC, you can set up a simulation. The following is an example of setting up a DC component to netlist for HSpice.
Since we know what the component is, check to see what HSpice needs in order to designate a simulation.
When a DC simulation is done, you are trying to find the operating point of the circuit at the time index of zero. To do this in HSpice, the correct line is as follows:
.OP <format> <time> <format> <time>
Additionally, to perform variable sweeps, you need a DC line as follows:
.DC var1 start1 stop1 incr1 <var2 start2 stop2 incr2 >
In ADS, the operating point calculation and the variable sweeps are both potentially designated in a single DC component. This is a case of needing two lines of output for a single component.
The only way to figure out the right parameter name is to look at the netlist, and then use the simulator's help capability.
First, generate an ADS netlist, and identify the components line by looking for its instance name. The string in front of the instance name is the device that the component is netlisted as, in this case, DC. To get help on the DC component from the simulator, type in hpeesofsim -help DC in a command line terminal. This will give you the parameters that are valid for the DC device, and a brief description of each parameter.
For the DC operating point, the parameter name in the simulator is DevOpPtLeve l.
If DevOpPtLevel is placed in the component definition, it will be possible to retrieve its value using the function cnexGetParameterValues . The value is examined, and either NONE , BRIEF , or ALL is output, based on the value that was returned. If there was no value, nothing is output at all.
The sweep line is determined by looking at the value of SweepVar , which will specify whether a .DC sweep will need to be output.
The sweep plan has the variable names Start , Stop , and Step . Assume these are the right parameter names, and set these up on the parameters line along with SweepVar . The function will then have to step through and grab these values from the parameter list that was returned from cnexGetParameterValues .
Since there is a known set of values set, a while loop is set up to output the remaining three parameters. This yields the following component definition file for DC.cnex :
Netlist_Function = hspiceOutputDcComponent Component_Name = Terminal_Order = Parameters = DevOpPtLevel SweepVar Start Stop Step
And the following function definition was created for hspiceOutputDcComponent:
defun hspiceOutputDcComponent(instH, instRecord)
{
\* This is a function that will specifically output a .OP and .DC
line for HSpice from a DC component. */
decl net=".OP";
decl paramList=cnexGetParameterValues(instH, instRecord);
decl paramRecord, paramValue;
/* Get the record for DevOpPtLevel */
paramRecord=car(paramList);
paramValue=nth(1, paramRecord);
paramList=cdr(paramList);
if(paramValue)
{
if(paramValue == "0")
{
net=strcat(net, " NONE");
}
else if (paramValue == "2")
{
net=strcat(net, " BRIEF");
}
else
{
net=strcat(net, " ALL");
}
}
/* Get the record for SweepVar */
paramRecord=car(paramList);
paramList=cdr(paramList);
paramValue=nth(1, paramRecord);
if(paramValue)
{
net=strcat(net, "\n.DC ", paramValue);
while(paramList)
{
paramRecord=car(paramList);
paramList=cdr(paramList);
net=strcat(net, " ", nth(1, paramRecord));
}
}
return(net);
}
The component is netlisted, and the result is as follows:
.OP ALL
.DC "X" 1000 10000 1000
After the first iteration, it appears that the name of the variable is quoted. The parameter formatting function did not take the double quotes out, and ADS specifies the value is explicitly a string.
Two things could be done. A parameter type mapping function could be specified that would remove the quotes, or, code could be added directly into the function to remove the quotes. The second choice has been made in this case, so two new line are added prior to the net=strcat(net, "\n.DC ", paramValue); line:
if(leftstr(paramValue, 1) == "'") paramValue=midstr(paramValue, 1, strlen(paramValue)-2);
A DC component is placed, and a netlist is created. Now the output is as follows:
.OP ALL .DC X 1000 10000 1000
This is what is needed. It is now possible to run a basic DC simulation in both ADS and HSpice by placing a DC component.
Similar setups could be done for the AC component and the Tran component. Other than DC, AC, and Transient simulation, ADS and HSpice don't have much in common in the way of simulation. These three simulations should be enough to drive model comparison simulations.
Components that Access Netlist Fragment Subcircuits
A netlist fragment is a piece of a netlist that is meant to be reused in other netlists by using library statements or include statements. These can either be models, or they can be complete subcircuits, or even complete subcircuit hierarchies.
If you have a component that is hierarchically defined in ADS, it is a subcircuit and uses cnexSubcircuitInstance . If your component is going to access another subcircuit, and it is not hierarchically defined in ADS, but the instance line still needs to be output as a subcircuit reference, you still need to use the function cnexSubcircuitInstance. If you use cnexNetlistInstance , assuming that because your subcircuit in the fragment is now a new primitive, like it is in ADS, you will not get the correct HSpice format.
For HSpice, a subcircuit is referenced by an instance by using a line with the following format:
Xyyy n1 <n2 n3 ...> subnam <parnam= _val_ ...> <M= _val_ >
A new component, test4 is created. This component access one of the following two pre-made netlist fragments that has the subcircuit headers:
.subckt cktA pos neg Width=2u Lenth=10u .subckt cktB pos net Width=2u Length=10u
These represent the resistors of two different types. The user chooses between the two resistors by selecting from a pull-down menu on a parameter called circuit . This is the type of setup used if you have a high impedance and a low impedance resistor and have parasitic subnetworks to represent each of the two types of resistor where the parasitic values cannot be simply calculated based on parameters that are passed into the circuit.
You can make a component definition for a user defined device. Because the default behavior will not be correct in this case, a new file, test4.cnex , is made in the HSpice component directory.
Since the netlist fragments are subcircuits, the Netlist_Function is set up to be cnexSubcircuitInstance .
The terminal order can be determined from the subcircuit headers. It must be pos neg .
You want the subcircuit name, Component_Name field, to be picked up from the value that is specified in the circuit parameter. Instead of putting an explicit name, the Component_Name field is set to @circuit , which tells the netlisting code to use the value of the circuit parameter.
Because circuit is being used as the component name, it does not need to be output as a parameter. The only two parameters are Width and Length . For this particular subcircuit, the parameter names in the SPICE file are the same as the parameter names of the component. No name mapping is required. The final component definition file becomes the following:
Netlist_Function = cnexSubcircuitInstance Component_Name = @circuit Terminal_Order = POS NEG Parameters = Width Length
Two instances of test4 are placed in a new circuit, test5 . Once instance has circuit set to cktA and the other has circuit set to cktB . A netlist is generated and the output lines are the following:
xx2 _net28 _net27 cktb Width=2uM Length=10uM xx1 _net28 _net27 ckta Width=2uM Length=10uM
These two instance lines match the needed output for the subcircuit headers that were shown.
Verifying the Netlist
Verifying the netlist comprises of making sure that the subcircuit definitions are output correctly and that each instance is output correctly.
For the HSpice simulator ready netlists, to back annotating the DC results to the ADS schematic, you can name all of the nodes in the schematic, which will force ADS to store the DC results into a dataset file. You can then view the results of the ADS simulation in the Data Display Server, and the HSpice results in their results viewer.
If you have a schematic in another tool that can drive HSpice, you can create a netlist from that tool, and a netlist from ADS, and view simulation results from both of the netlists.
Component Verification
Here is a check list to follow that will allow you to verify any component:
- Determine the ADS component type.
- Determine the ADS terminal order.
- Find out the ADS component parameters.
- Determine the format needed by the new tool. For example, to make a capacitor in HSpice, the format is the following:
Cxxx n1 n2 < mname > <C=>capacitance <<TC1=> val > <<TC2=> val > <SCALE= val > <IC= val > <M= val > <W= val > <L= val > <DTEMP= val >. - Create a component definition for the ADS component.
- Place one instance of the component in a schematic. Make sure to set all of the parameters so they have values.
This will guarantee that parameters that are supposed to be netlisted are netlisted, and that parameters that aren't supposed to be netlisted are not. - Create a netlist. Make sure to set the checkbox so that the netlist will be shown after netlisting is finished.
- Compare the instance line that was output to the format line that you determined was needed.
If they match, you are finished. If they do not match, determine if it is because you need a value mapping function, or if you mis-configured something. Also, consider whether your format may need to have configuration variables or the instance function itself changed.
Privacy
Statement 
|
Terms of Use |
Legal |
Contact Us |
© Agilent 2000-2008
