The How To’s

of Advanced Mixed-Signal Verification

John Brennan, Thomas Ziller, Kawe Fotouhi,
Ahmed Osman
Cadence Design Systems

© Accellera Systems Initiative 1

 Agenda

1. Metric-Driven Verification for MS

2. Verification Planning and Management in MS

3. Universal-Verification Methodology for MS

4. Real-number Modeling Capabilities

5. Analog and MS Assertions

6. Q&A
Metric-Driven Verification for Mixed-signal
John Brennan
The Winds of Change
Many forces at work to drive change
Software
Control

Industry Integration of
Standards AFE
Mixed
Signal

Digital Process ≤
Calibration/
Computation 28nm

TIPPING POINT INDICATORS

• Digitally-calibrated, compensated
• Feedback between D and A
• Software controlled
• Power management
• 28nm and below
Source: IBS
• Long Verification Cycles
 Mixed-signal Verification: Complexity Issues
Mixed-signal DUT &
How do I build consistency between
Verification test bench environment
digital and analog teams?
How do I verify the digital
content in this SoC?
How do I verify the mixed-signal
interconnects?

Design
Analog
Design
Measure

How do I abstract How do I verify the

analog behavior? mixed-signal IP?
Advanced Verification Methodology
Functional Verification Approaches

Directed Tests Driven

Results
Test 1:  Least effective
Test 2: 
in finding the
DUT Test 3:
Test 4:
x
 hidden bugs

Test targets

Coverage Driven
Results Adds quality &
Coverage productivity,
CG1  but difficult to
G DUT CG2
CG3

x
estimate
CG4  completion
Coverage targets

Metric Driven Chip Features Feature-based

Results 50% plan with
Feature A
G extended
Subset 1 …. 20%
DUT A Subset 2 …. 80%
metrics
enables
Verif. Plan
C D B Feature B 10%
efficient
• Feature A
Feature C 70%
• Feature B Feature-based and accurate
• Feature C
Feature D 20% project closure
Verification targets
• Feature D
(Metrics for cov+checks)
 Metric Driven Verification (MDV): Overview
Planning with unified verification metrics
Metric-based
Executable
PDF
Verification plan
Yes No

Done Signoff? Incisive®

Plan VIP Portfolio

Target Metrics Milestones Successful Milestone

Measure /
Coverage
Actual Metrics Achieved Missed Milestone

Construct Assertions
Analyze
Checks
VE Start Module Module Chip Prototype Production
Set One Set Two Integration

Execute
Coverage & Failure
Analysis IEM
Metric Visualization
JG ISX
IES SN

Testbench Simulation,
Formal,
HW/SW Co-Sim, LPV, MSV,
Sim-Acceleration, Emulation
Key Elements of MS Verification Solution

• Planning
• Tracking to closure
• Execution and debugging
• Integrated Digital
Environment verification
concepts

Behavioral
Simulation Modeling
• Methodology
• Performance • Library
• Tools abstracting
• Features
analog and mixed-
signal functionality
Cadence mixed-signal verification solution
Bridging the GAP, addressing complexity

Focus for Today*

Integration & Automation

Metric-Driven
Verification
Methodology
Plan,Track,Analyse,Report

TB Development
Sim Management
UVM Mixed Signal Re-use and Automation
PSL / SVA Assertion
(Analog Design
Functional Coverage
Environment)
Enabling technology
Analog Modeling (SMG) RNM Simulation
Multi-Mode Simulation (MMSim) Multi-Language Simulation
Fast SPICE (XPS) (Incisive) Core simulation engine

Transistor Simulation (Spectre) Logic Simulation (Incisive)

Abstraction Level
Analog High accuracy Digital High simulation throughput
 Agenda

1. Metric-Driven Verification for MS

2. Verification Planning and Management in MS

3. Universal-Verification Methodology for MS

4. Real-number Modeling Capabilities

5. Analog and MS Assertions

6. Q&A
Verification Planning in MS
Kawe Fotouhi
What is a Meaningful Verification plan?
• Functional Verification is the
process of proving the
convergence of the functional
specification, the design intent,
and the Test environment Functional
Specification
Implementation
of verification
implementation Verification environment
Plan
• A good and meaningful
verification plan will prove that
convergence Design Intent
 Fundamentals of a Good
