Biggest pet peeve of FPGA toolchains

4 points by vWijdaan 2 days ago

I’m interested - what’s everyone’s most hated features of AMD/Intel FPGA toolchains?

I was having a discussion with my colleagues, for us it’s the overcrowded UI. So many cluttered buttons and features, half of which we never use…

We were debating about what the most hated features would be in the wider FPGA community. Tell me your thoughts!

elevation 2 hours ago
Xilinx ships IBERT cores so you can test high speed lanes between devices. When you bake them into a bitstream and configure an FPGA, you can read/clear the status of the cores over JTAG via the UI or a TCL script.
Using these cores in particular have revealed a bunch of issues with the Vivado suite:
Inconsistent naming conventions: In a Vivado block diagram, you must figure an IBERT core to use a transceiver by bank number, e.g, Quad 127, Quad 224. But when you get per-lane test results they reference transceivers as X0Y1, X0Y23. The official “packaging and pinout” documentation will help you translate between these identifiers, but you shouldn’t need to: the Towing should use a consistent naming convention in both the design flow and the test flow.
Another issue: incomplete script Support. When you’re viewing the status of an IBERT core over JTAG, you can see a lot of meta data in the details panel, but not all of this information is available in the TCL objects provided to the script console. This means that certain checks cannot be scripted.
Bad UI architecture: all TCL commands run in the UI thread, so long running commands can lock you out of even unrelated actions for minutes at a time.
TCL was novel in the 90s, but it is haggard, and ill-suited to this line of work. Give me python!
elevation 1 hour ago
Also, you can’t generate a bitstream for a hello world design without getting 10^5 warnings about why the fit for your part could be suboptimal. The signal to noise is awful.
Also, not supporting new VHDL2008 for years and years, and lagging on newer updates.
elevation 1 hour ago
Another Vivado bugaboo: terrible support for source control.
My current flow is to use the ‘write_project_tcl’ command to export a tcl script that would rebuild the project from a single command. Tracking this in git along with your RTL and constraints should be enough. But the file is jam packed with hard coded paths that have to be carefully removed, or else the source can’t be built on another machine. I wrote a custom tool to post process “setup.tcl” but it is brittle because with every new release, Vivado tampers with the output format.