> 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.


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 
design.


> 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 
consumption/timing closure?

- 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
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

Reply via email to