基本仕様

USB2.0はUSB1.xとの互換性を維持したまま、より高速な動作の実現が求められているので、以下の4点をクリアできる仕様になっています。

  1. 480MbpsのBus動作を実現することでバンド幅を大幅に改善する。
  2. USB1.xとの互換性を維持するために、ケーブルやコネクタは変えない。
  3. 12/1.5Mbpsの転送と480Mbpsの転送が混在できるようにする。
  4. 12/1.5Mbpsの転送と480Mbpsの転送が混在しても、12/1.5Mbpsが480Mbpsのバンド幅を大幅に占有しないようにする。
USB2.0の基本仕様

IEEE1394との違い

USB2.0とIEEE1394の位置付けについて説明します。
従来のUSBはPC周辺の低中速のデバイスから、IEEE1394は高速なAV系デバイスから普及しています。低速のUSBのデバイスはコスト／パフォーマンスの点からUSB2.0のhigh-Speed modeに対応する事はないでしょう。これらはBluetoothなどの無線系におきかわるかもしれません。高速の動作レートが要求され始めているプリンタ、スキャナ、ストレージの領域では同程度の転送レートを持つUSB2.0とIEEE1394の競合が考えられますが、PCの周辺機器としてはUSB2.0が主流になるでしょう。USB2.0では従来の互換性を維持しており、例えば、USB2.0対応のPCがなかったとしても、USB1.1のデバイスとして使うことができます。すでに100%のPCに搭載されるようになったUSBと比べるとIEEE-1394はPCではまだまだ普及率は高くありません。ただし、USB2.0はPCと言うホストが存在しない限り、Busを構成できませんので、周辺機器同士の直接接続はできません。プリンタでもAVと直接接続するようなケースは、IEEE1394になるでしょう。 広義ではプリンタはプリンタですが、実際には目的ごとにインタフェースは選択されていくでしょう。

USB標準　1394オプション

電気的仕様

480MbpsのBus動作を実現するためには電気的な仕様の変更が、USB1.xとの互換性を維持しながら必要になります。 また、12/1.5Mbpsの転送と480Mbpsの転送が混在できるようにするために、プロトコルの変更が必要になります。また、USB1.xで目立つようになってきた 問題点も改善されます。

電気的な仕様は3.3Vでは480Mbpsの転送を実現できないため変更され、小振幅信号が採用されています。

USB2.0の電気的仕様

480MbpsのBus動作を実現するためには、Buffer内にある定電流源 17.88 mAを45Ωの両終端のラインに流します。これによって 22.5Ω × 17.88 mA = 402.3 mV の出力振幅を実現できます。

480Mbps eye pattern
回路図

EOPとSYNC

480MbpsのBus動作を実現するためには電気的な仕様の変更が、USB1.xとの互換性を維持しながら必要になります。 また、12/1.5Mbpsの転送と480Mbpsの転送が混在できるようにするために、プロトコルの変更が必要になります。また、USB1.xで目立つようになってきた問題点も改善されます。

USB2.0ではhigh-Speed modeとfull/low-Speed modeはIdle Stateを示す状態 が違います。full /low-Speed modeではIdle Stateは"J" Stateで 示されますが、high-Speed Idle Stateは"D+=D-=0" stateで示されます。これはfull/low-Speed modeでは"SE0"と呼ばれるstateと同じです。
SE0はfull/low-Speed modeではResetとpacketの終わりを示す"EOP"とDeviceの切断を示すために使われますが、high-SpeedはResetとhigh-Speed Idle Stateを示すために使われ ます。つまり、EOPを示すためのデリミタはhigh-Speed modeでは変更され、 Deviceの切断の検出も変更されます。full/low-Speed modeではpacketの終わりを示す"EOP"はSE0 2 bit times に続いて "J"になることで示されます。

full/low-speed mode

一方、high-Speedではpacketの終わりを示す"EOP"はStuffed bit insertionなしの8bit NRZ 01111111で示されるように変更されます。"EOP"を示すfirst symbolはEOP直前のlast symbolの反転値になり、EOP patternの終わりに、driverはD+かD- lineに流す電流を止め、lineをhigh-Speed Idle stateに戻します。

high-speed mode

high-Speed SOFに対するEOPは特殊なケースで、8bit長ではなく 40bit長となります。 これは、Deviceの切断の目的のために使われるものです。Deviceが切断された場合、Hubのダウンストリームポートから遠い側の抵抗45Ωが無くなることを意味します。しかし、high-Speed Idle StateではdriverはD+、D-lineのどちらにも電流を流さないので、このStateではDeviceの切断は検出できません。実際のDeviceの切断の検出はBusのtransaction中にしか行えません。40bit長と長いEOPを使う理由はケーブル端から反射した信号が送信端に戻ってくるまでの間、出力レベルを維持するためです。出力レベルが約600mVを越えたことでDeviceの切断と判定されます。

