EEVblog Electronics Community Forum
Electronics => FPGA => Topic started by: Mario87 on June 08, 2023, 05:42:50 pm
-
Hi all, I have a project that I have been working on for a while that uses a MicroBlaze CPU with address range 0x00000000 to 0x0003FFFF (256KB) and RAM with address range 0x80000000 to 0x9FFFFFFF (512MB).
With the project I can create the download.bit file in Vitis from the Vivado generated .bit file and the .mmi file if I have the processor to only initilise on bootloop at startup and not an actual ELF file. Then I can kick off the code manually from within Vitis.
I now want to include the ELF file within download.bit so that I can run from a MicroSD and as soon as it loads the MicroBlaze program kicks off, but when I try to do that I get the error below...
\Vitis\xv_procss_example_2\Debug\xv_procss_example_2.elf is mapped to address range [80000000:80034BEB], but there is no memory available in that range. Make sure that the data file base address is set to an address corresponding to the memory address range in the design.
The address range is for the DDR memory, where as it should be for the MicroBlaze Local RAM (0x00000000 to 0x0003FFFF)....how can I update the 'data file' (as it says) to set the correct base address to 0x00000000 instead of 0x80000000?
Thanks!
-
Find a linker script in the project tree (typically in "src" folder, called lscript.ld), double-click it, and you will see all sections and which address space they go to. Each line there is a combo-box where you can select any address space which is declared in your BSP as a type of "memory". See attached screenshot for details.
Also remember that once you compile your binary, you will need to "integrate" it into the bitstream. And you will have to do it every time you make any code changes - unless you run the code directly through Vitis - in which case Vitis will take care of it for you.
-
Find a linker script in the project tree (typically in "src" folder, called lscript.ld), double-click it, and you will see all sections and which address space they go to. Each line there is a combo-box where you can select any address space which is declared in your BSP as a type of "memory"). See attached screenshot for details.
Also remember that once you compile your binary, you will need to "integrate" it into the bitstream. And you will have to do it every time you make any code changes - unless you run the code directly through Vitis - in which case Vitis will take care of it for you.
Awesome, that has sorted it thanks! :-+
-
Awesome, that has sorted it thanks! :-+
You are most welcome!
Just a word of caution - debugging firmware running from BRAM is very tricky as debug builds are typically much larger than release ones, and BRAM space is typically very limited, so if your board has some kind of external memory, it's best to use it during debugging even if you don't intend to use it for the final build - it will make your life a lot easier.
The way I design most of my firmware is that I include a small bootloader into the BRAM which loads the main application from spare space in the QSPI flash into DDR and then launches it. Xilinx includes a template for such bootloader with Vitis, but it's not very hard to develop one by yourself. There is also an option to set QSPI flash as XIP and run it directly, but you will need to remember than XIP address space is read-only and so you will need to remap all non-readonly sections into some other address space. I personally never tried that, but it sounds like an interesting way to save some memory if you are short of it. The advantage of both those approaches is that there is virtually no limit for the firmware size (within reason of course, as long as it fits within spare space of QSPI flash, but that's usually are few MBytes), and you don't actually need to burn into the flash debug versions as Vitis can copy them into DDR directly for you.
-
Thanks for the info, I have however noticed that as a minimum, the ones listed as 'MicroBlaze_MCU.....' in the image attached need to be in BRAM otherwise I get the same error above about the base address being wrong.
I cannot put all of them in the 256K of BRAM in my design otherwise it says there is not enough space (approx 95K short) and if I increase to 512K of BRAM in Vivado it totally messes up the timing.
Is it possible to force them all to run off of DDR and not throw up that error relating to the base address being wrong? Or as a minimum to I have to keep the 256K of BRAM in my design and run these from the MicroBlaze with base address 0x00000000?
Just that I am developing on an Artix 7 Series XC7A200T FPGA at the moment on a dev board and it looks like if I can limit the BRAM usage then I could probably fit this onto an XC7A50T in the final design, but the BRAM availability on the XC7A50T is just 75x 36Kb blocks vs the 365x 36Kb blocks available on the XC7A200T (of which I am using ~235, but also with ILAs and other devices which I will remove in the final design).
-
Thanks for the info, I have however noticed that as a minimum, the ones listed as 'MicroBlaze_MCU.....' in the image attached need to be in BRAM otherwise I get the same error above about the base address being wrong.
I cannot put all of them in the 256K of BRAM in my design otherwise it says there is not enough space (approx 95K short) and if I increase to 512K of BRAM in Vivado it totally messes up the timing.
Is it possible to force them all to run off of DDR and not throw up that error relating to the base address being wrong? Or as a minimum to I have to keep the 256K of BRAM in my design and run these from the MicroBlaze with base address 0x00000000?
Just that I am developing on an Artix 7 Series XC7A200T FPGA at the moment on a dev board and it looks like if I can limit the BRAM usage then I could probably fit this onto an XC7A50T in the final design, but the BRAM availability on the XC7A50T is just 75x 36Kb blocks vs the 365x 36Kb blocks available on the XC7A200T (of which I am using ~235, but also with ILAs and other devices which I will remove in the final design).
I don't really understand what are you trying to achieve to be honest. Can you please be more specific as to what are you trying to do?
-
I don't really understand what are you trying to achieve to be honest. Can you please be more specific as to what are you trying to do?
If you look at the image in my last post you can see some are set to ‘MicroBlaze_MCU…’ and the rest are set to ‘mem_block_mig7…’ (DDR RAM).
If I try to set them all to the DDR ram I get the error below…
\Vitis\xv_procss_example_2\Debug\xv_procss_example_2.elf is mapped to address range [00000000:00034BEB], but there is no memory available in that range. Make sure that the data file base address is set to an address corresponding to the memory address range in the design.
That address range in the error is for the MicroBlaze memory. All the ones set to MicroBlaze in the image must be like that in order to avoid that error, if I change even 1 of them the error above appears. How can I fix that & what would cause this?
I would like to set them all to the DDR RAM but I can’t without getting the error above.
Sorry if my last post wasn’t clear.
-
If I try to set them all to the DDR ram I get the error below…
\Vitis\xv_procss_example_2\Debug\xv_procss_example_2.elf is mapped to address range [00000000:00034BEB], but there is no memory available in that range. Make sure that the data file base address is set to an address corresponding to the memory address range in the design.
What exactly shows this error? Build? Programming? Attempting to lauch a debug session?
Sorry if my last post wasn’t clear.
No worries - English is not my mother tongue, so I might've misunderstood you.
-
If I try to set them all to the DDR ram I get the error below…
\Vitis\xv_procss_example_2\Debug\xv_procss_example_2.elf is mapped to address range [00000000:00034BEB], but there is no memory available in that range. Make sure that the data file base address is set to an address corresponding to the memory address range in the design.
What exactly shows this error? Build? Programming? Attempting to lauch a debug session?
The error appears when I generate a new download.bit file under the programming option.
-
The error appears when I generate a new download.bit file under the programming option.
Why do you need to generate a new bitstream if your entire program is going to be in DDR and thus will not affect bitsteam at all? DDR contents can not be pre-set from the bitstream, you will need to burn your application into the QSPI flash (for production, for debug you can use Vitis IDE to launch it directly), and create a bootloader which would read your application from QSPI flash into DDR memory and then launches it. I remember talking about it before here, take a look here for some steps: https://www.eevblog.com/forum/fpga/xilinx-microblaze-bootloading-from-flash/msg3456970/?topicseen#msg3456970 (https://www.eevblog.com/forum/fpga/xilinx-microblaze-bootloading-from-flash/msg3456970/?topicseen#msg3456970)
-
Thanks, I’ll have a proper look at that link and give it a go when I get time.
What I have been doing so far is a ‘build all’ to generate the ELF file, then going to ‘Program’ and selecting the project.bit, project.mmi and ELF file so that the microblaze boots into its code.
Then I click ‘generate’ and it creates ‘download.bit’ for me. Then I put the ‘download.bit’ file onto a MicroSD and it works fine if I have the linker settings as per my image above, but it will not generate the download.bit and gives an error if I try setting them all to DDR only.
Any idea why that is the case and will the info on your link fix it?
-
What board do you use and how do you program it?
-
Board is a Digilent Nexys video and I program it over USB or by using MicroSD card where I simply need to put the ‘download.bit’ onto the card and it loads everything at power on.
-
Board is a Digilent Nexys video and I program it over USB or by using MicroSD card where I simply need to put the ‘download.bit’ onto the card and it loads everything at power on.
It should work using Vitis over USB (because Vitis will program the board and download a binary by itself when you launch it), but it won't work using MicroSD card if my understanding of how this process works is correct.
-
It doesn’t make a difference, Vitis will not generate the ‘download.bit’ file so there is nothing to program the board with if I set the linker to have everything in DDR.
The issue is not the programming method, first need to figure out why the file is not generated when I set everything to DDR, then the programming will work either way. It already works both ways if I put the settings like my photo.
-
It doesn’t make a difference, Vitis will not generate the ‘download.bit’ file so there is nothing to program the board with if I set the linker to have everything in DDR.
It does not need to generate a bitstream because it can simply use the one created by Vivado. Most of my applications are set to run from DDR (which is Vitis default btw), and I've never had this problem before. I will try it later in my latest Vitis 2023.1 just to be sure, but like I said, there has never been the case that running exclusively off DDR caused any issues.
The issue is not the programming method, first need to figure out why the file is not generated when I set everything to DDR, then the programming will work either way. It already works both ways if I put the settings like my photo.
The issue absolutely is programming method - MicroSD card method can't download your executable straight into DDR memory, but Vitis can (via xdb). You might want to read more about mechanics of these processes so you will understand how they work, and what is the difference.
-
The issue absolutely is programming method - MicroSD card method can't download your executable straight into DDR memory, but Vitis can (via xdb). You might want to read more about mechanics of these processes so you will understand how they work, and what is the difference.
It can’t be programming method related because if I go to the programming window and just click ‘generate’ instead of ‘program’ to create the download.bit file it fails.
You seem to be thinking this is done differently without the need to a ‘download.bit’ file, but that’s how it is done on my setup with 2022.2, the project.bit, project.mmi and ELF are all brought together into a ‘download.bit’ file and then I can put it on MicroSD or use Vitis to transfer over USB.
If it can’t even generate the download.bit file and save it to my pc then it can’t be programming method.
As I said before, I do not get this issue if I don’t load an ELF file into the program window and leave the microblaze set to ‘bootloop’ then do a ‘Run’ or ‘Debug’ command.
I only get this issue when I add the ELF into the programming window so it runs the config as soon as it’s put onto the board.
EDIT: Looks like I’m stuck here, these parts need to fit into BRAM and Vitis is asking for just under 256kB, so I need to set my BRAM to that…
The reason this worked in the debugger by the way, was the debugger will place the elf into your memory (DDR in this case). Updatemem is used for BRAM. So, if you want to place this into BRAM, then place it in this in the LMB (the first one in the list).
You have 32KB of BRAM connected to the LMB. If your application is too big to fit here, then you would need to go back to Vivado an increase the BRAM size in the address editor.
https://support.xilinx.com/s/question/0D52E00006rCaGeSAK/unable-to-generate-the-downloadbit-file-updatemem-error?language=en_US
EDIT 2: Actually there may be a way with the SPI flash, but not sure if I can make it work with MicroSD (ie will it give me a single .bit file??), looks essentially the same as what you linked to above, I will take a proper look later.
https://support.xilinx.com/s/question/0D52E00006hpfo8SAA/associate-elf-not-working?language=en_US
https://support.xilinx.com/s/article/47909?language=en_US
-
You seem to be thinking this is done differently without the need to a ‘download.bit’ file, but that’s how it is done on my setup with 2022.2, the project.bit, project.mmi and ELF are all brought together into a ‘download.bit’ file and then I can put it on MicroSD or use Vitis to transfer over USB.
This is where your misunderstanding is coming from. Take a look at what's inside mmi file. You will see references to all BRAMs. What "update_mem" does is that it pulls sections from elf file and integrates them into BRAMs inside the bitstream. BUT - your executable does NOT have any sections which are supposed to go into BRAM (because you set them to be in DDR)! So what needs to happen in your case is that there needs to be some sort of bootloader which would somehow upload your executable right into DDR. The problem is - it is IMPOSSIBLE to do, unless you do it through JTAG, or if your design will somehow get access to that MicroSD card, and you would add a bootloader (which would be running IN BRAM and thus integrated into bitstream) which would read your executable from MicroSD card, place it into DDR and launch. What I typically do is to use spare space inside QSPI flash to store my application elf file (as very few of my boards have other non-volatile memories onboard), and include an SREC bootloader (provided by Xilinx) which would be running off BRAM and integrated into bitstream. It reads that elf file from QSPI flash upon startup, and jumps to it.
If it can’t even generate the download.bit file and save it to my pc then it can’t be programming method.
That is not relevant as I said above. You confusion comes from not understanding what is happening here, and I seem to be failing to explain it such that you would understand :(
As I said before, I do not get this issue if I don’t load an ELF file into the program window and leave the microblaze set to ‘bootloop’ then do a ‘Run’ or ‘Debug’ command.
EXACTLY what I was talking about! When you run your application through Vitis, it not only programs FPGA with a bitstream containing a bootloop, but also downloads your elf file straight into DDR through JTAG, and then forces the CPU to jump to the beginning of DDR (which is where it placed your executable). This is something that your MicroSD card flow can not do, which is why I stressed that point.
EDIT 2: Actually there may be a way with the SPI flash, but not sure if I can make it work with MicroSD (ie will it give me a single .bit file??), looks essentially the same as what you linked to above, I will take a proper look later.
No, it will not. What it will do is create an image which you would need to burn into QSPI flash. Because, as I said above, your application can not be integrated into bitstream.
-
Thanks, I understand now (or at least I have a better understanding). So in order to get it to work fully off of DDR I need to program to the dev boards QSPI with an offset, put a bootloader in that offset region and point it to the starting point of the program.
I don't want to overwrite the QSPI on the Nexys Video and lose the demo (don't ask, my OCD just won't let me unless I HAVE to), and the Nexys Video XC7A200T FPGA has enough BRAM to manage the program.
For now I will keep it in BRAM and it also lets me run from MicroSD if I do that, then I will be making my own hardware later where I will have a QSPI flash memory device and most likely a smaller FPGA with less BRAM, so I will implement this using the bootloader when I get to that stage.
I just have to remember this thread exists so I can reference it in future. ;D
-
I don't want to overwrite the QSPI on the Nexys Video and lose the demo (don't ask, my OCD just won't let me unless I HAVE to), and the Nexys Video XC7A200T FPGA has enough BRAM to manage the program.
You can save the contents of QSPI flash to your PC using Vivado Hardware Manager. Connect to the board using USB, right click on FPGA -> Add Memory Device, pick the right parameters according to what you have on a board, say "no" to the question "Do you want to program memory?", then you need to right click on a memory device that appeared in the device tree and say "Read memory contents" and save it as "bin" or "mcs". I'm writing this off my memory so menu items might be named slightly differently, but you should have no problems figuring out which does what.
-
Thanks for the info, I have backed up the QSPI and been trying to get it working in Vivado / Vitis, but I think I am doing something wrong in how it should be connected in the block diagram.
Looking at the link you provided above you said...
1. Created a system diagram which includes DDR controller (DDR2 in my case), Microblaze, Timer, UART, EthernetLite (for 100 Mbit Ethernet) and Quad SPI (configured in "Performance Mode" and Quad).
2. Once generated bitstream and exported HW, went in Vitis and created a platform project based on that xsa file
3. Created a baremetal echo application using LwIp echo template. It's set to run from DDR (0x8000_0000).
4. Using "Xilinx -> Program Flash" menu item, converted the executable into SREC and burnt it into flash at offset 0x40_0000 (I have 128 Mbit flash, so 0x100_0000 bytes, full bitstream is 0x21_72F7 bytes).
5. Created another baremetal application using "SREC SPI Bootloader" template. It's automatically set to run off BRAM.
6. Opened blconfig.h file inside generated project and changed FLASH_IMAGE_BASEADDR to 0x00400000
7. Launched bootloader under debugger and observed what's going on.
I have configured my QSPI IP to be the same (performance mode and quad), but I am not sure how to connect it up properly. Can you upload a snip of your block diagram and how it is connected? I am a bit confused on the connections to the right in my image below (io0_i, io0_o, io0_t, etc).
Looking on line there is a lot of info on how to connect the IP in standard mode, but no details on how to connected in quad mode. The pins I have available in the Nexys Video Constraints file for QSPI are:
- qspi_cs
- qspi_dq[0]
- qspi_dq[1]
- qspi_dq[2]
- qspi_dq[3]
How should I connect those pins on the constraints file with the pins in the block diagram to get it working?
For the connections to the left I have connected as follows:
- AXI_FULL to MicroBlaze
- ext_spi_clk to 100MHz clock
- s_axi4_aclk to 100MHz clock
- s_axi4_aresetn to clock resetn signal
-
I have configured my QSPI IP to be the same (performance mode and quad), but I am not sure how to connect it up properly. Can you upload a snip of your block diagram and how it is connected? I am a bit confused on the connections to the right in my image below (io0_i, io0_o, io0_t, etc).
Make sure you also have "Enable STARTUP Primitive" selected as well.
As for connections:
All data pins (ioX) and a chip select (ss) are exposed as external and constained to pins which are actually connected to QSPI memory - refer to your board's schematics. Here is an example for my board (BTW I used the board from my signature as a testbed for this exersize):
set_property IOSTANDARD LVCMOS33 [get_ports {qspi_ss_io[0]}]
set_property IOSTANDARD LVCMOS33 [get_ports qspi_io0_io]
set_property IOSTANDARD LVCMOS33 [get_ports qspi_io1_io]
set_property IOSTANDARD LVCMOS33 [get_ports qspi_io2_io]
set_property IOSTANDARD LVCMOS33 [get_ports qspi_io3_io]
set_property PACKAGE_PIN C11 [get_ports {qspi_ss_io[0]}]
set_property PACKAGE_PIN B11 [get_ports qspi_io0_io]
set_property PACKAGE_PIN B12 [get_ports qspi_io1_io]
set_property PACKAGE_PIN D10 [get_ports qspi_io2_io]
set_property PACKAGE_PIN C10 [get_ports qspi_io3_io]
Your PACKAGE_PIN's are going to be different - look them up in the schematics.
Now, from the system side - AXI_FULL needs to connect to peripheral port of a Microblaze (probably through interconnect), s_axi4_aclk should be connected to AXI clock, s_axi4_aresetn - to AXI reset, ext_spi_clk has to be 50 MHz or below, so you will probably want to add another output clock to MCMM/PLL (if you have one), or add an extra output clock in MIG (page 7 "Memory Options", check "Select Additional Clocks", select a suitable frequency, run the wizard to completion, and you should see another output from MIG with that clock, which you need to connect to ext_spi_clk input of Quad SPI IP). You can also connect an interrupt output of that IP to your interrupt controller if you wish as well.
Once you regenerate a bitstream, make sure you re-export hardware (including bitstream) from Vivado and then refresh HW platform in Vitis to have all these changes propagate to your Vitis project.
-
Thanks I’ll add a new 50MHz clock for ext_spi_clk and enable startup primitive.
It’s clear that the ss pin on the BD goes to cs in the constraints file however I am still unsure on the data pins.
Should I connect io0_i, io0_o and io0_t all together then tie them to qspi_dw[0]??
That’s the part that is not clear, there are 3 pins on the BD for every 1 pin on the actual flash memory and constraints file. How are these 3 pins meant to interface with 1 pin on the QSPI flash?
-
It’s clear that the ss pin on the BD goes to cs in the constraints file however I am still unsure on the data pins.
Should I connect io0_i, io0_o and io0_t all together then tie them to qspi_dw[0]??
That’s the part that is not clear, there are 3 pins on the BD for every 1 pin on the actual flash memory and constraints file. How are these 3 pins meant to interface with 1 pin on the QSPI flash?
You only need to constrain pins as I showed "io0", without any suffixes. Those suffixes connect to IOBUF's pins which will be automatically generated by Vivado because they are bidirectional, so you don't have to worry about this. Right click on an "SPI_0" port of IP and select "Mark External" command, then rename that port to qspi to match names I have listed in my previous post, no need to mess with individual lines).
-
Ok, so I think I am making progress, but it still not working as it should, to summarise I have done the following:
1. Created HW design in vivado with QSPI IP 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 (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:
SREC SPI Bootloader
FlashID=0x1 0x2 0x19
Loading SREC image from flash @ address: 00A00000
Then nothing happens!
It is progress from this morning where I was getting the output below, as now it does not give an error and it picks up a flashID, but when my application boots I should see a load of text in the serial terminal and I get nothing, when I hook up external devices like a monitor there is no output either which indicates it is not loading the application.elf.
Have I missed something?
SREC SPI Bootloader
FlashID=0x0 0x0 0x0
Loading SREC image from flash @ address: 00A00000
Error in SREC line: 00000001srec line is corrupted
-
8. Programmed the application.elf at 0xA00000 as per the definition in step 4
Did you select "Convert ELF to bootloadable SREC format and program" checkbox while programming that file (see attached screenshot)? If so, please read back the flash contents into bin format and check with a binary editor what do you have at offset 0xA00000. You should see a bunch of human-readable lines starting from "S", here is example:
S02B0000443A2F416E647265792F50726F6A656374732F56697469732F53706172746135305F4D43555F5153C7
S30D00000000008000B0000008B802
S30D00000008008000B0F42008B8E6
S30D00000010008000B07C2C08B84A
S30D00000020008000B0AC0208B834
S31580000000018000B0D067A031018000B030624030FE
S315800000100C8000B088DD2030000000B0E001F4B92B
-
Hey, yes I did select the tick box and I do have data programmed at 0x00A00000, see image attached....not sure what is happening??
Also added an image of how I have the QSPI IP configured. Slave device set to Spansion as the Nexys Video resource manual says...
The correct part to be set in the tools is s25fl256xxxxxx0 from the manufacturer Spansion®.
I have also noticed it is quite slow to load up the bootloader (20-30 seconds maybe), but that might be a separate issue to look at later, first need to figure out why it wont load the application.elf??
EDIT:
Right, so interestingly enough just after posting I found this thread... https://forum.digilent.com/topic/18106-srec-spi-bootloader-is-very-slow/?sortby=date
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??
-
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?
Yes SREC is slow because it accepts binary in a text form (which is what you've seen in the flash dump), and then performs text-to-binary conversion, byte by byte. It was designed back in a day for small firmwares (on the order of perhaps tens of KB), so then it was acceptable.
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??
You've got to address that question to the author of that bootloader, I have no idea honestly.
-----
There is also a third way, which is to configure Quad SPI IP as XIP (eXecute-In-Place), which would map flash contents directly into CPU's address space as a read-only memory, and thus the CPU can execute this executable directly from flash, but for that you've got to make sure to map executable sections of your firmware appropriately - namely, read-only sections of your firmware needs to go to the XIP address space, while writable ones have to be mapped into DDR, and then you will still need some sort of shim in BRAM which would initialize Quad SPI IP (if neccessary) and jump to it. I haven't tried that approach myself yet (even though I've been meaning to do it for a long time), so if you want to give it a try - please let us all know if you can get it to work as I'd be curious myself.
-
Yes SREC is slow because it accepts binary in a text form (which is what you've seen in the flash dump), and then performs text-to-binary conversion, byte by byte. It was designed back in a day for small firmwares (on the order of perhaps tens of KB), so then it was acceptable.
The bootloader I am using doesn't uses SREC, it uses the ELF file programmed directly onto the QSPI flash and loads that into RAM. It's not the loading of my application that is slow, it is the actual programming of the FPGA it seems that takes 25 seconds or so, as soon as the LEDs on the board come up (to indicate the FPGA is programmed) I can see the code executes almost immediately with this bootloader from the serial terminal.
Is there any way to speed up the FPGA programming from QSPI? I would have though it would be quicker than 25-30 seconds, no?
You've got to address that question to the author of that bootloader, I have no idea honestly.
-----
There is also a third way, which is to configure Quad SPI IP as XIP (eXecute-In-Place), which would map flash contents directly into CPU's address space as a read-only memory, and thus the CPU can execute this executable directly from flash, but for that you've got to make sure to map executable sections of your firmware appropriately - namely, read-only sections of your firmware needs to go to the XIP address space, while writable ones have to be mapped into DDR, and then you will still need some sort of shim in BRAM which would initialize Quad SPI IP (if neccessary) and jump to it. I haven't tried that approach myself yet (even though I've been meaning to do it for a long time), so if you want to give it a try - please let us all know if you can get it to work as I'd be curious myself.
I will try to reach out to them, but I did find the following thread: https://support.xilinx.com/s/question/0D52E00006hpSlnSAE/software-reset-of-mb-processor?language=en_US
It links to this support article for ISE & EDK, I need something similar but for Vivado & Vitis: https://support.xilinx.com/s/article/30878?language=en_US
I was going to ask, if you don't mind, can you test with the SREC QSPI bootloader, if you get your program running with the bootloader then use a button to reset the MicroBlaze, does it reset and start working from the bootloader again?
I am wondering if when the application is loaded into DDR it modifies the .data linker script and then on a reset you are stuck in limbo and hence it needs a full FPGA programming. That is basically what those links above describe and what I see with this bootloader I have, but I was wondering if you could test it out with the SREC QSPI Bootloader if its not too much hassle?
Running as XIP may be something I will look into, to be honest my program does not need to write any info to memory, it just reads the program and then sends commands to other parts of the FPGA to kick them off, once done it sits silently forever more unless a reset is initiated then I want it to just start over again and re-configure the hardware.
So that may be an easier implementation of XIP that could work, I will need to look into it.
Thanks for all your time and help so far, however. Hugely appreciated! Altho I would still be interesting in knowing why the SREC SPI Bootloader doesn't work?? Very odd.
-
The bootloader I am using doesn't uses SREC, it uses the ELF file programmed directly onto the QSPI flash and loads that into RAM. It's not the loading of my application that is slow, it is the actual programming of the FPGA it seems that takes 25 seconds or so, as soon as the LEDs on the board come up (to indicate the FPGA is programmed) I can see the code executes almost immediately with this bootloader from the serial terminal.
Is there any way to speed up the FPGA programming from QSPI? I would have though it would be quicker than 25-30 seconds, no?
Did you set config frequency higher than default (2 MHz if my memory serves me), and also enabled bitstream compression? If not, try to add the following lines to the end of your constraints file (*.xdc) and regenerate a bitstream:
set_property BITSTREAM.GENERAL.COMPRESS TRUE [current_design]
set_property BITSTREAM.CONFIG.CONFIGRATE 66 [current_design]
set_property CONFIG_MODE SPIx4 [current_design]
These constraints (1) enable bitstream compression, (2) enable 66 MHz config frequency (most half-modern QSPI flash devices can handle that kind of frequency, if not, try 50 or 33, note that this frequency has very large tolerance ±50%), and (3) set QSPI mode.
I was going to ask, if you don't mind, can you test with the SREC QSPI bootloader, if you get your program running with the bootloader then use a button to reset the MicroBlaze, does it reset and start working from the bootloader again?
I will give it another try when I have some more spare time.
-
Did you set config frequency higher than default (2 MHz if my memory serves me), and also enabled bitstream compression? If not, try to add the following lines to the end of your constraints file (*.xdc) and regenerate a bitstream:
set_property BITSTREAM.GENERAL.COMPRESS TRUE [current_design]
set_property BITSTREAM.CONFIG.CONFIGRATE 66 [current_design]
set_property CONFIG_MODE SPIx4 [current_design]
These constraints (1) enable bitstream compression, (2) enable 66 MHz config frequency (most half-modern QSPI flash devices can handle that kind of frequency, if not, try 50 or 33, note that this frequency has very large tolerance ±50%), and (3) set QSPI mode.
I added those to my constraints file, but seems to have not made a difference??
I will give it another try when I have some more spare time.
Thanks! Appreciate it! :-+
-
I added those to my constraints file, but seems to have not made a difference??
I assume you re-did export hardware and updated it in Vitis? If so - make sure that Vitis actually picked up the updated bitstream, in the past I had to do "Update Hardware" multiple times sometimes for the changes to be picked up. Check if the bitstream in /hw subfolder of your Vitis "platform" folder is the same as "<you_Vivado_project_name>.runs/impl_1/<diagram_name>_wrapper.bit", if not, repeat "Update hardware" until it is.
Also make sure that those lines are the very last lines of that constraints file. Since these are tcl commands, later commands which could possibly present in your file down the line can override those values.
-
I assume you re-did export hardware and updated it in Vitis? If so - make sure that Vitis actually picked up the updated bitstream, in the past I had to do "Update Hardware" multiple times sometimes for the changes to be picked up. Check if the bitstream in /hw subfolder of your Vitis "platform" folder is the same as "<you_Vivado_project_name>.runs/impl_1/<diagram_name>_wrapper.bit", if not, repeat "Update hardware" until it is.
Also make sure that those lines are the very last lines of that constraints file. Since these are tcl commands, later commands which could possibly present in your file down the line can override those values.
Yes to all the above, made the changes, generated bitstream, exported, updated in Vitis, as you say had to do it a few times before the 'Created On:' date / time in Vitis updated to show it had taken the new hardware.
Rebuilt project, confirmed the bit & MMI are created recently before generating download.bit, then programmed to SPI flash and still the same.
They are also the very last lines in the .xdc constraints file
Still takes 25-30 seconds or so for the FPGA to load, then the bootloader and my application come online instantly within a second or 2.
-
Yes to all the above, made the changes, generated bitstream, exported, updated in Vitis, as you say had to do it a few times before the 'Created On:' date / time in Vitis updated to show it had taken the new hardware.
Rebuilt project, confirmed the bit & MMI are created recently before generating download.bit, then programmed to SPI flash and still the same.
They are also the very last lines in the .xdc constraints file
Still takes 25-30 seconds or so for the FPGA to load, then the bootloader and my application come online instantly within a second or 2.
That doesn't make any sense... Can you try removing compression, regenerate a bitstream and see if file size is any different?
-
Just checked the bitstream size and I can confirm without doing anything else that the file size did not change when I added the following line....
set_property BITSTREAM.GENERAL.COMPRESS TRUE [current_design]
It was 9,503kB before I added that to my constraints and having just checked the file is the same size after the line above has been added.
Looks like Vivado is ignoring it for some reason??
-
Just checked the bitstream size and I can confirm without doing anything else that the file size did not change when I added the following line....
set_property BITSTREAM.GENERAL.COMPRESS TRUE [current_design]
It was 9,503kB before I added that to my constraints and having just checked the file is the same size after the line above has been added.
Looks like Vivado is ignoring it for some reason??
Yeah, that is super-weird. Please right-click on your constraints file in a "Sources" tab, select "Source File Properties" and ensure that "Enabled", "Synthesis" and "Implementation" checkboxes are all set. If they are, I honestly don't really know what else to try. Unless you can post your design somewhere so I can download and take a look, there is nothing else I can think of at the moment.
-
Yeah, that is super-weird. Please right-click on your constraints file in a "Sources" tab, select "Source File Properties" and ensure that "Enabled", "Synthesis" and "Implementation" checkboxes are all set. If they are, I honestly don't really know what else to try. Unless you can post your design somewhere so I can download and take a look, there is nothing else I can think of at the moment.
Yeah, that is all set already. In all fairness the Xilinx documentation does say that enabling compression does not guarantee a smaller file size (see snippet attached), but I think the stranger thing is that the config clock doesn't change anything.
The Xilinx docs state 3MHz is default and I have tried at 66, 33 and 50 (in that order) all to no avail, still takes 25-30 seconds and that is what doesn't make sense, more so than the compression.
-
Ok, so I decided to edit device properties under implementation and make the configuration changes that way, then allow Vivado to update the constraints file as it wants instead of doing it manually (see page 38 in the link below) and now at 16MHz it works and flashes in 1 second or so with the following settings...
BITSTREAM.CONFIG.CONFIGRATE 16
BITSTREAM.GENERAL.COMPRESS TRUE
BITSTREAM.CONFIG.SPI_32BIT_ADDR
BITSTREAM.CONFIG.SPI_FALL_EDGE
Compression also seems to work properly now as the bitstream is down from 9,503kB to 4,673kB!
I will test at higher speeds also, but that is essentially 1 issue fixed, now I need to see if I can get the MicroBlaze to re-load the bootloader during a reset instead of doing what it does now and seemingly tries to load the main application but can't as it can't do that without the bootloader.
https://docs.xilinx.com/viewer/book-attachment/vbfPKhIJDzuHzAa46EWDIA/0tKFPiZS~Js8F29Ex2VsaQ
EDIT: Updated to 66MHz and the loading is near as makes no difference instant! ;D :-+
-
Ok, so I decided to edit device properties under implementation and make the configuration changes that way, then allow Vivado to update the constraints file as it wants instead of doing it manually (see page 38 in the link below) and now at 16MHz it works and flashes in 1 second or so with the following settings...
That means you have more than one constraints file.
-
That means you have more than one constraints file.
No I don’t, I only have the one and I can see the file Vivado made changes to is the same one I made changes to.
I suspect it was enabling these 2 extra settings that made the difference and fixed it.
BITSTREAM.CONFIG.SPI_32BIT_ADDR
BITSTREAM.CONFIG.SPI_FALL_EDGE