Configurable Verification IP for UART
Stepan Harutyunyan
Chair of Microelectronic Circuits and Systems National
Polytechnic University of Armenia
Synopsys Armenia Educational Department
Yerevan, Armenia
stepanh@synopsys.com
Artak Kirakosyan
School of Electrical Engineering and Computer Science
University of Ottawa
Ottawa, Canada
akira034@uottawa.ca
Abstract—Verification of Integrated Circuits using Verilog lacks
the flexibility and reusability of the environment. System Verilog
provides building blocks and OOP concepts to work with. That
allows to create much more flexible test environment with reusable
components. This paper presents a verification architecture of
configurable Verification IP for UART interface. The Verification IP
presented in this paper provides complete functionality of an
operating UART interface and can be used to test any UART device.
A functional coverage model has been developed to determine if the
verification process covers all possible scenarios or not. Each testcase
reports coverage which is later used to analyze the effectiveness of
the testcase. Full coverage has been achieved using both random and
directed test cases. The coding is done using System Verilog and the
simulation is done using VCS.
Keywords—UART, Verification, Functional Coverage, System
Verilog
I. INTRODUCTION
System on Chip design nowadays uses many reusable IP
cores and requires a lot of effort for the functional verification of
the system [1]. Since the systems are becoming bigger and bigger
the requirements for speed on the verification environment is
increasing. Not only speed but also the effectiveness of the
environment should increase in order to cover most functionality
in least time possible. Verilog is one of the ways to describe the
hardware, but Verilog is designed for hardware modeling and
lacks the features that are required for verification of complex
SoC designs. To fix those issues SystemVerilog has been
introduced with its specialized methodologies like Universal
Verification Methodology (UVM) and Verification Methodology
Manual (VMM). Those methodologies are currently widely used
in verification [2]-[5]. Other than methodologies in the
verification there are reusable IP blocks which are called
Verification Intellectual Properties (VIP). One of such VIP has
978-1-7281-9713-5/20/$31.00 ©2020 IEEE
2020 IEEE 40th International Conference on Electronics and Nanotechnology (ELNANO)
Authorized licensed use limited to: UNIVERSITY OF BIRMINGHAM. Downloaded on May 10,2020 at 08:47:42 UTC from IEEE Xplore. Restrictions apply.
Taron Kaplanyan
Chair of Microelectronic Circuits and Systems National
Polytechnic University of Armenia
Synopsys Armenia Educational Department
Yerevan, Armenia
tkaplan@synopsys.com
Haykaram Khachatryan
Chair of Microelectronic Circuits and Systems National
Polytechnic University of Armenia
Synopsys Armenia Educational Department
Yerevan, Armenia
khachatr@synopsys.com
been designed in this paper for UART interface. It is compliant to
UART specification [6] and can be easily used to verify any
device that has UART interface. Let’s describe the advantages of
SystemVerilog that the VIP is using.
One of such advantages is the functional coverage model [7].
System Verilog allows to do what’s called functional coverage-
driven verification. In order to do that you need to “translate” the
technical documentation into set of cover points and create the
coverage model. The coverage model will determine which
features have been tested by the environment and which have not.
That will help to understand the verification holes and cover them
to assure in completely verified product.
Other than the Coverage model SystemVerilog has the
object-oriented programming (OOP) concepts integrated into the
language too. That allows to separate the verification environment
into smaller parts. Those smaller parts or how you separate those
are the base of verification methodologies like VMM and UVM.
In general, the components are generators, for generate certain
packets, drivers to send those packets, receiver to receive,
monitors to monitor the interfaces and scoreboard to check the
correctness of the operation. There are other components, but
these are the widely used ones.
This paper concentrates on developing of configurable VIP
for UART interfaces. In upcoming chapters, the UART interface
overview is given to have general idea of the interface. The VIP
and test environment architectures are described, and everything
is concluded with the functional coverage results of the VIP.
II. UART OVERVIEW
Universal Asynchronous Receiver-Transmitter is one of the
widely used interfaces. It is a single TX and single RX line
interface. It can be configured to send and received data of 5-8
bits long with and without parity bit. Parity can be either even
234
 Fig. 1 The operating model of UART
