C through UVM: Effectively using C based models with UVM

based Verification IP
Chris Spear, Kevork Dikramanjian,
Abhisek Verma Senay Haile
Synopsys Qualcomm
[email protected] [email protected]
[email protected],
[email protected]
 Develop the SystemVerilog Direct Programming Interface
(DPI-C) code to transfer data from C to SystemVerilog side of
1. INTRODUCTION testbench
Based on widely used and emerging protocols, standards-compliant
 Transfer data between the C and SystemVerilog parts of the
third-party Verification IP (VIP) is rapidly being adopted to
testbench with DPI-C
accelerate the development of a complete verification environment.
 Establish the connectivity between the C testbench, the UVM
Since the High definition Multimedia Interface (HDMI) supports a
based VIP (source) and the DUT (sink)
wide variety of audio and video formats, one of the major challenges
in verifying it is to create all kinds of stimulus responsible to  Configure the HDMI VIP to run tests
generate various types of frames. At Qualcomm we chose Synopsys
HDMI VIP as it was compliant with the HDMI-1.4b specification, The C testbench acts as a stimulus generator and creates the frame as
adheres to the latest verification methodologies such as Universal per the HDMI protocol. The frame data is passed to the UVM based
Verification Methodology (UVM) and was developed using VIP, which drives them on signal interface as per the protocol.
SystemVerilog. The flow below outlines how we established handshaking to
The challenge for this project was to integrate the legacy C synchronize the flow between the C test and the SV testbench:
models/testbench mainly used for HDMI stimulus generation with  The UVM VIP enters build phase, deliberately skips the
the HDMI VIP UVM code effectively. The HDMI VIP would then randomization of the configuration class and then enters the
hook onto the design under test (DUT). With careful planning and connect and run phases where it polls the test_done flag, set by
execution we were successfully connected these three pieces. This the C model.
ensured complete reuse of the C-based models and efficient usage of  The C model initializes and then calls test library functions to
the HDMI VIP. The DUT is a video capture and processing set high-level knobs. DPI-C functions are used to set fields
subsystem used as a front-end to various video interfaces, including which eventually go into SystemVerilog constraint blocks
HDMI. within the configuration class. Constraints include video, audio
The HDMI VIP uses UVM-compliant classes to represent protocol and packet mode and traffic profile.
activity and the characteristics of that activity. For example, a  The C model calls a SystemVerilog function which builds and
transaction object has members that define the audio and video randomizes the configuration class with the applied constraints
information being transmitted. A set of base classes provide common  The C model reads back low-level constraints which were
functionality and structure to form the foundation for the entire solved by HDMI VIP and then configures the DUT with same
HDMI VIP. constraints.
In a testbench, an HDMI VIP agent can be a source in active mode or  C model starts HDMI traffic sequence in the VIP. In the
as a sink with EDID enabled optionally. Stimulus is created as a SystemVerilog testbench or the UVM VIP, the sequence
UVM sequence with constrained random values for frame line values generates N transactions and sends it to driver and then to the
of R, G and B components during video active period. These values DUT
can be randomized either independently or could depend on certain
HDMI VIP configuration parameters. A test would run many Categories and Subject Descriptors
standard HDMI frames from source to sink of a certain format type. HDMI, UVM, Re-use philosophy
The HDMI VIP has a default functional coverage model
implemented as user extensions or callbacks to the HDMI monitor. It
has a rich set of covergroups on HDMI configuration and HDMI
General Terms
Verification, Design
frame line class for comprehensive functional coverage. Enhanced
debug and validation is provided by allowing the user to read in
audio video data, by-passing the built-in generation infrastructure. It
incorporates place-holders for hooking the DUT on one side and C Keywords
based model on the other thus enabling reuse of C based models for HDMI, VIP, UVM, CEA-861-D, VESA, DMT, HDCP.
stimulus generation. To increase throughput per test, the UVM
phasing mechanism is leveraged to revert to the post-configure 2. HDMI PROTOCOL OVERVIEW
phases to line up multiple tests in one simulation. The HDMI is the de-facto standard for digital connection for
consumer electronics and PC products. It delivers highest quality
This paper demonstrates how a UVM compliant VIP enabled us to audio/video signal over a single cable. HDMI system architecture is
create a highly configurable testbench. defined as consisting of Sources, Sinks, Repeaters, and Cable
The project was divided into the following milestones: Assemblies. A given device may have one or more HDMI inputs,
 Define the communication between the C testbench and the and one or more HDMI outputs. The HDMI cables and connectors
