RfnocNOC Getting Started Tutorial

Welcome to the Rfnocknock Getting Started video tutorial. Rfnoc Network on a Chip, or RfnocNOC, gives FPGA developers a convenient entry point into Generation 3 USRP FPGAs, essentially creating or allowing developers to focus on the functions of their module or block and providing a standard interface to which that block can communicate with the rest of the USRP hardware driver, or UHD. Here you can see an example of this architecture. The custom blocks, in orange, can be blocks from the RfnocNOC block library or a user's custom block. These blocks are called computation engines or RfnocNOC blocks. and interface with the architecture through the standard Axie stream protocol. In this tutorial we'll be using an Edis Research USRP X310 and we'll have a focus on Rfnoc knock development with GNU radio integration. GNU Radio is not necessary to use RfnocNoc, but is helpful because of the many available resources it provides. This tutorial goes through the basics of the RfnocNoc architecture, setting up the RfnocNoc development environment, and goes through all the steps necessary to create a simple RfnocNoc block, and it does so with an example. The Getting Started Guide can be found by going to kb.edis.com and then under the getting started guide section clicking Rfnoc knock development the code that is developed throughout the tutorial is available for download here let's get started at the beginning of the getting started guide there's a brief intro into what is in this guide and then it goes on to the prerequisites. For this tutorial we are running a fresh install of Ubuntu 16.04. When we installed Ubuntu we made sure to check the following two options shown here. We also made sure that all the updates were installed. One way to do this is to open up the software update program. In this setup we've also loaded VocoScreen in order to capture our screen. I'm going to go ahead and open up a terminal that we'll be using shortly. The current version of Xilinx Vivado used for and with RfnocNOC is 2015.4. For the X300 series devices, a paid seed of system or design edition is needed. For the E300 devices, system design or the free webpack edition is sufficient. Here's a quick run-through on where to download the Vivado software. Go to the Xilinx website, then click here, the download. Try that again. Archive and you'll find the 2015.4. This first one is just an update. You actually have to have the software installed before you install an update. This next one allows you to just install a web installer and then it allows you to install the rest of the software or just the software that you want. My preference is usually to just download the very large download file as it says here, or the single download file. You can download it for your particular OS such as Windows or Linux or you can download the installer that has both Linux and Windows. Even with the free webpack version you still need to get a get and install a license from Xilinx. You can follow these links to find out more about licensing and how to get a license. However, I have found that this one address is very helpful. After the xilinx.com, just put in get license. You have to log in but it's fairly straightforward from there. If you're still having trouble downloading, installing, or getting and loading the license, there are plenty of YouTube videos and tutorials on YouTube on how to do this. Here's one that I recently found. There's about 40 minutes long on just in installing the Xilinx Vivado tools. Xilinx's 2015.4 license manager requires there be an Ethernet interface with the eth0 pattern. In my terminal if I run ifconfig You'll notice that I do not have an Ethernet interface with that pattern, eth0 or eth1. You can find information on this in our FAQ section of the RfnocNOC software research page. It's also located in the Edis Research Knowledge Base website. So if you go to RfnocNOC, then under the RfnocNOC FAQs at the very bottom, under Tools, you'll see this, Xilinx License Manager looks for an Ethernet adapter with the name ETH0. Let's follow the instructions on this FAQ to solve this problem. First it says we need to create this file, 70 persistent net rules, in that directory there. My preference is to use Nano. It's an easy little editor but you can use whatever you're most comfortable with. The other trick I'm going to use here is if I highlight something in Linux and then I push the middle mouse button, it actually does the paste for me. Put in my password, and I copy this line that I need to put in there. Here I need to put the MAC address of the Ethernet interface that I'll be using. I'm going to open up another terminal and find that MAC address and just copy it in. Once again if I just highlight it and then middle mouse click on the other terminal, it'll paste it in there for me. Then I exit out. Yes, right to this file. Okay, now we can see if the change has been made. You'll notice that nothing happens. The next thing we could do here is just reboot. There is a way of making this change happen without rebooting. I found this webpage the other day and it's got, I think, four steps that we can follow and then we don't have to reboot. Don't forget to put sudo in the front of these commands. I did it again. Okay, you saw that the connection went down and back up and now I have an interface with E0. Okay, I've already pre-downloaded the Xilinx software onto this computer, but the one thing we need to do before we install is to change the default shell in Ubuntu as described in the app notes. If we go back there, you'll notice here in the notes, in some Linux distributions, i.e. Ubuntu, dash is set as the default shell. We need to change that to bash and it gives an instruction down here on how to do that. Highlight, paste. This will come up and in the instructions it says choose no. The second line is simply to check to make sure that it was switched to bash instead of dash. It looks like it was. Okay now we can install Vivado. I'm going to go to that directory and start the installer. I have to run it under sudo because it actually installs it in the op directory so I need root access Just follow the steps here. Okay, it's installing. Remember that one page where I selected System is because I had the System Edition license. Just feel free to choose the license that you actually have. This will take a little bit to install so I'm just going to pause the video and come back when it's installed. Okay it's installed. At this point you don't want to load your license from this window so just close it out. There's lots of ways to install the license for Vivado. If I go down to where Vivado was installed in the op directory, I'm going to find a program that I can run called VLM, which is the Vivado License Manager. I'll run this as my own user and not as sudo or not as root. It'll become clear why in a minute. Load license, copy license, then I go out and find my license file. Open and you'll notice that it was copied to my home directory in a hidden folder called.xilinx. If I would have done this using the other window that was opened when I had root access, it would have put it in root's hidden.xilinx folder and at that point I wouldn't have had access to it. Now that the Vivado tools are installed and I have the license installed, the next step is to create a development environment. You may have noticed in the prerequisites that there was a need for the software build tools. Those will be loaded here. We're going to be putting our development environment together using Pybombs. Pybombs is the new GNU Radio install management system. It helps resolve any necessary dependencies. In order to install the latest version of PyBOMs, we're going to run the following commands. The first command installs Git. Git is software to manage code in Git repositories. The next command installs pip as well as some other necessary libraries that we need. pip is a package manager used for software written in Python. Okay, now we can install Pybombs using pip. You can see here that we're going right to the git repository where Pybombs exists. Now we have Pybombs loaded. Now we download Pybomb's recipes. Recipes have the instructions necessary to download libraries, programs, and code. For example, there are recipes to download and install GNU Radio. Now that PyBOMBS is installed, we can use it to install and create our development sandbox. One of the recipes that is in the Edis recipes that we just downloaded is called RfnocNoc. This recipe has the instructions to download libraries, programs, and code that we need to do our RfnocNoc development. The location where all this is downloaded to is called a prefix, and we will need to initialize that prefix as part of the process of creating the development sandbox. The directory I have chosen is my... in my home directory making a folder called Rfnoc knock and that's where I'll make my prefix install all of all of these things you can see that as a shortcut in this Linux distribution you can use the tilde forward slash as your home directory it's the same thing for me as typing forward slash home forward slash Edis In addition here you can also see that we're giving this prefix, this path, an alias called rfnock. Remember it'll create a directory right in here in my home directory. I could run this command as it is and it would work fine, but there are other options we can include in order to optimize the way it installs everything. For example, if your computer does not have very many processors or cores, you will want to limit how many PyBOMs it uses in order to install the Rfnoc0 components so that your computer does not appear to hang. However, if in your case it is the opposite and your computer has many processors or cores, then you want to make sure PyBOMs takes advantage of this. You can set the number of cores. so that PyBOMBS remembers your preference or you can add it to the command line we created earlier, which I'm going to do. If you're not sure how many processor cores your computer has, you can run this cat command and look at this file down in the proc directory and find how many CPU cores your computer has. As an alternative, Ubuntu ships with a program called System Monitor and you can view that as well to see how many cores your computer has. Because of hyper threading this computer looks like it has 16. Rule of thumb is to at least leave one or two cores free. Once I hit the command you will see the software that PyBOMs will be installing. It will not only install these but all their dependencies. Later we'll see a high level dependency tree as well. But you can see there are the four things that it's going to install. Oh my network connection went down for a moment. Let's see if PyBOMs can recover. I'm going to go ahead and fast forward a little bit here. It looks like when the network went down it failed to download some of the needed library some boost libraries. This isn't a problem let's just try again. I'm going to go ahead and delete this prefix folder that it created, Pybombs created for me. Just completely delete it as if it wasn't ever there. and I'm going to run that pyboms command again. This time pyboms is going to prompt me because it knows that we had created a prefix there before. When it prompts me, I'll just say that it's okay, that yes it's okay with overwriting it. There's the dependency tree we were talking about earlier. Because Pybombs downloads and compiles the latest code, it will take some time. How long it takes depends on the recipe you're installing from as well as your computer resources. On this computer, it takes a little over 20 minutes to install everything. Okay, install complete. I fast forwarded if you didn't notice. If you'd rather not use Pybombs, there are instructions in the Getting Started Guide to build this development environment manually. Okay, let's look at some of these files that were installed in this prefix. Okay, now remember UHD and other programs and libraries specific to RfnocNOC development sandbox are actually loaded into this RfnocNOC directory prefix. If I run a common UHD command, say UHD find devices, as shown here, it will not return anything because we did not install UHD into its regular install paths. So in order for you to use the programs that we just installed, You need to point to them, you need to set some environment variables. PyBOMB's created a script for you that sets all these variables for you in the current session. If you're in the directory, you can just type source and then set setup underscore env dot sh. Now if we run the command which and then the command we're trying to run the UHD find devices it'll show us where it's installed and you can see that it's actually in the prefix home Edis Rfnoc knock yep right where we expect it to be let's also run UHD config info dash dash version It's another command that's also being run from this prefix. Looks good. So, it's my preference to indicate a terminal session by changing some of its features. If I go to File and New Profile, give it a name, Rfnoc Knock. and we can change some of its attributes maybe the colors that's fine and then this terminal go to terminal change profile to Rfnoc knock now I know that this terminal has all the environment variables set that I need for Rfnoc knock development if you bring up another terminal it is a new session and it won't have these variables set this is how I tell these apart So we just ran this command in the other window. Let's see what happens when I run it in here. Yeah, as expected, because the environment variables aren't set. All right, let's see where we are on the getting started guide. Okay, there's that manually, if you want to manually install, verify the environment, okay, we just ended up doing that. Great, okay now testing the default FPGA images and building from existing blocks. Now let's pull down the default USRP FPGA images. You do this by running UHD underscore images underscore downloader. Now while this is downloading it's important to remember that FPGA images are specific to the device and not the series. An X310 FPGA image will not work on an X300. Loading the wrong type of image onto a USRP will likely brick your device. Here in the getting started guide you can see a table that shows the Rfnoc knock blocks that are included in each image. While this is downloading, I'm going to open up another terminal and set it up for running commands from my RfnocNOC prefix. Then I'm going to find my X310 USRP. Since I set the environment variables in this terminal, better change my profile there. Okay, well, looks like I haven't set up my network yet to be able to talk to my USRP. Take a moment to do that now. Okay, now it sees that I'm connected to something. Now let me try this command over here. Okay that's better. Okay, this command, it actually shows you where it sent the FPGA images, the default ones. Let's take a look at those real quick. Okay, here they are. As I said, we're going to load the default one for the X310, which means we really don't need to know the location. It knows, UHD already knows where it's located. We can follow the instructions in the UHD manual to load the RfnocNOC default image or any other image. Okay, the only thing this command is missing now is I have to input my IP address. What was it again? I've changed my default IP address on my X310 to be slightly different. Alright. 41.2. Okay. And I don't need to send a path as we talked about before because it's the default image. Make sure I got it correct. Looks good. Hit enter. Oh wait okay yeah I see what's going on here it's those brackets you don't want those brackets in that IP address that's part of what you need to remove okay now it's loading that default image onto the FPGA Loading the image often takes a little bit of time, but once the image is loaded onto the USRP, we need to reboot the USRP and then we can check the contents. We do that by just running UHD USRP probe. Then at the very bottom it shows us which blocks are available. It looks like it matches what we're expecting from the default image. Okay, well, let's go to the next section. While one of the main purposes of RfnocNOC is to have users create their own custom blocks and compile them onto the FPGA, there are already many blocks available, just like in GNU Radio, for you to use and create a custom image containing blocks specific to your needs. This section will show you just how to do that. Let's go to this directory in our terminal. In this directory we're going to find two scripts, UHD Image Builder and UHD Image Builder GUI. You can use the command line or the application to create a custom image with existing RfnocNOC blocks. Using the application is nice because it gives you a list of blocks. Oh looks like we're missing some libraries to run the GUI. This means that within the Pybombs recipes there are a couple of missing libraries. For now let's just install these manually. The process is actually different if you're running Ubuntu 14 or 16. Since we are running 16 we'll not have to compile anything. Open another terminal and type the following command to install the missing libraries. So once this is done I'm actually going to kick off one compile using the command line and the other with the GUI. The E310 in the command line and the X310 with the GUI. For this I'm going to open up another terminal so I can kick them off from different terminals. I have to run that setup underscore env.sh so we can set the environment variables. Okay, that terminal is ready for me to run commands. I'm going to need to go to that directory that has these scripts that we're just talking about. And I'll do that momentarily. So I'm going to go ahead and adjust the windows so we can run both of these side by side. Let me try the GUI. Okay, great. The GUI is open. You can see that there's the blocks that we were talking about. Let's go back to the Getting Started Guide and look at the command and its options. Here's the script followed by Rfnoc knock blocks. We're going to compile to window and FFT. Next is the device, an X310. The next option is the target. Different targets come with different peripherals on the USRP. For example, on the X310, you can have the two SFP ports be two 10 gig Ethernet connections, or you can have a 1 gig connection and the other be a 10 gig connection. HG is the target with the 1 gig and the 10 gig connections. The next option is the max number of blocks. Here set to 5. And the last option is filled with FIFOs. This means that we'll have 5 blocks in total. The two blocks I specified, window and FFT, and then the rest will be FIFOs, filled with FIFOs. Information on how and when to use FIFO blocks can be found on our RfnocNOC FAQ section in the software resource page. Okay, so let's choose the default target image. Let's take a peek here, okay, make sure we're getting all the blocks we want. So the default target is that X310 RfnocNOC underscore HG. Okay, let me move this so we can see. Okay, then the two blocks that we're interested in is the window and the FFT. Okay, we also want to fill with FIFOs. Oh, here's another note. You can actually see it building the command line with all the options here at the bottom of the screen in the GUI, which is kind of nice. Check that fill with FIFOs and you'll notice that there is no option to do the dash M. So, it's going to fill with the max number of blocks which up in green you can see is 10. So, we're actually going to get 8 FIFOs in this instance, not just 3. Okay, once I hit that generate the bit file. You'll notice in the command line it starts to work on compiling all those all the necessary code for our image and all those blocks we just added. So the next terminal I'm going to kick off the compile for the USRP e310. Remember I need to get to that directory first. Once I'm in that directory a simple copy and paste. will work just fine for us. Just so you know, the first time you compile, it could take up to two to three hours, and subsequent compiles will be a bit shorter. The other thing you should know, well and if you've ever worked with Xilinx FPGAs before, you know that not all compiles run successfully even if everything's okay. If it fails while creating the bit file, you may just need to start the compile again. Once again, if it fails while creating the bit file, you may just need to start the compile again. So while we wait for these to finish compiling, let's skip down here. To the Getting Started Guide with GNU Radio and Rfnoc Knock, there's a section here on using UHD and Rfnoc Knock. We won't dive into this for this tutorial as our focus is using Rfnoc Knock with GNU Radio. Since we have the default image loaded onto the X310, we can run our first GNU Radio flow graph using an Rfnoc Knock block. Remember that the default image had a DDC block in it? We're going to use that DDC block now. First we run GNU radio making sure that we launch it from a terminal that we have run the setup underscore env script so all the correct environment variables are available. Okay, let's go to open, Rfnoc knock. and source gr edis examples rf knock and there's the ddc.grc all right rf knock underscore ddc.grc important to note is the inclusion of this device 3 block it is needed when running any flow graph with rf with an rf knock block in it you also see the copy block in this flow graph the purpose of this block is to split the stream coming from the fpga block it is only needed to split the stream if only one sync block was enabled or connected to the copy block the copy block would not would could be removed more information on stream splitting is located in the Rfnoc knock FAQ section and it's in that Rfnoc knock software resource page it's also located there on the getting started guide as well okay you can see that we're running the flow graph now I'll tune it to a frequency where I know there's something which is my FM band It's one of my radio stations. Okay. It currently looks like we're pulling in, let's see, the sample rate right now is 10 mega samples per second. We're actually going to be talking about sample rates a little bit later, but there is a difference between what sample rates you're putting in into the Rfnoc knock radio block and in this DDC block. The one you're usually used to putting in is actually in the DDC block. This sample rates here in the Rfnoc knock radio block is actually the master clock rate. Essentially, the the clock rate that the digitizers are running at. That's what that master clock rate is. We'll talk more about that later. Okay, looks like the compiles are finished. Let's look for where the X310 bit file was placed and then load it onto the USRP and check its contents. Alright, here's where... The image was created and put into, or created. Here's where the bit file, the new bit file is that we just created. And notice that the prompt isn't back. That's because the GNU, yeah, the GUI is still running. So once we exit that out, we'll get our prompt back. so let's now load our new image that we just compiled with the window and the FFT and all those FIFO blocks let's load it onto the US and check the contents see if those blocks are in there okay there's the command now because it's a specific image that we want I'm going to be using this extended command of the UHD image loader I'm going to put my own prefix in here and then of course being careful to put my IP address in here with no brackets I think that looks okay okay might be missing something let's go back to the the UHD manual see if I'm doing something wrong so essentially I'm loading this custom image so it'll be this bottom one here okay looks like I'm missing an equal signs a couple equal signs here So this has double quotes on it, so that's okay, just like in the instructions in the manual. Let's put some double quotes around this statement, as well as the equal sign. Hey that looks better. Let's try that. Huh. That's strange. Okay one more time. Let's take a look at this. Ah it does look like the double quotes that I'm putting in that I just added instead of copied in are different. So let me change those. and just to see if it matters let me remove that the equal sign at a curiosity okay great that did it not sure what's different about those quotes but they are different Okay, now that I've done loading, I have to turn off the USRP, turn it back on so it loads the correct image, or our new image. Once I've done that, I can run UHD underscore USRP underscore probe. At the end here, it'll tell us what blocks are in there. So far, that's looking pretty good from what we're seeing in the Getting Started Guide. There's the DMA FIFO, Radio 0, Radio 1, the window, the FFT, and over here it has three FIFOs and ours has eight. And this was once again because the GUI didn't have the option to do the max number, to limit the max number of blocks, so it just put the max number in, which is 10 currently in the X310. So in order to create the custom RfnocNOC block files need to be generated for each layer of the RfnocNOC framework stack that's shown here. To help with this process, RfnocNOC mod tool was created in order to create skeleton code as well as other needed files within the RfnocNOC stack. RfnocNOC mod tool is currently part of the out-of-tree module GR-ETIS and will be familiar to those who have used the GR mod tool within Ganyu Radio. Running the command RfnocNOC mod tool help will give you some information about the tool. We're going to create an out-of-tree module, OOT module, named tutorial. To hold our custom block that we will be building in this tutorial, first we navigate to the source directory in our prefix folder. Once we're in that source directory, we can type rfnock modtool newmod tutorial. This created a directory called rfnock tutorial. We can look inside the directory and see the files in there. If you used RfnocNocModTool before, all of these folders will look familiar, except now there's an additional one, RfnocNoc. Now we want to create our example block called gain. This block will act as a digital gain to the incoming signal. So from within the RfnocNocTutorial directory, run RfnocNocModTool, add, gain. So we could provide all the arguments needed, but we'll just use the interactive menu at this time. Just press Enter at this point. The first thing it asks for is a block ID. Every RfnocNOC block requires an ID so that it can be addressed appropriately. Remember the NOC part of RfnocNOC stands for Network on a Chip. We'll give it something really simple. While we won't be using block controllers for UHD or the block interface files for GNU Radio, we'll take the defaults of no as their presence will not affect performance or function. But if we do want to edit them, they will be available in the future. More on these files later. Now you see the skeleton code and now we can start to begin our code development. Some of the files worth noticing in the output here include this knock block SV file, the.v file, which is the actual Verilog code, and some of these XML files that we'll be editing later. The beginning of this next section gives some high-level details on the RfnocNOC FPGA architecture. To summarize, RfnocNOC provides FPGA developers and infrastructure to add custom IP while using a standard interface to interconnect with the widely used USRP hardware driver, UHD. FPGA developers can then focus the majority of their time on the details of their individual modules and overall system function. RfnocNOC blocks or computation engines need to adhere to the AxiStream standard. There is a link here with more information. Information and a brief introduction to the AxiStream signal interface or signals are shown below. This line here will become important momentarily. It states that the possible address values for the settings register is from 128 to 255, the base address being 128. Now that we have the correct file structure and skeleton code, it's time to start editing the skeleton code, starting with the FPGA code. Our gain example block will have the following functionality as shown in the diagram, in that every sample that comes to it will be multiplied by a value we set in the settings register. For those familiar with FPGA development, you will know that this multiplication operation may take longer than a clock cycle. Therefore, it's necessary to add some pipelining to this design. Let's go ahead and open up the skeleton code for our Verilog code. The location of the code is there in the Getting Started guide. Okay, knock, block, gain. You will see elements in the code that match the architecture we have been talking about, including the knock shell and the axi wrapper. Scroll to the user code. This is where we're going to start making some edits. Notice here that the settings register, the base address is 128 as we saw before inside the getting started guide. So the first we need to set the address for our settings register, the one that will hold the gain value that we pass in from GNU radio and the next we'll set up the register itself. It'll be a 16-bit number. The address being the base value, which we set there. Okay, there's an additional settings register here, but we can ignore it. The readback register. Notice that it's the address 0 for this readback register. That'll become important momentarily. This readback register is how we read back this gain value. It's a 64-bit number, so we'll pad with 48 bits because our gain block is only 16 bits wide. Okay, the next thing we need to do once that register and the readback register are set is we need to add the code to do the multiplication. Now this code looks a little bit complicated. Let's take a look at the block diagram for a little bit easier explanation. Okay, there's the AxiWrapper block and that's the block that our custom block, our game block is going to interface with. Okay, remember that both the I and the Q signals come in from the same 32-bit bus, the I in the upper half of the bus and Q in the lower. This slice block here separates them. The FIFOs here are readily available in the RfnocNOC library for instantiation and are here to provide the pipelining that we spoke of earlier. The multiplication blocks here along with our gain register and then we truncate the outputs to concatenate I and Q into a 32-bit signal. In order to save time typing, I'll just copy this directly from the getting started guide into our Verilog file. Change the name of the section since it's no longer a simple loopback. Something like that. Okay, so on to the next section. So HDL, Hardware Description Language Test Benches, are used to run checks to validate code before compiling an FPGA image or bitstream. FPGA ModTool created a test bench structure as well as skeleton code for our gain block. The auto-generated test bench works with the RfnocNOC test bench architecture. In essence, this test bench architecture allows you to verify your block in the same environment your custom block will be placed in once it's compiled. The test bench code contains the NOC block TB. block which is controlled through the Rfnoc knock sim library sim lib API seen in the diagram this API essentially gives you ability to talk the Rfnoc dock protocol without having to know the details yourself this will become clearer when we take a look at the test bench skeleton code so down here is a diagram of the specific gain test bench that Rfnoc knock motto created for us now let's open up that test bench file We will modify this system Verilog file in order to check the Verilog code we just modified. The first thing we need to do is we need a variable called gain. We'll put that here. Remember, it's a 16-bit number. Under the test4 section, the test bench writes a random 16-bit number to the gain register of our block and then reads it back. Here you can start seeing the benefits of the RfnocNOC SimLib API. We simply use these pre-built tasks, the write underscore user underscore reg and the read user reg to write and to read from our register. Remember that read register was zero in the Verilog code? Well, you see it here as well. Here's where we set that. Also note that we are changing the values to read and write to 60-bit numbers as that is the size of our gain register. In this next section, test 5, we'll be doing three things. We'll set our settings register and here you can see we'll be setting it to 100. We'll send samples down to our block, which will then be multiplied. We'll receive those samples back and then compare them to our expected value. Now here again, we see the power of the RfnocNOC sim library. We don't need to worry about RfnocNOC signaling or the AxiStream signaling or clocking. We just need to use these tasks. For example, the tbstreamer.send to send the samples down, and then the tbstreamer.receive to receive those samples back and then to compare them. Now we're ready to save and run this test bench. In order to run the test bench we need to run a few commands that will set up the correct files as well as the paths in the Xilinx simulation tools. All these commands are in the getting started guide. First thing we need to do is create a build directory within our OOT module folder, the Rfnoc-tutorial that we built earlier. Go into that directory. Run CMake. As shown there. Okay, and the next command is make and then test underscore TB. As it says in the Getting Started Guide, the following command will modify the necessary files and set the correct path to the simulation tools. Remember, only run this following command once for each OOT module. So we're building a block here, our gain block, but the OOT module is the RfnocNOC-Tutorial. So not when we add a new block do we run this, just when we add a new OOT module. So we only need to run this once. Just good to know. Okay, now it's actually time to run our test bench. And we do this by running the following command, shown here in the Getting Started Guide. Then we wait to see if we've passed all the tests. An output here in the Getting Started Guide will allow us to compare whether or not it passed all the tests. That and it also says within the test bench, the test bench output, it actually tells you whether it passed or not. Perfect! We passed all of the tests. So now that we have our gain block written in Verilog and verified with the system Verilog test bench, it's time to compile it into the FPGA. So a few notes before compiling. There's only so much space and resources on an FPGA. Therefore, only a finite amount of blocks can fit onto the FPGA. If blocks are simple and take up very little resources, there is room for the max amount on the device. However, if blocks are complex and take up lots of resources, then fewer blocks can be added to the FPGA. Also, as discussed earlier in the video, There are a lot of other components inside an FPGA taking care of addressing and packetizing, hardware controls, etc. Various configurations of these other modules and components can be chosen based on the FPGA target that is chosen. For example, you can choose the standard default FPGA configuration for an X310 device by using the X310 underscore RfnocNOC underscore HG target. which includes the 1 gig interface and a 10 gig interface. Alternatively, if you choose the one that ends with XG, then if you prefer, you'll have two 10 gigs on both the SFP ports. Other target types are described in the Getting Started Guide as well as in the UHD manual. This next section goes into detail about the UHD image builder script. While we have used this script earlier in the tutorial, we have yet to use it while trying to compile a custom block. We'll skip down a bit in order to find more details on the options. But as we scroll down, you'll see the printout of the build script help menu, an example of how not to use the build script, In summary, it is important to notice that you don't add the block by its full file name where the code resides. That is, I don't type knock underscore block underscore gain dot v or knock underscore block underscore gain, but I simply type in gain. This applies to all the other Rfnoc knock blocks as well, as described in this section I'm highlighting here. Okay, here are some of the currently available Rfnoc knock blocks. You can always look in this folder that's right above this table to see if there have been any additions to the list. Okay, next here are some more details on the options of the build script. On the command line, we'll have to add the"-i option in the command in order to indicate the location of our custom block. Then"-d is for which USRP. Remember, it's the vice and not the series. X300 is not an X310. I think we've already discussed the"-t a couple of times already. Just remember, you don't want to break your device. Okay,"-m, and the"-fill with FIFOs options are often used together. For example, if you add two Rfnoc knock blocks, say the window and the- If you want 4 FIFOs, you could use the"-M6", and then fill with FIFOs. Dash G option will open the Vivado GUI. Once the compile is done, you'll be able to save the Vivado project and work from there if desired. And then dash C just cleans up all the IP and starts a clean compile of everything. Oh, whoops, I missed the dash O up there. Okay, the dash O option will allow you to inspect or edit the instantiation file for Rfnoc knock blocks if you want to see that instantiation file. Okay, so here's the actual command to build our Rfnoc knock block. So we can briefly go over this again. Here's the script, there's our block gain, and a couple other blocks we want, ddc, fft. This is the location of where our custom block is, the dash D for device, dash T for the target, dash M, and then fill with FIFOs. So this command will build the following image with the following blocks. Let's look at the figure down here below. Okay, so here are three blocks, DDC, GAIN, and FFT. The orange ones are custom one, and then three FIFOs because we specified six max, and then fill with FIFOs. Now it's time to go to the directory with the build scripts again. Put my prefix in here. The section here, the next section is on using the graphical interface. Even though I'll kick it off this time from the command line, let's see what it looks like in the Python application. Once we select the target you'll notice that our block isn't in the list. There is a digital gain but remember we called ours just gain so our blocks isn't actually in here. In this section in the Guiding Started Guide, it actually shows us how to get our block inside of the GUI. If we go to number 9, it says manually add an RfnocNOC mod tool generated OOT modules by pointing the application to the makefile.sources file. It tells us where it's located, so let's go there and point to it. Okay, let's hit open. Great, now there's our gain block. And this is how we would add it. Then we could add the other blocks in here as we did before, put them all in there, then we could hit the generate block. Excuse me, the generate bit file. Just as we did before, except this time it has our custom block in there. Instead let's exit out of the GUI and go to the command line. At this point we can just copy the command that was up above here. making sure we put our prefix in there. So this compile shouldn't take as long as the first one did. It's still probably going to be more than an hour though. I'll stop the video fade in and out we'll be back to see what happens okay that was fast so this error has popped up before it actually hasn't done anything to the compiles for me so you can just ignore it Let's load our custom image onto our USRP and check out what blocks are in there. Okay, this time I'm going to use this little trick called, well if I just hit control R and then I start searching for the last command or a command that I've used before, it'll actually bring it up. So if I type UHD underscore image and then loader, this is the one we used before. This will make sure I don't get another error as I have the last two times. Just out of curiosity, just like it says in the UHD manual, let's add those equals in there just to be completely compliant with the manual. Even though it worked fine without them last time. Okay, it's almost loaded. There it is. At this point, just like it says, we have to restart the USRP for it to load the newest image. Okay, remember, we're expecting six blocks, and also here's a printout of what we expect here in the Getting Started Guide. So once we restart our USRP, let's type in UHD underscore USRP underscore probe. All right. You'll notice that we have this block underscore zero. This is actually our gain block. However, we have yet to add the host code that describes our gain block to UHD, the USRP hardware host driver. So now that we have the FPGA portion complete, it's time to move up to the UHD and GNU radio integration. We need to let UHD know about our custom Rfnoc knock block, the name, the settings, registers, inputs, and outputs. It also may be necessary to do some value validating before sending a value to a register in the Rfnoc knock block. If the value validation is straightforward and basic logic and arithmetic can be used, say the value has to be within a certain range, greater than or less than, a domain specific language called knock script can be used if the validation is more complex or the samples coming to and from the block need additional processing then C++ can be used in order to handle such cases we'll start with the UHD integration once again Rfnoc knock mod tool has created skeleton code for us to start from let's modify the gain dot XML block block declaration file Here in the Getting Started Guide it shows you where it's located. We don't actually want it to open in the browser so let me do Open With. Okay that's better. You can see in the skeleton code it already has the name and the address. We just need to add the other details. You can see here in the getting started guide there's a section for registers, which is the first thing we're going to add. It's just one for our gain block. So I'm just going to do a copy paste. Okay, and here you can tell UHD what arguments this block takes. You can see the simple value validation Nox script code here used for validating the gains the gain value, and finally the input and output names and types. Don't forget to save it. Okay, the beginning of this next section provides a good summary of how RfnocNOC framework works within GNU Radio. To use our gain block within the GNU Radio companion software, we need to edit an XML file that is used by GRC. All other files that GNU Radio needs have already been generated for us. So let's just edit this tutorial-gain.xml file. You can also learn more about this file and other GNU Radio files by just going to the GNU Radio wiki and learning more about GNU Radio in general. Okay, I'm starting to put these edits in here, but I want to give kind of a reminder that some of this is actually Python code, and as such, the indentation and spacing becomes important. Once again, if you're curious about this particular XML file, it's pretty much the same for any other GNU Radio GRC XML file that you'd find even outside of the RfnocNOC framework. And more information can be found on the GNU Radio wiki website. I'm just going to speed through and put the rest of these changes in here. I think I have everything in there. I'm going to verify everything one more time. It's always good to verify. Save, close off. Okay. And if I run that again, you'll notice that the block underscore zero is still there. That's because we haven't actually finished inside of the Getting Started Guide. We still need to compile and then install these things, these changes that we've just created. So let's just follow the Getting Started Guide and go back to the build directory. And here we type make install as it shows in the getting started guide. This won't take very long. Okay, looks like it installed everything. Let's take a quick look here. We scroll up. You notice that here's that tutorial- underscore gain excuse me dot XML file is essentially just copied it over to where it needed where the GNU radio companion needed it can you radio in general needed that that XML file so if you ever wanted to uninstall all this stuff that we just installed you can simply type make uninstall and it will uninstall all those files that installed there and remove it from the GNU radio so getting radio companion doesn't see it etc Okay, the next thing we need to do is run UHD underscore USRP probe again to see if it sees it now. Now that everything's compiled and installed there, we should be able to see our block. Okay, great. It actually does see our block. Okay, well, you may remember seeing some warnings when we ran the UHD underscore USRP probe command. The warnings have to do with the PC system buffer sizes. Let's go back real quick and fix those before we continue on. The three warnings have to do with the network receive buffer, the send buffer, and the network MTU size. As you can see from the warning, the warnings, they give you help to get rid of the warnings. We can run commands for the receive and the send buffers. We can just simply do a copy paste right here in this command, in this command terminal. So I'll just highlight and then I'll scroll down, get rid of that. Oh well then I just hit the middle mouse button there. Okay, that's sent. Now I'll do the other one for the receive buffer. Okay, that's sent. And the last one is the MTU size. I'm going to open up another terminal and run a command in there that you'll see. Okay, that's the interface that we want to change. Right now it's currently set, it says, to MTU size of 1500. So let's change that to something like 9000. Then I put the interface name. Put in the password, ifconfig again, and now the MTU size is 9000. So if I run UHD underscore USRP probe again, you'll see that all the warnings are gone. All right now our game blocks in there now we can give it a try within the GRC within GNU radio and that's the next step in the getting started guide testing out the custom block. Okay we can open up the new radio from this terminal since it has all the environment variable set. It's always good to start with a GNU Radio Flow graph that has most of what we need. In this case, the example we used at the beginning of the tutorial, the RfnocNOC DDC block. Let's do a save as and save it as something we want and let's put it in our examples folder in our new OOT module. Okay we can remove those two blocks, change the name in the options block. Let's add another variable up here for our digital gain so we can just copy and paste this one and then change the parameters within. Okay once again thinking of a name what can we name it? That'll work. Let's just start it off. At 1, start, 30, even though it goes way higher, it's a 16-bit number, 30 is fine for example, besides multiplying it, you know. Anyway, that's a fine number there. We'll hit okay. We need to delete this connection. Remember, we already have a DDC block in there. We left it in there so we can leave that block in there. It's actually going to become important in a second because that's the block that actually does the down sampling for us. We actually did want to continue to have that block in there. Okay, but what we are missing is our gain block, so let's see where that might be. Okay, under here, under tutorial, which is our adderty module, there it is, the rfnought gain block. Let's connect it up. Okay, and put our variable in here. What was it? Rx. Okay, so we have our variable. That's right, rxdigital underscore gain. Okay, so here's the note. We talked about it earlier, but about the sampling rates. On the RfnocNOC radio block, this sample rate is actually meant to change the clock speed of the USRP digitizers. And on the X310, the default is 200 mega samples per second, and it can't be changed during runtime. So that's what that is. More information on supported clock rates can actually be found in the UHD manual. The DDC block is an FPGA block that... performs the down sampling and decimation operation that can be changed on the fly just like what you are used to using with the UHD source block this this is why this picture may seem a little confusing inside of the getting started guide because there was an error here so it doesn't actually do any conversion inside of the Rfnoc knock radio block it is coerced to 200 mega samples per second so we'll we'll make sure to get it right inside of this tutorial this video tutorial so by leaving the master clock rate set there inside of the radio block and inside of the DDC we're tracking well on exactly what's going on and what's supposed to happen because once again even if you change that radio the Rfnoc knock radio sampling rate to something else it's still going to be coerced to 200 mega samples per second. Let's move things around a little bit, try to run it, and we see that we got an error. Okay, it says that the error is unexpected indent. Oh, yeah. Remember what we talked about, that that XML file actually contained some Python, so I must have put some bad spacing in there. So let me take a quick look and see if I can see it. If not, we'll go back to the Getting Started Guide and see if I missed something. Okay, not seeing it, so let me go back to the getting started guide. Oh yes, there's a problem here. I can tell that those two aren't lined up. So self is actually lined up with that block tag. Okay, I see. So if I move this over, that looks good now. Okay, so I come back over here. Need to go back to the make install. Up to date, except if I go up, it does show that I installed that XML file again. Essentially, I wrote over it is what I did. So now let's try our flow graph. Oh well let's refresh it first and then run it. Refresh it because I did make that change. Okay good so now it's running no errors except I'm not seeing any output. Maybe it's just the frequency I'm at. So let's change that back to what I did before, which is a local radio station. Still nothing. Okay, well, actually, if you just toggle this digital gain, because the default is set to zero, you don't see anything. So once we set it back, go to zero, and then go to one, we can actually see that it is actually working, but the default was actually set to zero, and that's why. So once we toggled it, meaning we wrote to it a run, then we can see what we're expecting. You can see that if I change the gain, there I'm clipping. a little bit but you can see that it's actually doing it if we reduce the analog gain we can go even higher on the digital game not that you want to do that just that you can okay let's compare it to what we see in the getting started guide Okay, it is a little bit different, and the reason it's different, one, obviously the radio station might not be the same. Actually, I think it is the radio station, but it's different because I have the number of samples. Sample rate's different, so we can change that really quick. Looks like the sample rate in the example is only 1 MHz. And let's just change the frequency here so I don't have to bother with it again while it's running. Once again, it's set to zero, so if we toggle it, then it goes to what we expect. It starts working as we expect. Oh yeah, now that's looking a lot like what we would expect or what's inside the Getting Started Guide. You can reduce the analog gain and you can continue to fidget with the different knobs. There's a troubleshooting section here, so if for some reason you weren't able to To get it running there's a couple of tips in here. Also, the files, all the files used that we modified are also straight right here, so you can just copy them from this zip folder here as a zip file and copy and run them into the directories that it showed. And down here at the bottom we have links and additional resources, the GNU Radio resources, some more information on RfnocNOC, and some other things for you as well.

