1. Verification of 1M+ transistors Mixed Signal
IC for Cellular and Multimedia Applications
Session # 2
Freescale Semiconductors
Régis Santonja
Presented at

2. Verification of 1M+ transistors Mixed-Signal ICs for
Cellular and Multimedia Player Applications
Régis Santonja, Freescale Semiconductors
1. Introduction
As the complexity and modularity of modern mixed-signal Integrated Circuits (IC)
increase, together with the costs of masks and wafers, one needs to find new ways to
simulate the IC’s behavior, signal integrity and power consumption before tape-out.
This paper will demonstrate how, at Freescale, we take up this challenge by presenting
the real case verification of a family of power-management ICs containing up to 1 million
transistors, and more, with a wide variety of circuit topologies (linear analog circuits,
switched mode supplies and audio system, high precision data converters, etc…).
Most of the aspects involved will be presented, beginning with testbench architecture,
then to regression tests, up through database management, test coverage, signal integrity,
power consumption, etc…
Historically, our initial goal was limited to functional verification. This paper presents
our mixed-level simulation approach, based on some real case examples.
However, some IC respins were caused by signal integrity problems, accidental leakages,
or over consumptions. Indeed, the static current consumption requirements are getting
more and more challenging, and the risk of leakages are increasing with the use of several
voltage supplies that can be switched on or off independently. This paper presents how
we manage to correlate simulated current consumption at IC level with silicon measures,
and how we track potential floating nodes.
2. The IC specification
Our methodology has been used for several ICs of the same family. The diagram below
roughly presents the features embedded on a single die. As we can see, lots of analog
functions are implemented, but the digital is also important.
Verification requires a very deep knowledge of the circuit’s specification. Indeed, older
generations of Power-Management ICs had their functions quite independent one from
the other. Whereas today’s ICs have much more complex system interactions. For
example, the buck switchers that are used by the external processor can also be used to
supply the internal audio system; the boost switcher can be used by the internal LED
drivers; the negative charge pump can be a shared resource between the blue LED driver
and the “true-ground” audio biasing, etc… Chapter 8 will present the Verification Matrix
that we’re using to track that all specification has been covered by simulation.
2

3. 1M+ transistors Power-
Management IC
Figure 1: 1M+ transistor Power-Management IC
3. The Verification Environment
This chapter describes the Verification Environment (VE) that we used for the
verification of our Power Management ICs.
3.1. Block-level testbenches
In the example here, the audio of the IC was first simulated at block-level. The vector file
has been written in such a way that one could use it to re-simulate the audio at chip-level.
We call “vertical re-use” the ability to use the same resources at block-level and chip-
level.
The audio circuit did not have a SPI/I2C interface at this level. However, the vector file
was written with the chip-level SPI/I2C transactor syntax in such a way that it could be
re-used as is during chip-level simulation phase.
3

4. Block-level Testbench using the same vector file
Stimulus/Checker (VAMS)
Vector file (VAMS)
SPI /I2C
contains calls to the transactors.
wrapper
Also has stimulus and checkers
for remainder of test
initial begin
<specific digital stimulus>
end // initial
always @
analog begin
<specific analog stimulus>
end // analog
Audio
(SSI)
transactor
SPI map files
Optional
Environment defines
secondary
Audio Environment Tasks
transactor
Waveforms
Optional assertions
Figure 2: Block-level testbench
3.2. The Chip-level testbench
The chip-level testbench is built at the beginning of the project, as soon as the pad list of
the chip is defined, and is used throughout the whole project development.
This is the Verification Leader’s role to provide such a testbench. It will then be used by
the whole design and verification team to exercise all blocks individually, at different
levels.
At the top testbench level, each IC pin has its counterpart in the Stimulus/Checker block
and both are connected together (cf. Figure 3) in a Cadence schematic view.
4

5. Chip-level Testbench
IC Stimulus/Checker (VAMS)
(DUT) SPI/I2C pins
Vector file (VAMS)
SPI /I2C
contains calls to the transactors.
transactor
Also has stimulus and checkers
for remainder of test
initial begin
Optional <specific digital stimulus>
secondary end // initial
SPI/I2C
Supplies/Grounds transactor always @
and other analog
pins analog begin
<specific analog stimulus>
end // analog
Audio
(SSI)
transactor
BCL/FS/RX/TX
SPI map files
Optional
Environment defines
secondary
Audio Environment Tasks
transactor
Waveforms
USB
(ULPI)
transactor
Optional assertions
Other
miscellaneous
transactor
which may be
added in future
Figure 3 Chip-level Testbench block diagram with AMS Stimulus/Checker for mixed-level
simulations
The Verilog-AMS Stimulus/Checker gives the ability to exercise the IC through its
interfaces, such as SPI, I2C, I2S, general purpose Inputs/Outputs (IOs), but also through
all its analog pins.
3.2.1. The Verilog-AMS Stimulus/Checker module
As shown in Figure 2 and Figure 3, the Stimulus/Checker consists of a number of
include files. These are used to provide resources which can be used to write stimulus and
checkers for exercising and observing the Design Under Test (DUT).
5

