mixed signal verification challenges

CDNLive! EMEA 2010 1 Challenges of Mixed-Signal Verification

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.


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


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.

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.

LDO

ADC

DSP

I2C Custom Logic

oscillator

Memory

Bandgap

Digital Supplies and

Analog

Generators

AMS

stimulation SV

Monitoring

Code coverage

Functional

coverage

TESTBENCH


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


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 {


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)


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.


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.


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;


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.


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.

mixed signal verification challenges

Technology