JP4444101B2

JP4444101B2 - バスシステム、バスシステム内で用いるためのステーション、及びバスインタフェース

Info

Publication number: JP4444101B2
Application number: JP2004513949A
Authority: JP
Inventors: ジェローム、ティジア; バート、フェルテンテン
Original assignee: NXP BV
Current assignee: NXP BV
Priority date: 2002-06-12
Filing date: 2003-05-21
Publication date: 2010-03-31
Anticipated expiration: 2023-05-21
Also published as: US7383372B2; CN1659533A; WO2003107199A3; ATE403906T1; JP2005529430A; US20050216650A1; DE60322702D1; EP1516261A2; WO2003107199A2; KR20050010906A; AU2003228060A1; EP1516261B1; TWI313814B; CN100343840C; TW200404215A

Description

本発明は、第一のステーションと、信号を転送するためのバスに接続された第二のステーションと、を備えるバスシステムに係る。このバスシステムは、それによると第一のステーションがデータに対するリクエストを第二のステーションに向けて繰返して送ることを要請されるプロトコルに従って動作するように構成され、このプロトコルは、これらリクエストを第一のリクエストフォーマットにて第一の通信速度にて転送するための第一のモードと、これらリクエストを第二のリクエストフォーマットにて第二の速度にて転送するための少なくとも第二のモードを含む。第二のステーションは、リクエストをこれら第一と第二のモードを含む一群のモードから選択されたあるモードにて受信するように構成され、かつ、第一のステーションに対して、それが前記第一のモードに従って動作するように構成されているときは第一の指標を与え、それが第二のモードに従って動作するように構成されているときは第二の指標を与えるように構成される。

本発明は、更に、バスシステム内で用いるための、バスに対する接続を備えるステーションにも関する。このステーションは、それによるとこのステーションがリクエストをこの接続に向けて繰返して送ることを要請されるプロトコルに従って動作するように構成され、このプロトコルは、これらリクエストを第一のリクエストフォーマットにて第一の通信速度にて転送するための第一のモードと、これらリクエストを第二のリクエストフォーマットにて第二の速度にて転送するための少なくとも第二のモードを含む。

本発明は、更にバスシステム内で用いるための、バスに対する接続とプロセッサからリクエストプロパティ（request properties）を受信するための入力とを備えるバスインタフェースにも関する。このバスインタフェースは、それによるとこのバスインタフェースがリクエストをこの接続に向けて繰返して送るプロトコルに従って動作するように構成され、このプロトコルは、これらリクエストを第一のリクエストフォーマットにて第一の通信速度にて転送するための第一のモードと、これらリクエストを第二のリクエストフォーマットにて第二の速度にて転送するための少なくとも第二のモードを含む。

このようなバスシステムがユニバーサルシリアルバス（Universal Serial Bus, USB）仕様において開示されている。このUSB仕様は、Compaq Computer Corporation, Hewlett-Packard Company, Intel Corporation, Lucent Technologies Inc, Microsoft Corporation, NEC Corporation, 及びKoninklijke Philips Electronics N.Vを含む企業グループによって普及（promulgated）されている標準である。以下では、本発明の理解を助けるために関係があると思われるUSBの様々な面について説明する。USBに関するさらなる背景知識については、USB Specification 2.0を参照されたい。

USBは、パーソナルコンピュータと、様々な周辺機器、例えば、ウェブカメラ（webcams）、プリンタ、スキャナ、マイクロホン、キーボード、との間のデータの交換をサポートするために設計された標準バスである。USBバスは、こうして、現存のインタフェース、例えば、RS-232C、シリアルポート、パラレルポート、及びPS/2インタフェースに取って代わるものである。

バスシステム、例えば、USBシステムにおいては、電子バスステーションはバスを介して互いに接続される。通常は、バスステーションは、データを、処理或いは生成するため、或いはデータのフローを制御するためのプロセッサ或いは計算システムを備える。USBステーションは、ホスト（例えば、パーソナルコンピュータ）として、或いはデバイス（周辺機器）として定義される。一般的には、任意のUSBシステム内に、ホストは１つしか存在しない。ホストの所のUSBインタフェースは、ホストコントローラとも呼ばれる。ホストコントローラは、ハードウェア、ファームウエア、或いはソフトウェアの組み合わせにて実現される。USBデバイスはハブとして定義され、これらは追加の接続点（attachment points）或いはファンクション（functions）を提供し、これによってシステムに追加の能力が提供される。これらデバイスは、ホストに、星型トポロジにて接続される。ハブは、あるUSBデバイスが接続或いは除去されたことを示す。ホストは、新たに接続されたUSBデバイスが、ハブであるか、或いはファンクションであるかを決定し、そのUSBデバイスに一意のUSBアドレスを割当てる。全てのUSBデバイスは、一意のUSBアドレスにてアドレスされる。各デバイスは、加えて、１つ或いは複数のエンドポイントをサポートし、ホストはこれらを用いて（それらデバイスと）通信する。

USBはポーリング方式のバス（polled bus）である。ホストコントローラが全てのデータ転送を先導（initiates）する。ほとんどのバストランザクションは、最高３個までのパケットの伝送を伴う。各トランザクションは、ホストコントローラが、スケジュールベースにて、そのトランザクションのタイプと方向、USBデバイスアドレス、及びエンドポイント番号を記述するUSBパケットを送信することで開始される。このパケットは、”トークンパケット（token packet）”と呼ばれる。アドレスされたUSBデバイスは、それ自身を、該当するアドレスフィールドを復号することで選択する。ある与えられたトランザクションにおいて、データがホストからデバイスへ、或いはデバイスからホストへと転送される。データ転送の方向は、このトークンパケット内に指定される。次に、そのトランザクションのソース（側）が、データパケットを送信するか、或いは転送すべきデータを有さないことを示す。宛先（側）は、一般には、これに応答して、その転送が成功したか否かを示すハンドシェークパケット（handshake packet）を送り返す。

