JP2005173553A

JP2005173553A - パケット式ストリームトランスポートスケジューラ及びその使用方法

Info

Publication number: JP2005173553A
Application number: JP2004271144A
Authority: JP
Inventors: Osamu Kobayashi; 小林　修
Original assignee: Genesis Microchip Inc
Current assignee: Genesis Microchip Inc
Priority date: 2003-09-18
Filing date: 2004-09-17
Publication date: 2005-06-30
Also published as: US7487273B2; EP1517295A3; TW200520542A; TWI353167B; US20050066085A1; EP1517295A2; CN1602001B; SG110144A1; KR20050028869A; CN1602001A

Abstract

【課題】ラスタスキャン転送プロトコルの効率と、等時性パケット転送プロトコルの柔軟性とを有するデータストリームトランスポートプロトコルを提供。
【解決手段】トランスミッタユニットが接続されたソースデバイスと、レシーバユニットが接続されたシンクデバイスと、トランスミッタユニットにより、ネイティブストリームレートに従ったソースデータストリームを受領し、リンクユニットを経由してトランスミッタユニットとレシーバユニットとを結合し、多数のマルチメディアデータパケットから成るマルチメディアデータパケットストリームを形成、トランスミッタユニットとレシーバユニットとの間のリンクレートに従ってマルチメディアデータパケットストリームを転送するためのトランスポートスケジュールを生成する事により、マルチメディアソースデバイスをマルチメディアシンクデバイスに結合する方法。
【選択図】図１

Description

本発明は、マルチメディアデバイスに関する。特に、本発明は、データパケットストリームスケジューラ及びその使用方法について記載する。

ラスタスキャンビデオトランスポートプロトコルは、当初、１つ又は複数の電子銃を使用し、表示画像を一度に一本のラインで物理的に「ペイント」するという事実を考慮する必要があるブラウン管（ＣＲＴ）に基づくディスプレイシステムでの使用のために開発された。例えば、標準解像度（ＶＧＡ）ビデオ画像は、それぞれ６４０ピクセルで形成される４８０本のアクティブ表示ラインを通常含むアクティブ領域で形成される（即ち、解像度６４０×４８０）。しかしながら、アクティブ領域に加え、表示されないにもかかわらずビデオ信号に含まれるブランキング領域が含まれ、これはブランキング領域が水平及び垂直両方の帰線に必要な時間量を表すためである。例えば、ＶＧＡ画像の各フレーム（即ち、それぞれ４８０ライン×６４０ピクセルである完全な一フレーム）は、水平帰線のために一ライン当たり約１６０ピクセルクロックを必要とし、垂直帰線のために約４５ライン期間に等しい期間を必要とする。これにより（一ピクセルクロック当たり一ピクセルと仮定すると）、ＶＧＡ画像を表示するために必要なビデオデータを転送するために必要なビデオ信号は、８００ピクセルクロック（６４０アクティブピクセルクロック＋１６０ブランキングピクセルクロック）程度にする必要がある。そのため、転送効率（合計データストリーム帯域幅上での表示可能データの帯域幅として定義される）は、８０％程度となる（即ち、６４０／８００）。

更に最近では、ＨＤＴＶ及びその他のハイエンドグラフィック用途に対応するためにＣＲＴの解像度が増加するにしたがって、ラスタスキャンビデオトランスポートプロトコルの効率は、水平帰線を１６０ピクセルクロックまでに制限する（これにより関連するブランキング期間を低減する）ように定めることで、約９０％までに増加している。例えば、ＵＶＧＡ画像（即ち、１６００×１２００）について考えると、転送効率は、水平帰線を１６０ピクセルクロックに維持することで約９０％となる（１６００／（１６００＋１６０））。ラスタスキャンビデオ転送プロトコルは効率的であり（９０％程度）、大きなバッファを必要としないが、しかしながら、基本的に、与えられた通りのデータを表示することのみが可能であるという点において柔軟性がない。

ラスタスキャンビデオプロトコルに加えて、デジタルビデオに基づくシステムの出現が、デジタルビデオトランスポートプロトコルの必要性を形成している。Ｉ．Ｅ．Ｅ．Ｅ．１３９４又はＦｉｒｅＷｉｒｅ^TMと呼ばれるこうしたデジタルビデオトランスポートプロトコルの一つは、均一なビットレートを保証し、（ビデオストリームとオーディオストリームの形態の関連するサウンドトラックとのような）多数のデータストリーム間の同期を維持するために、大きなバッファ（６０Ｋｂ程度）に依存する等時性パケットトランスポートに基づいている。等時性パケット転送プロトコルは（パケットに基づく性質のため）生得的に柔軟だが、大きなバッファという要件は、非常に高いコストを要する可能性がある。

そのため、望ましいものは、ラスタスキャン転送プロトコルの（転送効率とメモリリソース利用率との両方の観点での）効率と、等時性パケット転送プロトコルの柔軟性とを有するデータストリームトランスポートプロトコルである。

トランスミッタユニットが接続されたソースデバイスを提供するステップと、レシーバユニットが接続されたシンクデバイスを提供するステップと、トランスミッタユニットにより、ネイティブストリームレートに従ったソースデータストリームを受領するステップと、リンクユニットを経由しトランスミッタユニットとレシーバユニットとを接続するステップと、多数のマルチメディアデータパケットから成るマルチメディアデータパケットストリームを形成するステップと、トランスミッタユニットとレシーバユニットとの間のリンクレートに従ってマルチメディアデータパケットストリームを転送するためのトランスポートスケジュールを生成し、これにおいてマルチメディアデータパケットが、それぞれ、リンクレートとデータストリームビットレートとに基づいた固定サイズになるステップとにより、マルチメディアソースデバイスをマルチメディアシンクデバイスに結合する方法。

データパケットソースからデータパケットシンクへデータパケット属性を送信するステップと、ソースからシンクへ送信されるべき多数のデータストリームのそれぞれについて、ストリームビットレートをデータリンクビットレートと比較するステップと、この比較に基づいてデータストリームのそれぞれのパケットサイズを固定パケットサイズに設定するステップと、各データパケットの少なくとも一つを組み合わせるステップと、組み合わせたデータパケットをソースからシンクへトランスポートするステップとにより、データリンクを経由してデータソースとデータシンクとの間での多数のデータパケットのトランスポートをスケジュールする方法。

更に別の実施形態においては、データパケットソースからデータパケットシンクへデータパケット属性を送信するコンピュータコードと、ソースからシンクへ送信されるべき多数のデータストリームのそれぞれについて、ストリームビットレートをデータリンクビットレートと比較するコンピュータコードと、この比較に基づいてデータストリームのそれぞれのパケットサイズを固定パケットサイズに設定するコンピュータコードと、各データパケットの少なくとも一つを組み合わせるコンピュータコードと、組み合わせたデータパケットをソースからシンクへトランスポートするコンピュータコードと、これらのコードを格納するコンピュータ読取可能な媒体とを含む、データリンクを経由してデータソースとデータシンクとの間での多数のデータパケットのトランスポートをスケジュールするコンピュータプログラム製品。

次に、本発明の特定の実施形態を詳細に参照し、本発明の例は、添付の図面に例示される。本発明については、特定の実施形態に関連させて説明するが、説明する実施形態に本発明を限定することは意図されないと理解されるであろう。反対に、代替、修正、及び等価物を、付記する請求項によって定義されるような本発明の趣旨及び範囲内に含まれ得るものとして網羅することが意図される。

本発明は、パケットベースのデジタルインタフェースを経由して、ビデオシンク又はレシーバに結合されたビデオソースを有するビデオディスプレイシステムの観点から説明される。ソースデバイスに結合されるトランスミッタユニットは、それぞれが関連ストリーム属性を有する任意の数のパケット化ビデオストリームを受領する。説明するビデオシステムに関して、こうした属性は、ビデオ形式と、色深度と、その他とを含む。レシーバユニットは、データリンク又はメインリンクと、データパケットの伝送前にメインリンクを経由してソースからレシーバへストリーム属性データを転送するために部分的に使用される関連補助リンクとを経由して、ソースに結合される。これにより、パケットヘッダは、データパケットがどのデータストリームに関連するかを最初に特定するために使用され、したがって、ストリームＩＤ又はその他のこのような識別子のみを含むことができる。これにより、パケットオーバヘッドは実質的に低減され、パケットオーバヘッドは、ビデオデータ及びオーディオデータのようなマルチメディアコンテンツのためのメインリンク帯域幅が失われないようにし、効率的なパケットトランスポートメカニズムを提供する。メインリンクでのデータの伝送を調整するために、トランスポートストリームスケジューラは、ソースからシンクへストリーム属性データを送信する補助チャネルが更に提供され得るデータリンク上での任意の数のパケット化データストリームをスケジュールする、柔軟で効率的なシステム、方法、及び装置を提供する。

各データストリームは、多数の関連データパケットで形成されており、関連データパケットのサイズは、特定のデータストリームに必要なリンク帯域幅の相対部分によって決まる。特定のデータストリームｉについて、対応するパケットサイズＰＳｉは、以下の関係を通じて、最大パケットサイズＭＰＳと、リンクビットレートＬＢＲと、ストリームビットレートＳＢＲｉとに関連付けられている。
PSi = MPS*SBRi/(LBRi+1)

これにより、パケットサイズは、データリンク帯域幅と比較したデータストリームの相対帯域幅に基づいて、各データストリームについて決定される。例えば、最大パケットサイズが６４データシンボルで、リンクビットレートＬＢＲが一レーン当たり２．５Ｇｂｐｓである場合において、表１は、選択されたストリームビットレートに対応する代表的なパケットサイズを示す。

スケジューラは、多数のストリームのパケットを対応するリンクデータストリームへと（トランスミッタにおいて）時分割多重化及び（レシーバにおいて）逆多重化する。望ましい実施形態において、トランスミッタは、例えば、最大データリンクレート、利用可能バッファサイズ、及び時間基準回復（タイムベースリカバリ。ＴＢＲ）ユニットの数に関して、レシーバの能力を読み出す。この知識により、トランスミッタは、最も効率的なトランスポート構成と、レシーバが後続のデータストリームに対応できるかを、レシーバに対する追加の問い合わせを全く行う必要なく判断できる。データストリームトランスポートを開始する前に、トランスミッタは、レシーバに対して、ビデオデータ、色形式及び深度、ジオメトリに関するもの及び各データストリームに関連するパケットサイズといったストリーム属性を通知する。この属性データを通信することで、パケットヘッダのサイズは、ストリームＩＤのみが必要となる程度まで実質的に低減できる。これにより、大きなサイズのパケットヘッダにより実質的に大きなオーバヘッドを必要とする従来のパケットトランスポートプロトコルに比べ、転送効率は大幅に増加する。

本発明のストリームスケジューラを説明するための基盤を提供するために、本発明の実施に十分に適した代表的なデジタルビデオシステムについて説明する。

