Failed in dbfixup.py:153 add_tag_bits (AssertionError) because the
process_rdb name-harmonisation loop folded two distinct-bit Y1 IN
groups onto a single feature name. On Virtex-7 IOB_Y1 LVCMOS*.IN
has bits {38_00,39_01} but SSTL*.IN has only {38_00}; the visited-
iostandard logic forced both onto 'LVCMOS18_SSTL12_SSTL135_SSTL15.IN'
(driven by the Y0 grouping where they happened to share bits),
emitting two contradictory db lines that dbfixup can't merge.
(The existing filter_negbits already expects the un-merged name
IOB_Y1.LVCMOS12_LVCMOS15_LVCMOS18.IN, confirming the merge is wrong
here.) kintex7's Y1 LVCMOS and SSTL share bits, so it never hits
this case.
Fix: require identical bits before adopting a visited name; gate
via XRAY_DATABASE == virtex7 so kintex7's behaviour is provably
unchanged. Adds 'import os' for the env check.
Verified: no duplicate tags; Y1 splits correctly into
LVCMOS12_LVCMOS15_LVCMOS18.IN + SSTL12_SSTL135_SSTL15.IN.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Two unrelated fixes the HP-IOB18 fuzzers need on a full-chip part:
1) top.py for both idelay and odelay collects all IOB18 tiles
('IOB18' in tile_name) but sorted with a key hardcoded to prefix
'RIOB18_' via create_xy_fun('RIOB18_'), which asserts on the first
LIOB18_* tile. kintex7's ROI only ever exposed the R side so this
was latent. Switch to a regex prefix '[LR]IOB18_' (matches the
existing '\\S+' idiom used by 037-iob18-pips). Doesn't change
which tiles get collected, so no-op for kintex7.
2) odelay generate.tcl: Vivado 2020.1 enforces DRC REQP-135 (ODELAY
VAR_LOAD/VAR_LOAD_PIPE requires CNTVALUEIN[0:4] connected) before
write_bitstream, but the fuzzer intentionally leaves CNTVALUEIN
unconnected. The idelay generate.tcl already disables IDELAY's
equivalents (REQP-79/81/84/85/87); add REQP-135 to the odelay
disable list to mirror.
Verified: idelay/odelay both run to completion on xc7vx485tffg1761-2,
producing valid segdata.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The earlier skip blamed a 'Vivado 2020.1 BEL-slot' difference; on close
investigation the real failure was generate.py:79 `assert bels == bels_tcl`
in the my_ram_N branch. The two ROI definitions disagree on X extent:
util.get_roi() (XRAY_ROI_GRID_*) yields SLICEM at SLICE X2..X12, but the
Vivado dump pblock built from $XRAY_ROI is X0..X11 — so the whole
SLICE_X12Y* column top.py LOC's primitives into falls outside the dumped
pblock and shows up as None in design.csv, tripping the assert.
The sibling RAM path already tolerated this via 'if ram != has_bel_tcl:
continue' (line ~137); mirror the same graceful skip in the SRL/LUT path.
For other families bels always == bels_tcl, so the change is a no-op.
Verified end-to-end on xc7vx485tffg1761-2: produces valid LUTRAM segdata
(ALUT/BLUT/CLUT/DLUT.{RAM,SRL,SMALL} + WA7USED/WA8USED/WEMUX.CE), pushes
into segbits_clblm_l/r (clblm coverage 95% -> ~100% vs kintex7).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
xc7vx485t has no IOB33/IOI3 (HR) tiles, so the HR-bank IOB/IOI fuzzers (030-iob,
035-iob-ilogic, 035a-iob-idelay, 035b-iob-iserdes, 036-iob-ologic, 037-iob-pips,
047-hclk-ioi-pips) have no sites. Gate them on a new HAS_HIGH_RANGE_BANKS flag
(0 for virtex7); the HP iob18/ioi18 fuzzers cover the part. Decouple
037-iob18-pips and 047a-hclk-idelayctrl-pips from the now-skipped HR fuzzers.
Kintex-7 and the other families are unchanged.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- settings/virtex7.sh: move XRAY_ROI and XRAY_ROI_GRID off the device bottom
edge (SLICE_X0Y50:X11Y99; grid 5-20/261-312). Edge tiles at Y0 can't exercise
features like BRAM36 ECC/cascade, and the bottom-edge BRAM is unsolvable.
- prjxray/segmaker.py: when a tile has no bitstream info (dummy tile, or an edge
tile dropped from the tilegrid such as BRAM_L_X114Y0 on xc7vx485t), account
for any tags on it and skip with a warning instead of asserting. Fixes the
BRAM config/FIFO fuzzers (027, 029, ...) for virtex7; no-op for normal dummy
tiles. Also print the unsolved tags before the all-tags-used assertion.
- fuzzers/Makefile: skip 018-clb-ram for virtex7 (Vivado 2020.1 packs SRL/RAM
into different BEL slots than the fuzzer pins).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Port prjxray to the Virtex-7 family, modelled on Kintex-7, targeting
xc7vx485tffg1761-2 (vc707). Non-breaking for the existing families.
Family registration:
- settings/virtex7.sh, settings/virtex7/devices.yaml
- Makefile: virtex7 in DATABASES/XRAY_PARTS + db-extras-virtex7 targets
- utils/update_parts.py, update_resources.py: virtex7 choice
- CI matrix (Pipeline.yml), Vivado edition (xilinx.sh), README
Architecture adaptations for the HP-bank-only VX part (verified non-breaking):
- update_resources.tcl: fall back to HP banks when no HR banks exist
- XRAY_IOSTANDARD env (default LVCMOS33; LVCMOS18 for virtex7), parameterised
across the fuzzer generate.tcl files
- fuzzers: enable HP-bank (iob18/ioi18) + IOI/HCLK handling for virtex7;
GTX skipped (ffg1761 bonds only ~7 of 14 GTX quads)
- 005-tilegrid: HP/HR bank tile handling; iob18_int INT offset 3->2;
ioi18 AUTO_FRAME; cfg PDRC-2 DRC disable; add_tdb skips unsolved edge tiles;
per-specimen retry for transient FlexLM SIGSEGV under concurrency
- per-family Vivado version gate (virtex7 -> v2020.1.1)
- XRAY_ROI and XRAY_ROI_GRID tuned to a compact CLBLL+CLBLM region
General fixes:
- tools/bitread.cc: fix use-after-free of the mmap'd bitstream (exposed by the
larger Virtex-7 bitstream)
- utils/environment.python.sh: add repo root to PYTHONPATH (PEP 660 editable
install doesn't expose the repo-root utils/ package)
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Dr Jonathan Richard Robert Kimmitt
Hans Baier
Hans Baier
David Shah