Jesse

Jesse

he/him

PhD researcher in SoC hardware/software co-design and system-level simulation. Working with Verilator and QEMU to bridge RTL and architecture. Passionate about AI-driven SoC design with an industry mindset.

Hardware/Software Co-Design: What It Actually Means in Practice

1 minute read

Published:

“Hardware/software co-design” is a phrase that gets thrown around a lot in academic papers. Having spent time both in research and close to industry SoC development, here is what it actually looks like in practice.

It Is Mostly About Feedback Loops

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.

The Hardest Part Is the Interface

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.

What Academia Gets Wrong

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.

You May Also Enjoy

AI Workloads Are Changing SoC Architecture — Here Is How

1 minute read

Published:

Neural network inference workloads have a fundamentally different memory access pattern and compute structure compared to traditional CPU workloads. This is reshaping how SoC architects think about memory hierarchy, interconnect, and heterogeneous compute integration.

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.

Why I Use Verilator Instead of Commercial Simulators

1 minute read

Published:

When I started my PhD, I assumed the right tool for RTL simulation was one of the big commercial simulators — VCS, Questa, or similar. A year in, I switched entirely to Verilator. Here is why.