byungin moon yonsei universitysoc.yonsei.ac.kr/class/material/dsp/developmenttools.pdfdsp vlsi...

DSP VLSI Design

Development Tools

Byungin Moon

Yonsei University

1YONSEI UNIVERSITYDSP VLSI Design

Development ToolsOutlineAssembly language tools

AssemblersInstruction set simulatorsIn-circuit emulationDebuggersAssembly code libraries

High-level language toolsStrength and weaknessC and other high-level languagesEfficiency concerns and libraries

Block-diagram-based programming toolsReal-time operations systemsMultimedia environments


Development ToolsAssembly Language Tools

Need for assembly programming in DSP systemsExtremely demanding production cost and performance requirementsSoftware often must be extremely efficientTraditionally, DSP software has been written in assembly language

Heavy emphasis on optimizationDeveloped from the ground up for each new systemHigh development costs – time-consuming and difficult

Very irregular instruction sets and highly specialized features that complicate programmingGood tools can make a dramatic difference in the productivity of DSP software developers


Development ToolsAssembly Language ToolsAssembly language development environments for DSP processor software may include

Assemblers, linkers, instruction set simulator, in-circuit emulators, debuggers, development boards, and assembly language librariesSpecific to the processor being targeted

Often developed and distributed by the processor vendor (and also by third parties)In some cases, processor vendors rely on third-party firms

The quality and completeness of the tools varyAll DSP processor vendors provide a set of basic assembly language tools

TI had the most extensive selection of tools; others do notOne stubborn paradoxes of DSP processors

Good software tools for DSP processors are essential because of the need to optimize, but DSP processor software tools lag behind their general-purpose counterparts in sophistication and quality

Assembly language tools are often also an integral part of higher level tools such as C compliers


Development Tools

Interaction among Assembly Language Development Tools


Development ToolsAssemblers

An assembler translates processor-specific assembly language source code files into binary object code files for a particular target processor

Object code requires the additional steps of linking and relocation to transform it into a binary executable fileAmong the most basic and important tools

A vast amount of software for DSP processors is developed in assembly language to optimize code speed and size

Important featuresMacro assemblers

Define parameterized blocks of code that will be expanded in-line in the final programReduce the amount of source code that must be maintainedAvoid the overhead of subroutine calls

Conditional assemblyConditionally control whether certain blocks of code are assembledUseful for maintaining multiple, slightly different versions of a single program without having to create multiple copies of the source code


Development ToolsExample Usage of the Macro

Macro definition

Macro use


Development ToolsLinkers

Used to combine multiple object files and libraries into an executable program

Relocate codeFix the addresses at which various code fragments in object files and libraries are to reside when they are executed

May not be needed for small applications, but a necessity for most applicationsFlexible enough to accommodate the requirements of different object files and memory configurations

Memory mapTells the linker which segments of memory to use for each section of program code and dataMost linkers for DSPs are based on the concept of a memory mapDifferent system hardware designs and applications require different memory maps

User must be able to specify these maps


Development ToolsLinkersCOFF (Common Object File Format) object files

A standard format for object code files and is supported by many assemblers and linkersAllow the annotation of object files with debugging information,such as pointers to the lines of source code that correspond to each machine instruction

Symbol tableA structure storing the addresses of symbols used in both object and executable files (for debugging)Some linkers are able to produce an ASCII representation of the symbol table at the end of the linking process, or other tools do this

Library (or archives)A group of object code files bundled into a single fileLinkers allow programs to be linked with code extracted from librariesUsers frequently want to produce their own libraries

Typically done with a separate program, called librarian or archiver


Development ToolsInstruction Set Simulator (ISS)

Programs that simulate execution of a processor at an instruction-accurate level

Provide a software view of the processorDisplay program instructions, registers, memory, and flagsAllow the user to manipulate register and memory contents

A key tool for DSP software debugging and optimizationOffer a more controlled, flexible, and interactive environment than a development board, emulator, or target system

