JP5038148B2 - 巡回冗長検査を実行するためのシステム及び方法 - Google Patents

Description

本発明は、一般に、データ通信に関する。更に詳しくは、本発明は、巡回冗長検査を使用するデジタル送信リンクに関する。

コンピュータ、モバイル電話、モバイル電話カメラ及びビデオキャプチャデバイス、パーソナルデジタルアシスタント、電子ゲーム関連製品及び様々なビデオ技術（例えば、ＤＶＤおよび高解像度ＶＣＲ）は、ますますより高い解像度の静止、ビデオ、ビデオオンデマンド、及びグラフィックイメージのキャプチャ及び表示のために、ここ数年の間に著しく進化した。そのようなビジュアルイメージを、例えばＣＤタイプの音再生、ＤＶＤ、及び関連するオーディオ信号出力を有するその他のデバイスのような高品質オーディオデータと組み合わせることによって、より現実的で、内容が豊富な、すなわちエンドユーザに対する真のマルチメディア体験を生み出す。更に、ユーザに対してオーディオのみを提供するために、例えばＭＰ３プレーヤのように高いモバイル性の高品質なサウンドシステムや、音楽転送機構が開発された。

高品質データ表示の進化によって、データ品質が低下したり害されることなく、高データレートでのデータ転送が可能な専用インタフェースを確立する必要性が生じた。そのような１つのインタフェースは、モバイルディスプレイデジタルインタフェース（ＭＤＤＩ）であり、例えば、カメラを有するセルラ電話の下部クラムシェルと上部クラムシェルとの間での高速データ交換のために使用される。ＭＤＤＩは、コスト効率が良く、低電力消費であり、ホストとクライアントとの間の短距離通信リンクによる超高速データ転送を可能にする転送メカニズムである。ＭＤＤＩは、最低でも、４本のワイヤと、双方向データ転送のための電力を必要とし、現在の技術では、毎秒最大３．２ギガビットの最大帯域幅を配信することができる。

ＭＤＤＩ及びその他のデータインタフェースは、インタフェースを介して高速なデータレートを効率的に提供することができるが、パフォーマンスを最適化し、かつ例えばＭＤＤＩリンクのようなデジタル送信リンクを効率的に使用するニーズが高まっている。
米国特許６，７６０，７７２号

本発明は、リンク初期化処理の改善、及びシステムエラー情報の交換のために、巡回冗長検査（ＣＲＣ）を実施するシステム及び方法を提供し、これによって、デジタル送信リンクがより効率的に利用できるようになる。本発明の１つの局面では、ユニークパターン検出器、ＣＲＣジェネレータ、ＣＲＣイニシャライザ、及びＣＲＣベリファイヤを含む巡回冗長検査（ＣＲＣ）チェッカが提供される。ＣＲＣチェッカは、ユニークパターンのためにＣＲＣジェネレータを予め実装する。ＣＲＣジェネレータが予め実装されるので、デジタル送信リンクによって受信されたデータストリーム内のユニークパターンを取得すると、ＣＲＣチェッカは、データをキュー及び格納する必要なくＣＲＣのチェックを進める。

本発明の別の局面では、システムエラー情報又は関連するシステムエラー情報を送信するためにＣＲＣ値を故意に破壊する（corrupt)ＣＲＣジェネレータシステムが提供される。このＣＲＣジェネレータシステムは、ＣＲＣジェネレータ、ＣＲＣコラプタ（corrupter）、誤り検出器、及び誤り値ジェネレータを含んでいる。ＣＲＣジェネレータは、デジタル送信リンクによって送信されるデータパケットに含まれるデータに基づいてＣＲＣ値を生成する。ＣＲＣコラプタは、ホスト又は関連するシステムステータス情報を伝送するために、ＣＲＣジェネレータによって生成されるＣＲＣ値を破壊（corrupt）する。誤り検出器は、ホスト又は関連するシステム内での誤り条件を検出し、ＣＲＣコラプタに対して、ＣＲＣ値を故意に破壊するように指示を与える。

本発明の更なる局面では、ＣＲＣジェネレータシステムは、含まれている誤りのタイプに関する具体的な情報を提供することができる。この場合、上記の要素に加えて、ＣＲＣジェネレータシステムは、ＣＲＣジェネレータによって生成されたＣＲＣ値を、システムエラーのタイプ又はステータス条件を示す具体的なＣＲＣ誤り値と交換するようにＣＲＣコラプタに指示する。

一例では、デジタル送信リンクはＭＤＤＩリンクである。本発明は、ＭＤＤＩリンクに限定されず、ＣＲＣが使用されるあらゆるタイプのデジタル送信リンクとともに使用することができる。

本発明の更なる実施形態、特徴、及び利点は、本発明の様々な実施形態の構造及び動作と同様に、添付図面を参照して以下に詳細に記載されている。

本発明は、添付図面に関連して記載される。図面では、同一の参照番号が、同一あるいは機能的に類似した要素を示す。要素が最初に現れる図面は、対応する参照番号における最も左の数字によって示される。

本明細書は、本発明の特徴を組み込む１又は複数の実施形態を開示する。開示される実施形態は、発明を単に例示している。本発明のスコープは、開示された実施形態に限定されていない。本発明は、添付された特許請求の範囲によって定義される。

記載された実施形態、及び「１つの実施形態」、「実施形態」、「例となる実施形態」等に対する明細書中の参照は、記載した実施形態が、具体的な機能、構造、又は特性を含むが、全ての実施形態が、この具体的な機能、構造、又は特性を必ずしも含む必要はないことを示す。更に、これらの表現は、必ずしも同じ実施形態を参照する必要はない。更に、具体的な機能、構造、又は特性が、実施形態に関連して記載される場合、明示的に記載されているか否かに関わらず、そのような機能、構造、又は特性を、他の実施形態について達成することは当業者の知識内であると理解される。

本発明の実施形態は、ハードウェア、ファームウェア、ソフトウェア、あるいはそれらの任意の組合せで実現されうる。本発明の実施形態はまた、１又は複数のプロセッサによって読取及び実行可能な計算機読取可能媒体上に格納された命令によっても実現される。計算機読取可能媒体は、（例えば、計算デバイスのような）計算機によって読取可能な形式で情報を格納又は送信する任意のメカニズムを含みうる。例えば、計算機読取可能媒体は、読取専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリデバイス、電気、光、音、又は（例えば、搬送波、赤外線信号、デジタル信号のような）他の形式の伝搬信号、及びその他を含みうる。更に、ファームウェア、ソフトウェア、ルーチン、命令が、ある動作を実行するものとして記載されうる。しかしながら、そのような記載は単に便宜のためであり、実際の動作は、計算デバイス、プロセッサ、コントローラか、あるいはファームウェア、ソフトウェア、ルーチン、命令等を実行するその他のデバイスによってなされることが認識されるべきである。

図１は、デジタルデバイス１５０及び周辺機器１８０に接続されたデジタルデータデバイスインタフェース１００のブロック図である。デジタルデバイス１５０は、限定される訳ではないが、セルラ電話、パーソナルデータアシスタント、スマートフォン又はパーソナルコンピュータを含むことができる。一般に、デジタルデバイス１５０は、デジタル表示データの処理及びデジタル命令のための処理ユニットとして役立つ任意のタイプのデジタルデバイスを含むことができる。デジタルデバイス１５０は、システムコントローラ１６０及びリンクコントローラ１７０を含む。

