advisor: prof. andy wu 2004/11/11access.ee.ntu.edu.tw/course/dsp_lab/slides/w9 2004-11-11... ·...

ACCESS IC LAB

Graduate Institute of Electronics Engineering, NTU

Advisor: Prof. Andy Wu2004/11/11

ACCESS IC LAB Graduate Institute of Electronics Engineering, NTU

P2

OutlineOutline

IntroductionGlossary of VDK TermsVDK APIUsing VDKCreating a VDK-Enabled ProjectLabReference


P3

IntroductionIntroduction

VisualDSP++ kernel (VDK)Real time operating system kernel integrated with the development toolsAbstract the details of the hardware implementation from the software designSoftware executive between DSP algorithms, peripherals, and control logic

ThreadA piece of the workEach thread operates independently of the othersA thread can communicate with other threads


P4

Partitioning an ApplicationPartitioning an Application

Reduce the complexity of your system.An application can be partitioned into smaller functional units that can be individually coded and tested.These building blocks then become reusable components in more robust and scalable systems.Define the behavior of VDK threads by creating thread types.Types are templates that define the behavior and data associated with all threads of that type.


P5

SchedulingScheduling

VDK State DiagramVDK is a preemptive multi-tasking kernelEach thread begins executionat its entry pointEach thread is given a priorityto assist the scheduler indetermining precedenceof threads


P6

Thread and Hardware Interaction (1/2)Thread and Hardware Interaction (1/2)

Threads should use device drivers for hardware controlA thread can control and interact with a device in a portable and hardware abstracted manner through a standard set of APIs

VDK Interrupt Service Routine framework encourages you to remove specific knowledge of hardware from the algorithms encapsulated in threadsInterrupts relay information to threads through signals to device drivers or directly to threadsUsing signals to connect hardware to the algorithms allows the kernel to schedule threads based on asynchronous events


P7

Thread and Hardware Interaction (2/2)Thread and Hardware Interaction (2/2)

VDK run-time environment can be thought of as a bridge between two domains, the thread domain and the interrupt domainDevice drivers and signals bridge the two domains


P8

OutlineOutline

IntroductionGlossary of VDK TermsUsing VDKVDK API Creating a VDK-Enabled ProjectLabReference


P9

Glossary of VDK Terms (1/6)Glossary of VDK Terms (1/6)Application Programming Interface (API) A library of C/C++ functions and assembly macros that define VDK services. These services are essential for kernel-based application programs. The services include interrupt handling, thread management, and semaphore management, among other services.

Channel A FIFO queue into which messages sent to a thread are placed. Each thread has 15 channels with messages being received in priority order from the lowest numbered channel to the highest.

Context switch A process of saving/restoring the processor s state. The scheduler performs the context switch in response to the system change.A hardware interrupt can occur and change the state of the system at any time. Once the processor s state has changed, the currently running thread may be swapped with a higher-priority thread. When the kernel switches threads, the entire processor s state is saved and the processor s state for the thread being switched in is restored. This process is known as a context switch.

Critical region A sequence of instructions, whose execution cannot be interrupted or swapped out. To ensure that the execution of a critical region is not interrupted, all interrupt service routines (ISRs) must be suspended before calling the critical region. Once thecritical region routine has been completed, ISRs are enabled.


P10

Glossary of VDK Terms (2/6)Glossary of VDK Terms (2/6)Device driver A user-written model that abstracts the hardware implementation from the application code. User code accesses device drivers through a set of device driver APIs.

Event A signal (similar to a semaphore or message) used to synchronize multiple threads in a system. An event is a logical switch, having two binary states (available/true and unavailable/false) that control thread execution. When an event becomes available, all pending (waiting) threads in the wait list are set to be ready-to-run. When an event is available and a thread pends on it, the thread continues running and the event remains available.To facilitate error handling, threads can specify a timeout period when pending on an event.An event is a code object of global scope, so any thread can pend on any event. Event properties include the EventBit mask, EventBit value, and combination type. Events are statically allocated and enumerated at runtime. An event cannot be destroyed, but its properties can be changed.

