About This Application Note
This ‘Profiling in Audio Weaver’ application note contains instructions for computational and memory profiling of and Audio Weaver Designer (.awd) signal flow in Audio Weaver. The profiling works in real time on a running .awd layout (Figure 1) for both Native (PC) and on embedded targets.
...
This profiling happens while the audio processing is running in real-time. Additionally, there is a manual audio pump feature which does similar profiling but operates in non-real-time.
...
Real Time Profiling
In Audio Weaver, Design Mode refers to a non-running .awd, while Tuning Mode refers to a running .awd layout. You can enter Tuning Mode by clicking the run button in Audio Weaver Designer:
...
The ‘Block by Block’ profiling will provide information MHz and Memory consumption of each individual element of the .awd at the time of the profiling, while ‘Peak’ profiling will provide information about average and peak CPU cycle usage over a user-specified time.
...
Selecting ‘Profile Block by Block’ will automatically run profiling on the entire running .awd layout at the time of selection, while ‘Profile Peak’ is manually started once the desired ‘Sampling Period’ and ‘Test Length” fields are set:
...
Understanding Real Time Profiling Information
Block by Block Profiling
When selecting the ‘Profile Block by Block’ real time profiling option, Audio Weaver will run complete MHz and Memory profiling on the entire audio system signal flow (.awd) and display the profiling information in a pop-up window. The ‘Tick’ mentioned here is the time measured in terms of CPU clock cycles. It can be measured as Tick = (1/CPU Clock Frequency). MHz is the Million Instructions Per Second (MIPS) of the system.
...
Total ticks per block process available (calculated and measured)
Average ticks per block
Instantaneous ticks per block
Peak ticks per block
Total memory usage of the system
Shared heap memory for multi-instance architectures
Profile Block by Block Terminology
The following table describes each field:
...
In a multi-instance architecture, by default the profiling pop-up window displays profiling information for all of the Audio Weaver instances used:
To display profiling information for only one specific Audio Weaver instance, you can do so by selecting the desired Audio Weaver instance from the Instance drop down menu in the upper left-hand corner:
...
Peak Profiling
When selecting the Profile Peak real time profiling option, the Peak Profile Window will pop up:
...
As discussed above, the ‘Sampling Period’ and ‘Test Length’ fields must be entered in order to run the peak profiling. The time unit for both fields are seconds, and the default values are 0.5s sampling period and 10s test length. When ready to start the peak profiling, simply click the ‘Start’ button.
...
The ‘Peak vs Average Cycles’ graph at the top of the Peak Profiling pop-up window displays peak and average CPU usage percentages of the processor Audio Weaver is running on. If the running .awd has a multi-instance architecture or contains multi-threading, multiple profiling measurements for each Audio Weaver instance and thread will also display. The x-axis is time in seconds and the y-axis is CPU percentage:
The bottom portion of the Peak Profiling pop-up window displays a Legend for the Peak vs Average Cycles line graph and an Instance List to select which Audio Weaver instance profiling measurements to display:
...
Manual Profiling
As mentioned earlier in this application note, Audio Weaver also features Manual Profiling, which collects the same exact profiling information as the real-time block by block profiling but in a different manner. Rather than profiling the runtime input audio stream, during manual profiling, real-time processing is halted on the target and all layouts present in the AWD/AWJ signal flow are processed one at a time through tuning commands (pump_layout), for the user specified amount of audio frames. The yielded profiling results may be preferred in some cases, as this decouples discrete layout processing (and thus layout thread priority) from real-time audio device interrupts. This allows for accurate profiling even in cases when the target is not configured for real-time audio, or if a layout is unable to finish executing in the allotted clock cycles (calculated total ticks per block process available).
...
If no audio file is used as input audio data, the Manual Profiler will use audio data from the specified source selected in the Layout Properties.
Exporting Profiling Data to CSV
All the Audio Weaver profiling utilities allow you to export the profiling data to a comma separated value (.csv) file. All three of the profiling windows (Profile Block by Block, Profile Peak, and Manual Profile Layout) have an ‘Export to File’ Button:
...
For multi-instance architectures, every Audio Weaver profiling utility enables users to export either profiling data for all instances or individual profiling data for a selected Audio Weaver instance:
...
For block by block and manual profiling of multi-instance architectures, if profiling data for all instances are selected for export, Audio Weaver will generate one aggregate profiling CSV file and individual CSV files for each Audio Weaver instance in the system:
...
The Profile Peak .csv file is structured as followed, where the Peak and Average Cycle CPU% profile values are indexed by the specified time period in seconds:
...
Profiling Diagrams
Below are some diagrams that further illustrate the real time profiling function in Audio Weaver.
...
CycleBurner, BiquadLoading, and FIRLoading Modules
The CycleBurner, BiquadLoading, FIRLoading and MemoryLoading Modules intentionally consume processing cycles on the target processor. They are useful for load/stress testing.
CycleBurner Module
The CycleBurner intentionally consumes a user-specified number of clock cycles. You can increase the number of clock cycles used by CycleBurner by adjusting the ‘numCyclesPerBlock’ slider of CycleBurner’s inspector. Using this technique we can increase the number of cycles until we start to hear distortion in the program material that is being processed by the signal flow.
...
If a higher priority tasks pre-empt the CycleBurner, the execution time of the CycleBurner will remain constant. This assumes that the module is pre-empted and the pre-emption completes before the Cycle Burner completes.
BiquadLoading Module
The BiquadLoading Module simulates the loading of biquad filters. This module is used for CPU load testing purposes and implements a large number of cascade Biquad filters. At instantiation time, you specify the maximum number of filter stages that you would like to simulate. Then at run-time you can vary the number of filters running. This makes the CPU work harder. Internally, the module uses the BiquadCascade module to implement the filtering.
...
If the BiquadLoading Module is pre-empted, then the execution time of the modules will be increased.
FIRLoading Module
The FIRLoading Module simulates FIR filter loading. This module is used for CPU load testing purposes and implements a large number of FIR filter taps. At instantiation time, you specify the maximum number of filter taps that you would like to simulate. Then at run-time you can vary the number of filter taps. This makes the CPU work harder since more filter taps are running. Internally, the module uses the FIR module to implement the filtering.
...
If the FIRLoading Module is pre-empted, then the execution time of the modules will be increased.
MemoryLoading Module
This module is used to check the memory bandwidth of the target. At instantiation time you specify the size of the memory buffer (memSize) and in which heap it should be allocated (memHeap). Then at run time, the module writes a block counter value into every value of the array. It repeats this blockWriteCount times per block process. That is, every time the processing function is called, the module performs a total blockWriteCount*memSize memory write operations. All write operations write the current value of the block counter.
Additional Notes on Audio Weaver Profiling
Since system and other interrupts can and sometimes will preempt audio processing, every profiling measurement has a first order low pass filter to mitigate preemption spikes. The low pass filters are designed so that the time for the profiling values to stabilize is less than 5 seconds. The output of these low pass filters represents the average cycle profiling numbers.
In order for profiling to be accurate for embedded targets, the AWE Core relies on a suitable operation to retrieve the system cycle count. This operation can be implemented internally in the AWE Core library configuration only if the method supported by the target is known at compile time. If the cycle count retrieve function is not implemented in the AWE Core library configuration, then the user must supply functions that retrieve the system cycle count as part of the application. The core speed and the units of the retrieved cycle counts must be correctly defined by the user for the profiling to be accurate.
Audio Weaver Server Profiling
While an .awd is running in Audio Weaver, the Audio Weaver Server provides real time CPU and Memory profiling of the entire layout:
...
Server Profiling on Multi-CPU Targets
AWE Core may be running in multiple threads on several CPUs in some instances. The application is not aware of which CPU the thread is running on by default. This means that without some extra work, the default display of CPU % cannot be trusted for multi CPU targets as the assumption will be that all threads run on a single CPU.
...