AgO User's Manual

Schematic

AnXplorerUser’s Manual

2012.10

Centering

Optimization

AnXplorer:

User’s ManualSoftware version

2012.10

c© 2007-12 AgO Synthesis LLP.All rights reserved

This document contains information that is proprietary to AgO Synthesis LLP. The original re-

cipient of this document may duplicate this document in whole or in part for internal business

purposes only, provided that this entire notice appears in all copies. In duplicating any part of this

document, the recipient agrees to make every reasonable effort to prevent the unauthorized use

and distribution of the proprietary information.

This document is for information and instruction purposes. AgO Synthesis LLP (AgO) reserves

the right to make changes in specifications and other information contained in this publication

without prior notice, and the reader should, in all cases, consult AgO to determine whether any

changes have been made.

AgO Synthesis LLP makes no warranty of any kind with regard to this material including, but

not limited to, the implied warranties of merchantibility and fitness for a particular purpose.

License Agreement

Limited Liability

In no event unless required by applicable law or agreed to in writing will any copyright holder, or

any other party, be liable for dameages, including any general, special, incidental or consequential

damages arising out of the user or inability to use the program AnXplorer (including by not limited

to loss of data, or data being rendered inacurrate or losses sustained by you or third parties or a

failure of the program to operate with any other programs), even if such holder or other party has

been advised of the possibility of such damages. AgO is not liable for circuit manufacturability and

failures after devices are manufactured. Users of AgO product AnXplorer are advised to contact

manufacturing vendors to validate the design with respect to Spice models used in AnXplorer

program. AnXplorer comes with no warranty.

Manufacturer is:

AgO Synthesis LLP

http://www.ago-inc.com

[email protected]

Contents

1 Introduction 8

1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.2 Product offering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3 Overview of product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Setting up AnXplorer 12

2.1 Supported operating systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Installation of AnXplorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1 License file setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3 Supported simulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Using AnXplorer in standalone graphical mode 16

3.1 A project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2 Inputs to AnXplorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3 The main GUI window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.4 Variable definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.5 Options definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.5.1 Selecting the simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.5.2 Specifying command line options for the simulator . . . . . . . . . . . . 24

c© 2007-12 AgO Synthesis LLP Proprietary and Confidential

3.5.3 Enabling multi-threading . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.5.4 Specifying the optimization stop criteria . . . . . . . . . . . . . . . . . . 25

3.5.5 Specifying the centering options . . . . . . . . . . . . . . . . . . . . . . 26

3.5.6 Selecting the global optimization algorithm . . . . . . . . . . . . . . . . 27

3.5.7 Logarithmic partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.5.8 Specifying the PVT corners . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.6 Technology specific parameter definition . . . . . . . . . . . . . . . . . . . . . . 30

3.6.1 Sizing rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.6.2 Using the technology parameter GUI . . . . . . . . . . . . . . . . . . . . 33

3.7 Analysis and target definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.7.1 Including a target in the feasibility analysis mode . . . . . . . . . . . . . 37

3.7.2 Selecting corners for an analysis . . . . . . . . . . . . . . . . . . . . . . 37

3.7.3 Operating point analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.7.4 Noise analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.7.5 Post-processing function based analysis . . . . . . . . . . . . . . . . . . 43

3.7.6 Using a custom postprocessor . . . . . . . . . . . . . . . . . . . . . . . . 44

3.7.7 Monte Carlo simulation based analysis . . . . . . . . . . . . . . . . . . . 46

3.7.8 User defined equation based analysis . . . . . . . . . . . . . . . . . . . . 47

3.8 Cost graph definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.8.1 Disabling cost graph rearragement . . . . . . . . . . . . . . . . . . . . . 51

3.8.2 Score calculation using the cost graph . . . . . . . . . . . . . . . . . . . 51

3.9 Running AnXplorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.9.1 Running a test simulation . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.9.2 Running feasibility analysis . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.9.3 Running global optimization . . . . . . . . . . . . . . . . . . . . . . . . 57

3.9.4 Running feasibility analysis and global optimization over multiple corners 58

3.9.5 Running in design centering mode . . . . . . . . . . . . . . . . . . . . . 58

3.9.6 Running all steps automatically . . . . . . . . . . . . . . . . . . . . . . . 60

3.9.7 Running in design porting mode . . . . . . . . . . . . . . . . . . . . . . 61

3.9.8 Manual tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.10 Database query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.11 Contents of the project directory . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4 Preparing a design for optimization in the standalone graphical mode 67

4.1 Usage with ADE using OCEAN scripts . . . . . . . . . . . . . . . . . . . . . . . 68

4.1.1 Creating the Spectre netlists and OCEAN scripts . . . . . . . . . . . . . 68

4.1.2 Preprocessing the OCEAN scripts . . . . . . . . . . . . . . . . . . . . . 70

4.1.3 Editing the Spectre netlist . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.1.4 Preprocessing the CDL netlist . . . . . . . . . . . . . . . . . . . . . . . 71

4.1.5 License queueing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.1.6 Usage with Finesim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.2 Usage with Hspice, SmartSpice, Eldo, Finesim and Msim with Spice format inputs 72

4.3 Usage with Dspice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5 Using AnXplorer within the Cadence Virtuoso design environment 74

5.1 Enabling AnXplorer menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.2 A project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.3 Variable definition, options definition, and technology specific parameters . . . . 76

5.4 Analysis and target definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.5 Running AnXplorer and back-annotating variable values into the cell view . . . . 80

6 Using AnXplorer from command line 82

6.1 The configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.1.1 Lexical convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6.1.2 Variable definition section . . . . . . . . . . . . . . . . . . . . . . . . . . 84

6.1.3 Optimizer options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6.1.4 Specifying the technology specific parameters . . . . . . . . . . . . . . . 88

6.1.5 Analysis and target definition . . . . . . . . . . . . . . . . . . . . . . . . 90

6.1.6 Cost graph definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

7

6.2 Technology specific parameter file . . . . . . . . . . . . . . . . . . . . . . . . . 96

6.3 Initial design point specification . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

6.4 Running AnXplorer from the command line . . . . . . . . . . . . . . . . . . . . 97

6.5 Outputs of AnXplorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

6.5.1 Log file format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

6.5.2 Contents of the output directory . . . . . . . . . . . . . . . . . . . . . . 99

7 Using the database query language 101

7.1 Running the database queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

7.2 The query language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

7.2.1 Objective names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

7.2.2 Database entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

7.2.3 Primary keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

7.2.4 Data sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

7.2.5 Data set operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

7.2.6 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

7.2.7 Displaying results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

7.2.8 Structure of the query file . . . . . . . . . . . . . . . . . . . . . . . . . . 106

8 Examples of input files to AnXplorer 108

8.1 Netlist file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

8.2 Configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

8.3 Technology parameter file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

8.4 Database query file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

8.5 OCEAN script example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

8.6 Spectre netlist example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118


CHAPTER 1

Introduction

1.1 Background

Demand for efficient analog circuits has grown significantly over the last few years for ap-plication in faster and low-power devices. As a resuilt, Analog and Mixed Signal (AMS) IC(Integrated Circuit) industry has grown much faster than the overall semiconductor IC mar-ket. Such explosive growth comes with the challenge of producing much more in a shortertime. The industry, therefore, requires proper automation of effort intensive stages in thedesign flow. One such stage is design optimization.

1.2 Product offering

AnXplorer is a software solution for simulation based synthesis/optimization of general ana-log and radio frequency (RF) circuits by efficient design space exploration. It can be used bycircuit designers to quickly explore different circuit schematics to identify the right choice. Italso helps in finding a robust design solution against variations in the manufacturing process,temperature and supply voltage. It takes an unsized SPICE netlist along with design speci-fications and constraints, and produces an optimized and centered netlist. It uses a SPICEsimulator to evaluate the target design. It supports design-equation based optimization aswell.


Overview of product 9

1.3 Overview of product

Inputs

AnXplorer takes as input the following:

1. A SPICE netlist of the circuit to be optimized, and/or a set of design equations whichthe user wants to optimize.

2. A set of design objectives. AnXplorer will optimize the given circuit such that it meetsthese design objectives.

3. A set of design variables. AnXplorer can change the values of these variables in orderto optimize the circuit. These variables should represent device dimensions or values.In the input netlist, the dimensions or values of the devices which the user wants tooptimize, should be represented by these variables.

4. A set of “corners” — these include manufacturing process corners (e.g. slow, typical,fast, etc.), different temperatures and different supply voltage values. Total numberof corners is equal to number of process corners × number of temperature values ×number of supply voltage values. AnXplorer optimizes the circuit to ensure that thedesign objectives are met across these corners.

Outputs

The outputs of AnXplorer is an optimized and centered netlist which meets or exceeds thespecified design objectives. It reports several optimal results found and the user can choosebetween them. In addition, it also produces an exploration database — a persistent storagefor all design points explored by AnXplorer during the process of optimization. It is storedas a relational database. This database can be queried using an easy-to-use query language.It can be used for effective trade-off analysis between conflicting design objectives (e.g. noiseand area, speed and power, etc.), or to find the limits of achievable performance.

The inputs and outputs of AnXplorer are shown pictorially in figure 1.1.

Capabilities

• AnXplorer has a fast convergence algorithm which enables it to quickly reach a solution.Thus, a designer can quickly explore the feasibility of different circuit topologies for aparticular purpose. It also has circuit-specific intelligence built into it, which eases thetask of the designer to specify the design objectives.


10 Introduction

Figure 1.1: Inputs and outputs of AnXplorer

• It supports all types of devices and processes, and is not limited to CMOS processesonly.

• It uses a SPICE simulator in the background to evaluate performances of differentpoints in the user defined design space. Currently, it is integrated with commercialsimulators HSpice[3] (from Synopsys, Inc.), Spectre[4] (from Cadence Design Systems,Inc.), SmartSpice[5] (from SILVACO, Inc.), Msim[6] (from Legend Design Technology,Inc.), Eldo[7] (from Mentor Graphics Corp.) and AgO’s own SPICE simulator DSpice.

• The graphical user interface (GUI) of AnXplorer has two modes.

– A “stand alone” mode, for usage with non Cadence simulators and design environ-ments. Here, the GUI is invoked from a command prompt.

– A mode which is completely integrated with the Cadence Virtuoso design environ-ment. In this mode, the tool is invoked via a menu button within the schematiceditor window. It can extract design variable names and create netlists by read-ing the Cadence database. It can also annotate design variable values into thedatabase. The calculator functions from Cadence Analog Design Environment(also known as Analog Artist) can be used to define design objectives.

More detailed description of the tool can be found in the subsequent chapters of thisdocument.

This manual is organized as follows:


Overview of product 11

• Chapter 2 describes the installation and setup process of the tool.

• The stand alone graphical user interface of the tool is described in Chapter 3.

• The graphical user interface of the tool, within the Cadence Virtuoso design environ-ment, is described in Chapter 4.

• Chapter 5 describes the command line mode of usage.

• The database query language for the exploration database is described in Chapter 6.

• The flow for preparing the design netlists for optimization is described in Chapter 7.Though this step is usally done first during optimization, it is described at a laterstage (after describing the input setup for AnXplorer) so that the user understands therationale behind the steps more easily.

• Finally, in Chapter 8, we present an example of an optimization setup.


CHAPTER 2

Setting up AnXplorer

2.1 Supported operating systems

At present, AnXplorer is available for the Linux operating system. The following versions aresupported:

• Red Hat Enterprise Linux 5, Kernel version 2.6.18-194 and above, both 32 bit and 64bit versions.

• Ubuntu 10.04, Kernel version 2.6.28-11-generic, 32 bit only.

2.2 Installation of AnXplorer

Unpacking and installing the distribution

The AnXplorer distribution is in the form of a gzip’ed tar file ago-<version>.tar.gz. Unzipand unpack this distribution in a suitable directory with a command like this:

% tar -zxf ago-<version>.tar.gz

This will create a directory called AgO.<version>. For example, for the 2011.07 release, thedirectory created will be called AgO.2011.07.


Installation of AnXplorer 13

To install the package, please invoke the script install.csh in the AgO.<version>

directory from a command prompt. This will setup the required library paths. You need tohave a functional internet connection for this to work, since this downloads some Tcl packagesfrom external repositories.

Editing the setup file

The file setup.csh in the directory AgO/<version> needs to be edited to reflect the path ofthe installation. Edit the value of the environment variable AGO ROOT which is set in this file.For example, if you have unpacked the distribution in the directory /home/<you>/test, thenset the value of this variable to /home/<you>/test/AgO.<version>. You will also need toedit the value of the variable AGO LICENSE FILE as described in section 2.2.1

2.2.1 License file setup

You should have received a license file for AnXplorer along with the release. If not, pleasecontact us at AgO Inc. By default, the license file is present in the subdirectory license ofthe AgO directory. However, it can be placed at any location.

Node locked license

If your license is a node-locked one (which will work only on a specific machine), then edit thesetup.csh file and set the value of the AGO LICENSE FILE variable to reflect the path of thelicense file that you received. With a node locked license, you can invoke unlimited numberof instances of AnXplorer in parallel, but on a single machine.

Floating license

For using a floating license, you need to follow these steps:

First, start the license server. This can be done only on the host for which the license wasgenerated. The license server can be started by any user, but it is preferable that the superuser starts it. This can be done with the following command:

% xanserver -f <license file name> -p <port number>

Here, <license file name> is the path of the license file that you received along with thedistribution. Port number can be any free port. Note that only one instance of the licenseserver can be invoked at a time on a given machine. The process runs in the background


14 Setting up AnXplorer

(there is no need to invoke it in the background) and if required, call be stopped using thekill command.

To run AnXplorer (on any host), set the environment variable AGO LICENSE FILE (in thesetup.csh file) as follows:

setenv AGO_LICENSE_FILE <port number>@<server IP address/host name>

For example, if the license server was started on machine with IP address 192.168.1.4 withport 8080, then add the following line to the setup file:

setenv AGO_LICENSE_FILE [email protected]

Depending on the license, a fixed number of instances of AnXplorer can co-exist at the sametime on different machines. If the specified number is exceeded, AnXplorer cannot be invoked.

The graphical user interface (GUI) of AnXplorer does not need a license. The license ischecked out only when the user performs circuit optimization. Thus, even if a license is notavailable, the GUI can be used to setup the optimization inputs and also view the outputs ofan earlier optimization run.

Querying the license status

The AnXplorer distribution also comes bundled with an executable called xlstat which canbe used to query the availability and other details of license.

If you are using a node locked license, xlstat can tell you the hostid of the node for whichthe license was generated, and the date till which it remains valid. For floating licenses, youcan query the number of licenses available and the date till which the license remains valid.

To query a license, just invoke the command xlstat at the command prompt.

% xlstat

Note: In the above case, the value of the environment variable AGO LICENSE FILE must beset appropriately before invoking xlstat. If it is not set, you can still query the license usingthe following options.

To query a node locked license, use:

% xlstat -f <license file name>.

To query a floating license, use:


Supported simulators 15

% xlstat -h <host name> -p <port number>

Here, the license server must be running on the specified host at the specified port.

Setting up the environment for use

Once the setup.csh has been edited properly to reflect the AGO ROOT and AGO LICENSE FILE

variable, the environment can be set up with a command like this:

% source <anxplorer installation directory>/setup.csh

Note: This file can be sourced only in the Csh or Tcsh shells. Bash or Ksh will not supportthis. If Bash or Ksh is used, the user needs to translate this file into an equivalent Bash orKsh script. Once this file has been sourced, AnXplorer is ready to be used. For convenience,you can put the above source command in your .cshrc file.

2.3 Supported simulators

AnXplorer currently supports the following versions of commercial simulators:

• Spectre version MMSIM6.0 and above.

• Hspice version G-2012.06.

• SmartSpice version 3.16.12.R

• Msim version 0906.

• Eldo version 2010.1

• Finesim version 2011.11.02 00

Other versions of these simulators might also work, but we have not tested with any otherversion.


CHAPTER 3

Using AnXplorer in standalone graphical mode

This chapter describes the usage of AnXplorer from its graphical user interface (GUI) in the“stand alone” mode, i.e. the GUI needs to be invoked from a command prompt. The GUIcan be used to setup the inputs to AnXplorer, running it for global optimization and localdesign centering, viewing the optimum design points found, and also to run queries on theexploration database. However, the netlists of the circuit being optimized (including the testbenches) cannot be prepared from within the GUI.

This mode of operation is suitable for usage with external simulators other than CadenceSpectre[4], or for usage with the Cadence Virtuoso environment version 5.x. For easier usagewith Spectre in the Cadence Virtuoso environment version 6.x please see chapter 5.

AnXplorer can also be used in the command line mode, which offers more flexibility andtunability. The command line usage is described in chapter 6.

3.1 A project

The starting point of using AnXplorer is a project. A project is a directory with a specialname, which contains all inputs and outputs of AnXplorer. The inputs to AnXplorer (asspecified in the GUI), must be saved as a project before running optimization. A project hasa name, which can be an arbitrary string. The project directory name is of the form <project

name>.xan. The extension .xan is used to identify project directories and thus should not bechanged. Project directories can be located anywhere.


Inputs to AnXplorer 17

Note: contents of a project directory, or the directory name, should not be manuallyaltered. This may lead to incorrect functioning of the tool. A more detailed description ofthe contents of the project directory can be found in section 3.11

3.2 Inputs to AnXplorer

Inputs to AnXplorer consist of the following sections:

1. Variable definition.

2. Optimizer options specification.

3. Technology specific parameter definition (optional).

4. Analysis and target definition section.

5. The targets priority assignment section (optional).

Each section has a separate “page” in the GUI, which are shown in the subsequent sections.

3.3 The main GUI window

AnXplorer can be invoked by typing the following command at the UNIX command prompt:

% anxplorer_gui &

Currently, the command has no command line options. This command brings up the mainGUI window of AnXplorer, which is shown in figure 3.1.

The window consists of a menu-bar at the top, followed by a tool bar containing buttonsto perform the most common tasks below it. The main work area consists of a set of “tabs”– each for a different function. Clicking on any of the tabs will bring up the correspondingpage of the GUI. There are seven tabs. The first five are used for setting up the inputs toAnXplorer. These tabs are: variable definition, options definition, technology specific param-eter definition, target and analysis definition, and target priority assignment. We recommendthat the inputs should be filled up in this order. The last two tabs are used for viewing theresults of AnXplorer. These are: the output log display tab, and the exploration databasequery tab.

The menu-bar consists of three menus: The “File” menu, the ”Optimization” menu andthe “Help” menu.


18 Using AnXplorer in standalone graphical mode

Figure 3.1: The main window of the GUI

Figure 3.2: Project selection dialog box

The “File” menu can be used to perform common tasks related to creating, opening, orsaving projects. The menu contains the following functions:


The main GUI window 19

• New project (keyboard shortcut: Ctrl+N): Creates a new project. If a project isalready opened when this function is invoked, the tool will prompt the user to save theexisting project before creating the new one.

• Open project (keyboard shortcut: Ctrl+O): Opens an existing project. Here too, if aproject is already opened, the user will be prompted to save the current project beforeopening the new one. The new project is selected by a special file selection dialog boxas shown in figure 3.2. The list on the left displays all directories except the projectdirectories. The list on the right displays all projects available in the present directory.The extension .xan is not shown. The user can browse different directories in the normalway, i.e. by double clicking on the directory names on the left. Double clicking on aproject name selects it.

• Save (keyboard shortcut: Ctrl+S): Saves the contents of a project. If the project namehas not been specified yet, it prompts the user for a name using the project selectiondialog box.

• Save as (keyboard shortcut: Ctrl+A): Saves the project with a different name. Allinformation in the existing project is copied into the new project. If the project namehas not been specified, this function is identical to the plain Save function.

• Revert to saved (keyboard shortcut: Ctrl+R): Provides an “undo” function. Theinputs are taken back to the last saved state. Any changes made after the last saveoperation are lost.

• Revert var ranges (keyboard shortcut: Ctrl+V): The ranges of the design variablesare updated after running the “feasibility analysis” for a project (feasibility analysis isdescribed in detail later in the text – please see section 3.9.2). This allows the user torevert back to the original (user-defined) ranges for the design variables.

• Quit (keyboard shortcut: Ctrl+Q): Quits the application. The user is always promptedfor a confirmation, as well as a prompt for saving the current project.

The “Optimization” menu can be used for perform the three types of optimization –feasibility, global and design centering, and viewing existing log files of AnXplorer. Please seethe section on “Running AnXplorer in this chapter for more details on running the tool indifferent modes. The menu consists of the following items:

