ModelGen Users Manual

Version 2.6 Integrand Software, Inc. Copyright c 20042012

Introduction

ModelGen is a model generator that reads Y-parameters and outputs netlists in formats accepted by various circuit simulators. Typically the Y-parameters come from running EMX , though they could also be from measured data. The output les contain subcircuits for use with Spice, Hspice, Spectre, Eldo, or ADS. ModelGen can be run in two dierent ways. 1. It can take a single Y-parameter le and produce a xed model (singlemodel mode); or 2. It can take a set of Y-parameter les representing a scalable device that has been instantiated with varying design parameters. In this case, ModelGen attempts to nd a single scalable model that is parameterized by the same design parameters and that matches all of the Y-parameter les. This mode of operation is called Continuum mode.

Single-model mode

To produce a xed model from a set of Y-parameters, the simplest command line is something like this: modelgen --type=inductor exind.y --spice-file=exind.sp (If you would like to try this example, the exind.y input le is included in the ModelGen distribution.) ModelGen will run for a few seconds and print this output: Iteration 1.... err 5.954709e-02 Iteration 2....
EMX is a registered trademark of Integrand Software, Inc. Hspice is a registered trademark of Synopsis, Inc. Spectre is a registered trademark of Cadence Design Systems, Inc. Eldo is a registered trademark of Mentor Graphics Corporation.

Iteration 3.... err 2.742651e-02 Iteration 4.... Iteration 5.... err 1.980710e-02 Iteration 6.... Iteration 7.... Iteration 8.... Iteration 9.... It will also produce a Spice subcircuit le, exind.sp, containing a two-port subcircuit model for an inductor. A comparison of the data and the model are shown in gure 1.
L 3 2.5 2 nH 1.5 1 2 0.5 0 0
3

Q 8

data model

6 4

10 GHz R

15

20

0 0
3

10 GHz Z

15

20

10

10

10

10

10

10

10

10 GHz

15

20

10

10 GHz

15

20

Figure 1: Comparison of inductor data and model The Y-parameter le must be in EMXs matlab output format. The le should consist of a series of lines, one per analysis frequency. For an n-port structure, each line has 2n2 +1 oating-point numbers, separated by spaces. The rst number is the frequency. The remaining numbers are real(Y11 ), imag(Y11 ), real(Y21 ), imag(Y21 ), . . . , real(Ynn ), imag(Ynn ). The behavior of ModelGen is controlled by command-line options. Options begin with two dashes (--). All options may be abbreviated as long as the result is not ambiguous (e.g., --spice-file and --spice are considered to be the same). Some options require an argument, such as a number or name. The argument follows =, e.g., --spice-file=ind.sp. Some options have single-letter forms which are preceded by one dash (e.g., -t inductor instead of --type=inductor). For the single-letter forms, the options argument is separated from the option with a space. Here are the commonly-used options. 2

--type=string The --type option species the type of device that should be produced. By default, ModelGen produces an inductor model. The allowed model types are discussed in section 3. You may abbreviate --type with -t. --spice-file=lename Save the model in generic Spice format to the specied le. --spectre-file=lename Output the model in the native format for Cadences Spectre simulator to the given le. --ads-file=lename Output le for Agilents ADS tools. --eldo-file=lename Output le for Mentors Eldo simulator. --hspice-file=lename Output le for Synopsis Hspice simulator. --skill-file=lename Output SKILL le for optimal component nders (see subsection 4.3). --beyond-resonance=number Normally, ModelGen makes a model using the data out to the rst resonance of the device. This is because the devices in a circuit are generally operated well below their self-resonant frequency (SRF). You can use this argument to set the frequency range to a multiple of the SRF. For example, --beyond-resonance=0.8 tells ModelGen to use data out to 0.8 times the SRF. The short form of this option is -b. The exact way in which ModelGen computes the SRF depends on the type of model. --name=string You set the name of the subcircuit using this option. The default name depends on the type of the model. The short form of --name is -n. ModelGen can produce multiple output les in one run, for example: modelgen ... --spice=ind.sp --spectre=ind.scs --hspice=ind.mdl

Model types

ModelGen can produce models for many dierent types of devices. For a full list, type modelgen --help. The last input for all of these models always represents the substrate. For example, the inductor model has terminals p1, p2, and gnd. The gnd terminal is usually tied to ground. The model types may be abbreviated as long as the result is unambiguous; for example, complex_tcoil and complex_tc are equivalent.

