Digital Signal Processors: fundamentals & system design Lecture 2

Digital Signal Processors: Digital Signal Processors:

fundamentals & system fundamentals & system

design design

Lecture 2Lecture 2Maria Elena Angoletta

CERN

Topical CAS/Digital Signal Processing

Sigtuna, June 1-9, 2007

M. E. Angoletta, “DSP fundamentals & system design – LECTURE 2”, CAS 2007, Sigtuna 2/40

Lectures planLectures plan

Lecture 1

DSP peripherals (cont’d), s/w dev’pment & debug.

introduction, evolution, DSP core + peripherals

Lecture 2

System optimisation, design & integration.

Lecture 3


Lecture 2 - outlineLecture 2 - outline

Chapter 4 DSP peripherals (cont’d)

Chapter 5 RT design flow:

introduction

Chapter 6 RT design flow: s/w

development

Chapter 7 RT design flow: debugging


Chapter 4 topicsChapter 4 topics

4.1 Introduction

4.2 Interconnect & I/O

4.3 Services

4.4 C6713 example

4.5 Memory interfacing

4.6 Data converter interfacing

4.7 DSP booting

Summary

DSP DSP peripheralsperipherals

Now

Yesterday


4.5 Memory interfacing4.5 Memory interfacing

No dedicated h/w interface → external h/w (ex: FPGA).

Ex: TI External Memory InterFace (EMIF).

Glueless interface to SRAM, EPROM, Flash, SBSRAM, SDRAM.

C6713: 32-bit EMIF, 512 MByte addressable ext. memory space.

Ex: ADI SHARC.

H/w interface often available in TI & ADI DSPs.

Generic DSP-external memory interfacing scheme.

Synchronous or asynchronous interface (DSP-driven).

Address decoding.

Careful with priority & interleaved memory access (data integrity).


4.6 Data converters interfacing4.6 Data converters interfacing TITI: Serial interfaces McBSP, McASP +DMA.

Bidirectional data flow + Serial Port Interface (SPI) to init/configure converter.

ADSP-BF533 Blackfin to AD9975 mixed-signal modem front-end interface.

ADIADI: Parallel Peripheral Interface (PPI) on Blackfin .

Also EMIF in asynchronous mode + DMA.

General solution: FPGA to rebuffer/pre-process (ex.: filtering) data.

Mixed-signal DSPs: on-board ADC/DAC. EX: ADSP-21190


4.7 DSP booting4.7 DSP booting Debugging: executable files uploaded to DSP via

JTAG.

Exploitation: DSP boots without JTAG.

Booting mode defined by DSP input pins.

Methods: No-bootNo-boot: DSP fetches instructions directly from EPROM/FLASH.

ROM bootROM boot: DSP reads formatted boot stream from ROM. Host bootHost boot: DSP stalled until host configures memory.

TI ‘C6x DSP booting from ROM.

POWER IN


Chapter 4 summaryChapter 4 summary Peripherals: wide range & important parameters for DSP

choice.

Interconnect & data I/O: serial + parallel interfaces.

Services: PLL, timers, JTAG, power management…

Memory interfaces Dedicated: ex. TI EMIF FPGA: DSP-driven synchronous/asynchronous

Data converters interfaces Serial or parallel

JTAG Load code / debug For exploitation DSP boots from memory.


5. RT design flow: introduction5. RT design flow: introduction

Definesarchitecture

interfacesdata flowcontrol

Developss/w project(s)

code

config. file

DebugsSimulationEmulation

Analyse & optimise

Evaluate performance

Optimise selected parts

System integratio

n within

controls infrastructure


Chapter 6 topicsChapter 6 topicsRT design flow: s/w RT design flow: s/w

developmentdevelopment

6.1 DSP programming – intro.

6.2 Development setup + environment.

6.3 Languages: assembly, C, C++, graphical.

6.4 RTOS.

6.5 Code building process.

Summary


6.1 DSP programming - intro6.1 DSP programming - intro

DSPs: programmed by software.

Languages:

High-level software tools (ex. MATLAB, National Instruments … ) to automatically generate files. → Rapid prototyping!

Cross-compilation: code developed & compiled on different machine (PC, SUN…) then uploaded to DSP & executed.

Code building tools from DSP manufacturers.

Trend: more complex, powerful & user-friendly development tools.

Assembly

high-level languages (ANSI C, C extensions/dialects, C++ …)


6.2 Development: setup6.2 Development: setup

Code development setup. Example: AD beam intensity measurement (TI ‘C40 DSP), CERN ‘98.

PowerPC board + PowerPC board + LynxOSLynxOS

(MasterVME)(MasterVME)

JTAG cable + emulator JTAG cable + emulator podpod

DSP boardDSP board

VME crateVME crate

Window-based PCWindow-based PC

DSP code development/debugging

System use from Control Room


6.2 Development: environment6.2 Development: environment Integrated Development Environment (IDE): editor,

debugger, project manager, profiler.

Developed & sold (~ 4000 USD) by DSP manufacturer.

Licenses: mostly per project (not floating).

VisualDSP++VisualDSP++ (PC/Windows) Two releases: for 16-bit & 32-bit DSPs. Licensed, per-family basis. Fully functional, 90-days free evaluation. Floating licenses available.

Code Composer StudioCode Composer Studio (mostly (mostly PC/Windows).PC/Windows).

Different version each family. No floating licenses. Fully functional, 90-days free evaluation.

AD

ITI


6.2 Development: Code Composer 6.2 Development: Code Composer StudioStudio

Memory region plots

FFT on memory

data

DSP registers

Disassembly

C-code editor

Symbolic debugging

DSP memor

y

Project files

Code Composer for TI ‘C40 DSPs – screen dump taken in 1999.


6.3 Programming languages6.3 Programming languages

a) Assembly

b) High-Level Languages (HLL): ANSI/ISO C, C extensions, C++

c) Graphical languages

Choice of programming language: depends on processor

Now many choices:

supported languages workload → optimisation level.

compilers generate efficient code hand-optimising difficult: h/w complexity!

Main choices:


6.3a) Assembly6.3a) Assembly

Code next to the machine: works with registers.

Needed: DSP architecture detailed knowledge.

Grammar/style depends on manufacturer / DSP family.

Takes longer to develop/to understand other people’s code.

Limited portability / reusability.

Assembly stiles comparison.


6.3a) Assembly [2]6.3a) Assembly [2]

Instruction address

Parallel instructio

nsMachine code

Load 32-bit →R3

Load 2x32 bit →A5-A4 & 2x32 bit →B5-B4

Add 2x32 bit →B5-B4

Store → memory

.D2 unit generates address & LD1 data path places value →A register file

breakpoint C6713 assembly exampleC6713 assembly example


6.3b) ANSI/ISO C language6.3b) ANSI/ISO C language

Popular/known → easier (faster) than assembly to develop.

Supports control structures & low-level bit manipulation.

Understandable & ~ portable (but limitations! ).

C compiler data alignment may be incompatible with DSP → bus errors

No support for DSP h/w features (ex: circular buffers, non-flat memory space) & fixed point fractional variables.

C compiler data-type sizes not standardized: may not fit DSP native data sizes!→ s/w emulation (slow) replaces h/w implementation (fast).

Ex: ADI TigerSHARC 64-bit double operations.

Typically slower & larger code size


6.3b) ANSI/ISO C language [2]6.3b) ANSI/ISO C language [2]

Data-type sizes on different Data-type sizes on different DSPs.DSPs.

C6713: h/w support for single & double precision float

operations!!

“portable C” is machine-dependent (if you want efficient code)!


6.3b) ANSI/ISO C language [3]6.3b) ANSI/ISO C language [3] “Embedded” C widely used on DSPs

Intrinsics: operators converted to efficient assembly code.

C-language extensions: specialised data type/constructs added.

Ex: some C6713 intrinsics

NB: Project “build” options often allows forcing ANSI C NB: Project “build” options often allows forcing ANSI C compatibility.compatibility.

