Analog Devices EE167 Application Notes

Engineer To Engineer Note EE-167

a

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

Contact our technical support by phone: (800) ANALOG-D or e-mail: [e-mail]
Or vi sit ou r on-l ine re sourc es ht tp:// www.analog.com/dsp and http://www.analog.com/dsp/EZAnswer

Introduction to TigerSHARC® Multiprocessor Systems Using VisualDSP++™

Contributed by Maikel Kokaly-Bannourah April 04, 2003

Introduction

The following Engineer-to-Engineer note
is intended to give an introduction to
Multiprocessor (MP) systems using
VisualDSP++. The explanation will be based
on assembly code written for the ADDS-TS101S
EZ-Kit Lite, consisting of two TigerSHARC®
Processors, using VisualDSP++ 3.0.

TigerSHARC® Multiprocessor systems can be
configured in different ways:

• Several processors sharing the external bus

• Link Port point-to-point communication
This note will discuss the implementation of an

MP system with the processors sharing the
external bus. For more details on other
implementations please refer to the
TigerSHARC® Processor Hardware Reference.

In addition to the assembly code explored
throughout this note, an MP code example
written in C is also available.

Linker Description File (LDF) for MP Systems

The very first step in setting up an MP
system is to create a multiprocessor project using
the multiprocessing capabilities of the linker, and
an LDF file to describe the system.

The LDF describes the multiprocessor memory
offsets, shared memory, and each processor’s

Copyright 2003, Analog Devices, Inc. All rights reserved. Analog Devices assumes no responsibility for customer product design or the use or application of
customers’ products or 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 regarding technical accuracy and topicality of the content provided in Analog Devices’ Engineer-to-Engineer Notes.

memory. The following LDF commands must be
considered when writing an MP LDF:

• MPMEMORY{}, it defines each processor’s
offset within multi-processor memory space
(MMS). The linker uses the offsets during
multiprocessor linking.

• MEMORY{}, it defines memory for all
processors present in the system.

• PROCESSOR{} and SECTIONS{} commands
define each processor and place program sections
for each processor’s output file, using the
memory definitions.

• SHARED_MEMORY{}, it is needed when
external shared memory is used in the system.

This command identifies the output for the
shared memory items and generates Shared
Memory executable files (.SM) that reside in the
shared memory of the MP system.

The .SM file is generated from a source code file
(.ASM, .C or .CPP), which must be included
with the project files. This file contains the
variable definitions for the data that will be
placed in the external shared memory.

• LINK_AGAINST(), it resolves symbols within
multiprocessor memory and directs the linker to
check specified executables (.DXEs and .SMs) to
resolve variables and labels that have not been
resolved locally. Whenever expressions or
variables are defined in the MMS (i.e. internal
memory of another processor in the system) the
LINK_AGAINST() command must be used in
the LDF.

s

a

Note: if .SM files and DXE files are included in
the command line, the .SM file must be placed
first, followed by all other DXE’s, for the linker
to be able to resolve the variables correctly.

The maximum number of processors that can be
declared in one LDF is architecture-specific (i.e.
maximum of 8 ADSP-TS101S’s). Also note that

a combination of different DSPs with different
architectures (i.e. ADSP-TS101S and ADSP-

21160) in the same LDF is not supported by
VisualDSP++.

Figure 1Excerpt from and MP LDF example

An MP LDF example where all the above
commands are used is shown in Figure 1. The
remaining of the LDF file is basically the same
as the default one provided with the tools
(please refer to the “Linker and Utilities

Manual for TigerSHARC® DSPs” or to “EE-69
Understanding and Using Linker Description
Files (LDFs)” for a general description on LDF

files).

Introduction to TigerSHARC® Multiprocessor Systems Using VisualDSP++™ (EE-167) Page 2 of 12

In Figure 1, a 2 ADSP-TS101S and external
shared memory system is defined

Now that the different sections of the LDF have
been discussed, we can examine the example
code that explores some of the MP capabilities
of the processor.

For MP system hardware configuration please
refer to Cluster Bus chapter of the

TigerSHARC® Processor Hardware Reference.

a

Multiprocessor Memory Space (MMS)

The multiprocessor memory space is
divided into a number of address regions (this
number is processor specific) that correspond to
the internal memory of the processors in an MP
system. The ADSP-TS101S’s multiprocessor
memory space appears in Figure 2.

not be used or other than in special cases where
data must pass through the TigerSHARC® bus
interface. Performing a self-multiprocessor
read access will set the SELF MPROC READ
bit in the SYSTAT register as an error
indication for the illegal access.

Example 1 shows source code where the MMS
is used to access a memory location of another
DSP in the system. In this case DSP with ID0
accesses a memory location in ID1’s internal
memory.

Example 1:

// Code in ID0

r0=0x02480000; //M0 Data in int mem of ID1

