hexforge manual / mailing list
The mailing list
There is one list, hexforge-dev. Questions, bug reports, patches and board results all go to it. There is no second list for users and no forum; a project this size does not need two places to not answer in.
Plain text. No HTML mail, no attachments for patches - git format-patch inline, or a unified diff pasted in the body. Mail that arrives as HTML gets a one-line reply asking for it again as text, which everyone finds rude exactly once. To subscribe, write to hexforge@hexforge.cloud with the word subscribe in the subject; it is handled by a person, not a daemon, so give it a day.
Archive
The archive is flat mbox, one file per month, rendered here as a thread list. Message bodies are kept verbatim; two recent threads are opened below the index as examples of what the list actually looks like.
2026-10 - October
- 2026-10-040.7.2 tagged - please retest your boardsnh
- 2026-10-02hxsyn: route_congestion_45k still red after iteration capt.okonkwo
- 2026-09-30Re: Fenwick A2 only configures with --config-mode spi-x1?j_reinholt
- 2026-09-29casex rejected as E156 - is this really intendedpmx
2026-09 - September
- 2026-09-24M1-8K pin table wrong on bank 2? (#164)a.varga
- 2026-09-18W204 on every design since 0.7.1 - false positivedunlin.user
- 2026-09-10patch: skip set_false_path warning for unclocked outputst.okonkwo
- 2026-09-06Re: 0.7.1 pre-release, please hammer Fenwick A2nh
2026-08 - August
- 2026-08-220.7.0: netlist is v4, your old .hxn will not loadnh
- 2026-08-15Please do not add a v3->v4 converters.halloran
- 2026-08-11hxta split from hxsyn - where did --report gopmx
Older months are in the archive back to 2024-05; the first message is the 0.1.0 announcement. Nothing is deleted from it, including the threads where the maintainer was wrong.
Thread: casex rejected as E156 - is this really intended
Porting a design that uses casex for a one-hot decoder. hxc stops with:
decode.v:44: error E156: casex is not supported (two-state core)
The code is correct standard Verilog. Why is this an error and not a
warning I can ignore? casez at least only warns.
> Why is this an error and not a warning I can ignore?
Because the core is two-state. There is no X to match against, so casex
does not mean here what it means in a four-state simulator; it would
silently synthesise something that does not match your simulation. A
warning you can ignore is exactly the trap I am refusing to build.
casez warns instead of erroring only because ? as a don't-care in a
constant is unambiguous without X. casex needs X to be a value. It is
not, here, so it is E156 and it will stay E156.
Rewrite the decoder as a plain case with explicit patterns. If that is
too painful for a wide one-hot, that is a real complaint and a different
thread; the answer is still not casex.
Thread: hxsyn: route_congestion_45k still red after iteration cap
0.7.2 added the router iteration cap, good. But route_congestion_45k is still in the failing four. Is that expected or did the cap not take?
> Is that expected or did the cap not take?
Expected, for now. The cap stops hxsyn running forever on that case; it
does not make it route. The design genuinely over-fills the T4-45K
routing in one region and the negotiated-congestion loop cannot resolve
it inside the cap. So the test still fails, it just fails in 40 seconds
instead of never. That is defect #198 and it is open.
The other three reds are ta_corner_interp (#141, the slow-corner
interpolation is wrong past 85C), pack_dense_m1 (#164, M1 clock-region
packing), and pack_clock_region_split (#212). None are 0.7.2
regressions; all four are tracked and none block a release because none
affect the eight bundled examples. If you want 45k congestion fixed
sooner than I will get to it, patches to the router welcome - read
limitations first so you know what the router is allowed to assume.