Analog Devices ee-66 Application Notes

Engineer To Engineer Note EE-66

Notes on using Analog Devices’ DSP, audio, & video components from the Computer Products Division
Phone: (800) ANALOG-D or [phone], FAX: [phone], EMAIL: [e-mail]

memory contains the main program, an overlay manager

Using Memory Overlays

In order to reduce DSP system costs, many applications
use DSPs with smaller amounts of on chip memory—
placing much of the program code and data off chip. In
order to run the applications efficiently, memory
overlays are used.

This note discusses the concept of memory overlays and
how they are used with Analog Devices 32-bit SHARC
DSPs. The following topics and examples are discussed:

• “The Concept of Memory Overlays”

• “VisualDSP Overlay Support”

• “Basic Overlay Example”

function and two segments reserved for execution of
overlay program instructions.

• “Pre-Load Overlay Manager Example”

All of the code segments used in the following
discussion are parts of the two example programs that
appear at the end of this note.

The Concept of Memory Overlays

Memory overlays provide support for applications
whose entire program instructions and data do not fit in
the internal memory of the processor. In such a case,
program instructions and data are partitioned and stored
in external memory until they are required for program
execution. The partitions are referred to as memory
overlays and the routines that call and execute them
overlay managers.

Overlays are a “many to one” memory mapping system.
Several overlays “live” (or are stored) in unique
locations in external memory, but they “run” (or
execute) in a common location in internal memory.
Throughout this note, the storage location of overlays
are referred to as the “live” location, and the internal
location where instructions are executed are referred to
as the “run” (runtime) space. Figure 1 demonstrates the
concept of memory overlays. In Figure 1 there are two
memory spaces: internal and external. The external
memory is partitioned into five overlays. The internal

Figure 1. Memory Overlays

In this example, Overlay 1 and 2 share the same run
time location within internal memory. Overlays 3, 4 and
5 also share a common run time memory. If FUNC_B is
required, the overlay manager loads Overlay 2 in the
location within internal memory where overlay 2 is
designated to run. If FUNC_D is required, the overlay
manager loads Overlay 3 into its designated run time
memory.

The overlay manager is a user defined function
responsible for insuring that a required symbol
(function or data) within an overlay is in the run time
memory when it is needed. The transfer occurs using the
direct memory access (DMA) capability of the SHARC
processor. The overlay manager may also handle more
advanced functionality such as checking if the requested
overlay is already in run time memory, executing
another function while loading an overlay, and tracking
recursive overlay function calls.

a

VisualDSP Overlay Support

The overlay support provided by the 32-bit tools
includes the following:

• specification of the live and run location of each
overlay

• the generation of constants

overlays. The information provided by the linker
includes the following constants:

_ov_startaddress_N
_ov_endaddress_N
_ov_size_N
_ov_word_run_size_N
_ov_word_live_size_N
_ov_runtimestartaddress_N

• the redirection of overlay function calls to a jump
table

• the overlay manager.

The overlay support is provided by the linker and is
partially designed by the user in the linker description
file (LDF). The user specifies which overlays share run
time memory and which memory segments establish the
live and run space. Listing 1 shows the section of an
LDF defining two overlays

.pm_code
{ OVERLAY_INPUT

OVERLAY_OUTPUT(OVLY_one.ovl)
INPUT_SECTIONS(FUNC_A.doj(pm_code))

}>ovl_code

{ OVERLAY_INPUT

OVERLAY_OUTPUT(OVLY_two.ovl)
INPUT_SECTIONS(FUNC_B.doj(pm_code))

(FUNC_C.doj(pm_code))
}>ovl_code
}>pm_code

where N = the Overlay ID

Listing 2. Linker Generated Overlay Constants

Each overlay has a word size and an address which the
overlay manager uses to determine where the overlay
resides and where it is executed.

The overlay live and run word sizes are different if the
internal memory and external memory widths are
different. For example, the instruction word width of the
SHARC DSP is 48-bits. A system containing 32-bit
wide external memory requires data packing to store an
overlay containing instructions. The overlay live word
size (number of words in the overlay) is based on the
number of 32-bit words required to pack all of the 48­bit instructions.

Listing 1. Overlay Declaration in LDF

The overlay declaration in Listing 1 configures two
overlays to share a common run time memory space.

