こんにちは！
e200z759n3 コアの命令実行パスを調べているときに、次の疑問が浮かびました。
- e200z7 コアリファレンスマニュアルでは、パイプライン実行ユニットの内容についてあまり一貫性がないようです。図 17 では、整数実行ユニットと乗算ユニットが分離されています。ただし、「4.2.1 整数実行ユニット」セクションでは整数の乗算と除算について説明します。セクション「4.6 同時命令実行」では、「デュアル スカラー整数ユニット」の存在について言及されていますが、乗算ユニットについては言及されていません。コアには、任意の整数演算 (合計、乗算、除算など) を実行CAN 2 つの整数実行ユニットがあると思います。私の結論は正しいでしょうか?デュアル発行パイプラインで 2 つの乗算を同時に実行CANか?
- リファレンスマニュアルに基づいてパイプラインの実行フローを説明し、理解を深めるために、次の図を描きました。何か概念を誤解していましたか?
よろしくお願いいたします。
マテウス
1) 確かにそうです、この写真はe200z4に関連しており、これも二重発行です
2) パイプラインの内容自体に依存します。前の回答の写真でCAN確認できます。最初の命令は短いため、次の命令の実行が停止することはありません。2 番目の命令は長いため、3 番目の命令は 2 番目の命令の結果に依存するため、停止が発生します。
3) それは待たなければなりません。
4) 基本的にはそうです。ここでは、コンパイラの最適化レベルによっても影響を受けるCANがあり、コンパイラはデュアルイシューアーキテクチャをより有効に活用するために命令の順序を変更する可能性があります（つまり、最高レベルの最適化を実現するには、命令スケジューリングを使用します。
返信ありがとうございます、デビッド！
さらにいくつか質問があります:
- パイプラインにはデュアル発行機能があり、実行ユニットには 2 つの整数ユニットがあるため、同じクロック サイクルで 2 つの独立した整数乗算命令または整数除算命令のフェッチ ステージを開始できますか?
- マニュアルには、加算のような単純な命令を実行する場合、実行ステージが 1 クロック サイクルで終了すると記載されています。WB ステージは E0 ステージの直後のクロック サイクルに入りますか、それともパイプラインの 10 ステージすべてを使用して IF0 から WB サイクル全体を完了するためにアイドル パディングを追加する必要があったのと同じように、さらに 3 つのアイドル クロック サイクルを待つ必要がありますか?
- 2 つの命令間にデータ依存関係がある場合、宛先命令はソース命令の最後の実行ステージと同じクロック サイクルで実行ステージを開始しますか、それとも次のクロック サイクルまで待つ必要がありますか?フィードフォワードがどのように機能するかがよく分かりませんでした。
- 命令間のデータ依存性をチェックするのはデコード フェーズなので、すべてのパイプライン ストールは D1 パイプライン ステージと E0 パイプライン ステージの間で発生すると結論付けるのは正しいでしょうか。
よろしくお願いいたします。
マテウス
1) 実行ユニットとは別に独立したものではなく、単にその一部であると思います。
2) それがまさにあなたが描いた通りであるとはCAN断言できませんが、原則的にはそれは確かに正しく、パイプラインのステージに適合します。
e200 マニュアルを読みやすくするために、次のプレゼンテーションをお勧めします。
こんにちは、デビッド！
命令パイプラインのメモリ依存性を理解するために、r6 に関連する依存性を持つ次のコードスニペットのタイミング ダイアグラムを作成しました。
mtctr r5
。ループ：
e_addi r6, r6, 1
e_mulli r6, r6, 1
e_bdnz .ループ
しかし、図をビルディングしているときに（この返信に添付）、スループットは一定のままであるものの、命令実行のレイテンシが反復ごとに 2 サイクルずつ増加し、上限がないように見えることに気付きました。何か見逃しましたか?パイプラインには、ストール状態で保持される命令の最大数がありますか?
私の図に他に間違いがあれば遠慮なく指摘してください。
よろしくお願いします、
マテウス
FF はフィードフォワードを意味し、STALL とは異なります。e200z6 RM も参照することをお勧めします。これは、コアのバリアントが古く、一部のトピックが少し異なる方法で説明されているため、より理解しやすい可能性があります。
https://www.nxp.com/webapp/Download?colCode=E200Z6RMAD&location=null
はい、プレゼンテーションは簡素化されるかもしれませんが、大きな違いは見当たりません。
こんにちは！
ループの繰り返しごとに、ストール状態で保持される命令の数が 2 つずつ増加し続けているようです。
- パイプラインには停止した命令の数に制限がありますか?
- それらは何らかのバッファに保存されますか?
- もしSOなら、このバッファにはいくつのエントリがありますか?
- これは何らかの形で問題バッファに関連しているのでしょうか?
- 停止した命令が何らかのバッファに保持されている場合、このバッファがいっぱいになり、さらに 1 つの命令が停止するとどうなるでしょうか?
よろしくお願いいたします。
マテウス
それは正しいと思います。乗算演算に指定されたレイテンシは、3 サイクルまたは 4 サイクルです (4 サイクルごとに結果が得られます)。これは、すべての操作が前の操作の結果に依存し、さらにループ内で実行されるという極めて最悪のCASEであり、実質的にパイプラインが完全に排除されます。これは、パイプラインが完全に存在しない場合と本質的に同じ動作をします。
こんにちは！
パイプラインのパディングに関する質問に戻ります。送信された画像のように 4 つの実行ステージすべてを埋めるパディングがない場合、リファレンス マニュアルの図に「FF」パディングが表示されるのはなぜですか?プレゼンテーションの図は簡易版ではないでしょうか？
パディングなしのプレゼンテーション図:
パディング付きのリファレンス・マニュアルの図:
よろしくお願いいたします。
マテウス
あなたの図で実際に間違っているのは、常に左側から始めていることだと思います。分かりやすく説明できるか分かりませんが…
e200z6 マニュアルの画像を使用すると、命令バッファの後に命令レジスタ (マーク付き) があり、その後にデコード ステージがあります。実行ユニットにストールがある場合、命令を後続のステージに配置できないと、命令バッファ内の命令もデコードできないことを意味します。
理想的には、特定のポイントで各ユニットの正確なステータスを考慮することができます。いずれにしても、図のどこにストールを配置するかは、結果として常に同じパフォーマンスにつながるため、マターではありません。
パフォーマンスはパイプラインのボトルネックによって制限され、このCASEは EU ユニットで停止し、システム全体に影響を及ぼします。
役に立つかどうかは分かりません。とにかく、なぜそのような正確な詳細を知る必要があるのですか?
実際のコードはこの方法では分析できませんが、この目的のためにパフォーマンス モニターやデバッグ トレースなどのツールが存在します。
共有ハードウェアを介したコア間相互作用が実行時間とリソース消費にどのような影響を与えるかを研究しています。検証のためにパフォーマンス モニターを使用しましたが、以前は結果を理解できませんでしたが、今は理解できます。ご説明いただきありがとうございました！
よろしくお願いします、
マテウス