1. Mixed-Signal UVM Demonstration using Real-Number Models
and System Verilog
September, 2015
Bob Peruzzi, Joe Medero, Cathy Miedema
1

2. Agenda
• Introduction
– problem/solution
• DUT
– Application
– Functional description
• Verification Plan
• Execution of Verification Plan
– Directed
– UVM
• UVM Introduction
– Basics
– Environment
– Stimulus
– Monitoring
– Coverage
• Summary
2

3. • SOCs are here to stay
• They will encompass more analog/mixed signal
• Including RF, analog front end and back end, data
conversion
• With nano-meter technologies, including fin-fet, analog
design cannot stand alone without digital enhancement
and calibration
• Fewer and fewer chips will be digital only or analog only
• Digital design verification (DV) approach, including the
Universal Verification Methodology (UVM), is the best
approach for mixed signal DV
Introduction
3

4. • PROBLEM: UVM is a large and complex methodology and
it was designed with digital in mind
• SOLUTION: This presentation demonstrates real-number
modeling techniques and the use of UVM for analog and
mixed-signal verification
Introduction
4

5. Outline of solution
• Present and explain DUT
• What needs to be verified in the DUT
• Verification plan
• execution using directed testing
• execution using UVM
Introduction
5

6. DUT is a Dual Converter - ADC and DAC
Example application - test instruments:
DAC for stimulus with ADC for calibration
ADC for measurement with DAC for calibration
Operating modes illustrated on following slides
DUT
6

7. DUT
7

8. DUT
8

9. DUT
9
Color code:
• red - logic 1
• green - logic 0
• blue - active data path

10. DUT
10
Color code:
• red - logic 1
• green - logic 0
• blue - active data path

11. DUT
11
Color code:
• red - logic 1
• green - logic 0
• blue - active data path

12. DUT
12
Color code:
• red - logic 1
• green - logic 0
• blue - active data path

13. DUT
13
Color code:
• red - logic 1
• green - logic 0
• blue - active data path

14. DUT
14
Color code:
• red - logic 1
• green - logic 0
• blue - active data path

15. Verification Plan
Digital Verifications
• Mode control functionality
Analog Verifications
• Frequency response. That is,
– Amplitude gain versus frequency
– Phase shift versus frequency
• Output common-mode voltage
• Output differential DC offset
15

16. Execution using Directed Testing
Digital Verifications
• Mode control functionality
• Step through all 16 input combinations and check that
output controls are as expected
Analog Verifications
• Frequency response
• Use a variety of input digital and analog sine waves
Measure output amplitudes, zero crossing delays, output
common-mode voltage and differential DC offset. Calculate gain
and phase shift versus frequency.
16

17. Execution using UVM
Digital Verifications
• Mode control functionality
• all 4 mode control inputs are constrained random values
Analog Verifications
• Frequency response
• Use a variety of input digital and analog sine waves using
constrained random controls
The monitors and scoreboard measure output amplitudes, zero
crossing delays, output common-mode voltage and differential
DC offset. Calculate gain and phase shift versus frequency. All
values are checked that they are within defined tolerances.
17

18. • Key UVM concepts used by digital verification engineers
that were adapted and applied to the mixed signal circuit:
– Transaction based stimulus and monitoring
– Constrained-random verification
– Self checking testbench
– Driver, Monitor and Scoreboard adaptations for mixed-
signal.
– Functional Coverage
UVM Introduction
18

19. UVM Basics
● UVM is a library of System Verilog classes that can be used to
build verification environments.
● We will be focusing on a few key pieces, most of which are
generally contained in a UVM Avent. This presentation is not
meant to thoroughly cover all of UVM.
Agent
Sequencer (if active) Driver (if active)
Monitor
Config
19
Interface
Analysis Port

20. UVM Test Environment
20
ams_base_test
ams_env
mode_control_agent
Interface
ams_sequence
digital_output_agent
(passive)
analog_output_agent
(passive)
clock_agent
vdd_gnd_agent
ams_env_scoreboard
analog_input_agent
(active)
digital_input_agent
(active)
InterfaceInterface
Interface
InterfaceInterface
Interface

21. • One of the main challenges when adding analog signals
to a UVM environment is that the continuous time signals
need to be defined by discrete transactions (also known
as sequence items).
• For an RNM-Sequencer the transactions could define
parameters such as vcm, offset, frequency, amplitude,
phase, lifetime, etc.
• The transaction is then passed to the analog Driver which
then generates the continuous time signals accordingly.
Transaction Based Stimulus
21

22. • Observed signals must also be summarized into
transactions by the analog Monitor.
• Defining the start and end point of a Monitor transaction
can be an even bigger challenge than on the stimulus
side.
• One method is to have the test start and stop the
monitor. Another way would be to use something in the
signals themselves as the trigger.
• The monitor transaction might include information such
as vcm, offset, frequency, amplitude, zc and zc_last.
Transaction Based Monitoring
22

23. • The different signal parameters defined in a transaction
can all be constrained-random values.
• Classes can be extended and constraints tightened to
have a variety of flavors of transactions or the constraints
can be left to be highly random depending on the need
(note, projects often use both at various times)
• Realistic signals contain multiple frequency components
that need to be added to properly to test the system.
Constrained-Random Verification
23