Enable software development to begin before sample chips are available

LimitationsAccuracy concerns and relatively low simulation speeds


Development ToolsInstruction Set Simulator (ISS)

Most DSP processor vendors offer ISSs for their processorsSome of the smaller vendors of DSP processor cores do not provide ISSs

Clarkspur Design and Tensleep DesignA few processors targeted exclusively at PC- and WS-based multimedia applications do not have ISSs

A stand-alone DSP simulator is less useful, because generally the DSP works in close cooperation with the host processorIBM’s MDSP2780 (Mwave)

All ISSs provide the user with the ability to single-step through a program and to view and edit the contents of the registers and memoryThe main factors differentiating ISSs from one another

Accuracy, speed, completeness, Debugging and optimization support, and integration and extensibility


Development ToolsAccuracy of ISSsFunctional accuracy

Fidelity with which a simulator models the functionality of the processor

The likelihood that a certain sequence of instructions operating on a certain set of data will yield the same results on the simulator as on the actual chip

Sometimes less than perfectDevelopers are well advised to recheck the functionality and timing of their application using an emulator or development board

Timing accuracyFidelity with the simulator models the time relationships of certain operations within the chip

Multi-cycle instructions, interlocks, bus contentionTrade-off between timing accuracy and simulator execution speed


Development ToolsSpeed and Completeness of ISSsSpeed

Much slower than the processors they simulateTypically, on the order of thousands of instructions per second on typical PCs and workstations

CompletenessSome ISSs model only the core processor itself and ignore or simulate very crudely supporting hardware units

On-chip timers, I/O interfaces, and peripheralsOthers model these functions quite accuratelySome ISSs provide interfaces to allow the user to add functionality to the simulator

Offset the lack of accurate modeling of some on-chip functionsGenerally use files on the host system as the sources and destinations for data arriving at the processor’s inputs and being sent from its outputs


Development ToolsDebugging and Optimization Support of ISSs

The user generally interacts with an ISS through a front-end program called a debugger

The same debugger can be used with the ISSs and with the emulator, and sometimes with the development boards

Key debugging and optimization featuresOf the debugger

Data display and editing, single-stepping, and symbolic and source-level debugging

Of the ISSBreakpoints, profiling and cycle counting

BreakpointsUser-specified conditions which cause the simulation to be haltedSimple breakpoints to halt when a particular program location isreachedSophisticated breakpoints conditioned on a complex arithmetic expression involving memory and register contents


Development ToolsDebugging and Optimization Support of ISSs

ProfilingHelps the developer ascertain the amount of time a program spends in a different sections of codeIn a per-instruction profiling

Keeps tabs on the number of executions of each instruction in the program

In a per-region profilingTracks the amount of time spent in various regions of the program

Important because of extreme performance-sensitivityCycle counting

Allows the user to obtain a count of the number of instruction cycles executed between any two points in a programUseful for determining the performance of an algorithm and average and/or worst-case execution time of a subroutine


Development ToolsIntegration/Extensibility of ISSsGenerally, ISSs do not provide capabilities for simulating the behavior of peripherals or other processors with some exceptions

DSP Group and MotorolaProvide the user the ability to link in custom C code to simulate external devices

MotorolaProvides built-in support for simulating multiprocessor configurations

Most ISSs provide memory-mapped file I/OA particular simulated memory location can be mapped to a file on the host computer

Some ISSs provide port- or pin-level I/OVarious processor I/O interfaces can be mapped to a file

Some ISSs provide scripting languagesUsed to specify input data sequences and interrupt arrival timesfor the processor’s I/O interfaces


Development ToolsHardware/Software CosimulationMore sophisticated models than the instruction set models traditionally provided to support DSP processor software developmentFull-functional model

Thought of as an ISS that can be embedded in a larger hardware or system simulation and that accurately models the processor’s I/O pins as the model simulates processor execution

