# wireguard-fpga: Open Hardware WireGuard on Artix-7

> wireguard-fpga is a proof-of-concept WireGuard system on FPGA for engineers evaluating hardware VPN processing without a proprietary accelerator or a host PC. Its open HDL and toolchain are promising, but the README explicitly says Phase 1 is not a deployable product.

**chili-chips-ba/wireguard-fpga** — Full-throttle, wire-speed hardware implementation of Wireguard VPN, using low-cost Artix7 FPGA with opensource toolchain. If you seek security and privacy, nothing is private in our codebase. Our door is wide open for backdoor scrutiny, be it related to RTL, embedded, build, bitstream or any other aspect of design and delivery package. Bujrum!

- Repository: https://github.com/chili-chips-ba/wireguard-fpga
- Website: https://nlnet.nl/project/KlusterLab-Wireguard
- Stars: 1,379 · Forks: 37
- Language: Verilog
- License: BSD-3-Clause
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/chili-chips-ba-wireguard-fpga

## The Hardware VPN Gap wireguard-fpga Targets

wireguard-fpga addresses the gap between software WireGuard implementations, which the README says operate below physical link speed, and hardware approaches that it describes as expensive and dependent on proprietary intellectual property and tools. The project seeks to move WireGuard packet processing into an FPGA while keeping the design and its development chain open. Its target is a commodity Artix-7 board with four 1000Base-T ports. It is also intended to operate without a connected PC, unlike the earlier Blackwire design described in the project history.

The intended users are FPGA engineers, networking researchers, and institutions that want to examine or extend hardware VPN architectures. This is not positioned as a desktop VPN client or an immediately deployable gateway. The board, physical interfaces, embedded control software, HDL, synthesis flow, and validation environment all form part of the engineering problem. That scope makes the repository useful for research, but it also means adoption depends on hardware access and FPGA toolchain competence.

The README describes the design as wire-speed and “full-throttle,” but the project outline also labels Phase 1 a proof of concept. Those statements should be read as project goals rather than a promise of production performance. No measured throughput, latency, channel capacity, or deployment readiness figures are provided.

## Open HDL and Toolchain Components in the Artix-7 Design

Based on the repository outline, the design combines hardware pipeline logic, control interfaces, an on-chip CPU, Ethernet, simulation, linting, and build infrastructure. PipelineC is used as an HLS-like component for constructing pipelines. PeakRDL supplies the CSR layer, while a RISC-V CPU participates in controlling the packet-processing backbone. VProc is named for co-simulation, SV2V converts SystemVerilog to Verilog, and OpenXC7 handles place-and-route for Xilinx Series 7 devices.

The Ethernet layer comes from Verilog-Ethernet, an open-source library identified in the README as Alex's Ethernet stack. This matters because a VPN gateway cannot be separated from packet ingress, MAC and IP processing, or data-plane output. The repository therefore presents WireGuard as part of a system-on-chip rather than as an isolated cryptographic core.

The visible top-level structure separates these concerns into `1.hw/`, `2.sw/`, `3.build/`, `4.sim/`, `5.lint/`, and `6.test/`. There are also documentation, warmup, licensing, and repository configuration directories. That organization supports hardware, software, build, simulation, and validation work in parallel. However, the README does not provide a detailed packet-flow diagram, interface contract, memory map, or channel configuration procedure. The exact division of work between the RISC-V CPU and the wire-speed datapath is identified as an engineering challenge, not documented as a completed specification.

## Self-Contained Operation and the RISC-V Control Split

One of the project's clearest design choices is removing the external-PC dependency associated with Blackwire. The board is intended to handle the system by itself through an on-chip RISC-V CPU and embedded software. This changes the adoption problem. Rather than shipping a host-side VPN process and a PC-connected accelerator, the project has to deliver device initialization, control logic, and data-path coordination within the FPGA platform.

