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
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 Cadences
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.
Document Update History

This section contains a history of all revisions to this document.
Revision
Number
Date
Author Name
1.7
Mar. 13,
2009
AMS PE
1.8
Sep 28, 2010
AMS PE
Comments
UPDATE:
ams_aps
ams_cpf
ams_ncf
amsd_saverestart
packngo
vhdl_spice_multi
wreal_resoluton_function
wreal_table_modeling
Added: Spice-on-top
Update: ams_aps
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
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:

AMSD Incisive Use Model:
ADE + OSS + irun

irun + AMS Control File
AMSD Use Models
AMS Designer
(with UltraSim, Spectre or
APS as analog solver)
AMSD Virtuoso Use Model (GUI Based)
AMSD Incisive Use Model (Text Based)
AMSD in ADE
(OSS+irun)
irun
+ AMS Control File
IUS & IC
IUS only
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:
Whats AMSD Incisive Use Model

Whats the basic usage for the AMSD Incisive Use Model
What kind of the advanced features does this Use Model have
Whats 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:
AMSS:
AMSU:
AIUM:
AVUM:
AMSCF:
amsd block:
ACF:
Card:
OOMR:
CM:
Crule:
IE:
BDR:
SFE:
AMS Designer simulator

AMSD with Spectre as the analog solver
AMSD with UltraSim as the analog solver
AMSD Virtuoso Use Model
AMS Control File, Analog and Mixed-signal inputs to the AMSD simulator, containing amsd
block, ACF and include statements for analog stuff
amsd block is a block consisting of ams cards like, portmap, config and ie
Analog Control File, analog control statements for analog solvers
Spectre/SPICE terminology for a Spectre/SPICE statement or command. Now is used in amsd
block as well, like portmap card, ie card, etc.
Out Of Module Reference, references cross the modules
Connect Module, the converter between Analog and Digital signals
Connect Rule, the file specifying which CM and what parameter values used in the design
Interface Element, spectreVerilog term, same thing as Connect Module
Block-based Discipline Resolution, used for the design with multiple power supplies
Simulation Front End analog parser
P: 2
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 digitalcentric 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 dont 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.
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: 3
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 SOCs 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.
Basic Application
Extensions
Verilog/AMS + SPICE AMS Simulation
SystemVerilog
VHDL
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
VHDL-AMS
Matlab
SpecMan
SystemC
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.
P: 4
Chapter 2 User Guideline for AMSD Incisive Use Model

The AIUM has been streamlining: three-step (ncvlog/ncelab/ncsim), ncverilog and now irun.
Digital Design/Testbench
Digital Design/Testbench
cds.lib
Not needed
cds.lib
worklib
Not needed
worklib
modelpath
Prop.cfg
Probe TCL
Analog ctrl file
discipline
timescale
Hdl.var
-amsconnrules
Moved to CB or *.scs for irun
modelpath
Moved to AMSD BLOCK
AMS Ctrl File
NC stuff and no change
Probe TCL
Moved to AMSD BLOCK
Analog ctrl file
Moved to AMS CB
NC stuff and no change
discipline
timescale
Moved to AMS CB
BDR
Not needed
-ams
irun in IUS8.1
CM/Crule
Ncvlog/ncelab/ncsim
Hdl.var
Not recommended
CM customization
Crule name
BDR
-ams
Analog Design
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.
P: 5
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: 6
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.
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 cant 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: 7
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 doesnt know the verilog-ams format.
When design has transistor-level verilog-AMS netlist
P: 8
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: 9
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.
Pll_top
refclk
PD
up
(HSPICE
vcoclk
down
)
CP
(HSPICE
)
vcop
vcom
VCO
(VerilogA
)
p0
Clock[2:0]
Counter
(Verilog) vcoclk
Divider
(Verilog)
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
P: 10
|-- 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 dont have to declare the electrical discipline to any wires even they are
connected to the ports of analog instances. And so you dont 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: 11
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 \
./amscf.scs \
-amsfastspice \
-timescale 1ns/100ps \
-input probe.tcl
//dig testbench and design modules

