Verification of a CAN bus model in SystemC with

functional coverage
Gilles B. Defo, Christoph Kuznik, Wolfgang Müller
University of Paderborn/C-LAB
Faculty of Electrical Engineering
Computer Science and Mathematics
33102 Paderborn, Germany
{defo, kuznik, wolfgang}@c-lab.de

Abstract—Many heterogeneous embedded systems, for exam- respect to the user-defined metrics. The task to verify the
ple industrial automation and automotive applications, require actual simulation behavior of the DUT functionality with the
hard-real time constraints to be exhaustively verified - which expected one still has to be accomplished by implementing a
is a challenging task for the verification engineer. To cope
with complexity, verification techniques working on different testbench. So, functional coverage can tell if a property was
abstraction levels are best practice. SystemC is a versatile executed at the right time, in the right order and context.
C++ based design and verification language, offering various In the ideal case of a close coupling of a testbench and
mechanisms and constructs required for embedded systems functional coverage analysis, the information can even be
modeling. Using the add-on SystemC Verification Library (SCV) processed at runtime to steer the constrained random stimuli
elemental constrained-random stimuli techniques may be used
for verification. However, SCV has several drawbacks such as generation. While the IEEE 1800 SystemVerilog [2] standard
lack of functional coverage. In this paper we present a functional and other Hardware Verification Languages (HVL) such as e
coverage library that implements parts of the IEEE 1800-2005 incorporate functional coverage language features, these are
SystemVerilog standard and allows capturing functional coverage neither available in the IEEE 1666 SystemC standard [3]
throughout the design and verification process with SystemC. nor in any publicly available SystemC library. To overcome
Moreover, we will demonstrate the usability of the approach with
a case study working on a CAN bus model written in SystemC. this, we developed a SystemC functional coverage library and
testbench and applied it to a SystemC model of a Controller
I. I NTRODUCTION Area Network (CAN) based on the standard described in [4].
In several domains like industry automation and automo- In this article, we first introduce our SystemC implementa-
tive systems, the verification of hard real-time constraints tion of the IEEE 1800-2005 SystemVerilog coverage language
and verification of functional and non-functional properties features in Section II. The fundamentals of the CAN Controller
for integrated system behaviors is essential. For example, bus model are introduced in Section III. Section IV outlines
machine-aided assembly lines, where process steps of auto- the testbench architecture and components of the implemented
matic units and human workers intertwine with each other Controller Area Network (CAN) case study. Thereafter, sce-
require a safe and deterministic behavior for the team play. narios of the verification environment are discussed in detail
In automotive applications multiple field busses running in in Section V. Section VI compares our approach with existing
parallel, exchanging messages with each other need to be standards and related work in the area of functional coverage
verified to guarantee safety-critical behavior. Verifying these within SystemC before we close with a conclusion in Section
systems is a time consuming and tedious task. To cope with VII.
always more complexity and to boost productivity, more effi-
cient verification techniques and technologies were introduced II. S YSTEM C C OVERAGE L IBRARY
through the last years like the notion of functional verification
[1] which supports features such as verification of assertions, The SystemC functional coverage (SCFC) library partly
constrained-based random test pattern generation, and func- implements the covergroup concept of the IEEE 1800-
tional coverage. This article, focuses on the implementation 2005 SystemVerilog standard [2] via a singleton Factory class
of a functional coverage library in SystemC and applies it on implemented in SystemC. In details, the library supports the
the verification of a CAN bus case study. definition of:
Functional coverage is a user defined metric to investigate • bins to collect hits for variable ranges of the coverpoint
to which extend the functionality of a given design under • default bins to capture all non-specified values
test (DUT) has been verified by simulation runs. As such, • ignore bins, i.e., values to ignore and disregard for
functional coverage keeps track of value assignments and coverage computation
changes of expressions and conditions within the code. Thus, • illegal bins, where a bin hit calls sc_stop()
it is not verified if the DUT is working properly rather than • transition bins to define value sequences and evaluation
just gives information of the quality of the test pattern with with help of user-defined sample function

978-1-4244-5841-7/10/$26.00 ©2010 IEEE 28 SIES 2010

 • cross bins to cover cross-products with binsof() and defining on what signal the sampling of the covergroup is
