Solving determinism problem after each PLL lock

[FabianSchwartau]

Hi everyone, @jordens said you are about to do a new release for the Phaser and asked if I have anything else to add. Yes, indeed, but I am not completely finished with the investigation. The core problem, that has been discussed on the m-labs forum (https://forum.m-labs.hk/d/173-phaser-pll-not-deterministic) is that the Phaser is not deterministic when re-locking the PLL for frequencies below 2.4 GHz. The core problem is, that the PLL (inside the TRF372017) is using different dividers for the PLL, the LO output and the RF signal for the mixer. The VCO can only operate between 2.4 and 4.8 GHz, and requires dividers for lower frequencies. As multiple dividers are used for the three different paths and they are not locked to each other, each of them can lock differently, resulting in a phase ambiguity during each lock process. TI also confirmed this problem and there seems to be no (software) workaround. I had a talk with even more physicists yesterday and we found a solution to work around this problem for our setup, but it involves using an additional Urukul, which I would like to avoid. I have two possible solutions in mind, which would solve the problem and would require a modification of the Phaser:

• Use an (additional) external VCO with an additional external divider and feed that signal into the EXT_VCO of the TRF. If cleverly designed it would be possible to switch between the internal and external VCO. All internal dividers are then set to 1 and no phase ambiguity is occuring, as the PLL and the mixer are using the same signal. This would have the additional benefit of a better VCO with lower phase noise. The downside of this approach: It seems like the TRF is not specified for such low frequencies at the EXT_VCO input. Nevertheless, it is working, I tested it with a frequency generator. However, the performance of the mixer seems to suffer (sideband suppression) when using the internal divider of 1 at lower frequencies. This is probably cause by the polyphase filter which is used to generate the 90° phase shifted signal, which is not trivial to implement with a high bandwidth and no division. As the TRF itself is not designed for that, I guess the 90° are a bit off at lower frequencies, which causes the worse sideband suppression (I measured as worse as 28 dB, compared to usually 40 dB, but my tests are not finished yet). Theoretically one may compensate for this in software by correctly manipulating (and overlapping) the I and Q singals. Nevertheless, if the VCO is additionally added, one can also continue to use the internal VCO with the same functionality as right now, so it would still be downwards compatible. I am planing to look deeper into this and find potential parts on Tuesday.
• The second solution would be to replace the TRF completely with a different part, which does not have this issue. I have not looked into this, yet, but I will also do that in the next week.

[gkasprow]

I'm planning a new release so can add an extra VCO chip + dividers. In case of alternatives, they yousually come with new bugs :) So once you find a workaround, implement it. What are the requirements for such VCO?

[FabianSchwartau]

Well, I have options for workarounds of this problem, but they all involve some serious external hardware and software extension, so I would prefer one of the two solutions I suggested. There are a few things which cause a bit of work to implement the VCO solution (not too much in total):

• You probably need a boost converter, as the control voltage of such VCOs often reaches ~24 V
• You will then need an active loop filter to up-convert the charge-pump output
• The active loop filter might allow to just hook it in parallel to the existing loop filter of the TRF, which in turn allows to have two loop filters connected to the charge-pump output and switch between the external and internal VCO only using software
• These VCOs are usually fairly large (maybe 12x12mm or even larger), so you need some additional space on the board
• We have to decide if we want one VCO for each TRF chip (I would prefer that) or just one for both TRF
• The RF divider(s) need to be hooked up to the FPGA, they usually have a parallel or SPI/I2C interface

If you like, I can create a schematic for you, but this will take me a few days (and I work only two days per week on this) and I don't have access to a (recent) Altium version. Depending on how much time we have before the planned release, I could also implement the circuit on an extension board and test it before we put it on the phaser, but this will take even more time. As I said, I maybe able to create a rough schematic (or at least know the parts) on Tuesday evening. Is replacing the TRF also an option? Or do you want to keep everything compatible?

[hartytp]

Hi @Jacky2k

The downside of this approach: It seems like the TRF is not specified for such low frequencies at the EXT_VCO input. Nevertheless, it is working, I tested it with a frequency generator. However, the performance of the mixer seems to suffer (sideband suppression) when using the internal divider of 1 at lower frequencies. This is probably cause by the polyphase filter which is used to generate the 90° phase shifted signal, which is not trivial to implement with a high bandwidth and no division.

Let me check I understand...we exposed a LO input for this kind of situation (as well as getting lower phase noise etc).

Is your statement here effectively that the polyphase filter is interconnected with the PLL divider, meaning that the performance becomes really poor using a lower frequency LO and no divider (as opposed to a high frequency LO with divider).

As the TRF itself is not designed for that, I guess the 90° are a bit off at lower frequencies, which causes the worse sideband suppression (I measured as worse as 28 dB, compared to usually 40 dB, but my tests are not finished yet). Theoretically one may compensate for this in software by correctly manipulating (and overlapping) the I and Q singals.

What is your specification for sideband suppression? 28dB is still pretty good. Do you actually need better than this (many applications do not)? As you say, if you do need better than this, what's the issue with doing a simple software calibration?

Nevertheless, if the VCO is additionally added, one can also continue to use the internal VCO with the same functionality as right now, so it would still be downwards compatible. I am planning to look deeper into this and find potential parts on Tuesday.

I do not understand this statement.

---

Taking a step back (as @jordens points out on the forum thread you linked to) this is very much expected behaviour for this kind of system (admittedly not documented). e.g. the same thing happens with Mirny (with a few subtleties). There are generally not easy "one size fits all solutions".

The second solution would be to replace the TRF completely with a different part, which does not have this issue. I have not looked into this, yet, but I will also do that in the next week.

It's always worth looking for alternative options but, if I've understood your post correctly, I don't think you'll find one. AFAICT you're after a chip that allows you to cover a huge frequency range with no dividers (which is fine for a specific application, but not for a board designed to cover a large range of uses) or wraps all dividers inside a feedback loop (which is generally "non-trivial" at best).

[hartytp]

There are a few things which cause a bit of work to implement the VCO solution (not too much in total):

Why put the external VCO on Phaser rather than using the MMCX that already exists here? AFAICT there are such a wide range of potential use cases that we'd struggle to add a VCO in a way that's broadly useful (rather than just scratching your itches).

What's wrong with e.g. using a Mirny + clocker to generate your LO?

[hartytp]

If you like, I can create a schematic for you, but this will take me a few days (and I work only two days per week on this) and I don't have access to a (recent) Altium version. Depending on how much time we have before the planned release, I could also implement the circuit on an extension board and test it before we put it on the phaser, but this will take even more time. As I said, I maybe able to create a rough schematic (or at least know the parts) on Tuesday evening. Is replacing the TRF also an option? Or do you want to keep everything compatible?

My two cents worth here are that this feels like a lot of complexity / a deep rabbit hole.

Let's pause for a second and ask weather we can do this with just using an external card to generate the LO. If we agree that will work, we'd need a strong argument as to why we should add extra circuitry to phaser to integrate this. What's the range of use cases you have considered? How does this impact them? What's the complexity trade off and is it really worth it to get a more integrated solution (IMHO one of the strengths of Sinara is that its modularity allows it to serve a wide range of use cases)?

[hartytp]

Is replacing the TRF also an option? Or do you want to keep everything compatible?

Everything is an option with a good enough motivation. But there are a few things missing here. e.g. what's your specification? Does the current design meet it (e.g. what suppression do you need)? Do chips even exist that can do what you want without determinism? If so, what are their trade offs (e.g. do we get stuck with a narrower frequency range)? Is the improvement worth the additional prototyping effort?

So far, from what I can gather you just need to use an external LO source and maybe use the TRF registers to tweak the SSB suppression.

[hartytp]

Well, I have options for workarounds of this problem, but they all involve some serious external hardware and software extension

What does serious external hardware mean? Do you mean a an external PLL IC? What does serious software extension mean? Do you mean exposing the TRF registers to tweak the SSB suppression?

[FabianSchwartau]

Wow, that's a lot of questions. So let's go :)