周辺機器１８０は、限定される訳ではないが、カメラ、バーコードリーダ、イメージスキャナ、オーディオデバイス、またセンサを含むことができる。一般に、周辺機器１８０は、周辺機器と処理ユニットとの間でデジタル表示データを交換することができるオーディオ、ビデオ又はイメージキャプチャ、及びディスプレイデバイスのうちの任意のタイプを含みうる。周辺機器１８０は、制御ブロック１９０を含む。例えば、周辺機器１８０がカメラである場合、制御ブロック１９０は、限定される訳ではないが、レンズコントロール、フラッシュ又はホワイトＬＥＤコントロール、及びシャッタコントロールを含むことができる。デジタル表示データは、オーディオ、イメージ、及びマルチメディアデータを表わすデジタルデータを含むことができる。

デジタルデータインタフェースデバイス１００は、通信リンク１０５を介して、高レートで、デジタル表示データを転送する。一例では、毎秒３．２ギガビットの最大帯域幅で双方向データ転送をサポートするＭＤＤＩ通信リンクが使用される。この例よりも高い又は低いレートであるその他の高レートデータ転送が、通信リンクに依存してサポートされうる。デジタルデータインタフェースデバイス１００は、メッセージ解釈モジュール１００、コンテンツモジュール１２０、制御モジュール１３０、及びリンクコントローラ１４０を含む。

デジタルデータインタフェース１００内に配置されたリンクコントローラ１４０と、デジタルデバイス１５０内に配置されたリンクコントローラ１７０とは、通信リンク１０５を確立する。リンクコントローラ１４０及びリンクコントローラ１７０は、ＭＤＤＩリンクコントローラでありうる。

本明細書において参照によってその全体が組み込まれるＶＥＳＡ（Video Electronics Standards Association）ＭＤＤＩ規格は、ポータブルデバイスに、小型のポータブルデバイスから大型の外部ディスプレイにデジタルイメージを伝送させる高速デジタルパケットインタフェースの要件を記載している。ＭＤＤＩは、ポータブル計算デバイス、通信デバイス、及びエンタテイメントデバイスを、例えばウェアラブルマイクロディスプレイのような先端製品にリンクするために理想的な薄型フレキシブルケーブル及び小型コネクタシステムを適用する。それはまた、コストを低減し、かつ接続の信頼性を高めるために、ホストプロセッサとディスプレイデバイスとの間の接続をどのように簡素化するかに関する情報をも含む。リンクコントローラ１４０，１７０は、ＶＥＳＡ ＭＤＤＩ規格に基づいて通信路１０５を確立する。

２００４年７月６日にＺｏｕらに与えられ、Generating and Implementing a Communication Protocol and Interface for High Data Rate Signal Transfer（高速データレート信号伝送のための通信プロトコル及びインタフェースを生成し実施すること）と題された米国特許６，７６０，７７２号（’７７２特許）（特許文献１）は、表示データのための通信プロトコルを形成するためにともにリンクされたパケット構成を用いて、通信路を介してホストとクライアントとの間でデジタルデータを転送するためのデータインタフェースを記載している。前記’７７２特許で教示された発明の実施形態は、ＭＤＤＩインタフェースに向けられる。信号プロトコルは、例えばリンクコントローラ１４０，１７０のようなリンクコントローラによって用いられ、通信プロトコルを構成するパケットを生成、送信、及び受信するように、かつデジタルデータを、少なくとも１つがホストデバイスに存在し、例えば通信路１０５のような通信路を介してクライアントに接続されている１又は複数タイプのデータパケットを形成するように構成されている。

このインタフェースは、コスト効率が良く、低電力で、双方向性の高速データ伝送メカニズムを、短距離「シリアル」タイプのデータリンクを介して提供する。これは、小型コネクタ及び薄型フレキシブルケーブルを用いた実装に向いている。リンクコントローラ１４０，１７０の実施形態は、’７７２特許の教示に基づいて通信路１０５を確立する。’７７２特許は、本明細書では、参照によって全体が組み入れられる。

他の実施形態では、リンクコントローラ１４０，１７０は、ともにＵＳＢリンクコントローラになりえる。あるいはそれらはともに、例えばＭＤＤＩリンクコントローラのようなコントローラと、例えばＵＳＢリンクコントローラのような別のタイプのリンクコントローラとの組み合わせを含みうる。あるいは、リンクコントローラ１４０，１７０は、例えばＭＤＤＩリンクコントローラのようなコントローラと、デジタルデータインタフェースデバイス１００とデジタルデバイス１５０との間でアクノレッジメッセージを交換するためのシングルリンクとの組み合わせを含みうる。リンクコントローラ１４０，１７０は、更に、例えばイーサネット（登録商標）あるいはＲＳ−２３２シリアルポートインタフェースのような別のタイプのインタフェースをサポートすることができる。本明細書での教示に基づいて、関連技術における個々の熟練者によって知られるように、更なるインタフェースもサポートされうる。

デジタルデータインタフェースデバイス１００内では、メッセージ解釈モジュール１１０が、通信リンク１０５を介してコマンドを受信し、システムコントローラ１６０への応答メッセージを生成する。更に、コマンドメッセージを解釈し、このコマンドの情報コンテンツを、デジタルデータインタフェースデバイス１００内の適切なモジュールへ経路付ける。

コンテンツモジュール１２０は、周辺機器１８０からデータを受信し、このデータを格納し、通信リンク１０５によってシステムコントローラ１６０にこのデータを転送する。

制御モジュール１３０は、メッセージ解釈モジュール１３０から情報を受け取り、この情報を、周辺機器１８０の制御ブロック１９０へ経路付ける。また制御モジュール１３０は、制御ブロック１９０からも情報を取得して、この情報を、メッセージ解釈モジュール１１０へ送ることができる。

図２は、上部クラムシェル部と下部クラムシェル部とを有するセルラ電話２００のブロック図であり、上部クラムシェル部と下部クラムシェル部との間に配置されたコンポーネント間で高速データ通信を提供するためにＭＤＤＩインタフェースを用いている。セルラ電話２００に関連する以下の記述は、例示的な例を提供し、デジタルデータインタフェースデバイス１００の利用を示し、また、その実施及び用途に関連する更なる詳細を与える。この説明に基づいて、例えばパーソナルデジタルアシスタントのような他のデバイスや、他のタイプのモバイル電話とのデジタルデータインタフェース１００の使用が明らかになるであろう。そして、それもまた本発明の精神及び範囲内である。

図２に示すように、セルラ電話２００の下部クラムシェル部２０２は、モバイル局モデム（ＭＳＭ：Mobile Station Modem）ベースバンドチップ２０４を含む。ＭＳＭ２０４は、ディジタルベースバンドコントローラである。セルラ電話２００の上部クラムシェル部２１４は、液晶ディスプレイ（ＬＣＤ）モジュール２１６、及びカメラモジュール２１８を含んでいる。セルラ電話で一般に使用されているように、下部クラムシェル部２０２と上部クラムシェル部２１４はともに、プラスチックで覆われている。ヒンジ２５０，２５２は、下部クラムシェル２０２を上部クラムシェル２１４に機械的に接続する。フレキシブルカップリング２５４は、下部クラムシェル２０２と上部クラムシェル２１４との間の電気的な結合を提供する。

ＭＤＤＩリンク２１０は、ＭＳＭ２０４にカメラモジュール２１８を接続する。一般に、ＭＤＤＩリンクコントローラは、カメラモジュール２１８及びＭＳＭ２０４のそれぞれに対して提供される。セルラ電話２００内では、例えば、ＭＤＤＩホスト２２２が、カメラモジュール２１２に接続されたインタフェースシステム２３０に統合される。一方、ＭＤＤＩクライアント２０６は、ＭＤＤＩリンク２１０のＭＳＭ側に存在する。一般に、ＭＤＤＩホストは、ＭＤＤＩリンクのマスタコントローラである。