6. These resources are available to be referenced from the vector file. The test-specific
vector file is pulled into the top stimulus via a Verilog include. The file to be included is
selected by a `define directive given during compilation.
In the vector file, one can have additional variable declarations, SPI transactor calls to
read/write SPI bits in either SPI or I2C mode, controls on pins, checks of pins or internal
nets, and any other various code needed to stimulate and check the response of the part.
An example vector file is shown in Listing 1. The first thing done here is to bring up the
various supply voltages (LICELL, BP, and SPIVCC). Once a rising edge on RESETB is
detected, some read accesses via the SPI interface are done. Also, the state of the chip’s
interrupt pin is checked. At the end, an END_SIM call prints a pass or fail report based
on whether any errors were found throughout the test (Cf. Listing 3).
/********************* DIGITAL EXECUTABLE **************************/
initial begin
// Initial Condition:
BP_level = 0;
LICELL_level = 0;
SPIVCC_level = 0;
#(10*`nano_in_usec);
LICELL_level = 2.5;
#(500*`nano_in_usec);
BP_level = 3.6;
SPIVCC_level = 2.775;
COMMENT(quot;********** WAIT FOR RESETB HIGH **********quot;);
@(cross(V(RESETB)-SPIVCC_level/2, +1, 1n, 10u));
wdi = 1;
COMMENT(quot;********** CHECK INT PIN IS HIGH **********quot;);
check_digital_net_id(quot; INT pin high checkquot;, `IC.INT, 1'b1);
COMMENT(quot;********** READING FIN, ICID AND REV BITS **********quot;);
spi_icid_fld = 3'b111;
spi_rev_fld = 5'b01_000; // 1.0
spi_read_fields1(SPI_ID_REG_ADR, 24'hff_ff_ff);
COMMENT(quot;*****READING ICID DUPLICATE **********quot;);
spi_icid_adc3_fld = spi_icid_fld;
spi_read_fields1(fnGetAddr(quot;spi_icid_adc3_fldquot;), spi_icid_adc3_mask);
COMMENT(quot;********** ALL TESTS COMPLETED **********quot;);
END_SIM;
end
/********************* ANALOG EXECUTABLE **************************/
analog begin
// Generic analog section
`include quot;generic_analog.vquot;
Listing 1 Example of vector file (extract)
6

7. The vector file is made of 2 parts. The digital side drives the test’s sequence. The analog
side is driven by the digital controls. It consists in a vector-specific section, and a generic
section imported via a file called “generic_analog.v”. This file contains all the external
components, such as external capacitors, crystal, microphone models, etc… It also
contains all the supply sources for the main battery, the charger, the Lithium cell, etc…
All these components are gathered in a single file in order not to duplicate their
declaration in every vector. They are usually declared in Verilog-AMS syntax, but can
also be a “spice” netlist. Finally, some `ifdef compiler directives can be used to select the
IC-specific file to be included. Indeed, the same vectors are often used for several ICs of
the same family that usually do not have the exact same external component list. Listing
2 presents an extract of such a file.
//*******************************************************************
// Main Supplies
V(BP_stim) <+ transition(BP_level, 0, BP_rise, BP_fall);
I(BP, BP_stim) <+ V(BP, BP_stim)/RBP;
//*******************************************************************
// External Capacitors
I(REGULATOR1) <+ 1e-6 * ddt(V(REGULATOR1));
I(REGULATOR2) <+ 1e-6 * ddt(V(REGULATOR2));
I(BANDGAP) <+ 100e-9 * ddt(V(BANDGAP));
//*******************************************************************
// GROUNDS
V( GND1) <+ 0.0;
V( GND2) <+ 0.0;
Listing 2 Generic analog file containing the external components
One can see in this example how BP_level, BP_rise and BP_fall play the role of digital
controls for the corresponding external voltage source.
The resulting log file for this specific simple example is presented in Listing 3.
% INFO @ 0 ns: ***************************************************
% INFO @ 0 ns: RUNNING SIMULATION common_topctrl_revid.vams
% INFO @ 0 ns: ***************************************************
% INFO @ 510000 ns: ********** WAIT FOR RESETB HIGH **********
% INFO @ 41229624 ns: ********** CHECK INT PIN IS HIGH **********
% PASS # 2 @ 41229624 ns: INT pin high check: correct digital value
% INFO @ 41229624 ns: ****** READING FIN, ICID AND REV BITS ********
% PASS # 3 @ 41230878 ns: PASS: SPI Reg. 7 Read Check PASS.
% INFO @ 41230878 ns: ****** READING ICID DUPLICATE******
% PASS # 4 @ 41232132 ns: PASS: SPI Reg. 46 Read Check PASS.
% INFO @ 51232132 ns: ********** ALL TESTS COMPLETED **********
% -----------------------------------------
% Simulation common_topctrl_revid.vams Completed Successfully
%
% END_SIM called @ Time = 51232632
% 4 Checks done
% 4 Checks successful
Listing 3: Log file example
7

8. 3.2.2. Assertions
It is common to consider that assertions are a concept limited to digital verification
languages, such as PSL/Sugar, Vera, or SystemVerilog. However, if we define assertions
as “piece of codes that are continuously monitoring one or several signals together,
whatever the specific test being applied to the DUT”, then Verilog/Verilog-AMS can be
used to create assertions. They would typically be coded with either combinational
(continuous) logic, or with @always processes.
These tests are implemented in the generic section of the testbench. They are permanently
running and monitoring the involved signals, independently of the vector file being used.
In our case, the behavior of the clock provided by the IC to the external processor
depends on the internal power system state of the IC. An assertion is permanently
controlling that the clock is correctly provided. Additionally a compiler directive is
available to automatically add rise and fall time monitors in case the clock is considered
analog.
Assertions can be implemented in the testbench as illustrated in Figure 3. They can also
be implemented in the design itself, or in the models of the blocks. For example each of
our models continuously checks that its supplies and grounds are within an accepted
voltage range.
3.3. Verification IP re-use
We talked about “vertical re-use” above. Indeed, as on the design side, reusing previous
developments in verification has become mandatory. A design IP can be a standard
interface implementation. The corresponding Verification IP (VIP) would be the set of
resources necessary to verify this interface. It can include block-level or chip-level
testbenches, together with their appropriate transactors, monitors, and even the vectors
created to stimulate and observe the complete behavior of the design (Cf. Figure 2 and
Figure 3). The testbench itself, and the Verification plan (cf. chapter on the Verification
Matrix), can be re-used or can at least serve as a good starting point for a new project.
In our case, we have developed a set of Verification IPs which consists in a list of
configurable mixed-signal Verilog-AMS modules, tasks and functions which can be
called from the Stimulus/Checker module. They allow printing comments, counting
error/warning/pass information, or report the final status of the simulation. They also
control the various transactors (SPI/I2C, USB/ULPI, I2S) and a set of standard digital
controls for the power supplies and other analog pins. Additionally they provide digital
and analog monitors (voltage or current levels, sine wave amplitude, frequency, gain,
etc…).
During the whole project development, the same bench can be used to verify each and
every sub-circuit as it gets changed: either after a specification change or because an
issue was found.
8

9. On the model side, we also have generic and configurable models for LDO’s, amplifiers,
etc…
In addition, we have also developed generic vector files for the most common mixed-
signal functions of our product line, i.e for linear regulators, buck switchers, audio
amplifiers and codecs. These benches can easily be plugged in every project-specific
chip-level testbench and are ready to be used immediately on any new project. These
generic vector files are connected to the specific DUT thanks to a set of `define that give
the correspondence between the generic names (instances, enables, outputs, etc…) and
the actual ones. Some of the involved signals can be addressed through the hierarchy of
the IC whose complete path is defined in a specific file that gets plugged in the generic
testbench.
Finally, a set of simulator options is available and can be reused to ease convergence or
to speed up some especially long simulations.
All these Verification IPs make the setup of the verification environment fast and easy.
4. Tagging Methodology
Today’s IC are developed by multi-site teams spread all over the world, counting tens of
designers, each of them re-using circuits from previous generations and also developing
new ones. It became absolutely necessary to have a very rigorous methodology to handle
the design and verification database.
During the development phase, each designer can release his work to integration, layout
or verification teams by checking it in a central database. At any time, he or another
designer can check it back out, modify it, and check it back in with a short comment
about the change. This increases the version of the corresponding circuit and builds the
version history of the block.
9

10. Top-block V3.0
X_top.01
X_top.01
B
A
V2.3
V1.2
X_top.01
X_top.01
C
V2.8
Figure 4 Block Tagging methodology
If a check-in can be considered being an official release for a flat block, one needs to find
a way to reliably release a hierarchical block. Indeed, it is unlikely that all sub-blocks will
have the same revision number. Placing a tag on the whole hierarchy of the block will
allow other teams to work with the good combination of sub-block versions. It will also
ensure that at any time in the future we are able to retrieve the exact state of today’s
design. Note that it is useful to also tag the complete development and verification
environment (testbenches, but also libraries, simulator version, etc…).
Such release tags must not be moved: once it is associated to a given version of a block, it
needs to get locked to it. In our case, the revision control tool is configured so that all tags
starting with X_ prefix can not be moved.
Each block instantiated at the top-level must be tagged by its owner before it gets
plugged in the IC. The designer takes the responsibility that his block is consistent across
all its hierarchy and is functional. If any change needs to be done on a block or one of its
sub-blocks, it must be checked-in and a new tag must be placed with an increased
number.
10

11. X_VE.12
Verification Environment
X_topcell.06
Top-cell
X_topblock_X.03
Topblock_X
B
A
V2.3
V1.2
X_topblock_Y.05
C
V2.8
Topblock_Y
B
A
V2.3
V1.2
Topblock_Z
B
A
V2.3
V1.2 C
V2.8
C
V2.8
X_topblock_Z.08
Figure 5 All tags in place for chip-level integration and complete Verification Environment release
One of the challenges of the design leader of a complex mixed-signal IC is to precisely
identify which version of each individual block is to be assembled into the chip-level
design. Thanks to the tagging methodology, this integration task is much easier, as he is
guaranteed that all the blocks that get integrated, and all their sub-blocks, are self
consistent, netlistable and simulatable. He just needs to ensure that his top-cell passes
Cadence schematic Electric Rule Checker (“check & save”) and tag it before releasing
the whole circuit database to the Verification Leader.
The latter will also tag the entire Verification Environment. The overall list of tags is
gathered in a Freescale specific file format (CCF) and a mail is sent to the whole
verification team to inform them that a new release is available. Each verification
engineer can then open this (versioned) file with a proprietary tool that will create a clean
11

12. workarea for them. The Verification engineer creates a new workarea at each new IC and
VE release. He can actually create many of them with any variation of its content.
Topblock_X X_topblock_X.03
Verification Engineer
Topblock_Y X_topblock_Y.05 #1 work area
Topblock_Z X_topblock_Z.08
Top-Cell X_topcell.06
Verification
Environment X_VE.12
CCF file
Central database (vault)
Figure 6 Building workareas for Verification of released database
5. Speeding the simulations up
Some years ago analog functions were limited to their minimum. Nowadays, even though
performance and size are still key constraints, a new one has shown up: the function must
now be modular, configurable for multiple standard usages. It needs to have special extra
features for test efficiency, calibration, low power modes, etc… All this has dramatically
increased the complexity of the mixed-signal circuits and the corresponding simulation
times.
Consequently, a constant concern of verification is the trade-off between simulation
speed and accuracy. Small linear analog blocks can still be simulated with full accuracy
using a “spice” engine (Spectre). However, for big, non-linear (i.e. switched capacitors)
analog functions, one can either promote simulation speed and go for mixed-level
simulations, or promote simulation accuracy and go for a “fast-spice” engine (Ultra-
AMS).
12

13. Analog block Requirement Simulation method
Small linear analog blocks Full accuracy Spectre
Big non-linear analog Speed Mixed-level
blocks (audio converters,
Accuracy Ultra-AMS
switchers, etc…)
Table 1: Accuracy versus speed simulation method
This chapter will present how mixed-level simulations (using transistors and models
together) can accelerate the simulations enough to get a good functional coverage, still
ensuring a satisfactory accuracy. The goal is to keep each simulation time below 2 hours.
The next chapter will present how Ultra-AMS or Ultrasim can handle big non-linear
functions, keeping the simulation time around a night, or maximum a few days.
5.1. Mixed-level Simulations
Mixed-level simulations give the opportunity to simulate the chip early in the process,
allowing the capture of system-level errors early in the development phase with a
minimal cost.
All models must be pin accurate and each pin must match the expected voltage levels,
drive strength, etc… of the block.
It is also high priority to verify Design For Test structures. The difficulty here is that the
test feature of the IC might not be detailed in the specification when the latter is owned
by the customer. It is still too often that DFT breaks the main functionality of a block or
creates over consumption if not properly turned off during normal operation.
Finally, the models should be reviewed with the block designers in order to check that no
essential functionality is missing or wrongly modeled. This also gives the designer a
reassuring knowledge of what is being simulated by the verification team prior to full-
transistor simulations.
5.1.1. Languages
An initial approach for the verification of mixed-signal designs has been to use digital
HDL (VHDL or Verilog-D) to model the analog blocks. The advantage was the
simulation speed, but the sensitive drawback was that these languages are not suitable to
model all necessary analog behaviors. Indeed, time steps are constrained to discrete
digital events, it is not possible to find zero-crossings; filtering, integration, derivatives,
and other functions need to be recreated manually, and until SystemVerilog, floating-
point connections were not supported.
13

14. Verilog-AMS solves these limitations. However, the modeling style of mixed-signal
circuits tends to be the major contributor to simulation speed, after the transistors. We
give some examples on how to speed up the simulations further in this paper.
In the digital world, SystemVerilog has brought a powerful syntax to the verification
engineer, such as concise assertion coding. Cadence’s AMS-Designer (based on ncsim
simulator) is able, providing some cleverness, to co-simulate transistors, Verilog-AMS
and SystemVerilog all together, enabling state-of-the-heart mixed-signal verification
techniques.
However, there is no SystemVerilog-AMS standard, even though Cadence and other
companies are working on that project with Accelera. One could imagine that a first step
would be to simply merge Verilog-AMS with SystemVerilog. Another valuable step
would be to add some new AMS constructs such as AMS assertions able to monitor
analog signals. Some companies are already proposing their own AMS assertion
language.
5.1.2. Mixing all levels together
Mixed-level simulations can start as soon as the pin list of all blocks is defined. A top-
cell can then be created which connects appropriately all the blocks’ pins together.
Depending on its availability, and the simulation time that we can live with, one can
either use a transistor or a behavioral model for each block.
STUB
RTL/GATES
VAMS
Figure 7 Mixed level circuit representation example
14

15. Figure 7 shows how a mixed-level simulation can look like. The analog blocks that are
complete can be selected at transistor-level while some or all of the surrounding blocks,
such as the biasing references or the digital logic, can be left as models. In this case, the
chip-level Verification Environment, together with the mixed-level representation of the
IC, act as a “super testbench” for the block under test. If undesired interactions are likely
to occur between several blocks, they should all be simulated at transistor level together.
In order to get rid of the risk inherent to the use of models, each analog block should be at
least simulated once at transistor level.
The “stub” views are empty models, used as simple placeholders, whose functionality is
not being activated in the given simulation. Our experience is that it is wiser to let the
simulator consider the pins of the stub views being digital, so that if a high frequency
signal is connected to it (such as a clock), it is kept digital by default. This avoids
potential dramatic simulation slowdowns.
As the design cycle progresses and the design of analog blocks is completed, the
behavioral models can be replaced with their corresponding transistor (or RTL/gates)
representation.
STUB
Digital model RTL/GATES
VAMS VAMS
VAMS
Figure 8 Top-Down Verification
Due to design re-use, some analog blocks that do not impact simulation time in a
sensitive manner, might have always been simulated at transistor-level. In this case, there
is no need to waste time creating models, unless the impact on simulation speed appears,
for example if a high frequency clock gets connected to it.
Finally, during the mixed-level simulation phase, the digital is kept at Register Transfer
Level (RTL) or gate level. The latter is usually used to ensure that the scan chain, which
is inserted during synthesis, did not break the functionality of the IC. Sometimes we also
use Standard Delay Files (SDF) files to back-annotate the digital blocks.
15

16. 5.1.3. Multiple supplies
Typical Power-Management ICs have an on-chip voltage regulator generating internal
supply voltages, as presented in Figure 9.
Internal voltage
Regulator
+
-
Digital
vcore
Block
VCORE
_z
Reg 1
USB
Block Block
Switched Cap Internal blocks
_x _y
supplied off the on-
chip voltage regulator
Figure 9: Internal regulator and its power tree
The digital blocks run at low voltages (such as 1.5V or below), while some analog blocks
need higher operating voltage levels for better performance (such as 2.8V).
Level-shifters are needed between digital and higher voltage analog domains. Level-
shifters are simple linear analog blocks that simulate quite fast. Still, a level-shifter on a
clock path can kill your simulation time. Hence, when possible, level-shifters on the
clock lines should be replaced by simple (digital) Verilog models.
5.1.3.1. Block-based Discipline Resolution
As presented in Figure 10, several connect modules need to be defined to support
multiple supplies mixed-level simulations. This is done using Cadence’s Block-based
Discipline Resolution (BDR) methodology. The latter allows to set different disciplines
in the digital domain. The elaborator uses BDR to determine which part of the design has
which power supply.
16

17. 1.5V
Digital
Analog
CM
(RTL)
(1.5V)
1.5V
Level-shifter
CM
Analog
(2.8V)
2.8V
CM
VAMS model
digital
pin
CM : Connect Module
Figure 10 Multiple connect modules
This example uses two power supplies: 1.5V and 2.8V. The default discipline, logic, is
set for 1.5V domain, while logic28V is created for handling the 2.8V domain.
discipline logic
domain discrete;
enddiscipline
discipline logic28V
domain discrete;
enddiscipline
Listing 4 Example of discipline declaration
Then the Connect Rules are associated with the new logic28V discipline as shown in
Listing 5.
17

18. `include quot;disciplines.vamsquot;
`include quot;userDisciplines.vamsquot;
connectrules ConnRules_28V_basic;
connect E2L_0
#( .vsup(2.8), .vthi(2.0), .vtlo(1.0), .tr(0.4n)) input electrical, output logic28V;
connect L2E_0
#( .vsup(2.8), .tr(0.4n), .rout(200)) input logic28V, output electrical;
connect Bidir_0
#( .vsup(2.8), .vthi(2.0), .vtlo(1.0), .tr(0.4n), .rout(200)) inout logic28V, inout
electrical;
endconnectrules
Listing 5 Example of Connect Rules declaration
Finally, the new discipline must be attached to the appropriate instance or cell terminals.
This is done with the –scope_discipline option of the elaborator. The latter can then use
this information during discipline resolution to detect the discipline pairs (such as
logic28V and electrical) and insert the proper connect module with the proper power
supply.
ncelab –scope_discipline quot;cellterm-gpadc.lshift_lv.out- logic28Vquot;
Listing 6 Example of –scope_discipline elaboration option
The command in Listing 6 tells the elaborator to consider the out pin of the cell lshift_lv
from the library gpadc to be at 2.8 volts.
5.1.3.2. Supply-sensitive Connect Modules
As we can see, this can be a bit tedious to specify all the cells or instances that need to be
associated with a given discipline. Indeed, in real Power-Management ICs, it is typical to
have 4 or 5 different supply levels, as some functions need to be connected to an external
lithium cell which can typically be at 2.5V, some others need to be connected to the
battery, which is typically around 3.6V, and one can also need to consider a 20V domain
because of a battery charger being on the same die.
In this case, one might consider to use supply-sensitive connect modules. The latter are
able to automatically grab the voltage level of the net connected to their analog side.
However, these connect modules require the digital code to include some Cadence-
specific syntax. Indeed, the libraries of the standard cells have to be re-written. And for
RTL or gate-level simulations, the code or netlist also needs to comply to this syntax.
Unfortunately, this syntax might not recognized by other tools. A wrapper might then be
needed.
18

19. `celldefine
module inv(x, a);
// define pin sensitivities
input (* integer supplySensitivity=quot;vdd! quot;;
integer groundSensitivity=quot;vss! quot;; *) a;
output (* integer supplySensitivity=quot;vdd! quot;;
integer groundSensitivity=quot;vss! quot;; *) x;
// supply declarations for supply sensitivity
wire (* integer inh_conn_prop_name=quot;vddquot; ;
integer inh_conn_def_value=quot;cds_globals.vdd! quot;; *) vdd! ;
wire (* integer inh_conn_prop_name=quot;vssquot; ;
integer inh_conn_def_value=quot;cds_globals.vss! quot;; *) vss! ;
// functional section.
not ( x, a );
endmodule
`endcelldefine
Listing 7 Example of a simple inverter using Cadence-specific syntax for supply-sensitive Connect
Modules.
Additionally, these Connect Modules are slower that the standard ones.
5.1.4. Examples of mixed-level simulations
As mentioned before, the goal of mixed-level simulations is to be able to guarantee a high
functional coverage by speeding up the simulations compared to running all transistors
together. Here are a few real case examples of techniques to speed mixed-level
simulations up.
5.1.4.1. Phase Locked Loop (PLL)
The designer had generated a model of his PLL, as a schematic, based on some Verilog-
A components. This was perfectly functional, but the PLL model took about 2 hours to
lock.
The simulation was accelerated by a factor of 100x, enabling the PLL to lock within a
minute of simulation time. The strategy was to minimize the number of high frequency
nets being considered analog. In practice, this consisted in changing the flops and the
divider to a Verilog description, rewriting a model of the Voltage Controlled Oscillator
(VCO) so that its output became digital, making sure the PLL output was not converted
to analog outside of the PLL, and finally that the input clock was digital too.
The PLL was not alone; it was driving the digital filters and sigma-delta modulator of an
audio Coder-Decoder (Codec). Providing some additional work on the modulator, we
19

20. could simulate tens of sine periods and extract an FFT, calculate the SNR, etc… which
was totally impractical with the original PLL and modulator description, still proving the
system was correct.
Charge
Phase Detector pump
Up
digital pllout
clk Loop Filter
VCO digital
analog
fb Dwn
digital Divider
Figure 11 Fast model of PLL
5.1.4.2. Non-overlapping clocks
Non-overlapping clock circuits are needed by all switched capacitors implementation.
The block is usually a schematic because, even though this might be a pure digital
implementation, the RTL is not well suited to model non-overlapping clocks because of
delays being required during simulation.
Figure 12 presents a simple implementation of a non-overlapping clock generator. In
order to simulate such a block in a timely manner, one needs to use the digital Verilog
models of the gates. Indeed, the actual implementation of non-overlapping clocks can be
more complex. And usually the delays are built with a chain of inverters, creating as
many nets that would dramatically slow down the simulation if they were to be simulated
as analog.
20

21. clk
δ φ1
δ φ2
clk
clk
φ1
φ2
Figure 12 Non-overlapping clocks kept digital
Keeping the high frequency nets digital allow a 100x improvement factor in terms of
simulation speed.
5.1.4.3. Switched capacitor (a/d and d/a converters)
In the same spirit, when simulating a switched capacitor circuit, we are used to replace
analog switches with an AMS model where the MOS gate is considered digital. This
allows keeping the clock lines digital.
Figure 13 presents a simplified implementation of a switched capacitor integrator. In real
life, the topology of switched capacitor circuits are differential (doubling the number of
switches and clock nets), and globally much more complex. They are used for example in
high performance audio converters.
V1
-
V2
φ1 φ2 +
21

22. Figure 13 Digital gates for switched-cap MOS
`timescale 1ns/10ps
`include quot;constants.hquot;
`include quot;discipline.hquot;
module Switch_Ams( Y, X, CTRL);
inout Y; //output pin
inout X; //input voltage pin
input CTRL; //1-bit control pin
electrical X, Y;
logic CTRL;
parameter real RON = 1m; //ON-resistance; unit=Ohm
parameter real ROFF = 1e9; //OFF-resistance; unit=Ohm
real res;
initial res = 1;
always @(posedge CTRL or negedge CTRL)
if (CTRL===0) res = ROFF;
else res = RON;
analog begin
I(X,Y) <+ V(X,Y)/res;
end // analog
Listing 8 Example of an AMS model of a transistor used as a switch
There is no need to edit the designer’s schematic if the AMS model used is included in
the MOS library.
Similarly to previous examples, a factor of 100x simulation speed is typically reached
compared to when the clock nets are kept analog.
5.2. Full-transistor simulations
In the analog world, there is no formal method to prove that a model is exactly
reproducing the circuit’s behavior. Hence, the use of models introduces the risk that the
simulation does not match the future silicon behavior.
Consequently, it is important to also run full-transistor simulations, with a minimum (but
carefully selected) set of functionalities being covered. Usually one tries to check the
startup, shut down, and basic communication through the IC’s interfaces. Unfortunately,
22

23. this can only be started once the design is complete, which is at the very end of the design
cycle.
However, using a “fast-spice” engine such as Ultrasim (Ultra-AMS) with the appropriate
set of simulator options, one can simulate complex functions, such as a complete audio
chain.
Figure 14 Example: Simulating a complete receive audio chain
Table 2 presents the Ultrasim options we found the most appropriate for this kind of
simulations.
Ultrasim options Comments
.usim_top sim_mode=df Global sim_mode set to digital fast
.usim_opt speed=8 Aggressive speed
.usim_opt analog=0 Aggressive partitioning
.usim_opt dyn_part=0 Disables Dynamic Paritionning
.usim_optrshort=1.01 #<block name> Remove small resistors
.usim_opt dcut=1 #<standard cell names> Remove standard cells’ antenna diodes
.usim_opt speed=3 sim_mode=a #< cell Tighten options for sensitive blocks
name>
Table 2 Complete receive audio chain simulation options
6. Full-chip current consumption simulations: 1M+ transistors!
Despite functionality, we also want to run to track potential leakages and over-
consumption at IC level.
23

24. Running full-chip, full-transistor simulations allows potential leakages and over-
consumption capture and tracking. Providing the huge number of transistors to simulate
at a time (1M+), this is very challenging… but it works.
We are using Cadence Ultra-AMS environment. However, as of today, we use a “spice”
testbench, because Connect Modules that otherwise are inserted between the
Stimulus/Checker and the IC introduce false current calculations. Hence, only the
Ultrasim solver is used: this is a pure analog simulation.
Indeed, the stimulus can either be selected as a Verilog-AMS view for mixed-level
simulations (cf. Figure 3) or a “spice” view in case of full-transistor current consumption
simulation (Cf. Figure 15).
Chip-Level Testbench
IC Stimulus/Checker (“Spice”)
(DUT)
Vin1
Vin2
Vin3
Vout1
Vout2
External devices
Vout3
Vout4
Figure 15: Chip-level Testbench with “spice” Stimulus for chip-level current consumption
simulations
The bench must be as close as possible to the application: “spice” external components
must be added (no Verilog-A/MS), and all pins must be connected. In our case, our
capacitor library makes Verilog-A calls. Hence, we had to use simpler (pure Spectre)
models.
24

25. Table 3 presents the Ultrasim options we found the most appropriate for this simulation.
As a general rule, one must be extremely careful when widening the tolerance settings, as
this can damage both functionality and performance simulation results. We’d better not
spend time thinking there might be a design issue when the unexpected results are due to
a too strong relaxation of the simulator parameters.
Ultrasim options Comments
.usim_opt rshort=1.01 rvshort=1.01 Remove small resistors on both signal and
power nets.
.usim_opt lshort=1e-3 lvshort=1e-3 Remove small inductances on both signal
and power nets.
.usim_opt elemcut_file=1 Print all cut elements into a file.
.usim_opt nodecut_file=1 Print all cut nodes into a file.
.usim_opt dcut=1 #<all standard cells Remove standard cells’ antenna diodes
names>
.usim_opt speed=2 #<digital cell name> Set speed=2 on all standard cells. A
speed=8 is functional but too loose for
accurate current consumption estimation.
The global speed is left to its default
value=5.
z.usim_opt sim_mode=da #<digital cell Set digital blocks to digital-accurate. A
name> digital-fast (df) option is functional but too
loose for accurate current consumption
estimation. The global sim_mode is left to
the default mixed-signal (ms) mode.
.usim_opt analog=0 #<digital cell name> Aggressive partitioning on digital blocks
.usim_vr block=#<regulator cell name> Cf. comment on VR simulation below.
node=<hierarchical path to supply node>
.probe x(<hierarchical node name>) Saving currents to waveform.
CAUTION : current probing increases the
size of the partitions. It is preferred to run
several successive simulations with a
limited number of current probes.
.probe v(<hierarchical node name>) Saving voltages to waveform
.usim_opt dc=1 Complete operating point calculation using
pseudo-transient algorithm.
.usim_opr dc_prolong=1 The simulator extends the DC calculation
until a stable operating point is reached.
This disables the default 3 hour time limit,
and the maximum DC event limit.
.usim_opt dc_rpt_num=100 Report the 100 most unstable nodes during
DC calculation into a .dcr file.
.usim_opt vdd=3.0 Higher voltage used for df or da models
calculation.
25

26. .usim_opt mos_method=a Non linear analog current and charge
model for all MOSFET devices.
Table 3 Full-chip, full-transistor simulator options
Using conventional partition method, all the blocks connected to an internally generated
supply (cf. Figure 9) have to be contained in a single partition, resulting in unacceptable
simulation performance. VR simulation is specifically designed to overcome this
limitation.
Finally, the simulator’s log file must be carefully read in order to see if there are no issues
or main warnings which could lead to an incorrect behavior of the simulator, such as a
bad partitioning or remaining Verilog-A models.
The settings presented in Table 3 have been carefully tuned in order to match silicon
measurements.
Over consumption and leakages are often very difficult to debug on silicon. This
methodology has proven to be very powerful to save this debug time, and it also
prevented several IC respins.
Unfortunately, some undesired consumptions due to floating nodes can not be caught by
traditional simulations. The following chapter presents how we track them.
7. Floating nodes
Some sanity checks need to be done before tape-out to track potential floating nodes.
Indeed, today’s wireless handsets and portable multimedia player integrate an incredible
set of features such as GPS, high resolution screens, WiFi, Bluetooth, still and video
cameras, etc… In order to deliver an acceptable battery life to these portable devices,
advanced power management techniques have been developed, such as power gating
which consists in turning off some of the supplies on the IC.
Unfortunately, such techniques often result in unknown states and floating nodes. The
floating nodes are the nodes that present high impedance values with respect to ground or
supply nets. They appear when they are not correctly driven by the design.
26

27. No Power VDD
Floating node
Figure 16 Example of floating node condition : the driver gate is powered down. Its floating output
can cause both PMOS and NMOS of the load to be passing, creating a short circuit leakage.
These floating nodes cannot be detected via usual transient simulations and are often
discovered on silicon, as they create over consumptions. As usual, the impact of detecting
issues on silicon is much higher that detecting them before the IC is fabricated, leading to
potentially being late on the market.
Because of that, we are using a tool that measures the impedance of each node in the
circuit, compares it to a user-defined threshold and generates the corresponding detailed
report. Cadence provides similar capabilities with the pcheck option of Ultrasim solver.
However, it does not report the values of the impedance, and has no integrated viewer to
ease the analysis (cross-probing between the report and the schematic).
Note that some nodes can voluntarily be high-impedance even when supplies are present,
for example in switched capacitors circuits. In any case, designers can analyze the report
and determine whether some nodes are badly controlled. As of today, this analysis at
chip-level (full transistor) is still tedious.
8. Tracking coverage with the Verification Matrix
This chapter presents the way we, at Freescale, track the verification coverage, during the
whole development cycle of our Power-Management ICs.
We gather all the specification items into an Excel document that we call the Verification
Matrix. The main focus is on functionality. However, some of the performance items are
also reported. Typically on our Power-Management ICs, several thousands of items are
listed in the matrix.
For each item, we document the required test conditions, the associated pair of Cadence
configuration and vector file, whether the item is to be verified at block-level only, or if a
chip-level simulation is required, a priority number used to mitigate the risks, and finally
a column is dedicated to add comments.
27

28. This priority level is consolidated during a Verification Matrix Review with the design
team. Typically, new functions have the highest priority. Then come the ones that need to
be adapted. Some other high priority simulations are the ones that check the startup, turn
off, some basic functionality such as communication with processor, etc… The latter are
required to be run at transistor-level.
Table 4 Example of Verification Matrix core sheet
For the ICs of the same family, providing their specifications have enough chapters in
common, we use the same Matrix. When the test of a specific item is developed, and the
item has been verified for a given IC, we report that into the matrix.
The latter is then able to gather all this information and build a coverage report for each
IC, allowing a continuous coverage follow up.
Several coverage are actually defined, giving the percent of items being verified at block-
level and at chip-level, the total reached coverage, and the percent of the items still
uncovered by the test suite.
It is worth mentioning that a 100% coverage, does not guarantee a bug-free design.
Indeed, there are quite often several ways to verify a specification item. For example,
some bugs are “sequence-dependent”. Let’s take the example of a function that needs
several SPI bits to be set. What if they all get programmed in a single SPI access, or if
they get programmed sequentially, and in a specific order? Will the function activated
behave the same?
Future improvements consisting in automatically generating stimuli, based on constrained
pseudo-random techniques, such as the ones already used in digital, will be able to reduce
this risk.
28

29. As mentioned, the Verification Matrix is used for several ICs of the same family. It is a
form of reuse (cf. “Verification IP re-use” Chapter). It is also reused, as a good starting
point, for the new projects, providing they are close enough in terms of specifications.
Indeed, writing down the matrix is quite a big task, but we’ve done it from scratch only
once, while we’ve used it on a complete family of ICs.
The Verification Matrix is finally reviewed with the design team and the management, in
order to identify some missing items, and to limit misunderstandings between teams.
9. Regression Testing
Last but not least, running all these simulations during the development of the project is
fine, but we need to make sure that the final database which is sent to fabrication is still
compliant with the simulation results we obtained. Hence, we need to re-run all
simulations at the very end of the development cycle. This is what we call regression (or
non-regression) testing: we ensure that no functional or performance regression got
introduced in the IC during the latest changes.
There are at least two pre-requisites for regression testing. The first one is that all tests
must be self-checking. Indeed, one cannot expect the engineers to visually review the
waveforms of hundreds of tests in the last days before tape-out. The Verification IP
library is made for that (cf. chapter 3). As luck would have it, this opens the door for all
techniques of random or pseudo-random stimulus generation that can be used to find
unexpected design corners or combinations.
9.1. Running a simulation from the command line
The second pre-requisite is that one must be able to launch the simulation from the
command line. Indeed, one cannot expect the verification engineer to stay at his
computer’s desk to click on the run button each time a new simulation needs to start.
This is done by using the AMS-Designer command which takes in the name of the
Cadence top cell and configuration, and from that determines what all of the files being
pulled into the simulation should be.
In order to ease the usage of the AMS-Designer command, a wrapper script was written.
The first thing the wrapper does is create a run directory for the simulation. By including
the hostname and process ID in the name, the run directory will always be unique each
time the wrapper script is called. This allows for multiple tests to be run in parallel with
no chance of conflict between the runs. The solver can be chosen directly from the
command line (either Spectre or Ultrasim), and the model files can be altered from the
default typ values to either bcs or wcs values.
One can also save off toggle coverage information for the top level of the chip for each
test. They can be combined to see the overall coverage of all tests taken together.
29

30. Finally, the script also allows one to submit the job directly to LSF with the –lsf option.
LSF will then select the most available compute servers, so that all tests can be run in
parallel on a pool of machines.
An example command line is given in Listing 9.
wrapper -lib top_verification -cell top_testbench -view config_topctrl
-test_name common_topctrl_revid -lsf -waves -waves_dir $RUN_DIR
Listing 9 Starting a simulation from the command line (Example)
9.2. Automatic log parser and regression suite report
We have also developed a script which parses all tests’ log files and collect the results in
a comprehensive report file.
30

31. Regis submitted the regression at Wed Mar 12 18:45:34 CET 2008
Workarea used was X_top_verification.07
Logfiles can be found in $WORKAREA/top_verification/logfiles
TEST NAME CONFIG NAME BCS TYP WORST LOGFILE
------------------------------------------------------------------------------------------------------------------------------
charger_batfet config_charger_batfet N/A NOT_RUN N/A [...]
gpadc config_gpadc N/A NCELAB N/A
gpo1 config_gpo1 N/A NOT_RUN N/A
pll config_pll N/A NOT_RUN N/A
startup config_startup N/A NOT_RUN N/A
tcled config_tcled N/A NCELAB N/A
topctrl_fsm config_topctrl N/A NOT_RUN N/A
topctrl_i2c config_topctrl N/A VNE N/A
topctrl_revid config_topctrl PASS PASS PASS
vcam config_vcam N/A NCELAB N/A
vdig config_vdig N/A FAIL N/A
viohi config_viohi N/A FAIL N/A
vpll config_vpll N/A FAIL N/A
vgen1 config_vgen1 N/A NCELAB N/A
vgen2 config_vgen2 N/A NCELAB N/A
vgen3 config_vgen3 N/A NCELAB N/A
vsd config_vsd N/A NCELAB N/A
sw1 config_sw1 N/A FAIL N/A
sw2 config_sw2 N/A FAIL N/A
backlight config_backlight N/A NCELAB N/A
[...]
N/A: The test was not in the regression for this mode
NOT_RUN: Logfile was not found.
ANE: Analog netlist error.
VNE: Verilog netlist error, check the log file for *E
NCELAB: Elaboration Error, check your config
RUNNING: Job is either still running, or it may have been terminated early
RUNERR: Job started running, but found a *E with no PASS/FAIL indication.
NOT_SC: Not self checking, simulation seemed to complete, but END_TEST was never called
NOCFG: Cadence couldn't find the config, likely caused by a machine with automount problems
UNKNOWN: Status could not be determined from log file
FAIL: Test finished with Errors
PASS: Test pass, yay!!!
Catagory Total(%) BCS(%) TYP(%) WCS(%)
--------------------------------------------------------------------------------------------------------------------------
Number tests in regression 66(100.00%) 2(100.00%) 62(100.00%) 2(100.00%)
Number Tests submitted 36( 54.55%) 2(100.00%) 32( 51.61%) 2(100.00%)
NOT_RUN 30( 45.45%) 0( 0.00%) 30( 48.39%) 0( 0.00%)
ANE: 0( 0.00%) 0( 0.00%) 0( 0.00%) 0( 0.00%)
VNE: 6( 9.09%) 0( 0.00%) 6( 9.68%) 0( 0.00%)
NCELAB: 15( 22.73%) 0( 0.00%) 15( 24.19%) 0( 0.00%)
RUNNING: 0( 0.00%) 0( 0.00%) 0( 0.00%) 0( 0.00%)
RUNERR: 0( 0.00%) 0( 0.00%) 0( 0.00%) 0( 0.00%)
NOT_SC: 0( 0.00%) 0( 0.00%) 0( 0.00%) 0( 0.00%)
NOCFG: 0( 0.00%) 0( 0.00%) 0( 0.00%) 0( 0.00%)
UNKNOWN: 0( 0.00%) 0( 0.00%) 0( 0.00%) 0( 0.00%)
FAIL: 9( 13.64%) 0( 0.00%) 9( 14.52%) 0( 0.00%)
PASS: 6( 9.09%) 2(100.00%) 2( 3.23%) 2(100.00%)
Listing 10 Regression suite report example
31

32. 10. Conclusion
Since 2003, we’ve been able to successfully verify a complete Power-Management IC
family of up to 1 million transistors, and more.
The approach described in this paper, allowed us to find critical bugs before tape-out and
to get a very high level of IC functionality on first silicon. This has been a very strong
requirement for fast platform’s software integration. In the mean time we also proved the
effectiveness of the IC modifications due to specification changes.
We have also been able to correlate our current consumption simulations with the real
silicon, and to detect some accidental floating nodes.
Overall, we reduced significantly our time-to-market and development costs.
11. Future improvements
We are closely observing several initiatives, such as Verimag’s AMT tool, or a future
SystemVerilog-AMS standard, that would propos AMS assertions.
Finally, as mentioned above, automatic regression tests opens the door for all techniques
of random or pseudo-random stimulus generation that can be used to find unexpected
design corners or sequence hazards.
As G.Bonfini writes in “An Analog Mixed-Signal Verification Kit for Verification of
Analog-Digital Circuits” (YOGITECH SpA, via Lenin 132/p, 56017 San Martino
Ulmiano (Pisa), Italia): “If verification of digital sub-systems is based on advanced
techniques such as constraints capture, randomized or pseudo-randomized stimulus-
generation and result collection with functional coverage evaluation, on the other side the
use of hand-coded analog blocks models, manually-verified within a digital verification
environment has been sufficient to provide confidence in a mixed-signal design to sign-
off prior to submitting it for fabrication. However, due to greater levels of integration,
changes in process technology and increasing market pressures and risks, an automated
and metric-driven methodology is now required”
The team
This paper is the result of a collective work that has taken place for several years at
Freescale. I would never have been able to write it down without the collaboration of Bill
Getka and Mike Doll, digital and verification engineers at Freescale Libertyville (USA),
Thierry Nouguier from our Toulouse CAD support team, Ana Ferreira-Noullet and Jean-
Claude Mboli from the Power-Management Verification team at Freescale Toulouse
(France).
32

33. About the author
Regis Santonja received a Bachelor of micro-electronics and signal processing from the
quot;Ecole Supérieure d’Ingénieurs en Eletrotechnique et Electroniquequot; (France) in 1993. He
began as an Applications Engineer at LSI LOGIC (France) and spent a few years in
several countries around Europe and in the U.S.A. as a digital IC designer. After a short
period working for the quot;Compagnie des Signaux Technologie Informatiquequot; (France), he
joined Motorola’s Power Management design team as a digital designer. Since 2002, he
has taken the lead of the verification activity of Freescale Power-Management ICs
dedicated to mobile phones and Portable Media Players.
Bibliography
- Detecting Leakage Problems in Low-Power Designs, Mike Demler, Nikkei
Electronics Asia – September 2007
- An Analog Mixed-Signal Verification Kit for Verification of Analog-Digital
Circuits, G.Bonfini, M. Chiavacci, R. Mariani, E. Pescari, YOGITECH SpA
- Regression Testing in Analog Verification, By Henry Chang and Ken Kundert
- Top-Down Design and Verification of Mixed-Signal Circuits, Ken Kundert, Henry
Chang.
- Regression Testing in Analog Verification, Part 1, Henry Chang and Ken
Kundert.
- Verification of Complex Analog and RF IC Designs, Henry Chang and Ken
Kundert.
- Verification Plan Reuse – Extending Verification Reuse for Verification Plan
Definition and Verification Environment Implementation, Nihar Shah and Sasan
Iman, SiMantis Inc.
- Analog Design Collaboration and Configuration Management, Paul Bompastore,
TI.
- Verification Plan Reuse, Nihar Shah, Sasan Iman, Simantis, Inc.
33