UVM based VIP carry four differential pairs that make up the TMDS data and clock
channels as shown in Figure-3. These channels are used to carry
video, audio and auxiliary data. Note that this paper doesn’t talk Transaction level Interfaces: UVM analysis ports broadcast the
about the Consumer Electronics Control (CEC) protocol associated required parameters to the coverage and scoreboard models.
with a typical HDMI device.
A HDMI source is responsible to send frames onto the Transition- Extension points: The VIP provides a rich set of UVM based
minimized differential signaling (TMDS) interface, while a HDMI callbacks across the different layers so we can add in project or test
sink receive them. The sink never responds back to the data from specific extensions.
source. As shown in Figure 3, an HDMI link includes three TMDS
data channels and a single TMDS clock channel. Each frame consists Data Exceptions: The extension points can also be used for changing
of a set of lines as per the HDMI specification. Each line is further the default stimulus and generate appropriate conditions for negative
segmented into video data audio data and control periods. The tests. A number of exception data classes are defined within the VIP
complete feature list can be referred from [2]. library for this purpose.

Factory Infrastructure: The VIP provides the user with the benefit of
overriding the default behavior of VIP components by providing user
specified extensions. This allows the user to meet the unpredictable
needs of different tests.

Event synchronization: Many UVM events are provided so users can

synchronize their testbench with transition of data or states within the
VIP. Most events are tied to the HDMI standard but there are a few
that are generic notifications from the data class.

Sequence Library: A rich set of sequences are available with the

HDMI VIP. These can be readily leveraged in tests by setting them
as the default_sequence of the HDMI source sequencer or by
explicitly starting them on the HDMI source sequencer. These
sequences help generate various types of HDMI compliant frames.
These are the building blocks for the user to stitch together a
Figure 1 :- HDMI source(Tx) and sink(Rx) block Diagram complicated scenario if required.

Since the HDMI protocol supports a wide variety of audio and video
formats, one of the major challenges is verifying all the different
frames across all the different configurations.

3. HDMI UVM VIP ARCHITECTURE

Figure-2 shows the architecture of Synopsys SVT (SystemVerilog
Technology) UVM based HDMI VIP.

Here are some of the features of the UVM VIP which are in our VIP
adoption guidelines.

Configuration: A protocol such as HDMI gives the flexibility of

working with different parameters. For example, the device can take
a varying number of frames to stabilize the video signal. Hence, to
address all such requirements, we would need to bring in the UVM
Resource mechanism to provide the configurability required. The
UVM VIP has a configuration class which is shared across all
components. This class is randomized in the build phase and then Figure 2 :- Synopsys HDMI VIP Block Diagram
propagated down to different individual component using the UVM
Resource mechanism [6]. This sharing allows individual components
to reconfigure themselves dynamically at different points in time. If a
user needs to change the configuration properties for specific tests, it 3.1 VIP usage and Configurability
would require setting constraints on a derived configuration class and The HDMI VIP can be configured to have either or both of the
overriding the configuration class in the environment using factories following two environments:
or through UVM configuration mechanism.
Source Environment - The Source Environment encapsulates the
Stimulus generation: To stay consistent with the architecture of the Source Agent and the CEC Agent (if CEC is enabled). It also
HDMI and Consumer Electronic Control (CEC) protocols, a layered contains the Source configuration object and a virtual sequencer to
approach has been adopted by the UVM VIP for stimulus generation. orchestrate the HDMI and CEC sequencers.
There are transaction classes for each of these layers (HDMI and
CEC). These are typical UVM data descriptors which will translate Sink Environment - The Sink Environment encapsulates the Sink
to protocol specified frames. Agent and the CEC agent (if CEC is enabled). It also contains the
Sink Configuration object and the CEC sequencer.
The HDMI VIP can be configured either as source or sink. This the same video frame(s) is passed to the HDMI Source VIP which
requires either of the Source/Sink Environment to be instantiated and transmits it to the DUT. The DUT processes the video stimuli(s)
hooked onto the TMDS interface. The Environment should be from the HDMI VIP and generates a memory dump which is then
configured with the corresponding configuration object descriptor. compared to the memory dump generated by the reference testbench.
Both Source and Sink configuration objects encapsulate audio and Since the reference testbench is used to validate the results from the
video configuration objects to support various types of audio and RTL testbench, the video configuration and the video stimuli needs
video attributes such as ASP audio or 24bit color video etc. The to be kept consistent between the C/C++ reference testbench and
complete list of attributes can be referred from [3]. Additionally, C/C++ RTL testbench.
these objects have parameters to control a host of features such as the
number of frames to be sent; enabling/disabling coverage, etc. 4.1 Test flow
These configuration objects are created in the UVM testbench. Their
attributes are then set or randomized then propagated to either the The HDMI is a SystemVerilog UVM-compliant VIP which contains
Source or Sink Environments using the UVM Resource mechanism the built-in standard phases for test flow. These include the
to configure the individual VIP components. The various modes of build_phase(uvm_phase phase), connect_phase(uvm_phase phase)
operation and the complete feature list can be referred from [3]. and run_phase(uvm_phase phase) phases which are invoked from
the UVM scheduler when the run_test() method is called in the
4. The Testbench testbench.
The structural testbench integration was done as shown in the figure The C/C++ testbench follows its own test flow that is independent
3 below. The components shown in purple color are Synopsys UVM from the UVM test flow. Since the C/C++ RTL testbench invokes
compliant VIPs. The components shown in orange are the the initialize/reset functions, DUT/VIP configuration functions and
Qualcomm legacy C testbench while the DUT is the light blue box. checking functions it was decided that the C/C++ RTL testbench
would dictate the test flow for the tests instead of the HDMI UVM-
compliant VIP. In order to allow the C/C++ RTL testbench to control
the test flow and to prevent the UVM test flows from colliding with
the C/C++ test flows, the HDMI VIP was effectively made a slave to
the C/C++ testbench. This was done by adding a semi-infinite loop
to the run_phase(uvm_phase phase) method of the uvm_test class
such that the HDMI VIP would never exit the loop until invoked by
the C/C++ RTL testbench. The HDMI VIP would only be active
when it accepts commands from C/C++ test library via DPI-C export
functions for the purpose of configuration and stimulus generation.
That way the HDMI VIP can gracefully go through all the UVM
phases at the end of the test as dictated by the UVM scheduler.

