Workshop for AMSD Incisive Use Model

© 2009 Cadence Design Systems, Inc. All rights reserved worldwide.

Cadence Design Systems, Inc.

Workshop for AMSD Incisive Use Model

Revision 1.8

AMS Product Engineering

September, 2010


2

Cadence Design Systems, Inc. (Cadence), 2655 Seely Ave., San Jose, CA 95134, USA.

Product AMS contains technology licensed from, and copyrighted by: Regents of the University of California, Sun Microsystems, Inc., Scriptics Corporation, and other parties and is © 1989-1994 Regents of the University of California, 1984, the Australian National University, 1990-1999 Scriptics Corporation, and other parties. All rights reserved.

Open SystemC, Open SystemC Initiative, OSCI, SystemC, and SystemC Initiative are trademarks or registered trademarks of Open SystemC Initiative, Inc. in the United States and other countries and are used with permission.

Trademarks: Trademarks and service marks of Cadence Design Systems, Inc. contained in this document are attributed to Cadence with the appropriate symbol. For queries regarding Cadence’s trademarks, contact the corporate legal department at the address shown above or call 800.862.4522. All other trademarks are the property of their respective holders.

Restricted Permission: This publication is protected by copyright law and international treaties and contains trade secrets and proprietary information owned by Cadence. Unauthorized reproduction or distribution of this publication, or any portion of it, may result in civil and criminal penalties. Except as specified in this permission statement, this publication may not be copied, reproduced, modified, published, uploaded, posted, transmitted, or distributed in any way, without prior written permission from Cadence. Unless otherwise agreed to by Cadence in writing, this statement grants Cadence customers permission to print one (1) hard copy of this publication subject to the following conditions: 1 The publication may be used only in accordance with a written agreement between Cadence and its customer. 2 The publication may not be modified in any way. 3 Any authorized copy of the publication or portion thereof must include all original copyright, trademark, and other proprietary notices and this permission statement. 4 The information contained in this document cannot be used in the development of like products or software, whether for internal or external use, and shall not be used for the benefit of any other party, whether or not for consideration. Patents: Cadence products described in this document, are protected by U.S. Patents 5,095,454; 5,418,931; 5,606,698; 6,487,704; 7,039,887; 7,055,116; 5,838,949; 6,263,301; 6,163,763; and 6,301,578.

Disclaimer: Information in this publication is subject to change without notice and does not represent a commitment on the part of Cadence. Except as may be explicitly set forth in such agreement, Cadence does not make, and expressly disclaims, any representations or warranties as to the completeness, accuracy or usefulness of the information contained in this document. Cadence does not warrant that use of such information will not infringe any third party rights, nor does Cadence assume any liability for damages or costs of any kind that may result from use of such information.

Restricted Rights: Use, duplication, or disclosure by the Government is subject to restrictions as set forth in FAR52.227-14 and DFAR252.227-7013 et seq. or its successor.


3

Document Update History

This section contains a history of all revisions to this document.

Revision

Number Date Author Name Comments

1.7 Mar. 13,

2009 AMS PE

UPDATE: ams_aps ams_cpf ams_ncf amsd_saverestart packngo vhdl_spice_multi wreal_resoluton_function wreal_table_modeling

1.8 Sep 28, 2010 AMS PE

Added: Spice-on-top Update: ams_aps


4

Contents Overview ....................................................................................................................................................... 1 Chapter 1 Introduction of AMSD Incisive Use Model .................................................................................... 3 Chapter 2 User Guideline for AMSD Incisive Use Model .............................................................................. 5

The “amscf.scs”................................................................................................................................... 6 The CM/Crule ...................................................................................................................................... 7 The option of -propspath ..................................................................................................................... 8 The option of -modelpath..................................................................................................................... 8

Chapter 3 Basic Flow: verilog/ams + SPICE................................................................................................. 9 3.1 How to build a AMSD case using irun + AMS Control File ................................................................ 9

3.1.1 The design information ........................................................................................................... 9 3.1.2 Building the AMSD case....................................................................................................... 11

3.2 Digital Testbench Reuse in AMS domain .......................................................................................... 15 3.2.1 Ignoring/defaulting OOMR SPICE ........................................................................................ 15 3.2.2 Reading/writing OOMR SPICE............................................................................................. 18

3.3 Verilog and SPICE Interoperation...................................................................................................... 22 3.3.1 Port Expression .................................................................................................................... 22 3.3.2 Port Mapping ........................................................................................................................ 23 3.3.3 Generating port-binding file for name-dominant matching ................................................... 28 3.3.4 Tutorials................................................................................................................................ 29

3.4 SPICE-in-Middle Tutorial ................................................................................................................... 36 3.5 “amsd” block ...................................................................................................................................... 39

3.5.1 “amsd” block Advantage....................................................................................................... 39 3.5.2 Prop.cfg to “amsd” block migration....................................................................................... 39 3.5.3 “amsd” block cards and syntax............................................................................................. 40 3.5.4 “portmap” card ...................................................................................................................... 40 3.5.5 “config” card.......................................................................................................................... 43 3.5.6 “ie” card ................................................................................................................................ 44

3.6 Spice-on-top in AIUM Flow................................................................................................................ 46 3.6.1 Introduction........................................................................................................................... 46 3.6.2 Testcase information ............................................................................................................ 48 3.6.3 Configuration and Run Instructions ...................................................................................... 48 3.6.4 Critical Steps for SPICE-on-top Configuration...................................................................... 50 3.6.5 Limitations ............................................................................................................................ 50 3.6.6 Summary .............................................................................................................................. 51

3.7 Prop2cb_Stubview............................................................................................................................. 51 3.8 AmsKeywords.................................................................................................................................... 53

3.8.1 Design Information ............................................................................................................... 54 3.8.2 Running the Tutorial ............................................................................................................. 54

3.9 Spice Encryption in AMS Simulation ................................................................................................. 55 3.9.1 AMS-Ultrasim encryption...................................................................................................... 55 3.9.2 Run AMS-Spectre Encryption............................................................................................... 56

3.10 Common Power Format (CPF) ................................................................................................... 57 3.10.1 Introduction of CPF..................................................................................................... 57 3.10.2 CPF in AMS Designer................................................................................................. 57 3.10.3 Running AMS Designer Simulator on CPF tutorial ..................................................... 58

3.11 AMS Designer With APS Solver ................................................................................................. 63 3.11.1 Introduction ................................................................................................................. 63 3.11.2 AMS-APS Usage Recommendations ......................................................................... 64 3.11.3 AMS-APS Command-line Use Model......................................................................... 64 3.11.4 Running Case with AMS-APS .................................................................................... 66

3.12 Packngo ...................................................................................................................................... 68 3.12.1 Introduction of Packngo.............................................................................................. 68


5

3.12.2 Background of Packngo ............................................................................................. 69 3.12.3 Testcase Information and Architecture....................................................................... 69 3.12.4 Running the Tutorial ................................................................................................... 70

3.13 Netlist Compiled Functions (NCF) .............................................................................................. 73 3.13.1 Loading a Plug-in........................................................................................................ 73 3.13.2 Using a NCF in a Spectre Netlist ................................................................................ 74 3.13.3 Running AMS Designer Simulator on NCF tutorial..................................................... 74

Chapter 4 Advanced AMSD Features....................................................................................................... 80 4.1 Multiple Power Supply in AIUM.......................................................................................................... 80 4.2 AmsSaveRestart................................................................................................................................ 86

4.2.1 Save-and-Restart Use Models ............................................................................................. 87 4.2.2 Options in irun to support save/restart.................................................................................. 87 4.2.3 Test Case Description .......................................................................................................... 87 4.2.4 Preparing to Run the Tutorial ............................................................................................... 88

4.3 AMS-Spectre Envelope ..................................................................................................................... 91 4.3.1 Envelope Analysis Syntax and Parameters.......................................................................... 92 4.3.2 Test Case Description .......................................................................................................... 92 4.3.3 Tutorial Module 1: Envelope Analysis for Digital Modulator/Demodulator............................ 93 4.3.4 Tutorial Module 2: Envelope Analysis for Oscillator ............................................................. 94

Chapter 5 AMSD extension support.......................................................................................................... 97 5.1 Real Number Modelling ..................................................................................................................... 97 5.2 SystemVerilog.................................................................................................................................. 106 5.3 AMSD wreal $table_model .............................................................................................................. 109

5.3.1 Introduction of Wreal $table_model.................................................................................... 109 5.3.2 $table_model test case description .................................................................................... 110 5.3.3 Run simulation of wreal $table_model................................................................................ 111

5.4 Global Wreal Driver Resolution ....................................................................................................... 114 5.4.1 Background ........................................................................................................................ 114 5.4.2 Test Case Description ........................................................................................................ 114 5.4.3 Running the Tutorial ........................................................................................................... 115

5.5 AMSD VHDL-SPICE........................................................................................................................ 117 5.5.1 Introduction of VHDL-SPICE .............................................................................................. 117 5.5.2 Introduction of VHDL-SPICE conversion elements ............................................................ 117 5.5.3 VHDL-SPICE Test case description ................................................................................... 117 5.5.4 Simulating a 16-bit SPICE multiplier with VHDL digital stimuli ........................................... 119

5.6 SystemVerilog Real in AMS Designer ............................................................................................. 126 5.6.1 The purposes of this tutorial ............................................................................................... 126 5.6.2 How AMS Designer supports SystemVerilog-real in general ............................................. 126 5.6.3 Test Case Description ........................................................................................................ 127 5.6.4 Running the Tutorial ........................................................................................................... 129


Overview

Virtuoso AMS Designer is noted for its advanced philosophy and concept. It is a single executable Language-based Mixed-signal simulation solution for the design and verification of the largest and most complex Mixed-signal SoCs and multchip designs. It is integrated and fully compatible with both the Virtuoso custom design and Incisive functional verification platform. Accordingly, AMSD supports two major use models:

• AMSD Virtuoso Use Model: ADE + OSS + irun • AMSD Incisive Use Model: irun + AMS Control File

AMSD Virtuoso Use Model means running AMSD simulator within Virtuoso platform, which is 5x library (schematic) based, while AMSD Incisive Use Model takes the textual netlist only (including verilog/AMS modules and HPSICE/Spectre format), which is totally out of Virtuoso and launched from command-line. AMSD Virtuoso Use Model is more targeting for analog-centric design while AMSD Incisive Use Model is more for digital-centric design verification. This workshop will focus on the second Use Model. All the cases in this workshop use irun and AMS Control File. AMSU SFE may not be able to be the default in this release. However all the cases in this workshop work well with both UFE and SFE in AMSUltra. In this workshop, the following topics will be addressed:

AMSD Use Models

AMSD in ADE (OSS+irun)

AMSD Virtuoso Use Model (GUI Based)

IUS & IC

AMSD Incisive Use Model (Text Based)

irun + AMS Control File

IUS only

AMS Designer (with UltraSim, Spectre or

APS as analog solver)


P: 2

• What’s AMSD Incisive Use Model • What’s the basic usage for the AMSD Incisive Use Model • What kind of the advanced features does this Use Model have • What’s the status for the AMSD extension supports

This workshop requires the AMSD version of IUSxx. Please make sure you set the correct path to your IUSxx installation.

AMSD Acronyms

AMSD: AMS Designer simulator AMSS: AMSD with Spectre as the analog solver AMSU: AMSD with UltraSim as the analog solver AIUM: AMSD Incisive Use Model AVUM: AMSD Virtuoso Use Model AMSCF: AMS Control File, Analog and Mixed-signal inputs to the AMSD simulator, containing “amsd”

block, ACF and “include” statements for analog stuff “amsd” block: “amsd” block is a block consisting of ams cards like, “portmap”, “config” and “ie” ACF: Analog Control File, analog control statements for analog solvers Card: Spectre/SPICE terminology for a Spectre/SPICE statement or command. Now is used in “amsd”

block as well, like “portmap” card, “ie” card, etc. OOMR: Out Of Module Reference, references cross the modules CM: Connect Module, the converter between Analog and Digital signals Crule: Connect Rule, the file specifying which CM and what parameter values used in the design IE: Interface Element, spectreVerilog term, same thing as Connect Module BDR: Block-based Discipline Resolution, used for the design with multiple power supplies SFE: Simulation Front End analog parser


P: 3

Chapter 1 Introduction of AMSD Incisive Use Model

Background on SOC verification with mixed signal SOC verification is a very important EDA application. SOCs are primarily implemented and verified using digital-centric flows and tools. However, the analog and mixed-signal IP (blocks) in the SOC are typically implemented using Virtuoso and this IP is then handed off to the SOC flow for the final verification often in the form of a SPICE (means SPICE and Spectre) netlist. As the final SOC verification processes and engineers are digital centric, simulation is expected to use the traditional verilog simulation use-model. This is the verilogXL use-model. VCS, ncverilog and irun all comply with this use-model. This compliance enables the verification engineers to easily swap and mix vendor tools to get their tasks done. For a tool to fit easily into the SOC verification precesses, it needs to comply with the traditional Verilog simulation use-model. The tool also needs to be easy to use, reliable and high performance. Performance is very important because that all the verification tasks that be done on time against a tight schedule before the tape-out. SOC verification processes typically incorporate nightly regression testing in which large numbers of design simulations are driven by carefully crafted testbenches. Nightly regression testing is necessary in order to make sure that design changes made to fix bugs identified during verification don’t in turn introduce new bugs. Mixed signal simulations need be high performance in order to be incorporated into this process. Ease of use and reliability are also very important as the verification team are working against a tight schedule to complete all their verification tasks before the tape-out. Usability and relability issues will slow them down and hence risk the tape-out schedule. AMSD Incisive Use Model It is in the context of SOC verification that we present the AMSD Incisive Use Model. This is a use model that is very suiteable for mixed signal simulation during SOC verification. Like the updated AMS-ADE, the AMSD Incisive Use Model runs the AMSD simulator using the irun flow. It is tuned for methodologies that use SPICE (means SPICE and Spectre) to represent the IP that need to be simulated by the analog engine. The AMSD Incisive Use Model is a good match for the mixed signal simulation requirements of SOC verification because:

• For performance, it can use all the performance features of Ultrasim, including dx-mode. It uses the highly tuned IUS single step flow (irun). Parsing and elaboration should also be faster as the analog is sent directly to the analog engine in the form of a SPICE/Spectre netlist.

• For reliability it encourages (and is tuned) for methodologies that use Verilog input for the digital engine and SPICE for the analog engine. The reliability comes from the fact that Verilog is the most natural input for the digital engine and SPICE is the most natural input for the analog engine so it greatly simplifies the AMS aspect of the simulation.

• For usability, it follows the traditional Verilog flow by being part of irun. This also enables it to be easily incorporated into established SOC verification flows.

• Also for usability, it provides a number of powerful features to enable users to easily incorporate SPICE blocks into Verilog-centric simulations. It allows users to work with SPICE blocks almost as easily they can work with Verilog blocks.

AMSD Incisive Use Model Applications


P: 4

We expect that for SOC verification, there are two primary sets of applications for the AMSD Incisive Use Model: one focused on analog/mixed-signal IP; the other focused on the digital IP. These are:

1. Enabling users to use SPICE (or verilog-AMS) to represent the analog and mixed-signal IP in full SOC simulations for more accurate simulation – the accuracy comes from the SPICE representation being very closely tied to the implementation of such analog/mixed-signal IP;

2. Enabling users to use the SPICE representation of some of the digital IP in a full SOC simulation in order to do checks and measurements that are not possible in digital simulation and really need analog simulation e.g. dynamic power consumption or current leakage.

These combined with the AMSD Virtuoso Use Model for Mixed Signal block design and verification applications means that an SOC’s design and verification teams can use AMSD for all their mixed signal simulations needs. AMSD Incisive Use Model Support Strategy In the mixed-signal verification marketing today, verilog/ams + SPICE is the most popular combination, in which verilog represents digital circuit while SPICE represents analog circuit. The verilog/ams + SPICE combination covers most of the application. Please see the left side for basic application in the following picture.

The left side is the major focus in AMSD Incisive Use Model today and of course, it is also recommended to the users. The Chapter 2 will talk the basic application. The right side in the picture above is for AMSD extension support which will be covered in the Chapter 4.

Basic Application

- Verilog + SPICE/Spectre

- Verilog on top, SPICE in middle

- Simple use model: irun + AMS Control File

- irun: single executable

- AMS Control File: user-friendly inputs

Verilog/AMS + SPICE AMS Simulation

VHDL

VHDL-AMS

Matlab

SpecMan

Extensions

SystemVerilog

SystemC


P: 5

Chapter 2 User Guideline for AMSD Incisive Use Model

The AIUM has been streamlining: three-step (ncvlog/ncelab/ncsim), ncverilog and now irun.

The highlighted inputs to irun in “irun in IUS8.2” means necessary options, while the grey items are either not needed or not recommended. You may see the setup files are way down to the fewer. The irun and AMSCF (AMS Control File) are the major components in the simplification of use model. The AIUM could be as simple as, irun *.v amscf.scs –input probe.tcl -timescale 1ns/100ps

in which

“*.v” means the testbench and digital design part. It also could be *.vams

“amscf.scs” is the AMS Control File including analog and mixed-signal stuff.

In general, although most of the three-step options can be directly taken by irun, here is the recommended usage. Please refer to the chart above.

cds.lib

worklib

CM/Crule

modelpath

Prop.cfg

Probe TCL

discipline

timescale

Analog ctrl file

Digital Design/Testbench

Analog Design

Nc

vlo

g/n

ce

lab

/nc

sim

BDR

Hdl.var

cds.lib

worklib

-amsconnrules

modelpath

AMS Ctrl File

Probe TCL

discipline

timescale

Analog ctrl file

Digital Design/Testbench

irun

in IU

S8

.1

BDR

Hdl.var

Not needed

Not needed

Not recommended

Crule name CM customization

Moved to CB or *.scs for irun

Moved to “AMSD” BLOCK

NC stuff and no change

Moved to “AMSD” BLOCK

Moved to AMS CB

Moved to AMS CB

NC stuff and no change

-ams -ams Not needed


P: 6

• cds.lib: it is a must in three-step. Now is NOT NEEDED in irun

• worklib: it is a must in three-step. Now irun handles it automatically. the user DO NOT NEED to do anything special for it

• hdl.var: it is optional and convenient mechanism in three-step. For irun, even pure incisive side, it is not recommended anymore. Thus NOT NEEDED.

Note: if you apply the new irun form to your existing cases, the existing cds.lib/worklib/hdl.var may cause some error message. The suggestion is to remove them (or convert into appropriate irun options if necessary).

• CM/crule releated: Please see "The CM/Crule" section below

• modelpath: the device model file should be loaded through “include” statement in AMSCF (AMS Control File). Please see "The option of -modelpath" section below for more information.

• prop.cfg: this is completely replaced with “amsd” block. But is supported for backward compatible. See more info from "The option of -propspath" section below

• probe.tcl: NC stuff and no change

• analogcontrol file: it is recommended to be included “amsd” block. Of course, the user still can continue to use -analogcontrol option

• -discipline: Please refer to "The CM/Crule" section below

• timescale: NC stuff and no change

• BDR (setdiscipline): No change in IUS82

• -ams: This is a must in three-step. Now is not needed in AMS8.2. As long as your design has *.vams, or has spice config in “amsd” block, the tool will automatically add –ams option internally.

The following we'll talk about other important components.

The “amscf.scs”

This file uses spectre format (as seen of the extension name, .scs) that contains the following major contents:

1. Include analog stuff: spice netlist, device model and analog control file

2. Design configure (analog or digital)

3. Analog and Digital connection

4. Handling of A/D Connect Module and Connect Rules

In which, the item 2, 3 and 4 fall into “amsd” block with “amsd” keyword. So AMSCF contains analog stuff and “amsd” block. A typical AMSCF could be like:

* AMS Control file // comment line, ignored by analog solver ahdl_include ./source/veriloga.va //verilogA modules include ./source/design.scs //analog netlist include ./models/model.scs //device model file


P: 7

include ./amsControl.scs //analog control file //”amsd” block amsd {

portmap subckt=pll_top busdelim="_" //port map between A and D

config cell=pll_top use=spice //pll_top is configured as spice

ie vsup=2.0 tr=0.1n // automatically customize the CDS standard CM/Cruluse }

Basically, AMSCF consists of “amsd” block, ACF (Aanlog Control File) and “include” statements for analog stuff. This AMSCF is parsed by analog solvers (UltraSim or Spectre), except that the “amsd” block (“amsd”) block will be ignored (while it is taken by elaborator).

The CM/Crule

There are two new approaches introduced in IUS8.2, regarding the CM/Crule, “ie” card and “-amsconnrules” option to irun.

• "ie" card is recommended for the new users or new cases

o When the CDS installed CM/Crule is used, for example, you can add the following line in “amsd” block

ie vsup=1.8

The tool will automatically build the _full_fast rule with 1.8v. the user don't need to use -amsconnrules and -discipline options, and don't need to specify the CM path and to compile the installed CM/crule.

o When the user wants to customize the CDS installed CM/Crule, for example,

ie vsup=2.0 tr=0.1n

Similarly, The tool will automatically build the _full_fast rule with 2.0v and 0.1n. the user don't need to use -amsconnrules and -discipline options. Once the tool sees the "ie" card, it will automatically customize the appropriate *full_fast CM/crule and create a discipline in fly. You don't need to worry about any details behind. You will get a report in irun.log for all the necessary information.

o If the user doesn't want to use full_fast crule, which means they can't use ie card, you need to use -amsconnrules option to specify something else than full_fast.

• "-amsconnrules" is a new option introduced in IUS8.2 which allows you to specify which crule you want to use. This is recommended to the existing cases or users

o When one or multiple existing customized (user-defined) CMs/crules are compiled, the tool can automatic search for the discipline used in this design and pick the appropriate CM/Crule from the compiled database. All the necessary information about CM/Crule will be printed out in irun.log file. Nevertheless, the user is allowed to specify the crule using –amsconnrules as well.

o When you have existing cases which contains predefined discipline, you need use this -amsconnrules options and probably –discipline option as well. The reason why you can’t use ie card is because the ie card creates its own discipline name which may differ from the existing predefined.

• When the design has multiple supplies, the current BDR solution is still needed in IUS8.2. In the future "ie" card in “amsd” block will be extended for BDR too. See a BDR example,

in “amsd” block

amsd {


P: 8

portmap subckt=pll_top busdelim="_" config cell=pll_top use=spice ie vsup=1.8 ie vsup=3.3 instport="tb.vlog_buf.I1.in, tb.vlog_buf.I2.out" }

The tool will automatically customize the appropriate *full_fast CM/crule and create different disciplines in fly. You don't need to worry about any details behind. You will get a report in irun.log for all the necessary information

The option of -propspath

As mentioned, in IUS8.2, the prop.cfg file is completely replaced with “amsd” block. For the existing prop.cfg users, there is an internal translator available to help user to convert the prop.cfg file into “amsd” block format. To do so, the user needs to set the following env var:

setenv AMSCB YES

The tool will automatically translate prop.cfg into prop.cfg.scs (“amsd” block) and exit by issuing a graceful message telling user how to use “amsd” block. The user needs to check the “amsd” block contents to make sure that it is something expected. And re-launch irun using the recommended way.

The option of -modelpath

The device model should always be loaded through "include" statement in AMSCF. However the following situations need -modelpath

• When the design has device/macro model file which is in the form of verilog-ams.

Some foundries, like TSMC, provide such models. This is because that AMSCF file will be parsed by analog solver who, of course doesn’t know the verilog-ams format.

• When design has transistor-level verilog-AMS netlist


P: 9

Chapter 3 Basic Flow: verilog/ams + SPICE

The core of the AMSD Incisive Use Model is irun, which is supposed to be the replacement of ncverilog, but much more beyond that. The major benefits of irun are:

• irun supports a much broader mixed-language base than ncverilog • irun improves the easy-of-use in command-line verification flow • irun follows the verilog use-model (verilogxl/ncverilog/vcs) making it much easy to integrate AMS into

existing verification flows that a company has established Its key features include:

• Support Verilog, VerilogAMS, VHDL, VHDL-AMS, System Verilog, System C, Specman e, C, and C++ source files in the same command line

o Support Spectre (.scs) and HSPICE (.sp) as well o irun *.v *.sv *.scs

• File-extension based compilation • Fully back compatible with ncveirlog • Support both dash and plus options, but the dash option is recommended (e.g. -amsf instead of

+ncamsf) • Automatically determine the top-level unit from Verilog or SystemVerilog source files • Support SPICE-in-middle use-model • Instance-Based Binding support (planned) • “amsd” block support

Besides irun, another important component is AMSCF which was mentioned in last Chapter and will be discussed in the following Chapters as well. In this Chapter, we are going to use a simple example to walk you through most of the necessary steps for a typical AMSD irun. For more detailed information, you will be referred to a separate sections in this workshop.

3.1 How to build a AMSD case using irun + AMS Control File

Basically there are two common ways to build an AMSD mixed-signal case.

• Converting a existing pure digital case into AMS domain by replacing one or more digital blocks with HSPICE/spectre subckt (netlist)

• Stitching the existing digital verilog modules and HSPICE/spectre subckt together The example here used is the second way. This tutorial is under build_up/ directory.

3.1.1 The design information

This example case is a PLL circuit, including SPICE netlists, verilogA and Verilog code. These netlists or codes may come from analog or digital design community separately. The PLL consists of a VCO (Verilog-A module), a digital frequency divider, a digital frequency counter, a phase detector (PD), and a charge pump. The VCO generates eight 400MHz signals with different phases (p0, p45,


P: 10

p90, … , p315). One of the outputs (p0) is divided down by a factor of 2 before feeding into the phase detector (vcoclk). The other input to the phase detector is a 200MHz reference clock signal (refclk). When the two inputs to the PD are out-of-sync, the PD generates corrective pulses to adjust the differential output voltages of the charge pump (vcop, vcom), which control the frequency of the VCO. When the PLL is in lock, the signals vcoclk and refclk are in phase, and the VCO control signals v(vcop)\250C v(vcom) are stable.

The key signals are: testbench.refclk testbench.clk_p0_1x testbench.clk_p0_4x testbench.p1.vcom testbench.p1.vcop testbench.p0 Design files: SPICE netlist for analog, analog device model files and verilog modules for digital . |-- .solutions # Hidden directory for reference |-- analog # Analog (SPICE) netlist | |-- ChargePump.sp # Charge pump subckt | |-- Gates.sp # Basic gates | |-- PLL.sp # PLL circuit, including all analog blocks | |-- PhaseDetector.sp # Phase detector subcircuit | ‘—VCO.va # Verilog-A module |-- digital # Digital code | |-- counter.v | |-- divider.v | ‘—testbench.v # digital stimulus file ‘—models # Model directory

|-- bipolar.scs |-- diode.scs

CP (HSPICE

)

refclk VCO (VerilogA

)

PD (HSPICE

)

Divider (Verilog)

vcop

vcom

vcoclk

p0

up

down

Counter (Verilog)

vcoclk

Clock[2:0]

Pll_top


P: 11

|-- gpdk.proc |-- gpdk.scs |-- nmos1.scs |-- pmos1.scs ‘—resistor.scs

Note: PLL.sp includes PhaseDetector, ChargePump blocks in a HSPICE netlist, and a Verilog-A VCO.

3.1.2 Building the AMSD case

Action 1: Check the design files to see if they are complete and correct Action 2: Re-organize the design files to be neater by creating a “source” directory and moving the “analog” and “digital” into “source” % mkdir source % mv analog source % mv digital source Action 3: building the testbench The Testbench is one of the most important steps to build up an AMS case (in this case, the testbench file is ./source/digital/testbench.v). The major tasks include:

• Create a top level for this AMS case by connecting and instantiating the digital and analog components In this case, the digital instances (counter and divider) and analog instance (pll_top) are initiated and connected through the wires of vcoclk, clock_2, clock_1, clock_0, net036 and p0. Please refer to the solution file under .solutions/source/digital/testbench.v file.

• Create the stimuli to the DUT

In this case, the stimuli for reset and refclk are added.

• Monitor or self-check the output

Note, in the testbench file, you don’t have to declare the “electrical” discipline to any wires even they are connected to the ports of analog instances. And so you don’t need to include the disciplines.vams file either. The following a few Actions will introduce the necessary steps for setting up irun. If we look at the “Streamlining” graph from three-step to irun, the following inputs need to be given:

• AMS Control File • timescale • probe TCL

Action 4: Creating a run script


P: 12

For a convenient purpose, usually a “run” script is created for irun, which lists all the necessary options to it. For example, in this case, the “run” script looks like:

#!/bin/csh -f irun ./source/digital/*.v \ //dig testbench and design modules ./amscf.scs \ //AMS Control File -amsfastspice \ //fastspice (UltraSim) switch -timescale 1ns/100ps \ //timescale definition -input probe.tcl //probe TCL file

The following Action 5 and 6 are to create an amscf.scs, the AMS Control File Action 5: Creating “amsd” block by adding the information of A/D connection, design configuration and CM/Crule This step is very critical. Most of the important information in the migration from pure digital to AMS domain should be given accurately. Refer to the following “amsd” block.

amsd { portmap subckt=pll_top busdelim="_" config cell=pll_top use=spice ie vsup=1.8 }

The “portmap” card tells how a SPICE subckt interface appears to the elaborator, like bus connection, etc. In this case, pll_top subckt in PLL.sp needs to configure into verilog testbench (testbench.v). Note that bus delimiter “_” is specified. This is because in verilog counter.v file, there is a bus, out [2:0], declared, which needs to be mapped to clock_2, clock_1 and clock_0 in PLL.sp file. However there isn’t a bus, such a concept, in SPICE world. You need to tell the tool that the verilog bus of out[2:0] is mapped clock_x with the “_” as the bus delimiter. In this case “autobus=yes” is used by default. The “config” card specifies which binding you want to use for particular cells or instances. In this case, the cell of “pll_top” will be configured to “SPICE”. This card is an equivalence to the prop.cfg file in three-step approach. The “ie” card specifies interface element (or CM) parameters for a particular design unit. If you do not specify a design unit, the elaborator applies the parameter settings to all interface elements globally. In this case, since it is a single power supply, 1.8v is used for the whole design. Accordingly, the _full_fast Crule will be used automatically. More information about the “amsd” block, refer to section 3.4 about “amsd” block. Action 6: Creating AMSCF file by adding analog stuff along with the “amsd” block

