Visualdsp++ User's Guide
Visualdsp++ User's Guide
0
User’s Guide
Disclaimer
Analog Devices, Inc. reserves the right to change this product without
prior notice. Information furnished by Analog Devices is believed to be
accurate and reliable. However, no responsibility is assumed by Analog
Devices for its use; nor for any infringement of patents or other rights of
third parties which may result from its use. No license is granted by impli-
cation or otherwise under the patent rights of Analog Devices, Inc.
PREFACE
Purpose of This Manual .............................................................. xxiii
Intended Audience ...................................................................... xxiii
Manual Contents ......................................................................... xxiv
What’s New in This Manual .......................................................... xxv
Technical or Customer Support .................................................... xxvi
Supported Processors ................................................................... xxvii
Product Information .................................................................. xxviii
MyAnalog.com ..................................................................... xxviii
Processor Product Information ................................................ xxix
Related Documents ................................................................. xxx
Online Technical Documentation ........................................... xxxi
Accessing Documentation From VisualDSP++ ................... xxxii
Accessing Documentation From Windows ......................... xxxii
Accessing Documentation From the Web .......................... xxxiii
Embedded Processing & DSP Knowledge Base ................. xxxiii
Printed Manuals ................................................................... xxxiii
INTRODUCTION TO VISUALDSP++
VisualDSP++ Features .................................................................. 1-1
Integrated Development and Debugging .................................. 1-2
Code Development Tools ........................................................ 1-2
Source File Editing Features .................................................... 1-3
Project Management Features .................................................. 1-4
Debugging Features ................................................................. 1-5
VDK Features ......................................................................... 1-6
VisualDSP++ 5.0 Features ....................................................... 1-7
Product Updates and Upgrades ................................................... 1-10
VisualDSP++ Product Upgrades ............................................ 1-10
VisualDSP++ Product Updates .............................................. 1-10
Project Development .................................................................. 1-11
Overview of Programming With VisualDSP++ ....................... 1-12
Project Development Stages ................................................... 1-14
Targets .................................................................................. 1-15
Simulation Targets ............................................................ 1-16
EZ-KIT Lite Targets ......................................................... 1-16
Emulator Targets .............................................................. 1-17
Platforms .............................................................................. 1-17
ENVIRONMENT
Project Window ............................................................................ 2-2
Project View ............................................................................ 2-3
Kernel Tab .............................................................................. 2-4
Project Dependencies .............................................................. 2-4
Project Nodes .......................................................................... 2-6
Project Folders .................................................................... 2-6
Project Files ........................................................................ 2-8
Project Window Icons for Source Code Control (SCC) ........ 2-9
Project Page Right-Click Menus ............................................. 2-10
Project Group Icon Right-Click Menu ............................... 2-10
Project Icon Right-Click Menu .......................................... 2-11
Folder Icon Right-Click Menu .......................................... 2-12
File Icon Right-Click Menu ............................................... 2-12
Project Window Rules ........................................................... 2-13
File Associations .................................................................... 2-14
Automatic File Placement ...................................................... 2-15
File Placement Rules ......................................................... 2-15
Example ........................................................................... 2-16
Editor Windows .......................................................................... 2-16
DEBUGGING
Debug Sessions ............................................................................. 3-1
Debug Session Management .................................................... 3-3
Simulation vs. Emulation ........................................................ 3-3
Breakpoints ........................................................................ 3-3
Watchpoints ....................................................................... 3-4
Multiprocessor (MP) System Debugging .................................. 3-4
Setting Up a Multiprocessor Debug Session ......................... 3-4
Debugging a Multiprocessor System .................................... 3-5
Focus and Pinning .......................................................... 3-6
REFERENCE INFORMATION
Support Information ..................................................................... A-2
IDDE Command-Line Parameters ................................................ A-7
Extensive Scripting ....................................................................... A-8
File Types ................................................................................... A-12
Parts of the User Interface ........................................................... A-15
Title Bar ............................................................................... A-16
INDEX
Thank you for purchasing Analog Devices, Inc. development software for
digital signal processing (DSP) applications.
Intended Audience
The primary audience for this manual is a programmer who is familiar
with Analog Devices processors. This manual assumes that the audience
has a working knowledge of the appropriate processor architecture and
instruction set. Programmers who are unfamiliar with Analog Devices
processors can use this manual, but should supplement it with other texts
(such as the appropriate hardware reference and programming reference
manuals) that describe your target architecture.
Manual Contents
The manual consists of:
• Chapter 1, “Introduction to VisualDSP++”
Describes VisualDSP++ features, license management, project
development, code development tools, and DSP projects
• Chapter 2, “Environment”
Focuses on window features, operations, and customization for the
main window and debugging windows.
• Chapter 3, “Debugging”
Describes debug sessions, code analysis tools, program execution
operations, simulation tools, and utilities.
• Appendix A, “Reference Information”
Describes file types, keyboard shortcuts, command-line parameters,
scripting, toolbar buttons, and text operations; also provides a
glossary and describes online Help features and operations.
• Appendix B, “Simulation of SHARC Processors”
Describes the simulator options available on the Anomalies,
Events, Simulator, Load Sim Loader, and Select Processor ID
submenus under Settings; also explains how to record simulator
anomalies and events, and describes SPI simulation in slave mode.
• Appendix C, “Simulation of TigerSHARC Processors”
Describes simulator instruction timing analysis, pipeline stages, the
Pipeline Viewer, stalls, aborts, the current program counter value,
stepping, and the Select Loader Program command on the Simu-
lator submenu under Settings.
• Appendix D, “Simulation of Blackfin Processors”
Provides an overview of peripheral support for Blackfin simulators
and describes limitations of the simulation software models, simu-
lator instruction timing analysis, and compiled simulation.
Supported Processors
The following is the list of Analog Devices, Inc. processors supported in
VisualDSP++ 5.0.
TigerSHARC (ADSP-TSxxx) Processors
The name “TigerSHARC” refers to a family of floating-point and
fixed-point [8-bit, 16-bit, and 32-bit] processors. VisualDSP++ currently
supports the following TigerSHARC processors:
ADSP-BF531 ADSP-BF532
ADSP-BF533 ADSP-BF535
ADSP-BF561 ADSP-BF534
ADSP-BF536 ADSP-BF537
ADSP-BF538 ADSP-BF539
ADSP-BF522 ADSP-BF525
ADSP-BF527 ADSP-BF542
ADSP-BF544 ADSP-BF548
ADSP-BF549
Product Information
You can obtain product information from the Analog Devices Web site,
from the product CD-ROM, or from the printed publications (manuals).
Analog Devices is online at www.analog.com. This Web site provides
information about a broad range of products—analog integrated circuits,
amplifiers, converters, and digital signal processors.
MyAnalog.com
MyAnalog.com is a free feature of the Analog Devices Web site that allows
customization of a Web page to display only the latest information on
products you are interested in. You can also choose to receive e-mail
notifications containing updates to the Web pages that meet your inter-
ests, including documentation errata against all manuals. MyAnalog.com
provides access to books, application notes, data sheets, code examples,
and more.
Registration
Visit www.myanalog.com to sign up. Click Register to use MyAnalog.com.
Registration takes about five minutes and serves as a means to select the
information you want to receive.
If you are already a registered user, just log on. Your user name is your
e-mail address.
Related Documents
For information on product related development software, see these
publications:
• VisualDSP++ 5.0 Product Release Bulletin
• VisualDSP++ 5.0 Getting Started Guide
• VisualDSP++ 5.0 Assembler and Preprocessor Manual
• VisualDSP++ 5.0 C/C++ Compiler Manual for SHARC Processors
• VisualDSP++ 5.0 Run-Time Library Manual for SHARC Processors
• VisualDSP++ 5.0 C/C++ Compiler and Library Manual
for TigerSHARC Processors
• VisualDSP++ 5.0 C/C++ Compiler and Library Manual for Blackfin
Processors
• VisualDSP++ 5.0 Linker and Utilities Manual
• VisualDSP++ 5.0 Loader and Utilities Manual
• VisualDSP++ 5.0 Device Drivers and System Services Manual
for Blackfin Processors
• VisualDSP++ 5.0 Kernel (VDK) User’s Guide
• VisualDSP++ 5.0 Installation Quick Reference Card
• VisualDSP++ 5.0 Licensing Guide
L Throughout this manual and online Help, tools manuals are often
identified by their titles, but without their software version (that is,
the 5.0 is not shown).
File Description
.HTM Dinkum Abridged C++ library and FlexLM network license manager software doc-
or umentation. Viewing and printing the .HTML files requires a browser, such as
.HTML Internet Explorer 6.0 (or higher).
Select a processor family and book title. Download archive (.ZIP) files, one
for each manual. Use any archive management software, such as WinZip,
to decompress downloaded files.
Printed Manuals
For general questions regarding literature ordering, call the Literature
Center at 1-800-ANALOGD (1-800-262-5643) and follow the prompts.
Processor Manuals
Hardware reference and instruction set reference manuals may be ordered
through the Literature Center at 1-800-ANALOGD (1-800-262-5643),
or downloaded from the Analog Devices Web site. Manuals may be
ordered by title or by product number located on the back cover of each
manual.
Data Sheets
All data sheets (preliminary and production) may be downloaded from the
Analog Devices Web site. Only production (final) data sheets (Rev. 0, A,
B, C, and so on) can be obtained from the Literature Center at
1-800-ANALOGD (1-800-262-5643); they also can be downloaded from
the Web site.
To have a data sheet faxed to you, call the Analog Devices Faxback System
at 1-800-446-6212. Follow the prompts and a list of data sheet code
numbers will be faxed to you. If the data sheet you want is not listed,
check for it on the Web site.
Notation Conventions
Text conventions in this manual are identified and described as follows.
Example Description
Close command Titles in reference sections indicate the location of an item within the
(File menu) VisualDSP++ environment’s menu system (for example, the Close
command appears on the File menu).
{this | that} Alternative required items in syntax descriptions appear within curly
brackets and separated by vertical bars; read the example as this or
that. One or the other is required.
[this | that] Optional items in syntax descriptions appear within brackets and sepa-
rated by vertical bars; read the example as an optional this or that.
[this,…] Optional item lists in syntax descriptions appear within brackets
delimited by commas and terminated with an ellipse; read the example
as an optional comma-separated list of this.
.SECTION Commands, directives, keywords, and feature names are in text with
letter gothic font.
L
mation on a related topic. In the online version of this book, the word
Note appears instead of this symbol.
a
Caution: Device damage may result if ...
A Caution identifies conditions or inappropriate usage of the product
that could lead to undesirable results or product damage. In the online
version of this book, the word Caution appears instead of this symbol.
[
A Warning identifies conditions or inappropriate usage of the product
that could lead to conditions that are potentially hazardous for devices
users. In the online version of this book, the word Warning appears
instead of this symbol.
VisualDSP++ Features
VisualDSP++ includes all the tools needed to build and manage processor
projects.
VisualDSP++ includes:
• Integrated Development and Debugging Environment (IDDE)
with VisualDSP++ Kernel (VDK) integration
• C/C++ optimizing compiler with run-time library
Source files are the C/C++ language or assembly language files that
make up your project. Processor projects can include additional
files such as data files and a Linker Description File (.ldf), which
contains command input for the linker. For more information
about .ldf files, see “Linker” on page 1-31.
• Editor windows. Open multiple editor windows (source windows)
to view and edit related files, or open multiple editor windows for a
single file. The VisualDSP++ editor is an integrated code-writing
tool that enables you to focus on code development.
• Specify syntax coloring. Configure options that specify the color of
text objects viewed in an editor window.
This feature enhances the view and helps locate portions of the
text, because keywords, quotes, and comments appear in distinct
colors.
• Context-sensitive expression evaluation. Move the mouse pointer
over a variable that is in the scope to view the variable’s value.
• Status icons. View icons that indicate breakpoints, bookmarks, and
the current PC position.
• View error details and offending code. From the Output window’s
Build view, display error details by highlighting the error code
(such as cc0251) and pressing the F1 key. Double-click an error
line to jump to the offending code in an editor window.
Debugging Features
While debugging your project, you can:
• View and debug mixed C/C++ and assembly code. View C/C++
source code interspersed with assembly code. Line number and
symbol information help you to source-level debug assembly files.
• Run command-line scripts. Use scripts to customize key debug-
ging features.
• Use memory expressions. Use expressions that refer to memory.
• Use breakpoints to view registers and memory. Quickly add and
remove, and enable and disable breakpoints.
• Set simulated watchpoints. Set watchpoints on stacks, registers,
memory, or symbols to halt program execution.
• Statistically profile the target processor’s PC (JTAG emulator
debug targets only). Take random samples and display them graph-
ically to see where the program uses most of its time.
• Linearly profile the target processor’s PC (Simulation only).
Sample every executed PC and provide an accurate and complete
graphical display of what was executed in your program.
• Generate interrupts using streaming I/O. Set up serial port
(SPORT) or memory-mapped I/O.
• Create customized register windows. Configure a custom register
window to display a specified set of registers.
• Plot values from processor memory. Choose from multiple plot
styles, data processing options, and presentation options.
VDK Features
The VisualDSP++ Kernel (VDK) is a scalable software executive specially
developed for effective operations on Analog Devices processors. The
VDK is tightly integrated with VisualDSP++.
The kernel enables you to abstract the details of the hardware implemen-
tation from the software design. As a result, you can concentrate on the
processing algorithms.
The kernel provides all the basic building blocks required for application
development. Properties of the kernel can be characterized as follows.
• Automatic. VisualDSP++ automatically generates source code
framework for each user-requested object in the user-specified
language.
• Deterministic. VisualDSP++ specifies whether the execution time
of a VDK API is deterministic.
• Multitasking. Kernel tasks (threads) are independent of one
another. Each thread has its own stack.
• Modular. The kernel comprises various components. Future
releases may offer additional functionality.
simulator. This assumes that the simulator shares the same set of
registers with the ICE and can access all the memory blocks rele-
vant to the program as the ICE does. Another benefit of this
capability is in understanding the effects of a program sequence.
You can generate a core file, step over a subroutine, and then gen-
erate a second core file. Then, convert both core files to text file
format and “diff” the files to show all the effects of the subroutine.
• Categories in Help. You can “filter” VisualDSP++ Help by setting
a preference or by launching a particular category of Help via the
Windows Start menu. Now there are three processor-specific Help
categories (one for each processor family) and a complete Help that
contains information about all processor families; an “automatic”
options displays Help for currently selected debug session. Each
Help category (for example, Blackfin processor family Help) dis-
plays information pertinent to that specific family of processors. By
selecting a Help category, in effect, you remove information about
other families of processors from Help; this improves your ability
to quickly locate information in Help, especially when running a
“search” or looking up an entry in the Help Index.
• Enhanced Licensing and Registration. Software licence borrowing
for floating licenses allows you to check out a floating license from
a server for a predetermined length of time. On the Licenses page
of the About dialog box, when a client license is installed, the
server_name appears under Serial Number, “client” appears under
Family, and “use_server” appears under Status. The “Machine ID”
box displays the C: drive’s volume ID. If you are running off a
server-based (floating) license, this box displays the MAC address
of the primary Ethernet controller in the machine.
• New Project Types. The Project Wizard has been changed to
simplify the process of creating a new project.
L Check the Analog Devices Web site to ensure that you have the
latest software version.
LDF, errata accommodations, EZ-KIT Lite software, and so on) for new
semiconductor products will be added as these products become available
and gain support within the VisualDSP++ tools.
Starting with VisualDSP++ 3.5, new versions of VisualDSP++ are discrete
upgrades. Your PC can maintain multiple versions of VisualDSP++.
Refer to online Help for details on updating your software. Help explains
how to identify the update currently installed on your system.
Project Development
During project development, VisualDSP++ helps you interactively observe
and alter the data in the processor and in memory.
This section describes:
• “Overview of Programming With VisualDSP++” on page 1-12
• “Project Development Stages” on page 1-14
• “Targets” on page 1-15
• “Platforms” on page 1-17
• “Debugging Overview” on page 1-20
• “VisualDSP++ Kernel” on page 1-22
• “Program Development Steps” on page 1-22
EZ-KIT Lite
Evaluation
Board
Pod
Emulation
Simulation
Project development typically begins in a simulation environment while
hardware engineers are developing the new hardware (cell phone, com-
puter, and so on). Simulation mimics system memory and I/O, which
allows portions of the target system hardware behavior to be viewed. A
simulator is software that mimics the behavior of a processor. Running
VisualDSP++ with a simulation target (without a physical processor)
enables you to build, edit, and debug your program, even before a proces-
sor is manufactured.
Evaluation
Use an EZ-KIT Lite evaluation system in your project’s early planning
stage to determine the processor that best fits your needs. Your PC con-
nects to the EZ-KIT Lite board via a cable, enabling you to monitor
processor behavior.
Emulation
Once the hardware is ready, move directly to a JTAG emulator, which
connects your PC to the actual processor target board. Emulators provide
fast communications between the board and your PC. An emulator
enables application software to be downloaded and debugged from within
VisualDSP++. Emulator software performs the communications that
enable you to see how your code affects processor performance.
Targets
A target (or debug target) refers to the communication channel between
VisualDSP++ and a processor (or group of processors). A target can be a
simulator, EZ-KIT Lite evaluation board, or an emulator. Your system
can include multiple targets.
Simulation Targets
A simulation target, such as the ADSP-2106x Family Simulator, is a pure
software module and does not require the presence of a processor or any
related hardware for debugging.
During simulation, VisualDSP++ reads an executable (.DXE) file and exe-
cutes it in software, similar to the way a processor executes a processor
image in hardware. VisualDSP++ simulates the memory and I/O devices
specified in an .ldf file. Some processors permit you to run a compiled
simulation. Refer to “Compiled Simulation” on page D-44.
Hardware Simulation
When connected to a simulation target in VisualDSP++, you can simulate
the following hardware conditions.
• Random interrupts that can occur during program execution
• Data transfer through the processor’s I/O pins
• Processor booting from a PROM or host processor
Setting up VisualDSP++ to generate random interrupts during program
execution enables you to exercise interrupt service routines (ISR) in your
code.
Emulator Targets
An emulator target is a module that controls a physical processor con-
nected to a JTAG emulator system. For example, the USB-ICE emulator
communicates with one or more physical devices through the host USB
port.
Platforms
A platform refers to the configuration of processors with which a target
communicates. Several platforms may exist for a given debug target. For
example, if three emulators are installed on your system, you might select
emulator 2 as the platform that you want to use. The platform that you
use depends on your project development stage. (See Table 1-1.)
Table 1-1. Development Stages and Supported Platforms
Stage Platform
Simulation Typically one or more processors of the same type. By default, the plat-
form name is the identical simulator. Some processors support compiled
simulation; refer to “Compiled Simulation” on page D-44.
Evaluation An EZ-KIT Lite evaluation system
Emulation Any combination of devices. You configure the platform for a particular
target with the VisualDSP++ Configurator. When the debug target is a
JTAG emulator, “platform” refers to a JTAG chain of specific device
types.
VisualDSP++ Configurator
Use the VisualDSP++ Configurator (Figure 1-2) to align the external
hardware target with an emulator so that the appropriate IDDE debug ses-
sion can be established.
After the EZ-KIT Lite evaluation system or emulator has been connected,
powered up, and recognized in the Windows Device Manager, you can
select or create the appropriate platform needed for configuring a debug
session. If the appropriate platform is not shown, you can create or config-
ure one by specifying its name, type and JTAG chain (scan path).
You can also use the VisualDSP++ Configurator to run ICE Test, a utility
that checks the functionality of your emulator; refer to Figure 1-3.
Refer to VisualDSP++ Help for details about using the VisualDSP++
Configurator and the ICE Test utility.
Debugging Overview
Once you have successfully built a processor project and generated an
executable file, you can debug the project. Projects developed in
VisualDSP++ are run as hardware and software debug sessions.
In Table 1-2, “Yes” indicates the debugging tools that are available during
the process of building and debugging a program.
You can attach to and control the operation of any Analog Devices
processors or simulator. Download your application code to the processor
and use VisualDSP++’s debugging facilities to ensure that your application
functions as desired.
VisualDSP++ Kernel
A project can optionally include the VisualDSP++ Kernel (VDK), which is
a software executive between algorithms, peripherals, and control logic.
The Project window’s Kernel tab accesses a tree control for structuring
and scaling application development. From this tree control, you can add,
modify, and delete Kernel elements such as thread types, boot threads,
round-robin priorities, semaphores, events, event bits, interrupts, and
device drivers.
Two VDK-specific windows, VDK State History and Target Load, pro-
vide views of VDK information. Another VDK window, VDK Status,
provides thread status data when a VDK-enabled program is halted. Refer
to the VisualDSP++ Kernel (VDK) User’s Guide for details.
By following these steps, you can build projects consistently and accu-
rately with minimal project management. This process reduces
development time and lets you concentrate on code development.
These steps, described below, are covered in detail in VisualDSP++ Help
and in the “Basic Tutorial” chapter of the VisualDSP++ Getting Started
Guide.
Editing Files
You can edit the file(s) that you add to the project. To open a file for
editing, double-click on the file icon in the Project window.
The editor has a standard Windows-style user interface and supports
normal editing operations and multiple open windows. You can customize
language- and processor-specific syntax coloring, and create and search for
bookmarks.
development tools that create your executable file. You can specify options
for a whole project or for individual files, or you can specify a custom
build.
Configuration
A project’s configuration setting controls its build. By default, the choices
are Debug or Release.
• Selecting Debug and leaving all other options at their default set-
tings builds a project that can be debugged. The compiler generates
debug information.
• Selecting Release and leaving all other options at their default set-
tings builds a project with limited or no debug capabilities. Release
builds are usually optimized for performance. Your test suite
should verify that the Release build operates correctly without
introducing significant bugs.
You can modify VisualDSP++’s default operation for either configuration
by changing the appropriate entries on the Compile, Assemble, and Link
pages. You can create custom configurations that include the build
options and source files that you want.
Compiler
The compiler processes C/C++ programs into assembly code. The term
compiler refers to the compiler utility shipped with the VisualDSP++
software.
The compiler generates a linkable object file by compiling one or more
C/C++ source files. The compiler’s primary output is a linkable object file
with a .DOJ extension.
To specify compiler options for your build, choose Project -> Project
Options. From the tree control of the ensuing Project Options dialog
box, expand Compile and click a subpage.
Compiler options are grouped into the subpages described in Table 1-3.
Source Language Settings related to the dialect of C or C++ accepted by the compiler
Settings
Assembler
The assembler generates an object file by assembling source, header, and
data files. The assembler’s primary output is an object file with a .doj
extension.
To specify assembler options, choose Project -> Project Options, and
click Assemble (in the Project Options dialog box).
Assembler terms are defined as follows.
instruction set
Set of assembly instructions that pertain to a specific processor.
For information about the instruction set, refer to your processor’s
hardware documentation.
preprocessor commands
Commands that direct the preprocessor to include files, perform
macro substitutions, and control conditional assembly
assembler directives
Directives that tell the assembler how to process source code and
set up processor features. Use directives to structure your program
into logical segments or sections that support the use of a Linker
Description File (.ldf) to construct an image suited to the target
system.
For detailed information, refer to the VisualDSP++ Assembler and
Preprocessor Manual or VisualDSP++ Help
Linker
The linker links separately assembled files (object files and library files) to
produce executable (.dxe) files, shared memory (.sm) files, and overlay
(.ovl) files, which can be loaded onto the target.
The linker’s output files (.dxe, .sm, .ovl) are binary, executable, and link-
able files (ELF). To make an executable file, the linker processes data from
a Linker Description File (.ldf) and one or more object (.doj) files. The
executable files contain program code and debugging information. The
linker fully resolves addresses in executable files.
To specify linker options, choose Project -> Project Options, and click
Link tab (on the Project Options dialog box). From the Link page, select
a Category of options. Linker options are grouped into the following
subpages.
• General
• LDF Preprocessing
• Elimination
• Processor
Linker terms are defined as follows.
link against
Functionality that enables the linker to resolve symbols to which
multiple executables refer. For instance, shared memory (.sm)
executable files contain sections of code that other processor
Expert Linker
Expert Linker is a graphical tool that enables you to:
• Define a target processor’s memory map
• Place a project’s object sections into that memory map
• View how much stack or heap has been used after you run a proces-
sor program
This interactive tool speeds up the configuration of system memory. It
uses your application’s target memory description, object files, and librar-
ies to create a memory map that you can manipulate to optimize your
system’s use of memory.
L Expert Linker works with the linker. For more information about
linking, refer to the VisualDSP++ Linker and Utilities Manual.
Expert Linker graphically displays the available project information in an
.ldf file as input. This information includes object files, LDF macros,
libraries, and target memory descriptions. Use the drag-and-drop function
to arrange the object files in a graphical memory-mapping representation.
When you are satisfied with the memory layout, generate the executable
file (.DXE) via VisualDSP++ project options.
Linker window (Figure 1-4 on page 1-36). Use this display to modify the
memory map or the object mappings. When the project is ready to be
built, Expert Linker saves the changes to the .ldf file.
Expert Linker can graphically display space allocated to program heap and
stack. After you load and run your program, Expert Linker indicates the
used portion of the heap and stack. You can then reduce the size of the
heap or stack to minimize the memory allocated for the heap and stack.
Freeing up memory in this way enables it to be used for storing other
things like processor code or data.
You can launch the Expert Linker (see Figure 1-4) from VisualDSP++ in
three ways:
• Double-click the .ldf file in the Project window.
• Right-click the .ldf file in the Project window to display a menu
and then choose Open in Expert Linker.
• From the VisualDSP++ main menu, choose Tools, Expert Linker,
and Create LDF.
View Mode -> Memory Map Displays the memory map in tree mode
Tree
View Mode -> Graphical Displays the memory map in graphical blocks
Memory Map
View ->Mapping Strategy Displays the memory map, which shows where you intended to
(Pre-Link) place object sections
View -> Link Results Displays the memory map, which shows where the object sec-
(Post-Link) tions are actually placed
New -> Memory Segment Opens the Memory Segment Properties dialog box, from which
you specify the name, address range, type, width, and so on of
the memory segment that you want to add
New -> Output Section Adds an output section to the selected memory segment
New -> Shared Memory Opens the Shared Memory Properties dialog box, from which
you specify the name of the shared memory output file and pro-
cessors that share the memory
New -> Overlay Opens the Overlay Properties dialog box, from which you add a
new overlay to the selected output section or memory segment
Note: The new overlay’s run space is in the selected output sec-
tion.
View Section Contents Opens the Section Contents dialog box, which displays the con-
tents of the input or output section
Add Hardware Page Overlay Sets up hardware overlay live and run spaces for all available
Support hardware pages by:
a) Checking if memory segments are currently defined in all
hardware pages. If memory segments are located, you are
queried about whether to delete those segments.
b) Creating a memory segment containing an overlay (live space)
in each hardware page
c) Creating a memory segment containing all overlay run spaces
in hardware page 0
d) Creating a default mapping for each overlay. The default
mapping maps objects containing the section, “pmpage0”
to the hardware overlay on PM page 0, “pmpage1” to PM
page 1, “dmpage0” to DM page 0, and so on.
View Symbols Opens the View Symbols dialog box and displays the symbols for
the project, overlay, or input section
This command is available after you link the project and then
right-click on the Memory Map pane for a processor, memory
segment, output section, or input section.
Expand All Expands all items in the memory map tree to make their con-
tents visible
View Legend Opens the Legend dialog box, which shows all possible icons in
the tree window, with a brief description of each icon.
View Global Properties Opens the Global Properties dialog box for the selected object.
The dialog box’s title and content depend on the selected object.
This operation occurs after you load the program into a processor
target. The stacks and heaps are located by their memory segment
names, which may vary across processor families.
• Search the heap and stack for the highest memory locations written
to by the processor program
This operation occurs when the target halts after you run the pro-
gram. Assume that these values are the start of the unused portion
of the stack or heap. Expert Linker updates the memory map to
show how much of the stack and heap are unused.
Be aware of the following stack and heap restrictions.
• The heap, stack, and system stack must be defined in output
sections named HEAP, STACK, and SYSSTACK, respectively.
• The heap, stack, and system stack must be the only items in those
output sections. You cannot place other objects in those output
sections.
For other processor families, the restrictions on memory segment names
differ according to what is used in the default .ldf files. If you do not
heed these restrictions, you cannot view stack and heap usage after run-
ning your program.
Figure 1-5 shows an example memory map after you run a SHARC C
program.
Archiver
The VisualDSP++ archiver (elfar.exe) combines object (.doj) files into
library (.dlb) files, which serve as reusable resources for project develop-
ment. The linker searches library files for routines (library members)
referred to by other objects and links them in your executable program.
Run the archiver from within VisualDSP++ or from the command line.
From VisualDSP++, create a library file as your project’s output.
To modify or list the contents of a library file (or perform other operations
on it), you must run the archiver from a command line. For details, refer
to the VisualDSP++ Linker and Utilities Manual.
Splitter
The splitter (elfspl21k.exe) processes executable files to prepare
non-bootable programmable read-only memory (PROM) image files.
These files are executed from the processor’s external memory.
The splitter’s primary output is a PROM file with these extensions:
• .s_#, .h_#, and .stk (SHARC processors)
• .ldr (Blackfin and TigerSHARC processors)
For TigerSHARC processors, output from the splitter is 32 bit. For
SHARC processors, output from the splitter is 32 bit, 40 bit, 48 bit, or 64
bit.
To specify splitter options, choose Project > Project Options, and in the
tree control, click the Split page (or the Splitter subpage).
Splitter terms are defined as follows.
Loader
The loader (elfloader.exe) generates boot-loadable files by processing
executable files in addition to a loader kernel. The loader output (.ldr)
file enables the processor to boot from an external device (host or ROM).
boot kernel
The executable file that performs memory initialization on the
target
boot-loadable file
The loader’s output (.ldr), which contains the boot loader and the
formatted system configurations. This is a bootable image file.
boot loading
The process of loading the boot loader, initializing system memory,
and starting the application on the target
loader
The loader application, such as elfloader.exe, contained in the
software release
For more information about the loader, refer to the VisualDSP++ Loader
and Utilities Manual or VisualDSP++ Help.
Processor Projects
Your goal is to create a program that runs on a single-processor
(or multiprocessor) system. A project is the structure where programs are
built. All development in VisualDSP++ occurs within a project.
A project refers to the collection of source files and tool configurations
used to create a processor program. The project file (.dpj) stores program
build information.
VisualDSP++ provides flexibility for setting up projects. You configure
settings for code development tools and configurations, and you specify
build settings for the project and for individual files. You can set up fold-
ers that contain your source files. A project can include VDK support.
Use the Project window to manage projects from start to finish. Within
the context of a project, you can:
• Specify code development tools
• Specify project-wide and individual-file options for Debug or
Release configurations of project builds
• Create source files
VisualDSP++ facilitates movement among editing, building, and debug-
ging activities.
This section describes the following topics.
• “Project Wizard” on page 1-44
• “Project Options” on page 1-47
• “Project Groups” on page 1-48
• “Source Code Control (SCC)” on page 1-50
• “Makefiles” on page 1-51
• “Project Configurations” on page 1-56
• “Project Build” on page 1-57
Project Wizard
VisualDSP++ provides a Project Wizard (Figure 1-6) to simplify the
creation of a new project. The Project Wizard provides pages of options to
configure your new project. Depending on selections, various page and
options are available.
First, the wizard queries you as to what you want configured. Then it
generates a custom startup code file based on your choices, adds it to the
project, and modifies the linker settings to link in the customized .ldf
file. After defining the project, you can project changes later via the
Project Options dialog box.
Startup Code
Generate customized startup code for your project if you want to config-
ure the processor’s cache, the processor’s clock and power settings,
run-time initialization options, or compiler-instrumented profiling. If you
do use startup code, your application is built with the default behavior.
.LDF File
L Wizard
The ability to add a customized file to a project via the Project
.ldf
is available for Blackfin processor projects only.
.ldf file generation options relate to the user heap, system stack, system
heap, external memory, and so on. At a later time, you can modify the
.ldf file via the Project Options dialog box.
There are also special sections in the .ldf file in which you can insert your
own LDF commands, comments, and so on. These sections are preserved
each time the .ldf is re-generated; the information is stored in the
basiccrt.s file.
Project Options
Project options apply to the entire project. Specify project options in the
Project Options dialog box. Figure 1-7 shows an example of this
multi-paged dialog box.
Figure 1-7. Example: Project Options Dialog Box Showing Project Page
For each code development tool (compiler, assembler, linker, splitter, and
loader), one or more pages provide options that control how each tool
processes inputs and generates outputs. The available pages depend on
your target. Options correspond to tool command-line switches. You can
define these options once or modify them to meet changing development
needs.
L Tools
line.
can also be accessed from the operating system’s command
Project Groups
A project group enables you to work with a number of projects at once. A
project group can be empty or contain any number of projects. Opening a
project adds it to the project group. Closing a project removes it from the
project group. Similar functionality is found in Microsoft Visual Studio.
The Project window (Figure 1-8) displays the project group icon and the
projects opened in that workspace.
Each workspace has one project group. When you switch among work-
spaces, the project group is loaded and the same set of projects are opened
just as when you last closed the workspace.
One project is active at a time. The active project responds to commands
and messages from menus and toolbars. The Project window displays the
active project with bold typeface. A Project box, located by default with
the toolbar buttons, displays the name of the active project (see
Figure 1-9).
Project box
indicates the
active project.
Though commands are sent to the active project, they may also be carried
out by a project on which the active project depends. For example, assume
that project A is active and depends on project B. Executing a Rebuild All
command on project A builds project B first. The same logic applies to the
Clean command, which deletes intermediate and target files.
Exporting a makefile exports one makefile for each open project. In the
makefile of a project depending on another project, one sub-target is cre-
ated for each project on which it depends. Thus, building a project builds
all dependent projects first.
The project group file (.dpg), which is in XML format, contains a list of
project entries. Each project entry corresponds to a project in the group
and contains project information, including the path to the project file
(.dpj) and its dependent projects. Batch build specifications are saved in
the .dpg file for later use (so you can load and execute them without
re-specifying the same build targets). In the Project window, the root
node shows the project group’s file name without an extension.
Makefiles
Use a makefile (.mak or .mk) to automate builds within VisualDSP++.
The output make rule is compatible with the gnumake utility (GNU
Make V3.77 or higher) or other make utilities. VisualDSP++ generates a
project makefile that controls the orderly sequence of code generation in
the target. You can also export a makefile for use outside of VisualDSP++.
For more information about makefiles, go to:
http://www.gnu.org/manual/make/
A project can have multiple makefiles, but only one makefile can be
enabled (active).
The project in Figure 1-10 includes an active makefile (indicated by ).
The active makefile, with its explicit gmake command line, builds the
project. When no makefile is enabled for a project, VisualDSP++ uses
specifications configured in the Project Options dialog box.
You can view a makefile’s command line. To change the makefile’s target,
use the Configuration box, shown in Figure 1-11.
When you close a project, the Make commands and the target list associ-
ated with each makefile are serialized in the project (.DPJ) file.
Rules
You can enable only one makefile when building a project. If you enable
more than one makefile, VisualDSP++ generates an error message. After
you build your project with an external makefile, the executable file is not
automatically loaded (even when this option is configured).
Output Window
Make command error messages and standard output appear in the Output
window. Double-clicking on an error-message position opens the makefile
in an editor window to the line of code causing the error.
Keywords in the makefile are syntax-colored.
Note: The error message format of gmake is parsed correctly when you
double-click on an error message. If you use another make utility, the
double-click feature does not function.
Example Makefile
An example of a makefile appears below.
# Generated by the VisualDSP++ IDDE
# Note: Any changes made to this Makefile will be lost the next
# time the matching project file is loaded into the IDDE. If you
# wish to preserve changes, rename this file and run it
# externally to the IDDE.
# The syntax of this Makefile is such that GNU Make v3.77 or
# higher is required.
# The current working directory should be the directory in which
# this Makefile resides.
# Supported targets:
# Debug
# Debug_clean
# Release
# Release_clean
# Define ADI_DSP if it is not already defined. Define this
# variable if you wish to run this Makefile on a host other than
# the host that created it and VisualDSP++ may be installed in a
# different directory.
ifndef ADI_DSP
ADI_DSP=C:\Program Files\Analog Devices\VisualDSP
endif
# $VDSP is a gmake-friendly version of ADI_DIR
empty:=
space:= $(empty) $(empty)
VDSP_INTERMEDIATE=$(subst \,/,$(ADI_DSP))
VDSP=$(subst $(space),\$(space),$(VDSP_INTERMEDIATE))
# Define the command to use to delete files (which is different
# on Win95/98 and Windows NT/2000)
ifeq ($(OS),Windows_NT)
RM=cmd /C del /F /Q
else
RM=command /C del
endif
#
# Begin "Debug" configuration
#
ifeq ($(MAKECMDGOALS),Debug)
Debug : ./debug/mean.dxe
./debug/mean.doj :./mean.c ../../../include/stdio.h
$(VDSP)/cc21k -c .\Mean.c -g -proc ADSP-21062 -o
.\Debug\Mean.doj
./debug/benchmark.doj :./benchmark.asm
../../../include/asm_sprt.h ../../../include/def21060.h
$(VDSP)/easm21k.exe -proc ADSP-21062 -o
.\Debug\benchmark.doj -g .\benchmark.asm
./debug/mean.dxe :./debug/mean.doj ./debug/benchmark.doj
$(VDSP)/cc21k.exe .\Debug\Mean.doj .\Debug\benchmark.doj -proc
ADSP-21062 -L .\Debug -flags-link -od,.\Debug -o .\Debug\Mean.dxe
endif
ifeq ($(MAKECMDGOALS),Debug_clean)
Debug_clean:$(RM) ".\Debug\Mean.doj"
$(RM) ".\Debug\benchmark.doj"
$(RM) ".\Debug\Mean.dxe"
$(RM) ".\Debug\*.ipa"
$(RM) ".\Debug\*.opa"
$(RM) ".\Debug\*.ti"
endif
# Begin "Release" configuration
#
ifeq ($(MAKECMDGOALS),Release)
Release : ./release/mean.dxe
./release/mean.doj :./mean.c
$(VDSP)/cc21k -c .\Mean.c -O1 -proc ADSP-21062 -o
.\Release\Mean.doj
./release/benchmark.doj :./benchmark.asm
$(VDSP)/easm21k.exe -proc ADSP-21062 -o .\Release\benchmark.doj
.\benchmark.asm
./release/mean.dxe :./release/mean.doj ./release/benchmark.doj
$(VDSP)/cc21k.exe .\Release\Mean.doj .\Release\benchmark.doj
-proc ADSP-21062 -L .\Release -flags-link -od,.\Release -o
.\Release\Mean.dxe
endif
ifeq ($(MAKECMDGOALS),Release_clean)
Release_clean:
$(RM) ".\Release\Mean.doj"
$(RM) ".\Release\benchmark.doj"
$(RM) ".\Release\Mean.dxe"
$(RM) ".\Release\*.ipa"
$(RM) ".\Release\*.opa"
$(RM) ".\Release\*.ti"
endif
Project Configurations
By default, a project includes two configurations, Debug and Release,
described in Table 1-5. In previous software releases, the term configura-
tion was called “build type.”
A customized configuration
named Version2 is added.
Project Build
The term build refers to the process of performing operations (such as
preprocessing, assembling, and linking) on projects and files. During a
build, VisualDSP++ processes project files that have been modified since
the previous build as well as project files that include modified files.
A build differs from a rebuild all. When you execute the Rebuild All
command, VisualDSP++ processes all the files in the project, regardless of
whether they have been modified.
Building a project builds all outdated files in the project and enables you
to make your program. An outdated file is a file that has been modified
since the last time it was built or a file that includes (#include) a modified
file. For example, if a C file that has not been modified includes a header
file that has been modified, the C file is out of date.
Build Options
You can specify options for the entire project and for individual files.
Table 1-6 describes these build options.
File Building
Building a file compiles or assembles the file and locates and removes
errors. You can build a single file or multiple files that you select.
Project Specify these options from a tabbed page (for example, Compile or
Link) for each of the code development tools.
Custom build For maximal flexibility, edit the command line(s) issued to build a
particular file. For example, you might call a third-party utility.
The build process updates the selected source file’s output (.obj) file and
the output file’s debug information. Building a single file is very fast.
Large projects, however, may require hours to build.
If you change a common header file that requires a full build, you can
build only the current file to ensure that your change fixes the error in the
current file.
Batch Builds
Performing a batch build builds one or more build targets in the open
project group. You must configure the batch build before you can build it.
A build target in a project group is formed by the combination of a project
and a project configuration (such as a Release configuration). Refer to
VisualDSP++ Help for details on configuring and running a batch build.
Command Syntax
Place “c:\windows\command.com /C” at the beginning of each DOS
command line. For example, to execute “copy a.txt b.txt”, type:
c:\windows\command.com /C copy a.txt b.txt
Project Dependencies
Dependency data determines which files must be updated during a build.
The following are examples of dependency information.
..\.\.\include\cplus\cstddef
..\.\.\include\cplus\exception
..\.\.\include\cplus\new
..\.\.\include\cplus\xstddef
..\.\.\include\def21060.h
..\.\.\include\limits.h
..\.\.\include\cplus\stddef
..\.\.\include\stdio.h
..\.\.\include\string.h
..\.\.\include\VDK_Internals.h
..\.\.\include\VDK_Public.h
..\.\.\include\yvals.h
The majority of the Help system files are VisualDSP++ manuals and
hardware documentation. These manuals are also available in PDF format
(on the installation disk) for printing. Manuals are also available from
Analog Devices as printed books.
Each window, toolbar button, and menu-bar command in VisualDSP++ is
linked to a topic in Help. Other portions of the VisualDSP++ Help system
provide procedures for configuring and using tools.
Some .chm files support pop-up messages for dialog box controls (buttons,
fields, and so on). These messages, which appear in little yellow boxes,
comprise part of the context-sensitive Help in VisualDSP++.
For more information about the Help system, refer to “Online Help” on
page A-53 and to “Using this Help System” in VisualDSP++ Help.
Project Window
To open a Project window, choose View and Project Window. Figure 2-1
shows a Project window with VDK enabled.
Project View
The Project view displays a project group, which may contain any number
of projects. Only one project, however, is active at a time. Nodes are
arranged in a hierarchy similar to the file structure in Windows Explorer.
Figure 2-2 shows an example of information that displays in Project view.
Active
project
Kernel Tab
The Kernel tab of the Project window is available only for VDK-enabled
projects.
From the Kernel view, you can add, modify, and delete kernel elements
such as thread types, priorities, semaphore, and events. VisualDSP++
automatically updates vdk_config.cpp and vdk_config.h to reflect the
changes made on the Kernel view.
The example in Figure 2-3 shows an expanded view of the elements on the
Kernel tab for a VDK-enabled project.
For information about VDK, refer to the VisualDSP++ Kernel (VDK)
User’s Guide.
Project Dependencies
A project may depend on other projects. The icon indicates depen-
dency and identifies the dependency. Building a project also builds the
sub-projects on which your project depends.
Figure 2-4 shows how project dependencies appear in the Project view.
Project Nodes
The Project window comprises the types of nodes described in Table 2-1.
Project Folders
Project window folders ( and ) organize files within a project. You
can specify properties for folders.
Folders can be nested to any depth. Folders carry no attributes to the build
process, as they do not reflect the file system. Folders do not appear in
directory listings, as in Windows Explorer.
When you add files to the project tree with automatic file placement, each
file is placed in the first folder configured with the same file extension.
After automatic placement, you can manually move a file anywhere.
To move a file out of one folder and into another folder, select the file and
drag it onto the other folder.
Project Files
In the Project window, files are represented by the icons in Table 2-2.
L dow,
File icon commands apply to the selected file in the Project win-
not to a source file in an editor window.
File Associations
VisualDSP++ associates the file extensions in Table 2-4 as the input to
particular code development tools.
Example
You create a folder labeled “C Source Files” and specify it with .c, .cpp,
and .cxx file extensions. You create a second folder labeled “Asm Files”
and associate it with .asm files.
If you drag three files (file1.cpp, file1.asm, and file2.c) into the
Project window, file1.cpp and file2.c go into the C Source Files
folder, and file1.asm goes into the Asm Files folder.
Editor Windows
Use editor windows to view and edit files. Open as many editor windows
as you like from the Project window by double-clicking on a file or by
choosing Open File from a file’s right-click menu.
This section describes the following topics:
• “Editor Window Features” on page 2-17
• “Editor Window Symbols” on page 2-18
• “Bookmarks” on page 2-19
• “Syntax Coloring” on page 2-19
• “Viewing Modes: Source Mode vs. Mixed Mode” on page 2-20
• “Editor Tab Mode” on page 2-21
• “Context-Sensitive Expression Evaluation” on page 2-23
• “Compiler Annotations” on page 2-24
• “Right-Click Menu” on page 2-39
Toggle
book-
marks
Bookmark
Bookmarks
Bookmarks are pointers in editor windows. Place a bookmark in a location
to return to it quickly at a later time.
Syntax Coloring
Specifying colors can help you locate information in the types of files
listed in Table 2-7.
Assembly .asm
C .C
C++ .CPP
Header .H
Source Mode
Source mode, as shown in Figure 2-11, displays C code only.
Mixed Mode
Mixed mode displays assembled code immediately after the corresponding
C code. The assembly code takes a specified color.
Figure 2-13 shows an editor window with the Editor Tab option enabled.
Figure 2-13. Switching Between Editor Windows Using Editor Tab Mode
Viewing an Expression
Expressions can be viewed in different ways. When the editor window is
in mixed mode, view an expression by moving the pointer over a register
in an assembly instruction. The register contents are displayed in a tool
tip.
Highlighting an Expression
Highlight an expression in the editor window and then move the pointer
on top of the highlighted expression to display its value in a tool tip.
Compiler Annotations
When enabled, the compiler can perform a large number of optimizations
in order to generate the assembly code. The decisions taken by the com-
piler as to whether certain optimizations are safe or worthwhile may be
viewed. This information can help you understand how close to “optimal”
a program is and what can be done to improve the generated code. For
more information about optimizing code, refer to your processor’s
VisualDSP++ C/C++ Compiler and Library Manual.
The compiler optimizer’s feedback is provided as annotations made to the
assembly file generated by the compiler. You can view compiler annota-
tions in C/C++ files in editor windows. The annotations are inserted
Compiler
annotation
icon
Hover the mouse cursor over an annotation icon to display the compiler
annotations in a tooltip (if it fits a tooltip). When there are multiple anno-
tations, the number of compiler annotations appears in the tooltip. (See
Figure 2-15).
Right-Click Menu
The editor window’s right-click menu provides the commands shown in
Figure 2-18.
Output Window
The Output window displays:
• Standard I/O text messages such as file load status
• Build status information for the current project build
• Code development tools messages and provides access to errors in
source files
The Output window also serves as a scripting interface.
The example Output window in Figure 2-19 shows build status informa-
tion. Display the Output window by choosing View and Output
Window.
Choosing Next Error or Prev Error from the Edit menu allows you to
scroll through error messages.
Double-clicking on an error message displays the offending code in an edi-
tor window. For more information, see “Viewing Error Message Details”
on page 2-33..
By default, VisualDSP++ output is blue and tool output is black. You can
modify these colors by using the Preferences dialog box.
Console Page
The Output window’s Console page (Figure 2-24 on page 2-39) allows
you to:
• View VisualDSP++ or target status error messages
• View STDIO output from C/C++ programs
• View I/O (streams) messages
• Scroll through previous commands by pressing the keyboard’s up
arrow and down arrow keys
• Perform multiline selection, copy, paste, and clear
• Issue script commands and view script command output
• Auto-complete script commands
• Execute a previously issued script command by double-clicking on
the command
• Enter multiline script commands by adding a backslash character
(\) to the end of a statement
• Use bookmarks
• Toggle a bookmark by pressing Ctrl+F2
• Move to the next bookmark by pressing the keyboard’s F2 key
All text that displays on the Console page is written to the VisualDSP++
log file.
Fatal error Identifies errors so severe that further processing of the input is suspended.
Fatal errors are sometimes called catastrophic errors.
Error Identifies problems that cause the tool to report a failure. An error might
allow further processing of the input to permit the reporting of additional
problems to be reported.
Warning Identifies situations that do not prevent the tool from processing the input,
but may indicate potential problems
You can change the severity level of a message marked with a “{D}”, which
means “discretionary”. The severity level of a message without a “{D}” is
“non-discretionary” and cannot be changed.
L Towindow.
view the details of a message, it must be viewed from the Help
If you run a tool from a command-line interface (such as a
Command Prompt window or MS-DOS Prompt window), the
message shows only the ID code, error text, and error location.
Identification Code Six-character code, unique to the message. The first two char-
acters identify the tool:
• ar (archiver)
• cc (compiler)
• ea (assembler)
• el (expert linker)
• id (IDDE)
• li (linker)
• pp (preprocessor)
• si (simulator)
• xml (custom board support)
Error Text Text that appears after the identification code in the Output
window
Error Code
Descriptive text
int main(void)
{
int x; // no initial value
printf("x = %d\n", x);
return foo();
}
Notice that the compiler appended the letter “D” to each warning message,
indicating that the message is discretionary.
The -Wremark 549,117 flag in the following command demotes two spe-
cific messages to remarks. The command produces no output because all
the messages are changed to remarks, which are not displayed.
$ cc21k -c test.c -Wremark 549,117
The following command changes the two warnings to remarks and then
displays all seven remarks.
$ cc21k -c test.c -Wremark 549,117 -Wremarks
Log File
The VisualDSP++ log file contains all the status and error messages that
have been written to the Output window’s Console page.
Figure 2-23 shows a sample log file.
All sessions append to the log file. Occasionally, open the file and
delete parts of it (or all of it) to conserve disk space.
By default, the Output window resides at the bottom of the main applica-
tion window. You can resize or move the Output window to a different
portion of the screen by dragging it to the selected location. You can dock,
hide, or float the window.
The Output window’s Console page interacts with script engines. All
script input and output is sent to the Console page, as shown in
Figure 2-24.
Right-Click Menu
The Output window’s right-click menu is shown in Figure 2-25.
This menu enables you to:
• Load a script or enable the debugger
• Clear the text in the window or copy selected text
• Toggle bookmarks
• Select a scripting language
The main benefit of calling scripts in these languages is that they have
support for COM scripting, which allows access to the VisualDSP++
Automation API. VisualDSP++ supports the following Microsoft ActiveX
script engines (languages):
• Visual Basic® (Scripting Edition)
• JScript®
• Load a script
You can load a script by selecting Load Script from the File menu,
from the Console view’s right-click menu or the editor window’s
right-click menu. The script loads and runs until it finishes run-
ning or until you halt the script by choosing Halt Script from the
Debug menu.
The Console view supports script command auto-completion, which you
can enable on the General page of the Preferences dialog box, accessible
via the Settings menu.
The VisualDSP++ installation directory includes example scripts in the
“Scripting Examples” folder located under the processor family name
(for example, 21k) and the Examples folder.
Debugging Windows
VisualDSP++ provides debugging windows to display program operation
and results. Table 2-10 describes these windows.
Output A Console page that displays standard I/O text messages such as file load
(on page 2-28) status, and error messages and streams, and a Build page that displays
build messages. You can interactively enter script commands and view
script output.
Disassembly Code in disassembled format. This window provides fill and dump capa-
(on page 2-45) bility.
Expressions The means to enter an expression and see its value as you step through
(on page 2-50) program execution
Locals All local variables within a function. Use this window with Step or Halt
(on page 2-54) commands to display variables as you move through your program.
Linear Profiling (Simulation only) Samples of the target’s PC register taken at every
(on page 2-55) instruction cycle, which provides an accurate picture of where instructions
were executed. Linear profiling is much slower than statistical profiling.
Statistical Profiling (JTAG emulation only) Random samples of the target processor’s program
(on page 2-55) counter (PC) and a graphical display of the resulting samples, showing
where the application spends time
Call Stack A means of moving the call stack back to the previous debug context
(on page 2-63)
Register Pre-configured windows display current values of registers. You can change
(on page 2-78) register contents and change the number format.
Custom Registers User-defined windows display the values of registers. Select the Analog
(on page 2-81) Devices processor memory-mapped registers [MMRs]) registers that you
want to monitor.
Custom Registers Custom board support. Display contents of registers on custom boards.
(on page 2-82) View any register (not just Analog Devices processor memory-mapped
registers [MMRs]). User-defined layout.
Memory A view of processor memory. Similar number format and edit features as
(on page 2-67) register windows, plus fill and dump capability.
BTC Memory A view of background telemetry channel contents in real time. The win-
(on page 2-73) dow displays the contents of the address that you want to see.
(SHARC and Blackfin emulator sessions only)
Plot A graphical display of values from memory addresses. The window sup-
(on page 2-109) ports linear and FFT (real and complex) visualization modes and allows
you to export an image to a file, the clipboard, or to a printer.
VDK State History (VDK-enabled projects only) History buffer of threads and events
(on page 2-105)
Target Load (VDK-enabled projects only) Percent of time the target spent in the idle
(on page 2-108) thread
VDK Status (VDK-enabled projects only) At a program halt, thread state and status
(on page 2-103) data
Image Viewer A view of BMP, JPEG, PPM, or MPEG data from processor memory or
(on page 2-119) from a file on your PC. You can edit, copy, print, or export image data.
Disassembly Windows
By default, a Disassembly window appears when you open a new session.
You can open a Disassembly window by choosing View, Debug Win-
dows, and Disassembly.
Figure 2-27 and Figure 2-28 show examples of Disassembly windows, one
with and one without the address bar enabled. The address bar shows
recently used addresses, symbols, and expressions.
Address bar
The color of the current source line and other window items are user con-
figurable. Refer to VisualDSP++ Help for detail.
Move to a different address An address field and double-click. Then select the address from
the ensuing Go To dialog box. Note that you can also use the
address bar to navigate to an address, symbol, or expression.
Toggle (enable or disable) An instruction and right-click. Then choose the appropriate com-
a breakpoint mand from the ensuing menu.
Right-Click Menu
The Disassembly window’s right-click menu provides access to the com-
mands shown in Figure 2-30.
(Gray arrow) The current instruction is being aborted due to a branch or jump
instruction.
(Yellow arrow) This instruction is currently in the Execute stage of the pipeline.
Expressions Window
The Expressions window (Figure 2-31) lets you enter an expression to
evaluate in your program. Evaluations are based on the current debug con-
text. Open this window by choosing View, Debug Windows, and
Expressions.
The Name and Value columns are always visible. Other columns
(Address, Type, Size, and Format) are user-defined. You can select the
number format used by the window (global format). You can override the
global format and specify each expression's format (per-expression basis).
Changing the window's global format overrides any per-expression for-
matting; for example, if the global format is set to Hexadecimal and you
set the format of a single expression to Integer, changing the global format
to Float will change the format of every expression to Float.
L Because of the way registers are saved and restored on the stack, the
register value on which the expression relies may be incorrect if you
change VisualDSP++’s context from the Call Stack window.
Register expression Precede register names with a $ sign, for example: $r0, $r1,
$ipend, $po, or $imask
@processor_name(expression)
As you step through your program, the Expressions window displays the
current value of each listed expression. Expressions evaluation is based on
the current debug context.
For example, if you enter expression “a” and a global variable “a” exists,
you see its value. If you then step into a function that has local variable
“a”, the local value displays until the debug context leaves the function.
When a variable goes out of context, a string displays next to the variable,
informing you that the variable is out of context.
The expressions described above are C expressions. The current syntax
also allows the use of registers in expressions.
For example, the following expression is valid.
$R0 + $I0
Trace Windows
Perform a trace (also called an execution trace or a program trace) to
analyze the run-time behavior of a processor program, to enable I/O
capabilities, and to simulate source-to-target data streaming. Figure 2-32
shows an example of data in a Trace window.
Locals Window
The Locals window displays the value of local variables within a function,
as shown in Figure 2-33. Open this window from the View menu by
choosing Debug Windows and Locals.
Use the Locals window with a Step or Halt command to display the cur-
rent value of variables when moving through your program.
You can select the number format used by the window (global format).
You can override the global format and specify each expression's format
(per-expression basis). Changing the window's global format overrides any
per-expression formatting; for example, if the global format is set to Hexa-
decimal and you set the format of a single expression to Integer, changing
the global format to Float will change the format of every expression to
Float.
Complex variables, C structures, and C++ classes appear with a plus
sign. Click on the plus sign to display all variable information.
Window Components
The window, which comprises two panes and a status bar, provides a
right-click menu for performing various window functions.
Left Pane
The window’s left pane displays a list of the executed functions, assembly
source lines, and PCs (with no debug information). The time that each
item spends on execution appears as a histogram and as a percent. The
order of the items in the display is determined by the percentage of global
execution time for each item.
The left pane includes the information described in Table 2-14.
Execution Unit Functions, assembly source lines, These items are sorted by the percent-
and PCs for which no debug age of global execution time that each
information exists item took to execute. The highest per-
centage items appear at the top of the
list
Right Pane
The right pane includes the information described in Figure 2-15.
% Execution percent in text format with two decimal places, for example:
1.03%
-or-
the PC sample count for each source line
File Entire source file. Each source line occupies one line in the grid control.
Status Bar
The status bar at the bottom of the window indicates the total number of
collected PC samples, the total elapsed time, and indicates whether statis-
tical profiling is enabled.
Right-Click Menu
The Statistical Profiling and Linear Profiling windows provide a
right-click menu. The menu commands depend on the context (whether
you right-click in the left pane or right pane) and the current settings.
Table 2-16 describes the right-click menu commands.
Window Operations
You can select various options for the Statistical/Linear Profiling window
and perform various window operations.
For power estimation, this window displays two additional columns. Refer
to “Energy-Aware Programming” on page 3-31 for more information.
When you view the window in mixed mode, profiling data for each assem-
bly line displays, as shown in Table 2-39. Mixed mode displays profiling
statistics for individual assembly instructions.
Figure 2-39. Profiling Data for Each Assembly Line (Mixed Mode)
The profiling results after filtering (Table 2-41) reflect the difference.
Use this debugging feature by walking up the call stack and viewing local
variables in different scopes. Use this window to analyze the state of par-
ent functions when erroneous data is being passed to the currently
executing function and to see the context from which the current function
is being called.
The Call Stack window provides call stack information when:
• Debug information is available
• Debug information is not available
L Frame pointers in the call stack that do not have debug symbols
associated with them may appear in the Call Stack window as man-
gled assembly labels or memory addresses with an offset.
Memory Windows
Use Memory windows to:
• View and edit memory contents
• Display the address of a value. Move the mouse pointer over the
value, and hold down the keyboard’s Ctrl key.
• Lock the number of columns currently displayed. This action
resizes the window horizontally without altering the display.
• Track one expression
You open memory windows from the Memory menu.
Memory windows provide:
• Number format and edit features
• Fill and dump capabilities
• An optional address bar for fast navigation to recently used
addresses, symbols, or expressions
To display the address bar, right-click in a memory window and
choose Address Bar. A check mark next to this command on the
right-click menu indicates that this option is enabled.
Available
formats depend
on processor
Title bar
Select the
expression
you want
to track
L The commands available via the menu bar’s Memory menu and the
memory window’s right-click menu depend on the processor that
you are debugging.
BTC_MAP_BEGIN
BTC_MAP_ENTRY ('Channel0', 0xf0001000, 0x00100)
BTC_MAP_ENTRY ('Channel1', 0xf0002000, 0x01000)
BTC_MAP_ENTRY ('Channel2', 0xf0003000, 0x10000)
BTC_MAP_END
which marks the beginning of the BTC map. Next, each individual chan-
nel is defined with the BTC_MAP_ENTRY macro, which takes the parameters
described in Table 2-17.
Once the channels are defined, end the BTC map by using the
BTC_MAP_END macro.
JUMP _btc_isr;
After the interrupt vector is installed, the interrupt itself must be enabled
with the following code:
// setup imask
ustat1 = imask;
BIT SET ustat1 EMULI;
imask = ustat1;
// enable interrupts
ustat1 = mode1;
BIT SET ustat1 IRPTEN;
mode1 = ustat1;
BTC Priority
On ADSP-2126x and ADSP-BFBF36x SHARC processors, BTC data
transfer is handled through the low-priority emulator interrupt (EMULI).
Since the priority of this interrupt is fixed, the priority of BTC is also
fixed.
The priority of the BTC can impact the response time from when the host
requests data and the processor responds. Once the processor begins to
service the request, interrupts can still be serviced by the processor. BTC
performance can be affected by the frequency of system interrupts.
Figure 2-52 shows the list of currently defined channels and the contents
of the selected channel.
Show Map Shows or hides a more informative map display of all the current chan-
or nel definitions
Hide Map Show Map displays a channel list. Double-click a channel to display its
contents in the lower portion of the window.
Hide Map removes the list of channels. The selected channel remains
in the display.
Lock Columns Locks or unlocks the number of columns currently displayed in the
window
Select Format Specifies how to display data in the window. Choices include double
words (32 bits), words (16 bits), and bytes (8 bits).
Refresh Rate Specifies the refresh rate, which is used when Auto Refresh is chosen.
The display is updated at the selected interval.
Auto Refresh Enables the window to refresh itself at given intervals. The rate is spec-
ified by Refresh Rate. Auto Refresh mode is valid only while the pro-
cessor is running.
Channel Timeout Specifies the length of time to wait for any single response from the
BTC. If the timeout value is exceeded, the current transaction ends.
Register Windows
Access various register windows via the VisualDSP++ Register menu. The
available commands (and subsequent windows) depend on the processor.
Stack Windows
Depending on your processor, access to various stack windows is available,
including:
• PC stack
• Counter stack
• Loop tack
• Status stack
Access stack windows via the Register menu. For more information about
your processor’s stack windows, consult VisualDSP++ Help.
• View the content of any register on your custom board (not just
Analog Devices processor memory-mapped registers [MMRs])
• Display your custom register windows via the VisualDSP++
IDDE's Register menu (you configure menu items that open the
customized register windows)
For detailed information and examples on using custom board support,
refer to online Help.
Multiprocessor Window
Use the Multiprocessor window (Figure 2-56) to select and control the
different processors in a multiprocessor debug session.
Status Page
The Status page (Figure 2-57) shows the status of each processor in the
multiprocessor system. A horizontal bar highlights the processor with
focus.
Change focus by clicking on a processor in the list.
Groups Page
The Groups page (Figure 2-58) shows the current list of multiprocessor
groups. A Default group is created with each new multiprocessor session.
The members of the Default group are the processors that you checked off
under Multiprocessor System in the New Session dialog box.
From the Groups page, you can assign one or more processors to a group.
Performing a multiprocessor operation (MP Run, MP Halt, MP Step,
MP Reset, and MP Restart) affects only the processors in the currently
selected group.
Right-clicking on the Group page displays a context menu for adding or
removing a group.
Focus
Processor focus changes, depending on the window currently selected.
To move focus among the processors, click on a processor listed in the
Multiprocessor window (Figure 2-56).
You can pin a register window, a memory window, or Disassembly win-
dow to a specific processor. Select the processor in the Multiprocessor
window and right-click in the window that you want to pin. Then choose
Pin to Processor to lock the window to the selected processor. A window
pinned to a processor always displays that processor’s data, regardless of
the currently focused processor.
For example, if a register window is pinned to Processor 1 and a memory
window is pinned to Processor 2, selecting the register window moves the
focus to Processor 1. Selecting the memory window moves the focus to
Processor 2. The Multiprocessor window’s Status page reflects the change
in focus.
Right-Click Menu
The Multiprocessor window’s right-click menu (Figure 2-59) offers these
commands:
• Add New Group
• Rename Group
• Delete Group
• Select All Processors
• Unselect All Processors
• Allow Docking
• Hide
• Float in Main Window
Enabled Enables and disables collection of pipeline data while running or step-
ping
Save Opens the Save As dialog box, where you export the collected data to a
text file
Properties Opens the Pipeline Viewer Properties dialog box, where you view and
specify properties (buffer and display depth, display format, column
widths, grid lines, and the appearance of stages) for the Pipeline Viewer
window. You can also modify window colors.
Buffer depth Specifies the total number of pipeline samples to retain at any
time. When this buffer overflows, the oldest data shifts out to
make room for new samples. The default is 100.
Show gridlines Toggles the display of gridlines in the window. The default is On.
Auto-size columns Automatically sizes all columns to have the same width as samples
are collected. The default is On.
Stages to view Specifies the stages to appear in the window. Note that all stages
are collected, but you view only the stages that you select to
appear.
From the dialog box’s Colors tab, you can specify the colors that display
in the Pipeline Viewer window. The current color appears under Current
Color. Click a color in the color palette or click Other to specify a custom
color. Click the Reset button to restore the default colors.
The icons in the above table are listed in descending priority. When more
than one event occurs at a certain stage at a certain cycle, only one icon
displays—the icon with highest priority. For example, if an instruction
that was a Branch Target Buffer hit is aborted, the Abort icon appears.
Figure 2-61. Example: Tool Tip Box Showing Pipeline Event Details
Enabled Enables and disables collection of cache data while the target is
running or stepping
Clear Clears all displays and deletes all stored cache data
Map References Opens the Map References dialog box, where you specify the
cache reference map (start address and end address)
Event Log -> Read Opens the File Open dialog box, where you select and open a
cache events log file. The log file data is used by the Cache
Viewer window’s Configuration view.
Event Log -> Write Opens the File Save dialog box, where you save a cache events
log file. Cache events are written to this log file.
Event Log -> Step Executes one cache event at a time from the cache events log
file. The cache event displays in the Detailed View, History,
and Histogram pages of the Cache Viewer window.
Properties Opens the Cache Viewer Properties dialog box, where you
specify the Cache Viewer window’s appearance
L The cache events log file does not include icons. Thus, the Cache
Viewer window’s Detailed View page does not display icons.
Stepping enables you to execute one cache event at a time from the cache
events log file. The cache event displays on the Detailed View, History,
and Histogram pages. When stepping is configured, a check mark appears
next to the Step command on the right-click menu. By default, this
option is enabled when a cache events log file is opened for reading.
Configuration Page
The Configuration page (Figure 2-63) displays configuration information
for configured cache.
The Cache Selection pull-down box (top of dialog box) lists cache dis-
plays. When multiple caches are configured, use this list to change cache
displays.
The Cache Configuration list box (below the Cache Selection pull-down
box) displays a list of items and their values. The first three items (Cache
Name, Number of Sets, and Number of Ways) are required. The target
may display additional items, such as Cache Size and Line Size. The list of
items depends on the selection in the Cache Selection pull-down box.
Data received from a cache event is placed in the cell corresponding to the
cache set and way. The most recent cache events are highlighted.
Each cell has an icon and text entry. The icon indicates the type of cache
event (hit, miss, and so on) that occurred. Depending on the selected
objects, details (such as reference address, PC address, cycle count, event
type, event description, and so on) can be shown.
Pressing down the keyboard’s Ctrl key and moving the mouse over a cell
displays a tooltip, showing cache event and cache line information.
A lock icon in the column header indicates that the cache way is locked.
A reference map icon in the Set # column indicates the results of the refer-
ence mapper function. Double-clicking on a cell switches the display to
the history view (History page) for the selected cell.
History Page
The History page (Figure 2-65) displays detailed information for each
cache event that occurred in the selected set and way.
Select the set and way from the pull-down control (top of dialog box) or
by double-clicking a cell on the Detailed View page.
You can specify the number of stored cache events. Sort the rows by click-
ing on any column heading. An up arrow in a column heading indicates
an ascending sort order; a down arrow indicates a decending sort order.
Table 2-25 describes cache event history information.
Index # Shows the order in which the cache events were received. The
index starts at zero and increments each time a cache event is
received.
Set # Displays the set number where the cache event occurred
Way # Displays the way number where the cache event occurred
Cycle Displays the cycle count when the cache event occurred
Symbol Lookup Displays the symbol name when the reference address resolves
to a symbol in memory
Valid Displays the cache line valid flag. (The values are Yes or No.)
Event Type Displays the cache event type, such as Hit or Miss
Description Displays the cache event’s description
Performance Page
The Performance page (Figure 2-66) shows a list of performance metrics
(items and values), which are determined by the target.
The target updates this list. The update rate, however, is not
predetermined.
Histogram Page
The Histogram page (Figure 2-67) shows a plot of the total number of
cache events that occurred in each cache set.
A vertical line displays for each cache set. The line starts at zero and ends
at the total number of cache events. Use this plot to identify the most
active cache sets.
Cache events display as icons, identical to the icons used in the detailed
view. A start address and count are required. Enter the start address as a
hexadecimal value or a symbol. Click the browse (…) button to browse for
a symbol.
The count determines the number of addresses displayed. After entering a
start address and count, click Update to display the cache event data. Use
horizontal and vertical scroll bars to scroll the view.
Window Operations
The status bar (at the bottom of the plot) on the State History page shows
the event’s details and thread status when the data cursor is enabled. Event
details include the event type, the tick when the event occurred, and an
event value. The value for a thread-switched event indicates the thread
being switched in or out.
Right-click on the plot and choose Data Cursor to activate the data cur-
sor, which is used to display event and thread status details. Based on the
event that occurred, the thread status changes. Press the keyboard’s right
arrow key or left arrow key to move to the next or previous event. When
the data cursor hits a thread-switched event, it moves to the thread being
switched in. The yellow triangle to the left of the thread name indicates
the currently active thread.
You can zoom in on a region to examine that area in more detail. Perform
this procedure:
1. Hold the left mouse button down while dragging the mouse to cre-
ate a selection box.
2. Release the mouse button to expand the plot.
3. To restore the plot to its original scale, right-click on the plot and
choose Reset Zoom.
Right-Click Menu
The VDK State History window’s right-click menu provides easy access
to operations that can be performed from the state history plot.
A load of 0% indicates that VDK spent all of its time in the Idle thread. A
load of 100% indicates that the target did not spend any time in the Idle
thread.
Load data is processed by means of a moving window average.
Plot Windows
Use a plot window to display a memory plot, which is a visualization of
values obtained from processor memory. You can display one or multiple
plot windows by choosing View, Debug Windows, Plot, and New.
In the Plot Configuration dialog box, specify the contents of a plot. In the
Plot Settings dialog box, specify the plot’s presentation. You can modify a
plot’s configuration and immediately view the revised plot.
Figure 2-72 shows an example of a plot window.
From a plot window, you can zoom in on a potion of a plot or view the
values of a data point.
You can print a plot, save the plot image to a file, or save the plot’s data to
a file. For details, refer to VisualDSP++ Help.
Status Bar
The status bar, located at the bottom of the plot window, displays the plot
type and other information, depending on the plot type and other
settings.
The following examples show different plot information displayed on the
status bar.
In a waterfall plot, the status bar indicates the azimuth and elevation view-
ing angles. If you zoom in on a region, the status bar indicates that zoom
is enabled. When using the data cursor, the status bar shows the selected
point’s data value.
When a plot window’s auto-refresh mode is enabled in BTC mode, the
status bar indicates current buffer capacity (for example, 38%) and data
logging status.
Tool Bar
The plot window’s toolbar, shown in Figure 2-74, provides buttons for
recording and playing back streaming data and a box for specifying
streamed data (.bin) file names.
Right-Click Menu
The plot window’s right-click menu is shown in Figure 2-75.
This menu provides access to the standard window options (docking,
closing, and floating in the main window) and to the plot window features
described in Table 2-27 on page 2-114.
Play New
Stop Record Open Filename
Data Cursor Displays the data value associated with the position of the plot
window’s data cursor. View the value on the left side of the plot
window’s status bar. Press the keyboard’s arrow keys to move
around the graph.
Reset Zoom Resets the plot window to its initial full-scale display
Configure Opens the Plot Configuration dialog box, where you add, remove,
or modify data sets. You can also change the plot type and rename
the plot.
Modify Settings Opens the Plot Setting dialog box, where you customize the plot’s
appearance. You can specify plot settings (grids, colors, margins,
fonts, axes, and so on) and settings for each data set (data process-
ing).
Save Settings Saves plot configuration settings for future use. The configuration
is stored, but not the data. You can retrieve settings (.VPS file) and
load new plot data.
Export Exports the plot image to various destinations including the Win-
dows clipboard. Save the plot image as a file (JPG, GIF, TIF, EPS,
TXT, or DAT format) or print a hard copy.
Auto Refresh Settings Enables you to configure options that control auto-refresh settings
for plot windows. These settings determine the method in which
memory is transferred.
Plot Configuration
A plot configuration comprises two parts: data values and presentation
(configuration) settings.
A plot window must contain at least one data set, a series of data values in
processor memory. Create data sets in the Plot Configuration dialog box,
shown in Figure 2-77.
Specify the type of plot (for example, waterfall), the memory location, the
number of values, the axis associated with each data set, and other options
that identify the data. Note that three-dimension (3-D) plots require addi-
tional specifications for row and column counts.
The Settings button enables the configuration of presentation options
(such as titles, grids, fonts, colors, and axis presentation) for each data set.
You can recall a plot from a saved settings file (.vps). VisualDSP++ uses
these settings and reads processor memory to display a plot window.
The Plot Settings dialog box provides the tabs shown in Figure 2-78.
Options on the tab pages enable you to configure the plot window’s
presentation. On the Style page, for example, you can easily specify sym-
bols for a data set as well as line type and width, as shown in Figure 2-79.
General Title and subtitle, grid lines, margins, background colors, and legend
2-D Axis For X-axis and Y-axis: axis titles, start and increment values, scales
3-D Axis For X-axis, Y-axis, and Z-axis: axis titles, Z-axis settings, step sizes, scale
multipliers, color and mesh
Style For a data set: line type, width, color; symbol and type
Data Processing For a data set: data processing algorithm, sample rate, and triggering
Image Viewer
The Image Viewer window reads and displays image data from processor
memory or a file on your PC. Use this window to configure image
attributes and to view images. This display is ideal for testing image-pro-
cessing algorithms.
Figure 2-81 shows a typical Image Viewer window. The status bar indi-
cates the DSP address, RGB values, and pixel coordinates.
Tools
You select the image source (from processor memory or a file on your PC)
and specify image attributes. If the image is located in processor memory,
you must specify the image’s address, size, and format.
The Image Viewer supports the following pixel formats: Grayscale 8,
Grayscale 12, Grayscale 16, RGB555, RGB565, RGB24, and RGB32.
To open the Image Viewer window, choose View, Debug Windows, and
Image Viewer.
Refer to Help for information about format types, packed data, and
detailed how-to information.
Automation Interface
The Image Viewer has an automation interface that permits COM-aware
languages to access Image Viewer functions, such as loading, retrieving,
displaying, and saving data.
Toolbar
The top of the window provides these tools:
Zoom Cancel
Save. Opens a Save dialog box, from which to save the image.
Status Bar
As you move the mouse over the image, the status bar indicates:
• Zoom status
• Processor address where the selected pixel is located
• Pixel values for color images, intensity values for gray-scale images
• Pixel coordinates (column and row)
L Pixel color depth (24 bits for color images and 8 bits for gray-scale
images)
Right-Click Menu
The Image Viewer window's right-click menu provides these commands:
Configure Opens the Image Configuration dialog box, from which to specify
image attributes
Color - Gamma Adjust Opens the Image Effects dialog box, from which to adjust gamma
and view the resulting image
Rotate Provides four selections: 0, 90, 180, or 270
Auto-Refresh Settings Opens the Auto-Refresh Settings dialog box, from which to config-
ure auto-refresh settings
Debug Sessions
You run the projects that you develop as debug sessions (sessions).
A session is defined by the elements listed in Table 3-1.
Processor When you create an executable file, the processor is specified by the Linker
Description File (.ldf) and other source files.
Platform For a given debug target, several platforms may exist. For a simulator, the
platform defaults to the identically-named simulator. When the debug target
is an EZ-KIT Lite® board, the platform is the board in the system on which
to focus. When the debug target is a JTAG emulator, the platforms are the
individual JTAG chains.
The processor, connection type, and platform specify the debug session.
By default, a session name is generated automatically. You can further
identify the session by modifying the default name, choosing a more
meaningful name.
L Innected
a JTAG emulator session, only one debug session may be con-
to each physical target/emulator combination. Otherwise,
contention issues may arise. Upon switching to a different session,
VisualDSP++ detaches from the old session before attaching to the
new session.
Breakpoints
In a simulator session, a breakpoint can be set at any address in your
executable program’s memory. Program execution halts at the address
where the breakpoint is located.
Watchpoints
Watchpoints are like breakpoints that trap on a specified condition.You
can set watchpoints on registers, stacks, and memory ranges. Reaching the
condition halts program execution and updates all windows.
L Before debugging, open and pin the register windows and memory
windows that you plan to use. If these windows are not pinned,
they display information for any processor that has focus.
When a window is pinned to a processor, a pin icon appears in the win-
dow’s upper-left corner.
For example:
Traces
(SHARC processors only) A trace captures a history of processor activity
during program execution. Run a trace (execution trace or a program trace)
to analyze the run-time behavior of your application program, enable I/O
capabilities, and simulate source-to-target data streaming.
VisualDSP++ provides a Trace window. Refer to “Trace Windows” on
page 2-52 and to Help for details.
A trace includes the following information.
• Buffer depth (instruction lines)
• Cycle count
• Instructions executed such as memory fetches, program memory
writes, and data/memory transfers
Viewing the disassembled instructions that were performed can also help
in analyzing code behavior.
L VisualDSP++
procedure.
must be closed before performing the following
This debugging feature saves time, because you do not have to load the
executable target manually. You can start to debug immediately after
successfully building the project.
Run Runs an executable program. The program runs until an event stops it, such as
a breakpoint or user intervention. When program execution halts, all windows
update to current addresses and values.
Halt Stops program execution. All windows are updated after the processor halts.
Register values that changed are highlighted, and the status bar displays the
address where the program halted.
Run to Cursor Runs the program to the line where you left your cursor. You can place the
cursor in editor windows and Disassembly windows.
Step Over (C/C++ code only in an editor window) Single-steps forward through program
instructions. If the source line calls a function, the function executes com-
pletely, without stepping through the function instructions.
Step Into (editor window or Disassembly window) Single-steps through the program
one C/C++ or assembly instruction at a time. Encountered functions are
entered.
Step Out Of (C/C++ code only in an editor window) Performs multiple steps until the cur-
rent function returns to its caller, and stops at the instruction immediately fol-
lowing the call to the function.
L Memory is not reset. Thus, C and assembly global variables are not
reset to their original values. Your program may behave differently
after a restart. To re-initialize these values, reload your .DXE file.
Breakpoints
An enabled breakpoint halts program execution at a specific instruction or
address. You can enable and disable breakpoints as well as add and delete
breakpoints.
A disabled breakpoint is set up, but not turned on. A disabled breakpoint
does not stop program execution. It is dormant and may be used later.
A break occurs when the conditions that you specify are met.
You can quickly place an unconditional breakpoint at an address in a
Disassembly window or editor window by:
• Selecting an address and clicking Toggle Breakpoint button
• Double-clicking a line in a Disassembly window or editor window
Symbols in the left margin of a Disassembly window or editor window
indicate breakpoint status, as shown in Table 3-3.
Automatic Breakpoints
You can configure whether the “automatic” breakpoints are set after a pro-
gram is loaded. (In VisualDSP++ 4.0 and earlier releases, after a program
is loaded, software breakpoints were automatically set at main.) Also, you
can specify additional breakpoints to be set after a load and you can spec-
ify each additional breakpoint as being a software breakpoint or a
hardware breakpoint.
You conifer the automatic breakpoints via the Automatic page of the
Breakpoints dialog box. Next to each label in the breakpoint list, is a brief
description of the breakpoint location like “start of program” for main,
“end of program” for ___lib_prog_term, and so on. User-defined break-
points are labeled “user breakpoint” if you do not provide a description.
Automatic breakpoints may be set as software breakpoints or hardware
breakpoints. If the IDDE is connected to a simulator target, the “hard-
ware/software” specification is ignored since all breakpoints are software
breakpoints. If the IDDE is connected to an emulator target that supports
hardware breakpoints, you can specify each automatic breakpoint as being
a hardware breakpoint or a software breakpoint in the target. Automatic
breakpoints are specified, saved, and restored on a per-session basis.
Multiprocessor Sessions. In a multiprocessor session, you must configure
the automatic breakpoints one processor at a time by setting focus on a
processor, opening the Automatic page of the Breakpoints dialog box, and
specifying/enabling the breakpoints for the processor that has the focus.
Watchpoints
Similar to breakpoints, watchpoints stop program execution when
user-specified conditions are satisfied. Watchpoints, however, are used to
set a condition, such as a memory read or stack pop, for halting events.
Hardware Breakpoints
Similar to simulator watchpoints, hardware breakpoints enable you to set
breaks on instructions or data transfers within a user-defined memory
range.
Choosing Hardware Breakpoints from the Settings menu opens the
Hardware Breakpoints dialog box, from which to configure the hardware
breakpoints.
Refer to VisualDSP++ Help for your processor family (SHARC ICE,
TigerSHARC ICE, or Blackfin ICE) for details about configuring the
hardware breakpoints.
Latency
Hardware breakpoints do not assert until one (1) or two (2) instruction
cycles after the actual break condition occurs. Note that the program
counter is not placed on the instruction that caused the break.
Restrictions
When using hardware breakpoints, do not place breaks at any address
where a JUMP, CALL, or IDLE instruction would be illegal.
Do not place breaks in the last few instructions of a DO LOOP or in the
delay slots of a delayed branch. For more information on these illegal loca-
tions, refer to your processor’s hardware documentation.
Simulation Tools
Before you have the processor, you can use interrupts and data streams
within VisualDSP++ to simulate the processor’s behavior.
Interrupts
Use interrupts to simulate external interrupts in your program. When you
use interrupts with watchpoints and streams, your program simulates
real-world operation of your processor system.
The processor application may collect and transfer data in four different
ways:
• Sampling a test point over time
• Transferring a data array over BTC at a specified point in the
application (SHARC and Blackfin emulation targets only)
• Using GetMem() directly
• Periodically halting the target to read memory
For information about using BTC, refer to the VisualDSP++ Getting
Started Guide.
Plots
Use the VisualDSP++ data plotting capability to display data in processor
memory as a plot (graph) in a plot window (Figure 3-2). A data plot can
assist you by allowing you to visualize data.
Refer to “Plot Windows” on page 2-109 for plot window configuration
information. For complete details on configuring plots, refer to
VisualDSP++ Help.
Plot Types
Each plot must be specified to be one of the plot types in Table 3-4.
X-Y Similar to a line plot, but also X value and Y value for each
(on page 3-21) uses X-axis data data point
Constellation Displays a symbol at each data X value and Y value for each
(on page 3-22) point data point
Eye diagram Typically used to show the sta- Y value for each data point
(on page 3-23) bility of a time-based signal
Waterfall 3-D plot typically used to show Z value for each data point
(on page 3-24) the change in frequency content
of signal over time
Spectrogram 2-D plot displays amplitude data Z value for each data point
(on page 3-26) as a color intensity
Line Plots
A line plot (Figure 3-3) displays a range of processor memory values con-
nected by a line. The values read from processor memory are assigned to
the Y-axis. The corresponding X-axis values are automatically generated.
X-Y Plots
An X-Y plot (Figure 3-4) requires an X value and a Y value for each data
point. Unlike a line plot, an X-Y plot requires X-axis data.
Constellation Plots
A constellation plot (Figure 3-5) displays a symbol at each (X,Y) data
point.
The X and Y data are specified separately in a user-defined processor
memory location. The number of X and Y points must be equal.
Eye Diagrams
An eye diagram plot (Figure 3-6) is typically used to show the stability of a
time-based signal. The more defined the eye shape, the more stable the
signal.
This plot works like a storage oscilloscope by displaying an overlapped his-
tory of a time signal. The eye diagram plot processes the input data and
optionally looks for a threshold crossing point (default is 0.0). A trace is
plotted when the threshold crossing is reached. Plotting continues for the
remainder of the trace data.
When a breakpoint occurs (or a step is performed), the plot data is
updated and a new trace is plotted. The eye diagram uses a data shifting
technique that stores the desired number of traces in a plot buffer (default
is ten traces). When the number of traces is exceeded, the first trace shifts
out of the buffer and the new trace shifts into the last buffer location. This
technique is referred to as first in, first out (FIFO).
You can modify options for threshold value, rising trigger, falling trigger,
and the number of overlapping traces.
Waterfall Plots
A waterfall plot (Figure 3-7) is typically used to show the change in fre-
quency content of signal over time.
The plot comprises multiple line plot traces in a three-dimensional (3-D)
view. Each line plot trace represents a slice of the waterfall plot.
The easiest way to create a waterfall plot is to define a 2-D array in C code
(a grid). The first array dimension is the number of rows in the grid, and
the second dimension is the number of columns in the grid. The number
of columns is equal to the number of data points in each line trace.
Sampled points
The plot output displays a legend showing each color and associated range
of values.
You can rotate the waterfall plot to any desired azimuth and elevation by
using the keyboard’s arrow keys.
Spectrogram Plots
A spectrogram plot (Figure 3-9) displays the same data as a waterfall plot,
except in a two-dimensional (2-D) format.
Each (X,Y) location displays as a color representing the amplitude of the
data. By default, an FFT performed on each slice results in a frequency
output display. A legend displays the colors and associated range of values.
Flash Programmer
The VisualDSP++ Flash Programmer provides a convenient, generic inter-
face to numerous processors and flash memory devices. This utility
simplifies the process of changing data values on a flash device and modi-
fying its memory. You no longer have to remove the flash memory from
the board, use a separate Flash Programmer, and then replace the flash.
Analog Devices supplies sample flash drivers for use with EZ-KIT Lite
evaluation systems (or custom hardware that uses flash devices similar to
those found on EZ-KIT Lite boards).
You may write your own flash drivers by following this API specification.
This allows you to implement new algorithms, modify existing ones, or
add support for a new flash device/processor combination with the current
Flash Programmer. Flash drivers may be implemented in C or assembly
language. To provide a completely generic flash loader interface, the
VisualDSP++ Flash Programmer API uses a set of named symbols, their
associated addresses, and a few numbered commands.
Flash Devices
Flash memory parts are non-volatile memories that can be read, pro-
grammed, and erased. In most applications, flash devices store:
• Boot code that the processor loads at startup
• Data that must persist over time and through the loss of power
Typically, flash device programming is performed with a device program-
mer at the factory or by an application developer. When a flash device is
wired appropriately to the processor, the processor can program the flash
device.
Flash Driver
To use the Flash Programmer utility, you must first load a flash driver
onto the processor. The driver is a processor application that interfaces
with the Flash Programmer and performs all the interaction with the flash
device. Analog Devices supplies sample drivers for use with certain
EZ-KIT Lite evaluation systems.
Energy-Aware Programming
Energy-aware programming is the ability to use simulation to view the
relative impact of instructions, source lines, functions, programs,
frequency, and voltage on an application’s estimated energy profile. This
allows you to make trade-offs that minimize power usage. The technique
used to estimate the energy of the application is a partial implementation
of a process known as Instruction Level Energy Estimation (ILEE).
For details on ILEE, refer to EE-294 on the Analog Devices Web site.
Ranking
The Linear Profiling window in the simulator displays an Energy Units
column. The numbers accumulated in the Energy Units column represent
the “ranking” of each instruction executed with regard to a power change
of the processor’s core voltage. These numbers are generated by measuring
the core voltage while running test code for each instruction.
Utilizing these readings as absolute measurements would not be accurate
enough considering factors (such as leakage current, temperature, and fab-
rication process of the chip) that play a part in an application’s power.
Therefore, these measurements are referred to as instruction “ranking”.
Example
The following example demonstrates how energy-aware programming can
be used to profile the core power used by an application.
To set up the Linear Profiling window for power profiling:
1. From the Tools menu, choose Linear Profiling, and then choose
New Profile.
2. Right-click on the Linear Profiling window, choose Properties,
and select Energy Units. Then click OK.
Using the profiled numbers in the “Count” and “Energy Units” columns
of both displays and referring to ___float32_mul, we can calculate a
power savings of approximately 50%.
First, we calculate the average Energy for the function by dividing the
“Energy Units” by the number of cycles in the “Count” column:
• Power Savings On = 2160473/5639 = 383.13
• Power Savings Off = 4307328/5639 = 763.84
The ratio of these two numbers (383.13/763.84) is 0.501580. This is the
power savings.
In the following example, the “ranking” measurements are based on an
EZ-KIT Lite evaluation system configured at 1.2 volts and 250 MHz.
Having enabled power savings, the voltage changes to .85 volts. We apply
these numbers to the “Voltage and Frequency Scaling” equation described
in EE-229:
This appendix includes a glossary (on page A-66) and collection of other
reference material. Take advantage of the many features in VisualDSP++
so you can speed up program development. Sections include:
• “Support Information” on page A-2
• “IDDE Command-Line Parameters” on page A-7
• “Extensive Scripting” on page A-8
• “File Types” on page A-12
• “Parts of the User Interface” on page A-15
• “Keyboard Shortcuts” on page A-31
• “Window Operations” on page A-37
• “Text Operations” on page A-44
• “Online Documentation” on page A-49
• “Online Help” on page A-53
• “Glossary” on page A-66
Support Information
Choose the About VisualDSP++ command from the Help menu to open
the About dialog box. This dialog box provides access to the following
types of support information.
• Software versions
The General page (Figure A-1), which displays version information
about the VisualDSP++ software. This information includes the
name of the registered user and company, the version of IDDE and
its build date, and the directory path in which VisualDSP++ is
installed.
• License management
The Licenses page (Figure A-2) provides a centralized view of your
current licenses. You can view license status and perform all neces-
sary licensing activities (installing, registering, and validating).
• Component versions
The Components page (Figure A-3) displays a list of your system’s
components and provides information (name, version, provider)
about your debug target, symbol manager, and processor library.
• Software Versions
The Versions page (Figure A-4) displays a list of your system’s
tools. Each tool includes a description, version number, and a
timestamp (day and time).
L parameter
Note: Specify the full path to
is permitted.
idde.exe. Only one instance of each
-f script_name Loads and executes the script specified by script_name. Use this
parameter to automate regression tests. You can also manipulate Visu-
alDSP++ by running a script from a library of common commands
that you create. If an error is encountered while executing this script,
VisualDSP++ exits automatically.
-s session_name Specifies the session to which VisualDSP++ connects when it starts.
The session must already exist. Use this parameter when you debug
more than one target board. Having multiple shortcuts to idde.exe
allows you to run a different session. This overrides VisualDSP++
default behavior of connecting to the last session.
-p project_name Specifies the project to load at startup. The project must already exist.
Examples:
idde.exe -f "c:\\scripts\\myscript.vbs"
idde.exe -p "c:\\projects\\myproject.dpj"
Extensive Scripting
You can issue script commands from a command window, the Output
window’s Console view, from a menu, from an editor window, or from a
user tool. Refer to “Script Command Output” on page 2-40 for details on
scripting.
• Command window issuance
Load a script from a command window with an idde command by
typing the following:
idde -f script_filename
Optionally, add -s and the session name to specify a previously
created session. If no session name is specified, the last session is
used.
If the script encounters an error during execution, VisualDSP++
automatically exits.
• Output window issuance
Load a script from the Output window’s Console view by typing
one of the following commands.
For the Microsoft ActiveX script engine, type:
Idde.LoadScript script_filename
For Tcl, type:
source filename
Similar to C/C++, use a backslash (\) as an escape character. If you
specify paths in the Windows environment, you must escape the
escape character, as shown in this example:
c:\\my_dir\\my_subdir\\my_file.vbs
For Tcl only, you may also use forward slashes to delimit
directories in a path, as shown in this example:
source c:/my_dir/my_subdir/my_file.tcl
• Menu issuance
You can quickly issue frequently used scripts. From the File menu,
choose Recent Scripts and then select the script.
You can invoke a script (such as .js or .vbs) automatically when launch-
ing VisualDSP++ from a shortcut on your Window’s desktop or Start
button. Right-click on the shortcut and select Properties and the Shortcut
tab. Then append -f and the name of the script file to the executable file
in the Target text box.
The example shown in Figure A-7 runs myscript.js automatically when
idde.exe is launched.
Script name
File Types
Table A-2 describes processor project files used by VisualDSP++.
.ldf Linker Description File Linker command source file is a text file
that contains commands for the linker in
the linker’s scripting language
.is Intermediate files Preprocessed assembly files generated by
.pp the preprocessor
.s
.map Linker memory map file Optional output for the linker. This text
file contains memory and symbol infor-
mation for executable files.
.tcl Tool Command Language Tcl scripting language files used to script
.tc8 files work
.obj Assembled object file (Previous releases only, replaced by .doj)
Output of the assembler
.lst Listing file Optional file output by the assembler
This work area contains everything necessary to build, manage, and debug
a project. You can set up preferences that specify the appearance of appli-
cation objects (fonts, visibility, and so on). You can open project files by
dragging and dropping them into the main window.
Title Bar
Figure A-9 shows the different parts of the title bar, which has been split
into three parts to fit the page.
• Project name
• File name (when an editor window is maximized in the main
window)
• Standard Windows buttons
Clicking the control menu button opens the control menu, which
contains commands for positioning, resizing, minimizing, maximizing,
and closing the window. Double-clicking the control button closes
VisualDSP++. The title bar right-click menu (Figure A-10) and control
menu (Figure A-11) are identical.
Control Menu
Control menu (system menu) commands move, size, or close a window.
Program Icons
Click one of the following program icon to open a control menu.
Program icon for the application and debugging windows
Program icon for editor windows
Placing the mouse pointer over a control menu command displays a brief
description of the command in the status bar at the bottom of the applica-
tion window.
Editor Windows
A floating editor window’s control menu includes the Next command,
which moves the focus to another window.
When an editor window floats in the main application window, its pro-
gram icon resides at the left side of its title bar. When an editor window is
maximized, the program icon resides at the left end of the menu bar.
Editor windows are described on page 2-16.
Debugging Windows
Each debugging window has a control menu. You can open a debugging
window’s control menu only when the window is floating in the main
window. For more information, see “Debugging Windows” on page 2-43.
Menu Bar
By default, the menu bar (Figure A-12) appears directly below the applica-
tion title bar. It displays menu headings, such as File and Edit.
Use toolbars to organize the tasks that you use most often. Position tool-
bars on the screen for fast access to the tools that you plan to use.
VisualDSP++ includes standard (built-in) toolbars. You can create custom
toolbars. Refer to “Toolbar Operation” on page A-27 for more informa-
tion about toolbars.
Built-In Toolbars
Table A-3 shows the standard (default) toolbars.
File
Edit
Help
Project
Window
Debug
Debug Session
Multiprocessor
User Tools
Workspaces
To obtain information about a tool, move the mouse pointer over the tool
and press the keyboard’s F1 key.
Toolbar Customization
By default, nine standard toolbars (Table A-3) appear near the top of the
application window, below the menu bar.
You can change the appearance of toolbars by:
• Moving, docking, or floating the toolbars
• Adding buttons to (or removing from) toolbars
• Displaying large buttons
You can also:
• Hide toolbars from view
• Add and delete custom-built toolbars
User Tools
Save time running commands by configuring user tools. A maximum of
ten user tools may be configured.
When a user tool is configured, its menu name (label) appears in the
Tools menu. The label also appears when you move the mouse pointer
over a user tool button.
Toolbar Buttons
The toolbar comprises separate tool buttons and provides quick mouse
access to commands.
The toolbar is a Windows docking bar which you can move it to different
areas of the screen by dragging it to the selected location.
Saves all open files that have been modified, including files not in the current
project
Cuts selected data from the document and store it on the clipboard
Opens the Project Options dialog box, where you specify project options
Runs the command associated with the user tool (one of ten)
Toolbar Operation
This section describes the toolbars and shows how to customize their
appearance. Refer to “Toolbars and User Tools” on page A-19 for more
information about toolbars.
Large buttons – On
Toolbar Shape
You can change the shape of a floating toolbar. Table A-6 shows two tool-
bar shapes.
Depending on the number of tools in the toolbar, you can create other
length and width arrangements.
Toolbar Rules
When working with toolbars, be aware of these rules:
• You can customize a built-in toolbar (for example, by removing a
button from the File toolbar), but you cannot delete a built-in
toolbar. You can reset the buttons in a built-in toolbar to their
original default settings.
• You can change the name of a user-defined toolbar, but not the
name of a built-in toolbar. For example, the File toolbar cannot be
changed to a different name.
Refer to VisualDSP++ Help for details.
Status Bar
The status bar, which is located at the bottom of the main application
window, provides various informational messages. Figure A-15 shows
examples of information displayed on the status bar.
The type of information that appears in the status bar depends on your
context (what you are doing).
• Moving the mouse pointer over a toolbar button or a menu bar
command displays a brief description of the button or command.
• Halting program operation with a Halt command displays the
address where the program halted.
• When using script commands, the status bar provides information,
such as when the menu item has focus.
While editing a file, the right side of the status bar displays editor window
information, as described in Table A-7.
Keyboard Shortcuts
VisualDSP++ includes keyboard shortcuts (also called shortcut keys) for
commonly used operations. These keyboard shortcuts appear in the tables
below. You can also access and run commands by:
• Clicking on menu items (and commands) in the menu bar
• Clicking toolbar buttons
• Right-clicking from a particular context, such as from the Project
window
• Clicking configured user tools (for example, )
• Clicking buttons in dialog boxes
• Running scripts (via the File menu, Output window, or editor
window)
• Choosing a command from a control menu
Move the cursor to the left one character Left Arrow (←)
Move the cursor to the right one character Right Arrow (→)
Go to a line Ctrl+G
Select by column Place cursor, press and hold down Alt and drag the
cursor (selects by column-character instead of by
line-character)
Go to next bookmark F2
Building Projects
To build projects, use the keyboard shortcuts listed in Table A-13.
Run F5
Halt Shift+F5
Miscellaneous
For windows and workspaces, use the keyboard shortcuts listed in
Table A-17.
Window Operations
Similar to many Windows applications, VisualDSP++ provides multiple
ways to adjust the view of the user interface.
Window Manipulation
The Window menu commands (Figure A-16) enable you to manipulate
your window display and update windows during program execution.
Refer to your Windows documentation for more information.
Float in Main Window Causes the window to become a normal MDI child window
(like an editor window) and disables its docking ability
Scroll bar
Scroll box
Pull-tab
The scroll boxes inside the scroll bars indicate the vertical and horizontal
location in the document. Use the mouse to scroll to other parts of the
document.
Docked Windows
The Project window in Figure A-18 is docked. (The docking option,
Allow Docking, is enabled.)
To prevent a window from docking, hold down the keyboard’s Ctrl key
while dragging the window to another position.
Floating Windows
The Project window in Figure A-19 is floating in the main window.
(Float In Main Window is enabled). The presence of an icon in the
top-left corner of a window indicates that it is floating.
The Project window in Figure A-20 is also floating in the main window.
(Float In Main Window is enabled.)
The Project window in Figure A-21 is floating, but not in the main win-
dow. (Float In Main Window is not selected.)
These buttons resize and close the window as described in Table A-19.
Text Operations
VisualDSP++ allows the use of regular expressions and tagged expressions
in find/replace operations and comments in your code.
[0–9] This shorthand form is valid within the sequence brackets. It specifies a
range of characters, from first through last, exactly as if they had been
written explicitly.
Ranges may be combined with explicit single characters and other ranges
within the sequence. Thus, [-+.0–9] matches any constituent character
of a signed decimal number; and [a–zA-Z0–9_] matches a valid identi-
fier character, either lowercase or uppercase.
[^abc] A caret (^) that is the first character of a sequence matches all characters
[^0–9] except for the characters specified after the caret.
(material) The material inside the parentheses can be any regular expression. It is
treated as a unit, which can be used in combination with other expres-
sions.
* An asterisk matches the preceding any number of times, including none at all.
Thus, ap*le matches apple, aple, appppple and ale.
For example, ^ *void matches only when void occurs at the beginning of a
line and is preceded by zero or more spaces.
+ A plus character matches the preceding any number of times, but at least one
time. Thus, ap+le matches apple and aple, but does not match ale.
? A question mark matches the preceding either zero or one time, but not more.
Thus, ap?le matches ale and aple, but nothing else.
| The pipe character (|) matches either the preceding or following item. For
example, (hot)|(cold) matches either hot or cold.
Spaces are characters. Thus, (hot) | (cold) matches “hot “or” cold”.
Match Rules
If multiple matches are possible, the *, +, and ? characters match the long-
est candidates. The | character matches the left-hand alternative first.
For more information, see the many reference texts available on this topic,
such as Mastering Regular Expressions, Powerful Techniques for Perl and
Other Tools by Jeffrey E. F. Friedl, (c) 1997 O’Reilly & Associates, Inc.
Online Documentation
VisualDSP++ includes three types of user documentation: Help files,
PDF files, and HTML files.
.chm VisualDSP++ Help system files and VisualDSP++ manuals are provided in Microsoft
HTML Help format. Installing VisualDSP++ automatically copies these files to the
<installation>\Help folder. VisualDSP++ Help is ideal for searching the entire
tools manual set. Invoke Help from the VisualDSP++ Help menu or via the
Windows Start button. The .chm files require Internet Explorer 6.0 (or higher) or
the installation of a component that provides a .CHM file viewer.
.pdf Manuals and data sheets in Portable Documentation Format are located in the instal-
lation CD’s Docs folder. Viewing and printing a .pdf file requires a PDF reader,
such as Adobe Acrobat Reader (4.0 or higher). Running setup.exe on the installa-
tion CD provides easy access to these documents. You can also copy PDF files from
the installation CD onto another disk.
.htm Dinkum Abridged C++ library and FLEXnet network license manager software doc-
or umentation is located on the installation CD in the Docs\Reference folder. View-
.html ing or printing these files requires a browser, such as Internet Explorer 6.0 (or
higher). You can copy these files from the installation CD onto another disk.
Help Categories
VisualDSP++ provides three processor-specific Help categories, one for
each processor family, that filter/adjust the content of Help. Each Help
category (for example, Blackfin processor family Help) displays the infor-
mation pertinent to that specific family of processors only.
A fourth category, provides access to the entire documentation set of all
three processor families (similar to software releases prior to version 5.0).
By selecting a Help category, in effect, you remove information about
other families of processors from Help; this improves your ability to
quickly locate information in Help, especially when running a “search” or
looking up an entry in the Help Index.
You can also specify a user preference that selects a category. You can also
switch among the different Help categories. Refer to VisualDSP++ online
Help for details.
Online Help
VisualDSP++ online Help refers to the application (product) Help
packaged together with the VisualDSP++ tool suite. This section describes
the following topics:
• Portions of the VisualDSP++ Help window
• Context-sensitive Help
• Copying example code from Help
• Printing from Help
• Bookmarking frequently used Help topics
• Navigating in online Help
• Search features
Help Window
The VisualDSP++ Help window comprises three parts:
• The navigation pane provides tabbed pages (Contents, Index,
Search, and Favorites) that provide different views.
• The viewing pane displays the selected object (Help topic,
Web page, video, .pdf file, application).
• Toolbar buttons provide navigation and allow you to specify
options.
Viewing pane
Toolbar
buttons
Navigation
pane
Move through the Help system and view Help topics by using the Help
window’s navigational aids, as shown in Figure A-24.
Other standard Microsoft HTML Help buttons are described in
Table A-26.
Context-Sensitive Help
You can view context-sensitive Help (information pertinent to your
current activity) for various items (toolbar buttons, menu commands,
windows, and dialog box controls) in VisualDSP++.
Move through viewed topics Jump to the ADI DSP tools Web site
Hides the Help window’s left pane. This button narrows the Help
window.
Displays the Help window’s left pane. This button restores a full
view after you click Hide.
Printing Help
You can print a specific Help topic or multiple Help topics (an entire
section of VisualDSP++ Help).
Current topic Right-click within the help topic and choose Print.
Tip: From the Help window’s Contents page, click ( ), located at the
top of the window.
Searching Help
VisualDSP++ Help provides full-text and advanced search capabilities for
finding information.
Full-Text Searches
A full-text search locates every occurrence of a text string within the Help
system. Specify a particular word or phrase to find only the topics that
contain that word or phrase.
You can search previous results, match similar words, and search through
the topic titles only.
A basic search consists of the word or phrase that you want to locate. Use
similar word matches, a previous results list, or topic titles to further
define your search.
You can run an advanced search, which uses Boolean operators and wild-
card expressions to further narrow the search criteria. Figure A-27 shows
an example of a Boolean search for “new AND plot”.
L When searching for a file name with an extension, group the entire
string in double quotes (for example, “filename.ext”). Otherwise,
the period breaks the file name into two separate terms. The
default operation between terms is AND, which creates the logical
equivalent to filename AND ext.
Wildcard Expressions
Wildcard expressions let you search for one or more characters by using a
question mark or asterisk. Table A-28 describes the results of these differ-
ent kinds of searches.
A single word project Locates topics that contain the word “project”.
Other grammatical variations, such as “projects”
are located.
A phrase “project window” Locates topics that contain the literal phrase
(note the quotation “project window” and all its grammatical varia-
characters) tions.
Boolean Operators
Use the Boolean AND, OR, NOT, and NEAR operators to precisely define your
search by creating a relationship between search terms.
Insert a Boolean operator by typing the operator (AND, OR, NOT, or NEAR) or
by clicking the arrow button.
Both terms in the same new AND plot Locates topics that contain both the words
topic “new” and “plot”
Either term in a topic new OR plot Locates topics that contain either the
word “new” or the word “plot” or both
The first term without the new NOT plot Locates topics that contain the word
second term “new”, but not the word “plot”
Both terms in the same new NEAR plot Locates topics that contain the word
topic, close together “new” within eight words of the word
“plot”
Do not use the |, &, or ! characters as Boolean operators. You must use OR,
AND, or NOT.
Nested Expressions
Use nested expressions to create complex searches for information.
For example, new AND ((plot OR waterfall) NEAR window) finds topics
containing the word “new” along with the words “plot” and “window”
close together, or topics containing “new” along with the words “water-
fall” and “window” close together.
Glossary
The following terms are important toward understanding VisualDSP++.
Application Programming Interface (API) functions
A set of functions available to an applications programmer. These
functions, which are part of an application, can be accessed by
other applications. For VDK, API refers to a library of C/C++
functions and assembly macros that define VDK services. These
services are essential for kernel-based application programs. The
services include interrupt handling, thread management, and sema-
phore management.
archiver
The VisualDSP++ archiver, elfar.exe, combines object (.doj)
files into library (.DLB) files, which serve as reusable resources for
project development. The linker searches library files for routines
(library members) that are referred to by other objects, and links
them in your executable program.
breakpoint
User-defined halt in an executable program. Toggle breakpoints
(turn them on or off) by double-clicking on a location in a
Disassembly window or editor window.
break condition
Hardware condition under which the target breaks and returns
control of the target back to the user. For example, a break condi-
tion could be set up to occur when address 0x8000 is read from or
written to.
build
Performing a build (or project build) refers to the operations (pre-
processing, assembling, and linking) that VisualDSP++ performs
on projects and files. During a build, VisualDSP++ processes the
files in the project that have been modified (or depend on files that
have been modified) since the previous build. A build differs from
a rebuild all. During a rebuild all, VisualDSP++ processes all the
files in the project, regardless of whether they have been modified.
build type
Replaced by “configuration”
channel
A transmission path between two communicating locations, usually
the smallest subdivision of a transmission system. For VDK, chan-
nel refers to a FIFO queue into which messages sent to a thread are
placed. Each thread has 15 channels. Messages are received in
priority order from the lowest numbered channel to the highest.
COFF
Common Object File Format. VisualDSP++ does not support files
formatted in COFF.
configuration (or project configuration)
A project is developed in stages (configurations). By default, a
project includes two configurations: Debug and Release.
A configuration refers to the collection of options (tool chain and
individual options for files) specified for the configuration. You
can add a configuration to your project at any time. You can delete
a customized configuration that you created, but you cannot delete
the Debug or Release configurations.
connection type
A simulator, EZ-KIT Lite development system, or an emulator.
Previously called “session type”.
context switch
A process of saving/restoring the processor’s state. The scheduler
performs the context switch in response to the system change.
A hardware interrupt can occur and change the state of the system
at any time. Once the processor’s state has changed, the currently
running thread may be swapped with a higher-priority thread.
When the kernel switches threads, the entire processor’s state is
saved and the processor’s state for the thread being switched in is
restored.
critical region
A sequence of instructions whose execution cannot be interrupted
or swapped out. Suspending all interrupt service routines (ISRs)
before calling the critical region ensures that the execution of a crit-
ical region is not interrupted. Once the critical region routine
concludes, ISRs are enabled.
CROSSCORE®
Analog Devices processor development tools, which provide easier
and more robust methods for engineers to develop and optimize
systems by shortening product development cycles for faster
time-to-market. CROSSCORE components include the Visu-
alDSP++ software development environment and EZ-KIT Lite
evaluation systems and emulators for rapid on-chip debugging.
current directory
Directory where the .DPJ file is saved. The build tools use the
current directory for all relative file path searches. See also “default
directories.”
data set
A series of data values in processor memory used as input to a plot.
You can create data sets and configure the data for each data set.
You specify the memory location, the number of values, and other
options that identify the data. Additional specifications for row and
column counts are required for 3-D plots.
Debug configuration
For a debug configuration, you can accept the default options or
specify your own options and save them. The configuration refers
to the specified options for all the tools in the tool chain. See also
“configuration.”
debug session
The combination of a processor, connection type, and platform.
For example, a debug session might consist of an ADSP-21262
processor, an EZ-KIT Lite connection, and an ADSP-21262
EZ-KIT Lite board.
Processor projects being developed are run as debug sessions. The
two types of sessions are hardware and software. When setting up a
session, set the focus on a series of more specific elements.
debug target
See “target”.
DWARF-2
(Debug With Arbitrary Records Format) A format for debugging
source-level assembly code via improved line and symbol
information
editor window
(source window) A document window that displays a source file for
editing. When an editor window is active, you can move about
within the window and perform typical text editing activities such
as searching, replacing, copying, cutting, pasting, and so on.
ELF
Executable Linking Format
emulator
Hardware used to connect a PC to a processor target board. This
hardware allows application software to be downloaded and
debugged from within the VisualDSP++ environment. Emulator
software performs the communications that enable you to see how
your code affects processor performance.
event
A signal (similar to a semaphore or message) used to synchronize
multiple threads in a system. An event is a logical switch, having
two binary states (available/true and unavailable/false) that control
thread execution. When an event becomes available, all pending
(waiting) threads in the wait list are set to a ready-to-run state.
When an event is available and a thread pends on it, the thread
continues running and the event remains available.
To facilitate error handling, threads can specify a timeout period
when pending on an event.
ICE
In-Circuit Emulator. Analog Devices offers emulators that provide
non-intrusive target-based debugging of processor systems. An
emulator can single-step or execute a processor at full speed to
facilitate viewing or altering a processor’s register and memory
contents.
IDDE
Integrated Development and Debugging Environment for Analog
Devices processor development tools
interrupt
An external or internal condition detected by the hardware inter-
rupt controller. In response to an interrupt, the kernel processes a
subroutine call to a predefined interrupt service routine (ISR).
Interrupts have the following specifications.
Latency – interrupt disable time. The period between the interrupt
occurrence and the first ISR’s executed instruction.
Response – interrupt response time. The period between the inter-
rupt occurrence and a context switch.
Recovery – interrupt recovery time. The period needed to restore
the processor’s context and to start the return-from-interrupt
(RTI) routine.
interrupt service routine (ISR)
A routine executed as a response to a software interrupt or hard-
ware interrupt. VDK supports nested interrupts, which means that
the kernel recognizes other interrupts, services interrupts, or both
with higher priorities while executing the current ISR. For VDK,
the ISRs are written in assembly language. VDK reserves the timer
and the lowest priority (reschedule) interrupt.
JTAG
Joint Test Action Group. This committee is responsible for imple-
menting the IEEE boundary scan specification, enabling in-circuit
emulation of ICs.
JTAG ICE configurator
See “VisualDSP++ configurator”.
kernel
The main module of a real-time operating system. The kernel loads
first and permanently resides in the main memory and manages
other modules of the real-time operating system. Typical services
include context switching and communication management
between OS modules.
keyboard shortcuts
The keyboard provides a quick means of running the commands
used most often, such as simultaneously typing the keyboard’s Ctrl
and G keys (indicated with the symbols Ctrl+G) to go to a line in a
file.
librarian
A utility that groups object files into library files. When linking
your program, specify a library file and the linker automatically
links any file in the library that contains a label used in your pro-
gram. Source code is provided so you can adapt the routines to
your needs.
library files
The VisualDSP++ archiver, elfar.ex, combines object (.DOJ) files
into library (.dlb) files, which serve as reusable resources for
project development. The linker searches library files for routines
(library members) that are referred to from other objects, and links
them into your executable program.
linear profiling
A debugging feature that samples the target’s PC register at every
instruction cycle. Linear profiling gives an accurate picture of
where instructions were executed, since every PC value is collected.
The trade-off, however, is that linear profiling is much slower than
statistical profiling. A display of the resulting samples appears in
the Linear Profiling window, which graphically indicates where
the application is spending its time. Simulator targets support lin-
ear profiling. See also “Statistical profiling.”
linker
The linker creates executable files, shared memory files, and overlay
files from separately assembled object and library files. It assigns
memory locations to code and data in accordance with a
user-defined .ldf file, which describes the memory configuration
of the target system.
Linker Description Files (.ldf files)
The .ldf files describe the target system and map your program
code within the system memory and processors. The .ldf file cre-
ates an executable file using the target system memory map and
defined segments in your source files.
loader
A utility that transforms an executable file into a boot file. The
loader creates a small kernel, which is booted into internal memory
at chip reset. A program of arbitrary size can then be loaded into
the processor’s internal and external memory.
makefile
VisualDSP++ can export a makefile (make rule file), based on your
project options. Use a makefile (.mak or .mk) to automate builds
outside of VisualDSP++. The output make rule is compatible with
the gnumake utility (GNU Make V3.77 or higher) or other make
utilities.
memory pool
An area of memory containing a specified number of uniformly
sized blocks of memory available for allocation and subsequent use
in an application. The number and size of the blocks in a particular
memory pool are defined at pool creation.
message
For VDK, a signal (similar to an event or semaphore) used to syn-
chronize two threads in a system or to communicate information
between threads. A message is sent to a specified channel on the
recipient thread (and can optionally pass a reference to a payload to
facilitate the transfer of data between threads). Posting a message
takes a deterministic amount of time and may incur a context
switch.
mixed mode
One of the two editor window display formats (the other being
source mode). Mixed mode displays assembled code after the line
of the corresponding C code.
multiprocessor group
The assignment of one or more processors to a group, enabling a
single multiprocessor operation (MP Run, MP Halt, MP Step,
MP Reset, and MP Restart) to affect the processors in the cur-
rently selected group.
multiprocessor system
A system built with multiple processors. Often, performance-based
products require two or more processors. A system built with a
single processor is called a single-processor system. Debugging a
multiprocessor system requires that you synchronously run, step,
halt, and observe program execution operations in all the proces-
sors at once. The SHARC and TigerSHARC simulators do not
support this capability.
non-bootable PROM-image file
Splitter output, consisting of PROM files that cannot be used to
boot-load a system
outdated file
A file that has been edited since the last build
payload
For VDK, an arbitrary amount of data associated with a message.
A reference to the payload can be passed between threads as part of
a message to enable the recipient thread to access the data buffer
that contains the payload.
pinning a window
A technique that statically associates a window to a specific
processor
pipelining
A feature that helps you analyze and tune your code for optimal
performance. For TigerSHARC processors and Blackfin processors,
VisualDSP++ provides a simulation-only debugging window
(Pipeline Viewer) to help visualize the pipeline by displaying pipe-
line stalls and aborts. For SHARC processors, the Disassembly
window displays symbols (F, D, or E) to indicate an instruction’s
pipeline stage.
platform
The device with which a target communicates. For simulation, a
platform is typically one or more processors of the same type. For
emulation, you specify the platform with the VisualDSP++ config-
urator, and the platform can be any combination of devices.
The platform represents the hardware upon which one or more
devices reside. You typically define a platform for a particular tar-
get. For example, if three emulators are installed on your system, a
platform selection might be emulator two.
Several platforms may exist for a given debug target. For a simula-
tor, the platform defaults to the identical processor simulator.
When the debug target is a JTAG emulator, the platforms are the
individual JTAG chains. When the debug target is an EZ-KIT Lite
board, the platform is the board in the system on which you wish
to focus.
pre-emptive kernel
A priority-based kernel in which the currently running thread of
the highest priority is pre-empted, or suspended, to give system
resources to the new highest-priority thread
processor
(DSP) An individual chip contained on a specific platform within a
target system. When you create the executable file, the processor is
specified in the Linker Description File (.ldf file) and other source
files.
profile-guided optimization (PGO)
A process that involves setting up and executing data sets to pro-
duce an optimized application. A data set is the association of zero
or more input streams with one .PGO output file. Refer to the Visu-
alDSP++ Getting Started Guide for a tutorial and to VisualDSP++
Help for “how-to” information.
profiling
A technique used during simulation to examine program execution
within selected ranges of code. Profiling helps you determine: per-
centage of time spent executing instructions, number of clock
cycles spent executing instructions, number of instructions exe-
cuted, and the number of times memory is read or written.
The profiler is non-intrusive. It does not report on execution
within a called function (“daughter” function). Use profiling to
monitor program memory. By watching one or more profile
ranges, you can find areas of code that may be optimized for better
performance. A profile session must include one memory range at a
minimum. For each range, specify a start and end address. You can
use symbols or hexadecimal numbers to represent addresses.
project
This term refers to the collection of source files and tool configura-
tions used to create a processor program. Through a project, you
can add source files, define dependencies, and specify build options
related to producing your output executable program. A project
(.dpj) file stores your program’s build information.
VisualDSP++ helps you manage projects from start to finish in an
integrated user interface. Within the context of a processor project,
you define project and tool configurations, specify project-wide
and individual file options for debug or release modes of project
builds, and create source files. VisualDSP++ facilitates easy move-
ment among editing, building, and debugging activities.
project configuration
This configuration includes all of the settings (options) for the
tools used to build a project.
project file tree display
See “Project window”.
Project window
This window displays your project’s files in a tree view, which can
include folders to organize your project files. Right-clicking on an
icon (the project itself, a folder, or a file) opens a menu of actions
that you can perform on the selected item. Double-clicking on the
project icon or a folder icon opens or closes the tree list.
Double-clicking a file icon opens the file in an editor window
Project wizard
Simplifies the creation of a new project by opening a series of pages
from which to specify options. For Blackfin processors, additional
pages facilitate the inclusion of startup code. You can modify
project options at a later time via the Project Options dialog box.
property pages
Refers to pages of the Project Options dialog box.
real-time operating system (RTOS)
A software executive that handles processor algorithms, peripherals,
and control logic. The RTOS comprises these components: kernel,
communication manager, support library, and device drivers. An
RTOS enables structured, scalable, and expandable processor
application development while hiding OS complexity.
rebuild all
See “build”.
registers
For information on available registers, see the corresponding pro-
cessor documentation or view the associated online Help.
release configuration
You can accept the default set of options, or you can specify the
options you want and save them. The configuration refers to the
specified options for all the tools in the tool chain. See also
“Configuration.”
reset
This command resets the processor to a known state and clears
processor memory.
restart
This command sets your program to the first address of the inter-
rupt vector table. Unlike a reset, a restart does not reload memory.
right-click
This action opens a right-click menu (sometimes called a context
menu, pop-up menu, or shortcut menu). The commands that
appear depend on the context (what you are doing). Right-click
menus provide access to many commonly used commands.
round-robin scheduling
For VDK, a scheduling scheme whereby all threads at a given pri-
ority are given processor time automatically in fixed duration
intervals. Round-robin priorities are specified at build time.
scheduler
For VDK, a kernel component responsible for scheduling system
threads and interrupt service routines. VDK is a priority-based
kernel in which the highest-priority thread is executed first.
scripting
You can interact with the IDDE by using a single command or a
script file. Scripting languages include VBScript, JavaScript, and
Tcl. Output displays in the Console view of the Output window.
The output is also logged to the VisualDSP_log.txt file.
semaphore
For VDK, a signal (similar to an event or message) used to synchro-
nize multiple threads in a system. A semaphore is a data object
whose value is zero or a positive integer (limited by the maximum
setup at creation time). The two states (available/greater than zero
and unavailable/zero) control thread execution. Unlike an event,
simulator
The simulator is software that mimics the behavior of a processor
chip. Simulators are often used to test and debug code before the
processor chip is manufactured.
The way a simulator runs an executable program in software is
similar to the way a processor does in hardware. The simulator also
simulates the memory and I/O devices specified in the .ldf file.
VisualDSP++ lets you interactively observe and alter the data in the
processor and in memory. The simulator reads executable files. A
simulator’s response time is slower than that of an emulator.
source files
The C/C++ language and assembly language files that make up
your project. Other source files that a project uses, such as the .ldf
file, contain command input for the linker and dependency files
(data files and header files). View source files in editor windows.
source mode
One of the two editor window display formats (the other being
mixed mode). Source mode displays C code only.
splitter
A PROM splitter utility that transforms an executable file into a
non-boot-loadable image. This file is loaded onto external proces-
sor memory.
statistical profiling
A debugging feature that provides a more generalized form of pro-
filing that is well suited to JTAG emulator debug targets. With
statistical profiling, VisualDSP++ randomly samples the target pro-
target
(also called “debug target”) The communication channel between
VisualDSP++ and a processor (or group of processors). Targets
include simulators, emulators, and EZ-KIT Lite evaluation sys-
unscheduled regions
For VDK, a sequence of instructions whose execution can be inter-
rupted, but cannot be swapped out. The kernel acknowledges and
services interrupts when an unscheduled region routine is running.
VDK
See “VisualDSP++ Kernel (VDK).”
VisualDSP++
An Integrated Development and Debugging Environment (IDDE)
for Analog Devices processor development tools
VisualDSP++ Configurator
Previously called JTAG ICE Configurator or ICE Configurator,
use this utility to describe the hardware to VisualDSP++ when con-
necting to a JTAG emulator session. VisualDSP++ requires this
description to set up the debug session. The VisualDSP++
Configurator also provides access to ICE Test, a utility for testing
the target.
VisualDSP++ Kernel (VDK)
The RTOS kernel from Analog Devices, a software executive
between processor algorithms, peripherals, and control logic. The
kernel is integrated with the Integrated Development and Debug-
ging Environment (IDDE), assembler, compiler, and linker
programs into the development tool chain.
Refer to the VisualDSP++ Kernel (VDK) User’s Guide for details.
watchpoints
For simulation only. Similar to breakpoints, watchpoints stop
program execution. Unlike breakpoints, which are attached to
specific addresses, watchpoints are attached to user-defined
Anomaly Options
The Anomalies submenu (under the Settings menu) provides commands
to help you determine where an anomaly might be affecting your code.
This submenu appears only when the simulator supports anomaly com-
mands for the selected processor.
Event Options
The Events submenu provides the following options.
• FP Denorm – This command opens the Configure Simulator
Event dialog box, from which to configure the reporting of the
generation of a floating-point denormal result. By default, this
option is OFF (disabled).
• Short Word Anomaly (all ADSP-2106x processors except the
ADSP-21065L) – This command opens the Configure Simulator
Event dialog box, from which to configure reporting for
short-word accesses that fail. By default, this option is OFF
(disabled).
• Access to 21065L 9th column Even Address (ADSP-21065L
processors only) – This command opens the Configure Simulator
Event dialog box, from which to configure reporting for invalid
memory access. By default, this option is ON (enabled).
FP Denorm
You can configure what happens when an FP Denorm event occurs.
Denormal operands flush to zero when input to a computation unit and
do not generate an underflow exception. Refer to your processor’s hard-
ware documentation for more information about floating-point
operations.
// to stall.
// writes to MSGR2.
L Ensure that a failing sequence does not occur when you use the
delayed branch ( ) option with jumps, calls, and returns. For
DB
example, ensure that the two instructions in RTI (DB) do not cause
an instruction stall in a return to code that includes short-word
accesses.
4. Click OK.
Simulator Options
The Simulator submenu (under the Settings menu) provides the
CLKDBL command for ADSP-21161 processors only. Use this command
to double the clock speed circuitry.
L the
Clock-doubling lets you set control bits, but it does not affect how
simulator runs.
You can configure the processor’s CLKOUT pin to be 1x or 2x the rate of
CLKIN. The appearance of a check mark (¸) beside the CLKDBL command
on the Simulator submenu indicates that this option is selected.
No Boot Mode
(ADSP-2106x and ADSP-2116x processors only).
The Simulation submenu’s NoBootMode command is available for
ADSP-21x6x simulators to support development code in configurations
where the processor is in “NoBoot” mode (starting execution from exter-
nal memory for pre-ADSP-2126x processors, or starting execution from
internal ROM for ADSP-2126x and ADSP-2136x processors).
When this mode is selected, check mark (¸) appears beside the NoBoot-
Mode command in the Simulation submenu. Also, a message displays,
reminding you to load a program or choose Debug -> Reset to complete
the mode change.
• Boot from SPI (32-bit Host, 16-bit Host, or 8-bit Host) for
ADSP-2116x processors only
• None of Above (disables boot mode)
Create a boot loader file (.ldr) based on the peripheral from which you
are loading. In a simulation target session, choose a peripheral (boot
option) and boot file as follows.
To create a boot loader file
1. From the Settings menu, choose Load Sim Loader and a boot
option (such as Boot from Host) to open the Open a Boot File
dialog box.
2. Navigate to the .ldr file and select it. Then click Open and OK.
A message instructs you to issue a reset instruction to execute the
loader.
3. From the Debug menu, choose Reset. The simulator runs and
boots in the boot-kernel (also called loader-kernel). A message
instructs you to issue a run instruction, which executes the loader.
4. From the Debug menu, choose Run (F5) to execute the loader.
The loader runs to completion and then displays a message,
indicating that the loader is finished and that it is OK to run the
application.
L Before clicking Run, load the symbols for the program as follows.
a. From the File menu, choose Load Symbols to open
the Load a Processor Program's Symbols dialog box.
b. Select the .dxe file that was used to create the .ldr
file. A message indicates that the selected symbols are
loading.
5. From the Debug menu, choose Run (F5) to run the application.
ADSP-TS101 Processors
This section includes the following topics, which apply to ADSP-TS101
processors.
• “Simulator Timing Analysis Overview” on page C-2
• “Pipeline Stages” on page C-2
• “Stalls” on page C-3
• “Aborts” on page C-5
• “Pipeline Viewer and Disassembly Window Operations” on
page C-7
• “Simulator Options” on page C-11
L Currently, the processor's external port and link ports are not
modeled in a cycle-accurate manner. The simulator cycle-counts
the code, but the cycle counts used for the external port or link
ports are rough estimates of cycle counts that you could obtain
by running the code on the chip. Do not rely on these counts for
performance evaluation.
The Pipeline Viewer window shows the flow of instructions through the
pipeline and any stalls due to sequencer or memory events. It helps you
understand how processor timing affects the execution of your program.
For information about configuring and using the Pipeline Viewer, see
“Pipeline Viewer Window” on page 2-88 or VisualDSP++ online Help.
Pipeline Stages
The ADSP-TS101 Pipeline Viewer window provides a representation of
instruction flow through the processor’s pipeline.Table C-1 lists the pipe-
line stages.
Instruction Fetch 1 F1
Instruction Fetch 2 F2
Instruction Fetch 3 F3
Decode DECODE
Integer INT
Access ACCESS
Stalls
The examples that follow illustrate how the Pipeline Viewer displays dif-
ferent types of stall events for ADSP-TS101 processors. For a complete list
of pipeline effects and memory transaction timing, refer to the processor’s
hardware specification.
Aborts
The following examples show how the Pipeline Viewer displays different
types of abort events for ADSP-TS101 processors. For a complete list of
pipeline effects and memory transaction timing, refer to the processor’s
hardware specification.
Figure C-6 shows how the program counter value is used for the
ADSP-TS101 processor.
Stepping
When single-stepping through a program, the simulator performs an
instruction line step and skips invalid instructions (aborted, bubbles, or
slots occupied by an invalid fetch).
Sometimes a step takes more than one cycle, and the Pipeline Viewer win-
dow advances by several lines, while the yellow arrow , which marks
the current program counter location in the Disassembly window, moves
to the next instruction line.
Simulator Options
The Simulator submenu (under Settings menu) provides the Configure
DMA File I/O command, which opens the DMA File I/O Configuration
dialog box (Figure C-7). This is used to specify files as sources, destina-
tions, or both for DMA transfers.
For information about dialog box options and simulating a DMA transfer
in the simulator, refer to VisualDSP++ online Help.
ADSP-TS20x Processors
This section includes the following topics, which apply to the
ADSP-TS201, ADSP-TS202, and ADSP-TS203 processors.
• “Simulator Timing Analysis Overview”
• “Pipeline Stages”
• “Stalls”
• “Aborts”
• “Pipeline Viewer and Disassembly Window Operations”
L Currently, the processor’s external port and link ports are not mod-
eled in a cycle-accurate manner. The simulator cycle-counts the
code, but the cycle counts used for the external port or link ports
are rough estimates of cycle counts that you could obtain by run-
ning the code on the chip. Do not rely on these counts for
performance evaluation.
Use the Pipeline Viewer window to understand how processor timing
affects the execution of your program. For information about configuring
and using the Pipeline Viewer, see “Pipeline Viewer Window” on
page 2-88 or refer to VisualDSP++ online Help.
Pipeline Stages
The ADSP-TS20x Pipeline Viewer window provides a representation of
instruction flow through the processor’s pipeline. Table C-2 lists the pipe-
line stages.
Instruction Fetch 1 F1
Instruction Fetch 2 F2
Instruction Fetch 3 F3
Instruction Fetch 4 F4
Predecode PD
Decode D
Integer I
Access A
Stalls
The examples that follow illustrate the way that the Pipeline Viewer dis-
plays different types of stall events for ADSP-TS20x processors. For a
complete list of pipeline effects and memory transaction timing, refer to
the processor’s hardware specification.
Aborts
The examples that follow illustrate how the Pipeline Viewer displays
different types of abort events for ADSP-TS20x processors. For a com-
plete list of pipeline effects and memory transaction timing, refer to the
processor’s hardware specification.
Aborted stages in the fetch pipe are marked with an , and aborted
instructions in the execution pipe are marked with an .
Figure C-14 shows how the program counter value is used for
ADSP-TS20x processors.
Stepping
When single-stepping through a program, the simulator performs an
instruction line step and skips invalid instructions (aborted, bubbles, or
slots occupied by an invalid fetch).
Sometimes a step takes more than one cycle, and the Pipeline Viewer win-
dow advances by several lines, while the yellow arrow , which marks
the current program counter location in the Disassembly window, moves
to the next instruction line.
Simulator Options
The Simulator submenu under Settings provides the Select Loader
Program command. This command opens the Open File dialog box, from
which to specify a custom loader program. Once selected, the loader pro-
gram automatically runs before a user program is loaded. The simulator
defaults to a standard loader program (TS20x_prom.dxe, where x is 1, 2,
or 3), but you can define your own loader by compiling a program into a
.dxe file. If you create your own loader, your code must contain the label
_init_debug_end to ensure that the loader is executed.
Table D-1.
Symbol
D Implemented
NA Not applicable
SPORT D D NA
UART D D NA
PCI NP NP NP
USB NP NP NP
Flags D D NA
System Timers D D NA
RTC D NA NA
EBIU NP NA NA
SPI D D NP
Watch Unit NP NA NA
Trace Unit NP NA NA
Core Timer D D NA
MEMDMA D NA FR
DMA D D FR
PROM FR NA FR
SPORT D D FR
UART FR FR FR
PCI NP NP NP
USB NP NP NP
Flags D D NA
System Timers D D NA
RTC D NA NA
EBIU NP NA NA
SPI FR FR NP
Watch Unit FR NA NA
Trace Unit FR NA NA
Core Timer D FR NA
MEMDMA D NA FR
DMA D D FR
PROM NP NA NP
GPIO FR FR NA
Watchdog Timer D NA NA
SPORT D D FR
UART D D FR
Flags FR FR NA
System Timers D D NA
RTC D NA NA
EBIU 1
D NA NA
PPI D D NP
SPI FR FR NP
Watch Unit D NA NA
Trace Unit D NA NA
Core Timer D NA NA
Watchdog Timer FR NA NA
PROM FR NA FR
MEMDMA D NA FR
DMA D D FR
SPORT D D FR
UART FR FR FR
Flags NP NP NA
System Timers D D NA
RTC D NA NA
EBIU NP NA NA
PPI FR FR NP
SPI FR FR NP
Watch Unit FR NA NA
Trace Unit FR NA NA
Core Timer D FR NA
Watchdog Timer D NA NA
GPIO FR FR NA
PROM NP NA FR
MEMDMA D NA FR
DMA D D FR
SPORT FR FR FR
UART FR FR FR
Flags FR FR NA
System Timers D D NA
EBIU 1
D NA NA
PPI D D NP
SPI FR FR NP
Watch Unit D NA NA
Trace Unit FR NA NA
Core Timer D NA NA
Watchdog Timer FR NA NA
PROM FR NA FR
MEMDMA D NA FR
DMA D D FR
• TIMER1_WDTH_CAP
• TIMER2_WDTH_CAP
In WDTH_CAP mode, the timer reads two 32-bit values from the input file.
The first value is the number of pulses (clocks) in the period. The second
value is the number of pulses in the width.
When PULSE_HI is set, the timer delivers high widths and low periods.
When PULSE_HI is not set, the timer delivers low widths and high periods.
Stall Reasons
The stall reasons are grouped into three categories:
• Multicycle instructions latencies (see “Multicycle Instructions and
Latencies” on page D-22)
• Instructions latencies (see “Instruction Latencies” on page D-26)
• L1 data memory latencies (see “L1 Data Memory Stalls” on
page D-34)
They are reported in the Pipeline Viewer as:
• Data address generator (DAG) read-after-write (RAW) hazard
• Data register (dreg) hazard: two cycle
Kill Reasons
The kill reasons are as follows.
• Branch Kill – change of flow
• Mispredict – mispredicted conditional change of flow
• Refetch – refetch, such as following an IDLE instruction
• Interrupt – interrupt/exception
These stalls are detected in the Decode stage. The instruction stalls there
until all DAG registers required and updated in later pipeline stages are
available.
In this example, the instruction “I0 = R0;” in the Execute1 stage (cycle
16), Execute2 stage (cycle 17) and Execute3 stage (cycle 18) is stalling the
“R4 = [ I0++ ];” instruction in the Decode stage. This stall is caused by
the first instruction because it updates the value of I0 in the Writeback
stage, while the second instruction needs the value of I0 in the Address
stage to increment I0.
Figure D-2 shows a fetch stall.
Fetch stalls are detected in the Decode stage and are caused by memory
latencies when an instruction is fetched.
In this example, two fetch stalls appear in the Decode stage (cycles 14 and
15) because of a memory latency when the “R1 = 0;” instruction is
fetched. These fetch latencies are then propagated in the pipeline:
“Address” stage (cycles 15 and 16), “Execute 1” stage (cycles 16 and 17),
and so on.
DCache store buffer Data cache buffer overflow. The processor stalls
full until the FIFO moves forward and a space is free.
DCache load while A load access collides with a pending store access
store pending in the store buffer. (They are tying to access the
same address.)
DCache load while Load access size is different from that of the store
store pending w/ size access. The buffer must be flushed before the
mismatch load can be carried out.
SYNC with store pend- SYNC instructions force all speculative, transient SSYNC;
ing in the core/system to be completed before pro-
ceeding.
EU->MUL/MAC RAW Execution unit, Multiply or Multiply accumulate R0 = R1 + R0;
hazard with a read after write hazard P0 = R0;
RETx RAW hazard Writing to one of the RETx (RETS, RETI, RETX = R0;
RETX, RETN, or RETE) registers immediately RTX;
followed by the corresponding return instruc-
tions.
Dagreg WAW hazard Writing to one of the DAG registers, and imme- I3 = R3;
diately writing to it again. I3 += M0;
Dagreg RAW hazard Writing to one of the DAG registers, and imme- I3 = R3;
diately reading [I3] = R7;
ccMV preg->dreg RAW A conditional move of a preg into a dreg, fol- If CC R0 = P1;
hazard lowed by a read of the dreg R0 = R1;
ccMV dreg->dreg RAW A conditional move of a dreg into a dreg, fol- If CC R0 = R1;
hazard lowed by a read of the source dreg R2 = R0;
loop top/bot RAW haz- Writing to a loop top/bottom register, followed LT0 = R0;
ard by a read of the same register R2 = LT0;
write to loop cnt stall A write to a LCreg, followed by any op LC0 = R0;
Nop; (any op)
CC2dreg RAW hazard Reading the CC register into a dreg, and then R0 = CC;
reading that register CC = R0;
Mac/video after regmv Register move of a system register to a dreg, fol- R0 = LC0;
sysreg to dreg raw haz- lowed by a MAC or video instruction R2.H = R1.L * R0.H;
ard
Regmv sysreg to dreg Writing a system register to a dreg, followed by R0 = LC0;
followed by ALU op an ALU operation using that dreg as an operand R2 = R1 + R0;
dreg raw hazard
Video after extracted
3-input add dreg raw
hazard
Search followed by exu A search instruction followed by any execution (R3,R0) = search R1
operation dreg raw haz- instruction with an operand of a dreg used in the (LE);
ard search instruction R2.H =R1.L * R0.H;
Regmv hazard: sysreg A register move of a system register to a dreg, fol- R0 = ASTAT;
to dreg -> dreg to dreg lowed by another register move of that same dreg R1 = R0;
RAW to a dreg
Regmv hazard: sysreg A register move of a system register to a dreg, fol- R0 = LC0;
to dreg -> dreg to sysreg lowed by another register move of that same dreg ASTAT = R0;
RAW to a system register
Regmv hazard: sysreg A register move of a system register to an accu- A0.w = LC0;
to areg -> dreg to areg mulator register, followed by another register A0 =R0;
WAW move of a dreg to the same accumulator register
Regmv hazard: sysreg A register move of a system register to an accu- A0.w = LC0;
to areg -> preg to areg mulator register, followed by another register A0 =P0;
WAW move of a preg to that same accumulator register
Regmv hazard: sysreg A register move of a system register to an accu- A0.w = LC0;
to areg -> areg to areg mulator register, followed by another register A0 =A1;
WAW move of an accumulator register to that same
accumulator register
Regmv hazard: sysreg A register move of a system register to an accu- A0.w = LC0;
to areg -> areg to dreg mulator register, followed by another register R0 =A0;
RAW move of that same accumulator register to a dreg
Regmv hazard: sysreg A register move of a system register to an accu- A0.w = LC0;
to areg -> areg to sysreg mulator register, followed by another register ASTAT = A0.w;
RAW move of that same accumulator register to a sys-
tem register
Regmv hazard: sysreg A register move of a system register to an accu- A0.w = LC0;
to areg -> load to areg mulator register, followed by a load to the same A0.w = [I0];
WAW accumulator register
Regmv hazard: sysreg A register move of a system register to an accu- A0.w = LC0;
to areg -> exu op using mulator register, followed by any execution unit A0 = A0(S);
areg RAW operation using that accumulator register as an
operand
Multicycle Instructions
Multicycle instructions are a category of instructions that cannot complete
in fewer than two cycles. Consequently, the extra cycles generated by such
an instruction cannot be removed without removing the multicycle
instruction itself.
In Figure D-3, multicycle instruction “[--SP] = (R7:6, P5:3)” enters the
pipeline Decode stage at cycle 16 and takes five cycles to complete (1 cycle
per register to push on the stack SP). The next instruction “R7 = 0” takes
only one cycle.
ALU Arithmetic Logic Unit operations (Logical ops, Bit ops, Shift/Rotate ops,
Arithmetic ops excluding Mult, Vector ops excluding Mult/MAC)
AQreg
CCreg CC register. This multipurpose flag typically holds the result of an arithmetic
comparison.
DAG Data Address Generator unit
Dagreg A DAG register (for example, P5-0, I3-0, M3-0, B3-0, and L3-0)
MUL Multiplier Unit operations (for example, Vector Multiply, 32-bit Multiply,
Vector MAC)
sysreg System Register (for example, LC1/0, LB1/0, LT1/0, SYSCFG, SEQSTAT,
ASTAT, RETS, RETI, RETX, RETN, RETE, CYCLES, and CYCLE2)
Stall Reasons
The stall reasons are as follows.
• Data address generator (DAG) read-after-write (RAW) hazard
• Memory stall
• Memory-mapped register (MMR) stall
• Unidentified stall
• Data register (dreg) hazard: two cycle
• Dreg hazard: one cycle
• CSYNC stall
• SSYNC or IDLE SYNC stall
• LSETUPO and not LPO_ALLOWED
• Awkward loop
• Raise stall
• SS mode
• RET read after write
Kill Reasons
The kill reasons are as follows.
• Branch Kill – change of flow
• Mispredict – mispredict conditional change of flow
• Interrupt – interrupt/exception
• Refetch – refetch, such as following an IDLE instruction
These stalls are detected in the Decode stage. The instruction stalls until
all the required DAG registers, which are updated in later pipeline stages,
are available.
In the example, I0=R5 in the Execute3 stage is stalling the instruction in
decode, which wants to increment I0.
Figure D-5 shows an MMR stall.
Multicycle Instructions
All instructions not mentioned here are completed in one cycle. This sec-
tion describes instructions that take more than one cycle. Instruction
names are consistent with the Blackfin Processor Instruction Set Reference.
The cycle counts in the following examples represent the entire cycle time
of the instruction shown.
Conditional Branch
The number of cycles that a branch takes depends on the prediction as
well as the actual outcome.
Return
Table D-14 lists return instructions and cycles.
1 Best case
Linkage
Table D-16 lists linkage instructions and cycles.
TESTSET
The TESTSET instruction is a multicycle instruction that is executed in a
variable number of cycles. It depends on the cycles needed for a read
acknowledge from off-core L2 memory and whether the address being
tested is both in the cache and dirty. The number of cycles is determined
as follows.
cycles = 1 (instruction) + 1 (stall) + x (read ack) + y (cache
penalty)
Instruction Latencies
In addition to being based on instructions, instruction latencies are con-
tingent on placement of specific instruction pairs relative to one another.
Avoid latencies by separating them by as many instructions as the number
of cycles incurred between them. For example, if a pair of instructions
incur a 2-cycle latency, separate them by two instructions to eliminate that
latency.
In the tables that follow, note that bold typeface identifies register depen-
dencies within the instruction pairs. Non-bold typface in an entry means
that the latency condition occurs regardless of the registers used.
For a list of accumulator-to-data register (Areg2Dreg), math, video, multi-
ply, and ALU operations, as well as register groupings, see “Instruction
Groups” on page D-41 and “Register Groups” on page D-42. Instruction
names are consistent with the Blackfin Processor Instruction Set Reference.
Calculate the total cycle time of each entry by adding the cycles taken by
the instruction to the number of stall cycles for the instruction.
BF532 BF535
ADSP-BF532 ADSP-BF535
ADSP-BF532 ADSP-BF535
ADSP-BF532 ADSP-BF535
BF532 BF535
loop setup with LC0 and LC0 != 0 1 <1 > LSETUP (top, bottom) LC0 = P0;
any processor op 1 < 1 + 1 > NOP;
loop setup with LC1 and LC1 != 0 1 <1 > LSETUP (top, bottom) LC1 = P0;
any processor op 1 < 1 + 1 > NOP;
• None of the above applies to the 10x core. The 10x core stalls when
the loop start does not directly follow the LSETUP. This condition
causes a one-time 3-cycle stall while the loop buffer is filled at the
beginning of the second loop iteration.
• LSETUP to the same loop count register in the shadow of a previous
LSETUP is held in D code until the first LSETUP commits.
BF532 BF535
BF532 BF535
core and system MMR access < 1 + 2 > R0 = [P0]; // P0 = MMR address
The minibanks are contiguous 4096-byte (4-KB) chunks within the A and
B address space. With two simultaneous accesses (via a multi-issue instruc-
tion) to the same minibank, a 1-cycle stall is incurred. For example:
(I0 is address 0x001348, I1 is address 0x001994)
R1 = R4.L * R5.H (IS), R2 = [I0++], [I1++] = R3;
<1 cycle stall> (due to a collision in the second minibank
in superbank A)
00 minibank 1 (0x0000–0x1000)
01 minibank 2 (0x1000–0x2000)
10 minibank 3 (0x2000–0x3000)
11 minibank 4 (0x3000–0x4000)
Every time the available bank memory is doubled, another bit must be
used. For example, if an implementation of Blackfin processor architec-
ture has 32KB of data bank memory (eight 4-KB memory banks), bits 14,
13, and 12 must be used.
For simplicity, this document assumes the standard 16-KB data memory
model. If the addresses in a dual-memory access (multi-issue) instruction
is cached to the same minibank, a 1-cycle stall is incurred.
(I0 is address 0x002348, I1 is address 0x002994)
R1 = R4.L * R5.H (IS), R2 = [I0++], [I1++] = R3;
<1 cycle stall> (due to a collision in minibank 3)
Instruction Groups
All instruction group members conform to naming conventions used in
the Blackfin Processor Instruction Set Reference. Instruction groups
described are not necessarily mutually exclusive in that the same instruc-
tion can belong to multiple groups.
Register Groups
Table D-29 lists register groups.
Compiled Simulation
A traditional simulator decodes and interprets one instruction at a time.
Each executed instruction often requires repeated decoding. Compiled
simulation removes the overhead of having to decode each instruction
repeatedly.
In VisualDSP++ 3.5, compiled simulation required you to first build a
compiled simulation .exe file from a .dxe program file and then load and
execute the program in a compiled simulation debug target.
In VisualDSP++ 4.0, the intermediate step is no longer required. You can
load the .dxe program into the compiled simulation debug target directly.
When you run, the debug target compiles the processor code into native
code and executes the native code.
documentation ELF
printing, A-50 defined, 1-27
.doj files, 1-28, 1-30, 1-31, 2-14, A-12 ELF/DWARF format, A-12
DOS commands elfloader.exe, 1-42
running, 1-60 Embedded Processing & DSP
.dpg files, 1-49, A-14 Knowledgebase, -xxxiii
.dpj files, 1-43, A-12 emulation
.dsp files, 2-14, A-13 available tools, 1-20
DSPs, See processors debug session management, 3-3
dumping restarting programs, 3-12
memory, 2-67 targets, 1-17
DWARF-2, 1-27 vs. simulation, 3-3
defined, A-71 emulator
.dxe files, 1-31, A-12 defined, A-71
automatic loading, 1-26 when to use, 1-15
emulator targets
statistical profiling, 3-8
E
energy
editing calculating for functions, 3-33
features, 1-3 energy-aware programming, 3-31
files, 1-24 error messages, 2-43
keyboard shortcuts, A-33 demoting, 2-35
editor files displaying offending code, 2-29
comments in, A-48 log file, 2-38, 2-39
Editor Tab mode, 2-21 Output window, 2-28, 2-31
editor windows promoting, 2-35
about, 2-16 scrolling in Output window, 2-29
bookmarks, 2-17, 2-19 severity hierarchy, 2-31
breakpoints, 3-13 suppressing, 2-35
compiler annotations, 2-24 syntax, 2-32
Editor Tab mode, 2-21 errors
expression evaluation, 2-24 discretionary, 2-31
operations, 2-17 estimated energy profile, 3-31
parts of, 2-17 evaluating
program icon, A-18 expressions in editor windows, 2-23
right-click menu, 2-27 evaluation
source mode vs. mixed mode, 2-20 available tools, 1-20
switching among, 2-23 event bit
symbols, 2-18 defined, A-72
syntax coloring, 2-19
events expressions
cache, 2-93 C expressions, 2-52
defined, A-71 context-sensitive evaluation, 2-23
Pipeline Viewer, 2-91 evaluating in editor windows, 2-23
thread, 2-107 Expressions window, 2-52
using data cursor, 2-107 memory windows, 2-69
events log nested, searching Help, A-64
cache, 2-95 register, 2-52
Events submenu (SHARC), B-4 regular, A-44
Access to ADSP-21065L 9th column tagged, A-47
Even Address, B-7 tracking, 2-69
FP Denorm, B-4 tracking in memory windows, 2-67
Short Word Anomaly, B-4 viewing value of, 2-24
Excel Expressions window
data files, 3-17 about, 2-50
plot window data, 3-17 valid expressions, 2-51
executables external interrupts
automatic loading, 1-26 generating, 3-17
loading, 3-11 simulating, 1-16
execution traces, 2-52, 3-9 eye diagrams
.exe files, A-13 about, 3-23
Expert Linker example of, 3-23
about, 1-34 EZ-KIT Lite evaluation systems
overview, 1-34 as targets, 1-16
stack and heap usage, 1-38 flash drivers, 3-30
window, 1-35 planning, 1-15
specifying as platform, 3-2
F
fatal errors, 2-31
features
new in VisualDSP++ 5.0, 1-7
project management, 1-4
VDK, 1-6
VisualDSP++, 1-1
file building options, 1-25
L loader
L1 data memory stalls, D-34 about, 1-42
cache access (1-cycle stall), D-36 specifying options, 1-42
minibank access collision, D-35 terms, 1-42
MMR access, D-39 loading
SRAM access (1-cycle stall), D-35 executable programs, 3-11
store buffer load collision, D-40 programs, 3-11
store buffer overflow, D-39 scripts, 2-42
system minibank access collision, D-39 scripts from a shortcut, A-11
latencies, D-22 Load Sim Loader submenu options, B-11
.ldf files, 1-31, 2-14, A-12 local build options, 1-25
customized, 1-46 Locals window
.ldr files, A-13, B-12 about, 2-54
legends Locate button, A-55
in plots, 3-26 log file, VisualDSP++, 2-38
librarian .lst files, A-13
defined, A-74
libraries M
C++ run-time, 1-29 main window
Dinkum abridged C++, 1-29 program icon, A-18
library functions status bar, A-29
displaying, 2-59 makefiles, 1-51, A-14
licenses example of, 1-53
list of, A-3 Output window, 1-53
management, 1-10 rules, 1-52
status, A-3 .mak files, See makefiles
linear profiling manuals
features, 3-8 online, A-49
minimizing energy, 3-31 printing, A-50
Linear Profiling window, 2-57, 3-8 .map files, A-13
about, 2-55 MATLAB
power savings, 3-32 data files, 3-17
line plots plot window data, 3-17
about, 3-21 measuring
linker performance, 3-8
file associations for tools, 2-14 memory
input files, 2-14 displaying an address’s value, 2-67
overview, 1-31 dumping, 2-46, 2-67
Linker Description Files, See .ldf files filling, 2-46, 2-67
linking, object files, 1-31, 1-32
optimizing pinning
programs, 2-94 definition, 3-6
Output window, 2-28, 2-43 pipeline
bookmarks, 2-30 kill reasons (ADSP-BF531,
Build page, 2-29 ADSP-BF532, ADSP-BF533,
capturing messages to log file, 2-38 ADSP-BF561), D-20
Console page, 2-30 kill reasons (ADSP-BF535), D-10
scripting, 2-41 stage event icons in Pipeline Viewer, 2-91
customization, 2-38 stall reasons (ADSP-BF531,
error messages, 2-31 ADSP-BF532, ADSP-BF533,
loading scripts, 2-39 ADSP-BF561), D-19
makefile errors, 1-53 stall reasons (ADSP-BF535), D-9
parts of, 2-29 pipeline stages
printing, 2-40 ADSP-TS101 processors, C-2
right-click menu, 2-39 ADSP-TS20x processors, C-13
scripts, 2-39 Disassembly windows, 2-50
scrolling previous commands, 2-30 pipeline symbols
overlays, 1-13, 1-32 mixed mode, 2-21
overriding Pipeline Viewer
project-wide options, 1-58 aborts (ADSP-TS101), C-5
.ovl files, 1-31, A-12 aborts (ADSP-TS20x), C-15
current program counter value
(ADSP-TS101), C-8
P
current program counter value
PC samples (ADSP-TS20x), C-20
filtering, 2-62 event details, 2-92
performance event icons, 2-91
measuring, 3-8 message abbreviations (ADSP-BF535),
optimizing, 2-94 D-17
peripherals pipeline stages (ADSP-TS101), C-2
Blackfin, simulating, D-1 pipeline stages (ADSP-TS20x), C-13
limitations in simulation for Blackfin, specifying properties, 2-90
D-7 stalls (ADSP-TS101), C-3
support in simulators for Blackfin, D-2 stalls (ADSP-TS20x), C-14
Timer (TMR), Blackfin, D-8 stepping (ADSP-TS101), C-9
UART for Blackfin, D-7 stepping (ADSP-TS20x), C-21
PGO window, 2-88, C-20
defined, A-79 window messages (ADSP-BF535), D-12
physical memory Pipeline Viewer window, 2-88, C-2
defining, 1-33
pipelining positioning
defined, A-78 windows, A-42
platforms post-build options, 1-59
about, A-78 command syntax, 1-60
definition, 1-17 power
specifying, 3-2 minimizing, 3-31
plots power profiling
See also plot windows setting up, 3-31
buffer capacity, 2-111 .pp files, A-12
colors, 3-26 pragmas, 2-35
configuring, 2-109, 2-115 pre-build options, 1-59
constellation, 3-22 preferences
data logging status, 2-111 load file and advance to main, 1-26
data sets, 2-115 VisualDSP++ and tool output color,
DSP memory, 3-19 2-29
eye diagram, 3-23 Preferences dialog box, 1-26, 2-29
legends, 3-26 printing
line, 3-21 hardware manuals, A-50
presentation options, 2-117 online Help, A-57
spectrogram, 3-26 VisualDSP++ manuals, A-50
types of, 3-20 processor
viewing statistics, 2-112 loading into simulator, B-10
waterfall, 3-24 specifying, 3-1
X-Y, 3-21 processor definition files, 2-83
plot windows, 2-109 processor ID
See also plots configuring, B-10
BTC mode, 2-110 product information, A-3
configuring, 2-114 profile-guided optimization
features, 2-110 defined, A-79
operations in, 2-114 profiling
presentation of, 2-116 about, 3-8
right-click menu, 2-111 assembly instructions, 2-61
status bar, 2-110 defined, A-79
streams, 3-17 functions, 2-60
toolbar, 2-111 profiling windows, 2-55
types of, 3-20 Program Counter (PC) register
viewing statistics, 2-112 setting, 3-12
windows wizards
BTC Memory, 2-75 Project, 1-23, A-81
buttons, A-42 workspaces
Call Stack, 2-63, 2-64 keyboard shortcuts, A-37
custom register, 2-81
debugging, 2-43
X
Disassembly, 2-45, 2-47
docked, A-39 .xml files, 2-82
Expert Linker, 1-35 X-Y plots, 3-21
Expressions, 2-50
Flash Programmer, 3-30
floating, A-39
focus in an MP debug session, 3-6
Help, A-53
Image Viewer, 2-119
keyboard shortcuts, A-37
Linear Profiling, 2-55, 3-8
Locals, 2-54
MDI, A-38
Multiprocessor, 2-84
operating on, A-37
Output, 2-28
Pipeline Viewer, See Pipeline Viewer
window
plot, 2-109
positions, A-42
profiling, 2-55
Project, 2-2
pull-tabs, A-38
register, 2-78
right-click menus, A-38
scroll bars, A-38
stack, 2-80
Statistical Profiling, 2-55, 3-8
Target Load, 2-108
Trace, 2-52, 3-9
VDK State History, 2-105
VDK Status, 2-103
VisualDSP++, A-15