ci(fpga): place gf10-sub with HeAP, not SA

[gHashTag]

Refs #856

ax7203-gf10-sub went red when regymm/openxc7:latest moved from sha256:eced1cdd to sha256:35c91073. This PR switches its placer from --placer sa to --placer heap. The search over seeds 1-8 stays as it is on main.

The first commit on this branch widened the SA seed search to 32 instead. That works: run 37210095288 printed seed=11, as the table predicted. But it treats a known placer bug as a lottery. The second commit replaces it.

The cause

Nearly every failing seed stops at one check: post-placement validity check failed for Bel 'SLICE_…/A5FF' (no cell). openXC7/nextpnr-xilinx#162 documents that exact signature as an SA-placer bug on xc7.

• SA can leave a tile in an illegal state: an OUTMUX claimed both by O5 and by a 5FF's Q.
• The final sweep then reports the first Bel of that tile, often an empty A5FF.
• HeAP's tile-level checks refuse the pairing, and the issue reports HeAP passing the same netlists.

The issue was closed on 2026-09-24 because that line is archived. I searched for the error text only after two CI rounds; it should have come first.

Measured

All numbers come from the experiment branch exp/gf10-image-ab. It uses the same Verilog, xdc and nextpnr command line as this workflow and only varies the placer and the synth image.

synth image	placer	seeds	clean	time per seed
new (Yosys 0.68)	sa	1-40	11 (first clean: 11)	failures ~7 s, clean 36-113 s
old (Yosys 0.62)	sa	1-8	2 (seeds 1, 6)	not timed
new (Yosys 0.68)	heap	1-16	16	5-7 s
old (Yosys 0.62)	heap	1-8	8	4-7 s

The runs were 37206223497, 37208602651 and 37210944365 (HeAP).

• HeAP placed every seed under both images, 24 of 24. SA placed about 1 seed in 4 under either image.
• The seed search becomes a margin. It is no longer what makes the job pass. Seed 1 should place in under 10 s.
• Fmax under HeAP was 64.9-71.6 MHz against the 50 MHz constraint. Clean SA seeds were not compared here. This workflow checks conformance and records no Fmax, so the placer is not part of a recorded measurement.

Verification

• Dispatched on this branch at a78f2b5e2: run 37211740006. Expected output: seed=1. I will post the result here.
• The change merges cleanly with fix(ci): key the chipdb cache on the openXC7 image so it can hit #852 and ci(fpga): print nextpnr's log when a seed search finds no clean seed #857 (git merge-tree, rc 0).
• actionlint is clean.

Not fixed here

• The other --placer sa workflows. 32 of 61 nextpnr workflows on main pass --placer sa. Some are measurements whose recorded CAD configuration includes the placer, where commits 5f571f9, d6e6978 and 30a230b show it moving Fmax by up to 4.3x. They need a per-workflow audit, not a sweep; that goes in a separate issue.
• A nextpnr crash under SA. Seeds 18 and 19 end in a nextpnr assertion, valid_wires_for_net.count(w) at common/router1.cc:331. Seed 24 cannot route $PACKER_VCC_NET. Neither was seen under HeAP, which is not evidence that HeAP cannot hit them.
• The floating regymm/openxc7:latest tag, used by every workflow. That is a separate decision.

🤖 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

[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

[gHashTag]

Check run for this head (a78f2b5e2, --placer heap): 37211740006, success.

• seed search stopped on seed=1, as predicted from round three on ci(fpga): seed searches hide nextpnr's log when every seed fails #856
• the whole nextpnr (seed search) step took 6 s (15:13:38 to 15:13:44 UTC; the log puts seed=1 5.5 s after the loop started)
• under --placer sa on the same image the first clean seed was 11 (round two on ci(fpga): seed searches hide nextpnr's log when every seed fails #856), and clean SA seeds took 36-113 s each

One run. What it shows is that the switch works on today's image, not that seed 1 will always be clean; round three had 16 of 16 seeds clean under HeAP, which is the stronger number.

#862 now has the same audit for the other 30 --placer sa workflows. Three of them (gf12-clean, gf14-add, gf14-sub) are red the same way gf10-sub was; their SA/HeAP A/B is running and is not part of this PR.