Functional Verifications for SoC Software/Hardware Co-Design: From

Virtual Platform to Physical Platform

Yi-Li Lin and Alvin W.Y. Su

Computer Science and Information Engineering Dept.
National Cheng Kung University, Tainan, Taiwan
AlvinSu@mail.ncku.edu.tw

ABSTRACT software part, the program can be enhanced to

This paper applies heterogeneous simulation
to achieve system and functional level co-
verification throughout SoC design flow. It reduces
high verification complexity resulted from covering
software and hardware works and involving various
tools. Stubs for data transport and a Verification
Router for heterogeneous simulation management
are proposed. A functional module is transformed
from a highly abstract model to its target design
progressively through a series of intermediate
models. Those models can be validated as a
portion of a complete SoC system model. The
proposed heterogeneous verification is
demonstrated with a jpeg encoder.
I. INTRODUCTION
Fig. 1 shows a conventional System-on-a-Chip
(SoC) design flow. First of all, the specification of
an application is built as a system model by using
C/C++. Because a SoC usually employs a
processor, the system model is ported to the target
processor for design space exploration (DSE). If an
off-the-shelf processor is used, an evaluation
board equipped the processor can be adopted. On
the contrary, if the target processor is unavailable,
one can use instruction set simulator (ISS) or
emulator. ISS is a software tool which executes
programs in the machine code format of the target
processor. Some ISS such as QEMU[1] can even
simulate or emulate a full system, including
peripherals. However, QEMU may be more helpful
than an evaluation board for DSE. In addition, a
guest operating system (OS) can be installed.
Thus, the system model is compiled to the target
processors instruction set and analyzed within
QEMU to determine software and hardware
partitions. Then, the development procedure is
divided into hardware and software parts. For
become the final application. The hardware part
follows VLSI design flow as shown in the upper
part of Fig. 1. Conventionally, after deciding
software and hardware partitions, RTL design
starts immediately by using hardware description
languages (HDL), such as Verilog and VHDL.
However, hardware design space exploration is
recommended recently. SystemC [3] is applied to
assist this procedure. Its a C++ library for
electronic system level [4] (ESL) modeling and
design. Tools like Synopsys Platform Architect [5],
included library such as ARM [6] mode and AMBA
model, can help to build a system level model
quickly. Before RTL design, the hardware model is
built by using SystemC. The model may reuse
codes from the original system model. Again, DSE
is applied to decide the hardware partition and
architecture. Afterwards, RTL design starts and is
verified by using stimuli dumped from the previous
hardware model. At this stage, HDL simulator, like
ModelSim [2], is involved in functional simulation
and verification. Usually, only pieces of stimuli are
used. At the end of hardware design flow, the
hardware module is emulated on FPGA as well.
However, for a SoC design, full-system verification
should combine both software and hardware
Figure 1: A Conventional SoC Design Flow.

978-1-4577-1617-1/11/$26.00 2011 IEEE 201