• Run test simulation (keyboard shortcut: Ctrl+E): Runs a test simulation with arandomly created design point. The purpose is to validate whether all simulations andother options have been setup correctly (described in section 3.9.1).



• Run feasibility (keyboard shortcut: Ctrl+F): Runs AnXplorer in the feasibility anal-ysis mode (described in section 3.9.2).

• Run global (keyboard shortcut: Ctrl+G): Runs AnXplorer in the global optimizationmode (described in section 3.9.3).

• Run centering (keyboard shortcut: Ctrl+D): Runs AnXplorer in the local designcentering mode around a user specified initial design point (described in section 3.9.5).

• Run porting (keyboard shortcut: Ctrl+T): Runs AnXplorer in the design portingmode (porting a design from one manufacturing process to another) around a userspecified initial design point (described in section 3.9.7).

• Stop (keyboard shortcut: Ctrl+C): Stops any existing optimization job. All back-ground processes invoked by the tool are killed.

• Create initial point (keyboard shortcut: Ctrl+P): Invokes the GUI for manuallycreating an initial design point for use in the design centering mode.

• Import initial point (keyboard shortcut: Ctrl+W): Using this option, the user canimport a SPICE input file from which the initial values of the design variables will beread and stored within the project. The SPICE file must define all the variables using.param statements. All other statements in the file will be ignored. Choosing thismenu option invokes a file selector window, using which the user can choose the file tobe imported.

• Manual tuning (keyboard shortcut: Ctrl+I): Invokes the GUI for manual tuning ofthe design (see section 3.9.8).

• Load feasibility log (keyboard shortcut: Ctrl+K): Loads the output log of AnXplorerfeasibility analysis for the current project, if it is present. The “Log” page of the GUI isautomatically opened. See more details about output logs in the section on “RunningAnXplorer”.

• Load global log (keyboard shortcut: Ctrl+L): Loads the output log of AnXplorerglobal optimization for the current project, if it is present. The local optimas found arereported.

• Load centering log (keyboard shortcut: Ctrl+J): The log file of the design centeringprocess is loaded into the Log page of the GUI.

• Load porting log (keyboard shortcut: Ctrl+U): The log file of the design portingprocess is loaded into the Log page of the GUI.


Variable definition 21

The file and optimization menus are disabled when any optimization job is running.

The “Help” menu contains the following items:

• Open manual (keyboard shortcut: Ctrl+M): Opens up this manual. The environmentvariable PDF VIEWER should be set to the path of the Portable Document Format (PDF)file viewer of your system. If it is not set, the tool will prompt you for the path of thePDF viewer. Once set, it will be remembered for the remainder of the session.

• Turn on/off balloon (keyboard shorcut: Ctrl+H): Turns on or off the “balloon help”facility – a tiny window popping up with a help message when the mouse is moved overa widget – which is turned on by default. Most widgets in the GUI have a help messageassociated with it.

The tool bar consists of buttons for performing the most common tasks, namely – Run-ning a test simulation, running feasibility analysis, global optimization and design centering,stopping the optimization job, saving and loading a project, quit, and turn on/off the balloonhelp facility. Later, more buttons will be added here.

3.4 Variable definition

As discussed before, a variable is an entity whose value can be changed by the optimizer inorder to achieve the specified objectives. Variables represent physical quantities in the circuit,e.g. transistor dimensions, values of passive devices. While preparing the design, denote thesequantities by parameters, and use the same parameter names as variables for AnXplorer.Currently there is no facility for directly importing variable names from the schematic viewof a cell in the Cadence design environment. The user has to manually enter the variablenames. This facility will be added later.

A variable has a range, defined by its minimum and maximum values. During optimiza-tion, the variable will be assigned a value within this range. A variable value also has agranularity, which denotes the minimum step size by which the value can be varied.

For global optimization, it is recommened to use a larger step size, leading to a coarserbut faster search to quickly arrive at a few nominal feasible design points (a design point is aset of values for the optimization variables) which satisfy the design objectives. During localdesign centering, the granularity is automatically reduced by a factor of 10, so as to enable afiner search.

The GUI for defining variables is displayed when the user clicks on the “Variable” tab ofthe main window. The window is shown in figure 3.3. On the right are entries for entering



Figure 3.3: Variable definition GUI

the name, minimum value, maximum value and granularity of the variable. Note: these aremandatory entries.

The name of the variable should be an identifier, i.e. it should begin with a letter (a-zA-Z)or the underscore (‘ ’) character and optionally followed by a sequence of letters, underscoreor digits. No other characters are allowed in the variable name. The minimum, maximumvalues and granularity should be numeric values – either integers, e.g. 123, or floating pointnumbers, e.g. 1.23, real numbers using the scientific notation, e.g. 1.2e-03, or numbers scaledwith a alphabetic suffix, e.g. 1.2m, as is commonly used in Spice input decks. The tool willcheck the format of the name and the numbers, and report an error if necessary. The meaningof each allowed alphabetic suffix is given in table 3.4.

The user can also choose a variable to be of type integer, i.e. it can be assigned onlyintegral values. For example, if the number of fingers of a MOS transistor is denoted by avariable, then it must be an integer. To make a variable an integer, select the checkbuttonbelow the entries in the GUI.

Once all entries are filled up, click on the button labeled “OK” in the box of buttonsabove the entries. This creates the variable.

Names of variables already defined are displayed in the list on the left. Clicking on anentry in the list displays the variable values in the entries. The user can move up or downthe list by clicking on the buttons labeled “Next” and “Prev” in the box of buttons.

To delete a variable already defined, click on its name in the list, and then click on the“Delete” button. The tool will prompt the user for a confirmation. To edit a variable, displayit by clicking on its name in the list, modify the values and then click on the “OK” button. Ifthe name of the variable was modified, then a new variable with the modified name is created.


Options definition 23

Scaling alphabet(s) Scaling factort,T 1012

g,G 109

M,x,X 106

k,K 103

m 10−3

u,U 10−6

n,N 10−9

p,P 10−12

f,F 10−15

a,A 10−18

Table 3.1: Table showing the mapping of the scaling alphabets to the corresponding scalingfactors.

The user must delete the original variable if necessary.

The values of each variable are displayed in a tabular format in the lower part of the GUI.This table updates itself as variables are created, edited or deleted.

The design space defined by a set of n variables is a bounded region in an n-dimensionalspace. The “size” of this region grows exponentially with the number of variables as wellas the range of the variables. The user is thus advised to choose the range of the variablesjudiciously. For a variable denoting a geometrical quantity, an obvious choice for the minimumand maximum values are the minimum and maximum dimensions supported by the fabricationtechnology. However, in most cases, the choice can be a much narrower range. For example,if a MOS transistor is expected to provide a significant gain, then the width of the transistorshould be large. Thus, the minimum value for the variable denoting the width of this transistorshould also be reasonably large. Such judicious choice of variable ranges by a knowledgeabledesigner can significantly reduce the amount of time required to find an optimal design point.

3.5 Options definition

This page is displayed when the user clicks on the “Options” tab. This page is used fordefinining several options to the optimizer. It is shown in figure 3.4. Each of the options arediscussed next.

3.5.1 Selecting the simulator

The user can choose from eight options: (1) Msim, (2) Hspice, (3) Spectre, (4) Eldo, (5)SmartSpice, (6) Finesim with Spice format inputs, (7) Finesim with Spectre format inputs



Figure 3.4: The options definition GUI

and (8) dspice. There are two options for using Eldo: with or without the -compat commandline argument. Further, for Finesim as well, there are two options – running with Spice formatinputs and running with Spectre format inputs. See the chapter on “Preparing the design”(Chapter 4) for details on using each of these simulator. If any external simulator is beingused (options 1 to 5 above), select the check-button labeled “External simulator to be used”and select the simulator from the drop down menu next to it. If the internal simulator dspiceis being used, do not select the check-button.

3.5.2 Specifying command line options for the simulator

This option is applicable only if an external simulator (i.e. anything other than dpsice) isbeing used. The user can specify command line parameters to the simulator being used.Please select the check-button labeled “Extra simulator options”, and enter the options inthe entry field next to it.

Please note:

1. Please do not use any options to specify the input netlist file (e.g. -i or -input) orthe output file (e.g. -o or =log). AnXplorer will always supply these options wheninvoking the simulator. Thus, it will create a conflict with the user specified options.

2. User specified options will replace all default options supplied by AnXplorer except theinput and output file specification options.



3. In most cases, the options used by AnXplorer by default serve the purpose. Thus,specify these options only in special cases where you are not able to get the desiredoutput with the default options.

The default options used by AnXplorer for each simulator are as follows:

• Eldo: -queue -silent -spiout -nojwdb -noinit -noerrmlog. Optionally, the -compatoption is added if the user selects “eldo with -compat” as the simulator. The immutable(i.e. which cannot be changed by the user options) are -i, -o and -l. Please see theEldo user manual for explanation of these options.

• Spectre: +lqtimeout 0 -format sst2 -I. The immutable options are -raw, -psf

and =raw.

• Msim: -hsp. Immutable option is -o.

• Smartspice: -sb -hspice. Immutable option is -o.

• Hspice: None by default

• Finesim (Spice format inputs): None by default

• Finesim (Spectre format inputs): None by default

3.5.3 Enabling multi-threading

If you are using a multi-CPU or multi-core CPU machine, then enabling multi-threading in theoptimizer can vastly improve its performance. Even on a single CPU machine, multi-threadingimproves performance because it leads to better utilization of CPU time. To enable multi-threading, select the check-button labeled “No. of threads” and enter the desired number ofthreads (must be an integer) in the entry next to it.

Note: In the multi-threaded mode, multiple simulation jobs will be fired simultaneously,each job possibly consuming one third party simulator license. Thus, specify the number ofthreads keeping the simulator license availability in mind.

3.5.4 Specifying the optimization stop criteria

AnXplorer allows flexible optimization termination criteria to be defined. By default, AnX-plorer runs till either all objectives have been completely satisfied, or a given maximumnumber of optimization iterations are over. The user can choose to specify other criteria.The section of the GUI labeled “Optimization stop criteria” is used for specifying these.



• The drop down list at the top of this section is used to specify the fraction of objectivesthat have to be satisfied before optimization stops. The allowed values are 100%, 95%,90%, 85% and 80%. Default is 100%, i.e. all objectives.

• The next drop down list is used to specify the criterion which determines whether anobjective has been satisfied. The default is that the objective should be fully met. Thismeans that for an objective which is to be maximized, the optimized value should begreater than the target. Similarly, for an objective to be minimized, the optimizedvalue should be less than the target, for it to be considered as “satisfied”. This defaultcriterion can be changed. The user can specify that when an optimized value is withina certain range of its objective, it can be taken to be met. This range is specified interms of a percentage of the target value. The user can select this percentage from thedrop down list. The allowed values are 2%, 5%, 10%, 15% and 20% respectively.

Note that these criteria are used in the global optimization, design centering and portingoptimization (see section 3.9). They are not used in the feasibility analysis mode, as thepurpose of feasibility analysis is to explore the design space, and not converge to a optimizedsolution.

The number of iterations for which the optimizer will search for solutions in the globaloptimization and feasibility analysis modes can be specified. Select the check-button labeled“Max no. of iterations” and enter the number of iterations in the entry beside it. This is usedonly in the feasibility analysis and global optimization modes.

Finally, if the user wants to continue the optimization process even when the stoppingcriteria are met, please select the check button labeled “Continue optimization ...”. If this isselected, the stopping criteria would be as follows:

• In global optimization and feasibility analysis modes, the optimizer will run for thespecified number of iterations. If the number of iterations is not specified, it defaults to60.

• In design centering and porting optimization modes, if the difference in performancebetween any two successive iterations is less than 0.2%, or the position of the optimizeddesign after two successive iterations do not differ by more than 0.2%.

3.5.5 Specifying the centering options

In the design centering mode (refer section 3.9.5), AnXplorer optimizes the circuit so that itmeets all objectives across all the PVT corners defined. In this phase, each design point isevaluated for all corners. However, that may unnecessarily increase the optimization time,since some of the corners may already be meeting all objectives. By default, AnXplorer



runs an exhaustive check at the beginning of the design centering phase and finds out whichcorners violate the optimization objectives. It then runs centering with only those corners.This reduces optimization time. However, the user also has the option of running centeringwith all corners.

To run with only the violating corners, select the option “only corners which violateoptimization criteria” from the dropdown menu. This is selected by default. To run with allcorners, select the option “all corners”.

At the end of centering, AnXplorer can also run a senstivity analysis which reports byhow much each objective varies across all corners for a slight perturbation in the value of eachvariable. This can be turned on by selecting the corresponding check button. It is turned offby default.

Setting the granularity reduction factor

During the design centering phase, the granularity, or step size of each variable is reducedby a factor of 10 by default. This is to enable a fine grained search around the initial designpoint. This factor can be controlled. The user can enter the reduction factor in the entryfield labeled “Reduce variable step size by this factor for design centering:”. A value of 1will mean that the variable step sizes are not reduced – they will be used as is in the designcentering phase. The default value appearing in this box is 10.

3.5.6 Selecting the global optimization algorithm

AnXplorer offers a choice of two algorithms for global optimization:

1. A fast algorithm, which is expected to converge quicker, i.e. with lesser number ofiterations. However, this algorithm can get stuck in local optima and fail to reach theoptimum solution in some rare corner cases.

2. A slow and robust algorithm. This may take a few iterations longer to reach the optimalsolution, but it has better safeguards against getting stuck in local optima.

The first algorithm is used by default. To use the second algorithm, please deselect the checkbutton labeled “Use fast algorithm for global optimization”.

The recommended flow is to use the fast algorithm first, and then use the slower algorithmonly if the first attempt fails to yield satisfactory results.



3.5.7 Logarithmic partitioning

This option needs some elaboration. Suppose there are n design variables which the optimizercan vary. This defines a bounded (by the minimum and maximum values of each variable)and discretized (by the step size of each variable) n-dimensional hyperspace. The optimizer,by default, subdivides the range of each variable into k equal partitions (k is determinedinternally). This gives rise to kn sub-regions of the design space. The optimizer tries tosample as many of these sub-regions as possible. If the size of the design space is very large,the optimizer may find it difficult to locate the optima using the above uniform partitioningstrategy. In such cases, it helps to divide the range of each variable in a logarithmic (octave)scale. This option can be set by selecting the check-button labeled “Logarithmic steps forvariables”.

For larger design spaces, logarithmic partitioning can vastly improve the speed of conver-gence. However, for reasonably sized design spaces logarithmic partitioning may not yieldany siginificant improvement. The user is advised to first try the optimization without thisflag. If the optimizer fails to achieve satisfactory results, then this option can be included.The future plan is to automatically detect the size of the design space and make this decision,without involving the user.

3.5.8 Specifying the PVT corners

A corner is defined as a combination of a model library, a temperature value, and a set ofdesign variable values. All three are optional. Corners are used during the design centeringprocess, where AnXplorer aims to ensure that all design objectives are met across all the userdefined corners.

This concept of a user defined corner is an addition in the 2011.11 release of AnXplorer.In earlier versions, the user had to specify a set of model libraries, a set of temperaturevalues, and a set of voltage variable values. AnXplorer used all permutations of these valuesas separate corners. However, this led to the creation of some corners which were not usefulor realistic (for example, a “fast” model library with a high temperature). From the 2011.11release onwards, this has been changed to explicit user defined corners. This change is fullybackward compatible. Projects created using older versions will be automatically convertedinto this new scheme - with a set of corners appearing in the GUI. The user can choose toomit the invalid corners.

To add a corner, click on the button labeled “Add”. The GUI, as shown in figure 3.5 popsup. The corner is identified by a unique name, to be entered in the first entry field at the top.This is followed by the entries for the model file, model corner and temperature. All theseare optional, and the entries are to be enabled by clicking on the check button next to each



entry. A file browser (invoked by clicking on the button labeled “...”) can be used to selectthe model file. Note that multiple model corners can be specified in the entry field for themodel corner, separated by spaces. This will create multiple model file inclusion statementsin the netlist, one for each model corner.

Figure 3.5: GUI to define a PVT corner

A corner can also have a set of variable values (e.g., the value of the variable representingthe supply voltage). The variable name and value are to be entered in the correspondingentries, and then click on the button labeled “Add”. The variable will appear in the list boxbelow. A variable can be deleted by clicking on the button labeled “Delete”.

Note: Any number of variables can be defined in a corner. However, the restriction isthat all user defined corners must have the same variables.

To finalize the corner definition, click on the button labeled “Add corner” at the bottom ofthe GUI. This window can be closed by clicking on the button labeled “Done”. To navigatebetween the user defined corners, use the buttons “¡¡” and ”¿¿”. The corner names alsoappear in the list in the main GUI window. A corner can be deleted from this GUI as well,by clicking on the button labeled “Delete”.

AnXplorer, while optimizing the design, will modify the testbench netlists as follows:

• It will remove any pre-existing model file inclusion statement and replace it with theuser defined model file for a corner.

• Similarly it will replace the temperature value with the one specified in the corner

• It will also replace the values of the corner variables in the netlist.

Thus, if the user wants to perform only global optimization, or use only one corner, then itneed not be explicitly defined. AnXplorer will simply pick up whatever is specified in the



input netlists. If, on the other hand, the design is to be optimized across multiple corners,then they must be specified here.

The user can choose to evaluate each test bench across all corners, or a subset of corners,or none at all. This is described in detail in section 3.7.

3.6 Technology specific parameter definition

3.6.1 Sizing rules

The technology parameter definition page is used for defining the parameters for sizing ruleevaluation. Thus, we discuss the concept of sizing rules first, before describing the operationof the GUI.

Sizing rules are a set of rules aimed at making the DC operating condition of a circuitinherently stable and insensitive to variation in process and environment. Currently, theserules are supported only for MOS transistor based designs. It will be extended for otherdevices, e.g. BJTs, later. AnXplorer reads the circuit netlist and automatically recognizestransistors which are meant to be in saturation and tries to ensure that these transistors aredeep in saturation. It also recognizes transistors which are meant to be in the linear region,and tries to place them well within the linear range. It also recognizes basic sub-blocksof analog circuits, like current mirrors (several types of current mirrors), banks of currentmirrors, differential pairs, level shifters, etc., and tries to ensure certain conditions that thesesub-blocks should ideally satisfy. These rules are generally applicable to most analog circuits.If, however, the user feels that such rule checking should not be done on a circuit, or ifshe specifies the constraints on the devices herself (this can be done in the operating pointanalysis, discussed in the next section), then the sizing rule evaluation can be turned off.

Following is a list of building blocks identified by AnXplorer

1. Single transistor acting as either voltage controlled current source (saturationregion), or voltage controlled resistor (triode region). This acts as the basis for allother building blocks. Rules applied to voltage controlled current source:

• VDS should be greater than (VGS − VTH) of the transistor by a specified mar-gin (Here, VDS stands for drain-to-source voltage, VGS stands for gate-to-sourcevoltage, and VTH stands for threshold voltage of a MOS transistor).

• VGS − VTH should be greater than a specified threshold.

Rules applied to voltage controlled resistors are:

• VDS should be less than (VGS − VTH) of the transistor by a specified margin


Technology specific parameter definition 31

• VGS − VTH should be greater than a specified threshold.

For both type of transistors (triode or saturated), an additional rule is applied – the area(product of width and length of the transistor) should be greater than a user-definedthreshold.

2. Simple current mirror, with both transistors in saturation. Represented as MOS-

CM 1 in the AnXplorer output. Rules applied to a current mirror are:

• The rules for the MOS transistors in saturation, comprising the current mirror.

• The maximum difference in VDS of the two transistors comprising the currentmirror should be less than a user-specified threshold.

3. Simple differential pair, both transistors in saturation. Represented as MOS-DP inoutput. The rules applied are the same as those on the constituent transistors, whichare supposed to be in saturation.

4. Level shifter, with both transistors in saturation. Represented as MOS-LS in output.Rules applied are:

• Rules for the constituent transistors in saturation.

• The current (IDS) through the transistors should be proportional to their widths.

5. Current mirror bank – extension of current mirror. Represented as MOS-CMB inoutput. Rules applied are those for the constiuent current mirrors.

6. Level shifter bank – extension of level shifter. Represented as MOS-LSB in output.Rules applied are those for the constituent level shifters.

7. Voltage reference. The bottom transistor (the one connected to the ground rail) isin triode, while the top one is in saturation (for NMOS structures. PMOS structurewould be exactly opposite). Represented as MOS-VR in output. The rules for satu-rated transistors and triode transistors are applied to the top and bottom transistors,respectively.