The README identifies hardware and software partitioning as a recognized challenge. Specifically, the interface between the RISC-V CPU and the high-speed datapath must balance control requirements against packet-processing throughput. Embedded software is expected to control the backbone of the wire-speed path, while hardware pipelines handle the latency-sensitive work. This split is sensible for a standalone FPGA appliance, but it also creates two implementation surfaces that must stay synchronized.

The repository's `2.sw/` and `1.hw/` directories reflect that division. Yet the README does not document how peers are provisioned, keys are stored, routing state is updated, configuration is persisted, or the board is initialized after reset. Those omissions are significant for anyone expecting a complete VPN endpoint. The project is therefore better understood as a hardware and software research platform whose standalone architecture is a design objective.

## Phase 1 Setup Boundaries and First Inspection

The README does not provide installation commands, board flashing instructions, tool versions, environment variables, or a tested startup procedure. It links to the NLnet project page and identifies the GitHub repository as the source, but it does not give enough information to issue a reproducible `git clone`, build, program, or network test command. Inventing those steps would mislead readers.

A realistic first use is therefore an architecture and feasibility review. Start with `README.md` to confirm the intended Artix-7 target and its four-port requirement. Inspect `1.hw/` for RTL, `2.sw/` for embedded control code, and `3.build/` for synthesis and bitstream generation. Then examine `4.sim/`, `5.lint/`, and `6.test/` to determine how the repository expects developers to validate changes. The reader should find a development tree organized around the FPGA's complete toolchain, but should not assume that cloning the repository is enough to produce a usable gateway.

For a first real network deployment, additional documentation is necessary. The project would need to state supported board revisions, exact tool versions, build commands, bitstream output, interface configuration, WireGuard peer setup, and a reproducible acceptance test. None of those procedures appears in the README.

## Proof-of-Concept Limits and Hardware Constraints

The most important limitation is stated directly: Phase 1 is “not full-featured” and “definitely not a deployable product.” It is described as an entry point for later optimization and expansion. Planned Phase 2 work includes increasing channel counts and potentially adding graphical management, but those plans are not current features.

The platform itself narrows applicability. The stated target is one inexpensive Artix-7 board with four 1000Base-T ports. The README does not claim support for common FPGA boards, PCIe SmartNICs, SFP interfaces, or arbitrary Artix-7 variants. A different board would require checking pin constraints, Ethernet PHY integration, memory availability, clocking, and physical interfaces. Because those details are not documented, compatibility should not be inferred from the Artix-7 family name.

Open-source synthesis also creates practical constraints. The project explicitly lists incomplete SystemVerilog and FPGA primitive support, quality of results, timing closure, utilization, and routing congestion as challenges. These concerns matter more than a generic claim that the toolchain is open. An open source flow can require more assembly, local troubleshooting, and tool-version management than a vendor-supported commercial flow. The README does not provide resource utilization, clock targets, or successful build instructions, so those adoption questions remain unanswered.

## Simulation, VProc, and the Central Validation Lab Plan

The project treats conventional validation as a hard part of its scope. For a design combining RISC-V software, high-throughput pipelines, control registers, and Ethernet, ordinary simulation would need to reproduce interactions across several domains. The README says standard simulation is impractical for the system's size and complexity and proposes using the VProc RISC-V instruction set simulator for hardware and software co-development.

The README also says that providing every developer with real traffic generators and checkers would be impractical and expensive. Its response is a planned central lab containing two test systems with remote access. That model could help evaluate at-speed behavior, but it is described as a plan rather than a documented service already available to every user. No access procedure, test protocol, supported traffic profile, or reproducibility instructions are given.

This leaves two validation levels. Repository simulation and test directories suggest a local development path, while the planned lab addresses physical hardware testing. Neither path comes with acceptance thresholds in the README. In particular, the project does not document key rotation tests, malformed packet handling, peer state limits, sustained throughput criteria, or interoperability procedures with standard WireGuard peers. Those are essential checks before any deployment claim.