Event bit A flag set or cleared to post the event. The event is posted (available) when the current values of the system Event Bits match the event bit s mask and event bits values defined by the event's combination type. There is one and only one Event Bits word in a system. It is the size of a data word minus 1: fifteen bits for ADSP-219x DSPs; thirty-one bits for ADSP-21xxx, Blackfin, and ADSP-TSxxxDSPs.


P11

Glossary of VDK Terms (3/6)Glossary of VDK Terms (3/6)Interrupt An external or internal condition detected by the hardware interrupt controller. In response to an interrupt, the kernel processes a subroutine call to a predefined Interrupt Service Routine (ISR).Interrupts have the following specifications:

Latency interrupt disable time. The period between the interrupt occurrence and the first ISR s executed instruction. Response interrupt response time. The period between the interrupt occurrence and a context switch. Recovery interrupt recovery time. The period needed to restore the processor s context and to start the return-from-interrupt (RTI) routine.

Interrupt Service Routines (ISRs) A routine executed as a response to a software interrupt or hardware interrupt. VDK supports nested interrupts, which means the kernel recognizes other interrupts and/or services interrupts with higher priorities while executing the current ISR. VDK ISRs are written in assembly language. VDK reserves the timer and the lowest priority (reschedule) interrupt.

Kernel The kernel is the main module of a real-time operating system. The kernel loads first and permanently resides in the main memory and manages other modules of the real-time operation system. Typical services include context switching and communication management between OS modules.


P12

Glossary of VDK Terms (4/6)Glossary of VDK Terms (4/6)Memory pool An area of memory containing a specified number of uniformly sized blocks of memory available for allocation and subsequent use in an application. The number and size of the blocks in a particular memory pool are defined at pool creation.

Message A signal (similar to an event or semaphore) used to synchronize two threads in a system or to communicate information between threads. A message is sent to a specified channel on the recipient thread (and can optionally pass a reference to a payload to facilitate the transfer of data between threads). Posting a message takes a deterministic amount of time and may incur a context switch.

Payload An arbitrary amount of data associated with a message. A reference to the payload can be passed between threads as part of a message to enable the recipient thread to access the data buffer that contains the payload.

Preemptive kernel A priority-based kernel in which the currently running thread of the highest priority is preempted, or suspended, to give system resources to the new highest-priority thread.

Real-time operating system (RTOS) A software executive that handles DSP algorithms, peripherals, and control logic. The RTOS comprises the following components: kernel, communication manager, support library, and device drivers. An RTOS enables structured, scalable, and expandable DSP application development while hiding OS complexity.


P13

Glossary of VDK Terms (5/6)Glossary of VDK Terms (5/6)Round-robin scheduling A scheduling scheme whereby all threads at a given priority are given processor time automatically in fixed duration intervals. Round-robin priorities are specified at build time.

Scheduler A kernel component responsible for scheduling system threads and interrupt service routines. VDK is a priority-based kernel in which the highest-priority thread is executed first.

Semaphore A signal (similar to an event or message) used to synchronize multiple threads in a system. A semaphore is a data object whose value is zero or a positive integer (limited by the maximum set up at creation time). The two states (available/greater than zero and unavailable/zero) control thread execution. Unlike an event, whose state is automatically calculated, a semaphore is directly manipulated. Posting a semaphore takes a deterministic amount of time and may incur a context switch.

Signal A method of communicating between multiple threads. VDK supports four types of signals: semaphores, events, messages, and device flags.

System configurator The System Configuration control is accessible from the Kernel page of the Project window. The Kernel page provides a graphical representation of the data contained in the vdk.h and vdk.cpp files.


P14

