Concepts of Compiler Design

1

• Why is it hard to integrate someone elses
  algorithm ?
• Dont know how fast it runs or how much
  memory it uses.
• How can I adapt the algorithm to meet my needs?
• Will the function names conflict with other code
  in the system?
• Will it use memory or peripherals needed by other
  algorithms?
• How can I run the same algorithm on more than one
  channel at a time? (How can I prevent variables
  from conflicting?)
• How many interfaces (APIs) do I have to learn?

• Traditional Solution
• Buy an algorithm, Need the source code (and lots
  of development time) or cant guarantee it will
  work.
• Purchasing source code costs a lot of money!

2
TI TMS320 DSP Algorithm Standard
ALGORITHM PRODUCERS
SYSTEMINTEGRATORS
Algorithm
Application
Off-the-shelf DSP content Ease of
Integration Purchase once, use widely
Write once, deploy widely
3
XDAIS Rules

• General Good Citizen Software Coding Rules
• C callable Reentrant
• Naming conventions enforced to avoid symbol
  clashes
• No direct peripheral interface or memory
  allocation
• Relocatable data and code in both static and
  dynamic systems
• No thread scheduling nor any awareness of
  controlling app
• Pure data transducer cannot alter the DSP
  environment
• Standard Algorithm Interface defined by TI
• Defines a memory management protocol between
  application and algorithm for all compliant
  algorithm modules
• Packaging Rules
• All algorithms packaged and delivered in a
  consistent format
• Documentation Rules

4
XDAIS Rules

• Dont know how fast it runs or how much memory
  it uses.

Strict rules on vendor-provided documentation
5
XDAIS Rules

• How can one adapt the algorithm to meet its
  requirements ?

6
XDAIS Rules

• Will the function names conflict with other code
  in the system?

• Algorithm must be C callable and re-entrant
• Strict rules on function naming virtually
  eliminate conflicts.

fir_company123_min.l64
fir_company123_max.h62
L library h header 62 C62x/C67x 64 C64x
Algorithm Module Name
Vendor Name
Variant
7
XDAIS Rules

• Will it use memory or peripherals needed by other
  algorithms?

8
Supports Static Dynamic Instances
Dynamic
Static
Framework (algorithm lifecycle)
algInit
Create

• algNumAlloc
• algAlloc
• algInit

Execute
Filter
algActivate Filter algDeactivate
algFree
Delete
Note Static case can also use algActivate if
algo uses scratch memory
9
XDAIS Rules

• If I want to run the same algorithm on more than
  one channel

10
XDAIS Rules

• If I want to run the same algorithm on more than
  one channel How can I prevent variables from
  conflicting with each other?

Each algorithm gets its own storage location
called an instance object.
IFIR algorithm Instance 1
instObj1
fxns ? Pointer to algorithm functions a ?
Pointer to coefficients x ? Pointer to new
data buffer
IFIR algorithm Instance 2
instObj2
fxns a x
11
XDAIS Rules

• How many interfaces (APIs) do I have to learn?

Only one XDAIS!
And, TI provides a tool ? that essentially writes
the XDAIS interface, though you still need to add
your magic.
12
IOM and XDAIS Common Interfaces

• With standardized interfaces to Algorithms and
  H/W, system software (i.e. framework) can also be
  standardized

• A standard framework can be used as a starting
  point for many different Applications
• Currently, three generic frameworks are available
• Also, application specific frameworks available
  (or coming) for specific applications (audio,
  video, etc.)

13
Mini-Driver Interface (IOM)

• Maximum Reuse and Portability
• One I/O mini-driver (IOM) interface to support
  all TI Class drivers.
• IOM Interface Consists Of

• Functions
• init function
• IOM_mdBindDev
• IOM_mdUnBindDev
• IOM_mdControlChan
• IOM_mdCreateChan
• IOM_mdDeleteChan
• IOM_mdSubmitChan
• interrupt routine (isr)

• Data Structures
• BIOS Device Table
• IOM function table
• Dev params
• Global Data Pointer (device inst. obj.)
• Channel Params
• Channel Instance Obj.
• IOM_Packet (aka IOP)