Main Content

Overview of CLA Configuration for C2000 Processors

The control law accelerator (CLA) is a coprocessor available with the TI C2000™ processor that allows parallel processing. Utilizing the CLA for time-critical tasks frees up the main CPU to perform other system and communication functions concurrently.

These sections explain:

CLA Task

A CLA Task block is used here to trigger a CLA task. This block runs the downstream function-call subsystem on the CLA. In the block mask of the CLA Task block, specify the CLA task number and the associated interrupt triggering source. Ensure that you are using the CLA Trigger block from the library corresponding to your hardware board selected in the Configuration Parameters. CLA task trigger source options are different for different processors. The downstream function-call subsystem is executed using the selected CLA Task when the selected interrupt triggers. For more, see C28x CLA Task.

For example, CLA Task1 is used and Software is selected as the trigger source, which means that the CLA task is triggered at the sample rate provided in the sample time parameter.

Interrupt Generation after CLA Task Completion

A CLA interrupt can be generated when the CLA Task completes. CLA Task1 interrupt is used as the interrupt source on the C28x Hardware Interrupt block. The function-call subsystem triggered by the Hardware Interrupt block with CLA task interrupt (CPU = 11, PIE = 1-8) is executed at the end of the CLA task when the particular interrupt occurs.

Note

When a CLA Task is triggered by an interrupt other than software, ensure that the interrupt gets cleared at the end of the CLA task. This is achieved automatically when you use Hardware Interrupt block with CLA end of the task interrupt or the CLA source trigger interrupt.

CLA Subsystem

A CLA Subsystem block contains a subset of blocks within a model or system. CLA Subsystem is a triggered subsystem which is caused by a CLA Task block.

CLA Subsystem block can only be used along with CLA Task block. For more, see CLA Subsystem.

CLA Subsystem requires you to load tic2000demospkg package in the model with a valid TI C2000 based hardware board.

  • Open Configuration Parameters > Hardware Implementation > Hardware board and change the parameter to a valid TI C2000 board.

  • After selecting TI C2000 hardware board, click Manage packages > Refresh > Load from Embedded coder dictionary app to load tic2000demospkg. For more information, see Data Exchange Between CLA and C28x CPU.

Method 1 - Nonreusable Function Code Generation for CLA Subsystem (Recommended)

In the CLA Subsystem block, the Function packaging parameter on the Code Generation tab is set to is Nonresuable by default. To open the block parameters, right-click on the CLA subsystem and select Block Parameters(Subsystem).

Note

This method requires tic2000demospkg package to be loaded in the model with TI C2000 hardware board. For more, see Data Exchange Between CLA and C28x CPU.

  • The CLA Subsystem block generates the CLA algorithm code as a separate .C file along with the data.

    The initialize/terminate functions are prefixed with compiler directives so it is compiled with only C complier and execution functions prefixed to ensure that it gets compiled by CLA compiler.

  • The constants, parameters, and internal data are configured automatically to be stored in Cla1DataRAM.

  • Save only the input signals from CPU to CLA as a signal and store them in the CpuToCla1MsgRAM storage class using the Code Mappings editor.

  • Use this method to Monitor & Tune (External mode) signals outside the CLA subsystem.

Compatibility Considerations

The Nonreusable Function Code Generation for CLA Subsystem feature is available starting R2021b.

Method 2 - Inline Code Generation for CLA Subsystem

In the CLA Subsystem block, select the Function packaging as Inline under the Code Generation tab of the Block Parameters. To open the Block Parameters, right-click on the CLA subsystem and select Block Parameters(Subsystem).

  • In this method, the entire algorithm inside CLA gets inlined and is part of CLA task file (cla_task.cla).

  • All the input signals to the CLA must be configured manually to store CpuToCla1MsgRAM storage class.

  • All the output signals from the CLA to CPU configured manually to store Cla1ToCpuMsgRAM storage class.

  • All discrete state variables used inside CLA function-call subsystems configured manually to store Cla1DataRam. For example, delay blocks and integrators must be set to use the Cla1DataRam storage class for state variables. See the State Attributes of the Delay block inside cla_subsystem in c28035blink_cla.slx example.

  • With this method, you cannot perform Monitor & Tune (External mode) for the signals outside CLA subsystem.

Data Exchange Between CLA and C28x CPU

