Myoung-Keun You

Case study : Co-simulation and co-emulation environments based on SystemC & SystemVerilog

The flow of universal system-level design methodology consists of system specification, system-level hardware/software partitioning, co-design, co-verification using virtual or physical prototype, and system integration. In this paper, hardware part and software part of a design are described with SystemVerilog and SystemC, respectively after hardware/software partitioning. The functional interaction between hardware part and software part of a design is verified through co-simulation in pure software domain, and then verified through co-emulation after implementation of hardware part onto a specific hardware emulator. Verilog PLI provides a mechanism for Verilog simulators to invoke C functions which are registered as system functions through a complex process of library registration. Communication between software part and hardware part running concurrently needs IPC. Low-level system functions of device driver or kernel are called from C functions which are registered into Verilog PLI library. In contrast to Verilog PLI, SystemVerilog DPI which is used in co-simulation of this paper provides a way to interface with C/C++ or any other foreign language. Functions and tasks registered to the shared library using DPI can be called out like native ones. ModelSim recently supports SystemC simulation with built-in compiler for SystemC design unit, so the co-simulation of SystemC design units and SystemVerilog modules is carried out as one simulation process on ModelSim. After co-simulation, co-emulation using an FPGA-based prototype board is carried out.

Implementation of a C-to-SystemC synthesizer prototype

A C-to-SystemC synthesizer which processes the input behavior according to high-level synthesis, and then transforms the synthesis result into SystemC code is implemented in this paper. In the synthesis process, the input behavioral description in C source code is scheduled using list scheduling algorithm and register allocation is performed using left-edge algorithm on the result of scheduling. In the SystemC process, the output from high-level synthesis process is transformed into SystemC code by combining it with SystemC features such as channels and ports. The operation of the C-to-SystemC synthesizer is validated through simulating the synthesis of elliptic wave filter in SystemC code.

SystemVerilog-based verification environment using SystemC custom hierarchical channel

A verification environment which is based on a constrained random layered testbench using SystemVerilog OOP is implemented in this paper to verify the functionality of DUT designed with synthesizable constructors of SystemVerilog. Although the uses of multiple inheritance in OOP appear to be less common than those of single inheritance, multiple inheritance is useful for creating class types that combine the properties of two or more class types. Because SystemVerilog OOP technique does not allow multiple inheritance, we adopt SystemC to design a component of verification environment which has multiple inheritance, and we combine SystemC design unit with the SystemVerilog-based layered testbench using SystemVerilog DPI and ModelSim macro. SystemVerilog DPI provides a way to interface with any other foreign language. Functions and tasks registered to shared library using DPI can be called out like native ones. ModelSim recently supports SystemC simulation with built-in compiler for SystemC design unit. In order to simulate SystemC design unit with ModelSim, the SystemC design unit should be modified using some macros provided by ModelSim. In this paper, FIFO channel frequently used in high-level communication is designed as a custom hierarchical channel which has three base classes; sc_channel, channel interface, and data payload interface. The low-layer components of the SystemVerilog-based layered testbench communicate with DUT using virtual interface, and other components can communicate with each other using FIFO channel. DUT in this paper includes BFM because most IPs designed for SoC are connected to a bus and controlled through the bus1.

Implementation of a hardware functional verification system using SystemC infrastructure

The implementation of a verification environment to check the behavior of a device-under-test using SystemC infrastructure is presented in this paper. SystemC is generally adopted in a system-level design methodology because of the capability of architectural model description and hardware/software co-design. The verification system implemented in this paper can explore design space using SystemC with a minor adaptation, and verify functional correctness of the progressively refined modules to RTL HDL. The infrastructure of the verification system uses intermediate user-defined channels as communication interface between variables of SystemC module and registers of Verilog module. SystemC modules of the verification system can be reused for other hardware component verification because of the object-oriented feature of SystemC. The functional verification of an UART is performed on the proposed verification system.

Case study: Functional verification of a reconfigurable systolic array using truss

This paper introduces our experience in verifying the operation of each systolic array before and after reconfiguration using Truss. Truss is an implementation of an open-source verification infrastructure based on layer approach. Reconfigurable systolic array for solving either single-source shortest path problem or 0–1 knapsack problem is chosen as a reconfigurable device-under-test. One systolic array can be reconfigured into the other and vice versa according to the problem. The functional verification is performed on a reconfigurable device-under-test using Truss configured to this specific hardware.1

Implementation of a simple emulator platform with limited resources

The implementation of a simple hardware emulator platform using limited resources is presented in this paper. The emulator platform consists of an evaluation board based around ARM processor core and a starter kit loaded with an FPGA chip, and uses tools from open-source software. The software part of the emulator is executed by ARM processor after being loaded into SRAM on evaluation board, and hardware part of it is implemented on FPGA chip on starter kit. The data transfer between ARM processor and hardware module on FPGA chip is carried out through the RS-232 serial port of each board. The evaluation board and host PC are connected by serial cable for debugging using arm-elf-gdb and on-board debugger of evaluation board. Starter kit and host PC are connected by JTAG cable for bitstream of hardware module to be programmed into FPGA chip. Although the emulator platform is constructed with limited budget combining elementary evaluation board, starter kit, and tools readily available from open source, it could be adopted to emulate various kinds of moderate size tasks.