Getting started with iunivers

Http://processors.wiki.ti.com/index.php/Getting_started_with_IUNIVERSAL

Http://processors.wiki.ti.com/index.php/Codec_Engine_GenCodecPkg_Wizard_FAQ#Running_the_Wizard

Getting started with iunivers
Getting started with iuniversal

Contents [Hide] 1 Introduction 2 additional background info 3 Procedure for making DSP algorithms that are callable from the arm 3.1 Step 1: invoke gencodecpkg 3.2 Step 2: Generate iuniversal starterware 3.3 Step 3: Build 3.4 Step 4: customizing the code Fit your algorithm 3.4.1edits to <module >_< vendor> _ priv. h 3.4.2edits to <module >_< vendor>. h 3.4.3edits to <module>. c 3.5 step 5: creating a "server" that integrates your algorithm plus any others 3.6 Step 6: invoking the DSP code from Arm 3.7 Step 7: Debug 4 iuniversal examples 4.1 source code 4.2 reference examples 5see also

Introduction

Ti sells processing system on chip (SOC) devices that feature both an arm and a DSP. typically Ti provides an executable which runs on the DSP but is callable from the arm to provide multimedia capabilities (e.g. h. 264 encode/decode, etc .). ti customers frequently
Wocould like to have their own algorithm also capable of running on the DSP. codec engine provides a framework to enable MERs to run their code on the DSP and to call it seamlessly from the arm. the universal interface provides a method for MERs
Plug in any algorithm into this framework and take advantage of the dual core architecture.

This article intends to provide Ti SOC users a process of writing algorithms which utilize the universal interface and CODEC engine framework to quickly get their code running on the DSP through function CALS from the arm.

Additional background info

