How to set base address in Vitis / Vivado??

[Mario87]

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!

[asmi]

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.

[Mario87]

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! 

[asmi]

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.

[Mario87]

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).

[asmi]

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?

[Mario87]

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.

[asmi]

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.

[Mario87]

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.

[asmi]

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

[Mario87]

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?

[asmi]

What board do you use and how do you program it?

[Mario87]

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.

[asmi]

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.

[Mario87]

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.

[asmi]

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.

[Mario87]

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

[asmi]

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.

[Mario87]

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. 

[asmi]

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.

[Mario87]

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

[asmi]

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.

[Mario87]

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?

[asmi]

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).

[Mario87]

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