qilimanjaro-tech / qililab

Qililab is a generic and scalable quantum control library used for fast characterization and calibration of quantum chips. Qililab also offers the ability to execute high-level quantum algorithms with your quantum hardware.
Apache License 2.0
30 stars 2 forks source link

[QHC-238] Quick fix to qprogram multiple bus acquisitions #691

Closed visagim closed 6 months ago

visagim commented 6 months ago

Temporary fix, assumes 2 things:

linear[bot] commented 6 months ago

QHC-238 [BUG] Fix QProgram QRM bus acquisitions

codecov[bot] commented 6 months ago

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 96.16%. Comparing base (83316aa) to head (4f46836).

Additional details and impacted files ```diff @@ Coverage Diff @@ ## main #691 +/- ## ======================================= Coverage 96.16% 96.16% ======================================= Files 273 273 Lines 9043 9043 ======================================= Hits 8696 8696 Misses 347 347 ``` | [Flag](https://app.codecov.io/gh/qilimanjaro-tech/qililab/pull/691/flags?src=pr&el=flags&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=qilimanjaro-tech) | Coverage Δ | | |---|---|---| | [unittests](https://app.codecov.io/gh/qilimanjaro-tech/qililab/pull/691/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=qilimanjaro-tech) | `96.16% <100.00%> (ø)` | | Flags with carried forward coverage won't be shown. [Click here](https://docs.codecov.io/docs/carryforward-flags?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=qilimanjaro-tech#carryforward-flags-in-the-pull-request-comment) to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

fedonman commented 6 months ago

Sorry to ask this after having the implementation, but could we consider a more clean approach, so we don't need to have assumptions about namings? There is an easy and quick solution that should work with any bus/acquisition name:

If we add a port parameter in the get_qprogram_acquisitions() method of ReadoutSystemControl we can move the information of the specific sequencer to acquire from down to the instrument. In the same way we do in the upload() method:

# Bus calls the system control with port=self.port
self.system_control.upload_qpysequence(qpysequence=qpysequence, port=self.port)

# SystemControl passes the port to the instrument method
def upload_qpysequence(self, qpysequence: QpySequence, port: str):
        """Uploads the qpysequence into the instrument."""
        for instrument in self.instruments:
            if isinstance(instrument, AWG):
                instrument.upload_qpysequence(qpysequence=qpysequence, port=port)
                return

        raise AttributeError("The system control doesn't have any AWG to upload a qpysequence.")

# QbloxModule finds the correct sequencer using the port
def upload_qpysequence(self, qpysequence: QpySequence, port: str):
        sequencers = self.get_sequencers_from_chip_port_id(chip_port_id=port)
        for sequencer in sequencers:
            ...

I am asking this, because I think it's super easy to implement. If you think it will complicate things we can move on with the current one. I just want to avoid having restrictions in namings. Because many examples and demos just use a drive_bus / readout_bus.