Memory Overlay - ADSP

Started by karthikbalaguru March 13, 2008
Hi,

I am trying to get more info about External Memory Overlay .
In the document 'ADSP-218x External Overlay Memory By G. Y' from
IEEE , i find a reference to
a document " PM/DM Overlay & I/O Memory Expansion Board for ADSP 2181
EZ-KIT Lite
written by G. Yi.". But i am unable to get this ( PM/DM Overlay & I/O
Memory Expansion Board
for ADSP 2181 EZ-KIT Lite written by G. Yi ) document from internet.
Does anyone has any link for this ?

Is there any other link / pdf that talks in detail about this Memory
Overlay ?

Thx in advans,
Karthik Balaguru



On Mar 13, 3:31 pm, karthikbalaguru <karthikbalagur...@gmail.com>
wrote:
> Hi, > > I am trying to get more info about External Memory Overlay . > In the document 'ADSP-218x External Overlay Memory By G. Y' from > IEEE , i find a reference to > a document " PM/DM Overlay & I/O Memory Expansion Board for ADSP 2181 > EZ-KIT Lite > written by G. Yi.". But i am unable to get this ( PM/DM Overlay & I/O > Memory Expansion Board > for ADSP 2181 EZ-KIT Lite written by G. Yi ) document from internet. > Does anyone has any link for this ? > > Is there any other link / pdf that talks in detail about this Memory > Overlay ? >
I collected info from internet . But, i am unable to find " PM/DM Overlay & I/O Memory Expansion Board for ADSP 2181 EZ-KIT Lite written by G. Yi." from internet. :(: ( http://www.cs.auckland.ac.nz/~alan/courses/os/book/1.Hist.0 8.memory.pdf " Even though we succeed in placing the different sections as part of single memory image, how is the particular section identified and loaded while execution ? " How do we keep track of what is where ? Clearly, we can no longer simply call, say, procedure B. Instead, we must first ask whether or not B is present in memory; if not, B must be loaded. Then B can be entered in the usual way. In practice, the ordinary programmer should not have to worry about the details, which are handled by software associated with the linker. The programmer does have to say which procedures are to be handled as overlays, because the decision must be based on an understanding of the flow of control through the programme, and that information is not necessarily available to the linker. The information is available to the compiler; should it be made available to the system as a whole, so that memory management strategies can be made more precise ? That's a matter to be decided when designing the operating system. If the information is required, it must be laid down as a system standard requirement. To our knowledge, no system has stipulated that compiler code files should contain information of this sort. " Is this feature good compared to virtual memory ? " ---> i) One difference between the different memory management techniques is in the binding time for addresses ( the time at which the actual address is determined ). ii) The major difference between overlay methods and the virtual memory systems which came later is that in virtual memory the transfer between memory and disc is managed by the operating system, but in an overlay system the responsibility for memory management lies with the programme itself. In SPRAA46.pdf i got the below info wrt TI ----------> Two steps are required to overlay sections: 1. The linker allocates the sections to a single memory range for running, but different memory ranges for loading. 2. The application, at runtime, manages the process of copying a section, as needed, from the load memory range to the run memory range. Implement step 1 with the UNION directive. Implementing step 2 requires three pieces of information about each section in the overlay: * Load address * Run address * Length The assembler and linker provide support for managing this information in various forms. Such support includes the .label directive, and the linker operators START(), END(), and SIZE(). While useful, these constructs impose a large responsibility upon the user. Further, some operations, such as splitting the load allocation over multiple memory ranges, are not even possible. Copy tables are a new and improved method for managing overlays. http://www.analog.com/UploadedFiles/Application_Notes/369485879 EE249v01.pdf has the below info wrt ADSP -------> In ADSP part of data / program code is loaded into internal memory during the booting process and the remaining part is placed in external memory. When program code (or data) in external memory has to be executed, it is loaded into internal memory and executed. The memory address range where the overlay function resides in the external memory is called "live address space", and the memory address where the program is executed in internal memory is called "run address space". The code responsible for transferring the data / program code from external memory to internal memory at runtime is called an overlay manager. It typically resides in a reserved space of the DSP's internal memory. The VisualDSP++ linker automatically generates overlay constants, which configure the BDMA parameters in the overlay manager. Each overlay has a word size, run-time address and live address used by the overlay manager to determine where the overlay resides and where it is executed. The linker-generated constants (where N is the ID# of the overlay) are: - _ov_startaddress_N (live address space) - _ov_word_size_run_N - _ov_word_size_live_N - _ov_runtimestartaddress_N (run addr. space) The linker is also responsible for resolving the symbol addresses of overlay data and labels. The Linker Description File (.LDF) in an overlay project has a section called a procedure linkage table (PLIT). The PLIT is a jump table in root memory constructed by the linker. Each call to an overlay section is replaced by a call to the PLIT. The PLIT {} commands provide a template by which the linker generates distinct assembly code for each overlay section. Listing 3 shows an example PLIT section that would be defined in the .LDF file. This section is defined only once in the .LDF file. However, the linker generates separate PLIT code for each overlay function call (pm_ovlay_1 and pm_ovlay_2). In other words, the PLIT {} command in an .LDF file inserts assembly instructions that handle calls to functions in overlays. There is a flowchart titled "Overlay Function Execution Flowchart", which gives an overall idea. In the main code, the overlay functions are called similar to ordinary (non-overlay) functions. For the overlay functions, the linker replaces the actual overlay function call with a call to the PLIT code generated for that particular overlay function. For example, the instruction: call Fast-LED-Blink; is replaced automatically by: call plt_1__.Fast_LED_Blink; Looking back at the code: plt_1__Fast_LED_Blink: AY0 = 0x0001; JUMP Overlay_Manager; In the AY0=0x0001 instruction, the content of the AY0 register in the plt_1__Fast_LED_Blink table is used as a pointer to access the linkergenerated data in the overlay manager. The next instruction (jump Overlay_Manager ()) transfers program control to the overlay manager. As explained earlier, the overlay manager code initiates a BDMA transfer of the Fast-LEDBlink overlay function from external memory to internal memory. Finally, the overlay manager executes a JUMP instruction to transfer program control to the Fast-LED-Blink() overlay function in run space. http://www.intel.com/education/highered/Embedded/lectu res/14_mem_mgmt.ppt has the below info in relation to ARM --------> Programmer breaks code into pieces that fit into RAM. Pieces, called overlays, are loaded and unloaded by the program .Does not require OS help Overlay manager loads an overlay segment when it is not in RAM. Supports Static and Dynamic Overlays. Static overlays - One root segment - 2 or more memory partitions (1 for the root partition which is always in RAM) - Within each partition, any number of overlay segments - Only 1 overlay segment can be in a partition at a given time - Application writer specifies what is in each partition and segment Dynamic Overlay - Include re-location information with each overlay segment - Have overlay manager allocate memory for an overlay segment when it is first loaded - Load and unload overlay segments by explicit calls to overlay manager - Each overlay segment is given its own name - linker links each as if it were in its own partition Problems with Overlays -> - Difficult for programmer to manage - Not general - management of resources (RAM) is an operating system issue But many embedded systems do not have the space or power for a "real" OS Solution -> Virtual Memory Why is VM important? - Cheap, no longer have to buy lots of RAM . - Removes burden of memory resource management from the programmer But, i am unable to find " PM/DM Overlay & I/O Memory Expansion Board for ADSP 2181 EZ-KIT Lite written by G. Yi." from internet. :(: ( Any links ? Thx in advans, Karthik Balaguru