Codec Engine configuration en breve

Codec Engine configuration en breve

Introduction

This page summarizes the most important care-abouts in a typical Codec Engine configuration. The best place to start is to study the .cfg and .tcf files in a given Codec Engine example. Make a copy of them and start modifying the relevant parameters.

More details can be found in the Codec Engine User Guides. But the goal of this page is to point out the things that most users would need to configure, so that they can quickly get started without going through the documentation.

Application configuration

This is the configuration that needs to be done in the configuration file (.cfg) of a Codec Engine-based application's executable.

Creating an Engine in Codec Engine configuration

One of the initial APIs that must be called when using the Codec Engine is Engine_open(); and in order to open an Engine, you must create it first. You can create one as shown in the example below:

<syntaxhighlight lang='javascript'> var decoder = xdc.useModule('ti.sdo.ce.examples.codecs.viddec_copy.VIDDEC_COPY');

var Engine = xdc.useModule('ti.sdo.ce.Engine'); var Engine = Engine.create("decode", // Engine name. Your C code will use it to reference this engine in Engine_open() [

   //List all codecs that would be part of the engine
   {name  : "viddec_copy",  // Name of the codec. Should match the name in the server if any
    mod   : decoder,        // The module corresponding to this codec
    local : true            // Whether this codec runs on the same CPU as the application
   },

]); </syntaxhighlight>

NOTE - for ARM+DSP devices there's a better way to do this in Codec Engine >= 2.0 - createFromServer().

See the Codec Engine Application Developer User's Guide for more details.

Configuring DSPLINK with DSP memory map in Codec Engine 1.20

This is required only on heterogeneous platforms (e.g. DM6446 or OMAP3 devices which contain an ARM and a C6x-based DSP), where the ARM runs the application and the DSP runs algorithms/codecs. DSP Link is used in this case as a communication layer between the two cores. Setup the armDspLinkConfig field for your engine to *match* the DSP/BIOS configuration file (.tcf) on the DSP side. Only the four memory sections shown in the example below needs to be listed.

Code Example: <syntaxhighlight lang='javascript'> demoEngine.armDspLinkConfig = {

   memTable: [
       ["DDRALGHEAP", {addr: 0x8F000000, size: 0x00A80000, type: "other"}],
       ["DDR",        {addr: 0x8FA80000, size: 0x00380000, type: "main" }],
       ["DSPLINKMEM", {addr: 0x8FE00000, size: 0x00100000, type: "link" }],
       ["RESETCTRL",  {addr: 0x8FF00000, size: 0x00000080, type: "reset"}],
   ],

}; </syntaxhighlight>

See the Codec Engine Application Developer User's Guide for more details.

DSP side configuration

This is the configuration that needs to be done in the configuration file (.cfg) of either a DSP server executable (on heterogeneous platforms such as the DM6446) or the DSP application (on DSP-only platforms such as the DM6437).

Setting up memory sections in DSP/BIOS configuration file (.tcf)

Define/Adjust memory sections (MEM objects) and heaps. These will be used later in the Codec Engine configuration file.

Code Example: <syntaxhighlight lang='javascript'> var mem_ext = [ {

   // Definition of a MEM object
   comment:    "DDR: off-chip memory for data",
   name:       "DDR",
   base:       0x8FA80000,   //Base address
   len:        0x00140000,   //Size of DDR memory section
   space:      "code/data"

} ];

var params = {

   clockRate: 594,
   catalogName: "ti.catalog.c6000",
   deviceName: "DM6446",
   regs: device_regs,
   mem: mem_ext           //Use the mem_ext array to define the memory sections

};

utils.loadPlatform("ti.platforms.generic", params);

bios.DDR.createHeap = true; //Creates a heap in DDR bios.DDR.heapSize = 0x80000; // size of heap </syntaxhighlight>

More details on how to configure DSP/BIOS in general can be found in the DSP/BIOS API reference guide.

DSKT2 configuration in Codec Engine's configuration file

Overview

DSKT2 is a module in the Framework Components (FC) product that dynamically manages XDAIS algorithm (e.g. codec) data memory requests. As of FC 2.21, DSKT2 only supported in DSP/BIOS based environments.

Memory Type Mapping