24. • Using directed testing it is possible to do the checking
visually or within the testcase for simple circuits.
• With more complex circuits and/or constrained random
stimulus this becomes more of a challenge and we need
to move to having the testbench perform closed loop
checking.
• Assertions can be used in the DUT code and in the
testbench to check behavior.
• Scoreboards can be used for more complex checking,
they can be implemented for an entire DUT, for a block,
for a subblock or some/all of the above.
Self Checking Testbench
24

25. UVM Analog Driver
• The driver is a piece of code that directly interacts with an
interface to the DUT.
• The driver waits for a sequence item (transaction) and
uses the contained information to drive the interface
accordingly.
25

26. class analog_driver #(parameter real PTby2asclk = 1, real tscale = 1) extends uvm_driver #(analog_drv_seq_item);
`uvm_component_param_utils(analog_driver #(PTby2asclk,tscale))
<removed code>
task run_phase(uvm_phase phase);
analog_drv_seq_item seq_item;
real temp_val;
forever begin
seq_item_port.get_next_item(seq_item);
for (int jj=0; jj < (seq_item.lifetime*(tscale/PTby2asclk*1e6)); jj++) begin
temp_val = 0.0;
for (int ii=0; ii < seq_item.num_components; ii++) begin
temp_val += seq_item.amplitude[ii] * $sin(2 * `PI * seq_item.frequency[ii] * $realtime *tscale + seq_item.phase[ii]);
end // for
m_analog_if.driver_mp.analog_p = seq_item.vcm + seq_item.offset + temp_val;
m_analog_if.driver_mp.analog_n = seq_item.vcm + seq_item.offset - temp_val;
#(PTby2asclk/tscale);
end // for
seq_item_port.item_done();
end // forever
endtask : run_phase
endclass : analog_driver
UVM Analog Driver Code
26

27. • The monitor is a piece that summarizes the activity on a
pin or group of pins and assembles it into a transaction.
• Monitors generally pass these transactions to a
scoreboard for further evaluation.
UVM Analog Monitor
27

28. class analog_monitor #(parameter real PTby2asclk = 1, real tscale = 1) extends uvm_monitor;
<...>
task run_phase(uvm_phase phase);
<initialize values>
forever begin
fork
begin
wait((m_analog_if.monitor_mp.analog_p != previous_analog_p) ||
(m_analog_if.monitor_mp.analog_n != previous_analog_n));
analog_diff = m_analog_if.monitor_mp.analog_p - m_analog_if.monitor_mp.analog_n;
if (m_config.is_monitoring == 1'b1) begin
<update vmax/vmin if appropriate>
<calculate amplitude_trans, offset_trans, vcm_trans>
<update zc, zc_last and frequency_trans if appropriate>
end
<copy values to previous_* versions>
end
begin
wait ((m_config.is_monitoring == 1'b0) && (previous_is_monitoring == 1'b1));
seq_item = analog_mon_seq_item::type_id::create("seq_item");
<fill in seq_item.* with amplitude_trans, offset_trans, vcm_trans, frequency_trans, zc and zc_last>
analog_ap.write(seq_item);
reset_variables();
previous_is_monitoring = m_config.is_monitoring;
end
join_any
end // forever
endtask : run_phase
endclass : analog_monitor
UVM Analog Monitor Code
28

29. UVM Scoreboard
• Scoreboards receive information from monitors and use
them to determine if the DUT is behaving as expected.
• For this example the scoreboard uses monitor
transactions from the mode_control, analog_input,
digital_input, analog_output and digital_output monitors.
• The resulting frequency, offset, phase and gain are all
calculated and checked depending on the mode. The
testcase is failed and error messages print if they are not
within set tolerances.
29

30. Functional Coverage
• Functional Coverage can be defined anywhere in the
verification environment but they are usually contained in the
monitors and/or scoreboards.
• Functional Coverage bins are all digital so analog signals hav
to be converted into digital values or grouped into digital
bins.
30

31. Functional Coverage Code Examples
covergroup cg_mode_control;
cp_mode_control: coverpoint {m_mode_control_if.monitor_mp.a2d_en,
m_mode_control_if.monitor_mp.d2a_en,
m_mode_control_if.monitor_mp.a2a_en,
m_mode_control_if.monitor_mp.d2d_en} {
bins powered_down = {4'b0000};
wildcard bins d2d_test_mode = {4'b??01};
wildcard bins a2a_test_mode = {4'b??1?};
bins dac_only = {4'b0100};
bins adc_only = {4'b1000};
bins dual_converters = {4'b1100};
}
endgroup : cg_mode_control
covergroup cg_analog_frequency;
cp_frequency: coverpoint frequency_cov {
bins frequency_1_to_lt_3_kHz = {1};
bins frequency_3_to_lt_5_kHz = {2};
bins frequency_5_to_lt_7_KHz = {3};
bins frequency_7_to_lt_9_KHz = {4};
bins frequency_9_to_lte_10_KHz = {5};
illegal_bins frequency_other = default;
}
endgroup : cg_analog_frequency
31

32. • A solution to the RNM-UVM problem has been presented.
• Work is still needed for the development of more driver
and monitor features to cover a wider range of analog
applications.
• The modeling of different Analog Instrumentation units will
allow for a complete characterization of mixed-signal parts.
When it comes to bridging the analog + UVM design verification gap, AMS, and digital
verification, think XtremeEDA. With over 65 engineers in North America, we are a leading
provider of expert front end design and verification engineering services.
Summary
32