DSP Getting Started Simon Sun 孙巍

DSP Getting Started Simon Sun 孙巍 simon@seeddsp.com

Agenda  Using Code Composer Studio (CCS)  Analog Interfacing  Creating A Stand-Alone System  Using Chip Support Library (CSL)  Using DSP/BIOS  Profiler  Simulator/Emulator

Using Code Composer Studio

Outline  Code Composer Studio (CCS)  Projects  Build Options  Build Configurations  Configuration Tool  Header Files  CCS Automation

Code Generation.out Editor.sa Asm Optimizer.c /.cpp Compiler Asm.asm Linker.obj Link.cmd.map

Code Composer Studio SIM  Simulator DSK’s Code Composer Studio Includes:  Integrated Edit / Debug GUI Edit DSK EVM Third Party  BIOS:Real-time kernel Real-time analysis DSP/BIOS Libraries DSP/BIOS Config Tool Debug  Code Generation Tools Compiler Asm Opto Asm Standard Runtime Libraries.out Link XDS DSP Board CCS is Project centric...

Outline Code Composer Studio (CCS)  Projects  Build Options  Build Configurations  Configuration Tool  Header Files  CCS Automation

What is a Project? Project (.PJT ) file contain: References to files:  Source  Libraries  Linker, etc … Project settings:  Compiler Options  DSP/BIOS  Linking, etc … Let’s look more closely at Build Options and Configurations …

 Set as Active Project Keep multiple projects open  Add files… to project Add drag-n-drop files onto.PJT  Open for Editing Opens PJT with text editor  Configurations… Keep multiple setsof build options  Options… Set build options Right-Click Menu

Compiler Build Options  Debug and Optimize options conflict with each other, therefore they should be not be used together These can be set/modified by …  Nearly one-hundred compiler options available to tune your code's performance, size, etc.  Following table lists most commonly used options: OptionsDescription -mv6700Generate ‘C67x code (‘C62x is default) -mv67pGenerate ‘C672x code -mv6400 Generate 'C64x code -mv6400+Generate 'C64x+ code -fr Directory for object/output files -fs Directory for assembly files Debug -gEnables src-level symbolic debugging -ssInterlist C statements into assembly listing Optimize (release) -o3Invoke optimizer (-o0, -o1, -o2/-o, -o3) -kKeep asm files, but don't interlist

-g -fr“$(Proj_dir)\Debug" -d"_DEBUG" -mv6700 Build Options GUI  GUI has 8 pages of options for code generation tools  Default build options for a new project are shown  Basic page defaults are -g -mv6700 To make options easier, TI recommends using …

Build Configurations  For new projects, CCS automatically creates two build configurations:  Debug ( unoptimized )  Release (optimized) -g -fr“$(Proj_dir)\Debug" -d"_DEBUG" -mv6700-o3 -fr“$(Proj_dir)\Release" -mv6700

Build Configurations  For new projects, CCS automatically creates two build configurations:  Debug ( unoptimized )  Release (optimized) -g -fr“$(Proj_dir)\Debug" -d"_DEBUG" -mv6700-o3 -fr“$(Proj_dir)\Release" -mv6700 $(Proj_dir) Indicates the current project directory. This aids in project portability. See SPRA913 (Portable CCS Projects) for more information.

Two Default Build Configurations  For new projects, CCS automatically creates two build configurations:  Debug ( unoptimized )  Release (optimized)  Use the drop-down to quickly select build config. -g -fr“$(Proj_dir)\Debug" -d"_DEBUG" -mv6700-o3 -fr“$(Proj_dir)\Release" -mv6700

Two Default Build Configurations  For new projects, CCS automatically creates two build configurations:  Debug ( unoptimized )  Release (optimized)  Use the drop-down to quickly select build config.  Add/Remove build config's with Project Configurations dialog (on project menus)  Edit a configuration: 1. Set it active 2. Modify build options (shown previously) 3. Save project -g -fr“$(Proj_dir)\Debug" -d"_DEBUG" -mv6700-o3 -fr“$(Proj_dir)\Release" -mv6700

