Introducing Radhdl
Portable FPGA IP For Modern Hardware Development
Motivations
FPGA Tooling in 2026: The Good, The Bad, And The Ugly
FPGA development in 2026 is more accessible than it has ever been. Capable silicon is available at lower cost, small teams can realistically target devices that once felt reserved for large programs, and parts of the vendor ecosystem have become more approachable. AMD/Xilinx, for example, has made modern Vivado licensing more practical for many developers than it was in previous generations.
That progress matters. It means FPGA design is no longer limited to large organizations with expensive tool licenses and rigid internal flows. Independent developers, research teams, startups, and specialized engineering groups can now build serious programmable logic systems.
But the tooling story is still uneven.
Open-source tools such as Yosys, nextpnr, and LiteX have made enormous progress. They are lightweight, scriptable, fast to integrate, and often far more pleasant to automate than large vendor suites. For supported devices and well-understood flows, they can be excellent. However, they are not yet a universal replacement for proprietary tools. Complex timing closure, advanced transceivers, hardened SoC integrations, and vendor IP ecosystems still frequently require vendor-provided flows.
Then there is the difficult part: proprietary FPGA toolchains remain fragmented, opaque, and deeply vendor-specific. Each vendor ships its own project formats, IP generation systems, primitive libraries, timing models, debug cores, and scripting conventions. Moving a design from one FPGA family to another is rarely a clean retargeting exercise. In practice, it often becomes a partial rewrite.
That is the gap RadHDL and RadBuild are designed to address.
Revision Control: Where Hardware Still Lags Software
Modern software development has largely solved revision control. Developers work with text files, commit meaningful changes, review diffs, branch safely, and reproduce builds from source. The repository is the source of truth.
FPGA development often breaks that model.
Vendor tools frequently treat the GUI project as the primary artifact. A simple configuration change can produce large, noisy diffs across generated XML files, project databases, block-design metadata, and tool-managed directories. These files are difficult to review, difficult to merge, and easy to corrupt across tool versions.
The common workaround is to avoid tracking vendor project files and instead regenerate the project from Tcl scripts. That is better than committing opaque project state, but it creates a second problem: the build system becomes a parallel codebase. Teams end up maintaining fragile Tcl templates, version-specific tool invocations, generated IP scripts, and custom directory conventions just to keep the repository clean.
This is not how hardware development should work.
A hardware project should have a clean, declarative source of truth. Its structure should be readable, reviewable, and reproducible. Tool-specific project files should be generated outputs, not hand-maintained source artifacts.
Vendor Lock-In And The Cost Of Portability
The deeper issue is not just project-file management. It is architecture lock-in.
A reusable HDL core should not need to know whether it is targeting AMD/Xilinx 7-Series, UltraScale+, Lattice ECP5, Gowin GW5A, or another fabric. In reality, portable logic often becomes contaminated by vendor-specific primitives and generated IP. Clock managers, block RAMs, FIFOs, DSP blocks, reset synchronizers, CDC helpers, and debug cores all tend to require different instantiation patterns across vendors.
That creates long-term engineering risk.
If a design needs to move because of cost, availability, device capacity, power, or product strategy, the porting effort can become expensive and unpredictable. Engineers must replace primitives, regenerate IP, rebuild debug infrastructure, update scripts, re-check timing assumptions, and re-verify behavior.
The result is that many FPGA teams do not truly own portable IP. They own vendor-specific implementations that happen to work in one toolchain.
RadHDL exists to change that.
Core Architecture
Decoupling The Hardware: How RadHDL Works
RadHDL is a vendor-neutral VHDL library focused on reusable hardware infrastructure. Its goal is simple: let engineers write portable core logic while still mapping efficiently to real FPGA resources.
The Crimson 0.2.2 release introduces the RadPrimitive abstraction layer. RadPrimitive provides stable VHDL interfaces for low-level FPGA building blocks while keeping vendor-specific details isolated behind wrapper modules. Instead of scattering XPM, DP16KD, Gowin primitives, or other vendor-specific structures throughout application logic, designs instantiate a RadHDL primitive boundary.
For example, a portable true dual-port RAM can be expressed through one interface:
xilinxram_inst : entity work.radhdl_ram
generic map (
VENDOR => "xilinx",
DEVICE_FAMILY => "7series",
MODE => "tdp",
MEMORY_KIND => "bram",
DATA_WIDTH => 18,
ADDR_WIDTH => 10,
DEPTH => 1024,
CLOCKING_MODE => "independent_clock",
MEMORY_INIT_FILE => "none",
USE_MEM_INIT => 0,
SIMULATION => false
)
port map (
clka => clk100m,
rsta => rst100,
a_addr => addr100,
a_din => din100,
a_dout => dout100,
a_we => we100,
clkb => clk125m,
rstb => rst125,
b_addr => addr125,
b_din => din125,
b_dout => dout125,
b_we => we125
);
The same high-level interface can target different FPGA families by changing generics and build configuration rather than rewriting the core design.
RadHDL also extends beyond memory primitives. The library includes reusable infrastructure for interfaces and debug, including register banks, bus bridges, streaming datapaths, I2C, SPI, UART, I2S, AXI-style flows, and hardware debug components.
A key part of this is RadILA and RadDebugHub. Instead of relying exclusively on vendor-generated integrated logic analyzers, RadHDL provides portable debug infrastructure that can be built into standard fabric. Diagnostic data and register access can move through ordinary communication paths such as UART, SPI, or memory-mapped bridges. That makes debug more portable, more scriptable, and less dependent on GUI-generated vendor cores.
The design rule is straightforward: vendor-specific primitives belong at the boundary, not in the application logic.
Verification: Portable Does Not Mean Approximate
A portability layer is only useful if behavior remains consistent across implementations.
RadHDL's primitive work is backed by a simulation and verification strategy that compares generic behavior against vendor-specific paths where possible. GHDL is used as the open baseline simulator for portable VHDL models. Vendor simulators such as Vivado xsim can be used where authoritative vendor models are required, especially for XPM-based behavior.
The goal is not to pretend every FPGA family is identical. They are not. RAM behavior, reset behavior, write modes, clocking assumptions, and initialization support all vary across vendors. The goal is to make those differences explicit, testable, and isolated.
That gives engineers a practical portability contract: application logic depends on RadHDL interfaces, while RadHDL owns the vendor mapping and verification burden.
Unifying the Execution — How RadBuild Steps In
Portable HDL still needs a reliable build system. Without one, teams simply move complexity from source files into scripts.
RadBuild is the orchestration layer for that problem. It provides a declarative, JSON-driven workflow for FPGA projects, embedded software, Linux builds, RADix OS images, toolchain discovery, and multi-target systems.
A minimal FPGA project configuration can look like this:
{
"system": "my_fpga_target",
"type": "fpga.vivado",
"toolchain_path": "/opt/Xilinx/Vivado/2024.1",
"source_packages": [
"radhdl.radprimitive",
"radhdl.radif"
]
}
Instead of manually maintaining vendor project files or large Tcl reconstruction scripts, RadBuild treats the JSON project configuration as the source of truth. Vendor project directories, generated files, build outputs, and logs become reproducible artifacts.
The CLI flow is designed to be predictable:
radbuild project validate --settings ./workspace/demo/settings.json radbuild generate --settings ./workspace/demo/settings.json radbuild build all --settings ./workspace/demo/settings.json
RadBuild also emits structured build status events, making it suitable for CI/CD, automation dashboards, and IDE integrations. The `radbuild-vscode-support` package builds on this by providing an interactive VSCode sidebar, project registration, template-aware configuration forms, toolchain scanning, and build controls.
The intent is to bring FPGA and embedded workflows closer to modern software development: declarative configuration, reproducible builds, readable diffs, and automation-first tooling.
Closing Out
Current Status: Crimson Experimental Release Suite
The current Crimson release suite is an experimental but increasingly capable foundation for portable hardware and system development.
RadHDL `v0.2.2-beta.1` includes a growing catalog of documented VHDL modules, primitive wrappers, interface components, register-map structures, simulation infrastructure, and example projects. The primitive layer is being developed around AMD/Xilinx 7-Series, UltraScale, UltraScale+, Lattice ECP5, and Gowin GW5A targets.
RadBuild `v0.2.1` provides the project orchestration layer. It supports schema validation, project generation, build execution, package metadata, toolchain scanning, and integration with installed vendor tools such as Vivado and PetaLinux.
The VSCode support package adds a more approachable front end for project selection, toolchain configuration, project creation, and build control.
Together, these tools form the early shape of a portable FPGA and embedded systems development environment: RadHDL defines reusable hardware infrastructure, while RadBuild makes projects reproducible and manageable.
Why This Matters
FPGA development should not require choosing between opaque GUI projects and fragile hand-maintained scripts. It should not force every reusable design to become tied to one vendor's primitive library. And it should not make CI/CD, code review, or multi-vendor support feel like afterthoughts.
RadHDL and RadBuild are built around a different assumption: hardware projects should be treated like serious source-controlled software projects.
That means:
Clean, reviewable source configuration
Portable HDL boundaries
Vendor-specific implementation isolated below stable interfaces
Repeatable project generation
Scriptable and CI-friendly builds
Debug infrastructure that is not locked to one vendor GUI
A path toward reusable IP across FPGA families
This does not eliminate the need for vendor tools. Timing closure, placement, routing, bitstream generation, and advanced device features still require vendor-specific flows. But it changes where those tools sit in the architecture. They become backend execution engines, not the source of truth for the project.
Contributing
RadHDL and RadBuild are actively evolving, and the Crimson release line is focused on hardening the foundation.
Useful contribution areas include:
Expanding primitive wrappers for additional FPGA families
Improving RAM, FIFO, DSP, PLL, and CDC abstraction coverage
Enhancing VSCode Plugin Functionality and Support
Adding vendor and generic simulation comparisons
Strengthening interface IP such as AXI, SPI, I2C, UART, and I2S
Improving RadBuild templates for FPGA, embedded Linux, RADix OS, and mixed hardware/software systems
Testing toolchain detection across Vivado, PetaLinux, open-source FPGA flows, and other vendor suites
Improving generated documentation, examples, and register-map references
The long-term goal is ambitious but practical: make portable FPGA and embedded development feel as disciplined, reproducible, and automation-friendly as modern software engineering.
Explore the RadHDL repository, review the Crimson documentation, and install the latest RadBuild packages to start building portable hardware without surrendering your project structure to vendor lock-in.
Resources and Links