<rjo>
sb0: we'll have to do 'Alternate synchronization procedure #1'
<rjo>
sb0: a) we can't arbitrarily move sysref relative to dac_clk and adc_clk since it needs to meet setup-hold there. that means the "[with fine delay]" should be removed.
<rjo>
b) we can't use the fine delay on dac_clk or adc_clk. that would increase noise too much.
<rjo>
basically we can't "fine-delay the entire clock tree to meet rtio". it also would completely sabotage reproducible (fine) phase. we'll have to coarse delay sysref (by integer dac_clk cycles) and track the fractional delay across reboots.
<rjo>
but yes. we can use the hmc7044 to do the delay scan (on FPGA SYSREF only). but there will be some state saving needed.
stekern has joined #m-labs
<whitequark>
sb0: oh, I remember one reason I didn't go with full on mailbox communication
<whitequark>
er
<whitequark>
full on queue communication
<whitequark>
I thought it would make sense to have stuff like cache and watchdog requests be processed independently of the state of async RPCs
<whitequark>
but now that I look at my current implementation, it doesn't take advantage of that anyway, so meh
<GitHub22>
[artiq] whitequark pushed 1 new commit to master: https://git.io/vXOej
<GitHub22>
artiq/master b30734a whitequark: runtime: fix a race condition with async RPCs....
<whitequark>
sb0: ok that will do for now i think. i'll rewrite it in the way you want if we ever find another concurrency bug
<whitequark>
what's the next priority?
<sb0>
all mailbox RPCs will block the kernel CPU until the RPC is completed, correct?
<whitequark>
yup
<sb0>
#589
<whitequark>
ah, the si5324 thing
<sb0>
yes
<whitequark>
ok that should be easy at least
<whitequark>
do I recall it correctly that you want it to lock to clock input 1, or clock input 2, or if none of those are available, generate a clock itself?
<whitequark>
and switch to whatever becomes available?
<sb0>
whitequark, lock to clock input 1 if it's available, otherwise generate a clock itself (freerun)
<sb0>
all inputs and outputs 62.5MHz
<sb0>
rjo, first method still works, it's just that the FPGA has to know where the clock lands on each DAC, and delay sysref accordingly
<sb0>
that's basically compensating for the clock/sysref skew on the PCB
<rjo>
sb0: clk and sysrefs are trace-length matched anyway to each chip.
<rjo>
sb0: but the state saving from the second method needs to be there. and fine-delay on dac_sysref and adc_sysref is neither useful nor possible.
<sb0>
and since sysref is a synchronous signal, that uncertainty is absorbed
<sb0>
to the dacs
<rjo>
as long as you stay with in setup-hold that doesn't change anything. if you get out of setup hold, first you violate them and then you add/sub one dac_clk cycle.
<sb0>
yes
<rjo>
so. you don't need the fine delay.
<sb0>
the delay resolution is 25ps, which is way below the setup/hold window
<sb0>
i need the fine delay on sysref
<rjo>
no. it doesn't give you anything. the trace lengths are matched.
<sb0>
it does
<sb0>
we measure the rtio/sysref phase in fine delay taps, then adjust sysref
<rjo>
as i said. you can only ever delay sysref by integer multiples of dac_clk.
<sb0>
no, you can move it within its s/h window
<rjo>
that is "to the dacs" as you said.
<rjo>
to the fpga you can move it as much as you wwant to do the scan. yes.
<rjo>
but to the dac moving it within s/h doesn't change anything.
<sb0>
I mean to the DACs
<rjo>
it is smack in the middle already by design.
<sb0>
and the scheme I propose does rely on a few delay taps giving the same result at the DAC as it will be within the s/h window
rohitksingh1 has joined #m-labs
<rjo>
iiuyc, all you are trying to do is to compensate for pcb skew. but that's not needed and not the primary concern.
<rjo>
(i.e. skew between dac_sysref and dac_clk).
rohitksingh has quit [Ping timeout: 250 seconds]
fengling has joined #m-labs
<sb0>
hm, yes you're right, there's a problem
<rjo>
sb0: ? just needs a bit of nudging.
fengling has quit [Ping timeout: 268 seconds]
<sb0>
I really dislike the state store across reboots
<sb0>
it looks like microsoft or xilinx design
<sb0>
rjo, what's the problem with fine-delaying the DAC clock exactly?
<rjo>
well. alternatively we can leave it to the user to "make sure that dac_clk meets rtio_clk setup-hold".
<rjo>
sb0: the fine delay taps are very noisy.
<sb0>
where do you find that spec'd?
<rjo>
"Causes phase noise degradation of up to 12 dB; therefore, do not use on noise sensitive"
<rjo>
DCLK channels.
<rjo>
and in the model
<sb0>
ah, found it.
<sb0>
well
<sb0>
we can delay the rtio clock then
stekern has quit [Ping timeout: 260 seconds]
<sb0>
let me think how that would work...
<rjo>
but you need to store something.
<rjo>
and using the fine delay on dac_clk is conceptually flawed.
<rjo>
even if it was noiseless.
<whitequark>
bb-m-labs: force build artiq
<bb-m-labs>
build #1055 forced
<bb-m-labs>
I'll give a shout when the build finishes
stekern has joined #m-labs
<sb0>
leave it to the user to "make sure that dac_clk meets rtio_clk setup-hold" << how, without delaying dac_clk?
<sb0>
delaying rtio clock by some fixed amount?
<rjo>
they can phase delay the 100 MHz into the rack.
<whitequark>
sb0: do you care about only loss of signal, or also frequency offset?
<sb0>
there shouldn't be a long term frequency offset, though the FPGA may glitch for a while
<whitequark>
it only does very crude ranges
<sb0>
(the input)
<whitequark>
50-105 MHz
<sb0>
what does that mean exactly?
<whitequark>
wait
<whitequark>
nvm, I was wrong
<whitequark>
the FOS alarm ranges are 11-12ppm, 48-49ppm, 30ppm, 200ppm
<whitequark>
all +/-
<whitequark>
sb0: so I am looking over it again
<whitequark>
and to me it looks that "switch to freerun if CKIN1 is lost" is the default behavior
<sb0>
okay, but freerun needs setup, and you need to connect the xtal to clkin2
<whitequark>
can you elaborate?
<sb0>
freerun is about connecting the xtal (internally) to clkin22
<sb0>
*clkin2
<whitequark>
that's the wrong freerun mode
<whitequark>
that's the bit that lets you use it in freerun mode without ever locking to an external signal
<whitequark>
if you simply set it up locked to a clock and then remove the clock, it will free run by itself
<sb0>
appropriate clkin1/clkin2 divider settings need to be set so that they both result in approximately the same output freq
<whitequark>
are you sure?
<sb0>
I know, but I want the freerun mode with the xtal on clkin2
<sb0>
yes
<whitequark>
ah ok
<sb0>
when the system boots it hasn't seen any clock
<sb0>
digital hold will fail
<whitequark>
and you want clock then, right?
<whitequark>
ok
<sb0>
but this mode is designed for dealing with that
<whitequark>
then I misunderstood
<sb0>
the chip should be configured to output 62.5MHz at all times, synchronized to clkin1 whenever possible, with hitless switching when clkin1 appears/disappears, in the most automous way possible
<sb0>
*autonomous
<whitequark>
so automated revertive mode
<whitequark>
ok
<sb0>
yes
<sb0>
it can do that, it's actually designed to handle this very problem that appears in some high speed serial systems like SDI
<whitequark>
yeah, I know it can do that
<whitequark>
I just misunderstood my task
<whitequark>
ok, so we have 62.5 MHz CKIN1 and 114.285 MHz XA/XB and always 62.5 MHz CKOUT1
<whitequark>
114.285, why that crystal specifically?
<whitequark>
idle question relaly
stekern has quit [Ping timeout: 260 seconds]
<sb0>
whitequark, precisely because that frequency is weird. for some reason, the PLL performs better when the output frequency is not a multiple of the crystal frequency
<sb0>
thanks
<whitequark>
so dspllsim shows me a 0.03ppm deviation