The custom blocks, in orange, can be blocks from the RfnocNOC block library or a user's custom block. These blocks are called computation engines or RfnocNOC blocks. and interface with the architecture through the standard Axie stream protocol.

In this tutorial we'll be using an Edis Research USRP X310 and we'll have a focus on Rfnoc knock development with GNU radio integration. GNU Radio is not necessary to use RfnocNoc, but is helpful because of the many available resources it provides. This tutorial goes through the basics of the RfnocNoc architecture, setting up the RfnocNoc development environment, and goes through all the steps necessary to create a simple RfnocNoc block, and it does so with an example. The Getting Started Guide can be found by going to kb.edis.com and then under the getting started guide section clicking Rfnoc knock development the code that is developed throughout the tutorial is available for download here let's get started at the beginning of the getting started guide there's a brief intro into what is in this guide and then it goes on to the prerequisites. For this tutorial we are running a fresh install of Ubuntu 16.04.

When we installed Ubuntu we made sure to check the following two options shown here. We also made sure that all the updates were installed. One way to do this is to open up the software update program. In this setup we've also loaded VocoScreen in order to capture our screen.

I'm going to go ahead and open up a terminal that we'll be using shortly. The current version of Xilinx Vivado used for and with RfnocNOC is 2015.4. For the X300 series devices, a paid seed of system or design edition is needed. For the E300 devices, system design or the free webpack edition is sufficient. Here's a quick run-through on where to download the Vivado software.

