------------------------------------------------------------------------------ Introduction to quantum technoloy project DAT096 2020, by Christian Križan ------------------------------------------------------------------------------ This text file comprises annotations to the introductory technical lecture, mainly meant for those who cannot open and view annotations in .ppts. Also, I was somewhat unsatisfied with the .pdf container export. ------------------------------------------------------------------------------ SLIDE 1 Opening slide. SLIDE 2 General welcome slide. Congratulations for selecting the first DAT096 project on FPGA-QPU interfaces. Your product owner would be myself, Christian. Currently employed as a research engineer at the Quantum Technology Laboratory, MC2 (Chalmers). SLIDE 3 What is it for? You have been tasked with constructing a QPU interface device, described in its entirety as per FPGA. The Project introduction document, currently on Canvas, introduces this project in further detail. This presentation will focus on introducing technical aspects. SLIDE 4 Cont. What is it for The idea of this device it to act as the interface to a QPU. An operator will specify some experiment, stream data to your device, which will then control and readout the state of qubits. Qubits are the fundamental processing 'unit' of a quantum processor. The logical state of a qubit is much more complex than that of the classical bit, ie. more complex than 0 and 1. These two logical states in fact comprise a subset of the qubit logical space, often illustrated as a sphere with 0 and 1 on its two poles. A typical qubit state is represented by a vector, drawn from the origin of the sphere (its center) to its surface. But, depending on a broad set of factors, the vector may point within the sphere itself as well. I have outlined more introductory theory to the qubit in my master's thesis, which is currently available on Canvas and in the Chalmers ODR. The QPU is an analogue device. An RF pulse enters, gets modified, and leaves. The resulting waveform contains the result of the quantum computation. Often simply represented in a so-called IQ-diagram. This latter term, ie. IQ-representation, is very relevant to the EESD engineer and appears practically everywhere in DSP engineering. The qubit signal is very weak at the QPU core, -135 dBm. So typically, there are a lot of sources of noise etc. that the operator does not want sent back to the host PC. This will be further outlined in the downconversion slides, as this is the main purpose of the skip / store block (waveform windowing). Apart from the so-called IQ-conversion stages, this comprises the simple DSP work expected in your project. The major hurdle of this project will highly likely be dataflow handling. SLIDE 5 Illustrated: a quantum processor. Quantum processors are third-level packaging systems. Components typically consist of microwave equipment put in racks (black). The rest (white) is a refrigerator, a helium-3 dilution cryostat capable of holding the QPU core at 7 mK. The core holder is about the size of an egg (the chip is of course much smaller), and resides inside a set of cylinders, themselves residing inside the white cylinder on the left ("the vacuum can"). A lot of smaller components are put inside the refridgeration unit itself. Microwave TWPA and HEMT amplifiers, isolators, cryogenic switches etc. The illustrated QPU is the one I myself do most of my work on, it does not use a user-configurable FPGA as its interface. Thus, your final testing will be performed on another QPU, standing further back in this image. There are currently four operational QPUs at QTL, Chalmers. We plan on acquiring many more. SLIDE 6 The very big picture. Your device comprises four major components: an Ethernet interface to a host PC, a central stream controller, an upconversion stage, and finally a downconversion stage. The Ethernet module will receive / send packets to / from the host PC. The upconversion lane will convert the payload contained within said packets to appropriate microwave frequencies used for communicating with the qubit. The downconversion lane will convert the output result from the QPU core into host-PC-readable data. Finally, the central stream controller will tie everything together in this system. Do note that the upconversion lane box contains within it a summation unit ("Add N") which allows for some nifty DSP tricks. It combines user-selected DAC channels element-by-element into some data output. All of these modules have been designed with the Nexys 4 DDR board in mind. The final device however, will be the Xilinx Zync Ultrascale+ RFSoC. SLIDE 7 Illustrated: the overall dataflow diagram. This image does not illustrate block-by-block what you are expected to implement. It outlines the over- arching dataflow plan of the device; you are implementing modules to achieve this overall dataflow plan. SLIDE 8 Ethernet communications Key terms: - Physical Ethernet - UDP - RMII - ARP - AXI This is a custom module. To enable high-speed data streaming from the host-PC, many modifications must be made to 'typical' Ethernet communication designs. Yet, to keep this module bare-bones enough to be suiting for DAT096, we have also kept the amount of specified modules to a minimum. From the PC, the operator will stream data using off-the-shelf, standard Ethernet frames. We have specified this project to operate using UDP, although you are expected to treat all frames regardless (aka. don't simply throw away non-UDP-containing frames). Should UDP be detected, and be within the specified port numbers 30000-30255, then this is a valid data stream packet. This will be sent onwards to the central stream controller. Packets that do not conform to this is to be sent onwards into the system. Typically, this will be your control signals for all kinds of modules in your design, such as selected frequency for the upconversion NCO. There may also be so-called ARP requests. You are expected to treat these using an ARP resolver module. This is so that you don't have to set MAC manually for a static IP on the host-PC operating system. Mainly as this is usually bound to admin-right issues. It is adamant that your design is non-host-PC-CPU dependent. The custom package format sent in the data payload is illustrated in a separate document. Basically, the first 16 bits will contain the data stream index, the following 16 bits the I-component of the waveform, and the last 16-bits the Q-component of the waveform. In total, expect at least a usable payload of 48 bits. The interface from the Ethernet communications module to the central stream controller will be over AXI bus. This is true for almost all datastream buses in the system. Likely, you will want to separate the stream index at this early stage; it is best to leave the dataflow path to *only* datastream payloads. The upstream to the host-PC is identical to the downstream one, of course in reverse. You are expected to conform to RMII, since this is what the Nexys 4 board uses in its Ethernet communications. SLIDE 9 Central stream controller Key terms: - Stream management - FIFO buffering - DDR DRAM - BRAM cells This block has on purpose been left up to interpretation, as it will differ greatly between groups. At any time, you may receive datastream packages from various sources in the system. These will have to be managed to ensure that the output stays in sync, and is constant. Some package will at some time be inserted into this controller from the Ethernet communications module. Its job is thereafter to look at the package index, and send its to the target FIFO buffer. Keep in mind that you are recommended to keep the number of writes to a minimum, thus typically the size of a slice in the FIFO buffer will typically equal that of a DRAM one. Meaning that the DRAM memory slice in question, containing several datastream payloads, is typically transferable as-is to the FIFO when the fifo_not_full signal is lit. You are greatly encouraged to look into the capabilities of the board, such as its DDR DRAM. Although not necessarily required, for instance if your design is fully operational using BRAM cells. This block will likely lead to a lot of contraints in your system, you are recommended to illustrate your dataflow using higher-level tools beyond blank VHDL on a screen. This will make it easier for whomever reads your final documentation as well. The bus annotations to the right of this image (M x N AXI) are misleading, please refer to more updated documentation. SLIDE 10 Upconversion lane stage Key terms: - FIFO buffer - Run length encoding - NCO - IQ mixing (this is a big one) The target FPGA DAC (and ADC) has eight parallel slots expected to be written to at a speed of 500 MHz. These are then read out successfully to generate a GHz output. Meaning, you have to treat 8 simultaneous data samples. These may arrive at random times, thus to keep the data pace constant, your upconversion lane will contain a FIFO buffer at the beginning. One slice of the FIFO buffer typically contains several payloads. The payloads in turn contain the I and Q components of the signal sample, needed in you IQ mixing block. The FIFO is expected to be able to signal to the controller that it may be filled up with additional content. Not illustrated: control lines to (pretty much) every module, from some host module that you steer using the 'other_data' line in the Ethernet communications module. Typically, sending 150 zeroes one-after-another is not that useful. Thus, you are expected to implement very basic RLE. Through some command structure, controlled using the control signal host, this block is expected to be able to output said 150 zeroes when deemed necessary. The qubit system is sensitive. We do not want to flood the QPU core with unneccesary frequency content from sideband mirrors. Thus, you are expected to implement IQ mixers into the upconversion stages. These in turn require numerically controlled oscillators. These will in turn be settable by the operator, which provides immense flexibility in quantum experiments. Remember: the qubit must receive data in its expected frequency range, otherwise you fall down the rabbit hole to the quantum fairyland. Meaning that IQ-mixing will have to be part of the final device. We do know that the ADC / DAC has a built in IQ-mixer, *but* it is only capable of mixing with a fixed frequency. SLIDE 11 (Zoomed-in upconversion lane stage) SLIDE 12 (Zoomed-in upconversion lane stage) SLIDE 13 Downconversion lane stage See upconversion lane stage, this is a reversed mirror image of the former, apart from the skip/store block. The skip/store block will be your fundamental tool for windowing a received waveform. The operator should be able to specify that everything outside a 5-8 µs window should be discarded, for instance. SLIDE 14 (Zoomed-in downconversion lane stage) SLIDE 15 (Zoomed-in downconversion lane stage) SLIDE 16 A general notice, warning if you may, is that sinusoidal generators and IQ- mixers may easily take up a lot of your time if you are not careful. Or, if you manage to get such a solution working, you might even want to play with the DSP designing tools available through Matlab toolboxes. I personally advice against this solution in this course. SLIDE 17 For testing, you are advised to rely on looping back your digital signals wherever you wish to test them. Should you want to procure input signals, corresponding to actual quantum experiments, let me know and I'll generate these on the fly. Extremely likely, I will upload a broad set of test signals for you to experiment with either way. SLIDE 18 Documentation in this project will be plentiful. If not straight away, then as soon as possible. We have knowingly used existing protocols etc. with documentation widely available practically anywhere online. Frankly, our spec. for (for instance) an Ethernet frame from the PC would pretty much be a copy of the Wikipedia entry. More precise specifications can of course be arranged. SLIDE 19 We are the people behind this project. Myself, Christian, will be your product owner. Please direct all your questions to me, I listen very actively to my e-mail, krizan@chalmers.se. The questions which arise are likely to be shared by many, don't be surprised if I post a bulletin or similar explaining your question + answer in further detail. At times, I may have to "refer up a level" to the specification source of this project, Mats Tholén. He wishes to be kept out of communication, as he is busy with other projects. Do note: Mats is associated with a company, Intermodulation Products AB. Mats is interested in co-ownership rights to your code (note: not total ownership transferal). The conversation is ongoing, and a contract is underway. SLIDE 20 Final slide.