Verification Plan
Functional Implementation
Specification of verification
env
Functional
&
Design Metrics
Specs
Verification Be able to correlate
Plan features with
corresponding
Directly links and measured metrics
maps all specified
features and key
details
design and
Verification
team
Correctly captures
important implementation
Design Intent specific concerns
 Creating a Feature based Verification Plan I
Feature Identification
• Get all project related people together
– Analog designer, analog and digital verification engineer, Marketing, Concept, Software, ...
• „Brainstorm“ plan hierarchy and features based on
– Specification
– KnowHow, experience & gut feeling
• Feature analysis focuses on :
– "What" to verify
– Which domain (analog/digital) to verify
– "How” to verify
• Feature Examples
– Device mode and configuration options
– Traffic or protocol handling
– Protocol or device exception handling
– Performance specification
– Operation conditions (PVT)
• Process variations
• Voltage supply
• Temperature
– Application modes
– External connections
– Typical and critical use and corner cases (duty cycle, phase noise ratio etc.)
 Creating Feature based Plan II
Attribute Elaboration

• Translating Feature requirements into concrete metric goals

• Ask HOW features will be measured
• Identify required testcases, coverage and checks metrics
• Which attributes and values are important?
– Driven by the spec
• Where should each value be observed?
– At boundary or involving internal signals
• When are the values valid to be sampled?
– reaching a certain voltage in a given time window after power-up
 PLL output (txi_clk) analog performance and functional feature

Test the SNR in combination

with ref_clk offset

- Cover corner case frequency

- Check PLL locks
 PLL (txi_clk) output Digital

Cover all possible output frequency

(randomize fsynth) FRACTIONAL
and INTEGRAL MODE
 PLL Core feature – modelling requirements

PLL locks even if it shouldn’t if the

dutycycle of the ref clock is too large
 Agenda

1. Metric-Driven Verification for MS

2. Verification Planning and Management in MS

3. Universal-Verification Methodology for MS

4. Real-number Modeling Capabilities

5. Analog and MS Assertions

6. Q&A
UVM for Mixed-signal
Thomas Ziller
Using UVM to Apply MDV
• Components of a MDV environment
– Automated Stimulus Generation
– Independent Checking
– Coverage Collection
stimulus sequences
coverage and check metrics
stimulus sequences sequence scoreboar
stimulus sequences library cov check
d
stimulus sequences

sequencer
seed new test transaction
monitor transaction
monitor
stimulus
0x223F
stimulus
0XA30E cov check cov check

stimulus
0X94D7
stimulus
0XFF78 UVC
stimulus
0X3767
stimulus
0XCC18
stimulus
0XDA83
stimulus
0XBA1F
stimulus
0X95FB
stimulus
driver slave
0X382E DUT
MS-MDV Block Diagram (dms_wire, SV top)
SV TB env

UVM master_agent
sequencer
Classes
Real Numbers seq
seq
seq

monitor driver
Customizable VIF VIF
dms_wire gasket
Real Numbers IF
Wreal/Electrical
VAMS CTRL
Netlist Gasket CTRL
CTRL
DUT
VAMS/Transistor SigGen Sampler