OptionsDescription -o Output file name -m Map file name -c Auto-initialize global/static C variables -x Exhaustively read libs (resolve back ref's) Linker Options  By default, linker options include the –o option  We recommend you add the –m option  “$(Proj_dir)\Debug\" indicates one subfolder level below project (.pjt) location  Run-time Autoinit (-c) tells compiler to initialize global/static variables before calling main()  Autoinit discussed in Ch 3 -c -m "$(Proj_dir)\Debug\lab.map" -o"$(Proj_dir)\De $(Proj_dir)\Debug\lab.out Run-time Autoinitialization $(Proj_dir)\Debug\lab.map

Using Separate Output Folders  When changing configurations, the -fr and -fs options prevents files from being overwritten  While not required, it allows you to preserve all variations of your project’s output files c60001day iw6000 labs lab2 Debug lab.out lab.obj Release lab.out lab.obj Debug files Release files

Outline Code Composer Studio (CCS) Projects Build Options Build Configurations  Configuration Tool  Header Files  CCS Automation

DSP/BIOS Configuration Tool Simplifies system design by:  Automatically includes the appropriate runtime support libraries  Automatically handles interrupt vectors and system reset  Handles system memory configuration (builds CMD file)  Generates 5 files when CDB file is saved:  C file, Asm file, 2 header files and a linker command (.cmd) file  More to be discussed later … Simplifies system design by:  Automatically includes the appropriate runtime support libraries  Automatically handles interrupt vectors and system reset  Handles system memory configuration (builds CMD file)  Generates 5 files when CDB file is saved:  C file, Asm file, 2 header files and a linker command (.cmd) file  More to be discussed later …

Outline Code Composer Studio (CCS) Projects Build Options Build Configurations Configuration Tool  Header Files  CCS Automation

Including Header Files in C /* * ======== Include files ======== */ #include #include "sine.h" #include "edma.h" 1.What is #include used for? 2.What do header (.h) files contain? It adds the contents of the header file to your C file at the point of the #include statement. Let's look at a header file...

Example Header Files /* *======== sine.h ======== *This file contains prototypes for all *functions and global datatypes *contained in sine.c */ #ifndef SINE_Obj typedef struct { float freqTone; float freqSampRate; float a; float b; float y0; float y1; float y2; … } SINE_Obj; #endif void copyData(short *inbuf, …); void SINE_init(SINE_Obj *sineObj, …); … /* * ======== edma.h ======== * This file contains references for all * functions contained in edma.c */ void initEdma(void); void edmaHwi(int tcc); extern EDMA_Handle hEdma;  Header files can contain any C code to be used over and over again  Usually a header file is paired with a C file or library object file. Essentially, the header file provides a description of the global items in the “paired” file.  Most commonly, header files contain:  Function prototypes  Global data references, such as new type definitions Therefore...

Including Header Files in C /* * ======== Include files ======== */ #include #include "sine.h" #include "edma.h" 1.What is #include used for? 2.What do header (.h) files contain? 3.What is the difference between and “.h”? It adds the contents of the header file to your C file at the point of the #include statement. They can contain any C statements. Usually, they contain code that would otherwise need to be entered into every C file. They’re a shortcut.  Angle brackets tell the compiler to look in the specified include path.  Quotes “.h” indicate the file is located in the same location as the file which includes it.

Including Header Files in C /* * ======== Include files ======== */ #include #include "sine.h" #include "edma.h" 1.What is #include used for? 2.What do header (.h) files contain? 3.What is the difference between and “.h”?

Outline Code Composer Studio (CCS) Projects Build Options Build Configurations Configuration Tool Header Files  CCS Automation

CCS Automation  GEL Scripting  Command Window  CCS Scripting

GEL Scripting GEL:General Extension Language  C style syntax  Large number of debugger commands as GEL functions  Write your own functions  Create GEL menu items GEL:General Extension Language  C style syntax  Large number of debugger commands as GEL functions  Write your own functions  Create GEL menu items

Command Window Some frequently used commands:  load  reload  reset  restart  ba  wa  help  dlog,a  dlogclose  alias...  take  run  go  step  cstep  halt

CCS Scripting  Debug using VB Script or Perl  Using CCS Scripting, a simple script can:  Start CCS  Load a file  Read/write memory  Set/clear breakpoints  Run, and perform other basic debug functions  Debug using VB Script or Perl  Using CCS Scripting, a simple script can:  Start CCS  Load a file  Read/write memory  Set/clear breakpoints  Run, and perform other basic debug functions

Outline Code Composer Studio (CCS) Projects Build Options Build Configurations Configuration Tool Header Files CCS Automation

Analog Interfacing

Learning Objectives  List various families of TI Analog that connect to DSP systems  Demonstrate how to find information on TI Analog components  List key and additional selection criteria for an A2D converter  Identify challenges in adding peripherals to a DSP design  Identify TI support to meet above design challenges  Describe the types of Analog EVMs available from TI  Select and configure a desired analog system from available EVMs  Create driver code with the Data Converter Plug-In  Apply Plug-in generated code to a given system 2

Interfacing TI DSP to TI Analog TI Analog Finding Information Data Converters Selecting An Example ADC Development Challenges Analog EVMs Data Converter Plug-In Completing the Code Build, Run, Evaluate Lessons Learned Additional Information… A/D 11100010011 3

TI Analog ADC Data Trans POWER SOLUTION DAC OP-AMPs/Comparators/Support - High Speed Amplifiers - Low Power, RRIO Signal Amps - Instrumentation Amps - Audio Power Amps - Power Amps - Commodity Amps - Comparators - Temp Sensors - References - Special Functions Data Converter -Standard A/D and D/A - High Resolution/Precision converters - High Speed converters - Touchscreen controllers -  -Law/A-Law Telecom “SLAC”s - Communication, Video, & Ultrasound optimized converters/codecs - Audio & Voice band converters/Codecs - Industrial converters Data Transmission - Many standards - SERDES STANDARDS RS232 RS422 RS485 LVDS 1394/Firewire USB PCI CAN SONET Gigabit Ethernet GTL, BTL, etc. Power - Power Modules - Linear Regulators/ LDOs - DC-DC controllers - PFC - Load Share - Battery Management - Charge Pumps & Boost Converters - Supervisory Circuits - Power Distribution/Hotswap - References (Codec) RF RF (or Wireless) DATA TRANSMISSION Digital MSP430 TI DSP etc Clocking Solution Another system/ subsystem/ etc. Data Trans Clocks Clock Buffer & fanouts PLL based buffers & fanouts Multipliers & Dividers Jitter cleaners & synchronizers Memory specific solutions Synthesizers Real Time Clocks 4

TI’s High-Performance Analog Portfolio 5

Interfacing TI DSP to TI Analog A/D 11100010011 TI Analog Finding Information Data Converters Selecting An Example ADC Development Challenges Analog EVMs Data Converter Plug-In Completing the Code Build, Run, Evaluate Lessons Learned Additional Information… 7

On-Line Data Converter App Notes Most contain downloadable software examples for use with CCS or Embedded Workbench! Click on “Application Notes” from the Product Folder for links to specific devices 9

Amplifier Design Utilities 10

FilterPro Design Tool 11

SWIFT Design Tool 12

The I-to-V Pro Tool 13

Application Areas for TI Data Converters Embedded  High Perf. DSP  Portable / Low Power  Micro Systems High Precision Measurement  Over Sampling ∆Σ ADCs  Precision ADCs  Micro Systems  High Speed ADCs  Current Input ADC’s Touch-Screen Controller  Stand-Alone  Intelligent  Integrated Audio Audio  Voiceband Codecs  Consumer  Professional Audio High Speed Comm / Ultrasound  Pipeline ADCs  Current Steering DACs Industrial Control / Instrumentation  SAR ADCs  High Speed  Low Power  Simultaneous Sampling  Bipolar  Data Acquisition Systems  String / R2R DACs  Single Supply  Monitor & Control  Dual Supply 15

1K1001010K100K1M10M100M 24 20 16 12 8 Pipeline SAR Successive Approximation  Oversampling ADS1625  18 bit Delta Sigma  1.25 MSPS - Fastest on the market  (averages and filters out noise) ADS1605  16 bit Delta Sigma  5 MSPS ADS8411  16 bit  2 MSPS  Market Leader ADS5500  14 bit  125 MSPS  Market Leader TI ADC Technologies Current Technology Converter Resolution Conversion Rate 16

TI DAC Technologies Settling Time-  s 20 16 12 8 Current Steering Resistor String & R-2R  Converter Resolution 6810 42 1.05.001 1001000 Current Technology High Speed Video and Communication Update rate (MSPS) Typically 1 Output but a few 2 Output Current out Industrial Settling Time (µs) Number of Out put DACs Resistor String – Inexpensive R-2R – More accurate -Trimmed at final test Typically Voltage out MDAC’s coming (dig control gain/atten, Waveform gen.) Instrumentation & Measurement Typically for Calibration Current Technology 17

DACs – Delta Sigma High Resolution/Accuracy DAC122X Touch Screen Controllers Stand Alone Controllers Integrated Audio Controllers TI Data Converters High Precision Low bandwidth High Bandwidth Intelligent / high resolution 8051 core ADCs – Delta Sigma High Precision Medical, Industrial Control, Data Acquisition Simultaneous sampling Motor control ADCs – SAR Versatile, High Speed Communication, Imaging, Ultrasound ADCs – Pipeline Low power, Single and bipolar Suppy, Precision DACs – String / R2R Consumer Codecs, ADC/DAC Voice A/C Codecs Pro audio DACs, ADCs PGAs, SRCs, DITs Audio 18

 Go to “ti.com” with your browser  In the Products box, hover over Analog and Mixed Signal & select Data Converters  In the Data Converters Home box in the upper left, hover over Find a Device and select Parametric Search  Pick a bit resolution and sample rate, and a list of suitable devices are displayed, comparing numerous additional parameters, including: Device nameStatus Resolution Sample Rate Architecture# ChannelsSE vs Diff’lPwr Consumpt’n SINADSNRSFDRENOB Voltage rangesBandwidth# suppliesPins/Pkg Selecting a Device 20

ADS8361 from : http://focus.ti.com/docs/prod/folders/print/ads8361.html Resolution (Bits)16 Sample Rate (max)500 KSPS Search Sample Rate (Max) (SPS)500000 # Input Channels (Diff)4 Power Consumption (Typ) (mW)150 SNR (dB)83 SFDR (dB)94 DNL (Max) (+/-LSB)1.5 INL (Max) (+/-LSB)4 INL (+/- %) (Max)0.00375 No Missing Codes (Bits)14 Analog Voltage AV/DD (Min/Max) (V)4.75 / 5.25 Logic Voltage DV/DD (Min / Max) (V)2.7 / 5.5 Input TypeVoltage Input Configuration Range+/-2.5 V at 2.5 No. of Supplies2 21

Design Flow…  Product Selection  Key specifications (speed, resolution, …)  Secondary parameters (power, size, price, channels, …)  Research data base of candidate devices  Additional factors: ease of use, cost/value  Hardware Design  ADC / DAC pins, requirements  DSP pin matchup  Layout considerations (noise, supply requirements, etc  Software Authoring  Configuring the (serial) port  Configuring the peripheral  Getting/sending data from/to the peripheral  How? Write it yourself or with the help of an authoring tool… 23

I/O Device Development Challenges  Hardware Design  Pinouts, etc  Layout – noise minimization, etc  Software Design  Select modes for serial port  Select modes for ADC / DAC  Write modes to port / peripheral  Debug  Observe / verify performance  Modify design as required Analog Evaluation Modules (EVMs) : ADC, DAC, Power,... Chip Support Library (CSL) + Data Converter Plug-In (DCP) CCS 24

Analog EVMs  5-6K Interface Board  Compatible with TMS320 C5000 and C6000 series DSP starter kits  Supports parallel EVM’s up to 24 bits  Allows multiple clock sources for parallel/Serial converters  Supports two independent McBSP channels  Provides complete signal chain prototyping opportunities  Data Converter EVMs  3 standardized daughter card format (2 serial, 1 parallel)  Serial – support for SPI, McBSP, I2C; 1-16 I/O channels  Connects to (nearly) any control system  Stackable  Third Party Interface Boards  Avnet, SoftBaugh, Spectrum Digital, Insight - Memec Design …  Analog Interface Boards  Bipolar and single supply  In development – differential amps, instrumentation amps, active filters  $50 each! 27

Data Converter Plug-In  Allows rapid application development  Automatically generates required DSP source code  Removes the necessity to learn the converter “bit by bit”  Includes help for device features  Fully integrated into Code Composer Studio (2, 5, and 6K) 29

Launching the Data Converter Plug-In 30

Adding an Instance of the Desired Converter 31

Specify the Configuration Define the DSP properties Set desired ADC modes Write files… 32

DCP Files Added to CCS Project  “API” file prototypes the 6 functions generated by the DCPin tool  Object file implements all device coding and creates structures that manage the behavior of the device 33

Files Generated by Data Converter Plug-In  tidc_api.c  Set of API that all Data Converter Plug-In authored code supports  tidc_api.h  Header file common to all Data Converter Plug-In generated code  dc_conf.h  Configuration data that holds the selections made in the Plug-In  tads8361_ob.c  Implementation of the API for the given device instance  tads8361.h  Header file to define the exposed object specific elements All are fully coded by the Plug-In All are fully exposed to the user for study/modification as desired 34

Data Converter Plug-In Uniform API DCPAPI TTIDCSTATUS dc_configure(void *pDC); DCPAPI long dc_read(void *pDC); DCPAPI void dc_rblock(void *pDC, void *pData, unsigned long ulCount, void (*callback) (void *)); DCPAPI void dc_write(void *pDC, long lData); DCPAPI void dc_wblock(void *pDC, void *pData, unsigned long ulCount, void (*callback) (void *)); DCPAPI void dc_power(void *pDC, int bDown); All objects created with the Data Converter Plug-In share these six API 35

Data Converter Plug-In Structures TADS8361 *configure // DC API *power *read *write *rblock *wblock 0, 0, 0, 0, // unused *CallBack serial iMode Buffer // data bk ptr ulBuffSize // data bk size iXferInProgress DCP_SERIAL port intnum hMcBsp sConfig MCBSP_Obj allocated xmtEventId rcvEventId *baseAddr drrAddr dxrAddr hADC CSL Config Structure Interacting with the structures... TADS8361 * hADC; // make a handle to the DC structure hADC = &Ads8361_1; // initialize handle to point to our instance MCBSP_getRcvAddr(hADC->serial->hMcbsp); // obtain info from instance object->substruc 36

Data Converter Plug-In Review  Greatly reduces development time  For the DSP software developer: No need to learn the details of the converter  For the analog designer: No need to learn DSP programming to test a give data converter  Supports 117 devices on 5 DSP platforms  Where to get the Data Converter Plug-In plug-in :  Included in Code Composer Studio  Download (free of charge) from : http://www.ti.com/sc/dcplug-in 37

Adapting Lab 6 Code main.c #include "dc_conf.h" #include "t8361_fn.h“... initMcBSP(); dc_configure(&Ads8361_1) mcbsp.c... MCBSP_close(hMcbspControl); *((unsigned char*)0x90080006) |= 0x01; edma.c hEdmaRcv = EDMA_open(EDMA_CHA_REVT1, EDMA_OPEN_RESET); gEdmaConfigRcv.src = MCBSP_getRcvAddr(hMcbspData); gEdmaConfigRcv.src = MCBSP_getRcvAddr(hADC->serial->hMcbsp); hEdmaRcv = EDMA_open(EDMA_CHA_REVT0, EDMA_OPEN_RESET); if (dc_configure(&Ads8361_1) != TIDC_NO_ERR) return; TADS8361 * hADC; hADC = &Ads8361_1; 39

Observations of Results Audio sounded ‘scratchy’ - Why?  8361 puts channel number in 2 MSBs  We can adapt the CSL structure to change this  We could mask off those bits before passing data to the algo  In “real life”, we’d probably want these bits to verify channel #  Mismatched data rates between input and output  In real-life situation, one wouldn’t still be using half a codec, so this problem would not have been encountered normally  If such a case did arise, we could have:  Rewired the ADC to run off the clocks provided by the codec  Adjusted rates to match in software  Sample-rate converted in the DSP 41

Conclusions on TI DSP + TI Analog …  TI offers a large number of low cost analog EVMs to allow developers to ‘snap together’ a signal chain for ultra-fast test and debug of proposed components  TI provides CSL and Data Converter Plug-In to vastly reduce the effort in getting a DSP to talk to ports and peripherals  Getting to ‘signs of life’ result is now a matter of minutes instead of days/weeks  Final tuning will sometimes be required, but amounts to a manageable effort with a device already easily observed, rather than ‘groping in the dark’ as often was the case otherwise 43

Driver Object Details long ads8361_read(void *pDC) prototype of the DC API { TADS8361 *pADS = pDC; get handle to object if (!pADS) return; parameter check if (pADS->iXferInProgress) return; verify no bk op in progress while (!MCBSP_rrdy(pADS->serial->hMcbsp)); actual SP ops use CSL API return MCBSP_read(pADS->serial->hMcbsp); when SP ready, return data rcvd }spin loop – oops ! ! t8361_ob.c code to implement the DC API, eg: read fn TADS8361 Ads8361_1 = { &ads8361_configure, &ads8361_power, &ads8361_read, &ads8361_write, &ads8361_rblock, &ads8361_wblock, 0, 0, 0, 0, 0, &serial0, ADC1_MODE, 0, 0, 0 }; t8361_ob.c make & fill instance obj typedef struct { TTIDC f; // std DC API void (*CallBack)(void *); DCP_SERIAL *serial; int iMode; int* Buffer; unsigned longulBuffSize; volatile intiXferInProgress; } TADS8361; t8361_ob.c define instance object type 45

Structure Definitions typedef struct { unsigned int port; Number of serial port used unsigned short intnum; Which interrupt driver uses MCBSP_HANDLE hMcbsp; Serial port handle (CSL) MCBSP_CONFIG sConfig; Ptr to CSL ser pt config struc } DCP_SERIAL; typedef struct { Uint32 allocated; Is port available? Uint32 xmtEventId; Which ints port will use Uint32 rcvEventId; volatile Uint32 *baseAddr; Address of port registers Uint32 drrAddr;* Data receive register Uint32 dxrAddr;* Data transmit register } MCBSP_Obj, *MCBSP_Handle; from TIDC_API.h from csl_mcbsp.h typedef struct { TTIDCSTATUS (* configure ) (void *pDc); void (* power ) (void *pDc, int bDown); long (* read ) (void *pDc); void (* write ) (void *pDc, long lData); void (* rblock ) (void *pDC, void *pData, unsigned long ulCount, void (*callback) (void *)); void (* wblock ) (void *pDC, void *pData, unsigned long ulCount, void (*callback) (void *)); void* reserved[4]; } TTIDC; typedef struct { TTIDCSTATUS (* configure ) (void *pDc); void (* power ) (void *pDc, int bDown); long (* read ) (void *pDc); void (* write ) (void *pDc, long lData); void (* rblock ) (void *pDC, void *pData, unsigned long ulCount, void (*callback) (void *)); void (* wblock ) (void *pDC, void *pData, unsigned long ulCount, void (*callback) (void *)); void* reserved[4]; } TTIDC; from TIDC_API.h 46

Analog Design Tools in Development OpAmpPro - Input data selects IC  Input data contains transfer function  Input data selects the appropriate circuit  Program enables adjustment resistor & worst case calculations  Op Amp Pro selects IC by analyzing applications and input data  Calculates error due to external component & IC tolerances Tina-TI Spice Simulation Program  To be offered free on www.ti.com  Uses TI’s SPICE macromodels  Allows general spice circuit simulation  Analysis  Circuit optimization 47

Creating A Stand-Alone System

Outline  Flow of events in the system  Programming Flash  Flash Programming Procedure  Debugging ROM’d code

Creating a Stand-alone System Codec SDRAMSDRAM Flash RAM C6x CPU SRAMSRAM CCS............  What is the flow of events from reset to main()?  How do you create a stand-alone system?

HardwareSoftware Reset H/W Device Reset System Timeline

Reset  h/w status  actions taken RESET  When RESET goes high, the following occurs:  Sample endian pin  Sample boot pins  Many registers are initialized to default values (always a good idea to initialize them anyway)  Peripherals are reset  Cache: L1 on, L2 off  Interrupts off

HardwareSoftware Reset H/W EDMA Device Reset Boot Loader System Timeline

What is a Boot Loader? SrcDest C6000  Host  P  Ext memory  Int mem  Ext mem “Boot loader” (EDMA) “slow”“fast”  In most systems, information must be moved before CPU execution begins. For example:  It could be from slow, flash ROM to fast RAM  Or, from the host memory to the DSP  C6000 uses the EDMA for Memory-to-Memory transfers  After boot, CPU always starts executing at address 0

L2 CE1 0000_0000 reset C671x Boot CE2 CE3 CE0 HD[4:3] Boot Modes 00 Host Boot (HPI) 01 8-bit ROM 10 16-bit ROM 11 32-bit ROM 1KBytes  Mode 0: Host boots C671x via HPI  Modes 1, 2, 3: Memory Copy  EDMA copies from start of CE1 to 0x0  Uses default ROM timings  After transfer, PC = 0x0  Bootloader copies 1K bytes  Must always boot (No “no-boot” option) ‘ C671x CPU L2 EDMA BOOT PinsRESET Boot Logic Host HPIHPI

L2 0000_0000 reset C64x Boot CE2 CE3 BEA[19:18] Boot Modes 00 None 01 Host Boot (HPI/PCI) 10 EMIFB (8-bit) 11 Reserved 1KBytes CE0 CE1 CE2 CE3 CE0 CE1 EMIFA EMIFB  Mode 0: No Boot bootmode; CPU starts at 0x0  Mode 1: Host boots C64x via HPI or PCI  Mode 2: Memory Copy  EDMA copies from start of EMIFB CE1 to 0x0  After transfer, PC = 0x0  Bootloader copies 1K bytes ‘ C64x CPU L2 EDMA BOOT PinsRESET Boot Logic Host HPIHPI PCIPCI

HardwareSoftware Reset H/W EDMAboot.asm Device Reset Boot Loader 2 nd Boot Loader  No Boot or  From EPROM or  Via HPI System Timeline  Software begins running at address 0 (Reset Vector)

User Boot Code boot.asm ; Configure EMIF... ; Copy Initialized Sections mvkl FLASH, A0 mvkh FLASH, A0 mvkl IRAM, A1... ; Start Program */ b _c_int00();  Your 2 nd Boot Loader should perform the following tasks:  (Optional) Self-Test routine  Configure the EMIF  Copy section(s) of code/data  Call _c_int00()  Code size is limited to 1K bytes  1K memory can be reused using overlay (we do this in an optional lab)  BOOT.ASM written in assembly (because it’s called before the C-environment is initialized)

HardwareSoftware Reset H/W EDMAboot.asmProvided by TI Device Reset Boot Loader 2 nd Boot Loader BIOS_init ( _c_int00 )  No Boot or  From EPROM or  Via HPI  EMIF  Self test  Load remaining initialized sections System Timeline  Software begins running at address 0 (Reset Vector)  When using “Boot Loader”, reset vector = address of boot.asm  If “Boot Loader” is not used, then usually Reset Vector = BIOS_init().

BIOS_init ( _c_int00 )  Initialize the C environment …  … and then call main()  Initialize BIOS  Initialize C environment:  Init global and static vars (copy.cinit .bss )  Setup stack pointer (SP) and global pointer (DP)  Initialize BIOS  Create DSP/BIOS objects  Bind IOM device drivers  Set NMIE = 1  Call main( ) Note: When using a.cdb file, reset vector defaults to _c_int00

HardwareSoftware Reset H/W EDMAboot.asmProvided by TI main.c Device Reset Boot Loader 2 nd Boot Loader BIOS_init ( _c_int00 ) System Init Code  No Boot or  From EPROM or  Via HPI  EMIF  Self test  Load remaining initialized sections  Initialize:  Stack  Heap  Globals  Bind IOM devices  Enable NMIE  Initialize periph’s  Enable indiv ints  Return(); System Timeline  Software begins running at address 0 (Reset Vector)  When using “Boot Loader”, reset vector = boot.asm  If “Boot Loader” is not used, then usually Reset Vector = BIOS_init(). Same stuff we’ve been doing in our lab exercises

HardwareSoftware Reset H/W EDMAboot.asmProvided by TI main.cProvided by TI Device Reset Boot Loader 2 nd Boot Loader BIOS_init ( _c_int00 ) System Init Code BIOS_start  No Boot or  From EPROM or  Via HPI  EMIF  Self test  Load remaining initialized sections  Initialize:  Stack  Heap  Globals  Bind IOM devices  Enable NMIE  Initialize periph’s  Enable indiv ints  Return();  GIE = 1 System Timeline  Software begins running at address 0 (Reset Vector)  When using “Boot Loader”, reset vector = boot.asm  If “Boot Loader” is not used, then usually Reset Vector = BIOS_init().

HardwareSoftware Reset H/W EDMAboot.asmProvided by TI main.cProvided by TI Device Reset Boot Loader 2 nd Boot Loader BIOS_init ( _c_int00 ) System Init Code BIOS_start DSP/BIOS Scheduler  Boot frm EPROM or  Via HPI or  No Boot  EMIF  Self test  Load remaining initialized sections  Initialize:  Stack  Heap  Globals  Bind IOM devices  Enable NMIE  Initialize periph’s  Enable indiv ints  Return();  GIE = 1  Runs IDL if no other threads are ready System Timeline  Software begins running at address 0 (Reset Vector)  When using “Boot Loader”, reset vector = boot.asm  If “Boot Loader” is not used, then usually Reset Vector = BIOS_init().

Outline Flow of events in the system  Programming Flash  Flash Programming Procedure  Debugging ROM’d code

Non-Volatile Memory SDRAMSDRAM Flash RAM C6000 CPU RAMRAM Non-volatile Options  ROM  EPROM  FLASH How do you program a FLASH memory?

Flash Programming Options MethodDescriptionTarget?  CCS plug-in that writes to flash via JTAG (DSK, EVM, XDS)  Board support library commands such as flash_write()  “On the fly” programming Any  Industry-standard programmer Data I/O FlashBurn BSL DSK  User writes their own flash alg Custom Target Specific How does FlashBurn work?

Flashburn CCS DSK DSP Flash L2 RAM EPROM image file FBTC file 1.Flashburn plugin downloads and runs the FBTC file (FlashBurn Transfer Control) to establish continuous link between CCS & DSP. 2.Choose “Erase Flash” to tell FBTC program running on DSP to erase the flash memory. 3.Select “Program Flash” to stream the EPROM image file (.hex) down to the DSP. The FBTC program must be customized for whatever flash memory is on the target board (documentation is provided). 1.Flashburn plugin downloads and runs the FBTC file (FlashBurn Transfer Control) to establish continuous link between CCS & DSP. 2.Choose “Erase Flash” to tell FBTC program running on DSP to erase the flash memory. 3.Select “Program Flash” to stream the EPROM image file (.hex) down to the DSP. The FBTC program must be customized for whatever flash memory is on the target board (documentation is provided).

Using FlashBurn  Flashburn saves these settings to a.CDD file  Flash Burn Transfer Controller (FBTC)  When FBTC has been downloaded to DSP and is running, FlashBurn is “connected” to DSP

Outline Flow of events in the system Programming Flash  Flash Programming Procedure  Debugging ROM’d code

Debug Flow Build app.out Flash L2 C6x CPU DSK CCS SDRAM File  Load Program…

Flash Data Flow Build app.out hex6x app.hex FlashBurn Flash RAM C6x CPU hex.cmd app.cdd DSK What is the procedure for creating a standalone system?

Flash/Boot Procedure Plan out your system’s memory map – Before and After boot.  Verify address for “top of Flash memory” in your system  Plan for BOOT memory object 1KB in length o Created for secondary boot-loader (boot.asm) o Not absolutely required, but provides linker error if boot.asm becomes larger than 1KB 1

Flash/Boot Procedure Plan out your system’s memory map – Before and After boot.  Verify address for “top of Flash memory” in your system  Plan for BOOT memory object 1KB in length o Created for secondary boot-loader (boot.asm) o Not absolutely required, but provides linker error if boot.asm becomes larger than 1KB  Note, when using the hardware boot, you do not have to relink your program with run/load addresses, HEX6x will take care of this for you (step #4) 1

System Memory Map (load vs. run) Load-time 0000_0000 8000_0000 9000_0000 9000_0400 0001_0000 FLASH “initialized sections” 9002_0000  Boot-loader copies code/data from FLASH to IRAM/SDRAM  When using the hardware boot, you do not have to relink your program with run/load addresses, HEX6x will take care of it for you  Some code/data can still reside in flash FLASH “boot.asm” Run-time BOOT “boot.asm” 0000_0000 IRAM init + uninit 0000_0400 SDRAM init + uninit 8000_0000 9000_0000 9000_0400 0001_0000 9002_0000 B O O T FLASH “init sections” FLASH “boot.asm”

Flash/Boot Procedure Modify.cdb, memory manager and do the following:  Create necessary memory areas (e.g. BOOT)  Direct the BIOS & compiler sections to their proper locations (when using the boot loader, these should be the runtime locations we have been using for all of our lab exercises) 2 Plan out your system’s memory map – Before and After boot. 1

Create Memory Objects (as needed) Memories listed in our previous memory-maps New

Flash/Boot Procedure Modify.cdb, memory manager and do the following:  Create necessary memory areas (e.g. boot)  Direct the BIOS & compiler sections to their proper locations 2 Create a user link.cmd file to specify boot.asm’s load/run addr 3 Plan out your system’s memory map – Before and After boot. 1

User Linker Command File (link.cmd) SECTIONS {.boot_load :> BOOT }

Flash/Boot Procedure Modify.cdb, memory manager and do the following:  Create necessary memory areas (e.g. boot)  Direct the BIOS & compiler sections to their proper locations 2 Create a user link.cmd file to specify boot.asm’s load/run addr 34  Modify hex.cmd w/proper options  Run hex6x to create.hex file Convert app.out to app.hex for Flash programming:Plan out your system’s memory map – Before and After boot. 1

Hex Conversion Utility (hex6x.exe) hex.cmd app.out hex6x app.hex  ASCII-hex  Tektronix  Intel MCS-86  Motorola-S  TI-tagged  Converts a “.out” file into one of several hex formats suitable for loading into an EPROM programmer.  Use: hex6x filename.cmd  Hex command file specifies options and filenames… What does hex.cmd look like?

Hex6x - Boot Options If –e is not used to set the entry point, then it will default to the entry point indicated in the COFF object file. For more information on using Hex6x for building a boot image, please refer the the C6000 Assembly Language Tools Users Guide (SPRU186).

c:\iw6000\labs\lab14a\debug\lab.out -a -image -zero -memwidth 8 -map.\Debug\lab14hex.map -boot -bootorg 0x90000400 -bootsection.boot_load 0x90000000 ROMS { FLASH: org = 0x90000000, len = 0x0040000, romwidth = 8, files = {.\Debug\lab14.hex} } Hex Command File (Flash ROM) Flash ROM 0x90000000.boot_load (boot.asm) 0x90000400 COPY_TABLE Remaining Inititalized Sections 0x90040000 Click here to see the COPY_TABLE

.sect“.boot_load” mvkl mvkh COPY_TABLE, a3 ldw*a3++, entry copy_sect_top: ldw*a3++, size ldw*a3++, dest [!size]bcopy_done copy_loop: ldb*a3++, data subsize,1,size [size]bcopy_loop [!size]bcopy_sect_top stbdata,*dest++ copy_done: bentry HEX6x Created Copy_Table COPY_TABLEEntry Point Section 1 Size Section 1 Dest Section 1 Data Section 2 Size Section 2 Dest Section 2 Data Section N Size Section N Dest Section N Data 0x00000000 Above code is a pseudo representation of the boot.asm file. In the map file this looks like....text.cinit etc -bootorg 0x90000400 Specifies address where symbol COPY_TABLE should reside

Map file representation of COPY_TABLE CONTENTS: 64000000..6400011f.boot_load 64000120..640003ff FILL = 00000000 64000400..6400af13 BOOT TABLE.hwi_vec : btad=64000400 dest=00003000 size=00000200.sysinit : btad=6400060c dest=00003520 size=00000360.trcdata : btad=64000974 dest=00002d68 size=0000000c.gblinit : btad=64000988 dest=00002d74 size=00000034.cinit : btad=640009c4 dest=00003880 size=00001454.pinit : btad=64001e20 dest=00002da8 size=0000000c.const : btad=64001e34 dest=00002db4 size=000000cf.text : btad=64001f0c dest=00004ce0 size=00003960.bios : btad=64005874 dest=00008640 size=00003ee0.stack : btad=6400975c dest=0000c520 size=00000400.trace : btad=64009b64 dest=0000c920 size=00000200.rtdx_text : btad=64009d6c dest=0000cf60 size=00000ee0.args : btad=6400ac54 dest=00002fc0 size=00000004.log : btad=6400ac60 dest=00002fc4 size=00000030.LOG_system$buf : btad=6400ac98 dest=0000e300 size=00000100.logTrace$buf : btad=6400ada0 dest=0000e400 size=00000100.sts : btad=6400aea8 dest=0000e2a0 size=00000060 6400af14..6407ffff FILL = 00000000 lab14hex.map  By default, the HEX6x utility adds all “initialized” sections to the bootloader table

Flash/Boot Procedure Modify.cdb, memory manager and do the following:  Create necessary memory areas (e.g. boot)  Direct the BIOS & compiler sections to their proper locations 2 Create a user link.cmd file to specify boot.asm’s load/run addr 34  Modify hex.cmd w/proper options  Run hex6x to create.hex file Convert app.out to app.hex for Flash programming: 5 Start Flashburn and fill-in the blanks:  hex cmd file  hex image file  FBTC file  Origin & length of Flash Plan out your system’s memory map – Before and After boot. 1

Using FlashBurn  Flashburn saves these settings to a.CDD file  Flash Burn Transfer Controller (FBTC)  When FBTC has been downloaded to DSP and is running, FlashBurn is “connected” to DSP

Flash/Boot Procedure Modify.cdb, memory manager and do the following:  Create necessary memory areas (e.g. boot)  Direct the BIOS & compiler sections to their proper locations 2 Create a user link.cmd file to specify boot.asm’s load/run addr 34  Modify hex.cmd w/proper options  Run hex6x to create.hex file Convert app.out to app.hex for Flash programming:Erase the FLASH 65 Start Flashburn and fill-in the blanks:  hex cmd file  hex image file  FBTC file  Origin & length of Flash Program FLASH, run, and debug ROM code 7 Plan out your system’s memory map – Before and After boot. 1 What if you want your image in the host's ROM?

Putting the DSP Image on the Host Build app.out ofd6x app.xml appimage.c perl script Flash Host CPU Target System C6x DSP RAM  Use Object File Description (OFD6x) to create an XML description of the.out file  Perl script uses XML to convert initialized sections from.OUT file into a C description of the program’s image  For more info refer to Using OFD Utility to Create a DSP Boot Image ( SPRAA64.PDF )

Outline Flow of events in the system Programming Flash Flash Programming Procedure  Debugging ROM’d code

Debugging Your Application 1.Use Hardware breakpoints to help locate the problem.  To debug ROM program, it’s especially important to put a H/W breakpoint at the start of your program, otherwise you won’t be able to halt the code in time to see what executing. 2.Create a “stop condition” (infinite loop) in your boot code. When the code stops, open CCS and load the symbol table.  Solutions:  If your application has problems booting up or operating after boot, how do you debug it?  Problem:  Standard breakpoints (aka Software Breakpoints) cannot be used with program code residing in ROM-like memory.  When using software breakpoints, CCS replaces the ‘marked’ instruction with an emulation-halt instruction. This cannot be done in ROM-like memory.

Some Helpful Hints (that caught us)  When you (try to) boot your application for the first time, your system may not work as expected. Here are a couple tips:  A GEL file runs each time you invoke CCS. This routine performs a number of system initialization tasks (such as setting up the EMIF, etc.). These MUST now be done by your boot routine.  Upon delivery, the DSK’s POST routine is located in its Flash memory and runs each time you power up the DSK. To perform its tests, it will initialize parts of the system (e.g. EMIF, codec, DMA, SP, etc). When you reprogram the Flash with your code (and boot routine), you will need to initialize any components that will be used.  Bottom line, it’s easy to have your code working while in the “debug” mode we mentioned earlier, then have it stop working after Flashing the program. Often, this happens when some components don’t get initilized properly.

Outline Flow of events in the system Programming Flash Flash Programming Procedure Debugging ROM’d code

Using Chip Support Library

Outline  Chip Support Library (CSL)  Programming EDMA with CSL  CSL’s _FMK macro ( field make )  Source Insight

Chip Support Library  C-callable library that supports programming of on-chip peripherals  Supports peripherals in three ways: 1. Resource Management (functions)  Verify if periph is available  “Check-out” a peripheral 2. Simplifies Configuration  Data structures  Config functions 3. Macros improve code readability  You still have to know what you want the peripherals to do, CSL just simplifies the code and maintenance CSL ModuleDescription CacheCache & internal memory CHIPSpecifies device type CSLCSL initialization function DATSimple block data move DMADMA (for ‘0x devices) EDMAEnhanced DMA (for ‘1x dev) EMIFExternal Memory I/F EMIFA EMIFB C64x EMIF’s GPIOGeneral Purpose Bit I/O HPIHost Port Interface I2CI 2 C Bus Interface IRQHardware Interrupts McASPAudio Serial Port McBSPBuffered Serial Port PCIPCI Interface PLLPhase Lock Loop PWRPower Down Modes TCPTurbo Co-Processor TIMEROn-chip Timers UTOPIAUtopia Port (ATM) VCPViterbi Co-Processor XBUSeXpansion Bus The best way to understand CSL is to look at an example...

General Procedure for using CSL 1.#include #include Timer Example: 1.Include Header Files  Library and individual module header files 1.Include Header Files  Library and individual module header files

General Procedure for using CSL 1.#include #include 2.TIMER_Handle myHandle; Timer Example: 1. Include Header Files  Library and individual module header files 2.Declare Handle  For periph’s with multiple resources 1. Include Header Files  Library and individual module header files 2.Declare Handle  For periph’s with multiple resources

General Procedure for using CSL 1.#include #include 2.TIMER_Handle myHandle; 3.TIMER_Config myConfig = { control, period, counter }; Timer Example: 1.Include Header Files  Library and individual module header files 2.Declare Handle  For periph’s with multiple resources 3.Define Configuration  Create variable of configuration values 1.Include Header Files  Library and individual module header files 2.Declare Handle  For periph’s with multiple resources 3.Define Configuration  Create variable of configuration values

1. Include Header Files  Library and individual module header files 2.Declare Handle  For periph’s with multiple resources 3.Define Configuration  Create variable of configuration values 4.Open peripheral  Reserves resource; returns handle 1. Include Header Files  Library and individual module header files 2.Declare Handle  For periph’s with multiple resources 3.Define Configuration  Create variable of configuration values 4.Open peripheral  Reserves resource; returns handle General Procedure for using CSL 1.#include #include 2.TIMER_Handle myHandle; 3.TIMER_Config myConfig = { control, period, counter }; 4.myHandle = TIMER_open( TIMER_DEVANY,... ); Timer Example:

1. Include Header Files  Library and individual module header files 2.Declare Handle  For periph’s with multiple resources 3.Define Configuration  Create variable of configuration values 4.Open peripheral  Reserves resource; returns handle 5.Configure peripheral  Applies your configuration to peripheral 1. Include Header Files  Library and individual module header files 2.Declare Handle  For periph’s with multiple resources 3.Define Configuration  Create variable of configuration values 4.Open peripheral  Reserves resource; returns handle 5.Configure peripheral  Applies your configuration to peripheral General Procedure for using CSL 1.#include #include 2.TIMER_Handle myHandle; 3.TIMER_Config myConfig = { control, period, counter }; 4.myHandle = TIMER_open( TIMER_DEVANY,... ); 5.TIMER_config(myHandle, &myConfig); Timer Example:

Outline Chip Support Library (CSL)  Programming EDMA with CSL  CSL’s _FMK macro ( field make )  Source Insight

Programming the EDMA  There are three methods available for programming the EDMA: (1)Writing directly to the EDMA registers. (2)Using the Chip Support Library (CSL). (3)Graphically using the DSP/BIOS GUI interface.

Programming the EDMA - Direct (1)Writing directly to the EDMA registers:  Although this method is straightforward, it relies on a good understanding of the EDMA and the DSP memory map.  This method is tedious and prone to errors. #include #include void EDMA_setup (void) { *(unsigned volatile int *) ECR = 0xffff; *(unsigned volatile int *) EER = 0xffff; *(unsigned volatile int *) CIPR = 0xffff; *(unsigned volatile int *) CIER = 0xffff;...}

Programming the EDMA - CSL (2)Using the Chip Support Library:  The CSL provides a C language interface for configuring and controlling the on-chip peripherals, in this case the EDMA.  The library is modular with each module corresponding to a specific peripheral. This has the advantage of reducing the code size.  Some modules rely on other modules also being included, for example the IRQ module is required when using the EDMA module.

Programming the EDMA - CSL Example

 CSL programming procedure: (1)Create handles for the EDMA channel and reload parameters: (2)Create the EDMA configuration: Programming the EDMA - CSL Example EDMA_Handle hEdma; EDMA_Config cfgEdma;

 CSL programming procedure (cont): (3)Create the configuration structures for the ping and pong channels: Programming the EDMA - CSL Example EDMA_Config cfgEdmaPong = {0x28720002, EDMA_SRC_OF(McBSP0_DRR), EDMA_CNT_OF(BUFF_SZ), EDMA_DST_OF((unsigned int)cin_data), EDMA_IDX_OF(0x00000004), }; EDMA_RLD_OF(0x00000000)}; EDMA_Config cfgEdmaPing = { EDMA_Config cfgEdmaPing = {0x28720002, EDMA_SRC_OF(McBSP0_DRR), EDMA_CNT_OF(BUFF_SZ), EDMA_DST_OF((unsigned int)in_data), EDMA_IDX_OF(0x00000004), }; EDMA_RLD_OF(0x00000000)};

Programming the EDMA - CSL Example  CSL programming procedure (cont): (4)Map the event to a physical interrupt (see Interrupt section): This maps the EDMA_INT interrupt to CPU_INT8. (5)Set the interrupt dispatcher configuration structure (see Interrupt section): IRQ_map (IRQ_EVT_EDMAINT, 8); IRQ_configArgs (IRQ_EVT_EDMAINT, EdmaIsr, EdmaIsr, 0x00000000, 0x00000000, IRQ_CCMASK_DEFAULT, IRQ_CCMASK_DEFAULT, IRQ_IEMASK_ALL); IRQ_IEMASK_ALL);

Programming the EDMA - CSL Example  CSL programming procedure (cont): (6)Open up an EDMA channel associated with the Timer 1 (remember each EDMA is associated with a specific event): (7)Allocate the EDMA reload parameters: Note: -1 means allocate at any available location. (8)Copy the first reload configuration structure to the EDMA configuration structure: hEdmaPing = EDMA_allocTable (-1); hEdmaPong = EDMA_allocTable (-1); cfgEdma = cfgEdmaPing; hEdma = EDMA_open (EDMA_CHA_TINT1, EDMA_OPEN_RESET);

Programming the EDMA - CSL Example  CSL programming procedure (cont): (9)Configure the link fields of the configuration structure: This can be done at stage 3 but in this way we do not know the numerical value of the reload address. (10)Setup the EDMA channel using the configuration structure: cfgEdmaPing.rld = EDMA_RLD_RMK(0,hEdmaPong); cfgEdmaPong.rld = EDMA_RLD_RMK(0,hEdmaPing); cfgEdma.rld = EDMA_RLD_RMK(0,hEdmaPong); EDMA_config (hEdmaPing, &cfgEdmaPing); EDMA_config (hEdmaPong, &cfgEdmaPong);

Programming the EDMA - CSL Example  CSL programming procedure (cont): (11)Finally initialise all the EDMA registers: EDMA_RSET (ECR, 0xffff);// clear all events EDMA_enableChannel(hEdma); EDMA_RSET (EER, 0x4);// set the timer 1 event enable bit EDMA_RSET (CIPR, 0xffff); EDMA_RSET (CIER, 0x4);// make the timer 1 event generate // an EDMA_INT interrupt

Programming the EDMA - DSP/BIOS GUI (3)DSP/BIOS GUI Interface  With this method the configuration structure is created graphically and the setup code is generated automatically.

 Procedure: (1)Create a configuration using the EDMA configuration manager. Programming the EDMA - DSP/BIOS GUI

 Procedure: (2)Right click and select “ Properties ”, see the figure below, and then select “ Advanced ” and fill all parameters as shown below.

Programming the EDMA - DSP/BIOS GUI  Procedure: (3)If you are using symbolic parameters such as “ in_data ” you need to declare it in the “ CSL Extern Declaration ”, see below figure.

Programming the EDMA - DSP/BIOS GUI  Procedure: (4)A file is then generated that contains the configuration code. The file generated for this example is shown on the next slide.

Programming the EDMA - DSP/BIOS GUI /* Do *not* directly modify this file. It was */ /* generated by the Configuration Tool; any */ /* changes risk being overwritten. */ /* INPUT edma_inout_csl.cdb */ /* Include Header File */ #include "edma_inout_cslcfg.h" extern far Uint16 McBSP0_DRR; extern far Uint16 in_data[]; extern far Uint16 BUFF_SZ; /* Config Structures */ EDMA_Config cfgEdmaPing = { 0x28720002, /* Option */ 0x28720002, /* Option */ 0x018C0000, /* Source Address - Numeric */ 0x018C0000, /* Source Address - Numeric */ 0x00000002, /* Transfer Counter */ 0x00000002, /* Transfer Counter */ (Uint32) in_data, /* Destination Address - Symbolic */ (Uint32) in_data, /* Destination Address - Symbolic */ 0x00000004, /* Transfer Index */ 0x00000004, /* Transfer Index */ 0x000001B0 /* Element Count Reload and Link Address */ 0x000001B0 /* Element Count Reload and Link Address */}; /* Handles */ /* * ======== CSL_cfgInit() ======== * ======== CSL_cfgInit() ======== */ */ void CSL_cfgInit() {}

Outline Chip Support Library (CSL) Programming EDMA with CSL  CSL’s _FMK macro ( field make )  Source Insight

CSL’s _FMK macro ( field make ) TCC 1916 0011 gTCC=3 << 16 EDMA Options Register PeripheralRegisterFieldValue EDMA_FMK(OPT, TCC, gTCC) = 0x00030000

CSL’s _FMK macro ( field make )  Before you can ‘or’ gTCC into the TCC bit field, it must be shifted left by 16 bits (to make it line up).  While this is easy to write in C, you must know that the TCC field is 4-bits wide from bits 19-16.  Worse yet, everyone who maintains this code must also know this (or they’ll have to look it up).  _FMK solves this for you. It creates a 32-bit mask value for you. You need only recall the symbol names: TCC 1916 0011 gTCC=3 << 16 EDMA Options Register = 0x00030000 PeripheralRegisterFieldValue EDMA_FMK(OPT, TCC, gTCC)

Outline Chip Support Library (CSL) Programming EDMA with CSL CSL’s _FMK macro ( field make )  Source Insight

Source Insight (1)

Source Insight (2)

Outline Chip Support Library (CSL) Programming EDMA with CSL CSL’s _FMK macro ( field make ) Source Insight

Using DSP/BIOS

Part 1 - Introduction

Learning Objectives  Introduce DSP/BIOS and its components.  Introduce the software tools for managing DSP/BIOS components and objects.  Run some examples.

DSP/BIOS  The DSP/BIOS is an operating system that can provide:  A graphical interface for static system setup.  Real-time scheduling.  Real-time analysis (RTA).  Real-time data exchange (RTDX).

DSP/BIOS Components  The user writes code (‘C’/assembly) using the DSP/BIOS library.  The user can use the configuration tools to setup the system.  All the files generated constitute a project.

DSP/BIOS Components  The project is then compiled, assembled and linked by the code generation tools in order to generate an executable file (*.out).  There are also some DSP/BIOS plug-ins that can be used, for instance, as program test while the target is running.

DSP/BIOS Components  Code composer simulator/debugger and the host emulator support are also part of the code composer studio.  The host and target communicate through the JTAG (Joint Test Action Group) connection (ssya002c.pdf).ssya002c.pdf

Graphical Interface for Static System Setup  Static system setup is performed using the DSP/BIOS GUI configuration tool.  The configuration tool has an interface similar to windows explorer.  It lets you:  Specify a wide range of parameters used by the DSP/BIOS real-time library.  Create run-time objects that are used by the target application’s DSP/BIOS API calls. Note: API: Application Programming Interface

Graphical Interface for Static System Setup  The DSP/BIOS main objects are: (1)Hardware interrupts (HWI). (2)Software interrupts (SWI). (3)Tasks (TSK, IDL). (4)Data and I/O streams (RTDX, SIO, PIP, HST). (5)Synchronisation and Communication (SEM, MBX, LCK). (6)Timing (PRD, CLK). (7)Logging and statistics (LOG, STS, TRC).

Graphical Interface for Static System Setup  Files used to create the DSP/BIOS program:  The abbreviation 62 is used for the C6000 processors. Programs generated by the user Programs/Files generated by the configuration manager

Part 2 - Real Time Scheduling

Learning Objectives  What is a real-time scheduler?  Why do we need a real-time scheduler?  DSP/BIOS Thread Types.  Example.

Real-time scheduling  Before embarking into real-time scheduling let us first state the problem: main () { for (;;); } ISR1() { algorithm1(); } ISR2() { algorithm2(); }  Once ISR1 or 2 is called, algorithm 1 or 2 runs to completion. Can this cause a problem?

Real-time scheduling  Before embarking into real-time scheduling let us first state the problem: main () { for (;;); } ISR1() { algorithm1(); } ISR2() { algorithm2(); }  Once ISR1 or ISR2 is called, algorithm 1 or 2 runs to completion. Can this cause a problem? There is no guarantee of meeting the real-time deadlines because: (1)The algorithms can run at different rates. (2)One algorithm can overshadow the other. (3)The timing can be non- deterministic. etc.

Real-time scheduling  The answer depends on the application.  If we want to process two algorithms in real-time then we have to answer the following questions:  Are ISR1 and ISR2 synchronised? If yes, then we can use only an ISR that processes both algorithms (assuming that we have enough processing power to complete algorithm 1 and 2 on time).  What happens if the algorithms are not synchronised?  Which algorithm has a higher priority?  Can the algorithm of lower priority be preempted (stopped)?

Real-time scheduling  Example: Simple application.  System description:  Algorithm 1 and 2 are not synchronised.  Assume algorithm 1 has the highest priority.  Algorithm 2 can be pended. Algorithm 1 Algorithm 2 CPU processing Algorithm 1 CPU processing Algorithm 2 ! MISSED!  Remember: there is only one CPU and therefore only one algorithm can be processed at a time.

Real-time scheduling  Example: Simple application.  Solution 1: Algorithm decomposition:  The algorithm can be decomposed into sub- functions:  When the CPU is not processing algorithm1 it can process one of the sub-functions (to completion) as shown: algorithm2 ();function1(); function2(); function3(); Algorithm 1 Algorithm 2 function1function2function3

Real-time scheduling  Example: Simple application.  Problems with this solution:  Difficult to write (as timing is critical).  Difficult to change (what happens if algorithm is modified or another algorithm is added).

Real-time scheduling  Example: Simple application.  Solution 2: Using an operating system Advantages:  Easy to write (algorithms are written independently).  Easy to maintain or change (operating system takes care of the scheduling).  Enables fast time to market.  Which operating system? Depends on:  The processor being used.  The DSP platform (single/multi processors).

Real-time scheduling: DSP/BIOS  For all TI DSPs there is a DSP/BIOS operating system which includes:  Small sized real-time library.  An API for using the library services.  Easy-to-use configuration tools.  Real-time analysis programs.  DSP/BIOS scheduling solution provides:  Fixed-priority preemptive scheduler.  Multiple thread types.

Real-time scheduling: Terminology No preemption: Resources cannot be preempted; which means that the only way of releasing a resource is by the process of holding it. Object: Term for data and code structures provided by DSP/BIOS, e.g. an event, task, semaphore. Pend: Wait for an event Resource preemption: Release of a resource. Post: Signal an event, e.g. post a software interrupt, that is make a software interrupt ready. Preemption: A higher priority function (or thread) interrupts other functions (or threads) of lower priority. Priority scheduling: Priority scheduling can be either preemptive or non- preemptive. A preemptive priority scheduling algorithm will preempt (release) the CPU if another process of higher priority arrives. Process: A task or thread of execution. Scheduler: System software to manage the execution of threads. Scheduling: The planning used to share a resource. Semaphore: Synchronisation system object that enables tasks to synchronise their activities. Thread: An independent function.

DSP/BIOS Thread Types Priority HWI Hardware Interrupts  HWI priorities set by hardware One ISR per interrupt. HWI triggered by hardware interrupt. IDL runs as the background thread. What causes a SWI or TSK to run? SWI Software Interrupts  14 SWI priority levels Multiple SWIs at each level. TSK Tasks  15 TSK priority levels Multiple TSKs at each level. IDL Background  Multiple IDL functions Continuous loop.

Triggering SWI or TSK SWI cannot pend. SWI always returns from function. SWI start end SWI_post “run to completion” TSK only returns when no longer needed, otherwise normally an infinite loop. TSK SEM_pend start end block SEM_post

Considerations in Selecting Thread Types  Thread latency and data rates.  Multi-tiered response to interrupts:  HWI is fast (for sample-by-sample response time).  SWI is slower (triggered to process frame).  Priority of thread.  Stack needs:  O.K. to share system stack? then use SWI.  Need private stack? then use TSK.  Synchronization and communication methods:  SWI and TSK have different methods.  User preference or ease-of-use.

Thread Preemption Example HWI SWI 2 SWI 1 IDL main() TSK 2 TSK 1 interrupt pend sem2 return interrupt pend sem2 pend sem1 interrupt return post swi1 return post swi2 return post sem2 return post swi2 return post sem1 post sem2 return pend sem2 pend sem1 Events over time

Part 3 - Real Time Analysis Tools

Learning Objectives  Introduction to the analysis tools.  Using the LOG module.  Using the STS module.  Defining DSP/BIOS objects using the configuration tools.  Example.

Introduction  Traditionally analysis was performed by halting the processor and examining variables or memory.  This traditional method is invasive and does not represent the reality of real-time issues.  Real-time analysis is the analysis of data acquired during real-time operation of a system without having to stop or interfere with the target.  The API’s and Plug-ins provided with DSP/BIOS enable the programmer to monitor data while the target is running.

Introduction  So how can data be monitored without stopping the target?  Target-host communications is performed in the background (IDL) thread (e.g. the CPU is performing NOPs or waiting for an interrupt).  Data formatting is done by the host and therefore releases the CPU to perform useful tasks.

DSP/BIOS - API Modules Instrumentation/Real-Time Analysis LOG Message Log manger STS Statistics accumulator manager TRC Trace manager RTDX Real-Time Data Exchange manager Thread Types HWI Hardware interrupt manager SWI Software interrupt manager TSK Multitasking manager IDL Idle function & processing loop manager Clock and Periodic Functions CLK System clock manager PRD Periodic function manger Comm/Synch between threads SEM Semaphores manager MBX Mailboxes manager LCK Resource lock manager Input/Output PIP Data pipe manager HST Host input/output manager SIO Stream I/O manager DEV Device driver interface Memory and Low-level Primitives MEM Memory manager SYS System services manager QUE Queue manager ATM Atomic functions GBL Global setting manager

LOG Module  The LOG module contains functions that can be used to capture events in Real-Time while the target program is running.  Functions in LOG module: (1)LOG_disable( ):Disable the system log (2)LOG_enable( ):Enable the system log (3)LOG_error( ):Write a user error event to the system log (4)LOG_event( ):Append unformatted message to a message log (5)LOG_message( ):Write a user message to the system log (6)LOG_printf( ):Append a formatted message to a message log (7)LOG_reset( ):Reset the system log

Moving from “printf” to the faster “LOG_printf”  How many cycles does the printf() function require? > 34000

Moving from “printf” to the faster “LOG_printf” (1)Include the following headers in the C file: /* #include NOT required */ #include /* this is required by all DSP/BIOS modules */ #include /* this is required by the LOG module */ (2)Include the following external reference to the DSP/BIOS object in the C code: extern far LOG_Obj fastprint; /*fastprint is a user chosen name */

Moving from “printf” to the faster “LOG_printf” (3) Create a LOG object using the configuration tool: (a)Open the cdb file, select instrumentation and open the “LOG - Event Log Manager”. (b)Create a new object, call it “fastprint” and change its properties as shown below:

Moving from “printf” to the faster “LOG_printf” (4) Use the following code when using the LOG_printf function: /* #include NOT required */ #include /* this is required by all DSP/BIOS modules */ #include /* this is required by the LOG module */ extern far LOG_Obj fastprint; void algorithm_1 (void) { LOG_printf (&fastprint, “Algorithm 1 is running\n”); }

Moving from “printf” to the faster “LOG_printf” (5) To visualise the output of the fastprint log you must open the Message Log window, see below:

STS Module  The STS module manages objects called statistics accumulators.  Each STS object accumulates the following information:  Count:The number of values  Total:The sum of count values  Maximum:The longest value encountered  Functions in the STS Module: (1)STS_add( ):Update statistics using provided value (2)STS_delta( ):Update statistics using the difference between the provided value and the set point (3)STS_reset( ):Reset the values stored in the STS object (4)STS_set( ):Save a setpoint value

Using the STS Module (1)Include the following headers in the C file: /* #include NOT required */ #include /* this is required by all DSP/BIOS modules */ /* #include : Created by the tools */ (2)Create an object with the configuration tool: (a)Open the cdb file, select “Instrumentation” and open the “STS - Statistics Object Manager”. (b)Create a new object and call it “mystsObj”.

Using the STS Module (3)You can use the following code to benchmark the printf function: #include /* Needed for the printf function */ #include /* this is required by all DSP/BIOS modules */ #include extern far STS_Obj mystsObj; void algorithm_1 (void) { STS_set (&mystsObj, CLK_gethtime()); printf (“Algorithm 1 is running\n”); STS_delta (&mystsObj, CLK_gethtime());}

Moving from “printf” to the faster “LOG_printf” (4) To visualise the statistics, open the statistics window as shown below: (5)Exercise: Compare the number of cycles the printf and LOG_printf take.

Low Instrumentation Overhead LOG, STS and TRC module operations are very fast and execute in constant time, as shown in the following list:  LOG_printf and LOG_event: approx 32 cycles  STS_add:approx 18 cycles  STS_delta:approx 21 cycles  TRC_enable and TRC disable:approx 6 cycles Each STS object uses only four words of data memory. This means that the host transfers only four words to upload data from a statistics object.

Profiler

Outline  Benchmark Code Performance  Thinking About the Result

Benchmark Code Performance (1)

Outline Benchmark Code Performance  Thinking About the Result

Thinking About the Result  How May CPU Cycles Does the Function Cost?  How May MMAC Can C64x Core Do?  Bad Performance?  Was the Method Right for Benchmark?  How to Solve It?

DSP Getting Started Simon Sun 孙巍

Similar presentations

Presentation on theme: "DSP Getting Started Simon Sun 孙巍"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

DSP Getting Started Simon Sun 孙巍

Similar presentations

Presentation on theme: "DSP Getting Started Simon Sun 孙巍"— Presentation transcript:

Similar presentations

About project

Feedback