Anyone who’s ever had the pleasure of programming FPGAs knows that it’s a land of proprietary tools that almost require marriage level commitment to a specific platform to be effective. Symbiflow hopes to solve this by becoming the GCC of FPGAs.
Rather than a tool built around a specific chip or architecture, Symbiflow will provide a more universal interface. Users can program in Verilog; architecture definitions define how the code will be compiled for the right chip. They are currently targeting the popular Xilinx 7-series, the very affordable iCE40 series from lattice, and the ECP5 FPGAs also from Lattice.
If you’re headed to Hackaday Supercon this year, [Timothy Ansell] will be giving a talk on how Symbiflow is making this process much more approachable and much less proprietary. Overall we’re very excited about a common interface, especially as the price of FPGAs keep dropping into micro controller territory while also increasing in capability.
(Speaking of Supercon, and maybe this is a spoiler, the badge would not have been possible without Symbiflow, Project Trellis, Yosys, and NextPNR.)
Having looked at making some FPGA projects myself, I do have to agree that “it’s a land of proprietary tools that almost require marriage level commitment to a specific platform to be effective.” is a fairly good description of the experience.
Would be nice to have a free, easily downloadable, semi decent piece of software that opens up the door to CPLDs and FPGAs without all the hazzle of export restricted software, crude logins to companies with questionable terms of services for just signing an account, etc.
Though, considering how varied FPGAs and CPLDs can be in their implementations, it would probably be semi hard to make a tool chain that has a unified development process for all types of programmable devices from all different manufacturers.
But well, I won’t complain if it can at least do a semi reasonable job at it.
Hopefully it has a schematics mode where one can lay things out as logical blocks, after all, Dyslexia and text walls don’t play well with each other… (And using schematics and logical blocks/nodes is just as capable as text if one implements it correctly. Even parametric design isn’t all that hard to implement for node based programming, not to mention that one can overview a more complicated design more easily.)
Though, would also be nice to have an option for hand routing the logic fabric oneself. (Not saying that this is a recommended, nor efficient way of doing things, it is a bit like programming in machine code, it isn’t optimal, but sometimes, one can make things more efficient then a compiler could since one knows what one wants to prioritize, instead of fiddling with the compiler settings for weeks….)
In the end, it could potentially be something worth taking a look at.
“it is a bit like programming in machine code, it isn’t optimal, but sometimes, one can make things more efficient then a compiler could since one knows what one wants to prioritize”
Don’t say things like that. You’ll have the Anti Assembler Society’s(tm) minions after you.
And don’t say it’s true either, that what makes it worse.
:)
Well, machine code at times even gets lynched by the assembler folks, so I guess I have two societies to avoid in that case.
Anti Assembler Society…. that assembles really nice acronym :D. You made my day, sir (tips a hat).
By the looks of it Symbolflow is hardly ready for prime time. It’s just a collection of files at this point in time. Definitely not usable. Maybe in a year or two they might have something or not.
I’ll stick with Quartus and Aldec until then.
While thats very harsh; i do have tot agree a lottle. A lot of worm needs tot be done. The again maybe the worm that needs tot be done is more on the underlaying items …
Will follow thuis very closly
Quartus is afterall just a text editor with some buttons that let you control the compiler… and a few other GUI utilities.
Symbiflow doesn’t have the GUI but it does give you most of everything else… so saying it is just a collection of files is frankly stupid. It might not be for you but that doesn’t make what you said right.
Open source tooling is nice and all but if it doesn’t support what I already have with the free versions of Vivado and Quartus I’ll pass. No VHDL support is a show-stopper for me. Can’t stand Verilog. I know Verilog well enough, just don’t like it. Also for less than trivial designs a lot time is spent in tuning clocks to meet timing requirements and pin planning.
Just for the record, Verilog/VHDL is not programming in the traditional sense, it’s a description of hardware. C/JAVA whatever get compiled or interpreted into instructions that run on a CPU the concepts are completely different and require a different mindset.
The TL;DR part:
I’ve been jumping in and out of FPGA as a hobby for about 10 years now. Started off with Xilinx and now working with Intel/Altera. As far as the tooling is concerned the free versions of Vivado (and ISE) on Xilinx and Quartus on Intel are pretty much clones of each other. Yes the initial learning curve is very steep but jumping from Vivado to Quartus was a day or two at most. They are just that similar (convergent evolution). I suppose for the JAVA folks to put this in context it’s like moving between Eclipse and IntelliJ. Also VHDL and/or Verilog will port across effortlessly as long as it’s reasonably vanilla. But even if you are using proprietary IP like AXI bus versus Avalon it’s really not that hard to port.
Sure, the underlying bitstream format is vendor tied and proprietary so you have to use that vendor’s toolchain. Would be nice if there was a GCC like toolchain where I could point my VHDL project to an Intel Cyclone IV or a Xilinx Zynq for example and it works (of course there are chip specific pin assignments and clock constraints that need to be dealt with).
As for a schematic mode I used it at first but then quickly soured on it because it was hard to maintain. Once I understood that designing hardware with Verilog or VHDL is a matter of recognizing bits of code has hardware templates it became easier to rationalize and scale. Couldn’t imagine designing something as simple as a UART with a schematic capture tool as opposed to just coding up a state machine in VHDL. The latter, seems so much easier.
It supports SystemVerilog fully from what I remember so… that makes it more usable that plain Verilog at least.
This is a very nice project but I don’t believe it can’t be successful without some level of support from the FPGA vendors. When running the LOGI project, we had a few talk with Xilinx because they where failing at building a user community. We proposed and prototyped an a graphical HDL tool using synthesis in the cloud with Xilinx tools. They refused to move forward because they refuse to support initiative that could harm their reputation if not working well.
Several challenges here, nothing that can’t be overcome in principle, but it won’t be quick. Modern FPGAs are complicated. They have a large variety of specialized IP blocks. Occasionally, there are hardware tuning parameters or defects that are worked around in software. For example, start-up sequences for high-speed transceivers or routing resources that might under specific circumstances cause cross-talk. The vendor can make the tools to do the right thing and avoid problems, but without expensive testing, an open source project will have a hard time discovering and reverse engineering this. The value proposition of FPGAs is heavily dependent on proprietary and often expensive libraries. Maybe their thinking has changed in the last decade, but FPGA vendors used to be quite hostile to reverse engineering of their configuration bitstreams. Legal challenges are definitely a possibility.
Yeah, they are doing it though, ECP5 is a fairly complex FPGA and they are making good progress there. ICE40 and ICE40Ultra are relatively simple FPGAs and were a good starting point though.