02:37 <_whitenotifier-e> [nmigen] whitequark commented on issue #24: Project Structure And Tox - https://git.io/fhZdA

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

02:50 <whitequark> adamgreig: no there isn't, and that's why you need to specify inputs explicitly

02:50 <whitequark> or will in the future

02:51 <whitequark> i really need to rework that, i'll do that soon

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

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

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

14:07 <d_n|a> rjo: Do you have a moment? Urukul phase tracking is broken here witih your driver, and I'm not sure I understand how your calculation is supposed to work.

14:30 <rjo> sb0: is the 35t ok for the rtm? can we lock that in?

14:30 <rjo> d_n|a: in a meeting right now.

14:31 <rjo> d_n|a: do you have an example

14:31 <sb0> rjo: just make sure to use a fast speed grade

14:31 <sb0> -3 should be safe, -2 maybe

14:31 <rjo> sb0: ack.

14:33 <rjo> d_n|a: i tested the phase tracking. could you describe what you mean by broken?

14:33 <sb0> other than that, 15t/35t/50t shouldn't really matter. we can even populate based on availability/price du jour, and then have the AMC detect what is there :)

14:34 <d_n|a> rjo: Turns out the problem isn't in the calculations, but somewhere else (still looking). Still, using the timestamp before the SPI transaction for the pow calculation rather than the one of the io_update pulse seems weird.

14:35 <d_n|a> (Symptoms are phase sync relative to the timeline being lost every few seconds, with a duty cycle of about 60% synced/40% unsynced. SYNC alignment is tuned using your code. Working on it, though, sorry for the noise.)

14:37 <sb0> can't we even just drop the IDCODE packet?

14:39 <rjo> d_n|a: if the time between before the spi xfer and the io update is constant then this doesn't matter, right? it just shifts the virtual t=0.

14:40 <rjo> sb0: i think there is the tooling aspect and the reliability aspect. hacking it precludes us from pushing stuff to xilinx (or even greg).

14:41 <rjo> sb0: try it. the tool is easy to modify. but maybe the idcode packet enables something.

14:42 <sb0> greg needs to stop loving trash software, and for xilinx we can likely send minimal designs

14:42 <sb0> anyway, it likely fits in 35t with some optimization

14:44 <rjo> he loves it (and uses it) as much as you love (and use xilinx fpgas).

14:47 <sb0> whitequark: what's the latest on mor1kx performance on ecp5?

14:48 <sb0> or lm32/vexriscv

14:58 <rjo> d_n|a: does your issue show up in the use cases in https://github.com/m-labs/artiq/issues/1143#issuecomment-438318875 ?

22:35 <whitequark> sb0: haven't tried yet. should i do this with higher priority?