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
Reply by karthikbalaguru●March 13, 20082008-03-13
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