セルラ電話２００では、カメラモジュール２１８からピクセルデータが受信され、ＭＤＤＩホスト２２２を用いてインタフェースシステム２３０によってＭＤＤＩパケットにフォーマットされ、その後、ＭＤＤＩリンク２１０で送信される。ＭＤＤＩクライアント２０６は、ＭＤＤＩパケットを受信し、それらを、カメラモジュール２１８によって生成されたものと同じフォーマットのピクセルデータに再変換する。そして、ピクセルデータは、処理のために、ＭＳＭ２０４内の適切なブロックに送られる。

同様に、ＭＤＤＩリンク２１２は、ＭＳＭ２０４にＬＣＤモジュール２１６を接続する。ＭＤＤＩリンク２１２は、ＭＳＭ２０４に統合されたＭＤＤＩホスト２０８と、ＬＣＤモジュール２１６に接続されたインタフェースシステム２３２に統合されたＭＤＤＩクライアント２２０とを相互接続する。ＭＳＭ２０４のグラフィックコントローラによって生成されたディスプレイデータは、ＭＤＤＩホスト２０８によって受信され、そしてＭＤＤＩパケットにフォーマットされ、しかる後に、ＭＤＤＩリンク２１２で送信される。ＭＤＤＩクライアント２２０は、ＭＤＤＩパケットを受信し、それらをディスプレイデータに再変換し、このディスプレイデータを、ＬＣＤモジュール２１６によって用いられるために、インタフェースシステム２３２によって処理する。

インタフェースステム２３０，２３２は、デジタルデータデバイスインタフェース１００の異なる実施形態を表わす。インタフェースシステム２３０の場合には、デジタルデータデバイスインタフェース１００要素は、カメラのためのカメラ制御機能、及びカメライメージのデータ転送をサポートするように実装されるであろう。インタフェースシステム２３２の場合には、デジタルデータデバイスインタフェース１００要素は、ＬＣＤのための制御機能、及びＬＣＤに対するデータ表示をサポートするように実装されるであろう。インタフェースシステム２３０は、例えばカメラモジュール２１８を備えたセルラ電話２００のように、カメラを備えたセルラ電話において使用される場合、デジタルデータデバイスインタフェース１００の実施形態を例示するために更に説明される。

図１におけるデバイスと、セルラ電話２００との間の関係は以下の通りである。デジタルデータデバイスインタフェース１００は、インタフェースシステム２３０によって代表される。リンクコントローラ１４０は、ＭＤＤＩホスト２２２によって代表される。周辺機器１８０は、カメラモジュール２１８によって代表される。システムコントローラ１６０は、ＭＳＭ２０４によって代表され、リンクコントローラ１７０は、ＭＤＤＩクライアント２０６によって代表される。

図３は、上部クラムシェル２１４のブロック図であり、カメラを備えたセルラ電話内で使用されるデジタルデータデバイスインタフェース１００の実施形態を強調するために、インタフェースシステム２３０に関連する更なる詳細を提供する。インタフェースシステム２３０は、ＭＤＤＩホスト２２２、カメラメッセージインタプリタ３０２、カメラビデオインタフェース３０４、Ｉ２Ｃマスタ３０３、モータ制御３０８、およびフラッシュ／白ＬＥＤタイマ３１０を含んでいる。Ｉ２Ｃバスは、回路間の通信リンクを提供する、一般に使用される制御バスである。Ｉ２Ｃバスは、１９８０年代にフィリップスエレクトロニクスＮ．Ｖ．によって開発された。

インタフェースシステム２３０が、デジタルデータデバイスインタフェース１００に対応していることを思い出して頂きたい。インタフェースシステム２３０のコンポーネントは、以下のように、デジタルデータデバイスインタフェース１００のコンポーネントに対応している。カメラメッセージインタプリタ３０２は、メッセージインタプリタモジュール１００に対応している。カメラビデオインタフェース３０４は、コンテンツモジュール１２０に対応している。まとめると、Ｉ２Ｃマスタ３０３、モータ制御３０８、及びフラッシュ／白ＬＥＤタイマ３１０は、制御モジュール１３０に対応している。

カメラメッセージインタプリタ３０２は、コマンドを受け取り、ＭＤＤＩホスト２２２を介してＭＳＭ２０４へと応答メッセージを生成する。カメラメッセージインタプリタ３０２は、メッセージを解釈し、ＭＤＤＩカメラインタフェースデバイスとも称されるインタフェースシステム２３０内の適切なブロックへ情報コンテンツを送る。カメラビデオインタフェース３０４は、カメラ３２０からイメージデータを受け取り、このイメージデータを格納し、このイメージデータをＭＤＤＩホスト２２２に転送する。まとめると、Ｉ２Ｃマスタ３０６、モータ制御３０８、及びフラッシュ／白ＬＥＤタイマ３１０は、カメラ制御ブロックを形成する。この場合、Ｉ２Ｃマスタ３０６は、カメラ３２０を管理するための制御を提供し、モータ制御３０８は、レンズ３２２を管理するための制御（例えば、レンズズーム機能）を提供し、フラッシュ／白ＬＥＤタイマ３１０は、フラッシュ／白ＬＥＤ３２４を管理するための制御（例えば、フラッシュ輝度及び持続時間）を提供する。

図４Ａは、ＭＤＤＩホスト２２２のブロック図である。ＭＤＤＩホスト２２２は、マイクロプロセッサインタフェース４１０、コマンドプロセサ４２０、レジスタ４３０、ダイレクトメモリアクセス（ＤＭＡ）インタフェース４４０、ＭＤＤＩパケットビルダ４５０、データハンドシェークモジュール４６０、及びデータパッド４７０を含む。マイクロプロセッサインタフェース４１０は、バスを用いて、ＭＤＤＩホスト２２２を制御するホストプロセッサにインタフェースする。ホストプロセッサは、レジスタを設定し、レジスタを読み取り、ＭＤＤＩホスト２２２にコマンドを発行するためにマイクロプロセッサインタフェース４１０を用いる。マイクロプロセッサインタフェース４１０は、アドレス値を調べ、ＭＤＤＩホスト２２２内の適切なモジュールへデータを渡す。これは、コマンドプロセッサ４２０への書き込みを渡すことを含む。更にマイクロプロセッサインタフェース４１０は、レジスタ４３０内のレジスタ値の読み取り及び書き込みを行う。

コマンドプロセッサ４２０は、ホストプロセッサから受け取ったコマンドを処理する。コマンドは、ＭＤＤＩリンク２１０のパワーダウン、ＭＤＤＩリンク２１０のパワーアップ、ＭＤＤＩホスト２２２の再設定、あるタイプのデータパケットの生成を含む。

レジスタ４３０は、ＭＤＤＩリンク２１０を介したデータ送信のためのレジスタを格納する。レジスタ４３０内のレジスタは、ＭＤＤＩホスト２２２のコンフィグレーションと同様に、ＭＤＤＩリンク２１０の挙動を制御する。

ＤＭＡインタフェース４４０は、外部メモリに対して、ＭＤＤＩパケットビルダ４５０用のデータをバッファするためインタフェースシステム２３０からの情報を受信するように、バースト要求を与える。ＤＭＡインタフェース４４０は、リンクリストノードヘッダのデータを解析し、実際のパケットデータを読むためにポインタを調節する。ＤＭＡインタフェース４４０は、ＭＤＤＩパケットビルダ４５０に送り出す次のデータパケットに関する情報を表示する。

