もう少しだけ、内部の実装の話をしたい。USB 3.0では当初から省電力化が拡張項目の1つに入っていた。こういうと、USB 1.1/2.0はまるで省電力ではないかのように聞こえるが、実際はUSB 1.1/2.0共に「当時は」十分省電力なI/Fだったのである。USB 2.0が登場したのは2000年4月で、当時のマザーボードはまだAGP/PCIに加えてISAバスが平然とくっ付いていた時代だから、そもそもI/Fレベルで省電力なんて何も考えていないも同然だった。まがいなりにもPCのシステムレベルの省電力が議論の対象になるのは、その後ISAバスが撤廃され、更にCPUの省電力機構が普通に利用できるようになり、加えてACPIがまともに実装されてからの話である。こうした動きはノートPCでまず顕在化し、やっと最近はデスクトップPCでもこうした話が言われるようになったわけだが、何しろ10年前のバス規格だから、省電力に対応していないことを責めるのは酷だろう。

　さてUSB 3.0での省電力の仕組みとは、要するにUSB 3.0で接続しているデバイスを省電力モードに(ホスト側から)入れたり、あるいはデバイスが自発的に省電力モードに入る場合にこれを正しくハンドリングすると共に、デバイスが省電力モードから復帰する場合にこれをサポートする、ということになる。

　もう少し具体例を挙げてみよう。例えばUSB 2.0でバスパワーで動くHDDを考えてみる。このHDDの場合、5V/500mAの電源をバスから取って、接続中は常にHDDの電源がONになったままである。つまり接続すると最大で2.5Wほどを常に消費し続けることになる。もちろん技術的な観点で言えば、USB I/Fの先のSATAコントローラ(と必要ならこれを駆動するドライバ)に作りこみをすれば、アクセスが無い間はモーターの回転を止めるといった細工は可能(ごくわずかにこうした機能をサポートしたUSB HDDケースも存在する)だが、当然標準のドライバで動かないといった問題も出てくるわけで、この手の機能は標準的に盛り込まないと使ってもらえないのが実情である。

【写真1】2009年のUSB-IF Developers Forumで公開された資料から。USB 2.0(High Speed)とUSB 3.0(SuperSpeed)で、20MB/secで転送を行なうと試算した場合のSystem Powerを示したものである。System Powerなので、ここにはUSBの通信以外の消費電力も含まれていることに注意。USB 2.0の実効転送速度を40MB/sec、USB 3.0を333MB/secと仮定しているあたりが面白い

　また、この方式の実装でも、USB I/F自身はフルに動くことになってしまい、この部分の省電力化は図れない事になる。写真1は消費電力の比較例であるが、転送を行なう際の絶対的な消費電力という意味ではUSB 3.0の方がやや多く(13W)、ところが転送速度そのものはUSB 2.0の方が遅いので長時間に渡って12.5Wを維持することになる。USB 2.0では頻繁にホストからの問い合わせが来て、そのたびに返事を返す必要があるから、平均消費電力はどうしても上がりやすいことになる。USB 3.0にすることで通信時間の短縮を図り、平均消費電力を下げることは可能だが、そもそも通信頻度が絶対的に多いのが問題である。

　そんなこともあり、USB 3.0では３段階の電力管理機構を搭載している。具体的には

・LINK PM(Localized Link Power Management)：物理層～リンク層～プロトコル層
・Device PM(USB Device Power Management)：プロトコル層～ホスト/デバイスレベル
・Host PM(USB Function Power Management)：ホストレベル

となっており、それぞれ個別に電源管理機能を提供する形だ。

　まずLINK PMであるが、ここはUSBのLinkそのものの管理を行なう。LINK PMはU0～U3の4段階のStateを持っており、

・U0:Link active(レイテンシ0)
・U1:Link idle, fast exit(μsオーダーのレイテンシ)
・U2:Link idle, slow exit(数msオーダーのレイテンシだが、μsオーダーも可能)
・U3:Suspend(msオーダーのレイテンシだが、μsオーダーも可能)

