Using FPGA Prototyping Board as an SoC

Verification and Integration Platform

Rev. 1.0
06-25-10

Abstract
Size of new designs has grown so much that it easily allows
creation of the entire system containing microprocessor unit
and peripherals on one chip. Verification of such designs can
no longer rely on software only, since simulation of MPU does
not allow fast enough testing of application software and formal
tools handle system hardware only.
The use of FPGA-based prototyping boards creates fast and
economical solution to this problem. This paper presents one
practical implementation of Prototyping Board Verification and
Integration Platform.
 Using FPGA Prototyping Board as SoC Verification and Integration Platform

Table of Contents
Using FPGA Prototyping Board as SoC Verification and Integration Platform ....................................................... 1
Abstract ........................................................................................................................................................ 1
Table of Contents ................................................................................................................................................ 2
Transaction Level Modeling (TLM) in SoC design flow. ...................................................................................... 3
Architecture analysis .................................................................................................................................... 3
Functional verification ................................................................................................................................... 4
Hardware and software integration .............................................................................................................. 4
Transaction Level Modeling (TLM). ................................................................................................................. 4
System Architects ......................................................................................................................................... 5
Software Developers .................................................................................................................................... 5
Hardware Designers ..................................................................................................................................... 5
Verification Engineers................................................................................................................................... 5
Functional Verification of RTL with TLM .............................................................................................................. 5
SCE-MI Standard for Building Transactors ...................................................................................................... 6
Transaction Level (TL) Testbench with SCE-MI and HDL Co-Simulation ....................................................... 7
Hardware Software co-verification with RTL ....................................................................................................... 7
Mapping ASIC to FPGA Prototyping Board ..................................................................................................... 8
Debugging SoC Emulated on FPGA Board ..................................................................................................... 9
Memory Debugging ...................................................................................................................................... 9
Processor Debugging ................................................................................................................................. 10
SoC Hardware Debugging ......................................................................................................................... 11
Summary............................................................................................................................................................ 12
About HES™ ..................................................................................................................................................... 13
About Aldec, Inc. ................................................................................................................................................ 13

Rev. 1.0 ©2010 Aldec, Inc.

06-25-10 Page 2 www.aldec.com
 Using FPGA Prototyping Board as SoC Verification and Integration Platform

Transaction Level Modeling (TLM) in SoC design flow.

With the advance of sub-micron semiconductor technology, ASIC design has migrated towards integration of
complete systems on a single die called System on Chip (SoC). Such systems comprise of microprocessors,
complex arbitrated buses, multiple masters and slaves on hardware site but also complete embedded software
(Figure 1). Benefits of this change are significant and span from lower production costs, through better physical
characteristics like speed and power dissipation, to much more advanced functions offered to end customers in
a shorter time.

Embedded
Software

CPU Mem Custom-IP

Interrupt
Arbiter
Controller

Co-processor DMA Bridge

DSP Mem Embedded

Software

Figure 1: Complex System on Chip Architecture

This technology breakthrough however generated several problems in the classic design and verification
processes of ASIC projects.
Architecture analysis
In the classic design flow architecture analysis was either not needed or performed only in a limited scope.
Architecture analysis was based on paper written specification document. Several performance calculations
were performed with spreadsheets and sometimes algorithmic models were developed to measure algorithm
performance.
Such methods are not sufficient anymore for complex SoCs, where system architect has to make early
decisions on which system components will be realized as software and what should be designed as hardware
IPs. Thus system architects have to accomplish following tasks before any hardware implementation and
software development starts:
Finding optimal HW/SW partitioning,
Finding optimal HW architecture of SoC (identify SoC components, on-chip bus configuration,
bandwidth etc.),
System performance analysis and controlling real time constraints and parameters imposed by
specification.

Rev. 1.0 ©2010 Aldec, Inc.

06-25-10 Page 3 www.aldec.com
 Using FPGA Prototyping Board as SoC Verification and Integration Platform

Functional verification
Functional verification assures that the SoC implementation is compliant with ASIC specification, usually
available as a written paper document. Thus, verification engineers not only have to prepare test harness and
test scenarios but also determine expected results – everything based on written specification documents. This
is a tedious and time consuming task that explodes with growing complexity of SoC. It is not unusual that the
functional verification takes from 50% to 70% of SoC design schedule.
Hardware and software integration
The traditional design flow postpones hardware and software integration until the ASIC prototype is ready. With
constantly shrinking time-to-market requirements this is significantly too late. If some hardware bugs are
identified during software integration phase then it is usually too late for hardware changes. In order to avoid
costly re-spins designers have to find sophisticated software workarounds, quite often sacrificing system
performance or some functions that could be key differentiators for their product. It is highly desirable to start
hardware software integration and co-verification much earlier.

