Utilizing SystemC/TLM for adapting block level

verification environment at System Level

Wasiq Zia, Cadence Design Systems, Noida, India (wasiqz@cadence.com)

Abstract— The ability to reuse verification environments and testcases from module level to system level
verification has been explored by verification teams at length. It is an important requirement with the growing size of
the SoCs and the associated verification environment. Ideally we would like to have a system where the verification
environment itself does not change while the stimulus generation mechanism can be altered. This would reduce the
time needed to stitch the verification environment at the system level while also providing flexibility in the way the
testcases are written. Along with reuse benefits this methodology also enables embedded testbenches that can be
connected to processor register interfaces. This paper proposes a methodology for adding a SystemC based TLM
layer to the verification component which can be used to direct traffic from the processor to these blocks without the
need for any high level stimulus generation mechanisms.

Keywords—verification component; TLM; Initiator Socket; target socket; System Level Testbench; Verification
environment reuse

I. INTRODUCTION
The motivation for this work was driven by the need to provide a mechanism which could enable verification
engineers to adapt existing IP level testcases and environments at the system level. System level verification has
a significant scope for reuse and recycle of the module level verification environments. Ability to have a single
verification environment that can be leveraged at different levels of the verification cycle using a common
testbench has been explored in detail.
Typically the intent of system level verification is very different from that of the IP level. While at the IP level
the verification is concerned with block and feature level details with coverage driven verification the main idea,
at the system level the concern is mainly to do with the flow and how the blocks are interconnecting and
behaving in a coherent manner. The IP level verification environments are written in HVLs like Specman or
System Verilog using methodologies like UVM and are specifically written in a way that stimulus can be
provided in a constraint random manner and directly to the block that is being verified.
At the system level the stimulus is predetermined and will not always be directly input to the block that needs to
be verified. Instead the stimulus will flow from one of the connecting blocks. For example in a typical SoC, the
processor will be scheduling the transaction through one of the associated interfaces like AXI, PCIe etc. Hence
adapting the PCIe module level traffic to system level will require some way of providing the stimulus through
the processor.

II. BACKGROUND
The TLM interface and systemC have been in use in the industry for some time now. They have been mostly
used for prototyping purpose and at transaction level modeling for designs. It is convenient to use SystemC
models in the earlier stages of development as they emulate the functional behavior at transaction level without
any need for pin interface definition and the data exchange can be done in a simulator event ignorant way. This
allows the definition of a model at a higher level till the time actual component is available.
TLM has been used for emulating software sockets by providing sockets for bus modeling. Along with the
sockets and ports, it also provides a generic way of communicating with the memory bus models through a
generic payload mechanism. The TLM standard itself provides different types of modeling interfaces like
blocking interface and non-blocking interface. This infrastructure can be used to communicate between two
models irrespective of the differences in their architecture and transaction format.

1
 Figure1. Register and socket interface connection

III. ARCHITECTURE
The use-model for our methodology employs initiator and target sockets using TLM analysis ports for
establishing the communication channel. The initiator socket is bound to the interface on the backward path
(connecting to the user interface) while the target socket is bound to the verification component. The generic
payload is used to ensure interoperability so that any verification component can be hooked to this setup. The
generic payload is updated with the register addresses and the data field for the current memory transaction that
is to be done.
The transaction on the user interface is encapsulated in the generic payload and written to the initiator sockets
out port using blocking transport calls. This will ensure that next call for transport of data will be scheduled only
once the present write call has been completed successfully.
For the read operation, the initiator socket will again schedule a blocking transport operation. In this case target
socket will block the operation till some read data is available. For this purpose several simulation cycles could
elapse thus requiring a loosely timed blocking transport mechanism in this case as well.
For our purpose the target socket is further bound to the model registers and transaction layer in order for the
commands to be executed for these.

Figure2. Methodology for use of TLM interface

2
 IV. METHODOLOGY
The proposed methodology uses a register based interface for creation and subsequent driving of transactions to
the verification component from a system level testbench. The architecture uses a predefined memory space
which can be used to configure the transactions and the memory space. These registers will be using a
SystemC/TLM based interface to connect to the verification component. The input stimulus can now be
provided in the form of C transactions or any other language if the adapter for that language has been
implemented. For the configuration purposes, registers specific to configuration parameters are added.

The following subsections provide information on the various blocks of the methodology.
A. Shared Memory Space
The shared memory space provides us with the ability to work across the language boundaries with ease. The
memory could be partitioned into a register space as relevant to the needs of the verification component. This
memory space will be having mirrored memory for every instance on both the sides of the TLM
boundary(shown in figure 2). The TLM connection exchanges data between the two layers using memory space
updates through TLM Read/Write
In case of multiple instances of the same verification component being used, separate memory space needs to
be created for each instance in order to be able to perform simultaneous operations on both the instances. This is
enabled through separate base address offsets being used for each agent.
B. TLM Sockets and Connection
The TLM connection across the language boundary uses a non-blocking generic payload transfer in order to
transfer the data (transaction) from one layer to another. The generic payload size is limited to the memory
register size available. The addressing is used to indicate the portion of transaction that is being transferred at
any moment or the particular memory space being written to in the model.

