OLEA® T222 - FPCU (4)
A mathematical accelerator is a module which allows to compute square root, division and performs trigonometric functions.
In addition, this module embeds an MCR (Matrix–multiplication/Cordic/Regulator) which has been designed to perform 3
types of computation which can be chained:
• M: Matrix multiplication (Ai*Bi+Aj*Bj…)
• C: Cordic algorithm for trigonometric operations
• R: Regulator of type PID (Proportional/Integral/Derivative)
The OLEA® LIB – T222 MATH provides the user an access to these hardware mathematical accelerators
Calibration parameters of the Flexible Logic Unit (FLU) are stored inside the DPRAM.
Use the genertaed file ram_logger.csv to get the offset address of the parameters you want to change e.g. Ki and Kp.
Open a memory window at address 0x60000000 (base address of the DPRAM) in your debugger and change the Ki and Kp as wanted.
Then in the APB FLU slave, in register CR set the bit 2 for the calibration to be applied on the FLU algorithm: Open a memory window at address 0xC4074000 and write at offset 0x60 the value 0x4.
OLEA® T222 - SDK (1)
The OLEA® T222 includes a complete set of features to facilitate software development debug, calibration and measurements.
The Debug Access Port (DAP) in combination with the Trace Port Interface Unit (TPIU) enables the tracing of all the FPCU
memory map and module events. These traces can be accessed by different interfaces, including the SWD and the TPIU.
Calibration of constant data is done using 16KB of Overlay RAM. The AMEC® DPRAM could also support the FLU algorithms
calibrations. OLEA® T222 implements a non intrusive calibration which do not affect the application execution.
OLEA® T222 - Target Framework (5)
To understand, improve or debug a FLU model on Hardware, the user requires access to the internal signals at every FLU-iteration (i.e. at the Data rate). Any signal within the main FLU model can be requested to be logged.
In order to trace a signal (wire), the following conditions should be respected:
– The signal must be directly connected to the output port of a standard subsystem (not a library block).
– The user shall activate the signal logging: right click on a wire, select “Properties”, tab “Logging and accessibility” and then tick “Log signal data”.
The framework will list logged signals and create a structure containing them.
At every main FLU model iteration, the signal values will be copied at their relevant addresses within the DPRAM.
During algorithm development, parameters need to be tuned and changed on the fly. To define a parameter as tunable, the user should:
– Make the parameter a data object of type Simulink.Parameter.
– Set the parameter storage class to ExportedGlobal.
Any variable (Simulink.Parameter with its CoderInfo.StorageClass set to ExportedGlobal) will be a candidate for calibration. The framework will list all those variables and create a structure in the DPRAM to store those values.
The Timing generation is meant to compute the delay to apply, within a data rate model, to each block requiring an external resource.
The resources can be DPRAM access, using the ram_controller or peripheral access, using the Sequencer.
This delay is counted in Flu clock cycles and is relative to the start of the algorithm, triggered by the StartPulse signal.
Those delays have no impact on the simulation as they use pipelines (clock rate delays, invisible during data rate simulation).
When you perform a Generate Interface command from the Silicon Mobility menu, all sources are cleaned up. You can also do it manually by following these steps :
- Close Matlab
- Delete all files in Model/SiliconMobility folder except Triggers folder
- Reopen the project