<whitequark[cis]>
anuejn: yep, that was my intention behind lib.data/lib.wiring all this time!
<whitequark[cis]>
it just takes a while to properly explore
<whitequark[cis]>
re: generic N:M gearbox, that would require an integer ratio
<zyp[m]>
not if you keep the remainder and concatenate it with the next input
<zyp[m]>
12->64 is effectively like doing 12->192->64; you get three transfers on the output for every 16 transfers on the input
<whitequark[cis]>
hm.
<whitequark[cis]>
i wonder if that's the design we want to use
<whitequark[cis]>
maybe
<whitequark[cis]>
okay, i have a convention to propose
<whitequark[cis]>
if something has an i_ or o_ in the name, it should always have that direction within the signature
<whitequark[cis]>
even if it's connected to an "output buffer"
<whitequark[cis]>
i've tried to use o_ for a stream that connects to an output buffer (i.e. an input stream) and this is absurdly confusing
Degi has quit [Ping timeout: 265 seconds]
Degi has joined #amaranth-lang
vup has quit [Remote host closed the connection]
vup has joined #amaranth-lang
Chips4MakersakaS has quit [Quit: Idle timeout reached: 172800s]
<vup>
whitequark[cis]: how does the universal FIFO know what kind of memory primitives are available?
<whitequark[cis]>
the usual mechanism, platform.get_fifo override
<whitequark[cis]>
or something similar that's more suitable for this use case
<whitequark[cis]>
in general, we should be able to lower any memory (including memories with asymmetric / "wide" ports) even to ice40, so it's probably not a huge issue in practice
<whitequark[cis]>
iirc, me and Wanda were more worried about Verilog frontend support for memories
balrog has quit [Ping timeout: 252 seconds]
balrog_ has joined #amaranth-lang
frgo has joined #amaranth-lang
<vup>
well I was more thinking about ASIC memories