Virtual Platforms and RPB for faster System Verification

Praveen Kondugari, Intel Mobile Communications

Abstract:

Virtual Platforms (simulation environment of SoC) is an emerging technology for System Verification enabling users development of early qualified verification software. Verification of bulk SoCs like Audio, and Video Architectures with existing methodologies like Emulators, FPGA, CPLD etc takes long period. Virtual Platforms run much faster and provide good debugging mechanism compared to existing methodologies.

As the size of the SoC grows, virtual platform might comprise 3rd party components simulated with different methodologies. Co-Simulation comes in place, where components are simulated with various tools running simultaneously. These components exchange information in time steps and control signals. When running verification software stacks on co-simulation platform, higher simulation speed is expected for quick verification or debugging. However it would be limited by the component running at low simulation speed. If the time step information, data and control information from such component could be captured and reused in next simulations/re-simulation, the simulation speed of co-simulation platform would be increased for faster verification and debugging. This paper presents a method for faster co-simulation verification where the signal data and time stamp is captured and re-used in next simulations. This method introduces RPB (Record and Post Block) for Capture and Re-Use of the timestamps, data and control signals.

I. INTRODUCTION

Simulation methodologies can be broadly abstracted out as Virtual Platforms, FPGA (Field-Programmable Gate Array), Emulators, RTL (Register Transfer Level) and Gate Level. The speed of simulations is faster in Virtual Platforms as they are modelled at transaction level and with high level languages and slowest at Gate Level. Most of the verification activities are carried out at Virtual Platforms down to RTL level. RTL Verification is more time consuming compared to Virtual Platforms and Emulators. Compared to Emulator, Virtual Platforms bring-up time is less and simulation speeds are 10x times faster.

Good simulation speeds will speed-up the verification phase especially for audio and video architectures which are bulk of size and involving many frames to run. The trend for verification phase is towards usage of virtual platforms which run at high simulation speeds.

However as the size of the system grows, Virtual Platform might comprise 3rd party components simulated with different methodologies. Co-Simulation comes in place, where individual components simulated with various tools run simultaneously.

Tool vendors like Cadence, CoWare etc provide tooling for co-simulation where existing RTL components can together be run with the components available in Virtual Platform. If a complex RTL component is available it can be co-simulated instead of going for development of the same component using higher level languages. Tools like Carbon [3] helps in converting RTL components to SystemC components (Carbonized component). Anyways RTL component or carbonized component run with low simulation speeds.

II. VIRTUAL PLATFORMS AND SIMULATION SPEEDS

Virtual Platforms are simulation environment of hardware. Virtual Platforms are developed using higher level languages like C++, SystemC [1], SCML (SystemC Modeling Language) [2] etc in different abstraction levels like loosely timed, approximately timed and cycle accurate. A typical Virtual Platform comprise processor core simulators connected to various models of bus, routers, adapters, memory controllers, and other data peripheral models. In loosely timed mode, modelling the virtual platforms focuses on functionality of the cores and peripherals and doesn’t carry actual timing information. This mode is preferred when requirement is to develop and verify application software. Loosely timed mode is faster compared to other two modes. Virtual Platform in approximately timed mode is preferred to explore architectural alternatives to platform architecture. This mode can also be used to partly carry out performance measurement. Virtual Platform in Cycle Accurate Mode is used to jointly verify the hardware and software in the system context. This mode is used to carry out performance measurement of architectures.

In the context of System verification of bulk architectures like Audio & Video architectures Loosely Timed abstraction of Virtual Platforms are best fit. Interconnect Verification such as Interrupts test, Address map tests, Reset tests and Functional Verification of each component and communication across components can be validated. Virtual Platforms are also used to validate the developed application software, driver softwares, middle wares etc.

Co-Simulation and Simulation Speed

