2.2. Orchestration Framework for Virtual Prototypes#

SimBricks provides users with a powerful orchestration framework to programmatically define and configure virtual prototypes through Python scripts. To do this, users leverage the simbricks-orchestration python package that offers an intuitive and flexible API, allowing for seamless virtual prototype configuration.

The orchestration framework package is divided into three modules that reflect SimBricks configuration abstractions, namely the System Configuration, Simulation Configuration, and Instantiation Configuration:

  • simbricks.orchestration.system: For defining the systems structure through components, interfaces, and channels.

  • simbricks.orchestration.simulation: For assigning simulators to components and defining simulation behavior.

  • simbricks.orchestration.instantiation: For configuring how and where the virtual prototype is executed.

Consequently, scripts written by users typically adopt a three-part structure corresponding to these abstractions.

We will now take a closer look at how the SimBricks orchestration framework works and examine some of its most important aspects in detail.

2.2.1. System Configuration#

The System Configuration defines the structure of the virtual prototype. This structure typically reflects the structure of real physical systems and is organized similar.

The System Configuration does not specify how the system will be simulated (that means the System Configuration does not make any simulator choices). Instead it only defines the blueprint of the virtual prototype and thus what the simualted system should look like.

The System Configuration makes use of three key concepts:

  • Components: Represent compoenents of the virtual prototype, such as a Corundum NIC, a Linux-Host, or a Switch.

  • Interfaces: Define intefaces between components through which they will comunicate. An Interface could e.g. be a PCIe interface or a Ethernet interface.

  • Channels: Channels connect interfaces and act as communication paths. These Channels are later upon execution transformed into shared memory queues that link simulator instances.

2.2.2. Simulation Configuration#

The Simulation Configuration determines how the Components from the System Configuration are simulated. Therefore, the System Configuration must be defined beforehand. Once that is done, each Component is assigned to a specific simulator. For example:

  • A Corundum NIC could be simulated by a behavioral C++ simulator or an RTL simulator such as Verilator.

  • A host could be simulated using QEMU or other full-system simulators like gem5.

2.2.3. Instantiation Configuration#

The Instantiation Configuration specifies how the virtual prototype is executed, including execution details such as:

  • Choice of a Runner responsible for the execution of the virtual prototype.

  • Specification of simulation Fragments, that can be distributed across multiple runners.