Bus-functional modelMimic processor’s I/O pins but do not actually simulate the execution of code

Hardware modelersEmploy a physical sample of the processor to provide both hardware and software simulation

Design-based modelsUse a low-level description of the processor generated to provide a very accurate


Development ToolsIn-Circuit Emulation (ICE)Assists the user in debugging and optimizing applications running on the DSP in the target system

External hardware and software on a PC or WS provide the user with the ability to monitor and control the processor in the target system as it executes application programsAll emulators provide the user with the ability to single-step through a program, and to view and edit the contents of registers and memory

Main factors differentiating emulators from one anotherProcessor speed supported, ability to trace program flow and pin activity in real-time, sophistication of breakpoint conditions supported, profile capabilities

Processor speedWhether or not the ICE supports full-speed operation of the target processor

What debugging features are supported with real-time operation


Development ToolsProgram Flow and Pin Tracing (in ICE)

Real-time program traceBy capturing the state of the processor’s program memory address bus during each instruction cycle using high-speed buffersExtremely useful

Some program bugs that appear when the processor executes in real-time may disappear if the processor is halted or placed into a slow, stepping-mode

Discontinuity bufferProvides limited information on program flow

Typically records the source and destination address of the last few jump, call, return, or any branching instructions

Pin tracingAlso, using high-speed buffers


Development ToolsBreakpoints

Real-time breakpointsAllow the processor to run at full speed until a specified trigger condition is metExample trigger conditions

Program execution at a specified program address supported all emulatorsAccess to a data memory location, access within a range of program/data memory locations, execution of a certain kinds of instructions

Counters in the breakpoint logicUsed to halt the processor after a particular condition has occurred a certain number of timesTI TMS320C4x and tMS320C5x


Development ToolsBreakpointsNot-real-time breakpoints

Used if the needed breakpoint trigger is more complex than the emulator’s breakpoint logic can supportExamples

Halting execution upon the change of the value in a register or memory locationHalting when an arithmetic or logic expression involving two or more memory locations becomes trueThese are beyond the capabilities of the emulator’s breakpoint logic

Must be evaluated by the debuggerThe processor is placed in a single-stepping modeThe emulator forces the DSP to execute debug instructions after each instruction


Development ToolsProfilingUsed to determine where a program spends most of its time during execution

Used to decide how to best optimize the programExamples

A statement of instruction execution counts on a particular block of code

Profile supportCommonly supported in instruction set simulatorsBut emulator supports are available only for TI TMS320C4x and TMS320C5x

Sets breakpoints at the start and end addresses of loops, subroutines, and functions and measures processor cycle counts between the breakpointsMust intervene for each profiling event, so execution speed is slowed, but still faster than the instruction set simulator


Development ToolsBasic Architecture of the Emulator

The features and capabilities of an in-circuit emulator are largely determined by the basic architecture of the emulatorEmulator architectures can be divided into three categories

Pod-base emulationScan-based emulationMonitor-based emulation


Development ToolsPod-base EmulationThe DSP is removed from the target system

Hardware (called an ICE adapter or pod) contains a sample (sometimes a special version) of the processor to be emulated with additional hardware for controlling itA cable having the same pin-out as the DSP connects the pod to the target system

StrengthProvide real-time traces of program execution and processor pin activity

WeaknessExpensive due to hardware complexityChanges the electrical drive and loading characteristics of the circuit, and may cause electrical timing problemsDo not always support full-speed processor operation because of hardware complexity and electrical loading effectsNow, only a few vendors offer pod-based emulators


Development ToolsPod-base ICE System


Development ToolsScan-based Emulation

Emulation by accessing the on-chip debug logic through a special serial port

Dedicated on-chip debugging logic in the DSPResponsible for monitoring the chip’s real-time operation and halting the processor when a breakpoint is reached

A special serial portTypically connect to a host computer (PC or WS) with a special interface cardSoftware communicates with the debugging logic over this port

