Chapter 13

UVM-Based CAN IP Verification

Jian Han, Ping Fu and Jiaqing Qiao

Abstract In this paper, a verification testbench-based UVM is established for a CAN

IP. To adapt to some features of the CAN IP and improve the efficiency of the veri-
fication, appropriate strategies and methods are implemented, such as the constraint
random stimulus, register model with indirect indexed registers, the coverage-driven
strategy, and a reference model for automatic comparison. It’s proved that UVM-
based verification testbench can make the process of verification clearer and more
efficient. During the verification, we find some problems of the CAN IP. After solving
them, we take regression test and all these problems are solved. Finally, we collect
the function coverage and code coverage as the evaluation of the verification, and
two of them could prove that the CAN IP could be used for FPGA firmware design.

Keywords UVM verification · CAN IP · Constraint random stimulus ·

Coverage-driven strategy · Regression test · FPGA firmware design

13.1 Introduction

Controller Area Network (CAN) is widely used in automobile, marine, railway, mine
exploration, and many other fields because of its advantages of resisting disturbance,
stability, and reliability [1]. As an essential component of the CAN, the CAN protocol
controller could be achieved by ASIC or FPGA. For the flexibility and integration
of the digital system, FPGA has been a commonly used component in our lab’s
research. FPGA supports users to define their own IP. We download a CAN protocol
controller IP from the OpenCores and make it a CAN component in FPGA firmware
design. However, the correction and stability of the IP are not guaranteed, for some

J. Han · P. Fu · J. Qiao (B)

Harbin Institute of Technology, Automatic Test and Control Institute, Harbin Heilongjiang, China
e-mail: [email protected]
J. Han
e-mail: [email protected]
P. Fu
e-mail: [email protected]
© Springer Nature Singapore Pte Ltd. 2020 117
J.-S. Pan et al. (eds.), Advances in Intelligent Information Hiding and Multimedia
Signal Processing, Smart Innovation, Systems and Technologies 156,
https://doi.org/10.1007/978-981-13-9714-1_13
118 J. Han et al.

bugs remaining in the design. To solve this problem, we decide to establish testbench
for CAN IP’s verification. With the complexity of CAN IP, traditional manual verifi-
cation methods have the characteristics of hard to achieve the expected coverage and
low verification efficiency, and hence Universal Verification Methodology (UVM)
is taken.
UVM is based on SystemVerilog classes and is powerful Object-Oriented Pro-
gramming (OOP) [2]. Not only open source but also supported by mainstream EDA
manufacturers, UVM has become a best-known verification method [3]. The newest
version of UVM is UVM 1.2, which was released in June 2014, and it includes some
bug fixes and some improvements [4]. In this paper, we build a UVM-based verifica-
tion testbench for CAN IP core, appropriate strategies and methods are implemented,
such as the constraint random stimulus, the register with indirect indexed registers,
the coverage-driven strategy, and a reference model for automatic comparison.
This paper has been organized into different sections. Section 13.2 shows the
analysis of the CAN IP, which gives a verification plan. Section 13.3 introduces
structure of the UVM-based testbench and some special details for adapting to the
features of the CAN IP. Section 13.4 shows results analysis. Conclusions are given
in Sect. 13.5.

13.2 CAN IP

13.2.1 CAN IP

CAN is a kind of widely used field bus in industrial automation, ships, medical
equipment, industrial equipment, and others. It has characteristics of safety, priority
of messages, low delays, arbitration, flexibility, and error operations.
In this paper, the design of the CAN IP is similar to stand-alone CAN con-
troller SJA1000, and it can be downloaded from OpenCores [5]. The specification
of SJA1000 could be a reference as design document for verification.

13.2.2 Verification Plan

For a complete and efficient verification, a detailed verification plan is essential.

The verification plan includes features of the CAN IP, architecture of the verifica-
tion testbench and goals of the verification. Part of features of CAN IP is given in
Table 13.1.
Details of the verification testbench are shown in Sect. 13.3.
13 UVM-Based CAN IP Verification 119

Table 13.1 Part of features of CAN IP

Features Details
Two modes BasicCAN, PeliCAN
Two host interfaces 8051, wishbone (not used)
CAN interface Tx_o, rx_i
Communication rate Up to 1 Mbit/Sec
Transmitting data Normal frames transmitting
Errors operation during frame transmitting
Arbitration during frame transmitting
Receiving data Normal frames receiving
Errors operation during frame receiving
Acceptance code register and acceptance mask register
Status during sending and receiving CAN IP will have different states in the process of work:
error activation, error recognition, and bus shutdown.
These three states need to be achieved in the process of
verification and can realize the transformation of these
three states

13.3 Testbench Description

13.3.1 UVM-Based Testbench’s Architecture

The architecture of the UVM-based testbench is shown in Fig. 13.1.

Can_test: As the top level of the testbench, it is connected to CAN IP through
interface. In can_test, hierarchical components are constructed.

Fig. 13.1 The architecture of UVM-based testbench of CAN IP

120 J. Han et al.

IML: This is a special module to form multiple CAN nodes into one network
to simulate communication, arbitration, and error operation among different CAN
nodes.
Interface: For connections between CAN IP and verification testbench.
Reg_env: Reg_env is a component for register layer’s operation, and with this
method, the portability of the sequence will be fine when some registers were
changed.
In_agent and out_agent: These two components are defined to contain the input-
related and output-related components such as monitor, driver, and sequencer.
Reference model: As a component to receive stimulus and simulate the behavior
of the CAN IP, it generates expected output for automatic comparison.
Scoreboard: Scoreboard is a component to compare the actual output with
expected output, and tells the reference model whether the coverage should be col-
lected.
Function coverage: It is for coverage collecting, collecting data from monitor and
reference model be valid when the test passed.

