ホストとの接続はUSB 2.0？ それともUSB 3.0？：失敗しないUSB 3.0、規格解説と実現のキーポイント（2）（2/2 ページ）

接続を担うステートマシン

　USBにおいて接続の目的は、USB通信を行うための物理的接点の接触にすぎません。接続においてはUSB 3.0が追加されたことで、USB 2.0との下位互換性を維持しながら連携して進めるためのルールが定められました。

USB 3.0の視点での接続シーケンス

　レシーバ検出シーケンスにのっとり、USB 3.0バスの対向側に何らかの接続状態があるかを検出するところから始まります。対向側の存在を把握できた場合、トレーニングシーケンスを実施して、物理的／論理的にも接続状態を確認します。LTSSMにおいてU0ステートに遷移した段階でパケット通信が可能な状態となります。対向側レシーバが検出できない場合にUSB 2.0での接続可能性が発生します。

USB 2.0の視点での接続シーケンス

　USB 2.0では互換性維持の観点からいままでとシーケンスはまったく変わっていません。ただし、USB 3.0側が先行して接続するため、ホスト側にデバイスの存在を知らせるプルアップレジスタ接続を行うべきタイミング制御が追加されました。

　これらの接続シーケンスは独立して行いますが、それぞれが勝手に行うことは許されていません。そのシーケンスを定めたステートマシンと各ステートの役割について以下に解説します。

画像5　Peripheral Device Connect State Machine

PCONNECT.Powered-off

　画像5の真ん中のステートを指し、PCONNECT.Powered-offステートはperipheral deviceのdefault stateとなります。もし次の条件に合致した場合は、peripheral deviceはこのステートに遷移します。

• どのステートからも、VBUSが切断された場合

　このステートでは、USB 3.0ポートのリンクはSS.Disabledステートにあるものとし、そしてUSB 2.0プルアップは適用されません。

PCONNECT.Attempt SS Connect

　初期状態からVBUSを検出したステートとなります。ポートは次の条件に合致した場合、このステートに遷移します。

• PCONNECT.Powered-offステートから、VBUSが有効になった場合（ローカル電源含む）

　このステートでは、USB 3.0ポートのリンクはRx.DetectまたはPolling、そしてUSB 2.0プルアップは適用されません。よって、USB 3.0のレシーバ検出が先行されるような制御が行われます。

PCONNECT.Connected on SS

　レシーバ検出が正常に終了して、論理的にも通信可能な状態（U0）のステートとなります。ポートは次の条件に合致した場合、このステートに遷移します。

• PCONNECT.Attempt SS Connectから、リンクがPollingからU0に遷移した場合
• PCONNECT.Connected on USB 2.0ステートから、USB 3.0 LinkがPollingからU0に遷移した場合

　このステートでは、USB 3.0ポートのリンクはU0、U1、U2、U3、Inactive、Rx.Detect、Recovery、またはPollingにあり、USB 3.0の通信可能状態（省電力モード含む）となります。よって、必然的にUSB 2.0プルアップは適用されません。

PCONNECT.Connected on USB 2.0

　レシーバ検出が未完了のままタイムアウトし、USB 2.0での接続を試みるステートとなります。ポートは次の条件に合致した場合、このステートに遷移します。

• PCONNECT.Attempt SS Connect、PCONNECT.Connected on SS、またはPCONNECT.Connected on USB 2.0 Attempting SSステートから、Rx.DetectまたはPolling sub stateがタイムアウトした場合

　このステートでは、USB 3.0ポートのリンクはSS.Disabledにあり、USB 2.0プルアップが適用されます。

PCONNECT.Connected on USB 2.0 and Attempting SS Connection

　USB 2.0での接続シーケンス中に、USB 3.0のレシーバ検出を再度試みる特殊なステートとなります。ポートは次の条件に合致した場合、このステートに遷移します。

• PCONNECT.Connected on USB 2.0ステートから、USB 2.0 Bus Resetが受信された場合

　このステートが大きなポイントとなります。USB 2.0ではBus Resetは特別なものではありませんので、何度でも、USB 3.0ポートではRx.DetectまたはPollingとしてリンクの形成を試みます。その間もUSB 2.0ではプルアップが適用されていますので、USB 2.0リンク形成は別に進行するため、仮に、USB 3.0ポートのリンクがPollingからU0に遷移したならば、デバイスはUSB 2.0プルアップを切断して、USB 3.0へ移行することができます。

　レシーバ検出は電圧値を基にしたアナログ的なイベントです。一般的には考えられませんが、閾値を境にバススピードが一定に定まらない可能性のあるステート遷移条件となっています。

バス接続後の注意点

　アプリケーションレベルではバススピードの決定はいつ、どのように考えるのが適切でしょう。インベンチュアではUSB 3.0でもUSB 2.0でも最初に通信可能な状態をバススピードが決定されたと位置付け、ホストからパケット受信可能な状態と考えています。制御をより簡単にするために共通で処理が可能なパケットを考えた場合、USBでは定期的に受信するパケットSOF/ITPが適切だとしています。

　全体的なフローを考えると以下のとおりです。

1. VBUS接続
2. Bus Reset/Warm Reset
3. 通信可能状態
4. SOF/ITP受信（⇒バススピード決定）

　デバイス側のファームウェア含めたアプリケーションではバススピード決定の影響は初期設定時と通信時に分けられます。

初期設定時

• 標準リクエストの応答が異なる
• 最大パケットサイズが異なる

通信時

• 転送レートが異なる

　　⇒ データサイズの縮小

　　⇒ データの送信レートの間引き

　ストレージのように実効時間が変わることで対処可能なアプリケーションもあれば、Webカメラの動画転送のように転送データの画枠サイズ／画質／フレームレートなどへの制御に影響を与える場合もあり得ます。USB規格としては下位接続のサポートも必要ではありますが、場合によってはUSB 3.0のみ推奨というアプリケーションが存在してもおかしくありません（USB 3.0スピードしか期待しないアプリケーションであれば、USB 3.0以外で接続した場合にPC画面に“動作不可”と表示する極端な意見もお聞きしたことがあります）。

　いずれにしてもUSB 2.0で不足した転送レートを補うのがUSB 3.0バススピードで、転送レートが重要であるということに尽きます。

今回のまとめ

　USB 3.0とUSB 2.0での接続決定は単に物理的な条件だけでないことがお分かりいただけましたでしょうか？ 次回はUSB 3.0とUSB 2.0をサポートするデバイスを効率よく開発する論理層や転送レートを重視するアーキテクチャを紹介します。