Glossary of VDK Terms (6/6)Glossary of VDK Terms (6/6)Threads A kernel system component that performs a predetermined function and has its own share of system resources. VDK supports multithreading, a run-time environment with concurrently executed independent threads.Threads are dynamic objects that can be created and destroyed at runtime. Thread objects can be implemented in C, C++, or assembly language. A thread s properties include an ID, priority, and current state (wait, ready, run, or interrupted). Each thread maintains its own C/C++ stack.

Ticks The system level timing mechanism. Every system tick is a timer interrupt.

Unscheduled regions A sequence of instructions whose execution can be interrupted, but cannot be swapped out. The kernel acknowledges and services interrupts when an unscheduled region routine is running.

VisualDSP++ Kernel (VDK) RTOS kernel from Analog Devices. VDK is part of VisualDSP++. The kernel is integrated with the Integrated Development and Debugging Environment (IDDE), assembler, compiler, and linker programs into the DSP development tool chain.


P15

OutlineOutline

IntroductionGlossary of VDK TermsUsing VDKVDK APICreating a VDK-Enabled ProjectLabReference


P16

1. Threads1. Threads

When designing an application, you partition it into threads, where each thread is responsible for a piece of the work. Each thread operates independently of the others. A thread performs its duty as if it has its own processor but can communicate with other threads.


P17

2. Scheduling2. Scheduling

The scheduler s role is to ensure that the highest priority ready thread is allowed to run at the earliest possible time. The scheduler is never invoked directly by a thread but is executed whenever a kernel APIcalled from either a thread or an ISR changes the highest priority thread. The scheduler is not invoked during critical or unscheduled regions, but can be invoked immediately at the close of either type of protected region.


P18

3. Signals3. Signals

Threads have four different methods for communication and synchronization:

SemaphoresMessagesEvents and Event BitsDevice Flags

Each communication method has a different behavior and use. A thread pends on any of the four types of signals, and if a signal is unavailable, the thread blocks until the signal becomes available or (optionally) a timeout is reached.


P19

4. Interrupt Service Routines (4. Interrupt Service Routines (ISRsISRs))

Unlike the Analog Devices standard C implementation of interrupts (using signal.h), all VDK interrupts are written in assembly. The VDK encourages users to write interrupts in assembly by giving hand optimized macros to communicate between the interrupt domain and the thread domain. All calculations should take place in the thread domain, and interrupts should be short routines that post semaphores, change event bit values, activate device drivers, and drop tags in the history buffer.


P20

5. I/O Interface5. I/O Interface

The I/O interface provides the mechanism for creating an interface between the external environment and VDK applications. In VisualDSP++ 3.5, only device driver objects can be used to construct the I/O interface.


P21

6. Memory Pools 6. Memory Pools Common problems experienced with memory allocation using malloc are fragmentation of the heap as well as non-deterministic search times for finding a free area of the heap with the requested size. The memory pool manager uses the defined pools to provide an efficient, deterministic memory allocation scheme as an alternative to malloc. The use of memory pools for memory allocation can be advantageous when an application requires significant allocation and deallocation of objects of the same size. A memory pool is an area of memory subdivided into equally sized memory blocks. Each memory pool contains memory blocks of a single size, but multiple pools can be defined, eachwith a different block size. Furthermore, on architectures that support the definition of multiple heaps, the heap that a pool is to use can be specified. The maximum number of active memory pools in the system is set up when the project is built.


P22

7. Multiple Heaps7. Multiple HeapsBy default all VDK elements are allocated in the system_heap. In previous versions of VDK, multiple heaps could be used in the definition of memory pools on processors for which multiple heap support is provided. This mechanism has been extended and VDK can now use multiple heaps defined at link time (dynamically created heaps are not allowed) to specify which area of memory is used to allocate the various VDK elements (semaphores, messages, thread stacks, and so on). The developer is responsible for setting up the heaps. For more information regarding how to specify multiple heaps, refer to the C/C++ Compiler and Library Manual. To specify a VDK heap, users create a new heap in VisualDSP++, which has a VDK HeapID. An ID is then associated with this name. This ID must be the same one used in setting up the heap under the C/C++ run-time (which is an integer or a string depending on the processor). For more information on how to set up VDK heaps, see the online documentation.