Go to the Xilinx website, then click here, the download. Try that again. Archive and you'll find the 2015.4. This first one is just an update. You actually have to have the software installed before you install an update.

This next one allows you to just install a web installer and then it allows you to install the rest of the software or just the software that you want. My preference is usually to just download the very large download file as it says here, or the single download file. You can download it for your particular OS such as Windows or Linux or you can download the installer that has both Linux and Windows.

Even with the free webpack version you still need to get a get and install a license from Xilinx. You can follow these links to find out more about licensing and how to get a license. However, I have found that this one address is very helpful. After the xilinx.com, just put in get license.

You have to log in but it's fairly straightforward from there. If you're still having trouble downloading, installing, or getting and loading the license, there are plenty of YouTube videos and tutorials on YouTube on how to do this. Here's one that I recently found.

There's about 40 minutes long on just in installing the Xilinx Vivado tools. Xilinx's 2015.4 license manager requires there be an Ethernet interface with the eth0 pattern. In my terminal if I run ifconfig You'll notice that I do not have an Ethernet interface with that pattern, eth0 or eth1. You can find information on this in our FAQ section of the RfnocNOC software research page.

It's also located in the Edis Research Knowledge Base website. So if you go to RfnocNOC, then under the RfnocNOC FAQs at the very bottom, under Tools, you'll see this, Xilinx License Manager looks for an Ethernet adapter with the name ETH0. Let's follow the instructions on this FAQ to solve this problem.

