Profiler

Description

The Profiler measures the processing time required by the SPARK Wireless Core during packet reception and transmission. It evaluates this time across three scenarios: a unidirectional transmission link, a unidirectional reception link and a bidirectional transmission-reception link, each tested over a range of payload sizes. This provides hardware-specific metrics to help optimize the transfers schedule based on application needs. A margin of 10% is recommended on these measurements since some events could increase processing time on some frames (ex: callback events, instruction cache miss, etc…)

The processing time is measured solely on the DUT (Device Under Test), with the Helper performing only the actions instructed by the DUT in order to measure the desired processing time accurately. For each scenario, the average processing time for each payload size is measured and logged.

• Scenario 1: The DUT is configured as the transmitter and the Helper as the receiver, transferring a set of payloads of varying sizes.

• Scenario 2: The DUT is configured as the receiver and the Helper as the transmitter, receiving the same set of payloads with varying sizes.

• Scenario 3: Both the DUT and the Helper operate in a bidirectional configuration, simultaneously transmitting and receiving payloads of different sizes.

Following the same structure as the example applications, users are required to implement a facade layer specific to their hardware.

Tip

For a better understanding of how to design the application’s schedule based on the measured processing time, refer to the Schedule Design Consideration section.

Using Processing Time to Optimize Timeslot Configuration

For a transmission, the processing time occurs immediately after the entire air time, which includes both the transmitted packet and the received ACK. For a reception, the processing time starts as soon as the packet is received, overlapping with the air time of the ACK transmission. The processing time is primarily determined by the duration of the SPI transfer between the radio and the MCU.

Scenario 1: Unidirectional Transmission Link

In a unidirectional transmission link, the SPI transfer is mainly dedicated to setting up the next transmission, which includes sending the packet to be transmitted. The packet will be transmitted once all the configuration as been set in the radio. No CPU cycles are required from this point, meaning that the total processing time increases linearly with the SPI speed and depends on the payload size.

The total processing time will be defined as:

total_processing_time_tx = base_processing_time_tx + (CMD_BYTE + MAC_HDR + nb_tx_byte) * SPI_time_per_byte

Where

• CMD_BYTE is 1 byte.

• MAC_HDR is at least 3 bytes, increasing depending on the Header Configuration.

• base_processing_time_tx refers to the constant processing time required for every transmission, including configuration and CPU cycles.

Figure 65: Processing Time of a unidrectionnal transmission link.

Scenario 2: Unidirectional Reception Link

In a unidirectional reception link, the SPI transfer is mainly dedicated to retrieving the received packet OTA and preparing the next reception. Since some CPU cycles can be executed while the RX payload is received via SPI, the total processing time only increases when the RX payload SPI transfer time exceeds the CPU processing time required for each received frame.

The total processing time will be defined as:

total_processing_time_rx = base_processing_time_rx + max((nb_rx_byte - rx_nb_byte_threshold), 0) * SPI_time_per_byte

Where

• base_processing_time_rx refers to the constant processing time required for every reception, including configuration and CPU cycles. This is shown in the first figure bellow.

• rx_nb_byte_threshold is the RX payload size where the SPI transfer time matches base_processing_time_rx. Beyond this threshold, the total processing time increases.

Figure 66: Base Processing Time of a unidrectionnal reception link (Small RX Payload).

Figure 67: Processing Time of a unidrectionnal reception link (RX Payload > rx_nb_byte_threshold).

Scenario 3: Bidirectional Link

In a bidirectional link, where the transfers alternates between sending and receiving packets, the SPI transfer varies:

• During one timeslot, it involves receiving the packet OTA and preparing the next transmission, which includes transferring the packet to be sent.

• During the following timeslot, the transfer primarily consists of configuring the next reception.

The total processing time that defines the required schedule time is determined by the timeslot with the longest processing duration. It is defined as:

total_processing_time_rx_tx = base_processing_time_rx_tx + (max((nb_rx_byte - rx_nb_byte_threshold), 0) + (CMD_BYTE + MAC_HDR + nb_tx_byte)) * SPI_time_per_byte

Where

• rx-tx refers to the processing of the end of a reception timeslot and the start of a transmission timeslots. This case shows the worst case scenario in terms of processing time.

• base_processing_time_rx_tx refers to the constant processing time required for every transfer, including configuration and CPU cycles.

• rx_nb_byte_threshold is the RX payload size where the SPI transfer time matches base_processing_time_rx in scenario 2. Beyond this threshold, the total processing time increases.

• CMD_BYTE is 1 byte.

• MAC_HDR is at least 3 bytes, increasing depending on the Header Configuration.

Note

In the profiler, the base_processing_time_rx is computed in the scenario 2, as it needs to be calculated with a transfer that consists exclusively of processing time related to reception.

Figure 68: Processing Time of a bidrectionnal link.

Summary

In other words, for a unidirectional application, the processing time depends on the size of the packet being sent or received, since the packet is transferred or received in each timeslot.

However, in a bidirectional application where the timeslots alternate between transmission and reception, only one out of every two timeslots on the DUT is influenced by the packet size. This is because one SPI transfer includes both receiving the OTA packet and preparing the next transmission, which involves transferring the packet to be sent. This scenario represents the worst case in terms of duration, as it includes both packet reception and transmission preparation, while the other transfer is limited to preparing the next reception, remaining mostly short and constant.

It is important to note that the Helper operates in the opposite sequence to the DUT. When the DUT is in a timeslot with a relatively constant and lower processing time, the Helper is handling the worst-case timeslot.

Note

For some tips on how to optimize the processing time, see Porting Optimizations

Terminal

Here is the Profiler’s output on Quasar, which uses UART to display the average processing times for different payload sizes in a terminal emulator on a PC.

Figure 69: Profiler print output example.

Note

The Profiler outputs processing time formulas that can be used by the user to estimate the processing time for a given payload size. This can be used when designing a schedule. See Schedule Design Consideration.