03:33 <sb0> cjbe, I'm using this pair: https://www.fs.com/products/36353.html / https://www.fs.com/products/36351.html

03:33 <sb0> and some meters of fiber

03:51 <sb0> cjbe, I suppose you modified the gateware? also if your experiment compiles with "t.pulse(10*us)(" (no syntax error) that would be a compiler bug

03:56 <sb0> the "received packet of an unknown type" errors in the satellite would point to some data corruption, which is consistent with the difference between the cables

04:04 <sb0> whitequa1k, what is the status of the buildbot?

04:05 <sb0> can it build release-3?

05:13 <GitHub62> [artiq] sbourdeauducq commented on issue #854: FINALLY got the damn thing to behave:... https://github.com/m-labs/artiq/issues/854#issuecomment-368284173

05:18 <GitHub164> [misoc] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/misoc/commit/2034579bca9fa25962042567b651baff79ef3965

05:18 <GitHub164> misoc/master 2034579 Sebastien Bourdeauducq: sayma: use working MMCM placement and phases

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

05:27 <whitequa1k> sb0: broken for unknown reasons.

05:27 <whitequa1k> I mean.

05:28 <whitequa1k> conda is broken for unknown reasons

05:32 <sb0> whitequa1k, is that still the wrong version of artiq-dev being installed?

05:32 <sb0> iirc that didn't affect release-3. is that one working at least?

05:49 <whitequark> no, needs conda updated

05:49 <whitequark> and release-3 works only by accident

05:49 <whitequark> it's still the wrong version, just the compatible one

05:55 <GitHub29> [artiq] sbourdeauducq commented on issue #854: Well, even *reloading* the *same* bitstream sometimes produces different results. Sayma is such a pain in the ass, screwing you at every turn. https://github.com/m-labs/artiq/issues/854#issuecomment-368285814

07:28 <GitHub3> [artiq] sbourdeauducq commented on issue #854: Additionally, the MMCM behaves differently when it has had its phase edited using the ``open_checkpoint`` method, and when using the original phase. ... https://github.com/m-labs/artiq/issues/854#issuecomment-368289503

11:25 <sb0> okay I am able to get (but non-reproducibly, as usual) 0% packet loss with SAWG enabled

11:26 <sb0> I wonder if the MMCMs work correctly, this behavior looks kinda similar to the SDRAM and serwb shitbugs

11:41 <sb0> I just don't get it, the TX phase adjustement may actually be doing nothing, sometimes it works sometimes it doesn't, based on god-knows-what set of conditions

11:42 <sb0> the exact history of vivado commands seems to have an effect, even if they result in the same properties set on the MMCMs

11:44 <sb0> it's like xilinx is taking the piss

11:45 <sb0> the behavior with the smaller traffic generator, of course, was deterministic, so that you have to spend time dealing with a huge and slow to compile design

12:36 <GitHub190> [artiq] gkasprow commented on issue #854: Is it really problem with Tx cock phase which is hard to explain because it sits in same bank,... https://github.com/m-labs/artiq/issues/854#issuecomment-368305825

12:45 <rjo> sb0: what about constraints like actually fixing input output delays?

13:26 <GitHub43> [artiq] sbourdeauducq commented on issue #854: Yes. Using the net_trace option I can see that frames are received correctly and the runtime answers them. https://github.com/m-labs/artiq/issues/854#issuecomment-368309279

13:41 <GitHub119> [artiq] gkasprow commented on issue #854: OK, so I will check with scope how TX delay affect the clock and data relationship. Maybe RC matching circuit will solve this issue. The trace length between FPGA and PHY is high so reflections occur. https://github.com/m-labs/artiq/issues/854#issuecomment-368310337

13:52 <sb0> rjo, it's IDDR/ODDR which AFAIK are per-pin dedidacted IOB resources with fixed timing

15:39 <cjbe> rjo: I have been using lab.m-labs to do some Sayma-Sayma DRTIO tests

15:40 <cjbe> sb0: I modified the Kasli Master and Satellite to have 4 TTLOut and 4 TTLInOut (without serdes) at each end

15:40 <cjbe> sb0: yeah - the trailing '(' was a copy-paste error

15:46 <cjbe> sb0: I assume you would not expect a 2m DAC cable to have SI issues? I have FS.com 36648 (0.5m) and 36651 (2m) - both are 10G SFP+ DAC

15:48 <sb0> cjbe, when you're not using the drtio link and with that cable, is there anything reported?