Simulation speed of Virtual Platform comes down when it comes to co-simulation. Simulation speed depends on the speed of the lowest speed component in the simulation path. In debugging phase irrespective of the dependency on that low speed component the simulation speed is dropped as it is part of simulation. If the data and control signals with respective to time stamps are captured for low speed component and can be used as stimuli the low speed component can be excluded in the next simulations and avoid low speeds. Section 4 describes a typical co-simulation environment and section 5 describes the proposed method for faster co-simulation verification. Section 6 describes the advantages and disadvantages of the proposed methodology.

III. LITERATURE SURVEY

SystemC provides SCV [4] for transaction recording and similarly in RTL simulation output can be recorded and viewed in Simvision. It includes control data and transaction data with respect to time stamps over the ports for all the components. It doesn’t provide the information of whether the data is input on the port or if it is output and there is no framework to use this data in next simulations as certain debuggers does. Emulators provide support to tools like DBGMON for debug checks. These are only redirected prints and need more human intervention to analysis and in emulation there is no way one can use this data as input to next run.

Most of the debug mechanisms or tools provide either accessing the data parameters at simulation run time or dump the required data post simulation. However no frame-work is available in simulations which records data during simulation and re-uses it in next simulations.

VCD Dumps are available in virtual platforms; how-ever this information cannot be reused as it is. The VCD dump does not provide information whether the captured data is input to the port or output from the port.

The proposed method captures and re-uses the data in next simulations under the constraints of running the same applications or verification software. This method as a plug in to virtual platform environment speeds up the debugging phase significantly.

IV. CO-SIMULATION PLATFORM USING SYSTEMC AND RTL COMPONENTS

SystemC is one predominantly used higher level language for modelling hardware IPs. Simulation speeds are very high compared to VHDL or Verilog (RTL) components. Figure 1 represents co-simulation environment where SystemC models and RTL models are put together. The data exchange between these models will be at signal level. Both RTL components and SystemC components should be synchronized for data/control interactions. This is achieved by synchronizing the clock modules in SystemC and RTL. Both the clocks need to be run at same phase. Since the SystemC clock module will be much faster it need to be enhanced to step for each clock only after completion of clock in RTL.

In the scenario of co-simulation between SystemC and RTL components the speed drops down significantly because of low speeds of RTL components. Debugging and running end to end software like audio/video processing over these platforms will be extreme time consuming and effort consuming. Such lower speeds can be overcome in a multiple run scenario by capturing data with respect to time over the interface between RTL components and SystemC components and using this data in next simulations.

Figure 1 : SystemC and RTL Co-simulation

V. METHOD FOR FASTER CO-SIMULATION SYSTEM VERIFICATION

Proposed method for faster Co-Simulation is to have a fast running block/module in lined with the interface between the low simulation speed components and fast simulation speed components. This model is expected to record the control triggers and data over the interface with respect to the simulation time. In the next simulations this component directly sits before the faster simulation components instead of slow simulation components and provides the required data and triggers at required time stamps.

Figure 2 : Record and Post block integrated b/n SystemC and RTL

Figure 2 represents record and post block (RPB) integrated or placed on the interface of SystemC components and RTL components. RPB is modelled using SystemC which runs at higher simulation speeds. RPB when configured to record, records control and data signals along with time stamps and when configured to post, stimulates the recorded data at the noted time stamps. The signature of recorded format is

simulation_time_stamp : signal_id : signal_width : data_value

A sample recorded data for a Traffic Generator Component is shown in Table 1. The captured data corresponds to interrupt and Data ports. Signal id SIG_C1_INTERRUPT corresponds to interrupt port and SIG_C1_AHB_DATA corresponds to Data port of Traffic generator.

TABLE 1: RECORDED SAMPLE FOR DMA MODULE

Recorded Sample for DMA Module
12 SC_NS : SIG_C1_INTERRUPT : 1 : 1
12 SC_NS : SIG_C1_AHB_DATA : 32 : 0xAABBCCDD
13 SC_NS : SIG_C1_INTERRUPT : 1 : 0
16 SC_NS : SIG_C1_AHB_DATA : 32 : 0xD0FFCEA0
54 SC_NS : SIG_C1_INTERRUPT : 1 : 1
55 SC_NS : SIG_C1_INTERRUPT : 1 : 0
55 SC_NS : SIG_C1_AHB_DATA : 32 : 0x0000FFE0

