Embedded Processors and Peripherals

[thirdeye]

Cool - good to know. Thanks.

[alear]

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]

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

[thirdeye]

In your linker script do you have something like:

MEMORY

{

   ilmb_cntlr_dlmb_cntlr : ORIGIN = 0x00000050, LENGTH = 0x0000FFB0

   xps_BRAM_cntlr_0 : ORIGIN = 0x10000000, LENGTH = 0x00010000

   xps_BRAM_cntlr_1 : ORIGIN = 0x10010000, LENGTH = 0x00010000

    xps_BRAM_cntlr_both : ORIGIN = 0x10000000, LENGTH = 0x00020000

   MPMC_LPDDR_C_MPMC_BASEADDR : ORIGIN = 0x48000000, LENGTH = 0x08000000

}

followed by something like:

.text : {

   *(.text)

   *(.text.*)

   *(.gnu.linkonce.t.*)

} > xps_BRAM_cntlr_both

I'm sure you do, but that is my only suggestion.

-Josh

[alear]

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:

MEMORY

{

   ilmb_cntlr_dlmb_cntlr : ORIGIN = 0x000F0000, LENGTH = 0x00010000

   ilmb_cntlr_2_dlmb_cntlr_2 : ORIGIN = 0x00020000, LENGTH = 0x00010000

   ilmb_cntlr_3_dlmb_cntlr_3 : ORIGIN = 0x000C0000, LENGTH = 0x00010000

   ilmb_cntlr_4_dlmb_cntlr_4 : ORIGIN = 0x00080000, LENGTH = 0x00010000

   ilmb_cntlr_5_dlmb_cntlr_5 : ORIGIN = 0x00030000, LENGTH = 0x00010000

   ilmb_cntlr_7_dlmb_cntlr_7 : ORIGIN = 0x00050000, LENGTH = 0x00010000

   ilmb_cntlr_6_dlmb_cntlr_6 : ORIGIN = 0x000D0000, LENGTH = 0x00010000

   ilmb_cntlr_8_dlmb_cntlr_8 : ORIGIN = 0x00090000, LENGTH = 0x00010000

   ilmb_cntlr_9_dlmb_cntlr_9 : ORIGIN = 0x00000050, LENGTH = 0x0000FFB0

   ilmb_cntlr_10_dlmb_cntlr_10 : ORIGIN = 0x000B0000, LENGTH = 0x00010000

   ilmb_cntlr_11_dlmb_cntlr_11 : ORIGIN = 0x00070000, LENGTH = 0x00010000

   xps_BRAM_cntlr_all : ORIGIN = 0x00000050, LENGTH = 0x000BFFFF

   SRAM_MEM0_BASEADDR : ORIGIN = 0x85400000, LENGTH = 0x00200000

   FLASH_MEM0_BASEADDR : ORIGIN = 0x86000000, LENGTH = 0x02000000

   PLATFORM_FLASH_MEM0_BASEADDR : ORIGIN = 0x82000000, LENGTH = 0x01000000

}

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

[thirdeye]

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:

MEMORY

{

   ilmb_cntlr_dlmb_cntlr : ORIGIN = 0x00010000, LENGTH = 0x00010000

   ilmb_cntlr_2_dlmb_cntlr_2 : ORIGIN = 0x00020000, LENGTH = 0x00010000 (0x00010000 + 0x00010000 = 0x20000)

   ilmb_cntlr_3_dlmb_cntlr_3 : ORIGIN = 0x00030000, LENGTH = 0x00010000 (0x00020000 + 0x00010000 = 0x30000)

   ilmb_cntlr_4_dlmb_cntlr_4 : ORIGIN = 0x00040000, LENGTH = 0x00010000 (0x00030000 + 0x00010000 = 0x40000)

   ilmb_cntlr_5_dlmb_cntlr_5 : ORIGIN = 0x00050000, LENGTH = 0x00010000 (0x00040000 + 0x00010000 = 0x50000)

   ilmb_cntlr_7_dlmb_cntlr_7 : ORIGIN = 0x00060000, LENGTH = 0x00010000 (0x00050000 + 0x00010000 = 0x60000)

   ilmb_cntlr_6_dlmb_cntlr_6 : ORIGIN = 0x00070000, LENGTH = 0x00010000 (0x00060000 + 0x00010000 = 0x70000)

   ilmb_cntlr_8_dlmb_cntlr_8 : ORIGIN = 0x00080000, LENGTH = 0x00010000 (0x00070000 + 0x00010000 = 0x80000)

   ilmb_cntlr_9_dlmb_cntlr_9 : ORIGIN = 0x00090000, LENGTH = 0x00010000 (0x00080000 + 0x00010000 = 0x90000)

   ilmb_cntlr_10_dlmb_cntlr_10 : ORIGIN = 0x000A0000, LENGTH = 0x00010000 (0x00090000 + 0x00010000 = 0xA0000)

   ilmb_cntlr_11_dlmb_cntlr_11 : ORIGIN = 0x000B0000, LENGTH = 0x00010000 (0x000A0000 + 0x00010000 = 0xB0000)

   xps_BRAM_cntlr_all : ORIGIN = 0x00010000, LENGTH = 0x000B0000 (0x00010000 * 11 = 0xB0000)

   SRAM_MEM0_BASEADDR : ORIGIN = 0x85400000, LENGTH = 0x00200000

   FLASH_MEM0_BASEADDR : ORIGIN = 0x86000000, LENGTH = 0x02000000

   PLATFORM_FLASH_MEM0_BASEADDR : ORIGIN = 0x82000000, LENGTH = 0x01000000

}

FYI - I use google as my hex calculator and converter for this kind of thing.

-Josh

[thirdeye]

Clearly the addresses need to match the address mappings in EDK itself as well. I suggest these are changed to be continuous.

[alear]

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!

[thirdeye]

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.

[fpgause]

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

[thirdeye]

---

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