Download programs, examine and modify registers and memory, set and clear breakpoints, and perform other functions on the DSP while it is installed in the target system

JTAG (Joint Test Action Group) or other interfaces (e.g., Motorola’s OnCE port)


Development ToolsScan-based EmulationJTAG (IEEE standard 1149.1)

The most popular interface to boundary-scan implementationsTMS, *TRST, TCK, TDI, and TDO (five wires, not four)Boundary-scan

Testability technique that uses a small number of devices pins running a simple serial protocol to allow an external device to observe the values on all of the input pins of an IC and to forces values onto the output pins of the IC

JTAG boundary-scan interface can also be used to communicate with on-chip debugging circuitry with addition of special on-chip circuitry

But most DSP processors that support JTAG-based on-chip debugging do not actually support boundary scan

JTAG standard is simply used as a convenient mechanism for communicating with the on-chip debugging circuitry


Development ToolsScan-based EmulationStrength

Does not require the processor to be physically removed from the target system

The debugging interface card in the host computer connects to a dedicated connector in the target systemFar fewer physical and electrical problems

Dedicated on-chip debugging circuitry provides visibility into aspects of the processor’s execution

Motorola’s scan-based debugging circuitry allows the user to examine the contents of the processor’s pipeline after reaching a breakpoint

The number of signal lines that must be connected to the target hardware is minimized and the debugging port signals do not have to operate at the same speed as the rest of the chip’s signals

Reduce the overall complexity and cost of the emulator system


Development ToolsScan-based EmulationWeakness

Limited capabilities than pod-based emulatorsCost must be carefully constrained

The on-chip debugging logic must be present on every copy of the DSP processor manufactured

Extremely limited bandwidth between the target processor and the host

Serial connectionMust revert to a very slow single-stepping mode to implement certain features such as program flow tracing and pin tracing

Tracing can be implemented in real-time with pod-based emulatorsProgram discontinuity trace buffer on some processors


Development Tools

On-chip Debug Circuitry for Scan-based Emulation/Debugging


Development ToolsMonitor-based EmulationEmulation method

Run a special supervisory program (called a monitor) on the DSP processorOne of the processor’s conventional I/O interfaces (such as a host port) is used for communication with the debugger program running on the host

ExampleIBM’s MDSP2780 MwavePrimarily used in host-based applications such as PC multimedia and with low-cost development boards or evaluation boards

StrengthNo special emulation hardware is required either on the DSP processor or externallyThe processor does not have to removed from the target system


Development ToolsMonitor-based EmulationWeakness

More limited than pod- or scan-based emulationNo hardware breakpointsReal-time breakpoints are typically limited to a program memory locations

Substitute a call to the monitor for the instruction at the breakpoint addressAfter execution of the user’s program is halted, the original instruction is replacedCannot be used if the program code is executed out of ROMThere is no means provided for detecting accesses to a specific data memory locations

Revert to a slow single-stepping mode for some featuresThe state of the processor’s pipeline is changed before it can be examined by the user (the monitor program is called)


Development ToolsDebuggersFront-end program that provides the user interface and much of the functionality of an emulator or ISS

A critical tool for software developmentShared by emulators and ISSs

Convenient because users do not need to learn different interfaces for the two tools

Vary significantly in power and ease of useDebugging high-level language programs

When a processor vendor provides a high-level language compiler for a DSP, often the debugger supports debugging high-level language programsIn some cases, third-part vendors of high-level language compilers provide separate source-level debuggers

Intermetrics offers their XDB debugger with their C complier forMotorola’s DSP96002


Development ToolsMain Types of DebuggersCharacter-based, command-line oriented

Provide text-based interaction with a single windowSimple and straightforwardMake it difficult to debug complex applications

Character-based, windowedCharacter-based, but divide the screen into windows for displaying different types of informationAn improvement over command-line-oriented types