ＭＤＤＩパケットビルダ４５０は、ＭＤＤＩリンク２２２に送る必要のある物理パケットを構築することと同様に、どのパケットを次に送るかに関する決定を行う。これらパケットは、内部レジスタ、カウンタ、及びＤＭＡインタフェース４４０によって取得されたデータから構築される。データが、ＭＤＤＩリンク２２２によって出力される場合、出力データは、いくつかのソースから生成されうる。第１のパケットソースは、ＭＤＤＩパケットビルダ４５０に対して内部生成された制御タイプパケットである。パケットの例は、サブフレームヘッダパケット、フィルパケット、及びリンクシャットダウンパケットを含む。別のパケットソースは、ＤＭＡインタフェース４４０を介する。これらのパケットは、リンクされたリストを経由して渡されるパケットを含む。他の実施形態では、ビデオデータは、周辺機器がビデオカメラを含んでいる場合、ＭＤＤＩパケットビルダ４５０に直接的に渡されうる。パケットソースに関わらず、全てのパケットは、ＭＤＤＩパケットビルダ４５０内に存在するＣＲＣジェネレータシステムを通じて処理される。

データハンドシェークモジュール４６０は、物理的ＭＤＤＩリンク２１０を管理する。これは、ハンドシェーク処理、データ出力、往復遅延測定及び逆方向データに責任を持つ状態計算機を用いて遂行される。データハンドシェークモジュール４６０は、ＭＤＤＩパケットビルダ４５０からデータを受け取り、このデータを、データパッド４７０に渡す。データパッド４７０は、このデータを、ＭＤＤＩリンク２２２に転送する。

図４Ｂは、ＭＤＤＩリンク２１０に提供されるパケットのフローを例示する。上述したように、パケットは、内部生成され、ＤＭＡインタフェース４４０から受け取られるか、あるいは直接的に受信されたビデオパケットである。内部生成されたパケットは、制御パケットジェネレータ４５２によって生成される。全てのタイプのパケットが、ＣＲＣジェネレータシステム４５４を介してデータハンドシェークモジュール４６０へ渡される。一方、データハンドシェークモジュール４６０は、データパッド４７０にパケットを提供する。データパッド４７０は、ＭＤＤＩリンク２１０にこのデータを送る。

図４Ｃは、ＭＤＤＩパケットビルダ４５０によって、ＭＤＤＩリンク２１０を介して受信されるパケットのフローを例示する。この場合、パケットは、データパッド４７０によってＭＤＤＩリンク２１０から受信され、次に、データハンドシェークモジュール４６０に渡される。データハンドシェークモジュール４６０は、このデータを、ＭＤＤＩパケットビルダ４５０内のＣＲＣチェッカ４５６へ渡す。一旦ＣＲＣチェッカ４５６が、到来したパケットのＣＲＣを確認すると、このパケットは、デジタルデータインタフェースデバイス１００内での配信のため、プロセッサバスに送られるためにＤＭＡインタフェース４４０に供給される。

パケットタイプの例は、図５及び図６に関して記載される。これらパケットの例は、本発明を例示するために使用されるが、これらのパケットタイプのみに本発明を限定するように意図されない。以下に述べるように、ユニークパターンを用いたその他のパケットタイプ、及びＣＲＣフィールドを、本発明とともに使用することができる。

図５は、ＶＥＳＡ ＭＤＤＩインタフェース規格に従ったサブフレームヘッダパケットフォーマット５００のブロック図である。サブフレームヘッダパケットフォーマット５００は、パケット長フィールド５１０、パケットタイプ長フィールド５２０、ユニークワードフィールド５３０、サブフレームヘッダパラメータフィールド５４０、及びＣＲＣフィールド５５０を含む。パケット長フィールド５１０は、パケット長フィールド５１０を含まないパケット内の合計バイト数を指定する１６ビット（２バイト）値を含む。パケットタイプフィールド５２０は、パケットに含まれる情報のタイプを指定する１６ビットの無符号整数を含む。ユニークワードフィールド５３０は、ユニークな１６ビットワードを含む。ユニークワードフィールド及びパケットタイプフィールド５２０の両方は、データを並べるための３２ビットのユニークパターンを形成するものと認識される。すなわち、パケットを受信した場合、ＭＤＤＩパケットビルダ４５０は、このユニークパターンに基づいて、ＭＤＤＩパケットビルダ４５０が処理しているのが、データパケットのどの部位又はフィールドであるかを判定することができる。サブフレームヘッダパラメータフィールド５４０は、ＭＤＤＩリンク２２２を管理するための制御パラメータを含んでいる。ＣＲＣフィールドは、１６ビットのＣＲＣ値を含んでいる。

図６は、ビデオストリームパケットフォーマット６００のブロック図である。ビデオストリームパケットは、ディスプレイの長方形部分を更新するためにビデオデータを運ぶ。ビデオストリームパケットフォーマット６００は、パケット長フィールド６１０、パケットタイプフィールド６１５、クライアントＩＤフィールド６２０、ビデオフォーマットフィールド６２５、ピクセルデータ属性フィールド６３０、Ｘ左端フィールド６３５、Ｙ上端フィールド６４０、Ｘ右端フィールド６４５、Ｙ下端フィールド６５０、Ｘ開始フィールド６５５、Ｙ開始フィールド６６０、ピクセルカウントフィールド６６５、パラメータＣＲＣフィールド６７０、ピクセルデータフィールド６７５、及びピクセルデータＣＲＣフィールド６８０を含む。

パケット長フィールド６１０は、パケット長フィールド６１０を含まないパケット内の合計バイト数を指定する１６ビット（２バイト）値を含んでいる。パケットタイプフィールド６２０は、パケットに含まれている情報のタイプを指定する２バイトの無符号整数を含んでいる。

フィールド６２０乃至６６５はそれぞれ、ビデオディスプレイがどのようにフォーマットされるかに関するパラメータデータを含む２バイトのフィールドである。これらフィールドの具体的定義は、ＶＥＳＡ ＭＤＤＩインタフェース規格において見つけることができる。パラメータＣＲＣフィールド６７０は、フィールド６１０乃至６６５内のパラメータデータを処理することにより生成されるＣＲＣ値を含む２バイトのフィールドである。

ピクセルデータフィールド６７５は、パケットサイズ及びピクセルカウントフィールドで許可された量までの任意のピクセルデータ量を含む。ピクセルＣＲＣフィールド６８０は、ピクセルデータフィールド６７５内でピクセルデータを処理することによって生成されるＣＲＣ値を含む２バイトフィールドである。

ＭＤＤＩリンク２１０によって送られる全てのパケットは、サブフレームヘッダパケットフォーマット５００内のＣＲＣフィールド５５０のような少なくとも１つのＣＲＣフィールドを含む。幾つかのより長いパケットでは、パケットは、例えばパラメータＣＲＣフィールド６７０とピクセルＣＲＣフィールド６８０とのように、ビデオストリームパケットフォーマット６００内に２つのＣＲＣフィールドを含むであろう。

ＣＲＣは、送信又は格納における誤りを検出するために、例えばネットワークトラフィックパケット、又はコンピュータファイルのブロックのような大きなデータブロックから多くの小さなビットを生成する。ＣＲＣは、（例えばＣＲＣフィールド５５０とともに）送信又は格納前に送られ追加されるデータの関数として計算され、その後、変化が起きていないことを確認するために検証される。

ＣＲＣは、パケットデータを、例えばＣＲＣジェネレータシステム４５４のようなＣＲＣジェネレータを介してプッシュすることによって計算され、パケットデータに関連するユニークなＣＲＣ値が生成される。ＣＲＣチェッカ４５６のようなＣＲＣチェッカは、受信データに基づいて、受信データＣＲＣ値を生成する。そして、この受信データＣＲＣ値は、送られたＣＲＣ値と比較される。これら２つが一致すると、データは有効であると考えられ、一致しないと、ＣＲＣ誤りが生成される。