回路図

SYNCのパターンもUSB2.0では変更されます。full/low-SpeedではSYNCは8bitNRZI KJKJKJKKで示されていますが、high-Speedでは送信側でSYNCは32bit NRZI KJKJ KJKJ KJKJ KJKJ KJKJ KJKJ KJKJ KJKKに受信側では条件によって32-12bit長と可変になります。high-Speed modeでは400mVという小振幅の信号を使います。このためノイズかSYNCかの判定は、バスラインの変化だけでは行うことができません。USB2.0では初めの4symbolが期待のパターンと一致した時、初めてSYNCが開始したと認識します。このため、HUBを経由するごとに4bit分のSymbolが欠けていくことになります。結果として受信できるSYNCは32symbol - 4 symbol X HUBの段数になります。

Chirp Handshake

480MbpsのBus動作を実現するためには電気的な仕様の変更が、USB1.xとの互換性を維持しながら必要になります。 また、12/1.5Mbpsの転送と480Mbpsの転送が混在できるようにするために、プロトコルの変更が必要になります。また、USB1.xで目立つようになってきた問題点も改善されます。

USB2.0では仕様追加として480Mbpsの転送が規定されました。USB2.0ではUSB1.1の上位互換の仕様ですから、USB1.1のシステムにつないだ場合にも正常の通信ができなければなりません(装置としてfull機能を使用できるかどうかは別ですが)。これに対応した12Mbpsと480Mbpsの両方で動作できるデバイスがhigh-Speed capable deviceと呼ばれます。USB2.0では480Mbpsを実現するためにコネクタ、ケーブルが変更されることはありません。つまり、外見えに480Mbpsのシステムか12Mbpsのシステムかを判定することはできないのです。このため、ホスト、ファンクションの両方にとってどのような通信スピードで動作するかを示し合う必要があります。USB1.1までではファンクション側に接続されたプルアップ抵抗の位置によってfull-Speedとlow-Speedの判定していました。

Chirp handshake

high-Speedはプルアップ抵抗の位置でスピードを判定する方法は取れませんので何か別の方法が必要になります。デバイスはhigh-Speed capable deviceでも12Mbpsで動作できなければなりません。このことを利用して、すべてのデバイスはまずfull-Speed デバイスとして接続され、その後、利用できる動作スピードをホストとファンクションの間で確認しあうようになっています。これをChirp handshakeと読んでいます。Chirp handshakeは以下のようなタイミングでUSB Reset sequenceの間に行われます。

Chirp handsakeタイミング
Chirp handshakeタイミング

Chirp handshakeの終わりにファンクション側のプルアップ抵抗をoffにして、USB2.0 high-Speed bufferとして動作するようになります。
何らかの理由でhigh-Speed capable deviceにも関わらず、480Mbpsで通信できなかった時のために、SoftwareによるRetryの思想としてGet_Descriptor Device_QualifierとGet_Descriptor Other_Speed_Configurationが追加されました。

high-Speed modeではIdleとしてD+ = D- = Low　を使いますから、そのままではSUSPEND状態とUSBRESETの区別がつきません。
このため、以下のように規定時間以上のD+ = D- = Lowを検出したら、ファンクション側のプルアップ抵抗を有効にする事でSUSPENDかUSB RESETかの判定を行います。

SUSPEND/USBRESET判定

転送レートの違い

480MbpsのBus動作を実現するためには電気的な仕様の変更が、USB1.xとの互換性を維持しながら必要になります。 また、12/1.5Mbpsの転送と480Mbpsの転送が混在できるようにするために、プロトコルの変更が必要になります。また、USB1.xで目立つようになってきた問題点も改善されます。

USB1.xでは一つのエンドポイントに対するInterruptまたはIsochronous転送は1 フレームに1回以上は行えませんでしたが、USB2.0では一つのエンドポイントに対するInterruptまたはIsochronous転送は1 マイクロフレームに３回まのでの転送が許されます。このような転送に対応するエンドポイントをUSB2.0ではhigh-Speed, High Bandwidth Endpointと呼びます。USB2.0ではこの複数回の転送を実現するためにEndpoint DescriptorのwMaxPacketSize Fieldを以下のように変更しています。

Endpoint Descriptor wMaxPacketSize Field
Bits 15:13 12:11 10:0
Field Reserved Number of transactions per microframe Maximum size of data payload in bytes

