> 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
Thanks for clarifying that.
Okay, so it really is the case that with the current design getting the 1GSPS
data rate, 8-channel SAWG to fit on the FPGA is going to be marginal at best.
It's not even just an issue that multi-hour compile times make debugging
anything a nightmare. In that case, there clearly is a need to simplify the
> The users who asked for that need to engage and answer that question. I can
> only point to the issues on our radar.
Thanks. So, we have:
- Moninj: Chris B/David N will be able to give a better-informed view on this
than me, but my feeling is that moninj isn't actually that useful for the SAWG.
What would SAWG moninj include? Leaving aside the work/funding required to
implement sawg moninj, is it likely to be a problem in terms of resource
- Analyzer: again, Chris B/David N are probably the people to answer this, but
it seems useful to have this
- External modulation (#801): I'm not sure I fully understand what this
proposal is. Can you give some details about what this would do and why it
would be needed, please?
As mentioned before, the one bell/whistle that I am keen on is an AM input to
the SAWG for a noise eater along the lines of SU-servo. Comments:
- no need for more than 1MSPS modulation bandwidth, since IIRC the DAC/JESD
latency alone limits us to something like 300kHz loop bandwidth
- I'd be happy with only being able to modulate the common-mode amplitude for
the two SAWG tones if that's easier, don't need to be able to modulate the
amplitude of the individual tones
- FM/PM might also be useful to some users, I guess, but I can't think of a
concrete use-case in our lab. Unless anyone specifically want's that, I'd argue
we can leave it out. In most cases, it will be easier to do things like fibre
phase noise cancellation with a separate AOM that runs CW using a FM version of
the Urukul-Sampler servo.
> However, among the features is one thing that I think is very important for
> us (but all can be debated at this stage),
> namely having the envelope for the upconverted sine waves update at the full
> 1 GSPS update rate. This is relevant for
> both the Oxford fast laser gate and the magtrap, where we want to be able to
> do pulse shaping on rise/fall times in the ~5-15 ns range.
If this is okay from a resource/complexity point of view then obviously I don't
object to it, but I'd put that pretty low down my priorities list. For now, I'm
keen to find the easiest way of getting the SAWG working at the full 1GSPS data
rate, which is an obvious prerequisite to this anyway.
Beyond that though, it's not totally clear to me that this is a good use-case
for SAWG as opposed to good old fashioned AWG. Maybe I'm wrong here, but I
think of SAWG as a means of data compression when the modulation bandwidth is
low compared with the sample rate. Once you start modulating close to the
sample rate, it's not so clear to me that one wins by using a SAWG instead of
playing pulses back from ram via DMA (maybe through a multiplier to enable
noise eating). For such short pulses, the event rate you have will be large
compared with the sustained RTIO event rate, so you'll probably be using DMA
even if you do use SAWG.
Maybe you feel differently, but I'm not sure that the win from doing this via
SAWG instead of DMA/AWG is worth the increased complexity (unless it really is
small) from making the SAWG modulation bandwidth so high.
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
Subject: Re: ARTIQ Digest, Vol 50, Issue 9
On Thu, Aug 9, 2018 at 11:56 AM Thomas Harty
> 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.
ARTIQ mailing list