>Back-to-back pulses are troublesome. Is that being used actively? As Daniel mentioned, for Ramsey experiments when you're scanning the delay, when the delay is 0 you'd have two back to back pi/2 pulses. How would that need to be coded differently? Explicitly,
ttl.pulse(t_pi/2) delay(t) ttl.pulse(t_pi/2) and we scan t from 0 onwards. Sincerely, Raghu -----Original Message----- From: ARTIQ [mailto:artiq-boun...@lists.m-labs.hk] On Behalf Of Robert Jördens Sent: Wednesday, November 23, 2016 1:24 PM To: Slichter, Daniel H. (Fed) <daniel.slich...@nist.gov> Cc: artiq@lists.m-labs.hk Subject: Re: [ARTIQ] [RFC] remove output event replacement feature On Wed, Nov 23, 2016 at 8:06 PM, Slichter, Daniel H. (Fed) <daniel.slich...@nist.gov> wrote: > We definitely use zero-length pulses as a regular part of our experiments. > The most prominent example is scanning a pulse duration time (e.g. for Rabi > flopping, or delay between Ramsey pulses), where the first item in the list > of pulse durations to scan is a zero duration pulse (i.e. no Rabi flopping, > or no delay between Ramsey pulses). The proposed modification would break > all of these experiments, and require the experiment code to have internal > conditional/branching to check for zero-duration pulses everywhere that we're > scanning pulse times and have a different branch to deal with these instances. Zero length pulse() can be resolved trivially at runtime. The impact looks negligible. And if you use those, you actually risk collisions already because we raise them when you submit events that are closer than a coarse RTIO cycle. We only suppress them when they conincide. Back-to-back pulses are troublesome. Is that being used actively? > The behavior of automatically collapsing zero-duration pulses simplifies the > experimental code substantially. One potentially acceptable compromise might > be to delegate the task of finding and eliminating zero-duration pulses to > the compiler. This could then address the situation above (where > zero-duration pulses are known at compile time), but would leave people to > fend for themselves if pulse durations are calculated at runtime (or are > otherwise unknowable at compile time). Peter should probably comment on the > feasibility of such a scheme, and in any event I am not sure that everyone > would be satisfied with that. That's not a good idea and wouldn't work: the pulse length can in general not be determined at compile time. > What is the DRTIO/DMA requirement that makes this functionality problematic? > Can you explain the rationale a bit? Replacing is very channel dependent. It can only happen on certain data and certain state of the channel. Not generally. It needs to be fine tuned for each channel. And it needs to happen at the input side of the RTIO FIFO. In DRTIO we can't have such channel dependent gateware close to the kernel CPU. Whether a channel supports replacing is done by adding to the RTIO CSR API a logical "address" that discriminates replaceable "register data". That additional address field directly impacts and increases the amount of data that is written on each RTIO event submission. We expect a significant speed up in event rate by removing it. It also bloats DRTIO packets. -- Robert Jördens. _______________________________________________ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq _______________________________________________ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
