sb0_ changed the topic of #m-labs to: https://m-labs.hk :: Logs http://irclog.whitequark.org/m-labs
proteusguy has quit [Ping timeout: 244 seconds]
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale has joined #m-labs
rohitksingh_work has joined #m-labs
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #m-labs
<sb0> rjo: confirmed that the 9912 works on 4.0
<sb0> bisecting...
<sb0> and that's in the coredevice driver, not the gateware or firmware
<sb0> as I thought it's 56315203a95bd2ebeb3ae9c64021fcdbfef5f11e
<sb0> whitequark: ^
proteusguy has joined #m-labs
<GitHub-m-labs> [artiq] sbourdeauducq opened issue #1252: no RF from AD9912 due to compiler change https://github.com/m-labs/artiq/issues/1252
futarisIRCcloud has joined #m-labs
<GitHub-m-labs> [artiq] sbourdeauducq closed issue #1249: Compiler: Generating binary ints https://github.com/m-labs/artiq/issues/1249
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1125: ```... https://github.com/m-labs/artiq/issues/1125#issuecomment-457094087
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1125: ```... https://github.com/m-labs/artiq/issues/1125#issuecomment-457094712
<GitHub-m-labs> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/0a0e8c3c933c050aa9d71aac2e404e3f98e9b900
<GitHub-m-labs> artiq/master 0a0e8c3 Sebastien Bourdeauducq: nix: bump migen/misoc
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
cedric has quit [Ping timeout: 250 seconds]
cedric has joined #m-labs
cedric has quit [Changing host]
cedric has joined #m-labs
<GitHub-m-labs> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/31592fc8e472a740241cf5a3f792a5e07a08d1b6
<GitHub-m-labs> artiq/master 31592fc Sebastien Bourdeauducq: nix: install flash proxy bitstreams with OpenOCD
<bb-m-labs> build #2331 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2331
<bb-m-labs> build #2332 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2332
<bb-m-labs> build #2865 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2865 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
<sb0> rjo: the range of the HMC7043 coarse delay is 8.5 CLKIN periods, so, at high CLKIN frequencies we can't scan by a whole RTIO cycle to check s/h....
<sb0> it should still work though but it makes the scan more annoying
<sb0> well, no, it won't work. you need to be able to actually align SYSREF with RTIO, since it can have any phase at startup (periods of the 1-2.4GHz input clock)
<sb0> if we connect RFSYNCIN to the FPGA, we can make it work though
<bb-m-labs> build #2333 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2333
<sb0> but using the hmc7043 will limit the maximum DAC frequency.
<sb0> if 1.2GHz with 2X interpolation works reliably, is there any reason to use 600MHz?
<sb0> RFSYNCIN to 150MHz clock input also works I guess
<bb-m-labs> build #2334 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2334
m4ssi has joined #m-labs
<GitHub-m-labs> [artiq] sbourdeauducq pushed 2 new commits to master: https://github.com/m-labs/artiq/compare/31592fc8e472...f8b39b0b9a98
<GitHub-m-labs> artiq/master 07b5b0d Sebastien Bourdeauducq: kasli: adapt Master target to new hardware
<GitHub-m-labs> artiq/master f8b39b0 Sebastien Bourdeauducq: sayma: enable 2X DAC interpolation...
<sb0> anyway, I don't see a nice way out with the HMC7043 that works well (in theory) above ~1.2GHz where we can't use the coarse delay to align SYSREF with RTIO anymore
<sb0> we might need to run the JESD core at 250MHz and add a second gearbox, but 1) that's complicated and 2) the Ultrascale I/O jitter and other problems will be the next limit
<sb0> so I think, stay with the discrete elements
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1129: Doesn't happen anymore after switching DAC clock to 1.2GHz with 2X interpolation. https://github.com/m-labs/artiq/issues/1129#issuecomment-457163496
<GitHub-m-labs> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/a92cc91dcbf6bfb5d9eb68a7ffd5d0cdeb2f4b5f
<GitHub-m-labs> artiq/master a92cc91 Sebastien Bourdeauducq: kasli_sawgmaster: correctly tune DDS and SAWG
rohitksingh_work has quit [Read error: Connection reset by peer]
<GitHub-m-labs> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/bbac92442f5db6d12cf4a080c58d686e58226207
<GitHub-m-labs> artiq/master bbac924 Sebastien Bourdeauducq: sayma: check hmc7043 slip period
<sb0> there are still some sysref slip issues, for some reason it seems to affect only the fpga. could be a gateware bug this time.
<sb0> anyway it probably doesn't make sense to debug the hmc7043 sytem further
<bb-m-labs> build #2866 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2866 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
<sb0> FWIW I didn't see any HMC830 lock issues or DAC problems at 1.2GHz over the few dozen reboots I did today
<GitHub-m-labs> [artiq] jordens opened issue #1253: set default experiment submission scheduling options from experiment code https://github.com/m-labs/artiq/issues/1253
<bb-m-labs> build #2335 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2335
<bb-m-labs> build #2336 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2336
<bb-m-labs> build #2867 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2867 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
jevinski_ has joined #m-labs
<sb0> hartytp: do you have a sayma patch ready for 4X interpolation?
<GitHub-m-labs> [artiq] cjbe commented on issue #1253: @jordens I agree this would be very useful - IIUC this is similar to #692 https://github.com/m-labs/artiq/issues/1253#issuecomment-457210572
hartytp has joined #m-labs
<hartytp> sb0: I don't think so, I have a rather messy fork with a lot of changes from back when I was working on sync
<hartytp> sb0: what's your plan for porting sayma DAC/JESD init to kernels?
<sb0> hartytp: okay, but do you know what to change?
<hartytp> just the DAC interpolation register value and the PLL dividers
<hartytp> pll/hmc7043
<sb0> 830 too, no?
<sb0> do you know already what the values should be?
<sb0> hartytp: idk. that doesn't really worry me, unlike hardware/silicon issues
<sb0> and what the DAC sync plan should be
<sb0> no matter if rust or kernels does it
<sb0> hartytp: so far there has been no test at all at 1GHz and 2GHz rates, correct?
<sb0> hartytp: and btw Greg apparently managed to get proper LVDS lines between AMC and RTM, so we can keep serwb at the beginning
<sb0> (but I still need to review those lines, by compiling a test design...)
<hartytp> sb0: the reason I want it is that it would make it much faster for me to play with DAC sync if I can do it from python
<sb0> rjo: https://hastebin.com/sijeyiqegu.rb << this reports 0 windows on kasli-1/tester
<sb0> latest master
<hartytp> assuming you're using a 100MHz ref then hmc830::set_dividers(1, 24, 0, 1);
<hartytp> gives 2.4GHz PLL output
<hartytp> then just set the HMC7043 dividers to 1
<hartytp> for the DACs and set the interpolation bits to 4 on the DAC
<hartytp> that worked for me
<sb0> okay. and you're saying DAC sync was breaking?
<hartytp> so far no testing at 1/2GHz
<sb0> it seems to work fine now (between the DACs) at 1.2GHz with the 7043
<hartytp> never tested with the HMC7043
<hartytp> only with the delay line
<sb0> one advantage of frequencies above 1.8GHz is that one cycle is within range of the 7043 analog delay
<sb0> and btw I didn't see ramp glitches today either
<sb0> (vivado 2018.3)
<hartytp> okay, good!
<hartytp> I had some issue with the DAC getting upset with sync pulses until I switched to one shot then monitor mode.
<hartytp> honestly though I can't remember what the details were. Would have to re-read the GitHub issue/IRC logs
<sb0> hm, why do we have the 830 output divider currently enabled for 1.2GHz?
<hartytp> ?
<hartytp> min VCO freq is 1.5GHz
<hartytp> so you need the divider
<hartytp> scratch that
<hartytp> I guess you can use the HMC7043 dividers
<hartytp> anyway, the PLL can't produce 1.2GHz directly
<sb0> ah. right.
<sb0> so the issue we have at 600MHz, we also have at 1200MHz
<hartytp> yes
<sb0> okay, i'll do some high-speed tests tomorrow
<hartytp> for the adf the min vco freq is 3.4ghz fwiw
proteusguy has quit [Remote host closed the connection]
<sb0> yeah ok, but the adf has the divider in the feedback path
<hartytp> so unless the output dividers really do what we want, it's actually worse
<hartytp> yes
<sb0> assuming no bugs, there is no disadvantage to using exclusively frequencies above 1.5GHz or even 1.8GHz (if we keep the 7043), correct?
<sb0> we can use interpolation
<hartytp> sb0: correct
<hartytp> well, more dac power consumption, I guess
<hartytp> but generally I'd want to push the clock rate up as much as possible
<sb0> just configure the uTCA fans in jet engine mode. at least this uTCA stuff is good for something...
<hartytp> the divider sync issue is strictly a plan B/risk mitigation stratergy in case of unforseen sync issues at higher dac clock frequencies
<hartytp> :)
<hartytp> jet engine mode fans...uTCA chassis: the world's least aerodynamic drone
hartytp has quit [Quit: Page closed]
<sb0> okay, so I'll try 2.4GHz tomorrow, and then rethink the SYSREF/RTIO alignment code considering that 1. the 7043 analog delay covers one cycle 2. the ultrascale I/O timing needs to have better stability than one 2.4GHz cycle
<sb0> the first thing to see is if the DACs can sync with each other at that frequency. in theory the I/Os are properly designed for that, unlike the shaky Xilinx ones
<sb0> ah, let me see if the US native mode i/o wizard is still complete trash with vivado 2018.3... they improved the transceiver one, so, there's a chance
<GitHub-m-labs> [artiq] jordens pushed 1 new commit to release-4: https://github.com/m-labs/artiq/commit/162ce813ea67c349af82787283f4908b76261ae8
<GitHub-m-labs> artiq/release-4 162ce81 Robert Jördens: ad53xx: ignore F3 (reserved)...
<GitHub-m-labs> [artiq] jordens pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/8c5a50259149cb4963ca23bfd55b8c1d8912a9fe
<GitHub-m-labs> artiq/master 8c5a502 Robert Jördens: ad53xx: ignore F3 (reserved)...
<GitHub125> [smoltcp] dlrobertson opened issue #271: Move to rust 2018 edition https://github.com/m-labs/smoltcp/issues/271
<GitHub-m-labs> [artiq] jordens closed issue #1253: set default experiment submission scheduling options from experiment code https://github.com/m-labs/artiq/issues/1253
<GitHub37> [smoltcp] whitequark commented on issue #271: This would be a problem for M-Labs because the ARTIQ Rust is not yet at the version that has the edition. https://github.com/m-labs/smoltcp/issues/271#issuecomment-457227701
<sb0> ah yep, still total trash written by people who don't know verilog
proteusguy has joined #m-labs
<GitHub80> [smoltcp] crawford commented on issue #271: Crates can use independent editions. smoltcp can switch to 2018 while the rest of your code stays on 2015. It works quite well in practice (I'm already using a mix of 2018 and 2015 with smoltcp). https://github.com/m-labs/smoltcp/issues/271#issuecomment-457233732
<bb-m-labs> build #2337 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2337
<GitHub52> [smoltcp] whitequark commented on issue #271: > smoltcp can switch to 2018 while the rest of your code stays on 2015.... https://github.com/m-labs/smoltcp/issues/271#issuecomment-457238539
<bb-m-labs> build #2338 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2338
cjbe has left #m-labs ["Leaving"]
<bb-m-labs> build #1008 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/1008
<bb-m-labs> build #2868 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2868
<bb-m-labs> build #2339 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2339
<bb-m-labs> build #2340 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2340
<bb-m-labs> build #1009 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/1009
<bb-m-labs> build #2869 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2869
rohitksingh has joined #m-labs
m4ssi has quit [Remote host closed the connection]
rohitksingh has quit [Remote host closed the connection]
zng has quit [Ping timeout: 244 seconds]
zng has joined #m-labs
jevinskie has joined #m-labs
jevinski_ has quit [Ping timeout: 250 seconds]
jevinskie has quit [Ping timeout: 240 seconds]
jevinski_ has joined #m-labs
zoobab has quit [Ping timeout: 245 seconds]
zoobab has joined #m-labs
mumptai has joined #m-labs
mumptai has quit [Quit: Verlassend]
_whitelogger has joined #m-labs