So next up is Jeremy Kerr, we have a talk on the power architecture. Thank you very much. My name is Jeremy Kerr, I work for the IBM Linux Technology Centre, and before we get started I have a bit of a confession. Actually, it's been the last year working on less kernel and more firmware. I'm allowed to say the F word, right? So firmware doesn't typically have a great reputation amongst system implementers and kernel developers. Not typically open, modifiable, verifiable. Generally you get a binary bit of firmware that does things like introduce interesting bugs into your environment. So what I'm going to talk about today is how we're trying to address this in open power and a bit of a general set of information about what open power is. And I guess we'll start there with a broad overview of open power. It's three things basically. Firstly, a system architecture based on the IBM power designs. It's a collaboration of development of hardware, system and firmware between the open power foundation's member parties. And thirdly, it's a Linux-based platform generally targeted in the cloud, the server market, HBC as well. And we'll go into how the lineage defines that in a little bit. So three essential things. As I mentioned, there is an open power foundation at openpowerfoundation.org. And the website there is where they track the members and basically all the designs and things end up in the open power foundation hopefully available on the website. I did mention earlier that the open power is an architecture as well. The core of which is power8. There's been a few talks on power8 over both this LCA and previous. If you haven't seen Paul McCarris' one earlier this week, let's just go and download it. But the first open power machines are based on power8 processors. They're quite interesting from a CPU architecture point of view. We have up to 96 threads per socket, some interesting transactional memory capabilities and a new function called CAPI where devices can participate in the coherency protocol between memory and CPU. So some interesting things there. Paul, we're sort of concentrating on the Linux side now. And what does power8 mean for the software stack? To find out, we'll sort of step back in time a little bit here, back to the pre-power4 days when the Earth's Earthened Magma was calling. The architecture itself defines what we call the machine state register. All power machines have this machine state register or MSR. It's described by the power architecture definition. And it defines what state the machine is, funnily enough. Things like whether the floating point unit is available, whether external exceptions will enter the processor. And one of the bits in there is called a PR bit for problem state. So if that bit is one, you're in supervisor mode or operating system. Sorry, for bit is one, you're in problem state mode, which is generally user space. You're in supervisor mode, which is the operating system. So this bit controls whether you can do certain things like execute privilege instructions or access certain bits of memory. Can you access memory with translation turned off, and hence access all of memory? Or if it's one, you're in their usual constraints of running a user space process where you have your only a certain set of translations and you can't execute arbitrary instructions. You have a smaller set to execute. So this is the pre-power4 days. Sometime around power4, the hardware folks introduce a new bit into the MSR, called HV or hypervisor. And like the PR bit, it controlled whether you have access to certain resources, certain instructions or certain translation mappings. So again in the table here, we have, if you're running with HV equals one, you're in hypervisor mode. Or if you're running in HV equals zero you're in hypervisor mode, and if you're running in PR one, then you're in user space. However, the hardware folks didn't really tell anyone outside of IBM at the time. So we didn't really have this HV equals one bit available. It was not listed in the power architecture. Well it was listed in the power architecture, just as a reserve bit, there was no mention of hypervisors or anything like that. So it wasn't really available for general use. Now this wasn't a huge problem. This was way before we had any open source hypervisor code to run before any sort of 4K VM was out. And before hypervisors were a huge thing in our world. So essentially this made a Linux running on power would always run in what would be a guest environment. And if Linux or if your operating system isn't using it, what's it for? We have this thing called PowerVM. Well it's called PowerVM now. It may have been called something back in those days. Maybe perhaps. The power hypervisor. Right. And what's it doing? So that we have originally a very light hypervisor, not necessarily visible. Again because we didn't see this thing described in the architecture. It wasn't really visible. And essentially we're running on a system with PR equals 1, PR equals 0 mode. Except we just had one bit in the register which was marked reserved, always set to 0 because we're always running in non-HV mode. So this meant things like all of our benchmarks we'd run on powerful hardware were always running with this very light hypervisor going. And no one kind of objected to it. There wasn't a huge amount of effect on the system. And we got quite good performance even with this tiny hypervisor running, running out our normal OS in what would be a guest mode. Over time over the generations of power systems the hypervisor grew more functionality, made it into more of a complete sort of virtualization solution. So you could buy one of these power machines and it's pretty much like a ready-to-go guest running operating system. You could put multiple OSes on it running at the same time. But of course this hypervisor is IBM internal. So it meant that you weren't writing code for the hypervisor, you were writing code for the guests all the time. The management systems for this are proprietary. You'd get these great bits of software where you could drag and drop guest OSes around and that sort of thing, but it's all proprietary. And there's no way to run any Linux code or any one-of-your-like code in this HV equals 1 mode. Now again it wasn't a huge problem. There wasn't a lot of code that you would want to run in HV equals 1 mode. But over the time, over the generations of power processes more and more open source virtualization solutions like KVM were coming out and we'd like to run those. We have a system that's capable of this hypervisor mode. We have a hypervisor, we'd like to put the two together and make it a nice system. So the big change for power rate is that we now don't have this hypervisor layer between Linux and the operating system. There's nothing separating the OS from the hardware. There's no higher privilege code than the OS. There's nothing that is going to steal your cycles or anything like that. And there's no bits of hardware that you can't access directly from the OS, which is a big thing for us. We like having access to the entire machine. We want to make sure that we know what's running on the machine and we want complete control of what our systems are running. So using this, we now also have access to all the functionality that we get with this hypervisor mode. So we can use KVM and use the facilities of the architecture to implement a Linux-based hypervisor. I mean, we're not exactly like this. We do need a little bit of firmware. But in this case, the firmware is less of a separation of OS from hardware and more of just a bit of a hardware abstraction layer. I'll go into that in a little bit. So I guess similar to what you'd think of as an X86 machine where you don't have a giant bit of software that's between the OS and the hardware, except now on X86, we're seeing this kind of thing happen where we do have a higher privilege layer of code by the SM BIOS, which is doing things like handling certain interrupts that never go to the OS. It will receive an SMI, system management interrupt, go into SM system management mode, execute some magic code that you have no idea what it is, and then possibly return to the OS or elsewhere. So we've gone to this model here where we no longer have a hypervisor. We have Linux running in HP equals one mode and a bit of firmware to sort of help that out. But the important thing now is it's all open source. So the entire stack that you can run on a... The entire stack you can run on one of these machines is verifiable. It's editable. You can see what software your machine is running from the first instruction onwards, which is really important for us, especially with the... I'm sure Matthew has told us last LCA about the importance of knowing what you're running and also being able to modify that and making the system do what you want it to do. So, again, you buy an open power system, you run code and the first instruction from there from boot is yours. As well as being open source, it means that it's available for others to implement. So we have this source repository on GitHub, but part of the open power architecture being licensed at all is that others can implement open power hardware, which is also a big thing for us at IBM. So the first example here is the Google's recent announcement... I think it's getting on a bit now, but their announcement of their custom open power board based on two Power8 CPUs. So they designed the board. They also modified the open power firmware to make... to accommodate the hardware that they've designed and have built an open power system in what we think is pretty quick time. And because they're able to modify the hardware in the firmware, they've customized the hardware itself to their workload, which I assume they're pretty happy about. One of the other designs based on this is the Tyan open power reference system. This is something that you can buy online at the moment, I believe, I haven't tried, but it's there. It's probably less expensive than traditional IBM Power hardware. And it is listed as experimental, so there will be bugs, there will be things that aren't implemented yet because the firmware is still being developed. One of the interesting things about this platform as well is that it's based on a standard ATX motherboard. So in theory, you could pull it out of that server and put it into your desk side system and have something really noisy next to you. Maybe Tyan will sell the motherboard separately, I'm not sure, but interestingly, we're sort of moving towards a bit more of a commodity part in the power design, which is sort of unheard of in the power seven days. So also interesting for us that this is the first time that we'd have non-IBM companies releasing power hardware, which is great. So a bit about the implementation, about what we've been doing over the last year or so and what our exposure to the firmware is. Firstly, the bits we need to build. So when you turn on your power machine, the first thing that starts executing, whether there's some little bits, but the main thing you start executing is hotspot. And this is responsible for early hardware specifically bringing up the caches, the memory, the clocks, the time tracking systems and whatnot. So this is a fairly self-contained thing now. It executes entirely and then passes control again entirely onto this new project called SkiBoot. It's executed by time SkiBoot has stopped entirely, so the system has been handed over to SkiBoot at that point. And SkiBoot does further machining initialization. Some of the things that HostBoot didn't do, it provides I think some more, basically the more the IO side of things, some interaction for PCI devices and then also produces the runtime interface for these machines. So again, we have a workload, we have an OS, we have this firmware down to the side and that firmware itself is SkiBoot at runtime. And less of a firmware than just a hardware abstraction layer in that it doesn't run in any extra privilege level than the kernel, it doesn't receive any interrupts. All interrupts are routed directly to Linux and then if the firmware is to handle that interrupt, Linux will then pass control back into the firmware to do what it needs to do. So its only entry point is a call from Linux. And the entry point is defined by a new firmware OS interface. It's not an x86 PC BIOS, it's not a UFI interface, it's basically just a set of function calls with a defined API. So it's really, it's no different than having a little library that your operating system can call to do certain hardware-dependent features. The, as a sort of fairly regular PowerPC firmware, it is device-tree-based. So a device-tree allows us to describe the hardware that's running to Linux and Linux will pass that device-tree to find out what the hardware looks like and probe the hardware based on the information of the device-tree. So SkiBoot is very small. Our plan is for it to be as compact as possible and to steal as few cycles as possible. And on steal, you actually give it cycles because you call it from Linux. But in that vein, we haven't implemented an operating system loader. So there is, SkiBoot doesn't have any functionality to execute your grub or execute your U-boot or whatever else because that would require reading grub from disk or it would require you're doing some network, implementing network stack to get a loader onto the system. So instead of implementing all this stuff in the firmware, what we've done is used SkiBoot as our operating system loader. And that means that we have a, basically the first thing that SkiBoot executes when it's finished in its initialization is a little embedded kernel that's burnt into, it's flashed onto the hardware itself. And this kernel contains little in-net ramfs which has some user space utilities that perform the functions of a boot of what you're expected by us to do to pass control to an operating system. So that means we use a standard Linux kernel for our boot loader. We have the standard Linux network stack. We don't have to write our own stack in firmware. We have all the standard Linux device drivers. We don't have to re-implement device drivers in firmware through our boot.  So essentially our BIOS interface is a user space application. The UI that you use to set your boot order or set your network boot or everything is just implemented as an end-curses application running on Linux embedded in your flash. So in that regard, our firmware doesn't have a lot of functionality that's provided by these bits. And one of the justifications to doing this was bring up time. There's no way we could write an entire firmware with a network stack with device drivers from everything you'd want to boot from. We can just use what's there in Linux and go straight from there. So another one of the components we've worked on is the platform ports, the PowerNV platform port, NV for non-virtualized. And this is the bit of Linux that interacts with our new firmware API provided by Skiboot. The API itself is called Opal, OpenPower AbstractionLayer. And it's the base for PowerKVM hypervisor. So KVM running on Linux will use these Opal calls to interact with the hardware. The platform port is quite small. It wasn't a huge amount of code. It's not a huge amount of difference from the previous or the other PowerPC platform code. Another one of the bits of software that makes an OpenPower firmware is what's called the OnShipController code. Also open source, we have a little CPU on your CPU that is responsible for thermal control power management, electrical power management, and provides the hardware-specific back-end for our CPU freak driver. So we basically set some registers. The ACC reads that and updates the frequency system accordingly. One of the other parts of any sort of server-class machine is some sort of management controller. We use a BMC from another company, and this provides out-of-band management that you'd expect, be able to turn your machine on and off over the network, get a console over the network, and all the sort of things you'd expect from a server platform. It's fairly standard in the x86 world to be able to send IP my commands to your server and get it to start, stop, and it has a separate network interface. It has a separate MAC address to the rest of the system so you can basically define a management network alongside your server's network. I think Matthew's got a talk coming up about IP my, and then we're going to talk into this. We have a BMC, which is kind of what you expect on a server machine. And to title together, we have some build infrastructure called OP build. This is responsible for basically getting all the bits of source we need to produce an open-power firmware, basically compile them using a compiler that builds itself and package it into a single flash image that you can then burn to your machine. It's based on the existing build route project. Again, an open-source sort of package building system. And that constructs a few things. It constructs the Peteyboot user space environment, which is our boot loader. It constructs a kernel to execute that and all the firmware components that also need to go into flash. So it's all built in one step. Well, download and build. So this is how you would build an open-power firmware. It's all fairly unconventional. We clone it from this repo, change the directory, and then do a... It has a menu config style interface. We just load up the Palmetto DevConfig for a Palmetto machine and then build. OP build is basically just an alias for make. And there we go. Some notes on kind of the open-source side of things here. We have ways to customize the build. We could, say, build a different version of SkiBoot. I think 2.1 is completely majoring at this point, but this is how you would do it if you want to specify a particular version of a particular package. Sorry? We started at 4, so don't do this. So the idea here is that when you're building open-power firmware, you have complete control about which packages go into that. You also have complete control about where those packages are sourced from. So you can point the OP build system at an existing tree and you have... be incorporating that particular sources rather than what we've defined already. There are also many other different ways to control the build. It is a standard sort of builder environment. We've tacked some bits onto it, but there's nothing particularly special about it, so you can define lots of variables to, say, use this version or use that tree or even use a custom set of patches that you provided or just completely ignore the version control and build something that you've hacked up yourself. So there's a lot in there. There's a lot of documentation, or there's a bit of documentation in the GitHub pages about how you can go about doing that. So yeah, so basically what we have now is a firmware that you have complete control of, a system that if you like to hack on hardware, you could build your own, and that gives us a bit of a new way to build machines for, you know, custom data centres and custom cloud deployments without having to redefine the computing industry. So I think we're pretty happy about what's happened so far. There's still a long way to go on Polish and using enabling new CPU features, getting new hardware out there, but hopefully we've learned to like firmware just a little bit more. I've got plenty of time for questions. Usually there's a few feature requests and things, so please ask away. Wow. Just a question on the Petty Boost. That used to have a graphical user interface.  It's still in the tree. I haven't built it for a long time now. So a bit of background here. So Petty Boost was originally built for the PS3. And the PS3, to the PlayStation 3 PowerPC machine with a little bit of flash, similar constraints. We want to be able to burn our kernel into flash and then boot your proper operating system from that.  And it was based on Keith Packard's lib twin. We've only recently got more than a text console on these power machines. So firstly, there hasn't been a lot of motivation to implement it. But it could well be reinstated. It's probably not the best sort of thing in a server environment where you want to have a low bandwidth link to your management. But it could definitely be done if necessary. If you can implement a 3D one, that would be even cooler. Just curious, you of course mentioned the fact that you guys are quite happy to have a full stack and you can only expand metal. Were customers asking for that a lot or were they just mostly the developers like we want this because it would make your job easier? I might have to let Anton come in and correct me if I'm making anything up here. But that was a big feature in why people wanted to use something that's open power based. They can control the hardware. They can control the entire software stack and not only customize it to what they want to do but know exactly what they're running.  Do you want to make your cloud, whatever, is only going to operate constrained by the worst latency system you have? So the idea here is that if there is something in a firmware that's taking up latency, in that case you can see what it's doing rather than having like... You can't measure it? Yeah, if it's a black box, you're less able to measure, you're less able to verify why your latency is, why you're getting jitter on the OS.  Anton, is that going to cover this? Yeah, I was just going to explain that what Jeremy's been talking about is the open power machines that will be produced by vendors other than IBM and perhaps by IBM in the future. That the current Power 8 machine that you can go and buy is not exactly like Jeremy described. It still has the Opal firmware but it has a service processor instead of the BMC and the service processor will only flash a signed image that's been signed by IBM. So you don't have that amount of freedom to modify things on the IBM Power 8 systems. However, the Opal ski boot stuff is still open source and you can get the source of it and so you can see what's there. And it's still true that you're running like this picture with the OS running directly on the bare hardware and this Opal firmware layer providing a library of services rather than being a layer that gets between you and the hardware. Yeah, I just need to clarify or expand on something Paul said there is that open power machines don't encompass the entire set of Power 8 machines. There is Power 8 open power and Power 8 IBM power. And the open power ones are basically they're implementable for anyone but only IBM can sell an IBM power machine. So what I've been describing here is the open power side of things the IBM power is still based on the open source components we've been talking about but sort of comes in in a slightly different sort of management architecture that uses some more IBM components than these open power machines would. Yeah, thank you. So traditionally power hardware has been tightly coupled with AIX. I'm curious with this new firmware architecture is AIX also running on it or is it going to have a proprietary stack for those machines? So you're asking does AIX run on open power machines? I haven't seen it running I don't know of any plans to make it run. The open power foundation is focused on Linux so as Jeremy Kerr the conference attendee not Jeremy Kerr the other employee I'd be very surprised if that would happen. So that's probably a good point to say. Yeah, if you could, thank you. Just making it clear. So AIX only runs as a guest it requires a hypervisor and only PowerVM is supported so AIX is only supported on PowerVM at the moment. And PowerVM does not run on the open power machines. On the IBM Power8 machines you currently get a selection in the Linux only ones you get a selection in the service process of WebMenu whether you want to run Opal and all of the stuff we've been describing or alternatively PowerVM so you can power on the machine with PowerVM and then you're just in the PowerVM world like we have been for years. So that's the sort of dichotomy. And if you're an AIX customer then you're over on the PowerVM side. Yeah, so the focus of OpenPower has very much been kind of the massive scale of Linux machines rather than your, I guess, cathedral versus bizarre sort of thing. You want your cathedral of IBM AIX traditional IBM PowerVM machines versus your bizarre of all kind of things we can implement on OpenPower using different hardware designs, different software designs and things that you can control yourself. So that's about the gist of it, as I understand it.  I'm not in the hardware business myself but I would say that you would at least need an IBM CPU and then you could probably build the rest yourself. So... The question was whether Mikey has access to a foundry and if so can we come and visit? And are we selling licenses to implement a new Power8 compliance CPU in not an IBM Foundry? Yeah. So the entire core is licensible. You can produce your own Mikey Power8 and go from there. I'm waiting for it to bat in breath. I've got a few resources in the slides. Slides will be up with the conference agenda after the conference I believe. So our GitHub repo, our mailing list and our little home in the kernel tree under Platforms PowerNB. Okay, no further questions. I can... Thank you very much. I'll give you your obligatory... Thank you.


