<sb0>
hartytp, and you are aware that there are two si5324, right? the AMC one does not have a connection into the JESD204 clock labyrinth.
<sb0>
on the other hand, the AMC one happens to have a uFL output that can be connected to the SMA input on the other side. then if everyone uses the same coax, we can do board sync this way
<sb0>
s/uFL/SMA
<sb0>
why was 100MHz chosen as the reference frequency for the HMC830? can't it be changed to the 150MHz RTIO frequency everywhere?
<GitHub152>
[smoltcp] jhwgh1968 commented on issue #232: I feel like I'm close. Now I just want to write one new regression unit test for non-windowed negotiation, and the test macros are not working the way I expect.... https://github.com/m-labs/smoltcp/pull/232#issuecomment-397934860
<sb0>
note to self: if async DRC ever lands in migen, it should treat all IOs as asynchronous and requiring a synchronizer unless marked otherwise by the user ...
balrog has joined #m-labs
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 260 seconds]
<sb0>
oh great, the sayma has completely stopped producing rf
<sb0>
exactly what I wanted
<sb0>
sigh
X-Scale has quit [Quit: HydraIRC -> http://www.hydrairc.com <- Would you like to know more?]
<GitHub-m-labs>
artiq/master 6272052 Robert Jördens: ad9154: don't drive the bsm with txen pins
rohitksingh_work has joined #m-labs
rohitksingh_wor1 has quit [Ping timeout: 248 seconds]
<sb0>
rjo, okay, that works. I had assumed you had tested it and I did something wrong with the board rework...
hartytp has joined #m-labs
<hartytp>
sb0: "the phase can be measured and controlled by the FPGA instead, afaik? "
<hartytp>
there is more than one way of doing this
<hartytp>
feeding the HMC7043 from the Si5324 is a pretty trivial way of synchronizing the phases
<hartytp>
that will work up to quite high DAC clocks
<sb0>
you mean, the 830?
<hartytp>
but, there are other ways as well
<hartytp>
yes, it would need to go to both the 830 and to the 7043
<sb0>
connecting to the 7043 actually sounds quite tricky
<hartytp>
?
<hartytp>
I'd solder a pair of pieces of coax to the AC coupling pads at the Si5324 output/HMC7043 input
<hartytp>
shield on a shirt pig-tail to ground
<hartytp>
that's not so hard
<hartytp>
short
<sb0>
but rfsyncin has to meet s/h wrt the DAC clock, otherwise, you get 1 DAC clock cycle jitter
<hartytp>
yes
<hartytp>
so you need to adjust the phase of the Si5324 to meet S/H
<sb0>
and that's the only indication you get
<hartytp>
I'd do it with a fast scope
<hartytp>
only needs to be done on one board
<hartytp>
at least for the DAC clocks we're currently working at
<hartytp>
for 2.4GHz it would get sketchy
<hartytp>
for the HMC7044 it's trivial since one only needs to meet S/H w.r.t. the RTIO clock
<sb0>
well. the FPGA has to look at sysref anyway to synch TTLs with the DACs
<hartytp>
yes, but that only has to meet S/H w.r.t. the rtio clock, right
<sb0>
yes
<hartytp>
so, no big dealy
<hartytp>
deal
<hartytp>
question is whether you really want to go down a path of using the FPGA to measure phases on a 2.4GHz clock and get that to work really robustly on many boards
<hartytp>
sounds like a headache to me
<sb0>
right now we are doing 1.2GHz. and things like siphaser are good to ~90ps, right?
<hartytp>
sb0: so long as it works reliably, I'm happy with you doing it any way you want
<hartytp>
many ways of skinning a cat
<sb0>
I'm thinking of using siphaser to align the DAC clock, and use the 5324 inter-output skew in case the phase we want breaks DRTIO data timing inside the FPGA
<hartytp>
sure, that's fine, but you will need to test it at 2.4GHz at some point
<hartytp>
just turn 4x interpolation on and change the dividers
<hartytp>
" hartytp, and you are aware that there are two si5324, right? the AMC one does not have a connection into the JESD204 clock labyrinth. "
<sb0>
yes
<hartytp>
yes, I was assuming you'd get DRTIO on the RTM working first
<sb0>
we need an extra cable, right?
<rjo>
sb0: i couldn't test.
<hartytp>
"why was 100MHz chosen as the reference frequency for the HMC830? can't it be changed to the 150MHz RTIO frequency everywhere? "
<hartytp>
it's more common for references
<hartytp>
there was only a vague plan, but I'd personally rather switch to only supporting DRTIO as a reference if the noise/drift checks out
<sb0>
DRTIO on the RTM first is additional complexity, another unknown, and the additional hop certainly doesn't help phase noise
<sb0>
or drift
<hartytp>
well, what's our long term plan here?
<hartytp>
Personally, I want to clock Sayma from the RTIO clock rather than having to use the LLRFBP or external power splitters + FP SMA
<hartytp>
so, that WR clock needs to make it to the RTM eventually
<sb0>
okay, but can't we just connect it directly via RTM connector?
<hartytp>
so, that's either via DRTIO and WR or we add an extra "clock" line to the RF BP (and then have to worry about x-talk on that connecftor)
<hartytp>
short term or long term?
<hartytp>
short term, yes, long term, no
<sb0>
keep DRTIO-on-RTM for less critical things like RF switches, attenuators, etc.
<sb0>
why not?
<hartytp>
wait, do you mean via coax or by adding an extra clock pair over the AMC<->RTM connector?
<sb0>
seems I got sc1 to work on the HK board. the jref edge was in the small s/h zone where it should not be. setting digital phase to 2 on that hmc7043 channel appears to solve the problem
<sb0>
but needs more testing
<hartytp>
sb0: nice
<sb0>
hartytp, add an extra clock pair on the amc/rtm connector
<hartytp>
okay, well two comments about that:
<sb0>
hartytp, btw, in your sc1 tests, the phase difference between the dac outputs was near-zero, right?
<hartytp>
1. We have a very limited number of IO for that and I'd like to reserve some for e.g. a SU-Servo type ADC
<sb0>
hartytp, before I got ~1 rtio cycle of skew
<sb0>
and ~0 intermittently
<sb0>
now it seems I only get ~0
<hartytp>
2. we have to worry about cross-talk n.b. any LVDS ADC won't be scrambled (I guess we could do some hack like route the ADC to the RTM and then scramble it and maybe even route it through a SERDES to reduce the amount of IO required, but seems like a PITA)
<sb0>
hartytp, hmm, can we keep things simple please?
<sb0>
does sayma really need an ADC?
<hartytp>
yes
<hartytp>
that's non-negotiable
<hartytp>
how do you want to do laser noise-eating
<hartytp>
?
<hartytp>
it could be JESD204B in principle, but as it needs to be 16-bit that's a hell of a lot more expensive
<hartytp>
and hard to argue that it's in any way simpler
<hartytp>
anyway, I'd argue that an LVDS ADC like Sampler is very simple
<hartytp>
what's the alternative? Add an external ADC + RF modulator?
<sb0>
hmm, maybe run su-servo entirely on the RTM
<hartytp>
simple has to take into account how this hardware will actually be used and what the minimum functional requirements are, not just what makes your life easiest
<sb0>
control it via DRTIO
<hartytp>
how does that work?
<hartytp>
how do you get the ASF back to the SAWG?
<hartytp>
adding an external modulator to the AFE mezzanine seems crazy when we can just modulate the SAWG amplitude
<hartytp>
and, FWIW, I think the case for not just adding WR to the RTM is quite thin
rohitksingh_work has quit [Ping timeout: 276 seconds]
<hartytp>
(well, assumign we can use WR at least, otherwise it's not really an option)
<sb0>
ok, so the plan is to put a better PLL than the 5324 on both AMC and RTM?
<hartytp>
short-term, what I'd really like to do is replace the Xtal with a DXCO, which has negligible additional cost/complexity
<hartytp>
compared with current solution
<sb0>
right now we can get 180ps pkpk of non-determinism with the two 5324 chained
<hartytp>
right, so WR should get that down to 0.1ps
<hartytp>
Weida's got most of it up and running
<hartytp>
my preference would be to not worry about full SC1 operation until Sayma v2.0 when we have the hardware to make it easier
<hartytp>
adding DCXO + Si5324 gives us the option of running the DCXO as an XO reference for the SI5324 with essentially no modifications to current code
<hartytp>
or, use the Si5324 as a buffer and add some WR gateware
<sb0>
so you'd put that new PLL right into the very next hardware batch?
<hartytp>
either way, there's minimal chance of breakage
<hartytp>
right
<sb0>
in that case I think it has to be done pretty quickly
<hartytp>
we're working on it
<sb0>
including thorough testing with ARTIQ DRTIO
<hartytp>
well, I'm not sure we have to do that before we add it to the design
<hartytp>
IMO, so long as it has been shown to work in a standalone KC705 configuration
<hartytp>
and so long as we keep the Si5324 so we have a fallback plan
<sb0>
who will test it? we definitely don't want another situation like sayma when a lot of things don't work and there is no clear plan of who is responsible to fix them and when
<hartytp>
I think it's okay
<hartytp>
well, as I said, the point is that with Si5324 can run from an XO
<hartytp>
so, worst case teh WR is a pile of crap, and we've just swapped the Xtal for an XO
<hartytp>
we've already tested that and shown that it works
<hartytp>
on Kasli (see the plots I posted on GitHub)
<hartytp>
so, we know that this won't break anything
<hartytp>
if we want to be really sure then we can add pads for both the Xtal and the DCXO and only populate the DCXO once it's been shown to work here
<hartytp>
sb0: re SC1
<hartytp>
great!
<hartytp>
I never measured the DAC to DAC skew directly
<hartytp>
just checked that it was constant over loads/power cycles
<GitHub-m-labs>
artiq/master 0e640a6 Sebastien Bourdeauducq: hmc7043: fix SYSREF to meet s/h at FPGA (#794)
<hartytp>
the fact that it worked on my board, but had 1/f_rtio non-determinism on other boards was why I suspected it was a S/H issue on the FPGA
<hartytp>
fwiw, I don't think you need to trim the phase of that
<hartytp>
I think a multi-reg is fine
<hartytp>
isn't it?
<hartytp>
doesn't JESD take care of the rest
<hartytp>
but, maybe I'm wrong about that, it's not my field at all
<hartytp>
anyway, either way, great if you've fixed it
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #794: @jbqubit Can you test again? With the latest code I am reliably getting ~30ps of absolute skew between the two DACs (at that level it can be the cables or the Red Pitaya). https://github.com/m-labs/artiq/issues/794#issuecomment-397989606
<sb0>
a single multireg shared between both JESD cores might work. but the current solution is cleaner.
<hartytp>
sure
<sb0>
though a bit more fragile, i.e. dependent on board layout etc.
<hartytp>
right, that was my thinking
<hartytp>
I tend to prefer to keep things asynchronous and add CDCs where possible
<hartytp>
rather than aligning clocks
<hartytp>
might be worth adding a comment somewhere that explains where the "magic" value for that phase comes from
<hartytp>
also, if you now switch f_DRTIO of f_DAC_CLK I wonder if that will break...
<hartytp>
marmelada: let me know how you get on looking at Sayma PI/crashes
<hartytp>
I'm happy to look as well, but I'm not sure there is much point us doing it at the same time (you're better placed to do a good job of PI measurements)
<sb0>
hartytp, will have to think about it again when the fpga dynamically adjusts sysref in drtio
<hartytp>
ack
<hartytp>
anyway, as always, many ways of skinning the cat. that's not how I would have done it, but if it works then it's pretty hard to complain ;)
<sb0>
actually with the siphaser technique, we can simply generate an internal sysref based on the value of the rtio counter, then phase-slip the MMCM that feeds the 5324 until the external sysref is aligned to it
<hartytp>
how fast do you think you can get that to work?
<hartytp>
2.4GHz?
<sb0>
or rather, phase-slip the 7043 sysref outputs, since messing with that MMCM will corrupt the DRTIO data
<sb0>
and we need a fully established DRTIO link to get RTIO counters synchronized
<sb0>
sure, why not? the sampling window of a FPGA flip-flop is small
<sb0>
and regarding skew variations, if this doesn't work, then nothing else will...
<hartytp>
well if that works out then it sounds as good as any other way
<hartytp>
not true, I think
<hartytp>
if we used the 7044 then the timing is easier because all the skews are handled inside the IC
<sb0>
well, with DRTIO you have the FPGA transceiver skew
<hartytp>
(it has the PLL + JESD204B bits inside a single IC, so there is less to worry about)
<bb-m-labs>
build #1656 of artiq-board is complete: Exception [exception conda_build_output] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/1656 blamelist: Robert J?rdens <rj@quartiq.de>, Sebastien Bourdeauducq <sb@m-labs.hk>
<bb-m-labs>
build #2460 of artiq is complete: Failure [failed] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2460 blamelist: Robert J?rdens <rj@quartiq.de>, Sebastien Bourdeauducq <sb@m-labs.hk>
<sb0>
but you can write them, refactor this code to use them, and send a PR
<kaolpr>
sb0, thanks for reference, ok, I'll do
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
hartytp_ has joined #m-labs
<hartytp_>
sb0: did you say that you're planning to phase shift the DAC clocks?
<sb0>
hartytp_, no
<hartytp_>
okay
<hartytp_>
remind me how you're planning to align the DAC clock with the rtio clock to give deterministic latency detween DAC updates and RTIO events
<hartytp_>
okay, I guess you don't have to (align the SYSREF that goes to the FPGA to the RTIO clock, and align the SYSREF that goes to the DAC with the DAC clock and then there is just a deterministic latency between FPGA and DAC)
<hartytp_>
anyway, was just going to point out that we want to avoid using analog phase shifters on the dac clocks if possible since they add noise and potentially phase drift
<GitHub144>
[smoltcp] whitequark commented on pull request #234 d05215f: Maybe `.into_iter()` so that we don't need to clone values? If the naive form doesn't pass borrow checker, use `swap`. https://github.com/m-labs/smoltcp/pull/234#discussion_r196079319
<GitHub194>
[smoltcp] dlrobertson commented on pull request #234 d05215f: Would it be more readable to have a static method that runs GC on a `BTreeMap` instead of `self`? That way we don't have the `match` with the `unreachable` statement. Just a thought. https://github.com/m-labs/smoltcp/pull/234#discussion_r196079722
<GitHub196>
[smoltcp] squidarth commented on issue #234: @whitequark @dlrobertson Updated. The problem with the static btree approach is that you can't assign `self.storage` inside the `match` block--I addressed this by using `swap`, but am not totally sure if this is more readable. Let me know what you think, and thanks again for the review https://github.com/m-labs/smoltcp/pull/234#issuecomment-398102107
<GitHub145>
[smoltcp] squidarth commented on issue #234: Ah, realized something with the test failure. This isn't going to work with the case where we are using `alloc` without `std`, since the static gc method depends on `std` (for importing the btreemap).... https://github.com/m-labs/smoltcp/pull/234#issuecomment-398114328
rohitksingh has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
<GitHub172>
[smoltcp] dlrobertson commented on pull request #234 3fbc626: 1 last nit: `use core::mem` so that this becomes `mem::replace`, then it becomes more clear that `core::mem::replace` is being used here. https://github.com/m-labs/smoltcp/pull/234#discussion_r196184017