Graphical, windowedProvide true graphical windowing by taking advantage of common windowing systems such as MS Windows or X Window SystemThe most powerful, flexible, and easy to useAllows extensive customization of the screen layout to suit the application and the ability to share the screen with other applications


Development Tools

Example of the Character-based, Windowed Debugger (TI TMS320C3x Debugger)


Development ToolsExample of the Graphical, Windowed Debugger


Development Tools

The Most Important Features Distinguishing One Debugger from AnotherSymbolic debugging

Ability to manipulate objects (such as variables) in the programbeing debugged by using their symbolic names, as apposed to addresses or other numeric valuesImportant both for assembly language and high-level language programming

Source-level debuggingRefers to the ability to manipulate objects in the application program by referring directly to the source code that produced themTypically, a window displays the source code (assembly or high-level) for a program and highlights each line as the simulator single-steps through the programSome are capable of source-level debugging for both C and assembly, while others can handle only one or neither


Development Tools

The Most Important Features Distinguishing One Debugger from AnotherData entry and display mechanisms

For allowing the user to focus on the important aspects of a problem, these are importantExamples

Flexible data displayVisually highlight data that have changed from one point to another in a programA flexible selection of data formats

Facilities for displaying profiling dataSignal plotting

Allows the user to graphically display signalsWatch variables and windows

Allow the user to specify a set of registers or memory locations(or in some cases expressions) to be displayed in a special windowVariables in a watch window are typically updated each time the simulator or emulator stops execution


Development Tools

The Most Important Features Distinguishing One Debugger from Another

DisassemblyRecreates an assembly language program from a machine language executableIn-line assembly

Allows the user to assemble instructions and store them in memory without having to reassemble and reload the entire programUseful for quickly patching an errant program

Command loggingProvides the ability to create a log file of all commands executed during a particular debugging sequenceSession logging

Records only the commands, but the output as wellScripting or macro capability

Ability to execute commands from a file


Development ToolsAssembly Code Libraries

Useful in two waysReusing optimized blocks from a library without modification

which can result in a huge time savingsCreating the needed function by making minor modifications to anexisting library block

Possible only if source code is provided (some libraries are provided only in object form)

Two categoriesFunction libraries

Consist of relatively small building block functions, such as matrix multiplication, filtering, and I/O driversOften provided by DSP processor vendors

Application librariesContain much larger blocks of code that implement complete application or parts of application such as speech coders or modemsUsually developed and licensed by independent third-party software developers

Often usable with users’ C code


Development ToolsHigh-Level Language Development

StrengthProductivity

Much easier to develop error-free codeMaintainability

Easier to understand, so easier to maintainPortability

Easier to move to a new processor (not processor-specific)

WeaknessLoss of execution speed and increase in code size

Acceptable in some applications, or not in others

Methodologies such as mixing assembly and high-level language code can be used to increase the rang of applications in which high-level languages can be used


Development ToolsC Programming LanguageThe most popular high-level language for developing software for DSP processors due to

Familiarity to a wide range of programmersCloseness to hardware (bit-wise operators)Free availability of a good general-purpose C compiler

GNU C compiler from the Free Software FoundationC compilers are available except DSP16xx and ZR3800x

Lack a number of essential features that simplify coding of DSP algorithms

Fixed-point data type and complex data typeExtensions to the C language

ExamplesInserting assembly language statements directlyMemory space qualifiers

ANSI Numerical C Extension Group (NCEG)ANSI committee working to extend the C language to better support numerical computations (but no standard)


Development ToolsThe Other Most Popular High-Level Languages

C++The DSP high-level language of the futureCan create new data types and operations to best address the needs of their applications

Increases modeling efficiency; fewer lines of codeIncreases the complier’s opportunities for optimization

Tartan C++ complier for TI TMS320C3x and TMS320C4xAda

Supports a wide range of constructs and data typesStrongly-typed language with a rich set of types, subtypes, and type attributesMore powerful than C, offers a number of interesting features for DSP programming, especially for fixed-point processors

