> 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
