Runcard Structure

[fedonman]

This is a proposal for the structure of the runcard. Currently, we use one runcard file for describing our platform. This has some disadvantages:

• The file gets huge quickly making it very difficult to maintain
• There is no rule for the qubits/resonators/ports indexes
• The chip and bus settings are coupled, meaning if you want to remove/add a bus you have to also change the chip settings
• Since there is no modularity it is very difficult to write tests for individual components

My thought is to split the runcard to (at least) three different files:

• chip.yml: The chip file should reflect the actual chip design and should be created once for each chip we use and shouldn't be edited again. For soprano there would be a file chips/soprano.yml. All qubits/resonators/ports indexes should be exactly as described in chip's diagram provided by the manufacturer.
• lab.yml: As the name suggests, this reflects the current lab setup. It defines the instruments and the buses.
• settings.yml This contains the operational settings of the setup. For example, delay_between_pulses, gates etc.

Each file should correspond to a class in Qililab. Currently, we have implementations for the chip.yml (Chip class), and the settings.yml (PlatformSettings class) and we should create a Lab class.

The Lab class should contain useful methods and properties like get_instruments_of_bus(index: int) etc, but it shouldn't concern itself about the Chip: It doesn't mater if you have a chip of N qubits but you have a lab setup connected to only one of it. (now this throws an error as mentioned above)

Finally, the Platform class, now constructed with something like platform = Platform(chip=chip, lab=lab, settings=settings) is responsible to figure out the connectivity. For example, it would provide methods like is_port_connected(index:int) or get_control_bus_for_qubit(qubit_index: int) etc.

[AlbertMitjans]

Thank you for the idea! 🙌

I agree that we should split the runcard for better readability!

In the long run I'd love to show all the runcard information in the website, such that the HW users can forget about using these long YAML files.

[AlbertMitjans]

Regarding the Lab class. Why not using Platform directly to get information about the buses? Currently the Platform class is the representation of the lab.

[AlbertMitjans]

In the beginning (right now it is not the case) the platform contained:

• chip: information about the chip
• instruments: information about the instruments
• buses: connectivity information

[AlbertMitjans]

I would separate the runcard into these 3 elements, and adding a 4th element containing the current PlatformSettings, which these are actually the transpiler settings.

[AlbertMitjans]

Most importantly, I would separate buses from instruments. This way a HW user can easily change the connectivity of the platform without touching the instruments.

[AlbertMitjans]

FYI this is related to #248

[fabiques]

I agree 100% with this idea. I just want to give a different perspective.

I wouldn't conceptualise it as a chip runcard, but rather as a calibration file. Any parameter that can be calibrated could go on this file, every gate parameter, crosstalk information, line distortions etc... (Note that this is not necessarily specific to the chip.)

We can then have methods to create/update these calibration files. For example the position of the sweet spots (in voltage) can change between cooldowns, a method to automatically measure it and update it would be great. If we swap a filter on a line, just recalibrate the distortion and update the calibration file, etc...

Also, It is imperative that qililab works (at least for spectroscopy) without a calibration file. It doesn't make sense to require calibration before calibrating.

[AlbertMitjans]

Thank you @fabiques!! Your comments are incredibly appreciated ❤️

This was the original goal of the runcard, but it has clearly deviated a lot...

It is imperative that qililab works (at least for spectroscopy) without a calibration file

I have this in mind, and it will soon be one of the team's goal for this quarter. I will soon share the plan to get your feedback!

[fabiques]

@fedonman, @AlbertMitjans how does qililab use (or plan to use) the chip schema information? It is not clear to me how it is useful.

[fabiques]

Good point. but if you send it via the drive_line you need to define two signals, I and Q, or define what port you are sending it thru

[AlbertMitjans]

Mmm regarding drive lines, I prefer to keep it generic (like the Square and ArbitraryPulse examples you showed above). Also (from a UX point of view) I'd prefer defining a complex signal (where the real part corresponds to I and the imaginary to Q) rather than defining two signals.

For example, in the ArbitraryPulse you could do: ql.ArbitraryPulse(I + iQ)

Where I and Q are arrays

[fabiques]

A drive line has 2 outputs, you need to be clear what you send where. I really dislike the complex number idea, we never contextualise it like that and it is not intuitive what it is doing.

[AlbertMitjans]

We've always done it like this in Quantum Spain... why isn't it intuitive? I thought that I and Q corresponded to the real/imaginary part of the waveform

[fabiques]

I and Q are the "in phase" and "quadrature" parts of an up-converted signal. The mixers do the mixing

$$S(t) = I(t)\cos(\omega_{LO} t) + Q(t)\sin(\omega_{LO} t)$$

Note the similarity to Euler's formula. I(t) and Q(t) are the outputs of the awg's and S(t) at the output of the mixer.

For heterodyne mixing (which we use) I(t) and Q(t) are themselves oscillators.

$$I(t) = I_{envelope}(t)\cos(\omega_{IF}t)+Q_{envelope}(t)\sin(\omega_{IF}t)$$

and

$$Q(t) = -I_{envelope}(t)\sin(\omega_{IF}t)+Q_{envelope}(t)\cos(\omega_{IF}t)$$

After some trigonometry, we get at the output of the mixers:

$$ S(t) = I_{envelope}(t)\cos\left[(\omega_{LO}+\omega_{IF}) t\right] + Q_{envelope}(t)\sin\left[(\omega_{LO}+\omega_{IF}) t\right] $$

