June 1, 2005 -- Dynamically reconfigurable processor architectures are likely to find wider acceptance for system design in near future. The key factors driving the adaptation of such systems would be: 1) availability of flexible hardware resources make systems easily adaptable to new applications and newer versions of existing application, which reduces cost, and 2) the reconfigurable component of the system can be designed to be more suitable for a particular type of applications (such as a data flow processor for stream processing and data dominated computations), which leads to better performance in terms of power dissipation and throughput. Moreover, such reconfigurable components tend to be denser than general purpose processors in terms of silicon area.

Such reconfigurable computing systems would typically use some RISC micro-controller (such as MIPS and ARM), and/or DSPs along with the reconfigurable co-processor. The reconfigurable processor would typically be used to implement specific functionality more suited to a tailor-made hardware than a RISC or a DSP processor. These system components would be using some interconnect structure for communication among them. The interconnect structure could either be a programmable switch based structure or a bus based structure.

The users of the reconfigurable processors for such system design require support for system verification, application development and system debugging. The reconfigurable processor vendors would typically provide a software simulation model for the reconfigurable processor architecture. This, however, does not take care of system verification and debug requirements.

This article presents our experience of developing a SystemC based co-simulation environment for application development and system debugging for such systems using a reconfigurable processor.

The co-simulation environment is targeted towards systems based on a dynamically reconfigurable dataflow processor architecture using MIPS/ARM like RISC processors. The interconnect architecture is assumed to be a bus based one (such as AMBA bus). Figure 1 shows a schematic of such a system.

Figure 1. A system using a reconfigurable processor.

System Verification of Reconfigurable System

A heterogeneous multi-processing system described above poses major challenges in terms of the verification of the complete system and debugging of applications.

Some of the traditional approaches for verifying the systems could be:

After system partitioning, independently verify each of the processor/component of the system using the simulation models for the respective components and writing testbenches for each such model. Considerable effort is required in developing testbenches and this approach is not usable for application debug at system level. A C/C++ based functional simulation environment, which integrates all the simulation models of the components, can be developed. However, such C/C++ code can get complicated as the synchronization across simulation models has to be handled by this code.

SystemC based system co-simulation environment

For our system verification environment, we decided to use SystemC as it does not suffer from any of the drawbacks of traditional approaches mentioned above. It provides abstract communication constructs, which can be used to model communication and synchronization across system components (which may be at different abstraction levels, such as ISS and Cycle Accurate). The SystemC simulation kernel takes care of the parallel execution and synchronization and need not be modeled explicitly. Further, Open SystemC kernel is easily available and many libraries are also available with it, which helps in modeling and extending the system for future processor architectures (and models at different abstraction levels).

For developing a System simulation and debug environment, the following components are available from variuos vendors:

Simulator for RISC processor (R-SIM), the simulator also provides API for debugging functionality. This simulator could either be an Instruction Boundary Accurate or a Cycle Accurate simulator. Such simulators are also available for the DSPs. C source code debugger for RISC and DSP Cycle accurate (CA) simulator for reconfigurable dataflow processor (DF-SIM). Being a dataflow architecture, CA model is same as Instruction boundary accurate for this processor. Data flow graph debugger for the dataflow processor Transaction Level Model (TLM) for memory (MEM)

The purpose of the System co-simulation environment is to provide a unified and seamless environment for simulating the whole system together using its various components. It means that after system partitioning of an application, the user need not simulate and verify different components in isolation but can simulate and debug the whole application implemented on such a system.

Architecture of the co-simulation environment

The components of the System co-simulation environment are illustrated in Figure 2. The key problem in providing such an environment is to make different simulator components (ISS, CAS, and TLM) communicate with each other correctly and managing the temporal ordering of events efficiently without unnecessarily slowing down any of the components. During debugging, whenever any of the components hits a breakpoint (or needs to stop due to any user/data event); all the components have to be synchronized in simulation time.

Figure 2. Components of a co-simulation system.

The Debug Manager (DM) handles all these tasks of synchronization across these processes and is implemented using SystemC. We use the interaction between DF-SIM and R-SIM only to illustrate the tasks of DM; it can be easily extended to more simulation processes.

