Phaser servo

[hartytp]

ARTIQ Feature Request

Problem this request addresses

Phaser (hardware gateware) is a Sinara SAWG (smart AWG) for multi-tone RF generation.

It has two RF output channels, each providing "baseband" outputs up to ~400MHz with optional (population variant) upconverters to get to ~5GHz.

It also has two analog input channels, each offering ~500kHz of analog bandwidth. The main intended use case for these is amplitude/phase feedback using "a port of SU-servo". This issue is intended to be a scoping exercise to establish what exactly that should mean, comments/corrections very welcome!

Describe the solution you'd like

Initial thoughts in no particular order:

• One loop filter for each output channel. Loop filters are IIR (PI, I'm assuming D not needed)
• All "software" (coredevice) updatable parameters should be updatable in <1us (ideally hundreds of ns)
• As with SU-servo, each channel has multiple -- up to 32 if easy, but fewer acceptable -- "profiles", consisting of: offset, gains, accumulator.
• software controllable mux to allow selection of which ADC is the input to each loop filter
• per-channel and per-card software IIR enables (integrator S/H)
• software controllable output override when integrator disabled
• software configurable delay between IIR enable set and IIR updates starting. Max delay of a us or so (AOMs, any digital latency, etc)
• loop filter output controls a multiplicative scaling factor on the ASF (all tones scaled equally). A future (i.e. not part of an initial contract) feature would be e.g. frequency feedback for PLLs.
• Closed-loop bandwidth: SU-servo can achieve ~100kHz (limited by the ~1us latency in each of the ADC and DDS). Phaser has a 5MSPS LVDS ADC and ~2MHz AFE 3dB bandwidth so can go a bit faster. It would be nice to push the achievable closed-loop BW close to the hardware limits.
• Readback
  • Per-channel high/low clipping indicators (cf https://github.com/m-labs/artiq/issues/1400)
  • otherwise same diagnostics as SU servo
• It would be nice (resources/timing etc) to keep the two channels separate and prioritize simplicity of implementation/extendability over efficiency as far as possible given other constraints. This is a bit of a wooly goal I admit, but I want to make sure this is easy to work on and extend, compared with SU-Servo which is a bit dense and couples everything together tightly to achieve a very efficient design.
• Moninj: I don't think Moninj should be part of an initial contract, but it's something we should consider for the future, particularly once "scalable moninj" lands. I'd love something to make asynchronous logging/monitoring of clipping and "y" values easy (e.g. to check for slow drifts in fibre coupling etc).
• PGIA gain control + readback from software

cc @jordens @dnadlinger @cjbe

[jordens]

• Feedback on amplitude restricts operating range. Consider feedback on power, i.e. sqrt before IIR or after.
• How does the per-card software IIR enable differ from the per-channel? Is it AND or OR?
• "a bit faster" is a bit vague. Could you run the numbers and get a minimum required and maximum achievable latency from the datasheets and the schematics?
• One parameter update per 1 µs is doable. All is impossible. There are about 65 Mb/s control data bandwidth remaining for everything (attenuators, DAC SPI, upconverter SPI, all servo config and servo control, LEDs, frequency shifter etc). But since this is already very cramped and necessarily tied to the DAC data framing, it won't be nice and easily extended.
• Readback and consequently moninj will be slower (like 32 Mb/s plus lots of round trip latency)
• What's the channel enable rate synchronicity (between channels and granularity w.r.t. RTIO clock) requirements?

[hartytp]

Feedback on amplitude restricts operating range. Consider feedback on power, i.e. sqrt before IIR or after.

You mean because of loop stability?

That's an interesting one, which we've discussed a few times but not bothered with. It's a little more complex since some AOMs are double-passed and some are single-passed. Also, if we want to do microwave amplitude leveling then there are different possible detector/modulator responses to consider.

My aim here is to scope out a minimal viable contract for intensity stabilization on Stabilizer. It's good to keep these kinds of things in mind but I think they'll probably have to wait for a later contract.

How does the per-card software IIR enable differ from the per-channel? Is it AND or OR?

I was thinking AND. But, on second thoughts, it's probably not worth the effort. It's only a two channel board.

"a bit faster" is a bit vague. Could you run the numbers and get a minimum required and maximum achievable latency from the datasheets and the schematics?

@cjbe @dnadlinger not sure if you have any particular minimum bandwidth in mind for this. I'd like to get a few hundred kHz out of it, but that's not a hard requirement.

yes, we can knock up a quick python simulation to look at the max possible bandwidth limited by the ADCs etc (but ignoring the FPGA-related latency).

Readback and consequently moninj will be slower (like 32 Mb/s plus lots of round trip latency)

Noted.

What's the channel enable rate synchronicity (between channels and granularity w.r.t. RTIO clock) requirements?

Again, @dnadlinger @cjbe and others should feel free to chip in here, but I'm not worried about synchronicity on the channel enables. If the noise eaters kick in at slightly different times/have some jitter WRT the RTIO clock, that's fine by me. So long as we can noise-eat on decently small pulses (limited by the loop settling time and fixed latencies) I'm happy.

It would be nice to have a good interface for shaped pulses where we can start a pulse ramp and turn the NE enable on at the same time, using the delay parameter to avoid noise-eating during the shape. I don't have any nice ideas for how this sould look.

Readback and consequently moninj will be slower (like 32 Mb/s plus lots of round trip latency)

Thanks, noted!

One parameter update per 1 µs is doable. All is impossible. There are about 65 Mb/s control data bandwidth remaining for everything (attenuators, DAC SPI, upconverter SPI, all servo config and servo control, LEDs, frequency shifter etc). But since this is already very cramped and necessarily tied to the DAC data framing, it won't be nice and easily extended.

Noted. I would not want to over complicate the interface to squeeze the parameter update rate.

[jordens]

@hartytp Another use case would be dynamic servoing not to a fixed setpoint defined in a profile but to a variable one, i.e. servo to a desired RF envelope streamed over the data channel. This wouldn't be possible with the current design and it wouldn't necessarily be easy to add on later. Instead of streaming baseband data, you would stream the setpoint AM data and and FM/PM data of the (single) oscillator.

[hartytp]

@jordens I know that some people do that, but it's not something we have any plans for here at the present time. Doing all the shaping open-loop with a relatively slow feedback loop to take out amplitude drifts is fine for us. I'm not aware of any other groups plans to use phaser so can't comment on wider applicability.