Both look promising, but I’d like to consider all options. Anything else that’s pretty complete for basic simulation and synthesis AND likely to be maintained?
I co-teach an introductory course in digital logic. We’re currently using a custom docker image in a dev container, but I’d like to move to something that’s better maintained. We need support for an introduction to Verilog, but additional features would be nice (like GHDL and full SystemVerilog frontend extension).
Tangent: The dev container has been a great fit for our needs. It works well on macOS, Linux, and Windows, has all the tools we need, and can be run from the cloud (via GitHub Codespaces). We’ve been using openFPGALoader-web to deploy to devices.
The IIC-OSIC-TOOLS image would probably be my suggestion too. The only ‘official’ YosysHQ docker images are for building Yosys, rather than using it. A docker image for benchmarking/profiling is something on my mind, but it would still be aimed at CI use rather than end-user.
Hi,
Please note that oss-cad-suite is self contained so you actually do not need any additional package for it to work, so containers are maybe not even needed since all required libraries are included. Also it does not depend on Linux distribution so it should work fine with all of them. You can point to a specific release (we are not removing old ones) and ask students to install OS specific version, since some of them may use macOS. And please note that for Windows users we still recommend using WSL and linux-x64 version on it since there are some tools that just do not have proper Windows build at all.
From my perspective, creating docker image based on oss-cad-suite is trivial, but distributing them on daily basis is maybe not that good idea to do, maybe monthly.
Hi @micko — Thanks for the response! I’m definitely open to alternatives or tips to improve what we’re doing. I’m new to containers and new to OSS tools for HDL/CAD. My first approach was to install individual packages that we needed in a container. I’ll test out switching to just installing oss-cad-suite in the container — that’s definitely an improvement. I’ll also consider/review how to approach local installs (within the constraints described below).
The reason for the “dev container” was to focus the student time on the important ideas and content rather than tool installation and tool-related details. The dev container provides a fully-configured IDE environment. It has a pretty consistent look, feel, and behavior for everyone, which makes it a lot easier for instructors and teaching assistants to support. It can also be launched from the cloud in about 2-4 minutes, which overcomes a lot of problems, like students not having enough space to install tools. We don’t have to provide too many O.S.-specific instructions either. (The only O.S. specific thing is having Windows users change a USB driver).
Our dev container includes a lot of VS Code extensions and everything runs in the same environment reasonably smoothly (Venus to simulate RISC-V assembly, Surfer to view waveforms, DigitalJS for gate-level simulation, syntax highlighting for Verilog and assembly language, etc.). Most activities automatically open an appropriate tool to view the result, like testbenches will open the vcd in Surfer. We do a lot of in-class activities where students create/launch the environment at the start of class and then work through problems related to the topic — the integration helps us focus on the important content in the short time we have.