First it says we need to create this file, 70 persistent net rules, in that directory there. My preference is to use Nano. It's an easy little editor but you can use whatever you're most comfortable with.

The other trick I'm going to use here is if I highlight something in Linux and then I push the middle mouse button, it actually does the paste for me. Put in my password, and I copy this line that I need to put in there. Here I need to put the MAC address of the Ethernet interface that I'll be using. I'm going to open up another terminal and find that MAC address and just copy it in. Once again if I just highlight it and then middle mouse click on the other terminal, it'll paste it in there for me.

Then I exit out. Yes, right to this file. Okay, now we can see if the change has been made.

You'll notice that nothing happens. The next thing we could do here is just reboot. There is a way of making this change happen without rebooting.

I found this webpage the other day and it's got, I think, four steps that we can follow and then we don't have to reboot. Don't forget to put sudo in the front of these commands. I did it again. Okay, you saw that the connection went down and back up and now I have an interface with E0. Okay, I've already pre-downloaded the Xilinx software onto this computer, but the one thing we need to do before we install is to change the default shell in Ubuntu as described in the app notes.

If we go back there, you'll notice here in the notes, in some Linux distributions, i.e. Ubuntu, dash is set as the default shell. We need to change that to bash and it gives an instruction down here on how to do that. Highlight, paste. This will come up and in the instructions it says choose no.

