USB 3.0の最後はホストコントローラの話である。第1回目に触れたとおり、XHCI Revision 1.0が2010年5月21日に発表され、原理的にはどのベンダーもこれに準拠したUSB 3.0のコントローラを作成・発売できるようになったハズなのだが、現時点で製品の形でリリースされているのはルネサスエレクトロニクスの製品のみである。ということで、このあたりから説明してゆくことにしよう。

　余談ながら第1回目で「『当面IntelはxHCIコントローラを内蔵した製品を出せそうにないため、Revision 0.95のまま保留しておいても意味がなく、Revision 1.0を公開した』というあたりではないかと想像される」と書いたが、やはり予想通りIDF Fall 2010ではUSB 3.0に関する新しい発表はほとんどなく(テクニカルセッションでセキュリティに関する考察とAV Classに関する話、それとまもなくSpecificationアップデートがあるという予告がなされた程度。ちなみにこのアップデートはエラッタの対応がメインとなるようだ)、そんなわけで当面はディスクリートのまま行くことになるのだろう。

　さて、話を元に戻す。第1回目にも触れたとおり、(USB 3.0を含む)USBの仕様書はいずれもホストコントローラに関しては「こうあるべき」という要件のみをまとめており、それをどうインプリメントするかについてはベンダー任せとされている。実際、電気的に言えばUSB 1.1/2.0とUSB 3.0では異なる信号を扱う関係で、説明図はこんな具合にUSB 1.1/2.0のコントローラとUSB 3.0のコントローラが内部的に分離した形で示されており、当初はこうした形でのインプリメントが進むことになると思われていた。実際、このあたりの対応は各社各様である。

　ルネサステクノロジはとりあえず措いておくとして、最近ちょっと話題になったFresco Logicの場合、当初はこんな具合(写真2)になっており、xHCIコントローラを実装するつもりであったことがわかる。対照的なのがPLDA(写真3)のそれで、内部的にUSB 2.0とUSB 3.0が別々に分かれている事が見て取れる。実はこうした構造は珍しくない。ホストコントローラに関しては他にもArasan(写真4)やGDA(写真5)などから製品アナウンスがあるが、いずれも内部的にはUSB 2.0とUSB 3.0のパートが分離できるようになっているのがおわかりいただけよう。

【写真1】これはUSB 3.0 SpecificationのFigure 3-1より抜粋。この図のタイトルはUSB 3.0 Dual Bus Architectureで、これだけ見ていれば中に2種類のコアがあるように思える	【写真2】これはIDF Fall 2008の折にFresco Logicが配布していたパンフレットからの抜粋。当時はまだ同社がIP売りを模索していた時期である

【写真3】PLDAのUSB 3.0 ホストコントローラの内部構造。これも同社のパンフレットからスキャンしたもの。点線の部分はオプション扱いでの提供となる	【写真4】これはArasanのUSB 3.0 Host IP Coreのパンフレットより抜粋。一応同社によればxHCI v0.9 compliantだとしている	【写真5】GDAのUSB 3.0 ホストコントローラの仕様より抜粋。ただし同社のサイトにはこの仕様のページが無いというあたりが謎である

　なんでこんな風になっているかといえば、特にIP売りの場合には、「顧客が既に持っているUSB 2.0 ホストコントローラのIPはそのまま使いたい」というケースがあるからだ。また、USB 3.0のSpecificationには沿わないが、とにかくUSB 3.0でのみ繋がれば良く、USB 1.1/2.0の互換性はいらない(その分実装のゲート数を減らしたい)なんて要望も組み込み向けには当然ありえる。これは別にホストのみでなく、デバイス側にも当然ありえる話である。

　例えばインベンチュアはUSB 3.0のデバイスIPの提供を開始しているが、ここにも明確に「規格から逸脱を承知でUSB 3.0 MACのみ実現し、実装リソースの削減」という文言が示されている。こうしたデバイスを「USB 3.0互換」として販売するのは問題だが(そもそもコンプライアンステストに通らないだろう)、組み込み向けなどでは普通に要求のある話である。実際、例えば機器の内部でデバイスを接続するのに、広帯域のバンド幅が必要なのでUSB 3.0を選ぶなんてケースでは

