03:55 <GitHub89> [artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vKKWP

03:55 <GitHub89> artiq/master 2099344 Sebastien Bourdeauducq: examples/handover: put slack after reset. Closes #520

04:08 <sb0> whitequark, are the si5324_read() calls absolutely necessary in si5324_init_125MHz()?

04:08 <sb0> I may want to implement this in gateware and the reads make it more annoying

04:11 <sb0> and all I need to change the phase is write to register 142, correct?

04:12 <bb-m-labs> build #561 of artiq-kc705-nist_clock is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-kc705-nist_clock/builds/561

04:14 <whitequark> let me remember

04:17 <bb-m-labs> build #276 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/276

04:20 <bb-m-labs> build #835 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/835

04:20 <whitequark> sb0: no, they are not necessary

04:20 <whitequark> you can replace them with the reset values of the registers from si5324 datasheet

04:21 <whitequark> 2: 8'b 0100 0010

04:21 <whitequark> 3: 8'b 0000 0101

04:21 <whitequark> 6: 8'b 0010 1101

04:22 <whitequark> 137: 0

05:46 <sb0> SFP working...

05:47 <sb0> now I suppose that understanding how to coax the xilinx 8b10b stuff into working will take longer than rolling my own

09:49 <whitequark> rjo: you are quite ruthless on the bug tracker

10:18 <rjo> whitequark: is that a compliment or not? ;)

10:18 <rjo> whitequark: w.r.t. tagging or triage?

10:27 <rjo> whitequark: anyway: please contradict me if you feel different about the triage and/or the handling!

10:28 <whitequark> I have no objection to either the content or the tone (I don't really think it's my call at M-Labs), the latter just strikes me as unusual compared to other open-source projects I participate in

10:29 <whitequark> that was about triage

10:33 <rjo> whitequark: you mean #522? there are a few problems that i am trying to adress. one is divergence in documentation (doesn't really happen for api docs but constantly happens for the tutorials) and the other is making proper usage and scope of the documentation clear. because i don't think it is.

10:35 <whitequark> #522, #512, I think there was some other one but I don't remember the exact number right now

10:35 <rjo> and iirc the tone is what i remember from my Debian Developer years. also the way the issues are used is becoming unconfortable to me.

10:37 <whitequark> the SNR of issues is not very high, but I don't see drastically better alternatives

10:37 <whitequark> issues are much easier to track than email threads, and IRC isn't good for asynchronous conversations that span weeks to months

10:38 <whitequark> actually the easiest, although hacky, way to handle this would be to make a repo artiq-discuss (or something) and just move all those conversations there from now on

12:07 <cr1901_modern> rjo strikes me as firm but fair. At least he doesn't seem to be taking cues from Linus

15:10 <sb0> _florent_, do I get that right that you intend to map litescope on wishbone and then access it via etherbone?

15:18 <_florent_> sb0: yes that's what I'm doing, why? :)

15:19 <_florent_> (I'm doing it since that's faster than serial for the logic analyzer)

15:30 <sb0> I'm going to look at litescope for debugging the transceiver stuff

15:38 <_florent_> ok

15:39 <key2> :)

15:54 <_florent_> rjo: I hacked something around your SPI core and got it working quite easily:

15:54 <_florent_> http://pastebin.com/nfBpd2G4

15:55 <cr1901_modern> _florent_: Let me compare that to what I have since I'm already working on it

15:56 <_florent_> to integrate it in misoc we should probably create a SPIMasterCore from your SPIMaster, remove specific Wishbone interface from it and integrate the interfaces in a SPIMaster class

16:00 <_florent_> cr1901_modern: my hack was closer to what the interface I was using before, but that doesn't mean that's the best solution

16:01 <cr1901_modern> _florent_: My solution was to directly take artiq's SPI Core and surgically graft on the CSR bus and remove the wishbone bus one reg at a time.

16:02 <cr1901_modern> (Oh and I tried to create a new test suite based on rjo's old one, but that didn't work)

16:03 <_florent_> cr1901_modern: I think you should create a core that has no interface and add two specific wrapper for wishbone and csr

16:04 <cr1901_modern> _florent_: Well, more specifically, the core CAN be used without an interface (SPIMachine)

16:05 <_florent_> cr1901_modern: I was talking about a higher level core, SPIMasterCore for example

16:06 <cr1901_modern> Hmmm, that's prob a good idea.

16:18 <sb0> _florent_, https://github.com/enjoy-digital/litex/blob/master/litex/soc/tools/remote/comm_uart.py#L29

16:18 <sb0> iirc pyserial will always give you the number of bytes you ask for

16:18 <sb0> also, "if debug: print()" is better done with logging

16:19 <sb0> what is this for? https://github.com/enjoy-digital/litex/blob/master/litex/soc/tools/remote/comm_uart.py#L12

18:24 <rjo> whitequark: i am fine with the noise. we just have to be ruthless and triage those "discuss" issues as such very rapidly.

18:24 <rjo> whitequark: ack otherwise.

18:25 <rjo> whitequark: i wouldn't do artiq-discuss though because i think we can handle it and migrating issues between those would be a pain.

18:25 <rjo> _florent_: looks fine.

18:26 <rjo> _florent_: i'd actually be very happy if you and cr1901_modern get that into misoc along those lines to be tested and used in the ad9154 demo.

18:33 <cr1901_modern> rjo: Where's the ad9154 demo?