Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 04:08
    tgingold commented #2065
  • 04:08
    tgingold reopened #2065
  • May 21 17:00
    Paebbels commented #2065
  • May 21 16:13
    gncemre23 closed #2065
  • May 21 16:12
    gncemre23 commented #2065
  • May 21 15:22
    gncemre23 edited #2065
  • May 21 15:06
    umarcor labeled #2065
  • May 21 15:06
    umarcor labeled #2065
  • May 21 15:03
    gncemre23 opened #2065
  • May 20 22:56
    umarcor opened #2064
  • May 18 17:58

    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)

  • May 18 17:17
    umarcor milestoned #2063
  • May 18 17:16
    tgingold closed #2063
  • May 18 17:16

    tgingold on master

    elab-vhdl_context: remove cur_s… synth-vhdl_stmts: add comments … synth-vhdl_stmts: avoid a crash… and 1 more (compare)

  • May 18 11:42
    cderrien commented #2063
  • May 18 10:35
    umarcor labeled #2063
  • May 18 10:35
    umarcor labeled #2063
  • May 18 10:25
    cderrien opened #2063
  • May 17 21:19
    umarcor milestoned #2062
  • May 17 21:17
    umarcor milestoned #2060
Unai Martinez-Corral
@umarcor

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.

tgingold
@tgingold
@mmicko For the GHDL plugin: I am pretty sure there are cross-compilers for the windows targets. I am not sure for Darwin even if theorically that should be possible too.
For the standard libraries, there is no need to create the object files as they are used only for simulation. The standard libraries should be analyzed once, but the result is a text file that is portable (although I fear this hasn't been tested).
Miodrag Milanović
@mmicko
Thanks @umarcor for very detail answer, will check links you have provided regarding docker solutions, and have to think of best way of providing that. As you pointed out it is one-man-project so some things take time, and also there are other things I do. So will solve things like GHDL integration and docker environment , but some of that may take time due to proiorities
@tgingold will probably jump in here with more questions when time comes :)
Sammy Lin
@bkzshabbaz
Hello, I'm trying out an exercise where I'm generating a clock from within the FPGA and sending it out to a pin using the ODDRX1F primitive. I get this warning when I do so:
ERROR: cell type 'oddrx1f' is unsupported (instantiated as 'odd_inst.oddr_inst')
0 warnings, 1 error
Unai Martinez-Corral
@umarcor

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.

@bkzshabbaz, please provide the full context of what you are trying to achieve. It seems that you are trying to use GHDL, ghdl-yosys-plugin and Yosys for synthesising a VHDL design targeting an ECP5 device?
Sammy Lin
@bkzshabbaz
That's correct.
Unai Martinez-Corral
@umarcor
@bkzshabbaz, then, I believe you are not including the "components", specifically the 'oddrx1f' component.
Those three examples are based on Makefiles. However, each of them uses an slightly different style and source organisation.
Sammy Lin
@bkzshabbaz
I am using the "components". I'm also using the EHXPLLL component, and it's not complaining about that.
I brought this up in the ulx3s gitter chat and they mentioned the oddrx1f component isn't capitalized.
@gatecat
It should be in capitals
I suspect there is some kind of GHDL issue going on here but don't know how to fix it
Unai Martinez-Corral
@umarcor
@bkzshabbaz if that is the case, please provide a MWE which we can execute and test. There have been some other issues related to lower/upper. Strictly, VHDL is not case sensitive, so it should not be relevant.
Sammy Lin
@bkzshabbaz
Will do. Does the rest of the toolchain's case sensitivity matter?
Unai Martinez-Corral
@umarcor
That might be the case. Maybe GHDL does not have a problem with it, but Yosys or nextpnr do.
Sammy Lin
@bkzshabbaz
Should I submit a Github issue?
Unai Martinez-Corral
@umarcor
Yes, please. You can add the MWE to some branch in some repo of yours, tho. You don't need to copy the sources to the body of the issue if you don't want to.
See ghdl/ghdl#1682. Not exactly the same, but also related to upper casing between GHDL and one specific variant of yosys.
Sammy Lin
@bkzshabbaz
Yup, exactly what I was thinking about.
Unai Martinez-Corral
@umarcor
Note that in that case the "request" was to "always emit uppercase" to the backend.
However, it could be handled by an specific option in yosys.
Sammy Lin
@bkzshabbaz
attrmap -tocase ODDRX1F?
Unai Martinez-Corral
@umarcor
Yeah, that might be. I don't know where in the pipeline you need to put it, tho. Maybe after 'ghdl' and before 'synth_ecp5'?
Sammy Lin
@bkzshabbaz
Thinking the same thing.
Sammy Lin
@bkzshabbaz
Not sure if attrmap is working, since this isn't an attribute?
Will get a MWE branch up soon.
Vitaly Konovalov
@arnfol

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?

