Target Support Package 4.0
Deploy generated code onto embedded processors, microcontrollers, and DSPs
Target Support Package lets you deploy code generated from MathWorks products for real-time execution on embedded microprocessors, microcontrollers, and DSPs. Using Target Support Package, you can integrate peripheral devices and real-time operating systems with algorithms created using Simulink models, Stateflow charts, and the Embedded MATLAB language subset without writing low-level drivers and run-time code. The resulting executable can be deployed onto embedded hardware for on-target rapid prototyping, real-time performance analysis, and field production.

Key Features

Support for generating executables that include algorithm, device-driver, and scheduler code Target-specific code and blocks for analog I/O, digital I/O, pulse-width modulation, waveform measurement, serial communication, CAN, and other peripherals Multitasking scheduling using synchronous and asynchronous tasks, task preemption, and temporary task overruns Interactive parameter tuning and monitoring of real-time applications using Simulink external mode Specialized block libraries for Ethernet host and target communication Optimized assembly code and blocks for Texas Instruments signal processing, IQMath, and Digital Motor Control libraries Support for the following processor families: Texas Instruments C2000 and C6000, Analog Devices Blackfin, Freescale MPC5xx, Infineon C166, and STMicroelectronics ST10
Combining Simulink, Real-Time Workshop, Embedded IDE Link, and Target Support Package to provide an integrated environment for designing, simulating, implementing, and verifying embedded systems using processors from different vendors.
Working with Target Support Package Target Support Package is part of a complete design flow for prototyping and implementing a wide variety of embedded applications. You construct system models and real-time algorithms using Simulink blocks and add-on blockset libraries. The model can be developed with fixed- or floating-point data. With Target Support Package,
you insert blocks for optimized functions and board peripherals based on your embedded hardware. You can then use Target Support Package along with Real-Time Workshop, Embedded IDE Link, and third-party development tools to automate the process of generating algorithm code and compiling, linking, downloading, and executing it on your hardware board. Third-Party Tool Integration Target Support Package is tightly integrated with third-party tools through Embedded IDE Link. As a result, it is easy to automatically build, download, and run your applications on hardware and to launch the debugger for debugging and verifying prototyping or production code. Hardware Configuration Target Support Package includes graphical user interfaces that simplify hardware configuration. You can control target environment parameters and build options in Simulink. On supported boards, you can access I/O, peripherals, and other utilities via Simulink dialog boxes. This access streamlines the analysis and enables transitions between simulation and real-time deployment.
Target Preferences library, used to preconfigure a model targeting either standard prototyping or custom boards that contain C2000 processors.
Real-Time Deployment Target Support Package lets you add device driver blocks to your model, generate and build real-time code, and download the code to hardware. You can also integrate your model with hand-coded I/O drivers. Target Support Package can then execute the code using on-target rapid prototyping to evaluate algorithm performance on production hardware. You can also deploy and execute the code in a production environment.
Application Download Target Support Package lets you download the code onto the hardware using third-party software tools. Depending on your hardware, the selected tool is launched automatically at the end of the build process. The generated executable is then downloaded and executed. On some hardware, you can also use JTAG, CAN, or serial communication to download the executable to flash or RAM memory and automatically start the execution in real time. Alternatively, you can launch a third-party debugger to execute code on an instruction set simulator (ISS) running on the host PC. Schedulers and Real-Time Operating System Target Support Package includes a variety of single-tasking, multitasking, synchronous, and asynchronous schedulers. A preemptive, multitasking scheduler supports the execution of multirate systems. You can configure this scheduler to enable temporary overruns, maximizing processor utilization when a task takes longer than normal to execute. An asynchronous scheduler lets you create multiple tasks, tie each task to a specific hardware interrupt, and use it to trigger the execution of a task. You can prioritize each task, enabling higher priority tasks to interrupt lower priority tasks at any time. This approach improves response times in your embedded application. It also lets you implement algorithms that could not be implemented with traditional periodic timer interrupts. You can assign background tasks to run while the system is idle without the involvement of a hardware interrupt, enabling you to control the execution schedule for noncritical tasks. All nonreserved CPU and PIE interrupts are supported by the asynchronous scheduler. Logical interrupt priorities are assigned to each interrupt-driven task that you specify. The generated code automatically incorporates these priorities. On selected Texas Instruments hardware, you can design and implement advanced embedded systems that use the DSP/BIOS operating system. The Hardware Interrupt block lets you create an interrupt service routine (ISR) that executes a subsystem or a task that you define using the Task block. Real-Time Parameter Tuning and Signal Logging Using Simulink external mode, you can log signals and tune parameters in your algorithm running on the hardware in real time without a calibration tool. As a result, you can execute your algorithm using different parameters without recompiling and downloading the code onto the hardware. Depending on your hardware, an Ethernet, CAN, or serial connection is required. You may also use a third-party calibration tool such as CANape from Vector Cantech, which requires the use of a CAN connection between host and target.

