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!
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!
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.
Also, not supporting new VHDL2008 for years and years, and lagging on newer updates.