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.

Transaction-Level Modeling
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 preferences.

SystemC
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^[1] – 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.^[2]

SystemVerilog
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,^[3] as developed by ARM and Synopsys.

All these features, and the fact that SystemVerilog is an IEEE standard,^[4] 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 and SystemVerilog.

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 simulations.

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.^[5] 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 1.

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.

Example 2.

This enables calling the interface methods of a SystemC interface directly from a SystemVerilog testbench, as shown in Example 3.

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.

Conclusions
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.

References
[1] SystemC in Europe - Current Usage and Future Requirements, John Aynsley, 40th Design Automation Conference, June 2003.

[2] IEEE RATIFIES SYSTEMC 2.1 STANDARD FOR SYSTEM-LEVEL CHIP DESIGN, http://standards.ieee. org/announcements/pr_p1666.html, December 2005.

[3] Verification Methodology Manual for SystemVerilog, Janick Bergeron, Eduard Cerny, Alan Hunter and Andrew Nightingale, Springer Science+Business Media, 2005.

[4] IEEE APPROVES SYSTEMVERILOG® and VERILOG® STANDARDS FOR ELECTRONIC DESIGN, http://standards.ieee.org/announcements/pr_p1364-1800.html, November 2005.

[5] System Design with SystemC, Thorsten Grötker, Stan Liao, Grant Martin and Stuart Swan, Kluwer Academic Publishers, 2002.

©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.