Dsp/bios

Chapter 4
DSP/BIOS
Chapter 4
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.
hapter 4, Slide 3 Dr. Nai

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).
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

 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).
For a complete list see: \Links\SPRU303.pdf (Page 1-5).

 How to create a configuration file:
 Open CCS and create a new project and name it “lab1.pjt”.
 Create a new configuration file by using a pre-built
template file:
File:New:DSP/BIOS Configuration

 Double click on the “dsk6711.cdb” icon and
the following configuration will appear:

 Now that you have selected the template, save it in your
current working directory, e.g: Code\Chapter4 -
DSP_BIOS\Lab1\lab1.cdb.
 Finally, add the “*.cdb” configuration file to the project.

 Files created by the configuration tools:
 Once the lab1.cdb file is modified, saved and added to the project, the configuration manager will create and
load the following files:
 lab1cfg.s62 Assembly file
 lab1cfg_c.c C file
 lab1cfg.h Header file for C
 lab1cfg.h62 Header file for assembly
 A file called “lab1cfg.cmd” is also created but must be loaded by the user.
Note: the user must add the *.cdb and *.cmd files to the project.

 Files used to create the DSP/BIOS
program:
 The abbreviation 62 is used for the C6000
processors.
Programs/Files generated by the

configuration manager
Programs generated by the user

Chapter 4
DSP/BIOS
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?
 Before embarking into real-time
scheduling let us first state the problem:
main ()
{ There is no guarantee of meeting
for (;;); the real-time deadlines because:
}
ISR1() (1) The algorithms can run at different
{
rates.
algorithm1(); (2) One algorithm can overshadow the
} other.
ISR2() (3) The timing can be non-deterministic.
{
etc.
algorithm2();
}
 Once ISR1 or ISR2 is called, algorithm 1 or 2

runs to completion. Can this cause a problem?
 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 pre-empted (stopped)?

 Example: Simple application.
 System description:
 Algorithm 1 and 2 are not synchronised.
 Assume algorithm 1 has the highest priority.
 Algorithm 2 can be pended.
CPU processing MISSED!

Algorithm 1
Algorithm 1
Algorithm 2
CPU processing Algorithm 2
 Remember: there is only one CPU and therefore

only one algorithm can be processed at a time.
 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
function1 function2 function3

 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).

 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
HWI  HWI priorities set by hardware
Hardware Interrupts One ISR per interrupt.
SWI  14 SWI priority levels
Priority
Software Interrupts Multiple SWIs at each level.

TSK  15 TSK priority levels
Tasks Multiple TSKs at each level.
IDL  Multiple IDL functions
Background Continuous loop.
HWI triggered by hardware interrupt.

IDL runs as the background thread.
What causes a SWI or TSK to run?
Triggering SWI or TSK
SWI_post SEM_post
SWI TSK
start
SEM_pend block
“run to
start
completion”
end end
SWI cannot pend. TSK only returns when no

SWI always returns longer needed, otherwise
from function. normally an infinite loop.
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
post post post post
return swi2 return sem2 return
swi1 swi2 return
HWI post post
return sem1 sem2
SWI 2 return
return
SWI 1 pend pend pend

sem2 sem2 sem2
interrupt
TSK 2 pend pend
sem1 sem1
TSK 1
interrupt interrupt
main()
return
IDL
interrupt
Events over time

Laboratory Exercise
 Laboratory objectives:
(1) Set the internal timer 1 to generate ticks at 8kHz.
(2) Set a hardware interrupt that is triggered by internal timer 1.
(3) Create a software interrupt that can be posted by the hardware interrupt.
(4) Create a task that can be posted by the hardware interrupt.
(5) Create a semaphore that can be used by the task functions.

(1) Setting Internal Timer 1
(1) Create a new project and call it “bios_lab.pjt”.
(2) Add the “dsk6711.cdb” file (see slide 10) and rename it
“bios_lab2.cdb”.
(3) Set a timer configuration by using the “Timer Configuration
Manager” and call it “timerCfg0” and set the properties:
The GUI interface will generate the “bios_labcfg.c”, see

\Links\bios_labcfg.pdf
(2) Setting the Hardware Interrupt
(1) Open the CDB file.
(2) Select the “HWI - Hardware Interrupt Service …”.
(3) Select HWI_INT15 and right

click to select properties.
Source = Timer_1
Function = _timerIsr

(2) Setting the Hardware Interrupt
(4) Write the Interrupt Service Routine in C.
void timerIsr (void)

{
/* Put your code here */
}

(3) Creating a Software Interrupt
(1) Open the cdb file and select the “SWI - Software Interrupt Manager”
and create a new software interrupt called “SWI_for_algorithm_1”.

