Oy. I'm a Python guy, but Tcl is NOT that bad. Do not blame the horrible software engineering at Altera and Xilinx on Tcl. Those companies make more than enough money that they could sit down with Tcl and Tk, spend some time on the code, and have a quite decent tool. Instead, they keep their bitstream completely closed to lock out competitors and saddle the world with shitty tools.
I'm really surprised that Lattice hasn't tried to go around Xilinx and Altera by doing exactly that. You would think that an open bitstream format and a couple million dollars thrown at academic researchers (Lattice makes about $200 million per quarter in gross profit) would produce some real progress, but I digress ...
SystemVerilog, on the other hand, was specifically created because Verilog and SystemC got loose to the end users and the EDA companies were not going to make that mistake again. So, yeah, SystemVerilog is pretty bad.
Open source tooling would not materalize if bitstream formats were opened, at least not competitive ones. Why? There are already open source versions for synthesis and PnR , and while functional they are very far off the 'terrible' EDA tools everyone rags on Xilinx for. The reality is SystemVerilog is a huge language, and already an open standard yet no open source project supports it fully, so I don't believe for a second if bitstreams were opened we'd see a load of top class tooling appear for synthesis and PnR. The reason is if it has not happened for the first (and arguably easiest) step in the chain i.e. System Verilog, they why would it happen for the others?
> There are already open source versions for synthesis and PnR , and while functional they are very far off the 'terrible' EDA tools everyone rags on Xilinx for.
These "tools" have no target so no incentive to improve. To use them you have to basically push their results back into a Cadence/Synopsys/Mentor toolchain anyway, so you might as well stick to the supported toolchain.
> The reality is SystemVerilog is a huge language, and already an open standard yet no open source project supports it fully
Most commercial systems don't support it fully. And its not clear that SystemVerilog is that superior to VHDL. And, for quite a while, SystemVerilog wasn't open and had some fairly obnoxious patents surrounding it. I don't know when/if that has changed as I have been out of semiconductors for about 20 years now.
Icarus Verilog has been slowly supporting features from SystemVerilog but doesn't have a lot of manpower.
In general, the consolidation of the semiconductor industry and EDA has hurt open-source EDA improvements. There's not very much money coming from companies to fund EDA research. EDA startups can't really get venture funding since VC's all want to fund the next pile of viral social trashware. And anyone with good software skills left the semiconductor industry eons ago because the pay differential is ridiculous.
The commercial FPGA tools have tremendous technological advantages, but the free part is inherently what many FOSS users value, not the other stuff. You're trying to talk about technical QoR between tools but the difference for anyone who really cares is ideological, not technical.
> The reason is if it has not happened for the first (and arguably easiest) step in the chain i.e. System Verilog, they why would it happen for the others?
Ehhhhh, I don't think I buy this at all. There are dozens of alt-HDLs out there, many of which are quite powerful, designed by solo users. People had working, simple-but-practical PnR for real devices in a ~7k C++ LOC codebase written by an individual (arachne-pnr) and many individuals have independently reverse engineered small-ish scale device families for packing utilities. nextpnr was written by a very small group (solo?) in a year or something. I don't think you could fit an equivalent parser for SV2017 in ~7k LOC, much less elaboration, type checking, a netlist database, to all go along with it. SystemVerilog might actually be the most difficult part of the whole equation because it simply has so much surface area. PnR tools are limited by their target: only targeting small iCE40 devices? Your PNR algorithms don't need to be cutting edge. Targeting SV2017? Your job is hard no matter what device you synthesize for. And I can't think of even a single commercial tool I know from any vendor that supports all of it, up-to-date with SV2017.
All that said, I use SystemVerilog as my "normal" RTL when using commercial tools for stitching together IP, wiring up top modules, etc.
My point a out SV was that the two major open source simulation tools (Icarus and Verilator) both only support a subset of SV, and not SV 2017, but a lot of SV 2009 is still not supported. Vivado has a free (not open) SV simulator that supports much more of the language. I agree not all of SV is needed for PnR, but what I'm saying is if we don't have the gcc or clang version of SV for simulation yet (vs MSVC or ICC), then what makes you think we'd get a near commercial grade synth / PnR tool? If Xilinx opened up their bitstream format, academics would rejoice, but it would not suddenly spur on a huge improvement in open source PnR tooling. In terms of improving the usability of what is there, given vivado is scriptable, if you want to make a better open one (like an IDE) you can, just call synth_design, etc in batch. This was what Heir Design were doing, and what turned into Vivado after they were acquired by Xilinx. So my point is lots of open source tooling could exist without opening the bitstream format, so given it largely does not, I am of the opinion opening the bitstream format would not change much.
> but the free part is inherently what many FOSS users value
The free part is valuable not in that it's cheap, but in that it saves you from having to deal with licensing.
DevOps pioneers hailed from the likes of Google, Amazon and Facebook, who are not exactly short on cash, but you simply couldn't do what they did if you had been nickeled and dimed at every VM and container.
I have not benchmarked the open source PnR tools, but I expect they are orders of magnitude worse qor than what a commercial one can do. I don't know a LOC comparison between SV and PnR but I'd say both are huge undertakings at commercial features set.
> already an open standard yet no open source project supports it fully
Bitstreams are closed. There's little to no point in doing an open source compiler if the target is not just proprietary, but deliberately opaque.
Overall your comment strikes me as what a proprietary compiler advocate would say in the 90s. "GCC? Lol"
Since then, Microsoft had to include Linux in Windows just because they absolutely needed Docker. DevOps was invented based on free/open source, it just couldn't be done proprietary style by a company as large as Microsoft.
I disagree. By far the largest part of SystemVerilog deals with verification, both simulation and formal property proving. These parts have nothing to do with the bitstream formats and the tooling in that area is quite as lacking as the synthesis and PnR tools.
The limitation here is writing the SystemVerilog parser and compiler.
What's the incentive for free software hackers and startups to even begin to work on this if the rest of the stack is not just proprietary, but held by actively hostile entities?
There are other places to start working on the stack which is not as actively hostile as place and route, e.g. simulation.
As for the incentive I'm fairly pessimistic. There is definitely no money to be made for a start-up in this space, it is way too conservative. Maybe the hobbyist intellectual challenge of working on some hard problems like constraint solving or formal property proving? There is a massive task of writing a SystemVerilog parser before you get there though and the SAT solving and property proving problems are present elsewhere with lowers barriers to entry.
Challenges can be stimulating, but there are diminishing returns. It's not like say, lockpicking or DRM-cracking, in that the subject matter is super hard to begin with, even without the proprietary sabotage.
Having said that, there has been some promising F/OSS work on the small Lattice devices. It allows for a decent, modern workflow, and it's possible because the devices are approachable, but also because Lattice hasn't been hostile. Why they haven't been more supportive is a mystery to me however.
TCL itself is not that bad for the purpose IMO; it's more the stuff around it, the proprietary binary formats, the gooey crap, and the non-open nature thereof.
Tcl is the de facto EDA tool scripting language. It's standard in the HW design world - of course it does not stop there being a second alternative scripting language, but not having TCL would alienate much of the HW design community, so must be there. As for the HDL, vivado supports SystemVerilog, VHDL, and C via HLS. I happen to like SystemVerilog, what about it makes it terrible?
TCL is the only language I have ever worked with where a comment would affect the next line. Might have been an interpreter issue, but it was enough for me never to want to touch it again.
SystemVerilog is a good examle of an organically grown language with no 'benevolent dictator'. A few pet peeves:
* Why is the simulation delta cycle split into 17 regions? Exactly when does the Pre-Re-NBA region happen and what assignments take place there?
* Why can't a function return a dynamic/associative array or a queue? This is clearly possible, since the array find functions return a queue, but it's not possible to define a user function with this return type.
* It has way too much cruft. E.g. what problem does the forkjoin keyword solve? Who thought that was necessary and why? Not a fork-join block, the forkjoin keyword.
* Why can't you have a modport inside a modport? This would be great for e.g. register interfaces, but modports are not composable.
* What is the difference between a const variable and a localparam and why does the language need both constructs?
* Is a covergroup a class or what? It behaves very much like it is, it has a constructor, some class local information and at least one class local function (the sample()
function), but you can't extend it.
* Why are begin-end used for scope delimitation everywhere except in constraints where curly brackets are used? I know it was a Cadence donation, but why wasn't the syntax changed before it was merged? Backwards compatibility can only justify so much...
You're right about tcl, a comment can mess stuff up as the comment is a command that says do nothing. It's a terrible language, and that may be it's worst flaw, but it's still in every EDA tool. It's kind of like how C is still around despite its foot shooting ability costing billions every year due to security and bugs due to buffer overflows, etc. If an EDA tool wanted to break the mold and use say python for scripting they would still likely need to offer a tcl option. It's very ingrained in industry.
As for SV - a lot of your gripes are Verilog issues, and SV has tried to fix some of them. I agree the blocking / nonblocking is a mess but most folks just learn the rules to avoid issues, but delta cycles can be a pain. The syntax limitations/quirks you point out are intersting, though not enough to say the language is terrible, it's extremely powerful with very good composability of types, constrained random is very powerful, the coverage is extensive, assertions again are very powerful. In a way its line a few seperate languages bolted together so sure there is some duplication, but it works surprisingly well in the whole.
Those toolchain disasters are not quite as hilarious when you have to use them daily....