nyanotech has quit [Remote host closed the connection]
nyanotech has joined #amaranth-lang
yuriks has quit [Quit: Connection closed for inactivity]
<whitequark[cis]>
zyp vup adamgreig i have a proposal for a standard packet queue component
<whitequark[cis]>
the input and output are both streams that include data, start, end
<whitequark[cis]>
for the output, these have the obvious semantics. for the input, end commits octets pushed in thus far, and start resets the counter to the beginning of what could be a half-pushed packet
<whitequark[cis]>
this is better than my current implementation (in glasgow) which has a stream and commit/rollback as sidebands, because there is a clear timing relationship of start/end to data
<whitequark[cis]>
(there should probably be an option to omit start signals for cases where you don't care)
<zyp[m]>
does start equal first, or does it mirror the difference between last and end?
<whitequark[cis]>
can you clarify the second part of the sentence?
<zyp[m]>
your COBS blocks introduced streams with end that differs from last in that it's asserted after the last data cycle
<whitequark[cis]>
that's correct, the COBS blocks use a different scheme
<whitequark[cis]>
(this is fine-ish because I'm not proposing them for inclusion into Amaranth, these are just things i built for Glasgow)
<zyp[m]>
if this is a traditional first/last scheme, I'd prefer those signal names :)
<whitequark[cis]>
that being said, this is a contradiction i haven't been able to resolve yet
<whitequark[cis]>
hm. i don't actually like first/last
<whitequark[cis]>
but i'm also not interested in discussing naming at the moment
<whitequark[cis]>
the COBS blocks are built the way they are because i may want to be able to terminate a stream at some point after i push a byte into it but without having any more bytes
<whitequark[cis]>
you can convert this into the usual AXI Stream scheme by buffering one octet at the source and pushing it whenever you want to terminate the packet unexpectedly
<zyp[m]>
yeah, which I found useful, so I included that in my stuff as well
<zyp[m]>
the point of the enum is to restrict implementation complexity to the actually useful combinations
<whitequark[cis]>
yeah, I think that's useful
<whitequark[cis]>
re: stream helpers, do you think you could write an RFC for adding stream_get/stream_put to the stdlib, as methods on stream.Interface?
<whitequark[cis]>
that seems useful and uncontroversial
<whitequark[cis]>
the "wrappers" aren't something i have clarity on the best design of yet, because it's not clear how rate conversion should work
anubis has joined #amaranth-lang
Ekho has quit [Ping timeout: 252 seconds]
sorear has quit [Ping timeout: 252 seconds]
anubis has quit [Read error: Connection reset by peer]
anubis has joined #amaranth-lang
sorear has joined #amaranth-lang
anubis has quit [Ping timeout: 252 seconds]
mithro has quit [Ping timeout: 252 seconds]
bob_twinkles has quit [Ping timeout: 252 seconds]
Ekho has joined #amaranth-lang
mobius has quit [Ping timeout: 272 seconds]
bob_twinkles has joined #amaranth-lang
feldim2425 has quit [Ping timeout: 248 seconds]
feldim2425 has joined #amaranth-lang
palmer has quit [Ping timeout: 248 seconds]
LoveMHz has quit [Ping timeout: 248 seconds]
vup has quit [Ping timeout: 252 seconds]
mithro has joined #amaranth-lang
vup has joined #amaranth-lang
frgo_ has quit [Read error: Connection reset by peer]
<zyp[m]>
I skimmed the implementation, and if I'm reading it right, you're using an internal queue to hold the sizes of the committed packets
<zyp[m]>
the obvious alternative would be to store an extra delimiter bit in the data memory, and have a commit pointer in addition to the read and write pointers
<whitequark[cis]>
let's say you have a 2048 entry FIFO. no matter how many packets you expect to store there, this wastes one BRAM worth of delimiters
<whitequark[cis]>
i don't like that waste
<zyp[m]>
right, because ice40 has 2kb blocks?
<whitequark[cis]>
4K, actually, but yosys will round up
<whitequark[cis]>
(assuming the data there is 8 bit)
<whitequark[cis]>
the math is even worse for FPGAs with bigger BRAMs
<whitequark[cis]>
although you could argue that it's "free" for the same 8 bit FIFO since Xilinx and ECP5 have 9 bit wide BRAMs
<zyp[m]>
I come from an ecp5 perspective with 18kb blocks, so you'd use a single 2048x9b block, fitting the delimiter bit next to a bytestream
<zyp[m]>
in which case it's free, yes
galibert[m] has joined #amaranth-lang
<galibert[m]>
Cyclone too has the 9th bit
<zyp[m]>
but yeah, your approach is more efficient if you can't fit a delimiter bit for free, and the packet count is reasonably low
<whitequark[cis]>
right. so we probably want a delimited one upstream
<zyp[m]>
could have both; interface would be identical except for size_depth, so it could just use a delimited memory if size_depth == None
<whitequark[cis]>
good plan!
<whitequark[cis]>
re: the interface, it seems reasonable to have independently configurable "has first" / "has last" for either end
<whitequark[cis]>
your enum would be helpful in achieving this
<whitequark[cis]>
actually no, it doesn't work without last on the input side
<zyp[m]>
you need both commit and discard signals on the input side for this to have much benefit over a regular queue
<zyp[m]>
although it could still be useful without discard if the goal is to ensure you have a complete package before you start transmitting, e.g. to prevent underruns
<whitequark[cis]>
this is actually what i want it for
<whitequark[cis]>
well, on the TX side of the Ethernet controller
<zyp[m]>
yeah, that's what I had in mind as well
<zyp[m]>
in a similar vein, I've made elasticity buffers before, where it blocks the output until it's either half full or got a complete packet
<zyp[m]>
as for the enum, I figure it's entirely reasonable to only support a subset of it
<whitequark[cis]>
zyp: one thing that isn't really provided is the ability to see how large an incoming packet is, which is something i use in my Ethernet implemenetation
<whitequark[cis]>
i think i'll probably replace the framing with COBS which makes that part irrelevant, however it would be useful to have an answer to this question more broadly
<whitequark[cis]>
as in "how do we provide this kind of API?"
<zyp[m]>
how do you need/use this information?
<whitequark[cis]>
(oh, side note: I no longer have any objection to first/last, I think the names you've used in katsuo are just fine)
<whitequark[cis]>
zyp[m]: I prefix the packet I'm sending to the host with its length
<zyp[m]>
right, information which you've already got in the size queue
<zyp[m]>
most obvious solution would be to have an option to include it in the payload
<whitequark[cis]>
the set of options starts to look rather scary at this rate
<zyp[m]>
I agree
<zyp[m]>
but the other option I came up with is to have another block that counts the size of the packets in front of the queue, and then it's just doing duplicate work
<whitequark[cis]>
unless you're using delimiters, in which case it's not