<whitequark>
although it could also be urb_cancel so I need the trace
<sb0>
whitequark: mailed
<whitequark>
interesting
<whitequark>
i'll take a look next time i'm in the lab
<whitequark>
unfortunately i don't think i have openvizsla with me
<sb0>
the bug is more infrequent on another computer, so I'll just use that I suppose
awe00 has quit [Ping timeout: 268 seconds]
sb0_ has joined #m-labs
sb0 has quit [Ping timeout: 246 seconds]
<sb0_>
also it seems that once the bug has occured, it occurs more often until you replug the device
<sb0_>
or if the previous capture had been interrupted
<whitequark>
it's a buffering issue i think
<whitequark>
some interplay between fx2lafw, sigrok code and linux
<whitequark>
i wonder if it'd be easier to just rip out the usb code from glasgow and see if that fixes it
sb0_ has quit [Quit: Leaving]
<lkcl>
whitequark: btw i remember seeing the 0.1 release announcement / request - would a "priority picker" - an optimised back-to-back PriorityEncoder-plus-Decoder - be a useful addition to nmigen utils?
<lkcl>
it's just a chain of AND and NOT gates, which is not entirely obvious when you think of connecting a PriorityEncoder's output to a Decoder's input
<lkcl>
i just remember seeing a call for "good ideas for utility routines to include"
<lkcl>
so wanted to throw the PriorityPicker your way to see what you think
<lkcl>
it's genuinely not obvious what's going on there, but it does *NOT* create a cascading gate chain which gets longer and longer as the width gets larger
<lkcl>
it *specifically* creates a chain that is only 2 gates deep, regardless of the width.
<whitequark>
that isn't the case if you synthesize for FPGAs
<lkcl>
ok ok at some point it would be necessary to have a...
<whitequark>
since they're kLUT architectures
<lkcl>
ok then it would need.... mm... an "if platform == 'FPGA'" option (something like that?)
<whitequark>
nope
<lkcl>
is there a way to detect if the platform is an FPGA?
<whitequark>
no, and that doesn't matter
<lkcl>
anyway: i leave the thought with you.
<whitequark>
for that matter, a good LUT mapper should be able to give good results for back-to-back encoder and decoder
<whitequark>
anyway. yes, a priority picker seems useful.
<whitequark>
your module doesn't follow any of nmigen coding standards so it can't be used directly though
<lkcl>
not so concerned about that. i threw it together because i needed it for register-port selection on the Out-of-Order processor.
awe00 has joined #m-labs
awe00 has quit [Ping timeout: 272 seconds]
lynxis has quit [Ping timeout: 250 seconds]
lynxis has joined #m-labs
mauz555 has quit [Remote host closed the connection]