4 ms·

All of this. There is a reason why NextPNR, the project mentioned in the article, uses custom code for every architecture instead of a fixed database. There is

by ATsch 5y ago

All of this. There is a reason why NextPNR, the project mentioned in the article, uses custom code for every architecture instead of a fixed database. There is also a reason why almost everyone uses nextpnr instead of the alternatives that use such a single format chip database. It is an approach that, according to all current evidence, suits itself well to experimentation and research, but does not scale to large and complex real world architecures.

adapteva 5y ago
If by the alternative you are referring to VPR, you are wrong. There are both public and non-public FPGA tool chains based on modified versions of VPR (and some of them are far more complex than what is currently handled by nextpnr).
mithro 5y ago
Except that nextpnr is one of the tools supporting the interchange format and you can see the status at https://symbiflow.github.io/fpga-interchange-tests/ https://symbiflow.github.io/fpga-interchange-tests/
aseipp 5y ago
This isn't quite how nextpnr is architected. Yes, there is architecture-specific code for each targeted FPGA such as ECP5, Gowin, Nexus parts, etc. But those architectural components are largely descriptions of the physical components that exist on the chip, and how they're wired together. Each architecture does implement a basic interface for describing logic elements. But it's not like there's a separate placer or router for each architecture that's hand tuned to the primitives. The placer and router have to work in abstract on some basic logical unit for any code reuse to occur at all! Go look at the ECP5-specific code in NextPNR for instance; it's all actually very small and there's nothing too magical about it. It has some device-specific passes, but that's not really unusual (a software compiler might have heavily generic APIs for all machines, and then some machine-specific passes, too.) Most of it is just "This is what a logical element looks like" or "What I/O standards are valid for pin XYZ" and other rote stuff. Some of this is boilerplate or chaff and some of it is actual wheat, but it's not like, earth shattering. Any compiler developer would think it's normal... In short: each architecture has some code for it, and often a lot of it is boilerplate. Some of it is for specific purposes (some devices might have specific rules about promoting clock lines or global device objects, whatever, and you might put them there.) But the generic descriptions of what the place-and-route algorithms work with, the "Basic Elements of Logic" (BELs), that's exactly what this project aims to solve. It describes how an Artix-7 or an ECP5 device can theoretically be mapped to these basic place-and-route abstractions. All EDA tools work this way... nobody would completely rewrite a placer and router ground up from scratch for every target architecture or PDK for every client they have or whatever. They all work at some level on an abstract description of a physical layout, and the vendor brings the real meat to the table and wires them together. The question of API design and where to draw the line between those two is, well, software engineering. So it's not like there will be effortless magical zero-effort plug-and-play between NextPNR and some random architecture. It just means that the integration work that must happen is now easier. That's it. So this does not make technology mapping more effective or anything like that more effective. It's just an efficient binary format for describing the FPGA wire layout with enough fidelity to do things like place-and-route effectively. That's all; it doesn't really improve expressiveness, fmax, or anything like that. It's a developer velocity thing so that vendors and tool developers get a little more stuff "for free" than before. Honestly as long as this lets me use NextPNR for Xilinx devices easily, I'm fine with it. As the maintainer of NextPNR for a package manager there might also be ancillary benefits for me but I don't think those matter much.

by ATsch 5y ago

adapteva 5y ago

If by the alternative you are referring to VPR, you are wrong. There are both public and non-public FPGA tool chains based on modified versions of VPR (and some of them are far more complex than what is currently handled by nextpnr).

mithro 5y ago

Except that nextpnr is one of the tools supporting the interchange format and you can see the status at https://symbiflow.github.io/fpga-interchange-tests/ https://symbiflow.github.io/fpga-interchange-tests/

aseipp 5y ago

This isn't quite how nextpnr is architected. Yes, there is architecture-specific code for each targeted FPGA such as ECP5, Gowin, Nexus parts, etc. But those architectural components are largely descriptions of the physical components that exist on the chip, and how they're wired together. Each architecture does implement a basic interface for describing logic elements. But it's not like there's a separate placer or router for each architecture that's hand tuned to the primitives. The placer and router have to work in abstract on some basic logical unit for any code reuse to occur at all! Go look at the ECP5-specific code in NextPNR for instance; it's all actually very small and there's nothing too magical about it. It has some device-specific passes, but that's not really unusual (a software compiler might have heavily generic APIs for all machines, and then some machine-specific passes, too.) Most of it is just "This is what a logical element looks like" or "What I/O standards are valid for pin XYZ" and other rote stuff. Some of this is boilerplate or chaff and some of it is actual wheat, but it's not like, earth shattering. Any compiler developer would think it's normal... In short: each architecture has some code for it, and often a lot of it is boilerplate. Some of it is for specific purposes (some devices might have specific rules about promoting clock lines or global device objects, whatever, and you might put them there.) But the generic descriptions of what the place-and-route algorithms work with, the "Basic Elements of Logic" (BELs), that's exactly what this project aims to solve. It describes how an Artix-7 or an ECP5 device can theoretically be mapped to these basic place-and-route abstractions. All EDA tools work this way... nobody would completely rewrite a placer and router ground up from scratch for every target architecture or PDK for every client they have or whatever. They all work at some level on an abstract description of a physical layout, and the vendor brings the real meat to the table and wires them together. The question of API design and where to draw the line between those two is, well, software engineering. So it's not like there will be effortless magical zero-effort plug-and-play between NextPNR and some random architecture. It just means that the integration work that must happen is now easier. That's it. So this does not make technology mapping more effective or anything like that more effective. It's just an efficient binary format for describing the FPGA wire layout with enough fidelity to do things like place-and-route effectively. That's all; it doesn't really improve expressiveness, fmax, or anything like that. It's a developer velocity thing so that vendors and tool developers get a little more stuff "for free" than before. Honestly as long as this lets me use NextPNR for Xilinx devices easily, I'm fine with it. As the maintainer of NextPNR for a package manager there might also be ancillary benefits for me but I don't think those matter much.