intersect() operators performed, for example, on a rising or falling edge of a
following the instantiation hierarchy as defined by the Sys- certain signal. This feature is necessary if the covergroup
temVerilog standard. The SCFC factory is the main facility shall automatically cover variable in dependence of a clock
of the library, providing all necessary setup and manage- signal. So far the library has support for automatically covering
ment API calls for the creation and administration of ev- signals of type sc_signal<int> or via an explicit API
ery element of the implemented covergroup concept. More- sample() function call. Once the covergroup is created,
over, the factory provides the administration of the cover- the actual coverage elements such as coverpoints, cross-
age database in order to store collected functional cover- coverpoints, bins, transition bins, illegal bins etc. can be
age information. The database has to fulfill two require- defined starting in line 9. The order of the definition is the
ments. It has (i) to capture already sampled coverage in- same as in the SystemVerilog standard and has to be respected.
formation prior to the next run and (ii) to save this data In the following, two more detailed examples of the SCFC
after the test, which is supported by a set of convenience library coverage features shall be illustrated. In Figure 2
API functions. The set_coverage_db_name(name) an example from the SystemVerilog specification is shown.
function defines where to store the collected data. By Here, the covergroup cg has one defined coverpoint v_a
load_coverage_db(name), this data may be loaded and with four associated bins definitions and a default bin. In
evaluated at later steps. To compute the functional coverage this example, the bins are not derived automatically (for every
of all covergroup types, the factory provides the method possible value) rather than they are defined to capture certain
get_coverage(). variable ranges. Additionally, the coverage computation only
considers the defined ranges. Bins a covers the range 0

K 92:563J
K to 63, and the single value 65. The notation bins b[]
K Q creates as many bins as values within the specified interval.
K  9I/ 9%E: J
KO
$K The same holds for bins c[]. bins others[] holds all
)K 
J9, 90R8R0KD9, JK non-specified values. These values are not considered during
+K Q
K  coverage computation.
.K 
 P B/@!9 
 J8S
T80R8R0KO
"K 

4K V


K V
K L"D4M9O

K  K

K 
R
9P!
JS
9T80RR0KO K 

XJ

KO
$K 
9
Fig. 1. Definition and instantiation of a covergroup in SystemC )K Q
+K PQL4D+M8+)VO
K (LMPQL
D
)4M8L
$.D
"
MVO
Figure 1 shows the abstract principles of the defini- .K LMPQ4484
84VO
tion and instantiation of a covergroup using our library. "K ,PQL
444D
4MVO

4K LMP
" O
A covergroup is created using a SystemC SC_MODULE

K V
macro which implicitly results in a C++ class defini-
K 

tion. The covergroup class is defined as a friend,
allowing access to variables of the surrounding class. Fig. 2. A SystemVerilog covergroup
In line 5, the constructor of the covergroup is defined.
The method new_SVCovergroup(SVRef scm, char*
name, const char* instname,/*...*/) creates a

K 92:563J
K
new covergroup type name and a associated first instance K Q
called instname. The actual instantiation is shown in line K  (D
$K  9I/ 9%E: J
KO
13. The instance cg_inst (with the parameter cg_inst) is )K
+K 
J9, 98*4"R KD9, JK
constructed via the constructor of SC_MODULE cg. This also K Q
leads to the creation of the covergroup type cg to which the .K  927I:5JKO
"K 9?? @O
instance is assigned.
4K ,9 JKO
The pointer scm is used both for the type and the in-

K

K 
 P B/@!9 
 J8\
\88 KO
stance and saves the hierarchical relation, pointing to the
K  B/@!9 J8\9\8ZJ @9KKO

$K  B/@!9 J8\\8
8$848+8+)8+)KO
first instance. scm is a reference of the SC_MODULE of
)K  B/@!9 J8\(\8/67:-G 8$8
8
)48
$.8
"
KO
the covergroup, whereas SVRef is a just macro for void*.
+K  B/@!9 J8\\8/67:-G 8+84484484
84
8
484KO
name identifies the name of the covergroup, instname the
K  B/@!9 J8\,\8
88
4448
4KO
name of the instance of the covergroup. Moreover, additional
.K  B/@,,9, J\\KO

"K V
parameters are possible and indicated by the ... charac- 4K VO
ters. The constructor allows the definition of a SC_METHOD
sample() method in line 7. This sensitivity method allows Fig. 3. SystemC implementation of the SV covergroup from Figure 2

