LPC55S69 CASPER SDK Example Performance

cancel
Showing results for 
Search instead for 
Did you mean: 

LPC55S69 CASPER SDK Example Performance

301 Views
Contributor I

I tested the lpc55s69_mbedtls_benchmark SDK example (from AN12445) in order to see how much speed-up ECDSA signing and verifying with the CASPER hardware accelerator could bring in my project. I  let the unmodified SDK example run on an LPC55S69 board and got the following output:  

 

"mbedTLS version 2.13.1 

fsys=96000000 

Using following implementations: 

  SHA: HASHCRYPT HW accelerated 

  [..]   

  Asymmetric encryption: CASPER HW accelerated 

  [..] 

  ECDSA-secp256r1          :    2.00 sign/s 

  ECDSA-secp256r1          :    1.67 verify/s" 

 

2 signs/s means 500ms per sign, 1.67verify/s means ~600ms per verify. This is way more than the Numbers for ECDSA-secp256r1 in the CASPER application Note (AN12445): 76ms per sign, 81ms per verify. 

 

I then commented out MBEDTLS_FREESCALE_CASPER_PKHA to see the difference when the operations run in software without CASPER and got the exact same numbers, though the printout is now "Software Implementation": 

 

"mbedTLS version 2.13.1 

fsys=96000000 

Using following implementations: 

 SHA: HASHCRYPT HW accelerated 

 [..]

 Asymmetric encryption: Software implementation 

  

ECDSA-secp256r1          :    2.00 sign/s 

ECDSA-secp256r1          :    1.67 verify/s" 

 

It seems that CASPER is not running at all in the example application. Is there a problem in the example application or did I miss something 

Labels (1)
0 Kudos
8 Replies

76 Views
Senior Contributor I

Hi !

Try to allocate some mbedTLS code/data in SRAMX area and enable flash prefetch bit.

You will get +xx% for sure for crypto algos where HW acceleration is not supported.

Regards,

Eugene

0 Kudos

76 Views
NXP Employee
NXP Employee

Hello Simon,

Hope you are well. First I'd like to confirm the microcontroller version that you are using, as well as your SDK version as I notice that your fsys=96MHz, this indicates that either one may be an older version.

In addition, I'd recommend that when testing the benchmark example, you use the release build instead of the debug build to optimize it.

In my test I am using MCUXpresso 11.1.0, SDK version 2.6.3, LPCXpresso 55S69 Revision A2(1B silicone).Here are my results(Release Build):

pastedImage_1.png

Same test but (Debug Build):

pastedImage_5.png

Let me know if this helps you.

Best Regards,

Sabina

0 Kudos

76 Views
Contributor I

I was indeed using an older IE and SDK (11.0.0 and 2.6.2). I now downloaded the newest (11.1.0 and 2.7.0 which already uses mbedTLS 2.16.2). However, the results still do not make sense to me: 

DEBUG:  

 

Asymmetric encryption: CASPER HW accelerated  

ECDSA-secp256r1          :    5.00 sign/s 

ECDSA-secp256r1          :    4.67 verify/s   

 

Asymmetric encryption: Software implementation (DEBUG)  

ECDSA-secp256r1          :    5.00 sign/s 

ECDSA-secp256r1          :    4.67 verify/s   

 

RELEASE:  

 

Asymmetric encryption: CASPER HW accelerated   

ECDSA-secp256r1          :    5.33 sign/s 

ECDSA-secp256r1          :    5.00 verify/s  

 

Asymmetric encryption: Software implementation  

ECDSA-secp256r1          :    5.67 sign/s 

ECDSA-secp256r1          :    5.33 verify/s   

Hardware or software implementation makes basically no difference. I tried various optimization settings which didn't change much. To me, it makes sense that (at least in my version of the SDK) there is not much difference between DEBUG and RELEASE and between various optimization settings, as the compute intensive part is done in hardware which should not be affected by those settings. However, Hardware vs. Software Implementation should make a difference. 

I debugged the application and found out that in both cases (HW and SW), various CASPER functions are called. Defining or uncommenting MBEDTLS_FREESCALE_CASPER_PKHA does not seem to make a difference. But if the explanation for the similar results would be that CASPER is running also when it should not, the results in AN12445 Table 8 are still more than 2 times better than my results in any build/optimization. I expect the results to be slightly different as AN12445 war used with IAR instead of MCUXpresso IDE, but I would not expect the results to be more than 2 times better for a mostly HW operation. 

0 Kudos

76 Views
NXP Employee
NXP Employee

Could you please provide the marking on the IC please, so I can verify the version of silicone.

Best Regards,

Sabina

0 Kudos

76 Views
Contributor I

Hi Sabina,

this is printed on the IC:

LPC55S69JBD100

TR7T4211                  02

sSD18501  Y

0 Kudos

76 Views
NXP Employee
NXP Employee

Hi Simon,

Thank you for providing the information. In your case, you are actually working with the first revision of this board, which is capable of running up to 100MHz. 

As you may have seen the requierements of the application note(AN12445) to be able to produce the results are the following:

pastedImage_1.png

The silicion 1B is now capable of running at 150MHz. The evaluation board that uses this chip is revision A2. You can find this printed under de NXP logo next to the crystal on the board. 

Here is a link on the other differences that have been fixed from the earlier revision to the new one.

https://community.nxp.com/docs/DOC-345272 

Best Regards,

Sabina

0 Kudos

76 Views
Contributor I

Thank you! I will order new boards now

0 Kudos

76 Views
NXP Employee
NXP Employee

You are very welcome! :smileyhappy:

0 Kudos