 Felly, rwy'n dechrau'n gweithio y cyfnod o ddegonio sydd y bydd ymwygarol. A'r fywr'r gwybod yn ddegasgynig o'r gwybod ymwg dda, ac yn ddegosodd gan oed o'r gwybod o'r gwybod fel pethau oherwydd, a phobl iawn o'n ddegosodd gwybod i'n ddegosodd gyda'r gwybod. Felly mae'n grwybod i ddegosodd. Felly rwy'n ddegosodd yn ddegosodd yn ddegosodd yn ddegosodd o ddegosodd. Dw i heddiw y gallai cinswch ar wneud ymlaen, a siaradau ar hyn, a eu hefyd yn birwyddol nad y troio i ni'n ymlaen. Rydyn ni'n ei dweud fu y dyma, yr hynny i chi hefyd. Rhyw hwn ni'n iddo, mae'n rhaid ddim y nhw mewn gwirionedd yma. A'r rheswm yn trefnill i chi'n gyfraimiao ar yr Yrys V. Mewn ymddangos, dyma'n rheswm yn rheswm ni'n meddylu ar y Hesr â'r Rheswm 5 o mynd i'r hen dim mewn yr Yrys V HAro. I'm not going to get in too much technical depth, but do feel free to ask me questions about all this stuff as well. So just before I get started with all that, just a quick self-introduction. So I'm a compiler engineer at MBocosm. Recently I've been working on a toolchain for a customized RIS5 processor and also a project to help developers write secure software using techniques in compilers. So MBocosm is a compiler toolchain consultancy. We do a lot of work with GCC and LLVM and we're members of the RIS5 foundation. So partly what I'm talking about is based on the experience we've gained at MBocosm, working with RIS5 over the last few months. So what is RIS5? And the answer to that is that it's a free and open instruction set architecture, or ISA. Now you might be wondering what is an ISA, what does it mean? And the definition or a description of it that I like is it's kind of the interface between computer hardware and computer software. It's a description of that interface. So if you have a piece of hardware that implements a particular ISA and a piece of software that's compiled for that ISA, then you should be able to expect that piece of software to run on that piece of hardware. Now that's kind of an abstract description. So it's trying to be more concrete. There's some examples of other ISAs that you might have heard of. The ARM ISA, Intel's x86 ISA, PowerPC, Spark. So in a sense you may already have an idea of what an ISA is. But what does the documentation for an ISA actually specify? What does it tell you? And broadly it consists of the things, the details that will be visible to an assembly language programmer and a bit more information as well. So an ISA description tells you things like what the registers are in the hardware, at what width they are, what data types they take, how many of them there are if they've got any special properties. It also will contain a list of all the instructions and all their semantics. And then encodings of all those instructions. How do individual instructions get translated into some packed bits or words or bytes or whatever that the hardware can actually understand? So that's roughly what an ISA document specifies. It doesn't specify everything. So the things that it doesn't specify in particular are, it doesn't specify how an implementation of a core implementer that ISA should work. So that means that you can have lots of different bits of hardware that all implement the same ISA. You can have a very simple core like maybe an order, no pipelining, very small that implements an ISA. Or you can have a very complicated superscalar deeply pipelined core or anything in between, or which implement the same ISA and can run the same programs for that ISA. It also doesn't tell you what software you should write for that ISA or how that software should be built. So you can have a variety of different compilers targets in that ISA. And then if a compiler targets an ISA and you can build software for that ISA, then you can have lots of different programs that will run on the hardware implement that ISA. So you can have a GCC implementation target an ISA and LLVM implementation. If Microsoft has started to implement one in Visual Studio as well, it could target any ISA. So now we've got a bit of an idea about what an ISA is. Let's look at the RIS5 ISA in particular. So I don't want to go into too much detail about it, but just describe some of the properties of it. One of the things that I really like about it is that it's actually quite a boring ISA. That sounds a bit of a funny thing to like, but it's actually a really good thing. You might expect that a relatively new ISA like RIS5 would have lots of advanced and interesting features. But in practice, having lots of advanced and interesting features makes it difficult for everyone, difficult for hardware implementers. If they've got to implement lots of complicated things and features, difficult for compiler writers, because if there's lots of different ways of doing things and lots of constraints on all the different features you have, it's more difficult to generate efficient code. So the RIS5 ISA is kind of a bit like MIPS. I think it was originally started as a modification MIPS and then sort of grew into something else in its own right. But it's got lots, or doesn't have lots of the things that would make MIPS a bit more complicated, because it's a RISC ISA. It's got a relatively simple, small set of instructions, and the register files are relatively uniform. They don't have too many different things going on with lots of different registers. I don't have too many different things going on with registers. I will elaborate a bit more on that in a minute. So the ISA is designed to be targeted at a really wide range of systems as well, from the smallest, most deeply embedded systems, all the way up to very large, multi-core, high-performance systems. And you might wonder, how can one ISA target such a wide range of systems? And the reason is that the ISA specification doesn't target a... Sorry, the ISA specification doesn't specify a single ISA. It's not one size fits all. Instead, it describes a set of base ISAs, which you can then extend with different instruction set extensions as you need or see fit. So the base ISAs, they're either 32-bit or 64-bit. 32-bit ISAs, E and I, are both quite similar, the difference between them being that E's only got 16 registers, and that's just designed for the very smallest of systems. The 64-bit ISA is similar to the 32-bit ones, but extends the register width to 64-bits. One of the boring things about RISC 5 that I like so much is that the instruction width for all these base ISAs is just 32-bit. It's simple, there's no variable-length instructions in the base ISA. So that's something that makes it easier for the hardware implementer. It makes instruction decoding simpler, and it's easier for the compiler engineer because instruction scheduling is easier. All of these base ISAs give you an architecture that can do integer arithmetic only without even having multiply or divide operations. So they're quite basic. Because of that, there's various different extensions that can be added on top of that. So the standard set of extensions on the left, you can add multiply and divide for integers, atomic operations and floating point units. Some of the more esoteric extensions on the right, I think non-standard ones, include things like forward precision floating point and decimal floating point and bit manipulation, things like that, lots of different things. So because there's all these different base ISAs and all these different extensions that you could add on top of them, you could have lots of different cores and slightly different variants of the ISA. I think in a way that could lead to a little bit of unnecessary fragmentation of the ecosystem. So one thing that combats that a bit is that there is a standard set of ISA extensions called G, which is shorthand for having integers with multiply, atomic operations and a floating point unit. So you would commonly expect probably a lot of targets to have all of those standard extensions. So it's worth noting that I think for a general purpose, a limit-based system, you would expect it to target something like RV64, so the base architecture with the standard extensions and then the C extension as well for compressed instructions. So I think a lot of limit systems would probably end up targeting that. Okay, so that's sort of the way the ISA is structured. And I want to talk a little bit about the particular RIS5 ecosystem. So I'm going to highlight some things in the ecosystem that I found interesting, or that have caught my attention for some reason or other. There are lots more things in the ecosystem as well that I haven't noticed or just haven't got time to talk about now. So this is just really a small subset, the idea being to show how many things are going on with it, sort of how the ecosystems grow in thriving. So in terms of hardware, over the last few months I've noticed at least 20 different implementations that cause implement the ISA or system-on-chips based on cause that implement the ISA or chip generators. Some of the ones that I think are quite interesting in particular are the Risky core from the pulp platform, Clifford Wolff's Pico RV32, the rocket ship generator from Barclay, PSY5's freedom system-on-chip, the low-risk system-on-chip. Now, as I say, there are lots of other cores as well. It's not to say that all those aren't interesting as well, but they're just interesting for probably different reasons that interest me. On the software side, there's a port of all the GNU development tools to RISC-5. The GCC and Binutils ports are now upstream and the process of upstreaming the other parts of that toolchain are in progress as well. There's also a port of LLVM, which at the minute is working progress, but it seems to be shaping up quite nicely. In terms of operating systems, there's at least a Linux and a free BSD port. I noticed there's a port of free RTOS, which is a real-time operating system. And also that the Fedora Linux distribution has been bootstrapped on RISC-5, so there's a version of the Fedora distribution with all the packages and everything for RISC-5. As well as things that are purely hardware and software, there's things that I see as being on the boundary of software and hardware, so simulators and emulators, that kind of thing. So there's the SPI Kaiser simulator, which is kind of the golden reference implementation of the ISA, which you can use to compare against if you're testing your own ISA. There's a port of QMU for RISC-5 as well, so you can use that to run a RISC-5 system, say on top of your Linux desktop. There's also a project called RVA, which seems to be quite an interest in looking RISC-5 to X86 binary translation system. It looks like quite a cool project, but I haven't had time to play around with that yet, but it looks like a really nice piece of work. So I'm just going to talk in a little bit more detail about some of those calls in particular, because I think they're interesting starting points, hopefully of interest to... hopefully of interest. So first of all, Clifford Wolff Pico RV32 call. I wanted to draw attention to this, because I think it's a really great starting point if you want to get into understanding how the implementation of a CPU works, because it's ever such a small and simple implementation with a few hundred lines of veralog. Even someone like me who's not really a hardware person, I just kind of have a shaky grasp of veralog at best, I can sort of read it and get an idea of what's going on and make small modifications to it. So it's a really good thing to start with for tinkering. It's been designed in particular with being able to put on an FPGA with a very high clock rate, so it goes up to several hundred megahertz on various different FPGAs. The trade-off with it in some sense is that it's a little bit slow in terms of cycles per instruction, so in some benchmarking that I've done with some small embedded benchmarks, the Beves benchmark suite, when I measured it, it seemed like it was taking about four cycles to execute an instruction on average. The next core that I find quite interesting is the Risky core from the Pult platform. So it's a little bit more complicated than the PicoRV32. It implements a four-stage in-order pipeline. Because of that, it's a bit faster in terms of cycles per instruction than PicoRV32. The benchmarking, it seems to manage to do about one instruction per cycle. So for a back-of-the-envelope calculation, it's about four times faster to put megahertz than PicoRV32. Now, as I keep iterating, I'm not a hardware person, so if that's a really stupid calculation to do, please shout at me. Because it's a bit more complex than PicoRV32 and it's got this pipeline, the implementation source itself is a little bit more complex. It's a little bit more than I can sort of get my head around with a limited experience of very long. But if you're kind of familiar with hardware design, I imagine you'll still find it quite straightforward. Also, looking at the source code, it is so immaculately designed and laid out. It's really nice to look at a really beautiful project. There's also the rocket ship generator from Barclay, and that's something that's much more complicated than either of those two other cores. So you can use it to generate various RV32 and 64 cores with different extensions, as well as a whole system on the chip with different cores on them, a network and peripherals and all sorts of stuff on it. The implementation of the rocket ship generator is done in Scala and a language called Chisel, which is a domain-specific language for designing hardware in Scala. So that toolchain itself allows you to generate implementations either for verilator to produce a cycle accurate model, or you can target FPGAs, or you can target VLSI tools, as well. As I mentioned, it's very complex. It's not something that I've been able to get to groups with myself, but if you're more familiar with hardware or Scala or all those kinds of things, it might be quite interesting to look at. One thing that I do think is quite interesting about it is that it has been used to generate various chips that have been taped out for research purposes at Barclay over the past few years. One other thing I wanted to talk about is some actual RIS5 hardware that you can buy now, which is Freedom E310 system on a chip, and that comes on that Hi5 One board, which is a board with an Arduino form factor with that RIS5 chip on it. So as well as being able to fit an Arduino shield to it, you can also program it using the Arduino IDE. I think it's a really great starting point. If you're interested, it's not so much in hardware, but doing software development for RIS5 that you can just buy one of these, use the RIS5 toolchain with it and get developing. It's relatively inexpensive. I think you can buy it for $59 on crowd supply. Okay, so that was sort of a very little introduction to a few bits of the ecosystem that I've kind of noticed. Why is such a great ecosystem sprung up around RIS5? I think, or at least to me, it looks like the reason for that is that there's the free and open nature of the ISO. It kind of reduces the amount of risk you have and the initial investment you have to make to start developing hardware or software with it. So, for example, you don't need to buy a license for the architecture if you want to implement a core. You don't need to license hardware designs from anyone if you don't want to because there's lots of open source calls that are probably a good starting point. That's not to say that there won't be closed source designs and designs that you can license as well, but there's sort of a lot of choice there. There's also no charge for documentation on the ISO. If you do start developing something and you think, okay, I want to develop or sell a commercial and use a product calling it RIS5, then you do need to make sure that your implementation conforms to the ISO using the ISO test suite, and you do need to join the RIS5 foundation, but I imagine that's quite a lower bar than, say, selling a commercial product for a different ISO. So, lots of good things about the ecosystem. There are a few challenges as well, but I've noticed over the past few months that I just wanted to draw attention to. So, although the documentation is free, some of it can be a bit limited. So, here's an excerpt from the RIS5 assembly programmer's handbook. I don't know if you can read the small text there, but it says this chapter is a placeholder for an assembly programmer's manual. So, that will be coming soon. What that means in practice is that you tend to have to hunt around various different GitHub repositories to find a bit of documentation, or sometimes I just can't find what I'm looking for, do some experiments with the compiler tool chain instead to see what code it generates to get an idea about whatever it was that I was trying to find out. The second thing that I've found to be a bit of a challenge over the last few months is when things are going upstream. So, some parts of the software ecosystem are being upstream now, in particular Linux, NewLib and GDB. So, that means that before the upstreaming process is complete, they might be subject to change, so you do need to keep an eye on changes to those things. There might be incompatible or breaking changes that you find from a system you were using from an earlier revision. So, I mean, it's not a huge problem, but something you need to keep track of. Also, the ISA test suite that I mentioned that you need to conform to is a little bit basic. So, if you implement a core and it passes the ISA test suite, in theory it should be able to run programs that are for RIS5, but in practice it's still the room for lots of different implementation errors and mistakes you could make. So, what we've used to kind of get around that issue for now is the GCC regression test suite because that contains about 87,000 tests, lots of which are executed on the target. The idea of it being is that, to check that GCC's generated the correct code, but it's also sort of implicitly checking that the core is executing the generated code correctly. So, if you get some failures in the GCC regression test suite, it can pinpoint things that might not be right that need fixing. The long-term solution for this, I believe, is that there is a testing working group that's been appointed by the RIS5 foundation that are working on improving the ISA test suite. So, those three things are the main kind of issues that I've come across over the past few months. For the future, what's going to happen to the ecosystem? I think that those issues that I've talked about will just go away as things get upstream, they'll stabilise, the documentation will get better. All the implementations that we have, the bugs will get teased out of them and they'll sort of come to be seen as more dependable and more reliable. I've decided to take a risk of making a prediction of where I think we'll see RIS5 in the future. I think in the short term, we'll see it in lots of embedded systems, places where there's maybe some other small embedded core already, in things where what the processor is or exactly what it's doing aren't really the concern of the person using it. So, in things like all sorts of peripherals, like GPUs and hard disks and network hardware and things like that, the more medium term we're likely to see it moving into general purpose computing devices, I imagine you might see lots of single, sorry, small world computers with RIS5 processors. The kind of thing that would maybe be used in a phone as well. I kind of like the idea that maybe in a few years' time I'll be able to buy a RIS5 based phone. In the longer term, maybe we'll see it moving into bigger systems, maybe we'll service that kind of thing. I think the system builders and the customers for those kinds of products are probably a bit more conservative than the other two groups, so that's something that would probably take quite a bit longer. But it does seem like there's various system builders that are kind of interested in doing that, so we might see something like that. I don't want to make too strong a prediction about what I think is going to happen there. So, your laptop is screen saver. Seven or eight minutes. Anyway, this is to conclude. If you're now really excited about RIS5 and want to get started with it, where do you start? What the best starting point is, depends on exactly what you want to do. So if you just want to do some work with software, you just want to use your desktop PC, Linux PC, using an instruction set simulator, then the official RIS5 toolchain is a good starting point. There's a readme in the repository that walks you through building all the toolchain and the ISA simulator in not too many steps. So, with a little bit of work, you can get to a point where you can build and run RIS5 programmes. If you want to buy the Hi5 hardware instead and use that for development because you don't want to faff about the simulator or you're more interested in running on actual hardware, then I would use the SciFi Freedom ESDK instead, which is just a slightly modified version of the RIS5 toolchain that's a bit more specialised for that particular hardware. It comes with some examples as well. You can use the official RIS5 toolchain to build stuff for it as well, but it won't come with examples and you'll have to faff about with linker scripts and things. If you're interested in cycle accurate modelling, then, and because we've produced a couple of verilator models of Risky and PicoRV32, there are more details that I want to provide for that, so I'm giving a talk about cycle accurate modelling of RIS5 at Orconf next weekend, and I was hoping to release a repository of scripts and tools to build and use those fairly easily, along with that talk, but I'm quite around to doing that yet. If you're trying to do something a bit more advanced or scaring yourself using the rocket chip generator, then the rocket chip repository's got a read me in it that walks through building all that toolchain and getting started with it. So those are the different places that I would get started experimenting with RIS5. That's all for now. Are there any questions? Thank you.