<jn>
hm, there seems to be a regression in/around the jtag-probe applet. with a particular DUT, it worked (showed an IDCODE) at 2024-06-20, and fails (DR chain too long) with current main. is something like that known? otherwise i'll bisect
<whitequark[cis]>
please bisect
<jn>
ok
<jn>
ah well, the error disappeared, even on current main, now sure why i saw it in the first place. sorry for the noise
<whitequark[cis]>
probably just a bad connection
<whitequark[cis]>
TDO fell off
<jn>
possible, yea
<whitequark[cis]>
or any other signal really
_whitelogger has joined #glasgow
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #glasgow
jfsimon has quit [Max SendQ exceeded]
jfsimon has joined #glasgow
jfsimon has quit [Max SendQ exceeded]
jfsimon has joined #glasgow
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #glasgow
GNUmoon has quit [Remote host closed the connection]
<isabelburgos[m]>
the syntax add_inout_pipe(in_stream = component.o_stream, out_stream = component.i_stream) makes complete sense when I consider that the output stream of Glasgow is the computer's input stream and vice versa. but it is the kind of thing that takes me an extra thinking step to get right. It makes me wonder if there's a way to make it semantically even clearer that HardwareInPipe and HardwareOutPipe are defining "in" and "out" from
<isabelburgos[m]>
the perspective of the host, but I can't think of any better terminology