Transaction-Level Modeling: SystemC and/or SystemVerilog

March 6, 2006 — 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. This article takes a practical view of transaction-level modeling. It looks at two well-accepted design languages, SystemC and SystemVerilog, and explores how they support the concepts of TLM. It further explores how today’s verification tools 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.

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 SystemC Initiative) TLM standard library created just last year, TLM methodologies are still in their early stages on the adoption curve.

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 other industry organizations, and supported by a broad range of tools from EDA vendors, a combined SystemC/SystemVerilog flow 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 modeling 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 likewise is a rather new language 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 languages and assertion languages, 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. 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.

This 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 efficiently. 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.

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.

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 of SystemC and SystemVerilog, OSCI and Accellera, respectively, have 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.

The example below shows part of a blocking interface of the simple_bus in SystemC as described in [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.

 

The example below shows a part of a SystemVerilog interface for the simple_bus that can be mapped directly to the SystemC interface shown in the above example. 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 the following example.

 

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.

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

By Rindert Schutten and Janick Bergeron, Synopsys, Inc.

[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, 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, November 2005.
[5] System Design with SystemC, Thorsten Grötker, Stan Liao, Grant Martin and Stuart Swan, Kluwer Academic Publishers, 2002.

Source:

http://soccentral.com/results.asp?EntryID=18241