yosyshq / fpga-toolchain Goto Github PK

tool for programming ulx3s
https://github.com/kost/fujprog

The build instructions in the README don't mention building the bba file. I guess it was recently split up? I noticed that the script build_bba.sh needs to be run first, to generate the file ecp5-bba-linux_x86_64-nightly.tar.gz, otherwise build.sh fails on a tar command in the compile_nextpnr_ecp5 step.
(there also appears to need to be a clean.sh step in between build_bba.sh and build.sh otherwise it gets confused about the pre-existing git checkout, but if you're not careful to first copy the generated file out, you'll end up losing it 😇 )

If possible, please include SymbiYosys (the formal verification tool, seeing increasing adoption by designers) in this package. Building/installing some of the solver dependencies is a pain.

• iverilog VPI?
• conda site-packages
• (whatever else can be found to get the release size down)

This might be too much scope creep and could be showing a little bias for one particular IDE, but I thought it could be nice to bundle some tools that allow us to give people a nice experience with VS Code without much effort.

VS Code plugin: verilog-formatter needs istyle verilog formatter

VS Code plugin: Verilog HDL/SystemVerilog needs universal ctags

Alternative: https://github.com/dalance/svls

GHDL Language Server + VS Code Plugin needs a python interpreter with a native module installed for the lang server (impacts #19 as it would mean we need to make sure there is an interpreter as well as a static lib - ideally we can keep the interpreter out of PATH). Also the VS Code plugin is currently not distributed on the marketplace - might be worth liasing with GHDL team to see what their plans are there/if anyone else is already generating builds of it.

I won't start working on this until people have a chance to comment, suggest additional/alternative tools, talk me out of it, etc.

1. list the tools included (+ link to upstream projects)
2. add CI badge(s)
3. make sure credits section is complete

I'm looking to spool up teaching and turnkey starter kits of getting your feet wet in FPGA and my board of choice is the Sipeed Tang Nano, supported by the Apicula interface layer.
If you could add build of the stack into this repo that'd be greatly appreciated!

Building ghdl-yosys-plugin as part of Yosys is not recommended and might become deprecated: https://github.com/ghdl/ghdl-yosys-plugin#build-as-part-of-yosys-not-recommended. Instead, it is suggested to build it as an object, an load it in Yosys as a plugin.

However, in this repository ghdl-yosys-plugin is built as part of Yosys (https://github.com/open-tool-forge/fpga-toolchain/blob/main/scripts/compile_yosys.sh#L28). Moreover, Yosys is built without plugin support (https://github.com/open-tool-forge/fpga-toolchain/blob/main/scripts/compile_yosys.sh#L55).

Is this because of some limitation when building Yosys statically?

Add another stage to the build which runs the tools in a fresh env without any of the build deps installed. For linux, we can test in a few different distros in a container to make sure there are no issues related to static libc.

This was requested for WSL users to avoid having to download two full packages

Various issues:

• Something broke the string matching after upgrading to ubuntu 20.04
• I am not running it on all the builds - vvp has accidentally ended up dynamically linked as a result
• Darwin and Windows are currently not testing for static linking - should be able to kludge together a whitelist of system dylibs/dlls so that we can test all platforms
• For linux we could spin up a container of a non-debian distro to check the binaries work without the system libs in the build environment.

Currently on windows we're linking against the mingw python provided by msys2 which doesn't provide a static lib. Darwin is statically linking against conda which is not exactly a minimal python installation. Linux is statically linking against the lib from the ubuntu package and currently extracting scripts from some .deb packages in the repo.

To get a static lib and minimal set of standard library scripts/modules it looks like building python from source is a good option. Building for MinGW might be slightly more complicated - MSYS2 maintains a fairly large set of patches to make it work https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-python

vvp isn't statically linked on linux and darwin

Hi!

As @edbordin mentioned when I logged a bunch of issues around adding things like support for Xilinx and QuickLogic toolchains, it is a lot of work to keep things building and moving forward. To help reduce burden on a single maintainer (and thus things like burnout) a bunch of people from the GHDL / V-Unit community created the HDL github organization and are trying to build a critical mass around providing open source EDA tooling (like the open source FPGA tooling) in a number of different ways like static binaries, conda, docker and including "native" solutions like homebrew.

The idea is that bringing these different styles of packaging together under one GitHub organization makes it easier to do things like; sharing tips around how to get things auto-building on CI, workarounds for common issues, how to test the tools are working, etc. There is quite a long document covering a lot of aspects of this topic. We plan to move the conda packaging currently found on LiteX-Hub / SymbiFlow / TimVideos organizations to this location and have already been working on doing a bunch of bazel related build rules (which are probably not that interesting to you but shows there is a bit of momentum behind the effort). Having everything under one organization also makes it easier for people like my employer to donate things like build resources to speed up CI and support on hardware testing.

I think you should consider collaborating with this group, joining the organization and potentially even going as far as moving your repositories over. Given the strong set of VHDL enthusiasts, I'm sure if you moved the repository over there would be a strong incentive to add things like GHDL and demonstrate things like mixed-synthesis support (The community did that recently for the Fomu workshop, see https://workshop.fomu.im/en/latest/vhdl.html and https://workshop.fomu.im/en/latest/mixed-hdl.html).

Understand if you want to maintain to stay separate but highly recommend considering this. If you are actively involved in the HDL organization you can also make sure things like the needs for the icebreaker and your FPGA workshops are first class citizens in not only when using static binaries but also in other packaging schemes like Docker / conda / etc.

Keep up the awesome work!

Tim @mithro Ansell

On other platforms this is a python script, for windows an exe launcher is generated but make install doesn't seem to be adding the script it expects.

$ yosys-smtbmc.exe --help
Cannot open <snip>\fpga-toolchain\bin\yosys-smtbmc-script.py

If I copy in the script from the linux build I get

$ yosys-smtbmc.exe --help
failed to create process.

https://github.com/YosysHQ/yosys/blob/93c6c6779861d7b41fae1b87d54790e0a9555b80/backends/smt2/smtbmc.py
https://github.com/YosysHQ/yosys/blob/93c6c6779861d7b41fae1b87d54790e0a9555b80/backends/smt2/Makefile.inc#L14
https://github.com/YosysHQ/yosys/blob/93c6c6779861d7b41fae1b87d54790e0a9555b80/misc/launcher.c

edit: related to #25

The artifact names are generated using the current date and are recomputed at the start of each stage, which breaks when the date changes mid-build.

example: https://dev.azure.com/open-tool-forge/fpga-toolchain/_build/results?buildId=457&view=results

Currently beginners using e.g. iceprog on Windows need to use the Zadig GUI tool to change their drivers. If we can include a tool like this to change the FTDI drivers on the command line (but perhaps without needing python) it could be handy for people writing quickstart instructions and also more convenient for everyone else:
https://github.com/CapableRobot/CapableRobot_USBRegister

There is also this new tool by xobs which is able to use the default drivers:
https://github.com/xobs/swot

Maybe we just bundle both for now?

Currently because I changed the version string format, nmigen can't parse it and ignores our yosys build. Standard yosys version string is something like 0.9+3292 which can be updated with make bumpversion

Would it be possible to compile nextpnr, in particular nextpnr-ecp5, with GUI support?

According to https://github.com/YosysHQ/nextpnr GUI support is disabled by default to reduce dependencies. It is not immediately clear to me whether this is related to build-time dependencies or run-time dependencies. At run-time, the GUI must be enabled with a command-line option, but again it is not clear to me whether one can run nextpnr headless on a headless system just by ommitting that option once it was built with GUI support.

All this could imply that GUI support can only be provided by building two separate executables, nextpnr-ecp5 and nextpnr-ecp5-gui, for headless and gui mode, respectively.

With respect to ccompile-time dependencies, the manual says "On Ubuntu, install qt5-default", but this sounds like it would install the qt5 runtime on the build host, not the necessary compile-time files to build a qt5 executable that is intended to be run on a different machine. In other words, it seems to confuse the build host and the target machine.

Since the delivery of the crowdsupply boards they are probably consolidating the repos. It appears https://github.com/ulx3s/ulx3s-examples is now the repo to use.

I've had raspberry pi support requested twice now. I wasn't anticipating huge demand for this but given some of the support is still there in the scripts I thought I should at least add it to the backlog

This has been requested a few times. fomu-toolchain bundles https://sourceforge.net/projects/ezwinports/files/make-4.3-without-guile-w32-bin.zip/download

VPR can be used to target Artix 7 and other Xilinx 7 series parts as well as the QuickLogic EOS S3 parts.

• https://github.com/SymbiFlow/vtr-verilog-to-routing
• https://github.com/verilog-to-routing/vtr-verilog-to-routing
• https://www.verilog-to-routing.org

Under (at least) Cygwin64, bash is unhappy with the CRs in yosys-config line endings, causing the script to fail. Changing to Unix convention (just LF) seems to fix it.

On OS X, archives downloaded in the browser are marked with a "quarantine flag" which is transferred to all files when an archive is extracted https://discourse.brew.sh/t/code-signing-installed-executables/2131/12

The user will get a warning for every executable they try to run if this flag is set.

These are the solutions to avoid the warning that I'm aware of:

• Download with a CLI tool like wget
• Remove the flag from the archive before extracting with xattr -d com.apple.quarantine
• Manually allow each executable to run (annoying and probably impractical if changing builds frequently).
• Code-sign the executables, which should stop the warning appearing at all so long as the developer cert is valid.

I will leave this open for discussion. I'm inclined to say we don't need it but I am not the end user of this build so happy for others to chime in.

EDIT: This behaviour is not new in Catalina so I'm inclined to think users are used to it. But this can stay open for now in case somebody wants to make a case for signing the binaries.

edit 2: windows 10 actually behaves a similar way

As part of the work in creating Project U-Ray (based on Project X-Ray) the tooling required by end users (such as FPGA RTL developers) have been split from the repo containing the fuzzers and other documentation generation tooling.

This should make it easy to package and is needed for Xilinx 7 series support (with either vpr or nextpnr).

https://github.com/SymbiFlow/yosys-symbiflow-plugins

Needed for Vivado compatible XDC support and other similar functionality.

see msys2/MSYS2-packages#2022
temporary fix here (hoepfully) mesonbuild/meson@d438a2d

system.vpi implements core simulation functions and is dynamically linked to the VPI functions implemented in /lib/ivl/ivl. It doesn't work when ivl is statically linked. Options I can see:

• Ship dynamic binaries with their rpath manipulated to find bundled shared libs
• See if we can patch iverilog to compile in system.vpi

Until this is fixed I will stop shipping iverilog since there is no point.

for yosys: https://github.com/YosysHQ/yosys-tests
"by default only the smaller included testsuite is run as yosys-tests exceeds CI runtime"

The replacement script for yosys-config works nicely, but by default doesn't have executable bit set. Thanks!

• nextpnr CMakeLists.txt were changed recently, need to adjust the build scripts
• upstream for prjtrellis has moved to https://github.com/YosysHQ/prjtrellis

yosys-abc.exe has been crashing with an access violation exit code on windows. It doesn't look like the code has changed (although it's possible the way it's building has changed). Looks like the binutils version changed from mingw-w64-x86_64-binutils-2.36-1 to mingw-w64-x86_64-binutils-2.36-3 when this started happening so it might be worth rolling that back as a first step.

Having a HDL code formatter (similar to clang-format) included in the tools would be nice, one such tool is Verible from Google. Seeing how to nicely format HDL code is useful for a beginner :-) -- Verible also does linting.

Verible is already /mostly/ statically linked and provides release on every commit (see https://github.com/google/verible/releases) and the binary is only ~5mb or less.

One problem is that Windows / Mac OS X support is currently lacking (which could be easy to fix by someone who knows about portability?) and it uses Bazel to build (being a Google project).

a change upstream in yosys to use GHDL_PREFIX instead of GHDL_DIR appears to have broken the build on the main branch here

Provided it doesn't add too much bloat and linking statically isn't too hard I don't see why not!

• Repeated stuff like git clone / rsync could be converted to bash functions
• The two nextpnr builds could probably be consolidated into one script
• There may still be files in the repo that are no longer used and could be deleted
• The stuff in build_setup copying python files to _packages might be better as a separate "compile_x"/"install_x" script that can be disabled during dev.
• The two CI steps to download artifact then copy it into place could be one step if we use path to download it into place https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/download-pipeline-artifact?view=azure-devops
• might be worth adding a flag to disable the BBA artifact build/download easily when doing development on something unrelated to nextpnr (currently several locations need to be commented out)

https://github.com/gregdavill/ecpprog

potential solution for the occasional error cc1plus.exe: out of memory allocating 65536 bytes
edit: potentially also -fno-var-tracking-assignments

While building for linux_x86_64 on Ubuntu 20.04 Focal, the following error appears and stops the build:

In file included from /home/ubuntu/fpga-toolchain/_builds/build_linux_x86_64/avy/avy/src/ItpMinisat.cc:2:
/home/ubuntu/fpga-toolchain/_builds/build_linux_x86_64/avy/avy/src/ItpMinisat.h: In member function 'bool avy::ItpMinisat::isSolved()':
/home/ubuntu/fpga-toolchain/_builds/build_linux_x86_64/avy/avy/src/ItpMinisat.h:127:52: error: cannot convert 'boost::logic::tribool' to 'bool' in return
  127 |     bool isSolved () { return m_Trivial || m_State || !m_State; }
      |                               ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
      |                                                    |
      |                                                    boost::logic::tribool
[ 98%] Built target minisat_core.BIN
[ 98%] Linking CXX executable minisat
[ 98%] Linking CXX executable glucose
[ 98%] Built target minisat
In file included from /home/ubuntu/fpga-toolchain/_builds/build_linux_x86_64/avy/avy/src/ItpGlucose.cc:2:
/home/ubuntu/fpga-toolchain/_builds/build_linux_x86_64/avy/avy/src/ItpGlucose.h: In member function 'bool avy::ItpGlucose::isSolved()':
/home/ubuntu/fpga-toolchain/_builds/build_linux_x86_64/avy/avy/src/ItpGlucose.h:129:52: error: cannot convert 'boost::logic::tribool' to 'bool' in return
  129 |     bool isSolved () { return m_Trivial || m_State || !m_State; }
      |                               ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
      |                                                    |
      |                                                    boost::logic::tribool
/home/ubuntu/fpga-toolchain/_builds/build_linux_x86_64/avy/avy/src/ItpGlucose.h: In member function 'bool avy::ItpGlucose::getVarVal(int)':
/home/ubuntu/fpga-toolchain/_builds/build_linux_x86_64/avy/avy/src/ItpGlucose.h:185:23: error: cannot convert 'boost::logic::tribool' to 'bool' in return
  185 |         return tobool (m_pSat->modelValue(x));
      |                ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
      |                       |
      |                       boost::logic::tribool

I suspect it is a boost version incompatibility, though I'm not sure the version of boost in this version of ubuntu is too old or too new.

Edit: looks like exactly the problem described in this tweet: https://twitter.com/FeatherOrNot/status/1266931889899741184
Edit.2: upstream PR on bitbucket, with patch: https://bitbucket.org/arieg/avy/pull-requests/20/cast-tribool-too-bool-for-boost-171/diff

This is blocking the nightly nextpnr-ecp5 from being usable

Specifically we probably want to support yosys-config --bindir and yosys-config --datdir.
E.g. seems to be a common use-case to point sim tools to cell libs: yosys-config --datdir/ice40/cells_sim.v

It would be safest if the other options --cxx, --cxxflags, --ldflags, --ldlibs throw an error so it is clear they are unsupported. The supported options should output absolute paths generated relative to the script's location. Probably easiest to just ship our own version of the script rather than patching.

Also consider getting it to work on windows in e.g. git bash.

The README says:

Z3: Engine for SymbiYosys