 Okay. Hello everybody. My name is Mark Kinjarroge. I'm a student at ECT. I'm a master student and thank you for coming to my presentation. It's on my dissertation and it's entitled Design and Implementation of a Risk-Five-Based Lower Module. Okay, let's just jump right into it. Yeah, just a bit of introduction. I was actually born in Nairobi, Kenya and then my family relocated to Botswana, Hapuroni. And then I grew up there and then I moved to Cape Town, South Africa to start tertiary education. I graduated in 2020 with a PhD in mechatronics and then went straight into my master's and try working with embedded systems. So yeah, the presentation outline is as shown here. I'm going to start with just giving a context of what it is that I've designed and where it fits in the world essentially. And then I'm going to go into the design of the system, both the PCB and the SOC. I'm going to look at programming. It and then there'll be a quick demonstration and then plans for the future. Cool, so yeah. So starting with the context, the way that the Internet of Things has been implemented, the architecture used from, I guess, the inception of IoT was cloud computing and that essentially entailed that Sentinel would spread out over a network would be, would have the primary focus of generating sensitive data and transmitting it to a central location for processing. And as time has progressed, those applications have become, I guess, more computationally requirements. And yeah, as well as the sheer number of sensors being used as there's been an increase. So what does that, what that has led to is more need for higher processing power essentially, and also reducing the traffic in the network system. So what what has been looked at is moving away from cloud computing and into edge or full computing. And what that is is just bringing the computational power closer to the end nodes. Yeah, so essentially, this project is a look into contributing to that shift. And yeah, so I chose risk five and Laura. And I'm going to go into both of those technologies. So yeah, starting with Laura, it's essentially a wireless communication protocol. And it stands for long range. You can see it has distances of up to 50 kilometers, which is pretty great for IoT use cases. So for example, using it in a smart city system where you have sensors spread out over over the city. Additionally, some other features that are quite desirable about Laura is that it's free to use that's both the network, usually used with Laura, Laura one, and also the frequency bands that Laura chips transmit in you, they're basically unlicensed, which means you don't need to pay to transmit in those frequencies. Yeah, it's also highly sensitive and low power, which is very ideal for imagining a sensor network with sensors being deployed for multiple years at a time. And yeah, it's also designed for low bandwidth to help with that fact. So you can only transmit little packets of data, but you are sure that they will be received and they can also go over a long distance. Moving on to risk five. It's basically an open source ISA. And that means that CPUs designed for the risk five ISA are shareable. There's no licenses or fees that you need to pay to buy or use the CPU, which basically has generated a lot of collaboration and also research into making CPUs. So yeah, that's why I chose risk five. Speaking about the research a little bit, there's been specific IOT use case SOCs that have been developed and they focus on higher order computational that edge computing is looking at. So examples of those would be AI or signal processing. And yeah, combining these two, risk five Laura, I managed to create the Laura dongle, which is the shorter, more catchy name of the board. And yeah, essentially what it is is that it's a low cost, fully open source custom PCB that houses a customizable SOC and offers reconfigurable logic. And yeah, now we're going to go into the design of the board and now let's just jump into it. So there's been two revisions, two prototypes that have been implemented so far with the second one being fully functional. It's more of an evolution of the first. Yeah, naturally with the first prototype, there was a couple of issues and errors along the way, but it worked for the most part. But yeah, there was always a plan to improve it on the second prototype and fix anything that came across. So yeah, the changes that were made, I'm going to go into it in more detail in the following slides, but just the overview is that I changed a couple of the ICs that I chose more applicable ones, reduce the size, also added a breakout section, that's the little bit sticking out at the bottom. That houses a gas sensor and that's more like a demonstration of applicable use cases for this. So an example would be like an indoor air quality measurement thing, whatever. And yeah, another thing is that the price difference between the first board and the second board, as you can see, was about like 20 times cheaper. I will explain why later in one of the changes that made, but it was one big change that happened. Yeah, so the functional block diagram of the PCB is this. It's quite simple, I believe, hope not, but yeah, just to talk you through it. So starting from the left, it has the USB connector, which goes, the USB signals goes into a converter from a USB protocol to SPI and URs. So that's the FTDI chip and then the SPI goes to 128 megabit SPI flash, that houses configuration data for the FPGA, but it also has the wrong region of the RISC-5 CPU. Yeah, and then the SPI flash is connected to the FPGA and CPU using SPI as well. The FPGA is the latest IS-40 UP5K, so that's 5,000 lookup tables. It's relatively small in the world of FPGAs, but it's enough for a prototype. And then it's connected to a gas sensor using I2C, and then it's connected to the Lora transceiver, which is from Centek. Yeah, so the changes that were made were the FTDI chip, the package of the FPGA and the SPI flash. The Lora circuitry was kept the same because I'll get there, but essentially I wasn't able to test it in the first revision, so yeah, I didn't know what would need it to be changed for the second one. And then the final connection is a 16 pin header to the unused pins of the FPGA. That's actually probably a really good addition because it gives an opportunity to add extensible circuitry, extensible applications for the Lora dongle as well. Okay, so starting with the changes that I made when I start with the FTDI chip, as I mentioned. So essentially the first revision is pictured at the top there, and that little jump wires to a breakout board to a USB cable is how I used UART from the computer. It was non-ideal because that would mean, A, it would take two USB ports, but also it's kind of a clunky setup. And the reason for that is because the FTDI chip that was originally used was a single channel chip, as you can see at the bottom left. So the change was essentially changing from the single channel to a dual channel. And the chip is essentially the same as just that it has now two channels. So the UART was passed through that into the USB connector as well. And what that means is when you connect it to a computer using the one USB connector, it shows up as two USB devices, which is pretty great. The next change that I made was the SPI flash. It wasn't fueled by anything particularly going wrong. It's more that well, first of all, I was going back to design the second revision. For some reason, the original SPI flash was out of stock. Actually, no, it was obsolete. But actually, when making the slides again, I went back and apparently it was back in stock. And then also the tools that we're using, I was using, support the second flash more than the first one. So specifically the program that was written to load the bit stream of the FPGA onto the flash. It was written for the second one, although it was still compatible with the first one. But yeah, that's what that changed was. But it was actually a positive change in the sense of the memory allocation. So the first one was about a 32 megabit SPI flash. And the second one, it says that the bottom is 128 megabits. So it's a much larger flash chip that was used and basically bigger space to work with in the firmware writing specifically. In terms of cost, the relatively the same price about I think was 30 cents difference between the two. And then power consumption is also pretty much identical. So yeah, I think this was a positive change as well. The last main change I made, and this is a bit of a convoluted change for multiple reasons. So I'm going to start with the reason that's shown in the slide. So the FGA pot that I was using basically had about 30 pins to work with. So in an attempt to minimize the pins and share some pin usage, I connected the SPI clocks for the configuration of the FPGA. That's the one to the flash. And then the SPI clock that would communicate with the Lore chip and connected them together. And I thought that I would be able to reuse the pin essentially. But unfortunately, when building the SoC, the error that is pictured here shows up and it didn't let me use the two pins at the same time. Or rather, they were instantiated separately. So there were ways to get around trying to tell it, okay, there's two pins and I want to use them. But I couldn't get the software to actually make it work. It managed to build. So this error was taken care with. But when it came to actually programming or running or doing anything, nothing was happening. So yeah, the change was fueled by that. And another reason is that this chip is the pins, it's a BGA package and the pins are extremely small and close to each other about 0.2 millimeters spacing between the pins. And essentially what that means is the PCB being manufactured would need to be, what's the word, high. It's a high density PCB. So it's an advanced PCB, which makes it much more expensive, much, much more expensive actually. So changing the FPGA parts, the same chip was used, but it was a different package. So it went from this really small pinout package to a larger, more traditional QFN package. And that just made the PCB now become a standard PCB, gave me more pinouts, which was also used in the 16 pin header, and ultimately drove the price down as you saw by about 20 times. So it was $300 for two boards to manufacture without components. And then with a new part, it was $25 for five boards. So yeah, a big change. Yeah. And I think that's it for the PCB design. I'm going to speak a bit about the SOC design. So essentially I used Litex, which is an open source Python framework for FPGA designs. It really lowers the barrier of entry for use. And it's actually, it was a great experience and I enjoyed it. And it has a bunch of cores that you would use in the design of an SOC. For example, I have the SPI, SPSC. There's also things like direct memory access. And then it also has a lot of already implemented CPUs. So essentially, when you're using Litex, you're just focusing on the structure of the SOC. Yeah. And then I use YOSIS as well, and direct memory. And I'll project ISOM, essentially, that open source synthesis and place and raw tools for lattice IS40 chips. Okay. So this slide is just a visualization of how Litex made the SOC design much easier than it would have been. So initially, when I started the project, I thought that I would have to use Verilog or VHDL or something to design the SOC, maybe even writing a specific course to do exactly what I want. And I quickly realized that that is a large project on its own, basically, a whole dissertation, I believe on its own. And Litex made that much easier. So what it is, it focuses on the interconnect between the SOC or the architecture used in the SOC as opposed to writing the actual course. And it also generates the useful information that you'd need to work with the SOC. So that's the C code as well as the tool chain, specific files like the link information, and also gives you documentation on what the SOC looks like. And then on top of that, there's also already a few open source projects out there that use Litex. And I took great inspiration from two in particular, which is the Icebreaker on Litex example and the FOMO. And those are both open source FPGA PCBs that have Litex SOCs as well. So when choosing the CPU for the SOC, that was one of the main decisions that need to be made. And how it came about was, okay, initially, we started by just doing simulations or looking at the documentations of the CPUs out there to figure out just how much resources or how big an FPGA would be needed. And we quickly realized that most SOCs or most implementations had large FPGAs and which would drive the cost of the board to be quite expensive. And as well as a first prototype, we want more proof of concept. So we look for a cheap FPGA before anything. So yeah, we settled on SERV, sorry, which is a really small CPU that's actually already implemented on Litex. Yeah, so we used SERV. And then as we programmed further and needed a bit more complexity for the CPU, for example, interrupts, we realized that we might need a bigger one. So I just implemented it with PicoRV32 as well, which is also used in Litex. And it says they're minimal because it's the minimal variant that's specified by Litex. And that's only mostly because the full version was too large again to fit on the FPGA. So that was the trace of CPU, SERV or PicoRV. And then the other specifications of the SOC. So just a quick rundown, it's a pretty, I guess, base level implementation, just what I needed to get a proof of concept down. So there's definitely room for improvement and massaging. But essentially as the CPU, as I mentioned earlier, and then there's about 128 kilobytes of RAM. And that's used as the dedicated SP RAM block in the FPGA. And then there's also eight megabytes of ROM, and that is stored in the SPI flash. So as I said, the second flash was larger, which also gave us larger ROM to work with. And then there's also just communication calls. I mentioned you had SPI and I2C already. And then just general GPIO pins. So there's two LEDs just to show indicate transmitting and receiving. And then we have some lower configuration pins. Those are just the things like a busy pin or the reset pins, et cetera. So this is the block diagram of the SOC. It, Lytex operates with a wishbone bus. And basically every peripheral or core in the SOC is given an address on the bus. And in order to interact with them, you just read and write at those addresses. So the CPU serves as the master on the wishbone bus. And it handles the transmitting and receiving of commands on the wishbone bus. So the GPIO SPC SPI, that section on the wishbone bus is under a specific name, which are the CSR registers. And what that is in Lytex is basically just memory mapped input output registers. So that means the CPU writes to a section on the CSR section in the wishbone bus that corresponds to a register that could be, for example, SPI meso register. So that's how you'd interact with the peripherals with the SOC and using the CPU. Yeah. And another thing is that those registers are also generated by Lytex, but I believe that I'll explain that later on. So this table just shows an example of the resource utilization by changing the two CPUs. So for this test, basically everything about this SOC was kept constant except the CPU being used. So the only change that was made is the CPU being used. And as you can see with the smaller CPU, less than 50% of the lookup tables was actually used by. So that leaves a lot of wiggle room for extensible designs and also using the FPGA fabric. Yeah. And then Pico RV, the minimal variant, as mentioned earlier, uses a bit more, but still leaves a bit of room to work with. And then the block RAM serve once again uses less, I mean, half than Pico. And then the SP RAM is 100% for both because that was predefined to use the block RAM, I mean, the SP RAM on the FPGA. Okay. So now I'm going to look at the code a bit, when I speak about how to generate the SOC and then how to also program it. And then I'll show a whole lot of snippets just to help the explanation further. So yeah, starting with the SOC Python scripts, essentially it's just two Python files that you need to have. And that's the target and the platform. So I'm going to start by talking about the platform, which is essentially just a constraints file for the FPGA. So if you've ever worked with FPGA, you know that with the pins, you basically need to specify which pin is what and give it a pin name. So that's what the platform file is, but then it also has some writing specific information, such as selecting the programmer and selecting the part number of the FPGA that you're actually using. So what that does essentially is once you run the target file, it's as simple as calling one script, and then your SOC is built, synthesized and loaded to the FPGA all from the one command run. Yeah, moving to the target, as I mentioned, it's now focuses on configuring of the SOC so that I'm setting up the different peripherals, the different CPUs and the other settings that you might want to have on the SOC. And then it also handles the building and the loading of the SOC as well. So yeah, this is a screenshot of a section of the platform. There's the constraint section, basically there's that IO list, and it shows that the different pins are mapped, pin names are mapped to physical pins on the board. Yeah, on the FPGA, I mean, and then this is a section of the platform that basically instantiates the part number that's being used and giving it the IOs, and then also setting up the program, the iStorm program, which is the OSIS tools that I mentioned earlier. Here's the target. So this is all the imports necessary for the SOC as it is now. So you import the various light takes cores and implement and classes that they have. So for example, there's the SP RAM that we're going to use to use this RAM. There's the builders, there's the programmers, and then further down you can see the SPI classes, GPIO classes, etc. And then also the section that I highlighted showing that importing the platform that we defined earlier. Yeah, looking at the SOC, I mean at the target, I'm just going to quick rundown of what it's doing from the jump, from the start, I mean. So yeah, first it's statically defined some memory map that's just to ensure that when you change versions that everything is where you expect it to be. And then the initialization functions first step is to initialize the platform that's been defined. And then the selection of the CPU type, as you can see, it's as simple as just changing the keyword keyword argument that'll be passed onto the SOC builder, just changing the name from serve to Pico RV. And then if it's Pico RV, use the minimal variant because as mentioned, the non-minimal one would be too large to fit. And then moving on, because the RAM and the ROM is being used in special cases for this SOC, just making sure that it's not automatically generated and it's forced to zero. And then setting up the CPU reset address, which as I mentioned, is in the SPI flash. So just telling the CPU with which address to look at in the flash in order to read the firmware that you will be running. Yeah, so that's what the flash offset is. And then this snippet shows setting up of the memory. So that's the RAM and the ROM. You can see it's as simple as just instantiating the UP5K SP RAM in the SP RAMs case. And then in the ROMs case, you pull in the specific part number of the SPI flash that you are using. And then just adding SPI flash using one of the functions that Litix has. And then now setting that region to be the ROM. So you set the ROM region and then you make sure that it's at the offset in the SPI flash. And then you also set the size. Yeah, and that's how the memory is set up. And then just a bit more generating of the the input-outward cores. Yeah, it's as simple as just setting up a GPIO in class, GPIO out class. This is just a snippet, not all the other pins I mentioned here. So yeah, there's all the LEDs that need to be done as well that have been done just my children here. And the SPI as well is also simple as just instantiating the SPI master class. That was input. Yeah, and then this is the main function of the target file. So it just starts with the system arguments that you put in just basically settings to configure how you want the SOC to be built or what you want to do. Pretty straightforward. And then moving further just instantiate the SOC with the arguments that have been set. And then if you want to build it or flash it, that's done as well. So as you can see, it's everything is taking care of from the building up until the loading into the FPGA. So now with the SOC built, this is going to look at the firmware and basically the structure of how to write and use it. I'm going to start with the bottom left, which is the latex generated files. So I'm actually going to focus on the CSR.h. And that's basically the header file that contains the addresses of all the peripherals in the CSR section of the wishbone bus. So essentially it's functions that you use to read and write to the peripherals. Yeah. And then so the rate, the Laura driver uses that specifically for the SPI communications. So talking about the Laura driver. So essentially the bottom two files, the HAL file and the non-HAL file were provided by SEMTECH, the middle one being fully written. And then just the user having to write this specific HAL functions for their specific microcontroller or CPU that they're using. So what SEMTECH provided is a function prototypes that have specific inputs and outputs and return types that you need to massage or write to fit that prototype in order to use the driver fully. And then radio.c is just a wrapper that I have on top of both, a higher level of abstraction essentially. Yeah. So I'm going to show snippets of all these files starting from CSR.h all the way out to main. And essentially it's looking at how to get a transmit working on the Laura dongle. So starting with the CSR.h. Yeah. So you can see from the top left that a little section just sets up the CSR base address value on the wishbone bus. And then the subsequent functions and addresses all relate to that. So you can look at the GPIO. This is just an example of how the LEDs is written. This is actually the entirety of the LED section for the CSR bus. Yeah. There's just those two functions that just read and write the CSR address. So when implementing in your own application code, all you need to do is just call LEDs are read or LEDs are write. Same thing can be seen there with the SPI section. This section just shows the MOSI and MISO registers as well as the chip select. It's the same situation. It's just all you need to do is call the specific functions for the registers that you want to interact with. Yeah. So working our way up from the on the Laura radio side of things. So this is just a snippet of the how writes. So essentially what this function does it writes SPI to the Laura chip over the MOSI line. Yeah. So you can see that at the top, the inputs and the outputs have been determined already by SymTech. So all you need to do is use those and transmit it to the Laura chip using whatever functions that's applicable to your microcontroller or CPU. And yeah, in this case, because it's using Litix, there's all those Litix generated CSR functions. All it does is just sets up the SPI communications. So those two for loops are basically writing to the MOSI register, the relevant bytes and then transmitting them. The read function is also the same how read. It's just that as opposed to writing the MOSI register, you're reading the MISO register. Moving on. There's another SymTech provided main driver file. And I've just highlighted two sections that show the write register and read register functions. The file is actually extremely huge and it essentially has, well, every command that's stipulated in the data sheet, which is nice. You don't have to write any of that. But you can see I've highlighted that these commands use the how write and how reads that we looked at in the previous slide. And essentially every function in this file ends with using one of those two functions. So you can see how they've had a good way of abstracting. Are you be able to write and read from the Laura chip? So yeah, this is a write register. So it just writes whatever value that you want into the register on the Laura chip. Yeah. Moving on here is the radio.c. Now this is the wrapper that I wrote on top of the driver. And this section just shows a transmit code, which essentially is the steps that are needed to be taken in order to transmit by a Laura using the board. And yeah, you can just see it sets up the transmit LED, turns it on, and then it prepares for first configures to transmit and then sets to transmit. And then those functions are also showed there below. And what they are is just using the files in the driver that SEMtet provided using the function, sorry, and calling them. Yeah. And then in main.c, this is not just the user application code. It's just sending a ping. Essentially, you set the message and then you initialize the various things in the main function. And then in the while loop, all you do is if you're transmitting, you just call the transmit function that I showed in the previous slide. So yeah, I think it's a good level of abstraction from the lowest level up until the main function. And that's essentially how you transmit using the port. So I'm now going to show a quick demonstration of the transmit being picked up by the spectrum analyzer. And it's just a video. If this was in person, I had a better demonstration to show, which was the ping, pinging from one lower dongle to the other. But unfortunately, I wasn't able to make it in person. So this is the next best thing of a demonstration. So yeah. So this is a spectrum analyzer. It's not picking up any signals right now. And then I connect the lower dongle and it turns on. And I don't know if you can see, but the LED is flashing. And then we go back to the spectrum analyzer and you can see that there's a peak at the transmit frequency. So just to make sure that it wasn't in any way with signals, I disconnect and yeah, there's no peak. And yeah, so this was actually the first time I was able to get transmit working. And I was quite excited. Yeah. Okay. So I do have some documentation. It's not thorough. It's not complete, but it's enough to essentially get the board manufactured, build SOC, and then start writing programs on it. So it's an interesting website. It's live now already. You can go click the link and you can just read more about it. Yeah, you can see how we're getting started. This just focuses on installing tool chains or light takes as well. And yeah, things like that. And then this tutorial as well is starting up from nothing into getting Blinky working on the LED. Yeah, so future plans. This is both for my immediate completion. So by the end of this year and then also be on like moving further into the lower dongle lifespan. So well, firstly, as I mentioned that actually I'm not sure I did, but the second prototype was actually only received like last week. So I've only only had a few days to play with which was getting that transmit working in the demonstration. So it's still in the early stages of testing. There's still a lot of testing that I would want to do. And that covers specifically CPU related things. So things like latency, how long it takes to transmit messages, how long the computation takes to do that, bandwidth and throughput, how much you can actually, how much data you can send in a given time. Range testing, I plan to see how far I can actually transmit because I know Rora is supposed to be long range. So I want to see the capabilities of my PCB. That's also both line of sight and obstructed. And then as well as indoor testing, buildings, indoors, multiple stories or multiple rooms. And then finally benchmarking of the SSC. So that's just seeing how performative it actually is. And then ultimately, I would love to connect to a lower end gateway that's already implemented somewhere in the world. And then that would be connecting to the lower end network. And then with the testing done, I've actually compartmentalized the plans for the lower dongle into three main goals. So the first one would be for my immediate goal for both finishing my dissertation and also just excitement of improving the PCB. So that's improving the SSC, which essentially making it more efficient, you know, giving it more computational using the FGA fabric. And yeah, just improving that in general. And then moving on, I'd want to be able to run Linux on it on the lower dongle, but that's a bigger endeavour. And that's because it would need a larger FGA. There are examples of Linux running Linux. Like it's been done before I actually used it on a dev board. But yeah, being able to do that on the lower dongle would, as I mentioned, require a much larger FGA. And therefore, that would mean redoing the whole board. So yeah, that's like more of a long term goal. But I do think it would also do much better in terms of contributing to edge computing. And then finally, with that done, it would be seeing it being used in the industry. So as I mentioned, the demonstration of the gas sensor, just having a Laura capable board for ease of pickup and use. So if somebody wants to have an application and they want to rapidly integrate Laura, they can just take the board and then use it. And the added benefit is increasing computing capacity as well. But yeah, that's my presentation. I just want to thank you once again for taking the time out to come and see it and hear it. I apologize for not being able to be there. But yeah, if you want to ask any questions, if you want to contact me, these are the links linked in email and then have personal portfolio type website as well. But yeah, thank you so much for attending. Bye-bye.