4.2 Configuration

The HDMI VIP contains a configuration class which has several

fields used to configure the type of video, audio and packet data it
can generate. The fields are fully constrained-random and are used in
several SystemVerilog constraint blocks that are included as part of
the HDMI VIP package. This contrasts with the more directed nature
of the C/C++ testbench, since C/C++ does not lend itself easily to
constrained-random testing.
A mechanism needed to be developed where the high-level video
mode could be controlled from the C/C++ test library and passed into
the HDMI VIP, effectively bypassing some of the constraint blocks
Figure 3 :- Synopsys HDMI VIP with Qualcomm C based for relevant configuration fields. Only the fields required for high-
testbench. level video mode would be set from C/C++, whereas other fields not
required by the reference testbench would be randomized within the
The DUT is a video capture and processing subsystem that is a front- HDMI VIP. The fields required to be controlled from the C/C++ test
end to various video interfaces, including HDMI. The DUT consists library includes video frame height, frame width, scan type, timing
of a set of DSP-intensive video processing blocks which process information (blanking/synchronization), pixel encoding type and
incoming analog/digital video streams and stores them into system color depth. These fields are passed in from C/C++ test library
memory. because they are used by the C/C++ reference testbench to configure
The video processing blocks within the subsystem are modeled using the SystemC reference models and generate the golden memory
SystemC reference models which are simulated within a C/C++ dumps.
reference testbench as shown by the orange components in Figure 3. DPI-C was chosen as the method of communication between C/C++
The SystemC reference models are used to generate reference test library and HDMI VIP, since SystemVerilog has built-in support
memory dumps from a given video frame(s). The C/C++ reference for DPI-C with little overhead. Configuration information that is
testbench is a pure software testbench which simulates only the determined from the C/C++ test library is passed into the HDMI VIP
SystemC reference models and generates reference memory dump via DPI-C export functions as shown in Figure ?. They get passed
files used for comparison. into the configuration class and ultimately end up as inputs to custom
In the other configuration (blue components in Figure 3) the C/C++ constraint blocks of the configuration class. Once all the
RTL testbench instantiates the HDMI Source VIP and the DUT, and configuration is passed in, the C/C++ test library invokes the
randomize() method of the configuration class via DPI-C to solve the
applied constraints.
Configuration fields in the HDMI VIP which are not constrained
from C/C++ test library are randomized and returned to the C/C++
test library for DUT configuration, such as audio-related
configuration and control-related information. This way the C/C++
RTL testbench can take full advantage of the randomization features
of SystemVerilog while maintaining control over basic configuration
required for the C/C++ reference testbench.

