では、もう少し具体的な話。まずPhysical Layerである(Photo14)。最低でも300MB/secのスループットで、3mまでのケーブルに対応するのが目的であり、加えて様々な制約がある(Photo15)。このために、PCI ExpressのPhysical Layerをそのまま使った、という話は昨年レポートした通りである。ではどの程度PCI Expressを流用したか、というのがこちら(Photo16)。Common Clockを廃したので、HostとDeviceはそれぞれが250MHzのClock Sourceを自前で持つ必要がある(Data Clockは8b/10bのEmbedded Clockで提供される)ほか、おそらくはノイズ対策としてSpread Spectrumが必須になり、またSignal Equalizationが必須になったあたりは、おそらく信号線を3mまで引き回すことへの対策であろう。

Photo14: ここに出てくる"Pipe Model"というのは、後述するPIPE I/Fとは別の話。USBにおいては、アプリケーションとターゲットデバイスの間に仮想的な"Pipe"と呼ばれる通信路が構築され、このPipeに対してリクエストを発行したり、Pipeから返答が返ってきたりするというモデルを指す。

Photo15: PCIe Cableの場合、信号そのもの以外に最低5本、実際には6本の信号が必須として定められている。これらの機能は全部信号線で送るパケットに統合してしまった。なんせConnect/Disconnectすら信号線のSenseで行うわけだから、余分な信号線は最小限となっている。

Photo16: 細かいところでは、Jitter budgetがPCI Expressよりも現実問題として小さくなりそうだ。これはPHYの制御をPCI Expressより高精度に行わなければならないことを意味するわけで、実装がちょっと大変そうだ。

Physical Layerでいえばコネクタも変化するわけで、昨年でもUSB 3.0 Standard-A/BやMicro-B Connectorの案が提示されたが、今年は案から一歩進んだ製品に近いレベルのものが出てきた(Photo17～20)。Micro-Bについては会場でReference Sampleも展示されていた(Photo21)。

Photo17: Standardに関してはUSB 1.1/2.0と3.0の両対応が必須だが、流石にMicroに関しては無理だったのだろう。

Photo18: Standard-A。USB 1.1/2.0が手前、奥がUSB 3.0であるが、着脱の際にうっかり両方の信号線が接触してしまったりしないのか、ちょっと心配。

Photo19: Standard-Aに比べると接触の可能性はなさそう。ただよくこの狭いところにこれだけのピッチで並べたなぁ、とは思う。

Photo20: 昨年におけるMicro-B/-ABのアイディアはこちら。どうも少し変化があった模様。というか、この２つ並んだものが最終的にMicro-Bになるのだろうか?

Photo21: 試作品はミツミ電機製のものだった。

その上位のLink Layerであるが、ここに関してはまだ内容がちょっと揺れ動いている感じだ。まずLink層の最終的な目標(Photo22)は、これはPCI Expressその他のHigh-Speed Serialとあまり変わらない。強いて言えば、電力管理が大きく前面に出ているあたりが、いかにもUSBといったとことか。では実装は? となると、Link LayerではLink Trainingとパケットフォーマット、エラーハンドリングなどが用意されることになる(Photo23)。ちなみにこのあたり、今年春の時点の内容(Photo24)を見ると、PCI Expressそのままという感じだったので、だいぶ内容の検討が進んだということだろう。

Photo22: もっともPCI Expressは現時点ではここまで積極的なPower Managementは入っていない。このあたりがシビアになるのはGen3世代の事になるだろう。

Photo23: Header PackerでLinkはともかくHostとDeviceが分離されるあたりがPCI Expressと異なる部分(PCI Expressではこんな区別はない)。このあたりは検討の結果追加されたものであろう。またLink Stateが4段階とかLFPSがサポートされたことも面白い。

Photo24: パケットの種類を見ると、まだ4月の時点ではPCI Expressのパケットフォーマットをそのまま使う方向が検討されていたようだ。ただPCI Expressの場合、特にFlow Control周りの負荷がかなり大きいから、このあたりもだいぶ簡略化したのではないかと想像される。

その上にProtocol Layerがくる(Photo25)。PCI ExpressだとTransaction Layerということになるが、ここは完全に独自である。春のIDFにおけるプレゼンテーション(Photo26)と比較すると、Flow ControlがProtocol Layerから削られてLink Layerに移ったことが判る。Packet Basicsを比較してみると(Photo27,28)、4月の時点では残されていたFlow IDが削られており、またRoutingに関する情報が多少減っていることが判る。

Photo25: Bulk/Control/Interrupt/Isochronousという4つの転送モードはUSB 3.0でも変わらない。ただし、Broadcast/PollingがUSB 3.0では削られていることが判る。

Photo26: PCI ExpressではFlow ControlがLink LayerとTransaction Layerの両方にまたがる形で実装されており、4月の時点ではこれをひきずっていたためかまだProtocol LayerにFlow Controlが残されていたが、今回はすっきりと削られた。

Photo27: こちらが今回のIDFでの情報。PacketはDevice Address、Endpoint Number、Directionの3つで指定される。また、Route Stringは残されるが、"Host initiates ALL data transfers"とはっきり明記されており、最終的なRoutingは全てHostが介在することになる。

Photo28: 4月の時点では、AddressにFlow IDが付いており、この時点ではまだFlow ControlをTransactionで行う気満々だったことが見て取れる。Route Stringの使い方はこちらの説明の方がわかりやすい。多分Route Stringの使い方は今も変化はないだろうと思われる。