Using the Control Law Accelerator (CLA)
This example shows how to use the Control Law Accelerator (CLA) available on some of the TI Piccolo processors.
For the LED blinking model:
- TI® Piccolo F28069, F28035, F28004x or Delfino F28377S board.
For the motor control application model:
- TI® DRV8312 Three-Phase Brushless Motor Control Kit (DRV8312-C2-KIT or DRV8312-69M-KIT) with F28035 or F28069 Piccolo processor
- Three-phase PMSM with Hall sensors attached to connector J10 of the DRV8312EVM board
Available versions of example models:
- F28035 Piccolo: c28035blink_cla.slx
- F28069 Piccolo: c28069blink_cla.slx
- F28377S Delfino: c28377Sblink_cla.slx
- F28004x Piccolo: c28004xblink_cla.slx
- F28069 Piccolo: c28069_dataintegrity_cla.slx
- F28379D Delfino: c28379D_dataintegrity_cla.slx
- F28379D Delfino Launchpad: c28379D_cpu1_blink_cla.slx, c28379D_cpu2_blink_cla.slx
- DRV8312 + F28069 Piccolo: c28069pmsmfoc_cla.slx
- DRV8312 + F28035 Piccolo: c28035pmsmfoc_cla.slx
Copyright 2013-2018 The MathWorks.
Task 1: Using the CLA with an LED Blinking Example
The following figure shows an example model configured to use the CLA available on the hardware.
This model generates code for a Simulink model where one part of the algorithm runs on the Control Law Accelerator (CLA) available on the device. The CLA is a co-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.
The following section shows how to trigger a CLA task, exchange data from the C28x CPU to the CLA using memory sections like CpuToCla1MsgRAM and Cla1ToCpuMsgRAM, schedule C28x interrupts at the end of the CLA task, and replace the standard linker command file to include CLA specific linking attributes.
CLA Task Block
In the c28069blink_cla.slx model, a CLA Task block is provided to trigger a CLA task. This block runs the downstream function-call subsystem on the CLA. On the CLA Task block mask, you can specify the CLA task number and the associated interrupt triggering source. Ensure that you are using the CLA Trigger block from the library matching the 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. In this 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.
Select Inline Code Generation for CLA Subsystem
For the CLA task subsystem, 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)".
Changing the 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, "Use custom linker command file" is selected and the pre-configured "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.
Interrupt Generation after CLA Task Completion
A CLA interrupt is generated when the CLA Task completes. CLA Task1 interrupt (CPU = 11, PIE = 1-8) is used as the interrupt source on the C28x Hardware Interrupt block. The function-call subsystem 'System executes at completion of CLA Task1' is executed when the interrupt occurs. GPIO pin 34 (connected to the LED on control cards; for LaunchPad boards the GPIO pin number is different) toggles on every occurrence of the CLA Task1 interrupt.
Data Exchange between the CLA and the C28x CPU
All the interfaces between CLA and CPU need to be placed in specific memory sections. To gain specific access to these sections, custom storage classes CpuToCla1MsgRAM and Cla1ToCpuMsgRAM are defined in the dataclass package tic2000demospkg.
Model Configuration Required while Using the CLA
In Model Configuration Parameters > Code Generation > Optimization, the Default parameter behavior parameter must be set to Inlined. This is to avoid the creation of model structure global variables, as CLA cannot access global data.
Discrete State Variables
All discrete state variables used inside CLA function-call subsystems must be stored in 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 for an example.
Other Guidelines to Consider while Using the CLA
Avoid the creation of sub-functions provided on atomic subsystems inside CLA function-call subsystems as this creates nested functions that are not supported on the CLA.
The specificity of the CLA may require more operations on the model or may prevent the use of Simulink features. Make sure to go through the list of limitations provided in the CLA C compiler documentation. Make sure to use the features of Embedded Coder to restrict the generated code in the limited syntax supported by the CLA C compiler.
Run the Model
- Open the example model, c28069blink_cla.slx, c28035blink_cla.slx, c28004xblink_cla.slx, c28377Sblink_cla.slx, c28379D_cpu1_blink_cla.slx, or c28379D_cpu2_blink_cla.slx.
- Open Model Configuration Parameters and select the required tool chain on the Code Generation pane.
- Press Ctrl+B to build a binary executable and to automatically load and run the executable on the selected target.
Task 2: Debug Code on the 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.
- Enable the debug function __mdebugstop() by removing the block comments around it.
- Compile the source code or build the CCS project.
- For debug instructions visit: http://processors.wiki.ti.com/index.php/C2000_CLA_C_Compiler#Debugging
Task 3: Ensure Data Integrity Between CPU and CLA
Data integrity issues may occur when:
- The data tranfer is not atomic. For example, data transfers where the data size is more than the atomic size (uint16).
- Tasks are not synchronized. For example, the CLA is triggered asynchronously.
- Sample time of the CPU and the CLA are different.
To ensure data integrity, data must be protected either using a double buffer algorithm or by synchronizing both the CPU and the CLA.
In this model, the CPU and the CLA are not syncrhonized because the CLA is triggered asynchronously using an ePWM interrupt. To ensure data integrity, a double buffer algorithm along with control flags (Read_index and Write_index) are used.
In the double buffer algorithm, two buffers are used for data exchange. The CPU checks the buffer that is being read by the CLA using the Read_index flag and writes the data to the other buffer. Similarly, the CLA checks the buffer that is being written by the CPU using the Write_index flag and reads the data from the other buffer.
By using the double buffer logic, data integrity is ensured even though the CPU and the CLA are not synchronous.
Run the Model
- Open the c28069dataintegrity_cla.slx model.
- Click Deploy to Hardware or press Ctrl+B to build and download the executable file on the CPU.
Task 4: Permanent Magnet Synchronous Motor Field-Oriented Control (FOC) Using CLA
The following figure shows a Permanent Magnet Synchronous Motor Field-Oriented Control (FOC) example model, which runs the FOC algorithm on the CLA.
This model implements the Field-Oriented Control (FOC) of a Permanent Magnet Synchronous Motor using the CLA. The FOC algorithm is implemented with a CLA Task and PWM duty cycles are refreshed on completion of CLA Task using the corresponding interrupt. This example requires a DRV8312 kit with an F28069 or F28035 Control card. This example is an extension of docid:texasinstrumentsc2000_examples.example-c28069pmsmfoc_ert, with the usage of CLA. All the considerations listed in the blinking LED example are applied in this example.
In this model, data integrity is ensured by synchronizing the CPU and the CLA. The CLA is software triggered using the sample time inherited from the inputs. The Simulink scheduler ensures that all inputs are ready before the CLA subsystem is triggered.
Run the Model
Specific interactions between the CLA and the C28x CPU along with CLA C compiler limitations force the modeling practices to be followed. Below is a list of concepts that reflects modeling practices described in this example:
- The CLA application code can only be triggered by a C28x event. CLA Task can be triggered by C28x CPU via software or by different peripheral interrupts.
- All the interfaces between CLA and CPU need to be placed in specific memory locations. The CpuToCla1MsgRAM memory section is used to exchange data from the C28x to the CLA. The Cla1ToCpuMsgRAM memory section is used to exchange data from the CLA to the C28x.
- The CLA application code does not have access to global variables.
- Early versions of the CLA C compiler support only 2 levels of function calls. CLA interrupt service routines may call leaf functions only. Leaf functions may not call other functions.
- Recursive function calls are not supported.
- Integer division, modulus, and integer unsigned comparison are not supported with the CLA C compiler.
For more details and an exhaustive list of limitations visit: http://processors.wiki.ti.com/index.php/C2000_CLA_C_Compiler
These limitations must be considered when modeling in Simulink.
- Ensure that the Code Generation Tools version used supports the CLA C Compiler.
- Ensure that the latest C/C++ header files with CLA support are installed on your system.