こんにちは、
添付のプロジェクト例（SDK 25.06.00 CAAM サンプルから派生したもの）では、CRC のみを計算して CAAM のパフォーマンスを測定したいと考えています。実際、サンプルを実行してみたところ、すぐに動作が遅すぎると感じました。これを実現するために、私はDWT->CYCCNTレジスタを使用します。
ソフトウェアによる実装とも比較してみました。
RT1170-EVKBで実行したところ、以下の結果が得られました。
最初の計算がCAAMのようなアクセラレータにとって既に遅すぎるように思えるなら（ソフトウェア実装よりもさらに遅い）、2番目の計算はとんでもないものだ。
何が問題なのですか？SDKのバグかもしれません。
よろしくお願いいたします
最大
こんにちは@Kan_Li
ご返信ありがとうございます。
残念ながら、あなたの回答はまさに私が抱いていた懸念を裏付けるものでした。添付されたプロジェクトファイルは、返信前に開かれることすらなかったようです。
私がこう言う理由は非常に単純かつ客観的です。プロジェクトは既にCAAM_CRC()を使用しているからです。それは私が見落としていた理論上の可能性でも、試すのを忘れていた代替手段でもありません。添付の例に既に示されており、私の測定結果ではまさにその経路が最も悪い結果を示しました。
念のためもう一度明確にしておきますが、私はドライバの使い方に関する一般的な質問を投稿したわけではありません。NXPのサポート担当者が直接ビルド、実行、動作確認ができるように、SDKのサンプルを基にした完全なプロジェクトを作成し、添付しました。
同じCRCの計算結果を比較しました。
- ソフトウェアにおいて
- CAAMと共に
そして結果はまさに私が報告している問題点そのものでした。ハードウェアアクセラレータとしては、測定された性能が予想外に悪く、テストしたケースの一つでは、ソフトウェア実装よりも著しく劣っていました。
それが問題なのです。
「CAAM_CRC() を試してみる」ということではありません。
それは既に済んでいます。
お客様がすぐに実行できるプロジェクトを添付する場合、通常はフォーラムのストレージ容量、ネットワーク帯域幅、または誰かの時間を無駄にしないためです。なぜなら、お客様はサポートが問題を実践形式で再現することを期待しているからであり、特にプロジェクトがその目的のために既に最小化されている場合はなおさらである。
添付された再現プロジェクトが回答前に実際に検証されるという考えに、私は過信しすぎているのかもしれない。もしそうなら、それは私の責任です。
しかし、完全な再現手順が添付された技術的な投稿に対して、このようなレベルの対応しかされないのであれば、多くのユーザーが受けるサポートの質について不満を漏らすのも当然と言えるでしょう。
それでは、誤解の余地が全くないような形で質問を言い換えてみましょう。
- 添付のプロジェクトは既にCAAM_CRC()を使用しています。
- DWT->CYCCNTを用いてサイクル数を計測しました。
- 同じターゲットに対して、ソフトウェアCRCとCAAM CRCを比較しました。
- CAAMの性能は予想よりも悪く、あるケースではソフトウェアと比べて非常に大きな差で劣っていた。
これらの事実を踏まえ、NXP社には以下のいずれかを実施していただきたい。
- 添付のプロジェクトを使用して結果を再現してください。
- オーバーヘッドがどこから発生するのか説明してください。
- これがSDK/ドライバーの問題であるかどうかを明記してください。
- または、これらの業績数値は予想値であることを明確に述べる。
添付の例自体によって既に矛盾している提案よりも、具体的な技術分析の方がはるかにありがたいです。
よろしくお願いします、
マックス
こんにちは、 @mastupristi さん。
SDKのサンプルでは、CRCの初期化、更新、および終了の各関数が別々に使用されています。ドライバには、代わりに使用できるワンタイムのCAAM_CRC()関数があり、そちらの方が高速であるはずです。CAAM_CRC() を使ってみて、違いが出るかどうか確認してください。
すてきな一日を、
カン
-------------------------------------------------------------------------------
注記：
この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとう！
- 最後の投稿から7週間はThreadをフォローしますが、それ以降の返信は無視されます。
後日、関連する質問がある場合は、新しいThreadを作成し、閉じられたThreadを参照してください。
-------------------------------------------------------------------------------
こんにちは、 @mastupristi さん。
ごめんなさい、私のミスです！CRCエンディアンに関する別のプロジェクトを拝見しました。私のプロジェクトビューでは、あなたのプロジェクトが非常に似通っており、main() 関数もほぼ同じです。見落としてしまい申し訳ありません。
異なるCRC入力データ長であなたのプロジェクトをテストしたところ、CRC処理対象のデータが十分に長い場合（例えば、テストで使用したデータ長の2倍）、CRC初期化、更新、終了に基づくハードウェア計算はソフトウェア実装よりも優れていることがわかりました。しかし、CAAM_CRC()は常にテストで最悪のケースでした。現在、この問題について社内で調査しており、詳細が分かり次第お知らせします。
お待ちいただきありがとうございます！
すてきな一日を、
カン
-------------------------------------------------------------------------------
注記：
この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとう！
- 最後の投稿から7週間はThreadをフォローしますが、それ以降の返信は無視されます。
後日、関連する質問がある場合は、新しいThreadを作成し、閉じられたThreadを参照してください。
-------------------------------------------------------------------------------
こんにちは、 @mastupristi さん。
どうやら私のボードに何か問題があるようです。別のRT1170EVKBボードを使ってみたところ、以下の結果になりました。
別のボードで再度試すことはできますか？
すてきな一日を、
カン
-------------------------------------------------------------------------------
注記：
この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとう！
- 最後の投稿から7週間はThreadをフォローしますが、それ以降の返信は無視されます。
後日、関連する質問がある場合は、新しいThreadを作成し、閉じられたThreadを参照してください。
-------------------------------------------------------------------------------
こんにちは@Kan_Li
3つのボードと合計4つのテストにおいて、非常に異なる行動と非常に異なる数値が見られることに懸念を抱いています。
ここで一つ覚えておいていただきたいのは、CAAMはMCUの内部ペリフェラルであり、MCU内部のRAMと相互作用するということです。取締役会の外部コンポーネントのうち、現実的に考えて、CAAMにこれほど重大かつ一貫性のない影響を与える可能性のあるものは何だろうか？
現段階では、根本的な問題は実はMCU側にあるのではないかと検討するのは妥当と思われる。
これが私のEVKに搭載されているものです
また、3回のテストで得られた数値は、具体的にどのような条件下で得られたものなのか、詳しく教えていただけますでしょうか？特に：
- どのボードが使用されたか、
- どのMCUが搭載されていたか、
- また、設定や条件に関して、他に何か関連する違いがあったかどうかも確認した。
最も重要なのは、私の数字とあなたの数字の差をどのように説明するのかということです。
現時点では、さらなるテストに使用できる他の基板がありません。
よろしくお願いします。
最大
こんにちは、 @mastupristi さん、
私のデバイスはMIMXRT1176DVMAA/0P94B/CTAS2152Aで、あなたのものと同じです。私のテストでは、あなたのコードのデバッグ前にフラッシュメモリで実行中のプログラムが起動しないように、ブートモードをシリアルダウンロードモードに設定し、SRAMであなたのコードを実行しました。あなたも同じようにしましたか？あなたのボード間で結果を共有していただけますか？
よろしくお願いいたします。
カン
こんにちは@Kan_Li
「アプリケーションをRAMにリンクする」を試してみました（プロジェクトを添付）。
この設定で、以下の結果が得られました。
ご覧のとおり、状況は大幅に改善されていますが、本当に驚くべきことは、CAAMを使用した最初のCRC計算にかかる時間が、ソフトウェア版と同じであるということです。
CAAM（CAAM_CRC()）を使用した最新のCRC計算には3億3700万サイクルかかります（以前は14億2200万サイクルかかっていたので、わずか4分の1に減っただけです）。
このマイクロコントローラを搭載した別のEVKBを借りることができました
以下のような結果が得られました。
つまり、ソフトウェアの実装は両方のボードで全く同じように動作するということです。それは驚くべきことではない。むしろ、私が予想していた通りだ。
最初のCAAMはわずかに時間がかかるだけであるのに対し、2回目のCAAMは大幅に短い時間（2億5200万サイクル）で完了する。
注意点として、憶測を立てる前に、コードを確認して、「第一」と「第二」のソフトウェアとハードウェアの意味を理解してください。
以下に概要を示します。
- SW CRC32 iSCSI
- SW CRC16 CCITT
- HW (CAAM) CRC32 iSCSI (初期化、更新、最終処理を個別に呼び出し)
- HW (CAAM) CRC16 CCITT (CAAM_CRC() を呼び出し中)
これは私にとって多くの疑問を抱かせる。
- 特に4位の成績に見られるこの一貫性のなさは、非常に懸念される。何が原因ですか？
- このアクセラレータは、ソフトウェアによる実装と比較して、全く処理速度を向上させていないようだ。本当にそうなのでしょうか？それとも私が何か見落としているのでしょうか？
よろしくお願いします。
最大
こんにちは、 @mastupristi さん。
4番目の検査結果については現在も社内で確認中です。新たな情報が入り次第、ご連絡いたします。
他のテストでは、ソフトウェア/ハードウェア別にデータをさらに計算しましたか？コア上で動作するソフトウェアはキャッシュからある程度の恩恵を受けるが、データ量が増えると、その差が顕著になる。
よろしくお願いいたします。
カン
こんにちは、 @mastupristi さん。
内部の後。議論の結果、問題の原因はDCACHEの無効化であることが判明しました。
このプロジェクトではキャッシュのライトスルー（"CACHE_MODE_WRITE_THROUGH=1") 設定を使用しており、マクロ（"CAAM_OUT_INVALIDATE") も有効になっているため、DCACHE 無効化機能によって機能のパフォーマンスが低下します。これは、主にミドルウェアにおけるデータ整合性の問題を回避するために、SDKのサンプルに実装されています。ERR050396（下記参照）のため、TCMは書き込みには使用できません。
以下は、その関数の測定値です。
この例では「出力」はキャッシュ不可能な領域に配置されているため、その特定の関数における無効化は不要です。
/*! @brief CRC の出力バッファ。*/
uint8_t AT_NONCACHEABLE_SECTION(crc_output[4U]);
DCACHE無効化が削除されると、次のようになります。
最高最適化（-O3）を有効にした場合：
データアクセス制限とCAAM構成構造の処理を考慮すると、この場合、800MHzでDTCM内のデータを使用してITCMから実行される最適化されたソフトウェア実装は、CAAMよりも高速になる可能性があります。ソフトウェア計算が頻繁に中断されるかどうかは、ペイロードのサイズとアプリケーション全体のコンセプトによって決まると言えるでしょう。
よろしくお願いいたします。
カン