Typically we give $I_{envelope}$ and $Q_{envelope}$ to the QCM and it creates $I(t)$ and $Q(t)$ digitally in the fpga. That is what hardware modulation is. Alternatively we can create $I(t)$ and $Q(t)$ in qililab and send it to the output of the fpga (software modulation).

Actual answer:

All this to wrap my head around what it means to send an arbitrary pulse in a drive line.

So you should be able to send whatever you want in this line, the behaviour will be very different depending if hardware modulation is on or off.

If it is arbitrary I would prefer it to go to the most physical description, voltages on an output, in which case it doesn't make sense to use the complex number.

[fabiques]

I wrote down what I think the calibration file could look like. This is just a schetch and for sure there are practicalities I'm not accounting for

qubits:
  0:
    frequency: 4.92e+09
    offset: -0.78 
    measurement:
      frequency: 7.734e+09
      amplitude: 0.12
      duration: 2000
      weighed_acq_enabled: false
      weights_i: [1., 1., 1., 1., 1.]
      weights_q: [1., 1., 1., 1., 1.]
      threshold: -0.0013194
      # All other parameters I cant remember
    gates:
      - name: Drag
        amplitude: 0.076
        duration: 20
        shape:
          name: drag
          num_sigmas: 4
          drag_coefficient: 0.1
  # similar structure for other qubits

two_qubit_gates:
  (0,2):
    - name: CZ
      amplitude: 0.34
      duration: 52
      shape:
        name: rectangular
      park:
        qubit: 1
        amplitude: 0.01
        safety_time: 16

bus_calibration:
  - bus: flux_q0
    time_of_flight: 0.04
    distortions:
      - name: lfilter
        a: [1.0526315789473684, 0, 0, 0, 0, 0, 0, 0, 0, -0.05263157894736836]
        b: [1.]
        norm_factor: 1.

  - bus: drive_q0
    time_of_flight: 0.04
    mixer:
      gain_imbalance: [0.1]
      pahse_imbalance: [0.02]
      offset_i: 0.01
      offset_q: -0.02

  - bus: readout
    mixer:
      gain_imbalance: [0.1, 0.02, 0.04, 0.05] # this could depend on IF
      pahse_imbalance: [0.1, 0.02, 0.04, 0.05]
      offset_i: 0.01
      offset_q: 0.02

crosstalk:
  buses: [flux_q0,flux_q1,flux_q2]
  matrix: [[1, 0.1, 0.05],[-0.1,1.0,0.01],[0.1, 0.1, 1.]]

[fedonman]

It would be very useful to have a educational session between HW-SW, so you can explain what each calibration does and what it depends upon. Personally I am very interested to know more, and many of these are unknown to me.

[fabiques]

That is a great idea. Hopefully @rsagas has time/will to do it, as he knows a lot more about this than me. Otherwise, either me or @paulqili could do it.

[AlbertMitjans]

Definitely! This is something I've been discussing with @rsagas for a couple of weeks now.

[fabiques]

In my head buses are meant to contain the logic of how multiple instruments connect together to make a signal. For example, microwave pulses require an awg and an LO while flux lines (sometimes) need an awg and a DC current/voltage source.

With this in mind, here is an example of how I think buses should be defined in the run card:

buses:
  - category: readout_bus
    qubits: [0,1,2,4]
    alias: readout
    awg:
      name: QRM1
      outputs: [0,1]
    digitizer:
      name: QRM1
      inputs: [2,3]
    LO: 
      name: rs_1
      frequency: 7.904e+09
    attenuator: 
      name: attenuator
      attenuation: 37
    
  - category: drive_bus
    qubit: 0
    alias: drive_q0
    awg:
      name: QCM1
      output: [0,1]
    LO: 
      name: rs_2
      frequency: 7.904e+09
    
  - category: flux_bus
    alias: flux_q0
    qubit: 0
    awg:
      name: QCM2
      output: 0
    source:
      name: s4g
      output: 0

[AlbertMitjans]

Thank you for sharing this! This is something I've been wanting to know for a while now. Are these all the types of buses that exist currently? Will you ever use any other type of instrument in a bus (the VNA, for example?).

[fabiques]

We need to discuss this.

The goal of qililab is to simplify complicated systems. So that as we add more and more qubits, we can still keep track, calibrate and control all of them. Scalability is the most important thing.

The VNA only has 2 ports and costs 10s of thousands of euros, we will never use it for scaling. Writing qililab thinking about it does not sound reasonable.

Having said that. There are tools (some not implemented yet) in qililab that are useful when using the VNA. These are, data saving, live plotting, parameter instantiation with the runcard, relation to other devices etc... We will find a way to use these with the VNA without designing qililab to accommodate the VNA.

To answer your question, there should not be a bus for the VNA. And qililab should be limited only to these 3 kinds of buses, readout, drive and flux.

[AlbertMitjans]

Glad to hear this!

[AlbertMitjans]

I'm a bit confused with the flux_bus having an AWG and a current source... shouldn't it have only one or the other?

[fabiques]

We are using the awg to set the threshold. Sometimes the awg cannot output a current/voltage high enough to set it, so we need a separate current source, like the yokogawa or the s4g. Also, and probably more importantly, setting the threshold with the awg adds noise, since it is not a stable current source.

The mixing of the two signals (awg and current source) is done using a bias t. Sometimes at room temperature but preferably in the cold.