Most AI inference is not compute-bound — it is memory-bandwidth-bound. The implication for SoC design is that the memory subsystem (DRAM bandwidth, on-chip SRAM sizing, cache behavior) matters far more than raw compute throughput for realistic workloads. Architects who treat NPU TOPS as the primary metric are optimizing the wrong thing.
For AI accelerators integrated into an SoC, the dataflow architecture — how data moves between compute units, scratchpads, and DRAM — dominates both performance and energy. This is a hardware/software co-design problem: the optimal dataflow depends on the network topology being run, which means the accelerator’s programming model must expose enough flexibility for software to exploit the hardware efficiently.
You cannot reason about these trade-offs in the abstract. A Verilator-simulated SoC running real inference workloads tells you far more than any analytical model. This is where simulation-driven co-design earns its keep.
]]>The core idea is simple: hardware and software teams should not work in isolation and reconcile at the end. They should share a simulation environment where architectural decisions are immediately visible to the software side, and software performance on real workloads feeds back into hardware architectural choices.
In practice, this means your RTL simulation must be fast enough and complete enough to run real software — not just synthetic benchmarks. That is why Verilator and QEMU are so central to my workflow: they make the feedback loop fast enough to actually use.
Most of the contentious co-design decisions happen at the hardware-software interface: register maps, interrupt behavior, DMA programming models, power management protocols. Getting these wrong is expensive in silicon. Getting them right requires both sides at the table, with a shared simulation environment they both trust.
Academic co-design papers often propose elegant joint optimization frameworks that assume hardware and software can be changed simultaneously and freely. Real SoC development is messier: hardware has a longer iteration cycle, software teams have deadlines, and the interface contracts freeze early. Good co-design methodology accounts for this asymmetry.
]]>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.
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).
Verilator compiles your SystemVerilog RTL into optimized C++ and runs it natively. For large SoC simulations running realistic software workloads, this is often 10–100x faster than event-driven commercial simulators. When you need to boot Linux on your simulated SoC to run a benchmark, that speedup is not optional — it is the difference between a usable flow and an unusable one.
Verilator is open source. That means I can instrument the simulation model, inject custom C++ side-channels, integrate it with QEMU via a shared memory interface, and generally treat the compiled simulation as a library rather than a black box. Commercial simulators rarely allow this level of integration.
Verilator is a two-state simulator (no X/Z propagation by default) and does not support all SystemVerilog constructs out of the box. For gate-level simulation or formal verification, you still need other tools. But for architecture exploration and hardware/software co-design, it is hard to beat.
]]>