図１は、本発明の任意の数の実施形態を実施するのに十分に適したパケット式デジタルビデオディスプレイインタフェースの一般化表現を図示している。インタフェース１００は、物理リンク１０６（パイプとも呼ばれる）を経由して、トランスミッタ１０２をレシーバに接続する。説明する実施形態では、多数のデータストリーム１０８〜１１２がトランスミッタ１０２に受領され、トランスミッタ１０２は、必要であれば、それぞれを対応する数のデータパケット１１４にパケット化する。こうしたデータパケットは、その後、対応するデータストリームの形態にされ、それぞれのデータストリームは、関連する仮想パイプ１１６〜１２０を経由してレシーバ１０４に渡される。各仮想リンクのリンクレート（即ち、データパケット転送レート）は、特定のデータストリームのために最適化可能であり、結果として、（特定のデータストリームに応じて、それぞれ互いに異なる可能性のある）関連リンクレートをそれぞれが有するデータストリームを伝送する物理リンク１０６が生じることに留意されたい。データストリーム１１０〜１１４は、ビデオ、グラフィック、オーディオ、及びその他といった、任意の数の形態をとることができる。

通常、ソースがビデオソースである時、データストリーム１１０〜１１４は、コンポジットビデオ、シリアルデジタル、パラレルデジタル、ＲＧＢ、又は家庭用デジタルビデオといった、任意の数及びタイプの周知の形式を有する可能性がある様々なビデオ信号を含む。アナログテレビ、スチルカメラ、アナログＶＣＲ、ＤＶＤプレイヤ、ビデオカメラ、レーザディスクプレイヤ、ＴＶチューナ、セットトップボックス（及び衛星ＤＳＳ又はケーブル信号）、及びその他といった何らかの形態のアナログビデオソースをソース１０２が含む場合、ビデオ信号はアナログビデオ信号にできる。ソース１０２は、更に、例えば、デジタルテレビ（ＤＴＶ）、デジタルスチルカメラ、及びその他といったデジタル画像ソースを含むことができる。デジタルビデオ信号は、ＳＭＰＴＥ２７４Ｍ−１９９５（解像度１９２０×１０８０、プログレッシブ又はインタレーススキャン）、ＳＭＰＴＥ２９６Ｍ−１９９７（解像度１２８０×７２０、プログレッシブスキャン）、及び標準の４８０プログレッシブスキャンビデオといった任意の数及びタイプの広知のデジタル形式にできる。

ソース１０２がアナログ画像信号を提供する場合、アナログ−デジタルコンバータ（Ａ／Ｄ）は、アナログ電圧又は電流信号を別個の一連のデジタルエンコードされた数（信号）に変換し、このプロセスにおいて、デジタル処理に相応しい適切なデジタル画像データワードが形成される。広範なＡ／Ｄコンバータのいずれかを使用できる。一例として、その他のＡ／Ｄコンバータは、例えば、Philips、Texas Instrument、Analog Device、Brooktree、及びその他が製造したものを含む。

例えば、データストリーム１１０がアナログタイプの信号である場合、トランスミッタに含まれる、又はトランスミッタに結合されたアナログ−デジタルコンバータ（図示なし）は、アナログデータをデジタル化し、その後、デジタル化データストリーム１１０を多数のデータパケット１１４にパケット化するパケタイザがパケット化を行い、それぞれのデータパケット１１４は、仮想リンク１１６を経由して、レシーバ１０４に伝送されることになる。レシーバ１０４は、次に、データパケット１１４を再び適切に組み合わせてオリジナルの形式にすることで、データストリーム１１０を再構成する。リンクレートは、ネイティブストリームレートから独立していることに留意されたい。唯一の要件は、物理リンク１０６のリンク帯域幅が伝送対象の（複数の）データストリームの総帯域幅より高いことである。説明する実施形態において、着信データ（ビデオデータの場合のピクセルデータ等）は、データマップ定義に基づいて、それぞれの仮想リンク上でパックされる。これにより、物理リンク１０６（又は構成する仮想リンクのいずれか）は、ＤＶＩのような従来の相互接続で行われるように、一リンクキャラクタクロック当たり一ピクセルデータを伝送しない。

これにより、インタフェース１００は、ビデオデータ及びグラフィックデータのみではなく、必要に応じて、オーディオ及びその他のアプリケーションデータのトランスポートのためのスケーラブルな媒体を提供する。加えて、本発明は、ホットプラグイベント検出をサポートし、物理リンク（又はパイプ）を最適な伝送レートに自動的に設定する。本発明は、多数のプラットフォームに適した全てのディスプレイのために、低ピン数、純デジタルのディスプレイ相互接続を提供する。こうしたプラットフォームは、ディスプレイのホスト、ラップトップ／オールインワン、及びＨＤＴＶその他の家庭用電子機器での応用を含む。

ビデオデータ及びグラフィックデータを提供することに加え、表示タイミング情報をデジタルストリームに埋め込み、本質的に完全かつ即時的な表示調整を提供し、「自動調整」のような機能の必要性を除去できる。本発明のインタフェースのパケットに基づく性質は、多数のビデオ／グラフィックストリーム及びマルチメディア用途でのオーディオストリームといった多数のデジタルデータストリームをサポートするスケーラビリティを提供する。加えて、周辺機器用のユニバーサルシリアルバス（ＵＳＢ）トランスポートと表示制御とを、追加のケーブルの必要性なしで提供できる。

本発明のディスプレイインタフェースのその他の実施形態について、下で説明する。

図２は、ビデオソース２００とビデオディスプレイユニット２０４とを接続するために使用される、図１に図示したシステム１００に基づくシステム２００を例示している。例示した実施形態において、ビデオソース２０２は、デジタル画像（又はデジタルビデオソース）２０６及びアナログ画像（又はアナログビデオソース）２０８の一方又は両方を含むことができる。デジタル画像ソース２０６の場合、デジタルデータストリーム２１０がトランスミッタ１０２に提供されるが、アナログビデオソース２０８の場合には、結合されたＡ／Ｄコンバータユニット２１２が、アナログデータストリーム２１３を対応するデジタルデータストリーム２１４に変換する。デジタルデータストリーム２１４は、その後、トランスミッタ１０２によって、デジタルデータストリーム２１０とほぼ同じ形で処理される。ディスプレイユニット２０４は、アナログタイプのディスプレイ又はデジタルタイプのディスプレイにすることが可能であり、或いは一部のケースでは、提供されたアナログ又はデジタル信号のどちらでも処理できる。いずれの場合においても、ディスプレイユニット２０４は、レシーバとディスプレイ２１８、及びアナログタイプのディスプレイの場合にはＤ／Ａコンバータユニット２２０とのインタフェースをとるディスプレイインタフェース２１６を含む。説明する実施形態において、ビデオソース２０２は、任意の数の形態（パーソナルデスクトップコンピュータ、デジタル又はアナログテレビ、セットトップボックス、その他）をとることが可能であり、ビデオディスプレイユニット１０４は、ビデオディスプレイ（ＬＣＤ型ディスプレイ、ＣＲＴ型ディスプレイ、その他）の形態をとることができる。

しかしながら、ビデオソース又はビデオシンクのタイプに関係なく、様々なデータストリームは、物理リンク１０６上での伝送の前に（必要に応じて）デジタル化及びパケット化され、物理リンク１０６は、等時性データストリームのための単方向メインリンク２２２と、リンク設定及びビデオソース２０２とビデオディスプレイ２０４との間でのその他のデータトラフィック（様々なリンク管理情報、ユニバーサルシリアルバス（ＵＳＢ）データ、その他）のための双方向補助チャネル２２４とを含む。

メインリンク２２２は、これにより、多数の等時性データストリーム（多数のビデオ／グラフィックストリーム及びマルチチャネルオーディオストリーム）を同時に伝送することができる。説明する実施形態において、メインリンク２２２は、多数の異なる仮想チャネルを含み、仮想チャネルのそれぞれは、数ギガビット／秒（Ｇｂｐｓ）で等時性データストリーム（非圧縮グラフィック／ビデオ及びオーディオデータ）を転送できる。そのため、論理的な観点では、メインリンク２２２は、単一の物理パイプとして捉えられ、この単一の物理パイプ内部では、多数の仮想パイプを確立できる。これにより、論理データストリームが物理チャネルに割り当てられるのではなく、各論理データストリームが自分の論理パイプ（即ち、上記の仮想チャネル）において伝送される。

説明する実施形態において、メインリンク２２２の速度又は転送レートは、リンク条件を補償するために調整可能である。例えば、一実施において、メインリンク２２２の速度は、一チャネル当たり、最も遅い速度である約１．０Ｇｂｐｓ〜約２．５Ｇｂｐｓに近い範囲において、約０．４Ｇｂｐｓの増分で調整できる（図３参照）。一チャネル当たり２．５Ｇｂｐｓにおいて、メインリンク２２２は、単一のチャネル上で、ＳＸＧＡ６０Ｈｚを一ピクセル当たり１８ビットの色深度でサポートできる。チャネル数の減少により、相互接続のコストが減少するだけでなく、ポータブルデバイス及びその他といった電力に敏感な用途にとって重要な考慮事項（及び望ましい状態）である電力消費量の減少も発生することに留意されたい。しかしながら、チャネル数を四本に増加させることで、メインリンク２２２は、６０ＨｚのＷＱＳＸＧＡ（３２００×２０４８）を一ピクセル当たり２４ビットの色深度で、或いは６０ＨｚのＱＳＸＧＡ（２５６０×２０４８）を一ピクセル当たり１８ビットの色深度で、データ圧縮することなくサポートできる。最低レートの一チャネル当たり１．０Ｇｂｐｓでも、非圧縮ＨＤＴＶ（即ち、１０８０ｉ又は７２０ｐ）データストリームをサポートするために必要なチャネルは僅か二本である。

説明する実施形態において、メインリンクのデータレートは、その構成要素である仮想リンクの総帯域幅を上回る帯域幅となるものが選択される。インタフェースに送信されたデータは、ネイティブレートでトランスミッタに到達する。レシーバ１０４内の時間基準回復（ＴＢＲ）ユニット２２６は、必要な場合には、メインリンクデータパケットに埋め込まれたタイムスタンプを使用して、ストリームのオリジナルのネイティブレートを再生する。しかしながら、図２Ｂに図示した適切に構成されたデジタルディスプレイデバイス２３２では、ディスプレイデータがリンクキャラクタクロックレートでディスプレイドライバ電子回路に送信されるため、時間基準回復は不要であり、これにより、必要なチャネル数は、ディスプレイの複雑性及びコストの相応の低減と共に、大幅に減少することに留意されたい。例えば、図２Ｃは、アレイ２４０内の選択された表示素子２３８を駆動するためにロウドライバ２３６と組み合わせて使用される様々なカラムドライバ２３４へ、ディスプレイデータが本質的にパイプラインされるため、時間基準回復が存在しない形で構成された例示的なＬＣＤパネル２３２を表している。

その他の実施形態では、リンクレート及びピクセル／オーディオクロックレートの単純な算出法について説明する。現時点で存在する全ての標準ピクセル／オーディオクロック周波数は、以下のマスタ周波数のサブセットであることが研究及び理解されている。
23.76GHz=210ラ33ラ57ラ111Hz

