# openwifi-hw: an IEEE 802.11 baseband in FPGA

> openwifi-hw is the FPGA half of openwifi, a Linux mac80211 compatible full stack Wi-Fi design built on software defined radio, written in Verilog and VHDL against Xilinx and Analog Devices parts. Building it means Vivado, the Analog Devices HDL library, a per board IP preparation step and a bitstream export, so this is a hardware project with a real toolchain, not a library you drop into a build.

**open-sdr/openwifi-hw** — open-source IEEE 802.11 WiFi baseband FPGA (chip) design: FPGA, hardware

- Repository: https://github.com/open-sdr/openwifi-hw
- Stars: 915 · Forks: 312
- Language: Verilog
- License: AGPL-3.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/open-sdr-openwifi-hw

## The hardware half of a full stack Wi-Fi design

openwifi is described as a Linux mac80211 compatible full stack IEEE 802.11 Wi-Fi design based on software defined radio, and this repository holds the hardware and FPGA side of it. The README is explicit that the repository includes the hardware design and is to be used together with the openwifi repository, which holds the driver and the software tools.

That split is the whole architecture. The FPGA implements the baseband, and the Linux side presents it to the kernel as a mac80211 device, which means ordinary Linux wireless tooling can see it. The primary language is recorded as Verilog, and the topics list includes VHDL, because the design mixes both, along with OFDM, CSMA, DMA, HLS, Xilinx, Zynq, AD9361, software defined radio and RTL.

The point of doing this rather than buying a radio is that you own the baseband. A research group studying frame aggregation, or MAC behaviour, or a novel modulation has to be able to change the hardware, and a commercial chipset will not let you.

There is also a software to hardware relationship worth naming. The FPGA files are pre-compiled in a separate repository, openwifi-hw-img, where boards/$BOARD_NAME/sdk/ holds the FPGA bit file, the ILA .ltx file if an ILA is inserted, and other initialisation files.

## A board table that tells you which hardware you can use

The supported board list is a table in the README with three columns: the environment variable name, the hardware, and whether a Vivado licence is needed. That third column is the one to read first, because it decides whether you can build the design at all.

Several entries need no Vivado licence. The Xilinx zed board with FMCOMMS2/3/4, the ADRV9364-Z7020 with ADRV1CRR-BOB, the Xilinx ZC702 with FMCOMMS2/3/4, the MicroPhase enhanced ADALM-PLUTO named antsdr, the MicroPhase new antsdr named e310v2, the smaller and cheaper enhanced ADALM-PLUTO named antsdr_e200, the HexSDR Raspberry Pi sized SDR named sdrpi, and two unofficial low cost Zynq 7020 plus AD9361 boards named neptunesdr and LibreSDR.

Others do need one. The Xilinx ZC706 with FMCOMMS2/3/4, the ADRV9361-Z7035 with ADRV1CRR-BOB or FMC, the Xilinx ZCU102 with FMCOMMS2/3/4, and the RFSoC4x2 board.

The unofficial boards being listed at all is a notable part of the story. A board with no Vivado licence requirement and a community maintainer is how a research project becomes accessible to people without a corporate Xilinx seat, and the ADALM-PLUTO based entries are the cheapest way in, since the Pluto is a low cost SDR with a Zynq on board.

Each board entry links to notes, and the notes live under kernel_boot/boards/BOARD_NAME/ in the tree, for example the antsdr notes and the e310v2 README.

## Preparing the toolchain before you build anything

The build preconditions are specific and are worth reading as a checklist.

You need Vivado 2022.2 with Vitis, and the note distinguishes Vitis from Vitis HLS explicitly: it should be your_Xilinx_install_directory/Vitis, and NOT Vitis_HLS. If Vitis is missing you can add it through the Xilinx design tools menu, or from the Help menu inside Vivado itself.

You also need the evaluation licence for the Xilinx Viterbi Decoder installed into Vivado, which is the piece that makes some boards require a licence.

The operating system should be Ubuntu 18, 20 or 22 LTS, which are the releases tested. Other distributions might work. There is a package to install, libtinfo5, and for Ubuntu 24 LTS the default libtinfo6 will not work so libtinfo5 has to be installed by hand.

The README gives the two commands to run, which are a wget of the libtinfo5 deb from the Ubuntu archive pool and then a sudo dpkg -i of the downloaded package.

Then the Analog Devices HDL library is prepared once, with an environment variable pointing at the Xilinx installation.

```bash
export XILINX_DIR=your_Xilinx_install_directory
(Example: export XILINX_DIR=/opt/Xilinx. The Xilinx directory should include sth like: Downloads, SDK, Vivado, xic)
./prepare_adi_lib.sh $XILINX_DIR
```

The same pattern repeats per board, because the board specific IP depends on which radio and carrier you have.

```bash
export BOARD_NAME=your_board_name
(Example: export BOARD_NAME=zc706_fmcs2)
./prepare_adi_board_ip.sh $XILINX_DIR $BOARD_NAME
```

## From IP preparation to a bitstream on disk

After the library and board IP are prepared, the openofdm_rx IP has to be fetched, and the README notes that this is only done once and only after openofdm is updated.

```bash
./get_ip_openofdm_rx.sh
```

Then the IP repository for the top level project is generated, which takes a while.

```bash
cd openwifi-hw/boards/$BOARD_NAME/
../create_ip_repo.sh $XILINX_DIR
```

There is a known failure mode here worth knowing in advance. If Vitis HLS reports an invalid argument error asking for an integer value, a Xilinx support patch has to be applied, and the link to it is given in the README.