Figure 2. Example Overlay Run and Live Sizes

The first overlay, OVL_one, contains FUNC_A and
lives somewhere in memory segment ovl_code. The
second overlay, OVLY_two, contains functions

Figure 2 shows the difference between overlay live and
run size.

FUNC_B and FUNC_C. The second overlay also lives
in memory segment ovl_code. The common run time
location shared by overlays OVL_one and OVL_two is
within the memory segment pm_code.

• Overlays 1 and 2 are instruction overlays, with a
run word width of 48-bits.

• Because external memory is 32-bits, their live word
width is 32-bits.

The LDF provides the linker with direction on how to
configure the overlays as well as the information
necessary for the overlay manager routine to load the

• Overlay 1 contains one function with 16
instructions—overlay 2 contains two functions with
a total of 40 instructions.

EE-66 Page 2

Notes on using Analog Devices’ DSP, audio, & video components from the Computer Products Division
Phone: (800) ANALOG-D or [phone], FAX: [phone], EMAIL: [e-mail]

• The live word size for overlays 1 and 2 are 24 and

60 words respectively.

• The run word size for overlay 1 and 2 are 16 and

40 respectively.

The following code shows the value of all constants
generated by the linker for the example in Figure 2:

_ov_startaddress_1 = 0x20000

_ov_startaddress_1 = 0x20000

_ov_endaddress_1 = 0x20017 _ov_endaddress_1
= 0x20017

_ov_word_run_size_1 = 0x118

_ov_word_run_size_1 = 0x118

_ov_word_live_size_1 = 0x10

_ov_word_live_size_1 = 0x10

_ov_runtimestartaddress_1 = 0x8800

_ov_runtimestartaddress_1 = 0x8800

The .plt_FUNC_A is the entry in the PLIT containing
your defined instructions. These instructions prepare the
VisualDSP environment for the overlay manager to load
the overlay containing FUNC_A. The instructions
executed in the PLIT are specified within the LDF.

Listing 4 is an example PLIT definition from an LDF
file. In the example the register R0 is set to the value of
the overlay ID that contains the referenced symbol, and
register R1 is set to the run time address of the
referenced symbol. (PLIT_SYMBOL_OVERLAY_ID
and PLIT_SYMBOL_ADDRESS are linker key words).
The last instruction branches to the overlay manager.
The overlay manager uses the initialized registers to
determine which overlay to load, and where to jump to
execute the overlay function called.

Listing 3. Linker Generated Constants

Along with providing constants, the linker redirects
overlay symbol references within your code to the
overlay manager routine. This redirection is
accomplished using a procedure linkage table (PLIT).
The PLIT is essentially a jump table that executes user
defined code and then jumps to the overlay manager.
The linker replaces an overlay symbol reference
(function call) with a jump to a location in the PLIT.

PLIT code is defined within the linker description file
(LDF) by the programmer. This code prepares the
overlay manager to handle the overlay containing the
referenced symbol. The code generally initializes
registers to contain the overlay ID and the referenced
symbols run time address.

The following is an example call instruction to an
overlay function:

R0 = DM(I0,M3);
R1 = R0 * R2;
CALL FUNC_A; /* Call to function in overlay

*/
DM(I3,M3) = R1;

If FUNC_A is in an overlay, the linker replaces the
function call with the following instruction:

R0 = DM(I0,M3);
R1 = R0 * R2;
CALL .plt_FUNC_A; /* Call to PLIT entry */
DM(I3,M3) = R1;

PLIT
{

R0 = PLIT_SYMBOL_OVERLAY_ID
R1 = PLIT_SYMBOL_ADDRESS;

JUMP_OverlayManager

}

;

Listing 4. PLIT Definition in LDF

The linker expands the PLIT definition into individual
entries in a table. An entry is created for each overlay
symbol as shown in Figure 3. The redirect function calls
and the PLIT table for overlays 1 and 2 of the example.
For each entry the linker replaces the generic assembly
instructions with specific instructions (where
applicable). For example, the first entry in the PLIT
shown in Figure 3 is overlay symbol FUNC_A. The
linker replaces the constant name
PLIT_SYMBOL_OVERLAYID with the ID of the
overlay containing FUNC_A. The linker also replaces
the constant name PLIT_SYMBOL_ADDRESS with the
run time address of FUNC_A.

