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

Previous Next

Full log

View this message in rfc822 format

From: Cayetano Santos <csantosb <at> inventati.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
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 14:24:05 +0200

[Message part 1 (text/plain, inline)]

>lun. 12 mai 2025 at 20:54, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> wrote:

> 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?

Fine with me; just keep in mind that we are not testing the binaries
(nextpnr-himbaechel, etc.).

This is it: #78390. It builds and performs as expected in all 4
architectures.

C.

[signature.asc (application/pgp-signature, inline)]

Previous Next

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