# ADI HDL: Analog Devices' FPGA reference designs for Vivado and Quartus > analogdevicesinc/hdl holds Verilog, VHDL, and Tcl build scripts for FPGA reference designs that use Analog Devices hardware, targeting AMD Xilinx and Intel toolchains. Support is exclusively on EngineerZone, each module may carry a different license, and pre-built files from the main branch are not tested in hardware. **analogdevicesinc/hdl** — HDL libraries and projects - Repository: https://github.com/analogdevicesinc/hdl - Website: http://analogdevicesinc.github.io/hdl/ - Stars: 2,039 · Forks: 1,694 - Language: Tcl - License: NOASSERTION - Published: 2026-10-09 · Updated: 2026-10-09 · Language: en - Canonical page: https://hysenlabs.com/projects/analogdevicesinc-hdl ## Verilog and VHDL reference designs for ADI boards on AMD Xilinx and Intel FPGAs Analog Devices publishes this repository for engineers who want to build FPGA designs around ADI data converters, signal processors, and other hardware. The repository contains HDL code written in Verilog or VHDL, paired with Tcl scripts that drive the AMD Xilinx Vivado Design Suite or the Intel Quartus Prime Design Suite through the build process. The code is organized as reference designs rather than standalone IP. Each entry under the projects directory corresponds to a specific ADI board combined with a specific FPGA development board, so a design for the FMCOMMS2 radio board on the ZCU102 carrier sits in projects/fmcomms2/zcu102. The library directory holds the shared HDL components that multiple projects draw from. The projects cover standard application areas in analog-to-digital and digital-to-analog conversion, with JESD204B listed explicitly in the repository topics as a supported interface standard. Engineers without an ADI hardware reference platform can still study the library components or adapt the individual Tcl build scripts, but the designs are written around specific ADI part numbers, specific FPGA carrier boards, and the broader ADI Linux and no-OS software stacks that sit in companion repositories. ## GNU Make triggers the build; the top-level Makefile uses project.board notation Building a bitstream follows a two-step path. First, change into the specific project directory. Second, run make. The repository gives a direct example: ```bash cd projects/fmcomms2/zcu102 make ``` The top-level Makefile shows the naming convention for individual targets. Each project can be built as a top-level target using the format proj.board: ```bash make adv7511.zed ``` The underlying Makefile logic discovers which directories hold a system_project.tcl file and which hold their own sub-Makefiles, then constructs the full project list from those. The Tcl scripts carry the actual Vivado or Quartus project definitions, so the make command is a wrapper that invokes the appropriate tool chain on the correct Tcl script. Windows users need to install GNU Make separately. A user guide page at analogdevicesinc.github.io/hdl/user_guide/build_hdl.html covers the environment setup for Windows, and the same page contains the comprehensive build guide. ## Each branch requires a specific Vivado or Quartus version listed in scripts/adi_env.tcl The repository does not work with any installed version of Vivado or Quartus. Each branch pins required tool versions, and the README points to two sources for this information: the releases page at analogdevicesinc.github.io/hdl/user_guide/releases.html, and the file scripts/adi_env.tcl on the branch you have checked out. This version dependency is a real constraint for teams who update their CAD tools independently of their HDL repository checkout. A Vivado upgrade that outpaces the branch you work from can break the build without an obvious error message. Checking scripts/adi_env.tcl before updating a tool installation is the direct way to confirm compatibility, and pinning the tool version in your development environment before starting a project saves debugging time later. For the most stable setup, the repository recommends using the latest release branch rather than main. Three releases are listed in the repository: 2026_R1 on 2026-10-01, 2023_R2_p1 on 2025-03-26, and 2023_R2 on 2024-11-21. The gap between 2023_R2 and 2026_R1 spans almost two years, which means anyone who has been using 2023_R2 will find significant changes in the 2026_R1 tree. Main is described as sometimes unstable and is not the recommended path for hardware bring-up work. ## Pre-built files from the main branch are not tested in hardware The repository offers two paths to a working design. Building from source produces a bitstream tailored to your exact environment, but takes time and requires a licensed EDA tool. Pre-built files are available as an alternative. For the main branch, pre-built files are linked from a document at swdownloads.analog.com/cse/boot_partition_files/main/latest_boot.txt. New versions are built from main whenever there are new commits in either the HDL repository or the Linux repository. The README carries an explicit warning here: files built from main are not tested in hardware. Using them means accepting that the hardware behavior has not been verified at that point in the repository's history. For tested files, the release branch is the documented recommendation. Engineers using pre-built files for production bring-up or integration testing should verify they come from a release tag rather than from main, since the build automation does not add a hardware-tested label to main branch artifacts. ## Five separate license files cover the repository, and each module may have its own GitHub classifies the repository license as Other because there is no single license covering the whole codebase. Five license files sit at the repository root: LICENSE, LICENSE_ADIBSD, LICENSE_ADIJESD204, LICENSE_BSD-1-Clause, LICENSE_GPL2, and LICENSE_LGPL. Individual modules are developed independently, and the README says each may be accompanied by its own separate and unique license terms. This means the correct approach before distributing or incorporating any component is to read the license file that accompanies that specific module, rather than assuming that the most permissive file covers everything. A module under LGPL has different redistribution implications than one under BSD-1-Clause, and those implications apply to any product that includes the HDL at the bitstream level. The README acknowledges this complexity directly and tells users to read each license and understand the freedoms and responsibilities it grants. There is no shortcut to that step for anyone doing a compliance review. ## Support is EngineerZone only, with a direct statement about free consulting substitutes The support section is unusually specific in what it rules out. The HDL is provided as-is, and support is available only on the Analog Devices EngineerZone FPGA forum at ez.analog.com/community/fpga. The README states explicitly that if you feel you cannot or do not want to ask questions on EngineerZone, you should not use the HDL in this repository. For time-sensitive or one-on-one engagements, the README acknowledges that there is no free replacement for consulting services and suggests finding a consultant familiar with the repository through EngineerZone. That is not a support channel; it is a direction to a commercial alternative. GitHub issues are not mentioned as a support path anywhere in the README. The repository does include a CONTRIBUTING.md file, which addresses contributions but is separate from general support. Engineers who plan to integrate this code into a product should account for the EngineerZone channel as the only documented path for asking questions about behavior they cannot resolve from the documentation. ## Projects target both no-OS baremetal and Linux software stacks, in separate repositories The hardware designs in this repository are half of the stack. All projects support both a no-OS baremetal software path and a Linux-based path. Neither of those software layers lives in this repository. The no-OS support is in the analogdevicesinc/no-OS repository, and Linux support is in the analogdevicesinc/linux repository. For a complete working system, a developer needs to align the HDL branch, the no-OS or Linux repository, and the correct EDA tool version together. Pre-built files from the main branch are rebuilt whenever there are new commits in either the HDL repository or the Linux repository, so the build automation ties the two repositories at the same time point. Building from source requires coordinating those repositories yourself, which is a separate tracking effort from managing the EDA tool version. Documentation for the project lives at analogdevicesinc.github.io/hdl/, including the user guide, the build guide, and the release notes. Building the documentation locally is marked as developer-only in the README and requires a few steps in sequence. First, upgrade pip past version 23: ```bash pip install pip --upgrade ``` Then install the Sphinx dependencies from the docs directory: ```bash (cd docs ; pip install -r requirements.txt --upgrade) ``` The library build is recommended before generating the HTML: ```bash (cd library ; make) (cd docs ; make html) ``` The finished HTML lands in docs/_build/html. ## Conclusion ADI HDL is for engineers developing FPGA-based systems around Analog Devices hardware who need tested reference designs rather than blank-slate RTL. It requires either AMD Xilinx Vivado or Intel Quartus Prime, and the Vivado or Quartus version must match the branch you check out, not the latest installed tool. Before starting a build, check scripts/adi_env.tcl on your chosen branch for the required tool version, read each module's individual license file since there is no single license covering the whole repository, and use the 2026_R1 release branch rather than main if hardware testing matters, since pre-built main branch files are explicitly marked as not tested in hardware. ## FAQ ### What is analogdevicesinc/hdl? It is Analog Devices' collection of HDL reference designs and libraries for FPGA development boards, written in Verilog or VHDL with Tcl build scripts for AMD Xilinx Vivado and Intel Quartus Prime. ### How do I build a project in analogdevicesinc/hdl? Change into the specific project directory and run make, for example cd projects/fmcomms2/zcu102 and then make. GNU Make is required, and Windows users need to install it separately following the instructions in the build guide. ### What license does analogdevicesinc/hdl use? There is no single license. The repository contains five separate license files (ADIBSD, ADIJESD204, BSD-1-Clause, GPL2, LGPL) and individual modules may have their own terms. Reading each module's accompanying license file is the only way to determine what applies to a specific component. ### Where do I get support for analogdevicesinc/hdl? Support is provided exclusively on the Analog Devices EngineerZone FPGA forum at ez.analog.com/community/fpga. The README states that GitHub issues and other channels are not a supported path. ### Is analogdevicesinc/hdl safe to use for production hardware? Pre-built files from the main branch are explicitly noted as not tested in hardware. For production use, the repository recommends using the latest release branch, which was 2026_R1 as of the 2026-10-01 release. ## Sources - [analogdevicesinc/hdl on GitHub](https://github.com/analogdevicesinc/hdl) - [Issues](https://github.com/analogdevicesinc/hdl/issues) - [Project website](http://analogdevicesinc.github.io/hdl/) - [README](https://github.com/analogdevicesinc/hdl/blob/main/README.md) - [Releases](https://github.com/analogdevicesinc/hdl/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/analogdevicesinc-hdl