チャネル動作マージンはそんなに悪くない

COMとは何か？

Channel Operating Margin（チャネル動作マージン）またはCOMは、よく理解されていない概念です。理解されていないため、多くの人々はそれが本当に何かを意味するのか疑っています。結局のところ、チャネル品質がデシベルで表される単一の数字でどうやって表せるのでしょうか？実は、COMはアイパターンを使用したチャネル検証技術の長い進化の最新の段階なのです。このブログでは、COMの進化をその起源まで遡り、悪名高いCOMメトリックに意味を与えます。

最初のチャネル動作マージン：アイパターン

まずはアイパターンから始めましょう。アイパターンは、長いシリアルデータの流れを見る方法です。Keysight ADSやPyBERT [1] [2]が登場する前は、アイパターンはデジタルサンプリングオシロスコープやリアルタイムスコープで測定されていました。アイパターンウィンドウでは、y軸の単位は電圧で、x軸の単位は2つの単位間隔にわたる時間です。単位間隔、またはUIは、1ビットが通過するのに必要な時間です。したがって、2UIの時間内に、画面の中央に1ビットのデータを半ビットのマージンを両側に持たせて中央に配置できます。しかし、1ビットだけを見るのではなく、すべてのビットが一度に重なり合い、シリアルデータの全ストリームが画面上に表示されるまで重ねていきます。信号品質は、中央の穴の大きさで定量化されます。アイパターンがとても良好に見える場合、エンジニアが「そのアイを通してトラックを運転できる！」と言うことがあります。開口部を定量化する最も一般的な方法は、幅、高さ、または面積です。アイのDC点での交差はジッターであり、ジッターは通常、ヒストグラムを用いて統計的に測定されます。

図1. シリアルビットストリームの例。

早期のチャネル仕様、そして場合によっては受動部品の仕様では、合否判定基準としてアイマスクと呼ばれるものが使用されていました。アイマスクは通常、アイ幅とアイ高さによって定義されるダイヤモンド形の領域です。合格するアイは、アイマスク内に検出されたサンプルまたはヒットが限られた数しかありません。1と0のパターンは標準によって指定され、通常は疑似ランダムビットシーケンスまたはPRBSパターンです。基本的に、パターンを10Gb/s未満と10Gb/s以降の2つのカテゴリーに分けることができます。10Gb/s未満では、ほとんどのシステムで8b10bエンコーディングが使用され、PRBS 7が適切なパターンでした。IEEEが802.3baで10Gb/sを導入したとき、エンコーディングは64b66bスクランブラーに切り替わり、PRBS 31が主流になりました。今日でも112Gb/sで、PRBS 31、またはQPRBS 31が最も使用される標準パターンです。

統計的に言えば

測定されたアイパターンの後、StatEyeは受動チャネルを評価する次の方法であり、OIFによって広く使用されました。StatEyeの背後にある考え方はここで詳しく説明されています：[3] 簡単に言うと、StatEyeはシステムのパルス応答を使用してアイパターンを予測します。パルス応答とは、1-UIの正方形パルスで興奮させたシステムの時間領域応答であり、システムは等化を含む受動チャネルです。StatEyeで利用可能な等化技術には、FFE、CTLA、DFEがあります。システムの伝達関数はSパラメータから収集されます。チャネルSパラメータはシミュレートできるため、StatEyeは多くのチャネルと等化設定を試して、何が機能するかを見る効率的な方法です。その間、アイマスクは統計的に予測されたアイオープニングを使用しての合格/不合格基準です。

StatEyeとCOMの間のどこかで、ピーク歪み分析（PDA）がある程度一般的になりました。この方法は、HeckとHallによって「高速デジタル設計のための高度な信号完全性」[4]でよく文書化されています。要約すると、StatEyeと同じパルス応答を使用しますが、出力は単にいわゆる最悪のケースのアイ開口となります。PDAはデータをでっち上げないため、個人的に好きな理由です。自分で実装してみたところ、PDAは高い信頼性を持って最悪のケースのアイパターンを予測することがわかりました。しかし、PDAとStatEyeはチャネル内の送信機と受信機の影響を含まず、最適なイコライゼーション設定を手動で見つける必要があります。

図2: 青で示されたアイパターンと点線の黒で示されたPDAの例。

COMへ