Is your statement here effectively that the polyphase filter is interconnected with the PLL divider, meaning that the performance becomes really poor using a lower frequency LO and no divider (as opposed to a high frequency LO with divider).

Yes. Normally the polyphase filter is only used for frequencies between 2.4 and 4.8 GHz, but now we would use it also for lower frequencies.

What is your specification for sideband suppression? 28dB is still pretty good. Do you actually need better than this (many applications do not)? As you say, if you do need better than this, what's the issue with doing a simple software calibration?

I have no specification, it is just something I noticed, which is a downside. So you gain determinism by worse sidelobe suppression.

Nevertheless, if the VCO is additionally added, one can also continue to use the internal VCO with the same functionality as right now, so it would still be downwards compatible. I am planning to look deeper into this and find potential parts on Tuesday.

I do not understand this statement.

The external VCO can be added without interfering with the current circuit. If you don't need it, you can just ignore it and the software will be 100% compatible between both hardware versions.

Taking a step back (as @jordens points out on the forum thread you linked to) this is very much expected behaviour for this kind of system (admittedly not documented). e.g. the same thing happens with Mirny (with a few subtleties). There are generally not easy "one size fits all solutions".

Sure, but I am trying to add a feature without impacting anything else (except the cost). I have to admit that I did not had the fact in mind, that the EXT_VCO input MMCX connector will be lost if we add a VCO. I would suggest to add it as a population option, also remove the cost "problem".