Phase
`uvm_do_with ana1_wire_seq {
clk_period == 0.5; // sample clk Bias
ampl == 0.001; // 1 mV
Amplitude
bias == 1.1;
freq == 100e6; // 100 MHz 0
phase == 0.0;
}
0 Frequency
SV RNM: Coverage/Randomization
• Coverage/Randomization of reals
• Cadence provides full coverage/randomization support
– Full compliment of real variable usage in randomization

// Vector bins with precision

class my_tb_cls;
rand real voltage; Randomization
constraint my_constr {voltage dist of the voltage
{ [1.0 :1.25] := 1,
[1.25:1.5 ] := 10,
[1.5 :2.0 ] := 1 };
Coverage of what
} voltage values
covergroup cg { were generated
my_voltage : coverpoint voltage {
type_option.real_interval = 0.1;
bins b1[] = {[1.0:2.0]};
}
endgroup : cg
endclass
 N-Fractional PLL Mixed-Signal
UVM-MS Testbench Hierarchy Structure
tb_dut (SV top)
sequencer
dms_wire pll_sim (vams)
master_agent pll DUT (vams)
driver real dms_wire_uvc
VIF electrical
IF gasket (vams) avdd
monitor VIF
fsynth<13:0>
logic ...
clk
pll_tx_agent
logic electrical

logic
driver VIF pll_stim (vams)
IF
monitor VIF
 N-Fractional PLL Mixed-Signal
Constrained Random Simulation Results
Constrained
random
variations

Set fsynth

Cal. done PLL lock Cal. done

Lock
Calibration Settling Calibration Settling

Turn on avdd supply

N-Fractional PLL Mixed-Signal
”avdd” Supply Range Checking

UVM-MS env. PLL DUT

Constrained dms_wire Vreg Vco
avdd div2clk
Random real Analog UVC PLL Volt. 1.2V and
Number Gen. electrical Regulator Div/2
[2.325 ... 2.675]

div2clk
avdd
+7% over_volt div2clk
over_volt avdd
+5% supply_ok div2clk
2.5 supply_ok
-5% 0V under_volt
under_volt
-7%
N-Fractional PLL Mixed-Signal
”avdd” Supply Range Checking
supply_ok
vco starts

avdd supply within 2.5V+/-5% range under_voltage

vco remains turned-off

avdd<2.375V  under_voltage condition

MS Regression Control & Analysis
Functional Coverage Results Example (20 runs)

Covergroup definitions:
covergroup bias_cg;
bias_cp : coverpoint bias {
bins over_volt = {[2.625:10]};
bins supply_ok =
{[2.375:2.625]};
bins under_volt ={[0: 2.375]}; }
endgroup // bias_cg
covergroup cg_fsynth;
cp_fsynth: coverpoint fsynth{
illegal_bins a =
{[14'h2201:14'h3fff]};
option.auto_bin_max = 25; }
endgroup : cg_fsynth

Automated Runs (2x10, randomized),

coverage data collection
 Agenda

1. Metric-Driven Verification for MS

2. Verification Planning and Management in MS

3. Universal-Verification Methodology for MS

4. Real-number Modeling Capabilities

5. Analog and MS Assertions

6. Q&A
Real-number Modeling Capabilities
Ahmed Osman
 Performance : Simulation throughput
Behavioral Modeling DMS vs AMS

• Model analog block operation as

discrete real data SPICE/APS

– Signal flow-based modeling FastSPICE

SoC Functional

Accuracy
approach Verilog-AMS
Verification

VHDL-AMS
• Key advantages of RNM Wreal/
SV-RNM
– Discrete solver only
– Very high simulation performance Pure
Digital
– Event driven or sampled data Performance
modeling of analog operation
– No analog solver, no convergence Effort
problems! Verilog- AMS
VHDL AMS
– Can be written by analog designers Wreal/
and/or digital verification engineers FastSPICE
SV-RNM
Pure
Digital
• RNM languages include SPICE/APS

‒ Verilog-AMS (wreal) Performance

‒ VHDL
‒ SystemVerilog wreal & wreal &
‒e electrical logic
 Analog or Real Modeling: What is the
Difference?
Analog Modeling Real Modeling
• Describes current vs. voltage • No matrix solution – output
relationship between nodes in computed directly from input &
model internal state. Model defines when
to perform each internal
• Newton-Raphson iteration process
computational segment
performs matrix inversion to solve
all voltage and currents • No continuous time operation –
only sampled, clocked, and/or
• Timestep until next solution is
event-driven operations. Updates
selected based on accuracy criteria
can be performed when inputs
change and/or at specific time
increments
• Same format for digital and real
modelling – difference is data type
SystemVerilog IEEE 1800-2012 LRM
– User-Defined Types (UDTs)
• Allows for single-value real nettypes
• Keyword used: nettype
• Allows for multi-value nets (multi-field record style)
• It can hold one or more values (such as voltage, current, impedance)
in a single complex data type that can be sent over a wire
– User-Defined Resolution (UDRs)
• Functions to resolve user-defined types using keyword: with
• Specifies how to combine user defined types
– Interconnect Nets
• Types
– Explicit: Type-less/Generic nets with keyword: interconnect
– Implied: A Verilog(-AMS) net with keywords: wire, tri, wand, triand,
wor, or trior
• Used only for a net or port declarations
 SystemVerilog User-Defined Nets
– User-Defined Nets can carry V(out) V(in)
one or more values over a
single net. SV SV
Analog Analog
– Real values can be used to Model UDT
UDT
Model

communicate voltage, {V,I,R} {V,I,R}

current and other values

between design blocks
Real-value
– User-Defined Resolutions (UDR) V(out) nettype
functions are used to combine UDR
Programmable
multiple outputs together. SV means to define
Analog how multiple fields
Model UDT in a UDT are
{V,I,R} resolved
 Declaring User-Defined Nettype
• A SystemVerilog user-defined nettype without any resolution function can be
declared as:
nettype T myNet;

Keyword Nettype identifier

UDT
Example // user-defined data type T
module top; typedef struct {
nettype T myNet; real voltage;
myNet w; real current;
assign w = T'{0.1, 0.2, 1'b1, 10}; bit field3;
initial begin integer field4;
$display("Value of w -> %f => %p",$realtime, w);
} T;
#1 $display("Value of w -> %f => %p",$realtime, w); UDT
#5 $display("Value of w -> %f => %p",$realtime, w);
end
endmodule

Value of w -> 0.000000 => '{voltage:0, current:0, field3:'h0, fileld4:x}

Value of w -> 1.000000 => '{voltage:0.1, current:0.2, field3:'h1, fileld4:10}
Value of w -> 6.000000 => '{voltage:0.1, current:0.2, field3:'h1, fileld4:10}
 Declaring User-Defined Net with Resolution Function
• A user-defined SystemVerilog nettype with its resolution functions can be declared as:
nettype data_type nettype_identifier with
[package_scope|class_scope] tf_identifier] ;
• nettype_identifier is the identifier you specify for the nettype.
• [package_scope|class_scope] tf_identifier] can be a Cadence built-in
resolution function or any typedef to the built-in real type

//Declaring a UDT nettype with UDR

nettype T wTsum with Tsum;

// user-defined data type T // user-defined resolution function Tsum

typedef struct { function automatic T Tsum (input T driver[]);
Tsum.field1 = 0.0;
real field1;
Tsum.field2 = 0.0; UDR
real field2; foreach (driver[i]) begin
} T; Tsum.field1 += driver[i].field1;
UDT Tsum.field2 += driver[i].field2;
end
endfunction
 User-Defined Nettype Example
Data Type and Resolution Function Model
(As a Package)
package temp_pkg; import temp_pkg::*;
module top; Resolved
// user-defined data type T wTsum w;
T myvar; {4.0,6.0}
typedef struct { assign myvar = w; d1
real field1;
w
} T;
real field2; UDT driver1 d1(w);
driver2 d2(w);
r1
receiver1 r1(w);
// user-defined resolution function Tsum endmodule d2
module receiver1 (input wTsum rec_1);
function automatic T Tsum (input T driver[]);
always @(rec_1.field1, rec_1.field2)
Tsum.field1 = 0.0;
$display($time , ," sum = %f flag = %f \n",
Tsum.field2 = 0.0;
foreach (driver[i]) begin UDR rec_1.field1, rec_1.field2);
if (driver[i].field1 !== `wrealZState)
endmodule
Tsum.field1 += driver[i].field1;
if (driver[i].field2 !== `wrealZState)
module driver1 (output wTsum dr_1);
Tsum.field2 += driver[i].field2;
assign dr_1 = T'{1.0, 2.0};
end
endmodule
endfunction

// A nettype declaration with datatype and resolution function module driver2 (output wTsum dr_2);
assign dr_2 = T'{3.0,4.0};
nettype T wTsum with Tsum; endmodule

endpackage

Nettype
 Electrical Package in SystemVerilog
• An Electrical Package for Systemverilog (EE_pkg.sv) defines an electrical
equivalent net (V-I-R) for use in discrete analog behavioral models.
• You can use the new EE_pkg package to port existing wreal models to SV.

 Describes the structure

EEstruct (UDT) which
consists of three reals
namely V, I and R.

• Has a UDR function that describes how the resolution of V, I and R are
resolved, res_EE.
• This package ends with the nettype declaration statement:
• The EEnet will conform to Kirchoff's laws.

nettype EEstruct EEnet with res_EE;

Case Study 1: N-Fractional PLL Mixed Signal
Voltage
Regulator

2MHz refclk Level Charge

Shifter Pump
Loop Filter
VCO

PFD

ESD Divider

Level Shifter

 Modulator + Digital
Control
Case Study 1: N-Fractional PLL Mixed Signal

Charge Pump
Loop Pass Filter
(bilinear transform)

EEnet

Loop Filter
(EE_pkg)
 Case Study 1: N-Fractional PLL Mixed Signal
• Loop Filter Voltage output (Verilog-AMS vs. SV EE_pkg)
Verilog-AMS

SV-RNM VAMS
EE_pkg
CPU Time 47 seconds 1 hr 8 min. 32 sec
SystemVerilog

A speed gain of 90x over mixed-signal Verilog-AMS

Case Study2: 3rd – order Feed-forward Gm-C 𝚫𝚺 ADC
High-level Sizing and frequency scaling

Schematic of 3rd – order Gm-C 𝚫𝚺 ADC

Case Study2: 3rd-order Feed-forwardGm-C 𝚫𝚺 ADC
Simulation results for input signal = 80mV

VAMS

SVRNM
 Case Study2: 3rd-order CIFF Gm-C 𝚫𝚺 ADC
Simulation results for ain = 80mV

 Spectrum Assistant has been used in ViVA to evaluate various spectrum properties, e.g.
SINAD, ENOB, THD, etc.

SV-RNM VAMS
SQNR 72.92 dB 72.33 dB
SINAD 71.06 dB 72.33 dB
ENOB 11.515 11.72
THD % 18.19m % 8.1m %
Noise Floor (per sqrt Hz) -126 dB/sqrt Hz -125.3 dB/sqrt Hz
CPU Time 0.4 seconds 92.5 seconds

A speed gain of 230x over mixed-signal Verilog-AMS

 Agenda

1. Metric-Driven Verification for MS

2. Verification Planning and Management in MS

3. Universal-Verification Methodology for MS

4. Real-number Modeling Capabilities

5. Analog and MS Assertions

6. Q&A
Analog and MS Assertions
Ahmed Osman
 Automation & re-use thru Assertions
in Digital, Analog, and Mixed Signal
Why Assertions? Language Support Not New for Analog
Assume SVA Device checks
Assert Spectre MDL
Cover PSL $cds_get_analog_value

Data converters • e.g. Monotonicity,DNL, comparator meta-stability

Digitally-assisted • e.g. Calibration / process variability compensation

analog
Systems with • PLL : e.g. PLL lock-in time, Output frequency tuning
Feedbcak • Sigma-Delta : e.g. Integrator stability, presence of tones

Multiple modes • Power modes, programmable gain, adaptive filters

Analog / Mixed-signal PSL Assertions
• Real Assertion (using RNM data type)
– PSL with explicitly declared wreals
– SVA using real variable

real vin;
// psl vin_check : assert always ( 1.2 < vin && vin < 1.3 )
// @(posedge clk);

• Analog Assertion (electrical domain behavior)

– PSL or e containing analog objects or access functions or operators
– (This is not possible in SVA since there is no analog object allowed in SV)

electrical vin;
// psl vin_check : assert always ( 1.2 < V(vin) && V(vin) < 1.3 )
// @( cross(V(clk)-1.25));
 Analog PSL assertions:
Verification Unit
• Verification units in PSL can contain analog objects
• Write your PSL statements/vunit into a file, e.g. inv_vams.pslvlog
• Example:
module INV_vams ( out1, in1 );
output out1;
input in1;
electrical in1, out1;
analog begin
if (V(in1) >= 1.25)
V(out1) <+ 0.0;
else
V(out1) <+ 2.5;
end vunit inv_vams_inst_vunit(INV_vams)
endmodule {
// psl assert
// always ( V(out1) < 1.25 )
// @( cross(V(in1)-1.25));
}
 Demo

© Accellera Systems Initiative 50

 Questions

© Accellera Systems Initiative 51