インベンチュア株式会社
USB 3.0の高速伝送は、転送速度の向上だけで実現できたわけではない。また、論理層やアプリケーションにもUSB 2.0と異なるアプローチが必要となる。本連載では、USB 3.0のプロトコル面での改善点を中心に解説し、USB 3.0デバイスを実現するポイントを探る。（編集部）

連載一覧

第1回何が変わった？ USB 3.0プロトコル

第2回ホストとの接続はUSB 2.0？それともUSB 3.0？

第3回USB 3.0／USB 2.0論理層は何が大事？

最終回USB 3.0の追加ディスクリプタ、実機動作速度は？

はじめに

　前回までの連載で、USBがホストやケーブル、ハブなどの周囲や接続環境に影響されたうえで実際のバススピードが決まることが分かりました。特に下位互換性を維持するバスに共通していえることですが、可能な限り高速なスピードでの接続が求められます。

　USB 3.0では従来の物理層と根本的に異なる仕様が追加されたうえに、下位互換性を保つことが必要ですので、ステートを用いた論理的なネゴシエーション仕様が盛り込まれました。それにより極力転送レートの高いUSB 3.0で接続されるような仕様であることを前回説明しました。

　今回はUSB 3.0制御フローやアーキテクチャに着目してUSB機器（USBデバイス）の実現について検討したいと思います。

USB 3.0の実現方法の前に

　USBインターフェイスを持つデバイスを実現するにはどのような手段があるでしょうか？ ASSPは適用ターゲットが限られていますので、現状のUSB 3.0の実現手段は自社開発、もしくはIP（知的所有権：Intellectual Property）のライセンスが選択肢として挙げられます。

　また、USB 2.0はすでに実績がある資産（ハード／ソフト含め）を所有している場合、USB 3.0部分だけアドオンできないかと考えられる方もいらっしゃいます。ただし、下図（図1）のようにUSB 3.0だけをアドオンすることはお勧めできません。

　前回ご説明したような論理的なネゴシエーションを新規開発し、USB 3.0動作時のみのソフトウェア開発を行う必要があるからです。結果的には非常に多くの開発コストが必要になることが見込まれます。

　やはりUSB 3.0は下位互換も含めてUSB 3.0ですので、USB 2.0部分も併せて導入されるべきだと思います。

図1　USB 2.0とUSB 3.0の実現

実際のUSBデバイス機能開発

　USB 3.0のような新しいバスを採用し、かつ下位互換を持つデバイス／製品を開発する場合、新しいバスを採用する最大の理由である高速転送を、いかに容易に実現するかがキーとなります。

　USB 2.0の10倍の転送速度をうたうUSB 3.0ですので、標準Classも含めた通信プロトコルや上位のソフトウェアはいままでの資産を生かせるかもしれません。ただし、デバイス内部では、USB 2.0基準にUSBインターフェイス論理（USB MAC）をUSB 3.0に入れ替えたとしてもUSB 3.0の実力を発揮できないデバイスとなることでしょう。インターフェイススピードに応じたデバイス内部のアーキテクチャを見直さなければなりません。よって、最初に浮かび上がるキーポイントは以下になります。

バススピードに依存しない制御フロー／データ転送フローの維持

　上記を議論する前に一度視点を変えて、USBバスの転送に用いる転送先指定方法についておさらいしましょう。USBではデバイス内部にEndpointと呼ばれるRAM領域を配置し、ホストはこのEndpointを指定して通信を行います。実際にホストからUSBバスの通信相手を指定する手段は、デバイス番号とEndpoint番号になり、一般的なアドレスの概念はありません。

　また、デバイス内部で考えた場合、USBデバイス機能を実現するアプリケーションはこのEndpointと呼ばれるRAM領域とデータのやりとりを行います。EndpointはUSBインターフェイス論理（MAC）の一部であり、あくまでUSB通信に必要な領域ですので、デバイス内部ではこのUSB MAC内のRAM領域は、アクセシビリティの低いUSB専用FIFOのように映ります。

