Vivado 2026.1 Drops Linux from the Free Tier: Your Options

In May 2026, FPGA developers on Linux got some unwelcome news. Starting with Vivado 2026.1, AMD’s free tier of its FPGA design suite will no longer be available on Linux. The free Standard edition becomes Windows-only, while the paid editions keep Linux support.

For a lot of people, that’s a big deal. Linux is where many FPGA engineers do embedded ARM work alongside their hardware designs, where most CI runners live, and where hobbyists and students often work. This post covers what changed, what options you have, and how to keep a Linux build pipeline running.

What exactly changed

From the reporting on Slashdot and elsewhere:

Vivado 2026.1 onward: the free Standard edition runs on Windows only.
Vivado 2025.2 stays licence-free on Linux and can be used indefinitely. It gets official bug-fix support until 2026.3 is released, after which it’s unsupported but still usable.
Paid tiers keep Linux support across the usual enterprise distributions (Red Hat, SUSE, Ubuntu, Alma, Rocky).
The free tier changes in other ways too: it gains support for some additional devices but loses certain debug features.

AMD’s explanation, from senior product application engineer Anatoli Curran, was that “close to 70% of the customers are still using Windows.”

Who this affects most

Hobbyists and students on Linux who used the free edition for dev boards.
Small teams whose CI runs synthesis and implementation on Linux runners or containers.
Embedded developers who build FPGA bitstreams and Linux software for Zynq or similar SoCs on the same machine.

If your company already pays for Vivado, little changes. If you depended on the free tier on Linux, you need a plan before 2025.2 support ends.

Your options

Option 1: Stay on Vivado 2025.2 for now

The simplest short-term move is to install 2025.2 and pin it. It keeps working on Linux without a licence. The catch is that it will eventually miss new device support and fixes, so treat this as a bridge, not a permanent home.

For CI, bake 2025.2 into a container image you control and store the installer somewhere safe. Don’t rely on being able to download old versions forever.

Option 2: Pay for a Linux-supported edition

For professional teams, a paid licence may simply be the cost of doing business. Compare it with the engineering time you’d spend maintaining workarounds.

Option 3: Windows, a VM or WSL

You can run the free edition on Windows directly, in a Windows virtual machine on a Linux host, or with a mixed setup using WSL for the Linux-side tools. It works, but it adds friction to automation. Windows CI runners are generally slower and costlier than Linux ones, and licensing a Windows VM has its own costs.

Option 4: Use the open-source toolchain where your hardware allows it

This is the most interesting option, with an important caveat about device support. The open-source FPGA flow has matured a lot:

Yosys for synthesis of Verilog, and SystemVerilog through plugins,
nextpnr for place and route,
openFPGALoader for programming boards,
Verilator, Icarus Verilog and GHDL for simulation, often driven by cocotb for Python testbenches.

The caveat is device support. Lattice iCE40 and ECP5 parts, plus several Gowin families, are well supported by open tools. Xilinx/AMD 7-series support exists through community projects, but it’s experimental and doesn’t cover everything Vivado does, and newer UltraScale+ and Versal parts realistically need Vivado. So the open flow is a full replacement for some boards and a helpful complement for others, such as running linting and simulation in CI even if final bitstreams still come from Vivado.

A working CI pipeline with open-source tools

Here’s a GitHub Actions workflow that lints, synthesises, places and routes, and packs a bitstream for an iCE40 UP5K design. The YosysHQ OSS CAD Suite bundles the tools, so there’s no long list of packages to install:

name: fpga-ci
on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: YosysHQ/setup-oss-cad-suite@v3

      - name: Lint
        run: verilator --lint-only -Wall src/top.v

      - name: Synthesise
        run: yosys -p "synth_ice40 -top top -json build/top.json" src/top.v

      - name: Place and route
        run: nextpnr-ice40 --up5k --package sg48 --json build/top.json --pcf constraints/top.pcf --asc build/top.asc

      - name: Pack bitstream
        run: icepack build/top.asc build/top.bin

      - uses: actions/upload-artifact@v4
        with:
          name: bitstream
          path: build/top.bin

Adjust the device flags (--up5k, --package) and the constraints file for your board. Create the build directory first or add a mkdir -p build step. Check the action’s README for its current version tag.

Keeping Vivado builds reproducible

If you stay on Vivado, in any edition, these habits make version changes much less painful:

Script everything in Tcl. Use non-project mode (read_verilog, synth_design, place_design, route_design, write_bitstream) driven by a Tcl script under version control, run with vivado -mode batch -source build.tcl. GUI-only projects are hard to reproduce and harder to move.
Pin the tool version in your repository and fail the build if it doesn’t match.
Containerise the toolchain so every developer and CI job uses the same install.
Separate simulation from implementation. Run fast simulation with open tools on every commit, and full implementation less often, such as nightly or on release branches. That reduces how often you need the licensed toolchain at all.

Where AI tools actually help

AI coding assistants are useful for FPGA work in fairly specific ways: drafting cocotb testbenches, explaining timing reports, writing Tcl build scripts and converting between HDL styles. They’re much less reliable at writing synthesisable RTL that meets timing, and they occasionally produce constructs that simulate fine but don’t synthesise the way you expect. Treat generated HDL like any other code: simulate it, check the synthesis report, and review it before trusting it on hardware.

What to do this month

If you use the free tier on Linux, download and archive Vivado 2025.2 now.
Move your builds to scripted, non-project Tcl flows if they aren’t already.
Add open-source linting and simulation to CI. It works regardless of which vendor tool you use for implementation.
For new hobby or low-cost projects, consider boards with good open toolchain support.
For professional work on newer AMD parts, budget for a licensed edition or a Windows build host.

AMD’s decision is a nudge toward Windows or paid licences. For some developers, it may also be the push to finally invest in open-source FPGA tooling, which is in far better shape than it was a few years ago.