8. Current mirror load. Represented as MOS-CML in output. Consists of a triodetransistor at the bottom (connected to the ground rail), and a saturated transistorabove it (again, this is for NMOS structures – the PMOS structure would be opposite).Rules applied to both transistors.

9. Cascode current mirror – a combination of one load shifter and one simple currentmirror. Represented as MOS-CCM in output. Rules for level shifter and current mirrorare applied.



The output of AnXplorer also indicates which transistors comprise each structure. The abovedescriptions are for NMOS structures. PMOS structures are just opposite. They are alsorecognized and the same rules are applied. These structures are shown pictorially in figure 3.6.Note that only NMOS transistor blocks are shown.

(This list is not complete and is useful as an example only)

Voltage controlled current sourceor voltage controlled resistor

Simple current mirror

Differential pair

Voltage reference

Level shifter

Current mirror load

Current mirror bank Cascode current mirror

Level shifter bank

Figure 3.6: Building blocks recognized by AnXplorer

In order to evaluate the in-built sizing rules, the user needs to specify the following pa-rameters, which are specific to a technology:

1. The names of the NMOS and PMOS transistor models. These are used to identify theN and P transistors from the netlist. Several model names for the same transistor type(N or P) can be specified.


Technology specific parameter definition 33

2. For transistors in saturation, the minimum difference (which makes the transistor safelyin saturation) between the drain-to-source voltage (VDS) and the overdrive. The over-drive is the difference between gate-to-source voltage (VGS) and threshold voltage (VTH)of the transistor. Thus, the tool tries to ensure that VDS > VGS −VTH + v1 for all tran-sistors in saturation, where v1 is the user defined safety limit.

3. For transistors in linear region, the user must specify a similar safety limit as above, buthere, the tool tries to ensure that VDS < VGS − VTH − v2. Here, v2 is the user definedsafety limit for transistors in the triode region.

4. The minimum overdrive for a conducting transistor (VGS−VTH) is specified by the user.Similarly, the maximum allowable overdrive also needs to be specified.

5. The minimum area for a transistor, for which the noise is within acceptable limits, hasto be specified.

6. For two transistors in a current mirror, the maximum allowable difference between theVDS of the two transistors has to be specified. This is to ensure that VDS differencedoes not cause any current mismatch for the mirror.

3.6.2 Using the technology parameter GUI

Figure 3.7: The technology parameter definition file

The GUI for entering the technology parameters is shown in figure 3.7. To enable the sizingrule evaluation, select the check button labeled “Enable automatic sizing rule evaluation” atthe top of the GUI (this is by default deselected). Note that if this button is deselected,the rest of this GUI need not be filled up. Technology parameters can be imported from



an existing project by clicking on the button labeled “Import technology parameters from adifferent project”. A selection dialog for selecting the other project pops up. Select a projectin this box. The technology parameters of this project, if any are defined, will appear inthe GUI. Otherwise, a message will be shown, stating that no parameters are defined for theother project.

The model names for the NMOS and PMOS transistors have to be entered in the two entryfields. The name of models should be exactly as they appear in the CDL netlist of the design.The parameters discussed above need to be entered for both NMOS and PMOS transistorsin the entries below. The labels on the entries explain the purpose.

Note that (currently) model names are case sensitive. So, even though in the SPICE netlistmodel names NCH and nch are treated the same, here they should be specified separately.There can be several N and P models.

3.7 Analysis and target definition

This section defines the objectives of the circuit and the analyses to be performed in order toextract these objective values. There are three types of analyses:

1. Special simulation based analyses with built-in intelligence about performance objec-tives.

2. General simulation based analyses with user defined objectives.

3. User defined function/equation based analysis.

Each analysis has one or more objective values and the goal of AnXplorer is to size thegiven circuit such that these objective values are met (or exceeded). There is a penalty for notmeeting an objective. On the other hand, there is a reward for over-achieving an objective.However, this reward is much smaller than the penalty for not meeting an objective. Forexample, the penalty for achieving 20% less gain is substantially bigger than the reward forachieving 20% more gain.

In the course of optimization, AnXplorer evaluates several candidate circuits. Each ob-jective is assigned a raw score depending on the target value. The total score of a candidatecircuit is a combination of the raw scores. A lower total score indicates a better solu-tion. Suppose an objective is to be minimized below a target value t. The evaluated valuefor this objective in a candidate circuit is, say, v. Then the raw score of this objective iscalculated as follows: If v > t, then the score (s) is given by s = 2 − exp(1 − v/t). If v < t,then s = exp(rp · (v/t− 1)), where rp is typically 0.01. Thus, the raw score has a maximum


Analysis and target definition 35

value of 2 (nowhere near the target), and a minimum value of 0 (vastly over-achieved). Avalue 1 or less indicates that the objective has been achieved.

In this evaluation scheme, the ideal total score of a design point should be equal to thenumber of objectives, since the ideal score for each objective is 1.

Using a factor rp for calculating the score when an objective has achieved the targetensures that the reward for over achieving a target is significantly less than the penalty forunder achieving the target by the same amount. Since the final score is a sum of individualobjective scores, this parameter also ensures that several over achieved objectives do notovershadow a small number of under achieved objectives.

Figure 3.8: Main page for defining targets

The main page for defining analyses and objectives is shown in figure 3.8. Currently, threetypes of analyses are supported in the GUI:

• Operating point analysis for measuring current consumption, node voltages, sizingrules and user-defined constraints on the DC condition of individual MOS transistors.

• Noise analysis for measuring the total input referred noise voltage of a circuit, aswell as the contribution of individual devices to the total noise (both thermal noise andflicker noise).

• Function based analysis for measuring objectives defined by simulator post-processingcommands.

• Equation based analysis for optimization based on user defined equations.

The GUI for each of the above types of analysis can be invoked by selecting the appropriateradio button in the main GUI.

Each analysis has a name which must be an identifier. This has to be entered in theentry field at the top of the GUI. An analysis also must have a test bench associated with



it. This is specified by selecting the top radio button and entering the file name in the entrylabeled “Spice deck”. The button next to it can be used to pop up a file selection dialog box.Details of the test bench netlist can be found Chapter 4. If Spectre (or Finesim with Spectreformat inputs) is being used as the external simulator, then an OCEAN script, with the samename prefix, should also be present in the same directory as the Spectre netlist. Further,in case of Spectre (or Finesim with Spectre format inputs), the user should also specify thelocation of the mapping directory, or "amap" directory in the text entry box labeled “amapdirectory”. This is usually present in the simulation netlist directory created by ADE L.Inside the simulation directory (as specified in ADE L, usually defaulting to ./simulation),the path should besimulation/<cell name>/spectre/schematic/netlist/amap. To select a mapping direc-tory, clicked on the button labeled “...”, and a file selection dialog box pops up. This isdifferent from a “normal” file selection dialog in that it displays only directory names bothin the left side and the right side scrolled lists. To traverse directories, use the list on the leftside. To actually select the directory, select it on the right side list, and click on “OK”.

Useful tip: To create a Spice deck in the Cadence Virtuoso environment, open ADEand load the state defining the test bench. From the “Simulation” menu, choose “Netlist”→ “Create”. This will pop up a text editor with the netlist file. From the text edi-tor “File” menu, choose “Save as” to save the netlist in your work area. The extensionof the file name should be .scs. To create the OCEAN script, choose the option “Savescript” from the “Session” menu in Analog Artist, and then save the script with the samename prefix as the Spectre netlist, and the extension .ocn. For example, if your Spectrenetlist is saved as /home/test/testbench1.scs, then the OCEAN script should be saved as/home/test/testbench1.ocn.

Alternatively, if a single test bench performs multiple simulations, then the data for oneanalysis can be read from the output of another analysis, i.e. the former is linked to the latter.In such a case, select the radio button at the bottom, and enter the name of the main analysis(which has the test bench) in the entry field labeled “Linked to”.

Finally, if it is a user defined equation based analysis (section 3.7.8), then neither of theabove two need to be selected.

Once an analysis is defined, click on the “OK” button. The list on the left of the GUIdisplays the names of the analyses defined so far. Selecting a name in the list brings up theGUI for that analysis. One can move the selection up or down the list by clicking on the“Next” and “Prev” buttons. To delete an analysis, select it in the list and then click on the“Delete” button. The user will be prompted for a confirmation before deleting.



3.7.1 Including a target in the feasibility analysis mode

The feasibility analysis mode of AnXplorer is described in detail in section 3.9.2. In short,feasibility analysis explores the design space defined by the design variables and finds regionswhich yield a feasible design. By the term feasible design we mean a candidate design whichmeets a subset of objectives. By default, all implicit sizing rules (if enabled), all explicit con-straints on MOS transistor operating conditions (section 3.7.3), and all user defined equationbased targets (section 3.7.8) are included in the feasibility analysis mode. A design point istermed feasible if all these objectives are satisfied.

In addition to these default objectives, the user can choose to include any arbitrary anal-yses in the feasibility analysis mode. This can be done by selecting the checkbutton labeled“Include this analysis in feasibility mode”, next to the entry area for the analysis name.

Including some of the lightweight analyses (i.e. analyses which require a very small timeto simulate, e.g. AC analyses) in the feasibility mode has a definite advantage. It cuts downthe design space, so that the global optimization mode converges faster. However, it is notadvisable to include analyses which have long simulation times in the feasibility analysismode. The time advantage gained in the global optimization, by cutting down the designspace size, will be lost if a lot of time is spent in the feasibility analysis mode running thelong simulations.

3.7.2 Selecting corners for an analysis

In the design centering mode, each analysis can be evaluated either at all user defined corners(see section 3.5.8), or a subset of corners, or none at all. Further, for optimization modes whereonly a single corner is used (feasibility analysis, global optimization and porting optimization),the user can potentially evaluate each analysis at a different user defined corner.

The drop down widget just below the “Linked to” entry has three values to choose from –“No corners”, “Use all corners” and “Use selected corner” (the default being “No corners”).

• No corners: In this case, AnXplorer will not do any model library or temperaturesubstitution in the netlist file for this analysis. Thus, it is expected that the netlist forthe analysis, in this case, should be “self contained”. In case of design centering, thisanalysis will be evaluated only once for every design point, and the normal performanceat that design will be taken as its worst case performance.

• All corners: In this case, as the name of the option suggests, all user defined cornerswill be used for this analysis. If there N corners, in the design centering mode, thisanalysis will be evaluated N times, each time in a different corner, and the worst caseperformance of each objective across these N runs will be taken as the performance of



the circuit. In case of feasibility analysis and global optimization, the analysis will beevaluated with the first design corner defined by the user in the list of corners specifiedin the options definition page. The order of the corners can be changed by using thebuttons labeled “Move up” and “Move down” in the options definition page.

• Selected corners: Here, as the name suggests, instead of all corners, only the selectedcorners will be used to find the worst case performance of this analysis. In the feasibilityanalysis and global optimization modes, the first corner in the list of selected cornerswill be used.

To add a corner to the list of corners to this analysis, click on the button labeled “Add”.A window, containing a list of user defined corners, will pop up. Select corners from this listand click on “OK”. Corners can be deleted from the list by clicking on the “Delete” button.

3.7.3 Operating point analysis

Operating point analysis can be used to measure the following:

1. Expected voltages at various nodes in the circuit. AnXplorer tries to minimize therelative error between the expected voltage and the actual (simulated) voltage below agiven relative tolerance.

2. Expected current consumption from a voltage source. Here, the objective is to reducethe current consumption below the specified value.

3. Implicit sizing rules are evaluated. These rules impose constraints on the biasing con-dition of transistors. AnXplorer recognizes commonly used structures in the circuit,e.g. differential pairs, several types of current mirrors, etc. It tries to bias the circuitsuch that all these rules are met.

4. Biasing constraints on individual MOS transistors. The user can choose to increase ordecrease the difference between the VDS and Vdsat of a transistor. She can also chooseto increase or decrease the overdrive (i.e. the difference between VGS and VTH) of atransistor.

All the above measurements are optional. The user can choose any number of measurementsto perform.

The GUI for defining an operating point analysis is shown in figure 3.9. It can be invokedby clicking on the radio button labeled “Operating point” in the main analysis GUI.



Figure 3.9: GUI for defining an operating point analysis

Selecting the CDL file of the design

A CDL netlist of the test bench (which can be created from the Cadence design environment)is required if either the sizing rule evaluation or the constraints on individual devices are to beevaluated. The CDL netlist is parsed by the tool to gather information about the connectivityof the devices and also the hierarchical device names, which is required for evaluating the sizingrules. Since the tool is not directly integrated with the Cadence environment yet, it cannotread this information from the design database. A CDL netlist is easy to parse and henceused here. This requirement will be removed in future.

To specify the CDL netlist file, select the check-button labeled “CDL file” and enter thefile name in the entry next to it. The button on the right of the entry can be used to pop upa file selection dialog.

Defining current consumption limit

AnXplorer can limit the current consumption from one voltage source in the design belowa specified value. To enable this option, enter the name of the voltage source in the entrylabeled “Power supply name” and the limiting value (in amperes) in the entry below it (labeled“Current consumption”).



The name of the voltage source must be hierarchical. Normally, a hierarchical name isexpressed in the form I0.I1.vsource where vsource is the actual device name, and I0 andI1 are the names of the containing subcircuit instances. Alternatively, the name can also beexpressed as a hierarchical CDL/Hspice netlist name, in the form XI0/XI1/vsource. Here,the letter X at the beginning indicates a subcircuit instance. This name will be converted toa different format by the tool, which will be displayed in the name entry once the analysisis saved (by clicking the “OK” button). The formatted name will look different from theoriginal name, so the user should not get alarmed by this!

Defining node voltage targets

To define a node voltage target, enter the name of the node in the entry labeled “Node name:”and the target value (in volts) in the entry below it, and then click on the button labled “Add”next to it. The constraint appears in the list below. To delete a node voltage target, select itin the list and click on the “Delete” button. Clicking on the “New” button clears the entries.

The “Relative tolerance” (the entry below the voltage value entry) denotes the allowablerelative error between the target voltage and the actual calculated voltage. AnXplorer willtry to bring the actual voltage to within X% of the target value, where X is the specifiedrelative tolerance.

As in the case of the voltage source name, the node names must also be hierarchical.Here, too, the names will be changed to the internal format which will be different from theoriginal.

Defining constraints on individual MOS transistors

In order for a design to be stable and functional across process/voltage/temperature corners,it is required that all active devices be biased properly. AnXplorer allows the designer to settwo different constraints on the biasing of individual MOS transistors in the circuit. Theseare:

• Constraint on the overdrive of a transistor, i.e. the difference between the gate-to-sourcevoltage (VGS) and the threshold voltage (VTH). For this transistor, this difference canbe constrained to be either greater than, or less than, a specified target.

• Constraint on the difference between the actual drain-to-source voltage (VDS) and theminimum drain-to-source voltage required for a transistor to be in saturation (Vdsat -reported in the operating point analysis output of all transistors). For a transistor insaturation, this difference must be positive, whereas it should be negative for transistors



in the linear region. This difference can be constrained to be either greater than, or lessthan, a specified target.

To constrain the VGS−VTH of a transistor, enter the name of the transistor (hierarchical)in the entry field labeled “Transistor name”. In the drop down menu below it, choose theoption “Vgs - Vth”. Choose the type of constraint (greater than, or less than) in the menubelow it. Finally, enter the target value (in volts) in the entry labeled “Voltage (V)” and clickon the “Add” button next to it. The constraint will appear in the list below. Several suchconstraints can be added. To delete a constraint, select it in the list and click on the “Delete”button. Clicking on the “New” button clears the entries.

Similarly, to constrain the VDS − Vdsat for a transistor, choose the option “Vds - Vdsat”in the drop down menu.

The user can either enter the transistor names (hierarchical names) manually into thename box, or select transistors by using the transistor browser GUI. The browser GUI canbe invoked by clicking on the “Browse” button on the right side. This pops up a windowwhich is shown in figure 3.10. The list box on the left side of the window shows all subcircuitinstances defined in the design, showing their hierarchical names, and grouping them togetherby hierarchy. In addition, there is a special entry called ##all##. Clicking on any entry onthe left side shows all MOS transistors defined in that subcircuit in the listbox to the right(note that if a subcircuit instance does not contain any MOS transistors, it will not show upin the left list). Clicking on the ##all## entry will show all MOS transistors in the design.Multiple transistors in the listbox can be selected at the same time, by using either the “Shift”button (selecting transistors in a continuous list) or the “Ctrl” button (selecting individualtransistors). Once selected, the constraints on the transistors can be set by using the voltageoption, direction, and voltage value widgets, just below the listboxes. Clicking on the “Add”button adds these constraints to the main GUI listbox.

Either the CDL file, or the SPICE file for the test bench must be specified for the transistorbrowser to work. In addition, if using Spectre as the simulator, the CDL file must be specified.

If the transistor names are entered manually, the names must be hierarchical. Also notethat the transistor names should be as they appear in the CDL netlist. For example, evenif the name of a transistor is, say, M1 in the schematic view, but it appears as MM1 in theCDL file, it should be entered as MM1 in the name entry.

Note: For P transistors, VTH , Vdsat, VGS and VDS are negative. For a saturated transis-tor, both VGS − VTH and VDS − Vdsat will be negative. On the other hand, for N transistors,these quantities will be positive. However, the user need not worry about the signs of thesequantities while specifying these constraints. Thus, for any transitor supposed to be in satu-ration, whether N or P, the targets for both these quantities should be greater than a positive



Figure 3.10: GUI for browsing MOS transistors in the design

number (irrespective of transistor type).

Sizing rule evaluation

Sizing rules are evaluated implicitly. Evaluation of sizing rule and MOS transistor constraintscan be disabled by selecting an option in the technology specific parameters page (discussedearlier). Alternatively, the user can disable only the implicit sizing rule evaluation by explicitlyignoring the sizing rule target in the target priority assignment (cost graph) page (discussedlater).

3.7.4 Noise analysis

The noise analysis option is currently available only if Hspice is being used as the externalsimulator. It will be made available for all supported simulators in the near future. However,most simulators support noise analysis using post-processing statements. Thus, noise analysiscan be performed with any of the simulators using the user defined function based analysis.

In a noise analysis, AnXplorer tries to minimize the total input referred noise voltage ofa circuit at a user specified frequency. In addition, it also calculates the thermal noise, flickernoise, and total noise for individual devices at that frequency. For user specified devices, ittries to reduce the percentage contribution of any of these types of noise to the total noise ofthe circuit below a specified value.

The user needs to enter the frequency of measurement (in Hz) in the entry field at thetop of the GUI. The total input referred noise voltage target has to be entered in the entrybelow it.



To specify constraints on the noise contribution of individual devices, enter the devicename (hierarchical) in the entry labeled “Device name”, choose the type of noise (thermal,flicker or total noise) from the drop down menu below it, and enter the percentage contributiontarget in the entry field below it. Then, click on the “Add” button next to it. The constraintwill appear in the list below. Several such constraints can be added. To delete a constraint,select it in the list and click on the “Delete” button.

Figure 3.11: GUI for defining noise analysis

The GUI for noise analysis is shown in figure 3.11.

3.7.5 Post-processing function based analysis

AnXplorer allows the user to define arbitrary targets using post-processing commands ofthe simulator being used. These can be .measure statements in Hspice (or SmartSpice orMsim or Eldo), or general calculator functions using the Cadence waveform calculator. Forany simulation, an arbitrary number of such measures can be used as targets. The onlyconstraint is that the output of such a measure must be a numerical value, i.e. it cannot be awaveform. Each measurement must have a name, which can be any arbitrary string withoutany whitespaces. Details on defining the measurement commands can be found in Chapter 4.

For each target, the user needs to define a threshold value, and a direction of optimization,i.e. minimize or maximize.

The GUI for defining function based analysis is shown in figure 3.12. The user mustspecify the type of the underlying simulation, i.e. either transient, AC sweep, DC sweep orMonte Carlo (the last one is described in the next section) by selecting the appropriate radio



Figure 3.12: GUI for defining function based analysis

button in the section of the GUI labeled “Analysis Type”. The name of the target needsto be entered in the entry field labeled “Target name”. Select the direction of optimization(greater than or less than), in the drop down menu below. Enter the target value in the entrybelow it. Note that the expressions for these targets must be defined either in the netlist as.measure statements (in case of Hspice or similar simulators), or in ADE L as the output ofa calculator function. There is no way to define the expression in the AnXplorer GUI. Alsonote that the target must be specified in the same unit as the calculated value. Once done,click on the “Add” button and the target will appear in the list below. Any number of suchtargets can be added. To make a target equal to a given value, specify two constraints withthe same name – one less than, and the other greater than, to the desired value. To delete atarget, select it in the list and click on the “Delete” button.