Figure 3 shows the following components of DM:

Clock generator: This is the main module of DM that synchronizes the execution of R-SIM and DF-SIM. It uses the clock functionality provided by SystemC. Communication Channel: The communication channel is used to pass data across the two simulators; this is modeled using SystemC channel. It models the behavior of such data transfer (DMA etc.) across these devices in the system. This channel is modeled in two ways: Functional Level: Here only functionality of the channel is modeled without the timing, so clock input is not required in this mode. This is used for better simulation speed at cost of timing accuracy. Cycle Accurate: At this level the Communication Channel is also modeled in a Cycle Accurate fashion, which slows down the simulation with cycle level timing accuracy. In this case the clock input is needed by the model. Controller for R-SIM: this module implemented in SystemC controls the execution of R-SIM. It includes calls to debug API provided by R-SIM for synchronization purpose. It controls R-SIM as follows: Pass input from Communication Channel of DM to R-SIM. This is passed over Data Channel (Data_Ch) which could be implemented using IPC as well. Run R-SIM to execute one RISC instruction. This message is passed over the Message Channel (Msg_Ch) implemented using IPC. Ignore next few clock cycles to synchronize with SystemC clock. The number of clock cycles ignored is same as the number of cycles required to execute the particular RISC instruction. Pass output from R-SIM to Communication Channel of DM, this is obtained from Data_Ch. Controller for DF-SIM: this module is also implemented in SystemC and uses the API provided by DF-SIM to control its execution. At every positive edge of SystemC clock it performs the following actions: Pass input from Communication Channel of DM to DF-SIM. This is passed over Data Channel (Data_Ch) which could be implemented using IPC as well. Run DF-SIM for one cycle. Pass output from DF-SIM to Communication Channel of DM, this is obtained from Data_Ch.

Figure 3. Architecture of DM for co-simulation of DF-SIM and R-SIM.

The scheme described above for DM allows execution of R-SIM and DF-SIM in parallel. The overall synchronization of the system is handled by SystemC. The synchronization between R-SIM and DF-SIM can be done at two levels:

R-SIM instruction level: if R-SIM is an ISS, the system is stable after execution of one RISC instruction of the processor. The user/debugger can get control only after the simulation of a particular instruction and not in the middle. At this level, even though DF-SIM is Cycle Accurate, the user does not get control after a Clock Cycle, but only after R-SIM ISS has simulated a particular instruction. In such case, the effect of Breakpoints (or other debug commands) in DF-SIM can be seen after the execution of ISS instruction and not immediately after the occurrence of the event of interest in DF-SIM. Cycle level: if R-SIM is a Cycle Accurate simulator, the system is stable after every clock cycle, and the user/debugger gets control after every clock cycle. In this case there is no difference in the debug behavior of DF-SIM.

Although the above description discusses the interaction between only the two simulators, it can be observed that more simulators (processors) can be added to the co-simulation environment by extending the DM by adding more simulator controllers and by enhancing the Communication Channel model. As far as external memory models (TLMs) are concerned, the Communication Channel of the DM catches such memory requests from the simulators and issues appropriate Transactions to the memory model. The memory model being a TLM does not pose major synchronization challenge as the transactions are serviced instantly in simulation time.

The use of IPC channels for communication with the simulators from the Simulator Controller modules of DM allows execution of these simulators on different machines of a network with improved system simulation performance.

Conclusion

For dynamically re-configurable processor systems to gain wider acceptance, the system designers using these processors would require System level debug and verification environment. A SystemC based co-simulation system environment provides a unified and seamless environment for simulating the whole system together using its various simulation components. It means that after system partitioning of an application, the user need not simulate and verify different components in isolation but can simulate and debug the whole application implemented on such a system.

By Shridhar Laddha, Senior Member of Technical Staff, SoftJin

Laddha is a co-founder and Senior Member of Technical Staff at SoftJin. In his 11 years of experience in EDA industry, he has been responsible for developing several system level design and verification tools. He holds a Masters in Computer Science from Bombay University, India.