How to set base address in Vitis / Vivado?? - Page 1
Forum section: electronics / general

author: Mario87
author_rank: Frequent Contributor
timestamp: June 08, 2023, 05:42:50 pm
content: 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...QuoteThe 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!

author: asmi
author_rank: Super Contributor
timestamp: June 08, 2023, 07:41:04 pm
content: 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.

author: Mario87
author_rank: Frequent Contributor
timestamp: June 08, 2023, 10:22:15 pm
content: Quote from: asmi on June 08, 2023, 07:41:04 pmAwesome, that has sorted it thanks!

author: asmi
author_rank: Super Contributor
timestamp: June 08, 2023, 11:50:45 pm
content: Quote from: Mario87 on June 08, 2023, 10:22:15 pmYou 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.

author: Mario87
author_rank: Frequent Contributor
timestamp: June 09, 2023, 09:24:27 am
content: 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).

author: asmi
author_rank: Super Contributor
timestamp: June 09, 2023, 02:22:23 pm
content: Quote from: Mario87 on June 09, 2023, 09:24:27 amI 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?

author: Mario87
author_rank: Frequent Contributor
timestamp: June 09, 2023, 02:53:34 pm
content: Quote from: asmi on June 09, 2023, 02:22:23 pmIf 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…QuoteThat 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.

author: asmi
author_rank: Super Contributor
timestamp: June 09, 2023, 03:16:30 pm
content: Quote from: Mario87 on June 09, 2023, 02:53:34 pmWhat exactly shows this error? Build? Programming? Attempting to lauch a debug session?Quote from: Mario87 on June 09, 2023, 02:53:34 pmNo worries - English is not my mother tongue, so I might've misunderstood you.

author: Mario87
author_rank: Frequent Contributor
timestamp: June 09, 2023, 03:30:34 pm
content: Quote from: asmi on June 09, 2023, 03:16:30 pmThe error appears when I generate a new download.bit file under the programming option.

author: asmi
author_rank: Super Contributor
timestamp: June 09, 2023, 04:28:23 pm
content: Quote from: Mario87 on June 09, 2023, 03:30:34 pmWhy 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

author: Mario87
author_rank: Frequent Contributor
timestamp: June 09, 2023, 05:21:07 pm
content: 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?

author: asmi
author_rank: Super Contributor
timestamp: June 09, 2023, 05:26:59 pm
content: What board do you use and how do you program it?

author: Mario87
author_rank: Frequent Contributor
timestamp: June 09, 2023, 05:57:21 pm
content: 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.

author: asmi
author_rank: Super Contributor
timestamp: June 09, 2023, 06:12:26 pm
content: Quote from: Mario87 on June 09, 2023, 05:57:21 pmIt 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.

author: Mario87
author_rank: Frequent Contributor
timestamp: June 09, 2023, 06:40:36 pm
content: 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.

author: asmi
author_rank: Super Contributor
timestamp: June 09, 2023, 06:52:28 pm
content: Quote from: Mario87 on June 09, 2023, 06:40:36 pmIt 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.Quote from: Mario87 on June 09, 2023, 06:40:36 pmThe 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.

author: Mario87
author_rank: Frequent Contributor
timestamp: June 09, 2023, 07:05:37 pm
content: Quote from: asmi on June 09, 2023, 06:52:28 pmIt 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…Quotehttps://support.xilinx.com/s/question/0D52E00006rCaGeSAK/unable-to-generate-the-downloadbit-file-updatemem-error?language=en_USEDIT 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_UShttps://support.xilinx.com/s/article/47909?language=en_US

author: asmi
author_rank: Super Contributor
timestamp: June 09, 2023, 08:27:31 pm
content: Quote from: Mario87 on June 09, 2023, 07:05:37 pmThis 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.Quote from: Mario87 on June 09, 2023, 07:05:37 pmThat 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 understandQuote from: Mario87 on June 09, 2023, 07:05:37 pmEXACTLY 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.Quote from: Mario87 on June 09, 2023, 07:05:37 pmNo, 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.

author: Mario87
author_rank: Frequent Contributor
timestamp: June 09, 2023, 09:54:40 pm
content: 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.

author: asmi
author_rank: Super Contributor
timestamp: June 10, 2023, 01:08:46 am
content: Quote from: Mario87 on June 09, 2023, 09:54:40 pmYou 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.

author: Mario87
author_rank: Frequent Contributor
timestamp: June 10, 2023, 04:25:31 pm
content: 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...QuoteI 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- qspi_dq- qspi_dq- qspi_dqHow 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

author: asmi
author_rank: Super Contributor
timestamp: June 10, 2023, 05:50:46 pm
content: Quote from: Mario87 on June 10, 2023, 04:25:31 pmMake 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):QuoteYour PACKAGE_PIN's are going to be different - look them up in the schematics.Now, from the system side -AXI_FULLneeds to connect to peripheral port of a Microblaze (probably through interconnect),s_axi4_aclkshould be connected to AXI clock,s_axi4_aresetn- to AXI reset,ext_spi_clkhas 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 toext_spi_clkinput 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.