Abhisek, insert code here:

-

4.3 Stimulus Generation

Because the C/C++ reference testbench was used to generate golden
memory dumps for comparison, identical video frame stimuli were
applied to both the SystemC reference models and the DUT. Though
the HDMI VIP has the capability of generating random video frames,
it was required that the video frame stimuli needed to be generated
from C/C++ test library and sent to the HDMI VIP via DPI-C
functions/tasks. A DPI-C export task and a DPI-C import function
were used for passing video horizontal frame lines from C/C++ test
library to HDMI VIP. The DPI-C export task
sv_hdmi_send_frame_line() is invoked from C/C++ test library, and
within the task a DPI-C import task c_hdmi_get_frame_line_pixels()
is invoked from HDMI VIP to retrieve the frame line from C/C++
test library and pack it to the HDMI VIP sequence item for
transmission.
By allowing the HDMI VIP to retrieve video frames from the C/C++
test library, the same video frame stimuli can be applied to both
testbenches for producing golden memory dumps.

Figure 5 :- The SV side

4.2 HDMI VIP and Reconfiguration

The correct configuration for the VIP was known sometime during
the run_phase. On the other hand, the source model needed the
correct configuration to start the model during build_phase. This
called for a reconfiguration of the HDMI VIP during run phase as
shown in Figure [6]. This enables the integration of the HDMI VIP
into non-UVM testbenches. Of course some of the configuration
attributes are static and cannot be changed during run_phase but
most of them being dynamic enabled a robust reconfiguration.

Figure 6 :- reconfiguring the model

The new configuration was randomized to ensure all the

configuration parameters obey the reasonable and valid constraints as
Figure 4 :- The C Side part of the VIP. These constraints ensure that the protocol
specification is not violated. For example, in Digital Visual Interface
Figure 4 and 5 show the code snippet used for interaction between
(DVI) mode the VIP ensures there are no data island packets by
the C stimulus generation and SystemVerilog HDMI VIP.
constraining the attribute no_of_di_pkt of the frame line class to
zero. The user-constraints added for this testbench ensured that some
of the configuration values which came from C-side got applied to
the system configuration of the HDMI VIP.

4.3 Audio data Scoreboard

Unlike video data, audio data was entirely generated and checked
within the context of the HDMI Source VIP. An external audio
scoreboard was used for audio data checking. A callback function
within the UVM based HDMI Source monitor was used to extract
reference audio samples and queue them up in the scoreboard for
future comparison. There was little reliance of the C side since audio
data passes through the DUT relatively untouched. A monitor was
used in the audio output interface of the DUT for protocol checking,
and upon reception of an audio packet the monitor sends the packet
to the scoreboard for comparison.

Figure 8 :- Hooking of the Protocol Analyser with the

