> The coarse f0 DUC (as per the proposal) would be tens of multipliers
> instead of eight CORDICs+accumulators. We'd need an exploratory
> project to get hard numbers for the resource trade of.
I think a short exploratory project would be a good idea, as I have no real
means of making an informed decision about where to shoot for on the
performance/flexibility v complexity scale. 8 CORDICS + accumulators on 8
channels sounds like a lot, but it's a big FPGA and IIRC we're not really
pushing the resources limits yet (but maybe I'm wrong about that?), so it's not
clear that's actually a problem. I get that multi-hour compile times are death,
but at least we haven't seen any Sayma bugs that depend on whether the Sawg is
enabled or not for quite a while (since we fixed the power supplies). So, maybe
it's not actually such an issue if the majority of Sawg testing can be done in
simulation, and any non-SAWG issues on Sayma can be debugging in non-SAWG
builds?
>>> * 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
>
> Yes.
I'm not overly fussed about this, but the current parametrization seems more
logical for the things I have in mind. Do you have a reason to prefer one over
the other?
>> 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.
>
> The proposal is to have the f0 DUC at 125 MHz or 62.5 MHz granularity
> and do move the remaining center frequency offset into f1/f2
What level do you want to have this discussion on? A "high-level" specification
of user requirements/expectations, or a lower-level discussion about the
implementation? The above was a first attempt at the former. If it seems
ambiguous/unclear/misguided then let me know.
In terms of the proposed implementation: am I right in thinking that the
frequency range one can produce is approximately f0 +- f_rtio/2, less a bit due
to due to digital anti-aliasing filters etc? If so, am I right in thinking that
having f0 quantized in steps of f_rtio (125MHz) leads to bands around (n +
1/2)*f_rtio which are inaccessible? Moreover, scanning from slightly below (n +
1/2)*f_rtio to slightly above it requires a step in f0, which is quite
inconvenient. If so, that choice of quantization for f0 seems problematic.
AFAICT, quantizing f0 in steps of f_rito/2 removes this problem, since the
ranges now overlap (i.e. this choice does meet my "high-level" specification
above). However, some frequency ranges can only be produced with one choice of
f0. So, that doesn't give the user any ability to shift spurs around to avoid
hitting an atomic transition. That could also be problematic, depending on how
large the spurs are -- it will be particularly problematic for output
frequencies where the baseband oscillators are running close to DC.
So, making the quantization of f0 fine enough that users have at least some
ability to shift spurs around/avoid running the baseband oscillators close to
DC seems like a good idea. AFAICT, f_rtio/4 is probably fine enough. As always,
"better is better" so it would be good to know how much harder it is to
increase the resolution in f0 beyond this.
>>> * 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.
>
> One eighth of that. f1/f2 would run at 125 MHz.
ACK. Well, personally, I'd stick with the claim that less than about 0.1Hz is
likely to be problematic. mHz resolution is potentially nice, but a far lower
priority for me than having this thing work reliably at a GSPS data rate. My
guess is that all the use-cases that require ultra-fine frequency control can
probably be best served with Urukul-AD9912.
Would be good to hear from others on this point though.
> Both in different ways through different "width" paramters. What broad
> band phase noise is required?
That also needs an exploratory project -- list all the experiments we want to
do and do the simulations for how PM/AM hurts us. I don't think I can give you
a good answer on this at the moment. Sorry.
Aiming to not degrade the DAC's noise floor (which isn't that low in the scheme
of things) "significantly" (6dB?) seems like a good starting point however.
Again, we can probably relax this specification if there is a really good
reason to. But, I think we would need to
