April 2, 2007 -- System-on-chip (SOC) verification has become more complex than ever as applications converge to offer more features for consumer products. This new level of complexity is presenting SOC development teams with many challenges including verifying their designs in a mixed-language and mixed-abstraction level environment while meeting compressed schedules. Two languages in particular are increasingly popular for SOC development: IEEE Std 1800 SystemVerilog with its advanced verification, modeling and hardware design capabilities; and IEEE Std 1666 SystemC, with powerful modeling features and tight links to the C/C++ programming languages. The challenge faced by many SOC teams is how to use these languages together for mixed-language, mixed-abstraction level verification.

Mixed abstractions come from the fact that designers often develop models at the transaction level to capture the correct architecture and analyze the system performance fairly early in the design cycle. Various components of an SOC developed with high level languages such as C, C++, SystemC, and SystemVerilog are increasingly in demand and for obvious reasons. They are faster to write and faster to simulate. These components are also known as high level reference models. Typically, they are used to capture design specifications early in the design cycle, and then refined to lower levels of abstraction required for synthesis. High level reference models became increasingly important in verifying the implementation details at the RTL level.

Mixed-language environments using SystemC and SystemVerilog are becoming more common due to the growing complexity of the verification challenge and the growing size of verification teams. Both languages are positioned to address the need to abstract the communication behavior and separate communication from control, hence, creating a true IP re-use environment for speeding up designs. SystemC and SystemVerilog are both suitable for writing efficient transaction level models. The use of either language depends heavily on the engineer’s background and expertise.

Typically, engineers with C/C++ expertise use SystemC for its natural extension to C++. The majority of these engineers would be the system architects and analysts. On the other hand, engineers with RTL and verification background tend to use SystemVerilog for its natural extension to Verilog. One common scenario is for SystemVerilog to be used for creating the overall verification environment, while SystemC is used for high-level reference models. This paper explores techniques for integrate a SystemC reference models into SystemVerilog verification environments.

Limitations of the SystemVerilog direct programming interface (DPI)

Integrating a reference model written in SystemC to a verification environment written in SystemVerilog requires some sort of defined, programmatic interface. In the past, this was achieved with PLI, sockets or pipes. These approaches suffered from performance and other bottlenecks. The SystemVerilog language standard defines a Direct Programming Interface (DPI) which alleviates many of these bottlenecks.

DPI is part of the SystemVerilog standard. It’s an efficient interface between SystemVerilog and a foreign programming language. By the use of the “import” and “export” constructs DPI lets SystemVerilog call a C function just like any other native SystemVerilog function and task. Its benefit is that it significantly reduces the complexity of interfacing to C models.

In a mixed SystemVerilog/ SystemC environment, DPI is recommended for non-time-consuming functions that don’t require blocking calls. In simple terms, DPI is ideal for passing SystemVerilog data between the two domains through function arguments and results. There is no intrinsic overhead in this interface. DPI imported and exported functions are assumed to complete their execution instantly at zero simulation time.

The SystemVerilog DPI was targeted primarily for calling C functions and not SystemC. This introduces several challenges when trying to integrate SystemC class methods via DPI. First, DPI cannot be used to traverse hierarchy where handles to instances or objects are not possible. Second, DIP cannot call blocking (i.e., time consuming) SystemC methods with a wait(10, SC_NS) statement. Third, other SystemC processes must continue while one is suspended in blocking export-DPI task. DPI also provides no means of synchronization other than by data exchange and explicit transfer of control. These limitations make it difficult if not impossible to interface a SystemC cycle accurate, time consuming model in a SystemVerilog environment.

Transaction Level Interface for integrating SystemC models

Synopsys’ VCS functional verification solution addresses the challenge of integrating SystemC reference models with its SystemC-SystemVerilog Transaction-Level Interface (TLI). Using TLI SystemC interface methods can be invoked in SystemVerilog and vice versa. This provides an automated, transaction-level link between both languages.

Both SystemC and SystemVerilog have concepts of interfaces. An interface separates the communication from its implementation. SystemC interfaces are implemented using C++ classes (methods associated with the data member of the class) and SystemVerilog languages itself consists of interface construct defining set of signals and associated methods. Semantics of interfaces in both the languages are identical.

The automated generation of the communication code alleviates the difficulties in implementing a synchronized communication mechanism to fully integrate transaction-level, cycle-accurate SystemC models into a SystemVerilog environment using DPI.

SystemVerilog allows for the creation of powerful, reusable layered testbench architectures. The VMM methodology, a de facto standard for creating SystemVerilog verification environments, provides such a layered architecture. With a layered approach, transaction-level reference models can be easily integrated at the appropriate level to provide self-checking functions. Figure 2 shows an example of VMM layered testbench verifying the DUT against the reference SystemC transaction-level model. The VMM Function layer is communicating with the SystemC model using the TLI mechanism to perform read/write transactions. The VMM command layer is driving the DUT at pin level.

Figure 1. VMM driving TLM and RTL with checking.

Now let’s take a look at the various code components in SystemC and SystemVerilog based on the VMM methodology that enables such a verification use model. In the following example we define the read and write transactions as SC Interface methods.

The following code shows the VMM Transactor invoking SC transactions read and write at the function layer. VMM transactor Class tb_mast is communicating to SystemC TLM using tb_mast_out_ch1 and with RTL model using tb_mast_out_ch2 channel, as shown in the following code:

The following code shows VMM reference Transactors calling the SystemC transaction functions.

The ultimate benefit of the SystemC-SystemVerilog TLI is to improve mixed-language, mixed-abstraction level simulation performance and speed-up the development of the verification environment.

TLI augments the pin-level interfaces to enable both languages to communicate at different levels of abstraction. Using this interface, one can simulate some part of the design at the transaction-level and the other part at the RT level, and have full control over the level of detail required for the verification process.

Conclusion

The SystemC-SystemVerilog Transaction Level Interface complements the SystemVerilog DPI, and enables easy integration of SystemC reference models in a SystemVerilog testbench. When the TLI is used in a layered VMM testbench, engineers can quickly and easily incorporate existing SystemC reference models to speed both development time and execution performance, helping to meet their ever-shrinking verification schedules.

By Dr. Nasib Naser

Dr. Nasib Naser is a Corporate Applications Engineer Manager for the Verification Group at Synopsys, Inc. He has extensive experience in system-on-chip design and verification, embedded systems design, computer architecture, and real-time operating systems. For several years, Nasib worked with companies, including Synopsys, which provide System Level Design technologies and tools based on C/C++ and later on Open Source SystemC and SystemVerilog.