Change size of memory regions

Moved to CrossCore Embedded Studio and Add-ins community.

Hi,

additional question:

Is it possible to reserve more memory for the dm and pm memory sections as 1 Mbit each? The datasheet states a maximum of 1 Mbit on page 5.

If I have more data in the sample buffers and coefficient buffers as 1 Mbit, would it be possible to use the remaining memory of the 5 Mbit total?

Regards,
Markus

Hi Markus,

The .ldf file directs the linker by mapping code or data to specific memory segments.

We recommend to refer the below linked faq and document included in that, for more details.
[FAQ] : Modify LDF in CCES
ez.analog.com/.../faq-modify-ldf-in-cces

The ADSP-2156x SHARC+ cores have 5 Mbit L1 RAM split over four blocks, by default.
L1-Block 0 RAM (1.5 MBit)
L1-Block 1 RAM (1.5 MBit)
L1-Block 2 RAM (1 MBit)
L1-Block 3 RAM (1 MBit)

By default, the compiler automatically places static and global variables in the DM data section and program code in PM sections(make use of all available space for PM and DM automatically)

You can also enable the 'Generate Symbol Map' option under the 'General' options for the Linker . This will produce an XML map file, detailing all objects and memory usage/placement within your application which can be viewed in CCES's internal browser, via Right-clicking on the Proj_name_map.xml in CCES project explorer > open with > Other > internal web browser.

It shows the memory sections declared in the LDF, their start and end bounds and - most importantly - their free/used space. Using this map file you can determine whether there is perhaps a memory section that is being under-used that you could place more data into.

You can use the #pragma section("section_name") directive to force your specific function/data into L1 memory.Use this before each function or variable that you want to place in L1 memory.This pragma will only affect the next symbol and if you use this pragma right before a function, that function alone will be placed in the section.

You can provide any name in section name. But the memory section name should as it is named in app.ldf file.

For example:

#pragma section("testing1")
static unsigned int testArray1[1024*4]={1};

Also, add the appropriate INPUT_SECTIONS commands to your LDF in a suitable place in app.ldf, like below:

custom_section_name //Output section
{
INPUT_SECTIONS( $OBJS_LIBS(custom_section_name) ) // Input section
} > mem_block0_bw // Memory section

For example:

test1_dxe //Output section
{
INPUT_SECTIONS( $OBJS_LIBS(testing1) ) // Input section
} > mem_block0_bw // Memory section

To prevent modifications being over written by the tools, You should apply your modification to the sections which allow customization of the LDF by users.The sections are denoted by:

/*$VDSG<insert-user-ldf-commands> */
/* Text inserted between these $VDSG comments will be preserved */
/*$VDSG<insert-user-ldf-commands> */

Text inserted between these $VDSG comments will be preserved and any changes made outside of $VDSG section will be lost when the LDF is regenerated.

If you have larger buffer/arrays, you may have to make use of external memory. So please enable external memory option in your project to avoid out of memory linker error.

If your project exhaust the available internal memory, you would need to look at making use of SDRAM. Select Use external memory (SDRAM) to enable the size and partitioning controls under system.svc > Startupcode/LDF > LDF > External Memory

Regards,
Santhakumari.K

Hi santha.vijay ,

thank you for the informations.

Do I understand correctly: if I want to change the sizes of the memory regions I have to change the start (and end) addresses of the sections in the memory section of "app.ldf"?

   // ----------------------- L1-Block 0 RAM (1.5 MBit) ------------------------
   mem_iv_code             { TYPE(PM RAM) START(0x00090000) END(0x000900a7) WIDTH(48) }
   mem_block0_bw           { TYPE(BW RAM) START(0x002403f0) END(0x0026ffff) WIDTH(8) }

   // ----------------------- L1-Block 1 RAM (1.5 MBit) ------------------------
   // The data cache attached to block 1 caches all the external memory access
   // requests for the DM bus. The size of the cache can be adjusted with a
   // corresponding reduction of the available non-cache L1 space.
   // 16 KB at the end of block 1 is DM cache
   mem_block1_bw           { TYPE(BW RAM) START(0x002c0000) END(0x002ebfff) WIDTH(8) }

   // ----------------------- L1-Block 2 RAM (1 MBit) --------------------------
   // The data cache attached to block 2 caches all the external memory access
   // requests for the PM bus. If the size of the cache is 128KB, the whole
   // of block 2 is cache.
   // 16 KB at the end of block 2 is PM cache
   mem_block2_bw           { TYPE(BW RAM) START(0x00300000) END(0x0031bfff) WIDTH(8) }

   // ----------------------- L1-Block 3 RAM (1 MBit) --------------------------
   // The instruction cache is attached to block 3.
   // 16 KB at the end of block 3 is instruction cache
   mem_block3_bw           { TYPE(BW RAM) START(0x00380000) END(0x0039bfff) WIDTH(8) }

