SystemVerilog-SystemC TestBench Architecture for

VLSI Chip Design Verification

Mohammad Ismael§ , Ayman Hroub∗ , Nasib Naser§
Department of Electrical and Computer Engineering, Birzeit University, Birzeit, Ramallah, Palestine∗
Orion VLSI Technologies, Rawabi, Palestine§
2024 IFIP/IEEE 32nd International Conference on Very Large Scale Integration (VLSI-SoC) | 979-8-3315-3967-2/24/$31.00 ©2024 IEEE | DOI: 10.1109/VLSI-SOC62099.2024.10767804

Abstract—Simulation-based verification of Very-Large-Scale response of the DUT. It can be written in any language, such
Integration (VLSI) chip design is inevitable. However, the sim- as, C, C++, MATLAB, SystemVerilog, etc.
ulation speed can be a bottleneck in the verification process Simulation-based verification is a dynamic verification
productivity. People tried to accelerate simulation-based ver-
ification through parallelization, emulation, and reducing the technique, where the DUT is instantiated within a TestBench
number of test scenarios, etc. In this paper, we exploited the [1]. In this technique, the TestBench drives the DUT with
power of abstraction of SystemC to design fast and accurate constrained pseudo-randomly generated stimuli. The simula-
golden functional reference models. These reference models can tor, such as, Synopsys VCS or Cadence Xcelium simulates the
be integrated in the Universal Verification Methodology (UVM) behavior of the DUT for each stimulus. Then, the TestBench
based TestBench through Transaction Level Modeling (TLM).
Thus, the UVM based TestBench interacts with the SystemC samples the DUT’s response. Finally, the DUT’s response
reference model to get the golden values, and use them for is compared with the expected correct response obtained
checking. We used the proposed methodology to verify the from the reference model for the same stimulus. If the two
execution unit (EXU) of the open-source RISC-V based VeeR values do not match, then a bug has been detected. Figure 1
EL2 processor core. The experimental results showed that the depicts the role of the reference model in the simulation-based
proposed TestBench architecture with SystemC reference model
is up to 15x faster than the TestBench with SystemVerilog verification environment.
reference model.
Index Terms—Design Verification, UVM TestBench, Transac-
tion Level Modeling, SystemC, Co-Simulation.

I. I NTRODUCTION AND BACKGROUND

VLSI chip designs are getting complex and harder to verify.
The VLSI design process comprises many steps. Each design
step is a transformation of the design from one representation
to another. For example, the chip’s business requirements are
turned into architectural specifications. Then, the architectural
specifications are transformed into micro-architectural design.
After that, the micro-architecture is translated into a synthe-
sizable RTL (Register Transfer Level) design code, and so Fig. 1: High Level TestBench
on. Each design step has a corresponding verification step, to
ensure that the the original design intent has been preserved SystemC [2]–[4] is a powerful C++ based system-level
during these transformations. hardware modeling language. It has native support for TLM
Design verification is a crucial process to ensure that the which provides standardized communication models and
chip’s RTL design behaves as expected, before it is fabricated seamless integration with hardware and software components.
on silicon. Thus, the verification process aims to hunt the On the other hand, UVMC (UVM Connect) is an exten-
design bugs as early as possible to avoid the high cost and sion of UVM that provides a standardized way to connect
time-to-market delays resulting from bugs escape and chip simulation environments using TLM through a look-up string.
respin. The verification process comprises two steps, namely, In other words, it is a bridge between SystemVerilog UVM
driving and checking: and SystemC TLM [5]. It enables seamless communication
1) Driving the DUT (Design under Test) with an interesting, between SystemVerilog and SystemC models. UVM [6] is a
legal, and valid stimulus. SystemVerilog class library, and a methodology to build a
2) Capturing the DUT’s actual response for this stimulus, TestBench using this library. The UVM TestBench comprises
and comparing it with the expected correct response several verification components, such as, agents, drivers, mon-
obtained from the golden reference model. itors, sequencers, coverage, and scoreboards. Moreover, UVM
The reference model is a high-level executable version uses TLM [6] as a communication abstraction to exchange
of979-8-3315-3967-2/24/$31.00
the design specifications. It predicts
©2024theIEEE
expected correct data between its different components.

orized licensed use limited to: Smt Kamala & Sri Venkappa M Agadi College Of Engineering & Technology. Downloaded on February 25,2025 at 06:19:26 UTC from IEEE Xplore. Restrictions ap
 In this paper, we introduce a new UVM-based verification F. Poppen et al. [12], [13] talked about how UVM can work
