<_whitenotifier-5>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] daf7a8c - Deploying to main from @ amaranth-lang/amaranth@1d5de80347765788f58bf717e35c000b3b4a9ba5 🚀
jfng[m] has quit [Quit: Idle timeout reached: 172800s]
notgull has quit [Ping timeout: 256 seconds]
notgull has joined #amaranth-lang
<whitequark[cis]>
another reason to have ready combinationally depend on valid: imagine you are writing a command processor and you only want to accept valid commands, but without additional delay
notgull has quit [Ping timeout: 264 seconds]
<key2>
yes
<key2>
and it would make it compatible with other cores that are out there following this paradigm
<zyp[m]>
<whitequark[cis]> "another reason to have ready..." <- with the rules in #61, this would make the transmitter have to either violate rule 4 or lock up the stream until reset
<whitequark[cis]>
the lock-up is the expected and desirable outcome
<whitequark[cis]>
(it's an invariant violation checked by the receiver)
<zyp[m]>
sounds a bit heavy handed if this could be caused by e.g. a wrong CSR write by firmware (or even a developer poking in the debugger)
<whitequark[cis]>
then don't use that kind of signaling?
<whitequark[cis]>
zyp[m]: btw, this happens all the time with commercial SoCs; you poke a wrong memory area and the entire thing hangs
<zyp[m]>
yeah, and I hate it
<whitequark[cis]>
whitequark[cis]: ^
<whitequark[cis]>
I personally find it very valuable that I get a lock-up at exactly the wrong state and can e.g. introspect it with an ILA trivially
<whitequark[cis]>
I certainly don't want it to just swallow an invalid command and continue
<zyp[m]>
yeah, I agree that depending on the use case that could be preferable