<sb0>
rjo: using the noisy GT clock is the same as staying on the siphaser transition
<sb0>
but there is additional skews inside the FPGA that are poorly known; I guess you can extract them from vivado if you really want, but it's complicated and more prone to error than dynamic calibration
kuldeep has quit [Ping timeout: 240 seconds]
kuldeep has joined #m-labs
rohitksingh_work has joined #m-labs
mumptai has quit [Ping timeout: 240 seconds]
mumptai has joined #m-labs
futarisIRCcloud has joined #m-labs
_whitelogger has joined #m-labs
rohitksingh_work has quit [Ping timeout: 240 seconds]
rohitksingh_work has joined #m-labs
X-Scale has quit [Ping timeout: 252 seconds]
<rjo>
sb0: i mean just reverse the direction. now you are sampling si5324_clkout_fabric with rtio_rx0 in siphaser but ultimately you sample data in rtio_rx with the rtio clock in rxsynchronizer (which is the si5324, right?). i'd just turn the former around (and maybe not sample the clock but a FF toggling from it).
<rjo>
sb0: different q: what will break first if the drtio fiber gets longer and longer? and when will it break?
<sb0>
rjo: the underflow detection margin will have to be increased; the other things should not break
mumptai has quit [Ping timeout: 245 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
hartytp has joined #m-labs
<hartytp>
sb0, _florent_: I wanted to have a play with 10GBPS line rate
<hartytp>
(partially just to get some numbers for SAWG resource usage)
<sb0>
hartytp: i'd suggest focusing on the hmc7044 for now. the situation still looks very bad.
<hartytp>
AFAICT, the GTH channel PLL max multiplication factor is 25, givng a max linerate with 125MHz clock of 6.25GHz
<sb0>
then use a 250MHz clock. JESD uses elastic buffers so there are no skew issues there.
<hartytp>
what is the plan for supporting line rates above that?
<hartytp>
use the quad PLLs as well?
<sb0>
maybe, or just program the HMC to generate a higher clock frequency
<hartytp>
sb0: yes, that might be simpler
<hartytp>
so, move the GTH refclk to, say, 250MHz and then use a div 2 to generate the rtio clock
<hartytp>
I haven't got my head around what the constraints are for these clocks, so it's not obvious to me which path will work better
<hartytp>
anyway, yes, I'm mainly looking at the 7044 atm
<hartytp>
also the AD9258
<hartytp>
one thing I don't like about the HMC7044 is that it has a nice 4-way input mux, but there is no way to bypass the first PLL
<sb0>
does that mux even work?
<hartytp>
(which I really don't want to use, as low-bandwidth locks to VCXOs are a pita to sort out and can be v. drifty as we saw with the Si5324)
<hartytp>
so, AFAICT, we need to feed the input clock to the OSCIN VCXO input and configure the IC to run the VCO open-loop
<hartytp>
if that works
<hartytp>
this was the reason I originally voted against using the HMC7044 IIRC
<hartytp>
aah, but the AD9528 doesn't work above 2GHz
<hartytp>
sigh
mumptai has joined #m-labs
<hartytp>
sb0: other option
<hartytp>
is it crazy to consider doing the phase sync with only a si5324/si-phaser?
<hartytp>
idea would be to keep the HMC830, and use a fanout buffer to route that directly to the DAC clocks
<hartytp>
then put a si5324 on the RTM and use that to generate the SYSREFs
<sb0>
what is the purpose of the si5324 then? filter FPGA jitter?
<hartytp>
yes
<sb0>
it's not clear yet if that jitter is enough to cause problems
<hartytp>
just a clean way of having a programmable/low jitter phase shifter
<sb0>
the FPGA can do DDR4 at over 2Gbps/pin, so, its jitter can't be that high
<hartytp>
but, we also have to be careful about the phase drift between the AMC and RTM clocks, since the si-phaser is drifty
<hartytp>
hmm...other option is to put a fast (discrete) FF on the RTM, clocked from the RTM reference clock (at f_rtio) to retime the FPGA outputs
<hartytp>
and then find a simple phase shifter IC (no dividers, so phase deterministic)
<hartytp>
that would definitely work
<hartytp>
and seems pretty minimal complexity (replace the HMC7043 with a single FF + phase shifter)
<hartytp>
HMC7044 feels like a sledgehammer to crack a nut
<sb0>
yes, if we can ditch one HMC chip, that won't make me unhappy
<sb0>
we can use some other divider for the 125/250M. possibly fix it to 250M and divide further in the FPGA (need to check if that's possible, GTH clocking is quite messy)
<hartytp>
okay, let me see if I can find a decent phase shifter with sufficient resolution to do the job
<hartytp>
assuming that setting the divider value to 1 gives deterministic phase (which is easy to check)
<hartytp>
nope, that won't work (too coarse)
<sb0>
Output skew is the difference between any two similar delay paths while operating at the same voltage and temperature
<sb0>
wtf?
<sb0>
I don't see a spec for in-to-out skew
<sb0>
maybe using discrete delay lines is better, because then the manufacturer can't really escape spec'ing that :)
<sb0>
and we have more points to stick scope probes in case of problems
<hartytp>
sb0: right
<hartytp>
my feeling is that we can do some pretty quick measurements on a digital delay line to confirm that it works
<hartytp>
once that's done, the whole sync scheme becomes kind of trivial
<hartytp>
my concern with the HMC7044, having re-read the data sheet, is that there is so much functionality that we don't need, but which could end up causing issues (since it's not properly decoupled from the bits we do want)
<sb0>
yes. death to HMC!
<sb0>
this NB6L295 looks like a good candidate
<hartytp>
yes, I've arrived at the same conclusion
<hartytp>
those ON chips look like just what we want
<hartytp>
let me read the data sheet more carefully and but an eval board
<sb0>
we don't really need the two channels if we delay-match on the PCB
<hartytp>
really? that's bold
<hartytp>
wonder what the P variation is on the SYSREF DAC inputs
<hartytp>
for 2.4GHz we've probably got a, what, 200ps S/H window?
<sb0>
well I kept getting the same results when scanning either DAC on the current hardware
<hartytp>
okay
<sb0>
but sure, if there are two channels, we can use that
<hartytp>
well, seems safer to build in the redundancy until we have more experience
<sb0>
ok
<hartytp>
I don't see a time/T coefficient on the data sheet, but I'm happy measuring it with a hot air gun
<hartytp>
anyway, so long as it's not crazy, I don't see it being an issue
<hartytp>
I'll do some more thinking and post an issue on GitHub later today
<hartytp>
NB this does mean that we no longer have a clock for those JESD ADCs
<sb0>
it seems no one wants them anyway
<hartytp>
but, who cares? At this point it's pretty clear that no one actually wants them so let's just rip them out
<hartytp>
right
<hartytp>
also, FWIW, using a retiming FF and digital delay line to do the sync like this is exactly what Weida proposed in the document that he wrote up a couple of years back
<hartytp>
(if you remember the doc I circulated when we first designed Sayma)
<hartytp>
not saying we made the wrong decision at the time to go for the HMC7043, but it's just interesting to note that we've gone back to his solution
<hartytp>
(or, rather, that we're considering adopting it)
<hartytp>
sb0: one other question - what other bugs/issues do we need to look at before going to the next hw rev?
<hartytp>
adding delay lines to Sayma it going to be a royal pita, and those boards are fragile enough already.
<hartytp>
i'd be happy doing some proof of principle demos on eval boards and then cutting v2.0 without a full demo on hw
mumptai has quit [Remote host closed the connection]
rohitksingh_work has quit [Read error: Connection reset by peer]
hartytp has quit [Quit: Page closed]
rohitksingh has joined #m-labs
rohitksingh has quit [Remote host closed the connection]