Upstreaming effort

[jleightcap]

Including these packages in upstream nixpkgs comes with easier access and higher quality assurance.

Continuing discussion from ngi-nix/ngipkgs#7 (comment),

Was there anything else you needed in the toolchain-nix repo as part of the OpenXC7 toolchain, or would you say that merging this PR would complete the scope of work under Summer of Nix? We will open a separate thread (probably as an issue in toolchain-nix repo) about continuing to try and upstream packages outside of Summer of Nix.

(CC @albertchae)

[jleightcap]

Re: ngi-nix/ngipkgs#7 (comment), fasm is a good canidate for working into a useful state.

@hansfbaier would forking fasm into this GIthub organization as a place for active use in this toolchain, make sense?

[albertchae]

A list of the TODOs I'm aware of to make upstreaming possible:

• A specific yosys_0.17 or yosys_for_openxc7 has to be upstreamed to represent

  toolchain-nix/flake.nix

  Lines 52 to 68 in 2aecbef

  	yosys = (pkgs.yosys.overrideAttrs (prev: rec {
  	version = "0.17";
  	src = fetchFromGitHub {
  	owner = "yosyshq";
  	repo = "yosys";
  	rev = "${prev.pname}-${version}";
  	hash = "sha256-IjT+G3figWe32tTkIzv/RFjy0GBaNaZMQ1GA8mRHkio=";
  	};
  	doCheck = true;
  	passthru = {
  	inherit (prev) withPlugins;
  	allPlugins = { ghdl = yosys-ghdl; };
  	};
  	})).override { inherit abc-verifier; };

  . This needs to pull in an older version of abc-verifier that is compatible as well. OR we are able to get an updated yosys+abc-verifier that works with nextpnr-xilinx so that we don't have to use such an old package. @jleightcap believes the chances are slim of upstreaming with this requirement.
• nextpnr-xilinx can be upstreamed. @jleightcap opened a PR for that here nextpnr-xilinx: init at 0.5.0 NixOS/nixpkgs#257737
  • We should add @hansfbaier as a maintainer in a separate commit here so we aren't depending on that commit from the fasm PR
• fasm needs to be upstreamed.
  • @hansfbaier has a nixpkgs PR for this python310Packages.fasm: init at 0.0.2.post100 NixOS/nixpkgs#251333, but @jleightcap believes this may be using https://en.wikipedia.org/wiki/FASM (i.e. flat assembler) instead of fpga assembler
  • @jleightcap had a openXC7 PR for this fasm: init at 0.0.2 #6 which has been merged, but there were several issues
    • https://github.com/chipsalliance/fasm seems to be unmaintained, and the unmerged changes from Build system fixes chipsalliance/fasm#87 are necessary. It might make sense for OpenXC7 to fork fasm into its github org and apply the changes from Build system fixes chipsalliance/fasm#87, or find someone else to maintain it and apply those patches. It would probably be difficult to upstream to nixpkgs without this
    • This isn't strictly necessary, but fasm prefers to use ANTLR4 for performance. However, the ANTLR4 in nixpkgs now does not include the C++ runtime. @jleightcap has a WIP PR for packaging the ANTLR4 C++ runtime for this repo in libantlr4cpp: init at 4.13.1 #9, but this would require some modification to be upstreamed.

[hansfbaier]

@albertchae @jleightcap I forked fasm and applied the mentioned changes:
https://github.com/openXC7/fasm

[hansfbaier]

@albertchae @jleightcap I used to try it to build the fasm in the openxc7 flake.
Unfortunately the patches from the flake's default.nix do not apply anymore.

[jleightcap]

@albertchae @jleightcap I used to try it to build the fasm in the openxc7 flake. Unfortunately the patches from the flake's default.nix do not apply anymore.

Thanks for the report, after general Summer of Nix work wraps up I can sort out the now-obsolete AUR patches. That should be good progress towards upstreaming.