Skip to content

Remote Port

Jump to bottom
BrunoASMauricio edited this page Nov 16, 2023 · 4 revisions

Remote Port

Sources

Remote Port is a technology developed by Xilinx at https://github.com/Xilinx/qemu.git and https://github.com/Xilinx/libsystemctlm-soc

Xilinx board/kernel based examples are present at https://github.com/Xilinx/systemctlm-cosim-demo/docs

What it is

It allows information exchange between two simulators, such as memory transactions and synchronization.

Its' main goal is to make available an SOC environment capable of emulating a CPU that can communicate with any simulated fabric.

Based on what the creator mentions here, this should enable companies that produce SoCs to reliably and accurately simulate the RTL of the SoC while offloading the usually very expensive simulation of the CPU into a much faster emulation.

How to use it with ARC

By default, Remote Port is integrated in Xilinx boards and a RISCV one, in the Xilinx repository.

As of now (16/11/2023), it isn't upstream so support for CPUs not present in their repo can only be achieved by handpicking code into this repository directly.

As long as the simulations are coherent with what each things the other is providing, nothing on the SystemC side needs to change.

As progress is made on this front, more information will be added here.

Status

Branch remote-port currently supports memory based accesses (reads/writes) into the SystemC simulation

How it works

Overall, Remote Port implementation makes two changes to QEMU:

Devices

The most relevant one is the addition of devices that allow communication between the QEMU and SystemC These devices also require some minor alterations to QEMU, which means they aren't "drag and drop" These changes are (besides the ones to include the devices):

  • include/chardev/char-fe.h
  • include/chardev/char.h
  • include/exec/memory.h
  • include/sysemu/dma.h
  • softmmu/memory.c
  • softmmu/vl.c

See more details in the first commit of the remote-port branch, which contains solely these adaptations.

They aren't very invasive, and a few seem to be 'temporary', but should still be taken into consideration.

Generic devices

The other interesting change is the addition of generic FDT devices.

This change enables QEMU to generate and configure devices dynamically by inspecting a device tree from a file provided via command-line argument

This means that instead of being limited to hardcoded machines and their specific device configurability, we can adapt any machine that supports dynamic devices, at execution time.

Documentation TODOs

  • Add information on how fdt devices are identified and generated
  • Add per device information as they are added
  • Multiple basic tutorials
Clone this wiki locally