Why is heterodyne mixing defined in the awg rather than the bus?

[fabiques]

In the current runcard structure, the parameters of the heterodyne mixing, like the intermediate frequency, are defined on the QRM/QCM instruments. Shouldn't this be dealt with by the buses? Isn't that what the buses are for?

An exemple:

    - name: QCM
      alias: QCM
      id_: 1
      category: awg
      firmware: 0.7.0
      num_sequencers: 2
      out_offsets: [0.0, 0.0, 0.0, 0.0] # [-0.25, -0.004, 0.0, 0.0]
      awg_sequencers:
        - identifier: 0
          chip_port_id: 12
          output_i: 0
          output_q: 1
          num_bins: 1
          intermediate_frequency: 10.e+06
          gain_i: 0.1
          gain_q: 0.1
          gain_imbalance: 0.940
          phase_imbalance: 14.482
          hardware_modulation: true
          sync_enabled: true
          offset_i: 0. # -0.012
          offset_q: 0.

[AlbertMitjans]

The Bus is just an invented class to define the connections between the instruments and the chip. These settings are directly related to the instrument.

I understand that moving all these parameters inside the Bus would make the runcard much easier to read. But again, the runcard is not supposed to be read...

One thing we want to do in the future is being able to see all the settings per bus using a simple call platform call (also maybe in the website?), but to do this we need to master the connectivity between buses/outputs/sequencers.

[fabiques]

These settings are not directly related to the instrument, the QCM is the perfect example, If you'r using a QCM to do 2 qubit gates or annealing schedules, it doesn't need an intermediate frequency.

[fabiques]

I talked with @rsagas today about this and he seems to agree, so I'm going to double down. The QCM/QRM as instruments, should not deal with the heterodyne mixing. This is exactly what buses are used for. QCM is nothing more than an AWG, accepting arrays and spiting them out. They should not as objects have an intermediate frequency attribute.

If I said something crazy, let me know @rsagas.

I think this is in the heart of how qililab should work, so I'm going to be a bit annoying, apologise in advance XD

[AlbertMitjans]

In annealing this is true, but in gate based the QCM spits out the input envelope at the given (intermediate) frequency (we are using the NCO of the QCM).

However, I'm not against moving this logic inside the bus 👍

[fabiques]

Can't we use the QCM for two qubit gates? They don't need an Intermediate frequency.

I assume NCO refers to the hardware modulation in the QCM. I think qililab should work in the most general way possible. An awg is a dumb machine which takes an array and spits it out, once we can do that, we can figure out how to implement hardware optimisations, like the use of hardware modulation.

If one day we switch to a "dumb" awg the code should work the same. In which case the logic should not be done by the machine but rather by qililab at the bus level.