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.

When you say you replaced the FPGA, do you mean you actually de-soldered the original one and soldered a new one? If so there are a couple of things to query, such as how was this done (as in what tools / method were used)? Are you sure there have been no pads lifted when the old FPGA was lifted? Are you sure the new FPGA is soldered properly with no bridges, making good contact to the pads on the board, etc? Also, I suppose the bigger question is...where did you manage to source the new FPGA? Was it from a reputable retailer or someone on Ali-Express? As I have just done a quick check and this particular FPGA is one of the many which currently has a lead time into 2022 from places like Farnell, DigiKey & Mouser. So if you sourced it from Ali-Express it could be one which has issues and failed QC, hence was never sent onto reputable distribution centres. Honestly, if you have installed a new BGA to the board, you are effectively on your own with this one. Obviously there are users here willing to help, but I would not expect Digikey reps to be much help as you will have well and truly voided any warranties and introduced a change which has not been tested by them and not to mention the very high possibility the issues you are encountering are self-induced in the sense that it could very well be an issue with the removal & installation of the BGA packages.

Not much you can do other than edit the constraints file as Vivado is basically saying the pin you’ve selected that the LED is connected to is in a bad place for routing of the clock and could be optimised by using a more suitably placed pin on the FPGA. Unfortunately as it’s a dev board the LEDs and what not are connected to the pins chosen by digilent and you can’t change that, just add the line of text to your constraints file or chose a different LED that may be connected to somewhere Vivado prefers. Also, the solution was given to you by Vivado, there was no need to search the forum to find it ?

In the schematic, for example PMOD connector that is labelled “JA1” on the schematic linked goes to Bank 15, pin G13 on the FPGA. https://reference.digilentinc.com/_media/reference/programmable-logic/arty-a7/arty_a7_sch.pdf

Just had a look at those Trenz Electronik SOM's and I REALLY like the idea of them! Buy a single expansion (carrier) board then simply plug in the FPGA SOM you want to develop on. Or of course you can make your own carrier board if you wanted. I have had a look at the carrier board schematic and it is using an ADV7511 (36-bit device) for converting to HDMI. However there are a few issues with it that do not address the issues on the Nexys Video such as.... GTP ports of the FPGA SOM on are routed to header pins on the carrier which are used for the CameraLink connector, the HDMI comms are on the same header, but the pins that are used for the HDMI port are just generic IO like the Nexys Video. They are using an ADV7511 which made me think about buying their carrier and one of their SOMs as it would save me having to make my own daughter board to connect to the FMC connector, however despite the ADV7511 supporting 36-bit input, only 12-lines are connected to the FPGA, the remaining 24 are tied to ground. As I will be taking in 24-bit RGB it would be easier for me to just output 24-bit RBG to the ADV7513 (a 24-bit variant of the ADV7511) and not have to deal with processing data within the FPGA to try and convert a 24-bit input down to 12-bits which will likely result in a loss of video quality also. So for me to make use of their SOM in development stages at least, I would need to make up my own custom carrier board to suit my needs which is not out of the realms of possibility, but that in itself is not exactly a small task as I have to consider all the power rails, impedance, manufacturing of the board, how to program and interface to the FPGA via Vivado, etc, etc. A lot less hassle to just make a breakout board for the Nexys Video and if I decide to make a custom PCB at the end it will be specific for my project and not a dev board to make the project itself, if you know what I mean. However I do really like their concept of just plug in and go, full flexibility to use the FPGA as you desire with custom carrier boards. If the HDMI port had gone directly to the GTP on the FPGA or even made use of 24 or more inputs on the ADV7511 I would have probably opted to go for that, but as it stands, its the same price as the Nexys video (SOM & carrier) and if anything has less features, such as no display port, no OLED screen, less PMODs, etc.

