Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add FPGA tools nMigen and Glasgow #67827

Merged
merged 8 commits into from Sep 1, 2019
Merged

Add FPGA tools nMigen and Glasgow #67827

merged 8 commits into from Sep 1, 2019

Conversation

emilazy
Copy link
Member

@emilazy emilazy commented Aug 31, 2019 •
edited

Motivation for this change

This PR adds two pieces of FPGA-related software (and also bumps/fixes some of the EDA tools as required):

nMigen

nMigen is the new version of M-Labs' popular Python-based hardware description language and build system Migen (used in e.g. MiSoC, LiteX, ARTIQ, Milkymist, HDMI2USB...). Although it hasn't received an official stable release yet, it has a compatibility layer for the original Migen and it's already achieved some serious adoption through e.g. Glasgow (described below) and Minerva (a free-gateware RISC-V core), and it's rapidly approaching stabilization. It integrates with the FOSS EDA tools already in nixpkgs ((symbi)yosys, icestorm, trellis, nextpnr) as well as supporting proprietary vendor toolchains.

Glasgow

Glasgow is an FPGA-based adaptable digital interface multitool/"Scots Army Knife for electronics" powered by nMigen that should be in mass production soon. It uses Python software on the host to synthesize, program and communicate with the FPGA on the fly, and communicates with the on-board microcontroller using libfx2 (which provides both the Python module fx2 and fx2tool(1), an end-user bootloader recovery program). It's also intended to serve as a Python framework for development of custom applets.

I'm due to receive a preproduction model soon, so I spent the time to get it packaged for Nix. Glasgow has also not seen a proper release yet, but devices are already in the wild and the plan is for it to be updated in a rolling-release fashion from git commits, so this shouldn't be a major issue.

(These projects aren't mine and I've only made a few contributions to both so far, so hopefully this isn't taken as spamminess but rather rationales for inclusion ^^; I've talked with @whitequark and she's fine to see them packaged as-is.)

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.
Notify maintainers

cc @thoughtpolice for the yosys/nextpnr changes
cc @FRidh for Python assistance – is there a better way to handle the default checkPhase for Python packages unconditionally running the build_ext step, even if the build has already been done at an earlier stage?

@emilazy emilazy requested a review from FRidh as a code owner August 31, 2019 13:08
@ofborg ofborg bot requested a review from thoughtpolice August 31, 2019 13:24
@ofborg ofborg bot requested a review from q3k August 31, 2019 14:24
@emilazy emilazy mentioned this pull request Aug 31, 2019
Merged
q3k
q3k approved these changes Aug 31, 2019
View reviewed changes
Copy link
Member

@q3k q3k left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work!

pkgs/development/compilers/yosys/default.nix Outdated Show resolved Hide resolved
@ofborg ofborg bot requested a review from q3k August 31, 2019 21:01
thoughtpolice
thoughtpolice approved these changes Sep 1, 2019
View reviewed changes
Copy link
Member

@thoughtpolice thoughtpolice left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All the changes here look great as usual @emilazy, thank you! (though I haven't tested them all myself).

Would you mind doing one thing: could we just flatten commit e9e73ab6ed321c33e3932b1f9c37519b86fde4b5 ("nextpnr: fix build on clang/macOS") directly into ef19eba10e0b79e764dad6ea5a856d0114345058 ("nextpnr: 2019.08.21 -> 2019.08.31") so that the update and fix are all-in-one? (I realize not everyone likes rebasing like this, but generally I prefer to avoid incurring commits for things that only strictly fix build breaks introduced by something else -- it makes git bisect for example more annoying to use.)

But the actual changes themselves look fine. So let's go ahead and try to start getting borg to cycle things.

pkgs/applications/science/logic/symbiyosys/default.nix
@@ -26,6 +26,8 @@ stdenv.mkDerivation rec {
substituteInPlace $out/bin/sby \
--replace "##yosys-sys-path##" \
"sys.path += [p + \"/share/yosys/python3/\" for p in [\"$out\", \"${yosys}\"]]"
substituteInPlace $out/share/yosys/python3/sby_core.py \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sigh. I'm thinking we should really just patch the SymbiYosys build system at this point to make these parameters optional or more robust for discovery. (We can work something out and submit a PR to Clifford later, though)

@thoughtpolice
Copy link
Member

@GrahamcOfBorg build libfx2 glasgow

@emilazy
Copy link
Member Author

emilazy commented Sep 1, 2019

Fixed-output derivations are the bane of my existence... should be fixed now, the long build is progressing locally. Squashed the nextpnr commits too and let sdcc build on Darwin.

@thoughtpolice
Copy link
Member

Hurrah, was just about to ask about that.

@GrahamcOfBorg build libfx2 glasgow

@thoughtpolice thoughtpolice self-assigned this Sep 1, 2019
@thoughtpolice
Copy link
Member

The build succeeds on Linux, but fails on Darwin due to nextpnr, which hasn't been working: https://hydra.nixos.org/job/nixpkgs/trunk/nextpnr.x86_64-darwin

We might have missed that before with a builder timeout or something in previous PRs. Oh well, not a huge deal.

I think we should just merge this otherwise. sdcc on Darwin went through too, and the fixes clearly work on Linux except for the fact the builder was a rather underpowered x86 machine, I guess.

I'll follow with a commit to restrict nextpnr on Darwin for now, I suppose.

@thoughtpolice thoughtpolice merged commit f933335 into NixOS:master Sep 1, 2019
@risicle
Copy link
Contributor

risicle commented Sep 1, 2019

I definitely had nextpnr building on macos 10.13...

@thoughtpolice thoughtpolice mentioned this pull request Sep 1, 2019
Closed
@thoughtpolice
Copy link
Member

#67898

@emilazy emilazy deleted the add-nmigen-and-glasgow branch September 2, 2019 00:34
@emilazy emilazy mentioned this pull request Feb 10, 2020
Merged
10 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@whitequark whitequark whitequark left review comments

@risicle risicle risicle left review comments

@FRidh FRidh Awaiting requested review from FRidh

@q3k q3k Awaiting requested review from q3k

@thoughtpolice thoughtpolice Awaiting requested review from thoughtpolice

@yorickvP yorickvP Awaiting requested review from yorickvP

@bjornfor bjornfor Awaiting requested review from bjornfor

Assignees

@thoughtpolice thoughtpolice

Labels
6.topic: python 8.has: package (new) 10.rebuild-darwin: 11-100 10.rebuild-linux: 11-100 11.by: package-maintainer
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
5 participants
@emilazy @thoughtpolice @risicle @whitequark @q3k