When you develop software, you need some kind of toolchain. For example, to develop for an ARM processor, you need a suitable C compiler, a linker, a library, and a programmer. FPGAs use a similar set of tools. However, instead of converting source code to machine language, these tools map the intent of your source code into configuration of FPGA elements and the connections between them.
There’s some variation, but the basic flow in an FPGA build is to use a synthesizer to convert Verilog or VHDL to a physical design. Then a mapper maps that design to the physical elements available on a particular FPGA. Finally, a place and route step determines how to put those elements in a way that they can be interconnected. The final step is to generate a bitstream the chip understands and somehow loading it to the chip (usually via JTAG or by programming a chip or an external EEPROM).
One problem with making your own tools is that the manufacturers typically hold the bitstream format and other essential details close to their chest. Of course, anything can be reverse engineered (with difficulty) and [James Bowman] was able to build a minimal CPU using an open source Lattice toolchain. The project relies on several open source projects, including IceStorm, which provides configuration tools for Lattice iCE40 FPGAs (there is a very inexpensive development platform available for this device).
We’ve covered IceStorm before. The IceStorm project provides three tools: one to produce the chip’s binary format from an ASCII representation (and the reverse conversion), a programmer for the iCEstick and HX8K development boards, and database that tells other open source tools about the device.
Those tools blend with other open source tools to form a complete toolchain–a great example of open source collaboration. Yosys does the synthesis (one of the tools available on the EDAPlayground site). The place and route is done by Arachne. The combined tools are now sufficient to build the J1A CPU and can even run a simple version of Forth. If you’ve ever wanted to play with an FPGA-based CPU design, you now have a $22 hardware option and free tools.
Perfect just when I was looking for a new simple FPGA board.
So,
is this a first?
A complete open-source tool chain for fpga?
Well the fpga mfgr now eol the device rather than let it be open?
I’m sure it will depend on the software patents and licensing involved. But if in the long run it helps them to get a much much larger market segment, I can’t imagine too many companies shooting themselves in the foot, unless they are legally bound…
For the xc6slx9:
https://github.com/Wolfgang-Spraul/fpgatools
http://vjordan.info/log/fpga/category/fpga.html (dynamic partial live reconfiguration)
I’m just sick and tired of running 2 versions of Quartus II and ISE( I have cyclone II, cyclone V, Max II, Spartan 3E, Spartan 6 boards). Luckily all my boards work with the free editions but I’d hate to have to add to the behemoths.
Yea this (supported/not supported) stuff is rubbish, do you want me to use your product or not? I’ve already written code to “blink an LED” with your lower tier FPGA, but I can’t bloody compile it on your nicer one?
I’m trying to give you(FPGA manufacturers) money but you aren’t making it easy!
Inter-compatibility between series is the best way to maintain a good user base, sparse selection of supported products without paying a premium for licensing isn’t going to help most places decide to adopt a better/newer FPGA. “This Verilog works great on the Spartan 3, lets get more speed and bump up to a Spartan 5! Oh it doesn’t compile with this license.. maybe we should try Lattice instead..
Wow, very impressive!
Poked at the IceStorm web-site. They added support for the iCE40 HX8K a few weeks ago. So now you can run 6x larger designs with the tools. Eagerly watching for further progress!
question: how fast is the compiler? How long did it take to compile the verilog code for this demo?
Compilation takes about 5 seconds.
It seems even faster than Diamond, and DIamond is fast :). I wonder how difficult it could be to port the fitter to the MachXO2,,,
The hard part is reverse engineering the MachXO2 bitstream.
How good is the placing system? it’s an NP complete problem, and I’m slightly afraid of what can be done by volunteers with this kind of software. But I think it could be good to have a portable toolchain, and a good IDE.
Personally that’s the least of my concerns, I’m more than happy to throw a few more bucks at better hardware if it means a total turnaround time measured in seconds rather than minutes. If the build+upload times really are as good as James is indicating then this is a very big deal indeed.
Placement current uses simulated annealing and I’ve started working on an analytic placer. SA seems to work well in practice for a chips of this size. IceStorm hasn’t documented the timing details, so right now a “good” placement is one that successfully routes. The J1a has nearly 100% utilization (1270 / 1280 LCs) but still routes. Give me a design that works with the Lattice tools but fails with arachne-pnr, and I’ll improve it.
Occasionally I needed to be reminded that there are in fact people smarter than me on this planet. You sir must surely be one of them. Simulated annealing for FPGA routing? Goddamn I wouldn’t know where to start.
By the way, if you want to buy the ICEStick — the shipping from Lattice is as much as the board. Search on any of the usual distributors to find it with reasonable shipping.
Very interesting video, but the typing noise made my ears hurt so much that it was hard to concentrate on what he was saying. It would be nice to have closed captions. :-)
Ordering through Lattice is “powered by mouser”. hint, hint
Needs some RISC-V .
Clifford already wrote one:
https://github.com/cliffordwolf/picorv32
there are build scripts for IceStorm in scripts/icestorm. It fits on an 8K.
I was beginning to get a general interest in Lattice hardware due to these open source tools. I downloaded their Linux development tools only to find out that it bases the licensing information on a fixed “eth0” card which doesn’t exist anymore on newer systems. I worked around the issue with some udev rules to rename the interface. I opened a ticket to lattice explaining the issue and the solution. A week later I got an email from an outsourced Indian support guy saying “We’ve detected your using a public email address” (it’s not, it’s my personal domain) ” I’ve closed this ticket. Please open a new support case with an email from a company”
Screw Lattice. Given responses like the one above, I really doubt they’ll give a shit about open source bitstream generators.
All of the FPGA companies are like that. Its an industry obsessed with DRM, IP and IP licensing, and unfortunately us mere hobbyists and hackers don’t fit into that world view. But thats why projects like the icestorm toolchaiin are so important because we can tell the manufacturers to just hand over the parts and go away.
Does anyone think its possible to decode and encode cvbs video signal with this board. To, for example, overlay graphics into a video stream. I am guessing this would need some additional D to A and A to D analogue for the signal?
4:30 onwards is just next level stuff… omg