| Technology Update|
SystemC or SystemVerilog?
Today’s chip design requires extensive system-level simulations to ensure that the right architectural
trade-offs are made. In most cases these simulations require that a substantial amount of software is
executed on the simulation model of the chip to cover the required functionality. To perform these
simulations with adequate performance, design architects increasingly leverage abstract, transaction-level
models instead of RTL models to perform such analysis.
The concept of transaction-level modeling (TLM) has been around for a while, and many companies and
organizations today are looking for standards to help ensure portability and interoperability of models. Even
though some early standardization has already taken place, for example the OSCI (Open SystemCTM
Initiative) TLM standard library created just last year, TLM methodologies are still in their early stages on
the adoption curve.
This article takes a practical view of transaction-level modeling. It looks at two broadly supported, industrystandard languages, IEEE 1666 SystemC and IEEE 1800 SystemVerilog, and explores how they support
the concepts of TLM. It further explains how Synopsys’ verification solutions can leverage the strengths of
each language, and shows how a well-engineered transaction-level (TL) interface between SystemC and
SystemVerilog offers a modeling solution today that can accelerate the adoption of TLM by providing
portability and interoperability of TL models.
Whereas in the past chips were assembled and analyzed at the RT level, where every individual logic
function and signal is exposed, TL models describe the system in terms of abstract operations (transactions)
between functional units. These transactions typically are read/write or transmit/receive operations
operating on complete data structures (or objects) that are being exchanged between the functional units.
TL models simulate orders of magnitude faster then RTL models. First, not modeling the functionality of
each individual hardware signal, but instead operating on abstract data types (possibly representing many
individual signals), speeds up simulation substantially. Secondly, using an abstract data type to represent
multi-cycle data transfers in the RTL can speed up simulation even more. Hence, with these factors
combined, it is not uncommon for a TL model to run 100 to 1,000 times faster than the equivalent RTL
model, sometimes even faster.
While today the RT level of abstraction is well understood, this is not true for TLM. Actually, the right TL
abstraction level often depends on the application domain and purpose of running the simulation in the first
place. Some applications require cycle accuracy — for example to analyze detailed cache behavior. Some
might even require linking in RTL models as part of the development flow, while other applications (typically
software development tasks) only need functional accuracy.
Different answers may arise when asking in what language TL models should be written. Some engineers
on the project, specifically those with a software background, often prefer C/C++ or SystemC as the TLM
language while other engineers on the project, coming more from a hardware design background, may
prefer Verilog, SystemVerilog or VHDL.
Given these diverse requirements for TLM, this article takes a practical approach to ensure that most, if not
all, engineers are well supported and can cooperate on a common simulation model. With both SystemC
and SystemVerilog widely used today, standardized by the IEEE, and supported by a broad range of tools
from EDA vendors, a combined SystemC/SystemVerilog flow implemented with Synopsys’ System Studio
and VCS® can address the widest possible interpretation of transaction-level modeling and engineer
SystemC is a flexible, object-oriented architectural modeling language designed for multiple abstraction
levels, including TLM. SystemC is implemented as a C++ library that incorporates concurrency in the
traditional C++ linguistic framework.
While the SystemC language is relatively young, the adoption of SystemC is remarkable. One of the reasons is
that, before SystemC emerged as a standard, many companies and universities had been modeling systems
at a transaction level with their own proprietary C/C++ libraries. So SystemC offered these designers a
standard way to conduct their TL methodology work, while offering an easier way to exchange system-level
IP and knowledge. A second reason is that SystemC enables a relatively easy integration of a variety of
(C-based) tools and simulators such as instruction-set simulators (ISSs) for microprocessor cores, and the
ability to tap from a large pool of C++ experts to easily get up to speed with the language.
This also accounts for the typical usage of SystemC – from the recent publications on SystemC as well as
from surveys, for example by Doulos – the vast majority of SystemC users are using it for performance
modeling (68%), architectural exploration (68%), transaction-level modeling (56%), and hardware-software
co-simulation (56%). Originally developed within OSCI, the SystemC Language Reference Manual (LRM)
was recently approved as the IEEE 1666 standard.
SystemVerilog is built on the widely successful Verilog language and has emerged as the next-generation
hardware design and verification language. SystemVerilog combines concepts from Verilog, VHDL and C++,
but also from testbench and assertion languages such as OpenVeraTM, combining hardware description
languages (HDLs) with modern hardware verification languages (HVLs). This concept and its upward compatibility
with Verilog make it especially attractive to hardware verification engineers who need to verify
today’s highly complex designs. Another success factor for the adoption of SystemVerilog for verification
is the early availability of methodology guidelines and frameworks, such as the testbench methodology described
in the Verification Methodology Manual (VMM) for SystemVerilog, as developed by ARM
All these features, and the fact that SystemVerilog is an IEEE standard, supported by all major EDA
vendors, have made SystemVerilog indeed the language of choice for hardware design and verification.
SystemC and SystemVerilog
Looking at the two languages SystemC and SystemVerilog it is obvious that SystemC extends the C++
scope towards hardware, while SystemVerilog extends the Verilog scope to object orientation and testbenches.
Both languages support concepts such as signals, events, interfaces, and object orientation, yet
each language has its distinct application focus:
- SystemC is effective for writing abstract TL models for architectural exploration or performance
modeling, specifically for teams with a strong C++ background and especially in the context of
C/C++-based IP integration (such as processor simulators), and for creating virtual prototypes for
early software development.
- SystemVerilog is effective for designing advanced testbenches, for both RTL and TL models, since it
comes with the infrastructure needed for this task, such as constrained-random stimuli generation, functional
coverage, and assertions.
- And clearly, SystemVerilog is the language of choice for describing the final RTL design itself, not only
for its abilities to describe the actual hardware and assertions, but also because of the extensive
tool support available
That is not to say that each language cannot be used in different applications. SystemVerilog is entirely
appropriate for TLM, since it contains all the constructs necessary to describe and execute TL models ef-
ficiently. Verification engineers with a strong hardware background may prefer to use SystemVerilog rather
than SystemC to write TL models.
A SystemVerilog testbench can be used to verify TL models written in SystemC as well as TL and RTL models
written in SystemVerilog. SystemC also can be used to write testbenches, although constrained-random
stimuli generation and functional coverage are much more advanced in the tools supporting SystemVerilog.
The best productivity is achieved when each language is used at its application focus. This especially holds
for complex projects, where different tasks fall into different groups, often with different skill sets. The pragmatic solution, one that fits many skill-set profiles for design teams, is to use both SystemC and SystemVerilog
provided that an effective interface between them exists. Such an interface is provided in the Synopsys
Discovery™ Verification Platform with VCS and System Studio.
An Integrated Simulation Environment
Integrating SystemC and SystemVerilog in a single solution boils down to providing a mixed SystemC/SystemVerilog
simulation and debugging environment. The heart of such integration is the ability to call a SystemC
method directly from a SystemVerilog task and, vice versa, to call a SystemVerilog task directly from
within a SystemC method. Clearly this requires synchronization between the concepts of time in SystemC
In order to build efficient integrated solutions with SystemC and SystemVerilog, the languages have been
designed so that the underlying concepts such as signals and transactions, although in each language
optimized for their own usage, are semantically sufficiently close to enable an efficient mapping across the
language divide. In fact, the original standardization bodies recognized this as a requirement to build efficient
interfacing mechanisms between the two languages. The core of SystemC/SystemVerilog integration thus
supports a mixed-level modeling paradigm with the ability to create simulation models that are partly at the
transaction level and partly at the detailed hardware level. Hence, the integration enables SystemVerilog and
SystemC to communicate at different levels of abstraction.
A typical application example is the integration of a SystemVerilog RTL block into a SystemC model of the
entire system, perhaps for early integration checking. Since SystemC is typically used at the transaction
level, an adapter that serves as a bridge between the abstraction levels, as shown in Figure 1, is necessary.
Figure 1. Adapters form a bridge to connect abstract transaction-level models to
signal-level modules. Adapters can be written in either SystemC or SystemVerilog.
The purpose of these adapters is to translate transactions to signal behavior and vice versa. This allows
parts of the design to be simulated at the transaction level while other parts of the design are simulated on
the detailed hardware level. This way, designers have full control over the level of detail required for their
These adapters can be written in SystemC (as shown in Figure 1) or in SystemVerilog. Using a SystemC
adapter is fairly straightforward, based on mapping SystemC signals to SystemVerilog signals and vice versa.
Writing adapters in SystemVerilog, which typically gives higher performance, requires a transaction-level
interface between SystemC and SystemVerilog.
A Transaction-Level Interface between SystemC and SystemVerilog
In SystemC, the objective of separating communication and functionality has led to the concept of
interfaces. In SystemVerilog, a similar concept of interfaces has been designed into the language as well.
Although SystemVerilog interfaces and SystemC interfaces are not identical, they are semantically close
enough to represent an effective transaction-level link between the two languages. A SystemVerilog
interface is a structure that can bundle signals and have interface methods just as in a SystemC interface.
By using a SystemVerilog service layer based on the Direct Procedure Interface (DPI), a verification
engineer can directly map SystemC interfaces on SystemVerilog interfaces and thus access SystemC
transaction-level models directly from a SystemVerilog testbench.
Example 1 shows part of a blocking interface of the simple_bus in SystemC as described in System Design
with SystemC. It declares the interface method burst_read. The complete code for the simple_bus can
be found in any installation of SystemC 2.x. How the simple_bus implements the interface methods, for
example what type of bus bandwidth is used or what type of arbitration is used, is invisible to the caller of
the interface methods and hence can be easily changed for architectural exploration.
Example 2 shows a part of a SystemVerilog interface for the simple_bus that can be mapped directly to the
SystemC interface shown in Example 1. To ensure correct mapping of the SystemVerilog interface to the
SystemC methods, the DPI service layer, a standard feature of the SystemVerilog, can be used.
This enables calling the interface methods of a SystemC interface directly from a SystemVerilog testbench,
as shown in Example 3.
With this capability, the verification team can take full advantage of the SystemVerilog testbench technology
to verify SystemC TL models, and use SystemC TL models as reference models in the hardware verification
process, as sketched out in Figure 2. In addition, the native SystemVerilog functional coverage metrics
and assertions can be used to implement a complete coverage-driven verification solution for TL models,
providing new and unprecedented verification capabilities for SystemC models.
The layered testbench architecture and transaction-level abstraction services provided by VMM enables an reusable, maintainable and scalable implementation of this approach to functional verification.
Figure 2. SystemVerilog testbenches can verify both transaction-level and
hardware models of a design.
Synopsys’ Discovery Verification Platform is a prime example of such an integrated verification environment
with built-in support for both SystemC and SystemVerilog. It provides high-performance RTL verification,
including simulation and formal analysis, architectural development, and the extensive testbench support
required to build an infrastructure to handle verification for TLM.
SystemC is a language very well suited to create, simulate, and analyze transaction-level models of the
design. SystemVerilog is ideal for capturing the hardware implementation and the verification environment,
and may be preferred by some verification engineers for TL models. A well-implemented integration of
SystemC and SystemVerilog enables the verification of mixed (transaction and hardware) models. Furthermore, this integration allows the powerful features of SystemVerilog for verification – and the transaction-focused VMM – to be fully leveraged for transaction-level model verification, while the same testbenches are used for hardware verification.
By bringing SystemC and SystemVerilog together in a single modeling and verification environment,
architectural exploration and tradeoffs can be made before the final hardware-software partition is settled.
Further, software can be developed early in the project cycle and also verified to operate correctly in the
context of the architecture as well as the hardware.
 SystemC in Europe - Current Usage and Future Requirements, John Aynsley, 40th Design Automation
Conference, June 2003.
 IEEE RATIFIES SYSTEMC 2.1 STANDARD FOR SYSTEM-LEVEL CHIP DESIGN, http://standards.ieee.
org/announcements/pr_p1666.html, December 2005.
 Verification Methodology Manual for SystemVerilog, Janick Bergeron, Eduard Cerny, Alan Hunter and
Andrew Nightingale, Springer Science+Business Media, 2005.
 IEEE APPROVES SYSTEMVERILOG® and VERILOG® STANDARDS FOR ELECTRONIC DESIGN,
http://standards.ieee.org/announcements/pr_p1364-1800.html, November 2005.
 System Design with SystemC, Thorsten Grötker, Stan Liao, Grant Martin and Stuart Swan, Kluwer Academic
©2010 Synopsys, Inc. Synopsys and the Synopsys logo are registered trademarks of Synopsys, Inc. All other company and product names mentioned herein may be trademarks or registered trademarks of their respective owners and should be treated as such.