Analog Devices EE151 Application Notes

Engineer To Engineer Note EE-151

Technical Notes on using Analog Devices’ DSP components and development tools

Phone: (800) ANALOG-D, FAX: [phone], EMAIL: [e-mail], FTP: ftp.analog.com, WEB: www.analog.com/dsp

Copyright 2002, Analog Devices, Inc. All rights reserved. Analog Devices assumes no responsibility for customer product d esign or the use or a pplication of custo me rs’ products o r for
any infringements of patents or rights of others which may result from Analog Devices assistance. All trademarks and logos are property of their respective holders. Information
furnished by Analog Devices Applications and Development Tools Engineers is believed to be accurate and reliable, however no responsibility is assumed by Analog Devices rega rding
the technical accuracy of the content provided in all Analog Devices’ Engineer-to-Engineer Notes.

only requiring one selected filter response at any

Implementing Software Data
Overlays for the ADSP-21161
Using the EZ-KIT Lite

Last Modified: 1/25/02

Contributed by: John Tomarakos

Overview

In many DSP applications, there may be system
memory requirements where the DSP
programmer wishes to assign a section of
internal “scratchpad” memory to use for
multiple temporary variables, then store the
variables back to external SDRAM or FLASH
memory for later usage. Often, variables arrays,
or lookup tables are only used during a small
fraction of time of the DSP’s processing, but
they often can take up a large portion of the
internal memory space of the DSP. Or, an audio
system developer may want to copy a block of
recorded audio samples to storage and then
retrieve the data for playback at a later time.
Once the audio data is stored, the internal
memory is free to use for other operations.
Another example could be an application which
requires using a temporary section of shared
memory for sine/cosine lookup tables or FFT
twiddle factors which are only required when
the FFT algorithm is executed, but then perhaps
during the FFT algorithm’s “down time” the
user wants to use the same memory for loading
one out of a number of stored sets of filter
coefficients for other post-filtering operations,

given time upon request from a user-controlled
interface. And finally, another DSP application
could be a music synthesizer, where the DSP is
performing a wavetable synthesis or sample
playback algorithm, and when the musician
selects a new “instrument” on command from a
set of control knobs, telling the system’s host
microcontroller to direct the DSP to download a
new block of wavetable data to the same section
of memory to generate the new sound. To
support such memory management tasks we can
set up what is called a “soft data overlay” to
automate the process of reusing a small section
of internal memory efficiently.

Store Data x[ ]

ADSP­21161
Internal
Memory

Swap data buffers x[ ] & w[ ] to/from
same shared internal memory block

External
SDRAM
or FLASH

x[n]

w[n]

Load Data w[ ]

FIGURE 1: Basic Data Overlay Concept

Figure 1 demonstrates a basic concept of a soft
data overlay, where information is loaded from
external memory to a shared section if internal
memory, while the previous data is stored
simultaneously to external memory and recalled
at a later time. This data overlay technique may
provide support for applications where the total
amount of data memory required is greater than

a

the available amount of internal data memory
provided by the processor, and the user is
seeking a way to “make the code and data fit
into the DSP’s internal memory space.”

The data overlay “save-and-restore” approach
may be desirable because by keeping all the data
buffers outside in the external memory and
operating on them there, it can result in a
significant reduction in available MIPS, due to
external waitstates or SDRAM latencies. MAC
operations can slow down significantly if the
delay line data or filter coefficients are accessed
from external memory, and the cycle overhead
can also increase significantly depending on
SDRAM latencies if we access non-consecutive
addresses. However, the SHARC processor
may often provide much available non-utilized
I/O processor bandwidth to take advantage of.
During these unused IOP bus cycles it would be
desirable to initiate data overlay transfers which
would execute with zero-overhead to internal
memory from SDRAM, or vice versa. Perhaps
the application is performing 5 active serial port
DMAs or link port DMAs, but this still provides
much IOP bus bandwidth available for quick
100 MHz external port SDRAM block transfers
on a dedicated EPBx DMA channel. 100 MHz
SDRAM DMA transfer throughput with 32-bit
fixed or floating point data can make the use of
data overlays attractive because the SDRAM
controller is able to sustain 100 MHz throughput
in consecutive reads/writes to the same page in
SDRAM (of course, as long as there is no other
core, host or EPBx DMA activity to slow down
access to the external bus). Therefore, the DSP
core can initiate a fast data overlay load, then go
and execute another task in internal instruction
space while the data is quickly loaded by the I/O
processor in the background with no core
intervention.

