[jlokier]

Can confirm. I used Xilinx Vivado to compile for their FPGAs in Amazon F1 servers a few years ago. There came a point when each time I edited a single small Verilog file in my small project, the GUI took 40 minutes of 100% CPU just to update the file list in the GUI. That's before you could do anything useful like tell it to compile or simulate. The GUI wasn't useful until it finished this silly update.

I knew FPGA compilation could be slow, but this wasn't compilation, this was a ridiculously basic part of the GUI. I knew it had to read my file and analyse the few module dependencies, but seriously, 40 minutes? At that time I just wanted to run simple simulations of small circuits, which shouldn't be slow.

In (open source) Verilator, the same simulations ran from the same source files in just a few millliseconds with nothing precomputed or cached.

I looked into what Xilinx Vivado was really doing and found a log indicating that it was re-running a Verilog read on the changed file several thousand times, each time taking a second or so.

That was such a ridiculous bug for software Xilinx said they had spent over $500M developing. If there were good parts of the software I didn't get to see them due to this sort of nonsense. I think it was fixed in a later version, but due to (yay) enforced licensing constraints I couldn't use a fixed version targeting these FPGAs. That's when I abandoned Vivado and Xilinx (and Amazon) for the project as I didn't have that much spare time to waste on every edit.

I am under the impression the current crop of open source FPGA and especially open source ASIC tools are much better designed.

[MichaelZuo]

> I looked into what Xilinx Vivado was really doing and found a log indicating that it was re-running a Verilog read on the changed file several thousand times, each time taking a second or so.

Just reading that made me nauseous, to think this forced so many trillions of CPU cycles to be spent on nothing, and nobody at Xilinx corrected it until some time later.