“Embedded” C++ used on DSPs, too. Trimmed version: no multiple inheritance, exception

handling → more efficient code & smaller executables.


6.3c) Graphical DSP 6.3c) Graphical DSP programmingprogramming

Graphical programming can also generate DSP code. Ex: Matlab, Hypersignal RIDE (now NI), LabVIEW DSP

Module.

MATLAB

TI

Matlab: generates source files from model, compiles & upload to DSPs.

See DSP

lab!


6.3c) Graphical DSP 6.3c) Graphical DSP programming [2]programming [2]

Digital filter block

Example: MATLABExample: MATLAB


6.4 RTOS6.4 RTOS

Task-based + priorities (scheduler). Multi-tasking: time-sharing, often preemptive (NOT cooperative). Small memory footprint.

RTOS loaded to DSP @boot time.

manages DSP programs (tasks).

uses DSP resources (ex: timers).

API for tasks-peripherals interfacing.

H/w abstraction Task management

System debug & optimisation Memory protection …

Advantages

Typical features

Embedded DSP software component.


6.4 RTOS [2]6.4 RTOS [2] High RTOS turnover + royalties often required. Embedded Linux: uClinux (soft-RT), RT-Linux, RTAI. ADI & TI: scalable RTOS to optionally include in DSP code.

ADI: VisualDSP++ Kernel (VDK).

TI: DSP BIOS Kernel

Preemptive scheduler + multitasking support. Chip Support Library (CSL) to control on-chip peripherals. Real Time Data eXchange (RTDX) support [→ chapter 7]

DSP BIOS tasks


6.5 Code building process6.5 Code building process

Compiler & assembler (optimisers

)

Linker

Loader/ hex

conv.

Source files(.C++, C, .ASM)

Object files Executable

ADI: .doj .ldr .dxe .ldr

librarieslibraries

Linker Linker command command

filefile

TI: .obj .cmd .out various

Ext memor

y

TARGETARGETT


6.5 Code building process [2]6.5 Code building process [2]

No need to manually edit makefiles !

CCS OptionsCCS Options


6.5a) C/C++ compiler: TI ‘C6x6.5a) C/C++ compiler: TI ‘C6x

.if

.opt

Generates ‘C6x assembly code.

Input: C, C++ & linear assembly files.

Many levels of optimisation** (selectable).

Includes real-time library (non target-specific).

Optimizer: high-level optimisation.

Code generator: target-specific optimisation.

.sa

Assembly optimiser: hand-written linear assembly (extension .sa) optimisation.

.asm

** Optimisation: may modify code behaviour! [→ chapter 8]


6.5b) Assembler: TI ‘C6x6.5b) Assembler: TI ‘C6x

Generates machine language object files

Input: assembly files.

Supports macros (inline/library).

Creates a object file: Common Object File Format (COFF).

Allows segmenting code into sections ( section = smaller unit of object file)..asm

.text: executable code

.data: initialised data

.bss: space for un-initialised variables.

COFF basic sections


6.5c) Linker: TI ‘C6x6.5c) Linker: TI ‘C6x Generates executable modules.

Input: COFF object files.

Resolves undefined external references.

Assigns symbols/section final addresses.

Allocates sections: Efficient memory access speed. Shared memory map implementation.


Chapter 6 summaryChapter 6 summary DSPs: programmed by s/w via manufacturer-provided

development environment.

Languages: assembly, C, C++, graphical…

RTOS available for task/resource management.

Code building process: Compiler:

Assembler:

Linker:

generates assembly code. provides code

optimisation

Generates machine code

generates executable modules allocates sections to memory.


Chapter 7 topicsChapter 7 topics

RT design flow: debuggingRT design flow: debugging

7.1 Bugs & debugging

7.2 Simulation

7.3 Emulation

7.4 Traditional emulation techniques

7.5 Real-time debugging

Summary


7.1 Bugs & debugging7.1 Bugs & debuggingExecutable code: no compilation/linker errors but … does it do what it does it do what it should?should?

Debugging phase: most critical & least predictable !