C6000 Target Communication, Scheduling, and DSP/BIOS libraries (clockwise from left). These libraries help you design and implement UDP or Ethernet communication, and schedule code segments to be executed by interrupt service routines in response to hardware interrupts or as tasks enabled by external triggers on a Texas Instruments C6000 processor.
Device Drivers for Simulation and Code Generation The I/O device driver library in Target Support Package includes device driver blocks for on-board peripherals such as digital I/O, pulse-width modulation (PWM), waveform measurement, CAN communication, serial communication, analog output, and analog-to-digital conversion modules. Device drivers for vendor-specific peripherals, such as quadrature decode, programmable time accumulator, MIOS, QADC, ePWM, TPU, TouCAN, eCAN, and eQEP, are also available. If a specific driver is not available, Target Support Package includes information on integrating your drivers with the Simulink model. When you generate code, device drivers are automatically integrated with your algorithm in the resulting code. CAN Communication Target Support Package offers an extensive range of capabilities to support the development of systems with built-in CAN communication. Depending on the peripherals available on the hardware, it can send and receive standard or extended CAN messages using on-board CAN modules. You can specify a number of execution modes, including FIFO and priority-based message transmission. Blocks for decoding and formatting CAN messages enable you to insert multiple signals into a single CAN message to increase bandwidth. The reverse operation, message unpacking, extracts multiple signals from a single incoming CAN message. The CAN Calibration Protocol (CCP) block supports a subset of CCP and enables the use of Simulink external mode or a third-party calibration tool.
CAN driver library blocks for host PC CAN hardware or TouCAN modules on the MPC5xx in Target Support Package.
Ethernet Communication You can design and implement systems that involve Ethernet communicationsfrom host to target, target to host, or target to networkusing send and receive blocks. You can assemble and disassemble Ethernet data packets and perform byte manipulation. Video and Audio Drivers You can design and implement video processing systems that involve live, real-time video inputs and outputs. You can capture analog video data from video-input ports and convert it to supported digital formats. Drivers are provided to output digital video data as an analog signal from a video-out port. You can add text and other graphics to the output video stream.

For certain audio peripherals in starter kits and evaluation boards, blocks that encapsulate device drivers are provided to directly read and write analog data between the peripheral and the algorithm running on the processor. These blocks enable turnkey prototyping of your algorithms. Code Optimization You can manually optimize the generated code in the third-party software environment. Alternatively, for computationally intensive real-time applications that demand optimal execution speed and a high degree of accuracy, you can optimize the code by replacing corresponding portions of your Simulink diagram with blocks from vendor-specific libraries that call optimized assembly routines. These blocks simulate bit-true in Simulink. Target Support Package produces function calls to assembler implementations of these blocks in the generated code, which increases the efficiency and performance of critical portions of your design as compared with equivalent ANSI C code. Target Function Library Together with Embedded IDE Link, you can also use Target Function Libraries to obtain target optimized code. With Target Function Libraries, the ANSI C code generated for certain operators and functions is replaced by prebuilt target-optimized code. You do not have to add or replace blocks as described above because Target Function Libraries work directly with standard Simulink blocks, Stateflow charts, and Embedded MATLAB functions. Supported Hardware Devices and Vendors Target Support Package supports processors from multiple vendors, including Analog Devices, Freescale, Infineon, STMicroelectronics, and Texas Instruments. Target Support Package is compatible with third-party hardware boards from vendors such as Axiom, PHYTEC, and Spectrum Digital. You can find more information at the supported third-party board Web page.

