> 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).
Thanks for writing that up Daniel. The use cases I have in mind are a subset of the ones you describe. I don't currently plan to use the DAC's internal NCO or "digital mixer mode" for anything. Instead, we will use the "MixMod" analog SSB upconversion AFE, which will incorporate a high-quality PLL to generate the LO. The the DAC's phase noise is not great, so this should give better performance. It should also suffer less from X-talk/SI issues in the AFE connector than using mixer mode directly. With 1GSPS data rate and appropriate choice of LO frequency, that should give more than enough baseband bandwidth to span a hyperfine manifold, even for intermediate field qubits. Did you consider doing this? If so, what are your reasons for wanting to use digital mixer mode instead? AFAICT, if you use MixMod instead of digital mixing, you won't need the 600MHz DAC clock for anything. Is that correct? If we only had to support a single configuration in software/gateware (8x DUC parallelism) then it might make life easier than supporting + maintaining multiple configurations. > * Is it better to have relative frequency/amplitude/phase or absolute > (additive or multiplicative) amplitude/frequency/phase between the > tones? I'm not overly fussed about whether we specify frequency/phase/amplitude for the two tones on a single channel in terms of absolute values or common-mode and difference values (although, I do need to be able to specify both the common-mode *and* difference; relative values alone aren't enough). For most applications I have in mind, common-mode and differences are the more natural parameters to use (at least for amplitude and phase). But I can work with either. > * Also consider all those things with the servoing and modulation > applications in mind that were initially required. The main servo I have in mind at the moment is an amplitude servo very much along the lines of SU-servo. It might be nice to push the servo bandwidth up a little if JESD latency etc allows (we can probably put a 2-5MSPS ADC on Sayma's AFE). I can also imagine using a phase servo e.g. for beat note stabilization. I would be happy doing the downconversion to DC externally (photodiode + mixer) instead of using a high-speed JESD ADC (e.g. a 125MSPS ADC operating in the 3rd nyquist zone) + digital down conversion. So, again, that would look a lot like SU-servo, but with the IIR output controlling the phase (in most cases the beat note would only be available in pulses, making feedback to the frequency trickier). For cases where the beat note is available all the time at a constant frequency (e.g. fiber phase noise cancellation) I would probably use Sampler + Urukul instead of Sayma (if there is no pulse shaping etc, why use Sayma?). I would be fine with only being able to servo the common-mode amplitude/phase for the two tones on a single-channel if that makes life easier in the gateware/software. I would like the ability for a single IIR output to control more than one channel (e.g. for IQ pairs). I don't have any fancy modulation schemes/digital down conversion from a fast ADC in mind. e.g. I don't think it makes sense to use Sayma for PHD locks -- it's so much easier and cheaper to spin up a Eurocard with a DDS for that. > * Is (f0+f1, f0+f2) better than (f0+f1-f2, f0+f1+f2)? (with f0 coarse, > and f1/f2 fine) etc. Or other parametrizations. > * What is the maximum step size of f0 in terms of the f1/f2 rate? By `(f0 + f1)` do you mean the current parametrization? http://m-labs.hk/artiq/manual-master/core_drivers_reference.html?highlight=sawg#artiq.coredevice.sawg.SAWG My minimal requirements are to be able to pick an arbitrary (within the SAWG BW) centre frequency, fc, and to be able to produce either a single tone or a pare of tones anywhere within, say, +-10MHz of that centre frequency without changing the DUC frequency f0. So long as the DUC size steps are small enough to allow this then I'm happy. Having said that, more flexibility is always useful, so I'd be keen to keep the f0 size steps as small as reasonably (without excessive complexity) possible. I don't understand the flexibility v complexity trade-offs well enough here to know what level of flexibility would be best to shoot for. > * What width is really needed for the FTW on f1/f2? Less than 32-bits (0.2Hz for 1GSPS) is problematic. A few more bits would be nice, but can be traded off against gateware complexity. > * 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. Remind me, does the CORDIC width affect broad-band noise, or just spur level? If it's just spurs then I'm probably not too concerned so long as it doesn't degrade the SFDR -- although, I'd need to look at where the spurs are to be confident in that. The other potential issue I can see is AM/PM when this is combined with an amplitude/phase servo. I'd need to simulate this to know how bad that would actually be, but I wouldn't want to degrade the system's broad-band noise performance if we can avoid it. Tom 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 <artiq-boun...@lists.m-labs.hk> on behalf of artiq-requ...@lists.m-labs.hk <artiq-requ...@lists.m-labs.hk> Sent: 18 July 2018 08:29:32 To: artiq@lists.m-labs.hk Subject: ARTIQ Digest, Vol 50, Issue 7 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 ARTIQ Info Page - serverraum.org<https://ssl.serverraum.org/lists/listinfo/artiq> ssl.serverraum.org To see the collection of prior postings to the list, visit the ARTIQ Archives.. Using ARTIQ: To post a message to all the list members, send email to artiq@lists.m-labs.hk. 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. Re: ARTIQ Digest, Vol 50, Issue 2 (Robert Jördens) 2. Re: ARTIQ Digest, Vol 50, Issue 2 (Slichter, Daniel H. (Fed)) 3. Re: ARTIQ Digest, Vol 50, Issue 2 (Robert Jördens) 4. Using ARTIQ from a different experiment control (jan.kie...@ptb.de) ---------------------------------------------------------------------- Message: 1 Date: Tue, 17 Jul 2018 15:40:23 +0200 From: Robert Jördens <r...@m-labs.hk> Cc: artiq@lists.m-labs.hk Subject: Re: [ARTIQ] ARTIQ Digest, Vol 50, Issue 2 Message-ID: <CANb+zoHTJMHEtWoG3R8mBo-h=cagik8h9jdhh_jumbbq7c7...@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" On Fri, Jul 13, 2018 at 6:06 PM Slichter, Daniel H. (Fed) via ARTIQ <artiq@lists.m-labs.hk> 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. ------------------------------ Message: 2 Date: Tue, 17 Jul 2018 15:51:53 +0000 From: "Slichter, Daniel H. (Fed)" <daniel.slich...@nist.gov> To: "artiq@lists.m-labs.hk" <artiq@lists.m-labs.hk> Subject: Re: [ARTIQ] ARTIQ Digest, Vol 50, Issue 2 Message-ID: <sn1pr09mb0847646a6f9ece99da568b5d91...@sn1pr09mb0847.namprd09.prod.outlook.com> Content-Type: text/plain; charset="utf-8" > 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 ------------------------------ Message: 3 Date: Tue, 17 Jul 2018 18:44:12 +0200 From: Robert Jördens <r...@m-labs.hk> Cc: artiq@lists.m-labs.hk Subject: Re: [ARTIQ] ARTIQ Digest, Vol 50, Issue 2 Message-ID: <canb+zogr4dwmxmzjzzyyooe0nyxt3-eoyqgou0ii0vq6mzb...@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" On Tue, Jul 17, 2018 at 5:52 PM Slichter, Daniel H. (Fed) via ARTIQ <artiq@lists.m-labs.hk> 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 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. There are a couple user-visible differences that need to be considered and signed off: * Since you now can't place the carrier freely anymore, we need requirements on carrier (DC) leakage and IQ imbalance. AFAICT those can be low since it is all digital. But there are rounding errors and it's not a given that they are small. * With only a "coarse" carrier, to move the two tones, you now have to move each individually with two RTIO commands. Currently you can just nudge the carrier. The users and funders need to sign off the changes, the plan, and the specs. And if resources become scarce on Sayma, we should first look at who is using how much. IIRC last I checked a few months ago on Kasli the DMA engine, the analyzer, and the SED network are the largest users, in that order. On Sayma it might be different but it is not clear a priori that SAWG is driving that as a dominantly "additive" resource consumer. Robert. ------------------------------ Message: 4 Date: Wed, 18 Jul 2018 09:28:22 +0200 From: jan.kie...@ptb.de To: artiq@lists.m-labs.hk Subject: [ARTIQ] Using ARTIQ from a different experiment control Message-ID: <of86aa748f.f4271bfe-onc12582ce.00283de8-c12582ce.00290...@ptb.de> Content-Type: text/plain; charset="iso-8859-1" Hi to all, Robert asked me to share a short explanation on how we (*) use ARTIQ from another experiment control software. If you are interested, please have a look at the attached pdf. If you have questions about this, please to sent me an email. Cheers, Jan P.S.: (*) "We" being the Mehlstäubler group at PTB, Germany, working on a Multi-Ion Clock. ****************** Jan Kiethe Physikalisch-Technische Bundesanstalt QUEST Institute Email: jan.kie...@ptb.de -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://ssl.serverraum.org/lists-archive/artiq/attachments/20180718/a9d6ed31/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: Using_artiq_from_another_experiment_control.pdf Type: application/octet-stream Size: 197028 bytes Desc: not available URL: <http://ssl.serverraum.org/lists-archive/artiq/attachments/20180718/a9d6ed31/attachment.obj> ------------------------------ Subject: Digest Footer _______________________________________________ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq ------------------------------ End of ARTIQ Digest, Vol 50, Issue 7 ************************************
_______________________________________________ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
