nrf_cc310 and ARM TrustZone CryptoCell in interrupt mode

Hi,

The CC310 runtime library use interrupts internally, but the API calls are still blocking. This is achieved by the library calling __WFE() internally when waiting for events. During this time the CPU can sleep or other interrupts can be serviced. There is also some use of busy-waits in a few special cases, but only for very short waits.

Hi,

The CC310 runtime library use interrupts internally, but the API calls are still blocking. This is achieved by the library calling __WFE() internally when waiting for events. During this time the CPU can sleep or other interrupts can be serviced. There is also some use of busy-waits in a few special cases, but only for very short waits.

Thank you for the fast response Einar!
For me it is not clear why Nordic has integrated the CryptoCell peripheral. From this post (devzone.nordicsemi.com/.../184195 it is clear that CryptoCell doesn't provide significant speed benefits compared to software libraries such as oberon. In some cases CryptoCell is even slower than the software libraries. I was expecting that the benefit of CryptoCell is that the CPU is free for other operations when the CryptoCell  runs but this is apparently not the case.

The only benefit which I can imagine now is that CryptoCell is very energy efficient but according to the same post above Nordic doesn't have numbers for that.

Hi,

The performance of CC310 compared to SW implementations depend significantly on the algorithm, size of data etc. For instance you will get a huge benefit when calculating SHA256 over a larger buffer.

This is a comparison of SHA256 with message length 4123 for two backends:

• Oberon: 4.7413ms
• CC310: 0.1596ms

Where could I find speed numbers for CC310 doing AES CCM 128bit?

Hi,

There is no list of performance numbers that I am aware of. However, you can use the following numbers as a reference. WITH AEAD CCM 128, message_len=16 ad_len=250 mac_len=8 nonce_len=13', we got an execution time of 0.1389 ms using CC310 and 0.6879 ms using embed TLS (SW). So, in this case, CC310 was about 5 times faster. This test has some overhead though, and it typically also depends on toolchain etc. I suggest you take an example from the SDK and adapt it to get more accurate numbers for your specific use case if you need it.

During this time the CPU can sleep or other interrupts can be serviced. There is also some use of busy-waits in a few special cases, but only for very short waits.

I'm curious to what extent the CPU goes to sleep when using the CC310. I've been monitoring NRF_PWR_MGMT_SLEEP_DEBUG_PIN and can't see the MCU ever enter sleep mode when using the CC310. We use the CC310 for ecdh and eddsa (we are not using the nrf crypto backend/frontend). Should I open a separate issue for this or is this the expected behavior?

This was on SDK v17.0.2

Regards,

Tofik