Resources

Product Details, Demos, and System Requirements www.mathworks.com/products/target-package Trial Software www.mathworks.com/trialrequest Sales www.mathworks.com/contactsales Technical Support www.mathworks.com/support Online User Community www.mathworks.com/matlabcentral Training Services www.mathworks.com/training Third-Party Products and Services www.mathworks.com/connections Worldwide Contacts www.mathworks.com/contact
2009 The MathWorks, Inc. MATLAB and Simulink are registered trademarks of The MathWorks, Inc. See www.mathworks.com/trademarks for a list of additional trademarks. Other product or brand names may be trademarks or registered trademarks of their respective holders.

D. Richard Brown III

Associate Professor
Worcester Polytechnic Institute
Electrical and Computer Engineering Department

drb@ece.wpi.edu

October 19-20, 2009

Day 2 handouts

Matlabs Link for Code Composer Studio (Now Called Matlabs Embedded IDE Link)
Yesterday we used Matlab to design an FIR lter.
The Link for Code Composer Studio (now called Matlabs Embedded IDE Link) toolbox allows even more direct Matlab-CCS integration.

Page 2 of 57

Matlabs Link for CCS: Compatibility Considerations
To use Matlabs link for CCS, the Matlab and CCS versions must be compatible:

Matlab Version

R2007a

R2007b-present

Compatible CCS version
Code Composer Studio is now available in version 4.0.
Upgrade information for CCS v3.3 can be found here: http://focus.ti.com/docs/toolsw/folders/print/ccstudio.html

Page 3 of 57

Matlabs Link for CCS: Basics (R2007a / CCS v3.1)
% make sure DSK is connected to the computer via USB % and is on before proceeding % display a list of available DSP boards and processors ccsboardinfo % create Matlab/CCS link for board=0, processor=0 cc = ccsdsp(boardnum,0,procnum,0);
% get information about the status and capabilities of the link display(cc) info(cc) isrunning(cc) isrtdxcapable(cc) getproc(cc) % make CCS visible visible(cc,1)

Page 4 of 57

Opening, building, loading, and running a project
% open existing project cd(cc,c:\myproject\helloworld); open(cc,helloworld.pjt); % build the project (returns a value of 1 if successful) build(cc,all) % load the binary file to the DSK load(cc,Debug\helloworld.out) % run the code on the DSK and check to see if it is running restart(cc) run(cc) isrunning(cc) % halt execution on the DSK and check to see if it stopped halt(cc) isrunning(cc)

Page 5 of 57

Reading/Writing DSK Variables

Uint32 temp;

short foo[100];
(variables declared in CCS)
% Important: Do not attempt to read/write data from/to the DSK while it is running. % Insert one or more breakpoints in the code, run to the breakpoint, % perform the read, then resume execution % confirm the DSK is not running isrunning(cc) % create an object for the DSK variables temp and foo (can be global or local) tempobj = createobj(cc,temp); fooobj = createobj(cc,foo); % read/write examples x = read(tempobj) write(tempobj,1234) y = read(cc,fooobj) z = read(cc,fooobj,10) write(fooobj,4,999)

% % % % %

DSK temp -> Matlab x 1234 -> DSK temp DSK foo -> Matlab y (whole array) DSK foo -> Matlab y (10th element) 999 -> DSK foo (4th element)

Page 6 of 57

Useful things that you can do with Matlabs Link for CCS
Rapid lter design: Halt execution on the DSK (halt), write new lter coefcients (write), resume execution (restart/run), and test your lter without rebuilding the project.
Use specic test signals: Generate a specic test signal in Matlab, overwrite the codec samples (write) with your test signal samples, run the processing code on the DSK, observe the output.
Rapid data analysis/graphing: Read the contents of the a lter output (read) to Matlab, analyze the spectrum or other properties, generate plots.

Page 7 of 57

Tip: Making Interesting Test Signals in Matlab
Example: In-Phase and Quadrature Sinusoids

>> fs=44100;

% set up sampling frequency

>> t=0:1/fs:5;

% time vector (5 seconds long)
>> x=[sin(2*pi*1000*t) cos(2*pi*1000*t)]; % left = sin, right = cos

>> soundsc(x,fs);

