<zyp[m]>
I got inspired to do some cleanup and documentation and got the first part of the library I've been working on published: https://github.com/zyp/katsuo
<whitequark[cis]>
very nice
<zyp[m]>
still need to set up a CI flow for the docs build, but for now I've put a copy here: https://dump.jvnv.net/katsuo-stream/, for now it's mostly about packet semantics
<zyp[m]>
I adopted the end semantics :)
<whitequark[cis]>
i don't have a strong opinion on the semantics yet since i haven't used it, but i like the direction of evolution
<whitequark[cis]>
my only real concern is "is this too many options for comfort?"
<zyp[m]>
I still think most things will use last semantics, but having options is good, and I believe this is the best way to do so
<zyp[m]>
it is entirely reasonable for components to only support one or a specific subset of semantics
<zyp[m]>
and I also plan to add a component that can do conversions
<whitequark[cis]>
right. but wouldn't generic components like the ones in amaranth stdlib have to implement all four? with a potential combinational explosion if they have several i/os?
<zyp[m]>
which components are you thinking of?
<whitequark[cis]>
let's say a packet FIFO
<whitequark[cis]>
i guess it could regenerate the missing signals at the boundary
<_whitenotifier-2>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 8f22b63 - Deploying to main from @ amaranth-lang/amaranth@f3ac270a4db6c99efcce2d737c07119ab2ff0e71 🚀