00:21 <kc5tja> I suppose I should ask -- is it preferred that I join the devel mailing list? Looking through the archives, it seems not much discussion about nMigen is happening there (none that I've found so far, in fact). I'm guessing nMigen is predominantly being handled via IRC and Github issues?

00:47 <whitequark> correct

00:47 <whitequark> I don't really do mailing lists

02:29 <sb0> kc5tja: absolutely, do send us documentation patches

02:31 <whitequark> accepting patches via PR is way easier than messing with shitty mailing list software and unnecessary email issues like 80 column wrapping etc

02:32 <whitequark> i'm not sure if i've ever managed to send a patch using git that wasn't done via attachment

02:50 <kc5tja> Hehe, I'm working on the HDL chapter now.

03:22 <sb0> whitequark: ping re. satman size reduction

04:54 <sb0> satman is booting on the rtm :) (with a 50T FPGA)

04:54 <sb0> the si5234 locks, surprisingly the i2c switch stuff seems to behave itself

05:38 <sb0> GTP clocking does not

06:35 <kc5tja> Are multiple clock domains supported in nmigen?

06:36 <kc5tja> Put another way, what is the nMigen-native equivalent expression to Migen's "self.sync.foo += ..."?

06:50 <attie> kc5tja: still supported, iirc the syntax is now unified into domains named self.d.<something>

06:51 <attie> comb is "just another" albeit somewhat special domain

06:51 <attie> "sync" is just the default clock name

06:51 <attie> so you have self.d.comb, self.d.sync, and self.d.foo

06:53 <attie> oh and you don't use self any more

06:53 <attie> m.d.comb/m.d.sync/m.d.foo

06:54 <kc5tja> Already know about the differences in modules. I'm rewriting the Migen docs for nMigen. Major overhaul required, but I am really liking how it's shaping up.

06:54 <kc5tja> But, I'm not finding how to work with alternative clock domains.

06:55 <kc5tja> I mean, m.d.foo makes sense, but where does m.d.foo get assigned, and with what? :)

06:55 <kc5tja> The code in nMigen is so deeply indirect that I'm left completely baffled.

06:56 <kc5tja> (Basically, I'm rewriting the section on synchronous statements now, and I'm looking to provide a complete summary.)

07:00 <kc5tja> I'll need to finish this next weekend, I think. Getting late here.

07:01 <attie> I'm planning to start a new design in nmigen soonish (next month maybe?). Will gladly use any documentation :)

07:02 <attie> I just need FIFOs, which I think haven't been ported yet

07:02 <sb0> why the .d?

07:02 <attie> for name space reasons I think it was?

07:02 <attie> longish discussion with rjo a few weeks back, I vaguely remember

07:03 <attie> minimizes the amount of reserved attributes, avoids collisions with other things, but is still short to write unlike "m.domains.foo"

07:21 <_whitenotifier-e> [nmigen] sam-falvo synchronize pull request #22: Updated user guide introduction for nmigen. - https://git.io/fhszI

