[new ports] Lattice FPGA tools

JohnnySorocil · Apr 18, 2018

Hi all

I have ported tools for converting Verilog to the Lattice iCE40 FPGA bitstream. Examples for Olimex open hardware FPGA boards are also included.
PRs are:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226711
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227590
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227591
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227592
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227593
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227594
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227595

Ports files are also available here:
https://github.com/thefallenidealist/ports_FreeBSD

Those are my first FreeBSD ports, so if someone can take a look and give comments or commit them if they are OK.
They are tested and with them, $EDITOR and shell verilog files can be transformed to working blinky on FPGA hardware

tobik@ · Apr 28, 2018

Here's some general feedback about all of the PRs after a quick look at them.

Make USES+= => USES= (always ask yourself what am I appending too? If you append to an empty variable then do not use +=)
Try to add LICENSE_FILE to the ports if there is a dedicated file (e.g. LICENSE, COPYING, ...) for the license in the distfile.
Try to order variables as described in the handbook [0].
Do not add Python to BUILD_DEPENDS yourself. Use USES=python:3.6+,build instead. This makes sure that the proper variables like PYTHON3_DEFAULT are actually set to the right values.
Do not strip things in post-stage use post-install instead.
For snapshots and when using GH_TAGNAME try to use a longer commit hash than 7 chars. Collisions happen otherwise. I always just use the full commit hash. Also prefix PORTVERSION with a 'g' (or any other char) instead of just a date i.e. PORTVERSION=g20180428 so that we can avoid bumping PORTEPOCH in case upstream decides to do a proper release at some point with a version that is less than the date according to pkg version -t.

In some cases upstream seems to already have releases, but you seem to want to have something slightly newer. In those cases please use the procedure at [1] to derive a proper PORTVERSION instead.
Instead of patching ports to lookup /proc/curproc/file patch them to lookup the kern.proc.pathname sysctl instead. Use of procfs(5) can be avoided in simple cases like this.
Things like
Code:
```
${MAKE_CMD} -C ${WRKSRC}/demo/ice40hx1k-evb
```
need to be avoided because they ignore MAKE_ENV, MAKE_ARGS, MAKE_JOBS, etc. set by the ports framework. Use
Code:
```
${DO_MAKE_BUILD} -C ${WRKSRC}/demo/ice40hx1k-evb
```
instead.
Never ever use ${CP} when installing things. Always use one of the ${INSTALL_*} commands instead. They set the right file permissions, etc.
USES+=${GMAKE} => USES=gmake

Stuff like this

Code:

EXAMPLES_NAME=    lattice-ice40-olimex
EXAMPLESDIR=    ${PREFIX}/share/examples/
...
do-install:
    @${MKDIR} ${STAGEDIR}${PREFIX}/share/examples/${EXAMPLES_NAME}
    @${CP} ${WRKSRC}/demo/ice40hx8k-evb/example.v    ${STAGEDIR}${PREFIX}/share/examples/${EXAMPLES_NAME}/ice40hx8k-blinky.v

doesn't make much sense. Why not

Code:

EXAMPLESDIR=    ${PREFIX}/share/examples/lattice-ice40-olimex
...
do-install:
    @${MKDIR} ${STAGEDIR}${EXAMPLESDIR}
    ${INSTALL_DATA} ${WRKSRC}/demo/ice40hx8k-evb/example.v  ${STAGEDIR}${EXAMPLESDIR}/ice40hx8k-blinky.v

[0] https://www.freebsd.org/doc/en/books/porters-handbook/porting-order.html
[1] https://www.freebsd.org/doc/en/book...stfiles.html#makefile-master_sites-github-ex5

JohnnySorocil · May 29, 2018

Hey, thank you very much for looking into the ports.

New port is added - abc. It is dependency for yosys.

I think that all changes suggested in your post have been made.
Can you please take another look into relevant ports on my Github:
https://github.com/thefallenidealist/ports_FreeBSD

