Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1055171: fpga-icestorm: icebram incompatible with yosys 0.23
11 views
Skip to first unread message
Daniel Gröber
Nov 1, 2023, 1:00:05 PM11/1/23
to
Package: fpga-icestorm
Version: 0~20220915gita545498-3
X-Debbugs-Cc: Andras Pal <ap...@szofi.net>
Hi Andras,
On Wed, Nov 01, 2023 at 04:52:25PM +0100, Andras Pal wrote:
> I'm using the yosys/nextpnr/icestorm toolchain regularly under Debian and
> after upgrading to bookworm i noted (after some debugging) that in some
> cases yosys-0.23 tends to generate memory instances whose initialization
> values cannot be replaced with the `icebram` utility in a similar way like
> in the previous (and in the following) releases.
Do you have a reproducer/example for this? I haven't had the need to use
icebram in my projects yet so having a regression test in the package would
be good.
> By checking the source code on github, i found that `icebram` underwent a
> significant refactoring, likely after freezing the bookworm release (i.e.
> sometimes in between Sept '22 and Feb '23). And indeed, after manually
> downloading installing the trixie version (20230218gitd20a5e9-1) of the
> fpga-icestorm and fpga-icestrom-chipdb packages, the toolchain started to
> work again as it is expected.
>
> Is it possible to backport this upgraded version of `icebram` to bookworm as
> well in order to be compatible with the shipped yosys version? I don't know
> what is the severity of this bug - it is indeed not a security issue, but
> otherwise the packeges are broken in this sense. And it might be beneficial
> for another users and projects as well.
Sholdn't be a problem. There's two ways to go, either we find a (small)
patch that fixes the issue in the version from stable or (with some
negotiation with the release team) we get permission to upgrade the version
in stable.
--Daniel
Version: 0~20220915gita545498-3
X-Debbugs-Cc: Andras Pal <ap...@szofi.net>
Hi Andras,
On Wed, Nov 01, 2023 at 04:52:25PM +0100, Andras Pal wrote:
> I'm using the yosys/nextpnr/icestorm toolchain regularly under Debian and
> after upgrading to bookworm i noted (after some debugging) that in some
> cases yosys-0.23 tends to generate memory instances whose initialization
> values cannot be replaced with the `icebram` utility in a similar way like
> in the previous (and in the following) releases.
Do you have a reproducer/example for this? I haven't had the need to use
icebram in my projects yet so having a regression test in the package would
be good.
> By checking the source code on github, i found that `icebram` underwent a
> significant refactoring, likely after freezing the bookworm release (i.e.
> sometimes in between Sept '22 and Feb '23). And indeed, after manually
> downloading installing the trixie version (20230218gitd20a5e9-1) of the
> fpga-icestorm and fpga-icestrom-chipdb packages, the toolchain started to
> work again as it is expected.
>
> Is it possible to backport this upgraded version of `icebram` to bookworm as
> well in order to be compatible with the shipped yosys version? I don't know
> what is the severity of this bug - it is indeed not a security issue, but
> otherwise the packeges are broken in this sense. And it might be beneficial
> for another users and projects as well.
Sholdn't be a problem. There's two ways to go, either we find a (small)
patch that fixes the issue in the version from stable or (with some
negotiation with the release team) we get permission to upgrade the version
in stable.
--Daniel
Daniel Gröber
Nov 2, 2023, 7:02:55 AM11/2/23
to
Hi Andras,
On Thu, Nov 02, 2023 at 08:44:31AM +0100, Andras Pal wrote:
> sure, please find attached this simplistic example for this issue. Just
> enter `make`. Under bullseye, it should print:
>
> Found and replaced 1 instances of the memory.
>
> Under bookworm, it prints:
>
> Found and replaced 0 instances of the memory.
Yup, I can reproduce the issue.
I've sent a request to the release team and uploaded the proposed
fpga-icestorm=0~20230218gitd20a5e9-1~deb12u1 to my repo at
https://dxld.at/localdebs/ (sources.list instructions within) please test.
Note to self: the upstream discussion is at
https://github.com/YosysHQ/icestorm/issues/301
https://github.com/YosysHQ/icestorm/pull/309
--Daniel
On Thu, Nov 02, 2023 at 08:44:31AM +0100, Andras Pal wrote:
> sure, please find attached this simplistic example for this issue. Just
> enter `make`. Under bullseye, it should print:
>
> Found and replaced 1 instances of the memory.
>
> Under bookworm, it prints:
>
> Found and replaced 0 instances of the memory.
Yup, I can reproduce the issue.
I've sent a request to the release team and uploaded the proposed
fpga-icestorm=0~20230218gitd20a5e9-1~deb12u1 to my repo at
https://dxld.at/localdebs/ (sources.list instructions within) please test.
Note to self: the upstream discussion is at
https://github.com/YosysHQ/icestorm/issues/301
https://github.com/YosysHQ/icestorm/pull/309
--Daniel
Andras Pal
Nov 2, 2023, 8:00:05 AM11/2/23
to
Hi Daniel,
thank you - i removed the trixie packages, added your repo and upgraded
the fpga-icestorm* packages accoringly. Tested on both this minimal
example and on my larger projects - all passed and now working fine!
Yes, this thread is very interesting and discusses indeed the same issue.
This distribution of BRAM cells for larger memory blocks is indeed
implying an ambiguous solition and/or and interesting trade-offs (if we
also consider things like power consumption vs. path lengths).
Thanks again, Andras
thank you - i removed the trixie packages, added your repo and upgraded
the fpga-icestorm* packages accoringly. Tested on both this minimal
example and on my larger projects - all passed and now working fine!
Yes, this thread is very interesting and discusses indeed the same issue.
This distribution of BRAM cells for larger memory blocks is indeed
implying an ambiguous solition and/or and interesting trade-offs (if we
also consider things like power consumption vs. path lengths).
Thanks again, Andras
0 new messages