ＣＲＣは一般的である。なぜなら、バイナリハードウェア内で実施することが簡単であり、数学的に分析することが容易であり、送信チャネル内の雑音によって引き起こされる一般的な誤りを検出することに特に優れているからである。ＣＲＣジェネレータの具体的な実装は、関連技術における個々の熟練者に知られるであろう。

図５及び図６に例示するように、ＣＲＣフィールドは、パケット内において、パケットの終わり（例えば、ＣＲＣフィールド５１２及びピクセルデータＣＲＣフィールド６８０）において、及び時々、著しく大きなデータフィールド（例えば、パラメータＣＲＣフィールド６７０）をもつより重要なパラメータの後に現れる。従って、転送中の誤りの確率が増加する。２つのＣＲＣフィールドを持っているパケットでは、１つのみが使用される場合、ＣＲＣジェネレータが、最初のＣＲＣ後に再び初期化される。これによって、長いデータフィールド後のＣＲＣ計算が、パケットの最初におけるパラメータによって影響されなくなる。

多くのビット誤りを含むパケットの可能性が低くなり、良好なＣＲＣを生成する。パケットにおける良好なＣＲＣを、誤って検出する確率は、多くの誤りを含む非常に長いパケットについて、７．６×１０^−６に近づく。設計によって、ＭＤＤＩリンクは、非常に低いか、ゼロの誤り率を持つであろう。ＣＲＣは、リンクの健全性をモニタするために使用されることが意図され、どのパケットが再送信されるべきかを決定するために具体的パケットに関する誤りを検出することは意図されていない。

典型的な実施形態では、ＣＲＣ計算に使用される多項式は、ＣＲＣ−１６、すなわちＸ１６＋Ｘ１５＋Ｘ２＋Ｘ０として知られている。本発明を実現するために役立つＣＲＣジェネレータ４５４及びＣＲＣチェッカ４５６のサンプル実装が図４Ｄに示される。図４Ｄでは、Tx_MDDI_Data_Before_CRCラインに入力されたパケットの最初のビットを転送する直前に、ＣＲＣレジスタ４７１が、値０ｘ０００１に初期化され、次に、このパケットのバイトが、ＬＳＢから始まるレジスタ内にシフトされる。この図中のレジスタビット番号は、ＭＤＤＩによって使用されるビット位置ではなく、使用される多項式の順序に対応することに留意されたい。単一方向にＣＲＣレジスタをシフトするのがより効率的であり、その結果、ＭＤＤＩビット位置１４に到達するまで、ＣＲＣビット１５は、ＭＤＤＩ ＣＲＣフィールドのビット位置０に、ＣＲＣレジスタビット１４は、ＭＤＤＩ ＣＲＣフィールドビット位置１というように現れる。

一例として、パケットコンテンツが、０ｘ０００ｃ、０ｘ００４６、０ｘ０００、０ｘ０４００、０ｘ００、０ｘ００、０ｘ００００であり（あるいは、０ｘ０ｃ、０ｘ００、０ｘ４６、０ｘ００、０ｘ００、０ｘ００、０ｘ００、０ｘ０４、０ｘ００、０ｘ００、０ｘ００、０ｘ００のようにバイトのシーケンスとして表され）、マルチプレクサ４７２，４７３及びＡＮＤゲート４７４の入力を用いて出力されるのであれば、結果としてTx_MDDI_Data_With_CRCライン上で得られるＣＲＣ出力は、０ｘｄ９ａａである（あるいは０ｘａａ，０ｘｄ９としてシーケンスで表される）。

ＣＲＣジェネレータ４５４とＣＲＣチェッカ４５６がＣＲＣチェッカとして構成される場合、Rx_MDDI_Dataライン上で受信されるＣＲＣは、マルチプレクサ４７２及び排他的ＯＲ（ＸＯＲ）ゲート４７６に入力され、ＮＯＲゲート４７５、ＡＮＤゲート４７４、及びＡＮＤゲート４７７を用いてＣＲＣレジスタにおいて発見される値と、ビット毎に比較される。誤りがある場合、ＡＮＤゲート４７７による出力として、ゲート４７７の出力をレジスタ４７１の入力に接続することによって、ＣＲＣ誤りを含むパケットについて一度づつＣＲＣがインクリメントされる。図４Ｄのブロック図内に示す回路の例は、与えられたCHECK_CRC_NOWウィンドウ（図４Ｅ参照）内で、１よりも多いＣＲＣ誤り信号を出力できることに留意されたい。従って、ＣＲＣ誤りカウンタは、一般に、CHECK_CRC_NOWがアクティブである各インターバル内で最初のＣＲＣ誤りインスタンスのみをカウントする。ＣＲＣジェネレータとして構成される場合、ＣＲＣは、パケットの終了と一致する時間においてＣＲＣレジスタから計時される。

入出力信号及びイネーブル信号のタイミングは、図４Ｅ及び図４Ｆにおいてグラフ的に例示される。ＣＲＣの生成、及びデータパケットの送信は、Tx_MDDI_Data_Before_CRC信号及びTx_MDDI_Data_With__CRC信号とともに、Gen_Reset信号、Check_CRC_Now信号、Generate_CRC_Now信号、及びSending_MDDI_Data信号の状態（０又は１）を示す図４Ｅに示される。データのパケットの受信、及びＣＲＣ値のチェックは、Rx MDDI Data信号及びCRC error信号とともに、Gen_Reset信号、Check_CRC_Now信号、Generate_CRC_Now信号、及びSending_MDDI_Data信号の状態を示す図４Ｆに示される。

パケット内にＣＲＣが存在することは、運用上のチャレンジを示し、また、ＭＤＤＩリンク２１０をより効率的に利用するための様々な機会を与える余裕がある。ＣＲＣに関する議論の焦点は、ＭＤＤＩリンク２１０に関連しているが、本発明は、ＭＤＤＩコンテンツに限定されない。本発明は、ＣＲＣが使用される任意のタイプのデジタルデータ送信リンクに適用されうる。

ＣＲＣの使用に関連した１つのチャレンジは、リンク初期化に関連する。リンクが確立すると、サブフレームヘッダパケット５００のようなサブフレームヘッダパケットが、ＭＤＤＩホスト２２２によってＭＤＤＩクライアント２０６へ送られる。リンク初期化時、ＣＲＣチェッカ４５６は、通常、データストリーム内のデータの並びが分からないであろう。すなわち、例えば、ＣＲＣチェッカ４５６は、それがユニークワードフィールド５３０内の処理データであるか、あるいはＣＲＣフィールド５５０内の処理データであるか分からないであろう。その結果、ＣＲＣチェッカ４５６は、データストリーム内のどこにあるかを認識するまで、データをメモリに連続的にキューする必要はないであろう。これは、非能率をもたらし、データをキュー及び格納するために使用されるよりも多くのメモリとチップ領域とを必要とする。データストリーム内の正確な位置を知らずに、ＣＲＣチェッカ４５６は、受信データを検証するために受信ＣＲＣと比較されるＣＲＣを生成することはできないであろう。

図７は、これらのチャレンジに対処するＣＲＣチェッカ４５６のブロック図である。ＣＲＣチェッカ４５６は、ユニークパターン検出器７１０、ＣＲＣジェネレータ７２０、ＣＲＣイニシャライザ７３０、及びＣＲＣベリファイヤ７４０を含む。ユニークパターン検出器７１０は、到来するデータストリーム内のユニークなパターンを検出し、このデータストリーム内の特定のポイントを識別する。ＣＲＣジェネレータ７２０は、受信データに関連するＣＲＣ値を生成するために使用される標準的なＣＲＣジェネレータである。ＣＲＣイニシャライザ７３０は、ＣＲＣジェネレータ７２０に、ユニークパターン及びパケット長に関連するデータ値を送る。ＣＲＣベリファイヤ７４０は、受信データを確認するために、受信ＣＲＣ値を、受信データに基づいてＣＲＣジェネレータ７２０によって生成されたＣＲＣ値と比較する。

