Coldfire SEC and SKHA Benchmarks

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Coldfire SEC and SKHA Benchmarks

ソリューションへジャンプ
2,008件の閲覧回数
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

ラベル(1)
0 件の賞賛
返信
1 解決策
1,743件の閲覧回数
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 件の賞賛
返信
1 返信
1,744件の閲覧回数
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 件の賞賛
返信