frgo has quit [Read error: Connection reset by peer]
frgo_ has joined #amaranth-lang
frgo_ has quit [Read error: Connection reset by peer]
RobTaylor[m] has quit [Quit: Idle timeout reached: 172800s]
frgo has joined #amaranth-lang
frgo has quit [Remote host closed the connection]
<anuejn>
oh cool re glasgow streams
<anuejn>
vup and me started to migrate naps to amaranth streams the other day
<anuejn>
and we will probably come up with some extensions (like packetized streams with last) up downstream and might write an RFC when we prototyped it
<zyp[m]>
been meaning to make a library of that and other reusable stream blocks I'm writing
<zyp[m]>
although, to be honest, I'm finding that first is not very useful; almost every packetized stream interface I make only has last
BentoMon has joined #amaranth-lang
<anuejn>
zyp[m]: yeah we are also using first in exactly one place in the entire codebase
<anuejn>
and that place does not seem super nescessary
<anuejn>
but we use a lot of other signals (for example we have an ImageStream that has a frame_last and a line_last)
<anuejn>
huh, no actually only that and some axi-foo
<anuejn>
but in the past it was handy to be able to write cores so that they work with different kinds of streams (i.e. non-packetized, packetized, and image)
<anuejn>
maybe we can team up and make a library of stream stuff :)
<zyp[m]>
I've found first is useful as a resync thing, e.g. to throw away partial state and start over
<zyp[m]>
but I think maybe that should be decoupled from Packet and be its own thing with more strictly defined semantics
<whitequark[cis]>
<anuejn> "maybe we can team up and make..." <- we should, yeah!
<whitequark[cis]>
i'll chip in from glasgow too
<anuejn>
maybe lets collect cores (kind of streams) we have / find useful somewhere to gather requirements?
<whitequark[cis]>
I'd say open a discussion on the Amaranth repo
<anuejn>
I think that is like the more generic version?
<whitequark[cis]>
something that i want to have upstream is a universal FIFO
<whitequark[cis]>
you give it the depth and acceptable latency and clock domains and gearing ratio, it instantiates the right kind of FIFO inside
<anuejn>
that would be quite cool
<anuejn>
we now always gear before the fifo
<whitequark[cis]>
it's useful because the gearing could be done as a part of a memory with asymmetric ports
<anuejn>
yeah seems quite handy
<anuejn>
okay wrote some thoughts up
<anuejn>
I think the main trickyness is in the last paragraph:
<anuejn>
how do we enable cores to be written so that they can operate on different kinds of streams (like PacketizedStream vs ImageStream)
<zyp[m]>
<anuejn> "how do we enable cores to be..." <- write them so that they doesn't care about the stream payload's shape more than they have to
<zyp[m]>
and make use of lib.data aggregates
<anuejn>
did you read the motivating example of writing a MetadataWrapper that works with both PacketizedStream and ImageStream?
<anuejn>
or a StreamGearbox?
<zyp[m]>
yes, and I see your gearbox talks about bits, my serializer takes a data.ArrayLayout with an arbitrary shape, which I can further stick a Packet into
<anuejn>
ah huh cool
<zyp[m]>
lib.data shapes are introspectable, you can look at the layout and unwrap the inner payload if you need to separate it from the sideband signals
<whitequark[cis]>
yep
<anuejn>
so in your model sideband signals are always at the innermost level?
<zyp[m]>
no, the primary payload would be innermost, and each layer above could e.g. add sideband signals
<zyp[m]>
also, this only generalizes as far as you have something you can call a «primary payload» in the stream
<anuejn>
I see
<anuejn>
but how would a real gearbox fit into that model?
<anuejn>
I often have to convert a 12bit stream into a 64bit one to write it into dram