ASCO (ASCO A SPICE Circuit Optimizer)
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts.
Examples
Examples
ASCO (A SPICE Circuit Optimizer)
Copyright (C) 2004-2022 João Ramos
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation version 2 of the License.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
ASCO tool does not create nor suggest new circuit arrangements, but simplifies the design process, since fine-tuning, verification and optimization of circuit functionality over process-voltage-temperature corners is automated.
ASCO tool can be seen as the automaton that does the tedious work, thus giving time to the designer to concentrate on intellectual challenges of devising new architectures and solutions for existing problems.
| Convention | Description | |
| courier | Indicates a code fragment | |
| Brackets ([ ]) | Indicates the component is optional | |
| Arrows (< >) | Indicates the component is mandatory | |
| Pipe (|) | Indicates that one of the items can be selected |
tar -zxvf ASCO-<version>.tar.gz cd ASCO-<version> make
cp asco examples/Eldo/inv cd examples/Eldo/inv ./asco -eldo inv
otherwise, replace the word Eldo and eldo by the appropriate text representing your simulator.
nfeval=20 cmin=3.1914 cost-variance=3.9852 nfeval=30 cmin=3.1914 cost-variance=2.6059 nfeval=40 cmin=3.188 cost-variance=1.1017 nfeval=50 cmin=3.188 cost-variance=0.11595 nfeval=60 cmin=3.188 cost-variance=0.048998 nfeval=70 cmin=3.188 cost-variance=0.036212 nfeval=80 cmin=3.1879 cost-variance=0.0048361 nfeval=90 cmin=3.1879 cost-variance=0.0025139 nfeval=100 cmin=3.1879 cost-variance=0.00048362 nfeval=110 cmin=3.1795 cost-variance=0.00041958 nfeval=120 cmin=3.1696 cost-variance=0.00012673 nfeval=130 cmin=3.1696 cost-variance=5.568e-05 nfeval=140 cmin=3.1696 cost-variance=1.873e-05 nfeval=150 cmin=3.1696 cost-variance=1.1294e-05 nfeval=160 cmin=3.1696 cost-variance=5.8484e-06 nfeval=170 cmin=3.1696 cost-variance=3.3654e-06 nfeval=180 cmin=3.1696 cost-variance=3.5067e-07 Best-so-far obj. funct. value = 3.1696 best[0]=-7.990420912 Generation=18 NFEs=180 Strategy: DE/rand-to-best/1/exp NP=10 F=0.5 CR=1 cost-variance=3.5067e-07 INFO: de36.c - Minimum cost variance reached (cvarmin=1.000000E-06) INFO: Ending optimization
+cost:3.169600E+00: P_SUPPLY:3.169600E-01: +VHIGH:2.154500E+00: // +VLOW:2.605600E-02: WP:1.904311E-03:
The plus signal as the first character in the line, as opposed to -cost, is an indication that all optimization constraints have been met. In the last column, the transistor size, 1.904 mm, that originates the minimum power consumption is presented.
The ASCO tool as been written from the ground-up with the purpose of being simulator independent. As long as the simulator reads its inputs from text files, outputs its results in ASCII format, and can be launched from the command line, it can most likely be added to the list of supported SPICE simulators. Even though it has been designed to work with existing SPICE simulators, at this moment it is flexible enough to interact with other tools, for example, with FastHenry.
Today, it is possible to find various offers of commercial products with similar characteristics. In some cases, the optimization algorithms are suitable only for local optimizations. In other cases, they are better than the ASCO tool, but this comes at a monetary cost. Once again, it is up to the designer to decide the best option to meet the design goals.
, LTspiceTM, Spectre, Qucs and ngspice exist. More are to be included in future releases.
ASCO has been designed to address problems that are oriented to electric circuits. Although not limited, some possible applications can include:
Refer to Chapter 6 for ready to use practical examples to introduce you to ASCO, a SPICE circuit optimization tool.
tar -zxvf ASCO-<version>.tar.gz cd ASCO-<version> make
Two executables are created: asco and asco-test. Copy them to a common directory so that they can be used later.
tar -zxvf Autotools.tar.gz
to extract all necessary files. Then, type the following lines to configure and compile
aclocal automake -f -c -a sh autogen.sh ./configure make
and obtain the same executables.
A binary version is also made available to download at the project homepage, for situations where a build system is not installed.
The local optimizers use an intrinsically a sequential method. To gain design speed in situations where a good local starting point is known, the parallel global DE algorithm can be used in an emulated local mode. Thus benefiting from distributed computing while strongly limiting the search space.
BSIM selection
. The output from Spectre version changes from version-to-version but the change is more significant between different transistor models. As such, the selection between BSIM3 and BSIM4 (the only two supported models) has to be made by editing the source files. Search for BSIM4 string. File auxfunc_measurefromlis.c requires 2 one byte changes, while the file auxfunc_updatelis.c requires commenting 5 lines and un-commenting another 5 lines of code. The changes are self explanatory for an experienced C programmer.
The definition of the cost function is calculated automatically by the ASCO tool. This is the function that has to be minimized. Individual minimization or maximization of each one of the measurements is also accomplished without user intervention. In most of the cases, only the specification of the parameters range and constraints is sufficient before starting a new optimization.
of generation 
, a perturbed vector
is generated as follows:
The indexes 
, 
and 
indicate three randomly chosen individuals of the population. They are mutually different integer indexes (
![$\in [0, (N-1)]$](img15.png)
) and also differ from the running index 
. The (real) constant factor 
(![$\in [0,2]$](img18.png)
) controls the amplification of the differential variation. The vector
that is being perturbed has no relation to the vector
that will potentially be replaced. To increase the potential diversity of the perturbed parameter vectors, crossover is introduced. More information about the algorithm and details of several variants or strategies for constructing new parameter vectors can be found in [SP95,Sto96]. In addition, this algorithm has been altered to include parameter bounding, stop criteria and mixed continuous/discrete parameter support.
Any circuit variable (device sizes, component values, bias inputs, ...) can be selected as optimization parameters. Furthermore, one or more optimization objectives (minimize, maximize) can be specified as well as a number of (performance) constraints (e.g.
or
). All these requirements (
objectives and 
constraints) are combined into a single cost function 4.1 which can be evaluated by the optimizer:
with 
and 
the weights for the cost due to the objectives and constraints, respectively, and where 
indicates performances, either simulated or specified. With properly scaled weights (which is very easily accomplished), the optimizer will first try to find feasible solutions (satisfying the constraints) and then further tunes the parameters to optimize the objectives. This scaling can easily be adjusted manually after a “dry-run” (which can also be automated) and only requires altering the order of magnitude of one of the weights depending on the cost values which are logged. In order to deal with complex problems with many constraints, a minimax problem formulation is used in (4.2). When the genetic algorithm proposes bad combinations of parameters (e.g. out of bound), a “high” cost is assigned (e.g. 
) to such solutions.
In order to facilitate the automated optimization of specific circuit classes (Op-Amps, comparators, ...), constraint and objective templates can be loaded. These could have been stored for reuse by the designer himself or provided by another expert designer.
| <inputfile>.* | Properly formatted SPICE input netlist. Default extension is .cir for EldoTM, .sp for HSPICE, .net for LTspiceTM, .scs for Spectre, .txt for Qucs and .sp for ngspice. |
| <inputfile>.cfg | Configuration file having the same name as the SPICE input netlist with .cfg extension. |
| extract/ | Extract commands for each one of the performances are stored in this directory. |
Upon starting an optimization, the following files are created.
| <hostname>.tmp | Temporary file containing a post-processed version of the SPICE input netlist <inputfile>.*. |
| <hostname>.log | Simulator results log file. |
| <hostname>.* | Simulator specific input/output files. |
| asco.log | Optimizer log file. |
*Digital inverter .PARAM V_SUPPLY = '#V_SUPPLY#' .PARAM INP_FREQ = '#INP_FREQ#' .PARAM INP_PERIOD = '1/INP_FREQ' .PARAM NO_PERIODS = '4' .PARAM TMEAS_START = '(NO_PERIODS-1)*INP_PERIOD' .PARAM TMEAS_STOP = '(NO_PERIODS)*INP_PERIOD' .PARAM TMEAS_1 = 'TMEAS_STOP -3*INP_PERIOD/4' .PARAM TMEAS_2 = 'TMEAS_STOP -1*INP_PERIOD/4' *** *** SUPPLY VOLTAGES *** *** VDD VDD 0 V_SUPPLY VSS VSS 0 0 *** *** INPUT SIGNAL *** *** VSIG IN VSS PULSE V_SUPPLY 0 'INP_PERIOD/2' 'INP_PERIOD/1000' + 'INP_PERIOD/1000' 'INP_PERIOD/2' 'INP_PERIOD' *** *** CIRCUIT *** *** MP OUT IN VDD VDD PMOS W='#WP#' L=#LMIN# MN OUT IN VSS VSS NMOS W='#WP#/3' L=#LMIN# CL OUT VSS 10p *** *** ANALYSIS *** *** .TRAN 'INP_PERIOD/1000' 'NO_PERIODS*INP_PERIOD' .MC 2 ALL .PROBE TRAN V(IN) .PROBE TRAN V(OUT) .OPTION EPS=1E-6 .INCLUDE p.typ .INCLUDE n.typ .END
In the above netlist representing a digital inverter, all lines are the same as in a normal simulation with a couple of exceptions:
The following syntax is enforced throughout the configuration file so ASCO can properly write and read the input and output files:
#Optimization Flow# Alter:no $do we want to do corner analysis? MonteCarlo:no $do we want to do MonteCarlo analysis? AlterMC cost:0.00 $point below which ALTER and/or MONTECARLO can start ExecuteRF:no $Execute or not the RF module to add RF parasitics? SomethingElse: #
Word yes and no are used to perform or not a given analysis in the optimization loop. The scheduled simulations with Alter and/or MonteCarlo, are only executed if all constraints have been met in the previous cost evaluation, otherwise, they are executed immediately after the real value specified in the AlterMC cost.
During and optimization, misconvergence can occur if before starting simulations re-runs using Alter, a lower cost has already been obtained than the possible best when including design corners. This situation can be avoided by not setting AlterMC too low. Similar situation applies to the MonteCarlo case.
#DE# choice of method:3 maximum no. of iterations:50 Output refresh cycle:2 No. of parents NP:60 Constant F:0.85 Crossover factor CR:1 Seed for pseudo random number generator:3 Minimum Cost Variance:1e-6 Cost objectives:10 Cost constraints:100 #
There is no choice of parameters that fits all. Each optimization problem has an ideal choice of the above factors. However F=0.5 and CR=0.8 can be taken as good starting point alongside with method 3 or 4. Read the following lines for further clarification.
An explanation of the naming-convention follows for the DE/x/y/z. DE: stands for Differential Evolution; x: a string which denotes the vector to be perturbed; y: number of difference vectors taken for perturbation of x; z: crossover method (exp = exponential, bin = binomial). When the DE/best... schemes fail DE/rand... usually works and vice versa. One of the following methods can be chosen using a number between 1 and 10.
Stop criteria. Be aware that the maximum possible number of SPICE simulation calls can be as large as NIxNP. Generations is another name used for iterations.
Number of population members. To start off NP equal to ten times the number of parameters is a reasonable choice. Increase NP if misconvergence happens. If you increase NP, F usually has to be decreased. The number of population members NP is also not very critical. A good initial guess is 10xD. Depending on the difficulty of the problem NP can be lower than 10xD or must be higher than 10xD to achieve convergence.
DE-stepsize F from interval [0, 2] which affects the differential variation between two individuals. The scale factor F must be above a certain minimum value to avoid premature converge to a local minimum (sub-optimal solution). However, making F too large causes the number of function evaluations to increase before converging to an optimum solution. On the other hand, it allows global exploration of the search space. F is usually between 0.5 and 1 (in rare cases >1). DE is also somewhat sensitive to the choice of the stepsize F.
Crossover probability constant from interval [0, 1] which affects the diversity of population for the next generation. Helps to maintain the diversity of the population and is rather uncritical, with 0.0, 0.3, 0.7 and 1.0 being optimal first choices. If the parameters are correlated, high values of CR work better. The reverse is true for no correlation. In low-dimensional problems (<10), higher values of crossover probability work better to preserve the diversity in the population.
Self-explanatory.
Another stop criteria. Simulation stops if current cost variance is smaller than the defined value.
in (4.2)
in (4.2)
More information can be found either in the C source file de36.c or in [SP95,Sto96].
# Parameters # Supply voltage:#V_SUPPLY#:2.0:0:0:LIN_DOUBLE:--- Supply voltage:#V_SUPPLY#:2.0:0:0:LIN_DOUBLE:OPT Input frequency:#INP_FREQ#:850E6:0:0:LIN_DOUBLE:--- PMOS width:#WP#:70u:75u:250u:LIN_DOUBLE:OPT Multiplier:#M#:4:2:5:LIN_INT:OPT #
A sequence of colon separated specifying different fields: Text description, Symbol, Initial value, Minimum, Maximum, Number format and Type. A clarification of each one the parameters is now presented:
For IEC 60063 preferred number series (E3, E6, E12, E24, E48, E96 and E192 only) use for example :E48: alone. The code was contributed by Stefan Mahr.
Notes:
| T=1E12 | G=1E9 | MEG=1E6 | K=1E3 | |||||||
| A=1E-18 | F=1E-15 | P=1E-12 | N=1E-9 | U=1E-6 | M=1E-3 |
As such, each one of the above lines implies:
Text clarifies that this parameter is related to the Supply voltage, the symbol to look for and replace in the SPICE input netlist is #V_SUPPLY#. Initial value used for the optimization is 2.0 Volt with a minimum and maximum of 0. Because it is only a parameter to replace (note the string —) the maximum values would have been ignored. In this case LIN_DOUBLE indicates a parameter with double precision with linear parameter variation.
Owing to the fact that the maximum is equal to the minimum, but the variable is set to optimized, the parallel global DE algorithm is used in an emulated local mode. The minimum and maximum are internally set to -10/+10% of the initial value.
The Input frequency where the symbol to look and replace is #INP_FREQ# has an initial value of 850E6 Hertz. Again, because it is not a variable to optimize, due to the presence of —, the minimum and the maximum values are ignored.
The PMOS width has the symbol #WP#. The initial value is 70u. In this case, the parameter is to be optimized (OPT) with a minimum value of 75u and a maximum value of 250u. The double precision is used alongside with a linear swept of the optimization parameter range due to the LIN_DOUBLE keyword.
Possible values are 2, 3, 4 and 5 for multiplier parameter because xxx_INT is used. Initial value in the optimization is set to 4.
# Measurements # P_SUPPLY:---:MIN:0 P_OUT:OUT:GE:0.0316 #
A sequence of colon separated specifying different fields: Measurement, Node, Objective or Constraint, Gain or Constraint value, having the following meaning:
Taking as example the above lines:
Measure the power supply, no node is specified, minimize is the optimization objective. Because the objective gain is not yet implemented, the hardcoded value of 10 is used instead of 0.
Measure the output power at node OUT which must be greater-or-equal than 0.0316 Watt.
Only one objective and one constraint is specified, but in theory there is no limit to the maximum number of objectives and/or constraints that can be considered in an optimization. Neither is there a limit to the type of measurements to perform. However, different cost functions or different penalties can lead to distinctive “optimal” solutions. It is thus advisable to have only one objective combined with the necessary constraints. A figure-of-merit (FOM) which accounts for all partial minimize/maximize goals is then minimized by the optimizer.
In EldoTM, the following example is used to measure the output power at a user-defined frequency.
![\includegraphics[width=0.35\columnwidth]{figures/empty}](img7.png)
![$\displaystyle W_{con} \cdot \max_{j \in [1, m]} \left( \frac{P_{spec_j}-P_{sim_j}}{P_{spec_j}} \right)$](img28.png)
# Info #
Name:P_OUT
Symbol:ZP_OUT
Unit:W
Analysis type:TRAN
Definition:Output power at the fundamental harmonic.
Note:
#
# Commands #
.OPTFOUR TSTART=TMEAS_START TSTOP=TMEAS_STOP NBPT=1024
.FOUR LABEL=fftout v(#NODE#)
.EXTRACT FOUR LABEL=#SYMBOL# {((YVAL(FOUR(fftout), INP_FREQ))^2)/(2*FILT_RES)}
#
# Post Processing #
#
Each file defining one parameter extraction must have the three categories shown above:
All fields are self-explanatory. Currently ignored.
Commands to be included in the SPICE netlist to extract waveform information from a simulation run are defined here. The node where the measurement is to be done, is replaced by the text given in sub-section 4.3.2/Measurement Options. Currently, the symbol is automatically filled by the tool.
Refer to Section 7.4 for the appropriate syntax. Note, that only the MEASURE_VAR command can be used in here.
All output files are simulator specific and are created by the simulator that is being used. The exception, two log files that report all the steps that have been done during the optimization loop, more precisely:
To invoke ASCO, simply type at the command line:
./asco -<eldo|hspice|ltspice|spectre|qucs|ngspice|general> <inputfile>
The simulator to use must be specified in the first input argument. The <inputfile> can include the file extension.
As programmed, an Alter and/or Monte Carlo simulation is only started after all constraints are met in the previous step. This, unless AlterMC cost is defined in the configuration file with a high value making that the simulation re-runs start immediately, because the returned cost from the previous simulation is lower than the AlterMC cost defined to start simulating the PVT corners. The normal flow, if all steps are to be executed is: optimization
AlterMonte Carlo. If an error exists in any of the subsequent steps, the simulator might not run at all. The necessary corrections must be made so that the sequence of the three steps can end without errors. After this, the long optimization sequence can start, so that at this time one can rest assured that no errors exist in either Alter and/or Monte Carlo netlist. At the command line, type:
./asco-test -<eldo|hspice|ltspice|spectre|qucs|ngspice|general> <inputfile>
As programmed in this current version, it is not possible to first execute Monte Carlo simulations and then Alter. Monte Carlo always follows the optimization or Alter.
Interprocess communication is handled by the Message Passing Interface (MPI), a standard for a parallel program on a distributed memory system communicate to other nodes. In the model implemented, there is one master process responsible for giving to each slave the data which is then simulated on another computer. The cost function at the end of each simulation is then returned to the master. Due to the time required for a packet to travel among nodes, and in comparison with the sequential code, the parallel implementation is more suitable to expensive function evaluation.
First it is necessary to download, compile and install the implementation of the MPI standard available at:
http://www.mpich.org/downloads/
If the executable mpicc is not in the PATH environment variable, the ASCO Makefile must be edited and the full path added to CC_MPI. Compile asco-mpi, the executable with parallel processing support by typing at the command prompt:
make asco-mpi
Before continuing, make sure the simulator is available through ssh or rsh. If the PATH environment variable is set in your current shell but not in your remote shell environment, the simulator might not be visible. To test this, type the following at the command line
ssh|rsh <MACHINE_NAME> <simulator>
In case of an error two possible solutions exist. You can either edit your shell configuration file to add the path to the directories that are searched by default, or you can edit the file errfunc.c around line 600-650 (in Step3), and add the full path to the simulator. To execute the parallel version with just one computer, type
mpirun -np 2 asco-mpi -<simulator> <inputfile>
This is exactly the same as executing the sequential optimization algorithm, but with two processes, one being the master and the other being the slave. Should a network of computers be available, the following method can be used:
mpirun -f machines.txt [-np X] asco-mpi -<simulator> <inputfile>
where, to execute on three computers, machines.txt is a text file containing a list of machines similar to
node1 node1:2 #2 processes on this node node2:1 node3
in which nodeN is the name of the machine as given by the *NIX command hostname. More than one process can be launched per computer. The simulation netlist(s) and configuration file(s) is/are then copied to the local disk (of the node computer) to reduce traffic in the network and as such decrease total optimization time.
The result given by the parallel version of ASCO is exactly the same as given by the sequential implementation. The exception is in the case where PVT corner analysis is performed. Nevertheless, a similar result is reached.
versions
simulator version from circa 2012 and onward, the Spectre simulator starts but do not take any CPU, you need to downgrade your MPICH to an older version. New Spectre simulator versions also use MPI (possibly also MPICH) and it (possibly) interferes with recent MPICH commands. You are advised to use
http://ftp.mcs.anl.gov/pub/mpi/mpich-1.2.7p1.tar.gz
storn/code.html.
The methodology applied to the ASCO tool has been proved on silicon. For further details see Chapter 2 [Ram05] for a low-voltage low-power design of a three stage operational amplifier and Chapter 6 [Ram05] for the design in the presence of passive and board parasitics, a high-efficiency 30 dBm class-E CMOS two-stage power amplifier for the GSM standard.
A careful selection of the number of optimization PVT corners and a thoughtful number of Monte Carlo simulations, is a good trade-off between optimization time and robustness. In addition, planning the exact moment to start sweeping the process corners is critical for minimizing CPU time. A two-step approach, where first only the optimization is done, followed by shrinking the variables search space to the range where all constraints have been met, i.e., upper and lower range from all the lines starting with +cost. Only then, the more computer intensive PVT optimization is performed.
Minimizing the number of ASCII and binary files created by the simulator, the number of measurements (.EXTRACT or .MEAS) and output variables (.PROBE), and the number of analysis (.AC, .PZ and .TRAN) to the absolute minimum required to efficiently characterize the circuit in conjunction with a keen speed/accuracy simulation compromise, saves precious CPU time in the optimization loop.
Open literature suggests that further gains in terms of convergence speed could be obtained by first doing a global search to find a good starting point that is latter used by a local optimization algorithm such as Hooke&Jeeves or Nelder-Mead. This decision is taken at compilation time by editing the file asco.c around Step4.
Thoroughly analyze the asco.log file as the circuit can be working on an undesired operating point or on the edge of stability. Then, explain what the optimizer has found.
asco-0.4.1 - Copyright (c) 1999-2006 Joao Ramos
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
INFO: Current directory on 'linux': /home/users/asco/examples/inv
INFO: Eldo initialization on 'linux'
INFO: Initialization has finished without errors on 'linux'
PRESS CTRL-C TO ABORT
INFO: Starting global optimizer on 'linux'...
PRESS CTRL-C TO ABORT
Best-so-far cost funct. value=1.6891
best[0]=-4.180591714
best[1]=6.665600201
best[2]=0.03964113694
best[3]=-7.372717493
best[4]=3.691704024
Generation=1 NFEs=80 Strategy: DE/rand-to-best/1/exp
NP=40 F=0.7 CR=0.9 cost-variance=8.2357e+12
which is a summary of the optimization startup procedure. No errors have occurred during the initialization of the optimization which has 5 optimization variables. The values of best[], always between -10 and +10, are the values proposed by the DE algorithm. They are later scaled to the range defined in <inputfile>.cfg.
Best-so-far cost funct. value=0.40609 best[0]=-5.173398086 best[1]=9.592135291 best[2]=9.780050221 best[3]=-8.086606726 best[4]=9.822119525 Generation=51 NFEs=2080 Strategy: DE/rand-to-best/1/exp NP=40 F=0.7 CR=0.9 cost-variance=0.026777 INFO: de36.c - Maximum number of generations reached (genmax=50) Ending optimization INFO: ASCO has ended on 'linux'.The cause for the optimization ending is also printed, in this case the maximum number of generations has been reached. The minimum obtained cost of 0.40609 is achieved after 50 generations and 2080 function evaluations. The optimization has converged as result of the low value of the cost-variance. Although this may be true, some of the best[] are close to the search range of [-10, +10]. This can be the result that toward the minimum and/or maximum value of a given vector lies the optimum point. Therefore it is advisable to increase the lower bound for best[] vectors close to -10 and the upper bond for best[] vectors close to +10.
The following ready to use optimization examples can be found in the directory examples/ of the ASCO distribution, grouped for each one of the supported simulators.
| Circuit Name | Description | ||
| inv | Digital inverter | ||
| amp3 | Three stage operational amplifier | ||
| classE | Class-E power amplifier | ||
| bandpass | Chebyshev band pass filter |
This simple circuit gives a quick introduction to the procedures that must be executed before optimizing a circuit. The complete set of files described below can be found in examples/Eldo/inv.
The fact is that circuits having only one variable makes convergence quite fast on modern computers. As such, an example will show most of the ASCO present capabilities: optimize from scratch a circuit to achieve minimum power consumption while fulfilling the design constraints; guarantee that this is valid for different process corners and also take into account device parameter mismatch (Monte Carlo).
*Digital inverter .PARAM V_SUPPLY = '#V_SUPPLY#' .PARAM INP_FREQ = '#INP_FREQ#' .PARAM INP_PERIOD = '1/INP_FREQ' .PARAM NO_PERIODS = '4' .PARAM TMEAS_START = '(NO_PERIODS-1)*INP_PERIOD' .PARAM TMEAS_STOP = '(NO_PERIODS)*INP_PERIOD' .PARAM TMEAS_1 = 'TMEAS_STOP -3*INP_PERIOD/4' .PARAM TMEAS_2 = 'TMEAS_STOP -1*INP_PERIOD/4' *** *** SUPPLY VOLTAGES *** *** VDD VDD 0 V_SUPPLY VSS VSS 0 0 *** *** INPUT SIGNAL *** *** VSIG IN VSS PULSE V_SUPPLY 0 'INP_PERIOD/2' 'INP_PERIOD/1000' + 'INP_PERIOD/1000' 'INP_PERIOD/2' 'INP_PERIOD' *** *** CIRCUIT *** *** MP OUT IN VDD VDD PMOS W='#WP#' L=#LMIN# MN OUT IN VSS VSS NMOS W='#WP#/3' L=#LMIN# CL OUT VSS 10p *** *** ANALYSIS *** *** .TRAN 'INP_PERIOD/1000' 'NO_PERIODS*INP_PERIOD' .MC 2 ALL .PROBE TRAN V(IN) .PROBE TRAN V(OUT) .OPTION EPS=1E-6 .INCLUDE p.typ .INCLUDE n.typ .END
The CMOS inverter, in which the transistor width is to be optimized has a 10 pF load capacitance. All measurements have been removed from the netlist and included in the extract/ directory.
#Optimization Flow# Alter:yes $do we want to do corner analysis? MonteCarlo:yes $do we want to do MonteCarlo analysis? AlterMC cost:3.00 $point at which we want to start ALTER and/or MONTECARLO ExecuteRF:no $Execute or no the RF module to add RF parasitics? SomethingElse: $ #
Simulation re-runs are executed immediately upon having a returned cost below 3.00. Immediately after that, and because the AlterMC cost is smaller than the returned cost from the simulation, Monte Carlo Simulation is performed. For this to occur, the line .MC 2 ALL has to be present which tells the number of simulations runs, also ALL must exist.
# ALTER # .param + V_SUPPLY=[2.0 2.1 2.2] #
As a demonstration, only three process corners are executed. For an extensive list of possible examples refer to the configuration file.
# Parameters # Supply voltage:#V_SUPPLY#:2.0:0:0:LIN_DOUBLE:--- Temperature:#TEMP#:25:0:0:LIN_DOUBLE:--- Minimal gate length:#LMIN#:0.35u:0:0:LIN_DOUBLE:--- Input frequency:#INP_FREQ#:850E6:0:0:LIN_DOUBLE:--- PMOS width:#WP#:10000u:1m:10m:LIN_DOUBLE:OPT #
The PMOS transistor width is the only optimization variable used. The other parameters are used to configure the SPICE input netlist.
# Measurements # P_SUPPLY:---:MIN:0 VHIGH:OUT:GE:1.95 VLOW:OUT:LE:0.05 #
In here, minimization of the power supply consumption is the objective. This, while meeting the constraint of having an output voltage above 1.95 V and below 0.05 V at a fourth of the signal period.
To verify that the optimization leads to a functional inverter, the binary output file containing the simulation with the best set of values obtained during the optimization is checked with the visual display of the saved output.
In the <hostname>.log file, a complete report of all simulations is stored. The last 12 lines refer to the bet test vector (Alter plus Monte Carlo). It is possible that not all lines start with “+cost”. It should nevertheless be noted that the measured values are indeed very close to the constraint values. The number of function evaluations, minimum cost and cost-variance are stored in asco.log file. The reason for ending the optimization and a brief report of the DE parameters is stored in here for convenience.
The most important place to check correct operation is in the SPICE output log file: <hostname>.chi. A meticulous analysis is mandatory.
In the event that there is a need for statistical analysis on the simulation output log file, the tool log available in tools/log/ can be used. It takes as input the optimization log file and creates a summary of all performed measurements. Should the <inputfile>.cfg exist, a more complete report is created. To use such tool, type in the command prompt
<PATH_TO_LOG>/log <hostname>.log <hostname>.log.log
to obtain a file with a summary of the measurements and also with a list of parameters to use in new optimization. However, it is better to create the new parameter list (# Parameters #) in the situation where all constraints have been met, i.e., those where the line start with +cost. Filtering lines matching a pattern is obtained using the *NIX grep command
cat <hostname>.log | grep +cost > <hostname>_good.log <PATH_TO_LOG>/log <hostname>_good.log <hostname>_good.log.log
after which a new summary can be obtained, this time with a smaller range for the parameters. With this in hand, a new re-run can be started, either to fine-tune the design or for a new and faster optimization having corners.
[Block diagram of the PFC amplifier.] ![\includegraphics[width=0.50\columnwidth]{figures/PFCBlockDiagram}](img36.png)
[Schematic diagram of the PFC amplifier.] ![\includegraphics[width=0.50\columnwidth]{figures/PFCSchematic}](img37.png) |
*Three stage operational amplifier *** *** OPAMP SUBCIRCUIT *** *** .SUBCKT PFC.SUB VP VN VOUT IBIAS VB1 AVDD AVSS M00 IBIAS IBIAS AVDD AVDD PMOS W=#WM00_10# L=#LM1# * differential pair M10 1 IBIAS AVDD AVDD PMOS W=#WM00_10# L=#LM1# M=6 M11 2 VN 1 1 PMOS W=#WM11_12# L=#LM2# M12 3 VP 1 1 PMOS W=#WM11_12# L=#LM2# * folded cascode M13 4 IBIAS AVDD AVDD PMOS W=#WM13_16# L=#LM1# M=3 M16 5 IBIAS AVDD AVDD PMOS W=#WM13_16# L=#LM1# M=3 M14 4 VB1 2 AVSS NMOS W=#WM14_17# L=#LM3# M17 5 VB1 3 AVSS NMOS W=#WM14_17# L=#LM3# M15 2 4 AVSS AVSS NMOS W=#WM15_18# L=#LM4# M18 3 4 AVSS AVSS NMOS W=#WM15_18# L=#LM4# * second stage M20 6 5 AVDD AVDD PMOS W=#WM20# L=#LM6# M22 7 IBIAS AVDD AVDD PMOS W=#WM22# L=#LM1# M21 6 6 AVSS AVSS NMOS W=#WM21_23# L=#LM5# M23 7 6 AVSS AVSS NMOS W=#WM21_23# L=#LM5# * third stage M30 VOUT 5 AVDD AVDD PMOS W=#WM30# L=#LM6# M=22 M31 VOUT 7 AVSS AVSS NMOS W=#WM31# L=#LM7# M=5 * compensation CM1 5 VOUT #CC1# CM2 5 7 #CC2# .ENDS PFC.SUB *** *** SUPPLY VOLTAGES *** *** VDD VDD 0 #VSUPPLY# VSS VSS 0 0 *** *** BIAS VOLTAGE *** *** VVB1 VB1 VSS DC #VBIAS# *** *** BIAS CURRENT *** *** IIBIAS IBIAS VSS #IBIAS# *** *** SUB-CIRCUIT *** *** XOPAMP VP VN VOUT IBIAS VB1 VDD VSS PFC.SUB *** *** LOAD *** *** RL VOUT VX #RLOAD# CL VOUT VX #CLOAD# VX VX VSS '#VSUPPLY#/2' *** *** AC LOOP *** *** VIN VP VSS '#VSUPPLY#/2' AC 1 RX VN VOUT 1m AC=1E12 CX VN VSS 10 *** *** ANALYSIS *** *** .AC DEC 100 0.001 1E9 .PZ V(VOUT) .PROBE AC VDB(VOUT) .PROBE AC VP(VOUT) .OP .OPTION NOBOUND_PHASE .INCLUDE p.typ .INCLUDE n.typ .END
#DE# choice of method:3 maximum no. of iterations:100 Output refresh cycle:2 No. of parents NP:100 Constant F:0.7 Crossover factor CR:0.9 Seed for pseudo random number generator:3 Minimum Cost Variance:1e-6 Cost objectives:10 Cost constraints:10e6 #
A random starting point is used in combination with a population size of 100 for the evolutionary optimization algorithm. The number of iterations is arbitrarily set to 100, which translates into a long optimization time. However, this allows to verify that the optimal values are no longer changing significantly.
# Parameters # Supply voltage:#VSUPPLY#:3.0:2.4:3.3:LIN_DOUBLE:--- Minimal gate length:#LMIN#:0.35U:0.35U:0.35U:LIN_DOUBLE:--- Bias voltage:#VBIAS#:1.25:1:3.0:LIN_DOUBLE:OPT Bias current:#IBIAS#:5E-6:1E-6:10E-6:LIN_DOUBLE:OPT Load capacitance:#CLOAD#:100E-12:100E-12:130E-12:LIN_DOUBLE:--- Load resistance:#RLOAD#:25E3:10E3:50E3:LIN_DOUBLE:--- C compensation 1:#CC1#:15p:2p:20p:LIN_DOUBLE:OPT C compensation 2:#CC2#:3p:2p:20p:LIN_DOUBLE:OPT Length group 1:#LM1#:0.7E-6:0.35E-6:7E-6:LIN_DOUBLE:OPT Length group 2:#LM2#:0.7E-6:0.35E-6:7E-6:LIN_DOUBLE:OPT Length group 3:#LM3#:0.7E-6:0.35E-6:7E-6:LIN_DOUBLE:OPT Length group 4:#LM4#:0.7E-6:0.35E-6:7E-6:LIN_DOUBLE:OPT Length group 5:#LM5#:0.7E-6:0.35E-6:7E-6:LIN_DOUBLE:OPT Length group 6:#LM6#:0.7E-6:0.35E-6:7E-6:LIN_DOUBLE:OPT Length group 7:#LM7#:0.5E-6:0.35E-6:7E-6:LIN_DOUBLE:OPT Width M00_10:#WM00_10#:10E-6:0.35E-6:50E-6:LIN_DOUBLE:OPT Width M11_12:#WM11_12#:40E-6:0.35E-6:50E-6:LIN_DOUBLE:OPT Width M13+16:#WM13_16#:10E-6:0.35E-6:50E-6:LIN_DOUBLE:OPT Width M14_17:#WM14_17#:6E-6:0.35E-6:50E-6:LIN_DOUBLE:OPT Width M15_18:#WM15_18#:11.01E-6:0.35E-6:50E-6:LIN_DOUBLE:OPT Width M20:#WM20#:15E-6:0.35E-6:50E-6:LIN_DOUBLE:OPT Width M22:#WM22#:10E-6:0.35E-6:50E-6:LIN_DOUBLE:OPT Width M21_23:#WM21_23#:2E-6:0.35E-6:50E-6:LIN_DOUBLE:OPT Width M30:#WM30#:1.5E-6:0.35E-6:50E-6:LIN_DOUBLE:OPT Width M31:#WM31#:1.5E-6:0.35E-6:50E-6:LIN_DOUBLE:OPT #
In order to automatically size the amplifier circuit, the netlist of the PFC amplifier is parametrized using 21 design variables (one bias voltage and current, two compensation capacitors, seven transistor lengths and ten transistor widths). The number of transistor geometry variables is somewhat reduced by taking standard analog design constraints (e.g. the matching of differential input pairs and current mirrors) into account. However, constraints on the operating point of the circuit are not included, only the performance specifications are given as input to the tool. On the one hand, this makes the design space much more complex, but on the other hand this doesn't require specific circuit knowledge.
# Measurements # ac_power:VDD:MIN:0 dc_gain:VOUT:GE:122 unity_gain_frequency:VOUT:GE:3.15E6 phase_margin:VOUT:GE:51.8 phase_margin:VOUT:LE:70 amp3_slew_rate:VOUT:GE:0.777E6 #
The original performances as in [Ram05] are taken as constraints, except for the power consumption, which is requested to be minimized.
![\includegraphics[width=0.45\columnwidth]{figures/ClassEPATransistor}](img38.png) |
*Class-E power amplifier .PARAM V_SUPPLY = '#V_SUPPLY#' .PARAM INP_FREQ = '#INP_FREQ#' .PARAM INP_PERIOD = '1/INP_FREQ' .PARAM NO_PERIODS = '#NO_PERIODS#' .PARAM TMEAS_START = '(NO_PERIODS-1)*INP_PERIOD' .PARAM TMEAS_STOP = '(NO_PERIODS)*INP_PERIOD' .PARAM T_PERC = 99 .PARAM TMEAS_AUX = (NO_PERIODS-1)*INP_PERIOD + + T_PERC/100*INP_PERIOD *** *** SUPPLY VOLTAGES *** *** * Voltages and currents VDD VDD 0 V_SUPPLY VSS VSS 0 0 *** *** INPUT SIGNAL *** *** VSIG G1 VSS PULSE V_SUPPLY 0 'INP_PERIOD/2' 'INP_PERIOD/1000' + 'INP_PERIOD/1000' 'INP_PERIOD/2' 'INP_PERIOD' *** *** INDUCTOR *** *** .SUBCKT LBOND.SUB IN OUT L=1 RBOND IN 1 '0.135*(L/1n)' ! 0.135 Ohm/mm; gold LBOND 1 OUT 'L' ! 1 nH/mm .ENDS LBOND.SUB *** *** OUTPUT STAGE *** *** * Diffusion length, MOSwidth, MOSlength and multiplier .PARAM LDIFF='1.2u' WS='#TR1_W#' LS='#LMIN#' MS='1' M1 D1 G1 VSS VSS NMOS W=WS L=LS M=MS AD='WS*LDIFF' PD='2*(LDIFF+WS)' + AS='WS*LDIFF' PS='2*(LDIFF+WS)' XL1 VDD D1 LBOND.SUB L=#L1# XL0 D1 N2 LBOND.SUB L=#L0# C0 N2 OUT #C0# .PARAM FILT_RES = #RL# R OUT VSS FILT_RES *** *** ANALYSIS *** *** .TRAN 'INP_PERIOD/1000' 'NO_PERIODS*INP_PERIOD' .PROBE TRAN V(G1) .PROBE TRAN V(D1) .PROBE TRAN V(OUT) .OP .OPTION EPS=1E-6 .INCLUDE n.typ .END
The above file represents a class-E amplifier with a NMOS transistor acting as a switching device. Minimum inductor parasitics, using SPICE language, are included by the fact of the LBOND.SUB sub-circuit.
# DE # choice of method:3 maximum no. of iterations:50 Output refresh cycle:2 No. of parents NP:60 Constant F:0.85 Crossover factor CR:1 Seed for pseudo random number generator:3 Minimum Cost Variance:1e-6 Cost objectives:10 Cost constraints:100 #
The three control parameters controlling the optimization algorithm and that must be chosen by the user: NP, F and CR are set to 60, 0.85 and 1, respectively.
# Parameters # Supply voltage:#V_SUPPLY#:2.0:0:0:LIN_DOUBLE:--- Temperature:#TEMP#:25:0:0:LIN_DOUBLE:--- Minimal gate length:#LMIN#:0.35u:0:0:LIN_DOUBLE:--- Input frequency:#INP_FREQ#:850E6:0:0:LIN_DOUBLE:--- No of sim periods:#NO_PERIODS#:50:0:0:LIN_DOUBLE:--- TR1 width:#TR1_W#:1600.0u:5000u:20000u:LIN_DOUBLE:OPT L1 inductance:#L1#:38.2n:0.1n:10n:LIN_DOUBLE:OPT L0 inductance:#L0#:14.4n:0.1n:10n:LIN_DOUBLE:OPT C0 capacitance:#C0#:4.82p:10p:70p:LIN_DOUBLE:OPT Load resistance:#RL#:27.9:1:10:LIN_DOUBLE:OPT #
In first three lines above, inputs for the SPICE simulation are shown. The next five lines configure the parameters to be optimized with the bounding range for each one of the circuit components.
# Measurements # P_SUPPLY:---:MIN:0 P_OUT:OUT:GE:0.5 VDSOFF:D1:LE:0.2 SLOPEOFF:D1:LE:9E9 VDSON:D1:LE:0.2 VMIN:D1:GE:-0.2 #
The above category describes minimization of the power supply (the only objective) while meeting all other five constraints, specifically an output power of at least 0.5 W. The remaining four performance goals, ensure correct operation of the circuit as a class-E amplifier.
The minimization of the power supply while constraining the output power to be higher than 0.5 W is equivalent to maximizing the drain efficiency, thus the cost function has only one objective.
The character separated value makes importing to a spreadsheet easy where performance trade-offs among the various optimized circuit solutions can be studied: results in which the DC-feed inductance (L1) is below a certain threshold although the output power is less than the desired 0.5 W; all the cases where when transistor turns on, the voltage across the transistor drain is below than 0.2 V; etc. However, for situations where all constraints must strictly be met, the simple following shell command can be typed in the command prompt, to filter only those solution that have met all performance goals.
cat <hostname>.log | grep +cost > good.log
The same spreadsheet can again be used to analyze all results resting assured that only those where the design constraint have been met are shown.
The RF module described in Section 7.5 can be used for situations when is of paramount importance to consider parasitic effects in a circuit. To this end, the circuit can have the necessary devices to describe a real world implementation, including chip, packaging and board parasitics. Considering them during the optimization, leads to a closer match between simulations and lab measurements. All the files are available at examples/Eldo/bandpass.
[Magnitude constraints tolerance scheme.] ![\includegraphics[width=0.45\columnwidth]{figures/BPConstraints}](img39.png)
[Circuit topology.] ![\includegraphics[width=0.45\columnwidth]{figures/BPTopology}](img40.png)
[Equivalent of (b) with parasitics automatically added by the RF module during the optimization loop.] ![\includegraphics[width=0.45\columnwidth]{figures/BPTopologyFullParasitics}](img41.png)
|
*Chebyshev Band Pass Filter *** *** FILTER CIRCUIT *** *** C1 1 0 #C1# ! #CSMD_50p80p# L1 1 0 #L1# ! #LBOND_350p450p# L2 1 2 #L2# ! #LBOND_60n100n# C2 2 3 #C2# ! #CSMD_300f340f# C3 3 0 #C3# ! #CSMD_50p80p# L3 3 0 #L3# ! #LBOND_350p450p# *** *** PORT *** *** V1 1 0 iport=1 rport=50 V2 3 0 iport=2 rport=50 *** *** ANALYSIS *** *** .AC DEC 1000 800e6 1200E6 .PROBE AC SDB(1,1) .PROBE AC SDB(2,1) .END
The above text, describes a three pole Chebyshev band pass filter. The user-defined device models, are specified after the in-line comment specific to each one of the simulators used. Refer to Section 7.5 for a detailed description of its usage.
#Optimization Flow# Alter:no $do we want to do corner analysis? MonteCarlo:no $do we want to do MonteCarlo analysis? AlterMC cost:1.00 $point at which we want to start ALTER and/or MONTECARLO ExecuteRF:yes $Execute or no the RF module to add RF parasitics? SomethingElse: #
The difference to note is the definition of ExecuteRF setting to require the inclusion of RF parasitics in the netlist.
#DE# choice of method:3 maximum no. of iterations:100 Output refresh cycle:2 No. of parents NP:30 Constant F:0.7 Crossover factor CR:0.9 Seed for pseudo random number generator:3 Minimum Cost Variance:1e-6 Cost objectives:10 Cost constraints:1000 #
Above, normal settings for an optimization. Increase the number of parents to achieve better results at the expense of a longer simulation time.
# Parameters # C1:#C1#: 64.415p: 50p: 80p:LIN_DOUBLE:OPT L1:#L1#: 393.233p:350p:450p:LIN_DOUBLE:OPT L2:#L2#: 79.107n: 60n:100n:LIN_DOUBLE:OPT C2:#C2#: 320.205f:300f:340f:LIN_DOUBLE:OPT C3:#C3#: 64.415p: 50p: 80p:LIN_DOUBLE:OPT L3:#L3#: 393.233p:350p:450p:LIN_DOUBLE:OPT #
Each one of the filter components is defined as an optimization variable. It is based on this device value that the parasitics are found and added to the netlist by the RF module.
# Measurements # Left_Side_Lobe:---:LE:-20 Pass_Band_Ripple:---:GE:-1 Right_Side_Lobe:---:LE:-20 S11_In_Band:---:MAX:--- #
The first three lines define the magnitude constraints tolerance scheme as shown in Fig. 6.4(a). The objective, maximization of the in-band S11, is given in the last line. Considering that in extract/ it is defined as -S11, as result, the optimizer minimizes the in-band return loss (S11) value.
The other important file is in this case the place where the parasitic definition resides. In the file rfmodule.cfg, the following information can be found.
* This is the RFModule technology file describing circuit parasitics *for a given process (CMOS, Bipolar, etc) # Possible devices: resistor, capacitor and inductor. #CSMD# Device:capacitor Terminal:IN OUT CSMD IN 1 C RSMD 1 2 R LSMD 2 OUT L # # At this moment, the first device in each line # must be R for a resistor, C for a capacitor and # L for an inductor. Furthermore, the values in the # first column must be in ascending order, otherwise... #300f340f# C=300f R=1m L=0.01n C=320f R=2m L=0.01n C=340f R=3m L=0.01n # #50p80p# C=50p R=5m L=0.010n C=70p R=7m L=0.015n C=80p R=8m L=0.020n # #LBOND# Device:inductor Terminal:IN OUT LBOND IN 1 LS RBOND 1 OUT RS # #350p450p# LS=350p RS=0.0042 LS=450p RS=0.0054 # #60n100n# LS=60n RS=0.718 LS=100n RS=1.196 #
Two devices, one capacitor and one inductor are defined in parallel with the sub-circuit model and device range. Section 7.5 break down the format used in the parasitics configuration file.
The example is given as a demonstration of capability of using device parasitics during the optimization loop. The components in the rfmodule.cfg show extremely low parasitics and do not represent accurate real world values. However, this example has shown how simple it can be to consider parasitics effects during an optimization loop.
Examples
./asco -hspice inv
./asco -hspice amp3
./asco -hspice classE
./asco -hspice bandpass
LTspiceTM runs well under GNU/Linux using (Wine which is an Open Source implementation of the Microsoft Windows API on top of X and *NIX). A shell script must exist so that the simulator can be executed by typing ltspice in the command line. As an example, the following script file can be used:
#! /bin/sh wine -- "<PATH_TO_SCAD3>/LTC/SwCADIII/scad3.exe" $1 $2
while in a win32 platform, create instead the batch file ltspice.bat with
"C:/Program Files/LTC/SwCADIII/scad3.exe" %1 %2
Only for this particular simulator, the log filename is named <hostname>.log.log because the output from the simulator already has the .log extension.
If the netlist was created using LTspiceTM, the end-of-file is different than that used in *NIX. As such, the text file must be converted. Use for example the following command:
dos2unix <inputfile>.net
./asco -ltspice inv
./asco -ltspice amp3
./asco -ltspice classE
./asco -ltspice bandpass
Examples
, a non SPICE circuit simulator is implemented. As a result of this, simulation re-runs (using the altergroup command) and Monte Carlo analysis are currently not functional.
Although the MDL language has the capability to execute multiple simulations, only one type, currently limited to dc, ac and tran, can exist in the <inputfile>.scs without manual editing <hostname>.mdl file and changing one (1) line in the C source file. E-mail the developer if you need assistance.
./asco -spectre inv
./asco -spectre amp3
./asco -spectre classE
./asco -spectre bandpass
The main advantage of this free simulator is allowing both programs to be built as monolithic executables. The exchange of information can then be performed in memory resulting in tenfold gain in optimization time for simulations that take a few seconds to run.
./asco -qucs bandpass
./asco -ngspice inv
./asco -ngspice amp3
./asco -ngspice classE
./asco -ngspice bandpass
To allow the usage of different simulators that have distinct input arguments, the shell script general.sh is executed by ASCO. It is this executable that calls the appropriated simulator with the necessary options. An example of which is given below.
#! /bin/sh ./rosen $1.txt $2.out > /dev/null
# Parameters # Constant F:#F#:0:0:2:LIN_DOUBLE:OPT Crossover factor CR:#CR#:0:0:1:LIN_DOUBLE:OPT #
# Measurements # COST:---:MIN:0 #
tar -zxvf ASCO-<version>.tar.gz cd ASCO-<version> make -B cp asco examples/rosen/ # Rosenbrock's function cd examples/rosen/bin make cp rosen .. cd .. #Execute optimizer ./asco -general rosen.txt
+cost:4.930381E-31: COST:4.930381E-32: F:4.629414E-01:CR:6.327368E-01:
being as such F=4.629414E-01 and CR=6.327368E-01 in conjunction with the other control parameters in the file rosen.dat, the best set of values to solve the Rosenbrock Function (6.1).
A set of external functions have been developed as a “plug-and-play” extension of the original functionality of ASCO. Some of them have been integrated into the optimization flow, while others are intended to help analyzing the optimization results. Not all simulators are supported in each one of the tools.
), altergroup (in Spectre) and altermod/alter (in ngspice) are entered here.
# ALTER # .protect .inc [slow.mod typ.mod fast.mod] .unprotect .temp [-40 +25 +85] .param V_SUPPLY=[2.0 2.1 2.2] .param Ibias=[0.7 1.3] #
The above line format is dependent on the selected SPICE simulator due to the existing variations in the input format. The exactly same type of parameters, devices and commands available with the SPICE simulator can be used in here. To test PVT corners, the options must be enclosed in square brackets ([ ]) with only one space character between them. For example, if only one line exists and is the following:
.inc [slow.mod typ.mod fast.mod]
upon expansion, three re-runs will be executed for the same netlist:
.ALTER @1 .inc slow.mod .ALTER @2 .inc typ.mod .ALTER @3 .inc fast.mod
A total of
re-runs for the complete above example for EldoTM are necessary before the cost value can be obtained and returned to the optimizer. Use only the necessary lines, because upon expansion (to all possible combinations), the total number of simulation re-runs can rapidly grow, with the consequent increase in the optimization time. Besides the speed, no other caution seems to exist at this time.
Should a file with the name alter.inc exist in the running directory, this file is included in the netlist instead of adding the parameters in the category. This is useful in cases where it is important to use an existing file with re-run commands.
The alter tool can be used integrated in the ASCO optimization flow or as a standalone program. In this case, a file named alter.inc having the #ALTER# commands is created, which can then be included in the simulation netlist.
a restriction exist in that the command altergroup must be present and must be also the first line in the configuration file after the #ALTER# category name. Use for example
![\includegraphics[width=0.25\columnwidth]{figures/Inverter}](img35.png)
# ALTER #
ag altergroup {
simulatorOptions options temp=[-40 +25 +85]
parameters xvdd=[2.0 2.1 2.2]
include "n.typ" section=[slow typ fast]
}
dcOp_ag dc oppoint=logfile
dcOp dc oppoint=logfile
#
./alter -<eldo|hspice|spectre|ngspice> <configfile>
./log <hostname>.log <outputfile>
#Monte Carlo# NMOS_AVT:12.4mV $ This values will be divided by sqrt(2) by the program NMOS_ABETA:7.3% $ 'm' parameter is taken into account PMOS_AVT:10.9mV $ PMOS_ABETA:3.7% $ SMALL_LENGTH:0.0um $ Small transistors if l<= SMALL_LENGTH SMALL_NMOS_AVT:20mV $ Small transistors parameters SMALL_NMOS_ABETA:10% $ SMALL_PMOS_AVT:10mV $ SMALL_PMOS_ABETA:5% $ R_DELTA:0.333% $ Resistors matching at 1 sigma between two resistors L_DELTA:0.333% $ Inductors matching at 1 sigma between two inductors C_DELTA:0.333% $ Capacitors matching at 1 sigma between two capacitors #
Parameters describing device parameter mismatch following the Pelgrom's MOS transistor models are defined in here. Only the numerical values between the colon and the unit can be changed. This is also possible for circuit passives: resistors, inductors and capacitors.
The monte tool can be used integrated in the ASCO optimization flow or as a standalone program. In both cases, a file named <inputfile>.mc having the Monte Carlo parameters is created, which can then be used as the input simulation netlist.
./monte -<eldo|hspice> <inputfile>.* <configfile>
# Post Processing # #
Sometimes it is necessary to further manipulate a given value to obtain the final measurement. Some situations where this functionality is useful is:
To this end, the flexible post-processing language implemented allows to parse data existing in the output file and manipulate it to obtain values that are otherwise not possible. The general syntax is implemented in the MEASURE_VAR command where the values are in a colon separated list. The maximum number of measurements, i.e., the number of MEASURE_VAR lines is only limited by the memory available. The value is hardcoded in the C code and can be changed as desired. Each one of the five parameters that can be used are now described:
The name to give to the measurement (arbitrary).
The string that is to be found. Depending on the measurement type, it must be an exact match.
The beginning column position where the search string specified in SEARCH_FOR must exist to obtain a valid result.
The number of lines (below the line where exists a string match) to read before extracting the measurement.
The number of columns range within which the data is to be measured.
Enters in math mode and thus enables manipulation of data already measured.
Four simple type variations have been implemented, being each one of them better tailored to a given application with the goal to minimize user work.
MEASURE_VAR:UGF: SEARCH_FOR:' UGF =': S_COL:01: P_LINE:00: P_COL:09:18
will look for the ' UGF =' (without the quotation marks but including the spaces), starting at position 1, the first character of the line, and print what is in the current line between columns 9 and 18. As such, 7.6280E-04 will be read to variable UGF if the following line exist in the text file to be processed:
UGF = 7.6280E+04
As an example, the same measurement can be performed by using instead, each one of the following examples
MEASURE_VAR:UGF: SEARCH_FOR:'UGF =': S_COL:02: P_LINE:00: P_COL:09:18 MEASURE_VAR:UGF: SEARCH_FOR:' UGF = ': S_COL:01: P_LINE:0: P_COL:8:18 MEASURE_VAR:UGF: SEARCH_FOR:'UGF = ': S_COL:02: P_LINE:0: P_COL:9:18 MEASURE_VAR:UGF: SEARCH_FOR:'UGF = ': S_COL:02: P_LINE:0: P_COL:8:18 MEASURE_VAR:UGF: SEARCH_FOR:'GF = ': S_COL:03: P_LINE:00: P_COL:09:18
MEASURE_VAR:UGF: SEARCH_FOR:' UGF =' MEASURE_VAR:UGF: SEARCH_FOR:'UGF =' MEASURE_VAR:UGF: SEARCH_FOR:' UGF = '
MEASURE_VAR:m00: SEARCH_FOR:'M00': P_LINE:vth: vgs: id MEASURE_VAR:m00: SEARCH_FOR:'M00': P_LINE: 9: 6: 3 MEASURE_VAR:m00: SEARCH_FOR:'M00': P_LINE:vgs: vth: vds: MEASURE_VAR:m00: SEARCH_FOR:'M00': P_LINE:vgs :vgs-vth: vds-vdsat
format with the exception of 'ˆ' which is the square function. MATH is the only parameter allowed. To access data already in memory the character & must be used when referring to a variable. For example, upon reading some data
MEASURE_VAR: a: SEARCH_FOR:'M00': P_LINE:vgs MEASURE_VAR: b: SEARCH_FOR:'M10': P_LINE:vth
operations on the previous values are possible as described:
MEASURE_VAR:20*log(a/b): MATH:&a: &b: /: log10: 20: * MEASURE_VAR:a+b : MATH:&a: &b: + MEASURE_VAR:abs(a) : MATH:&a: abs MEASURE_VAR:a^2 : MATH:&a: ^
The postp tool can be used integrated in the ASCO optimization flow or as a standalone program. In this case, up to three files: nosat.txt, summary.txt and <inputfile>.?jr can be created. The first has a report of the transistors that are not simultaneously in strong inversion (
<
+margin) and saturation (
<
+margin); a synopsis of the measurements is available in the summary.txt; in the last file, the output simulation file is updated with the operating state of the CMOS transistors. The standalone program, also accepts a few other parameters that can be added to the correct category.
# Post Processing # CREATE_LJR:yes PRECISION:3 VOVD:150mV VOFF:100mV VDST:100mV SKIP_NOSAT=0:mi1*; 0:mi2/i7; 0:mi3*; 0:mi4/i23 SKIP_NOSAT=0:mi0/i14 #
Each one of the reserved words above can be used to fine-tune the comments and operating point of the electric simulation output file. A description follows:
Possibilities are yes or no. Useful when it is only necessary to extract the measurements, using the MEASURE_VAR command.
Numeric precision of the results printed to summary.txt. Not yet implemented.
Overdrive voltage margin: if <+VOVD, the transistor is in the weak inversion region.
Off voltage margin: if <-VOFF the transistor if in the off region.
Saturation voltage margin: if <+VDST the transistor is in the linear region.
Skips from the nosat.txt file, all transistors in the semicolon separated list, or all those with the given prefix if the asterisk (*) exists. More than one line can be used.
./postp -<eldo|hspice|ltspice|spectre> <inputfile>.* <configfile>
The file format of rfmodule.cfg is composed by groups of subcircuit definition and variable sets of tabled data to describe either different devices, different maximum operating current or different layout information.
* This is the RFModule technology file describing circuit parasitics *for a given process (CMOS, Bipolar, etc) # Possible devices: resistor, capacitor and inductor. #CSMD# Device:capacitor Terminal:IN OUT CSMD IN 1 C RSMD 1 2 R LSMD 2 OUT L # # At this momment, the first device in each line # must be R for a resistor, C for a capacitor and # L for an inductor. Furthermore, the values in the # first column must be in ascending order, otherwise... #1p5p# C=1p R=250m L=1n C=2p R=250m L=1n C=4p R=250m L=1n C=5p R=260m L=1.1n # #5p7p# C=5p R=260m L=1.1n C=7p R=300m L=1.5n # #7p9p# C=7p R=300m L=1.5n C=9p R=320m L=1.6n #
The above example describe the device #CSMD# as being a capacitor with IN OUT as the two nodes of the subcircuit. The next three lines describe the circuit components. After the subcircuit definition, the tabled values for each one of the devices is given. In the example, keys #1p5p#, #5p7p# and #7p9p# are different groups of characterization data. Arbitrary key names can be used, as long as it matches the symbol in the circuit input netlist file exactly.
The first line in the subcircuit definition is the device having parasitics, while the first column is always the device value with the following columns representing the parasitics.
To not interfere with the normal electric simulator flow, devices having parasitics have this instruction after the in-line comment, which is specific for each simulator. As an example, in the following SPICE input netlist for the case of EldoTM, it must be placed after the ! character.
C0 1 2 3p C1 1 2 3p ! C2 1 2 3p ! #CSMD_1p5p# C3 1 2 #C0# C4 1 2 #C0# ! C5 1 2 #C0# ! #CSMD_1p5p# C6 1 2 #C0# ! #CFLUX_1p5p# xC7 1 2 CSMD.SUB C=1 R=1 xC8 1 2 CSMD.SUB C=1 R=1 ! xC9 1 2 CSMD.SUB C=3p R=_RF_ L=_RF_! #1p5p# xCA 1 2 CSMD.SUB C=#C0# R=_RF_ L=_RF_ ! #1p5p# xCB 1 2 CFLUX.SUB C=#C0# R=_RF_ L=_RF_ ! #1p5p# L0 1 2 #L0# ! #LSMD_1nH390nH# xL1 1 2 LSMD.sub L=390n R2=_RF_ k=_RF_ C1=_RF_ R1=_RF_ ! #1nH390nH#
, but where the input parameter is only 
. In this situation, place the necessary parameter after the in-line comment that is specific to the simulator to use.
#LSMD#
Device:inductor
Terminal:IN OUT
LL 3 OUT L
RR2 IN 1 R2
RRV 1 3 VALUE={k*sqrt(FREQ)} ! k
CC1 1 2 C1
RR1 2 OUT R1
#
#1nH390nH#
L=1.6n R1=2 R2=0.001 C1=0.030p k=6.50E-06
L=10.0n R1=35 R2=0.010 C1=0.043p k=2.64E-05
L=21.9n R1=13 R2=0.050 C1=0.054p k=4.80E-05
L=51n R1=30 R2=0.010 C1=0.050p k=1.17E-04
L=100n R1=25 R2=0.010 C1=0.060p k=2.34E-04
L=390n R1=41 R2=1.052 C1=0.059p k=7.69E-04
#
Although designed to be an encapsulation of a SPICE simulator, the netlist parser is programmable which means it can read any ASCII file and look for a particular sequence of characters. About 100150 new lines of code are required, taking in total less than 2 hours for a new simulator to be added. Consequently, it is not specific to SPICE simulators. However, a higher degree of work is necessary if the simulator flow differs from those simulators that are already implemented.
which has number 2, and so on. Open source simulators start at number 50 to make possible to add more commercial simulators in the future, while keeping some logic in the numbering.
Depending on the intended level of support by ASCO, more or less code and files will have to edited. Basically, all switch(spice) code sections will have to be adapted to the new simulator. If it bares resemblance to another already supported, just adding a case will be enough. Otherwise, the difficulty really depends on how well support for the new simulator is desired.
Another option is to compile the code, run ASCO and read the file and section were the programs exits. Correct the code, compile and execute ASCO again and wait until all things run well. Certainly, not the best way.
DE(argc, argv); /*Rainer Storn and Ken Price Differential Evolution (DE)*/
Within the optimization algorithm code, replace where appropriate, every call to the function evaluation by the new evaluation function
evaluate(int D, double x[], char *filename); /* obj. funct. */
Above, D is number of parameters of the cost function, x contains the parameters proposed by the optimizer routine, and finally, filename is the SPICE file containing the netlist to optimize.
Edit the Makefile to include the new source file. Then, simply compile the code with make. The new optimization algorithm is then ready to be used by ASCO.
Obviously, you can also contribute new code, either adding new functionalities or correcting implementation errors.
Simply saying that a bug exist does not help much. Your results have to be adequately transmitted as well. Also, please understand that we live in a busy world. Your contribution is not forgotten if it takes more time than what you find reasonable. Furthermore, please understand that you might be asked further clarification. Besides this, follow all instructions below closely:
A useful text on how to ask questions is available in guide How To Ask Questions The Smart Way by Eric S. Raymond.
The idea of creating the ASCO project came out of a discussion with S. Xavier-de-Souza and the concepts around optimization algorithms and its applications. The result of which being, that although ASCO is intended to interact with zero effort with a SPICE simulator, only a handful lines of code are necessary to add support to a completely new simulator, as long as the simulator reads from text files, writes its output in ASCII and it can be launched from the command line.
The Internet is home to a huge amount of information it is not as nicely presented as in Wikipedia. No verbatim copy is done but some ideas where developed after reading its pages.
This document was generated using the LaTeX2HTML translator Version 2021.2 (Released July 1, 2021)
The command line arguments were:
latex2html -split 0 ASCO.tex
The translation was initiated on 2022-01-19