ci(fpga): place gf12-clean, gf14-add and gf14-sub with HeAP, not SA

[gHashTag]

Refs #862. Same change as #861, for the three other workflows the #862 audit found red the same way.

Why

ax7203-gf12-clean, ax7203-gf14-add and ax7203-gf14-sub all ended no clean seed on seeds 1-8 in the audit dispatch on main 38da24d3a (runs 37212183150, 37212211972, 37212248879). The A/B on exp/sa-audit-ab, run 37213406352, ran seeds 1-16 for each design under both placers, with the Yosys command and nextpnr flags copied from these workflows, on the pinned image regymm/openxc7@sha256:35c91073:

design	SA clean	why SA failed	HeAP clean	HeAP s/seed	HeAP Fmax
gf12_clean	0 of 16	16x post-placement validity check failed for Bel 'SLICE_*/A5FF' (no cell)	16 of 16	6-8	48.7-53.0 MHz
gf14_add	3 of 16 (10, 11, 15)	11x A5FF (no cell), 1x A5FF with a cell, 1x route failure on $PACKER_VCC_NET	16 of 16	4-5	43.5-47.9 MHz
gf14_sub	0 of 16	15x A5FF (no cell), 1x route failure on $PACKER_VCC_NET	16 of 16	6-9	36.8-39.9 MHz

The A5FF failure is the SA-placer bug documented in openXC7/nextpnr-xilinx#162 (the same one as gf10-sub, #856). SA failing on 1-8 in the experiment for all three designs reproduces what main saw, so the experiment measures the same thing the gate does.

Where SA did place (gf14_add seeds 10, 11, 15), it took 44-52 s per seed and reached 25.6-27.9 MHz. HeAP's placements are faster and better on that design, not just cleaner.

What changes

--placer sa becomes --placer heap in the seed search of each of the three files, with a comment carrying the numbers above. The seed range stays 1-8, as in #861.

These are conformance workflows: they pass --timing-allow-fail and none of them records or quotes Fmax, so the placer is not part of anything they claim. Workflows that do quote Fmax are left alone by the rule in #862.

Not changed, not measured

• HeAP's Fmax on gf14_add and gf14_sub is below the 50 MHz target. The gate allows that today and still does after this PR; whether any of these bitstreams is loaded on a board at a clock that matters is not something these workflows say.
• gf14_sub's Yosys logs yosys-abc ... Abc_LitIsCompl: Assertion 'Lit >= 0' failed (return code 134) as a warning and carries on, under both placers. The netlist places clean under HeAP; whether it is functionally right is not measured here (S27 on ci(fpga): audit the 31 workflows that pass --placer sa against today's image #862).
• No CI run of these exact files yet; the first one on this branch is the check.

Conflicts

git merge-tree --write-tree against #852, #857 and #861: no conflicts.

🤖 Generated with Claude Code

[github-actions]

X Brain Health Check

Score: 100.0/100
Status: 🟢 HEALTHY
Threshold: 80/100

X Brain is above merge threshold

[gHashTag]

All three workflows this PR switches to --placer heap are green on the PR head, each on its first seed:

workflow	run	clean seed	nextpnr seed-search step
ax7203-gf12-clean	37214979643	1	7 s
ax7203-gf14-add	37214983413	1	7 s
ax7203-gf14-sub	37214986763	1	7 s (16:16:45 → 16:16:52 UTC)

On main (38da24d3a), the #862 audit found no clean seed in 1-8 for any of the three under SA. The 16-seed A/B behind the switch is run 37213406352: SA 0, 3 and 0 of 16 clean, HeAP 16 of 16 for each.

Not changed here: gf14-sub's Yosys still logs the yosys-abc Abc_LitIsCompl assertion as a warning. It fires in &mfs, after &write -n output.aig, so Yosys reads back the &if mapping. Whether that netlist is equivalent to the RTL has not been checked; it is tracked separately under #862.

Fmax is lower than the target, and this PR does not hide that. Under HeAP the A/B measured gf12_clean at 48.7-53.0 MHz, gf14_add at 43.5-47.9 and gf14_sub at 36.8-39.9, against --freq 50. The workflows pass --timing-allow-fail, so the gate passes. They are conformance builds and quote no Fmax. Not measured: Fmax on the PR head itself.

Refs #862

[github-actions]

🧪 Brain Stress Test Results

Score: not measured (no stress test prints a Score: line)
Status: 🟢 PASS
Threshold: 270/300

X Stress test passed