Coriolis RTL-to-GDSII Toolchain
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Chaput, Jean-Paul
Sorbonne Université, in collaboration with Chips4Makers and LibreSOC are working to provide a complete FOSS toolchain to make ASICs in mature technological nodes, that is, no smaller than 130nm. We take a circuit description in HDL, synthetize with Yosys but instead of targetting a FPGA, use an ASIC standard cell library to get the RTL description. From there, with Coriolis2, we perform the classical steps of a RTL to GDSII flow, that is, placement, routage along with very basic timing closure. We will particularly focus on last year progresses and present the planned improvements and new features for 2022.
 Hello everyone and welcome to this presentation of the Coriolis ASIC design flow. The presentation is organized as follows. First I will remember the reasons that are behind or driving us to make Coriolis. Then I will present the basics of making an ASIC that is all ASICs are done, which will lead me to introduce the design flow with a special emphasis toward its software architecture. Then I will summarize the improvements that we made in 2021 and go to the plans for 2022. And finally I will present a small demonstration about the latest capabilities of Coriolis. One of the first reasons we started to develop Coriolis was to provide academics with tools independent from commercial software, which have closed source and with which you cannot exactly control what you do, or being trapped by backward capabilities problems. So with our tools you know exactly what's going on inside the source, and moreover if it doesn't exactly switch you, you can modify them. The second advantage is that with the software you can publish, share and modify the hardware design you have made. This avoids to have to reinvent the wheel every time you want something that has already been done by others, but cannot be published. We hope to build a free community with that approach exactly like the free software made for UNIX. But aside for those academics aspect, we also wanted Coriolis to be able to handle real situation designs, so small and medium enterprises will be able to make at low or no cost small or medium designs without having to pay the huge fees usually associated with commercial software. Of course by being open we should bolster the securities as I remind you, a secure software cannot run in an insecure hardware. If your hardware is not trusted, there is no way you can make a trusted software upon it, or at least that I'm aware of. Another aspect of this project is that it will help ensure the continued existence of the hardware. Typically there are some applications or domains when you want to be able to provide a design for a very long time. Typically imagine a nuclear power plant which has been qualified with a certain processor or certain kind of hardware. It will be only qualified for those hardware and not others. So you have to be able to provide those exact same hardware for the lifespan of the nuclear power plant which may be 50 or maybe even 60 years. So imagine a processor that has that kind of lifespan. As of today I don't know any one of them. So we wanted to start small and our first targets are the mature node. That is the node not lower than 130 nanometers because the problems to solve are less complex and we can make demonstrations and still have useful designs. I assume that most of you are familiar with the FPGA design flow and not with the ASIC design flow. So this figure helps to understand the difference. On the left hand side you have the FPGA design flow which starts by a logical synthesis. Then a place and route upon the FPGA matrix to targets that place and route generates a bit stream that you send inside the FPGA that you upload onto the FPGA and which configures it. Note that the FPGA is itself a kind of ASIC. It's a finished ASIC but it's an ASIC. On the other side, on the right side, you have the ASIC design flow which starts the same by a logical synthesis but on a slightly quite different structure which is the standard cells and gives a net list. Then we perform the physical synthesis which is called the place and route and gives us a layout. The layout is a drawing, just a big drawing and this is this drawing that we send to the funerary. The funerary is the factory that will translate, transform your design, your drawing, your layout into an ASIC and it will send back you that ASIC. There are two blocking points until recently in this design flow. The first point is the EDA tools. EDA tools exist but the commercial one comes with a very high license fee. For example, I heard that to benefit from the full flow of one major vendor, it's above a million euros per year. So that's quite as expensive for a small or medium business. The second blockage point is which is underlining in red here. It's the fact that the funerary protects their technological information, their trade secrets by NDA, non-disclosure agreements, that prevents you to share or publish everything you do with the design rules, with their private information. It completely prevents you to share your work. On the other hand, once fabricated, you have no restriction about the finished product which is the ASIC. So those two points are the key points that we want to solve. Let's have a closer look at the ASIC design flow. On the left-hand side of this slide, I put a drawing of a small, very small design so we can see the individual components. As I said, the design is just a drawing, but the drawing that has to respect a very complex set of design rules. That is drawing rules for modern technologies. This set of rules contains above a thousand rules. So how does that work? First, we have the RTL description of a design, which is basically a finite set machine, expressed in terms of registers and Boolean equations, complex Boolean equations. We use the logical synthesis to break it down in terms of little logical cells, which gives us a net list. The point of the logical cells called the standard cell library is that those little cells have a layout counterpart, that you can translate this small logical Boolean equation, which is a noun, into a design, an electrical design that will do the same function. When you have broken down your design, you have to reassemble it into a single coherent layout, which is done basically in two steps. The placement steps, which just place all those little pieces of layout inside an area, and then the routing step, which draws the wires that connect them, the electrical wires. And then you get, you got your complete layout, expressed in terms of GDS or AP file. This is basically a V-cycle into which the library, which is underlined in a light background, is the pivotal points. So you break down into the library, and then you assemble them. As I just said, the standard cell library is a key point of the design flow. The one we use has a long history. It starts with the S6-Lib 1, which has then been adapted by Naoshi Kochimizu from Tokai University, to better fit the deep submicron rules. It contains 89 cells, logic gate, depth lip flop, multiplexer, and so on. It is well validated, because we have built some design with it and checked that they work. But in the end, what we use now is another kind of portage, starting bas-aid on the topological structure of NS6-Lib, or S6-Lib, that has been made by Stav Veraghen from Chips-Foremaker, with its Flex-Lib library and the PDK maester. So it's an attempt to be portable across technology, but still getting close to the technology rules. So, and this is what we use through good old Coriolis project now. Here is a little bit more detailed view of the design flow, of the ISIC design flow. So, we want to emphasize in this slide the part that we are working on, which are the physical synthesis and the cell library, in cooperation with PDK maester and Chips-Foremaker. And the other part, we aggregate. So, the design flow starts with RTL generator, which can be anything that generates Verylog or VHDL. You have a MIGEN, TRISEL, Spinal HDL, System C, System Verylog, and maybe some other that I can forget. And this is a complex choice, because there are a lot of advantages to any of them, and these are advantages. So it's a trade-off. I won't go into the discussion about those kind of trade-offs, because it's almost a short discussion. So, we see that we can validate with VHDL. We have the logical synthesis, validation again with simulation, and we have to validate the layout with the DRC. We will go into that in more detail in the following slide. So, the right part, which is in a light-red background, is the part which is not publishable. That is, which is covered by the NDA. But fortunately, last year, Google released its SkyWater Free PDK Open Design Kit. So, fortunately, for that design kit, all this part can be published. Now, let's have a look to the logical synthesis part. As almost everyone out there, we are relying on YoSys to perform the logical synthesis. But as we are aggregating tools, it is a nightmare of file translation. For example, here, we start from VHDL, then we have to translate it into Verilog. Then YoSys can use it, generate a BlifFile as output, and we have then to translate the BlifFile into the Coriolis special subset of VHDL, which is called VST for VHDL Structural. Hopefully, this will improve in the future years and be more integrated and simplified. At the other end of the design flow, we found the validation. I mean that when you have placed and root your design, you will need to check that the layout that you have got is as error free as possible. It is not always sure that it will be, but at least you must perform all the verification possible. So there are three kinds of verification. Starting from the GDS file, which is your layout. You first perform a DRC or design rule checking. That means checking that all that you're drawing is completely correct. Respect all the rules dictated by the technological node. For example, that means that there is no wire too small or too close to each other. So that's basic verification. Then you need another tool, which is an extractor, which is currently and very recently we used OpenR6, which performs an extraction of the netlist. You compare the extracted netlist with the reference one, with an LVS tool, layout versus schematic, which means that the router has done its job correctly and the wire are exactly connecting the gates like they should. There is no open circuit or there is no disconnection and there is no short circuit. That is two wires crossing each other. So that's the second verification, which is very important. And the last one is the static timing analysis. It's based on the extracted netlist, but with a more fine, grained detail level, which is the transistor level. We use the gates inside the transistor and we combine them with the wire from the netlist and we check that all the timings are good, that you are really making all the timing constraints, meaning that the propagation time along the wire are all correct. And this is very important if you want to match the working frequency of your design and also check some other difficult problems. For that, we use the high-pass tool, which is also a tool developed at the Lipschitz Lab, which is old, but very reliable. Now let's have a look at the algorithm. At first glance, the algorithms are second-challenged, organized. First, you have the standard cell library, then the placer, based on a simple algorithm, then the global routing step, which uses a Dijkstra algorithm, very classic. And finally, the data-led router, which makes use of an unpublished academic algorithm, based on segment, rip-up and re-root. But each one of these steps, of course, is NP-complete. But they are not as second-challenged as they are. For example, one classical problem is the routing congestion. That is, the placer crammed the cells into two small areas, so the data-led router cannot draw all the wires without making overlap. So it must inform in some way that that area is overloaded, and the placer must insert more space for the router to complete. Basically, there are lots of constraints like that. This is what we really have in terms of interaction. And this has consequences in terms of data structure, upon which we construct our tools. So the key feature of Coriolis is the hurricane database through which all the tools communicate. And in terms of data structure, they make decorations, like illustrated here. The jcell is the hurricane database, and you have the data-led router or the global router, which makes decoration over it and communicate through them. Finally, all those considerations explain the shape of the doDesignScript.py, which manage how your design will be placed on route. As we have a Python interface, Descript is really a mix between Python part and C++ part. C++ part are used for computational intensive work or tasks, like placement or detailed routing. But other parts, like the clock tree generation here and some others, are only made in Python. In fact, there is not a real Coriolis binary. It's only made of Python scripts and library interfaces in Python. We also delegate as much as possible the task of managing the file system to Python, because it is already done and we don't want to reinvent the wheel by doing it inside Coriolis. We are also being busy making new chips. For example, the biggest one, the Librosoc, which is 120 kG, account for 1.3 million transistors, for an area of 28 mm2. It has been done in the TSMC 180 nanometers technology. And we hope to get it back, packaged, in a few weeks. Staff Veragen did also use our tools to make his own microcontroller chip, which contains a Motorola 68000 and a MOS 6502, including 4 kB of onboard RAM. The onboard RAM can be seen at the bottom right corner of the design. That are those four blanks area, because it did use directly the RAM supplied by TSMC for which we cannot display the design, the layout. So, as I said, it's done in TSMC 350 nanometers and amount for 2026 kG. The last chip was done by ChipFlow, and it contains a Minerva RISC-5 implementation by LambdaSoc. It was submitted to the MPW-4 Google program, which makes use of the SkyWater 180 nanometers. It makes use of the Caravelle Arnes, which is a way to encapsulate your design for measurements. And it accounts for about 57 kG. What are we going to do for next year? The first item is to improve the speed of the placer. The placer gives high-quality placement, but unfortunately, it seems more sensitive to the area of the placement than to the number of standard cells, which is quite strange. We will work on that. Then we will also work on density-driven placement, that is, start to introduce the loop, the retraction loop between the feedback loop, sorry, between the placement and the global routing. And at the same time, we will also interest ourselves to the timing-driven placement because they require similar functionalities or features. And in that same movement, we will also rewrite the netlist extractor and comparator, which are already present inside Coriolis. But unfortunately, their implementation is butchered, so we will rewrite them from scratch. And finally, we plan to release a new chip, which is a follow-up of the LibreSoc project, and which will be a small gigabit Ethernet router, and will be a much bigger design. And finally, let's have a little demonstration of what Coriolis can do for you. This example is not completely part of Alliance Check Toolkit yet, but it will be in the future. So, first, you see that we have some very low file, which describe our little design. In our case, it's the 6502, the most 6502. So we have the RTL representation of our design. We also have the little doDesign script, which will tell Coriolis what to do, how to place and route your design. There is some instruction inside, but not too much to customize by yourself. Most of them can be copied from one reference script to another. So it's very simple. And finally, a little Mac file, which is here again mostly generic, into which you have just to indicate what is your top Mac file. So, as I said, it is mostly done by Mac file. So the first step is to generate the, is to call YoSys and perform the logical synthesis. So we do that by Mac VST. So people familiar with YoSys did recognize this output. Now, it has been processed by YoSys and then the output BLEF file has been translated into a VST file, VHDL structural, which is loadable by Coriolis. If you look at VST, you see that we have the relevant file. So now we can run truly the place and route step. This makes TGT and run the script. We run do design. Here we go. So I activated the step by step. It is a debug feature, but it is useful for demo also. So what you see here is the core and around it is the harness, because it's the demonstration using the Caravelle harness for the Google SkyWater program. So we have done the design. Now we have built a clock tree. I will make a zoom on the center area, which is where the chip, the processor is located. So you see the clock tree, unconnected yet, but built prior to the placement. Then we perform the placement. This is the simple algorithm at works and we display the lower bound placement. That is the one with the shorter distances. And as you can see, the lower bound and the upper bound converge slowly together, which explains the progressive spreading of the cells over the area. Now we have performed the placement. So I will start to display one net for nicer demonstration. I did choose this one, C7. Here we go. So what you see now is the fly line representing the net. I will perform a zoom around the net. So we see it better as it progressively refined. We are before the global routine, so we only see a fly line connecting all the terminals. Now we see the global routine appear. Here we have the global routine and the trunk of the net. Here we see the global routine. I will zoom back on the net. Here we go. Then after the global routine comes the detailed routine. And finally you see it has just submitted a small adjustment and the global routine is finished. The detailed routine is finished. And you can see that any overlap has been solved. Now the whole design has been finished and you see that it's connected to the harness. We change the power distribution of the Google sky water harness by only putting vertical lines. Here big vertical lines that make them big vias to the alimentation. If we zoom again we can see them. So now you have a completed design which can be sent to the Sky Water Fundry through the Google program. Thank you for your attention. Thank you very much for that Jean-Paul. We have any questions? Please do type them in the main conference room. It's nice to see that we have had some questions and interactions. Thank you Jean-Paul for interacting with people. Adam does a specific PDK and implies a specific foundry. Our more open PDKs are coming by any chance. Our more open PDKs coming by any chance. This is a delicate issue. The foundries are a bit jumpy. Sky Water I believe through the Google sponsored program are considering 19 nanometer. There is a huge number of hoops to jump through before that happens. What else we got? This is your parameterised approach. Is your parameterised approach a template or was it a layout? Yes, it can do that. It is a virtual layout which generates the actual layout that is compliant with the PDK. The NSX lib was done before that and is independent of it. That is a different approach. You can either use NSX lib or you can use flexlib. You can see Adam typing. This will transfer over to the carousel room. Yes, of course, Jean-Paul, no we weren't able to hear you. Your microphone is still listed on mute. Yes, Jean-Paul, just waiting for Adam and Nathan to type. Jean-Paul, we are waiting for you to resolve the microphone. Nathan's question, do you extract timing information from the generator standard style through spy simulation to create lib files and then it is a place and route timing driven? We are still waiting for Jean-Paul to sort out the microphone. Do you extract the timing information from the generator standard styles? Yes, we do. We do extract the timing information from the generator standard styles. Alright, Marie Minervais put it into high task Jiggle to do a transistor and a mixed transistor gate level static time analysis. Is the place and route timing driven? Yes, I believe so. That's a key feature of it. Adam is asking who is going to disconnect and reconnect to the Q&A clinic to see if we can solve the microphone issue. Who on practice will be using the tools research institutions, small companies or individuals or three? One of the key things at the moment is the NDAs that are sort of basically equivalent to a worldwide cartel. They basically prevent research institutions and security researchers from doing academics from being able to publish any of their results. So this is one way to break that. Yes, 180 nanometer is extremely cheap and is the largest and most commonly used geometry in the world. Last time I checked it's only in production. You're only looking at $600 for an 18-inch wafer. The whole idea is that yes, you will be able to use Coriolis-TOOT to your full GDS-2 files, rather than having to spend a quarter of a million dollars a week on licensing of proprietary tools. That's a mad cost, which makes it completely impractical to consider doing an ASIC. The volume said you have to sell that you will be enormous to cover your costs, whereas if you've got LibreOpen place and route, many more people can consider it. And yes, I'm an individual and I've been doing layout and working with Sean Paul on this. Okay, reconnected. Nathan, I can see your typing, so just wait for you. Yes, Fari Fablas. Yes, they are. So there is now Chips for Makers house down a Skywarden 130 nanometer flex-lib port. The repository. So previously in the chat I linked the FreePDK45 version, so you can do your layout with that. But of course FreePDK45 is an academic PDK, it's not intended for actual GDS-2 files sending to a foundry, because there's no fab that actually exists, which would take it. But this Chips for Makers PDK Skywarden 130 nanometer is intended to work with the Skywarden 130 nanometer process. Thank you Sean Paul there, we do not have timing for different place and route yet, should be working on features this year. Okay. So there is at least one project that has submitted to EFABLAS using Coriolis-2 with Chips for Makers 130 PDK. Hi David, nice to see you here. Thank you Nathan and Sean Paul really appreciates that. It's been a lot of work. John Paul's project has been running since 1993, 1994. One of the things, there is a Japanese foundry in something very very large. Free software projects come submit to, I forget the name of the university but they're working with a company that uses for training purposes. So, the PENGIMP 3 was a 180, yes, exactly. 400MHz DDR3 memory was done in 130 nanometer. So, 800MHz DDR, so 400MHz clock rate. If you look you can see DRAM chips were in 130 nanometer, it's perfectly possible. Yes, Elias started in the 90s here. And it's been slowly converting from that C and C++ code over to Python, but keeping the high performance parts in C++. If anybody actually wants to try it out for themselves, I'm just going to go whilst there's a question and it's still running. I'm going to drop a link to the Coriolis install script which we've been running within the LibreSupp project. There you go, if you want to actually just run an automated auto install, there you go, there's a script to do that, which I've dropped into the chat. It's at git.librestock.org and it's on the dev end setup repository. If anybody would like to continue talking with Jean-Paul, I will drop the link in the chat and the last two. Thank you very much Jean-Paul for such a fascinating talk, it's really appreciated. It's really important to work that you're doing.
 Hello everyone and welcome to this presentation of the Coriolis ASIC design flow.  The presentation is organized as follows.  First I will remember the reasons that are behind or driving us to make Coriolis.  Then I will present the basics of making an ASIC that is all ASICs are done,  which will lead me to introduce the design flow with a special emphasis toward its software architecture.  Then I will summarize the improvements that we made in 2021 and go to the plans for 2022.  And finally I will present a small demonstration about the latest capabilities of Coriolis.  One of the first reasons we started to develop Coriolis was to provide academics with tools independent from commercial software,  which have closed source and with which you cannot exactly control what you do,  or being trapped by backward capabilities problems.  So with our tools you know exactly what's going on inside the source,  and moreover if it doesn't exactly switch you, you can modify them.  The second advantage is that with the software you can publish, share and modify the hardware design you have made.  This avoids to have to reinvent the wheel every time you want something that has already been done by others,  but cannot be published.  We hope to build a free community with that approach exactly like the free software made for UNIX.  But aside for those academics aspect, we also wanted Coriolis to be able to handle real situation designs,  so small and medium enterprises will be able to make at low or no cost small or medium designs  without having to pay the huge fees usually associated with commercial software.  Of course by being open we should bolster the securities as I remind you,  a secure software cannot run in an insecure hardware.  If your hardware is not trusted, there is no way you can make a trusted software upon it,  or at least that I'm aware of.  Another aspect of this project is that it will help ensure the continued existence of the hardware.  Typically there are some applications or domains when you want to be able to provide a design for a very long time.  Typically imagine a nuclear power plant which has been qualified with a certain processor or certain kind of hardware.  It will be only qualified for those hardware and not others.  So you have to be able to provide those exact same hardware for the lifespan of the nuclear power plant which may be 50 or maybe even 60 years.  So imagine a processor that has that kind of lifespan.  As of today I don't know any one of them.  So we wanted to start small and our first targets are the mature node.  That is the node not lower than 130 nanometers because the problems to solve are less complex  and we can make demonstrations and still have useful designs.  I assume that most of you are familiar with the FPGA design flow and not with the ASIC design flow.  So this figure helps to understand the difference.  On the left hand side you have the FPGA design flow which starts by a logical synthesis.  Then a place and route upon the FPGA matrix to targets that place and route generates a bit stream that you send inside the FPGA that you upload onto the FPGA and which configures it.  Note that the FPGA is itself a kind of ASIC.  It's a finished ASIC but it's an ASIC.  On the other side, on the right side, you have the ASIC design flow which starts the same by a logical synthesis but on a slightly quite different structure which is the standard cells and gives a net list.  Then we perform the physical synthesis which is called the place and route and gives us a layout.  The layout is a drawing, just a big drawing and this is this drawing that we send to the funerary.  The funerary is the factory that will translate, transform your design, your drawing, your layout into an ASIC and it will send back you that ASIC.  There are two blocking points until recently in this design flow.  The first point is the EDA tools.  EDA tools exist but the commercial one comes with a very high license fee.  For example, I heard that to benefit from the full flow of one major vendor, it's above a million euros per year.  So that's quite as expensive for a small or medium business.  The second blockage point is which is underlining in red here.  It's the fact that the funerary protects their technological information, their trade secrets by NDA, non-disclosure agreements,  that prevents you to share or publish everything you do with the design rules, with their private information.  It completely prevents you to share your work.  On the other hand, once fabricated, you have no restriction about the finished product which is the ASIC.  So those two points are the key points that we want to solve.  Let's have a closer look at the ASIC design flow.  On the left-hand side of this slide, I put a drawing of a small, very small design so we can see the individual components.  As I said, the design is just a drawing, but the drawing that has to respect a very complex set of design rules.  That is drawing rules for modern technologies.  This set of rules contains above a thousand rules.  So how does that work?  First, we have the RTL description of a design, which is basically a finite set machine,  expressed in terms of registers and Boolean equations, complex Boolean equations.  We use the logical synthesis to break it down in terms of little logical cells, which gives us a net list.  The point of the logical cells called the standard cell library is that those little cells have a layout counterpart,  that you can translate this small logical Boolean equation, which is a noun, into a design, an electrical design that will do the same function.  When you have broken down your design, you have to reassemble it into a single coherent layout, which is done basically in two steps.  The placement steps, which just place all those little pieces of layout inside an area, and then the routing step,  which draws the wires that connect them, the electrical wires.  And then you get, you got your complete layout, expressed in terms of GDS or AP file.  This is basically a V-cycle into which the library, which is underlined in a light background, is the pivotal points.  So you break down into the library, and then you assemble them.  As I just said, the standard cell library is a key point of the design flow.  The one we use has a long history.  It starts with the S6-Lib 1, which has then been adapted by Naoshi Kochimizu from Tokai University,  to better fit the deep submicron rules.  It contains 89 cells, logic gate, depth lip flop, multiplexer, and so on.  It is well validated, because we have built some design with it and checked that they work.  But in the end, what we use now is another kind of portage,  starting bas-aid on the topological structure of NS6-Lib, or S6-Lib,  that has been made by Stav Veraghen from Chips-Foremaker, with its Flex-Lib library and the PDK maester.  So it's an attempt to be portable across technology, but still getting close to the technology rules.  So, and this is what we use through good old Coriolis project now.  Here is a little bit more detailed view of the design flow, of the ISIC design flow.  So, we want to emphasize in this slide the part that we are working on,  which are the physical synthesis and the cell library,  in cooperation with PDK maester and Chips-Foremaker.  And the other part, we aggregate.  So, the design flow starts with RTL generator, which can be anything that generates Verylog or VHDL.  You have a MIGEN, TRISEL, Spinal HDL, System C, System Verylog,  and maybe some other that I can forget.  And this is a complex choice, because there are a lot of advantages to any of them,  and these are advantages. So it's a trade-off.  I won't go into the discussion about those kind of trade-offs, because it's almost a short discussion.  So, we see that we can validate with VHDL.  We have the logical synthesis, validation again with simulation,  and we have to validate the layout with the DRC.  We will go into that in more detail in the following slide.  So, the right part, which is in a light-red background, is the part which is not publishable.  That is, which is covered by the NDA.  But fortunately, last year, Google released its SkyWater Free PDK Open Design Kit.  So, fortunately, for that design kit, all this part can be published.  Now, let's have a look to the logical synthesis part.  As almost everyone out there, we are relying on YoSys to perform the logical synthesis.  But as we are aggregating tools, it is a nightmare of file translation.  For example, here, we start from VHDL, then we have to translate it into Verilog.  Then YoSys can use it, generate a BlifFile as output, and we have then to translate the BlifFile  into the Coriolis special subset of VHDL, which is called VST for VHDL Structural.  Hopefully, this will improve in the future years and be more integrated and simplified.  At the other end of the design flow, we found the validation.  I mean that when you have placed and root your design, you will need to check that the layout that you have got  is as error free as possible.  It is not always sure that it will be, but at least you must perform all the verification possible.  So there are three kinds of verification. Starting from the GDS file, which is your layout.  You first perform a DRC or design rule checking.  That means checking that all that you're drawing is completely correct.  Respect all the rules dictated by the technological node.  For example, that means that there is no wire too small or too close to each other.  So that's basic verification.  Then you need another tool, which is an extractor, which is currently and very recently we used OpenR6,  which performs an extraction of the netlist.  You compare the extracted netlist with the reference one, with an LVS tool, layout versus schematic,  which means that the router has done its job correctly and the wire are exactly connecting the gates like they should.  There is no open circuit or there is no disconnection and there is no short circuit.  That is two wires crossing each other.  So that's the second verification, which is very important.  And the last one is the static timing analysis.  It's based on the extracted netlist, but with a more fine, grained detail level, which is the transistor level.  We use the gates inside the transistor and we combine them with the wire from the netlist  and we check that all the timings are good, that you are really making all the timing constraints,  meaning that the propagation time along the wire are all correct.  And this is very important if you want to match the working frequency of your design  and also check some other difficult problems.  For that, we use the high-pass tool, which is also a tool developed at the Lipschitz Lab,  which is old, but very reliable.  Now let's have a look at the algorithm.  At first glance, the algorithms are second-challenged, organized.  First, you have the standard cell library, then the placer, based on a simple algorithm,  then the global routing step, which uses a Dijkstra algorithm, very classic.  And finally, the data-led router, which makes use of an unpublished academic algorithm,  based on segment, rip-up and re-root.  But each one of these steps, of course, is NP-complete.  But they are not as second-challenged as they are.  For example, one classical problem is the routing congestion.  That is, the placer crammed the cells into two small areas,  so the data-led router cannot draw all the wires without making overlap.  So it must inform in some way that that area is overloaded,  and the placer must insert more space for the router to complete.  Basically, there are lots of constraints like that.  This is what we really have in terms of interaction.  And this has consequences in terms of data structure, upon which we construct our tools.  So the key feature of Coriolis is the hurricane database through which all the tools communicate.  And in terms of data structure, they make decorations, like illustrated here.  The jcell is the hurricane database, and you have the data-led router or the global router,  which makes decoration over it and communicate through them.  Finally, all those considerations explain the shape of the doDesignScript.py,  which manage how your design will be placed on route.  As we have a Python interface, Descript is really a mix between Python part and C++ part.  C++ part are used for computational intensive work or tasks, like placement or detailed routing.  But other parts, like the clock tree generation here and some others, are only made in Python.  In fact, there is not a real Coriolis binary.  It's only made of Python scripts and library interfaces in Python.  We also delegate as much as possible the task of managing the file system to Python,  because it is already done and we don't want to reinvent the wheel by doing it inside Coriolis.  We are also being busy making new chips.  For example, the biggest one, the Librosoc, which is 120 kG,  account for 1.3 million transistors, for an area of 28 mm2.  It has been done in the TSMC 180 nanometers technology.  And we hope to get it back, packaged, in a few weeks.  Staff Veragen did also use our tools to make his own microcontroller chip,  which contains a Motorola 68000 and a MOS 6502, including 4 kB of onboard RAM.  The onboard RAM can be seen at the bottom right corner of the design.  That are those four blanks area, because it did use directly the RAM supplied by TSMC  for which we cannot display the design, the layout.  So, as I said, it's done in TSMC 350 nanometers and amount for 2026 kG.  The last chip was done by ChipFlow, and it contains a Minerva RISC-5 implementation by LambdaSoc.  It was submitted to the MPW-4 Google program, which makes use of the SkyWater 180 nanometers.  It makes use of the Caravelle Arnes, which is a way to encapsulate your design for measurements.  And it accounts for about 57 kG.  What are we going to do for next year?  The first item is to improve the speed of the placer.  The placer gives high-quality placement, but unfortunately, it seems more sensitive to the area of the placement  than to the number of standard cells, which is quite strange. We will work on that.  Then we will also work on density-driven placement, that is, start to introduce the loop, the retraction loop  between the feedback loop, sorry, between the placement and the global routing.  And at the same time, we will also interest ourselves to the timing-driven placement  because they require similar functionalities or features.  And in that same movement, we will also rewrite the netlist extractor and comparator,  which are already present inside Coriolis. But unfortunately, their implementation is butchered,  so we will rewrite them from scratch.  And finally, we plan to release a new chip, which is a follow-up of the LibreSoc project,  and which will be a small gigabit Ethernet router, and will be a much bigger design.  And finally, let's have a little demonstration of what Coriolis can do for you.  This example is not completely part of Alliance Check Toolkit yet, but it will be in the future.  So, first, you see that we have some very low file, which describe our little design.  In our case, it's the 6502, the most 6502. So we have the RTL representation of our design.  We also have the little doDesign script, which will tell Coriolis what to do,  how to place and route your design.  There is some instruction inside, but not too much to customize by yourself.  Most of them can be copied from one reference script to another.  So it's very simple. And finally, a little Mac file, which is here again mostly generic,  into which you have just to indicate what is your top Mac file.  So, as I said, it is mostly done by Mac file.  So the first step is to generate the, is to call YoSys and perform the logical synthesis.  So we do that by Mac VST.  So people familiar with YoSys did recognize this output.  Now, it has been processed by YoSys and then the output BLEF file has been translated into a VST file,  VHDL structural, which is loadable by Coriolis.  If you look at VST, you see that we have the relevant file.  So now we can run truly the place and route step.  This makes TGT and run the script.  We run do design.  Here we go.  So I activated the step by step. It is a debug feature, but it is useful for demo also.  So what you see here is the core and around it is the harness,  because it's the demonstration using the Caravelle harness for the Google SkyWater program.  So we have done the design. Now we have built a clock tree.  I will make a zoom on the center area, which is where the chip, the processor is located.  So you see the clock tree, unconnected yet, but built prior to the placement.  Then we perform the placement.  This is the simple algorithm at works and we display the lower bound placement.  That is the one with the shorter distances.  And as you can see, the lower bound and the upper bound converge slowly together,  which explains the progressive spreading of the cells over the area.  Now we have performed the placement.  So I will start to display one net for nicer demonstration.  I did choose this one, C7.  Here we go.  So what you see now is the fly line representing the net.  I will perform a zoom around the net.  So we see it better as it progressively refined.  We are before the global routine, so we only see a fly line connecting all the terminals.  Now we see the global routine appear.  Here we have the global routine and the trunk of the net.  Here we see the global routine.  I will zoom back on the net.  Here we go.  Then after the global routine comes the detailed routine.  And finally you see it has just submitted a small adjustment and the global routine is finished.  The detailed routine is finished.  And you can see that any overlap has been solved.  Now the whole design has been finished and you see that it's connected to the harness.  We change the power distribution of the Google sky water harness by only putting vertical lines.  Here big vertical lines that make them big vias to the alimentation.  If we zoom again we can see them.  So now you have a completed design which can be sent to the Sky Water Fundry through the Google program.  Thank you for your attention.  Thank you very much for that Jean-Paul.  We have any questions?  Please do type them in the main conference room.  It's nice to see that we have had some questions and interactions.  Thank you Jean-Paul for interacting with people.  Adam does a specific PDK and implies a specific foundry.  Our more open PDKs are coming by any chance.  Our more open PDKs coming by any chance. This is a delicate issue.  The foundries are a bit jumpy.  Sky Water I believe through the Google sponsored program are considering 19 nanometer.  There is a huge number of hoops to jump through before that happens.  What else we got?  This is your parameterised approach.  Is your parameterised approach a template or was it a layout?  Yes, it can do that.  It is a virtual layout which generates the actual layout that is compliant with the PDK.  The NSX lib was done before that and is independent of it.  That is a different approach.  You can either use NSX lib or you can use flexlib.  You can see Adam typing.  This will transfer over to the carousel room.  Yes, of course, Jean-Paul, no we weren't able to hear you. Your microphone is still listed on mute.  Yes, Jean-Paul, just waiting for Adam and Nathan to type.  Jean-Paul, we are waiting for you to resolve the microphone.  Nathan's question, do you extract timing information from the generator standard style through spy simulation to create lib files and then it is a place and route timing driven?  We are still waiting for Jean-Paul to sort out the microphone.  Do you extract the timing information from the generator standard styles?  Yes, we do.  We do extract the timing information from the generator standard styles.  Alright, Marie Minervais put it into high task Jiggle to do a transistor and a mixed transistor gate level static time analysis.  Is the place and route timing driven? Yes, I believe so. That's a key feature of it.  Adam is asking who is going to disconnect and reconnect to the Q&A clinic to see if we can solve the microphone issue.  Who on practice will be using the tools research institutions, small companies or individuals or three?  One of the key things at the moment is the NDAs that are sort of basically equivalent to a worldwide cartel.  They basically prevent research institutions and security researchers from doing academics from being able to publish any of their results.  So this is one way to break that.  Yes, 180 nanometer is extremely cheap and is the largest and most commonly used geometry in the world.  Last time I checked it's only in production. You're only looking at $600 for an 18-inch wafer.  The whole idea is that yes, you will be able to use Coriolis-TOOT to your full GDS-2 files,  rather than having to spend a quarter of a million dollars a week on licensing of proprietary tools.  That's a mad cost, which makes it completely impractical to consider doing an ASIC.  The volume said you have to sell that you will be enormous to cover your costs, whereas if you've got LibreOpen place and route, many more people can consider it.  And yes, I'm an individual and I've been doing layout and working with Sean Paul on this.  Okay, reconnected.  Nathan, I can see your typing, so just wait for you.  Yes, Fari Fablas. Yes, they are.  So there is now Chips for Makers house down a Skywarden 130 nanometer flex-lib port.  The repository. So previously in the chat I linked the FreePDK45 version, so you can do your layout with that.  But of course FreePDK45 is an academic PDK, it's not intended for actual GDS-2 files sending to a foundry, because there's no fab that actually exists, which would take it.  But this Chips for Makers PDK Skywarden 130 nanometer is intended to work with the Skywarden 130 nanometer process.  Thank you Sean Paul there, we do not have timing for different place and route yet, should be working on features this year.  Okay.  So there is at least one project that has submitted to EFABLAS using Coriolis-2 with Chips for Makers 130 PDK.  Hi David, nice to see you here.  Thank you Nathan and Sean Paul really appreciates that. It's been a lot of work.  John Paul's project has been running since 1993, 1994. One of the things, there is a Japanese foundry in something very very large.  Free software projects come submit to, I forget the name of the university but they're working with a company that uses for training purposes.  So, the PENGIMP 3 was a 180, yes, exactly.  400MHz DDR3 memory was done in 130 nanometer. So, 800MHz DDR, so 400MHz clock rate.  If you look you can see DRAM chips were in 130 nanometer, it's perfectly possible.  Yes, Elias started in the 90s here.  And it's been slowly converting from that C and C++ code over to Python, but keeping the high performance parts in C++.  If anybody actually wants to try it out for themselves, I'm just going to go whilst there's a question and it's still running.  I'm going to drop a link to the Coriolis install script which we've been running within the LibreSupp project.  There you go, if you want to actually just run an automated auto install, there you go, there's a script to do that, which I've dropped into the chat.  It's at git.librestock.org and it's on the dev end setup repository.  If anybody would like to continue talking with Jean-Paul, I will drop the link in the chat and the last two.  Thank you very much Jean-Paul for such a fascinating talk, it's really appreciated.  It's really important to work that you're doing.