author: Mario87
author_rank: Frequent Contributor
timestamp: June 10, 2023, 06:02:31 pm
content: 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??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?

author: asmi
author_rank: Super Contributor
timestamp: June 10, 2023, 06:11:39 pm
content: Quote from: Mario87 on June 10, 2023, 06:02:31 pmYou 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).

author: Mario87
author_rank: Frequent Contributor
timestamp: June 10, 2023, 10:31:09 pm
content: 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 bitstream2. Created my SW application in vitis and assigned all to DDR3. Created a new application in vitis for the bootloader and assigned all to BRAM4. 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.elf6. 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 4When I do the above I get the info below in the Vitis Serial Terminal:QuoteThen 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?Quote

author: asmi
author_rank: Super Contributor
timestamp: June 10, 2023, 11:20:41 pm
content: Quote from: Mario87 on June 10, 2023, 10:31:09 pmDid 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:Quote

author: Mario87
author_rank: Frequent Contributor
timestamp: June 11, 2023, 08:34:46 am
content: 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...QuoteI 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=dateIt 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??

author: asmi
author_rank: Super Contributor
timestamp: June 11, 2023, 06:48:41 pm
content: Quote from: Mario87 on June 11, 2023, 08:34:46 amYes 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.Quote from: Mario87 on June 11, 2023, 08:34:46 amYou'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.

author: Mario87
author_rank: Frequent Contributor
timestamp: June 11, 2023, 09:36:55 pm
content: Quote from: asmi on June 11, 2023, 06:48:41 pmThe 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?Quote from: asmi on June 11, 2023, 06:48:41 pmI 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_USIt 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_USI 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.

author: asmi
author_rank: Super Contributor
timestamp: June 12, 2023, 12:12:20 am
content: Quote from: Mario87 on June 11, 2023, 09:36:55 pmDid 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:Code:set_property BITSTREAM.GENERAL.COMPRESS TRUE set_property BITSTREAM.CONFIG.CONFIGRATE 66 set_property CONFIG_MODE SPIx4 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.Quote from: Mario87 on June 11, 2023, 09:36:55 pmI will give it another try when I have some more spare time.

author: Mario87
author_rank: Frequent Contributor
timestamp: June 12, 2023, 04:11:54 pm
content: Quote from: asmi on June 12, 2023, 12:12:20 amI added those to my constraints file, but seems to have not made a difference??Quote from: asmi on June 12, 2023, 12:12:20 amThanks! Appreciate it!

author: asmi
author_rank: Super Contributor
timestamp: June 12, 2023, 06:04:52 pm
content: Quote from: Mario87 on June 12, 2023, 04:11:54 pmI 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.

author: Mario87
author_rank: Frequent Contributor
timestamp: June 12, 2023, 07:05:08 pm
content: Quote from: asmi on June 12, 2023, 06:04:52 pmYes 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 fileStill 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.

author: asmi
author_rank: Super Contributor
timestamp: June 12, 2023, 07:16:30 pm
content: Quote from: Mario87 on June 12, 2023, 07:05:08 pmThat doesn't make any sense... Can you try removing compression, regenerate a bitstream and see if file size is any different?

author: Mario87
author_rank: Frequent Contributor
timestamp: June 13, 2023, 12:44:17 pm
content: 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....Code:set_property BITSTREAM.GENERAL.COMPRESS TRUE 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??

author: asmi
author_rank: Super Contributor
timestamp: June 13, 2023, 03:53:54 pm
content: Quote from: Mario87 on June 13, 2023, 12:44:17 pmYeah, 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.

author: Mario87
author_rank: Frequent Contributor
timestamp: June 14, 2023, 07:02:41 am
content: Quote from: asmi on June 13, 2023, 03:53:54 pmYeah, 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.

author: Mario87
author_rank: Frequent Contributor
timestamp: June 14, 2023, 12:19:20 pm
content: 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...Code:BITSTREAM.CONFIG.CONFIGRATE 16BITSTREAM.GENERAL.COMPRESS TRUEBITSTREAM.CONFIG.SPI_32BIT_ADDRBITSTREAM.CONFIG.SPI_FALL_EDGECompression 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~Js8F29Ex2VsaQEDIT: Updated to 66MHz and the loading is near as makes no difference instant!

author: asmi
author_rank: Super Contributor
timestamp: June 15, 2023, 12:35:12 am
content: Quote from: Mario87 on June 14, 2023, 12:19:20 pmThat means you have more than one constraints file.

author: Mario87
author_rank: Frequent Contributor
timestamp: June 15, 2023, 05:30:40 am
content: Quote from: asmi on June 15, 2023, 12:35:12 amNo 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.Code:BITSTREAM.CONFIG.SPI_32BIT_ADDRBITSTREAM.CONFIG.SPI_FALL_EDGE