Transaction Level Modeling (TLM).

Since 1990 several ASIC companies and IC design houses were researching that area with EDA vendors to find
a new methodology that would address problems identified with classic design flow. It was apparent that a new
abstraction level, above Register Transfer Level (RTL), is needed to create a system model that would be
available for software developers and system architects much earlier in design cycle. So the system model
should be fast to execute with little overhead of development efforts but providing enough accuracy to execute
with embedded software or to perform architecture analysis. These efforts resulted in TLM methodology. Except
methodology, we also have basic means such as SystemC – the C++ based HDL, with its concepts of
separating algorithms from communication, and TLM classes providing uniform communication layer for
transactions. Other transaction level methodologies based on SystemVerilog HDL have been developed
concurrently.
A new SoC design flow involves development of TLM model of entire system at the beginning of the project. The
TLM model is derived directly from system specifications. Such model, which is quick to develop because of its
higher abstraction level, is then used as a reference model throughout entire design implementation and
verification for all teams involved in the project (Figure 2).

SoC Architects
* Architecture Analisys
* HW/SW Partitioning

SW Developers SoC HW Designers

* TLM is used as golden
* Early SW development
* SW verification in complete TLM Model reference
* RTL checked against TLM
* SoC model

Verification Engineers
* Test harness
* Test scenarios
* TLM provides expected
response

Figure 2: Design and Verification Centralized around TLM model

Rev. 1.0 ©2010 Aldec, Inc.

06-25-10 Page 4 www.aldec.com
 Using FPGA Prototyping Board as SoC Verification and Integration Platform

System Architects
The first team that interacts with SoC TLM (or even is involved to build) is the SoC Architects group. They
explore system architecture and finally provide a stable TLM model of hardware with hooks for software
developers. Thus, hardware software partitioning is well defined right after TLM model is ready. System
architects are able to evaluate initially SoC performance and propose optimum system architecture. Later when
software team provides embedded code, system architects can validate system parameters and their
assumptions in the TLM model.
Software Developers
These people have a complete yet accurate system model to run their software much earlier in the design cycle
comparing to classic flow where they had to wait until ASIC prototype is available.
Hardware Designers
As soon as hardware/software partitioning is determined hardware designers start RTL implementation. The
TLM provides high level hardware specifications and parameters that are a guideline to further elaborate
hardware structure. Throughout RTL development the TLM serves as a reference model for hardware
designers.
Verification Engineers
Having an executable specification is very beneficial also for verification engineers that can develop test
scenarios and simultaneously run tests to generate expected response i.e. “golden results”. This way they avoid
a time consuming development of testbench models that would generate expected response.
As a result of parallel development, centralized around TLM, the SoC components and verification environment
are ready much earlier and all components are consistent as they derive from common TLM model.

Functional Verification of RTL with TLM

When the RTL implementation process advances, the complete SoC composed of TLM and embedded software
is ready to simulate with Transaction Level testbench (Figure 3).

Test Generator & Scoreboard

SoC
Test TLM Model
Monitor
Driver
+
Embedded Software

Figure 3: SoC TLM verification environment

Later, the TLM will be replaced with bit level and cycle accurate RTL model. In order to reuse existing
verification environment transactors will have to be developed. Transactors will translate high-level messages
into bit-level, cycle-accurate data transfers (Figure 4). Comparing to benefits of parallel software development
and co-verification this additional effort is justified.

Rev. 1.0 ©2010 Aldec, Inc.

06-25-10 Page 5 www.aldec.com
 Using FPGA Prototyping Board as SoC Verification and Integration Platform

Test Generator & Scoreboard

SoC
Test
Transactor
RTL Model Transactor Monitor
Driver
+
Embedded Software
Figure 4: SoC RTL Co-Simulation with transactors.

SCE-MI Standard for Building Transactors

When developing transactors it is essential to choose a proper standard to make the design portable and
reusable. The SCE-MI (Standard Co-Emulation Interface) seems to be the most useful here as it is provided by
many EDA vendors and currently supported by Accellera organization. Design with SCE-MI interface can be
simulated either in HDL simulator or run on emulators. For example Aldec Inc., the leading EDA supplier offers
all tools and interfaces for both.
The transactor, which is useful for emulation should be designed with SCE-MI macro based interface, where
messages are exchanged via SceMi Message Ports. There are two types of SceMi ports: Input and Output.
They are using simple TransmitReady/ReceiveReady handshake. The message is transported via a bit-vector
port named Message. Complete transactor will include a state machine that translates messages to a bit-level
interface of SoC (Figure 5). This could be for example data transfers over on-chip bus (e.g. AMBA with ARM-
centric designs).

