4.10.3 C28x CLA Object Mode

The CLA mode is used when the hardware Control Law Accelerator support is available on the C28x. This mode is available by invoking the compiler with the –v28 and --cla_support=[cla0|cla1|cla2] options, where cla0 indicates a CLA Type 0 device, cla1 indicates a Type 1 device, and so on. The --cla_support option can be specified along with other C28x options, such as those for specifying FPU support. Specifying both FPU and CLA options means that support is available for both types of accelerators. The CLA mode is very similar to the C28x mode (with/without FPU support). The differences are:

• The CLA is similar to a cut-down version of the FPU32 that is optimized to perform math tasks only. Some special floating point instructions are supported. These are documented in TMS320x28xx, 28xxx DSP Peripherals Reference Guide.
• The CLA pipeline is unprotected, but at this time, the tools do not detect pipeline conflicts for the CLA. You need to write CLA instructions in such a way that there are no pipeline conflicts.
• Assembly files containing CLA instructions can also contain C28x and FPU instructions. However, the CLA instructions should always be in a separate, named section. This section cannot contain any non-CLA instructions. Mixing CLA and non-CLA instructions in the same section is illegal and results in an assembler/linker error.
• When a linker command file is written, care must be taken to put all data referenced by CLA instructions within addresses 0-64K. This is because the CLA data read bus only has a 64K address range.
• A linker output section containing a CLA input section cannot contain any non-CLA input sections.
• The CLA mode does not need any special library support. Any of the C28x libraries suffices.
• The name of the section containing CLA instructions should be unique both within the file and across all files that are compiled and linked into the same output file.

The CLA compiler places all CLA function data, arguments, and temporary storage in function frames in the .scratchpad section. Function frame scratchpad sections are named in the form ".scratchpad:functionSectionName". (Each function has its own subsection and therefore a unique section name.) For example: .scratchpad:Cla1Prog:_Cla1Task2 would be the compiler-generated scratchpad section name for a function called Cla1Task2().

The CLA compiler's naming convention for the function scratchpad symbol is of the form __cla_functionSymbol_sp, but this is not required in assembly code.

CLA2 background tasks are placed in the scratchpad with function frame sections of the form ".scratchpad:background:functionSectionName". The background task frame cannot be overlaid with any other function frames, since the background task is likely to be returned to after yielding to interrupts.

The following example shows compiled code with a .sect directive for a CLA function and a .usect directive to identify the function scratchpad frame. This .usect directive identifies the function frame as part of the .scratchpad section and allows the compiler to use overlays when possible. Overlaid function frames use the same physical memory, thereby reducing memory utilization. It is recommended that assembly code follow the ".scratchpad:" naming convention to reduce memory requirements.

.sect "Cla1Prog:_Cla1Task2" .align 2 __cla_Cla1Task2_sp .usect ".scratchpad:Cla1Prog:_Cla1Task2",14,0,1 .global _Cla1Task2 ;*************************************************************** ;* FNAME: _Cla1Task2 FR SIZE: 14 * ;* * ;* FUNCTION ENVIRONMENT * ;* * ;* FUNCTION PROPERTIES * ;* 14 Auto, 12 SOE * ;*************************************************************** _Cla1Task2: [ ... ]

If the CLA function in the example above were a CLA2 background task, the .usect directive would instead identify the scratchpad frame as ".scratchpad:background:Cla1Prog:_Cla1Task2".

See the "CLA Compiler" chapter in the TMS320C28x Optimizing C/C++ Compiler User's Guide for more details.