Schematic
Optimization
Centering
AnXplorer User’s Manual 2012.10
AnXplorer: User’s Manual Software 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 recipient 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 info@ago-inc.com
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
Supported simulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.3
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.6
3.7
3.8
3.9
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
Technology specific parameter definition . . . . . . . . . . . . . . . . . . . . . .
30
3.6.1
Sizing rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.6.2
Using the technology parameter GUI . . . . . . . . . . . . . . . . . . . .
33
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
Cost graph definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
3.8.1
Disabling cost graph rearragement . . . . . . . . . . . . . . . . . . . . .
51
3.8.2
Score calculation using the cost graph . . . . . . . . . . . . . . . . . . .
51
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 4.1
67
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 6.1
82
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
c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
CHAPTER
1
Introduction
1.1
Background
Demand for efficient analog circuits has grown significantly over the last few years for application 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 market. Such explosive growth comes with the challenge of producing much more in a shorter time. The industry, therefore, requires proper automation of effort intensive stages in the design flow. One such stage is design optimization.
1.2
Product offering
AnXplorer is a software solution for simulation based synthesis/optimization of general analog and radio frequency (RF) circuits by efficient design space exploration. It can be used by circuit designers to quickly explore different circuit schematics to identify the right choice. It also 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 specifications and constraints, and produces an optimized and centered netlist. It uses a SPICE simulator to evaluate the target design. It supports design-equation based optimization as well. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Overview of product
1.3
9
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 which the user wants to optimize. 2. A set of design objectives. AnXplorer will optimize the given circuit such that it meets these design objectives. 3. A set of design variables. AnXplorer can change the values of these variables in order to 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 to optimize, 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 number of corners is equal to number of process corners × number of temperature values × number of supply voltage values. AnXplorer optimizes the circuit to ensure that the design objectives are met across these corners.
Outputs The outputs of AnXplorer is an optimized and centered netlist which meets or exceeds the specified design objectives. It reports several optimal results found and the user can choose between them. In addition, it also produces an exploration database — a persistent storage for all design points explored by AnXplorer during the process of optimization. It is stored as 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. noise and 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 a particular purpose. It also has circuit-specific intelligence built into it, which eases the task of the designer to specify the design objectives. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
10
Introduction
Figure 1.1: Inputs and outputs of AnXplorer
• It supports all types of devices and processes, and is not limited to CMOS processes only. • It uses a SPICE simulator in the background to evaluate performances of different points in the user defined design space. Currently, it is integrated with commercial simulators 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 environments. Here, the GUI is invoked from a command prompt. – A mode which is completely integrated with the Cadence Virtuoso design environment. In this mode, the tool is invoked via a menu button within the schematic editor window. It can extract design variable names and create netlists by reading the Cadence database. It can also annotate design variable values into the database. 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 this document. This manual is organized as follows: c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
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 environment, 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 later stage (after describing the input setup for AnXplorer ) so that the user understands the rationale behind the steps more easily. • Finally, in Chapter 8, we present an example of an optimization setup.
c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
CHAPTER
2
Setting up AnXplorer
2.1
Supported operating systems
At present, AnXplorer is available for the Linux operating system. The following versions are supported: • Red Hat Enterprise Linux 5, Kernel version 2.6.18-194 and above, both 32 bit and 64 bit 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. Unzip and 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, the directory created will be called AgO.2011.07. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
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 to have a functional internet connection for this to work, since this downloads some Tcl packages from external repositories.
Editing the setup file The file setup.csh in the directory AgO/<version> needs to be edited to reflect the path of the 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, then set the value of this variable to /home/<you>/test/AgO.<version>. You will also need to edit 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, please contact us at AgO Inc. By default, the license file is present in the subdirectory license of the 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 the setup.csh file and set the value of the AGO LICENSE FILE variable to reflect the path of the license file that you received. With a node locked license, you can invoke unlimited number of 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 was generated. The license server can be started by any user, but it is preferable that the super user 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 the distribution. Port number can be any free port. Note that only one instance of the license server can be invoked at a time on a given machine. The process runs in the background c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
14
Setting up AnXplorer
(there is no need to invoke it in the background) and if required, call be stopped using the kill command. To run AnXplorer (on any host), set the environment variable AGO LICENSE FILE (in the setup.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 with port 8080, then add the following line to the setup file: setenv AGO_LICENSE_FILE 8080@192.168.1.4 Depending on the license, a fixed number of instances of AnXplorer can co-exist at the same time 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 is checked out only when the user performs circuit optimization. Thus, even if a license is not available, the GUI can be used to setup the optimization inputs and also view the outputs of an earlier optimization run.
Querying the license status The AnXplorer distribution also comes bundled with an executable called xlstat which can be 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 which the license was generated, and the date till which it remains valid. For floating licenses, you can 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 be set appropriately before invoking xlstat. If it is not set, you can still query the license using the following options. To query a node locked license, use: % xlstat -f <license file name>. To query a floating license, use: c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
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 support this. If Bash or Ksh is used, the user needs to translate this file into an equivalent Bash or Ksh 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 other version.
c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
CHAPTER
3
Using AnXplorer in standalone graphical mode
This chapter describes the usage of AnXplorer from its graphical user interface (GUI) in the â&#x20AC;&#x153;stand aloneâ&#x20AC;? mode, i.e. the GUI needs to be invoked from a command prompt. The GUI can be used to setup the inputs to AnXplorer, running it for global optimization and local design centering, viewing the optimum design points found, and also to run queries on the exploration database. However, the netlists of the circuit being optimized (including the test benches) cannot be prepared from within the GUI. This mode of operation is suitable for usage with external simulators other than Cadence Spectre[4], or for usage with the Cadence Virtuoso environment version 5.x. For easier usage with 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 and tunability. 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 special name, which contains all inputs and outputs of AnXplorer. The inputs to AnXplorer (as specified in the GUI), must be saved as a project before running optimization. A project has a 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 be changed. Project directories can be located anywhere. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Inputs to AnXplorer
17
Note: contents of a project directory, or the directory name, should not be manually altered. This may lead to incorrect functioning of the tool. A more detailed description of the 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 main GUI 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 buttons to 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 corresponding page of the GUI. There are seven tabs. The first five are used for setting up the inputs to AnXplorer. These tabs are: variable definition, options definition, technology specific parameter definition, target and analysis definition, and target priority assignment. We recommend that the inputs should be filled up in this order. The last two tabs are used for viewing the results of AnXplorer. These are: the output log display tab, and the exploration database query tab. The menu-bar consists of three menus: The “File” menu, the ”Optimization” menu and the “Help” menu. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
18
Using AnXplorer in standalone graphical mode
Figure 3.1: The main window of the GUI
Figure 3.2: Project selection dialog box
The â&#x20AC;&#x153;Fileâ&#x20AC;? menu can be used to perform common tasks related to creating, opening, or saving projects. The menu contains the following functions: c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
The main GUI window
19
• New project (keyboard shortcut: Ctrl+N): Creates a new project. If a project is already opened when this function is invoked, the tool will prompt the user to save the existing project before creating the new one. • Open project (keyboard shortcut: Ctrl+O): Opens an existing project. Here too, if a project is already opened, the user will be prompted to save the current project before opening the new one. The new project is selected by a special file selection dialog box as shown in figure 3.2. The list on the left displays all directories except the project directories. 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 normal way, i.e. by double clicking on the directory names on the left. Double clicking on a project name selects it. • Save (keyboard shortcut: Ctrl+S): Saves the contents of a project. If the project name has not been specified yet, it prompts the user for a name using the project selection dialog box. • Save as (keyboard shortcut: Ctrl+A): Saves the project with a different name. All information in the existing project is copied into the new project. If the project name has not been specified, this function is identical to the plain Save function. • Revert to saved (keyboard shortcut: Ctrl+R): Provides an “undo” function. The inputs are taken back to the last saved state. Any changes made after the last save operation are lost. • Revert var ranges (keyboard shortcut: Ctrl+V): The ranges of the design variables are updated after running the “feasibility analysis” for a project (feasibility analysis is described in detail later in the text – please see section 3.9.2). This allows the user to revert back to the original (user-defined) ranges for the design variables. • Quit (keyboard shortcut: Ctrl+Q): Quits the application. The user is always prompted for 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 see the section on “Running AnXplorer in this chapter for more details on running the tool in different modes. The menu consists of the following items: • Run test simulation (keyboard shortcut: Ctrl+E): Runs a test simulation with a randomly created design point. The purpose is to validate whether all simulations and other options have been setup correctly (described in section 3.9.1). c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
20
Using AnXplorer in standalone graphical mode
• Run feasibility (keyboard shortcut: Ctrl+F): Runs AnXplorer in the feasibility analysis mode (described in section 3.9.2). • Run global (keyboard shortcut: Ctrl+G): Runs AnXplorer in the global optimization mode (described in section 3.9.3). • Run centering (keyboard shortcut: Ctrl+D): Runs AnXplorer in the local design centering 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 porting mode (porting a design from one manufacturing process to another) around a user specified initial design point (described in section 3.9.7). • Stop (keyboard shortcut: Ctrl+C): Stops any existing optimization job. All background processes invoked by the tool are killed. • Create initial point (keyboard shortcut: Ctrl+P): Invokes the GUI for manually creating an initial design point for use in the design centering mode. • Import initial point (keyboard shortcut: Ctrl+W): Using this option, the user can import a SPICE input file from which the initial values of the design variables will be read 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 this menu option invokes a file selector window, using which the user can choose the file to be imported. • Manual tuning (keyboard shortcut: Ctrl+I): Invokes the GUI for manual tuning of the design (see section 3.9.8). • Load feasibility log (keyboard shortcut: Ctrl+K): Loads the output log of AnXplorer feasibility analysis for the current project, if it is present. The “Log” page of the GUI is automatically opened. See more details about output logs in the section on “Running AnXplorer ”. • Load global log (keyboard shortcut: Ctrl+L): Loads the output log of AnXplorer global optimization for the current project, if it is present. The local optimas found are reported. • Load centering log (keyboard shortcut: Ctrl+J): The log file of the design centering process is loaded into the Log page of the GUI. • Load porting log (keyboard shortcut: Ctrl+U): The log file of the design porting process is loaded into the Log page of the GUI. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
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 environment variable 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 the PDF 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 over a widget – which is turned on by default. Most widgets in the GUI have a help message associated with it. The tool bar consists of buttons for performing the most common tasks, namely – Running 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 balloon help 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 in order 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 these quantities 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 view of a cell in the Cadence design environment. The user has to manually enter the variable names. This facility will be added later. A variable has a range, defined by its minimum and maximum values. During optimization, the variable will be assigned a value within this range. A variable value also has a granularity, 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 coarser but faster search to quickly arrive at a few nominal feasible design points (a design point is a set of values for the optimization variables) which satisfy the design objectives. During local design centering, the granularity is automatically reduced by a factor of 10, so as to enable a finer search. The GUI for defining variables is displayed when the user clicks on the “Variable” tab of the main window. The window is shown in figure 3.3. On the right are entries for entering c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
22
Using AnXplorer in standalone graphical mode
Figure 3.3: Variable definition GUI
the name, minimum value, maximum value and granularity of the variable. Note: these are mandatory 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, underscore or digits. No other characters are allowed in the variable name. The minimum, maximum values and granularity should be numeric values – either integers, e.g. 123, or floating point numbers, e.g. 1.23, real numbers using the scientific notation, e.g. 1.2e-03, or numbers scaled with a alphabetic suffix, e.g. 1.2m, as is commonly used in Spice input decks. The tool will check the format of the name and the numbers, and report an error if necessary. The meaning of 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 only integral values. For example, if the number of fingers of a MOS transistor is denoted by a variable, then it must be an integer. To make a variable an integer, select the checkbutton below the entries in the GUI. Once all entries are filled up, click on the button labeled “OK” in the box of buttons above the entries. This creates the variable. Names of variables already defined are displayed in the list on the left. Clicking on an entry in the list displays the variable values in the entries. The user can move up or down the 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, display it by clicking on its name in the list, modify the values and then click on the “OK” button. If the name of the variable was modified, then a new variable with the modified name is created. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Options definition
23
Scaling alphabet(s) t,T g,G M,x,X k,K m u,U n,N p,P f,F a,A
Scaling factor 1012 109 106 103 10−3 10−6 10−9 10−12 10−15 10−18
Table 3.1: Table showing the mapping of the scaling alphabets to the corresponding scaling factors.
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-dimensional space. The “size” of this region grows exponentially with the number of variables as well as the range of the variables. The user is thus advised to choose the range of the variables judiciously. For a variable denoting a geometrical quantity, an obvious choice for the minimum and maximum values are the minimum and maximum dimensions supported by the fabrication technology. 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 transistor should be large. Thus, the minimum value for the variable denoting the width of this transistor should also be reasonably large. Such judicious choice of variable ranges by a knowledgeable designer 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 for definining several options to the optimizer. It is shown in figure 3.4. Each of the options are discussed 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 c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
24
Using AnXplorer in standalone graphical mode
Figure 3.4: The options definition GUI
and (8) dspice. There are two options for using Eldo: with or without the -compat command line argument. Further, for Finesim as well, there are two options – running with Spice format inputs 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 being used (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 dspice is 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) is being 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 in the 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) or the output file (e.g. -o or =log). AnXplorer will always supply these options when invoking 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 the input and output file specification options. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Options definition
25
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 desired output 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 -compat option 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 the Eldo 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 the optimizer can vastly improve its performance. Even on a single CPU machine, multi-threading improves performance because it leads to better utilization of CPU time. To enable multithreading, select the check-button labeled “No. of threads” and enter the desired number of threads (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 of threads 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, AnXplorer runs till either all objectives have been completely satisfied, or a given maximum number 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. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
26
Using AnXplorer in standalone graphical mode
• The drop down list at the top of this section is used to specify the fraction of objectives that 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 an objective has been satisfied. The default is that the objective should be fully met. This means that for an objective which is to be maximized, the optimized value should be greater than the target. Similarly, for an objective to be minimized, the optimized value should be less than the target, for it to be considered as “satisfied”. This default criterion can be changed. The user can specify that when an optimized value is within a certain range of its objective, it can be taken to be met. This range is specified in terms of a percentage of the target value. The user can select this percentage from the drop 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 porting optimization (see section 3.9). They are not used in the feasibility analysis mode, as the purpose of feasibility analysis is to explore the design space, and not converge to a optimized solution. The number of iterations for which the optimizer will search for solutions in the global optimization 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 used only in the feasibility analysis and global optimization modes. Finally, if the user wants to continue the optimization process even when the stopping criteria are met, please select the check button labeled “Continue optimization ...”. If this is selected, the stopping criteria would be as follows: • In global optimization and feasibility analysis modes, the optimizer will run for the specified number of iterations. If the number of iterations is not specified, it defaults to 60. • In design centering and porting optimization modes, if the difference in performance between any two successive iterations is less than 0.2%, or the position of the optimized design 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 it meets all objectives across all the PVT corners defined. In this phase, each design point is evaluated 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 c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Options definition
27
runs an exhaustive check at the beginning of the design centering phase and finds out which corners 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 centering with all corners. To run with only the violating corners, select the option “only corners which violate optimization criteria” from the dropdown menu. This is selected by default. To run with all corners, select the option “all corners”. At the end of centering, AnXplorer can also run a senstivity analysis which reports by how much each objective varies across all corners for a slight perturbation in the value of each variable. This can be turned on by selecting the corresponding check button. It is turned off by default.
Setting the granularity reduction factor During the design centering phase, the granularity, or step size of each variable is reduced by a factor of 10 by default. This is to enable a fine grained search around the initial design point. This factor can be controlled. The user can enter the reduction factor in the entry field labeled “Reduce variable step size by this factor for design centering:”. A value of 1 will mean that the variable step sizes are not reduced – they will be used as is in the design centering 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 of iterations. However, this algorithm can get stuck in local optima and fail to reach the optimum solution in some rare corner cases. 2. A slow and robust algorithm. This may take a few iterations longer to reach the optimal solution, 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 check button labeled “Use fast algorithm for global optimization”. The recommended flow is to use the fast algorithm first, and then use the slower algorithm only if the first attempt fails to yield satisfactory results. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
28
3.5.7
Using AnXplorer in standalone graphical mode
Logarithmic partitioning
This option needs some elaboration. Suppose there are n design variables which the optimizer can 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 determined internally). This gives rise to k n sub-regions of the design space. The optimizer tries to sample 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 partitioning strategy. 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 for variables”. For larger design spaces, logarithmic partitioning can vastly improve the speed of convergence. However, for reasonably sized design spaces logarithmic partitioning may not yield any siginificant improvement. The user is advised to first try the optimization without this flag. 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 of design variable values. All three are optional. Corners are used during the design centering process, where AnXplorer aims to ensure that all design objectives are met across all the user defined 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 temperature values, and a set of voltage variable values. AnXplorer used all permutations of these values as separate corners. However, this led to the creation of some corners which were not useful or realistic (for example, a “fast” model library with a high temperature). From the 2011.11 release onwards, this has been changed to explicit user defined corners. This change is fully backward compatible. Projects created using older versions will be automatically converted into this new scheme - with a set of corners appearing in the GUI. The user can choose to omit the invalid corners. To add a corner, click on the button labeled “Add”. The GUI, as shown in figure 3.5 pops up. 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 these are optional, and the entries are to be enabled by clicking on the check button next to each c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Options definition
29
entry. A file browser (invoked by clicking on the button labeled “...”) can be used to select the model file. Note that multiple model corners can be specified in the entry field for the model corner, separated by spaces. This will create multiple model file inclusion statements in 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 representing the supply voltage). The variable name and value are to be entered in the corresponding entries, and then click on the button labeled “Add”. The variable will appear in the list box below. 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 is that all user defined corners must have the same variables. To finalize the corner definition, click on the button labeled “Add corner” at the bottom of the GUI. This window can be closed by clicking on the button labeled “Done”. To navigate between the user defined corners, use the buttons “¡¡” and ”¿¿”. The corner names also appear 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 the user 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 it need not be explicitly defined. AnXplorer will simply pick up whatever is specified in the c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
30
Using AnXplorer in standalone graphical mode
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 rule evaluation. Thus, we discuss the concept of sizing rules first, before describing the operation of the GUI. Sizing rules are a set of rules aimed at making the DC operating condition of a circuit inherently stable and insensitive to variation in process and environment. Currently, these rules are supported only for MOS transistor based designs. It will be extended for other devices, e.g. BJTs, later. AnXplorer reads the circuit netlist and automatically recognizes transistors which are meant to be in saturation and tries to ensure that these transistors are deep 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-blocks of analog circuits, like current mirrors (several types of current mirrors), banks of current mirrors, differential pairs, level shifters, etc., and tries to ensure certain conditions that these sub-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 if she specifies the constraints on the devices herself (this can be done in the operating point analysis, 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 (saturation region), or voltage controlled resistor (triode region). This acts as the basis for all other building blocks. Rules applied to voltage controlled current source: • VDS should be greater than (VGS − VT H ) of the transistor by a specified margin (Here, VDS stands for drain-to-source voltage, VGS stands for gate-to-source voltage, and VT H stands for threshold voltage of a MOS transistor). • VGS − VT H should be greater than a specified threshold. Rules applied to voltage controlled resistors are: • VDS should be less than (VGS − VT H ) of the transistor by a specified margin c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Technology specific parameter definition
31
• VGS − VT H 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-defined threshold. 2. Simple current mirror, with both transistors in saturation. Represented as MOSCM 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 current mirror should be less than a user-specified threshold. 3. Simple differential pair, both transistors in saturation. Represented as MOS-DP in output. The rules applied are the same as those on the constituent transistors, which are 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 in output. 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) is in triode, while the top one is in saturation (for NMOS structures. PMOS structure would be exactly opposite). Represented as MOS-VR in output. The rules for saturated 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 triode transistor at the bottom (connected to the ground rail), and a saturated transistor above 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 current mirror. Represented as MOS-CCM in output. Rules for level shifter and current mirror are applied. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
32
Using AnXplorer in standalone graphical mode
The output of AnXplorer also indicates which transistors comprise each structure. The above descriptions are for NMOS structures. PMOS structures are just opposite. They are also recognized 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)
Differential pair Simple current mirror
Voltage controlled current source or voltage controlled resistor
Voltage reference
Current mirror load Level shifter
Cascode current mirror
Current mirror bank
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 parameters, which are specific to a technology: 1. The names of the NMOS and PMOS transistor models. These are used to identify the N and P transistors from the netlist. Several model names for the same transistor type (N or P) can be specified. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Technology specific parameter definition
33
2. For transistors in saturation, the minimum difference (which makes the transistor safely in saturation) between the drain-to-source voltage (VDS ) and the overdrive. The overdrive is the difference between gate-to-source voltage (VGS ) and threshold voltage (VT H ) of the transistor. Thus, the tool tries to ensure that VDS > VGS − VT H + v1 for all transistors 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, but here, the tool tries to ensure that VDS < VGS − VT H − v2 . Here, v2 is the user defined safety limit for transistors in the triode region. 4. The minimum overdrive for a conducting transistor (VGS −VT H ) 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, has to be specified. 6. For two transistors in a current mirror, the maximum allowable difference between the VDS of the two transistors has to be specified. This is to ensure that VDS difference does 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 sizing rule evaluation, select the check button labeled “Enable automatic sizing rule evaluation” at the 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 c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
34
Using AnXplorer in standalone graphical mode
an existing project by clicking on the button labeled “Import technology parameters from a different project”. A selection dialog for selecting the other project pops up. Select a project in this box. The technology parameters of this project, if any are defined, will appear in the GUI. Otherwise, a message will be shown, stating that no parameters are defined for the other project. The model names for the NMOS and PMOS transistors have to be entered in the two entry fields. 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 transistors in 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 netlist model 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 to extract these objective values. There are three types of analyses: 1. Special simulation based analyses with built-in intelligence about performance objectives. 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 the given circuit such that these objective values are met (or exceeded). There is a penalty for not meeting 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. For example, the penalty for achieving 20% less gain is substantially bigger than the reward for achieving 20% more gain. In the course of optimization, AnXplorer evaluates several candidate circuits. Each objective is assigned a raw score depending on the target value. The total score of a candidate circuit is a combination of the raw scores. A lower total score indicates a better solution. Suppose an objective is to be minimized below a target value t. The evaluated value for this objective in a candidate circuit is, say, v. Then the raw score of this objective is calculated 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 c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Analysis and target definition
35
value of 2 (nowhere near the target), and a minimum value of 0 (vastly over-achieved). A value 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 the number 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 target ensures that the reward for over achieving a target is significantly less than the penalty for under achieving the target by the same amount. Since the final score is a sum of individual objective scores, this parameter also ensures that several over achieved objectives do not overshadow 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, three types of analyses are supported in the GUI: • Operating point analysis for measuring current consumption, node voltages, sizing rules 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, as well as the contribution of individual devices to the total noise (both thermal noise and flicker noise). • Function based analysis for measuring objectives defined by simulator post-processing commands. • 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 appropriate radio button in the main GUI. Each analysis has a name which must be an identifier. This has to be entered in the entry field at the top of the GUI. An analysis also must have a test bench associated with c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
36
Using AnXplorer in standalone graphical mode
it. This is specified by selecting the top radio button and entering the file name in the entry labeled “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 Spectre format inputs) is being used as the external simulator, then an OCEAN script, with the same name 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 the location of the mapping directory, or "amap" directory in the text entry box labeled “amap directory”. 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 be simulation/<cell name>/spectre/schematic/netlist/amap. To select a mapping directory, clicked on the button labeled “...”, and a file selection dialog box pops up. This is different from a “normal” file selection dialog in that it displays only directory names both in the left side and the right side scrolled lists. To traverse directories, use the list on the left side. 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 ADE and 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 editor “File” menu, choose “Save as” to save the netlist in your work area. The extension of the file name should be .scs. To create the OCEAN script, choose the option “Save script” from the “Session” menu in Analog Artist, and then save the script with the same name prefix as the Spectre netlist, and the extension .ocn. For example, if your Spectre netlist 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 one analysis 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 the above two need to be selected. Once an analysis is defined, click on the “OK” button. The list on the left of the GUI displays the names of the analyses defined so far. Selecting a name in the list brings up the GUI 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.
c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Analysis and target definition
3.7.1
37
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 regions which yield a feasible design. By the term feasible design we mean a candidate design which meets a subset of objectives. By default, all implicit sizing rules (if enabled), all explicit constraints on MOS transistor operating conditions (section 3.7.3), and all user defined equation based targets (section 3.7.8) are included in the feasibility analysis mode. A design point is termed feasible if all these objectives are satisfied. In addition to these default objectives, the user can choose to include any arbitrary analyses 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 time to simulate, e.g. AC analyses) in the feasibility mode has a definite advantage. It cuts down the design space, so that the global optimization mode converges faster. However, it is not advisable to include analyses which have long simulation times in the feasibility analysis mode. The time advantage gained in the global optimization, by cutting down the design space size, will be lost if a lot of time is spent in the feasibility analysis mode running the long 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 where only 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 temperature substitution in the netlist file for this analysis. Thus, it is expected that the netlist for the analysis, in this case, should be “self contained”. In case of design centering, this analysis will be evaluated only once for every design point, and the normal performance at 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 corners will be used for this analysis. If there N corners, in the design centering mode, this analysis will be evaluated N times, each time in a different corner, and the worst case performance of each objective across these N runs will be taken as the performance of c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
38
Using AnXplorer in standalone graphical mode
the circuit. In case of feasibility analysis and global optimization, the analysis will be evaluated with the first design corner defined by the user in the list of corners specified in the options definition page. The order of the corners can be changed by using the buttons labeled “Move up” and “Move down” in the options definition page. • Selected corners: Here, as the name suggests, instead of all corners, only the selected corners will be used to find the worst case performance of this analysis. In the feasibility analysis and global optimization modes, the first corner in the list of selected corners will 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 list and 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 the relative error between the expected voltage and the actual (simulated) voltage below a given relative tolerance. 2. Expected current consumption from a voltage source. Here, the objective is to reduce the current consumption below the specified value. 3. Implicit sizing rules are evaluated. These rules impose constraints on the biasing condition 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 circuit such that all these rules are met. 4. Biasing constraints on individual MOS transistors. The user can choose to increase or decrease the difference between the VDS and Vdsat of a transistor. She can also choose to increase or decrease the overdrive (i.e. the difference between VGS and VT H ) of a transistor. All the above measurements are optional. The user can choose any number of measurements to perform. The GUI for defining an operating point analysis is shown in figure 3.9. It can be invoked by clicking on the radio button labeled “Operating point” in the main analysis GUI. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Analysis and target definition
39
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 be evaluated. The CDL netlist is parsed by the tool to gather information about the connectivity of the devices and also the hierarchical device names, which is required for evaluating the sizing rules. Since the tool is not directly integrated with the Cadence environment yet, it cannot read this information from the design database. A CDL netlist is easy to parse and hence used here. This requirement will be removed in future. To specify the CDL netlist file, select the check-button labeled “CDL file” and enter the file name in the entry next to it. The button on the right of the entry can be used to pop up a file selection dialog.
Defining current consumption limit AnXplorer can limit the current consumption from one voltage source in the design below a specified value. To enable this option, enter the name of the voltage source in the entry labeled “Power supply name” and the limiting value (in amperes) in the entry below it (labeled “Current consumption”). c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
40
Using AnXplorer in standalone graphical mode
The name of the voltage source must be hierarchical. Normally, a hierarchical name is expressed in the form I0.I1.vsource where vsource is the actual device name, and I0 and I1 are the names of the containing subcircuit instances. Alternatively, the name can also be expressed 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 to a different format by the tool, which will be displayed in the name entry once the analysis is saved (by clicking the “OK” button). The formatted name will look different from the original 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 it in 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 allowable relative error between the target voltage and the actual calculated voltage. AnXplorer will try to bring the actual voltage to within X% of the target value, where X is the specified relative 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 the original.
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 set two different constraints on the biasing of individual MOS transistors in the circuit. These are: • Constraint on the overdrive of a transistor, i.e. the difference between the gate-to-source voltage (VGS ) and the threshold voltage (VT H ). For this transistor, this difference can be 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 the minimum 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 in saturation, this difference must be positive, whereas it should be negative for transistors c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Analysis and target definition
41
in the linear region. This difference can be constrained to be either greater than, or less than, a specified target.
To constrain the VGS − VT H 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 the option “Vgs - Vth”. Choose the type of constraint (greater than, or less than) in the menu below it. Finally, enter the target value (in volts) in the entry labeled “Voltage (V)” and click on the “Add” button next to it. The constraint will 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. 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 the name box, or select transistors by using the transistor browser GUI. The browser GUI can be invoked by clicking on the “Browse” button on the right side. This pops up a window which is shown in figure 3.10. The list box on the left side of the window shows all subcircuit instances defined in the design, showing their hierarchical names, and grouping them together by hierarchy. In addition, there is a special entry called ##all##. Clicking on any entry on the 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 up in 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 individual transistors). Once selected, the constraints on the transistors can be set by using the voltage option, 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 transistor browser 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 note that the transistor names should be as they appear in the CDL netlist. For example, even if the name of a transistor is, say, M1 in the schematic view, but it appears as MM1 in the CDL file, it should be entered as MM1 in the name entry. Note: For P transistors, VT H , Vdsat , VGS and VDS are negative. For a saturated transistor, both VGS − VT H 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 these quantities while specifying these constraints. Thus, for any transitor supposed to be in saturation, whether N or P, the targets for both these quantities should be greater than a positive c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
42
Using AnXplorer in standalone graphical mode
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 constraints can be disabled by selecting an option in the technology specific parameters page (discussed earlier). Alternatively, the user can disable only the implicit sizing rule evaluation by explicitly ignoring the sizing rule target in the target priority assignment (cost graph) page (discussed later).
3.7.4
Noise analysis
The noise analysis option is currently available only if Hspice is being used as the external simulator. 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 analysis can 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 of a circuit at a user specified frequency. In addition, it also calculates the thermal noise, flicker noise, and total noise for individual devices at that frequency. For user specified devices, it tries to reduce the percentage contribution of any of these types of noise to the total noise of the circuit below a specified value. The user needs to enter the frequency of measurement (in Hz) in the entry field at the top of the GUI. The total input referred noise voltage target has to be entered in the entry below it. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Analysis and target definition
43
To specify constraints on the noise contribution of individual devices, enter the device name (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 contribution target in the entry field below it. Then, click on the “Add” button next to it. The constraint will 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 of the simulator being used. These can be .measure statements in Hspice (or SmartSpice or Msim or Eldo), or general calculator functions using the Cadence waveform calculator. For any simulation, an arbitrary number of such measures can be used as targets. The only constraint is that the output of such a measure must be a numerical value, i.e. it cannot be a waveform. Each measurement must have a name, which can be any arbitrary string without any 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 must specify the type of the underlying simulation, i.e. either transient, AC sweep, DC sweep or Monte Carlo (the last one is described in the next section) by selecting the appropriate radio c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
44
Using AnXplorer in standalone graphical mode
Figure 3.12: GUI for defining function based analysis
button in the section of the GUI labeled “Analysis Type”. The name of the target needs to 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 entry below 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 of a calculator function. There is no way to define the expression in the AnXplorer GUI. Also note 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 such targets can be added. To make a target equal to a given value, specify two constraints with the same name – one less than, and the other greater than, to the desired value. To delete a target, 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 the user defined functions. However, the user can choose to use her own postprocessing program or script for this purpose. This program can be written in any language - scripting or compiled. It can be invoked either 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 c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Analysis and target definition
45
This command can be specified by clicking on the check button labeled “Custom postprocessor 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 to ensure that the script functions properly on the simulator text output. • The script should take four arguments as follows (all file and directory names are specified 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 text output of OCEAN. 4. The output file for the postprocessing program. The program should write its output 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 values contained in the file. • Each subsequent line should contain the name and value of one function in the form:name value. • Functions which did not evaluate properly (i.e. the simulator could not calculate its value) should be given a value of 2e+200. This custom program can internally invoke the in-built post processing programs of AnXplorer. These programs are as follows:
Simulator
Script name
Invoked as
Eldo Hspice
el process hsp process
Spectre Msim Finesim (spice input)
spec process msim process finesim process
el process inputfile "extract" output hsp process input "meas ac" output hsp process input "meas dc" output hsp process input "meas tran" output spec process "meas ocn" input output msim process input "meas" output finesim process spice input "meas" output
c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
46
Using AnXplorer in standalone graphical mode
A small sample of Perl code is given below as an example of how to use the in-built post-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 normal AC, DC or TRAN simulation, the user specifies the netlist of a Monte Carlo simulation. This is supported only when using Spectre as the underlying simulator. To use this mode, select the radio button labeled “Monte Carlo” in the “Analysis Type” section of the GUI. AnXplorer uses the netlist specified to run a 20-simulation Monte Carlo analysis for every design point that is evaluated. The mean µ and standard deviation σ of each quantity being measured is c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Analysis and target definition
47
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 based analyses, as defined in section 3.12. If the upper limit of a target is specified, AnXplorer tries to ensure that the maximum value of the target is less than the limit. Similarly, if the lower limit 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 function. A very common application of this is the circuit area optimization. The user can create an 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 performance parameter, if it can be expressed as a function of the variables, can be optimized using this analysis.
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 entered in the text entry box, one per line. The left hand side of the equation should use only the variables and any previously defined target as the unknowns. The right hand side is the target name. The function is to be defined as a standard expression as in the C programming language. All C standard library mathematical functions are available. An example equation is given below: c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
48
Using AnXplorer in standalone graphical mode
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. Select the direction (greater than or less than), and then enter the target value in the lower entry field. Clicking on the button labeled “Add” will add this target to the list. The GUI for creating 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 acyclic graph 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 difficult to achieve, should be placed at the top of the graph. We term this graph as the cost graph of the objectives. Ordering objectives simply according to their importance or difficulty simplifies the optimization objective function definition. There is no need to explicitly specified “weights” for each 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 power consumption. The DC gain of the amplifier comes next. The phase margin, positions of the second dominant pole and the zero (if present) have the same priority, each less than the priority of the DC gain. Finally, the unity gain bandwidth has the least priority. An edge in the cost graph denotes a priority assignment, with the target at the tail of the edge having more 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 level consists of one or more optimization targets or constraints. The levels are placed one on top of the other, in a linear list. Each target comprising a given level “dominates” each target in the level below it. This means that an edge is added (automatically) between each target in one level and each target in the level below. As an example, the level-wise specification of the cost graph for the operational amplifier will be as follows: c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
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. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
50
Using AnXplorer in standalone graphical mode
• 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 the GUI initially shows all the defined targets and constraints, and at any point of time, shows the 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 after defining the targets. Please click on the button labeled “Refresh target list” at the bottom of 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 objectives in each of them. To create a level, click on the button labeled “Add” below this list box. A dialog window, as shown in figure 3.16 pops up. This window consists of two lists. The one on the left shows the targets which are yet to be assigned to any level (if all targets have been 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 in the list on the left, and click on the button labeled ‘-->’. Double-clicking on the target name also has the same effect. Similarly, to remove a target from this level, select it in the list on the right and click the button labeled ‘<--’ (or double click on the name). Once done, click on 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”, or double click on the level in the list. The GUI for editing is the same as that for adding a level. Objectives which are removed from the level, will reappear in the box for unassigned targets on the left of the GUI. To delete a level, select it in the list and click on the button labeled “Delete”. A dialog will pop-up, asking the user to confirm the deletion. Once deleted, the objectives in a level c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Running AnXplorer
51
show up in the list for unassigned targets. Also, if there were levels below the level just deleted, 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 buttons labeled “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 with probability 0.6 after each local optimum found by the optimizer. This can help in achieving all the optimization targets. This is also useful when the user is not entirely sure about the relative importance of the objectives. However, if the user does not want to modify the cost graph, she can disable this feature by selecting the check-button labeled “Disable cost graph rearrangement after each optima” at the top of the GUI. In the latest version of AnXplorer this 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 (a set of edges) exists from p to c, then p is termed an ancestor or c, and c is a descendant of p. Let r be the raw score of an objective and let r0 be the maximum raw score of any ancestor of the objective in the graph. If r0 < 1, then r0 is set to 1. The prioritized score of the current objective is given by s = r · r0 . Thus, if any objective more important than the current objective is underachieved (i.e. its raw score is greater than 1), then the prioritized score of the current objective increases. The total score of the design point is the sum of the prioritized 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 optimization variables, 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 single process, voltage and temperature corner is used. The first model file, first temperature value and first voltage value (if specified) are used. It is recommended to have a larger c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
52
Using AnXplorer in standalone graphical mode
granularity for the variables as it speeds up the search process. The search continues for the number of iterations specified in the options definition page (default is 150). The output of this mode is a “volume” of the design space – represented by ranges of the design variables – which is termed as the “feasible design space”. All (or most) design points within this space are expected to be “feasible”. This truncated design space should be used as input to the global and centering optimization runs. • Global optimization: In this mode, AnXplorer searches the design space (either the truncated design space as found by feasibility analysis, or the entire design space, as chosen by the user) for suitable design points which satisfy all the user defined design objectives (targets). Several locally optimal points are reported. In this mode, too, only a single process, voltage and temperature corner is used. Here too, it is recommended to 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 is to find design points which satisfy the design objectives across all process, voltage and temperature corners specified by the user. The optimization continues till no further improvement is found locally. The tool reports the worst case objective values (discussed in more detail later) as well as the values for each corner. • Design porting: This can be used to port a design from one manufacturing process to another manufacturing process with similar characteristics (for example, porting a design from a TSMC 180nm process to an IBM 180nm process). The process starts, as in the case of design centering, with an user defined initial design point (which is the position 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 an optimized design in the new process. However, unlike the design centering mode, the optimization is done using only one nominal process, voltage and temperature corner. Optimization continues till no further improvement is found locally. The tool reports the ported design point, which can then be subjected to further design centering across corners. 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 evaluates the 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, to ensure that all simulator inputs and other optimizer options have been setup correctly. To c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Running AnXplorer
53
run a test simulation, click on the button labeled “Run test simulation” in the main tool bar, or select the option from the “Optimization” menu. If an initial design point (used for porting optimization and design centering) exists in the project, that design point will be used. Otherwise, the tool will create a random design point within the design space. All user specified analyses will be run at this design point. If multiple corners are defined, the first corner 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 at the 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 . This may or may not be an error. For example, if the DC gain of an amplifier at a random design point is less than 0 dB, then the phase margin and bandwidth cannot be calculated. This is not 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 an error status, the post-processing functions could not run properly. The user needs to debug the 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 DC operating points should be stable, and as immune to variations in process/temperature/etc. as possible. This means that all implict and explicit sizing rules must be met for a design point to be termed as a “feasible design point”. The design space specified by the user usually has large regions where these constraints are not met, and thus there is no use of running further simulations at such points. Further, all user defined equation based objectives are also evaluated in the feasibility analysis mode. For circuit optimization, the equation based objectives most often relate to a measure of the area of the die. Evaluating these in the feasibility analysis mode ensures that we cut down the design space to only those regions which satisfy these area measures. Since these objectives are cheap to evaluate (since they do not involve running a simulation), they add little extra overhead to the optimization process. Finally, any other objective that the user specifies to be included in the feasibility analysis mode, will also be evaluated. The process of including an objective in the feasibility analysis mode is described in section 3.7.1. In this mode, the tool is presented with a set of design variables with defined ranges (in c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
54
Using AnXplorer in standalone graphical mode
the variables definition page), a set of options (in the options page) and a set of analyses that should be run (in the analysis definition page). AnXplorer finds regions of the design space where all sizing rules are met. It runs only the operating point simulations (more than one may be used), and evaluates only the sizing rule objectives and the user defined equation based objectives. The other objectives and simulations are ignored. The cost graph specified for global/centering optimization is also not used. A special cost graph is constructed, which places all the equation based objectives at the highest level. All sizing rule objectives are placed in the next level and treated with equal importance. Further, the results of evaluation of all sizing rules are reported in detail to the user. AnXplorer finds the “volume” within the design space where all equation based objectives, implicit and explicit sizing constraints are met. It reports this “volume” as truncated ranges of the design variables. These truncated ranges 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 rise to oversized circuits. When global optimization is run, we do not waste time evaluating points within such regions. 2. The “feasible volume” identified by the tool is expected to be smooth in nature, with only a few optimas lying within. 3. Since it runs only the DC operating point simulations and the computationally cheap equation based objective evaluations, it takes considerably lesser time than the more expensive transient and other such simulations. The other simulations are run during global optimization, but the design space is vastly truncated (after the feasibility analysis), thus resulting in a faster optimization time. To run feasibility analysis, either click on the button labeled “Run feasibility” in the tool 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 or centering optimization) the tool performs a sanity check on the input and reports any error, if present. 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 (check the PATH variable). • The simulator returns an error. This is possible if all variables in the design are not defined in AnXplorer, or there is some error in the simulation setup, or simply if the simulator fails to converge. The error is reported in a pop-up window and simulation input and error log files are indicated, which the user can browse to rectify the problem. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Running AnXplorer
55
• The output post-processor returns an error. This can happen if all defined objectives are not found in the simulator output (maybe a missing measure statement in the test bench?). 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 log page, as shown in figure 3.17 displays the following: • The output of AnXplorer as it appears on the standard output when run in command line mode. This contains some informative messages, like the list of design variables used, a summary of options, a summary of the defined targets, and a textual description of the cost graph. As each locally optimum point is found, the position of the design point (i.e. the values of the design variables) and a textual description of the target values 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 for details 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 each line containing a variable name and its value. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
56
Using AnXplorer in standalone graphical mode
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 objectives. A “local optimum” design point is reported when a point is found whose performance cannot be improved upon by tweaking the variable values within a specified limit. After each local optimum is found, it is reported by the tool. The tool then proceeds to search hitherto unvisited regions of the design space. The locally optimum design points found by AnXplorer are shown in the lower part of the GUI, as can be seen in figure 3.18. These are not used during feasibility analysis, but are useful in case of the subsequent global optimization, to select an initial design point for centering optimization. The list on the left shows the index numbers of the optima found. Selecting an entry in this list shows the score and performance of the circuit at this optima, and also the position of the optima. The “File” and “Optimization” menus will be disabled during optimization. Also all buttons 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 number of 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 feasible design space is shown in the main log window. To update the range of the design variables c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Running AnXplorer
57
with the truncated range, click on the button labeled “Update variable ranges with feasible range” at the bottom of the log page. This will alter the ranges of the design variables, and display 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 shortcut Ctrl+v). Note: If feasibility analysis has been run once and the variable ranges have been updated with the feasible range, then each time the same project is loaded after that, the variable definition page will always show the truncated variable ranges. This is even if the user reverts the variable ranges to the original values. However, choosing the “Revert var ranges” option will 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. This will remain in the disabled state while running any optimization other than feasibility analysis. • A button labeled “Create initial position file with this design point”. This will create an initial design point (which can be used for design centering or design porting) with the optimum selected in the list of optima values. This button will remain disabled while running feasibility analysis and centering optimization. • A button labeled “Export this design point”. Using this, the user can export the selected design point into a SPICE input file, as .param statements, which can then be included in a SPICE netlist file. Clicking on this will invoke a file selection dialog box, where the output file name can be selected. This should be used at the end of the optimization process (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 the variables definition page), a set of options (in the options page), and a set of design objectives and targets (in the analysis definition page) which the synthesized circuit should meet. This mode is useful to locate “promising” regions of the design space, which can be explored further in the design centering mode. It is also useful to quickly explore the feasibility and suitability of 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 of the GUI, as can be seen in figure 3.18. These optima can be used to create the initial design c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
58
Using AnXplorer in standalone graphical mode
point for design centering. To create the initial design with an optimum point, select it in the list, and click on the button labeled “Create initial position file with this optima” at the bottom of the GUI. Global optimization stops when all the stopping criteria (specified in the Options tab) are satisfied, 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 used for feasibility analysis and global optimization. If an analysis uses all corners, then the first corner in the Options page is selected. Otherwise, the first in the list of corners to be used for the analysis is selected. The input netlists are modified to use these values, removing any existing model file inclusion or temperature specification. Feasibility analysis and global optimization can also be run across several user defined corners. In this case, the user can create two or more analyses for the same test bench, using a different set of corners for each analysis. Thus, if the first corner in the list is different for these different analyses, a different corner will be used for each of them in the feasibility analysis 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 design can 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 initial point” 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 file already exists for this process, the user will be asked whether she wants to overwrite the existing file. In the pop up window, please enter the value of each variable at the initial design point. Note that the value must lie within the range of the corresponding variable, c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Running AnXplorer
59
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 the button 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. Please select 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 input file. This input file should contain the variable values as .param statements, in the following format: .param <variable name> = <variable value> All variables must be assigned to, and the value must be within the range of the respective variables. Other statements in the file are ignored. As a third alternative, the user can also create a text file defining the values for all the design variables. Each line of this file should define a variable using the .param statement format as shown above. Only one variable can be defined per line. Also, do not leave any blank 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 across all user defined corners. For an objective which is to be minimized, the maximum value across corners is the worst case. Similarly, for a maximization objective, the minimum value across corners is the worst case. Different objectives can have their worst case values for different corners. For example, one can expect the settling time of an operational amplifier to be worst in the “slow” process corner, whereas the static current consumption would be maximum in the “fast” corner. Thus, all reported worst case values may not correspond to the same c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
60
Using AnXplorer in standalone graphical mode
corner. The objective values for all corners are reported for the final (converged) design point in the log. Scroll down the text box to view it. Note that an analysis is evaluated in only those corners which have been selected during the definition of the analysis. For example, if an analysis is specified to use only two out of three 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 for only those corners where the objectives are not met. All corners for which objectives are not being met are reported in the log. As for other optimization modes, the top part of the GUI displays the log, the current iteration number, the worst case performance of the best design point and its position. The lower 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) are satisfied, or no improvement is possible over two successive iterations.
Sensitivity analysis report Once design centering finishes, AnXplorer produces a sensitivity analysis report. Each of the design variables are perturbed by Âą5%, one at a time, and the variation of the worst case value of each objective is recorded. A low variation in the objective values indicates a design point 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 design centering), a human intervention is required after each step. For example, after the feasibility analysis, the user needs to choose the update the design variable space. After global optimization, the user needs to choose a suitable initial position from the list of optima, of by querying the database (see section 3.10). However, AnXplorer provides a way to run these three steps automatically. We call this a â&#x20AC;&#x153;Workflowâ&#x20AC;?. Here, after feasibility analysis, the design variable ranges are automatically updated. After global optimization, the optima with the lowest score is selected to be the initial position for the design centering phase. The user needs to enter the number of iterations the tool should run in the feasibility analysis mode and global optimization mode. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Running AnXplorer
61
Figure 3.20: Pop up window to setup the automated workflow
To run an automated workflow, select the option “Create workflow ...” (keyboard shortcut Ctrl+X) from the “Optimization” menu. The window shown in figure 3.20 pops up. The user needs to enter the number of iterations for feasibility analysis and global optimization here. If any of these three steps need not be run, please uncheck the corresponding button. Clicking on the “OK” button will start the automated run. The “Log” page of the GUI will be brought to 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 process, and tries to tune the variable values so as to make it optimized for a different manufacturing process. The assumption here is that for two similar manufacturing processes, the optimal design points will not be too far from each other. To run porting, the user first needs to setup the optimization environment using the target manufacturing process. This means that the variable ranges, corner selection, technology specific parameters, testbench netlists etc., must be appropriate for the target manufacturing process. The next step is to create an initial design point which is the value of the optimized design point in the source manufacturing process. The initial design point can be either created 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 started by clicking on the button labeled “Run porting” at the top of the GUI. In this optimization mode, AnXplorer searches for an optimal design in a small design space around the initial design point. It uses the first user defined corner specified. Alternatively, one can use different c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
62
Using AnXplorer in standalone graphical mode
corners for the same analyses, using the method outlined in section 3.9.4. Like the design centering process, the optimization proceeds in iterations, and the best performance after each 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 sets the 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 main GUI (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 the available 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 design point file exists for this project, then the values of the design variables as in the initial design point 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 empty frame. To evalute the circuit for a given set of variable values and a given corner configuration, click on the bottom labeled “Evaluate point” at the bottom of the GUI. The circuit is evaluated and the results (values of the target objectives and the score) are displayed in the right pane. The GUI will be inactive while the evaluation is ongoing in the background. If c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Database query
63
the evaluation failed for some reason (e.g. simulator error), then the score and other outputs will 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 the corners and the worst case results are reported. Note that if an analysis does not use one or more of the corners, it will not be evaluated in those corners. Further, corners are not used in the case of user defined equation based objectives. The user can create an initial design point file from this GUI. Please click on the button labeled “Create initial point”. The values of the variables, as specified in the pane for variable definition, will be exported into the initial design point file. The design point can also be exported as a SPICE file, by clicking on the button labeled “Export design point”. This will invoke 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 during optimization (both global and centering) into a database file. This can be queried using the GUI and also by a simple query language from the command line. Using it from the command line gives more flexibility to the user. All types of queries supported in the command line are not yet available in the GUI. These will be added in future. The database file is updated every 2 iterations while AnXplorer is running. Thus database queries 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 in figure 3.22. It consists of four buttons, labeled “Load global database”, “Load feasibility database”, ”Load centering database” and “Load porting database”. The lower part of the GUI will be blank. Clicking on any of these buttons will load the corresponding database, if it is present in the project directory. If it is not present, or is corrupted, an error message will pop up. Once the database is loaded, the bottom part of the GUI will be populated and will appear as shown in figure 3.23. All objective values defined by the user will appear in the query definition form. A query is a set of conditions on the values of the objectives. The result of a query is a set of design points where the objective values satisfy these constraints. Let us take an example. Figure 3.23 shows the following objectives: I(vsupply), risedelay, falldelay, c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
64
Using AnXplorer in standalone graphical mode
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 objective value, select the check-button corresponding to the objective name, select the direction of constraint (greater than, or less than), and enter the constrained value in the entry field. Any number 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 defined query. This allows nested queries. Select the source of data for a query from the drop down menu at the top of the GUI, labeled “Input data”. This menu always contains at least one entry titled “Entire DB”, which means the entire database file. Names of previously defined queries, 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 be unique, i.e. each query should have a different name. Once the query is defined, click on the button 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 then clicking on the button labeled “Display”. It can then be edited. The results display window consists of two tables – the upper one shows the objective values for all points which satisfy the constraints of a query. The lower table shows the position of each of the points. Both tables are indexed by the Record index, which is the serial number of the database record. Thus, the position and performance of a particular c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
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 to sort 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 points reported in the results, click on this button. A pop up window will appear, prompting the user for the record index of the design point. Enter the record index (from the table) of the chosen point, and then click on OK. The initial design point file is created. Similarly, the design point can be exported into a SPICE file by clicking on the button labeled “Export design 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 of what 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 optimization or design porting), the project directory will contain the following things: c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
66
Using AnXplorer in standalone graphical mode
1. AnXplorer input file (see Chapter 4 for the syntax of the input file) for the various optimizations, named opamp.input 2. Optimization log files for the various optimization. Please see section 6.5 for details of the log file format. The names will be opamp.feasibility.log, opamp.global.log, opamp.centering.log and opamp.porting.log, for feasibility analysis, global optimization, design centering and design porting, respectively. 3. Output directories for the various optimization. Please see section 6.5 for details of the contents of the output directories. The names will be (in the same order as above): 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.sdb and opamp.porting.sdb. 5. In case the user has run feasibility analysis, and updated the variable ranges with the feasible 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: â&#x20AC;˘ A local copy of all the OCEAN scripts created by the user, having the same naming convention as the netlist files, but ending with an extension .ocn. â&#x20AC;˘ 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 design porting, or imported from outside. The name will be opamp.initial design.sp. 9. The technology parameter file, named opamp.tparam containing the parameters for implicit sizing rule evaluation. 10. The file opamp.map contains the mapping between original file names and locally copied file names (for example, for the testbench files). This is used when the project directory is copied to a new location .
c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
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, the netlists of the design and its test benches need to be prepared. This chapter describes how the 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 is defined as a subcircuit which may be defined in a separate file. Each test bench has a separate netlist which instantiates the main block, either by defining the main block subcircuit, or by including the netlist file of the main block. AnXplorer needs one or more such test bench nelists for optimizing a design. All commercial analog simulators support parameterized netlists, i.e. netlists where some quantities are denoted by variables. While preparing the design for optimization, denote the optimizable quantities, e.g. transistor width and length, value of passive devices, etc., by such parameters. The user may assign some â&#x20AC;&#x153;testâ&#x20AC;? values to these parameters to test the simulation setup. Otherwise, she may choose to leave these variables undefined. While optimizing a circuit, AnXplorer will assign different values to these variables and evaluate the circuit at different design points. A design point is a set of values for the optimizable variables. AnXplorer currently supports the following simulators: â&#x20AC;˘ The Spectre circuit simulator from Cadence Design Systems, Inc., used from the Cadence Analog Design Environment (ADE) with Cadence waveform calculator functions as objectives. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
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 as objectives. • 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 commercial simulators 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 for Cadence 5.x users only. For designers using Cadence 6.x and Spectre as the simulator, this is 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 setup a design, as AnXplorer is not directly integrated with the 5.x environment. Additionally, if Finesim with Spectre format inputs is the external simulator, these steps must be followed to setup the design for optimization, irrespective of the version of the Cadence 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 can be used with OCEAN scripts to calculate the objective function. OCEAN scripts can use a variety of analog simulators for performing actual simulation. However, in this flow, we currently support only Spectre as the underlying simulator. This flow is the easiest to use and can be listed as follows: 1. Prepare the main block and the test bench schematic views as is normally done in Cadence Schematic Editor. 2. For each test bench schematic view, open ADE, import the variables from the cell view, and set up the required simulations. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Usage with ADE using OCEAN scripts
69
3. For DC operating point simulations, enable the printing of the operating point. This can be done as follows: Open DC analysis, click on “Options” and then click on the check button labeled “print”. Note that this step is mandatory for using the in-built operating point analysis (see Chapter 3 and 6). Also note that the name of the operating point analysis block in the input to AnXplorer, either from the GUI or command line, should be same as the name of the operating point analysis in the test bench. Usually, this name is dcOp. 4. Also, if the in-built operating point analysis is being used, dump the CDL netlist of the design. 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 netlist needs to be recreated. 5. Select the outputs to be saved. It is prudent to save only those outputs which are required for post processing the results and calculating the objectives. Saving everything increases the simulation time. 6. Define the post processing functions. There are usually two types of functions – ones which return a waveform and others which return a number. Any number of postprocessing functions can be defined, but the performance objectives to be used for optimization with AnXplorer must have a numerical return value. Also, the names of these 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 performance objectives. While creating the functions, to get the waveform at a node, say, net1, type getData("/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 set up is correct. 8. Once satisfied, dump the Spectre netlist and OCEAN script for this test bench. To create a Spice desk in the Cadence Virtuoso environment, open Analog Artist and 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 editor “File” menu, choose “Save as” to save the netlist in your work area. To create the OCEAN 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 the OCEAN 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 the OCEAN script should be saved as /home/test/testbench1.ocn. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
70
Preparing a design for optimization in the standalone graphical mode
4.1.2
Preprocessing the OCEAN scripts
If you are using AnXplorer in the graphical mode, then the above steps complete the design setup. You now need to create the optimization setup by defining variable ranges, optimization targets, etc. Use the OCEAN scripts saved from ADE as the Spice file option of the analysis blocks. These OCEAN scripts need some pre-processing to be used with the tool. In the graphical mode, these are done automatically. In the command line mode, the user needs to invoke a preprocessing script for this purpose. In the command line usage mode, the OCEAN scripts can be preprocessed using the following 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 (with slight modifications) from the input script. It adds a set of printf commands to print the values 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 to be followed. â&#x20AC;˘ From the original script, delete all lines except the ones which define the calculator functions. â&#x20AC;˘ 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 proprocessing script), use this as the netlist file attribute of the corresponding analysis in either the graphical or command line mode. Please see Chapter 8 for an example of an OCEAN script. Note: Hspice, SmartSpice, Eldo or Msim currently cannot be used as the underlying simulator if OCEAN scripts are being used. This feature will be added in the future. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Usage with ADE using OCEAN scripts
4.1.3
71
Editing the Spectre netlist
In the graphical mode of AnXplorer, the Spectre netlist is modified automatically. In the command 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 configuration file or the GUI. Otherwise, retain the model file inclusion statements. These statements begin with the keyword include. 2. Remove the definition of all parameters which are optimization variables. Retain the definition of other parameters. The optimization variables will be defined by AnXplorer and included in the netlist. 3. If temperature corners are being used, remove the temperature definition in the netlist file. 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 this part of the file, remove all info commands. Any statement where the second word is info is an info command. This needs to be done for any test bench netlist for which an in-built analysis type (operating point or gain/bandwidth â&#x20AC;&#x201C; 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, requires Spectre to dump waveform outputs in text format. However, these info commands are supported only in the binary output formats of Spectre, which AnXplorer cannot presently 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 of the operating point analysis â&#x20AC;&#x201C; it is typically dcOp. Use exactly the same name for the operating point analysis block in the input to AnXplorer. 7. Edit the analysis names to be exactly same as the analysis names defined in the configuration 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 automatically in the graphical mode. In the command line mode, the user needs to manually edit the netlist as follows: In the file, the user needs to comment out the last .SUBCKT line and the last .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. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
72
Preparing a design for optimization in the standalone graphical mode
4.1.5
License queueing
When AnXplorer is used with Spectre as the underlying simulator, it will by default expect the Spectre license to be available. If it is not available when the tool starts, or becomes unavailable while optimization is ongoing, the tool will error out. To make AnXplorer wait for 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 be available.
4.1.6
Usage with Finesim
Finesim is input compatible with Spectre and can be used to simulate Spectre netlists, using the -spectre command line option of Finesim. AnXplorer supports the use of Finesim with Spectre 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 the external simulator being used. It is not applicable in case of Finesim. Finesim users must follow 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 exactly the 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 exactly the 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 Hspice here. Usage with SmartSpice, Msim or Eldo is exactly similar. As with Spectre, the Hspice netlist 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 configuration file or the GUI. Otherwise, retain the model file inclusion statements. 2. Remove the definition of all parameters which are optimization variables. Retain the definition of other parameters. 3. If temperature corners are being used, remove the temperature definition in the netlist file. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
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 them with .print statements for the appropriate outputs. For the in-built gain/bandwidth analysis, print the magnitude and phase (vm and vp) of the output node. For the in-built noise analysis, print the input referred noise voltage. 6. For post-processing function based analysis, remove all .probe and .print statements and add approprate .measure statements. The names of the measurements should be the 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, typically there will be two option statements like this: ARTIST=2 and PSF=2. Remove these options. Automatic editing of Hspice netlists is currently not available. This feature will be added in the near future.
4.3
Usage with Dspice
Dspice is the in-built simulator of AnXplorer. It is a simple upgradation of the free source Berkeley Spice3, with some additional features like parameter substitution, .measure based post-processing, etc., added. It is just a prototype simulator, to be used only on very simple designs, for demonstration purposes. Its interface is aimed to be compatible with hspice, but there are a few major deficiencies: â&#x20AC;˘ The parameter scoping is not exactly like hspice, and thus it may not be able to handle all types of .lib statements for model inclusion. â&#x20AC;˘ It does not support Verilog-A based models. â&#x20AC;˘ It supports only a small subset of .measure statements supported by hspice. The convergence mechanism of Dspice is, also, considerably weaker than those of commercial simulators. It can often fail to converge.
c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
CHAPTER
5
Using AnXplorer within the Cadence Virtuoso design environment
This chapter describes the usage of AnXplorer within the Cadence Virtuoso design environment. This mode (which can only be used with Spectre as the underlying simulator) has several advantages.
• This mode melds in seamlessly with the normal analog circuit design flow within the Cadence environment.
• No need to separately create or edit test bench netlists and OCEAN scripts. AnXplorer directly creates these from the Cadence database.
• Optimized design variable values can be written back to the original cell view by the click 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 can not be used in this mode. For 5.x users, the fall back is to generate netlists and OCEAN scripts 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. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Enabling AnXplorer menu
5.1
75
Enabling AnXplorer menu
To start using AnXplorer in the Cadence Virtuoso mode, you need to add the following line to 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 installation directory. Once this is done, the “AnXplorer” menu will show up in the Schematic Editor window menubar, 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 schematic view of the cell (and possibly a symbol view as well). In addition, she will also have one or more test bench schematics (not needed if the test bench is included in the cell schematic itself), and one or more ADE L state(s) for each test bench, to measure the performance of the circuit. AnXplorer blends in seamlessly with this flow. Each cell being optimized is treated as a separate project in AnXplorer, and the ADE L states are used as the analysis functions. When AnXplorer is invoked from the schematic view window of a cell, it automatically takes the name of the cell as the name of the project. The main window of the project, invoked by 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. The name 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.xan under the current working directory. Here libname is the name of the Cadence library conc 2007-12 AgO Synthesis LLP
Proprietary and Confidential
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 the project 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, the ADE L window pops up automatically, and then disappears, several times. This is normal behavior, and should not cause an alarm.
5.3
Variable definition, options definition, and technology specific parameters
The variable definition tab in this mode is similar to that in the stand alone mode, with one difference. In addition to the optimization variables, the GUI also shows the variable names extracted from the cell view (and their values, if available) in a list box, at the bottom left corner of the page. Clicking on the variables in this list will display the corresponding optimization variable, if one has been already defined, Otherwise, it will show its name in the c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Analysis and target definition
77
entry field for the variable name. Please see section 3.4 for details on defining optimization variables. The options definition tab is also similar, except that the widget to select the external simulator is absent in this case. This is because only Spectre can be used as the external simulator in this mode. Please see section 3.5 for details on the different options to be specified in this page. The technology specific parameter definition tab, for defining the thresholds for the in-built sizing 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 individual transistors. 2. General simulation based analyses with user defined objectives. Calculator functions can 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 of arbitrary 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 its own simulation inputs, or link it to another analysis. The concept is described in detail in section 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 ADE L state. The state must be storead as a cell view, and not a directory. Please select the radio button labeled “Use Artist state”. There are three entry fields, one each for the library, cell and view names. These entries are disabled (user cannot directly type text into them). To select a state, click on the button labeled “Browse”. This will bring up 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 three entry fields, and will automatically generate the Spectre netlist, OCEAN script, and CDL file for this analysis. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
78
Using AnXplorer within the Cadence Virtuoso design environment
• 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 commands for performing a Monte Carlo simulation are generated by the tool and added to the Spectre netlist created from the ADE L state. The different options for Monte Carlo simulation can be specified by clicking on the button labeled “Monte Carlo options” in the 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 latin hypercube 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 optimization 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 the target are taken as µ − 3σ and µ + 3σ respectively. If a target has a upper limit, then the 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 than the limit. • For Monte Carlo simulation based optimizations, the user can also choose to specify a Spectre netlist, created through ADE XL. To use this mode, please select the radio button labeled “Spectre netlist (only for MC)”. In this mode, the user has to specify the location of a Spectre netlist to perform Monte Carlo simulation. This netlist can be specified by using the button labeled “...”, which will pop up a file browser. The netlists is usually found under the adexl simulation directory. The user needs to run Monte Carlo 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 former can be linked to the latter. To do this, check the button labeled “Link to analysis” and type in the name of the analysis in the entry labeled “Linked to”. An example of this could be as follows. 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 transient analysis. In this case, the user can define an operating point analysis in AnXplorer with the 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, and analyze the values of the functions defined on the transient analysis. Thus, the function analysis should be linked to the operating point analysis. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Analysis and target definition
79
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 described in section 3.7.2. Further, the specification of the constraints and objectives for operating point and function analysis, and the score calculation methodology, are almost exactly similar to what has been already covered in section 3.7. Thus, we omit these here. Operating point c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
80
Using AnXplorer within the Cadence Virtuoso design environment
analysis details can be found in section 3.7.3. The only difference is that here the user need not explicitly specify a CDL netlist file, as it is automatically generated by AnXplorer. The in-built noise analysis feature is not supported in this mode of operation. The user defined function analysis description can be found in section 3.7.5. The difference in this case is that the user need not specify the type of simulation (AC, DC, transient, etc.) being used for the analysis. Simply select the radio button labeled “AC/DC/TRAN”. For Monte Carlo simulation based analysis, select the button labeled “Monte Carlo”. The GUI for a Monte Carlo simulation based analysis is shown in figure 5.5.
Figure 5.5: GUI for creating a Monte Carlo simulation based analysis in the Cadence Virtuoso environment
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 all simulation inputs and other optimizer options have been setup correctly. This is described in detail in section 3.9.1. As in the stand alone mode, here too AnXplorer can be run in four modes: Feasibilty analysis, global optimization, design centering and porting optimization. The semantics of these 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 in this mode. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
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 detailed description can be found in section 3.10. The manual tuning GUI (see section 3.9.8) can be used here as well. Optimized variable values can be back annotated into the cell view from multiple places in the GUI: 1. From the Log tab of the GUI. In the lower part of the tab, the user can select any optima (in case of feasibility analysis or global optimization), or the end result of any iteration (in case of design centering), and click on the button labeled “Export variables to cell view’. 2. From the database query result window. Click on the button labeled “Export variables to cell view”. A pop up window will appear, where the user has to type in the index of the point to be exported. 3. From the manual tuner GUI. Once satisfied with the simulation results, the user can choose 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 SPICE input file (this is available in the stand alone mode).
c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
CHAPTER
6
Using AnXplorer from command line
As stated earlier, AnXplorer also has a command line usage model. This model provides the user more flexibility in terms of input setup and analysis. It provides a few analysis types which are not available in the GUI. The database query language offers many more features in the command line mode. The inputs to AnXplorer in the command line mode are as follows: â&#x20AC;˘ The configuration file, which defines the variables, options, analyses and targets, and the cost graph. â&#x20AC;˘ The technology specific parameter file (optional). In the GUI mode, this is defined in the technology parameters page. â&#x20AC;˘ The analysis test benches.
6.1
The configuration file
The configuration file is the main input to AnXplorer. It contains four sections which should be written in the following order: 1. The variable definition section. 2. The optimizer options specification section. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
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 commands or command blocks from different sections cannot be intermingled. For example, an analysis specification 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 characters do not matter.
Keywords The following are reserved keywords of the input language and can be used only in their designated positions. Some keywords are not used currently but reserved for future use. abs analysis_type cdl_file cosh current_consumption deltav exp frequency HCG input log max_iters midpoint model_name node_voltage no_sizing_rule parallel_exec sin sqrt tanh
ac asin cmrr corner dc delvds extract gain_bw i_gain_bw i_variable log10 max_step min_val montecarlo noise_analysis ocean_script pow sinh subckt_mos_model techfile
c 2007-12 AgO Synthesis LLP
acos atan cos cmrr dc_gain directory flicker_noise granularity ignore linked_to log_partition max_val model_file mos_constraints no_mutation op_point reltol spice_file tan techspec Proprietary and Confidential
84
Using AnXplorer from command line
temperature tran use_fsim_spice use_msim use_smartspice voltage_supply
thermal_noise use_eldo use_fsim_spectre use_ocean use_virtuoso weight
total_noise use_eldo_compat use_hspice use_spectre variable sim_options
Identifiers Identifiers, e.g. variable and analysis names, can contain only alphanumeric characters and the 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 (“”). Anything enclosed 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 character sequence // 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 currently supported.
6.1.2
Variable definition section
The general form of a variable specification is as follows: variable <variable name> { min_val <minimum value>; c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
The configuration file
85
max_val <maximum value>; granularity <step size>; } The keyword step can be used in place of granularity in the example above. They have the same meaning. The variable name should be an identifier (as described above) and minimum value, 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 keyword i 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. Intermediate results are also stored in this directory. The temporary directory to be used is specified with 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 â&#x20AC;&#x2DC;;â&#x20AC;&#x2122; at the end. This directory, if not already present, will be created by the tool. If the directory is not specified, then the default directory name is AgO outdir. If the directory is already present, its contents will be deleted 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 corner name, a temperature value and a set of design variable values (all of them are optional). The syntax for corner definition is as follows: corner "<corner name>" { model_file "</path/to/model/file>", "<optional library corner>"; temperature <temperature value>; variable { "variable1" = <value1>; ... c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
86
Using AnXplorer from command line
"variableN" = <valueN>; } } Please see section 3.5.8 for a detailed explanation of corners and how they are used. Multiple corners can be specified.
Specifying the model file Note: This has been phased out from version 2011.11 onwards, and is retained only for backward compatibility. Use the corner definition instead. Model file(s) to be used in the optimization process should be specified using this command. 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 included with a statement like .lib <file name> <corner name>. Specifying the temperature options Note: This has been phased out from version 2011.11 onwards, and is retained only for backward compatibility. Use the corner definition instead. 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 Note: This has been phased out from version 2011.11 onwards, and is retained only for backward compatibility. Use the corner definition instead. Let the voltage supply parameter be called vsupplyvar. The supply voltage options can be specified with the following command: voltage_supply vsupplyvar <value 1> , <value 2> , ... ; c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
The configuration file
87
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 argument. To use the native DSpice, do not specify any simulator command. If using directly from Analog Artist, using OCEAN scripts for calculator functions, specify virtuoso as the simulator.
Specifying the simulator command line options The user can override the default command line options for the external simulator supplied by AnXplorer at the time of invoking the simulator. The user supplied command line options for 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 for details.
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 mode is specified by the following command: max_iters <number of iterations> ; This option is used only in the global optimization and feasibility analysis modes. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
88
Using AnXplorer from command line
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 command: 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 and specified in the configuration file. The technology parameter file should be specified with a command 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 specific parameter file, and thus did not support different technology specific parameters for different types of transistor. From version 2010.12 onwards, different rules can be specified for different transistors types, by specifying them in different files. This is useful for processes which provide 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 technology specific parameters in the main input file itself. The provision for a separate technology specific parameter file is retained for backward compatibility. The syntax of specifying the technology parameters within the main input file is described next. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
The configuration file
89
Specifying technology parameters in the configuration file The technology specific parameters for a model type can be specified using a command block similar 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 different type of transistor. NMOS and PMOS model names are specified in the model name section of the above block. Any number of model names can be specified for each type (NMOS and PMOS) – the same rules will apply to all. AnXplorer requires several parameters to determine whether a circuit has been properly sized. 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_A_MIN N_V_MIN P_V_MAX
P_VSAT_MIN N_VTRIO_MIN P_V_MIN N_DELTA_VDS_MAX
N_A_MIN P_VTRIO_MIN N_V_MAX P_DELTA_VDS_MAX
• N VSAT MIN and P VSAT MIN denote the minimum allowable difference between VDS and the overdrive for transistors in saturation (N and P respectively). • N TRIO MIN and P TRIO MIN denote the minimum allowable difference between the overdrive 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 the VDS of two transitors in a current mirror structure. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
90
Using AnXplorer from command line
â&#x20AC;˘ 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 the internal format. One can use the GUI to get the name in the internal format from a normal hierarchical 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 calculation. 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 c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
The configuration file
91
mos constraints command block. Each line in this block is a constraint on a separate device. To set a constraint on the overdrive, use the keyword deltav, and for constraint on Vds − Vdsat use delvds. <sign> is either <, or >. The user should also specify the set of corners for which this analysis will be evaluated in the design centering mode, as shown in the above block. If all corners are to be used, please specify 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 location of the mapping directory, or the "amap" directory. 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 be simulation/<cell name>/spectre/schematic/netlist/amap. This needs to be specified using the amap dir command shown above. To include this analysis (the node voltage and current consumption objectives) in the feasibility analysis mode, please specify the command include in feasibility in the analysis definition 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 of amplifiers. In this analysis, the user specifies the following: • The expected DC gain of the output node. The magnitude of the input AC source is also required, as it is used to calculate the gain. The tool tries to increase the gain beyond this limit. • The expected unity gain bandwidth (UGB) of the amplifier. Here, too, the target is to increase the UGB beyond the specified limit. • The expected phase margin of the amplifier, which will be increased beyond the specified limit. While these targets can be calculated easily using standard post-processing functions provided by different simulators, the value addition of this in-built analysis is that it tries to analyze the Bode plot of the output node versus frequency. It searches for the existence of poles and c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
92
Using AnXplorer from command line
zeroes in the Bode plot, and tries to move the second dominant pole and any zero at least a decade beyond the unity gain bandwidth. Thus, it ensures that that the amplifier is stable in closed loop operation. Large R − Mega ohm range
inm + −
Large C
inp
vsmall
+ −
Vdd out
−
+ −
+
Supply voltage
Vss Load impedance
Vinp
Vinp inp1 0 DC Vdd/2 Vsmall inp inp1 DC 0 AC 1 .ac dec 100 1 10e+9 .print ac vm(out) vp(out)
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 shown in figure 6.1. Here, one input is held at AC ground and an AC signal is applied at the other end. For fully differential amplifiers, AC signals are applied at both inputs. This analysis is available only with simulators which give textual dumps of the output waveforms. 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. amap_dir <location of the mapping directory, in case of Spectre>; include_in_feasibility; // Same as in operating point analysis } c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
The configuration file
93
The magnitude of the input AC waveform is specified by the input command. The expected gain, bandwidth and phase margin of the node specified by <node name> will be calculated and optimized, i.e. the gain, bandwidth and phase margin of the synthesized circuit should exceed 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 targets list.
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. corner <list of corners>; // As before. amap_dir <location of the mapping directory, in case of Spectre>; include_in_feasibility; // Same as in operating point analysis } 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 measurement for 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 the following: extract <analysis name> { spice_file <test bench file name> ; ocean_script <script file> ; // As in other analyses. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
94
Using AnXplorer from command line
// 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. corner <list of corners>; // As before. amap_dir <location of the mapping directory, in case of Spectre>; include_in_feasibility; // Same as in operating point analysis } Here, <sign> is either < or >. Target name should normally be an identifier. However, if enclosed 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 function. A very common application of this is the circuit area optimization. The user can create an 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 performance parameter, if it can be expressed as a function of the variables, can be optimized using this analysis. 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 previously defined target as one of its input parameters. The function is to be defined as a standard expression as in the C programming language. All C standard library mathematical functions are available. An example of this type of analysis is given below: extract esm { c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
The configuration file
95
{ 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.8 for a more detailed description of the concept of a hierarchical cost graph). It must be a a non-negative integer. It should be followed by a space separated list of target indices which belong to that level. In the cost graph definition, targets are indicated by their indices in the targets 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 use the 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 edge definitions. Note: There can be only one HCG block in the configuration file. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
96
Using AnXplorer from command line
6.2
Technology specific parameter file
If separate technology specific parameter files are used, its name has to be specified in the input configuration file. The syntax of this file is much more restrictive than the input configuration file. Specifically, comments and blank lines are not allowed. Commands can be written only in a specific order. It is not free-format. Each command should be in a separate line. 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 specified in this section. The section must begin with the keyword Model in a separate line. Each subsequenty 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 parameter specification section should begin with the keyword Parameters in a separate line. Each subsequent line must begin with a parameter name (refer to section 6.1.4) and the next entry should be the value for the parameter in appropriate units. Each line should contain only a single 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, specified as a set of parameter values, needs to be provided. This design point is to be written into a c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Running AnXplorer from the command line
97
file and provided to the tool in the command line (by the -p argument). The design point has to be specified as a set of standard .param statements supported by Hspice[3] or other commercial SPICE tools. Again, comments and blank lines are currently not supported in the 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 configuration file. • -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 design centering mode. The name of the file containing the initial design point (in the format described earlier) should be specified with this option. If this option is specified, the tool 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. This overrides the number of threads specified in the input configuration file. • -t: The maximum number of iterations for global optimization is specified using this option. This overrides the iterations specification in the input configuration file. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
98
Using AnXplorer from command line
• -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 initial point is updated and a new design space is searched. To change the size of the design space being searched, use this option. The argument is a percentage value, e.g. 10, or 2, or 15.
6.5
Outputs of AnXplorer
Major outputs of the tool are printed on the standard output. They are also printed in the output log file as discussed above in the current directory which can be used for future reference. The tool also stores the performance measures and score at each design point explored in the database file. After AnXplorer exits, this file can be queried to extract very useful information about the design points. The query language for the database is discussed in the next chapter. As the tool run, a dot (‘.’) is printed on the standard output for every design point that is 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 command line, is derived from the name of the input file. For example, if the input file name is 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 optimization, design centering, and design porting modes, respectively. When the tool is invoked, it prints a brief description of the variables used and the objectives specified. The user can use this message to verify whether the objectives specified in the configuration 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 obtained at each design point in one iteration, the positions of the design points in the next iteration are determined. At each iteration, key statistics for that iteration is printed in the log file. A sample 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 so far. This number should approach the number of objective specified, as the process nears a local optimum, since a score of 1 (or less) for each objective indicates that the objective has c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Outputs of AnXplorer
99
been met. The third column indicates the best scrore encountered in that iteration. Note that this might be greater than the overall best score. The fourth column is the average score of all positions evaluated in the iteration. The fifth column indicates the worst score encounted in that iteration. The last column indicates the number of positions evaluated so far in the course of the optimization process. The above holds true for the global optimization and feasibility analysis modes. In the case of design centering and design porting, the semantics are slightly different. Here, each iteration has 10 sub-iterations. The statistics for each sub-iteration is printed in the above manner. AnXplorer does a systematic exploration of the design space. In the feasibility analysis and global optimization modes, it finds several local optima, each of which are printed as they are found. The information printed are: the position of the design point (the values of the variables), the performance measure of the design point, and its score. In case of design centering and design porting, the same information is printed after each iteration. In the feasibility analysis and global optimization modes, the tool exits when either â&#x20AC;˘ all objectives have been met. â&#x20AC;˘ the user specified maximum number of iterations are over. Note that the tool may not stop immediately after the specified number of iterations are over. It will proceed till the next optima is found, and then exit. â&#x20AC;˘ 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 improvement 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 prints the list of locally optimum points found, sorted in the ascending order of scores (i.e. best ones first). In case of design centering, in addition to the worst case performance of the final centered design, it also prints the performance at each corner. Finally, it also prints a sensitivity analysis report. This shows by how much the worst case value of each objective function 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 named iteration*, suffixed by the iteration number. Each subdirectory contains a file called best positions, which gives the best design points encountered by the tool till that iteration. These can be analyzed to determine the path that was taken by the optimizer to c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
100
Using AnXplorer from command line
reach the optima. The file contains the position and performance of the positions encountered by the tool, sorted in ascending order of score.
c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
CHAPTER
7
Using the database query language
As mentioned in the previous chapters, AnXplorer dumps a record of all design points visited by it global into a database file. This file can be queried (using a simple query language that we 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 can specify the name of the database file in the command line for AnXplorer. The default name for the database file is <fname>.global.sdb and <fname>.centering.sdb in the global and design 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 two iterations, while AnXplorer is running. Thus, database queries can be run in parallel with AnXplorer. The distribution of AnXplorer includes an executable called xdbsh which has 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 next section. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
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 be written 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 the configuration file discussed in Chapter 6. This language is free format, and every statement ends 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 search for design points where the objectives satisfy the specified constraints. The objective names used 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 function based analysis, or some in-built names for other special analyses (discussed next). <analysis name> is the name of the analysis block which defines this target. The objective names, when used 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>, where node 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>). Note that the constraints for individual transistors are not available. A sum total of evaluation on 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>). c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
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 the keywords 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 following information. • 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 keys for processing the database entries. For example, the database entries can be sorted in the descending order of their gain. The score value of the entries can also be used as a primary key. 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 same thing. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
104
Using the database query language
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 can be done using the function get(). This function returns a data set containing all database entries, which can then be passed on as argument to data set processing functions, or assigned to 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 given primary key. For example, we can choose to sort a data set in descending order of the values of gain. • Finding the top n entries for a given primary key, i.e. to find the n highest values for the given primary key. Similarly, we can also find the bottom n entries, i.e. the n entries which 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 a given 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 an argument 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, one should use variables (discussed later) to achieve greater depths of nesting. Note: None of the data 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 command should be used. The sortd command is used to sort in descending order. The syntax of these two functions are as follows: c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
The query language
105
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 to be used. Similarly, the bottom function is used to find the least n values of a given primary key. 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 a given 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 by the intersect function, and set difference is performed by the diff function. The syntax of these 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>. It is best to use parentheses to disambiguate precedence. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
106
Using the database query language
7.2.6
Variables
Variables are placeholders or shorthand notations for data sets. A data set can be assigned to a variable. This variable can later be used as argument to data set operations. Variables must be assigned prior to use. A variable name is an identifier, i.e. it must begin with a letter or the character. Variables can be assigned using the following type of statement:
underscore
<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 the readability of a query.
7.2.7
Displaying results
The contents of a data set can be displayed using the display function. This will display the values of all performance metrics and the score of each database entry contained in the set, on the standard output. It the data set is empty, it will post a message <NO DATA>. The position function can be used to display the position vector (values of design variables) of specific 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 the integer.
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 following three: • A variable assignment statement. • A display function call. • A position function call. c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
The query language
107
A data set function, by itself, is not a syntactically valid statement. Each statement must end with 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 we want to display the performance metric values for all entries whose gain is greater than 65 db and bandwidth is greater than 255 MHz, and phase margin is greater than 60 degrees, sorted in 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. We take the intersection of these two sets. We now display the top ten entries of the intersection in 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)"));
c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
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 circuit is a two stage opamp whose schematic is given in figure 8.1.
Vdd
Vin(â&#x2C6;&#x2019;)
Vin(+) Vout
Gnd
Figure 8.1: Example two stage opamp circuit
c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Netlist file
8.1
109
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 MM9 net2 net1 vdd vdd PCH w=pcm1w l=pcm1l Ibias net1 gnd DC 100u * N MM8 MM7 MM6
current sources net2 net2 gnd gnd NCH w=ncm1w l=ncm1l net3 net2 gnd gnd NCH w=ncm2w l=ncm1l 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 MM3 net4 net4 vdd vdd PCH w=pcm2w l=pcm2l MM4 net5 net4 vdd vdd PCH w=pcm2w l=pcm2l * 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 c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
110
8.2
Examples of input files to AnXplorer
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 { c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
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; } c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
112
Examples of input files to AnXplorer
// 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; } c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
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" ); c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
114
Examples of input files to AnXplorer
// 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; }
c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
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 be found 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 examples section of the AnXplorer distribution. // c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
116
Examples of input files to AnXplorer
// 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); // // // // // t1
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.. = 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)")); c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
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( c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
118
Examples of input files to AnXplorer
’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 special format 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 circuit definition 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
c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
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
c 2007-12 AgO Synthesis LLP
Proprietary and Confidential
Bibliography
[1] P. E. Allen and D. R. Holberg, CMOS Analog Circuit Design, London, U.K.: Oxford Univ. 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 R High Accuracy Circuit Simulator [Online] Available: [6] MSIM http://www.legenddesign.com/products/msim.shtml [7] Eldo [Online] Available: http://www.mentor.com/products/ic nanometer design/analog-mixed-signalverification/eldo/ [8] ActiveState [Online] Available: http://www.activestate.com/Products/activetcl/
c 2007-12 AgO Synthesis LLP
Proprietary and Confidential