coriolis2_0_155.png coriolis2_156_203.png coriolis2_204_407.png coriolis2_408_1763.png coriolis2_1764_2147.png coriolis2_2148_7811.png coriolis2_7812_12467.png coriolis2_12468_16379.png coriolis2_16380_18299.png coriolis2_18300_21263.png coriolis2_21264_22691.png coriolis2_22692_25355.png coriolis2_25356_26303.png coriolis2_26304_26747.png coriolis2_26748_26795.png coriolis2_26796_26927.png coriolis2_26928_27011.png coriolis2_27012_27143.png coriolis2_27144_29291.png coriolis2_29292_30107.png coriolis2_30108_31847.png coriolis2_31848_32663.png coriolis2_32664_34019.png coriolis2_34020_34127.png coriolis2_34128_34967.png coriolis2_34968_37079.png coriolis2_37080_37223.png coriolis2_37224_37331.png coriolis2_37332_37511.png coriolis2_37512_37559.png coriolis2_37560_40559.png coriolis2_40560_40607.png coriolis2_40608_40691.png coriolis2_40692_40847.png coriolis2_40848_41495.png coriolis2_41496_41579.png coriolis2_41580_41723.png coriolis2_41724_42023.png coriolis2_42024_42083.png coriolis2_42084_42143.png coriolis2_42144_42959.png coriolis2_42960_43055.png coriolis2_43056_43175.png coriolis2_43176_43223.png coriolis2_43224_43415.png coriolis2_43416_43475.png coriolis2_43476_43571.png coriolis2_43572_43691.png coriolis2_43692_44231.png coriolis2_44232_44435.png coriolis2_44436_44675.png coriolis2_44676_44855.png coriolis2_44856_45191.png coriolis2_45192_45863.png coriolis2_45864_46403.png coriolis2_46404_46595.png coriolis2_46596_46727.png coriolis2_46728_47003.png coriolis2_47004_47063.png coriolis2_47064_47111.png coriolis2_47112_58895.png coriolis2_58896_59459.png coriolis2_59460_72767.png coriolis2_72768_72890.png