Show of hands. How many people here are really more of a physics background? Okay. How many are really more of a computer science background? Okay, slight majority. My own background is in classical computer architecture and high performance computing. And so the talk I'm going to give here is from that perspective. I'm not a quantum mechanic, but I do understand how complex systems tend to go together and work. And I do understand computational models. One of the things that, and I tend to like to approach this really as a hardware up kind of an approach. So I'm not going to get into any interesting machine learning algorithms. But I am going to get from some basic concepts through a hardware model through some fairly specific details on how we actually build a quantum machine. And then up to this, of course, being an open source conference, some descriptions and an example of our CERC Quantum Programming Toolkit, which was developed largely at Google. But we've got collaboration from academia, particularly in Europe. Now, a lot of people find, well, those of you who are physicists who have mastered quantum mechanics, bless you. I spend most of my time in airplanes reading textbooks and trying to catch up with what I should have learned when I was much younger. But I've come to the conclusion that, in fact, it's okay to be intimidated by quantum systems because Newtonian mechanics is something that has an evolutionary advantage to understand. When you throw a rock, it's going to follow a parabola. It may have taken us tens of thousands of years to understand the mathematics of a parabola. But even children can understand fairly quickly that if they're trying to hit something at a certain distance, they throw the rock with a certain force and a certain angle and that resolves. It's important. It matters. It can be a life or death thing. And so evolution is going to favor brains that are good at understanding and intuiting Newtonian mechanics. But there has been no evolutionary reason to be able to have intuitions about quantum mechanics. And so it sort of hurts our brains when we look at it. If you go back and consider the origins of this, I mean, the classical experiment and, again, I'm just talking for some slides that are here at the intro that you don't really need to see. You can imagine what I'm talking about here. That you consider the experiment of the beam splitter experiment. Classic thing. You fire photons into a beam splitter. The split beams you put to two mirrors. You run those two mirrors into another beam splitter and then you put some kind of detector on the two paths coming out of that second splitter.  Then they're going to merge. Then they're going to split again. And my detector should see the equivalent signal. In fact, this is not the case. And this is rather perplexing. Now, quantum mechanics has a model that explains this rather neatly through linear algebra. But in order for that particular phenomenon to be explained by the equations, we have to be prepared to accept the notion that the photons are actually on both paths at the same time. And again, this hurts my caveman brain, but it is observable. It is verifiable. There's a good solid mathematical basis for it. Now, given that a photon can be on two paths at the same time, there are implications for what we can do in terms of information theory. And so what we do is we construct qubits, a quantum bit, that can have two values at the same time. Two values that are superposed. It is not either one or zero. It's not even statistically maybe one or zero. It is both one and zero, concurrently to some degree of probability. I have not had the good fortune to have seen all of the other presentations today. But I imagine you've seen some block spheres out there, this three-dimensional sphere that's usually used to visualize a qubit. And so if I have a single qubit, it's a unit vector that's out there to some point on the sphere. And that has some degree of oneness and it has some degree of zero-ness. But the projection of the complex space ends up showing that I can be performing rotations around three axes on this value. In some cases, it's going to affect that one or zero-ness. In some cases, it's not. It's going to be indirect. I'm affecting the phase, which may become a factor in some later manipulation of the qubit. So, okay, still nothing? Fine. Look, I'm just going to use my deck to just organize my thoughts, if you all don't mind. You can rotate it and then we squeeze our eyes out. It would be nice. It would be nice. Because now the slides are online. Yes, by the way, I mean not that I want everybody heads down on their computers, but the slides are on there. So for once, the people who are remote have the advantage. Oh, dear. No, but the people who are remote may have downloaded the deck already. So for those of you in the studio audience, there's a copy of this deck out there on the conference site and you can pull it in and look at it locally. Anyway, so having these quantum bits is a really cool concept in terms of information theory. But how can we get at them? How can we manipulate them? The simplest quantum systems are fundamental particles. And so, and again, you know, Xanadu is working with photons in this regard. And they're doing some very cool stuff. This is the first time I've seen them present and it was really interesting. But the smaller you get, you know, an electron, a photon. Yes, individual particles could be quantum bits, but they're hard to capture and manipulate. The first really successful experiments going back 10, 12 years now were using ions, a charged atom. If I have a charge on the atom, I can push it around using electromagnetic fields. And it is nevertheless a quantum particle and there's a lot of good work still going on in that space. But this is one of the few places in computing where being bigger is actually an advantage. We've spent decades trying to make things smaller and smaller and smaller, fit millions of transistors, billions of transistors onto chips. When I'm trying to manipulate a qubit, I actually kind of like it to be big at this stage of technology because I want to be able to get control and measurement circuits around that thing in some way and then pack them together. So the technology that we've been working with at Google, very similar to what IBM and Ruggeri have been doing, are superconducting qubits, which is to say I've got a superconducting magnetic field that I'm generating in a particular point in space. These are not tiny. If I look at a naked quantum chip, I can actually see where the qubit would be. Now, I can't see the qubit because the qubit's only going to exist at like hard vacuum and much colder than deep space temperatures, but nevertheless, I can see where it will be. It's really quite macroscopic. And the way we use these things, I now know, is visualize, if you will, that the qubit space is sort of a plus sign and with the field essentially in the middle. At each end of that plus sign, I have an opportunity to align another plus sign. And at that interface, I have some degree of coupling possible. The coupling that I can use to create entanglement and to manipulate qubits in multi-qubit operations. And so what ends up happening is the closer the frequencies are of oscillation of the qubit, the more likely they are to entangle, to interact, to couple. And so X-mons, which is the simplest thing to build, this is what we build our largest chips to use, these X-mon qubits, function by direct coupling. These qubits are right next to one another. If you bring the frequencies together, you can entangle them. If you move the frequencies apart, this creates essentially an isolation and a resistance to operation. And on that basis, we can selectively manipulate the qubits. Now, one thing that is interesting for the computer science folks here, those of you who ever written assembly language, try and imagine an assembly language where the only way you can get data into a register is through an immediate operation. You could make a machine like they, it would be awkward, and the compiler would be painful, but you could do it. And that's good, because that's what quantum computers need today. These gate-level models, there is no load, there is no store. There is simply, but however, we can send instructions in that create values. And indeed, the whole operation of a machine is somewhat turned on its head. You've got, the qubits don't move. The qubits are static, the data flows, literally flows through a computer. You've got inputs to gates, you've got outputs to gates. You've got signals going from transistor to transistor. When a quantum computer, at least of the technologies that we're using today, operates, the qubits are staying right where they are. And we are in some sense sending instructions to those qubits so that they will do what we want them to do. In the case of the superconducting devices we have at Google, that ends up being in the form of microwave pulses, very carefully timed microwave pulses that are input to the device. So if you, there is a photo later in my deck if we ever get anything live visually. But you'll see that our quantum computer looks like pretty much everybody else's. A big suspended cylinder, which is essentially a dilution refrigerator, with a lot of cables coming out of it going to racks of equipment. Well, an important element of those racks of equipment is an atomic clock. And we need atomic clocks to keep things synchronized tightly enough to actually function. The gates that we use, and this may have been touched on in the IBM talk. Again, I missed it. There are single input gates and there are multiple input gates, much as there is in classical logic. There is something. Does this mean if we just, well, I mean, I am actually on this slide. So what if we just, well, I'll let you do what you got to do. I'll continue for just a moment. But anyway, there are unary gates and there are binary gates. And in fact, there are multiple input gates. One of the things about these gate model computations is the concept of a gate is relatively virtual at this point. We're still trying to figure out what we need to do. Just as you can build an entire quantum computer, pardon me, an entire classical computer out of nothing but NAND gates. It would be foolish, but a NAND gate is sufficient. No, no, still not there. A NAND gate is sufficient to build any logic circuit, though it would be foolish to do so. To fully gate is, in principle, sufficient to build any quantum gate model system. Ooh. Okay. We are getting close. Okay. Okay. You missed the cute caveman picture, but it's cool. Now, what's interesting is I don't see here what's on the screen. So, forgive me if I look back nervously over my shoulder from time to time. So, here is a diagrams from a paper. There's a reference to it that was published by our team actually about five years ago now. And in fact, the next slide will show you what it's actually doing that is interesting. But I like this because this is showing the execution at a couple of levels. You've got your qubits there. There's three qubits. It was always required to do this particular operation. There is a phase where we're preparing an initial state. Then we are sending various operations out there. You can sort of see these symbolic microwave pulses there along the thread. And what we end up getting is the result. But the result is encoded in the phase of the qubit that we're looking at. Well, the way these machines work is by having a resonator circuit that's close to the magnetic field. That resonator circuit is going to read a higher value, the higher the amplitude of the field. So, in the end, to read anything out of this machine, we have to convert it into amplitude. So, basically, we're running a phase to amplitude conversion in this final step. And then we do our measurement. Now, what was that doing? It was simulating the hydrogen molecule. What the output was the bond energy that varies with the distance between the two nuclei. And so, we're very pleased. Again, this is almost five years ago now, I guess, that they did this. The blue dots on this line are the actual measurements from the quantum machine, the Google quantum machine. The red dots there are IBM's data. They were able to confirm our work. And we're very pleased to see that it took them a couple years longer and they still didn't get as good a resolution. But, all credit to IBM, they put their machines on the web early. Okay, so, again, a lot of respect there, but we do take some pride in the quality of our work. So, perhaps other people have talked about this. I'll address it here in another way of visualizing it because sometimes these concepts, if you're not used to them, it's useful to see things in several ways. It's useful to read a couple of textbooks on the same subject to really grasp the matter. So, here what we're looking at is a computation as sort of a 3D volume.  And those arrows are all pointing out because we've all set them to an initial zero state. And then we start applying gates to those qubits in place. So, you can see some little cubes. Those are unary gates, single input gates. And then you can see some rectangular boxes which represent two qubit gates, operations that are being applied to those qubits. Now, those things can be done within limitations, which I'll get to later, in parallel. And then at some point, when we finish the algorithm, there's a phase where we measure all the qubits that we're interested in. Now, the problem is that every time we do an operation, there is a probability that we're going to deco here. And so, you know, nothing is free and particularly not in quantum. So, depending on that fidelity factor, and depending on just sort of the absolute stability of my system, I have a variable number of steps that I can do before I have to measure, before it becomes highly probable that my measurement is meaningless because something has gone wrong. So, two qubit gates are more dangerous than single qubit gates. They tend to intrinsically have a lower fidelity. And so, part of the art of quantum algorithm development is to minimize the number of intangible operations, minimize the number of conditional operations that need to be done, and put things into unary gates. Another factor of these sort of early machines, like the model I just showed you of the hydrogen molecule, there were some unary gates in there that were really quite complex and really unique to that particular problem. If I'm building a general-purpose computer, general-purpose tool, portable programming, things like that, I'm probably going to want to have some fairly general operations, but because fidelity is relatively low, because my reliability is relatively low, it really behooves me to minimize the number of steps. So, having a large number of, you know, it's one of these risk versus sys things. Sys wins in NISC, noisy intermediate-scale quantum systems. So, we're building these qubits in arrays, and where we are on our particular development roadmap is we're making them larger and larger and better and better, and then there's a certain amount of feedback that goes in, because every time we make them larger, we start seeing secondary effects that we had not observed at the smaller scale. Those need to be dealt with. We get better at the control logic. We get better at how the silicon actually has to be laid out. And so, what we're shooting for in the very near term is what's referred to as quantum supremacy. I'll explain a little bit about that in a moment. But not much beyond this quantum supremacy threshold, we expect there to be some useful applications that people will actually be able to get out of these NISC machines. It's a limited subset of what quantum computing will be able to ultimately do, but there are some of them out there, and we're hoping that will keep a whole sector of industry and a couple generations of grad students going. And so, and then once we get to a certain scale, then we will actually have error-corrected machines. An error-corrected quantum device uses logical qubits, so you're doing exactly what you're doing. Your thought processes of algorithm design are quite the same, but the underlying hardware and one of a better word, firmware, the classical firmware that's controlling the system, is really quite different because to have a single logical qubit that is preserving my value and phase information for seconds and seconds, hours and hours, days and days, I need periodically to regenerate things, and that's tricky because quantum mechanics doesn't actually allow us to make a copy of a qubit. We can measure it, we can teleport it in a certain sense, we can cause it to be recreated by converting to classical and back again, but this basic act of just give me a copy of this and I'll check at some point whether I'm happy, you can't do that. So the algorithms are far more subtle and they're far more expensive in terms of qubits. The better your qubit, the less overhead you have. And this is why various people are taking very aggressive and exotic approaches to constructing qubits in hopes of having a higher fidelity so they can reduce their overhead. We'll continue looking at that, we'll continue working at that, but we're close enough to having something that we think is workable where we're moving ahead, but at today's technology it's going to be about a thousand physical qubits to get a logical qubit. So to get a really good quantum computer, we're going to need large numbers of physical qubits. We're pushing hard and we'll get there. So this quantum supremacy experiment I alluded to is something that's somewhat controversial. I was never wild about it because I'm an old school computer architecture guy and when you build a computer you build it to do something specific and useful. Whether that's weather forecasting or video gaming, it's doing something you know what you want to do. Quantum supremacy, as described by the guys on the team, is a question of, well, first of all, it's doing something with a quantum computer that you couldn't do with a classical machine no matter how big it was. Now as a classical architect I have a little bit of a problem with that because give me enough centuries and enough energy, I could build a really big classical machine. But so, you know, never say never and all that, but nevertheless to show this advantage, to show the fact that there are things that you could do, you could not do reasonably with a classical machine. But then you get to the problem of, okay, I've done a computation on my quantum machine that can't be done on a classical machine. How do I know it was right? And that's where the subtlety comes in. That's where I really respect the guys that worked on this. The notion is that this is a, an example, I don't even know if this is a candidate, but at any rate you generate random circuits. They don't do anything particularly useful, but they're generated according to particular rules. And those rules cause the measured output to have a certain well-defined statistical distribution. Now while I cannot simulate the actual circuit on a classical supercomputer, or Google Cluster is what we use, much the same thing really. We can compute what the statistical distribution is going to be and these statistical distributions have a really nice instability property, which is to say if everything's working I get this very nice exponential looking curve. And if an error happens, this is labeled multiple errors as a flat line, I've seen more recent simulation results that show even a single bit, single error on a two qubit gate will cause the thing to essentially flat line. So you can tell pretty quickly whether it did the right thing. And again, these things being unreliable, the way one tends to run these things, you do a lot of runs, you do a lot of measurements, and you accumulate the data and you look at it. So we can throw away the bad runs, but the point being once we start getting good runs, we know we will have achieved this quantum supremacy. And then beyond quantum supremacy, the exciting stuff is error correction. This is a, at the lowest level, what's going on? The algorithms are really quite complex, but at the lowest level is what's going on. If you can see on that diagram, and for those of you who have no visual, I'm really sorry, there's the little white dots are the actual qubits that are being used for the computation. This is what we refer to as the data qubits. The black dots are essentially what we refer to as measurement qubits and those are just there to see if something has gone wrong. And because we can have potentially both data value, sort of errors, z-axis errors, and phase errors, x-axis errors, then we actually need to have both x and z. So those are the yellows and greens there. So there's a, that actually only looks like two to one overhead, but that's just the beginning because every logical qubit is still going to need more than one of those data qubits. Now this requires a lot of qubits and it requires them in a fairly regular grid to use this kind of a model. And so we got to this hardware-wise in a stepwise manner that is instructive. So if you look up here, there's a diagram you can see. This is a photo micrograph. You can even see the University of California Santa Barbara logo at the top of the picture there. We were using the UCSB FAB line for the longest time because the team is in Santa Barbara. They were from the Santa Barbara research team when they came to Google and they knew how to use that line. And you do not need, as I say, these are course geometry things. You can see the qubits. We don't need the latest Intel TSMC technology to build this stuff. So you can build it on a student line. And so those plus signs are the qubits. The little squiggly lines above them, those are the resonators. That's what you're actually doing the measuring. And then what's coming in from below are the control signals. And so this is a linear array, nine qubits, and here we managed to get the two-bit error rate down to .6%, or a fidelity of 99.4%, which is damped close to what we believe is needed to be able to hit supremacy and start doing some meaningful error correction experiments. And indeed, they've published some work using this device that showed that at least one dimension of the error correction algorithm worked. So we're moving forward here. But I can only make chips so long and thin. Mechanics get us into that material science. So I want to do a couple of things. One of the things I want to do is to fold that linear array onto a vertical axis. So our scheme is to use 2.5D technology, as it's sometimes called in the field, where we actually have two pieces of silicon that we process. And what we do is we put the qubits on one, we put the resonators and the control logic on the other, and we mate them together.  And so there's some bump bonds between them. And again, this is already operating at superconducting temperatures and in a near vacuum. So a lot of the problems that you would have doing this normally, I mean, people do have. This is not an unusual procedure in the industry. It works really quite well. And now that's solved my 1D problem, but now I need to go to a 2D array. And so as you might imagine, what I do is I tile the qubits on one substrate, on one silicon substrate. I align my readout and control logic onto another substrate. I align the geometries. I can sandwich them and that allows me to build chips up to the scale of what I can reasonably do on a die, which is reasonably large these days. So here are some pictures, and thank God I have the deck now, of the first of these 2.5D quantum computing chips. It's called Foxtail. The guys assure me that putting the Google logo across the middle had absolutely no impact on the functionality of the device. Made me nervous. I was in the semiconductor industry for a long time, ages ago, and yes, of course we put our logos on, but they were off in the corner somewhere. Anyway. But you can see this thing labeled, and yes, it had its quirks coming up, but nothing having to do with the logo. But moving onward to what we ultimately want to get to, or not ultimately want to get to, but the next phase, to get to supremacy, to demonstrate error correction, we organized things a little bit differently. So you saw this linear array here, what we did, what we're actually doing is pivoting. We're doing a rotate. We're putting them on a diagonal. Now that might seem counterintuitive and geometrically inefficient, but what that allows us to do is to basically say that I have groupings of qubits that are either data qubits or measurement qubits. So I can use a common read-out line down a set of qubits and know that I'm not mixing my data and my measurement qubits. And so this gives us an architecture where we tile these diagonal strips. The first chip that we made with this was code named Bristlecone. It's a 72 qubit device. 12 unit cells, 6 qubits each. There it looks in the package, and again you can sort of see it's kind of high in the middle because this is one of these flip chip that's posed on the substrate, two and a half D kinds of things. I sometimes wonder who's ever going to see the logo because as I say, it's in a hard vacuum at the bottom of a cryostat. But hey, pride of place. And so here's some photos of what it looks like. And yes, it looks rather more like an automotive garage than a computer center. But this is one corner of the lab. This is the famous yellow fridge. We have fridges in the various primary Google colors as you might imagine. But this is yellow and it is up there. When you see these photos, you always see these things suspended. I don't know if anybody else tells you why, but it's about minimizing vibration. You really got to eliminate as much of any kind of energy that's getting in there. Mechanical coupling, acoustical energy is just as nasty as electromagnetic energy when it comes to perturbing these things. So it's suspended in isolation and huge sets of wires coming out. You can see those racks of equipment. They were still in the process of wiring the whole thing up when that picture was taken. The actual racks of equipment, that rack of equipment is replicated a couple more times down the road to get to all 72 bits. So near-term devices at the scale that we're talking about, getting to these NIST devices, people have talked about, for example, oh yeah, we're going to obsolete RSA. We're going to bankrupt all the Bitcoin people. Sorry, any Bitcoin people in the audience. But Bitcoin is toast once things start working at scale. The good news for Bitcoin is that you need a pretty darn big quantum machine to break RSA for any sensible key length. So you've got a few years yet. But there are things that we can do with order of 100 qubits. And so the most likely things, as has been said, quantum simulation of quantum processes. This is pretty basic. Again, we've demonstrated it for hydrogen, the most trivial case. IBM has shown work both hydrogen. They've done lithium-hydride. I don't believe we publish any lithium-hydride results ourselves yet. Every qubit you add adds additional complexity to the whole, every quantum element you add adds additional complexity to the thing. But this is a promising area. And then another is numerical optimization. Now, numerical optimization covers a broad field. There is just the whole optimization notion along the lines of the quantum annealing that the D-wave does. And there's also machine learning. Machine learning can be thought of the same thing. This tends to be a fairly common looking set of algorithms. And these are things where we hope to be able to do relatively small numbers of qubits and relatively unstable qubits to do that. The model that we have at Google is more one of, we would use classical processing for the first several layers of a neural network. But as things fan down, it'll start reaching the scale where we can actually process them in quantum and use the quantum technology. But this is a conference about open source software. So I want to talk about some open source software. And specifically, I want to talk about CERC, which I don't even know that the guys who wrote it on the phone was possible, but I like it. So what is CERC? Hit the button on my own machine. So it's a Python package, unsurprisingly. Seymour Cray is quoted to have said, back in the 1970s or 80s, someone asking what will people be doing, writing high performance computing programs in in the 21st century? And his reply, which is often quoted in the communities, I don't know what they're going to, what it's going to look like, but they'll call it Fortran. With all due respect to Seymour Cray, and I have enormous respect for Seymour Cray, he was wrong. I don't know what they're going to call it, but it's going to look like Python. So at any rate, but the model is it's, so you have a Python framework and, which was conceived to allow us to have a sort of a, a quantum engine, if you will, sort of as a cloud service that one would connect to, and then provide one's program, and that program might be run on simulations, on classical simulations. We happen to have rather a lot of computers at Google, and we have some parallel simulation algorithms, and we can simulate pretty large systems on those machines. But as the quantum hardware comes online and the quantum hardware gets larger and larger, then, you know, we start having more capability, and certainly you'll run out of steam in that sort of 30 to 40 qubit range. Because remember, every time I'm adding a qubit, I'm doubling the possible state space. So just going from simulating 45 qubits to 46 qubits, all of the things being equal, I need twice as much memory and roughly twice as much processing power. So hence the appeal of this. So there are reasons why I described a lot of how the machine works, because the design of CIRC is built around the requirements that come out of these sorts of machines. For example, I know some of you actually, you know, could probably eyeball this and know what I'm talking about. Well, here we have a set of controlled Z gates across a set of qubits. Okay, I have nine qubits here, A through I. And you look at this, is this a good quantum circuit? Well, let me put it to you this way. Would this be a good assembly language program? And those of you who have an I for data dependency would probably say that's a dreadful program, because you have a linear chain of data dependencies going right down the line. Well, guess what? In the quantum universe, it's a similar problem. I've created a gate depth that is not good, because as I mentioned, the stability of my qubits is time limited. I need to do things as quickly as possible and as much in parallel as possible. So how about this? Is this a decent circuit? Because here I've broken things up. And so this would be a big improvement if I were running this, say, on a Intel or some other classical microprocessor. This is a little, I'm scheduling the registers, I'm scheduling the pipeline a little bit. And in the quantum sense, yeah, I visualize that this is what's going to happen, that I can do four in parallel and then the other four in parallel. But I didn't tell you what the topology was. And the topology matters. Cubits that are in contact with another can be entangled easily. There are swaps that you can do. You can move these things around by various operations, but it's inefficient. But fundamentally, these operations can only be done on adjacent qubits, on one axis or another. If it were a linear array of nine qubits, like the picture I showed you, that would actually be a good program. But for a 3x3 grid, it's not. Because F and G and C and D are rather too far apart to actually do those operations. So no, it was not actually a good circuit. Okay, third try. I know that I have a 3x3 grid.  I can do those four and those four in that order and so this ought to be a two-step process. But again, life is not so simple. There are things that you can't actually do. And we have to protect certain qubits. Now, why is this? The way we do CZs on an X-mon device, at least, is we bring the frequencies close together. As you heard me mention, we get this coupling when the frequencies of oscillation of two qubits get close to one another and they're isolated from another if you shift the frequency away. So the way we actually perform the operation is to bring to the same frequency, the ones that we're interested in working with, but we're also going to take the other surrounding qubits to frequencies that are further away. Because we want to introduce any, and I don't want to use the word ancilliary, even though that would be a correct English word. It's an overloaded meaning here. But all the bits not involved, we want to keep them at frequencies that are relatively far away. And what that means is we can't just do arbitrary operations on the grid in parallel. We have to take some care of this. And so on this particular 6x6 grid, to actually do a CZ along every edge, it would take eight steps to make sure everything was properly isolated. So these are the kinds of things that we are playing with. These are the kinds of things we're experimenting with. And so we need to be able to get at that level of detail in the programming of these early devices. We need to be able to do algorithms, but we also need to be able to actually do experiments on the systems themselves. So we need a relatively low level language. And so there's this sort of range here of levels of detail and complexity and abstraction that these proposed quantum languages have. CERC is very deliberately pretty low level. I think the biggest contrast will be with Q-Sharp. I don't know if Microsoft or anybody working with Q-Sharp was in here today, but Q-Sharp, it fits into Visual Studio, very cool. But it is a high level language, and it pretty much presumes that you have logical qubits, pretty reliable qubits to work with. So we're down on the low end of this range. So here's just a trivial case. I'll take just a slightly more interesting case in a moment. So you can generate qubits. You can generate circuits built from those qubits. You can put operations into that model. In the trivial cases, there's this circuit. There's the from-ops method, which I basically provide a long set, a variable length, a number of described operators, and it will populate the array with them. You can do it incrementally if it's a more complex thing. And of course, this being Python, you have to be able to print it. And when I print a circuit, we get these sort of cute ASCII versions of the circuit model diagram. So the structure of the tool is very modular. I think this is pretty important. So there is a circuit area and a schedule area. User code will typically go in and it will generate circuits. And those circuits can be saved and expressed in various formats. So ProtoBuffs is an internal format. RPC is basically Google generic RPC payload. We can save it as various people's chasms. We can print it out as text diagrams. And so various formats can be done there. But then, of course, operationally, those gates have to be played on the machine. And as I showed you, directly playing the qubits onto the machine may not be what you need to do. There are rules. There are constraints. It's like the old risk processors where the compiler had to schedule instructions around conflicts. You had branch delay slots. And if you couldn't put something useful in the branch delay slot, you had to stick a no op in and pad things out. You had low delays on the original Berkeley risk that were visible and the compiler had to deal with them. Well, it's a similar thing. But we've separated out the circuit and schedule. And that's a concept that you'll find throughout CIRC. So typically, just writing and running a program, you have the path through that is just going, you generate a circuit, generate a schedule, send it out to the machine or the simulator. But you can also use it as an optimizer. You can read chasm. You can also use the optimization modules at the circuit level. And then you can write it back out again. And I'll show an example of that in a moment. We can also do transcoding. And I suppose you could argue that that's what that initial example did where I just sort of generated something and said print. But the circuit and schedule dichotomy permeates the thing. And the notion is sort of circuit is a discretized sort of a thing. You basically have operations. Operations are essentially a binding of gate to a qubit. And at the level of a circuit, you're really not concerned about timings and durations. It's just things and they're ordering and the schedule is continuous. So that's made up of scheduled operations. So operations what ties the whole thing together, but they're operating in a couple of different domains. Now one example, and this is a nice simple example that fits on a page but does something comprehensible and almost useful, is the one bit calculator. Now it's not hard for me, just with transistors on a piece of circuit board, I could create a one bit adder. That's fine. But this one bit calculator is actually calculating all possible additions at once. And so it's actually, it is executing in parallel. It's doing four operations concurrently. So my top two gates are, my top two qubits are going to be the inputs coming in and then the bottom is an ancilla. So what I'm doing is I'm using Hadamard gates. Hadamard gate, if I'm coming in with a zero state initially, is going to put something that's in a super position that is exactly between, is equally zero and one. An important tool. And then I'm going to run that in a Tifoli gate, which is, again, a conditional, conditional knot. And then I'm going to run it into a conditional knot gate. And what I'm going to measure is the ancilla that was involved in the Tifoli gate and the qubit that was involved in the CZ gate, not the controlling element, but the data element. And so that in principle should do all this simultaneously. So I don't know how well you can see this. This is in the deck if you want to download it. This is actually not too unreadable. But here's what it looks like, as you've seen in several of the other examples. We're importing our package, picking up some additional things I'm going to need later when I actually plot the thing out. But one of the things you'll note is that I'm generating my qubits and I'm generating them as grid qubits with certain coordinates. Now, the earliest versions of CERC did things a little differently. The earliest versions of CERC were actually rather similar to one of the other talks that happened a little earlier, where when you create the qubit, you specify what kind of qubit it is. And so the earliest versions of CERC, the earliest versions of this program, it was CERC dot Xmon qubit. I'm just generating Xmon qubits. And then I would take those Xmon qubits and put them in an array. But the more we work with this stuff, the more we understand that topology is more important than technology. Technology matters, but I may want to have the same topology, but have different implementation technologies on me. So this is very interesting in terms of quantum languages, because we're still figuring out what the appropriate points are to bind things. And so, again, earliest efforts, early binding of qubit type, and then now we're taking it up a level and abstracting it a little bit more. So I generate my three qubits of this type. I generate a circuit from the operations. So I have, essentially, you'll note that I say CERC, I imported the C naught and Tifoli. Those aren't there automagically, but they're part of the standard libraries so I can import them. And then the Hadamard is so fundamental, it's just there as a built-in. And so I attach the Hadamards on Q1 and Q2. I do a Tifoli of 1, 2, and 3, a C naught of 1 and 2, and then I perform a measurement on these things. And then I print the circuit, and I print the circuit. Now, this actually is screen capture off my workstation, so I know darn well that this is not cheating. So then, having had the program instantiated, now I'm going to simulate it. So I instantiate a simulator, and this is where the X-Mind binding came in. I say, OK, now I actually want to run this simulating X-Monds. And then I'm going to run that simulator on the circuit for some number of times. These are statistical critters, as has been observed before. I can have a lot of states superposed, but for every qubit, I can only read one of them at a time, and the rest of it just sort of collapses.  And so it worked, which is to say, if you think about adding two bits together, then two ones is going to give me this, two zeros is going to give me that, and zero one or two zero, in other words, two possible combinations will give me this. So this trivially works, but it's a very easy package to use. Here is an example of optimization. I did not personally run this. This was somebody's prototype optimization method, but it worked pretty well, which is to say we started out with this kind of awkward looking gate diagram. But the important thing to understand is all of those vertical bars represent two qubit operations. Those are all intangible operations. And so by optimizing, we've taken that from six down to three. And because those are the operations that contribute most to my loss of coherence, that's a really, really big deal. So thanks for your attention. I will leave this up here as long as I can get away with. You've already heard about OpenFermian.  ETH in Europe, they were a big contributor to this. University of Oxford, as well as the two main European institutions involved, as well a number of US universities and national laboratories. It's out there. Play with it. Then CERC is also off the GitHub slash quantum repository. It contains its own little simulator. It's very self-contained. There's a startup page that's pretty trivial. You install the package and you can just follow the sort of steps that I did there. So thanks. I'm probably over time with all the technical hiccups, but hopefully the organizers will tolerate my taking a question or two.


