Page MenuHomeSolus

initial inclusion of iverilog, fixes T4393
ClosedPublic

Authored by ThanosApostolou on Mar 17 2018, 8:27 AM.

Details

Summary

Initial inclusion of iverilog. Fixes T4393

Test Plan

Diff Detail

Repository
R4191 iverilog
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

ThanosApostolou requested review of this revision.Mar 17 2018, 8:27 AM

Additional notes:

  • I've set version at 10.2 instead of the upstream 10_2 because it seemed better, so tell me if I need to change it
  • For some weird reason, %make_install gives error while make install DESTDIR=%installroot% works properly.
ThanosApostolou retitled this revision from initial inclusion of verilog, fixes T4393 to initial inclusion of iverilog, fixes T4393.Mar 17 2018, 8:37 AM
ThanosApostolou edited the summary of this revision. (Show Details)

Note that there are now two diffs for this package D2557

%make_install -j1 should resolve the install issue

Also shouldn't ship the .a file unless it is needed for a purpose.

I suppose between the two patches should take the best parts to be merged to the repo.

use %make_install -j1

@sunnyflunk aaa the other diff didn't mention the task, so I didn't see it. If you want close this and accept the other one, it's fine by me.

Both fedora and arch (https://src.fedoraproject.org/rpms/iverilog/blob/master/f/iverilog.spec, https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/iverilog) keep the .a files. I don't see any .so files included so I guess they are needed for the program to work properly.

I see that the other person has set component as office.scientific but I've set it as programming (since it's technically a compiler), but maybe office.scientific is better. What do you think it's more suitable?

I was going to test it further with some verilog simulations and after the glibc upgrade but submitted D2557 accidentally.
My primary concern is whether those .a libs should be split into the -devel package. Since vpp compiles verilog source into an executable, it's possible that those .a files are need for this compile process.

If @ThanosApostolou is able to test it please go ahead and ignore mine, because I probably will only come back next weekend.

Btw, iverilog's vpp program can use the readline library (as seen from configure.in). Since readline is not in the base image, we should list it as a builddep.

ThanosApostolou updated this revision to Diff 6231.EditedMar 17 2018, 2:00 PM

Move /usr/include headers and /usr/lib64/*.a files into iverilog package since it's built that way in both Fedora and Ubuntu (https://packages.ubuntu.com/artful/amd64/iverilog/filelist).
Also in fedora (https://src.fedoraproject.org/rpms/iverilog/blob/master/f/iverilog.spec) which normally has a strick rule for separate devel patterns, has a comment which states that headers are meant to be used by the user.

@hashhsah readline is part of system.base and readline-devel is part of system.devel so unless I'm missing something it shouldn't be added. I've only tested it with the getting started tutorial, but I will keep using it and testing it even after the initial inclusion since I need it for my university in this semester. Do you think that office.scientific is a more suitable component than programming?

@ThanosApostolou

Do you think that office.scientific is a more suitable component than programming?

On one hand verilog is a programming language, on the other it is almost exclusively used for electronics hardware design.
I believe iverilog should fall in the same component as kicad and klayout. There is no engineering component in solus, hence office.scientific.

Move /usr/include headers and /usr/lib64/*.a

I read further, these headers and .a libraries are for compiling VPI/PLI plugins for iverilog. Since most of my projects actually uses VPI/PLI plugins, I'd say it constitutes normal usage, instead of development.
Therefore I concur that these files should be packaged in iverilog, not iverilog-devel.

@ThanosApostolou

Do you think that office.scientific is a more suitable component than programming?

On one hand verilog is a programming language, on the other it is almost exclusively used for electronics hardware design.
I believe iverilog should fall in the same component as kicad and klayout. There is no engineering component in solus, hence office.scientific.

Move /usr/include headers and /usr/lib64/*.a

I read further, these headers and .a libraries are for compiling VPI/PLI plugins for iverilog. Since most of my projects actually uses VPI/PLI plugins, I'd say it constitutes normal usage, instead of development.
Therefore I concur that these files should be packaged in iverilog, not iverilog-devel.

I agree with office.scientific for the component

As for static libraries, are those plugins compiled as separate packages or at run-time via iverilog itself? If yes, I agree they can stay in. If no, they belong in -devel

change component from programming to office.scientific

As for static libraries, are those plugins compiled as separate packages or at run-time via iverilog itself? If yes, I agree they can stay in. If no, they belong in -devel

Short answer: the static library and the plugins are consumed within the iverilog ecosystem, and are useless to other packages.

Long answer:

Example usage: https://github.com/myhdl/myhdl/blob/master/cosimulation/icarus/Makefile

One runs the following command, and iverilog-vpi will call gcc to compile (using the above mentioned .h files) and link (to the .a files) behind the scene, and produce the .vpi plugin.

iverilog-vpi myhdl.c myhdl_table.c

After that, one runs simulation with the vpp program (part of iverilog), which loads the .vpi plugins. Typical use of .vpi plugins are input/output in custom data format, piping to external programs.

Happy to report that I tested @ThanosApostolou's diff after updating to the latest stable. Both verilog simulation and VPI plugin building work well.

ThanosApostolou edited the summary of this revision. (Show Details)Mar 23 2018, 11:17 AM

@hashhsah if you want me to accept @ThanosApostolou 's diff, mind letting me know by closing yours? D2557: initial release

DataDrake accepted this revision.Mar 24 2018, 4:37 PM

LGTM. Thanks!

This revision is now accepted and ready to land.Mar 24 2018, 4:37 PM
This revision was automatically updated to reflect the committed changes.