SymbiFlow: A FOSS Verilog-to-Bitstream FPGA synthesis flow for Various FPGAs | Hacker News Reader

SymbiFlow: A FOSS Verilog-to-Bitstream FPGA synthesis flow for Various FPGAs

symbiflow.github.io

Not too happy with the "will be" part, because these types of endeavors are really hard, and it's unclear what likelihood of success the project has.

But apart from that ... I really wish these guys will be successful.

The FPGA world sorely needs to open up.

My favorite analogy is that the FPGA world (and the ASIC design world in general) needs a project equivalent to LLVM: something that sorts out once and for all all the gnarly and nasty low-level stuff, offering a consistent high level view of hardware (a hard feat of course, given how different H/W might be from one vendor or chip gen to the next, but LLVM did pull it off) - even if it's not as optimal as coding down to the metal would be - and lets the rest of the world build amazing, high-level tech. on top of it.

As a matter of fact, I really wish they had a link on their page to tell people how the project can be helped.

That commoditizes the FPGA market. Which is great for consumers but the exact thing the manufacturers hate, because suddenly they have to compete on price because it's easier to switch tooling.

If Intel thought they could get away with requiring a licensed compiler for their processors, they would. GPUs are in the no-mans-land: somewhat portable shader languages, but the compiler targets are proprietary and rapidly shifting.

It's pretty obvious the manufacturers will try and get away with vendor lock-in for as long as they can.

NVidia has been playing that game with Cuda from day one, leaving OpenCL as a barely supported, barely usable, and complete no-no for anyone who wants to do production work with their hardware so they can avoid this very criticism.

The manufacturers are the villain in that story, and they know it.

This makes the kind of project described in the OP all the more important, and the folks who work on it should get help form anyone who uses FPGA's commercially.

I work with FPGAs commercially. Using non- supported tools isn't an option.

If you're building anything 'real', you're not going to try to save a few thousand dollars and risk the program, you just cost it in.

Yeah, I know, Synplify costs way more than that, it isn't exactly standard anymore (Xilinx' tools got good enough).

It's really not that expensive, considering the FPGA is usually critical system architecture.

I don't see Nvidia as the 'villain' in that story either - they designed the graphics chips, they designed Cuda. Nobody is forcing anyone to use either. They don't support the language you like? Use somebody else's chips. They can't support every language - I'm not upset they don't directly support Object Pascal.

The SymbiFlow project seems to have an "ideas" repository at https://github.com/SymbiFlow/ideas/issues

@mithro on twitter (https://twitter.com/mithro) sometimes posts requests for help like https://twitter.com/mithro/status/1018270467545706496 || https://twitter.com/mithro/status/1012113316385132545 || https://twitter.com/mithro/status/1010702164790874113

Maybe someone needs to help them do a better website!

The site is actually a bit out of date, the ECP5 bit (Project Trellis) and nextpnr are already working:

https://github.com/YosysHQ/nextpnr

I thought not all the blocks of the FPGA were available yet - block rams were just recently added, but I think some of their clocking tiles are not fully operational.

Could be outdated info though, if someone knows can you provide a link?

On of the developers of SymbiFlow gave a high level update at OrConf 2018 (https://orconf.org) recently. I believe it was recorded but haven't seen any info of when they will be published. You can find the slides at https://j.mp/orconf-symbiflow but it is a little cryptic without narration.

The guy working on the ECP5 stuff also gave an in-depth dive into how that part works but I can't find a link to his slides.

Are these projects characterizing the timing of these chips also? Or just stealing the timing data from the vendor tools?

Anyway this has famously been done in the past. A company called NeoCAD reverse engineered Xilinx FPGAs in the early 90s and produced place and route tools that produced better results than Xilinx's own tools. Xilinx eventually bought them, and their tools became the basis for Xilinx Foundation and ISE. NeoCAD also targeted AT&T's FPGAs, which eventually became Lattice FPGAs. You will still see some NeoCAD references in the Lattice Diamond tools command outputs...

Relevant USENET thread: https://groups.google.com/forum/#!topic/comp.arch.fpga/WwsoA...

(look for message from Eric Dellinger...)

(also, I miss USENET..)

A fascinating piece of computer history. Thank you for the post and the link. (I miss USENET too...)

You all surely must be aware of the only existing completely functioning FOSS FPGA toolchain, right?

http://www.clifford.at/icestorm/

and even featuring a gui app built on top of it! https://icestudio.readthedocs.io/en/latest/

Check out who's behind icestorm, and compare that with who's behind symbiflow.

Last bit from tfa:

"Project IceStorm

Project IceStorm is a previous project that documented the iCE40 bit-stream format. It will become a part of SymbiFlow. SymbiFlow will support the old Yosys-ArachnePnr-IceStorm flow but will also add a Yosys-VPR-IceStorm flow."

To me, the state of development of open source FPGA tools feels about like the GNU project in the late 1980s.

gcc 1.x and 2.x targeted several Unix platforms and produced working code some of the time. It would work with gas or the vendor's assembler and gld or the vendor's linker, depending on target. It almost always used the vendor's libc and other libraries.

GNU autotools didn't exist but every significant project had its own "configure && make && install" system that worked some of the time.

The vendors mostly ignored the project, though clueful engineers from vendors as well as customers were cheering it on.

I think it will not take Yosys/iCEstorm/SimbiFlow/whatever 20 years to take over the world this time around. At least I hope not.

It will take 4 years, in under 2 years, one of the FPGA vendors will support it directly.

I wonder, wouldn’t some of the Chinese fpga startups be more receptive to cooperate with an open source project?

The Eda industry is ripe for disruption, and it seems the incumbent Chinese semi players may become the catalyst. See also, how they embraced RISC-V.

i do not think the Chinese can understand the long term value of this open toolchain (as it will not make them sell MORE chips in the short term. that's IMHO their only expected ROI for any effort..). anyway i've recently got a nic(h)e board Lichee Tang (http://tang.lichee.pro/) sporting a "weird" Anlogic Eagle FPGA, that's also sold with a 1o1 "pin compatible feature" against similar parts from X & A(I) manufacturers. that's tells a lot about their marketing practices!

I once met people doing titan fpga, but since around half a year ago, the company went dark on the internets, so far, they were the one and only modern indigenous fpga co in China.

Reply on news.ycombinator.com