* include "./models/resistor.scs" section=res include "./models/diode.scs" section=dio include "./models/pmos1.scs" section=nom include "./models/nmos1.scs" section=nom include "./source/analog/PLL.sp" include "./acf.scs" amsd { portmap subckt=pll_top busdelim="_" config cell=pll_top use=spice ie vsup=2.0e0 }

As you see, except “amsd” block, all the stuff is in spectre format. The first line is a comment line and will be ignored by analog solvers according to SPICE conventions.


P: 13

The include statements for resistor.scs, diode.scs, pmos1.scs and nmos1.scs are for SPICE device models. PLL.sp is the HSPICE netlist for pll subckt. acf.scs file the ACF (Analog Control File). Action 7: Creating ACF file, acf.scs The following is a typical analog simulation control file telling how UltraSim simulates this design.

*********************************** simulator lang=spice lookup=spectre *********************************** *--------------------------------------------------------* * UltraSim Analysis Options *--------------------------------------------------------* .tran 1ns 200ns *--------------------------------------------------------* * UltraSim Simulator Options *--------------------------------------------------------* *.probe v(*) .probe v(testbench.p1.vcom) v(testbench.p1.vcop)

The first half part is for UltraSim simulation controls. The simulation time in this example is set to 200ns. Once the simulation runs to 200ns, a finish signal will be sent to ncsim and the whole simulation will stop. The second half is for analog probing. The “.probe v(*) means save all the signals in analog domain. For more detailed information, refer to UltraSim User Guide. Often the ACF file comes along with the analog design from analog designer. Action 8: Probing on digital nodes TCL command is used for probing on digital nodes. Usually, a file called probe.tcl is created for the digital probing:

database -open waves -into waves.shm -default #probe -create -database waves -all -depth all probe -create -database waves testbench.refclk probe -create -database waves testbench.clk_p0_1x probe -create -database waves testbench.clk_p0_4x probe -create -database waves testbench.p0 #simvision -input simvision.sv run exit

The waveform for all the probed nodes will be saved in the database of waves.shm. This TCL file can be used not only for probing, but also for simulation controls. This is added to irun through the option, -input probe.tcl.


P: 14

From Action 7 and 8, you see that, in AIUM, the analog probing is controlled by the analog control file, acf.scs, while digital probing is controlled by probe.tcl file. Both analog and digital waveforms are saved into one common database, waves.shm, so that both analog and digital waveforms can be displayed in the same waveform viewers with a common time axis. Action 9: Invoking irun Run “run” script and use simvision to check the waveforms after the simulation is over. When issues occur, please check the irun.log file. Action 9: Checking irun.log file By default, an irun.log is created when you invoke irun. The following is an excerpt from it, with some important information which reflects your setting in “amsd” block.

ncelab: *N,SFEDPL: Deploying new SFE in analog engine. Top level design units: Testbench Discipline resolution Pass... Doing auto-insertion of connection elements... Connect Rules applied are: discrete_2__1_cr Building instance overlay tables: .................... Done Using implicit TMP libraries; associated with library worklib Generating native compiled code: connectLib.Bidir_2:module <0x624c0176> streams: 8, words: 5825 connectLib.E2L_2:module <0x6ecd33f0> streams: 7, words: 4604 connectLib.L2E_2:module <0x7f40398e> streams: 3, words: 1660 Loading native compiled code: .................... Done

“discrete_2__1_cr” is the Crule name automatically created by the tool from the setting of “ie” card in “amsd” block. Bidir_2, E2L_2 and L2E_2 are the Connect Module names used in your design. Action 10 (optional): Checking INCA_libs directory As you might notice, some setup files, that are required by three-step, like cds.lib, hdl.var and worklib, are not needed in irun. Irun automatically handles those in fly. After simulation is done, go to INCA_libs/irun.lnx86.08.20.nc, you will find some intermediate files.

– cds.lib

include ./cdsrun.lib

– cdsrun.lib SOFTINCLUDE /grid/cic/ams/ius82/pink/tools/inca/files/IEEE_vhdlams/cds.lib define worklib /home/daniell/ams/tut/build_up/INCA_libs/worklib

– in worklib directory

inca.connectLib/ inca.lnx86.166.pak


P: 15

Note: if there is a cds.lib existing, irun will take it, which may cause some unexpected warning/error messages Summary This section demonstrates how to prepare to run AMSD in command-line use model for a design based on SPICE netlists and Verilog modules, using irun, the single step, and AMS Control File. You would see the use model has been significantly simplified, compared to ncvlog/ncelab/ncsim three-step approach.

3.2 Digital Testbench Reuse in AMS domain

It is very common to convert an existing pure digital Incisive case into AMS domain by replacing one or more digital blocks with HSPICE/spectre circuit (netlist). This is a typical digital centric use model. However this use model often causes a question: can the pure digital testbench be reused by AMSD simulator? The reason why having such question is because the pure digital testbench often has some OOMR (Out Of Module Reference) which previously worked fine with all pure digital hierarchy but fails when it crosses the different domains between verilog and SPICE (OOMR SPICE) when some verilog modules is replaced with SPICE subckt. For example,

• force testbench.dut.timer.data[0] = 0

• if (testbench.dut.timer.data[0] ==1 ) counter = 0