TransmitReady TransmitReady
SceMi SceMi
ReceiveReady
Out In ReceiveReady
Message Message
Port Message Message Port

Transactor

SceMi
In/Out Transactor
Message Core
Ports

Figure 5: SCE-MI macro based transactor.

Rev. 1.0 ©2010 Aldec, Inc.

06-25-10 Page 6 www.aldec.com
 Using FPGA Prototyping Board as SoC Verification and Integration Platform

The transactor is implemented as VHDL or Verilog module. It is also important to design transactors or more
precisely its Transactor Core part as a synthesizable RTL. This would enable running entire SoC together with
transactors in a hardware prototyping board.
The SCE-MI reference manual defines also C++ API that can be used inside SystemC testbench to access
SceMi Message Ports in HDL transactors. The API provides read and write methods to transfer messages
between the TL testbench and the SoC RTL model. The EDA vendor that provides a SCE-MI compliant
infrastructure assures proper communication of SystemC testbench with the HDL design.

Transaction Level (TL) Testbench with SCE-MI and HDL Co-Simulation

Aldec with its HES™ and Riviera-PRO™ products provides a complete solution, which is compatible with SCE-
MI. Using Aldec's Riviera-PRO simulator with SCE-MI Simulation (SMS) plug-in; you can easily co-simulate your
TL testbench with HDL implementation of SoC.
If the TL testbench was based on SCE-MI API you don't need to change anything in it. Otherwise you will have
to develop simple Proxy classes that implement translation layer between abstract types in your testbench and
SceMi messages transported by SCE-MI API (Figure 6).

C++, SystemC + TLM, OSCI simulator

Test Generator & Scoreboard

SCE-MI
SCE-MI
Proxy
Test Proxy
For Monitor
Driver SCE-MI API For
Test
Monitor
Driver

SCE-MI
Simulation
plugin

SoC
Transactor
RTL Model Transactor

+
Embedded Software

HDL Simulator, Riviera-Pro

Figure 6: TLM Testbench and HDL co-simulation environment.

Hardware Software co-verification with RTL

The co-simulation environment is very convenient to run some basic tests or to verify interfaces. However, HDL
RTL simulation slows down verification to an unacceptable level for software developers. In order to benefit from
Rev. 1.0 ©2010 Aldec, Inc.
06-25-10 Page 7 www.aldec.com
 Using FPGA Prototyping Board as SoC Verification and Integration Platform

powerful TLM methodology at the final SoC integration stage, it is desirable to employ a solution faster than
HDL simulation.
Traditional emulation systems might help here but these are very expensive resources, frequently not available
in the company or reserved for another projects. Aldec comes with another idea of reusing typical FPGA
prototyping boards for emulation purposes. An example of such a board would be one from the Dini Group
portfolio (Figure 7). It provides about 24 million ASIC gates capacity.

Figure 7: The Dini Group FPGA Prototyping Board DN8000K10.

Aldec provides all necessary interfaces to hook this board to the PC workstation either on Linux or MS
Windows® operating systems. Additional daughter board with PCI Express controller is used to provide physical
communication channel between prototyping board and the testbench running in the workstation.
Such boards are orders of magnitude cheaper than classic emulators, and provide much better performance.
Another benefit would be the possibility to reuse this board for high speed prototyping. Actually every design
house should already have such kind of boards in their inventory.

Mapping ASIC to FPGA Prototyping Board

If you decide to use FPGA board for SoC co-emulation with TL testbench you will certainly come to obstacles
with SoC design compilation for FPGA. This task is fairly straightforward when dealing with small size ASICs,
that fit in a single FPGA, but partitioning and partition interconnection dilemma might overwhelm even
experienced engineering teams. Not mention about ASIC clock structures or ASIC memory macro cells mapping
to FPGA. Certainly it would be a time consuming and costly process.
Aldec addresses these issues providing DVM (Design Verification Manager) software that is used to convert
ASIC design into multi-FPGA emulation. The DVM will automatically convert ASIC clock gating circuits to FPGA-
proof clocking structures. The same with mapping of on-chip memories, that additionally will implement a
debugging interface.
Finally the DVM will partition your design automatically and implement inter-chip multiplexed connections.
DVM starts with RTL source code of SoC and finishes with complete emulation setup that contains all FPGA bit-
files and SCE-MI configuration file (Figure 8). Intermediate steps automated by the DVM include:
Design synthesis run incrementally. DVM runs 3rd party synthesis tools like Synopsys® Synplify
Premier™ or Xilinx® XST
Design instrumentation for static and dynamic debugging
ASIC clock tree conversion to FPGA
Mapping ASIC memories to FPGA or to external RAM resources (on-board DDR SDRAM)

