The How To’sof 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
5. Analog and MS Assertions
3. Universal-Verification Methodology for MS
4. Real-number Modeling Capabilities
6. Q&A
Metric-Driven Verification for Mixed-signalJohn Brennan
Mixed Signal
Software Control
Integration of AFE
Process ≤ 28nm
Digital Calibration/
Computation
IndustryStandards
The Winds of ChangeMany forces at work to drive change
Source: IBS
TIPPING POINT INDICATORS• Digitally-calibrated, compensated• Feedback between D and A• Software controlled• Power management• 28nm and below• Long Verification Cycles
Mixed-signal Verification: Complexity IssuesMixed-signal DUT &
Verification test bench environment
Measure
Design
How do I verify the mixed-signal IP?
How do I verify the mixed-signalinterconnects?
How do I verify the digital content in this SoC?
AnalogDesign
How do I abstractanalog behavior?
How do I build consistency betweendigital and analog teams?
Advanced Verification Methodology Functional Verification Approaches
Test targets
DUT
Test 1:
Test 2:
Test 3: xTest 4:
Least effective
in finding the
hidden bugs
Directed Tests DrivenResults
DUTG
CoverageCG1
CG2
CG3 x
CG4
Coverage DrivenResults Adds quality &
productivity,
but difficult to
estimate
completionCoverage targets
80%
20%
10%
70%
DUTG
Chip Features
Feature ASubset 1 ….
Subset 2 ….
Feature B
Feature C
Feature D
Verif. Plan
• Feature A
• Feature B
• Feature C
• Feature D
Metric Driven50%
20%
Feature-based
plan with
extended
metrics
enables
efficient
and accurate
project closure
Results
ABDC
Feature-based
Verification targets
(Metrics for cov+checks)
Plan
Construct
Execute
Measure /
Analyze
Metric Driven Verification (MDV): OverviewPlanning with unified verification metrics
Done
Yes No
Signoff?
Metric-based
Executable
Verification planPDF
VE Start ProductionPrototypeChip
Integration
Module
Set TwoModule
Set One
Actual Metrics AchievedTarget Metrics Milestones
Missed Milestone
Successful Milestone
VE Start ProductionPrototypeChip
Integration
Module
Set TwoModule
Set One
Actual Metrics AchievedTarget Metrics Milestones
Missed Milestone
Successful Milestone
Coverage & Failure
Analysis
Metric Visualization
IEM
Checks
Assertions
Coverage
Incisive®VIP Portfolio
Testbench Simulation, Formal,HW/SW Co-Sim, LPV, MSV, Sim-Acceleration, Emulation
ISXJG
IES SN
Key Elements of MS Verification Solution
Digital verification
concepts
Behavioral Modeling
Simulation
• Performance
• Features
• Methodology
• Library
• Tools abstracting
analog and mixed-
signal functionality
• Planning
• Tracking to closure
• Execution and debugging• Integrated
Environment
Cadence mixed-signal verification solutionBridging the GAP, addressing complexity
A b s t r a c t i o n L e v e l
Analog High accuracy Digital High simulation throughput
Inte
gra
tio
n &
Au
tom
ati
on
Metric-Driven
Verification
Methodology
Logic Simulation (Incisive)Transistor Simulation (Spectre)
RNM Simulation
Multi-Language Simulation
(Incisive)
Analog Modeling (SMG)
Multi-Mode Simulation (MMSim)
Fast SPICE (XPS)
UVM Mixed Signal
PSL / SVA Assertion
Functional Coverage
TB Development
Sim Management
(Analog Design
Environment)
Re-use and Automation
Plan,Track,Analyse,Report
Enabling technology
Core simulation engine
Focus for Today*
Agenda
1. Metric-Driven Verification for MS
2. Verification Planning and Management in MS
5. Analog and MS Assertions
6. Q&A
3. Universal-Verification Methodology for MS
4. Real-number Modeling Capabilities
Verification Planning in MSKawe Fotouhi
• Functional Verification is the process of proving the convergence of the functional specification, the design intent, and the Test environment implementation
• A good and meaningful verification plan will prove that convergence
What is a Meaningful Verification plan?
Design Intent
VerificationPlan
Functional
SpecificationImplementation
of verification
environment
Design Intent
Fundamentals of a Good Verification Plan
VerificationPlan
Functional
Specification
Functional&
DesignSpecs
Implementation
of verification
env
Metrics
design and
Verification
team
Be able to correlate
features with
corresponding
measured metrics
Correctly captures
important implementation
specific concerns
Directly links and
maps all specified
features and key
details
• 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 a Feature based Verification Plan IFeature Identification
• 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
Creating Feature based Plan IIAttribute Elaboration
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
5. Analog and MS Assertions
6. Q&A
3. Universal-Verification Methodology for MS
4. Real-number Modeling Capabilities
UVM for Mixed-signalThomas Ziller
UVC
scoreboar
d
transactiontransactionmonitor monitor
sequencer
stimulus
Using UVM to Apply MDV• Components of a MDV environment
– Automated Stimulus Generation
– Independent Checking
– Coverage Collection
driverDUT
slave
0x223Fstimulus0XA30E0X94D70XFF780X37670XCC180XDA830XBA1F0X95FB0X382E
stimulusstimulusstimulusstimulusstimulusstimulusstimulusstimulusstimulus
seed new test
coverage and check metrics
check
check check
cov
cov cov
stimulus sequences
stimulus sequences
stimulus sequences
stimulus sequences
sequence
library
SV TB
MS-MDV Block Diagram (dms_wire, SV top)
VAMS
Netlist
env
master_agentsequencer
drivermonitor
VIFVIF
Gasket
SigGen Sampler
IFReal Numbers
DUT
VAMS/Transistor
seqseqseq
UVM
Classes
Customizable
dms_wire gasket
Real Numbers
CTRLCTRLCTRL
Wreal/Electrical
0
0
Frequency
Amplitude
Bias
Phase`uvm_do_with ana1_wire_seq {
clk_period == 0.5; // sample clk
ampl == 0.001; // 1 mV
bias == 1.1;
freq == 100e6; // 100 MHz
phase == 0.0;
}
• Coverage/Randomization of reals
• Cadence provides full coverage/randomization support
– Full compliment of real variable usage in randomization
SV RNM: Coverage/Randomization
// Vector bins with precision
class my_tb_cls;
rand real voltage;
constraint my_constr {voltage dist
{ [1.0 :1.25] := 1,
[1.25:1.5 ] := 10,
[1.5 :2.0 ] := 1 };
}
covergroup cg {
my_voltage : coverpoint voltage {
type_option.real_interval = 0.1;
bins b1[] = {[1.0:2.0]};
}
endgroup : cg
endclass
Randomization
of the voltage
Coverage of what
voltage values
were generated
N-Fractional PLL Mixed-SignalUVM-MS Testbench Hierarchy Structure
tb_dut (SV top)
pll_sim (vams)pll DUT (vams)
pll_stim (vams)
sequencer
dms_wire_uvc
gasket (vams)
dms_wire
master_agent
driver
IFVIF
monitor VIF
realelectrical
logic electrical
avdd
pll_tx_agent
driver
IFVIF
monitor VIF
logic
logicfsynth<13:0>
clk
...
N-Fractional PLL Mixed-Signal Constrained Random Simulation Results
Calibration Settling
PLL lockCal. done
LockCalibration Settling
Cal. done
Constrained
random
variations
Set fsynth
Turn on avdd supply
div2clk
N-Fractional PLL Mixed-Signal”avdd” Supply Range Checking
dms_wire
Analog UVC
Vreg
PLL Volt.
Regulator
Vco
and
Div/2
Constrained
Random
Number Gen.
[2.325 ... 2.675]
PLL DUT
div2clk
UVM-MS env.
electrical
real avdd
-7%
+7%
+5%
-5%
2.5 supply_ok
under_volt
over_volt
1.2V
0V
avdd
supply_ok
under_volt
over_voltavdd
div2clk
div2clk
N-Fractional PLL Mixed-Signal”avdd” Supply Range Checking
vco starts
avdd supply within 2.5V+/-5% range
vco remains turned-off
avdd<2.375V under_voltage condition
supply_ok
under_voltage
covergroup cg_fsynth;
cp_fsynth: coverpoint fsynth{
illegal_bins a =
{[14'h2201:14'h3fff]};
option.auto_bin_max = 25; }
endgroup : cg_fsynth
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
MS Regression Control & AnalysisFunctional Coverage Results Example (20 runs)
Covergroup definitions:
Automated Runs (2x10, randomized),
coverage data collection
Agenda
1. Metric-Driven Verification for MS
2. Verification Planning and Management in MS
5. Analog and MS Assertions
6. Q&A
3. Universal-Verification Methodology for MS
4. Real-number Modeling Capabilities
Real-number Modeling CapabilitiesAhmed Osman
Performance : Simulation throughputBehavioral Modeling DMS vs AMS
Performance
Acc
ura
cy
Verilog-AMS
VHDL-AMS
Pure
Digital
Wreal/
SV-RNM
FastSPICE
SPICE/APS
SoC Functional
Verification
Eff
ort
SPICE/APS
Verilog- AMS
VHDL AMS
Pure
Digital
Wreal/
SV-RNMFastSPICE
Performance
• Model analog block operation as discrete real data
– Signal flow-based modeling approach
• Key advantages of RNM– Discrete solver only – Very high simulation performance– Event driven or sampled data
modeling of analog operation– No analog solver, no convergence
problems!– Can be written by analog designers
and/or digital verification engineers
• RNM languages include‒ Verilog-AMS (wreal)‒ VHDL‒ SystemVerilog‒ e
wreal &
electrical
wreal &
logic
Analog or Real Modeling: What is the Difference?
Analog Modeling
• Describes current vs. voltagerelationship between nodes in model
• Newton-Raphson iteration process performs matrix inversion to solve all voltage and currents
• Timestep until next solution is selected based on accuracy criteria
Real Modeling
• No matrix solution – output computed directly from input & internal state. Model defines when to perform each internal computational segment
• No continuous time operation –only sampled, clocked, and/or event-driven operations. Updates 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 one or more values over a single net.
– Real values can be used to communicate voltage, current and other values between design blocks
– User-Defined Resolutions (UDR) functions are used to combine multiple outputs together.
V(out) V(in)
V(out)
Real-value
nettypeUDR
Programmable
means to define
how multiple fields
in a UDT are
resolved
UDT
{V,I,R}
SV
Analog
Model
UDT
{V,I,R}
SV
Analog
Model
UDT
{V,I,R}
SV
Analog
Model
Example
Declaring User-Defined Nettype• A SystemVerilog user-defined nettype without any resolution function can be
declared as:
// user-defined data type Ttypedef struct {
real voltage;
real current;
bit field3;
integer field4;
} T;UDT
nettype T myNet;
KeywordUDT
Nettype identifier
module top;
nettype T myNet;
myNet w;
assign w = T'{0.1, 0.2, 1'b1, 10};
initial begin
$display("Value of w -> %f => %p",$realtime, w);
#1 $display("Value of w -> %f => %p",$realtime, w);
#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_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
nettype data_type nettype_identifier with
[package_scope|class_scope] tf_identifier] ;
//Declaring a UDT nettype with UDRnettype T wTsum with Tsum;
// user-defined resolution function Tsumfunction automatic T Tsum (input T driver[]);
Tsum.field1 = 0.0;
Tsum.field2 = 0.0;
foreach (driver[i]) begin
Tsum.field1 += driver[i].field1;
Tsum.field2 += driver[i].field2;
end
endfunction
// user-defined data type Ttypedef struct {
real field1;
real field2;
} T;
UDT
UDR
User-Defined Nettype Example
package temp_pkg;
// user-defined data type Ttypedef struct {
real field1;
real field2;
} T;
// user-defined resolution function Tsumfunction automatic T Tsum (input T driver[]);
Tsum.field1 = 0.0;
Tsum.field2 = 0.0;
foreach (driver[i]) begin
if (driver[i].field1 !== `wrealZState)
Tsum.field1 += driver[i].field1;
if (driver[i].field2 !== `wrealZState)
Tsum.field2 += driver[i].field2;
end
endfunction
// A nettype declaration with datatype and resolution functionnettype T wTsum with Tsum;
endpackage
import temp_pkg::*;
module top;
wTsum w;
T myvar;
assign myvar = w;
driver1 d1(w);
driver2 d2(w);
receiver1 r1(w);
endmodule
module receiver1 (input wTsum rec_1);
always @(rec_1.field1, rec_1.field2)
$display($time , ," sum = %f flag = %f \n",
rec_1.field1, rec_1.field2);
endmodule
module driver1 (output wTsum dr_1);
assign dr_1 = T'{1.0, 2.0};
endmodule
module driver2 (output wTsum dr_2);
assign dr_2 = T'{3.0,4.0};
endmodule
Data Type and Resolution Function(As a Package)
Model
d1
d2
r1 w
Resolved
{4.0,6.0}
UDT
UDR
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.
• 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;
Describes the structure EEstruct (UDT) which consists of three reals namely V, I and R.
Case Study 1: N-Fractional PLL Mixed Signal
Voltage
Regulator
2MHz refclk Level
Shifter
PFD
Charge
Pump
VCO
Divider
Level Shifter
Modulator + Digital
Control
ESD
Loop Filter
Charge PumpLoop 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)
EE_pkg
SystemVerilog
Verilog-AMS
SV-RNM VAMSCPU Time 47 seconds 1 hr 8 min. 32 sec
A speed gain of 90x over mixed-signal Verilog-AMS
Case Study 1: N-Fractional PLL Mixed Signal
Case Study2: 3rd – order Feed-forward Gm-C 𝚫𝚺 ADCHigh-level Sizing and frequency scaling
Schematic of 3rd – order Gm-C 𝚫𝚺 ADC
Case Study2: 3rd-order Feed-forwardGm-C 𝚫𝚺 ADCSimulation results for input signal = 80mV
VAMS
SVRNM
Case Study2: 3rd-order CIFF Gm-C 𝚫𝚺 ADCSimulation 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
5. Analog and MS Assertions
6. Q&A
3. Universal-Verification Methodology for MS
4. Real-number Modeling Capabilities
Analog and MS AssertionsAhmed Osman
Automation & re-use thru Assertionsin Digital, Analog, and Mixed Signal
Why Assertions?
Assume
Assert
Cover
Language Support
SVA
PSL
Not New for Analog
Device checks
Spectre MDL
$cds_get_analog_value
• e.g. Monotonicity,DNL, comparator meta-stabilityData converters
• e.g. Calibration / process variability compensationDigitally-assisted
analog
• PLL : e.g. PLL lock-in time, Output frequency tuning
• Sigma-Delta : e.g. Integrator stability, presence of tones
Systems with Feedbcak
• Power modes, programmable gain, adaptive filtersMultiple modes
• Real Assertion (using RNM data type)– PSL with explicitly declared wreals– SVA using real variable
• 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)
Analog / Mixed-signal PSL Assertions
real vin;
// psl vin_check : assert always ( 1.2 < vin && vin < 1.3 )
// @(posedge clk);
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
endmodule
vunit inv_vams_inst_vunit(INV_vams)
{
// psl assert
// always ( V(out1) < 1.25 )
// @( cross(V(in1)-1.25));
}
Demo
© Accellera Systems Initiative 50
Questions
© Accellera Systems Initiative 51