Skip to content

Commit 190a21e

Browse files
umarcorumarcor
committed
initial commit
0 parents  commit 190a21e

19 files changed

+250
-0
lines changed

‎.gitignore

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
*.log

‎CONTEXT.md

Lines changed: 41 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,41 @@
1+
# Context
2+
3+
There are a handful of approaches for providing *great prepackaged/prebuilt and easy-to-set-up EDA tooling environments*:
4+
5+
## Default package managers
6+
7+
Each GNU/Linux distribution has a default package manager: `apt-get`/`apt` on Debian/Ubuntu/LinuxMint, `yum/dnf` on RedHat/CentOS/Fedora, `pacman` on ArchLinux, etc. Therefore, the most natural procedure is to install tooling through the default package manager, since that ensures the best compatibility and stability.
8+
9+
However, on the one hand, it is a huge effort to develop and maintain multiple recipes for each tool and for each officially supported architecture on each distribution. On the other hand, the release schedule and packaging guidelines of some distributions make it unfeasible to keep bleeding-edge projects up to date. That is the case of e.g. Debian or CentOS, which are known to be stable and slowly updating environments.
10+
11+
Therefore, some projects provide non-official recipes for users to build their own `deb`/`rpm`/`tar.xz` packages. For example: [SymbiFlow/symbiflow-arch-pkgs](https://github.com/SymbiFlow/symbiflow-arch-pkgs). Fortunately, on Windows it is easier to upstream recipes because `pacman` is the only supported Unix alike package manager (see [hdl/MINGW-packages](https://github.com/hdl/MINGW-packages)).
12+
13+
Moreover, several alternatives arised in the open source EDA community for making it easier to get latest working toolchains involving several projects. The following solutions trade either features and/or platform/architecture portability for achieving working bleeding-edge environments.
14+
15+
## Statically pre-built packages
16+
17+
[open-tool-forge](https://github.com/open-tool-forge) provides statically pre-built packages for GNU/Linux, Windows and macOS through [fpga-toolchain](https://github.com/open-tool-forge/fpga-toolchain).
18+
19+
This provides the easiest setup approach and it allows having multiple versions of the toolchains, without running into conflicts. However, some features are limited when tools are built statically. See [open-tool-forge/fpga-toolchain: DEVELOPMENT.md > General guidelines](https://github.com/open-tool-forge/fpga-toolchain/blob/main/DEVELOPMENT.md#general-guidelines).
20+
21+
## OCI container images
22+
23+
[ghdl/docker](https://github.com/ghdl/docker), [hdl/containers](https://github.com/hdl/containers), [dbhi/docker](https://github.com/dbhi/docker) (uses [dbhi/qus](https://github.com/dbhi/qus)), [alpin3/ulx3s](https://github.com/alpin3/ulx3s)... provide Linux container images, which can be used on any platform with Docker or Podman support.
24+
25+
This provides the less invasive solution, because no tools are installed on the host, besides the container runtime. Moreover, the behaviour of the tools is exactly the same, regardless of the host OS. However, on Windows, accessing USB devices from containers is not straightforward. See [ ghdl/docker: usbip/README.md > USB/IP protocol support for Docker Desktop](https://github.com/ghdl/docker/tree/master/usbip).
26+
27+
## WebAssembly packages
28+
29+
[YoWASP](http://yowasp.org/) aims to distribute tools form [YosysHQ](https://github.com/YosysHQ/) compiled to [WebAssembly](https://webassembly.org/) via language package managers like Python’s [PyPI](https://pypi.org/).
30+
31+
## Conda packages
32+
33+
[SymbiFlow/conda-packages](https://github.com/SymbiFlow/conda-packages), [SymbiFlow/fpga-tool-perf](https://github.com/SymbiFlow/fpga-tool-perf), [litex-hub/litex-conda-eda](https://github.com/litex-hub/litex-conda-eda), [litex-hub/litex-conda-packages](https://github.com/litex-hub/litex-conda-packages), [antmicro/conda-build-prepare-actions](https://github.com/antmicro/conda-build-prepare-actions)... provide and use non-static packages through [Conda](https://conda.io).
34+
35+
Conda is an *open source package management system and environment management system that runs on Windows, macOS and Linux*. However, for Conda packages to install/configure tools, those need to be previously compiled or available as pre-built packages. Therefore, Conda packages can indeed be wrappers around any of the previous solutions.
36+
37+
---
38+
39+
Apart from building and distributing tools using any of the solutions above, those need to be then used somehow. As discussed in [eine/vhdl-cfg](https://github.com/eine/vhdl-cfg), there are currently about a dozen projects for managing the execution of EDA tools. Any of those might rely on any of the distribution solutions explained above.
40+
41+
In this regard, [SymbiFlow/make-env](https://github.com/SymbiFlow/make-env) is an *environment provider* meant for bootstraping the tools along with tool management projects.

‎README.md

Lines changed: 35 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,35 @@
1+
# Smoke tests
2+
3+
As discussed in [CONTEXT](CONTEXT.md), there is a thriving activity for providing ready-to-use packages of open source EDA tooling: static build, dynamic builds, containers, Conda... Regardless of the packaging approach, most integration and distribution projects need to build each tool using some custom options, and then ensure that the produced artifacts are valid. Running full test suites included in project codebases is sometimes not possible, because CI services timeout. Nevertheless, EDA tools are expected to be thoroughly tested upstream; so, integrators need a set of quick sanity tests.
4+
5+
Existing third-party testsuites and examples typically require additional dependencies for testing multiple tools at the same time. However, integration/distribution strategies do not always build all the tools in the same environment. Therefore, a fine grained approach to test definition is required. In analogy to electrical smoke testing, [smoke testing (software)](https://en.wikipedia.org/wiki/Smoke_testing_%28software%29) is a subset of test cases that cover the most important functionality of a software tool. This repository contains smoke tests for the following tools:
6+
7+
- [x] [bootlector](http://fmv.jku.at/boolector/)
8+
- [ ] [cocotb](https://github.com/cocotb/cocotb)
9+
- [x] [ghdl](https://github.com/ghdl/ghdl)
10+
- [ ] [ghdl-yosys-plugin](https://github.com/ghdl/ghdl-yosys-plugin)
11+
- [ ] [gtkwave](https://github.com/gtkwave/gtkwave)
12+
- [x] [icestorm](https://github.com/cliffordwolf/icestorm)
13+
- [ ] [iverilog](https://github.com/steveicarus/iverilog)
14+
- [ ] [netlistsvg](https://github.com/nturley/netlistsvg)
15+
- [x] [nextpnr](https://github.com/YosysHQ/nextpnr)
16+
- [x] [prjtrellis](https://github.com/SymbiFlow/prjtrellis)
17+
- [ ] [sigrok-cli](https://sigrok.org/wiki/Sigrok-cli)
18+
- [ ] [surelog](https://github.com/alainmarcel/Surelog)
19+
- [x] [symbiyosys](https://github.com/YosysHQ/SymbiYosys)
20+
- [ ] [verible](https://github.com/google/verible)
21+
- [ ] [verilator](https://github.com/verilator/verilator)
22+
- [ ] [vpr/vtr](https://github.com/verilog-to-routing/vtr-verilog-to-routing)
23+
- [ ] [vunit](https://github.com/VUnit/vunit)
24+
- [x] [yices 2](https://github.com/SRI-CSL/yices2)
25+
- [x] [yosys](https://github.com/YosysHQ/yosys)
26+
- [x] [z3](https://github.com/Z3Prover/z3)
27+
28+
Board programming:
29+
30+
- [x] [dfu-util](http://dfu-util.sourceforge.net/)
31+
- [ ] [ecpprog](https://github.com/gregdavill/ecpprog)
32+
- [ ] [fujprog](https://github.com/kost/fujprog)
33+
- [ ] [icesprog](https://github.com/wuxx/icesugar/tree/master/tools)
34+
- [x] [openFPGALoader](https://github.com/trabucayre/openFPGALoader)
35+
- [ ] [openocd](http://openocd.org/)

‎all.sh

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,15 @@
1+
#!/usr/bin/env sh
2+
3+
stdir="$(dirname "$0")"
4+
5+
"$stdir"/bootlector.sh
6+
"$stdir"/dfu-util.sh
7+
"$stdir"/ghdl.sh
8+
"$stdir"/icestorm.sh
9+
"$stdir"/nextpnr.sh
10+
"$stdir"/openFPGALoader.sh
11+
"$stdir"/prjtrellis.sh
12+
"$stdir"/symbiyosys.sh
13+
"$stdir"/yices.sh
14+
"$stdir"/yosys.sh
15+
"$stdir"/z3.sh

‎bootlector.sh

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
#!/usr/bin/env sh
2+
3+
. $(dirname "$0")/common.sh
4+
5+
ST_LOGFILE=./bootlector.log
6+
7+
[ -f "$ST_LOGFILE" ] && rm -rf "$ST_LOGFILE" || true
8+
9+
test_help boolector btorsim btoruntrace btormc btorimc

‎common.sh

Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,34 @@
1+
#!/usr/bin/env sh
2+
3+
enable_color() {
4+
ANSI_RED="\033[31m"
5+
ANSI_GREEN="\033[32m"
6+
ANSI_YELLOW="\033[33m"
7+
ANSI_BLUE="\033[34m"
8+
ANSI_MAGENTA="\033[35m"
9+
ANSI_GRAY="\033[90m"
10+
ANSI_CYAN="\033[36;1m"
11+
ANSI_DARKCYAN="\033[36m"
12+
ANSI_NOCOLOR="\033[0m"
13+
}
14+
15+
disable_color() { unset ANSI_RED ANSI_GREEN ANSI_YELLOW ANSI_BLUE ANSI_MAGENTA ANSI_CYAN ANSI_DARKCYAN ANSI_NOCOLOR; }
16+
17+
enable_color
18+
19+
#-
20+
21+
test_help() {
22+
for tool; do
23+
echo "· $tool help >> $ST_LOGFILE"
24+
$tool --help >> "$ST_LOGFILE" 2>&1
25+
exit_code=$?
26+
printf "· $tool help: exit code $exit_code | "
27+
if [ "$exit_code" = "0" ] || [ "$exit_code" = "64" ]; then
28+
printf "${ANSI_GREEN}OK${ANSI_NOCOLOR}\n"
29+
else
30+
printf "${ANSI_RED}FAIL${ANSI_NOCOLOR}\n"
31+
exit $exit_code
32+
fi
33+
done
34+
}

‎dfu-util.sh

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
#!/usr/bin/env sh
2+
3+
. $(dirname "$0")/common.sh
4+
5+
ST_LOGFILE=./dfu-util.log
6+
7+
[ -f "$ST_LOGFILE" ] && rm -rf "$ST_LOGFILE" || true
8+
9+
test_help dfu-prefix dfu-suffix dfu-util

‎ghdl.sh

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
#!/usr/bin/env sh
2+
3+
. $(dirname "$0")/common.sh
4+
5+
ST_LOGFILE=./ghdl.log
6+
7+
[ -f "$ST_LOGFILE" ] && rm -rf "$ST_LOGFILE" || true
8+
9+
test_help ghdl

‎icestorm.sh

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
#!/usr/bin/env sh
2+
3+
. $(dirname "$0")/common.sh
4+
5+
ST_LOGFILE=./icestorm.log
6+
7+
[ -f "$ST_LOGFILE" ] && rm -rf "$ST_LOGFILE" || true
8+
9+
test_help icebram icemulti icepack icepll iceprog icetime

‎nextpnr-ecp5.sh

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
#!/usr/bin/env sh
2+
3+
. $(dirname "$0")/common.sh
4+
5+
ST_LOGFILE=./nextpnr-ecp5.log
6+
7+
[ -f "$ST_LOGFILE" ] && rm -rf "$ST_LOGFILE" || true
8+
9+
test_help nextpnr-ecp5

0 commit comments

Comments
 (0)