これは、ピクセル（又はオーディオ）クロックレートを、四つのパラメータＡ、Ｂ、Ｃ、及びＤによって、次のように表現できることを意味する。
ピクセルクロックレート＝２Ａ＊３Ｂ×５Ｃ×１１Ｄ
Ａ＝４ビット、Ｂ＝２ビット、Ｃ＝３ビット、及びＤ＝１ビット

リンクレート（８Ｂ／１０Ｂ文字のような１０ビット文字を使用するリンクにおいて、シリアルリンクビットレート／１０）がピクセルクロックレートとは異なる可能性があるリンクについても、こうした四つのパラメータＡ’、Ｂ’、Ｃ’、及びＤ’によってリンクレートを定義することには利点がある。この利点は、リンククロックからピクセル／オーディオクロックを再生する際の容易さである。例えば、リンクレートがＡ’＝６、Ｂ’＝３、Ｃ’＝７、及びＤ’＝０に設定され、対応するリンクレートが１３５ＭＨｚであるとする。しかしながら、ピクセルクロックレートがＡ＝８、Ｂ＝３、Ｃ＝６、及びＤ＝０（＝１０８ＭＨｚ）に設定されると仮定すると、ピクセルクロックは、ピクセルクロックレートがリンクレート＊２２／５１に等しくなるように、リンククロックから生成できる。

時間基準回復を必要とするシステムを再び参照すると、時間基準回復ユニット２２６は、デジタルクロックシンセサイザとして実施してよい。非圧縮ビデオストリームについて、タイムスタンプは、パケットヘッダに格納され、下で更に詳細に説明するように２０ビット値となる。一定のストリームにおいて、２０ビットのうちの各四ビットが、各ヘッダにおいて連続的に格納される（TS3-0、TS7-4、TS11-8、TS15-12、TS19-16）。ネイティブストリーム周波数（Freq_native）は、次のように、リンク文字クロック周波数（Freq_link_char）から取得される。
Freq_native = Freq_link_char*(TS19-0)/220

トランスミッタ１０２は、２２０サイクルのリンク文字クロック周波数期間においてネイティブストリームクロック数をカウントすることで、このタイムスタンプを生成する。カウンタは、２２０サイクルのリンク文字クロック毎に値を更新する。これら二つのクロックは互いに非同期であるため、タイムスタンプ値は、時間と共に１ずつ変化することになる。更新と更新との間に、トランスミッタ１０２は、一定のパケットストリームのヘッダにおいて、同じタイムスタンプを繰り返し送信する。タイムスタンプ値の（１カウントより大きい）急変は、レシーバによって、ストリームソースの不安定状態を示すものと解釈される。

オーディオストリームでは、タイムスタンプが通信されないことに留意されたい。この場合、ソースデバイスは、ディスプレイデバイスに対して、オーディオサンプルレートと一サンプル当たりのビット数とを通知する。下のようにオーディオレート及びリンク文字レートを決定することで、ディスプレイデバイスは、オリジナルのオーディオストリームレートを再生する。
オーディオレート＝（オーディオサンプルレート）×（サンプル当たりビット数）×（チャネル数）

図４Ａに図示したメインリンクデータパケット４００は、図４Ｂに図示したようなメインリンクパケットヘッダ４０２を含み、パケットヘッダ４０２は、１６ビットの形態であり、ビット３〜０はストリームＩＤ（ＳＩＤ）（最大ストリームカウントが１６であることを示す）、ビット４はタイムスタンプ（ＴＳ）のＬＳＢである。ビット４が１に等しい時、このパケットヘッダは、タイムスタンプ値の最下位の四ビットを有する（非圧縮ビデオストリームに対してのみ使用される）。ビット５は、ビデオフレームシーケンスビットであり、ビデオフレーム境界において「０」から「１」或いは「１」から「０」にトグルするフレームカウンタの最下位ビットの役割を果たす（非圧縮ビデオストリームに対してのみ使用される）。ビット７及び６はリザーブされるが、ビット８〜１０は、先行する八ビットのエラーをチェックする四ビットＣＲＣ（ＣＲＣ）となる。ビット１５〜１２は、タイムスタンプ／ストリームＩＤ反転（ＴＳＰ／ＳＩＤｎ）であり、非圧縮ビデオでは、２０ビットタイムスタンプ値のうちの四ビットとして使用される。

本発明のインタフェースの利点の一つは、それぞれ異なる形式にすることが可能な異なるデータストリームを多重化し、更に、一定のメインリンクデータパケットに多数のサブパケットを包含させる能力である。例えば、図５Ａは、本発明の実施形態による、サブパケットエンクロージャ及び複数パケット多重化を提供するように構成されたシステム５００を図示している。システム５００は、図２に図示したシステム２００の特定の実施形態であり、したがって、本発明の範囲及び意図のいずれかを限定するものと解釈されるべきではないことに留意されたい。システム５００は、トランスミッタ１０２に含まれ、ストリーム１補足データストリーム５０４をデータストリーム２１０に組み合わせて多重化データストリーム５０６を形成するために使用される、ストリームソースマルチプレクサ５０２を含む。多重化データストリーム５０６は、その後、リンク層マルチプレクサ５０８に転送される。任意の数のデータストリームを組み合わせ、多重化メインリンクストリーム５１０を形成し、多重化メインリンクストリーム５１０は、多数のデータパケット５１２で形成され、データパケット５１２の一部は、内部に封入された任意の数のサブパケット５１４を含んでもよい。リンク層デマルチプレクサ５１６は、ストリームＩＤ（ＳＩＤ）と関連サブパケットヘッダとに基づいて、多重化データストリーム５１０を分割し、構成要素であるデータストリームとし、一方、ストリームシンクデマルチプレクサ５１８は、サブパケットに収容されたストリーム１補足データストリームを更に分割する。

図６は、三本のストリームがメインリンク２２２上で多重化される時の図５に図示したストリーム５１０の例として、多重化メインリンクストリーム６００の高レベル図を図示している。この例の三本のストリームは、ＵＸＧＡグラフィックス（ストリームＩＤ＝１）と、１２８０×７２０ｐビデオ（ストリームＩＤ＝２）と、オーディオ（ストリームＩＤ＝３）とである。メインリンクパケット４００の小さなパケットヘッダサイズは、パケットオーバヘッドを最小化し、結果として、非常に高いリンク効率を生み出す。パケットヘッダをこれほど小さくできるのは、メインリンク２２２でのパケットの伝送前に、補助チャネル２２４を介して、パケット属性が通信されるためである。

一般的に言えば、非圧縮ビデオデータストリームはビデオブランキング期間に対応するデータアイドル期間を有するため、サブパケットエンクロージャは、メインパケットストリームが非圧縮ビデオである時に効果的な方式となる。したがって、非圧縮ビデオストリームの形態であるメインリンクトラフィックは、この期間中に一連のＮｕｌｌ特殊文字を含むことになる。様々なデータストリームを多重化する能力を十分に利用することで、本発明の特定の実施は、ソースストリームがビデオデータストリームである時に、様々な方法を使用して、メインリンクレートとピクセルデータレートとの間の差異を補正する。例えば、図７に例示したように、ピクセルデータレートは、０．５Ｇｂ／秒となり、２ｎｓ毎にピクセルデータのビットが送信されるようになる。この例において、リンクレートは、１．２５Ｇｂ／秒に設定されており、０．８ｎｓ毎にピクセルデータのビットが送信されるようになっている。ここで、トランスミッタ１０２は、図８に例示したように、ピクセルデータ間に特殊文字を散在させる。二つの特殊文字は、ピクセルデータの第一のビットＰ１とピクセルデータの第二のビットＰ２との間に配置される。特殊文字によって、レシーバ１０４は、ピクセルデータの各ビットを区別することが可能となる。ピクセルデータのビット間に特殊文字を散在させることで、更に、リンクが同期を維持可能な安定したデータのストリームが形成される。この例において、特殊文字はＮｕｌｌ文字である。こうした方法では、リンクレートが十分に高速であるため、ラインバッファは不要であり、小さなＦＩＦＯのみが必要となる。しかしながら、受信側では、ビデオ信号を再構築するために、相対的に多くのロジックが必要となる。レシーバは、特殊文字の開始及び終了の時期を認識する必要がある。

散在法の代替は、ピクセルデータの連続ビットを、ヌル値のような特殊文字と交互に配置することである。例えば、Ｐ１からＰ４をトランスミッタ１０４に含まれるラインバッファに供給し、その後、更なるピクセルデータが利用可能になるまで、一つ以上のヌル値をバッファに供給することができる。こうした実施には、上記の散在法よりも相対的に大きなバッファスペースが必要となる。こうした多くの実施では、相対的に高速なリンク速度のため、ラインバッファを満たすのに必要な時間は、ラインバッファが一杯になった後でデータを伝送するのに必要な時間を上回ることになる。

図５Ａを参照して説明したように、本発明のインタフェースの利点の一つは、様々なデータストリームを多重化する能力だけでなく、更に特定のメインリンクデータパケット内に任意の数のサブパケットを封入することである。図９Ａは、本発明の実施形態による、代表的なサブパケット９００を図示している。サブパケット９００は、サブパケットヘッダ９０２を含み、説明する実施形態において、サブパケットヘッダ９０２は２バイトであり、ＳＰＳ（サブパケットスタート）特殊文字を伴う。サブパケット９００が封入されるメインリンクデータパケットがサブパケット９００に加えてパケットペイロードを含む場合には、ＳＰＥ（サブパケットエンド）特殊文字によって、サブパケット９００の終了を示す必要がある。そうでない場合には、メインパケットの終了（図９Ｂに図示した例ではＣＯＭ文字に続くことで示される）が、サブパケット９０２と、封入するメインパケットとの両方の終了を示す。しかしながら、サブパケットは、サブパケットを封入するメインパケットがペイロードを有していない時、ＳＰＥで終了する必要はない。図９Ｂは、本発明の実施形態による、メインリンクパケット内の例示的なサブパケット形式を図示している。ヘッダフィールド及びサブパケットペイロードの定義は、サブパケット９０２を使用する特定のアプリケーションのプロファイルに応じて変化することに留意されたい。

特に有用なサブパケットエンクロージャの使用法の例は、図１０に図示した非圧縮グラフィックス画像１０００の選択的リフレッシュである。フレーム１００２全体の属性（水平／垂直合計、画像幅／高さ、その他）については、ストリームが有効であり続ける限り、こうした属性は一定のままであるため、補助チャネル２２４を介して通信されることになる。選択的リフレッシュ動作では、画像１０００の一部１００４のみが、ビデオフレーム毎に更新される。更新された（複数の）長方形（即ち、部分１００４）の四つのＸ−Ｙ座標は、フレーム毎に伝送する必要があり、これは長方形座標の値がフレーム毎に変化するためである。別の例は、２５６色グラフィックデータに必要なカラールックアップテーブル（ＣＬＵＴ）の伝送であり、この場合、八ビットピクセルデータが２５６エントリＣＬＵＴに対するエントリとなり、ＣＬＵＴのコンテンツは、動的に更新されなければならない。

