07-14-2009 07:47 AM
Does anyone has an idea how can I use larger BRAM (more than 64K) in a MicroBlaze project? From the MicroBlaze user guide, it looks like I need to generate
a new BRAM module using core generator. I did that and now I have vhdl source file for 128K BRAM module and need to incorporate this module into my project.
I checked the Create or Import Peripheral Wizard. Seems it can incorporate peripheral modules which connect to PLB. But in my case, I want to replace the default 64K BRAM
in XPS using my 128K one and connect it to LMB. Is there any way to do that? Or is there any way I can go to enlarge the BRAM size? Thanks.
04-07-2010 04:16 AM
Hi,
If you're making your memories to have contiguous addresses, you can make the memory to be as one contiguous memory block in the linker script.
In the linker script you will most likely have something like this:
MEMORY
{
ilmb_cntlr_dlmb_cntlr : ORIGIN = 0x00000050, LENGTH = 0x00001FB0
DDR2_SDRAM_C_MPMC_BASEADDR : ORIGIN = 0x50000000, LENGTH = 0x10000000
}
If you have extended the lmb_bram to be 96kbyte by using multiple lmb_bram_if_cntlr, you can change the LENGTH in the linker script.
like this:
ilmb_cntlr_dlmb_cntlr : ORIGIN = 0x00000050, LENGTH = 0x00017FB0
Göran
07-14-2009 08:18 AM
EDK->System Assembly View->Addresses->
Increase data local memory bus (dlmb) and instruction local memory bus (ilmb) BRAM controller's address range, hence changing the memory space to, say, 128K of both equally. Don't forget to re-generate the linker script of your application.
Best,
JM
07-14-2009 08:38 AM
I tried yesterday but did not work. Maybe forgot to regenerate the linker script. I will try again. Thx.
Bests,
Changyun
07-15-2009 04:19 AM - edited 07-15-2009 04:25 AM
Hi,
There is no need to use the core generator.
If you want more BRAM on the LMB bus, just add more lmb_bram_if_cntlr and connect them to new bram_module.
Each lmb_bram_if_cntlr can handle 64kbyte so just add more of them.
The same if the BRAM is on the OPB or PLB, just add the bram_controller for that bus and a new bram_module.
This can be done in the normal system assembly view in XPS.
Göran
07-15-2009 09:19 AM
Hi,
I added in one more bram_block and one more lmb_bram_if_cntlr, generate addresses in system assembly view. In SDK, I did xilinx tools->synchronize with hardware, re-generate
linker script, compile, generate the elf file. Then updated bitstream in XPS, downloaded bitstream to the board. But seems the software did not really execute (even in my linker script,
I did not use the newly added BRAM block). Is there any missing steps?
Thanks.
Bests,
Changyun
07-15-2009 11:30 PM - edited 07-15-2009 11:33 PM
Hi,
Did you connect them to MicroBlaze?
Can you post the .mhs?
If you only added one more lmb_bram_if_cntlr, did you connect it to the ILMB or DLMB interface on MicroBlaze?
Do you need more BRAM for code or for data?
If you added it for code, you need to add another lmb_bram_if_cntlr so that the data side can have access to this bram.
Data need access to the instruction memory if you want to download to it or setting soft breakpoints.
Göran
07-16-2009 12:38 PM
Hi,
It works now. I regenerated the libraries and BSPs then it works now. Thanks a lot for your help.
Bests,
Changyun
03-29-2010 11:25 AM
Göran,
My EDK executable .data section is ~ 84K. I have a 64 K BRAM but I cannot fit this section into this BRAM. Is there any way to split code sections into smaller sections for using multiple BRAMs to store a given section?
Thank you,
Josh
03-31-2010 12:25 AM
Hi,
Just add another 32k lmb_bram controller and make the address align with the 64k BRAM block.
This makes MicroBlaze to have a contiguous memory region of 96 K which should be enough for your application.
Göran
03-31-2010 02:51 PM
Great, however, the Linker Script generator does not allow me to use this as one location since my individual memories cannot hold the .data section without splitting it up.
I have attempted to setup the linker script manually, but there ar emany things I am unsure about.
Is ther any way to"merge" these such that the linker script generator can see them as one?
Any other ideas?
04-07-2010 04:16 AM
Hi,
If you're making your memories to have contiguous addresses, you can make the memory to be as one contiguous memory block in the linker script.
In the linker script you will most likely have something like this:
MEMORY
{
ilmb_cntlr_dlmb_cntlr : ORIGIN = 0x00000050, LENGTH = 0x00001FB0
DDR2_SDRAM_C_MPMC_BASEADDR : ORIGIN = 0x50000000, LENGTH = 0x10000000
}
If you have extended the lmb_bram to be 96kbyte by using multiple lmb_bram_if_cntlr, you can change the LENGTH in the linker script.
like this:
ilmb_cntlr_dlmb_cntlr : ORIGIN = 0x00000050, LENGTH = 0x00017FB0
Göran
04-07-2010 11:32 AM
11-09-2010 08:23 AM
hi,
I have exactly the same problem, and I came to this point like you,
although I manually changed the size of Memory in linker script, compiler again say that .text does not fit in memory,
//--------------------------
ELF file : D:/Ar_SDK/Debug/Ar_SDK.elf
ERROR:EDK - elfcheck failed!
The following sections did not fit into Processor BRAM memory:
Section .text (0x50 - 0x14E67)
//--------------------------
although it shows no compile error, but when I want to program elf file, it says :
//--------------------------
Programming the FPGA failed due to errors from elfcheck
//--------------------------
it seems that there is some whereelse but linker script that tell compiler maximum amount of a section is 64 K,
did you have any progress?
11-09-2010 09:00 AM
@hamze wrote:
hi,
I have exactly the same problem, and I came to this point like you,
although I manually changed the size of Memory in linker script, compiler again say that .text does not fit in memory,
//--------------------------
ELF file : D:/Ar_SDK/Debug/Ar_SDK.elf
ERROR:EDK - elfcheck failed!
The following sections did not fit into Processor BRAM memory:
Section .text (0x50 - 0x14E67)//--------------------------
although it shows no compile error, but when I want to program elf file, it says :
//--------------------------
Programming the FPGA failed due to errors from elfcheck
//--------------------------
it seems that there is some whereelse but linker script that tell compiler maximum amount of a section is 64 K,
did you have any progress?
Ah, yes, I was unable to ever do this using SDK. It appears you are using SDK. I ended up putting my software project in EDK and building from there - then it worked.
Xilinx still has a long long way to go before their tools have consistency and work the way Xilinx says they should. You can usually do anything but you just have to find out a hack to get it to work. Simple changes like this could be made, but Xilinx usually fails to fix issues like this in new releases of software tools - instead adding functionality like "SDK will be your only option in the next release" while SDK still has integration issues with EDK. I have been repeatedly frustrated with the tools and show stoppers like this, but the tools are pretty powerful - you just gotta figure out how to get things done. This forum has been my saving grace.
Let me know if switching the software project to EDK and building it in there works for you. If not I'll dig up my old project and see if I can figure it out.
11-10-2010 06:15 AM
thanks,
it worked!
I moved whole my software project from SDK on eclipse to EDK inside, now manually changing size of BRAM in the linker script file makes no compile error. I programed it on board and it runs normally.
if possible I will try to find a solution for SDK, because it is better environment for software development,
11-10-2010 06:26 AM
hi goran,
manually changing size fo memory in linker script ask you said worked inside EDK software environment,
but exactly the same change does not work in SDK eclipse environment, it is still say that .text does not fit in section,
SDK is a better enrivonment for software development, do you have any solution for this?
11-10-2010 08:30 AM
@hamze wrote:
thanks,
it worked!
I moved whole my software project from SDK on eclipse to EDK inside, now manually changing size of BRAM in the linker script file makes no compile error. I programed it on board and it runs normally.
if possible I will try to find a solution for SDK, because it is better environment for software development,
Great! I am glad that worked for you.
Yes it would be nice to have it work in SDK. You would think SDK would be smarter, but I guess that is the problem - it is "smarter" and knows you're trying to trick it.
I just hope that Xilinx makes this work in SDK before disabling EDK software development entirely. I always find issues like this puzzling because it seems that software too large to fit in one BRAM block must be a very common issue. It seems like something like this would have been resolved years ago, but maybe it is not as common as I expect.
Adding software to PROM files (if not in BRAMs) is another problematic process I would expect to be common and with a clear solution, but this is a buggy, tricky, and poorly documented issue as well.
Happy coding,
Josh
12-08-2010 04:43 AM
hi
I prefer to work in SDK because it allows software and hardware engineers work separately ( and also backuping software and hardware projects separately )
I think I found a solution for SDK. Solution contains these steps :
12-08-2010 08:55 AM
Thanks for posting your solution - that is great.
What would really be great is if Xilinx would post things like that or better yet, make SDK just work in this configuration. I don't mind running things on command line, but c'mon Xilinx, don't make us figure out how to "hack" the tools to make them work.
Thanks again for sharing your solution. Hopefully they'll make this a little more seamless before requiring SDK use for all software designs.
12-09-2010 05:48 AM
12-09-2010 09:13 AM
Cool - good to know. Thanks.
02-16-2011 03:14 PM - edited 02-16-2011 03:39 PM
I'm trying to get this to work with a Virtex-5 SX95 that has 11 BRAMs added in XPS. The addresses are contiguous for each ilmb/dlmb/blockram @ 64K each.
I get this error:
----------------------------
ERROR:Data2MEM:31 - Out of bounds code segment for ram space in'implementation\system_bd.bmm'. Memory space 'microblaze_0.lmb_bram_9_combined' occupies[0x00000000:0x0000FFFF] Code segment #3 occupies [0x00000050:0x0002218B]
----------------------------
It seems the bmm file still shows the 64K total for ilmb_cntlr_9_dlmb_cntlr_9, which is the base addressed controller in my case. I also get the error in SDK until I tell it not to do the elf check (as mentioned earlier). I've adjusted the linker to only show the ilmb_cntlr_9_dlmb_cntlr_9 memory and changed the length to 0x000BFFF.
Any suggestions as to why these don't combine into the total conbined size?
Thanks,
Alex
02-16-2011 03:52 PM
In your linker script do you have something like:
I'm sure you do, but that is my only suggestion.
-Josh
02-17-2011 09:53 AM
I had my linker slightly different but I think it acomplished the same thing. I adjusted it to look like yours with each controller shown and one that I made to combine them all (I do have to make that manually, right?).
Here's what it looks like now:
with sections like:
.data : {
. = ALIGN(4);
__data_start = .;
*(.data)
*(.data.*)
*(.gnu.linkonce.d.*)
__data_end = .;
} > xps_BRAM_cntlr_all
None of the sections reference the individual controllers. As I mentioned before, I always get the elf error in SDK so (as instructed in another reply) I turn off the error check and use data2mem in a command window. I get the same error as before though.
It looks like the referenced data section in the bmm file shows 64K areas and that's why its failing. Could there be something I'm not doing right in the hardware to cause this? One of the previous replies indicated that a change may need to be made manually to the bmm file. If so, which documentation shows the format of the bmm file?
Thanks,
Alex
02-17-2011 10:13 AM
You do have to combine them all manually (add the 'all' memory area to the linker script) - otherwise the defined areas are not large enough.
I used a separate set of BRAM_cntlr that is not the ilmb or dlmb just to avoid confusion or potential overlap issues. I don't really know if this makes a difference at all, but it is possible. I just wanted to be safe and sure that I had my own dedicated memory area.
I think the real issue is that the memory areas are not actually continuous as you think they are.
I think you want something more like:
FYI - I use google as my hex calculator and converter for this kind of thing.
-Josh
02-17-2011 01:29 PM - edited 02-17-2011 01:30 PM
Clearly the addresses need to match the address mappings in EDK itself as well. I suggest these are changed to be continuous.
02-17-2011 02:59 PM
You're completely right about the memory not being contiguous, its not even close and I must have regenerated the addresses recently and didn't notice they had changed so much. That explains the bmm file inconsistencies as well.
Thanks for your help Josh!
02-17-2011 03:08 PM - edited 02-17-2011 03:16 PM
My pleasure :-)
I've spent so much time struggling with Xilinx stuff that I try to help people out with things I've been through.
02-27-2011 09:13 PM
03-01-2011 07:34 AM
@fpgause wrote:
hi iam new to this and iam facing a problem in which i was storing the instruction and video from camera both in external memory and transmitting through Ethernet but it is not working what i guess it may be due to data instruction in external memory .I got of increasing the bram from this forum but do u have any basic docs for this so that i can implement that thing the .elf has reached to156 kB and whether it is required to part-ion the code or not
I used to store my programs in DDR, but realized that you then need a bootloader to get the program elf file into DDR just as you load the video data into DDR after the FPGA is loaded. If you do have both in memory you need ot be sure that the things you store in memory to not overlap or you will have corruption. I have had issues where my heap and stack were overwriting video data I stored in memory.
I tend to use BRAMS for program storage and heap and stack. I then can use DDR for frame buffers and such. Just to be safe, unless you need all of your memory - I usually start storing my video data at the midpoint of my memory, ie: 64M for 128MB memory. I fyou need more - move it back from there but I do not suggest putting it in the very beginning since it is possible something else is going there also.
I have written little test programs to run my firmware and software for a while and then read and print out the ends of my memory range to be sure my data is exactly where I think it is and not overunning bounds or actually not even there.
I hope this helps,
Josh