The best part of open-source synthesis tools is that they don't require absurdly bloated development environments. The only thing I've encountered that's worse is Android Studio.
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.
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.
I don't understand the table under Benchmark Results. To compare the quality of two toolchains, the device architecture needs to be the same. "LUT6" vs "LUT4" doesn't cut it, there's much, much more to the architecture of an FPGA than the width of its look-up tables [1], and even for the "LUT6" category, I see four different devices.
[1] Consequently, there's more to FPGA synthesis than LUT mapping, so take the reported results with a huge grain of salt.
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:-)
This is not a separate synthesis tool. This is just a yosys plugin and only works for their own FPGAs. Kind of leaves a bad taste in my mount that they choose to advertise this as their own synthesis tool when it isn't. I'm curious why they didn't work together with upstream.
Also looking to their full stack it seem they use VPR/VTR instead of nextpnr for routing. That seems like a backwards choice.
When I looked into Yosys it very much seemed like a tool from the 80s that you pretty much had to be a Yosys developer to use. It still uses TCL scripting (which I know is standard in EDA but it shouldn't be).
I didn't realize that Xilinx xc7 synthesis was officially a feature of Yosys already!
Dropping the logic depth for picorv32 on LUT6s from 17 to 6 seems like it will double the achievable frequency or more. It's especially impressive that this beats the vendor tools—but it's unclear to me if this is an apples-to-apples comparison.
13 comments
[ 2.8 ms ] story [ 36.0 ms ] threadGetting more efficient output is a nice bonus.
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.
The open source tools still lack too many features to be useful for non-hobby development.
[1] Consequently, there's more to FPGA synthesis than LUT mapping, so take the reported results with a huge grain of salt.
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:-)
Also looking to their full stack it seem they use VPR/VTR instead of nextpnr for routing. That seems like a backwards choice.
https://github.com/YosysHQ/yosys?tab=readme-ov-file#getting-...
I wish we had a modern easy-to-use solution.
For anyone else who was wondering, it says it's under the Apache 2.0 license: https://github.com/zeroasiccorp/wildebeest?tab=Apache-2.0-1-...
I didn't realize that Xilinx xc7 synthesis was officially a feature of Yosys already!
Dropping the logic depth for picorv32 on LUT6s from 17 to 6 seems like it will double the achievable frequency or more. It's especially impressive that this beats the vendor tools—but it's unclear to me if this is an apples-to-apples comparison.