parity or odd parity. Also, the stop bit count can be 1, 1.5 and 2
bits. Let’s quickly go over the UART operating model.
The UART bit clock is derived from an input clock of the
UART. Each data slot consists of either 13 or 16 BCLKs. The
operating model of the UART is presented in Fig 1.
When the data is being sent first the START bit should be
sent. In the idle state the TX line has logic high value and in order
to transmit the data TX line is being deasserted. On the receiver
side it is being considered as the beginning of START bit. After
the START bit, DATA bits are being sampled. Depending on the
configuration the data length can be from 5 to 8 bits long. After
the DATA bits, there may or may not be the PARITY bit. And at
the end, there are the STOP bits. Just like the START bit deasserts
the TX line the STOP bits assert the TX line. After that, the packet
sending part has been completed and the process can be restarted.
When, the data is being sampled depends if each data lasts 13
or 16 BCLKs. For 13 BCLK the data is being sampled at the 6th
BCLK and for 16 BCLK on the 8th.
Fig. 2 VIPs Block Diagram
Another thing to consider is the possible glitches that may
occur. To make sure that possible glitch on the TX line may not
cause any non-valid data sampling, debounce mechanism is
implemented. Each time the TX line is being deasserted for the
first time (START bit) that mechanism comes into play. The TX
2020 IEEE 40th International Conference on Electronics and Nanotechnology (ELNANO)
Authorized licensed use limited to: UNIVERSITY OF BIRMINGHAM. Downloaded on May 10,2020 at 08:47:42 UTC from IEEE Xplore. Restrictions apply.
line is being checked each BCLK and if on any of those the TX
line doesn’t have logic 0 value it is considered as glitch and no
sampling happens. This wraps up the operation of the UART.
Next chapter shows how the UART VIP was designed to support
all these features.
III. VIP ARCITECTURE
As mentioned earlier System Verilog has been used to create
the VIP. Unlike Verilog, System Verilog supports OOP which
helps to create the verification environment much more
faster and the components created for the current application may
be used in others also, in other words the components are reusable.
Since OOP concepts came into verification, the components
of the environment are split up. Fig. 2 shows the components that
the VIP consist of:
Generator: The generator is used to generate UART packets
according to the DUT configuration. At the beginning of
simulation, before sending packets the VIP is being configured.
During that part generator is configured also and when Data
should be sent, packets with correct data format are being created.
CLK_GEN: This module is used both in driver and receiver.
It is used to generate the BCLK and is responsible for all
operations related to data sampling and glitch checking. It uses
EVENT mechanism to trigger data sampling and state changes.
Driver: Driver is the component that controls the TX line.
When the generator creates a packet, it is being passed to driver
through mailbox and driver starts to send it. Driver doesn’t check
the configuration, it is done on earlier stage inside the generator.
The Driver simply sends the data. It has an instance of CLK_GEN
class which controls the timing.
Receiver: This block is used for RX purposes. It monitors the
RX line and is also responsible for glitch checking on RX line.
This block also has an instance of CLK_GEN class. This module
in combination with its CLK_GEN module is also responsible for
glitch checking.
In order to pass the data objects from one class to another a
special class for data has been created. All mentioned components
are working with “uart_pkt” type. This is special type which
encapsulates all the info needed to describe a full packet. This
datatype is also used in Scoreboard to compare received and
transmitted packets. Additionally, this data type includes special
variables which are sampled to determine functional coverage.
235
 IV. TESTBENCH ARCHITECTURE