15:48 <sb0> (i.e. don't run kernels)

15:53 <GitHub91> [misoc] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/misoc/commit/60eb326ba8d17bca7c2cb61d30b8cb7d3faaf929

15:53 <GitHub91> misoc/master 60eb326 Sebastien Bourdeauducq: sayma: work around Vivado MMCM/set_property problems

15:53 <GitHub150> [artiq] sbourdeauducq commented on issue #854: With the current MiSoC (60eb326b), Ethernet will fail upon startup in ~3/4 the cases due to 100% of the transmitted packets being lost. RX is OK as can be seen by using ``net_trace 1``. In the ~1/4 of startup cases when it works, there is no packet loss reported by ``ping``. This works with and without SAWG.... https://github.com/m-labs/artiq/issues/854#issuecomment

15:55 <GitHub121> [artiq] gkasprow commented on issue #854: I will explore this case tomorrow. This is indeed strange. https://github.com/m-labs/artiq/issues/854#issuecomment-368320271

15:57 <bb-m-labs> build #393 of misoc is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/misoc/builds/393

16:02 <rjo> cjbe: ok. good.

16:37 <sb0> the I MMC command doesn't seem to have an effect either way (doesn't unbreak a broken ethernet, doesn't break a working one)

16:38 <sb0> so, it looks a bit more like a FPGA and not a MMC issue

16:39 <rjo> sb0: are the delays also fixed w.r.t. the clock input?

16:39 <sb0> I'm pretty amazed at how something as simple as ethernet can become messed up like that

16:40 <rjo> sb0: or is this definitely only the tx half? and you are changing the timing between the tx clock (output) and the data?

16:41 <sb0> rjo, right now I'm looking at non-reproducibility across reloads of the same bitstream

16:41 <sb0> sometimes I load the FPGA and things are working perfectly, 0% packet loss either way

16:41 <rjo> i understand that. but "packet loss" is which half?

16:41 <sb0> sometimes RX works 100% (or close to 100%), but all TX packets are lost

16:41 <sb0> TX

16:41 <rjo> and the tx clock is derived from sys_clk?

16:42 <sb0> yes

16:42 <sb0> it's the same MMCM that generates both

16:42 <sb0> the ODDR that drive the data and txctl are clocked by sys_clk

16:43 <sb0> the clock that goes to the PHY is driven by another output of the same MMCM

16:43 <rjo> and (after all the back and forth with the mmc configuring the phy) we know that the phy is using that txclk to register the data?

16:44 <sb0> yes, otherwise I don't see how we can get 0% packet loss

16:44 <sb0> large packets (1000+ bytes) are also transmitted correctly

16:45 <sb0> and even when the board has been running for ~30min with a working ethernet, it keeps working

16:46 <rjo> this is nibble-based, right? how do those phys determine which nibble is which? txclk phase?

16:46 <sb0> it's DDR nibbles

16:46 <sb0> send 4 bits on rising edge, another 4 bits on falling edge

16:50 <cjbe> sb0: sample size 1: I get an aux packet error a few ms after the 'Si5324 is locked' message on the slave, but no other errors for ~10 s, until I ran the kernel

17:13 <GitHub149> [migen] jordens pushed 1 new commit to master: https://github.com/m-labs/migen/commit/0996e0b96b9e7951429323a7473058de59397ffb

17:13 <GitHub149> migen/master 0996e0b Robert Jordens: sim: more verbose exec/eval request ValueError...

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

18:17 <rjo> sb0: just to check: cd_eth_rx.clk and eth_clocks.rx are ok to have a random phase of 0-7 ns

18:23 <rjo> sb0: forget it. didn't read that correctly.

18:27 <rjo> sb0: hmm the BUFGCE_DIV divider that makes cd_sys and the PLL divider that makes eth_clocks.tx might have a random offset.

18:29 <rjo> sb0: i think you want to drive BUFGCE_DIV.CLR with a flop from eth_clock.tx.

18:29 <rjo> sb0: that is exactly the 1/4 chance on boot you are seeing.

19:18 <GitHub144> [artiq] jordens commented on issue #854: Probably the phase between BUFGCE_DIV divider driving the data and the PLL divider driving TXCLK. https://github.com/m-labs/artiq/issues/854#issuecomment-368336259

19:36 <cr1901_modern> rjo: Is it your intent to make proxy bitstreams that write to the flash in qspi mode in the future?

19:36 <GitHub47> [pdq] jordens pushed 2 new commits to spi2: https://github.com/m-labs/pdq/compare/65f2a2c10b07...8d610129bae1

19:36 <GitHub47> pdq/spi2 7d68819 Robert Jordens: spi: reset cs_n high...

19:36 <GitHub47> pdq/spi2 8d61012 Robert Jordens: tests: port to spi2

21:01 <rjo> cr1901_modern: no. that doesn't make sense. jtag is still 1 bit per cycle.