単一の双方向補助チャネル２２４は、リンク設定に有用な、メインリンクの動作をサポートする様々なサポート機能のための経路で、更にＵＳＢトラフィック等の補助アプリケーションデータを伝送する経路を提供する。例えば、補助チャネル２２４により、ディスプレイデバイスは、ソースデバイスに、同期消失等のイベント、欠落パケット、及びトレーニングセッションの結果（下記）を通知できる。例えば、特定のトレーニングセッションが失敗した場合、トランスミッタ１０２は、失敗したトレーニングセッションの事前に選択された或いは決定された結果に基づいて、メインリンクレートを調整する。これにより、調整可能な高速メインリンクと、相対的に低速で非常に信頼性の高い補助チャネルとを組み合わせることで形成される閉ループは、様々なリンク条件での堅牢な動作を可能にする。一部のケースでは（図５Ｂに図示した例）、データをソースデバイス２０２からシンクデバイス２０４に転送するメインリンク２２２の帯域幅の一部５２２と、シンクデバイス２０４からソースデバイス２０２への単方向バックチャネル５２４とを使用して、論理双方向補助チャネル５２０を確立できることに留意されたい。一部の応用では、この論理双方向補助チャネルの使用は、図５Ａにおいて説明した半二重双方向チャネルを使用することより望ましい場合がある。

実際のパケットデータストリームの伝送を開始する前に、トランスミッタ１０２は、概念においてモデムのリンク設定に類似するリンクトレーニングセッションを通じて、安定したリンクを確立する。リンクトレーニング中、メインリンクトランスミッタ１０２は、確実なビット／文字ロックが達成可能かをレシーバ１０４が判断できるように、所定のトレーニングパターンを送信する。説明する実施形態では、トランスミッタ１０２とレシーバ１０４との間でのトレーニングに関連するハンドシェイクが、補助チャネル上で実行される。本発明の実施形態による、リンクトレーニングパターンの例は、図１１に図示される。例示のように、トレーニングセッション中、段階１は、イコライザを最適化するためにレシーバによって使用される最短のランレングスを表し、一方、段階２は、最長のものである。段階３において、ビットロック及び文字ロックは、両方とも、リンク品質が妥当である限り達成される。通常、トレーニング期間は、約１０ｍｓであり、この時間内に、約１０７ビットのデータが送信される。レシーバ１０４は、確実なロックを達成しない場合、補助チャネル２２４を介してトランスミッタ１０２に通知を行い、トランスミッタ１０２は、リンクレートを低下させて、トレーニングセッションを繰り返す。トレーニングセッション経路を提供することに加え、補助チャネル２２４は、更に、メインリンクパケットストリームの説明を伝送するために使用可能であり、これにより、メインリンク２２２でのパケット伝送のオーバヘッドは大幅に減少する。更に、補助チャネル２２４は、全てのモニタで見られるディスプレイデータチャネル（ＤＤＣ）の代わりに、拡張表示識別データ（ＥＤＩＤ）情報を伝送するように構成できる（ＥＤＩＤは、ＶＥＳＡ規格のデータ形式で、ベンダ情報と、最大画像サイズと、色特性と、工場プリセットタイミングと、周波数範囲限界と、モニタ名及びシリアル番号の文字列とを含め、モニタ及びその機能に関する基本情報を含む。情報は、ディスプレイに格納され、モニタとＰＣグラフィックスアダプタとの間に位置するＤＤＣを通じてシステムと通信するために使用される。システムは、この情報を構成の目的で使用するため、モニタ及びシステムは連動が可能となる）。拡張プロトコルモードと呼ばれるものにおいて、補助チャネルは、キーボード、マウス、及びマイクロフォンといった追加的なデータタイプをサポートするために、必要に応じて、非同期パケット及び等時性パケットの両方を伝送できる。

図１２は、本発明の実施形態による、データスケジューラ１２０２を有する代表的なシステム１２００を図示している。システム１２００は、図５Ａ及び５Ｂを参照して説明したシステムに基づいており、そのため、本発明の任意の数の実施の一つに過ぎないと考えるべきであることに留意されたい。したがって、ストリームスケジューラ１２０２は、ビデオソース２０２に組み込まれるか、或いは結合され、続いて、マルチプレクサ１２０４と、スケジューラサイクル時間Ｔ_schedと呼ばれる期間中にリンクデータストリーム１２０８を送り込むのに使用される着信データストリーム（Ｓ１、Ｓ２、及びＳ３）の部分のみを格納するのに適したデータバッファ１２０６とに結合される。説明する実施形態において、データバッファ１２０６は、ＦｉｒｅＷｉｒｅ^TM等の等時性ビデオ転送プロトコルで代表的な６０Ｋバイトを超えるものとは対照的に、通常数十バイト程度のサイズである。これにより、リンク効率（利用可能帯域幅で除算したデータストリームのペイロード帯域幅合計の比較に基づく）は、およそ９０％程度以上となる。

説明する実施形態において、リンクデータストリーム１２０８は、データストリームＳ１、Ｓ２、及びＳ３のそれぞれからのサイズデータパケットＰ１、Ｐ２、及びＰ３（サイズは、リンク帯域幅との関係における各データストリームの相対帯域幅を反映する）を組み合わせるために時分割多重化を使用することで、スケジューラ１２０２によって形成される。以前に説明したように、各データパケットのサイズは、特定のデータストリームビットレート（ＳＢＲ）とリンクビットレート（ＬＢＲ）との関数である。特に、特定のデータストリームビットレートが大きくなれば、表１の例で示したように、特定のデータパケットは大きくなる。例えば、リンクビットレートＬＢＲが２．５Ｇｂｐｓ程度であり、最大パケットサイズがおよそ８０リンクシンボル程度であり（一リンクシンボルは、一リンククロック当たりのデータ単位として定義され、通常は４ｎｓである）、表１の前提（即ち、ＳＢＲ１が１．０５Ｇｂｐｓ、ＳＢＲ２が０．３１２５Ｇｂｐｓ、ＳＢＲ３が０．２５Ｇｂｐｓ）を使用する場合、ストリームＳ１に関連するデータパケットＰ１は、３２リンクシンボルとなり、一方、ストリームＳ２及びＳ３に関連するデータパケットＰ２及びＰ３は、それぞれ１０リンクシンボル及び８リンクシンボルとなる。各スケジューラサイクル時間Ｔ_schedの開始時には、スケジューラ１２０２が、通常は２リンクシンボル程度のサイズである、レシーバ２０４用のアライメントツールを提供するレーン間アライメントパケット（ＩＬＡ）を挿入することに留意されたい。そのため、この例においては、スケジューラサイクル時間Ｔ_schedは、（３２＋１０＋８＋２）５２リンクシンボル程度となる（各リンクシンボルが約４ｎｓを表す時、約２０８ｎｓと解釈される）。

更に、各データパケットＰは、次のようなストリームビットレート（ＳＢＲ）及びリンクビットレート（ＬＢＲ）に関するデータシンボルＤの数とスタッフィングシンボルＮとの関連アクティブデータ比を有することに留意されたい。
SBR/LBR = D/(D+N)

したがって、データストリームが追加（又は削除）され、スケジューラサイクル時間Ｔ_schedの増加（又は減少）が生じる状況においては、データシンボルＤの数との関係において、スタッフィングシンボルＮの数を変化させることで、パケットサイズＰは、一定状態を維持する。データストリームの追加（又は削除）により、特定のパケットサイズは同じ状態を維持し、他のデータストリーム及びスケジューラサイクル時間Ｔ_schedは増加（又は減少）するため、スタッフィングシンボルＮの数は、Ｔ_schedの変化に比例して増加（又は減少）する。単一のデータストリームのみが残る「縮退」のケースでは、スタッフィングシンボルＮは存在しなくなる。

図１３は、実施形態によるデータストリーム１２１０の更に詳細な部分１３００を図示している。特に、図１３は、表１に示した値を使用したデータストリーム１２０８のデータシンボルＤとスタッフィングシンボルＮの配置を図示している。更に、特定のデータストリームを動的に追加又は削除することで、残りのデータストリームの特定のパケットサイズが影響されないままとなることに留意されたい。したがって、図１４は、２０リンクシンボルのパケットサイズＰ４に対応する０．６２５Ｇｂｐｓのストリームビットレートを有する第四のデータストリームＳ４の追加を例示しており、この結果、Ｔ_schedは５２から７２リンクシンボル（４ｎｓに等しいリンクシンボルでは２８８ｎｓに相当する）に増加する。しかしながら、特定のパケットサイズＰ１、Ｐ２、及びＰ３を一定に保つために、スタッフィングシンボルＮの数は、各データパケットについて増加する。反対に、（例えばＳ３のような）データストリームが削除される場合、スケジューラサイクル時間Ｔ_schedは、スタッフィングシンボルＮの数に関係するデータシンボルＤの数の相応の増加に応じて減少することになる。一つ以外の全データストリームが削除される「縮退」のケースでは、残存するデータパケットは、スタッフィングシンボルＮを有しておらず、何らかのバッファの必要性も存在せず、これにより、上で説明したラスタスキャントランスポートプロトコルをシミュレートする。

リンクデータストリーム１２０８が（図１５に図示するような）単一の非圧縮ビデオストリームである時の縮退接続のケースにおいて、ＩＬＡパケットは、Ｓ１のアイドル期間（水平ブランキング領域）に配置され、アクティブな表示領域は、その後、データシンボルＤとスタッフィングシンボルＮとの混合によって表現される（図１６参照）。

更に、特定のデータストリームに関係しないデータシンボルと関連させて、特定のデータストリームのデータシンボルＤの数をカウントすることで、問題のデータストリームのストリームクロックが提供されることから、データシンボルＤの相対数が、埋め込みタイムスタンプを提供することに留意されたい。例えば、図１３に図示したケースにおいて、回復のために、特定のデータストリームのストリームクロックＦ_{stream_clk}は、単純に、スタッフィングシンボル及びストリームデータシンボルの合計数（Ｐ）と比較したストリームデータシンボルの数（Ｍ）を確定することで決定できる。更に詳しくは、ストリームクロックＦ_{stream_clk}は、次のように決定される。
F_{stream_clk}= (M/P)*F_{link_clk}
ここで、Ｍ及びＰは、レシーバ２０４によって測定できる。

図１７は、本発明の実施形態による、多数のデータストリームをスケジュールするプロセス１７００を詳細に表すフローチャートを図示している。プロセス１７００は、１７０２で、トランスミッタがストリーム属性データをレシーバに送信することで開始される。説明する実施形態において、属性データは、補助チャネルを経由して送信される。次に、１７０４において、レシーバは、着信データストリームを受領及び処理するために（利用可能な場合）十分なリソースを割り当てる。トランスミッタがデータストリーム１７０６を受領した後、ストリームトランスポートスケジューラは、１７０８において、リンクデータストリームを形成し、一方、１７１０において、リンクデータストリームは、メインリンクを経由して、トランスミッタによりレシーバへ送信される。次に、１７１２において、追加データストリームが追加され、１７１４において、レシーバが追加対象のデータストリームの受領及び処理の両方を行える場合、１７１６において、新しいデータストリームは、以前に伝送されたデータストリームのデータパケットサイズが一定に維持されるという点でトランスペアレントに追加される。

