02:07 <GitHub22> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/77f90cf93bef711c37fad9c3e46c5ab81d1742a9

02:07 <GitHub22> artiq/master 77f90cf Sebastien Bourdeauducq: test: relax RTIO counter test and print result

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

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

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

05:45 <sb0> whitequark, what's the status of the rtm fpga programming?

08:24 <whitequark> let me finish the artiq_flash changes needed for that...

15:50 <rjo> cjbe__: good that it works. no idea about the JGS516, especially weird since at least one other "GS" works. try forcing the interface speed and MDI-X on the switch? i'll try the GS728TP in a week or so.

16:01 <GitHub189> [artiq] sbourdeauducq commented on issue #788: Should this be part of ARTIQ 4.0? 5.0? Not in ARTIQ? https://github.com/m-labs/artiq/issues/788#issuecomment-360181824

16:09 <GitHub37> [artiq] jordens commented on issue #788: Waiting for... https://github.com/m-labs/artiq/issues/788#issuecomment-341490593

16:09 <GitHub190> [artiq] jordens commented on issue #788: Waiting for... https://github.com/m-labs/artiq/issues/788#issuecomment-341490593

16:12 <GitHub68> [artiq] jordens commented on issue #788: Will merge into ARTIQ when working. Let's try to hit 4.0. https://github.com/m-labs/artiq/issues/788#issuecomment-360185522

16:20 <GitHub134> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/ca4d5ae73e6082b8e3778a9c6437315c2d15e0dc

16:20 <GitHub134> artiq/master ca4d5ae Sebastien Bourdeauducq: artiq_flash: add kasli drtio variants

16:24 <rjo> cr1901_modern: what commit?

16:24 <cr1901_modern> rjo: https://github.com/jordens/misoc/commit/ed1bc46498051ee3e6a65b3370db26e78fa9d38f This one

16:25 <cr1901_modern> After this commit, a pure read chained after a write uses the correct divider

16:25 <cr1901_modern> _but_ now a pure read that waits till the master is no longer active _after_ a pure write uses the wrong divider for a full cycle

16:26 <sb0> _florent_, what do you think of my JESD scan idea? https://irclog.whitequark.org/m-labs/2018-01-23#1516706108-1516706081;

16:27 <rjo> cr1901_modern: exactly.

16:27 <sb0> rjo, so we do 3.3 after this SPI problem is fixed?

16:28 <cr1901_modern> rjo: So when I say "I found the problem", I was referring to after your fix. And I was wondering if you had gotten that far into debugging yesterday

16:29 <rjo> sb0: yes

16:29 <GitHub31> [artiq] jordens opened issue #905: spi clock divider (chained read) https://github.com/m-labs/artiq/issues/905

16:29 <rjo> cr1901_modern: i only looked at it.

16:31 <cr1901_modern> rjo: Well here's a screencap for your viewing pleasure: https://imgur.com/a/mCE8W

16:31 <cr1901_modern> write0 is being asserted far too long, so looks like I need to add extra logic to your fix to ensure write0 is deasserted properly

16:31 <cr1901_modern> So I'll be doing that now

16:31 <cr1901_modern> (note: I changed the dividers in this example)

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

17:02 <bb-m-labs> build #708 of artiq-win64-test is complete: Warnings [warnings python_coverage] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/708 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>

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

17:08 <GitHub157> [artiq] gkasprow commented on issue #854: OK, I found an error. The PHY was not correctly initialised and both clock were fighting. That's why I preferred to test it first.... https://github.com/m-labs/artiq/issues/854#issuecomment-360204211

17:10 <GitHub7> [artiq] sbourdeauducq commented on issue #854: > This is what the TXCLK looks like with register GMIICR = 0x8c80... https://github.com/m-labs/artiq/issues/854#issuecomment-360204885

17:11 <GitHub82> [artiq] sbourdeauducq commented on issue #854: > This is what the TXCLK looks like with register GMIICR = 0x8c80... https://github.com/m-labs/artiq/issues/854#issuecomment-360204885

17:37 <GitHub110> [artiq] gkasprow commented on issue #854: @sbourdeauducq yes, my test bit stream generates this clock.... https://github.com/m-labs/artiq/issues/854#issuecomment-360213407

17:38 <sb0> rjo, setting OPTION_DCACHE_SET_WIDTH=10 fixes the mor1kx timing issue. but then the vivado trash fails timing in, uh, an innocuous-looking part in the middle of liteeth, with a massive routing delay

18:04 <rjo> sb0: and the 8 previously as well as the default 9 are heuristic values or is there magic behind them?

19:19 <rjo> sb0: why does more dcache logic make timing closure easier?

20:17 <rjo> cr1901_modern: https://github.com/m-labs/misoc/compare/master...jordens:spi-clock-divider

20:17 <rjo> cr1901_modern: that's still WIP, didn't test it yet.

20:20 <cr1901_modern> rjo: Ack. Testing now.

20:24 <cr1901_modern> rjo: This appears to have fixed it

20:29 <cr1901_modern> rjo: You got a fix before I was able to. I was also experimenting w/ something: https://github.com/cr1901/misoc-spi-tb

20:30 <cr1901_modern> Specifically: https://github.com/cr1901/misoc-spi-tb/blob/master/mk-verilog.py#L45-L53

20:30 <cr1901_modern> (I wanted to prove that the bug you filed can't occur. But I couldn't properly set up the proof :()