axiZero: Configurable AXI Interconnect Generator

What axiZero does

Every SoC-style FPGA design ends up needing the same piece of plumbing: an interconnect that routes a few bus masters (CPU, DMA, debug bridge) to a set of slaves (DDR, SRAM, peripheral registers). The usual options are a vendor IP wizard that ties the design to one toolchain, or hand-written glue that grows arbitration bugs as the design evolves.

axiZero takes a different route: you describe the topology in a short YAML file — how many masters and slaves, which protocol each port speaks, the address map, the arbitration policy — and a generator built on SpinalHDL produces a non-blocking M×N crossbar as plain synthesizable Verilog. The same flow also generates standalone AXI4-Stream utility cores for the data-plane side of a design. If you would rather not run the generator at all, fifteen pre-built configurations ship in the repository, ready to instantiate.

The YAML is the design entry

A configuration lists the masters, the slaves, and the fabric options. Each port is independently AXI4 or AXI4-Lite; adapters and width converters are inserted automatically where the ports disagree:

designs:
  - name: MySoC
    arbitration: qos          # or round_robin, fixed, weighted_round_robin
    max_outstanding: 4        # pipelined mode
    fabric_data_width: 64
    masters:
      - { type: full, data_width: 64, id_width: 4 }   # CPU
      - { type: lite, data_width: 32 }                # DMA / debug
    slaves:
      - { type: full, base: 0x80000000, size: 0x40000000 }  # DDR
      - { type: lite, base: 0x40000000, size: 0x10000 }     # regs

Then python scripts/axizero.py generate my_design.yaml writes the Verilog. Port names follow Vivado's AXI conventions, so the module drops into a block design and is recognized as an AXI peripheral without manual interface mapping.

What's inside

• Full AXI4 and AXI4-Lite, mixed per port. IDs, bursts, and outstanding transactions on full ports; automatic protocol adapters between them — a combination most open-source interconnects do not offer.
• Data-width conversion. Burst-splitting upsizers and downsizers at port boundaries, covering FIXED, INCR, and WRAP bursts.
• Four arbitration policies. Round-robin, fixed-priority, weighted round-robin, and QoS (highest AXQOS wins) with aging-based anti-starvation.
• Pipelined operation. Configurable outstanding transactions with per-slave write FIFOs and ID-based response routing.
• Practical extras. Register slices per port for timing closure, IPIF-compatible write presentation, and an AXI3-to-AXI4 bridge with a WID reorder buffer.
• AXI4-Stream utility cores. Six standalone stream cores from the same YAML flow (kind: axis): register slice, width adapter, FIFO, packet-aware arbiter-mux, packet demux, and broadcaster, each with optional TKEEP/TSTRB/TLAST/TID/TDEST/TUSER sidebands and standard s_axis/m_axis port naming.

The generated logic is light: the smallest pre-built crossbar (1 master, 4 AXI4-Lite slaves) synthesizes to 237 LUTs and 8 flip-flops on an Artix-7, the stream cores range from 2 to 49 LUTs, and no configuration uses BRAM or DSP blocks. Current limitations are documented rather than hidden: all ports share one clock (no clock domain crossing yet), and the Lite-only crossbar path is single-outstanding per slave.

How it's verified

An interconnect generator has a specific verification problem: it is not one design but a family of them, and a bug can live in the generator rather than in any single output. axiZero addresses this with three independent layers, all in the repository and all run in CI.

Unit tests at the source (SpinalSim)

96 tests across 16 suites exercise the components before generation: arbitration under contention (fixed-priority ordering, weighted-round-robin throughput proportionality, QoS priority with aging-based anti-starvation), width conversion across all three AXI burst types (INCR, FIXED, WRAP — including the actual wrap-around case), mixed Full/Lite adapter insertion, IPIF-style slaves that require AW and W simultaneously, the AXI3 bridge's write-interleaving reorder buffer, and the AXI4-Stream cores down to sparse-TKEEP edge cases.

Integration tests against the output (cocotb)

Unit tests alone would still leave a gap: they verify the source, not the artifact you instantiate. So a second, independent layer — 34 cocotb tests using the cocotbext-axi bus functional models — runs directly against the pre-built Verilog files. These cover address routing and isolation, 64-beat bursts, concurrent dual-master traffic, starvation checks, randomized regressions (up to 80 random transactions per suite), and stream-BFM tests for all six AXI4-Stream cores — on the exact files a user would drop into a project. A separate CI job regenerates every tracked netlist on each run and fails if the committed output differs, so the shipped Verilog cannot silently drift from the generator.

Hardware validation (Arty A7-100T)

Five test suites run on a Xilinx Arty A7-100T at 100 MHz, with MicroBlaze as a live master and hardware traffic generators as the others:

• Base 1M×4S: ten tests from single-word accesses up to a full 64 KB BRAM checkerboard (16,384 words written and verified) and cross-slave boundary crossings.
• Weighted round-robin 2M×4S: two masters writing concurrently under contention, with the lower-weight master checked for forward progress.
• QoS stress 4M×4S: MicroBlaze at QoS 15 against three traffic generators at QoS 8/4/0, each with a different access pattern (sequential, reverse-order, random short bursts), monitored continuously — 14,000+ iterations and 70,000+ passing checks over a 10-minute run with zero failures.
• AXI3 adapter in the data path: every MicroBlaze transaction routed through a full AXI4→AXI3→AXI4 round-trip, proving the bridge's reorder buffer and field conversion in silicon rather than just simulation.
• AXI4-Stream smoke test: a self-running datapath chains all six stream cores — three sources through the arbiter-mux, FIFO, register slice, 32→8 width adapter, demux, repack, and broadcaster — with a deliberately stalled sink; MicroBlaze passes the test only if frame counts, checksums, routing, and observed backpressure all check out on the board.

The hardware tests are reproducible, not a one-off claim: each suite has a runner script that finds your Vivado install, builds the bitstream, compiles the MicroBlaze firmware, programs the board, and runs the checks — on Windows or Linux.

Frequently asked questions

What license does axiZero use?

MIT. The generated Verilog is yours to use in commercial or open designs without share-alike obligations — unlike some interconnect projects under copyleft hardware licenses, which can require releasing your full design.

Which FPGAs does it support?

The output is plain Verilog with no vendor primitives, so any FPGA or ASIC flow works. Vivado users get AXI-convention port naming for clean block-design integration; validation hardware is a Xilinx Arty A7-100T.

Can bard0 help integrate or extend it?

Yes. axiZero is maintained by bard0 design, and we take on integration, customization, and extension work — from adding a topology feature to wiring the interconnect into a full SoC design with our other cores, like the MIPI CSI-2 Aggregator and FPGA ISP.