propagate_IOB_SING and propagate_IOI_SING walk each IO column from a
parent IOB/IOI tile down to the SING half-tiles at the column endpoints
and alias the parent's CLB_IO_CLK bits into both halves (offset=0 for
the bottom SING, offset=99 for the top SING). The parent-type
allowlists were missing the HP-bank L-column types:
propagate_IOB_SING: ["LIOB33", "RIOB33", "RIOB18"] # LIOB18 missing
propagate_IOI_SING: ["LIOI3", "RIOI3", "RIOI"] # LIOI missing
On artix7 / kintex7 the leftmost HP column doesn't exist as a parent
LIOB18 / LIOI in the tilegrid, so the omission was latent. On
virtex7 VX (HP-only) both LIOB18 and RIOB18 columns exist, and the
gap surfaces as half the SING IOB / IOI tiles (the L-column ones)
having empty bits in tilegrid.json:
LIOB18_SING: 0/14 with bits -> 14/14
RIOB18_SING: 14/14 (unchanged)
LIOI_SING: 0/14 with bits -> 14/14
RIOI_SING: 14/14 (unchanged)
Add the missing types. Cross-checked against iob18's own measured
parent bases (e.g. LIOB18_X81Y2 -> 0x00421000 lines up with the
propagated LIOB18_SING_X81Y1 base 0x00421000 offset=0 and Y51 offset=99).
Also de-wire the iob18_sing sub-fuzzer from TILEGRID_TDB_DEPENDENCIES:
SING tiles aren't independently addressed (they share the parent IOB's
base with a word-offset variant), and half of iob18_sing's tdb entries
land at an unaligned frame (offset+1) that add_tdb's frame-alignment
assertion would reject anyway. The build rule stays so the fuzzer can
be invoked manually as a Vivado-measurement guard for the propagation.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The existing iob18 sub-fuzzer filters to IOB18S (main IOB of a diff
pair) and ioi18 explicitly skips _SING tile types, so the SING-row
IOB18 singletons (one IOB18 site per LIOB18_SING / RIOB18_SING tile)
never had their tilegrid frame addresses resolved. On xc7vx485t this
left 28 tile rows un-addressed in tilegrid.json.
Add a parallel iob18_sing sub-fuzzer: places an IBUF on every SING-row
IOB18 site (14 specimens), bit-diffs to a segbits_tilegrid.tdb, and
hooks into TILEGRID_TDB_DEPENDENCIES alongside iob18 / iob18_int so
add_tdb.py merges the resulting frame addresses into tilegrid.json.
Pairs with task #17 (HP-bank glue end-to-end).
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>
The 'make clean' command in the top-level Makefile calls 'clean' of all
fuzzers. The top-level Makefile does not source and settings file before and
therefore no XRAY_PART is set.
The 005's fuzzers only cleans data for a XRAY_PART file, which is not set.
Remove all fuzzer data during clean and only for a specific part during
clean_all.
Signed-off-by: Daniel Schultz <d.schultz@phytec.de>
Fabric data should be deployed to a separate directory inside the database
and all devices with the same fabric should access it.
Signed-off-by: Daniel Schultz <d.schultz@phytec.de>