と規定されている。このあたりはACPIでCPUのステートに使うC0とかC1とかにかなり近い。U0は全ての回路を稼働状況においているため、消費電力は一番多い。U1は通常送受信回路を止める(単にクロックの供給を止める程度)、U2は更にPLLなどを止めるレベルで、U3になると電源まで止めると考えればよい(この辺りはあくまでもインプリメントに依存するが、USB 3.0の仕様におけるインプリメント例がこんな感じである)。通信を実際に行なうのはあくまでU0の場合のみである。

　U0→U1/U2/U3は、相手先ポートにそれを通知したらすぐに入れるが、逆にU1/U2/U3→U0に戻る場合は、通信が正しく再開できるかどうかを確認する必要がある。その第1段階が、「USB 3.0の速度で通信が出来るか」という確認で、だからといっていきなり5GHzで転送を始めても同期が取れない場合がある。そこで(前回もちょっと触れた)LFPS(Low Frequency Periodic Signaling)と呼ばれる方法でのハンドシェイクをまず行なうことになっている。このLFPSはUSB 3.0で導入されたもので、LFPSのハンドシェイクを行なってくれる相手は間違いなくUSB 3.0に対応しているということで、そこからUSB 3.0での通信再開を開始する仕組みだ。このLFPSもまたLINK PMの一部である。

　ちなみにU0→U1/U2/U3の遷移は上位からのリクエストで行なう場合もあるが、Link層が内部に持っているタイマーを使って自動的に遷移する場合もある。無通信のまま一定時間経過すると、省電力状態に入るというわけだ。ただ、前回の図2のように、トランザクションの中に入っている際に勝手にU1～U3に落ちてしまうと転送に差し支えるので、こうした場合にはタイマーで勝手にU0に落とさないことも可能だ。

　Device PMでは、サスペンド/復帰のためのAPIが提供されている。細かいパワーモードまで提供しても、デバイスそのものがそれを利用できるかどうか不明というあたりもあってか、標準で提供されるのはサスペンド/復帰のみで、これ以上きめ細かい部分はデバイス自身のインプリメントに任せる形だ。もっともUSB 3.0そのものがデバイスのサスペンドをサポートするわけではなく、デバイスがサポートされたAPIを呼び出すと、USB 3.0のI/Fもまたサスペンドされるというだけである。細かいところではSelective Suspend(USBカードリーダのように、1つのUSBポートに複数のデバイス、というか、USB用語で言うところのDevice Function)がぶら下がっている場合がある。こうしたものについては、全体をまるごとサスペンドする事もできるし、特定のDeviec Functionのみをサスペンドすることも出来る。

　一方の復帰だが、これはホストの方からWakeupを掛ける(Host initiated wakeup)事も、デバイス自身が復帰する(Remote wakeup/device initiated wakeup)事もできる。例えばPCでサスペンドを掛けるような場合、当然周辺機器もまとめてサスペンド状態に入れる事になるが、PCが復帰する際にはやはり周辺機器も復帰しないと都合が悪い。こうした場合には前者を使い、PCに繋がっている全てのサスペンドしている周辺機器を復帰することになる。このPCの復帰をキーボードあるいはマウスの動作で解除しようと思った場合、そのマウスなりキーボードは移動あるいは操作といったトリガーによりデバイスを復帰し、ついてDevice initiate wakeupを使ってUSB I/Fを復帰することでホストを起動するわけだ。(Device initiate wakeupの場合、USBコントローラにその通知が渡るため、これをトリガーにPC本体を立ち上げることも出来る)。この場合問題になるのは「そのキーボードなりマウスはどういう電源で動作するか」である。セルフパワーデバイスなら別に問題はないのだが、バスパワーだと、サスペンド状態では電源の供給が大きく減らされることになっている。

　ちょっと話が前後するが、ご存知の通りUSB 2.0ではポートあたり最大500mAまでの電源が供給できることになっている。(充電用の規格であるBattery Charging Revisionとはまた別の話である)。これがUSB 3.0の場合900mAまで増やされているのだが、この数字はあくまでU0 Stateにおけるものである。サスペンド中の場合、デバイスあたり2.5mAが許されている消費電流である。もっとも「一瞬だけフルに消費電流を使いたい」というニーズには対応しており、下記を条件に、もう少し消費電流を使うことが可能になっている。