USBは、３つのレンジのデータトラフィックワーク負荷（data traffic workloads）：つまり、高速（high-speed）、全速（full-speed）、及び低速（low-speed）をサポートする。低速データレンジ（low-speed data range）は、キーボード、マウス（mice）、ゲーム用周辺機器等の対話型デバイス用として設計され、１０から１００kb/secの通信をサポートする。全速データレンジは、電話、オーディオ、及び圧縮ビデオアプリケーション用として設計され、５００kb/secから１０Mb/secの通信をサポートする。高速データレンジは、ビデオ及び格納（storage）アプリケーション用として設計され、２５から４００Mb/secの通信をサポートする。

USBは、PCと周辺機器との間でデータを交換するための非常に普及したインタフェースとなっている。例えば、デジタル静止カメラ（digital still carmeras）、ビデオカメラ、パーソナルデジタルアシスタント、セルラ電話器等の、ますます多くのポータブル周辺機器が、PCとの通信のためにUSBを用いるようになっている。これらポータブルデバイスの多くは、USBインタフェースを介して互いに通信することで利益を得るが、ただし、USBの幾つかの点はこの達成を困難なものとしている。より具体的には、USB通信は、ホストと周辺機器との間でしか行なえない。ところが、PCホストとしての資格を有するためには、そのデバイスは、幾つかの特性（能力）、例えば、多数のデバイスドライバ用のメモリ、大きな電流を電源とする能力、Series”A”コネクタリセプタクル等、を有することを要求される。多くのデバイスにとって上述の全ての能力を有することは現実的ではなく、多くの場合、これら能力は、ポータブルデバイスを互いにインタフェースするためには必要とされない。