Rev. 1.0 ©2010 Aldec, Inc.

06-25-10 Page 8 www.aldec.com
 Using FPGA Prototyping Board as SoC Verification and Integration Platform

Design partitioning and inserting multiplexed interconnections

Connecting external interfaces to on-board connectors
Running FPGA place & route

Figure 8: Aldec DVM used to automate setup of emulation in FPGA.

Debugging SoC Emulated on FPGA Board

The speed advantage of using FPGA emulation would be nothing without tools that improve design debugging
capabilities. As the SoC has a hardware / software dual nature the two engineering teams have different
expectations.
It is obvious that software developers are the primary users of this co-emulation platform as this is the first
chance for them, in the design process, to run embedded software in target hardware with cycle and bit-level
accuracy. Thus software engineers would appreciate:
1. Ability to upload compiled embedded software and data to SoC RAM at initialization or in runtime
2. Watching system memory contents
3. Debugging CPU in context of C/C++ source code use of software debugger like GDB or other
proprietary

Memory Debugging
The first two requirements are fulfilled by Aldec's HW Debugger tool that comes in package with DVM software
(Figure 9). It allows viewing or even modifying on-chip memory contents during emulation. If you have mapped
any design memories using DVM tool, during design setup, you would be able to browse such instances in HW
Debugger to view or modify their contents. HW Debugger communicates with the emulator via MMU API. This
API is a C/C++ API and is also available for user. Aldec customers typically use MMU API in their TL testbench
to initialize memory contents at the beginning of emulation.

Rev. 1.0 ©2010 Aldec, Inc.

06-25-10 Page 9 www.aldec.com
 Using FPGA Prototyping Board as SoC Verification and Integration Platform

Figure 9: Debugging embedded RAM with HW Debugger.

Processor Debugging
Debugging of CPU and embedded software is another case. Usually the embedded processor contains all
necessary debugging interfaces. The question is how to hook the debugger with this interface.
For example the ARM core contains a debugging interface that can be accessed over JTAG port. In order to use
this port it is required to pull it out of the emulator and connect to on-board connector. This can be also achieved
easily with DVM that provides access to on-board connectors and allows connecting any internal or external
design signals. With processor debugging port drown to the on-board connector it is possible to hook any
external debugger. For example one of Aldec customers connected this way Lauterbach TRACE32 to the SoC
with ARM-9 core and AMBA bus (Figure 10).

Figure 10: ARM® CPU core debugging with Lauterbach tools and SoC emulated in FPGA.
The ARM® core natively supports an adaptive clock of JTAG port with the RTCK feedback. This mode resolves
a common issue with synchronization between emulation and external debugging instruments. The above
configuration obtained easily and without any additional development effort was a perfect platform for software

Rev. 1.0 ©2010 Aldec, Inc.

06-25-10 Page 10 www.aldec.com
 Using FPGA Prototyping Board as SoC Verification and Integration Platform

developers that could interact with a real hardware of complete SoC when integrating low level drivers as well
as booting RTOS and user applications.
SoC Hardware Debugging
Even though software developers would occupy the emulation platform most of the time it is also required to
have some generic hardware debugging capabilities. This is especially true if running software tests would
trigger hidden hardware bug. Such a situation is hard to repeat in HDL simulation or TLM / HDL co-simulation
environment, so hardware debugging is indispensable. Unfortunately, vendors of FPGA prototyping boards do
not provide convenient tools for debugging. Traditionally, hardware designers had to tackle with logic analyzers
connected to the board or in the best case on-chip logic analyzers supplied by FPGA vendors. Both tools
provide limited control and visibility to the design.
Aldec addresses this disadvantage with complementary HW Debugger tool. The tool provides both static and
dynamic debugging increasing design visibility to the level which was available only in expensive classic
emulation systems. These are highlights of Aldec's HW Debugger:

Advanced Logic Analyzer (ALA)

Allows tracing static probes in multiple FPGAs. It provides advanced triggering functions and is able to save
ASDB (Aldec) and FSDB (Springsoft) waveform files. Continues capture mode and automatic re-triggering
increases significantly amount of debugging data comparing to traditional on-chip logic analyzers.

Dynamic Debugging (DD)

Debugging of any internal registered signal; a set of debugging probes can be changed dynamically without
stopping emulator. HW Debugger re-maps raw hardware data to hierarchical signals in context of original HDL
design structure.

