<_whitenotifier-2>
[glasgow] whitequark opened pull request #804: Reorganize module hierarchy of the framework implementation details into "simulation" and "hardware" - https://github.com/GlasgowEmbedded/glasgow/pull/804
<_whitenotifier-2>
[glasgow] whitequark synchronize pull request #804: Reorganize module hierarchy of the framework implementation details into "simulation" and "hardware" - https://github.com/GlasgowEmbedded/glasgow/pull/804
<_whitenotifier-2>
[glasgow] whitequark synchronize pull request #804: Reorganize module hierarchy of the framework implementation details into "simulation" and "hardware" - https://github.com/GlasgowEmbedded/glasgow/pull/804
<_whitenotifier-2>
[glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-804-257c90e7391e293738349738272eb3d1afd9e6b5 - https://github.com/GlasgowEmbedded/glasgow
<_whitenotifier-2>
[glasgow] whitequark closed pull request #804: Reorganize module hierarchy of the framework implementation details into "simulation" and "hardware" - https://github.com/GlasgowEmbedded/glasgow/pull/804
<josHua[m]>
hm, I understand the reason why inout_fifo / inout_pipe is the default primitive (rather than a unidirectional pipe) is because "that is how it used to be, and flipping that around would be onerous"? and it is unimportant for now to support, say, two unrelated in pipes and one unrelated out pipe (which would not be available by this implementation), because the endpoint-driven multiplexing will be killed and replaced by COBS over a
<josHua[m]>
single EP?
<josHua[m]>
well, over a single pair of EPs
<whitequark[cis]>
i'm actually not committing to a default yet
<whitequark[cis]>
the code i'm writing rn treats unidirectional and bidirectional pipes exactly equally. it's slightly annoying but i'm doing it anyway
<whitequark[cis]>
most likely, before migrating to COBS, i'm going to release a version which supports the traditional multiple-EP model much better than what we have in main right now
<joshua_>
I guess the architectural quesitonis why the bidirectional primtive exists as something other than emulation on top of pairs of unidirectional pipes (as opposed to th eother way around)
<whitequark[cis]>
this is because the migration to COBS is the type of thing that promises to be painful and require escape hatches, and i'd like updates to glasgow to leave it in a strictly better state, not slightly degraded in hopes of uncertain future improvement
<joshua_>
yes, that seems likely that *something* will go wrong in that process
<whitequark[cis]>
re: architectural question: look at my push
<joshua_>
haha indeed
<joshua_>
I think that adequately answers my question. assembly.py:104 in the old version made me scratch my head, and indeed the answer was "because ther eplacement was not done" or some such
<whitequark[cis]>
joshua_: btw, there are arguments both for and against treating a bidirectional stream as exactly a pair of unidirectional ones
<joshua_>
yeah, I think I asked not because I thought it was a bad idea but because I didn't understand why one might intuitively choose it
<whitequark[cis]>
ah, makes sense
<whitequark[cis]>
i had both options at various points and it's really not clear whether one is clearly beneficial over the other
<whitequark[cis]>
i'm leaning towards "unidirectional as a special case of bidirectional" because the synthesizer should be able to completely remove unused FIFO interfaces / streams / etc anyway
<whitequark[cis]>
and it maps better to TCP
<whitequark[cis]>
but i'm undecided
<joshua_>
mapping to TCP makes sense (though opening two TCP sessions is sort of free anyway)
<whitequark[cis]>
hm
<whitequark[cis]>
you... are in fact correct
<joshua_>
I have always been allergic to "we just generate some stuff and hope it gets optimized out", since you have to be very certain that you have not accidentally caused something to confuse the optimizer
<whitequark[cis]>
well yes but i moonlight as a toolchain maintainer/author
<whitequark[cis]>
so i feel empowered to make decisions like that, given that, worst case, i just fix the toolchain
<joshua_>
if you wanted to expose a TCP protocol to non-Glasgow things you would want bidirectional TCP... if you wanted to expose it only to things that get to it with `import glasgow`, less important
<whitequark[cis]>
a big part of the point of having TCP is bidirectionality
<joshua_>
yeah, I mean, I think the thing I'm thinking about is hard-to-notice interactions like "we wrote a DFD inserter that instrumetns some flops, and suddenly this cone of logic can't get optimized out anymore"
<whitequark[cis]>
er, sorry, a big part of the point of having TCP is compatibility with other software
<whitequark[cis]>
but you could also glue together two streams into one at a very late point if you need to
<whitequark[cis]>
so it doesn't need to be special at gateware level
<joshua_>
it's also not obvious to me that the right API boundary is "TCP sessions from other software that are guaranteed to feed data straight down to gateware pipes"
<joshua_>
it seems that if you want to expose something to other unrealted software, the applet ought do that exposing in some stable way
<whitequark[cis]>
oh, it's generally not, and thus far i have provided no API to do so because it's basically impossible to do it in a stable way
<joshua_>
anyway, I am nitpicking over something that is not actually important, and truly either will work
<whitequark[cis]>
but (a) the performance characteristics of piping TCP straight to gateware are very alluring and (b) it is possible and sometimes desirable to implement a stable protocol in gateware (a simple example would be TAP)
<whitequark[cis]>
(TAP would be better served by UDP but i digress)
<whitequark[cis]>
we already have a few cases of implementing a stable protocol. namely jtag-openocd and swd-openocd
<joshua_>
yeah, TAP is exactly the case where you would not want to do this :)
<whitequark[cis]>
although these interfaces are so absurdly slow it's not like python in the middle matters much (i've still seen python peg a core so maybe it does?)
<whitequark[cis]>
how so?
<joshua_>
due to indeed wanting UDP for such a thing
<whitequark[cis]>
oh. i'm using TCP and UDP somewhat interchangeably
<joshua_>
'something that socket() gives you and implements send() and recv()'
<joshua_>
indeed, though, the mapping of gateware pipes to what send()s and what recv()s on which socket need not be one-to-one for every single applet
<jn>
"ever since migrating to Amaranth 0.5 lib.io [--trace] has stopped registering pin events, which made it essentially useless" <-- ah, i tried to use it once and wondered why i only saw internal signals, but didn't dig deeper (i didn't recognise this as a bug because i didn't quite know what to expect)
<whitequark[cis]>
yeah it was a really unfortunate casualty