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>
For xc7z boards the Debug bitstream is unavailable. To get the necessary
information we can use the FAR addresses present in the perframecrc
bitstream.
The gen_part_base_yaml tool has been modified to have the possibility to
read the FAR addresses depending on a flag setting.
Signed-off-by: Alessandro Comodi <acomodi@antmicro.com>
Xilinx tools generate and expect an additional header to be added to the
bitstream. This header is the only difference between .bit and .bin
files and is not required by the part in any way. OpenOCD only supports
reading .bit files so the easiest path to a using FOSS tools from FASM
down is to generate a .bit header in xc7patch's output. To distinguish
xc7patch-generated files from Xilinx-generated files, the source file
field includes a Generator tag indicating that the bitstream was produced by
xc7patch. Vivado uses the same technique to record the Vivado version
in a Version tag.
Signed-off-by: Rick Altherr <kc8apf@kc8apf.net>
Bitstreams generated by xc7patch can now be directly loaded into parts
via Vivado's Hardware Manager (bitstream must have .bin suffix) or by
flashing into a boot FLASH.
Signed-off-by: Rick Altherr <kc8apf@kc8apf.net>
ConfigurationPacket assumes that the payload data is owned by someone
else. For frame data, that is generally true. For initialization and
finalization sequences, those payloads need to be created and managed.
Instead, dynamically allocate packets which allows for using subclasses
of ConfigurationPacket that store the payload with the packet.
Signed-off-by: Rick Altherr <kc8apf@kc8apf.net>