<GitHub-m-labs>
artiq/release-4 76f63b2 Sebastien Bourdeauducq: ad9910: add precision about tune_io_update_delay/tune_sync_delay order
<sb0>
rjo: tune_sync_delay returns zero window, on all three cards (which otherwise work properly), additionally, initialization fails intermittently with "ValueError: no valid window/delay", and sometimes, the phase between two cards slips by 1ns after a power cycle (with no error reported)
<GitHub-m-labs>
artiq/master 84f7d00 Sebastien Bourdeauducq: ad9910: add precision about tune_io_update_delay/tune_sync_delay order
<sb0>
rjo: that's release-4 btw
hartytp has joined #m-labs
<hartytp>
rjo: I did consider that, but it seems unlikely
<hartytp>
we're feeding back after the output divider and I would usually assume there is just one output divider for all VCO bands (at least within the same VCO core)
<hartytp>
so, any phase shifts due to band selection should be taken out by the feedback
<hartytp>
another possibility is that there is some feed-forwards from the VCO band selection to the CP or PFD e.g. to keep the VCO gain constant across ranges
<hartytp>
the lack of docs or useful feedback from questions at the ADI forum makes it quite hard to divine what the truth is
<rjo>
sb0: post device_db, experiment, and describe the cabling.
<hartytp>
my best guess is that even with the frac registers set to zero there is still some frac-N circuitry in the feedback loop that needs to be correctly reset
<rjo>
hartytp: that's less plausible since they talk about manual vco calibration as a potential fix for some of the non determinism
<hartytp>
well, who knows
<hartytp>
anyway, doing more reading and testing today. will let you know how I get on
<rjo>
yes. good that that was finally tested before signing off on the design. it pays off.
<sb0>
rjo: I have ~30cm EEM cables + ~30cm MMCX cables between kasli and urukul
<rjo>
sb0: can't see anything wrong. maybe check the unittests. this has been working on kasli-1 reliably and about 6 other systems as well. maybe compare hardware.
<hartytp>
anyway, wanted your input on this PLL issue
<hartytp>
I've lost track of people's priorities and timeframes
<hartytp>
but, it seems to me that it's not going to be trivial to get really confident that the ADF will do the job
<rjo>
i don't know the relevant deadlines either.
<hartytp>
I'll try an active loop filter to eliminate band-dependent VCO leakage current. But, the temp co still scares me for this PLL and it generally seems less nice than the HMC830 in terms of analog spec
<hartytp>
well, the other option is to stick with the HMC830 and use the DAC as a phase detector to measure the phase offset between the DAC clock and SYSREF
<hartytp>
if the sysref is stable enough to sync a 2.4GHz DAC clock then it must also be stable enough to tell us the startup phase of an HMC830 (VCO freq is lower than ADF which makes it easier to manually reset)
<hartytp>
so, we can scan SYSREF and, if the edges are too far away, reset the PLL until it starts with the correct phase.
<hartytp>
I'm starting to think that ditching the ADF and demoing the HMC830 sync in a kernel might be the better use of time
<rjo>
yes. it would be good to test that as well.
<hartytp>
yes, I'll aim to do both, question is just priorities.
<hartytp>
sb0: can you give me a hand porting the JESD core reset/init to kernels?
<rjo>
also. remind me why the hmc7044 is worse than hmc830+fanout+cystom_sync?
<hartytp>
:)
<hartytp>
well, the fanout and custom sync stuff does seem to work for us (I've tested that part quite carefully). It's currently small analog effects in the PLL which seem to be the problem
<hartytp>
no reason I'm aware of to assume that wouldn't also be the case in the 7044
<rjo>
i remember the rfsync thing and maybe some vco details which made it preferrable over hmc830+hmc7043
<hartytp>
AFAICT the 7044 is designed to provide the master clock for a tree of HMC7043s and data converters
<rjo>
small analog effects in the hmc830?
<hartytp>
so it probably isn't too well characterised to give low drifts relative to the external reference
<hartytp>
one big reason I didn't like the 7044 is that afaict it's not possible to bypass the double PLL architecture
<rjo>
iirc the consensus was that the 7044 has a similar pll section than the hmc830 in quality and in design.
<hartytp>
so, one really has to use it with a low-bw lock to an external VCXO. But, those are really quite hard to make phase stable (WR is much easier since the low-bw loop is in analog)
<hartytp>
(s/analog/digital)
<hartytp>
the 7044 is nice in a lot of ways, but it crams a lot into a black box
<rjo>
iirc that was discussed and you can just use FIN.
<hartytp>
usual issue is features that one doesn't want but can't fully bypass, and problems with debugging since one can't probe test nodes
<hartytp>
I think one can't use the RFSYNC with FIN
<hartytp>
so one still has a nasty 2GHz sync issue to solve
<hartytp>
but, it's been a while since I thought about it so I might be misremembering
<rjo>
ime the black box risk/benefit ratio tends to be about as low as the custom-discrete risk/benefit ratio. there is no clear cut.
<hartytp>
"small analog effects in the hmc830?" it's still a multi-band VCO, so presumably there is still some band-dependent VCO leakage
<rjo>
yeah. then in any case the vco selection should be manual. but this is not the (only/biggest) problem with the adf*, right?
<rjo>
and about the tempco, you are worried about phase stability, not sync stability, right?
<hartytp>
i.e. don't think we've tested the phase stability of any PLL, so issues like this could show up on any of them
<rjo>
iirc we did discuss the 7044 way back. and the reason to go for 830+7043 was that you guys/maryland had more experinece with it and liked it more. i don't remember seeing or hearing anything that would indicate that the 7044 would not work with an extern vco if the internal turns out to be "not so good".
<hartytp>
yes, it's phase stability I'm worried about, not just sync
<hartytp>
rjo: no, I don't think that's the case
<hartytp>
I think the reason we didn't go for the 7044 was wanting to break the system down into smaller pieces that could be tested individuall (I'd never used either the 7043 or 830 before)
<rjo>
in any case i don't need to lobby for plls. pll selection is not our task.
<hartytp>
anyway, while historically interesting, I'm not so fussed in disecting old decisions. Mistakes were made, plenty by me
<hartytp>
ack. SB seemed to have some strong opinons. If your current view is "don't care" then I'll make a call on it
<rjo>
nono. there were strong statements about the hmc830 being tried and tested almost perfect pll...
<hartytp>
ack. I may have said that as a younger and more naive person (not that I'd tested it, but rather that it's widely used and tested by others)
<hartytp>
anyway, as I said, that's all history and I'm not sure it helps us move forward. I'd be fine using the 7044 if it was tested and demonstrated to work both as a PLL (phase stability and noise) and for sync
<rjo>
i am happy to give advice if there is the need for it.
<hartytp>
"but this is not the (only/biggest) problem with the adf*, right?"
<hartytp>
I'm not aware of any other problems with this PLL
<hartytp>
what are you referring to?
<rjo>
sure. i am not trying to give you the i-told-you-so. i am trying to understand the situation and options now.
<hartytp>
the situation is that almost any of the options we've discussed probably can be made to work (assuming there isn't a killer bug in the DAC we haven't hit now).
<rjo>
there is the analog (tempco) and the digital (vco cal/band). those are different.
<hartytp>
the more time I spend on this, the more I like using simple discrete components because of the ease of debugging. But if we can find a black box that works easily then that would be better.
<hartytp>
rjo: different but may be related
<rjo>
and there is the (digital) divider issue in the hmc830.
<rjo>
the hmc830 may also have the vco cal/band thing.
<hartytp>
in the sense of I can well imagine the leakge having a strong temp co and dominating the overall PLL temp co
<rjo>
ok. i thought there was data on the tempco of the 830.
<hartytp>
yes, the HMC830 may well have the same issue we just didn't see it yet. or maybe the leakage is lower so it's a much smaller issue. I can test that
<hartytp>
rjo: not that I'm aware of. Do you mean data we took or external data?
<rjo>
iirc external.
<hartytp>
I have an eval board so I can take that data, but it will take me a day to set it up
<hartytp>
okay, that would be ace. Do you have a ref
<rjo>
but that was just in the back of my mind. may wall be wrong.
<rjo>
*well
<hartytp>
ack. I'll have a google and see if I can find something. Otherwise, I can take the data.
<hartytp>
the other thing I don't like about the ADF PLLs is that the phase noise starts off a bit worse than the HMC830. To take advantage of the output divider feedback we have to run at a lower PFD freq
<rjo>
can't find it now. i'll let you know if i do.
<hartytp>
that degrades the noise further
<hartytp>
we can live with that, but it's an issue. If using the DAC as a phase detector works and gives better phase noise then it may be a better long-term approach.
<rjo>
where is the dac compared to the adf worst case?
<hartytp>
yes, we could add extra hardware to do that
<hartytp>
using the DAC is a cheap way of doing it without any extra kit
<hartytp>
or, maybe we mean the same thing. I mean use the custom sync thing to sweep the SYSREF phase at the DAC. use the DAC to tell us where the DAC clock edges are
<hartytp>
if the sync stuff isn't stable enough to tell us where the edges of a 2GHz DAC clock are then it's not stable enoug to do its job.
<hartytp>
(my testing suggests that it will under realistic assumptions about temperature stability)
<hartytp>
the other big elephant in the room is that we haven't measured DAC phase/temp cos yet. If that sucks then the whole thing is a waste of time anyway
<rjo>
yes. that as well.
<hartytp>
anyway. back track. one thing at a time
<rjo>
so you want to decide on pll now. my impression is that there are similar numbers of pitfalls and problems with either the adf and the hmc830.
marmelada has joined #m-labs
<hartytp>
rjo: yes
<hartytp>
830 does have less noise
<hartytp>
and is a bit simpler, which appeals
<hartytp>
the digital side is flaky, but adding a power-cycler should fix that
<rjo>
then i'd keep the 830.
<hartytp>
it doesn't have the output divider, but we can probably work around that easily. and, in any case, if we can get DAC interpolation working then it's a non-issue
<rjo>
btw. i'd not do the power cycler but just do a single hardware sequencing of the spi lines on power-up. and afterwards hand over to the fpga.
<hartytp>
rjo: it's quite easy to brick the SPI machine. e.g. aborted SPI writes seem to put it into a non-recoverable state
<hartytp>
so, having a way of cycling it from software seems valuable
<sb0>
hartytp: i'm not fully up-to-date on the various hmc830 bugs. how exactly is the power cycler supposed to be operated? power cycle it until intialization and lock succeed? or is it more subtle?
<hartytp>
sb0: no, power cycle it if it stops responding to identity queries
<hartytp>
afacit if all registers are written to on each update and if it responds to identity queries then it will always lock
<sb0>
on the boards here sometimes it identifies but fails to lock, but maybe i'm missing some hardware patch...
<hartytp>
interesting
<hartytp>
I wasn't aware of that
<hartytp>
I thought your board now works reliably
<sb0>
I have two boards with 3.3V failures after some minutes/hours, and one where all voltages except 0.9V are dead, and I saw several unexplained hmc830 lock failures when using them recently
<sb0>
that's not what i'd call reliable...
<sb0>
plus the new JTAG SCANSTA bug when it's in uTCA
<sb0>
on the board with the power failure, that happened after I cycled it many times using IPMI commands to work around the 3.3V bug
<sb0>
via NATview
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<sb0>
wasn't there some hardware rework to fix certain hmc830 intermittent lock problems? maybe i'm missing it or it broke...
<hartytp>
sb0: not that I'm aware of
<hartytp>
IIRC it was only the SPI init, but if that's wrong the PLL doesn't respond to identify queries.
<hartytp>
sb0: ok. Well, if you've got power glitches going on, it's hard to know if the PLL is the issue or if it's something else. We need to triage this a little to be able to make an informed decision
<hartytp>
but, if there really are still more issues with the HMC830 than I'm aware of, then I'm okay to go for the adf. I don't have a strong preference one way or the other. (on the plus side, my coredevice driver for the adf PLL has locked every time I've used it...)
<adamgreig>
whitequark: for tiny things in nmigen would you rather issues/PRs/just telling you on irc? e.g. asyncfifo docstring says to use ClockDomainsRenamer but it's just DomainRenamer in nmigen
cedric has quit [Ping timeout: 246 seconds]
<adamgreig>
(also, DomainRenamer seems to require a Fragment rather than a Module?)
cedric has joined #m-labs
cedric has quit [Changing host]
cedric has joined #m-labs
bluebugs has quit [Ping timeout: 245 seconds]
zng has quit [Quit: ZNC 1.8.x-nightly-20181211-72c5f57b - https://znc.in]