この時、マイクロフレーム当たりの転送回数と1つのパケットのデータ　ペイロードには以下のような制約があります。

  1. transaction, Max packet size < 1024 bytes
  2. transactions, Max packet size 513-1024 bytes
  3. transactions, Max packet size 683-1024 bytes

USB1.x Isochronous転送ではData packetのPIDとしてDATA0(C3h)のみを使用していましたが、リトライの無いIsochronous転送で転送に失敗した場合にHigh Bandwidth Isochronous転送では、どのパケットが有効であったかを知ることができません。このため、DATA0(C3h)以外にDATA1(4Bh)、DATA2(87h)、MDATA(0Fh)の3つのPIDを新たに使うようになりました。

USB2.0 Isochronous transfers

なお、High Bandwidth Interrupt転送は通常と同じData toggle sequenceを使います。

PING と NYET

480MbpsのBus動作を実現するためには電気的な仕様の変更が、USB1.xとの互換性を維持しながら必要になります。 また、12/1.5Mbpsの転送と480Mbpsの転送が混在できるようにするために、プロトコルの変更が必要になります。また、USB1.xで目立つようになってきた問題点も改善されます。

USB1.xにおいてOut transactionにおけるNAK応答はTOKEN、DATA packetの転送が終了した後にしか発行できません。このため、ファンクション側の処理が遅くNAK応答の回数が多いデバイスを接続するとUSB busにOUT → DATA → NAKが多数発行されることになります。OUT → DATA → NAKは実際にUSB Busを占有する期間が長い上、データ転送としては無効ですから、USB Busでの実際の転送レートを低下させることになります。

USB2.0ではこれを解決するためにPINGとNYETと言う新しいパケットを仕様として追加しました。

PING and NYET

Bulk OUTデバイスに対して、ホストはまずPINGによってデータを受け付けるための空きBufferがあるかどうかを問い合わせます。ファンクションはデータを受け付けられないならNAK応答し、データを受け付けられるならACKで応答します。ホストはPINGに対してNAK応答を受信している限り、PINGを繰り返し送り、ファンクションの受信Bufferの空き状況を確認し続けます。
ホストがPINGに対してACK応答を受信したら、実際のBulk-out転送を行います。
ファンクションはこれに対してACK,NYET,NAK,(STALL)応答のいずれかで応答します。
ACK応答はさらにBufferの空きがあるので次のBulk-out転送を受け付けられることを意味しています。このため、ホストは連続してBulk-out転送を行います。NYET応答は、Bufferの空きがないため、次のBulk-out転送をすぐには受け付けられないことを意味しています。このため、ホストは次のBulk-out転送を行う代わりにPINGを送り、ファンクションの受信Bufferの空き状況を確認します。
NAK応答は基本的には使用すべきではありませんが、何らかの理由によりBufferの空きがなくなり、データ受信ができない場合には使うことができます。
このPING、NYETによって無意味にUSB Busのバンド幅を消費してしまうOut → data → NAKシーケンスの発生を防ぎ、効率的なUSB Busの利用を可能にします。

Split Transaction

480MbpsのBus動作を実現するためには電気的な仕様の変更が、USB1.xとの互換性を維持しながら必要になります。 また、12/1.5Mbpsの転送と480Mbpsの転送が混在できるようにするために、プロトコルの変更が必要になります。また、USB1.xで目立つようになってきた問題点も改善されます。

USB2.0ではUSB1.xとの上位互換を維持して、480Mbpsの通信を実現できるようにしています。
ホストのポートにfull/low-Speedのデバイスを接続する場合には、そのポート自身が12Mbps/1.5Mbpsで動作し、high-Speedのデバイスを接続する場合には、480Mbpsで動作します。この場合は特別な処理なしにhigh-Speed capable デバイスとfull/low-Speed デバイスを混在できます。しかしながら、USB2.0 Hubの下にfull/low-Speed デバイスを接続した場合、USB2.0Hubは少なくともupstream側の480Mbpsのパケットをdownstream側のfull-Speedの12Mbpsかlow-Speedの1.5Mbpsのパケットかdownstream側のfull-Speedの12Mbpsかlow-Speedの1.5Mbpsのパケットをupstream側の480Mbpsのパケットに変換する機能が必要です。USB1.x装置のプロトコルは変更できませんから、この状態ではupstream側が480Mbpsになっても、応答までの時間は改善されませんから、バスに占めるfull/low-Speed デバイスの時間は同じとなり、480Mbpsのレートを効率的に利用できないことになります。

480Mbpsの通信