This recorded data is dumped in to a local file at the end of the simulation. In the next simulation when RPB is configured to post the file is read and the recorded data is send over the interface to SystemC models at respective time stamps without running the RTL models.

Figure 3 : Simulation with Record and Post block and SystemC components

Figure 3 represents simulation with SystemC components and RPB where the block is configured to stimulate the recorded data in previous simulation. The recorded sample shown in Table 1 is stimulated by RPB and the respective Timing diagram is shown in Figure 4.

Figure 4 : Timing diagram for Record and Post block stimulated data

VI. POSITIVES & NEGATIVES OF THE METHODOLOGY

Virtual Platforms completely modelled with higher level languages and at transaction level are faster and are best suit for System Verification and Debugging.

If the platform needs to be a co-simulation platform tools like Carbon are available to generate SystemC models to convert existing RTL models to SystemC models. However carbon tools are expensive and the generated models simulation speed is still much less compared to Virtual Platforms with transaction level models.

A. Positives:

• The said method is low cost method to achieve high simulation speeds for forward (like Video/Audio) data flow architecture based systems.
• Usage of tools such as Carbon where RTL models are converted to signal level SystemC models will need expensive license.
• Newly developing and validating SystemC model of existing RTL IP in problem is time consuming.
• Emulation platforms are expensive, time consuming in creating the platform, simulation speeds are less compared to Virtual Platforms

B. Negatives:

• This method doesn’t hold for the very first new simulation.
• This method is useful only when debugging the same application i.e. without any change in application for next simulations

VII. CONCLUSIONS

Virtual Platforms, which give high simulation speeds compared to other existing methodologies, enable users for faster System Verification or debugging process of bulk architectures like Audio and Video Architectures. The proposed method of RPB enables users to have high simulation speeds in case of re-simulation even if the Virtual Platform needs to be a co-simulation Platform having low simulation speed components.

Though SCV provides the log of time-stamp and port values, it doesn’t provide the information of whether the data is input on the port or if it is output. As part of future work the proposed RPB can be made compatible to reuse the recordings from standard tools like SCV.

REFERENCES

[1] IEEE Standard SystemC Language Reference Manual, IEEE Computer Society, 2006.

[2] SCML 2.0, SystemC Modeling Library, http://www.synopsys.com/cgi-bin/slcw/kits/reg.cgi

[3] http://www.carbondesignsystems.com/

[4] C. Genz and R. Drechsler, “System exploration of SystemC designs” in IEEE Annual Symposium on VLSI, 2006.

[5] C. N. Ip and S. Swan. A tutorial introduction on the new SystemC verification standard. White paper, 2003

[6] Synopsys Inc., CoWare Inc., and Frontier Design Inc., http://www.systemc.org. Functional Specification for SystemC 2.0.

[7] SystemC Verification Working Group, http://www.systemc.org. SystemC Verification Standard Specification

[8] Grotker, Thorsten and Liao, Stan and Martin, Grant and Swan, Stuart. System Design with SystemC. Kluwer Academic Publishers, 2002, pp 87-130.

[9] Moshe Y. Vardi. Formal Techniques for SystemC Verification. DAC 2007

[10] Ghenassia, F. Transaction Level Modeling with SystemC. Springer, Dordrecht, Netherlands, 2005.

[11] Stuart Swan. SystemC Transaction Level Models and RTL Verification. DAC 2006

[12] Nicolas Blanc, Daniel Kroening, Natasha Sharygina. A Tool for the Analysis of SystemC Models. ETH research grant TH-21/05-1

Keywords— Virtual Platforms, System Verification, SoC, RPB, Architectures, Co-Simulation