Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 679340 - sci-electronics/ghdl - an open-source simulator for the VHDL language
Summary: sci-electronics/ghdl - an open-source simulator for the VHDL language
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Default Assignee for New Packages
Depends on:
Reported: 2019-03-03 16:46 UTC by Alex Orange
Modified: 2021-11-14 12:13 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---

ghdl-0.36.ebuild (ghdl-0.36.ebuild,470 bytes, text/plain)
2019-03-03 22:17 UTC, Alex Orange
ghdl_configuration.patch (ghdl_configuration.patch,4.27 KB, patch)
2019-03-03 22:18 UTC, Alex Orange
Details | Diff
Test case (test2.vhdl,220 bytes, text/x-vhdl)
2019-03-03 22:19 UTC, Alex Orange
New version of ghdl-0.36 ebuild (ghdl-0.36.ebuild,914 bytes, text/plain)
2019-03-11 16:37 UTC, Alex Orange
Updated ebuild for 0.37.0 (ghdl-0.37.0.ebuild,923 bytes, text/plain)
2020-11-03 19:09 UTC, Alex Orange
Patch needed for the 0.37.0 ebuild (in files dir) (ghdl_0.37.0_configuration.patch,3.96 KB, patch)
2020-11-03 19:09 UTC, Alex Orange
Details | Diff
Oops, didn't test the install phase. This one tested, and ghdl itself tested after. (ghdl_0.37.0_configuration.patch,3.96 KB, patch)
2020-11-03 19:20 UTC, Alex Orange
Details | Diff
ghdl v1.0.0 ebuild (ghdl-1.0.0.ebuild,1.06 KB, text/plain)
2021-08-29 21:24 UTC, Alex Orange
Configuration patch for ghdl v1.0.0 (ghdl_1.0.0_configuration.patch,4.31 KB, patch)
2021-08-29 21:24 UTC, Alex Orange
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Orange 2019-03-03 16:46:23 UTC
I'd like to ask that ghdl be brought back (or at least get the discussion going). ghdl can be built with gnat-gpl and the modern versions of ghdl don't seem to require any out of date packages (I'm building on stock gentoo). Also, the llvm version provides very nice speed without all the complexity of the gcc build process.

Long story short, what would it take to bring ghdl back? To be clear I'm suggesting that I provide a stand alone ebuild that works without requiring any other packages and providing the upkeep.
Comment 1 Jeroen Roovers (RETIRED) gentoo-dev 2019-03-03 20:38:12 UTC
Comment 2 Alex Orange 2019-03-03 22:17:09 UTC
Here's my first run at an ebuild. Basically it (kludge) fixes the cooky configuration system that ghdl uses to handle things like lib dirs and the like. This is the llvm configuration. I'll probably add the other two in the future.

I could use some help testing the dependencies. Is there an automated system for this?
Comment 3 Alex Orange 2019-03-03 22:17:51 UTC
Created attachment 567692 [details]
Comment 4 Alex Orange 2019-03-03 22:18:21 UTC
Created attachment 567694 [details, diff]
Comment 5 Alex Orange 2019-03-03 22:19:31 UTC
Created attachment 567696 [details]
Test case

Test by:
$ ghdl -a test2.vhdl
$ ghdl -e hello_world
$ ghdl -r hello_world
Hello world!
Comment 6 Alex Orange 2019-03-11 16:37:29 UTC
Created attachment 568586 [details]
New version of ghdl-0.36 ebuild

Fixed ebuild for those who haven't misconfigured their gcc version to be the gnat-gpl version (oops). Now with USE flags for gnat version, used gprbuild-2017-r1.ebuild as a template.
Comment 7 Alex Orange 2019-04-07 18:57:55 UTC
Poke. Is there anything I can do to further push this along? This is a very useful tool that I think a lot of people use. It's been updated to make the build process be much more friendly. It still needs some modification as indicated in the patch I attached, but it's not at all as involved as it used to be. Can we get this back in portage please?
Comment 8 Carlo 2020-08-20 16:38:01 UTC
hi Alex Orange, thank you for your effort!
I massively use ghdl for my HDL designs and I do appreciate your attempt to resurrect the ebuild.

I am currently using ghdl-v0.29 on an old stage4-i686-2014.
Yesterday I downloaded a fresh new Gentoo-stage3 and start emerging things.

I have just tried your ebuild, I got this error.

>>> Emerging (1 of 1) sci-electronics/ghdl-0.36::gentoo
 * ghdl-0.36.tar.gz BLAKE2B SHA512 size ;-) ...                                                                   [ ok ]
>>> Unpacking source...
>>> Unpacking ghdl-0.36.tar.gz to /var/tmp/portage/sci-electronics/ghdl-0.36/work
>>> Source unpacked in /var/tmp/portage/sci-electronics/ghdl-0.36/work
>>> Preparing source in /var/tmp/portage/sci-electronics/ghdl-0.36/work/ghdl-0.36 ...
 * Applying ghdl_configuration.patch ...                                                                          [ ok ]
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/sci-electronics/ghdl-0.36/work/ghdl-0.36 ...
./configure --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib --with-llvm-config
Use full IEEE library
Build machine is: i686-pc-linux-gnu
Unhandled version llvm 10.0.0
Comment 9 Carlo 2020-08-21 21:52:19 UTC
solved it in a different way