% play sound through sound card
Another example: white noise (in stereo)

>> L=length(t);

>> x=[randn(L,1) randn(L,1)];
These signals are all generated as double precision oats but can be cast to xed point or integer formats if necessary.
You can save your signals to.wav les with Matlabs wavwrite function. These.wav les can be burned to CD and played with conventional stereo equipment.

Page 8 of 57

Proling Your Code and Making it More Efcient
to estimate the execution time of your code.
How to use the optimizing compiler to produce more efcient code.
How data types and memory usage affect the efciency of your code.

Page 9 of 57

How to estimate code execution time when connected to the DSK
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Start CCS with the C6713 DSK connected
Debug -> Connect (or alt+C)
Open project, build it, and load.out le to the DSK
Open the source le you wish to prole
Set two breakpoints for the start/end of the code range you wish to prole
Prole -> Clock -> Enable
Prole -> Clock -> View
Run to the rst breakpoint

Reset the clock

Run to the second breakpoint
Clock will show raw number of execution cycles between breakpoints.
Tip:You can save your breakpoints, probe points, graphs, and watch windows with
File -> Workspace -> Save Workspace As

Page 10 of 57

Another method for estimating code execution time (part 1 of 3)
Repeat steps 1-4 previous method.
5. Clear any breakpoints in your code

6. Prole -> Setup

7. Click on Custom tab

8. Select Cycles

9. Click on clock (enable proling)

Page 11 of 57

Another method for estimating code execution time (part 2 of 3)

10. 11.

Select Ranges tab
Highlight code you want to prole and drag into ranges window (hint: you can drag whole functions into this window)
Repeat for other ranges if desired

Page 12 of 57

Another method for estimating code execution time (part 3 of 3)

Prole -> Viewer

14. Run (let it run for a minute or more)

15. Halt

16. Observe proling results in Prole Viewer window
Hint: edit the columns to see averages

Page 13 of 57

What does it mean?

Access

count is the number of times that CCS proled the function
Note that the function was probably called more
than 49 times. CCS only timed it 49 times.

Inclusive

average is the average number of cycles needed to run the function including any calls to subroutines
Exclusive average is the average number of cycles needed to run the function excluding any calls to subroutines

Page 14 of 57

Optimizing Compiler

Page 15 of 57

Proling results after compiler optimization
In this example, we get a 3x-4x improvement with Speed Most Critical and File (-o3) optimization
Optimization gains can be much larger, e.g. 20x

Page 16 of 57

Limitations of hardware proling
Breakpoint/clock proling method may not work with compiler-optimized code
Prole -> View method is known to be somewhat inaccurate when connected to real hardware (see proling limitations in CCS help)
Accuracy is better when only one or two ranges are

proled

Best accuracy is achieved by running a simulator

Page 17 of 57

Running CCS with a Cycle-Accurate Simulator
Limitations include not being able to use any DSK functionality (AIC23 codec, etc.)

Page 18 of 57

Other factors affecting code efciency

Memory

C6713 has 256kB internal SRAM
Up to 64kB of this SRAM can be congured as shared L2 cache
DSK provides additional 16MB external RAM (SDRAM)
Code location (.text in linker command le)
internal SRAM memory (fast)
external SDRAM memory (typically 2-4x slower, depends on cache

conguration)