environment that uses a SystemC based golden functional with SystemC and their own Integrated Functional verification
reference model. Script environment (IFS) in the verification process without
The reference model can be either, (1) run offline to gener- relying on a specific software. In [12], they used Mentor and
ate an execution trace that can be used as a golden reference Cadence simulators to show that their approach worked with
model, (2) or connected with the TestBench, such that the UVMC without depending on a certain proprietary technol-
TestBench can interact with the reference model and obtain ogy. In [13], they extended their work to cover the VCS-
the reference values at simulation time. We went for the latter MX simulator from Synopsys to use UVM inside a SystemC
in this paper. There are different ways to connect the SystemC TestBench for the verification of a Bus Arbiter with codes
reference model with a verification environment, such as, provided. However, to continue their productivity, they needed
Direct Programming Interfaces (DPIs) or Verilog wrappers to modify the verification strategy carefully. E. Erichsen [14]
using syscan. However, these ways have some limitations, Used TLM 2.0 to interface a SystemC reference model of a
such as, limited reusability, and limited coverage. This makes complex memory controller DUT with a UVM verification
them unsuitable for complex designs. environment to verify its functionality. SystemC and UVM
The DUT used to prove the efficiency of the proposed have their own TLM structure that is used as a communication
TestBench architecture is the execution (EXU) unit of the abstraction, where transactions are sent as communication
open-source RISC-V-based VeeR EL2 processor core [7]. This objects between components. However, SystemC TLM and
unit is responsible for supporting a wide range of arithmetic UVM TLM are not compatible with each other without a
and logic operations. Moreover, it implements RISC-V bit communication protocol.
manipulation extension instructions. Also, it handles branches, Baskar et al. [15] proposed an event sampling solution
pipeline flushes, pipeline control, and optimizations for small- to export functional coverage from the SystemC model to
number arithmetic. SystemVerilog each time the event is triggered. The coverage
The simulation results showed that the proposed methodol- data are sent as packets from the SystemC side to the
ogy resulted in a simulation speedup of up to 15x compared SystemVerilog side via TLM. On the SystemVerilog side,
with the verification environment that uses a SystemVerilog- the data can be de-serialized for functional coverage analysis.
based reference model. This is thanks to the abstract and fast Table I summarizes the related work.
SystemC-based reference model, and the TLM-based com-
munication between the UVM TestBench and the reference III. T HE P ROPOSED T EST B ENCH A RCHITECTURE
model.
The rest of this paper is organized as follows. Section Figure 2 shows a high-level block diagram of the proposed
II surveys the related work. Section III shows the proposed TestBench architecture. The DUT here is a RISC-V-based
TestBench Architecture. Section IV discusses and analyzes processor execution unit connected to the verification environ-
the experimental results. Finally, we conclude in section V. ment via a virtual interface. The SystemC EXU unit reference
model has similar functionality to the DUT, but with a high
II. R ELATED W ORK level of abstraction. It is used to calculate the expected output
and send it back to the UVM TestBench for checking. The
A. Moursi et al. [8] discussed the effect of using high-level
primary objective is to convert our native UVM TestBench
languages over SystemVerilog for building reference models.
which uses a built-in SystemVerilog reference model to a
They used implementation complexity, memory footprint, run-
UVM TestBench that can be interfaced with a SystemC
time, and UVM interface parameters to compare the high-level
reference model using TLM. On the UVM TestBench side,
language reference model’s performance.
the workflow is as follows:
Murti et al. [9] presented SystemC as an example of Exe-
cutable Specification Languages (ESL) to show the concrete • The top TestBench module is renamed to sv main,
illustration that can be applied in real-world scenarios, which serving as the entry point of the SystemVerilog side.
will enhance the understanding of the theoretical concepts • During the connect phase of the uvm env, UVMC TLM
and architectural exploration. Moreover, Abdulhameed et al. ports are connected and registered using lookup strings.
[10] talked about the benefits of using SystemC, such as, • These ports handle generic payload transactions via a
the Analog and Mixed-Signal good accuracy in modeling and TLM-blocking transport interface defined in the score-
simulating complex systems. board’s run phase.
Baskar et al. [11] used the basic building blocks of TLM • The uvm scoreboard has three TLM connections:
connection examples provided with the UVMC library to – A native uvm analysis imp import to receive the data
build and connect SystemC with SystemVerilog using UVMC. from the monitor using the write() method.
The paper shows a co-simulation of two send-receive packets – A uvm tlm b initiator socket, which is a socket that
examples. A packet is sent from the SystemVerilog to the sends generic payload transactions to the SystemC
SystemC side, which works as a monitor that unpacks the simple target socket via the b transport method.
received data and compares the bits using a comparator to – Another uvm analysis imp import to receive the ex-
check that the received data are the
979-8-3315-3967-2/24/$31.00 same IEEE
©2024 as the sent data. pected output from the reference model.

