 Okay, the next tar is 45 minutes in the schedule, why is that? Why is it special? So it's actually shorter because we took two presentations and we squished them together in a single one. So Nikolas is here, so yeah. So Nikolas will probably be giving the more interesting part and I'll give the introductory to the following question. FGAs, why, when, and how to use them with Argonauts. So part one is why, when, and then part two is how. And now, last year I gave a similar presentation. So you might, and just, was someone there? Does someone remember that? Yeah, one guy? Okay, good. If it's one guy, then that's two guys off. If it's two guys, then that's not too bad. I didn't want to bore people, but I also didn't want to give the same presentation twice. And there was something that we realized sort of, and actually this goes back to the panel, you know, we sometimes start in the middle. So basically last year I said, oh, well, you want to do an FPGA, more accelerated, blah, blah, blah, and this is what you do. And then I think Daniel, this morning gave a really good presentation that started from basically scratch, you know, everyone calm down. We want to do hand radio. This is what we do. It's not that hard. And I felt that was a good approach. And so today I will actually talk about something very basic, which is why do we even have FPGA? Why would we even want them? Now, if you know all of this and I want to apologize in advance, the next 10 minutes will be not the most enlightening. But I do feel, just from conversations with people, it's sometimes nice to sort of start from zero and sort of kind of like, it's assuming you know nothing, why is this interesting? And that is exactly what I'm going to talk about now. First of all, we always assume that everyone knows what an SDR looks like, but maybe that's not true. And here's sort of a very, very, very, very high-level schematic. It's really hard to get any in your high level than this. And we start on the sort of the analog side, which I'm completely going to ignore now. So this is everything that's in tenors and filters and whatnot. Oh, no, I don't. Man, I guess I hopefully spoke loud enough to pick up the first couple of minutes. It's like half an hour ago, I was stationed during asking people the same question. How could you possibly forget the microphone? Let's not talk about that today. We've already talked about ADCs and DACs a little bit. And what comes out of those is digital data. Now, on most commercially available software radios, and by the way, I work for a company that builds software radios, they look like that. But it's not limited to that. This is sort of the generic design that you always have. Data coming from the DAC goes into an FPGA. And then between the FPGA and your actual software running, so you can radio, for example, you will have some kind of transport, something that is getting the data from the FPGA into your software. That's also something I don't really want to talk about now, but there's a difference between those black lines and those orange lines, which is the black lines are typically PCB traces, as a matter of fact, or something similar, some local connector, whereas the orange thick arrow could be anything. So network, I don't know, it could be through the internet for all I care. OK. And here we have an FPGA. What the hell does this guy do and what is it? So first of all, what is an FPGA? And I just copy and paste at the Wikipedia definition here, integrated circuit designed to be configured by a customer, a designer after manufacturing, hence field programmable. So let's dissect that. So we have a user-definable digital circuit. So the digital is sort of something, like if you go and sort of the very, very modern things, there will actually, people will actually start implementing analog components on FPGA. And then technically, I think we shouldn't be calling them FPGAs anymore, but the name is just stuck. So let's stick with that. Going back to this slide, we have an output of the DAC, and then somewhere we have maybe a network connection, and then we have something that we can define. So when we sort of the hardware, we say, OK, this is yet to be defined, but it's a digital hardware circuit. So that's important to keep in mind. We will have flip-flops and et cetera, somewhere in there, but at the time when we manufacture it, we don't know yet what they are. That's a thing to keep in mind. And even after shipping the device, we can readily change that basically at any time with some caveats. And what is the typical clock rate for such an FPGA? Well, that varies. There's not something, there's no one answer to that question, but it's not gigahertz. It's usually typically in the order of several hundred megahertz. Now, if you think 100 megahertz, does that sound like a lot? If you come from a software world, maybe it doesn't, but it's actually more than you need in most cases, and I will tell you why in a sec. So yes, in a sec, Phil, don't be so impatient. Drink some club mate. So I actually have a lot of colleagues that, like me, studied electrical engineering and then started doing software. But if you study electrical engineering, you handle stuff like this in class. And if you remember what you did in school, you have all the knowledge you need to get started with FPGA development. So how do we even program such an FPGA? And as a matter of fact, I will show a demo here. So there is one buried somewhere in here. And this is something that I will be programming, reprogramming all the time. And how does that even happen? So on a very high level, four steps. First of all, define your circuitry. OK, what do we even want to achieve? And this will be all kinds of things. As I said earlier, we have the ADC on the one side and we have some kind of transport in the other. And everything that's in between needs to be defined in order for something useful to come out of it. So I need to design the digital circuit that then later on I will actually be requiring. We have ways to encode that. For example, we have programming languages called Verlog and DHL, which are textual descriptions. There are graphical tools. And honestly, I'm not a fan of graphical tools in general. For FPGA development, they make more sense than for code development, I feel. Because what you are developing at the end of the day is a digital circuit. And we are used to dealing with schematics. Practically, though, if you're maintaining this, you will probably use Verlog or DHL for good reason. So now comes the black box part. So we take this, say, Verlog or DHL or whatever. And then we turn it into a bit stream. It's like the compile step in software. And this is sort of a binary file that is usually proprietary. And we don't exactly know what's in there, except people have reverse engineered it. The point I'm trying to make is at this point, you will be relying a lot on proprietary tools and tool chains. There are exceptions to this. But this is something we currently have to live with. Now, once we have the bit stream, this is actually an instruction for the FPGA how to internally reconfigure itself. So we have some pins that say, here we can load that bit stream, and then that's what we do. And if you buy an eval board, those will be very obviously exposed. I have pictures of those. And what can we use them for? Well, can it run software? So that's sort of a typical question. We could, but the way we run software is we reconfigure the digital circuit to behave like a CPU. And then it runs software. It's typically not a very efficient use of our FPGA. So if you have a digital circuit that you can draw out, that's something you would want to put on an FPGA. And something to keep in mind is you have a lot of space in some of these FPGA. You can take data from everywhere and do things in several places at the same time. You can sort of split it in several regions. And every one of those can be handling a subtask at the same time. So the design philosophy here is very, very, very deep. And I can't cover it in five minutes. But here's sort of a typical example. This is an FFT as a digital circuit. And this is something where it's very obvious that you can put it on an FPGA. And if you were to put this in software, for example, you'd be writing some kind of recursive function, maybe. And then you have to deal with stacks, something, something, something. But on an FPGA, it's very easy. You have data on the left-hand side. And then it sort of gets clocked through from left to right. And at the output, you have your FFT. A couple of clock cycles later. It's very nice. So FFTs, filters, neural networks, examples of things that are easily implementable on FPGAs. Control loops also nice, because I mentioned this here. We can control latency very tightly. It's nice for control loops. If we have to do a sort of complex decision making, it can get difficult. Now, as I said earlier, we can replace the contents of an FPGA, but we can't do it any time willy nilly. Because one of the reasons is this is like a big part of our SDR, and it'll take down certain pieces of the rest of the SDR if we do so. So this is copied from a schematic of this device, which is downloadable on the Edda's website. And so I don't want to go into detail, but this here is basically the FPGA. And it has certain components connected to it. OK, I cropped them out. That was stupid. But the whole point of this slide was to show that here we have a network connection, ethernet. Actually, no, that's not true. We do not. But let's say we have. And we are talking to that FPGA of the ethernet connection, and then reprogramming, down goes the ethernet connection. It's something to keep in mind. So there are three major challenges for FPGA development. The first one is sort of the digital logic part. And if you come out of, as I said earlier, an EE school, you will be familiar with this. So what's this equation as a digital circuit? And what is this equation? You just someone said it? It's a convolution. So could you draw that out as a digital circuit? It's not a trick question. Do you think you could do that? Yeah? I mean, it's not hard. We basically add a bunch of things. And the bunch of things we add up are delayed versions of a signal multiplied by something else. So I could use the whiteboard to do that, but I don't want to steal Nicolas' time. But here's an example. What does this do? This is the reverse to the other question. It's a shift register, yes? So the purpose of this is, and actually copy this from the computer, that there is a, you can't see it here, there's the sources listed. The purpose of this circuit is to have a serial connection here, serial data coming in. And we shift, so we have data here, then we have a clock signal. It sort of toggles these flip-flops. We do this four times. And then the bit that was here got all the way here. And then the one after that is here. The one after that is here. So we have four bits. So now we have gone from serial to parallel. So it's a serial in parallel shift register circuit. I think this is fairly, I hate saying this is easy, but because I studied it, blah, blah, blah. But I think these are concepts that are tangible. I think you can play around with simulators, and you will get very far. And I would love to hear people disagree and then have a discussion over that some other time. However, oh, there we are. No, I blended it out because it had the answer to my question. However, when we actually implement these, we have, I'm just going to call it circuit magic. So sort of understanding the logic is one part, but then actually building it, we get all these weird constraints, et cetera, et cetera. What could go wrong in this circuit? Just random ideas. Like has someone? Set up and hold violation. There you go. That's good. I'm sorry I ignored you because that's more useful to my, yeah, set up and hold violation. What does that mean? Okay, I don't want to go into that much detail, but I'm glad you do because that sort of emphasizes my point that you have this simple circuit, and then all of a sudden you have to think of all these things. So I just randomly came up with these four. Like, where does this clock come from? Like how fast is it? And that goes slightly into your question. Like will the flip-flops keep up, which is sort of an unscientific way of asking the same question? Like, I mean, when will I be reading these outputs? Because they're not valid until I've put in four inputs, right? So how do I synchronize the input to the output? And all these things that I suddenly need to care about and that's really something that is sort of the art of FPGL or something you sort of have to go through. And then the tools are sort of one of the biggest, like personally I'm a little bit miffed by that because in the software world we have, you know, GCC has come a long way recently to produce nice error messages and just be easy to set up and you go to a C programming tutorial. You can start writing code immediately. With most proprietary tool chains, you will have, for example, the precursor to the tool called Vivado was called ISE and with about 20 gigabytes installation because it shipped all these random things. Yeah, and good luck getting that run on sort of one of the unsupported OSes. I just picked a random screenshot where you sort of try and debug something that's going on on the FPGA and you will be spending a lot of time trying to sort of go through menus. And you know, that's just not great. It's just the way it is. So there are actually some developments in open source FPGA development, but they sort of target very specific chips and aren't that broadly applicable. I hope that'll change and 20 years from now we'll be laughing about this. If you're interested, there are nice resources. EDA Playground is, I showed a screenshot here, is you can sort of load examples in the Playground and you can press play and it'll sort of tell you what's going on. There's sort of a mental shift you have to do going from sort of a description of a circuit to then running it sort of in time. That's something that is covered in many, many tutorials and I can't really do that right now. If you want to get started cheaply and maybe even using free tools, so YOSIS is a free tool chain and then there's the ICO board which is an extension for the Raspberry Pi which has a small FPGA and it'll let you do some interesting things. If you want to go for the bigger FPGAs, you will have to work with the proprietary tools from Xilinx and Chara. They both have, or this is the ICO board, but they have like eval kits like these. These are slightly more expensive but they will also let you do really interesting things. You could even play around with JST204B if you have stuff like this. And then of course, user peers like these will also let you do SDR and use FPGAs at the same time. Okay, I'm already over time, so very, very briefly explain RFNOC which is an FPGA framework that we as an at this research have been working on. So the problem we're trying to solve, no actually, I have this one slide. Yeah, this slide I carry around on every presentation I give on RFNOC. So if you walk out now with this presentation, I'd like to just remember this one slide. What is RFNOC? It is for FPGAs what KinoRadio is for GPPs. So we have this sort of block-based modular design approach both in RFNOC and KinoRadio. And then as Marcus showed earlier in KinoRadio, we have this ability to write blocks and then data will magically go from one block to the next. It's obviously not magic, but we don't have to care how it happens. The same thing is true for FPGAs. And what I talked earlier about the digital clock, so the digital magic that you have to do is much, much reduced if you use a framework such as this. And we like working together with KinoRadio, so and I'll show that in a bit. Okay. So here's an example of a KinoRadio application that would simply not work, even though it's very simple. So you generate data from your SDR, you stream it to the computer, then you calculate an FFT, 1024k, whatever. Complex or Mac, moving average, and then you plot that, so very simple spectrum estimation application. This is DSP 101 level. Already this won't work if you have a high bandwidth, why? Because A, you need to get data out of your SDR onto your computer fast enough, which is maybe not even theoretically possible if you have say a gigabit ethernet connection. Then you're doing all these simple number crunchy applications on the computer, which you could just as well or much, much, much better do on the FPGA. Then here, you are decimating your data. So the output of this block is very low rate, but so you can plot it, but you've done all this unnecessary calculation on your computer. Why not move all of this stuff to the FPGA? That's exactly, but this is the important part is, we want to move this to the FPGA, but we do not want to lose this modular approach. We don't want to say, okay, we fold all of this into here, and then we have this new black box that does everything on the FPGA. That's not the point. No, we want to have the same modularity, but on the FPGA. So I'm going to run a little example right now, and then this slide will actually explain the example. Oh, my antenna. So I have an embedded SDR here, which means I, oh, crap, did I forget it? Do you see him? Sorry, I see him. Does someone have an ISM? SMA, please? Oh, S&B. Your reception will be great. Let's give it a try. I was testing this in my hotel room, and that's where my antenna is right now. So that would be better. I always did not. Yeah, so this is an embedded Linux. I've logged in. You can see this is my command prompt on the device, and I will run an application in GNU radio. Here it is, which looks like this. So we sample stuff, then we put it through a couple of DSP applications, then we put it through this block called Phosphor, which by the way, Sylvain wrote. It'll then distribute the data through these zero MQ connectors to my laptop. The reason I need the laptop for this is because I need to visualize this and this does not have a display. So then on my laptop, just for clarity, I'll be running this application which just only does visualization. I have one, like this is getting the data in and then here we visualize it. Okay, so what I will do here, so I'll set up my environment, and so what I did earlier was I compiled this to a Python, this year to a Python script, which is now living on the device, and I will execute that, and I would be blown away if this works out of the box, but so it does all kinds of output, but I'm gonna scroll right to the top, and here, there we go. It said loading FPGA image, blah, blah, blah, blah, some bit file done, and then it talks to the FPGA. All of the rest of this output is just verbose information about conversing with the FPGA. So it's doing stuff, but we can't see it, we need something to visualize it, and I will do that in here, there we go. So we have 56 megahertz of bandwidth being processed and beautifully displayed. Now that doesn't sound too impressive if you know your spectrum analyzer, but here we have an ARM dual core running at 600 something megahertz, like this by itself would never, ever, ever be able to process that kind of data by putting it on the FPGA that works, but not only did we put it on the FPGA, but we also kept it there in a sort of modular fashion that is sort of easily understandable. So if I'm debugging this, I could go into the, is it, yeah. I could go into new radio and then sort of tap into outputs of individual components. So, oh man, I'm stealing Nick last time, I'm sorry. So this is what the application looks like, and if you know new radio then this looks familiar, but we have these green arrows which notify, green arrow means this is happening on the FPGA, black arrow means happening on the CPU, and dashed means it's going from one to the other. Okay, so this is what happens internally. Inside the USIP we have all these individual blocks, and if we run the new radio app it'll simply tap out the data at the right position. So this is, at some point you make a choice which blocks you wanna run on an FPGA, so here's a random selection. And then what Nicholas will talk about is like how, whoa. And what Nicholas will talk about now is how do you actually build a block? And this is sort of the internals. The point we were trying, the problem we were trying to solve is that all of this magic was like data comes in, goes out, like how does that happen? It's taken care by a framework. And in this example is like say this is the radio, it sends data to another block which could be an FFT. All you have to do is put in your lines of verilog here, that'll then do the actual processing. So let me just disconnect. And you can take over. Okay, Pete, if you came to the talk because of the name FBEA, FBEA is over now. Microphone. Microphone. Jesus Christ. Okay. Well, yeah. I hope it is okay. All right. Okay, so I'm not gonna talk about what verilog is or what can you do in the code because right now I'm gonna talk about airfnog. And understanding the framework of airfnog is already some challenge. And well, with 20 minutes I will be like kind of running over it. So if this works and it doesn't, Jesus, Martin, what do you do? Okay, no, my computer just crashed. And that's the first thing. All right, I'm gonna send it to sleep. So we'll continue talking while it boots. So airfnog, as Martin already said, is just a way to connect your blocks in a genuine radio fashion, so to say. So I'm assuming that everybody has used a genuine radio, right? And has anybody or everybody created your own out-of-tree module in genuine radio? Out-of-tree modules? Okay, that is less than I expected, actually. But it's okay. So the thing is that you can do the same stuff with airfnog module. That is the stuff that I'm gonna be talking about when everything works. And I hope it will. All right, this is not the tool that I need. All right, okay, so this is the outline. I'm not gonna start with who I am. So I am a master's student in KIT in Karlsruhe, Germany. I spent six months last year in Santa Clara being an intern in Ethos Research. And right now I'm working for Ethos as a customer support engineer, meaning that if you have some problems with airfnog or whatever from Ethos, and you contact us with a mailing list, and sometimes I will answer because Marcos does it faster. I'm better. All right, so create your own blog. So the thing that we want to do is to put our own application in the FPGA. Same stuff that you do with genuine radio. You want to do that also in the FPGA. So with genuine radio, what you do is you create some Python or C++ code, and you hope it works and it will because you're really good at it. But with airfnog, you have to go a little bit further. So we have this beautiful image that we use a lot. This is called the airfnog stack. So basically what you have here in different colors is the different like interface that you're kind of working with. So you have the FPGA, you have the UHD integration and genuine radio. So FPGA is what you want to have in the hardware. So that is very luck. That is what you want to code. That is going to be your IP. But you want to connect that to your host computer if you're using, for example, one of the biggest devices. But if you're using an embedded device, you really want that not to your host but maybe with genuine radio. You use the UHD driver. So that is the way that you connect your FPGA to the other part of the software. So then you go into genuine radio and you use your blog connections and everything will be really, really nicely connected. So basically the different colors are the way that you're working but the different blocks are kind of the amount of files that you have to modify to do that. So first you have the very low file, obviously because that is your IP, that is what you're writing, that is your algorithm. But then you have to tell UHD, okay, I have a very low file, I have my FPGA image, I want to connect that. So the first part you have the block declaration that is an XML file. Normally, usually at the beginning, it contains only the amount of inputs and outputs that your blog has at the node ID. The node ID is something really important. That is the only way that your computer, your driver, your genuine radio will know which block are you using. So that is like the identifier, that's it. And that is like the first stuff that you're using in UHD. Then you have your blog controller. If you have more than one input, if you have something going on with the driver, if you're actually going into the connection between the FPGA and the host, you're gonna have to write that C++ file. Usually, you don't. Usually, it just works with the descriptor because you have something that is called node script. That is a way of instantiating or creating some small functions in your descriptor so that you don't really have to write a block controller. And then you want to have genuine radio like blogs that you can connect that they will look really nice. Then you have to go a step further. So basically, apart from that, like from the orange spot, it's basically what you will know until now what your module did. So it's going to create a lot of files that are going to describe the block as is. The XML, basically, is the one that you want to modify because if you have more inputs and more outputs, you have to tell the genuine radio. And also, there's where you have the UHD streamer. So actually, there's where you're saying what type of samples are you using if you're taking parameters from your blog, from your graphical interface. And then your blog code is, you can also do more signal processing with your radio after you go to the samples. That is like the basics. But what happened? Like one year ago, actually, you had to know also where those files were to be put. And that was quite a challenge. You had to know where Vivado is going to look for the very dog. You had to know where UHD is actually taking the block controller from. And you have to know what your address is first. Your address is actually the out-of-tree module for AirFnock that Aetus provides. So there's already some blocks that are written in AirFnock that you can use. But also, if you had an out-of-tree module that you want to use, you actually had to write everything in the same repository as your address. And that was quite a problem because you don't really have to have different locations for something that is only doing one application. So then is where AirFnock module actually comes from. So if you have used your module, you will be really familiar with it because this is based on that. So what it does basically is I want to create my own out-of-tree module. And then I want to have everything in one location because that is what an out-of-tree module is. So right now it's just a line of code. It's just a Python application. And if you're familiar with your module, what this does is basically the same options. You're going to create a module. That's it. And that's really easy. So yeah, for example, if you do something like this, you will create that. So let's do it because I really hope that my computer doesn't crash anymore. So I have these folders, this FOSDM. The only thing that I have right now is only the presentation, right? But what I'm doing with this is always the alias for setting up my pybom's environment. If you don't use pyboms, that is actually really, really useful right now. So right now I have access to AirFnock module. And I want to create a new module, right? And I want to call it FOSDM because I am FOSDM. Well, the name doesn't really matter, right? So I already create this, and I have a whole bunch of files that are describing my block. And you're getting everything in that location. And that is great because that is what you want. And right now I have only the module. So it's the structure. There is no block yet. I want to add the block, right? So AirFnock module at chair. So I'm having a block that is going to be called chair and it's going to do whatever. So right now it's going to ask you something, some stuff that you want to have maybe so that the application knows what it is going to do. So you can add some arguments at the beginning so that they are going to be automatically add. Right now I don't have any, so I can skip that. Quality assurance, no, we don't write that. So this is important, the knock ID. Before the AirFnock module, actually you had to remember your knock ID and all your files had to have the same knock ID. You can choose whichever one here and the AirFnock module will create all the files with the same knock ID because that is what you want, right? I don't really know one, so I skip this and it creates one for me. The good thing is that I don't have to remember. Every file that is going to be created already has it. That it's done. I don't care anymore. Skip block controllers, that depends. If I actually don't want to use the block controllers because I can do everything with the generic block, that is something that you might want to read about. I don't have the time to explain it. You can skip the block control generation because you can do it without it. But if you create it because you don't know if you're going to use it, it's okay. If you create it and you don't use it, it's perfect. Nothing is going to go bad. Same stuff with the block interface. Everything can be done in the XML if you know how to do it and it fits easy. Actually doing a lot of stuff with the inputs and outputs. Everything is going to be working fine without the block interface of block controllers. So it's okay if you skip it, but if you don't, it's okay. So bam, I already got a bunch of files that obviously most of them are quite familiar from the radio, but important part is mostly this RF knock stuff, oh, I missed one, but it's okay. So the XML is the one that has the node ID, so that's why it's part of RF knock. The rest of those are basically software, but the other ones are old hardware describers. So you have the very low file or you have the test bench. And the good thing about the RF knock mode tool, they have a lot of good things. But for example, if you are all right now starting with the RF knock framework, it creates a block that is based on something that we call the skeleton. And actually the skeleton is a full functional RF knock module block, sorry, that it will work. I mean, if you create something like this and you actually don't know what you're gonna do, but you wanna try, you're really eager to know what is going on, you can compile this block, you can create the big file for it, and actually it will do something that is basically put input into output. It's really easy, but all the files that are already there are functional. So you can just give it a try. It will work right out of the box. So let's go back here. This is basically what we did, adding a bunch of files. So the basic structure of the generated out-of-tree module is somewhat alike to the one from generated. Important apart from those is the RF knock folder that is this. There is where all your files that are going to be FPGA related are going to be located. So you write your very log file, you write your test bench, you set up your make file for the test bench, and everything will be here, and you don't really have to deal with the repository for FPGA, so there is no file location, there is nothing else. All your files are here, and they will just be called whenever they are needed. All right, so already build a block. I've been talking a lot, but actually the block, the creation of the block taught me like less than one minute. But the thing is that we want to use the FPGA because that's why we're here, right? So RF knock module doesn't do it. Geez, right. All right, okay, I'm gonna run. So we have something that is gonna do that for you. Like seriously, it was not that easy to do the connection with your blocks before RF knock module. Right now we have something that is called UHD image builder, and if you were working with that until one month ago it was called make.py. What it does is you tell the script, I'm going to create an image with this, this, this block, and it's like, okay, I'm doing it. For you, you don't have to care about it. Just an example, I created an RFT module that is in the RF knock function. I called it their full bar because of whatever. So FFT and window are blocks that Edo's provides. So you don't really need to tell the script where they are located. But the RFT module actually is nowhere to be found. So you give that with dash i. You say that the device target that is the X300 that is an Edo's device. Dash T, RF knock image. The amount of blocks that you want to have if you want to fill it with hyphos or not, doesn't matter. And it will do it for you. And you just have to wait about one or two hours when it's done, but it's okay. So maybe some of you don't really use a command line. You don't really remember the name of the block, blah, blah, blah. We still got you back because we created a GUI for that. And you're gonna find it really easy to know which blocks are available. And if you add your RFT module, it's going to be listed there. You don't have to remember what it is anymore. You have all the targets here. So if you have an X300, you use the X300. If you have an E200, that is the device that Martin was using, well, you choose that. And you import all your blocks into that part and you click Generate Bitfile and it just do it for you. Takes a long time. You have to have Vivaro, that's the only thing. But it will do it for you. And this button also is really interesting. If you're really into Generator and you're really, really new into that, you can create all your blocks. You have your flow graph and everything is working fine. You import your GRC file here and all your blocks that are RFNUC related are going to be put directly there. And you're like, yeah, I have my flow graph. I want the bitfile for that. Just bam, put it there. And it will do it for you. And that's it. I kind of run a lot. Maybe you have a lot of questions. Well, I'm open to questions. The ICO FPGAs, are they big enough to do any practical SDR work? They what? The ICO FPGAs? Really, I don't know. Well, it was related. Okay. Morton did mention that. Yeah. I think the answer is no. Another question? Have a look at Megan for the ANOC implementation. Well, that will be more a marketing question. I don't know what that is. Megan, from what we talked about, from the past year, but also the high-level design language. Oh, no. So as a matter of fact, we are interested in all tools that make it easy to write your own implementation of the blocks. So we are not looking at that specifically here, but we do not want to force everyone to write everything from bare-locked by hand. So tools that make it easier, we're very interested. So maybe consider that. Yeah. I don't know if we have time for more questions. Yeah, you have like one minute. All right. Is there any way to include IP from the start or in this framework? Oh, right now. I mean, we have this since a long time. It just gets reduced all the time. Yes. Yes. All right, it's a kind of... Yes. I'm really eager to put the IP inclusion into a level of model, because that's what we want. But the thing is that I'm doing my master thesis and it's taking also a lot of time. I'm kind of... Yeah. But it's gonna be very soon. And we have looked at that. So yeah, it would allow us to exchange blocks. You know what I said earlier, like you take down the FQGA, like all the peripherals go away. Like that would solve that problem. Yeah. And you're willing to do it all the time? Yeah. Okay. Thank you. All right.