The second line is simply to check to make sure that it was switched to bash instead of dash. It looks like it was. Okay now we can install Vivado. I'm going to go to that directory and start the installer.

I have to run it under sudo because it actually installs it in the op directory so I need root access Just follow the steps here. Okay, it's installing. Remember that one page where I selected System is because I had the System Edition license. Just feel free to choose the license that you actually have.

This will take a little bit to install so I'm just going to pause the video and come back when it's installed. Okay it's installed. At this point you don't want to load your license from this window so just close it out. There's lots of ways to install the license for Vivado.

If I go down to where Vivado was installed in the op directory, I'm going to find a program that I can run called VLM, which is the Vivado License Manager. I'll run this as my own user and not as sudo or not as root. It'll become clear why in a minute.

Load license, copy license, then I go out and find my license file. Open and you'll notice that it was copied to my home directory in a hidden folder called.xilinx. If I would have done this using the other window that was opened when I had root access, it would have put it in root's hidden.xilinx folder and at that point I wouldn't have had access to it. Now that the Vivado tools are installed and I have the license installed, the next step is to create a development environment. You may have noticed in the prerequisites that there was a need for the software build tools.

Those will be loaded here. We're going to be putting our development environment together using Pybombs. Pybombs is the new GNU Radio install management system.

It helps resolve any necessary dependencies. In order to install the latest version of PyBOMs, we're going to run the following commands. The first command installs Git.

Git is software to manage code in Git repositories. The next command installs pip as well as some other necessary libraries that we need. pip is a package manager used for software written in Python. Okay, now we can install Pybombs using pip. You can see here that we're going right to the git repository where Pybombs exists.

Now we have Pybombs loaded. Now we download Pybomb's recipes. Recipes have the instructions necessary to download libraries, programs, and code. For example, there are recipes to download and install GNU Radio.

Now that PyBOMBS is installed, we can use it to install and create our development sandbox. One of the recipes that is in the Edis recipes that we just downloaded is called RfnocNoc. This recipe has the instructions to download libraries, programs, and code that we need to do our RfnocNoc development. The location where all this is downloaded to is called a prefix, and we will need to initialize that prefix as part of the process of creating the development sandbox. The directory I have chosen is my...

in my home directory making a folder called Rfnoc knock and that's where I'll make my prefix install all of all of these things you can see that as a shortcut in this Linux distribution you can use the tilde forward slash as your home directory it's the same thing for me as typing forward slash home forward slash Edis In addition here you can also see that we're giving this prefix, this path, an alias called rfnock. Remember it'll create a directory right in here in my home directory. I could run this command as it is and it would work fine, but there are other options we can include in order to optimize the way it installs everything. For example, if your computer does not have very many processors or cores, you will want to limit how many PyBOMs it uses in order to install the Rfnoc0 components so that your computer does not appear to hang.

However, if in your case it is the opposite and your computer has many processors or cores, then you want to make sure PyBOMs takes advantage of this. You can set the number of cores. so that PyBOMBS remembers your preference or you can add it to the command line we created earlier, which I'm going to do. If you're not sure how many processor cores your computer has, you can run this cat command and look at this file down in the proc directory and find how many CPU cores your computer has.

As an alternative, Ubuntu ships with a program called System Monitor and you can view that as well to see how many cores your computer has. Because of hyper threading this computer looks like it has 16. Rule of thumb is to at least leave one or two cores free. Once I hit the command you will see the software that PyBOMs will be installing. It will not only install these but all their dependencies. Later we'll see a high level dependency tree as well.

But you can see there are the four things that it's going to install. Oh my network connection went down for a moment. Let's see if PyBOMs can recover. I'm going to go ahead and fast forward a little bit here.

It looks like when the network went down it failed to download some of the needed library some boost libraries. This isn't a problem let's just try again. I'm going to go ahead and delete this prefix folder that it created, Pybombs created for me.

Just completely delete it as if it wasn't ever there. and I'm going to run that pyboms command again. This time pyboms is going to prompt me because it knows that we had created a prefix there before. When it prompts me, I'll just say that it's okay, that yes it's okay with overwriting it.

There's the dependency tree we were talking about earlier. Because Pybombs downloads and compiles the latest code, it will take some time. How long it takes depends on the recipe you're installing from as well as your computer resources.

On this computer, it takes a little over 20 minutes to install everything. Okay, install complete. I fast forwarded if you didn't notice.

If you'd rather not use Pybombs, there are instructions in the Getting Started Guide to build this development environment manually. Okay, let's look at some of these files that were installed in this prefix. Okay, now remember UHD and other programs and libraries specific to RfnocNOC development sandbox are actually loaded into this RfnocNOC directory prefix. If I run a common UHD command, say UHD find devices, as shown here, it will not return anything because we did not install UHD into its regular install paths. So in order for you to use the programs that we just installed, You need to point to them, you need to set some environment variables.

PyBOMB's created a script for you that sets all these variables for you in the current session. If you're in the directory, you can just type source and then set setup underscore env dot sh. Now if we run the command which and then the command we're trying to run the UHD find devices it'll show us where it's installed and you can see that it's actually in the prefix home Edis Rfnoc knock yep right where we expect it to be let's also run UHD config info dash dash version It's another command that's also being run from this prefix. Looks good.

So, it's my preference to indicate a terminal session by changing some of its features. If I go to File and New Profile, give it a name, Rfnoc Knock. and we can change some of its attributes maybe the colors that's fine and then this terminal go to terminal change profile to Rfnoc knock now I know that this terminal has all the environment variables set that I need for Rfnoc knock development if you bring up another terminal it is a new session and it won't have these variables set this is how I tell these apart So we just ran this command in the other window.

