QEMU emulated devices need to communicate to external world to properly simulate its functionality. For example, when a emulated network device receives a packet from the Guest O.S. to be sent, the device needs to send the packet to the Host O.S. and the Host O.S. will send the packet to the real network.

To help this task, QEMU provides a set of helper functions and a common API for all types of devices. Those include: network and sockets functions (net.c), block devices management (block.c), audio (audio/audio.c), and usb (usb-linux.c, hw/usb.c, …). We call them QEMU back-end functions

Standard QEMU modules use this back-end functions calling them as a usual C functions. When we replace these modules with our SystemC modules, we have two options to use this back-end functions inside the SystemC model, or splitting in two parts each C module: one for the HW functionality (written in SystemC) and one receiving the virtual I/O part and transforming it to the QEMU back-end.

In the case we embedded the back-end calls in the SystemC model, every device has only one SystemC file (a part of the sc_bridge and the sc_link).

In the second case and for the previous example, we can develop a SystemC model of the network card with a TLM socket emulating the PCI bus of the card, and a TLM socket to emulate the Ethernet plug (from which the networks packets are send and received). This second TLM socket, will be connected to a module that receives that Ethernet TLM socket (data that should be sent/receive to/by the Ethernet cable) and call proper QEMU back-end functions to ask the Host O.S. to do the job.

This second approach seems to be “more TLM” or “more ESL” in the sense that third-party SystemC-TLM models can be plugged in our QEMU-SC framework, and only may need to change the way this module do the I/O instead to embedded the back-end functions in the third-party SystemC code.