But even better is to get a FPGA supported by the open stack, and not have to deal with any of this.

iCE40 and ECP5 have been pure joy to me.

I'm also not sure what the point of posts like this in general are. "You've done this thing. But I don't like it. Why didn't you do this other thing instead, that I like and confirms my priors?" Well, because they presumably had this particular problem, not whatever problem you would prefer them to have. It would be nice, though.

With proprietary tools, you're simply shooting at the dark.

Because the synthesis QoR and features of Quartus (don’t confuse it with the Quartus GUI) is miles ahead of Yosys and NextPnR.

And, most important, the ease of use and features of Signaltap. The open source equivalents for that don’t come close.

I'm very very much greateful to Yosys/nextpnr and VexRiscV/SpinalHDL developers for their tools and open source IPs which made it possible for me to smoothly enter into the world of FPGAs recently. I tried many times before, but every time I had to install proprietary bloatware it made my sick and puke, sorry.

But they falls far short for anything that requires commercial grade work. (Which I’ve done for years.)

The timing driven synthesis is weak. The ability to specify timing constraints is limited to setting a clock speed. There are no cross clock domain timing checks. There are no multi-cycle paths. The post routing timing reports are indecipherable, with most references to internal signals lost. The NextPnR becomes slow to the point where it’s unusable once the design grows in size. The floor plan viewer is barely usable. There is no way to specify placement regions. There’s no way to do ECOs. There are no netlist viewers that tie in to the layout viewer.

The list goes on and on. And most of these items are absolute basic functionality, nothing corner case fancy.

And did I mention the nonexistent debugging features? Let me repeat that again, just to be sure: there is nothing that comes close to SignalTap.

I don’t understand why “bloat” is considered an argument these days. A Quartus installation is 10GB. So what? That’s 1% of my 1TB SSD.

“Do not get yourselves depraved.”

You guys are weird. :-)

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.

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?

I learned the ropes with yosys/nextpnr, and I am glad. No dependency in proprietary tools whatsoever.

I believe, sooner or later more vendors hop on the train and get their FPGA inners documented and received support from FOSS tools. Also I believe there's a room on the market for a couple of fabless startups offering small-to-middle-tier FPGAs that have only FOSS tools (very small investment in software is needed).

But any strong reason why? Do you prefer specifying the params as part of the module instantiation itself?

One of the main problems with defparam is that you can redefine anything anywhere. The SystemVerilog spec (weirdly) touts this as a benefit: "The defparam statement is particularly useful for grouping all of the parameter value override assignments in one module". Then gives an example that would strike fear into the heart of both verification AND design engineer, where a lone "annotate" module with just defparams redefines the parameters at multiple levels of a completely unrelated hierarchy of other modules.

In reality chip designs are so much larger these days that it would be information overload to try to define ever parameter in a single module that you would have to update any time the hierarchy anywhere in your chip changed. It is just such a nonstarter, it's kind of astounding that statement is still in there. It probably dates back to the introduction of the feature.

Thanks!