図８は、リンク初期化方法８００のフローチャートであり、図７に示すようなＣＲＣチェッカ４５６の使用を実証する。１つのアプローチでは、サブフレームヘッダのパケット長が、常に同一であると仮定され、予め計算された値が、ＣＲＣチェッカにロードされる。これは、パケット長、パケットタイプ、及びユニークワードに基づく部分的なＣＲＣである。代替アプローチは、パケット長さが変数である状況をサポートする。この状況では、パケット長が、ユニークパターンとともに、事前計算機を介して送られ、値が生成される。この値は、ユニークパターンが受信された時、このポイントにおいてＣＲＣチェッカ内に配置される。

方法８００はステップ８１０で始まる。ステップ８１０では、送信リンクを初期化又はウェイクアップする要求が受信される。例えば、ＭＤＤＩクライアント２０６は、ＭＤＤＩリンク２１０を初期化又はウェイクアップする要求を、ＭＤＤＩホスト２２２から受信するだろう。ＭＤＤＩクライアント２０６内では、ＣＲＣチェッカ４５６は、このリンクウェイクアップ要求によって初期化されうる。特に、ＣＲＣイニシャライザ７３０は、この要求によって初期化されうる。

ステップ８２０では、ＣＲＣジェネレータが、ユニークパターン及びパケット長フィールド５１０に関連するデータ値が予め入力され、ユニークパターン及びパケット長フィールドに関連するＣＲＣ値が、ＣＲＣジェネレータによって生成される。上述したように、１つの実施形態では、パケット長フィールドは、固定されていると仮定される。例えば、ＣＲＣイニシャライザ７３０は、ユニークパターン及びパケット長フィールドをＣＲＣジェネレータ７２０に提供することができる。ＭＤＤＩの場合、このユニークパターンは、パケットタイプフィールド５２０及びユニークワードフィールド５３０内に含まれるデータに関連するデータ値である。リンクをウェイクアップすると、これらフィールドの値が、演繹的に知られるだろう。従って、ＣＲＣイニシャライザ７３０は、それらを格納し、ウェイクアップリンク要求が受信された場合にそれらをＣＲＣジェネレータ７３０に提供する立場にある。代替アプローチでは、ＣＲＣジェネレータにデータ値を提供するのではなく、ＣＲＣチェッカは、提供されたユニークパターン及びパケット長フィールドを有するＣＲＣジェネレータによって生成され、事前に計算されたＣＲＣ値とともに事前にロードされる。

ステップ８３０では、例えばＣＲＣジェネレータ７２０のようなＣＲＣジェネレータがディセーブルされる。このジェネレータは、更なるデータを処理してＣＲＣ値を変更しないように、ユニークパターン及びパケット長フィールドが受信されるまでディセーブルされる。

ステップ８４０では、到来するデータがモニタされ、ユニークデータパターンの受信が確認される。例えば、ユニークパターン検出器７１０は、ＭＤＤＩリンク２１０からの受信データをモニタする。

ステップ８５０では、ユニークパターンが受信されたことが判定される。例えば、ユニークパターン検出器７１０は、パケット長フィールド５１０、パケットタイプフィールド５２０、及びユニークワードフィールド５３０が受信されたことを判定する。

ステップ８６０では。ＣＲＣジェネレータがイネーブルされる。ＣＲＣジェネレータ７２０は、イネーブルされると、事前にロードされたユニークパターンを用いて生成された既存のＣＲＣ値に頼るであろう。その結果、ＣＲＣジェネレータ７２０は、データが直ちに並べられ、メモリ内にデータをキューして格納する必要はない。ＣＲＣフィールド５５０に含まれるＣＲＣ値を受け取ると、ＣＲＣベリファイヤ７４０は、ＣＲＣフィールド５５０内の値を、ＣＲＣジェネレータ７２０によって生成された値と比較して、ＣＲＣ誤りが存在するかを判定する。ステップ８７０では、方法８００が終了する。

通常、ＣＲＣ値は、送信リンクに関する問題が、送信中のデータを破壊したかを判定するために使用される。本発明の別の局面では、ＣＲＣ値は、システムエラー及びステータスに関連する情報を伝えるために使用される。このように、メッセージ内のＣＲＣフィールドは、送信リンク問題と、システムステータス又は誤り情報との両方をサポートするためにより効率的に使用される。

本発明の１つの実施形態では、ＣＲＣフィールドデータが破壊され、データを送信しているシステムに何か不具合があり、受信中のデータに問題があるかもしれないことが単に示される。例えば、ある場合には、ＭＤＤＩリンク２１０を通って進むデータは、破壊されるであろう。なぜなら、ＭＤＤＩパケットビルダ４５０に入るデータは、十分速く受信されないからである。たとえ不十分なデータがパケットに利用可能だったとしても、ＭＤＤＩ仕様は、パケットが依然として送られるべきであると記載している。従って、たとえパケットが送られても、データは有効ではないか、あるいは幾分不十分でありうる。

この場合、例えばパラメータＣＲＣ６７０又はピクセルデータ６８０のようなＣＲＣ値が故意に破壊され、ＭＤＤＩクライアント２０６は、送信されたパケットの完全性を害する何かが起こったことを認識できるようになる。ＭＤＤＩ仕様では、これが、データに問題があることをＭＤＤＩクライアント２０６に通知する方法である。あるいは、誤りを含むパケットの後に、基本的には「私が最後に送ったパケットは不完全である」と言う別のメッセージが送られる必要がある。

ＭＤＤＩクライアント２０６は、ＣＲＣ値が故意に破壊されたパケットを受信すると、このパケットをどのように取り扱うか判断する。アルゴリズムは、故意に破壊されたＣＲＣ値を有するパケットを検出し、それをどのようにして取り扱うかを決定するように開発される。あるタイプのパケットについては、ＭＤＤＩクライアント２０６は、単に、ＣＲＣ誤りを記録し、データを使用し続けるかもしれない。一方、他の状況では、ＭＤＤＩクライアント２０６は、受信パケットを廃棄し、新しいパケットを要求するかもしれない。

例えば、ビデオストリームパケット６００のようなビデオパケット内では、ピクセルデータＣＲＣ値６８０が故意に破壊された場合、ＭＤＤＩクライアント２２０は、ＭＤＤＩクライアント２２０の外部のロジックに、パケットが破壊されていることを通知しないであろう。この場合、受信データは、あらゆる種類の誤り通知を提供する前に、バッファされうる。ビデオデータの全て（すなわち、表示される全てのピクセルデータ）を潜在的にバッファする十分なメモリは存在しない。従って、ピクセルデータは、受信されるとすぐに、ディスプレイに供給される。その結果、ビデオ情報のどこかにＣＲＣ誤りがある場合、ビデオ情報の使用を停止するのには遅すぎる。この場合、問題が生じたと記録すること以外に何もなされない。要約すると、故意に破壊されたＣＲＣ誤りが、ピクセルデータ内で生じるが、パラメータデータ内には生じないのであれば、ＭＤＤＩクライアントは、単に、このＣＲＣ誤りをエラーカウンタに記録するが、依然として次のピクセルデータを使用する。一方、パラメータＣＲＣ値が故意に破壊された場合、ＭＤＤＩクライアントは、このピクセルデータを使用しないであろう。

