Zero ASIC releases Wildebeest, the highest performance FPGA synthesis tool (opens in new tab)

> ... don't require absurdly bloated development environments.

Outside hobbies, I've been mostly away from this field for little over a decade by now. Is it still that bad? I remember back then, every single professional electronics engineer that I met had this die hard belief that this was simply how things work:

You want to use DerpSemi micro controllers? You must install DerpStudio '98! Not the later 2005 version tough, that has some major UI bugs. You want to program a HerpSoft PLC? You need EasyHerpes IDE! What, command line toolchain? Text editor? You must be completely insane!

It's been somewhat of a personal fight against windmills for me back then. That, plus suggesting that we are actually developing software and the C/Assembly/VHDL maybe shouldn't be an undocumented, tested-only-once pile of spaghetti based off a circuit diagram inside one guys head (and no, a 50 line comment block with a German transcription of the code below is not documentation).

As much as I wish this would come true, there's little chance for a full, end-to-end open source toolchain for Xilinx or Altera FPGAs that's competitive with the vendor tools. The reason for this is that there's no publicly available documentation of the signal routing configuration or the bitstream format, which are required for the final two steps in the chain. I don't see the two market leaders releasing this information anytime soon, and reverse engineering it from the data files is probably rather difficult.

The synthesis discussed in the linked page is one of the earliest steps, and from the point of view of open source implementations, the simplest one, because all necessary information is freely available.

Most FPGA vendor tools can be used from the console. But they are very fat.

The installation can be around 100GB, which is a lot, but you have to distinguish the build part from the IDE. I hardly ever use the IDE and just use a Makefile.

The open source tools still lack too many features to be useful for non-hobby development.

When you release something as open source, a third party grabbing it and releasing it is explicitly something that can be done.

I can't speak for them, so I'm not sure, but I feel like new FPGA suppliers coming around having open source tooling being the default is something that the authors of Yosys would like.

Zero ASIC even credited the original authors in the press release and released the source code, which they didn't need to do. If you release your code under a permissive license, like Yosys did, a company taking it and selling a closed source version of it is something you are allowing. If that's not something you want, choose a different license.

They seem to be making their own eFPGA architecture, so there's no vendor tool to compare against for their primary purpose.

The closest you'll get is xc7 (Xilinx) vs vendor, one of which is surely Xilinx 7. But the Yosys xc7 support is limited and not the best supported, so it's not a great comparison either.

Yeah, this was a big dilemman You can't compare two different compilers for two different hw targets. That would be like benchmarking GCC compiling to ARM with LLVM compiling to x86.

Thierry's synthesis scripts are really very clever, and the go way beyond our Platypus FPGA arch. We are realistic that until we have seilicon nobody cares about our arch. Releasing the work as open source, we think someone should adapt the code for all of the other targes I Yosys (xilinx, lattice...etc) so that everyone can benefit.

We contribute a lot of code to open source, but as an FPGA vendor we are not going to spend time/money optimizing compilers for our competitors:-)

Not just that, their device "z1060" doesn't exist outside this blog post. We literally don't know what it is.

Yosys supports Python scripting.

I expect my synthesis tools to consume text and output a netlist and to be able to do that in regression with a Makefile. Is that eighties? Synopsys DC does it, so does Vivado and Quartus and any other synthesis tool, including Yosys.

Often but not always. For most newer FPGAs, routing is the main source of delay on the critical path, not logic. So if the synthesis tool lowers the logic depth, but does so in a way that increases the distance the signal must travel on the chip, it likely won't help FMax.

This can be caused by increased logic usage, if the synthesis tool must create significantly more LUTs to reduce the critical path. This may make it harder to place the logic on the critical path close together, increasing the routing delay.

Additionally, if the synthesis tool replaces something with a dedicated routing path (most FPGAs have dedicated routing for carries, some may have dedicated routing for local connections in a CLB or between CLBs). These dedicated routing connections usually have a lower delay than the general purpose routing network, potentially increasing delay

The figures they have listed look promising though, they're lower or comparable to the commercial tools in terms of resource usage, with lower or comparable logic depths. They do however not have support for things like carry chains, which may potentially make some things like adders slower than the other tools.