Data location (.data in linker command le)
external SDRAM memory (slower, depends on datatypes and cache

Data types

Slowest execution is double-precision oating point
Fastest execution is xed point, e.g. short

Page 19 of 57

TMS320C6713 DSK Memory Map

Page 20 of 57

Linker Command File Example
MEMORY { vecs: IRAM: CE0: } SECTIONS {.vectors.cinit.text.stack.bss.const.data.far.switch.sysmem.tables.cio } o = 00000000h o = 00000200h o = 80000000h l = 00000200h l = 0002FE00h l = 01000000h
> > > > > > > > > > > >
vecs IRAM IRAM IRAM IRAM IRAM IRAM IRAM IRAM IRAM IRAM IRAM

Code goes here

Data goes here
Addresses 00000000-0002FFFF correspond to the lowest 192kB of internal memory (SRAM) and are labeled IRAM.

External memory is mapped to address range 80000000 80FFFFFF. This is 16MB and is labeled CEO.
Both code and data are placed in the C6713 internal SRAM in this example. Interrupt vectors are also in SRAM.

Page 21 of 57

Page 22 of 57

Some Things to Try

Try proling parts of your FIR lter code from Day 1 without optimization. Try both proling methods.
Rebuild your project under various optimization levels and try various settings from size most critical to speed most critical.
Compare prole results for no optimization and various levels of optimization.
Change the data types in your FIR lter code and rebuild (with and without optimization) to see the effect on performance.
Try moving the data and/or program to internal/external memory and proling (you will need to modify the linker command le to do this)
Contest: Who can make the most efcient 8th order bandpass lter (that works)?

Page 23 of 57

Assembly Language Programming on the TMS320C6713
To achieve the best possible performance, sometimes you have to take matters into your own hands.

Three options:

1. Linear assembly (.sa)
Compromise between effort and efciency
Typically more efcient than C
Assembler takes care of details like assigning functional units, registers, and parallelizing instructions

asm(assembly code)

Full control of assigning functional units, registers, parallelization, and pipeline optimization
2. ASM statement in C code (.c)
3. C-callable assembly function (.asm)

Page 24 of 57

C-Callable Assembly Language Functions

Basic concepts:

Arguments are passed in via registers A4, B4, A6, B6,. in
that order. All registers are 32-bit.
Result returned in A4 also.
Return address of calling code (program counter) is in B3. Dont overwrite B3!

Naming conventions:

In C code:

In ASM code:

_label (note the leading underbar)
Accessing global variables in ASM:

.ref _variablename

A function prototype must be included in your C code.

Page 25 of 57

Skeleton C-Callable ASM Function

; header comments

; passed in parameters in registers A4, B4, A6,. in that order

.def _myfunc

; allow calls from external

ACONSTANT

.equ 100

; declare constants

.ref _aglobalvariable
; refer to a global variable

_myfunc:

; instructions go here
; return (branch to addr B3)
; function output will be in A4

; pipeline ush

Page 26 of 57
Example C-Callable Assembly Language Program int rcasmfunc(short x[], short h[], int N)

Page 27 of 57

TMS320C67x Block Diagram
One instruction is 32 bits. Program bus is 256 bits wide.
Can execute up to 8 instructions per clock cycle (225MHz->4.4ns clock cycle).
8 independent functional units:

- 2 multipliers

- 6 ALUs
Code is efcient if all 8 functional units are always busy.
Register les each have 16 general purpose registers, each 32-bits wide (A0-A15, B0-B15).
Data paths are each 64 bits wide.

Page 28 of 57

C6713 Functional Units
Two data paths (A & B)

Data path A

Multiply operations (.M1)
Logical and arithmetic operations (.L1)
Branch, bit manipulation, and arithmetic operations (.S1)
Loading/storing and arithmetic operations (.D1)
Multiply operations (.M2)
Logical and arithmetic operations (.L2)
Branch, bit manipulation, and arithmetic operations (.S2)
Loading/storing and arithmetic operations (.D2)

Data path B

All data (not program) transfers go through.D1 and.D2

Page 29 of 57

Fetch & Execute Packets
C6713 fetches 8 instructions at a time (256 bits)
Denition: Fetch packet is a group of 8 instructions fetched at once.
Coincidentally, C6713 has 8 functional units.
Ideally, all 8 instructions would be executed in parallel.
Often this isnt possible, e.g.:
3 multiplies (only two.M functional units)
Results of instruction 3 needed by instruction 4 (must wait for 3 to

complete)

Page 30 of 57

Execute Packets

Denition: Execute Packet is a group of (8 or less) consecutive instructions in one fetch packet that can be executed in parallel.

fetch packet

execute packet 1

execute packet 2

execute packet 3
C compiler provides a ag to indicate which instructions should be run in parallel.
You have to do this manually in Assembly using the double-pipe symbol ||. See Chapter 3 of the Chassaing and Reay textbook.

Page 31 of 57

C6713 Instruction Pipeline Overview
All instructions ow through the following steps:
a) PG: Program address Generate
b) PS: Program address Send
c) PW: Program address ready Wait
d) PR: Program fetch packet Receive

