[Feature Request] More flexible implementation of CNOT gates

[SophLin]

When congestion results from simultaneous CNOT gates, besides reconsidering the allocation of ancilla (https://github.com/latticesurgery-com/liblsqecc/issues/15#issue-1216018964), one can also try flipping the MXX between ancilla and target, and the MZZ between ancilla and control. This requires a small change to the input format as well. One should specify which pair of MXX and MZZ belong to the same CNOT.

See this paper https://arxiv.org/abs/1704.08670 In ZX calculus, the 3 diagrams below all represent CNOT

[alexandrupaler]

It is a nice feature request. We could get it very soon implemented. The main issue might be related to #15, but we can sort that out also pretty fast.

[gwwatkin]

Implementing a new kinds of cx gates, distinguishing with QASM comment annotations

• cx q[0],q[1]; // SplitControl
• cx q[0],q[1]; // SplitTarget

Implementing in two steps. The first step should achieve the minimal viable functionality with existing LLI, enough for testing and unblock you on other things. The second step is to obtain the slice-optimal implementation of the CNOT with lattice surgery. Once I get there we can assess whether to prioritize that or other things.

1) Prepare routing and connectivity and parsing only using existing LLI

Pre-allocating the patch used by the third wire:

We already perform CNOTs in a very similar way in the Python interface repo things to add are:

• Support for both kinds (Current approach is closer to one of the two)
• Path finding to determine a better placement for the mediating patch (the central wire)
• Simplify corrective terms given that the operation is a CNOT (instead of deriving them from pi/4 rotations.

  Example

  (excluding corrective terms)

2) Minimal ZX implmentation with new LLI

Add new LLI, so that a new patch needs not to be initialized and patches can be merged into a single one.

• Protrude
• Explicit Merge
• Explicit Split
• Shrink Will define later the details

  Example

  (excluding corrective terms)

[gwwatkin]

After discussing with @SophLin, it turns out that approach 1 is as efficient as approach 2 because patch initialization and measuring in the Standard or Hadamard bases takes 0 code-distance-proportional time steps.

Will only implement approach 1 since it does not require any new instructions.

[gwwatkin]

Implemented most of the functionality in #20. Now have to work out corrective terms

[gwwatkin]

Corrective terms