P23

8. Thread Local Storage8. Thread Local StorageThread local storage allows the association of data with threads on a per thread basis. A typical usage of this functionality involves allocating the data required by individual threads for a thread-safe library function, for example, to store the thread-specific value of errno for each thread for the C runtime libraries. There are eight thread local storage slots available for this purpose. Before a value is stored in the relevant slot in the thread's slot table, an entry must be allocated in the global slot table by using either AllocateThreadSlot() or AllocateThreadSlotEx(). If a slot is available in the global table, then the corresponding slot is also reserved in each thread slot table. These APIs return FALSE if there are no free slots available. An allocated entry in the global slot table can subsequently be freed by a call to FreeThreadSlot(). This mechanism for allocating slots provides one time initialization of slots for thread-specific data for library functions slots are allocated in every thread's slot table on the first calling of the library function by any thread. Once a slot has been allocated in the global slot table, the corresponding value in the slot table of a particular thread can be set by a call to SetThreadSlotValue()from the thread in question. The value is of type void * and so can be used to store an integer value or a pointer to allocated memory. The use of AllocateThreadSlotEx() to allocate a slot allows the specification of a cleanup function to be called on thread destruction to deal with any dynamically allocated memory that has been associated with a thread slot. Finally, GetThreadSlotValue()can be used to obtain


P24

OutlineOutline



P25

VDK API (1/5)VDK API (1/5)The VisualDSP++ Kernel Application Programming Interface is a library of functions and macros that may be called from your application programs. Application programs depend on API functions to perform services that are basic to the VDK. These services include interrupt handling, scheduler management, thread management, semaphore management, memory pool management, events and event bits, device drivers, and message passing. All of the VDK functions are written in the C++ programming language.


P26

VDK API (2/5)VDK API (2/5)


P27



P28



P29



P30

OutlineOutline



P31

Projects Built With VDKProjects Built With VDKA new project can optionally include the VisualDSP++ kernel (VDK), which is a software executive between DSP algorithms, peripherals, and control logic.The Project window Kernel page provides a tree control, from which to configure (structure and scale) application development. Add, modify, and delete Kernel elements such as thread types,boot threads, round-robin priorities, semaphores, event bits, events, interrupts, device drivers, boot I/O objects, device flags, and memory pools.The two pages of the VDK State History window allow you to view VDK information. The VDK Status window provides thread status data when a VDK-enabled program is halted.


P32

Project Window Kernel PageProject Window Kernel Page

From this page, you can add, modify, and delete kernel elements, such as thread types, semaphores, event bits, events, interrupts, device drivers, device flags, and memory pools. VisualDSP++ automatically updates the project's .VDK, vdk.cpp, and vdk.h files to reflect any configuration changes you make.

VDK system configurator (.VDK).VDK is used to generate the vdk.h and vdk.cpp


P33

VDK State History Window (2/2)VDK State History Window (2/2)

Display thread event and thread status


P34

Target Load PageTarget Load Page

The Target Load page of the VDK State History window displays a target load plot that shows the percentage of time the target spent in the Idle thread. A load of 0% means VDK spent all of its time in the Idle thread, and a load of 100% means the target did not spend any time in the Idle thread.Load data is processed using a moving window average.


P35

VDK Status WindowVDK Status Window

The VDK Status window is available when a DSP executable is built with VDK support enabled. When you halt execution of a VDK program, VisualDSP++ reads data for threads, semaphores, events, event bits, device flags, memory pools, and messages and displays the state and status data in this window When one of the above VDK entities is created, it is added to the display. An entity is removed from the display when it is destroyed.


P36

Create Project with VDKCreate Project with VDK1. From the Project menu, choose New.

The Save New Project As dialog box appears.2. In File name, type a name for the project.3. In Save in, select the folder in which to place the project.4. Click Save.

The Project page of the Project Options dialog box appears.5. Specify your target processor via the Project Options dialog box.6. Click OK.