Thanks for all the info, seems that if I want proper timings at 1080p, 60Hz, 24-bit colour I am best just using the ADV7513 (or similar). Considering the IC's are only £14 from RS Components and they are purpose built for the job, it seems going that route is first of all, less headache and second of all, likely to yield superior results. Not to mention the cost saving vs a Genesys 2! Just need to make up a custom PCB so it can interface to the FPGA via the FMC connector, not a big deal. As for the Geneys 2, I cannot justify an extra £600 over the Nexys Video, it's just not worth it, even future projects I have involving FPGA's are likely to require lesser devices than the Nexys Video, probably stuff I can do with my current Basys 3. Maybe in future I can re-visit the Genesys, but not just now. However I might re-visit this topic after I get everything fully functional with my project and have completed boards made up and the project is all but finished. Just to see how well I can make it run without the ADV7513 for my own curiosity. Seems that the Nexys Video should be able to do 720p & 1080i at 60Hz with 24-bit colour without too much hassle, even 1080p 30Hz with 24-bit colour depth should be fine, but getting it up to 1080p, 60Hz & 24-bit colour I think will have her running a bit hot. Thanks for all the info so far, especially that IP core! Really good to have that, but I think the answer as to "how did Digilent do it on their demo" (for anyone who finds this thread in the future) is that if they are indeed outputting 24-bit colour, then the only solution has to be running the FPGA out of spec and effectively over-clock it.