COMはIEEE 802.3bj、100GBASE Ethernetの一部として開発され、シミュレートされたチャネルにICの不完全性を追加しました。StatEyeよりも使いやすく、より広く採用されており、今日では事実上のチャネル品質予測ツールです。既に述べたように、COMはStatEyeから構築され、いくつかの新しいノイズ源を追加します。具体的には、ノイズ源はICからの損失、ICパッケージの反射、IC関連のジッター、およびクロストークなど、IC内で発生するその他のすべてのものに対する一括ガウスノイズ源です。COMの実装はIEEE 802.3 Annex 93A [5]に記載されています。

COMの背後にある数学のほとんどは、標準化団体によってできるだけ簡素化されています。例えば、Sパラメータの連結は、SパラメータからABCDパラメータやTパラメータへの変換や行列の乗算ではなく、代数に簡素化されています。最も難しい方程式は、ISI関連ノイズの確率密度関数（PDF）を計算することですが、数回試せばそれほど悪くはありません。データの各UI内に32のサンプルポイントを確保する方法など、実装固有と考えられるいくつかの省略がありますが、これらの詳細はIEEEが自由に提供するオープンソースコード内で見つけることができます[5]。

TRANSLATE: COMは、可能なイコライゼーション設定のセットを使用して、与えられたチャネルに対する最適なケースシナリオを見つけます。これは、すべてのイコライゼーション設定をスイープして、メリットの図（FOM）と呼ばれるものを計算することによって達成されます。最良のFOMを生成するイコライゼーション設定が、残りの計算に使用されます。すべてのノイズ源のPDFが計算されると、検出されたエラー率（DER）でのノイズが特定されます。DERはシステムの望ましいビットエラー率（BER）であり、考慮されている前方誤り訂正（FEC）技術によって決定されます。利用可能な信号は、特定のサンプリングポイントでのパルス応答電圧によって決定されます。利用可能な信号は検出されたエラー率でのノイズ（信号対雑音比）で割られ、この数値はデシベルに変換されます。ヴォイラ！COM！実は、それは意味を持っています。

COMで使用される設定は、利用可能なIC技術によって決定されます。IC技術のレベルは、Intel、Broadcom、Mellanox、Fujitsuなどの業界リーダーによって合意されます。言い換えれば、COMで実装された技術を使用するICは、COMによって予測される通りに動作チャネルで機能することができるはずです。明らかに、これは非常に強力です。なぜなら、標準がついにチャネルの所有権の一部をICベンダーに移したからです。

COMがチャネル予測の理想郷のように聞こえるかもしれませんが、制限があります。標準によって考慮されているすべてのシステムに対して一つの設定セットであるため、個々のICのパフォーマンスを予測することはできません。測定の相関を得るには、個々のICごとにCOM設定を調整する必要があります。さらに、COMはスキューからのノイズ寄与を無視します。幸いなことに、Jason ChanによるDesignConの論文がこの不足を取り上げており、将来、彼のアイデアを活用した更新されたCOMスクリプトを見ることを期待しています [6]。

結論

要するに、COMはそれほど悪くないです。チャネル分析の進化の非常に論理的な次のステップであり、チャネル評価を比較的容易にします。COMの著者がMATLABコードを自由に公開し、サポートしてくれたことに非常に感謝しています。将来、他の信号整合性エンジニアによってCOMが実装され、改善されることを期待しています。誰が知っているでしょう、いつの日かPythonやOctaveの実装を見るかもしれません。

すべての図はGNU Octaveで作成されました、https://www.gnu.org/software/octave/。

参考文献:

[1] Keysight ADS ランディングページ, https://www.keysight.com/en/pc-1297113/advanced-design-system-ads?&cc=US&lc=eng

[2] PyBERT ランディングページ, https://pypi.org/project/PyBERT/

[3] A. Sanders, M. Resso, J. Ambrosia, チャネルコンプライアンステストにおける新しい統計的アイメソドロジーの利用, DesignCon 2004, http://www.ece.tamu.edu/~spalermo/ecen689/stateye_theory_sanders_designcon_2004.pdf

[4] S. Hall, H. Heck, 高速デジタル設計のための高度なシグナルインテグリティ, Wiley 2011

[5] IEEE 802.3 Ethernet Working Group ランディングページ, http://www.ieee802.org/3/

[6] J. Chan, G. Zheoff, 112-Gbps PAM4 システムへの影響とモード変換, DesignCon 2019.