hexforge / install
Install
Source only. There are no distribution packages, no installer and no container image, because maintaining those for a pre-1.0 project would cost more attention than the router currently gets.
Host platforms
| Host | State | Notes |
|---|---|---|
| Linux x86-64 | supported | Development platform. Every release is built and tested here first. |
| Linux aarch64 | supported | Tested on a 4-core board before each release. Builds take about four times longer. |
| macOS arm64 | builds | Compiles and runs; one timing test fails on floating-point rounding. Nobody has chased it down. |
| Windows | unsupported | Paths, file locking and the device-table generator all assume POSIX. No plans to change this. A Linux environment inside Windows works fine. |
| FreeBSD | reported working | A contributor built 0.6.0 there in 2026-04 with no patches. Not tested since. |
Dependencies
- A C++20 compiler. GCC 12 or newer, or Clang 15 or newer. Older compilers fail on the designated initialisers in the device tables, and the error messages are not kind.
- CMake 3.22 or newer.
- Python 3.10 or newer, used once during the build to turn the device description into static C++ tables. It is not needed to run the tools afterwards.
- Nothing else. No Boost, no LLVM, no GUI libraries, no package manager fetching anything over the network at configure time.
The deliberate absence of a network step at build time is the reason the device tables are generated by a script in the tree rather than downloaded. It also means a build works on a machine that has never seen the internet, which is how it gets tested on the aarch64 board.
Building
$ git clone https://git.hexforge.cloud/hexforge.git
$ cd hexforge
$ cmake -B build -DCMAKE_BUILD_TYPE=Release
$ cmake --build build -j8
On eight cores that takes about three and a half minutes and leaves a 40 MB build directory. The four binaries together come to 11 MB stripped. A debug build is roughly three times larger and the router is about twenty times slower, which matters: do not debug placement problems in a debug build unless you are prepared to wait.
$ cmake --install build --prefix ~/.local
-- Installing: ~/.local/bin/hxc
-- Installing: ~/.local/bin/hxsyn
-- Installing: ~/.local/bin/hxta
-- Installing: ~/.local/bin/hxpack
-- Installing: ~/.local/share/hexforge/devices/t4.hxd
-- Installing: ~/.local/share/hexforge/devices/m1.hxd
Running the tools from the build directory without installing works too; they locate device data relative to their own path, and fall back to HEXFORGE_DEVICES if that fails.
The test suite, including the failures
$ ctest --test-dir build --output-on-failure
...
97% tests passed, 4 tests failed out of 221
Total test time (real) = 96.41 sec
The following tests FAILED:
118 - ta_corner_interp (Failed)
164 - pack_dense_m1 (Failed)
189 - route_congestion_45k (Timeout)
203 - pack_clock_region_split (Failed)
These four fail on every platform and have failed for at least two releases. They are listed here rather than quietly skipped, because a test suite that always prints green teaches you nothing:
- ta_corner_interp
- Interpolation between temperature corners disagrees with the reference by up to 1.8%. The reference was computed by hand and may itself be wrong; until that is resolved the test stays red.
- pack_dense_m1
- Packing a design to above 94% occupancy on M1-8K fails to find a legal arrangement. Known weakness of the packer on the smaller family, tracked since 0.5.0.
- route_congestion_45k
- A deliberately congested T4-45K case exceeds the 180-second test timeout. It does finish, in about four minutes. This is the clearest single statement about router quality on the large part.
- pack_clock_region_split
- A design with two clocks whose loads straddle a clock region boundary gets packed into an illegal configuration. Workaround is in limitations; a fix needs the packer to understand clock regions, which it currently does not.
Device data files
Two files describe the hardware: t4.hxd at 2.1 MB and m1.hxd at 0.6 MB. They hold the tile grid, routing graph, bitstream frame layout and a delay table per cell type. Everything the tools know about silicon lives there; the binaries contain no device-specific code paths beyond reading those files.
They were built by measuring, and that shows. Delay numbers came from ring oscillators of varying length on real boards, fitted to a straight line per cell type, which is accurate to roughly ±12% and systematically optimistic on long routes. If you want to know how much to distrust a timing report, that sentence is the answer, and the timing page expands on it.
Upgrading from 0.6.x
The netlist and routed-design formats both changed in 0.7.0. A .hxn file written by 0.6.x is rejected with format version 3, expected 4; there is no converter. Rebuild from HDL, which takes seconds anyway. Bitstreams produced by 0.6.x remain valid and loadable - the device frame format has not changed since 0.4.0.
Flag changes in the same release: --chip became --device, and hxsyn --timing was removed in favour of running hxta separately. Both old spellings print an error naming the replacement instead of silently doing nothing.