The Vivado steps are short because the script does most of the work.

```bash
source ../openwifi.tcl
Click "Generate Bitstream" in the Vivado GUI.
(Will take a while)
File --> Export --> Export Hardware --> Next --> Include bitstream --> Next --> Next --> Finish
```

The export step is invoked automatically by the previous script, so the manual sequence is mostly for the cases where you want to do it yourself. Finally the FPGA files are stored into the directory that the openwifi software build expects.

```bash
cd openwifi-hw/boards
./sdk_update.sh $BOARD_NAME $OPENWIFI_HW_IMG_DIR
```

That command stores the FPGA image, the .xsa and .ltx files and the related git information into the target directory, which the openwifi repository's build environment then picks up.

## Working on the IP cores individually

The design is decomposed into IP cores under the ip/ directory, with names like xpu and tx_intf. To create the Vivado project for one of them and do modification, simulation or other work, you go into that directory and run a script.

```bash
../create_vivado_proj.sh $XILINX_DIR ip_name.tcl
```

That gives you a standalone Vivado project for one core, which is the practical way to simulate or rewrite it without building the entire baseband. The alternative, running the top level project, is a much heavier operation.

The simulation story is separate again. The README carries a table of contents entry for simulating IP cores alongside modifying them, and the tools directory contains a scripts/ directory for helper scripts such as checkpatch for contributors, so there is a contribution path with style checking rather than ad hoc patches.

There is also a section on conditional compilation by Verilog macro, which matters for a design that has to support a dozen boards. Being able to switch features with a macro, rather than maintaining a branch per board, is what keeps that support matrix maintainable.

The final entry in the table of contents is migration to a new Analog Devices release and Vivado version, and the presence of that section tells you how much work a toolchain upgrade is in a project built on a vendor HDL library.

## Licensing, the subscription tier and what this is for

The licensing is a compound arrangement and it needs reading carefully.

The openwifi code has dual licences. AGPLv3 is the open source licence, and for non open source use and advanced features there is a contact form on the project site for a commercial licence. The project also states that it remains committed to open source as its foundation, and that a subscription is the route to advanced features and dedicated support.

Then there is the third party dimension. The openwifi project leverages some third party modules, and it is the user's duty to check and follow the licences of those modules according to the purpose and usage of the work. An example explanation of these compound licence conditions from Analog Devices is linked for that reason.

That last point is the one to take seriously in an FPGA project, because the hardware design leans on the Analog Devices HDL library and on the openofdm receiver, both of which are separate codebases with their own terms.

On what the project is and is not, the framing in the README is research oriented. openwifi-hw is the hardware repository to be used together with the openwifi driver and software tools, and the companion projects are the openwifi repository itself, mesh_tools for mesh handling in a different domain, and the openwifi-hw-img repository of pre-compiled bitstreams. There are also Windows tips linked, since the toolchain is Linux oriented and the README acknowledges that.

The repository is not archived and the last push was on 2026-10-13, and it publishes no GitHub releases, so the version of the design is tracked by commits and by the pre-compiled image repository rather than by tags.

## Conclusion

Adopt openwifi-hw if you are doing research on the IEEE 802.11 physical layer and want a baseband you can read, modify and synthesise, since the design is open, the IP cores are separable and each supported board has a documented preparation path. Do not expect a plug and play Wi-Fi radio for ordinary networking, since the project is a research platform with a subscription tier for advanced features and dedicated support, and it needs licensed Vivado tooling. Verify first which board you have and whether its row in the board table needs a Vivado licence, since several do not, that you have Vivado 2022.2 with Vitis rather than Vitis HLS, and that you have read the AGPL terms and the third party module licence conditions before using the design in a product.

## FAQ

### What do I need to build openwifi-hw?

Vivado 2022.2 with Vitis and not Vitis HLS, the evaluation licence for the Xilinx Viterbi Decoder for the boards that need one, an Ubuntu 18, 20 or 22 LTS release, and the libtinfo5 package installed manually on Ubuntu 24. Then run prepare_adi_lib.sh once and prepare_adi_board_ip.sh once per board.

### Which openwifi-hw boards do not need a Vivado licence?

The zed_fmcs2, adrv9364z7020, zc702_fmcs2, antsdr, e310v2, antsdr_e200, sdrpi, neptunesdr and LibreSDR entries are marked as not needing one. The zc706_fmcs2, adrv9361z7035, zcu102_fmcs2 and rfsoc4x2 boards do need a licence.

### How do I compile an individual IP core in openwifi-hw?

Go into the ip/ip_name directory and run ../create_vivado_proj.sh $XILINX_DIR ip_name.tcl, which creates a standalone Vivado project for that core so you can modify or simulate it. To apply the result to the top level project you rerun create_ip_repo.sh.

### What licence applies to openwifi-hw?

The openwifi code is dual licensed, with AGPLv3 as the open source option and a commercial licence for non open source use and advanced features. The design also leverages third party modules such as the Analog Devices HDL library, and the project states it is the user's duty to check and follow those licences too.

## Sources

- [Issues](https://github.com/open-sdr/openwifi-hw/issues)
- [License: AGPL-3.0](https://github.com/open-sdr/openwifi-hw/blob/master/LICENSE)
- [open-sdr/openwifi-hw on GitHub](https://github.com/open-sdr/openwifi-hw)
- [README](https://github.com/open-sdr/openwifi-hw/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/open-sdr-openwifi-hw