This document discusses the challenges of verifying mixed-signal integrated circuits. It presents how Freescale used Cadence eManager and a variety of modeling and simulation techniques to verify a sensor IC. They took a progressive approach starting with digital simulations using wreal models for speed and then incorporating more accurate Verilog-AMS and transistor-level models. They were able to set up a single simulation environment in eManager to run analog, digital and mixed-signal simulations. The document discusses using control-oriented and data-oriented functional coverage to ensure the chip's functionality was verified.

1. Mixed-Signal Verification Challenges
Regis Santonja, Verification Engineer, Freescale
Semiconductors
The increasing complexity of today’s Mixed-Signal Integrated Circuits (IC) goes with
increasing needs in IC verification to ensure the functionality, but also signal integrity
and power consumption. This paper is going to present the challenges of mixed-signal
verification in its two main phases: simulation setting and coverage analysis on the
other hand. In the mean time, it will present how, at Freescale, we took up these
challenges during the development of a real-case Sensor IC, using Cadence eManager
together with Verilog-AMS, SystemVerilog, and “wreal-based” digital models of the
analog environment.
CDNLive! EMEA 2010 1 Challenges of Mixed-Signal Verification

2. Contents
Presentation of the IC and its Verification Environment................................................ 3
Early simulations with wreal models............................................................................. 3
Mixed-signal simulations .............................................................................................. 4
A single simulation environment................................................................................... 5
Simulation Results and Coverage.................................................................................. 7
Control-oriented functional coverage ........................................................................ 8
Data-oriented functional coverage............................................................................. 8
Applying advanced digital methods to mixed-signal verification................................. 10
Conclusion.................................................................................................................. 10
Bibliography ............................................................................................................... 11
CDNLive! EMEA 2010 2 Challenges of Mixed-Signal Verification

3. Presentation of the IC and its Verification Environment
The methodology detailed in this paper has been applied to a low-power three axis
accelerometer IC dedicated to consumer applications. It has several programmable G-
scales and output data rate frequencies It can detect orientation, motion, taps, and free-
fall events. This is a mixed-signal chip where analog and digital functions are roughly
of the same size and complexity.
The chip-level testbench is hierarchical. Its top-level is in Verilog-AMS and gives the
ability to exercise the IC through its digital and analog interfaces, including the
supplies. The sequence of each test is based on a usual initial process, the analog
interface being controlled from it, via the sharing of real values that affect the analog
begin section. Each specific test is coded in a vector file that is included into the
testbench at compilation, thanks to a compiler directive. The monitoring is taken in
charge both by the Verilog-AMS part of the bench, and by an instantiated
Systemverilog monitoring module. The diagram below presents the IC and its
surrounding testbench.
Bandgap
AMS LDO
stimulation Memory SV
oscillator
Monitoring
DSP
ADC
Code coverage
Analog
Generators
Custom Logic I2C Functional
coverage
Supplies and Digital
TESTBENCH
Figure 1 The SoC and its mixed-Signal, Mixed-level testbench
Early simulations with wreal models
We adopted a progressive verification approach to verify our circuit. We started the
chip-level simulations in a pure digital world, using the wreal modeling technique,
taking advantage of the execution speed of the digital solver, and the lack of
convergence issues. This let us look, early in the verification process, for potential long-
run issues that were not affordable with analog or even mixed-signal simulations.
CDNLive! EMEA 2010 3 Challenges of Mixed-Signal Verification

