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:
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.
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.
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
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).
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 filealong 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
Save only the input signals from CPU to CLA as a signal and store them in the
CpuToCla1MsgRAMstorage class using the Code Mappings editor.
Use this method to Monitor & Tune (External mode) signals outside the CLA subsystem.
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
inlinedand is part of CLA task file (cla_task.cla).
All the input signals to the CLA must be configured manually to store
All the output signals from the CLA to CPU configured manually to store
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
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 Storage Class
|CpuToCla1MsgRAM||Read & Write||Read only|
|Cla1ToCpuMsgRAM||Read only||Read & Write|
|Cla1DataRAM||Read & Write||Read & Write|
Signal or states with
Cla1ToCpuMsgRAMstorage class will add initialization in the function compiled by CPU (model initialization function) but CPU does not have write access to the above memory section. If initialization is required for a particular variable and needs to be editable by CLA as well, it is recommended to use
For F2803x processor, the
Cla1DataRAMbehave similar to
Cla1ToCpuMsgRami.e. CPU does not have write access to any of the above storage class except
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
ClaFunction is compiled by
The following figures show the configurations of specific memory section between CPU and CLA in the model.
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
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
Profiling with XCP External Mode
When performing profiling with XCP External mode for a model containing CLA subsystem, ensure to disable the parameter Terminate function required under Configuration Parameters > Code Generation > Interface > Advanced parameters.
For a model containing CLA, running profiling with XCP External mode, will not profile the tasks executed in CLA.
CLA LSRAM Memory Configuration
In the Model Configuration Parameters, you can configure the local shared RAM (LSRAM) as CLA program and data memory.
In Model Configuration Parameters, navigate to Hardware Implementation > Target hardware resources > Build options and select Configure CLA program and data memory. For information, refer to C28x-Build Options.
The following table describes the total LSRAM memory available for the processors.
CLA LSRAM Memory Allocation
|Processor||Total LSRAM Memory available in KiloWords (KW)|
The debug function
/*__mdebugstop()*/ is present at the beginning of
the CLA task
(__interrupt void Cla1Task1 ( void )) in the generated
Enable the debug function
__mdebugstop()by removing the block comments around it.
Compile the source code or build the CCS project.
CLA Limitations and Troubleshooting
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.
Constants with sample time as
infand mapped as
Cla1ToCpuMsgRAMis always initialized to
0. Ensure that the sample time for such constant is set to
any positive integer.
For a model containing CLA subsystem running in external mode, the data cannot be logged inside the CLA subsystem. You have to move the data out of the CLA subsystem to monitor the data.
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.
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.