 So, let's talk about the RISC-5 first. RISC-5 has been quite a big topic in the recent years. The market is estimated at $500 million this year and is predicted to double in two years. Western Digital was the first major industry player adopter and they used it for their Hydra microcontrolls. Alibaba has been developing high-performance RISC-5 cores for the cloud. NASA has recently selected cores from Sci-Fi for its next space mission. Google released new kernel just for RISC-5 and even Intel promised significant investments into RISC-5 and they have recently produced the most powerful RISC-5 SOC in existence in its five nanometer foundries. And finally, even MIPS technologies are now producing RISC-5 cores. So, we see that RISC-5 is quite a thing but for those who are not following the hardware scene so closely, let's recap on what RISC-5 is. So, RISC-5 is an instruction set architectural like ARM or x86. However, unlike those, it is an open standard instruction set architecture that is managed by a non-profit organization so anybody who wants to participate can join. The standard is also relatively free and is open source. Also, the core of the standard is really small and simple. It's in fact only 47 instructions so really anybody can start producing RISC-5 cores and it is also very extensible and customizable. But let's not forget how RISC-5 was created. It was originally meant to be a good ISA for research and education. And we at the Czech Technical University don't want to stay behind and both the faculties of information technology and electrical engineering have switched computer architecture courses to RISC-5. Moreover, both faculties have joined forces to produce high quality open materials and because we know that image is more approachable than text, animation is better than image and interactive animation is the best, we have developed a graphical RISC-5 simulator. QTR-VSIM which is free and of course open source and I'm here today to tell you more about it. But before we begin, one student of ours once said that nothing that does not run in the browser is relevant and we took him seriously so you can open this link and you can follow the presentation with your simulator running in your browser and it's native QTF. So first I will show you the hydro simulator looks and what can it do for you. Then we will just peek inside for those who might be interested in contributing to the simulator and in the end I will point you to some available materials. So let's go. The simulator is essentially a debugger with a lot of visualization and some extra useful tools. It comprises of flexible windows each representing a significant part of the computer system. So if you look at basic configuration, we can see a program memory view right here. It has the memory address, binary code in hexadecimal and these are simple instructions. Both the last two fields are editable directly in the view and you can see a colorful highlight that matches each stage of the pipeline and gray area that shows which instructions are cached. And as I mentioned, it is essentially a debugger so the leftmost column can be used to set breakpoints. If we move up here, we can see general purpose and control status registers with colorful highlight of recently read and written registers. And down here we can see the heart of the simulator, the visualization of the pipeline. So let's zoom in. We can see here all the important control paths and data paths on the simulator with labels showing values in each stage and they are animated as the simulation progresses. So let's see a few steps. Here we can see an interesting instruction coming in. E-call is risk five term for system call and we can see that as it reaches the decode stage, it gets recognized and to simplify it for students, we stop fetching more instructions before the E-call is processed. However, full pipeline is not always what we want. We also teach simple concepts and for that we have a single cycle processor available. So the simulator accepts elf binaries. However, external compilation and re-compilation and uploading might be too much of hassle. So we also should be integrated editor with basic syntax highlight and of course integrated assembler which can be especially helpful in the web assembly settings when you don't have some clank or something available. So if you have the simulator, you can go to file and examples and open some of the prepared examples in the integrated editor and try it out. And once we have basic program running, we want to observe its effects and except for registers, the most important effects are in memory. So here you can see editable view of the memory where you can change the size of memory in it and it will respect the endearness of the processor and you can view it directly of your cache. Speaking of cache, on the right side, you can see animation of how the cache is comprised and how is it filled with data as well as we have statistics of the cache usage. So again, we can see a few steps. This is a simple program that sequentially writes to memory and it is currently set to write back. So nothing has been written to memory so far and as our cache is full, we have to evict the data, write it back to memory and we use the cache line for new data. Of course, you can configure the cache to have arbitrary size and shape and you can observe what effects does it have on the performance of the program. So let's see the configuration. We have some pre-configured architectures which are satisfied, which are enough for most cases but we have more options for the custom one. And here you can insert the exit viewable. So first we have settings for the pipeline and the hazard unit. Then you can set the shape of the cache and also some memory penalties for statistics. And finally, you can configure a behavior over the operating system emulation. So once we are satisfied with the basic program, you can play with some memory map profiles and system call emulation. We provide the LEDS, free knobs with buttons, terminal and LCD display. These profiles were inspired by a real board board that we use for teaching and it is quite interesting that you can run the same code on this board and in the simulator. So far, I have shown you the graphical user interface but we also provide a command line interface which can be useful to analyze more complex program quantitatively and also to evaluate student homeworks automatically. So that's our simulator and now let's look inside. I will speak about the decoding, execution, memory model and core visualization. So to make the simulator easily extendable, it uses single recursive table for our execution, assembler, disassembler and execution and index highlighting. It is indexed by a portion of the instruction until it reaches the individual instruction. So let's see a concrete example. Here we have some groups of instructions and here it leads to table with concrete instruction. Here it's load instructions and if we go more concrete, we can see that we have name type order instructions, memory operation, allow operation, subclass if this is a group of instructions, arguments for the assembler, allowed and mandatory bits and finally control signals. If you look at the execution, we can see that the simulator is written in a very similar manner. You would do that in a hardware description language. Here you can see that we have function for each stage of the pipeline which produces new state of the interstage registers and if we peek inside fetch, we can see that it takes the previous stage of the interstage registers. It does some operations reading from the memory, managing interrupts and it finally writes to the interstage register that is next. So now let's take a look at the memory model. The user interface currently exposes only a small number of configurations for the caches and other frontend parts. However, the simulator is ready to support arbitrary shapes of caches and also things like memory management unit and TLB would be added here in this part and all the frontend parts finally lead to memory bus which redirects them to some of the backing devices which can be either simulated RAM, it can be also memory mapped file for the host operating system or it can be the peripherals. The devices can be theoretically added and removed during grind time though we don't use that currently. And finally, the visualization, some simulators take the approach of generating it from the description of the core. However, we think that it's best to draw it manually to draw attention to the most important parts. So previously we used hard-coded QT objects. However, that was tedious to maintain. So this visualization is in fact SVG file that is tagged with special tags that correspond to the state of the pipeline. So now some frequently asked questions. Is the simulator cycle accurate? And the answer is yes with small exception. In the visualization we assume that the memory will always finish in one cycle and we only take a note of memory taking longer for the statistics. Then is the simulator compliant with official risk five test and I can finally say yes. We have added that in the latest release and now it's part of the CI. So what instructions at extension do we support? So the graphical part supports the basic 32-bit part and also multiplication extension and recently we have added control status, control and status register support. And in the common interface you can also simulate 64-bit instructions at architecture. However, we haven't yet found out how to fit it into the visualization nicely. So that will happen probably soon. And unfortunately, we don't support virtual memory yet. So about our future plans we would like to add compressed instructions that support as soon as possible. However, it's quite tricky to visualize in the program memory part. We would like to add a view of how the instructions are assembled from pieces because that's quite interesting part in the risk five. We would also want to simulate some minimal target configured compiled for Linux and also at the 64-bit visualization and memory management unit. Interesting parts would be also pipeline utilization graph which would show how the instructions are executed in each stage and how stalls are inserted to have better overview over time. And we all know that stepping back in debugger is very useful if you can do that. So we would like to add that at least for the core. It would probably not work for the memory but for the core it would be nice. So some calls for cooperation. If you are a teacher or if you represent an educational institution feel free to use the simulator or contact us regarding using the simulator and you can also cooperate on the materials. If you are a student on developer you are more than welcome to contribute and you can even do some final thesis on the simulator and if you are a distribution maintainer you can help us to get the simulator package into official repositories to help us get it to the user as easily as possible. So the simulator is available on GitHub and we provide generic binaries for Windows, Linux and Mac and we also have some binary packages already. You can read more in the final thesis that happened so far and here you can look at our courses that we have and materials we have for them. And that's all from me, thank you. So if you have any questions. I would like to ask you if you managed to run the simulator on like real risk five system like one of the bigger course. If you manage to or if you run it even on other hardware than just Intel. Yes, we are on it on ARM and x86, we don't have anything. This is nice. And one more question, how does it compare in performance to the small boards with risk files, it's still slower? Performance is not an issue for us. We want to show how it works inside and it's very slow, especially other QT parts, signals, slots and visualizations. So that's really not the task of the simulator. We want to show how it works and you can use QMU if you care about performance. Yeah, I was more like you mentioned the homework. So it's better for you to have somehow managed board to evaluate the homework. Well, most important part about the homework is that it will be consistent with the simulator and what the students can see. So they can like debug it in the visual simulator and it is guaranteed that they will get the same results in the evaluation. Thanks, thank you very much. Thank you. Awesome, thank you. Do we have any other questions? Yes, if you're interested, we have some leaflets here that you can take links.