Technical information

Porting Process
 Application Porting 3
2.1 Porting Process
To set up the application to run on DSP56800E tools, the following steps were performed:
1. The original application code was tested, and test vectors were obtained. These steps are
required for testing the ported code and for possible further optimization.
2. The original code’s compliance with the coding requirements for porting was verified.
2.1.1 Running the Original Application Code and Obtaining Test
Vectors
The original application was run in digital loopback mode under CodeWarrior 3.5.1 for DSP. The output of
the digital loopback is a Boolean value resulting from a comparison between the transmitted and received
data.
Using this version, we also obtained the test vectors: the data to be sent, the data received, and the
information to be transmitted to the analog converter (data received as parameters by the transmitter’s
callback function, which should be sent by wire by the codec). Only the global test vectors were saved.
Local test vectors, represented by the input and output data of a function, were saved later using
DSP56800E tools, when they were required during the optimization process. The reason for this approach
is that the local vectors were not required for porting, and it was simpler to save them from DSP56800E
tools using simulator scripts (the CodeWarrior simulator does not accept scripts, and memory save and
restore operations using I/O streams increase the simulation time).
2.1.2 Verifying the Coding Requirements
Coding practices are required to ensure that a DSP56800 program is compatible with the DSP56800E. The
main code example that is featured in this application note met all requirements without being modified.
2.1.2.1 AGU Arithmetic Overflow and Underflow
Applications must be written so that there is no AGU overflow or underflow of 64K boundaries when data
or program memory is accessed with the following DSP56800 addressing modes:
• (Rn)+
• (Rn)–
• (Rn)+N
• (SP–xx)
• (SP+xxxx)
• (R2+xx)
AGU overflow and underflow should not appear in normal conditions. They are not always easy to detect.
Consider a scenario showing the differences that appear when AGU overflow occurs. Assume that during
the linking phase, a certain array or data structure is placed at the end of the addressable space, wrapping
from a high address to a low address. To help detect such memory areas, an indication of the memory
arrangement can be obtained from a memory utilization report generated by the assembler or from a linker
map file.
One case is the access to this array using the (Rn)+ addressing mode. On DSP56800 architecture, the AGU
overflows. When the application is ported to DSP56800E architecture, the wrapping does not occur and the
array is placed in a contiguous space above the 64K boundary. Then, if the same addressing mode is used,
the AGU calculates 24-bit addresses, overflow does not occur, and the array is accessed correctly.
Fr
eescale S
emiconduct
or
, I
Freescale Semiconductor, Inc.
For More Information On This Product,
Go to: www.freescale.com
nc...