3
0
Fork 0
forked from mirrors/nixpkgs
nixpkgs/pkgs/development/tools/icestorm/default.nix

65 lines
2.1 KiB
Nix
Raw Normal View History

icestorm: improve x86 build/runtime perf with pypy PyPy3 offers tremendous speedups for IceStorm tools written in Python, including tools used at compile-time to generate the chip databases, and runtime tools distributed to users, such as icebox_vlog. For example, on my ThreadRipper 1950X, build times for IceStorm consistently go from 2m30s -> 1m30s with this change, a 40% improvement, simply due to improvements in raw CPU efficiency. (This is also worsened by the fact the build is currently serial, but that can easily be fixed anyway.) On top of that, tools distributed to users are also now run using PyPy. Utilities such as icebox_vlog are useful for post-bitstream testing, for instance, and also are improved due to improved CPU efficiency as well. For example, when "decompiling" an ICE40 bitstream for HX8K devices, containing a synthesized copy of PicoRV32 (from the NextPNR demos), the runtime of icebox_vlog is cut from 25 seconds to 9 seconds consistently with this change alone. Normally, picking a Python interpreter outright for Python-based code is a "bad idea", but in the case of IceStorm it should be perfectly safe, and an excellent improvement for users. There are a few reasons for this: - IceStorm uses pure Python 3 and nothing else. There are no requirements for any 3rd party packages, which might cause annoying incompatibilities, and PyPy has historically shown very strong core Python compatibility. - IceStorm is NOT a set of Python libraries, it is a set of tools, some of which, coincidentally, are written in Python. It is (normally) bad form to fix libraries to certain interpreters versions if the reason strictly isn't "it doesn't work/isn't compatible". That is not the case here. These tools may later be used by other programs, such as NextPNR, but the Python interpreter is ultimately not that important in quesion for the user. In this sense, there is almost no downside to picking PyPy explicitly if it offers far better performance. (Point 2 is not actually strictly true; there are some distributed .py files that you can import from but they are basically just static classes that are imported by tools like nextpnr; this is expected.) Because of this, users should see very little change except better performance for IceStorm tools on their machines. Note that PyPy is not supported on aarch64 -- this only applies to x86_64 machines. Signed-off-by: Austin Seipp <aseipp@pobox.com>
2019-01-10 00:08:06 +00:00
{ stdenv, fetchFromGitHub
, pkgconfig, libftdi1
icestorm: improve x86 build/runtime perf with pypy PyPy3 offers tremendous speedups for IceStorm tools written in Python, including tools used at compile-time to generate the chip databases, and runtime tools distributed to users, such as icebox_vlog. For example, on my ThreadRipper 1950X, build times for IceStorm consistently go from 2m30s -> 1m30s with this change, a 40% improvement, simply due to improvements in raw CPU efficiency. (This is also worsened by the fact the build is currently serial, but that can easily be fixed anyway.) On top of that, tools distributed to users are also now run using PyPy. Utilities such as icebox_vlog are useful for post-bitstream testing, for instance, and also are improved due to improved CPU efficiency as well. For example, when "decompiling" an ICE40 bitstream for HX8K devices, containing a synthesized copy of PicoRV32 (from the NextPNR demos), the runtime of icebox_vlog is cut from 25 seconds to 9 seconds consistently with this change alone. Normally, picking a Python interpreter outright for Python-based code is a "bad idea", but in the case of IceStorm it should be perfectly safe, and an excellent improvement for users. There are a few reasons for this: - IceStorm uses pure Python 3 and nothing else. There are no requirements for any 3rd party packages, which might cause annoying incompatibilities, and PyPy has historically shown very strong core Python compatibility. - IceStorm is NOT a set of Python libraries, it is a set of tools, some of which, coincidentally, are written in Python. It is (normally) bad form to fix libraries to certain interpreters versions if the reason strictly isn't "it doesn't work/isn't compatible". That is not the case here. These tools may later be used by other programs, such as NextPNR, but the Python interpreter is ultimately not that important in quesion for the user. In this sense, there is almost no downside to picking PyPy explicitly if it offers far better performance. (Point 2 is not actually strictly true; there are some distributed .py files that you can import from but they are basically just static classes that are imported by tools like nextpnr; this is expected.) Because of this, users should see very little change except better performance for IceStorm tools on their machines. Note that PyPy is not supported on aarch64 -- this only applies to x86_64 machines. Signed-off-by: Austin Seipp <aseipp@pobox.com>
2019-01-10 00:08:06 +00:00
, python3, pypy3
2019-08-14 00:38:56 +01:00
# PyPy yields large improvements in build time and runtime performance,
# and IceStorm isn't intended to be used as a library other than by the
# nextpnr build process (which is also sped up by using PyPy), so we
# use it by default. See 18839e1 for more details.
2019-08-20 06:02:27 +01:00
, usePyPy ? stdenv.hostPlatform.system == "x86_64-linux"
2019-08-14 00:38:56 +01:00
}:
2015-12-29 16:29:44 +00:00
stdenv.mkDerivation rec {
2019-08-14 00:38:56 +01:00
pname = "icestorm";
2019-09-27 15:06:50 +01:00
version = "2019.09.13";
2019-08-14 00:38:56 +01:00
pythonPkg = if usePyPy then pypy3 else python3;
pythonInterp = pythonPkg.interpreter;
2015-12-29 16:29:44 +00:00
src = fetchFromGitHub {
owner = "cliffordwolf";
repo = "icestorm";
2019-09-27 15:06:50 +01:00
rev = "0ec00d892a91cc68e45479b46161f649caea2933";
sha256 = "1qlh99fafb7xga702k64fmc9m700nsddrfgcq4x8qn8fplsb64f1";
2015-12-29 16:29:44 +00:00
};
nativeBuildInputs = [ pkgconfig ];
buildInputs = [ pythonPkg libftdi1 ];
makeFlags = [ "PREFIX=$(out)" ];
2015-12-29 16:29:44 +00:00
enableParallelBuilding = true;
# fix icebox_vlog chipdb path. icestorm issue:
# https://github.com/cliffordwolf/icestorm/issues/125
icestorm: improve x86 build/runtime perf with pypy PyPy3 offers tremendous speedups for IceStorm tools written in Python, including tools used at compile-time to generate the chip databases, and runtime tools distributed to users, such as icebox_vlog. For example, on my ThreadRipper 1950X, build times for IceStorm consistently go from 2m30s -> 1m30s with this change, a 40% improvement, simply due to improvements in raw CPU efficiency. (This is also worsened by the fact the build is currently serial, but that can easily be fixed anyway.) On top of that, tools distributed to users are also now run using PyPy. Utilities such as icebox_vlog are useful for post-bitstream testing, for instance, and also are improved due to improved CPU efficiency as well. For example, when "decompiling" an ICE40 bitstream for HX8K devices, containing a synthesized copy of PicoRV32 (from the NextPNR demos), the runtime of icebox_vlog is cut from 25 seconds to 9 seconds consistently with this change alone. Normally, picking a Python interpreter outright for Python-based code is a "bad idea", but in the case of IceStorm it should be perfectly safe, and an excellent improvement for users. There are a few reasons for this: - IceStorm uses pure Python 3 and nothing else. There are no requirements for any 3rd party packages, which might cause annoying incompatibilities, and PyPy has historically shown very strong core Python compatibility. - IceStorm is NOT a set of Python libraries, it is a set of tools, some of which, coincidentally, are written in Python. It is (normally) bad form to fix libraries to certain interpreters versions if the reason strictly isn't "it doesn't work/isn't compatible". That is not the case here. These tools may later be used by other programs, such as NextPNR, but the Python interpreter is ultimately not that important in quesion for the user. In this sense, there is almost no downside to picking PyPy explicitly if it offers far better performance. (Point 2 is not actually strictly true; there are some distributed .py files that you can import from but they are basically just static classes that are imported by tools like nextpnr; this is expected.) Because of this, users should see very little change except better performance for IceStorm tools on their machines. Note that PyPy is not supported on aarch64 -- this only applies to x86_64 machines. Signed-off-by: Austin Seipp <aseipp@pobox.com>
2019-01-10 00:08:06 +00:00
#
# also, fix up the path to the chosen Python interpreter. for pypy-compatible
# platforms, it offers significant performance improvements.
patchPhase = ''
substituteInPlace ./icebox/icebox_vlog.py \
--replace /usr/local/share "$out/share"
icestorm: improve x86 build/runtime perf with pypy PyPy3 offers tremendous speedups for IceStorm tools written in Python, including tools used at compile-time to generate the chip databases, and runtime tools distributed to users, such as icebox_vlog. For example, on my ThreadRipper 1950X, build times for IceStorm consistently go from 2m30s -> 1m30s with this change, a 40% improvement, simply due to improvements in raw CPU efficiency. (This is also worsened by the fact the build is currently serial, but that can easily be fixed anyway.) On top of that, tools distributed to users are also now run using PyPy. Utilities such as icebox_vlog are useful for post-bitstream testing, for instance, and also are improved due to improved CPU efficiency as well. For example, when "decompiling" an ICE40 bitstream for HX8K devices, containing a synthesized copy of PicoRV32 (from the NextPNR demos), the runtime of icebox_vlog is cut from 25 seconds to 9 seconds consistently with this change alone. Normally, picking a Python interpreter outright for Python-based code is a "bad idea", but in the case of IceStorm it should be perfectly safe, and an excellent improvement for users. There are a few reasons for this: - IceStorm uses pure Python 3 and nothing else. There are no requirements for any 3rd party packages, which might cause annoying incompatibilities, and PyPy has historically shown very strong core Python compatibility. - IceStorm is NOT a set of Python libraries, it is a set of tools, some of which, coincidentally, are written in Python. It is (normally) bad form to fix libraries to certain interpreters versions if the reason strictly isn't "it doesn't work/isn't compatible". That is not the case here. These tools may later be used by other programs, such as NextPNR, but the Python interpreter is ultimately not that important in quesion for the user. In this sense, there is almost no downside to picking PyPy explicitly if it offers far better performance. (Point 2 is not actually strictly true; there are some distributed .py files that you can import from but they are basically just static classes that are imported by tools like nextpnr; this is expected.) Because of this, users should see very little change except better performance for IceStorm tools on their machines. Note that PyPy is not supported on aarch64 -- this only applies to x86_64 machines. Signed-off-by: Austin Seipp <aseipp@pobox.com>
2019-01-10 00:08:06 +00:00
for x in icefuzz/Makefile icebox/Makefile icetime/Makefile; do
substituteInPlace "$x" --replace python3 "${pythonInterp}"
done
for x in $(find . -type f -iname '*.py'); do
substituteInPlace "$x" \
--replace '/usr/bin/env python3' '${pythonInterp}'
icestorm: improve x86 build/runtime perf with pypy PyPy3 offers tremendous speedups for IceStorm tools written in Python, including tools used at compile-time to generate the chip databases, and runtime tools distributed to users, such as icebox_vlog. For example, on my ThreadRipper 1950X, build times for IceStorm consistently go from 2m30s -> 1m30s with this change, a 40% improvement, simply due to improvements in raw CPU efficiency. (This is also worsened by the fact the build is currently serial, but that can easily be fixed anyway.) On top of that, tools distributed to users are also now run using PyPy. Utilities such as icebox_vlog are useful for post-bitstream testing, for instance, and also are improved due to improved CPU efficiency as well. For example, when "decompiling" an ICE40 bitstream for HX8K devices, containing a synthesized copy of PicoRV32 (from the NextPNR demos), the runtime of icebox_vlog is cut from 25 seconds to 9 seconds consistently with this change alone. Normally, picking a Python interpreter outright for Python-based code is a "bad idea", but in the case of IceStorm it should be perfectly safe, and an excellent improvement for users. There are a few reasons for this: - IceStorm uses pure Python 3 and nothing else. There are no requirements for any 3rd party packages, which might cause annoying incompatibilities, and PyPy has historically shown very strong core Python compatibility. - IceStorm is NOT a set of Python libraries, it is a set of tools, some of which, coincidentally, are written in Python. It is (normally) bad form to fix libraries to certain interpreters versions if the reason strictly isn't "it doesn't work/isn't compatible". That is not the case here. These tools may later be used by other programs, such as NextPNR, but the Python interpreter is ultimately not that important in quesion for the user. In this sense, there is almost no downside to picking PyPy explicitly if it offers far better performance. (Point 2 is not actually strictly true; there are some distributed .py files that you can import from but they are basically just static classes that are imported by tools like nextpnr; this is expected.) Because of this, users should see very little change except better performance for IceStorm tools on their machines. Note that PyPy is not supported on aarch64 -- this only applies to x86_64 machines. Signed-off-by: Austin Seipp <aseipp@pobox.com>
2019-01-10 00:08:06 +00:00
done
'';
2015-12-29 16:29:44 +00:00
meta = {
description = "Documentation and tools for Lattice iCE40 FPGAs";
longDescription = ''
Project IceStorm aims at reverse engineering and
documenting the bitstream format of Lattice iCE40
FPGAs and providing simple tools for analyzing and
creating bitstream files.
'';
icestorm: improve x86 build/runtime perf with pypy PyPy3 offers tremendous speedups for IceStorm tools written in Python, including tools used at compile-time to generate the chip databases, and runtime tools distributed to users, such as icebox_vlog. For example, on my ThreadRipper 1950X, build times for IceStorm consistently go from 2m30s -> 1m30s with this change, a 40% improvement, simply due to improvements in raw CPU efficiency. (This is also worsened by the fact the build is currently serial, but that can easily be fixed anyway.) On top of that, tools distributed to users are also now run using PyPy. Utilities such as icebox_vlog are useful for post-bitstream testing, for instance, and also are improved due to improved CPU efficiency as well. For example, when "decompiling" an ICE40 bitstream for HX8K devices, containing a synthesized copy of PicoRV32 (from the NextPNR demos), the runtime of icebox_vlog is cut from 25 seconds to 9 seconds consistently with this change alone. Normally, picking a Python interpreter outright for Python-based code is a "bad idea", but in the case of IceStorm it should be perfectly safe, and an excellent improvement for users. There are a few reasons for this: - IceStorm uses pure Python 3 and nothing else. There are no requirements for any 3rd party packages, which might cause annoying incompatibilities, and PyPy has historically shown very strong core Python compatibility. - IceStorm is NOT a set of Python libraries, it is a set of tools, some of which, coincidentally, are written in Python. It is (normally) bad form to fix libraries to certain interpreters versions if the reason strictly isn't "it doesn't work/isn't compatible". That is not the case here. These tools may later be used by other programs, such as NextPNR, but the Python interpreter is ultimately not that important in quesion for the user. In this sense, there is almost no downside to picking PyPy explicitly if it offers far better performance. (Point 2 is not actually strictly true; there are some distributed .py files that you can import from but they are basically just static classes that are imported by tools like nextpnr; this is expected.) Because of this, users should see very little change except better performance for IceStorm tools on their machines. Note that PyPy is not supported on aarch64 -- this only applies to x86_64 machines. Signed-off-by: Austin Seipp <aseipp@pobox.com>
2019-01-10 00:08:06 +00:00
homepage = http://www.clifford.at/icestorm/;
license = stdenv.lib.licenses.isc;
2019-08-20 06:02:27 +01:00
maintainers = with stdenv.lib.maintainers; [ shell thoughtpolice emily ];
platforms = stdenv.lib.platforms.all;
2015-12-29 16:29:44 +00:00
};
}