> Also specifically with Xilinx they seem to have zero consideration for basic version control and create/duplicate/modify an explosion of files and cached versions of files.

There is an ugly feedback loop here. HDL tools interact poorly with version control -> it is difficult to collaborate using those tools -> HDL engineers would rather silo up than fight the tools -> no pressure to improve tools' support for version control.

Perhaps there is some truth in your assessment but I think the lack of pressure on tool support is more related to the lack of industry-grade alternatives, more so than HDL teams clinging on to a desire of developing like it's 1989. The reality is that nowadays HDL teams are composed of a lot of people with CS and CE background, who are obviously aware of sane development processes and practices. You will find that a lot of people simply use their text editor of choice and then just use the vendor's tool whenever absolutely necessary with a 7 foot pole (from a script or CLI if possible).

The problem again (in my very speculative opinion) is that you have a very limited set of vendors who have a complete lock down on their hardware.

Imagine a world without gcc or llvm and only Intel or AMD could provide you with a compiler. Imagine also that they would provide you with this compiler for free, such that their business model was entirely based on them selling their CPU's. How much pressure would they have in providing a high quality toolchain?

It's not like their customers are gonna run away to a non existent competition they still need to buy CPU's and they would be stuck with their 'barely works' toolchain.

You can see the difference if you compare FPGA vendor software with HDL simulation software. Simulators are in the business of selling you software so they have pressure to actually deliver quality software. FPGA vendors are in the business of selling _silicon_ (@saagarjha) so they pretty much see the toolchain as an operational cost.

Xilinx's toolchain is the worst piece of software I've ever had to work with.

There are two things that amaze me:

1. That the dumpster fire is actually capable at all to synthesize hardware without exploding

2. That their head of software still has a job.

I'm so happy to read ratings of Xilinx here. I'm a novice to the world of FPGA, and I've spent so much time fighting the tools.

My very favorite issue is with their IDE. The version I'm using has a broken search and replace... if the two strings have different lengths, the editor loses its place after the first replacement -- they compute the location of matches and then just smash the replacement strings in... failing to maintain an offset as character offsets change. Makes me scream.

I'm using Vivado after having previously attempted Quartus and I can't actually say it's any worse. I was able to eventually find my way around it and in some ways it was more intuitive than Quartus.

I see the pile of ideas they're trying to glue together. But it really just does get in the way more than anything else.

Now my process is: Verilator + CMake + CLion + SystemVerilog plugin for CLion (excellent but $$$); then when it runs well in verilator I bring it over to Vivado, fix any warnings it gripes about and try it on hardware.

And I've just discovered fusesoc and this is 50x better...

What amazes me is this, from Wikipedia:

"Replacing the 15 year old ISE with Vivado Design Suite took 1000 person-years and cost US $200 million.[12]"

Try inaccel.com

Can't agree more. We literally have a version controlled Windows image with Vivada just to be able to quickly restore it when it breaks.

We switched nearly all of our PCs to Linux, and it's ironic that it is our engineers' computers that still have to be on Windows because of Solidworks, MCU toolchains, Virtuoso and other semi tooling

The non-software engineering world is laughably behind the times when it comes to computer technology and software. SolidWorks is one of the defacto industry standard CAD packages, and their version control software essentially just creates copies of the files and increments the versions. There's no real concept of change management on the content level.

OpenSCAD is a nice example of how this kinda stuff can work. It's nowhere near viable as a general purpose CAD program, but the concept could easily scaled up to the level of SolidWorks.

Its file format works very well with version control systems, is human readable to an extent and can be opened with any text editor (so your data isn't 100% gone if one bit gets accidentally flipped).

It's worth pointing out that OpenSCAD was started by Clifford Wolf, who went on to develop Yosys, the synthesis tool used in these open FPGA workflows.

TIL!

Check out CadQuery. It's miles better then OpenSCAD.

Onshape (the complete CAD runs in a web browser) has built-in document management (version control, review, approval, sharing, ..).

I’ve used to do mechanical design with Pro/Engineer for several years. Now I occasionally do some mechanical design stuff in Onshape and all I can say is that this is a tool designed by elite mechanical engineers and developed by elite software engineers.

Regarding document management it is like going from assembly to some high level programming language.

The only downside could be that it cannot run on premise. Everything is in the cloud.

So I would not agree that non-software engineering is behind the times:-)

(I’m not affiliated with onshape)

update: Onshape was bought by PTC (the developer of Pro/Engineer). I hope they won’t screw it up:-|

