Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reconsider delay accumulation convention #114

Open
grahamrow opened this issue Jul 28, 2017 · 3 comments
Open

Reconsider delay accumulation convention #114

grahamrow opened this issue Jul 28, 2017 · 3 comments
Assignees

Comments

@grahamrow
Copy link
Member

Right now QGL automatically offsets pulses by the minimum delay to avoid negative delays. This is awkward across multiple APS slices if you want to delay a slave trigger, since it automatically pushes quadrature channel pulses off into the future, thereby canceling the intention. What should we do?

@blakejohnson
Copy link
Collaborator

Yes, I have been bitten by that oddness before with the slave trigger. But, this isn't a simple matter of "avoiding" negative delays. What does it even mean for a master AWG channel to have a negative delay, given that the AWG output is triggered?

@gribeill
Copy link
Contributor

gribeill commented Aug 7, 2017

Possible solutions, off the top of my head:

  1. Channel timing is preserved across AWGs, with all delays relative to 0 delay on the master AWG.
  2. Channel timing is preserved across AWGs, with all delays relative to the leftmost channel or marker on the master AWG
  3. Channel timing is preserved across AWGs, with all delays relative to the first pulse in the whole sequence.
  4. Channel delays only refer to a specific AWG, with negative delays being an error. t=0 for each AWG happens when it receives its trigger.
  5. Channel delays only refer to a specific AWG, with negative delays being an error for the master AWG and delays for the slaves relative to the tx_channels on that AWG.
  6. What we are doing now, where delays move pulses left or right in time.

I think 2, 3, and 5 are clearly bad ideas, since they require the user to infer too much state when setting up delays. 1 is misleading, since it mixes "logical" delays that the user wants between pulses and "physical" delays between pulses due to cabling, etc... I might have missed something but I think (4) would be my preferred solution -- although I suspect this would require some additional cleverness from the QGL compiler...

@blakejohnson
Copy link
Collaborator

It is somewhat of a hack, but I think you would also get sane behavior if the slave trigger channel were really forced to have delay = 0, i.e. the slave trigger output would be invariant under changes to any other channel delay. This would allow, for example, putting negative delays on slave AWGs and have The Right Thing Happen™.

This would also imply that negative delays on the master AWG would be an error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants