<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1166: The problem is **not** present with the DRTIO satellite target (@hartytp please confirm). So this looks like a clocking gateware/firmware bug, or more HMC7043 shenanigans (with DRTIO satellite, the JESD transceivers are clocked by the Si5324 and not the HMC).... https://github.com/m-labs/artiq/issues/1166#issuecomment-450898678
rohitksingh has quit [Remote host closed the connection]
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1166: The problem is **not** present with the DRTIO satellite target (@hartytp please confirm). So this looks like a clocking gateware/firmware bug, or more HMC7043 shenanigans (with DRTIO satellite, the JESD transceivers are clocked by the Si5324 and not the HMC).... https://github.com/m-labs/artiq/issues/1166#issuecomment-450898678
rohitksingh has joined #m-labs
<GitHub-m-labs>
[artiq] jordens commented on issue #1166: Ha. The glitches are every 40 ns. That's an even 6 coarse RTIO periods and 5 periods of 125 MHz. That's why they look random on the ram and periodic on the sine. There isn't that much (anything?) driven at 125 MHz in DRTIO satellites, but quite a bit in master bitstreams. This could be some fabric or external crosstalk due to the beat and thus PI/SI issues. Or a gatewar
<GitHub-m-labs>
[artiq] jordens commented on issue #1166: Ha. The glitches are every 40 ns. That's an even 6 coarse RTIO periods and 5 periods of 125 MHz. That's why they look random on the ramp and periodic on the sine. There isn't that much (anything?) driven at 125 MHz in DRTIO satellites, but quite a bit in master bitstreams. This could be some fabric or external crosstalk due to the beat and thus PI/SI issues. Or a gatewa
<GitHub-m-labs>
[artiq] jordens commented on issue #1166: Ha. The glitches are every 40 ns. That's an even 6 coarse RTIO periods and 5 periods of 125 MHz. That's why they look random on the 600/4/16 MHz ramp and periodic on the 600/4/3 MHz sine. There isn't that much (anything?) driven at 125 MHz in DRTIO satellites, but quite a bit in master bitstreams. This could be some fabric or external crosstalk due to the beat and thus
<GitHub-m-labs>
[artiq] jordens commented on issue #1166: Ack. The difference could still be due to the reduced amount of 125 MHz logic (kernel cpu and associated logic). But this is definitely at the beat. If this is PI, one might naively expect a significant "intermodulation" product on the power supplies at 25 MHz. If it is SI, then we should look at how the 125 MHz clock is getting into the 150 MHz/JESD domain. Could also
lkcl has quit [Read error: Connection reset by peer]
lkcl has joined #m-labs
cjbe has joined #m-labs
kristianpaul has quit [Quit: leaving]
kristianpaul has joined #m-labs
hartytp has joined #m-labs
<hartytp>
rjo: do you understand the ADF[45]356 init sequence?
<hartytp>
maybe I'm not reading it correctly, but the data sheet doesn't seem clear to me
<hartytp>
afaict the VCO calibration doesn't work with PFD frequencies > 75MHz (which is the regime we'd normally want to operate since higher PFD freq gives bette noise performance)
<hartytp>
hence the requirement to first lock at half pfd frequency
<hartytp>
but I don't really get what the ADC is doing, or how the temperature compensation works.
<hartytp>
the init sequence specifies a time between writing to register 10 (the ADC configuration) and writing to register 0. however. that seems odd since the ADC clock is a divided version of the PFD clock, and the PFD clock is configured by register 4, which is the next one written to
<hartytp>
moreover, there is no specification of the default values for most registers
<hartytp>
anyway, maybe I'm missing something silly but I know you've thought about this PLL IC so I thought I'd ask
<hartytp>
NB there seem to be a few issues with using these PLLs with differential inputs.
<cjbe>
sb0: I measured the DRTIO timing stability by looking at the master and slave Kasli clock outputs on a good scope and taking statistics.
<cjbe>
I also looked at the RTIO outputs via a DIO board, but the output jitter of the DIO boards is quite bad (~300ps IIRC), so it is harder to get good statistics like this.
<cjbe>
sb0 / whitequark: any suggestions on how to preallocate / store a DMA sequence handle?
<hartytp>
also, it's not clear to me whether the CE pin reliably resets registers to power on defaults. if not, does this change the requirements for the init sequence?
<cjbe>
I have a class that generates and records a DMA sequence, and I want it to have a play method that is fast (hence does not call get_handle() on the critical path). Here is what I currently have: https://hastebin.com/ogusovayuh.rb
<hartytp>
it's also not clear to me why calibrating the VCO at temperatures away from 25C results in worse phase noise, despite the fact that the device includes a temperature sensor as part of the calibration setup (I think this is what the ADC is for)...
<cjbe>
hartytp: I would not expect the CE to touch the shift register state at all - I think this just intended to shut off the power-hungry parts of the chip (cf the software shutdown).
<cjbe>
The datasheet seems fairly explicit that the correct way to initialise it is to write a known value to every register.
<hartytp>
cjbe: yes.
<hartytp>
it's the timing constraints I don't get
<hartytp>
"Ensure that >16 ADC_CLK cycles have elapsed between the write of Register 10 and Register 0."
<hartytp>
ADC_CLK cycle time depends on register 4
<hartytp>
also, what triggers the ADC sampling? Is this just a one-off temperature measurement that only occurs when register 10 is written to?
<hartytp>
" The ADC uses a clock that is equal to the output of the R counter (or the PFD frequency) divided by ADC_CLK_DIV." also not really true, as it's ADC_CLK_DIV*4+2. Basically, I read it as the thermometer ADC needing a 100kHz clock,
<hartytp>
which the max clock divider being 255
<hartytp>
so one needs to set an appropriate PFD frequency before the conversation takes place which, AFAICT, is immediately after writing to get 10
mumptai has quit [Quit: Verlassend]
<cjbe>
hartytp: yeah - that is ugly! At least you have an eval board to look at the timings AD used...
<hartytp>
undocumented diagnostic modes does seem to be a favourite with PLL ICs
<cjbe>
documentation is hard...
<hartytp>
yes
<hartytp>
+ expensive and boring
<hartytp>
the concern would be that it will most likely lock with the init sequence incorrect, but may give bad phase noise/loose lock from time to time due to incorrect VCO calibration
<hartytp>
or, we'll find that it works fine the first time when configured from power on default values, but if it's reconfigured without a power cycle then will behave oddly.
<cjbe>
surely at the worst case you can just run the init sequence twice? For the first one the ADC clock might be off, but for the second you know it is correct
<hartytp>
yes, or just program reg 4 first
<hartytp>
well, I think
<hartytp>
I'd feel more confident saying that if I actually understood what's going on. As I said, it's not clear to me how the init sequence works.
<hartytp>
if f_ref > 75MHz then when reg 10 is written to, which seems to be the temperature conversion trigger, the R divider is 1
<hartytp>
(assuming the power on default state)
<hartytp>
so the ADC clock wouldn't be correct
<hartytp>
anyway, I guess the sequence in the data sheet must work so if we stick to that it should be fine, I just like to understand what I'm doing