Design & Verify Virtual Platform with reusable TLM 2.0

By Deep Masiwal, 3D-IP Semiconductors Pvt Ltd

As the system, software & IP complexity is increasing so is the demand of SystemC models & Virtual Platform for verification. To achieve it, the key requirements are that the models/platform should be developed fast, reusable & highly accurate. We are sharing the experience of our company 3D-IP Semiconductors Ltd. for the development of a generic Virtual Platform using TLM 2.0; reusable for any system model. This development is completely done using open source libraries e.g. SystemC, QEMU & TLM 2.0 (basically no tools are required for the development). We will also explain the use of open source libraries for packaging the deliverables, configuring, integrating and verifying our SystemC IP model.

Keywords — SystemC; TLM 2.0; Linux driver; TLM wrapper; Data Error Checker (DEC)

I. INTRODUCTION

As the system, software & IP complexity is increasing so is the demand of SystemC models & Virtual Platform for verification. To achieve it, the key requirements are that models/platform should be developed fast, reusable & highly accurate. We are sharing the experience of our company 3D-IP Semiconductors Ltd. for the development of a generic Virtual Platform using TLM 2.0; reusable for any system model.

Figure 1. Architecture of Verification Environment

We are presenting two verification methods for verifying SystemC models.

• LINUX Driver based verification (SystemC IP model for embedded application)
• Developing our own traffic injector (verify unit model)

The above techniques include the development of different packages utilized for automation of model verification; e.g. booting Linux driver as an application software and its integration using TLM 2.0.

The paper discusses the benefits of generic models and automation techniques which eases and reduces the model verification time without prior requirement of any tools. Additionally, we are proposing a verifying methodology that utilizes TLM 2.0 sockets and interfaces for verification purposes. These methodologies give the benefit of reuse & creates a verification environment that passes the traffic from the driver to the system level model via TLM 2.0 interface. In the traffic injector method, a Data Error Checker model which checks the error in the transactions or data; by this we also increase the debugging scenario of our modelling technique. These generic model & environment are used to develop a Virtual Platform for a next generation Memory Controller based on JEDEC Universal Flash Storage (UFS) 2.0 Standard.

II. BACKGROUND

We are already using SystemC and TLM for prototyping and at transaction level modelling. Use of SystemC and TLM at early stages emulate the functional behaviour at transaction level without any need for pin interface definition. TLM is being used for emulating software sockets by providing sockets for bus modelling. 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 modelling interfaces like blocking interface and non-blocking interface. These modelling interfaces can be used to communicate between two models irrespective of the differences in their architecture and transaction format.

III. ARCHITECTURE

Our proposed methodology can verify two types of model one is embedded s/w application based hardware model and other is unit testing of bus functional model. Based on the requirement we can use either of the techniques to verify a model. Before compiling we have to mount the test cases on either of the environment and select the environment while compiling.

Linux Driver Verification method employs a Linux kernel (core CPU) whose image is built over QEMU emulator. The root system file for the Linux kernel image is provided with the test case executable. When Kernel boots, it mounts test case file as filesystem. The filesystem is driven by the Linux driver through TLM 2.0 initiator socket. A TLM wrapper provides a communication between the CPU i.e. Linux driver over a QEMU emulator to the SystemC IP model through TLM 2.0 interface. As Linux kernel is a core CPU which already holds many device drivers, so many embedded based hardware models can be tested by mounting the C based test cases executable as root file for Linux driver.

Figure2. LINUX Driver based testing environment

Traffic Injector Verification method is used for unit testing of bus functional model. A TLM 2.0 initiator socket is bound to the verification component while a target socket is bound to the model for testing. Now traffic injector writes the test cases onto the model through TLM 2.0 blocking transport calls. Next transaction will take place only after the completion of previous call. For the read operation, the initiator socket will again use a blocking transport call. In this case target socket will block the operation till some read data is available. By this blocking transport call mechanism several simulation cycles could elapse.

Figure 3. Traffic Injector based verification architecture

IV. METHODOLOGY

LINUX Driver Verification Environment: There are device drivers in the kernel module which are responsible for controlling the hardware. These device drivers are utilized for testing the hardware model. Description of our proposed environment and every component (Short for Quick Emulator) is a free and open-source hosted hypervisor that performs hardware virtualization. Below is the description of our environment components.