978-1-4244-5841-7/10/$26.00 ©2010 IEEE 29 SIES 2010

 The corresponding SystemC implementation is shown in
K 
J9, 98 R8(,KD9, JK
K Q
Figure 3. AUTOBINS is the equivalent to the SystemVerilog K  927I:5JKO
[] notation and creates as many bins as present values in the $K 9??@O
defined range. The definition of a certain number of bins is )K ,9 JKO
done via the third parameter of new_SVBins(). The default +K
bin is defined in line 18. The add_default() method K 
 P B/@!9 
 J8\
\88KO
computes all non-covered values and adds them to the default .K  RP B/@!9 J8\\8@
KO
"K  R(P B/@!9 J8\(\8@
KO
bin. Bins which are created after this call will be ignored.
4K  B/@!9 J\(\KO
In Figure 4, an example for the original SystemVerilog no-

K  B/@,,9 99JKO

K  B/@,,9 99J(KO
tation for ignore and illegal bins is displayed. Ignore
K  R
9P B/@!9
9 
bins specify values or ranges which shall be ignored while J\
9\8(9J8$8)8)8
8KKO

$K  R9P B/@!9
9 
covering the expression, even if they are included in the J\9\8 B/@(9J(88(,8(,KKO
declaration of other bins. Illegal bins specify values on
)K V
which the simulation shall be halted. In this case, a user-
defined error message is shown. A cross-coverpoint allows Fig. 5. SystemC implementation of Figure 4
computing the cross product on all values of given coverpoints.
As this may result in a large data sets, it is useful to limit
the product on certain bins. Therefore, this example makes in transition bins.
just use of the two operators binsof and intersect. The III. C ONTROLLER A REA N ETWORK (CAN) MODEL
binsof operator refers to the bins of an existing coverpoint.
In our case study we use a CAN controller model imple-
By the intersect expression the possible candidates can
mented in SystemC. The architecture of the model is depicted
be limited using specific values or intervals.
in Figure 6. This architecture was motivated by the Stand-
alone CAN controller SJA1000 from Philips Semiconduc-

K LD4M8(O tors [5]. The implemented controller mainly consists of four
K modules: a Message Buffer module, an Interface Management
K 

J(,KXJ

KO
$K 8(
Logic module (IML ), a Bit Stream Processing (BSP ) module
)K Q and an Error Management Logic (EML ) module. Furthermore,
+K 
&
9P"JK

Q)8L
DMVO the CAN simulation model also contains a so-called bus
K 
 &9P"J(K

Q(,VO module (CAN Bus) used as an abstraction of the physical bus.
.K V
"K 

Host

Fig. 4. SystemVerilog ignore and illegal bins

CAN controller
The corresponding implementation of the illegal and
IML
ignore concept within the SCFC library is shown in Figure
5. To define a cross-coverpoint, a coverpoint has to be declared
first. Using the methods new_illegal_SVCrossBins Clock Message Buffer
EML
and new_ignore_SVCrossBins the respective bins are txb
created. Moreover, the cross product is limited using the
intersect operator and an expression consisting of boolean
operators !, &&, and ||, which are also supported by the
rxfifo

BSP
SystemC library. Transition bins are support in two ways. First,
ACF
it is possible to define a custom sample function whereas return
value true leads to a bin hit. Second, transition vectors are
assigned to a transition bin and are elaborated with a vector
matching class.
In summary, our SystemC functional coverage implementa-
tion allows the definition of coverpoints with bins, transition CAN bus

bins, illegal bins, ignore bins, default bins as well as cross-

coverpoints. As it is implemented as a library and based Fig. 6. CAN bus model
on the factory concept, the solution is highly flexible and
can be easily combined with existing SystemC designs to • Message buffer is used to store messages (CAN frames)
leverage functional coverage. Compared to SystemVerilog, coming from or going to the bus. In the current imple-
the current implementation does not support clocking block mentation, it consists of two simple buffers for incoming
signals, conditional guards to avoid sampling and wildcards and outgoing frames.

978-1-4244-5841-7/10/$26.00 ©2010 IEEE 30 SIES 2010

 • Interface Management Logic (IML) is a module that • Stimulus generator
transforms data and identifier received from the host into • Transfer function
CAN frames. Following, the built frame is stored into the • Driver
message buffer and is ready for transfer. • Design under test
• Bit Stream Processing (BSP) is responsible for the recep- • Coverage monitor
tion (de-serialization) and transmission (serialization) of • Logging and Acceptance evaluation
the CAN messages. It performs aspects of the CAN pro- The stimulus generator of the testbench is used for the
tocol like bitwise arbitration, (de-)stuffing, error detection input stimuli generation for the CAN controller (DUT). The
(bit errors, form errors and acknowledge errors). Further- transfer function module simulates the input and generates
more, the BSP performs acceptance filtering (ACF) and the expected output using a reference model of the CAN
CRC checking. controller. The driver (adaptation) component converts the data
• Error Management Logic (EML) is a module that im- received from the stimuli generator and drives it to the DUT.
plements fault confinements rules according the CAN Another important component of the testbench is the coverage
specification described in [4]. This module consists of monitor, as it collects various coverage information based on
several counters to keep track of reception and transmis- the output of the stimulus generator and the output of the DUT
sion errors. The counters are updated depending of the for later scoreboarding. Note, that the coverage monitor is part
kind of error that occurred (Bit Error, Stuff Error, Form of the testbench and autonomous for the functional coverage
Error, CRC Error, Acknowledgement Error). collection. The logging and acceptance module is needed for
• The CAN bus module is needed for simulation purposes, data logging and acceptance evaluation based on a scoreboard.
it is a SystemC channel, that was implemented to abstract
the physical bus. Transfer-
function
The implemented CAN controller is an abstract high level
CAN model. Therefore, not all the features of the specification Stimulatus-
Driver
Design Under
Logging and
Acceptance
generator Test
are supported. In the current implementation, there is no Evaluation

support of extended CAN frames. Only standard CAN frames

Coverage-
are used for network communication. Figure 7 compares a monitor

Fig. 8. testbench model

A. Stimulus generation
The stimulus generator creates specific or completely ran-
domized messages for the Design Under Test based on the
parameterization. It offers the possibility to generate both
standard and extended CAN frames along CAN Specification
2.0 (see [4]. The choice is made based on a value that indicates
with what percentage standard CAN frames will be generated
throughout the simulation process. 100% means that only
standard CAN frames shall be generated. This value can be
set by a specific function within the testbench. Furthermore,
Fig. 7. Structure of a CAN message
it is possible to set a fixed ID for the CAN message that is
generated. Here, the use of the stimulus generator is inspired
standard and an extended CAN message format. As it can be by the SystemC Verification Library (SCV). Its application
seen, the main difference lies in the size of the arbitration is as follows: After its instantiation it can be parameterized
and the control field. Furthermore, Bit Timing Logic (BTL) using appropriate function calls. New CAN frame objects
which is a module that handles bit timing in CAN systems are created by the function call next() and can be directly
is not implemented. Instead, the assumption is made that referenced in the generator. Furthermore, CAN frames which
all controllers in the network are triggered by the same do not need stuff bits can also be generated by using the
clock. Therefore, no synchronization is needed. For further next no stuff() function call. Stuff bits are special bits needed
information of the module Bit Timing Logic see [4]. Due to for synchronization purposes during data transmission on a
the absence of the BTL module, no overload frames are sent CAN bus. After five consecutive bits of the same value an
by the BSP. inverted bit has to be inserted. For the generation of Stuff-
bit-free CAN frames, the fields Arbitration, Control and Data
IV. CAN T ESTBENCH
are created without stuff bits. Thereafter, the CRC check is
The general architecture of the implemented CAN is given simulated to verify that no stuff bits are really expected. If
in Figure 8. It comprises six components: this is the case, the message is stored in the generator and

978-1-4244-5841-7/10/$26.00 ©2010 IEEE 31 SIES 2010

 received transfer function message:
can be used within test cases to investigate the behavior of
the system for this specific case. The generated CAN frames data --> 01011110
are then passed to the reference model for simulation purpose arbitration -- > 548(1000100100)
and, after treatment of data by the adaptation module (Driver),
generation_time -- > 0 s
to the actual model for data transmission.
start_time -- > -

B. Transfer function
Fig. 9. transfer function
The transfer function module receives all CAN frames
generated by the stimulus generator as input. These are then received controller message:
taken to compute the expected output of the DUT in order data -- > 01011110
to compare it with the actual output produced by the DUT
later within the LA (Logging and Acceptance evaluation) arbitration -- > 548(1000100100)
module. Another task of the transfer function is to compute generation_time -- > -
the transmission durations of the frames in clock ticks and
start_time --> 5
stores them in the scoreboard of the LA module. Hereby, the
length of the frame including the stuff bits that are inserted
during transmission and the arbitration on the CAN bus are Fig. 10. logging and acceptance evaluation
considered. The computation of the frame length is done by
the so-called StuffbitChecker.
The StuffBitChecker is part of the transfer function module. E. Logging and Acceptance evaluation
It automatically checks the number of stuff bits of each frame The LA module in the testbench is used for system analysis
generated by the stimulus generator and stores it with its and for logging of generated and received CAN frames.
position. For this, it iterates through the relevant fields of the These are the messages produced by the generator and the
frame (SOF, ARB, CTRL, DATA, CRC). Furthermore, CRC- received by the receiving controller within the DUT are
Check is simulated for the computation of Stuff bits present logged. The second task of the LA module is the comparison
in the CRC field. Afterward the results of the computation can and verification of the output provided by the Transfer function
be accessed by the LA Module or by the Coverage monitor. module with the actual output of the DUT. Figures 9 and
All frames present in the system are stored in a vector and 10 depict such a log-file generated by the LA module. As
processed according to their respective IDs. This guarantees shown in the figure, only the dynamic part (i.e., parts that
that only those messages compete as in the arbitration phase were automatically generated) of the messages are logged with
of the CAN network. some additional timing information.
Figure 9 shows the message produced by the stimulus
generator, and simulated by the transfer function. This file
C. Driver
contains the generation time, the calculated arrival time in
Since the message objects produced by the stimulus gener- clock ticks and the ID controller sending of this message.
ator are standard data types (int, char), and because of the Figure 10 shows the message after its transmission over the
fact that the CAN model uses sc_logic vectors to store the CAN bus. It contains the time stamp at which the controller
individual message elements, the driver module makes use of started the message transfer and the time stamp at which
a message converter to convert the generated values into CAN- the message was received. These log files can be used for
frames before driving them to the DUT. manual review of DUT behavior. Furthermore, the LA module
monitors the bus traffic in order to rebuild the transmitted
D. Coverage monitor CAN-frames. Hereby, the main focus is to test and verify the
behavior of the BSP module by investigating aspects such
The coverage monitor is used in the testbench model to as the recognition of stuff bits and correct behavior during
gather coverage information for message objects produced by the arbitration phase. These are stored in a map with the
the generator and for messages received from the DUT. For appropriate CAN frame along with the position of stuff bits
this, we define a functional coverage metric with help of our for each message. The stuff bits identified by the BSP module
functional coverage library and make use of it in several test are compared with those calculated by the transfer function
scenarios. The coverage metric monitors the desired values and taken into account during the acceptance evaluation. The
and performs a functional coverage analysis. An example is frames calculated by the transfer function and the frames
to cover the IDs of the generated CAN frames of the stimulus transmitted on the CAN bus are stored in a scoreboard and
generator. A termination condition can be set based on the can later be used to conduct the acceptance evaluation. In
information from the coverage analysis like for instance when order to check the reliability of the design under the conditions
a specific number of IDs within a certain interval have been provided by the test cases, it is possible to alter various metrics
generated. such as the percentage of error free message receptions or the

978-1-4244-5841-7/10/$26.00 ©2010 IEEE 32 SIES 2010

maximum latency. D. Messages Coverage 1
Scenario V-D is an extensive test case where a large set
V. S CENARIOS of controllers is applied. In fact, for every possible binary
For verification of the CAN bus model and usability study combination of the ID field (which is used for arbitration
of the SystemC coverage library, we have defined and im- in the CAN bus standard) a CAN controller is configured
plemented several test scenarios. First the relevant signal and instantiated. This leads to 2032 CAN Controllers each
valuations of the DUT have to be identified such as ID fields, sending messages with the same ID as their Controller ID.
CRC and Stuff Bits in order to cover the associated expressions Additionally, all controllers act as receivers once they sent
within the simulation. Moreover, with help of the functional their messages or in case of lost arbitration, accepting mes-
coverage library the DUT control path logic can be efficiently sages with arbitrary ID value. This scenario enables extensive
covered using transition bins. In the following subsection, we coverage collection with help of the SystemC coverage library.
first give a briefly overview about these scenarios and how we During the simulation, the received CAN messages ID are
made use of the functional coverage features of our developed sampled (covered), resulting in one bin for every occured
library. There, we also summarize Scenarios V-A to V-D, as message ID. With help of this collected data, the coverage
scenario V-E is a superset of all previously iterative developed of the input data can be calculated.
scenarios, applying most coverage library features. Figure 11 shows the constructor of the test class. The
SystemC functional coverage library is instantiated and a
A. Sender/Receiver Scenario database file for the collected coverage information is specified
via set_coverage_db_name(). For a proper working
This scenario verifies the CAN data packet transmission coverage, the factory is initialized via init_factory().
via the CAN bus from a single CAN controller to two CAN Additionally, the CAN bus itself, the transfer function compo-
controllers. The controller which intends to send data starts nent and the CAN messages generator are instantiated. These
to send a data packet with a certain CAN message ID onto initializing steps of the verification environment are based on
the CAN bus. Two other controllers are configured in a way SCV Library behaviors [6].
to accept this CAN message ID. In the test run, the IDs are
randomized and the SystemC functional coverage library is 5):!"+.255/
used to determine the coverage of the ID variable. Though this P
5:K.255/7.SS/
use case quite simple, it allows the efficient combination of P
random constrained stimuli and functional coverage analysis. 5)D:!.@/U
5,./U
The developer has easy access to information like how much @5
RRU
of the overall variable values have been assigned during the 5)D:!./U
test run. 5,./U
@5
RRU
FI5I>77./U
B. Bus Arbitration Scenario (G5@
5'5.S2555@
5'S/U
(G5>./U
In this scenario, three CAN controllers start to drive a '  F-5' .S' S<55 /U
' (G./U
CAN packet onto the CAN bus model at the same time. One
F-5.S2555S/U
controller sends the message for the receiving CAN controller, 5 F
(G
55 ./U
5 (G./U
the other two send data with different CAN IDs. So despite  (G5./U
there is not collision in this test, it verifies the wiring of the V
CAN bus model and the bus arbitration. Again, the SystemC
Fig. 11. Constructor of test scenario V-D
coverage library is used to cover the CAN ID and to emphasize
verification efforts to corner cases. Additionally, the control
flow logic of the controller is covered via transition bins. E. Messages Coverage 2
Figure 12 shows the constructor of Scenario five. First,
C. Priorities & Arbitration Scenario
relevant variables are defined and initialized. The variable
This scenario combines V-A and V-B to verify that messages message_counter is a counter variable and represents
with lower IDs, and a higher priority, win the bus arbitration. how many messages are present in the system. If a new
Here, at least two sender and receivers are created. In the message is generated it is incremented. Once a message is
fourth controller scenario, the first sender controller sends a received it is decremented. This indicates how many messages
CAN message to the other controllers. The second sender also have to be driven to the bus simultaneously in the arbitration
sends a message with a higher ID. So this model verifies the phase. Variable stuff_bit_count_sig is a sc_signal
bus arbitration in a multi-sender and receiver CAN network. from type int. It is used for the coverage computation and
The coverage library is again used to cover simulated IDs. represents the stuff bits in a generated CAN message. The
Illegal bins have been specified to capture disallowed variable boolean compute_coverage indicates if the coverage has
assignments as they should not occur during the simulation. to be computed within the specific clock cycle or not. It is

978-1-4244-5841-7/10/$26.00 ©2010 IEEE 33 SIES 2010

 5):!"+.255 / @./P
. 5@
/P
P I5@
 O
>F(G
5I5@
 5>.<
5:K.255 /7 .S S/ S 55@
 S/U
P .
>QF2"++/
..2"++//U NN,, 
>(G./U
 RRSKK:K7I5@
  TSU

5 F3U
 5@
FU
 5'5 5
-.(
/U V
 5@
FU .5 (G5>5
./FF /P
FI5I>77./U  5'5 5
-.5 (G
5 5'5 .//U
(G5@
5'5.S255 5@
5''S/U  5@
F U
5 (G5>5
-./U
(G5>./U V
5)D:!.
555-5
/U .F3UR55 UYY/P
5,./U 5OF..5O/.55>WX//U
@RR U .(G955@'5
.//P
(G955@'5
-./U
5)D:!./U 5WX(G
5
55' ./U
5,./U 
5 ((U
@RR U V
'  F-5' .S' S<55 /U V
' (G. /U .Q 5@
[[(G
5I5@
 5>.<
S 55@
 S/(G
5@
./GF$3/P

F-5.S255 5S/U  RRS SRR55./RRS- ('(@

5 F
(G
55 ./U SRR(G
5I5@
 5>.<
5 (G. /U S 55@
 S/(G
5@
./RRSTSU
(G5./U ./U
V
V V


Fig. 12. Constructor of test scenario V-E Fig. 14. sample() method of test scenario V-E

always set to true once the transfer function has determined on the stuff_bit_count_sig signal which is driven
the stuff bits of a generated CAN message. by the transfer function and contains the amount of stuff
Additionally, two SC_METHOD are defined which will be bits generated for the latest generated CAN message. The
executed every clock cycle. In order to generate meaningful transitions bin makes use of that value in order to check
traffic for the CAN bus model, one method is utilized to if they are covered. After these steps, the coverage library
generate and transmit new messages, as depicted in Figure is instantiated, configured by setting database filename, and
13. initialized.

Fig. 13. CAN message randomizer of test scenario V-E Fig. 15. Verification Environment (transition bins) in test scenario V-E

Here, the sample() method in Figure 14 can be subdi-

vided into four tasks: VI. R ELATED WORK
1) Start of the coverage analysis once the transfer function In the area of CAN bus testing, [7] validated a CAN IP
calculated the stuff bits of a new CAN message. and analyzed several aspects of verification methodologies to
2) Check if the transfer function calculated stuff bits of a validate designs in the context of automotive systems develop-
new CAN message. ment. However, the authors apply manual directed test pattern
3) Check if the CAN controller received a CAN message design and no constrained random stimuli generation and no
when delivering this message to the Logging and Ac- functional coverage in the sense of functional verification and
ceptance evaluation model. the SystemVerilog standard. Our studies have shown that for
4) Stop in case of sufficient coverage (stop criterion). the identification of corner cases, constrained random tech-
The verification environment is depicted in Figure 15. First, niques are much ahead of classical techniques. Moreover, it is
a covergroup for the stuff bit coverage is defined. For every not possible to define allowed sequences of variable transitions
stuff bit class a transition bin is declared. The coverpoint relies (e.g., via transition bins) or forbidden cases (e.g., via illegal

978-1-4244-5841-7/10/$26.00 ©2010 IEEE 34 SIES 2010

bins). In the area of verification libraries, the Open Verification bins, whereas forbidden cases may be modeled as illegal
Library (OVL) [8] is maintained by Accellera and provides bins. Though SystemC CAN model is implemented at RTL
checkers that may work as assertion, assumption or coverage level, test cases could be driven and managed by a high level
point checkers. The most recent versions support SystemVer- testbench.
ilog, Verilog and VHDL. Unfortunately, there is currently Future work, is the investigation of the impact of the Open
no support for SystemC. Additionally, except SystemVerilog Verification Methodology (OVM) to SystemC in combination
the supported languages are working on RTL level, impeding with adding coverage support for arbitrary data types such
verification on higher levels of abstraction on more abstract as events on transaction level. Additionally, a closer database
data types. In the area of functional coverage implementations coupling to, for example, Accellera UCIS could enhance
with SystemC, [9] introduces a functional coverage prototype. coverage results reuse and management.
Unfortunately, just a list of functions without any details is
ACKNOWLEDGEMENTS
available. In contrast, our library is open with all details
as open source. In [10] the authors introduce a verification This work was partly funded by the DFG Collaborative
framework based on the SystemC Verification Library (SCV) Research Centre 614 and by the German Ministry of Education
providing a coverage monitor library for functional coverage and Research (BMBF) through the BMBF projects SANITAS
modeling. The implemented basic coverage operators range (01M3088) and VERDE (01IS09012). We greatly appreciate
from logical OR, equal, non-equal, greater, etc. and the cooperation with the project partners.
are not as powerful as the IEEE 1800 SystemVerilog cover- R EFERENCES
age features. In [11] the authors propose a coverage-driven
[1] J. Bergeron, “Writing testbenches: Functional verification of HDL
verification methodology approach that uses the their own models.” Kluwer Academic Publishers, 2003.
bve_cover class. This class has also been referenced in [12] [2] “IEEE Standard for System Verilog-unified Hardware design, specifica-
and [13]. It is reported that the approach allows definition tion, and verification language,” IEEE STD 1800-2009, 2009.
[3] Open SystemC Initiative, “IEEE Standard SystemC language reference
of (illegal) buckets (similiar to bins) and cross-coverage. manual,” IEEE Std 1666-2005, 2006.
Unfortunately, the authors do not given more details. In [14] [4] Robert Bosch GmbH, “CAN Specification version 2.0”, 1991.
a coverage driven testing policy is proposed whereas Property [5] Philips Semiconductors, “SJA1000 stand-alone CAN controller,” Data
sheet, 2000.
Specification Language (PSL) expressions which are converted [6] SystemC Verification Library v1.0p2, Open SystemC Initiative, 2006.
to C++ are used to gather and inspect function coverage [Online]. Available: http://www.systemc.org/downloads/standards/
information. In [15] the author uses the callback facility of [7] J. S. Antonio Souza and P. Domingues, “Functional verification of a
CAN data layer implementation: a case study,” Brazil Semiconductor
the SystemC SCV library to achieve functional equivalent of Technology Center (BSTC), 2003.
SystemVerilog value and transition coverpoints. Unfortunately, [8] Accellera Organization Inc., Open verification library (OVL). (2009,
this approach does not include advanced features like cross May) [Online]. Available: http://www.accellera.org/activities/ovl/
[9] R. Siegmund, U. Hensel, A. Herrholz, and I. Volt. (2004) Functional
coverage, illegal bins or default declaration. coverage prototype for SystemC-based verification of chipset designs.
AMD Dresden Design Center.
VII. C ONCLUSION & O UTLOOK [10] S. Park and S.-I. Chae, “A C/C++-based functional verification frame-
work using the SystemC verification library,” Rapid System Prototyping,
In this article, we introduced a SystemC functional coverage IEEE International Workshop on, vol. 0, pp. 237–239, 2005.
library and testbench and applied it to a SystemC model of [11] K. R. G. da Silva, E. U. K. Melcher, G. Araujo, and V. A. Pimenta, “An
a Controller Area Network (CAN). The SystemC implemen- automatic testbench generation tool for a SystemC functional verification
methodology,” in SBCCI ’04: Proceedings of the 17th symposium on
tation of the coverage language features of IEEE 1800-2005 Integrated circuits and system design. New York, NY, USA: ACM,
SystemVerilog, such as covergroup, allows functional cov- 2004, pp. 66–70.
erage to be efficiently collected and evaluated within SystemC [12] G. S. Silveira, K. R. G. da Silva, and E. U. K. Melcher, “Functional
verification of an mpeg-4 decoder design using a random constrained
simulation runs. In advanced testbenches this coverage data movie generator,” in SBCCI ’07: Proceedings of the 20th annual
may be efficiently used to steer the stimuli generators or conference on Integrated circuits and systems design. New York, NY,
the constraint solvers of constrained random variables into USA: ACM, 2007, pp. 360–364.
[13] C. L. Rodrigues, K. R. G. da Silva, and H. N. Cunha, “Improving func-
the right direction, targeting closure of the coverage gap. tional verification of embedded systems using hierarchical composition
With our library, we could efficiently analyze the testbench and set theory,” in SAC ’09: Proceedings of the 2009 ACM symposium
for different configurations of CAN controllers. We defined on Applied Computing. New York, NY, USA: ACM, 2009, pp. 1632–
1636.
several test scenarios, each utilizing the different features of [14] Y. Lahbib, O. Missaoui, M. Hechkel, D. Lahbib, B. Mohamed-Yosri, and
the functional coverage library. With help of our coverage R. Tourki, “Verification flow optimization using an automatic coverage
collection uncovered corner cases of the CAN testbench and driven testing policy,” in Design and Test of Integrated Systems in
Nanoscale Technology, 2006. DTIS 2006. International Conference on,
the DUT could be identified which were not addressed by the sept. 2006, pp. 94 –99.
initial verification environment. By improving the testbench [15] K. Schwartz, “A Technique for Adding Functional Coverage to Sys-
we could successfully identify various design flaws and bugs temC,” in DVCON 2007. Willamette HDL, Inc., 2007.
of the CAN bus model. As such, the functional coverage
collection helped to emphasize verification effort into the
right directions during the development. For example, control
path logic can be efficiently covered using transition

978-1-4244-5841-7/10/$26.00 ©2010 IEEE 35 SIES 2010