## wireguard-fpga Compared with Blackwire and Software VPN Stacks

Blackwire is the closest architectural alternative discussed by the project. The README describes it as a 100Gbps hardware WireGuard switch for an AMD/Xilinx Alveo U50, using the proprietary Vivado toolchain and SpinalHDL. wireguard-fpga instead targets lower-cost Artix-7 hardware, uses Verilog and SystemVerilog, and relies on OpenXC7 for place-and-route. It also seeks to operate without the external PC arrangement described for Blackwire.

The trade-off is not simply “open versus closed.” Blackwire is associated with much higher stated line-rate ambition and an established accelerator platform, while wireguard-fpga is still a proof of concept with no published performance result. Its accessible board and open components may make experimentation more practical for educational and research teams, but they also expose the user to immature synthesis support and the project's own hardware integration work.

Software alternatives named in the README include Netbird, Tailscale, and the Linux kernel WireGuard implementation. Their approach is fundamentally different: they process VPN traffic in software on general-purpose systems. wireguard-fpga moves that work into an FPGA and adds embedded control requirements. It is therefore not a drop-in software replacement, and the README does not document interoperability or operational equivalence.

## Openness, Licensing, and Upgrade Work After v1.0.0

The repository identifies its license as BSD-3-Clause and includes a top-level `LICENSE`, a `LICENSES/` directory, SPDX identifiers, and `REUSE.toml`. This structure makes license metadata visible throughout the source tree. The third-party HDL, CPU, simulation, conversion, and place-and-route components also come from separate open-source projects, so an adopter must examine their individual licenses and notices rather than assuming one identifier covers every dependency. The README does not provide legal analysis of those obligations.

The repository is not archived, and its last push was on 2026-10-15. That is recent relative to the stated release history, although recency does not establish production readiness. The listed releases are `v1.0.0` from 2026-01-27 and `v0.1.0` from 2025-05-26. The README does not provide upgrade notes, migration instructions, compatibility statements, or a hardware and toolchain support matrix for either release.

An upgrade may therefore require more than replacing a bitstream. Reviewers should check changes across RTL, embedded software, RISC-V behavior, CSR definitions, generated Verilog, Ethernet integration, tests, and build scripts. The repository's broad open scope supports scrutiny, but it does not remove the cost of maintaining a mixed HDL, firmware, simulation, and FPGA build environment.

## Conclusion

Engineers prototyping hardware VPN acceleration can adopt the repository as a research and educational platform, while operators seeking a deployable appliance should not use Phase 1. The first checks should be whether their exact board and Ethernet interfaces are covered, whether the required open-source tool flow can synthesize the design, and whether they need functionality that the proof of concept does not yet provide.

## FAQ

### Is chili-chips-ba/wireguard-fpga ready for production deployment?

No. The README explicitly describes Phase 1 as a proof of concept that is not full-featured and not a deployable product.

### Which hardware does chili-chips-ba/wireguard-fpga target?

The stated platform is a commodity Artix-7 FPGA board with four 1000Base-T ports. The project also says it is designed to operate without a connected PC host.

### How can I build and install chili-chips-ba/wireguard-fpga?

The README does not document installation commands, supported tool versions, flashing steps, or a startup procedure. The repository separates work among `1.hw/`, `2.sw/`, `3.build/`, `4.sim/`, `5.lint/`, and `6.test/`, but these paths are not a complete build tutorial.

## Sources

- [chili-chips-ba/wireguard-fpga on GitHub](https://github.com/chili-chips-ba/wireguard-fpga)
- [License: BSD-3-Clause](https://github.com/chili-chips-ba/wireguard-fpga/blob/main/LICENSE)
- [Project website](https://nlnet.nl/project/KlusterLab-Wireguard)
- [README](https://github.com/chili-chips-ba/wireguard-fpga/blob/main/README.md)
- [Releases](https://github.com/chili-chips-ba/wireguard-fpga/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/chili-chips-ba-wireguard-fpga