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.
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.
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 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
Save only the input signals from CPU to CLA as a signal and store them in the
CpuToCla1MsgRAM storage class using the Code Mappings
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.
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
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
With this method, you cannot perform Monitor & Tune (External mode) for the signals outside CLA subsystem.
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).
The data in the model is stored in the various memory sections which has the following access rules.
|CpuToCla1MsgRAM||Read & Write||Read only|
|Cla1ToCpuMsgRAM||Read only||Read & Write|
|Cla1DataRAM||Read & Write||Read & Write|
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.
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.
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
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.
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®.
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.