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:[email protected]] On Behalf Of Robert > Jördens > Sent: Wednesday, November 23, 2016 10:20 AM > To: [email protected] > 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
