Re: [ARTIQ] [RFC] remove output event replacement feature

2016-11-24 Thread Sébastien Bourdeauducq
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

Re: [ARTIQ] [RFC] remove output event replacement feature

2016-11-24 Thread Robert Jördens
On Thu, Nov 24, 2016 at 2:55 AM, Sébastien Bourdeauducq wrote: > 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)

Re: [ARTIQ] [RFC] remove output event replacement feature

2016-11-24 Thread Robert Jördens
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

Re: [ARTIQ] [RFC] remove output event replacement feature

2016-11-23 Thread Sébastien Bourdeauducq
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

Re: [ARTIQ] [RFC] remove output event replacement feature

2016-11-23 Thread Srinivas, Raghavendra (IntlAssoc)
...@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 (Int

Re: [ARTIQ] [RFC] remove output event replacement feature

2016-11-23 Thread Slichter, Daniel H. (Fed)
> > 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

Re: [ARTIQ] [RFC] remove output event replacement feature

2016-11-23 Thread Robert Jördens
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

Re: [ARTIQ] [RFC] remove output event replacement feature

2016-11-23 Thread Srinivas, Raghavendra (IntlAssoc)
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

Re: [ARTIQ] [RFC] remove output event replacement feature

2016-11-23 Thread Jonathan Mizrahi
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ördens wrote: > On Wed, Nov 23, 2016 at 9:16 PM, Jonathan

Re: [ARTIQ] [RFC] remove output event replacement feature

2016-11-23 Thread Robert Jördens
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

Re: [ARTIQ] [RFC] remove output event replacement feature

2016-11-23 Thread Robert Jördens
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),

Re: [ARTIQ] [RFC] remove output event replacement feature

2016-11-23 Thread Jonathan Mizrahi
> > 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

Re: [ARTIQ] [RFC] remove output event replacement feature

2016-11-23 Thread Slichter, Daniel H. (Fed)
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