5 ms·
For some context, Verilog to Routing (VTR) [1] is a framework for open-source FPGA synthesis, implementation, and FPGA architecture exploration/modeling. The co
by stefanpie 3y ago
For some context, Verilog to Routing (VTR) [1] is a framework for open-source FPGA synthesis, implementation, and FPGA architecture exploration/modeling. The core of VTR is Versatile Place and Route, also known as VPR (a little confusing, VPR is part of VTR). The synthesis part is not really the novel part of VPR since it is mainly done by existing tools including `odin`, `yosys`, and `abc`. The exciting part is VPR.
VPR mainly tackles the problems of packing, placement, and routing. Given any netlist (circuits with gates, other components, and wires), how might one map that circuit to the resources on a specific FPGA architecture (with LUTs, FFs, DSPs, Memory) and also route the design using the FPGA's routing resources? These are typically modeled as optimization problems with many ways to approach them.
For example, placement (putting the circuit elements in your circuits onto a resource on the FPGA at a specific location) is done using a simulated annealing optimizer to minimize "the distance between any two placed elements that are connected in my circuit."
Routing is a bit more complex. Given the graph of all the nodes (routing switches, FPGA element inputs, FPGA element outputs) and edges (physical metal wires on the chip die), one can build a routing graph of the entire system (many implementations model the opposite, where nodes are wires and edges are routing switches). Routing your circuit entails finding non-overlapping subgraphs that connect all the nodes that need to be connected (in your circuit, the output from one gate needs to connect to the input of another gate). I believe VTR uses a variation of the "Pathfinder negotiated congestion algorithm."
Finally, what's nice about VTR is that you can define your own custom FPGA architectures that you want to use in the tool. In this architecture description, I can describe all the elements in my FPGA and how they are all laid out in the FPGA grid and how they connect to each other via routing resources. Useful if you are a startup trying to make and sell your own FPGA with it's own architecture and don't want to write your own EDA tools from scratch.
Digging through the C++ source code for VPR is super interesting as to how these high-level optimizations are solved with various solutions. Since most EDA tools are closed-source, you usually never see this, let alone make contributions and experiment with new ideas.
For me personally, I am fascinated by the EDA algorithms themselves that actually implement the designs and solve these hard, messy optimization problems. I feel like the Hacker News community might find the same aspect interesting.
[1]: "VTR 8: High-performance CAD and Customizable FPGA Architecture Modelling": https://dl.acm.org/doi/10.1145/3388617 https://dl.acm.org/doi/10.1145/3388617
Edit / Source: I don't work on VTR directly but I use VTR for my own research, parts of my research are in the same field, and I see the students and PIs who work on VTR at same conferences I go to.
- msapaydin 3y agoDoes this support Xilinx pynq?
- mathisfun123 3y agosupport 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 agoThis 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 agoI 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)
- 3y ago