3.7.6 Using a custom postprocessor

AnXplorer employs its own scripts to read the simulator output and extract the values of theuser defined functions. However, the user can choose to use her own postprocessing programor script for this purpose.

This program can be written in any language - scripting or compiled. It can be invokedeither directly as an executable, e.g./home/me/bin/myprog option1 option2 ...

or through a scripting language interpreter, e.g.perl -I/home/mescripts /home/me/scripts/myscript.pl



This command can be specified by clicking on the check button labeled “Custom postpro-cessor program:” and then typing in the command in the entry field.

There are some restrictions on the command:

• AnXplorer will not do any validation on the program. It is the user’s responsibility toensure that the script functions properly on the simulator text output.

• The script should take four arguments as follows (all file and directory names are spec-ified as absolute paths) :

1. The directory where the simulation is run.

2. The input netlist file name of the simulation.

3. The text output file of the simulator. In case of Spectre, this will be the textoutput of OCEAN.

4. The output file for the postprocessing program. The program should write itsoutput to this file.

The output format of the postprocessor should be as follows:

• The first line of the file should be an integer which specifies the number of output valuescontained in the file.

• Each subsequent line should contain the name and value of one function in the form:namevalue.

• Functions which did not evaluate properly (i.e. the simulator could not calculate itsvalue) should be given a value of 2e+200.

This custom program can internally invoke the in-built post processing programs of AnX-plorer. These programs are as follows:

Simulator Script name Invoked as

Eldo el process el process inputfile "extract" output

Hspice hsp process hsp process input "meas ac" output

hsp process input "meas dc" output

hsp process input "meas tran" output

Spectre spec process spec process "meas ocn" input output

Msim msim process msim process input "meas" output

Finesim finesim process finesim process spice input "meas" output

(spice input)



A small sample of Perl code is given below as an example of how to use the in-builtpost-processor from within the custom post-processor for the Eldo simulator

#!/usr/bin/env perl

# Run el_process and store output in $tmp_output_file

‘el_process $input_file extract $tmp_output_file‘;

my $num_results = ‘head -1 $tmp_output_file‘;

my %additional_results;

read_additional_results($input_file, \%additional_results);

# read_additional_results is your function

# which does the custom post-processing

# Calculate total number of results and print it in output file

my $total_results = $num_results + scalar(keys %additional_results);

‘echo $total_results > $output_file‘;

my $t = $num_results + 1;

# Get the output of el_process in $output_file. The below command

# prints all lines of $tmp_output_file except the first one.

‘head -$t $tmp_output_file | tail -$num_results >> $output_file‘;

# Append your results to the output_file

while (my ($k, v) = each(%additional_results)) {

‘echo $k $v >> $output_file‘;

}

3.7.7 Monte Carlo simulation based analysis

This is an extension of the post-processing function based analysis. Instead of using a normalAC, DC or TRAN simulation, the user specifies the netlist of a Monte Carlo simulation. Thisis supported only when using Spectre as the underlying simulator. To use this mode, selectthe radio button labeled “Monte Carlo” in the “Analysis Type” section of the GUI. AnXploreruses the netlist specified to run a 20-simulation Monte Carlo analysis for every design pointthat is evaluated. The mean µ and standard deviation σ of each quantity being measured is



calculated from the simulation output. The minimum and maximum values are calculated asµ− 3σ and µ + 3σ respectively.

The target and limit specifications are the same as for other post-processing function basedanalyses, as defined in section 3.12. If the upper limit of a target is specified, AnXplorer triesto ensure that the maximum value of the target is less than the limit. Similarly, if the lowerlimit is specified, then it tries to ensure that the minimum value is less than the limit.

3.7.8 User defined equation based analysis

User can define any arbitrary function of the optimization variables and optimize that func-tion. A very common application of this is the circuit area optimization. The user can createan expression for the circuit area in terms of the lengths and widths (which are variables)of the transistors and set an upper limit on the area. Alternatively, any circuit performanceparameter, if it can be expressed as a function of the variables, can be optimized using thisanalysis.

Figure 3.13: GUI for defining user-defined equation based analysis

The GUI for defining these equations is shown in figure 3.13. The equations are enteredin the text entry box, one per line. The left hand side of the equation should use only thevariables and any previously defined target as the unknowns. The right hand side is thetarget name. The function is to be defined as a standard expression as in the C programminglanguage. All C standard library mathematical functions are available. An example equationis given below:



fx = -cos(x1)*cos(x2)*exp(-(x1-3.1415926)

*(x1-3.1415926)-(x2-3.1415926)

*(x2-3.1415926));

The euqation definition should be written in one line only, and should end with a ;.

The objectives on the equation values are to be entered in the lower part of the GUI,similar to the function based analyses. Enter the target name in the first entry box. Selectthe direction (greater than or less than), and then enter the target value in the lower entryfield. Clicking on the button labeled “Add” will add this target to the list. The GUI forcreating a user-defined equation based analysis is shown in figure 3.13.

3.8 Cost graph definition

In the preceding section, we defined how optimization targets for AnXplorer can be defined.Once the targets are defined, they can be ordered in the form of a hierarchical directed acyclicgraph in order of their importance. This is similar to a priority queue, though more general.Objectives which are either more important than others, or are perceived to be more difficultto achieve, should be placed at the top of the graph. We term this graph as the cost graph ofthe objectives.

Ordering objectives simply according to their importance or difficulty simplifies the opti-mization objective function definition. There is no need to explicitly specified “weights” foreach target, as is commonly done for a multi-objective optimization process.

An example of a cost graph for an operational amplifier is shown in figure 3.14. Here,the settling time of the amplifier is of paramount importance, followed by the static powerconsumption. The DC gain of the amplifier comes next. The phase margin, positions of thesecond dominant pole and the zero (if present) have the same priority, each less than thepriority of the DC gain. Finally, the unity gain bandwidth has the least priority. An edge inthe cost graph denotes a priority assignment, with the target at the tail of the edge havingmore priority than the target at the head of the edge.

From version 2011.04 onwards, the cost graph is specified in terms of “levels”. Each levelconsists of one or more optimization targets or constraints. The levels are placed one on topof the other, in a linear list. Each target comprising a given level “dominates” each target inthe level below it. This means that an edge is added (automatically) between each target inone level and each target in the level below.

As an example, the level-wise specification of the cost graph for the operational amplifierwill be as follows:


Cost graph definition 49

Figure 3.14: An example cost graph for an operational amplifier

Figure 3.15: GUI for defining the cost graph

• Level 0 : Settling time.

• Level 1 : Static power.

• Level 2 : DC gain.



• Level 3 : Phase margin, position of second pole, position of zero.

• Level 4 : Unity gain bandwidth.

The GUI for defining the cost graph is shwon in figure 3.15. The list on the left of theGUI initially shows all the defined targets and constraints, and at any point of time, showsthe targets which are not assigned to any level yet. As and when targets are assigned levels,they are removed from this list. This list may be empty when you first open this page afterdefining the targets. Please click on the button labeled “Refresh target list” at the bottomof the GUI to load the target names into this list.

Figure 3.16: GUI for defining a level in the cost graph

The list on the right side of the GUI shows the currently defined levels, and the objectivesin each of them. To create a level, click on the button labeled “Add” below this list box. Adialog window, as shown in figure 3.16 pops up. This window consists of two lists. The oneon the left shows the targets which are yet to be assigned to any level (if all targets havebeen assigned, this list will be empty). The list on the right shows the targets in this level.To move a target from the list of unassigned targets to this level, select the target name inthe list on the left, and click on the button labeled ‘-->’. Double-clicking on the target namealso has the same effect. Similarly, to remove a target from this level, select it in the list onthe right and click the button labeled ‘<--’ (or double click on the name). Once done, clickon the “OK” button, or to exit without any changes, click on the “Cancel” button.

The main window shows each level, where the objective names are separated by a ;

(semicolon). To edit a level, select it in the list and click on the button labeled “Edit”, ordouble click on the level in the list. The GUI for editing is the same as that for adding alevel. Objectives which are removed from the level, will reappear in the box for unassignedtargets on the left of the GUI.

To delete a level, select it in the list and click on the button labeled “Delete”. A dialogwill pop-up, asking the user to confirm the deletion. Once deleted, the objectives in a level


Running AnXplorer 51

show up in the list for unassigned targets. Also, if there were levels below the level justdeleted, they are “moved up” one position each, to maintain continuity in the level numbers.A selected level can also be moved up or down in the list, by clicking on the two buttonslabeled “Move up” and “Move down” at the bottom of the GUI.

3.8.1 Disabling cost graph rearragement

In the global optimization mode, the cost graph defined by the user is rearranged slightly withprobability 0.6 after each local optimum found by the optimizer. This can help in achievingall the optimization targets. This is also useful when the user is not entirely sure about therelative importance of the objectives. However, if the user does not want to modify the costgraph, she can disable this feature by selecting the check-button labeled “Disable cost graphrearrangement after each optima” at the top of the GUI. In the latest version of AnXplorerthis button is selected by default.

3.8.2 Score calculation using the cost graph

The method of calculating the raw score of an objective is described in the previous section.The prioritized score of an objective is calculated as follows:

Let two nodes (i.e. objectives) in the cost graph be p and c. If a continuous path (aset of edges) exists from p to c, then p is termed an ancestor or c, and c is a descendantof p. Let r be the raw score of an objective and let r′ be the maximum raw score of anyancestor of the objective in the graph. If r′ < 1, then r′ is set to 1. The prioritized score ofthe current objective is given by s = r · r′. Thus, if any objective more important than thecurrent objective is underachieved (i.e. its raw score is greater than 1), then the prioritizedscore of the current objective increases. The total score of the design point is the sum of theprioritized score of all the objectives.

3.9 Running AnXplorer

AnXplorer can be used in four modes:

• Feasibility analysis: This mode is used as a pre-cursor to the actual optimization runs.In this mode, AnXplorer searches the entire design space as defined by the optimizationvariables, for suitable design points which satisfy the (a) equation based objectives, and(b) the sizing rule constraints (both implicit and explicit). In this mode, only a singleprocess, voltage and temperature corner is used. The first model file, first temperaturevalue and first voltage value (if specified) are used. It is recommended to have a larger



granularity for the variables as it speeds up the search process. The search continues forthe number of iterations specified in the options definition page (default is 150). Theoutput of this mode is a “volume” of the design space – represented by ranges of thedesign variables – which is termed as the “feasible design space”. All (or most) designpoints within this space are expected to be “feasible”. This truncated design spaceshould be used as input to the global and centering optimization runs.

• Global optimization: In this mode, AnXplorer searches the design space (either thetruncated design space as found by feasibility analysis, or the entire design space, aschosen by the user) for suitable design points which satisfy all the user defined designobjectives (targets). Several locally optimal points are reported. In this mode, too, onlya single process, voltage and temperature corner is used. Here too, it is recommendedto have a larger granularity for the variables.

• Local design centering: In this mode, AnXplorer searches a smaller design spce(determined internally) around a user defined initial design point. The objective here isto find design points which satisfy the design objectives across all process, voltage andtemperature corners specified by the user. The optimization continues till no furtherimprovement is found locally. The tool reports the worst case objective values (discussedin more detail later) as well as the values for each corner.

• Design porting: This can be used to port a design from one manufacturing processto another manufacturing process with similar characteristics (for example, porting adesign from a TSMC 180nm process to an IBM 180nm process). The process starts, asin the case of design centering, with an user defined initial design point (which is theposition of the design point in the original process). Like design centering, in this mode,AnXplorer searches a smaller design space around this initial design point to find anoptimized design in the new process. However, unlike the design centering mode, theoptimization is done using only one nominal process, voltage and temperature corner.Optimization continues till no further improvement is found locally. The tool reportsthe ported design point, which can then be subjected to further design centering acrosscorners.

In addition to the automated optimization modes, AnXplorer can also be run in a manual“tuning” mode, where the user manually tunes the values of the design variables, and evaluatesthe performance of the circuit.

3.9.1 Running a test simulation

Before starting any of the optimization modes, it is advisable to run a test simulation, toensure that all simulator inputs and other optimizer options have been setup correctly. To



run a test simulation, click on the button labeled “Run test simulation” in the main toolbar, or select the option from the “Optimization” menu. If an initial design point (used forporting optimization and design centering) exists in the project, that design point will beused. Otherwise, the tool will create a random design point within the design space. All userspecified analyses will be run at this design point. If multiple corners are defined, the firstcorner in the list is used.

If an error occurs during the simulation, the error message is displayed in a pop-up window.If all simulations completed successfully, the values of the various objectives, calculated atthe design point, are displayed in a pop-up window. Please go through these values carefully.If an objective could not be calculated, then it is denoted by either 10100 or −10100. Thismay or may not be an error. For example, if the DC gain of an amplifier at a random designpoint is less than 0 dB, then the phase margin and bandwidth cannot be calculated. This isnot an error. On the other hand, if all objectives for a given analysis report undefined values,then it is a cause for concern. It means that even though the simulator did not return anerror status, the post-processing functions could not run properly. The user needs to debugthe simulation setup.

Once all simulation outputs look to be in order, the user should proceed to the next step– feasibility analysis.

3.9.2 Running feasibility analysis

The most important criterion (or constraint) of analog circuit optimization is that the DCoperating points should be stable, and as immune to variations in process/temperature/etc. aspossible. This means that all implict and explicit sizing rules must be met for a design pointto be termed as a “feasible design point”. The design space specified by the user usually haslarge regions where these constraints are not met, and thus there is no use of running furthersimulations at such points.

Further, all user defined equation based objectives are also evaluated in the feasibilityanalysis mode. For circuit optimization, the equation based objectives most often relate to ameasure of the area of the die. Evaluating these in the feasibility analysis mode ensures thatwe cut down the design space to only those regions which satisfy these area measures. Sincethese objectives are cheap to evaluate (since they do not involve running a simulation), theyadd little extra overhead to the optimization process.

Finally, any other objective that the user specifies to be included in the feasibility analysismode, will also be evaluated. The process of including an objective in the feasibility analysismode is described in section 3.7.1.

In this mode, the tool is presented with a set of design variables with defined ranges (in



the variables definition page), a set of options (in the options page) and a set of analysesthat should be run (in the analysis definition page). AnXplorer finds regions of the designspace where all sizing rules are met. It runs only the operating point simulations (more thanone may be used), and evaluates only the sizing rule objectives and the user defined equationbased objectives. The other objectives and simulations are ignored. The cost graph specifiedfor global/centering optimization is also not used. A special cost graph is constructed, whichplaces all the equation based objectives at the highest level. All sizing rule objectives areplaced in the next level and treated with equal importance. Further, the results of evaluationof all sizing rules are reported in detail to the user. AnXplorer finds the “volume” within thedesign space where all equation based objectives, implicit and explicit sizing constraints aremet. It reports this “volume” as truncated ranges of the design variables. These truncatedranges may be used for further global optimization.

The feasibility analysis mode has many advantages:

1. It eliminates portions of the design space which do not yield stable circuits or give riseto oversized circuits. When global optimization is run, we do not waste time evaluatingpoints within such regions.

2. The “feasible volume” identified by the tool is expected to be smooth in nature, withonly a few optimas lying within.

3. Since it runs only the DC operating point simulations and the computationally cheapequation based objective evaluations, it takes considerably lesser time than the moreexpensive transient and other such simulations. The other simulations are run dur-ing global optimization, but the design space is vastly truncated (after the feasibilityanalysis), thus resulting in a faster optimization time.

To run feasibility analysis, either click on the button labeled “Run feasibility” in thetool bar, or select the corresponding option from the optimization menu (keyboard shortcut:Ctrl+F). Before starting the search (in all modes – feasibility analysis, global optimization orcentering optimization) the tool performs a sanity check on the input and reports any error, ifpresent. The validity of the netlists and test benches are also validated by a “test simulation”which is performed prior to the actual optimization. The test simulation can fail if either:

• The user has chosen the wrong simulator, or the simulator could not be invoked (checkthe PATH variable).

• The simulator returns an error. This is possible if all variables in the design are notdefined in AnXplorer, or there is some error in the simulation setup, or simply if thesimulator fails to converge. The error is reported in a pop-up window and simulationinput and error log files are indicated, which the user can browse to rectify the problem.



• The output post-processor returns an error. This can happen if all defined objectivesare not found in the simulator output (maybe a missing measure statement in the testbench?).

Once the test simulation passes without errors, the actual optimization starts.

Figure 3.17: Top part of the output log GUI

The log of AnXplorer is displayed in the “Log” page of the GUI. The top part of the logpage, as shown in figure 3.17 displays the following:

• The output of AnXplorer as it appears on the standard output when run in commandline mode. This contains some informative messages, like the list of design variablesused, a summary of options, a summary of the defined targets, and a textual descriptionof the cost graph. As each locally optimum point is found, the position of the designpoint (i.e. the values of the design variables) and a textual description of the targetvalues are reported.

• The current iteration number is displayed in a label below the text box for the output.This is refreshed every 30 seconds.

• The best score reported by the tool so far. See the section on cost graph definition fordetails on score calculation. This is also refreshed every 30 seconds.

• The position of the design point for the best score. This is reported in a list with eachline containing a variable name and its value.



Figure 3.18: Lower part of the output log GUI

• The performance of the circuit at the best position, i.e. the values of the design objec-tives.

A “local optimum” design point is reported when a point is found whose performancecannot be improved upon by tweaking the variable values within a specified limit. After eachlocal optimum is found, it is reported by the tool. The tool then proceeds to search hithertounvisited regions of the design space. The locally optimum design points found by AnXplorerare shown in the lower part of the GUI, as can be seen in figure 3.18. These are not usedduring feasibility analysis, but are useful in case of the subsequent global optimization, toselect an initial design point for centering optimization. The list on the left shows the indexnumbers of the optima found. Selecting an entry in this list shows the score and performanceof the circuit at this optima, and also the position of the optima.

The “File” and “Optimization” menus will be disabled during optimization. Also allbuttons in the tool bar, except the “Stop” and “Show/Hide Help” buttons will be disabled.To stop the optimization process, either click on the “Stop” button, or type Ctrl+C.

Feasibility analysis stops once the user specified number of iterations are over (the numberof iterations are specified in the Options tab). If the number of iterations are not specified,then it runs for 60 iterations.

Once feasibility analysis is over, the ranges of the design variables representing the feasibledesign space is shown in the main log window. To update the range of the design variables



with the truncated range, click on the button labeled “Update variable ranges with feasiblerange” at the bottom of the log page. This will alter the ranges of the design variables, anddisplay the variable definition page. To go back to the original (user defined) variable ranges,use the menu option under the “File” menu (labeled “Revert var ranges” – keyboard shortcutCtrl+v).

Note: If feasibility analysis has been run once and the variable ranges have been updatedwith the feasible range, then each time the same project is loaded after that, the variabledefinition page will always show the truncated variable ranges. This is even if the user revertsthe variable ranges to the original values. However, choosing the “Revert var ranges” optionwill always revert the ranges to their original values.

The bottom part of the GUI has three button:

• A button labeled “Update variable range with feasible range”, as described above. Thiswill remain in the disabled state while running any optimization other than feasibilityanalysis.

• A button labeled “Create initial position file with this design point”. This will createan initial design point (which can be used for design centering or design porting) withthe optimum selected in the list of optima values. This button will remain disabledwhile running feasibility analysis and centering optimization.

• A button labeled “Export this design point”. Using this, the user can export the selecteddesign point into a SPICE input file, as .param statements, which can then be includedin a SPICE netlist file. Clicking on this will invoke a file selection dialog box, where theoutput file name can be selected. This should be used at the end of the optimizationprocess (either global or centering) to export the final design point.

3.9.3 Running global optimization

In this mode, the tool is presented with a set of design variables with defined ranges (in thevariables definition page), a set of options (in the options page), and a set of design objectivesand targets (in the analysis definition page) which the synthesized circuit should meet. Thismode is useful to locate “promising” regions of the design space, which can be explored furtherin the design centering mode. It is also useful to quickly explore the feasibility and suitabilityof different circuit topologies for a given set of specifications and constraints.

To run global optimization, either click on the button labeled “Run global” in the tool bar,or select the corresponding option from the optimization menu (keyboard shortcut: Ctrl+G).

The locally optimum design points found by AnXplorer are shown in the lower part ofthe GUI, as can be seen in figure 3.18. These optima can be used to create the initial design



point for design centering. To create the initial design with an optimum point, select it inthe list, and click on the button labeled “Create initial position file with this optima” at thebottom of the GUI.

Global optimization stops when all the stopping criteria (specified in the Options tab) aresatisfied, or the specified maximum number of iterations are over.

