(57)【要約】      （修正有）【課題】より高いデータレートのための信号プロトコルおよびインターフェイスの生成および実行を実現する。【解決手段】ディジタル制御および提示データの予め選択された組を通信する通信プロトコルを形成するために一緒にリンクされたパケット構造を使用して、ディジタルデータをホストとクライアントとの間で通信リンクによって転送するためのデータインターフェイス。信号プロトコルは、通信プロトコルを形成しているパケットを生成、送信、受信するように、およびディジタルデータをデータパケットの１つ以上のタイプに形成するように構成されたリンク制御装置によって使用され、少なくとも１つのリンク制御装置が、ホストデバイス内に存在し、通信経路によってクライアントに結合される。インターフェイスは、短距離の“直列”型データリンクによって、コスト効率が良く、低電力で、双方向で、高速のデータ転送機構を与える。【選択図】図５
2011176810.tif 000002
【特許請求の範囲】
【請求項１】
ディジタル提示データを高レートでホストデバイスとクライアントデバイスとの間で通信経路によって転送するディジタルデータインターフェイスであって、
ディジタル制御および提示データの予め選択された組をホストとクライアントとの間で前記通信経路によって通信するための通信プロトコルを形成するために一緒にリンクされた複数のパケット構造と、
前記通信経路によって前記クライアントに結合された前記ホストデバイス内に存在していて、前記通信プロトコルを形成しているパケットを生成、送信、受信するように、およびディジタル提示データをデータパケットの１つ以上のタイプへ形成するように構成された少なくとも１つのリンク制御装置とを含むディジタルデータインターフェイス。
【請求項２】
前記ホストとクライアントとの間で通信され、予め定義された固定長をもち、異なる可変長をもつ所定数の前記パケットをもつ媒体フレーム内で一緒にグループ化された前記パケットをさらに含む請求項１記載のインターフェイス。
【請求項３】
前記ホストからのパケットの転送の始めに置かれたサブフレームヘッダパケットをさらに含む請求項１記載のインターフェイス。
【請求項４】
前記リンク制御装置が、ホストリンク制御装置であり、前記通信経路によって前記ホストに結合された前記クライアントデバイス内に存在していて、前記通信プロトコルを形成しているパケットを生成、送信、受信するように、およびディジタル提示データをデータパケットの１つ以上のタイプへ形成するように構成された少なくとも１つのクライアントリンク制御装置をさらに含む請求項１記載のインターフェイス。
【請求項５】
クライアントのユーザへ提示するために、順方向リンクによって前記ホストから前記クライアントへデータを転送するための、ビデオタイプデータのための１つ以上のビデオストリームパケットと、オーディオタイプデータのためのオーディオストリームパケットとをさらに含む請求項１記載のインターフェイス。
【請求項６】
各転送モードが、所与の時間期間において異なる最大数のビットのデータを並列に転送することを可能にし、各転送モードが、前記ホストおよびクライアントのリンクドライバ間のネゴシエーションによって選択可能である複数の転送モードをさらに含み、
前記転送モードが、データ転送中に、前記モード間で動的に調整可能である請求項２記載のインターフェイス。
【請求項７】
カラーマップ、ビットブロック転送、ビットマップ区域充填、ビットマップパターン充填、および透明色イネーブルタイプパケットのグループから選択されたビデオ情報を転送するのに使用可能な複数のパケットをさらに含む請求項１記載のインターフェイス。
【請求項８】
データをもたない順方向リンク伝送の期間を占有するための、前記ホストによって生成されるフィラータイプパケットをさらに含む請求項１記載のインターフェイス。
【請求項９】
インターフェイス−ユーザ定義データを転送するユーザ定義ストリームタイプパケットをさらに含む請求項１記載のインターフェイス。
【請求項１０】
前記ホストによって前記クライアントへ伝送し、前記通信経路による何れか方向におけるデータ転送も終了するためのリンク遮断タイプパケットをさらに含む請求項１記載のインターフェイス。
【請求項１１】
前記クライアントが前記ホストを休止状態から起動する手段をさらに含む請求項１記載のインターフェイス。
【請求項１２】
ユーザに提示するために、ディジタル提示データを高レートでホストデバイスとクライアントデバイスとの間で通信経路によって転送する方法であって、
複数の予め定義されたパケット構造の１つ以上を生成し、それらを一緒にリンクして、予め定義された通信プロトコルを生成することと、
前記通信プロトコルを使用して、ディジタル制御および提示データの予め選択された組を前記ホストと前記クライアントのデバイス間で前記通信経路によって通信することと、
前記ホストデバイス内に存在する少なくとも１つのホストリンク制御装置を前記通信経路によって前記クライアントデバイスに結合することであって、ホストリンク制御装置が前記通信プロトコルを形成しているパケットを生成、送信、受信するように、およびディジタル提示データをデータパケットの１つ以上のタイプへ形成するように構成されていることと、
前記リンク制御装置を使用して、データをパケットの形で前記通信経路によって転送することとを含む方法。
【請求項１３】
前記ホストとクライアントとの間で通信するための前記媒体フレーム内で前記パケットを一緒にグループ化することをさらに含み、媒体フレームが、予め定義された固定長をもち、異なる可変長をもつ所定数の前記パケットをもつ請求項１２記載の方法。
【請求項１４】
前記ホストからのパケットの転送をサブフレームヘッダタイプパケットで開始することをさらに含む請求項１２記載の方法。
【請求項１５】
情報を前記ホストとクライアントとの間で双方向で前記通信リンクによって転送することをさらに含む請求項１２記載の方法。
【請求項１６】
前記通信経路によって前記ホストデバイスに結合された前記クライアントデバイス内に存在していて、前記通信プロトコルを形成しているパケットを生成、送信、受信するように、およびディジタル提示データをデータパケットの１つ以上のタイプへ形成するように構成された少なくとも１つのリンク制御装置をさらに含む請求項１２記載の方法。
【請求項１７】
前記ホストリンク制御装置が、１つ以上の差動ラインドライバを含み、前記クライアントリンク制御装置が、前記通信経路に結合された１つ以上の差動ライン受信機を含む請求項１６記載の方法。
【請求項１８】
ホストリンク制御装置によってクライアントからディスプレイ能力情報を要求して、前記クライアントが前記インターフェイスによって何れのタイプのデータおよびデータレートに適応できるかを判断することをさらに含む請求項１２記載の方法。
【請求項１９】
前記リンク制御装置の各々によって、ＵＳＢデータインターフェイスを、前記通信経路の一部として動作することをさらに含む請求項１２記載の方法。
【請求項２０】
前記パケットが、それぞれ、パケット長フィールド、１つ以上のパケットデータフィールド、および巡回冗長検査フィールドを含む請求項１２記載の方法。
【請求項２１】
前記ホストとクライアントのリンクドライバ間で各方向における複数の転送モードの使用をネゴシエートし、各転送モードが所与の時間期間において異なる最大数のビットのデータを並列に転送することを可能にすることと、
データ転送中に前記転送モード間で動的に調節することとをさらに含む請求項１３記載の方法。
【請求項２２】
複数のパケットの１つ以上を使用して、カラーマップ、ビットブロック転送、ビットマップ区域充填、ビットマップパターン充填、および透明色イネーブルタイプパケットのグループから選択されたビデオ情報を転送することをさらに含む請求項１２記載の方法。
【請求項２３】
前記ホストによってフィラータイプパケットを生成し、データをもたない順方向リンク伝送の期間を占有することをさらに含む請求項１２記載の方法。
【請求項２４】
前記ホストによって前記クライアントへ伝送するリンク遮断タイプパケットを使用して、前記通信経路による何れの方向におけるデータ転送も終了することをさらに含む請求項１２記載の方法。
【請求項２５】
前記クライアントとの通信によって休止状態から前記ホストを起動することをさらに含む請求項１２記載の方法。
【請求項２６】
ユーザに提示するために、ディジタル提示データを高レートでホストデバイスとクライアントデバイスとの間で通信経路によって転送する装置であって、
１つ以上の複数の予め定義されたパケット構造を生成し、それらを一緒にリンクして、予め定義された通信プロトコルを生成するため、および前記通信プロトコルを使用して、ディジタル制御および提示データの予め選択された組を前記ホストと前記クライアントのデバイスの間で前記通信経路によって通信するための、前記ホストデバイス内に配置された少なくとも１つのホストリンク制御装置と、
前記クライアントデバイス内に配置され、前記通信経路によって前記ホストリンク制御装置に結合された少なくとも１つのクライアント制御装置とを含み、
各リンク制御装置が、前記通信プロトコルを形成しているパケットを生成、送信、受信するように、およびディジタル提示データをデータパケットの１つ以上のタイプへ形成するように構成されている装置。
【請求項２７】
前記ホスト制御装置が状態機械を含む請求項２６記載の装置。
【請求項２８】
前記ホスト制御装置が汎用信号プロセッサを含む請求項２６記載の装置。
【請求項２９】
前記ホストからパケットの転送の始めにサブフレームヘッダタイプパケットをさらに含む請求項２６記載の装置。
【請求項３０】
前記リンク制御装置が、情報を前記ホストとクライアントのデバイス間で双方向で前記通信リンクによって転送するように構成されている請求項２６記載の装置。
【請求項３１】
前記ホスト制御装置が、１つ以上の差動ラインドライバを含み、前記クライアント受信機が、前記通信経路に結合された１つ以上の差動ライン受信機を含む請求項３０記載の装置。
【請求項３２】
クライアントのユーザへ提示するために前記ホストから前記クライアントへデータを転送するときに、ビデオタイプデータのためのビデオストリームタイプパケットと、オーディオタイプのためのオーディオストリームタイプパケットとをさらに含む請求項２６記載の装置。
【請求項３３】
前記クライアントから前記ホストへデータを転送するための１つ以上の逆方向リンクカプセル化タイプパケットをさらに含む請求項２６記載の装置。
【請求項３４】
表示または提示能力をクライアントリンク制御装置から前記ホストリンク制御装置へ通信するための少なくとも１つのディスプレイ能力タイプパケットをさらに含む請求項３３記載の装置。
【請求項３５】
前記パケットが、それぞれ、パケット長フィールド、１つ以上のパケットデータフィールド、および巡回冗長検査フィールドを含む請求項２６記載の装置。
【請求項３６】
前記ホストおよびクライアントリンク制御装置が、各方向において複数の転送モードの１つを使用するように構成されていて、各転送モードが、所与の時間期間において異なる最大数のビットのデータを並列に転送することを可能にし、データ転送中に前記転送モード間で動的に調整することができる請求項２６記載の装置。
【請求項３７】
カラーマップ、ビットブロック転送、ビットマップ区域充填、ビットマップパターン充填、および透明色イネーブルタイプパケットのグループから選択されたビデオ情報を転送する複数のパケットの１つ以上をさらに含む請求項２６記載の装置。
【請求項３８】
データをもたない順方向リンク伝送期間を占有するために、前記ホストによって転送するためのフィラータイプパケットをさらに含む請求項２６記載の装置。
【請求項３９】
前記ホスト制御装置が、前記クライアントへリンク遮断タイプパケットを伝送して、前記通信経路による何れの方向におけるデータ転送も終了するように構成されている請求項２６記載の装置。
【請求項４０】
ユーザに提示するために、ディジタルデータを高レートでホストデバイスとクライアントデバイスとの間で通信経路によって転送する電子システムにおいて使用するための、    コンピュータシステム上でアプリケーションプログラムを実行させるために、コンピュータ読み出し可能プログラムコード手段を自分の中に組込んだコンピュータ使用可能媒体を含むコンピュータプログラムプロダクトであって、前記コンピュータ読み出し可能プログラムコード手段が、
コンピュータシステムに、複数の予め定義されたパケット構造の１つ以上を生成させ、それらを一緒にリンクして、予め定義された通信プロトコルを形成させるコンピュータ読み出し可能な第１のプログラムコード手段と、
コンピュータシステムに、前記通信プロトコルを使用して、ディジタル制御および提示データの予め選択された組を前記ホストと前記クライアントのデバイスとの間で前記通信経路によって通信させるコンピュータ読み出し可能な第２のプログラムコード手段と、    コンピュータシステムに、前記通信経路によって、前記ホストデバイス内に配置された少なくとも１つのホストリンク制御装置を、前記クライアントデバイス内に配置された少なくとも１つのクライアント制御装置に結合させるコンピュータ読み出し可能な第３のプログラムコード手段であって、リンク制御装置が、前記通信プロトコルを形成しているパケットを生成、送信、受信するように、およびディジタル提示データをデータパケットの１つ以上のタイプへ形成するように構成されているコンピュータ読み出し可能な第３のプログラムコード手段と、
コンピュータシステムに、前記リンク制御装置を使用して、データをパケットの形で前記通信経路によって転送させるコンピュータ読み出し可能な第４のプログラムコード手段とを含むコンピュータプログラムプロダクト。
【請求項４１】
ユーザに提示するために、ディジタルデータを高レートでホストデバイスとクライアントデバイスとの間で通信経路によって転送する装置であって、
複数の予め定義されたパケット構造の１つ以上を生成し、それらを一緒にリンクして、予め定義された通信プロトコルを形成する手段と、
前記通信プロトコルを使用して、ディジタル制御および提示データの予め選択された組を前記ホストと前記クライアントのデバイス間で前記通信経路によって通信する手段と、
前記ホストおよびクライアントの各々に１つずつ、少なくとも２つのリンク制御装置を前記通信経路によって一緒に結合する手段であって、各リンク制御装置が、前記通信プロトコルを形成しているパケットを生成、送信、受信するように、およびディジタル提示データをデータパケットの１つ以上のタイプへ形成するように構成されている手段と、    前記リンク制御装置を使用して、データをパケットの形で前記通信経路によって転送する手段とを含む装置。
【請求項４２】
前記ホストからのパケットの転送をサブフレームヘッダタイプパケットで開始する手段をさらに含む請求項４１記載の装置。
【請求項４３】
情報を前記ホストとクライアントとの間で双方向で前記通信リンクによって転送する手段をさらに含む請求項４１記載の装置。
【請求項４４】
ホストリンク制御装置によってクライアントからディスプレイ能力情報を要求して、前記クライアントが前記インターフェイスによって何れのタイプのデータおよびデータレートに適応できるのかを判断する手段をさらに含む請求項４１記載の装置。
【請求項４５】
少なくとも１つのディスプレイ能力タイプパケットを使用して、表示または提示能力をクライアントリンク制御装置から前記ホストリンク制御装置へ通信する手段をさらに含む請求項４１記載の装置。
【請求項４６】
各方向における複数の転送モードの１つの使用を前記ホストとクライアントのリンクドライバ間でネゴシエートする手段であって、各転送モードが所与の時間期間において異なる最大数のビットのデータを並列に転送することを可能にする手段と、
データ転送中に前記転送モード間で動的に調節する手段とをさらに含む請求項４２記載の装置。
【請求項４７】
複数のパケットの１つ以上を使用して、カラーマップ、ビットブロック転送、ビットマップ区域充填、ビットマップパターン充填、および透明色イネーブルタイプパケットのグループから選択されたビデオ情報を転送することをさらに含む請求項４１記載の装置。
【請求項４８】
ディジタルデータを高レートでホストデバイスとクライアントデバイスとの間で通信経路によって転送する電子システムにおいて使用するためのプロセッサであって：複数の予め定義されたパケット構造の１つ以上を生成し、それらを一緒にリンクして、予め定義された通信プロトコルを形成し；ディジタル提示データをデータパケットの１つ以上のタイプへ形成し；前記通信プロトコルを使用して、ディジタル制御および提示データの予め選択された組を前記ホストと前記クライアントのデバイス間で前記通信経路によって通信し；データをパケットの形で前記通信経路によって転送するように構成されたプロセッサ。
【請求項４９】
ディジタルデータを高レートでホストデバイスとクライアントデバイスとの間で通信経路によって転送する電子システムにおいて同期を得るときに使用する状態機械であって、少なくとも１つの非同期フレーム状態の同期状態、少なくとも２つの同期獲得状態の同期状態、および少なくとも３つの同期状態の同期状態をもつように構成された状態機械。
【請求項５０】
ディジタルデータを高レートでホストデバイスとクライアントデバイスとの間で通信経路によって転送する電子システムにおいて同期を得るときに使用する状態機械であって、少なくとも１つの同期獲得状態の同期状態と、少なくとも２つの同期状態の同期状態とをもつように構成された状態機械。
【請求項５１】
同期獲得状態と第１の同期状態との間をシフトする１つの条件が、通信リンクにおける同期パターンの存在を検出することである請求項５０記載の状態機械。
【請求項５２】
同期獲得状態と第１の同期状態との間をシフトする第２の条件が、フレーム境界においてサブフレームヘッダパケットおよび好適なＣＲＣ値の存在を検出することである請求項５１記載の状態機械。
【請求項５３】
第１の同期状態と同期獲得状態との間をシフトする１つの条件が、サブフレーム境界において非同期パターンまたは不適当なＣＲＣ値の存在を検出することである請求項５０記載の状態機械。
【請求項５４】
第１の同期状態と第２の同期状態との間をシフトする１つの条件が、サブフレーム境界において非同期パターンまたは不適当なＣＲＣ値の存在を検出することである請求項５０記載の状態機械。
【請求項５５】
同期獲得状態と第１の同期状態との間をシフトする１つの条件が、通信リンクにおける同期パターンの存在を検出することと、好適なパケットのＣＲＣ値の存在を検出することである請求項５０記載の状態機械。
【請求項５６】
第１の同期状態と同期獲得状態との間をシフトする条件が、パケット内に不適当なＣＲＣ値の存在を検出することである請求項５０記載の状態機械。
【請求項５７】
ディジタルデータを高レートでホストデバイスとクライアントデバイスとの間で通信経路によって転送する電子システムにおいて同期を得るのに使用するための状態機械であって、状態機械が、少なくとも１つの同期獲得状態の同期状態と、少なくとも２つの同期状態の同期状態とをもつように構成され、第１の同期状態と同期獲得状態との間を直接にシフトする条件が、一連のパケットの何れかに不適当なＣＲＣ値の存在を検出することである状態機械。
【請求項５８】
第１の同期状態と同期獲得状態との間を直接にシフトする条件が、ユニークワードが、それが到達すると予測されるときに現れないときを検出することである請求項５７記載の状態機械。
【請求項５９】
前記ホストによって、少なくとも１０クロックサイクルの間、データラインをハイ状態に駆動し、データラインがゼロであるかのように、ストローブ信号を伝送し始めることによって、通信リンクを起動することをさらに含む請求項２６記載の方法。
【請求項６０】
ホストが１５０クロックサイクルの間データラインをハイに駆動した後で、前記ホストによって５０クロックサイクルの間データラインをローに駆動し、一方で、ストローブ信号を伝送し続けることをさらに含む請求項５９記載の方法。
【請求項６１】
前記ホストによって第１のサブフレームヘッダパケットを伝送し始めることをさらに含む請求項５９記載の方法。
【請求項６２】
前記クライアントによって、ハイであるデータラインの少なくとも１５０連続クロックサイクルと、その後のローであるデータラインの少なくとも５０連続クロックサイクルをカウントすることをさらに含む請求項６０記載の方法。
【請求項６３】
前記クライアントによって第１のサブフレームのユニークワードをサーチすることをさらに含む請求項６２記載の方法。
【請求項６４】
クライアントがハイであるデータの７０連続クロックサイクルをカウントした後で、前記クライアントによってデータラインをハイに駆動することを止めることをさらに含む請求項６０記載の方法。
【請求項６５】
前記クライアントによって、ハイであるデータラインの別の８０連続クロックサイクルをカウントして、ハイであるデータラインの１５０クロックサイクルに到達し、ローであるデータラインの５０クロックサイクルを探し、ユニークワードを探すことをさらに含む請求項６４記載の方法。
【請求項６６】
逆方向タイミングパケットの間、立ち上り端と立ち下がり端との両者の上でデータラインをサンプリングすることによって、１が前記ホストによってサンプリングされるまで行われるクロックサイクル数をカウントすることをさらに含む請求項２６記載の方法。
【請求項６７】
ディジタルデータがＣＲＣ値をもつパケットの形でホストデバイスとクライアントデバイスとの間で通信経路によって転送される通信システムにおいて、誤りコードを転送する方法であって、誤りの存在を検出することと、前記誤りに対応する所定の誤りコードを選択することと、ＣＲＣ値を前記コードで上書きすることとを含む方法。
【請求項６８】
転送される連続するパケット内の前記ＣＲＣ値を、前記誤りが訂正されるまで上書きすることをさらに含む請求項６７記載の方法。
【請求項６９】
ユーザに提示するために、ディジタルデータを高レートでホストデバイスとクライアントデバイスとの間で通信経路によって転送する方法であって、
各々が少なくとも１つのＣＲＣフィールドを含む複数の予め定義されたパケット構造の１つ以上を生成し、それらを一緒にリンクして、予め定義された通信プロトコルを形成することと、
前記通信プロトコルを使用して、ディジタル制御および提示データの予め選択された組を前記ホストと前記クライアントとの間で前記通信経路によって通信することと、
前記ホストデバイス内に存在する少なくとも１つのホストリンク制御装置を前記通信経路によって前記クライアントデバイスに結合することであって、ホストリンク制御装置が、前記通信プロトコルを形成しているパケットを生成、送信、受信するように、およびディジタル提示データをデータパケットの１つ以上のタイプへ形成するように構成されていることと、
前記リンク制御装置を使用して、データをパケットの形で前記通信経路によって転送することと、
通信リンクにおいて誤りの存在を検出することと、
前記誤りに対応する所定の誤りコードを選択することと、ＣＲＣ値を前記コードで上書きすることとを含む方法。
【請求項７０】
転送される連続するパケット内の前記ＣＲＣ値を、前記誤りが訂正されるまで上書きすることをさらに含む請求項６９記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本特許出願は、2003年6月2日に出願された仮出願第60/475,459号（“Generating and Implementing a Signal Protocol and Interface for Higher Data Rates”）に対して優先権を主張しており、第60/475,459号は、本発明の譲受け人に譲渡され、本明細書において参考文献としてとくに取上げられている。
【０００２】
発明の分野
本発明は、ホストデバイスとクライアントオーディオ／ビジュアル提示デバイスとの間で信号を高データレートで通信または転送するディジタル信号プロトコルおよび処理に関する。とくに、本発明は、低電力、高データレートの転送機構を使用して、マルチメディアまたは他のタイプのディジタル信号を、無線デバイスから超小型ディスプレイユニットまたは他の提示デバイスへ転送する技術に関する。
【背景技術】
【０００３】
コンピュータ、電子ゲーム関連製品、および種々のビデオ技術（例えば、ＤＶＤおよび高精細度ＶＣＲ）は、最近数年間において非常に進歩し、いくつかのタイプのテキストを含んでいるときであっても、このような装置のエンドユーザに、より一層高い解像度の静止、ビデオ、ビデオ・オン・デマンド、およびグラフィックの画像を提示する。これらの進歩により、その結果として、高精細度のビデオモニタ、ＨＤＴＶモニタ、または特定の画像投影素子のような、より高い解像度の電子ビューイングデバイスの使用が必要になった。このようなビジュアル画像と、ＣＤタイプの音響再生を使用するときのような高精細度または高品質のオーディオデータとの合成、すなわちＤＶＤ、および同様にオーディオ信号出力と関係付けられる他のデバイスは、エンドユーザのために、よりリアル感がある、コンテントが豊富である、または忠実なマルチメディア体験を生成するのに使用される。さらに加えて、ＭＰ３プレイヤのような、高移動性で、高品質の音響システムおよび音楽転送機構は、エンドユーザにオーディオのみを提示するために開発された。
【０００４】
通常のビデオ提示のシナリオでは、ビデオデータは、通常、現在の技術を使用して、遅いまたは中程度と最適に言われ得る、１秒当たりに約１ないし数十キロビット秒のレートで転送される。その後で、このデータは、希望のビューイングデバイス上での遅延（遅れ）再生のために、一時的な、またはより長い期間のメモリデバイス内で緩衝または記憶される。例えば、画像は、画像をディジタルで表現するのに有益なデータを受信または送信するための、モデムまたはインターネット接続デバイスをもつコンピュータ上に常駐のプログラムを使用して、インターネットを“横切って”または使用して転送されることができる。同様の転送は、無線モデムを備えたポータブルコンピュータ、または無線パーソナルデータアシスタント（Personal Data Assistant, PDA）、または無線電話のような無線デバイスを使用して行うことができる。
【０００５】
データは、受信されると、再生のために、外部記憶デバイスを含む、ＲＡＭまたはフラッシュメモリのような、メモリ素子、回路、またはデバイスに局所的に記憶される。データ量および画像解像度に依存して、再生は、比較的に迅速に始まっても、またはより長い期間を遅延して提示されてもよい。したがって、いくつかの例では、画像の提示は、多くのデータを必要としない、非常に少量または低解像度の画像において、またはいくつかのタイプの緩衝を使用して、ある程度の実時間再生を可能にし、したがって、僅かな遅延の後で、幾らかの材料が提示される一方で、より多くの材料は転送されている。転送リンクに中断がないならば、提示が始まると、転送はビューイングデバイスのエンドユーザにとって適度にトランスペアレントである。
【０００６】
静止画像または動画ビデオの何れかを生成するのに使用されるデータは、多くの場合に、Joint Photographic Experts Group(JPEG)、Motion Picture Experts Group(MPEG)、並びにメディア、コンピュータ、および通信業界における他の周知の標準規格設定機関または会社によって特定されたいくつかの周知の技術の１つを使用して圧縮され、通信リンクによるデータ転送を高速化する。これは、より少ない数のビットを使用して、所与の量の情報を転送することによって、画像またはデータをより迅速に転送することを可能にする。
【０００７】
データが、コンピュータまたは他の受信デバイスのような“ローカル”デバイスに転送されると、結果の情報は逆圧縮され（または、特別の復号プレーヤを使用して再生され）、必要とされるときに復号され、対応する使用可能な提示解像度および制御素子に基づく適切な提示のために準備される。例えば、Ｘ×Ｙ画素のスクリーン解像度に関して、通常のコンピュータビデオの解像度は、４８０×６４０から、６００×８００、ないし１０２４×１０２４画素の範囲にわたるが、一般に、種々の他の解像度が、希望または必要に応じて、可能である。
【０００８】
画像の提示は、画像の内容と、所与のビデオ制御装置の能力とによっても影響を受ける。このビデオ制御装置は、ある規定の色レベルまたは色の濃さ（色を生成するのに使用される１画素当たりのビット）および輝度、並びに採用される任意の追加のオーバーヘッドビットに関して、画像を操作する。例えば、通常のコンピュータの提示では、種々の色（濃淡度および色相）を表現するのに１画素当たりに約８ないし３２、またはそれ以上の任意のビットを予想するであろうが、他の値もある。
【０００９】
上記の値から、所与のスクリーン画像が、それぞれ、最低ないし最高の標準的な解像度および濃さの範囲において、約２．４５ないし約３３．５５メガビット（Megabit, Mb）のデータの転送を要求することになることが分かる。１秒当たりに３０フレームのレートでビデオまたは動画タイプの画像を表示するとき、必要なデータ量は、約７３．７ないし１，００６メガビット秒（Megabits of data per second, Mbps）、または約９．２１ないし１２５．７５メガバイト秒（Megabytes per second, MBps）のデータである。さらに加えて、例えば、マルチメディアの提示のような、オーディオデータを画像と組合わせて、またはＣＤ品質の音楽のような、別々の高解像度のオーディオを提示することを要求してもよい。対話命令、制御、または信号を扱う追加の信号も採用されることができる。これらのオプションの各々は、転送されるより一層多くのデータを追加する。何れの場合においても、高品質または高解像度の画像データ、および高品質のオーディオ情報またはデータ信号をエンドユーザへ転送して、コンテントが豊富な体験を生成することが要求されるとき、提示素子と、このようなタイプのデータを与えるように構成された源またはホストデバイスとの間に、高データ転送レートリンクが必要とされる。
【００１０】
約１１５キロバイト秒（Kilobyte per second, KBps）または９２０キロビット秒（Kilobit per second, Kbps）のデータレートは、現在のシリアルインターフェイスによって普通に処理されることができる。ＵＳＢシリアルインターフェイスのような他のインターフェイスは、１２メガビット秒ほどの速さのレートでのデータ転送に適応することができ、電気電子技術者協会（Institute of Electrical and Electronics Engineers, IEEE）の１３９４標準を使用して構成されているもののような、特殊高速転送は、約１００ないし４００メガビット秒のレートで行うことができる。都合の悪いことには、これらのレートは、ポータブルビデオディスプレイまたはオーディオデバイスを駆動するための高解像度で、コンテントが豊富な、出力信号を与える将来の無線データデバイスおよびサービスでの使用を考えられている上述の希望の高データレートには達しない。さらに加えて、これらのインターフェイスは、動作するのに相当量のホストまたはシステムおよびクライアントのソフトウエアの使用を必要とする。これらのソフトウエアのプロトコルスタックは、とくに、移動無線デバイスまたは電話の応用が考えられているときは、望ましくないほどの大量のオーバーヘッドも生成する。このようなデバイスは、厳しいメモリおよび電力消費の制限、並びに、既に重い負担をかけられた計算容量をもつ。さらに加えて、これらのインターフェイスのいくつかは、美しさを非常に重視する移動体の応用にとっては重過ぎて、満足できない嵩張るケーブル、およびコストを追加する複雑なコネクタを使用するか、または単に電力を消費し過ぎる。
【００１１】
アナログ ビデオ グラフィックス アダプタ(Video Graphics Adapter, VGA)、ディジタル ビデオ インタラクティブ(Digital Video Interactive, DVI)、またはギガビット ビデオ インターフェイス(Gigabit Video Interface, GVIF)のインターフェイスのような、他の既知のインターフェイスもある。これらの中の最初の２つは、より高い転送レートでデータを処理する並列型インターフェイスであるが、やはり、重いケーブルを採用し、約数ワットの大量の電力を消費する。これらの特徴の何れも、ポータブルな一般消費者向け電子デバイスで使用するように改良できない。３つ目のインターフェイスでさえ、電力を過度に消費し、コスト高の、または嵩張るコネクタを使用する。
【００１２】
上記インターフェイスのいくつか、および固定の設置コンピュータ装置のためのデータ転送と関係付けられる他の非常に高いレートのデータシステム／プロトコルまたは転送機構には、別の主要な欠点がある。希望のデータ転送レートに適応するには、相当量の電力または高電流レベルでの動作、あるいはこの両者をさらに必要とする。これは、非常に移動体の消費者を重視した製品に対して、このような技術の有用性を相当に低減する。
【００１３】
一般に、例えば、光ファイバタイプの接続および転送素子のような、代わりとなるものを使用して、このようなデータ転送レートに適応するには、多数の追加のコンバータおよび素子も必要とし、これらは、真に販売先の消費者を重視した製品にとって望ましいものよりも、複雑さおよびコストをさらに相当に取り込む。今までのところ、光システムの概してコスト高の性質を別にして、それらの電力要求および複雑さが、軽量で、低電力で、ポータブル形の応用に対する一般的な使用を妨げている。
【発明の概要】
【００１４】
ポータブルまたはモバイルの応用について業界に欠けていたものは、それがオーディオ、ビデオ、またはマルチメディアに基づいていても、高品質の提示体験を、高移動のエンドユーザに与える技術である。したがって、ポータブルコンピュータ、無線電話、ＰＤＡ、または他の高移動の通信デバイスまたは装置を使用するとき、使用されている現在のビデオおよびオーディオ提示システムまたはデバイスは、簡単に、希望の高品質レベルで出力を配信することができない。欠けている知覚品質は、高品質の提示データを転送するのに必要とされる、未獲得の高データレートの結果である。したがって、新しい転送機構は、データを与えるホストデバイスと、出力をエンドユーザに提示するクライアントのディスプレイデバイスまたは素子との間のデータスループットを増加することが必要とされる。
【００１５】
出願人は、このような新しい転送機構を米国特許出願第10/020,520号および第10/236,657号において提案し、両者は、“Generating And Implementing A Communication Protocol And Interface For High Data Rate Signal Transfer”という名称であり、本発明の譲受け人に譲渡され、本明細書において参照によって取入れられている。これらの出願に記載されている技術では、高速データ信号の大量のデータの転送レートを相当に向上することができる。しかしながら、とくにビデオ提示に関係するデータレートを一層高める要求は、増え続けている。データ信号技術における他の進行中の発展があっても、依然として、さらに一層高速の転送レートのために努力する必要がある。したがって、ホストとクライアントデバイスとの間のデータスループットを増加するのに必要とされる新しい、または向上した転送機構を開発することが、必要とされ続けている。
【００１６】
この技術に存在する上述の、および他の欠点は、本発明の実施形態によって対処されており、この中では、ホストデバイスと受信クライアントデバイスとの間でデータを高データレートで転送するための新しいプロトコルおよびデータ転送機構が展開されている。
【００１７】
本発明の実施形態は、ディジタルデータをホストデバイスとクライアントデバイスとの間で通信経路によって高レートで転送する移動データディジタルインターフェイス（Mobile Data Digital Interface, MDDI）に関し、これは、一緒にリンクされた複数または一連のパケット構造を採用して、ホストとクライアントデバイスとの間で、ディジタル制御および提示データの予め選択された組を通信する通信プロトコルを形成する。信号通信プロトコルまたはリンク層は、ホストまたはクライアントのリンク制御装置の物理層によって使用される。ホストデバイス内に存在する少なくとも１つのリンク制御装置は、通信経路またはリンクによってクライアントデバイスに結合され、通信プロトコルを形成しているパケットを生成、送信、受信するように、およびディジタル提示データをデータパケットの１つ以上のタイプへ形成するように構成されている。インターフェイスは、ホストとクライアントとの間で情報の双方向転送を与える。
【００１８】
本発明の実施形態の別の態様では、少なくとも１つのクライアントリンク制御装置、すなわちクライアント受信機は、クライアントデバイス内に配置され、通信経路またはリンクによってホストデバイスに結合される。クライアントリンク制御装置も、通信プロトコルを形成しているパケットを生成、送信、受信するように、およびディジタル提示データをデータパケットの１つ以上のタイプへ形成するように構成されている。一般に、ホストまたはリンク制御装置は、命令、またはある特定のタイプの信号の準備および照会処理に使用されるデータパケットを処理する状態機械を採用しているが、より低速の汎用プロセッサを使用して、通信プロトコルに使用されているデータおよび複雑さのより低いパケットのいくつかを処理することができる。ホスト制御装置は、１つ以上の差動ラインドライバを含み、一方で、クライアント受信機は、通信経路に結合された１つ以上の差動ライン受信機を含む。
【００１９】
パケットは媒体フレーム内で一緒にグループ化され、媒体フレームは、ホストとクライアントのデバイスの間で通信され、予め定義された固定長をもち、いろいろな可変長の所定数のパケットをもつ。各パケットは、パケット長フィールド、１つ以上のパケットデータフィールド、および巡回冗長検査フィールドを含む。サブフレームヘッダパケットは、ホストリンク制御装置からの他のパケットの転送の始めに転送されるか、または置かれる。１つ以上のビデオストリームタイプパケットおよびオーディストリームタイプパケットは、ビデオタイプデータおよびオーディタイプデータをそれぞれ、クライアントデバイスのユーザに提示するために、順方向リンクによってホストからクライアントへ転送するための通信プロトコルによって使用される。１つ以上の逆方向リンクカプセル化タイプパケットは、クライアントデバイスからホストリンク制御装置へデータを転送するための通信プロトコルによって使用される。
【００２０】
フィラータイプパケットは、ホストリンク制御装置によって生成され、データをもたない順方向リンク伝送の期間を占有する。複数の他のパケットは、ビデオ情報を転送するための通信プロトコルによって使用される。このようなパケットは、カラーマップ、ビットブロック転送、ビットマップ区域充填、ビットマップパターン充填、および透明色イネーブルタイプパケットを含む。ユーザ定義ストリームタイプパケットは、インターフェイス−ユーザ定義データを転送するための通信プロトコルによって使用される。キーボードデータおよびポインティングデバイスデータタイプパケットは、前記クライアントデバイスと関係付けられたユーザ入力デバイスとの間でデータを転送するための通信プロトコルによって使用される。リンク遮断タイプパケットは、前記通信経路による何れの方向におけるデータ転送も終了するための通信プロトコルによって使用される。
【００２１】
通信経路は、一般に、一連の４本以上の芯線およびシールドをもつケーブルを含む、または採用する。いくつかの実施形態では、リンク制御装置は、ＵＳＢデータインターフェイスを含み、ケーブルは、ＵＳＥタイプのインターフェイスを他の導線と共に使用する。さらに加えて、希望に応じて、プリント配線または可撓性の導線を使用することができる。
【００２２】
ホストリンク制御装置は、クライアントデバイスから表示能力情報を要求して、前記クライアントが前記インターフェイスによって何れのタイプのデータおよびデータレートに適応できるかを判断する。クライアントリンク制御装置は、少なくとも１つの表示能力タイプパケットを使用して、表示または提示能力をホストリンク制御装置へ通信する。多数の転送モードが、通信プロトコルによって使用され、各々は、所与の時間期間において、異なる最大数のビットのデータを並列で転送することを可能にし、各モードは、ホストとクライアントのリンク制御装置の間でネゴシエーションによって選択可能である。これらの転送モードは、データ転送中に動的に調節可能であり、順方向リンク上で使用されているのと同じモードを、逆方向リンク上で使用する必要はない。
【００２３】
本発明のいくつかの実施形態の他の態様では、ホストデバイスは、無線電話、無線ＰＤＡ、または無線モデムを内蔵したポータブルコンピュータのような、無線通信デバイスを含む。通常のクライアントデバイスは、超小型ディスプレイデバイスのようなポータブルビデオディスプレイ、またはポータブルオーディオ提示システム、あるいはこの両者を含む。さらに加えて、ホストは、記憶手段または素子を使用して、クライアントデバイスのユーザに提示するために転送される提示またはマルチメディアデータを記憶し得る。
【００２４】
本発明の別の特徴および長所、並びに本発明の種々の実施形態の構造および動作は、添付の図面を参照して、さらに詳しく別途記載される。図において、同様の参照番号は、全体的に、同一、機能上類似した、および／または構造上類似した要素または処理ステップを示し、要素が最初に現れる図は、参照番号内の最も左の数字によって示されている。
【図面の簡単な説明】
【００２５】
【図１Ａ】ポータブルコンピュータと共に使用される超小型ディスプレイデバイスの使用を含む、本発明の実施形態が動作し得る基本的な環境を示す図。
【図１Ｂ】無線トランシーバと共に使用される超小型ディスプレイデバイスおよびオーディオ提示素子の使用を含む、本発明の実施形態が動作し得る基本的な環境を示す図。
【図２】ホストとクライアントとが相互接続された移動ディジタルデータインターフェイスの全体的な概念を示す図。
【図３】クライアントデバイスからホストデバイスへのデータ転送を実現するのに役立つパケットの構造を示す図。
【図４】ＭＤＤＩリンク制御装置と、タイプＩおよびタイプＵのインターフェイスにおいて物理データリンク導線によってホストとクライアントとの間で送られる信号のタイプとの使用を示す図。
【図５】ＭＤＤＩリンク制御装置と、タイプＩＩ、ＩＩＩ、およびＩＶのインターフェイスにおいて物理データリンク導線によってホストとクライアントとの間で送られる信号のタイプとの使用を示す図。
【図６】インターフェイスプロトコルを実行するのに使用されるフレームおよびサブフレームの構造を示す図。
【図７】インターフェイスプロトコルを実行するのに使用されるパケットの全体的な構造を示す図。
【図８】サブフレームヘッダパケットのフォーマットを示す図。
【図９】フィラーパケットのフォーマットおよび内容を示す図。
【図１０】ビデオストリームパケットのフォーマットを示す図。
【図１１】図１０のビデオデータフォーマット記述子のフォーマットおよび内容を示す図。
【図１２】データのパックされたフォーマットおよびアンパックされたフォーマットの使用を示す図。
【図１３】オーディオストリームパケットのフォーマットを示す図。
【図１４】データのバイトを整列させたＰＣＭフォーマット、およびパックされたＰＣＭフォーマットの使用を示す図。
【図１５】ユーザ定義ストリームパケットのフォーマットを示す図。
【図１６】カラーマップパケットのフォーマットを示す図。
【図１７】逆方向リンクカプセル化パケットのフォーマットを示す図。
【図１８】表示能力パケットのフォーマットを示す図。
【図１９】キーボードデータパケットのフォーマットを示す図。
【図２０】ポインティングデバイスデータパケットのフォーマットを示す図。
【図２１】リンク遮断パケットのフォーマットを示す図。
【図２２】ディスプレイ要求および状態パケットのフォーマットを示す図。
【図２３】ビットブロック転送パケットのフォーマットを示す図。
【図２４】ビットマップ区域充填パケットのフォーマットを示す図。
【図２５】ビットマップパターン充填パケットのフォーマットを示す図。
【図２６】通信リンクデータチャネルパケットのフォーマットを示す図。
【図２７】インターフェイスタイプハンドオフ要求パケットのフォーマットを示す図。
【図２８】インターフェイスタイプ肯定応答パケットのフォーマットを示す図。
【図２９】タイプハンドオフ実行パケットのフォーマットを示す図。
【図３０】順方向オーディオチャネルイネーブルパケットのフォーマットを示す図。
【図３１】逆方向オーディオサンプルレートパケットのフォーマットを示す図。
【図３２】ディジタルコンテント保護オーバーヘッドパケットのフォーマットを示す図。
【図３３】透明色イネーブルパケットのフォーマットを示す図。
【図３４】往復遅延測定パケットのフォーマットを示す図。
【図３５】往復遅延測定パケット中のイベントのタイミングを示す図。
【図３６】本発明を実行するのに役立つＣＲＣ発生器およびチェッカのサンプル構成を示す図。
【図３７Ａ】データパケットを送信するときの、図３６の装置のＣＲＣのタイミングを示す図。
【図３７Ｂ】データパケットを受信するときの、図３６の装置のＣＲＣのタイミングを示す図。
【図３８】競合のない、通常のサービス要求のための処理ステップを示す図。
【図３９】リンクの起動の競合のある、リンク再起動順序が始まった後で、通常のサービス要求がアサートされる処理ステップを示す図。
【図４０】ＤＡＴＡ−ＳＴＢ符号化を使用して、データ系列がどのように伝送されることができるかを示す図。
【図４１】ホストにおいて入力データからＤＡＴＡおよびＳＴＢ信号を生成して、クライアントにおいてデータを復元するのに役立つ回路を示す図。
【図４２】１つの実施形態を実行するのに役立つドライバおよび終端抵抗を示す図。
【図４３】ホストから、およびホストによるサービスを保護するために、クライアントによって採用されるステップおよび信号レベルを示す図。
【図４４】Ｄａｔａ０、他のデータライン（ＤａｔａＸ）、およびストローブライン（Ｓｔｂ）における遷移間の相対的間隔を示す図。
【図４５】ホストがパケットを転送した後でホストドライバをディスエーブルするときに生じ得る応答の遅延の存在を示す図。
【図４６】ホストがホストドライバをイネーブルして、パケットを転送するときに生じ得る応答の遅延の存在を示す図。
【図４７】ホスト受信機入力における、転送されるデータのタイミングと、ストローブパルスのリーディングエッジおよびトレーリングエッジとの関係を示す図。
【図４８】スイッチングの特性と、逆方向データのタイミングによって生じる対応するクライアント出力の遅延とを示す図。
【図４９】状態機械を使用して同期が実現されることができる信号処理ステップおよび条件の高レベルの図。
【図５０】ＭＤＤＩを採用しているシステムにおける順方向および逆方向経路上での信号処理において生じる標準的な遅延量を示す図。
【図５１】限界往復遅延測定値を示す図。
【図５２】逆方向リンクデータレートの変化を示す図。
【図５３】逆方向レートの除数の値対順方向リンクデータレートのグラフ。
【図５４Ａ】インターフェイスの動作において行なわれるステップを示す図。
【図５４Ｂ】インターフェイスの動作において行なわれるステップを示す図。
【図５５】パケットを処理するインターフェイス装置の全体図を示す図。
【図５６】順方向リンクパケットのフォーマットを示す図。
【図５７】タイプＩのリンクインターフェイスにおける伝搬遅延およびスキューの標準値を示す図。
【図５８】インターフェイスによる例示的な信号処理におけるタイプＩのリンク上のデータ、ストローブ（Stb）、およびクロックの復元のタイミングを示す図。
【図５９】タイプＩＩ、タイプＩＩＩ、またはタイプＩＶのリンクインターフェイスにおける伝搬遅延およびスキューの標準値を示す図。
【図６０Ａ】２つのデータ信号およびＭＤＤＩ Ｓｔｂの相互の、それぞれ理想的な、早い、および遅いタイミングの異なる可能性を示す図。
【図６０Ｂ】２つのデータ信号およびＭＤＤＩ Ｓｔｂの相互の、それぞれ理想的な、早い、および遅いタイミングの異なる可能性を示す図。
【図６０Ｃ】２つのデータ信号およびＭＤＤＩ Ｓｔｂの相互の、それぞれ理想的な、早い、および遅いタイミングの異なる可能性を示す図。
【図６１】タイプＩ／タイプＩＩのインターフェイスで使用される例示的なコネクタのためのインターフェイスのピン割当てを示す図。
【図６２Ａ】タイプＩのインターフェイスにおける予想されるＭＤＤＩ ＤＡＴＡおよびＭＤＤＩ Ｓｔｂの波形を示す図。
【図６２Ｂ】タイプＩＩのインターフェイスにおける予想されるＭＤＤＩ ＤＡＴＡおよびＭＤＤＩ Ｓｔｂの波形を示す図。
【図６３】状態機械を使用して同期を実現することができる別の信号処理ステップおよび条件の高レベルの図。
【図６４】一連のクロックサイクル間の例示的な相対的タイミングと、種々の逆方向リンクパケットビットおよび除数値のタイミングとを示す図。
【図６５】例示的な誤りコード転送処理を示す図。
【図６６】誤りコード転送処理に役立つ装置を示す図。
【図６７Ａ】コードのオーバーローディングのための誤りコード転送処理を示す図。
【図６７Ｂ】コードの受信のための誤りコード転送処理を示す図。
【図６８Ａ】ホストが開始する起動のための処理ステップを示す図。
【図６８Ｂ】クライアントが開始する起動のための処理ステップを示す図。
【図６８Ｃ】競合のある、ホストおよびクライアントが開始する起動のための処理ステップを示す図。
【発明の詳細な説明】
【００２６】
Ｉ．概要
本発明の全体的な意図は、別途記載されるように、移動ディスプレイディジタルインターフェイス（Mobile Display Digital Interface, MDDI）を与えることであり、これは、 “直列”タイプのデータリンクまたはチャネルを使用して、ホストデバイスとディスプレイデバイスとの間の短距離の通信リンクによって高速または超高速のデータ転送を可能にする、コスト効率のよい低電力消費の転送機構になる、またはこれを与える。この機構は、小型コネクタおよび細い可撓性ケーブルを用いて実行するのに向いており、これらは、着用可能な超小型ディスプレイ（ゴーグルまたは投影器）のようなディスプレイ素子またはデバイスを、ポータブルコンピュータ、無線通信デバイス、または娯楽用デバイスに接続するのにとくに有益である。
【００２７】
本発明の実施形態の長所は、複雑さが低く、低コストであり、高い信頼性をもち、使用環境内に適切にフィットし、非常にロバストである一方で、高い融通性を維持するデータ転送のための技術を与えることである。
【００２８】
本発明は、種々の状況において、一般に、オーディオ、ビデオ、またはマルチメディアの応用のための大量のデータを、このようなデータが生成されるか、または記憶されるホストまたは源デバイスから、クライアント表示または提示デバイスへ、高レートで通信または転送するのに使用されることができる。別途記載される一般的な応用は、ポータブルコンピュータ、無線電話、またはモデムの何れかから、小型ビデオスクリーンか、あるいは、例えば、小型投影レンズを含むゴーグルまたはヘルメットの形の、着用可能な超小型ディスプレイ機器への、すなわち、ホストから、このような構成要素内のクライアントデバイスへのデータの転送である。したがって、プロセッサから、内部スクリーンあるいは他の提示素子へである。
【００２９】
ＭＤＤＩの特性または属性は、特定のディスプレイ技術とは無関係のものである。これは、データの内部構造とも、それが実行するデータまたは命令の機能的な側面とも関係なく、そのデータを高レートで転送する非常に融通の利く機構である。これは、転送されるデータパケットのタイミングが、個々のディスプレイデバイスの特異性、またはある特定のデバイスのユニークな表示要求に適応するか、あるいはいくつかのＡＶシステムにおける合成されたオーディオおよびビデオの要件を満たすように調整されることを可能にする。選択されたプロトコルにしたがう限り、インターフェイスは、まさに、ディスプレイ素子またはクライアントデバイスの認知不可能なもの（agnostic）である。加えて、集合体直列リンクデータまたはデータレートは、通信システムまたはホストデバイスの設計者がコスト、電力要件、クライアントデバイスの複雑性、およびディスプレイデバイスの更新レートを最適化することを可能にするいくつかのオーダにわたって変化することができる。
【００３０】
データインターフェイスは、主として、“ワイヤード”信号リンクまたは小型ケーブルによって大量の高レートのデータを転送するのに使用するために与えられる。しかしながら、いくつかの応用では、光を用いたリンクを含む無線リンクが、インターフェイスプロトコルのために生成された同じパケットおよびデータ構造を使用するように構成されていて、かつ電力消費または複雑さが十分に低い希望の転送レベルを維持して、実用的であり続けることできることを条件として、それも使用できる。
【００３１】
ＩＩ．環境
典型的な応用は、図１Ａおよび１Ｂにおいて見られ、ここでは、ポータブルまたはラップトップコンピュータ100および無線電話またはＰＤＡデバイス102が、オーディオ再生システム108および112と共に、ディスプレイデバイス104および106と、それぞれデータを通信していることが示されている。加えて、図１Ａは、より大きいディスプレイまたはスクリーン114または画像投影器116への潜在的な接続を示しており、これらは、分かり易いように、一方の図のみに示されているが、無線デバイス102へも接続可能である。無線デバイスは、現在データを受信しているか、あるいはメモリ素子またはデバイス内にある特定量のマルチメディアタイプのデータを予め記憶して、無線デバイスのエンドユーザが見たり、および／または聞いたするために、後で提示することができる。通常の無線デバイスは、時間の大部分を音声および単純なテキスト通信に使用されるので、情報をデバイス102のユーザへ通信するための、相当に小型の表示スクリーンおよび単純なオーディオシステム（スピーカ）をもつ。
【００３２】
コンピュータ100は、相当により大きいスクリーンをもつが、まだ不十分な外部音響システムをもち、依然として、高精細度のテレビジョンまたは映画のスクリーンのような、他のマルチメディア提示デバイスには達しない。コンピュータ100は、説明のために使用されており、他のタイプのプロセッサ、対話型ビデオゲーム、または家庭用電子デバイスも、本発明で使用されることができる。コンピュータ100は、無線通信のための無線モデムまたは他の組み込み型デバイスを、これらに制限することなく、採用するか、あるいは希望に応じて、ケーブルまたは無線リンクを使用して、このようなデバイスに接続されることができる。
【００３３】
これは、有益な、または楽しい体験とは言えない、より複雑な、または“豊富な”データの提示を行う。したがって、業界では、エンドユーザに情報を提示し、最低レベルの希望の楽しい、またはポジティブな体験を与えるための他の機構およびデバイスを開発している。
【００３４】
既に記載されているように、いくつかのタイプのディスプレイデバイスは、デバイス100のエンドユーザへ情報を提示するために開発された、または現在開発されている。例えば、１つ以上の会社が、デバイスのユーザの眼の前に画像を投影して、視覚的表示を提示する着用可能なゴーグルのセットを開発した。このようなデバイスは、正しく位置付けられると、視覚出力を与えている要素よりも相当に大きい仮想画像を、ユーザの眼によって知覚されるように、効果的に“投影”する。したがって、非常に小さい投影素子が、ユーザの眼が、標準的なＬＣＤスクリーン、等で可能な大きさよりも相当に大きい尺度で画像を“見る”ことを可能にする。より大きい仮想スクリーン画像の使用は、より制限されたＬＣＤスクリーンのディスプレイで可能なものよりも、相当に高い解像度の画像の使用も可能にする。他のディスプレイデバイスは、小型ＬＣＤスクリーンまたは種々のフラットパネルディスプレイ素子、画像を表面に投影する投影レンズおよびディスプレイドライバ、等を、これらに制限されことなく、含むことができる。
【００３５】
追加の素子が、無線デバイス102またはコンピュータ100に接続されるか、またはその使用と関係付けられ、追加の素子が、出力を別のユーザか、または別のデバイスに提示して、次に別のデバイスが信号を他のところへ転送するか、または記憶してもよい。例えば、データは、後で使用するために、例えば、書込み可能なＣＤ媒体を使用して、光の形で、フラッシュメモリに記憶されるか、または例えば、磁気テープレコーダおよび同様のデバイス内の磁気媒体上に記憶されてもよい。
【００３６】
加えて、多くの無線デバイスおよびコンピュータは、現在、ＭＰ３音楽復号能力、並びに他の高度な音響復号器およびシステムを組み込んでいる。ポータブルコンピュータは、一般に、ＣＤおよびＤＶＤの再生能力を使用し、いくつかのものは、予め録音されたオーディオファイルを受信するための小型の専用フラッシュメモリリーダをもつ。このような能力をもつことについての問題は、復号および再生処理が速さを保つことができるときのみ、ディジタル音楽ファイルが、非常に向上した特徴の豊富な体験を約束することである。ディジタルビデオファイルにも、同じことが当てはまる。
【００３７】
音響再生を補助するために、図１Ａには、外部スピーカ108が示されており、サブウーファ、または前および後の音響を伝えるための“サラウンド−サウンド”スピーカのような追加の素子を付属することもできる。同時に、スピーカまたはイヤフォン108が、図１Ｂの超小型ディスプレイデバイス106の支持フレームまたは機構に組込まれていることが示されている。知られているように、電力増幅または音響形成デバイスを含む、他のオーディオまたは音響再生素子が使用されることができる。
【００３８】
何れの場合でも、既に記載されたように、高品質または高解像度の画像データ、および高品質のオーディオ情報またはデータ信号を、データ源からエンドユーザへ１本以上の通信リンク110によって転送したいとき、高データレートが必要である。したがって、既に記載されたように、現在の転送機構は、一般に望まれる高データレートを達成していないので、転送リンク110は、明らかに、データの通信において潜在的なボトルネックがあり、システムの性能を制限している。既に記載されたように、例えば、１０２４×１０２４の画素のような、より高い画像解像度で、色の濃さが１画素当たりに２４ないし３２ビットで、データレートが３０ｆｐｓで、データレートは、７５５メガビット秒を越えるレートに近付くことができる。加えて、このような画像は、オーディオデータおよび潜在的な追加の信号を含むマルチメディア提示の一部として提示されることもあり、潜在的な追加の信号は、対話式ゲーミングまたは通信、あるいは種々の命令、制御、または信号を扱い、量またはデータおよびデータレートをさらに高めるものである。
【００３９】
データリンクを設定するのに必要とされるケーブルまたは相互接続がより少ないことは、ディスプレイと関係付けられた移動デバイスが、より使い易く、より大きいユーザ層によって取り入れられる可能性がより高いことを意味することも明らかである。これは、多数のデバイスが、一般に、完全なオーディオ−ビジュアル体験を設定するのに使用されるときに、とりわけ、ディスプレイおよびオーディオ出力デバイスの品質レベルが高まるときに、とくに当てはまる。
【００４０】
都合の悪いことには、より高いデータレートは、データを転送するのに使用可能な現在の技術を越えている。必要とされることは、提示素子とデータ源との間のデータ転送リンクまたは通信経路のための、データをより高いレートで転送する技術であり、これは、（より）低い電力で、軽量で、可能な限り単純で経済的なケーブリング構造を常に可能にするものである。出願人は、新しい技術、または方法および装置を開発し、これらの、および他の目標を達成し、数多くのいろいろなモバイル、ポータブル、または固定デバイスでさえもが、データを希望のディスプレイ、超小型ディスプレイ、またはオーディオ転送素子へ非常に高いデータレートで転送する一方で、希望の低い電力消費および複雑さを維持することを可能にした。
【００４１】
ＩＩＩ．高レートディジタルデータインターフェイスシステムアーキテクチャ
新しいデバイスインターフェイスを生成し、効率的に利用するために、低電力信号を使用して、非常に高いデータ転送レートを与える信号プロトコルおよびシステムアーキテクチャが開発された。プロトコルは、パケットおよび共通フレーム構造か、またはデータまたはデータタイプの予め選択された組を通信するためのプロトコルを、インターフェイスに課された命令または動作構造と共に形成するために、一緒にリンクされた構造に基づく。
【００４２】
Ａ．概要
ＭＤＤＩリンクによって接続されるか、または通信するデバイスは、ホストおよびクライアントと呼ばれ、クライアントは、通常いくつかのタイプのディスプレイデバイスである。ホストからディスプレイへのデータは、順方向に移動し（順方向トラヒックまたはリンクと呼ばれる）、ホストによってイネーブルされるとき、ディスプレイからホストへのデータは、逆方向に移動する（逆方向トラヒックまたはリンクと呼ばれる）。これは、図２に示されている基本構成で説明されている。図２において、ホスト202は、双方向通信チャネル206を使用してクライアント204へ接続されていて、双方向通信チャネル206は順方向リンク208および逆方向リンク210を含むように示されている。しかしながら、これらのチャネルは、導線の共通の組によって形成され、そのデータ転送は、順方向または逆方向リンクの動作間で効率的にスイッチされる。
【００４３】
別途記載されるように、ホストは、本発明を使用することにより恩恵を得ることができるいくつかのタイプのデバイスの中の1つを含む。例えば、ホスト202は、ハンドヘルド、ラップトップ、または同様のモバイルコンピューティングデバイスの形のポータブルコンピュータであってもよく、ＰＤＡ、ページングデバイス、または多くの無線電話またはモデムの中の1つであってもよい。その代りに、ホスト202は、ポータブルＤＶＤまたはＣＤプレーヤ、またはゲームプレイングデバイスのような、ポータブルの娯楽または提示デバイスであってもよい。同時に、クライアント204は、情報をエンドユーザに提示するのに役立つ種々のデバイスを含み得る。例えば、ゴーグルまたは眼鏡に内蔵された超小型ディスプレイ；帽子またはヘルメットに組込まれた投影デバイス；車両の、例えば、ウインドウまたはフロントガラスに組込まれた、小型スクリーンまたは、さらにはホログラフィ要素；あるいは種々のスピーカ、ヘッドホン、または高品質の音響または音楽を提示するための音響システムである。しかしながら、当業者は、本発明がこれらのデバイスに制限されず、市場には他の多くのデバイスがあり、使用を提案されていて、記憶および移送に関して、または再生時の提示に関しての何れかにおいて、エンドユーザに高品質の画像および音響を与えることを意図されていることが容易に分かるであろう。本発明は、希望のユーザ体験を実現するのに必要とされる高データレートに適応するように、種々のデバイス間のデータスループットを増加するのに役立つ。
【００４４】
Ｂ．インターフェイスのタイプ
ＭＤＤインターフェイスは、通信およびコンピュータ業界に見られるインターフェイスの５つ以上のある程度異なる物理タイプに対処すると考えられる。これらは、この点で、単にタイプＩ、タイプＩＩ、タイプＩＩＩ、タイプＩＶ、およびタイプＵと呼ばれる。
【００４５】
タイプＩのインターフェイスは、６線（導線）インターフェイスとして構成され、これは、それを、移動または無線電話、ＰＤＡ、電子ブック、電子ゲーム、およびポータブルメディアプレーヤ、例えば、ＣＤプレーヤ、またはＭＰ３プレーヤ、および同様のタイプの一般消費者向け電子技術のデバイスに適したものにする。タイプＵのインターフェイスは、８線（導線）インターフェイスとして構成され、これは、ラップトップ、ノートブック、またはデスクトップのパーソナルコンピュータおよび同様のデバイスまたは応用により適しており、ディスプレイを迅速に更新することを必要とせず、組み込まれたＭＤＤＩリンク制御装置をもたない。このインターフェイスのタイプは、追加の２線ユニバーサルシリアルバス（ＵＳＢ）インターフェイスの使用によっても区別することができ、これは、大抵のパーソナルコンピュータ上に見られる既存のオペレーティングシステムまたはソフトウエア支援に適応するのにとくに有益である。タイプＵのインターフェイスは、ＵＳＢ専用モードで使用されることもでき、この場合に、ディスプレイは、単にＵＳＢコネクタをもっているだけで、ＵＳＢコネクタが、コンピュータまたは同様のデバイス上の標準のＵＳＢポートに、例えば、このようなポートを備えた、ディジタルカメラまたはビデオプレーヤのような一般消費者向け電子デバイスに接続する。
【００４６】
タイプＩＩ、タイプＩＩＩ、およびタイプＩＶのインターフェイスは、高性能ディスプレイまたはデバイスに適しており、追加の撚線対タイプの導線との、より大きくて、より複雑なケーブリングを使用して、データ信号に適切なシールディングおよび低損失転送を与える。
【００４７】
タイプＩのインターフェイスは、両者の表示、オーディオ、制御、および制限されたシグナリング情報を含むことができる信号を送り、一般に、高解像度のフルレートのビデオデータを必要としないデバイスに使用される。このタイプのインターフェイスは、主として、移動無線デバイスのようなデバイス向けであり、この場合に、ＵＳＢのホストは、一般に、信号の接続および転送のためのデバイス内で使用可能ではない。この構成では、移動デバイスは、ＭＤＤＩホストデバイスであり、ホストからの通信リンク、すなわち、通常、ディスプレイデータをクライアントへ送るもの（順方向トラヒックまたはリンク）を制御する“マスタ”として働く。
【００４８】
このインターフェイスでは、ホストが特別の命令またはパケットタイプをクライアントへ送って、クライアントがバス（リンク）を特定の期間の間支配して、データを逆方向パケットとしてホストへ送ることができるようにすることによって、ホストにおいてクライアントからの通信データ（逆方向トラヒックまたはリンク）を受信できるようにする。これは、図３に示されており、ここでは、カプセル化パケット（別途記載される）と呼ばれるタイプのパケットが使用され、転送リンクによる逆方向パケットの転送に収容して、逆方向リンクを生成する。ホストがディスプレイにデータについてポーリングするために割り振られた時間間隔は、ホストによって予め決められていて、各特定の応用の要件に基づく。このタイプの半二重双方向データ転送は、ＵＳＢポートがクライアントからの情報またはデータの転送に使用可能でないときに、とくに有利である。
【００４９】
タイプＵのインターフェイスは、ラップトップおよびデスクトップの応用で使用するのに十分に適した信号を転送し、この場合に、ＵＳＢインターフェイスは、多くのマザーボードまたは他のハードウエアによって、およびオペレーティングシステムのソフトウエアによって幅広く支援されている。追加のＵＳＢインターフェイスの使用は、“プラグ・アンド・プレイ”機能および容易な応用構成での使用を可能にする。さらに加えて、ＵＳＢを含むと、命令、状態、オーディオデータ、等の汎用の双方向フローが可能になり、一方でクライアントデバイスに宛てられたビデオおよびオーディオデータを、撚線対を使用して、低電力および高速度で転送することもできる。電力は、別途記載されるように、他のワイヤを使用して送ることができる。ＵＳＢインターフェイスを使用する本発明の実施形態は、１組の導線による高速転送を可能にする一方で、主として、シグナリングおよび制御をＵＳＢ接続によって実行し、したがって、使用しておらず、電力をほとんど使用しないときに、遮断されることができる。
【００５０】
ＵＳＢインターフェイスは、現代のパーソナルコンピュータ装置において非常に広く使用されている標準であり、ＵＳＢインターフェイスおよびその動作の詳細は、この技術において非常によく知られているので、ここでは説明しない。ＵＳＢインターフェイスにおいて、ホストとディスプレイとの間の通信は、ユニバーサルシリアルバス仕様、改訂２．０（Universal Serial Bus Specification, Revision 2.0）にしたがう。タイプＵのインターフェイスを使用し、ＵＳＢが主要なシグナリングチャネル、および恐らくは、音声応答チャネルである応用では、ホストがＭＤＤＩ直列データ信号によってクライアントにポーリングすることはオプションである。
【００５１】
ＨＤＴＶタイプまたは同様の高解像度が可能な高性能のディスプレイは、フルモーションビデオを支援するために、約１．５ギガビット秒のレートのデータストリームを必要とする。タイプＩＩのインターフェイスは、２ビットを並列で伝送することによって、タイプＩＩＩは、４ビットを並列で伝送することによって、高データレートを支援し、タイプＩＶのインターフェイスは、使用できる最高データレートが何かをネゴシエートすることによって、８ビットを並列で転送する。ＭＤＤＩによって使用されるプロトコルは、各タイプＩ、ＩＩ、ＩＩＩ、またはＩＶのホストが、何れかのタイプＩ、ＩＩ、ＩＩＩ、またはＩＶのクライアントまたはディスプレイと普通に通信することを可能にする。最低能力デバイスと呼ばれ得るものの能力または使用可能な機能は、リンクの性能を設定するのに使用される。概して、ホストおよびクライアントの両者が、タイプＩＩ、タイプＩＩＩ、またはタイプＩＶのインターフェイスを使用できるシステムにおいてでさえ、この両者は、タイプＩのインターフェイスとして動作を開始する。その後で、ホストは、目標のクライアントまたはディスプレイの能力を判断し、個々の応用に適するように、タイプＩＩ、タイプＩＩＩ、またはタイプＩＶのモードの何れかへのハンドオフまたは再構成動作をネゴシエートする。
【００５２】
一般に、ホストは、（別途記載される）適切なリンク層プロトコルを使用して、いつでも、動作をより低速のモードへステップダウンするか、または再び再構成して、電力を節約するか、あるいは例えば、より高い解像度の表示内容のために、より高速のモードへステップアップして、より高速の転送を支援することができる。例えば、ホストがディスプレイモードを変更できるのは、ディスプレイシステムが、バッテリのような電源からＡＣ電力へスイッチするとき、あるいはディスプレイ媒体源が、より低いまたはより高い解像度のフォーマットへスイッチするときであるか、あるいはディスプレイまたはデータ転送モードを変更するための原則として、これらまたは他の条件またはイベントの組合せが考えられ得る。
【００５３】
システムが、一方向において１つのモードを使用し、別の方向において別のモードを使用して、データを通信することも可能である。例えば、タイプＩＶのインターフェイスモードは、データを高レートでディスプレイに転送するのに使用されることができ、一方で、タイプＩまたはタイプＵのモードは、キーボードまたはポインティングデバイスのような周辺デバイスからホストデバイスへデータを転送するときに使用される。
【００５４】
Ｃ．物理インターフェイス構造
ホストとクライアントのデバイスの間の通信を設定するためのデバイスまたはリンク制御装置の全体的な配置は、図４および５に示されている。図４および５では、ＭＤＤＩリンク制御装置402および502が、ホストデバイス202および202'にインストールされていることが示されており、ＭＤＤＩリンク制御装置404および504が、クライアントデバイス204および204'にインストールされていることが示されている。既に記載されたように、ホスト202は、一連の導線を含む双方向通信チャネル406を使用して、クライアント204に接続されている。別途記載されるように、ホストおよびクライアントのリンク制御装置の両者は、単一回路設計を使用した集積回路として製造されることができ、これは、ホスト制御装置（ドライバ）またはクライアント制御装置（受信機）の何れかとして応答するように、設定され、調整され、またはプログラムされることができる。これは、単一回路デバイスのより大きい規模の製造において、コストを低減する。
【００５５】
図４には、ＭＤＤＩのタイプＵのインターフェイスバージョンを実行するのに使用するための、ＵＳＢホストデバイス408およびＵＳＢクライアントデバイス410も示されている。このような機能を実行するための回路およびデバイスは、この技術においてよく知られており、本明細書ではさらに詳しく記載されない。
【００５６】
図５には、ＭＤＤＩリンク制御装置502がホストデバイス202'にインストールされていることが示されており、ＭＤＤＩリンク制御装置504がクライアントデバイス204'にインストールされていることが示されている。既に記載されたように、ホスト202'は、一連の導線を含む双方向通信チャネル506を使用して、クライアント204'に接続されている。既に記載されたように、ホストおよびクライアントのリンク制御装置の両者は、単一回路設計を使用して製造されることができる。
【００５７】
ＭＤＤＩリンク、または使用されている物理的導線によって、ホストと、ディスプレイデバイスのようなクライアントとの間で送られる信号も、図４および５に示されている。図４および５において見られるように、ＭＤＤＩによってデータを転送する一次経路または機構は、ＭＤＤＩ Ｄａｔａ０＋／−およびＭＤＤＩ Ｓｔｂ＋／−として示されているデータ信号を使用する。これらの各々は、低電圧データ信号であり、ケーブル内の差動のワイヤの対によって転送される。インターフェイスによって送られる各ビットに対して、ＭＤＤＩ Ｄａｔａ０の対か、またはＭＤＤＩ Ｓｔｂの対の何れかにおいて、１回のみ遷移される。これは、電流を用いたものではなく、電圧を用いた転送機構であり、したがって、静的電流消費は、ほぼゼロである。ホストは、クライアントのディスプレイへＭＤＤＩ Ｓｔｂ信号を駆動する。
【００５８】
データがＭＤＤＩ Ｄａｔａの対、すなわち、双方向転送経路により、順方向および逆方向の両者において流れることができる一方で、ホストはデータリンクのマスタまたは制御装置である。ＭＤＤＩ Ｄａｔａ０およびＭＤＤＩ Ｓｔｂの信号経路は、差動モードで動作され、雑音耐性を最大化する。これらのライン上の信号のデータレートは、ホストによって送られるクロックのレートによって判断され、約１キロビット秒ないし４００メガビット秒以上の範囲で可変である。
【００５９】
タイプＩＩのインターフェイスは、タイプＩのインターフェイスのデータの対、導線、または経路の他に、１つの追加のそれを含み、ＭＤＤＩ Ｄａｔａ１＋／−と呼ばれる。タイプＩＩＩのインターフェイスは、タイプＩＩのインターフェイスのデータの対または信号経路の他に、２つの追加のそれを含み、ＭＤＤＩ Ｄａｔａ２＋／−、およびＭＤＤＩ Ｄａｔａ３＋／−と呼ばれる。タイプＩＶのインターフェイスは、タイプＩＩＩのインターフェイスのデータの対または信号経路の他に、４つ以上のそれを含み、それぞれ、ＭＤＤＩ Ｄａｔａ４＋／−、ＭＤＤＩ Ｄａｔａ５＋／−、ＭＤＤＩ Ｄａｔａ６＋／−、およびＭＤＤＩ Ｄａｔａ７＋／−と呼ばれる。上述のインターフェイス構成の各々において、ホストは、ＭＤＤＩ ＰｗｒおよびＭＤＤＩ Ｇｎｄとして示されているワイヤの対または信号を使用して、電力をクライアントまたはディスプレイへ送ることができる。
【００６０】
タイプＵの構成で使用可能にされるほぼ唯一の転送のタイプは、ＭＤＤＩのＵＳＢ接続または信号経路である。ＭＤＤＩのＵＳＢ接続は、ホストとクライアントのディスプレイとの間の通信のための二次経路を含む。ある特定の応用では、ホストとクライアントとの間で、比較的に低いデータレートで、ある特定の情報を送ることがより好都合であり得る。ＵＳＢ転送リンクを使用すると、ＭＤＤＩリンク制御装置をもたず、ＵＳＢホストをもつか、またはホスト能力が制限されたデバイスが、タイプＵのインターフェイスを備えたＭＤＤＩ対応のクライアントまたはディスプレイと通信することができる。ＵＳＢインターフェイスによりディスプレイへ便利に転送されることができる情報の例は、静的ビットマップ、ディジタルオーディオストリーム、ポインティングデバイスデータ、キーボードデータ、および制御および状態情報である。ＵＳＢインターフェイスによって支援される機能は、一次ＭＤＤＩ高速直列データ経路を使用して実行されることもできる。上述で定義されたデータ（以下では、パケットを参照）がＵＳＢタイプのインターフェイスによって送られ得る一方で、データをパケットの形で背中合わせに連鎖させるための要件は、このようなＵＳＢインターフェイスに適用せず、ＭＤＤＩタイプのハンドオフを支援するパケットも使用しない。
【００６１】
ＭＤＤＩリンクによりホストとクライアント（ディスプレイ）との間で送られる信号の概要は、インターフェイスのタイプにしたがって、次の表１に示されている。
【表１】
2011176810.tif 000003
【００６２】
上述の構造および動作を実行するのに一般に使用されるケーブリングは、公称で、１．５メートルのオーダの長さであり、３つの撚線対の導線を含み、各々は、マルチストランドの３０ＡＷＧワイヤである。フォイルシールドカバリングが、巻付けられるか、または、さもなければ、追加のドレイン線のような、３つの撚線対の上に形成される。撚線対およびシールドドレイン導線は、ディスプレイ（クライアント）のためのシールドに接続されたシールドをもつディスプレイコネクタにおいて終端し、ケーブル全体をカバーしている絶縁層があり、この技術において周知であるであろう。ワイヤは、ＭＤＤＩ ＧｎｄとＭＤＤＩ Ｐｗｒ、ＭＤＤＩ Ｓｔｂ＋とＭＤＤＩ Ｓｔｂ−、ＭＤＤＩ Ｄａｔａ０＋とＭＤＤＩ Ｄａｔａ０−、ＭＤＤＩ Ｄａｔａ１＋とＭＤＤＩ Ｄａｔａ１−、等のように対にされる。公称のケーブルの直径は、３．０ミリメートルであり、８５オーム±１０％の公称インピーダンスをもち、１０００フィート当たりに公称で１１０オームのＤＣ抵抗をもつ。信号伝搬速度は、公称で０．６６ｃであるべきであり、ケーブルを通る最大遅延は、約８．０ナノ秒よりも短い。
【００６３】
Ｄ．データタイプおよびレート
ユーザ体験および応用の全範囲において有益なインターフェイスを実現するために、移動ディジタルデータインターフェイス（ＭＤＤＩ）は、種々のディスプレイおよびディスプレイ情報、オーディオ変換器、キーボード、ポインティングデバイス、および移動ディスプレイデバイスに統合されるか、それと共に動作し得る多くの他の入力デバイスを、制御情報と一緒に、その組み合わせで支援する。ＭＤＤインターフェイスは、最少数のケーブルまたは導線を使用して、順方向または逆方向の何れかにおいて、ホストとクライアントとの間を横断する種々の潜在的なタイプのデータストリームを適応させることができるように設計される。等時性ストリームおよび非対称ストリームの両者（更新）が支援される。集合体データのレートが最大希望ＭＤＤＩリンクレート以下である限り、データタイプの多くの組合せが可能である。これらは、次の表２および３に示されている項目を含むことができるが、これらに制限されない。
【表２】
2011176810.tif 000004
【表３】
2011176810.tif 000005
【００６４】
インターフェイスは、固定されず、拡張可能であり、したがって、将来のシステムの柔軟性のために、ユーザ定義データを含む種々の情報“タイプ”の転送を支援することができる。適応させられるデータの具体的な例は、フルまたは部分スクリーンビットマップフィールドまたは圧縮ビデオの何れかの形のフルモーションビデオ；電力を節約し、実行コストを低減する低レートの静的なビットマップ；種々の解像度またはレートのＰＣＭまたは圧縮オーディオデータ；ポインティングデバイスの位置および選択；並びに、まだ定義されていない能力についてのユーザ定義可能データである。このようなデータは、制御または状態情報と共に転送され、デバイスの能力を検出するか、または動作パラメータを設定することもできる。
【００６５】
本発明は、データ転送において使用する技術を向上する。これは、映画を見ること（ビデオ表示およびオーディオ）；個人的に見ることが制限されているパーソナルコンピュータを使用すること（グラフィック表示であり、ビデオおよびオーディオと組み合わされることもある）；ＰＣ、コンソール、またはパーソナルデバイス上でビデオゲームをすること（モーショングラフィック表示、または合成ビデオおよびオーディオ）；インターネットを“サーフすること”；ビデオ電話（双方向の低レートのビデオおよびオーディオ）、静止ディジタル写真用のカメラ、またはディジタルビデオ画像を取り込むためのカムコーダの形のデバイスを使用すること；およびセル電話、スマート電話、またはＰＤＡを用いた生産性の向上または娯楽的使用を含むが、これらに制限されない。
【００６６】
以下で記載される移動データインターフェイスは、一般にワイヤーラインまたはケーブルタイプリンクとして構成されている通信または転送リンク上で、大量のＡＶタイプのデータを与えることに関して提示される。しかしながら、信号構造、プロトコル、タイミング、または転送機構は、データ転送の希望のレベルを維持することができるとき、光または無線媒体の形のリンクを与えるように調整され得ることが容易に分かるであろう。
【００６７】
ＭＤＤインターフェイス信号は、基本信号プロトコルまたは構造における共通フレーム（Common Frame, CF）として知られている概念を使用する。共通フレームを使用することの背後にある発想は、同時等時性データストリームに同期パルスを与えることである。ディスプレイデバイスは、この共通フレームレートを時間基準として使用することができる。低いＣＦレートは、サブフレームヘッダを伝送するオーバーヘッドを低減することによって、チャネル効率を高める。他方で、高いＣＦレートは、待ち時間を低減し、オーディオサンプルのための融通の利くデータ緩衝をより小さくすることができる。本発明のインターフェイスのＣＦレートは、動的にプログラム可能であり、特定の応用に使用される等時性ストリームに適した多くの値の１つに設定され得る。したがって、ＣＦ値は、希望に応じて、所与のディスプレイデバイスおよびホスト構成に最も適するように選択される。
【００６８】
ヘッドマウント形超小型ディスプレイのような応用で最も使用されそうな等時性データストリームのための調整可能またはプログラム可能な、１共通フレーム当たりに通常要求されるバイト数は、表４に示されている。
【表４】
2011176810.tif 000006
【００６９】
１共通フレーム当たりのバイトの分数のカウントは、簡単なプログラム可能なＭ／Ｎカウンタ構造を使用して、容易に得られる。例えば、１ＣＦ当たりに２６と３分の２バイトのカウントは、２７バイトの２フレームを転送することによって実現され、各フレームの後には、２６バイトの１フレームが続く。１ＣＦごとに整数のバイトを生成するために、より小さいＣＦレートが選択され得る。しかしながら、一般に、ハードウエア内に簡単なＭ／Ｎカウンタを構成するのに必要とされる区域は、本発明の一部または全てを実行するのに使用される集積回路チップまたは電子モジュール内に、より大きいオーディオサンプルのＦＩＦＯ緩衝器に必要とされる区域よりも、より小さい。
【００７０】
異なるデータ転送レートおよびデータタイプの効果を示す例示的な応用は、カラオケシステムである。カラオケでは、システムのユーザは、音楽ビデオのプログラムと共に歌を歌う。歌の歌詞は、スクリーンの下部に表示されるので、ユーザには、歌われる言葉と、歌の大体のタイミングとが分かる。この応用は、グラフィックの更新が頻繁でないビデオ表示と、ユーザの声とステレオオーディオストリームとを結び付けることとを必要とする。
【００７１】
３００ヘルツの共通フレームレートを仮定するとき、各ＣＦは、ディスプレイデバイスへの順方向リンク上の９２，１６０バイトのビデオコンテントと、（ステレオにおける、１４７ １６ビットのサンプルに基づいて）５８８バイトのオーディオコンテントとから成り、平均２９．６７（２６と３分の２）バイトの音声が、マイクロフォンから移動カラオケ装置へ送られる。非同期のパケットが、ホストとディスプレイとの間で送られる。これは、最高で７６８バイトのグラフィックデータ（４分の１スクリーンの高さ）と、諸々の制御および状態命令のための約２００（数）バイト未満のバイトとを含む。
【００７２】
表５は、カラオケの例において、データが共通フレーム内にどのように割り振られるかを示している。使用される総レートは、約２２５メガビット秒であるように選択される。２２６メガビット秒のわずかにより高いレートは、１サブフレーム当たりに別の約４００バイトのデータが転送されることを可能にし、不定期の制御および状態メッセージの使用を可能にする。
【表５】
2011176810.tif 000007
【００７３】
Ｅ．リンク層
ＭＤＤインターフェイス高速直列データ信号を使用して転送されるデータは、次々にリンクされる時間多重化パケットのストリームから成る。送信デバイスが送るためのデータをもたないときでも、ＭＤＤＩリンク制御装置は、一般に、フィラーパケットを自動的に送り、したがってパケットのストリームを維持する。簡単なパケット構造の使用は、ビデオおよびオーディオ信号またはデータストリームの確実な等時性のタイミングを保証する。
【００７４】
パケットのグループは、サブフレームと呼ばれる信号成分または構造内に含まれ、サブフレームのグループは、媒体フレームと呼ばれる信号成分または構造内に含まれる。サブフレームは、それぞれのサイズおよびデータ転送の使用に依存して、１つ以上のパケットを含み、媒体フレームは１つ以上のサブフレームを含む。本発明によって採用されるプロトコルによって与えられる最大のサブフレームは、２３２−１または４，２９４，９６７，２９５のオーダのバイトであり、したがって、最大の媒体フレームのサイズは、２１６−１または６５，５３５のオーダのサブフレームになる。
【００７５】
特定のヘッダパケットは、別途記載されるように、各サブフレームの始めに現れる固有の識別子を含む。その識別子は、ホストとクライアントとの間の通信が開始されるときに、クライアントデバイスにおけるフレームのタイミングを得るのにも使用される。リンクのタイミングの捕捉は、別途より詳しく記載される。
【００７６】
一般に、フルモーションビデオが表示されるとき、ディスプレイスクリーンは、１媒体フレーム当たりに１回更新される。表示フレームレートは、媒体フレームレートと同じである。リンクプロトコルは、希望の応用に依存して、ディスプレイ全体のフルモーションビデオか、または単に、静的画像によって取り囲まれたフルモーションビデオコンテントの小さい領域を支援する。ウエブページまたは電子メールの表示のような、いくつかの低電力のモバイルの応用では、ディスプレイスクリーンは、ときどき更新されることのみを必要とし得る。これらの状況では、１つのサブフレームを伝送し、次に、リンクを遮断または非活動にして、電力消費を最小化することが好都合である。インターフェイスは、ステレオビジョンのような効果も支援し、図形要素を処理する。
【００７７】
サブフレームは、定期的に高優先度のパケットの伝送を可能にするために存在する。これは、同時等時性ストリームが最少量のデータ緩衝で共存することを可能にする。これは、本発明が、多数のデータストリーム（ビデオ、音声、制御、状態、ポインティングデバイスデータ、等の高速通信）が共通チャネルを本質的に共用することを可能にするディスプレイの処理を与える１つの長所である。これは、比較的に少ない信号を使用して情報を転送する。これは、ＣＲＴモニタにおける水平方向同期パルスおよびブランキング間隔のような、表示技術専用の動作が存在することも可能にする。
【００７８】
Ｆ．リンク制御装置
図４および５に示されているＭＤＤＩリンク制御装置は、ＭＤＤＩのデータおよびストローブ信号を受信するのに使用される差動ライン受信機を除いて、完全にディジタルの構成であるように製造されるか、または組立てられる。しかしながら、差動ラインドライバおよび受信機でさえ、リンク制御装置をもつ同じディジタル集積回路において実行されることができる。リンク制御装置のハードウエアを実行するのに、アナログ機能またはフェーズロックループ（phase lock loop, PLL）は不要である。ホストおよびクライアントのリンク制御装置は、リンク同期のための状態機械を含むディスプレイインターフェイスを除いて、非常に類似した機能を含む。したがって、本発明は、ホストまたはクライアントの何れかとして構成されることができる単一の制御装置の設計または回路を生成でき、したがって、全体として、リンク制御装置のための製造コストを低減することができるという実際的な長所を可能にする。
【００７９】
ＩＶ．インターフェイスリンクプロトコル
Ａ．フレーム構造
パケット転送のための順方向リンク通信を実行するのに使用される信号プロトコルまたはフレーム構造は、図６に示されている。図６に示されているように、情報またはディジタルデータは、パケットとして知られている要素にグループ化される。次に、多数のパケットは、一緒にグループ化されて、“サブフレーム”と呼ばれるものを形成し、次に、多数のサブフレームは、一緒にグループ化されて、“媒体”フレームを形成する。フレームの形成およびサブフレームの転送を制御するために、各サブフレームは、サブフレームヘッダパケット（Sub-Frame Header Packet, SHP）と呼ばれる、特別に予め定義されたパケットで始まる。
【００８０】
ホストデバイスは、所与の転送に使用されるデータレートを選択する。このレートは、ホストの最大転送能力、またはホストによって源から検索されるデータと、ディスプレイ、またはデータが転送される他のデバイスの最大能力との両者に基づいて、ホストデバイスによって動的に変更されることができる。
【００８１】
ＭＤＤＩまたは発明的な信号プロトコルで動作するように設計された、または動作することができる受信者のクライアントデバイスは、使用できる最大の、または現在最大のデータ転送レート、あるいは使用され得るデフォルトのより緩慢な最低レート、あるいは支援される使用可能なデータレートおよび特徴を判断するために、ホストによって照会されることができる。この情報は、別途さらに記載されるように、ディスプレイ能力パケット（Display Capability Packet, DCP）を使用して転送されることができる。クライアントのディスプレイデバイスは、インターフェイスを使用して、予め選択された最低データレートで、または最低データレートの範囲内で、データを転送するか、または他のデバイスと通信することができ、ホストは、この範囲内のデータレートを使用して照会を行い、クライアントデバイスの全能力を判断することになる。
【００８２】
ディスプレイのビットマップおよびビデオフレームレート能力の性質を定義する他の状態情報は、状態パケットでホストに転送されることができ、その結果、ホストは、インターフェイスを、実用上、または任意のシステムの制約内で希望に応じて、効率的または最適であるように構成することができる。
【００８３】
ホストは、現在のサブフレーム内に（最早）転送されるデータパケットがないとき、または順方向リンクのために選択されたデータ伝送レートと速さを合わせるのに十分なレートで転送することができないとき、フィラーパケットを送る。各サブフレームは、サブフレームヘッダパケットから始まるので、前のサブフレームの最後は、前のサブフレームを正確に充填するパケット（フィラーパケットである可能性が最も高い）を含む。データを乗せたパケット自体の余白が不十分である場合は、フィラーパケットは、サブフレーム内の最後のパケットか；もう１つ前のサブフレームの最後で、サブフレームヘッダパケットの前かである可能性が最も高くなる。サブフレーム内で伝送される各パケットのために、そのサブフレームに十分な余白が残っていることを保証することは、ホストデバイスの制御動作のタスクである。同時に、ホストデバイスは、データパケットの送付を開始すると、フレーム内のそのサイズのパケットを、データ不足状態を招くことなく、完全なものにするのに成功できなければならない。
【００８４】
実施形態の１つの態様では、サブフレームの伝送には２つのモードがある。一方のモードは、生のビデオおよびオーディオストリームを伝送するのに使用される周期的サブフレームモードである。このモードでは、サブフレームの長さは、ゼロ以外であるように定められる。第２のモードは、非同期または非周期的モードであり、このモードでは、新しい情報が使用可能であるときのみ、フレームを使用して、ビットマップデータをディスプレイデバイスへ与える。このモードは、サブフレームヘッダパケット内のサブフレーム長をゼロに設定することによって定義される。周期的モードを使用する場合は、サブフレームパケットの受信は、ディスプレイが順方向リンクのフレーム構造に同期したときに始まることができる。これは、図４９または６３に関連して別途記載される状態図にしたがって定められる“同期（in sync）”状態に対応する。非同期の非周期的サブフレームモードでは、受信は、第１のサブフレームヘッダパケットが受信された後で始まる。
【００８５】
Ｂ．全体的なパケット構造
本発明によって実行されるシグナリングプロトコルを形成するのに使用されるパケットのフォーマットまたは構造は、インターフェイスが拡張可能であり、かつ追加のパケット構造を希望に応じて追加できることを想定して、別途記載される。パケットは、異なる“パケットタイプ”として、インターフェイスにおけるそれらの機能、すなわちそれらが転送する命令またはデータに関して示されるか、または分割される。したがって、各パケットタイプは、所与のパケットの予め定義されたパケット構造を示し、転送されるパケットおよびデータを処理するのに使用される。容易に明らかになるように、パケットは、予め選択された長さをもっていても、あるいはそれぞれの機能に依存して、可変または動的に変更可能な長さをもっていてもよい。パケットは異なる名前をもつこともできるが、標準へ受け入れられる間に、プロトコルが変更されるときに行うことができるのと、同じ機能が、なお実現される。種々のパケット内で使用されるバイトまたはバイト値は、多数のビット（８または１６ビット）の無符号整数として構成される。採用されるパケットの概要は、タイプ順に示されている“タイプ”の名称と共に、表６に示されている。パケットの転送が有効であると考えられる方向も、それらがタイプＵのインターフェイスで使用されるかどうかと共に示されている。
【表６】
2011176810.tif 000008
【００８６】
パケットは、パケット長フィールド、パケットタイプフィールド、データバイトフィールド、およびＣＲＣフィードを含む共通の基本構造または最小フィールドの全体的な組をもち、これは図７に示されている。図７に示されているように、パケット長フィールドは、情報を多数のビットまたはバイト値の形で含み、これは、パケット内のビットの総数、すなわちパケット長フィールドからＣＲＣフィールドまでの長さを特定している。１つの実施形態では、パケット長フィールドは、１６ビットまたは２バイトの幅の無符号整数を含み、パケット長を特定している。パケットタイプフィールドは、パケット内に含まれている情報のタイプを示す別の多数のビットのフィールドである。例示的な実施形態では、これは、８ビットまたは１バイトの幅の値であり、８ビットの無符号整数の形をとり、表示能力、ハンドオフ、ビデオまたはオーディオストリーム、状態、等のようなデータタイプを特定する。
【００８７】
第３のフィールドは、データバイトフィールドであり、これは、そのパケットの一部としてホストとクライアントデバイスとの間で転送または送付されるビットまたはデータを含んでいる。データのフォーマットは、転送されるデータの特定のタイプにしたがって、各パケットタイプごとに明確に定められ、一連の追加フィールドに分割されることができ、各々は自分自身のフォーマット要件をもつ。したがって、各パケットタイプは、この部分またはフィールドのための定められたフォーマットをもつことになる。最後のフィールドは、ＣＲＣフィールドであり、これは、データバイト、パケットタイプ、およびパケット長フィールドにわたって計算される１６ビットの巡回冗長検査の結果を含み、パケット内の情報の保全性を確認するのに使用される。言い換えると、ＣＲＣフィールド自体を除いたパケット全体にわたって計算される。クライアントは、通常、検出されたＣＲＣの誤りの総数を維持し、この数をディスプレイの要求および状態パケット（別途記載する）においてホストへ報告する。
【００８８】
パケットを転送する間に、フィールドは、最初に最下位ビット（Least Significant Bit, LSB）で始まり、最後に伝送される最上位ビット（Most Significant Bit, MSB）で終了するように伝送される。２バイト長を越えるパラメータは、最初に最下位バイトを使用して伝送され、これは、８ビット長よりも長いパラメータに使用されるのと同じビット伝送パターンになり、ＬＳＢが最初に伝送される場合は、より短いパラメータに使用される。ＭＤＤＩ Ｄａｔａ０の信号経路上のデータは、タイプＩ、タイプＩＩ、タイプＩＩＩ、またはタイプＩＶのモードの何れかで、インターフェイス上で伝送されるバイトのビット‘０’と整列させられる。
【００８９】
表示のためにデータを処理するとき、画素のアレイのデータは、電子工学の分野において従来より行われてきたように、最初に、行、その後で、列ごとに伝送される。言い換えると、ビットマップ内の同じ行内に現れる全画素は、最左画素を最初に伝送し、最右画素を最後に伝送する順序で伝送される。行の最右画素が伝送されると、列内の次の画素が、次の行の最左画素になる。画素の行は、通常、大抵のディスプレイにおいて、上から下へ順番に伝送されるが、必要に応じて、他の構成に適応することができる。さらに加えて、ビットマップの処理において、本明細書において後で示されるアプローチでは、ビットマップの最左角部を、位置またはオフセット“０，０”として示すことによって、基準点を定める。ビットマップ内の位置を定めるか、または判断するのに使用されるＸおよびＹ座標は、それぞれ、ビットマップの右および下に近付くにしたがって値を増加する。第１の行および第１の列は、ゼロの指標値で始まる。
【００９０】
Ｃ．パケットの定義
１．サブフレームヘッダパケット
サブフレームヘッダパケットは、全てのサブフレームの第１のパケットであり、図８に示されている基本構造をもつ。図８に見られ得るように、このタイプのパケットは、パケット長、パケットタイプ、ユニークワード、サブフレーム長、プロトコルバージョン、サブフレームカウント、および媒体フレームカウントのフィールドを、通常この順番でもつように構成されている。このタイプのパケットは、通常、タイプ２５５（０ｘｆｆの１６進法）のパケットとして識別され、１７バイトの予め選択された固定長を使用する。
【００９１】
パケットタイプフィールドが１バイト値を使用する一方で、ユニークワードフィールドは、３バイト値を使用する。これらの２つのフィールドを一緒にした４バイトの組合せは、好適な自己相関をもつ３２ビットのユニークワードを形成する。例示的な実施形態では、実際のユニークワードは、０ｘ００５ａ３ｂｆｆであり、ここでは、最初に、下位の８ビットがパケットタイプとして伝送され、その後で最上位の２４ビットが伝送される。
【００９２】
サブフレーム長フィールドは、４バイトの情報を含み、１サブフレーム当たりのバイト数を特定する。このフィールドの長さは、リンクがアイドル状態に遮断される前に、１つのみのサブフレームがホストによって伝送されることを示すために、ゼロに等しく設定されてもよい。このフィールドの値は、１つのサブフレームから次のサブフレームへ遷移するときに、“実行中に（on-the-fly）”動的に変更されることができる。この能力は、等時性データストリームに適応するために、同期パルスにおけるタイミングの微調整を行うのに有益である。サブフレームヘッダパケットのＣＲＣが有効でないときは、リンク制御装置は、既に分かっている好適なサブフレームヘッダパケットのサブフレーム長を使用して、現在のサブフレームの長さを推定すべきである。
【００９３】
プロトコルバージョンフィールドは、２バイトを含み、ホストによって使用されるプロトコルバージョンを特定する。プロトコルバージョンフィールドは、第１の、または使用されている現在のプロトコルバージョンを特定するために、‘０’に設定される。新しいバージョンが生成されると、この値は時間にしたがって変化する。サブフレームカウントフィールドは、２バイトを含み、媒体フレームの最初から、伝送されたサブフレーム数を示す順序番号を特定する。媒体フレームの第１のサブフレームは、ゼロのサブフレーム数をもつ。ｎが、１媒体フレーム当たりのサブフレーム数であるとして、媒体フレームの最後のサブフレームは、ｎ−１の値をもつ。サブフレーム長が、ゼロに等しく設定される（非周期的サブフレームを示す）とき、サブフレーム数も、ゼロに等しく設定されなければならないことに注意すべきである。
【００９４】
媒体フレームカウントフィールドは、３バイトを含み、転送されているこの現在の媒体項目またはデータの始めから、伝送された媒体フレーム数を示す順序番号を特定する。媒体項目の第１の媒体フレームは、ゼロの媒体フレームカウントをもつ。媒体フレームカウントは、各媒体フレームの第１のサブフレームの直前にインクリメントし、最大媒体フレームカウント（例えば、媒体フレーム数２２４−１＝１６，７７７，２１５）が使用された後で、ゼロに折り返される。媒体フレームのカウント値は、一般に、最後の応用の要求に適するように、ホストによって、ほぼいつでもリセットされ得る。
【００９５】
２．フィラーパケット
フィラーパケットは、順方向リンクまたは逆方向リンクの何れにおいても送られるのに使用可能な情報が他にないときに、クライアントデバイスへ、またはクライアントデバイスから転送されるパケットである。フィラーパケットは、要求に応じて他のパケットを送るときに最大の融通性を可能にするために、最短長をもつことが推奨される。リンク制御装置は、サブフレームまたは逆方向リンクカプセル化パケット（別途記載する）の最も最後において、パケットの保全性を維持するために、残りの余白を充填するためのフィラーパケットのサイズを設定する。
【００９６】
フィラーパケットのフォーマットおよび内容は、図９に示されている。図９に示されているように、このタイプのパケットは、パケット長、パケットタイプ、フィラーバイト、およびＣＲＣのフィールドをもつように構成されている。このタイプのパケットは、通常、タイプ０として識別され、１バイトのタイプフィールドにおいて示される。フィラーバイトフィールド内のビットまたはバイトは、可変数の全てゼロのビット値を含み、フィラーパケットが希望の長さになることを可能にする。最小のフィラーパケットは、このフィールド内にバイトを含まない。したがって、パケットは、パケット長、パケットタイプ、およびＣＲＣのみから成り、３バイトの予め選択された固定長を使用する。
【００９７】
３．ビデオストリームパケット
ビデオストリームパケットは、ビデオデータを保持し、ディスプレイデバイスの一般に長方形の領域を更新する。この領域のサイズは、１画素と同じくらい小さくても、またはディスプレイ全体と同じくらい大きくてもよい。ストリームを表示するのに必要とされる全文脈は、ビデオストリームパケット内に含まれているので、同時に表示されるストリームは、ほぼ無制限であり、システム資源によって制限され得る。ビデオストリームパケット（ビデオデータフォーマット記述子）のフォーマットは、図１０に示されている。図１０に示されているように、このタイプのパケットは、パケット長（２バイト）、パケットタイプ、ビデオデータ記述子、表示属性、Ｘの左端、Ｙの上端、Ｘの右端、Ｙの下端、Ｘ開始、Ｙ開始、画素カウント、パラメータのＣＲＣ、画素データ、およびＣＲＣのフィールドをもつように構成されている。このタイプのパケットは、通常、タイプ１として識別され、これは、１バイトのタイプフィールドにおいて示されている。
【００９８】
既に記載された共通フレームの概念は、オーディオ緩衝サイズを最小化し、待ち時間を低減する効率的なやり方である。しかしながら、ビデオデータでは、１つのビデオフレームの画素を媒体フレーム内の多数のビデオストリームパケットの全体にわたって拡散することが必要であり得る。また、１つのビデオストリームパケットが、ディスプレイ上の完全に長方形のウインドウに正確に対応しなくなることがよく起こり得る。１秒当たりに３０フレームのビデオフレームレートの例では、１秒当たりに３００サブフレームがあり、したがって、１媒体フレーム当たりに１０サブフレームになる。各フレームにおいて画素の４８０行があるとき、各サブフレーム内の各ビデオストリームパケットは、画素の４８行を含むことになる。他の状況では、ビデオストリームパケットは、画素の整数の行を含まないことがある。１媒体フレーム当たりのサブフレームの数が、１ビデオフレーム当たりの行の数（ビデオラインとしても知られている）へ均等に分割されないとき、他のビデオフレームのサイズについても当てはまる。各ビデオストリームパケットは、整数の行の画素を含まないことがあっても、通常は、整数の画素を含まなければならない。それぞれ画素が１バイトよりも大きいか、または図１２に示されているのようなパックされたフォーマットであるとき、これは重要である。
【００９９】
既に記載したように、例示的なビデオデータ記述子フィールドの動作を実現するために採用されるフォーマットおよび内容は、図１１ａないし１１ｄに示されている。図１１ａないし１１ｄにおいて、ビデオデータフォーマット記述子フィールドは、２バイトを１６ビットの無符号整数の形で含み、このパケット内のこのストリーム内の画素データ内の各画素のフォーマットを特定する。異なるビデオストリームパケットは、異なる画素データフォーマットを使用し、すなわち、ビデオデータフォーマット記述子において異なる値を使用してもよく、同様に、ストリーム（ディスプレイの領域）は、そのデータフォーマットを実行中に変更してもよいことが可能である。ビデオデータフォーマット記述子は、このパケットの画素フォーマットを定めており、これのみでは、一定のフォーマットが、個々のビデオストリームの存続期間の間に使用され続けることになることを示唆しない。
【０１００】
図１１ａないし１１ｄは、ビデオデータフォーマット記述子がどのように符号化されるかを示している。これらの図において使用されているように、この実施形態では、図１１ａに示されているように、ビット[１５：１３]が、‘０００’に等しいとき、ビデオデータは、モノクロームの画素のアレイから成り、ここで、１画素当たりのビットの数は、ビデオデータフォーマット記述子のワードのビット３ないし０によって定められる。ビット１１ないし４は、この状況ではゼロに設定される。その代りに、図１１ｂに示されているように、ビット[１５：１３]が、‘００１’に等しいとき、ビデオデータは、各々がカラーマップによって色を特定するカラーの画素のアレイから成る。この状況では、ビデオデータフォーマット記述子のビット５ないし０は、１画素当たりビット数を定め、ビット１１ないし６はゼロに等しく設定される。その代りに、図１１ｃに示されているように、ビット[１５：１３]が‘０１０’に等しいときは、ビデオデータは、カラーの画素のアレイであって、赤の１画素当たりのビットの数は、ビット１１ないし８によって定められ、緑の１画素当たりのビットの数は、ビット７ないし４によって定められ、青の１画素当たりのビットの数は、ビット３ないし０によって定められるものから成る。この状況では、各画素内のビットの総数は、赤、緑、または青に使用されるビット数の和である。
【０１０１】
しかしながら、その代りに、図１１ｄに示されているように、ビット[１５：１３]が、 ‘０１１’に等しいときは、ビデオデータは、輝度およびクロミナンス情報をもつ４：２：２のフォーマットのビデオデータのアレイから成り、輝度（Ｙ）の１画素当たりのビット数は、ビット１１ないし８によって定められ、Ｃｒ成分のビット数は、ビット７ないし４によって定められ、Ｃｂ成分のビット数は、ビット３ないし０によって定められる。各画素内のビットの総数は、赤、緑、および青に使用されるビット数の和である。ＣｒおよびＣｂ成分は、Ｙの２分の１レートで送られる。さらに加えて、このパケットの画素データ部分のビデオサンプルは、Ｙｎ、Ｃｒｎ、Ｃｂｎ、Ｙｎ＋１、Ｙｎ＋２、Ｃｒｎ＋２、Ｃｂｎ＋２、Ｙｎ＋３、．．．のように編成され、ここで、ＣｒｎおよびＣｂｎはＹｎおよびＹｎ＋１と関係付けられ、Ｃｒｎ＋２およびＣｂｎ＋２はＹｎ＋２およびＹｎ＋３と関係付けられる、等である。このストリーム内の行（Ｘの右端−Ｘの左端＋１）内に奇数の画素があるときは、各行内の最後の画素に対応するＣｂ値の後には、次の行の最初の画素のＹ値が続く。
【０１０２】
図に示されている全部で４つのフォーマットにおいて、“Ｐ”として示されているビット１２は、画素データサンプルがパックされているか、すなわちバイトを整列させた画素データであるかどうかを特定している。このフィールド内の‘０’の値は、画素データフィールドにおける各画素と各画素内の各色とが、ＭＤＤインターフェイスのバイトの境界とバイトを整列させていることを示す。‘１’の値は、画素データにおける各画素と各画素内の各色とが、前の画素または画素内の色に対してパックされ、未使用のビットが残っていないことを示す。
【０１０３】
個々のディスプレイウインドウにおける媒体フレームの第１のビデオストリームパケット内の第１の画素は、Ｘの左端およびＹの上端によって定められるストリームウインドウの左上角部に行くことになり、受信される次の画素は、同じ行内の次の画素の位置に置かれる、等。媒体フレームのこの第１のパケットでは、Ｘの開始値は、通常は、Ｘの左端に等しく、Ｙの開始値は、通常は、Ｙの上端に等しい。同じスクリーンウインドウに対応する次のパケットでは、ＸおよびＹの開始値は、通常は、前のサブフレーム内で伝送されたビデオストリームパケット内で送られた最後の画素の後に大抵続いているスクリーンウインドウ内の画素の位置に設定されることになる。
【０１０４】
４．オーディオストリームパケット
オーディオストリームパケットは、ディスプレイのオーディオシステムによって、またはスタンドアローン形オーディオ提示デバイスにおいて再生されるオーディオデータを乗せている。異なるオーディオデータストリームは、音響システムにおける別々のオーディオチャネル、使用されているオーディオシステムのタイプに依存して、例えば、左前、右前、中央、左後、右後に割り振られ得る。向上した空間−音響信号処理を含む、オーディオチャネルを完全に補足するものは、ヘッドセットに与えられている。オーディオストリームパケットのフォーマットは、図１３に示されている。図１３に示されているように、このタイプのパケットは、パケット長、パケットタイプ、オーディオチャネルＩＤ、オーディオサンプルカウント、１サンプル当たりのビットおよびパッキング、オーディオサンプルレート、パラメータのＣＲＣ、ディジタルオーディオデータ、並びにオーディオデータのＣＲＣのフィールドをもつように構成されている。１つの実施形態では、このタイプのパケットは、通常、タイプ２のパケットとして識別される。
【０１０５】
１サンプルおよびパッキング当たりのビットのフィールドは、１バイトを８ビットの無符号整数の形で含み、オーディオデータのパッキングフォーマットを特定する。通常採用されるフォーマットは、ビット４ないし０において、１ＰＣＭオーディオサンプル当たりのビット数を定めている。次に、ビット５は、ディジタルオーディオデータサンプルがパックされているかどうかを特定する。パックされたオーディオサンプルと、バイトを整列させたオーディオサンプルとの間の違いは、図１４に示されている。‘０’の値は、ディジタルオーディオデータフィールド内の各ＰＣＭオーディオサンプルが、ＭＤＤＩインターフェイスのバイトの境界とバイトを整列させられていることを示し、‘１’の値は、各連続するＰＣＭオーディオサンプルが、前のオーディオサンプルに接してパックされていることを示している。このビットは、ビット４ないし０に定められている値（１ＰＣＭオーディオサンプル当たりのビット数）が８の倍数でないときのみ、効果的である。ビット７ないし６は、将来の使用のために確保され、通常、ゼロの値に設定される。
【０１０６】
５．確保されたストリームパケット
１つの実施形態では、パケット３ないし５５は、直面している種々の応用に対する希望に応じて、パケットプロトコルの将来のバージョンまたはバリエーションにおいて使用するために定められるストリームパケットのために確保される。ここでも、これは、他の技術と比較して、変化し続ける技術およびシステムの設計であるにもかかわらず、ＭＤＤインターフェイスをより融通が利き、かつ有益なものにすることの一部である。
【０１０７】
６．ユーザ定義のストリームパケット
タイプ５６ないし６３として知られている、８個のデータストリームタイプは、ＭＤＤＩリンクで使用するために、装置の製造者によって定義され得る所有権を保護された応用において使用するために確保され得る。これらは、ユーザ定義のストリームパケットとして知られている。ビデオストリームパケットは、ディスプレイの長方形領域を更新する（または、しない）ためのビデオデータを乗せている。これらのパケットタイプのためのストリームパラメータおよびデータの定義は、その使用を求めている特定の装置の製造者に任されている。ユーザ定義のストリームパケットのフォーマットは、図１５に示されている。図１５に示されているように、このタイプのパケットは、パケット長（２バイト）、パケットタイプ、ストリームＩＤ番号、ストリームパラメータ、パラメータのＣＲＣ、ストリームデータ、およびストリームデータのＣＲＣのフィールドをもつように構成されている。
【０１０８】
７．カラーマップパケット
カラーマップパケットは、ディスプレイに色を提示するのに使用されるカラーマップルックアップテーブルの内容を特定する。いくつかの応用では、１つのパケット内で伝送されることができるデータ量よりも多いカラーマップを必要とすることがある。これらの場合には、別途記載されるオフセットおよび長さフィールドを使用することによって、各カラーマップがカラーマップの異なるサブセットをもつ、多数のカラーマップパケットが転送される。カラーマップパケットのフォーマットは、図１６に示されている。図１６に示されているように、このタイプのパケットは、パケット長、パケットタイプ、カラーマップデータサイズ、カラーマップオフセット、パラメータのＣＲＣ、カラーマップデータ、およびデータＣＲＣのフィールドをもつように構成されている。このタイプのパケットは、通常、タイプ６４のパケットとして識別されている。
【０１０９】
８．逆方向リンクカプセル化パケット
例示的な実施形態では、データは、逆方向リンクカプセル化パケットを使用して、逆方向で転送される。順方向リンクパケットが送られ、このパケットの途中で、ＭＤＤＩリンクの動作（転送方向）が変更されるか、または折り返され、その結果、パケットは逆方向で送られることができる。逆方向リンクカプセル化パケットのフォーマットは、図１７に示されている。図１７に示されているように、このタイプのパケットは、パケット長、パケットタイプ、逆方向リンクフラグ、折り返し長、パラメータのＣＲＣ、折り返し１、逆方向データパケット、および折り返し２のフィールドをもつように構成されている。このタイプのパケットは、通常、タイプ６５のパケットとして識別されている。
【０１１０】
ＭＤＤＩリンク制御装置は、特定の様式で動作し、一方で逆方向リンクカプセル化パケットを送る。ＭＤＤインターフェイスは、ホストによって常に駆動されるストローブ信号をもっている。ホストは、それが、逆方向リンクカプセル化パケットの折り返しおよび逆方向データパケットの部分の各ビットにゼロを伝送しているかのように動作する。ホストは、２つの折り返し時間中および逆方向データパケットに割り振られた時間中に、各ビット境界においてＭＤＤＩ Ｓｔｒｏｂｅ信号を切換える。（これは、それが全てゼロのデータを送っているのと同じ動作である。）ホストは、折り返し１によって特定される時間期間中に、そのＭＤＤＩデータ信号ラインドライバをディスエーブルし、クライアントは、折り返し２フィールドによって特定される時間期間の後のドライバ再イネーブルフィールド中に、そのラインドライバを再イネーブルする。ディスプレイは、折り返し長パラメータを読み出し、折り返し１フィールド内の最後のビットの直後に、ホストへデータ信号を駆動する。ディスプレイは、パケット長および折り返し長パラメータを使用して、パケットをホストへ送るのに使用可能な時間長を知る。クライアントは、ホストへ送るデータをもたないとき、フィラーパケットを送るか、またはデータラインをゼロの状態へ駆動してもよい。データラインがゼロに駆動されると、ホストは、これを、ゼロの長さをもつ（有効な長さをもたない）パケットとして解釈し、ホストは、現在の逆方向リンクカプセル化パケットの間に、クライアントからパケットをそれ以上受取らない。
【０１１１】
クライアントのディスプレイは、折り返し２フィールドの開始前の、少なくとも１つの逆方向リンククロック期間の間に、ＭＤＤＩデータラインをゼロのレベルに駆動する。これは、折り返し２の時間期間中に、データラインを決定性状態に維持する。（別途記載される）休止状態バイアスレジスタは、逆方向データパケットフィールドの残りの間データラインをゼロのレベルに維持するので、クライアントは、送るためのパケットをこれ以上もたないときは、それらをゼロのレベルに駆動した後で、データラインをディスエーブルにさえしてもよい。
【０１１２】
ディスプレイ要求および状態パケットの逆方向リンク要求フィールドは、ホストへデータを送るための逆方向リンクカプセル化パケットにおいて、ディスプレイが必要とするバイト数についてホストに知らせるために使用されることができる。ホストは、逆方向リンクカプセル化パケット内に、少なくともそのバイト数を割り振ることによって要求を承認することを試みる。ホストは、サブフレームにおいて、２つ以上の逆方向リンクカプセル化パケットを送ってもよい。ディスプレイは、ディスプレイ要求および状態パケットをほぼいつでも送ることができ、ホストは、逆方向リンク要求パラメータを、１つのサブフレームにおいて要求される総バイト数として解釈することになる。
【０１１３】
９．ディスプレイ能力パケット
ホストは、ホストからディスプレイへのリンクを、ほぼ最適な、または希望のやり方で構成するために、それが通信しているディスプレイ（クライアント）の能力を知る必要がある。順方向リンクの同期が得られた後で、ディスプレイはディスプレイ能力パケットをホストへ送るように勧められる。このようなパケットの伝送は、ホストによって逆方向リンクカプセル化パケット内の逆方向リンクフラグを使用して要求されるときに、要求されると考えられる。ディスプレイ能力パケットのフォーマットは、図１８に示されている。図１８に示されているように、このタイプのパケットは、パケット長、パケットタイプ、プロトコルバージョン、最低プロトコルバージョン、ビットマップの幅、ビットマップの高さ、モノクローム能力、カラーマップ能力、ＲＧＢ能力、Ｙ Ｃｒ Ｃｂ能力、ディスプレイ特徴能力、データレート能力、フレームレート能力、オーディオ緩衝器深度、オーディオストリーム能力、オーディオレート能力、最小サブフレームレート、およびＣＲＣのフィールドをもつように構成されている。例示的な実施形態では、このタイプのパケットは、通常、タイプ６６のパケットとして識別されている。
【０１１４】
１０．キーボードデータパケット
キーボードデータパケットは、クライアントデバイスからホストへキーボードデータを送るのに使用される。ワイヤレス（またはワイヤード）のキーボードは、制限はしないが、とくに、ヘッドマウント形ビデオ表示／オーディオ提示デバイスを含む、種々のディスプレイまたはオーディオデバイスに関連して使用されることができる。キーボードデータパケットは、いくつかの既知のキーボードのようなデバイスの中の１つから受信されたキーボードデータを、ホストへ中継する。このパケットは、データをキーボードへ送るために、順方向リンク上でも使用されることができる。キーボードデータパケットのフォーマットは図１９に示されており、キーボードからの、またはキーボードへの種々のバイト数の情報を含む。図１９に示されているように、このタイプのパケットは、パケット長、パケットタイプ、キーボードデータ、およびＣＲＣのフィールドをもつように構成されている。本明細書では、このタイプのパケットは、通常、タイプ６７パケットとして識別されている。
【０１１５】
１１．ポインティングデバイスデータパケット
ポインティングデバイスデータパケットは、無線マウスまたは他のポインティングデバイスからの位置情報を、ディスプレイからホストへ送るのに使用される。このパケットを使用して、データは、順方向リンク上でポインティングデバイスへ送られることもできる。ポインティングデバイスデータパケットの例示的なフォーマットは、図２０に示されており、ポインティングデバイスからの、またはポインティングデバイスへの種々のバイト数の情報を含む。図２０に示されているように、このタイプのパケットは、パケット長、パケットタイプ、ポインティングデバイスデータ、およびＣＲＣのフィールドをもつように構成されている。例示的な実施形態では、このタイプのパケットは、通常、タイプ６８のパケットとして１バイトのタイプフィールドにおいて識別されている。
【０１１６】
１２．リンク遮断パケット
リンク遮断パケットは、ホストからクライアントディスプレイへ送られ、ＭＤＤＩデータおよびストローブが遮断され、低電力消費の“休止”状態になることを示す。静的なビットマップが、移動通信デバイスからディスプレイへ送られた後か、またはホストからクライアントへ転送する情報が他にしばらくの間ないとき、このパケットは、リンクを遮断し、電力を保存するのに役立つ。ホストがパケットを再び送るとき、正規の動作が再開される。休止状態の後で送られる最初のパケットは、サブフレームヘッダパケットである。ディスプレイ状態パケットのフォーマットは、図２１に示されている。図２１に示されているように、このタイプのパケットは、パケット長、パケットタイプ、およびＣＲＣのフィールドをもつように構成されている。１つの実施形態では、このタイプのパケットは、通常、タイプ６９のパケットとして１バイトのタイプフィールドにおいて識別され、３バイトの予め選択された固定長を使用する。
【０１１７】
低電力の休止状態では、ＭＤＤＩ Ｄａｔａドライバは、高インピーダンス状態にディスエーブルされ、ＭＤＤＩ Ｄａｔａ信号は、ディスプレイによってオーバードライブされ得る高インピーダンスバイアスネットワークを使用して、論理ゼロ状態へ引っ張られる。インターフェイスによって使用されるストローブ信号は、休止状態において論理ゼロのレベルへ設定され、電力消費を最小化する。別途記載されるように、ホストまたはクライアントの何れかが、ＭＤＤＩリンクを、休止状態から“起動”させることができ、これは、本発明の重要な向上および長所である。
【０１１８】
１３．ディスプレイ要求および状態パケット
ホストは、ホストからディスプレイへのリンクをほぼ最適なやり方で構成できるようにするために、ディスプレイからの少量の情報を必要とする。ディスプレイは、各サブフレームにおいて、１つのディスプレイ状態パケットをホストへ送ることを勧められる。ディスプレイは、逆方向リンクカプセル化パケットにおいて、このパケットを第１のパケットとして送り、それがホストへ確実に送られることを保証すべきである。ディスプレイ状態パケットのフォーマットは、図２２に示されている。図２２に示されているように、このタイプのパケットは、パケット長、パケットタイプ、逆方向リンク要求、ＣＲＣの誤りカウント、およびＣＲＣのフィールドをもつように構成されている。このタイプのパケットは、通常、タイプ７０のパケットとして１バイトのタイプフィールドにおいて識別され、８バイトの予め選択された固定長を使用する。
【０１１９】
逆方向リンク要求フィールドは、ホストへデータを送るための逆方向リンクカプセル化パケットにおいて、ディスプレイが必要とするバイト数をホストに知らせるのに使用されることができる。ホストは、逆方向リンクカプセル化パケットにおいて、少なくともそのバイト数を割り振ることによって、要求を承認することを試みるべきである。ホストは、データを収めるために、サブフレームにおいて２つ以上の逆方向リンクカプセル化パケットを送ることができる。クライアントは、ディスプレイ要求および状態パケットをいつでも送ることができ、ホストは、逆方向リンク要求パラメータを、１つのサブフレームにおいて要求されるバイトの総数として解釈することになる。逆方向リンクデータがホストへどのように送られるかについての、追加の詳細および特定の例は、後で示される。
【０１２０】
１４．ビットブロック転送パケット
ビットブロック転送パケットは、ディスプレイの領域を任意の方向においてスクロールする手段を与える。この能力をもつディスプレイは、ディスプレイ能力パケットのディスプレイ特徴能力指標フィールドのビット０において、その能力を報告する。ビットブロック転送パケットのフォーマットは、図２３に示されている。図２３に示されているように、このタイプのパケットは、パケット長、パケットタイプ、左上のＸの値、左上のＹの値、ウインドウの幅、ウインドウの高さ、ウインドウのＸの移動、ウインドウのＹの移動、およびＣＲＣフィールドをもつように構成されている。このタイプのパケットは、通常、タイプ７１のパケットとして識別され、１５バイトの予め選択された固定長を使用する。
【０１２１】
フィールドは、移動されるウインドウの左上角部の座標のＸおよびＹの値、移動されるウインドウの幅および高さ、並びにウインドウが水平方向および垂直方向にそれぞれ移動される画素数を特定するのに使用される。最後の２つのフィールドの正の値は、ウインドウを右および下へ、負の値は左および上へそれぞれ移動する。
【０１２２】
１５．ビットマップ区域充填パケット
ビットマップ区域充填パケットは、ディスプレイの領域を１つの色へ容易に初期設定する手段を与える。この能力をもつディスプレイは、ディスプレイ能力パケットのディスプレイ特徴能力指標フィールドのビット１において能力を報告する。ビットマップ区域充填パケットのフォーマットは、図２４に示されている。図２４に示されているように、このタイプのパケットは、パケット長、パケットタイプ、左上のＸの値、左上のＹの値、ウインドウの幅、ウインドウの高さ、データフォーマット記述子、画素区域充填値、およびＣＲＣのフィールドをもつように構成されている。このタイプのパケットは、通常、タイプ７２のパケットとして１バイトのタイプフィールドにおいて識別され、１７バイトの予め選択された固定長を使用する。
【０１２３】
１６．ビットマップパターン充填パケット
ビットマップパターン充填パケットは、ディスプレイの領域を予め選択されたパターンに容易に初期設定する手段を与える。この能力をもつディスプレイは、ディスプレイ能力パケットのディスプレイ特徴能力指標フィールドのビット２において能力を報告する。充填パターンの左上角部は、充填されるウインドウの左上角部と整列させられる。充填されるウインドウが、充填パターンよりも、幅がより広く、高さがより高いときは、パターンは、ウインドウを充填するために、水平方向または垂直方向に何度も繰返され得る。最後に反復されたパターンの右または下は、必要に応じて、端を切り捨てられる。ウインドウが充填パターンよりも小さいときは、充填パターンの右側または下側は、ウインドウに適合するように切り捨てられ得る。
【０１２４】
ビットマップパターン充填パケットのフォーマットは、図２５に示されている。図２５に示されているように、このタイプのパケットは、パケット長、パケットタイプ、左上のＸの値、左上のＹの値、ウインドウの幅、ウインドウの高さ、パターンの幅、パターンの高さ、データフォーマット記述子、パラメータのＣＲＣ、パターンの画素データ、および画素データのＣＲＣのフィールドをもつように構成されている。このタイプのパケットは、通常、タイプ７３のパケットとして１バイトのタイプフィールドにおいて識別されている。
【０１２５】
１７．通信リンクデータチャネルパケット
通信リンクデータチャネルパケットは、ＰＤＡのような高レベルの計算能力をもつディスプレイが、セル電話または無線データポートデバイスのような無線トランシーバと通信するのための手段を与える。この状況において、ＭＤＤＩリンクは、通信デバイスと、モバイルディスプレイをもつコンピューティングデバイスとの間の便利な高速度のインターフェイスとして動作しており、この場合に、このパケットは、デバイスのオペレーティングシステムのデータリンクレイヤにおいてデータを移送する。例えば、このパケットは、ウエブブラウザ、電子メールクライアント、またはＰＤＡ全体が、モバイルディスプレイに組込まれているときに、使用されることができる。この能力をもつディスプレイは、ディスプレイ能力パケットのディスプレイ特徴能力指標フィールドのビット３において能力を報告する。
【０１２６】
通信リンクデータチャネルパケットのフォーマットは、図２６に示されている。図２６に示されているように、このタイプのパケットは、パケット長、パケットタイプ、パラメータのＣＲＣ、通信リンクデータ、および通信データＣＲＣのフィールドをもつように構成されている。このタイプのパケットは、通常、タイプフィールドにおいてタイプ７４として識別されている。
【０１２７】
１８．インターフェイスタイプハンドオフ要求パケット
インターフェイスタイプハンドオフ要求パケットは、ホストが、クライアントまたはディスプレイが既存の、または現在のモードを、タイプＩ（直列）、タイプＩＩ（２ビット並列）、タイプＩＩＩ（４ビット並列）、またはタイプＩＶ（８ビット並列）のモードへシフトすることを要求することを可能にする。ホストは特定のモードを要求する前に、ディスプレイ能力パケットのディスプレイ特徴能力指標フィールドのビット６および７を検査することによって、ディスプレイが希望のモードで動作できることを確認すべきである。インターフェイスタイプハンドオフ要求パケットは、図２７に示されている。図２７に示されているように、このタイプのパケットは、パケット長、パケットタイプ、インターフェイスタイプ、およびＣＲＣのフィールドをもつように構成されている。このタイプのパケットは、通常、タイプ７５のパケットとして識別され、４バイトの予め選択された固定長を使用する。
【０１２８】
１９．インターフェイスタイプ肯定応答パケット
インターフェイスタイプ肯定応答パケットは、ディスプレイによって送られ、インターフェイスタイプハンドオフパケットの受信を確認する。要求されるモード、すなわち、タイプＩ（直列）、タイプＩＩ（２ビット並列）、タイプＩＩＩ（４ビット並列）、またはタイプＩＶ（８ビット並列）のモードは、このパケットにおいてパラメータとしてホストへエコーバックされる。インターフェイスタイプ肯定応答パケットのフォーマットは、図２８に示されている。図２８に示されているように、このタイプのパケットは、パケット長、パケットタイプ、インターフェイスタイプ、およびＣＲＣのフィールドをもつように構成されている。このタイプのパケットは、通常、タイプ７６のパケットとして識別され、４バイトの予め選択された固定長を使用する。
【０１２９】
２０．タイプハンドオフ実行パケット
タイプハンドオフ実行パケットは、ホストが、このパケットにおいて特定されたモードへハンドオフするように、ディスプレイに命令する手段である。これは、インターフェイスタイプハンドオフ要求パケットおよびインターフェイスタイプ肯定応答パケットによって、既に要求され、肯定応答されたものと同じモードである。ホストおよびディスプレイは、このパケットが送られた後で、合意されたモードに切り換わるべきである。ディスプレイは、モードの変更中に、リンクの同期を失い、再び得ることができる。タイプハンドオフ実行パケットのフォーマットは、図２９に示されている。図２９に示されているように、このタイプのパケットは、パケット長、パケットタイプ、およびＣＲＣのフィールドをもつように構成されている。このタイプのパケットは、通常、タイプ７７のパケットとして１バイトタイプのフィールドにおいて識別され、４バイトの予め選択された固定長を使用する。
【０１３０】
２１．順方向オーディオチャネルイネーブルパケット
このパケットは、ホストが、ディスプレイにおいてオーディオチャネルをイネーブルまたはディスエーブルすることを可能にする。この能力は、ホストによってオーディオが出力されないときは、ディスプレイ（クライアント）がオーディオ増幅器または類似の回路素子の電源を切って、電力を節約することができるので、有益である。単に、オーディオストリームがあるか、またはないかを、指標として使用して、暗黙的に実行することは、より相当に困難である。ディスプレイシステムが起動されるときのデフォルト状態は、全てのオーディオチャネルをイネーブルする。順方向オーディオチャネルイネーブルパケットのフォーマットは、図３０に示されている。図３０に示されているように、このタイプのパケットは、パケット長、パケットタイプ、オーディオチャネルイネーブルマスク、およびＣＲＣのフィールドをもつように構成されている。このタイプのパケットは、通常、タイプ７８のパケットとして１バイトのタイプフィールドにおいて識別され、４バイトの予め選択された固定長を使用する。
【０１３１】
２２．逆方向オーディオサンプルレートパケット
このパケットは、ホストが、逆方向リンクオーディオチャネルをイネーブルまたはディスエーブルし、このストリームのオーディオデータサンプルレートを設定することを可能にする。ホストは、ディスプレイ能力パケットにおいて有効であると定義されたサンプルレートを選択する。ホストが無効のサンプルレートを選択すると、ディスプレイは、オーディオストリームをホストへ送らない。ホストは、サンプルレートを２５５に設定することによって、逆方向リンクのオーディオストリームをディスエーブルすることができる。ディスプレイシステムが最初に起動されるか、または接続されるとき、想定されるデフォルト状態では、逆方向リンクオーディオストリームはディスエーブルされる。逆方向オーディオサンプルレートパケットのフォーマットは、図３１に示されている。図３１に示されているように、このタイプのパケットは、パケット長、パケットタイプ、オーディオサンプルレート、およびＣＲＣのフィールドをもつように構成されている。このタイプのパケットは、通常、タイプ７９のパケットとして識別され、４バイトの予め選択された固定長を使用する。
【０１３２】
２３．ディジタルコンテント保護オーバーヘッドパケット
このパケットは、ホストおよびディスプレイが、使用されているディジタルコンテントの保護方法に関するメッセージを交換することを可能にする。現在、２つのタイプのコンテントの保護、すなわち、ディジタル伝送コンテント保護（Digital Transmission Content Protection, DTCP）、または高帯域幅ディジタルコンテント保護システム（High-bandwidth Digital Content Protection System, HDCP）が検討されていて、将来の別の保護方式の設計のため余地が残されている。使用される方法は、このパケット内のコンテント保護タイプパラメータによって特定される。ディジタルコンテント保護オーバーヘッドパケットのフォーマットは、図３２に示されいている。図３２に示されているように、このタイプのパケットは、パケット長、パケットタイプ、コンテント保護タイプ、コンテント保護オーバーヘッドメッセージ、およびＣＲＣのフィールドをもつように構成されている。このタイプのパケットは、通常、タイプ８０のパケットとして識別される。
【０１３３】
２４．透明色イネーブルパケット
透明色イネーブルパケットは、何れの色がディスプレイにおいて透明であるかを特定し、画像を表示するために透明色の使用をイネーブルするか、またはディスエーブルするために使用される。この能力をもつディスプレイは、ディスプレイ能力パケットのディスプレイ特徴能力指標のビット４において、その能力を報告する。透明色の値をもつ画素がビットマップに書き込まれるとき、色は前の値から変わらない。透明色イネーブルパケットのフォーマットは、図３３に示されている。図３３に示されているように、このタイプのパケットは、パケット長、パケットタイプ、透明色イネーブル、データフォーマット記述子、透明の画素の値、およびＣＲＣのフィールドをもつように構成されている。このタイプのパケットは、通常、タイプ８１のパケットとして１バイトのタイプフィールドにおいて識別され、１０バイトの予め選択された固定長を使用する。
【０１３４】
２５．往復遅延測定パケット
往復遅延測定パケットは、ホストからクライアント（ディスプレイ）への伝搬遅延と、クライアント（ディスプレイ）からホストへの遅延との和を測定するのに使用される。この測定値は、本質的に、ラインドライバ、受信機、および相互接続サブシステムに存在する遅延を含む。この測定値は、既に概ね記載された逆方向リンクカプセル化パケット内に、折り返し遅延および逆方向リンクレート除数パラメータを設定するのに使用される。ＭＤＤＩリンクが、特定の応用のための最大速度で実行しているときに、最も有益である。ＭＤＤＩ Ｓｔｂ信号は、全てゼロのデータが、次のフィールド、すなわち、全てゼロ、両者の保護時間、および測定期間の間に送られているように働く。これは、ＭＤＤＩ Ｓｔｂが、測定期間中にディスプレイにおける周期的クロックとして使用されることができるように、ＭＤＤＩ Ｓｔｂを２分の１のデータレートで切り換わるようにする。
【０１３５】
往復遅延測定パケットのフォーマットは、図３４に示されている。図３４に示されているように、このタイプのパケットは、パケット長、パケットタイプ、パラメータのＣＲＣ、全てゼロ、保護時間１、測定期間、保護時間２、およびドライバ再イネーブルのフィールドをもつように構成されている。このタイプのパケットは、通常、タイプ８２のパケットとして識別され、５３３ビットの予め選択された固定長を使用する。
【０１３６】
往復遅延測定パケット中に行われるイベントのタイミングは、図３５に示されている。図３５において、ホストは往復遅延測定パケットを伝送し、これは、パラメータのＣＲＣおよびストローブ整列フィールドの後に、全てゼロおよび保護時間１のフィールドが続いていることが示されている。遅延3502は、パケットがクライアントディスプレイデバイスまたは処理回路に到達する前に現れる。ディスプレイは、パケットを受信すると、ディスプレイによって判断される測定期間の始めに、実際的に正確な０ｘｆｆ、０ｘｆｆ、０ｘ０のパターンを伝送する。ディスプレイがこの系列を伝送し始める実際の時間は、ホストから見た場合、測定期間の始めより遅れている。この遅延量は、実質的に、パケットがラインドライバ、受信機、および相互接続サブシステムによって伝搬するのにかかる時間である。同様の量の遅延3504は、このパターンがディスプレイからホストへ伝搬するときに生じる。
【０１３７】
クライアントとの間をトラバースする信号の往復遅延時間を正確に判断するために、ホストは、０ｘｆｆ、０ｘｆｆ、０ｘ０の系列の開始が到達時に検出されるまで、測定期間の開始後に生じるビット時間期間の数値をカウントする。この情報は、往復信号が、ホストからクライアントへ行き、再び戻るまでの時間量を判断するのに使用される。したがって、この量の約２分の１は、信号がクライアントへ片道で向かう間に生じる遅延に属する。
【０１３８】
ディスプレイは、０ｘｆｆ、０ｘｆｆ、０ｘ０のパターンの最後のビットを送った、ほぼ直後に、そのラインドライバをディスエーブルする。保護時間２は、ホストが次のパケットのパケット長を伝送する前に、ディスプレイのラインドライバが、高インピーダンス状態に完全に入ることを可能にする。休止状態プルアップおよびプルダウン抵抗（図４２参照）は、ＭＤＤＩ Ｄａｔａ信号が、ラインドライバがホストとディスプレイとの両者においてディスエーブルされる間隔で、有効なローレベルに維持されることを保証する。
【０１３９】
２６．順方向リンクスキュー較正パケット
順方向リンクスキュー較正パケットは、クライアントまたはディスプレイが、ＭＤＤＩ Ｓｔｂ信号に対するＭＤＤＩ Ｄａｔａ信号の伝搬遅延の差について自分自身を較正することを可能にする。遅延スキューの補償がないならば、最高データレートは、通常、制限され、これらの遅延における潜在的に最悪の場合のバリエーションを説明する。通常、このパケットは、順方向リンクデータレートが、約５０メガビット秒以下のレートに構成されるときのみ送られる。このパケットを送って、ディスプレイを較正した後で、データレートは、約５０メガビット秒より高くステップアップされることができる。スキュー較正処理中のデータレートの設定が高過ぎるとき、ディスプレイは、ビット期間のエイリアスに同期することがあり、したがって、遅延スキューの補償の設定を、２ビット時間以上ずらし、誤ったデータのクロッキングにし得る。順方向リンクスキュー較正パケットを送って、全ての既存のデータビットが較正される前に、インターフェイスの最高データレートタイプまたは最大可能インターフェイスタイプが選択される。
【０１４０】
順方向リンクスキュー構成パケットのフォーマットは、図５６に示されている。図５６に示されているように、このタイプのパケットは、パケット長（２バイト）、パケットタイプ、パラメータのＣＲＣ、較正データ系列、およびＣＲＣのフィールドをもつように構成されている。このタイプのパケットは、タイプ８３のパケットとしてタイプフィールドにおいて識別され、５１５ビットの予め選択された長さをもつ。
【０１４１】
Ｄ．パケットのＣＲＣ
ＣＲＣフィールドは、パケットの最後に、ときには、相当に大きいデータフィールド、をもち得るパケット内のある特定のより重要なパラメータの後に現れ、したがって、転送中の誤り率は増加する。２つのＣＲＣフィールドをもつパケットにおいて、ＣＲＣ発生器は、１つだけが使用されるときは、最初のＣＲＣの後で再び初期設定され、したがって、長いデータフィールドの後のＣＲＣの計算は、パケットの最初のパラメータによって影響を受けない。
【０１４２】
例示的な実施形態では、ＣＲＣの計算に使用される多項式は、ＣＲＣ−１６、またはＸ１６＋Ｘ１５＋Ｘ２＋Ｘ０として知られている。本発明を実行するのに役立つＣＲＣ発生器およびチェッカ3600のサンプルの実行は、図３６に示されている。図３６では、ＣＲＣレジスタ3602は、Ｔｘ ＭＤＤＩ Ｄａｔａ Ｂｅｆｏｒｅ ＣＲＣのライン上で入力されるパケットの第１のビットの転送の直前に、０ｘ０００１の値に初期設定され、その後で、パケットのバイトは、レジスタでシフトされ、最初にＬＳＢで始まる。この図におけるレジスタのビットの数値は、ＭＤＤＩによって使用されるビット位置ではなく、使用されている多項式の次数に対応していることに注意すべきである。ＣＲＣレジスタを一方向にシフトすることが、より効率的であり、その結果、ＣＲＣビット１５が、ＭＤＤＩのＣＲＣフィールドのビット位置０に、ＣＲＣレジスタビット１４が、ＭＤＤＩのＣＲＣフィールドのビット位置１に現れる、など、ＭＤＤＩビット位置１４に到達するまで行われる。
【０１４３】
例として、ディスプレイ要求および状態パケットのパケット内容は、０ｘ０７、０ｘ４６、０ｘ０００４００、０ｘ００（または、０ｘ０７、０ｘ００、０ｘ４６、０ｘ００、０ｘ０４、０ｘ００、０ｘ００のようなバイトの系列として表わされる）であり、マルチプレクサ3604、3606、およびＮＡＮＤゲート3608の入力を使用して提出されるとき、Ｔｘ ＭＤＤＩ Ｄａｔａ Ｗｉｔｈ ＣＲＣのライン上の結果のＣＲＣ出力は、０ｘ０ｅａ１である（または、０ｘａ１、０ｘ０ｅのような系列として表される）。
【０１４４】
ＣＲＣ発生器およびチェッカ3600がＣＲＣチェッカとして構成されるとき、Ｒｘ ＭＤＤＩ Ｄａｔａライン上で受信されるＣＲＣは、マルチプレクサ3604およびＮＡＮＤゲート3608に入力され、ビットごとに、ＮＯＲゲート3610、排他的ＯＲ（ＸＯＲ）ゲート3612、およびＡＮＤゲート3614を使用して、ＣＲＣレジスタにおいて検出される値と比較される。ＡＮＤゲート3614による出力として、何らか誤りがあるときは、ゲート3614の出力をレジスタ3602の入力へ接続することによって、ＣＲＣは、ＣＲＣの誤りを含む各パケットごとに１回インクリメントされる。図３６の図に示されている例示的な回路は、所与のＣＨＥＣＫ ＣＲＣ ＮＯＷウインドウ（図３７Ｂ参照）内に、２つ以上のＣＲＣ誤り信号を出力し得ることに注意すべきである。したがって、ＣＲＣ誤りカウンタは、一般に、ＣＨＥＣＫ ＣＲＣ ＮＯＷがアクティブである各間隔内で、第１のＣＲＣ誤りインスタンスのみをカウントする。ＣＲＣ発生器として構成されるときは、ＣＲＣは、パケットの最後と一致する時間に、ＣＲＣレジスタから同期して引き出される。
【０１４５】
入力および出力信号と、イネーブリング信号とのタイミングは、図３７Ａおよび３７Ｂにグラフで示されている。ＣＲＣの生成およびデータパケットの伝送は、図３７Ａにおいて、Ｔｘ ＭＤＤＩ Ｄａｔａ Ｂｅｆｏｒｅ ＣＲＣおよびＴｘ ＭＤＤＩ Ｄａｔａ Ｗｉｔｈ ＣＲＣの信号と共に、Ｇｅｎ Ｒｅｓｅｔ、Ｃｈｅｃｋ ＣＲＣ Ｎｏｗ、Ｇｅｎｅｒａｔｅ ＣＲＣ Ｎｏｗ、およびＳｅｎｄｉｎｇ ＭＤＤＩ Ｄａｔａの信号の状態（０または１）で示されている。データパケットの受信およびＣＲＣ値の検査は、図３７Ｂにおいて、Ｒｘ ＭＤＤＩ ＤａｔａおよびＣＲＣ  ｅｒｒｏｒの信号と共に、Ｇｅｎ Ｒｅｓｅｔ、Ｃｈｅｃｋ ＣＲＣ Ｎｏｗ、およびＳｅｎｄｉｎｇ ＭＤＤＩ Ｄａｔａの信号の状態で示されている。
【０１４６】
Ｅ．パケットのＣＲＣにおける誤りコードのオーバーロード
データパケットおよびＣＲＣのみが、ホストとクライアントとの間で転送されるたびに、誤りコードは適応させられない。唯一の誤りは、同期を失うことである。そうでなければ、リンクが、好適なデータ転送経路またはパイプラインの損失からタイムアウトして、その後で、リンクをリセットして、開始するのを待たなければならない。都合の悪いことに、これは、時間がかかり、幾分、非効率的である。
【０１４７】
１つの実施形態で使用するために、パケットのＣＲＣ部分を使用して、誤りコード情報を転送する新しい技術が開発された。これは、概略的に、図６５の全体図に、より詳しくは、図６６、６７Ａ、および６７Ｂに示されている。すなわち、１つ以上の誤りコードは、通信処理またはリンク内に現れ得る特定の予め定義された誤りまたは欠陥を示すデータ転送を処理するプロセッサまたはデバイスによって生成される。誤りに直面すると、適切な誤りコードが生成され、パケットのＣＲＣビットを使用して転送される。すなわち、ＣＲＣの値が、希望の誤りコード、または誤りの存在を表す他の予め選択された値でオーバーロードされ、または上書きされ、受信側では、ＣＲＣフィールドの値を監視している誤りモニタまたはチェッカによって、これを検出することができる。誤りコードが、何らかの理由で、ＣＲＣの値に整合する場合に、誤りの補数が転送され、混乱を防ぐ。
【０１４８】
１つの実施形態では、ロバストな誤り警告および検出システムを与えるために、誤りが検出された後に転送されるか、または送られる一連のパケット、ほぼ全てを使用して、誤りコードを何度か転送することができる。これは、誤りを生じる条件がシステムからクリアされる時点で、すなわち、正規のＣＲＣビットが別の値によってオーバーロードすることなく転送される時点まで行われる。
【０１４９】
ＣＲＣの値をオーバーロードするこの技術は、最小量の予備のビットまたはフィールドを使用する一方で、システムエラーに対する相当により迅速な応答を与える。
【０１５０】
図６６に示されているように、ＣＲＣ上書き機構または装置6600が、誤り検出器または検出手段6602を使用することが示されており、誤り検出器または検出手段6602は、既に記載された、または知られている他の回路の一部を形成することができ、通信リンクまたは処理内における誤りの存在または実在を検出する。誤りコード発生器または手段6604は、他の回路の一部として形成されるか、またはルックアップテーブルのような技術を使用して、予め選択された誤りメッセージを記憶することができ、検出された特定の予め定義された誤りおよび欠陥が生じていることを示す１つ以上の誤りコードを生成する。デバイス6602および6604は、希望に応じて、１つの回路またはデバイスとして、または他の既知のプロセッサおよび素子のプログラムされた一連のステップの一部として形成されることができることが容易に分かるであろう。
【０１５１】
選択された誤りコードが、転送されているＣＲＣ値と同じであるかどうかを確かめる検査をするためのＣＲＣ値比較器または比較手段6606が、示されている。同じであるときは、コード補数発生器または発生手段またはデバイスを使用して、誤りコードの補数を与え、元のＣＲＣパターンまたは値と間違えられ、検出方式を混乱させるか、または複雑にしないようにする。次に、誤りコードセレクタまたは選択手段素子またはデバイス6610は、挿入または上書きすることが望まれる誤りコードまたは値か、あるいはそれぞれの補数を適宜、選択する。誤りコードＣＲＣオーバーライタまたはオーバーライティング機構または手段6612は、希望の誤りコードを受信デバイスに転送するために、挿入されるデータストリーム、パケット、および希望のコードを受信し、対応する、または適切なＣＲＣ値に上書きするデバイスである。
【０１５２】
既に記載したように、誤りコードは、一連のパケットを使用して、何度か転送され、したがって、オーバーライタ6612は、メモリ記憶素子を使用して、コードのコピーを処理中維持するか、あるいは、必要に応じて、または希望に応じて、それらの値を記憶するか、または保持するのに使用されることができる前記素子または他の記憶位置から、これらのコードを呼出すことができる。
【０１５３】
図６６のオーバーライト機構が行なう通常の処理は、図６７Ａおよび６７Ｂにさらに詳しく示されている。図６７Ａでは、ステップ6702において、通信データまたは処理内の誤りが１つ以上検出され、ステップ6704において、この条件を示す誤りコードが選択される。同時に、または適切なときに、ステップ6706において、置き換えられるＣＲＣ値が検査され、ステップ6708において、希望の誤りコードと比較される。既に記載したように、この比較の結果は、希望のコード、または他の代表値が、存在するＣＲＣ値と同じになるかどうかについて決定する。同じであるときは、処理はステップ6712に進み、補数、または場合によっては、希望に応じて、別の代表値が、挿入するコードとして選択される。ステップ6710および6714において、何れの誤りコードまたは値が挿入されるかを判断されると、挿入する適切なコードが選択される。これらのステップは、分かりやするために、別々に示されているが、通常は、ステップ6708の決定の出力に基づく１つの選択を表わす。最後に、ステップ6716において、処理によって目標にされているパケットで転送するために適切な値がＣＲＣの位置に上書きされる。
【０１５４】
図６７Ｂに示されているように、ステップ6722において、パケットの受信側で、パケットのＣＲＣ値が監視されている。概して、ＣＲＣ値は、システム内の１つ以上の処理によって監視され、データ転送において誤りが発生すると、パケットの再伝送を必要とするか、またはこれ以上の処理を禁止するかどうか、等を判断し、その一部は既に記載されている。このような監視の一部として、値を、既知の、または予め選択された誤りコードまたは代表値と比較し、誤りの存在を検出するのに、情報を使用することもできる。その代りに、別々の誤り検出処理およびモニタを実行してもよい。コードが存在していることが明らかであるとき、それは抽出されるか、または、ステップ6724に示されているのとは異なり、別の処理をされる。ステップ6726において、これが実際のコードであるか、または補数であるかを判断することができ、補数である場合は、値を希望のコード値に変換するための追加のステップ6728が使用される。何れの場合においても、次に、ステップ6730において、何れの誤りが、伝送されたコードから現れたかを検出するのに、結果の抽出されたコード、補数、または他の復元された値が使用される。
【０１５５】
Ｖ．休止状態からのリンクの再起動
ホストは、順方向リンクを休止状態から再起動すると、約１５０μsecの間、ＭＤＤＩ Ｄａｔａを論理１状態へ駆動し、次に、ＭＤＤＩ Ｓｔｂをアクティブにし、同時に、約５０μsecの間、ＭＤＤＩ Ｄａｔａを論理０の状態へ駆動し、その後で、サブフレームヘッダパケットを送ることによって順方向リンクトラヒックを開始する。これは、通常、信号間に十分な整定時間を与えることによって、サブフレームヘッダパケットが送られる前に、バスの競合が解決されることを可能にする。
【０１５６】
クライアント、ここでは、ディスプレイは、ホストからデータまたは通信を必要とするとき、約７０μsecの間（しかしながら、希望に応じて、他の期間も使用できる）、ＭＤＤＩ Ｄａｔａ０のラインを論理１の状態へ駆動し、その後で、それを高インピーダンス状態にすることによって、ドライバをディスエーブルする。この動作は、ホストに、順方向リンク（208）上でデータトラヒックを開始または再起動させ、その状態についてクライアントにポーリングさせる。ホストは、５０μsec内で要求パルスの存在を検出し、その後で、ＭＤＤＩ Ｄａｔａ０を１５０μsecの間、論理１へ、５０μsecの間、論理ゼロへ駆動する起動順序を開始しなければならない。それが５０μsecよりも長い間論理１の状態のＭＤＤＩ Ｄａｔａ０を検出するときは、ディスプレイはサービス要求パルスを送るべきではない。休止状態の処理および起動順序に関係する時間および時間間隔の許容値の選択の種類は、別途さらに記載される。
【０１５７】
競合のない、通常のサービス要求イベントの処理ステップの例は、図３８に示されており、ここでは、イベントは、便宜を図って、文字Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、およびＧを使用して示されている。処理は、ポイントＡにおいて、ホストがリンク遮断パケットをクライアントデバイスへ送り、リンクが低電力の休止状態へ遷移することになることを、それに知らせるときに始まる。次のステップでは、ポイントＢに示されているように、ホストは、ＭＤＤＩ Ｄａｔａ０のドライバをディスエーブルし、ＭＤＤＩ Ｓｔｂドライバを論理ゼロに設定することによって、低電力の休止状態に入る。ＭＤＤＩ Ｄａｔａ０は、高インピーダンスバイアスネットワークによって、ゼロのレベルへ駆動される。ある時間期間の後で、ポイントＣにおいて見られるように、クライアントは、ＭＤＤＩ Ｄａｔａ０を論理１のレベルに駆動することによって、サービス要求パルスをホストへ送る。ホストは、引き続き、高インピーダンスバイアスネットワークを使用して、ゼロのレベルでアサートするが、クライアントのドライバはラインを論理１のレベルにする。ホストは、５０μsec内で、サービス要求パルスを認識し、ポイントＤにおいて見られるように、そのドライバをイネーブルすることによって、ＭＤＤＩ Ｄａｔａ０を論理１のレベルでアサートする。次に、クライアントは、サービス要求パルスをアサートするのを試みるのを止め、ポイントＥにおいて見られるように、そのドライバを高インピーダンス状態にする。ポイントＦに示されているように、ホストは、５０μsecの間、ＭＤＤＩ Ｄａｔａ０を論理ゼロのレベルに駆動し、さらに、ＭＤＤＩ Ｄａｔａ０の論理ゼロのレベルと一致するように、ＭＤＤＩ Ｓｔｂを生成し始める。ホストは、５０μsecの間に、ＭＤＤＩ Ｄａｔａ０をゼロのレベルでアサートし、ＭＤＤＩ Ｓｔｂを駆動した後で、ポイントＧに示されているように、サブフレームヘッダパケットを送ることによって、順方向リンク上でデータを伝送し始める。
【０１５８】
同様の例は、図３９に示されており、ここでは、リンク再起動順序が始まった後で、サービス要求がアサートされ、ここでも、イベントは文字Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、およびＧを使用して示されている。これは、最悪の場合のシナリオを表わしており、クライアントからの要求パルスまたは信号は、サブフレームヘッダパケットが破損することに最も近くなる。処理は、ポイントＡにおいて、ホストがリンク遮断パケットをクライアントデバイスへ送り、リンクが低電力休止状態に遷移することになることを、それに知らせるときに始まる。次のステップでは、ポイントＢにおいて示されているように、ホストは、ＭＤＤＩ Ｄａｔａ０ドライバをディスエーブルし、ＭＤＤＩ Ｓｔｂを論理ゼロに設定することによって、低電力の休止状態に入る。既に記載したように、ＭＤＤＩ Ｄａｔａ０は、高インピーダンスバイアスネットワークによってゼロのレベルに駆動される。ある時間期間の後で、ポイントＣにおいて見られるように、ホストは、１５０μsecの間、ＭＤＤＩ Ｄａｔａ０を論理１のレベルに駆動することによって、リンク再起動順序を開始する。リンク再起動順序が始まった後で、５０μsecを経過する前に、ポイントＤに見られるように、ディスプレイも、７０μsecの間、ＭＤＤＩ Ｄａｔａ０をアサートする。これは、ディスプレイがホストからサービスを要求する必要があり、かつホストがリンク再起動順序を既に始めたことを認識していないために生じる。その後で、ポイントＥにおいて見られるように、クライアントは、サービス要求パルスをアサートすることを試みるのを止めて、クライアントは、そのドライバを高インピーダンス状態にする。ホストは、ＭＤＤＩ Ｄａｔａ０を論理１のレベルに駆動し続ける。ポイントＦに示されているように、ホストは、５０μsecの間、ＭＤＤＩ Ｄａｔａ０を論理０レベルに駆動し、同じく、ＭＤＤＩ Ｄａｔａ０の論理ゼロのレベルと一致するように、ＭＤＤＩ Ｓｔｂを生成し始める。ホストは、ＭＤＤＩ Ｄａｔａ０を論理ゼロのレベルでアサートし、５０μsecの間、ＭＤＤＩ Ｓｔｂを駆動した後で、ポイントＧに示されているように、サブフレームヘッダパケットを送ることによって、順方向リンク上でデータを伝送し始める。
【０１５９】
上述から、従来の解決案は、起動順序の一部として、ホストに２つの状態を踏ませていることが分かる。第１の状態では、ホストは、１５０μsの間、ＭＤＤＩ Ｄａｔａ０の信号をハイに駆動し、その後で、５０usの間、ＭＤＤＩ Ｄａｔａ０の信号をローに駆動し、一方でＭＤＤＩ Ｓｔｂラインをアクティブにし、その後で、ＭＤＤＩパケットを伝送し始める。この処理は、ＭＤＤＩ装置および方法を使用して達成可能なデータレートに関する最新技術を向上させるように適切に働く。しかしながら、既に記載したように、条件への低減された応答時間に関する高速化、または次のステップまたは処理をより迅速に選択する能力、または処理または素子を簡単にする能力は、常に要求されている。
【０１６０】
出願人は、ホストが信号の切換えにクロックサイクルに基づくタイミングを使用する起動処理およびタイミングへの新しい発明的なアプローチを発見した。この構成では、ホストが、起動順序の始めに、ＭＤＤＩ Ｄａｔａ０の信号をハイに駆動した後で、０ないし１０μsecで、ＭＤＤＩ Ｓｔｂの切換えを開始し、信号がローに駆動されるまで待たない。起動順序の間、ホストは、ＭＤＤＩ Ｄａｔａ０の信号が常に論理ゼロ０レベルであるかのように、ＭＤＤＩ Ｓｔｂを切換える。これは、クライアント側から時間の概念を完全に取り除き、ホストは、最初の２つの状態の従来の１５０μsおよび５０μsの期間を、これらの期間について、１５０クロックサイクルおよび５０クロックサイクルへ変える。
【０１６１】
ここでは、ホストは、そのデータラインをハイに駆動し、１０クロックサイクル内で、データラインがゼロであるかのように、ストローブ信号を伝送し始めることを担うことになる。ホストは、１５０クロックサイクルの間、データラインをハイに駆動した後で、５０クロックサイクルの間、データラインをローに駆動し、一方で、ストローブ信号を伝送し続ける。これらの処理の両者を完了した後で、ホストは、第１のサブフレームヘッダパケットを伝送し始めることができる。
【０１６２】
ここで、クライアント側では、クライアントの実行は、生成されたクロックを使用して、データラインが最初にハイであり、その後で、ローになるクロックサイクル数を計算することができる。ハイ状態に駆動された両者のデータラインで行われる必要のあるクロックサイクル数は、１５０であり、ロー状態に駆動されたデータラインでは、５０である。これは、適切な起動順序において、クライアントが、ハイであるデータラインの少なくとも１５０の連続クロックサイクルと、その後のローであるデータラインの少なくとも５０のクロックサイクルとをカウントすることができるべきであることを意味する。これらの２つの条件が満たされると、クライアントは、第１のサブフレームのユニークワードのサーチを開始することができる。このパターンにおける中断は、カウンタを初期状態に戻す根拠として使用され、クライアントは、再び、ハイであるデータラインの最初の１５０の連続クロックサイクルを探す。
【０１６３】
休止状態からのホストを用いた起動についての本発明のクライアントの実行は、既に記載したように、クロックレートが１メガビット秒で開始するように強要されないことを除いて、最初の起動の場合に非常に類似している。その代りに、クロックレートは、通信リンクが休止状態になったときにアクティブであった前のレートで、それが何であっても、再開するように設定されることができる。ホストが、既に記載したようにストローブ信号の伝送を始めるとき、クライアントは、ここでも、ハイであるデータラインの少なくとも１５０の連続クロックサイクルと、その後の、ローであるデータラインの少なくとも５０の連続クロックサイクルをカウントできるべきである。これらの２つの条件が満たされると、クライアントは、ユニークワードのサーチを開始することができる。
【０１６４】
休止状態からのクライアントを用いた起動についての本発明のホストの実行は、それが、クライアントにデータラインを駆動させることによって開始することを除いて、ホストを用いた起動に類似している。クライアントは、クロックなしにデータラインを非同期に駆動し、ホストデバイスを起動することができる。ホストは、データラインがクライアントによってハイに駆動されていることを認識すると、その起動順序を開始することができる。クライアントは、ホストが開始することによって、またはその起動処理中に生成されたクロックサイクル数をカウントすることができる。クライアントは、ハイであるデータの７０の連続クロックサイクルをカウントすると、データラインをハイに駆動するのを止めることができる。この時点では、ホストも、既にデータラインをハイに駆動しているはずである。その後で、クライアントは、ハイであるデータラインの別の８０クロックサイクルをカウントし、ハイであるデータラインの１５０クロックサイクルに到達し、その後で、ローであるデータラインの５０クロックサイクルを探すことができる。これらの３つの条件が満たされると、クライアントは、ユニークワードを探し始めることができる。
【０１６５】
起動処理のこの新しい実行の長所は、これが時間測定デバイスを不要にしたことである。
【０１６６】
これが発振器であっても、コンデンサ放出回路であっても、または他の、このような既知のデバイスであっても、クライアントは、起動条件を判断するのに、このような外部デバイスを最早必要としない。これは、クライアントデバイスボード上に制御装置、カウンタ、等を構成するときの費用および回路の場所を省く。一方で、これは、クライアントにとって好都合でないこともあるが、ホストにとっては、この技術は、コア回路に使用される超高密度論理（very high density logic, VHDL）に関して、ホストを潜在的に簡素にもするはずである。コア素子がホストを用いた起動を待っている間、外部回路が動作している必要がなくなるので、起動通知および測定源としてデータおよびストローブラインを使用する電力消費も、より少なくなる。
【０１６７】
使用されるサイクル数またはクロック期間は、例であり、当業者には明らかであるように、他の期間を使用することができる。
【０１６８】
この新しい技術の動作を明らかにして、説明するために、ＭＤＤＩ Ｄａｔａ０、ＭＤＤＩ Ｓｔｂ、およびクロックサイクルに関係する種々の動作が、図６８Ａ、６８Ｂ、および６８Ｃに示されている。
【０１６９】
競合のない、一般的なホストが開始する起動の処理ステップの例は、図６８Ａに示されており、イベントは、ここでも、説明における便宜を図って、文字Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、およびＧを使用して示されている。処理は、ポイントＡにおいて、ホストがリンク遮断パケットをクライアントデバイスへ送って、リンクが低電力の休止状態に遷移することになることを、それに知らせるときに始まる。次のステップでは、ポイントＢにおいて、ホストは、ＭＤＤＩ Ｓｔｂを約６４サイクルの間（または、システム設計に対する希望に応じた期間）切換えて、ＭＤＤＩ Ｓｔｂが切換わるのを停止し、クライアントデバイス内の回復されたクロックを停止する前に、クライアントによる処理が完了されることを可能にする。ホストは、さらに加えて、最初に、ＭＤＤＩ Ｄａｔａ０を論理ゼロのレベルに設定し、次に、ＣＲＣの後で、（通常、出力ディスエーブル伝搬遅延を含む）１６ないし４８サイクルの範囲において、ＭＤＤＩ Ｄａｔａ０の出力をディスエーブルする。ＣＲＣの後の４８サイクルの後で、次の新しい段階（Ｃ）の前のしばらくの間、低電力状態のクライアント内にＭＤＤＩ Ｄａｔａ０およびＭＤＤＩ Ｓｔｂのための高速受信機を置くことが望ましい。
【０１７０】
ホストは、ＭＤＤＩ Ｄａｔａ０およびＭＤＤＩ Ｓｔｂのドライバをディスエーブルして、ホスト制御装置を低電力の休止状態にすることによって、ポイントまたはステップＣにおいて低電力の休止状態に入る。また、希望に応じて、（高インピーダンスバイアスネットワークを使用して）ＭＤＤＩ Ｓｔｂのドライバを論理ゼロのレベルに設定するか、または休止状態中に切換え続けることもできる。クライアントも、低電力レベルの休止状態である。
【０１７１】
ある時間期間の後で、ポイントＤにおいて、ホストは、ＭＤＤＩ Ｄａｔａ０およびＭＤＤＩ Ｓｔｂのドライバの出力をイネーブルすることによって、リンク再起動順序を開始する。ホストは、ドライバがそれぞれの出力を完全にイネーブルするのにかかる時間の間、ＭＤＤＩ Ｄａｔａ０を論理１のレベルに、ＭＤＤＩ Ｓｔｂを論理ゼロのレベルに駆動する。これらの出力が希望の論理レベルに到達した後で、ＭＤＤＩ Ｓｔｂ上でパルスを駆動する前に、ホストは、通常、約２００ナノ秒待つ。これは、クライアントが受信の準備をする時間を可能にすることができる。
【０１７２】
ホストドライバがイネーブルされ、ＭＤＤＩ Ｄａｔａ０が論理１のレベルに駆動されると、ポイントＥに見られるように、ホストは、１５０ＭＤＤＩ Ｓｔｂサイクルの間、ＭＤＤＩ Ｓｔｂを切換え始める。ポイントＦに示されているように、ホストは、５０サイクルの間、ＭＤＤＩ Ｄａｔａ０を論理ゼロのレベルに駆動し、ＭＤＤＩ Ｄａｔａ０が４０ＭＤＤＩ Ｓｔｂサイクルの間、論理ゼロのレベルであった後で、クライアントは、サブフレームヘッダパケットを探し始める。ポイントＧに示されているように、ホストは、順方向リンク上で、サブフレームヘッダパケットを送ることによって、データを伝送し始める。
【０１７３】
競合のない、一般的なクライアントが開始する起動の処理ステップの例は、図６８Ｂに示されており、イベントは、ここでも、説明における便宜を図って、文字Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ、Ｈ、およびＩを使用して示されている。前のように、処理は、ポイントＡにおいて、ホストがリンク遮断パケットを送って、リンクが低電力状態に遷移することになることを、クライアントに知らせるときに始まる。
【０１７４】
ポイントＢにおいて、ホストは、ＭＤＤＩ Ｓｔｂを約６４サイクルの間（または、システム設計に対する希望に応じた期間）切換えて、ＭＤＤＩ Ｓｔｂが切換わるのを停止し、クライアントデバイス内の回復されたクロックを停止する前に、クライアントによる処理が完了されることを可能にする。ホストは、さらに加えて、最初に、ＭＤＤＩ Ｄａｔａ０を論理ゼロのレベルに設定し、次に、ＣＲＣの後で、（一般に、出力ディスエーブル伝搬遅延を含む）１６ないし４８サイクルの範囲において、ＭＤＤＩ Ｄａｔａ０の出力をディスエーブルする。ＣＲＣの後の４８サイクルの後で、次の段階（Ｃ）の前のしばらくの間、低電力状態のクライアントにおいてＭＤＤＩ Ｄａｔａ０およびＭＤＤＩ Ｓｔｂのための高速受信機を置くことが望ましい。
【０１７５】
ホストは、ＭＤＤＩ Ｄａｔａ０およびＭＤＤＩ Ｓｔｂのドライバをディスエーブルして、ホスト制御装置を低電力の休止状態にすることによって、ポイントまたはステップＣにおいて低電力の休止状態に入る。また、希望に応じて、（高インピーダンスバイアスネットワークを使用して）、ＭＤＤＩ Ｓｔｂのドライバを論理ゼロのレベルに設定するか、または休止状態中に切換えを続けることもできる。クライアントも、低電力レベルの休止状態である。
【０１７６】
ある時間期間の後で、ポイントＤにおいて、クライアントは、ＭＤＤＩ Ｓｔｂの受信機をイネーブルして、ＭＤＤＩ Ｓｔｂの受信機におけるオフセットにイネーブルして、ホストがそのＭＤＤＩ Ｓｔｂのドライバをイネーブルする前に、受信されたＭＤＤＩ Ｓｔｂの状態がクライアントにおいて論理ゼロのレベルであることを保証することによって、リンク再起動順序を開始する。クライアントが、受信機をイネーブルする前に、オフセットをイネーブルして、有効な差動信号の受信を保証し、誤り信号を阻止することを保証することが望ましい。クライアントは、ＭＤＤＩ Ｄａｔａ０のドライバをイネーブルし、一方でＭＤＤＩ Ｄａｔａ０のラインを論理１のレベルに駆動する。
【０１７７】
約１ミリ秒内で、ポイントＥにおいて、ホストは、クライアントからのサービス要求パルスを認識し、ホストは、ＭＤＤＩ Ｄａｔａ０およびＭＤＤＩ Ｓｔｂのドライバの出力をイネーブルすることによって、リンク再起動順序を開始する。ホストは、ドライバがそれぞれの出力をイネーブルするのにかかる時間の間、ＭＤＤＩ Ｄａｔａ０を論理１のレベルに、ＭＤＤＩ Ｓｔｂを論理ゼロのレベルに駆動する。これらの出力が希望の論理レベルに到達した後で、ＭＭＤＩ Ｓｔｂ上でパルスを駆動する前に、ホストは、通常、約２００ナノ秒待つ。これは、クライアントが受信の準備をする時間を可能にする。
【０１７８】
ホストドライバがイネーブルされ、ＭＤＤＩ Ｄａｔａ０が論理１のレベルに駆動されると、ポイントＦに見られるように、ホストは、１５０ＭＤＤＩ Ｓｔｂサイクルの間、ＭＤＤＩ Ｓｔｂでパルスを出力し始める。クライアントは、ＭＤＤＩ Ｓｔｂ上の第１のパルスを認識すると、ＭＤＤＩ Ｓｔｂにおけるオフセットを使用不可にする。クライアントは、７０ＭＤＤＩ Ｓｔｂサイクルの間、ＭＤＤＩ Ｄａｔａ０を論理１のレベルに駆動し続け、ポイントＧにおいて、そのＭＤＤＩ Ｄａｔａ０のドライバをディスエーブルする。
【０１７９】
ポイントＧおよびＨに見られるように、ホストは、５０サイクルの間、ＭＤＤＩ Ｄａｔａ０を論理ゼロのレベルに駆動し、ＭＤＤＩ Ｄａｔａ０が４０ＭＤＤＩ Ｓｔｂサイクルの間、論理ゼロのレベルであった後で、クライアントは、サブフレームヘッダパケットを探し始める。ポイントＩに示されているように、ホストは、サブフレームヘッダパケットを順方向リンク上で送ることによって、データを伝送し始める。
【０１８０】
クライアントからの競合のある、すなわち、クライアントもリンクを起動したいときの、典型的なホストが開始する起動の処理のステップの例は、図６８Ｃに示されている。ここでも、イベントは、説明における便宜を図って、文字Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ、Ｈ、およびＩを使用して示されている。前のように、処理は、ポイントＡにおいて、ホストがリンク遮断パケットを送って、リンクが低電力の休止状態に遷移することになることを、クライアントに知らせるときに始まり、ホストＢに進み、ここでは、ＭＤＤＩ Ｓｔｂを約６４サイクルの間（または、システム設計に対する希望に応じた期間）切換えて、クライアントによる処理を完了することを可能にし、次に、ポイントＣへ進み、ここでは、ホストは、ＭＤＤＩ Ｄａｔａ０およびＭＤＤＩ Ｓｔｂのドライバをディスエーブルし、ホスト制御装置を低電力休止状態にすることによって、低電力の休止状態に入る。いくらかの時間期間の後で、ポイントＤにおいて、ホストは、ＭＤＤＩ Ｄａｔａ０およびＭＤＤＩ Ｓｔｂのドライバの出力をイネーブルすることによって、リンク再起動順序を開始し、ポイントＥに見られるように、１５０ＭＤＤＩ Ｓｔｂサイクルの期間の間、ＭＤＤＩ Ｓｔｂを切換え始める。
【０１８１】
ポイントＥの後の７０までのＭＤＤＩ Ｓｔｂサイクルにおいて、ここでは、ポイントＦにおいて、クライアントは、ホストがＭＤＤＩ Ｄａｔａ０を論理１のレベルに駆動していて、クライアントもＭＤＤＩ Ｄａｔａ０を論理１のレベルに駆動することをまだ認識していない。ここで、これは、クライアントはサービスを求める要求をもつが、自分が通信することを試みているホストが、リンク再起動順序を既に始めたことを認識しないときに生じる。ポイントＧでは、クライアントは、ＭＤＤＩ Ｄａｔａ０を駆動するのを止め、その出力をディスエーブルすることによって、そのドライバを高インピーダンス状態にする。ホストは、追加の８０サイクルの間、ＭＤＤＩ Ｄａｔａ０を論理１のレベルに駆動し続ける。
【０１８２】
ポイントＨに示されているように、ホストは、５０サイクルの間、ＭＤＤＩ Ｄａｔａ０を論理ゼロのレベルに駆動し、ＭＤＤＩ Ｄａｔａ０が、４０ＭＤＤＩ Ｓｔｂサイクルの間、論理ゼロのレベルであった後で、クライアントは、サブフレームヘッダパケットを探し始める。ポイントＩに示されているように、ホストは、サブフレームヘッダパケットを送ることによって、順方向リンク上でデータを伝送し始める。
【０１８３】
ＶＩ．インターフェイスの電気仕様
例示的な実施形態では、非ゼロ復帰（Non-Return-to-Zero, NRZ）フォーマットのデータが、データ−ストローブ信号またはＤＡＴＡ−ＳＴＢフォーマットを使用して符号化されると、クロック情報が、データおよびストローブ信号に埋め込まれるのを可能にする。クロックは、複雑なフェーズロックループ回路なしに回復されることができる。データは、通常ワイヤーラインケーブルを使用して構成される双方向の差動リンクによって搬送されるが、既に記載されたように、他の導線、プリントワイヤ、または転送素子が使用されることができる。ストローブ信号（strobe signal, STB）は、ホストのみによって駆動される一方向リンクによって搬送される。ストローブ信号は、０または１の背中合わせの状態、すなわち、データラインまたは信号において同じ状態を維持するときは必ず、値（０または１）を切換える。
【０１８４】
ビット“１１１０００１０１１”のようなデータ系列が、ＤＡＴＡ−ＳＴＢの符号化を使用して、どのように伝送されることができるかの例が、図４０にグラフの形で示されている。図４０では、ＤＡＴＡ信号4002は、信号タイミングチャートの上のラインに示されており、ＳＴＢ信号4004は、二番目のラインに示されており、各々は適切に（共通の開始点で）時間整列している。時間の経過にしたがって、ＤＡＴＡライン4002（信号）において状態の変化が現れるとき、ＳＴＢライン4004（信号）は前の状態を維持し、したがって、ＤＡＴＡ信号の最初の‘１’の状態は、ＳＴＢ信号の最初の‘０’の状態、すなわち、その開始値と相関する。しかしながら、図４０において、ＤＡＴＡが別の‘１’の値を与える場合のように、ＤＡＴＡ信号の状態、すなわちレベルが変化しないならば、またはそのときは、ＳＴＢ信号は、逆の状態、または、この例では‘１’に切り換わる。したがって、ＤＡＴＡとＳＴＢとの間に、１ビットサイクルごとに１つの、しかも１つのみの遷移がある。したがって、ＤＡＴＡ信号が‘１’に留まるとき、ＳＴＢ信号は、再び、このときは‘０’へ遷移し、ＤＡＴＡ信号がレベルを‘０’に変えるとき、ＳＴＢ信号は、このレベルまたは値を維持する。ＤＡＴＡ信号がレベルまたは値を変えるか、あるいは維持するかにしたがって、ＤＡＴＡ信号が‘１’に留まるときは、ＳＴＢ信号は、逆の状態、または、この例では‘１’に切り換わる、等である。
【０１８５】
これらの信号を受信すると、排他的論理和（exclusive OR, XOR）の動作は、ＤＡＴＡおよびＳＴＢ信号に対して行われ、クロック信号4006を生成し、クロック信号4006は、希望のデータとストローブ信号とを相対的に比較するためのタイミング図の下側に示されている。ホストにおいて入力データからＤＡＴＡまたはＳＴＢ出力または信号を生成し、その後で、クライアントにおいてＤＡＴＡおよびＳＴＢ信号からデータを復元するか、または再び得るのに役立つ回路の例は、図４１に示されている。
【０１８６】
図４１では、送信部4100は、元のＤＡＴＡおよびＳＴＢ信号を生成して、中間信号経路4102によって送信するのに使用され、一方で、受信部4120は、信号を受信し、データを復元するのに使用される。図４１に示されているように、データをホストからクライアントへ転送するために、ＤＡＴＡ信号は、クロック信号と共に、Ｄタイプのフリップフロップ回路素子4104および4106へ入力され、回路をトリガする。その後で、２つのフリップフロップ回路の出力（Ｑ）は、２つの差動ラインドライバ4108および4110（電圧モード）を使用して、差動の対の信号、ＭＤＤＩ Ｄａｔａ０＋およびＭＤＤＩ Ｄａｔａ０−と、ＭＤＤＩ Ｓｔｂ＋およびＭＤＤＩ Ｓｔｂ−とにそれぞれ分割される。３つの入力の排他的ＮＯＲ（exclusive-NOR, XNOR）ゲート、回路、または論理素子4112は、ＤＡＴＡと両者のフリップフロップの出力とを受信するように接続され、第２のフリップフロップにデータ入力を与えるための出力を生成し、次に、第２のフリップフロップは、ＭＤＤＩ Ｓｔｂ＋およびＭＤＤＩ Ｓｔｂ−の信号を生成する。便宜を図って、ストローブを生成するフリップフロップのＱ出力を効果的に反転することを示すために、ＸＮＯＲゲートは反転バブルを置かれている。
【０１８７】
図４１の受信部4120では、ＭＤＤＩ Ｄａｔａ０＋およびＭＤＤＩ Ｄａｔａ０−と、ＭＤＤＩ Ｓｔｂ＋およびＭＤＤＩ Ｓｔｂ−の信号とは、２つの差動ライン受信機4122および4124の各々によって受信され、これらは、差動信号から信号出力を生成する。次に、増幅器の出力は、２つの入力の排他的ＯＲ（ＸＯＲ）ゲート、回路、または論理素子4126の入力の各々に入力され、これはクロック信号を生成する。クロック信号は、２つのＤタイプのフリップフロップ回路4128および4130の各々をトリガするのに使用され、これらは、遅延素子4132を通って、遅延したＤＡＴＡ信号を受信し、その一方（4128）はデータ ‘０’を生成し、他方（4130）は‘１’の値を生成する。クロックも、ＸＯＲ論理からの独立の出力をもつ。クロック情報は、ＤＡＴＡおよびＳＴＢのライン間で分配されるので、何れの信号もクロックレートの半分より速く状態間を遷移しない。クロックは、ＤＡＴＡおよびＳＴＢ信号の排他的ＯＲ処理を使用して再生されるので、システムは、クロック信号が１本の専用データラインによって直接に送られるときの状況と比べて、入力データとクロックとの間の２倍のスキュー量を事実上許容する。
【０１８８】
ＭＤＤＩ Ｄａｔａの対、ＭＤＤＩ Ｓｔｂ＋、およびＭＤＤＩ Ｓｔｂ−の信号は、差動モードで動作され、雑音の負の影響からの耐性を最大化する。差動信号経路の各部分は、信号を転送するのに使用されるケーブルまたは導線の特性インピーダンスの２分の１で終端する源である。ＭＤＤＩ Ｄａｔａの対は、ホストエンドおよびクライアントエンドの両者において終端する源である。これらの２つのドライバの一方のみが、所与のときにアクティブであるので、終端は、転送リンクの源において、常に存在する。ＭＤＤＩ Ｓｔｂ＋およびＭＤＤＩ Ｓｔｂ−の信号は、ホストのみによって駆動される。
【０１８９】
発明的なＭＤＤインターフェイスの一部として信号を転送するためのドライバ、受信機、および終端を実現するのに役立つ素子の例示的な構成は、図４２に示されており、一方でＭＤＤＩ ＤａｔａおよびＭＤＤＩ Ｓｔｂの対応するＤＣ電気の仕様は、表７に示されている。この例示的なインターフェイスは、ここでは、２００ミリボルトの低電圧を感知し、電力の揺れが１ボルト未満で、低電力ドレインのものを使用する。
【表７】
2011176810.tif 000009
【０１９０】
差動ラインドライバおよびライン受信機の電気パラメータおよび特性は、表７に記載されている。機能上、ドライバは、入力上の論理レベルを直接に正の出力へ、入力の逆のものを負の出力へ転送する。入力から出力への遅延は、差動して駆動される差動ラインに適切に整合させられる。大抵の実行では、出力における電圧の揺れは、入力における揺れよりも小さく、電力消費および電磁放出を最小化する。表７には、約０．５Ｖの最小の電圧の揺れが示されている。しかしながら、当業者には分かるような、他の値を使用することができ、発明者は、いくつかの実施形態において、設計の制約に依存して、より小さい値を検討する。
【０１９１】
差動ライン受信機は、高速電圧比較器と同じ特性をもつ。図４１では、バブルのない入力は、正の入力であり、バブルのある入力は負の入力である。（Ｖｉｎｐｕｔ＋）−（Ｖｉｎｐｕｔ−）がゼロよりも大きいときは、出力は論理１である。これを他のやり方で説明するならば、差動増幅器は、論理０および１の電圧レベルで切られた出力で非常に大きい（事実上、無限の）利得をもつ。
【０１９２】
異なる対間の遅延スキューは、差動伝送システムを、最高潜在速度で動作するために最小化されるべきである。
【０１９３】
図４２には、ホスト制御装置4202と、クライアントまたはディスプレイ制御装置4204とが示されており、これらは、通信リンク4206によってパケットを転送する。ホスト制御装置は、一連の３つのドライバ4210、4212、および4214を採用して、ホストＤＡＴＡおよびＳＴＢ信号を受信して、転送し、さらに加えて、クライアントデータ信号を受信して、転送する。ホストのＤＡＴＡを送ることを担当するドライバは、通常、ホストからクライアントへの転送が要求されるときのみ、イネーブル信号の入力を用いて、通信リンクをアクティブにすることができる。ＳＴＢ信号は、データ転送の一部として形成されているので、そのドライバ（4120）のために、追加のイネーブル信号は用いられない。ＤＡＴＡおよびＳＴＢのドライバの各々の出力は、終端インピーダンスまたは抵抗4216a、4216b、4216c、および4216dにそれぞれ接続されている。
【０１９４】
また、終端抵抗4216aおよび4216bは、ＳＴＢ信号処理のためのクライアント側受信機の入力4220におけるインピーダンスとしても働き、一方で、追加の終端抵抗4216eおよび4216fは、クライアントデータ処理受信機の入力4222において、抵抗4216cおよび4216dと直列に置かれる。クライアント制御装置内の６番目のドライバ4226は、クライアントからホストへ転送されるデータ信号を準備するのに使用され、ここで、入力側で終端抵抗4216cおよび4216dを通る、ドライバ4124は、処理のためのホストへ転送するデータを処理する。
【０１９５】
２つの追加の抵抗4218aおよび4218bは、それぞれ、別途記載される休止状態の制御の一部として、終端抵抗と、接地と、電圧源4220との間に置かれる。電圧源は、既に記載したハイまたはローレベルに転送ラインを駆動して、データの流れを管理するのに使用される。
【０１９６】
上述のドライバおよびインピーダンスは、ディスクリートな構成要素として、または回路モジュールの一部、すなわち、よりコスト効率のよい符号器および復号器の解決としての役割を果たす特定用途向け集積回路（application specific integrated circuit, ASIC）として形成されることができる。
【０１９７】
電力は、ＭＤＤＩ ＰｗｒおよびＭＤＤＩ Ｇｎｄとして示されている信号を使用して、１組の導線によって、ホストデバイスから、クライアントデバイス、すなわち、ディスプレイへ転送されることが容易に分かるであろう。信号のＭＤＤＩ Ｇｎｄの部分は、基準接地、およびディスプレイデバイスへの電源復路または信号としての役割を果たす。ＭＤＤＩ Ｐｗｒ信号は、ホストデバイスによって駆動されるディスプレイデバイスの電源としての役割を果たす。例示的な構成では、低電力の応用において、ディスプレイデバイスは、５００ミリアンペアまで引き上げることを許可されている。ＭＤＤＩ Ｐｗｒ信号は、ホストデバイスに存在するポータブル電源、制限はしないが、例えば、リチウムイオンタイプのバッテリまたはバッテリパックから与えられることができ、ＭＤＤＩ Ｇｎｄに対して３．２ないし４．３ボルトの範囲に及び得る。
【０１９８】
ＶＩＩ．タイミング特性
Ａ．概要
ホストからの、またはホストによるサービスをセキュリティ保護して、そのようなサービスを与えるために、クライアントによって採用されるステップおよび信号レベルは、図４３に示されている。図４３では、図示されている信号の第１の部分は、ホストから転送されるリンク遮断パケットを示し、したがって、データラインは、高インピーダンスバイアス回路を使用して、論理ゼロの状態に駆動される。データは、クライアントディスプレイによっても、または、そのドライバをディスエーブルしたホストによっても伝送されない。ＭＤＤＩ Ｓｔｂは、リンク遮断パケットの間アクティブであるので、ＭＤＤＩ Ｓｔｂ信号ラインの一連のストローブパルスは、下側に示されている。このパケットが終了して、ホストがバイアス回路を駆動して、論理をゼロにするとき、論理レベルがゼロに変わると、ＭＤＤＩ Ｓｔｂの信号ラインもゼロのレベルに変わる。これは、ホストからの最後の信号転送またはサービスの終了を表わし、過去の何れのときでも行われることができ、サービスの事前の中止、およびサービス開始前の信号の状態を示すために含まれる。希望であれば、このような信号は、このホストデバイスによって行われた‘既知’の事前の通信なしに、通信リンクを適切な状態に単にリセットするために送られることができる。
【０１９９】
図４３に示されているように、クライアントからの信号出力は、最初に、ゼロの論理レベルに設定される。言い換えると、クライアントの出力は、高インピーダンスであり、ドライバはディスエーブルされている。サービスが要求されているとき、クライアントは、そのドライバをイネーブルし、サービス要求をホストへ送る。これは、ｔｓｅｒｖｉｃｅと呼ばれる期間であり、この間に、ラインは論理１のレベルに駆動される。ホストが要求を検出する前に、一定の時間が経過するか、または要求されることがあり、これはｔｈｏｓｔ−ｄｅｔｅｃｔと呼ばれ、その後で、ホストは、信号を論理１のレベルに駆動することによって、リンク起動順序で応答する。この時点で、クライアントは要求をデアサートし、サービス要求ドライバをディスエーブルし、その結果、クライアントからの出力ラインは、再びゼロの論理レベルになる。この時間中、ＭＤＤＩ Ｓｔｂ信号は、論理ゼロのレベルである。
【０２００】
ホストは、ｔｒｅｓｔａｒｔ−ｈｉｇｈと呼ばれる期間の間、ホストのデータ出力を‘１’のレベルで駆動し、その後で、ｔｒｅｓｔａｒｔ−ｌｏｗと呼ばれる期間の間、ホストは論理レベルをゼロに駆動し、ＭＤＤＩ Ｓｔｂをアクティブにし、その後で、第１の順方向トラヒックは、サブフレームヘッダパケットで始めて、したがって、順方向トラヒックのパケットが転送される。ＭＤＤＩ Ｓｔｂの信号は、ｔｒｅｓｔａｒｔ−ｌｏｗの期間および次のサブフレームヘッダパケットの間、アクティブである。
【０２０１】
表８は、上述の種々の期間の長さの代表的な時間と、例示的な最小および最大データレートに対する関係とを示す。ここで、次式を条件とする。
【０２０２】
ｔｂｉｔ＝１／（Ｌｉｎｋ Ｄａｔａ Ｒａｔｅ）
【表８】
2011176810.tif 000010
【０２０３】
当業者には、図４１および４２に示されている個々の素子の機能が周知であり、図４２の素子の機能が、図４３のタイミング図によって確認されることが容易に分かるであろう。図４２に示されている直列の終端および休止状態の抵抗に関する詳細は、どのようにデータ（Ｄａｔａ）−ストローブ（Ｓｔｒｏｂｅ）の符号化を行い、それからクロックを回復するかを説明するのに不要であるので、その情報は、図４１から省かれている。
【０２０４】
Ｂ．データ−ストローブのタイミングの順方向リンク
ホストドライバ出力からの順方向リンク上でのデータ転送についてのスイッチング特性は、表９に示されている。表９は、ある特定の信号の遷移を行うための、希望の最小値および最大値に対する標準的な時間についての表を提示している。例えば、データ値（‘０’または‘１’の出力）の最初から最後に行われる遷移、すなわち、ｔｔｄｄ−（ｈｏｓｔ−ｏｕｔｐｕｔ）と呼ばれるＤａｔａ０からＤａｔａ０への遷移の標準的な時間長は、ｔｔｂｉｔであり、これに対して、最小時間は、約ｔｔｂｉｔ−０．５ナノ秒であり、最大時間は、約ｔｔｂｉｔ＋０．５ナノ秒である。Ｄａｔａ０、他のデータライン（ＤａｔａＸ）、およびストローブライン（Ｓｔｂ）における遷移間の相対的な間隔は、図４４に示されており、ここでは、Ｄａｔａ０からストローブ、ストローブからストローブ、ストローブからＤａｔａ０、Ｄａｔａ０からＤａｔａ０以外、Ｄａｔａ０以外からＤａｔａ０以外、Ｄａｔａ０以外からストローブ、ストローブからＤａｔａ０以外への遷移が示されており、これは、ｔｔｄｓ−（ｈｏｓｔ−ｏｕｔｐｕｔ）、ｔｔｓｓ−（ｈｏｓｔ−ｏｕｔｐｕｔ）、ｔｔｓｄ−（ｈｏｓｔ−ｏｕｔｐｕｔ）、ｔｔｄｄｘ−（ｈｏｓｔ−ｏｕｔｐｕｔ）、ｔｔｄｘｄｘ−（ｈｏｓｔ−ｏｕｔｐｕｔ）、ｔｔｄｘｓ（ｈｏｓｔ−ｏｕｔｐｕｔ）、およびｔｔｓｄｘ−（ｈｏｓｔ−ｏｕｔｐｕｔ）とそれぞれ呼ばれる。
【表９】
2011176810.tif 000011
【０２０５】
順方向リンク上でデータを転送している同じ信号のためのクライアント受信機の入力のための標準的なＭＤＤＩのタイミング要件は、表１０に示されている。当業者には分かるように、時間が遅延されていることを除いて、同じ信号が扱われているので、各レベルの信号特性または意味を示すための新しい図は不要である。
【表１０】
2011176810.tif 000012
【０２０６】
図４５および４６は、ホストがホストドライバをディスエーブルまたはイネーブルするときに生じ得る応答における遅延の存在をそれぞれ示している。ホストが、逆方向リンクカプセル化パケットまたは往復遅延測定パケットのような、ある特定のパケットを送付する場合に、ホストは、図４５に示されている、転送されたパラメータのＣＲＣ、ストローブ整列、および全てゼロのパケットのような、希望のパケットが送付された後で、ラインドライバをディスエーブルする。しかしながら、図４５に示されているように、ラインの状態は、‘０’から希望のより高い値へ必ずしも即座にスイッチしないが、これは、ある特定の制御または回路素子の存在で、潜在的には達成可能であるが、応答するには、ホストドライバディスエーブル遅延期間と呼ばれる時間期間がかかる。これは事実上瞬間的に行われ、したがって、この時間期間は０ナノ秒（nanosecnd, nsec）長であるが、希望最大期間長で１０ナノ秒の幾らかより長い期間に容易に延長することができ、これは、保護時間１または折り返し１のパケット期間中に現れる。
【０２０７】
図４６を参照すると、ホストドライバが、逆方向リンクカプセル化パケットまたは往復遅延測定パケットのようなパケットを転送するためにイネーブルされるときに、信号レベルが変えられるのが分かる。ここでは、保護時間２または折り返し２のパケットの期間の後で、ホストドライバはイネーブルされ、レベル、ここでは、‘０’を駆動し始める。この値には、ホストドライバイネーブル遅延期間と呼ばれる時間期間において近付く、または到達し、ホストドライバ遅延期間は、ドライバ再イネーブル遅延期間中で、第１のパケットが送られる前に現れる。
【０２０８】
同様の処理が、クライアントデバイス、本明細書では、ディスプレイのドライバおよび信号転送でも行われる。これらの期間の長さ、それらのそれぞれの関係についての概略的な基準は、次の表１１に示されている。
【表１１】
2011176810.tif 000013
【０２０９】
Ｃ．データ−ストローブのタイミングの逆方向リンク
クライアントドライバの出力から、逆方向リンク上でデータを転送するのに使用されるデータおよびストローブ信号のスイッチング特性およびタイミングの関係は、図４７および４８に示されている。ある特定の信号の遷移の標準的な時間は、別途記載される。図４７は、ホスト受信機の入力における、転送されるデータのタイミングと、ストローブパルスのリーディングおよびトレーリングエッジとの間の関係を示している。したがって、ストローブ信号の立ち上がり端またはリーディングエッジの設定時間、すなわち、ｔｓｕ−ｓｒと、ストローブ信号のトレーリングエッジまたは立ち下がり端の設定時間、すなわち、ｔｓｕ−ｓｆについて参照される。これらの設定期間における標準的な時間長は、最低約８ナノ秒である。
【０２１０】
図４８は、逆方向データのタイミングによって行われるスイッチング特性と対応するクライアントの出力の遅延とを示す。図４８では、転送されるデータのタイミングと、取り込まれた遅延を考慮したストローブパルスのリーディングおよびトレーリングエッジとの関係が分かるであろう。したがって、ストローブ信号の立ち上がり端またはリーディングエッジと、データ（有効）との間の伝搬遅延、すなわち、ｔｐｄ−ｓｒと、データと、ストローブ信号のトレーリングエッジまたは立ち下がり端との間の伝搬遅延、すなわち、ｔｐｄ−ｓｆについて参照される。これらの伝搬遅延期間の標準的な最大時間は、約８ナノ秒である。
【０２１１】
ＶＩＩＩ．リンク制御の実行（リンク制御装置の動作）
Ａ．状態機械パケットプロセッサ
ＭＤＤＩリンク上を転送されるパケットは、非常に迅速に、標準で、約３００メガビット秒以上のレート、例えば、４００メガビット秒で送り出されるが、もちろん、希望に応じて、より低いレートに適応する。このタイプのバスまたは転送リンクの速度は、現在市販の（経済的な）汎用マイクロプロセッサ、等が制御するには速過ぎる。したがって、このタイプの信号転送を達成するための実用的な実行では、プログラム可能な状態機械を使用して、入力パケットストリームをパースして、パケットを生成し、それらが宛てられた適切なオーディオ−ビジュアルサブシステムに転送するか、または再び方向付ける。このようなデバイスは、周知であり、制限された数の動作、機能、または状態にほぼ専用の回路を使用して、希望の高速度、または超高速度の動作を達成する。
【０２１２】
汎用制御装置、プロセッサ、または処理素子は、より低い速度が要求される制御または状態パケットのような幾つかの情報に、より適切に作用するか、または処理するのに使用されることができる。状態機械は、これらのパケット（制御、状態、または他の予め定義されたパケット）を受信すると、それらをデータ緩衝器または同様の処理素子を経由して、汎用プロセッサに送り、パケットは希望の結果（効果）を与えるように作用されることができ、一方でオーディオおよびビジュアルパケットは、処理のために適切な宛先へ転送される。将来の、マイクロプロセッサまたは汎用制御装置、プロセッサ、あるいは制御素子が、より高いデータレートの処理能力を実現するように製造されるとき、別途記載される状態または状態機械も、このようなデバイスのソフトウエア制御、一般的には、記憶素子または媒体上に記憶されたプログラムを使用して実行され得る。
【０２１３】
幾つかの実施形態において、汎用プロセッサの機能は、コンピュータの応用におけるマイクロプロセッサ（ＣＰＵ）、または制御装置、プロセッサ、ディジタル信号プロセッサ（digital signal processor, DSP）、専用回路、あるいは無線デバイス内に見られるＡＳＩＣにおいて使用可能な処理電力、または超過サイクルを利用することによって、実現されることができ、これは、いくつかのモデムまたはグラフィックプロセッサが、コンピュータ内に見られるＣＰＵの処理電力を使用して、幾つかの機能を実行し、ハードウエアの複雑さおよびコストを低減するのとほぼ同じやり方である。しかしながら、このサイクルの共用または使用は、このような素子の処理速度、タイミング、または全体的な動作にマイナスの影響を与えることがあり、したがって、多くの応用では、この一般的な処理には、専用の回路または素子が好ましい。
【０２１４】
画像データがディスプレイ（マイクロディスプレイ）上に表示されるか、またはホストデバイスによって送られる全パケットを確実に受信するために、ディスプレイの信号処理は、順方向リンクチャネルのタイミングと同期させられる。したがって、ディスプレイおよびディスプレイ回路に到達する信号を、行われる適切な信号処理と実質的に時間同期させる必要がある。このような同期を実現することができる信号処理ステップまたは方法によって達成される高レベルの状態図は、図４９に示されている。図４９では、状態機械4900における予想される順方向リンク同期“状態”が示されており、１つの非同期フレーム状態4904、２つの同期獲得状態4902および4906と、３つの同期状態4908、4910、および4912として分類されている。
【０２１５】
開始ステップまたは状態4902によって示されているように、提示デバイスのようなディスプレイまたはクライアントは、予め選択された“非同期”状態で始まり、検出される第１のサブフレームヘッダパケット内のユニークワードをサーチする。この非同期状態は、最小通信設定または“フォールバック”設定を表わし、タイプＩのインターフェイスが選択されることに注意すべきである。ユニークワードがサーチ中に検出されると、ディスプレイは、サブフレーム長フィールドをセーブする。この第1のフレームにおいて、すなわち、同期が得られるまでは、処理に対するＣＲＣビットの検査はない。このサブフレーム長がゼロであるときは、それに応じて、同期状態の処理は、ここでは“非同期フレーム”状態と示されている状態4904に進み、これは、同期がまだ達成されていないことを示す。処理におけるこのステップは、図４９において、cond3、すなわち条件３になるように示されている。そうではなくて、フレーム長がゼロよりも長いときは、同期状態の処理は、状態4906へ進み、インターフェイスの状態は、“１つの同期フレームを検出”として設定される。処理におけるこのステップは、図４９において、cond5、すなわち条件５として示されている。さらに加えて、状態機械が、ゼロよりも長いフレーム長において、フレームヘッダパケットと好適なＣＲＣの判断とを確認すると、処理は、“１つの同期フレームを検出”状態へ進む。これは、図４９において、cond6、すなわち条件６として示されている。
【０２１６】
システムが“非同期”以外の状態である各状況において、ユニークワードが検出され、サブフレームヘッダパケットに対して好適なＣＲＣの結果が判断され、かつサブフレームの長さがゼロよりも長いときは、インターフェイスの状態は、“同期”状態4908に変わる。処理におけるこのステップは、図４９において、cond1、すなわち条件１として示されている。他方で、ユニークワードも、サブフレームヘッダパケット内のＣＲＣも正しくないときは、同期状態の処理は、“非同期フレーム”状態のインターフェイス状態4902へ進む、または戻る。処理のこの部分は、図４９の状態図において、cond2、すなわち条件２として示されている。
【０２１７】
Ｂ．同期の獲得時間
同期が失われていると判断して、“非同期フレーム”状態に戻る前に、ある特定数の“同期誤り”を受け入れるように、インターフェイスを構成することができる。図４９では、状態機械が“同期”状態に達し、誤りが見付からないときは、それは、引き続きcond1の結果に出会い、“同期”状態のままである。しかしながら、１つのcond2の結果が検出されると、処理は状態を“１つの同期誤り”の状態4910に変更する。この時点で、処理が、別のcond1の結果を検出すると、状態機械は、“同期”状態に戻り、そうではなくて、別のcond2の結果に出会うと、“２つの同期誤り”の状態4912に移る。再び、cond1が現れると、処理は状態機械を“同期”状態へ戻す。そうではなくて、別のcond2に出会うと、状態機械は“非同期”状態へ戻る。インターフェイスが“リンク遮断パケット”に出会うと、これは、リンクにデータ転送を終了させ、同期するものがないので、“非同期フレーム”状態に戻り、これは、図４９の状態図においてcond4、すなわち条件４と呼ばれることも理解できる。
【０２１８】
サブフレーム内の幾つかの固定位置に現れ得るユニークワードの反復的な“偽のコピー”が存在する可能性があることが分かる。この状況では、ＭＤＤインターフェイスの処理が“同期”状態に進むために処理されるとき、サブフレームヘッダパケット上のＣＲＣも有効でなければならないので、状態機械がサブフレームに同期することになる可能性は非常に低い。
【０２１９】
リンクが遮断される前に、ホストが１つのみのサブフレームを伝送することを示すために、サブフレームヘッダパケット内のサブフレーム長をゼロに設定してもよく、ＭＤＤインターフェイスは、アイドル休止状態に置かれるか、またはそれに構成される。この場合に、リンクがアイドル状態に遷移する前に、１つのみのサブフレームが送られるので、サブフレームヘッダパケットを検出した後で、ディスプレイは、直ちに順方向リンク上でパケットを受信しなければならない。正規の、または標準的な動作において、サブフレーム長は、ゼロ以外であり、ディスプレイは、順方向リンクパケットのみを処理し、一方で、インターフェイスは、図４９において一括して“同期”状態として示されている状態である。
【０２２０】
ディスプレイが順方向リンク信号に同期するのに必要とされる時間は、サブフレームのサイズおよび順方向リンクのデータレートに依存して可変である。順方向リンクにおいてランダムな、またはよりランダムなデータの一部として、ユニークワードの“偽のコピー”を検出する可能性は、サブフレームのサイズがより大きくなるときに、より高くなる。同時に、順方向リンクのデータレートがより緩慢になるとき、偽の検出から回復する能力がより低くなり、これを行うのにかかる時間は、より長くなる。
【０２２１】
Ｃ．初期設定
既に記載したように、“起動”時に、ホストは、１メガビット秒の最低要求、または希望データレート以下で動作するように順方向リンクを構成し、サブフレーム長および媒体フレームレートを、所与の応用にとって適切に構成する。したがって、順方向リンクおよび逆方向リンクの両者は、タイプＩのインターフェイスを使用して動作を始める。これらのパラメータは、一般に、一時的に使用されることになる一方で、ホストは、クライアントディスプレイ（または、他のタイプのクライアントデバイス）の能力または希望の構成を判断する。ホストは、順方向リンクによってサブフレームヘッダパケット、およびそれに続く、１の値に設定された要求フラグのビット‘０’をもつ逆方向リンクカプセル化パケットを送るか、または転送し、ディスプレイまたはクライアントがディスプレイ能力パケットで応答することを要求する。ディスプレイは、順方向リンク上で（または、それとの）同期を得ると、ディスプレイ能力パケットおよびディスプレイ要求および状態パケットを逆方向リンクまたはチャネル上で送る。
【０２２２】
ホストは、ディスプレイ能力パケットの内容を調べて、最適または希望レベルの性能のためにリンクをどのように再構成するかを判断する。ホストは、プロトコルバージョンおよび最低プロトコルバージョンフィールドを調べて、ホストおよびディスプレイが、相互に互換性のあるプロトコルバージョンを使用していることを確認する。プロトコルバージョンは、通常、ディスプレイ能力パケットの最初の２つのパラメータとしてそのまま残り、したがって、プロトコルの他の要素が、互換性がない可能性があるか、または互換性がないと完全に理解され得るときでも、互換性があると判断することができる。
【０２２３】
Ｄ．ＣＲＣの処理
パケットプロセッサ状態機械は、全てのパケットタイプについて、ＣＲＣのチェッカが適切にまたは適正に制御されることを保証する。また、これは、ＣＲＣの比較により、１つ以上の誤りが検出されたときは、ＣＲＣ誤りカウンタをインクリメントし、各サブフレームが処理される始めに、ＣＲＣカウンタをリセットする。
【０２２４】
Ｅ．別の同期損失検査
上述の一連のステップすなわち条件が、より高いデータレートまたはスループット速度を生むように働く一方で、出願人は、クライアントが、ホストとの同期が失われていることを宣言するのに使用する条件における別の取り決めまたは変更を効果的に使用して、一層高いデータレートまたはスループットを達成できることを発見した。新しい発明的な実施形態は、同じ基本構造をもつが、状態を変更する条件が変わっている。さらに加えて、新しいカウンタが構成され、サブフレームの同期の検査を行うのを助ける。これらのステップまたは状態は、図６３に関係付けて提示されており、これは、方法すなわち状態機械の動作を設定するのに役立つ一連の状態および条件を示している。分かり易くするために、“同期獲得状態”および“同期状態”の部分のみが示されている。さらに加えて、結果の状態は、状態機械自体と実質的に同じであるので、同じ参照番号を使用する。しかしながら、状態を変更する条件（および、状態機械の動作）は、ある程度異なるので、分かり易くするために、２つの図において、違いを識別するのに便利なように、全てが番号を付け直されている（１、２、３、４、５、および６に対して、６１、６２、６３、６４、および６５）。非同期フレーム状態は、この説明において検討されないので、この図では、１つの状態（4904）および条件（６）は、最早使用されていない。
【０２２５】
図６３では、（表示または提示のための）システムまたはクライアントは、図４９におけるように、予め選択された“非同期”状態4902の状態機械6300で始まる。非同期条件4902から状態を変更するための第１の状態変化は、同期パターンの発見である条件64である。サブフレームヘッダのＣＲＣもこのパケットを承諾する（条件61を満たす）と仮定すると、パケットプロセッサ状態機械の状態は、同期状態4908に変わることができる。同期誤りの条件62があると、状態機械は状態4910へ移り、第２の同期誤り条件が現れると、状態4912に移ることになる。しかしながら、ＭＤＤＩパケットの何れかのＣＲＣの不合格は、状態機械を同期状態4908から１つの同期誤り状態4910へ動かすことになることが分かった。何れかのＭＤＤＩパケットの別のＣＲＣの不合格は、２つの同期不合格状態4912に動かすことになる。正しいＣＲＣ値で復号されたパケットは、状態機械を同期状態4908へ戻すことになる。
【０２２６】
変わったことは、‘各’パケットごとにＣＲＣの値または判断を使用することである。すなわち、状態機械に、単にサブフレームヘッダパケットを観察するのではなく、各パケットごとにＣＲＣ値を調べて、同期の損失を判断することである。この構成または処理では、同期の損失は、ユニークワードおよび単なるサブフレームヘッダのＣＲＣ値を使用して判断されない。
【０２２７】
この新しいインターフェイスの構成は、ＭＤＤインターフェイスリンクが、相当により迅速に同期の不合格を認識し、したがって、それらからより迅速に回復することも可能にする。
【０２２８】
このシステムをよりロバストにするために、クライアントは、サブフレームカウンタも追加または使用すべきである。したがって、クライアントは、ユニークワードの存在を、それが到達するか、または信号内に現れると期待されるときに、検査する。ユニークワードが適時に現れないときは、クライアントは、同期の不合格が生じたことを、サブフレーム長よりも長い幾つか（ここでは、３つ）のパケット時間または期間を待たなければならない場合よりも、さらに一層早く認識できる。ユニークワードの試験が、それが存在しない、言い換えると、タイミングが正しくないことを示すとき、クライアントは、直ちに、リンクが同期を失なったことを宣言し、非同期状態へ移ることができる。適切なユニークワードの存在を検査する処理は、状態機械に、ユニークワードが正しくないことを示す条件65（cond65）を追加する。サブフレームパケットがクライアント上で受信されると期待されるが、一致しないときは、クライアントは、直ちに非同期状態4902へ行き、通常は状態4910と4912とを横切るときに出会う多数の同期誤り（条件62）を待つ追加の時間を省くことができる。
【０２２９】
この変更では、クライアントのコアにおいて追加のカウンタまたはカウンティング機能を使用して、サブフレーム長をカウントする。１つの実施形態では、カウントダウン機能が使用され、カウンタの時限が切れたときに、現在処理されている任意のパケットの転送が中断されて、サブフレームのユニークワードを検査する。その代りに、カウンタはカウントアップしてもよく、カウントは、現在のパケットが検査される時点で、希望の最大または特定の希望値と比較される。この処理は、クライアント上で不適切に受信された、異常に長いパケット長をもつパケットを復号することから、クライアントを保護する。サブフレーム長カウンタが、何か別のパケットが復号されているのを中断するのに必要とされるとき、パケットはサブフレーム境界を横切らないので、同期を失ったと判断することができる。
【０２３０】
ＩＸ．パケットの処理
状態機械が受信する上述のパケットの各タイプごとに、これは、インターフェイスの動作を実行するための特定の処理ステップまたは一連のステップを行う。順方向リンクパケットは、通常、次の表１２に示されている例示的な処理にしたがって処理される。
【表１２】
2011176810.tif 000014
【０２３１】
Ｘ．逆方向リンクデータレートの低減
非常に望ましい、最大またはより最適化された（スケールの）逆方向リンクのデータレートを達成するために、ホストリンク制御装置で使用されているある特定のパラメータを、ある特定のやり方で調整または構成できることが、本発明者によって確認された。例えば、逆方向リンクカプセル化パケットの逆方向データパケットフィールドを転送するのに使用される時間中に、ＭＤＤＩ Ｓｔｂ信号の対は、順方向リンクのデータレートの２分の１で、周期的なデータクロックを生成するように切り換わる。これは、ホストリンク制御装置が、それが全てゼロを送っているかのように、ＭＤＤＩ Ｄａｔａ０の信号に対応するＭＤＤＩ Ｓｔｂ信号を生成するために生じる。ＭＤＤＩ Ｓｔｂ信号は、クライアントからホストへ転送され、ここで、これは、ディスプレイから逆方向リンクデータを転送するためのクロック信号を生成するのに使用され、逆方向データは、それと共に、ホストへ再び送られる。ＭＤＤＩを採用しているシステムにおける順方向および逆方向の経路上での信号転送および処理において直面する標準量の遅延の説明は、図５０に示されている。図５０では、一連の遅延値、すなわち、１．５ナノ秒、８．０ナノ秒、２．５ナノ秒、２．０ナノ秒、１．０ナノ秒、１．５ナノ秒、８．０ナノ秒、および２．５ナノ秒が、Ｓｔｂ＋／−の生成段、ディスプレイへのケーブル転送段、ディスプレイ受信機段、クロック生成段、信号クロッキング段、Ｄａｔａ０＋／−の生成段、ホストへのケーブル転送段、およびホスト受信機段の処理部分の近くに、それぞれ示されている。
【０２３２】
直面している順方向リンクデータレートおよび信号処理遅延に依存して、“往復”効果または完了される１組のイベントにおいて、ＭＤＤＩ Ｓｔｂ信号に対して２つ以上のサイクルを必要とすることがあり、したがって、望ましくない消費量の時間またはサイクルになる。この問題を回避するために、逆方向レートの除数は、逆方向リンク上での１ビット時間が、ＭＤＤＩ Ｓｔｂ信号の多数のサイクルにまたがることを可能にする。これは、逆方向リンクデータレートが、順方向リンクレートよりも低いことを意味する。
【０２３３】
インターフェイスを通る信号の遅延の実際の長さは、使用されている各専用のホスト−クライアントシステムまたはハードウエアに依存して異なり得ることに注意すべきである。要求されているわけではないが、通常、往復遅延測定パケットを使用して、システムにおける実際の遅延を測定し、逆方向レートの除数を最適値に設定できるようにすることによって、各システムをよりよく動作するようにすることができる。
【０２３４】
往復遅延は、ホストに往復遅延測定パケットをディスプレイへ送らせることによって測定される。ディスプレイは、測定期間フィールドと呼ばれる、そのパケット内の予め選択された測定ウインドウ中、またはその間に、１の系列をホスト側へ送ることによって、このパケットに応答する。この測定の詳細なタイミングは、既に記載した。往復遅延は、逆方向リンクデータを安全にサンプリングすることができるレートを判断するのに使用される。
【０２３５】
往復遅延測定は、測定期間フィールドの始めと、クライアントからの０ｘｆｆ、０ｘｆｆ、０ｘ００の応答系列がホストにおいて受信されるときの時間期間の始めとの間に現れる順方向リンクデータクロック間隔の数を判断、検出、またはカウントすることから成る。測定カウントがインクリメントしようとする前の、順方向リンククロック期間の小さい部分において、クライアントからの応答が受信されることができることに注意すべである。逆方向レートの除数を計算するのに、この未修正値が使用されると、信頼できないデータのサンプリングのために、逆方向リンク上にビット誤りを生じ得る。この状況の例は、図５１に示されており、ここでは、ホストにおけるＭＤＤＩ Ｄａｔａ、ホストにおけるＭＤＤＩ Ｓｔｂ、ホスト内の順方向リンクデータクロック、および遅延カウントを表わす信号がグラフで示されている。図５１では、ディスプレイからの応答系列は、遅延カウントが６から７へインクリメントしようとする前に、順方向リンクのクロック期間の一部において受信された。遅延が６であると仮定すると、ホストは、ビットの遷移の直後に、または恐らくは、ビットの遷移の途中で、逆方向データをサンプリングすることになる。したがって、ホストにおけるサンプリングが誤りを含むことになり得る。このために、測定された遅延は、逆方向レートの除数を計算するのに使用される前に、通常は、１をインクリメントされるべきである。
【０２３６】
逆方向レートの除数は、ホストが、逆方向リンクデータをサンプリングする前に待つべきＭＤＤＩ Ｓｔｂのサイクルの数である。ＭＤＤＩ Ｓｔｂは、順方向リンクのレートの２分の１のレートで循環されるので、補正された往復遅延の測定値は、２によって除算され、その後で、次の整数に切り上げられる必要がある。この関係を、式として表わし、次に示す。
【数１】
2011176810.tif 000015
【０２３７】
この例に使用されている往復測定値が、６ではなく、７であるとき、逆方向レートの除数も、４に等しくなる。
【０２３８】
逆方向リンクデータは、ホストによって、逆方向リンククロックの立ち上がり端においてサンプリングされる。ホストおよびクライアント（ディスプレイ）の両者内に、逆方向リンククロックを生成するためのカウンタまたは同様の既知の回路またはデバイスが存在する。カウンタは、逆方向リンククロックの第１の立ち上がり端が、逆方向リンクカプセル化パケットの逆方向リンクパケットフィールド内の第１のビットの最初に現れるように初期設定される。これは、後で与えられる例のために、図５２に示されている。カウンタは、ＭＤＤＩ Ｓｔｂ信号の各立ち上がり端でインクリメントし、カウントがラップアラウンドするまでに現れるカウントの数は、逆方向リンクカプセル化パケット内の逆方向レートの除数のパラメータによって設定される。ＭＤＤＩ Ｓｔｂ信号は、順方向リンクレートの２分の１で切り換わるので、逆方向リンクレートは、逆方向レートの除数によって除算される順方向リンクレートの２分の１である。例えば、順方向リンクレートが２００メガビット秒であり、逆方向レートの除数が４であるとき、逆方向リンクのデータレートは、次のように表わされる。
【数２】
2011176810.tif 000016
【０２３９】
逆方向リンクカプセル化パケットにおいてＭＤＤＩ Ｄａｔａ０およびＭＤＤＩ Ｓｔｂの信号のラインのタイミングを示す例は、図５２に示されており、ここでは、説明のために使用されるパケットパラメータは、次に示す値をもつ。
【０２４０】
パケット長＝１０２４（０ｘ０４００）    折り返し１の長さ＝１
パケットタイプ＝６５（０ｘ４１）        折り返し２の長さ＝１
逆方向リンクフラグ＝０                  逆方向レートの除数＝２
パラメータＣＲＣ＝０ｘｄｂ４３          全てゼロは、０ｘ００
パケット長とパラメータＣＲＣのフィールド間のパケットデータは、
０ｘ００、０ｘ０４、０ｘ４１、０ｘ００、０ｘ０２、０ｘ０１、０ｘ０１、０ｘ４３、０ｘｄｂ、０ｘ００、．．．である。
【０２４１】
ディスプレイから戻される第１の逆方向リンクパケットは、７のパケット長および７０のパケットタイプをもつディスプレイ要求および状態パケットである。このパケットは、バイト値０ｘ０７、０ｘ００、０ｘ４６、．．．等で始まる。しかしながら、第１のバイト（０ｘ０７）のみが、図５２に示されている。この第１の逆方向リンクパケットは、実際の逆方向リンクの遅延を示すために、図においてほぼ１の逆方向リンククロック期間分、タイムシフトされる。ホストからデバイスへの往復遅延がゼロである理想的な波形は、点線で示されている。
【０２４２】
パラメータＣＲＣフィールドのＭＳのバイトは、パケットタイプ、したがって、全てゼロのフィールドに先行して転送される。ホストからのストローブは、１からゼロへスイッチし、ホストからのデータがレベルを変更するときに、１に戻って、より幅広いパルスを形成する。データがゼロになると、ストローブはより高いレートでスイッチし、データライン上のデータのみが、整列フィールドの最後の近くで変わる。図の残りにおいて、データ信号は、より長い時間期間の間、０または１のレベルに固定されるまで、ストローブはより高いレートでスイッチし、遷移はパルスパターン（端）に入る。
【０２４３】
クロックが逆方向リンクパケットに適応するように開始されるとき、ホストの逆方向リンクのクロックは、折り返し１の期間の最後までゼロである。図の下方部分の矢印は、データがサンプリングされるときを示しており、これは、後の開示から明らかになるであろう。転送されるパケットフィールド（ここでは、１１００００００）の第１のバイトは、折り返し１の後で始まることが示されており、ラインレベルは、ホストドライバがディスエーブルされることにより安定化される。第１のビットを送る遅延は、ビット３で分かるように、データ信号の点線で示されている。
【０２４４】
図５３では、順方向リンクのデータレートに基づく逆方向レートの除数の標準値を確認することができる。実際の逆方向レートの除数は、適切な逆方向リンクの動作を保証するために、往復リンク測定の結果として判断される。第１の領域5302は、安全動作区域に対応し、第２の領域5304は、限界パフォーマンス区域に対応し、一方で、第３の領域5306は、適切に機能しそうにない設定を示している。
【０２４５】
往復遅延測定および逆方向レートの除数の設定は、順方向リンクまたは逆方向リンクの何れかにおけるインターフェイスタイプの設定の何れかで動作する間、送信または受信されるビット数でなく、実際のクロック期間の単位で表され、演算されるので、同じである。
【０２４６】
ＸＩ．折り返しおよび保護時間
既に記載したように、逆方向リンクカプセル化パケット内の折り返し１のフィールドと、往復遅延測定パケット内の保護時間１のフィールドとは、ディスプレイインターフェイスドライバがイネーブルされる前に、ホストインターフェイスドライバがディスエーブルされるのを可能にする時間長の値を示す。折り返し２および保護時間２のフィールドは、ホストドライバがイネーブルされる前に、ディスプレイドライバがディスエーブルされるのを可能にする時間値を与える。保護時間１および保護時間２のフィールドは、通常、調節されるのを意図されていない長さにおいて、予め設定された、または予め選択された値で埋められる。使用されるインターフェイスのハードウエアに依存して、これらの値は、経験的なデータを使用して生成され、動作を向上するために、いくつかのインスタンスで調整され得る。
【０２４７】
幾つかの要素が、折り返し１の長さの判断に役立ち、それらは、順方向リンクデータレート、およびホスト内のＭＤＤＩ Ｄａｔａドライバの最大ディスエーブル時間である。最大のホストドライバのディスエーブル時間は、表１１に特定されており、これは、ドライバが、ディスエーブルするのに最大約１０ナノ秒、イネーブルするのに約２ナノ秒かかることを示している。ホストドライバがディスエーブルされるのに必要とされる順方向リンククロックの最小数は、次の関係にしたがって表わされる。
【数３】
2011176810.tif 000017
【０２４８】
折り返し１の許容値の範囲は、次の関係にしたがって表わされる。
【数４】
2011176810.tif 000018
【０２４９】
ここで、インターフェイスタイプの係数は、タイプＩは１、タイプＩＩは２、タイプＩＩＩは４、タイプＩＶは８である。
【０２５０】
上記の２つの式を組合せると、インターフェイスタイプの係数の項は、約分され、折り返し１は次のように定められることが分かる。
【数５】
2011176810.tif 000019
【０２５１】
例えば、１５００メガビット秒のタイプＩＩＩの順方向リンクは、次の折り返し１の遅延を使用することになる。
【数６】
2011176810.tif 000020
【０２５２】
往復遅延時間が増加するのにしたがって、ホストがディスエーブルされる時点から、ディスプレイがイネーブルされるときまでのタイミングのマージンは、向上する。
【０２５３】
通常折り返し２に使用される時間長を判断する要素は、順方向リンクのデータレート、ディスプレイ内のＭＤＤＩ Ｄａｔａドライバの最大ディスエーブル時間、および通信リンクの往復遅延である。ディスプレイドライバをディスエーブルするのに必要とされる時間の計算は、本質的に、上述のホストドライバのものと同じであり、次の関係にしたがって定められる。
【数７】
2011176810.tif 000021
【０２５４】
折り返し２の許容値の範囲は、次のように表わされる。
【数８】
2011176810.tif 000022
【０２５５】
例えば、１０個の順方向リンククロックをもつ１５００メガビットのタイプＩＩＩの順方向リンクは、通常、次式と同等の折り返し２の遅延を使用する。
【数９】
2011176810.tif 000023
【０２５６】
ＸＩＩ．別の逆方向リンクのタイミング
既に記載したタイミングおよび保護帯域の使用は、高データ転送レートのインターフェイスを実現するように働くが、本発明者は、逆方向のタイミングの発見を変えることによって、往復時間よりも短い逆方向ビットの長さを可能にする技術を発見した。
【０２５７】
既に提示されたように、逆方向リンクのタイミングへの以前のアプローチは、クロックサイクルの数は、逆方向のタイミングパケットの保護時間1の最後のビットから、第１のビットがＩＯクロックの立ち上がり端においてサンプリングされるまで、カウントされるように構成されている。これは、ＭＤＤインターフェイスの入力および出力の時間を計るのに使用されるクロック信号である。したがって、逆方向レートの除数の計算は、次の式によって与えられる。
【数１０】
2011176810.tif 000024
【０２５８】
これは、往復遅延に等しいビット幅を与え、非常に確実な逆方向リンクになる。しかしながら、逆方向リンクは、より迅速に、またはより高いデータ転送レートで実行できることが示されており、本発明者がそれを利用することを望んでいる。新しい発明的な技術は、より高い速度に達するインターフェイスの付加的な能力を使用することを可能にする。
【０２５９】
これは、１がサンプリングされるまで、ホストにクロックサイクル数をカウントさせるが、ホストが逆方向タイミングパケット中に、立ち上がり端および立ち下がり端の両者上でデータラインをサンプリングすることによって達成される。これは、ホストが、逆方向ビット内の最も有益か、または、さらには、最適なサンプリング点を選び、ビットが安定していることを保証することを可能にする。したがって、最も有益な、または最適な立ち上がり端を検出して、逆方向トラヒックの逆方向カプセル化パケットのデータをサンプリングする。最適サンプリング点は、逆方向リンクの除数と、第１のものが立ち上がり端または立ち下がり端上で検出されたかどうかの両者に依存する。新しいタイミング方法は、ホストが、逆方向リンクのタイミングにおいてクライアントによって送られた０ｘｆｆ０ｘｆｆ ０ｘ００のパターンの第１の端を単に探して、逆方向カプセル化パケット内のサンプリングする場所を判断することを可能にする。
【０２６０】
到達する逆方向ビット、およびそのビットが種々の逆方向レートの除数をどのように探すかの例は、保護時間１の最後のビット以降に現れたクロックサイクル数と共に、図６４に示されている。図６４では、第１の端が、立ち上がり端と立ち下がり端（立ち上がり／立ち下がりと示されている）との間に現れるとき、１の逆方向レートの除数の最適サンプリング点、すなわち最適サンプル点は、‘ｂ’が逆方向ビットの期間内に現れる唯一の立ち上がり端であるので、‘ｂ’と示されたクロックサイクルの端であることが分かる。２の逆方向レートの除数では、サイクルの端‘ｃ’が、‘ｂ’よりもビットの端により近いので、最適サンプリング点は、恐らくは、依然としてクロックサイクルのリーディングエッジ‘ｂ’である。４の逆方向レートの除数では、‘ｄ’が、逆方向ビットの後ろの端により近く、ここでは、値が、恐らくは安定しているので、最適サンプリング点は、恐らくは、クロックサイクルの端‘ｄ’である。
【０２６１】
図６４に戻ると、しかしながら、第１の端が立ち下がり端と立ち上がり端（立ち下がり／立ち上がりと示されている）との間に現れるときは、 ‘ａ’が逆方向ビットの時間期間内の唯一の立ち上り端であるので、１の逆方向レートの除数の最適サンプリング点は、クロックサイクルの端‘ａ’のサンプリング点である。２の逆方向レートの除数では、最適サンプリング点は、端‘ｂ’であり、４の逆方向レートの除数では、最適サンプリング点は端‘ｃ’である。
【０２６２】
逆方向レートの除数が大きくなるのにしたがって、最適サンプリング点は、真ん中に最も近い立ち上がり端になるはずであるので、確認または選択し易くなることが分かる。  ホストは、この技術を使用して、タイミングパケットデータの立ち上がりデータ端がデータライン上で確認される前に、立ち上がりクロック端の数値を検出することができる。したがって、これは、端が、立ち上がり端と立ち下がり端との間に現れるか、または立ち下がり端と立ち上がり端との間に現れるか、および逆方向レートの除数が何であるかに基づいて、ビットが常に、可能な限り真ん中近くでサンプリングされることを合理的に保証するために、数カウンタに追加する追加のクロックサイクルがいくつであるかを決定することができる。
【０２６３】
ホストは、クロックサイクルを選択するか、または判断すると、クライアントの種々の逆方向レートの除数を“探り”、特定の逆方向レートの除数が働くかどうかを判断することができる。ホスト（およびクライアント）は、１の除数で始め、クライアントから受信した逆方向状態パケットのＣＲＣを検査して、この逆方向レートがデータを転送するために正しく機能しているかどうかを判断することができる。ＣＲＣが正しくないときは、恐らくは、サンプリングに誤りがあり、ホストは、逆方向レートの除数を大きくして、状態パケットを再び要求することを試みる。第２の要求されたパケットが正しくないときは、除数を再び大きくして、再び要求を行うことができる。このパケットが正しく復号されると、この逆方向レートの除数は、全ての将来の逆方向パケットに使用されることができる。
【０２６４】
逆方向のタイミングは、最初の往復のタイミングの推定値から変わるはずはないので、この方法は、効果的で、有益である。順方向リンクが安定しているときは、逆方向リンクの破損があるときでも、クライアントは、順方向リンクのパケットを復号し続けるべきである。もちろん、この方法は、完全な逆方向リンクを保証していないので、リンクのための逆方向リンクの除数を設定することは、依然としてホストの責務である。さらに加えて、除数は、主に、ＩＯクロックを生成するのに使用されるクロックの品質に依存する。そのクロックが相当な量のジッタをもつとき、サンプリングの誤りの確率がより高くなる。この誤りの確率は、往復遅延内のクロックサイクルの量に伴って増加する。
【０２６５】
この実行は、タイプＩの逆方向データでは最も良く働くと考えられるが、タイプＩＩないしタイプＩＶの逆方向データでは、１つのみのデータの対において最良に働くレートでリンクを実行すると、データライン間のスキューが潜在的に大き過ぎるために、問題を提示し得る。しかしながら、動作のためにタイプＩＩないしタイプＩＶを使っても、恐らくは、データレートを前の方法に低減する必要はない。また、この方法は、理想的な、または最適なクロックサンプルの位置を選択するために、各データライン上で複製されるときに、最良に働き得る。それらが各データの対において同じサンプル時間であるとき、この方法は機能し続けるであろう。それらが異なるサンプル期間であるときは、２つの異なるアプローチが使用され得る。第１のアプローチでは、各データの対にとって同じでなくても、各データポイントにおいて、希望の、またはより最適なサンプル位置を選択する。ホストは、データの対の組からビットの全て、すなわち、タイプＩＩには２ビット、タイプＩＩＩには４ビット、タイプＩＶには８ビットをサンプリングした後に、データストリームを再構成することができる。他のオプションでは、ホストが逆方向レートの除数を大きくして、各データの対におけるデータビットが、同じクロック端においてサンプリングされることができるようにする。
【０２６６】
ＸＩＩＩ．リンク遅延およびスキューの効果
ＭＤＤＩ Ｄａｔａの対とＭＤＤＩ Ｓｔｂとの間の順方向リンク上の遅延スキューは、遅延スキューの補償が使用されない限り、最大可能データレートを制限し得る。タイミングのスキューを生む遅延の差は、別途概略的に記載されるように、制御装置の論理、ラインドライバおよび受信機、並びにケーブルおよびコネクタによる。
【０２６７】
Ａ．スキューにより制限されるリンクのタイミングの解析（ＭＤＤＩのタイプＩ）
１．タイプＩのリンクの遅延およびスキューの例
図４１に示されているものに類似した、タイプＩのインターフェイスのリンクに適応する標準的なインターフェイス回路は、図５７に示されている。図５７では、伝搬遅延およびスキューの例示的な、または標準的な値が、ＭＤＤＩのタイプＩの順方向リンクの幾つかの処理またはインターフェイス段の各々に示されている。ＭＤＤＩ ＳｔｂとＭＤＤＩ Ｄａｔａ０との間の遅延におけるスキューは、出力クロックのデューティサイクルを歪ませる。フリップフロップ5728、5730を使用する受信機のフリップフロップ（receiver flip-flop, RXFF）段のＤ入力におけるデータは、それが確実にサンプリングされることができるように、クロック端の後で、わずかに変わっていなければならない。図は、２つのカスケードされた遅延ライン5732aおよび5732bを示しており、これらは、このタイミングの関係を作ることに関する２つの異なる問題を解決するのに使用される。実際の実行では、これらは、１つの遅延素子に合成され得る。
【０２６８】
インターフェイスによる例示的な信号処理における、タイプＩのリンクのデータ、ストローブ、およびクロックの回復のタイミングは、図５８に示されている。
【０２６９】
大きい総遅延スキューは、通常、次の段、すなわち、フリップフロップ5704、5706をもつ送信機のフリップフロップ（transmitter flip-flop, TXFF）；ドライバ5708、5710をもつ送信機ドライバ（transmitter driver, TXDRVR）；ケーブル5702；受信機5722、5724をもつ受信機ライン受信機（receiver line receiver, RXRCVR）；受信機のＸＯＲ論理（receiver XOR logic, RXXOR）におけるスキューの和から成る、または来る。遅延１ 5732aは、ＲＸＸＯＲ段におけるＸＯＲゲート5736の遅延に整合するか、またはこれを越えるべきであり、次に示す関係によって判断される。
【０２７０】
ｔＰＤ−ｍｉｎ（Ｄｅｌａｙ１）≧ｔＰＤ−ｍａｘ（ＸＯＲ）
受信機のフリップフロップ5728、5730のＤ入力が、そのクロックの入力の前に変化しないように、この条件を満たすことが望ましい。ＲＸＦＦの保持時間がゼロであるとき、これは有効である。
【０２７１】
遅延２の目的または機能は、次の関係にしたがって、ＲＸＦＦのフリップフロップの保持時間を補償することである。
【０２７２】
ｔＰＤ−ｍｉｎ（Ｄｅｌａｙ２）＝ｔＨ（ＲＸＦＦ）
多くのシステムでは、保持時間がゼロであるので、これはゼロになり、もちろん、この場合は、遅延２の最大遅延もゼロになることができる。
【０２７３】
受信機ＸＯＲ段におけるスキューの最悪の場合の原因は、データ−遅／ストローブ−早の場合であり、ここで、遅延１は、最大値であり、ＸＯＲゲートからのクロック出力は、次に示す関係にしたがって可能な限り早くなる。
【０２７４】
ｔＳＫＥＷ−ｍａｘ（ＲＸＸＯＲ）＝ｔＰＤ−ｍａｘ（Ｄｅｌａｙ１）−ｔＰＤ−ｍｉｎ（ＸＯＲ）
この状況では、データは、２ビット期間、すなわち、ｎとｎ＋１との間で、ビットｎ＋１が受信機のフリップフロップへクロックされる時間に非常に近くで変化し得る。
【０２７５】
ＭＤＤＩのタイプＩのリンクの最大データレート（最小ビット期間）は、ＭＤＤＩリンクにおける全ドライバ、ケーブル、受信機と、ＲＸＦＦ段への集合体データ設定との和によって生じる最大スキューの関数である。ＲＸＲＣＶＲ段の出力までのリンクにおける総遅延スキューは、次のように表されることができる。
【０２７６】
ｔＳＫＥＷ−ｍａｘ（ＬＩＮＫ）＝ｔＳＫＥＷ―ｍａｘ（ＴＸＦＦ）＋ｔＳＫＥＷ−ｍａｘ（ＴＸＤＲＶＲ）＋ｔＳＫＥＷ−ｍａｘ（ＣＡＢＬＥ）＋ｔＳＫＥＷ−ｍａｘ（ＲＸＲＣＶＲ）
最小ビット期間は、次の式によって与えられる。
【０２７７】
ｔＢＩＴ−ｍｉｎ＝ｔＳＫＥＷ−ｍａｘ（ＬＩＮＫ）＋ｔＳＫＥＷ−ｍａｘ（ＲＸＸＯＲ）＋ｔＰＤ−ｍａｘ（Ｄｅｌａｙ２）＋ｔＳＵ（ＲＸＦＦ）
図５７に示されている例では、ｔＳＫＥＷ−ｍａｘ（ＬＩＮＫ）＝１．４ナノ秒であり、最小ビット期間は、
ｔＢＩＴ−ｍｉｎ＝１．４＋０．３＋０．２＋０．５＝２．４ナノ秒、または約４１６メガビット秒として表わされることができる。。
【０２７８】
Ｂ．ＭＤＤＩのタイプＩＩ、ＩＩＩ、およびＩＶのリンクのタイミングの解析
図４１および５７に示されているものに類似した、タイプＩＩ、ＩＩＩ、およびＩＶのインターフェイスリンクに適応する標準的なインターフェイス回路は、図５９に示されている。付加的な信号処理に適応するために、追加の素子が、ＴＸＦＦ段(5904)、ＴＸＤＲＶＲ段（5908）、ＲＸＲＣＶＣＲ段（5924）、およびＲＸＦＦ段（5932、5928、5930）において使用されている。図５９では、伝搬遅延およびスキューの例示的または標準的な値が、ＭＤＤＩのタイプＩＩの順方向リンクの幾つかの処理またはインターフェイス段の各々に示されている。出力クロックのデューティサイクルに影響を与えるＭＤＤＩ ＳｔｂとＭＤＤＩ Ｄａｔａ０との間の遅延におけるスキューに加えて、これらの２つの信号の両者と他のＭＤＤＩ Ｄａｔａ信号との間にもスキューがある。フリップフロップ5928および5930から成る受信機のフリップフロップＢ（receiver flip-flop, RXFFB）のＤ入力におけるデータは、それが確実にサンプリングされることができるように、クロック端の後で、僅かに変えられる。ＭＤＤＩ Ｄａｔａ１が、ＭＤＤＩ ＳｔｂまたはＭＤＤＩ Ｄａｔａ０よりも早く到達するときは、ＭＤＤＩ Ｄａｔａ１は、少なくとも遅延スキュー量分、サンプリングされるのを遅らされるべきである。これを実現するために、データは、遅延３の遅延ラインを使用して、遅延させられる。ＭＤＤＩ Ｄａｔａ１が、ＭＤＤＩ ＳｔｂまたはＭＤＤＩ Ｄａｔａ０よりも遅く到達し、さらに加えて、遅延３によって遅らされるときは、ＭＤＤＩ Ｄａｔａ１が変わる点は、次のクロック端により近くに動かさせられる。この処理は、ＭＤＤＩのタイプＩＩ、ＩＩＩ、またはＩＶのリンクのデータレートの上限を決める。２つのデータ信号とＭＤＤＩ Ｓｔｂとの相互のタイミングまたはスキューの関係についての幾つかの例示的な異なる可能性は、図６０Ａ、６０Ｂ、および６０Ｃに示されている。
【０２７９】
ＭＤＤＩ ＤａｔａＸが可能な限り早く到達したときに、ＲＸＦＦＢにおいてデータを確実にサンプリングするために、遅延３は、次の関係にしたがって設定される。
【０２８０】
ｔＰＤ−ｍｉｎ（Ｄｅｌａｙ３）≧ｔＳＫＥＷ−ｍａｘ（ＬＩＮＫ）＋ｔＨ（ＲＸＦＦＢ）＋ｔＰＤ−ｍａｘ（ＸＯＲ）
最大リンク速度は、最小許容ビット期間によって判断される。これは、ＭＤＤＩ ＤａｔａＸが可能な限り遅く到達したときに、最も影響を受ける。その場合には、最小許容サイクル時間は、次の式によって与えられる。
【０２８１】
ｔＢＩＴ−ｍｉｎ＝ｔＳＫＥＷ−ｍａｘ（ＬＩＮＫ）＋ｔＰＤ−ｍａｘ（Ｄｅｌａｙ３）＋ｔＳＵ（ＲＸＦＦＢ）−ｔＰＤ−ｍｉｎ（ＸＯＲ）
したがって、リンク速度の上限は、
ｔＰＤ−ｍａｘ（Ｄｅｌａｙ３）＝ｔＰＤ−ｍｉｎ（Ｄｅｌａｙ３）であり、
ｔＢＩＴ−ｍｉｎ（ｌｏｗｅｒ−ｂｏｕｎｄ）＝２・ｔＳＫＥＷ−ｍａｘ（ＬＩＮＫ）＋ｔＰＤ−ｍａｘ（ＸＯＲ）＋ｔＳＵ（ＲＸＦＦＢ）＋ｔＨ（ＲＸＦＦＢ）
と仮定される。
【０２８２】
上記で与えられた例において、最小ビット期間の下限は、次の関係によって与えられる。
【０２８３】
ｔＢＩＴ−ｍｉｎ（ｌｏｗｅｒ−ｌｅｖｅｌ）＝２・１．４＋１．５＋０．５＋０．１＝４．８ナノ秒、すなわち、約２０８メガビット秒である。
【０２８４】
これは、タイプＩのリンクで使用されることができる最大データレートよりも、一層相当に緩慢である。ＭＤＤＩの自動遅延スキュー補償能力は、遅延スキューが最大リンクレートに与える影響を相当に低減する。
【０２８５】
ＸＩＶ．物理層の相互接続の説明
本発明にしたがってインターフェイスを実行するのに役立つ物理的接続は、ホスト側では、Ｈｉｒｏｓｅ  Ｅｌｅｃｔｒｉｃ  Ｃｏｍｐａｎｙ  Ｌｔｄ．によって製造された部品番号３２６０−８Ｓ２（０１）、ディスプレイデバイス側では、Ｈｉｒｏｓｅ  Ｅｌｅｃｔｒｉｃ  Ｃｏｍｐａｎｙ  Ｌｔｄ．によって製造された部品番号３２４０−８Ｐ−Ｃのような市販の部品を使用して、実現されることができる。タイプＩ／タイプＩＩのインターフェイスで使用されるこのようなコネクタのための例示的なインターフェイスピン割り当てまたは“ピン配列”は、表１３に記載され、図６１に示されている。
【表１３】
2011176810.tif 000025
【０２８６】
シールドは、ホストインターフェイス側においてＭＤＤＩ Ｇｎｄに接続されており、ケーブル内のシールドドレイン線は、ディスプレイコネクタのシールドに接続されている。しかしながら、シールドおよびドレイン線は、ディスプレイの回路接地の内部に接続されていない。
【０２８７】
相互接続素子またはデバイスは、相対的なデバイスのサイズと比較して、ひどく目立つ、または美観が悪くなることなく、ＰＤＡおよび無線電話、またはポータブルゲームデバイスのような移動通信およびコンピューティングデバイスで使用するのに十分に小型であるように、選択または設計される。何れかのコネクタおよびケーブリングは、一般の消費者環境において使用するのに十分に耐久性があり、とくにケーブリングのための、小さいサイズと、比較的に低コストとを可能にするべきである。転送素子は、タイプＩおよびタイプＩＩでは約４５０メガビット秒まで、８ビットの並列のタイプＩのＶバージョンでは３．６ギガビット秒までの転送レートをもつ差動ＮＲＺデータであるデータおよびストローブ信号に適応すべきである。
【０２８８】
ＸＶ．動作
本発明の実施形態を使用して、インターフェイスの動作中にデータおよびパケットを処理するのに行われる一般的なステップの概要は、図５５のパケットを処理するインターフェイス装置の全体図と共に、図５４Ａおよび５４Ｂに示されている。これらの図において、処理は、ステップ5402において、クライアントおよびホストが、通信経路、ここでは、ケーブルを使用して、接続されているかどうかについて判断することから始まる。これは、（ＵＳＢインターフェイスで見られるように）ホストへの入力においてコネクタ、ケーブル、または信号の存在を検出するソフトウエアまたはハードウエアを使用して、または他の既知の技術で、ホストによる定期的なポーリングの使用によって行われることができる。ホストに接続されたクライアントがないときは、これは、単に、応用に依存して、ある所定の長さの待機状態に入るか、休止モードになるか、またはイナクティブにされて、ホストを再びアクティブにする動作をとるようにユーザに要求し得る将来の使用を待つようにすることができる。例えば、ホストがコンピュータタイプのデバイス上にあるとき、ユーザは、スクリーンのアイコンをクリックするか、またはクライアントを探すためのホストの処理をアクティブにするプログラムを要求することができる。ここでも、ホストまたは常駐のホストのソフトウエアの能力および構成に依存して、タイプＵのインターフェイスに使用されるような、ＵＳＢタイプの接続の簡単なプラグインが、ホストの処理をアクティブにすることができる。
【０２８９】
クライアントがホストに接続されるか、またはこの逆か、または存在していると検出されると、ステップ5404および5406において、クライアントまたはホストの何れかが、適切なパケット要求サービスを送る。ステップ5404において、クライアントは、ディスプレイサービス要求または状態パケットの何れかを送ることができる。既に記載したように、リンクは、既に遮断されているか、または休止状態であるので、これは、それがたどる通信リンクの完全な初期設定でないことがあることに注意すべきである。通信リンクが同期化され、ホストがクライアントと通信することを試みると、ステップ5408におけるように、クライアントも、ディスプレイ能力パケットをホストへ与える。ここで、ホストは、クライアントが適応できる、転送レートを含む、支援のタイプを判断し始めることができる。
【０２９０】
通常、ステップ5410において、ホストおよびクライアントは、使用されるサービスモードのタイプ（レート／速度）、例えば、タイプＩ、タイプＵ、タイプＩＩ、等もネゴシエートする。サービスタイプが設定されると、ホストは、情報を転送し始めることができる。さらに加えて、ステップ5411において、ホストは、往復遅延測定パケットを使用して、他の信号処理と並行する通信リンクのタイミングを最適化することができる。
【０２９１】
既に記載したように、全ての転送は、ステップ5412において転送されるサブフレームヘッダパケットから始まり、その後で、ステップ5414において転送されることが示されているデータのタイプ、ここでは、ビデオおよびオーディオストリームパケット、およびフィラーパケットが続く。オーディオおよびビデオデータは、予め準備されるか、またはパケットにマップされ、フィラーパケットは、必要または希望に応じて挿入され、媒体フレームへの必要な数のビットを充填する。ホストは、順方向オーディオチャネルイネーブルパケットのようなパケットを送って、音響デバイスをアクティブにすることができる。さらに加えて、ステップ5416において、ホストは、既に記載された他のパケットタイプ、ここでは、カラーマップ、ビットブロック転送、または他のパケットの転送として示されているものを使用して、命令および情報を転送することができる。さらに加えて、ホストおよびクライアントは、適切なパケットを使用して、キーボードまたはポインティングデバイスに関係するデータを交換することができる。
【０２９２】
動作中に、幾つかの異なるイベントの1つが行われ、これは、希望する異なるデータレートまたはインターフェイスのモードタイプへ導く。例えば、コンピュータ、またはデータを通信する他のデバイスは、パケットの準備または提示を減速させる、処理データの負荷条件に直面し得る。データを受信するディスプレイは、専用のＡＣ電源から、より制限されたバッテリ電源に変わると、迅速にデータを転送して、容易に命令を処理することも、またはより制限された電力設計のもとで、同じ程度の解像度または色の濃さを使用することもできない。その代りに、制限的な条件が緩和または無くされると、何れのデバイスもより高いレートでデータを転送することができる。したがって、より高い転送レートのモードに変える要求を行うことができることが、より望ましい。
【０２９３】
これらの、または他のタイプの既知の条件が現れるか、または変わるとき、ホストまたはクライアントの何れかが、それらを検出して、インターフェイスモードを再びネゴシエートすることを試みることができる。これは、ステップ5420に示されており、ここでは、ホストは、インターフェイスタイプハンドオフ要求パケットをクライアントへ送り、別のモードへのハンドオフを要求し、クライアントは、インターフェイスタイプ肯定応答パケットを送って、変更が求められたことを確認し、ホストは、タイプハンドオフ実行パケットを送って、特定のモードへの変更を行う。
【０２９４】
処理の特定の命令を要求することなく、クライアントおよびホストは、ポインティングデバイス、キーボード、または主にクライアントと関係付けられた他のユーザタイプの入力デバイス（このような素子は、ホスト側にも存在し得る）に宛てられた、またはそこから受信したデータに関係するパケットも交換することができる。これらのパケットは、一般に、状態機械ではなく、汎用プロセッサタイプの素子を使用して処理される（5502）。さらに加えて、既に記載された命令の幾つかも、汎用プロセッサによって処理されることになる（5504、5508）。
【０２９５】
データおよび命令が、ホストとクライアントとの間で交換された後で、幾つかの時点で、追加のデータが転送されるか、あるいはホストまたはクライアントが転送をサービスするのを止めることになるかについて、決定が行われる。これは、ステップ5422に示されている。リンクが、休止状態に入るか、または完全に遮断されることになるときは、ホストは、リンク遮断パケットをクライアントへ送って、両者はデータの転送を終了する。
【０２９６】
上述の動作処理において転送されるパケットは、ホストおよびクライアント制御装置に関連して既に記載されたドライバおよび受信機を使用して転送されることになる。これらのラインドライバおよび他の論理素子は、図５５の全体図に示されているように、既に記載された状態機械および汎用プロセッサに接続されている。図５５において、状態機械5502および汎用プロセッサ5504、5508は、図示されていない他の素子にも接続され得る。他の素子は、例えば、専用ＵＳＢインターフェイス、メモリ素子、またはそれらが対話するリンク制御装置の外部に存在する他の構成要素、すなわち、データ源、およびビューディスプレイデバイス（view display device）のためのビデオ制御チップを含むが、これらに制限されない。
【０２９７】
プロセッサおよび状態機械は、保護時間、等に関係して、既に記載されたドライバのイネーブリングおよびディスエーブリングにより制御を行って、通信リンクの効率的な設定または終了、およびパケットの転送を保証する。
【０２９８】
ＸＶＩ．補遺
本発明の実施形態のアーキテクチャおよびプロトコルを実行するのに使用される種々のパケットについて既に記載されたフォーマット、構造、および内容に加えて、ここでは、パケットタイプのいくつかについて、より詳しいフィールドの内容または動作を提示する。ここでは、これらは、それぞれの使用または動作をさらに明らかにして、当業者が本発明を容易に理解し、種々の応用に使用することを可能にするために提示される。ここでは、まだ記載されていないフィールドのいくつかのみを、さらに記載する。さらに加えて、これらのフィールドは、既に提示された実施形態に関連する例示的な定義および値と共に提示される。しかしながら、このような値は、本発明を制限するものとして解釈されるべきではなく、インターフェイスおよびプロトコルを実行するのに役立つ１つ以上の実施形態を表わしており、全ての実施形態が、一緒に、または同時に実行される必要があるわけではない。当業者には分かるように、他の実施形態では、希望のデータの提示またはデータレートの転送結果を達成するのに、他の値が使用されることができる。
【０２９９】
Ａ．ビデオストリームパケットについて
１つの実施形態では、表示属性フィールド（１バイト）は、一連のビット値をもち、それらを次に説明する。ビット１および０は、ディスプレイの画素データがどのように方向付けられるかを選択する。‘００’または‘１１’のビット値では、データは、両方の眼に表示され、ビット値‘１０’では、データは左眼のみに方向付けられ、ビット値‘０１’では、データは右眼のみに方向付けられる。ビット２は、画素データがインターレース形式で提示されるかどうかを示し、‘０’の値は、画素データが標準の漸進的な形式であることを意味し、１つの行から次の行へ進むときに、行番号（画素のＹ座標）が、１ずつインクリメントされる。このビットが‘１’の値をもつとき、画素データはインターレース形式であり、１つの行から別の行へ進むとき、行番号は２ずつインクリメントされる。ビット３は、画素データが、別の画素形式であることを示す。これは、ビット２によってイネーブルされる標準のインターレースモードに類似しているが、インターレーシングは、水平方向ではなく、垂直方向である。ビット３がゼロであるとき、画素データは標準の漸進的な形式であり、各連続の画素が受信されるときに、列番号（画素のＸ座標）は、１ずつインクリメントされる。ビット３が１であるとき、画素データは、別の画素形式であり、各画素が受信されるときに、列番号は、２ずつインクリメントされる。ビット７ないし４は、将来の使用のために確保され、通常、ゼロとして設定される。
【０３００】
２バイトのＸ開始およびＹ開始のフィールドは、画素データフィールド内の第１の画素のＸおよびＹの絶対座標の点（Ｘ開始、Ｙ開始）を特定する。２バイトのＸの左端およびＹの上端のフィールドが、画素データフィールドによって充填されたスクリーンウインドウの左端のＸ座標および上端のＹ座標を特定する一方で、Ｘの右端およびＹの下端のフィールドは、更新されるウインドウの右端のＸ座標および下端のＹ座標を特定する。
【０３０１】
画素カウントフィールド（２バイト）は、後述の画素データフィールド内の画素数を特定する。
【０３０２】
パラメータＣＲＣフィールド（２バイト）は、パケット長から画素カウントの全バイトのＣＲＣを含む。このＣＲＣが検査に不合格すると、全パケットが捨てられる。
【０３０３】
画素データフィールドは、表示される生のビデオ情報を含み、これは、ビデオデータフォーマット記述子フィールドによって記載されるやり方でフォーマットされる。データは、他で記載されるときは、１“行”で伝送される。
【０３０４】
画素データのＣＲＣフィールド（２バイト）は、画素データのみについて１６ビットのＣＲＣを含む。この値のＣＲＣの検証が不合格であるとき、それでも、画素データは使用されることができるが、ＣＲＣ誤りカウントはインクリメントされる。
【０３０５】
Ｂ．オーディオストリームパケットについて
１つの実施形態では、オーディオチャネルＩＤフィールド（１バイト）は、クライアントデバイスによってオーディオデータが送られる特定のオーディオチャネルを識別する。物理的なオーディオチャネルは、このフィールドにおいて特定されるか、またはこれによって、０、１、２、３、４、５、６、または７の値としてマップされる。これらの値は、それぞれ、左前、右前、左後、右後、前中心、サブウーファ、サラウンド左、およびサラウンド右のチャネルを示す。２５４のオーディオチャネルＩＤ値は、ディジタルオーディオサンプルの１本のストリームが、左前および右前の両者のチャネルへ送られることを示している。これは応用を特定し、ステレオヘッドセットが音声通信に使用されるときは、ＰＤＡ上で生産性向上の応用が使用され、または簡単なユーザインターフェイスが警告音を発生するときは、他の応用が使用される。ＩＤフィールドの値は、８ないし２５３の範囲にわたり、２５５は、新しい設計が追加の指示を要求するときに使用するために、現在は、確保されている。
【０３０６】
オーディオサンプルカウントフィールド（２バイト）は、このパケット内のオーディオサンプルの数を特定する。
【０３０７】
１サンプル当たりのビットおよびパッキングフィールドは、１バイトを含み、オーディオデータのペーシングのフォーマットを特定する。通常採用されるフォーマットは、ビット４ないし０であって、１ＰＣＭオーディオサンプル当たりのビット数を定める。次に、ビット５は、ディジタルオーディオデータサンプルがパックされるかどうかを特定する。既に記載したように、図１２は、パックされたオーディオサンプルと、バイトを整列させたオーディオサンプルとの相違を示している。ビット５における‘０’の値は、ディジタルオーディオデータフィールドの各ＰＣＭのオーディオサンプルが、インターフェイスのバイトの境界とバイトを整列させていることを示し、‘１’の値は、各連続するＰＣＭオーディオサンプルが、前のオーディオサンプルとパックされていることを示している。このビットは、ビット４ないし０に定められている値（１ＰＣＭオーディオサンプル当たりのビット数）が、８の倍数でないときのみ、有効である。ビット７ないし６は、システムの設計が追加の指定を要求するときに使用するために確保され、通常は、ゼロの値に設定される。
【０３０８】
オーディオサンプルレートフィールド（１バイト）は、オーディオＰＣＭサンプルレートを特定する。採用されたフォーマットでは、０の値は１秒当たりに８，０００サンプル（samples per second, sps）のレートを示し、１の値は１６，０００ｓｐｓを示し、２の値は２４，０００ｓｐｓ、３の値は３２，０００ｓｐｓ、４の値は４０，０００ｓｐｓ、５の値は４８，０００ｓｐｓ、６の値は１１，０２５ｓｐｓ、７の値は２２，０５０ｓｐｓ、８の値は４４，１００ｓｐｓを示し、９ないし１５の値は、将来の使用のために確保され、したがって、現在は、ゼロに設定されている。
【０３０９】
パラメータＣＲＣフィールド（２バイト）は、パケット長からオーディオサンプルレートへの全バイトの１６ビットのＣＲＣを含む。このＣＲＣが検査に適切に合格しないときは、全パケットが捨てられる。ディジタルオーディオデータフィールドは、再生される生のオーディオサンプルを含み、通常は、無符号整数のような線形フォーマットの形である。オーディオデータＣＲＣフィールド（２バイト）は、オーディオデータのみの１６ビットのＣＲＣを含む。このＣＲＣが検査に不合格であるとき、オーディオデータは、それでも使用されることができるが、ＣＲＣの誤りカウントはインクリメントされる。
【０３１０】
Ｃ．ユーザ定義ストリームパケットについて
１つの実施形態では、２バイトのストリームＩＤ番号フィールドは、個々のユーザ定義ストリームを識別するのに使用される。ストリームパケットおよびストリームデータフィールドの内容は、通常、ＭＤＤＩの装置の製造者によって定義される。２バイトのストリームパラメータのＣＲＣフィールドは、パケット長から始まり、オーディオ符号化バイトまでのストリームパラメータの全バイトの１６ビットのＣＲＣを含む。このＣＲＣが検査に不合格すると、全パケットが捨てられる。２バイトのストリームデータのＣＲＣフィールドは、ストリームデータのみのＣＲＣを含む。このＣＲＣフィールドが、検査に適切に合格しないときは、応用の要件に依存して、データストリームの使用はオプションである。ＣＲＣが好適であることを条件として、ストリームデータを使用することは、通常、ＣＲＣが好適であると確認されるまで、ストリームデータが緩衝されることを必要とする。ＣＲＣが検査しないときは、ＣＲＣの誤りカウントはインクリメントされる。
【０３１１】
Ｄ．カラーマップパケットについて
カラーマップデータサイズフィールド（２バイト）は、このパケット内のカラーマップデータ内に存在するカラーマップテーブルのエントリの総数を特定する。この実施形態では、カラーマップデータのバイト数は、カラーマップサイズの３倍である。カラーマップサイズは、カラーマップデータを送らないときは、ゼロに等しく設定される。カラーマップサイズがゼロであるときは、カラーマップオフセット値は、通常は、それでも依然として送られるが、ディスプレイによって無視される。カラーマップオフセットフィールド（２バイト）は、ディスプレイデバイスにおけるカラーマップテーブルの始めからの、このパケット内におけるカラーマップデータのオフセットを特定する。
【０３１２】
２バイトのパラメータＣＲＣフィールドは、パケット長からオーディオ符号化バイトまでの全バイトのＣＲＣを含む。このＣＲＣが検査に不合格すると、全パケットは捨てられる。
【０３１３】
カラーマップデータフィールドにおいて、カラーマップの位置は３バイトの値であり、第１のバイトは青の大きさを特定し、第２のバイトは緑の大きさを特定し、第３のバイトは赤の大きさを特定する。カラーマップサイズフィールドは、カラーマップデータフィールド内に存在する３バイトのカラーマップテーブルの項目の数を特定する。１つのカラーマップが、１つのビデオデータフォーマットおよびカラーマップパケットに適合することができないときは、各パケットにおいて、異なるカラーマップデータおよびカラーマップのオフセットと共に、多数のパケットを送ることによって、全カラーマップを特定することができる。
【０３１４】
２バイトのカラーマップデータのＣＲＣフィールドは、唯一のカラーマップデータのＣＲＣを含む。このＣＲＣが検査に不合格であるとき、カラーマップデータは、それでも使用されることができるが、ＣＲＣの誤りカウントはインクリメントされる。
【０３１５】
Ｅ．逆方向リンクカプセル化パケットについて
１つの実施形態では、逆方向リンクフラグフィールド（１バイト）は、ディスプレイから情報を要求する１組のフラグを含む。ビット（例えば、ビット０）が１に設定されると、ホストは、ディスプレイ能力パケットを使用して、ディスプレイから特定の情報を要求する。ビットがゼロであるときは、ホストは、ディスプレイから情報を要求しない。残りのビット（ここでは、ビット１ないし７）は、将来の使用のために確保され、ゼロに設定される。しかしながら、より多くのビットが、希望に応じて使用され、逆方向リンクのためのフラグを設定することができる。
【０３１６】
逆方向レートの除数のフィールド（１バイト）は、逆方向リンクデータクロックに関係して行われるＭＤＤＩ Ｓｔｂサイクルの数を特定する。逆方向リンクデータクロックは、順方向リンクデータクロックを逆方向レートの除数の２倍で除算したものに等しい。逆方向リンクのデータレートは、逆方向リンクにおける逆方向リンクデータクロックとインターフェイスタイプとに関係する。タイプＩのインターフェイスでは、逆方向データレートは、逆方向リンクデータクロックに等しく、タイプＩＩ、タイプＩＩＩ、およびタイプＩＶのインターフェイスでは、逆方向データレートは、それぞれ、逆方向リンクデータクロックの２倍、４倍、および８倍に等しい。
【０３１７】
折り返し１の長さのフィールド（１バイト）は、折り返し１に割り振られたバイトの総数を特定する。折り返し１の推奨される長さは、ホスト内のＭＤＤＩ Ｄａｔａドライバが出力をディスエーブルするのに必要とされるバイト数である。これは、既に記載した出力ディスエーブル時間、順方向リンクデータレート、および使用されている順方向リンクインターフェイスタイプ選択に基づく。折り返し１の設定についてのより完全な記述は、既に与えられている。
【０３１８】
折り返し２の長さのフィールド（１バイト）は、折り返しに割り振られたバイトの総数を特定する。折り返し２の推奨される長さは、ディスプレイ内のＭＤＤＩ Ｄａｔａドライバが出力と往復遅延とをディスエーブルするのに必要とされるバイト数である。折り返し２の設定の説明は、既に与えられている。
【０３１９】
パラメータＣＲＣフィールド（２バイト）は、パケット長から折り返し長までの全バイトの１６ビットのＣＲＣを含む。このＣＲＣが検査に不合格すると、全パケットは捨てられる。
【０３２０】
全てゼロのフィールド（１バイト）は、ゼロに等しく設定され、第１の保護時間期間中に、ラインドライバをディスエーブルする前に、全ＭＤＤＩ Ｄａｔａ信号がゼロの状態であることを保証するのに使用される。
【０３２１】
折り返し１のフィールドは、第１の折り返し期間を設定するのに使用される。折り返し長さパラメータによって特定されるバイト数は、このフィールドによって割り振られ、クライアント（ディスプレイ）内のラインドライバがイネーブルされる前に、ホスト内のＭＤＤＩ Ｄａｔａラインドライバがディスエーブルするのを可能にする。ホストは、折り返し１のビット０中に、そのＭＤＤＩ Ｄａｔａのラインドライバをディスエーブルし、クライアント（ディスプレイ）は、折り返し１の最後のビットの直後に、そのラインドライバをイネーブルする。ＭＤＤＩ Ｓｔｂ信号は、折り返し期間が全てゼロであるかのように動く。
【０３２２】
逆方向データパケットフィールドは、クライアントからホストへ転送される一連のデータパケットを含む。既に記載したように、フィラーパケットは、他のパケットタイプによって使用されていない残りの空間を充填するために送られる。
【０３２３】
折り返し２のフィールドは、第２の折り返し期間を設定するために使用される。折り返し長パラメータによって特定されるバイト数は、このフィールドによって割り振られる。
【０３２４】
ドライバ再イネーブルフィールドは、ゼロに等しい１バイトを使用して、全ＭＤＤＩ Ｄａｔａ信号が、次のパケットのパケット長フィールドの前に、再びイネーブルされるのを保証する。
【０３２５】
Ｆ．ディスプレイ能力パケットについて
１つの実施形態では、プロトコルバージョンフィールドは、２バイトを使用して、クライアントによって使用されるプロトコルバージョンを特定する。最初のバージョンがゼロに等しく設定される一方で、最低プロトコルバージョンフィールドは、２バイトを使用して、クライアントが採用または解釈することができる最低プロトコルバージョンを特定する。ディスプレイデータレート能力フィールド（２バイト）は、ディスプレイがインターフェイスの順方向リンク上で受信することができる最大データレートを特定し、１秒当たりのメガビット（megabit per second, Mbps）の形で特定される。インターフェイスタイプ能力フィールド（１バイト）は、順方向および逆方向上で支援されるインターフェイスタイプを特定する。これは、現在は、順方向リンクにおけるタイプＩＩ、タイプＩＩＩ、またはタイプＩＶのモードの何れかを選択するためにビット０、ビット１、またはビット２をそれぞれ選択し、逆方向リンクにおけるタイプＩＩ、タイプＩＩＩ、またはタイプＩＶのモードの何れかを選択するためにビット３、ビット４、またはビット５をそれぞれ選択し、ビット６および７を予備にして、ゼロに設定することによって示されている。ビットマップ幅および高さ（２バイト）は、画素内のビットマップの幅および高さを特定する。
【０３２６】
モノクローム能力フィールド（１バイト）は、モノクロームフォーマットで表示されることができる解像度のビット数を特定するのに使用される。ディスプレイがモノクロームフォーマットを使用できないときは、この値はゼロに設定される。ビット７ないし４は、将来の使用のために確保され、したがって、ゼロとして設定される。ビット３ないし０は、各画素において存在することができるグレースケールの最大ビット数を定める。これらの４ビットは、各画素において１ないし１５の値を特定することを可能にする。値がゼロであるときは、モノクロームフォーマットはディスプレイによって支援されない。
【０３２７】
カラーマップ能力フィールド（３バイト）は、ディスプレイ内のカラーマップテーブル内に存在するテーブルの項目の最大数を特定する。したがって、ディスプレイがカラーマップフォーマットを使用できないときは、この値はゼロである。
【０３２８】
ＲＧＢ能力フィールド（２バイト）は、ＲＧＢフォーマットで表示されることができる解像度のビット数を特定する。ディスプレイがＲＧＢフォーマットを使用することができないときは、この値はゼロに等しい。ＲＧＢ能力ワードは、３つの異なる無符号値から構成され、ビット３ないし０は、各画素内の青のビットの最大数を定め、ビット７ないし４は、緑のビットの最大数を定め、ビット１１ないし８は、赤のビットの最大数を定める。現在、ビット１５ないし１２は、将来の使用のために確保され、通常、ゼロに設定される。
【０３２９】
Ｙ Ｃｒ Ｃｂ能力フィールド（２バイト）は、Ｙ Ｃｒ Ｃｂフォーマットで表示されることができる解像度のビット数を特定する。ディスプレイがＹ Ｃｒ Ｃｂのフォーマットを使用できないときは、この値はゼロに等しく設定される。Ｙ Ｃｒ Ｃｂ能力ワードは、３つの別々の無符号値から構成され、ビット３ないし０は、Ｃｂサンプルにおけるビットの最大数を定め、ビット７ないし４は、Ｃｒサンプルにおけるビットの最大数を定め、ビット１１ないし８は、Ｙサンプルにおけるビットの最大数を定め、ビット１５ないし１２は、現在は、将来の使用のために確保され、ゼロに設定される。
【０３３０】
ディスプレイ特徴能力指標フィールドは、４バイトを使用し、支援されるディスプレイ内の特定の特徴を示す１組のフラグを含む。１に設定されたビットは、能力が支援されることを示し、ゼロに設定されたビットは、能力が支援されないことを示す。ビット０の値は、ビットマップブロック転送パケット（パケットタイプ７１）が支援されるかどうかを示す。ビット１、２、および３の値は、ビットマップ区域充填パケット（パケットタイプ７２）、ビットマップパターン充填パケット（パケット７３）、または通信リンクデータチャネルパケット（パケット７４）がそれぞれ支援されるかどうかを示す。ビット４の値は、ディスプレイが、１つの色を透明にする能力をもつかどうかを示し、一方で、ビット５および６の値は、ディスプレイが、それぞれ、ビデオデータまたはオーディオデータをパケットの形で受取ることができるかどうかを示し、ビット７の値は、ディスプレイがカメラから逆方向リンクのビデオストリームを送ることができるかどうかを示す。ビット１１および１２の値は、クライアントが、ポインティングデバイスで通信しているときに、ポインティングデバイスデータパケットを送受信できるか、またはキーボードで通信しているときに、キーボードデータパケットを送受信できるかをそれぞれ示す。ビット１３ないし３１は、現在は、将来の使用のために、またはシステム設計者にとって便利な別の設計のために確保され、通常、ゼロに等しく設定される。
【０３３１】
ディスプレイビデオフレームレート能力フィールド（１バイト）は、１秒当たりの、ディスプレイのフレームにおける最大ビデオフレーム更新能力を特定する。ホストは、このフィールドに特定されている値よりも遅いレートで画像を更新することを選択できる。
【０３３２】
オーディオ緩衝器深度フィールド（２バイト）は、各オーディオストリームに専用の、ディスプレイ内の融通の利く緩衝器の深度を特定する。
【０３３３】
オーディオチャネル能力フィールド（２バイト）は、何れのオーディオチャネルがディスプレイ（クライアント）によって支援されているかを示すフラグのグループを含む。１に設定されたビットは、チャネルが支援されていることを示し、ゼロに設定されたビットは、チャネルが支援されていないことを示す。ビット位置は、異なるチャネルに割り当てられ、例えば、ビット位置０、１、２、３、４、５、６、および７は、左前、右前、左後、右後、前中央、サブウーファ、サラウンド左、およびサラウンド右のチャネルをそれぞれ示す。ビット８ないし１５は、現在は、将来の使用のために確保され、通常は、ゼロに設定される。
【０３３４】
順方向リンクにおける、２バイトのオーディオサンプルレート能力フィールドは、クライアントデバイスのオーディオサンプルレートの能力を示す１組のフラグを含む。ビット位置は、適宜、異なるレートに割当てられ、例えば、ビット０、１、２、３、４、５、６、７、および８は、１秒当たりに８，０００、１６，０００、２４，０００、３２，０００、４０，０００、４８，０００、１１，０２５、２２，０５０、および４４，１００サンプル（samples per second, SPS）を割り当てられ、ビット９ないし１５は、将来の使用のために確保されるか、または、希望に応じて、別のレートが使用し、したがって、これらは、現在は、０に設定される。これらのビットの１つのビット値を‘１’に設定することは、特定のサンプルレートが支援されていることを示し、ビットを‘０’に設定することは、サンプルレートが支援されていないことを示す。
【０３３５】
最小サブフレームレートフィールド（２バイト）は、１秒当たりのフレーム内の最小サブフレームレートを特定する。最小サブフレームレートは、ディスプレイ内のある特定のセンサまたはポインティングデバイスを読み出すのに十分なディスプレイ状態更新レートを維持する。
【０３３６】
逆方向リンクにおける、２バイトのＭｉｃサンプルレート能力フィールドは、クライアントデバイス内のマイクロフォンのオーディオサンプルレート能力を示す１組のフラグを含む。ＭＤＤＩのために、クライアントデバイスのマイクロフォン（microphone）は、１秒当たりに、最低で、少なくとも８，０００サンプルのレートを支援するように構成されている。このフィールドのビット位置は、異なるレートに割り当てられ、例えば、ビット０、１、２、３、４、５、６、７、および８は、１秒当たりに、それぞれ８，０００、１６，０００、２４，０００、３２，０００、４０，０００、４８，０００、１１，０２５、２２，０５０、および４４，１００サンプル（samples per second, SPS）を表わすのに使用され、ビット９ないし１５は、将来の使用のために確保されるか、または、希望に応じて、別のレートが使用し、したがって、それらは、現在は、‘０’に設定される。これらのビットの１つのビット値を‘１’に設定することは、特定のサンプルレートが支援されていることを示し、ビットを‘０’に設定することは、サンプルレートが支援されていないことを示す。マイクロフォンが接続されていないときは、Ｍｉｃサンプルレート能力ビットの各々は、ゼロに等しく設定される。
【０３３７】
コンテント保護タイプフィールド（２バイト）は、ディスプレイによって支援されるディジタルコンテント保護タイプを示す１組のフラグを含む。現在、ビット位置０は、ＤＴＣＰが支援されるときを示すのに使用され、ビット位置１はＨＤＣＰが支援されるときを示すのに使用され、ビット位置２ないし１５は、他の保護方式で使用するために確保され、したがって、これらは、現在は、０に設定される。
【０３３８】
Ｇ．ディスプレイ要求および状態パケットについて
逆方向リンク要求フィールド（３バイト）は、ディスプレイが、逆方向リンクにおいて、情報をホストへ送るために、次のサブフレームにおいて必要とするバイト数を特定する。
【０３３９】
ＣＲＣ誤りカウントフィールド（１バイト）は、媒体フレームの最初から、いくつのＣＲＣの誤りが現れたかを示す。ＣＲＣのカウントは、サブフレームヘッダパケットが、ゼロのサブフレームカウントと共に送られるときにリセットされる。ＣＲＣの誤りの実際の数が２５５を越えるとき、この値は、通常は、２５５で飽和する。
【０３４０】
能力変更フィールドは、１バイトを使用し、ディスプレイの能力における変更を示す。これは、ユーザが、マイクロフォン、キーボード、またはディスプレイのような周辺デバイスを接続するとき、または何らかの他の理由のために起こり得る。ビット[７：０]が０に等しいときは、最後のディスプレイ能力パケットが送られてから、能力は変更されていない。しかしながら、ビット[７：０]が、１ないし２５５に等しいときは、能力は変更されている。ディスプレイ能力パケットは、新しいディスプレイの特性を判断するために調べられる。
【０３４１】
Ｈ．ビットブロック転送パケットについて
ウインドウの左上座標のＸ値およびＹ値のフィールドは、２バイトを使用し、各々は、移動されるウインドウの左上角部の座標のＸ値およびＹ値を特定する。ウインドウの幅および高さのフィールドは、２バイトを使用し、各々は、移動されるウインドウの幅および高さを特定する。ウインドウのＸ移動およびＹ移動のフィールドは、２バイトを使用し、各々は、ウインドウが水平方向および垂直方向にそれぞれ移動される画素の数を特定する。通常、これらの座標は、Ｘの正の値がウインドウを右へ移動し、負の値が左へ移動し、一方で、Ｙの正の値がウインドウを下へ移動し、負の値が上へ移動するように構成されている。
【０３４２】
Ｉ．ビットマップ区域充填パケットについて
ウインドウの左上座標のＸ値およびＹ値のフィールドは、２バイトを使用し、各々は、充填されるウインドウの左上角部の座標のＸ値およびＹ値を特定する。ウインドウの幅および高さのフィールド（それぞれ、２バイト）は、充填されるウインドウの幅および高さを特定する。ビデオデータフォーマット記述子フィールド（２バイト）は、画素区域充填値のフォーマットを特定する。フォーマットは、ビデオストリームパケット内の同じフィールドと同じである。画素区域充填値フィールド（４バイト）は、既に記載されたフィールドによって特定されるウインドウ内へ充填される画素の値を含む。この画素のフォーマットは、ビデオデータフォーマット記述子フィールドにおいて特定されている。
【０３４３】
Ｊ．ビットマップパターン充填パケットについて
ウインドウの左上座標のＸ値およびＹ値のフィールドは、２バイトを使用し、各々は、充填されるウインドウの左上角部の座標のＸ値およびＹ値を特定する。ウインドウの幅および高さのフィールド（それぞれ、２バイト）は、充填されるウインドウの幅および高さを特定する。パターンの幅およびパターンの高さのフィールド（それぞれ、２バイト）は、充填パターンの幅および高さをそれぞれ特定する。２バイトのビデオデータフォーマット記述子フィールドは、画素区域充填値のフォーマットを特定する。図１１は、ビデオデータフォーマット記述子がどのように符号化されるかを示している。このフォーマットは、ビデオストリームパケット内の同じフィールドと同じである。
【０３４４】
パラメータＣＲＣフィールド（２バイト）は、パケット長からビデオフォーマット記述子への全バイトのＣＲＣを含む。このＣＲＣが検査に不合格すると、全パケットが捨てられる。パターン画素データフィールドは、ビデオデータフォーマット記述子によって特定されたフォーマットにおける充填パターンを特定する生のビデオ情報を含む。データはバイトにパックされ、各行の第１の画素は、バイトを整列させられなければならない。充填パターンデータは、一度に１行ずつ伝送される。パターン画素データＣＲＣフィールド（２バイト）は、パターン画素データのみのＣＲＣを含む。このＣＲＣが検査に不合格すると、パターン画素データは、それでも使用されることができるが、ＣＲＣの誤りカウントはインクリメントされる。
【０３４５】
Ｋ．通信リンクデータチャネルパケットについて
パラメータのＣＲＣフィールド（２バイト）は、パケット長からパケットタイプへの全バイトの１６ビットのＣＲＣを含む。このＣＲＣが検査に不合格すると、全パケットが捨てられる。
【０３４６】
通信リンクデータフィールドは、通信チャネルからの生のデータを含む。このデータは、単に、ディスプレイ内のコンピューティングデバイスへ送られる。
【０３４７】
通信リンクデータＣＲＣフィールド（２バイト）は、通信リンクデータのみの１６ビットのＣＲＣを含む。このＣＲＣが検査に不合格すると、通信リンクデータは、それでも使用されるか、または有効であるが、ＣＲＣの誤りカウントはインクメントされる。
【０３４８】
Ｌ．インターフェイスタイプハンドオフ要求パケットについて
インターフェイスタイプフィールド（１バイト）は、使用する新しいインターフェイスタイプを特定する。このフィールドの値は、次のやり方でインターフェイスのタイプを特定する。ビット７の値が‘０’に等しいときは、タイプハンドオフ要求は、順方向リンクであり、それが‘１’に等しいときは、タイプハンドオフ要求は、逆方向リンクである。ビット６ないし３は、将来の使用のために確保され、通常は、ゼロに設定される。ビット２ないし０は、使用されるインターフェイスタイプを定めるのに使用され、１の値はタイプＩのモードへのハンドオフを意味し、２の値はタイプＩＩのモードへのハンドオフを意味し、３の値はタイプＩＩＩのモードへのハンドオフを意味し、４の値はタイプＩＶのモードへのハンドオフを意味する。‘０’および５ないし７の値は、将来の別のモードまたはモードの組合せを示すために確保される。
【０３４９】
Ｍ．インターフェイスタイプ肯定応答パケットについて
インターフェイスタイプフィールド（１バイト）は、使用する新しいインターフェイスタイプを確認する値をもつ。このフィールド内の値は、次のやり方でインターフェイスタイプを特定する。ビット７が‘０’に等しいときは、タイプハンドオフ要求は、順方向リンクであり、その代りに、それが‘１’に等しいときは、タイプハンドオフ要求は、逆方向リンクである。ビット位置６ないし３は、現在は、希望に応じて、他のハンドオフタイプを示すのに使用するために確保され、通常は、ゼロに設定される。しかしながら、ビット位置２ないし０は、使用されるインターフェイスタイプを定めるのに使用され、‘０’の値は、否定応答、すなわち、要求されたハンドオフを実行できないことを示し、‘１’、‘２’、‘３’、および‘４’の値は、タイプＩ、タイプＩＩ、タイプＩＩＩ、およびタイプＩＶのモードへのハンドオフをそれぞれ示す。５ないし７の値は、希望に応じて、別のモードを示すのに使用するために確保される。
【０３５０】
Ｎ．タイプハンドオフ実行パケットについて
１バイトのインターフェイスタイプフィールドは、使用する新しいインターフェイスタイプを示す。このフィールド内に存在する値は、最初にビット７の値を使用して、タイプのハンドオフが順方向リンクであるか、または逆方向リンクであるかを判断することによって、インターフェイスタイプを特定する。‘０’の値は、タイプハンドオフ要求が順方向リンクであり、‘１’の値は、逆方向リンクであることを示す。ビット６ないし３は、将来の使用のために確保され、したがって、通常は、ゼロの値に設定される。しかしながら、ビット２ないし０は、使用されるインターフェイスタイプを定めるのに使用され、値１、２、３、および４は、タイプＩ、タイプＩＩ、タイプＩＩＩ、およびタイプＩＶのモードへのハンドオフの使用をそれぞれ特定する。これらのビットのための値０および５ないし７の使用は、将来の使用のために確保される。
【０３５１】
Ｏ．順方向オーディオチャネルイネーブルパケットについて
オーディオチャネルイネーブルマスクフィールド（１バイト）は、何れのオーディオチャネルがクライアントにおいてイネーブルされるかを示すフラグのグループを含む。１に設定されたビットは、対応するチャネルをイネーブルし、ゼロに設定されたビットは、対応するチャネルをディスエーブルし、ビット０ないし５は、左前、右前、左後、右後、前中央、およびサブウーファのチャネルを扱うチャネル０ないし５をそれぞれ指定する。ビット６および７は、将来の使用のために確保され、しばらくの間は、通常は、ゼロに等しく設定される。
【０３５２】
Ｐ．逆方向オーディオサンプルレートパケットについて
オーディオサンプルレートフィールド（１バイト）は、ディジタルオーディオサンプルレートを特定する。このフィールドの値は、異なるレートに割り当てられ、０、１、２、３、４、５、６、７、および８の値は、１秒当たりに、それぞれ８，０００、１６，０００、２４，０００、３２，０００、４０，０００、４８，０００、１１，０２５、２２，０５０、および４４，１００サンプル（samples per second, SPS）を示すのに使用され、９ないし２５４の値は、希望に応じて、別のレートに使用するために確保され、したがって、それらは、現在は、‘０’に設定される。２５５の値は、逆方向リンクオーディオストリームをディスエーブルするのに使用される。
【０３５３】
サンプルフォーマットフィールド（１バイト）は、ディジタルオーディオサンプルのフォーマットを特定する。ビット[１：０]が‘０’に等しいときは、ディジタルオーディオサンプルは、線形フォーマットであり、それらが１に等しいときは、ディジタルオーディオサンプルはμ法のフォーマットであり、それらが２に等しいときは、ディジタルオーディオサンプルはＡ法のフォーマットである。ビット[７：２]は、希望に応じて、オーディオフォーマットを示す別の使用のために確保され、通常は、ゼロに等しく設定される。
【０３５４】
Ｑ．ディジタルコンテント保護オーバーヘッドパケットについて
コンテント保護タイプフィールド（１バイト）は、使用されるディジタルコンテント保護方法を特定する。‘０’の値は、ディジタル伝送コンテント保護（Digital Transmission Content Protection, DTCP）を示し、一方で、１の値は、高バンド幅ディジタルコンテント保護システム（High-bandwidth Digital Content Protection System, HDCP）を示す。２ないし２５５の値の範囲は、現在は、特定されていないが、希望に応じて、別の保護方式で使用するために確保される。コンテント保護オーバーヘッドメッセージフィールドは、ホストとクライアントとの間で送られるコンテント保護メッセージを含む可変長フィールドである。
【０３５５】
Ｒ．透明色イネーブルパケットについて
透明色イネーブルフィールド（１バイト）は、透明色モードがイネーブルされるか、またはディスエーブルされるときを特定する。ビット０が０に等しいときは、透明色モードはディスエーブルされ、それが１に等しいときは、透明色モードはイネーブルされ、透明色は、次の２つのパラメータによって特定される。このバイトのビット１ないし７は、将来の使用のために確保され、通常は、ゼロに設定される。
【０３５６】
ビデオデータフォーマット記述子フィールド（２バイト）は、画素区域充填値のフォーマットを特定する。図１１は、ビデオデータフォーマット記述子がどのように符号化されるかを示している。フォーマットは、ビデオストリームパケット内の同じフィールドとほぼ同じものである。
【０３５７】
画素区域充填値フィールドは、４バイトを使用し、上述で特定されたウインドウ内へ画素値を充填するために割り振られる。この画素のフォーマットは、ビデオデータフォーマット記述子フィールドに特定されている。
【０３５８】
Ｓ．往復遅延測定パケットについて
１つの実施形態では、パラメータＣＲＣフィールド（２バイト）は、パケット長からパケットタイプへの全バイトの１６ビットのＣＲＣを含む。このＣＲＣが検査に不合格すると、全パケットが捨てられる。
【０３５９】
全てゼロのフィールド（１バイト）は、ゼロを含み、全ＭＤＤＩ Ｄａｔａ信号が、第１の保護時間期間の間の、ラインドライバをディスエーブルする前に、ゼロの状態であることを保証する。
【０３６０】
保護時間１のフィールド（８バイト）は、クライアント（ディスプレイ）内のラインドライバがイネーブルされる前に、ホスト内のＭＤＤＩ Ｄａｔａラインドライバがディスエーブルするのを可能にするために使用される。ホストは、保護時間１のビット０中に、そのＭＤＤＩ Ｄａｔａラインドライバをディスエーブルし、ディスプレイは、保護時間１の最後のビットの直後に、そのラインドライバをイネーブルする。
【０３６１】
測定期間フィールドは、５１２バイトのウインドウであり、ディスプレイが、順方向リンク上で使用されるデータレートの２分の１で、０ｘｆｆ、０ｘｆｆ、０ｘ００で応答するのを可能にするのに使用される。このレートは、１の逆方向リンクレートの除数に対応する。ディスプレイは、測定期間の始めに、直ちに、この応答を戻す。この応答は、ホストにおける測定期間の第１のビットが始まった後のリンクの正確な往復遅延で、ホストにおいて受信される。ディスプレイのＭＤＤＩ Ｄａｔａラインドライバは、ディスプレイからの０ｘｆｆ、０ｘｆｆ、０ｘ００の応答の直前および直後にディスエーブルされる。
【０３６２】
保護時間２のフィールド（８バイト）の値は、ホストのラインドライバがイネーブルされる前に、クライアントのＭＤＤＩ Ｄａｔａラインドライバがディスエーブルすることを可能にする。保護時間２は、常に存在するが、往復遅延が、測定期間において測定されることができる最大量であるときのみ必要とされる。クライアントは、保護時間２のビット０の間、そのラインドライバをディスエーブルし、ホストは、保護時間２の最後のビットの直後に、そのラインドライバをイネーブルする。
【０３６３】
ドライバ再イネーブルフィールド（１バイト）は、ゼロに等しく設定され、全てのＭＤＤＩ Ｄａｔａ信号は、次のパケットのパケット長フィールドの前に再びイネーブルされる。
【０３６４】
Ｔ．順方向リンクスキュー較正パケットについて
１つの実施形態では、パラメータＣＲＣフィールド（２バイト）は、パケット長からパケットタイプまでの全バイトの１６ビットのＣＲＣを含む。このＣＲＣが検査に不合格すると、全パケットが捨てられる。
【０３６５】
較正データ系列フィールドは、各データ期間においてＭＤＤＩ Ｄａｔａ信号を切換える５１２バイトのデータ系列を含む。較正データ系列の処理中に、ＭＤＤＩホスト制御装置は、全てのＭＤＤＩ Ｄａｔａ信号をストローブ信号に等しく設定する。較正データ系列フィールドは、クライアントのディスプレイによって受信されている間、ディスプレイクロック回復回路は、データクロックを回復するのに、ＭＤＤＩ Ｓｔｂ ＸまたはＭＤＤＩ Ｄａｔａ０ではなく、ＭＤＤＩ Ｓｔｂのみを使用すべきである。較正データ系列フィールドの始めのＭＤＤＩ Ｓｔｂ信号の正確な位相に依存して、較正データ系列は、通常、このパケットが送られるときに使用されているインターフェイスタイプに基づいて、次に示すものの１つである。
【０３６６】
タイプＩ−0xaa,0xaa…または0x55,0x55…
タイプＩＩ−0xcc,0xcc…または0x33,0x33…
タイプＩＩＩ−0xf0,0xf0…または0x0f,0x0f…
タイプＩＶ−0xff,0x00,0xff,0x00…または0x00,0xff,0x00,0xff…
タイプＩおよびタイプＩＩのインターフェイスの両者における予想されるＭＤＤＩ ＤａｔａおよびＭＤＤＩ Ｓｔｂの波形の例は、図６２Ａおよび６２Ｂにそれぞれ示されている。
【０３６７】
ＸＶＩＩ．結論
本発明の種々の実施形態が上述で記載されてきたが、それらは、制限によってではなく、例のみによって提示されてきたことが理解されるべきである。したがって、本発明の広さおよび範囲は、上述の例示的な実施形態の何れによっても制限されるべきではないが、特許請求項およびそれらに相当するもののみにしたがって定められるべきである。
【符号の説明】
【０３６８】
102・・・無線電話またはＰＤＡデバイス、104,106・・・ディスプレイデバイス、108・・・オーディオ再生システム、110,4206・・・通信リンク、206,406,506・・・双方向通信チャネル、3602・・・ＣＲＣレジスタ、3604,3606・・・マルチプレクサ、3608・・・ＮＡＮＤゲート、3610・・・ＮＯＲゲート、3612,5736・・・排他的ＯＲ（ＸＯＲ）ゲート、3614・・・ＡＮＤゲート、4002・・・データ信号、4004・・・ストローブ信号、4006・・・クロック信号、4100・・・送信部、4102・・・中間信号経路、4104,4106,4128,4130,5704,5706,5728,5730,5928,5830・・・フリップフロップ、4108,4110,4210,4212,4214,5708,5710,5722,5724・・・ドライバ、4122,4124・・・差動ライン受信機、4120・・・受信部、4112,4126・・・論理素子、4216,4218・・・抵抗、4220・・・電圧源、5302・・・第１の領域、5304・・・第２の領域、5306・・・第３の領域、5702・・・ケーブル、6600・・・ＣＲＣ上書き機構または装置。
【図１Ａ】
2011176810.tif 000026
【図１Ｂ】
2011176810.tif 000027
【図２】
2011176810.tif 000028
【図３】
2011176810.tif 000029
【図４】
2011176810.tif 000030
【図５】
2011176810.tif 000031
【図６】
2011176810.tif 000032
【図７】
2011176810.tif 000033
【図８】
2011176810.tif 000034
【図９】
2011176810.tif 000035
【図１０】
2011176810.tif 000036
【図１１】
2011176810.tif 000037
【図１２】
2011176810.tif 000038
【図１３】
2011176810.tif 000039
【図１４】
2011176810.tif 000040
【図１５】
2011176810.tif 000041
【図１６】
2011176810.tif 000042
【図１７】
2011176810.tif 000043
【図１８】
2011176810.tif 000044
【図１９】
2011176810.tif 000045
【図２０】
2011176810.tif 000046
【図２１】
2011176810.tif 000047
【図２２】
2011176810.tif 000048
【図２３】
2011176810.tif 000049
【図２４】
2011176810.tif 000050
【図２５】
2011176810.tif 000051
【図２６】
2011176810.tif 000052
【図２７】
2011176810.tif 000053
【図２８】
2011176810.tif 000054
【図２９】
2011176810.tif 000055
【図３０】
2011176810.tif 000056
【図３１】
2011176810.tif 000057
【図３２】
2011176810.tif 000058
【図３３】
2011176810.tif 000059
【図３４】
2011176810.tif 000060
【図３５】
2011176810.tif 000061
【図３６】
2011176810.tif 000062
【図３７Ａ】
2011176810.tif 000063
【図３７Ｂ】
2011176810.tif 000064
【図３８】
2011176810.tif 000065
【図３９】
2011176810.tif 000066
【図４０】
2011176810.tif 000067
【図４１】
2011176810.tif 000068
【図４２】
2011176810.tif 000069
【図４３】
2011176810.tif 000070
【図４４】
2011176810.tif 000071
【図４５】
2011176810.tif 000072
【図４６】
2011176810.tif 000073
【図４７】
2011176810.tif 000074
【図４８】
2011176810.tif 000075
【図４９】
2011176810.tif 000076
【図５０】
2011176810.tif 000077
【図５１】
2011176810.tif 000078
【図５２】
2011176810.tif 000079
【図５３】
2011176810.tif 000080
【図５４Ａ】
2011176810.tif 000081
【図５４Ｂ】
2011176810.tif 000082
【図５５】
2011176810.tif 000083
【図５６】
2011176810.tif 000084
【図５７】
2011176810.tif 000085
【図５８】
2011176810.tif 000086
【図５９】
2011176810.tif 000087
【図６０Ａ】
2011176810.tif 000088
【図６０Ｂ】
2011176810.tif 000089
【図６０Ｃ】
2011176810.tif 000090
【図６１】
2011176810.tif 000091
【図６２Ａ】
2011176810.tif 000092
【図６２Ｂ】
2011176810.tif 000093
【図６３】
2011176810.tif 000094
【図６４】
2011176810.tif 000095
【図６５】
2011176810.tif 000096
【図６６】
2011176810.tif 000097
【図６７Ａ】
2011176810.tif 000098
【図６７Ｂ】
2011176810.tif 000099
【図６８Ａ】
2011176810.tif 000100
【図６８Ｂ】
2011176810.tif 000101
【図６８Ｃ】
2011176810.tif 000102
【手続補正書】
【提出日】平成23年3月9日(2011.3.9)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ユーザに提示するために、ディジタルデータを高レートでホストデバイスとクライアントデバイスとの間で通信経路によって転送する方法であって、
複数の予め定義されたパケット構造の１つまたは複数を生成し、それらを一緒にリンクして、予め定義された通信プロトコルを形成することと、
前記通信プロトコルを使用して、ディジタル制御および提示データの予め選択された組を前記ホストと前記クライアントデバイスとの間で前記通信経路によって通信することと、
前記ホストデバイス内に存在する少なくとも１つのホストリンク制御装置を前記通信経路によって前記クライアントデバイスに結合することであって、ホストリンク制御装置が、前記通信プロトコルを形成しているパケットを生成、送信、受信するように、およびディジタル提示データを１つまたは複数のタイプのデータパケットへ形成するように構成されていることと、
前記リンク制御装置を使用して、データをパケットの形式で前記通信経路によって転送することと、
前記ホストによって、少なくとも１５０クロックサイクルの間、データラインをハイ状態に駆動し、データラインがゼロであるかのように、ストローブ信号を伝送し始めることによって、通信リンクを起動することと、
前記ホストが１５０クロックサイクルの間データラインをハイに駆動した後で、前記ホストによって５０クロックサイクルの間データラインをローに駆動し、一方でストローブ信号を伝送し続けることと
を含む方法。
【請求項２】
前記ホストによって第１のサブフレームヘッダパケットを伝送し始めることをさらに含む請求項1記載の方法。
【請求項３】
前記クライアントによって、ハイであるデータラインの少なくとも１５０連続クロックサイクルと、その後のローであるデータラインの少なくとも５０連続クロックサイクルをカウントすることをさらに含む請求項1記載の方法。
【請求項４】
前記クライアントによって第１のサブフレームのユニークワードをサーチすることをさらに含む請求項3記載の方法。
【請求項５】
クライアントが、ハイであるデータの７０連続クロックサイクルをカウントした後で、前記クライアントによって、データラインをハイに駆動することを止めることをさらに含む請求項3記載の方法。
【請求項６】
前記クライアントによって、ハイであるデータラインの別の８０連続クロックサイクルをカウントして、ハイであるデータラインの１５０クロックサイクルに到達し、ローであるデータラインの５０クロックサイクルを探し、ユニークワードを探すことをさらに含む請求項5記載の方法。
【請求項７】
ユーザに提示するために、ディジタルデータを高レートでホストデバイスとクライアントデバイスとの間で通信経路によって転送する方法であって、
各々が少なくとも１つのＣＲＣフィールドを含む複数の予め定義されたパケット構造の１つまたは複数を生成し、それらを一緒にリンクして、予め定義された通信プロトコルを形成することと、
前記通信プロトコルを使用して、ディジタル制御および提示データの予め選択された組を前記ホストと前記クライアントとの間で前記通信経路によって通信することと、
前記ホストデバイス内に存在する少なくとも１つのホストリンク制御装置を前記通信経路によって前記クライアントデバイスに結合することであって、ホストリンク制御装置が、前記通信プロトコルを形成しているパケットを生成、送信、受信するように、およびディジタル提示データを１つまたは複数のタイプのデータパケットへ形成するように構成されていることと、
前記リンク制御装置を使用して、データをパケットの形式で前記通信経路によって転送することと、
通信リンクについての誤りの存在を検出することと、
前記誤りに対応する所定の誤りコードを選択することと、
前記コードでＣＲＣ値を上書きすることと、
転送される連続するパケット内の前記ＣＲＣ値を、前記誤りが訂正されるまで上書きすることと
を含む方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０３６７
【補正方法】変更
【補正の内容】
【０３６７】
ＸＶＩＩ．結論
本発明の種々の実施形態が上述で記載されてきたが、それらは、制限によってではなく、例のみによって提示されてきたことが理解されるべきである。したがって、本発明の広さおよび範囲は、上述の例示的な実施形態の何れによっても制限されるべきではないが、特許請求項およびそれらに相当するもののみにしたがって定められるべきである。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
［1］  ディジタル提示データを高レートでホストデバイスとクライアントデバイスとの間で通信経路によって転送するディジタルデータインターフェイスであって、
ディジタル制御および提示データの予め選択された組をホストとクライアントとの間で前記通信経路によって通信するための通信プロトコルを形成するために一緒にリンクされた複数のパケット構造と、
前記通信経路によって前記クライアントに結合された前記ホストデバイス内に存在していて、前記通信プロトコルを形成しているパケットを生成、送信、受信するように、およびディジタル提示データをデータパケットの１つ以上のタイプへ形成するように構成された少なくとも１つのリンク制御装置とを含むディジタルデータインターフェイス。
［2］  前記ホストとクライアントとの間で通信され、予め定義された固定長をもち、異なる可変長をもつ所定数の前記パケットをもつ媒体フレーム内で一緒にグループ化された前記パケットをさらに含む［1］記載のインターフェイス。
［3］  前記ホストからのパケットの転送の始めに置かれたサブフレームヘッダパケットをさらに含む［1］記載のインターフェイス。
［4］  前記リンク制御装置が、ホストリンク制御装置であり、前記通信経路によって前記ホストに結合された前記クライアントデバイス内に存在していて、前記通信プロトコルを形成しているパケットを生成、送信、受信するように、およびディジタル提示データをデータパケットの１つ以上のタイプへ形成するように構成された少なくとも１つのクライアントリンク制御装置をさらに含む［1］記載のインターフェイス。
［5］  クライアントのユーザへ提示するために、順方向リンクによって前記ホストから前記クライアントへデータを転送するための、ビデオタイプデータのための１つ以上のビデオストリームパケットと、オーディオタイプデータのためのオーディオストリームパケットとをさらに含む［1］記載のインターフェイス。
［6］  各転送モードが、所与の時間期間において異なる最大数のビットのデータを並列に転送することを可能にし、各転送モードが、前記ホストおよびクライアントのリンクドライバ間のネゴシエーションによって選択可能である複数の転送モードをさらに含み、
前記転送モードが、データ転送中に、前記モード間で動的に調整可能である［2］記載のインターフェイス。
［7］  カラーマップ、ビットブロック転送、ビットマップ区域充填、ビットマップパターン充填、および透明色イネーブルタイプパケットのグループから選択されたビデオ情報を転送するのに使用可能な複数のパケットをさらに含む［1］記載のインターフェイス。
［8］  データをもたない順方向リンク伝送の期間を占有するための、前記ホストによって生成されるフィラータイプパケットをさらに含む［1］記載のインターフェイス。
［9］  インターフェイス−ユーザ定義データを転送するユーザ定義ストリームタイプパケットをさらに含む［1］記載のインターフェイス。
［10］  前記ホストによって前記クライアントへ伝送し、前記通信経路による何れか方向におけるデータ転送も終了するためのリンク遮断タイプパケットをさらに含む［1］記載のインターフェイス。
［11］  前記クライアントが前記ホストを休止状態から起動する手段をさらに含む［1］記載のインターフェイス。
［12］  ユーザに提示するために、ディジタル提示データを高レートでホストデバイスとクライアントデバイスとの間で通信経路によって転送する方法であって、
複数の予め定義されたパケット構造の１つ以上を生成し、それらを一緒にリンクして、予め定義された通信プロトコルを生成することと、
前記通信プロトコルを使用して、ディジタル制御および提示データの予め選択された組を前記ホストと前記クライアントのデバイス間で前記通信経路によって通信することと、
前記ホストデバイス内に存在する少なくとも１つのホストリンク制御装置を前記通信経路によって前記クライアントデバイスに結合することであって、ホストリンク制御装置が前記通信プロトコルを形成しているパケットを生成、送信、受信するように、およびディジタル提示データをデータパケットの１つ以上のタイプへ形成するように構成されていることと、
前記リンク制御装置を使用して、データをパケットの形で前記通信経路によって転送することとを含む方法。
［13］  前記ホストとクライアントとの間で通信するための前記媒体フレーム内で前記パケットを一緒にグループ化することをさらに含み、媒体フレームが、予め定義された固定長をもち、異なる可変長をもつ所定数の前記パケットをもつ［12］記載の方法。
［14］  前記ホストからのパケットの転送をサブフレームヘッダタイプパケットで開始することをさらに含む［12］記載の方法。
［15］  情報を前記ホストとクライアントとの間で双方向で前記通信リンクによって転送することをさらに含む［12］記載の方法。
［16］  前記通信経路によって前記ホストデバイスに結合された前記クライアントデバイス内に存在していて、前記通信プロトコルを形成しているパケットを生成、送信、受信するように、およびディジタル提示データをデータパケットの１つ以上のタイプへ形成するように構成された少なくとも１つのリンク制御装置をさらに含む［12］記載の方法。
［17］  前記ホストリンク制御装置が、１つ以上の差動ラインドライバを含み、前記クライアントリンク制御装置が、前記通信経路に結合された１つ以上の差動ライン受信機を含む［16］記載の方法。
［18］  ホストリンク制御装置によってクライアントからディスプレイ能力情報を要求して、前記クライアントが前記インターフェイスによって何れのタイプのデータおよびデータレートに適応できるかを判断することをさらに含む［12］記載の方法。
［19］  前記リンク制御装置の各々によって、ＵＳＢデータインターフェイスを、前記通信経路の一部として動作することをさらに含む［12］記載の方法。
［20］  前記パケットが、それぞれ、パケット長フィールド、１つ以上のパケットデータフィールド、および巡回冗長検査フィールドを含む［12］記載の方法。
［21］  前記ホストとクライアントのリンクドライバ間で各方向における複数の転送モードの使用をネゴシエートし、各転送モードが所与の時間期間において異なる最大数のビットのデータを並列に転送することを可能にすることと、
データ転送中に前記転送モード間で動的に調節することとをさらに含む［13］記載の方法。
［22］  複数のパケットの１つ以上を使用して、カラーマップ、ビットブロック転送、ビットマップ区域充填、ビットマップパターン充填、および透明色イネーブルタイプパケットのグループから選択されたビデオ情報を転送することをさらに含む［12］記載の方法。
［23］  前記ホストによってフィラータイプパケットを生成し、データをもたない順方向リンク伝送の期間を占有することをさらに含む［12］記載の方法。
［24］  前記ホストによって前記クライアントへ伝送するリンク遮断タイプパケットを使用して、前記通信経路による何れの方向におけるデータ転送も終了することをさらに含む［12］記載の方法。
［25］  前記クライアントとの通信によって休止状態から前記ホストを起動することをさらに含む［12］記載の方法。
［26］  ユーザに提示するために、ディジタル提示データを高レートでホストデバイスとクライアントデバイスとの間で通信経路によって転送する装置であって、
１つ以上の複数の予め定義されたパケット構造を生成し、それらを一緒にリンクして、予め定義された通信プロトコルを生成するため、および前記通信プロトコルを使用して、ディジタル制御および提示データの予め選択された組を前記ホストと前記クライアントのデバイスの間で前記通信経路によって通信するための、前記ホストデバイス内に配置された少なくとも１つのホストリンク制御装置と、
前記クライアントデバイス内に配置され、前記通信経路によって前記ホストリンク制御装置に結合された少なくとも１つのクライアント制御装置とを含み、
各リンク制御装置が、前記通信プロトコルを形成しているパケットを生成、送信、受信するように、およびディジタル提示データをデータパケットの１つ以上のタイプへ形成するように構成されている装置。
［27］  前記ホスト制御装置が状態機械を含む［26］記載の装置。
［28］  前記ホスト制御装置が汎用信号プロセッサを含む［26］記載の装置。
［29］  前記ホストからパケットの転送の始めにサブフレームヘッダタイプパケットをさらに含む［26］記載の装置。
［30］  前記リンク制御装置が、情報を前記ホストとクライアントのデバイス間で双方向で前記通信リンクによって転送するように構成されている［26］記載の装置。
［31］  前記ホスト制御装置が、１つ以上の差動ラインドライバを含み、前記クライアント受信機が、前記通信経路に結合された１つ以上の差動ライン受信機を含む［30］記載の装置。
［32］  クライアントのユーザへ提示するために前記ホストから前記クライアントへデータを転送するときに、ビデオタイプデータのためのビデオストリームタイプパケットと、オーディオタイプのためのオーディオストリームタイプパケットとをさらに含む［26］記載の装置。
［33］  前記クライアントから前記ホストへデータを転送するための１つ以上の逆方向リンクカプセル化タイプパケットをさらに含む［26］記載の装置。
［34］  表示または提示能力をクライアントリンク制御装置から前記ホストリンク制御装置へ通信するための少なくとも１つのディスプレイ能力タイプパケットをさらに含む［33］記載の装置。
［35］  前記パケットが、それぞれ、パケット長フィールド、１つ以上のパケットデータフィールド、および巡回冗長検査フィールドを含む［26］記載の装置。
［36］  前記ホストおよびクライアントリンク制御装置が、各方向において複数の転送モードの１つを使用するように構成されていて、各転送モードが、所与の時間期間において異なる最大数のビットのデータを並列に転送することを可能にし、データ転送中に前記転送モード間で動的に調整することができる［26］記載の装置。
［37］  カラーマップ、ビットブロック転送、ビットマップ区域充填、ビットマップパターン充填、および透明色イネーブルタイプパケットのグループから選択されたビデオ情報を転送する複数のパケットの１つ以上をさらに含む［26］記載の装置。
［38］  データをもたない順方向リンク伝送期間を占有するために、前記ホストによって転送するためのフィラータイプパケットをさらに含む［26］記載の装置。
［39］  前記ホスト制御装置が、前記クライアントへリンク遮断タイプパケットを伝送して、前記通信経路による何れの方向におけるデータ転送も終了するように構成されている［26］記載の装置。
［40］  ユーザに提示するために、ディジタルデータを高レートでホストデバイスとクライアントデバイスとの間で通信経路によって転送する電子システムにおいて使用するための、
コンピュータシステム上でアプリケーションプログラムを実行させるために、コンピュータ読み出し可能プログラムコード手段を自分の中に組込んだコンピュータ使用可能媒体を含むコンピュータプログラムプロダクトであって、前記コンピュータ読み出し可能プログラムコード手段が、
コンピュータシステムに、複数の予め定義されたパケット構造の１つ以上を生成させ、それらを一緒にリンクして、予め定義された通信プロトコルを形成させるコンピュータ読み出し可能な第１のプログラムコード手段と、
コンピュータシステムに、前記通信プロトコルを使用して、ディジタル制御および提示データの予め選択された組を前記ホストと前記クライアントのデバイスとの間で前記通信経路によって通信させるコンピュータ読み出し可能な第２のプログラムコード手段と、
コンピュータシステムに、前記通信経路によって、前記ホストデバイス内に配置された少なくとも１つのホストリンク制御装置を、前記クライアントデバイス内に配置された少なくとも１つのクライアント制御装置に結合させるコンピュータ読み出し可能な第３のプログラムコード手段であって、リンク制御装置が、前記通信プロトコルを形成しているパケットを生成、送信、受信するように、およびディジタル提示データをデータパケットの１つ以上のタイプへ形成するように構成されているコンピュータ読み出し可能な第３のプログラムコード手段と、
コンピュータシステムに、前記リンク制御装置を使用して、データをパケットの形で前記通信経路によって転送させるコンピュータ読み出し可能な第４のプログラムコード手段とを含むコンピュータプログラムプロダクト。
［41］  ユーザに提示するために、ディジタルデータを高レートでホストデバイスとクライアントデバイスとの間で通信経路によって転送する装置であって、
複数の予め定義されたパケット構造の１つ以上を生成し、それらを一緒にリンクして、予め定義された通信プロトコルを形成する手段と、
前記通信プロトコルを使用して、ディジタル制御および提示データの予め選択された組を前記ホストと前記クライアントのデバイス間で前記通信経路によって通信する手段と、
前記ホストおよびクライアントの各々に１つずつ、少なくとも２つのリンク制御装置を前記通信経路によって一緒に結合する手段であって、各リンク制御装置が、前記通信プロトコルを形成しているパケットを生成、送信、受信するように、およびディジタル提示データをデータパケットの１つ以上のタイプへ形成するように構成されている手段と、
前記リンク制御装置を使用して、データをパケットの形で前記通信経路によって転送する手段とを含む装置。
［42］  前記ホストからのパケットの転送をサブフレームヘッダタイプパケットで開始する手段をさらに含む［41］記載の装置。
［43］  情報を前記ホストとクライアントとの間で双方向で前記通信リンクによって転送する手段をさらに含む［41］記載の装置。
［44］  ホストリンク制御装置によってクライアントからディスプレイ能力情報を要求して、前記クライアントが前記インターフェイスによって何れのタイプのデータおよびデータレートに適応できるのかを判断する手段をさらに含む［41］記載の装置。
［45］  少なくとも１つのディスプレイ能力タイプパケットを使用して、表示または提示能力をクライアントリンク制御装置から前記ホストリンク制御装置へ通信する手段をさらに含む［41］記載の装置。
［46］  各方向における複数の転送モードの１つの使用を前記ホストとクライアントのリンクドライバ間でネゴシエートする手段であって、各転送モードが所与の時間期間において異なる最大数のビットのデータを並列に転送することを可能にする手段と、
データ転送中に前記転送モード間で動的に調節する手段とをさらに含む［42］記載の装置。
［47］  複数のパケットの１つ以上を使用して、カラーマップ、ビットブロック転送、ビットマップ区域充填、ビットマップパターン充填、および透明色イネーブルタイプパケットのグループから選択されたビデオ情報を転送することをさらに含む［41］記載の装置。
［48］  ディジタルデータを高レートでホストデバイスとクライアントデバイスとの間で通信経路によって転送する電子システムにおいて使用するためのプロセッサであって：複数の予め定義されたパケット構造の１つ以上を生成し、それらを一緒にリンクして、予め定義された通信プロトコルを形成し；ディジタル提示データをデータパケットの１つ以上のタイプへ形成し；前記通信プロトコルを使用して、ディジタル制御および提示データの予め選択された組を前記ホストと前記クライアントのデバイス間で前記通信経路によって通信し；データをパケットの形で前記通信経路によって転送するように構成されたプロセッサ。
［49］  ディジタルデータを高レートでホストデバイスとクライアントデバイスとの間で通信経路によって転送する電子システムにおいて同期を得るときに使用する状態機械であって、少なくとも１つの非同期フレーム状態の同期状態、少なくとも２つの同期獲得状態の同期状態、および少なくとも３つの同期状態の同期状態をもつように構成された状態機械。
［50］  ディジタルデータを高レートでホストデバイスとクライアントデバイスとの間で通信経路によって転送する電子システムにおいて同期を得るときに使用する状態機械であって、少なくとも１つの同期獲得状態の同期状態と、少なくとも２つの同期状態の同期状態とをもつように構成された状態機械。
［51］  同期獲得状態と第１の同期状態との間をシフトする１つの条件が、通信リンクにおける同期パターンの存在を検出することである［50］記載の状態機械。
［52］  同期獲得状態と第１の同期状態との間をシフトする第２の条件が、フレーム境界においてサブフレームヘッダパケットおよび好適なＣＲＣ値の存在を検出することである［51］記載の状態機械。
［53］  第１の同期状態と同期獲得状態との間をシフトする１つの条件が、サブフレーム境界において非同期パターンまたは不適当なＣＲＣ値の存在を検出することである［50］記載の状態機械。
［54］  第１の同期状態と第２の同期状態との間をシフトする１つの条件が、サブフレーム境界において非同期パターンまたは不適当なＣＲＣ値の存在を検出することである［50］記載の状態機械。
［55］  同期獲得状態と第１の同期状態との間をシフトする１つの条件が、通信リンクにおける同期パターンの存在を検出することと、好適なパケットのＣＲＣ値の存在を検出することである［50］記載の状態機械。
［56］  第１の同期状態と同期獲得状態との間をシフトする条件が、パケット内に不適当なＣＲＣ値の存在を検出することである［50］記載の状態機械。
［57］  ディジタルデータを高レートでホストデバイスとクライアントデバイスとの間で通信経路によって転送する電子システムにおいて同期を得るのに使用するための状態機械であって、状態機械が、少なくとも１つの同期獲得状態の同期状態と、少なくとも２つの同期状態の同期状態とをもつように構成され、第１の同期状態と同期獲得状態との間を直接にシフトする条件が、一連のパケットの何れかに不適当なＣＲＣ値の存在を検出することである状態機械。
［58］  第１の同期状態と同期獲得状態との間を直接にシフトする条件が、ユニークワードが、それが到達すると予測されるときに現れないときを検出することである［57］記載の状態機械。
［59］  前記ホストによって、少なくとも１０クロックサイクルの間、データラインをハイ状態に駆動し、データラインがゼロであるかのように、ストローブ信号を伝送し始めることによって、通信リンクを起動することをさらに含む［26］記載の方法。
［60］  ホストが１５０クロックサイクルの間データラインをハイに駆動した後で、前記ホストによって５０クロックサイクルの間データラインをローに駆動し、一方で、ストローブ信号を伝送し続けることをさらに含む［59］記載の方法。
［61］  前記ホストによって第１のサブフレームヘッダパケットを伝送し始めることをさらに含む［59］記載の方法。
［62］  前記クライアントによって、ハイであるデータラインの少なくとも１５０連続クロックサイクルと、その後のローであるデータラインの少なくとも５０連続クロックサイクルをカウントすることをさらに含む［60］記載の方法。
［63］  前記クライアントによって第１のサブフレームのユニークワードをサーチすることをさらに含む［62］記載の方法。
［64］  クライアントがハイであるデータの７０連続クロックサイクルをカウントした後で、前記クライアントによってデータラインをハイに駆動することを止めることをさらに含む［60］記載の方法。
［65］  前記クライアントによって、ハイであるデータラインの別の８０連続クロックサイクルをカウントして、ハイであるデータラインの１５０クロックサイクルに到達し、ローであるデータラインの５０クロックサイクルを探し、ユニークワードを探すことをさらに含む［64］記載の方法。
［66］  逆方向タイミングパケットの間、立ち上り端と立ち下がり端との両者の上でデータラインをサンプリングすることによって、１が前記ホストによってサンプリングされるまで行われるクロックサイクル数をカウントすることをさらに含む［26］記載の方法。
［67］  ディジタルデータがＣＲＣ値をもつパケットの形でホストデバイスとクライアントデバイスとの間で通信経路によって転送される通信システムにおいて、誤りコードを転送する方法であって、誤りの存在を検出することと、前記誤りに対応する所定の誤りコードを選択することと、ＣＲＣ値を前記コードで上書きすることとを含む方法。
［68］  転送される連続するパケット内の前記ＣＲＣ値を、前記誤りが訂正されるまで上書きすることをさらに含む［67］記載の方法。
［69］  ユーザに提示するために、ディジタルデータを高レートでホストデバイスとクライアントデバイスとの間で通信経路によって転送する方法であって、
各々が少なくとも１つのＣＲＣフィールドを含む複数の予め定義されたパケット構造の１つ以上を生成し、それらを一緒にリンクして、予め定義された通信プロトコルを形成することと、
前記通信プロトコルを使用して、ディジタル制御および提示データの予め選択された組を前記ホストと前記クライアントとの間で前記通信経路によって通信することと、
前記ホストデバイス内に存在する少なくとも１つのホストリンク制御装置を前記通信経路によって前記クライアントデバイスに結合することであって、ホストリンク制御装置が、前記通信プロトコルを形成しているパケットを生成、送信、受信するように、およびディジタル提示データをデータパケットの１つ以上のタイプへ形成するように構成されていることと、
前記リンク制御装置を使用して、データをパケットの形で前記通信経路によって転送することと、
通信リンクにおいて誤りの存在を検出することと、
前記誤りに対応する所定の誤りコードを選択することと、ＣＲＣ値を前記コードで上書きすることとを含む方法。
［70］  転送される連続するパケット内の前記ＣＲＣ値を、前記誤りが訂正されるまで上書きすることをさらに含む［69］記載の方法。
【外国語明細書】
2011176810000001.pdf