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

Move drivers into separate projects #779

Open
3 tasks
terrorfisch opened this issue Aug 7, 2023 · 2 comments
Open
3 tasks

Move drivers into separate projects #779

terrorfisch opened this issue Aug 7, 2023 · 2 comments
Assignees

Comments

@terrorfisch
Copy link
Member

terrorfisch commented Aug 7, 2023

The goal is to make driver tinkering independent of each other and indepentend of the frontend.

Currently the driver code of each device lives in two places. A file _program contains the programming logic and a file in hardware/awgs contains the device communication.

The _program package and its contents are currently not considered a stable interface. We need to declare (parts of) Loop as stable for a somewhat independent driver implementation to make sense.

  • Create qupulse.program.loop (Simon)
  • Create the project qupulse-hdawg-idx for the playWaveIndexed based driver and move seqc.py and hdawg.py there
  • Create the project qupulse-hdawg-cmd for the command table based driver

Open questions:

  • Where should the projects be located? Gitlab? Here?
  • Should we avoid code duplication between the two projects? Here the plan is to duplicate everything to avoid conflicts and make workarounds for different firmware versions easier.

@Nomos11 @maxbeer99 What are your thoughts on this plan?

@Nomos11
Copy link
Collaborator

Nomos11 commented Aug 7, 2023

Regarding loop: I know too little about that to judge which parts can be deemed "stable" or not.
Regarding the questions:
The first version lives in Gitlab already and could possibly stay there for internal consumption until some issues have been discussed (?) (referring e.g. to reocurring upload issues out of our control and possible optimizations)
I would not have a strong aversion to code duplication; but workarounds have previously been made in separate branches for individual experimental setups anyway...

@Nomos11
Copy link
Collaborator

Nomos11 commented Jun 21, 2024

can this be closed?

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

3 participants