　また、EndpointはFIFOライクな構造となりますのでデバイス開発者は何らかのローカルバスを用いてCPUやそのほかのモジュールをローカルアドレスにメモリマッピングするのが一般的です。

　ではUSB 3.0に限らず、USBインターフェイスを備えたデバイス内部に着目したとき、デバイスを開発するうえでのキーポイントはどこにあるでしょうか？

　以下に挙げる2点がアーキテクチャ改善に直結すると考えています。

　　■Endpointと呼ばれるRAM領域の存在定義とアクセシビリティの向上

　　■バスマスタとデバイス内部へのローカルアドレス付与手段

図2　USB Endpointとデータパス

バススピードと制御フロー

　USB 2.0でも同じことがいえますが、USB 3.0でも接続して実際に転送が始まるまでバススピードは分かりません。USB 2.0のときはFS、HSでは転送レートはもちろんですが、最大パケット長やフレーム内パケット数の相違以外は、プロトコルの小追加（例えばPINGシーケンスなど）でした。

　しかし、USB 3.0の場合、シリアルバスの物理的な通信方式が大きく変わったのと、USBが抱えていたプロトコルの問題が改善されており、前々回、プロトコルの改善点としてリクエストとハンドシェイクのパケットが共有化された点を解説いたしました。

　ここでは、最も転送フローの違いが分かるのは例として、コントロール転送を挙げます。コントロール転送はセットアップステージ／データステージ／ステータスステージから成り立ち、ステータスステージまで完結しないとそのすべての転送は正常終結と見なされないことが特徴です。

図3　USBコントロール転送（USB 2.0）

図4　USBコントロール転送（USB 3.0）

　上の図から特にシーケンスが異なるのはステータスステージだとお気付きになられたでしょうか？ USB 2.0まではステータスステージはデータステージのデータ転送方向の逆となり、ステージを解釈する1つの指針ともなっています。USB 3.0ではTP（Transaction Packet）ステータスステージを意味するフィールドが存在し、容易にデータステージとの区別が付けられるようになったため、プロトコル面ではよりシンプルになりました。

　また、ステータスステージの正常完結はコントロール転送の完結を意味しますので、ステータスステージの正常完結時にデバイス設定／状態を変更しなければならないケースがあります。最も代表的な標準リクエストであるSET_ADDRESSのステータスステージが完結して初めてホストに割り振られたデバイスアドレスをデバイスに反映させる必要があります。

　このようにコントロール転送は一般的にデバイスの情報をホスト、さらにいえばOSとやりとりをする重要なもので、デバイス内部にCPUを配置して柔軟な対応が可能な実装をすることが多いものです。

　これをUSBのバススピードごとにソフト／ファーム制御フローが異なっていたらどうでしょうか？設計だけでなく検証や接続性に十分な時間と作業が必要となることは明白です。やはりこのような転送上の差異はUSB MAC部でうまく吸収して制御フローは共通化されていることが望ましいでしょう。

　デバイスにとってのステータスステージの応答制御とは以下に分類されます。

　　■USB 2.0：OUT Token/Out Dataに対して正常であれば、ACK応答を行う。In Tokenに対して正常であれば、Nullパケットを送信する

　　■USB 3.0：StatusTPに対して正常であれば、ACK応答を行う

　また、ステータスステージの完結を意味するイベントは以下に分類されます。

　　■USB 2.0：OUT Token/Out Dataに対して正常であれば、ACKを送信する。In Tokenに対して正常であれば、Nullパケットを送信し、正常なACKを受信する

　　■USB 3.0：StatusTPに対して正常であれば、ACKを送信する

　上記にとらわれないステータスステージの応答制御をUSB MAC側で吸収し、ステータスステージの完了条件にとらわれない完了イベント通知を行うことがこの例でいう共通化／共有化と考えます。USBデバイスの開発を容易化するのはこのような共有化の積み重ねていくことで、USB内のソフトウェア（ファームウェア）も共通フローで実装することが可能になります。

　これは一例となりますが、USBはどんなバススピードであっても、制御フローも完全に共通化し、USBバススピードを意識する必要がないことが重要であると考えています。