Until a few years ago, developing for FPGAs required the use of proprietary locked-down tools, but in the last few years, the closed-source dam has burst, and open-source FPGA tools such as Yosys, SimbiFlow, and Icestorm have come flooding out. Setting up a build environment for these exciting new tools can still be quite a challenge, but [Carlos Eduardo] has decided to make setting up an open-source toolchain for Xilinx FPGAs a breeze with Docker.
His image only has three prerequisites: Docker, Python 3, and OpenOCD (which is used to load your FPGA with your bespoke bitfile). After the Docker image has been built and all of the tools installed, [Carlos] guides you through using Python, FuseSoc, and SymbiFlow to build your first open-source Xilinx FPGA project.
In addition to making setup a whole lot easier, utilizing containers allows the same development environment to be built on Linux, Mac, and Windows (using WSL), which will make life a lot easier for teams working across different OSs. [Carlos’s] Dockerfile is unique because it supports the popular Artix-7 series of FPGAs — for the Lattice FPGAs that have been supported for a lot longer, there are existing Docker files already up on DockerHub. It’s easier than installing the vendor’s toolchain!
If this has you thinking it might be time to dip your toes into open-source FPGA development, check out this rundown of open-source FPGA tools from the 2019 Superconference.
Here is another one (it’s only ~1GB) that includes support for ICE40 and ECP5 and formal verification open source tools https://github.com/vmunoz82/eda_tools
Hi Victor! Are you aware of https://hdl.github.io/containers/ ? It’d be nice to collaborate for adding the tools/projects that you might miss in the ecosystem.
Very slick docker solution, =)
I used the qemu/kvm cow session snapshot for frozen build environments, and pass in the host machines usb device to the VM (along with a samba NFS binding for the slow build path). For some vendors, they still only support win10 based builds.
#Something like:
devInfo=$( lsusb | grep -oE “^Bus.*ID 1209:2101.*InterBiometrics” )
BusID=$( echo “$devInfo” | cut -d’ ‘ -f2 | sed ‘s/[^0-9]//g’ | grep -o ‘[^0].*’ )
DeviceID=$( echo “$devInfo” | cut -d’ ‘ -f4 | sed ‘s/[^0-9]//g’ | grep -o ‘[^0].*’ )
serialDevFlags=””
if [ ! “$BusID” = “” ] && [ ! “$DeviceID” = “” ]
then
serialDevFlags=” -usb -device usb-host,hostbus=$BusID,hostaddr=$DeviceID ”
fi
at the risk of exposing my own ignorance :)
docker sucks. it requires root, and any user who can control docker can easily get root. its interactions with the network stack are complicated and opaque and tend to break other scripts. its main select() loop actively polls, consuming CPU when nothing is happening!
it’s also really slick at a lot of things, naturally, and has many features i don’t need/want but which are undeniably cool.
i switched from docker to lxc a few months ago and every weakness of docker is a strength of lxc. true non-privileged containers, obvious and simple network functioning, and (i can’t believe this is differentiating) a select() loop that actually waits for something to happen. and it was fairly easy to transition from docker, since my Dockerfiles were just a list of packages to install..
just, you know, my sixth of a bit.
> it requires root
Wrong… you need to be a member of the “docker” group.
sure, but all the other concerns apply:
me@localhost:~ $ docker run -v /tmp:/host-tmp –rm -it ubuntu:20.04
root@43a60583eb08:/# touch /host-tmp/hi_there_i_am_root.txt
root@43a60583eb08:/# exit
me@localhost:~ $ ls -al /tmp/hi_there_i_am_root.txt
-rw-r–r– 1 root root 0 May 5 19:21 /tmp/hi_there_i_am_root.txt
every member of the docker group can get host root trivially
Docker + Docker-Hub, LXC + LXD, Jail + Warden, rkt, etc., etc… All have their varying strengths and weaknesses. Like having a good set of hand tools, it’s good to have all of them to pick & choose from.
Only Sith deal in absolutes :)
Greg, I believe you are shooting the wrong bird here! You don’t like Docker, that’s ok. This is about containers with EDA tooling. Don’t use Docker if you don’t want to; pick the engine you most like. Use podman, or lxc, or kata-containers, or convert the container to a QEMU disk, or take the instructions in the dockerfile and run them natively, or use a virtual machine through VirtualBox. All of that is absolutely up to you!
This post is about a technical demo that showcases how one can build a complete solution for FPGA (and ASIC) design using open source tooling only, which can target Xilinx’s 7 series devices. I believe that this specific set of tools had not been packaged together before.
OpenVZ (lxc) is still popular, and Docker isn’t for every use case (RancherVM is pretty cool though).
Also, the KVM linux guests I use for xilinx builds run minimal virtualization kernels, and that configuration generally prevents a guest instance from excessive resource use.
But you are correct, in that host permission hierarchy quickly falls apart if one needs CUDA/GPU access in a Docker guest. That may have changed recently, but I doubt it given nVidias shenanigans over the years.
;-)
I wish there is an opensource alternative for oldskool cplds like xc95xl.
I use these cplds for connecting 5v logic on old computer like c64 and amiga. Xilinx is supplying a virtual machine with the old tools, but that is running an ancient OS, however the tools to program the cpld are either using a parallel port or a special Xilinx cable. I found a sullotion to program them using a generic ft2232 cable, but that doesn’t run (or can’t be compiled on/for the xilinx virtual machine).
Gigabytes of framework just to develop kilobytes of code, sounds like a sin.
Well, fpga stuff is notoriously complex: it’s code that makes a temporary custom IC, so I think we can probably excuse it. Unless you want to code your FPGA in raw LUTs and do your place and route by hand…
But once you’ve installed the toolchain, you can develop those kilobytes for the rest of your life. You could write petabytes of Verilog for all I know!
Interesting… I’m still waiting for somebody to get good Spartan 6 support so I can try some custom bitstream on my old school OSVR HDK 1.x, which has one with some sdram in the display path between the HDMI receiver and the MIPI transmitter. (It was used to perform image rotation as well as image cloning.) Not sure what I’d actually put on it, but it’s the closest I have to an fpga dev board until my Glasgow gets here later this month hopefully.
I can appreciate the work and skill that goes in to the open fpga tool chains but this seems like an extreme amount of cruft to avoid installing the free tool chain from xilinx. Are the oss tools that annoying to work with?
Granted, I’ve done similar things for LAMP dev but the altera/xilinx/efino/microsemi tools are all free, easy to install, and awesome to use.
Depends what you mean by ‘free’. some need license files with fixed mac address which is a pain to use freely, also you need to register account with them and agree to lot of stuff including not reverse engineer their hw of file formats, not free at all in my book
For most of us who have been down this path thousands of times, it is installing random tools & dependencies directly on a system that is the true cruft.
Theoretically, various toolchains of multiple versions will coexist peacefully on the same install, and clean up easily when you want to remove them. In reality, we have failed as a species and this never works. Just install virtualization/environment/container support tools on your system and never worry about that again. Docker exists in the real world where work must be done and you can’t reinstall a fresh Linux every two weeks after playing with a new toolchain and then getting bored with it.
Vivado for artix7 is free. Just takes forever to compile to but stream.
Vivado is known for having a very poor VHDL language support that forces users to archaic VHDL 1993 or Verilog 2005. This is because Vivado is NOT an HDL synthesis tool. That’s a minimally functional feature in the IDE.
Conversely, tools such as GHDL + Yosys (or Verific + Yosys) allow using modern language features, significantly reducing development time and complexity. That is a must for the SoCs we build nowadays.
Still, you can use GHDL (and optionally Yosys) for doing synthesis only, and then run PnR with Vivado. It is shown in the diagram that illustrates this article. See https://github.com/hdl/awesome/issues/98.
That provides you “the best of both worlds”. Good language support and vendor specific implementation.
Therefore “why use X if Y is free” is a rather useless claim, which seems to be motivated by lack of expertise with EDA tooling, very regardless of tools being open source or not.
Let’s learn from this new generation of open source tooling for EDA, instead of dismissing it. This happened with open source software before. We know the outcome.