3.9.4 Running feasibility analysis and global optimization over multiple

corners

If multiple corners are specified, then the first corner in the list for each analysis is usedfor feasibility analysis and global optimization. If an analysis uses all corners, then the firstcorner in the Options page is selected. Otherwise, the first in the list of corners to be usedfor the analysis is selected. The input netlists are modified to use these values, removing anyexisting model file inclusion or temperature specification.

Feasibility analysis and global optimization can also be run across several user definedcorners. In this case, the user can create two or more analyses for the same test bench, usinga different set of corners for each analysis. Thus, if the first corner in the list is differentfor these different analyses, a different corner will be used for each of them in the feasibilityanalysis and global optimization modes.

3.9.5 Running in design centering mode

In this mode of operation, AnXplorer is presented with an initial design. The initial designcan be created by either:

• From an optimum position found in global optimization mode, as discussed earlier.

• From the result of a database query (disscussed later).

• Manually creating an initial design point file.

• Importing a SPICE input file to read in the parameter values.

To manually create an initial design point file, please select the option “Create initialpoint” from the “Optimization” menu at the top of the main GUI (keyboard shortcut:Ctrl+P). This will pop up a GUI as shown in figure 3.19. If an initial design point filealready exists for this process, the user will be asked whether she wants to overwrite theexisting file. In the pop up window, please enter the value of each variable at the initialdesign point. Note that the value must lie within the range of the corresponding variable,



Figure 3.19: GUI for creating an initial design point

as defined by its minimum and maximum values. Once the entries are filled up, click on thebutton labeled “Create file”. This will create the required file and close the window.

Alternatively, the user can also import the variable values from a SPICE file. Pleaseselect the option “Import initial point” from the “Optimization” menu (keyboard shortcut:Ctrl+W). This will pop up a file selection dialog box which can be used to select the inputfile. This input file should contain the variable values as .param statements, in the followingformat:

.param <variable name> = <variable value>

All variables must be assigned to, and the value must be within the range of the respectivevariables. Other statements in the file are ignored.

As a third alternative, the user can also create a text file defining the values for all thedesign variables. Each line of this file should define a variable using the .param statementformat as shown above. Only one variable can be defined per line. Also, do not leave anyblank lines or comments in this file. Once this is created, save it with name <project

name>.initial design.sp in the current project directory.

In design centering mode, the tool reports the worst case value for each objective acrossall user defined corners. For an objective which is to be minimized, the maximum value acrosscorners is the worst case. Similarly, for a maximization objective, the minimum value acrosscorners is the worst case. Different objectives can have their worst case values for differentcorners. For example, one can expect the settling time of an operational amplifier to be worstin the “slow” process corner, whereas the static current consumption would be maximumin the “fast” corner. Thus, all reported worst case values may not correspond to the same



corner. The objective values for all corners are reported for the final (converged) design pointin the log. Scroll down the text box to view it.

Note that an analysis is evaluated in only those corners which have been selected duringthe definition of the analysis. For example, if an analysis is specified to use only two out ofthree user defined corners, the worst case performance will correspond to those two corners.Further, equation based objectives do not use any corners.

As described in section 3.5.5, design centering can be run either across all corners, or foronly those corners where the objectives are not met. All corners for which objectives are notbeing met are reported in the log.

As for other optimization modes, the top part of the GUI displays the log, the currentiteration number, the worst case performance of the best design point and its position. Thelower part of the GUI shows the list of iterations, and the best performance at each iteration.

The score calculation for design centering differs slightly from global optimization. Here,the worst case value of an objective is used to calculate its raw score.

Design centering stops when all the stopping criteria (specified in the Options tab) aresatisfied, or no improvement is possible over two successive iterations.

Sensitivity analysis report

Once design centering finishes, AnXplorer produces a sensitivity analysis report. Each of thedesign variables are perturbed by ±5%, one at a time, and the variation of the worst casevalue of each objective is recorded. A low variation in the objective values indicates a designpoint which is indeed stable. This sensitivity analysis appears in the log window.

3.9.6 Running all steps automatically

Typically, in the above three step process (feasibility analysis, global optimization and designcentering), a human intervention is required after each step. For example, after the feasibilityanalysis, the user needs to choose the update the design variable space. After global opti-mization, the user needs to choose a suitable initial position from the list of optima, of byquerying the database (see section 3.10). However, AnXplorer provides a way to run thesethree steps automatically. We call this a “Workflow”. Here, after feasibility analysis, thedesign variable ranges are automatically updated. After global optimization, the optima withthe lowest score is selected to be the initial position for the design centering phase. The userneeds to enter the number of iterations the tool should run in the feasibility analysis modeand global optimization mode.



Figure 3.20: Pop up window to setup the automated workflow

To run an automated workflow, select the option “Create workflow ...” (keyboard shortcutCtrl+X) from the “Optimization” menu. The window shown in figure 3.20 pops up. The userneeds to enter the number of iterations for feasibility analysis and global optimization here. Ifany of these three steps need not be run, please uncheck the corresponding button. Clickingon the “OK” button will start the automated run. The “Log” page of the GUI will be broughtto focus and the log will be displayed normally.

3.9.7 Running in design porting mode

In the design porting mode, AnXplorer takes a design optimized for one manufacturing pro-cess, and tries to tune the variable values so as to make it optimized for a different manu-facturing process. The assumption here is that for two similar manufacturing processes, theoptimal design points will not be too far from each other.

To run porting, the user first needs to setup the optimization environment using the targetmanufacturing process. This means that the variable ranges, corner selection, technologyspecific parameters, testbench netlists etc., must be appropriate for the target manufacturingprocess.

The next step is to create an initial design point which is the value of the optimizeddesign point in the source manufacturing process. The initial design point can be eithercreated manually, or imported, as described in the section on design centering.

Once the initial design point has been created, the design porting process can be startedby clicking on the button labeled “Run porting” at the top of the GUI. In this optimizationmode, AnXplorer searches for an optimal design in a small design space around the initialdesign point. It uses the first user defined corner specified. Alternatively, one can use different



corners for the same analyses, using the method outlined in section 3.9.4. Like the designcentering process, the optimization proceeds in iterations, and the best performance aftereach iteration is displayed in the lower part of the GUI.

Please see section 6.5 for details of the textual output of AnXplorer.

3.9.8 Manual tuning

As mentioned earlier, AnXplorer can also be run in a manual tuning mode where the user setsthe values of design variables and evaluates the performance of the circuit. To use this mode,select the option “Manual tuning” from the “Optimization” menu in the menubar of the mainGUI (Keyboard shortcut: Ctrl+I). This pops up the GUI which is shown in figure 3.21.

Figure 3.21: GUI for manual tuning of design variables

The GUI consists of three “panes” whose widths are adjustable. The left pane shows theavailable corner configurations, if multiple configurations are available.

The middle pane of the GUI displays the values of the design variables as a set of “sliders”.These can be used to set the value of any design variable within its range. If an initial designpoint file exists for this project, then the values of the design variables as in the initial designpoint will be pre-loaded. The user can then adjust these.

The pane on the right displays the results of the analyses and will initially be an emptyframe. To evalute the circuit for a given set of variable values and a given corner configura-tion, click on the bottom labeled “Evaluate point” at the bottom of the GUI. The circuit isevaluated and the results (values of the target objectives and the score) are displayed in theright pane. The GUI will be inactive while the evaluation is ongoing in the background. If


Database query 63

the evaluation failed for some reason (e.g. simulator error), then the score and other outputswill be shown as “Unknown”. To find the worst case performance across available corners,click on the button labeled “Evaluate worst case”. The circuit is simulated across all thecorners and the worst case results are reported. Note that if an analysis does not use one ormore of the corners, it will not be evaluated in those corners. Further, corners are not usedin the case of user defined equation based objectives.

The user can create an initial design point file from this GUI. Please click on the buttonlabeled “Create initial point”. The values of the variables, as specified in the pane for variabledefinition, will be exported into the initial design point file. The design point can also beexported as a SPICE file, by clicking on the button labeled “Export design point”. This willinvoke a file selection dialog box which can be used to specify the output file name.

3.10 Database query

As mentioned earlier, AnXplorer dumps a record of all design points visited by it duringoptimization (both global and centering) into a database file. This can be queried using theGUI and also by a simple query language from the command line. Using it from the commandline gives more flexibility to the user. All types of queries supported in the command line arenot yet available in the GUI. These will be added in future.

The database file is updated every 2 iterations while AnXplorer is running. Thus databasequeries can be performed parallely while the optimization is ongoing.

Figure 3.22: The database GUI, before any database file is loaded

The GUI for the database query page, before any database file is loaded, is shown infigure 3.22. It consists of four buttons, labeled “Load global database”, “Load feasibilitydatabase”, ”Load centering database” and “Load porting database”. The lower part of theGUI will be blank. Clicking on any of these buttons will load the corresponding database, ifit is present in the project directory. If it is not present, or is corrupted, an error messagewill pop up. Once the database is loaded, the bottom part of the GUI will be populated andwill appear as shown in figure 3.23. All objective values defined by the user will appear inthe query definition form.

A query is a set of conditions on the values of the objectives. The result of a query isa set of design points where the objective values satisfy these constraints. Let us take anexample. Figure 3.23 shows the following objectives: I(vsupply), risedelay, falldelay,



Figure 3.23: The query definition GUI

skew, minbp and imax. Suppose the user wants to find all design points, where I(vsupply) <

0.9e-03, risedelay < 3e-10, skew < 2.5e-10 and imax < 1e-3. To constrain an objectivevalue, select the check-button corresponding to the objective name, select the direction ofconstraint (greater than, or less than), and enter the constrained value in the entry field. Anynumber of objectives can be selected in a query.

The input data to a query can be the entire database, or the output of a previously definedquery. This allows nested queries. Select the source of data for a query from the drop downmenu at the top of the GUI, labeled “Input data”. This menu always contains at least oneentry titled “Entire DB”, which means the entire database file. Names of previously definedqueries, if present, will also appear in this list.

Once the input data source is defined, enter a name for the query in the entry field labeled“Query name” at the bottom of the GUI. This name must be an identifier and should beunique, i.e. each query should have a different name. Once the query is defined, click on thebutton labeled “Evaluate”. The results of the query will be displayed in a pop-up window,which is shown in figure 3.24.

The definition of a query can be displayed by selecting it in the drop down menu and thenclicking on the button labeled “Display”. It can then be edited.

The results display window consists of two tables – the upper one shows the objectivevalues for all points which satisfy the constraints of a query. The lower table shows theposition of each of the points. Both tables are indexed by the Record index, which is theserial number of the database record. Thus, the position and performance of a particular


Contents of the project directory 65

Figure 3.24: The query result display window

design point are listed in the same row of the two tables. Currently, there is no facility tosort or search this table. These will be added in future.

There is a button at the top of the results window, labeled “Create initial position file”.To create an initial design position file for design centering from any of the design pointsreported in the results, click on this button. A pop up window will appear, prompting theuser for the record index of the design point. Enter the record index (from the table) of thechosen point, and then click on OK. The initial design point file is created. Similarly, thedesign point can be exported into a SPICE file by clicking on the button labeled “Exportdesign point”.

3.11 Contents of the project directory

This section gives a brief description of the contents of the project directory. As stated earlier,the contents should not be altered in any way manually, unless the user is absolutely sure ofwhat is being changed. Otherwise, it may lead to the tool being in an inconsistent state.

As an example, for a project named opamp, the project directory name will be opamp.xan.After a full run of optimization (feasibility analysis, global optimization, centering optimiza-tion or design porting), the project directory will contain the following things:



1. AnXplorer input file (see Chapter 4 for the syntax of the input file) for the variousoptimizations, named opamp.input

2. Optimization log files for the various optimization. Please see section 6.5 for details ofthe log file format. The names will be opamp.feasibility.log, opamp.global.log,opamp.centering.log and opamp.porting.log, for feasibility analysis, global opti-mization, design centering and design porting, respectively.

3. Output directories for the various optimization. Please see section 6.5 for details ofthe contents of the output directories. The names will be (in the same order asabove): opamp feasibility outdir, opamp global outdir, opamp centering outdir

and opamp porting outdir.

4. The exploration database files (which are in binary format) for the various optimizations.The names will be: opamp.feasibility.sdb, opamp.global.sdb, opamp.centering.sdband opamp.porting.sdb.

5. In case the user has run feasibility analysis, and updated the variable ranges with the fea-sible range, the original ranges of the variables are stored in the file opamp orig var range.The feasible range is stored in the file opamp.feasibility.range.

6. There will be a local copy of all testbench files. These will be named opamp.<analysis

name>.sp where <analysis name> is the name of the analysis (as defined in the GUI)associated with each testbench file. In case of Spectre, the file extension will be .scs

instead of .sp.

7. In case of usage with Spectre, there will be two other entities for each analysis:

• A local copy of all the OCEAN scripts created by the user, having the same namingconvention as the netlist files, but ending with an extension .ocn.

• A copy of the mapping directory (or "amap" directory) for each analysis.

8. The initial design point, exported from either the result of global optimization or designporting, or imported from outside. The name will be opamp.initial design.sp.

9. The technology parameter file, named opamp.tparam containing the parameters forimplicit sizing rule evaluation.

10. The file opamp.map contains the mapping between original file names and locally copiedfile names (for example, for the testbench files). This is used when the project directoryis copied to a new location .


CHAPTER 4

Preparing a design for optimization in the standalone graphical mode

AnXplorer optimizes a design so that it meets its performance goals. For the tool to run, thenetlists of the design and its test benches need to be prepared. This chapter describes howthe design netlists need to be set up for usage with different commercial simulators.

Throughout this chapter, we assume the following: The main block being optimized isdefined as a subcircuit which may be defined in a separate file. Each test bench has a separatenetlist which instantiates the main block, either by defining the main block subcircuit, or byincluding the netlist file of the main block. AnXplorer needs one or more such test benchnelists for optimizing a design.

All commercial analog simulators support parameterized netlists, i.e. netlists where somequantities are denoted by variables. While preparing the design for optimization, denotethe optimizable quantities, e.g. transistor width and length, value of passive devices, etc.,by such parameters. The user may assign some “test” values to these parameters to testthe simulation setup. Otherwise, she may choose to leave these variables undefined. Whileoptimizing a circuit, AnXplorer will assign different values to these variables and evaluatethe circuit at different design points. A design point is a set of values for the optimizablevariables.

AnXplorer currently supports the following simulators:

• The Spectre circuit simulator from Cadence Design Systems, Inc., used from the Ca-dence Analog Design Environment (ADE) with Cadence waveform calculator functionsas objectives.


68 Preparing a design for optimization in the standalone graphical mode

• Hspice, from Synopsys, Inc., using .measure statements as objectives.

• SmartSpice, from SILVACO, Inc., using .measure statements as objectives.

• Msim, from Legend Design Technology, Inc., using .measure statements as objectives.

• Eldo, from Mentor Graphics Corporation, using .measure and .extract statements asobjectives.

• Finesim, from Synopsys, Inc., using .measure statements.

• Finesim, from Synopsys, Inc., using Cadence ADE calculator functions.

In the next few sections, we discuss the flow for preparing the netlists with these commercialsimulators and design environments.

4.1 Usage with ADE using OCEAN scripts

If Spectre is the external simulator being used, the information in this section is meant forCadence 5.x users only. For designers using Cadence 6.x and Spectre as the simulator, thisis not useful, since AnXplorer is directly integrated with the Virtuoso Design Environment,and these steps are unnecessary. For 5.x users, it is necessary to follow these steps to setupa design, as AnXplorer is not directly integrated with the 5.x environment.

Additionally, if Finesim with Spectre format inputs is the external simulator, these stepsmust be followed to setup the design for optimization, irrespective of the version of theCadence design environment being used (see Section 4.1.6).

4.1.1 Creating the Spectre netlists and OCEAN scripts

OCEAN (Open Command Environment for Analysis), from Cadence Design Systems, Inc.,is a flexible way to run simulations and analyze outputs in the batch mode. AnXplorer canbe used with OCEAN scripts to calculate the objective function. OCEAN scripts can usea variety of analog simulators for performing actual simulation. However, in this flow, wecurrently support only Spectre as the underlying simulator. This flow is the easiest to useand can be listed as follows:

1. Prepare the main block and the test bench schematic views as is normally done inCadence Schematic Editor.

2. For each test bench schematic view, open ADE, import the variables from the cell view,and set up the required simulations.


Usage with ADE using OCEAN scripts 69

3. For DC operating point simulations, enable the printing of the operating point. Thiscan be done as follows: Open DC analysis, click on “Options” and then click on thecheck button labeled “print”. Note that this step is mandatory for using thein-built operating point analysis (see Chapter 3 and 6). Also note that the nameof the operating point analysis block in the input to AnXplorer, either from the GUI orcommand line, should be same as the name of the operating point analysis in the testbench. Usually, this name is dcOp.

4. Also, if the in-built operating point analysis is being used, dump the CDL netlist of thedesign. This can be done from the main icfb window. Use the option File → Export

→ CDL in the main window. Every time the design is changed, the CDL netlistneeds to be recreated.

5. Select the outputs to be saved. It is prudent to save only those outputs which arerequired for post processing the results and calculating the objectives. Saving everythingincreases the simulation time.

6. Define the post processing functions. There are usually two types of functions – oneswhich return a waveform and others which return a number. Any number of post-processing functions can be defined, but the performance objectives to be used foroptimization with AnXplorer must have a numerical return value. Also, the names ofthese performance objectives must be identifiers. They must begin with either a letter(a-zA-Z), or the underscore (“ ”) character and followed by any number of letters,digits, or underscore. Other characters are not allowed in the names of performanceobjectives. While creating the functions, to get the waveform at a node, say, net1, typegetData("/net1") in the calculator expression entry first, and then form the function.

7. Assign test values to the variables and run a test simulation to verify whether the setup is correct.

8. Once satisfied, dump the Spectre netlist and OCEAN script for this test bench. Tocreate a Spice desk in the Cadence Virtuoso environment, open Analog Artist and loadthe state defining the test bench. From the “Simulation” menu, choose “Netlist” →“Create”. This will pop up a text editor with the netlist file. From the text editor“File” menu, choose “Save as” to save the netlist in your work area. To create theOCEAN script, choose the option “Save script” from the “Session” menu in ADE,and then save the script. In the graphical mode of usage, the Spectre netlist and theOCEAN script should be saved in the same directory, and with the same name prefix.For example, if your Spectre netlist is saved as /home/test/testbench1.scs, then theOCEAN script should be saved as /home/test/testbench1.ocn.



4.1.2 Preprocessing the OCEAN scripts

If you are using AnXplorer in the graphical mode, then the above steps complete the designsetup. You now need to create the optimization setup by defining variable ranges, optimizationtargets, etc. Use the OCEAN scripts saved from ADE as the Spice file option of the analysisblocks. These OCEAN scripts need some pre-processing to be used with the tool. In thegraphical mode, these are done automatically. In the command line mode, the user needs toinvoke a preprocessing script for this purpose.

In the command line usage mode, the OCEAN scripts can be preprocessed using thefollowing command.

% xocean_pp -i <OCEAN script name> -o <output file name>

xocean pp is a script which does the preprocessing.

The preprocessed OCEAN script retains only the calculator function definitions (withslight modifications) from the input script. It adds a set of printf commands to print thevalues of the calculator functions, as shown below.

printf( "\n####anxplorer <target name> = %lg\n" <target name> )

The marker ####anxplorer is mandatory.

If the user chooses to edit the OCEAN script manually, then the following steps need tobe followed.

• From the original script, delete all lines except the ones which define the calculatorfunctions.

• For each calculator function, put in a printf statement as shown above.

At the end of the file, the following statement needs to be typed in:

printf( "\n&&&&&& End output &&&&&&\n")

Once the preprocessed OCEAN script is prepared (either manually or by using the propro-cessing script), use this as the netlist file attribute of the corresponding analysis in either thegraphical or command line mode. Please see Chapter 8 for an example of an OCEANscript.

Note: Hspice, SmartSpice, Eldo or Msim currently cannot be used as the underlyingsimulator if OCEAN scripts are being used. This feature will be added in the future.


Usage with ADE using OCEAN scripts 71

4.1.3 Editing the Spectre netlist

In the graphical mode of AnXplorer, the Spectre netlist is modified automatically. In thecommand line mode, this needs to be done manually. Edit the Spectre netlist as follows:

1. Remove all model file inclusion statements, if model file is specified in the configurationfile or the GUI. Otherwise, retain the model file inclusion statements. These statementsbegin with the keyword include.

