00:22 <_whitenotifier-e> [YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±1] https://github.com/YoWASP/nextpnr/compare/8132ae34cf13...1f7af943c8ad

00:22 <_whitenotifier-e> [YoWASP/nextpnr] whitequark 1f7af94 - Update dependencies.

00:59 <_whitenotifier-e> [YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1] https://github.com/YoWASP/yosys/compare/c8ea0c7a78a3...bc2eb210fe5e

00:59 <_whitenotifier-e> [YoWASP/yosys] whitequark bc2eb21 - Update dependencies.

01:32 <bl0x_> question: PR review in amaranth-boards is low prio right now?

13:49 <whitequark> yeah

16:23 <_whitenotifier-e> [YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1] https://github.com/YoWASP/yosys/compare/bc2eb210fe5e...f8b58b705730

16:23 <_whitenotifier-e> [YoWASP/yosys] whitequark f8b58b7 - Update dependencies.

16:56 <whitequark> sigh, yosys requires zlib now

17:08 <_whitenotifier-e> [YoWASP/yosys] whitequark pushed 12 commits to release [+0/-0/±13] https://github.com/YoWASP/yosys/compare/4a5bf3fd316a...bc2eb210fe5e

17:08 <_whitenotifier-e> [YoWASP/yosys] whitequark 5c808dd - Update dependencies.

17:09 <_whitenotifier-e> [YoWASP/yosys] whitequark d020487 - Update dependencies.

17:09 <_whitenotifier-e> [YoWASP/yosys] whitequark 14700f2 - Update dependencies.

17:09 <_whitenotifier-e> [YoWASP/yosys] ... and 9 more commits.

21:40 <SimonSapin> would Amaranth be a good fit for simulating something where a Memory is used as a framebuffer, and regularly extracting all of the values to show pixels on an actual display?

21:41 <SimonSapin> it it looks like `yield` can only read one item at a time from a Memory

21:41 <Degi> Hmh, maybe some internal variable can access it

21:41 <Degi> Though maybe repost that message when everybody is back online

21:41 <d1b2> <TheManiacalLemon> I vaguely remember there being some parameter you can pass in to make all of the memory visible at simulation time, at the expense of it generating a TON of signals

21:41 <SimonSapin> Ah yes. I sent this just before the Matrix bridge came back: Would Amaranth be a good fit for simulating something where a Memory is used as a framebuffer, and regularly extracting all of the values to show pixels on an actual display?

21:42 <tpw_rules> i don't think you will be excited by the speed

21:42 <SimonSapin> yeah I kinda expect that :)

21:42 <Degi> Yes, its pretty slow. Can you yield _array?

21:43 <SimonSapin> I think yielding an Array was also an unsupported operation error

21:44 <Degi> It should be possible to loop through the array

21:44 <d1b2> <bob_twinkles> I did something similar (though using cxxrtl, which also didn't handle memories well at the time). My solution was to just stub out the memory interface and implement a more efficient memory simulation outside of my design

21:44 <Degi> [(yield memory._array[i]) for i in range(depth)] or so

21:44 <SimonSapin> right, so one item at a time

21:44 <Degi> But its still all within one cycle

21:44 <d1b2> <TheManiacalLemon> Could always benchmark that one-liner and see how bad it is

21:45 <Degi> Or (yield Cat(memory._array))

21:45 <d1b2> <bob_twinkles> i.e. the memory bus was published as top-level signals and I could just back it using a native array in C++ + some glue code

21:46 <d1b2> <TheManiacalLemon> You could go with an extra-cursed approach and Cat all the signals in your HDL for the memory by just reaching into _array

21:46 <d1b2> <TheManiacalLemon> then it's just one yield at sim time

21:47 <Degi> Though there is a limit at 65535 signals or so, if I remember correctly

21:47 <SimonSapin> I was gonna ask that

21:47 <Degi> I'd just yield loop over the array. Maybe you can time it to see how bad it is

21:48 <SimonSapin> it looks like python will just happily make integers arbitrary large until it runs out of memory

21:48 <SimonSapin> (1 << (1 << 37)).bit_length() takes a couple seconds

21:50 <Degi> Hmm, the 65535 limitation was somewhere in the toolchain IIRC. Might even work in sim.

21:54 <mwk> wasn't that the limit on a single signal's length?

21:54 <SimonSapin> Cat would create that single signal

21:54 <mwk> oh.

21:54 <Degi> Hmm yeah

21:55 <SimonSapin> though if going that way, one might as well skip the array and directly use slices of the One Big Signal as memory

23:30 <agg> SimonSapin: for something vaguely similar i did what bob_twinkles did and had my actual module drive addr, data, en pins to write to the memory, and then in hardware I wire those to a Memory object but in sim I can capture whatever's being written into a 2d numpy array or whatever was convenient for me to display

23:31 <agg> so instead of dumping the whole state of the framebuf each simulator cycle, I read at most one new update per cycle, and store the state outside the simulator

23:32 <cr1901> Why is there a 65535 limit for a signal width (incl/esp array index)?

23:33 <mwk> cr1901: because ending up with a signal that large is usually a sign that something went horribly wrong, and it also tends to cause downstream failures / performance issues in yosys

23:34 <cr1901> That's fine. It's more "something I never thought about", more than "something I think I actually need"

23:34 <mwk> the motivating case for that was when you write "a << b" in nmigen, and b happens to be a 32-bit signal

23:34 <mwk> this immediately results in a 4-gigabit signal

23:35 <mwk> which will cause all kind of OOMs and integer overflows when yosys attempts to actually synth it

23:37 <cr1901> mwk: Also, I'm confusing 65335 for 2^65535 again in my head :P

23:37 <cr1901> An array w/ 65535 indices uses a 16 bit signal, not a 65535 bit signal :D