13:58 <acathla> If I comment out my VGA submodule, everything is working. If I uncomment it, migen throw a "Unresolved clock domain: "sys"

13:59 <acathla> I cannot find how to tell migen to use the default clock everywhere except for the VGA module.

14:01 <acathla> self.clock_domains.cd_sys = ClockDomain("sys") in the Top module allows everything to build fine, but with the sys clock unplugged.

14:09 <acathla> Ok, found it. The default clock is unrequested when there is more than one clock domain, so I can do it with a plat.request("clk50") (which is not working with only one clock domain)

15:04 <GitHub-m-labs> [artiq] jordens pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/e6efe830c486b078d72ba0317741f8ca7069a4e7

15:04 <GitHub-m-labs> artiq/master e6efe83 Robert Jördens: ad9910: rewire sync delay tuning...

15:17 <GitHub-m-labs> [artiq] hartytp commented on issue #790: Testing switching out on a Kasli->Kasli->Kasli system. (`RoutingTable { 0: 0; 1: 1 0; 2: 1 1│... https://github.com/m-labs/artiq/issues/790#issuecomment-436658039

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

15:42 <GitHub-m-labs> [artiq] sbourdeauducq created new (+4 new commits): https://github.com/m-labs/artiq/compare/efd735a6ab3d^...fae95e73ada0

15:42 <GitHub-m-labs> artiq/new 3d0c3cc Sebastien Bourdeauducq: gateware,runtime: optimize RTIO output interface...

15:42 <GitHub-m-labs> artiq/new ad0254c Sebastien Bourdeauducq: Merge branch 'switching125' into new

15:42 <GitHub-m-labs> artiq/new efd735a Sebastien Bourdeauducq: Revert "drtio: monitor RTIOClockMultiplier PLL (#1155)"...

15:42 <GitHub-m-labs> [artiq] hartytp commented on issue #790: Posting detailed testing notes here so I have them to refer back to in the future. Mute if you're not interested!... https://github.com/m-labs/artiq/issues/790#issuecomment-436667505

15:45 <GitHub-m-labs> [artiq] hartytp commented on issue #790: On a few occasions I've seen errors after cycling the repeater... https://github.com/m-labs/artiq/issues/790#issuecomment-436668707

15:47 <sb0> pulse rate is 60% faster

15:50 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #790: When you shut down the repeater, it probably sends glitches/bogus data. The error reporting function is only run while the link is up, which is why you are seeing the message with a delay. https://github.com/m-labs/artiq/issues/790#issuecomment-436670578

15:54 <GitHub-m-labs> [artiq] jordens deleted urukul-sync at 6fb1827: https://github.com/m-labs/artiq/commit/6fb1827

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

15:57 <rjo> sb0: nice

16:00 <GitHub-m-labs> [artiq] hartytp commented on issue #790: ack. Anyway, so far I haven't managed to break anything which is always a good sign...... https://github.com/m-labs/artiq/issues/790#issuecomment-436674432

16:00 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #790: Looks normal. https://github.com/m-labs/artiq/issues/790#issuecomment-436674648

16:02 <GitHub-m-labs> [artiq] hartytp commented on issue #790: > Looks normal.... https://github.com/m-labs/artiq/issues/790#issuecomment-436675341

16:03 <GitHub-m-labs> [artiq] sbourdeauducq pushed 1 new commit to new: https://github.com/m-labs/artiq/commit/aadf5112b7e97d234cbdb5bb8de967cf79aef510

16:03 <GitHub-m-labs> artiq/new aadf511 Sebastien Bourdeauducq: rtio: remove incorrect comment

16:07 <GitHub-m-labs> [artiq] hartytp commented on issue #790: - [x] timing is deterministic between SERDES and simple TTLs both on the master... https://github.com/m-labs/artiq/issues/790#issuecomment-436677050

16:07 <bb-m-labs> build #2672 of artiq is complete: Exception [exception python_unittest_2 board_unlock_1] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2672 blamelist: Robert J?rdens <rj@quartiq.de>

16:10 <GitHub-m-labs> [artiq] jordens commented on issue #790: As another data point I had also tested the switching branch with 125 MHz RTIO (just master-satellite with DIO, without another repeater through) a while back and ran it through the usual stress testing and determinism tests and found no additional issues.... https://github.com/m-labs/artiq/issues/790#issuecomment-436678208

16:21 <sb0> whitequark: in what order (which 32-bit word first) does llvm store 64-bit values? is that constant and can it be enforced?

16:21 <sb0> on or1k ofc

16:28 <GitHub-m-labs> [artiq] hartytp commented on issue #790: @jordens ack. Once I've finished basic testing, measured latencies etc, I'll port an experiment over to it and check that Zotino, Urukul, SU-Servo etc still work https://github.com/m-labs/artiq/issues/790#issuecomment-436685358

16:28 <sb0> if i == 0 and insn.op == "printf" or i == 1 and insn.op == "rtio_log":

16:28 <sb0> lloperands.append(self.llbuilder.extract_value(lloperand, 0))

16:28 <sb0> whitequark: ^ what does this do? I'm removing the timestamp argument to rtio_log, how should I adapt this code?

16:31 <sb0> just change i == 0?

16:31 <sb0> it becomes just like printf...

17:19 <GitHub-m-labs> [artiq] jordens pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/fcb611d1d2ccb7b69feb1a4eb9d1e46dc564601a

17:19 <GitHub-m-labs> artiq/master fcb611d Robert Jördens: test_ad9910: don't expect large SYNC_IN delay margins...

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

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

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

21:33 <whitequark> sb0: re: 64-bit values: it is constant in practice, but it is not enforced

21:33 <whitequark> and it would be cleaner to store the halves explicitly

21:33 <whitequark> iirc we discussed this

21:33 <whitequark> re: rtio_log, yes, it becomes just like printf

23:17 <sb0> whitequark: how could you store the halves explicitly?

23:19 <whitequark> sb0: the same way as in C, basically

23:19 <whitequark> uhh, sec

23:20 <sb0> whitequark: the idea is to replace the "now" memory location with the csr

23:20 <whitequark> yes, i remember that we discussed this

23:20 <whitequark> let me find it in the bugtracker

23:21 <whitequark> sb0: https://github.com/m-labs/artiq/issues/636#issuecomment-377291124

23:21 <whitequark> so, a), you can rely on LLVM's ordering of halve writes, it will not change randomly or get reordered

23:21 <whitequark> because there's no code to do that

23:21 <whitequark> b) it is not guaranteed by contract

23:22 <whitequark> c) cast it to i32* and write each half with ptr::write_volatile() manually

23:22 <whitequark> to guarantee that it will always work