Hardware Breakpoints
It is possible to set hardware breakpoint in a similar way as setting static debugging triggers. When the
breakpoint was hit the emulator is stopped waiting for user interaction. For example you can enable capturing of
dynamic debugging probes or add more signals for capturing.

Integration with SpringSoft® Siloti™/Verdi™

Siloti™ and Verdi™ are advanced hardware debugging tools that allow tracing design signals in context of
original RTL source code. Aldec's HW Debugger is capable of generating input to SpringSoft® tools in form of
FSDB waveform. Even though HW Debugger in dynamic debugging mode can capture only registered signals,
the Siloti tool can expand this to provide 100% design visibility.
Aldec's HW Debugger connects to the board via TCP/IP interface so that the emulation board can be accessed
from any computer in the corporate LAN (Figure 11). This interface is integrated with SCE-MI API provided by
Aldec so no additional effort is required to enable this tool. If only you have prepared your emulation with DVM
and enabled DD or ALA features you can control your emulation from HW Debugger.

Rev. 1.0 ©2010 Aldec, Inc.

06-25-10 Page 11 www.aldec.com
 Using FPGA Prototyping Board as SoC Verification and Integration Platform

Figure 11: HW Debugger interface to emulator.

Summary
Transaction Level Modeling is new and promising methodology. It solves many problems in design and
verification of complex SoCs. The major benefit is integration of different design teams around a common TLM
model of SoC, which can be created quickly at the beginning of design flow. Next the TLM model of SoC is used
as a golden reference model by hardware architects, software developers, hardware designers and verification
engineers. This allows starting SoC integration phase much earlier and finally cut the total design and
verification time.
The TLM model speeds up SoC software development and testing, however the integration is not complete until
all the software is run in target hardware environment. Real time hardware/software co-verification is not
possible in HDL simulation environment because of low execution speed. The two other options are either wait
for ASIC prototype or use classic emulation box.
Waiting for ASIC prototype or using classic emulation systems might be too expensive. Thus many design
teams seek for incorporating FPGA platforms to run their designs and finally integrate SoCs hardware and
software.
Aldec provides a unique solution to support those engineers. With DVM tool the SoC can be translated
automatically to the multi-FPGA emulation. With SCE-MI interface and infrastructure provided with DVM,
emulation can be connected to existing TL Testbench. Additional tools like HW Debugger fill the gap in FPGA
board debugging capabilities. A complete TLM + RTL co-emulation and hardware/software co-verification
environment is shown on Figure 12.

Rev. 1.0 ©2010 Aldec, Inc.

06-25-10 Page 12 www.aldec.com
 Using FPGA Prototyping Board as SoC Verification and Integration Platform

Figure 12: Complete SoC Hardware/Software co-verification environment with TLM and FPGA emulation.

About HES™
HES ™ is a patented in-circuit and transaction-level Hardware Emulator. HES-Emulator can handle large,
complex ASIC, SOC and FPGA designs, up to 32Million ASIC gates. HES-Emulator uses hardware boards
from Synopsys® HAPS™, The Dini Group or Aldec and includes Transaction Level Modeling (TLM),
SystemC/C/C++ and SCE-MI for fast-logic emulation. The Aldec advantage includes: automated design setup,
clock conversion and design partitioning for ultra-fast debugging using brand-leading tools such as Xilinx®
ChipScope™, SpringSoft® Verdi™, Siloti™. The product feeds selected test points from Synopsys® or The
Dini Group hardware supporting Altera® and Xilinx® FPGA devices, into waveform viewers of leading
simulators including Active-HDL™, NC-Sim®, ModelSim®, Riviera-PRO™, VCS® and can accelerate ANY
simulation performance 10Xor more. HES ™ is patented with HES™ Hardware Embedded Simulation
technology, Technology Patent no. 5,479,355 and 7,003,746. For additional product information, visit
http://www.aldec.com/products/hes

About Aldec, Inc.

Aldec, Incorporated, established in 1984, is committed to delivering best-in-class verification solutions to
government, military, aerospace, telecommunications, automotive and industrial customers. Aldec offers a
patented technology suite including: design entry, HDL simulators, co-simulation, design rule checking,
hardware-assisted verification, co-verification, IP Cores, DO-254 compliance tool sets and engineering specialty
solutions. Continuous innovation, superior product quality and total commitment to customer service comprise
the foundation of Aldec’s corporate mission. For more information, visit www.aldec.com

Rev. 1.0 ©2010 Aldec, Inc.

06-25-10 Page 13 www.aldec.com