・そのデバイスを他のUSBホストに繋いだり、逆に他のUSBデバイスをその機器内部で繋ぐことは考慮する必要がない
・そもそも広帯域が必要でUSB 3.0を選ぶ以上、USB 1.1/2.0で繋がっても要求を満たせない

　という事情があるから、USB 1.1/2.0のIPを実装するための動機に欠ける事になる。こうしたケースではUSB 3.0のみをホスト/デバイスに実装することで実装コスト(というかASICやFPGAのゲート数)や相互接続性テスト(USB 3.0同士だけをテストすれば済む)を節約することを選ぶユーザーは少なくないだろう。こうした向きにIPを提供する場合、USB 2.0を切り離せないのはむしろデメリットとなる。

　もっとも、こうした製品がそのまま一般マーケットに流れてしまうと、相互接続性の問題が出てしまうことになる。その代表例がFresco Logicの「FL1000G」である。もともと同社は2009年9月にFL1000という最初のコントローラをリリース、2010年5月には2ポートのFL1009を発表しているが、実はどちらのコントローラもxHCIに完全準拠ではない(厳密に書けば、xHCI準拠を目指して作ったにも関わらず、実装が一部間に合っていない)ため、一部の機能を殺して利用されることになった。

　FL1000Gは、FL1000にGoXtreamというxHCIのアクセラレータ(これはFL1009で初めて実装された機能)を搭載したものらしいが、このFL1000GでもまだxHCIの実装不足があったようで、結果としてUSB 3.0では繋がるがUSB 2.0では繋がらない、なんて状況のままであったりする。もちろん組み込み向けにはこれでもそれほど問題なかったりするのだが、ASRockの「890GM Pro3」のように一般向けのマザーボードに実装されてしまったりすると、これは当然互換性の問題が出てくることになる。

　もっともこのASRockの製品に関しては、悪いのはFresco LogicというよりもASRockな気がするのだが。というのはFresco Logicは当然USB 2.0では動作しないことをASRockに伝えているはずで、それをわかっているからASRockは意図的に“USB 3.0 Certified”に良く似た、ただしCertifiedの文言が入っていないロゴを基板上に載せていると考えられるからだ。

　とはいえ、当初からxHCI準拠を謳いつつ、未だに実現できないFresco Logicにも問題があるのも事実で、それもあってIDF Fall 2010のタイミングにあわせて、AMIと共同でxHCI Revision 1.0準拠のコントローラの開発を行なうというリリースを出したものと思われる。なので、今年はムリにしても2011年以降は、Fresco Logicのホストコントローラもまともになる(既存の製品がBIOSアップデートなどだけで対応できるか? はちょっと不明である。普通に考えると無理そうな気もするのだが……)と思われる。

　さて、最後に「ではなんでそんなにxHCIが大変か」という話を簡単にご紹介したい。もともとUSB 2.0ではホスト側のCPUの負荷が大きいとか、最近だと仮想化に対応していないのも問題となりつつあった。

　特にCPU負荷に関しては、USB 2.0の60MB/secですらCPUへの割り込み頻度が非常に多く、これが結構な問題になっていた。厄介なのは、純粋にCPUパワーの問題というよりは割り込み/復帰が煩雑に行なわれるという問題であり、単にCPUの性能を上げただけではムリで、根本的にはOSにおける割り込みのハンドリングのあり方を見直さないと対応が難しい。ところがこれは言うまでも無く副作用が大きい。

　ものすごく古い話になるが、Windows NT 3.51→Windows NT 4.0でGDIなどがユーザーモードからカーネルモードに移される、という話があった。これは描画を高速化するのに、ユーザーモードのままだとオーバーヘッドが大きいので、カーネルモードの中で全部済ませる事でオーバーヘッドを削減するというものだったが、同じようにUSBの割り込みを少ないオーバーヘッドで処理できるような仕組みを用意しないと、CPUの負荷率が高い問題の解決は難しかった。