The Testbench architecture is presented in Fig. 3. It shows
that the environment consists not only from DUT and the VIP but
also has application and scoreboard.
Application (APP): is the application side of the UART, the
other side, that needs to use the received data or sends the data to
VIP through DUT. Application has control over the DUT, at the
beginning of the test application reconfigures the DUT and resets
to prepare it for normal operation.
Fig. 3 Test Environment Diagram
Scoreboard: This component is responsible for multiple
things. First of all, it is used to compare sent and received data. It
has 4 mailboxes which are used to compare data sent in both
directions. When VIP sends data, it puts sent packet into
scoreboard and when the DUT received that exact packet it puts
it into scoreboard too. Those two packets are than compared to
make sure data was not corrupted.
Fig. 4. Loopback Mode in TE
Scoreboard is also responsible for test termination. This is
generally used in random testing, since it is hard to put an
endpoint in random testcase. It works based on coverage
percentage. After successful comparison of the packet, the packet
is used to take coverage results. Special variables inside the packet
2020 IEEE 40th International Conference on Electronics and Nanotechnology (ELNANO)
Authorized licensed use limited to: UNIVERSITY OF BIRMINGHAM. Downloaded on May 10,2020 at 08:47:42 UTC from IEEE Xplore. Restrictions apply.
object are used to sample coverage, those variables are set inside
the generator. When the coverage percentage reached certain
level, the simulation is completed. That level is determined by
user and shows how much of the functionality has been checked.
In general, the test environment works in loopback mode.
When the environment starts the application configures the DUT.
After that VIP is configured, and generator starts to create packets.
Packets are put into send mailbox and VIP automatically sends
those. At the same time application monitors the DUT signals.
When the DUT receives data, the application reads it and moves
it into the TX buffer of the DUT. DUT sends it back to VIP. Using
this mechanism both TX and RX sides are being tested. The idea
mentioned here is shown in Fig. 4.
Whenever the DUT received data it generates the
“uart_rx_fifo_read” signal. After one clock cycle the data is being
reported to the “uart_rx_fifo_data_out”. Data is being taken from
that port, moved to “uart_tx_fifo_write_data” and
“uart_tx_fifo_write” is being pulsed. It completes the loop and the
data is already in the TX fifo of the DUT. Since the TX is enabled
DUT starts to send that data back to VIP. Before sending the
packet is being sent to the Scoreboard to compare with the packet
that VIP will receive. In general, the Scoreboard has 4 packet
queues. It is separated 2 by 2 to compare data that VIP sent and
APP received and vice versa.
The Verification process is separated into couple phases, one
of them is random testcases to cover most of the functionality.
After that directed testcases are written to hit scenarios that
randomization-based testing hasn’t hit. Same process was used for
this environment also. In the random testcase the application was
reconfiguring the DUT, VIP was reconfigured after that and
certain number of packets were being sent in the loopback mode.
It was being done until a coverage of 90% was reached. When that
was done the results have been analyzed and remaining part has
been covered using directed testcases. These test cases allowed to
achieve 100% coverage on UART functionality.
V. FUNCTIONAL COVERAGE AND SIMULATION RESULTS
In order to measure the efficiency of the verification the code
coverage is introduced. It does a quantitative measurement of the
test environment by measuring and reporting the percentage of the
DUTs checked functionality [7]. One of the Coverage types is the
Functional Coverage. It is determined by user and can be used to
understand how much of the design specification is tested in the
environment.
Two separate cover groups have been introduced to check the
VIPs functionality. One for Tx side of the VIP and one for RX.
The Functional coverage cover groups are shown in Fig. 5. From
that figure it is seen that 100% coverage has been obtained on both
cover groups. The Code coverage results are being calculated after
each packet is sent and received either from VIP of from
application side. Than if it is random testcase the coverage metrics
is used to terminate the simulation.
236
 To achieve the full coverage both random and directed TABLE I. TEST CASE DISCRIPTIONS
testcases have been developed. Table 1 shows the summary of the Coverage Simulation
Test Name Config Name
testcases. Table contains the test case name, configuration of the TX/RX Time(s)
UART, Coverage percentage in both TX and RX (all the testcases Directed 01 8-EN-ODD-1 51.6 / 51.38 7.18s
were using the loopback mode) and the simulation time. Directed 02 7-EN-ODD-1 51.6 / 51.38 6.88s
Directed 03 6-EN-ODD-1 51.6 / 51.38 6.65s
Directed 04 5-EN-ODD-1 51.6 / 51.38 6.40s
Directed 05 8-EN-EVEN-1 51.6 / 51.38 7.22s
Directed 06 8-DIS-ODD-1 51.6 / 51.38 6.84s
Directed 07 8-EN-ODD-2 51.6 / 51.38 7.48s
Directed 08 8-EN-ODD-1.5 51.6 / 51.38 7.28s
Directed 09 8-EN-ODD-1 41.66 / 43.05 4.23s
Random 01 -Random- 95/83.33 65.8s

Test environment on the other hand implements not only the