Quite complex (twice as many keywords as C), and less suitable than C for some lower-level operations, such as bit manipulationsTartan compiler for TMS320C3x, TMS320C4x and ADSP-2106x


Development ToolsHigh-Level Language Efficiency ConcernsInefficiency of High-level language compliers for DSP processors

DSP processors are compiler-unfriendlyDSP processor vendors have spent years developing architectures that contain the minimal set of functions required to implement signal processing algorithms; in contrast, GPP vendorsattempting to make their processor more compiler-friendlyMultiple memory spacesA small number of registers (typically of varying widths and dedicated to different uses)Nonorthogonal instruction setNo hardware support for software stacksMultioperation instructions

A small amount of on-chip memoryCompliers tend to produce code that is larger than its hand-coded equivalent; more quickly consumes scarce on-chip memory


Development Tools

High-Level Language Efficiency Concerns:Fixed-Point vs. Floating-PointFixed-point

Efficiency concerns are more seriousFixed-point processors tend to be used in applications that are extremely const sensitiveC has no fixed-point for fractional data type

Emulating floating-point (very expensive)Programmers must make do with integer data and add explicit shifts to their code as necessary to implement desired fixed-point arithmetic (if no extension to C is provided_

Floating-pointHave generally fared better than compilers for fixed-point

Tend to be used in less cost-sensitive applicationsTend to have wider instruction words and more registers

Resulting in a more orthogonal instruction setA good match for C’s float data type


Development ToolsHigh-Level Language Libraries

Libraries of support functions callable from the high-level language

Vendors of DSP C compilers bundle a subset of the ANSI-standard C run-time library

Standard utility functions used in many C programs, such as strcpy, atoi, and othersOften omit portions of the library

For example, standard I/O functions like printf, scanf, getc, and putc

ANSI-standard math functions (e.g., sin, cos)May not be particularly useful on fixed-point, because these routines are specified by ANSI to use double-precision floating-point arithmetic

Function and application librariesWritten in a high-level language or assembly language


Development ToolsBlock-Diagram-Based Programming Tools

Block-diagram-tools that can generate programs that implement algorithms from block-diagram specificationsUseful in several ways

Provide a mechanism for rapidly generating C or assembly codeA convenient way to access libraries

Libraries of blocks correspond of language librariesSome include simulation, fixed-point analysis, and hardware synthesis capabilities

Useful for many aspects of DSP system designGenerate C programs; some tools can directly generate assembly code for some processors


Development ToolsReal-Time Operating SystemsOperating systems that provide guarantees about the real-time performance of the operation system

Real-time meansThe maximum amount of time between an interrupt occurring and a certain process being allowed to run is boundedEach process is guaranteed a certain percentage of the CPUEach process is allowed to run within a specified time

Greatly simplify the problem of managing more than one task on a given processor

Guarantees that a system will meet its real-time constraintsHelps the system designer construct a system with known real-time performance

Have long been popular for general-purpose microprocessors

Real-time operating systems available on DSP processors were designed for use on DSPs from the start, or adapted from those for general-purpose processors


Development ToolsMultimedia EnvironmentsDSP processor’s flexibility

Exploited in the integration of DSP processors with PC and WS platforms

Can be used as a fax or data modem, a music synthesizer, or voice main system

Cost associated with this flexibilityThe execution of different tasks on the DSP processor must be choreographed in such a way to ensure that real-time requirements of each task are met

Typically provided by a real-time operating systemA standardized interface must be provided so that write DSP tasks that can communicate with the operating system, and so that developers of applications for the host processor can interface their programs to task running on the DSP in a consistent manner

Multimedia operating environment includesA real-time operating system with a standardized interface for DSP functions, software that resides on the host processor to provide means of communications between host applications and DSP tasks, and possibly a library of DSP software

byungin moon yonsei universitysoc.yonsei.ac.kr/class/material/dsp/developmenttools.pdfdsp vlsi...

Documents