When the overlay manager subroutine is called via the
jump instruction of the PLIT table, R0 contains the
referenced function’s overlay ID, and R1 contains the
referenced function’s run time address. The overlay
manager subroutine uses the overlay ID and run time
address to load and execute the referenced function.

EE-66 Page 3

Notes on using Analog Devices’ DSP, audio, & video components from the Computer Products Division
Phone: (800) ANALOG-D or [phone], FAX: [phone], EMAIL: [e-mail]

Overlay 1

FUNC_A

Main: Plit_table:

call .plt_FUNC_A

.
.

.
call .plt_FUNC_C
call .plt_FUNC_B

.

.

Overlay 2
FUNC_B
FUNC_C

Internal Memory

.plt_FUNC_A: r0=0x00001;

r1=0x22000;
jump OverlayManager;

.plt_FUNC_B: r0=0x00002;

r1=0x22000;
jump OverlayManager;

.plt_FUNC_C: r0=0x00002;

r1=0x23000;
jump OverlayManager;

Figure 3. Expanded PLIT Table.

Overlay Manager

The overlay manager is a user defined routine that is
responsible for loading a referenced overlay function or
data buffer into internal memory (run time space). This
is done with the aid of the linker generated constants
and the PLIT commands. The linker generated constants
tell the overlay manager the addresses of the live
overlay, were the overlay resides for execution, and the
number of words in the overlay. The PLIT commands
tell the overlay manager such information as which
overlay is required and the run time address of the
referenced symbol.

The main objective of overlay managers is to transfer
overlays to their run time location when required.
However, overlay managers may also be required to:

• set up a stack to store register values

You may need your overlay manager to perform other
specialized tasks to satisfy the special needs of a given
application.

Overlay Manager Examples (ADSP­21065L)

The following sections discuss two different overlay
managers. The first always executes an overlay function
immediately after the overlay has been transferred—it
only transfers the overlay at the time execution is
requested. In this case, the core is idle while the transfer
occurs.

The second overlay manager is designed to load one
overlay while executing a function from a previously
loaded overlay. This reduces the core idle time that
occurs while the core waits for the overlay function to
load for execution.

The two example overlay mangers are demonstrated on
the same application. The application is a 256 point
radix-2 FFT.

The FFT implementations of the two examples are the
same except for the mapping of functions to overlays.
The main FFT routine is composed of four functions:
fft_first_2_stages, fft_middle_stages, fft_next_to_last
and fft_last_stage. The first example consists of two
overlays, each containing two functions, and the second
example consists of four overlays, each containing one
function. The allocation of functions to overlays and the
overlay manager for each example are explained.

in some cases stacks may be corrupted by the
overlay

• check if a referenced symbol has already been
transferred into its runtime space as a result of a
previous reference

if the overlay is already in internal memory, the

Basic Overlay Example

This example has two overlays, each of which contain
two functions. Overlay 1 contains the functions
fft_first_two_stages and fft_last_stage. Overlay 2
contains functions fft_middle_stages and
fft_next_to_last. In this example the overlay manager:

overlay transfer is bypassed and execution of the
overlay routine can begin immediately.

• load an overlay while executing a function from a
second overlay (or a non overlay function).

1. creates and maintains a stack for the registers it uses

2. determines if the referenced function is in internal
memory

3. sets up a DMA transfer

EE-66 Page 4

Notes on using Analog Devices’ DSP, audio, & video components from the Computer Products Division
Phone: (800) ANALOG-D or [phone], FAX: [phone], EMAIL: [e-mail]

4. flushes the cache and executes the referenced
function

The following code segment from the LDF represents
the overlay definitions of Example 1. Several code
segments for the LDF and the Overlay Manager are
displayed and explained in the text.

OVERLAY_INPUT

{
ALGORITHM(ALL_FIT)
OVERLAY_OUTPUT(fft_one.ovl)
INPUT_SECTIONS(

Fft_1st_last.doj(pm_code) )
PACKING(12 B1 B2 B3 B4 B0 B11 B12 B5 B6 B0

B7 B8 B9 B10 B0)
} >ovl_code // Overlay to live in section

ovl_code