2. Remove the definition of all parameters which are optimization variables. Retain thedefinition of other parameters. The optimization variables will be defined by AnXplorerand included in the netlist.

3. If temperature corners are being used, remove the temperature definition in the netlistfile.

4. If voltage corners are being used, remove the definition of the voltage supply variable.

5. The end of the file contains the commands for simulation and output saving. In thispart of the file, remove all info commands. Any statement where the second word isinfo is an info command. This needs to be done for any test bench netlist for whichan in-built analysis type (operating point or gain/bandwidth – see Chapters 3 and 6)will be evaluated. For analyses using post-processing functions, this is not necessary.The reason for this requirement is that AnXplorer, for in-built analysis types, requiresSpectre to dump waveform outputs in text format. However, these info commandsare supported only in the binary output formats of Spectre, which AnXplorer cannotpresently read.

6. If operating point analysis is being used, add the command: oppoint=logfile print=yes

in the statement defining the operating point analysis. Also, please note the name ofthe operating point analysis – it is typically dcOp. Use exactly the same name for theoperating point analysis block in the input to AnXplorer.

7. Edit the analysis names to be exactly same as the analysis names defined in the config-uration file or GUI.

4.1.4 Preprocessing the CDL netlist

The CDL netlist created for the test bench needs to be preprocessed. This is done automati-cally in the graphical mode. In the command line mode, the user needs to manually edit thenetlist as follows: In the file, the user needs to comment out the last .SUBCKT line and thelast .ENDS line. This is the definition of the top test bench cell and will have no I/O ports.A comment in CDL is indicated with a * at the beginning of the line.



4.1.5 License queueing

When AnXplorer is used with Spectre as the underlying simulator, it will by default expectthe Spectre license to be available. If it is not available when the tool starts, or becomesunavailable while optimization is ongoing, the tool will error out. To make AnXplorer waitfor the spectre license in a queue, please set the environment variable SPECTRE LICENSE QUEUE

to anything. When this is set, AnXplorer will wait indefinitely for a Spectre license to beavailable.

4.1.6 Usage with Finesim

Finesim is input compatible with Spectre and can be used to simulate Spectre netlists, usingthe -spectre command line option of Finesim. AnXplorer supports the use of Finesim withSpectre format inputs generated from Cadence ADE.

Note that this section applies to both Cadence version 5.x users and version 6.x users.The Cadence integrated mode of AnXplorer (see chapter 5) applies only when Spectre is theexternal simulator being used. It is not applicable in case of Finesim. Finesim users mustfollow the steps in this section in both Cadence 5.x and 6.x environments.

The process to be followed for creating the input netlists and OCEAN scripts is exactlythe same as described in Section 4.1.1. Further, if the pre-processing is being done by hand,then the user must follow the steps as in the previous sections. All other steps are also exactlythe same with the Spectre flow.

4.2 Usage with Hspice, SmartSpice, Eldo, Finesim and Msim

with Spice format inputs

Hspice, SmartSpice, Eldo, Finesim and Msim are input compatible (except for the .extract

statements which are available only in Eldo). Thus, we describe only the usage with Hspicehere. Usage with SmartSpice, Msim or Eldo is exactly similar. As with Spectre, the Hspicenetlist can also be created from ADE. The netlist thus created has to be edited as follows:

1. Remove all model file inclusion statements, if model file is specified in the configurationfile or the GUI. Otherwise, retain the model file inclusion statements.

2. Remove the definition of all parameters which are optimization variables. Retain thedefinition of other parameters.

3. If temperature corners are being used, remove the temperature definition in the netlistfile.


Usage with Dspice 73

4. If voltage corners are being used, remove the definition of the voltage supply variable.

5. For in-built analysis types, remove all .probe statements in the file and replace themwith .print statements for the appropriate outputs. For the in-built gain/bandwidthanalysis, print the magnitude and phase (vm and vp) of the output node. For the in-builtnoise analysis, print the input referred noise voltage.

6. For post-processing function based analysis, remove all .probe and .print statementsand add approprate .measure statements. The names of the measurements should bethe same as the name of the target as defined in the AnXplorer input.

7. Important: If the netlist was generated from ADE, near the end of the file, typicallythere will be two option statements like this: ARTIST=2 and PSF=2. Remove theseoptions.

Automatic editing of Hspice netlists is currently not available. This feature will be added inthe near future.

4.3 Usage with Dspice

Dspice is the in-built simulator of AnXplorer. It is a simple upgradation of the free sourceBerkeley Spice3, with some additional features like parameter substitution, .measure basedpost-processing, etc., added. It is just a prototype simulator, to be used only on very simpledesigns, for demonstration purposes. Its interface is aimed to be compatible with hspice, butthere are a few major deficiencies:

• The parameter scoping is not exactly like hspice, and thus it may not be able to handleall types of .lib statements for model inclusion.

• It does not support Verilog-A based models.

• It supports only a small subset of .measure statements supported by hspice.

The convergence mechanism of Dspice is, also, considerably weaker than those of commercialsimulators. It can often fail to converge.


CHAPTER 5

Using AnXplorer within the Cadence Virtuoso design environment

This chapter describes the usage of AnXplorer within the Cadence Virtuoso design environ-ment. This mode (which can only be used with Spectre as the underlying simulator) hasseveral advantages.

• This mode melds in seamlessly with the normal analog circuit design flow within theCadence environment.

• No need to separately create or edit test bench netlists and OCEAN scripts. AnXplorerdirectly creates these from the Cadence database.

• Optimized design variable values can be written back to the original cell view by theclick of a button.

However, this mode works only with the Cadence Virtuoso environment 6.1 and above.Version 5.x does not support many of the ADE L APIs that AnXplorer uses, and hence cannot be used in this mode. For 5.x users, the fall back is to generate netlists and OCEANscripts from ADE L, as described in chapter 4.

The concept of a project, setting up a project, defining variables, options and objectives,are all exactly similar to what has already been described in chapter 3. Thus, in this chapter,we highlight only those features and usage patterns which are unique to this mode of operation.


Enabling AnXplorer menu 75

5.1 Enabling AnXplorer menu

To start using AnXplorer in the Cadence Virtuoso mode, you need to add the following lineto the end of the .cdsinit file in all directories where you invoke virtuoso.

load( strcat( getShellEnvVar("AGO_ROOT") "/src/gui/skill/anxplorer.il" ))

Here, AGO ROOT is the environment variable which must be set to the root of the AgO instal-lation directory.

Once this is done, the “AnXplorer” menu will show up in the Schematic Editor windowmenubar, as shown in figure 5.1.

Figure 5.1: The menubar of the Schematic Editor window, with the AnXplorer menu

5.2 A project

Typically, in a design flow for a lower level analog block, the designer will create a schematicview of the cell (and possibly a symbol view as well). In addition, she will also have one ormore test bench schematics (not needed if the test bench is included in the cell schematicitself), and one or more ADE L state(s) for each test bench, to measure the performanceof the circuit. AnXplorer blends in seamlessly with this flow. Each cell being optimized istreated as a separate project in AnXplorer, and the ADE L states are used as the analysisfunctions.

When AnXplorer is invoked from the schematic view window of a cell, it automaticallytakes the name of the cell as the name of the project. The main window of the project, invokedby choosing the “Run AnXplorer” option in the “AnXplorer” menu, is shown in figure 5.2.

The appearance of the GUI is very similar to its appearance in the standalone mode. Thename of the cell from which the GUI is invoked, is taken as the project name. Thus, there is no“Save as” option in this version. The project directory is stored as anxplorer/libname/cellname.xanunder the current working directory. Here libname is the name of the Cadence library con-


76 Using AnXplorer within the Cadence Virtuoso design environment

Figure 5.2: The main GUI window

taining the cell, and cellname is the name of the cell being optimized. The contents of theproject directory are similar to what has been already described in section 3.11.

AnXplorer uses ADE L heavily for various purposes. During the run of the tool, theADE L window pops up automatically, and then disappears, several times. This is normalbehavior, and should not cause an alarm.

5.3 Variable definition, options definition, and technology spe-

cific parameters

The variable definition tab in this mode is similar to that in the stand alone mode, withone difference. In addition to the optimization variables, the GUI also shows the variablenames extracted from the cell view (and their values, if available) in a list box, at the bottomleft corner of the page. Clicking on the variables in this list will display the correspondingoptimization variable, if one has been already defined, Otherwise, it will show its name in the



entry field for the variable name. Please see section 3.4 for details on defining optimizationvariables.

The options definition tab is also similar, except that the widget to select the externalsimulator is absent in this case. This is because only Spectre can be used as the externalsimulator in this mode. Please see section 3.5 for details on the different options to be specifiedin this page.

The technology specific parameter definition tab, for defining the thresholds for the in-builtsizing rules, remains exactly the same. The details of this tab are described in section 3.6.

5.4 Analysis and target definition

In this mode of operation, AnXplorer supports three types of analysis:

1. Operating point analysis for node voltage constraints, power consumption constraints,implict sizing rule evalation, and explicit operating condition constraints on individualtransistors.

2. General simulation based analyses with user defined objectives. Calculator functionscan be used as objectives. This includes Monte Carlo simulation based analyses as well.

3. User defined quation based analysis, where the objectives are the values of a set ofarbitrary user defined functions.

Details of each type of analysis can be found in section 3.7.

To define an analysis, the user has to either mark it as a primary analysis, with itsown simulation inputs, or link it to another analysis. The concept is described in detail insection 3.7. The top part of the analysis definition GUI is shown in figure 5.3.

The simulation based analyses are again of three types:

• Simulations which can be performed from ADE L. Here, the user has to choose an ADEL state. The state must be storead as a cell view, and not a directory. Please select theradio button labeled “Use Artist state”. There are three entry fields, one each for thelibrary, cell and view names. These entries are disabled (user cannot directly type textinto them). To select a state, click on the button labeled “Browse”. This will bringup a library browser, as shown in figure 5.4. In this pop-up window, select the library,cell and view (actually an ADE state), and click on ‘OK”. This will populate the threeentry fields, and will automatically generate the Spectre netlist, OCEAN script, andCDL file for this analysis.



• Monte Carlo simulation based analysis, using a simulation defined in an ADE L state.Here, the user selects the ADE L state as above. The special simulator commandsfor performing a Monte Carlo simulation are generated by the tool and added to theSpectre netlist created from the ADE L state. The different options for Monte Carlosimulation can be specified by clicking on the button labeled “Monte Carlo options” inthe lower part of the GUI. Here, the user can specify:

– The variation method – process, mismatch, or both. Default is mismatch.

– The sampling method – random or latin hypercube sampling. Default is latinhypercube sampling.

– For latin hypercube sampling, the number of bins to be used. Defaults to 200.

– The random seed to be used for Monte Carlo simulation. Defaults to 12345.

AnXplorer uses this netlist to run a 20-simulation Monte Carlo analysis in the optimiza-tion loop. For each expression defined in the netlis, the mean µ and standard deviationsσ (for the 20 simulations) is calculated. The minimum and maximum values of thetarget are taken as µ− 3σ and µ + 3σ respectively. If a target has a upper limit, thenthe optimization objective is to have the maximum value less than the limit. Similarly,if a target has a lower limit, the objective is to have the minimum value greater thanthe limit.

• For Monte Carlo simulation based optimizations, the user can also choose to specifya Spectre netlist, created through ADE XL. To use this mode, please select the radiobutton labeled “Spectre netlist (only for MC)”. In this mode, the user has to specifythe location of a Spectre netlist to perform Monte Carlo simulation. This netlist can bespecified by using the button labeled “...”, which will pop up a file browser. The netlistsis usually found under the adexl simulation directory. The user needs to run MonteCarlo simulation at least once, from ADE XL, before this, to generate the netlist.

Alternatively, if one analysis can read data from the output of another analysis, the formercan be linked to the latter. To do this, check the button labeled “Link to analysis” and typein the name of the analysis in the entry labeled “Linked to”. An example of this could be asfollows. Suppose the user has defined a test bench which performs an operating point analysis,and a transient analysis. Some functions have been defined on the output of the transientanalysis. In this case, the user can define an operating point analysis in AnXplorer withthe corresponding ADE state. When the simulator is called, it will run both the simulations(operating point and transient), but the analysis will only analyze the operating point output.Another analysis can be defined, which will read the output of the earlier simulations, andanalyze the values of the functions defined on the transient analysis. Thus, the functionanalysis should be linked to the operating point analysis.



Figure 5.3: The top part of the analysis definition tab

Figure 5.4: Library browser

The selection of PVT corners for an analysis is exactly similar to what has been describedin section 3.7.2. Further, the specification of the constraints and objectives for operating pointand function analysis, and the score calculation methodology, are almost exactly similar towhat has been already covered in section 3.7. Thus, we omit these here. Operating point



analysis details can be found in section 3.7.3. The only difference is that here the user neednot explicitly specify a CDL netlist file, as it is automatically generated by AnXplorer. Thein-built noise analysis feature is not supported in this mode of operation. The user definedfunction analysis description can be found in section 3.7.5. The difference in this case isthat the user need not specify the type of simulation (AC, DC, transient, etc.) being usedfor the analysis. Simply select the radio button labeled “AC/DC/TRAN”. For Monte Carlosimulation based analysis, select the button labeled “Monte Carlo”. The GUI for a MonteCarlo simulation based analysis is shown in figure 5.5.

Figure 5.5: GUI for creating a Monte Carlo simulation based analysis in the Cadence Virtuosoenvironment

The definition of the cost graph of the different objectives can be found in section 3.8.

5.5 Running AnXplorer and back-annotating variable values

into the cell view

Before starting optimization, it is advisable to run a test simulation and check whether allsimulation inputs and other optimizer options have been setup correctly. This is described indetail in section 3.9.1.

As in the stand alone mode, here too AnXplorer can be run in four modes: Feasibiltyanalysis, global optimization, design centering and porting optimization. The semantics ofthese modes remain unchanged, and the details of each mode can be found in section 3.9.The automatic end-to-end run, or workflow (described in section 3.9.6) can also be used inthis mode.


Running AnXplorer and back-annotating variable values into the cell view 81

The database query GUI is also exactly similar to the stand alone mode. The detaileddescription can be found in section 3.10. The manual tuning GUI (see section 3.9.8) can beused here as well.

Optimized variable values can be back annotated into the cell view from multiple placesin the GUI:

1. From the Log tab of the GUI. In the lower part of the tab, the user can select anyoptima (in case of feasibility analysis or global optimization), or the end result of anyiteration (in case of design centering), and click on the button labeled “Export variablesto cell view’.

2. From the database query result window. Click on the button labeled “Export variablesto cell view”. A pop up window will appear, where the user has to type in the index ofthe point to be exported.

3. From the manual tuner GUI. Once satisfied with the simulation results, the user canchoose to export the variable values into the cell view by clicking on the button labeled“Export to cell view”.

In this mode of operation, there is no option to export a design point position as a SPICEinput file (this is available in the stand alone mode).


CHAPTER 6

Using AnXplorer from command line

As stated earlier, AnXplorer also has a command line usage model. This model provides theuser more flexibility in terms of input setup and analysis. It provides a few analysis typeswhich are not available in the GUI. The database query language offers many more featuresin the command line mode.

The inputs to AnXplorer in the command line mode are as follows:

• The configuration file, which defines the variables, options, analyses and targets, andthe cost graph.

• The technology specific parameter file (optional). In the GUI mode, this is defined inthe technology parameters page.

• The analysis test benches.

6.1 The configuration file

The configuration file is the main input to AnXplorer. It contains four sections which shouldbe written in the following order:

1. The variable definition section.

2. The optimizer options specification section.


The configuration file 83

3. The technology specific parameter definition section (optional).

4. The analysis and target definition section.

5. The targets priority assignment section (optional).

Each of these sections contain serveral commands or command blocks. Note that commandsor command blocks from different sections cannot be intermingled. For example, an analysisspecification cannot be placed in between two variable definitions.

6.1.1 Lexical convention

The language used in the configuration file is free format, i.e. spaces and newline charactersdo not matter.

Keywords

The following are reserved keywords of the input language and can be used only in theirdesignated positions. Some keywords are not used currently but reserved for future use.

abs ac acos

analysis_type asin atan

cdl_file cmrr cos

cosh corner cmrr

current_consumption dc dc_gain

deltav delvds directory

exp extract flicker_noise

frequency gain_bw granularity

HCG i_gain_bw ignore

input i_variable linked_to

log log10 log_partition

max_iters max_step max_val

midpoint min_val model_file

model_name montecarlo mos_constraints

node_voltage noise_analysis no_mutation

no_sizing_rule ocean_script op_point

parallel_exec pow reltol

sin sinh spice_file

sqrt subckt_mos_model tan

tanh techfile techspec


84 Using AnXplorer from command line

temperature thermal_noise total_noise

tran use_eldo use_eldo_compat

use_fsim_spice use_fsim_spectre use_hspice

use_msim use_ocean use_spectre

use_smartspice use_virtuoso variable

voltage_supply weight sim_options

Identifiers

Identifiers, e.g. variable and analysis names, can contain only alphanumeric characters andthe character. The first character should always be either a letter, or the character.

Note: If a variable name, a node name or an analysis name is either not an identifier,or clashes with a reserved keyword, it should be enclosed in double quotes (“”). Anythingenclosed within quotes is not subjected to any further lexical checks.

Numbers

Numbers can be specified either as integers, e.g. 123, or as floating point numbers, e.g. 1.23,or as floating point numbers using the scientific notation, e.g. 1.2e-3.

File names

A file name should be a proper UNIX style file name, either absolute path or relative path,enclosed in double quotes (“”).

Comments

Comments can be embedded in the configuration file to increase readability. The charactersequence // is treated as the beginning of a comment. The rest of the line after this sequence,till the newline character, is ignored by the reader. No other form of comment is currentlysupported.

6.1.2 Variable definition section

The general form of a variable specification is as follows:

variable <variable name> {

min_val <minimum value>;



max_val <maximum value>;

granularity <step size>;

}

The keyword step can be used in place of granularity in the example above. They have thesame meaning. The variable name should be an identifier (as described above) and minimumvalue, maximum value and step size should be numbers. Note the ; at the end of each line.

Variables which can take on only integer values should be specified using the keywordi variable instead of variable.

6.1.3 Optimizer options

Specifying the temporary directory

The optimizer needs a temporary directory where all temporary files will be placed. Interme-diate results are also stored in this directory. The temporary directory to be used is specifiedwith a command like this:

directory <directory name>;

This is transparent to the user in the GUI mode. Directory name should contain the path(relative or absolute) of the temporary directory. Note the ‘;’ at the end. This directory, ifnot already present, will be created by the tool. If the directory is not specified, then thedefault directory name is AgO outdir. If the directory is already present, its contents will bedeleted prior to running the tool.

Note: The directory name should be enclosed in double quotes.

Specifying the user defined corners

Corners are used for design centering. A corner consists of a model file name, a library cornername, a temperature value and a set of design variable values (all of them are optional). Thesyntax for corner definition is as follows:

corner "<corner name>" {

model_file "</path/to/model/file>", "<optional library corner>";

temperature <temperature value>;

variable {

"variable1" = <value1>;

...



"variableN" = <valueN>;

}

}

Please see section 3.5.8 for a detailed explanation of corners and how they are used. Multiplecorners can be specified.

Specifying the model file

Note: This has been phased out from version 2011.11 onwards, and is retained only forbackward compatibility. Use the corner definition instead.

Model file(s) to be used in the optimization process should be specified using this com-mand. The form of this command is:

model_file <model file name>, <model file name>, ... ;

Here, each model file name is either just a file name, or a tuple (<file name>, <corner

name>). If just the file name is mentioned, it will be included in the simulation file using a.include statement. If the file name and the corner name is specified, it will be includedwith a statement like .lib <file name> <corner name>.

Specifying the temperature options


Temeperature options can be specified with the following command:

temperature <value 1> , <value 2> , ... ;

The temperature will be included in the simulation spice deck by a .temp card.

Specifying the supply voltage options


Let the voltage supply parameter be called vsupplyvar. The supply voltage options canbe specified with the following command:

voltage_supply vsupplyvar <value 1> , <value 2> , ... ;



Selecting the simulator

To use the simulator of your choice, include the following command in the configuration file:

use_<simulator> ;

Here, <simulator> is one of virtuoso, hspice, smartspice, msim, spectre, eldo, eldo compat,fsim spice, fsim spectre . eldo compat invokes eldo with the -compat command line ar-gument. To use the native DSpice, do not specify any simulator command. If using directlyfrom Analog Artist, using OCEAN scripts for calculator functions, specify virtuoso as thesimulator.

Specifying the simulator command line options