図９は、ＣＲＣ値を故意に破壊するメカニズムを提供する巡回冗長ジェネレータシステム４５４のブロック図である。巡回冗長ジェネレータシステム４５４は、ＣＲＣジェネレータ９１０、ＣＲＣコラプタ９２０、誤り検出器９３０、及び誤り値ジェネレータ９４０を含む。

ＣＲＣジェネレータ９１０は、例えば、限定される訳ではないが、ＭＤＤＩリンク２１０のようなデジタル送信リンクによって送信されるデータパケットに含まれるデータに基づいてＣＲＣ値を生成する。

ＣＲＣコラプタ９２０は、ホスト又は遠隔システムステータス情報を運ぶために、ＣＲＣジェネレータ９１０によって生成されたＣＲＣ値を破壊する。例えば、インタフェースシステム２３０が、適切にＭＤＤＩパケットを入力するためにＭＤＤＩホスト２２２に十分早くデータを提供できない場合、ＣＲＣコラプタ９２０は、送られたパケットのＣＲＣ値を故意に破壊する。

誤り検出器９３０は、例えばＭＤＤＩホスト２２２のようなホストシステム内で誤り条件を検出するか、あるいはインタフェースシステム２３０から受信した情報に基づいて誤り条件情報を受信し、ＣＲＣコラプタ９２０が、ＣＲＣ値を故意に破壊するような指示を与える。１つの実施形態では、誤り検出器９３０は、単に、どこかに不具合があることを検出するが、具体的な誤り条件を判定しない。別の実施形態では、誤り検出器９３０は、誤り条件の特定のタイプを判定する。後者の実施形態では、誤り検出器９３０は、誤り値ジェネレータ９４０に誤りの特徴を伝える。誤り値ジェネレータ９４０は、ＣＲＣコラプタ９４０に対して、ＣＲＣジェネレータ９４０によって生成されたＣＲＣ値を、システムエラー又はステータス条件のタイプを示す具体的な値と交換するように命じる。

ＣＲＣ値を破壊する場合、アルゴリズムは、故意に破壊することが、有効なデータに対応しうるＣＲＣ値に至らず、もって、送信リンクの受信端において、ＣＲＣチェッカによってユニークなＣＲＣ値として受信されないことを保証するようにアルゴリズムが選択されねばならない。１つの可能なアルゴリズムは、有効なデータによって生成されないＣＲＣ値を識別し、かつこれらの値を、ＣＲＣ値を故意に破壊するためのユニークな値として使用することであろう。本明細書の教示に基づいて、関連技術における個々の熟練者は、本発明の精神及び範囲内に含まれる他のアルゴリズムを決定するであろう。

図１０は、ＣＲＣジェネレータシステム４５４からの故意に破壊されたＣＲＣ値を解釈することができるＣＲＣチェッカ４５６のブロック図である。ＣＲＣチェッカ４５６は、ＣＲＣ誤り値検出器１０１０、ＣＲＣジェネレータ１０２０、及びＣＲＣベリファイヤ１０３０を含む。ＣＲＣ誤り値検出器１０１０は、デジタル送信リンクによって受信されたデータパケットのＣＲＣフィールド内の値を検出する。ＣＲＣ誤り値検出器１０１０は、ＣＲＣ値が、システムエラー条件を識別する故意に破壊されたＣＲＣ値に一致する場合を識別する。ＣＲＣ値が、システムエラー条件に一致すると判定された場合、ＣＲＣ誤り値検出器１０１０は、ホストプロセッサに、例えばＭＤＤＩクライアント２０６のような受信クライアントを通知する。ホストプロセッサは、検出された誤りのタイプに基づいて動作を講じるであろう。ＣＲＣジェネレータ１０２０は、受信されたデータストリームに基づいてＣＲＣ値を生成する。ＣＲＣベリファイヤ１０３０は、受信されたデータストリームに基づいて生成されたＣＲＣ値の、受信されたデータストリーム内で送られたＣＲＣ値に対する相違を検出する。ＣＲＣジェネレータ１０２０及びＣＲＣベリファイヤ１０３０は、関連技術における個々の熟練者によって知られる従来方式で動作する。

図１１は、ＣＲＣ値を故意に破壊することによって、デジタル送信リンクを介してシステムエラー情報を送信する方法１１００のフローチャートである。方法１１００は、ステップ１１１０で始まる。ステップ１１１０では、ホストシステムあるいは関連システム内で誤りが検出される。例えば、誤り検出器９３０は、ＭＤＤＩホスト２２２あるいはインタフェースシステム２３０内で誤りを検出する。ステップ１１２０では、ＣＲＣ値が生成される。例えば、ＣＲＣジェネレータ９１０は、送られるパケットに関連したデータに対してＣＲＣ値を生成する。ステップ１１３０では、ＣＲＣ値が破壊される。例えば、誤り検出器９３０は、ＣＲＣ値を破壊するようにＣＲＣコラプタ９２０に命じる。ステップ１１４０で、方法１１００は終了する。方法１１００は、ＭＤＤＩを含むシステムに関して記述されているが、方法１１００は、ＣＲＣが使用されるあらゆるデジタル通信システムに適用可能であることに留意されたい。

本発明では、ＣＲＣフィールドは、誤りのタイプを表わす誤り符号情報を送信するために使用されてもよい。データパケットとＣＲＣのみがホストとクライアントとの間で転送されている場合は常に、誤り符号は提供されていない。唯一の誤りは同期の損失である。そうでない場合、良好なデータ転送経路又はパイプラインの欠如によりリンクがタイムアウトになることを待ち、リンクをリセットし、続けなければならない。あいにく、これは、時間を浪費し、幾分非能率的である。

１つの実施形態での使用のために、新しい技術が開発された。そこでは、パケットのＣＲＣ部が、誤り符号情報を転送するために使用される。すなわち、１又は複数の誤り符号が、データ転送を取り扱うプロセッサ又はデバイスによって生成される。これは、通信処理又はリンク内で発生しうる特定の予め定義された誤り又は欠陥を示す。誤りに遭遇する場合、適切な誤り符号が生成され、パケットのＣＲＣのビットを用いて転送される。すなわち、所望の誤り符号を用いてＣＲＣ値がオーバロード又はオーバライトされる。これは、ＣＲＣフィールドの値をモニタする誤りモニタ又はチェッカによって受信端上で検出される。幾つかの理由で、誤り符号がＣＲＣ値と一致する場合、混乱を避けるために、誤りのコンプリメントが転送される。

１つの実施形態では、ロバストな誤り警告及び検出システムを提供するために、誤り符号は、一般に全てである一連のパケットを用いて、数回転送される。これは、誤りが検出された後に転送又は送信される。これは、誤りを生成する条件が、システムから取り除かれるポイントまで生じる。このポイントでは、規則的なＣＲＣビットが、別の値によってオーバロードされることなく転送される。

ＣＲＣ値をオーバロードするこの技術は、最小量の追加ビット又はフィールドを用いながら、より迅速な応答をシステムエラーに提供する。

図１２に示すように、ＣＲＣオーバライトメカニズム又は装置１２００が、例えば誤り検出器９３０のような誤り検出器又は検出手段１２０２を用いて示されている。これは、以前に説明したか、あるいは周知の他の回路の一部を形成することができ、通信リンク又はプロセス内の誤りの存在又は実在を検出する。例えば誤り値ジェネレータ９４０のように、他の回路の一部として構成されることができるか、あるいは、例えば予め選択されたエラーメッセージを格納するためのルックアップテーブルのような技術を使用する誤り符号ジェネレータ又は手段１２０４は、特定の予め定めた誤りであるか、あるいは引き起こったものとして検出された欠陥を示すために１又は複数の誤り符合を生成する。デバイス１２０２，１２０４は、単一の回路又は所望されるデバイスとして、あるいは、他の周知のプロセッサ及び素子のためにプログラムされたステップのシーケンスの一部として形成することができることが容易に理解される。

