# pulp-platform/axi: Modular SystemVerilog for AXI4 Interconnects > pulp-platform/axi is a collection of synthesizable SystemVerilog modules for AXI4, AXI4-Lite, and AXI4 ATOP communication fabrics. Its composable design suits hardware engineers building heterogeneous on-chip networks, but adopters must assess EDA compatibility and the custom Solderpad license themselves. **pulp-platform/axi** — AXI SystemVerilog synthesizable IP modules and verification infrastructure for high-performance on-chip communication - Repository: https://github.com/pulp-platform/axi - Stars: 1,734 · Forks: 375 - Language: SystemVerilog - License: NOASSERTION - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/pulp-platform-axi ## What pulp-platform/axi solves inside an SoC pulp-platform/axi addresses a recurring System-on-Chip problem: connecting AXI initiators and targets whose interfaces do not naturally have identical data widths, ID widths, clock domains, or buffering requirements. The repository provides AXI4 modules for higher-performance communication, AXI4-Lite components for lightweight control traffic, and AXI4 atomic transaction support through ATOP-related filtering. Its stated scope also reaches endpoints such as DMA engines and on-chip memory controllers, although the module list in the README is centered primarily on interconnect infrastructure. The intended users are hardware designers constructing an on-chip communication network rather than application developers looking for a conventional software package. The repository can serve ASIC or FPGA projects that use AXI-family interfaces and synthesize SystemVerilog. It also targets teams that need reusable network elements rather than one fixed interconnect configuration. That distinction matters because the project favors composition: a design may connect a demultiplexer, crossbar, width converter, FIFO, and clock-domain-crossing module instead of configuring one universal switch. The repository does not document a board, operating system, or host-side installation. It is RTL source code plus verification infrastructure, with a Bender manifest, source lists, documentation, tests, and a Makefile. Adoption therefore begins with integration into an existing RTL build and tool flow, not with installing a daemon or binary. The README also frames full AXI standard compliance as a design goal, but that is a stated project objective rather than independent proof that every module suits every AXI configuration. ## The modular AXI network model The central architectural choice is topology independence through small, composable elements. `axi_mux` and `axi_demux` route an AXI interface across multiple interfaces, while `axi_xbar` supplies a commonly needed crossbar. This permits a designer to construct a topology instead of accepting one hard-coded interconnect. The README explicitly favors design by composition over design by configuration and applies that preference even where a parameter might appear convenient. Several modules solve adaptation problems that arise when subnets have different properties. `axi_dw_converter` supports AXI interfaces with different data widths, while `axi_dw_downsizer` and `axi_dw_upsizer` handle the narrower and wider directions respectively. `axi_iw_converter` is listed among the modules for heterogeneous networks, and `axi_id_remap` maps wide IDs toward narrower interfaces. `axi_id_serialize` takes a different approach by reducing available ID concurrency through serialization when necessary. That distinction can affect transaction-level throughput, so ID handling should be reviewed as a design tradeoff rather than treated as transparent renaming. The repository also separates protocol control from timing and buffering concerns. `axi_atop_filter` identifies write transactions with a nonzero `aw_atop`, `axi_burst_splitter` divides AXI4 bursts into single-beat transfers, and `axi_burst_unwrap` converts wrapping bursts into up to two incremental bursts. `axi_fifo` buffers requests independently for AXI4 channels, while `axi_cdc` handles clock-domain crossing through a Gray FIFO implementation. Based on the repository layout, these modules are intended to be instantiated in SystemVerilog and joined through their ports rather than controlled through an external configuration service. Not every transformation is free. Splitting, serializing, converting, buffering, or crossing clock domains introduces logic and changes timing or concurrency behavior. AXI channel rules and response ordering remain design obligations. The README does not publish a universal performance figure or area estimate for these compositions, so any claim that a particular network will meet bandwidth or timing targets would need synthesis and simulation evidence from the integrating project. ## AXI4-Lite, DMA, and memory-facing building blocks The project covers both performance-oriented AXI4 communication and lighter AXI4-Lite traffic. The README describes AXI4 plus AXI5 ATOPs as the high-performance path and AXI4-Lite as the lightweight path. Modules listed in the repository include `axi_lite_regs`, `axi_lite_to_apb`, `axi_lite_to_axi`, `axi_lite_mailbox`, and `axi_lite_xbar`. These indicate coverage for register-facing control, protocol conversion, messaging, and crossbar construction, though the README does not define each module's complete port list or parameter constraints. For memory-oriented designs, `axi_from_mem` behaves like an SRAM while issuing AXI4 requests downstream. The Makefile also identifies verification targets named `axi_sim_mem`, `axi_to_mem_banked`, and `axi_atop_filter`, among others. This indicates that the repository includes both reusable RTL and simulation-oriented infrastructure. It does not, however, establish that `axi_from_mem` is a physical memory compiler replacement. Its documented behavior is architectural: it presents SRAM-like behavior and makes downstream AXI4 requests. `axi_cut` serves a particularly clear structural purpose. It breaks all combinational paths between its input and output, which can create a boundary in timing-sensitive interconnects. `axi_err_slv` provides the opposite kind of endpoint behavior: it returns AXI decode or slave errors for transactions sent to it. Such modules are useful for deliberate network control, isolation, and error-response design, but the README does not provide a complete example showing how registers or address decoding should be attached. Endpoint availability should therefore be checked module by module. The project description mentions DMA engines and on-chip memory controllers as part of the broader platform aim, but the module list does not justify assuming that every endpoint is equally complete or documented. An SoC team should inspect the relevant source file, generated documentation for the selected tag, and formal or simulation coverage before depending on a module. ## EDA compatibility and repository maintenance costs The repository states that it aims for compatibility with recent versions of EDA tools and implements standardized synthesizable SystemVerilog. The root entries support this orientation: `src/` contains RTL, `test/` contains verification work, `.gitlab-ci.yml` defines continuous integration, and `scripts/` contains repository automation. The Makefile refers to `questa-2025.1 vsim` for designated IIS environments and otherwise uses `vsim` for simulation. It also selects `synopsys-2022.03 dcnxt_shell` for designated IIS environments and otherwise uses `dc_shell` for synthesis-related work. Those names are configuration defaults, not a promise that every contributor has those commercial tools installed. A prospective user therefore needs an existing simulation and synthesis environment, or compatible alternatives accepted by the project. Because the README does not present a complete EDA support matrix, tool-version verification belongs in the first integration phase. The repository is not archived, and its last push was on 2026-09-24. Recent tagged releases include v0.39.11 on 2026-09-08, v0.39.10 on 2026-06-19, and v0.39.9 on 2025-11-21. These dates show recent project changes, but they do not remove the cost of upgrading a hardware IP dependency. Changes to module interfaces, parameters, verification infrastructure, or supported tools can affect downstream RTL and regression environments. For repeatable integration, users should select a tag rather than depend implicitly on `master`. The README states that generated module documentation can target a tag by replacing `master` in its documentation URL with that tag. Pinning a release also makes it possible to keep documentation, source lists, and Bender dependencies aligned. Maintenance cost will depend on the number of modules adopted and on whether an upgrading team tracks changes across the repository. ## Installation and first integration tutorial The project provides no software installation instructions because it is a SystemVerilog RTL repository. It also gives no complete RTL instantiation in the README, so this tutorial does not invent module parameters, ports, clocks, widths, or tool flags. The first real step is to obtain the repository and place it under the dependency-management path expected by the SoC build. The repository exposes a Bender manifest, `Bender.yml`, plus `Bender.lock`, `axi.core`, `src_files.yml`, and `ips_list.yml`. Those files are the concrete integration surface visible in the repository. A team already using Bender would inspect the manifest and lock file, choose a release or commit, add the dependency through its established dependency process, and then reconcile source inclusion with its own build system. The README does not document an exact `bender` command, so no command is supplied here. The Makefile provides a `help` target, with summaries for tasks including elaboration, compilation, and simulation. The Makefile also defines `sim_all`, `clean`, and a collection of testbench targets through variables. Because the remainder of the file is truncated in the repository file listing, its exact recipes should be inspected in the selected checkout before running them. For the first RTL use, start with one narrowly selected module, such as `axi_dw_downsizer` or `axi_id_remap`. Confirm its module declaration and parameters in the chosen tag's source and generated documentation, add the required source through the existing RTL manifest, and connect one compatible AXI interface to another. Then add the smallest testbench that exercises the project's documented responsibility: width adaptation for a downsizer, ID mapping for a remapper. Do not begin with `axi_xbar` or `axi_cdc` unless the design actually needs an interconnect or clock boundary. This sequence keeps interface review separate from network-level verification and avoids treating the repository's collection of modules as a ready-made SoC. ## SHL-0.51 licensing and reuse boundaries The README identifies Solderpad Hardware License 0.51, and the Makefile repeats the Solderpad Hardware License, Version 0.51 notice. GitHub classifies the repository license as Other because of this custom license, so an adoption decision should not treat the project as conventionally permissively licensed merely because its source is visible. The `LICENSE` file is the authoritative project-specific text for use conditions. This review does not provide legal advice and does not infer permissions or obligations that are not visible in the repository. Hardware IP licensing can affect redistribution, modification, internal use, and the relationship between derived RTL and surrounding designs. Organizations with formal open source compliance rules may need a separate review even if the repository is incorporated through a dependency manager. The practical cost appears before simulation begins: license review, provenance tracking, and coordination with downstream chip or FPGA programs. Users should preserve the selected license version and review changes when upgrading to a different tag. The release dates alone do not indicate that licensing terms remained unchanged, and the repository does not provide a historical license comparison. Commercial-tool availability is a second cost boundary. The Makefile's references to Questa and Synopsys Design Compiler indicate that the development flow can involve licensed software. That does not establish licensing terms for those tools, but it means an open repository does not make the complete verification environment cost-free. ## Where pulp-platform/axi is the wrong abstraction The clearest wrong-tool case is a project that expects a complete, preconfigured SoC interconnect or a board-ready AXI subsystem. The repository offers building blocks, and its design philosophy explicitly favors back-to-back module instantiation. That approach gives topology freedom, but it leaves the integrating engineer responsible for address decoding, endpoint connections, parameter choices, timing closure, and end-to-end protocol checking. It is also a poor match for a pure software team with no SystemVerilog build, simulation model, or FPGA or ASIC implementation flow. There is no documented package manager, runtime, or host installation command in the README. Someone seeking a Python API, a command-line network simulator, or a Linux kernel driver would not find that role represented here. AXI4 specialization creates another boundary. `axi_atop_filter`, wrapping-burst conversion, burst splitting, ID serialization, and clock-domain crossing solve specific protocol or structural problems. Using them unnecessarily adds hardware and may reduce concurrency or timing slack. Conversely, assuming generic AXI behavior without reviewing a module's implementation can create protocol errors, particularly around response handling, outstanding transactions, and ID remapping. A genuine alternative is to purchase or obtain a vendor-qualified AXI interconnect that arrives as a configurable subsystem with integration documentation, support obligations, and tool-specific collateral. That approach moves more work into the supplier's product but can reduce the engineer's burden of composing and qualifying individual RTL blocks. Another alternative is to retain a single homogeneous AXI interface and redesign around matching widths, IDs, and clock domains. Avoiding adaptation and crossing modules may be simpler when traffic requirements do not justify heterogeneous interconnects. pulp-platform/axi sits between those choices. It offers source-level composability rather than a turnkey support contract, and that boundary should drive adoption. ## Conclusion pulp-platform/axi is appropriate for hardware teams that need composable AXI infrastructure and can support its SystemVerilog, EDA integration, and Solderpad Hardware License obligations. It is a poor fit for users seeking a packaged bus subsystem with documented board-level setup or a conventional open source license. Before adoption, verify the required RTL module against the target EDA tools, review the exact interface parameters and channel behavior, and have counsel assess the project-specific implications of Solderpad Hardware License 0.51. ## FAQ ### What protocols does pulp-platform/axi support? The repository provides modules for AXI4 and AXI4-Lite, and its high-performance implementation includes AXI4 ATOPs from AXI5. It also includes conversion, routing, buffering, and clock-domain-crossing components. ### How is pulp-platform/axi integrated into a SystemVerilog design? The repository describes composing modules rather than configuring one universal network. Its `Bender.yml`, `axi.core`, and source-list files provide integration surfaces, but the README does not give a complete instantiation example or dependency-manager command. ### What license applies to pulp-platform/axi? The README identifies Solderpad Hardware License 0.51. The `LICENSE` file is the authoritative source for its terms, and this custom license should be reviewed separately from ordinary permissive open source licensing expectations. ## Sources - [Issues](https://github.com/pulp-platform/axi/issues) - [pulp-platform/axi on GitHub](https://github.com/pulp-platform/axi) - [README](https://github.com/pulp-platform/axi/blob/master/README.md) - [Releases](https://github.com/pulp-platform/axi/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pulp-platform-axi