次がSerial/Parallelの変換であるが、ここは別段複雑な事をやっている訳ではない。単にByte Orderに則って、1bitづつ処理をしてゆくだけである(Photo01)。問題になるのはこの処理そのものというよりも、Signalingそのものである。というわけで、ちょっと順序がひっくり返るが、ここでSignalingの話に触れておきたい。

Photo01: PCI Express Base Specification Rev.2.0のFigure 4-3より抜粋。要するに8bit(というか8b/10b処理後だから10bit)分のデータを一列に並べるか、あるいは逆に一列に並んだデータを10bit単位で切り分けるかの差でしかない。

SignalingそのものはPCI Express Gen2のElectrical Sub-block(Chapter 4.3)に定義された話とほぼ一緒であるが、だいぶ端折ってあるというか、本当に必要になるパラメータのみが記載されており、方法論などは既に理解しているという前提の書き方になっているので、ここではSpecificationを離れて先日のDeveloper Conferenceのプレゼンテーションから説明したい。

まず、5GHzの信号を何もしないで流すとどんな具合か? というのはPhoto02に示す通りだ。ただしこれは、適切なEqualizationを行うことで、大幅に改善される(Photo03)。具体的には、まず送信側ではDLEを使って送信波形の補正を行い(Photo04)、受信側はCTLEを使ってやはり受信データの補正を行う。言ってみれば送信側ではDLEを使ってPre-emphasisを行い、受信側ではCTLEを使ってDe-enphasisを行うことになると考えれば良いだろう。ちなみにPhoto05の下に書いてある通り、受信側のEqualizerは固定設定ではなく、実際の接続環境に応じてSettingの変更を動的に行う事になる。動的、といっても一度通信が始まったら基本的には設定は固定であり、Settingは接続時にTSEQというシンボルを2^16回送信するタイミングで行う事になっている。

Photo02: 信号減衰も著しく、クロストークの影響も著しいため、まともな信号になっていない。

Photo03: Data Eyeもちゃんと開くし、クロストークも大幅に軽減される。

Photo04: DLEは時間方向で複数回のサンプリングをして、その和を組み合わせることで信号強度を高める技法。信号の高周波成分を強くする事で、信号を強調する形になる。

Photo05: CTLEは逆に高周波成分を減らす方向で作用する。

ちょっと気になるのは、PCIeの場合、Cable接続といっても、それはたとえばNotebookとDocking Bayだったり、Slim CaseとExpansion Boxだったりという、物理的にはCableであっても、動作中にケーブルの位置関係が大きく変わったりすることは余り想定していない筈で、それであればLink Upの際のTrainingだけで問題はないと思う。ところがUSBの場合、ケーブルを繋いだ状態で機器が移動する事は割に少なくないだろう。たとえばUSB HDDを繋いでいたら、うっかりテーブルからHDDがずれおち、USB Cableのみでテーブルからぶら下がって揺れている、なんて経験をした人は筆者だけではないと思う。従来のUSBはこうしたラフな使い方を許したし、実際これでコネクタが抜けてしまわない場合、問題なく通信できていた。ただUSB 3.0の場合に同じ事をすると、急激にケーブルの状況が変わるから、Initial Learningの際のEqualizer Settingでは補正しきれなくなる状況はありそうに思う。もちろんこの場合、最終的には通信ができなくなれば一旦Link切断となり、再びInitializationから始めればいいわけだが、その場合煩雑にLinkがUp/Downを繰り返す事になり、事実上使い物にならなくなる可能性もある。理論上は、たとえば回線状況が悪くなったらダイナミックにUSB 3.0→USB 2.0に切り替えるとか、逆に回線状況が復活したらダイナミックにUSB 2.0→USB 3.0に切り替えるといった事がサポートされていれば、こうした状況でもそれほど使い勝手は悪化しないと思うのだが、残念ながらUSB 3.0では規格上そうした実装が一切許されていない。実際に製品が出てきたときに、このあたりがどうなるのかちょっと興味ある部分ではある。

Signalingそのものと同じ程度にクリティカルなのがJitterである(Photo06)。この左下の表はTx/Channel(つまり配線やコネクタ)/RxそれぞれがどれだけのJitter Budgetを持てるかを規定したもので、トータル200psというのは5GT/secで伝送を行う時にJitterを1T以内に抑える、という条件から出ている。ここで、Data Scramblingを行う事のメリットが出てくる。Scramblingを行わない場合、ChannelのDeterministic Jitterは最大75psとなるが、Scramblingを行うと、これがトータルで20ps程度低減できるとしている(Photo07)。

Photo06: Jitterは要するにタイミングの揺らぎである。JitterにはRandom JitterとDeterministic Jitterがあり、前者は確率的に計算することになる。もっともこれを確率論的に計算できるのは、Data Scramblingを行っているから、という事であるが。14.069という数字は、BERが10^-12を満たす必要性があるところから出てくる。

Photo07: Photo06でChannelのTotal Jitterは75psとしており、つまり±37.5psになる。ところがScramblingをかけることで、Random Jitterの分を分散させる事が可能になり、この結果平均的なJitterのピークを10ps程度内側に寄せることが出来、トータルで20psの節約になるという仕組み。

ただ、こうした技法を使っても、まだ十分とは言い切れない場合があるようで、オプション扱いながらDFEをReceive側に入れることで、より多くのマージンを確保できる、という話であった(Photo08)。

Photo08: DEFは日本語では「判定帰還等化」などと称される。CTLEとは異なり、非線形のシステム。簡単に言えば、以前のビット列の結果を元に現在のビットを推定するという方式。DFEを追加することで、Windows Sizeを50mV、Jitterを20psほど稼ぐことが出来る。ただ一般にDFEは回路が複雑になるので、あとはコストとの相談ということになり、そのあたりがオプション扱いされている理由なのだろう。

(続く)