<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
<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
<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
<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