It's always worth looking for alternative options but, if I've understood your post correctly, I don't think you'll find one. AFAICT you're after a chip that allows you to cover a huge frequency range with no dividers (which is fine for a specific application, but not for a board designed to cover a large range of uses) or wraps all dividers inside a feedback loop (which is generally "non-trivial" at best).

The solution can use dividers, and will. Finding a VCO with more than one octave of tuning range is pretty much impossible, so there has to be a divider. But it has to be within the PLL loop and the signal used for the mixer cannot have any additional dividers. And as I said, I haven't come around to come up with a selection of component, maybe it is not possible to do what I want.

What's wrong with e.g. using a Mirny + clocker to generate your LO?

I don't know, probably nothing. Whats wrong with adding an additional feature to the Phaser that will be no harm to those not needing it?

Let's pause for a second and ask weather we can do this with just using an external card to generate the LO. If we agree that will work, we'd need a strong argument as to why we should add extra circuitry to phaser to integrate this. What's the range of use cases you have considered? How does this impact them? What's the complexity trade off and is it really worth it to get a more integrated solution (IMHO one of the strengths of Sinara is that its modularity allows it to serve a wide range of use cases)?

Well, I considered my usecase at least ;) It impacts them as I don't need extra external circuits to solve this problem. I don't know how complex the circuit will be, as I said, I am still working on it. And after all, this is just a suggestion. If the majority of the people involved here say they don't want/like it, I will have to accept it and work my way around it, which might be much harder than to modify the Phaser (which is what I might do anyway).

Everything is an option with a good enough motivation. But there are a few things missing here. e.g. what's your specification? Does the current design meet it (e.g. what suppression do you need)? Do chips even exist that can do what you want without determinism? If so, what are their trade offs (e.g. do we get stuck with a narrower frequency range)? Is the improvement worth the additional prototyping effort?

Glad to hear that ;) I never said, that the suppression is insufficient for my purpose (currently I think it is not), I just wanted to point that out, as the TRF will be operated out of spec. I will search for chips on Tuesday.

So far, from what I can gather you just need to use an external LO source and maybe use the TRF registers to tweak the SSB suppression.

Probably yes. I have to admit that I was not aware of the Mirny, which might be a solid solution for my problem, I have to look into it and figure out if it is actually deterministic. And, sorry to say that, but in that case I will not listen to anyone telling me it is. I had been told the same for the Phaser.

What does serious external hardware mean? Do you mean a an external PLL IC? What does serious software extension mean? Do you mean exposing the TRF registers to tweak the SSB suppression?

Using an external PLL/VCO is one option. The other would be to measure the phase relation between the Phaser output and the 125 MHz reference after the TRFs are locked. Both are much more complex than adding a VCO to the Phaser. Measuring the phase also involves quite a bit of software. For starters, I cannot pass a DC signal though the baseband of phaser, which means I need to generate an additional signal, which I include in the phase measurement afterwards. I have not thought about this very much, yet.

[hartytp]

I have no specification, it is just something I noticed, which is a downside. So you gain determinism by worse sidelobe suppression.

The external VCO can be added without interfering with the current circuit. If you don't need it, you can just ignore it and the software will be 100% compatible between both hardware versions.