図１８は、本発明の実施形態による、リンクデータストリームを形成するプロセス１８００を詳細に表すフローチャートを図示している。処理１８００は、処理１７０８の形成動作１７０８の特定の実施であることに留意されたい。したがって、トランスポートスケジューラは、１８０２において、メインリンクのリンクビットレートを決定し、１８０４において、トランスミッタからレシーバへのリンクを経由してトランスポートされるべきデータストリームのそれぞれについて、ストリームビットレートを決定する。次に１８０６において、それぞれのデータストリームのためのパケットサイズが、ストリームビットレートと、リンクビットレートと、所定の最大パケットサイズとに基づいて決定される。次に１８０８において、それぞれのデータストリームのためのデータパケットが、それぞれ多数のデータシンボルとスタッフィングシンボルとを含む状態で形成される。データパケットが形成されると、単一のトランスポートスケジューラサイクル時間中に、トランスポートスケジューラは、１８１０において、レシーバに送信されるべきデータストリームのそれぞれからのデータパケットを（時分割多重化を使用して）連結し、１８１２において、連結されたデータパケットにレーン間アライメントパケットを追加する。１８１４において、トランスポートスケジューラは、連結されたデータパケットをレシーバに伝送するために、トランスミッタに信号を送り、１８１６において決定されるような伝送の中止まで、１８０８〜１８１４を繰り返す。

図１９は、本発明の実施形態による、システム２００の論理層構造１９００を例示している。正確な実施は用途に応じて変化してよいが、一般に、ソース（ビデオソース２０２等）は、トランスミッタハードウェアを含むソース物理層１９０２と、多重化ハードウェア及びステートマシン（又はファームウェア）を含むソースリンク層１９０４と、オーディオ／ビジュアル／グラフィックスハードウェア及び関連ソフトウェアのようなデータストリームソース１９０６とにより形成されることに留意されたい。同様に、ディスプレイデバイスは、物理層１９０８（様々なレシーバハードウェアを含む）と、逆多重化ハードウェア及びステートマシン（又はファームウェア）を含むシンクリンク層１９１０と、ディスプレイ／タイミングコントローラハードウェア及びオプションのファームウェアを含むストリームシンク１９１２とを含む。ソースアプリケーションプロファイル層１９１４は、ソースがリンク層１９０４と通信する形式を定義し、同様に、シンクアプリケーションプロファイル層１９１６は、シンク１９１２がシンクリンク層１９１０と通信する形式を定義する。

次に、様々な層について、更に詳細に説明する。

ソースデバイス物理層：
説明する実施形態において、ソースデバイス物理層１９０２は、電気副層１９０２−１と論理副層１９０２−２とを含む。電気副層１９０２−１は、ホットプラグ／アンプラグ検出回路と、ドライバ／レシーバ／終端レジスタと、パラレル−シリアル／シリアル−パラレル変換と、スペクトラム拡散対応ＰＬＬとのような、インタフェース初期化／動作のための全回路を含む。論理副層１９０２−２は、パケット化／逆パケット化と、データスクランブル化／スクランブル解除と、リンクトレーニング用パターン生成と、時間基準回復回路と、メインリンク２２２用の（図１３に例が図示された）２５６リンクデータ文字及び１２の制御文字を提供する８Ｂ／１０Ｂ（ANSI X3.230-1994第１１条において規定される）及び補助チャネル２２４用のManchester II（図２１参照）のようなデータエンコード／デコードとのための回路を提供する。

８Ｂ／１０Ｂエンコードアルゴリズムは、例えば、米国特許第４，４８６，７３９号において説明されており、参照により本明細書に組み込まれることに留意されたい。当業者に知られている通り、８Ｂ／１０Ｂコードは、シリアル伝送のために８ビットデータブロックを１０ビットコードワードにエンコードするブロックコードである。加えて、８Ｂ／１０Ｂ伝送コードは、１及び０のバイト幅ストリームを、最大ランレングスが５である１及び０のＤＣバランスストリームに変換する。こうしたコードは、トランシーバ１１０等のレシーバによる信頼性の高いクロック回復を可能にするのに十分な信号遷移を提供する。更に、ＤＣバランスデータストリームは、光ファイバ及び電磁線接続にとって有利となる。シリアルストリームにおける１及び０の平均数は、均等又は均等に近いレベルに維持される。８Ｂ／１０Ｂ伝送コードは、１及び０の数の格差を、６及び４ビットブロック境界に渡って、−２、０、又は２となるように抑制する。このコード方式は、更に、コマンドコードと呼ばれる、信号送信用の追加コードを実施する。

非圧縮ディスプレイデータが示す反復ビットパターンを回避する（したがって、ＥＭＩを低減する）ために、メインリンク２２２上で伝送されるデータは、８Ｂ／１０Ｂエンコードの前に、まずスクランブル化されることに留意されたい。トレーニングパケットと特殊文字とを除き、全データがスクランブル化されることになる。スクランブル化機能は、リニアフィードバックシフトレジスタ（ＬＦＳＲ）により実施される。データ暗号化が有効である時、ＬＦＳＲシードの初期値は、暗号鍵セットに応じて決まる。暗号化のないスクランブル化の場合、初期値は固定されることになる。

データストリーム属性は補助チャネル２２４上で伝送されるため、メインリンクパケットヘッダは、ストリーム識別番号の役割を果たし、これにより、オーバヘッドを大幅に減らし、リンク帯域幅を最大化する。更に、メインリンク２２２と補助リンク２２４とは、どちらも別個のクロック信号線を有していないことに留意されたい。これにより、メインリンク２２２及び補助リンク２２４上のレシーバは、データをサンプリングし、着信データストリームからクロックを抽出する。レシーバ電気副層内の任意の位相同期ループ（ＰＬＬ）回路のための高速位相同期は、補助チャネル２２４が半二重双方向であり、トラフィックの方向が頻繁に変化するため、重要となる。したがって、補助チャネルレシーバのＰＬＬは、Manchester II（MII）コードの頻繁かつ均一な信号遷移の結果、僅か１６データ期間で位相同期を行う。

リンク設定時、メインリンク２２２のデータレートは、補助チャネル２２４上でのハンドシェイクを使用して交渉される。このプロセス中には、トレーニングパケットの既知のセットが、メインリンク２２２上において、最高リンク速度で送信される。成功又は失敗は、補助チャネル２２４を介して、トランスミッタ１０２に連絡を返す。トレーニングが失敗した場合、メインリンク速度を低減し、成功するまでトレーニングを繰り返す。これにより、ソース物理層１９０２は、ケーブルのトラブルに対する抵抗力が更に増し、したがって、モニタアプリケーションの外部ホストとして更に適したものとなる。しかしながら、従来のディスプレイインタフェースとは異なり、メインチャネルのリンクデータレートは、ピクセルクロックレートから切り離される。リンクデータレートは、リンク帯域幅が伝送ストリームの総帯域幅を上回るように設定される。

ソースデバイスリンク層：
ソースリンク層１９０４は、リンクの初期化及び管理を扱う。例えば、モニタの電源投入時、或いはソース物理層１９０２からのモニタケーブルの接続時に生成されるホットプラグ検出イベントを受領すると、ソースデバイスリンク層１９０４は、補助チャネル２２４上でのやり取りを介して、レシーバの能力を評価し、トレーニングセッションで決定されるような最大メインリンクデータレートと、レシーバ上の時間基準回復ユニットの数と、両側で利用可能なバッファサイズと、ＵＳＢ拡張機能の可用性とを決定し、その後、ストリームソース１９０６に、関連するホットプラグイベントを通知する。加えて、ストリームソース１９０６からの要求時、ソースリンク層１９０４は、表示能力（ＥＤＩＤ又は同等のもの）を読み出す。正常動作中、ソースリンク層１９０４は、補助チャネル２２４を介してレシーバ１０４にストリーム属性を送信し、メインリンク２２２が要求データストリームを処理するのに十分なリソースを有するかをストリームソース１９０４に通知し、同期消失及びバッファオーバフローといったリンク障害イベントをストリームソース１９０４に通知し、ストリームソース１９０４によって提出されたＭＣＣＳコマンドをレシーバに対して、補助チャネル２２４を介して送信する。ソースリンク層１９０４とストリームソース／シンクとの間の全ての通信では、アプリケーションプロファイル層１９１４において定義された形式を使用する。

アプリケーションプロファイル層（ソース及びシンク）：
一般に、アプリケーションプロファイル層は、ストリームソース（又はシンク）が関連するリンク層とインタフェースする際の形式を定義する。アプリケーションプロファイル層によって定義された形式は、以下のカテゴリ、即ち、アプリケーション独立形式（リンク状態問い合わせのためのリンクメッセージ）及びアプリケーション従属形式（メインリンクデータマッピング、レシーバのための時間基準回復数式、及び該当する場合のシンク能力／ストリーム属性メッセージサブパケット形式）に分類される。アプリケーションプロファイル層は、以下の色形式、即ち、２４ビットＲＧＢ、１６ビットＲＧ２５６５、１８ビットＲＧＢ、３０ビットＲＧＢ、２５６色ＲＧＢ（ＣＬＵＴに基づく）、１６ビットＣｂＣｒ４２２、２０ビットＹＣｂＣｒ４２２、及び２４ビットＹＣｂＣｒ４４４をサポートする。

例えば、ディスプレイデバイスのアプリケーションプロファイル層（ＡＰＬ）１９１４は、本質的には、インタフェース１００に送信される又はインタフェース１００から受領されるデータの提示形式を含む、メインリンク２２２上でのストリームソース／シンク通信のための形式を記述するアプリケーションプログラミングインタフェース（ＡＰＩ）である。ＡＰＬ１９１４の一部の態様（電力管理コマンド形式等）は、基本モニタ機能であるため、インタフェース１００のあらゆる使用法において共通である。データマッピング形式及びストリーム属性形式といった、その他の非基本モニタ機能は、アプリケーション、或いは伝送対象である等時性ストリームのタイプに固有のものとなる。アプリケーションに関係なく、ストリームソース１９０４は、ソースリンクレイヤ１９１４に問い合わせを行い、メインリンク２２２上で何らかのパケットストリーム伝送を開始する前に、メインリンク２２２が（複数の）保留中のデータストリームを処理できるかを確認する。

メインリンク２２２が（複数の）保留中のデータストリームを処理できると判断された時、ストリームソース１９９６は、ソースリンク層１９１４にストリーム属性を送信し、その後、ストリーム属性は補助チャネル２２４上でレシーバに伝送される。こうした属性は、特定のストリームのパケットを識別し、ストリームからオリジナルのデータを復元し、ストリームのネイティブデータレートにフォーマットし直すために、レシーバによって使用される情報である。データストリームの属性は、アプリケーション従属である。