OVERLAY_INPUT
{
ALGORITHM(ALL_FIT)
OVERLAY_OUTPUT(fft_two.ovl)
INPUT_SECTIONS( Fft_mid.doj(pm_code)

)
PACKING(12 B1 B2 B3 B4 B0 B11 B12 B5 B6 B0

B7 B8 B9 B10 B0)

} >ovl_code // Overlay to live in
section ovl_c

Listing 5. FFT Overlay Example 1

Two overlays are defined: fft_one.ovl and fft_two.ovl.
Both overlays live in the segment ovl_code defined in
the memory section of the LDF and run in section
pm_code. All instruction and data defined in segments
named pm_code within the file Fft_1st_last.doj are part
of overlay fft_one.ovl. All instructions and data defined
in segments named pm_code within the file Fft_mid.doj
are part of overlay fft_two.ovl. The result is two
functions within each overlay.

The first and the last functions called are in overlay
fft_one. The two middle functions called are in overlay
fft_two. When the first function is referenced during
code execution, fft_one, overlay id=1 is transferred to
internal memory. When the second function is
referenced, fft_two, overlay id=2 is transferred to
internal memory. Since the third function is in overlay
fft_two, when it is referenced the overlay manager
recognizes that it is already in internal memory and an
overlay transfer does not occur. Finally, when the last

function is referenced, overlay fft_one, overlay id=1 is
again transferred to internal memory for execution. The
following code segment calls the four functions of FFT:

fftrad2:

call fft_first_2_stages (db);
call fft_middle_stages (db);
call fft_next_to_last (db);
call fft_last_stage (db);

wait: idle;

jump wait;

The linker replaces the overlay function calls with calls
to the appropriate entry in the procedure linkage table
(PLIT). For this example only three instructions are
placed in each entry of the PLIT as shown below:

PLIT

{

R0 = PLIT_SYMBOL_OVERLAYID;
R1 = PLIT_SYMBOL_ADDRESS;
JUMP _OverlayManager;

}

Register R0 contains the overlay ID that occupies the
referenced symbol and register R1 contains the run time
address of the referenced symbol. The final instructions
jump the program counter (PC) to the overlay manager
routine. The overlay manager routine uses the overlay
ID in conjunction with the overlay constants generated
by the linker to transfer the proper overlay into internal
memory. Once the transfer is complete, the overlay
manager sends the PC to the address of the referenced
symbol stored on R1.

The linker generates the following constants used by the
overlay manager:

.EXTERN _ov_word_run_size_1;
.EXTERN _ov_word_run_size_2;
.EXTERN _ov_word_live_size_1;
.EXTERN _ov_word_live_size_2;
.EXTERN _ov_startaddress_1;
.EXTERN _ov_startaddress_2;
.EXTERN _ov_runtimestartaddress_1;
.EXTERN _ov_runtimestartaddress_2;

These constants supply the overlay manager with:

EE-66 Page 5

Notes on using Analog Devices’ DSP, audio, & video components from the Computer Products Division
Phone: (800) ANALOG-D or [phone], FAX: [phone], EMAIL: [e-mail]

1. the size of the overlays, using both run time word
sizes and live word sizes,

2. the starting address of the live space

3. the starting address of the run space.