2. Decode

a) DP: Instruction DisPatch
b) DC: Instruction DeCode

3. Execute

a) 10 phases labeled E1-E10
b) Fixed point processors have only 5 phases (E1-E5)

each step

= 1 clock cycle

Page 32 of 57

Pipelining: Ideal Operation

Remarks:

At clock cycle 11, the pipeline is full
There are no holes (bubbles) in the pipeline in this example

Page 33 of 57

Pipelining: Actual Operation
Fetch packet n has 3 execution packets
All subsequent fetch packets have 1 execution packet
Notice the holes/bubbles in the pipeline caused by lack of parallelization

Page 34 of 57

Execute Stage of C6713 Pipeline
C67x has 10 execute phases (oating point)
C62x/C64x have 5 execute phases (xed point)
Different types of instructions require different numbers of these phases to complete their execution
Anywhere between 1 and all 10 phases
Most instruction tie up their functional unit for only one phase (E1)

Page 35 of 57

Execution Stage Examples (1)
results available after E1 (zero delay slots)
Functional unit free after E1 (1 functional unit latency)

Page 36 of 57

Execution Stage Examples (2)

results available after

E4 (3 delay slots)
Functional unit free after E1
(1 functional unit latency)

Page 37 of 57

Execution Stage Examples (3)
Results available after E10 (9 delay slots)
Functional unit free after E4
(4 functional unit latency)

Page 38 of 57

Functional Latency & Delay Slots
Functional Latency: How long must we wait for the functional unit to be free?
Delay Slots: How long must we wait for the result?

General remarks:

Functional unit latency <= Delay slots
Strange results will occur in ASM code if you dont pay
attention to delay slots and functional unit latency
All problems can be resolved by waiting with NOPs
Efcient ASM code tries to keep functional units busy all of the time.

Efcient code is hard to write (and follow).

Page 39 of 57

Lunch Break
Workshop resumes at 1:30pm

Page 40 of 57

rewriting your FIR lter code as a Ccallable ASM function

Create a new ASM le

Call the ASM function from your main code
See Chassaing examples rcasm.pjt and

rcasmfast.pjt for ideas

Prole
your new FIR code and compare to the optimized compiler.

Page 41 of 57

Innite Impulse Response (IIR) Filters

Advantages:

Can achieve a desired frequency response with less
memory and computation than FIR lters

Disadvantages:

Can be unstable
Affected more by nite-precision math due to feedback
Input/output relationship:

Page 42 of 57

IIR Filtering - Stability

Transfer function:

Note that the lter is stable only if all of its poles (roots of the denominator) have magnitude less than 1.
Easy to check in Matlab: max(abs(roots(a)))
Quantization of coefcients (as and bs) will move the poles. A stable lter in innite precision may not be stable after coefcient quantization.
Numerator of H(z) does not affect stability.

Page 43 of 57

Creating IIR Filters

Design lter

Type: low pass, high pass, band pass, band stop,.

Filter order N

Desired frequency response

Matlab

2. 3. 4. 5.
Decide on a realization structure
Decide how coefcients will be quantized.
Compute quantized coefcients
Decide how everything else will be quantized (input samples, output samples, result of multiplies, result of additions)
Write code to realize lter
CCS Test lter and compare to theoretical expectations

Page 44 of 57

IIR Realization Structures
Many different IIR realization structures available (see options in Matlabs fdatool)
Structures can have different memory and computational

requirements

All structures give the same behavior when the math is innite precision
Structures can have very different behavior when the math is nite precision

Stability

Accuracy with respect to the desired response
Potential for overow/underow

Page 45 of 57

Direct Form I
Notation: 1/z = one sample delay

Page 46 of 57

Direct Form II
Note that DFII has fewer delay elements (less memory) than DFI. It has been proven that DFII has minimum number of delay elements.

Page 47 of 57

Direct Form II: Second Order Sections
Transfer function H(z) is factored into H1(z)H2(z)HK(z) where each factor Hk(z) has a quadratic denominator and numerator

Each quadratic factor is called a Second Order Section (SOS)
Each SOS is realized in DFII
The results from each SOS are then passed to the next SOS (cascade)

Page 48 of 57