I notized that the start addresses are not consecutive with the end of the block before. For example the end of block 0 is at 0x0026ffff and the start of block 1 is at 0x002c0000. Are there any boundary conditions that have to be considered?
Is there any tool to calculate and setup the addresses?

Regards,
Markus

Hi Markus,

As you have seen, for ADSP-2156x all available space of L1 blocks are partitioned for 8-bit range as below in app.ldf file by default.

mem_block0_bw { TYPE(BW RAM) START(0x002403f0) END(0x0026ffff) WIDTH(8) }
mem_block1_bw { TYPE(BW RAM) START(0x002c0000) END(0x002ebfff) WIDTH(8) }
mem_block2_bw { TYPE(BW RAM) START(0x00300000) END(0x0030ffff) WIDTH(8) }
mem_block3_bw { TYPE(BW RAM) START(0x00380000) END(0x0039bfff) WIDTH(8) }

The available space for L1 BLOCK 0 SRAM (1.5Mb) starts from address 0x00240000 and ends in 0x0026FFFF.

And corresponding range for L1 BLOCK 1 SRAM (1.5Mb)starts from address 0x002C0000 and ends in 0x002EFFFF.

Please note that, the address range(0x00270000 - 0x002BFFFF) in between L1 BLOCK 0 and L1 BLOCK 1 belongs to the reserved section, which cannot be accessed for application purposes. Hence You need to be careful regarding which and how they are accessing a particular memory in a processor.

You can refer the "Figure 4. ADSP-2156x Memory Map" in Page 6 of 102 in the below linked datasheet for more details.
www.analog.com/.../adsp-21562-21563-21565-21566-21567-21569.pdf

Also, you can modify available memory sections start and end address to partition any specific block as per your need.
For example,
Partitioning  mem_block2_bw into 2 blocks.
mem_block2_bw { TYPE(BW RAM) START(0x00300000) END(0x0030f000) WIDTH(8) }
mem_block2_bw_1 { TYPE(BW RAM) START(0x0030f001) END(0x0030ffff) WIDTH(8) }

Hope this helps

Best Regards,
Santhakumari.K

Hi santha.vijay ,

thank you for the information.

I need to force data which is located in DM to be stored in block1 instead of block0, because there is not enough space for the heap and stack since there is also DM data placed in block 0.
How can I do that?

Regards,
Markus

Is it sufficient to just put

#pragma section("seg_l1_block1")

before the variables and arrays I want to put in block 1 instead of block 0 ?

Hi Markus,

Controlling the placement of the function or data is then a case of adding appropriate output section in LDF.

You can use #pragma section("section_name") directive to force your data into specific memory. Use this before each function that you want to place in the section. This pragma will only affect the next symbol and if you use this pragma right before a function, that function alone will be placed in the section.

For example:

#pragma section("seg_test_data")
int data1;

Also, add the appropriate INPUT_SECTIONS commands to your LDF in a suitable place in app.ldf, like below.

custom_section_name //Output section
{
INPUT_SECTIONS( $OBJS_LIBS(custom_section_name) ) // Input section
} > > mem_section_name // Memory section

For eg:

dxe_test
{
INPUT_SECTIONS( $OBJS_LIBS(seg_test_data ) )
} > mem_block1_bw

We have tried mapping data into block 1 memory using #pragma section("section_name") directive.Please refer the attached screenshots for your reference.

For more information, take a look at the "#pragma section/#pragma default_section" in the CCES help:
CrossCore® Embedded Studio <version> > Sharc® Development Tools Documentation > C/C++ Compiler Manual for Sharc® Processors > Compiler > C/C++ Compiler Language Extensions > Pragmas > Linking Control Pragmas > #pragma section/#pragma default_section

Also, By enabling the 'Generate symbol Map' option under the 'General' options for the Linker. If you enabled the option to "Generate Symbol Map", the Linker will also generated a project_name.map.xml file which can be viewed in Internet Explorer to view a map of your project. It shows the memory sections declared in the LDF, their start and end bounds and - most importantly - their free/used space. Using this map file you can determine whether there is perhaps a memory section that is being under-used that you could place more data into.

Regards,
Santhakumari.K