Coldfire SEC and SKHA Benchmarks

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Coldfire SEC and SKHA Benchmarks

Jump to solution
900 Views
TomE
Specialist II

We're about to use the SKHA on an MCF5235 to do AES.

 

Nothing in the Reference manual or Data Sheet says how fast it is.

 

The only App Note I can find is AN2788, and it doesn't say either. It does list "Up to 133 MHz operation", but doesn't state how many clocks it takes to do anything.

 

Has anyone benchmarked these modules, or know where the execution speed is documented?


Thanks,

 

Tom

Labels (1)
0 Kudos
1 Solution
635 Views
TomE
Specialist II

It looks like nobody is using the SKHA, or maybe it is used by people who'd have to kill us after they told us.

We've done some testing, and on a 150MHz MCF5235, a single 128-bit-block AES cycle takes 40us in software and 4us in hardware.

Except the SKHA module in the MCF5235 is somewhere between "sub-optimal" and "broken". This problem seems to have been fixed in the MCF5329 implementation. What problem?

When we used the MCF5235 SKHA it gave the wrong results. We found we had to BYTE_REVERSE all data before pushing it into the module and then reverse it all on the say back out again.

Yes, it looks like the SKHA was lifted from a little-endian design and dropped into the big-endian Coldfire chip, with no hardware assist considered.

It looks to be better on the MCF5329. It adds DMA support to the encryption and there's now an "END" bit in the SKCR which can be used to set it to "Big endian mode" to match the CPU, memory and DMA controller.

Not too hard to four-byte-swap on a ColdFire chip? No, but it needs inline assembly to use the BYTEREV instruction.

Tom

View solution in original post

0 Kudos
1 Reply
636 Views
TomE
Specialist II

It looks like nobody is using the SKHA, or maybe it is used by people who'd have to kill us after they told us.

We've done some testing, and on a 150MHz MCF5235, a single 128-bit-block AES cycle takes 40us in software and 4us in hardware.

Except the SKHA module in the MCF5235 is somewhere between "sub-optimal" and "broken". This problem seems to have been fixed in the MCF5329 implementation. What problem?

When we used the MCF5235 SKHA it gave the wrong results. We found we had to BYTE_REVERSE all data before pushing it into the module and then reverse it all on the say back out again.

Yes, it looks like the SKHA was lifted from a little-endian design and dropped into the big-endian Coldfire chip, with no hardware assist considered.

It looks to be better on the MCF5329. It adds DMA support to the encryption and there's now an "END" bit in the SKCR which can be used to set it to "Big endian mode" to match the CPU, memory and DMA controller.

Not too hard to four-byte-swap on a ColdFire chip? No, but it needs inline assembly to use the BYTEREV instruction.

Tom

0 Kudos