# [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

```
${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

```
${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

```
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

```
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.


----------

