3 ms·
I don’t understand why “bloat” is considered an argument these days. A Quartus installation is 10GB. Last time I tried it, it was just 4GBs and that was couple
by ruslan 5y ago
I don’t understand why “bloat” is considered an argument these days. A Quartus installation is 10GB.
Last time I tried it, it was just 4GBs and that was couple of years ago. Did they really improve so much in their design software ? I really doubt so. Most likely they added even more useless junk^H^H^H^Hfeaures into it. Anyway, package size is not a problem, the real problem is that you physically not able to comprehend it, not to mention you cannot compile it from scratch. And you still forced to use GUI for most of the "advanced" features.
I consider myself an old-timer hacker, I come from epoch where FeeBSD release counted 1.0 and Linux... I think there was no Linux at that time, though I might be wrong. I am pretty much used to CLI and to ability to build world from scratch. I'm used to small and neat tools, to possibility to randomly peek into code of a tool I use to get better understanding its underhoods. E.g., some tools have undocumented options like mkisofs -use-the-force-luke, which I learnt by browsing its code. When I see something like Quartus it makes me feel dumb and armless.
Of course, Yosys/NextPnR are missing lots of features, they miss timing driven synthesis mostly because timing database is vendor's top secret. Yet what they provide is a pretty much convenient way for those like me to quickly dive into the world of hardware development, to accomplish quite complex projects in no time. I just finished a project using only FOSS tools that has RISC-V soft-core, DDR3 memory, I2C, I2S, Uarts and FastEthernet + tons of my legacy code above that. It took me less than three months to get things done. During this project I did not feel like I miss any of the "advanced" features, neither I bothered much about timing - it worked well with the defaults Yosys provides. I'm not trying to tell that timing is not important, what I mean is that for middle-sided project like mine one may not need it. And I'm sure by the time I find myself working on a bigger project, Yosys will have all the missing features I would need. :-)
Were I went the conventional way, I think I was still sitting and browsing the list of features Quartus has.
As for debugging, I use Verilator and am pretty much satisfied with it - good old printf does its trick. On real hardware, oscilloscope is your best friend of course. :-)
PS: I like the way ecpbram updates RAM content of an already synthesized bitstream statistically analyzing it - pretty clever hack. I just read how same effect can be achieved in Quartus - it's really mind-bogglng.
- tverbeure 5y agoWhy 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?