The advantage of data overlays to SDRAM is
that SDRAM provides a low-cost, bulk-storage,

high-speed interface to move the blocks of data
at up to 100 MHz throughput. The disadvantage
is that a system requires external memory in
addition to a boot flash device, increasing
system cost. If the system does not necessarily
need fast access to swap data blocks, an external
boot flash used for data overlays can could meet
system cost constraints. It is possible to still use
the unused upper sectors of the flash device
which is not used for boot program storage to be
able to temporarily load and store samples, or
filter coefficients or data tables. In this case, we
can set up data overlays with the necessary 8-bit
DMA packing and flash memory commands.
Table 1 below shows the tradeoffs for
implementing data overlays in flash or SDRAM.

TABLE 1. DATA OVERLAY SDRAM/Boot

FLASH comparisons:

MEMORY
Type

SDRAM

SBSRAM

FLASH

Data Overlay
Throughput

100 MHz
transfer
throughput
possible

50 MHz fixed
transfer
throughput

Could require
up to 7 CLKIN
waitstates,
slowest data
throughput

Bus
Width

32-bit

32-bit

8/16-bit

System Cost

May require both
SDRAM and boot
memory

May require both
SBSRAM and
boot memory

Only Boot Flash
Required, can be
mapped to both
/BMS and /MSx
space

So then the question becomes, how can we use
the current VisualDSP++ code generation tools
to provide the ability to load and store data
variables and buffers? As one suggested
solution, this Engineer-To-Engineer Note
discusses a simple technique using Analog
Devices’ Visual DSP++ 2.0 tools and it’s code
overlay support to implement “Data Software
Overlays.”

EE-151 Page 2

Technical Notes on using Analog Devices’ DSP components and development tools

Phone: (800) ANALOG-D, FAX: [phone], EMAIL: [e-mail], FTP: ftp.analog.com, WEB: www.analog.com/dsp

The source code listing in this EE-Note
demonstrates a way to accomplish swapping
data to and from SDRAM using the 21161 EZ­KIT Lite Evaluation Platform (Figure 2) as the
demonstration vehicle. For more information on
implementing software overlays, refer to EE­Note # 66: Using Memory Overlays. Keep in
mind the example demonstrated here is just a
sample of one process that may be required in
an actual application. Depending on the user’s
application, further customization of the overlay
process may be required to suit your needs
(through the modification of the overlay
manager discussed later in this document).

FIGURE 2: ADDX-21161-EZ-LITE

The current VisualDSP 2.0++ tools support
software code (instruction) overlays but no
direct data overlay support built into the linker.
By using some of the existing code overlay
support methods supplied with our tools, we can
alternatively develop a data overlay routine
which copy the data variables and buffers from
external memory to internal memory, and then
back to the external memory after the variables
have been modified. This is taken care by a
routine called the data overlay manager, but
when using data overlays (in the current
VisualDSP++ 2.0 toolset) the data movement

process is still required to be initiated by the
programmer in order to start the DMA transfer
(vs. code overlays, which are a more automatic
process with the linker generating the necessary
jump instructions via access to a jump table).

As mentioned earlier, it is also possible for the
ADSP-21161 programmer to perform data
overlays to flash memory. This can be done on
the flash memory used on the EZ-KIT Lite, by
simply modifying the overlay manager to
perform 8-bit DMA accesses to flash memory
while including all of the necessary
housekeeping flash instructions in with the data
overlay manager. For more information on
programming the EZ-KIT flash, refer to EE­150: In-circuit programming a boot-image into
the FHASH on the ADDS-21161N-EZLITE.
Look for an additional update to this EE-NOTE
to include data overlays to/from flash memory
using the EZ-KIT Lite.

SDRAM Data Overlay System Design
Assembly and C Examples:

External
Memory

Data Overlay 1

Data Overlay 2

Data Overlay 3

Overlay

Data Overlay 4

Overlay 5

Overlay 6

X[1000]
Y[1000]

M[1000]
N[1000]

P[1024]