(2) Change the properties of the “SWI_for_algorithm_1” to:

(3) Create a software interrupt function in C.
void algorithm_1 (void)

{
}

(4) Creating a Task
(1) Open the cdb file and select the “TSK - Task Manager”
and create a new task called “TaskOneTsk”.

(4) Creating a Task
(2) Change the properties to:

(4) Creating a Task
(3) Create a task function in C:
void ProcessTask (void)

{
/* Put your algorithm here */
}

(5) Creating a Semaphore
(1) Open the cdb file and select the “SEM - Semaphore Manager”
and create a new semaphore called “taskOneSem”.
(2) Change the properties of the “taskOneSem” to:

Posting Software Interrupts and Tasks
(1) Software Interrupts
The software interrupts can be posted simply by writing:
SWI_post (&SWI_for_algorithm_1);
(2) Tasks
The task can be removed from semaphore queue and put it on the ready queue:
SEM_post (&taskOneSem);

More on Tasks…
 A task can be pending where as Software Interrupts (SWI) run to completion.
 Tasks normally run in an infinite loop and within the loop the task tests for a semaphore.
 A task can preempt itself, e.g:

{
while (1)
{
SEM_pend (&taskOneSem, SYS_FOREVER);
/* Insert your code here */
}
}

Putting it all together…
void main (void)
{
/* Put all your setup code here */
return; /*DSP BIOS starts after the return */
}
/* Hardware Interrupt */
{
}
/*Software Interrupt */
{
}
/* Task */
{
while (1)
{
}
}
void main (void)
{
/* Put all your setup code here */
return; /*DSP BIOS starts after the return */
}
/* Hardware Interrupt */
{
}
/*Software Interrupt */
{
}
/* Task */
{
while (1)
{
}
}
See example located in:
…\ Chapter 04 - DSP BIOS\Bios_Lab2\bios_lab_2.pjt

Chapter 4
DSP/BIOS
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.
 For more details see Chapter 3 of the
DSP/BIOS Users Guide (
Links\SPRU303.pdf).

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

“LOG_printf”
(1) Include the following headers in the C file:
/* #include <stdio.h> NOT required */
#include <std.h> /* this is required by all DSP/BIOS modules */
#include <log.h> /* 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 */

“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:

“LOG_printf”
(4) Use the following code when using the LOG_printf function:

#include <log.h> /* this is required by the LOG module */
extern far LOG_Obj fastprint;

{
LOG_printf (&fastprint, “Algorithm 1 is running\n”);
}

“LOG_printf”
(5) To visualise the output of the fastprint log you must open the Message Log window, see below:
Note: The complete code can be found in: \Code\Chapter 04 - DSP

BIOS\Bios_Lab2\
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 <sts.h> : 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 <stdio.h> /* Needed for the printf function */

#include <sts.h>
#include <clk.h>
extern far STS_Obj mystsObj;

{
STS_set (&mystsObj, CLK_gethtime());
printf (“Algorithm 1 is running\n”);
STS_delta (&mystsObj, CLK_gethtime());
}

“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.
Note: The complete code can be found in: \Code\Chapter 04 - DSP

BIOS\Bios_Lab3\
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

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.

Chapter 4
DSP/BIOS
Part 4 - Real-Time Data Exchange
Learning Objectives
 Introduction.
 Example: Send data from the target
(DSK6711) to the host (PC).

RTDX: Real-Time Data Exchange
TMS320 DSP PC
Display
USER CODE
EMU H/W
IEEE  User
RTDX
JTAG
CCS  TI
 3rd Party
 MS
Third COM
Party
Display
 RTDX enables non-obtrusive two-way communication between the

host PC and the DSP (during IDL).
 Since it runs in IDL (by default), it runs lower priority than your
real-time code.
 RTDX is used by DSP/BIOS RTA, but it is also available directly
to DSP programmer (useful for testing or if end-equipment is PC
resident).
 Transfer speed limited by:
 JTAG connection type (parallel, PCI, etc.).
 DSP activity level.
RTDX: Flow of Data
 Code Composer Studio controls the flow
of data between the host (PC) and the
target.

RTDX: Example (1)
Target
Host
DSK6711
 In this application a program is written

for sending data from the DSK6711 to
the host.
 Code location:
\CD ROM 2004\DSP Code 6711 Update\Chapter 04 - DSP BIOS\Bios_Lab3
DSK6711 Host
bios_lab3.pjt s1l1.c
s1l1.exe