・平均時間(通常1秒間)あたりの消費電流が2.5mAを超えないこと。
・最大電流は150mA(USB 2.0)ないし900mA(USB 3.0)を超えないこと。
・ピークの立ち上がり/立ち下がりのレートが100mA/μsを超えないこと。

なので、Device initiate wakeupを行ないたいバスパワーデバイスの場合、この仕組みを使って一瞬だけデバイスを動かし、復帰を掛けるといった仕組みを実装する形になると思われる。

　最後がHost PMである。デバイス管理という観点で見ると、U3になったデバイスは無視できるのだが、U1/U2状態のデバイスは無視できない。これは特にIsochronous Transferの場合に問題になってくる。Isochronous Transferの場合、一定時間毎に必ず通信が必要になるが、先に書いたとおりU1/U2状態にあると復帰まで数μs～数msのレイテンシが発生するので、タイミングによっては復帰が間に合わない場合がある。これを防ぐため、HostはIsochronous Transferに先立ち、PINGパケットを配下の(Isochronous Transferを行なう)デバイスに送る。受け取ったデバイスがU0 StateならばすぐにPING Responseを送り返せるが、U1/U2ステートのデバイスはまず復帰を掛け、その後にPING Responseを返す形となる。このPING/PING Responseの送受信を行なうことで、Isochronous Transferが必要なデバイスを強引にU0ステートにし、確実にIsochronous Transferが行なえるようになるという仕組みだ。またHost PMとは直接関係ないが、ホストはまた定期的にTimestamp packetと呼ばれるものを(U0状態のデバイスに)送る仕組みが提供されている。

　加えて、更に積極的に電力管理を行なうための仕組みとしてLTM(Latency Tolerance Message)と呼ばれる仕組みも搭載されている。これはデバイスがBELT(Best Effort Latency Tolerance)という値を個別にレポートするものだ。標準でBELTの値は1msで、つまり1msごとにホストがデバイスに対してアクセスすることを期待するという意味だが、「もっとアクセス頻度を減らしても行ける」というデバイスは、例えばBELTに2msとか3msとかを入れてHostに送ることができる。これを受けてホストは、そのデバイスに対するアクセス頻度を減らす事が可能で、これにより潜在的に消費電力を下げる事が可能になるというわけだ。

　このようにUSB 3.0では大幅に電源管理機能が強化されているのだが、USB 3.0が普及してくるとUSB 3.0ホストにUSB 2.0 デバイスを繋ぐというケースも増えてくるわけで、こうしたときにUSB 2.0 デバイスが電源管理に未対応だと、USB 2.0にあわせた形で動作させざるを得ず、結果としてUSB 3.0の電源管理をフルに使えない可能性がある。これに対応するため(という言い方も変だが)、USB 2.0にもECN(Engineering Change Notice)の形でLPM(Link Power Management)Addendumが2007年7月に公開された。タイミング的にはまだUSB 3.0はリリースされていない(なにせUSB 3.0の存在が公開されたのが2007年9月だ)ため、“Reasons for ECN”(ECNを発行する理由)は「USB 2.0の電源管理は原始的すぎ、複数の電源モードを持つ最近のPCには十分ではない(意訳)」とされているが、L0～L3という4種類のLink Modeを持つところとか、各Link StateのState Machineの構造などはUSB 3.0と非常に酷似している。少なくともUSB 3.0の電源管理は、このUSB 2.0のLPMを下敷きにしたと考えてよさそうだ。

　もっとも既存のUSB 2.0対応ホスト/デバイスがこれにあわせて製品をリビジョンアップすることは正直考えにくい。むしろメインは今後登場するUSB 3.0 ホスト/デバイスであろう。これらは何れもUSB 2.0互換を保つ必要があり、従ってUSB 2.0 I/Fを搭載する。デバイス自身が色々な電源管理モードを持つようなものであれば、USB 2.0で接続の場合もUSB 2.0 LPMを有効にする、という方向は一応ありそうに思える。

　ということでUSB 3.0の規格に関してはこれで総ざらえが終わった形だが、次回ちょっとホストコントローラに関する動向をまとめて御紹介したいと思う。