Let's see what happens when I run it in here. Yeah, as expected, because the environment variables aren't set. All right, let's see where we are on the getting started guide. Okay, there's that manually, if you want to manually install, verify the environment, okay, we just ended up doing that.

Great, okay now testing the default FPGA images and building from existing blocks. Now let's pull down the default USRP FPGA images. You do this by running UHD underscore images underscore downloader. Now while this is downloading it's important to remember that FPGA images are specific to the device and not the series. An X310 FPGA image will not work on an X300.

Loading the wrong type of image onto a USRP will likely brick your device. Here in the getting started guide you can see a table that shows the Rfnoc knock blocks that are included in each image. While this is downloading, I'm going to open up another terminal and set it up for running commands from my RfnocNOC prefix. Then I'm going to find my X310 USRP.

Since I set the environment variables in this terminal, better change my profile there. Okay, well, looks like I haven't set up my network yet to be able to talk to my USRP. Take a moment to do that now.

Okay, now it sees that I'm connected to something. Now let me try this command over here. Okay that's better.

Okay, this command, it actually shows you where it sent the FPGA images, the default ones. Let's take a look at those real quick. Okay, here they are.

As I said, we're going to load the default one for the X310, which means we really don't need to know the location. It knows, UHD already knows where it's located. We can follow the instructions in the UHD manual to load the RfnocNOC default image or any other image. Okay, the only thing this command is missing now is I have to input my IP address.

What was it again? I've changed my default IP address on my X310 to be slightly different. Alright. 41.2. Okay.

And I don't need to send a path as we talked about before because it's the default image. Make sure I got it correct. Looks good. Hit enter. Oh wait okay yeah I see what's going on here it's those brackets you don't want those brackets in that IP address that's part of what you need to remove okay now it's loading that default image onto the FPGA Loading the image often takes a little bit of time, but once the image is loaded onto the USRP, we need to reboot the USRP and then we can check the contents.

We do that by just running UHD USRP probe. Then at the very bottom it shows us which blocks are available. It looks like it matches what we're expecting from the default image. Okay, well, let's go to the next section. While one of the main purposes of RfnocNOC is to have users create their own custom blocks and compile them onto the FPGA, there are already many blocks available, just like in GNU Radio, for you to use and create a custom image containing blocks specific to your needs.

This section will show you just how to do that. Let's go to this directory in our terminal. In this directory we're going to find two scripts, UHD Image Builder and UHD Image Builder GUI. You can use the command line or the application to create a custom image with existing RfnocNOC blocks.

Using the application is nice because it gives you a list of blocks. Oh looks like we're missing some libraries to run the GUI. This means that within the Pybombs recipes there are a couple of missing libraries. For now let's just install these manually. The process is actually different if you're running Ubuntu 14 or 16. Since we are running 16 we'll not have to compile anything.

Open another terminal and type the following command to install the missing libraries. So once this is done I'm actually going to kick off one compile using the command line and the other with the GUI. The E310 in the command line and the X310 with the GUI. For this I'm going to open up another terminal so I can kick them off from different terminals. I have to run that setup underscore env.sh so we can set the environment variables.

Okay, that terminal is ready for me to run commands. I'm going to need to go to that directory that has these scripts that we're just talking about. And I'll do that momentarily.

So I'm going to go ahead and adjust the windows so we can run both of these side by side. Let me try the GUI. Okay, great.

The GUI is open. You can see that there's the blocks that we were talking about. Let's go back to the Getting Started Guide and look at the command and its options. Here's the script followed by Rfnoc knock blocks. We're going to compile to window and FFT.

Next is the device, an X310. The next option is the target. Different targets come with different peripherals on the USRP. For example, on the X310, you can have the two SFP ports be two 10 gig Ethernet connections, or you can have a 1 gig connection and the other be a 10 gig connection. HG is the target with the 1 gig and the 10 gig connections.

The next option is the max number of blocks. Here set to 5. And the last option is filled with FIFOs. This means that we'll have 5 blocks in total. The two blocks I specified, window and FFT, and then the rest will be FIFOs, filled with FIFOs. Information on how and when to use FIFO blocks can be found on our RfnocNOC FAQ section in the software resource page.

Okay, so let's choose the default target image. Let's take a peek here, okay, make sure we're getting all the blocks we want. So the default target is that X310 RfnocNOC underscore HG. Okay, let me move this so we can see. Okay, then the two blocks that we're interested in is the window and the FFT.

Okay, we also want to fill with FIFOs. Oh, here's another note. You can actually see it building the command line with all the options here at the bottom of the screen in the GUI, which is kind of nice.

Check that fill with FIFOs and you'll notice that there is no option to do the dash M. So, it's going to fill with the max number of blocks which up in green you can see is 10. So, we're actually going to get 8 FIFOs in this instance, not just 3. Okay, once I hit that generate the bit file. You'll notice in the command line it starts to work on compiling all those all the necessary code for our image and all those blocks we just added.

So the next terminal I'm going to kick off the compile for the USRP e310. Remember I need to get to that directory first. Once I'm in that directory a simple copy and paste. will work just fine for us.

Just so you know, the first time you compile, it could take up to two to three hours, and subsequent compiles will be a bit shorter. The other thing you should know, well and if you've ever worked with Xilinx FPGAs before, you know that not all compiles run successfully even if everything's okay. If it fails while creating the bit file, you may just need to start the compile again.

Once again, if it fails while creating the bit file, you may just need to start the compile again. So while we wait for these to finish compiling, let's skip down here. To the Getting Started Guide with GNU Radio and Rfnoc Knock, there's a section here on using UHD and Rfnoc Knock. We won't dive into this for this tutorial as our focus is using Rfnoc Knock with GNU Radio. Since we have the default image loaded onto the X310, we can run our first GNU Radio flow graph using an Rfnoc Knock block.

Remember that the default image had a DDC block in it? We're going to use that DDC block now. First we run GNU radio making sure that we launch it from a terminal that we have run the setup underscore env script so all the correct environment variables are available.

Okay, let's go to open, Rfnoc knock. and source gr edis examples rf knock and there's the ddc.grc all right rf knock underscore ddc.grc important to note is the inclusion of this device 3 block it is needed when running any flow graph with rf with an rf knock block in it you also see the copy block in this flow graph the purpose of this block is to split the stream coming from the fpga block it is only needed to split the stream if only one sync block was enabled or connected to the copy block the copy block would not would could be removed more information on stream splitting is located in the Rfnoc knock FAQ section and it's in that Rfnoc knock software resource page it's also located there on the getting started guide as well okay you can see that we're running the flow graph now I'll tune it to a frequency where I know there's something which is my FM band It's one of my radio stations. Okay.

It currently looks like we're pulling in, let's see, the sample rate right now is 10 mega samples per second. We're actually going to be talking about sample rates a little bit later, but there is a difference between what sample rates you're putting in into the Rfnoc knock radio block and in this DDC block. The one you're usually used to putting in is actually in the DDC block. This sample rates here in the Rfnoc knock radio block is actually the master clock rate. Essentially, the the clock rate that the digitizers are running at.

That's what that master clock rate is. We'll talk more about that later. Okay, looks like the compiles are finished.

Let's look for where the X310 bit file was placed and then load it onto the USRP and check its contents. Alright, here's where... The image was created and put into, or created.

Here's where the bit file, the new bit file is that we just created. And notice that the prompt isn't back. That's because the GNU, yeah, the GUI is still running.

So once we exit that out, we'll get our prompt back. so let's now load our new image that we just compiled with the window and the FFT and all those FIFO blocks let's load it onto the US and check the contents see if those blocks are in there okay there's the command now because it's a specific image that we want I'm going to be using this extended command of the UHD image loader I'm going to put my own prefix in here and then of course being careful to put my IP address in here with no brackets I think that looks okay okay might be missing something let's go back to the the UHD manual see if I'm doing something wrong so essentially I'm loading this custom image so it'll be this bottom one here okay looks like I'm missing an equal signs a couple equal signs here So this has double quotes on it, so that's okay, just like in the instructions in the manual. Let's put some double quotes around this statement, as well as the equal sign.

Hey that looks better. Let's try that. Huh.

That's strange. Okay one more time. Let's take a look at this. Ah it does look like the double quotes that I'm putting in that I just added instead of copied in are different. So let me change those.

and just to see if it matters let me remove that the equal sign at a curiosity okay great that did it not sure what's different about those quotes but they are different Okay, now that I've done loading, I have to turn off the USRP, turn it back on so it loads the correct image, or our new image. Once I've done that, I can run UHD underscore USRP underscore probe. At the end here, it'll tell us what blocks are in there.

So far, that's looking pretty good from what we're seeing in the Getting Started Guide. There's the DMA FIFO, Radio 0, Radio 1, the window, the FFT, and over here it has three FIFOs and ours has eight. And this was once again because the GUI didn't have the option to do the max number, to limit the max number of blocks, so it just put the max number in, which is 10 currently in the X310.

So in order to create the custom RfnocNOC block files need to be generated for each layer of the RfnocNOC framework stack that's shown here. To help with this process, RfnocNOC mod tool was created in order to create skeleton code as well as other needed files within the RfnocNOC stack. RfnocNOC mod tool is currently part of the out-of-tree module GR-ETIS and will be familiar to those who have used the GR mod tool within Ganyu Radio.

Running the command RfnocNOC mod tool help will give you some information about the tool. We're going to create an out-of-tree module, OOT module, named tutorial. To hold our custom block that we will be building in this tutorial, first we navigate to the source directory in our prefix folder.

Once we're in that source directory, we can type rfnock modtool newmod tutorial. This created a directory called rfnock tutorial. We can look inside the directory and see the files in there.

If you used RfnocNocModTool before, all of these folders will look familiar, except now there's an additional one, RfnocNoc. Now we want to create our example block called gain. This block will act as a digital gain to the incoming signal. So from within the RfnocNocTutorial directory, run RfnocNocModTool, add, gain.