13.3.2 Strategies and Methods of the Verification

Constraint Random Stimulus. Directed stimulus is not suitable when the design is
most complex that needs lots of sequences. Constraint random stimulus could solve
the problem. So, in this paper, we decide to use the constraint random stimulus and
use the coverage-driven strategy to evaluate the process of the verification.
In UVM, different verification components communicate with each other through
the transaction. The transaction is a class defined to conclude all valid information
that can represent a message in CAN.
There are three main parts in the can_transaction class (shown in Fig. 13.2.): data
values, field_automation, and constraints.
Data values conclude the information of the CAN such as data field, arbitration
field or type, and formats of a frame. Some values of these are included in CAN’s
frame structure, and some values are indicator for constraints or field_automation.
Field_automation is easy for packed data operation. Data registered by the macros
uvm_field_* can be packed together, and copy, compare, print, and other func-
tions could be used directly.

Fig. 13.2 Three main parts

of can_transaction class
13 UVM-Based CAN IP Verification 121

Constraints are defined to constrain the random transaction’s generation, such as

when format of the frame is different, the structure is also different. In this way, we
can use only one transaction class and constraints to generate every transaction.
Register Model with Indirect Indexed Registers. To apply to the feature that some
registers’ address may be different if the value of the special register is different, the
indirect indexed register of UVM is appropriate.
For further details, an example of indirect indexed register could be found in the
Universal Verification Methodology (UVM) 1.2 User’s Guide [6].
Coverage-Driven Strategy. Only constraint random stimulus and automatic com-
parison cannot evaluate the process of the verification. Coverage-driven strategy is
taken for this.
Coverage comparison between function coverage and code coverage is shown in
Fig. 13.3. Only when the functional coverage and code coverage are both high, the
verification is adequate. In this paper, our coverage goal is that functional coverage
reaches 100% and code coverage reaches almost 95%.
Reference Model for Automatic Comparation. To check the CAN IP’s actual
behavior’s correction, there should be a reference model to generate the expected
transaction to be compared. For this, a reference model is designed to collect the
stimulus from the bus monitor or through registers’ value and then generate the
expected transaction to the scoreboard to be compared with the actual transaction
collected from the output’s monitor.
For transaction to be compared in scoreboard, there are mainly three processes:
1. Update the mirror values in register model.
2. Collect transactions from in_agent and generate expected output for tx_o.
3. Collect transactions from out_agent, decide whether the transaction is of trans-
mitting or receiving, and take operations.

Fig. 13.3 Coverage

comparison
122 J. Han et al.

13.4 The Results of Verification and Analysis

We use the ModelSim as the simulator of the verification, which supports UVM and
has comprehensive function.
During the process of the verification, some problems of the design are found
which are given below:
1. Arbitration inconsistency: CAN IP does not stop sending data immediately after
the failure of arbitration, and will send one more bit, which may lead to the failure
of sending by the node that has already received arbitration, thus the two nodes
that may participate in arbitration have been in error frames, stop sending data.
2. Unset interrupt bits: There may be a case when setting the sending interrupt
register while accessing the sending interrupt register, the bit for sending data
in the interrupt cannot be set. This problem has already been reported in the
bugtracker page of the OpenCores website.
3. Cannot recover from bus shutdown: When the bus shutdown occurs, if the idle
count of bus recovery is set manually, the controller logic cannot recover from
bus shutdown.
4. Receiving buffer overflow processing: In the processing of receiving buffer over-
flow, the CAN controller logic implements the following processing: marking
the frame as an overflow frame, discarding the frame if it is an overflow frame
at the time of reading.
We solved the problems and the regression test is correct.
To evaluate the verification, code coverage and function coverage are combined to
make sure all function points concluded in the verification are covered and whether
the design is fully verified.
For function coverage, the result is shown in Fig. 13.4. These coverages are
collected based on constraint random stimulus and coverage-driven strategy. Some

Fig. 13.4 Function coverage after constraint random stimulus

13 UVM-Based CAN IP Verification 123

Fig. 13.5 Code coverage some modules reported by the simulator

function points not covered are shown clearly. We also add some indirect sequences
to cover these function points and the function coverage reaches 100%.
Some modules’ code coverage is shown in Fig. 13.5.

13.5 Conclusion

In this paper, a UVM-based verification testbench is established for the CAN IP’s
verification. During the process of verification, we take constraint random stimulus,
register model layer, coverage-driven strategy, and make up a reference model for
automatic comparison. The process of verification is clear and efficient.
Finally, we find some problems of the CAN IP, which are shown in Sect. 13.4.
Regression test are token after we solved these problems. Function coverage and
code coverage are also given.

References

1. Desai, M., Shetty, R., Padte, V., Parulekar, M., Ramrajkar, S.: Controller area network for
intelligent vehicular systems. In: International Conference on Advances in Technology and
Engineering (ICATE) (2013)
124 J. Han et al.

2. Zhong, G., Zhou, J., Xia, B.: Parameter and UVM, making a layered testbench powerful. In:
2013 IEEE 10th International Conference on ASIC (ASICON), vol. 1(4), pp. 28–31 (2013)
3. Bağbaba, A.Ç., Ustaoğlu, B., Erdem, İ., Ors, B.: A layered UVM based testbench design for
SpaceWire. In: 2015 9th International Conference on Electrical and Electronics Engineering
(ELECO). Bursa, pp. 1164–1168 (2015)
4. Accellera Homepage. www.accellera.org/. Last accessed 20 Apr 2019
5. CAN Protocol Controller. https://opencores.org/projects/can. Last accessed 20 Apr 2019
6. Universal Verification Methodology (UVM) 1.2 User’s Guide, October 8 (2015)