5 ms·

I'm really interested in this subject. What with it being my job. I've thought about this a lot, and the fundamental problem for me is that you have RTLs, but t

• p1esk 5y ago
  Your comment is insightful. But what would be the solution? IP blocks for everything? Smarter compilers/mappers? A dominant FPGA vendor who would force a standard for everyone to follow? Or are you content with the status quo? I mean, I don't see why an FPGA expert wouldn't be :)
  • admax88qqq 5y ago
    Perhaps this is why FPGAs are still relegated to mostly prototyping tools, or niche use cases where such low level reprogrammability is needed. For mainstream use and high perf/low power you're maybe still better off doing custom synthesis.
    • YZF 5y ago
      I'm not quite sure I'm parsing this right but I thought FPGAs were pretty widely used. If you're not using an FPGA then you either need some other general purpose hardware or you need an ASIC. An ASIC is a multi-million-dollar investment. There are many applications that need "hardware performance" but don't justify manufacturing an ASIC. As the parent says, you're likely to be targeting a specific FPGA for your application.
      • duskwuff 5y ago
        > If you're not using an FPGA then you either need some other general purpose hardware or you need an ASIC. An ASIC is a multi-million-dollar investment. And if you are using an ASIC, most of the design is usually carried out in an HDL, just like an FPGA design. The end result may be different, but the process is similar.
      • FPGAhacker 5y ago
        > I'm not quite sure I'm parsing this right but I thought FPGAs were pretty widely used. They are very widely used. Some iPhones used an FPGA. iPhone 7 had a small lattice FPGA. https://www.ifixit.com/Teardown/iPhone+7+Teardown/67382 https://www.ifixit.com/Teardown/iPhone+7+Teardown/67382
        • octoberfranklin 5y ago
          "FPGA" is a big space, like "processor". There are big server CPUs, and tiny microcontrollers. The FPGA in that iPhone is the FPGA version of a microcontroller. Those are very popular, as glue logic, and for kludging in emergency fixes after production has already begun. They are also not terribly difficult to program; you hardly even need an HDL, much like you often don't really need a compiler to program a microcontroller. All the "high level synthesis" pfaff is aimed at the big gigantic $20,000-per-chip FPGAs. Those have mostly been a big fat failure, except for a few big military and cryptocurrency-mining sales. They are wonderful for prototyping ASICs, but that application doesn't sell enough chips to be economically meaningful.
• 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.
• asddubs 5y ago
  I'm an FPGA noob but I really like ghdl. It also has a feature to check code is synthesizable and translate it down to a vhdl 93 netlist, so you can use modern features that proprietary synthesizers may not support in your vhdl codebase
• rthomas6 5y ago
  I do not think it needs full optimality to be useful though. Because the tools are open source, I can see making SpinalHDL et al. to bitfile in a streamlined flow a reality. You can finally have performant, functional languages supported by tools. Because, as someone who uses them every day, VHDL, Verilog, and SystemVerilog are not good.
• tremon 5y ago
  I worked with FPGAs for my master's thesis (specifically, scheduling workloads for a runtime-reconfigurable FPGA). The bad taste of the proprietary tooling is what made me abandon the field. I've always kept an eye on the GHDL and gEDA projects, but open progress has been glacial. The Icestorm project finally opened up FPGAs enough for me to want to work with them, but it came 15 years too late. I agree with you that designing for FPGA hasn't become any easier since the introduction of hardware accelerators inside the chip (multipliers, block rams etc) but the lack of standardization has been hurting the field for more than 20 years. Even upgrading a project from Xilinx $chip to Xilinx $chip++ was a multi-week project.