 and tends to behave a little bit better at times. But overall, this topic is going to go on what it means to be open because silicon as a topic is something that a lot of people don't really know about. So the concept of what is open silicon requires a rather lengthy amount of discussion. What can we do today with the current state of open tools? What can't we do today? And where can we go from here? So to begin with, what does it mean for silicon to be open? Broadly, there are four things that need to happen for a system we considered completely open. To start us, we need manuals. If I give you a piece of silicon and there's no manual whatsoever, there's not much you could do with it. So we need to know things like characterization. What voltage does run out? Where did the debug pins come in? What does the memory map look like if it's a CPU? We need the source code to the CPU, which includes things like the veriloc or the VHDL or the scallop that went into actually defining the CPU. Even if you can't do anything, but even if you just have the source code, there is some value into seeing how the CPU is built. As an example, there's a chip called propeller, which has 16 cores in it, and they actually produce the actual release, the veriloc for the CPU for an actual physical chip you can buy. Also important is the tooling, I probably spoke earlier about the open-lane flow. But if I give you a piece of silicon, if I give you a C program, and I don't give you the compiler, there's not much you could do with it. So it's important for a chip to be considered open if you have the tooling to actually do something useful with the source. And finally, the GDS2. How many people here have ever built a PCB with chuck of hands? How many people have ever made a PDF file? A Gerber file is a PCB. It is the output that you send to the PCB file. A PDF is a file that contains everything in your document or the symbol of the document that you send. The file is going to be the same regardless of what platform you're on. GDS2, sometimes called GDS, is the file that you send the foundry that they will then turn into physical silicon. So if somebody has a GDS2 file, they have everything they need to give the foundry to copy the chip. And this is some of the most rare stuff when you want to make an open chip, because it means that anyone can just clone it. So in terms of chip design, there are more or less four different steps to making a chip. For starters, there's non-explosive agreements, which are required because the foundry has put a lot of money into building their tools, and they don't necessarily want the competitors to know what they're capable of. There's also a lot of other characterization that goes into it, which is the process design kit. So this is when you make a silicon chip, you run it through hundreds of machines. And each machine has a different tuning. And the actual tuning of the machine means that the output will have slightly different characteristics. And that is all very proprietary for each individual foundry. And that is the resultant in a process design kit. This is an example of a stackup. So what this is is five metal layers of polysilicon. And so with this, you can tell that at this particular foundry, this is what the different layers are. And so this is what you have to work with. On top of that, you need software to actually generate the tools. This is that tool that goes from the source code to the GDS25. And it consists of a bunch of different things, synthesis, power generation, clotry synthesis, place and round, verification, simulation, and a whole bunch of other things. The thing is, this costs a million dollars per seat per engineer. So this is completely cost prohibitive to any sort of open source project. And if we want to be able to make our own chips, we're going to have to replicate all of this in order to have an NDA3 and open process. Now, I want to talk a little bit about synthesis, because that is the first step in here. And that is the side of this tools that users most directly see. I'm going to talk about them in a little bit. The first IP blocks are another thing you're going to need to build a chip. When you write a program, you go to Node, NPN, or a cargo, you pick up a library. For example, if you want to do a JSON parser, you don't want to write a JSON parser. You want to get a validated JSON parser that does what you want, because you really want to build something that is doing your processing of a post or something like that. You don't necessarily want to be in the business of writing JSON parsers. In Silicon, it's the same way. We go to IP blocks, which are kind of libraries of pre-bedded, pre-tested, silicon blocks. You can just drop on your chip, like a library. An example is a PCI Express version, which is a really complicated piece of hardware. It's a lot of timings, serdesis, all the configuration that needs to go. Radios are another example. If you want your chip to have Wi-Fi that you're going to need to get that tuning from a library vendor who, hopefully, has tested out in the particular founder you're working with so that it's guaranteed to work the first time. And then there are standard cells. And these are the tools that most people interact with, although they don't really know it. So I am going to go in a little bit about standard cells. But first, a quick side detail on Boolean logic. Think back to your secondary school. You have Boolean logic is what underpins most of the CPUs, most electronics, much digital design these days. You have your P and your Q on the left side, and you have all these gates. And this is a truce table. Basically, it is a piece of silicon that has inputs on one side and defined outputs on the other side in a combinatorial fashion. In the old days, way back in the 1970s, when you designed a chip, you would design it with a pen and a piece of paper. And a room full of people just sitting down for weeks designing each individual transistor. They were designed each of the metal layers by hand. And then they would image it and project it onto a piece of silicon. It was very time consuming. You couldn't scale it very high. This thing is only, I think, about 10,000 transistors. And if you make a mistake, it's kind of a big deal because you have to erase everything and start over again. So it was fine in the 70s. It was becoming a kind of fell out of favor in the 80s. Nowadays, we do chips like this. This is a GD32 gigabyte, a relatively modern farm chip. And if you look at this, you can see we have, this is the section of the chip. We have memory in purple there. Those are all IP blocks that came from either a foundry or an IP vendor. And then we have logic on the side. And you can see we call this kind of a sea of gates type thing. All of this logic here is code that was written by either a human or a text generator or a code generator that is then compiled down using a synthesizer. So when we say we designed a chip using Barlow, this section right here, this purple section right here, is all of the logic that is resulting from writing Barlow code. So the synthesizer, you can see, is generating a third, the two-thirds of this chip. And it's a fairly big section of it. Zooming in, if you were here at the prop, you'd have seen something like this in the generator code. This is zoomed into that logic area. And you can kind of make out these vertical tracks where they just line these standard cells up one next to each other and then run the wire. So when you place a route, this is what it looks like in real life. It's a real-life consequence to what we do. And we strip away another area of memory. You can actually see this is the low polysilicon layer. So this is what it looks like in real life. So today, we do something like this. Rather than wiring up transistors by hand, we do a Barlow module like this. This takes input A, B, C, D, outputs X, and the actual mathematical operation we're doing is A and B and C and D. And the job of the synthesizer is to take that and turn it into gates. It may be that your standard cell library that you got from the founder or whatever has two input ends, in which case the synthesizer would do something like this. Two A, B could end it together. C, D could end it together. Results of those get ended together and you get your output. But it may be that your boundary has a four input end. And so the same synthesizer would take those inputs and end them all together in a single step. So in a sense, the process, the standard cell library provided that you're using has a direct impact into what the synthesizer goes and does. But also you could put both of these in the standard cell, in the digital design section. It's whichever one happens to be fit better. Having said all of that, how we get to the meat of this, where are we now in open source? Well, these are actually looking pretty good. Non-disclosure agreements, we don't have to really do that. Everything here is up on GitHub. Everything is freely available and downloaded. No NDA is required for open PDKs. We actually have quite a few. We've got Sky 130 and GF 180. These are primarily the, so Sky 130 is from Sky Water in the West. GF 180 is from Global Foundries. That's 130 and 180 nanometers, respectively. SG 13G2 is from Austria. That's relatively one. And we have this interesting thing where we actually have fake PDKs. PDKs that don't actually correspond to any particular boundary. This is kind of an interesting artifact of how, remember I mentioned that everybody in all the non-disclosure agreements are important in design. If you're publishing a paper as an academic, you need to be able to have reproducible results, but you obviously can't publish the PDK because it's completely proprietary. So they have fake PDKs that they generate that you will see used in papers. And these are kind of a stop-get that they've invented to get around with that. Well, the great thing is we have real PDKs we can use now. So this is gonna be a boom for academics because it's no longer just a fake thing they're doing. They can actually use real PDKs. For hardware synthesis, anybody who's done any FPGA work will have used YOSIS in the open source world. YOSIS primarily deals in Veralog, which I showed earlier. There's also VHDL, which is handled to a point called GHDL, and System Veralog, which is what a lot of microprocessors are written in as support as well. In terms of placement and routing, this honestly produces the greatest picture. So if nothing else, it's good for that. Placement, routing, power distribution, or clock distribution network, this all comes from a tool called OpenRoad that basically exists to take existing projects such as OpenSTA or Static Timing Analysis, and it pulls them all together into one very crazy-looking GUI. In this case, you can see the lines there are the clock tree in this particular chip. As for inspecting the output, you have your PDF viewer to view your PDF. We've got K-Layout and Magic, which are capable of inspecting the resulting GTS file. And this is a chip that I routed, and you can actually see, again, the lines of standard cells in here. It's taken all the logic from this particular CPU and stuffed it into lines that are filled with those standard cells. And it is for available IP, not that's one of the other things we needed. Thanks to the OpenMPW project that Google has sponsored, there is a lot of IP available. So we have CPUs, we have the FPGA that you mentioned, those mentioned earlier with an SPI, USB, crypto accelerators like APS. We have some analog IP for things like analog to digital controllers and phase log loops. So those are all available as well. The standard cells we actually have a few different flavors. We've got SkyWater 30 from SkyWater. We have GF18. We also have this thing called OSU 018, which comes out of Oklahoma State University. And we also have Libre Silicon, which comes out of, I believe, Hong Kong. And the interesting thing is you can use these standard cells with other process design kits. So we've actually had OSU and Libre Silicon ticked up in global boundaries. It's great that we can do this, but there is a lot of stuff that we can't do today. Memory is still rather hard. The density is improving, we're getting better. But for a tiny three by two millimeter chip, you can expect a few kilobytes on the chip, which is kind of unfortunate when you compare it to like modern CPU where you have megabytes of cash. We just can't do that yet. The hope is over time we'll get better density. And we do have experimental ROM support, which should remove some, should shrink ROMs down to someone. But here's kind of a sad example of this. Here's a CPU I did with, let's see the registers are, the memory is everything in red and the CPU is kind of that block right there. To be fair, this is kind of a contrived example because in this case, the CPU was designed to be small and these memories are all five volt tolerance. And this is kind of, but the point is memory is still really hard. They said that the OpenRAM project is designed to pack memory as tightly as possible. And oftentimes memories actually violate the design rules because they're regular enough that you know you don't have any interaction between nearby transistors. And so this is an example of just 16 kilobytes of RAM at 3.3 volts on Skyroland 30 from the OpenRAM project. Non-volatile storage is also a bit of a problem. We don't have anything like flash or EEPROM. Skyroland 30B has resistive RAM, RERAM, which is still somewhat experimental. There are modules to put down, but that is specific to Skyroland 30 it hasn't yet been ported to some of the other platforms. Kind of the solution that we're working with now is just use an external SDI flash. I mean, this is what a lot of processes are used today actually, big devices and ESP as chips don't have on-chips spy on-chip flash. They all use external spy flash. So it's not really a problem, but it is a thing to look out for. The other issue is that I've mentioned Skyroland 30 and GF 180, these are relatively large nodes. Wikipedia has this great section on what designs were common on these nodes. The PlayStation 2 was at 180 nanometers in the great year of 2000. The Gamecube was in 2001, was on 130 nanometer. Having said that, the Gamecube and the PlayStation are really great machines. They did a lot of interesting stuff. So even though we're not on the latest five nanometer process, three nanometer process, there's still a lot we can do. There's still a lot of work to be done. There's still a lot of value to get from these large nodes. And in fact, just because it's a large node doesn't mean that it's a bad node. I mean, here is an LED flicker. This is dashed out again courtesy of Zepto bars. This is a digital chip that basically emulates a candle flicker. That's all you can see. Again, the tracks here are the digital logic. This is 3,000 nanometers, three microns. So you don't need a super tiny process to do something interesting in open silicon. You may not make the latest and greatest fast processor, but you can still derive valuable from this. Because one of the other issues is that analog IP is still a little bit difficult. We have a lot of work on the digital section, but unfortunately analog is still kind of an unsolved problem. We do have some ADCs and PLLs, there's a band gap generated, somebody did, but it's still somewhat difficult to integrate that into your project. There are various projects to solve that, such as Viewsoft as an example of an IP curation project. But analog IP is unfortunately still one of the blind spots in open software, over hardware. And of course, in the elephant of the room, taping out chips is still kind of a problem. Google occasionally does open MPW runs with the caveat that any design you put on open MPW must be released as a fully open project. If you don't want to have a fully open project, it wants to keep your IP closed for whatever reason. Other companies, Chippick Night, EuroPactus News, SIMC, and plenty of other foundries run multi-project wafers, where they amortize the cost of one wafer, which is several million dollars, across multiple projects. But even so, it can still be 10 to $50,000 or 10 square millimeters of silicon. So if you can get on something like the Google MPW or open MPW, or hopefully you can find somebody else who would be willing to fund this for the exchange for getting open IP. But for now, unfortunately, this is the reality. So thanks to that, where are we going from here and how can you help? Well, the hope is more open projects. So this is a screenshot from one of the open MPW projects. They run occasionally. I don't think there's one open right now, but if there is one, you can help by getting in on it and learning more and submitting a design to grow the pool of IP that we have. Education has benefited a lot. And so education will be getting a lot more with the open tools. I know I was speaking with some academics who were running entire courses using the open road, open lane flow. And one of the nice benefits they have is that they didn't have to have their students sign an NDA, normally when you're running a classroom, one machine that is running some version of the proprietary vendor tools and everyone has to connect to that, which can be rather challenging when you're off campus or when everyone's accessing at the same time or running their place around synthesis at the same time. So allowing students to run the design tools on their machine with a PDK that they can get without any NDA has been huge. There's also the tiny takeout project that was mentioned earlier. They divide one of these chips into 250 subchips. And so for $25, you can get an area on a chip. It's about 1,000 gates, so you can design, you can see little tiny scripts of cells in here. $25, it's a deal for your own chips. It's also part of the zero to ASIC course, which is another resource you can go to if you want to learn more. And I'm hoping we can get more analog design because there is a lot of interesting things you can do with digital. There's simulators, there are generators for digital. But analog, again, is still somewhat of a blind spot. So if you want to help learn more about analog and create analog IP, there's a website called Silly Lids that has a lesson plan that you can use. This is actually an example of a PDK running in the browser where you're actually drawing on a virtual GDS file and runs a physics simulation in the browser. And it's great because you can see in real time what changes get made. This change will affect the voltage in this way over time. Hopefully that someday we get a smaller process from other notes is more wishing. Open NDA, open road has been tested on smaller process notes. They've taped out upon Intel's run two. They've taped out on GF1, GF12. But unfortunately, there's no deep sub-micron NDA-free PDKs yet. Sub-micron is anything under 100. It would be really nice if we had an open PDK that was 45 above, but unfortunately, we don't have one yet. So hopefully we can convince some counties that SkyWater and Global Foundries have released their older notes. They haven't done that business yet. Hopefully we can convince them that some of the smaller notes are worth opening up so we can actually have smaller PDKs to work with. And finally, just more involved. Get involved in open MPW, do a tiny tape out, learn about SillyWiz. We need more people to realize that this is now an open section of design. And you too can become a chip designer thanks to these open tools and make pretty pictures. Thanks. Any questions? Questions, anybody? No, the question will come into that. I can suddenly see the reason why I'm wondering about it. No, so no. Yes, I'll leave it at the end of the question. Any of this, now that you're closed up, maybe at work or going further long or doing new things with blocks, doing AC stuff, is there progress being made on that area? I know that's like a really hard area for fighting with FPTAs. Ooh, AC, I'm not aware of any ACM CPUs that have done in any open tools. I know that many of the simulators that exist. For example, iVerilog, which is one of the Verilog simulators, it's really unhappy with a lot of AC stuff. Verilator just gets rid of it, so it doesn't matter at all. You would need to do something like Spice, which does exist and would work just fine, but I don't know of any Verilog to Spice. It would be challenging to get working and I don't want that anybody has, but the tools are all there. I don't feel like loading them together. All right, if there's no one for the else. Thank you, John, but thank you for the session. Thank you. Thank you.