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.

../../_images/unidir_tx_link_timings.svg — Figure 99: 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.

../../_images/unidir_base_rx_link_timings.svg — Figure 100: Base Processing Time of a unidrectionnal reception link (Small RX Payload).

../../_images/unidir_rx_link_timings.svg — Figure 101: 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.

../../_images/bidir_link_timings.svg — Figure 102: 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 SR1120 with SPI, which uses UART to display the average processing times for different payload sizes in a terminal emulator on a PC.

=== Running SWC Profiler ===


SCENARIO 1: Measuring processing time for unidirectional transmission link.

< Payload size: 2 bytes >
        TX Processing Time:  48.231 us
< Payload size: 4 bytes >
        TX Processing Time:  48.638 us
< Payload size: 8 bytes >
        TX Processing Time:  49.431 us
< Payload size: 16 bytes >
        TX Processing Time:  51.044 us
< Payload size: 32 bytes >
        TX Processing Time:  54.169 us
< Payload size: 64 bytes >
        TX Processing Time:  60.562 us
< Payload size: 128 bytes >
        TX Processing Time:  73.438 us
< Payload size: 250 bytes >
        TX Processing Time:  97.838 us

SCENARIO 2: Measuring processing time for unidirectional reception link.

< Payload size: 2 bytes >
        RX Processing Time:  53.062 us
< Payload size: 4 bytes >
        RX Processing Time:  53.050 us
< Payload size: 8 bytes >
        RX Processing Time:  53.112 us
< Payload size: 16 bytes >
        RX Processing Time:  53.156 us
< Payload size: 32 bytes >
        RX Processing Time:  53.294 us
< Payload size: 64 bytes >
        RX Processing Time:  53.569 us
< Payload size: 128 bytes >
        RX Processing Time:  62.081 us
< Payload size: 250 bytes >
        RX Processing Time:  87.087 us

SCENARIO 3: Measuring processing time for bidirectional link.

< Payload size: 2 bytes >
        TX Processing Time:  41.981 us
        RX Processing Time:  58.288 us
< Payload size: 4 bytes >
        TX Processing Time:  41.950 us
        RX Processing Time:  58.694 us
< Payload size: 8 bytes >
        TX Processing Time:  41.956 us
        RX Processing Time:  59.475 us
< Payload size: 16 bytes >
        TX Processing Time:  41.956 us
        RX Processing Time:  61.138 us
< Payload size: 32 bytes >
        TX Processing Time:  41.906 us
        RX Processing Time:  64.538 us
< Payload size: 64 bytes >
        TX Processing Time:  41.962 us
        RX Processing Time:  71.213 us
< Payload size: 128 bytes >
        TX Processing Time:  41.969 us
        RX Processing Time:  91.263 us
< Payload size: 250 bytes >
        TX Processing Time:  41.962 us
        RX Processing Time: 140.062 us

=== SWC Profiler Summary ===

<<< Constants >>>
TX Base processing time: 47.031 us
RX Base processing time: 53.062 us
RX Payload processing threshold: 79.896 Bytes
RX-TX Base processing time: 57.087 us
SPI Time per Byte: 0.200025 us / Byte
SPI Speed: 39.995 Mbps

< Processing Formulas >
<< TX processing formula >>
proc = 47.031 us + (CMD_BYTE + MAC_HDR + nb_tx_byte) * 0.200 us/byte
<< RX processing formula >>
proc = 53.062 us + max((nb_rx_byte - 79.896), 0) * 0.200 us/byte
<< RX-TX processing formula >>
proc = 57.087 us + (max((nb_rx_byte - 79.896), 0) + (CMD_BYTE + MAC_HDR + nb_tx_byte)

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.