3
0
Fork 0
forked from mirrors/nixpkgs
Commit graph

12 commits

Author SHA1 Message Date
Austin Seipp 25bea5054e
nextpnr: 2019.04.02 -> 2019.04.19
Signed-off-by: Austin Seipp <aseipp@pobox.com>
2019-04-22 14:27:44 -05:00
Austin Seipp 3b6c07c398
nextpnr: enable OpenMP support (for Eigen)
The new HEaP analytic placer for NextPNR uses Eigen for underlying
placement algorithms. Enabling -DUSE_OPENMP passes -fopenmp onto the
compiler, which Eigen picks up automatically with no extra work.

This should result in placer speedups for large designs, e.g. on ECP5
85k chips.

Signed-off-by: Austin Seipp <aseipp@pobox.com>
2019-04-15 00:17:54 -05:00
Ben Wolsieffer a1f3127f40 nextpnr: 2019.02.20 -> 2019.04.02 2019-04-14 23:48:14 -05:00
Austin Seipp b30ad4be96
nextpnr: 2019.01.08 -> 2019.02.20
Signed-off-by: Austin Seipp <aseipp@pobox.com>
2019-02-23 12:08:48 -06:00
Austin Seipp 3d36ea6a05 nextpnr: with GUI support, be sure to set QT_PLUGIN_PATH
This is to help QT find all the necessary plugin libraries at startup
time, otherwise it freaks out when run out of 'nix-env' environment or
run directly, e.g.  `./result/bin/nextpnr-ice40 --gui`. The reason for
this is that none of the traditional paths it looks for are available.
The workarounds for this are to otherwise:

  - Install e.g. into environment.systemPackages (presumably it will
then pick up QT libraries in /run/current-system/sw/lib/qt-*)

  - Install 'qtbase' into your user environment (qt will also try to
load dependent libraries out of ~/.nix-profile/lib/qt-*)

However, this QT_PLUGIN_PATH wrapping hack is used elsewhere in the
tree, presumably to mitigate these (poor) workarounds, especially for
non-NixOS users. There seems to be no downside to this.

With this, I have been able to run NextPNR's GUI on an Ubuntu 16.04
system using the 'nixGL' hack by simply running the resulting binary
from anywhere (though there seems to be some glitching artifacts in the
floorplan UI, I suspect this is due to a buggy OpenGL stack rather than
any direct problem with NextPNR or the QT libraries themselves).

This does not mark the GUI build as non-broken yet, though. That will
happen in the future after a bit more testing and splitting nextpnr into
separate minimal/GUI attributes.

Signed-off-by: Austin Seipp <aseipp@pobox.com>
2019-01-12 15:51:00 -06:00
Austin Seipp beaf69cee2 nextpnr: enable ECP5 P&R with Project Trellis
This requires an absurd, disgustingly gross hack in order to share the
build artifacts necessary for nextpnr to use trellis.

Signed-off-by: Austin Seipp <aseipp@pobox.com>
2019-01-08 19:15:24 -06:00
Austin Seipp 651679c257 nextpnr: fix version string output
Signed-off-by: Austin Seipp <aseipp@pobox.com>
2019-01-08 19:15:24 -06:00
Austin Seipp 412e02c784 nextpnr: disable broken GUI build for now
This didn't work remotely (on a server with Nvidia drivers) _or_ on a
local Intel machine with integrated graphics. I presumably messed
something up (a missing dependency), but I'm not sure where. We can fix
it later.

In the mean time, just disable this by hiding it behind a minimal flag.
As a bonus this reduces the closure size by about half, although it's
still surprisingly large (~300MB or so). Part of that is probably
Python, though.

When the GUI is reintroduced in a working manner, we can expose two
nextpnr attributes for the minimal non-GUI build, and the GUI build.
(Note that I have no plans of making Python optional, since it's
extremely valuable in general and much more lightweight than qtbase.)

Signed-off-by: Austin Seipp <aseipp@pobox.com>
2019-01-08 19:15:24 -06:00
Austin Seipp 1d36130ac1 nextnpr: 2018.12.29 -> 2019.01.08
Signed-off-by: Austin Seipp <aseipp@pobox.com>
2019-01-08 19:15:24 -06:00
Ben Gamari 15681afe9c nextpnr: 2018.10.17 -> 2018.12.29 2018-12-30 17:11:09 -05:00
Ben Gamari 8f64cedf17 nextpnr: 2018.08.09 -> 2018.10.17 2018-10-17 00:15:47 -04:00
Austin Seipp e7e77e108a nextpnr: init at 2018.08.09
Signed-off-by: Austin Seipp <aseipp@pobox.com>
2018-08-15 12:14:02 -05:00