Today's semiconductor designs contain a good deal of mixed languages like SystemVerilog and SystemC. This paper describes an easy method of integrating these two languages, using TLM connections made via UVM Connect (UVMC). Using a UVMC example, this paper will demonstrate how to build, connect, and execute a verification simulation with SystemVerilog and SystemC.
With the increasing use of mixed language in today’s semiconductor and design industry, the question arises of how to effectively verify such complex designs. Thanks to the merger between the Open SystemC Initiative (OSCI) and Accellera, SystemC (SC) and the universal verification methodology (UVM) can be easily connected via TLM-1.0 and 2.0. This allows complex models in SystemC to help verify complex designs in SystemVerilog (SV).
UVM Connect was developed to make this process consistent and easy to debug. The hybrid SC-SV model enables abstraction refinements at various levels, SystemC being a sweet spot for high-level modeling. Reusing the stimulus generation agents in SV to verify models in SC can be made possible. Also, a key feature to be noted is that when there is no single language restriction for verification IPs, either SystemVerilog or SystemC versions may be used interchangeably. The strength of each language can be used to provide random verification for your model. And you can leverage the speed and capacity of SC for verifying untimed or loosely timed system-level environments. In this paper, we will discuss two examples1, one is a simple example dealing with TLM-1.0 and the other is a complex example with TLM-2.0.
Transaction level modeling (TLM) uses transaction-based methods which can be used for communication between modules. UVM offers TLM libraries such as ports, sockets, imp, and interface ports. The libraries branch into 2 versions, TLM-1.0 and TLM-2.0. As quoted in the IEEE std 1666-2011 IEEE Standard for Standard SystemC Language Reference Manual Page.415/Sec.10:
a. TLM-1.0 has no standard transaction class, so each application must create its non-standard classes, resulting in very poor interoperability between models from different sources. TLM-2.0 addresses this shortcoming with the generic payload.
b. TLM-1.0 has no explicit support for timing annotation, so no standardized way of communicating timing information between models. TLM-2.0 addresses this shortcoming with the addition of timing annotation function arguments to the blocking and non-blocking transport interface.
c. The TLM-1.0 interfaces require all transaction objects and data to be passed by value or const reference, and models created using it must generate a delay using "wait", which may slow down simulation in certain use cases. TLM-2.0 passes transaction objects by non-const reference, which is a fast solution for modeling memory-mapped buses.
TLM-2.0 library provides model interoperability for memory-mapped bus modeling, and it recommended that core interfaces, sockets, generic payload, and base protocol be used together in concert. They are collectively known as the interoperability layer. If the generic payload is inappropriate, the core interface and both the initiator and target connector can be used with a different type of transaction. TLM-2.0 communication is pass-by-reference, which we emulate in UVM Connect by copying the changes made to the original transaction object on return from each interface method call. TLM-2.0 rules require that the same transaction object be used until transaction execution is complete.