SWRA667 January   2020 CC1312PSIP , CC1312R , CC1314R10 , CC1352P , CC1352P7 , CC1352R , CC2642R , CC2642R-Q1 , CC2652P , CC2652R , CC2652R7 , CC2652RB , CC2652RSIP

 

  1.   Cryptographic Performance and Energy Efficiency on SimpleLink™ CC13x2/CC26x2 Wireless MCUs
    1.     Trademarks
    2. 1 Abbreviations and Acronyms
    3. 2 Introduction
    4. 3 Benefits of Cryptographic Acceleration in Embedded Security Solutions
    5. 4 TI Drivers for SimpleLink MCUs
      1. 4.1 Power Management Overview
      2. 4.2 Return Behavior
        1. 4.2.1 Runtime Overhead
      3. 4.3 Efficient Power Management
    6. 5 CC13x2/CC26x2 Crypto Peripherals
      1. 5.1 AES and Hash Crypto Accelerator
      2. 5.2 Public Key Accelerator
        1. 5.2.1 ECDH Power Management Driver Example
      3. 5.3 TRNG
    7. 6 Benchmarks
      1. 6.1 AES and Hash Crypto Accelerator Based Drivers
        1. 6.1.1 AES CBC
        2. 6.1.2 AES CCM
        3. 6.1.3 AES GCM
        4. 6.1.4 AES CTR DRBG
        5. 6.1.5 SHA-224
        6. 6.1.6 SHA-256
        7. 6.1.7 SHA-384
        8. 6.1.8 SHA-512
      2. 6.2 PKA Engine Based Drivers
        1. 6.2.1 ECDH
        2. 6.2.2 ECDSA
        3. 6.2.3 ECJPAKE
      3. 6.3 TRNG Based Drivers
        1. 6.3.1 TRNG
    8. 7 Conclusion
    9. 8 References
    10.     Appendix: Plots of Blocking vs Polling Performance

4.2.1 Runtime Overhead

We use overhead to describe the CPU cycles spent over the course of an operation on anything that is not directly related to configuring the hardware or returning to the original calling context.

Polling return behavior has the least overhead. This is because its implementations are the closest to bare-metal we can provide. Apart from acquiring the mutex protecting the hardware from concurrent access, there are no OS calls and interrupts are avoided when hardware flags are available. How this affects power and call duration depends on how computationally expensive the operation is.

Callback return behavior has more inherent overhead. It requires the handling of an asynchronous event. That means that at least one context switch is required to handle the asynchronous event.

Blocking return behavior is effectively a specialized case of callback return behavior in terms of overhead. It will always post a semaphore and unblock a pending Task when the asynchronous event triggers.

If the power driver puts the device into idle when using callback or blocking return behavior, that comes with the associated overhead of going into and coming out of idle.

Table 2. Relative Runtime Overhead of Different Return Behaviors

Return Behavior Overhead
Polling Low
Callback Medium-High
Blocking High