github-actions[bot] on nightly
elab-vhdl_context: remove cur_s… synth-vhdl_stmts: add comments … synth-vhdl_stmts: avoid a crash… and 1 more (compare)
tgingold on master
elab-vhdl_context: remove cur_s… synth-vhdl_stmts: add comments … synth-vhdl_stmts: avoid a crash… and 1 more (compare)
I would love to have GHDL plugin for yosys built and distributed, problem is that it is ADA based, and that is possible to cross compile to other linux variants , but have issue for darwin and windows targets
As commented in YosysHQ/oss-cad-suite-build#1, for distribution on Windows I very strongly recommend using MSYS2. If you don't want users to install MSYS2 explicitly, you can hide it from them with a wrapper. That is what projects Ruby or Qt do. GTKWave provides it too. You don't need to use the upstream recipes if you don't want to, but you can tweak those.
Recently, UCRT64 was added to MSYS2, which complements MINGW32, MINGW64 and CLANG64. UCRT64 should reduce possible corner cases when combining binaries with others built with VS.
For Linux, I avoid cross-compilation by using QEMU along with containers. See dbhi/qus and dbhi/docker. QEMU's user mode does not receive as much love as the system mode; hence, there might be issues with "weird" system signals. However, it works fairly well, and ARM support was improved significantly in these last 2 years. On the other hand, there are no official images for RISC-V yet. @carlosedp is pushing hard in that area: carlosedp/riscv-bringup.
For sure I need to use LLVM based build, but problem in it is that it try to precompile VHDL libraries with created binaries which is not possible for all targets since no QEMU for macOS (darwin)
You have issues for cross-building for macOS on ARM, from a Linux on x86-64?
Would appreciate any help in making minimal ghdl plugin build that can work on all targets
The plugin is not an issue. You can embed it into yosys. The plugin depends on the libghdl shared library. That is neither an issue, since you can build it. The problem is that almost all VHDL designs do depend on the standard and IEEE libraries. That's why, in practice, ghdl-yosys-plugin is said to depend on GHDL (on the installation, no the binary).
Theoretically, I'd say you could avoid building the libraries by providing an specific target to make
. Then you would need to bundle GHDL, the shared libs, the headers, the includes and the VHDL sources of the libraries. Last, you would need to provide an script for building the libraries, similar to https://github.com/ghdl/ghdl/tree/master/scripts/vendors, which users would need to run once after extracting the bundle. However, I don't think anyone used that workflow in practice...
Also apologize if it sounded for a time that I am not listening, it was more pressure to finish things and have it ready for customers, but keeping community in mind as well.
It's ok. The pressure is very different since you want to provide an specific set of tools on some specific platforms for some specific users in a given timeframe. Conversely, in hdl/containers and hdl/MINGW-packages there is no specific set of tools, platforms, users or timeframe. That is the point: to use the canonical solutions, even if it takes longer to achieve a complete solution. That is because no one is explicitly funding those solutions, so the time that can be demanded is zero. Well, I must say that Google is donating a container registry with "unlimited" resources since a couple of days ago. I need to start using it, tho.
I am pretty sure there are cross-compilers for the windows targets.
@tgingold maybe you mean https://github.com/hackfin/ghdl-cross.mk ? I think that is different. That generates a GHDL to be executed on Linux, which will produce simulation models for Windows. But GHDL itself is not cross-compiled.
@mmicko, absolutely no pressure or rush at all. Having a solid and stable open source EDA ecosystem is a mid-long term project that requires a lot of people to coordinate. We will get there, step by step.
Hi everyone!
I am trying to install ghdl-ls on my WSL Ubuntu 18.04. Everything looks fine, but when I am calling ghdl-ls
I got following:
Traceback (most recent call last):
File "/home/arnfol/anaconda3/bin/ghdl-ls", line 5, in <module>
from pyGHDL.cli.lsp import main
File "/home/arnfol/anaconda3/lib/python3.8/site-packages/pyGHDL/cli/lsp.py", line 44, in <module>
import pyGHDL.libghdl as libghdl
File "/home/arnfol/anaconda3/lib/python3.8/site-packages/pyGHDL/libghdl/__init__.py", line 149, in <module>
libghdl = _initialize()
File "/home/arnfol/anaconda3/lib/python3.8/site-packages/pyGHDL/libghdl/__init__.py", line 131, in _initialize
_libghdl_path = _get_libghdl_path()
File "/home/arnfol/anaconda3/lib/python3.8/site-packages/pyGHDL/libghdl/__init__.py", line 126, in _get_libghdl_path
raise Exception("Cannot find libghdl {}".format(basename))
Exception: Cannot find libghdl libghdl-2_0_0_dev.so
Here is my installation script:
#!/usr/bin/env bash
sudo apt-get install -y libz-dev
sudo apt-get install -y gcc gnat
# get & install GHDL
git clone https://github.com/ghdl/ghdl.git
cd ghdl
mkdir build && cd build
../configure --prefix=/opt/ghdl
make && make install
# install PyGHDL
cd ..
pip3 install .
What am I doing wrong?
/opt/ghdl/lib/libghdl-2_0_0_dev.so
and here is my ghdl --dispconfig
output:command_name: /opt/ghdl/bin/ghdl
command line prefix (--PREFIX): (not set)
environment prefix (GHDL_PREFIX): (not set)
exec prefix (from program name): /opt/ghdl
library prefix: /opt/ghdl/lib/ghdl
library directory: /opt/ghdl/lib/ghdl
default library paths:
/opt/ghdl/lib/ghdl/ieee/v93/
/opt/ghdl/lib/ghdl/
Locate the directory where the shared library is installed.
Search order:
GHDL_PREFIX
- directory (prefix) of the vhdl libraries.VUNIT_GHDL_PATH
- path of theghdl
binary when using VUnit.GHDL
- name of, or path to theghdl
binary.- Try within
libghdl/
Python installation.- Try when running from the build directory.
GHDL_PREFIX=/opt/ghdl/lib/ ghdl-ls
cause the same error
GHDL=/opt/ghdl/bin/ghdl ghdl-ls
?
GHDL_PREFIX=/opt/ghdl/lib/ghdl ghdl-ls