Device N … TCP/IP 192.168.x.x TLM 2.0 QoM (QEMU Object Model) Original Method: • Aggregate all hardware into a single QEMU device (QoM) Cons: • A single driver must handle every feature, making it difficult to design, test, and maintain • Poor flexibility for adding or iterating on new hardware/plug-ins VPIPC
Device N … TCP/IP 192.168.x.x TLM 2.0 Proposed Method: Decouple one large device into several devices. All traffic is carried over one shared VPIPC channel (single TCP/IP endpoint) VPIPC QoM 0 QoM 1 QoM N Pros: • New devices can be added or replaced without touching others • Per-device drivers are smaller and easier to implement/maintain • The same drivers can be reused for the corresponding FPGA/ASIC IP blocks. …
accelerate the simulation process • Add Shared-Memory IPC as the primary transport to remove kernel/TCP stack costs (e.g. context switches, copies, timers) • Keep TCP/IP as a tested fallback path • Refactor the QEMU device model, split the monolithic device into multiple QOM devices that share the same IPC endpoint • Workload • Need larger, representative workloads (control-heavy, DMA-streaming, mixed, multi-device) to validate AISVP’s results (throughput, tail-latency, and scalability) and improve external validity
AISVP • To leverage event-driven SystemC (TLM-2.0), we should avoid using cycle-accurate models in the VP • If we limit the SoC simulation system environment to SystemC only, we can delegate timing entirely to SystemC, which means we treat QEMU or other traffic sources as functional producers/consumers • QEMU stays purely functional, providing instruction and device behavior only • SystemC/TLM-2.0 owns all timing approximation, via temporal decoupling and optional lightweight plug-ins such as trace analysis when needed • By building the end-to-end model-deployment workflow on AISVP, the SoC simulator system serves DSE, for rapid prototyping and analysis of performance trends across devices/configurations rather than exact cycle counts