• wire a=((testbench.dut.timer.data[0] === 1) || (testbench.duv.timer.data[1] === 0

• always @(posedge testbench.dut.timer.data[0] counter = 1

These cases above run fine in a pure digital sim, but error out in ncelab when the timer is switched to a SPICE netlist. This section will discuss how AMSD handles those scenarios in Incisive Use Models.

AMSD Incisive Use Model has two ways to handle the OOMR SPICE, based on the customer’s needs.

• Ignoring the OOMR SPICE or defaulting its value to “x”, instead of error out • Read/write the OOMR SPICE as in pure digital domain

The following two sub-sections will look into the two approaches. The lab is under tbreuse_ignDef directory.

3.2.1 Ignoring/defaulting OOMR SPICE

3.2.1.1 Ignoring the OOMR SPICE

The basic idea is to totally ignore all the OOMR SPICE, by assuming the user has other constructs or techniques to verify the mixed-signal simulation using the same digital testbench. Conservatively, the following digital behavior statements are allowed to be ignored:

• force/release • blocking/non-blocking assignment • $display/$monitor • if statement (including "else if" and "else") • continuous assignment • delay/event control expression


P: 16

Here is the procedures how the “ignoring” works in AMSD with the example of “tbreuse_igndef”. In this example, there is following verilog system task in ./source/digital/testbench.v file:

initial begin $monitor (testbench.pll_top.vcom); $monitor (testbench.pll_top.vcop); end

If it is a pure digital case, the OOMR of testbench.pll_top.vcom and testbench.pll_top.vcop worked fine. Now the pll_top is a SPICE subckt, which means the OOMR cross into SPICE domain. This won’t work any more if it as is. Action 1: Change directory to tbreuse_ignDef. Simulating it with the original testbench by executing “run” It should error out by issuing the following error message:

$monitor (testbench.pll_top.vcom); | ncelab: *E,CUVSOE (./source/digital/testbench.v,32|35): OOMR

'testbench.pll_top.vcom' refer into SPICE error. $monitor (testbench.pll_top.vcop); | ncelab: *E,CUVSOE (./source/digital/testbench.v,33|35): OOMR

'testbench.pll_top.vcop' refer into SPICE error. irun: *E,ELBERR: Error during elaboration (status 1), exiting.

Action 2: Modifying the testbench file, source/digital/testbench.v, by using the following two pragmas to open/close the ignored statements.

àms_testbench_reuse_ignore initial begin $monitor (testbench.pll_top.vcom); $monitor (testbench.pll_top.vcop); end ènd_ams_testbench_reuse_ignore

To do so, you may just uncomment out the two lines in testbench.v file in this example. // àms_testbench_reuse_ignore // ènd_ams_testbench_reuse_ignore

Action 3: Simulating it by executing “run” with the modified testbench The simulation should be finished successfully with the following warnings (instead of errors) during elaborating stage: $monitor (testbench.pll_top.vcom); | ncelab: *W,CUVSOW (./source/digital/testbench.v,32|35): The out-of-module-reference 'testbench.pll_top.vcom' refers to a SPICE block. Because the software detected the àms_testbench_reuse_ignore directive, it is ignoring the above statement. $monitor (testbench.pll_top.vcop); | ncelab: *W,CUVSOW (./source/digital/testbench.v,33|35): The out-of-module-reference 'testbench.pll_top.vcop' refers to a SPICE block. Because the software


P: 17

detected the àms_testbench_reuse_ignore directive, it is ignoring the above statement

3.2.1.2 Defaulting the OOMR SPICE

The basic idea is to default all the OOMR SPICE into 1’bx, by assuming the user has other constructs or techniques to verify the mixed-signal simulation using the same digital testbench.

The positive point of this idea is following case:

if ( top.SPICE.net == 1'b1 || top.verilog.net == 1'b1 )

The negative point of this idea:

if ( top.SPICE.net == 1'b1 ) $monitor(); else $monitor();

The second monitor will be always executed. The only difference from the “ignoring” approach is using the different pragma. Action 1: Edit source/digital/testbench.v to uncomment the two lines wrapping around initial segments to make it like

àms_testbench_reuse_default_value initial begin $monitor (testbench.pll_top.vcom); $monitor (testbench.pll_top.vcop); end ènd_ams_testbench_reuse_ default_value

Action 2: type ./run on command line. The simulation will be finished with the following warnings: $monitor (testbench.pll_top.vcom); | ncelab: *W,CUVSOD (./source/digital/testbench.v,32|35): The out-of-module-reference 'testbench.pll_top.vcom' refers to a SPICE block. Because the software detected the àms_testbench_reuse_default_value directive, it is setting the value in the above statement to "1'bx". $monitor (testbench.pll_top.vcop); | ncelab: *W,CUVSOD (./source/digital/testbench.v,33|35): The out-of-module-reference 'testbench.pll_top.vcop' refers to a SPICE block. Because the software detected the àms_testbench_reuse_default_value directive, it is setting the value in the above statement to "1'bx". Summary


P: 18

This is a very simple way to reuse the digital testbench. However, some testbench functionalities are lost. It is up to the end user deciding which approach to go, based on the real design.

3.2.2 Reading/writing OOMR SPICE

Compared to ignoring/defaulting, the biggest advantage of this approach is that the SPICE OOMR is still valid! However, it needs some minor modifications in the testbench, but without having to change the design. The basic idea is that, using a kind of “alias” instances converts the “logic” into “electrical” discipline within testbench, so that the “electrical” nodes can be connected to the SPICE nodes smoothly. The “alias” converters include:

• cds_spice_d2a: for a digital to analog connection from verilog to SPICE (i.e. digital drives) • cds_spice_a2d: for an analog to digital connection from SPICE to verilog (i.e. analog drives) • cds_spice_bidir: for a bidir connection between verilog and SPICE • cds_spice_a2a: for an analog to analog connection from verilog-AMS to SPICE (e.g., driving SPICE port

from top level) The following is the source code for the cds_spice converters.

//cds_spice.vams // // cds_spice_d2a causes a D2A IE to be inserted because its port dir is input module cds_spice_d2a(e); input e; electrical e; parameter spicenet = "null"; // Just a null body endmodule // cds_spice_a2d causes an A2D IE to be inserted because its port dir is output module cds_spice_a2d(e) output e; electrical e; parameter spicenet = "null"; // Just a null body endmodule // cds_spice_bidir causes a bidir IE to be inserted because its port dir is inout module cds_spice_bidir(e) inout e; electrical e; parameter spicenet = "null"; // Just a null body endmodule module cds_spice_a2a(e) input e; electrical e; parameter spicenet = "null"; // Just a null body


P: 19

endmodule

This cds_spice.vams file is installed in $AMS_INST_DIR/tools/affirma_ams/etc/cds_spice_alias. It must be pre-complied before used. Now let’s walk through the steps with the tutorial case of “tbreuse_rw”. In this example, there are a couple of verilog OOMR in pure verilog testbench, which are used for a system task of $monitor and force operation:

initial begin // pure digital configuration assign testbench.pll_top.buf1.a = a; assign y = testbench.pll_top.buf1.y; end initial begin $monitor (y); end initial begin # 1000 force a = 0; end

When the pll_top switches to SPICE, those OOMR crosses into SPICE and become OOMR SPICE. The following actions will display how AMSD makes the OOMR SPICE still valid. Action 1: Modifying the testbench file, testbench.v, by adding appropriate cds_spice aliases under the control of a macro Please see the following changes:

ìfdef OOMR_SPICE // AMS mode with OOMR SPICE cds_spice_d2a # ("testbench.pll_top.xi85.a") d2a1 (a); cds_spice_a2d # ("testbench.pll_top.xi85.y") a2d1 (y); èlse initial begin // pure digital configuration assign testbench.pll_top.buf1.a = a; assign y = testbench.pll_top.buf1.y; end èndif initial begin $monitor (y); end initial begin # 1000 force a = 0; end

Note:

• A cds_spice_d2a is added to the node “a”, with the instance name of “d2a1”. It means the “a” is represented to a truce SPICE hierarchical name: “testbench.pll_top.xi85.a” which is very different from the typical verilog hierarchy of “testbench.pll_top.buf1.a”. Especially in HSPICE (rather than spectre), all the instance name begins with “x”, as shown in this example. Similarly to node “y”.


P: 20

• Since “a” is a driving digital, a “d2a” is used. While “y” is analog driving, a “a2d” is used • A macro of “OOMR_SPICE” is used to switch on or off the OOMR SPICE. When this macro is defined

in irun command, the “a” and “y” will be aliased to SPICE hierarchy. Otherwise, to verilog ones Action 2: Creating the run script for irun This is the run script you need to create:

irun ./source/digital/*.v \ ./source/digital/cds_spice.vams \ ./amscf.scs \ -define OOMR_SPICE \ -amsfastspice \ -timescale 1ns/100ps \ -input probe.tcl

Note:

• The cds_spice.vams needs to be compiled. This may be automatically done by tools someday. • OOMR_SPICE macro is defined • ACF (AMS Control File) is used

Action 3): Run simulation by executing “run” script Action 4): Checking the IE report Check the irun.log file for the IE report section. The first two IEs are: ----------IE report ------------- Automatically inserted instance: testbench.a__L2E_2__electrical (merged): connectmodule name: L2E_2, inserted across signal: a and ports of discipline: electrical Sensitivity information: No Sensitivity info Discipline of Port (Din): logic, Digital port Drivers of port Din: (testbench.d2a1) input port 1, bit 0 (./source/digital/testbench.v:28) Loads of port Din: Load: VST_S_BLOCKING_ASSIGNMENT, Line 75, Index 0, in: testbench.a__L2E_2__electrical Discipline of Port (Aout): electrical, Analog port Automatically inserted instance: testbench.y__E2L_2__electrical (merged): connectmodule name: E2L_2, inserted across signal: y and ports of discipline: electrical Sensitivity information: No Sensitivity info Discipline of Port (Ain): electrical, Analog port Discipline of Port (Dout): logic, Digital port Drivers of port Dout: No drivers Loads of port Dout: No loads ----------------------------------


P: 21

The first IE is testbench.a__L2E_2__electrical which matches with the cds_spice_d2a with the instance name of d2a1, which can be verified by the Driver pin of testbench.d2a1. The second is testbench.y__E2L_2__electrical which matches with the cds_spice_a2d with the instance name of a2d1. However, since the driver is from SPICE, elaborator doesn’t have the information about the driver. Action 5): Checking the simulation result by simvision In the testbench.v, the nodes of “a” and “y” are the input and output of a SPICE buffer, xi85. You can check it in the source/analog/PLL.sp file. The “y” is connected to an output port of clk_p0_4x. When the “a” is forced to “0”, the “y” should be “0” accordingly. In turns, the clk_p0_4x becomes “0”. This can be verified by Simvision -> Open -> waves.shm:waves.trn, to check a, y, clk_p0_4x under testbench in Designer Browser. Action 6 (optional): Talking about an issue when the cds_spice is used When you use a cds_spice aliasing a port right on the boundary between verilog and SPICE, you usually use cds_spice_d2a or cds_spice_a2d. Please note, they are uni-directional cds_spice. However, in elaboration stage, all the boundary ports by default are treated as bi-directional internally. Thus they are conflicted. When doing the AICM (Auto Insertion of Connect Module), the elaborator will issue an error message like, ----------------------------------- Discipline resolution Pass... Doing auto-insertion of connection elements... pll_top p1(refclk, reset, vcoclk, clock_2, clock_1, clock_0, net036, p0, clk_p0_1x, clk_p0_4x); | ncelab: *E,CUVNAS (./source/digital/testbench.v,37|23): segmentation of a signal between analog ports is illegal -------------------------------------

The solution is to change the port direction in the automatically created portmap_file from “inout” to “input” or “output” according the actual cds_spice types you used. Then add the “file” option into the “portmap” card in “amsd” block. For example,

* include "./source/analog/PLL.sp" amsd { portmap subckt=pll_top autobus=yes file=”./portmap_files/pll_top.pb” config cell=pll_top use=spice }

More details about portmap file, please refer to section 3.3. Summary This testbench reuse approach is very powerful, since all the testbench functionalities still stay valid. However, it needs a certain modifications on testbench based the actual situation of mixed-signal hierarchy. Again, it is up to the end user deciding which approach to go, based on the real design.


P: 22

3.3 Verilog and SPICE Interoperation

Verilog to Spice connection is a necessary process for some typical structures in AMS Incisive flow, such as verilog-on-top and Spice-in-middle. It has to work properly to guarantee the signals are propagated between verilog and spice blocks as designer expected, even in mishap scenarios like mismatched ports size, reversed bus order, concated expressions and so on. The tutorials here demonstrate how to address these issues with current technologies in IUS82, and how to select appropriate methods in different situations. Here we put emphasis on two port connection problems: one is port expression and another one is port mapping. Port expression provides designer flexibility to combine different types of signals (like logic,reg,electrical,or even OOMR parameters) into one in the port list; While port mapping deals with connecting spice ports to corresponding verilog ports under certain rules set by the designer. The following sections describe these issues and show corresponding procedures/methods with four tutorials.

3.3.1 Port Expression

These connectivity combinations have been supported prior to IUS82: * digital concate expression, consisting of constant expressions, registers and digital nets connected to analog child ports. IEs are inserted across such as connection. This is the most basic feature for concate support.

* concat expression, consisting of constant, expressions, registers, digital nets and analog nets/slices, connect to analog, digital or mixed signal ports. IEs may be inserted across such a connection, if needed;

In IUS82, connectivity combinations are extended to multiple concat and other complex port expressions(including parameters) connected to analog, digital or mixed signal ports. They can be divided into three items: * Multiple/complex concats in port expressions

Digital Concats {2'b10, a, b}

Concat Expressions {2'b10, a, b, ana}

Multiple/Complex Concat Expressions {2{2'b10, a, b, ana}}

{{2'b10, a, b, ana}, {2'b10, a, b, ana}} {{2{2'b10, a, b, ana}}, a, ana, {b, a, 2'b01}}

{2{{2'b10, a, b, ana}, ana, {2'b10, a, b}}}

Parameters Expressions spice_block i1(c, top.I1.c);

OOMR on port Expressions spice_block s1(top.d1.r, top.d1.l, top.d1.p);

logic [0:1] a; reg [0:1] b; electrica ana;

parameter real c=1.0;

parameter p=2`b10; reg [2:3] r;

Basic, already supported prior to ius82

Supported in IUS82!!!


P: 23

* Parameter expressions * OOMR on port connection Please note all these features are for with SFE flow only. Here are the limitations for port expressions: * Recursive multiple concat is not yet supported. e.g., logic [0:1]a; reg [0:1]b; analog_child child6( {2{{2{a[1], 1'b1}},{2'b01,b}}} ); --� NOT SUPPORTED * concats with real parameter parts like parameter in_real = 5.0; analog_child child1( {2'b01, in_real} ); -�NOT SUPPORTED It will print error message "illegal type real concatenation sub-expression".

3.3.2 Port Mapping

Case mapping and bus connection are two important issues in Verilog to Spice port connection. Three types of port mapping methods are developed at different stages to meet designer's requirements. The very first one is -auto_bus which makes bus connection feasible in AMS and avoids the need to break all port bus signals into scalars. It is applied only for regular situation, that is, all buses are with ascending/descending order and all ports have uniform case mapping, so it is lack of flexibility on signal concat and upper/lower case specification for different ports. Then -portmap_file method is presented to address more accurate port mapping requirements and can be customized by the designer as wanted. That is to say, the designer needs to provide the port map file for the expected connection. Of course, as a general recommendation, designer can use -auto_bus first to generate portmap file(*.pb) automatically and then change to desired mapping for -portmap_file application. In case designer also has verilog version for spice block(usually verification is done first with verilog blocks then switched to spice level so this is common in AMS Incisive flow) he can use -reffile with -portmap_file together to generate port mapping automatically and then go straight on to simulation, since verilog ports specify all the corresponding ports for spice blocks in acceptable verilog format and designer does not need to write it manually. This also brings convenience for the leaf verilog blocks in Spice-in-middle situation.(The leaf verilog blocks connected to spice).

3.3.2.1 auto_bus

* Use Model: use include statement and portmap/config cards in “amsd” block (or sourcefile and source_opts properties in prop.cfg) to specify the spice file and subcircuits that are instantiated in the Verilog modules. Then use “irun <AMSCF>” to pass the ams control file to irun/ncelab(also could use “–propspath <path/prop.cfg> as before). for example, in “amsd” block *********************************** include “analog_top.sp” amsd{ portmap subckt=analog_top autobus=yes busdelim=”<>” config cell=analog_top use=spice } Please note: autobus=yes is already default in “amsd” block and you even don’t need to explicitly specify it. If with prop.cfg it can be cell analog_top { string prop sourcefile="analog_top.sp";


P: 24

string prop sourcefile_opts="-auto_bus -bus_delim <>"; } Where analog_top.sp contains .subckt analog_top p<0> p<1> p<2> p<3> p<4> p<5> ... .ends The busdelim/-bus_delim specify the delimiters you use. However if you are using "[]" or "<>" as bus delimiters you don't need to specify since they are recognized by default. But if you use busdelim/ -bus_delim options the default does not exist any more.

* List of sourcefile_opts property supports: (options for “amsd” block and prop.cfg source_opts) autobus/-aubo_bus | -no_bus : automatic bus mapping or no bus mapping. busdelim/-bus_delim empty | delimiters : empty indicates no bus delimiters. Multiple busdelim/-bus_delim option can be applied for multiple bus delimiters. excludebus/-exclude_bus : specifies ports to be excluded from consideration as buses. For example you want to exclude "net1 net2 net3" as buses, you can use in “amsd” block portmap autobus=yes busdelim=none excludebus=net (in prop.cfg: string prop sourcefile_opts="-auto_bus -bus_delim empty -exclude_bus net") input/output/-in_port | -out_port port_basename : Specifies the direction of a subcircuit port, allowing you to control the direction of an interface element that connected to the port of the spice block. This is useful because using interface element with uni-direction(input/output) may improve performance. By default all ports are treated as bi-directional. subckt/-subckt subckt_name : This option is used for instance or path-based binding to specify the name of the subcircuit which is master of the instance being bound. For example, the following options specifies instance binding in “amsd” block portmap autobus=yes subckt=sub1 config inst=xinst1 use=spice in prop.cfg it is inst xinst1 { string prop sourcefile_opts="auto_bus -subckt_sub1"; } casemap/-case_map lower|upper|keep : Specifies the handling for case mismatches when mapping ports between Verilog instantiations and spice subcircuit names. All letters are changed to lower_case | upper_case | unchanged. Please note this option controls the global handling of port mappings so it should be specified in the default binding section. Default is keep. reversebus/-reverse_bus : for the situation the bus order is reversed.

* Cell and Path/Instance based binding Besides cell based binding in prop.cfg, path/Instance based bindings for verilog to spice bus are also supported. In “amsd” block, these bindings are implemented by cell/inst=<full path to instance> in config card. But in prop.cfg cell/inst/path are used for specifying bindings respectively. For cell-based binding, all instances of the specified cell will be bound to the same property, for example: cell analog_top { string prop sourcefile="analog_top.cir"; string prop sourcefile_opts="-auto_bus -bus_delim <>"; } means all instances within subckt named "analog_top" will be bound with the above properties.


P: 25

Note: the cell name used in cell-based binding should be based on verilog instantiation. All instance or path-based bindings require -subckt option to specify the name of the subcircuit that is instantiated. For instance-based binding, all instances named will be bound with the same property, for example: inst top.xa1 { string prop sourcefile="analog_top.cir"; string prop sourcefile_opts="-auto_bus -bus_delim <> -subckt sub1"; } means all instances named xa1 which is instantiated in subckt sub1 will be bound with above properties. For path-based binding(occurance-based), full path for the instances must be specified. for example, path top.x1.xinv { string prop sourcefile = "analog_top.cir"; string prop sourcefile_opts = "-auto_bus -bus_delim <> -subckt sub1"; } means only top.x1.xinv which is instantiated from subckt sub1 will be bound with the above properties.

In IUS82, instance-based binding is supported in amsd block. Please note only full-path based instance for binding is acceptable with amsd block.

The following is the use model for instance-binding in amsd block: For Spice-at-leaf, it can be: portmap subckt=analog_top autobus=yes config inst=top.a2 use=spice

For Spice-in-middle, the cards can be portmap module=nand2 file=nand2.pb config inst=top.a1.x1 use=hdl

* Default binding In “amsd” block, the portmap cards will be applied to the blocks following this card if no subckts are specified. amsd{ portmap autobus=yes //this will set autobus=yes globally config cell=block1 use=spice //this will use autobus=yes config cell=block2 use=spice //this will use autobus=yes portmap autobus=no //this will set autobus=no globally config inst=block3 //will use autobus=no } User can also set a default binding for common properties within the default block in the prop.cfg file. For example, default values for the sourcefile_opts property can be specified using the following syntax: default { string prop sourcefile_opts="-auto_bus -bus_delim _"; } The above values of sourcefile_opts property will be applied to every cell, inst or path based sourcefile_opts binding specified later in the prop.cfg file. However, if a cell, inst or path based binding also specifies the sourcefile_opts property, then the local sorucefile_opts property will override the default sourcefile_opts property.


P: 26

3.3.2.2 reffile

One typical verification flow use model is that user runs through pure digital for whole design first and then selectively replace some blocks with spice view. In this case, the spice blocks have both spice and verilog versions. Therefore port mapping file can be created based on verilog file, through a binding option reffile. But if port mapping file exists it won't be created to avoid overwrite used specified port settings. For example: ********

include “analog_top.sp” amsd{ portmap subckt=ANALOG_TOP reffile=”analog_top.v” -�Here analog_top.v is verilog file config cell=ANALOG_TOP use=spice

} Please note here the keyword in control block is reffile for verilog file reference. But in prop.cfg it is -veri_file

3.3.2.3 portmap_file

With -auto_bus method there are still limitations on port mapping. For example, mixed case mapping and more complicated bus forms, like concats, mixed ascending/descending bus orders, are not supported. -portmap_file provides a more direct and elaborate solution on this, through a port_mapping file. The general format for port mapping file: Spice_port_name: verilog_port_name [dir=input|output|inout] The detailed format for port mapping

* For scalar nodes Node1 : NODE1

* For vector {myBus_0, myBus_1} : myBUS[0:1] * For a range of bus elements { busA[0] - busA[10] } : BusA[0:10] * For customized mapping of elements { busA[10] - busA[5], busA[0] - busA[4] } : busA[0:10] * Default rules for unspecified nodes or buses --- Port names match exactly (name-to-name), including casing --- Bus delimiters are [ ] and < > Here is an example for portmap_file and prop.cfg format: // The original verilog and spice files: // mrcg.v -- verilog top module mrcg (ext_clk, pll_clk); ANALOG_TOP xana_top(.Q_1(Q_1), .Q_2(Q_2), .IN2(pll_clk), .ITUNE(ITUNE), .IN1(ext_clk)); endmodule // analog_top.cir -- spice leaf .subckt analog_top q_1 q_2 IN1 itune_0 itune_1 in2 .ends analog_top

// analog_top.pb -- portmap file


P: 27

// amsd.scs ****** include “analog_top.sp” amsd{ portmap subckt=ANALOG_TOP file=”analog_top.pb” config cell=ANALOG_TOP use=spice }

In binding file mrcg.pb, the strings on the left column are actual names, or the port names in SPICE file. The

right column are the port names to be used in verilog skeleton file. Option "dir" is optional and it indicates the port direction. This is like a map-by-name approach and guarantees the correct mapping. There are also quick ways for the binding file:

* When the size of bus is huge. You may use range/subrange to express them, for example, {a[10], ..., a[5], a[0], ..., a[4] } can be rewritten as { a[10]-a[5], a[0]-a[4]}. * You don't have to list all the ports in binding file if their mapping comply with default rules as below(equal to -auto_bus setting): ---- The port name is exactly matched. ---- Bus delimiter is either [] or <>

* You can also define the default rules in binding options. For example the above port mapping file can be written as:

// amsd.scs ****** include “analog_top.sp” amsd{ portmap subckt=ANALOG_TOP file=”analog_top.pb” casemap=upper busdelim=”_” config cell=ANALOG_TOP use=spice }

// analog_top.pb -- binding file IN1 : IN1 dir=input in2 : IN2 dir=input Here the bus mapping {itune_0, itune_1} : ITUNE[0:1] is defined by the casemap and busdelim option. Please note portmap_file will take precedence over any other source file options, including autobus, busdelim, casemap etc.

:

:

:

dir=inout in1 IN1

dir=input Q_2 q_2

dir=input Q_1 q_1

Spice Port Separator Verilog Port Direction

:

:

dir=inout IN2 in2

dir=input ITUNE[0:1] { itune_0 , itune_1 }


P: 28

3.3.3 Generating port-binding file for name-dominant matching

Currently, for those cases with order-dominant ports, good portbind scratch is generated with option "reffile" (by-order mechanism). However, we need other binding approach to take care of those cases with name-dominant ports. One new parameter in portmap card is supported from IUS82: porttype. This parameter specifies which one of following approachs is ued to generate port-binding file for the interface between SPICE and Verilog:

(1) Port-binding-match-by-order (porttype=order) (2) Port-binding-match-by-name (porttype=name)

The default method is match-by-order, that is, porttype=order. When users have most ports in SPICE and Verilog with same names but order of ports is not matched or messed up and it is difficult to match ports by hand. In this situation, porttype=name is recommended to generate more accurate port-binding file. For example for the following test case: // top file "top.v" module top (); wire a1, b1; reg [0:1] c1; ana_spice_middle xana_spice (.a(a1) , .b(b1), .c(c1)) endmodule // spice middle level "ana_spice_middle.sp" .subckt ana_spice_middle a b c_0 c_1 xnand1 nand2 a c_0 c_1 b .ends // leaf hdl_cell module "nand2.v" module nand2 (a_veri, b, c); reg [0:1] c; endmodule // corresponding subckt for hdl_cell "nand2" .subckt nand2 a_spice c_0 c_1 b ... .ends

In this case, we expect to achieve binding as below.

Inst xand1: a c_0 c_1 b | | | | subckt nand2: a_spice c_0 c_1 b | | | | | module nand2: a_veri c[0] c[1] b

For the case above, the default port-binding by order does not work well since most of them are not with matched positions. So use the following AMSD control block:

// work.scs .include "./ana_spice_middle.sp" amsd{ portmap subckt=ana_spice_middle autobus=yes config cell=ana_spice_middle use=spice portmap module=nand2 reffile=nand2.v porttype=name config cell=nand2 use=hdl }


P: 29

The above AMSD block works in this way: for each master SPICE port, check whether there is "relevant" port existed in reffile "nand2.v". If found, it would be the right column of portbind file. Otherwise, keyword "not_found" is used.

Thus, for this case, it will generate following portbind scratch file.

// portbind file a_spice : not_found {c_0, c_1} : c[0:1] b : b

Note: If parameter option "reffile" is missing, Verilog-source file with the same of HDL (extension is ".v") is supposed to be used implicitly. For this case example, implicit verilog file name is "nand2.v". The implicit file is used to generate halfbind file. Once this implicit file doesn't exist or can't find relevant HDL module in the implicit file, error message would be report as below. ------ ERROR: Could not find the matching Verilog file "nand2.v" for 'cell=nand2' in the 'config' statement (line # 7) in the AMSD control block. Specify a valid reference file by adding a 'portmap' statement containing 'module=nand2' and 'reffile' and try again.

The scratch file can be manually modified to reflect expected mapping: // portbind file: ./portmap_files/nand2.pb a_spice : a_veri {c_0, c_1} : c[0:1] b : b Then re-run the simulation with modified port-binding file: // work.scs .include "./ana_spice_middle.sp" amsd{ portmap subckt=ana_spice_middle autobus=yes config cell=ana_spice_middle use=spice portmap module=nand2 file=./portmap_files/nand2.pb config cell=nand2 use=hdl }

3.3.4 Tutorials

This section contains four tutorials: The first one is port_expression, and the other three are for port mapping: -auto_bus, -portmap_file and -reffile. Please follow instructions to go through experiments. Also please set up $AMSHOME to IUS82 before starting. For example: setenv AMSHOME /grid/cic/ams/ius82/pink set ams_path = ( $AMSHOME/tools/bin ) set path = ( $ams_path $path) Notes: all tutorials here will be with irun/ams control file/AMS-Ultrasim SFE. Since analog control file is a new feature(also introduced in other tutorial) some replaced old files like prop.cfg are still kept. For each tutorial command "run" will be for ams control file and "run_propcfg" for prop.cfg. For setting AMSU new SFE, use setenv AMSU_NEW_SFE YES All labs are under VerilogToSpice directory.


P: 30

3.3.4.1 Tutorial I: port_expression

This tutorial is to demonstrate some port expression types supported in current IUS82, including multiple concat, recursive concat, concat inside multiple_concat, oomr on port and parameter expressions and so on. Action 1: Change to tutorial I directory cd VerilogToSice/port_expression/ Action 2: Open test.vams file, you can see the top module is top which instantiates five analog child blocks: analog_child child1( {{a, b, c, 2'b10}, {d,c,a, b, 2'b10}} ); analog_child child2( {{a, {2{b, 2'b10}}}, {a, b, 2'b10}} ); analog_child child3( {{top.d1.r, top.d1.p, top.d1.l, top.d1.l}, {top.d1.r, top.d1.p, top.d1.l, 2'b10}} ); analog_child child4( {2{top.d1.r, top.d1.p, top.d1.l, top.d1.l}} ); dummy d1(); analog_child child5( {{2{2'b10, 2'b10}}, {2'b10, in_bit, in_bit, 2'b10}} ); Here child1 is with recursive concat, child2 with multiple concat inside concat, child3 is for multiple concat expression with oomr on port, child4 with multiple concat including oomr expression, child5 is with multiple concat inside concat. Note: Recursive multiple concat is not supported. Like the commented child6 line: //analog_child child6( {2{{2{a[1], 1'b1}},{2'b01,b}}} ); which has multiple factor outside multiple/recursive. Action 3: open run command, the run options is like: #! /bin/csh -f irun \ amscf.scs \ -amsfastspice \ -iereport \ ./test.vams \ -timescale 1ns/1ns \ -input probe.tcl Action 4: start the run by ./run Action 5: check irun.log you can see the inserted connect modules at ports. Please note the connect modules for constant expressions like: Automatically inserted instance: top.\Exp0=2'b10__L2E__electrical (merged): connectmodule name: L2E, inserted across signal: Exp0=2'b10 and ports of discipline: electrical Sensitivity information: No Sensitivity info Discipline of Port (Din): logic, Digital port which uses "Exp0=2'b10" at the position of signal names. Also check the ports inside concats, a lot of L2Es are inserted due to logic to electrical connection. Action 6: go to top.shm/ directory and start simvision to check if all port signals are with correct values. Also check if oomr on ports returns correct values. Action 7: clean up the directory by ./clean_up


P: 31

Summary: After finishing this tutorial you will learn what kind of port expressions can be applied to facilitate port connections.

3.3.4.2 Tutorial II: auto_bus for verilog to spice connection

This tutorial shows how auto_bus works for port connection from verilog to spice, this is only for the regular ports connectivity with uniform case mapping(lower,upper or kept same as original) and identical bus order(ascending/descending). Also other necessary options are introduced to work with auto_bus. Instance-based binding as a new feature in IUS82 is also shown in this tutorial. The same cell is set to SPICE view for top level instance(Spice-at-leaf) but set to Verilog view for the instance inside Spice subckt(Spice-in-middle). They are implemented in amsd block. Prior to the Verilog to SPICE bus connection enhancement, Verilog vector buses connected to SPICE subcircuits had to be broken down into scalar ports and the nets had to be passed by order. For example, module verilog; wire [0:5] v; analog_top xana_top ( v[0], v[1], v[2], v[3], v[4], v[5] ); endmodule .subckt analog_top p<0> p<1> p<2> p<3> p<4> p<5> ... .ends Often, this breakdown process required time-consuming manual editing, especially for vectors of large number of bits. With the support for Verilog to SPICE bus connections, AMS Designer simulator now allows Verilog bus to be connected to SPICE scalar ports directly. Making port connections to bus by name is also supported. This design uses a DLL circuit that includes both a digital part (Verilog modules) and an analog part (a SPICE netlist). To see the circuit schematic, open dll.pdf. Key signals are the following: dll.clk_in dll.comp dll.ld dll.bit[5:0] dll.clk_out

Design architecture . |-- dll.pdf # Circuit structure |-- clean_up # Clean created files, use to rerun the case |-- models # Model directory | |-- n_p6.pm3 | `-- p_p6.pm3 |-- probe.tcl # tcl file for saving signals |-- amscf.scs # ams control file |-- run # Run script for irun with ams control file |-- simvision.sv # Simvision config file for showing waveforms |-- source # Include all source files | |-- analog # Analog netlist | | `-- dll_spice.sp | |-- digital # Verilog source code | | |-- dll.vams | | `-- sar6bit.v | | `-- div4.v `-- acf.scs # Analog control file including options of AMS


P: 32

Instructions to run the tutorial Action 1: Set AMSHOME environment. Set AMSU_NEW SFE to YES. Then Change to VerilogToSice/auto_bus/ directory. Type vi source/digital/dll.vams To view the dll.vams file and examine the Verilog to SPICE bus connection. Note the bit[5:0] at line 15. Also note there are four instances inside top module. The first instance is I_dll_spice which will be applied with autobus for bus connection. The second instance I_SAR6BIT is one block inside DLL circuit. The third and the fourth ones are two instances of div4 cell. In the following we will see how there two instances are set to SPICE or Verilog views with amsd block. Action 2: Close the dll.vams file without saving. Action 3: Open amscf.scs and can see the equivalent statements in control block for the options in prop.cfg ******* include "dll_spice.sp" include "acf.scs" amsd { ie vsup=5 portmap subckt=dll_spice autobus=yes busdelim="<>" config cell=dll_spice use=spice portmap subckt=div4 config inst=dll.Idiv4_spice use=spice portmap module=div4 reffile="source/digital/div4.v" config inst=dll.I_dll_spice.XI69 use=hdl }

This file is AMS control file(AMSCF). The first line is comment line for complying with general spice file format. And first include statement specifies spice subckt file and second is analog control file for analysis. It can be seen inside amsd{} block autobus/busdelim are specified. Also ie card is used for passing connect module parameters. The second portmap/config card pair is for specifying the div4 instance Idiv4_spice at top level is with SPICE view, while the third portmap/config pair is used to set the view for div4 instance XI69 inside I_dll_spice to Verilog view. Both of them are with full paths. Action 4: Type ./run to run the design with the irun/ams control file. The simulation is finished and you can see a generated directory portmap_files/ containing a file dll_spice.pb under it. This portmap file can be used for port mapping if it meets your requirements. Open this file you can see there is one row: { bit<5>, bit<4>, bit<3>, bit<2>, bit<1>, bit<0> }: bit[5:0] dir=inout

which is generated by the autobus rule. Action 5: Check the results in waves.shm with simvision. Also check the signals inside Idiv4_spice, Idiv4_behav and I_dll_spice.XI69, the first one is with SPICE signals and the other two are with Verilog signals. Compare input and output of these instances to see how clock is divided by 4 and which one is with digital signals and which one is analog. Action 6: Close the simvision window. And type clean_up to clean the created files.


P: 33

Summary: After completing this tutorial, you have been introduced to how to use autobus/-auto_bus and other options for regular verilog to spice connection. Also understand how instance-based binding are set with amsd block.

3.3.4.3 Tutorial III: portmap_file for verilog to spice connection

This tutorial demonstrates how to use a port mapping file to specify port mapping at digital/SPICE boundaries in ams control file(or -portmap_file option in prog.cfg). Note: You cannot connect a port/net in SystemVerilog directly to a SPICE port. You specify the port mapping file using the portmap in “amsd” block(or -portmap_file option in prog.cfg). Test Case Information In this tutorial, you will simulate a PLL circuit that contains five major blocks: * Voltage-controlled oscillator (Verilog-A module) * Phase detector (SPICE) * Charge pump (SPICE) * Divider (Verilog) * Counter (Verilog) The top-level test bench is a Verilog module that instantiates a spice block pll_top. Inside pll_top, the VCO outputs eight evenly-spaced 400 MHz clocks, 45 degree phase apart from each other. One output clock then passes through a divider and feeds back into the phase detector (vcoclk). The phase detector (PD) compares the incoming clock signal with the VCO output clock and produces either an up or a down signal to control the charging or discharging of the charge pump (CP). As a result, the PD either raises or lowers the VCO output clock frequency to bring it back in sync with the incoming clock. When the feedback loop becomes stable, the VCO frequency is locked to that of the incoming signal. The design/test bench structure is as follows: Verilog (on top) | | SPICE (PLL) | |----------------------------------|----------------------------------|---------------------------------------| VerilogA (VCO) SPICE (PD & CP) Verilog(divider) Verilog (counter) The simulation directory/file structure is as follows: ------------------------------------- . |-- clean_up # clean-up script |-- models # model directory |-- pll_top.pb # port mapping file |-- probe.tcl # Tcl script for saving signals |-- simvision.svcf # SimVision config file |-- amscf.scs # “amsd” block |-- prop.cfg # config file |-- run # run script with irun/ams control file |-- run_propcfg # run script with irun/prop.cfg |-- source # source file directory | |-- analog # analog netlist | | |-- ChargePump.sp # Charge Pump in SPICE | | |-- Gates.sp # Buffer in SPICE | | |-- PLL.sp # PLL in SPICE | | |-- PhaseDetector.sp # Phase Detector in SPICE | | `-- VCO.va # VCO in Verilog-A | `-- digital


P: 34

| |-- counter.v # counter in Verilog | |-- divider.v # divider Verilog module | `-- testbench.v # top-level test bench Verilog module `-- acf.scs # analog control file Running the Tutorial Action 1: Change to VerilogToSice/portmap_file/ directory. Look at the SPICE-in-the-middle configuration in the tutorial test case and browse through the Verilog modules in the source directory. Action 2: Open amscf.scs file which shows how portmap file is used here:

*********** include "./source/analog/PLL.sp" include "./models/resistor.scs" section=res include "./models/diode.scs" section=dio include "./models/pmos1.scs" section=nom include "./models/nmos1.scs" section=nom include "acf.scs"

amsd{ ie vsup=1.8 portmap subckt=pll_top file="pll_top.pb" config cell=pll_top use=spice portmap module=divider reffile="./source/digital/divider.v" config cell=divider use=hdl

portmap module=counter reffile="./source/digital/counter.v" config cell=counter use=hdl } Action 3: Open the source/digital/testbench.v file and review the pll_top instantiation: It is a SPICE netlist instantiated at the middle level. The clk_out port index is from 0 to 1 and RESET is in upper case. --------------------------------------------------------- wire [0:1] clk_out; pll_top p1 (.refclk(refclk), .RESET(RESET), .P0_CLK(clk_out)); ------------------------------------------------------------- Close the file and open source/analog/PLL.sp to look at the pll_top subcircuit definition: --------------------------------------------------------- .subckt pll_top refclk reset p0_clk_1 p0_clk_0 ------------------------------------------------------------- The reset port is in lower case and the bus bits order is from p0_clk_1 to p0_clk_0. The port mapping with the parent Verilog block would be incorrect without special handling. You use the port mapping file to correct this issue. Open the pll_top.pb port mapping file to see how: --------------------------------------------------------- refclk : refclk dir=inout reset : RESET dir=inout {p0_clk_1, p0_clk_0} : P0_CLK[0:1] dir=inout ------------------------------------------------------------- Of the three columns in the file, the leftmost column shows the actual port names in the SPICE file, the middle column shows the corresponding port names in the Verilog file, and the rightmost column indicates the port direction (which is optional).


P: 35

Action 4: Open the run script. Note that irun supports dash options just like the three-step method (ncvlog/ncelab/ncsim). Based on file extensions, irun passes the source files listed on the command line to the appropriate compiler along with the dash options.

#!/bin/csh -f irun \ -messages \ -amsf \ -access +rw \ -timescale 1ns/100ps \ -iereport \ -DRESOLUTION \ amscf.scs \ -input probe.tcl \ ./source/digital/*.sv \ ./source/digital/*.v

In the comment session of the run script, you can see the equivalent (and more involved) three-step method commands. Action 5: Run the script to start the simulation: ./run The run script goes through compilation and elaboration, then opens SimVision and simulates the design to completion. Several key signals appear in the SimVision waveform window. Action 6: To close the SimVision window, select File - Exit SimVision. Action 7: Run the clean-up script to remove simulation-generated files: clean

3.3.4.4 Tutorial IV: reffile for port mapping

The test circuit is same as the one in tutorial III, but difference is that verilog file is set up for the spice block. So port mapping will look up the verilog ports interface to help create port map file. Action 1: Change to VerilogToSice/veri_file/ directory. Open source/analog/PLL.v you can see there is a simple verilog definition for pll_top. This file will be used to generate the port mapping between the actual spice block(in source/analog/PLL.sp) and top verilog test bench. Action 2: Take a look at source/digital/testbench.v, there is one instance p1, which is defined in SPICE. Open source/analog/PLL.sp, search counter subckt definition: .subckt counter out[2] out[1] out[0] asynch_reset clock .ends counter This is a dummy SPICE definition(empty inside) which is necessary for SPICE-in-middle portbinding. Compare the port order here with source/digital/counter.v, it is with different port order but same port name: module counter (asynch_reset, clock, out); So for this cell(counter) you need to use porttype=name to generate right port binding file. Similarly compare the definition of another cell divider in Veirlog and SPICE, it can be used with porttype=order(default). Action 3: Open amscf.scs:


P: 36

*********** include "./source/analog/PLL.sp" include "./models/resistor.scs" section=res include "./models/diode.scs" section=dio include "./models/pmos1.scs" section=nom include "./models/nmos1.scs" section=nom include "acf.scs" amsd{ ie vsup=1.8 portmap subckt=pll_top reffile="./source/analog/PLL.v" config cell=pll_top use=spice portmap module=divider reffile="./source/digital/divider.v" config cell=divider use=hdl portmap module=counter reffile="./source/digital/counter.v" porttype=name config cell=counter use=hdl

}

Also it can be seen all model files/sections are included in this file. Look at portmap cards, there are three reffiles are used for portbinding reference. Action 4: Run the simulation by typing ./run Action 5: Check the generated portbind files under portmap_files/ directory. The port binding for counter is: { out[2], out[1], out[0] } : out[2:0] asynch_reset : asynch_reset clock : clock You can see it is correctly bound as expected even they are not with same port order. Also check other binding files for other two cells: pll_top and divider, which are correctly mapped by default porttype=order. Action 6: The simulation could go through now and you can check the output waveforms. Action 7: Clean up the run directory. ./clean_up

Summary Through theses tutorials you can see how different expressions could be applied at verilog to spice connection and how different port mapping methods could be selected by using reffile/portmap/config option in “amsd” block. You can also learn how porttype is applied to help generate correct port binding files.

3.4 SPICE-in-Middle Tutorial

This tutorial demonstrates how to use the AMS Designer simulator capability of using a Verilog-AMS block to instantiate a SPICE block that, in turn, instantiates a Verilog-AMS block. This is termed SPICE-in-middle. This capability is now supported with control block in AMS Incisive flow in IUS82. The AMS Designer Simulator Supports SPICE-in-Middle A mixed-signal simulation tool needs to support many different block configurations. One particular combination is the ability for a Verilog-AMS block to instantiate multiple SPICE blocks that, in turn, instantiate Verilog-AMS blocks. This is termed SPICE-in-the-middle. In IUS82, amsd block with portmap and config cards is used to support this capability. In “amsd” block, this can be implemented as


P: 37

amsd{ portmap subckt=subckt1 config cell=cell1 use=spice portmap module=cell2 reffile=”$cell2_path/cell2.v” config cell=cell2 use=hdl } Where cell2 is a verilog module instantiated in spice block. Note: The port mapping between Spice and leaf Verilog can be controlled by a parameter in portmap card, porttype. The default setting is porttype=order(meaning order-based port mapping) but it can be switched to name based mapping when setting up porttype=name. Design Information This tutorial design is a PLL circuit that includes a digital part (Verilog-AMS modules) and an analog part (SPICE netlist, Verilog-A module). The PLL consists of a VCO (Verilog-A module), a digital frequency divider, a digital frequency counter, a phase detector (PD), and a charge pump. The VCO generates eight 400MHz signals with different phases (p0, p45, p90, ... , p315). One of the outputs (p0) is divided down by a factor of 2 before feeding into the phase detector (vcoclk). The other input to the phase detector is a 200MHz reference clock signal (refclk). When the two inputs to the PD are out-of-sync, the PD generates corrective pulses to adjust the differential output voltages of the charge pump (vcop, vcom), which control the frequency of the VCO. When the PLL is in lock, the signals vcoclk and refclk are in phase, and the VCO control signals v(vcop) \250C v(vcom) are stable. The design architecture is as follows: TB1_pllDivider_stimuli module <-- Verilog at top level pll_top subckt <-- SPICE netlist at middle counter and divider modules <-- Verilog at bottom level The PLL_top subckt includes PhaseDetector, ChargePump blocks with a SPICE netlist, and the Verilog-A VCO. Key signals are the following: TB1_pllDivider_stimuli.refclk TB1_pllDivider_stimuli.clk_p0_1x TB1_pllDivider_stimuli.clk_p0_4x TB1_pllDivider_stimuli.p1.vcom TB1_pllDivider_stimuli.p1.vcop TB1_pllDivider_stimuli.p1.xi19.p0 Testcase Architecture . |-- clean_up # Clean created files, use to rerun the case |-- models # Model directory |-- probe.tcl # tcl file for saving signals |-- simvision.sv # SimVision config file |-- run # run script |-- source # Include all source files | |-- analog # Analog netlist | | |-- ChargePump.sp | | |-- Gates.sp | | |-- PLL.sp | | |-- PhaseDetector.sp | | ‘-- VCO.va | ‘-- digital # Verilog code | |-- counter.v


P: 38

| |-- divider.v | ‘-- stimuli.vams ‘-- amscf.scs # AMS control file including AMS options Running the Tutorial To run this tutorial, Action 1: Be sure AMS Designer is set up and ready to run. Action 2: Type vi source/digital/stimuli.vams to examine the top-level Verilogams module. Note the instantiation of the pll_top module pll_top p1(refclk1, reset1, clk_p0_1x, clk_p0_4x); The pll_top module is a SPICE subckt. Action 3: Quit from the stimuli.vams module without saving. Action 4: Type vi source/analog/PLL.sp to examine the SPICE netlists. Note the following two instantiations in the plldivider_g17 subckt. .subckt plldivider_g17 ... ... xi116 reset vcoclk clock_2 clock_1 clock_0 counter xi20 vcoclk net036 p0 reset divider ... .ends plldivider_g17 These two lines instantiate Verilog modules. At this point, the structure that constitutes the SPICE-in-the middle is visible. The Verilog module, stimuli.vams instantiates a SPICE netlist, pll_top. The pll_top SPICE netlist instantiates subcircuit plldivider_g17, which, in turn, instantiates two Verilog modules called counter and divider. Action 5: Quit from the PLL.sp file without saving. Action 6: Type vi amscf.scs to examine the AMS control file.

*********** include "./source/analog/PLL.sp" include "./models/resistor.scs" section=res include "./models/diode.scs" section=dio include "./models/pmos1.scs" section=nom include "./models/nmos1.scs" section=nom include "acf.scs" amsd{ ie vsup=1.8 portmap subckt=pll_top config cell=pll_top use=spice

portmap module=divider reffile="./source/digital/divider.v" config cell=divider use=hdl

portmap module=counter reffile="./source/digital/counter.v” config cell=counter use=hdl }

The cell and use statements specifies which cell to use verilog or spice formats. So this control file shows pll_top is with spice but divider and counter are with verilog formats, actually they are instantiated in the spice block. Action 7: Quit from the amscf.scs file without saving. Action 8: Type ./run to run the case by using the run script.


P: 39

Action 9: Check the portmap_files directory, there are three *.pb files generated, they are for the portmapping of top verilog-ams, leaf divider and counter verilog blocks, respectively. Action 10: Type ./clean_up to remove all the files created during the simulation. Summary This tutorial illustrates how to use the SPICE-in-middle feature, including the properties that are required.

3.5 “amsd” block

As briefly introduced earlier, “AMSD” BLOCK is being adopted as a single mechanism which allows the user to add all the aspects of AMS elaboration and simulation in AIUM. It is another important step to simplify the AMSD Incisive Use Model (besides irun).

3.5.1 “amsd” block Advantage

• The vision for 'amsd' control block is that a new command line user should be able to specify all the basic AMS options to the tool using a single approach and not worry about the complexity of Verilog-AMS language, connectrules, ncelab options, envvars etc. Hence, a simple, cleaner and scalable way in terms of usability. The prop.cfg or ncelab command line was not scalable enough to meet this goal.

• The prog.cfg was also felt to be a cumbersome and confusing language in terms of syntax and specifications. The 'amsd' control block uses the Spectre language format which is more popular and widely acceptable to community within and outside Cadence.

• It works on the new SFE (Simulation Front End) technology hence is more closer to the simulation engine and powerful enough to work on complex designs. Hence, user can put AMS and analog options together. The prop.cfg has another way to specify analog options which require re-implementation.

• It uses an improved and efficient binding algorithm instead of OCCprop/HDB lookup. Used as an opportunity to clean up, unify and improve the performance of ncelab, BDR and other chunks of code.

• The 'amsd' block provides necessary precondition for irun -update working with AMS hence giving a key elaboration performance benefit in single step flow.

• Works in cases where existing prop.cfg flow had its own limitations. For example, provides a capability for users to specify the combination of cell and instance based properties in the same design configuration (cell and instance).

3.5.2 Prop.cfg to “amsd” block migration

To the new users or new cases, the approach of “amsd” block within AMSCF is recommended. However to the existing users or cases, “amsd” block is an alternative to the prop.cfg flow. Either prop.cfg or “amsd” block can be used depending on how the user set. For example, % irun –propspath prop.cfg // traditional way: prop.cfg is used % irun amscf.scs // new way: “amsd” block within AMSCF is used There is an environmental variable which can be used to control the migration of prop.cfg flow to “amsd” block flow. Once the following variable is set:


P: 40

% setenv AMSCB YES Elaborator will automatically translate the existing 'prop.cfg' file to 'prop.cfg.scs' “amsd” block file, and the user will be required to switch to “amsd” block flow.

3.5.3 “amsd” block cards and syntax

AMS statements must appear only in an AMSD control block:

amsd {

AMS_statements }

The following sections will introduce more details for the individual amsd cards.

3.5.4 “portmap” card

The portmap statement tells the AMS Designer simulator how a SPICE subcircuit interface should

appear to the elaborator.

portmap subckt=name [parameter=value...]

Valid parameter=value assignments for the portmap statement are as follows:

subckt Name of a SPICE subcircuit to which to apply these portmap settings.

Valid Values: Any valid subcircuit name.

Autobus Indicates whether to map Verilog buses to SPICE ports.

Valid Values:

yes Map Verilog buses to SPICE ports.

no Do not map Verilog buses to SPICE ports.

Default: yes

busdelim List of bus delimiters.

Valid Values: [], _, <>, or none

Default: [] <>

Casemap Specifies casing for name mapping .

Valid Values:

upper Map all names to uppercase.


P: 41

lower Map all names to lowercase.

keep Maintain name casing as it is.

Default: lower

portcase Specifies casing for port names.

Valid Values:

upper Map all port names to uppercase.

lower Map all port names to lowercase.

keep Maintain port casing as it is.

Default: keep

file Name of the portmap file containing customized port mappings.

Reffile Name of the reference file containing customized port mappings. You must also specify

the format of this file

refformat Specifies the format of the reffile (currently, the software supports only the verilog

format).

Valid Values:

verilog Verilog format

excludebus List of entities not to map because they are not buses.

No default.

reversebus Specifies the reversebus name. No default.

stub Name of the cell for which you want to use the stub version; you must also specify a

match assignment.

match Specifies which definition to use when matching the interface. The match assignment

applies only when you also specify stub on the portmap statement and use=stub on the

config statement.

Valid Values:


P: 42

verilog Use the Verilog interface

spice Use the SPICE interface

Default: verilog

input Specifies a net as an input port. No default.

output Specifies a net as an output port. No default.

inout Specifies a net as an input and output port. No default.

In the following example, the analog_top.cir file contains the subcircuit definition for ANALOG_top.

The portmap statement tells the elaborator not to map Verilog buses to SPICE ports (autobus=no) and

not to change the case mappings between Verilog-AMS instantiations and SPICE subcircuits

(casemap=keep). The config statement tells the elaborator to bind the ANALOG_top cell as a SPICE

subcircuit; the analog_top.cir file contains the master.

include "analog_top.cir" // SPICE or Spectre format include file amsd { portmap subckt=ANALOG_top autobus=no casemap=keep config cell=ANALOG_top use=spice }

Global Portmaps

Any portmap statement for which you have not specified a subckt parameter applies to all portmap

statements that follow it. In this way, these portmap statements are global as the software applies the

settings to all subcircuits.

Here is an example of how you might apply global portmaps:

amsd { portmap autobus=yes // apply autobus=yes globally config cell=block1 use=spice // this subcircuit will use autobus=yes config cell=block2 use=spice // this subcircuit will use autobus=yes config cell=block3 use=spice // this subcircuit will use autobus=yes config cell=block4 use=spice // this subcircuit will use autobus=yes portmap autobus=no // apply autobus=no globally from this point config cell=block1 use=spice // this subcircuit will not use autobus }

Portmap Ordering

The last relevant portmap statement determines the settings the software uses when creating interfaces

to cells and instances bound to SPICE (config ... use=spice).

In the following example, two instances of the pll subcircuit cell have different portmaps:


P: 43

amsd { portmap cell=pll autobus=yes config inst=top.foo.pll_one use=spice portmap cell=pll autobus=no config inst=top.bar.pll_two use=spice }

3.5.5 “config” card

The config statement specifies which definition you want to use (bindings) for particular cells or

instances.

config use=definition [parameter=value...]

Valid parameter=value assignments for the config statement are as follows:

cell One or more names of cell references in the NC HDLs for which you want to use the specified

definition (use=definition).

If you specify more than one cell name, you must use double quotation marks around the list:

config cell="subA subB subC" use=spice config cell=dsp use=hdl

inst Full hierarchical path to one or more names of instance references in the NC HDLs for which

you want to use the specified definition (use=definition).

config inst=I1.I2 I1.I3 use=hdl config inst=X1.X4 use=spice

use Specifies which definition you want the simulator to use.

Valid Values:

hdl Use the HDL definition

spice Use the SPICE definition

stub Replace the specified cell with a stub version (which has the same interface but no

content); you must specify a cell parameter assignment; you can specify a match choice

of verilog or spice in the portmap statement for the stub

No default. You must specify a use assignment.

You must specify either a cell or an instance or both. If you specify both, the

instance must be an instance of the cell.

Here are some examples:

amsd { config cell="subA subB subC" use=spice config inst=I1.I2 use=spice


P: 44

config cell=dac use=hdl } amsd { portmap stub=pll match=spice // SPICE stub config cell=pll use=stub portmap stub="worklib.analog_top:module" match=verilog // Verilog stub config inst=top.xana_top4 use=stub } include "analog_top_1.cir" include "analog_top_2.cir" amsd { config cell="analog_top_a analog_top_b analog_top_c analog_top_d" use=spice } include "analog_top.cir" amsd { portmap stub=analog_top match=spice // SPICE stub config inst=top.xana_top2 use=stub portmap subckt=analog_top autobus=yes // SPICE subcircuit config inst=top.xana_top3 use=spice portmap stub=worklib.analog_top:module match=verilog // Verilog stub // You can alternatively assume lib=worklib and view=module for irun with // AMSD control block and use the following simplified form for the stub: // portmap stub=analog_top match=verilog config inst=top.xana_top4 use=stub }

3.5.6 “ie” card

The ie statement specifies interface element parameters for a particular design unit.

Note: If you do not specify a design unit, the elaborator applies the parameter settings to all interface

elements globally.

ie vsup=supplyValue [scope=scopeValue] [parameter=value...]

where vsup=supplyValue is a mandatory parameter that specifies the final real value for logical 1.

The software automatically builds the _full_fast connect rule with the voltage supply level you

specify; you do not need to use -amsconnrules and -discipline options; you do not need to specify

the connect module path or to compile any connect modules. The software also applies any

parameter=value customizations you specify, automatically, and writes information to the irun.log

file.

If you do not specify a scope assignment, the scope is global. Any customizations you specify apply to

domainless nets only. Valid scope=scopeValue assignments are as follows:

inst Full hierarchical path to one or more names of instances to which you want to apply the


P: 45

specified interface element parameters. If you specify more than one name, you must

separate each name with a space and enclose the string in double quotation marks. For

example:

ie vsup=4.5 inst="tb.vlog_buf tb.vlog_buf1 tb.vlog_buf2"

cell One or more cells to which you want to apply the specified interface element parameters. If

you specify more than one name, you must separate each name with a space and enclose the

string in double quotation marks.

instport Full hierarchical path to one or more names of instance ports to which you want to apply

the specified interface element parameters. If you specify more than one name, you must

separate each name with a space and enclose the string in double quotation marks. For

example:

ie vsup=1.2 instport="a b c"

cellport One or more cell ports to which you want to apply the specified interface element

parameters. If you specify more than one name, you must separate each name with a space

and enclose the string in double quotation marks.

net One or more net names to which you want to apply the specified interface element

parameters. If you specify more than one name, you must separate each name with a space

and enclose the string in double quotation marks.

lib Library of design units to which you want to apply the specified interface element

parameters.

Valid parameter=value assignments for the ie statement are as follows:

vthi Voltage value above which the simulator assigns a logical 1. The simulator determines the

default value from the connect rule.

vtlo Voltage value below which the simulator assigns a logical 0. The simulator determines the

default value from the connect rule.

vx Final real value for logical x. The simulator determines the default value from the connect rule.

tr Rise time for analog transition, from vtlo to vthi or vx.

Default Value: 0.2 ns

rout Output resistance.

Default Value: 200 Ohms

rlo Output resistance for L2E when digital input is 0.



P: 46

rhi Output resistance for L2E when digital input is 1.


rx Output resistance for L2E when digital input is x.


rz Output resistance for L2E when digital input is z.

Default Value: 10M Ohms

mode Mode for discipline application.

Valid Values:

set The simulator forces the global supply discipline on all domainless nets in the design.

default The simulator uses the global supply discipline as the default discrete discipline on

domainless nets when discipline resolution does not resolve a domainless net to the

analog domain.

In the following example, all digital nets that connect to analog in the top.I3 scope have interface

elements with vsup=4.5 and tr=1.2; all other nets use the global value, vsup=5.0:

amsd { ... ie vsup=5.0 ie inst=top.I3 vsup=4.5 tr=1.2n }

Here is another example showing how you can specify more than one instance (scope) to use the same

discipline:

amsd { ... ie vsup=4.5 inst="testbench.vlog_buf testbench.vlog_buf1 testbench.vlog_buf2" }

3.6 Spice-on-top in AIUM Flow

3.6.1 Introduction

AMS has been used to simulate designs with behavioral module(Verilog/ams, vhdl/ams etc.) as the top block, which may underneath embrace or refer to analog netlists (SPICE,HSpice,Spectre etc.). The benefits of this convention are internal, that is, one uniform tool(or digital tool) is used to resolve/elaborate the design by calling analog parsers(like Spectre, Ultrasim) and simulate the system by synchronizing digital inputs/outputs with results from analog simulation engine. As a result, the AMS tool has been more naturally for Verilog(ams)-on-top(or VHDL),


P: 47

in which Verilog/ams descriptions are always the starting point of the design and analog netlists are more like “foreign” parts, no matter how huge their size is.

Inevitably this propensity of AMS tool brings about inconvenience for some designers/users. From designers’ view, each circuit system can be either digital or analog dominated. For large digital systems, like digital signal processing(DSP), CPU(like ARM), FPGA, they contain thousands/millions of digital behavioral statements for the design as DUT(Design-under-Testing) and large number of initialization/testing-vector generation statements at top, accompanied with small block of analog netlists embedded somewhere in the design(like A/D interfaces). This is a natural fit for the AMS tool(as shown in below graph,left side). However, other than that, a lot of designs are analog-dominated, which have only small part of digital functions. Illustrated on the right side of below graph, it is an audio/power amplifier, its top have a bunch of SPICE statements, including voltage sources, current sources, bandgap power blocks, and a small digital block for feedback control. The task of adopting AMS onto the design for analog designers can be troublesome as behavioral modeling/coding is likely another unfavorable world for them so minimum interaction with digital contents is highly desired. For example, previously in order to use AMS tool on SPICE-on-top test cases the designer need to add dummy Verilog at top of their design and wrap all distributed SPICE devices into subckt form, to make them recognizable/acceptable by the tool. Even this tiny modification can change the database structure, make hierarchies of OOMR signals wrong and cause the hierarchical probing not to work any more.

Now the new SPICE-on-top feature has been implemented to fill in this gap. It makes the tool ambidextrous to be capable of reading in and processing both combinations of SPICE and Verilog/ams netlists(either on top) with minimum extra efforts from users, especially for the designs migrated into AMS from pure analog solver. Using this new SPICE-on-top feature, the designers can reuse all design settings as they are with analog engine, like probing, stitching, dc initialization on hierarchical signals etc. The task of mixed-signal simulation is reduced to only necessary work including adding digital source files into design, the hdl statements into amsd block and digital options into irun command(like –timescale), more like a plug-and-play mode.


P: 48

This tutorial is to show how a PLL test case can be configured as SPICE-on-top structure and be run with AIUM flow. As one important update, a default option of auto using reffile is introduced and demonstrated in the tutorial.

3.6.2 Testcase information

This tutorial at the top level is the SPICE netlist for a PLL, which instantiates one Spice block, multiple analog primitives, voltage/current sources and digital stimulus from Verilog source file. At the bottom level there are Verilog blocks and Spice blocks instantiated in middle-layer Spice block.

The structure for this case is:

3.6.3 Configuration and Run Instructions

(1) Setup the AMS environment, for example

setenv AMSHOME /grid/cic/amscm_v1/ams/ius92/lnx86/pink/

set path= ($AMSHOME/tools/dfII/bin $path)

setenv LD_LIBRARY_PATH $AMSHOME/tools/lib:$AMSHOME/tools/inca/lib:$AMSHOME/tools/simvisdai/lib:$AMSHOME/uvlib:$AMSHOME/tools/dfII/lib

(2) Take a look at the Spice file source/analog/PLL.sp, at top level there is one Spice instance of PLL circuit:

xi19 clk_p0_1x clk_p0_4x ibias net038 net034 net027 net033 net026 net032 net025 net031 refclk reset net030 vcom vcop setic0! vdd! 0 plldivider_g17

Following that is an instance of Verilog module to generate inputs of PLL circuit:

xstimulus refclk reset TB1_pllDivider_stimuli

Correspondingly there is dummy SPICE definition for this Verilog module:


P: 49

.subckt TB1_pllDivider_stimuli refclk reset

.ends TB1_pllDivider_stimuli

Its definition is inside a Verilog source file(source/digital/stimulus.v).

The other components are analog primitives and voltage/current sources.

(3) Trace down the Spice subckt of plldivider_g17, look for two digital blocks instantiated inside this subckt: counter and divider. These two blocks are defined with Verilog modules(source/digital/counter.v and source/digital/divider.v). To make Verilog ports connected to Spice nets properly, add these two dummy Spice definitions into Spice netlist(source/analog/PLL.sp)

.subckt counter reset vcoclk clock_2 clock_1 clock_0

.ends counter

.subckt divider vcoclk net036 p0 reset

.ends divider

(4) Compose amsd block and control file.

The power supply is 1.8V so we have

ie vsup=1.8

For two Verilog blocks instantiation, portmap/config cards are used:

portmap module=counter

config cell=counter use=hdl

portmap module=divider

config cell=divider use=hdl

portmap module=TB1_pllDivider_stimuli

config cell=TB1_pllDivider_stimuli use=hdl

Note there is a new technology used here. Before IUS92 it needs reffile for Verilog modules in Spice to be specified in portmap cards(otherwise there must be corresponding .v file at current directory). Now with IUS92, as long as the Verilog file(same name as the module) is compiled at irun command line, this necessity disappears as internally the compiled Verilog file is automatically used as reffile.

(5) After composing amsd control block, add include statements for analog control file and Spice netlist file at beginning(source/analog/PLL.sp) to complete ams control file.

(6) Write irun run script.

This is a Spice-on-top case and -spicetop option is needed. Other options are same as before. Here is the complete run script:


P: 50

irun ./source/digital/*.v -spicetop -modelpath "./models/resistor.scs(res):./models/diode.scs(dio):./models/pmos1.scs(nom):./models/nmos1.scs(nom)" -amsfastspice -timescale 1ns/100ps -iereport amscf.scs -input probe.tcl

(7) Run simulation and check irun.log logfile and waveform in Simvision window.

Note the following info in log file:

Top level design units:

xi19

Currently in Spice-on-top case AMS takes the first instance name as snapshot name and top level design unit name as well. So there is message in log file too:

Writing initial simulation snapshot: worklib.xi19:spice_skeleton

Also note in design brower part of Simvision window, there is one item called cds_ams_spice_top_connect, under which all connect modules at top level are saved.

3.6.4 Critical Steps for SPICE-on-top Configuration

Here listed are the summarized key steps on what need to do when converting a SPICE test case into AMS SPICE-on-top:

(1) List all Verilog(ams) blocks to be embedded in SPICE netlist, compose corresponding dummy SPICE definitions for proper port connections. For instance, in the above tutorial case, the stimulus is from module TB1_pllDivider_stimuli (./source/digital/stimuli.v), it has dummy SPICE definition in the SPICE netlist (./source/analog/PLL.sp). Otherwise, irun will hit into unexpected error during amsd block processing.

(2) If there is vcd file in original SPICE netlist, it can be kept intact in SPICE-on-top configuration; However, if vcd file is not generated yet and the Verilog(ams) source for vcd file is ready, the user can instantiate the Verilog(ams) module directly in SPICE netlist without generating vcd file, as AMS has more customized setting on the interface between digital drivers and SPICE nets (for example,driving strength, rising/falling time etc.);

(3) Add statements for each Verilog(ams) module into amsd block; Similarly, if SPICE subckts are instantiated in Verilog(ams) module, entries in amsd block are also needed; As the improvement, top SPICE netlist does not need to be wrapped as a subckt any more;

(4) For the Verilog modules instantiated in SPICE netlist, try to use identical file names as their module names; This will take the advantage of auto using reffile;

(5) For signals probing, all .probe statements in original SPICE netlist can be kept; For probing digital signals or connect modules, add commands into tcl file.

(6) Add –spicetop option into irun command; Together add Veirlog(ams) source files,–timescale, -amsf, -input, -gui options when needed;

3.6.5 Limitations

(1) SPICE-on-top does not support direct vhdl(ams) instantiation at top netlist yet;


P: 51

(2) The snapshot name is usually the first instance name in SPICE netlist; It looks weird but is a unique name;

(3) .lprobe is not supported for signals probing in SPICE-on-top netlist;

(4) Some case has vec/vcd stimulus applied onto SPICE nets which are actually instance ports of Verilog(ams) modules, it may cause large number of unnecessary connect modules due to the back to back connection(L2E and E2L for each port); We have an internal selection for optimization to address this issue(check with Cadence).

3.6.6 Summary

This tutorial is purposed to show how the new SPICE-on-top feature works, including how to combine SPICE/Verilog blocks, configure amsd block, add irun command line options and follow the overall procedure of migrating a pure analog SPICE case into AMS SPICE-on-top structure for mixed-signal simulation. Other than that, limitations are enumerated for the aspects that are not covered by SPICE-on-top. As a counterpart of testbench reuse when transferring from a pure digital test case into AMS, the SPICE-on-top can be a very beneficial method of reusing numerous analog/SPICE setting/checking/probing functions, while only minimum work need to be done for introducing the digital/behavioral contents into the design.

3.7 Prop2cb_Stubview

There are two parts of contents covered in this section: (1) How ams control file is converted/created from 3-step flow with prop.cfg; (2) How stub view is set up in amsd control block.

3.7.1 Prop2cb translator To facilitate the migration from 3-step prop.cfg flow to irun flow with AMS control file, this procedure is developed to translate prop.cfg to AMS control block:

(1) Set up env variable AMSCB to YES; (2) Run 3-step with prop.cfg. It will generate a new file prop.cfg.scs; (3) Set up AMSCB to NO; (4) Modify prop.cfg.scs to the contorl file you need; (5) Run irun with the modified control file;

With this translation, general prop.cfg settings like sim_mode and speed, stub view and file/reffile port-

binding propties in prop.cfg can be converted into corresponding statements in AMS control file. For example, for prop.cfg file,

cell transmitter { string prop sourcefile="./source/analog/transmitter.scs" ; string prop sim_mode="a"; } cell receiver { string prop sourcefile="./source/analog/receiver.scs" ; string prop sim_mode="a"; string prop speed="1"; } It will be translated to prop.cfg.scs: include "./source/analog/transmitter.scs"


P: 52

include "./source/analog/receiver.scs" *ultrasim usim_opts sim_mode=a #transmitter *ultrasim usim_opts sim_mode=a speed=1 #receiver amsd { portmap subckt=transmitter config cell=transmitter use=spice portmap subckt=receiver config cell=receiver use=spice }

3.7.2 Stub View Stub view replaces one block inside design with a empty stub module but keeps interface and discipline declarations as same as before stub. This is a useful method to help identify which block slows down simulation by eliminating it from design even you can probably see unexpected simulation results. One example for use model of stub view in amsd block is like: amsd { portmap stub=dll_spice autobus=yes config cell=dll_spice use=stub } Please note that stub is used as one parameter in portmap card while as one value for the parameter use in config card. 3.7.3 Tutorial This tutorial uses same design as in auto_bus under VerilogToSpice/ directory. It firstly demostrates the procedure to translate prop.cfg into prop.cfg.scs(ams control file), then shows how stub is used in amsd block. Action 1: Change to prop2cb_stubview/ directory. Action 2: Take a look at prop.cfg file. The property settings on cells are:

cell dll_spice { string prop sourcefile="./source/analog/dll_spice.sp"; string prop sourcefile_opts="-auto_bus -input spice -bus_delim <>"; string prop sim_mode="a"; string prop speed="1"; } cell SAR6BIT { string prop sim_stub="worklib.SAR6BIT:module"; }

Action 3: Set environment variable AMSCB to YES. Action 4: Type ./run_3steps to run prop.cfg flow.


P: 53

Action 5: Check the generated prop.cfg.scs file. Add analog control file and ie card into it. Here is the file amscf.scs for reference for irun use: (you can rename your file to amscf.scs after change)

* // --- This file is auto-generated by prop2cb translator include "./source/analog/dll_spice.sp" include "acf.scs" amsd { ie vsup=5 portmap stub="worklib.SAR6BIT:module" match=verilog config cell=SAR6BIT use=stub portmap subckt=dll_spice busdelim="<>" autobus=yes config cell=dll_spice use=spice } *ultrasim usim_opts sim_mode=a speed=1 #dll_spice

Please note the syntax of stub view setting in amsd block. Action 6: Set environment variable AMSCB to NO. Action 7: Rename cds.lib to cds.lib.org. Rename hd.var to hdl.var.org. irun will not need these two files for its simulation. Clean up worklib and other INCA directory by type ./clean. Action 8: Start simulation with ./run_irun. This script uses the amscf.scs file as AMS control file. Action 9: It can seen there is one file SAR6BIT.stub_vams generated which is an empty module. Check the waveform in Simvision. The bit[5:0] are all 0 since there are no outputs from SAR6BIT. Action 10: Close Simvision window and clean up the directory.

3.8 AmsKeywords

This tutorial demonstrates how to use the keywords selection feature of the Virtuoso AMS Designer simulator. This feature allows you to select an active set of keywords, which can help you to avoid keyword clashes. It takes about 10 minutes to complete this tutorial. The AMS Designer Simulator Allows You to Select the Active Set of Keywords When mixing the Verilog-AMS and Verilog (digital) languages together, the use of different sets of keywords sometimes cause errors. Wire names used legally in the Verilog language turn out to be identifiers or keywords in the Verilog-AMS language. For example, the defined port name sin in Verilog refers to the sinusoidal function in Verilog-AMS. You can use sin as an identifier in a Verilog module, by adding the statement: `begin_keywords "1364-2001" in the Verilog file before the module. This statement sets the parser keywords to be strictly the Verilog 2001 keywords so that all the Verilog-AMS keywords such as sin, cos, and discipline are not recognized as keywords. Inserting the `end_keywords keyword after the Verilog module resets the keyword list to contain Verilog-AMS keywords


P: 54

again.

3.8.1 Design Information

This tutorial case is a simple test case, including a Verilog (digital) module and a Verilog-AMS module. Testcase Architecture . |-- amscf.scs #ams control file |-- clean_up # Clean created files |-- run # Run script |-- source # Includes digital source files | |-- ams_module.vams | |-- dig_module.vams | -- top.v -- acf.scs # Analog control file, including simulator options

3.8.2 Running the Tutorial

To run this tutorial, Action 1: Be sure AMS Designer is set up and ready to run. Action 2: Type run to launch the script file that runs the design. Compilation fails with the error messages file: ./source/dig_module.vams parameter sin = "hello"; // uses an AMS keyword as an identifier! | ncvlog: *E,FNDKWD (./source/dig_module.vams,5|12): A Verilog keyword was found where an identifier was expected. $strobe("%s",sin); | ncvlog: *E,EXPLPA (./source/dig_module.vams,7|22): expecting a left parenthesis ('(') [4.2(AMSLRM)]. module worklib.digital_module:vams errors: 2, warnings: 0 Action 3: Type clean_up to remove the generated files. Action 4: Open ./source/dig_module.vams, uncomment line2 and line12 so that it begins like this. `begin_keywords "1364-2001" .... `end_keywords indicating that only the subset of Verilog-AMS keywords that are included in the 1364_2001 standard are to be recognized as keywords. Action 5: Save and quit from the file. Action 6: Type run to relaunch the script file that runs the design. The error messages are gone and the design runs because sin is no longer considered


P: 55

a keyword. Action 7: Type clean_up to remove the generated files.

Summary This tutorial illustrates how to use the keywords selection feature in the AMS Designer verification flow and how to resolve a similar issue when the Verilog (digital) and Verilog-AMS languages are mixed.

3.9 Spice Encryption in AMS Simulation

Encryption with spectre_encrypt is already supported in standalone mmsim tools. This tutorial talks about running with encrypted spice/spectre file in both AMS-Ultrasim and AMS-Spectre simulation. The tutorial is under irun_encrypt/ directory. The following two parts describe the use models for running AMS with encrypted spice file.

3.9.1 AMS-Ultrasim encryption

Action 1: Set up IUS82 environment. Also set up AMSU new SFE by % setenv AMSU_NEW_SFE YES

Action 2: Open run file and here is command: irun test.vams ./cds_globals/verilog.vams -amsf -amsconnrules ConnRules_5V_full -errormax 50 -discipline logic -timescale 1ns/1ns -messages -status -delay_mode None -novitalaccl -access +rwc -iereport -dresolution -propspath props.cfg -input amsControl_tran.tcl -simcompat spectre -analogcontrol amsControl_tran.scs *********************************************************************

Please note here it is using -propspath props.cfg because AMSCB is not yet supported for encryption. *********************************************************************

Action 3: Open props.cfg it points to one spice file instantiated in verilog: cell top string prop sourcefile="./vco.scsp" ; *********************************************************************

Please note source_opts are not yet supported for encryption. ********************************************************************* Here vco.scsp is an encrypted spice file.

Action 4: Open vco.scsp file: //////////////////////////////////////////////////////////// simulator lang=spectre ahdl_include "moscap.va" ahdl_include "multiplier.va" include "function.scs"


P: 56

global 0 parameters vcon=1.5 rpc=0.1 rrr=500k StopTime=1u model bsim3p bsim3 kf=3.6e-20 vth0=-0.87 type=p capmod=1 model bsim3n bsim3 kf=3.6e-20 vth0=0.87 type=n capmod=1 //pragma protect begin_protected //pragma protect data_method = RC5 //pragma protect data_keyowner = Cadence Design Systems. //pragma protect data_keyname = CDS_KEY //pragma protect data_block EVa7/f+6KcIuj1YAwEoUnDiLYKNBabvIcD5G/+WfwTu3TNpZaxv08UWT313x/uHV gVSFXMbLDK6QpGQ2VUh3GMXcZ75rpZjyBnnSIWUZiMmrhLJdVC5qx5fFFyA4uTaL gcYLzSXX71Z22Y9T939pWnlesWgqCnwAb7skL3WM/EaHaP4AqRWAZSs7V5Ow4qMc iHr7g6f+4Fvx6CSS+IqZkJ8mTwD1Mgx8ml80bzz3Adr2zaUKqLwZzg7E51llPgym 9OEhtDfPnK8DbqJfaEhamZrECe4R7l+YyBYZjdoGyglOn3cg8vFouDdy62UzXBog RRoSFj5L0yVWM6TBUXXvTwsM0tcGeros0xy4TboLJ5v1dnFBmY0ieK9rV8IrmMt+ ...... //pragma protect end_protected ///////////////////////////////////////////////////////////////////// The bottom part of this file is generated by spectre encryption.

Action 5: (optional): To see how encryption file is generated, use following command to do the experiment(Assume you have mmsim binary path installation/set up)

% spectre_encrypt -i vco.scs -o myvco.scsp then open myvco.scsp to see which part is encrypted inside.

Action 6: Run the simulation by type % ./run It finishes simulation successfully. Then in irun.log you can see in Device Model Statistics part: All OTHERS (including encrypted models): 31 31

Action 7: clean up and move waves_tran.shm to a new directory: % ./clean_up % mv waves_tran.shm waves_tran_amsu.shm/ This waveform will be used to compare with AMS-Spectre run results in next part.

3.9.2 Run AMS-Spectre Encryption

Action 8: Edit run and remove -amsf option: irun test.vams ./cds_globals/verilog.vams -amsconnrules ConnRules_5V_full -errormax 50 -discipline logic -timescale 1ns/1ns -messages -status -delay_mode None -novitalaccl -access +rwc -iereport -dresolution -propspath props.cfg -input amsControl_tran.tcl -simcompat spectre -analogcontrol amsControl_tran.scs

Action 9: Run AMS-Spectre Encryption by typing


P: 57

% ./run Now analog solver is with Spectre so it needs longer time to finish simulation.

Action 10: Open Simvision tool to compare the results from AMS-Ultrasim and AMS-Spectre runs.

Action 11: Close Simvision windows and clean up the run directories.

Summary

After experiments in this tutorial, you can learn how the encryption is supported in AMS and its use model/current limitations.

3.10 Common Power Format (CPF)

The Power Forward Initiative is an industry-wide effort to establish a single standard format for specifying all power-specific design, constraint, and functionality requirements for a design. This new standard, called the Common Power Format (CPF), captures all design and technology-related power constraints in a single file. The CPF file acts as the sole repository for all power-related information from design through verification and implementation.

3.10.1 Introduction of CPF

CPF is a strictly Tcl-based format. The CPF file is a power specification file. This implies that the functionality of the design does not change when sourcing a CPF file. The CPF file complements the HDL description of the design and can be used throughout the design creation, design implementation, and design verification flow. For more information about the syntax and use of the Common Power Format, see the following reference:

• Low-Power Simulation Guide • Common Power Format Language Reference

• Common Power Format User Guide

3.10.2 CPF in AMS Designer

An example of CPF in AMS is described in Figure 3.9.1. The design contains 4 blocks: Inst_A, Inst_B, Inst_C, and PM. Two power domains are defined, Inst_A belongs to Power Domain 1 (PD1) and Inst_C belongs to Power Domain 2 (PD2). Inst_B is an analog block connected with Inst_A. PM is a power manager module. The power control signals PD1_ctrl, PD2_ctrl, are correlative with PD1 and PD2 respectively via the CPF file. They can turn on or shut off the controlled power domain.


P: 58

Figure 3.9.1 CPF in AMS

AMS Designer supported AMS and CPF co-exist. In IUS8.1 it only supported pure digital blocks which do NOT directly/indirectly interact with analog blocks. Since IUS8.2, it supports digital blocks which interact with analog blocks through Power-Smart Connect Module (Power-Smart CM). Simulator identifies the CPF influence on analog blocks and auto-inserts “Power-Smart” CM, which carries the effect of digital Power ShutOff (PSO) onto analog blocks. The effect is also programmable for users.

3.10.3 Running AMS Designer Simulator on CPF tutorial

Testcase Information:


P: 59

Figure 3.9.2 CPF Testcase

In this tutorial, you will simulate a mixed-signal circuit that contains three 8-bit registers (verilog), two adders (verilog), a DAC (verilog-a) and a RC Low Pass Filter (SPICE), shown in Figure 3.9.2 CPF Testcase. There are five power domains defined in the design.

• default_pd: is the power domain with whole design scope.

• pwr_pd: contain two registers pwr_inst1 and pwr_inst2 and an adder.

• pwr_inst1_pd: is a sub power domain defined onto pwr_inst1.

• dig_pd: defined onto top_inst2.

• ana_pd: is a power domain contained analog circuits.

The input signal ‘data’ latch in pwr_inst1 and add to $random, then the result adds with ‘data’ again. The output of second adder is sent to ana_adc. The signal converted to analog pass a RC LPF out. The simulation directory/file structure is as follows: -------------------------------------------------------------------------- ./ |-- clean_up # clean-up script |-- probe.tcl # Tcl script for saving signals |-- amscf.scs # “amsd” block and analog circuits included |-- run # run script with irun/amss control file |-- run_amsu # run script with irun/amsu control file |-- source # source file directory | |-- analog # analog netlist | | |-- ana.sp # analog top module | | `-- ana_dac # 10-bit DAC in Verilog-A


P: 60

| `-- digital #digital netlist | |-- ams_pm.cpf # CPF file | |--ana_child.vams # wrapper Verilog-AMS module | |-- pmc.v # power manager Verilog module | |-- pwr.v # one power domain Verilog module | |-- Reg_8.v # 8-bit register in Verilog | `-- top.v # top-level Verilog module `-- acf.scs # analog simulation control file Running the Tutorial: Please set up $AMSHOME to IUS82 before starting. For example: %setenv AMSHOME /grid/cic/ams/ius82/pink %set ams_path = ($AMSHOME/tools/bin) %set path = ($ams_path $path)

Action 1: Change to the tutorial directory. For using CPF in IUS82, you need set an environment variable $AMS_CPF_ENABLE to YES.

%cd ams_cpf

Action 2: Have a look at the file ./source/digital/ams_pm.cpf; and notice how the five power domains with PSO condition are defined:

==================== ams_pm.cpf =================== # ams_pm.cpf set_hierarchy_separator . set_design top create_power_domain -name default_pd -default create_power_domain -name pwr_pd \ -instances top_inst1 \ -shutoff_condition !pmc.pw_top_inst1_ctrl create_power_domain -name pwr_inst1_pd \ -instances top_inst1.pwr_inst1 \ -shutoff_condition !pmc.pw_pwr_inst1_ctrl create_power_domain -name dig_pd \ -instances top_inst2 \ -shutoff_condition !pmc.pw_top_inst2_ctrl create_power_domain -name ana_pd \ -instances top_instA \ -shutoff_condition !pmc.pw_top_instA_ctrl # ISOLATION create_isolation_rule -name iso_from_top_inst1 \ -isolation_condition pmc.iso_top_i1_out_ctrl \ -from pwr_pd \ -isolation_output hold create_isolation_rule -name iso_from_pwr_inst1 \ -isolation_condition pmc.iso_pwr_i1_out_ctrl \ -from pwr_inst1_pd \


P: 61

-isolation_output hold create_isolation_rule -name iso_from_top_inst2 \ -isolation_condition pmc.iso_top_i2_out_ctrl \ -from dig_pd \ -isolation_output hold end_design ===============================================

Action 3: Then take a look at the file ./source/digital/pmc.v. The control signals of PSO condition are given:

===================== pmc.v ====================== module pmc; reg pw_top_inst1_ctrl, pw_top_inst2_ctrl, pw_pwr_inst1_ctrl, pw_top_instA_ctrl; reg iso_top_i1_out_ctrl, iso_top_i2_out_ctrl, iso_pwr_i1_out_ctrl; initial begin pw_top_inst1_ctrl = 1; pw_top_inst2_ctrl = 1; pw_pwr_inst1_ctrl = 1; pw_top_instA_ctrl = 1; iso_top_i1_out_ctrl = 0; iso_top_i2_out_ctrl = 0; iso_pwr_i1_out_ctrl = 0; end always begin #30 // Pwr Domain | Dig Domain // | Inst1 Domain | pw_top_inst1_ctrl = 0; // OFF ON ON #20 pw_top_inst2_ctrl = 0; // OFF ON OFF #20 pw_pwr_inst1_ctrl = 0; // OFF OFF OFF #20 pw_top_inst1_ctrl = 1; // ON OFF OFF #20 pw_top_inst2_ctrl = 1; // ON OFF ON #20 ...... ===============================================

Action 4: open run command, the run options is like:

#!/bin/csh -f irun \ ./source/digital/*.v \ ./source/digital/*.vams \ ./amscf.scs \ -iereport \ -discipline logic \ -amsconnrules ConnRules_18V_full \ -lps_cpf "./source/digital/ams_pm.cpf" \ -lps_simctrl_on \ -lps_stime 1ns \ -input probe.tcl

Action 5: execute the run script by


P: 62

%./run

Action 6: Check irun.log file, make sure Power Smart CM were inserted.

===================== irun.log ====================== ...... ----------IE report ------------- Automatically inserted instance: top.\connect[9]__L2E_CPF__electrical (merged): connectmodule name: L2E_CPF, inserted across signal: connect[9] and ports of discipline: electrical Sensitivity infomation: No Sensitivity info Discipline of Port (Din): logic, Digital port Drivers of port Din: (top) assign connect = c1 + c2 Loads of port Din: No loads Discipline of Port (Aout): electrical, Analog port Automatically inserted instance: top.\connect[8]__L2E_CPF__electrical (merged): connectmodule name: L2E_CPF, inserted across signal: connect[8] and ports of discipline: electrical Sensitivity infomation: No Sensitivity info Discipline of Port (Din): logic, Digital port Drivers of port Din: (top) assign connect = c1 + c2 Loads of port Din: No loads Discipline of Port (Aout): electrical, Analog port ...... IE Report Summary: L2E ( logic input; electrical inout; ) total: 1 L2E_CPF ( logic input; electrical inout; ) total: 10 -------------------------------------------------------------------

Total Number of Connect Modules total: 11 ...... ===============================================

top.\connect[9]__L2E_CPF__electrical is one of Power Smart CM.

Action 7: If you run the case in simvision GUI mode (add –gui option in irun), Simvision provide a powerful tools Power Sidebar to help you locate and debug power domains on running. %./irun_gui

Click the Power tab in the Design Browser, Source Browser or Waveform. The Power Sidebar displays each power domain in the design. Repeat the run command in Console-SimVision window. The light bulb next to each domain name indicates its state at the current simulation time as in Figure 3.9.3. For More detail, please refer to: Low-Power Simulation Guide, Chapter 7, “Debugging a Low-Power simulation”. ncsim> run 0.1ns ncsim> run 0.1ns ……


P: 63

Figure 3.9.3 Power Sidebar

Action 8: Run the case in AMS-UltraSim. %./run_amsu Run script is like:

#!/bin/csh -f irun \ ./source/digital/*.v \ ./source/digital/*.vams \ ./amscf.scs \ -amsfastspice \ -iereport \ -discipline logic \ -amsconnrules ConnRules_18V_full \ -lps_cpf "./source/digital/ams_pm.cpf" \ -lps_simctrl_on \ -lps_stime 1ns \ -input probe.tcl

Action 9: clean up the directory by

%./clean_up

Summary: After gone through this tutorial, you should get ideas on

a. How to import CPF in AMS. b. Power-Smart CM is auto-inserted between analog blocks and directly /indirectly related digital blocks. The PSO information of digital blocks defined in Power-Smart CM will transfer to analog blocks. c. Run AMS-Spectre and AMS-UltraSim with CPF.

3.11 AMS Designer With APS Solver

3.11.1 Introduction

Virtuoso Accelerated Parallel Simulator (APS) is a next generation SPICE simulator that provides high performance, high capacity circuit simulation with full Spectre accuracy.


P: 64

From IUS8.2 USR4, APS has been integrated into AMS Designer as a new analog solver. AMS-APS combines an advanced simulation engine with existing AMS-Spectre and AMS-Spectre Turbo technologies. It is primarily targeted at speeding up DC and Transient analyses in analog portion. The AMS-APS use model is identical to AMS-Spectre. AMS-APS has the following key features:

� Full Spectre accuracy. � Much improved capacity compared to AMS-Spectre. � Multi-threading support on multi-core and multi-CPU systems to achieve maximum simulation

performance � Fully compatible with Spectre Solver.

This tutorial talks about topics:

� AMS-APS Usage Recommendations � AMS-APS Command-line Use Model � Running a Case with AMS-APS

3.11.2 AMS-APS Usage Recommendations

AMS-APS is recommended for the following types of designs: � Medium and large designs with more than 5K analog elements. � Post-layout designs with large amount of parasitic RC

Table below provides guidance regarding how to choose among AMS-Spectre, AMS-Spectre Turbo, and AMS-APS #Analog Elements

AMS-Spectre AMS-Spectre Turbo Mode

AMS-APS

1 thread 2 threads 4 threads 8 threads

< 100 ��

< 5K ��

< 50K ��

> 50K �� Note:

� Cells marked with the symbol �� in the above table indicate the recommended tool to use for designs of a particular size.

3.11.3 AMS-APS Command-line Use Model

AMS command line argument for selecting Ultrasim/Spectre/APS solvers 1 irun command line argument -solver spectre : for AMS-Spectre. This is the default. -solver ultrasim : for AMS-Ultra. -solver spectre –spectre_args “+aps” : for AMS-APS. 2 ncelab/ncsim command line argument for 3-step user

• ncelab –amsfastspice remains the only way to select Ultrasim solver. – If -amsfastspice is not in ncelab AND -solver spectre –spectre_args “+aps” is added in ncsim, the APS solver is selected. – If -amsfastspice is not in ncelab AND -solver spectre is added in ncsim, the spectre solver is selected.


P: 65

– If neither -amsfastspice is in ncelab nor -solver spectre –spectre_args “+aps” is in ncsim, the default spectre solver is selected.

• ncsim errors out with proper error messages: –––– If both -amsfastspice is in ncelab AND -solver is in ncsim, prompting user to select only one of them. –––– If there are multiple -solver are in ncsim, prompting user to select only one of them. –––– If -solver has no solver name as its argument, prompting user to select one of the three: spectre, aps, ultrasim. –––– If -solver has an unrecognizable argument, prompting user to select an appropriate one. –––– If -solver ultrasim is in ncsim, prompting user to use ncelab -amsfastspice instead.

Please check the Virtuoso® AMS Designer Simulator User Guide for more details. irun/ncsim command line argument for passing Ultrasim/Spectre/APS options 1 -spectre_args "<arguments separated with space>":

Arguments are appended to the spectre solver arguments if spectre solver is selected. Multiple -spectre_args can be added by user in the command line, and they are concatenated.

Note: –––– It is ignored without warning if ultrasim or aps solver is selected. –––– ncsim errors out with proper error message if unsupported spectre args are added when spectre solver is selected. –––– The Spectre arguments supported in –spectre_args are: +lorder, +mt, +multithread, +parasitics, +turbo, -V, -W, -cmiconfig, -cmiversion, -h, -mt, -

multithread, -plugin, -r and -raw. 2 -spectre_args "+aps <arguments separated with space>":

Arguments are appended to the aps solver arguments if aps solver is selected. Multiple -spectre_args can be added by user in the command line, and they are concatenated.

Note: –––– It is ignored without warning if ultrasim or spectre solver is selected. –––– ncsim errors out with proper error message if unsupported aps args are added when aps solver is selected. –––– The APS arguments supported in –spectre_args are: +lorder, +mt, +multithread, +parasitics, -V, -W, -cmiconfig, -cmiversion, -h, -mt, -multithread, -

plugin, -r, –raw and –pro[cessor]. 3 -ultrasim_args "<arguments separated with space>":

Arguments are appended to the ultrasim solver arguments if ultrasim solver is selected. Multiple -ultrasim_args can be added by user in the command line, and they are concatenated.

Note: –––– It is ignored without warning if spectre or aps solver is selected. –––– ncsim errors out with proper error message if unsupported ultrasim args are added when ultrasim solver is selected. –––– The Ultrasim arguments supported in –ultrasim_args are: +lorder, -plugin and –turbo.

Note: The syntax of the arguments passed to the above 3 solver is defined by the analog solver, and the analog solver may later error out on any wrong arguments. Please check the Virtuoso® AMS Designer Simulator User Guide for more details. irun/ncsim command line argument for selecting the number of threads of parallel simulation

-spectre_args “+aps +mt=n”


P: 66

n is the number of threads. If n is larger than the number of cores of the computer, n is reset to the number of cores. If +mt=n is not specified, the default number of threads is the number of cores of the computer.

Please check the Virtuoso® AMS Designer Simulator User Guide for more details. irun/ncsim command line argument for supporting parasitics reduction for RF circuits

-spectre_args “+aps +parasitics=n” n is a number in GHz of the cut-off frequency of the RF signals that need to be accurately simulated.

Please check the Virtuoso® AMS Designer Simulator User Guide for more details.

3.11.4 Running Case with AMS-APS

The design information This example case is a PLL circuit, including only SPICE netlists and Verilog code. These netlists or codes may come from analog or digital design community separately. The PLL consists of a VCO (Verilog-A module), a digital frequency divider, a digital frequency counter, a phase detector (PD), and a charge pump. The VCO generates eight 400MHz signals with different phases (p0, p45, p90, ... , p315). One of the outputs (p0) is divided down by a factor of 2 before feeding into the phase detector (vcoclk). The other input to the phase detector is a 200MHz reference clock signal (refclk). When the two inputs to the PD are out-of-sync, the PD generates corrective pulses to adjust the differential output voltages of the charge pump (vcop, vcom), which control the frequency of the VCO. When the PLL is in lock, the signals vcoclk and refclk are in phase, and the VCO control signals v(vcop)\250C v(vcom) are stable. The key signals are: testbench.refclk testbench.clk_p0_1x testbench.clk_p0_4x testbench.p1.vcom testbench.p1.vcop testbench.p0

Note: This is the same design in Chapter 2 Basic Flow: verilog/ams + SPICE Run the case with AMS-Spectre Action 1: Check the run script.

irun ./source/digital/*.v \ ./amscf.scs \ -timescale 1ns/100ps \ -input probe.tcl

Action 2: Run the case with AMS-Spectre first. And copy the wave form as the golden. ./run

cp -r waves.shm/ waves.shm.amss

Run the case with AMS-APS Action 3: Modify the run script. Add –solver spectre –spectre_args “+aps” in the command.


P: 67

irun ./source/digital/*.v \

./amscf.scs \ -timescale 1ns/100ps \ -input probe.tcl \ -solver spectre -spectre_args “+aps”

Action 4: Save the modification and run the simulation again. Check the log file. You will find the solver changes to APS. AMSD: Using aps solver. Cadence (R) Virtuoso (R) Accelerated Parallel Simulator

Note: If the machine is multi-core you will see a log file message listing the number of cores and how many are used for this simulation.

User: xxx Host: xxx HostID: xxx PID: 7809 Memory available: 6.4210 GB physical: 8.3656 GB CPU(1 of 2): CPU 0 AMD Opteron(tm) Processor 252 2593.643MHz

Action 5: You may also copy the waves to another directory for future comparison.

cp -r waves.shm/ waves.shm.amsaps

Run the case with –spectre_args “+aps” Action 6: Modify the run script. Add –spectre_args “+aps +parasitics” in the command.

irun ./source/digital/*.v \ ./amscf.scs \ -timescale 1ns/100ps \ -input probe.tcl \ -solver spectre \ -spectre_args “+aps +parasitics”

Action 7: Save the modification and run the simulation again. Check the log file.

At the beginning of ncsim log you can find a short summary of the taken arguments/options AMSD: Using aps solver with arguments: +parasitics

You will also find a report about parasitic reduction. Please note this case does not include any small resister or capacitor, so none is reduced.

********************************* Parasitics Reduction Mode Enabled. Resistors reduced by 0%. Capacitors reduced by 0%.

*********************************

Action 8: You may also copy the waves to another directory for future comparison.

cp -r waves.shm/ waves.shm.amsaps_rcr Run the case with AMS-APS multi-thread Please make sure you’are using a machine with more than one core. Action 9: Modify the run script. Change the argument to –spectre_args “+aps +mt=2” in the command. This will limit the number of cores to 2.


P: 68

irun ./source/digital/*.v \ ./amscf.scs \ -timescale 1ns/100ps \ -input probe.tcl \ -solver spectre \ -spectre_args “+aps +mt=2”

Action 10: Save the modification and run the simulation again. Check the log file.

At the beginning of ncsim log you will find a short summary of the taken arguments/options AMSD: Using aps solver with arguments: +mt=2

You may find the note in the log file.

Notice from aps during initial setup. Multithreading Enabled: 2 threads on system with 8 available processors.

The default number of threads is the number of cores of this machine (up to 8), if you do not set +mt option. Notice from aps during initial setup.

Multithreading Enabled: 8 threads on system with 8 available processors.

(Optional) Verify the results Action 11: Going through action 1-10, we’ve collected three versions of database. You may start wavescan to

compare the key signals.

waves.shm.amsaps_amss waves.shm.amsaps_amsaps waves.shm.amsaps_amsaps_rcr

Please note waves in waves.shm.amsaps_amsaps and waves.shm.amsaps_amsaps_rcr are identical because there’s no resister or capacitor reduced.

Summary This totorial talks about the new solver in AMS. Going through this tutorial you learn AMS-APS is suitable for large and post layout design. You also learn how to use AMS-APS on command-line. Note: the tutorial case used here is just to show you the use model. It is too small to see a significant performance gain.

3.12 Packngo

3.12.1 Introduction of Packngo

This tutorial talks about how to use Packngo with irun in AMSD Incisive Use Model ONLY. AMSD Virtuoso Use Model is not covered here. The estimated time to complete this tutorial is about 10 minutes.


P: 69

Note: Packngo currently has the following limitations

• Doesn’t support AIX operating system • 64Bit Packngo doesn’t support SystemC (while 32Bit is fine) • Doesn’t support plus options (e.g. +ncvlogargs, +ncelabargs,). If you have + options, please add them

into a option list file (e.g. option.f), then run irun –f option.f

3.12.2 Background of Packngo

Packngo is a design packing tool integrated in Virtuoso AMS Designer Simulator, and gives the users a standard way to package design runs so that they can be shipped to and faithfully reproduced by others. This capability is useful, for example, when the customers of AMS Designer encounter a bug, a program crash, or a performance issue and need to have Cadence support personnel to reproduce the problem. Cadence AE, PE or R&D can quickly reproduce the issues based on the case generated by Packngo. Therefore, Packngo can save much time and improve the efficiency for the users. Packngo has 2 modes of operation: record and replay.

• Record mode The purpose of the record mode is to create a record of all the files opened by irun. The mode is switched on by using the –packngorec <directory name> option. We shall call the directory argument to the –packngorec option as the packngo directory. The packngo directory contains all the files and directories opened by irun and thus constitutes a location-insensitive test case. The packngo directory can be tarred up and transferred to another person or place.

• Replay mode The replay mode is to replay the test case created in the record mode. The test case contains an automatically generated script called exec_flow.run to run the test case.

3.12.3 Testcase Information and Architecture

This example case is a PLL circuit, including only SPICE netlists and Verilog code. These netlists or codes may come from analog or digital design community separately. The PLL consists of a VCO (Verilog-A module), a digital frequency divider, a digital frequency counter, a phase detector (PD), and a charge pump. The VCO generates eight 400MHz signals with different phases (p0, p45, p90, ... , p315). One of the outputs (p0) is divided down by a factor of 2 before feeding into the phase detector (vcoclk). The other input to the phase detector is a 200MHz reference clock signal (refclk). When the two inputs to the PD are out-of-sync, the PD generates corrective pulses to adjust the ifferential output voltages of the charge pump (vcop, vcom), which control the frequency of the VCO. When the PLL is in lock, the signals vcoclk and refclk are in phase, and the VCO control signals v(vcop)\250C v(vcom) are stable. The key signals are: testbench.refclk testbench.clk_p0_1x testbench.clk_p0_4x testbench.p1.vcom testbench.p1.vcop testbench.p0 Design files: SPICE netlist for analog, analog device models and verilog modules for digital .


P: 70

|-- source #All source files | |-- analog # Analog (SPICE) netlist | | |-- ChargePump.sp # Charge pump subckt | | |-- Gates.sp # Basic gates | | |-- PLL.sp # PLL circuit, including all analog blocks | | |-- PhaseDetector.sp # Phase detector subcircuit | | ‘-- VCO.va # Verilog-A module | ‘-- digital # Digital code | |-- counter.v | |-- divider.v | ‘-- testbench.v # digital stimulus file ‘-- models # Model directory

|-- bipolar.scs |-- diode.scs |-- gpdk.proc |-- gpdk.scs |-- nmos1.scs |-- pmos1.scs ‘-- resistor.scs

Note: PLL.sp includes PhaseDetector, ChargePump blocks with a SPICE netlist, and a Verilog-A VCO.


Record Mode Action 1. Make sure AMS Designer environment is set up and ready to run. Action 2. Add the –packngorec option to your irun command in the “run” script:

irun –packngorec <directory name>

The <directory name> is the directory where you want the software to write the packaged test case. Here’s an example.

irun -packngorec `pwd`/packngo_data \ ./source/digital/*.v \ ./amscf.scs \ -amsfastspice \ -timescale 1ns/100ps \ -input probe.tcl

Action 3. Run the tutorial with the script file “run”.

./run

Then you will see “Pack-N-Go running in ‘record’ mode.” printed out (see Fig 3.11.1).

Fig 3.11.1 Note from irun for ‘record’ mode

And after the simulation finishes, you will also see the message from Pack-N-Go (see Fig 3.11.2 and Fig 3.11.3), including packngo directory, version information, logfile directory, the working process of Pack-N-Go and the summary of copied files.


P: 71

Fig 3.11.2 Message from Pack-N-Go

Fig 3.11.3 Message from Pack-N-Go

Note: If you want to run the script “run” again, rename the first packngo directory. Successive calls of "irun -packngo ..." (from script file run or command-line) results in irun.run file in the packngo directory being appended with each irun command (rather then cleaning out the file).

Action 4. Launch Simvision to check the waveform. Start SimVision and open ./waves.shm/waves.trn, and then you’ll see the three signals mentioned before

(see Fig 3.11.4).

simvision &

Fig 3.11.4 waves form the original test case

(Optional) To test the packaged test case, run the top-level script in the packngo directory: Action 5. Move to the packngo directory and Run the top-level run script

cd packngo_directory


P: 72

./exec_flow.run

Action 6. Running with no errors, finally, we can package up the whole packngo directory and send it to the recipient

tar –cvf packngo_design.tar packngo_directory

Note:

• Make sure that you package the whole packngo directory, not just the files within the directory, so that hidden files in the directory are included.

• Please note that the packngo directory will end up with a copy of every file that the tools touch so that

the resulting tar file could be quite large for real designs. Sufficient disk space should be available for creating this directory.

Replay Mode

Action 7. After obtain the test case in other machine or place, it is easy to replay it. Please untar the case firstly.

tar –xvf packngo_design.tar

Action 8. Run the top-level run script to replay the test case (just like 5.).

cd packngo_directory ./exec_flow.run

Action 9. You may launch SimVision to check the waveform.

cd <data location> simvision &

The <data location> can be found in the script file irun.run, which is called by exec_flow.run. At the bottom of the script file irun.run you’ll find a statement like cd $PACKNGO_DIR/…/packngo

The location after “cd” is the <data location>. You may find the waveforms are the same with the ones from the original test case (see Fig. 4).


P: 73

Fig.4 waves form the test case relocated

Summary After completing this tutorial case, the user now knows how to use Pack-N-Go feature with irun in AMS Designer.

3.13 Netlist Compiled Functions (NCF)

The Virtuoso® AMS Designer simulator (both AMS-Spectre and AMS-UltraSim) now allows a netlist expression to call functions that are loaded from a Dynamic Link Library (DLL). With this functionality, you can create your own functions in C or C++, for example, taking advantage of the features of these languages and overcoming the restrictions of the netlist user-defined function. For information about creating a plug-in, installing a NCF, and modifying the default behavior of NCF etc, see the following reference:

• Virtuoso® Spectre® Circuit Simulator User Guide Appendix C.

3.13.1 Loading a Plug-in

In IUS8.2 release, new options is added into -spectre_args and –ultrasim_args to load plug-in DLL. For example:

#!/bin/csh -f irun ./source/digital/*.v \ //dig testbench and design modules ./amscf.scs \ //AMS Control File -timescale 1ns/100ps \ //timescale definition -input probe.tcl \ //probe TCL file -spectre_args “-plugin ./src/sti.so” //load plug-in sti.so

Or for running AMS-UlstraSim:

#!/bin/csh -f irun ./source/digital/*.v \ //dig testbench and design modules ./amscf.scs \ //AMS Control File -amsfastspice \ //fastspice (UltraSim) switch -timescale 1ns/100ps \ //timescale definition -input probe.tcl \ //probe TCL file -ultrasim_args “-plugin ./src/sti.so” //load plug-in sti.so

A plug-in DLL also can be loaded by add “loadplugin” statement in spectre netlist. loadplugin “./src/sti.so”


P: 74

The third way to load plug-in is using the CDS_MMSIM_PLUGINS environment variable. %setenv CDS_MMSIM_PLUGINS “./src/sti.so”

3.13.2 Using a NCF in a Spectre Netlist

A NCF is called in a Spectre netlist just like any built-in mathematical function or user-defined function is called. There is no special syntax required to use a NCF once its plug-in has been successfully loaded by Spectre. In the following example, safe_sqrt( x ) is a simple NCF that evaluates the following code if (x < 0.0) return 0.0; else return sqrt( x );

In the Spectre netlist, this is called as follows parameters w=1u y=safe_sqrt( w )

It could also be called on any instance or model parameter expression. There are some restrictions on the use of NCF functions.

• A NCF cannot be used in a behavioral source if an argument to the NCF is non-constant, i.e. a reference to a node voltage, device current, etc.

r1 1 0 resistor r=add( 1.0, 2.0 )*1k // Used correctly b1 1 0 bsource i=v(1)/(add( 1.0, 2.0 )*1k) // Used correctly b1 1 0 bsource i=add( v(1), 0 )/1k // Error, cannot compute d(i)/d(v(1))

• A NCF cannot be used in a post-processing statement, such as a save, .PRINT, .PROBE

or .MEASURE.

3.13.3 Running AMS Designer Simulator on NCF tutorial

This tutorial demonstrates how to use a NCF in spice (spectre) netlist to calculate parameters’ values. This function is supported in both AMS-Spectre and AMS-Ultrasim. Testcase Information: In this tutorial, you will simulate a PLL circuit that contains five major blocks: * Voltage-controlled oscillator (Verilog-A module) * Phase detector (SPICE) * Charge pump (SPICE) * Divider (Verilog) * Counter (Verilog) The top-level test bench is a Verilog module that instantiates a spice block pll_top. Inside pll_top, the VCO outputs eight evenly-spaced 400 MHz clocks, 45 degree phase apart from each other. One output clock then passes through a divider and feeds back into the phase detector (vcoclk). The phase detector (PD) compares the incoming clock signal with the VCO output clock and produces either an up or a down signal to control the charging or discharging of the charge pump (CP). As a result, the PD either raises or lowers the VCO output clock frequency to bring it back in sync with the incoming clock. When the feedback loop becomes stable, the VCO frequency is locked to that of the incoming signal. The design/test bench structure is as follows:


P: 75

Verilog (testbench on top) | | SPICE (PLL) | |----------------------------------|----------------------------------|---------------------------------------| VerilogA (VCO) SPICE (PD & CP) Verilog(divider) Verilog (counter) The simulation directory/file structure is as follows: -------------------------------------------------------------------------- ./ |-- clean_up # clean-up script |-- models # model directory |-- probe.tcl # Tcl script for saving signals |-- amscf.scs # “amsd” block and analog circuits included |-- run # run script with irun/amss control file |-- run_amsu # run script with irun/amsu control file |-- source # source file directory | |-- analog # analog netlist | | |-- ChargePump.sp # Charge Pump in SPICE | | |-- Gates.sp # Buffer in SPICE | | |-- PLL.sp # PLL in SPICE | | |-- PhaseDetector.sp # Phase Detector in SPICE | | `-- VCO.va # VCO in Verilog-A | |-- digital #digital netlist | | |-- counter.v # counter in Verilog | | |-- divider.v # divider Verilog module | | `-- testbench.v # top-level test bench Verilog module | `-- src # NCF source files | |-- ncf.h # NCF head file | `-- incr_decr.c # C code source file `-- acf.scs # analog control file Have a look at the file ./source/src/incr_decr.c: =============== incr_decr.c ================== #include <stdlib.h> #include <stdio.h> #include <math.h> #include "ncf.h" /* Forward declarations of functions. */ static double incr( ncfHandle_t handle, int argc, double argv[] ); static double decr( ncfHandle_t handle, int argc, double argv[] ); /* The NCF plugin entrypoint. This function must exist and be exported * from the DLL for the DLL to be recognised as a NCF plugin. */ extern void ncfInstall( void ) { ncfHandle_t func = 0L; /* What version of NCF are we using ? * If the return value is ncfFALSE, then this version is not supported * by the simulator. */ if (!ncfSetDefaultVersion( NCF_VERSION_1 )) return;


P: 76

/* First we create the NCF incr. It will take 1 argument. */ func = ncfCreateFunction( "incr" ); ncfSetNumArgs( func, 1, 1 ); ncfSetDLLFunctionV1( func, &incr ); ncfRegisterFunction( func ); /* First we create the NCF decr. It will take 1 argument. */ func = ncfCreateFunction( "decr" ); ncfSetNumArgs( func, 1, 1 ); ncfSetDLLFunctionV1( func, &decr ); ncfRegisterFunction( func ); return; } /* Implementation of incr */ static double incr( ncfHandle_t handle, int argc, double argv[] ) { return argv[0] * 1.1; } /* Implementation of decr */ static double decr( ncfHandle_t handle, int argc, double argv[] ) { return argv[0] * 0.9; }

========================================== Two functions incr() and decr() was created and implemented, incr() increases 10% of input value, and decr() decreases 10% of input value. By load the plug-in in spice (spectre) netlist, you can call the functions directly. Running the Tutorial: Please set up $AMSHOME to IUS82 before starting. For example: %setenv AMSHOME /grid/cic/ams/ius82/pink %set ams_path = ( $AMSHOME/tools/bin ) %set path = ( $ams_path $path)

Action 1: Change to the tutorial directory.

%cd ams_ncf

Action 2 (optional): Using mmsim_genplugin (it belongs to MMSIM7.0) or gcc to ompile the C code source file in ./source/src. Otherwise a complied file was given in ./source/analog/libincr_decr_sh.so, then you can use this file and skip Action2.

%cd ./source/src %mmsim_genplugin -n incr_decr incr_decr.c %gnumake

The compiled file was placed in ./source/src/lnx86/lib/libincr_decr_sh.so. Copy it to the analog source file directory (You also can load the plug-in by relative path). %cp lnx86/lib/libincr_decr_sh.so ../analog/ %cd ../../


P: 77

Action 3: Open ./source/analog/PLL.sp file, you can see the functions defined in incr_decr.c are called in the netlist.

=============== PLL.sp ===================== …… loadplugin "./libincr_decr_sh.so" //Parameters define parameters res_org = 2.4e3 parameters cap_org = 500e-15 //Option_1 parameters res_ncf = incr (res_org); parameters cap_ncf = decr (cap_org); //Option_2 //parameters res_ncf = decr (res_org); //parameters cap_ncf = incr (cap_org); …… c3 vcom 0 cap_ncf c7 clk_p0_1x 0 5e-12 c5 vcop 0 cap_ncf c2 clk_p0_4x 0 5e-12 r1 vcom net7 res_ncf r4 vcop net11 res_ncf …… ==========================================

In the Low Pass Filter (LPF), we adjusts the resistors and capacitors r1, r4, c3, c5, then run the case in two options and compare the results. Action 4: open run command, the run options is like:

#! /bin/csh –f irun ./source/digital/*.v \

./amscf.scs \ -iereport \ -timescale 1ns/1ns \ -input probe.tcl

Another way to run the case, you can comment off the “loadplugin” statement in PLL.sp, and load plug-in from irun command options, like:

#!/bin/csh -f irun ./source/digital/*.v \ ./amscf.scs \ -iereport \ -timescale 1ns/100ps \ -input probe.tcl \ -spectre_args “-plugin ./source/analog/libincr_decr_sh.so”

Or set the environment variable CDS_MMSIM_PLUGINS to load the plug-in: %setenv CDS_MMSIM_PLUGINS “./source/analog/libincr_decr_sh.so” Action 5: Execute the run script by %./run


P: 78

Action 6: Check probe waves in ./waves.shm/waves.trn with simvision and copy the directory to waves.opt1.shm. %./simvision & %cp -r ./waves.shm/ ./waves.opt1.shm/

Action 7: Comment off the option_1 in PLL.sp and delete the comment marks in option_2.

=============== PLL.sp ===================== …… //Option_1 //parameters res_ncf = incr (res_org); //parameters cap_ncf = decr (cap_org); //Option_2 parameters res_ncf = decr (res_org); parameters cap_ncf = incr (cap_org); …… ==========================================

Action 8: Run the case again. Execute the run script by %./run

Action 9: Copy the directory to ./waves.opt2.shm/. Compare signals testbench.pll_top.vcom and testbench.pll_top.vcop in the two results, opt1 and opt2. In LPF, increasing resistance of r1, r4 and decreasing capacitance of c3, c5, will widen the loop-bandwidth and shorten the settling time. Action 10: Run the case in AMS-UltraSim.

Option 1: Execute run script for AMS-UltraSim. %./run_amsu This run script is like:

#!/bin/csh -f irun ./source/digital/*.v \ ./amscf.scs \ -iereport \ -amsfastspice \ -timescale 1ns/100ps \ -input probe.tcl

and “loadplugin” statement in PLL.sp. =============== PLL.sp ===================== loadplugin "./libincr_decr_sh.so" ========================================== Option 2: Comment off “loadplugin” statement in PLL.sp. And load plug-in via –ultrasim_args option: irun ./source/digital/*.v \ ./amscf.scs \ -iereport \ -amsfastspice \ -timescale 1ns/100ps \ -input probe.tcl \ -ultrasim_args “-plugin ./source/analog/libincr_decr_sh.so” Or using environment variable: %setenv CDS_MMSIM_PLUGINS “./source/analog/libincr_decr_sh.so”


P: 79

Action 11: clean up the directory by %./clean_up

Summary: After gone through this tutorial, you should get ideas on

a. How to compile NCF in AMS by using mmsim_genplugin. b. Three ways import NCF to AMS. (1) irun options: -spectre_args and –ultrasim_args; (2) “loadplugin” statement in netlist (3) environment variable CDS_MMSIM_PLUGINS

c. Run AMS-Spectre and AMS-UltraSim with NCF


P: 80

Chapter 4 Advanced AMSD Features

4.1 Multiple Power Supply in AIUM When the design is moved from pure digital (or pure analog) to AMS domain, the full-chip verification engineer could get confused by some AMSD specific concepts, like CM (Connect Module), Crule (Connect Rules), discipline, discipline solutions, etc. Refer to $IUS_INST_DIR/tools/amsd/samples/ius611/BDR_multpwr for more details about the concepts of those terminologies. From IUS8.1 release, ie card is used to help the user to setup CM/Crules and multiple power supplies, along with AIUM (AMSD Incisive Use Model). The ie card sits in a “amsd” block. The following is simple example.

amsd { … ie vsup=2.0 tr=0.1n }

This tutorial will give you a general guideline on how to use ie card for CM/Crules setup and the design with multiple power supplies.

• ie card for CM/Crules • ie card for the design with multiple power supplies • Running AMSD simulator on the tutorial case with ie card • Summary

ie card for CM/Crules There are two new approaches introduced since IUS8.1 regarding the CM/Crule, “ie” card and “-amsconnrules” option to irun.

• "ie" card is recommended for the new users or new cases

o When the CDS installed CM/Crule is used, for example, you can add the following line in “amsd” block

ie vsup=1.8

This is the only thing you need to do. The tool will automatically build the _full_fast rule with 1.8v. You don't need to use -amsconnrules and -discipline options.

o When the user wants to customize the CDS installed CM/Crule, for example, you can add the following into ie card.

ie connrules=full vsup=2.0 tr=0.1n

In the standard CDS installed CM/Crule, there isn’t a CM/Crule with 2.0v for vsup and with 0.1ns for transition time. With this ie card, similarly, the tool will automatically customize the appropriate “full” type CM/crule with 2.0v and 0.1n and create a discipline in fly. You don't need to worry about any details behind. You will get a report in irun.log for all the necessary information. You don't need to use -amsconnrules and -discipline options.

• "-amsconnrules" is a new option introduced in IUS8.1 which allows you to specify which crule you want to use. This is recommended to the existing cases or users


P: 81

o When one or multiple existing customized (user-defined) CMs/crules are compiled, the tool can automatic search for the discipline used in this design and pick the appropriate CM/Crule from the compiled database. All the necessary information about CM/Crule will be printed out in irun.log file. Of course, the user is allowed to specify the crule using –amsconnrules as well.

o When you have existing cases which contains predefined discipline, you need use this -amsconnrules options and probably –discipline option as well. The reason why you can’t use ie card is because the ie card creates its own discipline name which may differ from the existing predefined.

ie card for the design with multiple power supplies

When the design has multiple supplies, currently there are two solutions.

• BDR (Block-based Discipine Resolution): it is still available in IUS8.1 (Refer to tutorial of ius611/BDR_multpwr for more details). However, it is recommended to use ie card.

• ie card: ie card has been extended to cover BDR as well since IUS8.1. This is recommended to the user because it has much simplified use model compared to BDR. It has been well received by many customers already.

In general, there are two level of scopes for the multiple power supply, block level and lower level. Block-level means the multiple power supply based on different cell, instance or libraries, while lower level is based on port or net. In the IUS8.1 release, only block-level is supported, while the lower level are available in IUS82.

Now we are going to understand how ie card works on the design with multiple power supplies based on higher scopes like cell and instance, and lower scopes like port, etc.

Running AMSD simulator on the multiple power tutorial case with ie card Testcase information The case used in this tutorial consists of inveters, buffers and level shifter in the format of verilog and Spectre/spice individually. After inverted by an analog inverter, the digital clock, “clk”, is sent to an analog level shifter and a digital inverter separately. “ls_out”, the output of level shifter, is sent out through the digital buffers, dig_buf1 and dig_buf2, with the analog capacitors of c1 and c2 grounded. “dig_inv_out” is sent to a analog buffer that outputs “ana_buf_out3”. In this case, there are two power supplies, 1.8v and 3.3v. ie card will help to create and insert the appropriate CMs with the correct parameters like vsup, vthi, vtlo, etc. For instances, the CM between ana_inv (with 1.8v) and dig_inv should have the vsup of 1.8v, while the CM between lever shifter (3.3v) and dig_buf should have 3.3v.


P: 82

Case 1 Diagram

Key signals are the following. testbench.clk // Digital stimulus input: clk testbench.ana_inv_out // Output of analog inverter: pulse with 1.8V testbench.ls_out // Output of analog level_shifter: pulse with 3.3V testbench.vlog_buf_out1 // Output of digital buffer channel1: pulse with 3.3V testbench.vlog_buf_out2 // Output of digital buffer channel2: pulse with 3.3V testbench.ana_buf_out3 // Output of analog buffer channel3: pulse with 1.8V The database structure of the tutorial case |-- clean_up # clean created intermediate files |-- models # device model directory | `-- spectre_prim.scs |-- probe.tcl # tcl file for saving signals |-- run # run script |-- source # include all soure files | |-- analog # analog netlist | | |-- ana_buf.scs | | |-- ana_inv.scs | | `-- level_shifter.sp | `-- digital # digital code | |-- dig_buf.v | |-- dig_inv.v | `-- testbench.vams # testbench file |-- amscf.scs # AMS Control File, including all Analog/MS stuff (analog design | and “amsd” block) `-- acf.scs # analog control file for analog solver

level Shifter

(1.8->3.3v)

clk dig_buf2 ana_inv

(1.8v)

ls_out

vlog_buf_out2 ana_inv_out

dig_inv

ana_buf (1.8v)

dig_buf1 vlog_buf_out1

ana_buf_out3 dig_inv_out

c1

c2


P: 83

Running the tutorial Please do the following steps to complete this tutorial: Action 1: Point the AMS installation to IUS8.2, for example setenv AMSHOME <IUS8.2_INST_DIR> set path = ($AMSHOME/tools/bin $path) Action 2: Check the tutorial case and understand why and where to instert the CMs. Action 3: Check the amscf.scs file, focusing on how ie card is given in amsd block

amsd { … ie vsup=1.8 ie vsup=3.3 cell=dig_buf }

In the above amsd block, “ie vsup=1.8” specifies the parameters for global CM usage, except the situation which has scope-based ie setting. “ie vsup=3.3 cell=dig_buf” is a scope-based (cell-based) setting. In the boundaries of the cell of dig_buf, 3.3v will be used as the vsup (power supply) for CMs.

As a summary on the ie card setting above, except the cell of dig_buf using 3.3v CM, all the rest of this design will apply 1.8v. Action 4: Check the “run” script file You may notice that the option of –chkdigdisp. This is Digital Discipline Checker. It performs digital net's discipline compatibility check. When this option is specified, the elaborator scans the design to identify any nets with incompatible digital discipline connections, using proprietary rules. Any error is reported with complete information about the incompatible discipline and connection. This makes it possible for designers to verify such multiple-supply connectivity with very high confidence, without having to run laborious analog simulations. This option is strongly recommended for the design with multiple power supplies.

In this tutorial case, this option is used for final checking. Action 5: Run the case by using run script. % run Action 6: After the simulation is complete, invoke the simvistion by the following commands: % simvision –input simvision.svcf & Check the key nodes: testbench.clk, testbench.ana_inv_out, testbench.ls_out, testbench.vlog_buf_out1, testbench.vlog_buf_out2, testbench.ana_buf_out3.


P: 84

The vlog_buf_out1 and 2 should be 3.3v while out3 should 1.8v. Action 7: Check the ie report in irun.log file. You would find the following message: Connect Rules applied are: ddiscrete_1_8_cr ddiscrete_3_3_cr The ddiscrete_1_8_cr and ddiscrete_3_3_cr are the two CRules created for 1.8v and 3.3v power supplies. Also, you may find that there are totally 6 CMs insterted automatically. Can you figure out why and where they are located? Action 8: How to use instance-based ie card setting? In this case, the cell of dig_buf has two instances, dig_buf1 and dig_buf2, if we want to use instance-based setting, we can do the following. amsd { … ie vsup=1.8 ie vsup=3.3 inst=”testbench.dig_buf1 testbench.dig_buf2” } Note: you must give the accurate hierarchical instance name for the concerned instances. The following steps will explain how and when to use lower scope for ie setting, like cellport, instport, etc.

Case 2 Diagram

We still use the same case but with a small modification: a wrapper is created and called output_buf which instantiates dig_buf1, dig_buf2 and ana_buf3. To do so, follow the actions.

level Shifter

(1.8->3.3v)

clk dig_buf2 ana_inv

(1.8v)

ls_out

vlog_buf_out2 ana_inv_out

dig_inv

ana_buf (1.8v)

dig_buf1 vlog_buf_out1

ana_buf_out3 dig_inv_out

c1

c2

output_buf

(1) 3.3v discipline is applied

(2) 1.8v discipline is applied


P: 85

Action 9: Rename the extension name from vams1 to vams for prepared module (output_buf), so that it can be compiled by irun. % mv source/digital/output_buf.vams1 source/digital/output_buf.vams Action 10: modify source/digital/testbench.vams file by Changing it from: dig_buf dig_buf1 ( ls_out, vlog_buf_out1 ); dig_buf dig_buf2 ( ls_out, vlog_buf_out2 ); ana_buf ana_buf ( dig_inv_out, ana_buf_out3, vdd18, gnd ); // output_buf output_buf ( ls_out, ls_out, dig_inv_out, vlog_buf_out1, vlog_buf_out2, ana_buf_out3, vdd18, gnd ); To: // dig_buf dig_buf1 ( ls_out, vlog_buf_out1 ); // dig_buf dig_buf2 ( ls_out, vlog_buf_out2 ); // ana_buf ana_buf ( dig_inv_out, ana_buf_out3, vdd18, gnd ); output_buf output_buf ( ls_out, ls_out, dig_inv_out, vlog_buf_out1, vlog_buf_out2, ana_buf_out3, vdd18, gnd ); Action 11: modify the ie card in amscf.scs file to: amsd { … ie vsup=1.8 ie vsup=3.3 cell=dig_buf } Action 12: run the simulation by % run The following like error messages are expected: ncelab: *E,DSPMM: Incompatible discrete disciplines testbench.output_buf.in1(ddiscrete_1_8) connected to testbench.output_buf.dig_buf1.in(ddiscrete_3_3). ncelab: *E,DSPMM: Incompatible discrete disciplines testbench.output_buf.out1(ddiscrete_1_8) connected to testbench.output_buf.dig_buf1.out(ddiscrete_3_3). ncelab: *E,DSPMM: Incompatible discrete disciplines testbench.output_buf.in2(ddiscrete_1_8) connected to testbench.output_buf.dig_buf2.in(ddiscrete_3_3). ncelab: *E,DSPMM: Incompatible discrete disciplines testbench.output_buf.out2(ddiscrete_1_8) connected to testbench.output_buf.dig_buf2.out(ddiscrete_3_3). irun: *E,ELBERR: Error during elaboration (status 1), exiting. The errors above are reported by –chkdigdisp, the Digital Discipline Checker, which found the incompatible disciplines.


P: 86

Taking the first error as an example, since cell of dig_buf was explicitly declared as 3.3v discipline, while the rest of the digital domain was 1.8v, it is conflicted. Please see the callout (1) and (2) in Case 2 Diagram above. To address it, we need to set the port in the location of callout (1) as 3.3v discipline as well, by amsd { … ie vsup=1.8 ie vsup=3.3 cell=dig_buf ie vsup=3.3 cellport="output_buf.in1 output_buf.in2 output_buf.out1 output_buf.out2" } Action 13: run again % run The simulation should run to completion. Action 14: After the simulation is complete, invoke the simvistion by the following commands: % simvision –input simvision.svcf & Check the key nodes of testbench.clk, testbench.ana_inv_out, testbench.ls_out, testbench.vlog_buf_out1, testbench.vlog_buf_out2, testbench.ana_buf_out3. The vlog_buf_out1 and 2 should be 3.3v while out3 should 1.8v. Action 15: clean up the directory by

%./clean_up SummarySummarySummarySummary After having walked through this tutorial, you should get ideas on

a. How to use ie card to setup CM/Crule b. How to use ie card to setup multiple power supplies based on different level of scope: cell, inst and

cellport c. You also may find that the new use model of ie card is much simpler than previous solutions for

CM/Crule and BDR

4.2 AmsSaveRestart

You can use the save-and-restart feature of the Virtuoso® AMS Designer simulator (both AMS-Spectre and AMS-UltraSim) to save the simulation database at a specific time point and use that saved database to restart the simulation from that same time point. In particular, the save-and-restart feature lets you * Achieve maximum simulation speed by simulating only the portion of time that requires a highly accurate simulation mode (for example, simulating a PLL locking process in accurate mode and then switching to a higher speed mode once the PLL is locked) * Perform what-if analyses on problematic sections of a design * Test circuits that are only semi-functional using an abstract model for unimplemented capabilities


P: 87

* Save and restart for “rainy days” such as unexpected simulation crashes You can save time by saving snapshots during a long simulation run (such as a full-chip design that might take days, or even weeks) so that you do not need to rerun the simulation from the beginning (to support any special debugging/analysis purposes you might have or in case of any mishaps that might occur), especially prior to tape-out. The following topics will be covered for tutorial details: * Save-and-Restart Use Models * Test Case Description * Preparing to Run the Tutorial * Using Save-and-Restart in AMS-Spectre * Using Save-and-Restart in AMS-UltraSim

4.2.1 Save-and-Restart Use Models

The most common use models for save-and-restart are * Running AMS-Spectre in command-line mode, save a snapshot of a simulation and restart after making changes in the analog control file to simulation parameters such as reltol or abstol that do not affect the circuit topology * Running AMS-UltraSim, you can save a snapshot either in non-interactive (command-line) mode or in tcl mode, and you can restart either from command-line mode or tcl mode

4.2.2 Options in irun to support save/restart

* -snapshot <snapshot_name> : to save snapshot after elaboration at command-line * -r <snapshot_name> : Force simulation using snapshot you saved before(from command-line or tcl) * -R : Simulate using last snapshot generated Basically you can use irun -r <snapshot_name> <other options> or irun -R <other options> to restart from irun command line, for both AMS-Spectre and AMS-Ultrasim. Please note at restart you can modify some irun simulation command options, instead of adding only -R -r <snapshot_name> options.

4.2.3 Test Case Description

The design in this tutorial is an oscillator circuit composed of AC-coupled varactors. It produces an oscillated clock (4 GHz) which is then modulated by a digital clock (500 KHz). The top-level DUT is a SPICE block and the top-level test bench is a Verilog-AMS module. You will run this example using both AMS-Spectre and AMS-UltraSim. The test case file/directory structure is as follows: . |-- amscf_tran.scs #ams control file for transient simulation |-- amscf_tran_spectre1.scs #ams control file for restart simulation in AMS-Spectre |-- run_amss # run script for AMS-Spectre |-- run_amsu # run script for AMS-UltraSim |-- test.vams # the top Verilog-AMS test bench |-- amsControl_tran.tcl # Tcl script for save/restart |-- amsd.scs # ams control file |-- amsControl_tran.scs # analog control file for UltraSim/AMS-Spectre |-- amsControl_tran_spectre1.scs # analog control file for AMS-Spectre with changed options


P: 88

|-- vco.scs # SPICE on top DUT |-- moscap.va # mos capacitor Verilog-A model |-- multiplier.va # multiplier Verilog-A model |-- bsim.mos # original transistors model |-- bsim_new.mos # transistors model used in AMS-Spectre restart |-- amsControl.raw # waveform directory generated by control file |-- waves_tran.shm # waveform directory generated by Tcl script `-- clean_up # clean-up script

4.2.4 Preparing to Run the Tutorial

Before running the tutorial, do the following: Action 1: Verify that your AMS Designer installation is set up and working. Then change to the tutorial directory you created when you untar the tutorial file and browse through the directory structure and files: cd amsd_saverestart/ ls Action 2: Open test.vams which is the top-level Verilog-AMS test bench. The test bench generates a 500 KHz baseband clock. Action 3: Open vco.scs, the top-level DUT, which is in SPICE. Underneath it, there are a moscap (Verilog-A), a multiplier (Verilog-A) and some SPICE components. Action 4: Open amsControl_tran.scs. This analog control file sets up a list of simulation options. For example: tight options reltol=1.0e-6 Action 5: Run the script: ./run_amss The simulation stops at the Tcl ncsim> prompt after running ncvlog/ncelab/ncsim. Action 6: Type the following run command and wait until it finishes: ncsim> run 1us Action 7: Type the following save command: ncsim> save amss1us A confirmation message appears: Saved snapshop worklib.amss1us:vams Action 8: Type the following ls command: ncsim> ls -a A new .worklib.amss1us.vams.lnx86.166.pkl file appears in the directory INCA_libs/worklib. Action 9: Type the following run command and watch while the simulation runs until 3us: ncsim> run 2us Action 10: Type the following restart command: ncsim> restart amss1us A confirmation message appears: Loaded snapshot worklib.amss1us:vams Action 11: Type the time command to check the current run time: ncsim> time The program confirms that the current run time is 1us.


P: 89

Action 12: Type the following run command and wait until it finishes: ncsim> run 1.5us The simulation reaches 2.5us: save-and-restart works as expected. Action 13: Type the following run command: ncsim> run The simulation runs until 4us and stops because that is the stop time specified in the analog control file. Action 14: Type the exit command: ncsim> exit Action 15: Start SimVision: simvision & Action 16: Load and review the following waveform files: * waves_tran.trn from the ./waves_tran.shm directory The simulation duration in this case is 1us which matches the snapshot time point. * waves_tran-1.trn * waves_tran-2.trn Action 17: Exit SimVison. Action 18: Save waves_tran.shm to a different directory for later comparison. Action 19: Open and review amsControl_tran_spectre1.scs. reltol is 1e-4 instead of 1e-6. You will use this analog control file to restart the simulation. Action 20: At the prompt, type the following irun command:(or type ./run_amss_restart) irun amscf_tran_spectre1.scs -input amsControl_tran.tcl -simcompat spectre -r amss1us Please find with this command, the analog control file(in amscf_tran_spectre1.scs) becomes amsControl_tran_spectre1.scs instead of amsControl_tran.scs. Also note that the modelpath is switched to bsim_new.mos model file. You can use this new modelpath when you run AMS with Spectre solver and new SFE(simulation front end). This command restarts the simulation from the snapshot time point, 1us. Action 21: At Tcl prompt type ncsim> time to verify the current time is 1us. Action 22: At Tcl prompt, type the following run command: ncsim> run 1.5us The simulation stops at 2.5us. Note the changed value for reltol from the specified control file. Action 23: Type the run command and wait until it finishes: ncsim> run Action 24: Exit the simulation: ncsim> exit Action 25: Load and compare the waveform files under waves_tran.shm with the previous waveform files.


P: 90

Action 26: Run the clean-up script: ./clean_up AMS Designer Simulator Save-and-Restart Tutorial To run the tutorial using AMS-UltraSim, do the following: Action 1: Open the run_amsu script and make sure you see -amsf (UltraSim) on the ncelab command. Action 2: (Optional) Open the amsControl_tran.scs control file to view this UltraSim option: *UltraSim: .usim_opt sim_mode=a speed=1 Speed is set to 1 for higher accuracy. Action 3: Run the script: ./run_amsu Action 4: At the Tcl prompt, type the following run command: ncsim> run 1.5us Action 5: To save the database, type the following save command: ncsim> save amsu1p5us Action 6: Type the run command: ncsim> run 1us Action 7: At Tcl prompt type ncsim> time to verify the current time is 2.5us. Action 8: To restart the restart command: ncsim> restart amsu1p5us Action 9: At Tcl prompt type ncsim> time to verify the current time comes back to 1.5us. Action 10: Exit the simulation: ncsim> exit Action 11: Start SimVision: simvision & Action 12: Load and examine the following waveform files: * waves_tran.trn * waves_tran-1.trn Action 13: At prompt, type the following irun command to restart the simulation from the snapshot time point, 1.5us(or type ./run_amsu_restart): irun amscf_tran.scs -input amsControl_tran.tcl -simcompat spectre -r amsu1p5us Please note that many options(even –amsf) for compilation/ncelabration stages are taken off but simulation stages need to be kept for simulation to run. Action 14: At Tcl prompt type ncsim> time to confirm it print out 1.5us which is restart time point.


P: 91

Action 15: At Tcl prompt, type the following run command: ncsim> run 1us The simulation runs until 2.5us. Action 16: Type the run command: ncsim> run Action 17: Exit the simulation: ncsim> exit Action 18: Start SimVision and compare these waveform results with the AMS-Spectre waveform results.

Summary Upon completing this tutorial, you have learned how to use the save-and-restart feature in AMS-Spectre and AMS-UltraSim. You have also explored the flexibility of changing simulation options in the analog control file in between save and restart runs.

4.3 AMS-Spectre Envelope

Note: AMS-Spectre means the Virtuoso® AMS Designer simulator using the Spectre solver. RF designs are complex high-speed designs widely used in wireless systems. Some RF designs such as modulation systems have a very high carrier frequency along with one or more baseband frequencies that are orders of magnitude lower. It is difficult to simulate using traditional transient analysis because the simulator must use a very tiny time step to accommodate the high carrier frequency thus requiring a huge number of time steps to simulate. In this tutorial, you will run envelope simulation for RF circuits. Envelope analysis is a simulation technique developed to reduce the large number of time steps and high computational costs associated with conventional transient RF analysis. During envelope analysis, the analog parts of the design are simulated with various envelope methods such as FM envelope for frequency-modulated sources, autonomous envelope for oscillators, harmonic balance envelope, shooting Newton envelope, and multi-carrier envelope. The digital parts are handled entirely by the digital solver. For each envelope step, the envelope solver skips as many high-frequency cycles as possible while keeping fine accuracy within an allowed range. Digital and analog parts of the design are synchronized through A/D and D/A events at the next analog solution point. Envelope simulation is most efficient for RF circuits with modulation frequencies that are orders of magnitude lower than the carrier frequency. For example, circuits that have a clock as the only fast-varying signal in addition to other input signals that have a spectrum with a frequency range that is orders of magnitude lower than the clock frequency. In general, envelope simulation is not intended for circuits working with multiple carriers (fundamentals). However, you can use it for specific classes of circuits that operate with multiple, proportionate fundamentals. In this case, you use the greatest common denominator of all fundamental frequencies as the clock frequency. See the following topics for tutorial details: * Envelope Analysis Syntax and Parameters * Test Case Description * Tutorial Module 1: Envelope Analysis for Digital Modulator/Demodulator * Tutorial Module 2: Envelope Analysis for Oscillator


P: 92

* Summary

4.3.1 Envelope Analysis Syntax and Parameters

Envelope analysis syntax is very similar to that of transient analysis. The typical syntax is: For autonomous designs such as oscillator use: Envelope_Analysis_Name (node1 node2) envlp parameter=value... For non-autonomous designs use: Envelope_Analysis_Name envlp parameter=value... The following table lists typical parameters for envelope analysis. You can also get detailed parameter descriptions by typing the Spectre command: spectre -h envlp. Some parameters are required while others are optional. Parameter Name Description clockname Specifies the carrier name modulationbw Specifies the modulation bandwidth stop Specifies the simulation stop time start Specifies the simulation start time envmaxstep Specifies the maximum outer envelope step size Default Value: Derived from errpreset envmethod Specifies the method to use for envelope simulation envlteratio Specifies the ratio to use to calculate envelope LTE tolerances Default Value: Derived from errpreset envmaxiters Specifies the maximum number of Newton iterations in one carrier (clock) period harmonicbalance Defines the flag value to enable harmonic balance envelope Valid Values: no (not enabled) yes (enabled) Default Value: no flexbalance Alternative parameter for harmonicbalance Valid Values: no (not enabled) yes (enabled) Default Value: no fund Specifies the carriers (fundamentals) that use harmonic balance envelope harms If harmonicbalance is no, it specifies the number of harmonics for the carrier frequency and the default value is 1 If harmonicbalance is yes, it is the maximum number of harmonics for the carrier frequency and the default value is 3 resetenv Defines the flag value to reset envelope data after D2A/A2D events Valid Values: no (do not reset) yes (reset) Default Value: no ignoredclk Defines the flag value to allow envelope simulation to ignore the timing of digital clocks during simulation Valid Values: no (do not allow) yes (allow) Default Value: no trancycles Specifies the number of transient cycles for envelope simulation; that is, the cycles between two adjacent D2A/A2D event time points Default Value: 5


In this tutorial, you will run envelope simulation in AMS-Spectre. There are two tutorial


P: 93

modules: A simple digital modulator/demodulator (non-autonomous) An AC-coupled oscillator (autonomous) To set up your environment, do the following: 1. Change to amss_envelope/ directory or you can copy the tutorial from installation directory to your own directory. For example cp -r /grid/cic/amscm_v1/ams/ius82/tools/amsd/samples/amss_envelope ~/ 2. Define the following environment variables: setenv AMSHOME /grid/cic/amscm_v1/ams/ius82/lnx86/pink set path= ( $AMSHOME/tools/dfII/bin $path) setenv LD_LIBRARY_PATH $AMSHOME/tools/lib:$AMSHOME/tools/inca/lib:$AMSHOME/ tools/simvisdai/lib:$AMSHOME/uvlib:$AMSHOME/tools/dfII/lib setenv CDS_Netlisting_Mode Analog Now you are ready to run the tutorial.

4.3.3 Tutorial Module 1: Envelope Analysis for Digital Modulator/Demodulator

The design you will simulate in this module is a digital modulator/demodulator. The DUT has SPICE format and consists of five major Verilog-A blocks, an adder, three multipliers, and a demodulator. There is a Verilog-AMS test bench on top that generates the 50 KHz baseband clock for the DUT. I and Q signals (generated from data file) are 2 GHz sinusoidal carrier signals with 90 degree phase apart from each other. The adder produces the sum of I and Q signal. The output signal then feeds into the multiplier for modulation. Then the output signal is passed to the demodulator. Note that the carrier signal is 2 GHz while the baseband signal is 50 KHz, orders of magnitude lower than the carrier frequency. In other words, the modulation ratio is 50 KHz/2 GHz=2.5e-5, much less than 1.0. It is a suitable example for Envelope analysis. The file/directory structure for Module 1 is as follows: |-- run_env # irun script for envelope analysis |-- run_tran # irun script for transient analysis |-- test.vams # the top Verilog-AMS file |-- datafile # data file directory |-- i_data.ascsig # data file for I-channel |-- q_data.ascsig # data file for Q-channel |-- amsControl_env.tcl # Tcl script saving signals for envelope analysis |-- amsControl_tran.tcl # Tcl script saving signals for transient analysis |-- amscf_tran.scs # ams control file for transient analysis |-- amscf_env.scs # ams control file for envelope analysis |-- amsControl_env.scs # analog control file for env analysis |-- amsControl_tran.scs # analog control file for tran analysis |-- simpDM.scs # SPICE subckt file for digital modulator |-- adder.va # adder verilog-A model |-- demodulator.va # demodulator verilog-A model |-- multiplier.va # multiplier verilog-A model |-- amsControl.raw # waveform directory generated by control file statements |-- waves_env.shm # waveform directory generated by Tcl file for envelope analysis |-- waves_tran.shm # waveform directory generated by Tcl file for transient analysis |-- clean_up # clean-up script To run the simulation, do the following: Action 1: Change to the following directory and browse the directory structure and files: cd ./simpDM_hbenv/ Action 2: Open the test.vams file and notice that the test bench generates a 50 KHz baseband clock (period=20us).


P: 94

Action 3: Open the simpDM.scs file to view the definition for the top-level DUT. Notice the port connections. Also, notice that there are five Verilog-A blocks instantiated in the DUT, three multipliers, one adder, and one demodulator. Action 4: There are two run scripts in the simulation directory so that you can run both the transient analysis (run_tran) and the envelope analysis (run_env). For the same reason, there are two sets of analog control files and Tcl files: amsControl_tran.scs and amsControl_tran.tcl are for the transient analysis; amsControl_env.scs and amsControl_env.tcl are for the envelope analysis. Simulation time is 60 us. Action 5: Run the transient analysis by typing the following command at the prompt: ./run_tran When the simulation finishes, note the run time. Action 6: Browse through amsControl_env.scs to review and understand the parameter values. envlp envlp clockname="fff" stop=60u maxstep=0.2ns annotate=status tstab=15n flexbalance=yes trancycles=10 Action 7: Run the envelope analysis by typing the following command at the prompt: ./run_env Pay attention to the log messages during the simulation: Envelope Following Analysis `envlp': time = (0 s -> 60 us) ********************************************************** Onset of periodicity = 500 ps Clock period = 500 ps Initial transient integration from 0 s to 15 ns Envelope Analysis Using Harmonic Balance ... EnvStepIndex = 1, envTime = 15.5 ns, completed = (25.8 m%) EnvStepIndex = 2, envTime = 16 ns, completed = (26.7 m%) .............. envTime indicates envelope analysis time points. The intervals (time steps) between two adjacent envTime points are changing all the time as a result of digital events, input control signal changes, and so on. Pay attention to the simulation summary when it finishes. Total clock cycles: 119969, skipped cycles: 119656, speed-up factor: 369 Done with the envelope-following analysis. Clean up envelope following analysis. Total time required for envlp analysis `envlp' was 26.85 s Note that 90% of the clock cycles have been skipped. As a result, the envelope analysis time is five times less than that of the transient analysis. The speed-up factor applies only to analog parts. Action 8: Start Simvision and load the waveform file under ./waves_env.shm. You can also overlay it with the transient waveform and compare the two waveforms. Action 9: Run the clean-up script: ./clean_up You have completed Module 1.

4.3.4 Tutorial Module 2: Envelope Analysis for Oscillator

The design you are going to simulate in this module is an Oscillator. The top-level DUT is a SPICE block containing three major blocks: a varacator (SPICE), a moscap (Verilog-A), and


P: 95

a multiplier (Verilog-A). It is instantiated in a Verilog AMS test bench which generates a 500 KHz baseband clock. The carrier frequency is the oscillator frequency, 4 GHz. Nevertheless, it is unknown at the beginning before the oscillator is locked. You should use Envelope Analysis command for autonomous devices in this module. The simulation stop time is 2us. The file/directory structure for Module 2 is as follows: |-- run_env # run script for envelope analysis |-- run_tran # run script for transient analysis |-- test.vams # the top-level Verilog-AMS test bench |-- amsControl_env.tcl # Tcl script saving signals for envelope analysis |-- amsControl_tran.tcl # Tcl script saving signals for transient analysis |-- amscf_env.scs # ams control file for envelop analysis |-- amscf_tran.scs # ams control file for transient analysis |-- amsControl_env.scs # analog control file for envelope analysis |-- amsControl_tran.scs # analog control file for transient analysis |-- vco.scs # SPICE subckt file for vco |-- moscap.va # RF mos capacitor verilog-A model file |-- multiplier.va # multiplier verilog-A model file |-- amsControl.raw # waveform directory |-- waves_env.shm # waveform directory for envelope simulation |-- waves_tran.shm # waveform directory for transient simulation |-- clean_up # clean-up script To run the simulation, do the following: Action 1: Change to the following directory and browse the directory structure and files: cd ./osc_hb/ Action 2: Open the test.vams file and notice that the test bench generates a 500 KHz baseband clock for the DUT. Action 3: Open the vco.scs file to view the top-level DUT which has two Verilog-A models and some SPICE components. A sinusoidal signal together with vin control the oscillator. Action 4: Run the transient analysis by typing the following command at the prompt: ./run_tran When the simulation finishes, note the run time. Action 5: Start SimVision, load and review the waveforms under ./waves_tran. Action 6: Browse through amsControl_env.scs to review and understand the parameter values. Action 7: Run the envelope analysis by typing the following command at the prompt: ./run_env Pay attention to the log messages during the simulation. When the simulation finishes, look at the simulation summary and notice that it skipped 8016 out of 8070 clock cycles. The analog speed-up factor is 130. The run time is 10 times less for the envelope analysis than for the transient analysis. Action 8: Start Simvision and load the waveform file under ./waves_env.shm. You can also overlay it with the transient waveform and compare the two waveforms. The oscillation in the envelope analysis is much sparser than that in the transient analysis because of the huge amount of cycle skipping. Action 9: Run the clean-up script:


P: 96

./clean_up

Summary Upon completing this tutorial, you have learned how to run envelope analysis using AMS-Spectre and you have seen how much it can speed up the simulation while keeping fine accuracy.


P: 97

Chapter 5 AMSD extension support

5.1 Real Number Modelling

Using either Verilog-AMS or VHDL-AMS languages, you can define real ports that are not electrical. Using

“real modeling” technology, the elaborator automatically inserts appropriate connect modules between

electrical ports (analog domain) and wrealports (digital domain) so that you can benefit from increased

simulation speed. In this tutorial, we introduce real modeling technology using simple test cases that

highlight the main capabilities and advantages.

This tutorial illustrates the following:

■ Real modeling for a 14-bit ADC and a 14-bit DAC in Verilog-AMS

■ Real modeling for a 14-bit DAC in VHDL-AMS

■ New R2E (real-to-electrical), E2R(electrical-to-real), and ER_bidir(bidirectional electrical-to-real) connect

modules on simple circuits.

Test Case Information This tutorial covers two different topics:

■ Real modeling: The test bench, top, instantiates one step ramp source connected to the input of a 14-bit

ADC. The 14 output bits of this ADC connect to the inputs of a DAC. We created a real DC source to define the

supply and the LSB values of these two mixed-signal converters. We will exercise and simulate all possible

conversions of the ADC and DAC. Because there are 14 bits, the number of conversions to simulate is

2**14=16384. The transistor-level simulation of the real IC for this number of conversions can take from a few

days to more than a week.

■ E2R, R2E, ER_bidir: We will examine these connect modules and learn how the elaborator inserts them

automatically for Verilog-AMS using small test benches.

Running the Tutorial

Before running the tutorial, verify that your AMS Designer installation is set up and working. Running the

tutorial consists of the following segments, in order:

■ wreal Modeling in Verilog-AMS

■ wreal Modeling in VHDL-AMS

■ R2E Connect Module

■ ER_bidir Connect Module


P: 98

■ E2R Connect Module

wreal Modeling in Verilog-AMS

For this segment of the tutorial, do the following:

1. Open and examine the following files:

source/rdcsource.vams contains the real type model for a DC source. The

output port type is wreal, which is like a wire with the capability to transfer a real number.

❑ source/step.vams contains the real type model for a ramp source. An external

clock defines the sampling rate.

❑ source/adc14.vams contains an example of a real type model for an ideal 14-bit

ADC.

❑ source/dac14.vams contains an example of a real type model for an ideal 14-bit

DAC.

Note: The Verilog-AMS code for the ideal ADC and DAC is fairly efficient so that the simulation runs

quickly.

2. Open the run script, run1_adc_dac, and notice the irun ams control file method it employs. The ncelab options -

ACCESS +r let you use the SimVision debugger to display object values and see the connectivity.

3. Run the simulation:

./run1_adc_dac

Several key signals appear in the SimVision waveform window.

4. In the Design Brower window, right-click simulator::top and select Send to Schematic tracer.

The Schematic tracer window opens.

5. In the schematic tracer window, double-click top rectangular.

The blocks diagram of simulator::top appears.

6. In the SimVision waveform window, click the run button.

The simulation completes in less than 3 seconds for 2**14=16384 ACD + DAC bit conversions. In this

test case, the clock frequency is 1GHz. The ADC and DAC perform a conversion on each positive edge of

the clock. All signals are discrete in this dataflow simulation.

7. In the SimVision window, select the signals rin and aout.


P: 99

You will change the display format.

8. Choose Format - Trace - Digital.

There is a delay of two clock periods between the input source rin signal and the output after the ADC + DAC conversion,

signal aout.

9. Choose File - Exit SimVision.

wreal Modeling in VHDL-AMS

We wrote the 14-bit DAC model in VHDL-AMS in this test case using discrete real ports for the analog

signals. We defined the LSB default value in a package. To perform the wreal modeling exercise for this

segment of the tutorial, do the following:

Note: You can execute the same steps as in “wreal Modeling in Verilog-AMS” on page 6. Notice that the

name of the run script is different.

1. Open and examine source/source/dac14.vhms and source/top_adc_dac.vhmsfile.

In this example, we instantiate both VHDL-AMS entities and Verilog-AMS modules.


./run2_adc_dac_vhms

Several key signals appear in the SimVision waveform window.

3. In the Design Brower window, right-click WORKLIB:TOP(BHV) and select Send to

Schematic tracer.

The Schematic tracer window opens.

4. In the schematic tracer window, double-click top rectangular.

The block diagram of WORKLIB:TOP(BHV) appears.


The simulation completes in less than 3 seconds for 2**14=16384 ACD + DAC bit

conversions. In this test case, the clock frequency is 1GHz. The ADC and DAC perform

a conversion on each positive edge of the clock. All signals are discrete in this dataflow

simulation.

6. Select the signals rin and aout.



There is a delay of two clock periods between the input source rin signal and the output

after the ADC + DAC conversion, signal aout.


P: 100


R2E Connect Module

In the amscf.scs file we defined the usage of the 1.8 interface elements, using the following command: include "tran.scs" amsd { ie vsup=1.8 }

For this segment of the tutorial, we will examine the insertion of the R2E (real-to-electrical) connect module.

See also E2R Connect Module on page 13.

1. Open source/step.vams.

The output of this generator is a wrealtype. We used real modeling to design this ramp. This is a unidirectional

output discrete port connected to a resistor load.

2. Open the source/R2E_example.vams test bench file.

Signal aout is an electricalnet. The step generator drives the electrical primitive resistor. During elaboration, the

software inserts an R2E connect module.

The RLOAD2 resistance value is 200 Ohms. We chose this value to create a divider by two (because the

R2E output impedance is 200 Ohms).


./run3_top_R2E

The following message from ncelab appears in the console terminal: Discipline resolution Pass... step #(.step(10.0e-6)) I2 ( .clk( clk ), .y( aout) ); | ncelab: *W,CUCMGB (./source/R2E_example.vams,17|49): Resolve connect module R2E binding through a search of all libraries in cds.lib, connectLib.R2E:module is taken.

Because we added the -IEREPORT option to the ncelab command, we get the following report

about interface element insertion at the end of elaboration: ----------IE report -------------

Automatically inserted instance: top.aout__R2E__discrete_18__1 (merged): connectmodule name: R2E__discrete_18, inserted across signal: aout and ports of discipline: 1 Sensitivity information: No Sensitivity info Discipline of Port (Din): logic, Digital port Drivers of port Din: (top.I2) assign y = yval Loads of port Din: Load: VST_S_BLOCKING_ASSIGNMENT, Line 34, Index 0, in: top.aout__R2E__discrete_18__1


P: 101

Discipline of Port (Aout): electrical, Analog port ncsim: *N,SFEDPL: Deploying new SFE in analog engine. Starting analog simulation engine...

4. In the run3_top_R2E.tclTcl script, we add the following command to get the domain

descriptions of the signals:

describe -verbose top.* top.gnd... .analog net (electrical) = 0 top.aout...analog net (electrical) = 0 top.clk... .net (wire/tri) logic = St0

The software inserts one R2E connect module on net top.aout. 5.


The simulation completes. You can do a zoom fit to see eight events on the aoutsignal.

6. Select signal yval.



Observe the high activity. The clock period of 1 ns forces the step block to generate a

new sample value every 1 ns. The R2E operates like a sample-and-hold.

vdelta=1.8V/64=0.028225 Vdefines the step for the V(aout)signal. In the waveform display, we see a step of

1.8/(64*2)= 0.0140625Volts because the R2E output impedance is 200 Ohms and we have a resistor load of

200 Ohms, (divider by two).

At the end of the simulation, the simulator reports the activity in the SimVision console:

**** AMSD: Mixed-Signal Activity Statistics **** Number of A-to-D events: 0 Number of A-to-D events in IEs: 0 Number of D-to-A events: 5 Number of D-to-A events in IEs: 5 Number of VHDL-AMS Breaks: 0

The number of D-to-A events in interface elements is 5. Which matches the number of

executions of steps display for the signal aout. The R2E introduces multi rate sampling.


9. Read in the hidden connect rule 1.8 volts file which has been automatically created when we run the irun command with the amscf.scs file. This .ams_spice_in/amscb_ie_crules.vams file includes the rules for the insertion of the real connect modules.

//*** amscb_ie_crules.vams *** //* connect rules file for AMSCB IE card //* This file is automatically generated. //* (c) Copyright 2007-2008 Cadence Design Systems, Inc.


P: 102

//* All rights reserved. `include "disciplines.vams" // using connectrule: full_fast discipline discrete_18__1 domain discrete; enddiscipline `define Vsup1 1.8 `define Vthi1 1.20 `define Vtlo1 0.60 `define Tr1 0.2n `define Rlo1 200 `define Rhi1 200 `define Rx1 40 `define Rz1 10M `define Vdelta1 `Vsup1/64 `define Vdelta_tol1 `Vdelta1/4 `define Tr_delta1 `Tr1/20 connectrules discrete_18__1_cr; connect L2E_2 #( .vsup(`Vsup1), .tr(`Tr1), .tf(`Tr1), .rlo(`Rlo1), .rhi(`Rhi1), .rx(`Rx1), .rz(`Rz1) ) discrete_18__1, electrical; connect E2L_2 #( .vsup(`Vsup1), .vthi(`Vthi1), .vtlo(`Vtlo1), .tr(`Tr1) ) electrical, discrete_18__1; connect Bidir_2 #( .vsup(`Vsup1), .vthi(`Vthi1), .vtlo(`Vtlo1), .tr(`Tr1), .tf(`Tr1), .rlo(`Rlo1), .rhi(`Rhi1), .rx(`Rx1), .rz(`Rz1) ) discrete_18__1, electrical; connect E2R #(.vdelta(`Vdelta1), .vtol(`Vdelta_tol1), .ttol(`Tr_delta1)) electrical, discrete_18__1; connect R2E #(.vdelta(`Vdelta1), .tr(`Tr_delta1), .tf(`Tr_delta1), .rout(`Rlo1)) discrete_18__1, electrical; connect ER_bidir #(.vdelta(`Vdelta1), .vtol(`Vdelta_tol1), .ttol(`Tr_delta1), .tr(`Tr_delta1), .tf(`Tr_delta1), .rout(`Rlo1), .rz(`Rz1)) discrete_18__1, electrical; endconnectrules

ER_bidir Connect Module

For this segment of the tutorial, we will examine the insertion of the ER_bidir (electrical-to-real bidirectional)

connect module. Using the same test case, we changed step_bidir.vams output port from wreal, output to

wreal, inout. To view the differences, you can use the UNIX sdiff command as follows:

sdiff -s source/step.vams source/step_bidir.vams

output y; | inout y;


P: 103

To perform this segment of the tutorial, do the following:.


./run4_top_ER_bidir

The following message from ncelab appears in the console terminal: Discipline resolution Pass... step #(.step(10.0e-6)) I2 ( .clk( clk ), .y( aout) ); | ncelab: *W,CUCMGB (./source/R2E_example.vams,17|49): Resolve connect module ER_bidir binding through a search of all libraries in cds.lib, connectLib.ER_bidir:module is taken. Doing auto-insertion of connection elements... Connect Rules applied are: discrete_18__1_cr.

2. In the run3_top_R2E.tclTcl script (which we are reusing for this segment), we add

the following command to get the domain descriptions of the signals:

describe -verbose top.* top.gnd... .analog net (electrical) = 0 top.aout...wire (real) = 0 top.clk... .net (wire/tri) logic = St0

The software inserts one bidirectional connect module on wreal net top.aout.


The simulation completes. You can do a zoom fit to see eight events on the aoutsignal.

4. Select signal yval.



Observe the high activity. The clock period of 1 ns forces the step block to generate a new sample value

every 1 ns. The ER_bidir operates like a sample-and-hold.

At the end of the simulation, the simulator reports the activity in the SimVision console:

**** AMSD: Mixed-Signal Activity Statistics **** Number of A-to-D events: 6 Number of A-to-D events in IEs: 6 Number of D-to-A events: 6 Number of D-to-A events in IEs: 6 Number of VHDL-AMS Breaks: 0

The number of D-to-A events in interface elements is 6, which matches the number of executions of the

following statement:

At time =0, the connect module function absdelta(V(Aout), vdelta, ttol, vtol)triggers an additional event in the

simulator. With the absdelta function, at time 0, the signal conversion happens unconditionally.


P: 104


When you are finished, choose File - Exit SimVision in the SimVision window.

E2R Connect Module

For this segment of the tutorial, we will examine the insertion of the E2R (electrical-to-real) connect module.

The sample test bench circuit is a SPICE voltage PWL source that drives a wreal gain amplifier. The vsource

PWL definition is the following: wave({0,0,10u,0.1})

R2E Connect Module on page 9

1. Open source/top_E2R.vams.

On electricalnode v_in, we connect the PWL SPICE source to the real modeling amplifier. The real amplifier is

a synchronous real modeling style example. The code is as follows:

module rgain (din, dout ); input din; output dout; wreal din, dout; parameter real gain=1.0; assign dout = gain * din; endmodule

Every time the real discrete input signal (din) changes, the output signal (dout) changes.


./run5_top_E2R

The following message from ncelab appears in the console terminal: Discipline resolution Pass... rgain #(.gain(1.0)) I0 (v_in, v_out); | ncelab: *W,CUCMGB (./source/top_E2R.vams,17|28): Resolve connect module E2R binding through a search of all libraries in cds.lib, connectLib.E2R:module is taken. Doing auto-insertion of connection elements... are: discrete_18__1_cr

3. In the run5_top_E2R.tclTcl script, we add the following command to get the domain

descriptions of the signals: describe -verbose top.* top.gnd.....analog net (electrical) = 0 top.v_in....analog net (electrical) = 2e-07 top.v_out...wire(real)

4. In SimVision, type the following ncsim command to display the IE inserted.

scope -aicms -all

The following report appears: Instance: top.v_in__E2R__discrete_18__1 (merged) is: instance of connect_module: E2R__discrete_18, inserted across signal: top.v_in,


P: 105

and ports of discipline: 1.

The software inserted one E2R connect module.


The simulation completes.

6. Zoom fit and select signals v_in and v_out.

You will change the display format to digital for both signals.


We observe lower activity between 0 and 10 us on v_out: The v_out discrete signal changes 6 times. This

behavior comes from the E2R connect module whose code (in E2R.vams) is as follows: connectmodule E2R (Ain, Dout); input Ain; electrical Ain; //input electrical output Dout; wreal Dout; //output wreal \logic Dout; //discrete domain parameter real vdelta=1.8/64 from (0:inf); // voltage delta parameter real vtol=vdelta/4 from (0:vdelta); // voltage tolerance parameter real ttol=10p from (0:1m]; // time tolerance real Dreg; //real register for A to D wreal conversion assign Dout = Dreg; //discretize V(Ain) triggered by absdelta function always @(absdelta(V(Ain), vdelta, ttol, vtol)) Dreg = V(Ain); endmodule

The absdeltafunction drives the electrical-to-real conversion. Using absdelta, we can generate events whenever the signal changes more than a delta (defined by vdelta) from the previous conversion signal value, and a new conversion occurs.

Summary

This tutorial illustrates real modeling in both Verilog-AMS and VHDL-AMS. It also demonstrates how

to use wreal connect modules so that you can connect real modeling models to Spectre or SPICE or

electrical blocks. Real connect modules offer analog/digital (discrete wreal) conversion with a user-defined

variable rate. wreal connect modules support variable rate signal conversion for better performance. The

absdelta function drives the real connect module A-to-D conversion. Digital events drive the real connect

module D-to-A conversion.


P: 106

5.2 SystemVerilog

Background Modern day analog/mixed signal designs such as high speed SERDEs, RF designs are invariably mixed signal by nature with complex interactions between analog circuits and digital control blocks. As designs grow more and more complex and huge, more accurate analog simulations, even at a significantly high level of abstraction, have become necessary. Facing this challenge, traditional Spice centric block level simulation and full-chip simulation with simple HDL-D models as analog representations are no longer enough. Mixed-signal simulation using with AMS models is becoming increasingly popular to address the needs of accurate yet fast full-chip simulation. Another emerging trend is to blend digital regression methodology into analog/mixed signal. This has been successfully explored and adopted across the industry. As a result, digital languages such as Specman e and SystemVerilog, and SystemC, are being more and more widely adopted in analog/mixed signal validation/regression. Digital centric validation tools such as Specman has been extended to support analog/mixed signal capabilities such as real number read/write to make tasks such as coverage, constraint, regression, etc, possible in analog/mixed-signal application areas. SystemVerilog is a hardware design & verification language that is rapidly gaining popularity. Some of its language features that increase the verification efficiency and quality include:

• Dynamic data types, such as classes and various kinds of arrays • Constrained randomization for stimulus generation • Functional coverage • Property definition and assertions • Advanced use of interfaces for transaction-based verification (TBV) • Interprocess synchronization • Programming constructs, such as clocking blocks, final blocks, and programs • The direct programming interface (DPI)

SystemVerilog and AMS: What is supported and What is not (current as of IUS8.2)

• Establish the "basic flow" with pure digital SystemVerilog testbench and/or pure digital SystemVerilog design blocks and analog/AMS blocks elsewhere in the design. AMS is assumed to not interact with SystemVerilog in any behavioral or structural context. As part of this goal, a separate test suite is planned to be developed with customer cases. This "basic flow" can be characterized as follows:

o SystemVerilog and Verilog-AMS can both be present in the same design

o uses either 3-step (ncvlog, ncelab, ncsim) or single-step (irun). In both modes, SystemVerilog and Verilog-AMS parts of the design must be in separate files, allowing either multiple invocations of ncvlog, or irun to use file suffixes to switch between the different modes.

o no coexistence of SystemVerilog and Verilog-AMS in the same module (i.e. at most one of -sv and -ams options can be given to any compilation)

o SystemVerilog and Verilog-AMS modules can be arranged in any manner of hierarchy, with either language on top or at leaf level, and the two languages interspersed (sandwich mode) at different levels of the hierarchy

o hierarchical connections are allowed between SystemVerilog and Verilog-AMS, however limited to the following types of connections:


P: 107

� currently supported connections between existing Verilog-2001 and Verilog-AMS data objects (this includes items from SystemVerilog packages)

o no use of analog nets (this includes nets that become analog due to discipline resolution) in SystemVerilog assertions

o OOMR's in analog blocks which reference items in SystemVerilog modules may only reference types which would also be allowed in hierarchical connections between the two languages

o no referencing of analog nets via OOMRs in SystemVerilog context

This module focuses on basic SystemVerilog-AMS verification with irun in both AMS-Ultrasim and AMS-Spectre. The goal of the testcase is to demonstrate how a core digital verification concept, such as coverage, applies to a mixed-signal block with both SV and AMS content (following rules of co-existence as stated above) present.

Test Case Description The test case in this tutorial is to use a SystemVerilog test bench (mem_test.sv) to verify an 8X32 synchronous memory block (mem.vams). Here is a block diagram

• Functionality Description

• data_in is written to memory[addr] on the positive edge of clk when write =1. • data_out is assigned by memory[addr] on the positive edge of clk when read=1. • read and write should never be simultaneously high.

• File Descriptions o Tree for directory tutorial:

. |_amscf.scs |_clean |_probe.tcl |_README |_run |_source | |_mem7-virtual.vams


P: 108

| |_mem_test.sv | |_top.sv |_top.scs

o Source files � mem.vams: memory DUT, Verilog-AMS module � top.sv: SystemVerilog module, top level wrapper that instantiates both memory (mem) and

the memory test (mem_test) module. It also generates the clock � mem_test.sv: the testbench, the SystemVerilog language features used in this module

include • write_mem and read_mem tasks • Class and class randomization to generate directed-random stimulus • Functional coverage

o run: run script for AMS-Spectre and AMS-Ultrasim o probe.tcl: Tcl script o amscf.scs: analog control file for AMS Ultrasim and AMS Spectre o clean: clean up script

Here is the timing diagram for memory write and read

Running the Tutorial The case “sv_ams” will be used in this tutorial. To run the tutorial using AMS-Spectre, do the following: Action 1: Change to the tutorial directory, sv_ams, and browse through the directory structure and files Action 2: Open mem.vams which is the memory DUT in Verilog-AMS. Action 3: Open mem_test.sv, memory test module in SystemVerilog. Pay attention to what languagegs features are used for verification and the way they are used. Action 4: Open top.sv, top level wrapper that instantiates both memory DUT and mem_test module. It also generates a clock. Action 5: Open run script, please note how irun is used for SystemVerilog-AMS verification. Action 6: Run simulation with AMS-Spectre, type


P: 109

./run Action 7: Start SimVision: simvision & Action 8: Load wave.trn from the waves.shm directory Action 9: Browse through the signals, and also pay attention to the connect elements inserted Action 10: Exit SimVison.

Action 11 (Optional): Use Incisive Comprehensive Coverge to view coverage results to analyze the Coverage Data. To run the Incisive Comprehensive Coverage (ICC) analysis tool in the graphical mode:

iccr -gui & • Using the File menu, open the functional coverage file cov_work/design/test/icc.fcov • At the bottom of the Coverage Totals window select the Functional tab. • Expand the Data-Oriented Coverage tree. • Expand your address coverpoint and select the automatically created bin. You will most likely see some address values never covered and some address values covered multiple times. • Expand your data coverpoint. You should see no coverage of the default values and much more coverage of lowercase values than uppercase values. The longer you run the test, the more closely the bins reflect your weighting.

Action 12: To run AMS-Ultrasim, type ./run –amsf

Summary Upon completing this tutorial, you have explored how to use SystemVerilog advanced verification features for Analog/Mixed signal verification.

5.3 AMSD wreal $table_model

This workshop is for first-time users of AMS-D wreal $table_model, who want to use wreal $table_model, in the stand-alone mode, irun command, to replace transistors circuit by a table model in their designs in terms of functionality and timing. We assume that you are familiar with wreal and SPICE format and basic UNIX commands and AMS-D Irun command.

5.3.1 Introduction of Wreal $table_model

$table_model is supported in the Verilog-AMS analog block for years. The $table_model can use sweep data which can be measured on real applications or by simulator using real numbers. This tutorial shows the new capability available since the release of AMS-D in IUS8.2. The $table_model can now be used in the digital context with the event solver and wreal models. We are introducing how you can generate sweep data measurement table and reused it with wreal $table_model table. The data in the table model file must be in the form of a family of ordered isolines. An isoline is a curve of at least two values generated when one variable is swept and all other variables are held constant. We will meaure a SPICE inverter characteristic during the transition using probe2table Verilog-AMS module and save the measured input and output voltage values in an ASCII file ordered isolines values.


P: 110

5.3.2 $table_model test case description

This test case is an inverter application. Inverter circuit is the simplest CMOS logic gate. The process used is 1.2v. When a high voltage (1.2 V, in our current case) is applied at the input, the bottom transistor (N-type) is conducting (switch closed) while the top transistor behaves like an open circuit. Hence, the output voltage is low (0 V). Prob2table module will capture this transfer function, which we will reuse with the $table_model.

Figure 5.3.1 Test bench functionnal inverter measurement

The design/test bench directory structure as follows: Wreal_modeling |_1_run_table_creation : run script measuring and creating the table model |_2_run_table_inverter : run script using two inverters table models |_amscf.scs : AMS control file used for the 1_run_table_creation |_clean_up : clean up script |_probe.tcl : probe.tcl script for signal probing during 2_run_table_inverter |_README.pdf : readme file |_simvision.svcf : simvision waveform post processing setup for 2_run_table_inverter |_source : source sub directory | |_clock_gen.v : clock generator | |_spice : SPICE source sub directory | | |_inv.sp : SPICE inverter description with the power supply source | | |_model : SPICE model sub directory | | |_AgeNMOS.mod : nmos model card | | |_AgePMOS.mod : pmos model card | |_vams : Verilog-AMS subdirectory | | |_inv_table.vams : wreal inverter using the table model | | |_inv_table_tb.vams : wreal inverted test bench for the step two. | | |_measure_inv_tb.vams : inveter test bench for the creation of the table model | | |_probe2table.vams : Verilog-AMS module creating the ASCII table model | | |_square_gen.vams : wreal square wave generator used in step two | | |_step.vams : wreal ramp generator | |_verilog : Verilog-HDL sub directory | |_clock_gen.v : clock generator |_table2d.dat : table values for the inverter table model.


P: 111

5.3.3 Run simulation of wreal $table_model

Generate sweep data measurement table for a SPICE inverter

Action 1: Change to the wreal_table_modeling directory.

% cd wreal_table_modeling Action 2: Look at the probe2table.vams file.

% more probe2table.vams `include "disciplines.vams" `timescale 1ns/100ps module probe2table ( a, b, clk ); input a, b, clk; electrical a, b; parameter lsb=1u; real previous_b_value=0; integer fptr; integer index=1; initial begin fptr = $fopen("table2d.dat", "w"); if( !fptr ) $stop; $display(" >> We open the data file for writting" ); previous_b_value = V(b); end always @( posedge(clk)) begin if (V(b) - previous_b_value > lsb ) begin // When the value increases from 1 lsb we write in the table

$fwrite(fptr, "%d %1.9f %1.9f\n", index, V(a), V(b) ); $display(">> We write in the data file t=%-6d ns V(a)=%1.9f V(b)=%1.9f ", $time, V(a), V(b) ); previous_b_value = V(b); index = index +1; end end endmodule The above module will create the table2d.dat table file. We save values when they are different versus the previous one.

Action 3: launch the run script generating sweep data measurement table

% 1_run_table_creation. We are using irun command with an ams control file which contains an amsd block. A config command in the amsd block is used to select a SPICE subcircuit representation for the inverter. At the end of the simulation an ASCII table has been created with the input and corresponding values.

Using the inverter sweep data measurement table for creating a inverter table mode

Action 4: edit the the ./source/vams/inv_table.vams file


P: 112

% nedit ./source/vams/inv_table.vams. We are calling two times the $table model file: first for initialisation and also in an always bloc. The interpolated data is saved to a real variable named y_reg. This y_reg values is assigned to the y wreal output with a delay equal set by td real parameter. Td represents the inverter gate propagation delay. Interpolation and extrapolation techniques are then used to estimate a new value from the set of known values. First character controls interpolation/lookup. The next two characters control extrapolation. For the table we are using a linear extrapolation. This is defined with the L of the control string "I,1L.”. `define TABLE_FILE_NAME "table2d.dat" `timescale 1ns / 100ps module inv_table ( a, y ); output y; wreal y; parameter real td=10p; // inverter propagation delay input a; wreal a; real y_reg; real delay_ns= td / 1.0e9; initial begin y_reg = $table_model(a,`TABLE_FILE_NAME , "I,1L"); end always @(a) begin #delay_ns y_reg = $table_model(a,`TABLE_FILE_NAME , "I,1L"); end assign y = y_reg; endmodule

Action 5: Run AMS-D simulation and wait until the simulation completes.

%./2_run_table_inverter Then, ncsim> run

Note:

We are running two inverter table models. Viewing the simulation results

We display the signals at top level. Action 6: View the results and check the two inverter table operations using a previously saved command script.

[SimVision: Design Browser] File � Source Command Script…

Action 7: In the “Select SimVision Command File” window, select file simvision.svcf and click OK.


P: 113

Figure 5.3.2 Simvision source command script

You should see all the input (neta) and output (nety) waveforms displayed in the digital format they are the input and output of the first inverter. (netb) and (nety) are the input and output of the second inverter under test with a ramp stimuli.

Fig. 5.3.3 Output of Multi16 simulation

Action 8: Exit SimVision.

Conclusion You measured a SPICE inverter characteristic. Simulating the inverter, we did the generation of sampled data points and saved the behavior in a table model. We use the measurement table for the wreal table_model inverters. Data based modeling technology in Verilog-AMS is now extended to the digital context.


P: 114

5.4 Global Wreal Driver Resolution

5.4.1 Background

Note: This tutorial is for the AMS Designer simulator in the IUS 8.2 release (November 2008). The estimated time to complete this tutorial is about 15 minutes. IUS82 provides support for multiple drivers on a wreal net via Global Wreal Driver Resolution Function This tutorial focuses on differentiating the six global wreal driver resolution functions. The choice is done with a command line option -wreal_resolution to irun or ncelab that will allow the user to select a resolution function when there are multiple wreal drivers on the same net. This -wreal_resolution option will take exactly one argument corresponding to the global multi drivers resolution function to be used for all wreals in the design. The format of the wreal_resolution option is as follows: -wreal_resolution <default | 4state | sum | avg | min | max> If no -wreal_resolution option is given to ncelab the default resolution function will be used for all wreal nets having multiple drivers in the design


The test case based on two Verilog-AMS files named top.vams, wreal_gen.vams. In wreal_gen.vams we coded a wreal generator which periodically assigned different wreal value (`wrealZState, `wrealXState, 1.0, 2.0) to the wreal output port. The top.vams intantiates two wreal_generators I0 and I1. Their wreal port outputs are connected to the same wreal net. Also we have two drivers for the same wreal net. The wreal_generator instance I1 is changing periodicity with a time width four times larger than the wreal_generator instance I0. The simulation time is defined to cover the 4*4=16 possible wreal output values. An irun TCL script, named run.tcl, checks the wreal_resolution operation for each wreal output values. This is limited example for four multiple drivers output values checked by run.tcl script

-------- wreal Periodic Verification --------------------------------------

t=15 NS top.I0.y_reg=`wrealXState, top.I1.y_reg=`wrealZState

The wreal multi drivers resolution function gives:

top.I0.y=`wrealXState, top.I1.y=`wrealXState, top.wr_resolved=`wrealXState


t=25 NS top.I0.y_reg=1, top.I1.y_reg=`wrealZState


top.I0.y=1, top.I1.y=1, top.wr_resolved=1


t=35 NS top.I0.y_reg=2, top.I1.y_reg=`wrealZState


top.I0.y=2, top.I1.y=2, top.wr_resolved=2


t=45 NS top.I0.y_reg=`wrealZState, top.I1.y_reg=`wrealXState


top.I0.y=`wrealXState, top.I1.y=`wrealXState, top.wr_resolved=`wrealXState



P: 115

t=55 NS top.I0.y_reg=`wrealXState, top.I1.y_reg=`wrealXState


top.I0.y=`wrealXState, top.I1.y=`wrealXState, top.wr_resolved=`wrealXState The test case directory/file structure overview is as follows: real_resolution_function. |_1_run_default : run script testing default wreal_resolution |_2_run_4state : run script testing 4state wreal_resolution |_3_run_sum : run script testing sum wreal_resolution |_4_run_avg : run script testing avarage wreal_resolution |_5_run_min : run script testing min wreal_resolution |_6_run_max : run script testing max wreal_resolution |_clean_up : clean up script |_README : readme file |_run.tcl : TCL script checking the wreal_resolution operation |_run_all : run script for testing the six resolution functions |_source : source subdirectory |_top.vams : tops test bench

|_wreal_gen.vams : wreal stimuli generator


The recommended software version AMS-D 8.2 (from IUS8.2) or latter Before running the tutorial, verify that your AMS Designer installation is set up and working.

Action 1: In a terminal window, copy the wreal_resolution_function.tar.gz file to your directory, untar the file and then change to the directory wreal_resolution_function. % cp wreal_resolution_function tar.gz <your work directory> % gtar - zxvf wreal_resolution_function tar.gz % cd wreal_resolution_function

Action 2: Open source/wreal_gen.vams. This wreal generator periodically assigned different wreal values(`wrealZState, `wrealXState, 1.0, 2.0) to the wreal output port module. You should observe that we can assign to a real variable the high impedance `wrealZState and unknown `wrealXState values.

`timescale 1ns / 1ns

module wreal_gen ( y );

output y;

wreal y;

parameter real time_width=10n;

parameter real v1= 1.0;

parameter real v2= 2.0;

parameter integer nb_repeat=16;

real y_reg;

real delay_ns= time_width * 1.0e9;

initial begin

repeat (nb_repeat) begin

y_reg=`wrealZState;

#delay_ns;

y_reg=`wrealXState;

#delay_ns;

y_reg=v1;

#delay_ns;

y_reg=v2;


P: 116

#delay_ns;

end

end

assign y = y_reg;

endmodule

Action 3: Open source/top.vams test bench. We have two wreal drivers for the same wreal net named

wr_resolved ``timescale 1ns / 1ns

module top ( );

wreal wr_resolved;

wreal_gen #(.time_width(10n)) I0 (wr_resolved);

wreal_gen #(.time_width(40n)) I1 (wr_resolved);

endmodule;

Action 4: Launch the six simulations. Each simulation is using a using different global Wreal Driver

Resolution Function. un_all script starts the six CSH scripts named 1_run_default 2_run_4state 3_run_sum 4_run_avg 5_run_min 6_run_max. The difference between each script is the -wreal_resolution option argument used (default | 4state | sum | avg | min | max). Each script will generate a logfile named default.log , 4state.log, sum.log, avg.log, max.log, min.log.

% run_all

Action 5: It is interesting to compare the six wreal_resolution to understand the differences. We suggest two solutions:

a) Increase your UNIX shell terminal to be able to display at least 125 characters, in a line. Check the wreal_resolution default versus 4state differences by launch the UNIX command % sdiff -d default.log 4state.log. Look to the differences.

b) If you have installed the tkdiff graphical front end to the diff program You could use it.. tkdiff provides a side-by-side view of the differences between two files. ( It can be downloaded from the URL http://tkdiff.sourceforge.net). Instead of sdiff you will use tkdiff. % tkdiff default.log 4state.log. Look to the differences.

Action 6: Repeat the step 5, with the sum.log % sdiff -d default.log sum.log.

Action 7: Repeat the step 5, with the sum.log % sdiff -d default.log sum.log.

Action 8: Repeat the step 5, with the avg.log % sdiff -d default.log avg.log.

Action 9: Repeat the step 5, with the min.log % sdiff -d default.log min.log.

Action 10: Repeat the step 5, with the mac.log % sdiff -d default.log max.log.

Summary


P: 117

Upon completing this tutorial, you have learned IUS82 provides support for multiple drivers on a wreal net. The user can select a resolution function when there are multiple wreal drivers on the same net. This choice is global for the full design in this IUS82.1 version. In the future AMS-D will support local wreal resolution function. As a designer using wreal for system modeling, you must select the correct wreal multiple drivers resolution function based on you needs.

5.5 AMSD VHDL-SPICE

This workshop is for first-time users of AMS-D VHDL-SPICE, who want to use VHDL-SPICE, in the stand alone mode, irun command, to simulate their transistor-level designs in terms of functionality, timing, and power with VHDL test bench. It is assumed that you are familiar with VHDL and Spice format and basic UNIX commands and AMS-D Irun command...

5.5.1 Introduction of VHDL-SPICE

IEEE 1076 (VHDL) standard or VHDL-AMS IEEE Std 1076 ( IEEE Standard VHDL Analog and Mixed-Signal Extensions) do not provide a method to connect an VHDL entity to a SPICE sub circuit. This tutorial shows the new capability available since the release of AMS-d in IUS8.2.

5.5.2 Introduction of VHDL-SPICE conversion elements

We are introducing conversion elements. The CE card is VHDL-Spice conversion element card. With this feature, you could specify the conversion element (VHDL-IE). The CE card provides flexibility to the users to define, select the VHDL conversion elements for various VHDL-D (signal) to analog (spice) connections in a design. The user can also specify the values of various generics in a conversion element to control the accuracy and performance of the inter-kernel value conversions. The CE card specification can also allow users to define the conversion element for a given scope of the design based on the library, cell name. For IUS8.2, we allow the specification the cell name for which the CE card can be specified. The specification of scope is optional. If unspecified, the CE card will apply to the whole design.

5.5.3 VHDL-SPICE Test case description

This test case is a 16 bits multiplier application with 13732 bsim3v3 MOS models. The clock and input stimuli models are coded with VHDL language. The 16 bits multiplier DUT is implemented at transistor level.


P: 118

Figure 5.5.1 Test bench functionnal diagram

This is an overview of the SPICE multiplier sub circuit. The transistor implementation is a 16-bit x 16-bit parallel unsigned multiplier topology. *************************************************************** * A<15:0> 16-bit multiplier input * B<15:0> 16-bit multiplier input * P<31:0> 32-bit product output * PRD<31:0> 32-bit product output before the output register * CLK clock input * RegA 16-bit input register(postive edge triggered) * RegB 16-bit input register(postive edge triggered) * RegP 32-bit output register(postive edge triggered) * * ---- * 16 | | * A<15:0> ----/-->|RegA|--------+ * | | | * +---->| | v * | ---- ---------- PRD<31:0> * | | | ---- * | | 16x16 | 32 | | * | |Multiplier|---/---|RegP|--/--> P<31:0> * | | array | | | 32 * | | | +-->| | * | ---------- | ---- * | ---- ^ | * | 16 | | | | * B<15:0> ----/-->|RegB|-------+ | * | | | | * +---->| | | * | ---- | * CLK --+----------------------------+ * *

The design/test bench directory structure as follows: vhdl_spice_multi |_amscf.scs : ams control file


P: 119

|_amscf_forSpectre.scs : ams control file used for Spectre solver. |_clean_up : clean up sript |_models : models directory | |_nmos.mod : nmos model file | |_pmos.mod : pmos model file |_mult16.net : multiplier full design SPICE netlist |_README : README FILE |_run : run script for AMS-D+Ultrasim solver |_run.tcl : TCL script for AMS-D |_run_spectre : run script for AMS-D+Spectre solver |_run_spectre_tubo : run script for AMS-D+Spectre Turbo solver |_simvision.svcf : Simvision postprocessing script |_source: : Source sub directory |_a_b_gen.vhd : VHDL A and B stimuli generator |_clock.vhd : VHDL clock generator |_mult16x16_spice.vhd : VHDL multiplier entity |_top.vhms : VHDL top test bench

5.5.4 Simulating a 16-bit SPICE multiplier with VHDL digital stimuli

Action 1: Change to the vhdl_spice_multi directory.

% cd vhdl_spice_multi Action 2: Look at the multiplier netlist file, mult16.net.

% more mult16.net The 16*16 bits multiplier has two 16-bit inputs (A<15:0>, B<15:0>), a clock input (CLK), and a 32-bit output (P<31:0>).

Action 3: Look at the. mult16x16_spice.vhd

% more source/mult16x16_spice.vhd. This is16*16 bits multiplier VHDL unit of the two 16-bit inputs (A<15:0>, B<15:0>), a clock input (CLK), and a 32-bit output (P<31:0>). It defines the directions for the converter element insertion between SPICE and VHDL.

LIBRARY IEEE; USE IEEE.STD_LOGIC_1164.ALL; ENTITY mult16x16_spice IS PORT ( A : in std_logic_vector ( 15 DOWNTO 0 ); B : in std_logic_vector ( 15 DOWNTO 0 ); CLK : in std_logic; P : out std_logic_vector( 31 DOWNTO 0 )); END ENTITY mult16x16_spice; ARCHITECTURE spice_skeleton OF mult16x16_spice IS BEGIN END ARCHITECTURE spice_skeleton;


P: 120

The 16*16 bits multiplier has two 16-bit inputs (A<15:0>, B<15:0>), a clock input (CLK), and a 32-bit output (P<31:0>). Clock signal type is std_logic, and the buses are std_logic_vector type. .

Action 4: Look at the source/top.vhms file

% more source/top.vhms We have the VHDL test bench definition. LIBRARY ieee; USE ieee.math_real.ALL; USE IEEE.STD_LOGIC_1164.ALL; USE IEEE.ELECTRICAL_SYSTEMS.all; LIBRARY STD; USE STD.textio.all; LIBRARY worklib; USE worklib.ALL; ENTITY top IS END top; ARCHITECTURE bhv OF top IS SIGNAL sa : std_logic_vector (15 downto 0); SIGNAL sb : std_logic_vector (15 downto 0); SIGNAL sp : std_logic_vector (31 downto 0); SIGNAL sclk : std_logic; BEGIN Iclk: ENTITY work.clk_gen PORT MAP ( clk => sclk); Iab: ENTITY work.a_b_gen PORT MAP ( clk => sclk, a => sa, b => sb); SPICE_DUT: ENTITY worklib.mult16x16_spice PORT MAP (sa , sb, sclk, sp); END ARCHITECTURE bhv;

The 16 bits multiplier is directly instantiated in the testbench.

Action 5: Look at the AMS control file amscf.scs.

% more amscf.scs * AMS Control file for AMSD+Ultrasim

include "mult16.net"

simulator lang=spectre

timedomain tran stop=6u

amsd {

portmap subckt=mult16x16_spice autobus=yes refformat=vhdl

reffile=source/mult16x16_spice.vhd


P: 121

config cell=mult16x16_spice use=spice

ce name=worklib.std_logic2e dir=input type=std_logic genericmap="vsup 2.5"

ce name=worklib.e2std_logic dir=out type=std_logic genericmap="vsup 2.5"

}

simulator lang=spice lookup=spectre

.op

.probe v(*)

.usim_opt sim_mode=dx subckt=[ mult16x16_spice ]

The AMS control file includes the full multiplier SPICE netlist. In addition it specifyes for AMS-D simulator that the VHDL unit named mult16x16_spice will be replaced by the SPICE sub-circuit named mult16x16_spice. In the amsd block the config card specifyes that the mult16x16_spice cell will be replaced by a SPICE representation. The portmap provide a reference file were we find the VHDL port types and directions. We are using VHDL autobus generation for the signal std_logic_vector connection to the SPICE netlist.

The ce VHDL-Spice conversion element card spedifies the the conversion element used. The detailed syntax for the CE card is given below: ce <name=value> <type=value> [dir=value] [cell=value] [genericmap=value] name : conversion element name with the compilation library name=mylib.std_logic2e (or name=mylib.std_logic2e:arch) dir : direction for the digital port, default is 'inout', example, dir=input (or direction=in) cell : The name of the architecture (cell) which can use the specified conversion element. This is an optional specification. type: The digital signal type that is connected to Spice (analog) blocks genericmap: genericmap for the conversion element for overriding the generic values. These are needed if user wants to override the generic values. In our example, we are using std_logic provided in AMSD installation as examples. You can use your own conversion elements.

Action 6: Look at the run

% more run The clean_up remove the previous files. It is followed by the irun compilation of the converter elements in the worklib.

It is followed by two irun commands. The first irun command compiles the conversion elements. The second launch the simulation with the ams control file. We specify the usage of Cadence FastSpice solver for the analog blocks of the design(-amsf). UltraSim solver will simulate the 16-bit multiplier sub circuit.

irun -compile -mess `ncroot`/tools/affirma_ams/etc/vhdlams_connectlib_samples/*.vhms irun -access +r -v93 -top top -gui -mess \ amscf.scs \ source/a_b_gen.vhd source/clock.vhd source/top.vhms \ -amsf \ -input run.tcl


P: 122

Action 7: Run AMS-D simulation and wait until the simulation completes.

%./run

Note:

You are running 15 multiplications at transistors level. Ultrasim sim_mode=dx is set on the spice subcircuit. The AMS-D+Ultrasim runs the 13K MOS transistors simulation in 12 seconds!.

Viewing the simulation results

We display the signals at top level. Action 8: View the results and check the 16 multiplier operations.

using a previously saved command script.

[SimVision: Design Browser] File � Source Command Script…

Action 9: In the “Select SimVision Command File” window, select file simvision.svcf and click OK.

Figure 5.5.2 Simvision source command script

You should see all the input and output waveforms displayed in the digital format. SP is equal to A value * B value,

after a period cycle delay.

Fig. 5.5.3 Output of Multi16 simulation

Understanding the converters elements insertion

Action 10: When you launch the run command, at the irun simulation snapshot elaboration the simulator created the SPICE

multiplier skeleton. Read the SPICE multiplier skeleton file:

% more .ams_spice_in/generated_skeleton_amscb.skl_vhdl We observe the DA_converter and AD_converter insertions done automatically in the spice_skeleton OF mult16x16_spice entity. It supports the bus type STD_LOGIC_VECTOR automatically..


P: 123

LIBRARY IEEE; USE IEEE.STD_LOGIC_1164.ALL; USE IEEE.ELECTRICAL_SYSTEMS.ALL; LIBRARY CDS_SPICELIB; USE CDS_SPICELIB.CDS_SPICESKELETON_LIB.ALL; LIBRARY worklib; ENTITY mult16x16_spice IS PORT ( A : in STD_LOGIC_VECTOR ( 15 DOWNTO 0 ); B : in STD_LOGIC_VECTOR ( 15 DOWNTO 0 ); CLK : in STD_LOGIC; P : out STD_LOGIC_VECTOR ( 31 DOWNTO 0 )); ATTRIBUTE spiceskeleton OF mult16x16_spice : ENTITY IS "./amscf.scs"; END ENTITY mult16x16_spice; ARCHITECTURE spice_skeleton OF mult16x16_spice IS ATTRIBUTE spiceskeleton OF spice_skeleton : ARCHITECTURE IS "./amscf.scs"; ATTRIBUTE spicename OF spice_skeleton : ARCHITECTURE IS "mult16x16_spice"; ATTRIBUTE spicesfversion OF spice_skeleton : ARCHITECTURE IS "2.0"; ATTRIBUTE spicebus OF spice_skeleton : ARCHITECTURE IS "A=A;<15:0>, B=B;<15:0>, P=P;<31:0>"; TERMINAL A_tempnode_0 : ELECTRICAL; TERMINAL A_tempnode_1 : ELECTRICAL; TERMINAL A_tempnode_2 : ELECTRICAL; .......... TERMINAL A_tempnode_64 : ELECTRICAL; BEGIN DA_converter_0 : ENTITY worklib.std_logic2e GENERIC MAP (vsup=>2.5) PORT MAP (A(15), A_tempnode_0); DA_converter_1 : ENTITY worklib.std_logic2e GENERIC MAP (vsup=>2.5) PORT MAP (A(14), A_tempnode_1); ......... DA_converter_32 : ENTITY worklib.std_logic2e GENERIC MAP (vsup=>2.5) PORT MAP (CLK, A_tempnode_32); AD_converter_33 : ENTITY worklib.e2std_logic GENERIC MAP (vsup=>2.5) PORT MAP (A_tempnode_33, P(31)); AD_converter_34 : ENTITY worklib.e2std_logic GENERIC MAP (vsup=>2.5) PORT MAP (A_tempnode_34, P(30)); ......... AD_converter_64 : ENTITY worklib.e2std_logic GENERIC MAP (vsup=>2.5) PORT MAP (A_tempnode_64, P(0)); END ARCHITECTURE spice_skeleton;

Note: The mult16x16_spice ARCHITECTURE spice_skeleton, inserted 32 digital to analog converter elements

STD_LOGIC2E and 32 analog to digital converter elements E2STD_LOGIC. Note: Using the Designer Browser you can see these inserted converter elements.


P: 124

Fig. 5.5.4 the conversion elements can be se in the Design Browser

You can debug them with the source browser.


P: 125

Fig. 5.5.5 the conversion elements can be debug in the Source Browser

Running the tutorial with AMS-D Spectre turbo.

Action 10: launch the script named:

% run_spectre_tubo

Total time required for tran analysis `timedomain' was 23 minutes on the same CPU using Spectre turbo the Total

time required for tran analysis `timedomain' became 5 minutes.

Action 11: Exit SimVision.

CONCLUSION You simulated a 16-bit x 16-bit parallel unsigned multiplier topology application with 13732 bsim3v3 MOS models driven by VHDL entities. Using the amsd control bloc from the amscontrol file the setup is easy. You can create you own VHDL-AMS conversion elements. AMSD+ Spectre Turbo provides acceleration in the order from 4 times to 10 times versus AMS-D Spectre. AMSD+UltraSim in DX mode provides an interesting acceleration of 130 times faster versus AMS-D + Spectre.


P: 126

5.6 SystemVerilog Real in AMS Designer

SystemVerilog is a powerful unified hardware description and verification language. As designs grow more complex, the testbench verification environment is required to verify more and more analog content without sacrificing simulation performance. Toward this goal, SystemVerilog language offers variables of real data type to be driven just as nets and as a consequence such real variables can be associated to ports – either declared as an input port or connected to an output port. This capability offers a lot of potential to bring in analog and mixed-signal content into the testbench and participate in testbench driven verification processes such as monitors, assertion, coverage etc.

5.6.1 The purposes of this tutorial

In this tutorial, we are going to talk on how AMS Designer supports SystemVerilog real variable. We will divide the discussion into following parts:

• How AMS Designer supports SystemVerilog-real in general • When SystemVerilog-real connects to wreal in Verilog-AMS • When SystemVerilog-real connects to electrical in Verilog-AMS

The item 2-3 above will be based on the configuration of SystemVerilog on top instantiating Verilog-AMS/spice.

5.6.2 How AMS Designer supports SystemVerilog-real in general

The following information provides a general introduction as of IUS82 USR4. Due to the lack of a comprehensive SystemVerilog-AMS language, SystemVerilog and AMS modules in a design must exist in different source files. A SystemVerilog scope must not contain any electrical net, including nets that become electrical as a result of discipline resolution or nets of electrical discipline referenced via Out of Module Reference (OOMR). Conversely, any OOMR of a SystemVerilog item from a Verilog-AMS or VHDL-AMS scope may only reference types that can be used in hierarchical connections between the two languages. In general, you may have hierarchical connections between SystemVerilog and Verilog-AMS, as long as the connections consist of those the AMS Designer simulator currently supports between existing Verilog-2001 and Verilog-AMS data objects. How SystemVerilog-real connected to AMS can be discussed in the following design configurations. SystemVerilog on top instantiating Verilog-AMS

SystemVerilog is often used as a top-level testbench in the verification methodology. The design case in this tutorial will be focusing on this kind of configuration.

• SystemVerilog-real connects to wreal in Verilog-AMS module underneath In this case, SystemVerilog-real will be automatically connected to wreal in Verilog-AMS module without the insertion of any converter modules. The wreal port can be input, output or inout. Refer to the scenario 1 in this tutorial case.

• SystemVerilog-real connects to electrical in Verilog-AMS module underneath In this case, a Real2Electrical Connect Module (R2E) or Electrical2Real (E2R) will be automatically inserted between SystemVerilog-real and Verilog-AMS-electrical. The electrical port can be input or output. inout can’t participate in such connection, since SystemVerilog-real supports single driver only, i.e. unidirectional.


P: 127

Refer to the scenario 2 in this tutorial case. Verilog-AMS on top instantiating SystemVerilog SystemVerilog is sometimes used as a functional block or a stimulus generator, which instantiated in Verilog-AMS top testbench.

• Verilog-AMS wreal connects to SystemVerilog-real underneath If the port of the Verilog-AMS block is of wreal type, a conection is established with the SystemVerilog real variable without the need for any connection module.

• Verilog-AMS electrical connects to SystemVerilog-real underneath If the port of the Verilog-AMS block is of electrical discipline, which connects to real variable in SystemVerilog, currently this configuration is not supported. SystemVerilog on top instantiating Spectre/HSPICE In the verification flow, to get close-to-silicon accuracy, some critical functional blocks usually use Spectre/HSPICE netlist instead of any behavioral modules.

• SystemVerilog-real connects to SPICE primitives underneath Spice primitives such as resistor, capacitor or MOSFET, or primitives from CMI libraries, or primitives that are brought in via the MODELPATH option are not recognized by SystemVerilog and the tool will look for a regular master of the same name, failing which the elaboration step would exit with error.

• SystemVerilog-real connects to a SPICE subckt underneath A Spice subckt can be instantiated in SystemVerilog with restriction if the connection is made using the SystemVerilog real variable. This is because SystemVerilog real variable cannot be connected to bidirectional (inout) ports since it can only support a single driver. In AMSD Incisive Use Model (AIUM), the direction of each port of the subckt must be clearly specified using any of the following three ways. a. By using the “reffile” option on the AMS control block portmap card - this points back to the original Verilog AMS file from which the port directions are taken b. Via an “input” or “output” option on the port in question on the AMS control block portmap card c. Via a “file” option for a port bind file specified on the AMS control block portmap card, which contains explicit instructions for mapping spice ports to ports in the generated skeleton ‐ these instructions can include port directions. Each port of the subckt must be clearly designated


The test case in this tutorial is to use a SystemVerilog test bench (top.sv) with vco_vin as a real, to verify an 8X32 synchronous memory block. A clock signal, clk, is created by VCO and is sent to mem_test.sv, the stimulus generator in SystemVerilog and mem.v, the memory module in verilog. Here is a block diagram.


P: 128

The signal of vco_vin is specified as real variable in top.sv, and is sent to VCO as the input for control voltage. VCO in turns generates clk. In this tutorial, VCO will be presented as the following two different abstracts.

• Scenario 1: Verilog-AMS behavioral with vco_in specified as wreal • Scenario 2: Verilog-AMS behavioral with vco_in specified as electrical

Functionality Description as follows

• data_in is written to memory[addr] on the positive edge of clk when write =1 • data_out is assigned by memory[addr] on the positive edge of clk when read=1 • read and write should never be simultaneously high

Here is the timing diagram for memory write and read

addr

read

write

data_in

data_out

TEST mem_test.sv MEMORY

mem.v

TOP: top.sv

VCO

vco_vin (real) clk


P: 129

File Descriptions . |_amscf.scs // AMS Control File |_clean_up // clean script |_irun_args1.f // irun argument file for Scenario 1 (VCO with wreal) |_irun_args2.f // irun argument file for Scenario 2 (VCO with electrical) |_probe.tcl // TCL probing file |_run1 // run script file for scenario 1 |_run2 // run script file for scenario 2 |_acf.scs // Analog Control File |_source // directory storing source files |_mem.v // memory module in Verilog, DUT

|_mem_test.sv // memory testbench in SystemVerilog. The SystemVerilog language features used in | this module include tasks (write_mem, read_mem), class and class randomization |_top.sv // top file in SystemVerilog with real, instantiating both memory (mem) | and the memory test (mem_test) modules. Also generates the clock

|_vco_wreal.vams // VCO module in Verilog-AMS with wreal |_vco_electrical.vams // VCO module in Verilog-AMS with electrical


The case “sv_real” will be used in this tutorial. To run the tutorial using AMS-Spectre, do the following: Action 1: Change to the tutorial directory, sv-real, and browse through the directory structure and files % cd sv_real Action 2: Open mem.v which is the memory DUT in Verilog. Action 3: Open mem_test.sv, memory test module in SystemVerilog. Pay attention to what language features are used for verification and the way they are used.


P: 130

Action 4: Open top.sv, top level wrapper that instantiates both memory DUT and mem_test module. It also generates a clock. Pay attention on the following declaration: real vco_vin ; //vco_vin is declared as a SystemVerilog "real" variable The following steps will demonstrate the on Scenario 1: how SystemVerilog-real connected to wreal works. Action 5: Take a look at run1 script, and figure out how this script works with AMS Designer simulator (The run script launches irun whose arguments are specified in a arguments file, irun_args1.f, which is sent to irun via –f option). Action 6: Open irun-args1.f file. You should find the vco_wreal.vams used for VCO module Action 7: Check vco_wreal.vams file and pay attention on the following:

wreal vin; //vin is declared as wreal Note in Scenario 1

• real variable is used in SystemVerilog and wreal is used in Verilog-AMS, and no any “electrical” or SPICE is used for analog. Thus, when it is simulated, only digital solver only will be needed

• In the irun-args1.f file, there isn’t “amscf.scs” file which is used to control how analog solver works, including simulation stop time. This is because in a “digital” design, the simulation time is usually controlled by TCL file, or $finish task defined in testbench (mem_test.sv in this case)

• From IUS82 base release, AMS Designer licenses (70020, 70030 or MMSIM token) won’t be able to run such “digital” case

Action 8: Simulate the Scenario 1 by doing %./run1 Action 9: Check the simulation waveform for write/read activities after the simulation is finished. You may notice the simulation stops at around 2,500us. Action 10: Pay attention on the vco_vin waveform in SimVision. If it shows as “linear”, you may change it to “sample+hold” mode from Format -> Trace, so that the real value looks like its true values. Note, its value changes at the beginning of the waveform.

Action 11: Take a look at the log file, run_1_sv-real_to_wreal.log. You should find the followings

• Empty in the “IE Report” section, which means no any converter module are inserted when SystemVerilog-real connected to wreal

• You should find three “PASSED” flags, which means DUT test is successful Next, we are going to run the Scenario 2: how SystemVerilog connected to electrical works. Action 12: Take a look at run2 script, and figure out how this script works with AMS Designer simulator Action 13: Open irun-args2.f file. You should find the vco_electrical.vams used for VCO module Action 14: Check vco_electrical.vams file and pay attention on the following:

electrical vin; //vin is declared as electrical discipline Note in Scenario 2


P: 131

• Since electrical is now also used in Verilog-AMS in this scenario, when it is simulated, analog solver (Spectre in this case) will also be involved

• In AMS, the simulation time is controlled by “stop” option defined in Analog Control File (acf.scs) which usually is included in AMS Control File (amscf.scs). If you check irun-args1.f file, you would find the “amscf.scs” file which include acf.scs in which the “stop” is specified as “30us”. So the Scenario 2 case will run 30us instead of 2,500us, compared to Scenario 1

• AMS Designer licenses (70020, 70030 or MMSIM tokens) will be required

Action 15: Simulate the Scenario 2 by doing %./run2 Action 16: Check the simulation waveform for write/read activities after the simulation is finished Action 17: Pay attention on the vco_vin waveform in SimVision. If it shows as linear, you may change it to sample+hold mode from Format -> Trace, so that the real value looks like its true values.

Action 18: Take a look at the log file, run_2_sv-real_to_elec.log. You should find the followings

• From the “IE Report” section, you should find a R2E Connect Module (CM) was inserted, which means the SystemVerilog real values (vco_vin) were converted into electrical (analogous) signal.

• You should find three “PASSED” flags, which means DUT test is successful

Action 19 (Optional): Use Incisive Comprehensive Coverage to view coverage results to analyze the Coverage Data for this test bench. Coverage analysis highlights you the areas of the design that have not been fully exercised and identifies those parts that did not meet the desired coverage criteria. Launch the run1 script

In both irun arguments files scripts, we set the irun code Coverage options.

-coverage all -covoverwrite

The goal is to generate code coverage for our test bench and to ensure verification completeness. (see the ICC User Guide provides in-depth information on coverage analysis) Now we can look the code coverage results. Invoke the reporting tool iccr Incisive Comprehensive Coverage (ICC) analysis tool in the graphical mode, using the following command:

% iccr -gui & • Using the File menu, open the functional coverage file cov_work/design/test/icc.fcov Combined results (block, expression, and toggle) for the design is 86% for the module and 86% for the instance. Control-oriented functional coverage is 100% and Data-oriented coverage is 100%. • At the bottom of the Coverage Totals window, click the Code/Data tab. We can Perform the analyze coverage data for block, expression, and toggle coverage: Click the + sign against the instance name top > vco_a.


P: 132

The tree expands, listing the names of the cells and the percentage statistics of code coverage. Notice that the coverage for vco_a is reported as 100%. Coverage figure less than 100% indicates that there are unexercised blocks, expressions, or untoggled signals within the design.

• At the bottom of the Coverage Totals window select the Functional tab • Expand the Data-Oriented Coverage tree. • Expand your address coverpoint and select the automatically created bin. You will most likely see some address values never covered and some address values covered multiple times. • Expand your data coverpoint. You should see no coverage of the default values and much more coverage of lowercase values than uppercase values. The longer you run the test, the more closely the bins reflect your weighting.

Summary Upon completing this tutorial, you have explored how SystemVerilog-real is supported with AMS Designer, how you should configure your SystemVerilog-real design into AMS Designer.

Workshop for AMSD Incisive Use Model

Documents

Transcript of Workshop for AMSD Incisive Use Model