In example 1, the MMS address for ID1 is
0x2400000, which is then added to the address
corresponding to ID1’s internal memory
(0x80000). Therefore, this will result in a read
access of ID0 from ID1’s internal memory.

Figure 2 ADSP-TS101S’s Multiprocessor Memory
Space.

Depending on the address range used, the
internal memory of a particular DSP in the
multiprocessor system will be accessed as a
source or destination. Writes to the Broadcast
region access the memory of all DSPs in the
multiprocessing system.

For instance, accessing a memory location
within the address range 0x3000000 –
0x33FFFFF, is equivalent to accessing the
internal memory of the DSP in the MP system
with ID 4.

Note: A TigerSHARC’s® own Internal space
can be accessed via the multiprocessing space
for write transactions only. This, however, is
performed through the external bus and should

Note: In DSP multiprocessor systems including
SDRAM a DSP with ID=000 must be present,
since this DSP performs the initialization (MRS)
of the SDRAM. Also, there are issues related to
open drain pull-ups only enabled on the DSP
with ID=000. After reset, ID0 becomes the bus
master and priority rotates in a round robin
fashion, going up from the present master.

External Memory

The ADSP-TS101S has 6Mbits of on­chip SRAM memory that can store both
program and data. However, some applications
also require the use of external memory devices.

External memory is widely used in MP systems,
and can be implemented as a shared resource for
all DSPs in the system, or dedicated to a
particular processor.

It is very important to keep in mind that all
DSPs in the system must set up the proper
access mode for the type of memory used in the
hardware system. The access mode is

Introduction to TigerSHARC® Multiprocessor Systems Using VisualDSP++™ (EE-167) Page 3 of 12

a

programmed via the System Control (SYSCON)
register. Default power up/reset settings for
SYSCON are detailed in the TigerSHARC®
Processor Hardware Reference. User defined
settings must support the access mode
appropriate to the memory device(s) that the
user intends to use in their hardware systems.
SYSCON settings must be the same across all
devices sharing the cluster bus connection.

Note that SDRAM is gluelessly supported by
the ADSP-TS101S. As with the SYSCON
register, the SDRAM Configuration (SDRCON)
register of all processors in the system must be
initialized to the same value. Once the DSP’s
internal memory controller has been configured,
the external memory can be accessed by the
DSP via the external bus.

In this project, SDRAM was used as an external
shared resource for the two DSPs in the system.
The code shown in example 2 corresponds to
the SDRCON register initialization, which, as
previously mentioned, must be done by all
DSPs sharing the same external memory (in this
case, ID0 and ID1).

Example 2:

// Excerpt from ID0 & ID1: SDRAM Init.

j11 = j31 + 0x00005913;;
SDRCON = j11;;

// Enable SDRAM: ENA=1,CAS=2CL,pipedepth=0,
page=512w,
ref.rate=1200,trp=2,tras=5,init=1

Shared.asm contains the variable definitions for
the data that will be placed in external memory.

Vector Interrupt (VIRPT)

Vector Interrupts are used for inter­processor communication between a host and a
DSP or between DSPs.

This interrupt is a general-purpose interrupt for
another master’s use. The host (or master DSP)
can issue a vector interrupt to the slave DSP by
writing the address of an interrupt service
routine to the VIRPT register. When serviced,
this high priority interrupt causes the DSP to
branch to the service routine at that address.

Example 3:

// Extract from ID1: VIRPT Generation

j1 = MMS_ID0 + VIRPT_REG;;
xr0 = VIRPT_ISR_ID0 - MMS_ID0;;
[j1 += j31]= xr0;;

In example 3, ID1 triggers a vector interrupt in
ID0 by writing the address of the service routine
to be served in ID0 (labeled VIRPT_ISR_ID0)
to the VIRPT register in ID0 (0x2180730 =
0x180730 VIRPT address + 0x2000000 MMS
ID0).

Note: In case an external defined label is used
for the ISR address (like in this example, i.e.
VIRPT_ISR_ID0), the MMS offset value of the
DSP serving the interrupt (MMS_ID0) must be
subtracted for the DSP to vector to the address
of the ISR correctly.

This is just an example of how inter-processor
VIRPT interrupts can be used as flags or just to
indicate program execution completion in MP
systems.

Note: the DSP with the lowest ID number (and
therefore highest priority in the system) is
responsible for initializing the external data
defined in the .ASM shared memory file during
the booting-up sequence.

Bus Lock and Semaphores

Semaphores are useful for synchronizing
tasks performed in an MP system. A semaphore
is a flag, set of data or memory location that can
be accessed by any of the DSPs present in the
system.

In critical tasks (i.e. should not be interrupted),
when attempting a read-modify-write operation

Introduction to TigerSHARC® Multiprocessor Systems Using VisualDSP++™ (EE-167) Page 4 of 12