Full System Simulation
October 2014 - December 2015
  • Highlight
Software-oriented Heterogeneous Device Support

Modern electronic devices are often heterogeneous in nature. This is due to the limitations imposed by the current technology that prevent us from pushing the clock rates beyond a certain limit, and thus motivates us to step back from general purpose processors and specialize the architecture to best fit the problem at hand.

In particular, it is not uncommon to see boards that couple an ARM processor with an FPGA. The former usually deals with standard operations, such as running an operating system and interfacing with the user, while the latter takes charge of the application-dependent tasks that can, in this way, take advantage of the huge parallelism it can offer. A notable example of such boards is represented by the recent Zynq SoC (see Fig. 1), but the recent acquisition of Altera by Intel supports the hypothesis that these architectures are going to become the new standard in the near future.
                    Figure 1: Zynq
Figure 1: Structure of the Xilinx Zynq-7000 SoC (source: Xilinx press release).

While the above mentioned strategy allows for impressive performance gains, the complexity of the overall system increases greatly: not only programming the two parts requires different skills (and thus the development is usually performed by two separate teams), but also the interactions between them are not easily defined, tested, and debugged. This fact makes the boundary between them one of the most critical points in the system design.

It is not unusual to overhear engineers from the above-mentioned groups discuss whether a given problem in their system has to be sought in the CPU software design, in the FPGA design, or in the way the two parts communicate...

Despite well-defined best practices, the lack of appropriate tools makes it the norm to test the CPU software design using a set of test cases that are supposed to mimic the expected behavior of the FPGA, and at the same time test the FPGA on a test bench that should simulate all the possible interactions with the CPU part. As an extreme example of this practice, ARM was used to employ a VHDL simulation of Linux boot process to validate the design of new processors. These techniques are far from being the optimal solution, and involve a significant amount of duplicated work.
We claim that, in the context of heterogeneous systems composed by a CPU and an FPGA, huge benefits arise from a complete co-simulation of the two parts. Indeed, such a simulation allows full visibility on the internals of the two systems during their interaction, making it possible to spot incongruences, mistakes in the interface design, and business logic errors. Moreover, it allows to test both components while performing real interactions and operating on realistic data, instead of relying on made-up test benches.
An attempt in this direction is represented by the RABBITS project (http://tima.imag.fr/sls/research-projects/rabbits). This framework proposes a system-level simulation based on QEmu and SystemC. However, while the approach and the preliminary results are extremely interesting, the choice of SystemC as working language has a major impact upon the applicability of the methodologies. Indeed, while SystemC is still a promising technology, it is not yet supported by standard workflows adopted in industry.
Another related project is SimXMD (www.eecg.toronto.edu/~willenbe/simxmd), which focuses on using GDB to drive the simulation of a processor. This is similar to what we would like to achieve, but we would like to generalize the adopted approach by letting GDB (or QEmu, in our case) take control of the simulation and interact with it.

The FSS Approach

In the context of this project we are developing a system that interfaces QEmu (http://www.qemu.org) — one of the most renowned machine emulators — with ModelSim/QuestaSim (www.mentor.com/products/fv/modelsim), two standard multi-language HDL simulation environments by Mentor Graphics. A sketch of our system is presented in Fig. 2.
The source code of the system is available on GitHUB at the address:

Figure 3: Circuit used in our proof-of-concept example, composed by two UART ports linked together by their serial pin.
Figure 2: FSS is an interface between the simulation of a processor (obtained using QEmu) and an HDL simulator (in this image, QuestaSim).

An Introductory Example

As a proof-of-concept, we have devised the system depicted by Fig. 3, composed by two simplified UART ports described in VHDL and taken from the net, interconnected by their serial interfaces.
The goal in this example is to create a bidirectional communication channel between two different QEmu instances, each using one of the parallel terminals of the above mentioned circuit. The full system is represented in Fig. 4, while a snapshot of the system’s state during a simulation is shown in Fig. 5.
Figure 4: Full sketch of the circuit used in our proof-of-concept example, where the QEmu instances are relied to the UART ports through the FSS interfaces.

Figure 5: Snapshot of the signals’ states in QuestaSim during a simulation, along with the terminals corresponding to the two QEmu instances. In this example, the first QEmu instance wrote to the communication channel the text “This is”, while at the very same time the second QEmu instance replied “an example!”.

Look it in action

Source Code

The source code of the system is available on GitHUB at the address: