Rapid-Prototyping Emulation System for Embedded System
Hardware Verification, using a SystemC Control System
Environment and Reconfigurable Multimedia Hardware
Dave Carroll, Richard Gallery
email@example.com , firstname.lastname@example.org
School of Informatics and Engineering,
Institute of Technology Blanchardstown, Dublin 15, Ireland
This paper describes research into the suitability of using SystemC for rapid prototyping of
embedded systems. SystemC communication interface protocols  are
interfaced with a reconfigurable hardware system platform to provide a real-time emulation
environment, allowing SystemC simulations to be directly translated into real-time solutions.
The consequent Rapid Prototyping Emulation System Platform1, suitable for the
implementation of consumer level multimedia systems, is described, including the system
architecture, SystemC Controller model, the FPGA configured MicroBlaze CPU system and
additional logic devices implemented on the Multimedia development board used for the
hardware in the PESP, illustrated in the context of a typical application.
The paper describes research into the development for SystemC of an emulation environment
in which SystemC based specifications can be translated directly into real-time
hardware/software implementations. This would allow SystemC based designs to be
implemented directly as real-time solutions, and would provide a rapid prototyping route
(improved time-to-market) for complex hardware/software systems.
This paper describes a prototyping platform, incorporating hardware acceleration under
software control, suitable for the real-time implementation of SystemC designs,. The
this system includes research into the architecture required to enable SystemC to be used
directly for real-time systems, and the implementation of a prototyping system, with an
application focus on consumer level multimedia systems, to investigate the viability of the
The SystemC section of the prototyping system provides a tool for the specification,
implementation and evaluation of different embedded system architectures and facilitates
selection and evaluation of different communication interface approaches between the
embedded SystemC functional models within the design.
The hardware acceleration platform, oriented towards consumer level multimedia
applications, is based on an FPGA multimedia development platform, which provides a
reconfigurable hardware real-time emulation environment, for prototyping real-time
application designs, in conjunction with the SystemC system model. The Hardware subsystem
is designed around a Xilinx MicroBaze and Multimedia Development Board2,
incorporating a MicroBlaze3 processor architecture implementation, on an Xilinx Virtex
II FPGA based platform. Hardware functional blocks developed as part of the system are
written as VHDL4 models5  in the FPGA.
2. Real-time implementation of SystemC based designs
Research questions with regard to the practicality of developing real-time emulation systems
for SystemC designs include:
Whether the underlying architecture of SystemC is suitable for direct real-time
implementation of a SystemC based model
ð If not, is there some subset of, or enhancement to, the SystemC approach, which is
suitable for real-time implementation.
ð Which modelling approaches, when deployed in SystemC based designs, are suitable
for (real-time) emulation.
The interaction of SystemC with real-time OS. This is an active development area within
SystemC, and also in hardware-software co-verification systems (e.g. ).
What hardware/software architecture(s) for emulation platforms are required to allow real
time implementation of SystemC designs?
What hardware components are required within such real-time platforms to facilitate
What interfaces are required between the software and hardware aspects of such systems?
This paper discusses the PESP and in doing so presents a suitable SystemC based design, that
when interfaced with a reconfigurable hardware system platform, using a suitable
communication interface protocol, demonstrates that the underlying architecture of SystemC
is suitable for direct real-time implementation of a SystemC based model. The paper discusses
a modular modelling approach, which when deployed in the PESP SystemC based design, is
suitable for (real-time) emulation. The author presents an hardware/software architecture for
1 Here after referred to as PESP
2 Here after referred to as MMDB
3 Harvard architecture, 32bit CPU, defined and supplied by Xilinx
4 VLSI Hardware Descriptive Language
5 Refers to a functional block configured within the FPGA, written in VHDL or Verilog.
an emulation platform that facilitates the real time implementation of the SystemC design and
defines the hardware components used in that design.
3. A Co-Verification Platform
There is already active research into the development of architectures and platforms suitable
for the emulation of systems described with system level description languages (such as
SystemC). To date the research is largely targeted towards co-verification platforms6, where
fast verification of a design is required, rather than real-time emulation . Nevertheless there
is a significant correspondence in the research required to develop both fast verification
systems and real-time systems.
For example in  the functional requirements for a co-emulation modelling interface are
discussed and an architecture and API is provided (SCE-MI) to achieve these requirements.
SCE-MI has been developed to meet growing industry demands for verification platforms for
Systems-on-Chip (SoC) designs. It provides a mechanism via which the software aspects of
an SoC design may be simulated on a workstation, the hardware aspects may be simulated on
a hardware verification platform, and an efficient interface mechanism (hardware-software
transactors) between the two, represented in Figure 12. SCE-MI facilitates the use of a system
design language such as SystemC, as it offers the potential for fast verification (as the
hardware aspects of the system may be emulated using real hardware, as opposed to using a
workstation based software simulator).
In a SystemC design it would be normal to initially produce a high-level abstract model of the
entire system, with the process of refinement then being used to redesign the system, such that
software components of the system modelled at a high level of abstraction, and hardware
components modelled at an appropriate lower level of abstraction. Once this process of
refinement has taken place, the hardware components must be simulated and verified. The
Zebu system provides a software/hardware co-verification platform using an
implementation of the SCE-MI protocol. Using Zebu the software and hardware components
of the design can be verified together, with the hardware emulation system allowing much
more rapid verification time than would be the case using a software simulation of the
The hardware-software transactor is a form of abstract gasket, which forms part of the SCEMI
infrastructure. The transactor communicates at the transactional level (e.g. Read and Write
commands) with the software side of the system model, decomposing untimed messages into
a series of cycle-accurate clocked signals. These clocked signals form the communication
interface between the transactor and the hardware, on the hardware side of the system model.
Similarly the hardware communicates with the transactor at the signal level, where the cycle
accurate signals are recomposed into transactional level messages, for transfer to the software
interface. Figure 13 shows an example of a message being translated from the software side of
a system model, through the transactor, to the hardware signal side of the transactor.
During the period from when the message is received by the transactor, controlled time will
be suspended within the software environment via handshaking between the transactor and
the SCE-MI infrastructure. The transactor will decompose the incoming message and generate
required cycle accurate bit level signals to drive the hardware. Once the transactor actions
have been completed, controlled time will be resumed via the transactor handshaking and the
4. PESP Description
The PESP has been developed with a focus on investigating the application of SystemC based
rapid prototyping in consumer level multimedia applications. Its is based around the concept
of a SystemC based control system, supported by application specific hardware accelerators
and other components, with communication between the software and hardware managed by
transactors based upon the SCE-MI protocol.
Currently this system is based on a SystemC control system using set-up on a host PC7 and a
MMDB hardware development platform, containing a Xilinx, MicroBlaze softcore
processor implemented on a XilinxVirtex II FPGA fabric, along with other ASIC devices.
The SystemC control system and the MMDB communicate through transactors, utilising a
serial or other interface (such as an Ethernet link) at the physical layer. It should be apparent
that the use of a PC in the development system is for convenience of development purposes
only, and that, outside of the research environment, the System C control system would
naturally be implemented, for example, on the MicroBlaze softcore processor.
5. Platform Architecture
The architecture of PESP can be described using a multi-layered model to describe the overall
system in an abstract form, de-coupling the system architecture from the implementation
details. The multi-layered architecture consists of an Application Layer (AL), Presentation
Layer (PL) and Driver Layer (DL), as shown in Figure 14.
The PL is responsible for the management of the data-flow, which implements the various
functions of the platform and is controlled by the AL. The PL converts information received
from the AL into a defined order and communicates with the DL, sending requests to and
receiving status from the DL. The DL controls each of the hardware components (e.g. in the
case of a Digital camera application, a task may consist of image capture) directly, passing
required parameters and enabling the hardware components. The DL will receive status
information from the hardware components and pass appropriate status response to the PL.
Where several tasks are required to complete one single user command (e.g. capture an image
and save it to memory), the PL will define the sequence of execution and control the
execution, through the DL.
The DL is the only layer that interfaces directly with the Hardware Components of the
system. Thus if any changes are required to the hardware, only the DL will be required to be
modified to accommodate the change. The Hardware Component blocks are under the control
of the DL and may be implemented directly in hardware, software, or a combination of both
hardware and software. For example an image compression feature may be implemented in
hardware, in software or in a combination of both, depending on the optimal implementation
for the particular system, which will be determined by the design engineer based on system
design goals and constraints. For example, hardware implementation of the compression
feature might result in a faster execution of this feature than the software implementation of
the same feature, however this may result in an unacceptable increase in hardware costs.
6. SystemC and MMDB Communications Interface
The overall platform architecture described above is now mapped to an implementation
incorporating SystemC, a re-configurable hardware board. The communications interface
between the SystemC model and the re-configurable hardware is modelled on the Standard
Co-Emulation API: Modelling Interface. This specification describes a modelling interface
based on a multi-channel abstract bridge, providing multiple communication channels that
allow software models describing system behaviour, such as the PESP SystemC controller
Figure 15 shows a high level view of the communications interface between the SystemC
controller system and the MMDB based hardware emulation system. The SystemC system is
on the left of the figure and consists of several SystemC models describing the controller
functions, the Xilinx MMDB platform is on the right of the figure. The Transactor performs
the interface mechanism linking the high level SystemC controller description and the
hardware implementation of functions within the FPGA MMDB development platform. The
Transactor implementation consists of several layers of software and hardware, from the
SystemC model down to the PC hardware drivers, across the physical serial interface to the
MMDB development platform and onto the MicroBlaze system implemented on the FPGA
7. SystemC Controller System Description
The PESP SystemC is constructed using a modular approach to provide partitioning between
the different functional elements of the overall controller. Some of the benefits obtained from
using this approach include:
1. The ability to break the complex system to smaller more manageable pieces, which
proved useful when defining the overall SystemC system. A list of sub-functions required
by the system was initially generated and a SystemC model created for each sub-function.
Each model was then tested individually to ensure functionality. When the overall system
was built, errors were diagnosed quickly by focusing on the interconnections between the
2. The movement of functionality between different models, which proved useful during the
Control model design. For example, moving all of the message display functions to the
message display model, which has previously been contained in the system control
model. The modular nature of the system made the movement of the functionality a
relatively straightforward process, with only two SystemC models affected.
3. The simplification of addition and/or removal of models from the system. This was
particularly useful when moving functionality from the SystemC Controller System to
hardware, as the hardware platform was being built. Additional SystemC models were
required in order to implement the SCE-MI protocol. It was simply a matter of defining
the functionality and inserting the models into the existing SystemC system. The ability to
change or refine the communication interfacing between the different models is relatively
straightforward when the system is designed with a modular construction. This proved
very useful when deciding which interface channel type to use to connect the SystemC
models that make up the overall SystemC Controller system. Different interface channel
and port types can affect the flow of data from one SystemC model to another,
communication refinement is described in detail in  and . Primitive channels
(sc_fifo) were chosen for communications between SystemC models in this system. The
sc_fifo primitive channel provides the ability to communicate between SystemC models
using a blocking and non-blocking read/write instruction; which ensures that data does
not get lost between data transfers. Primitive channels also suspend the operation of a
Thread model if the channel is full or empty, depending on the requested command.
Figure 16 shows the SystemC models designed for this system and the interconnections
Figure 16: Block diagram for PESP SystemC Controller
The controller system architecture can be represented as a multi-layered architecture model as
shown in Figure 17, where the AL of the system consists of the SystemC application model.
The PL function of the controller system architecture is defined in the control model. The PL
puts commands received from the AL in a defined order and communicates with the DL,
sending requests and receiving status. The PL defines the order of execution and controls the
hardware component activities through the DL. The PL will interpret commands and ensure
that only predefined and acceptable user commands will be responded to and passed on to the
DL. The PL will also communicate command execution status to the user, via the AL. In this
system the DL is spread across the Port Interface model (Figure 16) and on to the MMDB
platform. The DL contains the transactors, resident on the MMDB, and is responsible for all
communications with the hardware.
8. Reconfigurable Hardware
The MMDB was chosen to provide the reconfigurable hardware as it provided a range of
multimedia oriented features (such as video and audio codecs), combined with an FPGA to
allow additional hardware functionality to be developed. This system is built around the
Xilinx MicroBlaze 32-bit RISC Soft processor, which, as currently configured, acts as part of
the transactor, interpreting commands from the SystemC controller, controlling hardware
components on the MMDB, and managing dataflow between those hardware components
themselves, and the higher level SystemC modules. The transactor is implemented through
software (written in C programming language) and hardware, which instructs the
MicroBlaze hardware to initialise the image grabber hardware using clock cycle accurate bit
signals through the MicroBlaze Peripheral Bus interface registers Figure 18.
As has been eluded to earlier, the higher level SystemC models are currently implemented on
a PC, but it would be the intention, in a later stage of development, to transfer all software
functionality to the MicroBlaze itself, in which case it would implement the entire system
architecture described in Figure 14.
Figure 19 shows the hardware components that were developed as part of the research and are
controlled by the transactor. The Display Engine Module, Image Grabber, Workarea Control
Module and Resync Module are all VHDL modules, designed, constructed and tested using
the Xilinx ISE design environment . The peripherals are attached to the MicroBlaze CPU
via the OPB8 Interface Bus, which is a 32Bits data bus and is configured to run at 81 MHz.
All devices are accessed and controlled by software running on the MicroBlaze processor.
Video images are decoder external to the FPGA and enter the FPGA via the Video Resync
module9 in 10-bit YCbCr PAL data format . Here the data is synchronised with
the output from a 27 MHz-clock generator model, contained in the FPGA (not shown in the
figure). Data exiting the Video Resync model is passed directly to the Video Encoder, a single
chip, outside the FPGA boundary, on the development board.
Image display switching between the live video input data stream and the Display Engine
output (containing a saved image) is controlled by the Display Engine under the control of the
software running on the MicroBlaze.
The Image Grabber VHDL model is used to capture and store images, and is under the control
of the MicroBlaze software. Communications to and from, the software takes place through
Control, Status and Data models connected to the OPB interface bus. Images are stored in the
Image Memory10 device, located outside the FPGA. The SRAM is controlled by the Image
Grabber VHDL model.
The Display Engine model is responsible for the display of captured images. It provides a
continuous stream of 10-bit video data to the Video Resync module, synchronised with the
system 27 MHz clock. The Display Engine also controls the contents of the Image Display
Memory device, which is located on the MMDB, external to the FPGA. The Display Engine
is under the control of the MicroBlaze via a Control, Status and Data models connected to the
OPB interface bus.
The Interrupt Controller is used to interrupt the CPU upon request from the Uart Serial
Control model, which is connected to the RS232 interface and the OPB interface bus.
Commands to and from the SystemC Controller are sent through the Uart model. The JTAG
Interface Control model is used for debug interface access for the EDK system.
The Workspace Memory consists of a single SRAM device on the MMDB and is controlled
by the Workarea Controller connected to the OPB bus. This storage facility is used for
temporary storage of images as they are being manipulated.
9. Sample PESP Application Implementation
A digital camera was used as the focus application for functional testing of the PESP
platform. The digital camera application is an example of a widely available digital system,
which is sufficiently complex to provide scope for different architecture and technology
configurations. The digital camera functions also suited the application devices, which are
integrated into the Xilinx MMDB hardware development board (however PESP is not board
specific). A digital camera is an example of a system that uses several data processing
functions, which are relatively self-contained and as such simplify the implementation of
functions using a modular approach. For example the image grab function is not dependent on
image display function and as such both functions can be implemented in separate hardware
10. Conclusion & Future work
This paper discussed the PESP, which consists of an integration of both a SystemC controller
and a reconfigurable multi-media hardware development platform.
This paper presented a suitable SystemC based design, that when interfaced with a
reconfigurable hardware system platform, using a suitable communication interface protocol,
demonstrates that the underlying architecture of SystemC is suitable for direct real-time
implementation of a SystemC based model.
The paper discussed a modular modelling approach, which when deployed in the PESP
SystemC based design, is suitable for (real-time) emulation. The paper also discussed an
hardware/software architecture for an emulation platform that facilitates the real time
implementation of the SystemC design and defines the hardware components used in that
The higher level SystemC models used in PESP are currently implemented on a PC, however
models could be transferred from the PC platform to the MicroBlaze itself, which would
implement the entire system architecture described in Figure 14 on the MMDB. The
interaction of SystemC with real-time OS was not considered as part of this paper and could
 OSCI; http://www.systemc.org
 OSCI; “Functional Specification for SystemC 2.0”, available at http://www.systemc.org
 T. Grotker, S Liao, G. Martin, S Swan; “System Design with SystemC”; Kluer Academic