Right, let's be clear about design methodology for this project and other Sinara projects (we should really write a page on our philosophy at some point): we do not add complexity to designs without a strong justification. It's very easy to say "if you don't want it don't use it" but IME that always ends up with low quality designs.

From my perspective, and without prejudging the answers, there are a few of things that are strictly required before we can consider adding additional complexity to the design:

1. A specification: how good does this need to be for your application? What phase noise do you need? Making things "as good as possible" without clear direction rarely results in good designs.
2. A consideration of use cases: is this something that's widely useful, or only useful for you? If the latter, then it would be better for you to use a separate PCB with the VCO on than to integrate it directly onto Phaser. It's really easy to underestimate the cost of complexity and we shouldn't make everyone pay that price for a niche application.
3. A proper analysis of the full cost (in the broad sense beyond financials) of your proposal. Not trying to be rude, but when people start putting scare quotes around cost "problem" I get scared. If every user of a design starts trying to add a few components that are specific to their application without consideration of the above, the designs quickly descend into over crowded chaos. This requires thought and curation.

Without those as a starting point I don't think there is a productive conversation to be had here.

Sure, but I am trying to add a feature without impacting anything else (except the cost). I have to admit that I did not had the fact in mind, that the EXT_VCO input MMCX connector will be lost if we add a VCO. I would suggest to add it as a population option, also remove the cost "problem".

Cost, board space which we might want later on, complexity to be managed, increase in routing complexity, risk that when we add this we break an important piece of functionality (all routing/layout changes carry a risk), managing an increasing number of variants, etc. Again, this is not impossible, but it needs to be costed correctly and justified.

The solution can use dividers, and will. Finding a VCO with more than one octave of tuning range is pretty much impossible, so there has to be a divider. But it has to be within the PLL loop and the signal used for the mixer cannot have any additional dividers. And as I said, I haven't come around to come up with a selection of component, maybe it is not possible to do what I want.

Have you looked at the range of ICs? I'm not aware of many PLL ICs with dividers inside the feedback loop. The PLL IC used on Mirny does have dividers inside the feedback loop but the prescaler means that one ends up having to use a really low PFD frequency which has its own problems. There are further subtlties one has to account for like not using autocal if one really wants deterministic phases.

I might be wrong, but I do not thing there is an easy option to do what you're suggesting.

Using an external PLL/VCO is one option. The other would be to measure the phase relation between the Phaser output and the 125 MHz reference after the TRFs are locked. Both are much more complex than adding a VCO to the Phaser. Measuring the phase also involves quite a bit of software. For starters, I cannot pass a DC signal though the baseband of phaser, which means I need to generate an additional signal, which I include in the phase measurement afterwards. I have not thought about this very much, yet.

Right, but here you're thinking about complexity in the narrow context of what you want to do rather than in the context of creating high quality designs that will serve a hole community.

[hartytp]

Probably yes. I have to admit that I was not aware of the Mirny, which might be a solid solution for my problem, I have to look into it and figure out if it is actually deterministic. And, sorry to say that, but in that case I will not listen to anyone telling me it is. I had been told the same for the Phaser.

Right, you always have to be careful with dividers. Also step-tuned VCOs which can give subtler non-determinism even without dividers.

The advantage is that if you use a single Mirny as your LO source for all your upconverters and then use a clocker to distribute it you then get guaranteed determinism between channels (which is generally what one cares about, rather than determinisim w.r.t. the 125MHz), but you need to think this through for your use case

[hartytp]

Anyway, summarising, there is a straightforward solution to your problems which does not require any hardware changes (use an external LO source and change a few registers on the TRF chip) and will work fine for your application.

If you want a change to the phaser design to provide a more integrated solution we need to discuss target specs and use-cases first.

[hartytp]

Some context here in case the above seems a little unfriendly...these designs are used by a lot of people for a lot of different things. Pretty much every user could list off a few small changes that make the designs nicer for their specific application without actively breaking it for others. However, there flat out isn't enough board space to accept all those changes -- let alone more practical considerations like routing, cost, design quality, risks associated with making changes, etc etc

The only workable methodology for a multi-stakeholder project like Sinara is to be very critical about proposed changes and consider the value they add to the design as a whole. If you want to make a fork and add a few changes that make it nicer for your specific application, go for it! But, if you want to alter the main design then you have to come with specs, use-case analysis, etc