orized licensed use limited to: Smt Kamala & Sri Venkappa M Agadi College Of Engineering & Technology. Downloaded on February 25,2025 at 06:19:26 UTC from IEEE Xplore. Restrictions ap
 TABLE I: Related Work Summary
Paper Key Contributions Limitations Our Proposed Improvement
A Python script that takes the
Compared high-level languages with SystemVerilog for Generic payload data array size length uvm sequence item class file as an input,
[8]
building reference models limitation in SystemC. and generates the required code for sending
and receiving data.
Generic payload data array size length
Presented methods for data transfer between SystemC limitation in SystemC. Solved by A Python script that does not require any
[11] and SystemVerilog, including TLM 1.0 and TLM 2.0 designing a custom-made conversion custom-made conversions as it uses the UVM
approaches. algorithm for each connection using native generic payload class.
TLM-2.0 libraries
Investigated UVM integration with SystemC and their
[12], Requires verification environment
IFS environment, showcasing compatibility with various Does not require such changes.
[13] changes.
simulators without reliance on proprietary technologies.
Interfacing SystemC reference models with UVM TLM compatibility issues and Easier way to connect with SystemC reference
[14]
verification environments using UVMC. integration with SystemVerilog. models.

similar lookup strings of the registered ports. The matched

ports will interact with each other to send and receive trans-
actions. If there is a port with no match, an error is reported,
and the simulation is dropped. Because we are working with
cross-language verification, synchronization inside the UVM
TestBench is very important, as we need to make sure what
is being compared is what was initially drived to the DUT.
To achieve this synchronization, two points were taken into
consideration:
• The initial synchronization occurs during the driving and
sampling of transactions. The UVM driver employs a
clocking block that waits for the clock’s positive edge to
drive the signals. As the driver sends signals to the DUT,

Fig. 2: TestBench architecture and connections

On the SystemC reference model side, the workflow is as

follows:
• The entry point for the SystemC side is the sc main
function where the UVMC TLM ports with lookup
strings are defined.
• A simple target socket receives transactions from the
scoreboard. Fig. 3: Driver-Monitor Synchronization Workflow
• Upon receiving a transaction, an event signals that the
reference model’s inputs are ready. it simultaneously changes the value of enable signal
• After calculating the expected output, another event to high at the monitor to signal a driving operation as
triggers a thread that uses a tlm analysis port to send shown in Figure 3. The monitor will only sample if the
the output back to the scoreboard. enable signal is set to high and after a certain number of
During the connect phase, the registration of the TLM clock cycles. This prevents any sampling without driving,
lookup strings takes place when calling the UVMC TLM leading to improved reporting.
instances. This lookup string works as a reference to the • The second synchronization takes place in the
instance and is registered globally across both SystemC ref- uvm scoreboard. Figure 4 shows two queues that
erence model and UVM TestBench. are defined in the scoreboard, and are used to make sure
Before UVM’s end of elaboration phase, the UVMC will we are comparing the right data. The first queue stores
establish the actual cross-language©2024
979-8-3315-3967-2/24/$31.00 connection
IEEEand match the the received actual response (DUT response) gathered

orized licensed use limited to: Smt Kamala & Sri Venkappa M Agadi College Of Engineering & Technology. Downloaded on February 25,2025 at 06:19:26 UTC from IEEE Xplore. Restrictions ap
 by the monitor. On the other hand, the second queue We used Synopsys VCS for simulation. The simulation
