 Hi everyone, my name is Lauren Capaluto. I am a software engineer at IBM Quantum and I want to thank all of you for joining my APS March meeting talk virtually. Qiskit is IBM's open source software development kit for quantum computing and Qiskit Pulse is the aspect that I work on. In this talk I'm going to be introducing the Pulse programming model and I'm going to go through a quick demonstration of the kinds of physics that this system enables. With the near-term devices in the field we're of course immensely interested in driving down error rates of program execution. This can be done on both the hardware and software side in parallel. On the hardware side we are pushing the boundary of what these machines are capable of and on the software side we are trying to reach that boundary by optimizing programs that are executed on the device given the constraints of the hardware. We do this by developing sophisticated quantum compilation techniques. Quantum circuits are what most people in quantum computing are most familiar with. It's a high-level programming paradigm that's mostly agnostic to the exact timing of operations. It operates at the level of gates and circuits. The circuit optimizer which we call our transpiler at IBM is mainly responsible for reducing the overall size of the input circuit to improve the performance of that circuit. It can also reduce the number of higher error two qubit operations. Sometimes we want more control, fine green control over what the hardware is going to do and this is where pulse schedules come in. So this lower level control means that now those black box operations of gates and measurements on the circuit level become transparent. So if we want to improve the performance of an individual gate potentially through pulse waveform shaping that is possible at this level. We also get lower level data through the readout chain and that means that we can mitigate readout errors as well. Of course this comes at a cost and that is greater complexity and it really requires much more user know-how at this level. Now I'm just going to introduce the pulse programming model. So we're introducing a new interface, a level below the quantum circuit again for that power user. So quantum circuits can be translated to pulse schedules but the opposite is generally not true. So this lower level interface for a power user is going to allow them to send the exact signal data that they want to play on every channel across the device to influence qubits on that device. It will also allow the user to collect information about that back end and collect readout data. Naturally pulses are a pretty central aspect of the pulse programming model. So the pulses in our system are actually the complex valued amplitudes. They are separate from the phase and frequency which are controlled by separate instructions. So in the bottom left we have an example of a pulse. This is our pulse envelope for in this case a drag pulse. So the orange line here is the imaginary component and the blue line is the real component. On the bottom right we have the modulated signal. So this is the drag pulse with the phase and frequency modulating it and that is what is going to go to the qubit. The separation makes sense if we think about how the control rack electronics could be set up. So we have a digital to analog converter that can be part of arbitrary waveform generator. This instrument is going to consume the play instruction which is passing the user's sample data to this device. The set frequency and shift phase instructions are setting that phase and frequency and playing it through a continuous sine wave generator. So the output tone will get mixed in with the output of the DAC and get sent through a signal channel to the qubit. In our system we have virtual channels. So that means that our channels are labeling physical channel lines and the back end is ultimately really responsible for matching the labels to the proper drive lines. This means that we can abstract away things such as a multiplexed readout where we have multiple measure channels on our side going to a single physical hardware channel. We don't have to worry about that here. Every qubit will have also a measure channel which is going to stimulate readout for that qubit goes down to the readout resonator and then we have an acquire channel to collect the data. That acquire channel goes to an analog to digital converter which is in turn triggered by the acquire command. Lastly we have as I mentioned before lower level data in the readout chain. So what this looks like in our system we have at the lowest level our raw data. This is output directly from those analog to digital converters. We can integrate this signal using a kernel to create an IQ point. So the signal on the on the left side is going to correspond to just a single point in the middle. When we repeat this many times we can see that the scatter of these IQ points is going to be dependent on the state of the qubit that the readout resonator is coupled to. Using that we can build a discriminator. So this is building a threshold in this data where any new point to the left of that green line is going to be classified as the ground state and anything to the right or the top right of this scatter plot will be classified as the excited state. Now quick overview of circuit scheduling. So this means that I'm taking an input circuit and I'm going to lower it to a pulse schedule. This is really straightforward in Qiskit. So I import my scheduler method and then I build my quantum circuit as usual. I do have to transpile my input circuit. That means that the input circuit is going to be rewritten in terms of the native gates of the device that I'm transpiling for. Once I've done that I can build my schedule on that transpiled circuit. The back ends which is pulse enabled with the system will have calibrations for each of its native gates. So I can just translate pretty directly. As you can see on the right we have the Hadamard gate. It's translated to a single drive pulse on qubit 1. We have a collection of pulses to implement that CNOT gate and then finally we have measurement stimulus and acquisition on both qubits. Now I'm going to go through our physics demo. So for this we're going to be probing readout crosstalk between two qubits and we're making use of the low level readout measurement data. So that is what's allowing us to get these IQ scatter plots on the right here. We selected two qubits randomly for this experiment, qubit 16 and 17 on IBM Q Almedin. And what we did was set up four different configurations of these qubits. All four where we have four product states. We have the zero zero state where they're both in the ground state, the one zero state, the zero one state, and finally the one one state where both qubits have been set up in the excited state. And then immediately after we measure all four configurations separately. Then using this data we build two discriminators. One is going to use a subset of the data. So qubit 16 will be discriminated while qubit 17 will be held in the ground state and vice versa. Discriminator two is using all four calibration setups. So we'd expect that discriminator two will perform better if there's readout crosstalk because perhaps the state of qubit 16 in the ground state will shift a bit depending on the state of qubit 17. It's important to note that the runtime of these two discriminators is very different. So if we only need to use a subset of the data for discriminator one, then we can perform all of our readout calibrations in linear time with respect to the number of qubits. But if there's significant crosstalk, we would need an exponential number of calibrations to accurately calibrate the device. Again, it only takes about a dozen lines of code to set up this entire experiment. So the important thing to note in this Qiskit code here on the left is that we're using kernel measurement levels. So that means that when we get our measurement data back, we're going to get complex valued points rather than already classified data, as we would normally get for quantum circuits. On the right, we have an example of one of our pulse schedules. In this case, the one one schedule where both qubits have been excited and then immediately after measured with the acquisition and measure stimulus pulses. As it turns out, the discriminator taking into account all of the data did not perform any better than the other one. This is good news. It suggests that there's no significant crosstalk between these two qubits. And although we can't make a claim about the entire device based on only two qubits, it's still evidence that we may be able to do a linear number of calibrations. So in my talk, I introduced the pulse programming model, and I showed a quick demonstration of how we can make use of it. In the future, we're going to continue building out the functionality of this model. Thank you all very much for listening in. Please stay safe, stay home through this global pandemic. Thank you very much.