Upload
others
View
21
Download
0
Embed Size (px)
Citation preview
IEEE Design & Test
1
Abstract—The automotive trend is to increase the electronics
systems inside vehicles. The complexity of such systems is rising
with the number of components involved on the one hand and on
the other hand on the tighter interaction between these
components, being analog, digital hardware or software. The
verification of Electronic Control Systems (ECU) becomes more
and more challenging. In this paper we show that the Universal
Verification Methodology (UVM), initially developed for digital
systems, which consists in clearly distinguishing between the test
scenario, described in an abstract way, the Device Under Test
(DUT) and the test environment that translates the test to the
DUT interface, can be extended to analog and mixed signal
systems. We introduce the UVM-SystemC-AMS library for
functional verification, implemented based on SystemC and its
AMS extension SystemC-AMS. This approach is used to verify
two ECUs from automotive industry. The first use case shows
how UVM can be used for the simulation-based verification of a
complex mixed-signal design. The second use case shows how
UVM can be used on a Hardware In the Loop (HIL) system to
verify/validate a FPGA prototype.
Index Terms— Coverage Driven Verification (CDV), Design
Under Test (DUT), Electronic Control Unit (ECU), Electronic
System Level (ESL), functional verification, Hardware In the
Loop (HIL), system simulation, SystemC, SystemC-AMS, Timed
Data Flow (TDF), Transaction Level Modeling (TLM), Universal
Verification Methodology (UVM), system verification, Virtual
Prototyping (VP).
I. INTRODUCTION
The complexity of electronic systems for the automotive
industry is increasing. Such systems are designed to exploit
Manuscript received 24 October 2014. “This work was supported in part
by the project Verification for Heterogeneous Reliable Design and Integration (VERDI) which is funded by the European Commission within the 7th
Framework Program (FP7/ICT 287562) ”.
M. Barnasconi is with NXP Semiconductor, Eindhoven, Netherland ([email protected]).
K. Einwich and T. Vörtler are with Fraunhofer IIS, Design Automation
Division, EAS, Dresden, Germany (karsten.einwich @eas.iis.fraunhofer.de). F. Pêcheux, M.-M. Louërat, J.-P. Chaput, Z. Wang are with the LIP6 lab,
SU-UPMC, CNRS, Paris, France ([email protected]).
P. Cuenot is with Continental Automotive France, Toulouse, France ([email protected])
I. Neuman is with Continental Teves AG & Co. oHG, Germany,
([email protected]) T. Nguyen is with Infineon Technology, Austria AG, Villach, Austria
R. Lucas and E. Vaumorin are with Magillem Design Services, Paris, France ([email protected])
tight interaction between the physical world, captured or
controlled through sensors and actuators, and the digital
hardware (HW) and software (SW) world. Electronic Control
Units (ECU) in cars are fully heterogeneous systems,
implementing analog power electronics and low-voltage
electronics, controlled by software running on an embedded
processor. To master the complexity of the ECU design, a
variety of Electronic System Level (ESL) design methods and
languages have arisen. For that purpose, the SystemC
language standard [1][2] has been extended with powerful
Analog and Mixed Signal (AMS) modeling capabilities [3],
addressing functional and architecture level.
Yet, as great effort was made towards efficient analog and
mixed system level design and modeling technologies
[4][5][6][7][8][9], the technologies needed for efficient and
effective system-level verification are left behind. Coverage-
driven verification (CDV) of digital IP has become more
mature since the introduction of the Universal Verification
Methodology (UVM) standard [10], implemented in
SystemVerilog [11]. The principle is to build structured test-
benches with reusable verification components. Following the
UVM approach, the tests are designed in a hierarchical and
modular way, using similar abstraction levels as the device
under test (DUT) itself. This includes abstraction methods
such as Transaction Level Modeling (TLM) for the test
sequences [12], combined with accurate, signal interface to the
DUT. We introduce verification technology implemented in
UVM-SystemC and AMS extensions, called here UVM-
SystemC-AMS, to enable the development of virtual
prototypes at TLM abstraction with a structured test bench
methodology compatible with UVM. The goal is to perform
extensive functional verification of the embedded application.
Yet, one application will often require a high computational
effort, which can take up to hours or days. When the DUT
model includes RTL level descriptions, the simulation-based
verification may become impractical. This is where the UVM
approach also helps to efficiently translate the test bench built
for functional verification based on simulation into real
hardware prototyping validation using laboratory
measurements. Using UVM-SystemC-AMS we were able to
establish a tight coupling between the virtual prototyping
simulation and the Hardware In the Loop (HIL) laboratory
validation leading to an increase in speed and bug detection.
Two use cases will show the applicability of UVM-
AMS System-Level Verification and Validation
using UVM in SystemC and SystemC-AMS:
Automotive Use Cases
M. Barnasconi, K. Einwich, T. Vörtler, F. Pêcheux, M.-M. Louërat, J.P. Chaput, Z. Wang, P. Cuenot,
I. Neumann, T. Nguyen, R. Lucas and E. Vaumorin
IEEE Design & Test
2
SystemC-AMS for industrial scale applications. The first use
case shows how UVM can be used for the simulation-based
functional verification of a complex SystemC-AMS design,
which uses Timed Data Flow (TDF) abstraction for its models
and interfaces. The second use case shows how UVM can be
used on a HIL system to verify/validate a FPGA prototype.
The paper is organized as follows. Section II describes the
related work in the areas of methodologies and verification
tools for AMS-ESL. Section III presents our approach in terms
of layered verification environment architecture based on
UVM, SystemC and SystemC-AMS. Section IV introduces the
UVM-SystemC-AMS library and its main features. Section V
describes the constrained randomization of real values as well
as the functional coverage API illustrated with a SPI-
controlled filter example. Section VI presents the creation of a
verification environment in UVM-SystemC-AMS for an
automotive verification use case. Section VII presents an
automotive validation use case. Section VIII concludes the
paper.
II. STATE OF THE ART AND CONTRIBUTION
The trend to start earlier with system verification in the
design cycle, in combination with the growing complexity of
the actual design implementation (and its virtual prototype
counterpart), emphasizes the need to apply a proven
verification methodology. Therefore there have been many
attempts in the past to create structured and reusable
verification environments in SystemC/C++ (Figure 1).
A. History of verification methodology developments
In [13], the Open Verification Methodology (OVM) formed
the basis for creating a SystemC-equivalent verification
environment. The System Verification Methodology [14] was
based on OVM-SystemC, donated by Cadence to the
community [15]. Mentor Graphics released a SystemC version
as part of their Advanced Verification Methodology (AVM)
[16]. Also Synopsys introduced as part of their Verification
Methodology Manual (VMM) a class library in SystemC
[17][18]. More recent studies address the need to support a
true multi-language verification environment in
SystemVerilog, SystemC and e [19].
Figure 1 : Evolution of Verification Methodologies
However, all these initiatives do not fully comply with the
methods defined in the UVM standard, primarily because they
are built on the former AVM, OVM, and VMM technologies.
The consolidation into a single UVM standard resulted in
major changes. As a consequence, the user has to deal with the
incompatibilities related to simulation semantics and language
constructs. Especially the move from OVM to UVM
significantly changed the way components deal with the
phasing mechanism and how the end-of-test is managed. To
avoid legacy concepts and constructs in modern test benches,
migration to UVM standard compatible implementations
should be encouraged.
Alternative solutions are proposed in [20][21][22] to
address the multi-language integration challenges found in
today’s verification environments, by defining a set of coding
guidelines centered around TLM communication. However,
the creation of reusable verification components and
integration in a test bench is much more than having an agreed
communication method; additional elements like test bench
configuration and reuse of test sequences do require a more
holistic view on UVM and its principles, and justifies making
these concepts available in other languages.
Therefore an up-to-date and UVM standard compliant
language definition and reference implementation is needed in
SystemC/C++, which not only gives the user community a
semantically and syntactically correct implementation of
UVM, but also the same user experience in terms of the UVM
“look & feel”. Especially the latter aspect would facilitate
UVM users to start using SystemC for system-level and
hardware/software co-verification, or make SystemC or
software experts more familiar with the powerful UVM
concepts to advance in the verification practice [23].
The recent C++ based extension for the analog mixed signal
(AMS) simulation in SystemC-AMS [3] has opened the
perspective for electronic mixed domain system simulation
and extension to the verification domain and test coverage. In
addition, there is a strong need to extend UVM with new
constructs to support the analog domain usable for the Model
of Computation (MoC) of SystemC-AMS, to support electrical
networks, signal-flow and data-flow representations.
Ultimately, this will benefit the entire design community,
where verification and AMS system-level design practices
come closer together. It will serve the universal objectives of
the UVM, addressing the need for having a common
verification platform, including hardware prototyping in which
C-based test sequences or verification components in UVM-
SystemC are reused in HIL simulation or Rapid Control
Prototyping (RCP) [24].
B. Coverage driven verification
UVM is a verification framework that allows the creation of
test benches based on a constrained random stimulus principle.
Instead of testing the DUT with directed test sequences,
random stimulus is applied, which is shaped by constraints so
that the randomly generated values are valid stimulus. As the
input stimulus is randomly generated, it is very important to
observe which data has been sent to the DUT, to make sure
that all design corners have been tested during a verification
regression run. Therefore, functional coverage can be used
IEEE Design & Test
3
which allows defining our own coverage goals.
However, the UVM standard and associated class library
implementation in SystemVerilog does not define the
constructs for randomization and functional coverage, because
these concepts are intrinsically part of the SystemVerilog
standard, defined in IEEE Std. 180 [11]. In a similar way,
UVM-SystemC-AMS will not introduce such constructs for
randomization and coverage, but will make use of dedicated
libraries for this purpose. Several good attempts have been
made to support constrained randomization for SystemC, such
as the SystemC Verification library (SCV) [25] and the
Constrained Random Verification Environment for SystemC
(CRAVE) [26]. Also different libraries that add functional
coverage to SystemC have been proposed in [12][27][28][29].
Furthermore, various commercial, proprietary or vendor-
specific solutions are available.
In the following sections we will present our contributions:
a methodology based on UVM and SystemC-AMS, called
UVM-SystemC-AMS allowing to verify mixed-signal designs
at different abstraction levels. We will illustrate how the test
descriptions are reusable also for the laboratory and prototype
validation. To support coverage driven verification for analog
signals, we will introduce an API for randomization, which
supports constraints randomization of continuous distribution
functions as well as an API for coverage of real values.
III. UVM PRINCIPLES FOR AMS SYSTEMS
The AMS system-level verification methodology is based
on three UVM basic principles that have been extended to
AMS systems since the first presentation of UVM-SystemC
library [23]. The first one consists of a clear separation
between tests, test bench and AMS DUT implementation. The
second one is the definition of abstract and reusable tests
scenarios. Creating a sequence of commands, which can drive
an analog signal pattern, forms a test scenario. The third one
concerns the test bench, or verification environment. It is the
translator between the abstract test scenario and the DUT.
A. Layered approach
UVM-SystemC-AMS follows a layered approach, inspired
by [17], where levels of abstraction are introduced to
distinguish the test scenario from the actual verification
environment on which sequences are executed. Figure 2
illustrates the 3-level top-down refinement of test sequence
stimuli as well as the bottom-up reconstruction of performance
indicators for verification. The virtual sequences are extracted
from a scenario database (the test) and propagated to the test
bench. The virtual sequencer controls all sequences at top-
level. The sequencers control the sequence of data transactions
and send them to drivers. The drivers translate the sequence of
data transaction to physical signals, for example Discrete
Event (DE) signals for the digital IPs and SystemC-AMS TDF
signals for AMS IPs and send them to DUT ports. The
monitors collect the output signal from the DUT and store
them. From a relevant set of output signals, the analysis utility
functions translate them to transactions. Figures of merit are
computed from these outputs signal transactions as well as the
associated collected input stimuli transactions. The scoreboard
compares the results for the DUT with the reference signals by
means of a reference model.
Figure 2: UVM based layering. Left side showing refinement
from transaction to DUT input signal. Right side showing
abstraction from DUT output signal to scoreboard performances.
B. UVM components
We take advantage of the already existing principles of
UVM used in the digital domain to clearly separate the
analog/mixed signal test, the test bench and the actual
implementation of the DUT exhibiting AMS behaviors.
Universal Verification Components (UVCs) are the primitive
building blocks to create the test bench or verification
environment. Figure 3 illustrates a typical example. At the top
level of the hierarchy, two UVCs (called here VIP1 and VIP2)
are connected to the virtual sequencer using TLM
communication (see Figure 2 and in Figure 3).
A UVC contains one or more agents. The corner stone of
UVC is the agent ( in Figure 3), which instantiates the
sequencer, the driver (Figure 2 and in Figure 3) and the
monitor (Figure 2 and in Figure 3). The agent receives
sequential request and converts them into low-level data at the
DUT interface. Agents may be active or passive. Active agents
drive signals to the DUT and thus instantiates a sequencer and
a driver. Passive agents do not drive DUT and thus do not
instantiate any sequencer or driver. Whether active or passive,
agents may instantiate monitors to collect results.
The sequences encapsulate sequence items, also called
transactions. The sequences are not part of the test
IEEE Design & Test
4
environment hierarchy. They are transient objects that are
mapped on one or more sequencers. The sequencer reacts to
the orders given by the driver by getting sequence item and
delivering it to the driver. The driver requests transactions
(sequence item) and translate them to one or more physical
signals.
Figure 3: UVM-SystemC-AMS test environment
All components can be configured using the UVM
configuration database.
Functional coverage can be collected by adding coverage
models at different levels of abstractions shown in green in
Figure 3. Coverage requesting signal values is collected in a
monitor ( in Figure 3). More abstract coverage estimation is
collected based on transactions, which a monitor provides
through an analysis port (Figure 2 and in Figure 3). The
subscribers ( in Figure 3) are supplied with such kind of
collected information. This allows functional coverage related
to the overall checking of the verification goals to be
performed by the scoreboard.
C. Reuse across verification and validation environment
UVM test environments in SystemC can be reused for
verification at different levels of abstractions as well as for
validation in the laboratory. UVM-SystemC-AMS test
environment can be used to test a design from a system level
description down to an RTL-description of the design, as
SystemC can be coupled with different simulators [30][31].
Furthermore, as the C++ language can be easily compiled to
different hardware platforms it is also possible to reuse UVM
test environments for laboratory based validation. SystemC
can run e.g. on Hardware in the Loop Simulator systems
[32][33], an example of possible reuse of a test environment is
shown in Figure 4.
Figure 4: Reuse of UVM-SystemC-AMS test environment for
different levels of abstraction
The application use case shown in Section VII demonstrates
the reuse possibilities of UVM for SystemC.
D. Test execution and verification features
In order to have a consistent test bench execution flow, the
UVM-SystemC-AMS library defines phases to order the major
steps that take place during simulation (Figure 5).
Figure 5: UVM-SystemC-AMS common and runtime phases
There are three groups of phases, which are executed in the
following order:
1. Pre-run phases (build_phase, connect_phase): The
build_phase is executed at the start of the UVM testbench
simulation and their overall purpose is to construct, configure
the test bench component hierarchy. During the build_phase
UVM components are indirectly constructed using the factory
pattern. The connect_phase is used to interconnect all the
components.
2. Runtime phase (run_phase): The test bench stimulus is
generated and executed during the runtime phases, which
follow the build phases. In run_phase and run-time phases,
we execute the test scenarios by performing the configuration
of the DUT and applying primary test stimulus to DUT. These
runtime phases are all spawned SystemC processes and can
consume time, unlike the other phases, which are untimed
function calls. All UVM components using the run-time
schedule are synchronized with respect to the pre-defined
phases in the schedule.
3. Post-run phases (extract_phase, check_phase,
report_phase and final_phase): where the results of the test
case are collected and reported. The 4 post-run phases are used
to post-process the results after the execution of the test
scenario of the DUT.
IEEE Design & Test
5
E. TDF and Discrete Event synchronization
Virtual sequences, sequences, and sampled signals represent
the actual data sent to or received from the DUT at different
time scales. To correctly synchronize the UVCs involved in
the test environment and the DUT, it is necessary to
synchronize the related SystemC and SystemC-AMS modules.
In Figure 6, an UVM-SystemC-AMS driver component
consisting of two modules is presented. The first component is
a SystemC TLM adaptor component. A process of this
component reads the timestamps of the transactions and writes
(schedules) the data of the transaction in the second delta
cycle, one resolution time step before the timestamp of the
transaction. This guarantees that the data will be read at the
correct time by the TDF module, since SystemC-AMS reads
event driven SystemC signals always at the first delta cycle of
the current time.
Figure 6: UVM-SystemC-AMS driver, from DE to TDF
This pipelined synchronization method is presented in
Figure 7.
Figure 7: Pipelined synchronization process for scoreboard
Between each sequence item, the sequencer/driver waits for
a period T0 (which can be variable). The monitoring thread
waits for the same period, so that the emission of stimuli and
the reconstruction of performance indicators are kept
synchronous during the simulation, for scoreboard
comparisons. Once a new sequence item has been propagated
to the driver (at the very beginning of the sequence item
period), the corresponding TDF driver module uses the
transaction description to generate the TDF stimuli for the
DUT. For instance, if the sequence item defines a new
operating frequency for the wave generator, the corresponding
TDF processing function reacts immediately (i.e. within a
TDF period indicated by the TDF cluster time step) and
generates the appropriate low-level samples. The sequence
item high-level information data remain valid during the
whole T0 period. At the very end of the T0 period, all the TDF
stimuli samples corresponding to a given sequence item have
been sent to the DUT, and all the monitored values coming
from the DUT have been aggregated in order to compute the
values of the performance indicators. When scheduled, the
thread associated to the monitor gains direct access to these
performance values, which will remain valid for the next T0
period.
IV. UVM-SYSTEMC-AMS LIBRARY IMPLEMENTATION
In this section we present the UVM-SystemC-AMS library
and describe the main features with code snippets, therefore
extending the UVM-SystemC library version of [23]. The
current implementation follows the UVM 1.1 standard.
A. The Agent
Listing 1 below shows the creation of an UVM component
with the user-defined name vip_agent in UVM-SystemC-
AMS. An agent encapsulates the components, which are
necessary to drive and monitor the (physical) signals to (or
from) the DUT. Typically, it contains three components: a
sequencer, a driver and a monitor. The agent can also contain
analysis functionality for basic coverage and checking, but this
is not shown in this simple example.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
class vip_agent : public uvm_agent {
public:
vip_sequencer<vip_trans>* sequencer;
vip_driver<vip_trans>* driver;
vip_monitor* monitor;
UVM_COMPONENT_UTILS(vip_agent)
vip_agent( uvm_name name )
: uvm_agent( name ), sequencer(0), driver(0), monitor(0) {}
virtual void build_phase( uvm_phase& phase ) {
uvm_agent::build_phase(phase);
if ( get_is_active() == UVM_ACTIVE ) {
sequencer = vip_sequencer<vip_trans>::type_id::create(
"sequencer", this);
assert(sequencer);
driver = vip_driver<vip_trans>::type_id::create(
"driver", this);
assert(driver);
}
monitor = vip_monitor::type_id::create("monitor", this);
assert(monitor);
}
virtual void connect_phase( uvm_phase& phase )
{
if ( get_is_active() == UVM_ACTIVE )
{
// connect sequencer to driver
driver->seq_item_port.connect(sequencer->seq_item_export);
}
}
};
Listing 1: UVM-SystemC-AMS agent
B. The sequences
The UVM sequence item is used as template argument for
the creation of the actual sequence, as shown in Listing 2. A
IEEE Design & Test
6
sequence is derived from template class uvm_sequence (Line
3). The macro UVM_OBJECT_PARAM_UTILS supports
the registration of template classes with multiple arguments,
which are derived from uvm_object (Line 11).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
template <typename REQ = uvm_sequence_item, typename RSP = REQ>
class sequence : public uvm_sequence<REQ,RSP>
{
public:
sequence( const std::string& name )
: uvm_sequence<REQ,RSP>( name ) {}
UVM_OBJECT_PARAM_UTILS(sequence<REQ,RSP>);
virtual void pre_body() {
if ( starting_phase != NULL )
starting_phase->raise_objection(this);
}
virtual void body() {
REQ* req,
RSP* rsp;
...
start_item(req);
// req->randomize(); //optional randomization call
finish_item(req);
get_response(rsp);
}
virtual void post_body() {
if ( starting_phase != NULL )
starting_phase->drop_objection(this);
}
};
Listing 2: UVM-SystemC-AMS sequence item
The callback function body is used to implement the user-
specific test scenario (Line 16). The member functions
start_item and finish_item are called to negotiate and then
send the sequence to the sequencer (Line 20 and 22). The
member function randomize, is defined as part of the
compatibility layer to the SCV or CRAVE library (Line 21,
see Section V). The member function body is automatically
called from the higher level in the test bench, for example by
explicitly calling the member function start in a virtual
sequence. Alternatively, a sequence can be started implicitly
by defining a default sequence in a test, along with specifying
the component and phase where it should be executed. The
latter approach is presented in section IV.D, Listing 4.
The callback functions pre_body and post_body (Line 11
and 26) are called before and after the callback body,
respectively, to raise and to drop an objection only when the
sequence has no parent sequence. For this purpose, the data
member starting_phase is used, offering a handle to the
default sequence (Line 13 and 28).
C. The test bench
The test bench is defined as the complete verification
environment which instantiates and configures verification
components (UVCs), scoreboard, and virtual sequencer if
necessary. The UVCs are sub-environments in the test bench,
which contain one or more agent. Listing 3 shows the
implementation of the test bench. It uses the base class
uvm_env (Line 1). The UVCs and scoreboard are instantiated
using the factory (Lines 15,17,21,24). This facilitates
component overriding from the test scenario. The
configuration database is used to configure each agent in the
UVC as being active or passive, by means of the global
function set_config_int (Lines 19 and 20).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
class testbench : public uvm_env
{
public:
vip_uvc* uvc1;
vip_uvc* uvc2;
virt_sequencer* virtual_sequencer;
scoreboard* scoreboard1;
UVM_COMPONENT_UTILS(testbench);
testbench( uvm_name name )
: uvm_env( name ), uvc1(0), uvc2(0),
virtual_sequencer(0), scoreboard1(0) {}
virtual void build_phase( uvm_phase& phase )
{
uvm_env::build_phase(phase);
uvc1 = vip_uvc::type_id::create("uvc1", this);
assert(uvc1);
uvc2 = vip_uvc::type_id::create("uvc2", this);
assert(uvc2);
set_config_int("uvc1.*", "is_active", UVM_ACTIVE);
set_config_int("uvc2.*", "is_active", UVM_PASSIVE);
virtual_sequencer = virt_sequencer::type_id::create(
"virtual_sequencer", this);
assert(virtual_sequencer);
scoreboard1 =
scoreboard::type_id::create("scoreboard1", this);
assert(scoreboard1);
}
virtual void connect_phase( uvm_phase& phase )
{
virtual_sequencer->vip_seqr = uvc1->agent->sequencer;
uvc1->agent->monitor->item_collected_port.connect(
scoreboard1->xmt_listener_imp);
uvc2->agent->monitor->item_collected_port.connect(
scoreboard1->rcv_listener_imp);
}
};
Listing 3: UVM-SystemC-AMS test bench
D. The test
Each UVM test is defined as a dedicated test class derived
from class uvm_test, as shown in Listing 4 (Line 1). It
instantiates the test bench (Line 11) and defines the default
sequence which will be executed on the virtual sequencer in
the run_phase (Lines 14-16).
The factory member function set_type_override_by_type
is used to override the original UVM driver in the agent by a
new driver (Listing 4, lines 18-20). The types of the original
and new driver are obtained by calling the static member
function get_type.
The result from the scoreboard checking is extracted in the
extract_phase and updates the local data member test_pass.
The actual pass/fail reporting is done in the callback
report_phase using the available UVM macros for reporting
information and errors.
1
2
3
class test : public uvm_test
{
public:
IEEE Design & Test
7
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
testbench* tb;
bool test_pass;
test( uvm_name name ) : uvm_test( name ),
tb(0), test_pass(true) {}
UVM_COMPONENT_UTILS(test);
virtual void build_phase( uvm_phase& phase )
{
uvm_test::build_phase(phase);
tb = testbench::type_id::create("tb", this);
assert(tb);
uvm_config_db<uvm_object_wrapper*>::set( this,
tb.uvc1.agent.sequencer.run_phase", "default_sequence",
vip_sequence<vip_trans>::type_id::get());
set_type_override_by_type(
vip_driver<vip_trans>::get_type() ,
new_driver<vip_trans>::get_type() );
}
virtual void run_phase( uvm_phase& phase )
{
UVM_INFO( get_name(),
"** UVM TEST STARTED **", UVM_NONE );
}
virtual void extract_phase( uvm_phase& phase )
{
if ( tb->scoreboard1.error )
test_pass = false;
}
virtual void report_phase( uvm_phase& phase )
{
if ( test_pass )
UVM_INFO( get_name(), "** UVM TEST PASSED **", UVM_NONE );
else
UVM_ERROR( get_name(), "** UVM TEST FAILED **" );
}
};
Listing 4: UVM-SystemC-AMS test definition
E. The top-level
The main program, also called top-level, uses the SystemC
sc_main function and contains the DUT, the interfaces
connected to the DUT, and the definition of the test, as shown
in Listing 5. The interfaces are stored in the configuration
database to be used by the UVC drivers and monitors to
connect to the DUT (Lines 6 - 9).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
int sc_main(int, char*[])
{
dut* my_dut = new dut("my_dut");
vip_if* vif_uvc1 = new vip_if;
vip_if* vif_uvc2 = new vip_if;
uvm_config_db<vip_if*>::set(0, "*.uvc1.*",
"vif", vif_uvc1);
uvm_config_db<vip_if*>::set(0, "*.uvc2.*",
"vif", vif_uvc2);
my_dut->in(vif_uvc1->sig_a);
my_dut->out(vif_uvc2->sig_a);
run_test("test");
return 0;
}
Listing 5: UVM-SystemC-AMS main program
The test to be executed is either defined by explicitly
instantiating the test object (of type uvm_test) or implicitly by
specifying the test as argument of the function run_test (Line
12). The latter method makes it possible to pass the test as
string via the command line, available via the arguments of the
function sc_main, and pass it to the run_test function.
The simulation is started using the SystemC function
sc_start. It is recommended not to specify the simulation stop
time, nor use the SystemC function sc_stop, as the end-of-test
is automatically managed by the UVM-SystemC-AMS
phasing mechanism, which is started when calling the
run_test function.
F. Using IP-XACT for design automation
IEEE1685 IP-XACT standard [34][35] enables an efficient
assembly and configuration of the structural layers of the test
environment (test bench, test and top level elements) by
generating the relevant SystemC and SystemC-AMS views
necessary to conduct verification. It provides also a unified
repository to exchange and share compatible components from
multiple companies or services.
In order to capture the UVM properties, we have introduced
vendor extensions in the schema of the IP-XACT standard.
These extensions concern especially:
- The identification of the different UVM objects (test, test-
bench, UVC, agent, scoreboard, monitor, driver and
sequencer)
- The interconnection of the DUT to the UVCs with the help
of virtual interfaces
- The configuration of the platform using the UVM
configuration database and agents of configuration.
The assembly described in IP-XACT, reproduces the same
architecture of the UVM test environment and then offers the
same level of reusability. At the end, the generator will
provide the SystemC and SystemC-AMS code (header and
cpp files) of the different layers: top, test and test-bench but
also the header of the virtual sequencer containing references
to the sequencers instantiated in the different UVCs. The
generation is based on templates, one per output file, to
introduce some flexibility. The textual part (header,
comments, library) is dumped without any modification and
key words are replaced by meta-data elaborated in an internal
model from the IP-XACT description. Figure 8 llustrates an
example of a generator. The left column shows the template
used. The right column shows the generated code.
Figure 8: Template and generated code of top level
with IP-XACT
IEEE Design & Test
8
V. CONSTRAINED RANDOMIZATION AND COVERAGE
To cope with the complexity of ESL, random
sequences/stimuli are used to increase the coverage of the
DUT. As several attempts exist to extend the power of
SystemC to digital verification such as SCV [25] or CRAVE
[26], we have proposed an API for randomization and
coverage as a compatibility layer, which can either use SCV or
CRAVE as a back end solver. This API is implemented in
C++ as library extension for UVM-SystemC-AMS (scvx).
To correctly handle the analog signals found in AMS
systems, new functions have been introduced to generate
random real values, following continuous distribution
functions, which are subject to constraints. More over the
functional coverage API provides the functions covergroup,
coverpoint and bins offered by SystemVerilog, which are
extended to handle real values using intervals (Table I).
Functionality UVM-SystemC-AMS (scvx)
Coverage model scvx_covergroup
Coverage point scvx_coverpoint
Coverage state bins bins()
Illegal bins illegal_bins()
Ignore bins ignore_bins()
Triggers sampling the covergroup sample()
Table I: Basic Language constructs for functional coverage in
UVM-SystemC-AMS (scvx)
In addition to the discretized weighted values, a set of
continuous distribution has been made available. The
randomization features and distribution functions of C++11
[37][38] have been used to build the API as shown in Table II.
Distribution function UVM-SystemC-AMS (scvx)
Normal distribution scvx_normal_distribution
Uniform distribution scvx_uniform_distribution
Bernouilli distribution scvx_bernouilli_distribution
Piece-wise linear
probability distribution
function
scvx_piecewise_linear_probability_distribution
Discretized probability
distribution function
scvx_discrete_probability_distribution
Table II: Continuous Distribution Fucntion available for real
values in UVM-SystemC-AMS (scvx)
Figure 9 shows the histogram of the normal distribution
with real values. To estimate the coverage, the range of each
random variable is divided into intervals. The number of
draws (tries which have fulfilled the constraints) is computed
in each interval. The functional coverage is based on these
figures.
The random variable a is declare in Listing 6. As an
example, the member function set_distibution defines the
distribution uniform_real, requiring the parameters min (15.3)
and max (40.2) for random variable a.
scvx::scvx_rand<real> a; a.set_distribution(scvx_distribution::uniform_real(15.3, 40.2));
Listing 6: Setting a distribution function for a random variable
Figure 9: Histogram of a Normal distribution featuring real
values
To illustrate the randomization for real values with
constraints, a simple case is presented in Figure 10. The DUT
is a SPI-controlled programmable filter. In order to verify the
DUT with UVM-SystemC-AMS, 4 UVCs have been
instantiated in the test environment: a sinusoidal signal
generator (U1), an input monitor U2, a power supply generator
(U3) and a SPI driver to generate SPI compliant commands
(U4).
Figure 10: Test of a programmable filter with the proposed
UVM-SystemC-AMS library
Connection between UVCs and the DUT follow the
interface configuration mechanism provided by UVM-
SystemC-AMS. The scoreboard is responsible for comparing
the expected performance of the filter (here the gain) with the
actual one.
Figure 11 presents a simulation result of the SPI controlled
programmable filter. Note that the first 4 signals at the top of
Figure 11 use a dedicated timescale, showing the setting of the
SPI commands. The next curves use another timescale,
dedicated to illustrate the randomization of real values.
0
10
20
30
40
50
60
70
80
0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40
Fre
qu
en
cy
x
IEEE Design & Test
9
The input stimulus of the programmable filter is a
sinusoidal signal with randomized frequency. Each frequency
corresponds to a certain sequence item. At the end of each
sequence item, the gain of the filter is computed from a set of
collected input and output signals and the result (green crosses
in Figure 11) is sent to the scoreboard.
Figure 11: Simulation result, showing SPI commands, power
supply, input/output of the DUT and performance indicator
(gain). The input signal is a sinusoidal one with randomized
frequency. The performance indicator is the gain of the filter.
The green crosses show the DUT gain after each sequence item.
The red curve shows the reference value computed in the
scoreboard.
To estimate the coverage of the test, the frequency range
has been divided into 12 intervals and a minimum number of
frequencies is required in each interval. At the beginning of
the test execution, the coverage is low, as shown in Listing 7
whereas at the end of the test, the coverage has increased,
though below 100% in our example to illustrate the coverage
report.
Wavefunc item sequence finished here... freq = 31278.9 frequence [100000] ± 10% is not covered! frequence [90000] ± 10% is not covered! frequence [70000] ± 10% is not covered! frequence [50000] ± 10% is not covered! frequence [40000] ± 10% is not covered! frequence [25000] ± 10% is not covered! frequence [19000] ± 10% is not covered! frequence [14000] ± 10% is not covered! frequence [10000] ± 10% is not covered! frequence [7000] ± 10% is not covered! frequence coverage is 16.6667% received gain = 1.51867 383645113 ps: test.tb.scoreboard: Successfully match the expected gain value ( 1.51867 ) ± 5%
Wavefunc item sequence finished here... freq = 34988.7 frequence [25000] ± 10% is not covered! frequence [10000] ± 10% is not covered! frequence [7000] ± 10% is not covered! frequence coverage is 75% 9621905335 ps: test.tb.scoreboard: Successfully match the expected gain value ( 1.50686 ) ± 5%
Listing 7: Output of functional coverage respectively at the
beginning of the test execution and at the end.
VI. VERIFICATION USE CASE
In order to evaluate the applicability of the methodology
and technology to the verification of complex heterogeneous
automotive system, it has been applied to an electronic
braking system design. The DUT consists of the electrical and
the mechanical components of a brake actuator, an
analog/mixed signal ASIC for brake actuator control and
Figure 12: Automotive system under test and test bench
IEEE Design & Test
10
external circuitry.
A major step in system architecture design is to define the
components of the system and to define the requirements for
these components. To verify that the component requirement
specifications will enable the complete system to work as
intended, i.e. to meet the system requirements, we have
developed an executable specification. The executable
specification uses an abstract behavioral simulation model
allowing a significantly higher simulation performance than
RTL and transistor-level representations.
The digital components of the system under test are
modeled in SystemC. The analog components and the
mechanical components are modeled in SystemC-AMS, either
as TDF data flow models or as electrical linear network
models depending on the accuracy required.
The test environment is implemented using the UVM-
SystemC-AMS methodology and technology. The system is
stimulated by driver modules and supervised by dedicated
monitors. Besides digital agents for SPI interfaces and bit
vector interfaces, the test bench contains analog interface
agents for creating piecewise linear (PWL) waveforms and
creating arbitrary analog waveforms.
The test stimuli are defined by sequences and sequence
items, which are sent to the drivers via TLM connections.
In addition to mechanisms for normal control operations,
safety critical systems typically contain various mechanisms
for detecting and handling system errors. Some examples are
the detection of electrical shorts, broken wires, over
voltage/under voltage scenarios and mechanical blocking.
An important step in the verification of such systems is to
verify that these mechanisms operate as intended. In order to
enable tests simulating the corresponding failure scenarios, the
test bench implements several drivers for injecting failures
into the system.
Figure 12 shows the overall system and test bench including
error injection for emulating a short.
The availability of a well-structured library of verification
components based on a standardized methodology simplified
the creation of tests and test benches, thereby reducing time
and cost for test development.
Furthermore, the UVM methodology enabled the
construction of fully automated regression test suites.
The tests have been written in a way enabling to reuse them
for the validation of RTL design when it becomes available by
coupling the HDL simulator simulating the system and a
SystemC simulator simulating the test bench.
VII. VALIDATION USE CASE
The methodology was also applied on an airbag SoC, as an
example for an AMS product, with high complexity and full
integration. It shows how UVM can be used for a hardware in
the loop (HIL) system to verify a FPGA prototype.
For an effective HIL simulation a tight coupling between
the verification of the virtual prototype and laboratory
validation of the DUT with the HIL had to be established, as
depicted in the workflow in Figure 13. Thereby the reuse of
the test environment, with its test and check sequences are
critical to allow an early move of the implementation onto the
prototype to accelerate and aid verification and validation.
Figure 13: Verification and laboratory evaluation overview
The DUT evolves from a behavioral SystemC-AMS
description to a mixed abstraction model. It is then
synthesized towards an FPGA prototype and results in the first
hardware setup [39].
While the DUT evolves, the test environment should remain
as similar as possible to guarantee functional correct testing
throughout the development process. This consistency also
ensures that a minimal effort is spend on test environment
creation. Figure 14 illustrates the implemented software and
hardware layers of the verification and laboratory validation
architecture and emphasizes the reuse.
Figure 14: Software and Hardware implementation
As depicted in Figure 14, the test environment is based on
UVM-SystemC-AMS represented by the three upper most
layers. The high abstraction test description provides test
vectors to the specific UVM agent via the virtual sequencer,
which in turn provides specific driver and monitor
IEEE Design & Test
11
components (not shown) to connect the test environment to the
corresponding DUT implementation. During the verification,
the monitor and drivers are functional implementations,
connecting and wrapping the modeled DUT via interfaces to
the UVM-SystemC-AMS test environment. The connection in
case of validation has to connect through the specific HW of
the HIL-Tester.
The HIL-Tester can directly build and run the native UVM-
SystemC-AMS based test environment. It was implemented
using an ARM based Zynq-SoC [40], build on a Zedboard
[41], running a real-time Linux scheduling the test
environment.
Figure 15 demonstrates the laboratory setup of the airbag
SoC DUT FPGA prototype. To realize the HIL-Tester
concept, the main micro-controller is replaced by the
Zedboard with the Xilinx Zynq based ARM-SoC, on which
the UVM-SystemC-AMS test bench is reused to emulate the
physical stimulus to drive the DUT FPGA-prototype.
Figure 15: Real laboratory setup for the evaluation of the new
verification/laboratory evaluation strategy
With this implementation, it was possible to shorten and
focus the effort of a root-cause analysis in the virtual
prototype through the reuse of the test sequences obtained
from the HIL simulation within the computer based
verification. As the test sequences are reused, including the
test vectors, a direct mapping between the verification and
validation activities becomes possible.
Including the HIL in the verification process increased the
speed of verification and the bug detection possibilities at an
early point in time, thus reducing development costs.
The UVM-SystemC-AMS test bench can be directly reused
and it can additionally be extended for long-term tests and
stress tests, which are impractical to do with classical
computer-based system simulation frameworks.
With the new setup, the whole prototype system is checked
at real-time speed against real sensor network used later in the
application instead of sensor model simulation.
VIII. CONCLUSION
We have explained how a unified methodology for the
verification of systems having interwoven AMS/RF, HW/SW
and non-electrical sub-systems and functions can be achieved.
As of today, there only exist verification methodologies
addressing either AMS/RF or digital HW/SW functions. The
clear separation of the DUT and its verification description,
which has been established in the last years for complex
digital systems, has been extended to analogue mixed signal
ones. Thus the essential unification of analogue and digital
verification is made possible. We have shown that the
components and the scenarios designed for the simulation-
based verification can be reused during the validation of the
actual hardware prototype measurements.
To support the new methodology inspired by UVM, we
have introduced new language constructs and generic
verification components in SystemC and its AMS extensions
to create application scenarios consisting of stimuli generation
and response checking. We have called this library UVM-
SystemC-AMS. The generic verification components with
their reuse features have been illustrated by two industrial use
cases: the first use one showing UVM-SystemC-AMS based
verification of a complex SystemC-AMS design, the second
one showing the verification/validation with HIL using a
FPGA prototype. Moreover, by extending the IP-XACT
schema, we introduced new design automation and reuse
capabilities such as the packaging of verification components
and generation of the verification infrastructure, facilitating its
exploitation in industrial design flows
The implemented UVM-SystemC-AMS library introduced
in this paper is under Standardization within the Accellera
Systems Initiative.
REFERENCES
[1] T. Wieman, B. Bhattarchary, T. Jeremiassen, C. Schröder, and B.
Vanthournout, “An Overview of SystemC Initiative Standards Development”; IEEE Design & Test of Compuers, 14-22, 2012,
doi:10.1109/MDT.2012.21845518.
[2] IEEE Standards Association, “SystemC”, 2011, http://standards.ieee.org/getieee/1666/download/1666-2011.pdf
[3] Accellera Systems Initiative, “SystemC AMS 2.0 extensions”,
2013, http://www.accellera.org/downloads/standards/systemc/ [4] E. Viaud, F. Pêcheux, and A. Greiner. “An efficient TLM/T
modeling and simulation environment based on conservative
parallel discrete event principles”, Design, Automation & Test in Europe Conference (DATE), 2006, 94-99.
[5] Wolfgang Ecker, Volkan Esen, Robert Schwencker, Thomas
Steininger, Michael Velten, TLM+ modeling of embedded HW/SW systems, Design, Automation & Test in Europe
Conference (DATE), March 2010.
[6] F. Cenni, S. Scotti, E. Simeu, "SystemC AMS behavioral modeling of a CMOS video sensor," International Conference on VLSI and
System-on-Chip (VLSI-SoC), Oct. 2011, pp.380-385,
doi: 10.1109/VLSISoC.2011.6081614 [7] Y. Zaidi, C. Grimm, J. Haase, "Simulation based tuning of system
specification," Design, Automation & Test in Europe Conference
(DATE), 2011, March 2011, doi: 10.1109/DATE.2011.5763204 [8] A. Lévêque, F. Pêcheux, M-M. Louërat, H. Anoushady, F. Cenni,
S. Scotti, A. Massouri, L. Clavier, “Holistic Modeling of
Embedded Systems with Multi-Discipline Feedback: Application to a Precollision Mitigation Braking System”, Design, Automation
& Test in Europe Conference (DATE), March 2012, 739-744.
[9] W. Li, D. Zhou, M/ Li, B.P. Nguyen, X. Zeng, “Near-Filed Communication Transceiver System Modeling and Analysis using
SytemC/SystemC-AMS with the Consideration of Noise Issues,
IEEE Trans. VLSI Systems, Vol. 21, N° 12, Dec. 2013, 2250-61 [10] Accellera Systems Initiative, “Universal verification Methodology
standard (UVM)”, 2014,
http://www.accellera.org/downloads/standards/uvm/
IEEE Design & Test
12
[11] IEEE Standards Association, “System Verilog”, 2012,
http://standards.ieee.org/getieee/1800/download/1800-2012.pdf
[12] M. F.S. Oliveira, C. Kuznik, H. M. Le, D. Groe, F. Haedicke, W.
Mueller, R. Drechsler, W. Ecker, and V. Esen., “The system
verification methodology for advanced TLM verification”. Int. Conference on Hardware/software codesign and system
synthesis,(CODES+ISSS), 2012, 313-322.
doi=10.1145/2380445.2380497 [13] A. Koczor, and W. Sakowski, “SystemC library supporting OVM
compliant verification methodology”, IP Embedded System
Conference and Exhibition (IP-SPOC), December 2011 [14] M. F. S. Oliveira, C. Kuznik, W. Mueller, W. Ecker and V. Esen,
“A SystemC Library for Advanced TLM Verification”, Design and
Verification Conference & Exhibition (DVCON), February 2012. [15] “Cadence Extends the Open Verification Methodology Beyond
System Verilog to Include SystemC and e Language Support”,
http://community.cadence.com/cadence_blogs_8/b/fv/archive/2009/02/27/ovm-multi-language-libraries-a-closer-look.
[16] Mentor Graphics, “Advanced Verification Methodology
Cookbook”, 2012,
http://www.mentor.com/products/fv/methodologies/uvm-
ovm/cb_details
[17] Synopsys, “Verification Manual for System Verilog”, http://vmm-sv.org
[18] A. Sarkar, “Verification in the trenches : A SystemC
implementation of VMM1.2”, 2010, https://www.vmmcentral.org/vmartialarts/2010/12/verification-in-
the-trenches-a-systemc-implementation-of-vmm1-2/ [19] IEEE Standards Association “1647-2011 - IEEE Standard for the
Functional Verification Language e”, August 2011, doi:
10.1109/IEEESTD.2011.6006495 [20] J. Aynsley, SystemVerilog Meets C++: Re-use of Existing C/C++
Models Just Got Easier, Design and Verification Conference &
Exhibition (DVCON), February 2010. [21] Mentor Graphics, “UVM Connect - a SystemC TLM interface for
UVM/OVM - v2.2, http://forums.accellera.org/files/file/92-uvm-
connect-a-systemc-tlm-interface-for-uvmovm-v22, accessed October 2014.
[22] A. Jafri, N. Naser,” Interoperable testbenches using VMM TLM”,
Synopsys User Group, April 2010. [23] M. Barnasconi, F. Pêcheux, T. Vörtler, “Advancing system-level
verification using UVM in SystemC“, Design and Verification
Conference & Exhibition (DVCON), March 2014 [24] K. Einwich, T. Vörtler, T. Arndt, “New technological opportunities
coming along with SystemC / SystemC AMS for AMS IP
Handling and Simulation”, European Nanoelectronics Design Technology Conference (DTC), June 2012
[25] Accellera Systems Initiative, “SystemC Verification Library”
http://www.accellera.org/downloads/standards/systemc/scv-2.0.0.tgz
[26] F. Haedicke, H. M. Le, D. Große, R. Drechsler, “CRAVE: An
Advanced Constrained Random Verification Environment for SystemC”, Int. Symposium on System on Chip (SoC), Oct. 2012.
[27] R. Siegmund, U. Hensel, A. Herrholz, and I. Volt, “A functional
coverage prototype for SystemC-based verification of chipset
designs”, ESCUG Meeting, Design Automation and Test in Europe
Conference (DATE), February 2004.
[28] K. Schwartz, “A technique for adding functional coverage to SystemC”, Design and Verification Conference & Exhibition
(DVCON) Feb. 2007.
[29] C. Kuznik and W. Müller, “Functional coverage-driven verification with SystemC on multiple level of abstraction”,
Design and Verification Conference & Exhibition (DVCON),
March 2011. [30] A. Hoffman, T. Kogel, and H. Meyr. “A framework for fast
hardware-software co-simulation.” Design, automation and test in
Europe Conference (DATE), 2001.. [31] M. Bombana and F. Bruschi, “SystemC-VHDL co-simulation and
synthesis in the HW domain”, Design, Automation & Test in
Europe Conference (DATE), March 2003, 101-105, doi: 10.1109/DATE.2003.1186679
[32] J.A. Ledin, “Hardware-in-the-Loop Simulation”, . Embedded
Systems Programming, February 1999, 42-60.
[33] T.A. Johansen, T.I. Fossen, B. Vik, “Hardware-in-the-loop Testing
of DP systems”, Dynamic Positioning Conference, Nov 2005.
[34] Accellera Systems Initiative, “IP-XACT standard”, 2009,
http://www.accellera.org/downloads/standards/ip-xact [35] IEEE Standards Association, “IP-XACT”, 2014,
http://standards.ieee.org/getieee/1685/download/1685-2014.pdf
[36] T. Vörtler, T. Klotz, K. Einwich, Y. Li, Z. Wang, M.-M. Louërat, J.-P. Chaput, F. Pêcheux, R. Iskander and M. Barnasconi,
“Enriching UVM in SystemC with AMS extensions for
randomization ad functional coverage”, Design & Verification Conference & Exhibition (DVCON Europe), October 2014
[37] The C++ Standards Committee, 2011 “C++11”, http://www.open-
std.org/jtc1/sc22/wg21/ [38] W. E. Brown, Random Number Generation in C++11, Document
WG21 N3551, 2013
[39] T. Nguyen and S. Wooters, " Mixed-abstraction Modeling Approach with Fault Injection for Hardware-Firmware Co-design
and Functional Co-verification of an Automotive Airbag System
on Chip Product," SAE Int. J. Passeng. Cars – Electron. Electr. Syst. 7(1):125-132, 2014, doi:10.4271/2014-01-0240.
[40] Xilinx – Zynq-7000 All Programmable SOC,
http://www.xilinx.com/products/silicon-devices/soc/zynq-7000/,
accessed Oct. 2014
[41] Zedboard – Product page, http://zedboard.org/product/zedboard,
accessed October 2014