So we could provide all the arguments needed, but we'll just use the interactive menu at this time. Just press Enter at this point. The first thing it asks for is a block ID. Every RfnocNOC block requires an ID so that it can be addressed appropriately. Remember the NOC part of RfnocNOC stands for Network on a Chip.

We'll give it something really simple. While we won't be using block controllers for UHD or the block interface files for GNU Radio, we'll take the defaults of no as their presence will not affect performance or function. But if we do want to edit them, they will be available in the future.

More on these files later. Now you see the skeleton code and now we can start to begin our code development. Some of the files worth noticing in the output here include this knock block SV file, the.v file, which is the actual Verilog code, and some of these XML files that we'll be editing later.

The beginning of this next section gives some high-level details on the RfnocNOC FPGA architecture. To summarize, RfnocNOC provides FPGA developers and infrastructure to add custom IP while using a standard interface to interconnect with the widely used USRP hardware driver, UHD. FPGA developers can then focus the majority of their time on the details of their individual modules and overall system function.

RfnocNOC blocks or computation engines need to adhere to the AxiStream standard. There is a link here with more information. Information and a brief introduction to the AxiStream signal interface or signals are shown below.

This line here will become important momentarily. It states that the possible address values for the settings register is from 128 to 255, the base address being 128. Now that we have the correct file structure and skeleton code, it's time to start editing the skeleton code, starting with the FPGA code. Our gain example block will have the following functionality as shown in the diagram, in that every sample that comes to it will be multiplied by a value we set in the settings register. For those familiar with FPGA development, you will know that this multiplication operation may take longer than a clock cycle.

Therefore, it's necessary to add some pipelining to this design. Let's go ahead and open up the skeleton code for our Verilog code. The location of the code is there in the Getting Started guide.

Okay, knock, block, gain. You will see elements in the code that match the architecture we have been talking about, including the knock shell and the axi wrapper. Scroll to the user code. This is where we're going to start making some edits.

Notice here that the settings register, the base address is 128 as we saw before inside the getting started guide. So the first we need to set the address for our settings register, the one that will hold the gain value that we pass in from GNU radio and the next we'll set up the register itself. It'll be a 16-bit number.

The address being the base value, which we set there. Okay, there's an additional settings register here, but we can ignore it. The readback register. Notice that it's the address 0 for this readback register.

That'll become important momentarily. This readback register is how we read back this gain value. It's a 64-bit number, so we'll pad with 48 bits because our gain block is only 16 bits wide. Okay, the next thing we need to do once that register and the readback register are set is we need to add the code to do the multiplication. Now this code looks a little bit complicated.

Let's take a look at the block diagram for a little bit easier explanation. Okay, there's the AxiWrapper block and that's the block that our custom block, our game block is going to interface with. Okay, remember that both the I and the Q signals come in from the same 32-bit bus, the I in the upper half of the bus and Q in the lower.

This slice block here separates them. The FIFOs here are readily available in the RfnocNOC library for instantiation and are here to provide the pipelining that we spoke of earlier. The multiplication blocks here along with our gain register and then we truncate the outputs to concatenate I and Q into a 32-bit signal. In order to save time typing, I'll just copy this directly from the getting started guide into our Verilog file.

Change the name of the section since it's no longer a simple loopback. Something like that. Okay, so on to the next section.

So HDL, Hardware Description Language Test Benches, are used to run checks to validate code before compiling an FPGA image or bitstream. FPGA ModTool created a test bench structure as well as skeleton code for our gain block. The auto-generated test bench works with the RfnocNOC test bench architecture. In essence, this test bench architecture allows you to verify your block in the same environment your custom block will be placed in once it's compiled. The test bench code contains the NOC block TB.

block which is controlled through the Rfnoc knock sim library sim lib API seen in the diagram this API essentially gives you ability to talk the Rfnoc dock protocol without having to know the details yourself this will become clearer when we take a look at the test bench skeleton code so down here is a diagram of the specific gain test bench that Rfnoc knock motto created for us now let's open up that test bench file We will modify this system Verilog file in order to check the Verilog code we just modified. The first thing we need to do is we need a variable called gain. We'll put that here. Remember, it's a 16-bit number.

Under the test4 section, the test bench writes a random 16-bit number to the gain register of our block and then reads it back. Here you can start seeing the benefits of the RfnocNOC SimLib API. We simply use these pre-built tasks, the write underscore user underscore reg and the read user reg to write and to read from our register. Remember that read register was zero in the Verilog code? Well, you see it here as well.

Here's where we set that. Also note that we are changing the values to read and write to 60-bit numbers as that is the size of our gain register. In this next section, test 5, we'll be doing three things.

We'll set our settings register and here you can see we'll be setting it to 100. We'll send samples down to our block, which will then be multiplied. We'll receive those samples back and then compare them to our expected value. Now here again, we see the power of the RfnocNOC sim library. We don't need to worry about RfnocNOC signaling or the AxiStream signaling or clocking.

We just need to use these tasks. For example, the tbstreamer.send to send the samples down, and then the tbstreamer.receive to receive those samples back and then to compare them. Now we're ready to save and run this test bench.

In order to run the test bench we need to run a few commands that will set up the correct files as well as the paths in the Xilinx simulation tools. All these commands are in the getting started guide. First thing we need to do is create a build directory within our OOT module folder, the Rfnoc-tutorial that we built earlier. Go into that directory.

Run CMake. As shown there. Okay, and the next command is make and then test underscore TB.

As it says in the Getting Started Guide, the following command will modify the necessary files and set the correct path to the simulation tools. Remember, only run this following command once for each OOT module. So we're building a block here, our gain block, but the OOT module is the RfnocNOC-Tutorial.

So not when we add a new block do we run this, just when we add a new OOT module. So we only need to run this once. Just good to know.

Okay, now it's actually time to run our test bench. And we do this by running the following command, shown here in the Getting Started Guide. Then we wait to see if we've passed all the tests.

An output here in the Getting Started Guide will allow us to compare whether or not it passed all the tests. That and it also says within the test bench, the test bench output, it actually tells you whether it passed or not. Perfect! We passed all of the tests. So now that we have our gain block written in Verilog and verified with the system Verilog test bench, it's time to compile it into the FPGA.

So a few notes before compiling. There's only so much space and resources on an FPGA. Therefore, only a finite amount of blocks can fit onto the FPGA. If blocks are simple and take up very little resources, there is room for the max amount on the device. However, if blocks are complex and take up lots of resources, then fewer blocks can be added to the FPGA.

Also, as discussed earlier in the video, There are a lot of other components inside an FPGA taking care of addressing and packetizing, hardware controls, etc. Various configurations of these other modules and components can be chosen based on the FPGA target that is chosen. For example, you can choose the standard default FPGA configuration for an X310 device by using the X310 underscore RfnocNOC underscore HG target.

which includes the 1 gig interface and a 10 gig interface. Alternatively, if you choose the one that ends with XG, then if you prefer, you'll have two 10 gigs on both the SFP ports. Other target types are described in the Getting Started Guide as well as in the UHD manual. This next section goes into detail about the UHD image builder script. While we have used this script earlier in the tutorial, we have yet to use it while trying to compile a custom block.

We'll skip down a bit in order to find more details on the options. But as we scroll down, you'll see the printout of the build script help menu, an example of how not to use the build script, In summary, it is important to notice that you don't add the block by its full file name where the code resides. That is, I don't type knock underscore block underscore gain dot v or knock underscore block underscore gain, but I simply type in gain.

This applies to all the other Rfnoc knock blocks as well, as described in this section I'm highlighting here. Okay, here are some of the currently available Rfnoc knock blocks. You can always look in this folder that's right above this table to see if there have been any additions to the list. Okay, next here are some more details on the options of the build script. On the command line, we'll have to add the"-i option in the command in order to indicate the location of our custom block. Then"-d is for which USRP.

