Why do you care what they did with those additional 6GB? How does it change the way you do your job? It’s just bits on an SSD. My Makefile to build a Quartus de

Why do you care what they did with those additional 6GB? How does it change the way you do your job? It’s just bits on an SSD. My Makefile to build a Quartus design today is identical to the one 8 years ago. I don’t care how much disk space it needs to execute those commands. What I do know is that in those 8 years, Quartus added support for tons of new devices, major new place and route improvements, better SystemVerilog support, it unified MegaWizard and Qsys handling, it added a pin assignment exploration tool that was a huge time saver when figuring out a new configuration. And more. Stuff that a hobbyist might call junk, can be immensely useful for a professional. “I don’t understand it, it must be junk.” And you’re wrong: NextPnR has a perfectly usable timing database. It already does static timing analysis as long as you stay within the same clock domain. What it lacks is a decent static timing analysis engine. One that has the features that commercial STA engines have had for the last 20+ years. It’s telling that you consider your project mid-sized. It’s not. I don’t know why you feel the need to drag simulation into the discussion. It’s a completely different topic, and Verilator is a fine tool. As for “still browsing the list of Quartus features”: have you considered the possibility that these kind of features are exactly what you need to create something that can be produced in volumes of millions without fallout? Did you do IO margin analysis on your DDR interface to check its behavior over PVT corners? Which IO is most marginal? How many picoseconds are you away from failure? How wide is the eye? How would you do any of that with your open source tools?