This kind of stuff requires access to the complete architectural parameters of the device, so adding support for even a single device family is a huge reverse-engineering^W documentation effort.
See f4pga.readthedocs.io which consolidates pretty much everyone's efforts into a distribution, but supports only 4 device families: iCE40 and ECP5 from Lattice, some 7-series devices from Xilinx and EOS-S3 from QuickLogic.
For internal testing, VPR has "Stratix IV-like" and most recently "Stratix 10-like" architecture files but these don't try to "document" the whole thing, they just want a close enough approximation to a modern device to evaluate the tool better.
the question of pynq support is addressed/implicated in several places (timing/delay maps, tech mapping, bitstream generation).
the short of it: this shit is proprietary/encumbered beyond belief.
the medium of it: there are OSS flows that can generate bitstreams for pynqs (depending on the actual FPGA part) but they are not at all supported by AMD (formerly Xilinx) and rely on rev-eng work. the problem is while burning a bitstream is important, it's not the only thing you need to make OSS worthwhile. in particular you need the timing/delay maps and as far as i know, those are all shipped encrypted with vivado (and the cracks haven't been released).
See f4pga.readthedocs.io which consolidates pretty much everyone's efforts into a distribution, but supports only 4 device families: iCE40 and ECP5 from Lattice, some 7-series devices from Xilinx and EOS-S3 from QuickLogic.
For internal testing, VPR has "Stratix IV-like" and most recently "Stratix 10-like" architecture files but these don't try to "document" the whole thing, they just want a close enough approximation to a modern device to evaluate the tool better.