[new ports] Lattice FPGA tools

JohnnySorocil

Member

Reaction score: 6
Messages: 32

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@

Daemon
Developer

Reaction score: 1,378
Messages: 1,909

Here's some general feedback about all of the PRs after a quick look at them.
  1. Make USES+= => USES= (always ask yourself what am I appending too? If you append to an empty variable then do not use +=)
  2. Try to add LICENSE_FILE to the ports if there is a dedicated file (e.g. LICENSE, COPYING, ...) for the license in the distfile.
  3. Try to order variables as described in the handbook [0].
  4. 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.
  5. Do not strip things in post-stage use post-install instead.
  6. 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.
  7. 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.
  8. 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.
  9. Never ever use ${CP} when installing things. Always use one of the ${INSTALL_*} commands instead. They set the right file permissions, etc.
  10. USES+=${GMAKE} => USES=gmake
  11. 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/books/porters-handbook/makefile-distfiles.html#makefile-master_sites-github-ex5
 
OP
OP
JohnnySorocil

JohnnySorocil

Member

Reaction score: 6
Messages: 32

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
  1. abc
  2. arachne-pnr
  3. icestorm
  4. lattice-ice40-examples (meta port)
  5. lattice-ice40-examples-hx1k
  6. lattice-ice40-examples-hx8k
  7. lattice-ice40-tools (meta port)
  8. 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.
 

tobik@

Daemon
Developer

Reaction score: 1,378
Messages: 1,909

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.
 
OP
OP
JohnnySorocil

JohnnySorocil

Member

Reaction score: 6
Messages: 32

rigoletto@

Daemon
Developer

Reaction score: 974
Messages: 1,999

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

JohnnySorocil

Member

Reaction score: 6
Messages: 32

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

rigoletto@

Daemon
Developer

Reaction score: 974
Messages: 1,999

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

Beastie's Twin

Reaction score: 1,809
Messages: 6,318

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@

Daemon
Developer

Reaction score: 974
Messages: 1,999

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