Electronic – hardware software co-simulation in HDL simulator

fpgartlsimulationsoftcorevhdl

When we simulate (VHDL) RTL designs in a simulation tool like ModelSim or ActiveHDL e.t.c, we can have a complete visibility of all signals and variables in the design. This goes a great deal in aiding debug in simulation. Certain things like function calls and procedure calls are not easy to debug though, we would have to set breakpoints for that.

Now assume I have a soft-processor inside the design like a Nios II processor or something else which has a program written in high level language. This program will have its own variables and state-machine code implemented in a high level programming language like C. If I carry out RTL simulation, I would be able to see what is happening at the interface of the processor. However, if I want to be able to debug the system, I should be able to see into the software of the processor in real-time as the simulation progresses.

How is this problem handled in the real world? How would such systems be debugged? If I want to fix an error in the code, I would have to have a command-line method to compile the code, generate hex and put it in a place where the simulation tool can access it everytime.

Best Answer

There is no concept of hardware software co-simulation on a general purpose, average CPU, since the CPU does not have the processing power to emulate hardware real-time in a fashion that is timing-accurate. You want to emulate hardware in a fashion that is timing-accurate since you want the software to run on the hardware and be able to debug it a timing-accurate fashion.

A more appropriate term would be Hardware-Software Co-Verification to describe the process of verifying that the software correctly runs on the hardware.

In practice, 3 options are used for hardware-software co-verification:

  1. Emulation: Specialised hardware called an emulator or emulation-box is used. The software runs on the hardware using an emulation box. Emulators usually provide high visibility of the system, so you can step through the C program and debug it.

  2. Hardware co-simulation using an FPGA: This is also known as Hardware in the loop simulation. It is supported by some FPGA vendors like Xilinx. The basic idea is that instead of simulating hardware, you synthesize it on an FPGA. The debugging of the system can be done by connecting the FPGA to a CPU using PCIe. The FPGA communicates with the CPU in real time.

  3. Use a Transaction-Level or functional Model: The idea is "Things which are equal to the same thing are equal to one another." A transaction-level model is at a higher abstraction than RTL, so it can be simulated on a CPU much faster than RTL. A transaction level model can be functional, cycle-accurate etc. To do hardware software co-verification, first verify the working of the software by running it on the Transaction-Level model. This can be done on a CPU, since it is not timing accurate. Then verify the validity of the transaction-level model by co-simulating it with the HDL simulator, using DPI for SystemVerilog or VHPI for VHDL. The transaction-level model can be written in C, C++ or SystemC. Alternatively gem5 or QEMU can also be used to co-simulate with the RTL model.