The Current State of FPGA tools

[zygot]

Since the early days of ISE Xilinx has has a habit of releasing tool versions that were just too buggy to use. 20 years ago you could find a vendor FAE who would be willing to steer you around the bad tools.. off the record of course. There was a time when Altera Quartus was quite bug free and reliable. Those days are long gone. Now, it's almost impossible to install the latest tools on any particular version of an OS and hope that they are supported... much less are reasonably functional to where you can work on your projects rather than hunting down bugs and work-around fixes.

The impetus for this post is a recent experience with Quartus 20.1 in Win10 for a PCIe based project. Quartus 20.1 supports the Cyclone V/IV. Quartus 20 versions later than 20.1 not so much. What I found out is that I can use Quartus 20.1 on a number of Linux platforms for Cyclone V PCIe projects but not on Win10. I haven't tracked down a fix yet as what I really want to do is complete my project. So, I can use Quartus 18.1 on WIn10 or Quartus 20.1 on Centos 7 or Unbuntu 20.04.

The idea that if you want to build a particular project, or even recompile a demo designed with another version of the tools, and be required to install not only the exact version of the tools that the original project was build on but also install a 'supported' OS that meets the criteria for a particular tool version is pretty absurd. It's also absurd to spend more time working out tool bugs than working out your project. Mostly these problems revolve around vendor IP, but the vendors make it impossible to implement some projects without using one or more of these. If your current project is a derivative of a project from a third party then the odds of completing a project in a reasonable amount of time are pretty low.

I realize that this is a bit of a rant but the typical reader of the Digilent Forums are no stranger to the kinds of problems I'm talking about. Since even smallish companies can't expect good technical support from the vendors or distributors who's going to step up and address the issue that currently the tools from the major vendors are broken. It would be nice if board vendors providing support for their products would do that.. if allowed. This doesn't have to be as bad as it is. At least knowing what to avoid or a list of how to set up the tools for actual OS versions that we use would be nice.

I think that it's time for the FPGA partners making development hardware to step up and start doing what the typical user can't and that is push back on the device vendors to make life for their customers a bit more productive. This starts with how they support their own products.

Edited March 17, 2021 by zygot

[RTalis]

Since before time man misrepresents product for profit.  OK i like Xilinx KU115 Ultra  on 8K5 board with 16GB 2bank RAM & 4 optical 40GB ports & 2  InfiniBand SFP+ ( hurrah get away from that <moderated> PCIe bottleneck) yet Xilinx still cant design a board like this Alpha Data & priced at $3800,  its also IBM P8 / 9 CAPI (finally a good Arch)

Now that Xilinx has a combined staff of 13,000 engineers , and i kno how they "hide behind" workloads ..may volunteer to manage a new AMD Epic  that does away with software supervision outside the kernel .    ANd here Xilinx were pouting about kernel byoass , where user space is handed control of runtime permissions.

 No wonder their Vivaldo is broken ,  with RDMA from 3 standards, Linux kernel now amorphous rather than monolithic , and soon to become the OS

  the OS always gets in the way of production ..its obsolete.  BEsides monthly kernel changes break many libraries any managed suite relies upon

 i personally like eBPF with control plane granularity in the core , i wonder when Compilers move to a different event loop supervision model, to kill of OS dependence\

 The kernel is the new OS .. yet another issue is speculative execution . it needs termination for smooth workflow,  CPU is  dead  as well, try telling a compiler.