Modeling Custom SoC Peripherals in QEMU

1 minute read

Published:

One of the most practical skills in pre-silicon SoC development is the ability to model custom peripherals inside QEMU so that your software team can begin driver development months before tape-out. Here is a quick walkthrough of how I approach this.

The Basic Pattern

Every QEMU device model implements a small set of C callbacks: read, write, and reset. These map to MMIO accesses from the emulated CPU. The key is to register your device’s memory region with the correct base address and size matching your SoC memory map.

Interrupt Modeling

Most peripherals need to signal the CPU. QEMU exposes IRQ lines that you connect during machine init. In your device model, call qemu_irq_raise and qemu_irq_lower to simulate interrupt assertion and deassertion — your Linux driver’s interrupt handler will see exactly the same behavior it will see on real silicon (assuming your model is accurate).

Lessons Learned

  • Keep your QEMU model and your RTL spec in sync. Divergence here is the most common source of “works in emulation, broken on silicon” bugs.
  • Model error conditions explicitly — drivers need to handle them, and QEMU is the only place to test them pre-silicon.
  • Use QEMU’s tracing infrastructure liberally during bring-up; it saves enormous debugging time.