Uploaded May 2026 | Updated September 2026, 2 weeks ago
Modern FPGAs can swap out a hardware module at runtime while the rest of the chip keeps running, this is partial reconfiguration. But when you try to verify that behavior in simulation, you hit a wall: Verilator and other simulators compile the entire design into a single binary at elaboration time, and cocotb's runtime assumes the module hierarchy never changes. Today, the only way to test a different module configuration is to recompile and restart the simulation from scratch, making it impossible to verify sequences of runtime swaps without deploying to physical hardware.
We present a multi-process simulation architecture that lets cocotb test arbitrary module swaps mid-simulation without modifying cocotb or Verilator. The key idea is to run each swappable module as an independent simulator process. In the main simulation, the module's slot is filled by an adapter which cocotb sees as a normal module, but under the hood, can shuttle signal values to and from the appropriate reconfigurable module simulator processes over shared memory. A lock-free barrier synchronizes all processes at every clock cycle. Swapping a module is just an OS-level process replacement: kill the old one, start the new one, resume the barrier. cocotb's VPI state, Python objects, and test flow are completely undisturbed.
Modern FPGAs can swap out a hardware module at runtime while the rest of the chip keeps running, this is partial reconfiguration. But when you try to verify that behavior in simulation, you hit a wall: Verilator and other simulators compile the entire design into a single binary at elaboration time, and cocotb's runtime assumes the module hierarchy never changes. Today, the only way to test a different module configuration is to recompile and restart the simulation from scratch, making it impossible to verify sequences of runtime swaps without deploying to physical hardware.
We present a multi-process simulation architecture that lets cocotb test arbitrary module swaps mid-simulation without modifying cocotb or Verilator. The key idea is to run each swappable module as an independent simulator process. In the main simulation, the module's slot is filled by an adapter which cocotb sees as a normal module, but under the hood, can shuttle signal values to and from the appropriate reconfigurable module simulator processes over shared memory. A lock-free barrier synchronizes all processes at every clock cycle. Swapping a module is just an OS-level process replacement: kill the old one, start the new one, resume the barrier. cocotb's VPI state, Python objects, and test flow are completely undisturbed.