Fig. 5 Cover groups of the VIP
Directed testcases from 1-4 test the environment for the bit
width. Test 05 checks the functionality of Even parity instead of
ODD. Test 06 is using disabled parity. Testcases from 7-9 are
checking the stop bit count. Coverage results are reported in “vdb”
format. As Table 1 shows all these testcases have quiet low
percentage on the coverage as they are testing specific
functionality of the UART Interface. In order to understand if
whole functionality was covered or not all those “vdb” files have
been merged and final results show 100% of coverage.
Other than usual testcases an error injection test case has been
developed to check if the RTL will detect the wrong parity and
will assert appropriate signal. That has been done using callback
mechanism. Before starting to send the packet, a certain function
is called. This idea is called callback. It is used to inject error
scenarios, such as parity error and also for coverage collection in
bigger designs.
Random testcase has also been implemented. It works in
certain order. At the beginning of the simulation application
reconfigures the DUT. When DUT is configured, the VIP is
reconfigured according to DUTs signals using same interface that
the application used to configure the DUT. When that is also
completed the VIP’s starts to generate and drive packets
according to the applied configuration. After certain numbers of
packets, if scoreboard doesn’t report any data mismatch the
configuration is randomized and the loop of reconfiguring the
application and DUT starts again.
The endpoint of the random testcase is determined by the
coverage results. It is being sampled after each packet is checked
in scoreboard and scoreboard from its side stops the loop if the
coverage has reached a certain threshold. For current testcase the
threshold was set to 90%. As shown in Table I the end result was
95% on RX side and 83.33% on TX side.
VI. CONCLUSION
A Verification IP for UART interface verification has been
successfully implemented using System Verilog. Simulations
have been done using VCS [8]. The VIP architecture is created
based on general verification concepts including generator,
drivers, scoreboard etc.
VIP but also application which allows to run the tests in loopback
mode allowing faster simulations and less code to manipulate the
DUT. About 10 Directed Test cases are written and simulated
using VCS to verify the functionality of UART. The simulation
waveform shows the successful data transfers in UART protocol.
This is also proved by the scoreboard results, as the VIP has
implemented data check mechanism. Functional coverage reports
show 100 percent functional coverage, this means that all the
cover groups are covered and prove the effectiveness of the
verification environment. The UART VIP created can be easily
used to test any device that has the UART interface as it can
simply be integrated in almost any Verification environment.
REFERENCES
[1] Khan S. A. “Digital design of signal processing systems: a practical
approach”, John Wiley & Sons, pp. 21-132, 2011.
[2] Visalli G. “UVM-based verification of ECC module for flash memories” in
2017 European Conference on Circuit Theory and Design (ECCTD). IEEE,
2017. С. 1-4.
[3] Elakkiya, C., Murty, N. S., Babu, C., & Jalan, G. “Functional Coverage-
Driven UVM Based JTAG Verification”, in 2017 IEEE International
Conference on Computational Intelligence and Computing Research
(ICCIC), pp. 1-7, IEEE. 2017.
[4] M. Moskala, P. Kloczko, M. Cieplucha, and W. Pleskacz, “UVM based
verification of bluetooth low energy controller”, in 2015 IEEE 18th
International Symposium on Design and Diagnostics of Electronic Circuits
& Systems, pp. 123-124, IEEE, 2015.
[5] Vineeth, B., and B. Bala Tripura Sundari. "UVM Based Testbench
Architecture for Coverage Driven Functional Verification of SPI Protocol."
2018 International Conference on Advances in Computing, Communications
and Informatics (ICACCI)., pp. 307-310 IEEE, 2018.
[6] Instruments, Texas. "Keystone architecture universal asynchronous
receiver/transmitter (uart) user guide." Texas Instruments User Guide
(2010).
[7] Chris Spear, "System Verilog for Verification, A guide to Learning the
Testbench Language Features", 3rd ed., pp 295-332, 2012.
[8] VCS® User Guide,Synopsys Inc. – Dec 2019. -2106p.
[9] Bergeron J. et al. “Verification methodology manual for SystemVerilog” –
Springer Science & Business Media, pp. 260-280 2006.
[10] Accellera, Universal Verification Methodology 1.1 User’s guide, CA,
(2011).
[11] Chu, Xiao Bin, L. U. Tie-Jun, and Y. Zong, "Combination of Assertion and
Coverage-Driven Verification Methodology." Microelectronics & Computer
11, 2008.

2020 IEEE 40th International Conference on Electronics and Nanotechnology (ELNANO) 237

Authorized licensed use limited to: UNIVERSITY OF BIRMINGHAM. Downloaded on May 10,2020 at 08:47:42 UTC from IEEE Xplore. Restrictions apply.