4
4.1

Continuum mode
The master le

In Continuum mode, ModelGen needs a master le in addition to a set of Y-parameter les. The master le gives information about the geometric parameters, the names of the Y-parameter les, and which parameter settings correspond to which le. ModelGen is run in Continuum mode as follows: modelgen --continuum master --spectre-file=sqind.scs Additional output les may also be specied. The --spice-file option is not available in this mode since generic Spice does not include facilities for parameterized models. In addition to continuum, some additional options are available in Continuum mode. --max-processes=number Use the specied number of parallel processes during model generation. This can speed up the process on multi-CPU machines. --interpolate-responses Create intermediate responses for multi-region models using interpolation. This works if the data les are dense enough that the electrical behavior does not change too radically as the parameters vary. For best accuracy, true data les should be provided (in the form of auxfiles), but this option can be used to avoid having to run too many simulations. See subsection 4.2. An example master le is shown in gure 2. Each line in the master le is a declaration. Possible declarations are: name string Gives the model name. description string Species a comment string that will be placed in the head section of the model. Multiple comments are allowed and are placed on separate lines. type string Gives the model type, as specied in section 3. parameter name and options Denes a model parameter. The name is a string, and the options which follow the name may include (in any order): = string Declares that the parameter corresponds to an internal geometric parameter with the given name. The allowed internal geometric parameters depend on the model. default number Sets the default value of the parameter. This only aects the default value printed in the various output les. If you dont specify a default, the minimum of the parameters range is used. scaling number Species the external scaling of a parameter. Normally, the geometric paramter values in the master le are in a convenient unit like microns. In this case, if the model is to be instantiated with values in meters, then you need to specify a scaling of 1e-6 (106 ). 4

name sqind description "Square inductor; thick metal6; underpass metals 4&5" description "Generic foundry 0.25um CMOS process" type inductor parameter innersz=d scaling 1e-6 rounding 0.1 default 30 parameter metalwid=w [1, 10] scaling 1e-6 rounding 0.01 parameter turns default 1.5 terminal port1=p1 terminal port2=p2 terminal sub=gnd validfn "innersz-metalwid >= 20e-6" lengthfn innersz turns*metalwid widthfn innersz turns*metalwid file sqind_turns1.5_innersz30_metalwid1.y length=81 width=100 file sqind_turns1.5_innersz30_metalwid3.y length=83 width=102 ... auxfile sqind_turns1.5_innersz30_metalwid9.y length=89 width=108 auxfile sqind_turns1.5_innersz45_metalwid1.y length=100 width=110 ... file sqind_turns1.5_innersz100_metalwid9.y length=150 width=183 file sqind_turns2.5_innersz30_metalwid1.y length=170 width=192 ... Figure 2: Example master le

userscaling symbol Like scaling, but uses a symbolic value instead of a number. The advantage of this is that it allows the user of the nal model to change the scaling. invuserscaling symbol This option is like userscaling, but the sense of the scaling is inverted. That is, instead of being multiplied by the symbolic value, the parameter is divided by it. range By default, the possible range of a parameter is extracted from the minimum and maximum values of that parameter over all the data les. If the actual allowed range is larger, you may specify the range explicitly, e.g., [1, 10]. There are also some options which are only relevant for SKILL models that will be used in the Continuum optimal component nders within the Cadence design environment. rounding number When choosing values for this parameter, the values should be rounded to the specied precision. step number Dene what is considered a signicant step in the parameters value. The range of parameter values will be searched at this level of granularity. The default depends on the parameter and the type of model. Parameters that do not correspond to internal geometric parameters are considered to be discrete, i.e., the model may only be instantiated at particular values of those variables. For examples, the allowed number of turns for an inductor could be 1, 2, . . . , 6, 7, but not 1.94. terminal string = string Declare the external name of a terminal and which internal name it corresponds to. The external name comes rst. Each internal terminal must have an external name. file string and parameter settings Specify a le name and the corresponding setting of the parameters. The le name may be followed by a series of string = number pairs to specify the parameter settings, but it is probably most convenient if the parameter values are encoded in the le name. This is done with a series of underscores, parameter names, and numbers that are placed just before the les extension, as shown in gure 2. For example, file sqind_innersz30.5_metalwid3.y is equivalent to file sqind63.y innersz=30.5 metalwid=3 auxfile string and parameter settings Specify an auxiliary le name and the corresponding setting of the parameters. 6