As a crude summary, an algorithm requests one or more blocks of memory during its initialization, each characterized by:

• Space - internal or external
• Usage - scratch or persistent
• Size
• Alignment

The algorithms request abstract memory types, defined by XDAIS's IALG (Interface for ALGorithms) spec. In systems that use DSKT2, the system integrator must configure DSKT2's abstract IALG memory types to concrete DSP/BIOS memory heaps. Each IALG memory space must be mapped to an available BIOS heap (defined in the DSP/BIOS .tcf configuration file). An example DSKT2 config block is here:

<syntaxhighlight lang='javascript'>

   var DSKT2 = xdc.useModule('ti.sdo.fc.dskt2.DSKT2');

   DSKT2.DARAM0     = "L1DSRAM";
   DSKT2.DARAM1     = "L1DSRAM";
   DSKT2.DARAM2     = "L1DSRAM";
   DSKT2.SARAM0     = "L1DSRAM";
   DSKT2.SARAM1     = "L1DSRAM";
   DSKT2.SARAM2     = "L1DSRAM";
   DSKT2.ESDATA     = "DDRALGHEAP";
   DSKT2.IPROG      = "L1DSRAM";
   DSKT2.EPROG      = "DDRALGHEAP";
   DSKT2.DSKT2_HEAP = "DDR";

</syntaxhighlight>

Scratch Configuration

