Docker image for the whole design flow about docker HOT 2 CLOSED

Thank you very much for the detailed answer!

Actually, I was looking exactly for https://github.com/tgingold/ghdlsynth-beta#docker, but looked at the wrong places. The approach with executing three containers worked for me. There is no additional effort needed to merge the images.

I'm not very familiar with docker images and had only my use case in mind. So I thought the easiest solution was a single image with all the tools. But as there are multiple tools available for each step, I agree that the modularity is essential for many users.

from docker.

Hi @marph91!

No, there is no such a single fat image that includes everything. This is a design decission. Hence, please, let me elaborate, and do not hesitate to argue against any of the following points. I'd be actually so glad to discuss this.

There are five related but different tasks during the development and testing of VHDL designs:

• Simulation. Can be done with GHDL, but also with ModelSim/QuestaSim, Riviera, etc. Might use some framework/tool, such as VUnit or cocotb.
• Synthesis. Can be done with GHDL + yosys, but also with Vivado, Precision, Quartus, Icecube...
• Place and route. Can be done with arachne-pnr or nextpnr, but also with Vivado, Quartus or Icecube.
• Programming/configuration of the device. Can be done with iceprog, but also with Xilinx cables, Digilent's JTAG...
• Formal verification. Can be done with Symbiyosys, but also with commercial tools (don't know any specific name).

Hence, the points are:

• Most users don't want to do all five tasks.
• Users that want to do all five tasks, might not want to execute everything at the same time, or on the same workstation. Say, one might generate the bitstream in a Windows workstation and copy it to a RPi in order to execute iceprog without dealing with buggy FTDI support on Windows.
• Some users might want to combine some tasks with open source tools and others with vendor tools. For example, ghdl --synth can be used as a kind of transpiler, to convert VHDL 2008 sources to a "less demanding" language variant that is accepted by other tools with poor language support.
• In CI environments or in low-cost SBCs, size matters. The following are compressed sizes:
  • Simulation or ghdl --synth: >75MB.
  • Synthesis with yosys: >200MB.
  • P&R with nextpnr: >340MB.
  • Icestorm >55MB.
  • Formal verification with symbiyosys: >220MB. Note that this includes the minimal installation. If multiple solvers are installed, it gets significantly larger.
• Almost all the images we provide, although tagged with different names, are built incrementally. For example, the image for synthesis with yosys shares all the layers except the last with one of the images for simulation. The image for formal verification is based on the one for synthesis with yosys. As a result, the volume of data required to pull 3-4 images should not be much larger than an equivalent single image with all the tools in it.

This last point is explained in the README, although I reckon that it might not be easy to understand, unless you know what to look for:

Each of the following images includes a tool on top of a debian:buster-slim image:

ghdl/synth:yosys: includes YosysHQ/yosys (master).

ghdl/cache:yosys-gnat: includes libgnat-8 on top of ghdl/synth:yosys.

A ghdl/ghdl:* image is created based on the corresponding ghdl/run:* image.

Which means that ghdl/ghdl:buster-mcode is based on ghdl/run:buster-mcode. ghdl/run:buster-mcode is based on debian:buster-slim.

ghdl/synth:latest: includes ghdl/ghdl with synthesis features enabled on top of a ghdl/run:buster-mcode image.

ghdl/synth:beta: includes ghdl from ghdl/synth:latest along with ghdlsynth-beta built as a module for YosysHQ/yosys, on top of ghdl/cache:yosys-gnat.

Then, image ghdl/synth:formal is built, which includes the tarball from ghdl/cache:formal and Python3 on top of ghdl/synth:beta.

Now that I explained the context, let me answer your question:

(ghdl, ghdlsynth, yosys, nextpnr and icestorm)

The suggested approach is to execute three containers: one for synthesis, another one for P&R and a last one to program the device. See https://github.com/tgingold/ghdlsynth-beta#docker. Regarding the note at the botton, it is technically possible to use icestorm on Windows from inside a Docker container, but it is not exactly plug & play: https://github.com/ghdl/docker/tree/master/usbip

Alternatively, due to the kind of modular infrastructure we use to build our images, you can reuse most of the content to build a single image that includes all of the tools. In this case, that would be merging three images into one. There are several possible approaches to do so. Should you be interested, please let me know.

from docker.