FUNC_

Q[1024]

FUNC_

U[512]

V[512]

FUNC_D
FUNC_E

FUNC_F
FUNC_G

Internal

Memory

(non-overlay code)
Interrupt Vector Table
Main code
PLIT
overlay manager

Run Space for

Overlays 5 an d 6

DM data “Run Space” for

Data Overlays 1 and 2

DM data “Ru n Space” for

Data Overlays 3 and 4

FIGURE 3: Data Overlay Live and Run

Segments

Like code overlays, data overlays are a “many to
one” memory mapping system. For example,
Figure 3 shows how several data overlays “live”

EE-151 Page 3

Technical Notes on using Analog Devices’ DSP components and development tools

Phone: (800) ANALOG-D, FAX: [phone], EMAIL: [e-mail], FTP: ftp.analog.com, WEB: www.analog.com/dsp

(or are stored) in unique external memory
locations, but then “run” (or are
executed/accessed) in a common shared location
in internal memory. This demonstrates an
application in which there are six “live”
segments in external SDRAM. Four segments
are data overlay segments, while the other two
are code overlay segments. There are also two
data overlay “run” segments and one code
overlay “run” segment which is shared between
the overlays in the internal memory of the DSP.

The data overlay concept is demonstrated in
both an assembly version and a C version.
Figures 3 and 4 show the project files for both
the assembly and C implementations. Both
projects consist of the linker description file,
DSP system initialization files, the main routine,
overlay, data files, macros/functions, three
overlay variable declaration files, the data
overlay manager and the data overlay test
routine.

FIGURE 5. Project Files for C Language
Data Overlay Example

FIGURE 4. Project Files for Assembly

Language Data Overlay Example

In these VisualDSP ++ project files, we
implement three data overlay segments which
share the same internal memory run space. The
example defines six 1K buffers x[], y[], m[],
n[], p[], q[] which will share a 2 k segment of
internal memory run space.

In the ADSP-21161’s 1 M-bit internal memory,
we would allocate at least 2K words of internal
memory in BLOCK1 as the “run” time memory
for the data by defining this memory segment in
the MEMORY{} section of the LDF file as
follows:

EE-151 Page 4

Technical Notes on using Analog Devices’ DSP components and development tools

Phone: (800) ANALOG-D, FAX: [phone], EMAIL: [e-mail], FTP: ftp.analog.com, WEB: www.analog.com/dsp

rundmda { TYPE(DM RAM) START(0x00051000)

END(0x00051fff) WIDTH(32) }

Next we want to define our “live” space in
SDRAM mapped to bank0, where our data
overlays will be stored. This is also defined in
the MEMORY {} section of the LDF file:

ovlydmda { TYPE(DM RAM) START(0x00200000)

END(0x0020FFFF) WIDTH(32) }

Each buffer within the two data overlay files are
defined with a length of 1000 words, and each
element contains 32 bit words. These are shown
in the two source listings below. Note that
Buffers x[] and m[] and q[] contain some
initialized values.

LISTING 1: Data Overlay Declarations for

ASM Example

dm1_overlay.asm

.SEGMENT/DM run_dmda;
.GLOBAL x, y;

.VAR x[1000]="sine1000.dat";
.VAR y[1000];

.ENDSEG;

dm2_overlay.asm

.SEGMENT/DM run_dmda;
.GLOBAL m, n;

.VAR m[1000]="sawtooth1000.dat";
.VAR n[1000];

.ENDSEG;

dm3_overlay.asm

.SEGMENT/DM run_dmda;
.GLOBAL p, q;

.VAR p[1000]="square1000.dat";
.VAR q[1000];

.ENDSEG;

LISTING 2: Data Overlay Declarations for

the C Example

dm1_overlay.c

/* Data Overlay 1 */

float sinetbl[1000] =

{

#include "sine1000.dat"

};

float y_out[1000];

dm2_overlay.c

/* Data Overlay 2 */

float sawtbl[1000] =

{

#include "sawtooth1000.dat"

};

float z_out[1000];

dm3_overlay.c

/* Data Overlay 3 */

float squartbl[1000] =

{

#include "square1000.dat"

};

float q_out[1000];