　そんなこともあり、xHCIではホストコントローラのあり方が完全に変わった。まずこれまでと異なり、USB 1.1/2.0/3.0が一括して管理されるようになった(写真6)。xHCIは接続されたデバイス毎にこのInstanceを生成し、そのInstanceがそれぞれデバイス毎に必要なパラメータを保持する形である。実のところ信号線そのものは異なるとは言え、USB 2.0 デバイスとUSB 3.0 デバイスが同時に通信を行なうことはないから、管理は1カ所にまとめて、デバイス毎に通信方法を切り替えながら処理をさせてゆくほうが効果的である。

【写真6】これはxHCI Revirion 1.0のFigure 2より。xHCIでは仮想的なBus Instanceでデバイスを管理するようになった。というか、他にもさまざまなコンテキストを内部で生成・利用するようになっており、ASICの内部構造というよりはソフトウェアで構成されるドライバみたいな構造になりつつある	【写真7】これはxHCI Revirion 1.0のFigure 3より。USB 2.0の場合、１つのTransfer Ring(というか、Transfer Queue)をぐるぐると「ソフトウェアで」回す形となっていた

　これにあわせて、実装も大幅に変わった(写真7)。xHCIでは複数のTransfer Ringが保持され、それぞれが独立で制御、転送を管理することになるのだが、ここで重要なのはTransfer Ringの実際の転送そのものはxHCIのホストコントローラが管理する形に変更されたことだ。

　USB 2.0まではキュー構造の管理や、実際にキューからエントリを取り出して転送を掛けたりする処理をベースドライバ(つまりホスト側のCPUだ)が行なうような実装を前提としていた。ところがxHCIはちょうどDMAコントローラのように、ホストCPUは転送の命令を下すだけで、実際の処理はxHCIのハードウェアが行なってくれるようになった。これだけでも大幅にCPU負荷が減る事になった。加えて3回目に説明した通り、USB 3.0ではAsynchronous notificationsと呼ばれる仕組みでポーリングの必要性を廃したため、転送命令を出す頻度そのものも減っている。結果、USB 1.1/2.0では転送速度そのものは上がらなくてもCPU負荷は大幅に減る、USB 3.0では効率よく転送を行なえる仕組みが整ったことになる。

　これだけのものをASICでインプリメントするのは、しかしながら当然大変である。実際ルネサスエレクトロニクス(というか、旧NECエレクトロニクス)はかなり初期からIntelと共同でxHCIコントローラのインプリメントを行なっていたが、「最初は既存のUSB 2.0の資産を利用できると思っていたが、最終的には全部作り直しになってしまった」と以前語っており、実装は容易ではなかったようだ。実際仕様を見ていると、内部にMCUを入れてソフトウェアで実装すればまだ実装は容易だろうが、今度は性能と消費電力の観点で難がある。USB 2.0までの速度ならばまだMCUを内蔵させても速度的に間に合うかもしれないが、5GT/secの信号のハンドリングではまず間に合わないだろう。なるほど、ホストコントローラがほとんど出てこないわけである。

　とはいえ、既にルネサスエレクトロニクスの製品もプロセスの微細化による省電力化を図った第2世代の「μPD720200A」となっている。こちらはまだxHCI Revision 0.96準拠なので、近いうちにRevision 1.0準拠のものに上がる可能性はあるが、Revision 0.96とRevision 1.0の差は4カ所しかなく、明確な修正は1カ所(Skip Link TRB ICO flagの扱い。Revision 0.96では未定義だったものを定義した)。残り3カ所は、Revision 0.96ではOption扱いだったものを必須扱いにしたというだけで、ほとんど同じと考えて良い。Fresco Logicは上述のようにRevision 1.0相当のコントローラを現在開発中であり、既にある程度動作するシリコンを出荷している現状を考えると、2011年位にはまともに動くコントローラがでてくるだろう。一方TIは「TUSB8040」をアナウンス済で、VIAは既に「VL810」を発表するなど、USB 3.0 Hubの準備も出来つつあるので、近い将来にはUSB 3.0ポートを4ポート以上持つマザーボードなどが登場してもおかしくない状況である。まだ低価格帯製品にはちょっと辛いUSB 3.0であるが、2011年は更に普及してゆくと考えて良いだろう。