望ましい帯域幅がメインリンク２２２上で利用できない場合には、ストリームソース１９１４は、例えば、画像リフレッシュレート又は色深度を低減することで、修正措置を講じてもよい。

ディスプレイデバイス物理層：
ディスプレイデバイス物理層１９１６は、ディスプレイデバイスリンク層１９１０とディスプレイデバイスＡＰＬ１９１６とを、リンクデータの送受信に使用される信号伝送技術から分離させる。メインリンク２２２及び補助チャネル２２４は、独自の物理層を有し、それぞれの物理層は、論理副層とコネクタ仕様を含む電気副層とで構成される。例えば、半二重双方向補助チャネル２２４は、図２２に示すように、リンクの各端部にトランスミッタとレシーバとの両方を有する。補助リンクトランスミッタ２９０２には、論理副層１９０８−１によってリンク文字が提供され、その後、リンク文字はシリアル化され、対応する補助リンクレシーバ２９０４に伝送される。レシーバ２９０４は、次に、補助リンク２２４からのシリアル化されたリンク文字を受領し、リンク文字クロックレートでデータを非シリアル化する。ソース論理副層の主要な機能は、信号エンコードと、パケット化と、（ＥＭＩ低減のための）データスクランブル化と、トランスミッタポート用のトレーニングパターン生成とを含むことに留意されたい。一方、レシーバポートについて、レシーバ論理副層の主要な機能は、信号デコードと、非パケット化と、データスクランブル解除と、時間基準回復とを含む。

補助チャネル：
補助チャネル論理副層のような機能は、データエンコード／デコードと、データのフレーム化／非フレーム化とを含み、補助チャネルプロトコルには二種類のオプションが存在し、スタンドアロンプロトコル（ポイントツーポイントトポロジにおけるリンク設定／管理機能に限定される）は、リンク層ステートマシン又はファームウェアによって管理可能な軽量プロトコルと、ＵＳＢトラフィック等の他のデータタイプ及びデイジーチェイン方式でつながれたデバイス等のトポロジをサポートする拡張プロトコルとになる。データエンコード及びデコード方式はプロトコルに関係なく同一だが、データのフレーム化は二種類の間で異なることに留意されたい。

更に図２９を参照すると、補助チャネル電気副層は、トランスミッタ２９０２及びレシーバ２９０４を含む。トランスミッタ２９０２には、論理副層によってリンク文字が提供され、リンク文字はシリアル化され外部に伝送される。レシーバ２９０４は、シリアル化されたリンク文字をリンク層から受領し、その後、リンク文字クロックレートで非シリアル化する。補助チャネル２２４の正及び負の信号は、図示したように、リンクの各端部で、５０オーム終端抵抗を介してアースさせ終端とする。説明する実施において、ドライバ電流は、リンク条件に応じてプログラム可能であり、約８ｍＡ〜約２４ｍＡの範囲となり、結果として、約４００ｍＶ〜約１．２ＶのVdifferential_ppの範囲が生じる。電気的アイドルモードでは、正及び負の信号は、どちらも駆動されない。電気的アイドル状態から伝送を開始する時には、ＳＹＮＣパターンを伝送し、リンクを再び確立する必要がある。説明する実施形態において、ＳＹＮＣパターンは、補助チャネル差動ペア信号をクロックレートで２８回トグルさせ、Manchester IIコードの四つの１を続けることで構成される。ソースデバイスの補助チャネルマスタは、補助チャネル２２４の正及び負の信号を周期的に駆動及び測定することで、ホットプラグ及びホットアンプラグイベントを検出する。

メインリンク：
説明する実施形態において、メインリンク２２２は、ローカル水晶周波数の整数の倍数である個別の可変リンクレートをサポートする（２４ＭＨｚのローカル水晶周波数を有するリンクレート定数の代表的なセットについては図３を参照）。図１６に図示したように、メインリンク２２２（単方向チャネル）は、ソースデバイスにおいてトランスミッタ１６０２のみを有し、ディスプレイデバイスにおいてレシーバ１６０４のみを有する。

図示したように、ケーブル２３０４は、一組のツイストペア線を含む形態をとり、通常のＲＧＢカラーに基づくビデオシステム（ＰＡＬに基づくテレビシステム等）において提供される赤（Ｒ）、緑（Ｇ）、及び青（Ｂ）のそれぞれについて一本となる、当業者に知られている通り、ツイストペアケーブルは、独立して絶縁して互いに撚り合わせた二本の線で構成されるケーブルのタイプである。一方の線は信号を伝送し、他方の線はアースされ、信号の干渉を吸収する。他の一部のシステムにおいて、信号は、ＮＴＳＣビデオテレビシステムで使用されるコンポーネントに基づく信号（Ｐｂ、Ｐｒ、Ｙ）にもできることに留意されたい。ケーブル内で、各ツイストペアは、個別にシールドされる。＋１２Ｖの電力及び接地用の二本のピンが提供される。各差動ペアの特性インピーダンスは、１００オーム±２０％である。ケーブル全体もシールドされる。この外部シールド及び個別シールドは、両方の端部でコネクタシェルに短絡させる。コネクタシェルは、ソースデバイスにおいて、アースに短絡させる。図２４に図示したコネクタ２４００は、１３ピンを一列で有し、ソースデバイス端部のコネクタとディスプレイデバイス端部のコネクタとの両方で同一なピンアウトを有する。ソースデバイスは、電力を供給する。

メインリンク２２２は、両方の端部で終端され、メインリンク２２２がＡＣ結合であることから、終端電圧は０Ｖ（アース）〜＋３．６Ｖのいずれかにすることができる。説明する実施において、駆動電流は、リンク条件に応じてプログラム可能であり、約８ｍＡ〜約２４ｍＡの範囲となり、結果として、約４００ｍＶ〜約１．２ＶのVdifferential_ppの範囲が生じる。最小電圧振幅は、トレーニングパターンを使用して、各接続について選択される。電気的アイドル状態は、電力管理モードを提供する。電気的アイドルにおいて、正及び負の信号は、どちらも駆動されない。電気的アイドル状態から伝送を開始する時、トランスミッタは、レシーバとのリンクを再確立するために、トレーニングセッションを実行する必要がある。

状態図：
次に、本発明を、下で説明する図２５及び２６に図示した状態図の観点から説明する。したがって、図２５は、下で説明する状態図を図示している。オフ状態２５０２において、システムはオフとなり、ソースが無効化されるようになる。ソースが有効となった場合、システムは、省電力及びレシーバ検出に適した待機状態２５０４へ遷移する。レシーバが存在するかどうか（即ち、ホットプラグ／プレイ）を検出するために、補助チャネルには周期的にパルスが送られ（１０ｍｓ毎に１ｕｓ等）、駆動中の終端レジスタに渡る電圧降下の度合いを測定する。測定された電圧降下に基づいて、レシーバが存在すると判断された場合、システムは、レシーバが検出されたこと、即ち、ホットプラグイベントが検出されたことを示す検出レシーバ状態２５０６に遷移する。しかしながら、レシーバが検出されなかった場合、レシーバ検出は、発生する場合はレシーバが検出される時点まで、或いはタイムアウトが経過した時点まで、継続される。一部のケースにおいて、ソースデバイスは、更なるディスプレイ検出が試行されない「オフ」状態への移行を選択してもよいことに留意されたい。

状態２５０６において、ディスプレイのホットアンプラグイベントが検出された場合、システムは、再び待機状態２５０４に遷移する。そうでない場合、ソースは、正及び負の信号により補助チャネルを駆動し、レシーバのスリープ解除を行い、存在する場合は、レシーバのその後の応答をチェックする。応答が受領されない場合、レシーバはスリープ解除されておらず、ソースは、状態２５０６にとどまる。しかしながら、ディスプレイから信号が受領された場合、ディスプレイはスリープ解除されており、ソースでは、レシーバのリンク能力（最大リンクレート、バッファサイズ、及び時間基準回復ユニット数等）を読み出す準備が整い、システムは、メインリンク初期化状態２５０８に遷移し、トレーニング開始通知段階を開始する準備が整う。

このとき、トレーニングセッションは、メインリンクにおいて、設定されたリンクレートでトレーニングパターンを送信することで開始され、関連するトレーニング状態をチェックする。レシーバは、三段階のそれぞれについて成功／失敗ビットを設定し、トランスミッタは、成功のみの検出によって次の段階に進み、成功が検出される時、メインリンクはそのリンクレートで準備されるようになる。このとき、インタフェースは、正常動作状態２５１０に遷移し、そうでない場合には、リンクレートが低減され、トレーニングセッションが繰り返される。正常動作状態２５１０の間、ソースは、リンク状態のインデックスを周期的にモニタし続け、失敗した場合には、ホットアンプラグイベントが検出され、システムは待機状態２５０４に遷移し、ホットプラグ検出イベントを待つ。しかしながら、同期消失が検出された場合、システムは、メインリンク再始動イベントのために状態２５０８に遷移する。

図２６は、下で説明するディスプレイ状態図２６００を図示している。状態２６０２では、電圧は検出されず、ディスプレイは、オフ状態へ進む。待機モード状態２６０４では、メインリンクレシーバ及び補助チャネルスレーブは、両方とも、電気的にアイドルとなり、補助チャネルスレーブポートの終端レジスタに渡る電圧降下が、所定の電圧についてモニタされる。所定の電圧が検出された場合、補助チャネルスレーブポートは、オンになってホットプラグイベントを示し、システムは表示状態２６０６へ移行し、そうでない場合、ディスプレイは待機状態２６０４にとどまる。状態２６０６（メインリンク初期化段階）において、ディスプレイが検出された場合、補助スレーブポートは、完全にオンとなり、トランスミッタは、レシーバリンク能力読み出しコマンドに応答し、ディスプレイ状態は２６０８に遷移し、そうでない場合には、所定の期間を超えて補助チャネルでの活動が存在しなければ、補助チャネルスレーブポートは、待機状態２６０４に入る。

トレーニング開始通知段階の間、ディスプレイは、トレーニングパターンを使用してイコライザを調整し、各段階の結果を更新することで、トランスミッタによるトレーニング始動に応答する。トレーニングが失敗した場合には、別のトレーニングセッションを待ち、トレーニングが成功した場合には、正常動作状態２６１０へ移行する。所定の時間（例えば、１０ｍｓ）を超えて補助チャネル又は（トレーニングのための）メインリンクでの活動が存在しない場合、補助チャネルスレーブポートは、待機状態２６０４に設定される。

図２７〜３１は、クロスプラットフォームインタフェースの特定の実装を図示している。

図２７は、本発明によるトランスミッタ２７０４を組み込んだオンボードグラフィックスエンジン２００２を有するＰＣマザーボード２００を図示している。トランスミッタ２７０４は、図１に図示したトランスミッタ１０２の特定の例であることに留意されたい。説明する実施形態において、トランスミッタ２７０４は、マザーボード２０００にマウントされた（コネクタ２４００の線に沿った）コネクタ２７０６に結合され、次にコネクタ２７０６は、ディスプレイデバイス２７１０を結合するツイストペアケーブル２７１０を経由して、ディスプレイデバイス２７０８に接続される。

