> All correct, except the last bit: the digital equivalent of DC/LO > leakage is less than one LSB. There will be a spur but it's well controlled.
Remind me, for the current design, what's a 1 LSB spur in dBc? How does that scale with the width parameters? > How low do the other spurs have to be? They can also be controlled somewhat. Generally, I'd argue that it's probably okay to think of this in terms of off-resonant excitation amplitude for a narrow-linewidth transition. So, the tolerable spur amplitude scales with the distance from the nearest atomic transition, which depends on the experiment. We're more sensitive if the spur offset is in the 100kHz - 10MHz range that motional modes lie in, due to Lamb-Dicke parameters. > And regarding the benefit I don't see a reason why the spurs would > necessarily move or be guaranteed to change a lot by choosing the "band". Am I wrong in thinking that the frequency separation between the spurs and the RF tones depends on things like the frequency of the base-band oscillator? So, for the same RF output frequency, the spur offset frequency can be moved by changing the DUC frequency. At the very least, I'd expect a spur at the DUC frequency, which will shift as that frequency changes. What am I missing here? > Maybe f_rtio/4 is going to be quite a bit costlier than f_rtio/2 I can't see any reason to go finer than f_rtio/4. f_rtio/2 is probably okay, but we'd need to give it more thought. Would be interesting to see how much worse f_rtio/4 actually is in terms of FPGA resources etc. > The logic resources are a bit worse than O(n*log(n)) in each of the > bit width parameters. And the noise goes roughly as the well known 6dB > per bit. Thanks. Can you remind me what the noise situation is with the current parametrize? Am I right in thinking this just contributes white PM/AM? At what level in dBc/Hz? I'm a bit reluctant to let the SAWG degrade the DAC's noise floor by too much. So, I'd prefer to try to concentrate on other ways of simplifying the design. If we can achieve something satisfactory without degrading the noise, let's do that. If we can't then we can come back to this. 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: Robert Jördens <r...@m-labs.hk> Sent: 10 August 2018 18:11:33 To: Thomas Harty Cc: artiq@lists.m-labs.hk Subject: Re: ARTIQ Digest, Vol 50, Issue 9 On Thu, Aug 9, 2018 at 11:56 AM Thomas Harty <thomas.ha...@physics.ox.ac.uk> wrote: > Where are we in terms of resource usage with the current design? What's a > rough upper bound on how high we can push the resource utilization on an FPGA > for this kind of design before timing closure/compile times/etc becomes a > nightmare (50%? 75%?)? IIRC resource usage is around 50%-60% now. But have a look at any Vivado run. It gets increasingly hard anywhere between 70 and 90% depending on the routing. > What "bells and whistles" do you mean? Do you mean things like fancy > modulation/demodulation schemes for PDH locks etc? Let's have a bells and > whistles list and see what we can agree to cull. The users who asked for that need to engage and answer that question. I can only point to the issues on our radar. There is a more like servoing in the plans and proposals. https://github.com/m-labs/artiq/issues/675 https://github.com/m-labs/artiq/issues/801 https://github.com/m-labs/artiq/issues/651 https://github.com/m-labs/artiq/issues/688 Robert.
_______________________________________________ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
