The FMA Boundary
A fused multiply-add unit looks simple at the arithmetic level: compute A x B + C with one rounding path. In hardware, it becomes a large floating-point datapath with alignment, partial-product reduction, normalization, rounding, exception behavior, pipeline staging, and verification.
That is why open-sourcing an ASIC FMA block is harder than publishing a compact formula or a software library.
RTL Is Not The Whole Artifact
The RTL matters, but ASIC usefulness depends on the path from RTL to layout. Timing closure, clocking, physical synthesis, placement, routing, standard-cell libraries, memories, power delivery, and design-rule closure all affect whether the block can become a chip.
Open HDL can still leave builders stuck if the manufacturable path depends on proprietary tools, foundry data, private implementation practice, or validation knowledge that is not available with the source.
The Open-Hardware Gap
Software openness scales well because most users can build, run, inspect, and test the result on commodity machines. ASIC openness has a deeper replication problem: the final object is physical, expensive to fabricate, and tied to process-specific constraints.
The useful open-hardware target is therefore larger than source release. It includes testbenches, timing constraints, implementation notes, process assumptions, verification coverage, and a path another builder can actually reproduce.
What Changed Since 2023
The open tool boundary moved. OpenROAD now documents an open RTL-to-GDSII toolchain, and OpenLane integrates Yosys, OpenROAD, KLayout, and Magic into reproducible flows. The problem is no longer accurately described as the absence of an open physical-design path.
Open floating-point RTL exists too. FPnew/CVFPU is a configurable SystemVerilog floating-point unit with standard and transprecision formats. That makes the sharper question visible: what must accompany an FMA implementation before another team can reuse it with confidence?
The answer includes supported formats and rounding modes, exception behavior, interface and pipeline contracts, tests and coverage, timing constraints, library and PDK assumptions, power-performance-area results, physical verification, and a named signoff boundary. A successful layout in one process is evidence. It is not automatically a portable hard macro or a complete reusable product.