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.
> ... 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).
It's not that the official tools are the only way to work with parts.
It's that they're the only vendor supported method of working with the parts. If you build your product with an unsupported toolset and something doesn't work, you need to be prepared to reproduce the issue in the vendor support toolchain if you want support.
People coming from desktop and mobile development roll their eyes at this because they aren't coming across bugs in their x86-64 process or M1 Silicon that haven't already been patched over by some combination of microcode, the OS, and the toolchain. Everything works as expected.
Not so in the world of embedded. On modern complex systems, vendor involvement can be a critical part of the development process. Many of the products you have in your house like your router, Wifi gear, and IoT devices were probably co-developed to some degree with the hardware vendor. Starting with the vendor-provided reference design gets you to market much faster, even though you often could forge your own path with a separate toolchain and start from scratch.
It's still this way even in MCU development. You can go out and develop something like an STM32 system completely without STMicro's tools, but it's much easier to start the project in STMicro's tools and copy over the parts you need for setting up everything from clocks to peripherals, then to maintain a skeleton project in the official tools in case your separate toolchain starts acting funny.
Working now with some advanced devices from Xilinx (using very expensive top-line SoC. If you change version of the Vivado tools, you have to basically start again from 0 your project. Is a complicated mess because of matching of the OS in the ARM controller and the FPGA part…
I have dedicated a large chunk of my (arguably short) professional career on improving upon this, mostly in the safety critical software domain. What was your experience back then, what made you leave ultimately, and what do you do now?
Now that's funny. The irony here is that, besides German (native), I do speak some HSK4-ish Mandarin as a 3rd language. A few years ago, a single line Chinese comment next to a blob of magic hex values did help me figure out a bug in a touch controller driver :-)
One thing I will say in favour of the Gowin IDE - it does seem to be much more lightweight than the larger vendors' tools. For smaller designs it will often go from zero to bitstream in less time than Quartus or Vivado would have taken to even start synthesizing.
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 I see this, I suspect the vendor is operating under conditions that approach absolute chaos: dumping whatever junk someone imagines might be necessary into the stack with zero resistance, for years on end. Zero effort spent on any factoring that might threaten redundancy.
I'm not saying the tools aren't bloated, but I believe that a lot of the size (sorry, can't quantify right now) are the datasets for each and every FPGA model that the tool supports. This includes, among other things, timing information for every wire in the chip. You really only need the files for the device that you are targeting and you do have the option to install only that, or you can install larger groups (e.g. same family, same generation), all the way up to installing every device that ever existed that the tool supports. That's how you get to hundreds of GB.
Are you sure about that, or is it just a guess? If that is the case, how will the open source toolchains avoid the same problem when they eventually become the industry standard? (I can imagine something like a software repository for serving device-specific information on demand.) Are they planning anything right now?
Xilinx toolchain installations used to include a file which was just the concatenation of the license files of every single open source library they were using somewhere inside any of their own software. Now if you installed two or more components of their toolchain (for example, Vivado, Vitis, and PetaLinux) into the shared installation directory, this same file was installed several times as well. Together, they made up something like 1.5 GiB alone.
Welcome to modern development lol. Try to refactor it and get an answer of "no money for testing".
On top of that, the "agile" mindset all too often also means there is no coherent vision where the project should go, which can and does lead to bad fundamental architecture decisions that need extensive and expensive workarounds later on.
And yes, there have been people describing exactly that in ASML [1], although the situation seems to have improved [2].
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 reverse engineering efforts are impressive (though as I understand it, limited to Xilinx series 7 and Cyclone V) but without robust and reliable timing data to go with the rest of the chip data, they can't give you the same level of confidence that a design will work across a range of a devices and operating conditions.
For the curious: the process of discovering the logic and route timings for an FPGA device is to use ring oscillators (three series inverters) and compare counters against a known clock. Place the inverters all over to test every LUT, and use every routing path to test each path's timing.
> Both of things either have already been reverse-engineered, or are in the process of being reverse-engineered.
Please provide a source for this claim. Yosys, for example, can't route [1] designs even for Xilinx 7-series devices, and that architecture has been introduced 15 years ago.
[1] Not to be confused with synthesis, mapping, or placing, all of which come earlier in the flow, and for all of which sufficient information is public available.
Yosys doesn't do place-and-route - typically that part would be handled by nextpnr, and there's an experimental fork of that for Xilinx series 7 devices:
https://github.com/openXC7/ (full toolchain)
It works well enough to build a working litex RISC-V SOC capable of running Linux, for the QMTech Kintex-7 325T board.
I don't think the Cyclone V project has got as far, but I could be wrong. (It kind of slipped off my radar after I realised I was spending way too much time on Discord and purged all but a very few servers to reduce my distractions.)
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.
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 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.
There is obviously a difference between legality and what I would consider good behavior. I didn't say what they are doing is illegal. I just said it leaves a bad taste in my mouth.
In essence this is something like 99% yosys + 1% their own sauce. Yet they market it as 99% their own sauce + 1% yosys.
I think we're reading the same article differently.
They start out by describing all the work that has been done by other people to make open source synthesis possible.
Then they say they've added some well known, industry standard optimizations to the existing open source tools. In addition, they made use of the abc tool in a way that maybe wasn't being done much before.
My view is that if you think someone taking your software, changing some parts, and releasing it under a different name (while still giving you credit in an about section) leaves a bad taste in your mouth, don't release your software with a permissive license. You are explicitly giving permission for someone to do this.
I don't like companies doing this, so I tend to release under GPL. Even then, I'm happy for someone to rebrand and sell it, as long as the source is still shared. I gave them permission to do that.
Don't give someone permission to do something, and then say it's in bad taste when they do that thing.
I am sorry you that's how it looks...can't argue with feelings, We did everything we could to give credit. Open source SW should be a stack and every project needs a proper name as a reference. I do find the statement a bit ironic though, b/c 99% of Yosys users don't know that 99% of the logic synthesis sauce in Yosys is done by ABC.
I think most people who seriously use Yosys already know that ABC is the foundation it’s built on. But let’s be real, this plugin is just twelve C++ source files. Calling that a “synthesis suite” just isn’t accurate. What it actually does is build on the synthesis suite provided by Yosys (and indirectly ABC), adding some extra algorithms and support for your FPGA family.
That said, this work is important, you do need it to get your FPGA running. And from the table, the reported optimizations look good (though I haven’t dug into them in detail). Still, describing it as “a synthesis suite” when it’s really “a plugin that adds FPGA support and a few optimizations to Yosys” does indeed leave me with a bad taste in my mouth.
Of course, you don’t have to agree with me. It’s clear from other comments that not everyone does, and that’s totally fine.
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.
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:-)
They’re showcasing their open-source stack, built on existing tools, for their own FPGA.
Imagine if, 25 years ago, a company had designed a new CPU ISA and core and, as part of the development process, ported GCC and done a nice job
tuning the existing optimization passes, with the intention of the GCC port being the primary toolchain that commercial users would use. They could write a blog post about it, and it would have been great. Maybe they even would have acknowledged in the blog post that the stack included binutils :)
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 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.
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.
Getting more efficient output is a nice bonus.
> ... 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).
It's not that the official tools are the only way to work with parts.
It's that they're the only vendor supported method of working with the parts. If you build your product with an unsupported toolset and something doesn't work, you need to be prepared to reproduce the issue in the vendor support toolchain if you want support.
People coming from desktop and mobile development roll their eyes at this because they aren't coming across bugs in their x86-64 process or M1 Silicon that haven't already been patched over by some combination of microcode, the OS, and the toolchain. Everything works as expected.
Not so in the world of embedded. On modern complex systems, vendor involvement can be a critical part of the development process. Many of the products you have in your house like your router, Wifi gear, and IoT devices were probably co-developed to some degree with the hardware vendor. Starting with the vendor-provided reference design gets you to market much faster, even though you often could forge your own path with a separate toolchain and start from scratch.
It's still this way even in MCU development. You can go out and develop something like an STM32 system completely without STMicro's tools, but it's much easier to start the project in STMicro's tools and copy over the parts you need for setting up everything from clocks to peripherals, then to maintain a skeleton project in the official tools in case your separate toolchain starts acting funny.
> Is it still that bad?
IMHO yes, if not worse.
Working now with some advanced devices from Xilinx (using very expensive top-line SoC. If you change version of the Vivado tools, you have to basically start again from 0 your project. Is a complicated mess because of matching of the OS in the ARM controller and the FPGA part…
It's much better in microcontrollers. Almost everything can now be handled with VSCode and some open source compiler toolchains.
PLCs and FPGAs are still pretty damn bad though.
I have dedicated a large chunk of my (arguably short) professional career on improving upon this, mostly in the safety critical software domain. What was your experience back then, what made you leave ultimately, and what do you do now?
> and no, a 50 line comment block with a German transcription of the code below is not documentation
You had it good back then. Now it's a one-line comment in Chinese. Line is 300 characters wide. /Yorkshire men skit.
Now that's funny. The irony here is that, besides German (native), I do speak some HSK4-ish Mandarin as a 3rd language. A few years ago, a single line Chinese comment next to a blob of magic hex values did help me figure out a bug in a touch controller driver :-)
One thing I will say in favour of the Gowin IDE - it does seem to be much more lightweight than the larger vendors' tools. For smaller designs it will often go from zero to bitstream in less time than Quartus or Vivado would have taken to even start synthesizing.
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.
Most FPGA vendor tools can be used from the console. But they are very fat.
I know of a few vendor tools whose application size is measured in the multi-hundred of GBs
How does that happen?
When I see this, I suspect the vendor is operating under conditions that approach absolute chaos: dumping whatever junk someone imagines might be necessary into the stack with zero resistance, for years on end. Zero effort spent on any factoring that might threaten redundancy.
I'm not saying the tools aren't bloated, but I believe that a lot of the size (sorry, can't quantify right now) are the datasets for each and every FPGA model that the tool supports. This includes, among other things, timing information for every wire in the chip. You really only need the files for the device that you are targeting and you do have the option to install only that, or you can install larger groups (e.g. same family, same generation), all the way up to installing every device that ever existed that the tool supports. That's how you get to hundreds of GB.
Are you sure about that, or is it just a guess? If that is the case, how will the open source toolchains avoid the same problem when they eventually become the industry standard? (I can imagine something like a software repository for serving device-specific information on demand.) Are they planning anything right now?
Xilinx toolchain installations used to include a file which was just the concatenation of the license files of every single open source library they were using somewhere inside any of their own software. Now if you installed two or more components of their toolchain (for example, Vivado, Vitis, and PetaLinux) into the shared installation directory, this same file was installed several times as well. Together, they made up something like 1.5 GiB alone.
I think they've fixed this only a year ago or so.
Seems a good candidate for a file that can be kept in a compressed form
Welcome to modern development lol. Try to refactor it and get an answer of "no money for testing".
On top of that, the "agile" mindset all too often also means there is no coherent vision where the project should go, which can and does lead to bad fundamental architecture decisions that need extensive and expensive workarounds later on.
And yes, there have been people describing exactly that in ASML [1], although the situation seems to have improved [2].
[1] https://news.ycombinator.com/item?id=23363938
[2] https://news.ycombinator.com/item?id=39465412
Xilinx and Altera want to talk to you :-)
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.
"there's no publicly available documentation of the signal routing configuration or the bitstream format"
Both of things either have already been reverse-engineered, or are in the process of being reverse-engineered.
The reverse engineering efforts are impressive (though as I understand it, limited to Xilinx series 7 and Cyclone V) but without robust and reliable timing data to go with the rest of the chip data, they can't give you the same level of confidence that a design will work across a range of a devices and operating conditions.
For the curious: the process of discovering the logic and route timings for an FPGA device is to use ring oscillators (three series inverters) and compare counters against a known clock. Place the inverters all over to test every LUT, and use every routing path to test each path's timing.
> Both of things either have already been reverse-engineered, or are in the process of being reverse-engineered.
Please provide a source for this claim. Yosys, for example, can't route [1] designs even for Xilinx 7-series devices, and that architecture has been introduced 15 years ago.
[1] Not to be confused with synthesis, mapping, or placing, all of which come earlier in the flow, and for all of which sufficient information is public available.
Yosys doesn't do place-and-route - typically that part would be handled by nextpnr, and there's an experimental fork of that for Xilinx series 7 devices: https://github.com/openXC7/ (full toolchain)
It works well enough to build a working litex RISC-V SOC capable of running Linux, for the QMTech Kintex-7 325T board.
I don't think the Cyclone V project has got as far, but I could be wrong. (It kind of slipped off my radar after I realised I was spending way too much time on Discord and purged all but a very few servers to reduce my distractions.)
This sounds exciting, and the press release does a great job of explaining why.
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.
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 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.
There is obviously a difference between legality and what I would consider good behavior. I didn't say what they are doing is illegal. I just said it leaves a bad taste in my mouth.
In essence this is something like 99% yosys + 1% their own sauce. Yet they market it as 99% their own sauce + 1% yosys.
I think we're reading the same article differently.
They start out by describing all the work that has been done by other people to make open source synthesis possible.
Then they say they've added some well known, industry standard optimizations to the existing open source tools. In addition, they made use of the abc tool in a way that maybe wasn't being done much before.
My view is that if you think someone taking your software, changing some parts, and releasing it under a different name (while still giving you credit in an about section) leaves a bad taste in your mouth, don't release your software with a permissive license. You are explicitly giving permission for someone to do this.
I don't like companies doing this, so I tend to release under GPL. Even then, I'm happy for someone to rebrand and sell it, as long as the source is still shared. I gave them permission to do that.
Don't give someone permission to do something, and then say it's in bad taste when they do that thing.
Exactly. “You did what? You complied with my license terms?!?! How dare you!”
I am sorry you that's how it looks...can't argue with feelings, We did everything we could to give credit. Open source SW should be a stack and every project needs a proper name as a reference. I do find the statement a bit ironic though, b/c 99% of Yosys users don't know that 99% of the logic synthesis sauce in Yosys is done by ABC.
https://github.com/zeroasiccorp/wildebeest
I think most people who seriously use Yosys already know that ABC is the foundation it’s built on. But let’s be real, this plugin is just twelve C++ source files. Calling that a “synthesis suite” just isn’t accurate. What it actually does is build on the synthesis suite provided by Yosys (and indirectly ABC), adding some extra algorithms and support for your FPGA family.
That said, this work is important, you do need it to get your FPGA running. And from the table, the reported optimizations look good (though I haven’t dug into them in detail). Still, describing it as “a synthesis suite” when it’s really “a plugin that adds FPGA support and a few optimizations to Yosys” does indeed leave me with a bad taste in my mouth.
Of course, you don’t have to agree with me. It’s clear from other comments that not everyone does, and that’s totally fine.
Not to be confused with GNU, the free operating system.
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.
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.
Documentation can be found in two places. What else do you need to know?
https://github.com/siliconcompiler/logiklib/tree/main/logikl...
https://github.com/zeroasiccorp/wildebeest/tree/main/archite...
ah so this is misdirection - what they are really showcasing is their own new FPGA asic
They’re showcasing their open-source stack, built on existing tools, for their own FPGA.
Imagine if, 25 years ago, a company had designed a new CPU ISA and core and, as part of the development process, ported GCC and done a nice job tuning the existing optimization passes, with the intention of the GCC port being the primary toolchain that commercial users would use. They could write a blog post about it, and it would have been great. Maybe they even would have acknowledged in the blog post that the stack included binutils :)
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).
https://github.com/YosysHQ/yosys?tab=readme-ov-file#getting-...
I wish we had a modern easy-to-use solution.
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.
will a smaller synthesis LUTs/logic depth result translate into smaller Map/P&R and higher fMax or not necessarily?
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.