The toolchain for ASIC/EDA in general is very poor. In 2019 I'm amazed that an open-source HDL simulator is not the de-facto industry standard. The big 3 EDA vendors charge astronomically high prices for simulator licenses, yet Verilog/VHDL along with simulator APIs (DPI/PLI) have been standardized for decades.

Verilator is gaining traction as the de-facto open-source simulator for industry and hobbyists. VCS is still the sign-off simulator, but at least there’s mounting pressure to support both.

In my day job as an FPGA developer I am using totally open source tools for simulation and verification (the only tool we pay for is Vivado but you have to pay for that in order to build for the FPGA). The simulator is icarus verilog and does the job pretty well. I use cocotb for simulation.

If you're using Intel's Quartus tool (Altera), pretty much every option is exposed through a Tcl API. You can accomplish everything without ever opening the GUI. The biggest problem is that those Tcl APIs are usually not documented very well...even for us internal developers (I used to develop Quartus)

The situation for Vivado (Xilinx) is more or less the same, Tcl for everything but terrible documentation.

Same for Lattice Diamond. Was nice for CI, but didn't help much with collaboration and merges for the reasons others have stated here.

Seems like every GUI based programming language I've worked with doesn't work well with version control. I get a dozen emails a day about someone locking/unlocking a file - if two people modify the file at the same time there is a merge conflict and no way to resolve the difference. Until git can merge two conflicting files in a sane way ("git mergetool" launching a custom merge GUI would be fine if it worked - I'm not locked into must be able to us vi to merge)

You can write a script (in Bash, Python, Go, whatever) that accepts the arguments passed by git (filenames for $BASE, $LOCAL, $REMOTE, and $MERGED)[1] and launches whatever diff tool you'd like to use. You can then tell git to use it by setting the merge.tool and merge.tool.cmd configuration variables.

If you want to invoke different tools for different types of files, you can either handle this in your script, or you can explicitly pass the --tool flag in cases where you want to use a non-default tool.

Writing the wrapper script is generally pretty straightforward - the only "gotchas" are making sure the file patterns can be handled by your merge tool, and making sure you write the result to $MERGED. Sometimes you need to have a "clean-up" step in your script that copies the merge tool output to $MERGED and maybe deletes tmp files that were created.

[1] https://git-scm.com/docs/git-mergetool

That doesn't help when the file is a binary and nobody has written a tool to merge it. How do you merge a picture?

You're not replying to me, but I imagine you'd decode both images to an uncompressed format and diff them visually, optionally with a way to highlight pixels that differ between the two.

Binary file types that you can't view in some way would be challenging.

JPEG doesn't really have pixels though, and with some modern formats it gets even worse. For netlists it's hopeless.

Unity3D works reasonably well with VCS when using Text format files, as an example of a GUI development environment.

Amen. I've been dabbling in the world of FPGA & hardware lately and I don't understand why hardware engineers tolerate the state of their toolsets.

Schematic design tools that make common tasks like drawing/connecting buses an obnoxious hassle involving futzing with the mouse making sure lines and nets line up when one should just be able to describe the whole thing in a DSL and have the tool build up an initial drawing for you.

FPGA "IDEs" with no auto indentation, refactoring/rename, no support for version control, arcane project structures that don't move easily between directory structures, non-modular tools that don't work well or at all outside of the IDE, critical settings buried in dialogs, 'drag and drop' authoring that takes you about 50% of the way to your solution and then falls over in a hot mess.

Demand better

Psst…I think you mean "silicon".

Haha indeed! I will leave it for traceability.

I had to apply some bathroom silicone sealant over the weekend so I just go ahead and blame it on that.

And we use silicone thermal paste on top of a piece of silicon ;-)

Nothing but the finest pulverized silver for me, thanks ;)

I removed those sticky e's from your fine comment above. I hope that's ok. It makes the discussion less distracting.

No problem at all, it is a relevant discussion but in a way I now feel I moved attention away from the intent of the OP which was to raise awareness and support for Symbiflow.

I've edited obvious typos in some comments. I can't seem to help it.

Psst...I think you mean "silicium" :P

(before any of you start typing your answers: that's the joke)

I always wonder why "silicium" is disused in favor of silicon, given that "-ium" is used liberally today, and you made me to look it up. Apparently, "-ium" is a suffix for metal only. But when naming new/hypothetical elements that have no standard name yet, IUPAC's Systematic Element Name rules overrides it and use "-ium" for all elements, but when the name is given, the usual rules apply.