Phaser PLL not deterministic?

FabianS

Hi everyone,
I am still trying to get the Phaser up and running and I stumbled across the next problem where some insight might be helpful.
Simple question first: Is the Phaser with upconverter supposed to be deterministic?
For me this is currently not the case. First of all I don't think this can work when using the internal 125 MHz reference from the Kasli. The maximum phase detector frequency of the TRF is below that, so I have to use an R-divider, which introduces a random phase offset. Any objections?
So, I guess I have to use an external reference with lower frequency, which I feed into the Kasli and the Phaser. As the 125 MHz have to be an integer multiple of that reference, I cannot use a common 10 MHz, right?
And is it also correct, that I have to modify the source code to tell Kasli/Phaser which external frequency is applied? I could not find any configuration value for that.

Thanks a lot
Fabian

rjo

The R divider introduces a non-deterministic phase if used. Use external LO (a) to slave one channel to the other to get deterministic phase between two channels or even (b) to feed both from the same external LO (via MMCX). I don't think that has been tested.
The external reference frequency input must be 125 MHz and it must be phase locked to the Kasli reference.

rjo

I suspect that you can actually measure the phase of the R counter (MUX out RDIV) w.r.t. the RTIO clock using the FPGA without any gateware changes and achieve deterministic phase. Not explored though.
And I think in principle it would be possible to change the clocking to use 62.5 MHz external ref, RDIV=1. But that would need some changes to the FPGA gateware.

FabianS

Thanks for the explanation of the different options.
I think feeding the LO from one channel to the other is not a viable solution, as it only provides deterministic behavior between the two channels, but not to the rest of the system.
Feeding both from an external source would be a possible solution, but the clock of the Kasli would have to be derived from that as well. Is the Kasli's CLK IN more flexible? Can I supply 25 or 62.5 MHz to it to get a deterministic x5/x2 multiplication for the 125 MHz clock?
Can you point me in the right direction on how to measure the R counter phase w.r.t. the RTIO clock?

rjo

FabianS
The scope of phase determinism required is very much application dependent.
The Kasli CLK IN can take a range of different frequencies, a few are predefined (125 MHz with PLL bypass, 100 MHz, 10 MHz etc). For others you'll have to determine custom Si5324 settings and use those in the firmware.
To measure the RDIV phase, get its output to TRF_LD and sample it with get_sta(). Since there are only two possible phase values, and assuming the sampling is valid (if not try a majority vote), you have your phase (at some arbitrary but fixed reference plane).

pathfinder49

Hi Fabian, what do you mean by random phase offse? The phase of the upconverter is stable with respect to the refrence clock (measurements here). As I understand PLLs, the phase of the TRF VCO will be deterministic with respect to the reference frequency (provided you are using an integer multiple of the reference frequency). As rjo said, if you need to know this phase, you should be able to measure it.

FabianS

pathfinder49 Well, you are of course right. If I choose an integer multiple of the 125 MHz the phase should always be deterministic, even if an R divider is used. However, choosing a lower base-frequency than 125 MHz would be nice, but obviously not possible.
rjo Thanks for the input. I will have a look at this and see if it helps me.
Thanks a lot both of you 🙂

FabianS

@pathfinder49 After a bit of testing and thinking, I realized that a multiple of 125 MHz is not enough. The output frequency also has to be between 2.4 and 4.8 GHz, which is the range of the integrated VCOs. If any smaller frequency is required, the PLL will have to use additional frequency dividers. Sadly there are three independent dividers for the PLL, for the FR signal and for the LO output, which are not locked to each other. This causes phase ambiguities.
I will now have a look at the get_sta() function, but currently I don't think it will be possible to use this feature for compensating/detecting the phase ambiguities as I would have to supply the RF signal to the TRF_LD an measure it's phase/value.
Please feel free to correct me, because otherwise I don't see that it is possible to use the Phaser for gate manipulation, as it is not deterministic.

rjo

@FabianS Note that in practice, this kind of non-determinism is calibrated out within seconds. Always question claims about what's required. Physicists are rarely diligent with their specifications.

FabianS

@rjo I had a discussion with a few of them and the conclusion was that detecting such a phase ambiguity for every experiment is basically not acceptable. The calibration would be quite complex and would require thousands of measurements followed by a statistical analysis of the results - so they told me.
My current workaround would probably be to develop an additional circuit that would replace the PLL of the TRF completely and feed that signal into the VCO input of the TRF, which is capable of accepting frequencies below 2.4 GHz. This way I can set all dividers to 1 and have a deterministic behavior. But I would prefer a software solution to make the RF signal unambiguous.

rjo

But it doesn't change every experiment. It's fixed as long as you don't unlock the PLL. And even if you do it's differentially fixed if you slave the second channel to the first.
And the "thousands of experiment" is nonsense. To extract one bit of information (the phase ambiguity if you have a divide-by-two) with a single qubit, you only need a dozen shots, i.e. milliseconds.
You might be fixing an issue that does not even exist.

FabianS

You may be right, I can't tell, so I would like to do what I am told to do 😉
Nevertheless, using the same LO for both will make both outputs fixed to each other, but not to other modules in the system, like the Urukul used for signal generation of the paul trap, which also needs to be synchronized.

rjo

Synchronizing the micromotion sounds a bit esoteric to me.
Again, w.r.t. everything else including Urukul, the Phaser phase will still always be synchronized and it will be deterministic as long as you don't unlock the PLLs.
But this is not the place to explain or derive the requirements.

FabianS

Is it correct, that the initialization of the phaser will reset the TRF? So, at least with the current software, I cannot start multiple experiments with deterministic behaviour?

rjo

You only have to initialize Phaser once.