これを改善するために、USB2.0ではsplit transactionと呼ばれる新たな転送を規定しています。split transactionはホストとUSB2.0のHUBの間でだけ利用される転送方法で、USB2.0 HUB以外のファンクションでは使用されません。split tranctionでは転送開始を示すstart-splitとホストに転送結果を伝えるcomplete-splitの二つのtransactionから構成されます。これによって、ホスト側ではfull-/low-Speedの応答を待つ必要がなく、USB2.0のバンド幅を効率的に使用することができます。

Split Transaction: IN Token
Split Transaction: OUT Token
Split Transaction : フレーム

スペックの差

ここでは、主なUSB1.1とUSB2.0の違いについて示します。詳細はUSBのスペックで確認下さい。

KEY USB1.1 USB2.0（HS Capability）
Signal 3.3V Differential 12/1.5Mbps 400mV Differential 480Mbps
Idle J - state SE0 (D + = D - Low)
SYNC 8 symbols 32 (12 min) symbols
EOP 2 X SE0 + J "0" + 7 "1" (39"1" for SOF)
Connect Position of pull-up R. FS->HS
Disconnect SE0 Voltage level of SOF EOP
Reset Long SE0 Long SE0 with chirp
Transaction SOF, Setup, In, Out SOF, Setup, In, Out, Ping, Split
Control 8, 16, 32, 64 byte 64 byte
Bulk 8, 16, 32, 64 byte 512byte
Interrupt 1 - 64 byte 1 - 1024 byte (1024 ×3 MAX )
Iso. 1 - 1023 byte 1 - 1024 byte (1024 ×3 MAX )
Get Desc. Device, Configuration Dev., Config., Qualifier, Other

ディスクリプタ

USBでは、各周辺機器をホスト側で正しく認識させるためにディスクリプタと呼ばれるデータを必ずもっています。各周辺機器のもっているディスクリプタは以下の７つ（USB2.0で２つ追加されました）になります。

種類 内容 各Descriptorの関連
Device
Descriptor

対応しているUSB Specのバージョン、Device Class、Device SubClass、Protocol、Endpoint 0に対する転送で利用可能な最大パケット長

  • ベンダID、製品ID、Deviceの版数、Configurationの個数
  • 各種String DescriptorのIndex
 どのデバイスにも必ず１つ存在。
Configuration
Descriptor

包含されるInterfaceの個数、Configurationを選択するためのConfiguration番号

  • デバイスの属性(電源供給方法)
  • 消費電力
  • 各種String DescriptorのIndex
 デバイスに１つ以上存在し、１つのConfiguration Descriptorに対して１つ以上のInterface Descriptorが存在。
Interface
Descriptor

Interfaceを選択するためのInterface番号

  • Alternative Settingの個数
  • 包含されるEndpointの個数
  • Interface Class、Interface SubClass、Interface Protocol、String DescriptorのIndex
  
Endpoint
Descriptor

Endpointを選択するためのEndpoint番号

  • 転送タイプ(転送方向)
  • 転送で利用可能な最大パケット長
  • 転送のインターバル
 各Interface Descriptorに対してそれぞれ、独立に存在。Endpoint 0はEndpoint DescriptorではなくDevice Descriptorで定義されるのでInterfaceによってはEndpoint Descriptorを持たないInterface Descriptorも存在。
String
Descriptor		 文字列を保持するディスクリプタ  
Device_Qualifier
Descriptor		 ベンダID、製品ID、Deviceの版数を除いてDevice Descriptorと同じもの。動作中のspeed mode以外の設定におけるDevice Descriptor。 high-Speed capable deviceに必ず１つ存在。
Other_Speed_
Configuration
Descriptor		 構成はConfiguration Descriptorと同じで、Interface、Endpoint Descriptorを持つ。動作中のspeed mode以外の設定におけるConfiguration Descriptor。 high-Speed capable deviceで必ず１つ以上存在。

Endpoint DescriptorはUSB Interface内に存在するバッファを説明するディスクリプタです。Endpoint0を除いたすべてのEndpointはこのディスクリプタを持っています。Interfaceは複数のEndpointを１つにまとめて管理するための単位です。
なぜ、EndpointをまとめてInterfaceとして管理するのかというと、それによって複合の機能を持った装置を設計できるからです。USBではClass, SubclassがDeviceとInterfaceの両方のDescriptorで定義できます。ひとつの例としてスピーカを考えた場合、制御のためのEndpoint 0 (Control転送)、Audioデータを受信するEndpoint 1(Isochronous)が必要になります。また、オプションとしてスピーカ上のボリュームを変化させた時に、結果をPCにフィードバックするためのEndpoint 2 (Interrupt)を持つかもしれません。

スピーカーの例

