Hi Erik,
As I mentioned above, I'm currently working on a re-design (for readability, better performance, and new features) of the NIOS II support, which is ongoing in the branch I mentioned. When we've finished and tested this to a significant degree, I'll plan to add some actual documentation on what the implementation is doing, and how to launch a debug session.
Note that the NIOS II is essentially a tiny "microcontroller" -- you won't be doing any signal processing in it. Think of it as more of a means to control and interact with the blocks (e.g., signal processing modules) you place in the programmable fabric, or the devices attached to the FPGA. In the hosted design, it's simply taking requests to configure/control FPGA modules or devices (i.e., the Si5338 and LMS6002D).
As I mentioned above, I'm focusing on finishing up these changes, but will then work on some of the documentation you noted to be lacking. This will probably be another two weeks, but hopefully you'll find it vastly more helpful.
For now, here's quick summary to get you started, assuming $BLADERF is the top-level of the repository. Hopefully this gets you on the right path. When I finish the aforementioned re-design, I can be of more help, and will have steps like these better documented.
Before starting: Ensure you've pulled the latest bladeRF master. While working on the NIOS II, I found
this change was needed by Eclipse to set up the debug target properly.
(1) Enter the "NIOS II command shell", which is just bash with a bunch of environment variables set. I installed Quartus 13.1 in ~/software/quartus, hence this being how I launch it: ~/software/quartus/13.1/nios2eds/nios2_command_shell.sh.
(1a) If you do not use the NIOS II command shell, you'll need the following environment variables in your shell, which will depend on where you've installed Quartus:
Code: Select all
# Quartus 13.1
export QUARTUS_13_1_DIR=~/software/quartus/13.1
export QUARTUS_ROOTDIR=$QUARTUS_13_1_DIR/quartus
export SOPC_KIT_NIOS2=$QUARTUS_13_1_DIR/nios2eds
export PATH=$PATH:$QUARTUS_ROOTDIR/sopc_builder/bin
export PATH=$PATH:$QUARTUS_ROOTDIR/bin
export PATH=$PATH:$QUARTUS_13_1_DIR/modelsim_ase/linuxaloem
export PATH=$PATH:$SOPC_KIT_NIOS2/bin
export PATH=$PATH:$SOPC_KIT_NIOS2/sdk2/bin
export PATH=$PATH:$QUARTUS_13_1_DIR/nios2eds/bin/gnu/H-i686-pc-linux-gnu/bin
(2) First, we need to do an initial build of the FPGA as-is, because this will generate the NIOS II BSP for us. In this case, the build is for an x40:
(2a) cd $BLADERF/hdl/quartus
(2b) ./build_bladerf.sh -s 40 -r hosted
(3) With the FPGA built, we should now have what we need for the NIOS II BSP. cd $BLADERF/hdl/fpga/ip/altera/nios_system/. Note that this is where all our NIOS II files live, included those autogenerated.
(4) cd software/ -- This is where the (soon to be more appropriately renamed) lms_spi_controller project lives, and the BSP.
(5) Launch the Eclipse that comes with the altera tools: ~/software/quartus/13.1/nios2eds/bin/eclipse-nios2
(5a) To get this to run on Ubuntu 15.04, I had to install the 32-bit JRE and a bunch of 32-bit libs.
(5b) Create a workspace wherever you see fit
(7) Import the lms_spi_controller and lms_spi_controller_bsp projects:
(7a) From the project explorer, right click and select Import...
(7b) "Existing projects into Workspace"
(7c) Select Root Directory
(7d) Select that "software/" directory from step 4. You should see both projects checked in in the "Projects" pane. Click Finish.
(8) You should now have both projects in Eclipse. Clean and build should work. Note that the eclipse editor won't know how to resolve macros and functions unless you configure this in the project settings to inform it of paths to search for source files and headers (i.e., the BSP and the gcc toolchain shipped with the Altera package).
(9) Load the FPGA via the bladeRF-cli. This ensures everything gets configured before we attach to the NIOS II target. We can reset and reload the NIOS after this.
(10) Connect the JTAG debugger. This assumes you're using an Altera or Terasic Blaster, and have already set up your udev rules to have access to it.
(11) Create a debug target.
(11a) Debug Configurations..
(11b) Create a new "NIOS II Hardware v2 (beta)" target
(11d) Project: lms_spi_controller
(11e) ELF file: lms_spi_controller.elf
(11f) Under Connections -> Processor, click Browse... It should detect the NIOS II via the USB-Blaster
(11g) Under Connections->JTAG UART, click Browse... Again, it should detect the NIOS II via the USB-Blaster
(11h) Uncheck "Check Unique ID" and "Check timestamp"
(11i) Here you can make a choice. Generally, I duplicate the debug configuration, and do one for attaching and one for loading and resetting:
(11i-1) If you only want to attach to the target, uncheck "Download ELF", "Reset Processor" and "Start Processor".
(11i-2) If you want to download your changes to the NIOS II code and restart it, leave all of these checked.
(12) Here's what my setup looks like at this point:
Debug_config.png
(13) From here, I'm able to launch the debug target and step through code:
debug.png
Don't be alarmed by Eclipse claiming every macro and type it can't resolve to be a "bug". If this bothers you, you can set up the source and header search paths for the project. (Since the project uses a Makefile, Eclipse doesn't know where to look -- it just launches make.)
(14) Now if you start setting break points, the host code will time out. You can disable timeouts the USB requests that go to the nios by changing
this line from 250 to 0.
Again, check back in a couple weeks, or take a peek my dev-nios_refactor branch... I think you'll find the overhaul to make a lot more sense and help you pull what you need from the lms.c and si5338.c files.
Best regards,
Jon