found the libghdl in /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/
Vitaly Konovalov
@arnfol
however I can't understand what's wrong here)
Unai Martinez-Corral
@umarcor
/opt/ghdl/lib is not an standard location for libraries. You need to specify it through some envvar.
Locate the directory where the shared library is installed.
Search order:
  1. GHDL_PREFIX - directory (prefix) of the vhdl libraries.
  2. VUNIT_GHDL_PATH - path of the ghdl binary when using VUnit.
  3. GHDL - name of, or path to the ghdl binary.
  4. Try within libghdl/ Python installation.
  5. Try when running from the build directory.
Vitaly Konovalov
@arnfol
do I need to specify it for the installation process only?
Running GHDL_PREFIX=/opt/ghdl/lib/ ghdl-ls cause the same error
Unai Martinez-Corral
@umarcor
What's the location of libghdl-2_0_0_dev.so?
Did you try GHDL=/opt/ghdl/bin/ghdl ghdl-ls?
I think that GHDL_PREFIX needs to point to a subdir of lib: GHDL_PREFIX=/opt/ghdl/lib/ghdl ghdl-ls
Kaleb Barrett
@ktbarrett
Does GHDL support VHDL-2019 Interfaces? Is there any documentation on what language features are supported/missing in each language revision? Something like this maybe?
I ran into type-generic entities not being supported last night =/ and a coworker is asking about interfaces.
Unai Martinez-Corral
@umarcor
@ktbarret, interfaces are not supported and generic types are supported mostly for the fixed and float packages, so not for entities.
Kaleb Barrett
@ktbarrett
That's unfortunate. Is there a timeline on when features will be implemented? Is there some general plan available for GHDL's future development?
Unai Martinez-Corral
@umarcor
Not at all. All the known info is whatever you can get by watching the repo and inspecting the commits that Tristan pushes. There is no further roadmap other than that. There is https://github.com/ghdl/ghdl/wiki as very general guidelines, but most of the features are added by surprise.
The same applies to bug fixes. If Tristan replies to an issue saying he is looking at it, you might expect a fix in a few hours/days. Otherwise, it can take weeks or months.
I know that Tristan wants to support generics, external names and unconstrained arrays, which are the three most relevant missing VHDL 2008 features. However, those are complex, because the elaboration model is very different from previous revisions. He was sidetracked with synthesis 2-3 years ago, which I believe we are all very thankful about. Lately, there have been several comments about Rust, JIT (deprecating GCC), supporting merging multiple revisions, etc. I believe all of those are small steps towards being able to implement 2008 and 2019 features properly. Nonetheless, that won't be quick.
With regard to interfaces, as valuable as I think they are, I would expect them to be added after the main 2008 features are done. Interfaces are more useful with generic types and unconstrained arrays.
Unai Martinez-Corral
@umarcor
Other than that, as you might already know, these last months we've been talking about proposing some kind of "VHDL Foundation" in order to be able to handle funds/donations and hopefully hire Tristan partially (through an agreement with his current employer). That is the very main priority we all agree on: having an open source implementation of the language which can be used as a reference. Once GHDL supports 2008 and 2019, it might be feasible to implement upcoming LCS after they are approved but before the standard is released. Yet, that's something that no single human can do. We can neither ask nor allow Tristan to do that himself. We need to scale.
The main problem is who is going/willing to manage that. I am "a child" and I don't have the economical stability for doing that. Someone or a group of people needs to step ahead, which "the community" accepts as legit for making good use of whichever resources are gathered in the name of "improving the open source VHDL ecosystem (tooling, tests, libraries, learning/teaching material...)".
Note that the "VHDL Foundation" is just a concept. In practice, it would probably be some group in an existing foundation. However, it needs not to be IEEE, because there would be conflicts of interest.
Unai Martinez-Corral
@umarcor
In the VASG meeting before the last one, I commented this with @JimLewis and @Paebbels. I had been mostly thinking about it from a EU perspective, and discussing it with @LarsAsplund. However, EU funds might be limited to EU citizens. Jim might try to replicate the same in the US. It would be nice if you, @marlonjames, @GlenNicholls and others could somehow coordinate.
For now, I created a private repository in my namespace in GitLab, where I'm gathering all the references and ideas in this regard. It's a pot-pourri yet, and there might be some sensible references, so I don't want to make it public. However, I have no problem for sharing it with you or others who are interested.