The user can override the default command line options for the external simulator suppliedby AnXplorer at the time of invoking the simulator. The user supplied command line optionsfor the simulator can be specifed using the following syntax:

sim_options "<user supplied options>";

There are some restrictions on what options can be specified. Please see section 3.5.2 fordetails.

Enabling multi-threaded execution

To enable multi-threading, use the following flag in the configuration file:

parallel_exec <no. of threads>;

The number of threads may be left blank, and specified in the command line.

Maximum number of iterations

The maximum number of iterations in the feasibility analysis and global optimization modeis specified by the following command:

max_iters <number of iterations> ;

This option is used only in the global optimization and feasibility analysis modes.



Sizing rule

The in-built sizing rule evaluation can be turned off using the following command:

no_sizing_rule ;

Partitioning mode

Logarithmic partitioning of the variable value ranges can be specified by the following com-mand:

log_partition;

Disabling cost graph rearrangement

To disable the cost graph rearrangement feature, use the following command:

no_mutation;

6.1.4 Specifying the technology specific parameters

Using a separate technology parameter file

In the command line mode, the technology parameter file can be created separately andspecified in the configuration file. The technology parameter file should be specified with acommand like this:

techfile <tech file name>;

Any number of such files can be specified.

Note: Versions of AnXplorer prior to 2010.12 supported only one technology specificparameter file, and thus did not support different technology specific parameters for differenttypes of transistor. From version 2010.12 onwards, different rules can be specified for differenttransistors types, by specifying them in different files. This is useful for processes whichprovide more than one type of MOS transistors (e.g. a 1.8V transistor and a 3.3V transistor).

Further, from version 2010.12 onwards, there is also an option to specify the technologyspecific parameters in the main input file itself. The provision for a separate technologyspecific parameter file is retained for backward compatibility. The syntax of specifying thetechnology parameters within the main input file is described next.



Specifying technology parameters in the configuration file

The technology specific parameters for a model type can be specified using a command blocksimilar to what is shown below

techspec { // Reserverd keyword

model_name { // Model name specification section

N <comma separated list of NMOS model names>;

P <comma separated list of PMOS model names>;

}

<parameter> = <value>;

...

<parameter> = <value>;

}

The configuration file can contain any number of such command blocks, each for a differenttype of transistor.

NMOS and PMOS model names are specified in the model name section of the aboveblock. Any number of model names can be specified for each type (NMOS and PMOS) – thesame rules will apply to all.

AnXplorer requires several parameters to determine whether a circuit has been properlysized. The transistor model name section is followed by a series of parameter value definitions,as shown above. The parameter names are as follows:

N_VSAT_MIN P_VSAT_MIN N_A_MIN

P_A_MIN N_VTRIO_MIN P_VTRIO_MIN

N_V_MIN P_V_MIN N_V_MAX

P_V_MAX N_DELTA_VDS_MAX P_DELTA_VDS_MAX

• N VSAT MIN and P VSAT MIN denote the minimum allowable difference between VDS andthe overdrive for transistors in saturation (N and P respectively).

• N TRIO MIN and P TRIO MIN denote the minimum allowable difference between the over-drive and VDS for transistors in the linear region (N and P respectively).

• N V MIN and P V MIN denote the minimum overdrive for conducting N and P transistors.

• N V MAX and P V MAX denote the maximum overdrive for conducting N and P transistors.

• N DELTA VDS MAX and P DELTA VDS MAX denote the maximum allowable difference in theVDS of two transitors in a current mirror structure.



• N A MIN and P A MIN denote the minimum allowable area of transistors.

The <value> above has to be a real number.

6.1.5 Analysis and target definition

Operating point analysis

The operating point analysis can be specified with the following command block:

op_point <analysis name> {

node_voltage <node name> <voltage value in V>;

... // Multiple node voltages can be specified.

current_consumption <voltage source name> <current value in A>;

reltol <relative tolerance value>; // Relative tolerance

spice_file <testbench file name>; // Test bench file

ocean_script <ocean script file>; // When using with Spectre as simulator

cdl_file <cdl file name>; // CDL file describing the circuit netlist.

// MOS constraints section

mos_constraints {

<mos name> <delvds/deltav> <sign> <value> ;

... // Multiple MOS constraints can be specified.

}

corner <list of corners>;

amap_dir <location of the mapping directory, in case of Spectre>;

// If user chooses to include these targets in the feasibility

// analysis, the following statement needs to be added.

include_in_feasibility;

}

Here, the node names, voltage source name and MOS transistor names must be in theinternal format. One can use the GUI to get the name in the internal format from a normalhierarchical name.

The node voltage command is used to set node voltage targets and the current consumption

command sets the current limit. reltol sets the relative tolerance for node voltage error cal-culation. The testbench file for the analysis is specified using the spice file command.If sizing rule is not turned off, the CDL netlist needs to be specified using the cdl file

command. Sizing rule checking is implicit. Constraints on MOS devices are set using the



mos constraints command block. Each line in this block is a constraint on a separate de-vice. To set a constraint on the overdrive, use the keyword deltav, and for constraint onVds − Vdsat use delvds. <sign> is either <, or >.

The user should also specify the set of corners for which this analysis will be evaluated inthe design centering mode, as shown in the above block. If all corners are to be used, pleasespecify

corner "all";

If, on the other hand, no corners are to be used, replace all with none in the above command.Otherwise, specify a comma separated list of corner names (each enclosed in double quotes),followed by a semicolon. These corners must have been specified earlier.

In case of usage with Spectre as the simulator, the user must also specify the locationof the mapping directory, or the "amap" directory. This is usually present in the simulationnetlist directory created by ADE L. Inside the simulation directory (as specified in ADE L,usually defaulting to ./simulation), the path should besimulation/<cell name>/spectre/schematic/netlist/amap. This needs to be specifiedusing the amap dir command shown above.

To include this analysis (the node voltage and current consumption objectives) in the fea-sibility analysis mode, please specify the command include in feasibility in the analysisdefinition block (for further details, see section 3.7.1).

Gain, bandwidth and phase margin analysis

AnXplorer provides a built-in function for gain, bandwidth and phase margin analysis ofamplifiers. In this analysis, the user specifies the following:

• The expected DC gain of the output node. The magnitude of the input AC sourceis also required, as it is used to calculate the gain. The tool tries to increase the gainbeyond this limit.

• The expected unity gain bandwidth (UGB) of the amplifier. Here, too, the target isto increase the UGB beyond the specified limit.

• The expected phase margin of the amplifier, which will be increased beyond thespecified limit.

While these targets can be calculated easily using standard post-processing functions providedby different simulators, the value addition of this in-built analysis is that it tries to analyzethe Bode plot of the output node versus frequency. It searches for the existence of poles and



zeroes in the Bode plot, and tries to move the second dominant pole and any zero at least adecade beyond the unity gain bandwidth. Thus, it ensures that that the amplifier is stablein closed loop operation.

−+

− +

Vdd

Vss

out

inp

inm

vsmall

Vinp inp1 0 DC Vdd/2Vsmall inp inp1 DC 0 AC 1

.ac dec 100 1 10e+9

.print ac vm(out) vp(out)

Large R − Mega ohm range

Supply voltage

Load impedance

Large C Vinp

+

−

−

+

Figure 6.1: Test bench for gain, bandwidth and phase margin measurement.

The test bench for the above analysis should be set up in a manner similar to that shownin figure 6.1. Here, one input is held at AC ground and an AC signal is applied at the otherend. For fully differential amplifiers, AC signals are applied at both inputs.

This analysis is available only with simulators which give textual dumps of the outputwaveforms. Thus ocean scripts cannot be used. One must use either Hspice, Smartspice,Msim, Finesim or Spectre directly.

The test bench file should print the output node voltage (not dB) and phase (vm(out)and vp(out)).

The analysis is specified with the following command block:

i_gain_bw <analysis name> {

spice_file <test bench file name> ; // As before

// Alternatively, one can also use a linked_to command

// to link it with another analysis.

input <magnitude>; // Input AC magnitude, to calculate gain.

<node name> <gain in dB20> <UGB in Hz> <phase margin in degrees>;

corner <list of corners>; // As before.


include_in_feasibility; // Same as in operating point analysis

}



The magnitude of the input AC waveform is specified by the input command. The expectedgain, bandwidth and phase margin of the node specified by <node name> will be calculatedand optimized, i.e. the gain, bandwidth and phase margin of the synthesized circuit shouldexceed the specified values.

This analysis has 5 targets: Gain, bandwidth, position of second dominant pole (implicit),position of zero (implicit) and phase margin, listed in the order of their indices in the targetslist.

Noise analysis

Noise analysis is specified with a command block like this:

noise_analysis <analysis name> {

spice_file <test bench file name> ; // As in other analyses

// Alternatively, one can also use a linked_to command

// to link it with another analysis.

total_noise <total input referred noise voltage target> ;

frequency <frequency of noise measurement in Hz> ;

<device name> <thermal_noise/flicker_noise/total_noise>

<percentage contribution of the device> ;

// ... Many such device specific commands can be used.




}

As in other analyses, the device names should be hiearchical. Keywords thermal noise,flicker noise and total noise are used to indicate different types of noise measurementfor the device.

In the simulator test bench file, please print the input referred noise voltage.

Post-processing function based analysis

The post-processing function based analysis is expressed with a command block like thefollowing:

extract <analysis name> {

spice_file <test bench file name> ;

ocean_script <script file> ; // As in other analyses.



// Or else, use the linked_to command.

analysis_type <ac/dc/tran> ;

<target name> <sign> <target value>;

"<target name>" <sign> <target value>;

// Any number of such targets can be specified.




}

Here, <sign> is either < or >. Target name should normally be an identifier. However, ifenclosed in double quotes, any arbitrary string without a white space can be used.

User defined equation based analysis

User can define any arbitrary function of the optimization variables and optimize that func-tion. A very common application of this is the circuit area optimization. The user can createan expression for the circuit area in terms of the lengths and widths (which are variables)of the transistors and set an upper limit on the area. Alternatively, any circuit performanceparameter, if it can be expressed as a function of the variables, can be optimized using thisanalysis.

The general form of this analysis is as follows:

extract <analysis name> {

{

<target name> = <function of variables> ;

// Several such targets can be defined.

}

<target name> <sign> <target values> ;

// Several constraints can be defined.

}

The user can define several targets in the same analysis. Also, a target can use any previouslydefined target as one of its input parameters. The function is to be defined as a standardexpression as in the C programming language. All C standard library mathematical functionsare available.

An example of this type of analysis is given below:

extract esm {



{

fx = -cos(x1)*cos(x2)*exp(-(x1-3.1415926)

*(x1-3.1415926)-(x2-3.1415926)

*(x2-3.1415926));

}

fx < -0.5;

}

Here, x1 and x2 are variables and fx is the target.

6.1.6 Cost graph definition

The cost graph definition takes the following form:

HCG {

<level index>: <target 1 index> [<target 2 index>] ... ;

// Several such levels can be defined.

}

Here, level index is the index of the level of the cost graph being described (see section 3.8for a more detailed description of the concept of a hierarchical cost graph). It must be a anon-negative integer. It should be followed by a space separated list of target indices whichbelong to that level. In the cost graph definition, targets are indicated by their indices in thetargets list. The line must end with a semicolon.

Versions of AnXplorer prior to 2011.04 used a different scheme for cost graph definition.This scheme is retained for backward compatibility reasons, but the user is encouraged to usethe scheme described above. The syntax of the old scheme is as follows:

HCG {

<target 1 index> > <target 2 index>;

// Several such edges can be defined.

ignore <target 3 index> ;

// Several such ignore commands can be defined.

}

Each > denotes an edge in the graph. The two schemes can be mixed-and-matched. That is,the same HCG block in the configuration file can have both level definitions, as well as edgedefinitions.

Note: There can be only one HCG block in the configuration file.



6.2 Technology specific parameter file

If separate technology specific parameter files are used, its name has to be specified in theinput configuration file. The syntax of this file is much more restrictive than the inputconfiguration file. Specifically, comments and blank lines are not allowed. Commands can bewritten only in a specific order. It is not free-format. Each command should be in a separateline.

The technology parameter file consists of two sections:

1. The model name specification section.

2. The transistor parameter specification section.

These sections must be specified in the above order.

The MOS transistor model names used in the circuit and their type (N or P) are specifiedin this section. The section must begin with the keyword Model in a separate line. Eachsubsequenty line, till the parameter specification section, should consist of one model name(from the model file) followed by its type. An example is as follows:

Model

NCH N

PCH P

The parameters that can be specified here are shown in section 6.1.4. The parameterspecification section should begin with the keyword Parameters in a separate line. Eachsubsequent line must begin with a parameter name (refer to section 6.1.4) and the next entryshould be the value for the parameter in appropriate units. Each line should contain only asingle parameter definition. An example is shown below

Parameters

N_VSAT_MIN 0.05

P_VSAT_MIN 0.05

...

N_DELTA_VDS_MAX 0.1

P_DELTA_VDS_MAX 0.1

6.3 Initial design point specification

When running AnXplorer in the local design centering mode, an initial design point, specifiedas a set of parameter values, needs to be provided. This design point is to be written into a


Running AnXplorer from the command line 97

file and provided to the tool in the command line (by the -p argument). The design pointhas to be specified as a set of standard .param statements supported by Hspice[3] or othercommercial SPICE tools. Again, comments and blank lines are currently not supported inthe design point specification file.

6.4 Running AnXplorer from the command line

Invocation of AnXplorer and its command line options, are shown below.

% anxplorer \

-i <configuration file name> \

-f -- If running in feasibility analysis mode \

-pt -- If running in design porting mode \

-p <initial design point file, if running in centering or porting mode> \

-o <optional output file name> \

-d <optional database file name> \

-m <optional max number of threads> \

-t <max no of iterations> \

-e <search area for design centering>

• -i: This option is mandatory. Use this to specify the name of the input configurationfile.

• -f: This option (which is a flag) is used to run the tool in the feasibility analysis mode.

• -pt: This option (which is a flag) is used to run the tool in the design porting mode.

• -p: This option is mandatory in the design centering and design porting modes. If the-pt option is specified, the tool runs in porting mode. Otherwise, it runs in designcentering mode. The name of the file containing the initial design point (in the formatdescribed earlier) should be specified with this option. If this option is specified, thetool automatically runs in design centering mode.

• -o: This option is used to specify the name of the output log file.

• -d: The name of the exploration database file is specified using this option.

• -m: The maximum number of parallel threads is specified using this option. Thisoverrides the number of threads specified in the input configuration file.

• -t: The maximum number of iterations for global optimization is specified using thisoption. This overrides the iterations specification in the input configuration file.



• -e: In the design centering mode, the tool, by default, searches an area which is ±5%of the values of the design variables at the initial point. After each iteration, the initialpoint is updated and a new design space is searched. To change the size of the designspace being searched, use this option. The argument is a percentage value, e.g. 10, or2, or 15.

6.5 Outputs of AnXplorer

Major outputs of the tool are printed on the standard output. They are also printed inthe output log file as discussed above in the current directory which can be used for futurereference. The tool also stores the performance measures and score at each design pointexplored in the database file. After AnXplorer exits, this file can be queried to extract veryuseful information about the design points. The query language for the database is discussedin the next chapter.

As the tool run, a dot (‘.’) is printed on the standard output for every design point thatis evaluated. This gives a feel of the progress of the tool.

6.5.1 Log file format

The name of the log file, unless explicitly specified by using the -o option in the com-mand line, is derived from the name of the input file. For example, if the input file nameis test.input then the log file names will be test.feasibility.log, test.global.log,test.centering.log and test.porting.log, for the feasibility analysis, global optimiza-tion, design centering, and design porting modes, respectively.

When the tool is invoked, it prints a brief description of the variables used and the objec-tives specified. The user can use this message to verify whether the objectives specified in theconfiguration file are indeed what she wants. After this, the tool proceeds with optimization,one iteration after another. AnXplorer uses a stochastic optimization method. An “iteration”indicates a set of design points which are evaluated together. Based on the scores obtainedat each design point in one iteration, the positions of the design points in the next iterationare determined. At each iteration, key statistics for that iteration is printed in the log file. Asample line from the log file will look like this:

12 17.3385 17.3385 41.9345 48.819 552

The first column is the iteration number. The second column shows the best score found sofar. This number should approach the number of objective specified, as the process nears alocal optimum, since a score of 1 (or less) for each objective indicates that the objective has


Outputs of AnXplorer 99

been met. The third column indicates the best scrore encountered in that iteration. Note thatthis might be greater than the overall best score. The fourth column is the average score ofall positions evaluated in the iteration. The fifth column indicates the worst score encountedin that iteration. The last column indicates the number of positions evaluated so far in thecourse of the optimization process.

The above holds true for the global optimization and feasibility analysis modes. In thecase of design centering and design porting, the semantics are slightly different. Here, eachiteration has 10 sub-iterations. The statistics for each sub-iteration is printed in the abovemanner.

AnXplorer does a systematic exploration of the design space. In the feasibility analysisand global optimization modes, it finds several local optima, each of which are printed asthey are found. The information printed are: the position of the design point (the values ofthe variables), the performance measure of the design point, and its score. In case of designcentering and design porting, the same information is printed after each iteration.

In the feasibility analysis and global optimization modes, the tool exits when either

• all objectives have been met.

• the user specified maximum number of iterations are over. Note that the tool may notstop immediately after the specified number of iterations are over. It will proceed tillthe next optima is found, and then exit.

• the default maximum number of iterations (currently 200) are over.

In the design centering and design porting mode, the tool exits when there is no improve-ment in performance of the best point encountered, over two successive iterations.

In the global optimization and feasibility analysis modes, at the time of exit, the tool printsthe list of locally optimum points found, sorted in the ascending order of scores (i.e. bestones first). In case of design centering, in addition to the worst case performance of thefinal centered design, it also prints the performance at each corner. Finally, it also prints asensitivity analysis report. This shows by how much the worst case value of each objectivefunction varies, for a 5% variation in the value of each design variable.

6.5.2 Contents of the output directory

The output directory (as specified in the configuration file) contains subdirectories namediteration*, suffixed by the iteration number. Each subdirectory contains a file calledbest positions, which gives the best design points encountered by the tool till that it-eration. These can be analyzed to determine the path that was taken by the optimizer to



reach the optima. The file contains the position and performance of the positions encounteredby the tool, sorted in ascending order of score.


CHAPTER 7

Using the database query language

As mentioned in the previous chapters, AnXplorer dumps a record of all design points visitedby it global into a database file. This file can be queried (using a simple query language thatwe will discuss in this chapter) to extract useful information about the results.

7.1 Running the database queries

AnXplorer dumps the record of all design points visited into a database file. The user canspecify the name of the database file in the command line for AnXplorer. The default namefor the database file is <fname>.global.sdb and <fname>.centering.sdb in the global anddesign centering modes, respectively, where <fname> is the first part (before the extension)of the input configuration file being used. This file is updated intermittently, once every twoiterations, while AnXplorer is running. Thus, database queries can be run in parallelwith AnXplorer. The distribution of AnXplorer includes an executable called xdbsh whichhas to be used to read the database file. It can be invoked with a command line like this:

% xdbsh -d <database file name> -f <query file name>

This file can contain any number of queries. The query language is discussed in the nextsection.


102 Using the database query language

7.2 The query language

In this section, we discuss the language used for querying the database. Queries need to bewritten into a file, which then has to be provided as an input to the xdbsh executable.

The lexical convention of the query definition language is exactly similar to that of theconfiguration file discussed in Chapter 6. This language is free format, and every statementends with a ‘;’. It also supports comments of the same form as the configuration language.Identifiers must begin with a letter or the character, and the other characters can be letters,numbers, or .

7.2.1 Objective names

The purpose of a query is to impose some constraints on the objective values and searchfor design points where the objectives satisfy the specified constraints. The objective namesused in the query language are of the form: <objective name> (<analysis name>). Here<objective name> is the name of the objective. This can be the target names for functionbased analysis, or some in-built names for other special analyses (discussed next). <analysisname> is the name of the analysis block which defines this target. The objective names, whenused in the queries, should always be enclosed in double quotes (“”).

Target names for operating point analysis

Target names for operating point analysis are as follows:

• Node voltage targets are named as: error(<node name>) <analysis name>, wherenode names are hierarchical.

• Current consumption target is named as: i(<supply source>) (<analysis name>).

• The implicit sizing rule target is named as: sizing rule (<analysis name>).

• The MOS constraints target is named as: mos constraints (<analysis name>). Notethat the constraints for individual transistors are not available. A sum total of evaluationon all transistors is available as a raw score.

Target names for gain, bandwidth and phase margin analysis

