[00:00.000 --> 00:11.640]  Welcome everybody. It's amazing to be back. It's amazing to be back in Brussels in person
[00:11.640 --> 00:18.960]  and see that many people here looking for an answer to the question, can we do an open
[00:18.960 --> 00:27.320]  source chip design in 45 minutes? And to save you all the hassle of actually just listening
[00:27.320 --> 00:41.760]  through this talk. Yes, we can. Thanks. Let's be great and enjoy Brussels. Or if you want
[00:41.760 --> 00:51.160]  to know more about how that actually can work, stay here. So we're going to look at technology.
[00:51.160 --> 00:56.240]  Obviously, this is for them. We're going to look at tools and process how to build an
[00:56.240 --> 01:03.320]  open source chip. We'll be looking at community because this is for them. We want to talk about
[01:03.320 --> 01:10.760]  the people and communities behind all of these efforts. And we will predict the future. Let's
[01:10.760 --> 01:15.800]  see how that goes and we'll see some examples of where that potentially went wrong in the past.
[01:15.800 --> 01:27.440]  So standing in front of you today is Philip. I'm a hardware developer. I've been doing a fair
[01:27.440 --> 01:32.320]  amount of software. I've been involved in open source for a fair amount of time. I gave my first
[01:32.320 --> 01:39.120]  foster target just looked 11 years ago. You find some contact information there. And I'm currently
[01:39.120 --> 01:49.680]  working at this company here. I've been doing chip verification for high-end mainframe CPUs. So
[01:49.680 --> 01:56.120]  that brings all the new together, actually. And I'm also a maintainer of the open source
[01:56.120 --> 02:02.160]  Cocoa2B project. And we'll get into that in a second. Previously, I was working at Lawrisk and
[02:02.160 --> 02:08.440]  open Titan. Again, to buzzwords just for you to Google if you want to. So open Titan is a
[02:08.440 --> 02:14.600]  security chip fully open source that you actually can get involved just like any other software
[02:14.600 --> 02:23.920]  community. I'm here today representing the Fossi Foundation. And this is a foundation there to
[02:23.920 --> 02:32.040]  kind of steward and take care of the open source chip design movement. It's based on individuals.
[02:32.040 --> 02:37.560]  And it's a non-for-profit registered in the UK. Also has been around for quite a while. And was
[02:37.560 --> 02:44.840]  initially born out of the open risk movement that did a open source processor CPU core back,
[02:44.840 --> 02:53.400]  probably, I don't know how many years by now, 10, 15, something like that, before risk 5 was a
[02:53.400 --> 03:09.840]  thing. So that's it for the introduction. Let's go into the technology. How do we build a chip? There
[03:09.840 --> 03:16.600]  are two main things that we need. First, we need to think about. We have an idea. Obviously,
[03:16.600 --> 03:22.680]  that's where we start. But then at some point, we need to implement the functionality. We do
[03:22.680 --> 03:33.800]  that. It looks similar to a regular programming task. So this is the logic design part. And that
[03:33.800 --> 03:40.320]  one is pretty well understood these days. Also an open source. We'll see why that is the case and
[03:40.320 --> 03:50.120]  why that has been thriving for many, many years now. The second part is the back end or the physics
[03:50.120 --> 03:57.360]  or the real world. The thing that actually gets us closer to not having a description of what our
[03:57.360 --> 04:03.200]  hardware could do, but actually a real physical chip that we can then potentially hold in our
[04:03.200 --> 04:11.440]  hands. So this was the part that was tricky so far. And again, we'll get into more of the details
[04:11.440 --> 04:17.560]  of that. But these two things are the ones we need. We need the logic, the functionality, and we
[04:17.560 --> 04:29.800]  need the implementation to make this a real thing. As in so many cases, kind of there is the terms
[04:29.800 --> 04:37.880]  are overloaded and fuzzy and ambiguous. So for my purpose here, I'm going to use the term front-end
[04:37.880 --> 04:44.120]  for kind of the logic part design. And then there will be a back end as well. So if you're
[04:44.120 --> 04:48.200]  coming from the web world or the JavaScript world, that probably means something very different to
[04:48.200 --> 04:56.880]  you. So if you have a front-end designer in IBM, they're potentially doing JavaScript because
[04:56.880 --> 05:02.400]  that's what they do as well. Or they're potentially doing chips. You don't know. Has led to interesting
[05:02.400 --> 05:12.120]  conversations in the past, I must say. So the front-end, I kind of briefly alluded to that.
[05:12.120 --> 05:23.120]  It's just like programming. So there are different levels of programming languages and
[05:23.120 --> 05:31.320]  hierarchies. There is, for example, high-level synthesis starting at the top. Well, if you would
[05:31.320 --> 05:35.400]  buy such a high-level synthesis tool, that would probably tell you you start with an idea and
[05:35.400 --> 05:40.280]  then maybe an algorithm, something that is fancy, and then just run the tool and you get your chip
[05:40.280 --> 05:47.600]  out of it immediately, kind of done. Some of them will sell you tools that allow you to start with a,
[05:47.600 --> 05:54.160]  well, in marketing, it sounds like an arbitrarily complex C or C++ code base and just run that
[05:54.160 --> 05:58.880]  high-level synthesis tool and you get a chip design out of it. Nothing, no human involves,
[05:58.880 --> 06:06.000]  works perfectly. Now, anybody who has C and C or C++ code bases will kind of attest, this is
[06:06.000 --> 06:16.440]  probably not how reality works. And it doesn't. Beyond that, again, the boundary is slightly
[06:16.440 --> 06:23.520]  fuzzy. There are high-level languages that make it ideally more convenient to write a chip. And then
[06:23.520 --> 06:32.480]  at the lowest level almost, there's always system Veriloc or Veriloc and PHDL. Again,
[06:32.480 --> 06:39.240]  system Veriloc being kind of slightly misleading in terminology. So system Veriloc is the current
[06:39.240 --> 06:45.480]  standard for hardware description languages that was previously called Veriloc. Some others use
[06:45.480 --> 06:51.680]  it as system Veriloc being a verification language, well, Veriloc is the design language. Again,
[06:51.680 --> 06:56.640]  let's make it as confusing as possible. It's the language called system Veriloc these days. The
[06:56.640 --> 07:04.160]  alternative is VHDL. Again, just like the C and yeah, more or less the C or C++ of the hardware
[07:04.160 --> 07:11.080]  world. And below there, that's typically not a, that's not a programming language. It's just
[07:11.080 --> 07:17.960]  a typically Veriloc as well. Just a lower-level representation of the same thing. That is the
[07:17.960 --> 07:26.560]  net list, which is effectively a C of ands and ors, and then connected by wires. So that's
[07:26.560 --> 07:32.840]  representing your logic. So these are the kind of the programming languages that you would use,
[07:32.840 --> 07:41.920]  and we'll get into a couple examples in a second. And then obviously, there's all the other stuff.
[07:41.920 --> 07:49.120]  Test frameworks, build tools. You need to have a proper conversation about a build tool. Otherwise,
[07:49.120 --> 07:55.480]  it's not a real programming environment. I mean, who are we if we can't argue endlessly about
[07:55.480 --> 08:03.000]  build tools. There are developer productivity tools. It's actually one of the areas where open
[08:03.000 --> 08:11.200]  source really shines compared to some of the commercial offerings and simulators. And again,
[08:11.200 --> 08:15.960]  we'll get into those in a second. So let's have a look at a couple examples. We want to do open
[08:15.960 --> 08:21.720]  source after all. So hardware description language that we can choose from. And the list is quite
[08:21.720 --> 08:30.720]  long, even though it kind of narrows down quickly once you kind of look deeper. So there is system
[08:30.720 --> 08:35.080]  Veriloc and Veriloc. So this is an IEEE standard. You can download a standard just like the C
[08:35.080 --> 08:43.400]  standard. And this is effectively the most commonly used language to do hardware design. It's quite
[08:43.400 --> 08:49.800]  old, which is not to say much of a problem, but it has been continuously updated. The other
[08:49.800 --> 08:56.880]  problem about system Veriloc and Veriloc is kind of years come and go and programming concepts
[08:56.880 --> 09:01.800]  and ideas come and go as well. The problem is if your language stays around that long,
[09:01.800 --> 09:08.600]  you just add everything. So if you look at the system Veriloc standards, it's huge. From that,
[09:08.600 --> 09:15.840]  it's huge as the C++ standard. But it will have some interesting corner cases if you look at that.
[09:15.840 --> 09:24.720]  And that has interesting side effects, because now we have a fair amount of tools, and we'll get
[09:24.720 --> 09:30.080]  to that in a second, how many tools you actually need to evolve to get a hardware design working.
[09:30.080 --> 09:36.520]  So all of those need to understand ideally the same subset of system Veriloc. And it also
[09:36.520 --> 09:43.040]  kind of interpreted the same way. So that's not always the case. That's why hardware designers
[09:43.040 --> 09:49.560]  who are per se already quite conservative in the tools they're choosing, will end up with a very
[09:49.560 --> 09:57.240]  kind of old school subset of Veriloc that you, India, and allowed to use. VHDL is another option,
[09:57.240 --> 10:04.200]  same story there, just slightly different. The Veriloc community is much larger. And especially
[10:04.200 --> 10:10.800]  if you're looking at producing real ASIC chip designs, you're going to look at Veriloc mostly.
[10:10.800 --> 10:17.440]  But then, program names as said come and go. So there are some interesting new ones up there as
[10:17.440 --> 10:24.160]  well. There's BlueSpec. There are a fair amount of Python-based HDLs, and some of them are more
[10:24.160 --> 10:30.840]  low-level than ours. So there is MyGen, Amaranth, and MyHDL, and a couple others. So this list is,
[10:30.840 --> 10:37.920]  by the way, no. It doesn't need to be complete. And it isn't complete. And there are a number of
[10:37.920 --> 10:42.840]  hardware description languages or programming languages that are based on functional programming
[10:42.840 --> 10:51.840]  languages. Spinal HDL, Chisel, and Clash, for example. Chisel, for example, being quite, well,
[10:51.840 --> 10:59.280]  often used these days because, I don't know, who has heard about Risk 5? Let's maybe raise your
[10:59.280 --> 11:10.280]  hand. So Risk 5 is an open-source instruction set architecture. So, like, the x86 instruction set
[11:10.280 --> 11:19.000]  architecture or ARM, the 78 instruction set architecture. And then, kind of that was developed
[11:19.000 --> 11:26.040]  in Berkeley originally. And they also developed a hardware language called Chisel. So the initial
[11:26.040 --> 11:30.960]  Risk 5 core implementation, the Rocket core is implemented in Chisel. And since that's open
[11:30.960 --> 11:38.360]  source and widely used, kind of Chisel also spread more widely. So you'll see that. And then there
[11:38.360 --> 11:45.640]  is a, I'm not quite sure how new or old it is, the circuit LLVM effort that kind of tries to
[11:45.640 --> 11:54.280]  build a LLVM-based compiler infrastructure to then place hardware languages or other pieces of
[11:54.280 --> 12:02.200]  functionality on top of. I've actually not seen that many, kind of, useful tools coming out of
[12:02.200 --> 12:11.120]  that LLVM-based middle layer. So we'll see what the future brings in that regard. So we choose
[12:11.120 --> 12:16.400]  programming languages. And then the next thing you want to do if you actually want to build a
[12:16.400 --> 12:24.880]  chip is ideally not write everything from scratch. So you reuse, you integrate existing things,
[12:24.880 --> 12:30.360]  and they're typically always called IP cores in that world. So there are a couple of options that
[12:30.360 --> 12:35.200]  makes it easier to integrate. So there is no, unfortunately, central package manager or something
[12:35.200 --> 12:40.560]  like that, like a cargo or an MPM or something like that, that you would have in the new or
[12:40.560 --> 12:49.000]  new software world. So, but what you have instead to do is more or less Google for whatever you
[12:49.000 --> 12:56.200]  might need, and you might find an abandoned Git repository or a sit drop somewhere that contains
[12:56.200 --> 13:01.160]  what you're looking for. And often it comes without, this has been potentially taped out,
[13:01.160 --> 13:05.480]  so a chip has been produced out of that, and it's stable, so we're not going to touch it again. So
[13:05.480 --> 13:11.080]  many of these kind of IP cores are considered stable because as soon as you've used them once,
[13:11.080 --> 13:17.560]  you don't want to touch them again. So you rarely have a fancy community around those cores. It's
[13:17.560 --> 13:23.960]  just, it's there, you use it, and then you're on your own. So that was, and still is, this website
[13:23.960 --> 13:30.160]  called OpenCourse, which was kind of a directory for open source hardware blocks. It's been
[13:30.160 --> 13:35.480]  unmaintained for quite a while, but it's still there. So if you're looking for, of course, it
[13:35.480 --> 13:39.960]  might be a good option, but again, don't expect that much of an active community around these
[13:39.960 --> 13:48.560]  offerings. And yes, I guess the best, that's why the slide is quite empty, option is just Google,
[13:48.560 --> 13:54.520]  and you'll find something. So now that we have put together a logic design, we have written some
[13:54.520 --> 13:58.480]  stuff on our own, we choose in the programming languages nobody else has been using before,
[13:58.480 --> 14:05.720]  and we added some IP cores that nobody was maintaining. So now we want to see if it actually
[14:05.720 --> 14:11.000]  works. I mean, it feels unlikely if I phrase it like that, but the chances are it actually does.
[14:11.000 --> 14:18.800]  So we need to verify it somehow, better or not so good. We're potentially documented. Nah,
[14:18.800 --> 14:24.800]  let's not do that. We want to make it look pretty. I mean, that's what we spend most of our time,
[14:24.800 --> 14:30.320]  don't we? I mean, it's tabs or spaces or indent here or there. It needs to look pretty, even
[14:30.320 --> 14:33.920]  it doesn't work. So that's something we need to do. And that's something the open source
[14:33.920 --> 14:39.320]  community was always fantastic about. And that's clearly something we're bringing to the world of
[14:39.320 --> 14:47.320]  commercial chip design. We need to simulate it. Because at this point, we're just doing logic
[14:47.320 --> 14:53.600]  design. So we don't have anything, we don't have a chip yet. So we somehow need to see what it
[14:53.600 --> 15:01.120]  actually does. And we potentially can run it on FPG. And I'll get to that in a second. So let's
[15:01.120 --> 15:07.680]  have a look at a couple buzzwords here of what is possible these days in the open source chip
[15:07.680 --> 15:15.360]  design world. Simulators, we start with that one. There are kind of three main simulators. And you
[15:15.360 --> 15:20.960]  see that they're main simulators because they have a logo. There is a fourth simulator that's
[15:20.960 --> 15:26.960]  rarely used, NVC, and doesn't have a logo. So I think that indicates what's going on. You also
[15:26.960 --> 15:33.960]  see by the style of the logos, what are the older projects? At least it's slightly misleading, I
[15:33.960 --> 15:40.320]  must say. And so on the top right, we have Ecois VariLog, which is an event-based VariLog
[15:40.320 --> 15:46.160]  simulator. It has been around for quite a while. It's stable, and it works really well. It's
[15:46.160 --> 15:54.720]  widely used. But it doesn't support much of the more modern system VariLog features. And it's
[15:54.720 --> 16:00.960]  not that fast. It's sufficiently fast for smaller designs. And it's kind of the standard choice if
[16:00.960 --> 16:07.360]  you just want to get started. Ecois VariLog is here. If you're looking for a BHGL option, there is
[16:07.360 --> 16:17.360]  GHGL, I think the most actively maintained BHGL simulator these days. And there is VariLog later
[16:17.360 --> 16:25.200]  in the middle, which is slightly different because it simulates VariLog as well. The name gives it
[16:25.200 --> 16:31.360]  away, I would say. But it's a cycle accurate simulator. So without going into too much of the
[16:31.360 --> 16:41.200]  details here, if you have kind of a real chip design, you clock it. And then you get kind of
[16:41.200 --> 16:51.600]  one clock pass per clock. Well, that's ridiculous. But that's kind of the only times when VariLog
[16:51.600 --> 16:57.120]  kind of re-evaluates things that are going on. In an event-based simulator, you get a slightly
[16:57.120 --> 17:03.680]  different behavior. Either way, VariLog behaves pretty much like a real chip would do afterwards.
[17:05.440 --> 17:10.160]  And it's a very, very active community. And it's typically based around the
[17:10.880 --> 17:16.720]  synthesizable subset of VariLog. So because that's kind of what it targets. It targets only the
[17:16.720 --> 17:21.520]  logic that you then want to bring on a chip and not so much the system VariLog that you can use
[17:21.520 --> 17:28.560]  to actually write a test bench or verification framework around it. The verification frameworks,
[17:28.560 --> 17:38.400]  I just mentioned that. Who has heard of UVM, the one up here, couple ones? Okay. So UVM is
[17:38.400 --> 17:44.800]  an interesting one. It's a system VariLog verification methodology. And already with methodology
[17:44.800 --> 17:50.720]  you kind of breathe this air of being designed by a committee. And that's how it looks. It's
[17:50.720 --> 17:56.320]  effectively a class library, a framework of classes and instructions on how to use them
[17:56.320 --> 18:00.640]  and when to use them to actually verify a chip. So write a test bench, more or less.
[18:02.480 --> 18:09.920]  So that's your Google test of VariLog, if you wish to. And there are a couple other options.
[18:11.200 --> 18:14.480]  And I mentioned that I'm involved there. So I'm going to mention that prominently.
[18:14.480 --> 18:20.640]  There's CocoDB, which gives you a way to write a test bench in Python that is then testing your
[18:20.640 --> 18:30.000]  hardware logic. There is OSVVM for BHDL designs. And there is on the top, just one of the further
[18:30.000 --> 18:34.880]  options. Symbiosis, if you don't want to do simulation-based verification, but you want
[18:34.880 --> 18:40.720]  to do formal verification, so you want to prove that certain things are happening or not happening.
[18:40.720 --> 18:46.480]  So this is then effectively using a SAT solver behind the scenes to prove some things can be
[18:46.480 --> 18:51.920]  done or can't be done. So that's a very different verification approach and works very,
[18:51.920 --> 18:59.920]  very well for some problems, not for all of them. And so you typically, if you're kind of trying
[18:59.920 --> 19:04.000]  to gain confidence in your design, you definitely go for some simulation-based
[19:04.000 --> 19:09.280]  verification, so simulation-based testing. And then you maybe throw in some formal around
[19:09.280 --> 19:16.800]  some specific areas. And while I'm putting these here, so this is kind of the way to do
[19:16.800 --> 19:21.440]  verification not new, but what we see here is that we have a fair amount of options in open
[19:21.440 --> 19:29.760]  source that are very, very high quality and ready to be used. So that's great.
[19:29.760 --> 19:38.720]  Build systems, and I need to mention the first one first. Who has heard of Feustock? Oh, a couple ones.
[19:38.720 --> 19:43.920]  So there's this guy called Ola Chingren, quite active on Twitter as well, and he's always writing
[19:43.920 --> 19:51.280]  award-winning software. So he started that initially when he just saw a tool that apparently has
[19:51.280 --> 19:56.560]  gained an award, but he couldn't find the award that it was awarded. So from then on, every tool
[19:56.560 --> 20:00.800]  he's writing is award-winning, even though it has never won any awards. Actually, I think Feustock
[20:00.800 --> 20:05.680]  has won one or two awards by now. So I think that's something we only took copy. Just make sure that
[20:05.680 --> 20:10.800]  we always say our software is award-winning. And from down, it's just much better.
[20:11.920 --> 20:20.080]  So Feustock is a build system for hardware designs, and Idyllize is a build system backend to make
[20:20.080 --> 20:26.800]  kind of the hardware design put together and feed that to a variety of different tools that are
[20:26.800 --> 20:31.760]  involved. So just like driving your compiler. There was VUnit, a regression manager.
[20:34.080 --> 20:39.200]  Well, okay, another maybe interesting term I'm saying regression manager here. So a regression
[20:39.200 --> 20:46.480]  in the software world would be something was working, and then it would broke it somehow. So
[20:46.480 --> 20:52.560]  kind of functionality degraded in quality. A regression in the hardware world would be somebody
[20:52.560 --> 20:57.840]  just running a fair amount of tests. So effectively, Unite DCI would be a regression,
[20:59.360 --> 21:04.960]  just to add confusing terminology. And there are a fair amount of other options for build systems.
[21:04.960 --> 21:12.960]  Again, just Google them and then fight about it, obviously. We talked about white space before,
[21:12.960 --> 21:19.440]  and when you're done with your fighting about your build system, you obviously need to fight
[21:19.440 --> 21:26.400]  about your right style guide to use for your programming languages. So we have come accustomed
[21:26.400 --> 21:33.120]  in the software world to there being kind of clang format and other go format and other
[21:33.120 --> 21:42.160]  enforcing, or not so much enforcing, auto format is there. If you look at a very low code and VHDL
[21:42.160 --> 21:50.640]  code, you see there is no format. And you see often there is kind of no taste either. So
[21:52.240 --> 21:58.160]  it just looks awful. And if you look through code, then everything looks different, which
[21:58.160 --> 22:04.640]  isn't that much of a problem in the commercial chip development world, because you own something.
[22:04.640 --> 22:08.960]  It's kind of, it's John's core. So this is kind of the piece of code that John is working on.
[22:08.960 --> 22:14.080]  Only he needs to be able to touch it, which is then up to John, however, they want to
[22:15.760 --> 22:19.600]  kind of format their code. And I've done that for 20 or 30 or 40 years, so they just
[22:20.160 --> 22:23.040]  have their in-house style that you also see changing over time.
[22:23.040 --> 22:33.440]  And that's not something that we kind of find normal in kind of these days of software development.
[22:33.440 --> 22:39.840]  So there was an effort, and there still is an effort to bring formatting and linting
[22:40.480 --> 22:45.440]  and language server integration. So that gives you a visual studio code integration,
[22:45.440 --> 22:50.240]  or other kinds of integrations. And the variable is the tool to look for there.
[22:50.240 --> 22:57.520]  There is very later lint. Part of that, very later simulated, I've shown before. And it actually
[22:57.520 --> 23:04.720]  does more static analysis jobs as well. And there are a couple other options to choose from.
[23:04.720 --> 23:09.360]  And mostly mentioning that a very long part here, you'll find that, because that's what I'm most
[23:09.360 --> 23:17.440]  familiar with, but I'm very sure there is an equivalent BHTL kind of option for many of these
[23:17.440 --> 23:21.680]  things as well. And if you know them, by the way, just raise your hand and we'll just add it right away.
[23:24.560 --> 23:30.320]  So let's have a look at just one or two examples. So this is a don't need to read it in full. So
[23:30.320 --> 23:38.240]  this is a piece of very low-con-top assigning something based on a ternary statement. And
[23:39.360 --> 23:47.200]  think about very like it's statically, it's not statically typed, but it still is easy to assign
[23:47.200 --> 23:53.760]  for example, 32 bits to seven bits or the other way around. And very likely, well, most very
[23:53.760 --> 24:01.760]  log tools will be, well, very much equal end of that fact and just strip off some bits that are
[24:01.760 --> 24:08.400]  not used or padded in some way. So what you would expect from many languages where the compiler
[24:08.400 --> 24:14.000]  just tells you, well, this is just bullshit that you've written here. And very likely need some
[24:14.000 --> 24:21.760]  further tools to do that actually. And variator lint is one of the options here. Just random
[24:21.760 --> 24:26.960]  examples where you actually need insight into the variables and the constants that are being used.
[24:29.520 --> 24:36.400]  With variable, we now also can do something that we also know quite well from a software world.
[24:36.400 --> 24:42.000]  It's just have style lints and stuff like that running in CIN actually give you feedback right
[24:42.000 --> 24:51.200]  away. And for example here, I'm having a screenshot from a open-type repository, a pull request,
[24:51.200 --> 24:55.360]  where one of these bots actually gives you immediately feedback on, well, that's
[24:55.360 --> 25:05.040]  training space. That's kind of the most boring example. But also things like rules about naming
[25:05.040 --> 25:09.040]  certain constructs. We don't need to go into the details of what's happening here. And I think
[25:09.040 --> 25:16.960]  I've seen some people from Antmicro here before. So if you have questions about variable, I think
[25:16.960 --> 25:22.480]  that people up there are to blame and to ask questions. But I've done a great job.
[25:25.760 --> 25:32.160]  So let's keep it at that for the moment. Frontend, we're doing great in terms of chip design. So
[25:32.160 --> 25:38.560]  we have all the tools. We've seen that the slides only always had a subset of tools that we can use.
[25:39.360 --> 25:45.200]  So Frontend is doing great and has been for ages. I mean, one thing I would love to see
[25:45.200 --> 25:50.960]  is that we just stop reinventing Verilog parsing. It's a huge language and we have so many tools
[25:50.960 --> 25:56.080]  that all think they can parse Verilog and they just can't. They just really can't. I mean,
[25:56.080 --> 26:00.320]  everybody thinks they just strip at that part of the standard and somebody uses it and you
[26:00.320 --> 26:05.280]  get these weird pipelines that just don't work anymore. So maybe a unified frontend at some
[26:05.280 --> 26:10.320]  point in time. And I know there have been a couple of attempts to actually do that.
[26:10.320 --> 26:14.880]  And it just leads to that situation that you now have one more frontend to care about, as always.
[26:14.880 --> 26:30.960]  Okay. We have our logic design. We can run it on an FPGA. Sure. And in the FPGA world,
[26:30.960 --> 26:35.520]  there are kind of two main manufacturers of FPGAs and there is something else. So who does,
[26:35.520 --> 26:42.080]  well, who does not know what an FPGA is? Okay. Very small number. So it's a field
[26:42.080 --> 26:47.840]  programmable gate array. So it's effectively a chip that you can reprogram. Let's put it like that
[26:47.840 --> 26:55.360]  in very simple terms. And normally you would use the tool that the vendor provides you that would
[26:55.360 --> 27:01.520]  be in, how do I name this thing? So it would be Vivado for Xilinx, now some other company,
[27:01.520 --> 27:10.320]  or Quartus for Altera, now Intel. Whatever. Just get bored. Come on. Stop it. Or if you
[27:10.320 --> 27:18.240]  don't want to use those closed tools, you can use symbiosis or formally Simpliflow or now for FPGA.
[27:18.960 --> 27:25.360]  And it gives you a reverse engineered way to actually target Xilinx 7-series FPGA. So these
[27:25.360 --> 27:33.440]  are the most common FPGAs. And actually do full designs, full open source using only open source
[27:33.440 --> 27:40.480]  tools and get them run on an FPGA. The problem there always was that kind of the programming
[27:40.480 --> 27:45.360]  instructions, the way how to kind of structure a program to put it in an FPGA wasn't known.
[27:45.360 --> 27:50.480]  That's what they reverse engineered and then put together kind of a various open source tools
[27:50.480 --> 28:00.240]  that then allow you to actually target FPGAs. So there is FPGAs are pretty much like if you're
[28:00.240 --> 28:09.040]  trying to build a phone, but the only thing you can do is actually build that. It's like it's
[28:09.040 --> 28:15.520]  nice, it's functionality, it's kind of similar, but it's pixely, you know. It's just it's not a
[28:15.520 --> 28:25.520]  right thing. And I mean I actually outsourced that work to my niece and nephew. So it's just
[28:25.520 --> 28:30.320]  well that's what we want, don't we? We want kind of open source silicon. We want a real chip.
[28:31.120 --> 28:44.160]  We want this thingy, not that. So how can we do that? We need the back end, we need the physical
[28:44.160 --> 28:55.200]  implementation. That adds a whole lot of new complexity, of course. And that's where things
[28:55.200 --> 29:01.920]  become interesting. And what we want is we want to go from RTL, so that's your registered transfer
[29:01.920 --> 29:08.720]  layer, a level, layer, level, I don't know. So that's your very lock to GDS2. That's a very old
[29:08.720 --> 29:13.840]  data format that you then send to a company that produces your chips. So that's a fact.
[29:15.440 --> 29:23.600]  So we want a RTL to GDS2 flow. And I have an example of one here. So we start with our
[29:23.600 --> 29:30.000]  very lock on the top. We do synthesis. And I'm not going to explain them all in detail here,
[29:30.000 --> 29:36.160]  because otherwise we're going to be here for a long time. But just to demystify some of the
[29:36.160 --> 29:41.600]  acronyms in here. So we do our synthesis that gives us a net list. We do a static timing analysis.
[29:41.600 --> 29:48.080]  So to see if we have put potentially too much logic after each other, so that you can't clock
[29:48.080 --> 29:51.840]  it anymore, that you only can clock the two kilohertz or something like that. That's what
[29:51.840 --> 29:58.160]  the static timing analysis does in the first one. So there's DFT designed for tests. If you have
[29:58.160 --> 30:02.720]  that chip, you're going to have a hard time looking inside it. So you want some test structures
[30:02.720 --> 30:07.600]  inside your chip that allow you to observe what's going on. So these are typically scan chains,
[30:07.600 --> 30:13.280]  something that JTEC was and still is used for, apart from the many other things that JTEC is
[30:13.280 --> 30:19.840]  being used for. But that's what DFT does. And these scans are automatically inserted normally for
[30:19.840 --> 30:29.360]  all or most registers. And then you have that. You still have a very long description. And then you
[30:29.360 --> 30:35.760]  do floor planning, placement, clock tree synthesis optimization, and global routing. So in the end
[30:35.760 --> 30:44.560]  you get a number of transistors and that you connect them somehow and you optimize them in a way that
[30:44.560 --> 30:52.160]  kind of minimizes or maximizes power or performance or area, depending on what you're looking for.
[30:53.120 --> 30:57.360]  And kind of all the things that we've skipped over so far that are now relevant in the physical
[30:57.360 --> 31:02.720]  world. For example, if you have that clock that goes to your chip, you always need to make sure,
[31:02.720 --> 31:06.400]  obviously also need to make sure that actually gets distributed across the chip. So you just
[31:06.400 --> 31:11.280]  have a single pin potentially where it comes in, but it needs to be everywhere. So you have that
[31:11.280 --> 31:16.480]  clock tree that you need to insert somehow. Something we don't need to worry about, for example,
[31:16.480 --> 31:21.360]  or not that much worry about if you're doing an FPGA design or a simulation, because that's
[31:21.360 --> 31:27.520]  something FPGA vendor has already done for us. So we're able to kind of ignore many of these
[31:27.520 --> 31:35.040]  things when we're just doing kind of FPGAs before. And then since we're back in the physical world,
[31:35.040 --> 31:40.560]  you need to manufacture them. We have antenna diodes that we need to insert. And after we've
[31:40.560 --> 31:48.080]  done that much processing, we're not quite sure what we got. So what we want to make sure is at
[31:48.080 --> 31:53.120]  this point that we actually know that still the original design is what we did. So we do a logic
[31:53.120 --> 32:02.000]  equivalence check that's the LEC here. And then we do detailed routing, RC extraction, another
[32:02.000 --> 32:07.680]  timing analysis. And finally, we're at GDS2 streaming. So that's when we do the file writing.
[32:07.680 --> 32:14.080]  And there we got our GDS2. Easy, isn't it? So just need to kind of hook those tools up together.
[32:14.720 --> 32:22.160]  Done. Beautiful. Why didn't we do that ages ago? I guess we were too lazy to just do that.
[32:23.200 --> 32:29.760]  Well, the reason is a different one. I just skipped out one part of the picture. And that's one
[32:29.760 --> 32:39.200]  input up here. That's the PDK, the process design kit. And this is something you get
[32:40.480 --> 32:45.040]  from a fab. And if you don't get it, you don't get it. You're not going to do any of that.
[32:46.320 --> 32:55.600]  And I was standing here in 2016, a couple years ago. These were some of the slides,
[32:55.600 --> 33:03.680]  style change as well. So we have the process design kit. We are getting their standard cell
[33:03.680 --> 33:10.320]  libraries. We get a fair amount of design rules. Like if you have ever done kind of PCB manufacturing,
[33:10.320 --> 33:14.320]  printed circuit boards, you also get a number of rules that you need to obey so that they can
[33:14.320 --> 33:19.760]  actually manufacture it. It's typically not that long that list. And if you want to
[33:19.760 --> 33:26.000]  fab a chip, the list is significantly longer. Electrical parameters. So you get it from the
[33:26.000 --> 33:31.120]  foundry. And you need to sign an NDA for that. That's where we stopped in 2016. That's where
[33:31.120 --> 33:38.480]  we stopped in 2017. And that's why we said back then, you can't do it as a hobbyist. So
[33:38.480 --> 33:44.720]  just there's no way of doing that. There were some companies who did it. And low risk was one of them.
[33:44.720 --> 33:50.400]  If you are kind of big enough, they still allow you to sign that NDA. But that's where we stopped.
[33:51.200 --> 33:58.640]  And then there was this talk. This was two years ago now. Tim Ansel, what?
[33:59.920 --> 34:06.480]  It's 2013. So 2020, I think. So that's even more. Yeah, let's say two years plus, minus.
[34:06.480 --> 34:14.800]  And where Tim Ansel, working at Google, was presenting the SkyWater PDK. So this is
[34:15.680 --> 34:20.880]  for the first time ever that, well, at least in the last 20 years, let's put it this way,
[34:21.520 --> 34:29.600]  a process design kit. So the rules from Foundry were open source. And they are available
[34:29.600 --> 34:36.480]  on GitHub right there. So let's think and switch over here. Can I? No, I can't.
[34:38.160 --> 34:42.560]  Let's keep it up there. So, yes, you can download them from GitHub. So now you solve
[34:42.560 --> 34:47.920]  that one problem. You actually can now manufacture a fully open source chip because you do have
[34:47.920 --> 34:57.040]  these rules. The downside here is this is a 130 nanometer PDK. If you're looking at
[34:57.040 --> 35:09.360]  current 3, 5 nanometer chips in your mobile phone potentially. So when was 130? 130 was this time.
[35:11.920 --> 35:17.280]  So these are Pentium 4's that were 130 nanometer roughly. So that's a net burst architecture.
[35:17.280 --> 35:25.200]  AMD roughly at the same time. So that's around 2002 where that technology was first introduced.
[35:27.120 --> 35:36.480]  Maybe you still have some of those PCs actually around. But nonetheless, these chips, well,
[35:36.480 --> 35:41.200]  this process is still being manufactured. Otherwise, Foundry wouldn't be able to produce
[35:41.200 --> 35:49.680]  something out of that. So they still have processing lines that actually use that flow. So the other
[35:49.680 --> 35:56.720]  thing that was happening is that Google said not only we talked at Foundry and they gave us this
[35:56.720 --> 36:05.200]  PDK away, we're also funding a shuttle. So that is effectively a cost effective way to produce
[36:05.200 --> 36:10.000]  chips together with others on a single wafer. And I said we're doing a couple of those every year.
[36:10.000 --> 36:15.440]  And if you submit an open source design, you get that manufactured for free, really kind of free
[36:15.440 --> 36:22.720]  as in no cost at all using only open source tools. So free as in real free as well. So that for the
[36:22.720 --> 36:27.760]  first time made it possible for everybody who only has internet access and doesn't need any cash at
[36:27.760 --> 36:32.960]  all to get a chip manufactured. So these are obviously not volume chips. So these are kind
[36:32.960 --> 36:40.560]  of experimental chips for you to actually give it a try. But you can for the first time ever you can.
[36:40.560 --> 36:51.040]  So this was a old article found that from these 130 nanometer chips, you know, kind of in a couple
[36:51.040 --> 36:57.920]  years they said that was in 2000, we should be able to reach 8 to 10 gigahertz on slightly better
[36:57.920 --> 37:04.000]  nodes. So I think that was around 70 nanometers. So if they said that would be possible, I mean,
[37:04.000 --> 37:09.520]  we are only like 18 years behind that prediction now. Let's see what we in the open source actually
[37:09.520 --> 37:15.120]  can do and probably not going to reach those eight gigahertz. But there's a fair amount of room
[37:15.120 --> 37:20.960]  in those old process nodes still to be optimized and still to be explored.
[37:20.960 --> 37:28.960]  So let's do some exploring actually. We've seen that picture before of that flow. You can get
[37:28.960 --> 37:36.320]  that flow very easily. You do a git clone of the open lane repository. You CD into it. You run make,
[37:37.280 --> 37:43.040]  make test and make mount and that gives you a docker container. And that docker container
[37:43.040 --> 37:49.760]  is something I have open right here. So this is the open lane docker container. And since we are
[37:49.760 --> 38:00.720]  recently short on time, I'm not going to run it in full. So I did run the flow. So this is a
[38:00.720 --> 38:09.120]  trivial design. So that's a SPM, a serial parallel multiplier. So this is a very small piece of
[38:09.120 --> 38:19.920]  very low code that we will then turn into a chip design. It's part of the standard demo,
[38:19.920 --> 38:25.040]  so I guess you can give that a try as well. So let's have a look.
[38:30.240 --> 38:36.240]  The flow, the processor runs through in a minute or after two minutes for that trivial design.
[38:36.240 --> 38:44.400]  For a larger design, it takes an hour for an AES core and a full SOC taking a couple
[38:45.440 --> 38:49.840]  10, 20 hours depending on how you're doing. It's still not the end of the world.
[38:52.000 --> 38:54.400]  So that was a boring summary, isn't it?
[38:58.800 --> 39:02.800]  Let's have a look at the output right away. So it comes with a
[39:02.800 --> 39:17.280]  GDS view. So GDS is the output format, as we said. And just starting from that very log
[39:17.280 --> 39:24.800]  and using only open source components, you get the full GDS. And that is confusing because
[39:24.800 --> 39:31.440]  physics are confusing. So let's see if we can get rid of some things here or just have a look at the
[39:31.440 --> 39:36.320]  left side first. So we see the different cells that are being used. So the Sky Water Foundry
[39:36.320 --> 39:43.120]  provides us with a number of ands and ores and knots and other things optimized for different
[39:43.120 --> 39:50.320]  process callers. And they get chosen and then inserted into that design. So let's get rid of
[39:50.320 --> 39:55.920]  a bit of the stuff that we actually need for physics. So decaps, who needs those, fillers,
[39:55.920 --> 40:02.560]  nobody is there either. So that already gives us a slightly better picture. Maybe we can get rid
[40:02.560 --> 40:11.360]  of some of those metal layers, the connectivity. I mean, who needs that? And we see we can get
[40:11.360 --> 40:25.040]  closer to the actual interesting parts. So that is effectively your file that you sent to the
[40:25.040 --> 40:30.800]  Foundry. And you can do that as set free of cost using the shuttle program. Or if you don't want
[40:30.800 --> 40:39.920]  to use that, you can also pay a company called eFabulous to then fab that for you. As I said,
[40:39.920 --> 40:47.040]  using only the open source tools. Since we are really short on time, here are the things that
[40:47.040 --> 40:53.040]  you can have a look and play with. You're also, if you don't want to install anything locally,
[40:53.040 --> 40:59.680]  you can have a look at that link that gives you a Jupyter notebook, an online way to just
[40:59.680 --> 41:06.080]  actually play around. And just in your browser, write some VHDL or Verilog, actually in that case,
[41:06.080 --> 41:12.560]  and synthesizes and have a look at the GDS2 in the end. Only in your browser, nothing else needed.
[41:15.680 --> 41:20.320]  There is a project called Tiny Tapeout, where you can get a very, very small chip
[41:20.320 --> 41:26.640]  manufactured and learn how to do it. And they have a very, very nice GitHub action set up.
[41:27.280 --> 41:32.080]  And I need to show that because it's just fantastic. So apart from kind of you have your
[41:33.680 --> 41:44.080]  Verilog and then in the end, your GDS, you also get a built-in 3D GDS viewer that
[41:44.080 --> 41:52.240]  allows you to zoom through your design and see the metal layers, see everything in there.
[41:52.880 --> 41:58.000]  And let's get rid of some of the, oops, there was a wrong button. Oh, how can I help you?
[41:59.600 --> 42:06.240]  Some of the layers, so that was remove the fields and the decaps, and then remove the
[42:06.240 --> 42:11.440]  cell geometry as well. So that's your standard cells now. And we can actually look at them
[42:11.440 --> 42:16.720]  and see what they are and also look at the different layers. So that's really cool. And that
[42:16.720 --> 42:21.840]  shows if you have now all the open source tools, you can do all that. You can do that in a GitHub
[42:21.840 --> 42:27.840]  action where before when you actually had licenses and license servers and all that crap that comes
[42:27.840 --> 42:32.960]  with software that you need to buy for a lot of money, it's not just expensive, it's also
[42:32.960 --> 42:38.880]  a pain to use, and stuff like that wouldn't just be possible. So open source is here with that
[42:38.880 --> 42:48.960]  stuff, and it's staying, I'm telling you. So we got that one. And again, the link is there.
[42:49.520 --> 42:56.640]  So let's have a look at who's actually doing that. So I had a look at some GitHub stats.
[42:57.760 --> 43:03.760]  So yours is the synthesis tool and actually quite old tool. So that's 10 people. Again,
[43:03.760 --> 43:10.160]  it's a random month. It's at last month roughly. So 10 people working there. So that's a healthy
[43:10.160 --> 43:17.280]  community of people adding things. It's not a huge community. And this is a thing we'll see
[43:17.280 --> 43:25.840]  repeating. Very late at the simulation tool, 20 people in the last month pushing and doing stuff.
[43:25.840 --> 43:35.120]  CocoaDB, not that many people, but still. The SkyWater PDK, that's the manual, effectively,
[43:35.120 --> 43:40.960]  of your PDK. And that doesn't see that many changes. And I think that's one of the areas where
[43:41.600 --> 43:44.880]  more people could get involved. And actually, where we have as a community,
[43:44.880 --> 43:50.720]  more to figure out because that description that PDK is not complete and not error free,
[43:50.720 --> 43:53.280]  like in any document that you write, there are probably going to be errors.
[43:53.280 --> 44:00.720]  So we're still looking for more ways how to get people involved and fix those kind of even small
[44:00.720 --> 44:08.320]  errors. So open lane, we've seen that flow, reasonably active as well. We've come open
[44:08.320 --> 44:14.800]  road, which is within open lane, they always make it sound similar. But open road is kind of the
[44:14.800 --> 44:22.560]  majority of those physical design tools and bundling them together. What open road has an idea,
[44:22.560 --> 44:31.360]  it was funded by DARPA. And the idea is to be able to go from an RTL to a GDS 2 and 24 hours
[44:31.360 --> 44:36.240]  with no human in the loop, which is something very different from the normal hardware world,
[44:36.240 --> 44:40.960]  where you always have tools that are... Well, you can put it in two ways. You can say the
[44:40.960 --> 44:45.760]  tools are too crappy, so you need to go manually in and fix some stuff in the way. Or you say the
[44:45.760 --> 44:50.480]  tools are good enough and you just need that human to actually give it that special touch because
[44:50.480 --> 44:57.840]  hardware is just so difficult. It feels like at times when you set up compiler, isn't exactly
[44:57.840 --> 45:03.600]  good enough to actually really compile my software. So at times I just go in and just do a bit of
[45:03.600 --> 45:09.840]  hand assembly editing because there's corners around memory access. So they just need a bit of
[45:09.840 --> 45:14.240]  manual work. So that's how hardware design works. And that's what they want to change is just make
[45:14.240 --> 45:22.480]  it completely automated. Just for comparison, this is how things on a Linux kernel would look.
[45:23.840 --> 45:30.000]  So the hardware community is significantly smaller than the software community. And that's
[45:30.000 --> 45:37.680]  why Ruby, for example, is funding some of these things, is finding hardware engineers is quite
[45:37.680 --> 45:42.000]  tricky. And there is just tons of software engineers and tons of good ideas that have been
[45:42.000 --> 45:47.120]  explored and tried in the software world. So we want to bring that to hardware as well and make
[45:47.120 --> 45:54.800]  it accessible there. We'll look at it very later. And we also see more and more chip designs being
[45:54.800 --> 46:01.040]  submitted to OpenMPW. So that's the free as in cost shuttle program where you can just submit your
[46:01.040 --> 46:07.200]  designs. So whenever somebody learns typically by themselves how to do a chip design and then
[46:07.200 --> 46:13.520]  submit it, it kind of shows up in that graph. So there have been eight free of those manufacturing
[46:13.520 --> 46:21.920]  runs now. And there is more to come. The first chips are back. So the MPW1 chips. You see this is
[46:21.920 --> 46:29.280]  a fair amount of lead time. It takes typically at least two and a half months roughly to get
[46:29.280 --> 46:34.480]  chips back from FAB. But then you want to test them and you want to actually potentially fix
[46:34.480 --> 46:39.920]  errors and these OpenMPW ones. Since all the tooling is new, that's still a fair amount of
[46:39.920 --> 46:44.720]  problems in them. So bringing them up is not quite trivial and they don't fully work. But that's
[46:44.720 --> 46:48.800]  what we're learning. And that's why we kind of do that repeatedly and again and again. So we don't
[46:48.800 --> 46:56.320]  need to be fully correct the first time. We just have a couple more tries. So looking at the future,
[46:56.320 --> 47:01.360]  always hard. We're going to see innovation. We're going to see change that nobody predicted. And
[47:01.360 --> 47:04.960]  that's the good thing about making this open source. So somebody who has an idea can actually
[47:04.960 --> 47:10.960]  give it a try and just see if they can do it. Pretty much before, if you wanted to do chip design,
[47:10.960 --> 47:14.960]  you had to be within a large company that did it the way they always did. So you had to do their
[47:14.960 --> 47:22.000]  product end of story. So there is no that much unpredictable innovation. Tools getting more
[47:22.000 --> 47:28.720]  accessible. We can actually get access to them. And finally, we can actually revolutionize learning
[47:28.720 --> 47:33.440]  about hardware. Before, when I was taking a university course, it was kind of very
[47:34.240 --> 47:39.360]  boring theoretical. So you had kind of course materials from 10 years ago from somebody who
[47:39.360 --> 47:43.520]  has never seen a chip being made in their life because they just actually used the course
[47:43.520 --> 47:48.800]  material that they got 20 years ago. And that's just how teaching evolves. And that's kind of the
[47:48.800 --> 47:53.680]  teaching we see in very many universities about hardware design. So they might have a VHDL,
[47:53.680 --> 47:59.360]  a very low course, but it's so far from reality. It's kind of not even funny. So we can actually
[47:59.360 --> 48:06.880]  now learn how to do it the real way. There are some news. I'll let the links up there. And
[48:06.880 --> 48:11.120]  finally, if you actually want to take a paid for learning course, with all those open source
[48:11.120 --> 48:16.480]  tools, there is the zero to AC course from Matt Van. So he helped me actually preparing some slides
[48:16.480 --> 48:24.640]  to have a look at that stuff. If you're looking for in person events, there is a lecture coming up
[48:24.640 --> 48:30.240]  in the US, a open source hardware conference that the Fosse Foundation has been organizing for a
[48:30.240 --> 48:37.440]  number of years. And there is all kind of coming back after COVID, the main open source hardware
[48:37.440 --> 48:43.200]  conference in Munich this year. I think we haven't announced that very widely at September 15 and 16.
[48:43.200 --> 48:47.520]  And just stay for the October fest. Just take your hotel room a couple more days. And this is
[48:47.520 --> 48:55.120]  going to be a great experience. We end with a quote that I found, an atmosphere of excitement
[48:55.120 --> 48:59.440]  and anticipation pervades this field. Workers from many backgrounds, computer scientists,
[48:59.440 --> 49:04.640]  electrical engineers, physics, physicists are collaborating on a common problem area,
[49:04.640 --> 49:09.680]  which has not yet become classical. This territory is vast and largely unexplored.
[49:09.680 --> 49:23.040]  The rewards for those who simply press forward are great. So this was written in 1978. And with
[49:23.920 --> 49:30.480]  there again, with the open source world, let's make this open source chip design a reality. We
[49:30.480 --> 49:47.280]  have all the necessary ingredients. We have all the necessary tools. Let's make it happen. Thank you.