If VDK supports the processor that you selected in step 5, a message box queries Would you like to add support for the VisualDSP++ kernel to this project?

7. Click Yes.The IDDE automatically generates the default VDK source files (vdk.cpp and vdk.h) and adds them to the project. A third file, project_name.vdk, is added to the project to enable VDK support in the IDDE.

Note: Do not modify, overwrite, or remove vdk.h or vdk.cpp.


P37

Adding a Thread Type to a ProjectAdding a Thread Type to a Project1. From the Project window, click the Kernel tab.2. Click the next to the Threads icon.

The thread element properties appear.3. Right-click on the Thread Types icon and choose New Thread Type.

The New Thread Type dialog box appears.4. In Name, type a name for the new thread type.

The thread type name must be a valid C identifier (no special characters, such as spaces or hyphens, are allowed).

5. In Source file and Header file, optionally change the name of the source and header files in which the new thread type will be defined.

6. In Would you like these files to be automatically generated and added to your project, select an option.Yes generates skeleton source code for this thread type. Choose the language (C++, C, or Assembly) in which the sources are generated.

Caution: If you create a source file specifying a name already in your project s directory, a pop-up box warns you that if you proceed, the existing files will be overwritten.

No uses existing code for the thread type. In this case, you must manually add the source to your project.

7. Click OK.If you chose to generate source code in step 6, the files are created and automatically added to the project.


P38

Adding a Device DriverAdding a Device Driver1. From the Project window, click the Kernel tab.2. Click the + next to the I/O Interface icon, right-click Device Drivers, and choose

New Device Driver.The New Device Driver dialog box appears.

3. In Name, type a name for the device driver.The device driver name must be a valid C identifier. No special characters, such as spaces or hyphens, are allowed.

4. In Source file and Header file, optionally change the name of the source and header files in which the new device driver will be defined.By default, the names are driver_name.cpp and driver_name.h.

5. In Would you like these files to be automatically generated and added to your project, select an option.Yes generates skeleton source code for this device driver.

Caution: If you create a source file specifying a name already in your project s directory, a pop-up box warns you that if you proceed, the existing files will beoverwritten.

No uses existing code for the device driver. In this case, you must manually add the source to your project.

6. In Language, select C or C++.7. Click OK.


P39

More AddingMore Adding

Adding a VDK Heap to a ProjectAdding Imported Projects

Boot ThreadsDevice FlagsEventsInterruptSemaphores


P40

./Analog Devices/VisualDSP 3.5 16-Bit/Blackfin/Examples/VDK/BF533/Factory

KernelThreads

Thread TypesBoot Threads

SemaphoresProject

FactoryRampGenRotator

Example 1Example 1


P41

Example 2Example 2

./Analog Devices/VisualDSP 3.5 16-Bit/Blackfin/Examples/VDK/BF533/InterProcessCommunication_DD

KernelThreads

Thread TypesBoot Threads

I/O InterfaceDevice DriversBoot I/O Objects

Device Flags

ProjectIPC.h, IPC.cpp: DispatchFunction()thread1.h, thread1.cpp: Run()thread2.h, thread2.cpp: Run()


P42

Result


P43

OutlineOutline



P44

LabLab

Example1(Factory) VDK ProjectThreads

Blink

Example2(ProcessCommunication_DD)Threads Device Driver (Optional)

Blink FIR


P45

OutlineOutline



P46

ReferenceReference[1] Analog Devices, Inc. Visual DSP++ 3.5 Kernel (VDK) User s Guide for 16-Bit Processors , Revision 1.0, October 2003.

[2] Analog Devices, Inc. Analog Devices_ Embedded Processing & DSP [Online] . Available: http://www.analog.com/dsp

[3] VDK VDK Help , VDK User s Guide

advisor: prof. andy wu 2004/11/11access.ee.ntu.edu.tw/course/dsp_lab/slides/w9 2004-11-11... ·...

Documents