abc
arachne-pnr
icestorm
lattice-ice40-examples (meta port)
lattice-ice40-examples-hx1k
lattice-ice40-examples-hx8k
lattice-ice40-tools (meta port)
yosys

Please note that arachne-pnr will be updated to use sysctl instead of procfs once this is merged upstream:
https://github.com/cseed/arachne-pnr/pull/119

All ports are tested with portlint -A and poudriere.
Only warning is for BSD license for abc. I'm not sure what type of BSD license is this:
https://github.com/berkeley-abc/abc/blob/master/copyright.txt
I have asked the author, but for now there is no reply.

If they are OK then I'll push it to FreeBSD bug reports page. If you prefer I can push it now on bug reports page so you can review it there.

rigoletto@ · May 29, 2018

I feel you should post those in the Phab.

tobik@ · May 31, 2018

JohnnySorocil said:
If they are OK then I'll push it to FreeBSD bug reports page. If you prefer I can push it now on bug reports page so you can review it there.

Hmm the indentation seems to be off in a few ports (tab width needs to be set to 8 in your editor) and I'm not sure about the metaports. Other than that it looks a lot better!

Opening a review on Phabricator is a good next step. It's probably best to put them all in one review. See https://wiki.freebsd.org/Phabricator on how to do that. Leave the reviewers field empty when you submit it so that others can give their input too.

JohnnySorocil · May 31, 2018

tobik@ said:
Hmm the indentation seems to be off in a few ports (tab width needs to be set to 8 in your editor) and I'm not sure about the metaports.

Yes, you are right, I forget about setting tab to 8. Patched and pushed to my GitHub.

tobik@ said:
Opening a review on Phabricator is a good next step. It's probably best to put them all in one review.

Here it is:
https://reviews.freebsd.org/D15632

JohnnySorocil · Jun 7, 2018

Mainstreamed into ports with commits:
rP471841 rP471842 rP471844 rP471846 rP471847 rP471848

JohnnySorocil · Oct 22, 2018

Can somebody please review an update to that programs?
https://reviews.freebsd.org/D17642

rigoletto@ · Oct 22, 2018

If you have PRs opened add the numbers to the revision summary, like: PR: xxxxx.

JohnnySorocil · Oct 23, 2018

Do I need to open PRs?
They were open for initial commit and I was told that Phabricator is better solution.

rigoletto@ · Oct 23, 2018

Not necessarily if you are the maintainer. The reason I told about the PRs are:

1. if there is a PR it is good to point the number in the phab review to make the reviewer aware of the PR (and close it later).
2. if you are not the maintainer the bug tracker is the official way to report bugs (including updates etc.), and it is from the date of the PR that the maintainer timeout count, unless the maintainer appear on the review (but many people do not use the phab, specially non FreeBSD developers).

Also, tobik@ requested you to remove the GH_TAGNAME from the 'yosys' port because it has a tag number for that particular commit. So, that variable should not be used in there.

kpa · Oct 23, 2018

Rigoletto said:
Also, tobik@ requested you to remove the GH_TAGNAME from the 'yosys' port because it has a tag number for that particular commit. So, that variable should not be used in there.

Where do you see this above? Removing GH_TAGNAME wouldn't make sense at all since the build of a particular port version has to be repeatable forever and for that you must use an exact commit as the source code, otherwise changes to the branch used will cause it to become out of sync with the port Makefile and other files of the port.

rigoletto@ · Oct 23, 2018

kpa I was talking about a comment in the Phabricator. When the port has a tag number matching the target commit hash, GH_TAGNAME should not be used.

Anyway, in regards to git there is no assurance the build will be repeatable using the tag number, because upstream is free to use git rebase/reset and re-use the same tag number. So, you will end up with a broken port anyway, but instead of having to re-create just the distfile you would also need to change the GH_TAGNAME while keeping the same version.

This is one of the reasons git is not considered a VCS by several people. Also HERE.