[FabianSchwartau]

we do not add complexity to designs without a strong justification.

OK, got it, makes sense. My justification is that it makes the phaser deterministic.

1. A specification: how good does this need to be for your application?

I need determinism - simple as that.

3\. A proper analysis of the full cost (in the broad sense beyond financials) of your proposal. Not trying to be rude, but when people start putting scare quotes around `cost "problem"` I get scared.

As I said countless times, my investigation is not finished yet. I will have a deeper look into possible solutions, their complexity and cost. I just wanted to let everyone know that I would like to see an additional feature for the next release and try to find out if this is even a possibility before I put too much effort into it.

Right, but here you're thinking about complexity in the narrow context of what you want to do rather than in the context of creating high quality designs that will serve a hole community.

OK, here a bit of background why we think we need determinism, even after re-locking the PLLs (please keep in mind that I am not a physicist nor I am too deeply in the topic of quantum computing): We are working on ion traps and want to use the Phaser for microwave gates and readout. The readout has to happen frequently during a single experiment and the required LO frequencies are between ~800 and 1600 MHz, which I cannot cover without re-tuning the PLL. I guess that other groups will need similar functionality.

Anyway, summarising, there is a straightforward solution to your problems which does not require any hardware changes (use an external LO source and change a few registers on the TRF chip) and will work fine for your application.

Well, only IF the Mirny is deterministic. If not, the straightforward solution to the problem is adding the VCO to the Phaser (whether or not it will be an "official" feature).

Some context here in case the above seems a little unfriendly...

Well, honestly, it is a bit unfriendly. I found a problem (for my use case), which I have to solve any way. Additionally, I go to the effort of publicly suggesting a solution which might help others and improve the hardware. I said multiple times that my solution is not yet finished in any way and I will continue to work on it, yet you criticize multiple times the lack of detailed information. I will get there. Whether or not it makes it in the final design, the lack of appreciation will reduce my motivation to report further problems/improvements.

[hartytp]

Well, honestly, it is a bit unfriendly. I found a problem (for my use case), which I have to solve any way. Additionally, I go to the effort of publicly suggesting a solution which might help others and improve the hardware. I said multiple times that my solution is not yet finished in any way and I will continue to work on it, yet you criticize multiple times the lack of detailed information. I will get there. Whether or not it makes it in the final design, the lack of appreciation will reduce my motivation to report further problems/improvements.

Sure. I get where you're coming from, the point is that this kind of issue was considered during the design and we provided an option for it: use the provided MMCX to supply an externally generated LO. If Mirny doesn't do it for you then use whatever other LO you want.

Explaining use cases is always useful and appreciated. Pushing for changes in the design requires a concrete specification and a discussion around the value the change adds to the community as a whole. The challenging part of these designs is generally not finding a way of achieving goals like deterministic phases for a specific application, but finding a good overall design that serves the range of use-cases.

During the design we explicitly considered putting a PLL IC/VCO on Phaser and decided against it for a number of reasons: complexity, cost, power consumption (not to be under-estimated). Part of that discussion was "yes, some users will want better phase noise etc, but that's not going to be the main use-case so we'll cover it by providing an external LO input". Nothing in this discussion so far really changes that calculation for me.

[FabianSchwartau]

the point is that this kind of issue was considered during the design

I did not know that, I wasn't around at that time. And please don't except a user to read through all of the discussions here.

Explaining use cases is always useful and appreciated.

I think I did that and I cannot provide any further information (at least at this time).

The challenging part of these designs is generally not finding a way of achieving goals like deterministic phases for a specific application, but finding a good overall design that serves the range of use-cases.

As I don't know any other use case than mine, I cannot contribute any further at that point. As far as I understood this, every group working on ion traps has (will have) this problem with Phaser. But I am not qualified to tell for sure.

I think I contributed/offered all of my knowledge, wishes, opinions, work time, and potential solutions. If you have no more questions and still think this feature is not worth the effort, feel free to close this issue.

[hartytp]

I did not know that, I wasn't around at that time. And please don't except a user to read through all of the discussions here.

