Sayma new PLL IC

[hartytp]

Now that LTC/ADI/HMC are a single mega RF entity I'm limiting my initial search to them.

Crude filtering of candidate ICs: https://www.analog.com/en/parametricsearch/11322#/p4466=1|400000000&p4467=3000000000|32000000000&p4781=|PLL%20with%20Integrated%20VCO|PLO&d=sel|4240|4467|4466|5129|5130|5149|4781|4862|s8|s7|s2|s5|2835|2836|4730&ps7=|Not%20Recommended%20for%20New%20Designs|Production|Recommended%20for%20New%20Designs

It looks like we need to filter for PLLs with names which don't begin "HMC". Firstly because I can't deal with more of SB's complaining about "HMC trash". More seriously because none of them seem to have synchronised output dividers (this is based on looking at the block diagrams for HMC835, HMC834, HMC829, HMC830, HMC833, ...)

The LTC offerings I've seen also do not have synchronised output dividers.

So, we have two options: use the FPGA to synchronise the PLL output dividers (low risk, but a but annoying to do and requires a small amount of gw/fw development) or use a PLL from the ADF series.

The new ADF PLLs look lovely but they're not generally ready yet and their specifications are subject to change. So, for now I've ruled them out by filtering for products that are actually available to purchase.

So, our choices are: (a) try to get engineering samples of the new ADF PLLs and live with any bugs/future changes to specifications, or (b) go for one of the existing PLLs (we can easily upgrade to the newer, lower noise models in a future hardware revision once they are in general release and have been tested with Mirny).

Assuming we're happy with (b) that leaves us with the ADF4356 or a related part as our only real choice.

I've read through the data sheet for that IC and haven't seen any obvious issues with it. @gkasprow @sbourdeauducq @jordens any thoughts?

Comments about other chips in the same family that I chose not to use:

• ADF5356 - basically same specs. Only difference AFAICT is the output doubler (which we don't need), and increased cost.
• ADF4351, ADF4350 - PFD max is only 32MHz which is annoying and can lead to worse phase stability. They are a bit cheaper, but not by an amount that's significant compared with the overall cost of Sayma.
• ADF4355-2, ADF4355-3, ADF4355 - similar part, similar cost, slightly worse phase noise. Pin-compatible but older model of the same PLL
• ADF5355 - same as 4355 but with doubler that we don't need

[hartytp]

Phase noise comparison between the HMC830 and ADF4356:

Open loop VCO noise scaled to 100MHz:

offset freq	HMC830 (-dBc/Hz)	ADF4356 (-dBc/Hz)	AD9154 (-dBc/Hz read from graph)
100kHz	142	146	145
1MHz	167	168	158
10MHz	188	186	160
100MHz	191	-	-

[hartytp]

• White phase noise floor calculated by: Pn = FOM + 10*log10(f_pfd) + 20*log10(N) where N is the PLL multiplication factor
  • ADF4356 FOM: -227dBc/Hz
  • HMC830 FOM: -230dBc/Hz
• Flicker phase noise floor calculated by Pn(f_offset) = FOM_1_f - 10*log10(f_offset) + 20*log10(f_rf)
  • HMC830 flicker FOM: -268dBc/Hz
  • ADF4356 flicker FOM: -261dBc/Hz

So, the ADF4356 is a bit worse than the HMC830, but likely not in a way we care about.

100MHz carrier, 10Hz offset:

• ADF4356 flicker: -111dBc/Hz
• AD9154: roughly -107dBc/Hz (read from plot)
• HMC830: -117dBc/Hz

The newer ADF PLLs like ADF437x nominally have the same flicker noise as the HMC830 (to within 1dB), but we can't buy them yet :(

[hartytp]

General comments:

• [ ] Let's route mux out to the RTM FPGA
• [ ] Let's route a pin from the RTM FPGA to a red LED on the FP for a PLL locked indicator
• @gkasprow are you worried about noise coupling from the FPGA to the PLL (as you were with Stabilizer's ADCs)? Should we have isolation buffers between the FPGA and PLL?
• [ ] Connect the output buffer enable to the FPGA with suitable resistor to ensure that the buffers start up muted
• [ ] I'll do a proper noise simulation before we go to production and tune the loop filter. For now, let's use the one from the eval board

[hartytp]

@gkasprow just follow the reference design (data sheet fig 43) which is teh same as the eval board.

• [ ] This PLL has two outputs so we can drive each DAC from an output
• [ ] please use a 500R + 100nF capacitor resistor to pick off a bit of RF from each output and send that to a UFL for debugging (we can DNP this later)

[hartytp]

Okay, I'm happy with that as a design (modulo loop filter optimization). Let me know when you've got it on the schematic and I'll do a design review.

[marmeladapk]

@hartytp in #601 ADF4351 is mentioned as a backup option. Is this issue outdated and we should close it or should we add it to Sayma v2.0 milestone and change #601?

[hartytp]

@marmeladapk good catch! The ADF4351 was an early suggestion before I'd had a careful look into PLL options. As I mention in the post at the top of this issue, it's essentially an older version of the ADF4356 with poorer performance (lower PFD frequency).

The ADF4356 should be used in Sayma v2.0 and https://github.com/sinara-hw/sinara/issues/601 should be updated (that plan pre-dates me doing proper research into PLLs for v2.0)

[hartytp]

FWIW the ADF[45]356 PLLs have a three wire serial port with no MISO, so there is no register read back at all (i.e. worse than the HMC830). Moreover, they have no software reset at all. The init sequence seems a bit fussy as well. I also don't see anywhere on the data sheet where power-on register values are specified.

Given all that, it will be interesting to see how well we are able to configure the PLL starting from an unknown state.

[hartytp]

NB also: from the data sheet, for references below 250MHz, it's best to use a single-ended reference. This applies to Mirny too.

[sbourdeauducq]

Yes, it seems to be as low-level as it can get - it's just a shift register and a few latches, and internal functioning of the analog part is exposed e.g. through the register write order specifications. Hopefully that also means that there is no internal state other than the exposed one, and that is the reason for the absence of a reset pin. Note that the initialization sequence specifies writing all registers.

The MUXOUT output can be driven hard-1 or hard-0 by changing the registers. I propose toggling it a few times and reading it back in the FPGA to test the communication with the ADF chip (as part of the firmware BIST).

[gkasprow]

OK, so I need to connect the MUXOUT to FPGA as well. For the moment it is driving LED.

[sbourdeauducq]

In general, please try not to connect LEDs to anything other than the FPGA (unless there are I/O voltage issues or a lack of I/O pins, we can always route LED signals through the FPGA if needed). The FPGA also needs to see MUXOUT to check PLL lock status.

[gkasprow]

OK, good idea.

[gkasprow]

done