2403381_ja-JP

Yes

T1040 mEMAC TX_FIFO_OVFL は、別のポートがリンクを失ったときにポートで動作します。

私は1G mEMAC RGMIIインターフェースを使ってT1040のイーサネット問題をデバッグしています。別のポートが物理的なリンクを切った場合(例えばケーブルが切断されている場合)、イーサネットポートでパケットロスが発生しています。これは、両方のポートが高速データ転送速度で動作している場合に最も頻繁に発生するようです。

問題が発生すると、健康なポートの割り込みイベントレジスタ(「IEVENT」)に「TX_FIFO_OVFL」ビットが設定されているのが見えます。

私の現在の解釈では、アクティブに送信中のmEMACが物理的なリンクを失うと、FMan/mEMAC送信経路の何らかの要因によって、別のmEMACがTX FIFOを十分に速く使い切ることが一時的に妨げられる、ということだ。正常なポートは最終的に`IEVENT[TX_FIFO_OVFL]`を報告し、フレームが失われます。しかし、この行動を引き起こす共通のリソースやメカニズムはまだ特定していません。

私の質問は以下のとおりです。

* これは既知のT1040 / FMan v3 / mEMACシリコンの問題ですか、それともエラタムですか?
* 1G mEMACポート間で共有リソースがあり、送信中に一方のポートでキャリアが失われ、別のポートの送信FIFOに一時的に影響が出る可能性があるか?
* PHYがリンクを失った場合、QMIデキューの停止、BMI TXポートの無効化、mEMAC TX/RXの無効化、mEMACのリセットなど、必要なシーケンスはありますか?
* オーバーフローが発生する前に「TX_FIFO_OVFL」状態を検出できるmEMACやFManステータスレジスタはありますか?
* この状況で「TX_FIFO_OVFL」を防ぐために推奨されるFMan/mEMACやPHYの設定変更はありますか?

よろしくお願いします。

Re: T1040 mEMAC TX_FIFO_OVFL on port when another port loses link

こんにちは、

T1040/FMan v3のシリコンエラッタで、ピアポートのリンク喪失によって正常なポートでTX_FIFO_OVFLトリガーされることを具体的に説明したものは、公式には文書化されていません。T1040チップの正誤表はNDA（秘密保持契約）によって管理されており、一般には公開されていませんが、T1040 mEMACに関して、そのようなクロスポートTX FIFOオーバーフローの正誤表は確認されていません。

観察されている現象は、シリコンの欠陥というよりも、共有されているFMan BMIリソース内のアーキテクチャ上の相互作用によるものである可能性が最も高いです。

よろしくお願いします。

Re: T1040 mEMAC TX_FIFO_OVFL on port when another port loses link

こんにちは、

共有される4つのBMIリソースは、TNUM(タスク)、DMAチャネル、FIFO(MURAM)、パイプライン深度です。FIFOサイズ、パイプライン深度(DPDE)、FIFOの低閾値(FLCL)の変更で改善が見られなかったため、DMAチャネル層が最もボトルネックであり、MURAM割り当てではありません。

T1040 FManは、すべてのアクティブなTXポートで共有される固定されたDMAチャネルプールを持っています。各ポートのTXパスは以下のとおりです。

CPU → QMI dequeue → BMI opens DMA read (DDR → MURAM) → TX FIFO → mEMAC → wire

停止したポートがリンクを失い、 COMMAND_CONFIG[TX_EN]クリアすると、mEMAC はワイヤへの送信を停止しますが、既にパイプラインの途中にあるフレーム、特に BMI TX ポートが既に DMA 読み取りトランザクション (DDR → MURAM TX FIFO) を発行しているフレームは、すぐには完了しません。DMA読み取りによって既にデータがTX FIFOに移動されている可能性があり、FMan DMAエンジンは現在、FIFOを消費するMACに依存する「DMA完了/EBD（外部バッファ記述子）解放」確認応答を待っています。TX_EN=0ではMACが消費されないため、DMAトランザクションは開かれたままになります。

停止したポートで開いているDMAトランザクションは、共有DMAチャネルスロットを保持します。高負荷時には、健康なポートのBMI TXパスが十分なDMAチャネルスロットを獲得できず、DDRからデータを迅速に取得できず、TX FI→FOが一時的に空になり→その後MACのドレインレート→ TX_FIFO_OVFLよりも速く戻ってしまいます。

よろしくお願いします。

Re: T1040 mEMAC TX_FIFO_OVFL on port when another port loses link

ありがとう。この行動を引き起こすと予想される共有のBMIリソースや仲裁メカニズムを特定しますか?

FMBM_PFS[IFSZ]、FMBM_TFP[DPDE]、およびFMBM_TFP[FLCL]への変更をテストしましたが、意味のある変化は見られませんでした。また、IF_STATUS[RGLINK]が低下したらエンキューをやめ、mEMAC TXをすぐに無効にしていますが、健康なポートでもパケットが失われることがあります。

この相互作用からポートを分離するための、文書化された、または推奨される構成はありますか？また、どのBMIリソースが枯渇したり、ブロックされたり、健康なmEMACがTX FIFOを消耗させないようにしているかを示すカウンター、ステータスレジスタ、デバッグ機構はありますか?