This doesn't appear to support any FPGAs other than their FPGA chiplet [1]. Also, like UncleOxidant said, the most complex parts of this toolchain are just existing open-source tools (Yosys and VPR).
This seems like a useful toolchain for ZeroASIC customers who are using their hardware, but not for FPGA enthusiasts more broadly.
I think it supports whatever SiliconCompiler supports (which is both FPGA and different ASIC flows) and the EBRICK example is showing how to put that design onto an ASIC or FPGA for testing.
I use to say this whenever I see anything related to FPGA: the FPGA world needs it's equivalent to Arduino. Before the Arduino, the world of microcontrollers was dominated by bad proprietary tools; the FPGA world suffers of the same illness today.
We really need to fix this before FPGA's falls in the hands and hearts of any willing hobbyist.
That's what I used to believe and it's probably true, but I think it will not really happen. You just don't need FPGAs for most things. Especially if you just like to tinker around. I mean we have Microcontrollers running at 600MHz+. That's usually fast enough to get things sorted in software.
I do have hell of a lot fun designing my own CPUs and other hardware on FPGAs, but I've been doing this for a couple of years now and whenever I talk to someone who hasn't done any development in that direction yet, I often have to remind myself that hardware development is just a completely different mindset.
Yes, copy pasting a few logic gates into vhdl is easy, but I don't know how you would go on from that if you just want to have fun. Getting something done in hardware can be really frustrating sometimes. Maybe all the "new-age HDLs" might be a solution to this - i have to admit i haven't really tried them out yet.
Arduino is a nice, but it's still built on the shoulders of tools like GCC, isn't it?
I never owned a computer in the 90s, but my impression was that Cygnus[1] did a lot of work porting GCC and improving it for use in a variety of platforms, including embedded targets. They arguably helped pull GCC into mainstream usage, to the point of almost permanently forking it [2].
Those first 20 years of GCC development were prerequisites for something like Arduino to emerge in the mid-2000s. I'm just not sure we have the equivalent of GCC yet when it comes to synthesis tools.
When it appears, it might be a good opportunity to create a consulting company and drive it forward while also making some money. The key pitch would be improving your ability to maintain and share designs across targets while not having to pay recurring licenses on your tools.
People have been working on it for years, but it's a lot of work when the chip vendor isn't helping to make it happen. At this point it's more akin to building reverse-engineered GPU drivers like Panfrost and Nouveau than a platform like Arduino (where AVR was well-documented by Atmel and avr-gcc already existed).
Lattice Semiconductor's iCE40 sort of qualifies, no? (Maybe getting a little old now?) Cheap and fully supported by an open-source toolchain and really easy to use. (Unless a GUI is needed.)
iCE40 was a good start, but boards based around that family are getting hard to find. For those who are building their own PCB and want an FPGA on it with minimal fuss, the iCE40HX1K comes in a TQFP-144 package and is still readily available from the usual retailers for such things. Nice for hobby PCB makers, but not a current-day solution for easy FPGA projects for software devs.
IMO Sipeed Tang is the product most like Arduino for FPGAs: boards ready to program with a USB cable and a range of plug-in-and-go peripheral boards available. The Gowin IDE is free but not open, while the yosys+nextpnr open toolchain claims full support for the FPGAs on the Tang boards.
LiteX makes speccing out an FPGA core much more approachable for someone from a software development background, too, so LiteX plus a Tang Nano 20k and you can do all sorts of awesome things without too much trouble.
> while the yosys+nextpnr open toolchain claims full support for the FPGAs on the Tang boards
Citation needed. The GoWin FPGAs on these boards are still very much a work in progress. YRabbit is doing most of the reverse engineering on them, it seems, with the DSP blocks only implemented a couple weeks ago.
Project Apicula says "currently supported boards are ... [list of mostly Tang boards]" without qualification.
I wouldn't be surprised to discover that it actually is qualified support, though. Do you think the actual support is low enough that one should avoid those boards for now?
Whether there is enough for you right now depends on your needs, plus the knowledge that the support will continue to mature as time goes on. A good indicator of what you can do with the open source tools right now is checking out this link [0] at Lushaylabs. It has a fantastic series of practical hands on and useful articles like making your own CPU and driving HUB75 panels. Plus "This series uses a completely open source toolchain which makes development open / fast and lightweight". There is also /r/GowinFPGA on Reddit.
Regarding interesting boards with the ice40, I recently saw an ice40 development system that is integrated into a microSD card and can be programmed by plugging into your PC: https://news.ycombinator.com/item?id=39933917
Looks like you can then put the card into one of those microsd breakout boards and use it like a processor module.
Before you can have an arduino you need a gcc. Arduino itself was just a user-friendly wrapper over the existing work of making an open-source cross compiler for the platform.
The problem with FPGAs is they're inherently unfriendly to beginners. Thinking in HDL is a bit more difficult than a high level language like scratch or arduino c++. Plus the "compile times" are absurd so a beginner would probably lose patience.
LabVIEW has had FPGA programming as block diagrams for a good 15 years now. Vivado has something similar.
Programming FPGA as block diagrams is very natural, because you are essentially designing a circuit. So strictly speaking, you don't need to learn a HDL to do FPGA anymore
Theres the open source Digital (https://github.com/hneemann/Digital) which can run simulations but then export Verilog. If you have an ICE40 based GPU then in theory you can then use open source tools (like apio) to get that onto your FPGA. I've seen some impressive fpga tasks being generated by that.
I'm early in my learning of FPGA and have done nandgame and some other non-HDL circuit learnings. I have gone back and forth if I want to design my project via HDL or via something like Digital. There's not an easy pro/con either way.
For example, everything I've read is that the verilog block diagram tools kinda create isn't behavior, which makes optimization by FPGA compilers hard, because it can't automatically infer optimal feature gate usage if you are giving transistor level HDL vs behavior HDL. Likewise, it's not totally clear if block diagramming tools can facilitate test bench behavior, which I think I want to prevent regressions.
From what I remember a few projects attempted this.
Papillio [1] is one I remember in particular but that is partly because I backed the kickstarter for the Papillio Duo. Still have it and never had any time to really sit down and do stuff with it.
I also worked with a company that made a few of the "wings" for it early on.
Yosys and vpr is clearly doing the heavy lifting here...the novelty here is the fact that an FPGA startup is giving public access to the fpga pre production and is opening the bit stream format. This hasn't really been done before.
In computer programming, you can get say a ~10x speed improvement between writing bit twiddling code in python and hand writing SIMD assembly to do the same job.
Is there a similar gaping gap between writing verilog for something, vs hand-designing the lookup tables and laying out the FPGA routing?
Most FPGAs have various kinds of primitives that can be instantiated manually in the middle of a larger Verilog design. Sometimes those primitives can be used to do things that are very hard to make the synthesizer create automatically.
In general, the synthesizer will be better than you at anything lookup-table or flip-flop related. Ditto for simple primitives like shift-registers. But it probably doesn't know how to infer the more complicated primitives, and so those are usually done with the Verilog equivalent of inline assembly.
For a few tight designs, I've given some hints to the the placer. These are things like grouping components together, or setting location constraints on a few key primitives. That kind of thing isn't too uncommon. I've never seen anybody try to route things manually though.
Makefiles can work for simple builds. Logik being Python based can do so much more: automated metrics gathering, conditional flows, parallel execution, error handling, dependency management
This seems like a useful toolchain for ZeroASIC customers who are using their hardware, but not for FPGA enthusiasts more broadly.
[1]. https://www.zeroasic.com/chiplets/fpga