Additionally, to optimize memory utilization, DSKT2 provides the ability to organize algorithms into "scratch groups". Scratch groups are collections of algorithms that share resources. Note that the Codec Engine consolidates the notion of these DSKT2 "scratch groups" with other resource groups (e.g. DMAN3's DMA resource sharing groups), and presents these as a single "group Id". There is more info on Group IDs at this article.

The DSKT2.DARAM_SCRATCH_SIZES[] and DSKT2.SARAM_SCRATCH_SIZES[] arrays are used to configure DSKT2 with the worst-case size of shared scratch memory for each scratch group. Codec Engine (CE) users have several methods to configure these arrays:

• CE 1.x prior to 1.10 - system integrators must explicitly configure these DSKT2 scratch arrays.
• CE 1.10 and later - Server integrators can configure the Servers to autogenerate these scratch arrays, assuming all codecs implement the necessary .getDaramScratchSize(), and .getSaramScratchSize() methods defined in the ti.sdo.ce.ICodec interface. The code to enable this autogeneration is here:

<syntaxhighlight lang='javascript'> var Server = xdc.useModule('ti.sdo.ce.Server'); Server.autoGenScratchSizeArrays = true; </syntaxhighlight>

Note that the necessary .getDaramScratchSize(), and .getSaramScratchSize() methods were also added in CE 1.10, so many codec producers have not implemented these methods, in which case you won't be able to use this approach.

To manually find out how much space to give to each scratch group (which is probably you best bet for most codecs that exist as of today), you can turn the DSKT2 trace on (see the debugging section following this one) to print out algorithm scratch requests for DARAM and SARAM. For example:

@0x000fd977:[T:0x88b665f4] ti.sdo.fc.dskt2 - _DSKT2_getScratchRequestInfo> Enter (ialgSpace=IALG_DARAM0, numRecs=9)
@0x000fd9c3:[T:0x88b665f4] ti.sdo.fc.dskt2 - _DSKT2_getScratchRequestInfo> Exit (sizeBestCase=64768, sizeWorstCase=64896, numScratchRecs=1)

The above trace snippet was captured while an algorithm is being created and indicates that in the worst case, a total of 64896 bytes were needed for DARAM scratch memory requests, for this particular algorithm.

After determining the amount of scratch memory needed by each algorithm, the size for a particular group i is:

• DARAM_SCRATCH_SIZES[i] = max(total DARAM scratch memory requested by an algorithm) over all algorithms in group i.
• SARAM_SCRATCH_SIZES[i] = max(total SARAM scratch memory requested by an algorithm) over all algorithms in group i.

When constrained in amount of internal memory heap space:

• Double-check the scratch sizes arrays to ensure you are not allocating more scratch space then necessary for each scratch group
• Assign DSKT2.DSKT2_HEAP to an external heap in the DSP's .cfg file (e.g. DSKT2.DSKT2_HEAP = "DDR";)

Debugging

In Framework Components 1.x, you can configure DSKT2.debug to true during development to enable obtain some tracing information and/or to insert debug symbols for this module. Just add a line to the server's .cfg file:

<syntaxhighlight lang='javascript'> var DSKT2 = xdc.useModule('ti.sdo.fc.dskt2.DSKT2'); DSKT2.debug=true; //Add this line </syntaxhighlight>

In Framework Components 2.x, an additional config param, DSKT2.trace, has been added. It's orthogonal to DSKT2.debug, meaning you can have all permutations of trace on/off and debug on/off. It also means that the FC 1.x interpretation of DSKT2.debug = true; providing trace statements is no longer applicable. FC 2.x users wishing to enable trace need to explicitly set

<syntaxhighlight lang='javascript'>DSKT2.trace = true;</syntaxhighlight>

DSKT2 trace lists out all IALG requests from each codec instance and computes totals of memory allocated for each one. This information is useful for sizing your memory map.

More details on the syntax with newer releases are here: FC_Config_Updates#Debug_and_Trace_settings

Debugging - a scratch sharing use-case

Let's look at e.g. the DVSDK 1.30 loopback (h.264 encode + decode) on DM6446. In the combos / servers dm6446_dvsdk_combos_1_35/packages/ti/sdo/servers/loopback/loopback.cfg you can see: -

<syntaxhighlight lang='javascript'> Server.algs = [

   {name: "h264enc", mod: H264ENC, groupId:0,threadAttrs: {
       stackMemId: 0, priority: Server.MINPRI + 1}
   },
   {name: "h264dec", mod: H264DEC, groupId:0,threadAttrs: {
       stackMemId: 0, priority: Server.MINPRI + 1}
   },

]; </syntaxhighlight>

This says "let's have both H.264 encode and decode at the same BIOS Task priority and consequently use the same scratch memory group (via usage of the same groupId)".

We have 2 codecs so how do we decide what to put for e.g. DSKT2.DARAM_SCRATCH_SIZES[]?

Clearly it has to be the greater of the 2 codecs. Let's now look at the codec configuration: -

• packages/ti/sdo/codecs/h264enc/ce/H264ENC.xs - it has: -

<syntaxhighlight lang='javascript'> function getDaramScratchSize(prog) {

   if (verbose) {
       print("getting DARAM scratch size for " + this.$name
           + " built for the target " + prog.build.target.$name
           + ", running onplatform " +  prog.platformName);
   }

   return (64768);

} </syntaxhighlight>

• packages/ti/sdo/codecs/h264dec/ce/H264DEC.xs - it returns 49152 for getDaramScratchSize().

Now let's look at the settings for the internal scratch arrays: - <syntaxhighlight lang='javascript'> /*

* Note that the sizes of these arrays is larger than the 1 element set below.
* Any unassigned elements of the array are initialized to zero.
*/

DSKT2.DARAM_SCRATCH_SIZES = [ 65536 ]; DSKT2.SARAM_SCRATCH_SIZES = [ 65536 ]; </syntaxhighlight>

That's fine. This size (65536) is larger than the biggest of both H.264 encode and decode codecs. This works.

However if you are a system integrator with 20+ codecs it can get tedious to go check the ce/MODULE.xs of every codec. Let's see if we can use CE_DEBUG=2 to detect problems.

First thing is to run the working setup with CE_DEBUG=2. But before that we need to turn on DSKT2 trace in the combo to dump more detailed memory trace information: - <syntaxhighlight lang='javascript'> DSKT2.trace = true; </syntaxhighlight>

And after a rebuild of the servers, we run it via: - <syntaxhighlight lang='bash'> CE_DEBUG=2 ./encodedecoded -t 5 > tmp.txt </syntaxhighlight>

Analyzing the tmp.txt trace dump we see: -

[DSP] @0,053,904tk: [+0 T:0x8b80006c] CV - VISA_create(0x0, 'h264dec', 0x8fe05cc0, 0x836, 'ti.sdo.ce.video.IVIDDEC')
...
[DSP] @0,055,355tk: [+4 T:0x8b80006c] ti.sdo.fc.dskt2 - DSKT2_createAlg3> Requested memTab[1]: size=0xf480, align=0x80, space=IALG_DARAM0, attrs=IALG_SCRATCH
...
[DSP] @0,126,012tk: [+4 T:0x8b80006c] ti.sdo.fc.dskt2 - DSKT2_createAlg3> Allocated memTab[1]: base=0x11f04000, size=0xf480, align=0x80, space=IALG_DARAM0, attrs=IALG_SCRATCH
...
...
[DSP] @0,207,816tk: [+0 T:0x8b80006c] CV - VISA_create(0x0, 'h264enc', 0x8fe05cc0, 0x828, 'ti.sdo.ce.video.IVIDENC')
...
[DSP] @0,208,907tk: [+4 T:0x8b80006c] ti.sdo.fc.dskt2 - DSKT2_createAlg3> Requested memTab[1]: size=0xfd00, align=0x80, space=IALG_DARAM0, attrs=IALG_SCRATCH
...
[DSP] @0,231,264tk: [+4 T:0x8b80006c] ti.sdo.fc.dskt2 - DSKT2_createAlg3> Allocated memTab[1]: base=0x11f04000, size=0xfd00, align=0x80, space=IALG_DARAM0, attrs=IALG_SCRATCH

One observation is that the real internal scratch requirements of the H.264 decode is 0xf480 (62592) i.e. more than the 49152 reported by the codec in its ce/H264DEC.xs - that's a bug (which will be reported!). However since we set DSKT2.DARAM_SCRATCH_SIZES[] larger all is well.

Now let's break it in order to understand how to diagnose such problems!

Let's change the server loopback.cfg to : - <syntaxhighlight lang='javascript'> DSKT2.DARAM_SCRATCH_SIZES = [ 62*1024 ]; DSKT2.SARAM_SCRATCH_SIZES = [ 62*1024 ]; </syntaxhighlight>

i.e. a scratch buffer that's big enough for decode but not for encode!

The first piece of good news is that we get a warning in the build. Don't ignore this!

Warning:  Alg "h264enc" DARAM scratch size exceeds engine configuration for groupId 0
Warning:  Alg "h264enc" SARAM scratch size exceeds engine configuration for groupId 0

If we fail to act on this what happens? Again using CE_DEBUG=2 we now see: -

[DSP] @0,049,630tk: [+0 T:0x8b80006c] CV - VISA_create(0x0, 'h264dec', 0x8fe05cc0, 0x836, 'ti.sdo.ce.video.IVIDDEC')
...
[DSP] @0,051,013tk: [+4 T:0x8b80006c] ti.sdo.fc.dskt2 - DSKT2_createAlg3> Requested memTab[1]: size=0xf480, align=0x80, space=IALG_DARAM0, attrs=IALG_SCRATCH
...
[DSP] @0,122,123tk: [+4 T:0x8b80006c] ti.sdo.fc.dskt2 - DSKT2_createAlg3> Allocated memTab[1]: base=0x11f04000, size=0xf480, align=0x80, space=IALG_DARAM0, attrs=IALG_SCRATCH
...
...
[DSP] @0,725,708us: [+0 T:0x424c1b60] CV - VISA_create(0x515d8, 'h264enc', 0x424c13e8, 0x828, 'ti.sdo.ce.video.IVIDENC')
...
[DSP] @0,203,358tk: [+4 T:0x8b80006c] ti.sdo.fc.dskt2 - DSKT2_createAlg3> Requested memTab[1]: size=0xfd00, align=0x80, space=IALG_DARAM0, attrs=IALG_SCRATCH
...
[DSP] @0,204,589tk: [+0 T:0x8b80006c] ti.sdo.fc.dskt2 - _DSKT2_useSharedScratch> Exit (status=FALSE)
...
[DSP] @0,227,054tk: [+4 T:0x8b80006c] ti.sdo.fc.dskt2 - DSKT2_createAlg3> Allocated memTab[1]: base=0x8bd39c00, size=0xfd00, align=0x80, space=IALG_ESDATA, attrs=IALG_PERSIST

Since there wasn't enough internal scratch allocated via the DSKT2.DARAM_SCRATCH_SIZES[] DSKT2 executed a fall back path to allocate from external memory. _DSKT2_useSharedScratch failed to allocate from the existing internal scratch buffer, and thus used external memory. That makes sense however many intensive video codecs simply can't operate with external scratch buffers - many frames get dropped and things go downhill rapidly!

So, in summary, the troubleshooting tips are: -

• Use CE_DEBUG (available in CE >= 2.0)
• Use DSKT2.trace to get detailed memory allocation information.
• Give thought to your settings for the scratch groups in DSKT2.DARAM_SCRATCH_SIZES[] and DSKT2.SARAM_SCRATCH_SIZES[]. Make them big enough.

Caveats?

• There is an Engine_open(), trace-related race condition in Codec Engine which, in multi-threaded applications concurrently calling Engine_open() with remote codecs, may not enable the DSP-side trace "quick enough". This may prevent the memTab[] initialization info from being printed under CE_DEBUG=2. The work-around is to serialize the thread's initial calls to Engine_open() so the first thread's call returns before any subsequent Engine_open() calls are made. This only affects trace enabling - and therefore debugging with CE_DEBUG; it does not affect any functionality.

Debugging - I've run out of internal scratch for key video algorithms

Scenario : you have an audio and a video algorithm - the latter is often scratch memory hungry. For example on DM644x some of TI's video codecs consume ~62K of 64K internal scratch.

So naturally you setup your server cfg file as follows: -

<syntaxhighlight lang='javascript'> Server.algs = [

   {name: "h264dec", mod: H264DEC, groupId: 0,threadAttrs: {
       stackMemId: 0, priority: Server.MINPRI + 1}
   },
   {name: "aacdec", mod: AACDEC, groupId: 1,threadAttrs: {
       stackMemId: 0, priority: Server.MINPRI + 2}
   },

];

DSKT2.DSKT2_HEAP = "DDR2"; /* alloc misc non-alg objects in ext heap */ DSKT2.ALLOW_EXTERNAL_SCRATCH = true; /* allow for external scratch for non-critical algos */

/* Scratch group 0 */ DSKT2.DARAM_SCRATCH_SIZES[0] = 62*1024; /* >= Video alg scr size */ DSKT2.SARAM_SCRATCH_SIZES[0] = 62*1024;

/* Scratch group 1 */ DSKT2.DARAM_SCRATCH_SIZES[1] = 20000; /* >= Audio alg scr size */ DSKT2.SARAM_SCRATCH_SIZES[1] = 20000; </syntaxhighlight>

In most cases this works fine. However in some apps it will fail. Why? The answer is because if you create the audio algorithm first it will dedicate 20000 bytes for the audio groupId = 1. DSKT2 will by default try and allocate this from internal memory first assuming that you set your DSKT2 DARAM and SARAM configuration parameters to internal memory (as most people do).

You can turn on debug and trace as per FC_Config_Updates instructions and it will clearly show this.

<syntaxhighlight lang='javascript'> //Use the DSKT2 library built with debug profile and no trace xdc.loadPackage('ti.sdo.fc.dskt2').profile = "debug_trace"; </syntaxhighlight>

In this case we require the video algorithm to get the scratch. Audio is less CPU intensive - we can live with these algorithms getting external scratch instead.

The solution therefore is to force the audio algorithm to use external scratch no matter what the create() call ordering is.

If we look at AUDDEC1_create() (or any other VISA create API) there is support to achieve what we desire.

Note - if this link fails/change just go to Codec Engine Release Notes -> Documentation -> API Ref Guide -> AUDDEC1 Interface

Under AUDDEC1_create we find exactly the feature we need: -

In general, name is the name of the codec configured by the system integrator.
However, an optional "argument string" may be appended to the codec name, to allow the
codec's configured priority and/or the heaps where its memory will be allocated, to be overridden.
This optional argument string is of the form ":priority", ":priority:flag", or "::flag".

priority is the new priority to create the codec with.

The flag must be either 0 or 1, and if 1, all memory allocated for the codec will be in the heap that
corresponds to IALG_EXTERNAL. If flag is 0, the memory for the codec will be allocated from the heaps
it has requested. For example, if a codec named "mp3" has been configured into the system, setting name to
"mp3:4" would cause the codec to be created at priority 4, instead of whatever priority was configured.
This feature is useful if more than one instance of the codec are to be created at different priorities.

The flag can be used to prevent the codec from using any internal memory, for example, if it is to be run
at the same time as another codec that must use internal memory, and there is insufficient internal
memory for both.

Perfect. So in this case we [application writer] would do: -

<syntaxhighlight lang='c'>

aud1Hdl = AUDDEC1_create(aud1Eng, "aacdec::1", aud1Params);

</syntaxhighlight>

Now our AAC decoder will use external memory for scratch (no matter what the algorithm actually requested) leaving all the internal memory for video scratch.

Note - for this to work the external heap must also be configured to truly use external memory via e.g.

<syntaxhighlight lang='javascript'> DSKT2.ESDATA = "DDRALGHEAP"; </syntaxhighlight>

More Info

See DSKT2 User's Guide or Memory_management_in_XDAIS_with_DSKT2 for more details on DSKT2. Note that the Codec Engine framework uses the DSKT2 APIs internally, so the API descriptions are not so important; however, the concepts behind scratch groups and configuration are still relevant.

DMAN3 configuration in Codec Engine's configuration file

DMAN3 is a module that is used for DMA resource management for codecs. To configure it, first set the heapInternal and heapExternal to memory sections with the corresponding heaps. These are used by DMAN3 for all private objects.

Code Example: <syntaxhighlight lang='javascript'> /* ... in your .cfg script */ DMAN3.heapInternal = "L1DSRAM"; DMAN3.heapExternal = "DDR"; </syntaxhighlight>

Be aware that DMAN3 takes up PaRam 0 for its internal use (as a 'nullparam') by default, hence it must not be assigned for use for anything else.

Set paRamBaseIndex, numQdmaChannels, qdmaChannels, numPaRamEntries, tccAllocationMaskL, tccAllocationMaskH to set the resources to be managed by DMAN3.

Code Example: <syntaxhighlight lang='javascript'> // DMAN3 will inclusively manage PaRAMs 78-125, QDMA channels 0-7, tcc's 32-63 DMAN3.paRamBaseIndex = 78; DMAN3.numPaRamEntries = 48; DMAN3.numQdmaChannels = 8; DMAN3.qdmaChannels = [0,1,2,3,4,5,6,7]; DMAN3.tccAllocationMaskL = 0; DMAN3.tccAllocationMaskH = 0xffffffff; </syntaxhighlight>

Note that DMAN3 works based on a division of codecs into different scratch groups, in which all members share the same scratch resources. There is more info on group ids here.

If you have access to the source code of the algorithm, set numTccGroup and numPaRamGroup for each group id according to the numWaits and numTransfers fields in the IDMA3 requests from the algorithm:

• numTccGroup[i] >= max{sum(numWaits requested by an algo)} among all algos in group i
• numPaRamGroup[i] >= max{sum(numTransfers requested by an algo)} among all algos in group i
• # bits set to 1 in tccAllocationMaskH and tccAllocationMaskL >= sum(all numTccGroups)
• numPaRamEntries >= sum(all numPaRamGroups)

If you don't have the data for numWaits and numTransfers, ask the codec producer. Alternatively, for CE version 2.00 or above, you can set

<syntaxhighlight lang='javascript'> DMAN3.trace = true; </syntaxhighlight>

in your server's cfg file, rebuild it and then run an application that creates the codec instance after setting the environment variables

TRACEUTIL_DSP0TRACEMASK="ti.sdo.fc.dman3=01234567", TRACEUTIL_REFRESHPERIOD=200 and TRACEUTIL_DSP0TRACEFILE="". (You can also run the application with CE_DEBUG set to 2 to see the DMAN3 trace, though the trace would be more verbose.) During algorithm creation, the DMAN3 trace shows the DMA resources being requested by the algorithm, and you can use that information to determine numTccGroup and numPaRamGroup for each group. For example:

@0x00106866:[T:0x88b665f4] ti.sdo.fc.dman3 - DMAN3_grantDmaChannels> Alg 0x88100280:
@0x0010689e:[T:0x88b665f4] ti.sdo.fc.dman3 - DMAN3_grantDmaChannels> Total Channels requested 6, PaRams requested 35, Tccs requested 6

The above trace snippet indicates that this algorithm/codec instance requested a total of 35 PaRam entries and 6 Tccs. So the group in which this algorithm belongs to (let's say it is in group i) must have at least numTccGroup[i] >= 6 and numTccGroup[i] >= 35.

If you are working on a system with ARM + DSP, it is important to ensure the PaRam entries, TCCs and QDMA channels do not conflict with ARM-side usage. If you are running Montavista Linux on the ARM, you can check out the file /opt/mv_pro_4.0/montavista/pro/devkit/lsp/ti-davinci/arch/arm/mach-davinci/dma.c to find out the DMA resources reserved for use for ARM side drivers.

When constrained in amount of internal memory heap space:

• Set DMAN3.idma3Internal to false to force DMAN3 to allocate logical DMA channel representations in the internal heap.
• Use shared scratch buffer in DSKT2 to allocate the protocol environment objects as follows:

<syntaxhighlight lang='javascript'> DMAN3.scratchAllocFxn = "DSKT2_allocScratch"; DMAN3.scratchFreeFxn = "DSKT2_freeScratch"; </syntaxhighlight>

Debugging

In Framework Components 1.x, you can configure DMAN3.debug to true during development to enable obtain some tracing information and/or to insert debug symbols for this module. Simply add a line to the server's .cfg file:

<syntaxhighlight lang='javascript'> var DMAN3 = xdc.useModule('ti.sdo.fc.dskt2.DMAN3'); DMAN3.debug=true; //Add this line </syntaxhighlight>

In Framework Components 2.x, an additional config param, DMAN3.trace, has been added. It's orthogonal to DMAN3.debug, meaning you can have all permutations of trace on/off and debug on/off. It also means that the FC 1.x interpretation of DMAN3.debug = true; providing trace statements is no longer applicable. FC 2.x users wishing to enable trace need to explicitly set

<syntaxhighlight lang='javascript'>DMAN3.trace = true;</syntaxhighlight>.

DMAN3 trace lists out all IDMA3 requests from each codec instance and computes total number of Params, QDMA channels and TCCs allocated for each. This information is useful for determining how much DMA resources should be set aside for DMAN3.

More details on syntax in newer releases are here: FC_Config_Updates#Debug_and_Trace_settings

More info

See Using DMA with Framework Components for C64+ for more detail on DMAN3. It is more than you ever need to know since CE automatically calls the DMAN3 APIs.

Defining a server in the Codec Engine configuration

If you have a heterogenous platform, the DSP is considered to be a server for the ARM. To define a server, simply configure the stackSize and priority of the remote messaging server task, and list out all the algorithms to be included as part of it in Server.algs.

Code Example: <syntaxhighlight lang='javascript'> var Server = xdc.useModule('ti.sdo.ce.Server'); Server.threadAttrs.stackSize = 16384; // Stack size of Codec Engine's remote messaging server task. Server.threadAttrs.priority = Server.MINPRI; var VIDDEC_COPY =

   xdc.useModule('ti.sdo.ce.examples.codecs.viddec_copy.VIDDEC_COPY');

Server.algs = [

   // List all codecs that are part of this DSP server
   {name: "viddec_copy",  //Pick a name for this codec
    mod: VIDDEC_COPY,     //Specify the module to be used
    groupId: 0,           //Specify which scratch group this codec belongs to
    threadAttrs: {
       stackMemId: 0,     //heapid for stack allocation of the task running the codec. 0 is the BIOS object heap.
       stackSize: 4096,   //Stack size of the task running the codec
       priority: Server.MINPRI + 1   //Priority of the task running the codec
    }
   },

]; </syntaxhighlight>

Note that if the application resides on the DSP, then the DSP is no longer a server. Hence an 'Engine' should be created instead, as detailed in the 'Application configuration' section. The groupId and threadAttrs can then be specified as part of the 'Engine' definition.

Other notes

Over time, old configuration parameters have evolved and new configuration parameters have been added. For a summary of changes to configuration parameters, see the Codec Engine Configuration Updates article.

See Also

• Codec Engine GroupIds
• Codec Engine StackMemIds
• Codec Engine Server Integrator's Guide