東海大学大学院 2004 年度 修士論文 USB 制御命令を持つ専用プロセッサの研究と USB デバイスコントローラへの実装試行 指導 清水 尚彦 教授 東海大学大学院工学研究科 名野 響 目次 第 1 章 はじめに 5 第 2 章 研究目的 6 6 6 2.1 2.2 汎用 USB デバイスコントローラの特徴とその問題点 . . . . . . . . . . . . . . . . . . . . . . . MPU を搭載した USB デバイスコントローラ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 第 3 章 USB プロト コル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7 7 7 7 8 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8 9 10 USB 制御命令をもつ専用プロセッサの問題点 . . . . . . . . . USB プロトコル制御の高速化と標準デバイスリクエスト . . . 4.2.1 標準デバイスリクエスト . . . . . . . . . . . . . . . . . 4.2.2 マスクによる比較演算と分岐命令によるリクエスト判別 4.2.3 ハッシュ関数によるリクエスト判別 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11 11 12 12 13 3.1 ホスト主導の通信 . . . . . . . . . . . . . . . . . . 3.2 アドレスとエンドポイント . . . . . . . . . . . . . 3.3 デバイスコンフィグレーションとデ ィスクリプタ 3.4 USB の通信プロトコル . . . . . . . . . . . . . . . 3.4.1 差動バス . . . . . . . . . . . . . . . . . . . 3.4.2 NRZI . . . . . . . . . . . . . . . . . . . . 3.4.3 3.4.4 3.4.5 3.4.6 Bit stuffing . . . . . . . . . . パケット . . . . . . . . . . . . トランザクションとフレーム トランスファ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 第 4 章 ハッシュ関数による USB リクエスト 判別手法の提案 4.1 4.2 第 5 章 USB デバイスコント ローラの設計 5.1 5.2 5.3 14 14 UTMI インタフェースの設計 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 設計方針 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . USB デバイスコントローラの設計 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 CRC 算出モジュールの設計 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.2 USB 制御用命令をもつ専用プロセッサの設計 . . . . . . . . . . . . . . . . . . . . . . . 15 16 17 5.3.3 5.3.4 パケット送信用 DMA コントローラの設計 . . . . . . . . . . . . . . . . . . . . . . . . . 18 20 5.4 ファームウェアの設計 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5 Verilog シミュレータによる動作確認 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 20 ハッシュ関数制御用コントローラの設計 . . . . . . . . . . . . . . . . . . . . . . . . . . 1 目次 第 6 章 FPGA を用いた USB ゲームパッド の実装 6.1 ゲームパッド の構造 . . . . . . . . . 6.2 ゲームパッド インタフェースの構造 . 6.3 ゲームパッド 用ファームウェアの設計 6.4 FPGA ボード への実装 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 21 21 21 21 第 7 章 評価 23 7.1 ゲート規模、メモリサイズの評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.2 USB プロトコル処理時間の評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 第 8 章 まとめ 25 謝辞 26 業績 27 参考文献 28 2 図目次 図目次 1.1 USB のバストポロジ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5 表目次 表目次 4.1 標準リクエストタイプと Hash Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1 5.2 5.3 5.4 開発環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UTMI が行う制御 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CRC の算出に使用するフィールド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16bit USB 専用プロセッサ “snx2pu2” の特徴 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 15 16 17 5.5 標準リクエストタイプと HASH KEY の関係 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.1 “Phy-link” と “IYOYOYO と RISC プロセッサによる USB デバイスコントローラ” との Total logic elements の比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . USB ゲームパッド を実装するために必要なメモリサイズの比較 . . . . . . . . . . . . . . . . . . リクエスト判別に必要な命令ステップ数 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 23 24 7.2 7.3 4 第 1 章 はじめに 第 1 章 はじめに USB(Universal Serial Bus) は様々な周辺機器に適応可能なインタフェースとして提案された規格である．現 在では PC(Personal Computer) の標準インタフェースとして使用されており，キーボード，マウス，フロッ ピーディスクド ライブ，ハードディスクド ライブ，メモリ，プリンタ，ディジタルカメラなどといった多くの製 品に採用されている． USB はプラグアンドプレ イ (PnP：コンピュータにデバイスを接続する際，手動の設定無しで OS が自動的 にデバイスを検出，最適な設定を行うシステム) やホットプラグ (コンピュータの電源を入れたままデバイスが 接続可能なシステム) といった特徴をもつ．USB は１対１，１対多の接続形態を構成する規格であり，図 1.1 のように USB ホストに対して USB デバイスを接続する (USB ハブを使用する事で最大１２７個の USB デバ イスが接続可能)．また３つの通信速度 (1.5Mbps，12Mbps，480Mbps) があり，基本となる４つの転送タイプ (コントロール転送、バルク転送、インタラプト転送、アイソクロナス転送) を組み合わせる事で多様なデバイ スに適応する事が出来る．本研究では USB デバイスの制御を行う USB デバイスコントローラの問題点を指摘 し，改善策を提案する．またその提案手法を用いて USB デバイスコントローラを HDL(Hardware Discription Language) で設計し，FPGA(Field Programmable Gate Array) による実装評価を行う． USB HOST Root HUB HUB USB Device USB Device HUB USB Device USB Device USB Device 図 1.1: USB のバストポロジ 5 第 2 章 研究目的 第 2 章 研究目的 2.1 汎用 USB デバイスコント ローラの特徴とその問題点 LSI ベンダで製品化されている USB デバイスコントローラの多くは図?? のような構成となる．このコント ローラは USB プロトコルで送受信するデータを次のような方法でデバイス側に提供する。 • 外部からアクセス可能な FIFO バッファ USB プロトコルで受信したデータを FIFO バッファにセットし 、デバイス側から FIFO バッファにセッ トされたデータを USB プロトコルで送信。 • i2c など 別のプロトコルに変換 デバイス側と送受信すべきデータを単純な通信プロトコルで提供 これらの機能はステートマシンで制御されており、USB デバイスコントローラの制御論理の細かい変更は出 来ない (ステート遷移を制御するフラグレジスタによって簡単な変更は可能)。このような USB デバイスコン トローラは USB プロトコルのみを制御し整形したデータをデバイス側に供給するため、デバイス制御用マイ クロコントローラが別に必要となる。 つまり USB デバイスを設計する場合、USB デバイスコントローラとデバイス制御用マイクロコントローラの ２つの LSI が基盤を占有する (図??(a))。製品の小型化が求められる組み込み機器においてこれは問題となる。 2.2 MPU を搭載した USB デバイスコント ローラ そこで本研究では内部に MPU(Micro Processing Unit) を搭載した USB デバイスコントローラを提案する (図??(b))。このコントローラはステートマシンを構成せずに、MPU とそのファームェアによって USB プロ トコルとデバイスの両方を制御する。つまりデバイス制御用マイクロコントローラを外部に用意する必要が無 いため、１チップで USB デバイスが制御可能となり基盤の占有面積を抑える事ができる。またファームウェア を変更する事で USB デバイスコントローラの制御論理を自由に変更する事が可能となり、コントローラに接 続するデバイスに適した制御を行える。 6 第 3 章 USB プロト コル 第 3 章 USBプロト コル 3.1 ホスト 主導の通信 USB はホスト主導の通信である。USB ホストが発行するトークンパケットによって転送が開始されるため、 USB デバイスから割り込みなどを利用して通信を開始する事は出来ない。USB デバイスは USB ホストが発行 したパケットから、要求されている転送を判別し実行する。 3.2 アドレスとエンド ポイント バス接続時に USB デバイスは USB ホストによってユニークなアドレスが付加される (付加される前のアド レスはデフォルトアドレス０を持つ)。これをデバイスアドレスと呼ぶ。 USB ホストと USB デバイスの論理的な接続関係を図??に示す。USB ホストと USB デバイスはエンドポイ ントとパイプと呼ばれる概念で接続する。一般的にエンド ポイントとは USB デバイス内に存在するバッファ を指し 、これと対応したホスト側のバッファがパイプによって接続している。 USB ホストは転送開始時に発行するトークンパケットでリクエスト対象とするデバイスのデバイスアドレス とエンドポイントを指定する。USB デバイスはトークンパケット受信時に自分にセットされたデバイスアドレ スとこのアドレスを比較し 、それらが等しいとき (自分に対して発行されたパケットだった場合) に指定された エンドポイントに対して対応した転送を行う必要がある。また、アドレスが異なっていた場合は発行された転 送開始のリクエストを無視する。 3.3 デバイスコンフィグレーションとディスクリプタ USB ホストはデバイスコンフィグレーションでバスに接続した USB デバイスを構成するために以下の処理 を行う。 • デ ィスクリプタの取得 • ド ライバのロード ディスクリプタとは USB デバイスがもつデバイスの特性や属性がセットされているデータテーブルで USB 仕 様でフォーマットが指定されている。全ての USB デバイスで使用する標準デ ィスクリプタを表??に示す。 USB ホストは取得したデ ィスクリプタを元に必要なド ライバを用意しデバイスを通信可能な状態にする。 3.4 USB の通信プロト コル USB の通信プロトコルの概要を図??に示す。図??は上位になるほど 転送単位が大きくなっている。以下で 各項目を説明する。 7 第 3 章 USB プロト コル 3.4.1 差動バス USB は表??に示す４線インタフェースである。データの送受信は D+ 、D-の差動データで行う。バスリセッ トとパケットの終了を示す EOP は例外として D+と D-が Low レベルとなる (図??)。 3.4.2 NRZI USB バス上を流れるデータは NRZI エンコード されたデータである。NRZI(Non Return to Zero Inverted) 方式は送信データが “1” のときにバスの状態を維持し 、“0” のときに状態を反転させる方式である (図??)。 3.4.3 Bit stuffing NRZI 方式でデータを送信する場合、送信データに “1” が連続してしまうとバスの値が変化しない事になる。 これを防ぐために USB では Bit stuffing を行う。Bit stuffing は送信データに 6 個の連続した “1” があるとき に、その後に “0” を挿入する方式である (図??)。この “0” はデータとして意味を持たないため受信側では無視 する必要がある。従って受信したデータに 7 個以上の連続した “1” があった場合通信エラーと見なされる。 3.4.4 パケット USB にはパケット、トランザクション、トランスファという三種類の転送フォーマットがある。その中でパ ケットは最小の単位である。USB1.1 仕様ではトークンパケット、データパケット、ハンドシェイクパケットと いう３種類のパケットが定められている。パケットフォーマットを図??に示す。 パケットの先頭には “0x80” で表される８ビットの SYNC フィールドがあり、受信側はこのフィールド を検 出し同期処理を行う。パケットの終了は 2 ビットタイムの間 D+ 、D-が共に Low となる特殊な EOP(End Of Packet) で定義される。パケットの種類は SYNC フィードに続くパケット ID フィールド で決定する。トーク ンパケット、データパケットには CRC5 、CRC16 といったエラーチェックのための CRC(Cyclic Redundancy Checks) フィールドがある。パケット受信側はこのフィールドから転送エラーの検出が可能である。 各パケットの概要を表??と以下に示す。 • トークンパケット (SOF パケット ) USB ホストはフレーム (1msec) という単位で USB バスのスケジューリングを行う。SOF パケットは各 フレームの開始を示すパケットで、1ms ごとに USB ホストが発行する。 • トークンパケット (SETUP パケット、IN パケット、OUT パケット ) 後述するトランザクションの開始時に USB ホストが発行するパケット。リクエスト対象となるデバイス のデバイスアドレス、エンドポイントを指定するための ADDR フィールド、ENDP フィールドがある。 • データパケット (DATA0 パケット、DATA1 パケット ) 送信データをセットするためのパケット。データをセットする DATA フィールドは 0∼1024 バイトの幅 をもつ。 • ハンド シェイクパケット (ACK パケット、NAK パケット、STALL パケット ) トランザクション終了時に発行するパケット。データパケットの送受信状態や通信エラーを通知するため に使用する。 8 第 3 章 USB プロト コル 3.4.5 ト ランザクションとフレーム ト ランザクション USB ホストと USB デバイスは複数のパケットを送受信する事でトランザクションと言う通信単位を構成す る。USB1.1 仕様で定められている５つのトランザクションフォーマットを図??に示す。トランザクションは USB ホストが発行するトークンパケットで開始する。USB ホストはトランザクションを行うターゲットデバイ スのデバイスアドレスとエンドポイントをこのパケットで指定する。各トランザクションの概要を以下に示す。 • IN トランザクション USB デバイスから USB ホストへデータ送信する際に使用する。USB ホストはトークフェーズで IN パ ケットを発行し USB デバイスに対してデータの送信リクエストを発行する。対象となるデバイスは要求 されたエンド ポイントにデータがあれば 、データフェーズでデータパケットを送信する。データパケッ トを受信した USB ホストはハンドシェイクフェーズで ACK パケットを発行する。デバイスはエンドポ イントに送信データが無い場合や通信エラーが発生した場合は NAK パケットや STALL パケットを発行 しこのトランザクションを終了する。 • OUT トランザクション USB ホストから USB デバイスへデータ送信する際に使用する。USB ホストはトークンフェーズで発行 する OUT パケットで送信対象となるデバイスとエンド ポイントを指定し 、それに続くデータフェーズ でデータパケットを送信する。データパケットを受信した USB デバイスは受信状態をハンド シェイク フェーズで通知する。 • SETUP トランザクション 後述するコントロールトランスファの最初に行うトランザクション。USB ホストはトーンフェーズでリ クエスト対象のデバイスとエンド ポイントを指定し 、その後に続くデータパケットでそのリクエスト内 容を指定する。対象となるデバイスはデータパケットを受信後に ACK パケットを送信する (それ以外の ハンド シェイクパケットを送信する事は許可されてない)。 このリクエストはデバイスリクエストと呼び 、USB 仕様で予め用意されている標準デバイスリクエスト (後述) や、デバイスクラス固有のリクエスト、ベンダ固有で定義したデバイスリクエストなどがある。 • アイソクロナストランザクション (IN) アイソクロナストランスファで使用する IN トランザクション。通常の IN トランザクションと異なりハ ンド シェイクフェーズが存在しない。 • アイソクロナストランザクション (OUT) アイソクロナストランスファで使用する OUT トランザクション。通常の OUT トランザクションと異な りハンドシェイクフェーズが存在しない (USB デバイスが USB ホストに対して受信状態を通知しない)。 フレーム USB ホストはフレーム (1msec) という単位で USB バスのスケジューリングを行う (USB2.0 仕様で追加され たハイスピード：480Mbps では uFrame)。1 フレームは SOF パケットから始まり次の SOF パケットを発行す るまでとなる。USB ホストはこのフレーム内でバスに接続している各デバイスのトランザクションをタイム シェアリングで処理する (図??)。 9 第 3 章 USB プロト コル 3.4.6 ト ランスファ トランスファは複数のトランザクションによって構成される転送単位である。４種類のトランスファがあり、 それらを使い分ける事で様々なデバイスに対応可能となっている。各トランスファを以下に示す。 • コントロールトランスファ USB ホストがデバイスアドレスセットやデバイスコンフィグレーションで使用するトランスファで、全 ての USB デバイスがサポートする必要がある。またそれ以外に簡単なデータの送受信でも使用される。 転送フォーマットを図??に示す。USB ホストは最初に SETUP トランザクションを行いリクエスト内容 をデバイスに通知する。その後データ転送が必要なリクエストであれば IN トランザクション 、OUT ト ランザクションを繰り返す。トランスファの終了はデータ転送と逆方向の IN トランザクションまたは OUT トランザクションを行う (この中のデータパケットの DATA フィールドは 0 バイトとなる)。 • インタラプトトランスファ キーボード やマウスといった HID(Huamn Interface Device) など 、非周期、低頻度な通信を行うデバイ スで使用する。転送フォーマットを図??に示す。図のように USB ホストのポーリングで制御する。 • バルクトランスファ ハードデ ィスクド ライブなどのストレージデバイスやプ リンタなど 、遅延が問題にならない大量のデー タを転送するために使用する。転送フォーマットを図??に示す。 • アイソクロナストランスファ 動画や音声などのストリーミングデータのようにデータ転送に時間的制約があり、連続的で周期的な通 信で使用する。転送フォーマットを図??に示す。他の転送とは事なり、一定の転送レートを保つために 転送エラーなどによるデータの再送信は行わない。 10 第 4 章 ハッシュ関数による USB リクエスト 判別手法の提案 第 4 章 ハッシュ関数による USB リクエスト 判別手 法の提案 4.1 USB 制御命令をもつ専用プロセッサの問題点 本研究では MPU を内臓した USB デバイスコントローラを提案する。このコントローラは内部の MPU と そのファームウェアによって USB プロトコルとコントローラに接続するデバイスの両方を制御する (図??)。 • USB プロトコル制御 既述した USB の通信プロトコルに従って USB ホストが発行したパケットを受信し 、リクエスト内容を 判別、対応したパケットを送信して、トランザクション 、トランスファを構成。 • デバイス制御 受信データのデバイスへの書き込みや、送信データのデバイスから読み出し 、デバイスコントロールなど 。 しかしこれらの制御を同時に行う事は出来ないため、USB プロトコル制御に多くの時間が必要となってしま うと、デバイス制御に割り当てる時間が少なくなる問題がある。つまり複雑な制御を必要とするデバイス (制 御に多くの時間や命令ステップを必要とするデバイス) が提案する USB デバイスコントローラに接続不可能と なってしまう。 そこで本研究では USB プロトコル制御の高速化を図り、その手法を採用した USB デバイスコントローラを 設計する。 4.2 USB プロト コル制御の高速化と標準デバイスリクエスト USB デバイスが行う USB プロトコル制御の中心は USB ホストが要求するリクエストの判別にある。リク エスト判別の高速化は USB プロトコル制御の高速化に繋がる。USB ホストがデバイスに対して発行するリク エストはデバイスリクエストと呼ばれ以下のものがある。 • 標準デバイスリクエスト デバイスコンフィグレーションやセットアドレスなど USB ホストが USB デバイスをセットアップする 際に使用するリクエスト。全ての USB デバイスで使用する。 • デバイスクラス固有のデバイスリクエスト USB 仕様で定める各デバイスクラス (表??) ごとに用意されているリクエスト。 • ベンダ固有のデバイスリクエスト USB ドライバで設定可能なデバイスリクエスト。USB ベンダがドライバを設計する事でリクエストフォー マットを自由に設定可能。 本研究では USB ホストが全ての USB デバイスに対して発行する標準デバイスリクエストに注目し 、このリ クエスト判別の高速化を図る。 11 第 4 章 ハッシュ関数による USB リクエスト 判別手法の提案 4.2.1 標準デバイスリクエスト 標準デバイスリクエストはコントロールトランスファを使用する。USB ホストはトランスファ内で発行する データパケットの８バイトのデータフィールドでリクエストパターンを決定する。標準デバイスリクエストと データフィールド の関係を表??に示す。 USB ホストはこのリクエストを使用して以下の処理を行う。 • デバイスステータスのセット • デバイスデータ (デ ィスクリプタ) の取得 表??の “SET ADDRESS” と “GET DESCRIPTOR” を例に標準デバイスリクエストのパケットフローを 示す。 SET ADDRESS Request パケットフローを図??に示す。SET ADDRESS Request は USB ホストがバスに接続した USB デバイスに 対してデバイスアドレスを設定するリクエストである。最初に SETUP パケットを発行してデバイスアドレス をセットするデバイスを指定する。ここで指定しているアドレス 0 はデフォルトアドレスである。デフォルト アドレスは USB ホストからデバイスアドレスを割り振られていないデバイスが初期値として持つアドレスで ある。またエンドポイント番号は 0 となっている。これは USB ホストが USB デバイスの基本設定を行うため のデフォルトパイプを指している。 次に発行するデータパケットでリクエストの種類 (SET ADDRESS Request) とセットするデバイスアドレ スを指定する。USB デバイスはこのパケットからリクエストの種類を判別する必要がある。 SET ADDRESS Request のようなデバイスステータスセットのリクエストは IN トランザクションや OUT トランザクションを利用したデータの送受信を行う必要がないため、SETUP トランザクション後に IN トラン ザクション (No-data) を行いトランスファを終了する。 GET DESCRIPTOR Request パケットフローを図??に示す。GET DESCRIPTOR Request は USB ホストが USB デバイスに対してディ スクリプタの送信要求を行うリクエストである。 USB ホストは SETUP パケットでデバイスを指定し、次の DATA パケットでリクエストの種類 (GET DESCRIPTOR Request) と要求するディスクリプタの種類やサイズを指定する。その後 USB ホストは IN トランザクションを 複数回行いデバイスからディスクリプタを取得する。トランスファ終了時は OUT トランザクション (No-data) を行う。 4.2.2 マスクによる比較演算と分岐命令によるリクエスト 判別 USB デバイスは USB ホストから受信した DATA パケットの DATA フィールド をチェックし 、要求されて いる標準デバイスリクエストの内容を判別する。ファームウェアでこの判別処理を行う場合、マスクによる比 較演算と分岐処理による方法が考えられる。GET DESCRIPTOR Request を例に判別処理のフローチャート を図??に示す。 判別対象となるデータフィールドはバイト単位で意味を持っているため、各項目についてマスクによる比較 演算と分岐処理を行いリクエストを判別する。GET DESCRIPTOR Request であれば wValue からホストが 要求しているデ ィスクリプタタイプを判別し 、wLength から要求サイズを判別する。 12 第 4 章 ハッシュ関数による USB リクエスト 判別手法の提案 表 4.1: 標準リクエストタイプと Hash Value 標準リクエストタイプ 設定する Hash Value ステータスセット ステータスセットを行うサブルーチンアドレス デ ィスクリプタなどのデータ送信 送信データがセットされているデータメモリ内のアドレス しかし図??からも分かるように、この方法は比較演算と分岐処理が複数回必要となり命令ステップが増大す る。またデバイスが持っているデ ィスクリプタの数に比例して演算回数が増大してしまう。 4.2.3 ハッシュ関数によるリクエスト 判別 そこで本研究ではハッシュ関数を用いた標準デバイスリクエスト判別手法を提案する。ハッシュ関数とは与え られた文字列から固定長の擬似乱数を生成する演算手法である。つまり、ある値 (これを本稿では “Hash Key” とする) をハッシュ関数に与える事でそれに対応したハッシュ値 (これを本稿では “Hash Value” とする) が得 られる (図??)。 提案手法では標準デバイスリクエストのパターンを決定するデータフィールド を Hash Key として利用し 、 そこから得られる Hash Value がリクエスト判別処理に利用可能なデータとなるようにハッシュ関数を設計す る。Hash Value はリクエストの種類によって表 4.1 のように定める。 このようにハッシュ関数を設計すると以下の方法で標準デバイスリクエスト判別が可能となる (図??)。 1. データパケットのデータフィールド ８バイト受信 2. データフィールド を Hash Key としてハッシュ関数に入力 3. ハッシュ関数から得られた Hash Value を利用してリクエスト判別 • リクエストがデバイスステータスセット ハッシュ関数から得られた Hash Value をステータスセットを行うためのサブルーチンアドレスと してジャンプ • リクエストがデ ィスクリプタの送信要求 得られた Hash Value をデータメモリのアドレスとしてパケット送信 この手法を用いる事でハッシュ関数の演算と 1 回の分岐処理でリクエスト判別が可能となる。またデバイス が持つディスクリプタ数の増大などにより判別パターンが増大したとしても、ハッシュ関数が変更されるだけ で判別処理に必要な命令ステップは変化しない。 本研究ではこのハッシュ関数をハード ウェアで設計し USB リクエスト判別のための専用命令として MPU に 実装する。 13 第 5 章 USB デバイスコント ローラの設計 第 5 章 USB デバイスコント ローラの設計 5.1 設計方針 USB デバイスコントローラの設計方針を以下に示す。 • MPU とファームウェアで USB プロト コルとデバイスを制御 USB デバイスコントローラの制御はステートマシンでは無く、MPU によって制御する。 • MPU にハッシュ関数を利用したリクエスト 判別用命令を実装 MPU にはハッシュ関数など USB プロトコル制御用の専用命令を実装し 、ファームウェアステップ数を 抑えた設計を行う。 • USB デバイスコント ローラにゲームパッド を接続し 、USB ゲームパッド として実装 ファームウェアでコントロール転送とインタラプト転送を制御し 、USB ゲームパッド として実装テスト を行う。 • ド ライバは各 OS に用意されている HID(Human Interface Device) ド ライバを使用 実装テストは Windows や Linux で行う。使用するド ライバはそれらに予め用意されている HID ド ライ バを利用する。 • USB1.1 仕様フルスピード (12Mbps) による通信 USB1.1 仕様に従って設計を行いフルスピード 仕様の通信を行う。 • USB2.0 への対応を考慮し物理層インタフェースに UTMI (USB2.0 Tranceiver Macrocell Interface) を採用 設計する USB デバイスコントローラは USB2.0 への対応を想定している。しかし 、USB2.0 仕様で用意 されているハイスピード (480Mbps) の高速な転送は論理 LSI のみで実現するのは難しい。そこで高速回 路制御部を物理層 (PHY チップ ) に分離する UTMI 仕様を採用した。設計する USB デバイスコントロー ラは UTMI の通信プロトコルに従って、PHY チップによって整形された USB パケットを送受信する (図 ??)。また、USB1.1 仕様のフルスピード であれば PHY チップ無しでの実装が可能であるため、フルス ピード 仕様の UTMI インタフェースを設計する。 USB の通信プロトコルと設計するフルスピード 仕様 USB デバイスコントローラとの対応関係を図??に示す。 NRZI エンコード /デコード 処理やパケット受信処理等は UTMI が処理するため、USB デバイスコントローラ はパケット、トランザクション 、トランスファと言った各種転送単位を制御する。 設計に用いた開発環境を表 5.1に示す。各モジュールは SFL 言語を用いて設計した。設計したモジュールは sfl2vl で Verilog-HDL に変換し 、Icarus Verilog と gtkwave を用いてシミュレーションを行った。 以下でフルスピード UTMI インタフェースと USB デバイスコントローラの設計について述べる。 14 第 5 章 USB デバイスコント ローラの設計 表 5.1: 開発環境 環境 概要 SFL 言語 ハード ウェア記述言語 sfl2vl SFL 言語処理系 Icarus Verilog Verilog シミュレータ gtkwave 波形表示ツール 表 5.2: UTMI が行う制御 5.2 制御 パケット送信時 パケット受信時 速度変換 [480MHz/12MHz] → [60MHz](HS/FS, with 8-bit interfacee) [12MHz] → [48MHz](FS Only, with 8-bit interfacee) パラレルシリアル変換 シリアルデータを 8 ビット (または 8 ビット (または 16 ビット ) のパラレ 16 ビット ) のパラレルデータへ変換 ルデータをシリアルデータへ変換 NRZI 制御 NRZI デコード NRZI エンコード Bit Stuffing スタッフビット除去 スタッフビット付加 SYNC フィールド 制御 SYNC フィールド 除去 SYNC フィールド 付加 EOP 制御 EOP の除去 EOP の付加 UTMI インタフェースの設計 UTMI は Intel 社によって 1999 年に策定された仕様である。UTMI は USB2.0 トランシーバとパラレルシリ アルインタフェースエンジン間で USB2.0 機能を区別する事により、USB2.0 準拠製品の互換性と設計の自由 度を高めている。UTMI が行う制御を図??と表 5.2に示す。 本稿ではフルスピード 仕様 UTMI を設計し USB デバイスコントローラと共に FPGA に実装した。設計した フルスピード 仕様 UTMI(以下 “FS-UTMI”) のブロック図を図??に示す。また各サブモジュール制御を表??に 示す。 FS-UTMI は “RecvSt” 、“TranSt”2 つのステートマシンで各サブモジュールを制御する。FS-UTMI は図?? のタイミングに従って USB バスから受信したパケットを 8 ビットのパラレルデータとして、USB デバイスコ ントローラに提供する (図??)。また図??のタイミングに従って USB デバイスコントローラから 8 ビットのパ ラレルデータを受信すると、パケットに整形して USB ホストへ送信する (図??)。 5.3 USB デバイスコント ローラの設計 FS-UTMI が USB 通信プロトコルの下位層を処理するため、USB デバイスコントローラはパケット、トラ ンザクション 、トランスファを制御する。 設計した USB デバイスコントローラ “Phy-link” のブロック図を図??に示す。各モジュールの特徴を以下に 示す。 • “snx2pu2” オリジナル 16bit RISC プロセッサ。ハッシュ関数制御命令など USB 通信プロトコルの制御に適した命 令セットを持つ。 • “Data MEM” 、“Inst. MEM” データメモリと命令メモリ。 • “HASH controller” 15 第 5 章 USB デバイスコント ローラの設計 表 5.3: CRC の算出に使用するフィールド パケットの種類 CRC フィールド CRC 算出に使用するフィールド トークンパケット CRC5 ADDR フィールド、ENDP フィールド データパケット CRC16 DATA フィールド ハッシュ関数制御モジュール。snx2pu2 から Hash Key を受信すると対応した Hash Value を返す。 • “Tag00/Tag01 ROM” 、“DATA00/DATA01 ROM” ハッシュ関数で使用するハッシュテーブルデータを格納するメモリ。 • “DMA controller” パケット送信用モジュール。snx2pu2 からパケット送信リクエストを受信すると、DATA MEM または ReadFIFO から送信データを読み込み UTMI プロトコルに従って FS-UTMI に送信する。 • “CRC5” 、“CRC16” CRC 算出＆エラーチェックモジュール。トークンパケット、データパケット受信時に CRC エラーの有無 を snx2pu2 に通知する。パケット送信時は送信データから CRC フィールド の算出を行う。 次に各モジュールの設計について述べる。 5.3.1 CRC 算出モジュールの設計 CRC フィールド USB のトークンパケットとデータパケットには転送エラーを検出するために CRC フィールド (CRC5・CRC16) がある。CRC(Cyclic Redundancy Check：巡回冗長検査) は誤り検出方式の 1 である。パケットの受信側は受 信パケットから CRC エラーの有無を計算し 、転送エラーが発生したかど うかを検出する事が出来る。 CRC の算出は以下の生成多項式を用いて行う。 (CRC5 の生成多項式) (CRC16 の生成多項式) X5 + X2 + X0 X 16 + X 15 + X 2 + X 0 パケット送信側は生成多項式を利用して表 5.3に示すフィールドから CRC フィールドを生成し 、パケットに付 加する。一方、パケット受信側は生成多項式を利用して表 5.3に示すフィールド と CRC フィードから CRC エ ラーチェックを行う。 CRC 算出モジュールの設計 USB の仕様に基づいてシフトレジスタと XOR ゲートによって CRC 算出モジュールを設計した (図??)。こ のモジュールは入力 “in” にシリアルデータを連続して入力する事で CRC フィールドが算出可能である。以下 にこのモジュールを使用した CRC フィールド の算出方法と CRC エラーチェック方法を示す。 • CRC フィード の算出方法 1. シフトレジスタを全て “1” に初期化 2. CRC 算出に使用するデータを in に連続して入力 16 第 5 章 USB デバイスコント ローラの設計 3. データ入力後シフトレジスタにセットされているビット反転値が CRC フィールド となる (in に “1” を入力する事でシフトレジスタ値のビット反転値を out から出力可能) • CRC エラーの検出 1. シフトレジスタを全て “1” に初期化 2. CRC 算出に使用するデータと CRC フィールド を in に連続して入力 3. データ入力後シフトレジスタの値が図??の下に示した値と一致しない場合 CRC エラーが発生して いる しかし 、設計する USB デバイスコントローラは FS-UTMI からパケットを 8 ビットのパラレルデータとし て受信する。そこで、図??に示すモジュールと論理的に等しい CRC 計算を 8 ビット単位で行うモジュールを 設計した (図??) このモジュールは in から 8 ビットのパラレルデータを連続に受信する事で CRC フィールド 算出と CRC エラー検出が可能である。 5.3.2 USB 制御用命令をもつ専用プロセッサの設計 USB の通信プロトコルと USB デバイスコントローラに接続するデバイスの両方を制御するオリジナルプロ セッサ “snx2pu2” を設計した。このプロセッサは図??のように USB バス側は UTMI インタフェースで接続 する。一方、コア側にはメモリマップした FIFO バッファを用意しており、このバッファを介してデバイスと データの送受信が可能である。 ‘snx2pu2” のブロック図を図??に示す。また特徴を表 5.4に示す。 表 5.4: 16bit USB 専用プロセッサ “snx2pu2” の特徴 ハーバード アーキテクチャ RISC タイプ 汎用レジスタ 4 本 ($0,$1,$2,$3) 即値 (I) 8bit 割り込み 有 (割り込み発生時の PC は repc レジスタに待避) 3 段パイプライン (if, dec/exe/mem, web) 命令セット ADD $A $B $C 加算 $A ← $B + $C AND $A $B $C 論理積 $A ← $B & $C NOT $A $B $C 反転 $A ← ˆ$B SR $A $B $C 右バイトシフト $A ← 0x00 || $B<15:8> COM $A $B $C 比較 $if($B ≦ $C): $A ← $B $else: $A ← $C HAS $A $B $C HASH コントローラの制御 LDA $A $B I 即値加算 $A ← $B + I LD $A $B I メモリ読み出し $A ← MemoryRead($B + I) ST $A $B I メモリ書き込み MemoryWrite(($B + I), $A) IO $A $B I UTMI インタフェースからのデータ受信 BZ $A $B I 条件分岐 if($A == 0) pc ← $B + I BAL $A $B I 強制分岐 $A ← pc + 1 , pc $B + I INA $A $B I 割り込みアドレス指定 intadd ← $B + I RET X $B I 割り込み復帰 if(X == 0): IntFlag ← 0, PC ← $B + I X:Flag(2bit) else: IntFlag ← 0, PC ← repc DMA X $B $C DMA コントローラの制御 SET $A $B X USB 専用命令 (アドレスチェック or コンペア) 17 第 5 章 USB デバイスコント ローラの設計 snx2pu2 は 16 ビット RISC プロセッサである。フェッチステージ、デコード・実行・メモリアクセスステー ジ、ライトバックステージの３段パイプラインを構成する。16 ビット汎用レジスタを 4 本もち、即値は 8 ビッ トまで取ることが可能である。 命令は表 5.4に示す 16 種類をもつ。基本的な論理演算命令、メモリアクセス命令、分岐命令に加え USB プ ロトコル制御用の専用命令がある。 snx2pu2 の制御内容を以下に示す。 • パケット受信制御 snx2pu2 は UTMI からパケットを受信する。パケット受信の開始は割り込みを使用する。また、パケッ ト受信専用命令として IO 命令を用意した。snx2pu2 のパケット受信タイミングを図??に示す。 UTMI はパケット受信開始時に RXActive をアサートするため、Interrupt controller は RxActive のア サートを検出して snx2pu2 に対して割り込みを発生させる。割り込みを検出した snx2pu2 は割り込みハ ンド ラに登録されてるサブルーチンにジャンプし 、パケット受信処理を行う。 IO 命令を 1 回発行すると、snx2pu2 は UTMI からのデータ受信タイミングに従って 8 ビットデータを汎 用レジスタにセットする。IO 命令を連続して発行することでパケットを 8 ビット単位で受信する事がで きる。また、IO 命令発行時に UTMI からデータ受信が出来ない場合は、受信できるまでアイドル状態と なる。 • パケット送信制御 snx2pu2 のパケット送信は DMA コントローラで行う。ファームウェアで DMA コントローラ制御用命令 “DMA 命令” を発行すると、このコントローラは命令内で指定したアドレスと送信サイズに従ってデー タメモリからデータをロードし 、パケットに整形して UTMI に送信する。 • ハッシュ関数制御 標準デバイスリクエスト判別で利用するハッシュ関数命令として “HAS 命令” を実装した。この命令は 引数に HASH KEY をとる。命令を実行すると USB デバイスコントローラ内のハッシュコントローラに 対して、HASH KEY と共にハッシュ検索リクエストを発行する。リクエストを受信したハッシュコント ローラは HASH KEY から対応する HASH VALUE を返す。 • デバイス制御 USB デバイスコントローラに接続するデバイスとは FIFO バッファを介して通信する。この FIFO バッ ファとそのステータスレジスタはメモリマップしており、メモリアクセス命令や DMA 命令でアクセス する事が出来る。 本稿では通信プロトコルが単純なインタラプト転送用の 8 バイト FIFO バッファを 1 つ用意した。 5.3.3 ハッシュ関数制御用コント ローラの設計 USB デバイスコントローラ “Phy-link” はハッシュ関数を用いて標準デバイスリクエストを判別する。そこ でハッシュ関数を制御するためにハッシュコントローラを設計した。このコントローラは MPU“snx2pu2” から ハッシュの検索リクエストと HASH KEY を受信すると、HASH KEY から HASH VALUE を算出し snx2pu2 に送信する。 ハッシュ関数の算出方法として “2-way set associative 方式” を採用した。概念図を図??に示す。これはキャッ シュ制御で用いられる方式で、way と呼ばれるメモリテーブルが 2 セットあるため “2-way set” と呼ばれる。 2-way set associative 方式は以下方法で HASH KEY から HASH VALUE を検索する。 18 第 5 章 USB デバイスコント ローラの設計 表 5.5: 標準リクエストタイプと HASH KEY の関係 リクエストタイプ HASH KEY(上位 8 ビット ) HASH KEY(下位 8 ビット ) デ ィスクリプタ送信リクエスト 送信デ ィスクリプタの開始アドレス 送信デ ィスクリプタサイズ ステータスセットリクエスト サブルーチンアドレス 0 1. HASH KEY を TAG 、SET 、BLOCK の 3 つのフィールドに分割する 2. SET フィールド をアドレスとして各 way の Tag rom からデータを読み出す 3. 2 と同時に SET フィールドと BLOCK フィールドをアドレスとして各 way の Data rom からデータを読 み出す 4. 各 Tag rom から読み出したデータと TAG フィールド を比較する 5. 比較結果が真であればその way の Data rom から読み出した値が HASH VALUE となる 表??に示す標準デバイスリクエストをこの方式で判別するため、以下のように HASH KEY と HASH VALUE を定めた。 HASH KEY の設定 標準デバイスリクエストのリクエストパターンはデータパケットのデータフィールドで決定するため、これ を HASH KEY に設定する。しかし 、データフィールド サイズは 8 バイトあり、そのまま HASH KEY とした 場合 HASH KEY サイズが大きくなり、メモリテーブルサイズが増大してしまう。そこで、表??に示す標準デ バイスリクエストのデータフィールド パターンを比較し 、判別に使用可能な 12 ビットから HASH KEY を生 成する (図??)。 ハッシュコントローラは snx2pu2 からデータフィールド 8 バイトを受信すると、この 12 ビットを抜き出し 、 ハッシュ検索を実行する。 HASH VALUE の設定 標準デバイスリクエストは大きく分けて 2 種類ある。 1. デ ィスクリプタの送信リクエスト 2. デバイスアドレスなどのステータスセットリクエスト そこでリクエストタイプが 1 の場合は HASH VALUE にディスクリプタの情報 (ディスクリプタをセットして あるデータメモリのアドレスやデータサイズ ) を設定し 、2 の場合はそのステータスセットを行うサブルーチン のアドレスとした。またハッシュ検索の結果得られた HASH VALUE が 1 と 2 ど ちらのリクエストタイプなの かを判別するために表 5.5のように HASH VALUE をめた。 このように HASH VALUE を設定する事でファームウェアは以下の手順で標準リクエスト判別が可能となる。 1. データフィールド 8 バイトを受信 2. 1 で受信したデータを HASH KEY として HAS 命令を用いてハッシュ検索 3. 2 の結果受信した HASH VALUE の下位 8 ビットをチェック 19 第 5 章 USB デバイスコント ローラの設計 4. HASH VALUE の下位 8 ビットのチェック • 0 のとき：上位 8 ビットをサブルーチンアドレスとしてジャンプ命令を実行 • 0 以外のとき：アドレスとサイズ情報に従ってパケット送信 5.3.4 パケット 送信用 DMA コント ローラの設計 DMA コントローラは snx2pu2 から送信リクエストを受信すると、送信データ情報 (送信データがセットし てあるデータメモリの開始アドレスとサイズ ) に従って UTMI に対してパケット送信を行う。 送信データはパケットフォーマットに従ってデータメモリにセットする (図??)。これにより DMA コント ローラはデータメモリから順にデータをロードし 、バスに送信するだけで図??に示すタイミングでパケット送 信が可能となる (図??)。 コントロール転送の DATA フィールド の最大サイズは 8 バイトとして設計した。そのため snx2pu2 から受 信した送信サイズが 9 バイト以上の時は、1 バイトのパケット ID フィールド と 8 バイトの DATA フィールド を送信し 、未送信データの開始アドレスとサイズを内部レジスタに保存しする。そして、再度 snx2pu2 から送 信リクエストを受信した場合は残りのデータを送信する。 USB デバイスが送信するパケットはデータパケットかハンドシェイクパケットである。DMA コントローラ はパケット送信時にそのパケット ID をチェックし 、送信データがデータパケットの場合は CRC16 モジュール から CRC16 フィールド を算出し 、パケットの最後に付加する。 5.4 ファームウェアの設計 snx2pu2 のアセンブリ言語を用いてファームウェアを設計した。このファームウェアは表??に示す標準デバ イスリクエストを判別し 、ディスクリプタの送信や、ステータスセットを行う。 ファームウェアは perl スクリプトで設計したアセンブラでバイナリファイルに変換し 、命令メモリにマップ する。 5.5 Verilog シミュレータによる動作確認 設計した各モジュールとファームウェアを Verilog シミュレーション上で実行した。テストベンチを設計し 以下の制御を確認した。 • 各標準デバイスリクエスト (GET DESCRIPTOR 、SET ADDRESS 、SET CONFIGURATION 、CLEAR FEATURE) 単体の動作 • 異なったデバイスアドレスに対するリクエスト応答 • CRC エラーパケット受信時の動作 • USB ホストが行う USB デバイスのセットアップ制御 USB バスや各信号線の値を波形表示し 、正常動作を確認した (図??)。 20 第 6 章 FPGA を用いた USB ゲームパッド の実装 第 6 章 FPGA を用いた USB ゲームパッド の実装 Verilog シミュレーションで正常動作が確認できた USB デバイスコントローラを FPGA に実装する。USB デバイスコントローラにゲームパッド を接続し USB ゲームパッド として動作確認を行う。 ただし 、本稿ではゲームパッド 制御をファームウェアで行わず、文献 [] の USB デバイスコントローラ (オリ ジナル USB インタフェースと汎用 RISC プロセッサで設計) と同様のゲームパッド インタフェースモジュール を使用する。これは文献 [] と同様の環境でファームウェアを設計し 、そのステップ数を評価するためである。 6.1 ゲームパッド の構造 市販のゲームパッド を利用して図??のゲームパッド を設計した。回路図を ??に示す。このコントローラは各 スイッチにプルアップ抵抗を接続し 、OFF 状態で HIGH レベル、ON 状態で LOW レベルとなる。 6.2 ゲームパッド インタフェースの構造 文献 [] と同様のゲームパッド インタフェースを使用する。図??にブロック図を示す。このインタフェースは チャタリング対策として約 100kHz で動作する。このインタフェースはゲームパッド からの 16 ビットの入力 (表??) とそのステータスレジスタを snx2pu2 にメモリマップする。 ゲームパッドからの入力データは 2 段ラッチし 、図??に示す制御でステータスレジスタの値を決定する。ス テータスレジスタはゲームパッド の入力が更新されたかど うかを示す。2 段レジスタの比較結果値が真のとき、 ゲームパッドの入力データが変化していないためステータスレジスタを更新しない。また偽であったとき、ゲー ムパッド のデータからの入力が変更されたとしてステータスレジスタに 1 をセットする。 6.3 ゲームパッド 用ファームウェアの設計 USB ゲームパッドは USB 仕様で HID クラスに分類される。このクラスはインタラプト転送でデータ通信を 行う。そこでファームウェアにインタラプト転送の制御を追加した。 インタラプト転送はホストのポーリング制御で実行される。設計した USB デバイスコントローラはポーリ ングを検出するとゲームパッド のステータスレジスタをチェックし 、データ更新が行われていればゲームパッ ドデータを送信する。もし 、更新が行われていなければ NAK パケットを送信する (図??)。 6.4 FPGA ボード への実装 設計した USB ゲームパッド を ALTERA QuartusII を用いて FPGA に実装した (図??)。ターゲットデバイ スは∼である。Windows2000 と RedHatLinux8.0 で動作確認を行った結果、デバイスのセットアップ処理やド ライバ登録が正常に行われ USB ゲームパッド としての正常動作が確認できた。 また、バスの値をロジックアナライザと USB アナライザを用いて確認した結果、以下の正常動作が確認で 21 第 6 章 FPGA を用いた USB ゲームパッド の実装 きた (??)。 • USB ホストによるデバイスアドレスセット • USB ホストに対するデ ィスクリプタ送信 • USB ホストによるコンフィグレーションセット • CRC フィールド 判別 • インタラプト転送 • バスに複数の USB デバイスが存在する場合の動作 22 第 7 章 評価 第 7 章 評価 7.1 ゲート 規模、メモリサイズの評価 設計した USB デバイスコントローラを ALTERA QuartusII を用いて論理合成した結果、Total logic elements は 2069 となった。過去に設計したオリジナル USB インタフェース “IYOYOYO” と RISC プロセッサによる USB デバイスコントローラ (文献 []) との比較を表 7.1に示す。文献 [] の USB デバイスコントローラは本稿の 表 7.1: “Phy-link” と “IYOYOYO と RISC プロセッサによる USB デバイスコントローラ” との Total logic elements の比較 Device Total logic elements “Phy-link” “IYOYOYO” ALTERA APEX20KE EP20K160EFC484-3 ALTERA APEX20KE EP20K160EFC484-3 2,069/6,400 1,645/6,400 “Phy-link” と同様に内部の MPU でコントローラの制御を行う。しかし 、その MPU は教育用に研修室で設 計した汎用の RISC プロセッサで、USB 制御などの専用命令はもっていない。また、オリジナル USB インタ フェース “IYOYOYO” もロースピード 制御のみに対応しておりフルスピード 通信は行えない。 一方、“Phy-link” は USB プロトコル制御に特化するために MPU にハッシュコントローラや DMA コント ローラを内臓し 、USB フルスピード 制御まで可能な UTMI インタフェースを採用した。そのため表 7.1のよう に文献 [] に比べ、Phy-link の Total logic elements の方が大きい結果となった。 次に USB ゲームパッド として実装した場合に必要なメモリサイズを表 7.2に示す。表中の PIC16C765 は 表 7.2: USB ゲームパッド を実装するために必要なメモリサイズの比較 “Phy-link” “IYOYOYO” “PIC16C765” Inst. Memory 298 bytes 394 bytes 1.9 kbytes Data Memory 159(1) bytes 506() bytes 50 bytes Hash Memory 135 bytes - - MICROCHIP 社の USB 用 8 ビットマイクロコントローラ (文献??) である。表に示すメモリサイズは同社で 公開している PIC16C765 を用いた USB ゲームパッド の設計サンプルの値である。 表??の命令メモリサイズを比較すると Phy-link のメモリサイズが非常に小さい値となっている。これは USB プロトコル制御に特化したハード ウェア実装を Phy-link に行ったためである。ハッシュコントローラや DMA コントローラの実装がファームウェアサイズの大幅な削減に繋がっている。 また、IYOYOYO はマスクによる比較演算と分岐処理によって標準デバイスリクエスト判別を行っている。 つまり、デバイスが持つディスクリプタ数が増大すると判別パターンも増大し 、さらに多くの命令メモリサイ ズが必要となってしまう。一方、Phy-link はハッシュ関数による標準リクエスト判別を行っているため、判別 パターンが増大しても命令メモリサイズは変化せず、ハッシュ関数に必要なハッシュテーブルを書き換えるだ けで良いという利点がある。 23 第 7 章 評価 表 7.3: リクエスト判別に必要な命令ステップ数 制御 処理にかかる最大ビット時間 トークンパケット受信からデバイスターゲットを 13 判別し対応したパケットを送信 セットアップパケット受信からデバイスクエスト 137 判別が終了 データメモリサイズを比較すると PIC16C765 に比べ Phy-link と IYOYOYO のメモリサイズが 5 倍以上に なっている。これは PIC16C765 がコントローラ制御のために必要なデータメモリサイズのみを示しているの に対し 、Phy-link と IYOYOYO がコントローラ制御のために必要なデータとデ ィスクリプタなどの送信デー タの合計値を表しているからである。表のデータメモリサイズの括弧の中のサイズが制御のために必要なデー タメモリサイズであり、これと比較するとデータメモリサイズについても大幅に削減できていると言える。 Phy-link についてはハッシュ関数用のハッシュメモリが必要となるが 、データメモリとハッシュメモリの合 計値と IYOYOYO のデータメモリサイズを比較しても Phy-link のメモリサイズが少ない結果となった。 7.2 USB プロト コル処理時間の評価 USB ゲームパッドとして実装した Phy-link のリクエスト判別に必要な命令ステップ数を Verilog シミュレー タで計測した。シミュレーション結果を表 7.3に示す。 表 7.3のように設計した USB ゲームパッド はトークンパケット受信後、リクエスト判別を行い 13 ステップ で対応したパケットを送信している。また、デバイスリクエストの判別にかかるステップ数は 137 となった。 Phy-link の MPU“snx2pu2” は動作周波数が 12MHz であるため 、図??のように判別処理にかかる時間が 11.4µs となる。つまり、USB ホストが次のトランザクションを発行するまでの約 988.6µs 間デバイスを制御で きる。このように USB プロトコル制御に特化したハード ウェア設計を行った結果、高速にリクエスト判別が 行える USB デバイスコントローラを設計できた。 24 第 8 章 まとめ 第 8 章 まとめ 本研究はステートマシン制御による一般的な USB デバイスコントローラの問題点を指摘し 、その解決策と して MPU を搭載した USB デバイスコントローラを提案した。 提案した USB デバイスコントローラは USB プロトコルとデバイスの両方を制御するため、デバイス制御に 時間的制約があったが 、ハッシュ関数による標準デバイスリクエストの判別手法によって高速な USB プロト コル処理を可能にし 、この問題点を解決した。 SFL 言語を用いて提案手法を用いた USB デバイスコントローラを設計し 、Verilog シミュレータによる論理 検証と評価を行った。シミュレータによる正常動作が確認できた USB デバイスコントローラにゲームパッド イ ンタフェースとゲームパッドを接続し 、USB ゲームパッドとして FPGA に実装した。FPGA に実装した USB ゲームパッド の動作は Windows2000 と RedHatLinux 環境で行い、USB アナライザやロジックアナライザで USB バスの値を監視し正常動作を確認した。 25 謝辞 26 業績 27 参考文献 28
© Copyright 2026 Paperzz