この技術で知られているように、PCI Express（カリフォルニア州サンタクララのIntel Corporationが開発）は、広帯域幅で低ピン数のシリアル相互接続技術であり、既存のＰＣＩインフラとのソフトウェア互換性も維持する。この構成において、PCI Expressポートは、図示したマザーボードマウントコネクタを使用しても、ディスプレイデバイスを直接的に駆動できるクロスプラットフォームインタフェースの要件に準拠するように増強される。

マザーボードにコネクタをマウントするのが実際的ではない状況において、信号は、PCI ExpressマザーボードのＳＤＶＯスロットを通じてルートを定め、図２８に図示したような受動カードコネクタを使用して、ＰＣの背面に伝えることができる。現世代のアドイングラフィックスカードと同様に、アドイングラフィックスカードは、図３０に図示したようなオンボードグラフィックスエンジンに取って代わることができる。

ノートブックでの応用の場合、マザーボードグラフィックスエンジン上のトランスミッタにより、パネルを直接的に駆動する一体式レシーバ／ＴＣＯＮが、内部配線を通じて駆動される。最も費用効率に優れた実施では、レシーバ／ＴＣＯＮは、パネル上にマウントされ、これにより、相互接続線の数は、図３１に図示したように八本又は十本に低減される。

上の全ての例では、一体式トランスミッタを想定している。しかしながら、PCI及びPCI Express環境に、それぞれＡＧＰ又はＳＤＶＯスロットを通じて統合される、スタンドアロントランスミッタとしても、完全に実現可能である。スタンドアロントランスミッタは、グラフィックスハードウェア又はソフトウェアを全く変化させることなく、出力ストリームを可能にする。

フローチャートの実施形態：
次に、本発明の方法について、本発明を可能にする特定のプロセスをそれぞれが説明する多数のフローチャートの観点から説明する。具体的には、図３２〜３６は、単独で或いは任意の組み合わせで使用される時に本発明の態様を説明する、多数の相互に関連するプロセスを表している。

図３２は、本発明の実施形態による、インタフェース１００の動作モードを決定するプロセス３２００を詳細に表すフローチャートを図示している。このプロセスにおいて、動作モードは、ビデオソース及びディスプレイデバイスが共にデジタルである場合、デジタルモードのみに設定されることになる。そうでない場合、動作モードは、アナログモードに設定されることになる。このコンテクストにおける「アナログモード」は、従来のＶＧＡモードと、埋め込みアライメント信号及び双方向側波帯を備えた差動アナログビデオを有する拡張アナログモードとの両方を含むことに留意されたい。この拡張アナログモードについては、下で説明する。

ステップ３２０２において、ビデオソースは、ビデオソースがアナログ又はデジタルデータをサポートするかを判断するために問い合わせを受ける。ビデオソースがアナログデータのみをサポートする場合、結合デバイス１００の動作モードは、アナログに設定され（ステップ３２０８）、プロセスは終了することになる（ステップ３２１２）。

ビデオソースがデジタルデータを出力できる場合、プロセスは、ステップ３２０６へ続く。ディスプレイデバイスは、次に、ディスプレイデバイスがデジタルデータを受領するように構成されているかを判断するために問い合わせを受ける。ディスプレイデバイスがアナログデータのみをサポートする場合、結合デバイス１００の動作モードは、アナログに設定され（ステップ３２０８）、プロセスは終了することになる（ステップ３２１２）。そうでない場合、結合デバイス１００の動作モードは、デジタルに設定される（ステップ３２１０）。例えば、プロセッサは、モードをデジタルに設定するために、結合デバイス内のスイッチを制御してよい。一般に、結合デバイスは、ビデオソース及びビデオシンクが対応するデジタルモードで動作する時のみ、完全デジタルモードで動作するように構成される。

図３３は、本発明の一部の態様による、リアルタイムビデオ画質チェックを提供するプロセス３３００を詳細に表すフォーチャートを図示している。この例において、プロセス３３００の全ての判定は、ディスプレイインタフェースに結合されたプロセッサにより行われる。

ステップ３３００において、ビデオ信号が、ビデオソースから受領される。次に、信号品質テストパターンが、受領ビデオ信号に関連するビデオソースによって提供される（ステップ３３０２）。ステップ３３０４において、品質テストパターンに基づいて、ビット誤り率が判定される。その後、ビット誤り率が閾値より大きいかについて判定される（ステップ３３０６）。ビット誤り率が閾値より大きくないと判定された場合には、ビデオフレームが更に存在するかどうかについて判定される（ステップ３３１４）。ビデオフレームが更に存在しないと判定された場合には、プロセスは、ステップ３３００に戻る。そうでない場合、プロセスは終了する。

しかしながら、ステップ３３０６において、ビット誤り率が閾値より大きいと判定された場合、ビットレートが最小ビットレートより大きいかについての判定が行われる（ステップ３３０８）。ビットレートが最小ビットレートより大きい場合、ビットレートを低下させ（ステップ３３１０）、プロセスはステップ３３０６に戻る。ビットレートが最小ビットレートより大きくない場合は、モードをアナログモードに変更し（ステップ３３１２）、プロセスを終了する。

図３４は、本発明の実施形態による、リンク設定プロセス３４００のフローチャートを図示している。プロセス３４００は、３４０２において、ホットプラグ検出イベント通知の受領によって開始される。３４０４において、最大データレートと、レシーバに含まれる時間基準回復ユニット数と、利用可能なバッファサイズとを決定するために、関連する補助チャネルを経由して、メインリンクの問い合わせが行われる。次に、３４０６において、最大リンクデータレートが、トレーニングセッションを経由して検証され、３４０８において、データストリームソースは、ホットプラグイベントを通知される。３４１０において、ディスプレイの能力が、補助チャネルを経由して（例えば、ＥＤＩＤを使用して）決定され、ディスプレイは、３４１２において、問い合わせに応答し、次に、３４１４において、メインリンクトレーニングセッションのための協働が生じる。

次に、３４１６において、ストリームソースは、補助チャネルを経由して、レシーバにストリーム属性を送信し、３４１８において、ストリームソースは、メインリンクが３４２０での要求データストリーム数をサポートできるかを更に通知される。３４２２において、様々なデータパケットが、関連するパケットヘッダを追加することで形成され、３４２４において、多数のソースストリームの多重化がスケジュールされる。３４２６において、リンク状態がＯＫかどうかについて、判定が行われる。リンク状態がＯＫではない場合、（複数の）ソースは、３４２８においてリンク障害イベントの通知を受け、そうでない場合、リンクデータストリームは、３４３０において様々なパケットヘッダに基づいて、ネイティブストリームに再構築される。３４３２において、再構築されたネイティブストリームは、ディスプレイデバイスに渡される。

図３５は、本発明の実施形態による、トレーニングセッションを実行するプロセス３５００を詳細に表すフローチャートを図示している。トレーニングセッションプロセス３５００は、図３２において説明した動作３２０６の一実施であることに留意されたい。トレーニングセッションは、３５０２において、設定リンクレートにより、メインリンク上でトレーニングパターンをレシーバに送信することで開始される。通常のリンクトレーニングパターンは、本発明の実施形態による、通常のトレーニングパターンは、図１１に図示される。例示のように、トレーニングセッション中、段階１は、最短のランレングスを表し、一方、段階２は、最長のものとなる。レシーバは、こうした二つの段階を使用して、イコライザを最適化する。段階３において、ビットロック及び文字ロックは、両方とも、リンク品質が妥当である限り達成される。３５０４において、レシーバは、関連するトレーニング状態をチェックし、トレーニング状態のチェックに基づいて、レシーバは、３５０６において、三段階のそれぞれとトランスミッタとについて、成功／失敗ビットを設定する。各段階において、レシーバは、成功のみが検出された時に次の段階に進み、３５１０において、レシーバが成功を検出しない場合、レシーバは、リンクレートを低減し、トレーニングセッションを繰り返す。メインリンクでは、３５１２において、成功が検出されたリンクレートでの準備が整う。

図３６は、本発明を実施するために利用されるコンピュータシステム３６００を例示している。コンピュータシステム３６００は、本発明の実施可能なグラフィックスシステムの例に過ぎない。コンピュータシステム３６００は、中央処理装置（ＣＰＵ）３６１０と、ランダムアクセスメモリ（ＲＡＭ）３６２０と、読み出し専用メモリ（ＲＯＭ）３６２５と、一つ以上の周辺機器３６３０と、グラフィックスコントローラ３６６０と、一次記憶デバイス３６４０及び３６５０と、デジタルディスプレイユニット３６７０とを含む。この技術でよく知られているように、ＲＯＭは、データ及び命令を単方向でＣＰＵ３６１０に転送する役割を果たし、一方、ＲＡＭは、通常、データ及び命令を双方向の形で転送するために使用される。ＣＰＵ３６１０は、一般に、任意の数のプロセッサを含んでもよい。一次記憶デバイス３６４０及び３６５０は、両方とも、任意の適切なコンピュータ読取可能な媒体を含んでもよい。通常は大容量メモリデバイスである二次記憶媒体８８０も、双方向でＣＰＵ３６１０に結合され、追加的なデータ記憶容量を提供する。大容量メモリデバイス８８０は、コンピュータコード、データ、及びその他を含む、プログラムを格納するのに使用し得るコンピュータ可読媒体である。通常、大容量メモリデバイス８８０は、一次記録デバイス３６４０、３６５０よりも一般的に低速な、ハードディスク又はテープのような記憶媒体である。大容量メモリ記憶デバイス８８０は、磁気又は紙テープリーダ、或いは他の何らかの広く知られたデバイスの形態をとってもよい。大容量メモリデバイス８８０内で保持される情報は、適切である場合、標準的な形で、仮想メモリとしてＲＡＭ３６２０の一部に組み込んでもよいと理解される。

ＣＰＵ３６１０は、更に、ビデオモニタ、トラックボール、マウス、キーボード、マイクロフォン、タッチセンシティブディスプレイ、トランスデューサカードリーダ、磁気又は紙テープリーダ、タブレット、スタイラス、音声又は手書認識器、或いは、当然ながら、他のコンピュータ等、その他の広く知られた入力デバイスといったデバイスを一部として含んでもよい一つ以上の入出力デバイス８９０に結合される。最後に、ＣＰＵ３６１０は、３６９５において一般的に図示したようなネットワーク接続を使用して、コンピュータ、或いはインターネットネットワーク又はイントラネットネットワーク等の電気通信ネットワークに、随意的に結合してもよい。こうしたネットワーク接続により、ＣＰＵ３６１０は、上記の方法のステップを実行する過程で、ネットワークから情報を受領してよく、或いは、ネットワークに情報を出力してよいと考えられる。こうした情報は、ＣＰＵ３６１０を使用して実行されるべき命令のシーケンスとして表現される場合が多く、例えば、搬送波内で具現化されるコンピュータデータ信号の形態で、ネットワークから受領され、ネットワークに出力されてよい。上記のデバイス及び材料は、コンピュータハードウェア及びソフトウェアに関わる当業者によく知られている。