Publishers, ISBN 1-4020-7072-1
 Standard Co-Emulation Modelling Interface (SCE-MI) Reference Manual, Version 1.0, Published
by Accellera, available from http://www.eda.org/itc
 J. Stickley, Duaine Pryor; “Functional Requirements Specification: Standard Co-Emulation
Modeling Interface (SCE-MI)”; http://www.systemc.org
 Emulation and Verification Engineering; “Universal Design Verification Platform for IP, FPGA,
ASIC Design and Embedded Software Developers”; http://www.eve-team.com
 Jon Connell, Bruce Johnson , Early Hardware/Software Integration Using SystemC 2.0, ESC San
 L. Benini et al., SystemC Cosimulation and Emulation of Multiprocessor SoC Designs, IEEE
Computer, April 2003, pp. 53-59.
 Virtex II data sheet (Xilinx doc. no. DS031-1), http://www.xilinx.com
 Embedded Systems Tools Guide (EDK 3.2.2), http://www.xilinx.com
 Xilinx Virtex II MicroBlaze and Multimedia Development Board, http://www.xilinx.com
 ISE user guide, http://www.xilinx.com
 A Technical Introduction to Digital Video, Charles Poynton, John Wiley & Sons, ISBN 0-471-
 Video & Television Engineering, J. Whitaker and B. Benson, McGraw Hill, ISBN 0-07-069627-6
 ADV7185 Video NTSC/PAL Decoder data sheet, http://www.analog.com
 MicroBlaze RISC 32-Bit Soft Processor data sheet, http://www.xilinx.com
 The C Programming Language, Kernighan & Ritchie, Prentice Hall, ISBN 0-13-110362-8
 VHDL made Easy, D. Pellerin & D. Taylor, Prentice Hall, ISBN 0-13-650763-8
 VHDL for Designers, S. Sjoholm & L. Lindh, Prentice Hall, ISBN 0-13-473414-9
 Digital System Design with VHDL, M.Zwolinski, Prentice Hall. ISBN 0-201-36063-2
 Co-Simulation Between SystemC and a New Generation Emulator, C. Alquier, S. Guerinneau,
L.Rizzatti, L. Burgun, DesignCon 2003
sumber: ITB Jurnal