QEMU-SystemC structure

QEMU-SystemC have 3 different modules:

• hw/sc_link.c (sc_link_arm.c): this file receives bus access from CPU and transforms that access to a tuple (data, address) and call Read/Write functions from the sc_bridge.cc. Also publishes functions to raise and low IRQs on the platform. We need a different sc_link for any platform/bus.
• SC/sc_bridge.cc: this file provides the read/write functions to sc_link and controls the SystemC simulation using the frozen-and-update method. This file also builds the TLM transaction from the tuple (data, address) send by sc_link, and performs the transaction to the SystemC device. This module manages the IRQ line (if any) from the SystemC device, and it calls the sc_link functions to use the IRQ.
• SC/sc_slave_dummy.h: the SystemC device.

New device

1. how the device is connected to CPU: fabric bus, direct I/O, PCI, AMBA, etc.
2. how the device interfaces with other components or outside QEMU (UART serial lines, VGA draws, Ethernet send packets). We call it the back-end.

First step actually means work on the following files:

• hw/sc_link.c (or hw/sc_link_arm.c), this file builds a system bus device (PCI of sc_link, AMBA for sc_link_arm). Note that in PCI case, this file has all the PCI configuration registers. Also this file may register IRQ line.
• hw/pc.c (or hw/versatilepb.c or ...) this QEMU files register the sc_link as a device of the selected platform. It is done calling the init function in sc_link (pci_sc_link_init(), sc_arm_init(), ...).

For the second step :

• SC/sc_bridge.cc: In case a device needs to talk to outside world, you may note that the device is frozen most of the time, so it cannot directly manage its communications. It should be done by the SC/sc_bridge.cc.

Example

In progress