3 ms·

Does this support Xilinx pynq?

by msapaydin 3y ago

mathisfun123 3y ago
support isn't even in the vernacular with these kinds of tools: https://docs.verilogtorouting.org/en/latest/vtr/cad_flow/#vtr-cad-flow https://docs.verilogtorouting.org/en/latest/vtr/cad_flow/#vt... 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).
duck2 3y ago
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.
- ZirconiumX 3y ago
  I should point out that even the F4PGA page [admits](https://f4pga.readthedocs.io/en/latest/how.html https://f4pga.readthedocs.io/en/latest/how.html) that ECP5 and iCE40 support is done through nextpnr, rather than VPR. (actually nextpnr has slowly-maturing support for Lattice MachXO{2,3}, Intel Cyclone V and Gowin parts too)

3 ms·

Does this support Xilinx pynq?

by msapaydin 3y ago

Does this support Xilinx pynq?

mathisfun123 3y ago
support isn't even in the vernacular with these kinds of tools: https://docs.verilogtorouting.org/en/latest/vtr/cad_flow/#vtr-cad-flow https://docs.verilogtorouting.org/en/latest/vtr/cad_flow/#vt... 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).
duck2 3y ago
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.
- ZirconiumX 3y ago
  I should point out that even the F4PGA page [admits](https://f4pga.readthedocs.io/en/latest/how.html https://f4pga.readthedocs.io/en/latest/how.html) that ECP5 and iCE40 support is done through nextpnr, rather than VPR. (actually nextpnr has slowly-maturing support for Lattice MachXO{2,3}, Intel Cyclone V and Gowin parts too)