Repeatable Intermittent (tough!) Due to implementation : src

code Not due to implementation :

h/w… Approaches: Simulation Traditional emulation Real-time debugging

Bugs:

Test & debug steps

First debug, then switch optimisation ON [→ chapter 8]


S/w simulation: slower than real h/w.

7.2 Simulation7.2 Simulation S/w DSP simulator: included with development environment.

Simulated:

CPU instruction set

Peripherals (ex: EDMA, caches…)

External interrupts

Highly repeatable! Ex: external events difficult to exactly repeat in h/w.

Task testing. Ex: algorithms, logical errors …

Measurement of execution duration (CAVEAT: limitations!).

Testing possible before h/w available.

TI CCS: rewind feature with ‘C5x/’C6x simulators.

→ Often different simulators for same target.

Traditional + real-time debug techniques available with simulation.


7.2 Simulation: TI C6x 7.2 Simulation: TI C6x SimulatorsSimulators

Device Cycle Accurate Simulator: models instruction set + device

peripherals.

CPU Cycle Accurate Simulator: models

instruction set.

C6713 DSK h/w


7.3 Emulation7.3 Emulation System-on-a-Chip (SOC): system functionality [ processor,

memory, logic elements, peripherals…] on single silicon chip..

Small-size devices: faster, cheaper, reliable, low power …

Vanishing visibility: a) impossible to probe pins (BGA packages);

b) many signals not available @pins anyhow. Emulation: debug components embedded to restore

visibility.

Pod-based In Circuit Emulation (ICE): DSP replaced by special version with additional h/w (emulator pod).

Scan-based emulation (JTAG): debugging logic + dedicated interface added to DSP.

Monitor-based emulation: supervisor program (monitor) runs on DSP.


7.3 Emulation: scan-based [2]7.3 Emulation: scan-based [2] Components:

On-chip debug facilities Emulation controller: controls info flow to/from target.

o Functions: run control + capture/record DSP activity.

o Location: external pod or on DSP board. Debugger program on host: visualization & user interface

Debug setup example

TI XDS560 emulator

Interfaces: DSP board: 14-pin header,

USB Host: Parallel/PCI/USB…

Capabilities: visibility into DSP processor, registers, memory.


7.4 Traditional emulation 7.4 Traditional emulation techniquestechniques

Breakpoints

Stop-mode debugging:

intrusive & possibly misleading!

Freeze entire DSP → examine registers, plot memory range, dump data to file…

Software: replace instruction with one creating exception.

Hardware: address monitoring stops execution for specified code fetch.

Triggerable by event detectors.

Source-level debugging See assembly-executed instruction Variables/memory accessed via

name/address.

C6713 registers: debugger view.

Others printf(), LOG_printf…


7.5 Real-time techniques7.5 Real-time techniques

New technology for real-time data exchange host ⇄ target without stopping the DSP.

ADI: Background Telemetry Channel (BTC).

Data retrieved in real time with minimal impact to DSP run.

Data can be transferred to/from DSP.

TI: Real-Time Data Exchange (RTDX)

Shared group of registers accessible (read/write) by DSP & host.

Supported on Blackfin + ADSP-219x.

See next slide


7.5 Real-time techniques: TI 7.5 Real-time techniques: TI RTDXRTDX

COM intf. clients: VisualBasic, VisualC++, Excel, LabView, Matlab...

RTDX channe

ls

NB: RTDX can also be simulated

TI & RTDX: data transfer speed as function of the emulator.


Chapter 7 summaryChapter 7 summary Debug phase: most critical & least predictable

Debug first, switch optimisation ON after!

Debug steps: Simulator

Emulator

No h/w needed Different simulator types available

Works with h/w Traditional techniques: stop-mode Real-time techniques: host-DSP data exchange when DSP

runs.

Digital Signal Processors: fundamentals & system design Lecture 2

Documents

dsp choice

dsp manufacturers

dsp bootingdebugging

asynchronous interface

dsp peripherals contdchapter

dsp programming introdsps

dsp core peripheralslecture

dsp fetches instructions