The objective in the ADSP-21161 data overlay
C and assembly tests shown here is to load in
the data buffers x[] and y[] inside to the internal
run space, copy the data from buffer x[] to
buffer y[], then store the current contents of
both buffers back to external SDRAM memory.
Once this process is over the run time memory
can be freed. Thus, this same process is then
repeated for buffers m[] and n[], where buffers
m[] and n[] are loaded to the same run space
previously used by the x[] and y[] buffers.
Buffer m[] is copied to buffer n[] and both
buffers are stored back to SDRAM for later use.
And again, the same process is repeated a third
time for buffers p[] and q[]. This process is
repeated over and over again, while the LED

EE-151 Page 5

Technical Notes on using Analog Devices’ DSP components and development tools

Phone: (800) ANALOG-D, FAX: [phone], EMAIL: [e-mail], FTP: ftp.analog.com, WEB: www.analog.com/dsp

blink status gives an indication which data
overlay load/store is executing.

Data Overlays Load/Store Functions:

As the VisualDSP++ tool only fully support
code overlays, we are still able take advantage
of this built in support to develop a scheme to
handle data overlays. This can be accomplished
by making a few modifications to the ADI­supplied instruction overlay manager which is
provided in EE-66. It does, however, require a
certain amount of house keeping on the
programmer’s part. Basically, this scheme
requires the programmer to initiate the loading
of an overlay containing the data buffers to be
brought into internal memory from external
SDRAM. This can be done by defining and
calling an assembly macro called
Load_Data_Overlay( ). For the C example, we
take a similar approach but instead of
implementing a macro, we can develop a small
C function to initiate the data overlay process.
The parameter the programmer must pass is the
ID of the overlay to be loaded. This can easily
be obtained from the map file.

To write the overlay back to external SDRAM
memory with the changes, the programmer then
calls a second macro or function called
Save_Data_Overlay( ). Again, this macro or
function requires the overlay ID as an input (this
also is obtained from symbol map file).

LISTING 3. data_ovl.h for ASM Data Overlay

Example

#define Load_Data_Overlay(SYMBOL_OVERLAYID)

r0 = 1;\
call _OverlayManager (DB);\
dm(DataTransfer) = r0;\
R0 = SYMBOL_OVERLAYID

#define Store_Data_Overlay(SYMBOL_OVERLAYID)

r0 = 1;\
dm(Internal2exttransfer)=r0;\
call _OverlayManager (DB);\
dm(DataTransfer) = r0;\

R0 = SYMBOL_OVERLAYID

LISTING 4. data_ovl.h for C Data Overlay

Example

extern int SYMBOL_OVERLAYID;

void load_data_overlay (int SYMBOL_OVERLAYID)

{

}

void store_data_overlay(int SYMBOL_OVERLAYID)

{

}

DataTransfer = 1;
asm volatile("R0 = R4;");
OverlayManager();

DataTransfer = 1;
Internal2exttransfer = 1;
asm volatile("R0 = R4;");
OverlayManager();

Thus, these two macros (assembly version) or
functions (C version) simply call the overlay
manager with the proper parameters set. This is
the only difference between data and code
overlays (aside from the overlay manager DMA
setup to initiate data vs. instruction transfers) as
far as the linker is concerned. The macros take
place of the PLIT table since a PLIT entry is not
created for data overlays.

The overlay support provided is built in to the
linker, and is partially designed by the user in
the linker description file (LDF). To set up a
data overlay, the user specifies which data
overlays share runt time memory and which
memory segments establish the live and run data
spaces. The following LDF file fragments shows
how we define three data overlays in the LDF.
The first example is the LDF file portion
contained in the assembly project. Listing 1
shows how to place the data overlay variables
defined in the three overlay asm files to reside in
the run space – run_dmda.

LISTING 3: Overlay Input/Output Sections

for assembly example

no_dmda
{

OVERLAY_INPUT

{

ALGORITHM(ALL_FIT)
OVERLAY_OUTPUT(dm1_ovly.ovl)
INPUT_SECTIONS(dm1_overlay.doj(run_dmda))

EE-151 Page 6

Technical Notes on using Analog Devices’ DSP components and development tools

Phone: (800) ANALOG-D, FAX: [phone], EMAIL: [e-mail], FTP: ftp.analog.com, WEB: www.analog.com/dsp