<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] whitequark 2543b4b - Deploying to main from @ amaranth-lang/rfcs@0b7c7a4e63df0e5550e5cdc783cc16e6b4576ec5 🚀
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] whitequark 9b11aa6 - Deploying to main from @ amaranth-lang/rfcs@03c7c3e62d5154ae903ad110ebd6881dbbd0699f 🚀
<Sarayan>
wq: if you have the bandwidth, I'd appreciate pointers on how you'd like the domains rfc to be implemented
<whitequark>
not in the 0.4 release cycle
<whitequark>
however for 0.5 this is directly relevant and a work that I've been planning to do
<Sarayan>
of course not in 0.4
<Sarayan>
ok, if you plan to do it I'll leave it to you then
<whitequark>
if you're up for it it would potentially make sense to collaborate; I just mean that it was on my personal roadmap before you wrote the RFC
<Sarayan>
I'm up for it, but since it's very core you probably and justifiably have strong opinions on how it should be done
<Sarayan>
we probably need a better definitions of resets along the way, it's quite tied
<whitequark>
yes
<Sarayan>
hmmm, should we allow to have both sync and async reset on the same signal/storage?
<whitequark>
yes
<whitequark>
the chip would usually have an async global reset, and then the individual modules may have sync reset via ResetInserter
<whitequark>
Rob Taylor: Matrix reactions are not translated to IRC
<robtaylor>
whitequark: ah booo
<robtaylor>
how do threads appear? =)
<Sarayan>
from your POV async reset is only POR? Or am I missing the mechanism for triggering an async reset?
<whitequark>
async reset is for any reason you want it to be, really
<Sarayan>
So you can ResetInserter an async reset? Where async may mean sync-but-on-a-different-enable-signal mind you
<whitequark>
re "sync-but-on-a-different-enable-signal": I think of registers as having a *control set*
<whitequark>
in the control set, we currently have: clock, domain (async or sync) reset, inserted (sync) reset, and inserted (sync) enable
<whitequark>
the asynchronous signals (clock and async domain reset) override all of the clock-synchronous signals
<whitequark>
sync reset overrides sync enable
<whitequark>
anyway, control set crossing can introduce logical issues and physical issues
<whitequark>
physical issues arise due to having a different async control set
<whitequark>
logical issues arise to having a different sync control set which violates an assumed invariant
<whitequark>
Rob Taylor: no idea re: threads, try it?
<whitequark>
whitequark: thread test
<whitequark>
looks like they appear as normal replies
<whitequark>
the context is definitely lost
<robtaylor>
ah, makes sense
<robtaylor>
yeah, irc does feel a bit lacking nowadays with matrix available
<whitequark>
there's also Discord bridged in!
<whitequark>
d1b2 <-
<whitequark>
I think there's IRCv3 which has many of the same features, but idk if this will be widely used
<Sarayan>
I wouldn't separate domain reset and inserted reset, in the spirit of the rfc they're one, it's just creating a new domain with a different setup
<whitequark>
I'm talking about the current implementation
<Sarayan>
ah, ok, I'm taling about rfc/definition for 0.5
<Sarayan>
talking
<whitequark>
I have to admit I actually haven't read it closely, since I have so much on my plate right now
<whitequark>
I just skimmed it and figured that you put a lot of thought into it and that it looks like it is a reasonable starting point for discussion
<whitequark>
in other words, determined that it is something clearly worth spending time on, but have not been able to spend the time
<Sarayan>
makes perfect sense
<Sarayan>
you have a 0.4 to get out the door, in addition of minor things like changing countries and stuff
<Sarayan>
I'll annoy you again once 0.4 is under control
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] whitequark 658f666 - Deploying to main from @ amaranth-lang/amaranth@2a45d0e9adebbb0985e26e1c4c1847de24b3fbef 🚀