01:55 <GitHub13> [artiq] sbourdeauducq commented on issue #627: > I'm not sure, but I wouldn't know if not.... https://git.io/v1YKy

01:56 <GitHub51> [artiq] sbourdeauducq commented on issue #627: > I'm not sure, but I wouldn't know if not.... https://git.io/v1YKy

01:57 <GitHub18> [artiq] sbourdeauducq commented on issue #627: > I'm not sure, but I wouldn't know if not.... https://git.io/v1YKy

02:01 <GitHub17> [artiq] sbourdeauducq opened issue #633: disable_applet not working https://git.io/v1Y6I

02:02 <GitHub12> [artiq] sbourdeauducq commented on issue #633: Or better, dump all calls to ``ccb_notify``, so you can see the applet creation request as well which confirms you have modified the file correctly. https://git.io/v1Y6O

02:24 <sb0> cr1901_modern, ?

02:25 <sb0> what do you mean "one more bit than it should"?

02:25 <sb0> oh and sifive does seem to handle the hackaday cheapskates properly, instead of being idealists like https://www.crowdsupply.com/onchip/open-v

02:28 <sb0> better specs too

02:42 <cr1901_modern> sb0: "One more bit than it should" probably wasn't the best way to describe it. I'm still looking over it.

02:53 <cr1901_modern> sb0: Ping when you're around.

03:02 <cr1901_modern> I basically just want to confirm I'm not missing something re: AD9912 behavior, as I don't have one I can test with. At this point, I cannot duplicate the problem exactly. I think I know why (and I very well might NOT be able to duplicate the bug exactly). But I want to know for sure.

03:14 <sb0> cr1901_modern, I don't know why you fixate on the AD9912.

03:15 <sb0> the bug is described in a pretty clear way that has little to do with that chip, other than it requires back-to-back 32-bit transfers

03:18 <cr1901_modern> sb0: "This is true both for chained transfers and for single transfers." https://github.com/m-labs/artiq/issues/615#issue-188333416

03:19 <sb0> right, so it's even simpler and even more independent of the ad9912

03:19 <cr1901_modern> And I fixate on it because in my simulations, the incorrect LSB is due to the first bit transferred from the slave

03:22 <cr1901_modern> In SPI Mode 0, the first rising edge will cause the master to sample the slave's output, and vice-versa, right? I increment a counter on my stub slave: 1 bit sampled.

03:23 <cr1901_modern> By the time my counter reaches 32 on the stub slave, the slave has JUST sample the first bit it sent to the master when the counter was 0 and incremented to 1.

03:24 <cr1901_modern> Want me to send you my VCD?

03:52 <sb0> well if I'm going to dig that deep into the code, I might as well handle the whole thing

04:01 <cr1901_modern> sb0: I only wanted to send you the VCD to show you what I'm seeing. I disagree that the problem is slave-independent, and I *have* a solution I can test, but I suspect that it's only going to fix it for the AD9912

04:02 <cr1901_modern> But whatever, I'll just apply my proposed change (raise cs_n one cycle earlier) and see what happens.

04:17 <sb0> cr1901_modern, please dig and understand what is going on instead of just seeing what happens.

04:20 <cr1901_modern> sb0: Okay. FWIW, I'm not going to sleep until I fix it tonight. So if you need me, I'll be around.

10:43 <GitHub184> [artiq] sbourdeauducq pushed 2 new commits to drtio: https://git.io/v1OsZ

10:43 <GitHub184> artiq/drtio cd3f68b Sebastien Bourdeauducq: rtio: DMA core (untested)

10:43 <GitHub184> artiq/drtio cf342ec Sebastien Bourdeauducq: kc705_drtio_master: fix number of fine RTIO timestamp bits

12:27 <sb0> oh, this crazy big bell test is today

12:30 <cr1901_modern> big bell test?

12:36 <sb0> thebigbelltest.org

12:37 <cr1901_modern> On, like Bell Inequality stuff?

12:38 <sb0> yes

12:39 <sb0> https://www.youtube.com/watch?v=ZuvK-od647c is a good intro video to it IMHO

12:53 <cr1901_modern> Wow, that *was* a good video. I don't feel clueless anymore at least.

13:08 <larsc> was, but no longer is?

13:10 <cr1901_modern> Yes, it became a bad video once I finished watching it :)

13:25 <larsc> being a wide about quantum stuff you could have said it was both good and bad until you watched it

13:35 <cr1901_modern> Good point XD

14:18 <larsc> wow, how did I manage misspell video as wide

14:21 <cr1901_modern> Magic

16:38 <kristianpaul> f1 instances, fpga instances in aws

18:18 <GitHub99> [artiq] r-srinivas commented on issue #633: I'm using artiq `3.0.dev py_252+git5b7e068` so it should have the fix for #629, and indeed it can create new groups now.... https://git.io/v13Be

18:45 <GitHub88> [artiq] r-srinivas commented on issue #633: I'm using artiq `3.0.dev py_252+git5b7e068` so it should have the fix for #629, and indeed it can create new groups now.... https://git.io/v13Be

18:48 <GitHub159> [artiq] r-srinivas commented on issue #631: >I had to enable debug output and run artiq_corelog locally to diagnose.... https://git.io/v13gm

18:51 <GitHub61> [artiq] r-srinivas commented on issue #623: @sbourdeauducq I was thinking of submitting a patch for the nist_qc2 gateware as well. Why does the timing fail in 3.0 exactly? https://git.io/v13gr

22:19 <GitHub162> [artiq] dleibrandt opened issue #634: pause experiment bug https://git.io/v1sTQ

22:31 <GitHub84> [artiq] klickverbot commented on issue #634: If I'm not mistaken, you currently need to close the core device connection manually by design (`self.core.comm.close()`) before calling `Scheduler.pause()`. https://git.io/v1sIz

22:44 <GitHub60> [artiq] dleibrandt commented on issue #634: Yup, that does it. Thanks. https://git.io/v1sqe

22:44 <GitHub119> [artiq] dleibrandt closed issue #634: pause experiment bug https://git.io/v1sTQ