//AMS Control File
//fastspice (UltraSim) switch
//timescale definition
//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 {
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 isnt 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 {
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: 12
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: 13
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: 14
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 customers 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: 15
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 wont 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:
|
ncelab: *E,CUVSOE (./source/digital/testbench.v,32|35): OOMR
'testbench.pll_top.vcom' refer into SPICE error.
|
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
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:
|
ncelab: *W,CUVSOW (./source/digital/testbench.v,32|35): The out-of-modulereference '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.
|
ncelab: *W,CUVSOW (./source/digital/testbench.v,33|35): The out-of-modulereference 'testbench.pll_top.vcop' refers to a SPICE block. Because the software
P: 16
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 1bx, 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
end
ènd_ams_testbench_reuse_ default_value
Action 2: type ./run on command line.
The simulation will be finished with the following warnings:
|
ncelab: *W,CUVSOD (./source/digital/testbench.v,32|35): The out-of-modulereference '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".
|
ncelab: *W,CUVSOD (./source/digital/testbench.v,33|35): The out-of-modulereference '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: 17
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;
// 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;
// Just a null body
endmodule
module cds_spice_a2a(e)
input e;
electrical e;
// Just a null body
P: 18
endmodule
This cds_spice.vams file is installed in $AMS_INST_DIR/tools/affirma_ams/etc/cds_spice_alias. It must be precomplied before used.

Now lets 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: 19
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/cds_spice.vams \
./amscf.scs \
-define OOMR_SPICE \
-amsfastspice \
-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
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: 20
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 doesnt 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...
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,
*
amsd {
portmap subckt=pll_top autobus=yes file=./portmap_files/pll_top.pb
}
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: 21
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;
Digital Concats
{2'b10, a, b}
Concat Expressions
{2'b10, a, b, ana}
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
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);
Supported
in IUS82!!!
OOMR on port Expressions

spice_block s1(top.d1.r, top.d1.l, top.d1.p);
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
P: 22
* 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 dont need to explicitly
specify it.
If with prop.cfg it can be
cell analog_top
{ string prop sourcefile="analog_top.sp";
P: 23
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: 24
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: 25
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:
********
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: 26
Spice Port
Separator
Verilog Port
Direction
q_1
Q_1
dir=input
q_2
Q_2
dir=input
IN1
in1
dir=inout
{ itune_0 , itune_1 }
ITUNE[0:1]
dir=input
in2
IN2
dir=inout
// amsd.scs
******
amsd{
portmap subckt=ANALOG_TOP file=analog_top.pb
}
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
******
amsd{
portmap subckt=ANALOG_TOP file=analog_top.pb casemap=upper busdelim=_
}
// 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.
P: 27
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:
subckt nand2:
|
module nand2:
a
|
a_spice
|
a_veri
c_0
c_1
|
|
c_0
c_1
|
|
c[0] c[1]
b
|
b
|
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: 28
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: 29
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
No Sensitivity info
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: 30
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-inmiddle). 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: 31
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: 32
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: 33
| |-- 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
include
include
include
include
include
***********
"./source/analog/PLL.sp"
"./models/resistor.scs" section=res
"./models/diode.scs" section=dio
"./models/pmos1.scs" section=nom
"./models/nmos1.scs" section=nom
"acf.scs"
amsd{
ie vsup=1.8
portmap subckt=pll_top file="pll_top.pb"
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: 34
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 \
-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: 35
***********
include "acf.scs"
amsd{
ie vsup=1.8
portmap subckt=pll_top reffile="./source/analog/PLL.v"
portmap module=counter reffile="./source/digital/counter.v" porttype=name
}
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: 36
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: 37
| |-- divider.v
| -- stimuli.vams
-- amscf.scs # AMS control file including AMS options
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 "acf.scs"
amsd{
ie vsup=1.8
portmap subckt=pll_top
portmap module=counter reffile="./source/digital/counter.v
}
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: 38
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 VerilogAMS 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
% irun amscf.scs
// traditional way: prop.cfg is used

// 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: 39
% 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: 40
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: 41
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
config cell=block1 use=spice
portmap autobus=no
}
//
//
//
//
//
//
//
apply autobus=yes globally

this subcircuit will use autobus=yes
apply autobus=no globally from this point
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: 42
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: 43
config cell=dac use=hdl

}
amsd {
portmap stub=pll match=spice
config cell=pll use=stub
// SPICE 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
portmap subckt=analog_top autobus=yes
config inst=top.xana_top3 use=spice
// SPICE subcircuit
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
}
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: 44
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: 45
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: 46
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: 47
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/u
vlib:$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: 48
.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
portmap module=divider
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: 49
irun ./source/digital/*.v -spicetop -modelpath

"./models/resistor.scs(res):./models/diode.scs(dio):./models/pmos1.scs(nom):./mode
ls/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: 50
(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-ontop. 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 portbinding 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 speed="1";
}
It will be translated to prop.cfg.scs:
include "./source/analog/transmitter.scs"
P: 51
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 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: 52
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
ènd_keywords
keyword after the Verilog module resets the keyword list to contain Verilog-AMS keywords
P: 53
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
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"
....
ènd_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: 54
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: 55
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: 56
% ./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 AMSSpectre 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: 57
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: 58
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.
-------------------------------------------------------------------------./
|-- 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: 59
|
`-- digital
|
|-- ams_pm.cpf
|
|--ana_child.vams
|
|-- pmc.v
|
|-- pwr.v
|
|-- Reg_8.v
|
`-- top.v
`-- acf.scs
#digital netlist
# CPF file
# wrapper Verilog-AMS module
# power manager Verilog module
# one power domain Verilog module
# 8-bit register in Verilog
# top-level Verilog module
# 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: 60
create_isolation_rule -name iso_from_top_inst2 \
-isolation_condition pmc.iso_top_i2_out_ctrl \
-from dig_pd \
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 =
pw_top_inst2_ctrl =
pw_pwr_inst1_ctrl =
pw_top_instA_ctrl =
iso_top_i1_out_ctrl
iso_top_i2_out_ctrl
iso_pwr_i1_out_ctrl
end
1;
1;
1;
1;
= 0;
= 0;
= 0;
always begin
#30
// Pwr Domain
| Dig Domain
//
| Inst1 Domain |
pw_top_inst1_ctrl = 0;
//
OFF
ON
ON
#20
//
OFF
ON
OFF
#20
pw_pwr_inst1_ctrl = 0;
//
OFF
OFF
OFF
#20
//
ON
OFF
OFF
#20
//
ON
OFF
ON
#20
......
===============================================
#!/bin/csh -f
irun \
./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: 61
%./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]
Sensitivity infomation:
No Sensitivity info
(top) assign connect = c1 + c2
Loads of port Din: No loads
Automatically inserted instance: top.\connect[8]__L2E_CPF__electrical
(merged):
connectmodule name: L2E_CPF,
inserted across signal: connect[8]
Sensitivity infomation:
No Sensitivity info
(top) assign connect = c1 + c2
Loads of port Din: No loads
......
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: 62
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/*.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
%./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: 63
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 AMSAPS
#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
of a particular size.
in the above table indicate the recommended tool to use for designs
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: 64
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.
irun/ncsim command line argument for selecting the number of threads of parallel simulation
-spectre_args +aps +mt=n
P: 65
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.
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.
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.
p90, ... , p315). One of the outputs (p0) is divided down by a factor of 2 before feeding into the phase detector
to the PD are out-of-sync, the PD generates corrective pulses to adjust the differential output voltages of the
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
./amscf.scs \
-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: 66
irun
./amscf.scs \
-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
./amscf.scs \
-input probe.tcl \
-solver spectre \
-spectre_args +aps +parasitics
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 youare 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: 67
irun
./amscf.scs \
-input probe.tcl \
-solver spectre \
-spectre_args +aps +mt=2
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, weve 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 theres 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: 68
Note: Packngo currently has the following limitations
Doesnt support AIX operating system

64Bit Packngo doesnt support SystemC (while 32Bit is fine)
Doesnt 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.
p90, ... , p315). One of the outputs (p0) is divided down by a factor of 2 before feeding into the phase detector
to the PD are out-of-sync, the PD generates corrective pulses to adjust the ifferential output voltages of the
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: 69
|-- 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.
3.12.4 Running the Tutorial
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. Heres an
example.
irun
-packngorec `pwd`/packngo_data \
./amscf.scs \
-amsfastspice \
-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: 70
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 youll 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: 71
./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 youll 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: 72
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
./amscf.scs \
//AMS Control File
-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
./amscf.scs \
//AMS Control File
-amsfastspice \
//fastspice (UltraSim) switch
-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: 73
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: 74
Verilog (testbench on top)

|
|
SPICE (PLL)
|
|----------------------------------|----------------------------------|---------------------------------------|
VerilogA (VCO)
SPICE (PD & CP)
Verilog(divider)
Verilog (counter)
-------------------------------------------------------------------------./
|-- 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;
/*
*
*
if
What version of NCF are we using ?

If the return value is ncfFALSE, then this version is not supported
by the simulator. */
(!ncfSetDefaultVersion( NCF_VERSION_1 ))
return;
P: 75
/* 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: 76
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.
#! /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
./amscf.scs \
-iereport \
-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: 77
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
./amscf.scs \
-iereport \
-amsfastspice \
-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:
./amscf.scs \
-iereport \
-amsfastspice \
-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: 78

%./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: 79
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 isnt 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: 80
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.
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 cant 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: 81
dig_buf1
vlog_buf_out1
c1
ls_out
clk
ana_in
v
(1.8v)
ana_inv_out
level
Shifter
(1.8->3.3v)
dig_in
v
dig_buf2
vlog_buf_out2
c2
dig_inv_out
ana_buf
(1.8v)
ana_buf_out3
Case 1 Diagram
Key signals are the following.
testbench.clk
testbench.ana_inv_out
testbench.ls_out
testbench.vlog_buf_out1
testbench.vlog_buf_out2
testbench.ana_buf_out3
// Digital stimulus input: clk

// Output of analog inverter: pulse with 1.8V
// Output of analog level_shifter: pulse with 3.3V
// Output of digital buffer channel1: pulse with 3.3V
// Output of digital buffer channel2: pulse with 3.3V
// 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
P: 82
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: 83
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:
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.
output_buf
(1) 3.3v discipline

is applied
dig_buf1
(2) 1.8v discipline
is applied
clk
ana_in
v
(1.8v)
ana_inv_out
c1
ls_out
level
Shifter
(1.8->3.3v)
dig_in
v
vlog_buf_out1
dig_buf2
vlog_buf_out2
c2
dig_inv_out
ana_buf
(1.8v)
ana_buf_out3
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.
P: 84
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 );
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:
//
//
//
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
}
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.
Action 12:
The errors above are reported by chkdigdisp, the Digital Discipline Checker, which found the incompatible
disciplines.
P: 85
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 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.
%./clean_up
Summary
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: 86
* 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: 87
|-- 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: 88
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: 89
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
ncsim> time
to verify the current time is 2.5us.
Action 8: To restart the restart command:
ncsim> restart amsu1p5us
ncsim> time
to verify the current time comes back to 1.5us.
ncsim> exit
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.
ncsim> time
to confirm it print out 1.5us which is restart time point.
P: 90
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
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: 91
* 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
clockname
modulationbw
stop
start
envmaxstep
envmethod
envlteratio
envmaxiters
harmonicbalance
flexbalance
fund
resetenv
ignoredclk
trancycles
4.3.2
Description
Specifies the carrier name
Specifies the modulation bandwidth
Specifies the simulation stop time
Specifies the simulation start time
Specifies the maximum outer envelope step size
Default Value: Derived from errpreset
Specifies the method to use for envelope simulation
Specifies the ratio to use to calculate envelope LTE tolerances
Default Value: Derived from errpreset
Specifies the maximum number of Newton iterations in one
carrier (clock) period
Defines the flag value to enable harmonic balance envelope
Valid Values: no (not enabled) yes (enabled)
Default Value: no
Alternative parameter for harmonicbalance
Valid Values: no (not enabled) yes (enabled)
Default Value: no
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
Defines the flag value to reset envelope data after D2A/A2D events
Valid Values: no (do not reset) yes (reset)
Default Value: no
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
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: 92
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
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: 93
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 ènvlp': 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 ènvlp' 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.
./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: 94
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
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.
P: 95
./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: 96
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.
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: 97
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: 98
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.

2.
Run the simulation:

./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.

7.
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.
P: 99
8.
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:
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
No Sensitivity info
(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: 100

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.
7. Choose Format - Trace - Digital.
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.
8.
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: 101
//* All rights reserved.

ìnclude "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: 102
To perform this segment of the tutorial, do the following:.

./run4_top_ER_bidir
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.
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:
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: 103
6. Choose File - Exit SimVision.

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
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:
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: 104
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: 105
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
uses either 3-step (ncvlog, ncelab, ncsim) or single-step (irun). In both modes, SystemVerilog and VerilogAMS 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.
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)
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
hierarchical connections are allowed between SystemVerilog and Verilog-AMS, however limited to the
following types of connections:
P: 106
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
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
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.

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: 107
o
o
o
o
| |_mem_test.sv
| |_top.sv
|_top.scs
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
run: run script for AMS-Spectre and AMS-Ultrasim
probe.tcl: Tcl script
amscf.scs: analog control file for AMS Ultrasim and AMS Spectre
clean: clean up script
Here is the timing diagram for memory write and read

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: 108
./run
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: 109
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: 110
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
ìnclude "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: 111
% 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: 112
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: 113
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
5.4.2
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
-------- wreal Periodic Verification -------------------------------------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
-------- wreal Periodic Verification -------------------------------------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
-------- wreal Periodic Verification -------------------------------------t=45 NS top.I0.y_reg=`wrealZState, top.I1.y_reg=`wrealXState
-------- wreal Periodic Verification --------------------------------------
P: 114
t=55 NS top.I0.y_reg=`wrealXState, top.I1.y_reg=`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
5.4.3
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: 115
#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))
wreal_gen #(.time_width(40n))
endmodule;
Action 4:
I0 (wr_resolved);
I1 (wr_resolved);
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:
Action 7:
Repeat the step 5, with the sum.log

% sdiff -d default.log sum.log.
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: 116
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: 117
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: 118
|_amscf_forSpectre.scs
|_clean_up
|_models
| |_nmos.mod
| |_pmos.mod
|_mult16.net
|_README
|_run
|_run.tcl
|_run_spectre
|_run_spectre_tubo
|_simvision.svcf
|_source:
|_a_b_gen.vhd
|_clock.vhd
|_mult16x16_spice.vhd
|_top.vhms
5.5.4
: ams control file used for Spectre solver.

: clean up sript
: models directory
: nmos model file
: pmos model file
: multiplier full design SPICE netlist
: README FILE
: run script for AMS-D+Ultrasim solver
: TCL script for AMS-D
: run script for AMS-D+Spectre solver
: run script for AMS-D+Spectre Turbo solver
: Simvision postprocessing script
: Source sub directory
: VHDL A and B stimuli generator
: VHDL clock generator
: VHDL multiplier entity
: VHDL top test bench
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: 119
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: 120
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: 121
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: 122
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;
..........
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));
.........
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: 123
Fig. 5.5.4 the conversion elements can be se in the Design Browser

You can debug them with the source browser.
P: 124
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
time required for tran analysis `timedomain' became 5 minutes.
on the same CPU using Spectre turbo the Total
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: 125
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 VerilogAMS/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 VHDLAMS 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 cant
participate in such connection, since SystemVerilog-real supports single driver only, i.e. unidirectional.
P: 126
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 VerilogAMS 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
5.6.3
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: 127
TOP: top.sv
addr
read
TEST
mem_test.sv
write
data_in
data_out
vco_vin
(real)
VCO
MEMORY
mem.v
clk
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
P: 128
File Descriptions
.
|_amscf.scs
|_clean_up
|_irun_args1.f
|_irun_args2.f
|_probe.tcl
|_run1
|_run2
|_acf.scs
|_source
|_mem.v
|_mem_test.sv
|
|_top.sv
|
|_vco_wreal.vams
|_vco_electrical.vams
5.6.4
// AMS Control File

// clean script
// irun argument file for Scenario 1 (VCO with wreal)
// irun argument file for Scenario 2 (VCO with electrical)
// TCL probing file
// run script file for scenario 1
// run script file for scenario 2
// Analog Control File
// directory storing source files
// memory module in Verilog, DUT
// memory testbench in SystemVerilog. The SystemVerilog language features used in
this module include tasks (write_mem, read_mem), class and class randomization
// top file in SystemVerilog with real, instantiating both memory (mem)
and the memory test (mem_test) modules. Also generates the clock
// VCO module in Verilog-AMS with wreal
// 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: 129
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 isnt 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) wont 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: 130
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: 131
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.
P: 132

Workshop For AMSD Incisive Use Model

Uploaded by

Copyright:

Available Formats

Workshop For AMSD Incisive Use Model

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Workshop For AMSD Incisive Use Model

Uploaded by

Copyright:

Available Formats

How does SystemVerilog-real connect to wreal in AMS Designer?

How does SystemVerilog-real connect to wreal in AMS Designer?

How does SystemVerilog connect to electrical in AMS Designer?

How does SystemVerilog connect to electrical in AMS Designer?

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

Cadence Design Systems, Inc.

AMS Product Engineering

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

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

Document Update History

Sep 28, 2010

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

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

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

AMSD Virtuoso Use Model:

ADE + OSS + irun

AMSD Use Models

AMSD Virtuoso Use Model (GUI Based)

AMSD Incisive Use Model (Text Based)

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

Whats AMSD Incisive Use Model

AMS Designer simulator

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

Chapter 1 Introduction of AMSD Incisive Use Model

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

Verilog/AMS + SPICE AMS Simulation

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

Chapter 2 User Guideline for AMSD Incisive Use Model

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

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

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

probe.tcl: NC stuff and no change

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

timescale: NC stuff and no change

BDR (setdiscipline): No change in IUS82

The following we'll talk about other important components.

* AMS Control file

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

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

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

portmap subckt=pll_top busdelim="_"

The option of -propspath

The option of -modelpath

When design has transistor-level verilog-AMS netlist

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

Chapter 3 Basic Flow: verilog/ams + SPICE

irun supports a much broader mixed-language base than ncverilog

Its key features include:

The design information

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

The key signals are:

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

Building the AMSD case

Action 3: building the testbench

Create the stimuli to the DUT

Monitor or self-check the output

AMS Control File

Action 4: Creating a run script

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