RTDX: Example (2) - Testing the Code
(1) Connect and power up the
DSK.
(2) Envoke CCS and load the
program (bios_lab3.out).
(3) Enable the RTDX as shown
opposite.
(4) Run the code.

(5) Run the host code “s1l1.cpp.exe” and observe the output.
The DSP C code is shown in: \Links\Main3.pdf

DSP/BIOS Feature Summary
Features Benefits
Easy to use Saves development time
Small Footprint (<2Kw) Easily fits in limited memory systems
Fast Execution Ideal for real time systems
Real-Time Analysis View system parameters
while system is executing without
breakpoints and without additional
overhead - “Test what you fly and fly
what you test”
Set of Library Functions Use only what you need to minimize
footprint
Extensible Full featured kernel allows additional
OS functions in future

DSP/BIOS Summary
 At present DSP/BIOS does not support
multiprocessors.
 The “VSPWorks” operating system from
WindRiver Systems does support
multiprocessing.
 www.windriver.com

DSP/BIOS
 Code location:
 Code\Chapter 04_- DSP BIOS\BIOS_Lab3\bios_lab_3.pjt
 Further Reading:
(1) Use the help provided with the CCS (Help also
includes tutorials c:\ti\tutorial\dsk6711).
(2) TMS320C6000 DSP/BIOS: User Guide.
(3) TMS320C6000 DSP/BIOS: Application Programming
Interface (API) SPRU403.
(4) Application Report: DSP/BIOS II Timing
Benchmarks on the TMS320C6000 DSP SPRA662.
(5) Application Report DSP/BIOS II Sizing Guidelines
for the TMS320C62x DSP SPRA667.

Chapter 4
DSP/BIOS
- End -

Dsp/bios

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Dsp/bios

Uploaded by

Copyright:

Available Formats

Chapter 4

hapter 4, Slide 3 Dr. Nai

hapter 4, Slide 4 Dr. Nai

 The user writes code (‘C’/assembly) using the

 The project is then compiled, assembled and linked by

 Code composer simulator/debugger and the host

Note: API: Application Programming Interface

hapter 4, Slide 8 Dr. Nai

hapter 4, Slide 9 Dr. Nai

hapter 4, Slide 10 Dr. Nai

hapter 4, Slide 11 Dr. Nai

hapter 4, Slide 12 Dr. Nai

hapter 4, Slide 13 Dr. Nai

Programs/Files generated by the

Programs generated by the user

hapter 4, Slide 14 Dr. Nai

hapter 4, Slide 16 Dr. Nai

 Once ISR1 or 2 is called, algorithm 1 or 2 runs

 Once ISR1 or ISR2 is called, algorithm 1 or 2

hapter 4, Slide 19 Dr. Nai

CPU processing MISSED!

 Remember: there is only one CPU and therefore

hapter 4, Slide 21 Dr. Nai

hapter 4, Slide 22 Dr. Nai

 Which operating system? Depends on:

hapter 4, Slide 23 Dr. Nai

hapter 4, Slide 24 Dr. Nai

hapter 4, Slide 25 Dr. Nai

Software Interrupts Multiple SWIs at each level.

HWI triggered by hardware interrupt.

SWI cannot pend. TSK only returns when no

SWI 1 pend pend pend

Events over time

hapter 4, Slide 29 Dr. Nai

hapter 4, Slide 30 Dr. Nai

The GUI interface will generate the “bios_labcfg.c”, see

(3) Select HWI_INT15 and right

hapter 4, Slide 32 Dr. Nai

void timerIsr (void)

hapter 4, Slide 33 Dr. Nai

and create a new software interrupt called “SWI_for_algorithm_1”.

hapter 4, Slide 34 Dr. Nai

hapter 4, Slide 35 Dr. Nai

void algorithm_1 (void)

hapter 4, Slide 36 Dr. Nai

and create a new task called “TaskOneTsk”.

hapter 4, Slide 37 Dr. Nai

hapter 4, Slide 38 Dr. Nai

void ProcessTask (void)

hapter 4, Slide 39 Dr. Nai

(2) Change the properties of the “taskOneSem” to:

hapter 4, Slide 40 Dr. Nai

hapter 4, Slide 41 Dr. Nai

void ProcessTask (void)

hapter 4, Slide 42 Dr. Nai

See example located in:

…\ Chapter 04 - DSP BIOS\Bios_Lab2\bios_lab_2.pjt

hapter 4, Slide 45 Dr. Nai

hapter 4, Slide 47 Dr. Nai

hapter 4, Slide 48 Dr. Nai

hapter 4, Slide 49 Dr. Nai

hapter 4, Slide 50 Dr. Nai

extern far LOG_Obj fastprint; /fastprint is a user chosen name /