4. However, wreal modeling also has several drawbacks, especially, if the model requires
a high “analog” accuracy level, or when it gets mixed with analog blocks. The code
might then get more complex than its Verilog-AMS equivalent. First of all, you have to
address the connection of wreal nets to logic pins yourself. Secondly, analog operators
available in plain Verilog-AMS code cannot be used here.
Verilog-AMS is rich of several analog operators, such as derivative, time and circular
integrator, transition and slew (that are used to remove discontinuities that help
preventing convergence issues when connected to analog circuits). Finally they include
Laplace and Z-transform filters and the last_crossing function to get the last simulation
time when a signal crossed zero. In pure wreal models, none of these operators are
available, as they can only appear in the analog process. Hence, using wreal models
makes it impossible to backtrack and find the time when a signal crossed a value. It is,
however, possible to design filters, transforms, integration or derivative functions. But
this needs to be done manually, which is not trivial. The input signal must be normally
sampled at twice its Nyquist frequency, or higher, but the more the steps, the slower the
simulation. Still, an analog transfer function, expressed in the s-domain, can be modeled
in the discrete z-domain thanks to the bilinear transform.
Moreover, wreal is based on a signal-flow model and can only handle a single value for
each node, whereas plain Verilog-AMS code represents each signal node with two
values: its potential and its flow. This is the conservative systems model. Signal-flow is
perfect for early verification, but, as the design progresses and some analog behaviors
need to become more accurate, it becomes necessary to take the flow into account.
Indeed, there is no easy way to model basic analog components such as capacitors or
resistors using wreal.
Mixed-signal simulations
Verilog-AMS models can be slow to simulate, depending on the modeling technique
and the level of abstraction used. A model can even be slower than its actual transistor
design! We have presented in a previous paper (“Verification of 1M+ transistors Mixed-
Signal IC for Cellular and Multimedia Applications”, Cadence Live 2008), how it is
possible to speed-up mixed-signal simulations by a mixed-level approach based on
minimal, but well targeted models.
Analog and digital signals are connected together via connect modules. Cadence
provides a set of connect modules to connect both logic and wreal to analog (electrical)
nets, and vice versa. However, when mixing wreal models with analog blocks, there are
several difficulties. One shows up when the value to be transferred through the
connection is representing a current. Indeed, the E2R default connect modules are
representing a voltage source. Tweaking the connect rules of such an R2E and make its
range better fit the required current values, or tweaking its output resistor is not enough
to appropriately represent a current source. Fortunately, Cadence gives in its “Verilog-
AMS Real Valued Modeling Guide” an example of what a R2E representing a current
source output can be. Similarly, an E2R_current main body could be something like:
connectmodule E2R_current (Dout, Ain);
output Dout;
wreal Dout; //output wreal
CDNLive! EMEA 2010 4 Challenges of Mixed-Signal Verification