これら制限的な要件を克服するために、USB2.0の補強機器（supplement）としての、ポータブル用のUSBアプリケーションである、USB On-The-Go (OTG）がKoninklijke Philips Electronics N.V.を含む複数の会社からの寄与者（contributors）によって開発された。OTGは、あるポータルデバイスがPCとして要求される上述の全ての機能（能力）をサポートするという負担を課せられることなく、ある限定されたUSBホストとして振る舞うことを許される。USB2.0仕様への補強機器としてのOTGは、USB2.0仕様に対する最小限の変更セットを定義し、これにより、ポータブルUSBアプリケーションが可能となる。OTGに関するさらなる背景に関しては、On-The-Go Supplement to the USB 2.0 Specification, Revision 1.0を参照されたい。

USB2.0或いはOTGホストコントローラは、高速通信をサポートする一つの高速ホストコントローラと、全速及び低速通信をサポートする一つ或いは複数のコンパニオンホストコントローラとを備える。高速ホストコントローラは、Enhanced Host Controller Interface (EHCI）を実装し、このため、EHCIホストコントローラ或いは略してeHCとも呼ばれる。これは、このホストコントローラに接続された高速デバイスとの全ての高速通信のために用いられる。コンパニオンホストコントローラは、例えば、Universal Host Controller Interface（UHCI）或いはOpen Host Controller Interface for USB (OHCI）を実装する。コンパニオンホストコントローラ或いはcHCは、ホストコントローラに接続された全速或いは低速デバイスとの通信を扱う。要約すると、このようなUSB2.0或いはOTGをサポートするために、ホストコントローラは、実際には、２つの別個のホストコントローラ、つまり、eHCとcHCを含む。

本発明は、この”２エンジン（two-engine）”アプローチでは、短所として、eHCとcHCの両方が別個のソフトウェアドライバを要求するという洞察に基づく。これは、例えば、ポータブルアプリケーションの場合のような、埋込み環境（embedded environment）では、ハードウェアとソフトウェア資源に限りがあり、制約となる。このアプローチのもう一つの短所は、２つの別個のソフトウェアドライバを開発及びデバッグすることを要求されるために、製品の開発により長い時間が必要となることである。更に、オペレーティングシステムは、eHCとcHCの両方に対してデータ通信をスケジュールすることを要求される。

本発明の一つの目的は、とりわけ、第一のステーションの設計を簡素化することで、ポータブルアプリケーションにより適するバスシステムを提供することにある。

本発明によると、これを達成するために、冒頭において定義されたようなバスシステムの、前記第一のステーションは、プロセッサと、コントローラと、トランスレータとを備え、前記プロセッサは、リクエストに対するリクエストプロパティを前記第一のリクエストフォーマットにて作成するよう動作可能であり、前記コントローラは、前記リクエストプロパティから前記リクエストを前記第一のリクエストフォーマットにて作成するよう動作可能であり、前記コントローラは、更に、前記第一の指標が検出された場合は、前記リクエストを前記第一のフォーマットにて前記第二のステーションに送信し、前記第二の指標が検出された場合は、前記リクエストを前記トランスレータに転送するよう動作可能であり、前記トランスレータは、前記リクエストを前記第二のフォーマットにて前記第二のステーションに送信するよう動作可能である。

動作において、第一のステーション内のプロセッサは、情報を第二のステーションに提供すること、或いは第二のステーションから情報を得ることを要求される。これを達成するためには、第一のステーションは、第二のステーションとバスを介して通信することを要求される。ポーリング方式のバスシステム（polled bus system）、例えば、USBシステムにおいては、通信は、第一のステーションによって、リクエストを送信することで先導される。第二のステーションは、これらリクエストを、第一或いは第二のモードのいずれかによって受信するように構成される。第二のステーションは、第一の指標を介してそれが第一のモードにて動作することを示し、或いは第二の指標を介してそれが第二のモードにて動作することを示す。従って、第一のステーションは、これらリクエストを第一のモードと第二のモードの両方にて送信できるように構成される必要がある。

本発明によるバスシステムにおいては、トランスレータが、必要に応じて、これらリクエストを第二のリクエストフォーマットにて第二の通信速度にて転送する、第二のモードを扱う。従って、プロセッサは、第一のモードにて伝送されるべきリクエストと第二のモードにて伝送されるべきリクエストとを区別することを要求されない。このため、プロセッサは、リクエストに対する第一のモードにて伝送されるべきリクエストプロパティを作成する能力を持つことで十分である。このため、このプロセッサは、リクエストに対するリクエストプロパティを第一のフォーマットにて作成するため必要とされるハードウェア及びソフトウェア資源を有することで十分である。このため、このバスシステムの第一のステーションの設計が簡素化され、このため、このシステムは、ポータブルアプリケーションにより適するものとなる。

本発明によるバスシステムの一つの実施例においては、前記第二のステーションはあるアドレスを割当てられ、前記リクエストプロパティはアドレス情報を含み、コントローラは、これらアドレス情報から、そのリクエストが、それぞれ、第一のフォーマット或いは第二のフォーマットのいずれによって送信されるべきかを決定するよう動作可能である。

バスを介していったん第一のステーションに接続されると、各第二のステーションは、第一のステーションに対して、第一の指標（indicator）にて、それが第一のモードにて通信することを、或いは第二の指標にて、それが第二のモードにて通信することを示す。バスを介して第一のステーションに接続された各第二のステーションに一意のアドレスを割当てることで、コントローラは、ある第二のステーションが、第一のモード或いは第二のモードのいずれによって通信するかを知ることが可能となる。こうして、リクエストプロパティ内にアドレス情報を含めることで、コントローラは、十分に、そのリクエストがどのフォーマットにて送信されるべきか、従って、そのリクエストをトランスレータに転送すべきか否かを決定することが可能となる。これによって、第二のステーションの設計はさらに簡素化される。

本発明によるバスシステムのもう一つの実施例においては、前記第一のステーションは、更に、それぞれ、コントローラとトランスレータによって、第一と第二のモードにて送信されたこれらリクエストをバスにルーティングするためのルータを備える。

ルータを用いることで、第一のステーションに接続された各第二のステーションは、コントローラ或いはトランスレータのいずれかに接続される。こうして、コントローラとトランスレータとの間の潜在的なバス衝突（bus conflicts）が解消される。これによって、コントローラとトランスレータの両方の設計がさらに簡素化される。

本発明によるバスシステムのさらにもう一つの実施例においては、前記第一のモードは、応答を第一の応答フォーマットにて第一の通信速度にて転送するためにも用いられ、前記第二のモードは、応答を第二の応答フォーマットにて第二の速度にて転送するためにも用いられ、前記第二のステーションは、応答を第一のステーションに向けて、第一と第二のモードを含む一群のモードから選択されたあるモードにてリクエストを送信するよう動作可能であり、前記トランスレータは、前記応答を前記第二の応答フォーマットにて受信し、これら応答を前記コントローラに転送するよう動作可能であり、コントローラは、これら応答を第一のフォーマットにて受信し、この応答から応答プロパティを第一の応答フォーマットにて作成するよう動作可能であり、前記プロセッサは前記コントローラによって生成された応答プロパティを扱うよう動作可能である。

トランスレータによってリクエストと応答の両方をそれぞれ第二のフォーマットにて扱えるようにすることで、第一のステーション内で要求されるハードウェア及びソフトウェア資源がさらに低減され、結果として、ポータブルアプリケーションにより適するバスシステムが得られる。

本発明に係るステーションは、バスシステム内で用いるための、バスに対する接続を備える。このバスステーションは、この接続にリクエストを繰返して送るプロトコルに従って動作するように構成され、このプロトコルは、これらリクエストを第一のリクエストフォーマットにて第一の通信速度にて転送するための第一のモードと、これらリクエストを第二のリクエストフォーマットにて第二の速度にて転送するための少なくとも第二のモードを含む。本発明によると、このステーションは、プロセッサと、コントローラと、トランスレータとを備え、トランスレータは、リクエストに対するリクエストプロパティを第一のリクエストフォーマットにて作成するよう動作可能であり、コントローラは、このリクエストプロパティからこれらリクエストを第一のリクエストフォーマットにて作成するよう動作可能であり、コントローラは、更に、これらリクエストを第一のフォーマットにて前記接続に送信し、或いはこれらリクエストを前記トランスレータに転送するよう動作可能であり、前記トランスレータは、これらリクエストを第二のフォーマットにて前記接続に送信するよう動作可能である。

本発明は、更に、バスシステム内で用いるための、バスに対する接続とプロセッサからリクエストプロパティを受信するための入力とを備えるバスインタフェースに係る。このバスインタフェースは、このバスインタフェースがリクエストを前記接続に向けて繰返して送るプロトコルに従って動作するように構成され、このプロトコルは、これらリクエストを第一のリクエストフォーマットにて第一の通信速度にて転送するための第一のモードと、これらリクエストを第二のリクエストフォーマットにて第二の速度にて転送するための少なくとも第二のモードを含む。本発明によると、このバスインタフェースは、コントローラと、トランスレータとを備え、前記入力は、リクエストに対するリクエストプロパティを第一のリクエストフォーマットにて受信するよう動作可能であり、コントローラは、これらリクエストプロパティからこれらリクエストを第一のリクエストフォーマットにて作成するよう動作可能であり、コントローラは、更に、これらリクエストを第一のフォーマットにて前記接続に送信し、或いはこれらリクエストを前記トランスレータに転送するよう動作可能であり、このトランスレータは、これらリクエストを第二のフォーマットにて前記接続に送信するよう動作可能である。

動作において、本発明によるこのバスインタフェースは、その入力の所にリクエストプロパティを第一のリクエストフォーマットにて受信するのみである。コントローラは、プロセッサから、リクエストプロパティを第一のリクエストフォーマットにて受信するのみである。トランスレータが、要求に応じて、これらリクエストを第二のフォーマットのリクエストに翻訳する。従って、コントローラは、より少ないハードウェア及びソフトウェア資源しか必要とされず、このためこの設計が簡素化される。この結果、ポータブルアプリケーションにより適するバスインタフェースが得られる。

以下では、本発明の、上述の及びその他の目的並びに特徴について、添付の図面との関連でより詳細に説明する。

図面中、同一のパーツは同一の参照符号にて示される。

図１は本発明によるバスシステムを示すブロック図である。図示されるバスシステム１００は、例えば、USB２０或いはOTGシステムから成る。このバスシステムは、第一のステーション或いはホスト１０１、第二のステーション或いはデバイス１０２、１０３、及び第一のステーション１０１を第二のステーション１０２、１０３に接続するバス１０４を備える。第一のステーション１０１はプロセッサ１０５、ホストコントローラとも呼ばれるコントローラ１０６、トランスレータ１０７、及びポートルータとも呼ばれるルータ１０８を備える。コントローラ１０６、トランスレータ１０７、及びルータ１０８は、例えば、図１に示されるようにバスインタフェース１０９内に含めることもできる。

バスシステム、例えば、USB2.0或いはOTGにおいては、デバイス１０２、１０３は、３つの可能なモード、つまり、高速、全速、及び低速の１つにて通信するよう動作可能である。これらデバイスは、USB2.0仕様において定義される通常のやり方にて、ホスト１０１に対して、それが、第一のモードとも呼ばれる高速モードにて通信するのか、或いは、まとめて第二のモードとも呼ばれる全速或いは低速モードにて通信するのかの指標（indication）を送る。このためには、デバイス１０２、１０３がバス１０４に接続され後に、デバイス１０２、１０３がリセットされた後に、下位レベルのシグナリング（low level signaling）が行なわれる。

ホスト集中型のバスシステム（host centric bus system）、例えば、USB2.0或いはOTGにおいては、ホスト１０１は、動作において、リクエストを、デバイス１０２、１０３に繰返して（repeatedly）送る。これらデバイスは、これらリクエストに、応答（responses）にて答える。このバスシステム１００における第一の通信モードにおいては、リクエストは、第一のリクエストフォーマットにて、第一の速度にて、ホスト１０１によって送信され、デバイス１０２、１０３によって受信され、他方、応答は、第一の応答フォーマットにて、第一の速度にて、デバイス１０２、１０３によって送信され、ホスト１０１によって受信される。バスシステム１００における第二の通信モードにおいては、リクエストは、第二のリクエストフォーマットにて、第二の速度にて、ホスト１０１によって送信され、デバイス１０２、１０３によって受信され、他方、応答は、第二の応答フォーマットにて、第二の速度にて、デバイス１０２、１０３によって送信され、ホスト１０１によって受信される。高速のリクエスト及び応答（第一の通信モード）のフォーマット、及び全速及び低速のリクエスト（第二の通信モード）のフォーマットに関する詳細については、USB2.0仕様を参照されたい。

バスシステム１００においては、プロセッサ１０５は、デバイス１０２、１０３に送信されるべきリクエストに関するリクエストプロパティ（request properties）を生成する。プロセッサ１０５は、リクエストに関するリクエストプロパティを第一のリクエストフォーマットにて作成する。コントローラ１０６は、例えば、これらリクエストプロパティ内に含まれるアドレス情報或いはモード情報に基づいて、そのリクエストが、そのリクエストプロパティに基づいて、第一のフォーマットにて送信されるべきであるか、或いは第二のフォーマットにて送信されるべきであるかを決定する。そのリクエストが第一のフォーマットにて送信されるべきである場合は、そのリクエストは、コントローラ１０６によって作成され、送信される。そのリクエストが第二のフォーマットにて送信されるべきであるときは、そのリクエスト或いはリクエストプロパティは、コントローラ１０６から、トランスレータ１０７に転送される。トランスレータ１０７は、これらリクエスト或いはリクエストプロパティを第二のフォーマットのリクエストに翻訳する。ルータ１０８は、コントローラ１０６から来るリクエストと、トランスレータ１０７から来るリクエストの両方をバス１０４にルーティングする。

プロセッサ１０５は、加えて、デバイス１０２、１０３によって送信された応答の応答プロパティを扱う。ホスト１０１によって第一の応答フォーマットにて受信された応答は、ルータによってコントローラ１０６にルーティングされる。コントローラ１０６は、応答に関する応答プロパティを第一のフォーマットにて作成し、これらプロパティをプロセッサ１０５に送信する。ホスト１０１によって第二の応答フォーマットにて受信された応答は、ルータによってトランスレータ１０７にルーティングされる。トランスレータ１０７は、この第二のフォーマットの応答を第一のフォーマットの応答に翻訳し、この応答をコントローラ１０６に転送する。コントローラ１０６は、応答に関する応答プロパティを第一のフォーマットにて作成し、これらプロパティをプロセッサ１０５に送信する。

リクエスト及び応答をこのやり方にて通信することの長所は、プロセッサ１０５とコントローラ１０６は、両方とも、リクエストプロパティ及びリクエストを第一のモードにて扱うだけで済むことである。こうして、USB2.0或いはOTGシステムにおいては、プロセッサ１０５とコントローラ１０６は、全てのデバイス１０２、１０３を、あたかもそれらが高速デバイスであるかのように扱うことができる。このため、プロセッサ１０５とコントローラ１０６は高速通信を扱うことのみを要求される。トランスレータ１０７は、高速通信から全速或いは低速への、或いはこの逆への要求される翻訳を遂行する。

USB2.0システムにおいては、コントローラ１０６は、ホストコントローラであり、プロセッサ１０５は、システムプロセッサ、例えば、パーソナルコンピュータのマイクロプロセッサである。このようなシステムにおいては、コントローラ１０６とプロセッサ１０５との間の通信は、PCIバスを介して行なわれる。このため、これらリクエスト及び応答プロパティは、PCIバスを介してメッセージの形態にて転送される。ポータブルアプリケーション（portable application）とデバイスとを接続するOTGシステムにおいては、プロセッサ１０５は、ポータブルアプリケーションのシステムプロセッサから成る。このようなシステムにおいては、プロセッサ１０５とコントローラ１０６との間の通信は、例えば、プロセッサ１０５のパラレルポートとコントローラ１０６或いはバスインタフェース１０９のパラレルポートとに接続されたパラレルバスを介して行なわれる。この場合は、これらリクエスト及び応答プロパティは、適当なフォーマットのメッセージの形態にて、パラレルバスを介して転送される。

図２は、公知のバスインタフェースを示すブロック図である。このブロック図は、EHCI (Enhanced Host Controller) Specification for Universal Serial Bus, version 1.1, March12, 2002（ユニバーサルシリアルバスに対するEHCI仕様）において定義されるようなUSB2.0ホストコントローラを示すが、詳細についてはこれを参照されたい。ホストコントローラとも呼ばれるこのバスインタフェース２００は、システムプロセッサへのインタフェース２０１、eHCとも呼ばれる高速ホストコントローラ２０２、及びcHCとも呼ばれるコンパニオンホストコントローラ２０３を備える。このEHCI仕様によると、コンパニオンホストコントローラ（cHC）は、USB1.1とコンパティブルであることを要求される。cHCは省くことも、複数個設けることもできる。ホストコントローラ２００は、加えて、PRLとも呼ばれるルータ或いはポートルーティング論理２０４を備える。このポートルーティング論理２０４は、高速ホストコントローラ２０２のポート２０６ととコンパニオンホストコントローラ２０３のポート２０７とを、ホストコントローラ２００のルート（根）ポート２０５にルーティングする。高速ホストコントローラ２０２はEHCIインタフェースを実装する。これは、ホストコントローラ２００のルートポート２０５に接続された高速デバイスへの全ての高速通信のために用いられる。EHCI仕様によると、ホストコントローラ２００のルート（根）ポート２０５に接続された全速及び低速デバイスへの通信は、コンパニオンUSB1.1ホストコントローラ２０３にて扱われる。高速ホストコントローラ２０２は、全速或いは低速デバイスに対しては動作できない。このフレキシブルな動作環境を提供するための鍵は、ポートトランシーバのルーティング論理２０４である。

コンパニオンホストコントローラ２０３は、任意のUSB1.1ホストコントローラであり得る。これは、例えば、オープンホストコントローラインタフェース（Open Host Controller Interface、OHCI）或いはユニバーサルバスホストコントローラインタフェース（Universal bus Host Controller Interface 、UHCI）を実装する。コンパニオンホストコントローラ２０３は、ルート（根）２０５に接続された全速及び低速UBSデバイスを管理する。コンパニオンホストコントローラ２０３は、高速ホストコントローラ２０２についての知識は有さない。高速デバイスは、高速ホストコントローラ２０２に、ルーティングされ、これによって制御される。起動されており、そのように構成（configured）されているときは、高速ホストコントローラ２０２が、全てのルート（根）ポート２０５の省略時のオーナ（default owner）となる。このことは、全てのデフォルトルートポート（default root port）２０５は、高速ホストコントローラのポート２０６にルーティングされることを意味する。高速コントローラ２０２は、システムプロセッサの所に常駐するそのドライバソフトウェアと一体となって、最初に、接続されている全てのデバイスを検出し、これらデバイスにアドレスを割当てる。ある接続されているデバイスが高速デバイスではないと思われ場合は、高速ホストコントローラ２０２は、そのポートの所有、従ってそのデバイスの制御を、コンパニオンホストコントローラ２０３に引き渡す。その後、コンパニオンホストコントローラ２０３の制御下で、この新たなポート指定（port enumeration）に対して、接続されたデバイスの検出が最初から開始され、そのデバイスが確認（enumerated）され、そのデバイスにアドレスが割当てられる。他方、そのデバイスが高速デバイスであることが検出された場合は、高速ホストコントローラ２０２は、そのポートの所有を維持し、高速ホストコントローラ２０２の制御下で、そのデバイスの確認（enumeration）が完結される。

このいわゆる”ツーエンジン（two-engine）”アーキテクチャの大きな短所は、システムプロセッサ上に、一方はEHCIを実装する高速ホストコントローラ２０２のための、もう一方は、OHCI或いはUHCIを実装するコンパニオンホストコントローラ２０３のための、２つのソフトウェアスタックが要求されることにある。これは、とりわけ、ハードウェア及びソフトウェア資源が非常に限られている埋込み環境（embedded environment）においては大きな制約となる。このアーキテクチャは、他にも、デバッギング（debugging）の作業が”二重手間”となることや、システムプロセッサ上にオペレーティングシステムのための２つのスケジューリングスキームを実装することが必要となることなどの短所を有する。この両方とも、販売までの時間を長引かせる要因となる。更に、このアーキテクチャでは、図１に示される本発明によるバスインタフェース１０９のアーキテクチャと比較して、ホストコントローラ２００内により多くのハードウェア（より多数のゲート）が必要となる。

図３は、公知のトランスレータを示すブロック図である。このブロック図は、USB2.0仕様においてUSB2.0ハブ内に設けることを指定されているトランザクショントランスレータ３００を示す。以下では、このトランザクショントランスレータ３００について簡単に説明する。より詳細については、USB2.0仕様を参照されたい。このトランザクショントランスレータ３００は、高速ハンドラ３０１、全速/低速ハンドラ３０２、及びバッファ３０３、３０４、３０５、及び３０６を備える。高速ハンドラ３０１は、高速モードでの通信用に設計されており、ホストからの、全速或いは低速リクエストに翻訳されるべきリクエストを受け取るとともに、ホストに、全速或いは低速応答から（高速応答に）翻訳された応答を送信する。全速/低速ハンドラ３０２は、あるデバイスからの、高速応答に翻訳されるべき応答を受け取るとともに、そのデバイスに、高速リクエストから（全速/低速リクエスト）翻訳されたリクエストを送信する。バッファ３０３、３０４、３０５及び３０６は、進行中のトランザクションを保持するとともに、各バッファリングされたトランザクションの状態を、それがトランザクショントランスレータ３００によって処理されている際に追跡する。トランザクションは、ホストによって送信されるリクエストと、デバイスによって送信される応答から成る。バッファ３０３、３０４、３０５及び３０６は、高速ハンドラ３０１と全速/低速ハンドラ３０２との間の接続を提供する。矢印は、データの流れを示す。

トランザクショントランスレータ３００の状態の追跡は、そのトランザクションが具体的にどのようなUSB転送タイプに属するかに依存する。可能な転送タイプには、バルク（bulk）、制御（control）、割込み（interrupt）、及びイソクロナス（isochronous）等がある。高速ハンドラ３０１は、高速分割開始（high-speed start-split）トランザクションを受け取ったり、高速分割完了（high-speed complete-split）トランザクションに応答したりする。高速ハンドラ３０１は、分割開始（start-split）トランザクションを、バッファ３０３及び３０４内に、全速/低速ハンドラ３０２による処理のために入れる。

こうしてバッファリングされた分割開始トランザクション（start-split transactions）は、全速/低速ハンドラ３０２に、全速/低速ハンドラ３０２が、それぞれ、全速或いは低速デバイスに向けて対応する全速或いは低速トランザクションを発行することを可能にする情報を提供する。加えて、全速/低速ハンドラ３０２は、これら全速/低速トランザクションの結果を、バッファ３０３及び３０４内にバッファリングするが、これらは、高速ハンドラ３０１によって、対応する分割完了トランザクション（complete-split transactions）を介して高速バス上に返される。

図３に示されるようなトランザクショントランスレータは、図１に示されるような本発明によるバスシステム１００内に設けられるトランスレータとは異なることに注意する。本発明によるトランスレータ１０７は、ハブ内ではなく、バスインタフェース自身内に組み込まれる。プロセッサ１０５の方向へのトランスレータ１０７からの、或いはこの逆方向への通信は非USB通信である。これに対して、トランザクショントランスレータ３００の上流の通信、つまり、ホストに向かう及びホストからの通信は、高速USB通信である。こうして、システムプロセッサ内に要求されるUSB1.1ドライバのトップの所には、高速、全速、及び低速通信を実装する従来のUSB2.0システムは、トランザクショントランスレータ３００を備えるハブを必要とし、このために要求されるハードウェア資源が更に増加する。

図４は、本発明によるバスインタフェースを示すブロック図である。バスインタフェース４００は、システムプロセッサへのインタフェース４０１、高速コントローラ４０２、トランスレータ４０６、及びルータ４０７を備える。高速コントローラ４０２は、構造デコーダ４０３、ハブエミュレータ（hub emulator）４０４、及び高速パケットハンドラ４０５を備える。

システムプロセッサへのインタフェース４０１は、任意のシステムバス、例えば、PCI或いはAHBバスへのインタフェースであり得る。

高速コントローラは、EHCI仕様において定義されているような、リクエストプロパティとも呼ばれる、全ての構造を扱う構造デコーダ４０３を備える。この構造デコーダ４０３は、EHCI仕様において定義されるデータ構造をフェッチングし、これら構造内の様々なフィールドを復号する。これらフィールドは、デバイスアドレス、デバイスエンドポイント番号、デバイス速度、送信或いは受信のために要求されるバイト数等を指定する。こうして復号された情報に基づいて、構造デコーダ４０３は、ハブエミュレータ４０４、高速パケットハンドラ４０５、或いはトランスレータ４０６へのリクエストを開始する。

そのデバイスアドレスがハブエミュレータ４０４のアドレスである場合は、そのリクエストはハブエミュレータ４０４に向けて発行され、その状態は直接にシステムプロセッサに返され、システムメモリ内で、USBバスを用いることなく更新される。そのデバイスアドレスがハブエミュレータ４０４のアドレスとは異なる場合は、そのデバイス速度フィールドは、このリクエストをどのモジュールが扱うべきかを示す。デバイス速度フィールドが高速デバイスであることを示す場合は、高速パケットハンドラ４０５がそのリクエストを扱う。高速パケットハンドラ４０５は、高速USBトランザクションを、全ての高速ポート４０８上に発行する。このUSBトランザクションの状態は、構造デコーダ４０３に返され、構造デコーダ４０３は、この状態情報をシステムプロセッサに返し、システムプロセッサはこの状態情報をシステムメモリ内で更新する。デバイス速度フィールドが全速或いは低速デバイスであることを示す場合は、構造デコーダは、リクエストを、トランスレータ４０６に向けて発行する。トランスレータ４０６は、構造デコーダ４０３からのこの情報を用いて、全速及び低速バス上でのUSBトランザクションを開始する。

高速パケットハンドラ４０５は、構造デコーダ４０３のリクエストを、直ちにUSBバス上に発行する。トランスレータ４０６は、内部に、２つのリクエストを格納することができるキューシステムを有する。これは、EHCIとUSB2.0ハブを備える従来のUSB2.0システムと互換性を持たせるために行なわれる。このような従来のシステムにおいては、一つの全速或いは低速トランザクションを完結させるために、２つの高速トランザクションを発行することを要求される。第一の高速トランザクションは、図３に示されるようなトランザクショントランスレータ３００に、全速或いは低速バス上でのトランザクションを開始するための情報を与える。トランザクショントランスレータ３００への第二の高速トランザクションは、全速或いは低速バス上に発行されたトランザクションの状態情報を取り出すために発行される。

本発明によるバスインタフェース４００によると、同一の原理が用いられるが、ただし、高速USBバスは用いられない。両方のリクエストとも、直接にトランスレータ４０６に向けて発行される。分割開始（start-split）と呼ばれる第一のリクエストの後に、トランスレータ４０６は、全速/低速USBバス上でトランザクションを開始する。分割完了（complete-split）と呼ばれる第二のリクエストがあると、トランスレータ４０６は、それが全速/低速バス上で遂行したトランザクションの状態情報を返す。トランスレータ４０６は、USB仕様に基づいて、適当なときに全速/低速バス上でのUSBトランザクションを開始する。これらトランザクションの結果は、トランスレータ４０６内にローカル的に格納され、分割完了（complete-split）が受信されたとき返される。

本発明によるバスインタフェース４００の、USB2.0ハブと組み合わせて用いられる従来のEHCIと比較したときの長所は、従来の組み合わせでは、USB2.0ハブ内に組み込まれた、図３に示されるようなトランザクショントランスレータ３００との間の全ての通信は全USBツリーを介して送られるところにある。これとは対照的に、本発明によるバスインタフェース４００のアーキテクチャでは、高速USB転送はトランスレータ４０６との通信とパラレルに扱うことができる。

更に、従来のEHCIとUSB2.0ハブとを組み合わせて用いるやり方においては、全ての全速及び低速バストラフィックを、高速にてUSB2.0ハブに転送することを要求される。これとは対照的に、本発明によるバスシステムにおいては、高速トラフィックと、全速/低速トラフィックは互いに分離される。トランスレータ４０６によって送ることを要求される全速/低速トラフィックは、高速バス上には転送されない。このため、高速バス上の負荷が軽減され、EHCIとUSB2.0ハブを組み合わせて用いる従来の方法と比較して、高速バス上により多くのトラフィックを発行することが可能になる。

ポートルーティング論理（port routing logic）とも呼ばれるルータ４０７は、接続されたUSBデバイスの速度を決定する。ルータ４０７のポート４１０に接続されたUSBデバイスが高速デバイスである場合は、これは、そのポートを、高速パケットハンドラ４０５の対応する高速ポート４０９にルーティングする。ポート４１０に接続されたデバイスが全速或いは低速ポートであるときは、これは、そのポート４１０をトランスレータ４０６の対応する全速/低速ポート４０９にルーティングする。

上で説明された本発明の実施例は解説のためのもので、制限を意図するものではない。当業者においては、添付のクレームに定義される本発明の範囲から逸脱することなく、これら実施例に対して様々な修正を加えることが可能である。

本発明によるバスシステムを示すブロック図である。公知のバスインタフェースを示すブロック図である。公知のトランスレータを示すブロック図である。本発明によるバスインタフェースを示すブロック図である。

Claims

第一のステーションと信号を転送するためのバスによって接続された第二のステーションとを備えるポーリング方式のバスシステムであって、前記バスシステムは、前記第一のステーションがデータに対するリクエストを前記第二のステーションに向けて繰返して送るプロトコルに従って動作するように構成され、前記プロトコルは、前記リクエストを第一のリクエストフォーマットにて第一の通信速度にて転送するための第一のモードと、前記リクエストを第二のリクエストフォーマットにて第二の速度にて転送するための少なくとも第二のモードを含み、前記第二のステーションは、前記第一と第二のモードを含む一群のモードから選択されたあるモードにてリクエストを受信するように構成され、かつ、それが前記第一のモードに従って動作するように構成されているときは第一の指標を前記第一のステーションに対して与え、それが前記第二のモードに従って動作するように構成されているときは第二の指標を与えるように構成され、前記第一のステーションは、プロセッサと、コントローラと、を備え、前記プロセッサは、リクエストに対するリクエストプロパティを前記第一のリクエストフォーマットにて作成するよう動作可能であり、前記コントローラは、前記リクエストプロパティから前記リクエストを前記第一のリクエストフォーマットにて作成するよう動作可能であり、更に、前記第一の指標が検出された場合は、前記リクエストを前記第一のフォーマットにて前記第二のステーションに送信し、
前記バスシステムは、ＵＳＢシステムであり、前記第一のステーションはＵＳＢホストであり、前記第一のステーションはトランスレータをさらに備え、前記コントローラは、前記第二の指標が検出された場合は、前記リクエストを前記トランスレータに転送するよう動作可能であり、前記トランスレータは、前記リクエストを前記第二のフォーマットにて前記第二のステーションに送信するよう動作可能である、ことを特徴とするバスシステム。
前記リクエストプロパティはモード情報を含み、前記コントローラは、前記モード情報から、前記リクエストが、それぞれ、前記第一のフォーマット或いは第二のフォーマットのいずれによって送信されるべきかを決定するよう動作可能である、ことを特徴とする請求項1記載のバスシステム。
前記第二のステーションはあるアドレスを割当てられ、前記リクエストプロパティはアドレス情報を含み、前記コントローラは、前記アドレス情報から、前記リクエストが、それぞれ、前記第一のフォーマット或いは第二のフォーマットのいずれによって送信されるべきかを決定するよう動作可能である、ことを特徴とする請求項1記載のバスシステム。
前記第一のステーションは、更に、それぞれ、前記コントローラと前記トランスレータによって、前記第一と第二のモードにて送信された前記リクエストを、前記バスにルーティングするためのルータを備える、ことを特徴とする請求項1記載のバスシステム。
前記第一のモードは、応答を第一の応答フォーマットにて前記第一の通信速度にて転送するためにも用いられ、前記第二のモードは、前記応答を第二の応答フォーマットにて前記第二の速度にて転送するためにも用いられ、前記第二のステーションは、応答を前記第一のステーションに向けて、前記第一と第二のモードを含む一群のモードから選択されたあるモードにて送信するよう動作可能であり、前記トランスレータは、前記応答を前記第二の応答フォーマットにて受信し、前記応答を前記コントローラに転送するよう動作可能であり、前記コントローラは、前記応答を前記第一のフォーマットにて受信し、前記応答から応答プロパティを前記第一の応答フォーマットにて生成するよう動作可能であり、前記プロセッサは前記コントローラによって生成された前記応答プロパティを扱うよう動作可能である、ことを特徴とする請求項1記載のバスシステム。
前記第一のステーションは、更に、前記第二のステーションによって送信された前記応答を、前記トランスレータと前記コントローラにルーティングするためのルータを備え、前記ルータは、前記第一の指標が検出された場合は、前記応答を前記コントローラにルーティングし、前記第二の指標が検出された場合は、前記トランスレータにルーティングするよう動作可能である、ことを特徴とする請求項５記載のバスシステム。
ポーリング方式のバスシステム内で用いるためのバスに対する接続を備えるステーションであって、前記ステーションは、前記ステーションがリクエストを前記接続に向けて繰返して送るプロトコルに従って動作するように構成され、前記プロトコルは、前記リクエストを第一のリクエストフォーマットにて第一の通信速度にて転送するための第一のモードと、前記リクエストを第二のリクエストフォーマットにて第二の速度にて転送するための少なくとも第二のモードを含み、前記ステーションは、前記バスに接続された他のステーションが前記第一のモードで動作するように構成される場合には前記他のステーションからの第一の指標を受信するように構成され、前記他のステーションが前記第二のモードで動作するように構成される場合には前記他のステーションからの第二の指標を受信するように構成され、前記ステーションは、プロセッサと、コントローラと、を備え、前記プロセッサは、リクエストに対するリクエストプロパティを前記第一のリクエストフォーマットにて生成するよう動作可能であり、前記コントローラは、前記リクエストプロパティから前記リクエストを前記第一のリクエストフォーマットにて作成するよう動作可能であり、更に、前記コントローラは、前記第一の指標が検出された場合には前記リクエストを前記第一のフォーマットにて前記接続に送信し、
前記ステーションはＵＳＢホストであり、前記ステーションはトランスレータを備え、前記コントローラは、前記第二の指標が検出された場合には前記リクエストを前記トランスレータに転送するよう動作可能であり、前記トランスレータは、前記リクエストを前記第二のフォーマットにて前記接続に送信するよう動作可能である、ことを特徴とするステーション。
前記リクエストプロパティはモード情報を含み、前記コントローラは、前記モード情報から、前記リクエストが、それぞれ、前記第一のフォーマット或いは第二のフォーマットのいずれによって送信されるべきかを決定するよう動作可能である、ことを特徴とする請求項７記載のステーション。
前記リクエストプロパティはアドレス情報を含み、前記コントローラは、前記アドレス情報から、前記リクエストが、それぞれ、前記第一のフォーマット或いは第二のフォーマットのいずれによって送信されるべきかを決定するよう動作可能である、ことを特徴とする請求項７記載のステーション。
前記ステーションは、更に、それぞれ、前記コントローラと前記トランスレータによって、前記第一と第二のモードにて送信された前記リクエストを、前記接続にルーティングするためのルータを備える、ことを特徴とする請求項７記載のステーション。
前記第一のモードは、応答を第一の応答フォーマットにて前記第一の通信速度にて転送するためにも用いられ、前記第二のモードは、前記応答を第二の応答フォーマットにて前記第二の速度にて転送するためにも用いられ、前記トランスレータは、前記応答を前記接続から前記第二の応答フォーマットにて受信し、前記応答を前記コントローラに前記第一のフォーマットにて転送するよう動作可能であり、前記コントローラは、前記応答を前記接続から前記第一のフォーマットにて受信し、前記応答から応答プロパティを前記第一の応答フォーマットにて作成するよう動作可能であり、前記プロセッサは、前記コントローラによって生成された前記応答プロパティを扱うよう動作可能である、ことを特徴とする請求項７記載のステーション。
前記第一のステーションは、更に、前記接続の所で受信される前記応答を、前記トランスレータと前記コントローラにルーティングするためのルータを備え、前記ルータは、前記応答を、前記応答が前記第一のフォーマットにて受信された場合は、前記コントローラに、前記応答が前記第二のフォーマットにて受信された場合は、前記トランスレータにルーティングするよう動作可能である、ことを特徴とする請求項１１記載のステーション。
ポーリング方式のバスシステム内で用いるためのバスに対する接続とプロセッサからリクエストプロパティを受信するための入力を備えるバスインタフェースであって、前記バスインタフェースは、前記バスインタフェースがリクエストを前記接続に向けて繰返して送るプロトコルに従って動作するように構成され、前記プロトコルは、前記リクエストを第一のリクエストフォーマットにて第一の通信速度にて転送するための第一のモードと、前記リクエストを第二のリクエストフォーマットにて第二の速度にて転送するための少なくとも第二のモードを含み、前記バスインタフェースは、前記バスに接続された他のステーションが前記第一のモードで動作するように構成される場合には前記他のステーションからの第一の指標を受信するように構成され、前記他のステーションが前記第二のモードで動作するように構成される場合には前記他のステーションからの第二の指標を受信するように構成され、前記バスインタフェースは、コントローラを備え、前記入力はリクエストに対するリクエストプロパティを前記第一のリクエストフォーマットにて受信するよう動作可能であり、前記コントローラは、前記リクエストプロパティから前記リクエストを前記第一のリクエストフォーマットにて作成するよう動作可能であり、更に、前記コントローラは、前記第一の指標が検出された場合には前記リクエストを前記第一のフォーマットにて前記接続に送信するよう動作可能であり、前記バスインタフェースは、ＵＳＢホスト用であり、前記バスインタフェースはトランスレータを備え、前記コントローラは、前記第二の指標が検出された場合には前記リクエストを前記トランスレータに転送するように動作可能であり、前記トランスレータは、前記リクエストを前記第二のフォーマットにて前記接続に送信するよう動作可能である、ことを特徴とするバスインタフェース。
前記リクエストプロパティはモード情報を含み、前記コントローラは、前記リクエストが、それぞれ、前記第一のフォーマット或いは第二のフォーマットのいずれによって送信されるべきかを前記モード情報から決定するよう動作可能である、ことを特徴とする請求項１３記載のバスインタフェース。
前記リクエストプロパティはアドレス情報を含み、前記コントローラは、前記リクエストが、それぞれ、前記第一のフォーマット或いは第二のフォーマットのいずれによって送信されるべきかを前記アドレス情報から決定するよう動作可能である、ことを特徴とする請求項１４記載のバスインタフェース。
前記バスインタフェースは、更に、それぞれ、前記コントローラと前記トランスレータによって、前記第一と第二のモードにて送信された前記リクエストを、前記接続にルーティングするためのルータを備える、ことを特徴とする請求項１３記載のバスインタフェース。
前記第一のモードは、応答を第一の応答フォーマットにて前記第一の通信速度にて転送するためにも用いられ、前記第二のモードは、前記応答を第二の応答フォーマットにて前記第二の速度にて転送するためにも用いられ、前記トランスレータは、前記応答を前記接続から前記第二の応答フォーマットにて受信し、前記応答を前記コントローラに前記第一のフォーマットにて転送するよう動作可能であり、前記コントローラは、前記接続から前記応答を前記第一のフォーマットにて受信し、前記応答から応答プロパティを前記第一の応答フォーマットにて作成するよう動作可能であり、前記バスインタフェースは、前記リクエストプロパティを前記プロセッサに送信するための出力を備える、ことを特徴とする請求項１３記載のバスインタフェース。
前記ステーションは、更に、前記接続の所で受信される前記応答を、前記トランスレータと前記コントローラにルーティングするためのルータを備え、前記ルータは、前記応答を、前記応答が前記第一のフォーマットにて受信された場合は、前記コントローラに、前記応答が前記第二のフォーマットにて受信された場合は、前記トランスレータに、ルーティングするよう動作可能である、ことを特徴とする請求項１３記載のバスインタフェース。