images: add pnr-xilinx (openXC7 for Xilinx 7-series) + refresh all pins

[soronpo]

Adds the toolchain DFHDL needs for build -t foss on Xilinx/AMD 7-series, and
refreshes every other pin to its current upstream release.

1. pnr-xilinx

A new image carrying nextpnr-xilinx, bbasm, prjxray (xc7frames2bit, xc7patch,
bitread, fasm2frames) and the prjxray bit database.

Deliberately separate from pnr: openXC7 is a fork of nextpnr
(openXC7/nextpnr-xilinx, -DARCH=xilinx), not an arch of the YosysHQ tree, and it
carries a ~500 MB bit database that ECP5/Gowin users should not pay for. Keeping them
apart also means a Trellis or Apicula pin bump never rebuilds this image, and vice versa.
The database is pruned to the families nextpnr-xilinx-meta also ships (artix7, spartan7,
zynq7), since without site metadata the bba exporter cannot build a chipdb for the rest
anyway. 100 MB sif from an 894 MB prefix.

NEXTPNR_XILINX_REV must stay at or after 6680df93 (openXC7 PR #156). Below it
create_clock does not propagate past the input BUFG, so every build silently reports
PASS at 12.00 MHz whatever the real constraint. Pinned at 3ad30f57, 24 commits after
the fix.

2. Chip databases as release assets

The per-part databases nextpnr places against cannot live in the image (90-670 MB each,
7.8 GB for the full set) and should not be built on a user's machine. scripts/chipdb.sc
generates them from inside a freshly built sif and publishes each as its own immutable,
content-addressed asset under a new chipdbs section of dftools.lock.json.

Generating from the image is what makes them valid: nextpnr asserts that a chipdb's
interned IdString table matches its own constids.inc. For the same reason the workflow
runs that job exactly when pnr-xilinx is rebuilt -- carrying a previous lockfile's
chipdbs past a NEXTPNR_XILINX_REV or PRJXRAY_DB_REV bump would publish databases the
new binary refuses.

Measured, not estimated (plain CPython inside the image):

part	bbaexport	bbasm	.bba	chipdb
xc7a35tcpg236	43 s	3 s	268 MB	93.0 MB
xc7a100tcsg324	71 s	5 s	466 MB	159.6 MB

Well under upstream's "1-3 h per family, 5-30 GB scratch", which must describe the full
34-part set and the large zynq/virtex footprints. No pypy3 needed.

3. Pin refresh

	from	to
ghdl master (synth-vhdl)	ea079441cff0	1391e71fabb8
ghdl-yosys-plugin	a45a8fbf1982	50420290404d
nextpnr (pnr)	nextpnr-0.10	nextpnr-0.11.1
apycula	0.32	0.33
verilator	dde6aa34cebb	f8c296ce2edb
xezim + xezim-core	0.9.8	0.10.3
wavecrux (+ sha256)	0.6.0	0.8.0

Already current and untouched: yosys/eqy v0.68, prjtrellis 1.4, ghdl v6.0.0, nvc
r1.22.1, iverilog v13_0, surfer v0.7.0, gtkwave v3.3.116, openFPGALoader v1.1.1,
fpga-isv v0.2.0.

nextpnr 0.11 moved the himbaechel and Trellis cmake options into subdirectory CMakeLists
files, but HIMBAECHEL_UARCH, HIMBAECHEL_GOWIN_DEVICES (still special-casing all) and
TRELLIS_INSTALL_PREFIX all still exist with the same meaning at the 0.11.1 tag, so the
pnr configure line is unchanged. The wavecrux sha256 was computed from the downloaded
AppImage and matches the checksum in upstream's own update feed.

Also drops the sim-xezim linux-arm64 exclude, which was marked TEMPORARY pending
aionhw/xezim#105. That issue is closed and its fix commit is an ancestor of 0.10.3 and
not of 0.9.8, which is the condition the comment set. CI is what proves the arm64
build actually goes through -- that is the one claim here I could not check locally.

Validation

Done locally on this branch:

• the pnr-xilinx image builds clean and every test.sc probe passes
• the full flow (yosys JSON -> nextpnr-xilinx -> fasm2frames -> xc7frames2bit)
  produces a valid 3,825,899 byte Nexys A7 bitstream from DFHDL's generated output,
  at the design's real 100 MHz constraint (PASS at 100.00 MHz)
• both chipdbs generated from the image and verified against real place-and-route;
  xc7a100tcsg324 comes out byte-identical to the FPGAwars prebuilt, which
  independently confirms chipdb validity tracks constids.inc rather than the revision
• lockfile.sc's new chipdbs section smoke-tested end to end

Left to CI: every other image at its new pin, and the arm64 sim-xezim build. Note the
diff touches scripts/ and .github/workflows/, so affected-images.sh correctly forces
a full 11-image rebuild rather than an incremental one -- a long run, but it means
every image is validated at its new pin.

The DFHDL side (YosysNextPNR.Xilinx7, DFToolsChipdb, the pnr XDC dialect) is a separate
change; until this is released it drives the flow through
-Ddfhdl.dftools.sif.pnr-xilinx and -Ddfhdl.chipdb.<part> overrides.

The two commits are independent if you would rather land the pin refresh separately.

🤖 Generated with Claude Code