GNU bug report logs - #78233
[PATCH 0/2 electronics-team] Upgrade nextpnr.

Previous Next

Full log

View this message in rfc822 format

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Cayetano Santos <csantosb <at> inventati.org>
Cc: 78233-done <at> debbugs.gnu.org, Gabriel Wicki <gabriel <at> erlikon.ch>, Ekaitz Zarraga <ekaitz <at> elenq.tech>
Subject: [bug#78233] [PATCH 2/2] gnu: nextpnr-ice40: Update to 0.8.
Date: Mon, 12 May 2025 20:54:11 +0900

Hi Cayetano,

Cayetano Santos <csantosb <at> inventati.org> writes:

>>lun. 12 mai 2025 at 16:14, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> wrote:
>
>> Thanks for V2, I've used it as the base of nextpnr-ice40 package, for
>> which I've also added patches, as mentioned previously.
>
> Thanks a lot for this ! I’m sure that providing a whole pipeline for fpga
> development (yosys+nextpnr+fpgaloader) in Guix is a rewarding effort.
>
>> By first updating nextpnr-ice40 to v0.8 and related changes, and later
>> renaming it to nextpnr with few adjustments needed, the commit history
>> is as clear as it can be. Please have a look/test to make sure
>> everything still works as intended.
>
> Well, I’m afraid I was not clear enough about it, but the whole original idea
> was to get a different package per device:
>
>   - nextpnr (not public) :: generic package
>   - nextpnr-ice40 (public, inherits from nextpnr) :: icestorm backend
>   - nextpnr-ecp5 (public, inherits from nextpnr) :: prjtrellis backend
>   - nextpnr-generic (public, inherits from nextpnr) :: no backend
>   - nextpnr-himbaechel-gowin (public, inherits from nextpnr) ::
>   - nextpnr-himbaechel-ng-ultra (public, inherits from nextpnr) ::
>     prjbeyond-db backend
>   - nextpnr-nexus :: ...
>   - etc.
>
> You can see the overall concept in my testing playground [0].

I see.  That's neat, but I think I'd rather try a single 'nextpnr'
package that does it all first, and complicate later if we find it
becomes unpractical.  The benefits:

1. all the executables share the same library, so space and compute
wise, it makes sense they are packaged together.

2. There doesn't seem to be many different inputs to be added to build
all the backends, so the maintenance cost should similar.  Inheritance
also introduce some complexity, by having to keep everything in sync
while the Guix tooling doesn't make the relationship easy to discover
(via 'guix refresh --list-transitive say').

3. It's done elsewhere, e.g. in nixpkgs, so we can compare in case of
problems.

What do you think?

-- 
Thanks,
Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.