popular realization structure
Low memory requirements (same as DFII)
Easy to check the stability of each SOS
Can write one DFII-SOS lter function and reuse it

for any length lter

Tends to be less sensitive to nite precision math than DFI or DFII. Why?
Dynamic range of coefcients in each SOS is smaller
Coefcient quantization only affects local poles/zeros

Page 49 of 57

Interpreting Matlabs Header Files for IIR Filters in DFII-SOS
Each row of the NUM/DEN arrays in the header le contains 3 coefcients.
The numerator (NUM) coefcients in each row, from left to right, are b[0], b[1], and b[2] in the usual notation.
The denominator (DEN) coefcients in each row, from left to right, are a[0], a [1], and a[2] in the usual notation.
Note that a[0] is always equal to 1 and that we don't use it in our calculations (refer to the IIR input/output equation).
The rows are processed from top to bottom. For each row:
compute u[n] using the denominator coefcients (and your scaled x[n] from the

prior row)

compute y[n] using the numerator coefcients.
Since you know that your lter always have 3 coefcients in this case, you should be able to write one SOS function that does this efciently.

Page 50 of 57

Determining How Coefcient Quantization Will Affect Your Filter

set quantization

parameters

Page 51 of 57

IIR Filtering Final Remarks
IIR lters are more sensitive to choice of realization structure and data types than FIR lters due to feedback

Memory requirements

Time required to compute lter output
Matlabs fdatool can be useful for examining the tradeoffs before writing code

Page 52 of 57

In fdatool, design an IIR lter with the following specs:

Bandstop

First passband 0-2500Hz, 0dB nominal gain, 0.5dB max deviation
First transition band 2500-3500Hz
Stop band 3500-10500Hz, -20dB minimum suppression
Second transition band 10500-12500Hz
Second passband 12500-22050Hz 0dB nominal gain, 0.5dB max deviation

Minimum lter order

Explore DFII with and without Second Order Sections
Try various coefcient quantizations including xed point
Implement your best lter in CCS
Compare actual performance to the theoretical predictions

Page 53 of 57

Other Interesting Applications of RealTime DSP
Fast Fourier Transform (FFT): Chapter 6

Example projects:

DFT, FFT256C, FFTSinetable, FFTr2, FFTr4, FFTr4_sim, fastconvo, fastconvo_sim, graphicEQ
Note that TI provides optimized FFT functions (search for cfftr2_dit, cfftr2_dif, cfftr4_dif)
Adaptive Filtering: Chapter 7
Adaptc, adaptnoise, adaptnoise_2IN, adaptIDFIR, adaptIDFIRw, adaptIDIIR, adaptpredict, adaptpredict_2IN,

Page 54 of 57

Workshop Day 2 Summary

What you learned today:

Some of the functions available in Matlabs Link for Code Composer Studio
How to prole code size and execution times.
How data types and memory usage affect code execution times.
How to reduce code size and execution time with CCSs optimizing compiler.
How assembly language can be integrated into your projects.
Basics of the TMS320C6713 architecture.
Fetch packets, execute packets, pipelining
Functional unit latency and delay slots
How to design and implement IIR lters on the C6713

Realization structures

Quantization considerations
Other applications for the C6713 DSK

Adaptive ltering

Page 55 of 57
Workshop Day 2 Reference Material
Matlabs Link for Code Composer Studio help (>> doc ccslink)
Chassaing textbook Chapters 3, 5-8

CCS Help system

SPRU509F.PDF CCS v3.1 IDE Getting Started Guide
C6713DSK.HLP C6713 DSK specic help material
SPRU198G.PDF TMS320C6000 Programmers Guide
SPRU189F.PDF TMS320C6000 CPU and Instruction Set Reference Guide
Matlab fdatool help (>> doc fdatool)
Other Matlab help (>> doc soundsc >> doc wavwrite)
Latest documentation available at http://www.ti.com/sc/docs/psheets/man_dsp.htm

Page 56 of 57

Additional Exploration
Explore some of Chassaings FFT and adaptive ltering projects in the myprojects directory
Explore some of the reference literature (especially the Chassaing text and the CCS help system)
Try a lab assignment in the ECE4703 real-time DSP course: http://spinlab.wpi.edu/courses/ece4703

Page 57 of 57