validfn string Some SKILL models need a function that returns t for valid settings of the parameters. This declaration denes the body of that function. The default is just t, meaning that all parameter settings are allowed. lengthfn terms SKILL models need functions to compute the length and width (in microns) of the layout. The function is assumed to be a sum of terms. Each term is specied as a product of parameters. For example, lengthfn innersz turns*metalwid means that the length function will have the form c1 + c2 innersz + c3 turns metalwid. The coecients ci are computed automatically. widthfn terms This declaration gives the terms needed for computing the width of the layout.

4.2

Files and auxiliary les

For each particular value of the discrete parameters, ModelGen can produce either a single-region or multi-region model. The number and size of regions is controlled by using file and auxfile declarations in the master le. Each file corresponds to a model region. The region used for a particular set of parameter values will be the one corresponding to the closest of the specied files. The data les used for building the model in a region include the le for that region, the les for any adjacent regions, any auxiliary les that fall within the region, and, optionally, responses that are interpolated from the les (when --interpolate-responses is specied). Typically about nine les are needed to produce the model for a region; if too few are available, ModelGen may convert some files to auxfiles internally in order to reduce the number of regions. In typical usage, the files will be form a coarse grid covering the desired parameter space, and auxfiles will be specied for the intermediate points on the grid. When some parts of the space are not valid, additional auxfiles are often provided for the boundary of the valid parameter space. A typical pattern of les and auxilary les is shown in gure 3. The stars represent files, the circles auxfiles, and the lines show the region boundaries.

4.3

SKILL and optimal component nders

The Continuum optimal component nders provide interfaces to the parameterized models within the Cadence design environment. An optimal component nder takes designer-specied constraints and computes the best set of geometric parameters satisfying those constraints. For example, the Continuum 7

12 10 8 6 120 140 160 180 200 220 240 260 280 300

Figure 3: Files, auxiliary les, and region boundaries optimal inductor nder allows the designer to specify inductance, operating frequency, and area constraints. It can then nd the highest Q inductor meeting those constraints. The optimal component nders require SKILL versions of the models, and these models must have some extra information beyond what is needed by the circuit simulators. The rounding and step declarations are used to control the search. Parameter values are rounded as specied by the rounding declarations, and the parameter values that dier by less than the amounts in a step declaration are considered essentially equivalent. If some combinations of parameters are invalid, a validfn must be specied to constrain the search. Finally, the SKILL model must have information about the layout length and width required in order to make area/performance tradeos. The layout size is specied with the special length and width attributes, as shown in gure 2. The SKILL output le for the model is specied with the --skill-file option.

Acknowledgements

ModelGen is based on various numeric libraries and other software. Licensing information and acknowledgements are as follows. ModelGen uses LAPACK and BLAS libraries from the ATLAS project. Automatically Tuned Linear Algebra Software v3.4.2 (C) Copyright 1998 R. Clint Whaley Redistribution and use in source and binary forms, with or without modication, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The name of the ATLAS group or the names of its contributers may not be used to endorse or promote products derived from this software without specic written permission. 8

This software is provided by the copyright holders and contributors as is and any express or implied warranties, including, but not limited to, the implied warranties of merchantability and tness for a particular purpose are disclaimed. In no event shall the ATLAS group or its contributors be liable for any direct, indirect, incidental, special, exemplary, or consequential damages (including, but not limited to, procurement of substitute goods or services; loss of use, data, or prots; or business interruption) however caused and on any theory of liability, whether in contract, strict liability, or tort (including negligence or otherwise) arising in any way out of the use of this software, even if advised of the possibility of such damage. MD5 code is from Alladin Enterprises. Copyright (C) 1999, 2002 Aladdin Enterprises. All rights reserved. This software is provided as-is, without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions: 1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required. 2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software. 3. This notice may not be removed or altered from any source distribution. L. Peter Deutsch ghost@aladdin.com Regular expression support is provided by the PCRE library package, which is open source software, written by Philip Hazel, and copyright by the University of Cambridge, England. Source code for the PCRE library may be obtained from: ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/