Welcome everybody. It's amazing to be back. It's amazing to be back in Brussels in person
and see that many people here looking for an answer to the question, can we do an open
source chip design in 45 minutes? And to save you all the hassle of actually just listening
through this talk. Yes, we can. Thanks. Let's be great and enjoy Brussels. Or if you want
to know more about how that actually can work, stay here. So we're going to look at technology.
Obviously, this is for them. We're going to look at tools and process how to build an
open source chip. We'll be looking at community because this is for them. We want to talk about
the people and communities behind all of these efforts. And we will predict the future. Let's
see how that goes and we'll see some examples of where that potentially went wrong in the past.
So standing in front of you today is Philip. I'm a hardware developer. I've been doing a fair
amount of software. I've been involved in open source for a fair amount of time. I gave my first
foster target just looked 11 years ago. You find some contact information there. And I'm currently
working at this company here. I've been doing chip verification for high-end mainframe CPUs. So
that brings all the new together, actually. And I'm also a maintainer of the open source
Cocoa2B project. And we'll get into that in a second. Previously, I was working at Lawrisk and
open Titan. Again, to buzzwords just for you to Google if you want to. So open Titan is a
security chip fully open source that you actually can get involved just like any other software
community. I'm here today representing the Fossi Foundation. And this is a foundation there to
kind of steward and take care of the open source chip design movement. It's based on individuals.
And it's a non-for-profit registered in the UK. Also has been around for quite a while. And was
initially born out of the open risk movement that did a open source processor CPU core back,
probably, I don't know how many years by now, 10, 15, something like that, before risk 5 was a
thing. So that's it for the introduction. Let's go into the technology. How do we build a chip? There
are two main things that we need. First, we need to think about. We have an idea. Obviously,
that's where we start. But then at some point, we need to implement the functionality. We do
that. It looks similar to a regular programming task. So this is the logic design part. And that
one is pretty well understood these days. Also an open source. We'll see why that is the case and
why that has been thriving for many, many years now. The second part is the back end or the physics
or the real world. The thing that actually gets us closer to not having a description of what our
hardware could do, but actually a real physical chip that we can then potentially hold in our
hands. So this was the part that was tricky so far. And again, we'll get into more of the details
of that. But these two things are the ones we need. We need the logic, the functionality, and we
need the implementation to make this a real thing. As in so many cases, kind of there is the terms
are overloaded and fuzzy and ambiguous. So for my purpose here, I'm going to use the term front-end
for kind of the logic part design. And then there will be a back end as well. So if you're
coming from the web world or the JavaScript world, that probably means something very different to
you. So if you have a front-end designer in IBM, they're potentially doing JavaScript because
that's what they do as well. Or they're potentially doing chips. You don't know. Has led to interesting
conversations in the past, I must say. So the front-end, I kind of briefly alluded to that.
It's just like programming. So there are different levels of programming languages and
hierarchies. There is, for example, high-level synthesis starting at the top. Well, if you would
buy such a high-level synthesis tool, that would probably tell you you start with an idea and
then maybe an algorithm, something that is fancy, and then just run the tool and you get your chip
out of it immediately, kind of done. Some of them will sell you tools that allow you to start with a,
well, in marketing, it sounds like an arbitrarily complex C or C++ code base and just run that
high-level synthesis tool and you get a chip design out of it. Nothing, no human involves,
works perfectly. Now, anybody who has C and C or C++ code bases will kind of attest, this is
probably not how reality works. And it doesn't. Beyond that, again, the boundary is slightly
fuzzy. There are high-level languages that make it ideally more convenient to write a chip. And then
at the lowest level almost, there's always system Veriloc or Veriloc and PHDL. Again,
system Veriloc being kind of slightly misleading in terminology. So system Veriloc is the current
standard for hardware description languages that was previously called Veriloc. Some others use
it as system Veriloc being a verification language, well, Veriloc is the design language. Again,
let's make it as confusing as possible. It's the language called system Veriloc these days. The
alternative is VHDL. Again, just like the C and yeah, more or less the C or C++ of the hardware
world. And below there, that's typically not a, that's not a programming language. It's just
a typically Veriloc as well. Just a lower-level representation of the same thing. That is the
net list, which is effectively a C of ands and ors, and then connected by wires. So that's
representing your logic. So these are the kind of the programming languages that you would use,
and we'll get into a couple examples in a second. And then obviously, there's all the other stuff.
Test frameworks, build tools. You need to have a proper conversation about a build tool. Otherwise,
it's not a real programming environment. I mean, who are we if we can't argue endlessly about
build tools. There are developer productivity tools. It's actually one of the areas where open
source really shines compared to some of the commercial offerings and simulators. And again,
we'll get into those in a second. So let's have a look at a couple examples. We want to do open
source after all. So hardware description language that we can choose from. And the list is quite
long, even though it kind of narrows down quickly once you kind of look deeper. So there is system
Veriloc and Veriloc. So this is an IEEE standard. You can download a standard just like the C
standard. And this is effectively the most commonly used language to do hardware design. It's quite
old, which is not to say much of a problem, but it has been continuously updated. The other
problem about system Veriloc and Veriloc is kind of years come and go and programming concepts
and ideas come and go as well. The problem is if your language stays around that long,
you just add everything. So if you look at the system Veriloc standards, it's huge. From that,
it's huge as the C++ standard. But it will have some interesting corner cases if you look at that.
And that has interesting side effects, because now we have a fair amount of tools, and we'll get
to that in a second, how many tools you actually need to evolve to get a hardware design working.
So all of those need to understand ideally the same subset of system Veriloc. And it also
kind of interpreted the same way. So that's not always the case. That's why hardware designers
who are per se already quite conservative in the tools they're choosing, will end up with a very
kind of old school subset of Veriloc that you, India, and allowed to use. VHDL is another option,
same story there, just slightly different. The Veriloc community is much larger. And especially
if you're looking at producing real ASIC chip designs, you're going to look at Veriloc mostly.
But then, program names as said come and go. So there are some interesting new ones up there as
well. There's BlueSpec. There are a fair amount of Python-based HDLs, and some of them are more
low-level than ours. So there is MyGen, Amaranth, and MyHDL, and a couple others. So this list is,
by the way, no. It doesn't need to be complete. And it isn't complete. And there are a number of
hardware description languages or programming languages that are based on functional programming
languages. Spinal HDL, Chisel, and Clash, for example. Chisel, for example, being quite, well,
often used these days because, I don't know, who has heard about Risk 5? Let's maybe raise your
hand. So Risk 5 is an open-source instruction set architecture. So, like, the x86 instruction set
architecture or ARM, the 78 instruction set architecture. And then, kind of that was developed
in Berkeley originally. And they also developed a hardware language called Chisel. So the initial
Risk 5 core implementation, the Rocket core is implemented in Chisel. And since that's open
source and widely used, kind of Chisel also spread more widely. So you'll see that. And then there
is a, I'm not quite sure how new or old it is, the circuit LLVM effort that kind of tries to
build a LLVM-based compiler infrastructure to then place hardware languages or other pieces of
functionality on top of. I've actually not seen that many, kind of, useful tools coming out of
that LLVM-based middle layer. So we'll see what the future brings in that regard. So we choose
programming languages. And then the next thing you want to do if you actually want to build a
chip is ideally not write everything from scratch. So you reuse, you integrate existing things,
and they're typically always called IP cores in that world. So there are a couple of options that
makes it easier to integrate. So there is no, unfortunately, central package manager or something
like that, like a cargo or an MPM or something like that, that you would have in the new or
new software world. So, but what you have instead to do is more or less Google for whatever you
might need, and you might find an abandoned Git repository or a sit drop somewhere that contains
what you're looking for. And often it comes without, this has been potentially taped out,
so a chip has been produced out of that, and it's stable, so we're not going to touch it again. So
many of these kind of IP cores are considered stable because as soon as you've used them once,
you don't want to touch them again. So you rarely have a fancy community around those cores. It's
just, it's there, you use it, and then you're on your own. So that was, and still is, this website
called OpenCourse, which was kind of a directory for open source hardware blocks. It's been
unmaintained for quite a while, but it's still there. So if you're looking for, of course, it
might be a good option, but again, don't expect that much of an active community around these
offerings. And yes, I guess the best, that's why the slide is quite empty, option is just Google,
and you'll find something. So now that we have put together a logic design, we have written some
stuff on our own, we choose in the programming languages nobody else has been using before,
and we added some IP cores that nobody was maintaining. So now we want to see if it actually
works. I mean, it feels unlikely if I phrase it like that, but the chances are it actually does.
So we need to verify it somehow, better or not so good. We're potentially documented. Nah,
let's not do that. We want to make it look pretty. I mean, that's what we spend most of our time,
don't we? I mean, it's tabs or spaces or indent here or there. It needs to look pretty, even
it doesn't work. So that's something we need to do. And that's something the open source
community was always fantastic about. And that's clearly something we're bringing to the world of
commercial chip design. We need to simulate it. Because at this point, we're just doing logic
design. So we don't have anything, we don't have a chip yet. So we somehow need to see what it
actually does. And we potentially can run it on FPG. And I'll get to that in a second. So let's
have a look at a couple buzzwords here of what is possible these days in the open source chip
design world. Simulators, we start with that one. There are kind of three main simulators. And you
see that they're main simulators because they have a logo. There is a fourth simulator that's
rarely used, NVC, and doesn't have a logo. So I think that indicates what's going on. You also
see by the style of the logos, what are the older projects? At least it's slightly misleading, I
must say. And so on the top right, we have Ecois VariLog, which is an event-based VariLog
simulator. It has been around for quite a while. It's stable, and it works really well. It's
widely used. But it doesn't support much of the more modern system VariLog features. And it's
not that fast. It's sufficiently fast for smaller designs. And it's kind of the standard choice if
you just want to get started. Ecois VariLog is here. If you're looking for a BHGL option, there is
GHGL, I think the most actively maintained BHGL simulator these days. And there is VariLog later
in the middle, which is slightly different because it simulates VariLog as well. The name gives it
away, I would say. But it's a cycle accurate simulator. So without going into too much of the
details here, if you have kind of a real chip design, you clock it. And then you get kind of
one clock pass per clock. Well, that's ridiculous. But that's kind of the only times when VariLog
kind of re-evaluates things that are going on. In an event-based simulator, you get a slightly
different behavior. Either way, VariLog behaves pretty much like a real chip would do afterwards.
And it's a very, very active community. And it's typically based around the
synthesizable subset of VariLog. So because that's kind of what it targets. It targets only the
logic that you then want to bring on a chip and not so much the system VariLog that you can use
to actually write a test bench or verification framework around it. The verification frameworks,
I just mentioned that. Who has heard of UVM, the one up here, couple ones? Okay. So UVM is
an interesting one. It's a system VariLog verification methodology. And already with methodology
you kind of breathe this air of being designed by a committee. And that's how it looks. It's
effectively a class library, a framework of classes and instructions on how to use them
and when to use them to actually verify a chip. So write a test bench, more or less.
So that's your Google test of VariLog, if you wish to. And there are a couple other options.
And I mentioned that I'm involved there. So I'm going to mention that prominently.
There's CocoDB, which gives you a way to write a test bench in Python that is then testing your
hardware logic. There is OSVVM for BHDL designs. And there is on the top, just one of the further
options. Symbiosis, if you don't want to do simulation-based verification, but you want
to do formal verification, so you want to prove that certain things are happening or not happening.
So this is then effectively using a SAT solver behind the scenes to prove some things can be
done or can't be done. So that's a very different verification approach and works very,
very well for some problems, not for all of them. And so you typically, if you're kind of trying
to gain confidence in your design, you definitely go for some simulation-based
verification, so simulation-based testing. And then you maybe throw in some formal around
some specific areas. And while I'm putting these here, so this is kind of the way to do
verification not new, but what we see here is that we have a fair amount of options in open
source that are very, very high quality and ready to be used. So that's great.
Build systems, and I need to mention the first one first. Who has heard of Feustock? Oh, a couple ones.
So there's this guy called Ola Chingren, quite active on Twitter as well, and he's always writing
award-winning software. So he started that initially when he just saw a tool that apparently has
gained an award, but he couldn't find the award that it was awarded. So from then on, every tool
he's writing is award-winning, even though it has never won any awards. Actually, I think Feustock
has won one or two awards by now. So I think that's something we only took copy. Just make sure that
we always say our software is award-winning. And from down, it's just much better.
So Feustock is a build system for hardware designs, and Idyllize is a build system backend to make
kind of the hardware design put together and feed that to a variety of different tools that are
involved. So just like driving your compiler. There was VUnit, a regression manager.
Well, okay, another maybe interesting term I'm saying regression manager here. So a regression
in the software world would be something was working, and then it would broke it somehow. So
kind of functionality degraded in quality. A regression in the hardware world would be somebody
just running a fair amount of tests. So effectively, Unite DCI would be a regression,
just to add confusing terminology. And there are a fair amount of other options for build systems.
Again, just Google them and then fight about it, obviously. We talked about white space before,
and when you're done with your fighting about your build system, you obviously need to fight
about your right style guide to use for your programming languages. So we have come accustomed
in the software world to there being kind of clang format and other go format and other
enforcing, or not so much enforcing, auto format is there. If you look at a very low code and VHDL
code, you see there is no format. And you see often there is kind of no taste either. So
it just looks awful. And if you look through code, then everything looks different, which
isn't that much of a problem in the commercial chip development world, because you own something.
It's kind of, it's John's core. So this is kind of the piece of code that John is working on.
Only he needs to be able to touch it, which is then up to John, however, they want to
kind of format their code. And I've done that for 20 or 30 or 40 years, so they just
have their in-house style that you also see changing over time.
And that's not something that we kind of find normal in kind of these days of software development.
So there was an effort, and there still is an effort to bring formatting and linting
and language server integration. So that gives you a visual studio code integration,
or other kinds of integrations. And the variable is the tool to look for there.
There is very later lint. Part of that, very later simulated, I've shown before. And it actually
does more static analysis jobs as well. And there are a couple other options to choose from.
And mostly mentioning that a very long part here, you'll find that, because that's what I'm most
familiar with, but I'm very sure there is an equivalent BHTL kind of option for many of these
things as well. And if you know them, by the way, just raise your hand and we'll just add it right away.
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
this is a piece of very low-con-top assigning something based on a ternary statement. And
think about very like it's statically, it's not statically typed, but it still is easy to assign
for example, 32 bits to seven bits or the other way around. And very likely, well, most very
log tools will be, well, very much equal end of that fact and just strip off some bits that are
not used or padded in some way. So what you would expect from many languages where the compiler
just tells you, well, this is just bullshit that you've written here. And very likely need some
further tools to do that actually. And variator lint is one of the options here. Just random
examples where you actually need insight into the variables and the constants that are being used.
With variable, we now also can do something that we also know quite well from a software world.
It's just have style lints and stuff like that running in CIN actually give you feedback right
away. And for example here, I'm having a screenshot from a open-type repository, a pull request,
where one of these bots actually gives you immediately feedback on, well, that's
training space. That's kind of the most boring example. But also things like rules about naming
certain constructs. We don't need to go into the details of what's happening here. And I think
I've seen some people from Antmicro here before. So if you have questions about variable, I think
that people up there are to blame and to ask questions. But I've done a great job.
So let's keep it at that for the moment. Frontend, we're doing great in terms of chip design. So
we have all the tools. We've seen that the slides only always had a subset of tools that we can use.
So Frontend is doing great and has been for ages. I mean, one thing I would love to see
is that we just stop reinventing Verilog parsing. It's a huge language and we have so many tools
that all think they can parse Verilog and they just can't. They just really can't. I mean,
everybody thinks they just strip at that part of the standard and somebody uses it and you
get these weird pipelines that just don't work anymore. So maybe a unified frontend at some
point in time. And I know there have been a couple of attempts to actually do that.
And it just leads to that situation that you now have one more frontend to care about, as always.
Okay. We have our logic design. We can run it on an FPGA. Sure. And in the FPGA world,
there are kind of two main manufacturers of FPGAs and there is something else. So who does,
well, who does not know what an FPGA is? Okay. Very small number. So it's a field
programmable gate array. So it's effectively a chip that you can reprogram. Let's put it like that
in very simple terms. And normally you would use the tool that the vendor provides you that would
be in, how do I name this thing? So it would be Vivado for Xilinx, now some other company,
or Quartus for Altera, now Intel. Whatever. Just get bored. Come on. Stop it. Or if you
don't want to use those closed tools, you can use symbiosis or formally Simpliflow or now for FPGA.
And it gives you a reverse engineered way to actually target Xilinx 7-series FPGA. So these
are the most common FPGAs. And actually do full designs, full open source using only open source
tools and get them run on an FPGA. The problem there always was that kind of the programming
instructions, the way how to kind of structure a program to put it in an FPGA wasn't known.
That's what they reverse engineered and then put together kind of a various open source tools
that then allow you to actually target FPGAs. So there is FPGAs are pretty much like if you're
trying to build a phone, but the only thing you can do is actually build that. It's like it's
nice, it's functionality, it's kind of similar, but it's pixely, you know. It's just it's not a
right thing. And I mean I actually outsourced that work to my niece and nephew. So it's just
well that's what we want, don't we? We want kind of open source silicon. We want a real chip.
We want this thingy, not that. So how can we do that? We need the back end, we need the physical
implementation. That adds a whole lot of new complexity, of course. And that's where things
become interesting. And what we want is we want to go from RTL, so that's your registered transfer
layer, a level, layer, level, I don't know. So that's your very lock to GDS2. That's a very old
data format that you then send to a company that produces your chips. So that's a fact.
So we want a RTL to GDS2 flow. And I have an example of one here. So we start with our
very lock on the top. We do synthesis. And I'm not going to explain them all in detail here,
because otherwise we're going to be here for a long time. But just to demystify some of the
acronyms in here. So we do our synthesis that gives us a net list. We do a static timing analysis.
So to see if we have put potentially too much logic after each other, so that you can't clock
it anymore, that you only can clock the two kilohertz or something like that. That's what
the static timing analysis does in the first one. So there's DFT designed for tests. If you have
that chip, you're going to have a hard time looking inside it. So you want some test structures
inside your chip that allow you to observe what's going on. So these are typically scan chains,
something that JTEC was and still is used for, apart from the many other things that JTEC is
being used for. But that's what DFT does. And these scans are automatically inserted normally for
all or most registers. And then you have that. You still have a very long description. And then you
do floor planning, placement, clock tree synthesis optimization, and global routing. So in the end
you get a number of transistors and that you connect them somehow and you optimize them in a way that
kind of minimizes or maximizes power or performance or area, depending on what you're looking for.
And kind of all the things that we've skipped over so far that are now relevant in the physical
world. For example, if you have that clock that goes to your chip, you always need to make sure,
obviously also need to make sure that actually gets distributed across the chip. So you just
have a single pin potentially where it comes in, but it needs to be everywhere. So you have that
clock tree that you need to insert somehow. Something we don't need to worry about, for example,
or not that much worry about if you're doing an FPGA design or a simulation, because that's
something FPGA vendor has already done for us. So we're able to kind of ignore many of these
things when we're just doing kind of FPGAs before. And then since we're back in the physical world,
you need to manufacture them. We have antenna diodes that we need to insert. And after we've
done that much processing, we're not quite sure what we got. So what we want to make sure is at
this point that we actually know that still the original design is what we did. So we do a logic
equivalence check that's the LEC here. And then we do detailed routing, RC extraction, another
timing analysis. And finally, we're at GDS2 streaming. So that's when we do the file writing.
And there we got our GDS2. Easy, isn't it? So just need to kind of hook those tools up together.
Done. Beautiful. Why didn't we do that ages ago? I guess we were too lazy to just do that.
Well, the reason is a different one. I just skipped out one part of the picture. And that's one
input up here. That's the PDK, the process design kit. And this is something you get
from a fab. And if you don't get it, you don't get it. You're not going to do any of that.
And I was standing here in 2016, a couple years ago. These were some of the slides,
style change as well. So we have the process design kit. We are getting their standard cell
libraries. We get a fair amount of design rules. Like if you have ever done kind of PCB manufacturing,
printed circuit boards, you also get a number of rules that you need to obey so that they can
actually manufacture it. It's typically not that long that list. And if you want to
fab a chip, the list is significantly longer. Electrical parameters. So you get it from the
foundry. And you need to sign an NDA for that. That's where we stopped in 2016. That's where
we stopped in 2017. And that's why we said back then, you can't do it as a hobbyist. So
just there's no way of doing that. There were some companies who did it. And low risk was one of them.
If you are kind of big enough, they still allow you to sign that NDA. But that's where we stopped.
And then there was this talk. This was two years ago now. Tim Ansel, what?
It's 2013. So 2020, I think. So that's even more. Yeah, let's say two years plus, minus.
And where Tim Ansel, working at Google, was presenting the SkyWater PDK. So this is
for the first time ever that, well, at least in the last 20 years, let's put it this way,
a process design kit. So the rules from Foundry were open source. And they are available
on GitHub right there. So let's think and switch over here. Can I? No, I can't.
Let's keep it up there. So, yes, you can download them from GitHub. So now you solve
that one problem. You actually can now manufacture a fully open source chip because you do have
these rules. The downside here is this is a 130 nanometer PDK. If you're looking at
current 3, 5 nanometer chips in your mobile phone potentially. So when was 130? 130 was this time.
So these are Pentium 4's that were 130 nanometer roughly. So that's a net burst architecture.
AMD roughly at the same time. So that's around 2002 where that technology was first introduced.
Maybe you still have some of those PCs actually around. But nonetheless, these chips, well,
this process is still being manufactured. Otherwise, Foundry wouldn't be able to produce
something out of that. So they still have processing lines that actually use that flow. So the other
thing that was happening is that Google said not only we talked at Foundry and they gave us this
PDK away, we're also funding a shuttle. So that is effectively a cost effective way to produce
chips together with others on a single wafer. And I said we're doing a couple of those every year.
And if you submit an open source design, you get that manufactured for free, really kind of free
as in no cost at all using only open source tools. So free as in real free as well. So that for the
first time made it possible for everybody who only has internet access and doesn't need any cash at
all to get a chip manufactured. So these are obviously not volume chips. So these are kind
of experimental chips for you to actually give it a try. But you can for the first time ever you can.
So this was a old article found that from these 130 nanometer chips, you know, kind of in a couple
years they said that was in 2000, we should be able to reach 8 to 10 gigahertz on slightly better
nodes. So I think that was around 70 nanometers. So if they said that would be possible, I mean,
we are only like 18 years behind that prediction now. Let's see what we in the open source actually
can do and probably not going to reach those eight gigahertz. But there's a fair amount of room
in those old process nodes still to be optimized and still to be explored.
So let's do some exploring actually. We've seen that picture before of that flow. You can get
that flow very easily. You do a git clone of the open lane repository. You CD into it. You run make,
make test and make mount and that gives you a docker container. And that docker container
is something I have open right here. So this is the open lane docker container. And since we are
recently short on time, I'm not going to run it in full. So I did run the flow. So this is a
trivial design. So that's a SPM, a serial parallel multiplier. So this is a very small piece of
very low code that we will then turn into a chip design. It's part of the standard demo,
so I guess you can give that a try as well. So let's have a look.
The flow, the processor runs through in a minute or after two minutes for that trivial design.
For a larger design, it takes an hour for an AES core and a full SOC taking a couple
10, 20 hours depending on how you're doing. It's still not the end of the world.
So that was a boring summary, isn't it?
Let's have a look at the output right away. So it comes with a
GDS view. So GDS is the output format, as we said. And just starting from that very log
and using only open source components, you get the full GDS. And that is confusing because
physics are confusing. So let's see if we can get rid of some things here or just have a look at the
left side first. So we see the different cells that are being used. So the Sky Water Foundry
provides us with a number of ands and ores and knots and other things optimized for different
process callers. And they get chosen and then inserted into that design. So let's get rid of
a bit of the stuff that we actually need for physics. So decaps, who needs those, fillers,
nobody is there either. So that already gives us a slightly better picture. Maybe we can get rid
of some of those metal layers, the connectivity. I mean, who needs that? And we see we can get
closer to the actual interesting parts. So that is effectively your file that you sent to the
Foundry. And you can do that as set free of cost using the shuttle program. Or if you don't want
to use that, you can also pay a company called eFabulous to then fab that for you. As I said,
using only the open source tools. Since we are really short on time, here are the things that
you can have a look and play with. You're also, if you don't want to install anything locally,
you can have a look at that link that gives you a Jupyter notebook, an online way to just
actually play around. And just in your browser, write some VHDL or Verilog, actually in that case,
and synthesizes and have a look at the GDS2 in the end. Only in your browser, nothing else needed.
There is a project called Tiny Tapeout, where you can get a very, very small chip
manufactured and learn how to do it. And they have a very, very nice GitHub action set up.
And I need to show that because it's just fantastic. So apart from kind of you have your
Verilog and then in the end, your GDS, you also get a built-in 3D GDS viewer that
allows you to zoom through your design and see the metal layers, see everything in there.
And let's get rid of some of the, oops, there was a wrong button. Oh, how can I help you?
Some of the layers, so that was remove the fields and the decaps, and then remove the
cell geometry as well. So that's your standard cells now. And we can actually look at them
and see what they are and also look at the different layers. So that's really cool. And that
shows if you have now all the open source tools, you can do all that. You can do that in a GitHub
action where before when you actually had licenses and license servers and all that crap that comes
with software that you need to buy for a lot of money, it's not just expensive, it's also
a pain to use, and stuff like that wouldn't just be possible. So open source is here with that
stuff, and it's staying, I'm telling you. So we got that one. And again, the link is there.
So let's have a look at who's actually doing that. So I had a look at some GitHub stats.
So yours is the synthesis tool and actually quite old tool. So that's 10 people. Again,
it's a random month. It's at last month roughly. So 10 people working there. So that's a healthy
community of people adding things. It's not a huge community. And this is a thing we'll see
repeating. Very late at the simulation tool, 20 people in the last month pushing and doing stuff.
CocoaDB, not that many people, but still. The SkyWater PDK, that's the manual, effectively,
of your PDK. And that doesn't see that many changes. And I think that's one of the areas where
more people could get involved. And actually, where we have as a community,
more to figure out because that description that PDK is not complete and not error free,
like in any document that you write, there are probably going to be errors.
So we're still looking for more ways how to get people involved and fix those kind of even small
errors. So open lane, we've seen that flow, reasonably active as well. We've come open
road, which is within open lane, they always make it sound similar. But open road is kind of the
majority of those physical design tools and bundling them together. What open road has an idea,
it was funded by DARPA. And the idea is to be able to go from an RTL to a GDS 2 and 24 hours
with no human in the loop, which is something very different from the normal hardware world,
where you always have tools that are... Well, you can put it in two ways. You can say the
tools are too crappy, so you need to go manually in and fix some stuff in the way. Or you say the
tools are good enough and you just need that human to actually give it that special touch because
hardware is just so difficult. It feels like at times when you set up compiler, isn't exactly
good enough to actually really compile my software. So at times I just go in and just do a bit of
hand assembly editing because there's corners around memory access. So they just need a bit of
manual work. So that's how hardware design works. And that's what they want to change is just make
it completely automated. Just for comparison, this is how things on a Linux kernel would look.
So the hardware community is significantly smaller than the software community. And that's
why Ruby, for example, is funding some of these things, is finding hardware engineers is quite
tricky. And there is just tons of software engineers and tons of good ideas that have been
explored and tried in the software world. So we want to bring that to hardware as well and make
it accessible there. We'll look at it very later. And we also see more and more chip designs being
submitted to OpenMPW. So that's the free as in cost shuttle program where you can just submit your
designs. So whenever somebody learns typically by themselves how to do a chip design and then
submit it, it kind of shows up in that graph. So there have been eight free of those manufacturing
runs now. And there is more to come. The first chips are back. So the MPW1 chips. You see this is
a fair amount of lead time. It takes typically at least two and a half months roughly to get
chips back from FAB. But then you want to test them and you want to actually potentially fix
errors and these OpenMPW ones. Since all the tooling is new, that's still a fair amount of
problems in them. So bringing them up is not quite trivial and they don't fully work. But that's
what we're learning. And that's why we kind of do that repeatedly and again and again. So we don't
need to be fully correct the first time. We just have a couple more tries. So looking at the future,
always hard. We're going to see innovation. We're going to see change that nobody predicted. And
that's the good thing about making this open source. So somebody who has an idea can actually
give it a try and just see if they can do it. Pretty much before, if you wanted to do chip design,
you had to be within a large company that did it the way they always did. So you had to do their
product end of story. So there is no that much unpredictable innovation. Tools getting more
accessible. We can actually get access to them. And finally, we can actually revolutionize learning
about hardware. Before, when I was taking a university course, it was kind of very
boring theoretical. So you had kind of course materials from 10 years ago from somebody who
has never seen a chip being made in their life because they just actually used the course
material that they got 20 years ago. And that's just how teaching evolves. And that's kind of the
teaching we see in very many universities about hardware design. So they might have a VHDL,
a very low course, but it's so far from reality. It's kind of not even funny. So we can actually
now learn how to do it the real way. There are some news. I'll let the links up there. And
finally, if you actually want to take a paid for learning course, with all those open source
tools, there is the zero to AC course from Matt Van. So he helped me actually preparing some slides
to have a look at that stuff. If you're looking for in person events, there is a lecture coming up
in the US, a open source hardware conference that the Fosse Foundation has been organizing for a
number of years. And there is all kind of coming back after COVID, the main open source hardware
conference in Munich this year. I think we haven't announced that very widely at September 15 and 16.
And just stay for the October fest. Just take your hotel room a couple more days. And this is
going to be a great experience. We end with a quote that I found, an atmosphere of excitement
and anticipation pervades this field. Workers from many backgrounds, computer scientists,
electrical engineers, physics, physicists are collaborating on a common problem area,
which has not yet become classical. This territory is vast and largely unexplored.
The rewards for those who simply press forward are great. So this was written in 1978. And with
there again, with the open source world, let's make this open source chip design a reality. We
have all the necessary ingredients. We have all the necessary tools. Let's make it happen. Thank you.