Interfaceという概念がない場合、Endpoint0/1だけを持った装置とEndpoint0/1/2を持った装置はともにDevice DescriptorでAudio Classと定義されますが、PC上のデバイスドライバはそれぞれ異なるものになります。それでもドライバを開発できれば問題ありませんが、効率はよくないでしょう。ドライバを開発する場合Endpoint 0/1のドライバとオプションのEndpoint 2用のドライバを分けて開発した方が他への流用はそれだけ行いやすいです。特にスピーカの例ではオプションのEndpoint 2はマウスなどと同じHID Classの装置分類できます。EndpointをInterfaceでまとめて、そのInterfaceにドライバを関連づけることができれば、ドライバを分離して開発できます。このためInterfaceに対してClass、SubClass、Protocolが記述できるようになっているのです。 また、InterfaceレベルではAlternative Settingと言う考えが導入されています。これは特にIsochronous Endpointで有効な考え方です。Audioを考えた場合、Busに送信されるデータ量はPCMのビット数やステレオ／モノラルによって大幅に変わります。

  • 1byte(PCM)　X 45(44.1kHz) X 1(モノラル) = 45 byte/ms
  • 1byte(PCM)　X 45(44.1kHz) X 2(ステレオ) = 90 byte/ms
  • 2byte(PCM)　X 45(44.1kHz) X 1(モノラル) = 90 byte/ms
  • 2byte(PCM)　X 45(44.1kHz) X 2(ステレオ) = 180 byte/ms

転送するデータ量にあわせてMax packet sizeを変更しないと、バンド幅を確保できずにクライアントS/Wとファンクションの通信を確立できないかもしれません。Alternative SettingはEndpointのMax Packet SizeをPCからの設定によって変更できる場合に使います。
Endpoint 0以外のEndpointは基本的（Shared Endpointという思想もありますが．．．．）に複数のInterfaceで共有させることはできません。InterfaceとEndpointの組み合わせを変更する場合には別のConfigurationとして準備し、Configurationそのものを変更して対応することになります。Configurationを複数持つ目的はこのためです。Device DescriptorはUSB規定されているリクエストのGetDescriptor Deviceによってホストによって読み込まれます。対象のドライバの検出はここに記載されているベンダID、製品IDまたはClass,Subclassを"Inf"ファイル内のドライバ リストと比較して行うかInterface Descriptorに記述されている Class、Subcｌass を"Inf"ファイル内のドライバリストと比較して行います。

USBリクエスト

USBでは、Endpoint 0を使って行う以下のような標準のリクエストを定義しています。リクエストとしてはこれ以外にClass毎に決められているClassリクエストとベンダ毎に規定できるベンダリクエストが存在します。

リクエスト名 対象 概要
Get_Status Device, Endpoint Device:Self-PoweredとRemote Wakeup読み取り, Endpoint:Halt読み取り
Clear_Feature Device, Endpoint Device:Remote Wakeup クリア, Endpoint:Halt解除(DATA PID=0)
Set_Feature Device, Endpoint Device:Remote Wakeup or Test mode設定, Endpoint:Halt設定
Get_Descriptor Device, Config., String, Device_qualifier, Other_speed_Config. 対象Descriptorの読み取り
Set_Descriptor Device, Config., String 対象Descriptorの変更(Option)
Get_Configuration Device 現行設定のConfiguration値の読み取り
Set_Configuration Device Configuration値の設定
Get_Interface Interface 対象Interfaceの現行設定のAlternative Setting値の読み取り
Set_Interface Interface 対象InterfaceのAlternative Setting値の設定
Set_Address Device USBアドレスの設定
Synch_Frame Endpoint Frame同期のデータ読み取り

USB2.0となって追加されたUSBの標準リクエストは特にありませんが、Get Descriptorの拡張として、high-Speed capable deviceがChirp handshakeに失敗した場合に本来のスピード能力で動作させるために使うDevice_qualifierとOther_speed_configuration、さらにUSB2.0トランシーバの特性をチェックするSet Feature TEST_MODEが追加されています。

Class

USBの基本スペックで定義されているものはUSBリクエストを含め周辺装置に影響を受けない一般的な部分です。実際の周辺装置の開発においては、周辺装置に最適な専用リクエストやEndpoint構成を規定することになります。これを開発者がそれぞれ独自に行っても問題ありませんが、ドライバを共有するためには、周辺機器に最適な専用リクエストやEndpoint構成、転送シーケンスを予め規定しておかなければなりません。Class specとはこのような周辺機器用に決められたUSBスペックでPrinter、Audio、Storage、Communication、Hubなどがあります。Classとは大分類、Subclassとは小分類といえます。

Storage

USBについて詳しく知る

調べる