stores the received expected response obtained from the results revealed that the verification environment with the Sys-
SystemC reference model. When the write ( ) method temC reference model is up to 15x faster than the verification
of the native TLM receives the DUT’s response, it environment with the SystemVerilog reference model.
pushes it on the first queue.
V. C ONCLUSION
VLSI chip design verification is a process of making sure
that what has been designed is what has been specified. This
process is complex and resources-consuming. In this paper,
we tried to accelerate the simulation-based design verification
process through using fast SystemC-based reference models.
We tested the proposed methodology on the execution unit
(EXU) of the open-source RISC-V-based VeeR EL2 pro-
cessor core. We replaced the EXU SystemVerilog reference
model with a new SystemC reference model. We integrated
the SystemC reference model with the UVM TestBench
through UVMC. The simulation results revealed that the UVM
TestBench with a SystemC reference model is up to 15x
faster than the corresponding TestBench with a SystemVerilog
reference model.
R EFERENCES
[1] G. Fey and R. Drechsler, “Improving simulation-based verification
Fig. 4: Queue Synchronization Workflow by means of formal methods,” in ASP-DAC 2004: Asia and South
Pacific Design Automation Conference 2004 (IEEE Cat. No. 04EX753),
pp. 640–643, IEEE, 2004.
[2] D. C. Black, “The definitive guide to systemc: The systemc language,”
This queue triggers the run phase as it waits for the queue’s 2015. Available at: https://newport.eecs.uci.edu/∼doemer/eee uci edu/
17f/16905/DAC15 SystemC Training.pdf.
size to be greater than zero. The data inside this queue will be [3] Wikipedia, “Systemc - wikipedia,” 2023. Available at: https://en.
pulled out and sent to the reference model via the b transport wikipedia.org/wiki/SystemC.
method after some tweaks. At the same clock cycle of sending [4] A. standards and TLM2.0, “www.accellera.org/downloads/standards/systemc
(visited: 17.02.2024)..”
the data to the reference model, the reference model will [5] Verification Academy, “Uvm-connect and tlm-2.0 primer,” 2023.
react and send back an expected output via a customized [6] “Uvm 1.2 user guide and reference manual,” 2015. [online] Available
write expected() method that pushes the data on the second in https://www.accellera.org/downloads/standards/uvm.
[7] Chips Alliance, “Cores-VeeR-EL2: A collection of risc-v cores and
queue. When the second queue’s size is greater than zero, this other ips targeting different levels of performance, size, and features..”
means that the actual response is inside the first queue and the https://github.com/chipsalliance/Cores-VeeR-EL2, Accessed: 2024-03-
expected response is inside the second queue. Now, the actual 04.
[8] A. Moursi, R. Samhoud, Y. Kamal, M. Magdy, S. El-Ashry, and
and expected responses can be sent for checking. SystemC A. Shalaby, “Different reference models for uvm environment to speed
elaborates faster than UVM. This means that the SystemC up the verification time,” in 2018 19th International Workshop on
reference model will start sending data to the UVM TestBench Microprocessor and SOC Test and Verification (MTV), pp. 67–72, IEEE,
2018.
before it is ready due to synchronization issues. This was [9] K. Murti and K. Murti, “Specification languages: Systemc,” Design
solved by the queue wait() synchronization method shown Principles for Embedded Systems, pp. 85–117, 2022.
in Figure 4. The generic payload includes a data attribute [10] A. Abdulhameed, B. AlKindy, and B. Al-Mahdawi, “Smart system
modeling and simulation design of hemodialysis machine by sysml with
represented as a byte array. This means that each index of systemc-ams,” 2022.
this array takes only eight bits. The DUT in the verification [11] V. Baskar, “Why not “connect” using uvm connect: Mixed language
environment has signals with varying data widths (32 and 64 communication got easier with uvmc,” DVCon United States, 2022.
[12] F. Poppen, M. Trunzer, and J.-H. Oetjens, “Connecting a company’s
bits). To address this UVMC limitation, a Python script was verification methodology to standard concepts of uvm,” DVCon Europe,
written to partition the signals that are wider than eight bits 2014.
into equivalent bytes within the data array. [13] F. Poppen, M. Trunzer, and J.-H. Oetjens, “Using synopsys vcs to
connect a company’s systemc verifiacation methodology to standard
concepts of uvm,” SNUG Germany, 2015.
IV. E XPERIMENTAL R ESULTS [14] E. S. Erichsen, “Interfacing systemc inside uvm using tlm 2.0,” Master’s
thesis, NTNU, 2020.
To evaluate the efficiency of using SystemC reference [15] V. Baskar, “Do not forget to ‘cover’ your systemc code with uvmc,”
models instead of SystemVerilog reference models in the DVCon United States, 2023.
design verification environment, we compared our SystemC
reference model with its SystemVerilog counterpart using the
execution unit (EXU) of the open-source RISC-V-based VeeR
EL2 processor core as our DUT. ©2024 IEEE
979-8-3315-3967-2/24/$31.00

orized licensed use limited to: Smt Kamala & Sri Venkappa M Agadi College Of Engineering & Technology. Downloaded on February 25,2025 at 06:19:26 UTC from IEEE Xplore. Restrictions ap