<cr1901_modern>
I'd love it, but I don't have the space for it (unless you had something else in mind by asking that).
<ysionneau>
whitequark: well, I don't have the time to dig in the content of those files, it was just for the "fun" of being part of the sharing (seeding)
<ysionneau>
thx for the offer
<cr1901_modern>
Everything I could probably find by grepping/html parsing has likely been done better by others already.
fengling has joined #m-labs
fengling has quit [Ping timeout: 256 seconds]
fengling has joined #m-labs
olofk has joined #m-labs
fengling has quit [Ping timeout: 256 seconds]
fengling has joined #m-labs
fengling has quit [Ping timeout: 256 seconds]
_whitelogger_ has quit [Ping timeout: 252 seconds]
_whitelogger_ has joined #m-labs
fengling has joined #m-labs
chiggs has joined #m-labs
fengling has quit [Ping timeout: 256 seconds]
bhamilton has joined #m-labs
fengling has joined #m-labs
sb0_ has joined #m-labs
sb0 has quit [Ping timeout: 256 seconds]
fengling has quit [Ping timeout: 252 seconds]
<olofk>
Have been playing around a bit with liteSATA and come across some issues that prevents simulations to be run under Icarus
<olofk>
Hi _florent_ :)
<_florent_>
hi olofk
<olofk>
Don't know if you have had this discussion before, but I finally figured out what the issue is
<_florent_>
ah interesting
<olofk>
_florent_: I actually got the phy_datapath_tb running now with some code changes in litesata
<olofk>
So it's possible to work around, bit in some cases it would become damn ugly, so I would prefer this to be fixed in migen
<olofk>
ok, so here's the problem
<_florent_>
yes, it's better to fix in migen
<_florent_>
it becomes very difficult to have a workaround when you connect multiple cores togethers
<olofk>
For example in datapath.py there's a mux choosing between ctrl and align_inserter to send to tx
<_florent_>
together
<olofk>
Inside align_inserter there's another mux
<olofk>
These gets converted in to a process each
<olofk>
lets say process1 is in align_converter and process2 is the external mux
<olofk>
process1 sets the stb, data and charisk signals. This triggers process2. process2 in turn sets the ack, which triggers process1
<olofk>
like forever :)
<olofk>
So, my workaround for this case was to move ack assignment out of the If() function, so that it becomes a simple assign instead. This breaks the loop, but it's harder to do in other places.
<olofk>
Like the SATAArbiter for example. That would require a rewrite
<olofk>
So my idea is to somehow make migen move the contradirectional signals out of the process, or have two process. One for each direction
<olofk>
Maybe this is what the forked migen already does. I tried to understand the changes, but I couldn't really grasp it
<olofk>
I'm surprised that this hasn't turned up in other places. From what I understand, it would just need two combinatorial muxes (with bidirectional signals) after each other
<olofk>
..to trigger the problem, I mean
<_florent_>
I really need to have a closer look a that, maybe you have a possible solution with what you are suggesting
<olofk>
_florent_: Yeah, I can send over some example snippets when I have time
<olofk>
What I did to debug this was to hack verilog.py to print out the current process it's running, to see where the loops are
<_florent_>
yes it would be interesting to have snippets
<olofk>
Don't ask how long I've spent following wires in the generated verilog :)
<olofk>
got to run now. bbl
<_florent_>
what would also be interesting is a minimal example hangs the simulation
<_florent_>
ok bye, thanks for the feedback
bhamilton has quit [Read error: Connection reset by peer]
bhamilton1 has joined #m-labs
bhamilton1 has quit [Remote host closed the connection]
balrog has joined #m-labs
balrog has quit [Changing host]
balrog has quit [Quit: Bye]
balrog has joined #m-labs
<ysionneau>
rjo: is the following shell line supposed to be able to reproduce the lda/hid issue?
<ysionneau>
while [ 1 ]; do ARTIQ_LDA_PRODUCT="LDA-102" ARTIQ_LDA_SERIAL="SN:03461" python3.4 ./lda.py; done
<ysionneau>
(in artiq/test)
<ysionneau>
so far I get sometimes "libusbx: error [handle_events] hotplug pipe read error -1 != 16" but all tests turn out "OK" (environment is linux-64, Ubuntu based distro)
* ysionneau
is using self-compiled hidapi-libusb git sha1 d17db57b9
<ysionneau>
ah I wasn't up to date, let's try again with latest artiq
<ysionneau>
hum, seems to work fine also on HEAD
<ysionneau>
hardware_testbench < nice!
ylamarre has joined #m-labs
tija has quit []
ohama has quit [Ping timeout: 256 seconds]
ohama has joined #m-labs
<rjo>
whitequark: treating VMs and their hosts or bare metal the same is completely valid. from a risk and vulnerability standpoint there is no real difference.
<rjo>
ysionneau: the lda test passes about half the time. the other half the pattern is as described.
<rjo>
what is your hidapi version?
<rjo>
it might also be a VM-related issue.. usb through windows and virtualbox-host is not the same as native.
<rjo>
there is also a libusbx: error [handle_events] hotplug pipe read error -1 != 16 from time to time.
<rjo>
timeout for the control message?
<ysionneau>
rjo: I cannot reproduce on my linux-64 but on my linux-32 (debian jessie) I can reproduce the same hid error
<rjo>
ah. you get that error on native linux? then the vm might just exacerbate the bug.
<ysionneau>
(both are native linux)
<ysionneau>
linux-64 is my Elementary OS laptop, linux-32 is my Jessie desktop
<rjo>
this is on a 64-bit linux vm.
<rjo>
debian user: good boy! ;)
<ysionneau>
ahah, yes I kind of like Debian
<rjo>
hidapi version on the laptop?
<ysionneau>
but Elementary OS is "nice" on the macbook (yes ... macbook ...)
<ysionneau>
on the laptop (where I cannot reproduce) : d17db57b9
<rjo>
from git?
<ysionneau>
on the desktop where I reproduce : same sha-1
<ysionneau>
yes
<rjo>
ah.
<ysionneau>
weird
<ysionneau>
and on the desktop, I only partially reproduce, I get the HidError : -1: None, but not the queuing mixup
<ysionneau>
happens at random i (loop index)
<ysionneau>
but does not propagate to the following indexes
<ysionneau>
19:14 < rjo> ysionneau: the lda test passes about half the time. the other half the pattern is as described. < ok, I reproduce with a very lower rate, errors are very rare on my desktop :/
<rjo>
i would focus on the initial error. do you know whether there are fast timeouts in the controll mesage stuff in hidapi that could trigger?
<ysionneau>
I have to do while [ 1 ] to run lots of tests
<rjo>
looks like the libusb call times out
<rjo>
whitequark: re VM security: you would not want all the info that NIST has on you on their VMs to become compromised and leak out, would you? ;)
<ysionneau>
weird that hid_error() returns None , should return a string describing the error
<ysionneau>
knowing that hid_write returned -1 which the API describes as "an error"
<ysionneau>
rjo: which device are you testing the lda driver on?
<ysionneau>
I'm using LDA-102
<ysionneau>
19:24 < rjo> looks like the libusb call times out < highly possible, passing tests take 0.5 s, failing take 1.5 s
<ysionneau>
let's try to analyze with wireshark
<olofk>
_florent_: You there?
<olofk>
_florent_: You got mail instead. Too much text :)
<ysionneau>
rjo: I indeed see some weird stuff happening in wireshark when the bug happens, instead of 1 URB_CONTROL_OUT (type submit) + 1 URB_CONTROL_OUT (type complete) (for set_attenuation) followed by 1 URB submit + 1 URB complete (get_attenuation) then followed by 2 URB_INTERRUPT_IN, when it bugs I get : Submit/complete + submit, no urb complete (yet), then the 2 URB_INTERRUPT_IN, then the USB_CONTROL_OUT (type complete) (being late ?), then 1 ...
<ysionneau>
... message only happening in the bug situation : 2x ( USBHUB CLEAR_TT_BUFFER request followed by USB CONTROL complete)
<ysionneau>
hope I'm clear :p
<ysionneau>
I can send the pcapng if needed
<ysionneau>
rjo: I suspect the device can sometimes respond more slowly (weird that this differs between my two machines...), maybe increasing the timeout for the hid_read_timeout() can help?
<ysionneau>
hum ... it's not just a bad timing it seems
<ysionneau>
when the URB CONTROL out happens "later", its content is different, instead of having URB Status: success (0), you get URB Status: No such file or directory (-ENOENT) (-2)
<olofk>
Hmm... this was a bit tricker than I had thought. Looks like verilog.py doesn't know about the direction. Does record.py strip away this info?
ylamarre has quit [Quit: ylamarre]
<rjo>
ysionneau: daniel was the one who signed of on the lda driver. i'll ping him whether he want to talk to vaunix or wether the work around is ok.
<ysionneau>
all right, thanks!
sb0_ has quit [Read error: Connection reset by peer]
<olofk>
_florent_: Started looking at the device mode phy a bit again. Have you found any info on how long time that the host and device should send align patterns?
sb0 has joined #m-labs
<sb0>
urgh, the gps chip in my tablet is using this proprietary protocol