HDMI VIP
5.1 HDCP Authentication
The HDCP (High-bandwidth Digital Content Protection)
authentication for the source model can be enabled by using a
configuration attribute. The authentication in terms of reading and
writing registers happen on the DDC (digital down-converter) or the
i2c bus connected to the sink. Once the authentication is successful,
Figure 7 :- Audio scoreboard callback in source monitor the encrypted frames appear on the TMDS interface. As per protocol
we also needed to apply a default pull-up on the sda and the sclk
lines.
4.4 Video data Scoreboard EVENT_HDCP_AU_DONE event is triggered by the source driver
The video data scoreboard relies on the C reference testbench for once the authentication is done. The default keys for the cipher
reference video frames. The C/C++ reference testbench contains process have been taken from the appendix A of the HDCP 1.4 spec
SystemC models which emulate the video processing functions [7].The user had the flexibility to use his own defined set of Key
found in the DUT. Once a SystemC simulation completes the Selection Vectors (KSV), Key set and AN through a callback task
memory output file is used to validate the C RTL simulation results. [pre_hdcp_keyset] in the source driver and the monitor. There is a
In this way the video data scoreboard acts as a post-process checker minimum requirement for a frame to have at least 508 pixels (which
for video data. is equal to `SVT_HDMI_HDCP_KEEP_OUT_START) when run
with HDCP enabled. This will lead to errors from the model if not
4.5 Control data Scoreboard met.
Similar to audio data, control/Info-frame data was entirely generated There is an array in source configuration "hdcp_seq", which the
and checked within the context of the HDMI Source VIP. Since the Source used to read/write from/to registers. Check the reasonable
packet data remains untouched within the DUT, packet data constraint shown in figure 9 below –
scoreboard and callback functions were used to extract reference
control packet data from the HDMI stream for comparison with DUT
output packet data.

5. Feature Verification
Hooking up of the Protocol Analyzer helped a lot in debugging
purposes as shown in Figure [8]. It provided a GUI based view of the
transaction and its synchronization with the waveforms helped a lot
in debugging at the transaction level.
 from the C-Side and set either to VESA or CEA as shown in
Figure[11] below.

Figure 11: Configuration of SV model from C

5.3 Enabling faster simulation

The HDMI VIP provides for a mechanism to reduce the number of
video active lines (denoted as vactive) in a given HDMI frame
leading to faster simulation. The number of pixels in each vactive
line (denoted by hactive) can also be reduced to further shorten the
frame size and increase simulation speed.

For example, according to the CEA-861D specification, the total

Figure 9:- HDCP Authentication sequence by using number of lines to construct a frame in 2D format with video id code
SystemVerilog constraints. (VIC) 1 is 525, out of which 480 lines are vactive lines. Each vactive
line contains 640 active pixels (or hactive). Hence the frame is of
It was a set of reads and writes to various registers in the sink thru size 640x480. The same frame when shortened to 16x12 improves
the ddc interface. This was the first authentication process, once this simulation performance drastically, while still keeping the control
goes thru without any errors, the source will start sending encrypted lines same as the CEA-861E spec.
frames on the HDMI tmds interface from the subsequent frames.
The above read and write to the registers was observed on the DUT It was achieved by using the UVM factory override of the HDMI
interface as shown in Figure 10 below. database object which contains the information as available in Table
2 and 3 of CEA-861E spec. The HDMI database object of the VIP
provides set_format_field and get_video_id APIs to be overridden by
the user to supply the attributes such as vactive/hactive of a frame
As shown in figure [12] below.

Figure 10: HDCP sequence as viewed on the DUT ddc

interface

5.2 VESA DMT frame generation in DVI mode

The HDMI source model was configured to generate the VESA
DMT format frames during DVI mode apart from the HDMI CEA
frames. The configuration to switch the mode from HDMI to DVI
came from the C-side via an API. This was then used to constrain the
op_mode attribute of the source configuration to DVI_MODE and
switch off the reasonable_op_mode constraint which sets the
op_mode to be in HDMI_MODE by default. The video_standard
attribute of the current frame video configuration was also obtained
 Figure 14: Frame parameters

Figure 12: set_format_fields and get_video_id APIs to

enable faster simulation
6. Results and Conclusion
This challenging project was a good example of how to integrate a
legacy testbench with new technology. By integrating our
The extended HDMI database class can be then used to override the
C/SystemC testbench with the HDMI VIP which was developed
blueprint of the HDMI database with the model by using the UVM
using UVM/SV we have reused our testbench code and have
factory override function as shown in Figure [12] below.
benefitted from using state of the art verification IP which complies
with the HDMI standards, compared to developing the VIP
ourselves. The simulation performance is measured as a tradeoff
between the relaxed System Verilog constraint solver efforts and
overhead for DPI-C calls.

Thus, with minimal user involvement, we were able to create and

control the desired testcases and thus concentrate on converging in
completing the verification tasks efficiently. Though the UVM based
HDMI VIP was used to demonstrate this flow, the various
approaches techniques and guidelines can be well leveraged with
Figure 13: Overidding the HDMI database thru test class other VIPs and methodologies across various constrained random
verification environments to increase the verification productivity.
5.4 Non-standard frame generation
The concept discussed in Section 5.3 was extended to generate non- 7. REFERENCES
standard HDMI frames. The typical parameters present in the HDMI [1] Accellera, Universal Verification Methodology (UVM) 1.1 User’s
database object that define a frame are shown in Figure [14]. The Guide, 2011
values in the figure is for VIC=1 extended resolution format. . The [2] HDMI-1.4 Specification
set_format_field and get_video_id APIs of the HDMI database were [3] Synopsys HDMI UVM VIP User Guide
overridden to generate a frame of user choice i.e the frame [4] CEA-861-D Specification
parameters were redefined using the set_format_field API as shown [5] UVM Reference Guide
in Figure[12] and subsequently the get_video_id API needs to map [6] Mark Glasser, Mohamed Elmalaki, Advanced Testbench
the new values of the frame parameters to the video id code. Configuration with Resources, DVCon 2011
[7] HDCP 1.4 Specification
[8] VESA DMT version 1 revision 12