RV32I on Zynq-7020 · dynamic function exchange

One core. One slot. Two accelerators.

The same program runs on the same static logic. Swapping the partial bitstream in the reconfigurable slot changes the answer.

Simulation
2.5msto swap the accelerator (kernel driver)
111KBpartial bitstream, 2.7 % of the full 4.0 MB
26×faster than reloading the whole device
50MHzcore clock, read back from FCLK0

The core, one clock at a time

cycle 0 · pc 0x000
42
dmem word 4 · the program's answer fn0 on (6, 7) → 6 × 7 Multiplier in the slot
One clock of a single-cycle core
Fetch–
Decode–
Execute–
Write back–
imem · sw/program.hex (41 instructions)
    CFU slot · MMIO at 0xF000_0000 Multiplier (cfu_mul.v)
    op_a 0op_b 0fn 0→ 0
    Registers
    dmem · read over AXI GPIO on the board

    Swap the slot

    xc7z020clg400-1 · device view
    core running Press swap: the core is held in reset while about 275 configuration frames stream into the Pblock.
    Swap timeline

      The animation runs about 500× slower than the real swap. Frames on 7-series parts span a full clock-region height, so the slot fills column by column. That is why partial-bitstream size follows Pblock width, not height.

      How often does a swap fail?

      overnight swap soak

      The board right now

      Swap vs full reload

      measured · PYNQ-Z2 · 20 swaps per tier · log scale
      full reload · 4.0 MBpartial swap · 111 KB

      The driver path does a DMA setup, cache flush and completion poll on every load. That fixed cost is why 2.5 ms sits above the 0.28 ms PCAP limit, and why 26× trails the 36× size ratio. PYNQ adds about 60 ms of bit→bin conversion on top.

      Questions we expect

      Why not 0.28 ms?

      PCAP peak bandwidth is a floor. The Linux zynq-fpga driver adds DMA setup, cache maintenance and a completion poll per load, and at 111 KB that fixed cost dominates. PYNQ adds a bit→bin conversion and a /lib/firmware copy on every call.

      Why hold the core in reset instead of a DFX decoupler?

      Nothing static samples the slot while it changes, and the reset guarantees that. A decoupler is needed when the static side keeps running against the partition.

      What limits the core clock?

      The CFU result had to reach the register file in one cycle on a single-cycle machine: a path of roughly 16 ns, so 50 MHz (20 ns) closes with about 4 ns of slack and 62.5 MHz (16 ns) did not. The 62.5 MHz build registers the result in the static region, which costs one clock: software leaves one nop after every CFU start. It closes 16 ns with 1.18 ns of slack. The accelerators' source is unchanged, but each build has its own partial bitstreams (same size, different bytes): a partial is tied to the locked static design it was built against, so the page loads the matching pair when you switch builds.

      Why is the partition 111 KB for 81 LUTs?

      7-series configuration frames span a full clock-region height, so partial size scales with Pblock width, not with what is inside it. This is already the narrow geometry, one DSP column wide. It was 221 KB with two.

      Any failures?

      Yes. A swap is occasionally ignored: the driver is given the right bitstream and reports success, but the slot keeps its old contents, and later partial loads are ignored too until the whole device is reloaded. The board server checks every swap and, on a miss, reloads the full bitstream, and the result box says so. The root cause is still open.