Target names for this analysis are as follows:

• The gain at the output is specified by: gain(<output node name>) (<analysis name>).


The query language 103

• The bandwidth is specified by: ugb(<node name>) (<analysis name>).

• The second pole position is specified by: second pole(<node name>) (<analysis

name>).

• The zero position is specified by: zero(<node name>) (<analysis name>).

• Phase margin target is specified by: phase margin(<node name>) (<analysis name>).

Target names for noise analysis

• The total input referred noise voltage of the circuit is accessed by: total noise(<analysis

name>).

• Thermal noise for individual devices is accessed by: thermal(<device name>) (<analysis

name>). Similarly, flicker noise and total noise for the devices are accessed using thekeywords flicker and total in place of thermal.

7.2.2 Database entries

The database is a collection of entries. Each entry in the database contains the followinginformation.

• The position vector of the design point, i.e. values of all design variables.

• The score of this design point as assigned by AnXplorer

• The values of all the performance metrics.

7.2.3 Primary keys

The names of the performance metrics as described above, are used as the primary keysfor processing the database entries. For example, the database entries can be sorted in thedescending order of their gain. The score value of the entries can also be used as a primarykey. Primary keys are expressed as character strings enclosed in double quotes. For example:

"gain(outp) (ac1)" "ugb(outp) (ac2)" "score"

are primary keys. The names are case insensitive, i.e. "Gain" and "gain" mean the samething.



7.2.4 Data sets

A data set is a collection (not necessarily ordered in any specific manner) of database entries.A data set is also the basic input to any query.

The start point of any query is to collect all database entries into a data set. This canbe done using the function get(). This function returns a data set containing all databaseentries, which can then be passed on as argument to data set processing functions, or assignedto a variable (both of these are discussed next).

7.2.5 Data set operations

A data set operation function takes as input one or more data sets, and returns a data set.The language currently supports the following operations on a data set:

• Sorting a data set in ascending or descending order, based on the value of a givenprimary key. For example, we can choose to sort a data set in descending order of thevalues of gain.

• Finding the top n entries for a given primary key, i.e. to find the n highest values for thegiven primary key. Similarly, we can also find the bottom n entries, i.e. the n entrieswhich have the lowest values for the key.

• Finding all entries whose value for a given primary key is greater than a given value.Similarly, we can also find all entries whose value for a given primary key is less than agiven value.

• Common set operations – union, intersection and set difference of two data sets.

Data set operations can be composed, i.e. the output of one operation can be used as anargument to another operation. This nesting can be done to any depth, without restriction.However, for readability reasons it is best not to use two or more levels of nesting. Instead, oneshould use variables (discussed later) to achieve greater depths of nesting. Note: None of thedata set operations affect the argument data set. They all return new data sets. Therefore,the same data set can be used as argument to several operations.

Sorting

To sort a data set in ascending order of the values for a primary key, the sorta commandshould be used. The sortd command is used to sort in descending order. The syntax of thesetwo functions are as follows:



sorta(<data set>, "<primary key name>")

sortd(<data set>, "<primary key name>")

These two functions returns a sorted data set.

Finding top n or bottom n

To find the top n (n is user specified) values of a given primary key, the top function has tobe used. Similarly, the bottom function is used to find the least n values of a given primarykey. The syntax of these two functions are as follows:

top(<data set>, "<primary key name>", <N>)

bottom(<data set>, "<primary key name>", <N>)

These two functions return a data set containing n elements.

Greater than or less than

The gt function returns all entries in a given data set, whose value for a given primary key,is greater than a given value. Similarly, the lt function returns all entries whose value for agiven primary key is less than a given value. The syntax of these functions are as follows:

gt(<data set>, "<primary key name>", <value>)

lt(<data set>, "<primary key name>", <value>)

The <value> has to be a number, either an integer or a floating point number.

Union, intersection and difference

The union of two data sets can be obtained using the union function. Intersection is done bythe intersect function, and set difference is performed by the diff function. The syntax ofthese functions are as follows:

union(<data set 1> , <data set 2>)

intersect(<data set 1> , <data set 2>)

diff(<data set 1> , <data set 2>)

These functions also have shorthand notations: ‘+’ stands for union, ‘*’ stands for intersection,and ‘-’ stands for difference. Note that the ‘*’ operator has a higher precedence than ‘+’.For example, <set1> + <set2>*<set3> is not the same as (<set1> + <set2>)*<set3>. Itis best to use parentheses to disambiguate precedence.



7.2.6 Variables

Variables are placeholders or shorthand notations for data sets. A data set can be assignedto a variable. This variable can later be used as argument to data set operations. Variablesmust be assigned prior to use.

A variable name is an identifier, i.e. it must begin with a letter or the underscorecharacter. Variables can be assigned using the following type of statement:

<variable name> = <data set> ;

Note the ‘;’ at the end. The data set can be either the return value of the get() function,or the return value of any data set processing function. Variables are useful in increasing thereadability of a query.

7.2.7 Displaying results

The contents of a data set can be displayed using the display function. This will displaythe values of all performance metrics and the score of each database entry contained in theset, on the standard output. It the data set is empty, it will post a message <NO DATA>. Theposition function can be used to display the position vector (values of design variables) ofspecific database entries. The syntax of these two functions are as follows:

display(<data set>) ;

position(<data set> , <index of entry> ) ;

The index of the entry is an integer, to print the position vector of a specific database entry.To print the position of all entries in a set, the keyword all has to be used in place of theinteger.

7.2.8 Structure of the query file

Syntactically, a query file is a list of statements. A statement can be any one of the followingthree:

• A variable assignment statement.

• A display function call.

• A position function call.



A data set function, by itself, is not a syntactically valid statement. Each statement must endwith a ‘;’. The statement will be evaluated serially in the order in which they are specified.

An example of a query file will make the above discussion clearer. Let us assume that wewant to display the performance metric values for all entries whose gain is greater than 65 dband bandwidth is greater than 255 MHz, and phase margin is greater than 60 degrees, sortedin ascending order of the values of the propagation delay. This can be done as follows:

// Get all entries with gain > 65 dB.

g65 = gt(get(), "gain(outp) (ac1)", 65);

// Get entries with UGB > 255 MHz. Note the usage of g65.

b255 = gt(g65, "ugb(outp) (ac1)", 2.5e+8);

// Now prune according to phase margin.

pm60 = gt(b255, "phase margin(outp) (ac1)", 60);

// Sort and diplay

display(sorta(pm60, "delay"));

We also calculate another set: whose values of slew rate are greater than 600 V/µs. Wetake the intersection of these two sets. We now display the top ten entries of the intersectionin the descending order of the values of the slew rates. This can be done as follows:

sl600 = gt(get(), "srate (tran1)", 600e-6);

i1 = pm60*sl600;

// This can also be written as: i1 = intersect(pm60, sl600);

// Get the top 10

t10 = top(i1, "srate (tran1)", 10);

// Sort and display

display(sortd(t10, "srate (tran1)"));


CHAPTER 8

Examples of input files to AnXplorer

In this chapter we provide an example of each type of input file to AnXplorer. The test circuitis a two stage opamp whose schematic is given in figure 8.1.

Vin(+)Vin(−)

Gnd

Vdd

Vout

Figure 8.1: Example two stage opamp circuit


Netlist file 109

8.1 Netlist file

The netlist of the above circuit, using variable dimensions for all transistors and capacitors,is given below.

* Two stage opamp circuit

* Current mirror attached to bias source.

MM10 net1 net1 vdd vdd PCH w=pcm1w l=pcm1l


Ibias net1 gnd DC 100u

* N current sources

MM8 net2 net2 gnd gnd NCH w=ncm1w l=ncm1l

MM7 net3 net2 gnd gnd NCH w=ncm2w l=ncm1l

MM6 out net2 gnd gnd NCH w=ncm3w l=ncm1l

* N differential pair.

MM1 net4 inm net3 gnd NCH w=ndpw l=ndpl

MM2 net5 inp net3 gnd NCH w=ndpw l=ndpl

* P current mirror



* Output P transistor

MM5 out net5 vdd vdd PCH w=popw l=popl

* Compensation circuit

Rc net5 net6 r_comp

Cc net6 out c_comp

cload out gnd 1.5p


110 Examples of input files to AnXplorer

8.2 Configuration file

Following is an example of the configuration file. This file can be found in the examples

directory of the AnXplorer distribution.

// Variable specification section.

// Length of P current mirror transistors attached to the current bias

// source.

variable pcm1l {

min_val 0.6e-6;

max_val 10e-6;

granularity 0.1e-6;

}

// Width of the above transistors.

variable pcm1w {

min_val 0.8e-6;

max_val 400e-6;

granularity 1e-06;

}

// Length of the P current mirror transistors in the input stage.

variable pcm2l {

min_val 0.6e-6;

max_val 10e-6;

granularity 0.1e-6;

}

// Width of the above transistors.

variable pcm2w {

min_val 0.8e-6;

max_val 400e-6;

granularity 1e-06;

}

// Length of P transistor in output stage.

variable popl {


Configuration file 111

min_val 0.6e-6;

max_val 10e-6;

granularity 0.1e-6;

}

// Width of above transistor

variable popw {

min_val 50e-6;

max_val 400e-6;

granularity 1e-06;

}

// Width of N differential pair transistors in the input stage.

variable ndpw {

min_val 100e-6;

max_val 400e-6;

granularity 1e-06;

}

// Length of the above transistors.

variable ndpl {

min_val 0.6e-6;

max_val 5e-6;

granularity 0.1e-6;

}

// Length of the N current mirror transistors below the input pair.

variable ncm1l {

min_val 0.6e-6;

max_val 200e-6;

granularity 1e-6;

}

// Width of the N transistor in the bias stage.

variable ncm1w {

min_val 0.8e-6;

max_val 400e-6;

granularity 1e-06;

}



// Width of the N current source transistor in the input stage.

variable ncm2w {

min_val 0.8e-6;

max_val 400e-6;

granularity 1e-06;

}

// Width of the N current source transistor in the output stage.

variable ncm3w {

min_val 10e-6;

max_val 400e-6;

granularity 1e-06;

}

// Value of the compensation resistor

variable r_comp {

min_val 10;

max_val 1000;

granularity 5;

}

// Value of the compensation capacitor.

variable c_comp {

min_val 0.01e-12;

max_val 2.0e-12;

granularity 0.01e-12;

}

// Directory where all the simulations will be run.

directory "outdir";

// Technology specific parameter definition for multiple types of

// transistors

techspec {

model_name {

N nch;

P pch;

}


Configuration file 113

N_VSAT_MIN = 0.15;

P_VSAT_MIN = 0.15;

N_A_MIN = 1e-12;

P_A_MIN = 1e-12;

N_VTRIO_MIN = 0.15;

P_VTRIO_MIN = 0.15;

N_V_MIN = 0.2;

P_V_MIN = 0.2;

N_V_MAX = 1;

P_V_MAX = 1;

N_DELTA_VDS_MAX = 0.1;

P_DELTA_VDS_MAX = 0.1;

}

techspec {

model_name {

N nfet;

P pfet;

}

N_VSAT_MIN = 0.15;

P_VSAT_MIN = 0.15;

N_A_MIN = 1e-12;

P_A_MIN = 1e-12;

N_VTRIO_MIN = 0.15;

P_VTRIO_MIN = 0.15;

N_V_MIN = 0.2;

P_V_MIN = 0.2;

N_V_MAX = 1;

P_V_MAX = 1;

N_DELTA_VDS_MAX = 0.1;

P_DELTA_VDS_MAX = 0.1;

}

// File containing the main netlist

netlist_file "netlist";

// The model file specification

model_file ( "model.sp" , "typ" ) , ( "model.sp" , "fast" ) ,

( "model.sp" , "slow" );



// Temperature specificaiton

temperature 25 , -40 , 80 ;

// Enable multi-threading

parallel_exec 4;

//

// Analysis and objective section.

//

// In-built operating point analysis.

op_point op1 {

// Expected output voltage ~ 1.35 +/- 0.2*1.35

node_voltage out 1.35;

reltol 0.2;

// The current drawn from source vsupply <= 2 mA

current_consumption vsupply 2.0e-3;

// Weight of this analysis.

// The testbench has been given in this file.

spice_file "op_eval.sp";

}

// In-built gain, bandwidth and phase margin analysis.

i_gain_bw ac1 {

input 1; // The magnitude of the input AC voltage source.

linked_to op1; // The output is available in the output of

// analysis op1.

out 68 255e+6 56; // Gain in dB, bandwidth and phase margin.

}

// Slew rate and delay calculation with user defined functions.

extract sd {

spice_file "tran_eval.sp";

analysis_type tran;

srate > 600; // slew rate > 600 V/us

delay < 2e-9;

}


Technology parameter file 115

// Cost graph specification.

HCG {

0: 1 2; // Current consumption (op1) and sizing rules (op1)

// are the highest priority

1: 3 8 9; // gain (ac1), srate (sd), delay (sd) are next

2: 7; // phase margin (ac1)

3: 4; // bandwidth (ac1)

}

8.3 Technology parameter file

An example of a technology specific parameters file is given below. This file, too, can befound in the examples section of the AnXplorer distribution.

Model

NCH N

PCH P

Parameters

N_VSAT_MIN 0.01

P_VSAT_MIN 0.01

N_A_MIN 1e-12

P_A_MIN 1e-12

N_VTRIO_MIN 0.01

P_VTRIO_MIN 0.01

N_V_MIN 0.02

P_V_MIN 0.02

N_V_MAX 1

P_V_MAX 1

N_DELTA_VDS_MAX 0.1

P_DELTA_VDS_MAX 0.1

8.4 Database query file

An example of a database query file is given below. This file, too, can be found in the examplessection of the AnXplorer distribution.

//



// Get the best 200 positions in terms of gain.

//

g20 = top(get(), "gain(out) (ac1)", 200);

//

// Among these, select those with phase margin > 55 degrees.

//

pm = gt(g20, "phase margin(out) (ac1)", 55.0);

//

// Get the top 20 from these in terms of slew rate.

//

sl = top(pm, "srate (sd)", 20);

//

// Get the 5 least delay values among these.

//

dl = bottom(sl, "delay (sd)", 5);

//

// Display the above result.

//

display(dl);

//

// Find all results where gain > 65 and ugb > 2.5e+8 and

// phase margin > 56 and delay < 3 ns and get the 10 which

// have the least delay..

//

t1 = bottom(lt(gt(gt(gt(get(), "gain(out) (ac1)", 67),

"ugb(out) (ac1)", 2.5e+8),

"phase margin(out) (ac1)", 56),

"delay (sd)", 3),

"delay (sd)", 10);

//

// Display these results by sorting in descending order of slew rate.

//

display(sortd(t1, "srate (sd)"));


OCEAN script example 117

//

// Display the position vectors of the first three elements in t1.

//

position(t1, 0);

position(t1, 1);

position(t1, 2);

//

// Take the intersection of dl and t1.

//

t4 = intersect(t1, dl); // This can also be written as t4 = t1*dl;

// Display.

display(t4); // This might be an empty set.

t4 = t1+dl; // Union of t1 and dl

t5 = t4-t1; // Set difference of t4 and t1. This is actually dl,

// since t1 and dl are disjoint.

// Display the result by sorting in ascending order of

// gain (least first).

display(sorta(t5, "gain(out) (ac1)"));

8.5 OCEAN script example

An OCEAN script, once saved from Analog Artist, will appear somewhat like this.

simulator( ’spectre )

design( "/home/testuser/simulation/testbench1/spectre/schematic/netlist/netlist")

resultsDir( "/home/testuser/simulation/testbench1/spectre/schematic" )

modelFile( ’("model.SCS" "TT" ) )

)

analysis(’dc ?saveOppoint t ?save "allpub" ?additionalParams "oppoint=logfile" )

analysis(’ac ?start "1" ?stop "100G" ?dec "100"

?save "allpub" )

desVar( "rc1" 760 )

desVar( "cc1" 3.7p )

desVar( "W34" 49u )

desVar( "W33" 19u )

envOption(



’firstRun nil

’analysisOrder list("dc" "ac")

)

saveOption( ’subcktprobelvl "2" )

temp( 27 )

run()

bw_1 = cross(mag(v("/outp" ?result "ac-ac")) 1 1 "either" nil nil)

plot( bw_1 ?expr ’( "bw_1" ) )

pm_1 = phaseMargin(v("/outp" ?result "ac-ac"))

plot( pm_1 ?expr ’( "pm_1" ) )

gain_1 = value(dB20(mag(v("/outp" ?result "ac-ac"))) 1)

plot( gain_1 ?expr ’( "gain_1" ) )

After pre-processing, the script appears as shown below:

bw_1 = cross(mag(v("/outp" ?result "ac-ac")) 1 1 "either" nil nil)

pm_1 = phaseMargin(v("/outp" ?result "ac-ac"))

gain_1 = value(dB20(mag(v("/outp" ?result "ac-ac"))) 1)

printf( "\n####anxplorer bw_1 = %lg \n" bw_1 )

printf( "\n####anxplorer pm_1 = %lg \n" pm_1 )

printf( "\n####anxplorer gain_1 = %lg \n" gain_1 )

printf( "\n&&&&&& End output &&&&&&\n")

Note that all plot commands have been removed and print commands with the specialformat have been added at the end.

8.6 Spectre netlist example

An example Spectre netlist, as created from Analog Artist, is shown below. The actual circuitdefinition is omitted for brevity.

simulator lang=spectre

global 0 vdd! sub!

include "/root/CADENCE/tools.lnx86/dfII/samples/artist/ahdlLib/quantity.spectre"

parameters vsupply=1.8 W4=75u W3=75u W2=75u W1=75u W0=75u

include "models.scs" section=TT

// Circuit definition => Omitted for brevity


Spectre netlist example 119

simulatorOptions options reltol=1e-3 vabstol=1e-6 iabstol=1e-12 temp=27 \

tnom=27 scalem=1.0 scale=1.0 gmin=1e-12 rforce=1 maxnotes=5 maxwarns=5 \

digits=5 cols=80 pivrel=1e-3 ckptclock=1800 \

sensfile="../psf/sens.output" checklimitdest=psf

ac ac start=10 stop=10G annotate=status

dcOp dc write="spectre.dc" maxiters=150 maxsteps=10000 annotate=status

dcOpInfo info what=oppoint where=rawfile

modelParameter info what=models where=rawfile

element info what=inst where=rawfile

outputParameter info what=output where=rawfile

designParamVals info what=parameters where=rawfile

primitives info what=primitives where=rawfile

subckts info what=subckts where=rawfile

saveOptions options save=allpub subcktprobelvl=2

The above netlist needs to be preprocessed to the following:

simulator lang=spectre

global 0 vdd! sub!

include "/root/CADENCE/tools.lnx86/dfII/samples/artist/ahdlLib/quantity.spectre"

// Parameter definition removed

// Model inclusion removed.

// Circuit definition => Omitted for brevity

// Note that the temperature definition has been removed.

simulatorOptions options reltol=1e-3 vabstol=1e-6 iabstol=1e-12 \

tnom=27 scalem=1.0 scale=1.0 gmin=1e-12 rforce=1 maxnotes=5 maxwarns=5 \

digits=5 cols=80 pivrel=1e-3 ckptclock=1800 \

sensfile="../psf/sens.output" checklimitdest=psf

ac ac start=10 stop=10G annotate=status

// Added oppoint=logfile print=yes to the command.

dcOp dc write="spectre.dc" maxiters=150 maxsteps=10000 annotate=status \

oppoint=logfile print=yes

// Removed all info commands.

saveOptions options save=allpub subcktprobelvl=2


Bibliography

[1] P. E. Allen and D. R. Holberg, CMOS Analog Circuit Design, London, U.K.: OxfordUniv. Press, 1987

[2] The Spice Page [Online], Available:http://bwrc.eecs.berkeley.edu/Classes/IcBook/SPICE

[3] HSPICE [Online] Available:http://www.synopsys.com/products/mixedsignal/hspice/hspice.html

[4] Virtuoso Spectre Circuit Simulator [Online] Available:http://www.cadence.com/products/custom ic/spectre/index.aspx

[5] SmartSpice: The Gold Standard Analog Circuit Simulator [Online] Available:http://www.silvaco.com/products/circuit simulation/smartspice.html

[6] MSIMR© High Accuracy Circuit Simulator [Online] Available:http://www.legenddesign.com/products/msim.shtml

[7] Eldo [Online] Available:http://www.mentor.com/products/ic nanometer design/analog-mixed-signal-verification/eldo/

[8] ActiveState [Online] Available:http://www.activestate.com/Products/activetcl/


Documents

AgO User's Manual