CLA storage classes can be loaded in the model (Embedded Coder > Code Interface > Embedded Coder Dictionary > Manage Packages) as shown.

The Code Mappings editor is the primary location to configure model data elements for code generation. For more information, refer to Code Mappings Editor – C (Simulink Coder).

All the interfaces between the CLA and the CPU need to be placed in specific memory sections. To gain specific access to these sections, Select Embedded Coder > Code Mappings > Data stores and Signal/States for CpuToCla1MsgRAM and Cla1ToCpuMsgRAM. For more information, refer to Code Mappings Editor – C (Simulink Coder).

Memory Section Data

The data in the model is stored in the various memory sections which has the following access rules.

Memory Section

CPU

CLA

CpuToCla1MsgRAMRead & WriteRead only
Cla1ToCpuMsgRAMRead onlyRead & Write
Cla1DataRAMRead & WriteRead & Write

Memory Section Code

The functions with the following memory section are prefixed with compiler directives to control the compilation of the code.

  • C28xFunction is compiled by C28x compiler

  • ClaFunction is compiled by CLA compiler.

The following figures show the configurations of specific memory section between CPU and CLA in the model.

Code Mappings

Required Model Configuration When Using CLA

In Model Configuration Parameters > Code Generation > Optimization, the Default parameter behavior parameter must be set to Inlined. This avoids the creation of model structure global variables, as CLA cannot access global data.

Change Standard Linker Command File

For F28035 and F28069 processors, a specific linker command file has to be selected to assign CLA memory sections. In the Model Configuration Parameters, under Hardware Implementation > Target hardware resources > Build options, and select Use custom linker command file. A preconfigured c28069_cla.cmd is used as linker command file. This file adds CLA memory sections description and can be found in the src directory at the root of the support package installation.

Debug CLA

The debug function /*__mdebugstop()*/ is present at the beginning of the CLA task (__interrupt void Cla1Task1 ( void )) in the generated cla_task.cla file.

  1. Enable the debug function __mdebugstop() by removing the block comments around it.

  2. Compile the source code or build the CCS project.

  3. For debug instructions visit: https://www.ti.com/microcontrollers-mcus-processors/microcontrollers/c2000-real-time-control-mcus/overview.html#Debugging

CLA Limitations and Troubleshooting

Limitations

You need to follow certain modeling practices because of specific interactions between the CLA and the C28x CPU and because of CLA C compiler limitations.

  • Only a C28x event can trigger the CLA application code. The C28x CPU can trigger a CLA Task via software or by using different peripheral interrupts.

  • Place all the interfaces between the CLA and the CPU in specific memory locations. Use the CpuToCla1MsgRAM memory section to exchange data from the C28x to the CLA. Use the Cla1ToCpuMsgRAM memory section to exchange data from the CLA to the C28x.

  • The CLA application code does not have access to global variables.

  • Recursive function calls are not supported.

  • The CLA C compiler does not support integer division and integer unsigned comparison. Use MATLAB function to access CLA math library functions provided by TI for the above operation.

  • You cannot use more than one instance of DAC block with same module when one instance is used inside CLA.

  • SPI, CAN and SCI blocks are not supported inside CLA.

  • The blocks which create reset functions cannot be used inside CLA. It is not possible to control the definition and compilation of the reset function to CLA core from Simulink. For example, PID integrator and conditional blocks which resets the states.

  • When you use constants inside MATLAB function, it is stored in constant section of C28x which CLA is unable to access. You can overcome this problem by using constants in Simulink with proper storage classes configured and using the same as input to MATLAB function.

For more details and an exhaustive list of limitations visit: https://www.ti.com/microcontrollers-mcus-processors/microcontrollers/c2000-real-time-control-mcus/overview.html

Consider these limitations when creating a model in Simulink®.

Other Guidelines to Consider While Using CLA

Avoid the creation of sub-functions using atomic subsystems inside CLA function-call subsystems as this creates nested functions that are not supported on the CLA.

Certain CLA configurations might require more operations on the model or might prevent you from using Simulink features. See the list of limitations provided in the CLA C compiler documentation. Use the Embedded Coder supported features to restrict the generated code in the limited syntax supported by the CLA C compiler.

Troubleshooting

  • Ensure that the Code Generation Tools version your are using supports the CLA C Compiler.

  • Ensure that you have installed the latest C/C++ header files with CLA support on your system.

See Also

|

Related Topics