Mario875

Right, so interestingly enough just after posting I found this thread... It points to an ELF bootloader on Github (https://github.com/henrikbrixandersen/elf-bootloader), I downloaded that and added it to my project (removing the SREC SPI loader) and it just works!! I had a slight issue with Vitis where it simply would not let me flash a raw .elf file, it says its a valid file to use when flashing, but then it kept complaining about a missing .bin file, so as the ELF bootloader wants a raw elf file with the '.ELF' header in the hex code I simply took the application.elf file and renamed it to application.bin, then Vitis programmed the SPI flash with that file in the location requested and now it works! It is also a bit smaller than the SREC loader (10kB with heap & stack vs 17-18kB with heap & stack). If I can get rid of the heapt & stack and have it still work I may even be able to reduce the BRAM on my MicroBlaze down to 8kB. Something isnt right with either the SREC SPI Bootloader or in the way Vitis is converting the .elf into SREC it seems. I have noticed the SREC file is only ~634kB where as my ELF file is 1,134kB! Could it be something to do with that?? HOWEVER...it does still take 25-30 seconds from power on to configuration completing (config itself is very quick, its about 23-24 seconds before the bootloader even starts doing its job), is there any way to speed that up? Also, when I reset the MicroBlaze using a push button the bootloader does not re-start and re-program the DDR memory with my application, so I need to reprogram the entire FPGA using the 'PROG' button the the Nexys Video. Any ideas on why the bootloader doesn't reset when I reset the MicroBlaze? I have noticed the reset works fine with my application on its own or with the SREC SPI Bootloader, just not with this ELF Bootloader I found??

Hi all, I am trying to get my project to boot directly from flash memory, but as requires a lot of BRAM, I am trying to use a bootloader to load up the application and run directly from the DDR memory I have. If I dont use a bootloader and run my application directly from MicroSD it works fine, but then needs a lot of BRAM and as I want to move this to a smaller FPGA later on a custom board I need to reduce the BRAM utulisation and to do that I need to run from DDR and use a bootloader. So far I have done the following... 1. Created HW design in vivado with QSPI IP on a 50MHz clock at ext_spi_clk and generated bitstream 2. Created my SW application in vitis and assigned all to DDR 3. Created a new application in vitis for the bootloader and assigned all to BRAM 4. Configured the blconfig.h to look for my application at 0xA00000 (10MB into the 32MB of QSPI) 5. Built all and generated a bootloader.elf as well as my application.elf 6. Generated a download.bit file using my project.bit, project.mmi and bootloader.elf (download.bit size is 9.5MB) 7. Programmed the download.bit file to QSPI via "Xilinx -> Program Flash" at offset 0x0 (no offset) 8. Programmed the application.elf at 0xA00000 as per the definition in step 4 When I do the above I get the info below in the Vitis Serial Terminal: [quote]SREC SPI Bootloader FlashID=0x1 0x2 0x19 Loading SREC image from flash @ address: 00A00000[/quote] Then nothing happens! I assume the bootloader is seeing the flash as it shows a flashID not equal to 0! I have read back the .bin file from the QSPI device and can see there is data that begins at 0x00A00000 (see image attached), so not sure what is going on, any ideas? Also attached a snippet of how I have the QSPI IP configured. This is on a Digilent Nexys Video dev board with Artix-7 XC7A200T FPGA.

So, I decided to side-step a little...my HW is VERY similar to what is on page 69 of the product guide (link below), as such I thought it would maybe be best to use the example code described in there from page 71 onwards. Only difference is I have an AXI traffic gen connected to the TPG to output a fixed pattern at fixed resolution, so I commented out the code for all the TPG stuff in the example and went to build it but not I keep getting the error "unknown type name Xperiph" and I am not sure why when that's part of the example code that relates to things like the VTC which I do have and I also have connected in the same way as them. The Vitis side of Xilinx stuff is really not my strong suite, embedded C and all that, especially their implementation of it. https://www.xilinx.com/content/dam/xilinx/support/documents/ip_documentation/v_proc_ss/v2_3/pg231-v-proc-ss.pdf

Quick follow up...someone on the Xilinx forum pointed me towards the Video Series Blog... https://support.xilinx.com/s/question/0D52E00006hpsS0SAI/xilinx-video-series-and-blog-posts It looks like "Video Series 29" is closest to what I need. I have downloaded the files but when I try to build the SW project I kept getting errors about missing headers. I added the "Includes" to the header file sources in the Xilinx Vitis directory, but now when I try and build I keep getting errors like the ones below and I don't know what to do to fix it, any suggestions? ../src/app_hdmi.c:111:15: error: 'XPAR_AXI_VDMA_0_BASEADDR' undeclared (first use in this function); did you mean 'XPAR_AXIVDMA_0_BASEADDR'? ../src/app_hdmi.c:260:26: error: 'XPAR_CLK_WIZ_0_BASEADDR' undeclared (first use in this function); did you mean 'XPAR_GPIO_0_BASEADDR'? ../src/app_hdmi.c:451:51: error: 'XPAR_V_TPG_0_DEVICE_ID' undeclared (first use in this function); did you mean 'XPAR_XV_CSC_0_DEVICE_ID'? ../src/app_hdmi.c:459:46: error: 'XPAR_V_TC_0_DEVICE_ID' undeclared (first use in this function); did you mean 'XPAR_XV_CSC_0_DEVICE_ID'? I just want to get this build working so I can use it as a template to modify and suit my own needs. Any help greatly appreciated!

Hi all, I am looking for a Microblaze (or at least some kind of Vitis) example project for the Xilinx Video Processing Sub-System. Really what I am looking for is something like this video with the sample code... https://www.youtube.com/watch?v=tBb1iL6lb24 If you skip to 8:20 in the video you will see that there is a menu which allows you to simply set the output resolution / scaling, that is all I am needing for now. I have a test pattern generator running as part of the block design and I have implemented the IP cores for VPSS, MicroBlaze, MIG_7 memory controller, etc. Now I just need an example MicroBlaze code to do the above. Any suggestions?

if you have the first 24 bytes, that means out of your 256 bits you still have 64-bits unknown. The RC5 distributed computing network took almost 5 years to brute force a 64-bit encryption according to this article... https://blog.codinghorror.com/brute-force-key-attacks-are-for-dummies/ A single FPGA or even a small cluster would likely take much longer.

Perfect, thanks! ?

In terms of going for the SoC board, that depends if you will have a use for a dedicated ARM hard core processor. Will you have applications that will make use of it or are you solely focused on FPGA development? If you only care about FPGA development and want to go between the Basys 3 or Nexus A7 along side that book I recommended, honestly, as the saying goes "buy cheap, buy twice". The Basys 3 is a fantastic board, but the Nexus A7 can do everything the Basys 3 can do and more. The Nexus A7 has RAM and an Ethernet Port that the Basys 3 does not and that is where the book calls up the use of the Arty A7. However the Nexus A7 also has the 7-segment displays that the Basys 3 has that the Arty A7 does not. So if you decide to get that book and read it cover to cover, then the Nexus A7 should be a "1-stop shop" board that you can use throughout the entire thing. However it is worth noting that the Arty A7 board is only really required for later chapter, the Basys 3 can do everything needed for most of it. When following the book you just have to be aware that if you are using the Nexus A7 the constraint files and setting up of the board in Vivado will be different, but as long as you are somewhat familiar / savvy with these already from your previous experience of FPGA's that should not be an issue.

This book is a great start. It begins with what logic gates are and builds upon that. From a basic LED being turned on and off with a switch all the way to implementing a soft core CPU on an FPGA and beyond. The book is to be used along side the Basys 3 or Arty A7 dev boards, but honestly, I would opt for the Basys 3 for this book as most of the early chapters are geared towards that board more so than the Arty A7. Everything taught in here is transferable to all other FPGA's. The book covers both Verilog and VHDL simultaneously, but I would only chose to learn 1 language first and skip everything related to the 2nd language for now, you can always go back and learn it later. It is however slightly geared more towards Verilog than VHDL, but all examples and exercises are shown in both languages. https://www.amazon.co.uk/Digital-System-Design-FPGA-Implementation/dp/1259837904

Hi All, Question is pretty much in the title, can someone confirm, is it possible to use the Digital Discovery signal generator function at the same time as using the logic analyser function? I am wanting to inject a signal into a device (any 1.8V signal will suffice for my testing at the moment) and then monitor the data that gets output at the other end. If the Digital Discovery can perform these functions simultaneously then it would be ideal. Thanks

I would recommend you look at the respective reference sites below. Essentially the differences are the size of the FPGA on the boards (XC7A35T on the Arty vs XC7A100T on the Nexys) and the differences in IO on the boards….Nexys has VGA, Arty does not, Nexys has 16 switches, Arty has 4, Nexys has 8-digit 7-segment displays, Arty does not have 7-segment displays, Arty has been designed with headers that allow for Arduino shields to directly plug in, Nexys does not. Which one to buy depends on what you want to do with it. The Nexys has more features, but it also costs more. There are no additional software costs, you can download Vivado ML 2021.1 Standard Edition for free and use it with either board you mention. https://reference.digilentinc.com/programmable-logic/arty-a7/start https://reference.digilentinc.com/programmable-logic/nexys-a7/start

Glad it's now sorted, looks like I was correct in my last post where I said... It is an issue if it's not on the board all together ?

Have you tried programming directly using the JTAG interface on jumper J17? If you have that option it would be my next port of call to rule out the USB - JTAG interface. Looks like xsct can see the board, but with errors on the JTAG boundary scan. Take a look at some of these threads.... https://forums.xilinx.com/t5/Embedded-Development-Tools/Problem-of-Boundary-Scan-Chain-of-Devices/td-p/168196 https://forums.xilinx.com/t5/Embedded-Development-Tools/JTAG-chain-error-in-SDK-9-Whole-scan-chain-DR-shift-through-all/td-p/819407 https://forums.xilinx.com/t5/ACAP-and-SoC-Boot-and/JTAG-chain-error-in-XSCT-1-Whole-scan-chain-DR-shift-output-all/td-p/1038266 Looks like you need to verify the JTAG TMS, TCK, TDI & TDO lines are all in the the correct states and being pulled up properly with the proper voltages, etc. The issue could also be the NC7SZ66P5X which is a bus switch that the TDI & TDO lines go do, presumably to allow interface either via the FMC connector or via normal JTAG header. However, just incase it is something this simple, you have double checked all the jumpers on the board are in the correct position, yes? Not set for say direct JTAG interface programming when you are trying to program over the USB or anything? If the jumpers are all correct then it's time to sit down with the board, schematic and an oscilloscope / test gear to find the fault (which could still be under the FPGA on the BGA connections). Schematic can be found here... https://reference.digilentinc.com/_media/reference/programmable-logic/nexys-video/nexys_video_sch.pdf

Hopefully that will fix the issue. If it does, please let us know.

The FTDI firmware should not be a problem, because it is the exact same FPGA, just a higher speed grade. All the pins for the JTAG will be the same as the original FPGA. Is it possible that the company you sent it to tried to update the FTDI firmware? I have read that the FTDI software can erase the Digilent firmware without warning when you open their software with the Digilent board connected. Maybe this happened? There is an dedicated thread about restoring FTDI firmware here... Maybe @JColvin can detail the method required to restore the FTDI firmware for the Nexys video. That is what I would do first. Restore the firmware back to factory and then see what happens.