07:21 <GitHub-m-labs> [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/migen/commit/9da60e35c1f70845acd5134d389d562a73b09261

07:21 <GitHub-m-labs> migen/master 9da60e3 Sebastien Bourdeauducq: sayma_rtm: offer 50T option

07:21 <GitHub-m-labs> [misoc] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/misoc/commit/613da4ec2a33a78a2518e44d5b6e6f3c33f9b660

07:21 <GitHub-m-labs> misoc/master 613da4e Sebastien Bourdeauducq: sayma_rtm: use 50T and larger RAM

07:23 <_whitenotifier-e> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/476231893?utm_source=github_status&utm_medium=notification

07:23 <_whitenotifier-e> [nmigen] Success. 80.53% remains the same compared to 560bb00 - https://codecov.io/gh/m-labs/nmigen/compare/560bb007cc3c7e5921ac353311dddb49f5da180e...d15e25fc2fd430947618986143bacce6eabce758

07:23 <_whitenotifier-e> [nmigen] Success. Coverage not affected when comparing 560bb00...d15e25f - https://codecov.io/gh/m-labs/nmigen/compare/560bb007cc3c7e5921ac353311dddb49f5da180e...d15e25fc2fd430947618986143bacce6eabce758

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

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

09:05 <sb0> whee! drtio on rtm works

09:07 <sb0> (when driven by kasli with the SATA/SFP adapter + a SFP copper cable + SATA crossover cable. the link does not establish when the AMC is mastering and uses its SATA connector for some reason)

09:09 <GitHub-m-labs> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/332bd6090f5a1494ae736c031a613078f5d48bbe

09:09 <GitHub-m-labs> artiq/master 332bd60 Sebastien Bourdeauducq: satman: wait for CPLL/QPLL lock after setting drtio_transceiver::stable_clkin

09:10 <GitHub-m-labs> [artiq] sbourdeauducq pushed 1 new commit to release-4: https://github.com/m-labs/artiq/commit/0303267d7eb32e88b15b24e3a9369fd8ca1406c7

09:10 <GitHub-m-labs> artiq/release-4 0303267 Sebastien Bourdeauducq: satman: wait for CPLL/QPLL lock after setting drtio_transceiver::stable_clkin

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

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

11:40 <GitHub-m-labs> [artiq] enjoy-digital commented on issue #1166: I just did some tests with KCU105 / AD9154 + simple test design @10Gbps linerate + pattern from Artiq, here is what i have:... https://github.com/m-labs/artiq/issues/1166#issuecomment-451908763

12:14 <GitHub-m-labs> [artiq] tballance opened issue #1229: Kernel occasionally hangs indefinitely when reading from Urukul CPLD https://github.com/m-labs/artiq/issues/1229

13:36 <GitHub-m-labs> [artiq] tballance commented on issue #1003: I understand the reasons why this issue has been closed, however I feel that this is still something that is sub-optimal with Urukul and requires annoying work-around (I have just hit this as an annoyance in some of our systems).... https://github.com/m-labs/artiq/issues/1003#issuecomment-451936500

13:57 <GitHub-m-labs> [artiq] jordens commented on issue #1003: Yes. This is not an optimal design. For the attenuators, I don't see how this can be fixed without breaking up the daisy chain. The CPLD is pretty small and I am pretty sure that there are no resources left to implement a full backing state in the CPLD that could be mixed/masked on the fly with updates via SPI to allow single-attenuator updates without sideffects. But i

13:59 <GitHub-m-labs> [artiq] jordens commented on issue #1229: I can reproduce this. Initializing the CPLD (`cpld.init()`) prevents it. I'd have to look at what part of `init()` is needed exactly. https://github.com/m-labs/artiq/issues/1229#issuecomment-451942954

14:30 <sb0> ever seen this sayma jtag bug? https://hastebin.com/xapexolivu.coffeescript

14:30 <sb0> that's new to me...

14:31 <sb0> that's in the microTCA crate, so there are more paths for fuckups

14:33 <sb0> doing a MCH reboot (with the hope that it power-cycles sayma) does not help

14:37 <sb0> for all its complexity, this microTCA stuff can't even power-cycle a board

14:55 <sb0> oh and also you have to pay for NATview licenses? ffs

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

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

15:03 <sb0> and of course, the free version crashes the JVM on startup

15:03 <whitequark> the *JVM*?

15:03 <whitequark> how the fuck do they achieve that?

15:03 <whitequark> does it have some horrible native executables?

15:04 <whitequark> s/excutables/JNI libraries/

15:04 <sb0> hm, no, the JVM itself does not crash, but the program crashes with an obscure java exception and the JVM exits

15:04 <whitequark> ah.

15:04 <whitequark> can you show me the backtrace

15:04 <sb0> tried another JVM: it displays the splash screen, and then crashes with a different exception :)

15:05 <whitequark> both backtraces

15:05 <whitequark> what does it do, anyway?

15:05 <whitequark> well, what is it supposed to do.

15:05 <sb0> the second exception is less obscure: Exception in thread "AWT-EventQueue-0" java.lang.Error: Probable fatal error:No fonts found.

15:06 <whitequark> ah,so it is a windows only java application

15:06 <sb0> with the first JVM: https://hastebin.com/kosegizica.css

15:06 <whitequark> "write once, run on the same platform it was developed on"

15:07 <whitequark> oh, these assholes obfuscated it, too

15:07 <sb0> I have another 5 JVMs to go through...

15:12 <sb0> whee! it works with one of them

15:15 <sb0> now of course this thing uses UDP, so it doesn't work well over SSH tunnel

15:16 <sb0> this is of course completely undocumented and you have to use tcpdump to find out

15:16 <sb0> java is portable and microTCA is perfect for remote administration, right

15:16 <sb0> what a brilliant demonstration again

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

15:32 <hartytp> sb0: nice re rtm drtio!

15:33 <hartytp> the uTCA configuration stuff does seem pretty nasty

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

15:49 <bb-m-labs> build #2795 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2795 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>

15:53 <sb0> currently: using natview over VNC (because X is crap), with the JVM installed on debian via nix because apt-get won't install it due to libc version conflicts, and this actually works...

15:53 <whitequark> i think this is why people use docker

15:53 <whitequark> out of desperation

15:59 <sb0> amazingly, I even managed to reset sayma with it in a way that jtag works again

16:03 <sb0> it seems, there are still plenty of IPMI bugs with sayma (unless those are NAT bugs). many of the functions in natview are broken when applied to sayma.

23:30 <d_n|a> sb0: How do you want to handle fixes that should go into stable? PR to master and then cherry-pick onto the release branch, if I interpret recent history correctly?