 I'm delighted to introduce Taima Dabbard from Sci-Fi. He will, he's maintainer of porting built towards, to the RISC-5 hardware. And yeah, here you go. Don't turn my mic on. Okay, thank you. I'm Paul Mer. I am the maintainer of the ports of various open source projects to RISC-5, including Binyo Tills, GCC, Linux, and G-Lib C. So what is RISC-5? So RISC-5 is a free and open ISA standard designed for every computing device. That means from the smallest embedded IoT device to the largest supercomputer. Oh, good, haha, good, it's working. All right, so the RISC-5 has been around for a while, but the major watershed moment in the last week is that the RISC-5 port of G-Lib C has been submitted upstream and released quickly after that, which means that now the core components of the Linux software stack have been ported to RISC-5 and are available in tarball releases from upstream. That means that it's now time to start porting your favorite software project to RISC-5. So what I'm here to do today is to convince you to join our revolution. So, good, it went. So why are ISA is important? So ISA is the most important interface in the computer. So it's the reason that Intel can't break into the mobile market. It's because the mobile software has largely ported for ARM systems. Similarly, it's the reason that ARM can't move into the server market because server software largely expects Intel systems. And this is despite large investments in software infrastructure over the years. I went to a talk earlier today about porting code from Python 2 to Python 3 and it was a 10-year process. Now, IBM's 360, the longest-lived ISA has been around for 50 years and will probably outlive all of us. So it's a very, very important, it's a very, very important interface and there is no free and open ISA. Now, free and open standards, as we know, have worked well all across the software stack. A great example is in networking. Ethernet and TCP have taken over the world. There's basically nothing left. Additionally, operating systems, largely, somewhat positive compliant systems are everywhere. And in graphics, OpenGL is a great example. You can run your 3D applications on systems from multiple vendors and they're largely portable. So why is there no free and open ISA standard? Well, it turns out that it's dominated, the field is dominated by proprietary ISAs and they're really not great designs. So risk five is a high quality, license-free, royalty-free ISA specification and it was originally designed at UC Berkeley. The standard is now maintained by a non-profit organization like many other industry standards. It's suitable for all types of computing systems from smallest IoT microcontrollers to the largest supercomputers. Numerous proprietary and open source cores exist. It is currently experiencing a rapid growth in industry and academia and also, as I recently mentioned, much software has been ported to it over the few years and like everything, it's still a work in progress. So for those of you less familiar with the risk five ISA, we've written a book and we're giving away signed copies. The book was written by Andrew Waterman and he's signed the title page. It was also written by Dave Patterson, a professor at UC Berkeley. The book is titled an Open Architecture Atlas and it's designed as an introduction to the risk five ISA. It's designed for students, hobbyists and basically anyone interested in computers. So hopefully you're here for your interesting computers. So if you wanna get your copy of the book, tweet a photo of the talk, it's hashtag high five unveiled and at sci five Inc. And we're going to select the winners during the talk. We have 10 books, there's more than 10 people here, which is good. So yeah, tweet us during the talk and we'll give them one. So now I'm gonna talk about the origin of risk five. So we've been developing this ISA for I think about eight years now. And you might say, so why did we start designing our own ISA? Well, so we were at Berkeley and we were trying to do computer architecture research. And if you're gonna build a processor, you need an ISA. So we wanted to look around at the existing ISAs and the only reasonable choices at the time were X86 and ARM, those were kind of the two market leaders. We've done projects based on other systems and they were largely obsolete. So X86 is kind of the obvious choice because particularly at the time it had the vast majority of software support. So if you wanna go, let's just look at kind of the first instruction in the X86 manual which is the AAA instruction. So this instruction is great if you're trying to build a calculator, which was actually what the X86 was kind of originally designed for. The 40.04 was sold in the calculator market. So basically what this does is binary coded decimal support makes it really nice and fast. And it turns out that this is a single byte instruction on modern X86 systems. And I actually went last night, took me a while to figure out how to get it into the assembler but I actually managed to compile an AAA-based program and it worked. Actually it's kind of odd. When digging around trying to figure out how to assemble it, I found out that the 286 had a little bit of a bug in its AAA implementation and we've maintained compatibility with that bug until today. So it turns out that not only do we have a legacy instruction designed to maintain compatibility with calculators, it's not even really quite compatible. So if Intel can't even get X86 right then how are we gonna do it? So the next option is ARM, which sounds great. It stands for the Acorn Risk Machine. That means it's probably pretty simple. So let's look at the L-D-M-I-A-E-Q instruction which has so many letters in it that can't possibly be a risk machine. So what does this do? It loads multiple memory addresses from the stack or multiple memory addresses. It increments another address which means that it writes to seven registers, reading six from memory. It's conditional. So it only executes if the equality condition code is set. It can write to the PC because on ARM the PC is an addressable register for any instruction. So that means that it can change control flow. So it's effectively a conditional branch along with doing a bunch of loads. Additionally, it can change the instruction set because ARM encodes the thumb instruction set in the lowest bit of the PC. So that means that something we use as an idiom for pop the stack in return is also capable of doing a bunch of other stuff which is a recipe for disaster. So now we look x86 and ARM really aren't viable. So at the time we started a three month long summer research project to design our own ISA. And four years later, we managed to actually release the base user ISA specification that was frozen. And of course, it took us four years because we were doing a lot of things in the meantime. So one of those things we were doing is we were taping out chips. Oops, I've got myself confused. Yes, sorry. So while we were taping out chips, we spent a lot of time working on the ISA and we are quite confident that it's the best ISA. And one of the reasons is because we have lots of metrics for it. So remember the ISA is designed to scale from microprocessors to supercomputers. So one of the most important metrics for a microprocessor ISA is the static code size because you're frequently trying to cram your code into a small memory. So you see risk five has the smallest static code size across all instruction sets. ARM's thumb too is somewhat close but none of the 64 bit instruction sets are close. So an important metric for supercomputer or high end implementations is the number of dynamic bytes fetched. So the number of dynamic bytes fetches are largely the maximum performance you can get from the machine. So risk five has the smallest number of dynamic bytes fetched across all instruction sets. It's smaller than S86. Usually people think that Sys construction sets are fairly densely encoded. And additionally it is 25% smaller than ARM. So like I said, we are co-designing the ISA and you can't design an ISA without implementing it in silicon. So as we, at Berkeley, as we design the ISA we additionally taped out chips with it. We taped out about eight chips before the final user ISA was frozen. People say, well in order to tape chips you need all sorts of state-of-the-art machinery. For example, in order to do a board you need a state-of-the-art reflow facility. Which we built with a toaster oven in Remus' kitchen because there was no other way to do it. So we had a raspberry pie attached to a temperature sensor and we would match the reflow profile from the manufacturer for the solder. And in order to match it you'd turn the oven up a little bit to make it hotter. And when it got too hot you'd open the door a little bit so it would cool down. Very advanced. And we used that to solder the board for the, for EOS 22 which was the first implementation of the final frozen risk five user specification. So this is all the hardware effort. I'm largely a software person. So this is how I started, got started with the software effort at Berkeley. So this is our lab. It looks very different than the hardware lab because it's a software lab, right? It's a lot of desks, but it's an open labs. That means you can hear what everyone else is doing. So I, the time was working on a different project that was less interesting than risk five. And I heard Andrew who had been designing the ISA and working on the tool chain talking to Chris who at the time was building a processor and they sat kind of right next to each other, right? And I kept hearing Chris say, oh gee, you know, G-Lib C doesn't compile today. Or I can't figure out why drystone is getting bad performance. And that seemed more interesting than what I was doing. So I thought, hey, I'll just kind of go help out. Okay, so that was in 2012. Two years later I submitted the first patch to an open source repository mentioning risk five. So this was like a two line config.subpatch. I thought this was a really big deal at the time. Andrew and I talked about it for like an hour. We poured over the thing to try to get it right. And now, four years later and about maybe 100,000 lines of code more, we have been accepted into G-Lib C, Linux, Phoenix Hills, and GCC. So the core of open source software is available released for risk five. Yeah, it's a big deal. Thank you. Okay, so now we're gonna switch gears a little bit. I'm gonna talk about the current state of risk five. So the current state of risk five is really defined by the risk five foundation. So the risk five foundation is a non-profit foundation. It has over 100 members and its charter is to steward the risk five ISA. So this means maintaining the ISA specifications, evolving new extensions and this sort of thing. So you'll see there's a lot of member companies up here. If your members logo is up here, I'd like to say thank you for joining, thank you for helping to contribute to open source hardware. If your members logo is not up here, sorry, but we're now big enough that we can't fit them all on one slide. So somebody had to get dropped. And if you're working for a company who is not part of the risk five organization, you should really join because, well it's great because you get to work on open source hardware and it's also, it's a lot of fun because you get to work on all sorts of interesting things. So the risk five specifications are really the core of what the risk five organization maintains. And the risk five user specification is designed to be a modular specification. So this means that you don't have to implement either the whole ISA or some of the ISA. Sorry, you don't have to implement the whole ISA, you can implement parts of the ISA. And this is what allows us to be scalable to implementations from the low end all the way up to the high end. So in addition to the user ISA specification, which is largely what you interact with, when say writing compilers or writing user code, there's a privilege mode specification. And this privilege mode specification allows supervisor software to run. So Linux is ported to the supervisor, or Linux is ported to the supervisor mode in the privilege ISA specification. We also have a hypervisor mode that will allow hypervisors to run. Okay, so in addition to these, we have what's called an external debug specification. So this allows you to bring up early boot software via a JTAG debugger. And this is a very important component of a kind of real computer systems. It's how you make things actually work. So there's one specific specification I'd like to kind of call out on its own, and that is the risk five memory model. So risk five has a weak memory model. And I think we're unique in having at least a draft of the formal model that's actually been kind of proven to match the pros model released before our Linux port was released. And this is really nice. It helped us actually find a handful of bugs in the Linux port as we were upstreaming it because there are a lot of very smart people in the open source community, and they're willing to pour through memory model specifications, which I find very confusing, and help me debug my code. So this was a really important step, and this is something you could only really get with an open standard ISA. So the real key development in the current state of risk five is that our software is now upstream, as I mentioned before. So Binyatil's has been upstream for about a year. It released originally in 2.28. The 2.30 release is pretty solid. We don't know of any major problems in it. Similarly, GCC released in 7.1 maybe six to nine months ago. The current release 7.3, which also came out a few days ago, is also pretty solid that can compile Linux and much of user software and that sort of stuff. Linux, which released about a week ago in 4.15, is the first release with risk five. So that means it's kind of right on the bleeding edge and things tend to be a little sticky there. So particularly for Linux, that means that none of our device drivers are upstream. So while nominally there's a port, it means you can't say take an interrupt or get to user space or write to the terminal. So it's not that useful, but we do maintain out-of-tree patches for all of these and I am submitting patch sets to the next Linux release because the merge window is open now and I was supposed to submit one on Wednesday, but we've been writing the talk because we're very excited about this. But hopefully we'll have that all released, probably not for 4.16, but hopefully for 4.17 and then you'll have upstream of the core system. G-Lib C similarly was very recently released. 2.17 came out on February 1st a couple days ago. The RV64, which is the 64-bit support, that's largely there, but RV32i support, which is our 32-bit ISA, that's not in. The port exists, we have it out-of-tree, we just didn't have time to get it kind of properly bug-fixed and we wanted to make sure that what we submitted was stable and ready to use. And the most important target for porting, say Linux distributions and such, is the 64-bit support, right? So I am a maintainer of all of those, but I couldn't do this by myself because porting software is a massive effort. So I'd like to thank the various other companies who have allowed their engineers to help me port RISC-5 software. I'd like to thank Berkeley, who still pays a couple of grad students to maintain RISC-5 software, they're still left over. We have Red Hat, who's helping maintain G-Lib C. Blue Spec is helping maintain both G-Lib C and GDB. And then Andes has done a lot of work on GCC and also LLVM, which I'm not a maintainer of, but I'm very happy for the help. So that's the current state of RISC-5. We've come a long way in the last four years. Now I'd like to talk about the future of RISC-5. So I mentioned that there are some deficiencies in our Linux port and G-Lib C port, some large deficiencies. There are also a few small ones in our Benutils and GCC ports. So one of these is that our linker relaxations are quadratic time. So RISC-5 uses something called linker relaxation in order to keep the ISA small. So what this means is that instead of adding a bunch of additional addressing modes to the ISA, you rely on software to implement these addressing modes. So for example, on the left here, well, I have a pointer. You can see here is a simple program that just loads a global variable and returns it. It's kind of nonsense because start wouldn't return in it, but it's just there to drive the compiler. So this program compiles to assembly code without linker relaxation that requires two instructions in order to load that global variable. A Louis, which generates the top 20 bits of an address, and then a load word, which generates the lower 20 bits of an address. And these are offset from zero. So that gives you a four gigabyte range around zero, which you can put your global symbols on. And as you can see, it requires two instructions. So in order to make this faster, we've introduced a global pointer, which is common optimization like systems like MIPS have it. And that allows you to have a smaller four kilobyte offset around the global pointer, which you can load in a single instruction. It turns out this is important for the performance on a lot of programs, most importantly, drystone, which still drives a lot of people's processor buying decisions, unfortunately. But it means that we get very good drystone performance. Now the problem here is that, so you can see, we convert the Louis LW pair, which is an absolute addressing mode, to a single LW that's GP relative. But then you end up with this NOUP. So when you remove the NOUP, because you have to remove it because if you didn't remove it, you'd just be accidentally in a NOUP, which would still take the same number of instructions that wouldn't help you at all. So we move it by shifting up all of the code below it. And that results in a quadratic time link for RISC-5, which can be quite slow if you're linking a large object, particularly if you run into something like Linux. So we have some infrastructure in Binyutils for doing linear time linker relaxation, but we haven't converted all of the relaxations over to do that. So if you're interested in helping out in RISC-5 software and you like hacking on Binyutils, this would be a great place to start. So similarly, we have a few deficiencies in the GCC port. I mentioned LUI and LW before. So in this case, we have a similar program that loads a single global variable, but in this case, it loads it twice. So in RISC-5, we have two addressing modes. We have absolute, which uses LUI, and we have PC relative, which uses OIPC. In both cases, you have two instructions, one that loads the top 20 bits of an address, and one that loads the bottom 12 bits. It's just that in the PC relative case, you're loading a 20-bit PC relative offset instead of a 20-bit absolute offset. So as you can see, in the PC relative mode, we cannot perform constant sub-expression elimination on the extra OIPC because it's actually not a constant because the PC changes between here and here, so it produces a different value, which is why you have the two load words also requiring different offsets. So one optimization that's missing from our GCC port is the ability to form effective constant sub-expression elimination on OIPC pairs like we can for LUI pairs, and this would help the performance of our PC relative addressing modes. Okay, so I've talked a little about RISC-5 software. For the last few years, we've been maintaining forks of all these projects in our own GitHub organization, which is github.com slash RISC-5. So there's also a RISC-5 mailing list you can go to contribute, but now that we're upstream, the development is moving largely to the official repositories. So this means you can go to, say, the Binyutils mailing list or the Linux mailing lists and contribute to the RISC-5 port just like you would with any other project. So in this case, we're really excited to have people start contributing. So if you're interested, please kind of pick your favorite project and start working on it. So I mentioned the, so we're talking about the future of RISC-5. So in this case, what's really gonna be coming up over the next few years are Linux distributions on RISC-5. So I've talked to a few people here and kind of IRC and whatnot, and we have a Debian port that's going. It's sort of in the process of being bootstrapped early in the process, but there's work being done. Additionally, there's a Fedora port. So the Fedora port is also in the process of being bootstrapped. The bootstrap was done at one point, but it was for a slightly older version of the ABI. So it needs to be redone. But hopefully over the course of the year, we can have Fedora and Debian come up. We have a little bit of support for RISC-5 in Open Embedded. We have some of the core tool chain support, but we have not bumped this since G-Lib C came up. But again, hopefully that will follow on soon. Open WRT, we have a maintainer for it and there's important progress. I believe he's here, but I don't know how far that's come along. And also Gen2, I submitted an arch name for Gen2, but we don't have any packages. So while technically we have a port, it doesn't work, but that's kind of how it always gets. Okay, so the real key here is that if you are interested in any of these projects or really any other project, now is the time to get started porting your favorite project to RISC-5. Because it's a free and open ISA and the only way we can make this work is if we have support from the whole community. And software porting is a huge effort, as I'm sure everybody knows. Now, in addition to new software reports coming out, the RISC-5 Foundation is also working on new specifications. Now, one of these, one particularly interesting one is the V extension, which is for, it was an advanced vector extension. So it's based on a Cray style vector, but it's kind of been updated for the modern world. It's targeted for both spatial and temporal vector machines, which is interesting because usually you have, for say, different spatial SIMD machines, you have very different vector ISAs as you move to longer widths, but the goal here is to have a single ISA that can execute across all classes of machines, much like how the RISC-5 user ISA can execute from small embedded microcontrollers to large super computers, the same thing. If you are a, say, LLVM vectorizing compiler expert or a GCC vectorizing compiler expert, this is a great time to start working on a real cutting edge vector ISA without all the headaches of the existing one. There was a presentation about this at the RISC-5 workshop in last December, December of 2017, and there's a draft expected by the end of year. Now additionally, we're working on something called the J extension, which is for advanced JITs, and this really means JVMs like OpenJDK. So there's also a standards process going through with this, and if you're interested in working on, say, a JDK for RISC-5, now would be a great time to start because the standard body, the working group, which writes the ISA extension, is just being formed now. So you can hop on the mailing list, be part of the J extension from the start, and help port a Java implementation to RISC-5. So in addition to that, we're working on something called the Unix platform specification. So this defines the interface between software, or sorry, between the boot loader and the kernel, and this allows you to make sure that your Linux distribution can boot on your hardware. The working group for this is not yet formed, but we're working through it. Now, a year ago, Sci-5 released the Hi-5.1 board, which had the Freedom E310 chip on it. That was an embedded microcontroller, and it was very popular. We've shipped it to 50 countries, and we've had lots of uptake from various embedded developers porting their systems to RISC-5. So now, in order to grow the RISC-5 Linux-capable ecosystem, what we really need is a Linux-capable RISC-5 board. I'm happy to tell you today that the future of RISC-5 is here. So we've actually been giving this entire presentation on a Linux-capable RISC-5 chip. So it's running the full RISC-5 Linux software stack, so it's running in X, Hardware Seller 3 graphics and a piece of Xpress and whatnot. And this is so cutting edge that Yonsep, in order to get the board here on time, had to fly to Fosdem the day after me because we couldn't get the chip stuck on the board in time for my flight. And he's very excited to come and give you a few words, and after that, we'll give you a demo so I can actually prove to you that this is running a real RISC-5 Linux system. So this is high-five Unleash, the world's first multi-core 64-bit Linux development board. As a matter of fact, it came out of the fab two days ago, so you guys are the first audience to actually see it. So this is really cutting edge. So what's on the board? So in the middle, you can see the sci-fi Freedom Unleash 540 chip. It's the first stepping of the chip. It's built in 28 nanometers. It has four 64-bit application cores, which implements the RV64 GC ISA. There's one management core, 64-bit, which implements the RV64 IMAC. There's a coherent two megabyte L2 cache inside it. And probably you can only see five DRAM chips here, but there's four DRAM chips on the other end too. So the board supports 64-bit plus ECC DDR4. And as you can see, there's Gigabit Ethernet. There's an integrated Mac. There's also the micro SD card for removable storage. And last but not least, there's the FMC riser socket so that you can put in additional IO cards. So for example, today we have mounted this board on a PGA, which supports PCIe, and that is supporting all the graphics, the SSD, as well as the clicker, as a matter of fact. So at the end of the talk, you will see a demo with accelerated graphics. And obviously, the first thing that we have to show is quake running on the actual chip. So let's look into the chip a little bit more. You can see the closed up shot of our cute chip there. So this is a block diagram. As I told you, there's one E-core and four U-cores. And in the middle, there's the coherent L2 cache and a bunch of low-speed peripherals on the right, as well as the Gigabit Ethernet. There's OTP, there's Maskrom. And notice that all the components on the SOC are connected with Tiling. So Tiling is a free and open SOC interconnect standard that we started building from Berkeley days. So all the specs are online. So there's something called ChipLink, which is a serialized version of the Tiling to expert all the traffic and accept traffic from the FMC socket. So the FPGA is connected to that. And it's exciting to tell you that, you can buy it now. You can go to our website, and I have to note that the early access boards, we only have 75, and I can count, I think you have more than 75 here. So I would go right now. I see some laptops opening. Yes, that's what I'm talking about. So the FU540 chip is an instantiation of the Freedom Platform, which is a open-source RISC-5-based SOC platform maintained by PSI-5. So in the Freedom Platform, what's inside it? So we have open-source the RISC-5 rocket CPU, and the Tiling, the free and open interconnect that I've told you, and a bunch of low-speed peripherals like SPI, UR, PWM, and I-squared C, things like that are all open-sourced. And there's also the high-speed Xilinx FPGA, DDR, PCIe controllers, and FIs that we have onboarded onto our platform, as well as the L2 cache, which will be open-sourcing alongside the high-5-unleashed launch. So, as I told you, the Freedom Unleashed 540 chip is based on the Freedom Platform, but unfortunately, there are things that we can't open-source. For example, the things that we got, the IPs that we got from the third parties, such as the standard cells, the pads, the PLLs, the OTPs, the mass grounds, the DDR controller five, the gigabit Mac. So, sadly, I have to point out that the chip, the FU540, is not a direct instantiation of the Freedom Platform. However, we'd love to work with the community, you guys, to hopefully make this a reality one day where everything on the chip is open-source and we'd be more than happy to build that chip together. So, in order to figure these, to look at the code base, you can go to our github.com, forward slash sci-fi, forward slash freedom, as well as dev.sci-fi.com. So, what can you do with this? Well, you can map the Freedom Platforms onto FPGAs. So, for example, we can map the Freedom Everywhere Platform on a $99 arty board. And you can, our do-we-know shield compatible, so you can plug in a lot of things. And also, for the Freedom Unleash Platform, you can map the platform onto the VC707, which has DRM and PCIE and things like that, so you can run Doom on it. So, what you can do is you can customize your Freedom Platform for your needs and sci-fi, you can come work with sci-fi to actually realize it into an actual chip. So, why do we open-source the Freedom Platform? Well, we all seen how open-source revolutionized software. Now it's time for hard work as well. So, once the base platform is open-source, that means you don't need to do all the grunt work to just get SOC platform up and running. You can focus on the part that really matters to you. Just like how we build software. We don't build an operating system just because we want to go build an application. There's a lot of good things that we leverage in the system out there. And what we want to do is we want to build this ecosystem together with open-source developers, as well as for-profit IP companies, to come work with the Freedom Platform so that you can customize a chip. And once you're ready to build a chip, you can come to side five and we can turn that into a piece of silicon. The quickest, the fastest, the most cost-efficient, and the fastest, that's what we're about. So, hopefully by now I have convinced you to join the RISC-V revolution. Thanks for your help. We have built the RISC-V software ecosystem pretty well. And as we told you today, the RISC-V hardware is here. Already. So, we hope that you all go and start porting or building your new software based on RISC-V. So again, you can buy the High-Five Unleashed Development Board. You can go to our website. And also, for updates, you can sign up at dev.sidefive.com. Okay, now we're gonna go see the exciting demo. And after the demo, we're gonna have a quick Q&A session. And if you have a lot of questions and wanna talk to us, there's actually a boss session after this from six to seven at this real location. So, we'll all see you there. I believe the RISC-V readers are gonna be given to the winners there. So, we'll go check it out there. So, thank you very much. All right. So, how do you prove that it's a RISC-V system? Well, let's take a look at the unit. It says it's a RISC-V64 machine. Let's go look at the CPU info. All right, let's go look at the LSPCI. Okay, so you see a bunch of stuff here, including the graphics card, right? Okay, now let's look at accelerated graphics. Now, we're ready to take some questions. Thank you. Questions? Hi. I was wondering what's the status for your embedded, more like pure embedded platforms, like in non-MMU targets, and if you're planning to release development boards on that as well. Yeah, so for like no MMU Linux? Yeah, sorry, so the question was, what's the status of our embedded targets, like no MMU Linux? So, right now there is no MMU Linux port. We like one, it's just, it's a lot of work, and right now I'm kind of oversubscribed. So, I would translate that into, we need a lot of your help. So, how is the virtualization support, if you want to run, if you don't have a board, I want to run, I think QMU, or if you have another virtualizing solution. Yeah, so we have something called, so the question was, how is the virtualization support? If you don't want to buy one of the boards or aren't one of the lucky 75 winners, how can you run your code? So, we have a QMU port, it's not upstream yet, but we're working through getting it upstream. We're finding some issues, but nothing super major, so hopefully it'll be in soon. There's something called FreedomUSDK, which is the SDK that goes along with the board, and that has a Linux version that's known to work and a tool chain that's known to work and some bootloader stuff, and if you go in there and you type make QMU, it will boot in QMU with a disk, and you can do whatever you want. It's build-root-based. Very quick question. And your proxy, for I solve four cores, you also have a management core. What does the management core do? Have you heard of the concept of a donkey engine, which is a small engine you use to start a very big marine diesel engine? I work in high-performance computing, and I've always said that we need chips where you have cores that work in flat-out, doing computations, but you need a smaller core, actually running the operating system and doing the housekeeping, and is that what that core does, or? Yeah, so the question is, what does the fifth core do? You only see five cores in proxy pu info. So, right now, it's asleep. It's supposed to be a power management unit, but we don't have that implemented right now. But the idea is that, yes, if you wanted to build for HPC systems with additional cores around the operating system, that'd be a great opportunity for customizing a RISC-5 chip, and that's something we do, and a lot of people aren't interested in that sort of thing. Parma, thank you for your talk. Great to hear the progress. I'm glad that we're part of the work on that tool chain. Can I just pick you up on one thing? You described RISC-5 as the first free and open ISA. How do you see RISC-5 compared to open RISC, because I'm sure the open RISC guys would feel that much as most of them are working on RISC-5 now, they possibly were there before you. Sorry, so they said we described it as the first free and open ISA. I don't, if I did, then that was a mistake. Yeah, I think we tried to say the first free and open Linux-capable processor platform, I think was what we said. That's all you meant. Yeah. That's what you meant. Yeah. So, you know, just to add on a little bit to that, when we started the RISC-5 project in 2010, we did look at open RISC at the moment, and one of the big things that we needed was 64-bit support, and at the moment, open RISC was just started to develop their 64-bit implementations, so. Yeah, sorry, one more thing. This is Jeremy from Mbacosm. Their name didn't make the slides because we were up very late making them, but they've been helping a lot with the GDB port, and without them, it would be not passing many test suite results at all, and now it's passing most of them. Thank you. Yes, thank you very much. So, you said it's suitable for the RISC-5 from the smallest to the biggest machines. Now, I've seen a lot of 8-bitters replaced by ARM 30-bit stuff, but the 8-bitters are still there. I believe you, with your code size stuff, you can easily replace the arms on the small microcontrollers, but how about the 8-bitters? Will RISC-5 replace them, or do we need another initiative like RISC-5 this time aimed at 8-bit microcontrollers? That's a great question. So I think your question is, how does RISC-5 compare to 8-bits? RISC-5 will be bigger than the 8-bit microcontroller slightly. I think one perspective I want to say is I think a lot of the microcontrollers doing more computation and things like that, obviously there are applications where 8-bit microcontrollers do just fine. And I think RISC-5 will do okay on those things, but it would be hard to beat the 8-bit microcontrollers, but if you're needing more compute power on things like that, I think this 32-bit RISC-5 is a fine target for those type of applications. Okay. I have the next question. Just to counter the 8-bitters, if you think about the pad size you need for connecting to the chip, it really doesn't make sense with the current process to use 8-bitters because the pad sizes are so large compared to the core that the price for a 32-bit doesn't matter anymore. But I have another question. What's the PowerPoint I've seen of the chip? I've seen heat mount holes on the PCB. Yeah, you're very sharp and was paying attention to the talk. Yes, so the board is the first revision so we had developed the board to put a socket in so that we can test multiple chips. But yeah, great catch. It's now for the heat sink. We're not burning 135 watts. I'm sorry. So right now we're measuring it but it's gonna be between a couple watts, one or two. How are you providing graphics acceleration and is there a plan to provide graphics acceleration using RISC-5 as well? So the question is how are we doing our graphics acceleration? So right now there's an ATI graphics card in a PCI Express extender box. You wanna try to roll it out? Yeah, it might not roll all the way out. It's always bad when the wire falls out and the demo keeps going. Yeah, but yeah, that's why we have the little card because there's a lot of stuff. Yeah, so there's an AMD graphics card in there. It's a Kaco Space Core. It's a few years old. It's one of the ones we could find a boot with very minimal firmware and that sort of stuff. So yeah, it kind of even works. Yeah, so that's doing the vast majority of the rendering. So it's just using the regular kernel drivers at the KMS and DRM and then Mesa in user space. And that kind of all just compiles and more or less works out of the box. We've been a lot of pushing on our kernel port over the last say year to get kind of devices up and running. And it's at the point where like, when I first started working on this stuff, if you ran something you hadn't run before, like there's no way it would work. Now when you run something you haven't run before, it might work like Quake kind of just worked. The hardest part to getting it to work was figuring out how to get it to go full screen because I didn't know the command line options. And I just like to add a little bit on the integrated graphics part. So we don't have IP today. So we need to source the IP from somewhere. Obviously there are some open source implementations which we're more than happy to onboard onto our platform. Once we onboard it, we can implement the chip for anyone who requests to build the chip. And in parallel to that, we started a program called Design Share for the for profit third party IP vendors to onboard their IP onto our platform. So that once you come to sci-fi to build the chip, we can include third party for profit IPs into the chip. And we're trying to cut down the prototyping cost of building a chip so that it's affordable. And it's basically, you will pay the full IP price when you go to production. So you don't need to pay it upfront for the prototyping phase. So there are some IP vendors for the integrated graphics that we're talking to today. Hi, I've got a two parter. So the first part is what are you doing to ensure that the ABI doesn't change again? And the other part is, can you go through the current status of platform standards? Again, to make sure that you retain compatibility for these platforms over time. Yeah, so the question is, how do you make sure the ABI won't change again? And how do you make sure the platform specs are set? So they won't change again. So, I mean, the ABI won't change again because we're just saying it won't change again. It's done, it's never, it's not changing. That's it, that's kind of how you make it not change as you just say it doesn't change. For the platform specific, right. So before when we were not upstream, we hadn't put a stake in the ground saying the ABI is not changing. Now that we are upstream, it's like every other port we're maintaining ABI compatibility kind of forever as far as I know, as long as I'm around at least. So, and then for the platform specifications, because there is no platform spec, there's kind of, there's nothing there, but we're producing one. The risk by platforms that exist are simple enough that the hope is that we can ensure that they will match up with the platform spec well enough that they can boot things and you can discover what's there and what not. But that's kind of, that would be a great way to get involved if you're interested in, so the platform specifications, that's something that's gonna be a lot of work over the next, say, a few months to a year. I mean, it's really important stuff because we don't want it to go the wrong way because that can have a lot of headaches. First, I wanted to say thank you for making it a free and open design, that's fantastic. It's great that that sort of thing exists now. And recently, you know, there were processes that had issues due to the Spectre and Meltdown bugs. And I'm curious to know, when people, when people wanted to mitigate that, one of the things that you have to do on some systems is install firmware, not firmware, but a microcode update. And that microcode is usually non-free. And I'm curious to know if the issue of free versus non-free microcode is orthogonal to having an open design or if you feel that having a free and open design facilitates the creation of free microcode updates. That's a great question. I have to say that the ISA is really orthogonal to Spectre and Meltdown. For example, anyone can take the RISC-5 Spec and implement a machine with microcode inside it. And, well, they have to secure it and they have to have a way to upgrade the microcode. And in that case, you know, the vendor could make a decision to make that API open or close proprietary. I have to say, although our processors from Sci-Fi, we don't have microcodes. So, you know, it's good in the sense that there's no software that's running that you can't see, really. But then on the flip side is we have to get the processors right in implementation. I see, that's really cool, thank you. And I'll have to say the current FU-540s are implementing in-order pipelines. So these processors are not affected by Meltdown and Spectre. So if you want a processor, that doesn't run any code on the side and it's not, no, subject to Meltdown and Spectre, this is your chip. Oh, thank you. Wow, a lot of affodding today. What's the performance of the chip you have there compared to recent ARM cores, which also in-order designs and also when you look at the chip space, so the space which Core takes? Right, that's a great question. So the U54 is a single-issue in-order pipeline. But it's a 64-bit pipeline. So it's somewhere between ARM, I think, A35 and A53, somewhere in between that. And the processors can run up to 1.5 gigahertz in terms of frequency. So the E51, the bookkeeping core that was on the side, doesn't have an MMU and that resembles more of a Cortex-M series. And that is similar to M23 and M33s, although it's a 64-bit embedded core, which ARM doesn't have, so not applicable. Okay, thank you very much again, and we're out of time. If you have further questions, I'm sure they will be happy to answer. Please come to the bot session if you have more questions. Thank you so much.