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
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)
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
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
...@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
> > 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
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
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
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
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
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),
>
> 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
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
13 matches
Mail list logo