グラフィックスコントローラ３６６０は、アナログ画像信号と対応する基準信号とを生成し、両方をデジタルディスプレイユニット３６７０に提供する。アナログ画像データは、例えば、ＣＰＵ３６１０又は外部エンコード（図示なし）から受領したピクセルデータに基づいて生成できる。一実施形態において、アナログ画像データは、ＲＧＢ形式で提供され、基準信号は、この技術で広く知られたＶＳＹＮＣ及びＨＳＹＮＣ信号を含む。しかしながら、本発明は、その他の形式のアナログ画像、データ、及び／又は基準信号により実施することも可能であると理解するべきである。例えば、アナログ画像データは、対応する時間基準信号を更に備えるビデオ信号データを含むことができる。

本発明のいくつかの実施形態のみを説明してきたが、本発明は、本発明の趣旨又は範囲から逸脱することなく他の多数の特定の形態で実施し得ると理解されるべきである。この説明は、制限的ではなく例示的なものと考えられるべきであり、本発明は、本明細書に記載した詳細に限定されず、付記する請求項の範囲内及び等価物の全範囲内で、変形し得る。

以上、好適な実施形態の観点から本発明を説明してきたが、本発明の範囲内に含まれる変更、置換、及び等価物が存在する。また、本発明のプロセス及び装置の両方を実現する多数の代替方法が存在することに留意されたい。したがって、本発明は、本発明の本来の趣旨及び範囲内に入るこうした全ての変更、置換、及び等価物を含むものであると解釈されるべきである。

本発明の実施形態によるクロスプラットフォームディスプレイインタフェース１００の一般化表現を示す図。本発明の多数の実施形態による、ビデオソースとビデオディスプレイユニットとを接続するために使用されるビデオインタフェースシステムを例示する図。本発明の多数の実施形態による、ビデオソースとビデオディスプレイユニットとを接続するために使用されるビデオインタフェースシステムを例示する図。本発明の多数の実施形態による、ビデオソースとビデオディスプレイユニットとを接続するために使用されるビデオインタフェースシステムを例示する図。本発明の実施形態による、例示的なメインリンクレートを示す図。本発明の実施形態による、メインリンクデータパケットを示す図。本発明の実施形態による、メインリンクパケットヘッダを示す図。本発明の実施形態による、サブパケットエンクロージャと多数のパケットの多重化を提供するように構成されたシステムを示す図。図５Ａに図示したシステムの別の実施を示す図。図５に図示したストリームの例としての多重化メインリンクストリームの高レベル図。本発明の実施形態による、データストリームの別の例を示す図。本発明の実施形態による、多重化データストリームの更に別の例を示す図。本発明の実施形態による、代表的なサブパケットを示す図。本発明の実施形態による、代表的なメインリンクデータパケットを示す図。選択的にリフレッシュされるグラフィックス画像の例を示す図。本発明の実施形態による、例示的なリンクトレーニングパターンを示す図。本発明の実施形態による、データストリームスケジューラを有する代表的なシステムを示す図。図１２に図示したデータストリームの一部を更に詳細に示す図。本発明の実施形態による、第四のデータストリームの追加を例示する図。本発明の実施形態による、単一非圧縮データストリームの縮退のケースを示す図。図１５に図示した縮退単一データストリームに基づいたビデオ表示を示す図。本発明の実施形態による、多数のデータストリームをスケジュールするプロセスを詳細に表すフローチャート。本発明の実施形態による、リンクデータストリームを形成するプロセスを詳細に表すフローチャート。本発明の実施形態による、システムの論理層状化を例示する図。本発明の実施形態による、８Ｂ／１０Ｂを使用する例示的な特殊文字のマッピングを示す図。本発明の実施形態による、例示的なManchester IIエンコード方式を示す図。本発明の実施形態による、代表的な補助チャネル電気副層を示す図。本発明の実施形態による、代表的なメインリンク電気副層を示す図。本発明の実施形態による、代表的なコネクタを示す図。本発明の実施形態によるソース状態図。本発明の実施形態によるディスプレイ状態図。本発明の様々なコンピュータに基づく実施を例示する図。本発明の様々なコンピュータに基づく実施を例示する図。本発明の様々なコンピュータに基づく実施を例示する図。本発明の様々なコンピュータに基づく実施を例示する図。本発明の様々なコンピュータに基づく実施を例示する図。本発明の実施形態による、インタフェースの動作モードを決定するプロセスを詳細に表すフローチャート。本発明の一部の態様による、リアルタイムビデオ画質チェックを提供するプロセスを詳細に表すフォーチャート。本発明の実施形態による、リンク設定プロセスのフローチャート。本発明の実施形態による、リンク設定プロセスのフローチャート。本発明の実施形態による、トレーニングセッションを実行するプロセスを詳細に表すフローチャート。本発明を実施するために利用されるコンピュータシステムを例示する図。

Claims

マルチメディアソースデバイスをマルチメディアシンクデバイスに結合するように構成されたパケット式ディスプレイインタフェースであって、
ソースデバイスに接続され、ネイティブストリームレートに従ってソースパケットデータストリームを受領するように構成されたトランスミッタユニットと、
前記シンクデバイスに接続されたレシーバユニットと、
前記トランスミッタユニットと前記レシーバユニットを接続し、前記トランスミッタユニットと前記レシーバユニットとの間で前記ネイティブストリームレートから独立したリンクレートに従い前記ソースパケットデータストリームに基づいて多数のマルチメディアデータパケットから形成されるマルチメディアデータパケットストリームを転送するように構成されたリンクユニットと、
前記リンクユニットに接続され、前記データストリームのうちの選択されたものについて前記リンクユニットを介して転送するためにデータパケットをスケジュールするように構成されたデータパケットスケジューラと、
を備え、
各データストリームのデータパケットサイズは、関連する固定サイズを有し、前記固定サイズはデータストリームビットレートとリンクビットレートとの間の比に依存する、ディスプレイインタフェース。
前記マルチメディアデータパケットストリームは、前記ネイティブストリームレートから独立した関連する調整可能なデータストリームリンクレートをそれぞれ有する多数のマルチメディアデータパケットストリームの一つである、請求項１記載のディスプレイインタフェース。
前記リンクユニットは、更に、
前記トランスミッタユニットから前記レシーバユニットへ前記マルチメディアデータパケットを伝送するように構成された単方向メインリンクと、
前記トランスミッタユニットと前記レシーバユニットとの間を双方向に情報を転送するように構成された双方向補助リンクと、を備える、請求項１記載のディスプレイインタフェース。
前記双方向補助チャネルは、前記シンクデバイスから前記ソースデバイスへ情報を伝送するように構成された単方向バックチャネルと、前記バックチャネルと協調して前記ソースデバイスから前記シンクデバイスへ情報を伝送するメインチャネルの一部として含まれる単方向フォワードチャネルと、により構成される、請求項３記載のディスプレイインタフェース。
前記メインリンクユニットは、更に、
前記マルチメディアデータパケットストリームのうちの特定の一つとそれぞれ関連付けられた多数の仮想リンクを備え、
前記仮想リンクのそれぞれは、関連する仮想リンク帯域幅と仮想リンクレートとを有する、請求項２記載のディスプレイインタフェース。
メインリンク帯域幅が、前記仮想リンク帯域幅の合計に少なくとも等しい、請求項５記載のディスプレイインタフェース。
マルチメディアソースデバイスをマルチメディアシンクデバイスに接続する方法であって、
トランスミッタユニットが接続されたソースデバイスを提供するステップと、
レシーバユニットが接続されたシンクデバイスを提供するステップと、
前記トランスミッタユニットにより、ネイティブストリームレートに従ったソースデータストリームを受領するステップと、
リンクユニットを介して前記トランスミッタユニットと前記レシーバユニットとを接続するステップと、
多数のマルチメディアデータパケッから成るマルチメディアデータパケットストリームを形成するステップと、
前記トランスミッタユニットと前記レシーバユニットとの間のリンクレートに従って前記マルチメディアデータパケットストリームを転送するためのトランスポートスケジュールを生成するステップと、
を備え、
前記マルチメディアデータパケットのそれぞれは、前記リンクレートとデータストリームビットレートとに基づいた固定サイズである、方法。
前記トランスミッタユニットから前記レシーバユニットへ前記マルチメディアデータパケットを伝送するように構成された単方向メインリンクを提供するステップと、
前記トランスミッタユニットと前記レシーバユニットとの間を双方向に情報を転送するように構成された双方向補助リンクを提供するステップと、を更に含む、請求項７記載の方法。
前記双方向補助チャネルは、前記シンクデバイスから前記ソースデバイスへ情報を伝送するように構成された単方向バックチャネルと、前記バックチャネルと協調して前記ソースデバイスから前記シンクデバイスへ情報を伝送するメインチャネルの一部として含まれる単方向フォワードチャネルと、により構成される、請求項８記載の方法。
前記メインリンクユニットは、更に、
前記マルチメディアデータパケットストリームのうちの特定の一つにそれぞれ関連付けられた多数の仮想リンクを備え、
前記仮想リンクのそれぞれは、関連する仮想リンク帯域幅と仮想リンクレートとを有する、請求項９記載の方法。
メインリンク帯域幅が、前記仮想リンク帯域幅の合計に少なくとも等しい、請求項１０記載の方法。
データリンクを経由してデータソースとデータシンクとの間での多数のデータパケットの転送をスケジュールする方法であって、
前記データパケットソースから前記データパケットシンクへデータパケット属性を送信するステップと、
前記ソースから前記シンクへ送信されるべき多数のデータストリームのそれぞれについて、ストリームビットレートをデータリンクビットレートと比較するステップと、
前記比較に基づいて、前記データストリームのそれぞれのパケットサイズを固定パケットサイズに設定するステップと、
各データパケットの少なくとも一つを組み合わせるステップと、
組み合わせたデータパケットを前記ソースから前記シンクへ転送するステップと、
を含む方法。
データリンクを経由してデータソースとデータシンクとの間での多数のデータパケットの転送をスケジュールするコンピュータプログラム製品であって、
前記データパケットソースから前記データパケットシンクへデータパケット属性を送信するコンピュータコードと、
前記ソースから前記シンクへ送信されるべき多数のデータストリームのそれぞれについて、ストリームビットレートをデータリンクビットレートと比較するコンピュータコードと、
前記比較に基づいて、前記データストリームのそれぞれのパケットサイズを固定パケットサイズに設定するコンピュータコードと、
各データパケットの少なくとも一つを組み合わせるコンピュータコードと、
組み合わせたデータパケットを前記ソースから前記シンクへ転送するコンピュータコードと、
前記コードを格納するコンピュータ読取可能な媒体と、
を備えるコンピュータプログラム製品。