The connection of the sockets to the model can be done through OVM_ML ports in case of connecting to
models using the HVL interface. In the present case a C based socket was implemented in order that the C-
models could be connected to the initiator sockets.
C. Test Writing Interface
The testcase itself can be written in a high level language such as C. The test writing interface has high level
API’s that can be used by the test writer to send/receive transactions or configure the model. The following
minimum control is provided to the verification engineer:
- Structs for specifying the instance configuration and for capturing the transaction related information
- API to exchange this transaction information with the model
- Methods to enable the writing the model configuration and allowing dynamic control of the model

These APIs ensure that the user can write testcases without any need to directly interact with the memory space
or TLM updates. These API’s also reduce the need to do extensive model randomization by only providing high
level controls that might be relevant to a system level verification environment.
Also since the test writing is in C, it ensures deterministic test vector behavior which is an important
requirement when integration testing is being done.

3
 Figure3. Test writing interface and connection

D. Testbench Instantiation
The testbench instantiation is not affected by the mode in which the model is working. The model can still be
directly connected to the DUT through its HDL interface in case of RTL verification. For the case that ESL-ESL
verification is to be done, the model can be connected through the SystemC port interface to another ESL model
for the DUT. This will typically be the case in earlier stages of verification where SystemC models will be used
as placeholders till RTL is ready.
In addition another hybrid model can also be used where RTL-ESL connection is to be established. In this case
the connection from the model to the DUT will be through the TLM sockets implemented on both the DUT and
verification component.

Figure4. Two modes of connection for the interface

V. EMBEDDED TESTBENCHES
Another application of this methodology is in environments where the stimulus might be directly picked from
memory programmed by the CPU. In such cases simply the remapping of the memory space on the C test side to
the environment’s memory space could be used to directly program the verification component into driving the
relevant traffic to the block.
Such cases are especially beneficial in verification of interface connections for protocols like PCIe which
directly interface with memory and CPU in an environment. Such a connection is shown in figure 4.

4
 Figure4. CPU based test vector generation

VI. BENEFITS OF THE METHODOLOGY

The reuse methodology by itself is helpful in shortening the verification time and helping with scaling of the
environments in any verification exercise. For the particular case of adapting module level testbenches at the
system level the following gains are to be made:
- The system integrator need not spend additional time in setting up the verification component again at
the integration stage
- The person integrating the environment need not be an expert on the particular IP being verified and
still would be able to test the module
- The same testcases at the module level can be reused with minor modifications
- The environment can be switched at ease from module level mode to system level mode allowing for
running the HVL tests as well as system tests
- The TLM interface provides capability for this environment to span several domains of connectivity
including RTL-ESL, RTL-RTL and ESL level individually. Hence, this enables the same verification
component to be used right from the SystemC modelling level to the actual design in HDL and further
into the system integration domain.
- It provides the capability to use a common register space for configuring the verification component
and the design under test.

VII. CONCLUSION AND FUTURE WORK

The addition of the register based interface and API’s to the verification component reduced the effective time
duration for the first test to be up at the system level without any significant effort addition on the part of the
verification team. It also allowed the system level verification engineer to be able to control the verification
through the tools and languages familiar to him and saved the need for ramping up on a new module and
language. The activity also allowed for verification engineers to directly hook up the verification environment
with a processor based environment to use a common interface for programming the verification module and the
IP to be verified.
As part of future work, it is planned that adaptors be provided for high level verification languages in order to
unify the testcase writing effort. With this change we should be able to use the same testcase at all the levels of
verification environments. Another addition would be enablement of the callbacks in order to provide the user
direct access to transaction mechanism itself. Under the present setup, the user needs to schedule specific
receive tasks in order to get information about received data. With callbacks this mechanism will become real
time and will be more intuitive.

REFERENCES

[1] Alexander Adamov, Karina Mostovaya, Inna Syzonenko, Alexey Melnik, “Electronic System Level Models for Functional
Verification of System-on-Chip”, CAD Systems in Microelectronics, 2007. CADSM '07. 9th International Conference, 2007.
[2] Andreas S. Meyer, “A Loosely Coupled C/Verilog Environment for System Level Verification”, ASIC Alliance Corporation, Verilog
HDL Conference and VHDL International Users Forum, 1998
[3] Ray Turner, “System-Level Verification -- a Comparison of Approaches”, IEEE International Workshop
on Rapid System Prototyping, 1999