In this presentation, we're going to record an advanced customer payment or a prepayment or a deposit from a customer into our accounting system. In other words, we're going to get money from the customer before the goods or services are provided. Time to rise above the crowd with Sage50Cloud accounting. Here we are in our Get Great Guitars file. We're currently in the customer and sales section. If we go down to the flow chart in the customers and sales section, we note that the normal flow of things that will typically happen in most businesses are either we're going to do the work and then build the client, in which case we'll receive money in the future. That's going to be typical for like a law firm or a bookkeeping firm or a landscaping firm or something like that where we actually do the work, we count the hours, we see how long it's going to take and whatnot. Then we build the client and we expect payment after that invoice or bill has been created or something like a restaurant or in our case the guitar shop in the store where people come into the shop, they buy goods and services at that point in time and we get paid at the same point in time. Those are the typical two ways that we receive money or the flow of money within the service that's going to be coming into the business from customers. However, it is possible that we receive payment before we do the work. That's more unusual type of business. It's actually becoming more and more usual in terms of a standard type of business and it also could be just some transactions within a particular business. For example, whole types of businesses that run that way would be something like if you sell newspapers or the magazines, those used to be the typical kind of methods that would use that method where you sell the subscription, you get paid before you deliver one newspaper or magazine, then you deliver the newspaper or magazines and you earn the revenue at that point in time. That model is also a model that's very more in use now with the applications, computer applications in which case you may sell a year's worth of computer applications to people and they pay you before you actually provide the apps, things like a Netflix or something like that are getting paid before they provide the service. That's another area where it becomes something that's going to be there. A lot of concerts are concerts are also a big area where of course you're getting a lot of money before the actual concert is on and you have to deliver on the concert before you have actually earned the money. In a business such as ours, we might have certain cases where that's going to happen such as a security deposit on a certain type of purchase. For example, if someone, this is our scenario, we're going to imagine here someone comes into our shop, they want a particular guitar, we say great, we have this guitar here, they're saying no, I want it in green with a nice strap on it and this one's like blue and I don't want that color and we say okay, we're going to buy it from our vendor, we'll go to our vendor, we'll buy you the guitar and make it the right color with the little strap on it and everything but you have to give us a security deposit now to make sure that we buy that and it's going to be specific for you because we don't really sell that color and that strap doesn't, you know, like in our shop so that means then they want, we want to get a down payment so that's going to be the down payment. So in our case, we're going to get a down payment and then we make the purchase, the down payment securing that the sale will be completed because there's been a commitment for it, then once we get the inventory, we will complete the process. So you can see this is a bit backwards now. That means that we're going to have to enter the, we're going to get the payment first, then we're going to enter the invoice that will match out to the payments that we got later. That's backwards. Okay. See the arrows are going this way and we're like going the other way. That so, so that's what we're going to have to do now. We're getting this prepayment. So we're going to use the same form. We're going to use the receive payment form. We're going to say receive payments here. Going to make this large. We're going to say this is coming from Anderson. I'm going to make the ticket and I'll say this is coming from Anderson, one of our current customers. So, and we're going to say we trust you Anderson because you've done business here before, but we still would like a deposit. And I'm going to go for the check number and the receipts number. And we'll say this is on the, I would say the 17th. Go with the 17th this time. And so the way we do this is we're going to say, Hey, this is a prepayment. So I'm going to check this little prepayment box. That's the key. This is the key, the prepayment. Notice it jumped back over to the right. There was an invoice out. We're not tying out to that invoice. We're making a prepayment here because it was jumping over to the left. So I believe there was an invoice in any case, we're making a new prepayment. So then we're going to say this is a description payment. Payment prepayment on guitar, we might something like that. And the amount we're going to say is 250. And you'll see the rest of the fields are grayed out. We can't enter an item or anything because it's a prepayment. That's the point. This is going to be increasing the cash on hand.  We got money. We owe it back to the customer until the point that we actually complete the service at which point then we have earned that 250 as well as any other price on the guitar. So let's go ahead and save this and take a look at it. We're going to save this. Let's open up our financial statements. I'll open up the balance sheet this time. Going to the reports drop down, going on down to the financial statement. Then we want to go to the balance sheet, double clicking on that balance sheet to open it. We want to take the range. The current period looks good to me. So that's the one I'll keep in February. We want February. So we will open that up and so then we can see the 250 here. If I was to double click on that 250. So there we have, I mean, there is our information, the 250 in the cash on hand, the other side then going, you would think now, if you're in financial accounting, you're going to say, Hey, there should be a liability down here that says undeposited funds. Now, logistically, a lot of times that's kind of an issue. That's kind of a problem because if we, if we use a liability account down here, then it's more difficult for the computer system to tie that out to the sub ledgers that we want to be tracking by customer. In other words, the 250 needs to be tracked to an invoice. It needs to be tied to an invoice. And the account that ties to invoices is typically the accounts receivable account up top. So a lot of times, a lot of systems from a logistical standpoint will actually put the prepayment as basically a negative accounts receivable account. And that makes it so it's going to be easier for us to tie to the invoice in the future, as well as create sub ledgers that will be able to track that information using the same, the same system. So if we, in other words, once again, same, same concept, if we made a liability account, then we wouldn't be able to tie it as easily to the sub ledger to the customers. And that's really difficult for people to learn. If you go through it like financial accounts, you know that well, that's not proper. There should be a liability account. It shouldn't be a negative receivable account. And, and it's not something you kind of often pick up in financial accounting because they don't really put that part in place. But a lot of systems will actually do that. And it works well to have the negative receivable as long as you recognize what is happening. That's what's happening here. If I go into the accounts receivable, we're going to say now we have this, this negative amount. So in other words, we have a credit here. The credit usually is going to be tied out to a debit that happened in the past, right? Accounts receivable goes up and then it goes back down. This is resulting in a negative receivable. It's resulting in a credit that's not tied out to any, any increase in the receivable that shouldn't happen. Theoretically, it should go into a liability account, but it works well here because that allows us to tie the invoice to it later. Well, now it's not correct in terms of financial reporting here because if I look at this, I'm going to say, well, you know, this accounts receivable is wrong. It should be higher and there should be a liability account, but just remember, it's just like any other kind of adjusting type of entry at the end of the month, you can do an adjusting entry and adjust things from a logistical standpoint that works well logistically to what is correct on an accrual basis as of that point in time. It's just like any other adjusting entry that you put in place, right? We don't worry about depreciation every day that should be recording. We record it at the end of the month because at the end of the month, because that's going to make it right periodically. And so logistically, that makes sense for us to do. Otherwise, it would be too tedious for us to be recording depreciation every second that passes as something gets depreciated, right? It's a similar kind of method here. It's logistically convenient for us to track this way. And then we can make an adjusting entry at the end of the time period to take it out of the receivable and put it into the liability account periodically when it's necessary for financial reporting purposes. So that's going to be that. If I take a look at another report just to just to consider this more fully, if we go to the reports dropdown and we look at the receivables report, we want to look at the customer ledger. The customer ledger is going to show the customer with detailed transaction information. So if we double click on that item, then you'll see Anderson here up top and notice I'm in on February. Now, Anderson already had an invoice outstanding. So Anderson still owes us money. In other words, the receivable isn't negative, but this 250 doesn't apply to any invoice, right? So that this is a credit that doesn't apply anywhere, anywhere out. And that could result in negative receivable accounts, meaning it would look like Anderson owes. It looks like we owe Anderson money and we do. We owe Anderson money or we owe them the guitar. So this amount is actually wrong until we create the invoice at some future point in time. So if we happen to hit the cutoff date at the end of the month and this had not yet cleared yet, we saw that timing difference. That's when we would create the adjusting entry that would create the liability account and remove the 250 from the accounts receivable, increasing the accounts receivable. So that's going to be it for now. Let's get out of here.


Shame is another kind of force, actually, it's the force of do it or else, stop it or else. And it originates in modern parenting methods that leverage the child's mammalian need for parental acceptance and the child's mammalian fear of parental abandonment. Punishment, it's not so much the physical pain that is effective on the child, it's the obvious repudiation of the child in that moment. So this is a type of primal force, it's the force of a gun to your head, do it or else, because that is the survival fear that is triggered through punishment. Or even like approval, when approval is used manipulatively.  Actually, there's one other part of shame, though, all of these expressions of our separation also have a seed of something else, even shame in a healthy culture.  And when that is exposed, the false self image dissolves, liberating heat, and there's a flush to the face. And if you're being held in total unconditional acceptance, then you're free to have that experience and to realize where you have been out of alignment with who you really are. However, like so many beautiful and good things that has been perverted into an instrument of aggression, oppression, control, domination, and that's actually a kind of a trauma too. You know, we can talk about the aces and the overt trauma, but in a way trauma is normalized in our society. And none of that happened to me, but on a more muted level, trauma is pretty much written into the fabric of our civilization, because it draws on paradigms of the conquest of nature, the conquest of the self rising above materiality, spirit and body in opposition, like all of these deep paradigms that are changing right now.