[Skip this section if you're already familiar with visa, xdm, xdais, rtsc.]

If you're not quite sure what this all means, let's take a few steps back: In the beginning, we wanted to be able to run multiple algorithms from multiple developers on a Single DSP, So Ti created a standard to ensure the algorithms didn't steal resources
From each other, had unique namespaces, and coshould "Play nice" together in general. There are a number of APP notes and docs on this, so check outxdais documentation.
If you learn better by example, go
Xdais sample algorithm. There's even a clever tool to make sure you 've got it right: qualiti.

Since most of the algorithms were strictly multimedia, Ti then extended xdais to create a standard API (called xdm) specifically designed for multimedia codecs. these codecs are frequently referred to as visa (for video, imaging, speech, and audio ). check
Out of
Xdm users guide. When combined with codec engine, we then have a nice way to simply "Plug and Play" our visa codecs.

We then started getting questions like, "How can I get my face detection algorithm to work with codec engine? "One solution is to create adaptorsas described here to make
Your algorithm look like a multimedia codec, and this worked well for a number of folks. but surely there shoshould be another (possibly easier) Way to get your algorithm to run-thus we get the introduction of the iuniversal API.

If you want a crash course on the above (xdais, xdm, rtsc packaging, etc. But not iuniversal in particle), check out the freely availableomap and DaVinci Software
For Dummies book.

Procedure for making DSP algorithms that are callable from the armstep 1: invoke gencodecpkg

The first thing to do is
Launch the wizard!

Step 2: Generate iuniversal starterware

Screen 1

Screen 1

1. Click 3rd option, "I want to create an algorithm from scratch"
2. The xdais directory shocould already point to your xdais directory (frequently the $ (ce_install_dir)/cetools/packages directory if you're not using a dvsdk ).
3. Point to the root of the compiler installation (I. e. One abve the "bin" directory ).
4. Click Next.

Screen 2

Screen 2

1. In the "module" field enter the name of the algorithm you're creating.
2. In the "vendor" field enter your company name.
3. Under "base interface" choose "iuniversal ".
4. For "target" choose c64p for 64x + devices or choose c674 for 674x devices (floating point ).
5. The output repository is where the generated files will be placed.
6. Click Finish to generate the starter files.

Generated output

Output files

The generated files will reside at <output_repository>/<vendor>/<module.

Step 3: Build

Before making ANY changes, you should be able
Build the generated package as is.

Step 4: customizing the code to fit your algorithmedits to <module >_< vendor> _ priv. h

The object definition<Module >_< vendor> _ OBJIsInstance ObjectFor your algorithm. The instance object is considered "private" in the sense that it is utilized internally by your algorithm. It shoshould containState
Of each instance of your algorithm. in an FIR filter example this might consist of a pointer to the history buffer, a pointer to the filter coefficients, and the length of the filter. in this way each new filter that is created can have its own associated
Filter coefficients and history. Memory acquired duringAllocPhase of the algorithm wowould likely have a parameter in this structure for use by the algorithm.

Edits to <module >_< vendor>. h

1. Define commands for use inControl ()Function.
   • Look# Define I <module> _ user1_0
   • ChangeUserdefaults 0To something more meaningful, e.g.Change_volume.
   • Remove# Ifdef 0From around the commands in order to use them.
2. ExtendI <module> _ ParamsAs needed. This structure defines
   OnlyParameters used at the time of instance creation.I <module> _ dynamicparamsStructure we see later is what will be passed toControl ()Function.
3. ExtendI <module> _ inargsStructure as needed. These are the input arguments that will be passed to yourProcess ()Function.
4. ExtendI <module> _ outargsStructure as needed. This structure is used byProcess ()Function to return info back to the application.
5. ExtendI <module> _ dynamicparamsStructure as need. This structure is passed along with a command toControl ()Function.
6. ExtendI <module> _ StatusStructure as necessary. This structure gets filled in byControl ()Function to provide status info back to the application.

Edits to <module>. c

1. Const I <module> _ Params
   • This Code defines default parameters for instance creation.
   • When creating an algorithm instance the application has the option of passing a null handle forI <module> _ Params. In that case the algorithm uses the default parameters which you define here.
2. <Module >_< vendor> _ alloc ()
   • This is the process by which you request memory for your algorithm. xdais algorithms never malloc () their own memory. they request it from the application through this function. this allows the system integrator to have better control over how memory is
     Being given out.
   • By default it requests memory to contain your instance object. Any other memory needed (working buffers, etc.) shocould be requested here.
   • Each memtab entry tells size, alignment, internal/external, and persistent/scratch/Write-once.
   • This function returns the number of entries it filled in. If you add any entries make sure you increment the return value accordingly.
3. <Module >_< vendor> _ free ()
   • Normally this can just utilizeAlloc ()Function.
   • You only need to do something here if your initial Memory Request inAlloc ()Was dependent uponI <module> _ ParamsPassed into the function.
4. <Module >_< vendor_initobj ()
   • This function gets called after the application has granted memory requests based on yourAlloc ()Function.
   • The rest of the memtab has now been filled out by the application with the corresponding pointers to the memory you requested.
   • Those pointers shocould be assigned to corresponding members of your instance object for use during Run-Time.
5. <Module >_< vendor> _ process ()
   • This is where the actual algorithm goes! Add your algorithm code here.
   • Important: For the purpose of cache coherence it's important to tell the framework about howCPU(Not DMA if you're using acpy !) Has accessed the buffers.
   • You must tell the application if you have read from or written to any of the buffers. This is achieved by usingAccessmaskFields associated with each and every buffer.
6. <Module >_< vendor> _ control ()
   • By default this function already supports the required command xdm_getversion.
   • There is# Ifdef 0That you can get rid of to add handling for any commands that you defined in <module >_< vendor>. h.

Step 5: creating a "server" that integrates your algorithm plus any others

Codec engine supports running any iuniversal-Compliant Algorithm 'locally '(on the same processor as your app) or 'remotely' (on a slave processor, like the c64p of an omap3 device ). see thecodec
Engine genserver wizard FAQ for details on creating a server that integrates your gencodecpkg-generated iuniversal algorithm into a DSP server.

Step 6: invoking the DSP code from the arm

• SeeUniversal_copyExample app in
  Codec engine examples (found in examples/Ti/SDO/CE/examples/apps/universal_copy). That example demonstrates
  • Building an application that contains an "engine" that includes des the algs in the "server" you just built
  • At runtime, opening the named engine (Engine_open())
  • Creating an instance of your algorithm (UNIVERSAL_create()
  • Interacting with that algorithm instance (UNIVERSAL_process()/UNIVERSAL_control())
  • Deleting the algorithm instance (UNIVERSAL_delete())
  • Closing the engine (Engine_close())

Step 7: Debug

Using the console output

• Ce_check = 1ce_debug = 2./MyApp
• Check for proper cache operations
• Using CCS to debug Algorithm
• Possibly using CCS to debug skeleton-
  Here's how to link in debug Libraries

JTAG based debug with CCS

• Debugging the DSP side of a CE application on DaVinci
  Using CCS

Iuniversal examples

Example code always makes it easier, so you may be want to download a set of iuniversal examples fromhere. There is
Also
Article that builds on these examples and provides a worked example of a Canny edge detector to build a C64 + iuniversal-compliant ALG and then CILS it from multiple platforms with both single cores (dm6437) and arm + DSP cores (dm6467 + omap3530 ).

Let's first checkout some examples and source within the xdais and Ce products:

Source code

Xdais iuniversal header file:Xdais _ <version>/packages/Ti/xdais/dm/iuniversal. h-Notice here that each of the iuniversal structs (I. e. iuniversal_params, iuniversal_inargs, etc) contain a size field. Only a few structs contain
Other fields, such as iuniversal_status contains extendederror and data.

Ce universal code(Of particle interest is universal. h ):
Codec_engine _ <version>/packages/Ti/SDO/CE/universal-Notice that universal. H is whereUNIVERSAL_process(),
UNIVERSAL_control(), Etc. are defined. These functions differ from the traditional xdm classes only slightly-mainlyUNIVERSAL_process()Schemdes
XDM1_BufDesc *inOutBufsArgument that can be used for buffers that are used for both inputAndOutput to/from the algorithm.

Reference examples

Universal copy Codec:Xdais _ <version>/examples/Ti/xdais/dm/examples/universal_copy/

Universal copy codec package:Codec_engine _ <version>/examples/Ti/SDO/CE/examples/codecs/universal_copy

Universal copy server package:Codec_engine _ <version>/examples/Ti/SDO/CE/examples/servers/all_codecs-Check out the main. c file to see that the DSP executable (aka "server") merely inits ce and trace. It is useful to note that
The memory map is contained in the TCI (or TCF) and the codec configuration is done in the. cfg file.

Universal copy Sample Application:Codec_engine _ <version>/examples/Ti/SDO/CE/examples/apps/universal_copy-This shows a short application that can run the codec either locally or remotely.