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

[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 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

[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) 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

[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 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

[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 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

[Srinivas, Raghavendra (IntlAssoc)]

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

[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 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

[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 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

[Srinivas, Raghavendra (IntlAssoc)]

>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

[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 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

[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 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

[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), 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

[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 durations starting at
zero.

Jonathan
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

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

[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 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

[ARTIQ] [RFC] remove output event replacement feature

[Robert Jördens]

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