portions. With off-the-shelf processors, co-
verification is usually achieved by using SoC
platform equipped with the target processor and
FPGA.
Though programming and simulation tools are
changed according to design stages, functions of a
module should be the same. Functional
equivalence can be validated easily if co-
simulations among tools are practical. There are
works regarding the co-simulation issue. Works [7-
10] provide QEMU-SystemC co-simulation.
SystemC co-simulates with HDL can be found
in[11]. The [12] and [13] deal with co-simulation
between SystemC and an FPGA platform.
SystemC and SystemVerilog co-simulation is
introduced in [14]. Issues regarding
hardware/software co-simulation can be found in
[15-17]. In spite of dealing with co-simulation in
above works, they dont cover a whole SoC design
flow. System level simulation, including software
and hardware parts, may be required in every
stage such that functions of a new intermediate
model or module can be validated as a part of a
whole system.
This paper concentrates on functional and
system level verification. It is achieved by making
an ISS (QEMU is used here) to co-simulate with
tools involved in the SoC design flow. A co-
verification model is used as a reference.
Functional equivalence in every design transition is
verified by applying this model and employing co-
simulation among tools which range from virtual to
physical platform, such as QEMU and FPGA
devices. We insert stubs into models running in
different tools to establish data exchange tunnels
across tools. In addition, a centralized co-
simulation manager, called Verification Router, is
proposed to cope with complicated heterogeneous
simulation scenarios, such as a simulation
combining QEMU, HDL simulator and FPGA. Thus,
even if the target processor of a SoC design is
absent due to adopting a new design, system level
verification can still be achieved.
The rest of this paper is organized as follows.
Section II introduces a co-verification model for
SoC design flow at the beginning. Applying the
model to each design stage is described. A jpeg
encoder design example is presented in section III.
The last section gives a conclusion.
202
II. Functional Verification with Heterogeneous
Tools
As can be seen in Fig. 1, the flow involves
various tools and simulation environments. To
validate functional equivalence of models in
different implementation levels, co-verifications
between models or modules are recommended.
We proposed a co-verification model depicted in
Fig. 2. The environment indicates the adopted
programming languages or simulation tools. The
blocks, which stand for functions, in both
environments can be software or hardware models
built by using C/C++/SystemC or hardware
modules designed by using HDL, respectively. In
this figure, block B in environment I is a transitional
model which represents the golden sample in
subsequent design process. Its corresponding
design under test (DUT) is in environment II. The
two environments are connected via stubs. When
co-simulating, the stimuli is generated from golden
sample and sent to DUT. The outcome from DUT
is returned to the golden sample in environment I
and examined on-the-fly. The co-verification model
is applied to the design flow. Thus, the co-
simulation pairs can be (system model, hardware
model), (hardware model, RTL design), (hardware
model, FPGA) and so on. Overall system level
verification can be achieved if system software is
included in co-simulation. The co-simulation
construction is described as follows.
A. System Model and Hardware Model Co-
Simulation
As mentioned in previous section, DSE is
applied to system model in QEMU for software and
hardware partition. After deciding the partitions, the
hardware model is built for DSE by using SystemC
and reusing codes from the system model. It helps
to determine hardware module partition as well as
its architecture. However, SystemC model must
Figure 2: The Proposed Co-Verification Model.
execute outside QEMU. Hence, co-simulation
between QEMU and SystemC is required if
functional equivalence of the hardware model is
examined by involving the proposed co-verification
model. Works regarding this feature can be seen in
[7-10]. In this paper, stubs shown in Fig. 2 are
created.
In QEMU, hardware device is usually treated
as an interrupt-supported memory-mapped I/O
device. Here, we create a hardware device, called
QEMU_stub, to exchange data with devices
outside QEMU. The QEMU_stub is a set of data
access functions, such as Qstub_write, in QEMU.
QEMU invokes Qstub_write when software sends
data to the stub. Stubs employ inter-process
communication (IPC) to build a tunnel. IPC is a
mechanism in host environments, such as Linux
and MS-Windows, to support communication of
software processes. There are several approaches
to implement IPC such as shared memory,
memory-mapped file, socket and pipe. Shared
memory mechanism is adopted here. When QEMU
starts up, a system memory space of host OS is
registered with an ID by stubs. The ID is the key to
obtain the access to the memory space for any
processes. All data transports are achieved
through this memory space.
In SystemC, stub is like a wrapper. For
example, HW_SystemC_stub is placed in
hardware model to exchange data with
QEMU_stub. Once software in QEMU writes data
to the hardware model, the information, including
data and target address, is sent to QEMU_stub.
Then, QEMU_stub transmits it to the shared
memory space and sends signals to the
corresponding HW_SystemC_stub. Next, the
information is moved from shared memory into
HW_SystemC_stub with the IPC mechanism.
Lastly, the data is transmitted to target module via
SystemC interface. It is noted that QEMU is not a
cycle-accurate emulator. Therefore, the data
transport timing, recorded in SystemC simulation,
can not represent the real case. In other words, if
the HW_SystemC_stub records a transport in
th
1000 cycle of simulation time after booting up a
Linux in QEMU, it doesnt indicate that the
th
transport happens in the 1000 cycle if a physical
processor is employed. The advantage of not
involving cycle-accurate processor model is the
simulation speed. It costs less than 30 seconds to
203
boot up a tiny Linux kernel on QEMU while it
requires around 16 minutes on a cycle-accurate
QEMU[10]. Here, we focus on the functional
verification so that timing isnt critical issue.
B. Hardware Model and HDL Co-Simulation
After hardware model is tested fully, RTL
design starts. RTL design can be verified with test
patterns obtained from its previous transitional
hardware model, though the volume of patterns is
usually small. The proposed co-verification model
can verify RTL design, generating stimuli and
examining the outcome from RTL design on-the-fly.
The environment I shown in Fig. 2 is the hardware
SystemC model while the opposite side is its RTL
design. Some HDL simulators support SystemC-
HDL co-simulation. For example, SystemC design
is included and compiled together with RTL design
in ModelSim. However, all modules have to be pin-
and cycle-accurate. If the original SystemC model
adopts interface like transaction level modeling
(TLM) [18], the alteration of communication
interface is needed. Such modification from TLM to
pin- and cycle-accurate may propagate to a large
portion of a module. To achieve it in an effortless
way, two wrappers, SystemC_Stub and
HDLSim_Stub, are introduced. The SystemC_stub
encapsulates data for transmission in SystemC
model. The interface between a SystemC model
and the stub can be either TLM or any SystemC
primitive signals. Once the stub receives data, it
encapsulates data and transmits it to the
HDLSim_stub via IPC. The HDLSim_stub is a pin-
and cycle-accurate SystemC model, compiled in
ModelSim for interface transformation. The
interface between a HDLSim_stub and a RTL
module has to be customized according to the RTL
module. It usually implements the protocol of
hardware communication channel, such as AMBA
or others. Hence, if a bus writing operation in TLM
involves a batch of data in the SystemC model,
both data and address information are sent to
HDLSim_stub. The stub places them on the bus
cycle by cycle.
C. Hardware Model and FPGA Co-Simulation
After RTL design is completed, it migrates to
an FPGA, running at a high clock rate close to the
target system. The simulation speed is faster than
HDL simulator and huge volume of stimuli can be
applied. Besides, peripheral devices can engage in
test pattern production so that the verification
coverage is enlarged.
SC_FPGA_stub is established to achieve data
transport and support the co-verification model. It
involves FPGA access functionality and is
embedded in the hardware SystemC module. Here,
we adopt FPGA platform from SMIMS[19]. The
platform connects to PC via USB and provides
application programming interfaces (APIs) such
that user software in host PC can exchange data
with circuits in FPGA. The SC_FPGA_stub calls
the SMIMS APIs, such as FIFODataWrite or
FIFODataRead, for such data exchange. In FPGA,
a data transport wrapper helps to exchange data
between SMIMS framework and users hardware
module. The interface between the wrapper and
the users hardware module has to be designed in
terms of its specification.
Another role of this wrapper is to collect timing
information when SystemC models adopt TLM
interface. In SystemC TLM protocol, there are four
types of transport interfaces: blocking, non-
blocking, debugging, and direct memory interface.
The blocking and non-blocking transport interfaces
support timing estimation. When calling blocking
transport function b_transport(), the period spent
on a transaction is returned along with the function
call. For non-blocking transport interface, timing is
further divided for more precise measurement. Fig.
3 shows an example of an initiator transmitting
data to a target model. When a transaction starts,
the initiator calls nb_transport_fw() with a request
tlm::BEGIN_REQ. The function call returns
immediately. After certain period of time, the target
model accepts the request by calling
nb_transport_bw() with a flag tlm::END_REQ. The
time period is taken as Request Latency. The time
period between request acceptance and response
start is defined as Response Latency, while the
Operation Latency is the duration from the
Figure 3: Timing Diagram of a TLM Non-Blocking Transport.
204
response start to the end. In this example, the
response latency, OP_Lat, is transmitted back to
the initiator along with the function call
nb_transport_bw().This mechanism is implemented
in data transport wrapper with two additional
signals: Req and Ack. Fig. 4 shows the timing
diagram. When the wrapper raises Req signal, it
starts a timer until the Ack signal goes high. This
interval is marked as request latency. The other
two periods are measured similarly. Such timing
information is returned to support TLM timing
mechanism mentioned above.
D. System Model and HDL/FPGA Co-
Simulation
Co-simulations described previously cover
hardware design flow only. Considering system
level verification, software part should be included.
It is also advantageous to simulate as a complete
system. The system model is constructed as a
golden sample, representing the target SoC. It
usually generates huge volume of test patterns.
With co-simulations, outcomes from hardware
portion can be examined by the system model on-
the-fly. The stimuli which results in incorrectness
can be recorded to test the possible faulty modules.
In section II-A, we employ QEMU as the target
processor running OS and software. Hardware
models can join co-simulation by embedding
QEMU_stub. Here, we modified HDLSim_stub and
SC_FPGA_stub, used in HDL simulator and FPGA
respectively. Originally, the HDLSim_stub
communicates with SystemC_stub via IPC. Thus, it
can also connect with QEMU_stub. Furthermore, in
order to make it closer to the target system, the
interface between HDLSim_stub and the RTL
module is advised to follow the one in the target
system. For example, if the RTL module connects
to an AMBA bus, it is better to adopt AMBA as the
interface between HDLSim_stub and the module.
As far as FPGA is concerned, the solution is
Figure 4: Timing Diagram of FPGA wrapper supporting TLM
Non-Blocking Transport.
similar to QEMU_stub. As mentioned above, we
adopted SMIMS FPGA platform which provides
APIs for data exchange. We wrapped SMIMS APIs
as a hardware device in QEMU. When software in
QEMU transmits data to the hardware device, the
data is sent to the module in FPGA so that
software and hardware portions cover the
complete functions of the SoC. This enables
system-level verification even the target processor
is absent.
E. Verification Router, the Heterogeneous
Simulation Manager
In above work, we adopted stubs to achieve
one-to-one co-simulation across two different
designs or simulation environments. The
QEMU_stub and HW_SystemC_stub help co-
simulation between software in QEMU and
hardware model built by using SystemC, while
SystemC_stub and HDLSim_stub link hardware
model and HDL simulator together. In addition,
SC_FPGA_stub connects hardware model to
FPGA. The derived versions support system level
simulation and verification. Since the
communication protocol among all stubs can be
identical, we defined a general communication
protocol and built a centralized heterogeneous
simulation manager, called Verification Router, to
cope with complicated co-simulation scenarios.
Verification Router is the rendezvous for all stubs,
as shown in Fig. 5. It is responsible for simulation
organization. When simulating, a session is
created, describing connections among stubs in
the Verification Router. Each connection is
represented by an ID. Thus, stubs connect to the
router with the dedicated ID and data transport is
built between two stubs of using the same ID. With
Figure 5: The Verification Router as a Heterogeneous
Simulation Manager
205
Verification Router, the co-simulation extends to
designs among tools. For example, a simulation
session can combine application software
executed in QEMU, hardware model by using
SystemC and an off-the-shelf design which is only
available on FPGA. Thus, system level simulation
and verification can be applied more widely.
III. Demonstration and Results
We used a JPEG encoder as a demonstration.
Its C code is first tested. Then, we ported it into
QEMU which emulated an ARM system with Linux
kernel installed. The JPEG encoder executed in
QEMU is regarded as one system model. Then,
DCT is separated from the C code and a dedicated
hardware circuit will be designed. Therefore, the
DCT function is refined as a SystemC model. The
model adopts TLM interface to connect with
HW_SystemC_stub. A QEMU_stub was inserted
into QEMU whose code snap can be found in [20].
The second system model is completed. Next,
DCT is designed as a RTL module and verified in
ModelSim. The interface between HDLSim_stub
and DCT module is memory-mapped bus, because
processor uses memory-mapped bus to connect
with DCT module in the target system. Part of
HDLSim_stub code is also in [20]. To verify the
RTL model, the DCT SystemC model generates
stimuli, which will be transformed by the DCT
module, and examines the transformed outcome.
In the simulation, 300 blocks of 8x8 pixel data were
involved and no failure was found. The co-
simulation with FPGA is similar and its description
isnt included here due to page limitation.
Next, system level verifications are applied
with QEMU and FPGA. We enhanced the software
part as a JPEG encoding application on Android
and placed the DCT hardwired into FPGA. A data
transport wrapper connects to the DCT by using
memory-mapped bus. The execution snapshot is
shown in Fig. 6. The android emulator, in the right
Figure 6: The Snapshot of QEMU and FPGA Co-Simulation
side, shows the original figure and the compressed
result. Messages in command console displayed
the exchanged data and the verified result. In this
simulation, 100 figures were used and the fault
resulted from register overflow was found and
removed. Finally, entire design, including JPEG
application on Android and RTL design, is migrated
to physical platform, shown in Fig. 7. The right-
hand-side is FPGA which hosts DCT hardwired
and the left-hand-side is an ARM cortex-A8. These
two are connected via a memory-mapped bus. The
JPEG application as well as Android is executed
on the ARM. Due to lack of image input device, we
used stored files as test data. The result is shown
on a LCD panel. Most off-the-shelf platforms are
usually close systems which make the execution
status of circuits in FPGA invisible. The adopted
FPGA platform provides USB interface connecting
with host PC. Therefore, an interface circuit is
added aside the DCT module to send intermediate
results of DCT module back to the system model
executed in A8 in real time so that it can be
compared with the golden sample. The system
works well through the series of co-verifications.
IV. Conclusion
In this paper, interfacing stubs and Verification
Router are proposed to support complicated co-
simulation scenarios of adopting a co-verification
model, employing heterogeneous tools in SoC
design flow. The co-verification model involves a
golden sample, like system model, to verify
intermediate designs generated when transforming
a design from its abstract level model to RTL. With
the proposed mechanism, boundaries of software
models and hardware modules operating in
different tools are removed. That is, models or
modules working in both virtual and physical
platform can simulate together just like they work in
target SoC design. In this paper, the co-simulation
tools include QEMU, SystemC, HDL simulator, and
FPGA. Finally, with USB interface of the FPGA
Figure 7: The Physical Platform of Executing Entire SoC
System
206
platform, circuit in FPGA can also be verified with
its golden sample running on the host PC on-the-
fly.
REFERENCES
1. F. Bellard, QEMU, a Fast and Portable Dynamic Translator,
2005 USENIX Annual Technical Conference, pp. 41-46,
April, 2005.
2. ModelSim [Online] available: http://model.com
3. SystemC [Online] available: http://www.systemc.org
4. D. Densmore, R. Passerone, and A. Sangiovanni-Vincentelli,
A platform-based taxonomy for ESL design, IEEE Des.
Test Comput., vol. 23, no. 5, pp. 359374, Sep. 2006.
5. Synopsys Platform Architect [Online] available: http://www.S
ynopsys.com/Systems/ArchitectureDesign/Pages/PlatformAr
chitect.aspx
6. ARM [Online] available: http://www.ARM.com
7. M. Monton, A. Portero, M. Moreno, B. Martinez, and J.
Carrabina, "Mixed SW/SystemC SoC Emulation
Framework," in IEEE Int. Symp. On Industrial Electronics, pp.
2338-2341, 2007
8. QEMU-SystemC, GreenSocs, [Online] Available:
http://www.greensocs.com/en/projects/QEMUSystemC.
9. S.T. Shen, S.Y. Lee and C.H. Chen, "Full system simulation
with QEMU: An approach to multi-view 3D GPU design," In
IEEE Proc. of Intl Symp. on Circuits and Systems, pp.3877-
3880, May 2010
10. M.C. Chiang, T.C. Yeh and G.F. Tseng "A QEMU and
SystemC-Based Cycle-Accurate ISS for Performance
Estimation on SoC Development," IEEE Trans. Comput.-
Aided Design Integr. Circuits Syst. , vol.30, no.4, pp.593-606,
April 2011
11. J. Park, B. Lee, K. Lim,J. Kim, S. Kim, K.H. Baek "Co-
simulation of SystemC TLM with RTL HDL for surveillance
camera system verification," IEEE Intl Conf. Electronics,
Circuits and Systems, pp.474-477, August 2008
12. W.M. Young, C.H. Huang, A.P. Su, C.P. Jou and F.L. Hsueh
"A practice of ESL verification methodology from SystemC
to FPGA - using EPC Class-1 Generation-2 RFID tag
design as an example," Design Automation Conference
(ASP-DAC), pp.821-824, 18-21 Jan. 2010
13. C.Y. Huang, Y.F. Yin, C.J. Hsu, T.B. Huang, T.M. Chang
"SoC HW/SW verification and validation," Design
Automation Conference (ASP-DAC), pp.297-300, 25-28
Jan. 2011
14. M.K. You and G.Y. Song "Case study: Co-simulation and
co-emulation environments based on SystemC &
SystemVerilog," IEEE TENCON 2009 Region 10
Conference , pp.1-4, 23-26 Jan. 2009
15. Vojin Zivojnovic and Heinrich Meyr,"Compiled HW/SW co-
simulation," Design Automation Conference, pp.690-695,
1996
16. A. Hoffmann, T. Kogel and H. Meyr, "A framework for fast
hardware-software co-simulation," Cofn. Design,
Automation and Test in Europe,pp.760-764, 13-16 March
2001
17. L. Formaggio, F. Fummi and G. Pravadelli, "A timing-
accurate HW/SW co-simulation of an ISS with SystemC",
CODES+ISSS '04, ACM , pp. 152--157, 2004
18. M. Monton, J. Carrabina, and M. Burton, Mixed simulation
kernels for high performance virtual platforms, in Proc.
Forum Specification Des. Languages, pp. 16, Sep. 2009
19. SMIMS Corp. [Online] available: http://www.smims.com
20. Code snap. [Online] available: http://screamlab-ncku-2008.
blogspot.com/2011/04/code-snaps.html