Remember, it's the vice and not the series. X300 is not an X310. I think we've already discussed the"-t a couple of times already. Just remember, you don't want to break your device. Okay,"-m, and the"-fill with FIFOs options are often used together. For example, if you add two Rfnoc knock blocks, say the window and the- If you want 4 FIFOs, you could use the"-M6", and then fill with FIFOs. Dash G option will open the Vivado GUI. Once the compile is done, you'll be able to save the Vivado project and work from there if desired. And then dash C just cleans up all the IP and starts a clean compile of everything. Oh, whoops, I missed the dash O up there. Okay, the dash O option will allow you to inspect or edit the instantiation file for Rfnoc knock blocks if you want to see that instantiation file. Okay, so here's the actual command to build our Rfnoc knock block. So we can briefly go over this again. Here's the script, there's our block gain, and a couple other blocks we want, ddc, fft. This is the location of where our custom block is, the dash D for device, dash T for the target, dash M, and then fill with FIFOs. So this command will build the following image with the following blocks. Let's look at the figure down here below. Okay, so here are three blocks, DDC, GAIN, and FFT. The orange ones are custom one, and then three FIFOs because we specified six max, and then fill with FIFOs. Now it's time to go to the directory with the build scripts again. Put my prefix in here. The section here, the next section is on using the graphical interface. Even though I'll kick it off this time from the command line, let's see what it looks like in the Python application. Once we select the target you'll notice that our block isn't in the list. There is a digital gain but remember we called ours just gain so our blocks isn't actually in here. In this section in the Guiding Started Guide, it actually shows us how to get our block inside of the GUI. If we go to number 9, it says manually add an RfnocNOC mod tool generated OOT modules by pointing the application to the makefile.sources file. It tells us where it's located, so let's go there and point to it. Okay, let's hit open. Great, now there's our gain block. And this is how we would add it. Then we could add the other blocks in here as we did before, put them all in there, then we could hit the generate block. Excuse me, the generate bit file. Just as we did before, except this time it has our custom block in there. Instead let's exit out of the GUI and go to the command line. At this point we can just copy the command that was up above here. making sure we put our prefix in there. So this compile shouldn't take as long as the first one did. It's still probably going to be more than an hour though. I'll stop the video fade in and out we'll be back to see what happens okay that was fast so this error has popped up before it actually hasn't done anything to the compiles for me so you can just ignore it Let's load our custom image onto our USRP and check out what blocks are in there. Okay, this time I'm going to use this little trick called, well if I just hit control R and then I start searching for the last command or a command that I've used before, it'll actually bring it up. So if I type UHD underscore image and then loader, this is the one we used before. This will make sure I don't get another error as I have the last two times. Just out of curiosity, just like it says in the UHD manual, let's add those equals in there just to be completely compliant with the manual. Even though it worked fine without them last time. Okay, it's almost loaded. There it is. At this point, just like it says, we have to restart the USRP for it to load the newest image. Okay, remember, we're expecting six blocks, and also here's a printout of what we expect here in the Getting Started Guide. So once we restart our USRP, let's type in UHD underscore USRP underscore probe. All right. You'll notice that we have this block underscore zero. This is actually our gain block. However, we have yet to add the host code that describes our gain block to UHD, the USRP hardware host driver. So now that we have the FPGA portion complete, it's time to move up to the UHD and GNU radio integration. We need to let UHD know about our custom Rfnoc knock block, the name, the settings, registers, inputs, and outputs. It also may be necessary to do some value validating before sending a value to a register in the Rfnoc knock block. If the value validation is straightforward and basic logic and arithmetic can be used, say the value has to be within a certain range, greater than or less than, a domain specific language called knock script can be used if the validation is more complex or the samples coming to and from the block need additional processing then C++ can be used in order to handle such cases we'll start with the UHD integration once again Rfnoc knock mod tool has created skeleton code for us to start from let's modify the gain dot XML block block declaration file Here in the Getting Started Guide it shows you where it's located. We don't actually want it to open in the browser so let me do Open With. Okay that's better. You can see in the skeleton code it already has the name and the address. We just need to add the other details. You can see here in the getting started guide there's a section for registers, which is the first thing we're going to add. It's just one for our gain block. So I'm just going to do a copy paste. Okay, and here you can tell UHD what arguments this block takes. You can see the simple value validation Nox script code here used for validating the gains the gain value, and finally the input and output names and types. Don't forget to save it. Okay, the beginning of this next section provides a good summary of how RfnocNOC framework works within GNU Radio. To use our gain block within the GNU Radio companion software, we need to edit an XML file that is used by GRC. All other files that GNU Radio needs have already been generated for us. So let's just edit this tutorial-gain.xml file. You can also learn more about this file and other GNU Radio files by just going to the GNU Radio wiki and learning more about GNU Radio in general. Okay, I'm starting to put these edits in here, but I want to give kind of a reminder that some of this is actually Python code, and as such, the indentation and spacing becomes important. Once again, if you're curious about this particular XML file, it's pretty much the same for any other GNU Radio GRC XML file that you'd find even outside of the RfnocNOC framework. And more information can be found on the GNU Radio wiki website. I'm just going to speed through and put the rest of these changes in here. I think I have everything in there. I'm going to verify everything one more time. It's always good to verify. Save, close off. Okay. And if I run that again, you'll notice that the block underscore zero is still there. That's because we haven't actually finished inside of the Getting Started Guide. We still need to compile and then install these things, these changes that we've just created. So let's just follow the Getting Started Guide and go back to the build directory. And here we type make install as it shows in the getting started guide. This won't take very long. Okay, looks like it installed everything. Let's take a quick look here. We scroll up. You notice that here's that tutorial- underscore gain excuse me dot XML file is essentially just copied it over to where it needed where the GNU radio companion needed it can you radio in general needed that that XML file so if you ever wanted to uninstall all this stuff that we just installed you can simply type make uninstall and it will uninstall all those files that installed there and remove it from the GNU radio so getting radio companion doesn't see it etc Okay, the next thing we need to do is run UHD underscore USRP probe again to see if it sees it now. Now that everything's compiled and installed there, we should be able to see our block. Okay, great. It actually does see our block. Okay, well, you may remember seeing some warnings when we ran the UHD underscore USRP probe command. The warnings have to do with the PC system buffer sizes. Let's go back real quick and fix those before we continue on. The three warnings have to do with the network receive buffer, the send buffer, and the network MTU size. As you can see from the warning, the warnings, they give you help to get rid of the warnings. We can run commands for the receive and the send buffers. We can just simply do a copy paste right here in this command, in this command terminal. So I'll just highlight and then I'll scroll down, get rid of that. Oh well then I just hit the middle mouse button there. Okay, that's sent. Now I'll do the other one for the receive buffer. Okay, that's sent. And the last one is the MTU size. I'm going to open up another terminal and run a command in there that you'll see. Okay, that's the interface that we want to change. Right now it's currently set, it says, to MTU size of 1500. So let's change that to something like 9000. Then I put the interface name. Put in the password, ifconfig again, and now the MTU size is 9000. So if I run UHD underscore USRP probe again, you'll see that all the warnings are gone. All right now our game blocks in there now we can give it a try within the GRC within GNU radio and that's the next step in the getting started guide testing out the custom block. Okay we can open up the new radio from this terminal since it has all the environment variable set. It's always good to start with a GNU Radio Flow graph that has most of what we need. In this case, the example we used at the beginning of the tutorial, the RfnocNOC DDC block. Let's do a save as and save it as something we want and let's put it in our examples folder in our new OOT module. Okay we can remove those two blocks, change the name in the options block. Let's add another variable up here for our digital gain so we can just copy and paste this one and then change the parameters within. Okay once again thinking of a name what can we name it? That'll work. Let's just start it off. At 1, start, 30, even though it goes way higher, it's a 16-bit number, 30 is fine for example, besides multiplying it, you know. Anyway, that's a fine number there. We'll hit okay. We need to delete this connection. Remember, we already have a DDC block in there. We left it in there so we can leave that block in there. It's actually going to become important in a second because that's the block that actually does the down sampling for us. We actually did want to continue to have that block in there. Okay, but what we are missing is our gain block, so let's see where that might be. Okay, under here, under tutorial, which is our adderty module, there it is, the rfnought gain block. Let's connect it up. Okay, and put our variable in here. What was it? Rx. Okay, so we have our variable. That's right, rxdigital underscore gain. Okay, so here's the note. We talked about it earlier, but about the sampling rates. On the RfnocNOC radio block, this sample rate is actually meant to change the clock speed of the USRP digitizers. And on the X310, the default is 200 mega samples per second, and it can't be changed during runtime. So that's what that is. More information on supported clock rates can actually be found in the UHD manual. The DDC block is an FPGA block that... performs the down sampling and decimation operation that can be changed on the fly just like what you are used to using with the UHD source block this this is why this picture may seem a little confusing inside of the getting started guide because there was an error here so it doesn't actually do any conversion inside of the Rfnoc knock radio block it is coerced to 200 mega samples per second so we'll we'll make sure to get it right inside of this tutorial this video tutorial so by leaving the master clock rate set there inside of the radio block and inside of the DDC we're tracking well on exactly what's going on and what's supposed to happen because once again even if you change that radio the Rfnoc knock radio sampling rate to something else it's still going to be coerced to 200 mega samples per second. Let's move things around a little bit, try to run it, and we see that we got an error. Okay, it says that the error is unexpected indent. Oh, yeah. Remember what we talked about, that that XML file actually contained some Python, so I must have put some bad spacing in there. So let me take a quick look and see if I can see it. If not, we'll go back to the Getting Started Guide and see if I missed something. Okay, not seeing it, so let me go back to the getting started guide. Oh yes, there's a problem here. I can tell that those two aren't lined up. So self is actually lined up with that block tag. Okay, I see. So if I move this over, that looks good now. Okay, so I come back over here. Need to go back to the make install. Up to date, except if I go up, it does show that I installed that XML file again. Essentially, I wrote over it is what I did. So now let's try our flow graph. Oh well let's refresh it first and then run it. Refresh it because I did make that change. Okay good so now it's running no errors except I'm not seeing any output. Maybe it's just the frequency I'm at. So let's change that back to what I did before, which is a local radio station. Still nothing. Okay, well, actually, if you just toggle this digital gain, because the default is set to zero, you don't see anything. So once we set it back, go to zero, and then go to one, we can actually see that it is actually working, but the default was actually set to zero, and that's why. So once we toggled it, meaning we wrote to it a run, then we can see what we're expecting. You can see that if I change the gain, there I'm clipping. a little bit but you can see that it's actually doing it if we reduce the analog gain we can go even higher on the digital game not that you want to do that just that you can okay let's compare it to what we see in the getting started guide Okay, it is a little bit different, and the reason it's different, one, obviously the radio station might not be the same. Actually, I think it is the radio station, but it's different because I have the number of samples. Sample rate's different, so we can change that really quick. Looks like the sample rate in the example is only 1 MHz. And let's just change the frequency here so I don't have to bother with it again while it's running. Once again, it's set to zero, so if we toggle it, then it goes to what we expect. It starts working as we expect. Oh yeah, now that's looking a lot like what we would expect or what's inside the Getting Started Guide. You can reduce the analog gain and you can continue to fidget with the different knobs. There's a troubleshooting section here, so if for some reason you weren't able to To get it running there's a couple of tips in here. Also, the files, all the files used that we modified are also straight right here, so you can just copy them from this zip folder here as a zip file and copy and run them into the directories that it showed. And down here at the bottom we have links and additional resources, the GNU Radio resources, some more information on RfnocNOC, and some other things for you as well.

Transcript for:RfnocNOC Getting Started Tutorial

Transcript for:
RfnocNOC Getting Started Tutorial