Re: [ARTIQ] [RFC] remove output event replacement feature
On Thursday, November 24, 2016 06:24 PM, Robert Jördens wrote: How do you want to do the replacement? Optimizing the sequence in advance in CPU/runtime would be channel-dependent and mode-dependent special casing. Doing so in gateware before it enters the DMA buffer would require gateware there that depends on channel features on remote DRTIO devices. All software, and yes there would be some channel-based special cases. I don't see advantages to writing DMA buffers in gateware, only inconvenience. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] [RFC] remove output event replacement feature
On Thu, Nov 24, 2016 at 2:55 AM, Sébastien Bourdeauducqwrote: > Well there is nothing unmanageable there. Sure. Unmanageable it is not. > * If we keep your "reset address CSR on timestamp modification" feature, > those writes that always have address zero (e.g. set TTL level) can use a > different syscall that ignores the address and saves the associated CPU > overhead. Yes. The downsides are maintainability, readability and code size. > * In DRTIO packets, the address field can be transmitted in a handful of > nanoseconds. But another -- let's say -- 16 bits fixed length address field is a significant overhead in DMA and DRTIO for small packets. > * For replacements in DRTIO, we can just do it on the remote side. The > inefficiency of sending multiple packets is fine as the throughput will be > limited by the CPU anyway. For DMA, we can optimize the sequences in advance > to remove internal replacements. How do you want to do the replacement? Optimizing the sequence in advance in CPU/runtime would be channel-dependent and mode-dependent special casing. Doing so in gateware before it enters the DMA buffer would require gateware there that depends on channel features on remote DRTIO devices. What one could do is add another bit that marks an event as replaceable. Then the gateware could be agnostic. > * The remote side also has a synchronous FIFO which is easier to handle than > the asynchronous FIFO of local RTIO. -- Robert Jördens. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] [RFC] remove output event replacement feature
On Thu, Nov 24, 2016 at 12:10 AM, Srinivas, Raghavendra (IntlAssoc)wrote: > Just out of curiosity, ttl.pulse(t) is essentially, > > ttl.on() > delay(t) > ttl.off() > > How would ttl.pulse_off(t) be different from > > ttl.off() > delay(t) > ttl.on() > > to avoid the problem when t=0 that back to back pulses have? As explained earlier, they would be if t: ttl.on() delay(t) ttl.off() and if t: ttl.off() delay(t) ttl.on() respectively. And as you can see, the behavior with zero-length pulses is surprising. You would expect a zero-length pulse to "do nothing". But it does: ttl.on() ttl.pulse(0) is not the same as ttl.on() In fact and maybe surprising it is equivalent to the same as the exact opposite, namely: ttl.off() Furthermore, and as explained earlier as well, it is confusing because you can always do both: ttl.pulse(0) and ttl.pulse(10*ns) though they have very different results. But sometimes you can't do: ttl.pulse(5*ns) That raises an exception depending on the exact fine timestamp. -- Robert Jördens. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] [RFC] remove output event replacement feature
On Thursday, November 24, 2016 04:54 AM, Srinivas, Raghavendra (IntlAssoc) wrote: 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. Well there is nothing unmanageable there. * If we keep your "reset address CSR on timestamp modification" feature, those writes that always have address zero (e.g. set TTL level) can use a different syscall that ignores the address and saves the associated CPU overhead. * In DRTIO packets, the address field can be transmitted in a handful of nanoseconds. * For replacements in DRTIO, we can just do it on the remote side. The inefficiency of sending multiple packets is fine as the throughput will be limited by the CPU anyway. For DMA, we can optimize the sequences in advance to remove internal replacements. * The remote side also has a synchronous FIFO which is easier to handle than the asynchronous FIFO of local RTIO. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] [RFC] remove output event replacement feature
Just out of curiosity, ttl.pulse(t) is essentially, ttl.on() delay(t) ttl.off() How would ttl.pulse_off(t) be different from ttl.off() delay(t) ttl.on() to avoid the problem when t=0 that back to back pulses have? Sincerely, Raghu -Original Message- From: Robert Jördens [mailto:r...@m-labs.hk] Sent: Wednesday, November 23, 2016 3:01 PM To: Srinivas, Raghavendra (IntlAssoc) <raghavendra.srini...@nist.gov> Cc: artiq@lists.m-labs.hk Subject: Re: [ARTIQ] [RFC] remove output event replacement feature On Wed, Nov 23, 2016 at 9:54 PM, Srinivas, Raghavendra (IntlAssoc) <raghavendra.srini...@nist.gov> wrote: >>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. ttl.on() delay(t_pi/2) ttl.pulse_off(t) delay(t_pi/2) ttl.off() would be a natural extension of the API. -- Robert Jördens. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] [RFC] remove output event replacement feature
> > 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. > > ttl.on() > delay(t_pi/2) > ttl.pulse_off(t) > delay(t_pi/2) > ttl.off() > > would be a natural extension of the API. If we're going to talk about "unaesthetic" code, I'd say this version is much worse than the three-line original code. From a logical standpoint, a Ramsey sequence consists of two rotations with a variable delay between them. While this 5-line code manages to create the desired sequence, it loses the logical flow that one has from reading code like the 3-line version -- much harder to tell from inspection that this is a Ramsey sequence. Is there another way to maintain or wrap the two back-to-back pulses so that you can accomplish your goals for DRTIO/DMA while not hurting the lexical clarity of the code on the physics level? Best, Daniel ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] [RFC] remove output event replacement feature
On Wed, Nov 23, 2016 at 9:54 PM, Srinivas, Raghavendra (IntlAssoc)wrote: >>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. ttl.on() delay(t_pi/2) ttl.pulse_off(t) delay(t_pi/2) ttl.off() would be a natural extension of the API. -- Robert Jördens. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] [RFC] remove output event replacement feature
>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
Re: [ARTIQ] [RFC] remove output event replacement feature
Good points; I understand the issue better now. I'm OK with removing this feature. Jonathan Mizrahi Research Scientist Joint Quantum Institute University of Maryland 301-314-1903 On Wed, Nov 23, 2016 at 3:29 PM, Robert Jördenswrote: > On Wed, Nov 23, 2016 at 9:16 PM, Jonathan Mizrahi > wrote: > >> leads to overhead and is unergonomic/unaesthetic. > > > > Can you clarify how you find this unaesthetic? From the perspective of an > > ARTIQ user, having to check for zero pulse lengths everywhere seems to > > create far more unaesthetic programs. > > You would obviously not do that every time but inside the pulse() method. > > The implementation is unaesthetic. And the behavior is not all that > obvious and intuitive: close-together events do raise a collision > while actual coincident events sometimes do not (depending on the > channel and on the event). > > > I also second Daniel's point -- we often scan pulse durations starting at > > zero. > > Zero length pulses can be worked around. Do you rely on being able to do > this: > > ttl.pulse(1*us) > ttl.pulse(1*us) > > Also, for some perspective, nobody seems to want to set the frequency > of a DDS twice at the same time. > > -- > Robert Jördens. > ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] [RFC] remove output event replacement feature
On Wed, Nov 23, 2016 at 9:16 PM, Jonathan Mizrahiwrote: >> leads to overhead and is unergonomic/unaesthetic. > > Can you clarify how you find this unaesthetic? From the perspective of an > ARTIQ user, having to check for zero pulse lengths everywhere seems to > create far more unaesthetic programs. You would obviously not do that every time but inside the pulse() method. The implementation is unaesthetic. And the behavior is not all that obvious and intuitive: close-together events do raise a collision while actual coincident events sometimes do not (depending on the channel and on the event). > I also second Daniel's point -- we often scan pulse durations starting at > zero. Zero length pulses can be worked around. Do you rely on being able to do this: ttl.pulse(1*us) ttl.pulse(1*us) Also, for some perspective, nobody seems to want to set the frequency of a DDS twice at the same time. -- Robert Jördens. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] [RFC] remove output event replacement feature
On Wed, Nov 23, 2016 at 8:06 PM, Slichter, Daniel H. (Fed)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
Re: [ARTIQ] [RFC] remove output event replacement feature
> > leads to overhead and is unergonomic/unaesthetic. > Can you clarify how you find this unaesthetic? From the perspective of an ARTIQ user, having to check for zero pulse lengths everywhere seems to create far more unaesthetic programs. I also second Daniel's point -- we often scan pulse durations starting at zero. Jonathan ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] [RFC] remove output event replacement feature
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. 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. What is the DRTIO/DMA requirement that makes this functionality problematic? Can you explain the rationale a bit? Best, Daniel > -Original Message- > From: ARTIQ [mailto:artiq-boun...@lists.m-labs.hk] On Behalf Of Robert > Jördens > Sent: Wednesday, November 23, 2016 10:20 AM > To: artiq@lists.m-labs.hk > Subject: [ARTIQ] [RFC] remove output event replacement feature > > Hello ARTIQ users, > > in preparation for DRTIO and DMA we are considering dropping a small > feature that -- while being potentially "convenient" to the user -- leads to > overhead and is unergonomic/unaesthetic. > > Currently, we support submitting multiple output events scheduled for the > same timestamp under certain conditions. That means you can turn a TTL > channel on() and off() in the same cycle. The prior on() is be replaced by the > off(). This happens transparently in gateware. It allows e.g. zero-length > pulses or back-to-back pulses to behave properly. They would otherwise > result in RTIOCollision exceptions. > > We are uncertain to what extent this feature is actually know and > used/relied upon in practice. > > Any comments on removing this feature and making it *always* an > RTIOCollision exception when two events are scheduled for the same > timestamp on the same channel? > > -- > Robert Jördens. > ___ > ARTIQ mailing list > https://ssl.serverraum.org/lists/listinfo/artiq ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq