13:33 <vup2> Is there any reason for FlippedInterface to not implement __hash__? Atm unflipped interfaces are hashable, but flipped ones not...

13:35 <whitequark[cis]> hm, that is indeed odd

13:50 <_whitenotifier-2> [amaranth] rroohhh opened pull request #1580: lib.wiring: make FlippedInterface hashable - https://github.com/amaranth-lang/amaranth/pull/1580

14:09 <mabl[m]> Are you sure it should return the identical hash as the flipped interface?

14:09 <mabl[m]> s/flipped/unflipped/

14:17 <vup> mabl[m]: I mean yes this means you get a hash collision when use the flipped and the unflipped interface in the same container, but I dont think the perf implications of that should ever be relevant?

14:18 <vup> It felt "cleaner" doing it this way, vs hash combining it with some magic constant or something, just to not get the same hash as the unflipped version

14:40 <tpw_rules> vup: you can just put a minus sign, __hash__ can return any integer

15:32 <whitequark[cis]> i think it needs to be a 32-bit one or sth?

15:38 <zyp[m]> > Note hash() truncates the value returned from an object’s custom __hash__() method to the size of a Py_ssize_t. This is typically 8 bytes on 64-bit builds and 4 bytes on 32-bit builds.

15:38 <zyp[m]> * > Note `hash()` truncates the value returned from an object’s custom `__hash__()` method to the size of a `Py_ssize_t`. This is typically 8 bytes on 64-bit builds and 4 bytes on 32-bit builds.

15:52 <whitequark[cis]> oh gotcha

18:31 <_whitenotifier-2> [amaranth] rroohhh opened pull request #1581: lib.wiring: make FlippedInterface hashable [0.5 backport] - https://github.com/amaranth-lang/amaranth/pull/1581

19:10 <_whitenotifier-2> [amaranth] whitequark closed pull request #1581: lib.wiring: make FlippedInterface hashable [0.5 backport] - https://github.com/amaranth-lang/amaranth/pull/1581

21:59 <zyp[m]> Radiant seems to throw out my JTAG primitive instance unless it's hooked up so it can affect any output pins; is there any way I can tell it not to?

22:01 <zyp[m]> when using it as the control interface for an ILA, it's not unreasonable for it to only be hooked up to inputs…

22:04 <cr1901> attrs={"keep": 1} or similar?

22:13 <zyp[m]> yeah, that's what I was thinking, but I'm not sure how, and from what information I found on google, that seems to be a signal attribute that keeps signals from being folded, and doesn't apply to signals not driving anything

22:15 <zyp[m]> so far, o_TDO = platform.request('jtag').tdo.o seems to be the most reasonable way to keep it from getting optimized out

22:18 <zyp[m]> but I don't have to hook up o_TDO at all if I have a couple of leds hanging off of this somewhere, and if I hook up i_TCK to the TCK pin, Radiant errors out about it not being a clock pin or something

22:31 <zyp[m]> anyway, now I have a ~~pile of mess~~ stack of stuff that's approaching useful; ILA block with CSR interface, CSR bus bridge to a pair of bytestreams, a JTAG transport that lets me run the bytestreams over the ecp5/nexus TAPs, and some client side tools for the whole thing: https://paste.jvnv.net/view/xM7J8