Right, so there is an issue about communication/framing here. It's quite different to say "I think we should change the design in such and such a way" versus "I'm trying to do this and having this problem, what do you think". Expecting people to do a bit of digging through issues before posting is reasonable IMHO. But, beyond that, asking questions before suggesting solutions generally leads to more productive conversations.

[hartytp]

As far as I understood this, every group working on ion traps has (will have) this problem with Phaser. But I am not qualified to tell for sure.

The requirements vary a lot between different experiments. Right now I'm satisfied that (a) the design covers a lot of use cases without external VCOs and (b) using an external VCO is a fine solution for the cases it doesn't cover (in many cases people with strict phase determinism requirements also have strict noise requirements and have tight specifications for their LO source so will want to generate that off Phaser). Changing that needs a broader discussion about use cases, a specification for phase noise, etc

Also, NB that AFAICT there is at least one part of your application which is non-standard: hopping the upconverter LO mid-sequence. That's something most people don't want to do since the settling time to get really good phase stability (say, 0.1deg) is pretty long compared with other operations.

[hartytp]

On a technical level, note that the vast majority of all PLL ICs you'll find have this structure

with the output divider explicitly outside the feedback loop. Last time I looked into this precise issue (admittedly a while back, but anyway) I only identified a single PLL + VCO IC that had the output divider inside the loop: the ADF IC used on Mirny which has this structure

so it is possible to route the divided signal into the PFD. However...one can't bypass the prescaler. As a result, the PFD frequency gets rather low which generates its own issues. Beyond that, even with the divider inside the feedback loop one doesn't necessarily get fully deterministic phases; the dividers become synchronised but one also has to do things like disable the PLL auto-cal etc. (although, this is generally not a huge effect, so the question comes back to: how deterministic do you want this? what are what are we actually trying to achieve here?) It's doable but not totally trivial and takes work (plus mucking around with un-documented IC registers). The other option is to use separate PFD + VCO + divider ICs and build something oneself but then it's just a lot of mess to add.

Or one could use the PFD inside the TRF IC and use an external step-tuned VCO IC. That has the downside that it still has the relatively poor phase noise performance from the TRF chip.

So there are plenty of solutions, but they're not trivial and the right one depends on what we're actually trying to achieve. e.g. what phase noise floor? That level of specification needs to precede discussions about implementation.

In the mean time, these all take up board area, which is at a premium, and consume power on a design that's already getting pretty toasty.

[FabianSchwartau]

Yeah, I know that it is not an easy task. Two things I don't understand: What does the prescaller exactly do? It is another frequency division, right? But by what? 4/5 means a division (multiplication?) by 0.8? Or does it mean it is using either 4 or 5? Why is the autocal a problem? As far as I understand it will just tune the VCO core to use the correct capacitors or whatever. As the VCO is within the loop, any phase difference cause by that should be compensated by the PLL?

[FabianSchwartau]

So there are plenty of solutions, but they're not trivial and the right one depends on what we're actually trying to achieve. e.g. what phase noise floor? That level of specification needs to precede discussions about implementation.

I asked this question several times in our group and beyond, the answer I always got: We don't really know, whatever you got is good enough. And that is my current assumption for the design of the hardware.

[hartytp]

Why is the autocal a problem? As far as I understand it will just tune the VCO core to use the correct capacitors or whatever. As the VCO is within the loop, any phase difference cause by that should be compensated by the PLL?