I forced an old gcc v4.9.4 as CC.
It got installed in /opt/gccada-4.9.4 and redirected as "main compiler".

This compiler is an "ada bootstrapper" and it's compiled with enable-languages="c,c++,ada", thus is able to compile ada stuff.

So I then simplified the ghdl-0.3*.ebuild and used gccada-4.9.4 to compile ghdl.

It worked for ghdl-0.35, 0.36 and 0.37

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
sci-electronics/ghdl v0.35 succesfully compiled with gccada-4.9.4
sci-electronics/ghdl v0.36 succesfully compiled with gccada-4.9.4
sci-electronics/ghdl v0.37 succesfully compiled with gccada-4.9.4
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  


DESCRIPTION="VHDL 2008/93/87 simulator"



        ./configure --prefix=/usr

Comment 10 Alex Orange 2020-11-03 19:06:50 UTC
Sorry, did *not* mean to abandon this. I've added a few more packages that I think are setup a bit more how they should be (at least somewhat parameterized for different ADA and LLVM packages).

Again, if someone who understands ebuild packaging could give some pointers I'd be happy to improve these, definitely still want these packages added though!
Comment 11 Alex Orange 2020-11-03 19:09:18 UTC
Created attachment 669935 [details]
Updated ebuild for 0.37.0

Updated ebuild for v0.37.0 and (I believe) improved it significantly irrespective of ghdl version (have yet to backport improvements to 0.36).
Comment 12 Alex Orange 2020-11-03 19:09:43 UTC
Created attachment 669938 [details, diff]
Patch needed for the 0.37.0 ebuild (in files dir)
Comment 13 Alex Orange 2020-11-03 19:20:54 UTC
Created attachment 669947 [details, diff]
Oops, didn't test the install phase. This one tested, and ghdl itself tested after.
Comment 14 Alain Zscheile 2021-03-08 02:56:11 UTC
I just want to throw in that I also made an ebuild for ghdl-0.37 in the past, as I needed it...
Comment 15 Mark 2021-03-27 04:14:17 UTC
Just a note, the tarball gets saved without the package name: 

    2021-03-26 21:35:01 (4.66 MB/s) - 
    '/usr/portage/distfiles/v0.37.0.tar.gz.__download__' saved [4775092]

Grepping for SRC_URI.*github in /usr/portage, it appears the solution is to change the line like so:

    +SRC_URI="${PV}.tar.gz -> ${P}.tar.gz"

I added a hunk to the patch, modifying configure to accept LLVM 11.1 (the version I have). Essentially
    @@ -279,6 +307,7 @@
    +       check_version 11.1 $llvm_version ||

Back in the ebuild, I got rid of the llvm version restrictions and enabled synthesis, though not in a kosher manner.

With these modifications it builds. In addition, I grabbed a few test files from the ghdl source and it seems to function correctly.
Comment 16 Alex Orange 2021-08-29 20:36:19 UTC
Mark, thanks for pointing that out. I've added that and bumped this to the next version (with some patch tweaking).

To whomever is in the sci-electronics list:
1. Is there anything against putting this back in?
2. I would be happy to be the maintainer for this.
3. Assuming 1&2 are good, what would be the process of doing this? The version I have for 1.0.0 also requires two other dev-python ebuilds for features related to testing.
Comment 17 Alex Orange 2021-08-29 21:24:17 UTC
Created attachment 736729 [details]
ghdl v1.0.0 ebuild
Comment 18 Alex Orange 2021-08-29 21:24:40 UTC
Created attachment 736732 [details, diff]
Configuration patch for ghdl v1.0.0
Comment 19 Steve Arnold archtester gentoo-dev 2021-10-28 19:06:59 UTC
I seem to have a recurring "need" for fpga/verification tools, so I've added a modified version of this to the new/clean-ish embedded-overlay for now. I think we probably *do* want this in the tree, so "we" might as well get it cleaned up a little more first (and by "we" I mean mostly Alex Orange ;)

Please fork and test out the tools, make a PR, dance a jig, and let me know what you think.
Comment 20 Steve Arnold archtester gentoo-dev 2021-11-03 21:00:08 UTC
GHDL 1.0.0 (plus the deps in the overlay) can run all the tests now, but the newer stuff throws in even more python deps (and thus needs more work). I'll take a look at splitting out the pyGHDL package for now.
Comment 21 Fabio Rossi 2021-11-14 12:13:58 UTC
(In reply to Steve Arnold from comment #20)
> GHDL 1.0.0 (plus the deps in the overlay) can run all the tests now, but the
> newer stuff throws in even more python deps (and thus needs more work). I'll
> take a look at splitting out the pyGHDL package for now.

Regarding the tests, upstream didn't intend to be run when the package is not installed yet so this leads to a failure during first installation, see also:

I managed to implement a workaround of the issue with the following src_test() for version 1.0.0, now we can run successfully all of tests:

src_test() {
	# testsuite assumes an already installed instance, not from build dir
	mkdir "${S}"/{include,lib}
	ln -s "${S}"/src/grt/vpi_user.h include/
	ln -s "${S}"/ lib/

	GHDL_PREFIX="${S}/ghdl" default

I agree that they take a lot of time but tests are not executed by default on Gentoo so I'd prefer to avoid running only a subset as proposed in the embedded-overlay