"巡回冗長検査CRCチェッカであって、デジタル送信リンクによって受信したデータストリーム内のユニークパターンを検出するユニークパターン検出器と、前記受信したデータストリームに基づいてCRC値を生成するCRCジェネレータと、CRCイニシャライザと、受信したデータストリームに基づいて生成されたCRC値の、前記受信したデータストリーム内で送られたCRC値に対する相違を検出するCRCベリファイヤとを備えるCRCチェッカ。前記CRCイニシャライザは、リンクが初期化されると、前記CRCジェネレータに、前記ユニークパターンを事前入力する請求項1のCRCチェッカ。前記CRCイニシャライザは、前記CRCベリファイヤに、前記ユニークパターンに関連するCRC値を事前入力する請求項1のCRCチェッカ。前記デジタル送信リンクはMDDI送信リンクである請求項1のCRCチェッカ。前記ユニークパターンは、パケット長フィールド、パケットタイプフィールド、及びユニークワードフィールドをサブフレームヘッダパケット内に含む請求項1のCRCチェッカ。デジタル送信リンクを初期化する方法であって、a前記デジタル送信リンクを初期化する要求を受信することと、bユニークなデータパターンに対応するCRC値をCRCジェネレータに事前入力することと、c前記CRCジェネレータをディセーブルすることと、d前記ユニークなデータパターンを検出するために、到来するデータストリームをモニタすることと、e前記ユニークなデータパターンを検出すると、前記CRCジェネレータをイネーブルすることとを備える方法。前記デジタル送信リンクはMDDI送信リンクである請求項5の方法。前記ユニークなデータパターンは、サブフレームヘッダパケットのパケット長フィールド、パケットタイプフィールド、及びユニークワードフィールドを含む請求項6の方法。ホストシステム内の巡回冗長検査CRCジェネレータシステムであって、デジタル送信リンクによって送信されるデータパケットに含まれるデータに基づいてCRC値を生成するCRCジェネレータと、前記CRCジェネレータによって生成されるCRC値を破壊して、ホスト又は関連するシステムステータス情報を伝送するCRCコラプタと、ホストシステム内で誤り条件を検出し、前記CRCコラプタに対してCRC値を故意に破壊するような命令を提供する誤り検出器とを備えるCRCジェネレータシステム。前記CRCコラプタに対して、前記CRCジェネレータによって生成されたCRC値を、システムエラーのタイプ又はステータス条件を示すCRC誤り値と交換するように指示する誤り値ジェネレータを更に備える請求項8のCRCジェネレータシステム。前記デジタル送信リンクはMDDI送信リンクである請求項8のCRCジェネレータシステム。巡回冗長検査CRCチェッカであって、デジタル送信リンクによって受信されたデータパケットのCRCフィールド内で、システム又は関連するシステムエラー条件を識別するCRC誤り値を検出するCRC誤り値検出器と、受信したデータストリームに基づいてCRC値を生成する巡回冗長検査CRCジェネレータと、受信したデータストリームに基づいて生成されたCRC値の、前記受信したデータストリーム内で送られたCRC値に対する相違を検出するCRCベリファイヤとを備える巡回冗長検査CRCチェッカ。前記デジタル送信リンクはMDDI送信リンクである請求項11のCRCチェッカ。デジタル送信リンクによってホストシステムからシステムエラー情報を送信する方法であって、aホストシステム又は関連するシステムエラーを検知することと、b前記デジタル送信リンクによってパケット内で送信されるデータに基づいてCRC値を生成することと、c前記CRC値を破壊することとを備え、前記破壊は、前記ホストシステム又は関連するシステムエラーが発生したことを示す方法。前記デジタル送信リンクによってデータパケット内で前記破壊されたCRCを送信することを更に備える請求項13の方法。前記デジタル送信リンクはMDDIリンクである請求項13の方法。デジタル送信リンクによってホストシステムからシステムエラー情報を送信する方法であって、aホストシステム又は関連するシステムエラーを検出することと、b前記デジタル送信リンクによってパケット内で送信されるデータに基づいてCRC値を生成することと、cステップaで検出されたエラーのタイプに基づいてCRC誤り値を決定することと、dステップbで生成されたCRC値を、ステップcで生成されたCRC誤り値と交換することとを備え、前記CRC誤り値は、前記ホスト又は関連するシステム内での誤り条件の具体的タイプを示す方法。前記CRC値は、前記デジタル送信リンクによってデータパケット内で送信される請求項16の方法。前記デジタル送信リンクはMDDIリンクである請求項16の方法。本発明は、添付図面に関連して記載される。図面では、同一の参照番号が、同一あるいは機能的に類似した要素を示す。要素が最初に現れる図面は、対応する参照番号における最も左の数字によって示される。本明細書は、本発明の特徴を組み込む1又は複数の実施形態を開示する。開示される実施形態は、発明を単に例示している。本発明のスコープは、開示された実施形態に限定されていない。本発明は、添付された特許請求の範囲によって定義される。記載された実施形態、及び1つの実施形態、実施形態、例となる実施形態等に対する明細書中の参照は、記載した実施形態が、具体的な機能、構造、又は特性を含むが、全ての実施形態が、この具体的な機能、構造、又は特性を必ずしも含む必要はないことを示す。更に、これらの表現は、必ずしも同じ実施形態を参照する必要はない。更に、具体的な機能、構造、又は特性が、実施形態に関連して記載される場合、明示的に記載されているか否かに関わらず、そのような機能、構造、又は特性を、他の実施形態について達成することは当業者の知識内であると理解される。本発明の実施形態は、ハードウェア、ファームウェア、ソフトウェア、あるいはそれらの任意の組合せで実現されうる。本発明の実施形態はまた、1又は複数のプロセッサによって読取及び実行可能な計算機読取可能媒体上に格納された命令によっても実現される。計算機読取可能媒体は、例えば、計算デバイスのような計算機によって読取可能な形式で情報を格納又は送信する任意のメカニズムを含みうる。例えば、計算機読取可能媒体は、読取専用メモリROM、ランダムアクセスメモリRAM、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリデバイス、電気、光、音、又は例えば、搬送波、赤外線信号、デジタル信号のような他の形式の伝搬信号、及びその他を含みうる。更に、ファームウェア、ソフトウェア、ルーチン、命令が、ある動作を実行するものとして記載されうる。しかしながら、そのような記載は単に便宜のためであり、実際の動作は、計算デバイス、プロセッサ、コントローラか、あるいはファームウェア、ソフトウェア、ルーチン、命令等を実行するその他のデバイスによってなされることが認識されるべきである。図1は、デジタルデバイス150及び周辺機器180に接続されたデジタルデータデバイスインタフェース100のブロック図である。デジタルデバイス150は、限定される訳ではないが、セルラ電話、パーソナルデータアシスタント、スマートフォン又はパーソナルコンピュータを含むことができる。一般に、デジタルデバイス150は、デジタル表示データの処理及びデジタル命令のための処理ユニットとして役立つ任意のタイプのデジタルデバイスを含むことができる。デジタルデバイス150は、システムコントローラ160及びリンクコントローラ170を含む。周辺機器180は、限定される訳ではないが、カメラ、バーコードリーダ、イメージスキャナ、オーディオデバイス、またセンサを含むことができる。一般に、周辺機器180は、周辺機器と処理ユニットとの間でデジタル表示データを交換することができるオーディオ、ビデオ又はイメージキャプチャ、及びディスプレイデバイスのうちの任意のタイプを含みうる。周辺機器180は、制御ブロック190を含む。例えば、周辺機器180がカメラである場合、制御ブロック190は、限定される訳ではないが、レンズコントロール、フラッシュ又はホワイトLEDコントロール、及びシャッタコントロールを含むことができる。デジタル表示データは、オーディオ、イメージ、及びマルチメディアデータを表わすデジタルデータを含むことができる。デジタルデータインタフェースデバイス100は、通信リンク105を介して、高レートで、デジタル表示データを転送する。一例では、毎秒3.2ギガビットの最大帯域幅で双方向データ転送をサポートするMDDI通信リンクが使用される。この例よりも高い又は低いレートであるその他の高レートデータ転送が、通信リンクに依存してサポートされうる。デジタルデータインタフェースデバイス100は、メッセージ解釈モジュール100、コンテンツモジュール120、制御モジュール130、及びリンクコントローラ140を含む。デジタルデータインタフェース100内に配置されたリンクコントローラ140と、デジタルデバイス150内に配置されたリンクコントローラ170とは、通信リンク105を確立する。リンクコントローラ140及びリンクコントローラ170は、MDDIリンクコントローラでありうる。本明細書において参照によってその全体が組み込まれるVESAVideoElectronicsStandardsAssociationMDDI規格は、ポータブルデバイスに、小型のポータブルデバイスから大型の外部ディスプレイにデジタルイメージを伝送させる高速デジタルパケットインタフェースの要件を記載している。MDDIは、ポータブル計算デバイス、通信デバイス、及びエンタテイメントデバイスを、例えばウェアラブルマイクロディスプレイのような先端製品にリンクするために理想的な薄型フレキシブルケーブル及び小型コネクタシステムを適用する。それはまた、コストを低減し、かつ接続の信頼性を高めるために、ホストプロセッサとディスプレイデバイスとの間の接続をどのように簡素化するかに関する情報をも含む。リンクコントローラ140,170は、VESAMDDI規格に基づいて通信路105を確立する。2004年7月6日にZouらに与えられ、GeneratingandImplementingaCommunicationProtocolandInterfaceforHighDataRateSignalTransfer高速データレート信号伝送のための通信プロトコル及びインタフェースを生成し実施することと題された米国特許6,760,772号’772特許特許文献1は、表示データのための通信プロトコルを形成するためにともにリンクされたパケット構成を用いて、通信路を介してホストとクライアントとの間でデジタルデータを転送するためのデータインタフェースを記載している。前記’772特許で教示された発明の実施形態は、MDDIインタフェースに向けられる。信号プロトコルは、例えばリンクコントローラ140,170のようなリンクコントローラによって用いられ、通信プロトコルを構成するパケットを生成、送信、及び受信するように、かつデジタルデータを、少なくとも1つがホストデバイスに存在し、例えば通信路105のような通信路を介してクライアントに接続されている1又は複数タイプのデータパケットを形成するように構成されている。このインタフェースは、コスト効率が良く、低電力で、双方向性の高速データ伝送メカニズムを、短距離シリアルタイプのデータリンクを介して提供する。これは、小型コネクタ及び薄型フレキシブルケーブルを用いた実装に向いている。リンクコントローラ140,170の実施形態は、’772特許の教示に基づいて通信路105を確立する。’772特許は、本明細書では、参照によって全体が組み入れられる。他の実施形態では、リンクコントローラ140,170は、ともにUSBリンクコントローラになりえる。あるいはそれらはともに、例えばMDDIリンクコントローラのようなコントローラと、例えばUSBリンクコントローラのような別のタイプのリンクコントローラとの組み合わせを含みうる。あるいは、リンクコントローラ140,170は、例えばMDDIリンクコントローラのようなコントローラと、デジタルデータインタフェースデバイス100とデジタルデバイス150との間でアクノレッジメッセージを交換するためのシングルリンクとの組み合わせを含みうる。リンクコントローラ140,170は、更に、例えばイーサネット登録商標あるいはRS-232シリアルポートインタフェースのような別のタイプのインタフェースをサポートすることができる。本明細書での教示に基づいて、関連技術における個々の熟練者によって知られるように、更なるインタフェースもサポートされうる。デジタルデータインタフェースデバイス100内では、メッセージ解釈モジュール110が、通信リンク105を介してコマンドを受信し、システムコントローラ160への応答メッセージを生成する。更に、コマンドメッセージを解釈し、このコマンドの情報コンテンツを、デジタルデータインタフェースデバイス100内の適切なモジュールへ経路付ける。コンテンツモジュール120は、周辺機器180からデータを受信し、このデータを格納し、通信リンク105によってシステムコントローラ160にこのデータを転送する。制御モジュール130は、メッセージ解釈モジュール130から情報を受け取り、この情報を、周辺機器180の制御ブロック190へ経路付ける。また制御モジュール130は、制御ブロック190からも情報を取得して、この情報を、メッセージ解釈モジュール110へ送ることができる。図2は、上部クラムシェル部と下部クラムシェル部とを有するセルラ電話200のブロック図であり、上部クラムシェル部と下部クラムシェル部との間に配置されたコンポーネント間で高速データ通信を提供するためにMDDIインタフェースを用いている。セルラ電話200に関連する以下の記述は、例示的な例を提供し、デジタルデータインタフェースデバイス100の利用を示し、また、その実施及び用途に関連する更なる詳細を与える。この説明に基づいて、例えばパーソナルデジタルアシスタントのような他のデバイスや、他のタイプのモバイル電話とのデジタルデータインタフェース100の使用が明らかになるであろう。そして、それもまた本発明の精神及び範囲内である。図2に示すように、セルラ電話200の下部クラムシェル部202は、モバイル局モデムMSM:MobileStationModemベースバンドチップ204を含む。MSM204は、ディジタルベースバンドコントローラである。セルラ電話200の上部クラムシェル部214は、液晶ディスプレイLCDモジュール216、及びカメラモジュール218を含んでいる。セルラ電話で一般に使用されているように、下部クラムシェル部202と上部クラムシェル部214はともに、プラスチックで覆われている。ヒンジ250,252は、下部クラムシェル202を上部クラムシェル214に機械的に接続する。フレキシブルカップリング254は、下部クラムシェル202と上部クラムシェル214との間の電気的な結合を提供する。MDDIリンク210は、MSM204にカメラモジュール218を接続する。一般に、MDDIリンクコントローラは、カメラモジュール218及びMSM204のそれぞれに対して提供される。セルラ電話200内では、例えば、MDDIホスト222が、カメラモジュール212に接続されたインタフェースシステム230に統合される。一方、MDDIクライアント206は、MDDIリンク210のMSM側に存在する。一般に、MDDIホストは、MDDIリンクのマスタコントローラである。セルラ電話200では、カメラモジュール218からピクセルデータが受信され、MDDIホスト222を用いてインタフェースシステム230によってMDDIパケットにフォーマットされ、その後、MDDIリンク210で送信される。MDDIクライアント206は、MDDIパケットを受信し、それらを、カメラモジュール218によって生成されたものと同じフォーマットのピクセルデータに再変換する。そして、ピクセルデータは、処理のために、MSM204内の適切なブロックに送られる。同様に、MDDIリンク212は、MSM204にLCDモジュール216を接続する。MDDIリンク212は、MSM204に統合されたMDDIホスト208と、LCDモジュール216に接続されたインタフェースシステム232に統合されたMDDIクライアント220とを相互接続する。MSM204のグラフィックコントローラによって生成されたディスプレイデータは、MDDIホスト208によって受信され、そしてMDDIパケットにフォーマットされ、しかる後に、MDDIリンク212で送信される。MDDIクライアント220は、MDDIパケットを受信し、それらをディスプレイデータに再変換し、このディスプレイデータを、LCDモジュール216によって用いられるために、インタフェースシステム232によって処理する。インタフェースステム230,232は、デジタルデータデバイスインタフェース100の異なる実施形態を表わす。インタフェースシステム230の場合には、デジタルデータデバイスインタフェース100要素は、カメラのためのカメラ制御機能、及びカメライメージのデータ転送をサポートするように実装されるであろう。インタフェースシステム232の場合には、デジタルデータデバイスインタフェース100要素は、LCDのための制御機能、及びLCDに対するデータ表示をサポートするように実装されるであろう。インタフェースシステム230は、例えばカメラモジュール218を備えたセルラ電話200のように、カメラを備えたセルラ電話において使用される場合、デジタルデータデバイスインタフェース100の実施形態を例示するために更に説明される。図1におけるデバイスと、セルラ電話200との間の関係は以下の通りである。デジタルデータデバイスインタフェース100は、インタフェースシステム230によって代表される。リンクコントローラ140は、MDDIホスト222によって代表される。周辺機器180は、カメラモジュール218によって代表される。システムコントローラ160は、MSM204によって代表され、リンクコントローラ170は、MDDIクライアント206によって代表される。図3は、上部クラムシェル214のブロック図であり、カメラを備えたセルラ電話内で使用されるデジタルデータデバイスインタフェース100の実施形態を強調するために、インタフェースシステム230に関連する更なる詳細を提供する。インタフェースシステム230は、MDDIホスト222、カメラメッセージインタプリタ302、カメラビデオインタフェース304、I2Cマスタ303、モータ制御308、およびフラッシュ/白LEDタイマ310を含んでいる。I2Cバスは、回路間の通信リンクを提供する、一般に使用される制御バスである。I2Cバスは、1980年代にフィリップスエレクトロニクスN.V.によって開発された。インタフェースシステム230が、デジタルデータデバイスインタフェース100に対応していることを思い出して頂きたい。インタフェースシステム230のコンポーネントは、以下のように、デジタルデータデバイスインタフェース100のコンポーネントに対応している。カメラメッセージインタプリタ302は、メッセージインタプリタモジュール100に対応している。カメラビデオインタフェース304は、コンテンツモジュール120に対応している。まとめると、I2Cマスタ303、モータ制御308、及びフラッシュ/白LEDタイマ310は、制御モジュール130に対応している。カメラメッセージインタプリタ302は、コマンドを受け取り、MDDIホスト222を介してMSM204へと応答メッセージを生成する。カメラメッセージインタプリタ302は、メッセージを解釈し、MDDIカメラインタフェースデバイスとも称されるインタフェースシステム230内の適切なブロックへ情報コンテンツを送る。カメラビデオインタフェース304は、カメラ320からイメージデータを受け取り、このイメージデータを格納し、このイメージデータをMDDIホスト222に転送する。まとめると、I2Cマスタ306、モータ制御308、及びフラッシュ/白LEDタイマ310は、カメラ制御ブロックを形成する。この場合、I2Cマスタ306は、カメラ320を管理するための制御を提供し、モータ制御308は、レンズ322を管理するための制御例えば、レンズズーム機能を提供し、フラッシュ/白LEDタイマ310は、フラッシュ/白LED324を管理するための制御例えば、フラッシュ輝度及び持続時間を提供する。図4Aは、MDDIホスト222のブロック図である。MDDIホスト222は、マイクロプロセッサインタフェース410、コマンドプロセサ420、レジスタ430、ダイレクトメモリアクセスDMAインタフェース440、MDDIパケットビルダ450、データハンドシェークモジュール460、及びデータパッド470を含む。マイクロプロセッサインタフェース410は、バスを用いて、MDDIホスト222を制御するホストプロセッサにインタフェースする。ホストプロセッサは、レジスタを設定し、レジスタを読み取り、MDDIホスト222にコマンドを発行するためにマイクロプロセッサインタフェース410を用いる。マイクロプロセッサインタフェース410は、アドレス値を調べ、MDDIホスト222内の適切なモジュールへデータを渡す。これは、コマンドプロセッサ420への書き込みを渡すことを含む。更にマイクロプロセッサインタフェース410は、レジスタ430内のレジスタ値の読み取り及び書き込みを行う。コマンドプロセッサ420は、ホストプロセッサから受け取ったコマンドを処理する。コマンドは、MDDIリンク210のパワーダウン、MDDIリンク210のパワーアップ、MDDIホスト222の再設定、あるタイプのデータパケットの生成を含む。レジスタ430は、MDDIリンク210を介したデータ送信のためのレジスタを格納する。レジスタ430内のレジスタは、MDDIホスト222のコンフィグレーションと同様に、MDDIリンク210の挙動を制御する。DMAインタフェース440は、外部メモリに対して、MDDIパケットビルダ450用のデータをバッファするためインタフェースシステム230からの情報を受信するように、バースト要求を与える。DMAインタフェース440は、リンクリストノードヘッダのデータを解析し、実際のパケットデータを読むためにポインタを調節する。DMAインタフェース440は、MDDIパケットビルダ450に送り出す次のデータパケットに関する情報を表示する。MDDIパケットビルダ450は、MDDIリンク222に送る必要のある物理パケットを構築することと同様に、どのパケットを次に送るかに関する決定を行う。これらパケットは、内部レジスタ、カウンタ、及びDMAインタフェース440によって取得されたデータから構築される。データが、MDDIリンク222によって出力される場合、出力データは、いくつかのソースから生成されうる。第1のパケットソースは、MDDIパケットビルダ450に対して内部生成された制御タイプパケットである。パケットの例は、サブフレームヘッダパケット、フィルパケット、及びリンクシャットダウンパケットを含む。別のパケットソースは、DMAインタフェース440を介する。これらのパケットは、リンクされたリストを経由して渡されるパケットを含む。他の実施形態では、ビデオデータは、周辺機器がビデオカメラを含んでいる場合、MDDIパケットビルダ450に直接的に渡されうる。パケットソースに関わらず、全てのパケットは、MDDIパケットビルダ450内に存在するCRCジェネレータシステムを通じて処理される。データハンドシェークモジュール460は、物理的MDDIリンク210を管理する。これは、ハンドシェーク処理、データ出力、往復遅延測定及び逆方向データに責任を持つ状態計算機を用いて遂行される。データハンドシェークモジュール460は、MDDIパケットビルダ450からデータを受け取り、このデータを、データパッド470に渡す。データパッド470は、このデータを、MDDIリンク222に転送する。図4Bは、MDDIリンク210に提供されるパケットのフローを例示する。上述したように、パケットは、内部生成され、DMAインタフェース440から受け取られるか、あるいは直接的に受信されたビデオパケットである。内部生成されたパケットは、制御パケットジェネレータ452によって生成される。全てのタイプのパケットが、CRCジェネレータシステム454を介してデータハンドシェークモジュール460へ渡される。一方、データハンドシェークモジュール460は、データパッド470にパケットを提供する。データパッド470は、MDDIリンク210にこのデータを送る。図4Cは、MDDIパケットビルダ450によって、MDDIリンク210を介して受信されるパケットのフローを例示する。この場合、パケットは、データパッド470によってMDDIリンク210から受信され、次に、データハンドシェークモジュール460に渡される。データハンドシェークモジュール460は、このデータを、MDDIパケットビルダ450内のCRCチェッカ456へ渡す。一旦CRCチェッカ456が、到来したパケットのCRCを確認すると、このパケットは、デジタルデータインタフェースデバイス100内での配信のため、プロセッサバスに送られるためにDMAインタフェース440に供給される。パケットタイプの例は、図5及び図6に関して記載される。これらパケットの例は、本発明を例示するために使用されるが、これらのパケットタイプのみに本発明を限定するように意図されない。以下に述べるように、ユニークパターンを用いたその他のパケットタイプ、及びCRCフィールドを、本発明とともに使用することができる。図5は、VESAMDDIインタフェース規格に従ったサブフレームヘッダパケットフォーマット500のブロック図である。サブフレームヘッダパケットフォーマット500は、パケット長フィールド510、パケットタイプ長フィールド520、ユニークワードフィールド530、サブフレームヘッダパラメータフィールド540、及びCRCフィールド550を含む。パケット長フィールド510は、パケット長フィールド510を含まないパケット内の合計バイト数を指定する16ビット2バイト値を含む。パケットタイプフィールド520は、パケットに含まれる情報のタイプを指定する16ビットの無符号整数を含む。ユニークワードフィールド530は、ユニークな16ビットワードを含む。ユニークワードフィールド及びパケットタイプフィールド520の両方は、データを並べるための32ビットのユニークパターンを形成するものと認識される。すなわち、パケットを受信した場合、MDDIパケットビルダ450は、このユニークパターンに基づいて、MDDIパケットビルダ450が処理しているのが、データパケットのどの部位又はフィールドであるかを判定することができる。サブフレームヘッダパラメータフィールド540は、MDDIリンク222を管理するための制御パラメータを含んでいる。CRCフィールドは、16ビットのCRC値を含んでいる。図6は、ビデオストリームパケットフォーマット600のブロック図である。ビデオストリームパケットは、ディスプレイの長方形部分を更新するためにビデオデータを運ぶ。ビデオストリームパケットフォーマット600は、パケット長フィールド610、パケットタイプフィールド615、クライアントIDフィールド620、ビデオフォーマットフィールド625、ピクセルデータ属性フィールド630、X左端フィールド635、Y上端フィールド640、X右端フィールド645、Y下端フィールド650、X開始フィールド655、Y開始フィールド660、ピクセルカウントフィールド665、パラメータCRCフィールド670、ピクセルデータフィールド675、及びピクセルデータCRCフィールド680を含む。パケット長フィールド610は、パケット長フィールド610を含まないパケット内の合計バイト数を指定する16ビット2バイト値を含んでいる。パケットタイプフィールド620は、パケットに含まれている情報のタイプを指定する2バイトの無符号整数を含んでいる。フィールド620乃至665はそれぞれ、ビデオディスプレイがどのようにフォーマットされるかに関するパラメータデータを含む2バイトのフィールドである。これらフィールドの具体的定義は、VESAMDDIインタフェース規格において見つけることができる。パラメータCRCフィールド670は、フィールド610乃至665内のパラメータデータを処理することにより生成されるCRC値を含む2バイトのフィールドである。ピクセルデータフィールド675は、パケットサイズ及びピクセルカウントフィールドで許可された量までの任意のピクセルデータ量を含む。ピクセルCRCフィールド680は、ピクセルデータフィールド675内でピクセルデータを処理することによって生成されるCRC値を含む2バイトフィールドである。MDDIリンク210によって送られる全てのパケットは、サブフレームヘッダパケットフォーマット500内のCRCフィールド550のような少なくとも1つのCRCフィールドを含む。幾つかのより長いパケットでは、パケットは、例えばパラメータCRCフィールド670とピクセルCRCフィールド680とのように、ビデオストリームパケットフォーマット600内に2つのCRCフィールドを含むであろう。CRCは、送信又は格納における誤りを検出するために、例えばネットワークトラフィックパケット、又はコンピュータファイルのブロックのような大きなデータブロックから多くの小さなビットを生成する。CRCは、例えばCRCフィールド550とともに送信又は格納前に送られ追加されるデータの関数として計算され、その後、変化が起きていないことを確認するために検証される。CRCは、パケットデータを、例えばCRCジェネレータシステム454のようなCRCジェネレータを介してプッシュすることによって計算され、パケットデータに関連するユニークなCRC値が生成される。CRCチェッカ456のようなCRCチェッカは、受信データに基づいて、受信データCRC値を生成する。そして、この受信データCRC値は、送られたCRC値と比較される。これら2つが一致すると、データは有効であると考えられ、一致しないと、CRC誤りが生成される。CRCは一般的である。なぜなら、バイナリハードウェア内で実施することが簡単であり、数学的に分析することが容易であり、送信チャネル内の雑音によって引き起こされる一般的な誤りを検出することに特に優れているからである。CRCジェネレータの具体的な実装は、関連技術における個々の熟練者に知られるであろう。図5及び図6に例示するように、CRCフィールドは、パケット内において、パケットの終わり例えば、CRCフィールド512及びピクセルデータCRCフィールド680において、及び時々、著しく大きなデータフィールド例えば、パラメータCRCフィールド670をもつより重要なパラメータの後に現れる。従って、転送中の誤りの確率が増加する。2つのCRCフィールドを持っているパケットでは、1つのみが使用される場合、CRCジェネレータが、最初のCRC後に再び初期化される。これによって、長いデータフィールド後のCRC計算が、パケットの最初におけるパラメータによって影響されなくなる。多くのビット誤りを含むパケットの可能性が低くなり、良好なCRCを生成する。パケットにおける良好なCRCを、誤って検出する確率は、多くの誤りを含む非常に長いパケットについて、7.6×10-6に近づく。設計によって、MDDIリンクは、非常に低いか、ゼロの誤り率を持つであろう。CRCは、リンクの健全性をモニタするために使用されることが意図され、どのパケットが再送信されるべきかを決定するために具体的パケットに関する誤りを検出することは意図されていない。典型的な実施形態では、CRC計算に使用される多項式は、CRC-16、すなわちX16X15X2X0として知られている。本発明を実現するために役立つCRCジェネレータ454及びCRCチェッカ456のサンプル実装が図4Dに示される。図4Dでは、TxMDDIDataBeforeCRCラインに入力されたパケットの最初のビットを転送する直前に、CRCレジスタ471が、値0x0001に初期化され、次に、このパケットのバイトが、LSBから始まるレジスタ内にシフトされる。この図中のレジスタビット番号は、MDDIによって使用されるビット位置ではなく、使用される多項式の順序に対応することに留意されたい。単一方向にCRCレジスタをシフトするのがより効率的であり、その結果、MDDIビット位置14に到達するまで、CRCビット15は、MDDICRCフィールドのビット位置0に、CRCレジスタビット14は、MDDICRCフィールドビット位置1というように現れる。一例として、パケットコンテンツが、0x000c、0x0046、0x000、0x0400、0x00、0x00、0x0000でありあるいは、0x0c、0x00、0x46、0x00、0x00、0x00、0x00、0x04、0x00、0x00、0x00、0x00のようにバイトのシーケンスとして表され、マルチプレクサ472,473及びANDゲート474の入力を用いて出力されるのであれば、結果としてTxMDDIDataWithCRCライン上で得られるCRC出力は、0xd9aaであるあるいは0xaa,0xd9としてシーケンスで表される。CRCジェネレータ454とCRCチェッカ456がCRCチェッカとして構成される場合、RxMDDIDataライン上で受信されるCRCは、マルチプレクサ472及び排他的ORXORゲート476に入力され、NORゲート475、ANDゲート474、及びANDゲート477を用いてCRCレジスタにおいて発見される値と、ビット毎に比較される。誤りがある場合、ANDゲート477による出力として、ゲート477の出力をレジスタ471の入力に接続することによって、CRC誤りを含むパケットについて一度づつCRCがインクリメントされる。図4Dのブロック図内に示す回路の例は、与えられたCHECKCRCNOWウィンドウ図4E参照内で、1よりも多いCRC誤り信号を出力できることに留意されたい。従って、CRC誤りカウンタは、一般に、CHECKCRCNOWがアクティブである各インターバル内で最初のCRC誤りインスタンスのみをカウントする。CRCジェネレータとして構成される場合、CRCは、パケットの終了と一致する時間においてCRCレジスタから計時される。入出力信号及びイネーブル信号のタイミングは、図4E及び図4Fにおいてグラフ的に例示される。CRCの生成、及びデータパケットの送信は、TxMDDIDataBeforeCRC信号及びTxMDDIDataWithCRC信号とともに、GenReset信号、CheckCRCNow信号、GenerateCRCNow信号、及びSendingMDDIData信号の状態0又は1を示す図4Eに示される。データのパケットの受信、及びCRC値のチェックは、RxMDDIData信号及びCRCerror信号とともに、GenReset信号、CheckCRCNow信号、GenerateCRCNow信号、及びSendingMDDIData信号の状態を示す図4Fに示される。パケット内にCRCが存在することは、運用上のチャレンジを示し、また、MDDIリンク210をより効率的に利用するための様々な機会を与える余裕がある。CRCに関する議論の焦点は、MDDIリンク210に関連しているが、本発明は、MDDIコンテンツに限定されない。本発明は、CRCが使用される任意のタイプのデジタルデータ送信リンクに適用されうる。CRCの使用に関連した1つのチャレンジは、リンク初期化に関連する。リンクが確立すると、サブフレームヘッダパケット500のようなサブフレームヘッダパケットが、MDDIホスト222によってMDDIクライアント206へ送られる。リンク初期化時、CRCチェッカ456は、通常、データストリーム内のデータの並びが分からないであろう。すなわち、例えば、CRCチェッカ456は、それがユニークワードフィールド530内の処理データであるか、あるいはCRCフィールド550内の処理データであるか分からないであろう。その結果、CRCチェッカ456は、データストリーム内のどこにあるかを認識するまで、データをメモリに連続的にキューする必要はないであろう。これは、非能率をもたらし、データをキュー及び格納するために使用されるよりも多くのメモリとチップ領域とを必要とする。データストリーム内の正確な位置を知らずに、CRCチェッカ456は、受信データを検証するために受信CRCと比較されるCRCを生成することはできないであろう。図7は、これらのチャレンジに対処するCRCチェッカ456のブロック図である。CRCチェッカ456は、ユニークパターン検出器710、CRCジェネレータ720、CRCイニシャライザ730、及びCRCベリファイヤ740を含む。ユニークパターン検出器710は、到来するデータストリーム内のユニークなパターンを検出し、このデータストリーム内の特定のポイントを識別する。CRCジェネレータ720は、受信データに関連するCRC値を生成するために使用される標準的なCRCジェネレータである。CRCイニシャライザ730は、CRCジェネレータ720に、ユニークパターン及びパケット長に関連するデータ値を送る。CRCベリファイヤ740は、受信データを確認するために、受信CRC値を、受信データに基づいてCRCジェネレータ720によって生成されたCRC値と比較する。図8は、リンク初期化方法800のフローチャートであり、図7に示すようなCRCチェッカ456の使用を実証する。1つのアプローチでは、サブフレームヘッダのパケット長が、常に同一であると仮定され、予め計算された値が、CRCチェッカにロードされる。これは、パケット長、パケットタイプ、及びユニークワードに基づく部分的なCRCである。代替アプローチは、パケット長さが変数である状況をサポートする。この状況では、パケット長が、ユニークパターンとともに、事前計算機を介して送られ、値が生成される。この値は、ユニークパターンが受信された時、このポイントにおいてCRCチェッカ内に配置される。方法800はステップ810で始まる。ステップ810では、送信リンクを初期化又はウェイクアップする要求が受信される。例えば、MDDIクライアント206は、MDDIリンク210を初期化又はウェイクアップする要求を、MDDIホスト222から受信するだろう。MDDIクライアント206内では、CRCチェッカ456は、このリンクウェイクアップ要求によって初期化されうる。特に、CRCイニシャライザ730は、この要求によって初期化されうる。ステップ820では、CRCジェネレータが、ユニークパターン及びパケット長フィールド510に関連するデータ値が予め入力され、ユニークパターン及びパケット長フィールドに関連するCRC値が、CRCジェネレータによって生成される。上述したように、1つの実施形態では、パケット長フィールドは、固定されていると仮定される。例えば、CRCイニシャライザ730は、ユニークパターン及びパケット長フィールドをCRCジェネレータ720に提供することができる。MDDIの場合、このユニークパターンは、パケットタイプフィールド520及びユニークワードフィールド530内に含まれるデータに関連するデータ値である。リンクをウェイクアップすると、これらフィールドの値が、演繹的に知られるだろう。従って、CRCイニシャライザ730は、それらを格納し、ウェイクアップリンク要求が受信された場合にそれらをCRCジェネレータ730に提供する立場にある。代替アプローチでは、CRCジェネレータにデータ値を提供するのではなく、CRCチェッカは、提供されたユニークパターン及びパケット長フィールドを有するCRCジェネレータによって生成され、事前に計算されたCRC値とともに事前にロードされる。ステップ830では、例えばCRCジェネレータ720のようなCRCジェネレータがディセーブルされる。このジェネレータは、更なるデータを処理してCRC値を変更しないように、ユニークパターン及びパケット長フィールドが受信されるまでディセーブルされる。ステップ840では、到来するデータがモニタされ、ユニークデータパターンの受信が確認される。例えば、ユニークパターン検出器710は、MDDIリンク210からの受信データをモニタする。ステップ850では、ユニークパターンが受信されたことが判定される。例えば、ユニークパターン検出器710は、パケット長フィールド510、パケットタイプフィールド520、及びユニークワードフィールド530が受信されたことを判定する。ステップ860では。CRCジェネレータがイネーブルされる。CRCジェネレータ720は、イネーブルされると、事前にロードされたユニークパターンを用いて生成された既存のCRC値に頼るであろう。その結果、CRCジェネレータ720は、データが直ちに並べられ、メモリ内にデータをキューして格納する必要はない。CRCフィールド550に含まれるCRC値を受け取ると、CRCベリファイヤ740は、CRCフィールド550内の値を、CRCジェネレータ720によって生成された値と比較して、CRC誤りが存在するかを判定する。ステップ870では、方法800が終了する。通常、CRC値は、送信リンクに関する問題が、送信中のデータを破壊したかを判定するために使用される。本発明の別の局面では、CRC値は、システムエラー及びステータスに関連する情報を伝えるために使用される。このように、メッセージ内のCRCフィールドは、送信リンク問題と、システムステータス又は誤り情報との両方をサポートするためにより効率的に使用される。本発明の1つの実施形態では、CRCフィールドデータが破壊され、データを送信しているシステムに何か不具合があり、受信中のデータに問題があるかもしれないことが単に示される。例えば、ある場合には、MDDIリンク210を通って進むデータは、破壊されるであろう。なぜなら、MDDIパケットビルダ450に入るデータは、十分速く受信されないからである。たとえ不十分なデータがパケットに利用可能だったとしても、MDDI仕様は、パケットが依然として送られるべきであると記載している。従って、たとえパケットが送られても、データは有効ではないか、あるいは幾分不十分でありうる。この場合、例えばパラメータCRC670又はピクセルデータ680のようなCRC値が故意に破壊され、MDDIクライアント206は、送信されたパケットの完全性を害する何かが起こったことを認識できるようになる。MDDI仕様では、これが、データに問題があることをMDDIクライアント206に通知する方法である。あるいは、誤りを含むパケットの後に、基本的には私が最後に送ったパケットは不完全であると言う別のメッセージが送られる必要がある。MDDIクライアント206は、CRC値が故意に破壊されたパケットを受信すると、このパケットをどのように取り扱うか判断する。アルゴリズムは、故意に破壊されたCRC値を有するパケットを検出し、それをどのようにして取り扱うかを決定するように開発される。あるタイプのパケットについては、MDDIクライアント206は、単に、CRC誤りを記録し、データを使用し続けるかもしれない。一方、他の状況では、MDDIクライアント206は、受信パケットを廃棄し、新しいパケットを要求するかもしれない。例えば、ビデオストリームパケット600のようなビデオパケット内では、ピクセルデータCRC値680が故意に破壊された場合、MDDIクライアント220は、MDDIクライアント220の外部のロジックに、パケットが破壊されていることを通知しないであろう。この場合、受信データは、あらゆる種類の誤り通知を提供する前に、バッファされうる。ビデオデータの全てすなわち、表示される全てのピクセルデータを潜在的にバッファする十分なメモリは存在しない。従って、ピクセルデータは、受信されるとすぐに、ディスプレイに供給される。その結果、ビデオ情報のどこかにCRC誤りがある場合、ビデオ情報の使用を停止するのには遅すぎる。この場合、問題が生じたと記録すること以外に何もなされない。要約すると、故意に破壊されたCRC誤りが、ピクセルデータ内で生じるが、パラメータデータ内には生じないのであれば、MDDIクライアントは、単に、このCRC誤りをエラーカウンタに記録するが、依然として次のピクセルデータを使用する。一方、パラメータCRC値が故意に破壊された場合、MDDIクライアントは、このピクセルデータを使用しないであろう。図9は、CRC値を故意に破壊するメカニズムを提供する巡回冗長ジェネレータシステム454のブロック図である。巡回冗長ジェネレータシステム454は、CRCジェネレータ910、CRCコラプタ920、誤り検出器930、及び誤り値ジェネレータ940を含む。CRCジェネレータ910は、例えば、限定される訳ではないが、MDDIリンク210のようなデジタル送信リンクによって送信されるデータパケットに含まれるデータに基づいてCRC値を生成する。CRCコラプタ920は、ホスト又は遠隔システムステータス情報を運ぶために、CRCジェネレータ910によって生成されたCRC値を破壊する。例えば、インタフェースシステム230が、適切にMDDIパケットを入力するためにMDDIホスト222に十分早くデータを提供できない場合、CRCコラプタ920は、送られたパケットのCRC値を故意に破壊する。誤り検出器930は、例えばMDDIホスト222のようなホストシステム内で誤り条件を検出するか、あるいはインタフェースシステム230から受信した情報に基づいて誤り条件情報を受信し、CRCコラプタ920が、CRC値を故意に破壊するような指示を与える。1つの実施形態では、誤り検出器930は、単に、どこかに不具合があることを検出するが、具体的な誤り条件を判定しない。別の実施形態では、誤り検出器930は、誤り条件の特定のタイプを判定する。後者の実施形態では、誤り検出器930は、誤り値ジェネレータ940に誤りの特徴を伝える。誤り値ジェネレータ940は、CRCコラプタ940に対して、CRCジェネレータ940によって生成されたCRC値を、システムエラー又はステータス条件のタイプを示す具体的な値と交換するように命じる。CRC値を破壊する場合、アルゴリズムは、故意に破壊することが、有効なデータに対応しうるCRC値に至らず、もって、送信リンクの受信端において、CRCチェッカによってユニークなCRC値として受信されないことを保証するようにアルゴリズムが選択されねばならない。1つの可能なアルゴリズムは、有効なデータによって生成されないCRC値を識別し、かつこれらの値を、CRC値を故意に破壊するためのユニークな値として使用することであろう。本明細書の教示に基づいて、関連技術における個々の熟練者は、本発明の精神及び範囲内に含まれる他のアルゴリズムを決定するであろう。図10は、CRCジェネレータシステム454からの故意に破壊されたCRC値を解釈することができるCRCチェッカ456のブロック図である。CRCチェッカ456は、CRC誤り値検出器1010、CRCジェネレータ1020、及びCRCベリファイヤ1030を含む。CRC誤り値検出器1010は、デジタル送信リンクによって受信されたデータパケットのCRCフィールド内の値を検出する。CRC誤り値検出器1010は、CRC値が、システムエラー条件を識別する故意に破壊されたCRC値に一致する場合を識別する。CRC値が、システムエラー条件に一致すると判定された場合、CRC誤り値検出器1010は、ホストプロセッサに、例えばMDDIクライアント206のような受信クライアントを通知する。ホストプロセッサは、検出された誤りのタイプに基づいて動作を講じるであろう。CRCジェネレータ1020は、受信されたデータストリームに基づいてCRC値を生成する。CRCベリファイヤ1030は、受信されたデータストリームに基づいて生成されたCRC値の、受信されたデータストリーム内で送られたCRC値に対する相違を検出する。CRCジェネレータ1020及びCRCベリファイヤ1030は、関連技術における個々の熟練者によって知られる従来方式で動作する。図11は、CRC値を故意に破壊することによって、デジタル送信リンクを介してシステムエラー情報を送信する方法1100のフローチャートである。方法1100は、ステップ1110で始まる。ステップ1110では、ホストシステムあるいは関連システム内で誤りが検出される。例えば、誤り検出器930は、MDDIホスト222あるいはインタフェースシステム230内で誤りを検出する。ステップ1120では、CRC値が生成される。例えば、CRCジェネレータ910は、送られるパケットに関連したデータに対してCRC値を生成する。ステップ1130では、CRC値が破壊される。例えば、誤り検出器930は、CRC値を破壊するようにCRCコラプタ920に命じる。ステップ1140で、方法1100は終了する。方法1100は、MDDIを含むシステムに関して記述されているが、方法1100は、CRCが使用されるあらゆるデジタル通信システムに適用可能であることに留意されたい。本発明では、CRCフィールドは、誤りのタイプを表わす誤り符号情報を送信するために使用されてもよい。データパケットとCRCのみがホストとクライアントとの間で転送されている場合は常に、誤り符号は提供されていない。唯一の誤りは同期の損失である。そうでない場合、良好なデータ転送経路又はパイプラインの欠如によりリンクがタイムアウトになることを待ち、リンクをリセットし、続けなければならない。あいにく、これは、時間を浪費し、幾分非能率的である。1つの実施形態での使用のために、新しい技術が開発された。そこでは、パケットのCRC部が、誤り符号情報を転送するために使用される。すなわち、1又は複数の誤り符号が、データ転送を取り扱うプロセッサ又はデバイスによって生成される。これは、通信処理又はリンク内で発生しうる特定の予め定義された誤り又は欠陥を示す。誤りに遭遇する場合、適切な誤り符号が生成され、パケットのCRCのビットを用いて転送される。すなわち、所望の誤り符号を用いてCRC値がオーバロード又はオーバライトされる。これは、CRCフィールドの値をモニタする誤りモニタ又はチェッカによって受信端上で検出される。幾つかの理由で、誤り符号がCRC値と一致する場合、混乱を避けるために、誤りのコンプリメントが転送される。1つの実施形態では、ロバストな誤り警告及び検出システムを提供するために、誤り符号は、一般に全てである一連のパケットを用いて、数回転送される。これは、誤りが検出された後に転送又は送信される。これは、誤りを生成する条件が、システムから取り除かれるポイントまで生じる。このポイントでは、規則的なCRCビットが、別の値によってオーバロードされることなく転送される。CRC値をオーバロードするこの技術は、最小量の追加ビット又はフィールドを用いながら、より迅速な応答をシステムエラーに提供する。図12に示すように、CRCオーバライトメカニズム又は装置1200が、例えば誤り検出器930のような誤り検出器又は検出手段1202を用いて示されている。これは、以前に説明したか、あるいは周知の他の回路の一部を形成することができ、通信リンク又はプロセス内の誤りの存在又は実在を検出する。例えば誤り値ジェネレータ940のように、他の回路の一部として構成されることができるか、あるいは、例えば予め選択されたエラーメッセージを格納するためのルックアップテーブルのような技術を使用する誤り符号ジェネレータ又は手段1204は、特定の予め定めた誤りであるか、あるいは引き起こったものとして検出された欠陥を示すために1又は複数の誤り符合を生成する。デバイス1202,1204は、単一の回路又は所望されるデバイスとして、あるいは、他の周知のプロセッサ及び素子のためにプログラムされたステップのシーケンスの一部として形成することができることが容易に理解される。例えばCRCベリファイヤ1030のように、選択された誤り符号が、転送されたCRC値と同じであるかを確認するCRC値コンパレータ又は比較手段1206が示されている。その場合、オリジナルのCRCパターン又は値として誤解され、検出スキームを混乱させたり、又は複雑にすることがないように、符号コンプリメントジェネレータ又は生成手段又はデバイスが、誤り符合のコンプリメントを提供するために使用される。誤り符合セレクタ又は選択手段要素又はデバイス1210は、その後、挿入又はオーバライトが望まれる誤り符合又は値、あるいは適切なコンプリメントを選択する。例えばCRCコラプタ920のような誤り符合CRCオーバライタ、又はオーバライトメカニズム、又は手段1212は、所望の誤り符号を受信デバイスへ転送するために、データストリーム、パケット、及び挿入される所望の符号を受信し、対応するCRC値又は適切なCRC値をオーバライトするデバイスである。既に述べたように、誤り符合は、一連のパケットを用いて何度も転送されるので、オーバライタ1212は、処理中、符号のコピーを保持するために、あるいは、必要に応じて又は所望に応じて値を記憶又は保持するために使用することが可能な前の素子又は他の周知の記憶場所から符号を呼び戻すために、メモリ記憶素子を利用しうる。図12のオーバライトメカニズムの一般的な処理の追加詳細が、図13及び図14に示されるように実施される。図13では、ステップ1302において、通信データ又はプロセスにおいて、1又は複数の誤りが検出され、ステップ1304において、誤り符号が選択され、この条件が示される。ステップ1306では、それと同時に、あるいは適切なポイントにおいて、交換されるCRC値がチェックされ、ステップ1308において、所望の誤り符号と比較される。この比較の結果は、以前説明したように、所望の符号、あるいはその他の代表値が、現在のCRC値と同じであるか否かの判定である。この場合、処理はステップ1312に進む。ここでは、コンプリメント、又は幾つかの場合には、所望に応じてその他の代表値が、挿入される符号として選択される。ステップ1310及び1314では、どの誤り符合又は値が挿入されるべきかが決定されると、その適切な符号が、挿入のために選択される。これらのステップは、明瞭さの目的のために個別に例示されているが、一般に、ステップ1308の判定に基づく単一の選択を表す。最後に、ステップ1316において、この処理のターゲットとされているパケットを用いて転送するために、適切な値がCRC位置にオーバライトされる。パケット受信側では、図14に示すように、パケットCRC値が、ステップ1422においてモニタされる。一般に、CRC値は、データ転送中に誤りが発生したか、パケットの再送信を要求するか否かを判定するために、あるいは上述したもののうちの幾つかのような更なる動作を禁止するために、システム内で、1又は複数の処理とともにモニタされている。そのようなモニタリングの一部として、この情報はまた、値を、既知又は予め選択された誤り符号、あるいは代表値と比較し、誤りの存在を検出するためにも使用される。あるいは、個別の誤り検出処理およびモニタを実施することができる。符号が存在するように思われる場合、ステップ1424では、更なる処理のために抽出されるか、そうでない場合には注釈が付けられる。ステップ1426では、これが実際の符号であるか、あるいはコンプリメントであるかの判定がなされる。コンプリメントである場合には、追加ステップ1428が使用され、この値が、所望の符号値に変換される。何れの場合も、ステップ1430では、結果として抽出された符合、コンプリメント、又はその他の復元された値は、送信された符号から、どの誤りが生じたのかを検出するために使用される。結論本発明の典型的な実施形態が示された。本発明は、これらの例に限定されない。これらの例は、本明細書において、例示目的で表されており、限定のために表されているのではない。本明細書に含まれる教示に基づいて、代替例本明細書の記載の等価物、拡張、変形、変更等が、関連技術における熟練者に明らかになるであろう。そのような代替例は、本発明の範囲及び精神内にある。本明細書で述べられた全ての出版物、特許、及び特許出願は、本発明が関連する技術における熟練者の熟練レベルを示しており、あたかも個々の出版物、特許、又は特許出願が、参照によって特別に及び個別に組み込まれていることが示されているかのように、同程度に参照によって本明細書に組み込まれている。"