plugins/org.eclipse.app4mc.amalthea.model.help/docu/user_memorysection.textile

h3(#user-memsection). Memory Sections

**Purpose**

Memory Sections are used for the division of the memory (RAM/ROM) into different blocks and allocate the "software" memory elements (_e.g. Labels_), code accordingly inside them.
Each Memory Section has certain specific properties (_e.g. faster access of the elements, storing constant values_). By default compiler vendors provide certain Memory Sections (_e.g. .data, .text_) and additional Memory Sections can be created based on the project need by enhancing the linker configuration.

**Definition**

A "Memory Section" is a region in memory (RAM/ROM) and is addressed with a specific name. There can exist multiple "Memory Sections" inside the same Memory (RAM/ROM) but with different names. Memory Section names should be unique across the Memory (RAM/ROM).

Memory Sections can be of two types: 
* Virtual Memory Section
* Physical Memory Section


h4. Virtual Memory Section

"Virtual Memory Sections" are defined as a part of data specification and are associated to the corresponding Memory Elements (e.g. Label's) during the development phase of the software. Intention behind associating "Virtual Memory Sections" to Memory elements like Label's is to control their allocation in specific Memory (e.g. Ram1 or Ram2) by linker. 

As a part of linker configuration - It is possible to specify if a "Virtual Memory Section" __(e.g. mem.Sec1)__ can be part of certain Memory _(e.g. Ram1/Ram2/SYSRAM but not Ram3)_.



+_Example:_+ 

Software should be built for ManyCore ECU - containing 3 Cores _(Core1, Core2, Core3)_. Following RAMs are associated to the Cores: Ram1 - Core1, Ram2 - Core2, Ram3 - Core3, and also there is SYSRAM.

Virtual Memory Section : mem.sec1 _(is defined as part of data specification)_ is associated to Label1 and Label2.

!(scale)../pictures/user_section_label_ref_to_memsection.png!

In Linker configuration it is specified that mem.sec1 can be allocated only in Ram1 or Ram2.

Below diagram represents the _+*linker configuration content*+_ - w.r.t. possibility for physical allocation of mem.sec1 in various memories .

!(scale)../pictures/user_section_linker_memsection.png!

Based on the above configuration - Linker will allocate Label1, Label2 either in Ram1/Ram2/SYSRAM but not in Ram3/Ram4.


h4. Physical Memory Section

"Physical Memory Sections" are generated by linker. The linker allocates various memory elements (e.g. Label's) inside "Physical Memory Sections".

Each "Physical Memory Section" has following properties:

* Name - It will be unique across each Memory 
* Start and End address - This represents the size of "Physical Memory Section"
* Associated Physical Memory _(e.g. Ram1 or Ram2)_

+_Example:_+  There can exist mem.sec1.py inside Ram1 and also in Ram2. But these are physically two different elements as they are associated to different memories (Ram1 and Ram2) and also they have different "start and end address". 

Below diagram represents the information w.r.t. virtual memory sections _(defined in data specification and associated to memory elements)_ and physical memory sections __(generated after linker run)__.

!(scale)../pictures/user_section_virtual_to_physical.png!


h4. Modeling Memory Section information in AMALTHEA

* As described in the above concept section:
** Virtual memory sections are used:
*** To specify constraints for creation of Physical memory sections by linker
*** To control allocation of data elements (e.g. Labels) in a specific memory _(e.g. Ram1/Ram2/SYSRAM)_
** Physical memory sections are containing the data elements after linker run _(representing the software to be flashed into ECU)_ 

Below figure represents the modeling of "Memory Section" (both virtual and physical) information in AMALTHEA model:
!(scale)../pictures/user_section_amalthea.png!

Below are equivalent elements of AMALTHEA model used for modeling the Memory Section information:
 
* *Section* 
** This element is equivalent to Virtual Memory Section defined during the SW development phase.
** As a part of data specification defined in the sw-development phase, a Section object _(with specific name)_ is associated to Label and Runnable elements.

* *PhysicalSectionConstraint*
** This element is equivalent to the constraint specified in the linker configuration file, which is used to instruct linker for the allocation of Physical Memory Sections in specified Memories.
** PhysicalSectionContraint is used to specify the combination of Virtual Memory Section and Memories _(which can be considered by linker for generation of Physical Memory Sections)_.

bq. _+Example:+_   PhysicalSectionConstraint-1 is specifying following relation "Section-1" <--> "Memory-1", "Memory-2". This means that the corresponding Physical Memory Section for "Section-1" can be generated by linker in "Memory-1" or in "Memory-2" 	or in both. 

* *PhysicalSectionMapping* 
** This element is equivalent to Physical Memory Section generated during the linker run.
*** Each PhysicalSectionMapping element:
**** Contains the Virtual Memory Section _(e.g. Section-1)_ which is the source. 
**** is associated to a specific Memory and it contains the start and end memory address _(difference of start and end address represents the size of Physical Memory Section)_.
**** contains the data elements _(i.e. Labels, Runnables part of the final software)_.

bq. *Note:* There is also a possibility to associate multiple Virtual Memory Section's as linker has a concept of grouping Virtual Memory Sections while generation of Physical Memory Section.

bq. _+Example:+_ For the same Virtual Memory Section __(e.g. Section-1)__, linker can generate multiple Physical Memory Sections in different Memories _(e.g. PhysicalSectionMapping-1, PhysicalSectionMapping-2)_. Each PhysicalSectionMapping element is an individual entity as it has a separate start and end memory address.