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 10:25:43 +0200

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

>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].

As it is now, we’d be using a single package for all devices, which is
possible, but complicates things as we would need a huge package
definition. In addition, this approach difficults maintenance, IMO,
whereas a different package per device/backend eases future upgrades
and fixes.

Let me know how do you prefer I proceed.

> I didn't keep the phase building the examples as the package already has
> a test suite, and I didn't see the gain/effort ratio of doing so as
> worth it.

Consider that nextpnr testing is different from nextpnr-ice40 testing,
which again differs from nextpnr-ecp5 testing, etc.

Thanks again,

Cayetano

[0] https://git.sr.ht/~csantosb/guix.channel-electronics/tree/main/item/electronics/packages/pnr.scm

[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.