• Emulator. It typically enables the host system to run software or use peripheral devices designed for the guest system. In our case we have used QEMU configured with arm architecture.
• Linux Kernel. It is a core CPU that holds embedded based device driver. These drivers are utilized to drive the commands/test cases that has been written in C language as per device driver module. The test cases file is compiled with the ARM compiler. An image of the Linux Driver is formed on which the executable of the test case is used to develop the root of file system for testing.
• Xterm. It provides standard terminal emulator. It creates a virtual environment to pass the test cases command. It showcases an exact way of running an application over a hardware. As you will see a command passed on Xterm terminal will be executed on our command terminal.
• TLM wrapper. It lets you connect CPU core in QEMU to SystemC models using TLM 2.0 interface. TLM initiator and target sockets are used for establishing the communication channel between the models.
• Application Layer. It’s a user layer where we write our C based test cases. These test cases are written according to the Linux driver module compatibility.

Traffic Injector Verification Environment: This verification environment is useful for testing unit models by passing the traffic via. TLM 2.0 interfaces. The environment is developed generic so as it can verify different modules with minor changes in the driver. The description of the component is as follows.

• Traffic Injector. This component is basically used for driving the data via TLM 2.0 by reading the test case file. The transmission & reception of data is controlled by Control FSM. Control FSM is a state machine which read the data from register in order to control the threads. The register configuration is being done as per the test cases developed.
• Test cases. Our Environment provide basic test case along with the protocol specific test cases. Basic test cases included, initial value test, reset test and access value test. These test case are configured inside the registers can be directed to any model integrated in our environment with minimal changes to address offset of register. Protocol specific test cases are easy to develop, as the whole environment is based on TLM sockets and the changes as interface level is not required. We need to just derive the commands and data specific to the protocol. The test case is created on an xlsx sheet which are written on traffic injector memory as per the compatibility of generic payloads through script. These test cases also configure the register in traffic injector so as to control the transactions.
• Registers. There are various registers e.g. precondition, post condition etc. inside the traffic injector which are being configured according to the test cases for controlling the FSM.
• Data Error Checker. It is a separate entity in 3dip semi environment which performs CRC checks. In our case we our using CRC-16, on the transaction which is received. The CRC is calculated before its transmission and checked again when data is received. Once it is confirmed that the transaction reception is error free, the transaction is sent to the comparator.
• Comparator. The comparator matches the received information with the expected one and decides whether the corresponding functional behaviour is realised correctly or not. The expected output data is written by the user on the test case xlsx sheet.

V. RESULTS

The reusable verification environment is helpful in reducing the overall verification time.

Key benefits by using this environment:

• Less time will be used for integrating verification component with modules.
• Easy to develop the test cases.
  • Not much programming skills are required.
  • Only good understanding of protocol is required.
• The same test cases at the module level can be reused with minor modifications.
• Only minor changes is required for verifying different protocols.
• Open source tools are utilized for development and automation.

VI. CONCLUSION & FUTURE WORK

The methodology adopted is best in class & easily used across various systems, software and platforms. Based on it we have verified a Virtual Platform for an advance Memory Controller (Universal Flash Storage (UFS) 2.0 JEDEC Standard). In future, the same methodology can be utilized for other Controllers such as embedded Multimedia Controller (eMMC), Solid State Drives (SSD), etc. Additionally, it allows the SOC Verification engineer to control the verification through the tools and languages familiar to him and saves time & effort on ramping up on a new module and language.

As a part of future work, it is planned that the development of the testcases for both environment be unified which will reduce the writing effort. Also, it allows to port the IP level testcases to system level environment. Another addition would be to develop this environment so that in can be used right from the SystemC modelling level to the actual design in HDL and further into the system integration domain.

REFERENCES

[1] https://github.com/hdlab/tlmu

[2] http://thawedoutnow.blogspot.in/2013/03/what-is-tlmu.html

[3] https://balau82.wordpress.com/2010/03/22/compiling-linux-kernel-for-qemu-arm-emulator/

[4] http://opensourceforu.efytimes.com/2011/06/qemu-for-embedded-systems-development-part-1/