I do think you are correct there and I have possibly assumed a 24-bit colour depth as it's generally fairly standard these days, but as they say "to assume is to make an ass out of you and me". Ideally a free to use video IP would be preferred as it would make things go a lot smoother, this is also a bit of a passion project, so budget is reasonably constrained compared to a professional project. I agree, as I've started digging into video and HDMI it seems to be a bigger and bigger rabbit hole! However that was partly what drew me into the Nexys Video. It has HDMI examples and projects already available and working on it which would help in implementing my own design. I agree that I need to do some rough estimates of the timing capabilities of an FPGA, that is exactly why I am here asking, as the Nexys Video demo can do 1080p @ 60Hz (albeit, without confirming the colour depth it's using) and it just seemed odd that it is doing that without using the GTP transceivers which is why I decided to ask, but maybe I need to dig a bit deeper into the FPGA datasheet. Getting hold of some example code I can synthesis and simulate in Vivado sounds like a good idea though! Will definitely look into that. Yes the Nexys Video LPC FMC connector is something I have looked at, and it seems it should work for me if I decide to go down the route of making a custom add-on board with ADV7513, hopefully will help with getting my project off the ground, but I would ideally prefer to get it working without the need for the ADV7513. Or even as I suggested before, get the project up and running with the ADV7513 and then work on implementing the HDMI transmitter capability into the FPGA so I can eliminate the need for the ADV7513. Oh, I just had a look at the vivado-library and it looks perfect! Thank you very much for pointing me in that direction. The rgb2dvi IP core PDF user guide says it supports a 24-bit RGB input and then outputting the video at up to 1080p @ 60 Hz (148.5 MHz) and is developed for the 7-series Xilinx FPGA's which is ideal. However, have you personally tested it at 1080p, 60fps 24-bit colour depth? The pixel clock frequency of 148.5 MHz means the serial frequency would need to be about 750 MHz which the datasheet says the Artix-7 FPGA (at any speed grade) does not support (officially). According to the IP core PDF (https://github.com/Digilent/vivado-library/blob/master/ip/rgb2dvi/docs/rgb2dvi.pdf) it says that the IP supports 1080 resolution at 60Hz (148.5 MHz, which is the frequency required for 1080p) and supports 24-bit RGB input which is exactly what I need. As for the clocking frequency of the Artix 7, this is where it seems to come a bit unstuck! For the -1 speed grade FMAX_BUFIO is 600 MHz, the pixel clock will be 1/5 of that which is only 120 MHz, not the required 148.5 MHz! However even the fastest Artix-7 speed grade is only 680 MHz, not the required 750 MHz. I have seen other posts on here and EEVBlog where @hamsterover clocked the FPGA to make it work, but it's not ideal. Problem is the next step up from the Artix series is in Kintex and the cost is too prohibitive for me for this project as it costs about £1050 for a Genesys 2 vs the £450 for the Nexys Video. Might be stuck with 1080i, or overclocking if I want to make use of the Artix and maintain HDMI specs. Either that or I just output RGB 24-bit video from the FPGA and let an ADV7513 deal with all the HDMI stuff as the input video feed is RGB 24-bit at 54 MHz. So the required bandwidth would be about 1.3 Gbps total which is well within the Artix-7 specs. That way the FPGA can just do upscaling & de-interlacing of the original feed then output RGB to the ADV7513. Xilinx already provide a free IP core for upscaling / deinterlacing on the 7-series FPGA's. EDIT: Interestingly enough, the Digilent IP core says it is for the Zynq-7000 and 7-series Xilinx FPGA's, but their FMAX_BUFIO is both the same. So the IP core can work with up to 1080p @ 60Hz, but neither FPGA it is developed for can support the frequencies required to achieve that (not officially at least)! ?

Thanks for responding, however that doesn't really answer my question. Please see below responses to your answer. I am aware HDMI uses TMDS, I suppose that is my query, how does the Nexys video implement it to achieve 1080p@60fps with 24-bit colour on their built-in demo? Genysys 2 look great, but is about double the cost and if I am not mistaken the Kintex requires a Vivado licence which I believe is included for 1 year with the Genysis 2, but then requires to be paid for, so not really an option for me due to the cost. I have just had a look at that, seems like a nice little board (website says it uses the A50T though), but I think the Nexys video still offers me more flexibility due to having the A200T, as they both have 160-pin breakout headers, of which about half (think just over half on the Nexys Video to be honest) can be used for GPIO. The Numato board also has it's GTP transceivers all used up with the mini display port connection, the Nexys Video at least has 1 GTP transceiver on the FMC connector should I ever need it. For my project I have considered (at least to begin with) I could implement it using a HDMI transmitter like the ADV7513 via a breakout board through the FMC connector on the Nexys Video, then come back later and try to eliminate the ADV7513 and implement it directly on the FPGA (hence these questions). I understand that, the only reason I mentioned LVDS is just because that is what the Xilinx datasheet refers to when discussing performance characteristics. According the the datasheet, the -1 speed grade (as is used on the Nexys video I believe) has a max transmitter / receiver speed of just 950 Mbps. So 950 Mbps x 3 TMDS pairs gives a max bandwidth of 2.85 Gbps. The HDMI standard states 1080p, 60fps, 24-bit colour requires 4.46 Gbps. Even if we have zero blanking area and do some quick math we get 1080 * 1920 * 60 * 24 = 2.985 Gbps This is without any blanking area in the transmission and with just taking the 8-bit per colour. TMDS uses 10 bits per colour as 2-bits are used for control signals during the blanking period, so realistically, even with no blanking period we would be looking at 1080 * 1920 * 60 * 30 (10-bits per colour) = 3.73 Gbps Neither of these figures should be achievable (without over clocking) on the Nexys Video Artix-7 with the -1 speed grade FPGA. So kind of going back to my original question. How have Digilent achieved this? As a side note, my project is going to be taking in 24-bit RGB from an external device and outputting over HDMI. As I have mentioned above, I have looked at just using an ADV7513 to transmit the HDMI and get round this. However, seemingly Digilent have found a way to make it work, and I am trying to understand how have they done it? As it may mean I can avoid using the ADV7513, at least in future revisions of my design, even if not initially.

Hi all, I am considering purchasing a Nexys Video dev board soon, but I have noticed the HDMI port is not connected to the GTP ports on the FPGA, just the standard IO ports. So I am wondering, can this board do 1080p 60fps with 24-bit RGB colour? According to this screen shot from the HDMI demo on the digilent website it appears that it can but I’m not sure how?? I believe the HDMI standards states 1080p 60fps with 24-bit colour (8- bits per colour) requires 4.46 Gbps. The Artix-7 standard IO is only 950 Mbps for LVDS at 2.5v, so I presume the 3.3v TMDS will be a bit faster, but not fast enough for 1080p60, as over 3 differential pairs (TMDS 0-2) would be a total theoretical limit of 2.85 Gbps. So how can the Nexys video do 1080p at 60fps with 24-bit RGB colour over HDMI? As I’m not really seeing a clear cut answer as to how the demo seemingly accomplishes this. It looks like it should not be possible, but the digilent demo says otherwise. Anyone care to explain how this is accomplished? I can see the FPGA connects to a TI “HDMI Hider” (as it’s called by TI), but that seems to do little more than improve the signal integrity before being passed on. Or am I missing something?