例えばＣＲＣベリファイヤ１０３０のように、選択された誤り符号が、転送されたＣＲＣ値と同じであるかを確認するＣＲＣ値コンパレータ又は比較手段１２０６が示されている。その場合、オリジナルのＣＲＣパターン又は値として誤解され、検出スキームを混乱させたり、又は複雑にすることがないように、符号コンプリメントジェネレータ又は生成手段又はデバイスが、誤り符合のコンプリメントを提供するために使用される。誤り符合セレクタ又は選択手段要素又はデバイス１２１０は、その後、挿入又はオーバライトが望まれる誤り符合又は値、あるいは適切なコンプリメントを選択する。例えばＣＲＣコラプタ９２０のような誤り符合ＣＲＣオーバライタ、又はオーバライトメカニズム、又は手段１２１２は、所望の誤り符号を受信デバイスへ転送するために、データストリーム、パケット、及び挿入される所望の符号を受信し、対応するＣＲＣ値又は適切なＣＲＣ値をオーバライトするデバイスである。

既に述べたように、誤り符合は、一連のパケットを用いて何度も転送されるので、オーバライタ１２１２は、処理中、符号のコピーを保持するために、あるいは、必要に応じて又は所望に応じて値を記憶又は保持するために使用することが可能な前の素子又は他の周知の記憶場所から符号を呼び戻すために、メモリ記憶素子を利用しうる。

図１２のオーバライトメカニズムの一般的な処理の追加詳細が、図１３及び図１４に示されるように実施される。図１３では、ステップ１３０２において、通信データ又はプロセスにおいて、１又は複数の誤りが検出され、ステップ１３０４において、誤り符号が選択され、この条件が示される。ステップ１３０６では、それと同時に、あるいは適切なポイントにおいて、交換されるＣＲＣ値がチェックされ、ステップ１３０８において、所望の誤り符号と比較される。この比較の結果は、以前説明したように、所望の符号、あるいはその他の代表値が、現在のＣＲＣ値と同じであるか否かの判定である。この場合、処理はステップ１３１２に進む。ここでは、コンプリメント、又は幾つかの場合には、所望に応じてその他の代表値が、挿入される符号として選択される。ステップ１３１０及び１３１４では、どの誤り符合又は値が挿入されるべきかが決定されると、その適切な符号が、挿入のために選択される。これらのステップは、明瞭さの目的のために個別に例示されているが、一般に、ステップ１３０８の判定に基づく単一の選択を表す。最後に、ステップ１３１６において、この処理のターゲットとされているパケットを用いて転送するために、適切な値がＣＲＣ位置にオーバライトされる。

パケット受信側では、図１４に示すように、パケットＣＲＣ値が、ステップ１４２２においてモニタされる。一般に、ＣＲＣ値は、データ転送中に誤りが発生したか、パケットの再送信を要求するか否かを判定するために、あるいは上述したもののうちの幾つかのような更なる動作を禁止するために、システム内で、１又は複数の処理とともにモニタされている。そのようなモニタリングの一部として、この情報はまた、値を、既知又は予め選択された誤り符号、あるいは代表値と比較し、誤りの存在を検出するためにも使用される。あるいは、個別の誤り検出処理およびモニタを実施することができる。符号が存在するように思われる場合、ステップ１４２４では、更なる処理のために抽出されるか、そうでない場合には注釈が付けられる。ステップ１４２６では、これが実際の符号であるか、あるいはコンプリメントであるかの判定がなされる。コンプリメントである場合には、追加ステップ１４２８が使用され、この値が、所望の符号値に変換される。何れの場合も、ステップ１４３０では、結果として抽出された符合、コンプリメント、又はその他の復元された値は、送信された符号から、どの誤りが生じたのかを検出するために使用される。

（結論）
本発明の典型的な実施形態が示された。本発明は、これらの例に限定されない。これらの例は、本明細書において、例示目的で表されており、限定のために表されているのではない。本明細書に含まれる教示に基づいて、代替例（本明細書の記載の等価物、拡張、変形、変更等）が、関連技術における熟練者に明らかになるであろう。そのような代替例は、本発明の範囲及び精神内にある。

本明細書で述べられた全ての出版物、特許、及び特許出願は、本発明が関連する技術における熟練者の熟練レベルを示しており、あたかも個々の出版物、特許、又は特許出願が、参照によって特別に及び個別に組み込まれていることが示されているかのように、同程度に参照によって本明細書に組み込まれている。

図１は、デジタルデバイス及び周辺機器に接続されたデジタルデータデバイスインタフェースのブロック図である。 図２は、高速データ通信を提供するＭＤＤＩインタフェースを使用する、上部及び下部クラムシェル部を有するセルラ電話のブロック図である。 図３は、カメラを備えたセルラ電話の上部クラムシェルのブロック図である。 図４Ａは、ＭＤＤＩホストのブロック図である。 図４Ｂは、ＭＤＤＩパケットビルダからＭＤＤＩリンクへのパケットフローのブロック図である。 図４Ｃは、ＭＤＤＩパケットビルダによってＭＤＤＩリンクから受信されるパケットフローのブロック図である。 図４Ｄは、ＣＲＣチェッカのブロック図である。 図４Ｅは、ＣＲＣの生成を示すタイミングブロック図である。 図４Ｆは、ＣＲＣの取得を示すタイミングブロック図である。 図５は、サブフレームヘッダパケットフォーマットのブロック図である。 図６は、ビデオストリームパケットフォーマットのブロック図である。 図７は、ＣＲＣチェッカのブロック図である。 図８は、ＣＲＣジェネレータの事前実装を含むリンク初期化方法のフローチャートである。 図９は、ＣＲＣ値を故意に破壊するメカニズムを提供するＣＲＣジェネレータシステムのブロック図である。 図１０は、故意に破壊されたＣＲＣ値を解釈できるＣＲＣチェッカのブロック図である。 図１１は、ＣＲＣ値を故意に破壊することにより、デジタル送信リンクによってシステムエラー情報を送信する方法のフローチャートである。 図１２は、ＣＲＣオーバライトメカニズムのブロック図である。 図１３は、ＣＲＣオーバライト方法のフローチャートである。 図１４は、オーバライトされたＣＲＣ値を受信する方法のフローチャートである。

Claims (4)

1. 巡回冗長検査（ＣＲＣ）チェッカであって、
   デジタル送信リンクによって受信したデータストリーム内のユニークパターンを検出するユニークパターン検出器と、
   前記受信したデータストリームに基づいてＣＲＣ値を生成するＣＲＣジェネレータと、
   リンクが初期化されると、前記ＣＲＣジェネレータに、前記ユニークパターンに関連するＣＲＣ値を事前入力するＣＲＣイニシャライザと、
   受信したデータストリームに基づいて生成されたＣＲＣ値の、前記受信したデータストリーム内で送られたＣＲＣ値に対する相違を検出するＣＲＣベリファイヤと
   を備えるＣＲＣチェッカ。
2. 前記ＣＲＣイニシャライザは、前記ＣＲＣベリファイヤに、前記ユニークパターンに関連するＣＲＣ値を事前入力する請求項１のＣＲＣチェッカ。
3. 前記デジタル送信リンクはＭＤＤＩ送信リンクである請求項１のＣＲＣチェッカ。
4. 前記ユニークパターンは、パケット長フィールド、パケットタイプフィールド、及びユニークワードフィールドをサブフレームヘッダパケット内に含む請求項１のＣＲＣチェッカ。

Images