The auto cal will non-deterministically select one out of a small number of VCO configurations that can achieve a desired frequency. If everything was perfect, this wouldn't be an issue because of the feedback. However....the different VCOs configurations have different non-idealities like leakage currents which can result in different locked phase offsets. How big these effects are depends on PFD frequency, loop filter design, etc but as a point of reference, when I played with this using an eval board for the PLL on Mirny it was beyond what I was willing to accept at the time (I can't give a better answer without digging through my notes). There were various factors that weren't helping in that measurement (passive loop filter, low PFD due to the pre-scaler, etc) so I'm not saying it's always death, but just that if one really cares about phase determinism then one needs to be prepared to do a lot of iterative design. This is not an issue people talk about much, but if you trawl google you'll find various discussions and posts on the ADI forums (this is where you can find how to read disable the auto-cal on the ADF PLLs to guarantee which VCO configuration you're using).

[hartytp]

I asked this question several times in our group and beyond, the answer I always got: We don't really know, whatever you got is good enough. And that is my current assumption for the design of the hardware.

I get that, and that's fine for your internal development, but I think we should put discussions about potential changes to Phaser on ice until we have a clearer map of the exact requirements.

[hartytp]

@Jacky2k I was thinking about this issue a bit more and I'm still not totally sure I understand what problem you're trying to solve. On the off-chance this is really an X-Y problem, I'd be interested to dig into it a bit more.

OK, here a bit of background why we think we need determinism, even after re-locking the PLLs (please keep in mind that I am not a physicist nor I am too deeply in the topic of quantum computing): We are working on ion traps and want to use the Phaser for microwave gates and readout. The readout has to happen frequently during a single experiment and the required LO frequencies are between ~800 and 1600 MHz, which I cannot cover without re-tuning the PLL. I guess that other groups will need similar functionality.

Am I right in thinking that this is 25Mg+ at 212.8G? So you're trying to hit transitions between 1.326GHz and 1.686GHz (see level diagram below)? So the actual range you need to span is only 360MHz.

Unless I'm missing something, Phaser should give you +-400MHz of IQ bandwidth around the LO frequency so there shouldn't be any need to retune the PLL -- stick the LO at any convenient frequency in the middle and you're done, right?

[hartytp]

or, is the statement about readout really a red herring and you're concerned with phase determinism between power cycles?

[hartytp]

anyway, modulo the above, let me summarise where I think we are on this:

You've explained a use case, which is helpful and welcome. One of the major limitations in improving these designs is lack of visibility over how they are used outside the handful of labs that we speak to regularly, so thanks for the contribution.

You've pointed out a subtlety that's easily missed: Phaser is a complex design and it's certainly not the case that it will give phase determinism across power cycles for all settings. Having this kind of conversation on GitHub is useful for others hitting similar issues, so thanks for that.

We've discussed at least one work around for the issues you're hitting: use the MMCX to supply an externally generated LO with your required phase properties.

We have discussed the possibility of adding additional circuitry (minimally, something like a step-tuned VCO + SPI microwave divider) to integrate a LO with the phase properties you're after onto Phaser. However, I do not feel that the discussion here is moving in a direction where we're going to be able to action that and change the design; as you've said, you don't have a specification for what you're after, you want something that will work for your application without too much additional thought. As I've pointed out before, that's a very reasonable and pragmatic approach for your lab, but not a practical way of maintaining something like Sinara. Before we can consider design changes based on this we need further discussion: as @jordens has already pointed out, if your only aim is to take out divider indeterminism, using the FPGA as a phase detector is a potentially very nice route to go down that should be explored; if we do want a VCO, what noise properties does it need, what frequency range, tuning bandwidth, etc? Once we add additional circuitry we won't be able to remove it, so we need to make sure that the change actually solves the wider issue of high-performance upconverter LO generation for the majority of users, rather than just getting your experiment up and running.

So, I'm going to close this issue. If you feel that you want to continue the discussion about specifications/approaches now or at another time feel free to reopen it. If you still have concerns about why -- based on the current discussion -- I'm not more open to implementing the suggested changes, maybe it's worth another Sinara veteran who hasn't participated in this discussion yet (e.g. @dhslichter ) giving their perspective on our approach to maintaining these designs.

[hartytp]

Note that even though this issue is closed, I'd encourage you to consider posting results of any further work you do on this here. Any data will help us inform future discussions.

If you do find a suitable replacement for the TRF chip that does what you want (i.e. broadly same spec as current chip but with the dividers inside the feedback loop) post the part number and we can consider changes (my current understanding is that there is no such chip commercially available, but I'd welcome being proved wrong on that).

[hartytp]

Glad to hear that ;) I never said, that the suppression is insufficient for my purpose (currently I think it is not), I just wanted to point that out, as the TRF will be operated out of spec. I will search for chips on Tuesday.

To check we're on the same page about what we mean by "operated out of spec": looking at the upconverter datasheet I don't see any explicit specification for the external LO input frequency range. From the data sheet, it's not really clear to me what the spec is here. As you point out, the carrier suppression degrades slightly with frequency (although, as we've agreed, even at 1GHz it should be plenty good enough for most use cases and can be improved by software trimming if needed), but beyond that, it's not clear to me that this isn't a completely fine thing to do. Did you did into this any further (e.g. post on the TI forum)?

