(57)【要約】  複数のスレーブデバイスは、制御データバスとともに、制御データバスへのスレーブデバイスのアクセスを管理している少なくとも1つのマスターデバイスに結合される。少なくとも1つのスレーブデバイスは、sI2Cプロトコル動作モードで動作し、少なくとも1つの他のスレーブデバイスは、CCIe動作モードで動作する。少なくとも、sI2Cプロトコルモードを使用するスレーブデバイスは、割込み要求のために制御データバスを使用する。CCIe通信の完全性を維持するために、sI2Cプロトコルモードを使用するスレーブデバイスは、制御データバスがCCIeモードに従って動作するときにIRQを出すのを無効にする。
2016538624.tif 000002
【特許請求の範囲】
【請求項１】
共有バスと、
前記共有バスに結合され、
前記共有バスを通じて帯域内割込み要求を出すことを含む第1のプロトコルモードに従って動作し、
前記共有バスが第2のプロトコルモードに切り替えていることを示すエントリ呼出しについて前記共有バスを監視し、
前記エントリ呼出しを検出すると、第1のスレーブデバイスが前記共有バスを通じて帯域内割込み要求を行うことを無効にする
ように構成される、前記第1のスレーブデバイスと、
前記共有バスに結合され、
割込みバスを通じて側帯割込み要求を出すことまたは前記共有バスを通じて帯域内割込み要求を出すことを含む前記第2のプロトコルモードに従って動作し、
前記共有バスで、前記第2のプロトコルモードに従って送信される前記エントリ呼出しを検出する
ように構成される、第2のスレーブデバイスとを備える、デバイス。
【請求項２】
前記共有バスに結合され、
前記第1のプロトコルモードと前記第2のプロトコルモードの両方に従って動作し、
前記共有バス上の通信を管理し、
前記共有バスが第2のプロトコルモードに切り替えていることを示す前記エントリ呼出しを前記共有バスを通じて送信する
ように構成される、マスターデバイスをさらに備え、前記エントリ呼出しが前記第1のプロトコルモードに従って送信される、請求項1に記載のデバイス。
【請求項３】
前記マスターデバイスがさらに、
前記第1のプロトコルモードと前記第2のプロトコルモードの両方に従って、スレーブデバイスからの割込み要求を検出し、
要求しているスレーブデバイスに対して前記共有バスへのアクセスを許可することによって、前記割込み要求に応答するように構成される、請求項2に記載のデバイス。
【請求項４】
前記マスターデバイスがさらに、
前記共有バスが前記第1のプロトコルモードに切り替えていることを示すイグジット呼出しを前記共有バス上で送信するように構成され、前記イグジット呼出しが、前記第2のプロトコルモードと前記第1のプロトコルモードの両方に従って送信される、請求項2に記載のデバイス。
【請求項５】
帯域内割込みのために、前記第2のプロトコルが、前記共有バスを通じて送信されるシンボル内で割込み期間を定義し、前記割込み期間の間、前記共有バスに結合された1つまたは複数のスレーブデバイスが前記共有バスの第1の線の上で割込み要求をアサートでき、一方で前記共有バスの第2の線がハートビート送信のために前記マスターデバイスによって使用される、請求項2に記載のデバイス。
【請求項６】
前記マスターデバイスおよび第2のスレーブデバイスが、前記割込み期間の間、前記共有バスの前記第1の線を内部的にマスクするように構成される、請求項5に記載のデバイス。
【請求項７】
前記マスターデバイスが、前記共有バス上で前記第2のプロトコルモードに従って動作するすべてのスレーブデバイスに割込みグループ照会呼出しを送信するように構成され、そのような割込みグループ照会呼出しが、任意のアサートしているスレーブデバイスが応答できる時間枠を提供する、請求項5に記載のデバイス。
【請求項８】
前記第2のスレーブデバイスがさらに、
前記共有バスが前記第2のプロトコルモードに従って動作するとき、前記第2のプロトコルモードに従って、前記共有バスを通じてデータまたはコマンドを受信するように構成される、請求項1に記載のデバイス。
【請求項９】
前記第1のスレーブデバイスがさらに、
前記共有バスが前記第2のプロトコルモードに従って動作する間、前記共有バスとは別の専用の割込み線またはバスを通じて、割込み要求を送信するように構成される、請求項1に記載のデバイス。
【請求項１０】
専用の線を通じて前記第1のスレーブデバイスから割込み要求を受信し、前記第2のプロトコルに従って前記専用の割込み線またはバスを通じて前記受信された割込み要求を送信するように構成される、割込みルータスレーブデバイスをさらに備える、請求項1に記載のデバイス。
【請求項１１】
前記共有バスが第1の線および第2の線を含み、前記共有バスが前記第1のプロトコルモードに従って動作するとき、前記第1の線がデータ送信のために使用され、前記第2の線が第1のクロック信号のために使用され、前記共有バスが前記第2のプロトコルモードに従って動作するとき、前記第1の線と第2の線の両方がデータ送信のために使用され、その間、第2のクロック信号が前記データ送信とともにシンボルからシンボルへの遷移に埋め込まれる、請求項1に記載のデバイス。
【請求項１２】
共有制御データバスに結合される他のデバイスに結合するための第1のバスインターフェースであって、前記データバスが、第1のプロトコルモードまたは第2のプロトコルモードのいずれかで動作するように動的に構成される、第1のバスインターフェースと、
前記他のデバイスの少なくともサブセットによって使用される専用の割込み線に結合し、前記第2のプロトコルモードにおいて前記専用の割込み線を通じて割込み要求を出すための、第2のバスインターフェースと、
前記第1のバスインターフェースと前記第2のバスインターフェースとに結合され、
複数の他のデバイスが結合される共有バスでのデータ転送を管理し、ここで、前記他のデバイスの少なくとも第1のサブセットが第1のプロトコルモードに従って動作し、前記他のデバイスの第2のサブセットが前記第1のプロトコルモードとは両立しない第2のプロトコルモードに従って動作し、
前記共有バスが前記第2のプロトコルモードに従って動作すべきであることを示すエントリ呼出しを前記共有バスを通じて送信すること、および/または、
前記共有バスが前記第1のプロトコルモードに従って動作すべきであることを示すイグジット呼出しを前記共有バスを通じて送信すること
によって、前記第1のプロトコルモードと第2のプロトコルモードとの間で前記共有バスの動作を動的に切り替える
ように構成される、処理回路とを備える、マルチモードマスターデバイス。
【請求項１３】
前記処理回路がさらに、
前記共有バスが前記第1のプロトコルモードに従って動作するとき、前記共有バスを通じてデバイスの前記第1のサブセットから割込み要求を受信するように構成される、請求項12に記載のマスターデバイス。
【請求項１４】
前記処理回路がさらに、
前記共有バスが前記第2のプロトコルモードに従って動作するとき、専用の割込みバスを通じてデバイスの前記第2のサブセットから割込み要求を受信するように構成される、請求項12に記載のマスターデバイス。
【請求項１５】
前記処理回路がさらに、
前記共有バスが前記第2のプロトコルモードに従って動作するとき、前記専用の割込みバスを通じてデバイスの前記第1のサブセットから割込み要求を受信するように構成される、請求項12に記載のマスターデバイス。
【請求項１６】
前記共有バスが前記第2のプロトコルモードに従って動作するとき、デバイスの前記第1のサブセットから割込み要求が受信されない、請求項12に記載のマスターデバイス。
【請求項１７】
前記共有バスが第1の線および第2の線を含み、前記共有バスが前記第1のプロトコルモードに従って動作するとき、前記第1の線がデータ送信のために使用され、前記第2の線が第1のクロック信号のために使用され、前記共有バスが前記第2のプロトコルモードに従って動作するとき、前記第1の線と第2の線の両方がデータ送信のために使用され、その間、第2のクロック信号が前記データ送信とともにシンボルからシンボルへの遷移に埋め込まれる、請求項12に記載のマスターデバイス。
【請求項１８】
前記第2のプロトコルが、前記共有バスを通じて送信されるシンボル内で割込み期間を定義し、前記割込み期間の間、前記他のデバイスの前記第2のサブセットが前記共有バスの第1の線の上で割込み要求をアサートでき、一方で前記共有バスの第2の線がハートビート送信のために前記マスターデバイスによって使用される、請求項12に記載のマスターデバイス。
【請求項１９】
前記処理回路がさらに、前記割込み期間の間、前記共有バスの前記第1の線を内部的にマスクするように構成される、請求項18に記載のマスターデバイス。
【請求項２０】
前記第2のプロトコルモードに従って動作しながら帯域内割込み要求に応答して、前記マスターデバイスが、前記共有バス上で前記第2のプロトコルモードに従って動作するすべてのスレーブデバイスに割込みグループ照会呼出しを送信し、そのような割込みグループ照会呼出しが、任意のアサートしているスレーブデバイスが応答できる時間枠を提供する、請求項12に記載のマスターデバイス。
【請求項２１】
複数の他のデバイスと共有される共有バスに結合するためのバスインターフェースであって、前記他のデバイスの少なくとも第1のサブセットが第1のプロトコルモードに従って動作し、前記スレーブデバイスが第2のプロトコルモードに従って動作する、バスインターフェースと、
前記バスインターフェースに結合され、
前記第1のプロトコルモードおよび前記第2のプロトコルモードに従って動作することが可能なマスターデバイスからのエントリ呼出しを前記共有バスを通じて検出し、前記エントリ呼出しが、前記共有バスが前記第2のプロトコルモードに従って動作すべきであることを示し、
前記共有バスを通じて帯域内で、または、前記マスターデバイスへの別の経路を通じて側帯で、割込み要求(IRQ)を送信する
ように構成される、処理回路とを備える、スレーブデバイス。
【請求項２２】
前記処理回路がさらに、
前記第2のプロトコルモードに従って前記共有バスを通じて通信するように構成される、請求項21に記載のスレーブデバイス。
【請求項２３】
前記処理回路がさらに、
前記マスターデバイスからのイグジット呼出しについて前記共有バスを監視し、
前記マスターデバイスからのイグジット呼出しを検出すると、前記スレーブデバイスが前記共有バスを通じて通信することを無効にするように構成される、請求項21に記載のスレーブデバイス。
【請求項２４】
前記イグジット呼出しが、前記共有バスが前記第1のプロトコルモードに従って動作すべきであることを前記スレーブデバイスに示すように機能する、請求項21に記載のスレーブデバイス。
【請求項２５】
前記共有バスが第1の線および第2の線を含み、前記共有バスが前記第1のプロトコルモードに従って動作するとき、前記第1の線がデータ送信のために使用され、前記第2の線が第1のクロック信号のために使用され、前記共有バスが前記第2のプロトコルモードに従って動作するとき、前記第1の線と第2の線の両方がデータ送信のために使用され、その間、第2のクロック信号が前記データ送信とともにシンボルからシンボルへの遷移に埋め込まれる、請求項21に記載のスレーブデバイス。
【請求項２６】
スレーブデバイスであって、
複数の他のデバイスと共有される共有バスに結合するためのバスインターフェースであって、前記スレーブデバイスが、第1のプロトコルモードに従って動作し、前記他のデバイスの少なくとも第1のサブセットが、第2のプロトコルモードに従って動作する、バスインターフェースと、
前記バスインターフェースに結合され、
前記第1のプロトコルモードおよび前記第2のプロトコルモードに従って動作することが可能なマスターデバイスからのエントリ呼出しを前記共有バスを通じて検出し、前記エントリ呼出しが、前記共有バスが前記第2のプロトコルモードに従って動作すべきであることを示し、
前記エントリ呼出しを検出すると、前記スレーブデバイスが前記共有バスを通じて帯域内割込み要求を出すことを無効にする
ように構成される、処理回路とを備える、スレーブデバイス。
【請求項２７】
前記処理回路がさらに、
前記マスターデバイスからのイグジット呼出しについて前記共有バスを監視するように構成され、前記イグジット呼出しが、前記共有バスが前記第1のプロトコルモードに従って動作すべきであることを示す、請求項26に記載のスレーブデバイス。
【請求項２８】
前記共有バスが第1の線および第2の線を含み、前記共有バスが前記第1のプロトコルモードに従って動作するとき、前記第1の線がデータ送信のために使用され、前記第2の線が第1のクロック信号のために使用され、前記共有バスが前記第2のプロトコルモードに従って動作するとき、前記第1の線と第2の線の両方がデータ送信のために使用され、その間、第2のクロック信号が前記データ送信とともにシンボルからシンボルへの遷移に埋め込まれる、請求項26に記載のスレーブデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本特許出願は、2013年10月8日に出願された「Coexistent of I2C Slave Devices and Camera Control Interface Extension Devices on a Shared Control Data Bus」という表題の仮出願第61/888,475号、2014年4月3日に出願された「Coexistent of I2C Slave Devices and Camera Control Interface Extension Devices on a Shared Control Data Bus」という表題の仮出願第61/974,910号、2014年1月14日に出願された「Camera Control Interface Extension With In-Band Interrupt」という表題の仮出願第61/927,102号の優先権を主張し、これらのすべてが本出願の譲受人に譲渡され、参照によって本明細書に明示的に組み込まれる。
【０００２】
本開示は、共有バス上でマルチモード動作を可能にすることに関し、より具体的には、異なるプロトコルを伴うデバイスが単一のバスを共有するのを可能にすることに関する。
【背景技術】
【０００３】
Inter Integrated Circuit(以後「I2C」であり、I2Cとも呼ばれる)は、マザーボード、組込みシステム、携帯電話または他の電子デバイスに低速の周辺装置を取り付けるために使用されるマルチマスターシリアルシングルエンドバスである。I2Cバスは、クロック(SCL)線と、7ビットのアドレス指定を伴うデータ(SDA)線とを含む。バスは、マスターデバイスおよびスレーブデバイスという、ノードまたはデバイスのための2つの役割を有する。マスターノード/デバイスは、クロックを生成し、スレーブノード/デバイスとの通信を開始するノード/デバイスである。スレーブノード/デバイスは、クロックを受信し、マスターによってアドレス指定されたときに応答するノードである。I2Cバスは、任意の数のマスターデバイスが存在し得ることを意味するマルチマスターバスである。加えて、マスターとスレーブの役割は、メッセージの間で(すなわち、STOPが送信された後に)変更され得る。I2Cは、メッセージの基本タイプを定義し、それらの各々はSTARTで開始し、STOPで終了する。
【０００４】
カメラの実装形態というこの文脈では、センサから画像を取り込み、そのような画像データをベースバンドプロセッサ内のメモリに送信するために、単方向送信が使用されてよく、一方、制御データは、ベースバンドプロセッサとセンサおよび他の周辺デバイスとの間で交換されてよい。一例では、ベースバンドプロセッサとイメージセンサ(および/または1つまたは複数のスレーブデバイス)との間のそのような制御データのために、カメラ制御インターフェース(CCI)プロトコルが使用され得る。一例では、CCIプロトコルは、イメージセンサとベースバンドプロセッサとの間のI2Cシリアルバス上で実装され得る。
【０００５】
技術が進化するにつれて、I2Cバス上での「ホットプラグ」機能が必要になっている。「ホットプラグ」とは、スレーブデバイスのようなデバイスがすでにアクティブなバスに差し込まれ得る(すなわち、バスを停止することなく)ことを意味する。このホットプラグ機能は、サブセットI2C(すなわち、sI2C)と呼ばれるものによって達成される。sI2Cは、割込み要求(IRQ)を実行するために、スレーブデバイスのための手段として制御データバスを(SCLとSDAを一緒に)利用する。加えて、CCIプロトコルの速度を上げることを望むので、CCIプロトコルよりも速度を向上させるCCI拡張(CCIe)プロトコルが本明細書で説明される。しかしながら、SDAを使用してスレーブデバイスにIRQを実行させることは、専用のIRQ線を提供するCCIeプロトコルとは両立しない。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
したがって、CCIプロトコルよりも速度を向上させると同時に、sI2CプロトコルスレーブデバイスがCCIeデバイスと共存することを可能にしCCIeバスへとホットプラグ可能にするための方法が必要とされている。
【課題を解決するための手段】
【０００７】
共有バス、第1のスレーブデバイス、第2のスレーブデバイス、および/またはマスターデバイスを備えるデバイスが提供される。第1のスレーブデバイスは、共有バスに結合されてよく、(a)共有バスを通じて帯域内割込み要求を出すことを含む第1のプロトコルモードに従って動作し、(b)共有バスが第2のプロトコルモードに切り替えていることを示すエントリ呼出しについて共有バスを監視し、かつ/または(c)エントリ呼出しを検出すると、第1のスレーブデバイスが共有バスを通じて帯域内割込み要求を行うことを無効にするように構成される。
【０００８】
第2のスレーブデバイスは、共有バスに結合されてよく、(a)割込みバスを通じて側帯割込み要求を出すこと、または共有バスを通じて帯域内割込み要求を出すことを含む第2のプロトコルモードに従って動作し、かつ/または(b)共有バス上でエントリ呼出しを検出するように構成され、エントリ呼出しは第2のプロトコルモードに従って送信される。
【０００９】
マスターデバイスは、共有バスに結合されてよく、(a)第1のプロトコルモードと第2のプロトコルモードの両方に従って動作し、(b)共有バス上の通信を管理し、(c)共有バスが第2のプロトコルモードに切り替えていることを示すエントリ呼出しを共有バスを通じて送信し、ここでエントリ呼出しは第1のプロトコルモードに従って送信され、(d)第1のプロトコルモードと第2のプロトコルモードの両方に従ってスレーブデバイスからの割込み要求を検出し、かつ/または(e)要求しているスレーブデバイスに共有バスへのアクセスを認めることによって、割込み要求に応答するように構成されてよい。
【００１０】
マスターデバイスはさらに、共有バスが第1のプロトコルモードに切り替えていることを示すイグジット呼出しを共有バス上で送信するように構成されてよく、イグジット呼出しは、第2のプロトコルモードと第1のプロトコルモードの両方に従って送信される。
【００１１】
帯域内割込みのために、第2のプロトコルは、共有バスを通じて送信されるシンボル内で割込み期間を定義し、この割込み期間の間、共有バスに結合された1つまたは複数のスレーブデバイスが共有バスの第1の線の上で割込み要求をアサートでき、一方で共有バスの第2の線がハートビート送信のためにマスターデバイスによって使用される。1つの実装形態では、マスターデバイスおよび第2のスレーブデバイスは、割込み期間の間、共有バスの第1の線を内部的にマスクするように構成され得る。
【００１２】
マスターデバイスは、共有バス上で第2のプロトコルモードに従って動作するすべてのスレーブデバイスに割込みグループ照会呼出しを送信するように構成されてよく、そのような割込みグループ照会呼出しは、任意のアサートしているスレーブデバイスが応答できる時間枠を提供する。
【００１３】
第2のスレーブデバイスはさらに、共有バスが第2のプロトコルモードに従って動作するとき、第2のプロトコルモードに従って、共有バスを通じてデータまたはコマンドを受信するように構成され得る。
【００１４】
第1のスレーブデバイスはさらに、共有バスが第2のプロトコルモードに従って動作する間、共有バスとは別の専用の割込み線またはバスを通じて、割込み要求を送信するように構成され得る。
【００１５】
デバイスはまた、専用の線を通じて第1のスレーブデバイスから割込み要求を受信し、第2のプロトコルに従って専用の割込み線またはバスを通じて受信された割込み要求を送信するように構成される、割込みルータスレーブデバイスを含み得る。
【００１６】
一例では、共有バスは第1の線および第2の線を含み得る。共有バスが第1のプロトコルモードに従って動作するとき、第1の線はデータ送信のために使用され、第2の線は第1のクロック信号のために使用される。共有バスが第2のプロトコルモードに従って動作するとき、第1の線と第2の線の両方がデータ送信のために使用され、その間、第2のクロック信号はデータ送信とともにシンボルからシンボルへの遷移に埋め込まれる。
【００１７】
マルチモードマスターデバイスは、第1のバスインターフェースと、第2のバスインターフェースと、処理回路とを含み得る。第1のバスインターフェースは、共有制御データバスに結合される他のデバイスに結合するように機能することができ、データバスは、第1のプロトコルモードまたは第2のプロトコルモードのいずれかで動作するように動的に構成される。第2のバスインターフェースは、他のデバイスの少なくともサブセットによって使用される専用の割込み線に結合し、第2のプロトコルモードにおいて専用の割込み線を通じて割込み要求を出すように機能し得る。処理回路は、(a)複数の他のデバイスが結合される共有バスを通じたデータ転送を管理し、ここで他のデバイスの少なくとも第1のサブセットは第1のプロトコルモードに従って動作し、他のデバイスの第2のサブセットは第1のプロトコルモードと両立しない第2のプロトコルモードに従って動作し、(b)(1)共有バスが第2のプロトコルモードに従って動作すべきであることを示すエントリ呼出しを共有バスを通じて送信し、かつ/または(2)共有バスが第1のプロトコルモードに従って動作すべきであることを示すイグジット呼出しを共有バスを通じて送信することによって、第1のプロトコルモードと第2のプロトコルモードとの間で共有バスの動作を動的に切り替えるように構成され得る。
【００１８】
マスターデバイスはさらに、(a)共有バスが第1のプロトコルモードに従って動作するとき、共有バスを通じてデバイスの第1のサブセットから割込み要求を受信し、(b)共有バスが第2のプロトコルモードに従って動作するとき、専用の割込みバスを通じてデバイスの第2のサブセットから割込み要求を受信し、かつ/または(c)共有バスが第2のプロトコルモードに従って動作するとき、専用の割込みバスを通じてデバイスの第1のサブセットから割込み要求を受信するように構成され得る。1つの実装形態では、共有バスが第2のプロトコルモードに従って動作するとき、デバイスの第1のサブセットから割込み要求は受信されない。
【００１９】
共有バスは、第1の線と第2の線とを含む。共有バスが第1のプロトコルモードに従って動作するとき、第1の線はデータ送信のために使用され、第2の線は第1のクロック信号のために使用される。共有バスが第2のプロトコルモードに従って動作するとき、第1の線と第2の線の両方がデータ送信のために使用され、その間、第2のクロック信号はデータ送信とともにシンボルからシンボルへの遷移に埋め込まれる。
【００２０】
第2のプロトコルは、共有バスを通じて送信されるシンボル内で割込み期間を定義することができ、この割込み期間の間、他のデバイスの第2のサブセットが共有バスの第1の線の上で割込み要求をアサートでき、一方で共有バスの第2の線がハートビート送信のためにマスターデバイスによって使用される。
【００２１】
マスターデバイスはまた、割込み期間の間、共有バスの第1の線を内部的にマスクするように構成され得る。
【００２２】
1つの実装形態では、第2のプロトコルモードに従って動作しながら帯域内割込み要求に応答して、マスターデバイスは、共有バス上で第2のプロトコルモードに従って動作するすべてのスレーブデバイスに割込みグループ照会呼出しを送信することができ、そのような割込みグループ照会呼出しは、任意のアサートしているスレーブデバイスが応答できる時間枠を提供する。
【００２３】
スレーブデバイスは、バスインターフェースと処理回路とを備え得る。バスインターフェースは、複数の他のデバイスと共有される共有バスに結合するように機能することができ、他のデバイスの少なくとも第1のサブセットは第1のプロトコルモードに従って動作し、スレーブデバイスは第2のプロトコルモードに従って動作する。
【００２４】
処理回路は、(a)第1のプロトコルモードおよび第2のプロトコルモードに従って動作することが可能なマスターデバイスからの共有バスを通じたエントリ呼出しを検出し、エントリ呼出しは共有バスが第2のプロトコルモードに従って動作すべきであることを示し、(b)共有バスを通じて帯域内で、またはマスターデバイスへの別個の経路を通じて側帯で、割込み要求(IRQ)を送信し、(c)第2のプロトコルモードに従って共有バスを通じて通信し、(d)マスターデバイスからのイグジット呼出しについて共有バスを監視し、かつ/または(e)マスターデバイスからのイグジット呼出しを検出すると、スレーブデバイスが共有バスを通じて通信するのを無効にするように構成され得る。イグジット呼出しは、共有バスが第1のプロトコルモードに従って動作すべきであることをスレーブデバイスに示すように機能し得る。
【００２５】
共有バスは、第1の線と第2の線とを含み得る。共有バスが第1のプロトコルモードに従って動作するとき、第1の線はデータ送信のために使用され、第2の線は第1のクロック信号のために使用される。共有バスが第2のプロトコルモードに従って動作するとき、第1の線と第2の線の両方がデータ送信のために使用され、その間、第2のクロック信号はデータ送信とともにシンボルからシンボルへの遷移に埋め込まれる。
【００２６】
スレーブデバイスは、バスインターフェースと処理回路とを含み得る。バスインターフェースは、複数の他のデバイスと共有される共有バスに結合するように機能することができ、スレーブデバイスは、第1のプロトコルモードに従って動作し、他のデバイスの少なくとも第1のサブセットは、第2のプロトコルモードに従って動作する。処理回路は、バスインターフェースに結合するように機能し、(a)第1のプロトコルモードおよび第2のプロトコルモードに従って動作することが可能なマスターデバイスからの共有バスを通じたエントリ呼出しを検出し、ここでエントリ呼出しは共有バスが第2のプロトコルモードに従って動作すべきであることを示し、かつ/または(b)エントリ呼出しを検出すると、スレーブデバイスが共有バスを通じて帯域内割込み要求を行うことを無効にするように構成され得る。
【００２７】
処理回路はさらに、マスターデバイスからのイグジット呼出しについて共有バスを監視するように構成され、イグジット呼出しは、共有バスが第1のプロトコルモードに従って動作すべきであることを示す。共有バスは第1の線および第2の線を含み、共有バスが第1のプロトコルモードに従って動作するとき、第1の線はデータ送信のために使用され、第2の線は第1のクロック信号のために使用され、共有バスが第2のプロトコルモードに従って動作するとき、第1の線と第2の線の両方がデータ送信のために使用され、その間、第2のクロック信号はデータ送信とともにシンボルからシンボルへの遷移に埋め込まれる。
【００２８】
割込み要求ルータスレーブデバイスは、第1のバスインターフェースと、第2のバスインターフェースと、第3のバスインターフェースと、処理回路とを含み得る。第1のバスインターフェースは、共有制御データバスに結合するように機能することができ、データバスは、第1のプロトコルモードまたは第2のプロトコルモードのいずれかで動作するように動的に構成される。第2のバスインターフェースは、共有バスに結合される他のスレーブデバイスの少なくとも1つのサブセットに結合するように機能することができ、他のスレーブデバイスのサブセットは、共有制御データバスを通じた帯域内割込み要求を含む第1のプロトコルモードに従って動作する。第3のバスインターフェースは、共有バスを管理するマスターデバイスに割込み要求を出すために、第2のプロトコルモードにおいて使用される専用の割込み線に結合するように機能し得る。処理回路は、(a)スレーブデバイスの第1のサブセット内のあるスレーブデバイスから第2のバスインターフェースを通じて割込み要求を受信し、かつ/または(b)第3のバスインターフェースを介してマスターデバイスに受信された割込み要求をルーティングするように構成され得る。
【００２９】
同様の参照文字が全体を通じて対応するものを特定する図面と併せて読まれると、以下に記載される詳細な説明から、種々の特徴、性質、および利点が明らかになり得る。
【図面の簡単な説明】
【００３０】
【図１】ベースバンドプロセッサおよびイメージセンサを有し、画像データバスおよびマルチモード制御データバスを実装するデバイスを示すブロック図である。
【図２】共有I2Cバス(たとえば、制御データバス)上でのI2Cモード(たとえば、レガシーCCIまたは第1のモード)およびCCIeモード(たとえば、第2のモード)の例示的な共存を示すブロック図である。
【図３】1つまたは複数のsI2Cスレーブデバイス、マルチモードI2CおよびCCIeマスターデバイス、1つまたは複数のI2Cスレーブデバイス、および1つまたは複数のCCIeスレーブデバイスを含む共通のI2Cバス上でのI2Cモード(すなわち、レガシーCCI)とCCIeモードの共存を示すブロック図である。
【図４】データシンボル内にクロックをどのように埋め込み、これによってデータ送信のために両方のI2C配線(すなわち、SDA線とSCL線)を使用することを可能にできるかを示す図である。
【図５】トランスコーディングされたシンボル内にクロック信号を埋め込むために、送信機においてデータビットをトランスコーディングされたシンボルへとトランスコーディングするための例示的な方法を示すブロック図である。
【図６】遷移番号と順次的シンボルとの間の例示的な変換を示す図である。
【図７】遷移番号と順次的シンボルとの間の例示的な変換をさらに示す図である。
【図８】I2Cの1バイトデータ書込み動作のタイミング図である。
【図９】sI2Cプロトコルに従った、最上位ビット(MSB)が1であるsI2Cの1バイトデータ書込み動作のタイミング図である。
【図１０】CCIeプロトコルの一例を示す図である。
【図１１】共通バスを通じてsI2C互換スレーブデバイスによって送信される例示的な帯域内割込み信号(IRQ)の図である。
【図１２】混合プロトコルモードの環境において割込み信号(IRQ)を出すためのsI2Cスレーブデバイスの追加の方法を示す図である(たとえば、共有バスは別個の通信プロトコルに従って動作することができ、または別個の通信プロトコルを動的に切り替えることができる)。
【図１３】送信機および受信機回路と処理/論理回路とを備える例示的なスレーブデバイスを示す図である。
【図１４】複数の通信モードを切り替える共有データバス上でシングルモードスレーブデバイスが共存することを許可するための方法を示す図である。
【図１５】共有制御データバスおよび共有割込みバス/要求に結合される、マスターデバイスと複数のスレーブデバイスとを有するシステムを示すブロック図である。
【図１６】割込みを出す目的で図15の複数のスレーブデバイスがどのように論理的にグループ化され得るかを示すブロック図である。
【図１７】IRQ信号がIRQ線またはバスの上でどのように調停され得るかの第1の例を示す図である。
【図１８】IRQ信号がIRQ線またはバスの上でどのように調停され得るかの第2の例を示す図である。
【図１９】一例では実現可能であり得る最短のIRQ信号長を示す図である。
【図２０】割込みバスが帯域内割込みを優先して除去された例示的なシステムを示すブロック図である。
【図２１】I2Cの1バイトデータ書込み動作の例示的なタイミング図である。
【図２２】SDA線およびSCL線を通じた送信のためにデータビットが12個のシンボルにトランスコーディングされている例示的なCCIe送信を示す図である。
【図２３】スレーブデバイスがIRQをアサートするために制御データバスを駆動することを許可されるべきではないが、マスターデバイスが競合を避けるために制御データバスを駆動していることを示す図である。
【図２４】図23の競合の可能性を避けるための解決法を示す図である。
【図２５】スレーブデバイスがSDA線上で帯域内IRQを送信するときに、それが誤ったクロックの検出を引き起こし得ることを示す図である。
【図２６】図25に示される余剰の受信機クロックパルスと同期の喪失とを避けるための解決法を示す図である。
【図２７】I2CモードとCCIeモードの両方をサポートしながら帯域内IRQ期間を実装するための1つの手法を示す図である。
【図２８】ビット19(すなわち、ビット0を第1のビットとしてビットのカウントを開始するときの20番目のビット)を示す図である。
【図２９】ビット19が数2221_2201_20023から2222_2222_22223にわたり得るとともに、その範囲の数が図29の左側の6個の区分へと区分され得ることを示す図である。
【図３０】ハートビートを定義するために使用され得るビット19の数空間内の範囲を示す図である。
【図３１】ハートビートクロックが共有制御データバスのSDA線およびSCL線を通じてどのように送信され得るかの一例を示す図である。
【図３２】ハートビートクロックがSDA線およびSCL線を通じて送信され得る別の例を示す図である。
【図３３】遷移番号からシンボル番号への変換の一例を示す図である。
【図３４】図33のシンボル番号から遷移番号への変換をさらに詳述する図である。
【図３５】SDA線がマスクされる帯域内IRQ期間の間の条件を示す図である。
【図３６】図32および図35のSDAマスクの副作用を示す図である。
【図３７】3進の数空間内での数空間0x81BD6〜0x81BF0(すなわち、27個のアドレス)を帯域内IRQのために使用されるハートビートが占有することを示す図である。
【図３８】CCIeモード送信のために図37において使用される3進数のビット19がどのようにマッピングされ得るかの例を示す図である。
【図３９】CCIeモードにおいて制御データバスを通じて帯域内IRQを実装するための代替的な技法を示す図である。
【図４０】SDA線がマスクされる図39の帯域内IRQ期間の間の条件を示す図である。
【図４１】図39および図40のSDAマスクの副作用を示す図である。
【図４２】3進の数空間内での数空間0x81BBB〜0x81BD5(すなわち、27個のアドレス)を帯域内IRQのために使用されるハートビートが占有することを示す図である。
【図４３】マスターデバイスがアクティブモードであり電力節約モードにあるときにハートビートがどのように送信され得るかを示す図である。
【図４４】同期ワードとハートビートの組合せを示す図である。
【図４５】CCIeプロトコルのビット19内での同期とハートビートのマッピングを示す図である。
【図４６】例示的なCCIeプロトコル内での割込みグループ照会の一般的な呼出しを示す図である。
【図４７】グループ照会呼出しに対する応答を示す図である。この例では、ハートビートをSCL線に転送してSDAマスクを使用することによって、1つまたは複数の応答期間(すなわち、照会ワード)がSDA線上で定義され得る。
【図４８】IRQグループ照会の一般的な呼出しの長さ(すなわち、ワードカウント)を柔軟にするためにIRQグループ照会の一般的な呼出しの終わりを示すために使用され得る例示的な「終止ワード」を示す図である。
【図４９】DDRクロック読取りの一般的な呼出しがどのように実施され得るかの一例を示す図である。
【図５０】グローバルクロック読取りワードの例示的なタイミング図である。
【図５１】デバイス内の共有バス上でのI2C適合デバイスとCCIe適合デバイスの共存を示し、すべてのマスター/スレーブデバイスが共有バス上での帯域内割込みを使用する図である。
【図５２】共有バス上での図51のマスター/スレーブデバイスの共存を示す図である。
【図５３】共有バス上でのCCIe適合スレーブデバイスとの共存を支援する、I2C適合スレーブデバイスによって動作可能な方法であり、すべてのデバイスが共有バスを通じた帯域内割込みを使用できる方法を示す図である。
【図５４】共有バス上でのI2C適合スレーブデバイスとの共存を支援する、CCIe適合スレーブデバイスによって動作可能な方法であり、すべてのデバイスが共有バスを通じた帯域内割込みを使用できる方法を示す図である。
【図５５】例示的なマルチモードマスターデバイスを示す図である。
【図５６】例示的なスレーブデバイスを示す図である。
【図５７】例示的な割込み要求ルータスレーブデバイスを示す図である。
【発明を実施するための形態】
【００３１】
以下の説明では、実施形態を完全な理解をもたらすために、具体的な詳細が与えられる。しかしながら、実施形態はこれらの具体的な詳細を伴わずに実践され得ることを当業者は理解されよう。たとえば、回路は、不必要な詳細で実施形態を不明瞭にしないために、ブロック図で示されることがある。他の例では、よく知られている回路、構造、および技法は、実施形態を不明瞭にしないために、詳細に示されない場合がある。
【００３２】
概説
第1の特徴は、複数の動作モードに従って共通/共有バス(たとえば、制御データバス)上で同時にデバイスを動作させるための方法を提供する。複数のスレーブデバイスは、制御データバスとともに、制御データバスへのアクセスを制御する少なくとも1つのマスターデバイスに結合され得る。少なくとも第1のスレーブデバイスは、サブセットI2C(sI2C)プロトコル動作モードで動作することができ、少なくとも第2のスレーブデバイスは、カメラ制御インターフェース拡張(CCIe)動作モードで動作することができる。sI2Cモード(たとえば、第1のモード)およびCCIeモード(たとえば、第2のモード)の使用は、例示的なモードおよび(たとえば、異なる通信規格に対する)他の動作モードであることに留意されたい。sI2Cプロトコルモード(たとえば、第1のモード)で動作する第1のスレーブデバイス(たとえば、sI2C適合スレーブデバイス)は、割込み要求またはIRQ(たとえば、帯域内IRQと呼ばれる)のために制御データバスを使用することができる。一例では、そのようなIRQは、第1のスレーブデバイスが共有バスを使用することを望むことをマスターデバイスに示すために、第1のスレーブデバイスによって出され得る。対照的に、第2のスレーブデバイス(CCIeスレーブデバイス)は、CCIeモード(たとえば、第2のモード)で動作して、IRQのために専用のIRQ線を使用する。共有バス上でのCCIe通信の完全性を維持するために、sI2Cプロトコルモードで動作する第1のスレーブデバイスは、共有制御データバス上でCCIe通信が開始すると、IRQ能力を無効にする(たとえば、帯域内IRQを出さない)。すなわち、共有制御データバスはCCIe通信のために使用されるが、sI2Cプロトコルモードで動作する第1のスレーブデバイスは、共有バスを通じて割込みを送信することを防がれる。
【００３３】
sI2Cプロトコルモードで動作する第1のスレーブデバイスはCCIe通信を理解しないが、CCIeモードへのエントリは、CCIeモードへのエントリを告知するI2Cプロトコルメッセージを共有制御データバスを通じて送信することによって、CCIeモードで動作するマスターデバイスによって開始される。sI2Cプロトコルモードで動作する第1のスレーブデバイスは、このCCIeエントリ告知を理解し、共有制御データバスを使用するのを止めることができる。加えて、共有制御データバスを通じてCCIeエントリ告知(すなわち、sI2Cプロトコルモードで動作する第1のスレーブデバイスが理解する、I2Cプロトコル中のメッセージ)を送信した後で、CCIeモードで動作するマスターデバイスは、CCIe通信のために共有バスを使用することからのイグジットまたはストップを告知する、イグジット/ストップメッセージを(たとえば、CCIeプロトコルおよびI2Cプロトコルにおいて)送信する。共有バスがCCIeモード通信のために使用されている間、sI2Cプロトコルモードで動作する第1のスレーブデバイスは、共有バスを通じてIRQを送るためのそれ自体の能力を無効にする。
【００３４】
sI2Cプロトコルモードで動作する第1のスレーブデバイス(たとえば、「sI2Cスレーブデバイス」)の観点からは、第1のスレーブデバイスは、CCIeモードへのエントリを告知する理解可能なI2Cプロトコルメッセージを受信し、それ自体が共有制御データバスを通じて帯域内IRQを送信することを直ちに無効にする。第1のスレーブデバイスは次いで、第1のスレーブデバイス(sI2Cプロトコルモードで動作する)が理解しない、かつ/または無視する、1つまたは複数のCCIe通信を受信し得る。その後、第1のスレーブデバイスは、共有バス上でのCCIeモードのイグジットまたは終了を告知する理解可能なI2Cプロトコルメッセージを受信し、第1のスレーブデバイスは、それ自体が帯域内IRQを送信することを有効にする。sI2Cスレーブデバイスによって帯域内IRQを送信することをこのようにそれ自体で無効および有効にすることは、CCIeモードのスレーブデバイスが同じ共有制御データバス上でCCIeプロトコルにおいて通信している間、帯域内IRQを実行するsI2Cスレーブデバイスからの共有制御データバス上でのデータの競合を防ぐ。
【００３５】
第2の機能は、CCIe対応バス(すなわち、共有制御データバス)へのsI2Cスレーブデバイスのホットプラグ(ホットスワップとも呼ばれる)を可能にすることを実現する。より一般的には、この第2の機能は、第1のプロトコルモード(たとえば、sI2C適合通信プロトコル)に従って動作するスレーブデバイスが、異なる第2のプロトコルモード(たとえば、CCIeモード)に従って動作するバスへと動的に差し込まれること、または追加されることを可能にする。sI2CスレーブデバイスがCCIeデバイスとともにCCIe対応の共有制御データバス上で共存することを可能にすることによって、ホットプラグ機能は、CCIe対応の共有バス上で動作するデバイスに対して実装される。
【００３６】
第3の機能は、割込み(IRQ)を出すための、sI2Cスレーブデバイスのためのさらなる方法を追加することを実現する。sI2Cスレーブデバイスが共有バス(たとえば、制御データバス)を使用して帯域内割込み(IRQ)を出すことに加えて、sI2CスレーブデバイスをIRQルータのCCIe適合スレーブデバイスに結合するために、別の線(たとえば、sI2Cデバイスのための専用のIRQバスまたは線)が利用され得る。IRQルータのCCIe適合スレーブデバイスは、sI2Cプロトコル割込み(IRQ)を受信し、sI2CプロトコルIRQをCCIeのIRQバスまたは線にルーティングする。一例では、sI2Cスレーブデバイスは、CCIeモードへのエントリについて共有バスを監視することができる。しかしながら、sI2CスレーブデバイスがIRQを実行する能力を無効にする代わりに、内部の論理が、共有バスから、IRQルータのCCIe適合スレーブにsI2Cスレーブデバイスを結合する線へと、IRQの出力を切り替える。その後、共有バスがCCIeモードに従って動作している間にイグジット信号を感知すると、sI2Cスレーブデバイスは、帯域内IRQを出すために共有バスを再び使用し始めることができる。したがって、sI2CスレーブデバイスとCCIeモードのスレーブデバイスの両方が、データ競合を伴わずにCCIe対応バス上で共存できる。IRQルータのCCIe適合スレーブデバイスは、sI2Cスレーブデバイスから受信されたすべてのIRQを、CCIeモードで動作する専用のIRQ線またはバスにルーティングする。
【００３７】
第4の機能は、sI2C適合デバイスとCCIeデバイスが同じ共有バス上で共存することを実現しながら、両方のタイプのデバイスが帯域内割込み要求(IRQ)を使用する。
【００３８】
共有バス上での異なる通信プロトコルを使用するデバイスの例示的な共存
図1は、ベースバンドプロセッサ104およびイメージセンサ106を有し、画像データバス116およびマルチモード制御データバス108を実装するデバイス102を示すブロック図である。図1はカメラデバイス内のマルチモード制御データバス108を示すが、この制御データバス108が様々な異なるデバイスおよび/またはシステム内に実装され得ることは明らかであろう。画像データは、画像データバス116(たとえば、高速差動DPHYリンク)を通じて、イメージセンサ106からベースバンドプロセッサ104に送信され得る。一例では、制御データバス108は、2つの配線、クロック線(SCL)およびシリアルデータ線(SDA)を備える、I2Cバスであり得る。クロック線SCLは、I2Cバス(制御データバス108)上でのすべてのデータ転送を同期するために使用され得る。データ線SDAおよびクロック線SCLは、I2Cバス(制御データバス108)上のすべてのデバイス112、114、118、122、および124に結合される。デバイス112、114、および118のいくつかまたはすべては、1線の割込み(IRQ)バス120とも結合され得る。スレーブデバイス114、118、122、および124は、異なるプロトコルモードを有し得る(たとえば、異なるプロトコルを使用して動作し得る)。たとえば、第1のスレーブデバイス122はsI2C適合スレーブデバイスであってよく(たとえば、sI2Cプロトコルに従って通信し)、第2のスレーブデバイス124はCCIe適合スレーブデバイスであってよく(たとえば、CCIeプロトコルに従って通信し)、第3のスレーブデバイス118はマルチモード動作が可能であってよい(たとえば、I2C/sI2CおよびCCIeプロトコルに従って通信する)。一例では、制御データは、共有制御データバス108を介して、ベースバンドプロセッサ104とイメージセンサ106との間、ならびにスレーブデバイス118、122、124の間で交換され得る。I2C通信/シグナリングの基準クロック(SCL)速度は最大で100KHzである。I2C高速モードにおける基準クロックSCL速度は最大で400KHzであり、I2C高速モードプラス(FM+)では最大で1MHzである。I2Cバスを通じたこれらの動作モードは、カメラの適用例に使用されるとき、カメラ制御インターフェース(CCI)モードと呼ばれ得る。
【００３９】
一態様によれば、カメラ動作をサポートするために、改善された(すなわち、1MHzを上回る)動作モードがマルチモード制御データバス108上で実装され得る。I2Cバスを通じたこの改善された動作モードは、カメラの適用例のために使用されるとき、カメラ制御インターフェース拡張(CCIe)モードと呼ばれ得る。この例では、ベースバンドプロセッサ104はマスターデバイス/ノード112を含み、イメージセンサ106はスレーブデバイス/ノード114を含み、マスターデバイス112とスレーブデバイス114の両方が、制御データバス108に結合された他のレガシーI2Cデバイスの適切な動作に影響を与えることなく、制御データバス108を通じてカメラ制御インターフェース拡張(CCIe)モードに従って動作することができる。一態様によれば、制御データバス108上でのこの改善された動作モードは、CCIeデバイスと、任意のレガシーI2Cスレーブデバイスとの間に任意のブリッジデバイスを伴わずに実装され得る。一態様によれば、レガシーI2Cデバイスは、第1のクロック、第1のバス速度および/または第1の信号プロトコルを有する第1のモードで動作することができ、一方、CCIe対応デバイスは、第2のクロック、第2のバス速度および/または第2のプロトコルを有する第2のモードで動作することができる。第1のクロック、第1のバス速度、および/または第1の信号プロトコルは、第2のクロック、第2のバス速度、および/または第2のプロトコルとは異なり得る。たとえば、第2のクロックおよび/または第2のバス速度は、それぞれ、第1のクロックおよび/または第1のバス速度よりも速く、すなわち大きい速度を有し得る。
【００４０】
一態様によれば、すべてのスレーブデバイス118および124がCCIe対応デバイスであるとき、第1の動作モードと第2の動作モードとを切り替える必要はない。すなわち、制御データバス108上でのすべてのシグナリングおよび/または通信は、第2のモードに従って(たとえば、第2のクロック、第2のバス速度および/または第2のプロトコルにおいて)実行され得る。たとえば、第2のモードは、第1のモードの第1の速度より高いビットレートを提供し得るので、第1のモードと第2のモードとの間を行き来する必要はない。実際には、第1のモードに適合するレガシーデバイスに対応する必要はないので、第2のモードより高い/速いビットレートを提供する第3の動作モードが実装され得る。
【００４１】
別の態様によれば、少なくとも第1のスレーブデバイス122は、第1のスレーブデバイス122がホットプラグ可能にすることと両立するsI2Cである。sI2Cスレーブデバイス122は、制御データバス108上の任意の他のデバイスが制御データバス108を通じて(I2Cプロトコルフォーマットの)CCIeエントリメッセージを送信するときは常に、制御データバス108を通じて帯域内IRQを送信するためのそれ自体の能力を無効にする。IRQが無効にされたスレーブデバイス122は、完全に無効にされてよく、または部分的に無効にされてよい。完全に無効にされるとき、sI2Cスレーブデバイス122は、制御データバス108を通じて帯域内IRQを送信しない。いくつかの実装形態では、部分的に無効にされるとき、sI2Cスレーブデバイス122は、制御データバス108を通じて帯域内IRQを送信するのではなく、sI2Cスレーブデバイス122からの側帯IRQを専用のIRQバスまたは線にルーティングするように機能し得るIRQルータのCCIeスレーブデバイスへの接続を通じて、側帯IRQを送信することができる。
【００４２】
図2は、共有I2Cバス206(たとえば、制御データバス)上でのI2Cモード202(たとえば、レガシーCCIまたは第1のモード)およびCCIeモード204(たとえば、第2のモード)の例示的な共存を示すブロック図である。バス206へのアクセスを管理するマスターデバイス208は、I2Cモード(たとえば、第1のモード)およびCCIeモード(たとえば、第2のモード)に従って動作することが可能であり得る。
【００４３】
I2Cモード202では、CCIe対応マスターデバイス208は、完全なCCIまたはI2C Fm+の能力をサポートすることができるが、CCIe対応スレーブデバイス210は、完全なI2Cの能力をサポートしないことがある。I2Cモードでは、CCIeマスター208は、1Mbpsのリンクレートという最大値でCCIまたはI2C Fm+プロトコルを使用して、バス206上でI2Cスレーブ210a、210b、210c、210dと通信する。
【００４４】
CCI規格動作のように、CCIe動作204は、単一マスターデバイス動作しかサポートしない(たとえば、複数のマスターはサポートされない)。CCIeモード204では(たとえば、バス206がCCIeプロトコル通信のために使用されている)、CCIeマスターデバイス208は、たとえば6.4Mbpsまたは16.7Mbpsのいずれかにおいて、制御データバス206上でCCIe対応スレーブデバイス212aおよび212bのみと通信する。
【００４５】
始動時において、デフォルトで、バス206はレガシーI2Cモード202で動作し得る(たとえば、バス206はCCIeプロトコル通信のために使用されている)。CCIeマスター208がCCIeスレーブ212aおよび/または212bにアクセスすることを望むとき、CCIeマスター208はI2Cの一般的な呼出しによってI2Cモード202からCCIeモード204に切り替える。
【００４６】
CCIeモード204では、CCIeマスター208がI2Cスレーブ210a、210b、210c、および/または210dにアクセスすることを望むとき、CCIeマスター208は、CCIe「イグジット」プロトコルとI2Cの一般的な呼出しの組合せによって、CCIeモード204から再びI2Cモード202に切り替える。
【００４７】
図3は、1つまたは複数のsI2Cスレーブデバイス308aおよび308b、マルチモードI2CおよびCCIeマスターデバイス304、1つまたは複数のI2Cスレーブデバイス312aおよび312b、ならびに1つまたは複数のCCIeスレーブデバイス310aおよび310bを含む共通のI2Cバス306上でのI2Cモード302(すなわち、レガシーCCI)とCCIeモード304の共存を示すブロック図である。図2に関して説明される様々な特徴および動作は、図3に関して適用可能であることがあり、簡潔にするために繰り返されない。一態様では、sI2Cスレーブデバイス308aおよび308bは、I2Cプロトコルモード動作だけが可能である(ここで、すべてではないとしても大半のI2C通信がsI2Cスレーブデバイス308aおよび308bによって理解可能であり、あるとしてもわずかなCCIe通信しかsI2Cスレーブデバイス308aおよび308bによって理解可能ではない)。すなわち、CCIeスレーブデバイス310aおよび310bがCCIeモードで動作する間、sI2Cスレーブデバイス308aおよび308bはsI2Cモードで動作する。sI2Cスレーブデバイス308aおよび308bは、任意のデバイスが制御データバス306を通じて(I2Cプロトコルフォーマットの)CCIeエントリメッセージを送信するときは常に、制御データバス306を通じてIRQを送信するためのそれ自体の能力を無効にする。
【００４８】
共有バス上でのビットレートを向上させるための例示的な通信プロトコルおよび符号化の方法
図4は、データシンボル内にクロックをどのように埋め込み、これによってデータ送信のために両方のI2C配線(すなわち、SDA線とSCL線)を使用することを可能にできるかを示す。一例では、クロックのこの埋め込みは、遷移クロックトランスコーディングによって達成され得る。たとえば、物理リンク(配線)を通じて送信されるべきデータ404は、送信されるシンボル406の各シンボル周期おいてデータ404が状態を変更するように、トランスコーディングされる。その結果、元のクロック402は、各シンボル周期におけるシンボル状態の変更に埋め込まれる。受信機は、(送信されたシンボル406中の)各シンボルにおける状態遷移からクロック情報408を復元し、次いで、送信されたシンボル406のトランスコーディングを逆行させて元のデータ410を得る。このことは、I2Cバスの両方の配線(図1の制御データバス108、SDA線およびSCL線)がデータ情報を送信するために使用されることを可能にする。加えて、クロック信号とデータ信号との間にセットアップ時間および保持時間を有する必要がもはやないので、シンボルレートは2倍にされ得る。
【００４９】
図5は、トランスコーディングされたシンボル内にクロック信号を埋め込むために、送信機においてデータビットをトランスコーディングされたシンボルへとトランスコーディングするための例示的な方法を示すブロック図である。送信機502において、一連のデータビット504が3進(base 3)の数(すなわち、「遷移番号」)に変換され、次いで、3進数が(順次的)シンボルに変換され、そのシンボルはクロック線SCL512およびデータ線SDA514を通じて送信される。
【００５０】
一例では、2進データの元の20ビットが、ビット遷移番号変換器ブロック508に入力され、12桁の3進数に変換される。12桁の3進数の各桁は、「遷移番号」を表す。2つの連続する遷移番号は、同じ数を有し得る(すなわち、3進数の連続する桁は同じであり得る)。各遷移番号は、2つの連続する順次的シンボルが同じ値を有しないように、遷移シンボルブロック510において順次的シンボルに変換される。順次的シンボルごとに1つの遷移が保証されるので、そのような順次的シンボル遷移は、クロック信号を埋め込むように機能し得る。次いで、各順次的シンボル516が2線物理リンク(たとえば、SCL線512およびSDA線514を備えるI2Cバス)を通じて送信される。
【００５１】
図6は、遷移番号602と順次的シンボル604との間の例示的な変換を示す。3進数、base 3の個別の桁は、遷移番号とも呼ばれ、0、1または2という、3つのあり得る値または状態のうちの1つを有し得る。3進数の2つの連続する桁において同じ値が現れることもあるが、2つの連続する順次的シンボルは同じ値を有しない。遷移番号と順次的シンボルとの変換は、連続する遷移番号が同じである場合でも、順次的シンボルが常に(順次的シンボルから順次的シンボルに)変化することを保証する。
【００５２】
図7は、遷移番号と順次的シンボルとの間の例示的な変換をさらに示す。送信機側(送信:TからS)702において、遷移番号(T)が順次的シンボル(S)に変換され得る。たとえば、現在の順次的シンボル(Cs)が、以前の順次的シンボル(Ps)と現在の遷移番号(T)の関数である一時遷移番号(Ttmp)とに基づいて取得され得る。一時遷移番号(Ttmp)は、現在の遷移番号Tを0と比較することによって取得されてよく、T=0であるとき、一時遷移番号(Ttmp)は3に等しくなり、それ以外(Tが0に等しくないとき)では、TtmpはTに等しくなる(すなわち、Ttmp=T=0?3:T)。現在の順次的シンボルは、以前の順次的シンボル(Ps)と一時遷移番号(Ttmp)との合計(すなわち、Cs=Ps+Ttmp)として取得され得る。
【００５３】
受信機側(受信:SからT)704において、現在の順次的シンボル(Cs)および以前の順次的シンボル(Ps)から遷移番号を得るために、変換動作が逆行される。一時遷移番号(Ttmp)は、現在の順次的シンボル(Cs)に4を足して以前のシンボル(Ps)を引いた合計として取得され得る(すなわち、Ttmp=Cs+4-Ps)。現在の遷移番号(T)は一時遷移番号(Ttmp)に等しいが、一時遷移番号(Ttmp)が3と比較され、Ttmp=3であるとき、一時遷移番号(Ttmp)は0に等しくなり、それ以外(Ttmpが3に等しくないとき)の場合、TはTtmpに等しくなる(すなわち、T=Ttmp=3?0:T)。
【００５４】
表706は、遷移番号と順次的シンボルとの間の変換を示す。
【００５５】
図6を再び参照すると、遷移番号と順次的シンボルとの間の変換の例が本明細書で示される。たとえば、第1の周期606では、現在の遷移番号(Ta)は2であるので、Ttmpも2であり、以前の順次的シンボルPsは1であり、新たな現在の順次的シンボルCsは現在では3である。
【００５６】
第2の周期608では、遷移番号(Tb)は1である。遷移番号(Tb)は0に等しくないので、一時遷移番号Ttmpは1という遷移番号(Tb)の値に等しい。現在の順次的シンボル(Cs)は、3という以前の順次的シンボル(Ps)の値を1という一時遷移番号Ttmpに加算することによって取得される。加算演算の結果は3より大きい4に等しいので、ロールオーバーされた数0が現在の順次的シンボル(Cs)になる。
【００５７】
第3の周期610では、現在の遷移番号(T)は1である。遷移番号Tは1であるので、一時遷移番号Ttmpも1である。現在の順次的シンボル(Cs)は、0という以前の順次的シンボル(Ps)の値を1という一時遷移番号Ttmpに加算することによって取得される。加算演算の結果は3より大きくない1に等しいので、現在のシンボル(Cs)は1に等しい。
【００５８】
第4の周期612では、現在の遷移番号(T)は0である。遷移番号Tは0であるので、一時遷移番号Ttmpは3である。
【００５９】
現在の順次的シンボル(Cs)は、1という以前の順次的シンボル(Ps)の値を3という一時遷移番号Ttmpに加算することによって取得される。加算演算の結果は3より大きい4であるので、ロールオーバーされた数0が現在の順次的シンボル(Cs)になる。
【００６０】
2つの連続する3進数の桁TbおよびTcが同じ数を有する場合であっても、この変換は、2つの連続する順次的シンボルが異なる状態値を有することを保証することに留意されたい。このため、順次的シンボル604中の保証された遷移がクロック信号を埋め込むように機能し、それにより、データ送信のためのI2Cバス中のクロック線SCLを解放することができる。
【００６１】
図5を再び参照すると、受信機520において、トランスコーディングされたシンボルをビットに変換するためにプロセスが逆にされ、そのプロセスにおいて、シンボル遷移からクロック信号が抽出される。受信機520は、2線の物理リンク(たとえば、SCL線524およびSDA線526を備えるI2Cバス)を通じて一連の順次的シンボル522を受信する。受信された順次的シンボル522は、クロックタイミングを復元し、トランスコーディングされたシンボル(S)をサンプリングするために、クロックデータ復元(CDR)ブロック528に入力される。その後、シンボル遷移番号変換器ブロック530が、トランスコーディングされた(順次的)シンボルを、遷移番号、すなわち、1つの3進数の桁の数に変換する。次いで、遷移番号ビット変換器532は、12個の遷移番号を変換して、12桁の3進数から20ビットの元のデータを復元する。
【００６２】
本明細書において示されるこの技法は、I2Cの標準的なバスが提供し本明細書においてCCIeモードと呼ばれるものを超えて、制御バス108(図1)のリンク速度を高めるために使用され得る。一例では、制御データバス108に結合されるマスターノード/デバイスおよび/またはスレーブノード/デバイスが、標準的なI2Cバスを使用して可能であるものよりも高いビットレートを同じ制御データバス上で達成するために、シンボル送信内にクロック信号を埋め込む送信機および/または受信機(図4および図5に示されるような)を実装することができる。
【００６３】
共有バス上でI2C、sI2C、およびCCIeデバイスをサポートするための例示的な方法
1つの機能は、I2CデバイスとCCIeデバイスの両方の同時にサポートする共有バスを実装することを実現する。図1〜図7において注記されるように、シンボル遷移内にクロック信号(I2CバスではSCL線)を埋め込み、それによってデータ送信のためにクロック線(SCL線)を使用できるようにすることが可能である。このことは、たとえば、通常のI2Cモードバスよりも高いビットレートでのCCIe動作モードを可能にし得る。
【００６４】
しかしながら、1つの課題は、同じ共有バス上でのレガシーI2C適合デバイスとCCIe適合デバイスの両方の同時の動作を可能にすることである。I2CプロトコルおよびCCIeプロトコルの要件についてのいくつかの詳細が、これらのモードに従って動作するデバイスをサポートするための方法を編成する際に有用であり得る。
【００６５】
I2C規格は、すべてのI2C適合スレーブデバイスがSTART条件(たとえば、SCL線が共有バス上でハイである間はSDA線上のハイからローへの遷移によって示される)の受信の際にバス論理をリセットしなければならないことを求める。
【００６６】
図8は、I2Cの1バイトデータ書込み動作のタイミング図を示す。I2Cマスターデバイスは、I2Cバス上のどのスレーブデバイスにマスターデバイスがアクセスすることを望むかを示すために、SDA線802において7ビットのスレーブIDを、次いで書込み動作を示すために1ビットを送信する。IDが7ビットのスレーブIDと一致するスレーブデバイスだけが、意図される活動を引き起こし得る。I2Cスレーブデバイスがそれ自体のIDを検出するために、マスターデバイスは、SDA線上で少なくとも8ビット(またはSCL線804上で8個のクロックパルス)を送信しなければならない。したがって、レガシーI2Cスレーブデバイスが共有バスを通じて任意のCCIe動作に反応するのを防ぐために、CCIeモードで共有バスを動作させるとき、上記のことが利用され得る。特に、CCIeプロトコルが開始(S)インジケータと開始インジケータの間に7ビット未満を送信する場合、レガシーI2Cスレーブデバイス(少なくとも7ビットを予期する)はこれを不完全なスレーブデバイス識別子(SID)として扱い、その論理をリセットする。
【００６７】
図9は、sI2Cプロトコルに従った、最上位ビット(MSB)が1であるsI2Cの1バイトデータ書込み動作のタイミング図を示す。この例では、SDA線902を通じたI2C送信は、スレーブ識別子(SID)904の最上位ビットにおいて1を含み得る。マスターデバイスは、新たに追加されたスレーブデバイスがスレーブデバイスであることを単にMSBを調査することによって簡単に知ることができるので、1であるMSBは、sI2Cスレーブデバイスのホットプラグまたはスワップを可能にする。
【００６８】
図10は、CCIeプロトコルの一例を示す。ブロックは、CCIe固有のタイミングおよびシグナリング、ならびにレガシーのI2Cのタイミングおよびシグナリングを示す。1002に示されるように、CCIeモードに入り、CCIeモードから出るためのプロトコルがある。CCIeモードへのエントリが実行されると、共有バスモードは、CCIeモードからのイグジットが実行されるまでCCIeモードにとどまる。この例では、CCIeモードへのエントリは、I2Cモードの間の一般的な呼出しの一部として、CCIeモードエントリシーケンス1004によって成し遂げられる。CCIeモードへのエントリをI2C適合デバイスに告知するために、CCIeモードで動作するマスターデバイスは、CCIeモード1032へのエントリを告知するI2Cの一般的な呼出し1030を、共有バスを通じて送信することができる。同様に、CCIeモードからのイグジット1006を告知するために、マスターデバイスは、一般的な呼出しの一部としてCCIeモードイグジットシーケンス1034を送信することができる。一般的な呼出しの中のこれらのエントリ/イグジットシーケンス1030および1034はそれぞれ、I2CモードからCCIeモードに、およびCCIeモードからI2Cモードに切り替えるために、CCIe対応デバイスによって使用される。これらの一般的な呼出し1030および1034はまた、I2Cのみのスレーブデバイスが、共有バスがいつCCIeモードに切り替えているかを知り、割込みを出すのを保留すること、またはそうでなければ共有バス上で送信するのを保留することを可能にする。
【００６９】
データ書込みプロトコル1008は、任意の数のアドレスワード1014およびデータワード1016を、スレーブ識別子(SID)1018によって特定されるスレーブノード/デバイスに送信することができる。同様に、データ読取りプロトコル1010は、スレーブ識別子(SID)によって特定されるスレーブノード/デバイスから複数のデータワード1022を読み取ることができるが、アドレスワード1020の数はそれでも任意である。
【００７０】
1つの最後の特別なプロトコルは、リンクレートを最大化するようにクロックデータ復元論理を較正するためのシーケンスを、指定されたCCIeデバイス(マスターデバイス自体を含む)に開始させるために、CCIeマスターデバイスによって使用され得る、クロックデータ復元(CDR)較正1012である。この目的で、CCIeマスターデバイスはまた、それ自体のスレーブIDを有しなければならない。
【００７１】
任意のCCIeワードは、19ビットの情報を搬送する12個のシンボルの中で送信され得る。CDR較正プロトコル1012を除けば、19ビットのうちの16個のビットがデータ情報であってよく、一方、19ビットのうちの3個のビットが制御情報のような他の情報のために使用される。
【００７２】
図11は、共有バスを通じてsI2C適合スレーブデバイスによって送信される例示的な帯域内割込み信号(IRQ)1102の図を示す。スレーブデバイスは、マスターデバイスが検出する共有バスのSDA線1104をプルダウンし、またはグラウンドに接続し(1106)、次いで要求しているスレーブデバイスへのSDA線1104を解放する。そうすると、スレーブデバイスは、IRQ信号1102を送信することが可能である。IRQ信号が終了すると、マスターデバイスは、SDA線1104をある期間ローに保つことによって、割込み信号の受信に肯定応答することができる。
【００７３】
再び図10を参照すると、I2C適合スレーブデバイスのように、sI2Cスレーブデバイスは、CCIeモードへのエントリを告知する理解可能なI2Cプロトコルメッセージ1030を受信することができ、それ自体が帯域内IRQ(すなわち、共有バスを通じた割込み信号)を送信することを直ちに無効にする。sI2Cスレーブデバイスは次いで、sI2Cスレーブデバイスが理解せず無視するCCIe通信1032を受信し得る。最後に、sI2Cスレーブデバイスは、CCIeモードからのイグジットを告知する理解可能なI2Cプロトコルメッセージ1034を受信することができ、sI2Cスレーブデバイスはそれ自体が帯域内IRQを再び送信することを有効にする。
【００７４】
図12は、混合プロトコルモードの環境において割込み信号(IRQ)を出すためのsI2Cスレーブデバイスの追加の方法を示す(たとえば、共有バスは別個の通信プロトコルに従って動作することができ、または別個の通信プロトコルを動的に切り替えることができる)。以前に述べられたように、共有バス1204がCCIeモードにおいてマスターデバイス1208によって管理される間、sI2C適合スレーブデバイス1210aおよび1210bは、共有バス1204を通じて帯域内割込み信号を送信することまたは出すことを止めることができる。しかしながら、この代替的な手法では、これらのsI2C適合スレーブデバイス1210aおよび1210bは、1つまたは複数の別の線1212および1214を介してIRQルータCCIeスレーブデバイス1216に結合され得る。共有バス1204がCCIeモードで動作しているとき、sI2C適合スレーブデバイス1210は、代わりに割込み信号をIRQルータCCIeスレーブデバイス1216に送信するように構成され得る。IRQルータCCIeスレーブデバイス1216は、sI2Cプロトコル割込み信号を受信し、割込みをCCIe IRQバスまたは線1206にルーティングするので、sI2Cプロトコル割込み信号はマスターデバイス1208によって処理され得る。マスターデバイス1208は次いで、共有バス1204をI2Cモードに切り替えるかどうかを決め、要求しているI2C適合スレーブデバイスに対して割込み要求を認めることができる。
【００７５】
その結果、共有バス1204がCCIeモードで動作している可能性がある間、sI2C適合スレーブデバイス1210が割込み信号(たとえば、共有バス1204のサービスまたは使用を要求する)を出すそれ自体の能力を無効にする代わりに、各sI2C適合スレーブデバイス1210内の内部論理は、共有バス1204からの割込み信号の出力を、sI2Cスレーブデバイス1210をIRQルータCCIeスレーブデバイス1216に結合する別の線1212または1214に切り替えることができる。また、共有バス1204を通じてCCIeモードからのイグジットコードを検出すると、sI2C適合スレーブデバイス1210は、割込み信号を出すために、共有バス1204を使用することに戻る。したがって、共有バス1204がデータ競合を伴わずにCCIeモードで動作する間、sI2C適合スレーブデバイス1210およびCCIe適合スレーブデバイス1218は共存し得る。
【００７６】
マルチモード共有制御データバス上で動作する例示的なシングルモードスレーブデバイス
図13は、送信機および受信機回路1306と処理/論理回路1304とを備える例示的なスレーブデバイス1302を示す。送信機および受信機回路1306は、処理/論理回路1304および1つまたは複数のバスとの間でデータを送信するために、処理回路1304に結合され得る。送信機および受信機回路1306は、たとえば、第1の線と第2の線とを含み得るマルチモード共有バス1320に結合され得る。第1の動作モード(たとえば、I2Cモード)では、送信機および受信機回路1306は、データ送信のために第1の線を、および第1のクロック信号のために第2の線を使用するように構成され得る。第2の動作モード(たとえば、CCIeモード)では、送信機および受信機回路1306は、データ送信のシンボル遷移内に第2のクロック信号を埋め込みながら、データ送信のために第1の線と第2の線の両方を使用するように構成され得る。マルチモード共有バスは、I2C適合バスおよび/またはCCIe適合バスであり得る。第3の動作モードでは、送信機および受信機回路1306は、第2のモードと同様に、しかし第1のモードのみのレガシーデバイス(たとえば、I2C適合レガシーデバイス)に対する同時のサポートを伴わずに動作する。
【００７７】
スレーブデバイス1302は、マルチモード共有バス1320に結合された他のデバイスのセットと共存することができるが、第1の動作モードと第2の動作モードの両方の間、少なくとも第1の線および/または第2の線を常に監視しながら、第1のモードのみにおいて動作する。第1の動作モードでは、スレーブデバイス1302は、共有バス1320の第1の線を通じてデータを別のデバイスに送信することができる。第2の動作モードでは、共有バス1320の第1の線および第2の線の両方が、第2のモードをサポートする他のデバイスのために、第2のモードに従ってデータを送信することができる。
【００７８】
様々な例において、共有バス1320に結合されるデバイスは、複数の異なる動作モード(たとえば、別個の通信プロトコル)をサポートすることができる。たとえば、第1のスレーブデバイスはsI2C適合スレーブデバイスであってよく、第2のスレーブデバイスはCCIe適合スレーブデバイスであってよく、第3のスレーブデバイスは複数のモード(たとえば、I2C適合モードおよびCCIe適合モード)が可能であり得る。
【００７９】
第1の動作モードは、共有バス1320を通じたデータ送信のために第1のプロトコルを実装することができ、第2のモードは、共有バス1320を通じたデータ送信のために第2のプロトコルを実装する。
【００８０】
一例では、スレーブデバイス1302は、sI2C適合スレーブデバイスであり得る。処理回路1304は、共有バス1320が第1のモードに従って動作するときに共有バス1320上の通信を監視するように機能する、共有バス監視回路/モジュール1310を含み得る。共有バス1320が第2のモードに従って動作するとき、共有バス監視回路/モジュール1310は、バスが第1のモードに戻っていることを示すイグジット呼出し/コマンドを監視するように機能する。割込み要求生成回路/モジュール1312は、割込み信号を生成するように機能し得る。割込み要求禁止回路/モジュール1314は、スレーブデバイス1302が割込み要求を生成することおよび/または出すことをいつ保留すべきであるかを見出すように機能し得る。たとえば、共有バス1320が第2のモードに従って動作していることを共有バス監視回路/モジュール1310が検出する場合、割込み要求禁止回路/モジュール1314は、共有バス1322を通じて割込みが出されることを防ぐことができる。
【００８１】
送信機および受信機回路1306は、(送信されたデータからクロック信号を復元するための)クロック復元回路1308を含み得る。任意選択の/代替的な手法では、IRQ切替え回路1316は、共有バス1320が第2のモードで動作するときに、スレーブデバイス1302が別の線を通じて割込みルータデバイス1322に割込み要求を出すことを可能にし得る。
【００８２】
図14は、複数の通信モードを切り替える共有データバス上でシングルモードスレーブデバイスが共存することを許可するための方法を示す。スレーブデバイスは、共有データバスを通じた帯域内割込み要求を含む第1のプロトコルモードで動作することができる(1402)。スレーブデバイスは次いで、共有データバスを通じた帯域内割込み要求を許容しない第2のプロトコルモードに従って共有データバスが動作することに切り替えることを示すエントリ呼出しについて、共有データバスを監視することができる(1404)。エントリ呼出しを検出すると、スレーブデバイスは、共有データバスを通じて帯域内割込み要求を出すことを無効にする(1406)。任意選択で、スレーブデバイスは、別の線を介して割込み要求ルータに割込み要求を送信することに切り替えることができる(1408)。スレーブデバイスは、第2のプロトコルモードからのイグジット呼出しについて共有データバスを監視することができる(1410)。イグジット呼出しを受信すると、スレーブデバイスは、共有データバスを通じて帯域内割込み要求を行うことを可能にする(1412)。
【００８３】
帯域内IRQを伴う共有制御データバス上でのI2Cスレーブデバイスおよびカメラ制御インターフェース拡張デバイスの共存
上の議論は、専用の割込みバスを使用して、I2C適合スレーブデバイスとCCIe適合スレーブデバイスとの間でIRQをルーティングすることを可能にした。以下の議論は、共有制御データバスを通じて帯域内割込みをI2C適合デバイスとCCIe適合デバイスの両方が使用することを可能にする。
【００８４】
第1の特徴は、共有バスに結合されるすべてのデバイスのための専用の割込み線およびピンを除去することを可能にする。代わりに、すべてのデバイスが、共有制御データバスを使用して割込み要求を出し、それによって、共有制御データバスに結合されるスレーブデバイスが共有制御データバスを通じてデータを送信することを可能にする。
【００８５】
第2の特徴は、共有制御データバスを通じて送信されるシンボル内で割込み期間を定義することを可能にし、この割込み期間の間、バスに結合された1つまたは複数のスレーブデバイスがバスの第1の線の上で割込み要求をアサートでき、一方でバスの第2の線がハートビート送信のためにマスターデバイスによって使用され、そのようなハートビート送信は1つまたは複数のスレーブデバイスを同期するように機能する。
【００８６】
第3の特徴は、共有バスを通じて受信されるトランスコーディングされたデータビットを復号する目的で、割込み期間の間に受信機デバイスにおいて共有バスの第1の線を内部的にマスクすることを可能にする。たとえば、マスターデバイスおよびスレーブデバイスは、ローカルで(内部的に)生成されるマスク信号を使用することによって、クロックデータ復元回路(CDR)への第1の線の入力をマスクすることができる。
【００８７】
第4の特徴は、スレーブデバイスが割込み要求をアサートしたかどうかを確かめるために、割込み期間の間に共有制御データバスの第1の線をマスターデバイスが監視することを可能にする。
【００８８】
第5の特徴は、共有制御データバスの第1の線を通じて割込み要求を検出すると、マスターデバイスが共有制御データバスを通じてスレーブデバイスをスキャンしてアサートしている/要求しているスレーブデバイスを特定することを可能にする。
【００８９】
専用のIRQ線を使用する割込み機構
図15は、共有制御データバス1504および共有割込みバス/要求1506に結合される、マスターデバイス1508と複数のスレーブデバイス1510a〜1510eとを有するシステム1502を示すブロック図である。一例では、制御データバス1504は、2つの配線、クロック線(SCL)およびシリアルデータ線(SDA)を備える、I2Cバスであり得る。クロック線SCLは、I2Cバス(制御データバス1504)上でのすべてのデータ転送を同期するために使用され得る。データ線SDAおよびクロック線SCLは、I2Cバス(制御データバス1504)上のすべてのデバイス1508および1510a〜1510eに結合される。CCIeモードにおいて使用されるとき、制御データバス1504のSDA線とSCL線の両方がデータ送信のために使用され得る。
【００９０】
一態様によれば、共有割込みバス1606は、スレーブデバイス1610a〜1610eに、さらにはマスターデバイス1608に結合される単一の線であり得る。この共有割込みバス1506は、使用されていないときはプルアップされてよく(たとえば、ハイに引き込まれてよく)、スレーブデバイスが割込み要求(IRQ)信号をアサートするときはローに引き込まれてよい(たとえば、グラウンドに接続されてよい)。すなわち、各スレーブデバイス1510a〜1510eは、IRQ信号(たとえば、要求)をマスターデバイス1508に送信することによって、共有制御データバス1504上で送信するためのアクセスを独立して要求することができる。
【００９１】
いくつかの例では、単線IRQバスは、非同期バスであってよい(たとえば、マスターデバイスまたは任意の他のデバイスによって管理されない)。これは、スレーブデバイスがいつでもIRQ信号を一方的にアサートできることを意味する。
【００９２】
別の例では、単線IRQバスは、スレーブデバイスからマスターデバイスへの単方向信号送信に専用であってよい。すなわち、単線IRQバスは、IRQ信号のためにだけ使用されることが可能であり、他のタイプの信号には使用され得ない。
【００９３】
一例では、制御データバス1504は、カメラ制御インターフェース(CCI)またはCCI拡張互換バスであってよい。
【００９４】
別の例では、制御データバス1504は、スレーブデバイスとマスターデバイスとの間の双方向バスであってよい。
【００９５】
図16は、割込みを出す目的で図15の複数のスレーブデバイス1510a〜1510eがどのように論理的にグループ化され得るかを示すブロック図である。この例では、第1の複数のスレーブデバイス1510aおよび1510bは第1のグループ1602の中にあってよく、第2の複数のスレーブデバイス1510cおよび1510dは第2のグループ1604の中にあってよい。そのようなグループ化は、たとえば、事前に構成されていてよく、またはマスターデバイス1508によって起動時に(たとえば、列挙によって)動的に定義されてよい。そのようなグループ化によって、マスターデバイス1508は、許容できない遅延を伴うことなく、どのスレーブデバイスがIRQバス1506上でIRQ信号をトリガしたかを、より迅速に特定できるようになる。
【００９６】
スレーブデバイス1602および1604の各グループは、別個のIRQ信号を有し得る。たとえば、第1のグループ1602は、第1の期間を有する第1の信号を使用することができ、第2のグループ1604は、第2の期間を有する第2の信号を使用することができ、以下同様である。たとえば、「期間」は、アサートしているスレーブデバイスによってIRQバス1506がローに引き込まれる時間の長さであってよい。たとえば、異なるスレーブデバイスのグループによって使用されるIRQ信号に対する異なる電圧レベルのような、他の形の信号の区別が使用され得ることに留意されたい。一実装形態では、各「グループ」は単一のスレーブデバイスを含み得る。他の実装形態では、各「グループ」は、2つ、3つおよび/または4つの、またはそれよりも多くのスレーブデバイスを含み得る。グループあたりのスレーブデバイスの数は、アサートしているスレーブデバイスに問い合わせ、それを特定するのに要する時間に依存し得る。たとえば、IRQバス1506に結合される多数のスレーブデバイスがマスターデバイス1508によって問い合わせられなければならない場合、このことは、許容できない長い遅延を引き起こし得る。その結果、スレーブデバイスをグループ化し、各グループに対して別個のIRQ信号を使用することにより、マスターデバイス1508は、比較的短期間で、または許容可能な期間で、アサートしているスレーブデバイスを特定することが可能になる。
【００９７】
マスターデバイス1508は、共有単線IRQバス1506上でIRQ信号の発生を検出し、グループ中の各スレーブデバイスに問い合わせ、どのスレーブデバイスがIRQ信号をトリガまたはアサートしたかを特定する。たとえば、IRQ信号がグループ2 1604スレーブデバイスを特定する場合、マスターデバイス1508は、グループ2 1604内の第1のスレーブデバイス1510cに(制御データバス1504を介して)レジスタステータス要求を送信することができる。第1のスレーブデバイス1510cのステータス応答が、第1のスレーブデバイス1510cがアサートしているスレーブデバイスでないことを指す場合、マスターデバイス1508は、グループ2 1604内の第2のスレーブデバイス1510dに(制御データバス1504を介して)別のレジスタステータス要求を送信することができる。このプロセスは、IRQ信号をアサートしたスレーブデバイスが特定されるまで、グループ2 1604中のすべてのスレーブデバイスに対して繰り返される。
【００９８】
代替的な手法では、マスターデバイス1508は、第1のスレーブデバイス1510cがIRQ信号の発行者であると特定された場合であっても、グループ2 1604中のすべてのスレーブデバイスをスキャンすることができる。たとえば、同じグループ中の2つ以上のスレーブデバイスが同時にIRQ信号を出す可能性がある。その結果、マスターデバイスは、グループ中のデバイスからのすべてのIRQ要求を一度に知り、それらを1つずつ扱うことができる。一実装形態では、単一のグループ中の複数のデバイスからの同時のまたは重複するIRQ要求は、緊急性、重要性、および/または優先度の順序でマスターデバイス1608によって扱われ得る。
【００９９】
図17は、IRQ信号がIRQ線またはバスを通じてどのように調停され得るかの第1の例を示す。この例では、異なるスレーブデバイスグループ1702および1704が定義されてよく、各スレーブデバイスグループ1702および1704は、異なる幅の割込み1706および1708を有する。IRQN線1506がローであることをスレーブデバイスが検出するとき、スレーブデバイスは、IRQN線をローにアサートする前に、IRQN線1506がハイになり、さらに最小バス自由時間1702が経過するのを待つ。この例では、第1の割込み1706は第1のグループ1702内のスレーブデバイスによってアサートされ、第2のグループ1704内の別のスレーブデバイスによってアサートされる第2の割込み要求1708が後に続く。
【０１００】
図18は、IRQ信号がIRQ線またはバス1506の上でどのように調停され得るかの第2の例を示す。2つのスレーブデバイスが(割込み要求を示すために)IRQN線をローへ同時に(または重複する時間に)アサートするとき、最長のIRQNロー期間を有するスレーブグループが優先される。この例では、第1の割込み信号1806は第1のグループ1802中の第1のスレーブデバイスによってアサートされる/出されるが、同時にまたは同時期に(たとえば、時間的に重複して)、第2のグループ1804中の第2のスレーブデバイスは、共有割込みバス1506を通じて第2の割込み信号1808をアサートしている/出している。第2の割込み信号1808は第1の割込み信号1806より長いので、第1のグループ1802中の第1のスレーブデバイスは調停を失う。すなわち、第2の割込み信号1808は割込みバス1506上で認識されるが、第1の割込み信号1806は認識されない。要求している第1のスレーブデバイスは、第1の割込み信号1806の終わりにおいて割込みバス1506を解放するときに調停の喪失を検出することができるが、割込みバス1506は、ハイに戻る(たとえば、ハイに引き込まれる)はずであったときにローにとどまる(たとえば、グラウンドに引き込まれる)。その結果、第1のスレーブデバイスは後の時間に(たとえば、割込みバス1506が第2の割込み信号1808の終了後にある長さの時間1812だけ再びプルアップされた後で)割込み信号1810を再び出す。
【０１０１】
図19は、一例では実現可能であり得る最短のIRQ信号長を示す。この例は、割込み線1902に対して、IRQ信号1904が遅くともVDDレベルの70%(たとえば、ハイ状態)であるときに「ハイ」状態が検出されることが可能であり、IRQ信号1904が遅くともVDDレベルの30%であるときに「ロー」状態が検出されることが可能であると仮定する。IRQ信号1902がVDDレベルの30%から70%の間のどこかにあるときは、受信機の入力レベルに応じて、ハイ状態またはロー状態が検出され得ることに留意されたい。ここで、TRF maxは最大の立ち下がり-立ち上がり時間であり、TLOWは意図されるローの期間である。tLOWの制約の主な目的は、マスターデバイスがスレーブデバイスの異なるグループからのIRQ信号を区別できるようにすることである。加えて、マスターデバイスの観点からは、IRQ信号1904がロー状態として検出されることが保証されるように、2TRF maxはTLOWより小さくなければならない(すなわち、2TRF max < TLOW)。
【０１０２】
第1のIRQ信号長(期間)tLOWはTLOW-TFRより大きく、2TLOW+TFRより小さい(すなわち、TLOW-TFR < tLOW < 2TLOW+TFR)。同様に、第2のIRQ信号長(期間)tLOWは2TLOW-TFRより大きく、2TLOW+TFRより小さい(すなわち、2TLOW-TFR < tLOW<2TLOW+TFR)。
【０１０３】
第1のスレーブデバイスがIRQ信号ローをアサートした後に、第2のスレーブデバイスは、TFR maxから、少なくともTFR maxの長さでなければならないtLOW minまでにわたる期間、IRQ信号をローとして検出することができないことに留意されたい。したがって、TLOW > 3TFR maxかつtLOW min > 2TFR maxである。
【０１０４】
(たとえば、専用のIRQバス/線を通じた)側帯IRQには、割込みのレイテンシに関して、(たとえば、共有制御データバスを通じた)帯域内IRQを上回る明らかな利点がある。側帯IRQは、割込み信号の検出において非常に短いレイテンシを要求するいくつかの実装形態では好ましいことがある。
【０１０５】
共有バスを通じた帯域内割込み機構
図15から図19に示される側帯IRQの方法は、各スレーブデバイスとマスターデバイスに対して過剰なピンの使用を必要とする。スレーブデバイスは特に、利用可能なサイズ/空間が限られていることが多く、側帯割込みの使用または専用の割込み線/バスの要件をなくすことが望ましいであろう。したがって、側帯IRQの方法に対する代替形態は、共有制御データを通じて帯域内IRQを送信することである。
【０１０６】
図20は、割込みバスが帯域内割込みを優先して除去された例示的なシステム2002を示すブロック図である。システム2002は、共有制御データバス2004に結合されるマスターデバイス2008と複数のスレーブデバイス2010a〜2010eとを含み得る。一例では、制御データバス2004は、2つの配線、クロック線(SCL)およびシリアルデータ線(SDA)を備える、I2Cバスであり得る。クロック線SCLは、I2Cバス(制御データバス2004)上でのすべてのデータ転送を同期するために使用され得る。データ線SDAおよびクロック線SCLは、I2Cバス(制御データバス2004)上のすべてのデバイス2008および2010a〜2010eに結合される。図15〜図16と比べると、このシステム2002は別の割込み線またはバスを有しない。代わりに、割込みは共有制御データバス2004を通じて帯域内で送信される。
【０１０７】
1つの特徴は、I2Cデバイスとカメラ制御インターフェース拡張(CCIe)デバイスの両方を同時にサポートする(たとえば、CCIeモードとI2Cモードとの間で共有バスを動的に切り替える)共有制御データバスを実装することを可能にする。
【０１０８】
共有バスを通じた例示的なCCIeおよびI2C送信
図21は、I2Cの1バイトデータ書込み動作の例示的なタイミング図を示す。この例では、共有制御データバス2004(図20)は、シリアルデータ線SDA2102およびシリアルクロック線SCL2104を含む。図21に示される送信方式は「I2Cモード」と呼ばれ得る。SCL線2104は、マスターデバイスからすべてのスレーブデバイスにクロックを送信するために使用されるが、SDA線2102はデータビットを送信する。I2Cマスターデバイスは、I2Cバス上のどのスレーブデバイスにマスターデバイスがアクセスすることを望むかを示すために、SDA線2102において7ビットのスレーブID2208を、次いで書込み動作を示すために1ビットを送信する。IDが7ビットのスレーブID2108と一致するスレーブデバイスだけが、意図される活動を引き起こし得る。I2Cスレーブデバイスがそれ自体のIDを検出するために、マスターデバイスは、SDA線上で少なくとも8ビット(またはSCL線2104上で8個のクロックパルス)を送信しなければならない。
【０１０９】
I2C規格は、すべてのI2C適合スレーブデバイスがSTART条件2106(たとえば、SCL線がハイである間はSDA線上のハイからローへの遷移によって示される)の受信の際にバス論理をリセットすることを求める。
【０１１０】
CCIeプロトコルは、データ送信内にクロック信号を埋め込みながら、データ送信のためにSDA線2102とSCL線2104の両方を使用する。たとえば、データビットは複数のシンボルへとトランスコーディングされてよく、複数のシンボルは次いで線を通じて送信される。クロック信号(図21のI2CバスではSCL線)をシンボル遷移の中に埋め込むことによって、SDA線2102とSCL線2104の両方がデータ送信のために使用され得る。
【０１１１】
図22は、SDA線2102およびSCL線2104を通じた送信のためにデータビットが12個のシンボルにトランスコーディングされている例示的なCCIe送信を示す。図22に示される送信方式は「CCIeモード」と呼ばれ得る。
【０１１２】
CCIeモードは、プッシュプルドライバによって駆動されるソースの同期である。共有制御データバスを通じてデータを送出するものは、データに埋め込まれるクロック情報も送出する。その結果、制御データバス上で1つのデバイスだけが、任意のある時間においてバスを駆動することが許可される。
【０１１３】
同じバスを通じてレガシーI2CデバイスとCCIeデバイスの両方をサポートするために、CCIeモードの動作は同じSTART条件2200、2202、2204を使用し、これは、レガシーI2CスレーブデバイスがCCIe動作に反応するのを防ぐ(たとえば、CCIeモードの間のStart条件は、レガシーI2Cスレーブデバイスをリセットさせる)。この例では、START条件2200、2202、および2204(すなわち、SCL線2104がハイである間のSDA線2102でのハイからローへの遷移によって示される)は、完全なスレーブID(すなわち、完全な7ビット)が送信される前に検出されるので、これは不完全なスレーブID(7ビット未満)である。マスターデバイスが6個のSCLパルスを送信し、次いでSTART条件2200、2202、または2204を出す場合、すべてのレガシーI2Cスレーブデバイスは、データをI2CスレーブIDとして認識する前にバス論理をリセットする。6ビットのシーケンス(たとえば、あらゆる2つのシンボルに対応する)が2つのSTART条件2200、2202、および2204の間に送信されるので、これらの6ビットのシーケンスは、いずれのスレーブデバイスによっても有効なスレーブIDとして復号されない。その結果、レガシーI2Cスレーブデバイスは、不完全なスレーブIDに対して動作しない。
【０１１４】
このシステムでは、マスターデバイスは共有バスへのアクセスを制御する。よって、制御データバスを通じて送信することを望むいずれのデバイスも、たとえば、割込み要求を出すことによって、マスターデバイスからのそのようなアクセスを要求しなければならない。割込みを出すための従来技術の機構は、専用の割込み線または専用の割込みバスに依存している。しかしながら、そのような専用の割込み線またはバスは、そのような割込み線またはバスに対応するためにデバイスが少なくとも1つの追加のピンを含まなければならないことを意味する。そのような専用の割込みピンおよび線/バスの必要をなくすために、CCIe内での帯域内割込みのための機構が必要である。
【０１１５】
帯域内割込みの使用は、バスのコンテンションまたは競合も回避しなければならない。たとえば、図23に示されるように、競合を避けるために、スレーブデバイスは、マスターデバイスが制御データバスを駆動している間、IRQをアサートするように制御データバス(たとえば、SDA線2102またはSCL線2104のいずれか)を駆動することが許可されるべきではない。
【０１１６】
図24は、図23の競合の可能性を避けるための解決法を示す。この手法では、CCIeプロトコルは、帯域内IRQがいつ出され得るかを定義する。ここで示されるように、マスターデバイスはSCL 2102線上でクロックを駆動することができ、一方、帯域内割込みを出すようにスレーブがSDA線2104を駆動することを可能にするためのある期間が定義される。具体的には、CCIe適合スレーブデバイスはまず、SDA線2104が使用されている(たとえば、ローに引き込まれている)かどうかを確認し、そうではない場合にだけ、SDA線2104をローに引き込むことによって割込み要求を出す。
【０１１７】
図25に示される別の問題は、スレーブデバイスがSDA線上で帯域内IRQを送信するときに、それが誤ったクロックの検出を引き起こし得ることである。すなわち、CCIeモードでは、受信機クロックRXCLKを生成するためにシンボル遷移が使用される。これは、すべての受信デバイスが共有バスの状態遷移からクロックタイミングを復元することを意味する。状態遷移、SDA線およびSCL線の状態変更は、SDA線とSCL線の間でタイミングが揃っていなければならない。CCIeクロックデータ復元(CDR)回路は、SDA線とSCL線の間にある程度のスキューを許容し得るが、CDRの許容範囲よりも大きいスキューは、CDRに余剰の受信機クロックパルス2502を生成させ、CCIeワードの境界に対する同期の喪失をもたらす。
【０１１８】
図26は、図25に示される余剰の受信機クロックパルスと同期の喪失とを避けるための解決法を示す。帯域内IRQのために使用される信号は、各デバイス(たとえば、マスターデバイスおよびスレーブデバイス)によって入力されるクロックデータ復元回路においてマスクされなければならない。たとえば、各CDR回路は、帯域内IRQ送信の間にSDA線2104またはSCL線(帯域内IRQのために使用される線はどちらでも)をマスクする(2602)。たとえば、マスターデバイスがスレーブデバイスに特定の帯域内IRQプロトコル2604によってSDA線2104を駆動させる場合、制御データバス上のすべてのデバイスは、エラーの多い/余剰のRXCLKパルスが検出されることを防ぐために、その期間の間はSDA線の入力をマスクしなければならない。一例では、各デバイスは、帯域内IRQ期間の間、CDR回路への値を1(またはハイ)に保つようにSDA線をゲーティングしなければならない。
【０１１９】
図27は、I2CモードとCCIeモードの両方をサポートしながら帯域内IRQ期間を実装するための1つの手法を示す。この手法では、共有バスがCCIeモードからI2Cモードに切り替えるべきであることを示すために、イグジットインジケータ2702および2704が、CCIeモードにおいて、さらにはI2Cモードにおいて送信される。その後、sI2Cスレーブデバイスは、I2Cモードにある間に帯域内IRQ 2706を出すことができる。帯域内IRQが出された後で、共有バスは、マスターデバイスがI2Cモードにある間にエントリ呼出し2708を出すとき、CCIeモードに戻ることができる。
【０１２０】
CCIeモード内でのハートビートクロックの例示的な組込み/符号化
一例によれば、「ハートビート」は、2線の制御データバスを通じた送信のためにデータビットを符号化するために使用される3進数空間内に符号化され、または組み込まれ得る。
【０１２１】
図5を参照すると、示されるトランスコーディング方法は、20ビットを3進数へと符号化するステップを含み、この3進数は次いで12個のシンボルに変換される。この符号化の使用は、CCIeプロトコル内でコマンドを送信するために使用され得る20ビット内で余剰ビットまたは予備ビットをもたらす。
【０１２２】
図28は、ビット19(すなわち、ビット0を最初のビットとしてビットのカウントを開始するときの20番目のビット)を示す。言い換えると、コンピュータ科学において典型的であるように、ビットごとのカウントは0で開始し、ビット19は20番目のビットである。ここで、ビット0〜18は、0000_0000_00003から2221_2201_20013という3進数の範囲内で表される。2221_2201_20023から2222_2222_22223の範囲内の3進数は、データ送信のためには使用されない。その結果、3進数の範囲2221_2201_20023から2222_2222_22223が、ビット19(すなわち、20番目のビット)を表すために使用され得る。言い換えると、2221_2201_20023という3進数は、1000_0000_0000_0000_0000という2進数(0x80000という16進数)であり、2222_2222_22223という3進数(0x81BF0)はとり得る最大の12桁の3進数である。ハートビートが送信され得るのは、この20番目のビット(ビット19)の数空間内である。
【０１２３】
図29は、ビット19が数2221_2201_20023から2222_2222_22223にわたり得るとともに、その範囲の数が図29の左側の6個の区分へと区分され得ることを示す。CCIeは、マルチマスター制御データバスアーキテクチャであり、制御データバスの管理は、あるマスターデバイスから別のマスターデバイスに移され得る。その結果、「マスターバス要求」コマンドが(副範囲2222_1121_02103から2222_2112_11213の中で)利用可能であり、さらには「マスターハンドオーバー」が(副範囲2222_2220_00023から2222_2221_12103の中で)利用可能である。
【０１２４】
図30は、ハートビートを定義するために使用され得るビット19の数空間内の範囲を示す。
図31は、共有制御データバスのSDA線およびSCL線を通じてハートビートクロックがどのように送信され得るかの一例を示す。受信機クロック(RXCLK)3108は、制御データバス(たとえば、SDA線3110およびSCL線3112)上の送信されるシンボルの状態遷移から抽出され得る。この例は、ハートビートクロックが送信または符号化の前に、かつ/または受信および復号の後にどのように現れ得るかを示し得る。理解され得るように、ハートビートクロックの第1の部分3102はSDA線で送信されるが、ハートビートクロックの第2の部分3104はSCL線で送信され得る。このようにして、ハートビートクロックの一部をSCL線に移すことによって、空間3106がSDA線上に作られる。
【０１２５】
CCIeデバイスに対する第1の例示的な帯域内IRQ技法
図32は、ハートビートクロックがSDA線およびSCL線を通じて送信され得る別の例を示す。この例では、ハートビートクロックの第1の部分3202はSDA線で送信されるが、ハートビートクロックの第2の部分3204はSCL線で送信されてよく、これによって、SDA線上の帯域内IRQのためにより大きい空間3206が生まれる。
【０１２６】
このプロトコルによれば、受信スレーブデバイスは、たとえば、開始Sインジケータ3212の後のn番目のRXCLK 3214を検出し得る。n番目のRXCLK 3214は、内部SDAマスク3224をトリガし、SDA線3226を内部的に(たとえば、受信スレーブデバイス内で)マスクさせ得る。
【０１２７】
n+1 RXCLK 3216において、スレーブデバイスは、SDA線をローに引き込むことによってIRQをトリガすることができる。SDA線はマスターデバイスによって弱くハイに引き込まれるので、(スレーブデバイスによって)ローに引き込まれるとき、このことは帯域内IRQを示すように機能する。すなわち、SDA線をハイに弱く引き込むことによって、このことは、スレーブデバイスが割込み信号をアサートするようにSDA線をローに引き込むことを可能にする。
【０１２８】
n+2 RXCLK 3218において、マスターデバイスは、帯域内IRQがアサートされているかどうかを確かめるために、SDA線をサンプリングすることができる。
【０１２９】
n+3 RXCLK 3220において、スレーブデバイスは、SDA線を解放する(たとえば、帯域内IRQをデアサートする)ことができる。
【０１３０】
n+3 RXCLKとn+4 RXCLKの間、マスターデバイスは、SDAドライバを再び有効にして、SDA線をハイに駆動し始める。これが、受信機デバイス(たとえば、スレーブデバイス)がn+4 RXCLKにおいてSDAマスクを安全に解放できる理由である。
【０１３１】
n+4 RXCLK 3222において、スレーブデバイスは、SDAマスク3224を解放することができる。
【０１３２】
このようにして、IRQは、SDA線上で定義されるIRQ期間3506の間にスレーブデバイスによって送信され得る。
【０１３３】
図33は、遷移番号からシンボル番号への変換の一例を示す。
【０１３４】
シンボルSは、CCIeモードでは制御データバス(たとえば、SDA線およびSCL線)を通じて送信される。一例では、各シンボルは2ビットからなっていてよく、LSBはSCL線に割り当てられMSBはSDA線に割り当てられる。
【０１３５】
一例では、各々の3進の遷移番号Tは次のように定義される。
Sがシンボル順序円において以前の状態から現在の状態へと1つの状態だけ時計回りに遷移するときはT=1である。
Sがシンボル順序円において以前の状態から現在の状態へと2つの状態だけ時計回りに遷移するときはT=2である。
Sがシンボル順序円において以前の状態から現在の状態へと3つの状態だけ時計回りに遷移するときはT=0である。
CCIeモードにおけるデータ制御バスを通じた典型的なデータ送信は、任意の遷移番号を利用し得る。
【０１３６】
図34は、図33のシンボル番号から遷移番号への変換をさらに詳述する。変換は次のように定義され得る。
Sがシンボル順序円において以前の状態から現在の状態へと1つの状態だけ時計回りに遷移するときはT=1である。
Sがシンボル順序円の反対側に以前の状態から現在の状態へと遷移するときはT=2である。
Sがシンボル順序円において以前の状態から現在の状態へと1つの状態だけ反時計回りに遷移するときはT=0である。
T=0または1のときにはSCL線の切替えが常に発生するが、T=2のときはSCL線は切り替えられない。
【０１３７】
図35は、SDA線3502がマスクされる帯域内IRQ期間の間の条件を示す。遷移番号T=2が送信されるときはSCL線3504は切り替わらないので、SDA線3502は、SDA線3502がマスクされる(3508)とき、実際の状態とは無関係に常にハイであると見なされ、シンボルの遷移はない。その結果、T=2がSDAマスク期間3510の間に送信される場合、生成されるクロックRXCLK 3506はない。この理由で、SDA Mask=1の間はT=2は禁止される。
【０１３８】
図36は、図32および図35のSDAマスクの副作用を示す図である。Tが2に等しくない場合でも、SDA線は帯域内IRQ期間の間は常に論理1の状態であると見なされるので、SDA線に対して論理0をもたらすであろう任意の遷移T値が、SDAビットが常に1であると仮定するT[2:0]=010へとエイリアシングされる。
【０１３９】
図37は、3進の数空間内での数空間0x81BD6〜0x81BF0(すなわち、27個のアドレス)を帯域内IRQのために使用されるハートビートが占有することを示す。SDA Mask=1である間にT=2が禁止されておりあらゆる他のTの組合せがT=010にエイリアシングされるという事実は、帯域内IRQをサポートするハートビートワードが1つのアドレスだけを占有するのではなく、実際にはビット19領域の27個のアドレスを占有することを意味する。この特定のハートビートパターンの使用は3進数2222_2222_2222の使用を妨げ、この3進数は16進数で81BF0であり、2ワードのCCIe同期の第1のワードとして非常に有用である。3進数2222_2222_2222がなければ、絶対的な同期は簡単または可能ではないことがある。
【０１４０】
図38は、CCIeモード送信のために図37において使用される3進数のビット19がどのようにマッピングされ得るかの例を示す。この例では、ハートビートは3進数2222_2222_20103に割り当てられ得る。この例では、2222_2222_2xxx3という範囲にある3進数が検出される限り、ハートビートおよび/または帯域内IRQ(たとえば、16進数で0x81BD9)であると解釈され得ることに留意されたい。
【０１４１】
CCIeデバイスに対する第2の例示的な帯域内IRQ技法
図39は、CCIeモードにおいて制御データバスを通じて帯域内IRQを実装するための代替的な技法を示す。この例は、帯域内IRQを実行するために図32において必要とされる受信機クロックRXCLK周期の数を減らす。
【０１４２】
帯域内IRQ期間3906を提供するためのこのプロトコルによれば、受信スレーブデバイスは、たとえば、開始Sインジケータ3912の後にn番目のRXCLK 3914を検出し得る。n番目のRXCLK 3914は、内部SDAマスク3924をトリガし、SDA線を内部的に(たとえば、受信スレーブデバイス内で)マスクさせ得る。
【０１４３】
n+1 RXCLK 3916において、スレーブデバイスは、SDA線をローに引き込むことによってIRQをトリガすることができる。SDA線はマスターデバイスによって弱くハイに引き込まれるので、(スレーブデバイスによって)ローに引き込まれるとき、このことは帯域内IRQを示すように機能する。
【０１４４】
次のクロック周期まで待つのでなく、n+1 RXCLK 3916の間に、しかしn+2 RXCLK 3918の前に、マスターデバイスは、SDA線がローになるかどうか、かつ/またはいつローになるかを確かめるためにSDA線を監視することができ、ローになることは帯域内IRQ要求がアサートされたことを意味する。マスターデバイスによるSDA線のそのような監視は、スレーブデバイスからのあらゆるIRQ要求を非同期的に検出するために、IRQ期間の間にのみ実行されることに留意されたい。
【０１４５】
n+2 RXCLK 3918において、スレーブデバイスは、SDA線を解放する(たとえば、帯域内IRQをデアサートする)ことができる。
【０１４６】
n+2 RXCLKとn+3 RXCLKの間に、マスターデバイスは、SDAドライバを再び有効にすることができ、SDA線をハイに駆動し始める。その結果、受信機(アサートしているスレーブデバイス)は、n+3 RXCLKにおいてSDAマスクを安全に解放することができる。
【０１４７】
n+3 RXCLK 3920において、スレーブデバイスは、SDAマスク3924を解放することができる。このようにして、帯域内IRQは、SDA線上で定義されるIRQ期間3906の間にスレーブデバイスによって送信され得る。
【０１４８】
図40は、SDA線がマスクされる図39の帯域内IRQ期間の間の条件を示す。遷移番号T=2が送信されるときはSCL線4004は切り替わらないので、SDA線4002は、SDA線4002がマスクされる(4008)とき、実際の状態とは無関係に常にハイであると見なされ、シンボルの遷移はない。その結果、T=2がSDAマスク期間4010の間に送信される場合、生成される受信機RXCLK 4006はない。この理由で、SDA Mask=1の間はT=2は禁止される。
【０１４９】
図41は、図39および図40のSDAマスクの副作用を示す。Tが2に等しくない場合でも、SDA線は帯域内IRQ期間の間は常に論理1の状態であると見なされるので、SDA線に対して論理0をもたらすであろう任意の遷移T値が、SDAビットが常に1であると仮定するT[2:0]=010へとエイリアシングされる。
【０１５０】
図42は、3進の数空間内での数空間0x81BBB〜0x81BD5(すなわち、27個のアドレス)を帯域内IRQのために使用されるハートビートが占有することを示す。図32および図39におけるハートビートと同様に、図39〜図41の代替的なハートビートもビット19領域の27個のアドレスを占有する。しかしながら、この代替的なハートビートは2222_2222_2xxxの3進数空間の使用を妨げないので、2222_2222_2222のワードが依然として同期のために利用可能である。このハートビートパターンはまた、より短い帯域内IRQ期間に対応するために非同期的な帯域内IRQ検出回路を使用することをマスターデバイスに要求し、これは大きな犠牲とはならないはずである。
【０１５１】
理想的には、帯域内割込みを実施するためのプロトコルは、帯域内IRQが可能な限り最小限のプロトコルオーバーヘッドで可能な限り頻繁に出され得るように、1つまたは2つのCCIeワード程度に小型であるべきである。たとえば、周期的な帯域内IRQ時間枠が定義され得る。考慮事項の中でもとりわけ、帯域内IRQ期間は、スレーブデバイスによる「飢餓」を防ぐためにバスシステムが低電力モードにあるときであっても利用可能であるべきである。このことに対する1つの解決法は、スレーブデバイスの同期を可能にするために共有制御データバスを通じてマスターデバイスによって定期的に送信されるCCIe「ハートビート」ワード内で帯域内IRQを定義することであり得る。
【０１５２】
図43は、マスターデバイスがアクティブモードにあり電力節約モードにあるときにハートビートがどのように送信され得るかを示す。マスターデバイスがアクティブモード4302にある通常の動作の間、マスターデバイスは、スレーブデバイスが帯域内IRQを出すことを可能にするために、CCIeフレーム4306の間にハートビートワード4608を定期的に送信する。ハートビートワード間隔は、割込み要求を出す機会の不足をスレーブデバイスに感じさせないようなものであり得る。
【０１５３】
マスターデバイスが電力節約モードにあるとき、ハートビート4316も送信されてよく、これによって、電力節約モードの間に帯域内IRQを出す機会を共有バス(たとえば、SDA線4310およびSCL線4312)上のスレーブデバイスに与える。
【０１５４】
マスターデバイスは、マスターデバイスによる電力の節約のために十分遅く、しかし、IRQ信号を出す機会の不足をスレーブデバイスに感じさせないようにするために十分速いレートで、この「ハートビート」CCIeワード4316を送信することができる。この「ハートビート」CCIeワードは、スレーブデバイスがIRQを出せることの、スレーブデバイスに対するインジケータとして機能し得る。「ハートビート」という用語は、アクティブ(アライブ)であり続けるための最小限の機能のための、電力節約モードの間のスレーブデバイスに対する低速クロックを指すために本明細書では使用される。
【０１５５】
図44は、同期ワードとハートビートの組合せを示す。ハートビートワードにはまた、同期ワードシーケンスの2番目のワードという役割がある。2ワードの同期シーケンスは、「SY-」として示されるようなすべて2であるワード2222_2222_2222と、「-NC」として示されるようなハートビートワード2222_2222_1101で開始する。
【０１５６】
バス状態(シンボル)が1(SDA=0、SCL=1)から3(SDA=1、SCL=1)になるとき、「SY-」ワードは、RXデバイスに、START条件のそばの1つの「2」と最後のシンボルの後の1つの「2」とを含む、14個の遷移状態の2を生成させる。
【０１５７】
「-NC」ワードは、RXデバイスに、START条件のそばに1つの「2」を含む9個の遷移状態の2を生成させる。
【０１５８】
「SY-」ワードおよび「-NC」ワードは一緒にされ、または組み合わされて(たとえば、したがって「SYNC」)、「1101」シーケンスが後に続く全体で23個の遷移状態の2をもたらし、これは固有のシーケンスであり、いずれの他のCCIeのトランザクションでも発生し得ない。CCIeデバイスは、このシーケンスを使用してCCIeワードの境界と同期することができる。
【０１５９】
図45は、CCIeプロトコルのビット19内での同期とハートビートのマッピングを示す。42個の数にわたる16進数の数空間0x81BC6〜0x81BEFが、同期のためだけの絶対的に一意である2つのワードパターン「SY-NC」、すなわち23個の「2」と「1101」とを作るために禁止される。マスターデバイスは、同期が喪失した場合にスレーブデバイスが再同期できるようにするために、またはホットプラグされるスレーブをバスに同期させるために、「-NC」ワードであるハートビートの直前に「SY-」ワードを定期的に送信することができる。
【０１６０】
例示的なIRQグループ照会
1つの特徴によれば、各スレーブデバイスは「グループ」を割り当てられてよく、または「グループ」と関連付けられてよく、各「グループ」は1つまたは複数のスレーブデバイスを含む。特定の「グループ」と関連付けられるIRQ信号を検出すると、マスターデバイスは、(たとえば、IRQ信号が制御データバス上で帯域内IRQとしてアサートされるか、専用のIRQバス上で側帯IRQとしてアサートされるかのいずれかの場合に)IRQ信号をアサートしたスレーブデバイスを特定するために、「グループ」中のスレーブデバイスの各々に照会を(たとえば、制御データバスを通じて)送信することができる。IRQをアサートしたスレーブデバイスは、割り当てられたグループ内でのみ照会に応答することができ、これによって、アサートしているスレーブデバイスがマスターデバイスに対して特定される。スレーブデバイスの各「グループ」は1つまたは複数のスレーブデバイスを有し得ることに留意されたい。電力の節約がマスターデバイスによって実施されているとき、スレーブデバイスはハートビートワード内で帯域内割込みを出せることに留意されたい。また、複数のスレーブデバイスが同じハートビートワード内で割込みを出すことができる。
【０１６１】
図46は、例示的なCCIeプロトコル内での割込みグループ照会の一般的な呼出しを示す。マスターデバイスは、一般的な呼出しであるIRQグループ照会4600を共有バス上のすべてのスレーブデバイスにブロードキャストすることができる。IRQグループ照会コマンド4602である16進数の0x0007の後で、複数のIRQグループ照会ワード4604が送信される。一例では、各照会ワードは3個の照会応答スロットを有し、全体ではグループ0からグループ32に対して33個のスロットを有する。一例では、照会ワード4604は、1個から11個のIRQグループ照会ワード(IQ)と、最後に1個の終止ワード(Term)4606とを含み得る。各照会ワード4604に対して、すべてのスレーブデバイスが共有バスのSDA線をマスクする。
【０１６２】
一般的な呼出しのペイロード4604の各IRQグループ照会(IQ)ワード4608において、各スレーブ受信機は、T11 RXCLKにおいてSDAをマスクするのを開始し、ダミー(T-1)RXCLKにおいてマスクを解放しなければならない。
【０１６３】
図47は、グループ照会呼出しに対する応答を示す。この例では、ハートビートをSCL線4710に転送してSDAマスク4712を使用することによって、1つまたは複数の応答期間(すなわち、照会ワード)がSDA線4708上で定義され得る。この例では、3つの別のスロット4702、4704、および4706が、各照会ワード4608(図46)に対して定義されている。各IQワード4608中の3つの時間スロット4702、4704、および4706の各々は、3つの異なるIRQグループに割り当てられ得る。各スロット4702、4704、および4706に割り当てられるスレーブデバイスは、スレーブデバイスがIRQを出したこと、またはサービスされていないIRQを有することを示すための照会応答として、割り当てられたスロット4702、4704、および4706の間にSDA線4708を駆動することができる。各IRQグループ照会(IQ)ワード4608は3つの照会応答スロット4702、4704、および4706を有するので、最大で11個のIRQグループ照会(IQ)ワードが一般的な呼出しのペイロード4604の中にあってよく、1つの呼出しの中に最大で33個のグループスロットがあり得る。
【０１６４】
1つのデバイスだけが1つのグループの中にあるように、最大で32個のデバイスがグループに割り当てられてよく、これによってIRQ発行者が直ちに特定される。この手法は複数のIRQグループを一度に特定し、これによって必要とされるIRQスキャンの数を減らす(たとえば、より少ないIRQネスティング)。代替的に、複数のデバイスが各グループに割り当てられ得るが、グループ中の複数のデバイスのいずれがIRQを出したかを特定するために、追加の照会がマスターデバイスによって必要とされ得る。
【０１６５】
マスターデバイスは、バスシステム上のIRQグループの数に基づいて、一般的な呼出しに含めるべきIRQグループ照会(IQ)ワードの数を選ぶことができる。いくつかの例では、マスターデバイスは、(たとえば、11個という最大の数よりも少ない)より少数の照会ワード4608を送信することができる。これは、IRQグループ照会の一般的な呼出しのための時間の短縮を可能にし得る。
【０１６６】
IRQグループ照会(IQ)ワードのシーケンスは、終止ワード(Term)4606で終了する。終止ワード4606のシンボルパターンは、各受信機のスレーブデバイスが、SDA線4708をマスクするのをいつ止めるべきかということとIRQグループ照会の一般的な呼出しの終了とを知るために、ワードがT11 RXCLKにおいてIRQグループ照会(IQ)ではなく終止(Term)であることを認識できるように、選ばれ得る。
【０１６７】
第1のIRQグループ照会(IQ)に対する3つのスロット4702、4704、および4706は、グループ0、1、および2に割り当てられ得る。より数字の小さいグループがより早い応答スロットに割り当てられ得る。
【０１６８】
一例では、グループ0は、ホットプラグされるデバイス、または共有バス上マスターデバイスがまだ認識していないデバイスのために確保され得る。少なくとも1つのIRQグループ照会(IQ)ワードが送信されなければならないので、IRQを出した任意のホットプラグされるデバイスが常に認識される。
【０１６９】
終止(Term)ワード4606の使用によって、ペイロード4604の長さを柔軟に設定することができ、IRQグループ照会(IQ)ワードシーケンスの長さは必要であれば11ワードを超えることができる。
【０１７０】
図48は、IRQグループ照会の一般的な呼出しの長さ(すなわち、ワードカウント)を柔軟にするためにIRQグループ照会の一般的な呼出しの終わりを示すために使用され得る例示的な「終止ワード」を示す。
【０１７１】
本明細書で説明されるIRQグループ照会方法は、帯域内IRQと側帯IRQの両方に適用可能であり得る。一例では、説明されるIRQグループ照会方法を使用することは、スレーブデバイスのグループを区別するためにIRQアサート期間を使用することを回避する。すなわち、すべてのスレーブデバイスがスキャンされているので、異なる幅の割込み要求を使用してそれらを区別する必要がない。その結果、側帯IRQは今やあらゆる任意の期間を有し得る。スレーブデバイスはもはやIRQ期間に正確に合わせる必要がないので、自走クロックはもはや必要ではない可能性がある。
【０１７２】
加えて、IRQ調整もIRQグループ照会を使用してなくされ得る。マスターデバイスがすべてのグループとその中のスレーブデバイスとをスキャンするので、マスターデバイスは、複数のIRQ発行者を一度に特定することができ、このことは、調停の喪失に対処する必要がもはやないのでスレーブデバイスの論理を簡単にする。
【０１７３】
IRQグループ照会を使用することのスレーブデバイスに対する1つの追加の利益は、プルアップ抵抗からのDC電流のグラウンドへの流出を招き得る、IRQ線のローへの長期間の保持をスレーブデバイスが行う必要がもはやないので、電力の節約になることであり得る。
【０１７４】
例示的なグローバルクロック読取り
CCIeは、ソース同期シンボル遷移クロッキングシステムである。制御データバスを通じてデータを送信するものは、データに埋め込まれるクロックも送信する。I2Cとは異なり、すべてのスレーブデバイスが、クロック情報とともに読取りデータを生成するためにクロックソースを有しなければならない。しかしながら、たとえば、すべてのスレーブデバイスにSDA入力をマスクさせてスレーブデバイスがSDA線を駆動することを可能にさせながらSCL線を常に切り替える、IRQグループ照会のために使用される技法は、実際にはグローバルクロック読取りを達成している。
【０１７５】
図46および図47において理解され得るように、IRQグループ照会ワードは、主に、異なるRXCLKタイミングを伴う複数のスレーブが同じ時間スロット内でSDA線を駆動することを可能にするために、3個のスレーブデバイス応答しか搬送できない。しかしながら、SDAマスクの間に単一のスレーブデバイスだけがSDA線を駆動するのを可能にすることは、ダブルデータレート(DDR)グローバルクロック読取りを実施することを可能にする。
【０１７６】
図49は、DDRグローバルクロック読取りの一般的な呼出しがどのように実施され得るかの一例を示す。DDRグローバルクロック読取りシーケンスを開始する前に、マスターデバイスは次のことを示すいくつかのCCIeプロトコル(一般的な呼出しのような)を出す。
1.後続のシーケンスがDDRグローバルクロック読取りであること
2.DDRグローバルクロック読取りのワードの数
3.データを読み取るべきデバイスのSID
4.データを読み取るべきデバイスのレジスタアドレス
バス上のすべてのデバイスが、(規定された数のワードが送信されるまでの)呼出しの後のすべてのCCIeトランザクションがDDRグローバルクロック読取りであることを理解する。
【０１７７】
DDRグローバルクロックモードでは、バス上のすべてのデバイスが、ワードの終わりにダミーシンボルを含むシンボル期間の間のクロックデータ復元(CDR)回路へのSDA入力をマスクしなければならない。
【０１７８】
アドレス指定されたスレーブデバイスは、(START条件のそばのRXCLKを含まない)2番目のRXCLKにおいてSDA線をローに駆動し、その論理0は、SDA線をサンプリングするためのクロック(SDACLK)を較正するためにマスターデバイスによって使用される。
【０１７９】
3番目のRXCLKから、アドレス指定されたスレーブデバイスは9ビットのデータを連続的に出すことができる。9ビットのデータは、システム要件に応じて、MSBが最初であってもLSBが最初であっても他のフォーマットであってもよい。この期間、マスターデバイスはSCL線上でDDRグローバルクロックを提供し、または駆動する。
【０１８０】
スレーブデバイスは、12番目のRXCLKにおいてSDA線をハイに駆動し、13番目のRXCLKにおいてSDA線を解放する。
【０１８１】
マスターデバイスは、最初のシンボル「3」が送信された後でSDA線を解放し、SDAドライバを有効にして、最後のシンボル「2」の後でSDA線をハイに駆動する。
【０１８２】
マスターは、SDACLKのタイミングにおいてSDA線をサンプリングして、9個の読み取られたデータビットをシフトインする。
【０１８３】
図50は、グローバルクロック読取りワードの例示的なタイミング図を示す。第1のクロック信号SDACLK 5002および第2のクロック信号RXCLK 5004は、マスターデバイス内の内部信号を示す。第2のクロック信号RXCLK5004は、マスターデバイスのクロックデータ復元回路(CDR)によって生成され得る。第1のクロック信号SDACLK5002は、スレーブデバイス信号によって駆動されるときにSDA線5008(これは共有バスの一部である)からデータ値をサンプリングするためにマスターデバイスによって使用され得る、クロック生成回路5006によって生成され得る。第1のクロック信号SDACLK5002は、SDAMASK信号5010が1である(CDRへのSDA線5008の入力がマスクされる)ときにだけ生成され得る。
【０１８４】
グローバルクロック読取り期間の間にSDA線5008を駆動するのはスレーブデバイスなので、バス上のすべてのデバイス(マスターデバイスを含む)がこの期間の間はCDRへのSDA線5008の入力をマスクしなければならず、その期間は、START条件から立ち上がる(5012)第2のクロック信号RXCLKにおいて開始し、ダミーシンボルのそばのワードのための最後のRXCLKの立ち上がり5014において終了する。
【０１８５】
この例では、マスターデバイスは、グローバルクロック読取りワードのために0x5BE75(2010_1010_10103)を送信する。これはグローバルクロック読取りの一般的な呼出しのペイロード部分であるので、共有バス上の各デバイスは、グローバルクロック読取りワードが呼出しメッセージ「6」の後に続くことを知っており、各デバイスはSDAMASK5010をいつ開始して終了すべきかも知っている。
【０１８６】
各デバイスは、次のワードが第1のシンボルにおいて別個の信号パターンを有する「終止」ワードではない限り、次のワードのためのグローバルクロック読取りワードを予期する。
【０１８７】
SDA線5008上のデータ信号はスレーブデバイスのCDRからのRXCLK5016を使用してスレーブデバイスによって駆動されるので、マスターデバイスは、マスターデバイスが十分な準備および保持の時間とともにデータをサンプリングするために、マスターデバイスのCDRからの第2のクロック信号RXCLK5004を「適切に」遅らせなければならない。マスターデバイスは、マスターデバイスがグローバルクロック読取りワードの第2のシンボル(すなわち、T10周期)を送出した後の、グローバルクロック読取りプロトコルごとにスレーブデバイスによって駆動されるSDA線5008の第1の立ち下がりにおける「適切な」遅延を学習する。「較正論理」5018は、T10周期の最初からのSDA線5008の立ち下がりの遅延を測定し、この遅延を使用して「SDACLK遅延」を構成するので、マスターデバイスは、次のシンボルから、スレーブデバイスからのSDA線5008の送信を信頼性をもってサンプリングする。
【０１８８】
帯域内IRQを使用したsI2CデバイスとCCIeデバイスの例示的な共存
図51は、デバイス5102内の共有バス5104でのI2C適合デバイスとCCIe適合デバイスの共存を示し、すべてのマスター/スレーブデバイスが共有バス5104を通じた帯域内割込みを使用する。この例では、I2C適合およびCCIe適合マスターデバイス5108は、共有バス5104上の通信を管理することができる。マスターデバイス5108は、I2CモードとCCIeモードの両方で(すなわち、2つ以上の別個のプロトコルに従って)動作するように構成され得る。I2C適合およびCCIe適合スレーブデバイス5110も、共有バス5104に結合されてよく、I2CモードとCCIeモードの両方で動作するように構成される。I2C適合スレーブデバイス5112も、共有バス5104に結合されてよく、I2Cモードで動作するように構成される。CCIe適合スレーブデバイス5114も、共有バス5104に結合されてよく、CCIeモードで動作するように構成される。
【０１８９】
図52は、共有バス上での図51のマスター/スレーブデバイスの共存を示す。I2C適合およびCCIe適合マスターデバイス5108は、第1のプロトコルモード(たとえば、I2Cモード)5202で最初は動作し得る。スレーブデバイス5110、5112、5114は、マスターデバイス5108または他のスレーブデバイスからのコマンド/送信について共有バスを単に監視することができる(5204)。
【０１９０】
I2C適合およびCCIe適合マスターデバイス5108は、共有バスを通じてエントリ呼出しメッセージを送信することによって、第2のプロトコルモード(たとえば、CCIeモード)への切替えを開始することができる(5208)。すべてのスレーブデバイス5110、5112、および5114は、共有バスを監視し、共有バスがどのように使用されるかについての変更(たとえば、第1のプロトコルモードから第2のプロトコルモードへの変更)としてエントリ呼出しメッセージを認識する。エントリ呼出しは、第1のプロトコルモード(たとえば、I2Cモード)および第2のプロトコルモード(たとえば、CCIeモード)で動作するデバイスがエントリ呼出しを検出および/または復号できるようなものであり得る。I2C & CCIeスレーブ1 5110は、それでもバスを使用することができ、第1のプロトコルモードと第2のプロトコルモードの両方で通信することが可能であるので割込み要求5210aを出すことができる。I2C適合スレーブ2 5112は、バスを使用することができず、第2のプロトコルモード(CCIeモード)で通信することが可能ではないので割込み要求5210bを出すことができない。CCIe適合スレーブ3 5114は、バスを使用することができ、第2のプロトコルモード(CCIeモード)で通信することが可能であるので割込み要求5210cを出すことができる。
【０１９１】
I2C適合およびCCIe適合マスターデバイス5108はその後、共有バス5212を通じてイグジット呼出しメッセージを送信することによって、第1のプロトコルモード(たとえば、I2Cモード)に戻ることができる。すべてのスレーブデバイス5110、5112、および5114は、共有バスを監視し、共有バスがどのように使用されるかについての変更(たとえば、第2のプロトコルモードから第1のプロトコルモードへの変更)としてイグジット呼出しメッセージを認識する。イグジット呼出しは、第1のプロトコルモード(たとえば、I2Cモード)および第2のプロトコルモード(たとえば、CCIeモード)で動作するデバイスがイグジット呼出しを検出および/または復号できるようなものであり得る。I2C & CCIeスレーブ1 5110は、それでもバスを使用することができ、第1のプロトコルモードと第2のプロトコルモードの両方で通信することが可能であるので割込み要求5216aを出すことができる。I2C適合スレーブ2 5112は、バスを使用することができ、第1のプロトコルモード(I2Cモード)で通信することが可能であるので割込み要求5216bを出すことができる。CCIe適合スレーブ3 5114は、バスを使用することができず、第1のプロトコルモード(I2Cモード)で通信することが可能ではないので割込み要求5216cを出すことができない。
【０１９２】
図53は、共有バス上でのCCIe適合スレーブデバイスとの共存を支援する、I2C適合スレーブデバイスによって実行可能な方法を示し、ここで、すべてのデバイスが共有バスを通じた帯域内割込みを使用することができる。第1のスレーブデバイス(たとえば、I2C適合スレーブデバイス)は、共有バスを通じた帯域内割込み要求を含む第1のプロトコルモードに従って動作してよく、共有バスは複数の他のスレーブデバイスと共有される(5302)。共有バスは、第1のプロトコルモードおよび第2のプロトコルモードに従って動作することが可能なマスターデバイスからのエントリ呼出しについて、第1のスレーブデバイスによって監視され得る(5304)。エントリ呼出しを検出すると、第1のスレーブデバイスは、第1のスレーブデバイスが共有バスを通じて第1のプロトコルモードに従って帯域内割込み要求を行うことを無効にし得る(5306)。第1のスレーブデバイスは、マスターデバイスからのイグジット呼出しについて共有バスを監視することができる(5308)。共有バスを通じたマスターデバイスからのイグジット呼出しを検出すると、第1のスレーブデバイスは、第1のスレーブデバイスが帯域内割込み要求を行うことを可能にし得る(5310)。複数の他のスレーブデバイスは、第2のプロトコルモードに従って動作する1つまたは複数のスレーブデバイスを含む。エントリ呼出しは、共有バスが第2のプロトコルモードに従って動作できることを、第2のプロトコルモードで動作する1つまたは複数のスレーブデバイスに示すものとして機能し得る。
【０１９３】
一例では、第1のスレーブデバイスは、処理回路に結合されたバスインターフェースを備え得る。バスインターフェースは、複数の他のスレーブデバイスと共有される共有バスに結合するように機能し得る。処理回路は、(a)複数の他のスレーブデバイスと共有される共有バスを通じた帯域内割込み要求を含む第1のプロトコルモードに従って第1のスレーブデバイスを動作させ、(b)第1のプロトコルモードおよび第2のプロトコルモードに従って動作することが可能なマスターデバイスからのエントリ呼出しについて共有バスを監視し、(c)エントリ呼出しを検出すると、第1のスレーブデバイスが共有バスを通じて第1のプロトコルモードに従って帯域内割込み要求を行うことを無効にし、(d)マスターデバイスからのイグジット呼出しについて共有バスを監視し、かつ/または(e)マスターデバイスからのイグジット呼出しを検出すると、第1のスレーブデバイスが共有バスを通じて帯域内割込み要求を行うことを可能にするように構成され得る。複数の他のスレーブデバイスは、第2のプロトコルモードに従って動作する1つまたは複数のスレーブデバイスを含み得る。エントリ呼出しは、共有バスが第2のプロトコルモードに従って動作できることを、第2のプロトコルモードで動作する1つまたは複数のスレーブデバイスに示すものとして機能し得る。
【０１９４】
図54は、共有バス上でのI2C適合スレーブデバイスとの共存を支援する、CCIe適合スレーブデバイスによって実行可能な方法を示し、ここで、すべてのデバイスが共有バスを通じた帯域内割込みを使用することができる。スレーブデバイスは、複数の他のデバイスと共有される共有バスに結合され、他のデバイスの少なくとも第1のサブセットは第1のプロトコルモードに従って動作し、スレーブデバイスは第2のプロトコルモードに従って動作する(5402)。第1のプロトコルモードおよび第2のプロトコルモードに従って動作することが可能なマスターデバイスからのエントリ呼出しは、共有バスを通じてスレーブデバイスによって検出され得る(5404)。割込み要求(IRQ)は、共有バスを通じて帯域内で、または第2のプロトコルモードに従って別の経路を通じて側帯で、スレーブデバイスによって送信され得る(5406)。エントリ呼出しは、共有バスが第2のプロトコルモードに従って動作できることをスレーブデバイスに示すものとして機能し得る。スレーブデバイスは、第2のプロトコルモードに従って、共有バスを通じてデータまたはコマンドを送信することができる(5408)。
【０１９５】
スレーブデバイスはまた、マスターデバイスからのイグジット呼出しについて共有バスを監視することができる(5410)。マスターデバイスからのイグジット呼出しを検出すると、スレーブデバイスは、共有バスを通じて帯域内割込み要求を行うのを無効にし、または止めることができる(5412)。イグジット呼出しは、共有バスが第1のプロトコルモードに従って動作すべきであることをスレーブデバイスに示すように機能し得る。
【０１９６】
一例では、スレーブデバイスは、処理回路に結合されたバスインターフェースを含み得る。バスインターフェースは、複数の他のデバイスと共有される共有バスに結合するように機能することができ、他のデバイスの少なくとも第1のサブセットは第1のプロトコルモードに従って動作し、スレーブデバイスは第2のプロトコルモードに従って動作する。処理回路は、(a)第1のプロトコルモードおよび第2のプロトコルモードに従って動作することが可能なマスターデバイスからの共有バスを通じたエントリ呼出しを検出し、(b)共有バスを通じて帯域内で、または第2のプロトコルモードに従って別の経路を通じて側帯で、割込み要求(IRQ)を送信し、(c)第2のプロトコルモードに従って共有バスを通じてデータまたはコマンドを送信し、(d)マスターデバイスからのイグジット呼出しについて共有バスを監視し、かつ/または(e)マスターデバイスからのイグジット呼出しを検出すると、スレーブデバイスが共有バスを通じて帯域内割込み要求を行うのを無効にするように構成され得る。
エントリ呼出しは、共有バスが第2のプロトコルモードに従って動作できることをスレーブデバイスに示すものとして機能し得る。イグジット呼出しは、共有バスが第1のプロトコルモードに従って動作すべきであることをスレーブデバイスに示すように機能する。
【０１９７】
同様に、I2C適合デバイスとCCIe適合デバイスが共存でき、一方で両方のタイプのデバイスが共有バスを通じた割込み要求を使用できる、システムが提供される。デバイスの第1のセットが共有バスに結合され得る。デバイスの第2のセットも共有バスに結合され得る。
【０１９８】
デバイスの第1のセット内の第1のデバイスは、(a)共有バスを通じて帯域内割込み要求を送信/受信することを含む第1のプロトコルモードに従って動作し、(b)デバイスの第2のセット中のデバイスからのエントリ呼出しについて共有バスを監視し、かつ/または(c)エントリ呼出しを検出すると、第1のスレーブデバイスが共有バスを通じて帯域内割込み要求を行うことを無効にするように構成され得る。
【０１９９】
デバイスの第2のセット内の第2のデバイスは、(a)第1のプロトコルモードに従って共有バスを通じてエントリ呼出しを検出し、(b)第2のプロトコルモードに従って共有バスを通じて割込み要求(IRQ)を送信し、(c)第2のプロトコルモードに従って共有バスを通じてデータまたはコマンドを送信し、かつ/または(d)イグジット呼出しが共有バス上で検出される場合、第2のプロトコルモードに従って共有バスを通じて帯域内割込みを送信することを無効にするように構成され得る。
【０２００】
マスターデバイスは、共有バスに結合されてよく、(a)共有バス上の通信を管理するために第1のプロトコルモードと第2のプロトコルモードの両方に従って動作し、(b)第1のプロトコルモードに従って共有バスを通じてエントリ呼出しを送信し、(c)第1のプロトコルモードと第2のプロトコルモードの両方に従ってスレーブデバイスからの割込み要求を検出し、かつ/または(d)要求しているスレーブデバイスに共有バスへのアクセスを認めることによって、割込み要求に応答するように構成されてよい。
【０２０１】
例示的なマルチモード共有バスアーキテクチャ
共有バス、第1のスレーブデバイス、第2のスレーブデバイス、および/またはマスターデバイスを備えるデバイスが提供される。第1のスレーブデバイスは、共有バスに結合されてよく、(a)共有バスを通じて帯域内割込み要求を出すことを含む第1のプロトコルモードに従って動作し、(b)共有バスが第2のプロトコルモードに切り替えていることを示すエントリ呼出しについて共有バスを監視し、かつ/または(c)エントリ呼出しを検出すると、第1のスレーブデバイスが共有バスを通じて帯域内割込み要求を行うことを無効にするように構成される。
【０２０２】
第2のスレーブデバイスは、共有バスに結合されてよく、(a)割込みバスを通じて側帯割込み要求を出すこと、または共有バスを通じて帯域内割込み要求を出すことを含む第2のプロトコルモードに従って動作し、かつ/または(b)共有バス上でエントリ呼出しを検出するように構成され、エントリ呼出しは第2のプロトコルモードに従って送信される。
【０２０３】
マスターデバイスは、共有バスに結合されてよく、(a)第1のプロトコルモードと第2のプロトコルモードの両方に従って動作し、(b)共有バス上の通信を管理し、(c)共有バスが第2のプロトコルモードに切り替えていることを示すエントリ呼出しを共有バスを通じて送信し、ここでエントリ呼出しは第1のプロトコルモードに従って送信され、(d)第1のプロトコルモードと第2のプロトコルモードの両方に従ってスレーブデバイスからの割込み要求を検出し、かつ/または(e)要求しているスレーブデバイスに共有バスへのアクセスを認めることによって、割込み要求に応答するように構成されてよい。
【０２０４】
マスターデバイスはさらに、共有バスが第1のプロトコルモードに切り替えていることを示すイグジット呼出しを共有バス上で送信するように構成されてよく、イグジット呼出しは、第2のプロトコルモードと第1のプロトコルモードの両方に従って送信される。
【０２０５】
帯域内割込みのために、第2のプロトコルは、共有バスを通じて送信されるシンボル内で割込み期間を定義し、この割込み期間の間、共有バスに結合された1つまたは複数のスレーブデバイスが共有バスの第1の線の上で割込み要求をアサートでき、一方で共有バスの第2の線がハートビート送信のためにマスターデバイスによって使用される。1つの実装形態では、マスターデバイスおよび第2のスレーブデバイスは、割込み期間の間、共有バスの第1の線を内部的にマスクするように構成され得る。
【０２０６】
マスターデバイスは、共有バス上で第2のプロトコルモードに従って動作するすべてのスレーブデバイスに割込みグループ照会呼出しを送信するように構成されてよく、そのような割込みグループ照会呼出しは、任意のアサートしているスレーブデバイスが応答できる時間枠を提供する。
【０２０７】
第2のスレーブデバイスはさらに、共有バスが第2のプロトコルモードに従って動作するとき、第2のプロトコルモードに従って、共有バスを通じてデータまたはコマンドを受信するように構成され得る。
【０２０８】
第1のスレーブデバイスはさらに、共有バスが第2のプロトコルモードに従って動作する間、共有バスとは別の専用の割込み線またはバスを通じて、割込み要求を送信するように構成され得る。
【０２０９】
デバイスはまた、専用の線を通じて第1のスレーブデバイスから割込み要求を受信し、第2のプロトコルに従って専用の割込み線またはバスを通じて受信された割込み要求を送信するように構成される、割込みルータスレーブデバイスを含み得る。
【０２１０】
一例では、共有バスは第1の線および第2の線を含み得る。共有バスが第1のプロトコルモードに従って動作するとき、第1の線はデータ送信のために使用され、第2の線は第1のクロック信号のために使用される。共有バスが第2のプロトコルモードに従って動作するとき、第1の線と第2の線の両方がデータ送信のために使用され、その間、第2のクロック信号はデータ送信とともにシンボルからシンボルへの遷移に埋め込まれる。
【０２１１】
例示的なマルチモードCCIe/I2Cマスターデバイス
図55は、第1のバスインターフェース5516と、第2のバスインターフェース5518と、処理回路5504とを含み得る例示的なマルチモードマスターデバイス5502を示す。第1のバスインターフェースは、共有制御データバスに結合される他のデバイスに結合するように機能することができ、データバスは、第1のプロトコルモードまたは第2のプロトコルモードのいずれかで動作するように動的に構成される。第2のバスインターフェースは、他のデバイスの少なくともサブセットによって使用される専用の割込み線に結合し、第2のプロトコルモードにおいて専用の割込み線を通じて割込み要求を出すように機能し得る。処理回路は、(a)複数の他のデバイスが結合される共有バスを通じたデータ転送を管理し、ここで他のデバイスの少なくとも第1のサブセットは第1のプロトコルモードに従って動作し、他のデバイスの第2のサブセットは第1のプロトコルモードと両立しない第2のプロトコルモードに従って動作し、(b)(1)共有バスが第2のプロトコルモードに従って動作すべきであることを示すエントリ呼出しを共有バスを通じて送信し、かつ/または(2)共有バスが第1のプロトコルモードに従って動作すべきであることを示すイグジット呼出しを共有バスを通じて送信することによって、第1のプロトコルモードと第2のプロトコルモードとの間で共有バスの動作を動的に切り替えるように構成され得る。
【０２１２】
マスターデバイスはさらに、(a)共有バスが第1のプロトコルモードに従って動作するとき、共有バスを通じてデバイスの第1のサブセットから割込み要求を受信し、(b)共有バスが第2のプロトコルモードに従って動作するとき、専用の割込みバスを通じてデバイスの第2のサブセットから割込み要求を受信し、かつ/または(c)共有バスが第2のプロトコルモードに従って動作するとき、専用の割込みバスを通じてデバイスの第1のサブセットから割込み要求を受信するように構成され得る。1つの実装形態では、共有バスが第2のプロトコルモードに従って動作するとき、デバイスの第1のサブセットから割込み要求は受信されない。
【０２１３】
共有バスは、第1の線と第2の線とを含む。共有バスが第1のプロトコルモードに従って動作するとき、第1の線はデータ送信のために使用され、第2の線は第1のクロック信号のために使用される。共有バスが第2のプロトコルモードに従って動作するとき、第1の線と第2の線の両方がデータ送信のために使用され、その間、第2のクロック信号はデータ送信とともにシンボルからシンボルへの遷移に埋め込まれる。
【０２１４】
第2のプロトコルは、共有バスを通じて送信されるシンボル内で割込み期間を定義することができ、この割込み期間の間、他のデバイスの第2のサブセットが共有バスの第1の線の上で割込み要求をアサートでき、一方で共有バスの第2の線がハートビート送信のためにマスターデバイスによって使用される。
【０２１５】
マスターデバイスはまた、割込み期間の間、共有バスの第1の線を内部的にマスクするように構成され得る。
【０２１６】
1つの実装形態では、第2のプロトコルモードに従って動作しながら帯域内割込み要求に応答して、マスターデバイスは、共有バス上で第2のプロトコルモードに従って動作するすべてのスレーブデバイスに割込みグループ照会呼出しを送信することができ、そのような割込みグループ照会呼出しは、任意のアサートしているスレーブデバイスが応答できる時間枠を提供する。
【０２１７】
例示的なCCIeスレーブデバイス
図56は、バスインターフェース5616と処理回路5604とを備え得る例示的なスレーブデバイス5602を示す。バスインターフェースは、複数の他のデバイスと共有される共有バスに結合するように機能することができ、他のデバイスの少なくとも第1のサブセットは第1のプロトコルモードに従って動作し、スレーブデバイスは第2のプロトコルモードに従って動作する。処理回路は、(a)第1のプロトコルモードおよび第2のプロトコルモードに従って動作することが可能なマスターデバイスからの共有バスを通じたエントリ呼出しを検出し、エントリ呼出しは共有バスが第2のプロトコルモードに従って動作すべきであることを示し、(b)共有バスを通じて帯域内で、またはマスターデバイスへの別の経路を通じて側帯で、割込み要求(IRQ)を送信し、(c)第2のプロトコルモードに従って共有バスを通じて通信し、(d)マスターデバイスからのイグジット呼出しについて共有バスを監視し、かつ/または(e)マスターデバイスからのイグジット呼出しを検出すると、スレーブデバイスが共有バスを通じて通信するのを無効にするように構成され得る。イグジット呼出しは、共有バスが第1のプロトコルモードに従って動作すべきであることをスレーブデバイスに示すように機能し得る。
【０２１８】
共有バスは、第1の線と第2の線とを含み得る。共有バスが第1のプロトコルモードに従って動作するとき、第1の線はデータ送信のために使用され、第2の線は第1のクロック信号のために使用される。共有バスが第2のプロトコルモードに従って動作するとき、第1の線と第2の線の両方がデータ送信のために使用され、その間、第2のクロック信号はデータ送信とともにシンボルからシンボルへの遷移に埋め込まれる。
【０２１９】
例示的なI2Cスレーブデバイス
例示的なCCIeスレーブデバイス1302(図13)は、バスインターフェース1306と処理回路1304とを含み得る。バスインターフェースは、複数の他のデバイスと共有される共有バスに結合するように機能することができ、スレーブデバイスは、第1のプロトコルモードに従って動作し、他のデバイスの少なくとも第1のサブセットは、第2のプロトコルモードに従って動作する。処理回路は、バスインターフェースに結合するように機能し、(a)第1のプロトコルモードおよび第2のプロトコルモードに従って動作することが可能なマスターデバイスからの共有バスを通じたエントリ呼出しを検出し、ここでエントリ呼出しは共有バスが第2のプロトコルモードに従って動作すべきであることを示し、かつ/または(b)エントリ呼出しを検出すると、スレーブデバイスが共有バスを通じて帯域内割込み要求を行うことを無効にするように構成され得る。
【０２２０】
処理回路はさらに、マスターデバイスからのイグジット呼出しについて共有バスを監視するように構成され、イグジット呼出しは、共有バスが第1のプロトコルモードに従って動作すべきであることを示す。共有バスは第1の線および第2の線を含み、共有バスが第1のプロトコルモードに従って動作するとき、第1の線はデータ送信のために使用され、第2の線は第1のクロック信号のために使用され、共有バスが第2のプロトコルモードに従って動作するとき、第1の線と第2の線の両方がデータ送信のために使用され、その間、第2のクロック信号はデータ送信とともにシンボルからシンボルへの遷移に埋め込まれる。
【０２２１】
例示的な割込み要求ルータスレーブデバイス
図57は、第1のバスインターフェース5716と、第2のバスインターフェース5718と、第3のバスインターフェース5720と、処理回路5704とを含み得る例示的な割込み要求ルータスレーブデバイス5702を示す。第1のバスインターフェースは、共有制御データバスに結合するように機能することができ、データバスは、第1のプロトコルモードまたは第2のプロトコルモードのいずれかで動作するように動的に構成される。第2のバスインターフェースは、共有バスに結合される他のスレーブデバイスの少なくとも1つのサブセットに結合するように機能することができ、他のスレーブデバイスのサブセットは、共有制御データバスを通じた帯域内割込み要求を含む第1のプロトコルモードに従って動作する。第3のバスインターフェースは、共有バスを管理するマスターデバイスに割込み要求を出すために、第2のプロトコルモードにおいて使用される専用の割込み線に結合するように機能し得る。処理回路は、(a)スレーブデバイスの第1のサブセット内のあるスレーブデバイスから第2のバスインターフェースを通じて割込み要求を受信し、かつ/または(b)第3のバスインターフェースを介してマスターデバイスに受信された割込み要求をルーティングするように構成され得る。
【０２２２】
図面に示されたコンポーネント、ステップ、特徴、および/または機能の1つまたは複数は、並べ替えられ、かつ/または単一のコンポーネント、ステップ、特徴もしくは機能へと組み合わされてよく、あるいはいくつかのコンポーネント、ステップ、または機能において具現化されてよい。本明細書において開示された新規の特徴から逸脱することなく、さらなる要素、コンポーネント、ステップ、および/または機能も追加され得る。図において示される装置、デバイス、および/またはコンポーネントは、図において説明された方法、特徴、またはステップの1つまたは複数を実行するように構成され得る。本明細書において説明される新規のアルゴリズムはまた、ソフトウェアで効率的に実装され、かつ/またはハードウェアに埋め込まれ得る。
【０２２３】
加えて、実施形態は、フローチャート、フロー図、構造図、またはブロック図として示されるプロセスとして説明され得ることに留意されたい。フローチャートは、動作を順次プロセスとして説明することがあるが、動作の多くは、並列にまたは同時に実行され得る。加えて、動作の順序は並べ替えられ得る。プロセスは、その動作が完了したとき、終了する。プロセスは、方法、関数、手順、サブルーチン、サブプログラムなどに対応し得る。プロセスが関数に対応するときには、その終了は、その関数が、呼出し関数またはメイン関数に戻ることに対応する。
【０２２４】
その上、記憶媒体は、読取り専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリデバイス、および/または情報を記憶するための他の機械可読媒体を含む、データを記憶するための1つまたは複数のデバイスを表し得る。「機械可読媒体」という用語は、限定はされないが、ポータブルのまたは固定式の記憶デバイス、光記憶デバイス、ワイヤレスチャネル、ならびに命令および/またはデータを記憶し、包含し、もしくは搬送することができる様々な他の媒体を含む。
【０２２５】
さらに、実施形態は、ハードウェア、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、またはそれらの任意の組合せによって実装され得る。ソフトウェア、ファームウェア、ミドルウェア、またはマイクロコードで実装される場合、必要なタスクを実行するためのプログラムコードまたはコードセグメントは、記憶媒体または他の記憶装置などの機械可読媒体に記憶され得る。プロセッサは必要なタスクを実行することができる。コードセグメントは、手順、関数、サブプログラム、プログラム、ルーチン、サブルーチン、モジュール、ソフトウェアパッケージ、クラス、または命令、データ構造もしくはプログラムステートメントの任意の組合せを表し得る。コードセグメントは、情報、データ、引数、パラメータ、またはメモリ内容を渡し、かつ/または受け取ることによって、別のコードセグメントまたはハードウェア回路に結合され得る。情報、引数、パラメータ、データなどは、メモリ共有、メッセージの受け渡し、トークンの受け渡し、ネットワーク送信などを含む任意の適切な手段を介して、渡され、転送され、または送信され得る。
【０２２６】
本明細書で開示される例に関して説明される様々な例示的な論理ブロック、モジュール、回路、要素、および/またはコンポーネントは、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)もしくは他のプログラマブル論理コンポーネント、個別ゲートもしくはトランジスタ論理、個別ハードウェアコンポーネント、または本明細書で説明される機能を実行するように設計されたそれらの任意の組合せで実装または実行され得る。汎用プロセッサはマイクロプロセッサであり得るが、代替形態では、プロセッサは、任意の従来型プロセッサ、コントローラ、マイクロコントローラ、または状態機械であり得る。プロセッサはまた、コンピューティングコンポーネントの組合せ、たとえば、DSPとマイクロプロセッサとの組合せ、いくつかのマイクロプロセッサ、DSPコアと連係した1つまたは複数のマイクロプロセッサ、あるいは他の任意のそのような構成として実装され得る。
【０２２７】
本明細書において開示される例に関連して説明される方法またはアルゴリズムは、ハードウェアで直接、プロセッサによって実行可能なソフトウェアモジュールで、またはその両方の組合せで、処理ユニット、プログラミング命令、または他の指示の形で具現化されてよく、単一のデバイスに含まれてよく、または複数のデバイスにわたって分散させられてよい。ソフトウェアモジュールは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーバブルディスク、CD-ROM、または当技術分野で知られている任意の他の形態の記憶媒体に存在し得る。記憶媒体は、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことができるように、プロセッサに結合され得る。代替形態では、記憶媒体はプロセッサと一体であってよい。
【０２２８】
本明細書において開示された実施形態に関連して説明される様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装され得ることを当業者はさらに理解されよう。ハードウェアとソフトウェアとのこの互換性を明確に示すために、種々の例示的なコンポーネント、ブロック、モジュール、回路、およびステップが、これまで概してそれらの機能の観点から説明されてきた。そのような機能がハードウェアとして実装されるか、またはソフトウェアとして実装されるかは、具体的な適用例およびシステム全体に課される設計制約によって決まる。
【０２２９】
本明細書において説明される本発明の様々な特徴は、本発明から逸脱することなく、異なるシステムにおいて実装され得る。上記の実施形態は例にすぎず、本発明を限定するものと解釈すべきではないことに留意されたい。実施形態の説明は、例示的なものであり、特許請求の範囲を限定するものではない。したがって、本教示は、他のタイプの装置に容易に適用することができ、多数の代替、修正、および変形が当業者には明らかであろう。
【符号の説明】
【０２３０】
102  デバイス
104  ベースバンドプロセッサ
106  イメージセンサ
108  制御データバス(SDAおよびSCL)
112  CCIe(I2C)マスターデバイス
114  CCIe(I2C)スレーブデバイス
116  画像データバス
118  I2C/CCIeスレーブデバイス
120  割込み(IRQ)バス
122  sI2Cスレーブデバイス
124  CCIeスレーブデバイス
202  I2Cモード
204  CCIeモード
206  バス
208  I2CおよびCCIeマスターデバイス
210a  I2Cスレーブデバイス
210b  I2Cスレーブデバイス
210c  I2Cスレーブデバイス
210d  I2Cスレーブデバイス
212a  CCIeスレーブデバイス
212b  CCIeスレーブデバイス
302  I2Cモード
304  CCIeモード
306  バス
308a  sI2Cスレーブデバイス
308b  sI2Cスレーブデバイス
310a  CCIeスレーブデバイス
310b  CCIeスレーブデバイス
312a  I2Cスレーブデバイス
312b  I2Cスレーブデバイス
402  元のクロック
404  送信されるべきデータ
406  送信されるシンボル
408  クロック情報
410  元のデータ
502  送信機
504  データビット
508  ビット遷移番号変換器ブロック
510  遷移シンボルブロック
512  SCL線
514  SDA線
516  順次的シンボル
520  受信機
522  順次的シンボル
524  SCL線
526  SDA線
528  クロックデータ復元ブロック
530  シンボル遷移番号変換ブロック
532  遷移番号ビット変換器
602  遷移番号
604  順次的シンボル
606  第1の周期
608  第2の周期
610  第3の周期
612  第4の周期
702  送信:TからS
704  受信:SからT
706  表
802  SDA線
804  SCL線
1004  CCIeエントリモードシーケンス
1006  イグジット
1008  データ書込みプロトコル
1010  データ読取りプロトコル
1012  CDR較正
1014  アドレスワード
1016  データワード
1018  SID
1020  アドレスワード
1022  データワード
1030  一般的な呼出し
1032  CCIeモード
1034  イグジットシーケンス
1102  帯域内割込み信号
1104  SDA線
1204  共有バス
1206  IRQバス
1208  マスターデバイス
1210  sI2C適合スレーブデバイス
1212  線
1214  線
1216  IRQルータCCIeスレーブデバイス
1218  CCIe適合スレーブデバイス
1302  スレーブデバイス
1304  処理/論理回路
1306  送信機および受信機回路
1308  クロック復元回路
1310  共有バス監視回路/モジュール
1312  割込み要求生成回路/モジュール
1314  割込み要求禁止回路/モジュール
1316  IRQ切替え回路
1320  マルチモード共有バス
1322  共有バス
1502  システム
1504  共有制御データバス
1506  共有割込みバス
1508  マスターデバイス
1510a  スレーブデバイス
1510b  スレーブデバイス
1510c  スレーブデバイス
1510d  スレーブデバイス
1510e  スレーブデバイス
1602  グループ1
1604  グループ2
1606  共有割込みバス
1702  第1のグループ
1702  最小バス自由時間
1704  第2のグループ
1706  割込み
1708  割込み
1802  第1のグループ
1804  第2のグループ
1806  第1の割込み信号
1808  第2の割込み信号
1810  割込み信号
1812  IRQNバス自由時間
1902  割込み線
1904  IRQ信号
2002  システム
2004  制御データバス
2008  マスターデバイス
2010a  スレーブデバイス
2010b  スレーブデバイス
2010c  スレーブデバイス
2010d  スレーブデバイス
2010e  スレーブデバイス
2102  SDA線
2104  SCL線
2106  START条件
2108  スレーブID
2200  START条件
2202  START条件
2204  START条件
2502  受信機クロックパルス
2604  帯域内IRQプロトコル
2702  イグジットインジケータ
2704  イグジットインジケータ
2706  帯域内IRQ
2708  エントリ呼出し
3102  第1の部分
3104  第2の部分
3108  受信機クロック
3110  SDA線
3112  SCL線
3202  第1の部分
3204  第2の部分
3206  空間
3212  開始Sインジケータ
3214  n番目のRXCLK
3216  n+1 RXCLK
3218  n+2 RXCLK
3220  n+3 RXCLK
3222  n+4 RXCLK
3224  SDAMASK
3502  SDA線
3504  SCL線
3506  RXCLK
3508  SDAMASK
3510  SDAマスク期間
3906  IRQ期間
3912  開始Sインジケータ
3914  n番目のRXCLK
3916  n+1 RXCLK
3918  n+2 RXCLK
3920  n+3 RXCLK
3924  SDAMASK
4002  SDA線
4004  SCL線
4006  RXCLK
4008  SDAMASK
4010  SDAマスク期間
4302  アクティブモード
4306a  CCIeフレーム
4306b  CCIeフレーム
4306c  CCIeフレーム
4308a  ハートビート
4308b  ハートビート
4308c  ハートビート
4310  SDA線
4312  SCL線
4600  IRQグループ照会
4602  IRQグループ照会コマンド
4604  一般的な呼出しのペイロード
4606  終止ワード
4608  各IRQグループ照会ワード
4702  スロット0
4704  スロット1
4706  スロット2
4708  SDA線
4710  SCL線
4712  SDAMASK
5002  SDACLK
5004  RXCLK
5006  クロック生成回路
5008  SDA線
5010  SDAMASK
5016  RXCLK
5018  較正論理
5102  デバイス
5104  共有バス
5108  I2C適合およびCCIe適合マスターデバイス
5110  I2C適合およびCCIe適合スレーブデバイス
5112  I2C適合スレーブデバイス
5114  CCIe適合スレーブデバイス
5502  マルチモードマスターデバイス
5504  処理回路
5516  第1のバスインターフェース
5518  第2のバスインターフェース
5602  スレーブデバイス
5604  処理回路
5616  バスインターフェース
5702  割込みルータデバイス
5704  処理回路
5716  第1のバスインターフェース
5718  第2のバスインターフェース
5720  第3のバスインターフェース
【図１】
2016538624.tif 000003
【図５３】
2016538624.tif 000004
【図５４】
2016538624.tif 000005
【図５５】
2016538624.tif 000006
【図５６】
2016538624.tif 000007
【図５７】
2016538624.tif 000008
【図２】
2016538624.tif 000009
【図３】
2016538624.tif 000010
【図４】
2016538624.tif 000011
【図５】
2016538624.tif 000012
【図６】
2016538624.tif 000013
【図７】
2016538624.tif 000014
【図８】
2016538624.tif 000015
【図９】
2016538624.tif 000016
【図１０】
2016538624.tif 000017
【図１１】
2016538624.tif 000018
【図１２】
2016538624.tif 000019
【図１３】
2016538624.tif 000020
【図１４】
2016538624.tif 000021
【図１５】
2016538624.tif 000022
【図１６】
2016538624.tif 000023
【図１７】
2016538624.tif 000024
【図１８】
2016538624.tif 000025
【図１９】
2016538624.tif 000026
【図２０】
2016538624.tif 000027
【図２１】
2016538624.tif 000028
【図２２】
2016538624.tif 000029
【図２３】
2016538624.tif 000030
【図２４】
2016538624.tif 000031
【図２５】
2016538624.tif 000032
【図２６】
2016538624.tif 000033
【図２７】
2016538624.tif 000034
【図２８】
2016538624.tif 000035
【図２９】
2016538624.tif 000036
【図３０】
2016538624.tif 000037
【図３１】
2016538624.tif 000038
【図３２】
2016538624.tif 000039
【図３３】
2016538624.tif 000040
【図３４】
2016538624.tif 000041
【図３５】
2016538624.tif 000042
【図３６】
2016538624.tif 000043
【図３７】
2016538624.tif 000044
【図３８】
2016538624.tif 000045
【図３９】
2016538624.tif 000046
【図４０】
2016538624.tif 000047
【図４１】
2016538624.tif 000048
【図４２】
2016538624.tif 000049
【図４３】
2016538624.tif 000050
【図４４】
2016538624.tif 000051
【図４５】
2016538624.tif 000052
【図４６】
2016538624.tif 000053
【図４７】
2016538624.tif 000054
【図４８】
2016538624.tif 000055
【図４９】
2016538624.tif 000056
【図５０】
2016538624.tif 000057
【図５１】
2016538624.tif 000058
【図５２】
2016538624.tif 000059
【手続補正書】
【提出日】平成28年4月11日(2016.4.11)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
共有バスと、
前記共有バスに結合され、
前記共有バスを通じて帯域内割込み要求を出すことを含む第1のプロトコルモードに従って動作し、
前記共有バスが第2のプロトコルモードに切り替えていることを示すエントリ呼出しについて前記共有バスを監視し、
前記エントリ呼出しを検出すると、第1のスレーブデバイスが前記共有バスを通じて帯域内割込み要求を行うことを無効にする
ように構成される、前記第1のスレーブデバイスと、
前記共有バスに結合され、
割込みバスを通じて側帯割込み要求を出すことまたは前記共有バスを通じて帯域内割込み要求を出すことを含む前記第2のプロトコルモードに従って動作し、
前記共有バスで、前記第2のプロトコルモードに従って送信される前記エントリ呼出しを検出する
ように構成される、第2のスレーブデバイスとを備える、デバイス。
【請求項２】
前記共有バスに結合され、
前記第1のプロトコルモードと前記第2のプロトコルモードの両方に従って動作し、
前記共有バスの通信を管理し、
前記共有バスが前記第2のプロトコルモードに切り替えていることを示す前記エントリ呼出しを前記共有バスを通じて送信する
ように構成される、マスターデバイスをさらに備え、前記エントリ呼出しが前記第1のプロトコルモードに従って送信される、請求項1に記載のデバイス。
【請求項３】
前記マスターデバイスがさらに、
前記第1のプロトコルモードと前記第2のプロトコルモードの両方に従って、スレーブデバイスからの割込み要求を検出し、
要求しているスレーブデバイスに対して前記共有バスへのアクセスを許可することによって、前記割込み要求に応答するように構成される、請求項2に記載のデバイス。
【請求項４】
前記マスターデバイスがさらに、
前記共有バスが前記第1のプロトコルモードに切り替えていることを示すイグジット呼出しを前記共有バスで送信するように構成され、前記イグジット呼出しが、前記第2のプロトコルモードと前記第1のプロトコルモードの両方に従って送信される、請求項2に記載のデバイス。
【請求項５】
帯域内割込みのために、前記第2のプロトコルが、前記共有バスを通じて送信されるシンボル内で割込み期間を定義し、前記割込み期間の間、前記共有バスに結合された1つまたは複数のスレーブデバイスが前記共有バスの第1の線の上で割込み要求をアサートでき、一方で前記共有バスの第2の線がハートビート送信のために前記マスターデバイスによって使用される、請求項2に記載のデバイス。
【請求項６】
前記マスターデバイスおよび第2のスレーブデバイスが、前記割込み期間の間、前記共有バスの前記第1の線を内部的にマスクするように構成される、請求項5に記載のデバイス。
【請求項７】
前記マスターデバイスが、前記共有バスで前記第2のプロトコルモードに従って動作するすべてのスレーブデバイスに割込みグループ照会呼出しを送信するように構成され、そのような割込みグループ照会呼出しが、任意のアサートしているスレーブデバイスが応答できる時間枠を提供する、請求項5に記載のデバイス。
【請求項８】
前記第2のスレーブデバイスがさらに、
前記共有バスが前記第2のプロトコルモードに従って動作するとき、前記第2のプロトコルモードに従って、前記共有バスを通じてデータまたはコマンドを受信するように構成される、請求項1に記載のデバイス。
【請求項９】
前記第1のスレーブデバイスがさらに、
前記共有バスが前記第2のプロトコルモードに従って動作する間、前記共有バスとは別の専用の割込み線またはバスを通じて、割込み要求を送信するように構成される、請求項1に記載のデバイス。
【請求項１０】
専用の線を通じて前記第1のスレーブデバイスから割込み要求を受信し、前記第2のプロトコルに従って前記専用の割込み線またはバスを通じて前記受信された割込み要求を送信するように構成される、割込みルータスレーブデバイスをさらに備える、請求項1に記載のデバイス。
【請求項１１】
前記共有バスが第1の線および第2の線を含み、前記共有バスが前記第1のプロトコルモードに従って動作するとき、前記第1の線がデータ送信のために使用され、前記第2の線が第1のクロック信号のために使用され、前記共有バスが前記第2のプロトコルモードに従って動作するとき、前記第1の線と第2の線の両方がデータ送信のために使用され、その間、第2のクロック信号が前記データ送信とともにシンボルからシンボルへの遷移に埋め込まれる、請求項1に記載のデバイス。
【請求項１２】
共有バスに結合される他のデバイスに結合するための第1のバスインターフェースであって、前記共有バスが、第1のプロトコルモードまたは第2のプロトコルモードのいずれかで動作するように動的に構成される、第1のバスインターフェースと、
前記他のデバイスの少なくともサブセットによって使用される専用の割込み線に結合し、前記第2のプロトコルモードにおいて前記専用の割込み線を通じて割込み要求を出すための、第2のバスインターフェースと、
前記第1のバスインターフェースと前記第2のバスインターフェースとに結合され、
複数の前記他のデバイスが結合される前記共有バスでのデータ転送を管理し、ここで、前記他のデバイスの少なくとも第1のサブセットが前記第1のプロトコルモードに従って動作し、前記他のデバイスの第2のサブセットが前記第1のプロトコルモードとは両立しない前記第2のプロトコルモードに従って動作し、
前記共有バスが前記第2のプロトコルモードに従って動作すべきであることを示すエントリ呼出しを前記共有バスを通じて送信すること、および/または、
前記共有バスが前記第1のプロトコルモードに従って動作すべきであることを示すイグジット呼出しを前記共有バスを通じて送信すること
によって、前記第1のプロトコルモードと第2のプロトコルモードとの間で前記共有バスの動作を動的に切り替える
ように構成される、処理回路とを備える、マルチモードマスターデバイス。
【請求項１３】
前記処理回路がさらに、
前記共有バスが前記第1のプロトコルモードに従って動作するとき、前記共有バスを通じてデバイスの前記第1のサブセットから割込み要求を受信するように構成される、請求項12に記載のマスターデバイス。
【請求項１４】
前記処理回路がさらに、
前記共有バスが前記第2のプロトコルモードに従って動作するとき、専用の割込みバスを通じてデバイスの前記第2のサブセットから割込み要求を受信するように構成される、請求項12に記載のマスターデバイス。
【請求項１５】
前記処理回路がさらに、
前記共有バスが前記第2のプロトコルモードに従って動作するとき、前記専用の割込みバスを通じてデバイスの前記第1のサブセットから割込み要求を受信するように構成される、請求項12に記載のマスターデバイス。
【請求項１６】
前記共有バスが前記第2のプロトコルモードに従って動作するとき、デバイスの前記第1のサブセットから割込み要求が受信されない、請求項12に記載のマスターデバイス。
【請求項１７】
前記共有バスが第1の線および第2の線を含み、前記共有バスが前記第1のプロトコルモードに従って動作するとき、前記第1の線がデータ送信のために使用され、前記第2の線が第1のクロック信号のために使用され、前記共有バスが前記第2のプロトコルモードに従って動作するとき、前記第1の線と第2の線の両方がデータ送信のために使用され、その間、第2のクロック信号が前記データ送信とともにシンボルからシンボルへの遷移に埋め込まれる、請求項12に記載のマスターデバイス。
【請求項１８】
前記第2のプロトコルが、前記共有バスを通じて送信されるシンボル内で割込み期間を定義し、前記割込み期間の間、前記他のデバイスの前記第2のサブセットが前記共有バスの第1の線の上で割込み要求をアサートでき、一方で前記共有バスの第2の線がハートビート送信のために前記マスターデバイスによって使用される、請求項12に記載のマスターデバイス。
【請求項１９】
前記処理回路がさらに、前記割込み期間の間、前記共有バスの前記第1の線を内部的にマスクするように構成される、請求項18に記載のマスターデバイス。
【請求項２０】
前記第2のプロトコルモードに従って動作しながら帯域内割込み要求に応答して、前記マスターデバイスが、前記共有バスで前記第2のプロトコルモードに従って動作するすべてのスレーブデバイスに割込みグループ照会呼出しを送信し、そのような割込みグループ照会呼出しが、任意のアサートしているスレーブデバイスが応答できる時間枠を提供する、請求項12に記載のマスターデバイス。
【請求項２１】
スレーブデバイスであって、
複数の他のデバイスと共有される共有バスに結合するためのバスインターフェースであって、前記他のデバイスの少なくとも第1のサブセットが第1のプロトコルモードに従って動作し、前記スレーブデバイスが第2のプロトコルモードに従って動作する、バスインターフェースと、
前記バスインターフェースに結合され、
前記第1のプロトコルモードおよび前記第2のプロトコルモードに従って動作することが可能なマスターデバイスからのエントリ呼出しを前記共有バスを通じて検出し、前記エントリ呼出しが、前記共有バスが前記第2のプロトコルモードに従って動作すべきであることを示し、
前記共有バスを通じて帯域内で、または、前記マスターデバイスへの別の経路を通じて側帯で、割込み要求(IRQ)を送信する
ように構成される、処理回路とを備える、スレーブデバイス。
【請求項２２】
前記処理回路がさらに、
前記第2のプロトコルモードに従って前記共有バスを通じて通信するように構成される、請求項21に記載のスレーブデバイス。
【請求項２３】
前記処理回路がさらに、
前記マスターデバイスからのイグジット呼出しについて前記共有バスを監視し、
前記マスターデバイスからの前記イグジット呼出しを検出すると、前記スレーブデバイスが前記共有バスを通じて通信することを無効にするように構成される、請求項21に記載のスレーブデバイス。
【請求項２４】
前記イグジット呼出しが、前記共有バスが前記第1のプロトコルモードに従って動作すべきであることを前記スレーブデバイスに示すように機能する、請求項21に記載のスレーブデバイス。
【請求項２５】
前記共有バスが第1の線および第2の線を含み、前記共有バスが前記第1のプロトコルモードに従って動作するとき、前記第1の線がデータ送信のために使用され、前記第2の線が第1のクロック信号のために使用され、前記共有バスが前記第2のプロトコルモードに従って動作するとき、前記第1の線と第2の線の両方がデータ送信のために使用され、その間、第2のクロック信号が前記データ送信とともにシンボルからシンボルへの遷移に埋め込まれる、請求項21に記載のスレーブデバイス。
【請求項２６】
スレーブデバイスであって、
複数の他のデバイスと共有される共有バスに結合するためのバスインターフェースであって、前記スレーブデバイスが、第1のプロトコルモードに従って動作し、前記他のデバイスの少なくとも第1のサブセットが、第2のプロトコルモードに従って動作する、バスインターフェースと、
前記バスインターフェースに結合され、
前記第1のプロトコルモードおよび前記第2のプロトコルモードに従って動作することが可能なマスターデバイスからのエントリ呼出しを前記共有バスを通じて検出し、前記エントリ呼出しが、前記共有バスが前記第2のプロトコルモードに従って動作すべきであることを示し、
前記エントリ呼出しを検出すると、前記スレーブデバイスが前記共有バスを通じて帯域内割込み要求を出すことを無効にする
ように構成される、処理回路とを備える、スレーブデバイス。
【請求項２７】
前記処理回路がさらに、
前記マスターデバイスからのイグジット呼出しについて前記共有バスを監視するように構成され、前記イグジット呼出しが、前記共有バスが前記第1のプロトコルモードに従って動作すべきであることを示す、請求項26に記載のスレーブデバイス。
【請求項２８】
前記共有バスが第1の線および第2の線を含み、前記共有バスが前記第1のプロトコルモードに従って動作するとき、前記第1の線がデータ送信のために使用され、前記第2の線が第1のクロック信号のために使用され、前記共有バスが前記第2のプロトコルモードに従って動作するとき、前記第1の線と第2の線の両方がデータ送信のために使用され、その間、第2のクロック信号が前記データ送信とともにシンボルからシンボルへの遷移に埋め込まれる、請求項26に記載のスレーブデバイス。
【国際調査報告】
2016538624.tif 000060
2016538624.tif 000061