5. input Ain;
electrical Ain; //inout electrical
electrical vref;
<parameters declaration>
real Iin;
real Dreg;
assign Dout = Dreg;
always @(absdelta(Iin, idelta, ttol, itol))
Dreg = Iin;
analog begin
V(vref) <+ 0.5*vsupply;
I(Ain,vref) <+ V(Ain,vref); //1 ohm resistor btwn Ain and vref
Iin = transition(V(Ain,vref), 0, tr, tf);
end
endmodule
One difficulty with these connect modules is that they pass the values with no sign
change, hence do not respect the usual current sign convention which considers the
current to be positive when getting into the block, and negative when flowing out of it.
Hence, we can get inconsistencies when mixing wreal models with analog, depending
on which block is swapped. Hence smarter connect modules to interface currents have
to be written.
As the design of our accelerometer progressed towards completion, more and more
blocks could be verified at transistor-level. High-frequency analog blocks could be kept,
at first, as wreal models, while those that had a close-to-DC behavior, such as the
biasing, could start being verified at transistor-level. In some cases, an intermediate step
was to replace some wreal models with more accurate Verilog-AMS models. We finally
ended with full-transistor simulations. Indeed, the more the blocks at transistor-level,
the higher the chances to catch leakages, over-consumptions, oscillations and
instabilities, or floating nodes, that cannot be caught earlier.
A single simulation environment
Traditionally, the analog, digital and mixed-signal designers, each, have a specific
simulation environment and flow. However, it is possible to use eManager as a single
front-end for analog, digital and mixed-signal simulations, providing we know how to
launch them from a command-line.
Additionally, having all our simulations self-checking, even the analog ones, eManager
can track our global Test Coverage. The latter is a metric which simply counts which
test passed and which failed, and presents the result as a coverage percentage. Indeed,
eManager is able to scan the simulation log files, look for specific words, strings, or
regular patterns, and record the test’s status accordingly.
Our digital simulations were launched based on the Unix make command and a
corresponding Makefile. Here is an extract of our VSIF file used by eManager to launch
our digital simulations:
session chip_regression {
top_dir : regressions;
output_mode: terminal;
group digital_simulations {
CDNLive! EMEA 2010 5 Challenges of Mixed-Signal Verification

6. timeout: 0; // No time out.
count: 1;
run_script: 'make ncsim TEST=$RUN_ENV(BRUN_TOP_FILES)
COMP_ARGS="-sv" SIM_ARGS="+nowavedump";';
scan_script: vm_scan.pl generic.flt shell.flt ius.flt;
test vey_i2c_standby_shift { count : 1 ;
top_files : vey_i2c_standby_shift;
};
Figure 2 Launching our pure digital simulations from eManager (extract of the VSIF file)
The Makefile tells the make command what to do in details. In the case of our digital
simulations, it launches ncvlog, ncelab and ncsim commands. Some generic command
switches are given to these commands via corresponding CAF files.
ncsim:
ncvlog -file rtl_func.caf -logfile ncvlog.log
-define stimulus_file="$(TEST).v" $(COMP_ARGS)
ncelab -file ncelab.caf -coverage a -logfile ncelab.log
ncsim -status -file ncsim.caf -logfile $(TEST).log
$(SIM_ARGS)
-covoverwrite -covdesign digital -covtest $(TEST)
...
Figure 3 Extract of the Makefile used to launch digital simulations
Our mixed-signal, mixed-level simulations were launched from eManager with a
custom Perl script (start_test.pl) that builds the appropriate amsdesigner command after
a pre-compilation of specific modules such as the custom connect modules and the
Systemverilog monitor. Here is an extract of the VSIF:
group mixed_simulations {
verification_scope: AMS;
timeout: 0;
count : 0;
run_script : “start_test.pl
-lib top_verification
-cell top_testbench
-view $ATTR(my_config)
-test_name $RUN_ENV(BRUN_TOP_FILES)
-run_dir `pwd`
cds_globals generic.cds_globals
-define SEED=`perl -e 'print
int(rand(1e6))'`
-profile";
scan_script: vm_scan.pl generic.flt shell.flt ius.flt;
test i2c {
count : 1 ;
my_config : config_ams;
top_files : i2c;
};
...
Figure 4 Launching our mixed-signal simulations from eManager (extract of the VSIF file)
CDNLive! EMEA 2010 6 Challenges of Mixed-Signal Verification

7. The amsdesigner command is able to read Cadence configuration views from the DFII
analog environment. The configuration views tell which representation of each block in
the design is to be compiled for each specific simulation. This is the place where we
select either a wreal model, an AMS model, or a transistor schematic for each block in
the design.
You can notice that a seed is fed to the simulation with a `define directive. We’ve been
using this seed to drive random ramp-up and ramp-down times on the chip’s power
supplies. The goal was to capture potential cross-conduction between supply lines. Here
is a piece of digital code in the testbench which drives the analog block to generate the
proper supplies. The variables used to drive the rise, fall and delays are real numbers.
initial begin
`ifdef SEED
VDD_rise = 100u + 1u*($random(seed) % 100);
VDD_fall = 100u + 1u*($random(seed) % 100);
VDDIO_rise = 100u + 1u*($random(seed) % 100);
VDDIO_fall = 100u + 1u*($random(seed) % 100);
`endif
end
Figure 5 Creating random supply ramps and delays
The piece of analog code which actually applies the supplies to the chip looks as
follows:
analog begin
V(VDD_stim) <+ transition(VDD_level, 0, VDD_rise, VDD_fall)
I(VDD, VDD_stim) <+ V(VDD, VDD_stim)/RVDD;
V(VDDIO_stim) <+ transition(VDDIO_level, 0, VDDIO_rise,
VDDIO_fall);
I(VDDIO, VDDIO_stim) <+ V(VDD_IO, VDDIO_stim)/RVDDIO;
end
Figure 6 Piece of analog code to drive the supplies
The other analog pins are driven the same way, all controlled from the digital process.
They are driven through resistors whose values are also driven from the digital code.
They can be set to high values to emulate high impedance states, for example when the
corresponding chip’s pin is configured as an output. This mechanism also allows the
dynamic connection of more complex external circuitry (such as RC filters), all being
controlled from the testbench and its stimulus file.
Simulation Results and Coverage
After we were able to simulate the chip, starting with wreal models, then with a mix of
wreal, Verilog-AMS and real transistors, and finally at full-transistor level, we needed
to ensure that enough required functionality got covered.
Test Coverage just tells which simulation passes or fails, but does not say what is
verified. There are two other types of coverage metrics for that: the Code Coverage, and
the Functional Coverage. The first one is automatic and measures the verification
completion of the digital part of the design.
CDNLive! EMEA 2010 7 Challenges of Mixed-Signal Verification

8. We have used ICC (Incisive Comprehensive Coverage) to build the necessary coverage
reports to identify the verification holes and generate additional tests to cover them.
eManager automatically interfaces with ICC and handles the coverage files generated
by the simulations.
We observed that we were right away having an excellent FSM state coverage, but that
some transitions were missing, usually the ones that go back to the Idle state when the
state-machine is interrupted. In the same spirit, we initially had a pretty poor toggle
coverage, especially on reset or enable lines. Indeed, not only is important to validate
what the chip should do (when we enable a particular function), but also what the chip
should not do (if the function is disabled).
The Functional Coverage is based on the specification and is basically a list of the
functional features that need to be covered. It is closely linked to the verification plan
and needs to be specified by the user prior to simulation. As such, it needs more effort
up-front than the automated, effortless Code Coverage.
Systemverilog provides language constructs to specify functional coverage of values or
expressions and their cross-coverage. It also gives means to create and manipulate
coverage bins and associate them with measures.
Control-oriented functional coverage
Our IC measures its acceleration on the 3 dimensional axes which are multiplexed in
time in order to share common hardware resources. The signal chain that converts the
analog acceleration to digital numbers is made of several time-multiplexed analog
stages. The time-sequence of controls of all the involved switches and commands is
very critical for the final converted result accuracy and must be carefully verified.
We have used concurrent assertion constructs provided by Systemverilog to check the
complex chronograms of the control signals fed to the analog signal chain. Here is an
example of how the chronogram of one regulator enable was constantly verified along
every simulation scenario:
prop_vreg_en : assert property
(@(posedge clk) $rose(hf_en)
|=> (vreg_en[*72] ##1 ~vreg_en[*240] ##1 vreg_en[*172] ##1
~vreg_en[*140])[*1:$])
`STIM.PRINT_PASS("vreg_en is OK");
else begin
$warning("%m fails");
PRINT_ERROR("");
end
Figure 7 Code example of a Systemverilog concurrent assertion
Data-oriented functional coverage
Data-oriented functional coverage tracks the number of times a specific variable in the
design reaches a specified set of values, or transitions, or a combination of those.
Systemverilog defines covergroups to gather those variables together. These variables
are called coverpoints. All the coverpoints within a covergroup are evaluated on the
same “clocking” event. The latter can be any expression that becomes true, or even the
start or the end of execution of a named block, task, function, or class method.
CDNLive! EMEA 2010 8 Challenges of Mixed-Signal Verification

9. As an example, here is how we tracked the coverage of all the programmable I2C
registers of our accelerometer. The actual code was generated automatically from the
I2C register map specified in an Excel document.
`define STATUS_FLD 0
`define XD_FLD 1
`define YD_FLD 2
`define ZD_FLD 3
`define F_CNT_FLD 4
`define F_WMRK_FLD 5
`define F_OVF_FLD 6
`define F_MODE_FLD 7
`define NONE 'h300
event i2c_write_field_event;
typedef enum {
STATUS_FLD = `STATUS_FLD,
XD_FLD = `XD_13_6_FLD,
YD_FLD = `YD_5_0_FLD,
ZD_FLD = `ZD_13_6_FLD,
F_CNT_FLD = `F_CNT_FLD,
F_WMRK_FLD = `F_WMRK_FLAG_FLD,
F_OVF_FLD = `F_OVF_FLD,
F_MODE_FLD = `F_MODE_FLD,
NONE = `NONE } i2c_field_type;
i2c_field_type i2c_write_field = `NONE;
covergroup cg_i2c_write_field @i2c_write_field_event;
cov_i2c_write_field : coverpoint i2c_write_field
{option.auto_bin_max = 512;} // otherwise limit is 64 values for
enum
endgroup : cg_i2c_write_field
cg_i2c_write_field I_cg_i2c_write_field = new();
always @(`STIM.f_cnt)
if ($time > 0)
begin
@(`DIGITAL_CORE.vey_i2c.i2c_write);
i2c_write_field = `F_CNT_FLD;
-> i2c_write_field_event;
end
Figure 8: Functional Coverage code for our I2C registers
Additionally, we could track analog events, such as the voltage level reached by the
internal supplies and biasing signals. The code example below shows how we can
record that the bandgap did start. The Systemverilog part of the code is instantiated in
the Verilog-AMS testbench. The latter monitors the signal of interest and sends an event
to the Systemverilog monitor. Here is a piece of the latter:
`define VBGON 1
`define VGBOFF 2
event vbg_event;
CDNLive! EMEA 2010 9 Challenges of Mixed-Signal Verification

10. typedef enum { VBGON = `VBGON,
VBGOFF = `VBGOFF } vbg_state_type;
vbg_state_type vbg = `VBGOFF;
covergroup cg_vbg @vbg_event;
cov_vbg : coverpoint vbg;
endgroup : cg_vbg
cg_vbg I_cg_vbg = new();
Figure 9 Systemverilog code used to monitor analog functional coverage
And here is the related AMS piece of code:
always @(cross(V(`TOPCELL.vbg)-0.9, 0, 1n, 10u))
begin
if (V(`TOPCELL.vbg) > 0.9)
covmon.vbg = `VBGON;
else
covmon.vbg = `VBGOFF;
-> vbg_event;
end
Figure 10 Verilog-AMS code used to trig the Systemverilog monitor on an analog event
Applying advanced digital methods to mixed-signal
verification
Wreal modeling is a means to handle real, analog-like signals, within the discrete digital
solver. As such, it opens the door of mixed-signal simulation to some highly advanced
digital verification tools and methodologies.
However, the quality of the verification is only as good as the quality of the test case
simulations that were developed. Reaching 90% coverage with directed tests is a tough
and costly challenge, in terms of time-to-market, and return on investment. Hence a
complementary approach would be to have an automatic test case generation solution,
just as it exists in pure digital verification. This approach would not replace the need to
write traditional directed tests. It would just be a means to complement the available
suite of directed tests.
As Systemverilog can now be used within mixed-signal, mixed-level simulations, we
can take advantage of its ability to track all types of coverage. As it also enables on-the-
fly queries of the coverage with system tasks such as $get_coverage(), a closed-loop
coverage-driven approach becomes possible. Constrained random stimuli generation
can explore unexpected places of the verification space.
Conclusion
We have presented how, at Freescale, we managed to guaranty a first pass success to a
three axis accelerometer IC, adopting a progressive verification approach, starting with
pure wreal models, then progressively replacing those with more accurate Verilog-AMS
ones, and finally with their transistor-level representation, ending with (full-)transistor
simulations.
CDNLive! EMEA 2010 10 Challenges of Mixed-Signal Verification

11. We have seen that, despite the fact that wreal modeling enables chip-level simulations
very early in the design cycle, helping system designers to find early issues, it also
presents some limitations and difficulties. Still, wreal coding can model complex analog
behaviors, at digital speed, and can be considered a bridge between the analog and the
digital world, opening the door of all the latter’s advanced verification techniques to
mixed-signal ICs.
We have also seen that eManager can be used as a common front-end for all our
simulations. Additionally, as it is linked with ICC, it can gather all types of coverage
metrics available for analog, digital and mixed-signal domains.
Bibliography
• Verification of 1M+ transistors Mixed-Signal IC for Cellular and Multimedia
Applications, in Cadence Live 2008 proceedings, Regis Santonja, Freescale
Semiconductors.
• Verilog-AMS Real Valued Modeling Guide, Cadence Design Systems Inc. 2009.
• ICC Used Guide, Cadence Design Systems Inc. 2009.
• Assertion Writing Guide, Cadence Design Systems Inc. 2009.
• Verilog-AMS Language Reference Manual, version 2.2, Accellera, November
2004.
• Systemverilog 3.1a Language Reference Manual, Accelleram May 2004.
• Solutions for mixed-signal SOC verification. As old methods fall short, new
techniques make advanced SOC verification possible, Kishore Karnane, Greg
Kurtis and Richard Goering, Cadence Design Systems, Inc.
• A scalable Verification Methodology to Overcome the limitations of current
Verification approaches, Brian Bailey, chief technologist for the Design
Verification and Test Division of Mentor Graphics.
• Verification of complex Analog Integrated Circuits, in Custom Integrated
Circuits Conference 2006 proceedings Ken Kundert and Henry Chang.
• Evolving the Coverage-Driven Verification Flow, Matthew Balance, Mentor
Graphics.
• Maximizing Verification Effectiveness using Metric-Driven Verification, Nick
Heaton, Senior Solution Architect, Cadence Design Systems, Inc.
CDNLive! EMEA 2010 11 Challenges of Mixed-Signal Verification