[FabianSchwartau]

Am I right in thinking that this is 25Mg+ at 212.8G? So you're trying to hit transitions between 1.326GHz and 1.686GHz (see level diagram below)? So the actual range you need to span is only 360MHz.

Unless I'm missing something, Phaser should give you +-400MHz of IQ bandwidth around the LO frequency so there shouldn't be any need to retune the PLL -- stick the LO at any convenient frequency in the middle and you're done, right?

No. We are working with Be+, which requires 1070, 1083, and 1095 MHz for the gates and additionally 754, 854, 954, 983, 1183, 1240, 1398, 1525, and 1764 MHz for the readout. The last one is kind of optional. Even if I leave out the last one, the ONLY LO frequency I can choose is 1125 MHz, as it is a multiple of 125 MHz and covers all frequencies. However, when generating 1398 MHz with this LO, the mirror frequency will be at 852 MHz, which is too close to 854 MHz. I need a bit of flexibility in the LO to make sure to not "accidentally" hit any other resonance frequency.

To check we're on the same page about what we mean by "operated out of spec": looking at the upconverter datasheet I don't see any explicit specification for the external LO input frequency range. From the data sheet, it's not really clear to me what the spec is here. As you point out, the carrier suppression degrades slightly with frequency (although, as we've agreed, even at 1GHz it should be plenty good enough for most use cases and can be improved by software trimming if needed), but beyond that, it's not clear to me that this isn't a completely fine thing to do. Did you did into this any further (e.g. post on the TI forum)?

Yes, you are right, the datasheet does not mention any limit for the EXT_VCO frequency. I should have chosen better words here: I measured that the TRF is not within spec, which might be because this is not a use-case covered by the datasheet or the designers - or I made a mistake in the measurement. I did not look further into replacing the TRFs.

[hartytp]

No. We are working with Be+, which requires 1070, 1083, and 1095 MHz for the gates and additionally 754, 854, 954, 983, 1183, 1240, 1398, 1525, and 1764 MHz for the readout. The last one is kind of optional. Even if I leave out the last one, the ONLY LO frequency I can choose is 1125 MHz, as it is a multiple of 125 MHz and covers all frequencies. However, when generating 1398 MHz with this LO, the mirror frequency will be at 852 MHz, which is too close to 854 MHz. I need a bit of flexibility in the LO to make sure to not "accidentally" hit any other resonance frequency.

are you ruling out R divs / frac-N PLLs?

If you don't need 1764 then you need to span 771MHz which (IIRC) should be doable without dynamically tuning the LO.

[hartytp]

Putting this another way, is the simplest solution here to use Mirny or any other decent source to produce a fixed LO that you can distribute (e.g. with clocker or any other distribution amp) to all of your Phasers to get deterministic phases and also improved phase noise performance?

That also eliminates the need to worry about the settling dynamics after tuning the LO frequency (which weren't considered at all during the design, since dynamic LO tuning was not a use case we thought about).

[FabianSchwartau]

are you ruling out R divs / frac-N PLLs?

Fractional is not an option I think, R div is fine as long as all dividers for the RF signal are within the PLL loop.

If you don't need 1764 then you need to span 771MHz which (IIRC) should be doable without dynamically tuning the LO.

Putting this another way, is the simplest solution here to use Mirny or any other decent source to produce a fixed LO that you can distribute (e.g. with clocker or any other distribution amp) to all of your Phasers to get deterministic phases and also improved phase noise performance?

That also eliminates the need to worry about the settling dynamics after tuning the LO frequency (which weren't considered at all during the design, since dynamic LO tuning was not a use case we thought about).

This is what I am currently working on. I asked for an offer for Mirny/Clocker, but got no response yet ;)

[dtcallcock]

754, 854, 954, 983, 1183, 1240, 1398, 1525, and 1764 MHz for the readout

In my experience, many of the frequencies at the upper and lower end of this range are just shelving pi-pulses that don't need to be super high spec or phase coherent with anything. At NIST we just used a DDS channel for these (and a switch to multiplex). This lets you make the all-singing, all-dancing pulse generator for the gates a narrow-band design that can be better optimized for that task.