>lun. 12 mai 2025 at 16:14, Maxim Cournoyer <maxim.cournoyer@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