The overlay manager code places the constants in arrays
as shown below. The arrays are referenced by using the
overlay ID as the index to the array. The index or ID is
stored in a modify (m#) register and the beginning
address of the array is stored in the (i#) register.

.VAR liveAddresses[2] =
_ov_startaddress_1, _ov_startaddress_2;

.VAR runAddresses[2] =
_ov_runtimestartaddress_1,

_ov_runtimestartaddress_2;
.VAR runWordSize[2] =

_ov_word_size_run_1, _ov_word_size_run_2;
.VAR liveWordSize[2] =

_ov_word_size_live_1, _ov_word_size_live_2;

Before preparing the DMA, the overlay manager stores
the values contained in each register it uses onto a
runtime stack. The stack stores the values of all data
registers, address generator registers and any other
registers required by the overlay manager.

The overlay manager also stores the ID of an overlay
currently in internal memory. When an overlay is
transferred to internal memory the overlay manager
stores the overlay ID in internal memory in the buffer
labeled ov_id_loaded. Before another overlay is
transferred, the overlay manager compares the required
overlay ID with that stored in buffer ov_id_loaded. If
they are equal the required overlay is already in internal
memory and a transfer is not required. The PC is sent to
the proper location to execute the referenced function. If
they are not equal, the value in ov_id_loaded is updated
and the overlay is transferred.

/* Store values of registers used by the
overlay manager in to the */

/* software stack. */
dm(ov_stack)=i8;
dm(ov_stack+1)=m8;
dm(ov_stack+2)=l8;
dm(ov_stack+3)=r2;

/* Use the overlay id as an index (must
subtract one) */

R0=R0-1; /* Overlay ID -1 */
m8=R0; /* Offset into the arrays

containing linker defined overlay
constants.*/

r2=dm(ov_id_loaded);
r0=r0-r2;
if EQ jump continue;
dm(ov_id_loaded)=m8;

r0=i0; dm(ov_stack+4)=r0;
r0=m0; dm(ov_stack+5)=r0;
r0=l0; dm(ov_stack+6)=r0;

The overlay manager uses the value of the linker
generated constants to set up the DMA transfer as
shown in the following code segment of the overlay
manager function. The constants are in arrays as
previously described. The index registers I8 and I7
point to the first location of the arrays. The overlay ID
is stored in the modify registers M8 and M7. The index
and modify registers together in DAG instructions read
the appropriate elements from the arrays.

The following segment of the overlay manager function
creates the runtime stack, stores the overlay ID in a
modify register and checks the overlay ID stored in
ov_id_loaded:

/* _overlayID has been defined as R0. R0 is
set in the PLIT of LDF. */

/* Set up DMA transfer to internal memory
through the external port. */

EE-66 Page 6

Notes on using Analog Devices’ DSP, audio, & video components from the Computer Products Division
Phone: (800) ANALOG-D or [phone], FAX: [phone], EMAIL: [e-mail]

/* Get overlay run and live addresses from
memory and use to */

/* set up the master mode DMA. */
i8 = runAddresses;
i0 = liveAddresses;

r0=0; /* Disable DMA */
dm(DMAC0) = r0;

/* Set DMA external pointer to overlay live
address */

r0=dm(m0,i0);
dm(EIEP0)=r0;

/* Set DMA internal pointer to overlay run
address */

r0=pm(m8,i8);
dm(IIEP0)=r0;

dm(DMAC0)=r0;

On completion of the transfer the overlay manager
restores register values from the runtime stack, flushes
the cache and then jumps the PC to the run time location
of the referenced function. It is very important to flush
the cache before jumping to the referenced function
because when code is replaced or modified, incorrect
code execution may occur if the cache is not flushed. If
the program sequencer searches the cache for an
instruction and an instruction from the previous overlay
is in the cache, the cached instruction may be executed
rather than receiving the expected cache miss. In
summary, the overlay manager routine does the
following:

1. maintains a runtime stack for registers being used by
the overlay manager

i0=runWordSize; /* Number of words stored
in internal memory */

/* Most likely the word size will be 48
bits for instructions. */

/* Set DMA external modifier */
r0=1;
dm(EMEP0)=r0;

i8=liveWordSize; /* Number of words
stored in external memory */

/* Most likely the word size will be 32 or
16 */

/* bits for external storage. */

/* Set DMA internal modify to 1 */
dm(IMEP0)=r0;

/* Set DMA internal count to Overlay run
size. */

r0=dm(m0,i0);
dm(CEP0)=r0;

/* Set DMA external count to Overlay live
size. */

r0=pm(m8,i8);
dm(ECEP0)=r0;
/* DMA enabled, instruction word, Master,

48-32 packing */
r0=0x2e1;

2. compares the requested overlay’s ID with that of the
previously loaded overlay (stored in buffer
ov_id_loaded)

3. sets up the DMA transfer of the overlay (if it is not
already in internal memory)

4. jumps the PC to the run time location of the
referenced function.

These are the basic tasks that are performed by an
overlay manager. More sophisticated overlay managers
may be required for individual applications.

Pre-Load Overlay Manager Example

The second example incorporates the ability to transfer
one overlay to internal memory while the core executes
a function from another overlay. Instead of the core
sitting idle while the overlay DMA transfer occurs, the
core enables the DMA then begins executing another
function.

This example uses the concept of overlay function
loading and executing. A function load is a request to
load the overlay function into internal memory but not
execute the function. A function execution is a request
to execute an overlay function that may or may not be in
internal memory at the time of the execution request. If
the function is not in internal memory a transfer must
occur before execution.

EE-66 Page 7

Notes on using Analog Devices’ DSP, audio, & video components from the Computer Products Division
Phone: (800) ANALOG-D or [phone], FAX: [phone], EMAIL: [e-mail]

There are several circumstances under which an overlay
transfer can be in progress while the core is executing
another task. Each circumstance can be labeled as
deterministic or non-deterministic. A deterministic
circumstance is one where you know exactly when an
overlay function is required for execution. A non­deterministic circumstance is one where you cannot
predict when an overlay function is required for
execution. For example, a deterministic application may
consist of linear flow code except for function calls. A
non-deterministic example is an application with calls to
overlay functions within an interrupt service routine
where the interrupt occurs randomly.

The following example contains deterministic overlay
function calls. The time of overlay function execution
requests are known as are the number of cycles required
to transfer an overlay. Therefore, an overlay function
load request can be placed such that the transfer is
complete by the time the execution request is made. The
next overlay transfer (from a load request) can be
enabled by the core and the core can execute the
instructions leading up to the function execution
request.

Since the linker handles all overlay symbol references
in the same way (jump to PLIT table then overlay
manager) it is up to the overlay manager to distinguish
between a symbol reference requesting the load of an
overlay function and a symbol reference requesting the
execution of an overlay function. In the example the
overlay manager uses a buffer in memory as a flag to
indicate whether the function call (symbol reference) is
a load or an execute request. The overlay manager first
determines if the referenced symbol is in internal
memory. If not it sets up the DMA transfer. If the
symbol is not in internal memory and the flag is set for
execution, the core waits for the transfer to complete (if
necessary) and then executes the overlay function. If the
symbol is set for load, the core returns to the
instructions immediately following the location of the
function load reference.

Every overlay function call requires initializing the
load/execute flag buffer. In the example, the function
calls are delayed branch calls. The two slots in the
delayed branch contain instructions to initialize the flag
buffer. Register R0 is set to the value that is placed in

the flag buffer, and the value in R0 is stored in memory;
1 indicates a load and 0 indicates an execution call. At
each overlay function call the load buffer must be
updated. The following code is from the main FFT
subroutine. Each of the four function calls are execution
calls so the pre-fetch (load) buffer is set to zero. The
flag buffer in memory is read by the overlay manager to
determine if the function call is a load or an execute.

call fft_first_2_stages (db);

r0=0;
dm(prefetch) = r0;

call fft_middle_stages (db);

r0=0;
dm(prefetch) = r0;

call fft_next_to_last (db);

r0=0;
dm(prefetch) = r0;

call fft_last_stage (db);

r0=0;
dm(prefetch) = r0;

The next set of instructions represents a load function call.

call fft_middle_stages (db); /* This
function call pre loads */

r0=1; /* the function into
the overlay run memory. */

dm(prefetch) = r0; /* Set prefetch flag
to 1 to indicate a load. */

The implementation executes the first function and
transfers the second function and so on. In this
implementation each function resides in a unique
overlay and requires reserving two run time locations;
while one overlay is loading into one run time location,
a second overlay function is executing in another run
time location.

The following code segment allocates the functions to
overlays and forces two runtime locations.

OVERLAY_INPUT
{

ALGORITHM(ALL_FIT)
OVERLAY_OUTPUT(fft_one.ovl)

INPUT_SECTIONS( Fft_ovl.doj(pm_code)
)

PACKING( 12 B1 B2 B3 B4 B0 B11 B12 B5

B6 B0 B7 B8 B9 B10 B0)
} >ovl_code // Overlay to live in section

ovl_code

EE-66 Page 8

Notes on using Analog Devices’ DSP, audio, & video components from the Computer Products Division
Phone: (800) ANALOG-D or [phone], FAX: [phone], EMAIL: [e-mail]

OVERLAY_INPUT
{

ALGORITHM(ALL_FIT)
OVERLAY_OUTPUT(fft_three.ovl)
INPUT_SECTIONS(

Fft_ovl.doj(pm1_code) )

PACKING( 12 B1 B2 B3 B4 B0 B11 B12 B5

B6 B0 B7 B8 B9 B10 B0)
} >ovl_code // Overlay to live in section

ovl_code

INPUT_SECTIONS(ovly_mgr.doj(pm_code))

OVERLAY_INPUT
{

ALGORITHM(ALL_FIT)
OVERLAY_OUTPUT(fft_two.ovl)
INPUT_SECTIONS(

Fft_ovl.doj(pm3_code) )

PACKING( 12 B1 B2 B3 B4 B0 B11 B12 B5

B6 B0 B7 B8 B9 B10 B0)
} >ovl_code // Overlay to live in section

ovl_code
OVERLAY_INPUT
{

ALGORITHM(ALL_FIT)
OVERLAY_OUTPUT(fft_last.ovl)
INPUT_SECTIONS(

Fft_ovl.doj(pm2_code) )

PACKING( 12 B1 B2 B3 B4 B0 B11 B12 B5

B6 B0 B7 B8 B9 B10 B0)
} >ovl_code // Overlay to live in section

ovl_code

jumps to the runtime location of the called function. If
the overlay is not in internal memory, a DMA transfer is
initiated and the core waits for the transfer to complete.

The complete overlay manager function is shown in the
Overlay Example 2 at the end of this note. The overlay
manager pushes the appropriate registers on the runtime
stack. It checks to see if the requested overlay is
currently in internal memory. If not, it sets up the DMA
transfer. It then checks to see if the function call is a
load or an execution call. If it is a load, it begins the
transfer and returns the PC back to the instruction
following the call. If it is an execution call the core is
idle until the transfer completes (if the transfer was
necessary) and then jumps the PC to the runtime
location of the function.

The overlay managers in these examples are used
universally. Specific applications may require some
modifications. These modifications may allow for the
elimination of some instructions. For instance, if your
application allows for the free use of registers, you may
not need a runtime stack.

The following examples are intended to help explain the
capabilities of overlays so you can get started on your
own applications quickly.

The first and third overlays share one runtime location
and the second and fourth overlays share the second
runtime location. By placing an input section between
overlay declarations, multiple runtime locations are
allocated.

The overlay manager requires modification from that of
example one. Additional instructions are included to
determine if the function call is a load or an execution
call. If the function call is a load the overlay manager
initiates the DMA transfer, then jumps the PC back to
the location where the call was made. If the call is an
execution call the overlay manager determines if the
overlay is currently in internal memory. If so, the PC

EE-66 Page 9

Notes on using Analog Devices’ DSP, audio, & video components from the Computer Products Division
Phone: (800) ANALOG-D or [phone], FAX: [phone], EMAIL: [e-mail]

Engineer To Engineer Note EE-66

Notes on using Analog Devices’ DSP, audio, & video components from the Computer Products Division
Phone: (800) ANALOG-D or [phone], FAX: [phone], EMAIL: [e-mail]

Overlay Example 1

Linker Description File

ARCHITECTURE(ADSP-21065L)
//
// ADSP-21065L Memory Map:
// -----------------------------------------------­// Internal memory 0x0000 0000 to 0x0007 ffff
// -----------------------------------------------­// 0x0000 0000 to 0x0000 00ff IOP Regs
// 0x0000 0100 to 0x0000 01ff IOP Regs of Processor ID 001
// 0x0000 0200 to 0x0000 02ff IOP Regs of Processor ID 002
// 0x0000 0300 to 0x0000 07ff Reserved
//Block 0 0x0000 8000 to 0x0000 9fff Normal Word (32/48) Addresses
// (0x0000 8000 to 0x0000 97ff) 48-bit words
// (0x0000 8000 to 0x0000 9fff) 32-bit words
// 0x0000 A000 to 0x0000 Bfff Reserved
//Block 1 0x0000 C000 to 0x0000 Dfff Normal Word (32/48) Addresses
// (0x0000 C000 to 0x0000 Cfff) 48-bit words
// (0x0000 C000 to 0x0000 Dfff) 32-bit words
// 0x0000 E000 to 0x0000 ffff Reserved
//Block 0 0x0001 0000 to 0x0001 3fff Short Word (16) Addresses
// 0x0001 4000 to 0x0001 7fff Reserved
//Block 1 0x0001 8000 to 0x0001 Bfff Short Word (16) Addresses
// 0x0001 C000 to 0x0001 ffff Reserved
// -----------------------------------------------­// External memory 0x0002 0000 to 0x03ff ffff
// -----------------------------------------------­// External Bank 0 0x0002 0000 to 0x00ff ffff
// External Bank 1 0x0100 0000 to 0x01ff ffff
// External Bank 2 0x0200 0000 to 0x02ff ffff
// External Bank 3 0x0300 0000 to 0x03ff ffff
//
// This architecture file allocates:
// Internal
// External

a

SEARCH_DIR( "$ADI_DSP\21k\lib" )

$LIBRARIES = lib060.dlb ;

$OBJECTS = $COMMAND_LINE_OBJECTS ;

//MAP(fft_ovly.map)

// Memory architecture description for FFT example on a 21062.
// 256 48-bit words for interrupt vector table (reset vector location).
// 1792 48-bit words of program memory for code storage.
// 2k 32-bit words of internal program memory for data storage.
// 2k 32-bit words of second segment of internal program memory for data

storage.
// 4k 32-bit words of internal data memory for data storage.
// 4k 32-bit words of second segment of internal data memory for data storage.

// 4k 48-bit words of external memory for program overlay

MEMORY
{

isr_tabl { TYPE(PM RAM) START(0x00008000) END(0x000080FF) WIDTH(48) }
pm_code { TYPE(PM RAM) START(0x00008100) END(0x000087ff) WIDTH(48) }

pm_data { TYPE(PM RAM) START(0x00009000) END(0x000097ff) WIDTH(32) }
pm_idat { TYPE(PM RAM) START(0x00009800) END(0x00009fff) WIDTH(32) }

dm_data { TYPE(DM RAM) START(0x0000C000) END(0x0000Cfff) WIDTH(32) }
dm_rdat { TYPE(DM RAM) START(0x0000D000) END(0x0000Dfff) WIDTH(32) }

ovl_code { TYPE(DM RAM) START(0x00020000) END(0x00020FFF) WIDTH(32) }

}// End MEMORY

// The global PLIT to be used whenever a PROCESSOR or OVERLAY specific PLIT
description

// is not provided. The PLIT initializes a register to the overlay id and the
overlay

// runtime address of the symbol called. Be sure the registers used in the PLIT
do not

// contain values which cannot be overwritten.

EE-66 Page 11

Notes on using Analog Devices’ DSP, audio, & video components from the Computer Products Division
Phone: (800) ANALOG-D or [phone], FAX: [phone], EMAIL: [e-mail]

PLIT
{

R0 = PLIT_SYMBOL_OVERLAYID;
R1 = PLIT_SYMBOL_ADDRESS;
JUMP _OverlayManager;

}

Processor Fft

{
LINK_AGAINST($COMMAND_LINE_LINK_AGAINST) // Link against all doj files on

// command line
OUTPUT( $COMMAND_LINE_OUTPUT_FILE )
SECTIONS
{
.isr_tabl

{
INPUT_SECTIONS( Fftrad2n.doj(isr_tabl) ) // ISR table placement
} >isr_tabl

.pm_code
{

INPUT_SECTIONS(Fftrad2n.doj(pm_code) ovly_mgr_65L.doj(pm_code)

$LIBRARIES(pm_code))

// Declare which functions reside in which overlay
// The overlays have been split up into either different
// segments if in the same file or different files.
// The overlays declared in this section, pm_code, will run
// in pm_code.

OVERLAY_INPUT
{

ALGORITHM(ALL_FIT)
OVERLAY_OUTPUT(fft_one.ovl)
INPUT_SECTIONS( Fft_1st_last.doj(pm_code) )

PACKING(12 B1 B2 B3 B4 B0 B11 B12 B5 B6 B0 B7 B8 B9 B10 B0)
} >ovl_code // Overlay to live in section ovl_code
OVERLAY_INPUT
{

EE-66 Page 12

Notes on using Analog Devices’ DSP, audio, & video components from the Computer Products Division
Phone: (800) ANALOG-D or [phone], FAX: [phone], EMAIL: [e-mail]