Re: [ARTIQ] ARTIQ Digest, Vol 50, Issue 2
On Tue, Jul 17, 2018 at 5:52 PM Slichter, Daniel H. (Fed) via ARTIQ wrote: > > You just need to get away from specifying sample rates and > > details of the DSP chain and start specifying the actual use cases. > > My apologies; I thought I had sent an email to the entire list but it turns > out it just went to Sebastien. I reproduce the email I sent Sebastien last > Friday below (with a couple of minor clarifications), which gives our use > cases and the motivation for wanting to run at 1 GSPS as well as 600 MSPS. Thanks. > > What sample rate(s) would you like to see and why? > > The primary application here would be the driving of AOMs centered at 220 MHz > (which could be done at 600 MSPS in theory) or 330 MHz (much harder to avoid > Nyquist images at 600 MSPS). We would most likely want 1 GSPS, with an RTIO > clock of 125 MHz, which also aids compatibility with our other hardware and > its RTIO clock frequencies (although some of our setups run with 100 MHz RTIO > clock, and thus we'd aim for 8x multiplexing still but which would yield 800 > MSPS -- still suitable for the 220 MHz and 330 MHz AOMs though). For a 1 > GSPS data rate, the DAC clock could be run at 1 GSPS, or with the 2x > interpolation enabled at 2 GSPS. We also have AOMs at ~600 MHz that we would > like to drive. For this application, we would take the second Nyquist image > running at 1 GSPS with no DAC interpolation, probably in mix mode and define > our band with filters afterwards (200 MHz would then separate first and > second Nyquist images so easy to filter). For obvious reasons 600 MSPS would > be a very poor data rate choice for this application. > > The second application for this would be microwave hyperfine transitions > accessed using single-sideband mixing with the Sayma outputs as the I and Q > inputs to an external mixer. Having 1 GSPS data rates would give us > sufficient bandwidth to span the hyperfine manifold of 25Mg+ qubits at > intermediate field (212 G); running at 600 GSPS (for example) would not allow > this, as spanning all relevant hyperfine transitions for shelving requires > ~700 MHz of bandwidth (350 MHz on each side of a carrier would work). For > this application, we would likely want to use 2x DAC interpolation to improve > spectral purity and clean up undesired Nyquist images. > > Because of the way the internals of the DAC work, using the NCO in the DAC to > shift signals to higher Nyquist bands forces the outputs to be paired as I/Q > channels, so for direct synthesis of microwaves for 9Be+ or 25Mg+ qubits, one > would have to discard half the output channels. For this task we would > probably perform updates of the internal NCO to shift frequencies coarsely, > but data rates of 1 GSPS would allow 2x digital upconversion plus internal > NCO shifting to higher Nyquist zones, at the cost of half the output > channels, to enable direct output using mix-mode of signals up to 2 GHz, > placing undesired images out of harm's way for 9Be+ at low field. At > intermediate field (119 G), relevant 9Be+ transitions are between 1 GHz and > 1.4 GHz, so using 800 MSPS with 2x digital upconversion and mix-mode would > probably work better. Using 600 MSPS data rates with 4x upconversion would > enable signals out to 2.4 GHz, which would be more suitable for 25Mg+ direct > generation at 212 G (~1.3 GHz to ~2.1 GHz). Ok. My question is about the parametrization of the waveform. * Is (f0+f1, f0+f2) better than (f0+f1-f2, f0+f1+f2)? (with f0 coarse, and f1/f2 fine) etc. Or other parametrizations. * Is it better to have relative frequency/amplitude/phase or absolute (additive or multiplicative) amplitude/frequency/phase between the tones? * Also consider all those things with the servoing and modulation applications in mind that were initially required. * What is the maximum step size of f0 in terms of the f1/f2 rate? * What width is really needed for the FTW on f1/f2? * What width do we need for the CORDICs (IQ)? Are we just beating the spurs? Then we certainly don't need 16 bits. Or is 16 bit amplitude resolution needed? And saying "one LSB", "16 bit" or equivalent might sound convenient but it's also potentially very expensive. If the requirement can't be derived from physics, then something like the DAC SFDR would be a reasonable target. Everybody needs to weigh in here. > > With high sample rates, there are two ways to ease the FPGA resource burden: > > * use the DAC interpolation modes (2X, 4X, 8X) if the goal is simply > > to improve spectral purity. > > I think we definitely would like to see these implemented to improve spectral > purity. Implementation of the Nyquist band shifting with the DAC onboard NCO > would be good but can happen later as long as 1 GSPS data rates are supported. > > * drastically reduce the SAWG digital upconverter resolution to a few > > frequencies (use the other NCOs to for fine tuning). > > Referencing the Github comment that Tom
Re: [ARTIQ] ARTIQ Digest, Vol 50, Issue 2
> You just need to get away from specifying sample rates and
> details of the DSP chain and start specifying the actual use cases.
My apologies; I thought I had sent an email to the entire list but it turns out
it just went to Sebastien. I reproduce the email I sent Sebastien last Friday
below (with a couple of minor clarifications), which gives our use cases and
the motivation for wanting to run at 1 GSPS as well as 600 MSPS.
===
> What sample rate(s) would you like to see and why?
The primary application here would be the driving of AOMs centered at 220 MHz
(which could be done at 600 MSPS in theory) or 330 MHz (much harder to avoid
Nyquist images at 600 MSPS). We would most likely want 1 GSPS, with an RTIO
clock of 125 MHz, which also aids compatibility with our other hardware and its
RTIO clock frequencies (although some of our setups run with 100 MHz RTIO
clock, and thus we'd aim for 8x multiplexing still but which would yield 800
MSPS -- still suitable for the 220 MHz and 330 MHz AOMs though). For a 1 GSPS
data rate, the DAC clock could be run at 1 GSPS, or with the 2x interpolation
enabled at 2 GSPS. We also have AOMs at ~600 MHz that we would like to drive.
For this application, we would take the second Nyquist image running at 1 GSPS
with no DAC interpolation, probably in mix mode and define our band with
filters afterwards (200 MHz would then separate first and second Nyquist images
so easy to filter). For obvious reasons 600 MSPS would be a very poor data
rate choice for this application.
The second application for this would be microwave hyperfine transitions
accessed using single-sideband mixing with the Sayma outputs as the I and Q
inputs to an external mixer. Having 1 GSPS data rates would give us sufficient
bandwidth to span the hyperfine manifold of 25Mg+ qubits at intermediate field
(212 G); running at 600 GSPS (for example) would not allow this, as spanning
all relevant hyperfine transitions for shelving requires ~700 MHz of bandwidth
(350 MHz on each side of a carrier would work). For this application, we would
likely want to use 2x DAC interpolation to improve spectral purity and clean up
undesired Nyquist images.
Because of the way the internals of the DAC work, using the NCO in the DAC to
shift signals to higher Nyquist bands forces the outputs to be paired as I/Q
channels, so for direct synthesis of microwaves for 9Be+ or 25Mg+ qubits, one
would have to discard half the output channels. For this task we would
probably perform updates of the internal NCO to shift frequencies coarsely, but
data rates of 1 GSPS would allow 2x digital upconversion plus internal NCO
shifting to higher Nyquist zones, at the cost of half the output channels, to
enable direct output using mix-mode of signals up to 2 GHz, placing undesired
images out of harm's way for 9Be+ at low field. At intermediate field (119 G),
relevant 9Be+ transitions are between 1 GHz and 1.4 GHz, so using 800 MSPS with
2x digital upconversion and mix-mode would probably work better. Using 600
MSPS data rates with 4x upconversion would enable signals out to 2.4 GHz, which
would be more suitable for 25Mg+ direct generation at 212 G (~1.3 GHz to ~2.1
GHz).
> With high sample rates, there are two ways to ease the FPGA resource burden:
> * use the DAC interpolation modes (2X, 4X, 8X) if the goal is simply
> to improve spectral purity.
I think we definitely would like to see these implemented to improve spectral
purity. Implementation of the Nyquist band shifting with the DAC onboard NCO
would be good but can happen later as long as 1 GSPS data rates are supported.
> * drastically reduce the SAWG digital upconverter resolution to a few
> frequencies (use the other NCOs to for fine tuning).
Referencing the Github comment that Tom referred to in his email:
https://github.com/sinara-hw/sinara/issues/515#issuecomment-371481089
"Even up-conversion to n*k/m*f_RTIO (k=8=f_sample/f_RTIO here) with m=16 and n
\in {0,...,m-1} could turn out to be as simple as m=8."
This kind of selection of available DUC frequencies on SAWG would be more than
enough from my perspective. For finer compensation you could just put the
frequency shift in the sine waves generated at baseband, as pointed out by Tom.
Best,
Daniel
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] ARTIQ Digest, Vol 50, Issue 2
On Fri, Jul 13, 2018 at 6:06 PM Slichter, Daniel H. (Fed) via ARTIQ wrote: > I think we will really need the 8x interleaving at the RTIO clock rate, > because 1 GSPS is pretty critical (600 MSPS is marginal or a non-starter for > most of our use cases). This to me seems much more important than > maintaining some kind of more arbitrary flexibility for DUC. I am a little > unclear on others' use cases regarding DUC on the FPGA itself, but it seems > to me that simply being able to shift the output by integer multiples of fs/8 > (or fs/16, perhaps) should be more than satisfactory. It would appear to me > that any tuning with finer frequency resolution can/should be done with the > baseband signals coming out of the 8 interleaved generation blocks. > Sebastien, are you saying that even this level of DUC presents substantial > challenge? No. That was exactly my proposal. On top of that there are probably more possibilities to simplify this dramatically. You just need to get away from specifying sample rates and details of the DSP chain and start specifying the actual use cases. Robert. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] ARTIQ Digest, Vol 50, Issue 2
On Wednesday, July 11, 2018 04:59 AM, Thomas Harty via ARTIQ wrote: My view is that we shouldn't give up the flexibility of being able to fine-tune the DUC frequency unless there is a good reason to do so. For example: if the complexity/compile times of the current code make development/maintenance problematic(*), or if the current code is going to have issues achieving the full 1GSPS data rate. It would be good to hear a bit more from SB/RJ on the advantages of moving to a simpler DUC parametrization. Right now we are producing 4 DAC samples per cycle (150MHz RTIO, 600MHz DAC). Moving to 1GSPS will need 8 samples per cycle (125MHz RTIO), i.e. requiring twice the FPGA resources plus adding interconnection paths between the parallel units. This can only exacerbate issues of compilation time, routing congestion, and timing closure. The last two can probably be addressed but there is no free lunch - it'll take significant work. And the compilation time would always remain problematic. Having the fixed DUC frequencies would simplify the sample generation logic and reduce the problems. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] ARTIQ Digest, Vol 50, Issue 2
> Fine adjustment of SAWG f0 by RTIO and local DSP is the planned path > for dynamically compensating for time-variation of the Coherent > Paladin laser repetition rate. Could the resolution of the the f0 NCO > be defined parametrically? This could enable relatively > straightforward switching between faster compile times and finer > resolution. Can't you do that equally well by adjusting the frequencies of the baseband oscillators while holding the DUC frequency fixed (assuming the drifts are small compared with the RTIO frequency)? My view is that we shouldn't give up the flexibility of being able to fine-tune the DUC frequency unless there is a good reason to do so. For example: if the complexity/compile times of the current code make development/maintenance problematic(*), or if the current code is going to have issues achieving the full 1GSPS data rate. It would be good to hear a bit more from SB/RJ on the advantages of moving to a simpler DUC parametrization. (*) this was certainly the case in the early days of Sayma where the board behaved differently when replacing the SAWG with a dummy ramp generator. Thankfully now the PI issues that caused that have been fixed, it seems that all non-SAWG related issues can be debugged without compiling the SAWG, so this may be less of an issue... Dr Thomas Harty Junior Research Fellow, St John's College University of Oxford, Department of Physics The Clarendon Laboratory Parks Road, Oxford, OX1 3PU Mob: +44 (0)7986 375 052 Lab: +44 (0)1865 272 572 From: Joe Britton Sent: 10 July 2018 21:37:31 To: Thomas Harty Cc: artiq@lists.m-labs.hk Subject: Re: [ARTIQ] ARTIQ Digest, Vol 50, Issue 2 > It would be good to get the interpolation running, both to improve spectral > purity and to put the hardware through its paces before we move on to the > next design revision (I'd love to see synchronisation at max DAC clock > rate). I agree with @hartytp on this. Pushing digitization artifacts to higher frequencies is really helpful. >> drastically reduce the SAWG digital upconverter resolution to a few >> frequencies (use the other NCOs to for fine tuning). Fine adjustment of SAWG f0 by RTIO and local DSP is the planned path for dynamically compensating for time-variation of the Coherent Paladin laser repetition rate. Could the resolution of the the f0 NCO be defined parametrically? This could enable relatively straightforward switching between faster compile times and finer resolution. > - f_RTIO = 125MHz > - f_DAC = 2GHz > - f_data = 1GSPS (2 x interpolation) These parameters are fine for the UMD-Duke-ARL application set. -Joe ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] ARTIQ Digest, Vol 50, Issue 2
> It would be good to get the interpolation running, both to improve spectral > purity and to put the hardware through its paces before we move on to the > next design revision (I'd love to see synchronisation at max DAC clock > rate). I agree with @hartytp on this. Pushing digitization artifacts to higher frequencies is really helpful. >> drastically reduce the SAWG digital upconverter resolution to a few >> frequencies (use the other NCOs to for fine tuning). Fine adjustment of SAWG f0 by RTIO and local DSP is the planned path for dynamically compensating for time-variation of the Coherent Paladin laser repetition rate. Could the resolution of the the f0 NCO be defined parametrically? This could enable relatively straightforward switching between faster compile times and finer resolution. > - f_RTIO = 125MHz > - f_DAC = 2GHz > - f_data = 1GSPS (2 x interpolation) These parameters are fine for the UMD-Duke-ARL application set. -Joe ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] ARTIQ Digest, Vol 50, Issue 2
> use the DAC interpolation modes (2X, 4X, 8X) if the goal is simply to improve > spectral purity. It would be good to get the interpolation running, both to improve spectral purity and to put the hardware through its paces before we move on to the next design revision (I'd love to see synchronisation at max DAC clock rate). > drastically reduce the SAWG digital upconverter resolution to a few > frequencies (use the other NCOs to for fine tuning). You mean something like https://github.com/sinara-hw/sinara/issues/515#issuecomment-371481089 ? I can't see that being a problem for us, so if it makes a big difference to the ease of development/maintenance then I'd be happy with it. Long term, the configuration I'd like to use is: - f_RTIO = 125MHz - f_DAC = 2GHz - f_data = 1GSPS (2 x interpolation) T Dr Thomas Harty Junior Research Fellow, St John's College University of Oxford, Department of Physics The Clarendon Laboratory Parks Road, Oxford, OX1 3PU Mob: +44 (0)7986 375 052 Lab: +44 (0)1865 272 572 From: ARTIQ on behalf of artiq-requ...@lists.m-labs.hk Sent: 09 July 2018 11:00:04 To: artiq@lists.m-labs.hk Subject: ARTIQ Digest, Vol 50, Issue 2 Send ARTIQ mailing list submissions to artiq@lists.m-labs.hk To subscribe or unsubscribe via the World Wide Web, visit https://ssl.serverraum.org/lists/listinfo/artiq or, via email, send a message with subject or body 'help' to artiq-requ...@lists.m-labs.hk You can reach the person managing the list at artiq-ow...@lists.m-labs.hk When replying, please edit your Subject line so it is more specific than "Re: Contents of ARTIQ digest..." Today's Topics: 1. Sayma DAC frequencies (Sébastien Bourdeauducq) -- Message: 1 Date: Mon, 9 Jul 2018 12:08:50 +0800 From: Sébastien Bourdeauducq To: "artiq@lists.m-labs.hk" Subject: [ARTIQ] Sayma DAC frequencies Message-ID: <26b2caca-db15-edc3-b2e3-e045064d6...@m-labs.hk> Content-Type: text/plain; charset=utf-8; format=flowed Hi, I'm trying to determine what is the best way forward to support sample rates better than the current 600MHz with the Sayma DAC and SAWG. What sample rate(s) would you like to see and why? With high sample rates, there are two ways to ease the FPGA resource burden: * use the DAC interpolation modes (2X, 4X, 8X) if the goal is simply to improve spectral purity. * drastically reduce the SAWG digital upconverter resolution to a few frequencies (use the other NCOs to for fine tuning). Are those acceptable? We have a large FPGA, but high resource utilization means long compilation times and potential difficulties to meet timing, so it is still a good idea to make the design as light as possible. Sébastien -- Subject: Digest Footer ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq -- End of ARTIQ Digest, Vol 50, Issue 2 ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
