Breakout of the hardware model coupling across logical boundaries

[jfriel-oqc]

Problem overview

The current design and implementation of QAT is being stretched across use cases that it wasn't ready for and is causing pain points across its use. A particularly painful component of QAT is the hardware model. The hardware model crosses several logically distinct boundaries that should be distinct. For example, the same hardware model that's used in the logical phase of compilation also lives during pulse generation for the control hardware. This has added a coupling between the cloud team's offline pre-compilation and quantum hardware daily operations, making upgrades unnecessarily complex. Further, the hardware model serialisation in QAT was built for internal storage to disk. It's now being used in a distributed way across the cloud and other remote access teams. The current serialisation is fragile to changes in the hardware model, exceptionally large in size and slow to re-hydrate. As can be seen in a very rough QAT design breakdown:

Required features

The main features we want to support here are:

1. Two layer cloud based, offline compilation. First being logical that almost never changes (up to coupling direction changes) and second being as close to the hardware as possible
2. External user compilation to native gate sets cleanly (in particular for noisy simulation and offline compilation in a HPC setting)
3. Optimised remote internal user access.
4. Faster throughput for offline compilation with serialisation the biggest bottleneck currently

Suggested new features to be built

In order to address these points, here I propose some core new features:

1. Logical and pulse level hardware models
2. Remote user hardware model (no control hardware, potentially parameterised pulses)
3. Hardware model builders that don't directly de-serialise, but protect against changes in the model, giving backwards compatibility and speed
4. Repository of hardware models alongside verifiers that assert that a logical and pulse level hardware model are indeed equivalent.

Solution overview

Logical and pulse level hardware models

Here we have an initial design in place with an example test. The core idea is to break down the hardware model into strictly:

class LogicalQubit:
    def __init__(self, index):
        self.index = index

class LogicalQubitCoupling:
    def __init__(self, direction):
        """
        Direction of coupling stated in a tuple: (4,5) means we have a  4 -> 5 coupling.
        """
        self.direction = tuple(direction)
        self.quality = 1

logical qubits and their couplings, along with a native gate set. The output should be switchable between a "simple" serialised format, something like:

def __str__(self):
        return f"{self.gate}[{self.qubit},{self.target_qubit} , {self.angle}]"

and qasm. Although it should be noted that qasm has some risk for the external usecase as qasm will be re-compiled to U and CX is parsed as the qasm spec specifies. The key point here is to maintain a faithful representation of the logical gates we will compile to pulse level. The serialised format here will be fed into the next pulse level HW model which will directly build the pulse level program. This hard decoupling removes the HW model from the serialised formats and will give an immediate large speed up in the serialisation times.

The pulse level hardware here is a much simpler feature, break apart any control hardware information from the current hardware model and have the driver/control hardware level model accept a pulse level package directly, holding the connections and details of the control hardware separately.

Remote user hardware model

Here we extend the notion of the pulse level HW model. Having removed the coupling to the control hardware and keeping the pulse level information for inspection, we're now looking to improve the remove development experience. Here there is an open question as to how much the user wishes to do locally vs remotely. There are two particular use cases:

1. direct, immediate results that require all pulse information
2. Slower results that don't need direct pulse information and parameterised pulses will suffice (e.g. current_frequency + 500mhz)

The first case is largely solved by the pulse level builder and a review of serialised formats depending on how much compilation engineers are willing to do locally. We can compile straight down to the control hardware package.

The second case requires more compilation on the live system so is slower, but allows for symbolic builders that don't need direct pulse values. For example, on going long term experiments that sweep around a currently calibrated value.

Hardware model builders that don't directly de-serialise

One of the issues with the hardware model being its fragility to changes. Even when the fundamentals of what the HW model needs doesn't fundamentally change. We can explicitly build a HW model serialisation that breaks down the fundamental properties to human readable json:

{
"qubits": {{"ID":"QO", "xp_pi_2": {values}, "resonator": "RO", "frequency":4.2ghz}, ...},
"qubit_couplings": {{"ID": "Q1-Q0", "XZ_pi_4": {values} "quality": 3},...}
}

which is then re-built much in the same way that the default builders are. This does add coupling between the HW rebuilder and the structure of the HW model that is currently entirely flexible and rebuilding. But this seems preferable in terms of future upgrades as we can easily change and version the rebuilders.

Repository of hardware models alongside verifiers

Finally, an internal feature to ensure the validity of our HW model separations. We will build a cloud based hardware model repository. With the HW models being tied to QPUs in the cloud. The logical level builders will be accessible to everyone signed up to OQC's cloud for the external use cases. Whenever a new pulse level HW model is uploaded we will run a verification to assert the logical level builder is indeed consistent with its respective pulse level HW.

This would require checking all qubits have an equivalent qubit with the same ID, similarly for qubit couplings and their directionality.

Summary

One of the key points to emphasis with this design is that it doesn't fundmentally redesign any of QAT. It's a selection of new features. As highlighted in the revised overview:

But this does build on the ideas we need to make the desired features a reality whilst making any feature more core redesigns of QAT an easier process.

Any comments, especially for gaps in suggested use cases here welcome.

[chemix-lunacy]

Logical and pulse level hardware models

The output should be switchable between a "simple" serialised format, something like ... and qasm.

Should mention emitted instructions here as otherwise it reads like you want to output the hardware model in QASM. Also should just use our own data structure, there's limited benefit to emitting QASM-like gates. Only one is someone (might) be able to do a to-string on it and paste into a QASM file, but it means we can't add/change the structure of that data going forward, which is a far greater problem.

The serialised format here will be fed into the next pulse level HW model which will directly build the pulse level program. This hard decoupling removes the HW model from the serialised formats and will give an immediate large speed up in the serialisation times.

You likely don't need to transfer the model if you use this format and I don't think that's explicitly spelled out here. Technically you don't for the pulse-level instructions either, you're just shifting serialization of the model to a remapping pass.

Remote user hardware model

I can't see what clearly the difference is here over just using pulse-level hardware or what distinct benefits its meant to have?

The second case requires more compilation on the live system so is slower, but allows for symbolic builders that don't need direct pulse values. For example, on going long term experiments that sweep around a currently calibrated value.

Compilation directly on a live system is what we're trying to get away from, and the term symbolic builders and what precisely this concept would look like is missing. This bit needs a bit more clarification I'd say. (With what's there I'd also say this shouldn't be dealt with by a hardware model)

Repository of hardware models alongside verifiers

Some questions:

1. Repository as-in git repository or cloud-hosted DB. I assume the latter, but better to be clear here.
2. Don't see why this can't just be public? Will allow people to test without having to get in contact. Could also hold all our current calibration info too. Can have both public and private if you really want.

Overview

In the final diagram you show both a pulse-level hardware model and what you call a control HW, which I assume is just the backend one. Are you thinking of transforming pulse->control in a similar way the logical one worked? Or is that an entirely seperate entity that is directly linked to the hardware, or will stay seperate.

[norbert-deak]

Control Hardware Model

I think it's a great idea of separating the control hardware information from the logical and pulse information (as you described). There could be benefits to having it as a separate entity that's directly linked to the hardware, as it can be used then for more advanced backend tests and validations, without actually needing the full set of QPU information.

However, this could introduce some additional overhead when matching the pulse HW to the control HW, as well as when translating the pulses to hardware instructions.