JP2007534232A - 高速データレートインタフェース装置及び方法 - Google Patents

高速データレートインタフェース装置及び方法 Download PDF

Info

Publication number
JP2007534232A
JP2007534232A JP2007504084A JP2007504084A JP2007534232A JP 2007534232 A JP2007534232 A JP 2007534232A JP 2007504084 A JP2007504084 A JP 2007504084A JP 2007504084 A JP2007504084 A JP 2007504084A JP 2007534232 A JP2007534232 A JP 2007534232A
Authority
JP
Japan
Prior art keywords
packet
data
client
host
field
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2007504084A
Other languages
English (en)
Other versions
JP4519903B2 (ja
JP2007534232A5 (ja
Inventor
アンダーソン、ジョン・ジェームズ
スティール、ブライアン
ウィレイ、ジョージ・エー.
シェカー、シャシャンク
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Publication of JP2007534232A publication Critical patent/JP2007534232A/ja
Publication of JP2007534232A5 publication Critical patent/JP2007534232A5/ja
Application granted granted Critical
Publication of JP4519903B2 publication Critical patent/JP4519903B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W52/00Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/04TPC
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1069Session establishment or de-establishment
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14Handling requests for interconnection or transfer
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38Information transfer, e.g. on bus
    • G06F13/40Bus structure
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80Responding to QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M1/00Substation equipment, e.g. for use by subscribers
    • H04M1/72Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72403User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
    • H04M1/72409User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by interfacing with external accessories
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24Negotiation of communication capabilities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M1/00Substation equipment, e.g. for use by subscribers
    • H04M1/72Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72403User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
    • H04M1/72409User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by interfacing with external accessories
    • H04M1/724094Interfacing with a device worn on the user's body to provide access to telephonic functionalities, e.g. accepting a call, reading or composing a message
    • H04M1/724097Worn on the head
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M1/00Substation equipment, e.g. for use by subscribers
    • H04M1/72Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72403User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
    • H04M1/72409User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by interfacing with external accessories
    • H04M1/72412User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by interfacing with external accessories using two-way short-range wireless interfaces
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W52/00Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02Power saving arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04Network layer protocols, e.g. mobile IP [Internet Protocol]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W84/00Network topologies
    • H04W84/02Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10Small scale networks; Flat hierarchical networks
    • H04W84/12WLAN [Wireless Local Area Networks]
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00Reducing energy consumption in communication networks
    • Y02D30/70Reducing energy consumption in communication networks in wireless communication networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Computer Hardware Design (AREA)
  • Communication Control (AREA)
  • Control Of Indicators Other Than Cathode Ray Tubes (AREA)
  • Information Transfer Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Small-Scale Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

【解決手段】デジタル制御データとデジタルプレゼンテーションデータの事前に選択されたセットを通信するための通信プロトコルを形成するために、共にリンクされるパケット構造を使用して、通信経路上、ホストとクライアントの間でデジタルデータを転送するためのデータインタフェース。前記信号プロトコルは、通信プロトコルを形成するパケットを生成、送信、及び受信し、デジタルデータを1つ又は複数のタイプのデータパケットに形成するように構成され、少なくとも1台が該ホストデバイスに常駐し、該通信経路を通して該クライアントに結合される、リンクコントローラによって使用される。インタフェースは、短距離「シリアル」タイプデータリンクでの、費用効果が高い、低電力の、双方向高速データ転送機構となる。
【選択図】 図3

Description

(関連出願の相互参照)
本特許出願は、ともに本譲受人に委譲され、参照してここに明示的に組み込まれる、2004年3月17日に出願された「切り替え可能閾値差動インタフェース(Swithchable Threshold Differential Interface)」と題される特許仮出願第60/554,309号に対する優先権と、2004年3月24日に出願された「切り替え可能閾値差動インタフェース(Swithchable Threshold Differential Interface)」と題される特許仮出願第60/556,345号に対する優先権とを主張する。
本開示の中の本発明の実施形態は、ホストデバイスとクライアントデバイスの間で高速データレートで信号を通信する、あるいは転送するための統合回路及びコンポーネントを含むデジタル信号プロトコル、プロセス、及び装置に関する。さらに具体的には、本開示は、内蔵デバイスアプリケーション及び外部デバイスアプリケーションを有する低電力高データレート転送機構を使用して、エンドユーザに対するプレゼンテーション又はディスプレイのためにホスト又はコントローラデバイスからクライアントデバイスにマルチメディア及び他の種類のデジタル信号を転送する技法に関する。
コンピュータ、電子ゲーム関連製品及び多様なビデオ技術(例えばDVD及び高解像度VCR)は、いくつかの種類のテキストを含むときにもますます高解像度化する静止画像、ビデオ画像、ビデオオンデマンド画像、及びグラフィック画像をこのような装置のエンドユーザへのプレゼンテーションに備えるために過去数年間に著しく進歩した。同様に、これらの進歩により高解像度ビデオモニタ、HDTVモニタ、又は特殊画像投影要素などのさらに高解像度の電子表示装置の使用を使用しなければならなくなった。CD型音響再生、DVD、サラウンドサウンド、及び音声信号出力に関連する他の装置を使用するときなど、このような視覚映像を高解像度又は高品質音声データと組み合わせることは、エンドユーザのためによりリアリスティックなコンテンツリッチな、又は真のマルチメディア経験を作り出すために使用される。加えて、MP3プレーヤなどのきわめて移動性の高品質サウンドシステム及びミュージックトランスポート機構がエンドユーザに対する音声専用プレゼンテーションのために開発された。これは、コンピュータからテレビ及び電話まで、現在、高品質つまり品質を誇る生産に慣れ、それを期待している市販の電子機器の典型的なユーザの期待を高める結果となった。
電子製品を必要とする典型的なビデオプレゼンテーションシナリオでは、ビデオデータは、通常、毎秒約1キロビットから10キロビットである、よくても低速又は中速と呼べる速度で現在の技法を使用して転送される。次にこのデータは所望される表示装置上での遅れた(後の)再生のためにバッファに入れられるか、あるいは一時的な又は長期の記憶装置に記憶されるかのどちらかである。例えば、画像は画像をデジタルで表すのに有効なデータを受信又は送信するためにモデム又はインターネット接続装置を有するコンピュータに常駐するプログラムを使用するインターネット「全体で」又はインターネットを使用して転送されてよい。類似する転送は無線モデム又は無線パーソナルデータアシスタント(PDA)又は無線電話を備えるポータブルコンピュータなどの無線装置を使用して行うことができる。
データはいったん受信されると、プレイバックのために内蔵記憶装置又は小型ハードディスク等の外部記憶装置を含むRAM又はフラッシュメモリなどのメモリエレメント、記憶回路又はメモリ素子に記憶される。データ量と画像解像度に応じて、プレイバックは相対的に迅速に開始するか、あるいはより長期間の遅延を伴なって提示される可能性がある。すなわち、いくつかの例では、画像プレゼンテーションは、多くのデータを必要としない、あるいは何らかのタイプのバッファリングを使用する非常に小さい又は低い解像度の画像にはある程度のリアルタイムプレイバックを可能にし、その結果より多くのデータが転送されている間に、少し遅延した後にいくらかのデータが提示される。転送リンクに中断がない、あるいは使用されている転送チャネルに関して他のシステム又はユーザからの干渉がないならば、いったんプレゼンテーションが開始すると、転送は表示装置のエンドユーザに適度にトラスペアレントである。結線されたインターネット接続のような単一の通信経路を複数のユーザが共用する場合、転送は割り込まれたり、所望されるより低速になる可能性がある。
静止画像又は動画ビデオのどちらかを作成するために使用されるデータは、通信リンク上でのデータの転送を加速するために、多くの場合、ジェイペグ(Joint Photographic Experts Group)(JPEG)、エムペグ(Motion Picture Experts Group)(MPEG)、及びメディア業界、コンピュータ業界、及び他の通信業界の周知の規格組織又は企業によって指定される技法等のいくつかの周知の技法の1つを使用して圧縮される。これにより、既定量の情報を転送するためにより少ないビット数を使用してより速く画像又はデータの転送することが可能になる。
データがいったんメモリあるいは磁気記憶素子又は光学記憶素子などの保存メカニズムを有するコンピュータ又は他の受取人装置などの「ローカル」デバイスに転送されると、結果として生じる情報は解凍され(あるいは特殊な復号プレーヤを使用して再生され)、必要な場合には復号され、対応する使用可能な提示解像度及び制御要素に基づいて適切なプレゼンテーションのために準備される。例えば、Xピクセル×Yピクセルの画面解像度に関して典型的なコンピュータビデオ解像度は、一般的には所望されるようにあるいは必要に応じて種々の他の解像度が可能であるが、通常、480ピクセル×640ピクセルほどの低さから600×800から1024×1024の範囲である。
画像プレゼンテーションは、画像コンテンツ及び既定のビデオコントローラの特定の所定のカラーレベル又はカラー階調(色を生じさせるために使用されるピクセルあたりビット)及び輝度に関して画像を操作する能力、及び追加の利用されているオーバヘッドビットによっても影響を受ける。例えば典型的なコンピュータプレゼンテーションは、他の値にも遭遇するが、多様な色(陰影と色相)を表現するために1ピクセルあたり約8から32以上のビットを予想するであろう。
前記値から、既定の画面画像はそれぞれ最低から最高の典型的な解像度と深度の範囲で約2.45メガビット(Mb)から約33.55Mbのデータの転送を必要とすることが分かる。毎秒30コマの速度でビデオ又は動画タイプの画像を見るとき、必要とされるデータ量は毎秒約73.7メガビットから1,006メガビット、つまり毎秒9.21メガバイトから125.75メガバイトである。加えて、マルチメディアプレゼンテーション用の画像と共に、あるいはCD品質の音楽などの別個の高解像度音声プレゼンテーションとして音声データを提示することを所望する場合がある。対話型コマンド、コントロール、又は信号を処理する追加の信号も利用されてよい。これらのオプションのそれぞれが転送されるなおさらに多くのデータを追加する。さらに高精細度(HD)テレビ及び映画の録画もさらに多くのデータと制御情報を追加してもよい。いずれにせよ、高品質又は高解像度の画像データと高品質音声情報又はデータ信号をコンテンツリッチな経験を生じさせるためにエンドユーザに転送することを所望するとき、プレゼンテーション要素と、このようなタイプのデータを提供するように構成されるソース又はホストデバイスの間では高データ転送レートリンクが必要とされる。
1秒あたり約115キロバイト(KBps)又は920キロビット(Kbps)のデータレートは、現代のシリアルインタフェースによって日常的に処理できる。USBシリアルインタフェースなどの他のインタフェースは、12Mbpsほどの速度のデータ転送に対処し、米国電気電子技術者協会(IEEE)1394規格を使用して構成される転送などの特殊高速転送が約100MBpsから400MBpsの速度で行われる。残念なことにこれらの速度は、ポータブルビデオディスプレイ又は音声デバイスを駆動するための高解像度でコンテンツリッチな出力信号を提供するために未来の無線データ装置とサービスと共に使用するために意図される前述された所望される高速データレートには及ばない。これは、事業用コンピュータ及びその他のプレゼンテーション、ゲーム機などを含む。加えて、これらのインタフェースは、操作するためにはかなりの量のホスト又はシステム及びクライアントソフトウェアの使用を必要とする。そのソフトウェアプロトコルスタックは、特にモバイルワイヤレス機器又は電話の応用例が意図される場合に、望ましくないほど大量のオーバヘッドも生じさせる。このような装置はすでに課されている計算能力だけではなく、厳しいメモリ制限と電力消費量制限も有する。さらに、これらのインタフェースのいくつかは、高度に美的指向のモバイル応用例には重すぎ、不満足な嵩張るケーブル、コストを追加する、つまり単に消費電力が多すぎる複雑なコネクタを活用する。
アナログビデオグラフィックスアダプタ(VGA)、デジタルビデオインタラクティブ(DVI)又はギガビットビデオインタフェース(GVIF)インタフェースなどの他の公知のインタフェースがある。これらの最初の2つは、さらに高速の転送速度でデータを処理するが、重いケーブルも利用し、大量の電力、つまり約数ワットを消費する並列型インタフェースである。これらの特性のどれも携帯型家庭用電子機器と使用するために修正できない。3番目のインタフェースも電力消費が大きすぎ、高価なあるいは嵩張るコネクタを使用する。
前記インタフェースのいくつか、及び他の非常に高速のデータシステム/プロトコル又は固定インストールコンピュータ装置用のデータ転送と関連付けられた転送機構の場合、別の主要な欠点がある。所望されるデータ転送速度に対処することは、大量の電力及び/又は高電流レベルでの動作も必要とする。これは、高度に移動性の消費財のためのこのような技法の実用性を大きく削減する。
一般的には例えば光ファイバ型接続及び転送要素などの代替策を使用してこのようなデータ転送速度に対処することは、真に商業的な消費財に所望されるよりはるかに高い複雑度と費用をもたらす多くの追加の変換器及び要素も必要とする。光学系の一般的に高価な性質に加えて、その電力要件と複雑度が軽量で低電力の携帯型応用例のための一般的な使用を妨げる。
携帯型、無線又はモバイル応用例のために業界で欠如してきたものは、それが音声であるのか、ビデオであるのか、あるいはマルチメディアベースであるのかに関係なく、きわめて移動性の高いエンドユーザ向けの高品質のプレゼンテーション経験を提供するための技法である。すなわち、携帯型コンピュータ、無線電話、PDA又は他の高度に移動性の通信デバイス又は装置を使用するとき、使用されている現在のビデオプレゼンテーションシステム又はデバイス及び音声プレゼンテーションシステム又はデバイスは単に所望される高品質レベルで出力を配信することができない。多くの場合、欠如している知覚される品質は、高品質プレゼンテーションデータを転送するために必要とされる入手できない高速データレートの結果である。これは、エンドユーザに対するプレゼンテーションのためのより効率的で高度なあるいは機能満載(feature laden)の外付け装置への転送と、コンピュータ、ゲーム機などの携帯装置と携帯電話などの無線装置の内部のホストとクライアント間の転送も含むことがある。
後者の場合、さらに高解像度の内蔵ビデオ画面、及び他の特殊入力装置及び/出力装置及び接続をいわゆる第三世代電話のような無線装置に、及びいわゆるラップトップコンピュータに追加する上で大きな前進があった。しかしながら、ホスト及び/又は多様な他の制御要素及び出力構成要素が存在する、ビデオ画面又は他の要素を主要筐体に取り付ける又は接続する、回転式又はスライド式蝶番又は蝶番状の構造にかかるブリッジを含んでよい内蔵データバスと接続。一般に、高帯域幅、又は高スループットのインタフェースが存在する。一例としては、例えば、無線電話で所望されるスループットを達成するためには最高90個の導体を必要とすることがある従来の技法を使用する高スループットデータ転送インタフェースを構築することは非常に困難である。現在の課題は、一般に、比較的高い信号レベルを持ったパラレルタイプのインタフェースを適用することを含んでいる。これは、相互接続をより高価にかつ低い信頼性にするとともに、デバイス機能と干渉しうる放射放出を潜在的に生成させる。これは、克服しなければならない多くの製造、費用、及び信頼性の問題を提示する。
このような問題点及び要件は、一例として、高度なデータ機能、インターネット及びデータ転送接続又は内蔵エンターテインメントを提供するために、通信装置又は計算型装置が電気製品及び他の消費者装置に追加される、固定されたロケーションのシステムにも見られる。別の例は、個別ビデオ及び音声プレゼンテーション画面がシートバックに取り付けられた、飛行機及びバスであろう。しかしながら、これらの状況では多くの場合、メイン記憶装置、処理要素及び通信制御要素を、情報のプレゼンテーションのための相互接続リンク又はチャネルとの可視画面又は音声出力からある距離離れて位置させる方が、より便利で効率的、且つ容易に実用的である。このリンクは、前述されたように所望のスループットを達成するために大量のデータを処理することを必要とする。
したがって、データを提供するホストデバイスとエンドユーザに出力を提示するクライアントディスプレイ装置又は要素の間のデータスループットを高めるためには新しい転送機構が必要とされる。
出願人は、新しい転送機構を、2004年7月6日にZouらに発行された米国特許6,760,772号(特許文献1)となった米国出願10/020,520号と、2002年9月6日に出願された米国特許出願10/236,657号(特許文献2)とで提案した。これらは、共に”Generating And Implementing A Communication Protocol And Interface For High Data Rate Signal Transfer”と題され、本発明の譲受人に委譲され、参照してここに組み込まれる。また、”Generating And Implementing A Signal Protocol And Interface For Higher Data Rates”と題され、2004年6月2日に出願された米国特許出願10/860,116(特許文献3)もある。それらの出願で説明されている技法は、高速データ信号の中の大量のデータのための転送速度を大幅に改善できる。しかしながら、特にビデオプレゼンテーションに関して増加の一途を辿るデータレートに対する需要は伸び続ける。データ信号技術における他の継続中の開発をもってしても、依然としてなおさらに高速の転送速度、通信リンク効率の改善、より強力な通信リンクを目指して努力する必要がある。したがって、ホストデバイスとクライアントデバイスの間のデータスループットを高めるために必要とされる新しい、あるいは改善された転送機構を開発する継続するニーズがある。
米国特許6,760,772号 米国特許出願10/236,657号 米国特許出願10/860,116号
技術に存在する前記の欠点及び他は、新しいプロトコル及びデータ転送手段、方法及び機構が、高速でホストデバイスと受取人クライアントデバイスの間でデータを転送するために開発された本発明の実施形態により対処される。
本発明の実施形態は、ホストデバイスとクライアントデバイス間のデジタル制御及びプレゼンテーションデータの事前に選択されたセットを通信するための通信プロトコルを形成するための複数の又は一連のパケット構造を利用する通信経路上で、ホストデバイスとクライアントデバイス間で高速でデジタルデータを転送するためのモバイルデータデジタルインタフェース(MDDI)を目的としている。信号通信プロトコル又はリンク層はホスト又はクライアントリンクコントローラ、受信機、又はドライバの物理層によって使用される。ホストデバイス内に常駐する少なくとも1台のリンクコントローラ又はドライバは通信経路又はリンクを通してクライアントデバイスに結合され、通信プロトコルを形成するパケットを生成し、送信し、受信するように、及び1種類又は複数の種類のデータパケットにデジタルプレゼンテーションデータを形成するように構成される。インタフェースは、1つの共通した全体的なハウジング又はサポート構造内に常駐できる、ホストとクライアント間の情報の双方向転送を実現する。
インプリメンテーションは、一般的には、デジタルCMOSチップ上に容易に実現できる差動ドライバと受信機を例外として本来すべてデジタルであり、6のように少ない信号を必要とし、システムデザイナにとって便宜的であるほとんどすべてのデータレートで動作する。簡略な物理層プロトコルとリンク層プロトコルにより統合は容易になり、ハイバネーション状態が加わったこの簡略さによりポータブルシステムは非常に低いシステム電力消費を有することができる。
使用と受容に役立つために、インタフェースはデバイスのコストをほとんど増加せず、標準電池電圧を使用するインタフェースを通じてディスプレイに電力を供給できる一方、電力をほとんど消費しないで済むようにし、ポケットサイズのフォームファクタを有する装置に対処できる。インタフェースはHDTVを超える解像度をサポートするためにスケラブルであり、表示措置に対する同時ステレオビデオと7.1音声をサポートし、任意の画面領域への条件付更新を実行し、両方向での複数のデータタイプをサポートする。
本発明の実施形態の更なる態様では、少なくとも1台のリンクコントローラ、受信機、デバイス、又はドライバがクライアントデバイス内に配置され、通信経路又はリンクを通じてホストデバイスに結合される。クライアントリンクコントローラも通信プロトコルを形成するパケットを生成し、送信し、受信するように、及び1種類又は複数の種類のデータパケットにデジタルプレゼンテーションデータを形成するようにも構成される。一般的には、ホスト又はリンクコントローラはコマンド又は特定の種類の信号作成及び照会処理で使用されるデータパケットを処理するための状態機械を利用するが、通信プロトコルで使用されるデータ及びあまり複雑ではないパケットのいくつかを操作するためにより低速の汎用プロセッサを使用できる。ホストコントローラは、1台又は複数台の差動ラインドライバを備える。一方クライアントレシーバは通信経路に結合される1台又は複数台の差動ラインレシーバを備える。
パケットは、様々な可変長を有する所定数のパケットと共に所定の固定長を有するホストデバイスとクライアントデバイス間で通信されるメディアフレーム内で共にグループ化される。パケットはそれぞれパケット長フィールド、1つ又は複数のパケットデータフィールド、及びサイクリックリダンダンシーチェックフィールドを備える。サブフレームヘッダパケットはホストリンクコントローラからの他のパケットの転送の始めに転送される又は配置される。1つ又は複数のビデオストリーム型パケット及び音声ストリーム型パケットは、クライアントデバイスユーザへのプレゼンテーションのために、順方向リンクで、ホストからクライアントへそれぞれビデオタイプデータと音声タイプデータを転送するために通信プロトコルによって使用される。1つ又は複数の逆方向リンクカプセル化タイプのパケットはクライアントデバイスからホストリンクコントローラにデータを転送するために通信プロトコルによって使用される。いくつかの実施形態におけるこれらの転送は、少なくとも1つのMDDIデバイスを有する内蔵コントローラから内蔵ビデオ画面へのデータの転送を含む。他の実施形態は内部サウンドシステムへの転送及びジョイスティック及び複雑なキーボードを含む多様な入力装置から内蔵ホストデバイスへの転送を含む。
フィラー型パケットは、データを有さない順方向リンク伝送の期間を占有するために、ホストリンクコントローラによって生成される。複数の他のパケットは、ビデオ情報を転送するために通信プロトコルによって使用される。このようなパケットは、カラーマップパケット、ビットブロック転送パケット、ビットマップ領域塗りつぶしパケット、ビットマップパターン塗りつぶし、及び透明カラーイネーブル型パケットを含む。ユーザ定義ストリーム型パケットは、インタフェースユーザ定義データを転送するために通信プロトコルによって使用される。キーボードデータと及びポインティングデバイスデータ型パケットは、前記クライアントデバイスと関連付けられるユーザ入力装置に、及びユーザ入力装置からデータを転送するために通信プロトコルによって使用される。リンクシャットダウン型パケットは、前記通信経路上のどちらかの方向でのデータの転送を終了するため通信プロトコルによって使用される。
ディスプレイ電力ステータスパケットは、システムリソース上のドレイン又はシステム電力消費を最小にするために、ディスプレイのようなクライアントが使用されていないか、あるいは現在アクティブに使用されている場合に、特定のディスプレイコントローラハードウェアを低電力状態にするための構造、手段、又は方法を提供するために生成される。一つの実施例では、クライアントは、クライアント機能パケットのクライアント特徴機能インジケータのビット9を用いて、ディスプレイ電力ステータスパケットに応答する能力を示す。
ディスプレイ電力ステータスパケットのための一つの実施例のフォーマット。この種のパケットは、パケット長さフィールド、パケットタイプフィールド、hClient IDフィールド、電力状態フィールド、及び周期的冗長チェック(CRC)フィールドを持つように構成されている。この種のパケットは一般に2バイトタイプフィールド内のタイプ75フィールドとして識別される。2バイトのhClient IDフィールドは、Client IDのために予約された値又は情報を含んでいる。電力状態フィールドは、特定のディスプレイを、ある予め選択されたビットの値に従って特定された電力状態にするために用いられる情報を特定する。2バイトのCRCフィールドは、パケット長さを含むパケット内の全てのバイトのCRCを特定するか、又は含んでいる。
通信経路は、通常、一連の4本又は5本以上の導線と1つのシールドを有するケーブルを備え、又は利用する。さらにプリントワイヤ又は導体を所望されるように使用でき、いくつかはフレキシブル基板上に存在する。
ホストリンクコントローラは、前記クライアントが前記インタフェースを通じてどのような種類のデータとデータタイプに対処できるのかを決定するためにクライアントデバイスから表示能力情報を要求する。クライアントリンクコントローラは、少なくとも1つのクライアント機能型パケットを使用して表示能力又はプレゼンテーション機能をホストリンクコントローラに伝達する。複数の転送モードが通信プロトコルによって使用され、それぞれは既定の期間で平行して異なる最大数のデータのビットの転送を可能にし、それぞれのモードはホストリンクコントローラとクライアントリンクコントローラの間の交渉によって選択可能である。これらの転送モードはデータの転送中に動的に調整可能であり、順方向リンクで使用されるのと同じモードが逆方向リンクで使用される必要はない。
本発明のいくつかの実施形態の他の態様では、ホストデバイスは、無線電話、無線PDA、又はその中に配置される無線モデムを有するポータブルコンピュータ等の無線通信装置を備える。典型的なクライアントデバイスはマイクロディスプレイ装置及び/又は携帯型音声プレゼンテーションシステム等のポータブルビデオディスプレイを備える。さらに、ホストはクライアントデバイスユーザに提示されるために転送されるプレゼンテーションデータ又はマルチメディアデータを記憶するための記憶手段又は要素を使用してよい。
いくつかの実施形態のさらに他の実施形態では、ホストデバイスは、無線電話、無線PDA又はポータブルコンピュータ等の無線通信装置などの携帯型電子装置内に常駐する、後述されるような、ドライバ付きのコントローラ又は通信リンク制御装置を備える。この構成の典型的なクライアントデバイスは、クライアント回路又は集積回路、あるいはホストに結合され、同装置内に常駐する、及び携帯電話用の高解像度画面等の内蔵ビデオディスプレイ、及び/又は携帯型音声プレゼンテーションシステムに結合される、代替の何らかの種類の入力システム又は装置の中のモジュールを備える。
本発明の多様な構造及び動作だけではなく、本発明の追加の特徴及び利点も添付図面に関して詳細に説明される。図中、同様の参照番号は、一般的に同一の、機能上類似する、及び/又は構造上類似する要素又は処理ステップを示す。
I.概要
本発明の全般的な目的は、後述されるように、「シリアル」型のデータリンク又はチャネルを使用して、表示要素等のホストデバイスとクライアントデバイス間の短距離通信リンクでの高速又は非常に高速のデータ転送を可能にする、費用効果が高く、電力消費が低い転送機構をもたらすモバイルディスプレイデジタルインタフェース(MDDI)を提供することである。本機構は、特に、内部(ハウジング又はサポートフレームの中にある)表示装置又は出力要素又はデバイス、又は入力装置を中央コントローラ、あるいは通信要素又は装置に接続する上で有効な小型コネクタと薄い可撓ケーブルを用いるインプリメンテーションに役立つ。更に、この接続機構は、例えばウェアラブルマイクロディスプレイ(ゴーグル又はプロジェクタ)又はその他のタイプのビジュアル、オーディオ、感知情報表示デバイスのような外部表示要素又は装置を、ポータブルコンピュータ、無線通信装置又はエンターテインメント装置へ接続するのに非常に役に立つ。
用語モバイルとディスプレイはプロトコルの命名に関連しているが、これがインタフェースとプロトコルを扱う仕事をする当業者により容易に理解される標準的な名称を有するという点でのみの便宜上であることが理解されなければならない。ビデオエレクトロニクス規格協会(VESA)規格及びその規格の様々なアプリケーションに関連する。しかしながら、以下の提示される実施形態を検討後、多くの移動性ではなく、ディスプレイに関係しない応用例がこのプロトコルの適用及び結果として生じるインタフェース構造から恩恵を受け、結果として得られるインタフェース構造又は転送機構、及びMDDIラベルが本発明の性質又は有効性、あるいは多様な実施形態に対する制限を暗示することを目的としないことが容易に理解されるであろう。
本発明の実施形態の利点とは、非常に柔軟でありながら、複雑度が低く、低コストで、信頼性が高く、使用環境によく適合し、非常に堅牢であるデータ転送のための技法が提供される点である。
本発明の実施形態は、通常は音声、ビデオ又はマルチメディアの応用例用の大量のデータをホスト又はソースデバイスから通信又は転送するための多岐に渡る状況で使用でき、この場合このようなデータは、生成され、例えば具体的なデバイスへ転送するために操作され、又は処理され、あるいは例えばビデオディスプレイ、プロジェクション要素、オーディオスピーカのようなクライアントデバイス又は受信デバイス、あるいはその他の表示デバイスへ高速で記憶される。後述される典型的な応用例は、ポータブルコンピュータ又は無線電話又はモデムのどれかから、小型ビデオ画面あるいは小型投射レンズとスクリーンを含むゴーグル又はヘルメットの形を取る等のウェアラブルマイクロディスプレイ器具への、あるいはホストからこのような構成要素内のクライアントデバイスへのデータの転送である。多様な内部入力装置、又はクライアントを利用する外部入力装置から内部に位置する(同じ装置のハウジング又はサポート構造内に配置される)、あるいはケーブル又は導電体によって接続されたホストへだけではなく、プロセッサ又はコントローラから内蔵スクリーン又は他のプレゼンテーション要素である。
MDDIの特性又は属性は、それらが特殊な表示技術又はプレゼンテーション技術と無関係であるほどである。これは、そのデータの内部構造に関わらず、あるいはそれが実現するデータ又はコマンドの機能上の態様に関係なく高速でデータを転送するためのきわめて柔軟な機構である。これにより、例えば特定の装置の一意の表示要望等のある特定のクライアントデバイスの特異性に適応するように、あるいはいくつかのオーディオビジュアル(A−V)システム用の結合された音声とビデオの、あるいはジョイスティック、タッチパッド等の特定の入力装置の要件を満たすように転送されているデータパケットのタイミングを調整できるようになる。選択されたプロトコルに従う限り、インタフェースは非常に表示要素又はクライアントデバイスに非常にとらわれない(agnostic)。加えて、集合シリアルリンクデータ、つまりデータレートは数桁変化することがあり、通信システム又はホストデバイス設計者がコスト、電力要件、クライアントデバイス複雑度、又はクライアントデバイス更新速度を最適化できるようにする。
データインタフェースは現在主に「有線」信号リンク又は小型ケーブル上で大量の高速データを転送する際に使用するために提示される。しかしながら、いくつかの応用例では、インタフェースプロトコルのために開発された同じパケットとデータ構造を使用することが構成されるならば光ベースのリンクを含む無線リンクも利用してよく、十分に低い電力消費量又は実際的であり続ける複雑度での所望されるレベルの転送を持続できる。
II.環境
典型的な応用例は、音声再生システム108と112と共に、それぞれ表示装置104と106とデータを通信しているポータブルコンピュータ又はラップトップコンピュータ100及び無線電話又はPDA装置102が示されている図1Aと図1Bに見られる。さらに、図1Aは、明確にするためだけに1つの図に示されているが、無線装置102にも接続可能である大型のディスプレイ又は画面114あるいは画像プロジェクタ116への潜在的な接続を示す。無線装置は、現在データを受信できる、あるいは無線装置のエンドユーザによる表示及び/又は聴聞のための後のプレゼンテーション用に特定量のマルチメディアタイプデータを記憶素子又は記憶装置に過去に記憶した。典型的な無線装置は、大体の場合、音声及び単純なテキスト通信用に使用されるので、情報を装置102のユーザに通信するためにやや小型の表示画面と単純な音声システム(スピーカ)を有する。
コンピュータ100は、はるかに大型の画面を有するが、依然として不適当な外部サウンドシステムを有し、高精細度テレビ又は映画のスクリーンなどの他のマルチメディアプレゼンテーション装置には及ばない。コンピュータ100は図解の目的に使用され、他の種類のプロセッサ、対話型ビデオゲーム又は家庭用電子機器も本発明と共に使用できる。コンピュータ100は無線通信のために無線モデル又は他の内蔵装置を利用できる、あるいは所望されるようにケーブル又は無線リンクを使用してこのような装置に接続できるが、これらに限定されない。
これにより、より複雑な、つまり「リッチな」データのプレゼンテーションが有効又は楽しい経験になる。したがって、業界はエンドユーザに情報を提示し、最小レベルの所望される楽しみ又は積極的な経験を提供するために他の機構及び装置を開発している。
前述されたように、装置100のエンドユーザに情報を提示するために複数の種類の表示装置が開発された又は開発されている。例えば、一社又は複数の企業が視覚的表示を提示するためにデバイスユーザの目の前で画像を投影するウェアラブルゴーグルのセットを開発した。正しく配置されると、このようなデバイスは、視覚的な出力を提供する要素よりはるかに大きい「仮想画像」を、ユーザの目によって知覚されるように効果的に「投射」する。つまり非常に小さい投射要素により、ユーザの目(複数の場合がある)は、典型的な液晶ディスプレイ(LCD)画面等で可能であるよりはるかに大規模に画像を「見る」ことができる。より大型の仮想画面画像を使用することにより、さらに限定されたLCD画面ディスプレイで可能となるよりはるかに高い解像度の画像の使用も可能になる。他の表示装置は、表面等の上に画像を映写するために、小型LCD画面又は多様なフラットパネルディスプレイ要素、映写レンズ及びディスプレイドライバを含むことができるが、これらに限定されないであろう。
別のユーザに、又は代わりに信号を他のどこかに転送する又はそれらを記憶する別の装置に出力を提示するために無線装置102又はコンピュータ100に接続されるあるいは無線装置102又はコンピュータ100の使用に関連付けられる追加の要素もあってよい。例えば、データは、例えば書き込み可能CD媒体を使用して光学形式でフラッシュメモリに、あるいは後の使用のために磁気テープレコーダ及び類似する装置内等の磁気媒体に記憶されてよい。
加えて、多くの無線装置とコンピュータは現在、他の高度なサウンドデコーダとサウンドシステムだけではなく、内蔵MP3ミュージック復号機能も有している。ポータブルコンピュータは原則としてCDプレイバック機能とDVDプレイバック機能を活用し、いくつかは事前に記録された音声ファイル用を受信するための小型専用フラッシュメモリ読取装置も有する。このような機能を有することの問題点は、デジタルミュージックファイルが、復号とプレイバックプロセスが足並みを合わせることができる場合にだけであるが、きわめて強化されたフィーチャリッチ(feature rich)な経験を約束するという点である。同じことはデジタルビデオファイルにも当てはまる。
音声再生を支援するために、サブウーファー等の追加要素、あるいは前部と後部のサウンドプロジェクション用の「サラウンドサウンド」スピーカも加えることができるであろう外部スピーカ114が図1Aに示されている。同時に、スピーカ又はイヤホン108は、図1Bのマイクロディスプレイ装置のサポートフレーム又は機構にとって内蔵として示されている。公知となるように、電力増幅装置又は音声整形装置を含む他の音声又はサウンド再生要素が使用できる。
いずれにせよ、前述されるように、データソースからエンドユーザに対して1つ又は複数の通信リンク110上で高品質又は高解像度の画像データ及び高品質の音声情報又はデータ信号を転送することを所望するときには高速データレートが必要とされる。すなわち転送リンク110は明らかに前述されたようなデータの通信では潜在的なボトルネックであり、現在の転送機構は通常所望されるような高速データレートを達成しないため、システム性能を制限している。例えば前述されたように、1024ピクセル×1024ピクセル等のさらに高解像度の場合、1ピクセルあたり24から32ビットのカラー階調と、30fpsというデータレートを用いると、データレートは755Mbps以上を凌ぐ速度に近づくことができる。加えて、このような画像は、音声データとおそらく対話型ゲーム又は通信に対処する追加の信号、あるいは多様なコマンド、制御又は信号を含むマルチメディアプレゼンテーションの一部として提示されてよく、量又はデータ及びデータレートをさらに増加する。
データリンクを確立するために必要なケーブル又は相互接続がより少ないということは、ディスプレイに関連付けられるモバイル機器がさらに使用しやすく、さらに大きなユーザベースに採用される可能性が高いことを意味することも明らかである。これは、特に、複数の装置が完全な視聴覚経験を確立するために一般的に使用される場合に、及びさらに特にディスプレイと出力装置の品質レベルが増加するにつれて当てはまる。
ビデオ画面及び他の出力装置や入力装置における前述の、及び他の改善に関する別の典型的な応用例は、音声再生システム136と146と共に、それぞれ「内蔵」表示装置134と144とデータを通信をしているポータブルコンピュータ又はラップトップコンピュータ130及び無線電話又はPDA装置140が示される図2Aと図2Bに見られる。
図2Aと図2Bでは、全体的な電子デバイス又は製品の小さな切取内部図が、今日のエレクトロニクス産業全体で使用されている何らかの公知のタイプの回転接続全体で、それらをビデオディスプレイエレメント又は対応するクライアントを有する画面に接続する汎用通信リンク、ここでは138と148を備えた装置の一部分の中の1つ又は複数の内部ホストとコントローラの位置を示すために使用される。これらの転送に関与するデータ量が多数の導線がリンク138と148を構成することを必要とすることが分かる。このようなデータを転送するために使用可能な並行した、又は他の公知のインタフェース技法のタイプのために、このような装置上で高度なカラーインタフェースとグラフィックインタフェース、ディスプレイエレメントを活用する今日の増大する必要性を満たすためにこのような通信リンクは90以上の導線に近づいていると推定される。
残念なことに、該さらに高いデータレートは、単位時間あたりに転送される必要がある未処理のデータ量と信頼性のある費用効果の高い物理的な転送機構を製造するという両方の点において、データを転送するために現在使用可能な技術を超えている。
必要とされるのは、一貫して(さらに)低い電力、軽量、及び可能な限り簡略且つ経済的なケーブル布線構造を可能にする提示要素とデータソース間のデータ転送リンク又は通信経路用のさらに高速でデータを転送するための技法、構造、手段、又は方法である。出願人は、所望される低電力消費と複雑さを維持する一方で、モバイル機器、携帯機器又は固定位置の装置も所望されるディスプレイ、マイクロディスプレイ又は音声転送要素に非常に高速でデータを転送できるようにするためにこれらの目標及び他の目標を達成するための新しい技法又は方法と装置を開発した。
III.高速デジタルデータインタフェースシステムアーキテクチャ
新しいデバイスインタフェースを作成し、効率的に活用するために、低電力信号で非常に高速のデータ転送速度を提供する信号プロトコルとシステムアーキテクチャが考案された。該プロトコルはパケットと共通フレーム構造、つまりインタフェースに課されるコマンド又は操作構造と共にデータ又はデータタイプの事前に選択されたセットを通信するためのプロトコルを形成するために共にリンクされる構造に基づいている。
A.概要
MDDIリンクによって接続される、あるいはMDDIリンク上で通信する装置はホストとクライアントと呼ばれ、他の出力装置と入力装置も意図されるが、クライアントは通常何らかのタイプの表示装置である。ホストからディスプレイへのデータは(順方向トラフィック又はリンクと呼ばれる)順方向で移動し、クライアントからホストへのデータは、ホストによりイネーブルされるように逆方向(逆方向トラフィック又はリンク)で移動する。これは図3に示される基本的な構成に描かれている。図3では、ホスト202は、順方向リンク208と逆方向リンク210を備えるとして描かれる双方向通信チャネル206を使用してクライアント204に接続される。しかしながら、これらのチャネルはそのデータ転送が順方向リンク動作と逆方向リンク動作の間で効果的に切り替えられる導線の1つの共通したセットにより形成されている。これにより、導線の数は大幅に削減され、モバイル電子デバイス向け等の低電力環境における現在の高速データ転送に対する手法が直面する多くの問題の1つに即座に対処できる。
他の箇所に説明されるように、ホストは、本発明を使用することから恩恵を受けることができる複数の種類の装置の内の1つを備える。例えば、ホスト202は携帯用デバイス、ラップトップ装置、又は類似するモバイル計算機器の形をしたポータブルコンピュータとなるであろう。それはパーソナルデータアシスタント(PDA)、ページング装置、又は多くの無線電話又はモデムの1つである場合もあるであろう。代わりに、ホスト202は携帯DVD又はCDプレーヤ、又はゲームプレイ装置等のポータブルエンターテインメント装置又は提示装置である場合もあるであろう。
さらに、ホストは、高速通信リンクがクライアントと共に所望される、種々の他の広く使用されている、又は計画されている商品にホストデバイス又は制御要素として常駐できる。例えば、ホストは、ビデオ記録装置から応答の改善のために記憶装置ベースのクライアントに、あるいはプレゼンテーションのために高解像度大型画面に高速でデータを転送するために使用できるであろう。機載在庫システム又は計算システム、及び/又は他の家庭用装置に対するブルーツース接続を組み込んだ冷蔵庫等の電気製品は、インターネットモード又はブルーツース接続モードで動作しているときに改善された表示機能を有することができる、あるいは電子コンピュータシステム又は電子制御システム(ホスト)がキャビネット内のどこかに常駐する一方で、ドア内(in−the−door)ディスプレイ(クライアント)及びキーパッド又はスキャナ(クライアント)に対する配線のための書き込みニーズを削減した。一般的には、当業者は、新規の追加された又は既存のコネクタ又はケーブルのどちらかで使用可能な制限された数の導線を活用する情報のより高速なデータレートトランスポートで旧い装置を改良する能力だけではなく、このインタフェースの使用から恩恵を受ける可能性のある種々の現代的な電子デバイスと家庭用製品を理解するであろう。
同時にクライアント204は、エンドユーザに情報を提示するため、あるいはユーザからホストに情報を提示するために有用な種々の装置を備えることができるであろう。例えばゴーグル又はめがねに組み込まれているマイクロディスプレイ、帽子又はヘルメットに内蔵されている映写装置、ウィンドウ又はフロントガラス等の車両に内蔵される小型画面又はホログラフィック素子、又は多様なスピーカ、ヘッドフォン、あるいは高品質のサウンド又は音楽を提示するためのサウンドシステム等である。他のプレゼンテーション装置は会議用、あるいは映画とテレビの画像用に情報を提示するために使用されるプロジェクタ又は映写装置を含む。別の例は、実際にはユーザからの接触又はサウンド以外の「入力」はほとんどない装置又はシステムユーザから大量の情報を転送するように要求される可能性のあるタッチパッド又は敏感な装置、音声認識入力装置、セキュリティスキャナ等の使用であろう。加えて、コンピュータ及びカーキット又はデスクキット、及び無線電話用のホルダのためのドッキングステーションは、エンドユーザ又は他のデバイスと装置に対するインタフェース装置として動作してよく、特に高速ネットワークが関係する場合にデータの転送を支援するためにクライアント(マウス等の出力装置又は入力装置)又はホストのどちらかを利用してよい。
しかしながら、当業者は、本発明がこれらの装置に限定されず、記憶とトランスポート、あるいはプレイバック時のプレゼンテーションのどちらかの点で高品質の画像とサウンドをエンドユーザに提供することを目的とした、市場には使用に提案される多くの他の装置があることを容易に認識するであろう。本発明は所望されるユーザ経験を実現するために必要とされる高データレートに対処するために多様な要素又は装置の間のデータスループットを増加するという点で有効である。
本発明のMDDインタフェース及び通信信号プロトコルは、コスト又は複雑度及び関連する電力と制御の要件又はこれらの接続の制約を削減するために、ホストプロセッサ、コントローラ、又は(例えば)回路構成要素及びデバイス又はデバイスハウジング又は構造内のディスプレイの間の相互接続を簡略化するために(内蔵モードと呼ばれる)、及び外部要素、デバイス又は装置に対する接続のため、又はそれらのためだけではなく信頼性を高めるため(外部モードと呼ばれる)に使用されてよい。
このインタフェース構造により利用される各信号ペアの集合シリアルリンクデータレートは、何桁も変化することがあり、システム又は装置設計者が、既定の用途又は目的のためにコスト、電力、インプリメンテーションの複雑度及び表示更新速度を容易に最適化できるようにする。MDDIの属性は表示又は他のプレゼンテーション装置(ターゲットクライアント)技術とは無関係である。インタフェースを通して転送されるデータパケットのタイミングは、表示装置、サウンドシステム、記憶素子と制御要素、又は視聴覚システムの結合されたタイミング要件等の特定のクライアントの特異性に適応するように容易に調整できる。これにより、電力消費が非常に小さいシステムを有することができる一方、少なくともなんらかのレベルでMDDIプロトコルを利用するためにフレームバッファを有することは多様なクライアントの要件ではない。
B.インタフェースタイプ
MDDインタフェースは、少なくとも4種類、おそらく5種類以上の通信業界及びコンピュータ業界の何らかの異なる物理的な種類のインタフェースに対処するとして意図されている。それらが使用されている特定の用途あるいはそれらが関連している業界に応じて、他のラベル又は名称が当業者によって適用されてよいが、これらは単に1型、2型、3型及び4型と名付けられている。例えば、単純な音声システムはより複雑なマルチメディアシステムより少ない接続を使用し、「チャネル」等の特徴を別に参照してよい等である。
該1型インタフェースは6ワイヤ、又は他のタイプの導線又は導電素子、つまりそれを携帯電話又は無線電話、PDA、電子ゲーム、及びCDプレーヤ等のポータブル媒体プレーヤ、又はMP3プレーヤ、及び類似した装置又は類似したタイプの電子消費者技術で使用される装置にとって最適にするインタフェースとして構成される。一実施形態では、インタフェースはラップトップコンピュータ、ノート型パソコン、又はデスクトップパソコン及び類似した装置又は用途により適し、迅速なデータの更新を必要とせず、内蔵MDDIリンクコントローラを持たない8ワイヤ(導線)インタフェースとして構成できる。このインタフェースのタイプは、大部分のパソコンで見られる、既存のオペレーティングシステム又はソフトウェアサポートを適応させる上できわめて有効である追加の2線ユニバーサルシリアルバス(USB)インタフェースの使用によっても区別可能である。
2型、3型、及び4型インタフェースは高性能クライアント又はデバイスに適切であり、データ信号に適切な遮蔽及び低損失転送を提供するために、追加のツイストペア型導線と共により大きくさらに複雑なケーブル布線を使用する。
1型インタフェースは、ディスプレイ、音声、制御及び制限されたシグナリング情報を備えることができる信号を送出し、通常、高解像度全速度ビデオデータを必要としないモバイルクライアント又はクライアントデバイスのために使用される。1型インタフェースは5.1チャネル音声が加えられた30fpsでスーパービデオグラフィックアレイ(SVGA)解像度を容易にサポートでき、最小の構成で2組をデータ伝送用、1組を電力伝送用とする合計3組のワイヤ組だけを使用する可能性がある。この種のインタフェースはおもに、USBホストは信号の接続と転送のためのこのような装置内では使用できないモバイル無線機器等の装置向けである。この構成では、モバイル無線装置はMDDIホストデバイスであり、通常は、プレゼンテーション、表示又はプレイバックのためにクライアントに(順方向トラフィック又はリンク)データを送信するホストからの通信リンクを制御する「マスタ」として働く。
このインタフェースでは、ホストは、指定された期間それがバス(リンク)を占有し、逆方向パケットとしてデータをホストに送信できるようにするクライアントに特殊なコマンド又はパケットタイプを送信することによってクライアントからの通信データのホストでの受信(逆方向トラフィック又はリンク)を可能にする。これは、(後述される)カプセル化パケットと呼ばれる種類のパケットが転送リンク上での逆方向パケットの転送に対処し、逆方向リンクを生じさせるために使用される図4に描かれている。ホストがデータのためにクライアントをポーリングするために割り当てられた時間間隔がホストによって予定され、それぞれの指定された用途の要件に基づいている。この種の半二重双方向データ転送は、USBポートがクライアントからの情報又はデータの転送に使用できない場合に、特に有利である。
HDTV型又は類似した高解像度を可能にする高性能ディスプレイは、フルモーションビデオをサポートするために約1.5Gbpsレートのデータストリームを必要とする。該2型インタフェースは並列で2ビットを送信することによって、該3型は並列で4ビットを送信することによって高速データレートをサポートし、該4型インタフェースは8ビットを並列で転送する。2型と3型インタフェースは1型と同じケーブルとコネクタを使用するが、ポータブルデバイスでさらに高性能のビデオアプリケーションをサポートするためのデータレートの2倍及び4倍で動作できる。4型インタフェースは、非常に高性能のクライアント又はディスプレイに適しており、追加のツイストペアデータ信号を備えるわずかに大きなケーブルを必要とする。
MDDIによって使用されるプロトコルは、各1型、2型、3型又は4型のホストが、通常、何が使用できる最高のデータレートなのかを交渉することによって1型、2型、3型又は4型のクライアントと通信できるようにする。最も低機能の装置と呼ばれるものの能力又は使用可能な機能はリンクの性能を設定するために使用される。概して、ホストとクライアントが両方とも2型、3型又は4型のインタフェースを使用しているシステムの場合にも、両方とも1型インタフェースとして動作を開始する。ホストは、次に、ターゲットクライアントの機能を決定し、特定の用途に適切な2型、3型又は4型のモードのどれかに応じてハンドオフ動作又は再構成動作を交渉する。
一般的には、ホストが(さらに後述される)適切なリンク層プロトコルを使用し、省電力のためにより低速なモードに通常どんなときでも下げる、つまり再び動作を設定し直す、あるいは高解像度表示コンテンツなどのより高速な転送をサポートするためにより高速なモードに上げることが可能である。例えば、ホストは、システムが電池等の電源からAC電力に切り替わるとき、あるいは表示媒体のソースがさらに低い解像度フォーマット又は高い解像度フォーマットに切り替わるときに、あるいはこれらの組み合わせ又は他の条件又は事象がインタフェースタイプ、つまり転送モードを変更する根拠とみなされてよいときにインタフェースタイプを変更してよい。
システムが一方向で1つのモードを使用し、別方向で別のモードを使用してデータを通信することも可能である。例えば、1型モードがキーボード又はポインティングデバイス等の周辺装置からホストデバイスにデータを転送するときに使用され、4型インタフェースモードは高速でディスプレイにデータを転送するために使用できるであろう。ホストとクライアントが様々な速度で発信データを通信してよいことは当業者によって理解されるであろう。
多くの場合、MDDIプロトコルのユーザは「外部」モードと「内部モード」とを区別してよい。外部モードは、ある装置内のホストを、ホストから最高約2メートルくらいであるその装置の外部にあるクライアントに接続するためのプロトコルとインタフェースの使用を説明する。この状況では、ホストは、両方の装置がモバイル環境で容易に動作できるように外部クライアントに電力を送信してもよい。内部モードは、ホストが、共通ハウジング又はサポートフレームあるいは何らかの種類の構造内等、同じ装置の内部に含まれるクライアントにいつ接続されるのかを記述する。一例は、無線電話又は他の無線装置内、あるいはクライアントがディスプレイ又はディスプレイドライバ、あるいはキーパッド又はタッチパッド等の入力装置、又はサウンドシステムであり、ホストが中央コントローラ、グラフィックエンジン又はCPU要素であるポータブルコンピュータ又はゲーム装置の応用例であろう。クライアントが外部モード応用例と対照的に内部モード応用例でのホストにはるかに近く位置するので、通常、このような構成ではクライアントに対する電力接続について説明される要件はない。
C.物理インタフェース構造
ホストデバイスとクライアントデバイスの間で通信を確立するためのデバイス又はリンクコントローラの一般的な配置が図5と図6に示されている。図5と図6では、MDDIリンクコントローラ402と502がホストデバイス202内に取り付けられて示され、MDDIリンクコントローラ404と504がクライアントデバイス204内に取り付けられて示される。前述されたように、ホスト202は、一連の導線を備える双方向通信チャネル406を使用してクライアント204に接続される。後述されるように、ホストコントローラとリンクコントローラの両方とも、ホストコントローラ(ドライバ)又はクライアントコントローラ(受信機)のどちらかとして対応するように設定、調整又はプログラミングできる単一の回路設計を使用して集積回路として製造できる。これは、単一回路デバイスのより大規模な製造のためのさらに低いコストを可能にする。
図6では、MDDIリンクコントローラ502はホストデバイス202’に取り付けられ、MDDIリンクコントローラ504はクライアントデバイス204’に取り付けられて示されている。前述されたように、ホスト202’は一連の導線を備える双方向通信チャネル506を使用してクライアント204’に接続される。前述されたように、ホストコントローラとクライアントリンクコントローラの両方とも単一回路設計を使用して製造できる。
MDDIリンク上で、あるいは使用されている物理的な導線の間でホストと表示装置等のクライアントの間で受け渡される信号も図5と図6に示されている。図5と図6で分かるように、MDDIを通してデータを転送するための一次的な経路又は機構はMDDI_Data0+/−MDI_Stb+/−と呼ばれるデータ信号を使用する。これらのそれぞれは、ケーブル内の差動組のワイヤで転送される低圧データ信号である。インタフェース上で送信されるビットごとにMDDI_Data0組又はMDDI_Stb組のどちらかで1つの遷移しかない。これは電流ベースではなく、電圧ベースの転送機構であるため、静的な電流消費はほぼゼロである。ホストはクライアントディスプレイにMDDI_Stb信号を駆動する。
データはMDDI_Data組上で順方向と逆方向の両方で流れることができる、つまりそれは双方向転送経路であるが、ホストはデータリンクのマスタ又はコントローラである。MDDI_Data0とMDDI−Stb信号経路は雑音排除性を最大限にするために差動モードで操作される。これらの線路での信号のためのデータレートは、ホストによって送信されるクロックのレートで決定され、約1kbpsから400Mbps以上の範囲で可変である。
該2型インタフェースは、MDDI_Data1+/−と呼ばれる該1型のそれを超える1つの追加データ組又は導線又は経路を含む。該3型インタフェースはMDDI_Data2+/−及びMDDI_Data3+/−と呼ばれる2型インタフェースのそれを超える2つの追加のデータ組又は信号経路を含む。該4型インタフェースは、それぞれMDDI_data4+/−、MDDI_Data5+/−、MDDI_Data6+/−、及びMDDI_Data7+/−と呼ばれる該3型インタフェースのそれを超える4つのさらに多くのデータ組又は信号経路を含む。前記インタフェース構成のそれぞれでは、ホストはHOST_PwrとHOST_Gndと表されるワイヤ組又は信号を使用してクライアント又はディスプレイに電力を送ることができる。さらに後述されるように、電力伝達は、使用可能であるあるいは他のモードのために存在するよりさらに少ない導体を利用するインタフェース「タイプ」が使用されているとき、所望される場合、MDDI_Data4+/1、MDDI_Data+/−5、MDDI_Data6+/−、又はMDDI_Data7+/−の導線の上のいくつかの構成で対処できる。電力伝達は、通常外部モードに利用され、いくつかの応用例は異なってよいが、通常内部モードの必要性はない。
多様なモードについてMDDIリンク上でホストとクライアント(ディスプレイ)の間で受け渡される信号の要約は、インタフェースタイプに従って以下の表Iに描かれている。
Figure 2007534232
ホストからの転送のためのHOST_Pwr/Gnd接続が通常外部モードに提供されることにも注意する。内部応用例又は運転モードは、当業者に明らかであるように、通常、他の内部リソースから直接電力を引き出し、電力分配を制御するためにMDDIを使用しないクライアントを有するため、このような分配はここではさらに詳細に説明されない。しかしながら、当業者によって理解されるように、例えば何らかの種類の電力制御、同期又は相互接続の便利さを可能にするために、MDDIインタフェースを通して電力を配分できるようにすることは確かに可能である。通常、前記構造及び動作を実現するために使用されるケーブル布線の長さは約1.5メートル、通常2メートル以下であり、それぞれが同様に、公称値で32乃至28AWG(American Wire Gauge)のマルチストランドワイヤである3本のツイストペアの導線を含む。当該技術分野における熟練者は理解するであろうが、ワイヤサイズはこの範囲には制約されないが、電気仕様又は制約は、最大合計抵抗、フット(foot)当たりの最大キャパシタンス、各ペアのインピーダンス、及び混線に対して満足すべきである。
フォイルシールドカバリングが巻き付けられるか、あるいは、ここでは3本であるツイストペアの組又はグループ全体、及び追加のドレイン線であるドレイン線の上に形成される。ツイストペアとシールドドレイン導線は、技術で周知であるように、シールドがクライアント用のシールドに接続されるクライアントコネクタで終端し、ケーブル全体を覆う絶縁層がある。該ワイヤは、HOST_GndとHOST_Pwr、MDDI_Stb+MDDI_Stb−、MDDI_Data0とMDDI_Data0−、MDDI_Data+とMDDI_Data1−等のように組にされる。しかしながら、当該技術で理解されるように、本発明の実施形態を実現するために、具体的な用途に依存して様々な導線及びケーブル布線が使用されうる。例えば、幾つかの用途においては、ケーブルを保護するために厚い外部皮膜や金属層さえも使用されうる。一方、別の用途には、薄い、平坦な導電性リボンタイプの構造も良好に適する。
D.データ型及び速度
一連のユーザ経験と応用例にとって有効なインタフェースを達成するために、モバイルデジタルデータインタフェース(MDDI)は、制御情報、及びその組み合わせと共に種々のクライアントと表示情報、音声トランスデューサ、キーボード、ポインティングデバイス及びモバイル表示装置に統合される、又はモバイル表示装置に合わせて作動する可能性のある他の多くの入力装置又は出力装置にサポートを提供する。MDDIは、最小数のケーブル又は導線を使用して、順方向又は逆方向のどちらかでホストとクライアント間で行き来するデータの種々の潜在的な種類のストリームに対処できるように設計される。等時性ストリームと非同期ストリーム(更新)の両方ともサポートされる。集合データレートが、最大シリアルレートと利用されるデータエア数により制限される最大所望MDDIリンクレート以下である限り、データ型の多くの組み合わせが考えられる。これらは、以下の表IIと表IIIに一覧表示されるそれらのアイテムを含むことがあるが、これらに限定されない。
Figure 2007534232
Figure 2007534232
インタフェースは固定されていないが、将来のシステム柔軟性のためにユーザにより定義されるデータを含む種々の情報「タイプ」の転送をサポートできるように拡張可能である。対処されるデータの特定の例は、全画面又は部分画面ビットマップフィールド又は圧縮ビデオのどちらかの形式のフルモーションビデオ、電力を節約し、インプリメンテーション費用を削減するための低速の静的ビットマップ、種々の解像度又は速度でのPCM又は圧縮音声データ、ポインティングデバイス位置と選択、ならびにまだ定義されなければならないユーザ定義可能なデータである。このようなデータは、装置の機能を検出する、あるいは操作パラメータを検出するために制御情報又はステータス情報と共に転送されてもよい。
本発明の実施形態は、映画(ビデオディスプレイ及び音声)を見ること、個人表示が制限されたパソコン(グラフィックディスプレイ、ビデオと音声と結合されることもある)使用すること、ビデオゲームをPC、コンソール、又はパーソナルデバイス(動画グラフィックスディスプレイ又は同期ビデオと音声)でプレイすること、ビデオ電話(双方向低速ビデオと音声)、静止デジタル写真用カメラ、又はデジタルビデオ画像を捕捉するためのカムコーダの形でデバイスを使用してインターネットを「サーフィンすること」、電話、コンピュータ又はプレゼンテーションを行うためにプロジェクタにドッキングされるか、ビデオモニタ、キーボード及びマウスに接続されるデスクトップドッキングステーションにドッキングされるPDAを使用すること、及び無線ポインティングデバイスとキーボードデータを含む携帯電話、スマートフォン、又はPDAによる生産性の強化又はエンターテインメントの用途を含むが、これらに制限されないデータ転送での使用のための技術を進展させる。
後述されるような高速データインタフェースは、大量のA−V型データを、通常はワイヤライン又はケーブル型リンクとして構成される通信リンク又は転送リンク上で提供するという点で提示される。しかしながら、信号構造、プロトコル、タイミング、又は転送機構が、それが所望されるレベルのデータ転送を持続できる場合に、光媒体又は無線媒体の形をとるリンクを提供するように調整できるであろうことは容易に明らかになる。
MDDI信号は、基本的な信号プロトコル又は構造用の共通フレームレート(CFR)として公知である概念を使用する。共通フレームレートを使用する背景にある考え方は、複数のストリームのためのフレームタイミング又はクロックを導出するために使用可能なレートでサブフレームヘッダパケットを送信することによって同時等時性データストリームに同期パルスを与えることである。サブフレームヘッダパケットが送信されるレートは、共通フレームレートである。クライアントデバイスはこの共通フレームレートを時間基準として使用できる。低CFRは、サブフレームヘッダを送信するためにオーバヘッドを減少させることによりチャネル効率を高める。他方、高CFRは待ち時間を減少させ、音声サンプル用にさらに小さく、融通の利くデータバッファを可能にする。本発明のCFRは動的にプログラム可能であり、特定の用途で使用される等時性ストリームに適切である多くの値の内の1つとして設定されてよい。つまり、CF値は、所望されるように、既定のクライアントとホスト構成に最も適するように選択される。
ビデオ又はミクロディスプレイ用等の用途と使用される可能性の高い等時性データストリーム用の調整可能又はプログラム可能であるサブフレームごとに通常必要とされるバイト数が表IVに示される。
Figure 2007534232
サブフレームあたりのバイトの部分的なカウントは、簡略なプログラム可能M/Nカウンタ構造を使用して容易に得られる。例えば、サブフレームあたり26−2/3バイトのカウントは、それぞれ26バイトの1つのサブフレームが後に続く27バイトの2つのフレームを転送することによって実現される。さらに小さいCFRは、サブフレームあたりのバイトの整数を生じさせるために選択されてよい。しかしながら、一般的にはハードウェア内で単純なM/Nカウンタを実現するためには、本発明の実施形態の一部又はすべてを実現するために使用される集積回路チップ又は電子モジュール内では、大型の音声サンプルFIFOバッファに必要とされる面積より少ない面積を必要とするはずである。
様々なデータ転送速度とデータ型の影響を描く例示的な応用例がカラオケシステムである。カラオケの場合、一人又は複数人のエンドユーザがミュージックビデオプログラムに沿って歌うシステム。歌の歌詞は、ユーザが歌われる歌詞と、大体歌のタイミングとを分かるように画面上のどこか、通常は最下部に表示される。この用途はグラフィック更新が不定期なビデオディスプレイ、及びユーザの1つの又は複数の声をステレオ音声ストリームと混合することを必要とする。
300Hzという共通フレームレートを想定する場合には、各サブフレームはクライアントに対する順方向リンク上での(ステレオの147個の16ビットのサンプルに基づき)92,160バイトのビデオコンテンツと588バイトの音声コンテンツからなり、平均26.67(26−2/3)バイトの音声がマイクから移動性カラオケ機械に送り返される。非同期パケットがホストとおそらくヘッドマウント式のディスプレイの間で送信される。これは、30秒間隔の1/30で歌詞テキストが更新される下部1/4スクリーン高さと、歌詞テキストが更新されていない場合にサブフレームに送られるその他の様々な制御及び状態コマンドを含む。
表Vは、カラオケ例のサブフレーム内でデータがどのように割り当てられるのかを示す。使用されている合計速度は約279Mbpsであるように選択される。280Mbpsというわずかに高いレートは、サブフレームあたり別の約400バイトのデータを転送できるようにし、臨時の制御メッセージとステータスメッセージの使用を可能にする。
Figure 2007534232
III.(続き)高速デジタルデータインタフェースシステムアーキテクチャ
E.リンク層
MDDI高速シリアルデータ信号を使用して転送されるデータは、次々にリンクされる時分割パケットのストリームからなる。たとえ送信側装置に送信するデータがなくても、MDDIリンクコントローラは通常自動的にフィラーパケットを送信し、このようにしてパケットのストリームを維持する。単純なパケット構造の使用は、ビデオ信号又は音声信号あるいはデータストリームのための信頼性の高い等時性タイミングを確実にする。
パケットのグループは、サブフレームと呼ばれる信号要素又は構造の中に含まれ、サブフレームのグループはメディアフレームと呼ばれる信号要素又は構造の中に含まれる。サブフレームは、そのそれぞれのサイズとデータ転送用途に応じて1つ又は複数のパケットを含み、メディアフレームはもう1つのサブフレームを含む。ここに提示される実施形態により利用されるプロトコルによって提供される最大サブフレームは約232−1、つまり4,294,967,295バイトであり、最大メディアフレームサイズは約216−1、つまり65,535サブフレームとなる。
特殊なサブフレームヘッダパケットは後述されるように各サブフレームの始まりに表示される一意の識別子を含む。その識別子は、ホストとクライアント間の通信が開始されるとクライアントデバイスでフレームタイミングを獲得するためにも使用される。リンクタイミング獲得は以下にさらに詳細に説明される。
通常、表示画面は、フルモーションビデオが表示されている間にメディアフレームあたりに一度更新される。該表示フレームレートは該メディアフレームレートと同じである。リンクプロトコルは、所望される応用例に応じて、ディスプレイ全体、あるいは静的画像によって囲まれるフルモーションビデオコンテンツの小さな領域だけでフルモーションビデオをサポートする。ウェブページ又はeメールを表示する等いくつかの低電力のモバイル応用例では、表示画面はときおりしか更新される必要がない場合がある。それらの状況では、単一のサブフレームを送信してから、電力消費を最小限にするためにリンクをシャットダウンする、又は非アクティブ化することが有利である。インタフェースはステレオビジョン等のエフェクトもサポートし、グラフィックスプリミティブを処理する。
サブフレームは、システムが周期的に優先順位が高いパケットの伝送をイネーブルできるようにする。これにより、同時等時性ストリームは最小量のデータバッファリングと共存できる。これは、実施形態が表示プロセスに提供する1つの利点であり、複数のデータストリーム(ビデオ、音声、制御、ステータス、ポインティングデバイスデータ等の高速通信)が本質的に1つの共通したチャネルを共用できるようにする。それは、比較的に少ない信号を使用して情報を転送する。また、それはCRTモニタの、あるいは他のクライアント技術に特殊な作用のための水平同期パルス及びブランキング間隔等の表示技術に特殊な作用が存在できるようにもする。
F.リンクコントローラ
図5と図6に示されているMDDIリンクコントローラは、MDDIデータとストローブ信号を受信するために使用される差動ラインレシーバを例外として完全にデジタルなインプリメンテーションとなるように製造又は組み立てられる。しかしながら、差動ラインドライバと差動ラインレシーバは、CMOS型ICを作成するとき等、リンクコントローラ付きの同じデジタル集積回路内でも実現できる。アナログ機能又は位相ロックループ(PLL)はビット回復のために、あるいはリンクコントローラ用のハードウェアを実現するために必要とされない。ホストコントローラとクライアントリンクコントローラは、リンク同期のために状態機械を含むクライアントインタフェースを例外として、非常に類似した機能を含む。したがって、本発明の実施形態は、ホスト又はクライアントのどちらかとして構成できる単一のコントローラ設計又は回路を作成できるという実用的な利点を可能にし、リンクコントローラの製造コストを全体として削減できる。
IV.インタフェースリンクプロトコル
A.フレーム構造
パケット転送のために順方向リンク通信を実現するために使用される信号プロトコル又はフレーム構造が図7に描かれている。図7に示されているように、情報又はデジタルデータはパケットとして知られる要素にグループ化される。複数のパケットは同様に共にグループ化され、「サブフレーム」と呼ばれるものを形成し、複数のサブフレームが同様に共にグループ化され、「メディア」フレームを形成する。フレームの形成及びサブフレームの転送を制御するために、各サブフレームは、特にサブフレームヘッダパケット(SHP)と呼ばれる所定のパケットで開始する。
ホストデバイスは既定の転送に使用されるデータレートを選択する。この速度は、ホストの最大転送機能、つまりホストによりソースから取り出されるデータ、及びクライアントの最大機能、つまりデータが転送されている先の他の装置の両方に基づいてホストデバイスによって動的に変更できる。
MDDI又は本発明の信号プロトコルと共に作業するために設計される、あるいは本MDDI又は本発明の信号プロトコルを扱うことができる受取人クライアントデバイスは、それが使用できる最大又は現在の最大データ転送速度を決定するためにホストにより照会できる、あるいは使用可能なデータ型とサポートされている特徴だけではなく、デフォルトのより低速な最小速度も使用されてよい。この情報は、さらに後述されるようにクライアント機能パケット(DCP)を使用して転送できるであろう。クライアント表示装置は、事前に選択された最小データレートで又は最小データレート範囲内でインタフェースを使用してデータを転送する、あるいは他の装置と通信することができ、ホストはクライアントデバイスの完全な機能を突き止めるためにこの範囲内のデータレートを使用して照会を実行する。
ビットマップ及びクライアントのビデオフレームレート機能の性質を定義する他のステータス情報は、ホストがインタフェースを実用的と同程度に効率的又は最適に構成できるようにステータスパケットでホストに転送できる、あるいは任意のシステム制約の中で所望される。
ホストは、現在のサブフレームの中に転送される(それ以上の)データがないときに、あるいはホストが順方向リンクに選ばれるデータ伝送速度に後れを取らないほど十分な速度で転送できないときにはフィラーパケットを送信する。各サブフレームはサブフレームヘッダパケットで始まるため、前のサブフレームの最後は正確に前のサブフレームを充填するパケット(十中八九フィラーパケット)を含む。パケットにデータ本来を運ぶベータのための余地が欠如している場合、フィラーパケットはサブフレーム内の最後のパケットとなる、あるいは次に前のサブフレームサブフレームの最後で、サブフレームヘッダパケットの前になる可能性が高い。サブフレーム内に、各パケットがそのサブフレーム内で送信されるための残りの十分な空間があることを保証することはホストデバイス内の制御動作のタスクである。同時に、いったんホストデバイスがデータパケットの送信を開始すると、ホストはデータアンダーラン状況を生じさせずにフレーム内でそのサイズのパケットを無事に完了できなければならない。
実施形態の一態様においては、サブフレーム伝送は2つのモードを有する。1つのモードは周期的なサブフレームモード、つまりライブビデオと音声ストリームを送信するために使用される周期的なタイミングエポックである。このモードでは、サブフレーム長は非ゼロであると定義されている。第2のモードは、新しい情報が入手可能であるときだけフレームがクライアントにビットマップデータを提供するために使用される非同期つまり非周期モードである。このモードはサブフレームヘッダパケット内でサブフレーム長をゼロに設定することによって定義される。周期モード使用時、サブフレームパケット受信は、クライアントが順方向リンクフレーム構造に同期したときに開始してよい。これは、図49又は図63を参照して後述されている状態図に従って定義された「同期中」状態に相当する。非同期非周期サブフレームモードでは、第1のサブヘッダパケットが受信された後に受信が開始する。
B.全体的なパケット構造
本実施形態により実現される通信又は信号プロトコルを考案するために使用されるパケットのフォーマット又は構造、又はデータ転送のための方法又は手段は、インタフェースが拡張可能であり、追加のパケット構造が所望されるとおりに追加できることを念頭にして以下に提示されている。パケットは、インタフェースにおけるそれらの機能、つまりそれらが転送するかあるいは関連するコマンド、情報、値、又はデータという点で様々な「パケットタイプ」とされる、つまり分類される。したがって、各パケットタイプは転送されているパケットとデータを操作する上で使用される規定のパケットの所定のパケット構造を示す。容易に明らかとなるように、パケットは事前に選択された長さを有するか、あるいはそれらのそれぞれの機能に応じた可変又は動的に変更可能な長さを有してよい。プロトコルが標準に受け入れられる間に変更されるときに発生するように、同じ機能が依然として実現されるとしても、パケットには異なる名称も付けることができるであろう。多様なパケットで使用されるバイト又はバイト値はマルチビット(8ビット又は16ビット)の符号なし整数として構成されている。タイプ順で一覧表示されるその「タイプ」名称と共に、利用されているパケットのまとめは、表VI−1からVI−4に図示される。
各表は、説明及び理解を容易にするために全体的なパケット構造の中のパケットの一般的な「タイプ」を表す。これらのグループ分けによって本発明について暗示される又は表される制限又は他の影響はなく、パケットは所望されるとおりに多くの他の様式で編成できる。パケットの転送が有効であると見なされる方向も注記される。
Figure 2007534232
Figure 2007534232
Figure 2007534232
Figure 2007534232
本文の他の説明から明らかであることは、サブフレームヘッダ、フィラー、逆方向カプセル化、リンクシャットダウン、クライアント機能及びクライアント要求及びステータスパケットがそれぞれ外部モード動作にとって重要であり、外部モードのための通信インタフェースの多くの実施例においても必要とされるという点である。しかしながら、逆方向カプセル化、リンクシャットダウン、クライアント機能、クライアント要求及びステータスパケットは、内部モード動作のためにもオプションとして考えられるか、あるいは考えられることが好ましい。このことから、通信パケットの縮小セットを用いた非常に高速のデータ通信、及び対応する制御とタイミングの簡略化を可能にするさらに別のタイプのMDDIプロトコルが生じる。
パケットは、図8に描かれている、パケット長フィールド、パケットタイプフィールド、データバイトフィールド(複数の場合がある)、及びCRCフィールドを備える最小のフィールドの共通の基本的な構造又は全体的な集合を有する。図8に示されるように、パケット長フィールドは、パケットの中のビット総数、つまりパケット長フィールドとCRCフィールドの間のその長さを指定するマルチビット値又はマルチバイト値の形をした情報を含む。一実施形態では、パケット長フィールドは、パケット長を指定する16ビットつまり2バイト幅の符号なし整数を含む。パケットタイプフィールドは、パケットの中に含まれる情報のタイプを指定する別のマルチビットフィールドである。例示的な実施形態では、これは、16ビットの符号なし整数の形を取る16ビットつまり2バイト幅の値であり、表示機能、ハンドオフ、ビデオストリーム又は音声ストリーム、ステータス等のようなデータ型を指定する。
第3のフィールドは、ホストデバイスとクライアントデバイスの間でそのパケットの一部として転送又は送信されているビット又はデータを含むデータバイトフィールドである。データのフォーマットは、転送されているデータ特定の型に従ってパケットタイプごとに特に指定され、それぞれがそれ自体のフォーマット要件を備える一連の追加のフィールドに分離されてよい。つまり、各パケットタイプはこの部分又はフィールドの所定のフォーマットを有するであろう。最後のフィールドは、パケット内で情報の完全性を確認するために使用される、データバイトフィールド、パケットタイプフィールド、及びパケット長フィールド上で計算される16ビットサイクリックリダンダンシーチェックの結果を含むCRCフィールドである。言い換えるとCRCフィールド自体を除きパケット全体で計算される。クライアントは通常、検出されたCRCエラーの総カウントを保存し、このカウントをクライアント要求及びステータスパケット(以下を参照)でホストに報告する。
一般的には、これらのフィールド幅と編成は2バイトフィールドを偶数バイト境界で位置合わせされた状態に、及び4バイトフィールドを4バイト境界で位置合わせされた状態に保つように作られている。これにより、大部分の、又は通常使用されるプロセッサ又は制御回路について遭遇されるデータ型位置合わせ規則に違反することなく、ホストとクライアントのメインメモリ空間内にパケット構造を容易に構築できるようにする、あるいはパケット構造をホストとクライアントに関連付けることができるようにする。
パケットの転送中、フィールドは最初に最下位ビット(LSB)で開始し、最後に送信される最上位ビット(MSB)で終了する。長さが1バイトを超えるパラメータは、最下位ビットを最初に使用して送信され、その結果、LSBが最初に送信されるより短いパラメータに使用されるように、同じビット伝送パターンが長さ8ビットを上回るパラメータに使用されることになる。各パケットのデータフィールドは通常、それらが以下の後の項で定められる順序で送信され、一覧表示されている最初のフィールドが最初に送信され、記述されている最後のフィールドが最後に送信される。MDDI_Data0信号経路上のデータは、モード1型、2型、3型又は4型のどれかでインタフェース上で送信されるバイトのビット「0」と位置合わせされる。
ディスプレイ用にデータを操作するとき、ピクセルのアレイのためのデータは、エレクトロニクス技術で従来行われるように最初に行、次に列単位で送信される。言い換えるとビットマップの中の同じ行に表示されるすべてのピクセルは、最も左のピクセルが最初に送信され、最も右のピクセルが最後に送信される順序で送信される。行の最も右のピクセルが送信された後、シーケンスの中の次のピクセルは、続く行の最も左のピクセルである。他の構成に必要に応じて対処できるが、ピクセルの行は通常、大部分のディスプレイの場合上から下への順で送信される。さらに、ビットマップを処理する上で、ここで従われる従来の手法は、ビットマップの左上角をロケーション又はオフセット「0、0」と名付けることによって基準点を定めることである。ビットマップの中で位置を定める又は突き止めるために使用されるX座標とY座標は、それぞれビットマップの右と下部に近づくにつれて値を増加させる。第1の行と第1の列(画像の左上角)はゼロというインデックス値で開始する。X座標の規模は、ディスプレイのユーザによって見られるときに画像の右側に向かって大きくなり、Y座標の規模は画像の下部に向かって大きくなる。
ディスプレイウィンドウはビットマップの可視部分、つまり物理的な表示媒体上でユーザが見ることができるビットマップのピクセルの部分である。ディスプレイウィンドウ及びビットマップが同じサイズである場合が多い。ディスプレイウィンドウの左上角はつねにビットマップピクセルロケーション「0、0」を表示する。ディスプレイウィンドウの幅はビットマップのX軸に相当し、ディスプレイウィンドウ幅は、本実施形態の場合、対応するビットマップの幅以下である。ウィンドウの高さはビットマップのY軸に相当し、ディスプレイウィンドウの高さは、本実施形態の場合、対応するビットマップの高さ以下である。ディスプレイウィンドウ自体は、それはビットマップの可視部分として定義されるに過ぎないためプロトコル内でアドレス指定可能ではない。
ビットマップとディスプレイウィンドウの関係性はコンピュータ、電子技術、インターネット通信、及び他のエレクトロニクス関連の技術で周知である。したがって、これらの原理についての追加の説明又は図解はここでは提供されない。
C.パケット定義
1.サブフレームヘッダパケット
サブフレームヘッダパケットはあらゆるサブフレームの最初のパケットであり、図9に描かれているような基本的な構造を有する。サブフレームヘッダパケットはホスト−クライアント同期に使用され、あらゆるクライアントがこのパケットを受信し、解釈できなければならない一方であらゆるホストはこのパケットを作成できなければならない。図9の一実施形態で分かるように、この種のパケットはパケット長フィールド、パケットタイプフィールド、一意のワードフィールド、予約1フィールド、サブフレーム長フィールド、プロトコルバージョンフィールド、サブフレームカウントフィールド及びメディアフレームカウントフィールドを、通常その順序で有するように構造化されている。一実施形態では、この種のパケットは通常15359型(0x3bff 16進)パケットとして識別され、パケット長フィールドを含まずに20バイトという事前に選択された固定長を使用する。
パケットタイプフィールドと一意のワードフィールドはそれぞれ2バイト値(16ビットの符号なし整数)を使用する。これらの2つのフィールドの4バイトの組み合わせは共に、優れた自己相関のある32ビットの一意のワードを形成する。一実施形態では、実際の一意のワードは0x005a3bffであり、ここでは下位の16ビットはパケットタイプとして最初に送信され、最上位の16ビットが後に送信される。
予約1フィールドは将来の使用のために予約される2バイトを含み、通常この点で構成され、すべてのビットがゼロに設定される。このフィールドの1つの目的は、以後の2バイトのフィールドを16ビットのワードアドレスに位置合わせさせ、4バイトのフィールドを32ビットのワードアドレスに位置合わせさせる。最下位バイトは、ホストが複数のクライアントデバイスをアドレス指定できるか否かを示すために予約される。このバイトに対するゼロという値は、ホストが単一のクライアントデバイスと共にのみ動作できることを示すために予約される。
サブフレーム長フィールドは、4バイトの情報又はサブフレームあたりのバイト数を指定する値を含む。一実施形態では、このフィールド長は、リンクがシャットダウンされアイドル常態になる前に、サブフレームだけがホストによって送信されることを示すためにゼロに設定されてよい。このフィールドの値は、あるサブフレームから次のサブフレームに遷移するときに「オンザフライで」動的に変更できる。この機能は等時性データストリームに対処するために同期パルスで軽微なタイミング調整を行うために有効である。サブフレームヘッダパケットのCRCが有効ではない場合は、リンクコントローラは現在のサブフレームの長さを推定するために過去の公知の良好なサブフレームヘッダパケットのサブフレーム長を使用する必要がある。
プロトコルバージョンフィールドは、ホストによって使用されるプロトコルバージョンを指定する2バイトを含む。プロトコルバージョンフィールドは、プロトコルの第1のバージョン又はカレントバージョンを使用されているとして指定するために「0」に設定される。この値は新しいバージョンが作成されると経時的に変化し、幾つかのバージョンフィールドについては、既に「1」の値にアップグレードされている。バージョン値は、知られるようになるであろうが、例えばMDDIのようなインタフェースをカバーする承認された標準的なドキュメントに対する現在のバージョン番号におそらく、あるいは一般には従うであろう。
サブフレームカウントフィールドは、メディアフレームの開始後に送信されたサブフレーム数を示すシーケンス番号を指定する2バイトを含む。メディアフレームの第1のサブフレームはゼロというサブフレームカウントを有する。メディアフレームの最後のサブフレームはn−1という値を有し、この場合nはメディアフレームあたりのサブフレーム数である。サブフレームカウントフィールドの値は、ゼロの値を持つメディアフレームの第1のサブフレームの場合を除いて、前のサブフレームパケット内で送られたサブフレームカウントに1を加えたものに等しい。サブフレーム長が(非周期サブフレームを示す)ゼロに設定される場合に、サブフレームカウントもゼロに等しく設定されなければならないことに注意する。
メディアフレームカウントフィールドは、転送されている本メディアアイテム又はデータの開始後に送信されたメディアフレーム数を示すシーケンス番号を指定する4バイト(32ビットの符号なし整数)を含む。メディアアイテムの第1のメディアフレームはゼロというメディアフレームカウントを有する。メディアフレームカウントは、各メディアフレームの第1のサブフレームの直前に増分し、最大メディアフレームカウント(例えば、メディアフレーム数23−1=4,294,967,295)が使用された後に完了して戻る(wraps back)。メディアフレームカウント値は、通常、最終用途のニーズに合うようにホストによっていつでもリセットされてよい。
2.フィラーパケット
フィラーパケットは、順方向リンク又は逆方向リンクのどちらかで送信するために使用可能な他の情報がないときにクライアントデバイスに、又はクライアントデバイスから転送されるパケットである。必要時に他のパケットを送信する上で最大の柔軟性を可能にするためにフィラーパケットが最小長を有することが勧められる。サブフレーム又は逆方向リンクカプセル化パケット(以下を参照されたい)のまさに最後に、リンクコントローラはパケット完全性を維持するために残りの空間を充填するためのフィラーパケットのサイズを設定する。フィラーパケットは、ホスト又はクライアントに送信又は交換する情報がないときに、リンク上でタイミングを維持するために有効である。あらゆるホストとクライアントは、インタフェースを効果的に使用するためにこのパケットを送受できる必要がある。
フィラーパケットのフォーマットとコンテンツの典型的な実施形態は図10に示されている。図10に示されるように、この種のパケットはパケット長フィールド、パケットタイプフィールド、フィラーバイトパケット、及びCRCフィールドを有するように構造化されている。一実施形態では、この種のパケットは通常、2倍とタイプのフィールドで示されるタイプ0として識別される。フィラーバイトフィールドの中のビット又はバイトは、フィラーパケットが所望される長さとなることができるようにするために可変数の全ゼロビット値を備える。最小のフィラーパケットはこのフィールドにバイトを含まない。すなわち、パケットはパケット長、パケットタイプ、及びCRCだけからなり、一実施形態では、6バイトという事前に選択された固定長又は4というパケット長を使用する。CRC値は、何らかの他のパケットタイプでは排除されてよい、パケット長を含むパケットの中のすべてのバイトについて求められる。
3.ビデオストリームパケット
ビデオストリームパケットは、表示装置の通常は矩形領域を更新するためにビデオデータを搬送する。この領域のサイズは、単一のピクセルと同程度に小さいか、ディスプレイ全体と同じ程度大きくてよい。ストリームを表示するために必要とされるすべてのコンテキストはビデオストリームパケット内に含まれるために、同時に表示され、システムリソースによって制限されるほぼ無制限な数のストリームがあってよい。ビデオストリームパケット(ビデオデータフォーマット記述子)の一実施形態のフォーマットは図11に示される。図11で見られるように、一実施形態では、この種のパケットはパケット長(2バイト)フィールド、パケットタイプフィールド、bClient IDフィールド、ビデオデータ記述子フィールド、ピクセル表示属性フィールド、X左端縁フィールド、Y上部端縁フィールド、X右端縁フィールド、Y下部端縁フィールド、X開始フィールドとY開始フィールド、ピクセルカウントフィールド、パラメータCRCフィールド、ピクセルデータフィールド及びピクセルデータCRCフィールドを有するように構造化されている。この種のパケットは、通常、2バイトタイプフィールドに示される16型として識別される。一実施形態では、クライアントはクライアント機能パケットのRGBフィールド、白黒フィールド、及びY Cr Cb機能フィールドを使用してビデオストリームパケットを受信する能力を示す。
一実施形態では、bClient IDフィールドは、クライアントIDに予約される2バイトの情報を含む。これは新規に開発された通信プロトコルであるので、実際のクライアントIDはまだ公知ではないあるいは十分に通信可能ではない。したがって、このフィールドの中のビットは、このようなID値が公知になるまで通常ゼロに等しく設定され、その時点でID値は、当業者に明らかであるように挿入又は使用できる。一般的には同じプロセスが、後述されるクライアントIDフィールドに当てはまる。
前述されたように、例示的なビデオデータ記述子フィールドの動作を実現するために利用されるフォーマット及びコンテンツは、図12Aから図12Eに示される。図12Aから図12Eでは、ビデオデータフォーマット記述子フィールドは、本パケットの本ストリームのピクセルデータの中の各ピクセルのフォーマットを指定する16ビットの符号なし整数の形の2バイトを含む。様々なビデオストリームパケットが様々なピクセルデータフォーマットを使用してよい、つまりビデオデータフォーマット記述子で違う値を使用してよく、同様にストリーム(表示の領域)がそのデータフォーマットをオンザフライで変更してよいことが考えられる。ピクセルデータフォーマットはクライアント機能パケットで定義されるようにクライアントの有効なフォーマットの内の少なくとも1つに従わなければならない。ビデオデータフォーマット記述子は、一定のフォーマットがある特定のビデオストリームの存続期間中使用し続けられることを暗示しない本パケットだけのピクセルフォーマットを定義する。
図12Aから図12Dは、ビデオデータフォーマット記述子がどのようにしてコード化されるのかを描く。これらの図で使用されるように、及びこの実施形態では、ビット[15:13]が図12Aに示されるように「000」に等しいときには、ビデオデータはピクセルあたりのビット数がビデオデータフォーマット記述子ワードのビット3から0で定義される、白黒ピクセルのアレイからなる。ビット11から4は通常将来の使用又は用途のために予約され、この状況ではゼロに設定される。代わりにビット[15:13]が図12Bに示されるように値「001」に等しいときには、ビデオデータはカラーマップ(パレット)を通してそれぞれが色を指定するカラーピクセルのアレイからなる。この状況では、ビデオデータフォーマット記述子ワードのビット5から0はピクセルあたりのビット数を定義し、ビット11から6は通常将来の使用又は用途のために予約され、ゼロに等しく設定される。ビット[15:13]が図12Cに示されるように代わりに値「010」に等しいときには、ビデオデータは、赤のピクセルあたりのビット数がビット11から8によって定められ、緑のピクセルあたりビット数がビット7から4によって定められ、青のピクセルあたりビット数がビット3から0によって定められるカラーピクセルのアレイからなる。この状況では、各ピクセルのビット総数は赤、緑及び青に使用されるビット数の合計である。
しかしながら、ビット[15:13]が、図12Dに示されるように代わりに値又は文字列「011」に等しいときには、ビデオデータは、輝度とクロミナンス情報を含む4:2:2YCbCrフォーマットのビデオデータのアレイからなり、ルミナンス(Y)のピクセルあたりビット数はビット11から8によって定義され、Cb成分のビット数はビット7から4によって定義され、Cr成分のビット数はビット3から0によって定義される。各ピクセルの中のビット総数は、赤、緑及び青に使用されるビット数の合計である。Cb成分とCr成分はYの速度の半分で送信される。加えて、このパケットのピクセルデータ部分の中のビデオサンプルは以下の通りに編成される。つまりCbn、Yn、Crn、Yn+1、Cbn+2、Yn+2、Crn+2、Yn+3,...であり、ここではCbnとCrnはYnとYn+1と関連付けられ、Cbn+2とCrn+2はYn+2とYn+3に関連付けられる等である。
Yn、Yn+1、Yn+2、及びYn+3は、左から右へ単一行の中の4つの連続ピクセルの輝度値である。ビデオストリームパケットにより参照されるウィンドウの中の1行に奇数のピクセルがある場合(X右端縁−Y左端縁+1)、各行の最後のピクセルに対応するY値の後には次の行の第1のピクセルのCb値が続き、Cr値は行の中の最後のピクセルのために送信されない。Y Cb Crフォーマットを使用するウィンドウが偶数のピクセルである幅を有することが勧められる。パケットの中のピクセルデータは偶数のピクセルを含まなければならない。それは、ピクセルデータの最後のピクセルがビデオストリームパケットヘッダに指定されるウィンドウの中の行の最後のピクセルに相当する場合、つまりピクセルデータの最後のピクセルのXロケーションがX右端縁に等しいときに奇数又は偶数のピクセルを含んでよい。
ビット[15:13]が代わりに値「100」に等しいときには、ビデオデータはピクセルあたりビット数がビデオデータフォーマット記述子ワードのビット3から0で定義される、Bayerピクセルのアレイからなる。ピクセルグループパターンは、図12Eに示されるように、ビット5と4によって定義される。ピクセルデータの順序は水平又は垂直であってよく、行又は列の中のピクセルは順方向順又は逆方向順で送信されてよく、ビット8から6によって定義される。ビット11から9はゼロに設定されなければならない。Bayerフォーマットを取るピクセルグループの中の4個のピクセルのグループは、多くの場合、いくつかの表示技術において単一ピクセルと呼ばれるものに似ている。しかしながらBayerフォーマットの1ピクセルはピクセルグループモザイクパターンの4個の色つきピクセルの内の1つに過ぎない。
図に示される5つすべてのフォーマットについて、「P」として示されるビット12が、ピクセルデータサンプルがパックされるのか、あるいはバイト位置合わせピクセルデータであるのかを指定する。このフィールドの「0」という値は、ピクセルデータフィールドの各ピクセルがMDDIバイト境界とバイト位置合わせされていることを示す。「1」という値は、各ピクセルと、ピクセルデータの各ピクセル内の各色がピクセル内の過去のピクセル又は色と対照してパックされ、未使用のビットを残さないことを示している。バイト位置合わせされたデータフォーマットとパックされたピクセルデータフォーマットの相違点は図13にさらに詳しく示され、バイト位置合わせされたデータが、未使用の部分を残さないパックされたピクセルフォーマットと対照的に、データサブフレームの未使用の部分を残していることが明確に分かる。
4.音声ストリームパケット
音声ストリームパケットは、クライアントの音声システムを通して、あるいはスタンドアロン音声プレゼンテーション装置用に再生される音声データを搬送する。様々な音声データストリームが、使用されている音声システムに応じて、例えば左前、右前、中央、左後ろ、及び右後ろ等サウンドシステムの別々の音声チャネルに割り当てられてよい。音声チャネルの完全な補完物は機能強化された空間−音響信号処理を含むヘッドセットに提供される。クライアントは、クライアント機能パケットの音声チャネル機能フィールドと音声サンプルレートフィールドを使用して音声ストリームパケットを受信する能力を示す。音声ストリームパケットのフォーマットは図14に示されている。
図14に示されるように、この種のパケットは、一実施形態においてパケット長フィールド、パケットタイプフィールド、bClient IDフィールド、音声チャネルIDフィールド、予約1フィールド、音声サンプルカウントフィールド、サンプルあたりビット及びパッキングフィールド、音声サンプルレートフィールド、パラメータCRCフィールド、デジタル音声データフィールド及び音声データCRCフィールドを有するように構造化されている。一実施形態では、この種のパケットは通常32型パケットとして識別される。
bClient IDフィールドは、過去に使用されたようにクライアントIDに予約される2バイトの情報を含む。予約1フィールドは将来の使用のために予約される2バイトを含み、すべてのビットがゼロに設定され、通常この点で構成される。
サンプルあたりビット及びパッキングフィールドは、音声データのパッキングフォーマットを指定する8ビットの符号なし整数の形を取る1バイトを含む。通常利用されているフォーマットは、PCM音声サンプルあたりのビット数を定めるためのビット4から0用である。次にビット5は、デジタル音声データサンプルがパックされるかどうかを指定する。パックされた音声サンプルと、ここでは10ビットのサンプルを使用するバイト位置合わせされた音声サンプルの相違点は、図15に示されている。「0」という値は、デジタル音声データフィールドの中の各PCM音声サンプルがMDDIバイト境界とバイト位置合わせされていることを示し、「1」という値は、各連続PCM音声サンプルが過去の音声サンプルに対照してパックされることを示す。このビットは通常、ビット4から0で定義される値(PCM音声サンプルあたりのビット数)が8の倍数ではないときにだけ有効である。ビット7から6は将来の使用に予約され、通常、ゼロという値で設定される。
5.予約ストリームパケット
一実施形態では、パケットタイプ1から15、18から31、及び33から55が、遭遇される多様な応用例について所望されるようにパケットプロトコルの将来のバージョン又は変形での使用のために定義されるストリームパケットに予約される。再び、これは、他の技法に比較して千変万化の技術及びシステム設計に直面してMDDIをより柔軟且つ有効にすることの一部である。
6.ユーザ定義ストリームパケット
56型から63型として知られている8つのデータストリームタイプは、MDDIリンクと使用するために装置製造メーカによって定義されてよい独自仕様の応用例で使用するために予約されている。これらはユーザ定義ストリームパケットとして知られている。このようなパケットは任意の目的で使用されてよいが、ホストとクライアントはこのような使用の結果が非常によく理解されている、又は知られている状況だけでこのようなパケットを使用しなければならない。ストリームパラメータ及びこれらのパケットタイプのためのデータの特定の定義は、このようなパケットタイプを実現する、又はその使用を求める特定の装置製造メーカ又はインタフェース設計者に委ねられる。ユーザ定義ストリームパケットのいくつかの例示的な用途は、試験パラメータと試験結果、工場校正データ、及び独自仕様の特殊使用データを伝達することである。一実施形態で使用されるようなユーザ定義ストリームパケットのフォーマットは図16に示されている。図16に示されるように、この種のタイプのパケットはパケット長(2バイト)フィールド、パケットタイプフィールド、bClient ID番号フィールド、ストリームパラメータフィールド、パラメータCRCフィールド、ストリームデータフィールド及びストリームデータCRCフィールドを有するように構造化されている。
7.カラーマップパケット
カラーマップパケットは、クライアントのために色を提示するために使用されるカラーマップルックアップテーブルのコンテンツを指定する。いくつかの応用例は、単一のパケットで送信できるデータ量より大きいカラーマップを必要とすることがある。これらの場合、後述されるオフセットフィールドと長さフィールドを使用することによってそれぞれがカラーマップの異なる部分集合を含む、複数のカラーマップパケットが転送されてよい。一実施形態でのカラーマップパケットのフォーマットは、図17に示されている。図17に示されるように、この種のパケットはパケット長フィールド、パケットタイプフィールド、hClient IDフィールド、カラーマップアイテムカウントフィールド、カラーマップオフセットフィールド、パラメータCRCフィールド、カラーマップデータフィールド、及びデータCRCフィールドを有するように構造化されている。一実施形態では、この種のパケットは通常、パケットタイプフィールド(2バイト)に指定されるような64型パケット(ビデオデータフォーマット及びカラーマップパケット)として識別される。クライアントは、クライアント機能パケットのカラーマップサイズフィールドとカラーマップ幅フィールドを使用してカラーマップパケットを受信する能力を示す。
8.逆方向リンクカプセル化パケット
例示的な実施形態では、データは逆方向リンクカプセル化パケットを使用して逆方向で転送される。順方向リンクパケットは送信され、MDDIリンク動作(転送方向)は、パケットが逆方向で送信できるようにこのパケットの真中のあたりで変更又は方向転換される。一実施形態での逆方向リンクカプセル化パケットのフォーマットは図18に示されている。図18に示されるように、この種のパケットは、パケット長フィールド、パケットタイプフィールド、hCLient IDフィールド、逆方向リンクフラグフィールド、逆方向レート除数フィールド、方向転換1長フィールド、方向転換2長フィールド、パラメータCRCフィールド、全ゼロフィールド、方向転換1フィールド、逆方向データパケットフィールド、方向転換2フィールド、及び全ゼロ2フィールドとを有するように構造化されている。一実施形態では、この種のパケットは通常65型パケットとして識別される。外部モードの場合、あらゆるホストがこのパケットを生成し、データを受信することができなければならず、あらゆるクライアントは、所望のプロトコルと、結果として生じるスピードとを効率的に利用するために、データを受信し、ホストに送信できなければならない。このパケットのインプリメンテーションは内部モードの場合オプションであるが、ホストが、クライアントからデータを受信するために逆方向リンクカプセル化パケットが使用される。
MDDIリンクコントローラは、逆方向リンクカプセル化パケットの送信中特別に動作する。MDDIは、通常リンクのコントローラとしてホストによって常に駆動されるストローブ信号を有する。ホストは、それが逆方向リンクカプセル化パケットの方向転換部分と逆方向データパケット部分の各ビットについてゼロを送信しているかのように動作する。ホストは、2回の方向転換の間、及び逆方向データパケットに割り当てられる時間中、各ビット境界でMDDI_Strobe信号をトグルする。すなわち、ホストは、全ゼロ1フィールドの初めから、全ゼロ2フィールドの終わりまでMDDI_Stbをトグルする(これは、それがあたかも全ゼロデータを送信しているかのと同じ動作である。)。
ホストは、そのMDDIデータ信号線ドライバをディスエーブルし、一般に、方向転換1フィールドの最後のビットの前にそれらが完全にディスエーブルされたことを保証する。そして、方向転換2フィールドの間、そのラインドライバを再イネーブルし、一般に、方向転換2フィールドの最後のビットの前にそれらが完全に再イネーブルされたことを保証する。クライアントは方向転換長パラメータを読み取り、方向転換1フィールドの最後のビットの直後にホストに向かってデータ信号を起動する。すなわち、クライアントは、パケットコンテンツの以下の説明、及びそれ以外の箇所に指定されるようにMDDIストローブの特定の立ち上がりでリンクの中に新しいデータの時間を記録する(clocks)。クライアントは、それがホストにパケットを送信するために有する利用可能な時間の長さを知るためにパケット長と方向転換長のパラメータを使用する。クライアントは、ホストに送信するデータがないときには、フィラーパケットを送信する、あるいはデータラインをゼロ状態に駆動してよい。データラインがゼロに駆動されると、ホストはこれをゼロ長(有効長ではない)パケットとして解釈し、ホストは現在の逆方向リンクカプセル化パケットの期間中、クライアントからそれ以上のパケットを受け入れない。
一実施形態では、クライアント要求及びステータスパケットの逆方向リンク要求フィールドは、クライアントがデータをホストに送り返すために逆方向リンクカプセル化パケットの中で必要とするバイト数をホストに知らせるために使用されてよい。ホストは、逆方向リンクカプセル化パケットで少なくともそのバイト数を割り当てることによって要求を許可しようとする。ホストは1サブフレームで複数の逆方向リンクカプセル化パケットを送信してよい。クライアントはほぼつねにクライアント要求及びステータスパケットを送信してよく、ホストは1サブフレームで要求される総バイト数として逆方向リンク要求パラメータを解釈する。
9.クライアント機能パケット
ホストは、通常最適な又は所望される方法でホストからクライアントへのリンクを構成するためにそれが通信しているクライアント(ディスプレイ)の機能を知る必要がある。ディスプレイは、順方向リンク同期が取得された後にホストにクライアント機能パケットを送信することが薦められる。このようなパケットの伝送は、逆方向リンクカプセル化パケットで逆方向リンクフラグを使用してホストによって要求されるときに必須と見なされる。クライアント機能パケットは、ホストにクライアントの機能を知らせるために使用される。外部モードの場合、あらゆるホストはこのパケットを受信できるべきであり、あらゆるクライアントはこのインタフェースとプロトコルを完全に活用するためにこのパケットを送信できるべきである。この状況におけるディスプレイ、キーボード、又はその他の入力/出力デバイス等のクライアントの機能は、製造又はなんらかのタイプの単一の構成部品又は装置への組み込みの時点ですでに明確でなければならず、ホストに知られていなければならないので、このパケットのインプレイメンテーションは内部モードに対してはオプションである。
一実施形態でのクライアント機能パケットのフォーマットは図19に描かれている。図19に示されているように、この実施形態では、この種のパケットはパケット長フィールド、パケットタイプフィールド、cClientIDフィールド、プロトコルバージョンフィールド、最小プロトコルバージョンフィールド、データレート機能フィールド、インタフェースタイプ機能フィールド、代替(Alt)ディスプレイ数フィールド、予約1フィールド、ビットマップ幅フィールド、ビットマップ高さフィールド、ディスプレイウィンドウ幅フィールド、ディスプレイウィンドウ高さフィールド、カラーマップサイズフィールド、カラーマップRGB幅フィールド、RGB機能フィールド、白黒機能フィールド、予約2フィールド、Y Cr Cb機能フィールド、Bayer機能フィールド、予約3フィールド、クライアント特徴機能フィールド、最大ビデオフレームレートフィールド、最小ビデオフレームレートフィールド、最小サブフレームレートフィールド、音声バッファ深さフィールド、音声チャネル機能フィールド、音声サンプルレート機能フィールド、音声サンプル解像度フィールド、マイクオーディオサンプル解像度フィールド、マイクサンプルレート機能フィールド、キーボードデータフォーマットフィールド、ポインティングデバイスデータフォーマットフィールド、コンテンツ保護タイプフィールド、製造メーカ名フィールド、製品コードフィールド、予約4フィールド、シリアル番号フィールド、製造週フィールド、製造年フィールド及びCRCフィールドを有するように構造化されている。例示的な実施形態では、この種のパケットは通常、66型タイプとして認識される。
10.キーボードデータパケット
キーボードデータパケットは、クライアントデバイスからホストにキーボードデータを送信するために使用される。無線(又は有線)キーボードは、ヘッドマウントビデオディスプレイ/音声プレゼンテーション装置を含むが、これに限定されない多様なディスプレイ又は音声装置と共に使用されてよい。キーボードデータパケットは、複数の公知のキーボード状の装置の1つから受信されるキーボードデータをホストに中継する。この種のパケットはキーボードにデータを送信するために順方向リンクで使用することもできる。クライアントは、クライアント機能パケットのキーボードデータフィールドを使用してキーボードデータパケットを送受する能力を示す。
キーボードデータパケットのフォーマットは図20に示され、キーボードからの、又はキーボード用の可変数のバイトの情報を含んでいる。図20に示されているように、このパケットは、パケット長フィールド、パケットタイプフィールド、bClient IDフィールド、キーボードデータフォーマットフィールド、キーボードデータフィールド、及びCRCフィールドを有するように構造化されている。ここでは、この種のパケットは通常67型パケットとして識別される。
bClient IDは前述されたように予約されたフィールドであり、CRCはパケットの全バイトで実行される。キーボードデータフォーマットフィールドは、キーボードデータフォーマットを記述する2バイト値を含む。ビット6から0は、クライアント機能パケットのキーボードデータフォーマットと同一でなければならない。この値は127に等しくない。ビット15から7は、将来の使用のために予約されているため、現在はゼロに設定されている。
11.ポインティングデバイスデータパケット
ポインティングデバイスデータパケットは、クライアントからホストへ、無線マウス又は他のポインティングデバイスからの位置情報を送信するための方法、構造、又は手段に使用される。データはこのパケットを使用して順方向リンクでポインティングデバイスに送信することもできる。ポインティングデバイスデータパケットの例示的なフォーマットは図21に示され、ポインティングデバイスから、又はポインティングデバイス用の可変数のバイトの情報を含む。図21に示されているように、この種のパケットはパケット長フィールド、パケットタイプフィールド、bClient IDフィールド、ポインティングデバイスフォーマットフィールド、ポインティングデバイスデータフィールド、及びCRCフィールドを有するように構造化されている。例示的な実施形態では、この種のパケットは通常1バイトタイプフィールドにおける68型パケットとして識別される。
12.リンクシャットダウンパケット
リンクシャットダウンパケットは、MDDIデータとストローブがシャットダウンされ、低電力消費「ハイバネーション」状態に入ることを示す方法又は手段としてホストからクライアントに送信される。このパケットはリンクをシャットダウンし、静的ビットマップが移動通信装置からディスプレイに送信された後、あるいはホストからクライアントに当面転送する追加の情報がないときに電力を節約するために有効である。ホストがパケットを再び送信すると通常の動作が再開される。一つの実施形態の場合、ハイバネーション後に送信される最初のパケットはサブフレームヘッダパケットである。クライアントステータスパケットのフォーマットは図22に示されている。図22に示されているように、この種のパケットはパケット長フィールド、パケットタイプフィールド、CRCフィールド及び全ゼロフィールドを有するように構造化される。一実施形態では、この種のパケットは、通常1バイトタイプフィールドで69型パケットとして識別される。
パケット長フィールドは、パケット長フィールドを含んでないパケット内の合計バイト数を特定するために2バイト使用する。一つの実施形態では、このパケットのパケット長は、リンクシャットダウンパケットが送られた時において有効であるインタフェースタイプ又はリンクモードに依存する。従って、典型的なパケット長は、1型モードの場合には20バイト(パケット内で合計22バイト)、2型モードの場合には36バイト(パケット内で合計38バイト)、3型モードリンクの場合には68バイト(パケット内で合計70バイト)、及び4型モードの場合には132バイト(パケット内で合計134倍)となる。
全ゼロフィールドは、ホストのラインドライバをディスエーブルする前に、可変数のバイトを用いて、MDDI_Data信号が十分な時間の間、論理ゼロレベルにあることを確証し、クライアントが、MDDI_Stbのみを用いてクロックの回復を始めることを許可する。全ゼロフィールドの長さは、リンクシャットダウンパケットが送られた時に有効であるリンクオペレーティングモード又はインタフェースタイプに依存する。全ゼロフィールドの長さは、任意のインタフェースタイプ設定に対するMDDI_Stb上に64のパルスを生成することが意図されている。従って、各インタフェースタイプに対する全ゼロフィールドは、1型の場合16バイト、2型の場合32バイト、3型の場合64バイト、4型の場合128バイトとなる。
CRCフィールドは、パケット長さからパケットタイプへのバイトからなる16ビットCRCを含む2バイトを使用する。
低電力ハイバネーション状態では、MDDI_Data0ドライバは、16番目から48番目のMDDI_Stbサイクルの後、又は全ゼロフィールドの最終ビットの後に始まる高インピーダンス状態にディスエーブルされる。2型、3型、又は4型リンクの場合、MDDI_Data1からMDDI_DataPwr7信号までもまた、MDDI_Data0ドライバがディスエーブルされるのと同じ時間に、高インピーダンス状態に置かれる。ホスト又はクライアントのどちらかによって、MDDIリンクはどこか他の箇所に説明されるようにハイバネーション状態から「目覚め」させられ、それが本発明のための重要な進展であり、本発明の利点である。
全ゼロフィールドの定義において記述したように、MDDI_Stbは、クライアントコントローラにおける規則的なシャットダウンを容易にするために、リンクシャットダウンパケットのCRCフィールドのMSBに続く64サイクルのためにトグルする。1サイクルは、高−低遷移が後に続く低−高遷移であるか、低−高遷移が後に続く高−低遷移である。全ゼロフィールドが送られた後、ホスト内のMDDI_Stbドライバがディスエーブルされる。
13.クライアント要求及びステータスパケット
ホストは、それが通常最適にホストからクライアントへのリンクを構成できるように、クライアントから少量の情報を必要とする。クライアントがクライアント要求及びステータスパケットをサブフレームごとにホストに送信することが勧められる。クライアントは、それが確実にホストに配信されることを保証するために逆方向リンクカプセル化パケット内で最初のパケットとしてこのパケットを送信する必要がある。また、このパケットの転送は、逆方向リンクカプセル化パケット内で逆方向リンクフラグを使用してホストによって要求されるときに達成される。クライアント要求及びステータスパケットは、ホストにエラーとステータスを報告するために使用される。外部モード動作の場合、あらゆるホストはこのパケットを受信できなければならず、あらゆるクライアントはMDDIプロトコルを適切に又は最適に利用するためにこのパケットを送信できなければならない。それは、内部ホスト及び内部クライアントである内部動作の場合にも推奨されるが、パケットに対するサポートがあるべきであり、それは要求されない。
クライアント要求及びステータスパケットのフォーマットは図23に示されている。図23に示されるように、この種のパケットは、パケット長フィールド、パケットタイプフィールド、cClient IDフィールド、逆方向リンク要求フィールド、機能変更フィールド、クライアントビジーフィールド、CRCエラーカウントフィールド、及びCRCフィールドを有するように構造化されている。この種のパケットは、通常、1バイトタイプフィールドの70型パケットとして識別され、通常は12バイトという事前に選択された固定長を使用する。
逆方向リンク要求フィールドは、ホストのデータを送り返すために逆方向カプセル化パケットでクライアントが必要とするバイト数をホストに知らせるために使用されてよい。ホストは逆方向リンクカプセル化パケット内で少なくともその数のバイトを割り当てることによって要求を許可しようとしなければならない。ホストはデータに対処するためにサブフレーム内で複数の逆方向リンクカプセル化パケットを送信してよい。クライアントはいつでもクライアント要求及びステータスパケットを送信してよく、ホストは逆方向リンク要求パラメータを1つのサブフレームで要求されるバイトの総数として解釈する。逆方向リンクデータがどのようにしてホストに送り返されるのかの追加の詳細及び特定の例が後述される。
14.ビットブロック転送パケット
ビットブロック転送パケットは、一般に、一つの長方形領域から別の長方形領域にピクセルのブロックをコピーすることによって、任意の方向でディスプレイの領域をスクロールするための手段、構造、又は方法を提供する。この機能を有するクライアントは、クライアント機能パケットの表示特徴機能インジケータフィールドのビット0で機能を報告する。ビットブロック転送パケットの、一つの実施形態のフォーマットは図24に示されている。図24に示されているように、この種のパケットはパケット長フィールド、パケットタイプフィールド、hClient IDフィールド、ピクセルデータ属性フィールド、ラスタ動作フィールド、左上X値フィールド、左上Y値フィールド、ウィンドウ幅フィールド、ウィンドウ高さフィールド、ウィンドウX移動フィールド、ウィンドウY移動フィールド、及びCRCフィールドを有するように構造化されている。この種のパケットは通常71タイプパケットとして識別され、一つの実施形態では、15バイトという事前に選択された固定長を使用する。2バイトのhClient IDフィールドは、説明したようにクライアントIDのために予約された値又は情報を含んでいる。このフィールドは、一般に、将来の使用のために予約されているので、所望の情報を転送するために、当該技術における熟練者によってその他の値が設定又は使用されることも可能であるが、ビットを論理ゼロレベルに設定することによって、一般にゼロに設定される。
一つの実施例では、2バイトのピクセルデータ属性フィールドは、ピクセルデータがどこで更新されるべきかを特定する値を持つ。ここでは、ビット1とビット0とが、ピクセルデータが更新されるディスプレイを選択する。クライアントの主ディスプレイがステレオイメージをサポートしていないのであれば、クライアントは、主ディスプレイ内のピクセルデータを、01,10,又は11からなるビット組み合わせのうちの1つに作用させることができる。値11は、ステレオディスプレイ機能をサポートしていないクライアントにおける主ディスプレイに対処するために使用されることが推奨される。ビット[1:0]が値11をもつ場合、ピクセルデータは、左目及び右目の両方のフレームバッファ内で更新される。ビット[1:0]が値10を持つ場合、ピクセルデータは、左目のみのフレームバッファ内で更新される。ビット[1:0]が値01を持つ場合、ピクセルデータは、右目のみのフレームバッファ内で更新される。ビット[1:0]が値00を持つ場合、ピクセルデータは、ビット8乃至11で特定される別のディスプレイのフレームバッファ内で更新される。
ビット7及びビット6は、フレームバッファを特定するディスプレイ更新ビットとして作用する。このフレームバッファでは、ピクセルデータが更新又は書き込まれる。フレーム更新ビットの効果は、後で詳述する。ビット[7:6]が‘01’である場合、ピクセルデータは、オフライン画像バッファに書き込まれる。ビット[7:6]が‘00’である場合、ピクセルデータはディスプレイをリフレッシュするために使用される画像バッファに書き込まれる。ビット[7:6]が‘11’である場合、ピクセルデータは画像バッファに書き込まれる。ビット[7:6]が‘10’である場合、無効な値として扱われる。これらビットは今のところ、将来の使用のために予約されている。この状況では、コマンド全体が無視され、フレームバッファは更新されない。
ビット11乃至8は、4ビットの符号なし整数である。これは、ピクセルデータが更新されるべき代替クライアント位置、あるいは代替ディスプレイを特定する。ビット0とビット1は、クライアントが、ビット11乃至8を、代替ディスプレイ番号として解釈するために00に等しく設定される。ビット1とビット0とが00に等しくない場合には、ビット8乃至11は一般に論理ゼロ値あるいは論理ゼロレベルに等しく設定される。ビット2乃至5とビット12乃至15は、将来の使用のために予約され、一般に、論理ゼロ値又は論理ゼロレベルに設定される。
一つの実施例では、2バイトのラスタ動作フィールドが、宛先イメージ位置に書き込まれる新たなピクセル値を生成するために、ソース位置と宛先位置とにおけるピクセルをどのように合成するのかを特定する。ラスタ動作は、フレームバッファ内の等しい大きさの2つの異なる長方形領域が、どのようにして合成されるのかを定義する。宛先イメージ領域はまた、合成される2つのイメージのうちの一つである。2つのイメージのうちの2つ目は、ソースイメージと呼ばれる。クライアントが、クライアント機能パケット内で特定されたラスタ動作フィールドをサポートしない場合、ホストは、一般に、3に等しいビット3乃至0でパケットを送り、クライアントはビット3からビット0を無視する。
一つの実施例では、ビット3からビット0が、これらビットを用いることによって、あるいは、これらビットを、表VIIに示すように、値の次に示される動作を選択するために、表VIIに示す値の1つと等しく設定することによって、実際のラスタ動作を特定するために使用される。すなわち、第一カラムにリストされた各特定されたビット[3:0]値によって、第二カラムで特定され、明確化のために第三カラムで定義された動作になる。
Figure 2007534232
ビット5乃至4は、透明色に関連する場合、宛先ピクセルが宛先位置に書き込まれたか否かを特定するために使用される。ビット5乃至4で特定される動作は、ラスタ動作がクライアントデバイスによってサポートされているか否かを加える。クライアントがラスタ動作をサポートしないのであれば、結果として得られ、ビット5乃至4によって定義される動作のために考慮される宛先ピクセル値は、ソースピクセル値のみに等しくなる。
ビット[5:4]の値が00に等しい場合、透明色は使用されない。結果として得られる宛先ピクセルは、透明色イネーブルパケットによって定義される透明色の値を考慮することなく宛先ピクセル位置に書き込まれる。01に等しいビット[5:4]の値は、当該技術分野における熟練者が関連する使用を設定するように利用可能であれば、今のところ、将来の使用のために予約されており、使用されていない。ビット[5:4]の値が10に等しい場合、ラスタ動作による計算の結果として得られる宛先ピクセルが透明色に等しいのであれば、結果として得られるピクセルは宛先ピクセル位置には書き込まれない。そうでない場合には、宛先ピクセル位置に書き込まれる。ビット[5:4]の値が11に等しい場合、ラスタ動作による計算の結果として得られる宛先ピクセルが透明色に等しいのであれば、結果として得られるピクセルは、宛先ピクセル位置に書き込まれない。そうでない場合には、結果として得られるピクセルは、宛先ピクセル位置に書き込まれない。
ビット15乃至6は、将来の使用のために予約されており、一般的に、論理ゼロ値又は論理ゼロレベルに等しく設定されている。
残りのフィールドは、移動すべきウィンドウの上左隅のX座標値とY座標値、移動すべきウィンドウの幅及び高さ、水平方向、垂直方向それぞれに移動すべきウィンドウのピクセル数を特定するために使用される。後者の2フィールドの正の値によって、ウィンドウは、右及び下に移動し、負の値によって、左及び上にそれぞれ移動するようになる。CRCフィールド(ここでは2バイト)は、パケット長さを含むパケット内の全バイトのうちの16ビットCRCを含む。
15.ビットマップ領域塗りつぶしパケット
ビットマップ領域塗りつぶしパケットはディスプレイの領域を単一の色に容易に初期化する手段、構造、又は方法を提供する。この機能を有するディスプレイは、クライアント機能パケットのクライアント特徴機能インジケータフィールドのビット1で該機能を報告する。ビットマップ領域塗りつぶしパケットのフォーマットの一つの実施形態は図25に示されている。図25に示されているように、この場合、この種のパケットはパケット長フィールド、パケットタイプフィールド、hClientフィールド、左上X値フィールド、左上Y値フィールド、ウィンドウ幅フィールド、ウィンドウ高さフィールド、データフォーマット記述子フィールド、ピクセル領域塗りつぶし値フィールド、及びCRCフィールドを有するように構造化されている。この種のパケットは通常1バイト型フィールドで72型パケットとして識別され、20バイトという事前に選択された固定長を使用する。
2バイトのhClientフィールドは、説明したように、クライアントIDのために予約された情報又は値を含む。このフィールドは一般に将来の使用のために予約されているので、ビットを論理ゼロレベルに設定することによって、一般には現在値をゼロに設定している。しかしながら、当該技術分野における熟練者によってその他の値に設定又は使用され、所望の情報の転送のために使用されることもある。
16.ビットマップパターン塗りつぶしパケット
ビットマップパターン塗りつぶしパケットは、事前に選択されたパターンに表示の領域を容易に初期化する手段又は構造を提供する。この機能を有するディスプレイはクライアント機能パケットのクライアント特徴機能フィールドのビット2で該機能を報告する。塗りつぶしパターンの左上角は、水平又は垂直パターンが、ゼロ以外にオフセットされていなければ、塗りつぶされるウィンドウの左上角と位置合わせされている。塗りつぶされるウィンドウが塗りつぶしパターンより幅広い、又は背が高い場合には、パターンはウィンドウを塗りつぶすために何回も水平に又は垂直に繰り返されてよい。最後に繰り返されるパターンの右又は下部は必要に応じて切り捨てられる。ウィンドウが塗りつぶしパターンより小さい場合には、塗りつぶしパターンの右上又は右下がウィンドウに適合するために切り捨てられてよい。
水平パターンオフセットがゼロ以外であれば、ウィンドウの左隅と、この左隅に水平パターンオフセットとを加えたものとの間のピクセルが、最も右側のピクセルパターンで塗り潰される。水平パターンオフセットは、パターン幅未満になるべきである。同様に、垂直パターンオフセットがゼロ以外であれば、ウィンドウの上側と、この上側に垂直パターンオフセットを加えたものとの間のピクセルが、最も下側のピクセルパターンで塗り潰される。垂直パターンオフセットは、パターン高さ未満になるべきである。
ビットマップ塗りつぶしパケットのフォーマットの一つの実施形態は図26に示されている。図26に示されているように、この種のパケットは、パケット長フィールド、パケットタイプフィールド、hClient IDフィールド、左上X値フィールド、左上Y値フィールド、ウィンドウ幅フィールド、ウィンドウ高さフィールド、パターン幅フィールド、パターン高さフィールド、水平パターンオフセットフィールド、垂直パターンオフセットフィールド、データフォーマット記述子フィールド、パラメータCRCフィールド、パターンピクセルデータフィールド及びピクセルデータCRCフィールドを有するように構造化されている。ある実施形態では、この種のパケットは通常1バイト型フィールドで73型パケットとして識別される。
17.通信リンクデータチャネルパケット
通信リンクデータチャネルパケットは、PDA等の高水準計算機能を備えたクライアントが携帯電話、又は無線データポート装置等の無線トランシーバと通信するための構造、手段、又は方法を提供する。この状況では、MDDIリンクは、通信装置とモバイルディスプレイ付きの計算装置の間の便利な高速インタフェースとして働いており、このパケットはデータを該装置のオペレーティングシステムのデータリンク層でトランスポートする。例えば、このパケットは、ウェブブラウザ、eメールクライアント、又はPDA全体がモバイルディスプレイの中に内蔵されている場合に使用できるであろう。この機能を有するディスプレイはクライアント機能パケットのクライアント特徴機能フィールドのビット3で該機能を報告する。
通信リンクデータチャネルパケットのための実施形態のフォーマットは図27に示されている。図27に示されているように、この種のパケットは、パケット長フィールド、パケットタイプフィールド、hClient IDフィールド、パラメータCRCフィールド、通信リンクデータフィールド、及び通信データCRCフィールドを有するように構造化されている。一つの実施形態では、この種のパケットは、通常、タイプフィールドで74型パケットとして識別される。
18.ディスプレイ電力ステータスパケット
ディスプレイ電力ステータスパケットは、システムリソース上のドレイン又はシステム電力消費を最小にするために、ディスプレイのようなクライアントが使用されていないか、あるいは現在アクティブに使用されている場合に、特定のクライアント制御された、又はクライアントに関連付けられた、あるいは接続されたコントローラハードウェアを低電力状態にするための構造、手段、又は方法を提供する。この種のパケットは、外部モード設定もしくは動作のためのインタフェース又はインタフェース構造、及びプロトコルのアプリケーションのために最も役に立つ。これらアプリケーションでは、外部デバイスは、恐らくは、例えばバッテリのように制限された電力リソースで動作するか、例えば限定された空間内でのオーバヒートのようなその他の電力制約及び不安を持っている。従って、期間中、又はアクティブではない場合、若しくは非使用時には最小の動作状態が望まれる。一つの実施例では、クライアントが、クライアント機能パケットのクライアント特徴機能インジケータフィールドのビット9を用いて、ディスプレイ電力ステータスパケットに応答する能力を示す。
図28には、ディスプレイ電力ステータスパケットのための一つの実施例のフォーマットが示されている。図28に示すように、一つの実施例では、この種のパケットは、パケット長さフィールド、パケットタイプフィールド、hClient IDフィールド、電力状態フィールド、及びCRCフィールドを持つように構成されている。この種のパケットは一般に2バイトタイプフィールド内のタイプ75パケットとして識別される。2バイトのhClient IDフィールドは、既に述べたように、Client IDのために予約された値又は情報を含んでいる。このフィールドは将来の使用のために予約されており、当該技術における熟練者によって、所望の情報を転送するように使用することができるが、現在は、ビットをゼロに設定することによってゼロに設定されている。
ここでは2バイトである電力状態フィールドは、特定のデバイス、ハードウェアの一部、あるいは例えばディスプレイのようなクライアントに関連付けられた機器を、特定の電力状態にするために使用される情報を特定する。ディスプレイのために使用される場合、このフィールドのビット0は、このパケットがメインディスプレイ又は代替ディスプレイに当てはまるか否かを特定する。ビット0が1に等しい場合には、パケットはメインディスプレイに当てはまる。ビット0が0に等しい場合には、パケットは、ビット11乃至8によって特定される代替ディスプレイに当てはまる。ビット1は、将来の使用のために予約され、一般的にはゼロに設定されている。
電力状態フィールドのビット3乃至2は、ビット11乃至8及びビット0によって選択されたディスプレイの電力状態を特定する。ビット[3:2]が‘00’の値を持っている場合には、この状態の間、選択されたディスプレイは照明されず、最小の電力量を消費するようにされ、フレームバッファの内容の保持は保証されない。ビット[3:2]が‘01’の値を持っている場合には、この状態の間、選択されたディスプレイは照明されず、比較的少量の電力が消費され、フレームバッファの内容の保持が保証される。ディスプレイは、この状態では、状態00よりも多くの電力を消費する。クライアントは、クライアント機能パケットのクライアント特徴機能インジケータフィールドのビット10を用いて、状態01をサポートする能力を示すことができる。電力状態フィールドのビット[3:2]が‘10’の値を持っている場合には、選択されたディスプレイが照明され、関連するフレームバッファからの画像を表示する。ビット[3:2]の値‘11’は、将来の使用のために予約された値又は状態であり、使用されていない。
当該技術分野における熟練者であれば、このパケットの利用は、ディスプレイ用途に最も役立つが、本発明ではディスプレイのみに限定されず、MDDIが使用され、クライアントが制御又は通信しているその他のハードウェア要素に関連して必要又は要求されるその他の用途、設定、又は状態が存在しうることを認識するであろう。これらの状態では、上述したビットは、類似の機能を持ちうるが、理解されるように、それら要素の第一及び第二のものを起動したり、電力レベルを設定したりしうる。
一つの実施例では、電力状態フィールドのビット11乃至8は、電力状態が適用される代替ディスプレイを特定する4ビット符号なし整数となる。クライアントが、ビット11乃至8を代替ディスプレイ番号と解釈するために、ビット0は、理論ゼロ値に設定される。ビット0が1に等しいのであれば、ビット11乃至8はゼロである。
ビット7乃至4及びビット15乃至12は、将来の使用のために予約され、現在のアプリケーション又は設計のために一般に理論ゼロレベル又は理論ゼロ値に設定されている。
2バイトのCRCフィールドは、パケット長さを含み、パケット内の全バイトのCRCを特定するか、あるいは含む。
ディスプレイ電力ステータスが一般にインタフェース構造又はプロトコルによってサポートされている要約を、表VIIIを示す。これを見て分かるように、クライアント特徴機能ビット10及び9の様々な組み合わせが、所望の電力状態のうちの一つを確立、設定、又はトリガするために使用されている。所定の行及び列位置に存在する印は、その列のトップで特定されているディスプレイ電力ステータスが、クライアント特徴機能インジケータビットの組み合わせでサポートされていることを示す。
Figure 2007534232
19.実行型ハンドオフパケット
実行型ハンドオフパケットは、ホストが、このパケットで指定されるモードにハンドオフするようにクライアントに命令するために使用する手段、構造、又は方法である。これは、クライアント機能パケットで説明したように、クライアントによってサポートされているインタフェースタイプ設定のうちの一つであるべきである。ホストとクライアントは、このパケットが送信された直後に、具体的な順方向及び逆方向リンクインタフェースタイプに切り替わるべきである。実行型ハンドオフパケットの一つの実施形態のフォーマットは図29に示されている。タイプ1以外のインタフェースタイプをサポートするホストとクライアントとは、このパケットのためのサポートを備えるべきである。クライアントがホストと同期していることを確認するために、ホストが、実行型ハンドオフパケットを送る直前に、クライアント要求とステータスパケットとをリードすることが一般に推奨される。
図29に示すように、一つの実施例では、この種のパケットが、パケット長さフィールド、パケットタイプフィールド、インタフェースタイプフィールド、予約1フィールド、遅延フィラーフィールド、及びCRCフィールドを持つように構成される。この種のパケットは一般に、2バイトのタイプフィールド内のタイプ77パケットとして特定され、パケット長さフィールドと遅延フィラーフィールドの外部である6バイトの予め選択された固定長さを使用する。
一つの実施例では、インタフェースタイプフィールドは、リンクのために使用又は適用される新たなインタフェースタイプを確認するために、1バイト値を使用する。このフィールドにおける値は、以下に示す手法で、インタフェースタイプを特定又は表示する。ビット2乃至0は順方向リンクで使用されるインタフェースタイプを定義する。ここで、値1はタイプ1モードへの、値2はタイプ2モードへの、値3はタイプ3モードへの、値4はタイプ4モードへのハンドオフをそれぞれ意味又は特定する。ビット5乃至3は、逆方向リンクで使用されるインタフェースタイプを定義し、値1はタイプ1モードへの、値2はタイプ2モードへの、値3はタイプ3モードへの、値4はタイプ4モードへのハンドオフをそれぞれ意味又は特定する。ビット0,6,7は現在、将来の使用のために予約されており、必ずしも必要ではないが、一般に理論ゼロレベルに設定されている。
遅延フィラーは、クライアントが、システムの一部に、実行インタフェースタイプハンドオフパケットのすぐ後に続くパケットの始めに設定する新たなインタフェースタイプを用いるための使用又は設定のために切り換えられるように準備又は設定するための十分な時間を与える手段、構造、又は方法として生成された。このフィールドは、全てが論理ゼロレベルに設定されているか、論理ゼロ値に等しく設定されている8ビット値又はビットグループを含む。このフィールドで使用されているバイト数は、64MDDI_Stbサイクルに等しい長さであるフィールドになるように選択される。遅延フィラーフィールドの長さは、タイプ1順方向リンクインタフェースタイプの場合には16バイト、タイプ2インタフェースの場合には32バイト、タイプ3インタフェースの場合には64バイト、タイプ4順方向リンクインタフェースタイプを特定又は使用している場合には128バイトである順方向リンクのインタフェースタイプ設定に基づいている。
予約1フィールド(ここでは1バイト)は、情報を伝える場合の将来の使用のために予約されている。このフィールド内の全てのビットは、一般に論理ゼロレベルに設定されている。このようなフィールドの目的は、今のところ、次に続く全ての2バイトフィールドを、16ビットワードアドレスにそろえさせ、4バイトフィールドを、32ビットワードアドレスにそろえさせることである。CRCフィールド(ここでは2バイト)は、パケット長さを含むパケット内の全てのバイトの16ビットCRCを含む。
20.順方向音声チャネルイネーブルパケット
このパケットは、ホストがクライアントの音声チャネルをイネーブル又はディスエーブルできるようにする構造、方法、又は手段を提供する。この機能は、クライアント(例えばディスプレイ)が、ホストによって出力される音声がないときに節電するために音声増幅器又は類似する回路要素の電源を切ることができる。これは、単にインジケータとして音声ストリームの存在又は不在を使用して暗示的に実現するのはかなり困難である。クライアントシステムの電源投入時のデフォルト状態は、すべての音声チャネルがイネーブルされることである。順方向音声チャネルイネーブルパケットの一つの実施形態のフォーマットは図30に示されている。図30に示されているように、この種のパケットはパケット長フィールド、パケットタイプフィールド、hClient IDフィールド、音声チャネルイネーブルマスクフィールド、及びCRCフィールドを有するように構造化されている。この種のパケットは、通常、1バイト型フィールドで78型パケットとして識別され、4バイトという事前に選択された固定長を使用する。
21.逆方向音声サンプルレートパケット
この種のパケットは、ホストが、クライアント内の音声チャネルをイネーブル又はディセーブルすることを可能にする構造、方法、及び手段を提供する。この機能は有用であり、クライアントは、ホストによって出力される音声が存在しない場合には、電力を節約するために、音声アンプの電源をオフにすることができる。音声ストリームの存在又は不在を用いて絶対的に実行するのは非常に難しい。クライアントシステムの電源がオンされたか、あるいはホストに接続された場合であるデフォルト状態は、全ての音声チャネルがイネーブルされている。ホスト及びクライアントに接続された音声システムは、0から1へ状態又は値を遷移した音声チャネルイネーブルマスクフィールド内のビットのうちの少なくとも一つを持つ順方向音声チャネルイネーブルパケットをクライアントが受け取った後、約100ミリ秒かそれ以内のうちに、意図した方法、あるいは所望の方法で音声信号の出力を準備するか、あるいは出力できなくてはならない。クライアントは、クライアント機能パケットの音声チャネル機能フィールドのビット15に設定された値を用いて順方向音声チャネルイネーブルパケットへ応答する能力を示す。
このパケットは、ホストが、逆方向リンク音声チャネルをイネーブル又はディスエーブルし、このストリームの音声データサンプルを設定できるようにする。ホストはクライアント機能パケットの中で有効であると定義されるサンプルレートを選択する。ホストが無効なサンプルレートを選択すると、クライアントはホストに音声ストリームを送信せず、適切なエラー、エラー値、又はエラー信号がクライアントエラーレポートパケットでホストに送信されてよい。ホストはサンプルレートを255という値に設定することによって逆方向リンク音声ストリームをディスエーブルしてよい。クライアントシステムが最初に電源を入れられる、あるいは接続されるときに想定されるデフォルトの状態は、逆方向リンク音声ストリームがディスエーブルされている状態である。逆方向音声サンプルレートパケットの一つの実施形態のフォーマットは、図31に示されている。図31に示されているように、この種のパケットはパケット長フィールド、パケットタイプフィールド、hClient IDフィールド、音声サンプルレートフィールド、予約1フィールド、及びCRCフィールドを有するように構造化されている。この種のパケットは、通常79型パケットとして識別され、4バイトという事前に選択された固定バイトを使用する。
22.デジタルコンテンツ保護オーバヘッドパケット
このパケットは、ホストとクライアントが使用されているデジタルコンテンツ保護方法に関してメッセージを交換できるようにする構造、方法、又は手段を提供する。現在、デジタル伝送コンテンツ保護(DTCP)又は高帯域幅デジタルコンテンツ保護システム(HDCP)という、将来の代替保護方式名称のために空間が予約される、二種類のコンテンツ保護が熟考されている。使用されている方法はこのパケットのコンテンツ保護タイプパラメータによって指定される。デジタルコンテンツ保護オーバヘッドパケットの一つの実施形態のフォーマットは図32に示されている。図32に示されているように、この種のパケットはパケット長フィールド、パケットタイプフィールド、bClientIDフィールド、コンテンツ保護タイプフィールド、コンテンツ保護オーバヘッドメッセージフィールド、及びCRCフィールドを有するように構造化されている。この種のパケットは通常80型パケットとして識別されている。
23.透明色イネーブルパケット
透明色イネーブルパケットは、どの色がディスプレイで透明であるのかを指定するため、及び画像を表示するために透明色の使用をディスエーブルするために使用される構造、方法、又は手段である。この機能を有するディスプレイはクライアント機能パケットのクライアント特徴機能フィールドの4でその機能を報告する。透明色の値が付いたピクセルがビットマップに書き込まれると、色は過去の値から変化しない。透明色イネーブルパケットのフォーマットは図33に示されている。図33に示されているように、一つの実施形態では、この種のパケットはパケット長フィールド、パケットタイプフィールド、hClient IDフィールド、透明色イネーブルフィールド、予約1フィールド、アルファ−カーソル識別子フィールド、データフォーマット記述子フィールド、透明ピクセル値フィールド、及びCRCフィールドを有するように構造化されている。この種のパケットは、通常、1バイト型フィールドで81型パケットとして識別され、事前に選択される10バイトという固定長を使用する。
24.往復遅延測定パケット
往復遅延測定パケットは、クライアント(ディスプレイ)からホストへ戻る遅延を加えた、ホストからクライアント(ディスプレイ)への伝搬遅延を測定するために使用される構造、方法、又は手段を提供する。この測定は、本来、ラインドライバとラインレシーバ、及び相互接続サブシステムに存在する遅延を含む。測定は、方向転換遅延と逆方向リンク速度除数パラメータを、通常前記に説明される逆方向リンクカプセル化パケットに設定するために使用される。このパケットは、MDDIリンクが特定の応用例に意図された最大速度で運転しているときに最も有効である。パケットは、往復遅延測定の範囲を増加するために、1型モードで、低いデータレート送信される。MDDI_Stb信号は、あたかも全ゼロデータが以下のフィールドの間に送信されているかのように動作する。つまり両方のガード時間、全ゼロ、及び測定期間である。これによりMDDI_Stbは、それが測定期間中にクライアント内の周期クロックとして使用できるようにデータレートの半分でトグルする。
一実施形態では、クライアントは、通常、クライアント機能パケットのクライアント特徴機能インジケータフィールドのビット18を使用することにより往復遅延測定パケットをサポートする能力を示す。すべてのクライアントが往復遅延測定をサポートすることが薦められるが、ホストは最大ケーブル遅延に基づいて、及び最大ドライバと受信機遅延に基づいて最悪のケースの往復遅延を知ることが可能である。これはインタフェースが使用されている装置の公知の設計要素(銅線長、回路網種類、及び特徴等)の一態様であるため、ホストは、内部モードで使用されるMDDIリンクに先行して往復遅延を知る可能性もある。
往復遅延測定パケットのフォーマットは図34に示されている。図34に示されているように、一実施形態では、この種のパケットはパケット長フィールド、パケットタイプフィールド、hClient IDフィールド、パラメータCRCフィールド、ガード時間1フィールド、測定期間フィールド、全ゼロフィールド、及びガード時間2フィールドを有するように構成されている。この種のパケットは、通常82型パケットとして識別され、159ビットという事前に選択された固定長を使用する。
往復遅延測定パケットの間に発生するイベントのタイミングは図35に示されている。図35では、ホストは、全ゼロフィールドとガード時間1フィールドが後に続くパラメータCRCフィールドとストローブ位置合わせフィールドの存在によって示される往復遅延測定パケットを送信する。パケットがクライアントディスプレイ装置又は処理回路網に達する前に遅延3502が発生する。クライアントがパケットを受信すると、それはクライアントにより決定されるような測定期間の始まりにできる限り正確に、0xff、0xff及び0x0パターンの30バイトを送信する。クライアントがこのシーケンスの送信を開始する実際の時間は、ホストの観点では測定期間の始まりから遅延している。この遅延の量が実質的に、パケットがラインドライバとレシーバを通して伝搬し、サブシステム(ケーブル、導線)を相互接続するために要する時間である。類似する遅延の量3504が、パターンがクライアントからホストに伝搬して戻るパターンについて発生する。
クライアントに、及びクライアントから行き来する信号のために往復遅延時間を正確に決定するために、ホストは、測定期間の開始後、0xff、0xff、及び30バイトの0x0シーケンスの始まりが到着時に検出されるまでに発生する順方向リンクビット時間期間の数をカウントする。この情報は、往復遅延信号がホストからクライアント、及び再び逆に通過する時間量を求めるために使用される。したがって、この量の約2分の1はクライアントへの信号の一方向の通過のために生じる遅延を原因とする。
ホストとクライアントの両方とも、MDDI_DATAラインを定められた状態に保つために、両方のガード時間中にラインを論理ゼロレベルに駆動する。両方のガード時間中におけるホストとクライアントのイネーブル時間及びディスエーブル時間が、MDDI_Data信号が、あらゆる有効な往復遅延時間に対して有効な低レベルにあるようにされる。
25.順方向リンク歪み校正パケット
順方向リンク歪み校正パケットは、クライアント又はディスプレイがMDDI_Stb信号に関してMDDI_Data信号の伝搬遅延での差異がないかそれ自体を校正できるようにする。遅延歪み補償を行わないと、最大データレートは通常これらの遅延の潜在的な最悪のケースの変動を考慮に入れるために制限される。通常、このパケットは、順方向リンクデータが約50Mbps以下の速度に構成されるときにだけ送信される。ディスプレイを校正するためにこのパケットを送信した後に、データレートは50Mbpsを超えて強化される。データレートが歪み補償プロセスの間に高く設定しすぎると、ディスプレイは、遅延歪み補償設定値を1ビットを超える時間オフにし、その結果誤ったデータクロッキングを生じさせる結果となる、ビット期間のエイリアスに同期する可能性がある。最高データレートタイプのインタフェース又は最大可能インタフェースタイプは、すべての既存のデータビットが校正されるように、順方向リンク歪み校正パケットを送信する前に選択される。
順方向リンク歪み校正パケットのフォーマットの一つの実施形態は図56に示されている。図56に示されているように、この種のパケットはパケット長(2バイト)フィールド、パケットタイプフィールド、hClient IDフィールド、パラメータCRCフィールド、全ゼロフィールド、校正データシーケンスフィールド及びCRCフィールドを有するように構造化されている。この種のパケットは通常、タイプフィールドで83型タイプとして識別され、519という事前に選択された長さを有する。
仮想制御パネル
仮想制御パネル(VCP)を使用すると、ホストはクライアントで特定のユーザ制御を設定できる。これらのパラメータをホストにより調整できるようにすることによって、クライアントのユーザインタフェースは、ユーザが音声音量又はディスプレイ明度等のパラメータを調整できるようにする画面がクライアント内の1台又は複数台のマイクロプロセッサによってよりむしろホストソフトウェアによって生成できるために簡略化できる。ホストは、クライアントのパラメータ設定値を読み取り、制御ごとの有効値の範囲を求める能力を有する。クライアントは、一般に、どの制御パラメータを調整できるのかをホストに報告する能力を有する。
制御コード(VCPコード)及び一般的に指定される関連データ値は、クライアントの制御と設定値を指定するために活用される。MDDI指定のVCPコードはパケット定義における適切なデータフィールド位置合わせを保存するために、及び将来、このインタフェースに、又は将来の機能強化に一意である補足値をサポートするために16ビットに拡大される。
26.VCP特徴要求パケット
VCP特徴要求パケットは、ホストが特定の制御パラメータ又はすべての有効な制御パラメータの現在の設定値を要求するための手段、機構又は方法を提供する。一般的には、クライアントはVCP特徴応答パケットで適切な情報でVCPパケットに応答する。一実施形態では、クライアントはクライアント機能パケットのクライアント特徴機能インジケータのビット13を使用してVCP特徴要求パケットをサポートする能力を示す。
VCP特徴要求パケットのフォーマットは図69に示されている。図69で見られるように、この種のパケットは、パケット長フィールド、パケットタイプフィールド、hClient IDフィールド、MCCS VCPコードフィールド及びCRCフィールドを有するように構造化されている。この種のパケットは、通常、2バイト型フィールドに示されている128型として一実施形態で識別される。パケット長フィールドを含まないパケット内のビットの総数を指定するパケット長は、通常、8ビットという長さでこの種のパケットに固定されている。
hClient IDフィールドは、将来の実施においてクライアントIDとして使用するために予約され、一般にゼロに設定されるMCCS VCPコードフィールドは、MCCS VCP制御コードパラメータを指定する2バイトの情報を備える。0から255の範囲の値は、VCP特徴応答パケットを指定されたMCCSコードに対応するVCP特徴応答リスト内の単一のアイテムと共に返させる。65535(0xfff)というMCCS VCPコードは、クライアントによってサポートされる制御ごとに特徴応答リストアイテムを含むVCP特徴応答リスト付きのVCP特徴応答パケットを要求する。このフィールドのための256から65534までの値は、将来の使用のために予約され、現在は使用されていない。
27.VCP特徴応答パケット
VCP特徴応答パケットは、クライアントが特定の制御パラメータ又はすべての制御パラメータの現在の設定値でホスト要求に応えるための手段、機構又は方法を提供する。一般的には、クライアントはVCP特徴要求パケットに応えてVCP特徴応答パケットを送信する。このパケットは、特定のパラメータの現在設定値を突き止め、特定の制御のための有効な範囲を決定し、特定の制御がクライアントによってサポートされているかどうかを判断し、あるいはクライアントによってサポートされている制御のセットを決定するために有効である。クライアント内で実現されない特定の制御を参照するVCP特徴要求が送信される場合、VCP特徴応答パケットは適切なエラーコードを含む実現されていない制御に対応する単一VCP特徴応答リストアイテムと共に返される。一実施形態では、クライアントは、クライアント機能パケットのクライアント特徴機能フィールドのビット13を使用してVCP特徴応答パケットをサポートする能力を示す。
一実施形態でのVCP特徴応答パケットのフォーマットは図70に示されている。図70で分かるように、この種のパケットは、パケット長フィールド、パケットタイプフィールド、cClient IDフィールド、MCCSバージョンフィールド、応答シーケンス番号フィールド、VCP特徴応答リストフィールド、及びCRCフィールドを有するように構造化されている。通常一実施形態では、この種のパケットは、2バイト型フィールドに示されるように129型として識別される。
cClient IDフィールドはクライアントIDに予約される情報を含む。このフィールドは将来の使用のために予約され、通常はゼロに設定されている。MCCSバージョンフィールドは、クライアントによって実現されるVESA MCCS仕様のバージョンを指定する2バイトの情報を含む。
2バイトの応答シーケンス番号フィールドは、クライアントによって返されるVCP特徴応答パケットのシーケンス番号を指定する情報又はデータを含む。クライアントは65535というMCCS制御コード値と共に、VCP特徴要求パケットに応えて1つ又は複数のVCP特徴応答パケットを返す。クライアントは複数のVCP特徴応答パケットによって特徴応答リストを拡散又は転送してよい。この場合、クライアントは各連続パケットにシーケンス番号又は識別子を割り当てるべきである。そして、単一のVCP特徴要求パケットに応えて送信されるVCP特徴応答パケットのシーケンス番号は一般にゼロで開始し、1つずつ増分する。最後のVCP特徴応答パケット内のVCP特徴リストアイテムはパケットが最後のパケットであることを識別するために0xffffに等しいMCCS VCP制御コード値を含まなければならず、返されるパケットのグループの最高のシーケンス番号を含む。ただ1つのVCP特徴応答パケットがVCP特徴要求パケットに応えて送信される場合、その単一のパケット内の応答シーケンス番号は一般にゼロに設定され、VCP特徴応答リストは、0xffffに等しいVCP特徴応答リストアイテム内のMCCS VCPコードを有するリストアイテムを含む。VCP特徴応答リストアイテムパケット内の最大値フィールド及び現在値フィールド(図71)は、MCCS VCP制御コードが0xffffに等しい場合、ゼロに設定される。
VCP特徴応答リストフィールドは1つ又は複数のVCP特徴応答リストアイテムを含むバイトのグループである一方、リストフィールド内の特徴の数は、このパケットの中のVCP特徴応答リスト内にあるVCP特徴応答リストアイテム数を指定する2バイトを含む。一実施形態での単一のVCP特徴応答リストアイテムのフォーマットは図71に示される。
図71に示されているように、各VCP特徴応答リストアイテムは長さが正確に12バイトであり、MCCS VCPコードフィールド、結果コードフィールド、最大値フィールド及び現在値フィールドを備える。2バイトのMCCS VCP制御フィールドはこのリストアイテムと関連付けられるMCCS VCP制御コードパラメータを指定するデータ又は情報を含む。この実施形態では、VESA MCCS仕様書バージョン2以降に定められる制御コード値だけが有効と見なされる。2バイト結果コードフィールドは指定されたMCCS VCP制御に関して情報の要求に関係するエラーコードを指定する情報を含む。「1」という値が、指定された制御がクライアントで実現されないことを意味する一方、このフィールドの「0」という値はエラーがないことを意味する。2から65535のこのフィールドの追加の値は、将来の使用及び技術によって考慮される他の応用例のインプリメンテーションのために現在予約されているが、当面使用されることはない。
4バイトの最大値フィールドは、指定されたMCCS制御を設定できる最大可能値を指定する。要求される制御がクライアントの中で実現されない場合、この値はゼロに設定される。返された値の長さが32ビット(4バイト)未満である場合は、値は32ビット整数の中に入れられ、最上位(未使用)バイトをゼロに設定されたままにする。4バイトの現在値提示フィールドは、指定されたMCCS VCP連続(C)又は非連続(NC)制御の現在値を指定する情報を含む。要求された制御がクライアントで実現されない場合、あるいは制御が実現されるが、テーブル(T)データ型である場合には、この値はゼロに設定される。指定されたMCCS VCPが、不連続制御又はテーブルデータ型式に対応している場合、この最大値フィールドは、ゼロに設定又は選択される。
28.VCP特徴設定パケット
VCP特徴設定パケットは、ホストがクライアント内での連続制御と非連続制御の両方にVCP制御値を設定するための手段、機構又は方法を提供する。一実施形態では、クライアントはクライアント機能パケットのクライアント特徴機能フィールドのビット13を使用してVCP特徴設定パケットをサポートする能力を示す。
一実施形態におけるVCP特徴設定パケットのフォーマットは図72に示されている。図72で分かるように、この種のパケットはパケット長フィールド、パケットタイプフィールド、hClient IDフィールド、MCCS VCPコードフィールド、リスト中の値数フィールド、制御値リストフィールド、及びCRCフィールドを有するように構造化されている。この種のパケットは、通常、2バイト型フィールドで示されるように130型として識別され、パケット長フィールドを除き20バイトの長さである。
hClient IDフィールドは再びクライアントIDとして指定するために、あるいはClient IDとして働くために2バイト値を使用する。このフィールドは将来の仕様のために予約され、現在はゼロに設定されている。MCCS VCPコードフィールドは、調整されるMCCS VCPコードパラメータを指定するための2バイトの情報、又は値を使用する。2バイトのリスト中の値数フィールドは、制御値リストに存在する16ビット値の数を指定する情報又は値を含む。制御値リストは、MCCS制御コードがクライアント内のテーブルに関連しない限り通常1つのアイテムを含む。非テーブル関連制御の場合、制御値リストはMCCS VCPコードフィールドにより指定される制御パラメータに書き込まれる新しい値を指定する値を含むであろう。テーブル関連制御の場合、制御値リスト中のデータのフォーマットは指定されたMCCS VCPコードのパラメータ説明によって指定される。リストが1バイトより大きい値を含む場合には、どこか他の箇所に定義される方法に一貫して最下位ビットが最初に送信される。最後に2バイトのCRCフィールドが、パケット長を含むパケット内のすべてのバイトの16ビットCRCを含む。
29.有効パラメータ要求パケット
有効パラメータ要求パケットは、クライアントが指定された非連続(NC)又は表(T)制御によってサポートされているパラメータのリストを含む有効パラメータ応答パケットを返すことを要求するために役立つ手段又は構造として使用される。このパケットは、非連続(NC)制御又はクライアントの表に関連する制御だけを指定しなければならず、すべての制御を指定するために65535(0xffff)というMCCS VCPコード値を指定してはならない。サポートされていない、又は無効のMCCS VCPコードが指定される場合には、適切なエラー値が有効パラメータ応答パケットで返される。一実施形態では、クライアントは表示機能パケットのクライアント特徴機能フィールドのビット13を使用して有効パラメータ要求パケットをサポートする能力を示す。
一実施形態における有効パラメータ要求パケットのフォーマットは図73に示されている。図73に示されているように、この種のパケットはパケット長フィールド、パケットタイプフィールド、hClient IDフィールド、MCCS VCPコードフィールド及びCRCフィールドを有するように構造化されている。この種のパケットは、2倍と型フィールドに示されているように、通常131型として1つの実施形態で識別されている。
2バイトのパケット長フィールドに示されているようにパケット長は、通常、8というパケット長フィールドを含まずにパケット内のバイトの総数を有するために設定される。hClient IDは再びクライアントIDを指定するが、当業者に明らかとなるように現在は将来の使用のために予約されており、ゼロに設定されている。2バイトのMCCS VCPコードフィールドは、照会される非連続MCCS VCP制御コードパラメータを指定する値を含む。このフィールドの値はクライアントで実現される非連続制御に相当する。値256から65535(0xffff)は通常、予約されるか、あるいは有効と見なされ、エラー応答の中で実現される制御として見なされている。
30.有効パラメータ応答パケット
有効パラメータ応答パケットは、有効パラメータ要求パケットに応えて送信される。それは、非連続MCCS VCP制御又は表のコンテンツを返す制御のための有効な設定値を識別するための手段、方法又は構造として使用される。制御がクライアント内の表に関する場合、VCPパラメータ応答リストは単に要求された順次表値の特定なリストを含むだけである。表のコンテンツが単一の有効パラメータ応答パケットに適合しない場合、順次応答シーケンス番号の付いた複数のパケットがクライアントによって送信できる。一実施形態では、クライアントはクライアント機能パケットのクライアント特徴機能フィールドのビット13を使用して有効パラメータ応答パケットをサポートする能力を示す。
ホストは、次のようにテーブルのコンテンツを要求してよい。ホストは、読み取り/書き込みパラメータ、ルックアップテーブル(LUT)オフセット、及びRGB選択等の必要な又は所望されるパラメータを含むVCP特徴設定パケット設定を送信する。それから所望される制御を指定する有効パラメータ要求パケットがホストによって送信され、次にクライアントが、表データを含む1つ又は複数の有効パラメータ応答パケットを返す。動作のこのシーケンスがMCCS動作モデルに説明される表読み取り機能として類似する機能を実行する。
特定のクライアントパラメータがクライアントによってサポートされていない場合には、一実施形態においてこのパケットの対応するフィールドは255という値を含むであろう。クライアントで使用されるパラメータの場合、対応するフィールドはクライアント内にパラメータの値を含む必要がある。
一実施形態の有効パラメータ応答パケットのフォーマットは図74に示されている。図74で分かるように、この種のパケットはパケット長フィールド、パケットタイプフィールド、cClient IDフィールド、MCCS VCPコードフィールド、応答コードフィールド、シーケンス番号応答フィールド、リスト中の番号値フィールド、VCPパラメータ応答リストフィールド及びCRCフィールドを有するように構造化されている。この種のパケットは、通常、2バイト型フィールドに示されているように132型として一実施形態について識別される。
3バイトMCCS VCPコードパケットはこのパケットによって記述される非連続MCCS VCP制御コードパラメータを指定する値を含むが、cClient IDフィールドは、前述の説明から公知であるように、将来のクライアントIDのために予約されている。無効MCCS VCP制御コードが有効パラメータ要求パケットによって指定される場合には、応答コードフィールドに適切な値を備える、同じ無効パラメータ値がこのフィールドに指定される。MCCS制御コードが無効である場合には、VCPパラメータ応答リストはゼロ長を有するであろう。
応答コードフィールドは、指定されたMCCS VCP制御に関する情報に対する要求に関連する応答の性質を指定する2バイトの情報又は値を含む。このフィールドの値が0に等しい場合には、エラーはこのデータ型に存在するとは見なされず、シーケンスの中の最後の有効パラメータ応答パケットが送信され、それは最高の応答シーケンス番号を有する。このフィールドの値が1に等しい場合には、エラーは存在すると見なされないが、さらに高いシーケンス番号を有する他の有効パラメータ応答パケットが送信される。このフィールドの値が2に等しい場合には、指定された制御はクライアントで実現されると見なされない。このフィールドidの値が3に等しい場合には、指定された制御は非連続制御ではない(ゼロからその最大値まですべての値の有効な集合をつねに有するのは連続制御である)。4から65535に等しいこのフィールドの値は将来の使用のために予約され、通常は使用されるべきではない。
2バイト応答シーケンス番号フィールドは、クライアントによって返される有効パラメータ応答パケットのシーケンス番号を指定する。クライアントは、有効パラメータ要求パケットに応えて1つ又は複数の有効なパラメータ応答パケットを返す。クライアントは複数の有効パラメータ応答パケット上でVCPパラメータ応答リストを広げてよい。この後者のケースでは、クライアントが各連続パケットにシーケンス番号を割り当て、シーケンス内の最後のパケットを除くすべてで応答コードを1に設定する。シーケンス内の最後の有効パラメータ応答パケットは最高の応答シーケンス番号を有し、応答コードは0という値を含む。
2バイトのリスト中の値の数フィールドは、VCPパラメータ応答リストに存在する16ビット値という数を指定する。応答コードがゼロに等しくない場合には、リスト中の値の数パラメータはゼロである。VCPパラメータ応答リストフィールドはMCCS 制御コードフィールドにより指定される非連続制御の有効な値の集合を示す0から32760の2バイト値のリストを含む。非連続制御コードの定義はVESA MCCS仕様で指定される。最後に本実施形態では、CRCフィールドはパケット長を含むパケット内のすべてのバイトの16ビットCRCを含む。
スケーリングビデオストリーム画像
MDDI又はプロトコル機構、構造、手段、又は方法は、ホストが元の画像より大きく又は小さく拡大縮小されるクライアントに画像を送信できるようにするスケーリングビデオストリーム画像に対するサポートを提供し、スケーリングされた画像はメイン画像バッファにコピーされる。スケーリング済みのビデオストリーム機能性と関連プロトコルサポートの概要は他の箇所で示される。スケーリング済みのビデオストリームをサポートする能力は、特殊ステータス要求パケットに応えて送信されるスケーリングビデオストリーム機能によって、あるいは中で定義される。
以下に説明するスケーリングビデオストリームパケットのヘッダは、画像を表示するために必要なコンテクスト全体を含むヘッダを持つより簡素なビデオストリームパケットとは若干異なっている。このスケーリングビデオストリームパケットは、ソース及び目的ウィンドウサイズと位置を定義するセットアップパケットと、ピクセルデータを送信する別のスケーリングビデオストリームパケットとを使用する。クライアントは、セットアップパケットと、各ストリームに関連付けられたピクセルデータの一部とからのストリームパラメータを格納するために、各ストリームに関連付けられた内部記憶装置を割り当てる。各ストリームのために必要とされる記憶容量は、ソース及び目的イメージのサイズと、セットアップパケット内で特定された値に依存して変わる。この理由により、プロトコルは、クライアントが、各スケーリングビデオストリームに関連付けられた記憶装置のために、動的なメモリ割り当てを実施できるように設計される。
ビデオストリームを、プログラムソースに由来するサイズを持つディスプレイに送り、ディスプレイスケール及び位置を持つことは有用である。複数のビデオ画像のリアルタイムスケーリングの実施は、とても複雑であり、クライアントにおいて、オプションでこの特徴のサポートをすることができない。
31.スケーリングビデオストリーム機能パケット
スケーリングビデオストリーム機能パケットはクライアントの中の、あるいはクライアントによって使用されるスケーリングビデオストリームソース画像の特性を定義する。スケーリングビデオストリーム機能パケットは、概して図79に示されている。図79で分かるように、一実施形態では、スケーリングビデオストリーム機能パケットはパケット長フィールド、パケットタイプフィールド、cClient IDフィールド、最大ストリーム数フィールド、ソース最大Xサイズフィールド、ソース最大Yサイズフィールド、RGB機能フィールド、白黒機能フィールド、予約1フィールド、Y Cr Cb機能フィールド、予約2フィールド及びCRCフィールドを有するように構造化されている。一実施形態において、パケット長は、長さフィールドに示されているように、クライアントIDの使用のために予約され、それ以外の場合ゼロに設定される2バイトのcClient IDフィールド、及びCRCフィールドを含む固定された20バイトとなるように選択されている。一実施形態では、クライアントは、有効ステータス応答リストパケットの有効パラメータ応答リストの中で143というパラメータ値を使用してスケーリングビデオストリーム機能パケットをサポートする能力を示す。
2バイトの最大ストリーム数フィールドは、一度に割り当てられてよい同時スケーリングビデオストリームの最大数を識別するための値を含む。一実施形態では、クライアントは、最大数のスケーリングビデオストリームがすでに割り当てられている場合、スケーリングビデオストリームを割り当てる要求を拒絶しなければならない。最大数未満のスケーリングビデオストリームが割り当てられている場合は、クライアントはクライアントにおける他のリソース制限に基づいて割り当て要求を拒否してもよい。
ソース最大XサイズフィールドとYサイズフィールド(2バイト)は、多くのピクセルとして表されるスケーリングビデオストリームソース画像の、それぞれ最大幅と高さの値を指定する。
RGB機能フィールドは、RGBフォーマットで表示できる解像度のビット数を指定するために値を使用する。スケーリングビデオストリームがRGBフォーマットを使用できない場合、この値はゼロに等しく設定される。ビット5から12は将来の機能定義で将来使用するために予約され、通常はゼロに設定されているが、RGB機能ワードは、各ピクセルの青の最大ビット数(青輝度)を定義するビット3から0、各ピクセルの緑の最大ビット数(緑輝度)を定義するビット7から4、及び各ピクセルの赤の最大ビット数(赤輝度)を定義するビット11から8の3つの別々の符号なし値から構成されている。
1バイトの白黒機能フィールドは、白黒フォーマットで表示できる解像度のビット数を指定する値を含む。スケーリング済みのビデオストリームが白黒フォーマットを使用できない場合、この値はゼロに設定される。ビット7から4は将来の使用のために予約されているため、当業者によって理解されるように、これは経時的に変化する可能性はあるが現在の応用例についてはゼロ(「0」)に設定されなければならない。ビット3から0は各ピクセルに存在できるグレイスケールの最大ビット数を定義する。これらの4個のビットは、各ピクセルが1から15ビットからなることを指定できるようにする。値がゼロである場合には、白黒フォーマットはスケーリングビデオストリームによってサポートされていない。
予約1フィールド(ここでは1バイト)は、スケーリングビデオストリームパケット情報又はデータに関係する値を提供する際に将来使用するために予約されている。したがって、現在このフィールドのすべてのビットは論理「0」に設定されている。このフィールドの1つの目的は、すべての以後の2バイトフィールドを16ビットワードアドレスに一合わせさせ、4バイトフィールドを32ビットワードアドレスに位置合わせさせることである。
2バイトのY Cb Cr機能フィールドは、Y Cb Crフォーマットで表示できる解像度のビット数を指定する値を含む。スケーリングビデオストリームがY Cb Crフォーマットを使用できない場合には、この値はゼロである。Y Cb Cr機能ワードは3つの別々の符号なし値から構成されている。つまり、Crサンプルを指定するビット最大数を定義するビット3から0、Cbサンプルを指定するビット最大数を定義するビット7から4、Yサンプルを指定するビット最大数を定義するビット11から8である。そしてビット15から12は将来の使用に予約されており、通常はゼロに設定されている。
1バイトの機能ビットフィールドは、スケーリングビデオストリームと関連する機能を指定するフラグのセットを含む。フラグは以下のとおりに定義される。ビット0はスケーリングビデオストリームパケットのピクセルデータをカバーし、パックフォーマットとなることができる。パックされ、バイト位置合わせされたデータは図13に前記に示されている。ビット1は将来の使用のために予約され、通常は、ゼロに設定される。ビット2もまた将来の使用のために予約され、ゼロに設定される。ビット3は、カラーマップデータフォーマットで指定できるスケーリングビデオストリームをカバーする。同じカラーマップテーブルが、メイン画像バッファ及びアルファ−カーソル画像平面に使用されるようにスケーリングビデオストリームに使用される。カラーマップは、他の箇所で説明されるカラーマップパケットを使用して構成されている。そしてビット7から4は将来の使用のために予約され、通常はゼロに設定されている。
予約2フィールド(ここでは1バイト)は、スケーリングビデオストリームパケット情報又はデータに関係する値を提供する上で将来の使用に予約されている。したがって、現在、このフィールドのすべての値は論理「0」に設定されている。このフィールドの1つの目的は、すべての以後の2バイトフィールドを16ビットワードアドレスに位置合わせさせ、4バイトフィールドを32ビットワードアドレスに位置合わせさせることである。
32.スケーリングビデオストリームセットアップパケット
スケーリングビデオストリームセットアップパケットは、スケーリングビデオストリームのパラメータを定義するために使用される手段、構造、又は方法を提供し、クライアントは、画像のバッファリング及びスケーリングのために内部記憶域を割り当てるための情報を使用する。ストリームは、X画像サイズフィールドとY画像サイズフィールドがゼロに等しい状態で、このパケットを送信することによって割り当て解除されてよい。割り当て解除されたスケーリングビデオストリームは、後で、同じストリームパラメータ又は異なるストリームパラメータを用いて割り当てし直されてよい。一実施形態では、クライアントは有効ステータス応答リストパケットの有効パラメータ応答リストの143というパラメータ値を使用して、及びスケーリングビデオストリーム機能パケットの最大ストリーム数フィールドで非ゼロ値を使用することによってスケーリングビデオストリームセットアップパケットをサポートする能力を示す。
スケーリングビデオストリームセットアップパケットのフォーマットは概して図80に示されている。図80で分かるように、一実施形態では、スケーリングビデオストリームセットアップパケットは、パケット長フィールド、パケットタイプフィールド、hClientフィールド、ストリームIDフィールド、視覚データフォーマット記述子フィールド、ピクセルデータ属性フィールド、X左端縁フィールド、Y上部端縁フィールド、X右端縁フィールド、Y下部端縁フィールド、X画像サイズフィールド、Y画像サイズフィールド、及びCRCフィールドを有するように構造化されている。
2バイトのパケット長フィールドは、パケット長フィールドを含まないパケットの中のバイト総数を指定する。一実施形態では、このパケット長は24で固定されている。2バイトのパケットタイプフィールドはパケットをスケーリングビデオストリームセットアップパケットとして識別するために136という値を利用する。2バイトのhClient IDフィールドはクライアントIDとしての将来の使用のために予約されており、通常は当面、あるいはプロトコルユーザが、公知であるように、どのID値を使用しなければならないのか判断するまで、論理ゼロ値に全てのビットが設定される。
ストリームIDフィールドは、ストリームIDの一意の識別子を指定するために2バイトを使用する。この値はホストにより割り当てられ、ゼロから、クライアント機能パケットで指定される最大ストリームID値までの値の範囲をとる。ホストは、各アクティブストリームに一意の値が割り当てられ、もはやアクティブではないストリームが割り当て解除される、あるいは再配分されることを保証するために注意深くストリームID値の使用を管理しなければならない。
一実施形態では、ビデオデータフォーマット記述子フィールドは、本パケットの本ストリームのピクセルデータの各ピクセルのフォーマットを指定するために2バイトを使用する。ピクセルデータフォーマットは、アルファカーソル画像機能パケットで定義されうるアルファ−カーソル画像平面の有効なフォーマット、あるいは上述したその他のパケット内で一般に定義されるようなその他の予め定義したパターンのうちの少なくとも1つと準拠する必要がある。ビデオデータフォーマット記述子は、現在のパケット専用のピクセルフォーマットを定義し、一定のフォーマットがある特定のビデオストリームの存続期間中に使用し続けられることを暗示していない。図12は、ビデオデータフォーマット記述子がどのようにコード化されるのか、他のパケットについて前述されたように実施形態を示す。
例えば、図12A乃至図12Dに示すように、一つの実施例において使用するために、ビット[15:13]が‘000’に等しい場合、ビデオデータは、白黒ピクセルのアレイから構成される。ここでは、ピクセル毎に多くのビットが、ビデオデータフォーマット記述子のビット3乃至0によって定義されている。ビット11乃至4は、一般に将来の使用またはアプリケーションのために予約されており、この場合ゼロに設定されている。一方、ビット[15:13]が値‘001’に等しい場合、ビデオデータは、カラーマップ(パレット)から各々色を特定するカラーピクセルのアレイから構成される。この場合、ビデオデータフォーマット記述子のビット5乃至0は、ピクセル毎のビット数を定義し、ビット11乃至6は、一般に、将来の使用又はアプリケーションのために予約され、ゼロに等しく設定されている。ビット[15:13]が値‘010’に等しい場合、ビデオデータは、カラーピクセルのアレイからなる。ここでは、赤のピクセルに関するビット番号が、ビット11乃至8で定義され、緑のピクセルに関するビット番号が、ビット7乃至4で定義され、青のピクセルに関するビット番号が、ビット3乃至0で定義される。この場合、各ピクセルの合計数は、赤、緑、及び青のために使用されたビット数の合計である。
しかしながら、図12Dに示すように、ビット[15:13]が値又はストリング‘011’に等しい場合、ビデオデータは、輝度とクロミナンスとを備えた4:2:2 YCbCrフォーマットのビデオデータのアレイからなる。ここでは、輝度(Y)のピクセル毎のビット番号が、ビット11乃至8で定義され、Cb成分のビット番号がビット7乃至4で定義され、Cr成分のビット番号がビット3乃至0で定義される。各ピクセルにおけるビットの合計数は、赤、緑、及び青のために使用されているビット数の合計である。Cb成分及びCr成分は、Yの半分のレートで送られる。更に、このパケットのピクセルデータ部におけるビデオサンプルは、Cbn,Yn,Crn,Yn+1,Cbn+2,Yn+2、Crn+2,Yn+3,・・・のように構成される。ここでCbnとCrnとはYn及びYn+1に関連しており、Cbn+2とCrn+2とはYn+2及びYn+3に関連している。Yn,Yn+1,Yn+2,及びYn+3は、一つの行の左から右への連続した4つのピクセルに対する輝度値である。
全4つのフォーマットについて説明した。図中“P”として示されているビット12は、ピクセルデータサンプルがパックされているか否かを、又はバイトが整えられたピクセルデータを特定する。このフィールド内の値‘0’は、ピクセルデータフィールド内の各ピクセルが、MDDIバイト境界でバイトが整えられていることを示す。値‘1’は、ピクセルデータの各ピクセル及び各ピクセル内の各色とが、前のピクセル、又は未使用ビットを残さないピクセル内の色に対してパックされたことを示す。
一つの実施形態では、2バイトのピクセルデータ属性フィールドは、以下のとおり、一般にはロジックゼロに設定され、将来の使用のために予約されているビット1とビット0とを用いて解釈される。そして、ビット2は、ピクセルデータがインタレースフォーマットを取っているかどうかを示す。ビット2が0であるときには、ピクセルデータは標準漸次フォーマットを取っている。行番号(ピクセルY座標)は、ある行から次の行に進むと1増分される。ビット2が1であるときには、ピクセルデータはインタレースフォーマットとなる。行番号(ピクセルY座標)は、ある行から次の行に進むと2増分される。
一つの実施形態では、ビット3は、ピクセルデータが代替のピクセルフォーマットを取っているかどうかを示す。これはビット2によってイネーブルされる標準インタレースモードに類似しているが、インターレースは水平の代わりに垂直である。ビット3が0であるとき、ピクセルデータは標準漸次フォーマットで生成又は配置される。列番号(ピクセルX座標)は、各連続ピクセルが受信されると1増分される。ビット3が1であるときには、ピクセルデータは代替ピクセルフォーマットで生成または配置される。列番号(ピクセルX座標)は、各ピクセルが受信されると、2増分される。
ビット4から15もまた将来の使用のために予約されており、一般に、現在のアプリケーション又は設計について論理ゼロのレベル又は値に設定される。
33.スケーリングビデオストリーム肯定応答パケット
スケーリングビデオストリーム肯定応答パケットにより、クライアントはスケーリングビデオストリームセットアップパケットの受信を確認できる。クライアントは有効ステータス応答リストパケットの有効パラメータ応答リストの中の143というパラメータ値を介して、及びスケーリングビデオストリーム機能パケットの最大ストリーム数フィールドの非ゼロ値を介してスケーリングビデオストリーム肯定応答パケットをサポートする能力を示すことができる。
スケーリングビデオストリーム肯定応答パケットのフォーマットは概して図81に示されている。図81で分かるように、一実施形態では、スケーリングビデオストリーム肯定応答パケットはパケット長フィールド、パケットタイプフィールド、cClientフィールド、ストリームIDフィールド、ACKコードフィールド及びCRCフィールドを有するように構造化されている。2バイトのパケット長フィールドは、137というパケットタイプがスケーリングビデオストリーム肯定応答パケットとしてパケットを識別する一方で、このパケットタイプの10という値で、パケット長フィールドを除き、バイト総数を指定するために使用される。
2バイトのcClient IDフィールドは、クライアントIDのための将来の使用のために予約されており、通常はゼロに設定されている。2バイトのストリームIDフィールドはストリームIDの一意の識別子を指定する。これはスケーリングビデオストリームセットアップパケットのホストによって割り当てられるのと同じ値である。
2バイトの肯定応答コードフィールドは、指定されたスケーリングビデオストリームを更新しようとする試みの結果を説明するコードを含む値を提供する。一実施形態では、コードは以下のとおりに定義される。
0−ストリーム割り当て試行は成功した。
1−ストリーム割り当て解除試行は成功した。
2−すでに割り当てられているストリームIDを割り当てようとする無効な試行。
3−すでに割り当て解除されているストリームIDを割り当て解除しようとする無効な試行。
4−クライアントはスケーリングビデオストリームをサポートしない。
5−ストリームパケットはクライアントの機能と一貫していない。
6−ストリームID値はクライアントによって許可される最大値より大きい。
7−指定されたストリームを割り当てるには不十分なクライアント内で入手可能なリソース。
2バイトのCRCフィールドは、パケット長を含むパケット内のすべてのバイトのCRCを含む。
34.スケーリングビデオストリームパケット
スケーリングビデオストリームパケットは、特殊なスケーリングビデオストリームと関連したピクセルデータを送信するために使用される。このパケットにより参照される(reference)領域のサイズは、スケーリングビデオストリームセットアップパケットにより定義される。クライアントは、有効ステータス応答リストパケットの有効パラメータ応答リストの中のパラメータ値143を介して、及びスケーリングビデオストリーム肯定応答パケットのAckコードフィールド内での成功したスケーリングビデオストリーム割り当て反応を使用して、スケーリングビデオストリームパケットをサポートする能力を示すことができる。
スケーリングビデオストリームパケットの1つの実施形態のフォーマットは、概して図78に示されている。図78で分かるように、スケーリングビデオストリームパケットは、パケット長フィールド、パケットタイプフィールド、hClient IDフィールド、ストリームIDフィールド、ピクセルデータ属性フィールド、ピクセルカウントフィールド、パラメータCRCフィールド、ピクセルデータフィールド、及びピクセルデータCRCフィールドを有するように構造化されている。2バイトのパケットタイプフィールドはスケーリングビデオストリームパケットとしてパケットを識別するために18という値を使用する。hClient IDフィールドはクライアントIDのために予約されており、通常ゼロに設定されている。前述されたように2バイトのストリームIDフィールドがストリームIDの一意の識別子を指定する。この値はスケーリングビデオストリームセットアップパケット内のホストによって指定され、スケーリングビデオストリーム肯定応答パケット内で確認される。一つの実施形態では、2バイトピクセルデータ属性フィールドは、ピクセルデータ経路を特定し、更新版又はバッファ位置を表示する値を持つ。これらの値は、一つの実施例では、 である。
一つの実施例では、2バイトのピクセルデータ属性フィールドは、ピクセルデータ経路及びディスプレイ更新又はバッファ位置を特定する値を持っている。これらの値は、一つの実施例では、以下のように解釈される。すなわち、ビット1とビット0とは、ピクセルデータが経路付けられるディスプレイを選択する。ビット値‘11’又はビット値‘00’では、ピクセルデータが両目に対して、又は両目のために表示される。ビット値‘10’の場合、ピクセルデータは左目のみに送られ、ビット値‘01’の場合、ピクセルデータは右目のみに送られる。
ビット7とビット6とは、ピクセルデータが書き込まれるフレームバッファを特定するディスプレイ更新ビットである。フレーム更新バッファの効果は、本明細書内の別の箇所に、より詳細に記載されている。ビット[7:6]が‘01’である場合、ピクセルデータは、オフライン画像バッファに書き込まれる。ビット[7:6]が‘00’である場合、ピクセルデータは、ディスプレイをリフレッシュするために使用される画像バッファに書き込まれる。ビット[7:6]が‘11’である場合、ピクセルデータは、全ての画像バッファに書き込まれる。ビット[7:6]が‘10’であれば、無効な値として取り扱われる。これらのビットは現在、将来の使用のために予約されている。この場合、ピクセルデータは無視され、画像バッファの何れにも書き込まれない。ビット2乃至5及びビット8乃至15は将来の使用のために予約され、一般に論理ゼロレベル又は論理ゼロ値に設定される。
2バイトのピクセルカウントフィールドは、以下のピクセルデータフィールド内のピクセル数を指定する。2バイトパラメータCRCフィールドはパケット長からピクセルカウントへすべてのバイトのCRCを有する。CRCがチェックできない場合には、パケット全体が廃棄される。2バイトピクセルデータフィールドは、スケーリングされてから表示されなければならない未処理のビデオ情報を含む。データは、ビデオデータフォーマット記述子フィールドによって記述されるようにフォーマットされる。データは過去に定められたように、一度に1行ずつ送信される。
2バイトのピクセルデータCRCフィールドはピクセルデータだけのCRCを含む。このCRCがチェックできない場合には、ピクセルデータが依然として使用されるものとするが、CRCエラーカウントは増分されるものとする。
35.特殊ステータス要求パケット
特殊ステータス要求パケットは、このパケットに指定されるように、クライアントが機能又はステータスパケットをホストに送り返すことをホストが要求するための手段、機構又は方法を提供する。クライアントは、次の逆方向リンクカプセルかパケット内に指定されるタイプのパケットを返す。クライアントは、クライアントが特殊ステータス要求パケットに応答する機能を有する場合、一般に、クライアント機能パケットのクライアント特徴機能フィールドでビット17を設定する。クライアントが返信又は転送することができるステータスパケットの全てのタイプを判定するためにホストが用いる便利な方法は、説明した有効ステータス応答リストパケットを使用することである。クライアントは、クライアント機能パケットのクライアント特徴機能フィールドのビット21を使用して有効ステータス応答リストパケットを用いて応答する能力を示すことができる。
特殊ステータス要求パケットの一実施形態のフォーマットは、概して図79に示されている。図79で分かるように、特殊ステータス要求パケットは、パケット長フィールド、パケットタイプフィールド、hClientIDフィールド、ステータスパケットIDフィールド、及びCRCフィールドを有するように構造化されている。パケット長フィールドはパケット長フィールドを含まないパケット内のバイト総数を指定し、通常このパケットタイプの場合10という値で固定されている。138というパケットタイプは、パケットを特殊ステータス要求パケットに識別する。hClient IDフィールド(2バイト)はクライアントIDのための将来の使用のために予約されており、当面ゼロに設定されている。一方、2バイトのステータスパケットIDフィールドは、ホストに送信する機能又はステータスパケットのタイプを指定する。典型的なパケットタイプは、
66−クライアント機能パケットがクライアントにより送信される。
133−アルファ−カーソル画像機能パケットがクライアントに送信される。
139−クライアントが送信できる機能パケットとステータスパケットの正確なタイプを識別する有効ステータス応答リストパケットが送信される。
141−個人クライアント機能パケットがクライアントによって送信される。
142−クライアントエラーレポートパケットがクライアントによって送信される。
143−スケーリングビデオストリーム機能パケットがクライアントによって送信される。
144−クライアント識別パケットがクライアントによって送信される。
パケットタイプ56から63は、製造メーカに特殊な機能識別子とステータス識別子に使用できる。
CRCフィールドは、パケット長を含むパケット内のすべてのバイトのCRCを再び含む。
36.有効ステータス応答リストパケット
有効ステータス応答リストパケットは、ホストに、クライアントがそれに返信する機能を有するステータスパケットと機能パケットのリストを持つ構造、手段、又は方法を与える。クライアントは、クライアント機能パケットのクライアント特徴機能フィールドのビット21を使用して有効ステータス応答リストパケットをサポートする能力を示すことができる。
有効ステータス応答リストパケットの一実施形態のフォーマットは概して図80に示されている。図80で分かるように、有効ステータス応答リストパケットは、パケット長フィールド、パケットタイプフィールド、cClient IDフィールド、リスト中の値数フィールド、有効パラメータ応答リストフィールド、及びCRCフィールドを有するように構造化されている。この種のパケットのパケット長は通常10という値に固定され、139というタイプ値は有効ステータス応答パケットとしてパケットを識別する。cClient IDフィールドはクライアントIDとしての将来の使用のために予約され、通常ゼロに設定されている。2バイトのリスト中の数フィールドは、以下の有効パラメータ応答リスト内で項目の数を指定する。
有効パラメータ応答リストフィールドは、クライアントがホストに送信できる機能パケット又はステータスパケットのタイプを指定する2バイトのパラメータのリストを含む。クライアントが、それが(クライアント機能パケットのクライアント特徴機能フィールドのビット21を使用して)特殊ステータス要求パケットに応答できることを示した場合には、それは少なくともクライアント機能パケット(パケットタイプ=66)と有効ステータス応答リストパケット(パケットタイプ=139)を送信できる。クライアントによって送信でき、このリストの中に含められてよいパケットタイプは、一実施形態の目的のためのそのそれぞれの割り当てと共に、以下のとおりである。
66−クライアント機能パケット
133−アルファ−カーソル画像機能パケット
139−クライアントが送信できる機能パケットとステータスパケットの正確なタイプを識別する有効ステータス応答リストパケット
141−パーソナルディスプレイ機能パケット
142−クライアントエラーレポートパケット
143−スケーリング済みビデオストリーム機能パケット
144−クライアント識別パケット
145-代替ディスプレイ機能パケット。
パケット56から63は、製造メーカに特殊な機能及びステータス識別子のために使用できる。
CRCフィールドはパケット長を含むパケット内のすべてのバイトのCRCを含む。
37.パーソナルディスプレイ機能パケット
パーソナルディスプレイ機能パケットは、ヘッドマウントディスプレイ又はディスプレイ眼鏡等のパーソナルディスプレイ装置の機能を記述するパラメータのセットを提供する。これによりホストはクライアントの特定の機能に従って表示情報をカスタマイズできる。他方、クライアントは有効ステータス応答リストパケットの有効パラメータ応答リストの対応するパラメータを使用することによってパーソナルディスプレイ機能パケットを送信する能力を示す。
パーソナルディスプレイ機能パケットの1つの実施形態のフォーマットは概して図81に示されている。図81で分かるように、パーソナルディスプレイ機能パケットは、パケット長フィールド、パケットタイプフィールド、cClient IDフィールド、サブピクセルレイアウトフィールド、ピクセル形状フィールド、水平視野フィールド、垂直視野フィールド、視軸交差フィールド、左右画像フィールド、シースルーフィールド、最大明度フィールド、光学機能フィールド、最小IPDフィールド、最大IPDフィールド、曲率リストのIFeldの点フィールド及びCRCフィールドを有するように構造化されている。このパケットのパケット長はつねに68である。141というパケットタイプ値は、パーソナルディスプレイ表示機能パケットとしてパケットを識別する。cClient IDフィールドは将来の使用のために予約されており、通常は当面ゼロに設定されている。
サブピクセルレイアウトフィールドは以下の値を使用して上から下へ、及び左から右へサブピクセルの物理的なレイアウトを指定する。つまり、0はサブピクセルレイアウトが定義されていないことを示し、1は赤、緑、青の縞を示し、2は青、緑、赤の縞を示し、3は、左上に赤、右下に青、及び一方が左下、他方が右上の2個の緑のサブピクセル2×2のサブピクセル配列を有するクワッドピクセルを示し、4は、左下に赤、右上に青の2×2のサブピクセル配列及び一方が左上、他方が右下の2個の緑のサブピクセルを示し、5はデルタ(トライアド)を示し、6は、赤、緑及び青がオーバレイされた(たとえば、フィールド順次色のLCOSディスプレイ)モザイクを示し、7から255の値が将来の使用のために通常予約されている。
ピクセル形状フィールドは、以下の値を使用し特殊な構成のサブピクセルから構成されている各ピクセルの形状を指定し、0はサブピクセル形状が定められていないことを示し、1は円形を示し、2は正方形を示し、3は矩形を示し、4は長円を示し、5は楕円を示し、値6から255が、当業者が理解できるように、所望される形状を示す上での将来の使用に予約されている。
A1バイトの水平視野(HFOV)フィールドは、0.5度の増分で水平視野を指定する(例えばHFOVが30度である場合、この値は60である)。この値がゼロである場合にはHFOVは指定されていない。
A1バイトの垂直視野(VFOV)フィールドは、0.5度の増分で垂直視野を指定する(例えば、VFOVが30である場合、この値は60である)。この値がゼロである場合、VFOVは指定されていない。
A1バイト視軸交差フィールドは、0.01ジオプタ(1/m)増分で視軸交差を指定する(例えば、視軸交差が2.22メートルである場合、この値は45である)。この値がゼロである場合、視軸交差が指定されない。
A1バイトの左/右画像重複フィールドは、左画像と右画像の重複のパーセンテージを指定する。パーセント単位の画像重複の許容可能な範囲は1から100である。101から255の値は無効であり、一般には使用されない。この値がゼロである場合には、画像重複は指定されない。
A1バイトシースルーフィールドは、画像のシースルーパーセンテージを指定する。パーセント単位のシースルーの許容範囲は0から100である。101から254の値は無効であり、使用されない。この値が255である場合には、シースルーパーセンテージは指定されない。A1バイト最大明度フィールドは20ニットの増分で最大明度を指定する(例えば、最大明度が100ニットである場合、この値は5である)。この値がゼロである場合には、最大明度は指定されない。
2バイト光学機能フラグフィールドはディスプレイの光学機能を指定する多様なフィールドを含む。これらのビット値は、通常、以下に従って割り当てられている。
ビット15から5は将来の使用のために受信され、一般に、論理ゼロ状態に設定される。
ビット4はメガネ焦点調整を選択し、「0」という値はディスプレイにメガネ焦点調整がないことを意味し、「1」という値はディスプレイがメガネ焦点調整を有することを意味する。
ビット3から2は、以下に従って両眼機能を選択する。0という値は、ディスプレイが両眼用であり、2次元(2D)画像だけを表示できることを意味し、1は、ディスプレイが両眼用であり、3次元(3D)画像を表示できることを意味し、2は、ディスプレイが単眼用であることを意味し、3は将来の使用のために予約されている。
ビット1から0は、左右像面湾曲対称を選択し、0という値は像面湾曲が定義されていないことを意味する。このフィールドがゼロである場合には、A1からE5までのすべての像面湾曲値は、点C3を除きゼロに設定され、ディスプレイの焦点距離を指定するか、あるいはゼロに設定され、焦点距離が指定されていないことを示す。1という値は左右のディスプレイが同じ対称性を有することを意味する。2は、左右のディスプレイが垂直軸(列C)でミラーリングされていることを意味し、3は将来の使用のために予約されている。
1バイト相互瞳孔間距離(IPD)最小フィールドは、ミリメートル(mm)で最小の相互瞳孔間距離を指定する。この値がゼロである場合には、最小相互瞳孔間距離が指定されない。1バイトの相互瞳孔間距離(IPD)最大フィールドはミリメートル(mm)で最大相互瞳孔間距離を指定する。この値がゼロである場合には、最大相互瞳孔間距離は指定されない。
像面湾曲の点リストフィールドは、1から65535(例えば、1は0.001ジオプターであり、65535は65.535ジオプターである)の範囲でジオプター(1/m)の千分の1で焦点距離を指定する25の2バイトパラメータを含む。像面湾曲の点リストの25の要素は、図82に示されているようにA1からE5と呼ばれている。該点はディスプレイのアクティブな領域で均等に分散される。列Cはディスプレイの垂直軸に相当し、行3はディスプレイの水平軸に相当する。列AとEは、それぞれディスプレイの左端縁と右端縁に相当する。そして、行1と5は、それぞれディスプレイの上部端縁と下部端縁に相当する。リスト中の25の点の順序は以下のとおりである。A1、B1、C1、D1、E1、A2、B2、C2、D2、E2、A3、B3、C3、D3、E3、A4、B4、C4、D4、E4、A5、B5、C5、D5、E5。
CRCフィールドは、パケット長を含むパケット内のすべてのバイトのCRCを含む。
38.クライアントエラーレポートパケット
クライアントエラーレポートパケットは、クライアントがホストに動作エラーのリストを提供できるようにするための機構又は手段として働く。クライアントはホストから特定のコマンドを受信した結果としてその通常の動作の過程で幅広い範囲のエラーを検出してよい。これらのエラーの例は以下を含む。クライアントは、それがサポートしていないモードで動作するように命令された可能性がある、クライアントは範囲外である、あるいはクライアントの能力を超えている特定のパラメータを含むパケットを受信した可能性がある、クライアントは不適切な順序でモードに入るように命令された可能性がある。クライアントエラーレポートパケットは、通常の動作中にエラーを検出するために使用される可能性があるが、ホストシステムとクライアントシステムの開発及び統合における問題点を診断するためにシステム設計者と統合者にもっとも有効である。クライアントは、有効ステータス応答リストパケットの有効パラメータ応答リストで142というパラメータ値を使用して、クライアントエラーレポートパケットを送信するその機能を示す。
クライアントエラーレポートパケットの一実施形態のフォーマットは、概して図83に示されている。図83で分かるように、クライアントエラーレポートパケットはパケット長フィールド、パケットタイプフィールド、cClient IDフィールド、リストアイテム数フィールド、エラーコードリストフィールド及びCRCフィールドを有するように構造化されている。142というパケットタイプ値は、パケットをクライアントエラーレポートパケットとして識別する。cClient IDフィールドは将来の使用のために予約され、通常、当面はゼロに設定されている。リストアイテム数フィールド(2バイト)は以下のエラーコードリストの中のアイテム数を指定する。エラーコードリストフィールド(ここでは8バイト)は、1つ又は複数のエラーレポートリストアイテムを含むリストである。単一のエラーレポートリストアイテムのフォーマットは図84に示されている。
一実施形態では、図84に示されているように各エラーレポートリストアイテムの長さは正確に4バイトであり、以下を備える一実施形態での構造を有する。つまり、報告されているエラーのタイプを指定する2バイトの表示エラーコードフィールド、2バイトのエラーサブコードフィールドはクライアントエラーコードパケットにより定められるエラーに関してより大きなレベルの詳細を指定する。各クライアントエラーコードの特殊な定義はクライアントの製造メーカによって定義されている。エラーサブコードは、表示エラーコードごとに定義される必要はなく、エラーサブコードが定義されていないそれらの場合、該値はゼロに設定される。各エラーサブコードの特定の定義はクライアントの製造メーカにより定義される。
39.クライアント識別パケット
クライアント識別パケットは、クライアントが特殊ステータス要求パケットに応えて識別データを返すことができるようにする。一実施形態では、クライアントは有効ステータス応答リストパケットの有効パラメータ応答リストの中の144というパラメータを使用してクライアント識別パケットを送信する能力を示す。ホストが、クライアントからこのデータを読み取ることによってクライアントデバイスの製造メーカ名及び型番を決定できるようにすることが有効である。情報は、クライアントがクライアント機能パケットに記述できない特殊な機能を有するかどうかを判断するために使用されてよい。クライアントから識別情報を読み取るための潜在的に2つの方法、手段又は機構がある。一方は、ベースEDID構造でのフィールドに類似するフィールドを含むクライアント機能パケットの使用による。他方の方法は、クライアント機能パケットないの類似するフィールドに比較される、より濃密な情報のセットを含むクライアント識別パケットの使用による。これは、ホストが3文字EISAコードを割り当てられていない製造メーカを識別できるようにし、シリアル番号が英数字文字を含むことができるようにする。
クライアント識別パケットの一実施形態のフォーマットは、概して図85に示されている。図85で分かるように、クライアント識別パケットは、パケット長フィールド、パケットタイプフィールド、cClient IDフィールド、製造週フィールド、製造年フィールド、製造メーカ名フィールド、製品名長フィールド、シリアル番号長フィールド、製造メーカ名文字列フィールド、製品名文字列フィールド、シリアル番号文字列フィールド、及びCRCフィールドを有するように構造化されている。
2バイトのパケットタイプフィールドは、クライアント識別パケットとしてパケットを識別する値を含む。この値は一実施形態で144になるように選択される。cClient IDフィールド(2バイト)は再びクライアントID用の将来の使用のために予約され、通常ゼロに設定されている。CRCフィールド(2バイト)は、パケット長を含むパケット内のすべてのバイトの16ビットCRCを含む。
1バイトの製造週フィールドは、ディスプレイの製造週を定める値を含む。少なくとも一実施形態では、この値は、それがクライアントによってサポートされる場合1から53の範囲内にある。このフィールドがクライアントによってサポートされていない場合には、それは通常ゼロに設定されている。1バイトの製造年フィールドは、クライアント(ディスプレイ)の製造の年を定める値を含む。他のベース年も使用できるであろうが、この値は開始点としての年1990からオフセットである。1991から2245の範囲の年をこのフィールドによって表すことができる。例:年2003は13という製造年値に対応する。このフィールドがクライアントによってサポートされていない場合には、それはゼロという値に設定されなければならない。
製造メーカ名長フィールド、製品名長フィールド、及びシリアル番号長フィールドは、あらゆるヌル終端又はヌルパッド文字を含む製造メーカ名文字列フィールドの長さ、あらゆるヌル終端又はヌルパッド文字を含む製品名文字列フィールドの長さ、及びそれぞれヌル終端文字又はヌルパッド文字を含むシリアル番号文字列フィールドの長さを指定する、それぞれ2バイトの値を含む。
製造メーカ名文字列フィールド、製品名文字列フィールド、及びシリアル番号文字列フィールドは、それぞれ製造メーカ、製品名、及び英数字シリアル番号を指定するASCII文字列を含む、それぞれディスプレイの製造メーカ名長フィールド、製品名フィールド、及びシリアル番号フィールドによって指定される可変数のバイトを含む。これらの文字列のそれぞれは少なくとも1つのヌル文字で終端する。
40.代替ディスプレイ機能パケット
代替ディスプレイ機能パケットは、MDDIクライアントコントローラに取り付けられる代替ディスプレイの機能を示す手段、構造、又は方法として使用される。それは特殊ステータス要求パケットに応えて送信される。プロンプトを出されると、クライアントデバイスは、サポートされている代替ディスプレイごとに代替ディスプレイ機能パケットを送信する。クライアントが一つより多い代替ディスプレイを持っている場合、非効率的ではあるものの、希望に応じて幾つかの構成が複数の要求特有ステータスパケットを使用するが、クライアントは、一つの要求特有ステータスパケットに応じて、各ディスプレイのためにそれぞれ代替ディスプレイ機能パケット送り、生成し、提供する。クライアントは、代替ディスプレイ機能パケットを送る。ここでは、代替ディスプレイ番号フィールドの値に基づいて、「不連続な順番」としても称されうる。クライアントは有効ステータス応答リストパケットの有効パラメータ応答リストの中の145というパラメータ値を介して代替ディスプレイ機能パケットを送信する能力を示すことができる。
内部モードで操作されているMDDIシステムの場合、MDDIクライアントコントローラに接続される複数のディスプレイを有することはよくあることである可能性がある。例の応用例は、フリップの内側に大型ディスプレイ、外側に小型のディスプレイを備えた携帯電話である。内部モードクライアントは、2つの潜在的な理由により、代替ディスプレイ機能パケットを返す必要はない。第1に、ホストは既にプログラムされているか、或いは製造中に、その機能が通知されているかもしれない。なぜなら、それらは共通のデバイス又は筐体で使用されているからである。第2に、これら2つの組み立てによって、クライアントは、接続が切られたり、ホストへの接続から分離されることが容易にはなされない。そして、ホストは、クライアント機能のハードコードコピーを含むか、あるいは、起こるかもしれないクライアント内の変化によって変化しないことを少なくとも知っているかもしれない。
クライアント機能パケットの代替ディスプレイ数フィールドは、複数のディスプレイが取り付けられ、代替ディスプレイ機能パケットが各代替ディスプレイの機能を報告することを報告するために使用される。ビデオストリームパケットは、クライアントデバイスの中の各代替ディスプレイに対処するためにピクセルデータ属性フィールドに4ビットを含む。
代替ディスプレイ機能パケットの一実施形態のフォーマットは、概して図86に示されている。図86で分かるように、代替ディスプレイ機能パケットは、パケット長フィールド、パケットタイプフィールド、cClient IDフィールド、代替ディスプレイ数フィールド、予約1フィールド、ビットマップ幅フィールド、ビットマップ高さフィールド、ディスプレイウィンドウ幅フィールド、ディスプレイウィンドウ高さフィールド、カラーマップRGB幅フィールド、RGB機能フィールド、白黒機能フィールド、予約2フィールド、Y Cb Cr機能フィールド、表示特徴機能フィールド、予約3フィールド、及びCRCフィールドを有するように構造化されている。145というパケットタイプ値は、代替ディスプレイ機能パケットとしてパケットを識別する。cClient IDフィールドは、将来の使用のためのクライアントIDのために予約され、通常はゼロに設定されている。
代替ディスプレイ数フィールドは、0から15の範囲内の整数で代替ディスプレイのアイデンティティを示すために1バイトを使用する。第1の代替ディスプレイは一般に0番に指定され、他の代替ディスプレイは、使用されている最大数が1を差し引いた代替ディスプレイの総数である、一意の代替ディスプレイ数値で識別される。1を差し引いた代替ディスプレイ総数より大きい値は、使用されない。例:一次ディスプレイとMDDIクライアントに接続されている発呼者IDディスプレイを有する携帯電話は、1つの代替ディスプレイを有するため、発呼者IDディスプレイの代替ディスプレイ数はゼロであり、クライアント機能パケットの代替ディスプレイ数フィールドは1という値を有する。
予約1フィールド(1バイト)は、将来の使用のために予約されている。このフィールドの中のすべてのビットはゼロに設定されている。このフィールドの1つの目的は、すべての以後の2バイトフィールドを16ビットのワードアドレスに位置合わせさせ、4バイトフィールドを32ビットワードのアドレスに位置合わせさせることである。
ビットマップ幅フィールドは、ピクセル数として表されるビットマップの幅を指定する2バイトを使用する。ビットマップ高さフィールドはピクセル数として表されるビットマップの高さを指定する2バイトを使用する。ディスプレイウィンドウ幅フィールドは、ピクセル数として表されるディスプレイウィンドウの幅を指定する2バイトを使用する。ディスプレイウィンドウ高さフィールドはピクセル数として表されるディスプレイウィンドウの高さを指定する2バイトを使用する。
カラーマップRGB幅フィールドは、カラーマップ(パレット)表示モードで表示できる赤、緑、及び青の色成分のビット数を指定する2バイトを使用する。色成分(赤、緑、及び青)ごとに最大8ビットが使用できる。8ビットの各色成分がカラーマップパケットで送信されるとしても、このフィールドに定義される各色成分の最下位ビットの数だけが使用される。ディスプレイクライアントがカラーマップ(パレット)フォーマットを使用できない場合、この値はゼロである。カラーマップRGB幅ワードは、3つの別々の符号なし値から構成されている。
ビット3から0は、0から8という値が有効と考えられる、各ピクセル内の青の最大ビット数を定義する。ビット7から4は、0から8の値が有効と考えられる、各ピクセル内の緑の最大ビット数を定義する。ビット11から8は、0から8の値が有効と考えられる、各ピクセル内の赤の最大ビット数を定義する。ビット14から12は将来の使用のために予約されており、通常ゼロに設定されている。ビット15は、パックフォーマット又はアンパックフォーマットでカラーマップピクセルデータを受け入れるクライアントの能力を示すために使用される。ビット15が論理1レベルに設定されているとき、こは、クライアントがパックフォーマット又はアンパックフォーマットのどちらかでカラーマップピクセルデータを受け入れることができることを示す。ビット15が論理ゼロに設定されている場合、これは、クライアントがアンパックフォーマットでのみカラーマップピクセルを受け入れることができることを示している。
RGB機能フィールドは、RGBフォーマットで表示できる解像度のビット数を指定するための2バイトを使用する。一実施形態では、クライアントがRGBフォーマットを使用できない場合に、この値はゼロに等しく設定される。RGB機能ワードは、以下の3つの別々の符号なし値から構成されている。ビット3から0は、各ピクセル内の青の最大ビット数(青輝度)を定義し、ビット7から4は各ピクセル内の緑の最大ビット数(緑輝度)を定義し、ビット11から8は各ピクセル内の赤の最大ビット数(赤輝度)を定義する。ビット14から12は将来の使用のために予約されており、ゼロに設定されている。ビット15は、パックフォーマット又はアンパックフォーマットでRGBピクセルデータを受け入れるためのクライアントの能力を示すために使用される。ビット15が論理1レベルに設定されているとき、これは、クライアントがパックフォーマット又はアンパックフォーマットのどちらかでRGBピクセルデータを受け入れることができることを示している。ビット15が論理ゼロに設定されると、これは、クライアントがアンパックフォーマットだけでRGBピクセルデータを受け入れることができることを示している。
1バイトの白黒機能フィールドは、白黒フォーマットで表示できる解像度のビット数を指定するための値又は情報を含む。クライアントが白黒フォーマットを使用できない場合には、この値はゼロに等しく設定される。ビット6から4は、将来の使用のために予約され、通常はゼロに設定されている。ビット3から0は、各ピクセルに存在できるグレイスケールの最大ビット数を定義する。これらの4つのビットにより、各ピクセルが1ビットから15ビットからなることを指定できるようになる。値がゼロである場合には、白黒フォーマットはクライアントによってサポートされていない。ビット7は、1に設定時、クライアントがパックフォーマット又はアンパックフォーマットのどちらかで白黒ピクセルデータを受け入れることを示す。ビット7がゼロに設定されている場合、これはクライアントがアンパックフォーマットだけで白黒ピクセルデータを受け入れることができることを示している。
予約2フィールドは、将来の使用のために予約されている1バイト幅のフィールドであり、通常、このフィールドの中のすべてのビットは論理ゼロレベルに設定されている。一実施形態では、このフィールドの目的とはすべての以後の2バイトフィールドを16ビットワードアドレスに位置合わせさせ、4バイトフィールドを32ビットワードアドレスに位置合わせさせることである。
2バイトのY Cb Cr機能フィールドは、Y Cb Crフォーマットで表示できる解像度のビット数を指定する。クライアントがY Cb Crフォーマットを使用できない場合には、この値はゼロである。Y Cb Cr機能ワードは以下の3つの別々の符号なし値から構成されている。ビット3から0は、Cbサンプルを指定する最大ビット数を定義し、ビット7から4はCrサンプルを指定する最大ビット数を定義し、ビット11から8はYサンプルを指定する最大ビット数を定義し、ビット14から12は将来の使用のために予約され、ゼロに設定されている。ビット15は、1に設定時に、クライアントがパックフォーマット又はアンパックフォーマットのどちらかでY Cb Crピクセルデータを受け入れることができることを示す。ビット15がゼロに設定されている場合、これはクライアントがY Cb Crピクセルデータをアンパックフォーマットだけで受け入れることができることを示している。
2バイトBayer機能フィールドは、解像度、ピクセルグループ及びBayaerフォーマットで転送できるピクセル順序のビット数を指定する。クライアントがBayerフォーマットを使用できない場合には、この値はゼロに設定されている。Bayer機能フィールドは以下の値から構成されている。ビット3から0は各ピクセルに存在する輝度の最大ビット数を定義し、ビット5から4は、必要とされる可能性のあるピクセルグループパターンを定義し、ビット8から6は必要とされるピクセル順序を定義し、ビット14から9は将来の使用のために予約され、ゼロに設定されている。ビット15は、1に設定時、クライアントがパックフォーマット又はアンパックフォーマットのどちらかでBayerピクセルデータを受け入れることができることを示す。ビット15がゼロに設定されている場合、これは、クライアントがアンパックフォーマットだけでBayerピクセルデータを受け入れることができることを示す。
2バイトのCRCフィールドは、パケット長を含むパケット内のすべてのバイトの16ビットCRCを含む。
41.レジスタアクセスパケット
レジスタアクセスパケットは、ホスト又はクライアントのどちらかに、MDDIリンクの反対端の構成レジスタとステータスレジスタにアクセスする手段、機構又は方法を与える。これらのレジスタは、各ディスプレイ又はデバイスコントローラに一意となる可能性がある。これらのレジスタは、設定構成、運転モードを必要とするすでに多くのディスプレイに存在し、他の有用且つ必要な設定値を有している。レジスタアクセスパケットは、MDDIホスト又はクライアントがレジスタに書き込むだけではなく、MDDIリンクを使用してレジスタを読み取ることも要求できるようにする。ホスト又はクライアントがレジスタ読み取りを要求すると、反対側はレジスタデータを同じパケットタイプで送信することによるが、これが読み取り/書き込み情報フィールドを使用してある特定のレジスタから読み取られたデータであることを示すことによっても応答しなければならない。レジスタアクセスパケットは、1より大きいレジスタカウントを指定することによって複数のレジスタを読み取る、又は書き込むために使用されてよい。クライアントは、クライアント機能パケットのクライアント特徴機能フィールドのビット22を使用してレジスタアクセスパケットをサポートする能力を示す。クライアントは、カプセル化パケットを用いてレジスタアクセスパケットを送信する。これによって、パケット設定又は構造内で何がパケットとして表れるのかを示す。
レジスタアクセスパケットの一実施形態のフォーマットは概して図87に示されている。図87で分かるように、レジスタアクセスパケットは、パケット長フィールド、パケットタイプフィールド、bClient IDフィールド、読み取り/書き込みフラグフィールド、レジスタアドレスフィールド、パラメータCRCフィールド、レジスタデータリストフィールド及びレジスタデータCRCフィールドを有するように構造化されている。146というパケットタイプ値は、レジスタアクセスパケットとしてパケットを識別する。bClient IDフィールドは将来の使用のために予約されており、通常、当面ゼロに設定されている。
2バイトの読み取り/書き込みフラグフィールドは、書き込み又は読み取り、あるいは読み取りに対する応答のどちらかとして特定のパケットを指定し、データ値のカウントを提供する。
ビット15から14は、読み取り/書き込みフラグとして働く。ビット[15:14]が「00」である場合には、このパケットはレジスタアドレスフィールドによってアドレス指定されるレジスタに書き込まれるデータを含む。指定されたレジスタに書き込まれるデータはレジスタデータリストフィールドに含まれている。ビット[15:14]が「10」である場合には、これはレジスタアドレスフィールドによってアドレス指定されている1つ又は複数のレジスタからのデータに対する要求である。ビット[15:14]が[11]である場合には、そのパケットは、読み取り/書き込みフラグのビット15:14が「10」に設定されているレジスタアクセスパケットに応えて要求されたデータを含む。レジスタアドレスフィールドは、第1のレジスタデータリストアイテムに対応するレジスタのアドレスを含み、レジスタデータリストフィールドは、1つ又は複数のアドレスから読み取られたデータを含む。ビット[15:14]が「01」である場合には、この場合、これは無効値として処理され、この値は将来のために予約され、使用されないが、当該技術分野における熟練者であれば、将来における利用のためにどのようにしてそれを適用するかを理解するであろう。
ビット13:0はレジスタデータリストフィールドで送信される32ビットのレジスタデータアイテムの数を指定するために14ビットの符号なし整数を使用する。ビット15:14が「00」に等しい場合には、ビット13:0はレジスタアドレスフィールドにより指定されるレジスタで開始するレジスタに書き込まれるレジスタデータリストフィールドに含まれる32ビットのレジスタデータアイテムの数を指定する。ビット15:14が「10」に等しい場合には、ビット13:0は、受信側装置がそのレジスタが読み取られるのを要求する装置に送信する32ビットのレジスタデータアイテムの数を指定する。このパケットの中のレジスタデータリストフィールドにはアイテムは含まれず、ゼロ長である。ビット15:14が「11」に等しい場合には、ビット13:0は、レジスタデータリストフィールドに含まれているレジスタから読み取られた、32ビットレジスタデータアイテムの数を指定する。現在、ビット15:14は無効値と見なされている「01」に等しく設定されておらず、無効の値とみなされ、それ以外の場合は将来の指定又は使用のために予約されている。
レジスタアクセスフィールドは、書き込まれる又は読み取られるレジスタアドレスを示すために4バイトを使用する。そのアドレス指定が32ビット未満であるレジスタをアドレス指定する場合、上位ビットはゼロに設定される。
2バイトパラメータCRCフィールドはパケット長からレジスタアクセスまでのすべてのバイトのCRCを含む。このCRCがチェックできない場合、パケット全体が廃棄される。
レジスタデータリストフィールドは、クライアントレジスタに書き込まれる4バイトのレジスタデータ値、又はクライアントデバイスレジスタから読み取られた値のリストを含む。
2バイトのレジスタデータCRCFフィールドは、レジスタデータリストだけのCRCを含む。このCRCがチェックできない場合には、レジスタデータは依然として使用されてよいが、CRCエラーカウントが増分される。
D.パケットCRC
CRCフィールドは、パケットの最後に、著しく大きなデータフィールドを有することがあるパケットの中のより重大なパラメータの後にも出現することがあり、したがって転送中のエラーの尤度が上昇する。2つのCRCフィールドを有するパケットの場合、CRCジェネレータは、ただ一方だけが使用されるときに、長いデータフィールドの後のCRC計算がパケットの始まりでパラメータによって影響を及ぼされないように第1のCRCの後に再初期化される。
多くのビット誤りを含むパケットが、良好なCRCを生成するわずかな可能性がある。誤りを持つパケットについて良好なCRCを検出する可能性は、多くの誤りを含む非常に長いパケットについて7×10−6に近づく。設計によって、MDDIリンクは、非常に低いか、あるいはゼロの誤り率となる。CRCは、リンクの健全性の監視のために使用されることが意図されており、パケットが再送信されるべきかを判定するために特定のパケットに関する誤りを検出するように意図されていない。
例示的な実施形態では、CRC計算のために使用される多項式はCRC−16、つまりX16+X15+X2+X0として知られている。本発明を実現するために有効なCRCジェネレータとチェッカ3600のサンプルインプリメンテーションは図36に示されている。図36では、CRCレジスタ3602は、Tx_MDDI_Data_Before_CRC線路上の入力であるパケットの第1のビットの転送の直前に0x0001という値に初期化され、次にパケットのバイトがLSBで最初に開始するレジスタの中にシフトされる。この図のレジスタビット番号が、使用されている多項式の順序に対応し、MDDIによって使用されるビット位置には対応しないことに注意する。単一方向でCRCレジスタをシフトする方がより効率的であり、この結果、MDDIビット位置14に達するまで、CRCビット15をMDDI CRCフィールドのビット位置0に、CRCレジスタビット14をMDDI CRCフィールドビット位置1に表示させる等である。
一例としては、クライアント要求及びステータスパケットのパケットコンテンツが0x000c、0x0046、0x000、0x0400、0x00、0x00、0x0000であり(あるいは0x0c、0x00、0x46、0x00、0x00、0x00、0x00、0x04、0x00、0x00、0x00、0x00等のバイトのシーケンスとして表現され)、マルチプレクサ3604と3606及びANDゲート3608の入力を使用して提出されると、Tx_MDDI_Data_With_CRC線路で結果として生じるCRC出力は0xd9aaである(あるいは0xaa、0xd9のようなシーケンスとして表される)。
CRCジェネレータとチェッカ3600が1台のCRCチェッカとして構成されるとき、Rx_MDDI_Data線路で受信されるCRCは、マルチプレクサ3604と排他的OR(XOR)ゲート3612に入力され、NORゲート3610、ANDゲート3608、及びANDゲート3614を使用してCRCレジスタ内で発見される値とビット単位で比較される。ANDゲート3614によって出力されるようなエラーがある場合には、ゲート3614の出力をレジスタ3602の入力に接続することによりCRCはCRCエラーを含むパケットごとに一度増分される。図36の図に示される例の回路が、既定のCHECK_CRC_NOWウィンドウ内で複数のCRCエラー信号を出力できる(図37Bを参照されたい)ことに注意する。したがって、CRCエラーカウンタは通常、CHECK_CRC_NOWがアクティブである各間隔内に第1のCRCエラーだけをカウントする。CRCジェネレータとして構成される場合、CRCはパケットの最後と一致する時間にCRCレジスタから退出時間を記録される。
入力信号と出力信号及びイネーブル信号のタイミングは、図37Aと図37Bに図で描かれている。CRCの生成とデータのパケットの伝送は、Tx_MDDI_Data_Before_CRC信号とTx_MDDI_Data_With_CRC信号と同様に、Gen_Reset信号、Check_CRC_Now信号、Generate_CRC_Now信号及びSending_MDDI_Data信号の状態(0又は1)と共に図37Aに示されている。データのパケットの受信及びCRC値のチェックは、Rx_MDDI_Data信号とCRCエラー信号と同様に、Gen_Reset信号、Check_CRC_Now信号、Generate_CRC_Now信号、及びSending_MDDI_Data信号の状態と共に図37Bに示されている。
E.パケットCRCのためのエラーコードオーバロード
データパケットとCRCだけがホストとクライアントの間で転送されているときはつねに、対処されているエラーコードはない。唯一のエラーは同期の損失である。それ以外の場合、リンクが良好なデータ転送経路又はパイプラインの欠如からタイムアウトするのを待機してから、リンクをリセットし、先に進まなければならない。残念なことに、これは多大な時間を必要とし、いくぶん非効率である。
一実施形態で使用するために、パケットのCRC部分がエラーコード情報を転送するために使用される新しい技法が開発された。これは概して図65に示されている。すなわち、1つ又は複数のエラーコードが、通信処理又はリンクの内に発生する可能性のある特定の所定のエラー又は不具合を示すデータ転送を処理するプロセッサ又は装置によって作成される。エラーに遭遇すると、該適切なエラーコードが作成され、パケットのCRCのためのビットを使用して転送される。つまり、CRC値はCRCフィールドの値を監視するエラーモニタ又はチェッカによって受信端で検出できる所望されるエラーコードと共にオーバロードされるか、上書きされる。エラーコードが何らかの理由からCRC値に一致するケースでは、エラーの賛辞(compliment)が混乱を妨げるために転送される。
一実施形態では、ロバストなエラー警告検出システムを提供するために、エラーコードは、エラー検出後に転送又は送信される一連のパケット、通常はすべてを使用して数回転送されてよい。これは、エラーを生じさせた状態がシステムから取り除かれる点まで発生し、その点で規則正しいCRCビットが別の値にオーバロードされることなく転送される。
CRC値をオーバロードするこの技法は、最小量の余分なビット又はフィールドを使用する一方でシステムエラーに対するはるかに迅速な対応を提供する。
図66に示されているように、前述された、あるいは公知の他の回路網の一部を形成できるエラー検出器又は検出手段6602を使用し、通信リンク又はプロセスの中でのエラーの存在又は実在を検出する、CRC上書き機構又は装置6600が示されている。他の回路網の一部として形成できるあるいは、事前に選択されるエラーメッセージを記憶するためにルックアップテーブル等の技法を使用することができるエラーコードジェネレータ又は手段6604は、発生中として検出された特定の所定のエラー又は不具合を示すために1つ又は複数のエラーコードを作成する。デバイス6602と6604が、所望されるように、単一の回路又は装置として、あるいは他の公知のプロセッサと要素のためのステップのプログラミングされたステップの一部として形成できることは容易に理解される。
1つ又は複数の選択されたエラーコードが転送されているCRC値と同じであるかどうかを確かめるためにチェックするためのCRC値コンパレータ又は比較手段6606が示されている。そうである場合には、コード賛辞ジェネレータ又は生成手段又は装置が、元のCRCパターン又は値と間違われないように、及び検出方式を混乱させたり、複雑化しないようにエラーコードの賛辞を提供するために使用される。エラーコードセレクタ又は選択手段要素又は装置6610は、挿入する、又は上書きすることが所望されるエラーコード又は値、あるいはそれらのそれぞれの賛辞を適宜に選択する。エラーコードCRCオーバーラーター又は上書き機構又は手段6612は、挿入されるデータストリーム、パケット及び所望されるコードを受信し、所望されるエラーコードを受信側装置に転送するために対応する又は適切なCRC値を上書きする装置である。
言及されたように、エラーコードは一連のパケットを使用して数回転送されてよいため、オーバーライター6612は、処理中にコードのコピーを維持するためにメモリ記憶素子を活用する、あるいは必要に応じて、又は所望されるようにその値を記憶する又は保持するために使用できる過去の要素又は他の公知の記憶ロケーションからこれらのコードをリコールしてよい。
図66の汎用処理、上書き機構が実現している、さらに詳細に図67Aと図67Bに示されている。図67Aでは、1つ又は複数のエラーが、通信データ又はプロセスのステップ6702で検出され、この状態を示すためにステップ6704でエラーコードが選択される。同時に、又は適切な時点で、置換されるCRC値はステップ6706でチェックされ、ステップ6708で所望されるエラーに比較される。この比較の結果は、前述されたように、所望されたコード又は他の代表的な値が存在するCRC値と同じであるかどうかに関する決定である。これが当てはまる場合、処理は、賛辞、あるいはいくつかのケースでは所望されるように別の代表値が挿入するためのコードとして選択されるステップ6712に進む。どのエラーコード又は値がステップ6710と6714で挿入されなければならないのかがいったん決定されると、その適切なコードが挿入のために選択される。これらのステップは明確にするために別々として描かれているが、通常はステップ6708の決定の出力に基づいた単一の選択である。最後に、ステップ6716では、パケットがプロセスのターゲットとされている状態での転送のために、適切な値がCRCロケーションで上書きされる。
図67Bに示されるように、パケット受信側では、パケットCRC値はステップ6722で監視されている。一般的に、CRC値は、データ転送のエラーが発生したかどうか、及び1つ又は複数のパケットの再送を要求するか否か、あるいは追加の動作を抑制するかどうか等を判断するためにシステム内は1つ又は複数のプロセスに監視されており、そのうちのいくつかは前述されている。情報はこのような監視の一部として値を公知の又は事前に選択されたエラーコード又は代表的な値に比較し、エラーの存在を検出するためにも使用できる。代わりに、別個のエラー検出プロセスとモニタが実現できる。コードが存在すると考えられる場合に、それは抽出され、あるいはそれ以外の場合は追加の処理のためにステップ6724で注記される。これが実際のコードであるのか否か、あるいは賛辞であるのか否かに関する決定はステップ6726で下すことができ、その場合、追加ステップ6728が値を所望されるコード値に変換するために使用される。どちらのケースでも結果として生じる抽出コード、賛辞、又は他の回復された値は、次にステップ6730で送信されたコードからどのようなエラーが発生したのかを検出するために使用される。
V.リンクハイバネーション
MDDIリンクは、迅速にハイバーネーション状態に入り、ハイバーネーション状態から迅速にウェイクアップすることができる。この応答性によって、通信システム又はデバイスは、MDDIリンクをハイバーネーションに頻繁に入れて、電力消費を低減させることが可能となる。なぜなら、使用のために極めて迅速に再びウェイクアップすることができるからである。一つの実施形態では、外部モードクライアントが、初めてハイバーネーションからウェイクアップすると、データレートにおいて、1Mbpsレートに一致したストローブパルスタイミングでそうする。すなわち、MDDI_Stbペアは、500kHzレートでトグルすべきである。一旦、クライアントの特徴がホストによって発見、あるいはホストに通知されると、ホストは一般に、1Mbpsから、クライアントが動作できる最大レートまでの任意のレートでリンクをウェイクアップさせる。内部モードクライアントは、ホストとクライアントとの両方が動作可能な任意のレートでウェイクアップする。これは一般に、内部モードクライアントがウェイクアップした最初の時にも適用可能である。
一つの実施形態では、リンクがハイバーネーションからウェイクアップした時、ホストとクライアントとはパルスのシーケンスを交換する。これらのパルスは、最大リンク動作速度において信号を受信することが要求される差分受信機として、電流のほんの一部のみを消費する低速ライン受信機を用いて検出することができる。ホスト又はクライアントの何れか一方が、リンクをウェイクアップさせることができるので、ウェイクアッププロトコルは、もしもホストとクライアントとの両方が同時にウェイクアップを試みる場合に発生しうる可能な競合を取り扱うように設計される。
ハイバーネーション状態の間、MDDI_DataとMDDI_Stbとの差分ドライバが高インピーダンス状態でディスエーブルされ、全ての差分ペアの間の差分電圧はゼロボルトである。ハイバーネーションからのウェイクアップの間にパルスのシーケンスを検出するために使用される差分ライン受信機は、意図的な電圧オフセットを持っている。一つの実施形態では、これら受信機における論理1レベルと論理0レベルとの間の閾値は、約125mVである。これは、リンクウェイクアップシーケンスの間、論理ゼロレベルとして見られる駆動されない差分ペアをもたらす。
ハイバーネーション状態に入るためには、リンクシャットダウンパケットのCRCの後、ホストが64MDDI_Stbサイクルを送る。ホストは、CRCの後、16から56MDDI_Stbサイクルの範囲にあるホストのMDDI_Data0出力をディスエーブルにする(出力ディスエーブル伝搬遅延を含む)。ホストは、リンクシャットダウンパケットのCRCの後、ウェイクアップシーケンスを開始する前に、64MDDI_Stbサイクルを送ることを完了する。一つの実施形態では、ホストによるウェイクアップの開始は、MDDI_Stb上でパルスを駆動する前、MDDI_Data0が有効な論理1レベルに達した後、少なくとも100ns待つ必要があるホストとして定義される。一つの実施形態では、クライアントは、MDDI_Data0を論理1レベルに駆動してホストをウェイクアップさせることを試みる前に、リンクシャットダウンンパケットのCRCの後、少なくとも60MDDI_Stbサイクル待つ。
ハイバーネーション状態から「ウェイクアップ」するためには、幾つかの動作又は処理が行われる。他の期間も所望されるように使用できるが、MDDI_Stbは、MDDI_Stbがアクティブになった後に、非アクティブであり、約70MDDI_Stbサイクル(60から80の範囲にわたって)の間、論理1レベルに駆動されたMDDI_Data0を保つが、クライアント、ここではディスプレイはデータ又は通信、サービスをホストから必要とするとき、約70μsecから1000μsecの間、MDDI_Data0線路を論理1状態に駆動することによって要求パルスを生成する。次にクライアントは、高インピーダンス状態にすることによりMDDI_Data0ドライバをディスエーブルする。
可能性は低いがMDDI_Stbがハイバネーション中にアクティブである場合は、クライアントは70MDDI_Stbサイクルの間(60から80の範囲にわたって)論理1状態にMDDI_Data0を駆動するに過ぎない可能性がある。この動作により、ホストは順方向リンク(208)でデータトラフィックを起動又は再起動し、そのステータスについてクライアントをポーリングする。
ホストは要求パルスの存在を検出してから、まず、MDDI_Stbを論理ゼロレベルに、MDDI_Data0を論理高レベルに、少なくとも約200ns駆動する起動シーケンスを開始しなければならない。そして、トグル中、MDDI_Stbは、約150MDDI_Stbサイクル(140から160の範囲)の間、MDDI_Data0を論理1レベルに、約50MDDI_Stbサイクルの間、論理ゼロに駆動し続ける。クライアントは、論理1状態で80MDDI_Stbサイクルを超えてMDDI_Data0を検出する場合にサービス要求パルスを送信してはならない。クライアントが、60〜80MDDI_Stbサイクルの間、論理1レベルにおいてMDDI_Data0を検出した時、ホストが、50MDDI_Stbサイクルの間、MDDI_Data0を論理ゼロレベルに駆動した間隔を探索し始める。ホストが、50MDDI_Stbサイクルの持続時間の間、MDDI_Data0を論理ゼロレベルに駆動した後、ホストは、リンク上でパケットを送り始める。送られる最初のパケットはサブフレームヘッダパケットである。クライアントは、50サイクル間隔の40MDDI_Stbサイクルの間、MDDI_Data0が、論理ゼロレベルであった後、サブフレームヘッダパケットを探索し始める。ハイバネーション処理と起動シーケンスに関連する時間の選択及び時間間隔の公差の性質は後述されるとおりである(以下の68A−Cを参照すること)。
ホストは、まずMDDI_Stbをイネーブルすることによってウェイクアップを開始し、同時にそれを論路ゼロレベルに駆動する。MDDI_Stbは、以下に述べるように、パルスが出力されるまで、論理1レベルに駆動されるべきではない。MDDI_Stbが論理ゼロレベルに達した後、ホストはMDDI_Data0をイネーブルし、同時にそれを論理1レベルに駆動する。MDDI_Data0は、ウェイクアッププロセスの間、以下に述べるように、50MDDI_Stbパルスの期間中、論理ゼロレベルに駆動される期間まで論理ゼロレベルに駆動されるべきではない。ホストは、MDDI_Stb上でパルスを駆動する前、MDDI_Data0が有効な論理1レベルに達した後、少なくとも200ns待つべきである。この時間関係は、最悪ケースの出力可能遅延を考慮している間に起こる。これは、ホストによって駆動されたMDDI_Data0上の論理1レベルによってアウェイクされた後にMDDI_Stb受信機を完全にイネーブルにするための十分な時間をクライアントが持っていることを実質的に保証する。
競合状態のない典型的なクライアントサービス要求イベント3800のための処理ステップの例は、イベントが文字A、B、C、D、E、F及びGを使用して図解の便宜上名付けられている図38に描かれている。プロセスは、ホストがクライアントデバイスに、リンクが低電力ハイバネーション状態に遷移することをそれに知らせるために、リンクシャットダウンパケットを送信するときに点Aで開始する。次のステップで、ホストは、MDDI_Data0ドライバをディスエーブルし、MDDI_Stbドライバを点Bで示されるように論理ゼロに設定することによって低電力ハイバネーション状態に入る。MDDI_Data0は高インピーダンスバイアスネットワークによって論理ゼロレベルに駆動される。しばらくしてから、クライアントはMDDI_Data0を、点Cで見られるような論理1レベルに駆動することによってサービス要求パルスをホストに送信する。ホストは高インピーダンスバイアスネットワークを使用して依然として論理ゼロレベルをアサートするが、クライアントの中のドライバが強制的に回線を論理1レベルにする。50μsec以内にホストはサービス要求パルスを認識し、点Dで見られるように、そのドライバをイネーブルすることによってMDDI_Data0上で論理1レベルをアサートする。次に、クライアントはサービス要求パルスをアサートしようとするのやめ、クライアントは点Eで見られるように、そのドライバを高インピーダンス状態にする。ホストは、点Fで示されるように50μsecの間MDDI_Data0を論理ゼロレベルに駆動し、MDDI_Data0の論理ゼロレベルと一貫した方法でMDDI_Stbを作成し始める。クライアントは、40MDDI_Stbサイクルの間、MDDI_Data0が論理ゼロレベルにあった後、サブフレームヘッダパケットを探索し始める。MDDI_Data0を論理ゼロレベルにアサートし、MDDI_Stbを50μsecの間駆動した後に、ホストは点Gで示されるようにサブフレームヘッダパケットを送信することにより順方向リンクでデータの送信を開始する。
類似する例は、リンク再起動シーケンスが開始後にサービス要求がアサートされ、イベントがやはり文字A、B、C、D、E、F及びGを使用して名付けられる図39に示されている。これは、要求パルス又はクライアントからの信号がサブフレームヘッダパケットを破壊しそうになる最悪のケースのシナリオを表している。プロセスは、ホストがクライアントデバイスに、リンクが低電力ハイバネーション状態に遷移することをそれに知らせるために再びリンクシャットダウンパケットを送信するときに、点Aで開始する。次のステップでは、ホストは、点Bで示されるように、MDI_Data0ドライバをディスエーブルし、MDDI_Stbドライバを論理ゼロレベルに設定することによって低電力ハイバネーション状態に入る。前記のように、MDDI_Data0は、高インピーダンスバイアスネットワークによって論理ゼロレベルに駆動される。しばらくすると、ホストは、点Cで見られるように150μsecの間論理1レベルにMDDI_Data0を駆動することによってリンク再起動シーケンスを開始する。リンク再起動シーケンス開始後50μsecが経過する前に、ディスプレイは点Dで見られるように70μsecの持続期間MDDI_Data0もアサートする。これは、ディスプレイがホストからのサービスを要求する必要があり、ホストがすでにリンク再起動シーケンスを開始したことを認識していないために発生する。次にクライアントはサービス要求パルスをアサートしようとすることをやめ、点Eで見られるように、クライアントはそのドライバを高インピーダンス状態にする。ホストは論理1レベルにMDDI_Data0を駆動し続ける。ホストは点Fに示されているように、50μsecの間MDDI_Data0を論理ゼロレベルに駆動し、MDDI_Data0での論理ゼロレベルと一貫するようにMDDI_Stbも作成し始める。MDDI_Data0を論理ゼロレベルにアサートし、MDDI_Stbを50μsec駆動した後、ホストはサブフレームヘッダパケットを送信することにより順方向リンクでデータの送信を開始する。
前記説明から、過去の解決策が、スリープ解除シーケンスの一部としてホストに2つの状態を経験させることを必要としたことが分かる。第1の状態の場合、ホストは150μsの間MDDI_Data0信号を高に駆動し、次に、MDDI_Stb回線をアクティブ化する一方で50μsの間MDDI_Data0信号を低に駆動し、次にMDDIパケットの送信を開始する。このプロセスは、MDDI装置と方法を使用して達成可能なデータレートという点で最先端に進展するためにうまく働く。しかしながら、前述されたように、状態に対する応答時間の短縮又は次のステップ又はプロセスをより迅速に選択できるようにするという点でのさらなる速度は処理又は要素を簡略化する能力であり、つねに要求されている。
出願人は、ホストが信号トグルのためにクロックサイクルベースのタイミングを使用するスリープ解除処理及びタイミングに対する新しい発明の手法を発見した。この構成では、ホストは、ホストがスリーブ解除シーケンスの始まりにMDDI_Data0信号を高に駆動してから0から10μsec、MDDI_Stbのトグルを開始し、信号が低に駆動されるまで待機しない。スリープ解除シーケンスの間、ホストは、MDDI_Data0信号がつねに論理ゼロレベルであるかのようにMDDI_Stbをトグルする。これは事実上クライアント側から時間の概念を排除し、ホストは、最初の2つの状態のための過去の150μsの期間と50μsの期間から、これらの期間の間の150クロックサイクルと50クロックサイクルに変化する。
ホストはそのデータラインを高に駆動することに責任を持つようになり、10−クロックサイクルのうちに、データラインがゼロであるかのようにストローブ信号の送信を開始する。ホストが150クロックサイクルの間データラインを高に駆動した後、ホストは、ストローブ信号の送信を続けながら50クロックサイクルの間データラインを低に駆動する。ホストは、これらのプロセスの両方ともを完了後、最初のサブフレームヘッダパケットの送信を開始できる。
クライアント側では、クライアントインプリメンテーションは、ここでデータラインが最初は高く、次に低くなるクロックサイクル数を計算するために生成されたクロックを使用できる。データライン駆動高状態で発生する必要のあるクロックサイクル数は150であり、データライン駆動低状態で発生する必要のあるクロックサイクル数は50である。つまり、適切なスリープ解除シーケンスのために、クライアントは、低であるデータ利案の少なくとも50の連続クロックサイクルが後に続く、高であるデータラインの少なくとも150の連続クロックサイクルをカウントできなければならない。いったんこれらの2つの条件が満たされると、クライアントは第1のサブフレームの一意のワードの検索を開始できる。このパターンの中断は、カウンタを、クライアントが高であるデータラインの最初の150連続クロックサイクルを再び探す初期状態に戻すための基礎として使用される。
ハイバネーションからのホストベースのスリープ解除のための本発明のクライアントインプリメンテーションは、クロックレートが前述されたように1Mbpsで強制的に開始されないことを除き、初期の起動ケースに非常に類似している。代わりに、クロックレートは、通信リンクがハイバネーションに入ったときにどのような過去の速度でアクティブであっても再開するために設定できる。ホストが前述されたようにストローブ信号の伝送を開始すると、クライアントは、低であるデータラインの少なくとも50連続クロックサイクルが後に続く、高であるデータラインの少なくとも150連続クロックサイクルを再びカウントできなければならない。いったんこれらの2つの条件が満たされると、クライアントは一意のワードの検索を開始できる。
ハイバネーションからのクライアントベースのスリープ解除のための本発明のクライアントインプリメンテーションは、それがクライアントにデータラインを駆動させることによって起動するという点を除きホストベースのスリープ解除に類似している。クライアントはホストデバイスをスリープ解除するために、クロックを使用せずにデータラインを非同期で駆動できる。いったんホストが、データラインがクライアントによって高に駆動されていると認識すると、それはそのスリーブ解除シーケンスを開始できる。クライアントは、ホストがそのスリープ解除プロセスを開始することによって、あるいはそのスリープ解除プロセスの間に生成されるクロックサイクルの数をカウントできる。いったんクライアントが高であるデータの70連続クロックサイクルをカウントすると、それはデータラインを高に駆動するのを停止できる。この点で、ホストはすでにデータラインも高にしているはずである。クライアントは、次に高であるデータラインの150クロックサイクルに達するために、高であるデータラインの別の80連続クロックサイクルをカウントすることができ、次に低であるデータラインの50クロックサイクルを探すことができる。いったんこれらの3つの条件が満たされると、クライアントは一意のワードを探し始めることができる。
スリープ解除処理のこの新しいインプリメンテーションの利点とは、それが時間測定装置に対する必要性を排除するという点である。これが発振器であるのか、あるいはコンデンサ式放電回路であるのか、あるいは他のこのような公知の装置であるのかに関係なく、クライアントは起動状態を確認するためにもはやこのような外部装置を必要としない。これにより、コントローラ、カウンタ等をクライアントデバイスボードで実現するときに資金と回路面積を節約する。これはクライアントにとって利点ではない可能性があるが、ホストにとってはこの技法はコア回路網のために使用される超高密度論理回路(VHDL)という点でホストを潜在的に簡略化するはずである。コア要素がホストベースのスリープ解除を待機するために外部回路網が実行している必要はないため、スリープ解除通知及び測定ソースとしてデータラインとストローブラインを使用することの電力消費も低くなる。使用されたサイクル又はクロック期間の数は例示的であり、他の期間は当業者に明らかとなるように使用できる。
スリープ解除処理のこの新しいインプリメンテーションの利点とは、それが時間測定装置に対する必要性を排除するという点である。これが発振器であるのか、あるいはコンデンサ式放電回路であるのか、あるいは他のこのような公知の装置であるのかに関係なく、クライアントは起動状態を確認するためにもはやこのような外部装置を必要としない。これにより、コントローラ、カウンタ等をクライアントデバイスボードで実現するときに資金と回路面積を節約する。これはクライアントにとって利点ではない可能性があるが、ホストにとってはこの技法はコア回路網のために使用される超高密度論理回路(VHDL)という点でホストを潜在的に簡略化するはずである。コア要素がホストベースのスリープ解除を待機するために外部回路網が実行している必要はないため、スリープ解除通知及び測定ソースとしてデータラインとストローブラインを使用することの電力消費も低くなる。
この新しい技法の動作を明確にし、説明するために、MDDI_Data0、MDDI_Stb及びクロックサイクルに関する多様な動作のタイミングが図68A、図68B及び図68Cに示されている。
競合のない典型的なホスト起動型スリープ解除の処理ステップの例は、文字A、B、C、D、E、F及びGを使用して、イベントが図中再び便宜上名付けられている図68Aに示されている。プロセスは、ホストがクライアントデバイスに、それにリンクが低電力ハイバネーション状態に遷移することを知らせるためにリンクシャットダウンパケットを送信するときに点Aで開始する。次のステップ、点Bでは、ホストは、MDDI_Stbがトグルするのを停止する前にクライアントによる処理を完了できるようにするために、約64サイクル(あるいはシステム設計のために所望されるとおりに)MDDI_Stbをトグルし、クライアントデバイス内の回復したクロックを停止する。ホストは、当初MDDI_Data0を論理ゼロレベルに設定してから、MDDI_Data0出力を、CRC後に16サイクルから48サイクル(通常は出力ディスエーブル伝播遅延を含む)の範囲でMDDI_Data0出力をディスエーブルする。CRCから48サイクル後、及び次の段階(C)の前にクライアント内のMDDI_Data0とMDDI_Stbのための高速受信機を低電力状態にすることは望ましい場合がある。
ホストはMDDI_Data0ドライバとMDDI_Stbドライバをディスエーブルし、ホストコントローラを低電力ハイバネーション状態にすることによって点又はステップCで低電力ハイバネーション状態に入る。所望されるように(高インピーダンスバイアスネットワークを使用して)MDDI_Stbドライバを論理ゼロレベルに設定する、あるいはハイバネーションの間トグルを続けることもできる。クライアントは低電力レベルハイバネーション状態にもある。
しばらくしてから、ホストはMDDI_Data0ドライバ出力とMDDI_Stbドライバ出力をイネーブルすることによって点Dでリンク再起動シーケンスを開始する。ホストは、ドライバがそのそれぞれの出力を完全にイネーブルするために要する時間の限り、MDDI_Data0を論理1レベルに、MDDI_Stbを論理ゼロレベルに駆動する。ホストは、通常、MMDI=Stbdeパルスを駆動する前に、これらの出力が所望される論理レベルに達してから約200ナノ秒待機する。これにより、受信を準備するためのクライアント時間が可能になる。
ホストドライブがイネーブルされ、MDDI_Data0が論理1レベルに駆動されている状態で、ホストは、点Eで見られるように150MDDI_Stbサイクルの持続期間中MDDI_Stbのトグルを開始する。ホストは、点Fで示されているように50サイクル、MDDI_Data0を論理ゼロレベルに駆動し、クライアントは、MDDI_Data0が40MDDI_Stbサイクルの間論理ゼロレベルにあった後にサブフレームヘッダパケットを探し始める。ホストは、点Gで示されているようにサブフレームヘッダパケットを送信することによって順方向リンクでデータ送信を開始する。
競合のない典型的なホスト起動型スリープ解除の処理ステップの例は、文字A、B、C、D、E、F、G、H及びIを使用して、イベントが図中再び便宜上名付けられている図68Bに示されている。前記のように、プロセスは、ホストがクライアントに、それにリンクが低電力状態に遷移することを知らせるためにリンクシャットダウンパケットを送信するときに点Aで開始する。
点Bでは、ホストは、MDDI_Stbがトグルするのを停止する前にクライアントによる処理を完了できるようにするために約64サイクル(又はシステム設計のために所望されるとおりに)MDDI_Stbをトグルし、クライアントデバイス内の回復されたクロックを停止する。ホストは当初MDDI_Data0も論理ゼロレベルに設定し、次にCRC後に16から48サイクル(通常は出力ディスエーブル伝搬遅延を含む)の範囲でMDDI_Data0出力をディスエーブルする。CRC後の48サイクルの後で、次の段階(C)の前に、クライアント内のMDDI_Data0とMDDI_Stbのための高速受信機を低電力状態にすることが望ましい場合がある。クライアントは、リンクシャットダウンパケットのCRCの後、48番目のMDDI_Stbサイクルの上昇端の後の任意の時間に、MDDI_Data0及びMDDI_Stbのための高速受信機をハイバーネーションにする。クライアントが、リンクシャットダウンパケットのCRCの後、64番目のMDDI_Stbサイクルの上昇端の前の任意の時間に、MDDI_Data0及びMDDI_Stbのための高速受信機をハイバーネーションにすることが推奨される。
ホストはMDDI_Data0ドライバとMDDI_Stbドライバをディスエーブルし、ホストコントローラを低電力ハイバネーション状態にすることによって点つまりステップCで低電力ハイバネーション状態に入る。所望されるように、(高インピーダンスバイアスネットワークを使用して)MDDI_Stbドライバを論理ゼロレベルに設定すること、あるいはハイバネーションの間トグルし続けることもできる。クライアントも低電力レベルハイバネーション状態にある。
しばらくしてから、クライアントは、MDDI_Stb受信機をイネーブルし、MDDI_Stbの受信されたバージョンが、ホストがそのMDDI_Stbドライバをイネーブルする前にクライアントの論理ゼロレベルにあると保証するためにMDDI_Stb受信機でオフセットをイネーブルすることによっても点Dでリンク再起動シーケンスを開始する。所望されるように有効な差動信号の受信を保証し、誤りのある信号を抑止するために、クライアントが、受信機をイネーブルするのよりわずかに先にオフセットをイネーブルすることが望ましい場合がある。クライアントは、MDDI_Data0ラインを論理1レベルに駆動する一方でMDDI_Data0ドライバをイネーブルする。オフセットをイネーブルし、標準的なMDDI_Stb差分受信機をイネーブルする時間が200ns未満である場合、MDDI_Data0とMDDI_Stbとが同時にイネーブルされることが許可される。
約1msec以内、点E内に、ホストはクライアントからのサービス要求パルスを認識し、ホストはMDDI_Data0ドライバ出力とMDDI_Stbドライバ出力をイネーブルすることによってリンク再起動シーケンスを開始する。ホストは、ドライバがそのそれぞれの出力をイネーブルするのにかかる限り、MDDI_Data0を論理1レベルに、MDDI_Stbを論理ゼロレベルに駆動する。ホストは通常、MDDI_Stbでパルスを駆動する前に、これらの出力が所望される論理レベルに達してから約200ナノ秒待機する。これによりクライアントに受信に備える時間が与えられる。
ホストドライバがイネーブルされ、MDDI_Data0が論理1レベルに駆動されている状態で、ホストは、点Fで見られるように150MDDI_Stbサイクルの持続期間、MDDI_Stbでパルスを出力し始める。クライアントは、MDDI_Stbで最初のパルスを認識すると、そのMDDI_Stb受信機でオフセットをディスエーブルする。クライアントは70MDDI_Stbサイクルの間論理1レベルにMDDI_Data0を駆動し続け、点GでMDDI_Dat0ドライバをディスエーブルする。ホストは、更に80MDDI_Stbパルスの間、MDDI_Data0を論理1レベルに駆動し続け、点Hにおいて、MDDI_Data0を論理ゼロレベルに駆動する。
点GとHで見られるように、ホストは50サイクルの間MDDI_Data0を論理ゼロレベルに駆動し、クライアントは、MDDI_Data0が40MDDI_Stbサイクルの間論理ゼロレベルにあった後サブフレームヘッダパケットを探し始める。MDDI_Stbを50サイクルの間駆動した後、ホストは、点Iで見られるようにサブフレームヘッダパケットを送信することにより順方向リンクでデータ送信を開始する。
クライアントから競合がある、つまりクライアントもリンクをスリープ解除することを希望する典型的なホスト起動型スリーブ解除のための処理ステップの例は、図68Cに示されている。イベントは、文字A、B、C、D、E、F、G、H及びIを使用して図中、便宜上再び名付けられる。前記のように、プロセスは、ホストがクライアントに、リンクが低電力状態に遷移することを知らせるためにリンクシャットダウンパケットを送信するときに点Aで開始し、クライアントによる処理を完了できるようにするために、MDDI_Stbが約64サイクルの間(又はシステム設計のために所望されるとおりに)トグルされる点Bに進み、それから、MDDI_Data0ドライバとMDDI_Stbドライバをディスエーブルし、ホストコントローラを低電力ハイバネーション状態にすることによってホストが低電力ハイバネーション状態に入る点Cに進む。しばらくしてから、ホストは、MDDI_Data0ドライバ出力とMDDI_Stbドライバ出力をイネーブルすることによって点Dでリンク再起動シーケンスを開始し、点Eで見られるように150MDDI_Stbサイクルの期間、MDDI_Stbのトグルを開始する。
点Eの後最大70MDDI_Stbサイクルで、ここでは点Fで、クライアントはまだ、ホストが論理1レベルにMDDI_Data0を駆動していることを認識していないため、クライアントもMDDI_Data0を論理1レベルに駆動する。これは、クライアントがサービスしたいという望みを有するが、それが通信しようとしているホストがすでにリンク再起動シーケンスを開始していることを認識していないためにここで発生する。点Gでは、クライアントはMDDI_Data0を駆動するのをやめ、その出力をディスエーブルすることによってそのドライバを高インピーダンス状態にする。ホストは、追加の80サイクルMDDI_Data0を論理1レベルに駆動し続ける。
ホストは、点Hで示されているように50サイクルの間、MDDI_Data0を論理ゼロレベルに駆動し、クライアントは、MDI_Data0が40 MDD_Stbサイクルの間論理ゼロレベルにあった後にサブフレームヘッダパケットを探し始める。ホストは点Iに示されているようにサブフレームヘッダパケットを送信することによって順方向リンクでデータの転送を開始する。
VI.インタフェース電気仕様
例の実施形態では、非ゼロ復帰(NRZ)フォーマットは、クロック情報をデータ信号とストローブ信号の中に埋め込むことを可能にするデータ−ストローブ信号又はDATA−STBフォーマットを使用して符号化される。クロックは、複雑な移送ロックループ回路網を使用しなくても回復できる。前述されたように他の導線、プリント配線、又は転送要素を使用することもできるが、データは双方向差動リンク上で伝搬され、通常ワイヤラインケーブルを使用して実現される。ストローブ(STB)信号は、ホストによってのみ駆動される単向性のリンク上で伝搬される。ストローブ信号は、データライン又は信号上で同じままとなる連続状態0又は1があるときはつねに値(0又は1)をトグルする。
ビット「1110001011」等のデータシーケンスをDATA−STB符号化を使用してどのようにして送信できるのかの例は図40にグラフ形状で示されている。図40では、DATA(データ)信号4002は、信号タイミングチャートの一番上の行に示され、STB(ストローブ)信号4004は2番目の行に示され、毎回適宜に位置合わせされている(共通開始点)。時間が過ぎるにつれて、データライン4002(信号)で状態の変化が発生し、次にSTB(ストローブ)ライン4004(信号)が過去の状態を維持し、このようにしてデータ信号の第1の「1」状態は、その開始値であるSTB(ストローブ)信号の最初の「0」状態と相関する。しかしながら、もしデータ信号の状態、レベルが変化しないときには、データが別の「1」値を提供する図40のケースと同様に、STB信号は本例で反対の状態つまり「1」にトグルする。つまり、DATAとSTBの間にはビットサイクルあたりただ1つの遷移しかない。したがって、DATA(データ)信号が「1」でとどまるのでSTB信号は再び、今回は「0」に遷移し、DATA(データ)信号がレベルを「0」に変えると、このレベル又は値を保持する。データ(DATA)信号が「1」にとどまるときには、DATA(データ)信号が変化する、あるいはレベル又は値を保持するので、STB(ストローブ)信号は本例では反対の状態、つまり「1」にトグルする等である。
これらの信号を受信すると、排他的OR(XOR)演算が、所望されるデータ信号とストローブ信号との相対比較のためにタイミングチャートの下部に示されている、クロック信号4006を作成するためにDATA(データ)信号とSTB(ストローブ)信号で実行される。ホストにある入力データからDATA(データ)出力又は信号とSTB(ストローブ)出力又は信号を生成し、次にクライアントにあるデータからDATA(データ)信号とSTB(ストローブ)信号を回復する又は捕捉しなおすための有効な回路網の例は図41に示されている。
図41では、受信部分4120は信号を受信し、データを回復するために使用されるが、伝送部分4100は、中間信号経路4102上でオリジナルのDATA(データ)信号とSTB(ストローブ)信号を生成し、送信するために使用される。図41に示されているように、ホストからクライアントにデータを転送するために、DATA(データ)信号は回路をトリガするためのクロック信号と共に、2つのD型フリップフロップ回路要素4104と4106に入力される。該2つのフリップフロップ回路出力(Q)は、次に、2台の差動ラインドライバ4108と4110(電圧モード)を使用してそれぞれ信号MDDI_Data0、MDDI_Data0−、及びMDDI_Stb+、MDDI_Stb−の差動組に分割される。3入力排他的NOR(XNOR)ゲート、回路、又は論理素子4112は両方のフリップフロップのDATA(データ)と出力を受信するために接続され、同様にMDDI_Stb+信号、MDDI_Stb−信号を生成する第2のフリップフロップにデータ入力を提供する出力を生成する。便宜上、XNORゲートはそれが事実上ストローブを生成するフリップフロップのQ出力を反転していることを示すために反転バブル(inversion bubble)を設置させる。
図41の受信部分4120では、MDDI_Data0+信号、MDDI_Data0−信号及びMDDI_Stb+信号、MDDI_Stb−信号が、差動信号から単一の出力を生成する2台の差動ラインレシーバ4122と4124のそれぞれにより受信される。増幅器の出力は次に2入力排他的OR(XOR)ゲート、回路、又はクロック信号を発生させる論理素子4126の入力のそれぞれに入力される。該クロック信号は、遅延素子4132を通してDATA(データ)信号の遅延バージョンを受信する2つのD型フリップフロップ回路4128と4130のそれぞれをトリガするために使用され、その内の一方(4128)がデータ「0」値を生じさせ、他方(4130)がデータ「1」値を生じさせる。クロックはXOR論理から独立した出力も有する。クロック情報はDATA(データ)回線とSTB(ストローブ)回線の間で分配されるため、どちらの信号も、クロックレートの半分より高速な状態の間で遷移しない。クロックはDATA(データ)信号とSTB(ストローブ)信号の排他的OR処理を使用して再生されるため、システムは、事実上、クロック信号が単一の専用データラインで直接的に送信されるときの状況に比べて、入力データとクロック間の二倍の量の歪みに耐えている。
MDDIデータペア、つまりMDDI_Stb+信号とMDDI_Stb−信号は、雑音の負の影響からの免疫を最大限にするために差動モードで運用される。各差分ペアは、信号を伝送するために使用されるケーブル又は導電体の特性インピーダンスで並列終端されている。一般に、全ての並列終端は、クライアントデバイス内に存在する。これは、順方向トラフィック(ホストからクライアントに送られたデータ)の場合の差分受信機に近いが、それは、逆方向トラフィック(クライアントからホストに送られたデータ)の場合のケーブル又はその他の導電体、又は転送要素の駆動端にある。逆方向トラフィックの場合、信号はクライアントによって駆動され、ホストにおいて高インピーダンス受信機によって反射され、クライアントにおいて終端される。上述したように逆方向リンクによるデータ又は逆方向データは、ケーブル内における往復遅延の逆数より大きいデータレートで転送または送られうる。MDDI_Stb+信号とMDDI_Stb−信号はホストによってのみ駆動される。
本発明のMDDIの一部として信号を転送するためのドライバ、受信機及び終端を達成するために有効な要素の例示的な構成は図42に示されている。この例示的なインタフェースは、1ボルト未満の脱調と低電力排出で低圧感知、ここでは200mVを使用する。各信号ペアのドライバは、差分電流出力を持つ。MDDIパケットを受信している間、MDDI_DataとMDDI_Stbとのペアは、ゼロボルトの差分電圧閾値を持つ従来式の差分受信機を用いる。ハイバーネーション状態では、ドライバ出力がディセーブルされ、並列終端抵抗が、各信号ペアにおける差分電圧をゼロボルトにする。ハイバーネーションの間、MDDI_Data0ペア上の特別の受信機は、正の125mVのオフセット入力差分電圧閾値をもつ。これは、ハイバーネーションライン受信機に対して、駆動されていない信号ペアを、論理ゼロレベルとして解釈させる。
差分ペアの差分電圧は、正(+)の信号についての電圧から、負(−)の信号についての電圧を引いた差として定義される。“+”又は“−”の何れかを用いた差分ペア信号の名前は、ペアの正の信号、又は負の信号をそれぞれ示す。差分ペアのドライバの出力電流は、正(+)の出力の電流フローとして定義される。差分ドライバの負(−)の出力を通る電流は、常に大きさが等しいが、同じ差分ドライバの正(+)の出力を通る電流と反対方向である。
しばしばホスト又はクライアントは、データ流れ方向が変わった時(ホストからクライアント、又はクライアントからホスト)に、ペア上の有効な論理レベルを保証するために、差分ペアを、論理1レベル又は論理ゼロレベルへ同時に駆動する。出力電圧範囲と出力仕様とは、同じ論理レベルに駆動された同時駆動された出力によって満足されている。あるシステムでは、ハイバーネーションの間、及びリンクがハイバーネーション状態からウェイクアップしたときのうちのある時間において、小さなオフセット電圧を生成するために、小電流を終端差分ペアへ駆動する必要がある。このような状態では、イネーブルされたオフセット電流バイアス回路が、IESD−and−Rx、IEx−Hi−Z、及びIexternal−ESDのように称される電流レベルを駆動する。IESD−and−Rxは、内部EDSダイオード及び差分受信機入力であり一般にIESD−and−Rx≦1μAである。IEx−Hi−Zは、高インピーダンス状態における差分ドライバ出力であり、一般にIEx−Hi−Z≦1μAである。Iexternal−ESDは、外部ESD保護ダイオードを通るリークであり、一般にIexternal−ESD≦3μAである。
これらリーク電流の各々は、図47に示されている。プルアップ及びプルダウン回路は、上述したように、全てが同時に起きる最悪ケースのリーク条件の場合、最小の差分電圧を達成しなければならない。合計リークは、外部ESD保護ダイオードを持たない内部モードの場合≦4μAであり、外部ESD保護を持つ外部モードの場合≦10μAである。
差動ラインドライバとラインレシーバの電気的なパラメータと特性は表IXa−IXd内に典型的な実施形態として記述されている。機能的に、ドライバは入力で直接的に論理レベルを正の出力に、入力の逆数を負の出力に転送する。入力から出力への遅延は差動的に駆動される差動線路に十分に整合されている。大部分のインプリメンテーションでは、出力での電圧振幅は、電力消費と電磁放射線を最小限に抑えるために入力での振幅より少ない。一つの実施形態では、最小電圧振幅は、約0.5Vである。しかしながら、当業者により知られるであろうように他の値が使用でき、発明者らは設計の制約に応じていくつかの実施形態ではさらに小さい値を意図する。
差動ラインレシーバは高速電圧コンパレータと同じ特性を有する。図41では、バブルのない入力は正の入力であり、バブルのある入力は負の入力である。出力は、(Vinput+)−(Vinput−)がゼロより大きい場合には、論理1である。これを説明する別の方法は、非常に大きな(実質的には無限の)利得を有する差動増幅器であり、出力は論理0電圧レベルと1電圧レベルでクリッピングされる。
様々な組の間の遅延歪みは、差動伝送システムを潜在的な最高の速度で動作するために最小限に抑えられなければならない。
Figure 2007534232
Figure 2007534232
Figure 2007534232
Figure 2007534232
図42では、通信リンク4206上でパケットを転送しているホストコントローラ4202とクライアント又はディスプレイコントローラ4204が示されている。ホストコントローラは、転送されるクライアントデータ信号を受信するためだけではなく、転送されるホストDATA(データ)信号とSTB(ストローブ)信号を受信するためにも一連の3台のドライバ4210、4212、及び4214を利用する。一方、クライアントは、3つのドライバ4230,4232,4234を適用する。ホストデータ(4212)の通過に関与するドライバは、ホストからクライアントへの転送が所望されるときにだけ通常通信リンクの起動を可能にするために、イネーブル信号入力を利用する。STB(ストローブ)信号はデータの転送の一部として形成されるので、追加のイネーブル信号はそのドライバ(4212)に利用されない。クライアントDATA(データ)ドライバとSTB(ストローブ)ドライバ(4132,4230)のそれぞれの入力は、それぞれ間をあけて配置された終端インピーダンス又は抵抗器4218,4220を有している。クライアントコントローラ内のドライバ4234は、クライアントからホストへ転送されているデータ信号を準備するために使用される。ここでは、ドライバ4214が入力側にあり、データを処理する。
特別な受信機(ドライバ)4216,4236がデータ線路に結合又は接続され、他の箇所で説明されたハイバネーション制御の一部として、上述したように、125mV電圧オフセットを生成又は使用する。これらオフセットは、ハイバーネーションライン受信機に対して、駆動されていない信号ペアを論理ゼロレベルとして解釈させる。
前記ドライバ及びインピーダンスは離散構成要素として、あるいは回路モジュール又はさらに費用効果の高いエンコーダ又はデコーダ解決策として働く特定用途向け集積回路(ASIC)の一部として形成できる。
電力が、HOST_PwrとHOST_Gndと呼ばれる信号を1組の導線上で使用して、クライアントデバイス、つまりディスプレイに、ホストデバイスから転送されるのは容易に理解できる。信号のHOST_Gnd部分は、基準接地、及び電源戻り経路又は表示装置用の信号として働く。HOST_Pwr信号はホストデバイスによって駆動されるクライアントデバイス電源として働く。例示的な構成では、低電力応用例の場合、クライアントデバイスは最高500mAまで引き出すことができる。HOST_Pwr信号は、リチウムイオン型電池又はホストデバイス内に常駐する電池パック等を含むが、これらに限定されない携帯電源から提供でき、HOST_Gndに関して3.2ボルトから4.3ボルトの範囲となってよい。
VII.タイミング特性
A.概要
ハイバーネーション状態(何のサービスも要求されず、望まれず、必要とされない)に入り、ホストからクライアントのためのサービスを確保するために、ホスト又はクライアントの何れかによって開始されるために適用されるステップ及び信号レベルは、図43A、図43B、及び図43Cにそれぞれ示されている。図43A、図43B、及び図43Cでは、描かれている信号の第1の部分は、ホストから転送されているリンクシャットダウンパケットであり、データラインは次に高インピーダンスバイアス回路を使用して論理ゼロ状態に駆動される。データはクライアント、つまりそのドライバがディスエーブルされているホストによって送信されていない。MDDI_Stbはリンクシャットダウンパケットの間アクティブであるので、MDDI_Stb信号線路のための一連のストローブパルスは下部に見ることができる。いったんこのパケットが終了すると、ホストがバイアス回路と論理回路をゼロに駆動するので、論理レベルがゼロに変化する。これは、ホストからの最後の信号転送又はサービスの終端を表し、過去におけるいかなる時点でも発生できたであろうし、サービスの過去の休止及びサービス開始前の信号の状態を示すために含まれている。信号が、「公知の」過去の通信がこのホストデバイスによって着手されずに、通信リンクを適切な状態に単にリセットするために信号を送信できる等所望される場合。
図43Aに示すように、そして、リンクシャットダウンパケットについて上述したように、低電力ハイバーネーション状態では、MDDI_Data0ドライバが、リンクシャットダウンパケット内の全ゼロフィールドの最後のビットの後、16番目から48番目のMDDI_Stbサイクル又はパルス後に始まる高インピーダンス状態にディスエーブルされる。2型、3型、又は4型のリンクの場合、MDDI_Data1からMDDI_DataPwr7までの信号もまた、MDDI_Data0ドライバがディスエーブルされるのと同時に、高インピーダンス状態に置かれる。全ゼロフィールドの定義において記載したように、MDDI_Stbは、リンクシャットダウンパケットのCRCフィールドのMSBの後に続く64サイクルのために(又はシステム設計に望まれるように)トグルし、クライアントにより処理が完了するようにし、クライアントコントローラにおける規則的なシャットダウンを容易にする。1サイクルは低から高への遷移の後、高から低への遷移となる。あるいは、高から低への遷移の後、低から高への遷移となる。全ゼロフィールドが送られた後、ホスト内のMDDI_Stbドライバ及びMDDI_Data0ドライバがディスエーブルされ、ホストは、低電力ハイバーネーション状態に入る。いくらか時間が経過した後、ホストは、MDDI_Data0線路及びMDDI_Stb線路又はドライバ出力をイネーブルすることによって、図43B及び図43Cに示すように、リンク再起動シーケンスを開始し、ウェイクアップ要求を開始したクライアント又はホストの何れかの一部としてMDDI_Stbのトグルを開始する。
図43Bに示すように、ディスエーブルされたMDDI_Data0とMDDI_Stbのためのドライバから出力された信号とともに時間が経過した後、ホストは、線路が論理ゼロに駆動されている間、tstb−dagta−enblと指定された期間、MDDI_Stbドライバをイネーブルすることによって、それが完全にイネーブルされ、MDDI_Data0ドライバをイネーブルするまで、ハイバーネーションからウェイクアップするか、あるいはサービスを開始する。ホストは、MDDI_Data0が、tclient−startupと指定された期間にわたって生じる論理1レベル又は高レベルに達した後、MDDI_Stbを論理ゼロレベルに保つ。tclient−startup期間の終わりに、ホストは、MDDI_Stb信号又は線路をトグルする。ホストは、クライアントがMDDI_Data0を駆動しない間、trestart−highと指定された期間、MDDI_Data0線路を高に、論理1レベルに駆動する。そして、trestart−lowと指定された期間、MDDI_Data0線路を低、すなわち論理ゼロレベルに駆動する。この後、第1の転送トラフィックが、サブフレームヘッダパケットとともに始まり、転送トラフィックパケットが転送される。MDDI_Stb信号は、trestart−low期間及び次のサブフレームヘッダパケットの間アクティブである。
図43Cに示すように、ディスエーブルされたMDDI_Data0とMDDI_Stbのためのドライバから出力された信号とともに時間が経過した後、クライアントは、ホストがそのMDDI_Stbドライバをイネーブルする前、上述したように、tstb−dagta−enblと指定された期間、出力信号又はMDDI_Stb受信機におけるオフセットをイネーブルすることによって、ハイバーネーションからのウェイクアップ、又はサービス要求を開始する。その後、クライアントは、ホストがMDDI_Stbトグルを開始する前に、線路が論理ゼロレベルに駆動されている間、thost−detectと指定された期間、そのMDDI_Data0ドライバをイネーブルする。
restart−high期間、MDDI_Data0を論理1又は高レベルに駆動することによって、ホストがリンク起動シーケンスを用いてMDDI_Stbのトグルを開始する前、tstb−startupと指定された期間、MDDI_Stbを論理ゼロレベルに保持することによって応答した後、thost−detectの間、ホストが要求を検出する前に一定量の時間が経過するか、あるいは必要とされる。クライアントは、MDDI_Stb上の第1のパルスを認識したとき、そのMDDI_Stb受信機内のオフセットをディスエーブルする。クライアントは、線路を駆動しているホストを検出するまで、MDDI_Data0を論理1レベル又はtclient−detectと指定された期間駆動し続ける。この点において、クライアントは、この要求を逆アサートし、クライアントからの出力が論理ゼロレベルに再び行き、ホストがMDDI_Data0を駆動することができるようにMDDI_Data0ドライバをディスエーブルする。前述したように、ホストは、MDDI_Data0を、trestart−highの間、論理1レベルに駆動し続け、第1の転送トラフィックがサブフレームヘッダパケットを用いて始まった後、trestart−lowの間、MDDI_Data0線路を低に駆動する。MDDI_Stb信号は、trestart−low及び次のサブフレームヘッダパケットの間アクティブである。
表Xは、前述された多様の期間の長さの代表的な時間又は処理期間、及び例示的な最小データレートと最大データレートに対する関係性を示す。
Figure 2007534232
ここで、Link_Data_Rateは、単一のデータペアのビットレートである。
Figure 2007534232
当業者は、図41と図42に示されている個々の要素の機能が周知であり、図42の要素の機能が図43A、図43B、及び図43Cのタイミング図で確認されることを容易に理解する、図42に示されている直列終端及びハイバネーション抵抗器についての詳細は、その情報が、データ−ストローブ符号化を実行し、そこからクロックを回復する方法の説明には不必要であるため図41から省略された。
B.データ−ストローブタイミング順方向リンク
ホストドライバ出力から順方向リンクでのデータ転送の切り替え特性は表XI−1に示されている。表XI−1は、表形式の所望される最小と最大対特定の信号遷移が発生するための典型的な時間を提示する。例えば、最小時間は約ttbit−0.5nsecであり、最大は約ttbit+0.5nsecであるが、遷移がデータ値(「0」又は「1」の出力)の始まりから最後までに発生する典型的な時間の長さ、ttdd−(ホスト−出力)と呼ばれるData0からData0遷移は、ttbitである。Data0、他のデータライン(DataX)、及びストローブ線路(Stb)での遷移間の相対的なスペーシングは、それぞれttds−(ホスト−出力)、ttss−(ホスト−出力)、ttsd−(ホスト−出力)、ttddx−(ホスト−出力)、ttdx−(ホスト−出力)、ttdxs−(ホスト−出力)、及びttsdx−(ホスト−出力)と呼ばれているData0からストローブ、ストローブからストローブ、ストローブからData0、Data0から非Data0、非Data0から非Data0、非Data0からストローブ、及びストローブから非Data0遷移が示されている図44に描かれている。
Figure 2007534232
順方向リンクでデータを転送している同じ信号のクライアント受信機入力のための典型的なMDDIタイミング要件は表XI−2に示されている。同じ信号が説明されているが、時間は遅延しているので、当業者によって理解されるように、それぞれのラベルの信号特性又は意味を説明するために新しい図は必要とされない。
Figure 2007534232
図45と図46は、ホストがそれぞれホストドライバをイネーブル又はディスエーブルするときに発生することがある応答の遅延の存在を図解する。逆方向リンクカプセル化パケット又は往復遅延測定パケット等の特定のパケットを転送しているホストの場合、転送されたとして図45に示されているパラメータCRCパケット、ストローブ位置合わせパケット、及び全ゼロパケット等、ホストは所望されるパケットが転送された後にラインドライバをディスエーブルする。しかしながら、図45に示されているように、これはおそらく特定の制御素子又は回路素子が存在する状態では達成可能であるが、線路の状態は必ずしも「0」から所望されるさらに高い値に瞬時に切り替わらないが、応答にはホストドライバディスエーブル遅延期間と呼ばれている期間を要する。それはこの期間の長さが0ナノ秒(nsec)であるように実質的に瞬時に発生できるが、それは、ガード時間1パケット期間又はターンアラウンド1パケット期間の間に発生する所望される最大期間長である10nsecのさらに長い期間でさらに容易に広がるであろう。
図46を見ると、ホストドライバが逆方向リンクカプセル化パケット又は往復遅延測定パケット等のパケットを転送するためにイネーブルされているときに信号レベル変化が起こったことがわかる。ここでは、ガード時間2パケット期間又はターンアラウンド2パケット期間の後、ホストドライバはイネーブルされ、レベル、ここでは「0」を駆動し始め、その値には、第1のパケットが送信される前に、ドライバ再イネーブル期間の間に発生するホストドライバイネーブル遅延期間と呼ばれる期間に近づく又は達する。
同様のプロセスは、ドライバについて、及びクライアントデバイス、ここではディスプレイのための信号転送について発生する。これらの期間の長さの一般的な指針及びそれぞれの関係性は以下の表XIIに示されている。
Figure 2007534232
C.ホストとクライアントの出力イネーブル及びディセーブル時間
図48には、ホスト出力とクライアント出力とのイネーブル時間及びディスエーブル時間の相対的なタイミング関係、又は逆方向リンクカプセル化パケット構造及び期間、及び切り替え特性を示す図である。ドライバ出力機能又は動作は、ホスト出力イネーブル時間の場合thost−enableと、ホスト出力ディスエーブル時間の場合thost−disableと、クライアント出力イネーブル時間の場合tclient−enableと、クライアント出力ディスエーブル時間の場合tclient−disableとそれぞれラベルされる。ある信号遷移に対する典型的な時間は以下に説明される。これら動作のための最小期間は、ゼロナノ秒となるであろう。インターフェースを適用したシステム設計から決定される一般的又は最大値は、おそらくは8ナノ秒あるいはそれ以上のオーダになるであろう。
これら期間の長さ(ホスト及びクライアントのイネーブル/ディセーブル時間)と、それぞれの関係の一般的なガイドラインは、表XIIIに示されている。
Figure 2007534232
VIII.リンクコントロール(リンクコントローラ動作)のインプリメンテーション
A.状態機械パケットプロセッサ
MDDIリンク上で転送されているパケットは、所望されるようにさらに低い速度で確実に対処されるが、非常に迅速に、通常約300Mbps以上の速度でディスパッチされる。この種のバス又は転送リンクの速度は速すぎて、現在市販されている(経済的な)汎用マイクロプロセッサ等が制御することはできない。したがって、この種の信号転送を達成するための実用的なインプリメンテーションは、それらが意図されている適切な視聴覚サブシステムに転送される又はリダイレクトされるパケットを作成するために入力パケットストリームを解析するためにプログラマブル状態機械を活用することである。このような装置は周知であり、通常、所望される高速又は超高速の動作を達成するためには、限られた数の動作、機能又は状態に専用である回路を使用する。
汎用コントローラ、プロセッサ、又は処理要素は、さらに低い速度要件を有する制御パケット又はステータスパケット等のなんらかの情報により適切に作用する、あるいは操作するために使用できる。それらのパケット(制御、ステータス、又は他の所定のパケット)が受信されると、ステータス機械は、音声パケットと視覚パケットが処置のためにその適切な宛て先に転送される間に所望される結果(効果)を提供するために作用を受けることができるように、それらをデータバッファ又は類似する処理要素を通して汎用プロセッサに渡す必要がある。将来、マイクロプロセッサ又は他の汎用コントローラ、プロセッサ、又は処理要素がより速いデータレート処理機能を達成するために製造される場合には、通常は記憶要素又は媒体に記憶されているプログラムとして、状態、又は後述される状態機械もこのような装置のソフトウェア制御を使用して実現される可能性がある。
汎用プロセッサ機能は、コンピュータアプリケーションにおけるマイクロプロセッサ(CPU)、又はコントローラ、プロセッサ、デジタル信号プロセッサ(DSP)、特殊化した回路、又は無線装置で見つけられるASIC等のために使用可能な処理力又は過剰なサイクルを、いくつかのモデム又はグラフィックプロセッサが何らかの機能を実行するためにコンピュータで見られるCPUの処理力を活用し、ハードウェアの複雑さとコストを削減するためにコンピュータの中で発見されるCPUの処理能力を活用することによりいくつかの実施形態で実現できる。しかしながら、このサイクル共用又は使用は、このような素子の処理速度、タイミング、又は全体的な動作にマイナス影響を及ぼす可能性があるため、多くの応用例では、この汎用処理のために専用回路又は素子が好ましい。
画像データがディスプレイ(マイクロディスプレイ)に表示されるために、あるいはホストデバイスによって送信されるすべてのパケットを確実に受信するために、クライアント信号処理は順方向リンクチャネルタイミングと同期される。つまり、クライアントに到達する信号及びクライアント回路は、適切な信号処理のために実質的に時間同期される必要がある。一つの実施形態において、信号によって達成される高水準図は、図49の図示されている。図49では、1つのASYNC FRAME(非同期フレーム状態)4904、2つの同期取得状態(ACQUIRING SYNC STATES)4902と4906、及び3つの同期中状態(IN−SYNC STATES)4908、4910、及び4912として分類されている状態機械4900の考えられる順方向同期「状態」が示されている。
ステップ又は状態4902を開始することによって示されているように、プレゼンテーション装置のようなディスプレイ又はクライアントは事前に選択された「同期なし」状態で開始し、検出される第1のサブフレームヘッダパケットの一意のワードを検索する。この同期なし状態が、最小通信設定、又は1型インタフェースが選択される「後退」設定を表すことが注記されなければならない。一意のワードが検索中に発見されると、クライアントはサブフレーム長フィールドを保存する。この第1のフレームに対する処理のための、あるいは同期が得られるまで、CRCビットのチェックはない。このサブフレーム長がゼロである場合は、同期状態処理はここで同期がまだ達成されていないことを示す「非同期フレーム」状態と呼ばれる状態4904に相応して進む。処理のこのステップは、図49の遭遇cond3、つまり条件3を有すると名付けられる。それ以外の場合、フレーム長がゼロより大きい場合には、同期状態処理は、インタフェース状態が「1つの同期フレームを発見」として設定される状態4906に進む。処理のこのステップは、遭遇cond5、つまり図49の条件5と名付けられている。さらに、状態機械が、ゼロより大きいフレーム長の間、フレームヘッダパケット及び良好なCRC決定を見る場合、処理は「1つの同期フレームを発見」に進む。これは会議cond6、つまり図49の条件6と名付けられている。
システムが「同期なし」以外の状態にあるそれぞれの状況では、良好なCRC結果を持つパケットが検出されると、インタフェース状態は「同期中」状態4908に変更される。処理の中のこのステップはcond1、つまり図49の条件1に遭遇したとして名付けられている。他方、何れのパケットのCRCも正しくない場合には、同期状態処理は、「同期なしフレーム(NO SYNC FRAME)」状態のインタフェース状態4902に進む、又は戻る。処理のこの部分は遭遇cond2、つまり条件2を図49の状態図と名付けられている。
B.同期の獲得時間
インタフェースは、同期が失われたと決定し、「NO SYNC FRAME(同期なしフレーム)」状態に戻る前に特定数の「同期エラー」に対処するように構成できる。図49では、いったん状態機械が「IN−SYNC STATE(同期中状態)」に到達し、エラーが検出されないと、それは連続してcond1結果に遭遇し、「IN−SYNC(同期中)」状態のままとなる。しかしながら、いったん1つのcond2結果が検出されると、処理は「1同期エラー」状態4910に状態を変更する。この時点で、処理が別のcond1結果を検出する結果となると、状態機械は「同期中」状態に戻り、それ以外の場合、それは別のcond2結果に遭遇し、「TWO−SYNC−ERRORS(2同期エラー)」状態4912に移る。再びcond1が発生すると、処理は状態機械を「IN−SYNC(同期中)」状態に戻す。それ以外の場合、別のcond2に遭遇し、状態機械は「同期なし」状態に戻る。インタフェースが「リンクシャットダウンパケット」に遭遇すると、これによりリンクがデータ転送を終了し、図49の状態図の中のcond4、つまりミーティング条件4と呼ばれる、同期するものが何もないので「同期なしフレーム」状態に戻ることも理解可能である。
サブフレーム内のどこか固定されたロケーションに現れる可能性のある一意のワードの「偽のコピー」を繰り返すことができることが理解される。その状況では、サブフレームヘッダパケット上のCRCは、MDDインタフェース処理が「IN SYNC(同期中)」状態に進むために処理されるときにも有効でなければならないため、状態機械がサブフレームに同期する可能性はきわめて低い。
サブフレームヘッダパケット内のサブフレーム長は、リンクがシャットダウンされる前にホストがただ1つのサブフレームを送信し、MDDIが休止ハイバネーション状態に入れられる、又は構成されることを示すためにゼロに設定されてよい。この場合、クライアントはサブフレームヘッダパケットを検出後、ただ1つのサブフレームだけが、リンクがアイドル状態に遷移する前に送信されるため、順方向リンクで直ちにパケットを受信しなければならない。通常の、又は典型的な動作では、サブフレーム長は非ゼロであり、クライアントは、インタフェースが図49に集合的に「IN−SYNC(同期中)」状態として示されているそれらの状態にある間に順方向リンクパケットを処理するに過ぎない。
外部モードクライアントデバイスは、ホストが既に順方向リンクデータシーケンスを送信している間、ホストに属している。この状況では、クライアントはホストに同期しなければならない。クライアントが順方向リンク信号に同期するのに要する時間は、サブフレームサイズと順方向リンクデータレートに応じて可変である。順方向リンク内で無作為な、又はさらに無作為なデータの一部として一意のワードの「偽のコピー」を検出する尤度は、サブフレームサイズがさらに大きいときより大きくなる。同時に、順方向リンクデータレートが低速化すると、偽検出から回復する能力は低くなり、そうするために要する時間は長くなる。
一つ又は複数の実施形態では、低電力モードに移行するために、あるいはリンクを完全にシャットダウンするために順方向リンク送信を停止する前に、MDDI逆方向リンクが安定であることを確証するために、MDDIホストがある追加ステップを実施すべきであることが推奨又は理解される。
起こりうる一つの問題は、ホストが正しくない往復遅延の測定値を用いた場合、順方向リンクが良好に見えるにも関わらず、クライアントから引き続き受信された逆データ送信の全てをだめにすることである。これは、クライアントが順方向リンクと同期していない場合にホストが往復遅延測定パケットの送信を試みた場合、あるいは往復遅延に影響を及ぼす差分ドライバ及び受信機の伝搬遅延における大きな変化をもたらす極端な周囲温度変化によって起こりうる。断続ケーブル又はコネクタ接続欠陥はまた、クライアントに、一時的に同期を失わせ、その後、同期を再取得させる。この間、往復遅延測定パケットの受信を失敗するかもしれない。それに続く逆方向リンクパケットは、ホストによって適切に復元することはできないであろう。
起こりうる別のタイプの問題は、もしもクライアントが一時的に同期を失った場合、クライアントが同期を再取得できる前にホストがリンクシャットダウンパケットを送ることである。ホストは、クライアントがハイバーネーション状態に入ることができない間はハイバーネーションにある。なぜなら、リンクシャットダウンパケットを受信しておらず、リンクがハイバーネーションにあるためにクロックを持っていないからである。
このような問題に打ち勝つために利用可能な技術又は実施形態は、リンクをハイバーネーション状態に入れる前にクライアントが順方向リンクと同期していることをホストに保証させることである。もしもMDDIホストがこれをすることができないか、又は例えば電力喪失時のような機会を持たない場合、あるいは動作中のケーブル、導電体、又はコネクタの分離、破壊、又は断線によってリンクが急に切れた場合には、ホストは先ず、往復遅延測定プロセスを開始するか、又は逆方向リンクカプセル化パケットを送る前に、クライアントが同期していることの保証を試みるべきである。
ホストは、クライアントによって送られたステータスパケットとクライアント要求におけるCRCエラーカウントフィールドを観察し、順方向リンク完全性を判定することができる。このパケットは、クライアントから、ホストによって要求される。しかしながら、大規模なリンク欠陥又は破断の事象では、クライアントは、パケットを適切に復号することができないためにほとんど応答されないであろう。あるいは完全に受信するであろう。逆方向リンクカプセル化パケット内で送られたステータスパケット及びクライアント要求を用いたCRCエラーカウントに対する要求は、第1の完全性チェック、一種の第1の防御ラインとして作用する。更に、ホストは、同期から抜け出たクライアントに関する仮定が、有効であるか否かを確認するために、往復遅延測定パケットを送ることができる。クライアントが往復遅延測定パケットに対して応答しないのであれば、ホストは、このクライアントは、同期から脱し、同期に戻るプロセスを開始することができると結論するであろう。
クライアントが順方向リンクとの同期を間違いなく失ったと一旦ホストが結論すると、ホストは、フィラーパケット以外のあらゆるパケットの送信を試みる前に、次のサブフレームヘッダまで待つ。これは、サブフレームヘッダパケットに含まれる一つのユニークなワードを検出又は見つけるためにクライアントに十分な時間を与えるために行われる。これに続いて、ホストは、クライアントが自己をリセットしたであろうと仮定する。なぜなら、それは、ユニークなワードを正しい場所において見つけていないであろうからである。この点において、ホストは、往復遅延測定パケットを備えたサブフレームヘッダパケットを追う。もしもクライアントが、往復遅延測定パケットに未だに正しく応答しないのであれば、ホストは、再同期プロセスを繰り返す。正しい応答においては、クライアントが、特定されたシーケンスを、往復遅延測定パケットの測定周期でホストに送り返す。このシーケンスが受信されないのであれば、逆方向リンクカプセル化パケット内の逆方向データを受信する試みは失敗するであろう。この特性の連続した失敗は、別の手法で対処されねばならない他のシステムエラーを示し、この点において、リンク同期の一部ではない。
しかしながら、往復遅延測定パケットが成功した後、ホストが未だに、逆方向リンクカプセル化パケットにおいて何の応答も見ないか、破損したデータを見ているのであれば、往復遅延測定パケットを再送信することによって、逆方向データサンプリングが正しいことを確認すべきである。もしも何度も試みても成功しない場合には、一つの実施形態では、逆方向レート逆数値を増加させることによって、逆方向データレートを低減することが推奨される。
ホストは、MDDIリンクをハイバーネーション状態に置く前に、リンク欠陥検出及び恐らくはリンク再同期ステップを実行すべきである。これは、一般に、後にリンクが再起動したときに実行される往復遅延測定パケットが成功したことを保証する。もしもホストがリンク欠陥を疑う理由も、逆方向リンクカプセル化パケットに対する正しい応答も持っておらず、ゼロ順方向リンクCRCエラーがクライアントによって報告されているのであれば、ホストは、全てがそれに従って、あるいは適切(例えば、リンク欠陥が無い)に動作又は機能していると仮定し、パワーダウン/ハイバーネーションプロセスを進める。
ホストが同期のためにテストできる別の方法は、ホストが、往復遅延測定パケットを送り、クライアントからの適切な応答を確認することである。もしも適切な応答がホストによって受信されると、クライアントは、順方向リンクパケットを正しく解釈していると適切に想定することができる。
C.初期化
前述されたように、「起動」時に、ホストは順方向リンクを、1Mbpsという最小の必須、つまり所望されるデータレートで、又は以下で動作するように構成し、、サブフレーム長とメディアフレームレートを既定の応用例のために適宜に構成する。つまり、順方向リンクと逆方向リンクの両方が1型インタフェースを使用して動作を開始する。これらのパラメータは通常、ホストがクライアントディスプレイ(又は他のタイプのクライアントデバイス)のための機能又は所望される構成を決定する間に一時的に使用されることになる。ホストは、ディスプレイ又はクライアントがクライアント機能パケットで応答することを要求するために、要求フラグのビット「0」を一(1)という値に設定させる逆方向リンクカプセル化パケットが後に続く順方向リンク上でサブフレームヘッダパケットを送信又は転送する。いったんディスプレイが順方向リンクで(又は順方向リンクと)同期を獲得すると、クライアント機能パケットとクライアント要求及びステータスパケットを逆方向リンク又はチャネル上で送信する。
ホストは、最適の、又は所望されるレベルの性能のリンクを再構成する方法を決定するために表示機能パケットの内容を調べる。ホストは、ホストとディスプレイが互いに互換性のあるプロトコルのバージョンを使用することを確認するためにプロトコルバージョンフィールドと最小プロトコルバージョンフィールドを調べる。プロトコルバージョンは、通常、他のプロトコルの要素が互換性がない、あるいは互換性があると完全に理解されないときにも互換性を決定できるように表示機能パケットの最初の2つのパラメータとして留まる。
内部モードでは、ホストは、クライアント機能パケットを受信する必要なく、前もってクライアントのパラメータを知ることができる。リンクは、ホストとクライアントとの両方が動作することができるあらゆるデータレートで起動することができる。多くの実施形態では、システム設計者は、データ転送を急ぐために、達成可能な最大データレートでリンクを開始することを最も選択するであろうが、これは、多くの状況では要求されず、使用されないかもしれない。内部モード動作の場合、ハイバーネーションシーケンスからのリンク再起動の間に使用されるストローブパルスの周波数は通常、望まれるレートと一致している。
D.CRC処理
すべてのパケットタイプについて、パケットプロセッサ状態機械は、CRCチェッカが適切に又は正確に制御されることを保証する。それは、また、CRC比較の結果、1つ又は複数のエラーが検出されるとCRCエラーカウンタを増分し、それは処理されている各サブフレームの始まりでCRCカウンタをリセットする。
E.同期チェックの代替損失
前記の一連のステップ又は状態はさらに高いデータレート又はスループット速度を生じさせるが、出願人は、ホストとの同期の損失があることを宣言するためにクライアントが使用する代替配列又は状態の変化は、事実上、なおさらに高いデータレート又はスループットを達成するために使用できることを発見した。新しい発明の実施形態は状態を変更するための状態が変更されているが、同じ基本構造を有する。さらに、新しいカウンタがサブフレーム同期のためにチェックを行うのに役立つために実現されている。これらのステップ及び状態は、方法の動作又は状態機械を確立する上で有効な一連の状態及び条件を示す状態機械図63に関して提示されている。「ACQUIRING−SYNC STATES(同期状態獲得)」部分と「IN−SYNC STATES(同期中状態)」部分だけが明確にするために示されている。加えて、結果として生じる状態は、状態機械自体と同様に、実質的には同じであるため、それらは同じ番号付けを使用する。しかしながら、状態を変更するための条件(及び状態機械の動作)はやや変化し、その結果、相違点を識別する上での都合を考えて2つの図(1、2、3、4、5及び6対61、62、63、64、65)の間で明確にするためにすべてが番号を付け直される。ASYNC FRAME(非同期フレーム)状態はこの説明では考慮されないために、1つの状態(4904)と条件(6)は図中では使用されない。
図63では、図49に示されているような事前に選択された「同期なし」状態4902で、(表示又はプレゼンテーション用の)システム又はクライアントが状態機械5000で開始する。同期なし状態4902から状態を変更するための第1状態変化は、同期パターンの発見である条件64にある。サブフレームヘッダのCRCもこのパケットを順送りにすると仮定すると(条件61を満たす)パケットプロセッサ状態機械の状態は同期中状態4908に変更できる。システムエラー、条件62は、状態機械を状態4910に、第2の発生を状態4912にシフトさせる。しかしながら、MDDIパケットのCRC故障により状態機械は同期状態4908から外れ、1同期エラー状態4910になることが発見された。MDDIパケットの別のCRC故障により、2つの同期故障状態4912に動かされる。正しいCRC値で復号されるパケットにより、状態機械は同期中状態4908に戻る。
変更されたのは、「あらゆる」パケットについてCRC値又は決定を活用することである。つまり、単にサブフレームヘッダパケットを観察する代わりに、同期の損失を決定するために状態機械にパケットごとのCRC値を調べさせるのである。この構成又はプロセスでは、同期の損失は一意のワード及び単にサブフレームヘッダCRC値を使用して決定されない。
新しいインタフェースインプリメンテーションによりMDDインタフェースリンクは、はるかに迅速に同期失敗を認識し、したがってそれらからさらに迅速に回復することもできるようになる。
このシステムをさらにロバストにするために、クライアントはサブフレームカウンタを追加又は活用する必要がある。クライアントは、一意のワードの存在がないか、それが到着又は信号内で発生することが予想されるときにチェックする。一意の野ワードが正しいときに発生しないと、クライアントは、それが複数(ここでは3)のパケット回数又はサブフレーム長を上回る期間待機しなければならなかった場合よりはるかに迅速に同期失敗が発生したことを認識できる。一意のワードのテストがそれが存在しない、言い換えるとタイミングが正しくないことを示すと、クライアントは直ちに同期のリンク損失を宣言し、同期なし状態に移ることができる。正確な一意のワードの存在がないかチェックするプロセスは、一意のワードが正しくないと述べて、状態機械に条件65(cond65)を追加する。サブフレームパケットがクライアントで受信されることを予想され、一致しない場合、クライアントはただちに同期なし状態4902に移動し、通常、状態4910と4912を通って行き来して遭遇される複数の同期エラー(条件62)を待つ追加の時間を省くことができる。
この変化は、サブフレーム長をカウントするためにクライアントコア内で追加のカウンタ又はカウント機能を使用する。一実施形態では、カウントダウン機能が使用され、現在処理されていた任意のパケットの転送が、カウンタが時間切れになった場合にサブフレーム一意のワードがないかチェックするために中断される。代わりに、カウンタは数え上げることができ、カウントは所望される最大の、又は特定の所望される値に比較され、その時点で現在のパケットがチェックされる。このプロセスはクライアントを、異常に長いパケット長でクライアント上、誤って受信されるパケットを復号することから保護する。サブフレーム長カウンタが復号されていた他のなんらかのパケットを中断することを必要とした場合には、パケットはサブフレーム境界を越えてはならないので、同期の損失を決定できる。
IX.パケット処理
状態機械が受信する前述された各種パケットについて、それはインタフェースの動作を実現するために、特定の処理ステップ又は一連のステップに着手する。順方向リンクパケットは、通常、以下の表XIVに一覧表示される例示的な処理に従って処理される。
Figure 2007534232
Figure 2007534232
Figure 2007534232
X.逆方向リンクデータレートの減速
発明者らにより、ホストリンクコントローラのために使用される特定のパラメータが、非常に望ましい最大又はさらに最適化された(スケール)逆方向リンクデータレートを達成するために特殊な方法で調整又は構成できることが観察された。例えば、逆方向リンクカプセル化パケットの逆方向データパケットフィールドを転送するために使用される時間中、MDDI_Stb信号組は、順方向リンクデータレートの半分で周期的なデータクロックを作成するためにトグルする。これは、ホストリンクコントローラが、あたかも全ゼロを送信しているかのようにMDDI_Data0信号に対応するMDDI_Stb信号を生成させるために発生する。MDDI_Stb信号は、クライアントから逆方向リンクデータを転送するためのクロック信号を発生させるためにそれが使用される場合に、ホストからクライアントに転送され、逆方向データはホストに送り返される。MDDIを利用するシステム内の順方向経路と逆方向経路での信号転送及び処理のために遭遇される遅延の典型的な量の図解は図50に示されている。図50では、一連の遅延値、1.5nsec、8.0nsec、2.5nsec、2.0nsec、10nsec、15nsec、8nsec及び25nsecは、それぞれStb+/−生成、表示用のケーブル転送、ディスプレイレシーバ、クロック作成、信号時間記録、Data0+/−生成、ケーブル転送からクライアントへ、及びクライアント受信機段のための処理部分近くに示されている。
順方向リンクデータ及び遭遇する信号処理遅延に応じて、この「往復」効果又はイベントのセットを完了するには、MDDI_Stb信号での1つのサイクルより多くの時間を要する可能性があり、時間又はサイクル望ましくない量の時間又はサイクルの消費につながる。この問題を回避するために、逆方向レート除数が、逆方向リンク上の1ビット時間がMDDI_Stb信号の複数のサイクルに及ぶことが可能になる。つまり、逆方向リンクデータは順方向リンクレート未満である。
インタフェースを通る信号遅延の実際の長さが、それぞれの特定のホスト−クライアントシステム又は使用されているハードウェアに応じて異なる可能性があることが注記されなければならない。必要とされていないが、各システムは通常、逆方向レート除数を最適値に設定できるように、システム内での実際の遅延を測定するために往復遅延測定パケットを使用することによりさらによく機能させることができる。ホストは、より簡単だが低速で動作する基本データサンプリングか、より複雑だが高速な逆方向データレートをサポートする改良型データサンプリングかの何れか一方をサポートする。両方法をサポートするクライアント機能も同様に考慮される。
往復遅延は、ホストに往復遅延測定パケットをクライアントに送信させることにより測定される。クライアントは、測定期間フィールドと呼ばれるそのパケットの中の事前に選択された測定ウィンドウの内部で、あるいはその間に1のシーケンスをホストに送り返すことによってこのパケットに応答する。この測定の詳細なタイミングは前述された。往復遅延は、逆方向リンクデータが安全にサンプリングできる速度を決定するために使用される。
往復遅延測定は、0xff、0xff、0x00応答シーケンスがクライアントからホストで受信し直されると、測定期間フィールドの始まりと時間期間の始まりの間で発生する順方向リンクデータクロック間隔の数を決定すること、検出すること、あるいはカウントすることからなる。クライアントからの応答が、測定カウントが増分しそうになる前に順方向リンククロック期間のほんの少し、受信できることに注記する。この未修正の値が逆方向レート除数を計算するために使用される場合、それは信頼できないデータサンプリングのために逆方向リンクでビットエラーを引き起こすであろう。この状況の一例は、ホストにおけるMDDI_Data、ホストにおけるMDDI_Stb、ホストの内部の順方向リンクデータクロック、及び遅延カウントを表す信号を示し、得られるピクセルをグラフ形式で示された宛先ピクセル位置に書き込む図51で示されている。図51では、応答シーケンスは遅延カウントが6から7に増分する前に順方向リンククロック期間の一部、クライアントから受信された。遅延が6であると見なされる場合には、ホストは逆方向データをビット遷移の直後に、あるいはおそらくビット遷移の途中でサンプリングする。この結果、ホストで誤ったサンプリングが行われるであろう。この理由から、測定遅延は、通常、それが逆方向データ除数を計算するために使用される前に1、増分されなければならない。
逆方向レート除数は、逆方向リンクデータをサンプリングする前に、ホストが待機しなければならないMDDI_Stbサイクルの数である。MDDI_Stbは順方向リンクレートの2分の1である速度で循環されるので、補正往復遅延測定は2で除算されてから次の整数に切り上げられる必要がある。公式として表すと、この関係性は以下のとおりである。
Figure 2007534232
示されている例の場合、これは以下になる。
Figure 2007534232
この例で使用される往復遅延測定が6と対照的に7であった場合、逆方向レート除数も4に等しくなるであろう。
逆方向リンクデータは、逆方向リンククロックの立ち上がりでホストによりサンプリングされる。逆方向リンククロックを作成するにはホストとクライアント(ディスプレイ)の両方に存在するカウンタ又は類似する公知の回路又は装置がある。カウンタは、逆方向リンククロックの第1の立ち上がりが、逆方向リンクカプセル化パケットの逆方向リンクパケットフィールドの第1のビットの始まりで発生するように初期化される。これは、後述の例について図52A及び図52Bに示されている。カウンタはMDDI_Stb信号の各立ち上がで増分し、それらがラップアラウンドするまで発生するカウント数は、逆方向リンクカプセル化パケットの中の逆方向レート除数パラメータにより設定される。MDDI_Stb信号は順方向リンクレートの2分の1でトグルするため、逆方向リンクレートは、逆方向レート除数で除算された順方向リンクレートの2分の1である。例えば、順方向リンクレートが200Mbpsであり、逆方向レート除数が4である場合は、逆方向リンクデータレートは以下のように表される。
Figure 2007534232
逆方向リンクカプセル化パケット内のMDDI_Data0信号線とMDDI_Stb信号線のタイミングを示す例は図52A及び図52Bに示されており、図に使用されているパケットパラメータは以下の値を有する。
パケット長=1024(0x0400) 方向転換1長=1
パケットタイプ=65(0x41) 方向転換2長=1
逆方向リンクフラグ=0 逆方向レート除数=2
パラメータCRC=0xdb43 全ゼロは0x00である
パケット長フィールドとパラメータCRCフィールドの間のパケットデータは以下のとおりである。
0x00、0x04、0x41、0x00、0x02、0x01、0x01、0x43、0xdb、0x00、...
クライアントから返された第1の逆方向リンクパケットは、7というパケット長及び70というパケットタイプを有するクライアント要求及びステータスパケットである。このパケットはバイト値0x07、0x00、0x46、...等で開始する。しかしながら、第1のバイト(0x07)だけが図52A及び図52Bで可視である。この第1の逆方向リンクパケットは、実際の逆方向リンク遅延を示すために、図中、ほぼ1逆方向リンククロック期間時間移動されている。ゼロホスト付きのクライアント往復遅延への理想的な波形は点線トレースとして示されている。
パラメータCRCフィールドのMSバイトは転送され、パケットタイプが先行し、次に全ゼロフィールドが続く。ホストからのストローブは1からゼロに、及びホストからのデータがレベルを変更するにつれて1に切り替わり、さらに幅広いパルスを形成する。データがゼロになると、ストローブはさらに高いレートで切り替わり、データラインでのデータの変化だけが位置合わせフィールドの最後近くで変化を引き起こす。ストローブは長期間、データ信号の固定された0レベル又は1レベルのために図の残りの部分についてさらに高速で切り替わり、パルスパターン(端縁)に立ち下りで遷移する。
ホストの逆方向リンククロックは、クロックが逆方向リンクパケットに対処するために起動される方向転換1期間の最後までゼロである。図の下部の矢印は、開示の残りの部分から明らかとなるようにデータがいつサンプリングされるのかを示している。方向転換1の後に開始した、転送されているパケットフィールドの第1のバイト(ここでは11000000)が示されており、線路レベルはディスエーブルされているホストドライバから安定化している。第1のビットの通過の遅延は、ビット3について見られるように、データ信号のための点線から見られる。
図53では、順方向リンクデータレートに基づいて逆方向レート除数の典型的な値を観察できる。実際の逆方向レート除数は適切な逆方向リンク動作を保証するために往復リンク測定の結果として求められる。第3の領域5306は、適切に機能する可能性が低い設定値を示し、第1の領域5302は、安全な動作の領域に相当し、第2の領域5304は限界性能の領域に相当する。
往復遅延測定及び逆方向レート除数設定値は、それらが送信される又は受信されるビット数よりむしろ実際のクロック期間の単位で表され、動作されるために順方向リンク又は逆方向リンクのどちらかでのインタフェースタイプ設定のどれかで動作している一方で同じである。
一般に、可能な最大の逆方向レート除数は、1型インタフェースを用いた往復遅延測定パケットの測定ウィンドウ内で送ることができるビット数の半分であり、この例では、以下のようになる。
Figure 2007534232
また、改良された逆方向データサンプリング方法は、逆方向ビット時間が、往復遅延よりも小さくなることを可能にする代替例として適用することが可能である。この技術では、ホストは、往復遅延を測定するのみならず、ゼロ遅延のリンクとクライアントとからなる「理想的な」ビット境界に関するクライアントからの応答の位相を決定することができる。クライアントデバイス応答の位相を知ることによって、ホストは、クライアントから逆方向データビットをサンプルするのに比較的安全な時間を決定することができる。この往復遅延測定は、逆方向データパケットフィールドの初めに関して逆方向データの初めのビットの位置をホストに示す。
改良された逆方向データサンプリングの一例の実施形態を、図52Bにグラフィック形式で示す。ゼロ往復遅延の理想的な逆方向データ信号を、点線波形で示す。3.5乃至4.5 MDDI_Stbサイクルの間である実際の往復遅延は、実線波形と理想との間の遅延の相違として示される。これは、往復遅延測定パケットを用いて測定されるものと同じ遅延であり、7順方向リンクビット時間に等しい、測定された往復遅延値となる。この実施形態では、逆方向データビットは、2MDDI_Stbパルス長である。これは4順方向リンクビット時間であり、2に等しい逆方向レート除数に対応する。改良された逆方向データサンプリングの場合、逆方向レート除数は、説明したようにして計算する代わりに、予め選択された2を用いるのが便利である。これは、改良された逆方向データサンプリングのために実質的に最適な選択に見える。なぜなら、理想的なサンプリングポイントは、前述した従来の測定を用いて、容易に決定することができるからである。
逆方向データのための理想的なサンプリングポイントは、往復遅延全体が、逆方向ビット毎の順方向リンククロックの数によって除された余り、すなわち、往復遅延の、逆方向ビット毎の順方向リンククロックによるモジュロを取ることによって容易に計算することができる。そして、1又は2を減じることによりデータ遷移から離れた安全なポイントを得る。この例では、7mod4=3であるので3−1=2、又は3−2=1となる。この安全なサンプリングポイントは、ゼロ往復遅延の場合、「理想的な」ビット境界の端から1又は2の順方向リンクビット時間である。図面は、タイミング図の底部における一連の垂直の矢印によって示すように、理想的なビット境界から2順方向リンクビット時間におけるサンプリングポイントを示している。第一のサンプリングポイントは、測定された往復遅延後の第一の理想的なビット境界に、安全なサンプリングのためのオフセットを加えている。この例では、往復遅延測定値は7であり、次の理想的なビット境界は8番目のビット時間であるので、安全なサンプリングポイントのために1又は2を加える。これによって、最初のビットは、逆方向データパケットフィールドの開始後、9又は10順方向リンクビット時間においてサンプルされるものとする。
XI.方向転換及びガード時間
逆方向リンクカプセル化パケットにおける方向転換1フィールドは、ホストドライバをディスエーブルし、クライアントドライバをイネーブルする時間を同時とする。往復遅延測定パケット内のガード時間1フィールドは、ホストとクライアントとのオーバラップを許すので、クライアントドライバは、ホストインタフェースドライバがディスエーブルされる前にイネーブルすることができる。逆方向リンクカプセル化パケット内の方向転換2フィールドは、ホストドライバがイネーブルされる前に、前のフィールド内のデータが、クライアントから完全に送信されるようにすることができる。ガード時間2フィールドは、クライアントドライバ及びホストドライバが論理ゼロレベルにおいて同時に駆動することを許す時間値又は期間を与える。ガード時間1フィールド及びガード時間2フィールドは、一般に、調整されることを意味しない長さについて予め設定されたか、あるいは予め選択された値で埋められる。使用されているインタフェースハードウェアに依存して、これらの値は、動作を改善するために、経験データを用いて発展されたり、あるいは調整される。
方向転換1
複数の要因が方向転換1の長さの決定に寄与し、これらは順方向リンクデータレート、ホスト内のMDDI_Dataドライバの最大ディスエーブル時間、及び一般にはホストディスエーブル時間と同じであるクライアントドライバのイネーブル時間である。方向転換1フィールドの長さは、24・tBITになるように選択される(表XIII)。方向転換1フィールドの順方向リンクバイト数の長さは、インタフェースタイプ因数を用いて決定され、以下の関係を用いて計算される。
Figure 2007534232
ここではインタフェースタイプ因数は1型の場合1であり、2型の場合2であり、3型の場合4であり、4型の場合8である。
方向転換2
方向転換2に通常使用される時間の長さを決定する要因は、通信リンクの往復遅延、クライアント内のMDDI_Dataドライバの最大ディスエーブル時間、及びクライアントドライバディセーブル時間と同じになるように指定されたホストドライバのイネーブル時間である。ホストドライバイネーブル時間と、クライアントドライバディスエーブル時間との最大は指定されている。往復遅延は、tBITの単位で測定される。方向転換2の順方向リンクバイト数で規定されている最小長さは、以下の関係性に従って計算される。
Figure 2007534232
例えば、10順方向リンククロックという往復遅延のある3型順方向リンクは、通常、以下の規則による方向転換2遅延を使用する。
Figure 2007534232
XII.代替逆方向リンクタイミング
前述されたタイミングと保護周波数帯は高データ転送速度インタフェースを達成するために努力するが、発明者らは、逆方向タイミング発見を変更することにより、往復時間より短い逆方向ビット長を可能にする技法を発見した。
前記に提示されたように、逆方向リンクのタイミングに対する過去の手法は、クロックサイクルの数が逆方向タイミングパケットのガード時間1の最後のビットから、最初のビットがIOクロックの立ち上がりでサンプリングされるまでカウントされるように構成されている。それはMDDIの入力と出力を計時するために使用されるクロック信号(複数の場合がある)である。したがって逆方向レート除数のための計算は以下により示される。
Figure 2007534232
これは非常に信頼できる逆方向リンクを生じさせる往復遅延に等しいビット幅を提供する。しかしながら、逆方向リンクは、発明者らが利用を希望するさらに高速に、つまりさらに高いデータ転送速度で運転できることが示されてきた。新しい本発明の技法はインタフェースの追加の機能をさらに高速に達するために活用することを可能にする。
これは、ホストに、1がサンプリングされるまでクロックサイクル数をカウントさせることによって達成されるが、ホストは逆方向タイミングパケットの間立ち上がりと立ち下りの両方でデータラインをサンプリングする。これによりホストは、ビットが安定していることを確実にするために、逆方向ビットの中のもっとも有効な、あるいは最適でもあるサンプリング点を選ぶことができる。つまり、逆方向トラフィック逆方向カプセル化パケットにとってデータをサンプリングするためのもっとも有効又は最適な立ち上がりを発見することである。最適なサンプリング点は逆方向リンク除数と、第1のものが立ち上がりで検出されたのか、あるいは立ち下りで検出されたのかの両方に依存している。新しいタイミング方法により、ホストは逆方向カプセル化パケットにおいてどこでサンプリングするのかを決定するために、逆方向リンクタイミングのためにクライアントによって送信される0xFF 0xFF 0x00パターンの第1の端縁を単に探すことができるようになる。
到着する逆方向ビット及びそのビットがどのようにして多様な逆方向レート除数を探すのかの例は、ガード時間1の最後のビット以来発生した多くのクロックサイクルと共に、図64に示されている。図64では、最初の端縁が立ち上がりと立ち下りの間で(立ち上がり/立ち下りと名付けられる)発生すると、それが逆方向ビットの期間内で発生する唯一の立ち上がりであるため、1という逆方向レート除数の最適サンプリング点、つまり最適サンプル点は「b」と名付けられているクロックサイクル端縁である。2という逆方向レート除数の場合、サイクル端縁「c」は「b」よりビット端縁により近いので、最適サンプリング点はおそらく依然としてクロックサイクル前縁「b」である。4という逆方向レート除数の場合、最適サンプリング点は、それは、値がおそらく安定化した逆方向ビットのバックエッジにさらに近いので、おそらくクロックサイクル端縁「d」である。
図64に戻ると、しかしながら、第1の端縁が立ち下りと立ち上がり(立ち下り/立ち上がりと名付けられた)の間で発生すると、1という逆方向レート除数の最適サンプリング点は、それは逆方向ビット期間内の唯一の立ち上がりであるため、サンプリング点クロックサイクル端縁「a」である。2という逆方向レート除数の場合、最適サンプリング点は端縁「b」であり、4という逆方向レート除数の場合は最適サンプリング点は端縁「c」である。
逆方向レート除数がどんどん大きくなるにつれて、真ん中にもっとも近いのは立ち上がりでなければならないので、最適サンプリング点も確かめる又は選択するのが容易になる。
ホストは、タイミングパケットデータの立ち上がりデータがデータラインで観察される前に立ち上がりクロックの数を見つけ出すためにこの技法を使用できる。その結果、それは、端縁が立ち上がりと立ち下りの間で発生するのか、あるいは立ち下りと立ち上がりの間で発生するのか、ならびに逆方向レート除数がいくつであるのか、番号カウンタを追加するためにいくつの追加クロックサイクルが加算されるのかに基づいて、ビットがつねに可能な限り真中近くでサンプリングされることを無理なく保証することを決定できる。
いったんホストがクロックサイクル数を選択又は決定すると、それは、特定の逆方向レート除数が働くかどうかを判断するためにクライアントと多様な逆方向レート除数を「検討」できる。ホスト(とクライアント)は1という除数で開始し、この逆方向レートがデータを転送するために適切に機能するかどうかを判断するために、クライアントから受信される逆方向ステータスパケットのRCをチェックできる。CRCが改悪されている場合、おそらくサンプリングエラーがあり、ホストは逆方向レート除数を高め、ステータスパケットの要求を再び試みることができる。第2の要求したパケットが改悪されている場合には、除数を再び増加でき、要求を再び行うことができる。このパケットが正しく復号されている場合、この逆方向レート除数はすべての将来の逆方向パケットについて使用できる。
この方法は、逆方向タイミングが初期の往復タイミング推定値から変化してはならないために効果的且つ有用である。順方向リンクが安定している場合、クライアントは、逆方向リンク障害があったとしても順方向リンクパケットを復号し続けなければならない。いうまでもなく、この方法は完全な逆方向リンクを保証しないため、リンクのための逆方向リンク除数を設定するのはホストの責任である。加えて、除数はIOクロックを作成するために使用されるクロックの質におもに左右される。そのクロックがかなりの量のジッタを有していると、サンプリングエラーの可能性は高くなる。このエラー確率は、往復遅延のクロックサイクル量と共に増加する。
このインプリメンテーションは、1型逆方向データに最善に働くと考えられるが、データライン間の歪みが大きすぎて、ただ1つのデータ組だけ最善に働く速度でリンクを実行できないために、2型から4型の逆方向データでは問題を呈する可能性がある。しかしながら、おそらくデータレートは動作のために2型から4型も用いる前記方法に従って減速される必要はない。この方法は、理想的な、又は最適なクロックサンプルロケーションを選択するために各データラインで重複される場合にも最善に働く可能性がある。それらがデータ組ごとに同じサンプル時間にある場合、この方法は作用し続けるであろう。それらが異なるサンプル期間にある場合には、2つの異なる手法が使用されてよい。第1は、たとえそれが各データ組にとって同じでないにしても、データポイントごとに所望される、あるいはさらに最適化されたサンプルロケーションを選択することである。次にホストはデータ組の集合からビットのすべてをサンプリングした後にデータストリームを再構築できる。つまり、2型に2ビット、3型に4ビット、及びIV型に8ビットである。他方のオプションは、データ組ごとのデータビットを同じクロック端縁でサンプリングできるように、ホストが逆方向レート除数を増加させることである。
XIII.リンク遅延及び歪みの影響
MDDI_Data組とMDDI_Stbの間の順方向リンクでの遅延歪みは、遅延歪み補償が使用されない限り、考えられる最大データレートを制限できる。タイミング歪みを引き起こす遅延の差異は、コントローラ論理回路、ラインドライバとレシーバ、及び以下に概略されるようなケーブルとコネクタに起因している。
A.歪みによって制限されるリンクタイミング分析(MDDI1型)
1.1型リンクの遅延及び歪みの例
図41に示されているインタフェース回路に類似した典型的なインタフェース回路は、1型インタフェースリンクに対処するために図57に示されている。図57では、伝搬遅延と歪みの例示的な又は典型的な値は、MDDI1型順方向リンクの複数の処理又はインタフェース段のそれぞれに示される。MDDI_StbとMDDI_Data0の間の遅延の歪みは、出力クロックのデューティサイクルを変形させる。フリップフロップ5728、5732を使用する受信機フリップフロップ(RXFF)段階のD入力でのデータは、それが確実にサンプリングできるようにクロック端縁後にわずかに変化する。図は、このタイミング関係を生じさせることにまつわる2つの異なる問題点を解決するために使用されている2つのカスケード式遅延線路5732aと5732bを示している。実際のインプリメンテーションでは、これらは単一の遅延要素に結合されてよい。
インタフェースを通した例示的な信号処理のための1型リンク上でのデータ、Stb(ストローブ)及びクロック回復タイミングは、図58に示されている。
著しい総遅延歪みは通常、以下の段階の歪みの合計から発生する又は生じる。つまりフリップフロップ5704、5706付きの送信機フリップフロップ(TXFF)、ドライバ5708、5710付きの送信機ドライバ(TXDRVR)、ケーブル5702、受信機5722、5724付きの受信機ラインレシーバ(RXRCVR)、及び受信機XOR論理回路(RXXOR)である。遅延1 5732aは、以下の関係性によって決定されるRXXOR段階でのXORゲート5736の遅延に一致、又は超えなければならない。
Figure 2007534232
受信機フリップフロップ5728、5732のD入力が、そのクロック入力の前に変化しないようにこの要件を満たすことが望ましい。これはRXFFの保持時間がゼロである場合に有効である。
遅延2の目的又は機能は、以下の関係性に従ってRXFFフリップフロップの保持時間を補償することである。
Figure 2007534232
多くのシステムでは、保持時間がゼロであるため、これはゼロとなり、いうまでもなくその場合遅延2の最大遅延もゼロとなる場合がある。
受信機XOR段階での最悪のケースの歪みへの貢献は、遅延1が最大値であり、XORゲートからのクロック出力が以下の関係性に従って可能な限り早期に起こるデータ−遅れ/ストローブ−早期ケースにある。
Figure 2007534232
この状況では、データは、ビットn+1が受信機フリップフロップの中に記録される時間に非常に近い2ビット期間、nとn+1の間で変化する可能性がある。
MDDI 1型リンクの最大データレート(最小ビット期間)は、RXFF段階に合計データセットアップを加えたMDDIリンク内のすべてのドライバ、ケーブル、及び受信機を通して遭遇される最大歪みの関数である。RXRCVR段階の出力までのリンクの総遅延歪みは以下のように表現でき、
Figure 2007534232
ここで、「ケーブル」は、種々の導電体又は相互接続又は有線と、対応する遅延を表し、最小ビット期間は、
Figure 2007534232
によって指定される。
図57に示される例では、外部モードの場合、tSKEW−max(LINK)=100psecであり、最小ビット期間は以下のように表現できる。
BIT−min=1000+2.125+625+125+200+0+100=2300psec、つまり約434Mbpsとして述べられる。図57に示される例では、内部モードの場合、tSKEW−max(LINK)=500psecであり、最小ビット期間は以下のように表現できる。
BIT−min=500+2.125+625+125+200+0+100=1800psec、つまり約555Mbpsとして述べられる。
B.MDDI2型、3型及び4型のリンクタイミング分析
図41と図57に示されるインタフェース回路に類似する典型的なインタフェース回路は、2型、III型、IV型インタフェースリンクに対処するために図59に示されている。追加の要素は、追加の信号処理に対処するためにTXFF(5904)、TXDRVR(5908)、RXRCVCR(5922)及びRXFF(5932、5928、5930)段で使用される。図59では、伝搬遅延と歪みの例示的な又は典型的な値が、MDDI2型順方向リンクの複数の処理段階又はインタフェース段階のそれぞれに示されている。出力クロックのデューティサイクルに影響を及ぼすMDDI_StbとMDDI_Data0の間の遅延での歪みに加えて、これらの2つの信号と他のMDDIデータ信号の両方の間にも歪みがある。フリップフロップ5928と5930からなる受信機フリップフロップB(RXFFB)段のD入力でのデータは、それが確実にサンプリングできるようにクロック端縁の後わずかに変更される。MDDI_Data1がMDDI_Stb又はMDDI_Data0より早く到着すると、MDDI_Data1は少なくとも遅延歪みの量、サンプリングされるのを遅らされなければならない。これを達成するためには、データは遅延3遅延線路を使用して遅延されている。MDDI_Data1がMDDI_StbとMDDI_Data0より後に到着し、それが遅延3分遅延する場合には、MDDI_Data1が変化する点が次のクロック端縁のより近くに移動する。このプロセスがMDDI2型、3型又は4型リンクのデータレートの上限を決定する。2つのデータ信号とMDDI_Stbの互いに関するタイミング又は歪み関係性に対するいくつかの例示的な異なる可能性は、図60A、図60B及び図60Cに示されている。
MDDI_DataXが可能な限り早期に到着するときにRXFFBで確実にデータをサンプリングするために、遅延3は以下に従って設定されている。
Figure 2007534232
最大リンク速度は、最小許容ビット期間により決定される。これは、MDDI_DataXが可能な限り遅れて到着すると最も影響を受ける。その場合、最小許容サイクル時間は以下によって示される。
Figure 2007534232
したがって、リンク速度の上限は
Figure 2007534232
であり、以下を考えれば
Figure 2007534232
前記に示される例では、最小ビット期間の下限は以下の関係性により示される。
Figure 2007534232
つまり約174Mbpsである。
これは、1型リンクと共に使用できる最大データレートよりはるかに遅い。MDDIの自動遅延歪み補償機能は、遅延歪みが、有効なデータ設定をしようとしている最大リンクレートファクタに対して及ぼす影響を大幅に削減する。MDDI_Data0とMDDI_Stbとの間で校正された歪みは、
Figure 2007534232
であり、最小ビット期間は、
Figure 2007534232
である。
ここで、“TB”すなわちtは、ビット境界から最小出力レベルへの信号ジターを表す。非対称は、単に、差分受信機を通った、又は差分受信機の内部遅延の非対称な性質を称している。“TP4”は、電気特性に関連付けられ、差分ラインドライバのための接続又はインタフェース(クライアントにおけるMDDIコントローラデバイスのピン)、及びクライアントのための受信機としての目的を試験するために効率的に定義されている。それは、便利な、又は予め定めたポイントを表す。ここから信号遅延が測定され、システムの残りにわたったリンクのために特徴付けられる。一つの実施形態では、TP4におけるパラメータtの最大値は、外部モードについて、
Figure 2007534232
であり、クライアント送信機の内部モードについて、
Figure 2007534232
であり、クライアント受信機の外部モードについて、
Figure 2007534232
である。
ラベルTP4は、種々の試験ポイント(TP)をナンバリングするのに簡単であり役立ち、インタフェース及びリンクである。一つの実施形態では、この試験ポイントは、内部モードと外部モードとの両方に同じになるように定義される。差分ラインドライバ及び受信機を含むホスト内のMDDIコントローラデバイスの接続又はインタフェースピンのための、又は関連した対応する“TP0”が存在する。この実施形態では、TP0におけるパラメータTの最大値は、内部モードの場合、
Figure 2007534232
ホスト受信機の外部モードの場合、
Figure 2007534232
ホスト送信機の場合、
Figure 2007534232
の関係によって定義される。
図59に示す例では、
Figure 2007534232
であり、最小ビット期間は、
Figure 2007534232
であり、約606Mbpsである。
MDDI_Data1が到着したとき、可能な限り早くRXFFB内のデータを高い信頼性でサンプルするために、関連するプログラム可能な遅延が、一つのタップの精度を用いて最適な設定に調整され、追加のタップ遅延が安全のために追加される。最大リンク速度は、最小許容ビット期間によって決定される。これは、MDDI_Data1が可能な限り遅れて到着した場合に最も影響を受ける。この場合、最小許容サイクル時間は、
Figure 2007534232
となる。ここで、“TA”すなわちtは、ビット境界から中心交点への信号ジターを表す。
図59に示す例では、サンプリングMDDI_Data1に基づく最小ビット期間の下部境界は、
Figure 2007534232
である。
一つの実施形態では、内部モードのホストにおけるクロックジター、遅延非対称、及び遅延歪みのための典型的な合計遅延時間は、
Figure 2007534232
のように定義され、外部モードの場合、
Figure 2007534232
のように定義される。
一方、内部モードにおけるクライアントデバイス内の設定時間(tB−TP4)、遅延非対称、及び遅延歪みのための典型的な合計遅延時間は、
Figure 2007534232
であり、外部モードの場合は、
Figure 2007534232
である。ここで、項TBDは、外部モード接続に必要な良く知られた様々な特徴及び動作要求に依存した値に定められる将来のためのラベルを保持したフレキシブルな場所である。
XIV.物理層相互接続説明
本発明に従ってインタフェースを実現するために有効な物理接続は、ホスト側でヒロセ電機株式会社(Hirose Electric Company Ltd.)により製造されるパーツ番号3260−8S2(01)、クライアントデバイス側でヒロセ電機株式会社(Hirose Electric Company Ltd.)により製造されるパーツ番号3240−8P−C等の市販されているパーツを使用して実現できる。1型/2型インタフェースと共に使用されるこのようなコネクタ向けの例示的なインタフェースピン割り当て、つまり「ピン配列」は、表XVに一覧表示され、図61に図解されている。
Figure 2007534232
シールドは、ホストインタフェース内のHOST_Gndに接続され、ケーブルの中のシールドドレイン線はクライアントコネクタのシールドに接続されている。ただし、シールドとドレイン線はクライアントの内部の回路接地には接続されていない。
相互接続要素又は素子は、相対的な装置サイズに比べて邪魔にならず、悪趣味にならずにPDA及び無線電話、あるいは携帯ゲーム機等の移動体通信装置及び計算装置と使用するほど十分小型であるために選ばれる、あるいは設計されている。あらゆるコネクタ及びケーブル布線は、典型的な消費者環境で使用するのに十分なほど耐久性があり、特にケーブル布線のために小型に対処し、相対的に低コストでなければならない。転送要素は、1型と2型の場合、最高450Mbps、8ビット並列4型バージョンの場合最高3.6Gbpsの転送率を有する差動NRZデータであるデータ信号とストローブ信号に対処する必要がある。
内部モードの応用例の場合、使用されている導線に対して同じ向きのコネクタはないか、あるいはこのような接続要素は非常に小型化する傾向があるかのどちらかである。1つの例は、集積回路又はホスト又はクライアントデバイスのどちらかを収容している素子を受け入れるためのゼロ挿入力の「ソケット」である。別の例はホストとクライアントが多様な相互接続導線と共にプリント基板上で常駐し、集積回路の相互接続のために導線上での接点にはんだ付けされているハウジングから伸びる「ピン」又は「接点」を有する場合である。
XV.動作
本発明の実施形態を使用するインタフェースの動作中にデータとパケットを処理する上で講じられる一般的なステップのまとめは、図55のパケットを処理するインタフェース装置の概要と共に、図54Aと図54Bに示されている。これらの図中、プロセスは、クライアント及びホストが通信経路、ここではケーブルを使用して接続されているかどうかに関する決定を行うステップ5402で開始する。これは、(USBインタフェースについて見られているように)ホストへの入力でコネクタ又はケーブル又は信号の存在を検出するソフトウェア又はハードウェアを使用する、ホストによる周期的なポーリングを使用することによって、あるいは他の公知の技法で発生する場合がある。ホストに接続されているクライアントがない場合には、それは、応用例に応じて単に所定の長さの待機状態に入る、ハイバネーションモードに入る、あるいはユーザにホストを再アクティブ化するための処置を講じることを要求する可能性のある将来の使用に待機するために非活性化される場合がある。例えば、ホストがコンピュータタイプの装置に常駐するとき、ユーザは画面アイコンをクリックする、あるいはクライアントを探すためにホスト処理をアクティブ化するプログラムを要求しなければならない可能性がある。再び、ホスト又は常駐ホストソフトウェアの機能と構成に応じてUSB型接続の簡略なプラグインにより、ホスト処理をアクティブ化できるであろう。
いったんクライアントがホストに接続される、あるいはその逆の場合、又は存在しているとして検出される場合、クライアント又はホストのどちらかがステップ5404と5406でサービスを要求する適切なパケットを送信する。クライアントはステップ5404でクライアントサービス要求パケット又はステータスパケットのどちらかを送信できるであろう。前述されたように、リンクは、これが続く通信リンクの完全な初期化ではないように、過去にシャットダウンできた、あるいはハイバネーションモードであったことが注記される。いったん通信リンクが同期され、ホストがクライアントと通信しようとすると、クライアントはステップ5408でのように、ホストへクライアント機能パケットも提供する。ホストは、ここでクライアントが対処できる転送速度を含むサポートのタイプの決定を開始できる。
一般的には、ホストとクライアントは、ステップ5410で例えば1型、2方等の使用されるサービスモードのタイプ(速度/速度)も交渉する。いったんサービスタイプが確立されると、ホストは情報の転送を開始できる。加えて、ホストは、ステップ5411に図示されるように他の信号処理と並列に通信リンクのタイミングを最適化するために往復遅延測定パケットを使用してよい。
前述されたように、すべての転送は、データのタイプ、ここではビデオ及び音声ストリームパケット、及びステップ5414で転送されているのが示されるフィラーパケットが後に続く、ステップ5412で転送されているのが示されるサブフレームヘッダパケットで開始する。音声データとビデオデータは過去に作成された又はパケットの中にマッピングされ、フィラーパケットはメディアフレーム用の必要数のビットを記入するために必要に応じて、又は所望されるように挿入される。ホストは、サウンドデバイスをアクティブ化するために順方向音声チャネルイネーブルパケット等のパケットを送信できる。加えて、ホストは前述された他のパケットタイプ、ここではカラーマップの転送、ビットブロック転送、又はステップ5416の他のパケットを使用してコマンド及び情報を転送できる。さらに、ホストとクライアントは適切なパケットを使用してキーボード又はポインティングデバイスに関連するデータを交換できる。
動作中、インタフェースモードの別のデータレート又はタイプを所望するホスト又はクライアントにつながる複数の異なるイベントの1つが発生することがある。例えば、コンピュータ又はデータを通信する他の装置は、パケットの作成又はプレゼンテーションにおいて低速化を引き起こすデータを処理する際の荷重条件に遭遇するであろう。データを受信するクライアントデバイスは専用AC電源からさらに制限された電池電源に変更し、データを迅速に転送できない、容易にコマンドを処理できない、あるいはより限られた電力設定の元で同程度の解像度又はカラー階調を使用できないであろう。代わりに、制限条件は排除される、あるいは姿を消し、装置がさらに高速でデータを転送できるようにする。これはより望ましく、さらに高速の転送速度モードへの変更を要求できる。
これらのあるいは他の種類の公知の条件が発生する、あるいは変化する場合、ホスト又はクライアントのどちらかはそれらを検出し、インタフェースモードを再交渉しようとしてよい。これは、ホストが、別のモードへのハンドオフを必要とするクライアントにインタフェースタイプハンドオフ要求パケットを送信するステップ5420で示され、クライアントは変更が求められることを確認するインタフェースタイプ肯定応答パケットを送信し、ホストは、指定されたモードに変更するために実行型ハンドオフパケットを送信する。
このような要素はホスト側に存在してもよいが、処理の特定の順序を要求していないが、クライアントとホストはポインティングデバイス、キーボード、又はおもにクライアントと関連付けられる他のユーザ型入力装置向けの、あるいはそれらから受信されたデータに関連するパケットも交換できる。これらのパケットは、通常、状態機械(5502)ではなく、汎用プロセッサタイプの素子を使用して処理される。加えて、前述されたコマンドのいくつかは汎用プロセッサ(5504、5508)によっても処理されるであろう。
データとコマンドがホストとクライアントの間で交換された後で、なんらかの点で、追加データが転送されるべきかどうか、あるいはホスト又はクライアントが転送にサービスを提供するのをやめるかどうかに関して決定が下される。これはステップ5422に示されている。リンクがハイバネーション状態に入る、又は完全にシャットダウンされるのどちらかである場合、ホストはクライアントにリンクシャットダウンパケットを送信し、両方の側がデータの転送を終了する。
前記動作処理で転送されているパケットは、ホストコントローラとクライアントコントローラに関連して前述されたドライバと受信機を使用して転送される。これらのラインドライバ及び他の論理素子は図55の概要に示されているように、前述された状態機械と汎用プロセッサに接続されている。図55では、状態機械5502及び汎用プロセッサ5504と5508がさらに、専用のUSBインタフェース、メモリ素子、又はビュー表示装置用のデータソースとビデオ制御チップを含むがこれらに限定されない、それらが対話するリンクコントローラの外部に常駐する他の構成部品等の図示されていない他の要素に接続されてよい。
プロセッサ及び状態機械は、通信リンクの効率的な確立又は終端、及びパケットの転送を保証するために、ガード時間に関して関連して前述されたようなドライバのイネーブルとディスエーブルに制御を提供する。
XVI.ディスプレイフレームバッファ
ビデオデータバッファリング要件はコンピュータグラフィックと比較して、動画ビデオ画像について異なっている。ピクセルデータは、クライアント上の画像を局所的にリフレッシュできるように、ほとんどの場合クライアント内のローカルフレームバッファに記憶される。
フルモーションビデオが表示されている(ディスプレイ内のほぼすべてのピクセルが各メディアフレームを変更する)とき、ディスプレイ上の画像は第2のフレームバッファからリフレッシュされているが、通常、1つのフレームバッファの中に入信ピクセルデータを記憶することが好ましい。3つ以上のディスプレイバッファは後述されるように可視アーチファクトを排除するために使用されてよい。画像全体が1つのフレームバッファ内に受け入れられると、バッファの役割は交換でき、新規に受信された画像は次にディスプレイをリフレッシュするために使用され、他のバッファは画像の次のフレームで充填される。この概念は、ピクセルデータが、表示更新ビットを「01」に設定することによりオフライン画像バッファに書き込まれる図88Aに示されている。
他の応用例では、ホストは画像全体を塗り直す必要なく、画像の小さな部分だけを更新する必要がある。この状況では、図88Bに詳細に示されるように、新しいピクセルを、表示をリフレッシュするために使用されているバッファに直接的に書き込むことが望まれる。
小型ビデオウィンドウ付きの固定画像を有する応用例では、図88Cに示されるように両方のバッファ(「11」に等しい表示更新ビット)に固定された画像を書き込み、後に表示更新ビットを「01」に設定することによりオフラインバッファに動画のピクセルを書き込むことが最も容易である。
以下の規則は、同時に新しい情報をクライアントに書き込み、表示をリフレッシュしながら、バッファポインタの有効な操作を記述している。3つのバッファポインタが存在する。つまり、current_fillは、MDDIリンク上でデータから現在充填されているバッファを指す。just_filledは、最も最近充填されたバッファを指す。being_displayedは表示をリフレッシュするために現在使用されているバッファを指す。すべての3つのバッファポインタは0からN−1の値を含んでよく、Nはディスプレイバッファの数であり、N≧2である。バッファポインタ上の演算はNを係数としている。例えばN=3及びcurrent_fill=2のとき、current_fillを増分すると、current_fillは0に設定される。N=2である単純な場合には、just_filledはつねにcurrent_fillの補数である。あらゆるMDDIメディアフレーム境界(サブフレームカウントフィールドがゼロに等しいサブフレームヘッダパケット)で、指定された順序で以下の演算を実行する。just_filledをcurrent_fillに等しく設定し、current_fillをcurrent_fill+1に設定する。
MDDIビデオストリームパケットは、以下の構造又は方法論に従ってバッファ更新する。つまり表示更新ビットが「01」に等しいとき、ピクセルデータはcurrent_fillによって指定されるバッファに書き込まれる。表示更新ビットが「00」に等しいとき、ピクセルデータはjust_filledによって指定されるバッファに書き込まれる。及び、表示更新ビットが「11」に等しいときには、ピクセルデータはすべてのバッファに書き込まれる。表示はbeing_displayedポインタによって指定されるバッファからリフレッシュされる。表示が1つのフレームリフレッシュエポックの最後のピクセルをリフレッシュした後、及びそれが次のフレームリフレッシュエポックの中の最初のピクセルのリフレッシュを開始する前に、表示更新プロセスはbeing_refreshedをjust_filledに等しく設定する動作を実行する。
ピクセルデータ属性フィールドを備えたパケットは、ピクセルデータが書き込まれるフレームバッファを指定する1組の表示更新ビットを含む。クライアント機能パケットは、表示更新ビットのどの組み合わせがクライアントでサポートされるのかを示す3つの追加ビットを有する。多くの場合、コンピュータにより作成される画像はユーザ入力に基づいて増分的に更新される、あるいはコンピュータネットワークから受信される情報から引き出される必要がある。表示更新ビット組み合わせ「00」と「11」は、ピクセルデータを、表示されているフレームバッファに、あるいは両方のフレームバッファに書き込ませることによってこの運転モードをサポートする。
ビデオ画像に対処するとき、図89は、ビデオデータが、表示更新ビットが「01」に等しい状態でMDDIリンク上で送信されるときに1組のフレームバッファを使用してどのようにしてビデオ画像が表示されるのかを示す。メディアフレーム境界がMDDIリンクで検出されると、表示リフレッシュプロセスは、現在リフレッシュされているフレームのリフレッシュプロセスが完了すると次のフレームバッファからのリフレッシュを開始する。
図89に関連する重要な仮定は、画像が、クライアントが表示をリフレッシュするためにフレームバッファからピクセルを読み取るのに使用するのと同じ順序で(通常、左上、行ごとに読み取り、画面の右下角へ)送信されるピクセルの連続ストリームとしてホストから受信されるという点である。これは、表示リフレッシュ動作と画像転送動作が同じフレームバッファを参照している場合に重要な詳細である。
部分的な画像を表示するのを回避するために、表示リフレッシュフレームレートが画像転送フレームレートを上回ることが必要である。図90は、どのようにしてゆっくりとした表示リフレッシュ速度で画像フラグメンテーションが発生できるのか、つまりどのようにして表示リフレッシュが画像転送より低速なのかを示す。
コンピュータグラフィックス画像と動画ビデオ画像の組み合わせを含む画像では、ビデオピクセルデータはメディアフレームの小さい部分を含んでいる可能性がある。これは、表示リフレッシュ動作と画像転送が同じフレームバッファを参照する状況では重要になるであろう。これらの状況は、表示をリフレッシュするためにバッファから読み取られたピクセルが2コマ前のバッファに書き込まれたピクセルである可能性がある、あるいはそれらが同じフレームバッファに直ちに書き込まれているフレームに一致する可能性がある、図91で斜行平行線の陰影により示されている。
3つのフレームバッファをクライアントで使用すると、図92に示されているようなフレームバッファへのアクセスの競合のある小さなウィンドウの問題が解決される。
ただし、図93に示されているように、表示リフレッシュレートがMDDIリンク上のメディアフレームレート未満である場合には依然として問題がある。
図94に示されるように、単一バッファを動画ビデオ画像に使用することはやや問題がある。バッファへの画像転送より高速の表示リフレッシュの場合、リフレッシュされている画像が書き込まれているフレームの上部を示し、画像の下部は過去に転送されたフレームとなる。画像転送より高速の表示リフレッシュ(好ましい運転モード)の場合、類似する分割された画像を示すフレームの例がより頻繁になるであろう。
XVII.マルチプルクライアントサポート
現在のプロトコルバージョンは、複数のクライアントデバイスを直接的にサポートしているように考えられない。しかしながら、大部分のパケットは、複数のクライアントがいるシステム内で特定のクライアントデバイスをアドレス指定するために使用できる予約クライアントIDフィールドを含んでいる。現在、多くの応用例の場合、このクライアントID又はこれらのクライアントIDはゼロに設定される。サブフレームヘッダパケットもホストが複数のクライアントシステムをサポートするか否かを示すためのフィールドを含む。したがって、複数のクライアントデバイスが、複数のクライアントホスト又はクライアントとの将来の互換性のためにシステム設計者が計画するのを支援するためにMDDインタフェース又はプロトコルの将来の応用例で接続され、アドレス指定される可能性がある様式がある。
複数のクライアントを有するシステムでは、図95に示されるように、クライアントのデイジーチェーンを使用して、又はハブを使用して、あるいは図96に示されるようにこれらの技法の組み合わせを使用してクライアントがホストに接続されるのが有用である。また、例えば、アドレス0を要求する一人又は複数のクライアントが接続された場合のエラーメッセージのように、ホストが、あるエラーメッセージを表示して、接続されたクライアントを管理することは役に立つかもしれない。なお、この例は、ディスプレイが、唯一のクライアントとして動作するように期待あるいは設定されているようなマルチクライアントシステムの場合には当てはまらない。
VXIII.補遺
本発明の実施形態のためのアーキテクチャ及びプロトコルを実現するために使用される多様なパケットについて前述されたフォーマット、構造、及びコンテンツに加えて、さらに詳しいフィールドコンテンツ又は動作がここではパケットタイプのいくつかのために提示されている。これらは、ここで当業者が種々の応用例のために本発明をさらに容易に理解し、利用できるようにするために、そのそれぞれの使用又は動作をさらに明確にするためにここで提示されている。すでに説明されていないフィールドの内の数個しかここではさらに説明されない。さらに、これらのフィールドには、前記に提示された実施形態に関連した例示的な定義及び値が提示される。
しかしながら、このような値は本発明の制限として解釈されるべきではなく、インタフェースとプロトコルを実現するために有効な1つ又は複数の実施形態を表し、すべての実施形態がいっしょに又は同時に実践される必要はない。他の値は、当業者により理解されるように、データ又はデータレート転送結果の所望されるプレゼンテーションを達成するために、他の実施形態で使用できる。
A.ビデオストリームパケットの場合
一実施形態では、ピクセルデータ属性フィールド(2バイト)は、以下のように解釈される一連のビット値を有する。ビット1と0は、どのようにして表示ピクセルデータが送られるのかを選択する。「11」というビット値の場合、ピクセルデータは両目に、又は両目用に展示され、ビット値「10」の場合、ピクセルデータは左目だけに送られ、ビット値「01」の場合、ピクセルデータは右目だけに送られ「00」というビット値の場合、データは後述されるようなビット8から11によって指定されるように代替ディスプレイに送られる。クライアント内、又はクライアントによって操作されているか、又は使用されている主ディスプレイが、ステレオ画像又はある形式の画像をサポートしていないのであれば、コマンドは、ディスプレイによって望まれるようなインパクトを持つように効果的に埋め込むことはできない。この状態又は設定では、クライアントは、ビット値、すなわち、‘01’、‘10’、‘11’のいかなるビット組み合わせにも関わらず、ピクセルデータを主ディスプレイに経路付けるべきである。なぜなら、結果として得られるコマンド又は制御は、このディスプレイによって実行されないからである。本実施形態では要求されないが、ステレオディスプレイ機能をサポートしないこれらクライアントにおける主ディスプレイに対処するために値‘11’が使用されることが推奨される。
ビット2は、「0」という値がピクセルデータが標準漸次フォーマットであることを意味し、行番号(ピクセルY座標)が、ある行から次の行に進むときに1増分されることを意味する、ピクセルデータがインタレースフォーマットで提示されるかどうかを示す。ビットに「1」という値があるとき、ピクセルデータはインタレースフォーマットであり、行番号は、ある行から次の行に進むときに2で増分される。ビット3は、ピクセルデータが代替ピクセルフォーマットを取ることを示す。これはビット2でイネーブルされる標準インタレースモードに類似しているが、インタレースは水平の代わりに垂直である。ビット3が「0」であるとき、ピクセルデータは標準漸次フォーマットであり、列番号(ピクセルX座標)が、各連続ピクセルが受信されると1増分される。ビット3が「1」であるとき、ピクセルデータは代替ピクセルフォーマットを取り、列番号は書くピクセルが受信されると2増分される。
データは、無線電話又は類似した装置又はポータブルコンピュータ又は前述されたようなこのような他の装置用の内部ディスプレイに、又は内部ディスプレイから転送される、あるいはデータは装置に内蔵される、又は直接的に結合されるカメラに、又はカメラから転送されているので、ビット4は、ピクセルデータがディスプレイに関連するのか、あるいはカメラに関連するのかを示す。ビット4が「0」であるとき、ピクセルデータはディスプレイフレームバッファへ、又はディスプレイフレームバッファから転送されている。ビット4が「1」であるとき、ピクセルデータは何らかのタイプのカメラ又はビデオ装置へ、又はそれから転送されており、このような装置は技術で周知である。
ビット5は、ピクセルデータがいつディスプレイ内のピクセルの次の連続行を含むのかを示すために使用される。これは、ビット5が「1」に等しく設定されるケースと見なされる。ビット5が「1」に設定されるときには、X左端縁、Y上部端縁、X右端縁、Y下部端縁、X開始、Y開始パラメータが定義されず、クライアントによって無視される。ビット15が論理1レベルに設定されると、これは、このパケットの中のピクセルデータが画像の中のピクセルの最後の行であることを示す。クライアント機能パケットのクライアント特徴機能インジケータフィールドのビット8は、この特徴がサポートされているかどうかを示す。
ビット7と6は、ピクセルデータが書き込まれなければならないフレームバッファを指定する表示更新ビットである。さらに具体的な効果は他の場所で説明される。「01」というビット値の場合、ピクセルデータはオフライン画像バッファに書き込まれる。「00」というビット値の場合、ピクセルデータは、表示をリフレッシュするために使用される画像バッファに書き込まれる。「11」というビット値の場合、ピクセルデータはすべての画像バッファに書き込まれる。「10」というビット値又は組み合わせは無効値又は指定として処理され、ピクセルデータは無視され、画像バッファのどれにも書き込まれない。この値はインタフェースの将来の応用例のために使用される可能性がある。
ビット8から11は、代替ディスプレイ又はピクセルデータが送られるディスプレイロケーションを指定する4ビットの符号なし整数を形成する。ビット0と1は、ディスプレイクライアントが代替ディスプレイ番号としてビット8から11を解釈するために「00」に等しく設定される。ビット0と1が「00」に等しくない場合には、ビット8から11は論理ゼロレベルに設定される。
ビット12から14は、将来の使用のために予約され、通常論理ゼロレベルに設定されている。ビット15は、前述されたように、ビット5と共に使用される。ビット15を論理1に設定すると、ピクセルデータフィールドの中のピクセル行がデータのフレームの最後の行であることが示される。ビット5が論理1に設定される次のビデオストリームパケットは、次のビデオフレームのピクセルの第1の行に相当する。
2バイトのX開始フィールドとY開始フィールドは、ピクセルデータフィールドの第1のピクセルの点(X開始、Y開始)の絶対X座標と絶対Y座標を指定する。X右端縁フィールドとY下部端縁フィールドは更新されているウィンドウの右端縁のX座標と下部端縁のY座表を指定するが、2バイトのX左端縁フィールドとY上部端縁フィールドは、ピクセルデータフィールドによって充填される画面ウィンドウの左端縁のX座標と上部端縁のY座標、上部端縁のY座標を指定する。
ピクセルカウントフィールド(2バイト)は、以下のピクセルデータフィールドの中のピクセル数を指定する。
パラメータCRCフィールド(2バイト)は、パケット長からピクセルカウントまでのすべてのバイトのCRCを含む。このCRCがチェックできない場合、パケット全体が廃棄される。
ピクセルデータフィールドは、表示されなければならず、ビデオデータフォーマット記述子フィールドによって記述されるようにフォーマットされる未処理ビデオ情報を含む。データは他の箇所に説明されるように一度に一「行」送信される。ピクセルデータ属性フィールドのビット5が、論理レベル1に設定されたとき、このピクセルデータフィールドは、正確に一行のピクセルを含む。ここで、最初のピクセルは、最も左側のピクセルに従って送信され、最後のピクセルは、最も右側のピクセルに従って送信される。
ピクセルデータCRCフィールド(2バイト)は、ピクセルデータだけの16ビットCRCをる含む。この値のCRC検証が失敗すると、ピクセルデータは依然として使用できるが、CRCエラーカウントが増分される。
B.音声ストリームパケットの場合
一実施形態では、音声チャネルIDフィールド(1バイト)が、音声データがクライアントデバイスによって送信される特定の音声チャネルを識別するために8ビットの符号なし整数値を使用する。物理音声チャネルは、それぞれ左前チャネル、右前チャネル、左後チャネル、右後チャネル、前中央チャネル、サブウーファーチャネル、サラウンド左チャネル及びサラウンド右チャネルを示す、0、1、2、3、4、5、6又は7という値としてこのフィールドによって物理チャネルに指定される、あるいは物理チャネルにマッピングされる。254という音声チャネルID値は、デジタル音声サンプルの単一のストリームが左前チャネルと右前チャネルの両方に送信されることを示す。これにより、音声通信にステレオヘッドセットが使用される、生産性強化応用例がPDAで使用される、あるいは単純なユーザインタフェースが警告音を生成する他の応用例のために使用される等の応用例のための通信を簡略化する。現在8から253の範囲及び255のIDフィールドのための値は、当業者によって予期されるように、新しい設計が追加の指定を所望する使用のために予約されている。
予約1フィールド(1バイト)は通常将来の使用のために予約されており、このフィールドのすべてのビットはゼロに設定される。このフィールドの1つの機能はすべての以後の2バイトフィールドを16ビットワードアドレスに位置合わせさせ、4バイトフィールド2を32ビットワードアドレスに位置合わせさせることである。
音声サンプルカウントフィールド(2バイト)は、このパケットの音声サンプル数を指定する。
サンプルあたりビット及びパッキングフィールドは音声データのパッキングフォーマットを指定する1バイトを含む。一実施形態では、通常利用されるフォーマットは、ビット4から0が、PCM音声サンプルあたりのビット数を定義することである。次にビット5は、デジタル音声データサンプルがパックされているかどうかを指定する。前述されたように、図12は、パッキングされたサンプルとバイト位置合わせされた音声サンプルの間の差異を示す。ビット5の「0」という値は、デジタル音声データフィールドの中の各PCM音声サンプルがインタフェースバイト境界とバイト位置合わせされていることを示し、「1」という値は、各連続PCM音声サンプルが過去の音声サンプルに対してパックされていることを示す。このビットは、ビット4から0(PCM音声サンプルあたりのビット数)に定義される値が8の倍数ではないときにだけ有効である。ビット7から6は、システム設計が追加の指定を所望する用途に予約され、通常ゼロという値で設定される。
音声サンプルレートフィールド(1バイト)は、音声PCMサンプルレートを指定する。利用されるフォーマットは、それぞれ0という値が毎秒8,000サンプル(sps)という速度を示し、1という値が16,000sps、2という値が24,000sps、3という値が32,000sps、4という値が40,000sps、5という値が48,000sps、6という値が11,025sps、7という値が22,050sps、及び8という値が44,100spsを示し、9から255という値は将来の使用のために予約されており、それらは現在ゼロに設定されている。
パラメータCRCフィールド(2バイト)は、パケット長から音声サンプルレートまでのすべてのバイトの16ビットCRCを含む。このCRCが適切にチェックできないとき、パケット全体が廃棄される。デジタル音声データフィールドは再生される未処理音声サンプルを含み、通常、符号なし整数として線形フォーマットの形をとる。音声データCRCフィールド(2バイト)は、音声データだけの16ビットCRCを含む。このCRCがチェックできない場合、音声データは依然として使用できるが、CRCエラーカウントは増分される。
C.ユーザ定義ストリームパケット用
一実施形態では、2バイトのストリームID番号フィールドは、特定のユーザが定義したストリームを識別するために使用される。ストリームパラメータフィールドとストリームデータフィールドのコンテンツは、通常、MDDI装置製造メーカによって定義される。2バイトのストリームパラメータCRCフィールドは、パケット長から始まり音声コーディングバイトまでのストリームパラメータのすべてのバイトの16ビットのCRCを含む。このCRCがチェックできない場合、パケット全体が廃棄される。MDDIの最終用途により必要とされない場合、つまりスそれらがオプションと考えられている場合、ストリームパラメータフィールドとストリームパラメータCRCフィールドの両方とも廃棄されてよい。2バイトのストリームデータCRCフィールドはストリームデータだけのCRCを含む。このCRCが適切にチェックできない場合には、ストリームデータの使用は、応用例の要件に応じてオプションとなる。CRCが良好であることを条件としたストリームデータの使用は、通常、CRCが良好であると確認されるまで、ストリームデータをバッファに入れることを必要とする。CRCエラーカウントは、CRCがチェックしない場合に増分される。
D.カラーマップパケットの場合
2バイトのhClientIDフィールドは、過去に使用されたようにクライアントIDに予約される情報又は値を含む。このフィールドは通常将来の使用に予約されるので、現在の値はビットを「0」に設定することによってゼロに設定される。
2バイトのカラーマップアイテムカウントフィールドは、カラーマップデータフィールドに含まれる3バイトのカラーマップアイテム又はこのパケットの中のカラーマップデータに存在するカラーマップテーブルエントリの総数を指定するために値を使用する。この実施形態では、カラーマップデータのバイト数はカラーマップアイテムカウントの3倍である。カラーマップアイテムカウントは、カラーマップデータを送信しないためにゼロに等しく設定される。カラーマップサイズがゼロである場合には、カラーマップオフセット値は通常依然として送信されるが、それはディスプレイによって無視される。カラーマップオフセットフィールド(4バイト)は、クライアントデバイスのカラーマップテーブルの始まりからのこのパケット内のカラーマップデータのオフセットを指定する。
2バイトのパラメータCRCフィールドは、パケット長から音声コーディングバイトまでのすべてのバイトのCRCを含む。このCRCがチェックできない場合、パケット全体が廃棄される。
カラーマップデータフィールドの場合、各カラーマップロケーションの幅はカラーマップアイテムサイズフィールドによって指定され、一実施形態では、第1の部分が青の規模を指定し、第2の部分が緑の規模を指定し、第3の部分が赤の規模を指定する。カラーマップサイズフィールドは、カラーマップデータフィールドに存在する3バイトのカラーマップテーブルアイテムの数を指定する。単一のカラーマップが1つのビデオデータフォーマットとカラーマップパケットの中に適合できない場合、カラーマップ全体が各パケット内に異なるカラーマップデータとカラーマップオフセットがある複数のパケットを送信することによって指定されてよい。各カラーマップデータアイテム内の青、緑及び赤のビット数は、表示機能パケットのカラーマップRGB幅フィールドに指定されるのと同じである。
2バイトのカラーマップデータCRCフィールドは、カラーマップデータだけのCRCを含む。このCRCがチェックできない場合、カラーマップデータは依然として使用できるが、CRCエラーカウントは増分される。
各カラーマップデータアイテムは、以下の順序で送信されなければならない。つまり、青、緑、赤で、各成分の最下位ビットが最初に送信される。各カラーマップアイテムの個々の赤、緑及び青の成分はパックされ、各カラーマップアイテム(青の成分の最下位ビット)はバイト位置合わせされる必要がある。図97は、6ビットの青、8ビットの緑、及び7ビットの赤のあるカラーマップデータアイテムの例を示す。この例の場合、カラーマップパケットのカラーマップアイテムサイズは21に等しく、クライアント機能パケットのカラーマップRGB幅フィールドは0x0786に等しい。
E.逆方向リンクカプセル化パケットの場合
パラメータCRCフィールド(2バイト)は、パケット長から方向転換長までのすべてのバイトの16ビットCRCを含む。このCRCがチェックできない場合、パケット全体が廃棄される。
一実施形態では、逆方向リンクフラグフィールド(1バイト)は、クライアントから情報を要求し、逆方向リンクタイプを指定するためにフラグのセットを含む。ビット(例えばビット0)が論理1レベルに設定される場合、ホストは、クライアントから指定された情報を要求するが、ビットが論理ゼロレベルに設定された場合、ホストはクライアントから情報を必要としない。ビット0(ゼロ)は、ホストがいつクライアント機能パケットを要求するかを示すために使用される。これは一般には、クライアントによって、逆方向データパケットフィールド内のホストへ送られる。ビット1は、ホストが、クライアント要求とステータスパケットとをいつ要求したかを示すために使用される。これは、クライアントによって、逆方向データパケットフィールド内のホストに送られる。残りのビット(ここではビット1から7)は将来の使用のために予約され、ゼロに設定されている。しかしながら、逆方向リンクのためにフラグを設定するために所望されるようにさらに多くのビットを使用できる。
逆方向レート除数フィールド(1バイト)は、逆方向リンクデータクロックに関連して発生するMDDI_Stbサイクルの数を指定する。逆方向リンクデータクロックは、逆方向レート除数の2倍で除算される順方向リンクデータクロックに等しい。逆方向リンクデータレートは、逆方向リンクデータクロック関連し、逆方向リンクでのインタフェースタイプである。本実施形態では、1型インタフェースの場合、逆方向データレートは逆方向リンクデータクロックに等しく、2型、3型及び4型インタフェースの場合、逆方向データレートはそれぞれ逆方向リンクデータクロックの2倍、4倍及び8倍に等しい。
全ゼロフィールドは、論理ゼロレベルでビットを設定することによって値の中のゼロに等しく設定されるバイトのグループ、ここでは8を含み、すべてのMDDI_Data信号が、クライアントが、方向転換1フィールドの間にホストのラインドライバをディスエーブルする前にMDDI=Stbだけを使用してクロックの回復を開始できるほど十分な時間論理ゼロレベルにあることを保証するために使用される。一実施形態では、全ゼロ1フィールドの長さはケーブルの往復遅延における順方向リンクバイト伝送回数以上である。
方向転換1長フィールド(1バイト)は、方向転換1に割り当てられるバイト総数を指定し、第1の方向転換期間を確立する。方向転換1長パラメータは、ホスト内のラインドライバがディスエーブルされる前に、クライアント内のMDDI_Dataラインドライバがイネーブルできるようにするために割り当てられた方向転換1長パラメータにより指定されるバイト数を適用する。クライアントは、方向転換1のビット0の間にそのMDDI_Dataラインドライバをイネーブルし、ホストは方向転換1の最後のビットの前に完全にディスーブルされるようにその出力をディスエーブルする。MDDI_Stb信号は、あたかもMDDI_Data0が方向転換1期間全体で論理ゼロレベルにあるかのように動作する。方向転換1の設定のさらに完全な説明は前記に示されている。
逆方向データパケットフィールドはクライアントからホストへ転送される一連のデータパケットを含む。クライアントは、ホストに送信するデータがないときには、フィラーパケットを送信してよい、あるいはMDDI_Data線路を論理ゼロ状態又はレベルに駆動してよい。本実施形態では、MDDI_Data線路がゼロに駆動されると、ホストはこれをゼロ長(有効長ではない)のパケットとして解釈し、ホストは現在の逆方向リンクカプセル化パケットの持続期間中クライアントから追加のパケットを受け入れない。
方向転換2長フィールド(1バイト)は、第2の方向転換期間を確立するために方向転換2に割り当てられるバイトの総数を指定する。推奨される方向転換2の長さは、ホストがMDDI_Dataドライバをイネーブルするために必要な時間に、往復遅延のための必要なバイト数を加えたものである。方向転換2の長さは、ホスト内の逆方向リンクパケットを処理するための十分な時間を可能にするように計算された値、又は必要な最小値よりも大きな値にもなりうる。
方向転換2フィールドは、方向転換長パラメータによって指定されたようなバイト数からなる。ホストは、方向転換2の間にMDDI_Dataラインドライバをイネーブルする前に、少なくとも往復遅延時間待つ。ホストは一般に、MDDI_Dataラインドライバを、方向転換2の最後のビットの前に完全にイネーブルされるようにイネーブルする。クライアントは一般に、その出力を、方向転換2の最後のビットの前に完全にディセーブルされるようにディセーブルする。方向転換2フィールドの目的は、逆方向データパケットフィールドからの残りのデータ量が、クライアントから送信又は転送されるようにすることである。割り当てられた安全マージンの量とインタフェースとを実施している異なるシステムにおける変化時には、ホスト内又はホストにおけるライン受信機でも説明したように、ホスト及びクライアントの何れも、方向転換2フィールド期間のある部分の間、MDDI_Data信号を論理ゼロレベルに駆動しないことが可能であろう。MDDI_Stb信号は、方向転換2期間全体で実質的に、MDDI_Data0が論理ゼロレベルであるかのように動作する。方向転換2の設定の説明は前述されている。
逆データパケットフィールドは、クライアントからホストに転送される一連のデータパケットを含む。前述されたように、フィラーパケットは他のパケットタイプによって使用されていない残りの空間を充填するために送信される。
全ゼロ2フィールドは、論理ゼロレベルでビットを設定することによって値のゼロに等しく設定されるバイトのグループ(この実施形態では8)を含み、すべてのMDDI_Data信号が、方向転換2フィールドの後にホストのラインドライバをイネーブルしてから、MDDI_Data0とMDDIStbの両方を使用してクロックを回復できるほど十分な時間、論理ゼロレベルとなることを保証するために使用される。
F.クライアント機能パケット用
一実施形態のために説明されているように、プロトコルバージョンフィールドは、クライアントによって使用されるプロトコルバージョンを指定する。最小プロトコルバージョンフィールドが、クライアントが利用する又は解釈する最小プロトコルバージョンを指定するために2バイトを使用するが、現在、初期のバージョンは1に等しく設定され、知られているように、新たなバージョンが生成されると、時間によって変化する。この場合、ゼロ値もまた有効な値である。データレート機能フィールド(2バイト)は、クライアントがインタフェースの順方向リンク上の各データペアで受信できる最大データレートを指定し、毎秒メガバイト(Mbps)の形式で指定される。インタフェースタイプ機能フィールド(1バイト)は、順方向リンクと逆方向リンクでサポートされているインタフェースタイプを指定する。
‘1’に設定されたビットは、指定されたインタフェースタイプがサポートされていることを示し、‘0’に設定されたビットは、指定されたタイプがサポートされていないことを示す。ホスト及びクライアントは、順方向ライン及び逆方向ライン上で少なくとも1型をサポートすべきである。インタフェースタイプの隣接領域をサポートする必要はない。例えば、インタフェースにおいて1型と3型のみをサポートすることは完全に有効であるが、3型と4型とをサポートすることは有効ではないであろう。また、順方向リンクと逆方向リンクとが同じインタフェースタイプを用いて動作する必要もない。しかしながら、リンクがハイバーネーションから出た場合、ホストとクライアントとの両方による使用のために別のモードがネゴシエートされ、選択され、あるいは承認されるまで、順方向リンクと逆方向リンクとの両方が、1型モードで動作を開始すべきである。
サポートされているインタフェースは、一つの実施形態では、順方向リンクでそれぞれ2型(2ビット)、3型(4ビット)又は4型(8ビット)モードのうちのどれかを選択するためにビット0、ビット1、又はビット2を選択し、逆方向リンクでそれぞれ2型、3型又は4型モードのうちのどれかを選択するためにビット3、ビット4又はビット5を選択することによって現在示されており、ビット6と7は予約され、この時点ではゼロに設定されている。ビットマップ幅フィールドと高さフィールドは、ここではそれぞれ2バイトであり、ピクセル単位でビットマップの幅と高さを指定する。
白黒機能フィールド(1バイト)は、一つの実施形態では、白黒フォーマットで表示できる解像度のビット数を指定するために使用される。ディスプレイが白黒フォーマットを使用できない場合は、この値はゼロで設定される。ビット7から4は将来の使用のために予約され、したがってゼロとして設定される。ビット3から0は、ピクセルごとに存在できるグレイスケールの最大ビット数を定義する。これらの4ビットにより、ピクセルごとに1から15の値を指定できるようになる。値がゼロである場合には、白黒フォーマットはディスプレイによってサポートされていない。
Bayer機能フィールドは、解像度、ピクセルグループ、及びBayerフォーマットで転送できるピクセル順序のビット数を指定するために1バイトを使用する。クライアントがBayerフォーマットを使用できない場合、この値はゼロである。Bayer機能フィールドは、以下の値から構成される。ビット5から4は必要とされるピクセルグループパターンを定義するが、ビット3から0は、各ピクセルに存在する輝度の最大ビット数を定義し、ビット8から6は必要とされるピクセル順序を定義し、ビット14から19は将来の使用ために予約されており、通常、当面ゼロに設定されている。ビット15は、論理1レベルに設定されるとき、クライアントがパックフォーマット又はアンパックフォーマットのどちらかでBayerピクセルデータを受け入れることができることを示す。ビット15がゼロに設定されると、これはクライアントがアンパックフォーマットでのみBayerピクセルデータを受け入れることができることを示す。
カラーマップ機能フィールド(3バイト)は、一つの実施形態では、ディスプレイのカラーマップテーブルに存在するテーブルアイテムの最大数を指定する。ディスプレイがカラーマップフォーマットを使用できない場合は、この値はゼロに設定される。
RGB機能フィールド(2バイト)は、RGBフォーマットで表示できる解像度のビット数を指定する。ディスプレイがRGBフォーマットを使用できない場合、この値はゼロに等しい。RGB機能ワードは3つの別々の符号なし値から構成され、ビット3から0は青の最大ビット数を定義し、ビット7から4は緑の最大ビット数を定義し、ビット11から8は各ピクセルの赤の最大ビット数を定義する。現在、ビット14から12は将来の使用のために予約され、通常ゼロに設定されている。ビット14から12は将来の使用のために予約され、通常ゼロに設定されている。ビット15は、論理1レベルに設定されると、クライアントがパックフォーマット又はアンパックフォーマットのどちらかでRGBピクセルデータを受け入れることができることを示す。ビット15が論理ゼロレベルに設定されている場合、これは、クライアントがアンパックフォーマットでのみRGBピクセルデータを受け入れることができることを示す。
Y Cr Cb機能フィールド(2バイト)は、Y Cr Cbフォーマットで表示できる解像度のビット数を指定する。ディスプレイがY Cr Cbフォーマットを使用できない場合、この値はゼロに等しく設定される。Y Cr Cb機能ワードは3つの別々の符号なし値から構成され、ビット3から0は、Cbサンプルの最大ビット数を定義し、ビット7から4はCrサンプルの最大ビット数を定義し、ビット11から8はYサンプルの最大ビット数を定義し、ビット15から12は将来の使用のために予約され、ゼロに設定されている。
クライアント特徴機能フィールドは、一つの実施形態では、サポートされているクライアントでの特定の特徴を示すフラグのセットを含む4バイトを使用する。論理1レベルに設定されるビットは、機能がサポートされていることを示し、論理ゼロレベルに設定されるビットは、機能がサポートされていないことを示す。この実施形態では、ビット0の値は、ビットマップブロック転送パケット(パケットタイプ71)がサポートされているか否かを示す。ビット1、2、及び3の値は、ビットマップ領域塗りつぶしパケット(パケットタイプ72)、ビットマップパターン塗りつぶしパケット(パケットタイプ73)、又はリードフレームバッファパケット(パケットタイプ74)がそれぞれサポートされているかどうかを示す。ビット4の値は、透明色イネーブルパケットを用いて、クライアントに1つの色を透明にする機能があるかどうかを示す。ビット5と6の値は、クライアントがそれぞれアンパックフォーマット又はパックフォーマットで音声データを受け入れることができるかどうかを示し、ビット7の値は、クライアントがカメラから逆方向リンクビデオストリームを送信できるかどうかを示している。ビット8の値は、クライアントがピクセルデータの完全行を受信し、ビデオストリームパケットのピクセルデータ属性のビット5によって指定されるディスプレイアドレス指定を無視する能力を有するかどうかを示し、クライアントはピクセルデータ属性フィールドのビット15を用いてビデオフレームデータのフレーム同期又は最後も検出できる。
ビット9の値は、クライアントが、要求特有ステータスパケットを解釈し、有効ステータス応答リストパケットに応答する能力を持っているか否かを示す。クライアントは、上述したように、有効ステータス応答リストパケットの有効パラメータ応答リストフィールド内の追加ステータスを戻す能力を持っていることを示すことができる。ビット10の値は、クライアントが、ディスプレイ電力ステータス01をサポートする能力を持っているか否かを示す。ディスプレイ電力ステータスは、上述したディスプレイ電力ステータスパケットの電力状態フィールドのビット[3:2]を用いて設定される。ディスプレイ電力ステータス01は、もしあれば、選択されたデイスプレイが照明されず、最低量の電力を消費している状態であり、この状態の間、フレームバッファの内容は、一般的に、保持されることが保証される。
ビット11と12の値は、いつクライアントがポインティングデバイスと通信中で、ポインティングデバイスデータパケットを送信、受信できるのか、あるいはキーボードを用いてそれぞれキーボードデータパケットを送信、受信できるのかを示す。ビット13の値は、VCP特徴パケットをサポートすることにより、クライアントが音声又はビデオパラメータの1つ又は複数を設定する能力を有するかどうかを示す。つまりVCP特徴要求パケット、VCP特徴応答パケット、VCP設定特徴パケット、有効パラメータ要求パケット、及び有効パラメータ応答パケットである。ビット14の値は、クライアントがピクセルデータをオフラインのディスプレイフレームバッファに書き込む能力を有するかどうかを示す。これは図88Aに示されている。このビットが論理1レベルに設定されると、表示更新ビット(ビデオストリームパケットのピクセルデータ属性のビット7と6)は値「01」に設定されてよい。
ビット15の値は、クライアントが、ディスプレイイメージをリフレッシュするために現在使用されているディスプレイフレームバッファのみにピクセルデータを書き込む能力を持っている場合を示す。これは、図88Bに示されている。もしもこのビットが、1に設定されていれば、表示更新ビット(ビデオストリームパケットのピクセルデータ属性の第6及び第7ビット)が値「00」に設定されるかもしれない。ビット16の値は、クライアントが、単一のビデオストリームパケットからのピクセルデータを全てのディスプレイフレームバッファに書き込む能力を持っている場合を示す。これは、図88Cに示されている。このビットが、論理1レベルに等しく設定されていれば、表示更新ビット(ビデオストリームパケットのピクセルデータ属性の第6及び第7ビット)が値「11」に設定されるかもしれない。
一つの実施形態では、ビット17の値は、クライアントが、要求特有ステータスパケットに対し応答する能力を持っている場合を示し、ビット18の値は、クライアントが、往復遅延測定パケットに対し応答する能力を持っている場合を示し、ビット19の値は、クライアントが、順方向リンク歪み校正パケットに対する能力を持っている場合に示す。一つの実施形態では、ビット20の値は、クライアントが、表示電力ステータスパケットに応答する能力を持っている場合を示す。
一つの実施例では、ブロック転送パケット(パケットタイプ71)、ビットマップ領域塗りつぶしパケット(パケットタイプ72)、及びビットマップパターン塗りつぶしパケット(パケットタイプ73)が、ビット0,1,2又はラスタ動作フィールドによって特定されたクライアントによってサポートされている場合、ビット21の値は、このクライアントが、ブロック転送パケット(パケットタイプ71)、ビットマップ領域塗りつぶしパケット(パケットタイプ72)、及びビットマップパターン塗りつぶしパケット(パケットタイプ73)のラスタ動作フィールドを使用することができる時を示す。一つの実施例では、ビット21が論理ゼロレベル又は論理ゼロ値を持ち、パケットがサポートされていれば、クライアントは、ラスタ動作フィールドを使用する能力を持たず、クライアントは、これらパケットによって特定されたピクセル位置にコピー又は書き込みを行う能力のみを持つ。
ビット22の値は、クライアントがレジスタアクセスパケットに応答する能力を有するかどうかを示す。ビット9から10、20及び23から31は、現在、システム設計者に有効な将来の使用又は代替指定のために予約され、通常はゼロに等しく設定される。
表示ビデオフレーム機能フィールド(1バイト)は、毎秒フレーム単位でディスプレイの最大ビデオフレーム更新機能を指定する。ホストは、このフィールドで指定される値より低速で画像の更新を選んでよい。
音声バッファ深度フィールド(2バイト)は、各音声ストリーム専用であるディスプレイ内の弾性バッファの深度を指定する。
音声チャネル機能フィールド(2バイト)は、どの音声チャネルがクライアント、又はクライアントに接続されたデバイスによってサポートされるのかを示すフラグのグループを含む。1に設定されるビットは、チャネルがサポートされていることを示し、ゼロに設定されているビットは、そのチャネルがサポートされていないことを示す。ビット位置は様々なチャネルに割り当てられる。例えば一つの実施形態では、ビット位置0、1、2、3、4、5、6、及び7は、左前チャネル、右前チャネル、左後チャネル、右後チャネル、前中心チャネル、サブウーファーチャネル、サラウンド左チャネルとサラウンド右チャネルを示している。ビット8から14は、将来の使用のために現在予約されており、通常ゼロに設定されている。一つの実施形態では、ビット15は、クライアントが、順方向音声チャネルイネーブルパケットをサポートしているかを示すために使用される。サポートしている場合、ビット15は、論理1レベルに設定される。しかしながら、クライアントが、順方向音声チャネルイネーブルパケットの結果として音声チャネルをディスエーブルすることができないか、クライアントが音声機能をサポートしていないのであれば、このビットは、論理ゼロレベル又は値に設定される。
順方向リンク用の2バイトの音声サンプルレート機能フィールドは、クライアントデバイスの音声サンプルレート機能を示すためにフラグのセットを含む。ビット位置は、さまざまな速度に相応して割り当てられ、例えばビット0、1、2、3、4、5、6、7及び8は、それぞれ8,000、16,000、24,000、32,000、40,000、48,000、11,025、22,050及び44,100毎秒サンプル(SPS)であり、ビット9から15は将来の又は代替レートの使用のために予約されているので、それらは現在「0」に設定されている。これらのビットの内の1つの値を「1」に設定すると、その特定のサンプルレートがサポートされていることを示し、ビットを「0」に設定すると、そのサンプルレートはサポートされていないことを示す。
最小サブフレームレートフィールド(2バイト)は、毎秒フレーム単位で最小サブフレームレートを指定する。最小サブフレームレートは、クライアントステータス更新レートをクライアント内の特定のセンサ又はポインティングデバイスを読み取るのに十分に保つ。
2バイトのマイクサンプルレート機能フィールドは、逆方向リンクの場合、クライアントデバイス内のマイクの音声サンプルレート機能を示すフラグのセットを含む。MDDIのために、クライアントデバイスマイクは少なくとも毎秒8,000サンプルレートを最小でサポートするように構成される。このフィールドのビット位置は、例えばそれぞれ8,000、16,000、24,000、32,000、40,000、48,000、11,025、22,050、及び44,100毎秒サンプル(SPS)を表すために使用されているビット位置0、1、2、3、4、5、6、7及び8の様々な速度に割り当てられ、ビット9から15は、所望されるように将来又は代替レートの使用のために予約されているため、現在は「0」に設定されている。これらのビットの1つのビット値を「1」に設定すると、その特定のサンプルレートがサポートされていることを示し、ビットを「0」に設定すると、そのサンプルレートがサポートされていないことを示している。マイクが接続されていない場合、マイクサンプルレート機能ビットのそれぞれはゼロに等しく設定される。
キーボードデータフォーマットフィールド(ここでは1バイト)は、キーボードがクライアントシステムに接続されているか否かと、接続されているキーボードのタイプを特定する。一つの実施形態では、ビット6から0によって設定された値は、接続されているキーボードのタイプを定義するために使用される。もしもこの値がゼロ(0)であれば、キーボードタイプは未知であると考えられる。1の値の場合、キーボードデータフォーマットは、標準的なPS−2スタイルであると考えられる。今のところ、2から125の範囲の値は、使用されておらず、システム設計者、インタフェース組込者、又は製品開発者が、MDDインタフェース及び対応するクライアント又はホストとの使用のために特定のキーボード又は入力デバイスを定義するために予約されている。キーボードデータフォーマットがユーザ定義されたことを示すために値126が使用される。一方、キーボードがクライアントに接続できないことを示すために値127が使用される。更に、ビット7は、キーボードがクライアントと通信できるか否かを示すために使用される。このビットの意図的な使用は、キーボードが無線リンクを使ってクライアントと通信できる時を示すためである。ビット7は、キーボードをクライアントに接続できないことをビット6から0が示すのであればゼロレベルに設定される。従って、一つの実施形態では、ビット7の値が0であれば、キーボードとクライアントは通信することができず、ビット7の値が1であれば、キーボードとクライアントとは、互いに通信できることを認める。
ポインティングデバイスデータフォーマットフィールド(ここでは1バイト)は、ポインティングデバイスがクライアントシステムに接続されているか否かと、接続されているポイントティングデバイスのタイプとを特定する。一つの実施形態では、ビット6から0によって設定されている値は、接続されているポインティングデバイスのタイプを定義するために使用される。もしも値がゼロ(0)であれば、このポインティングデバイスは、未知であると考えられる。値が1の場合、このポインティングデバイスデータフォーマットは、標準的なPS−2スタイルであると考えられる。今のところ、2から125の範囲の値は、使用されておらず、システム設計者、インタフェース組込者、又は製品開発者が、MDDI及び対応するクライアント又はホストとの使用のために特定のポインティングデバイス又は入力デバイスを定義するために予約されている。ポインティングデバイスデータフォーマットがユーザ定義されたことを示すために値126が使用される。一方、ポインティングデバイスがクライアントに接続できないことを示すために値127が使用される。更に、ビット7は、ポインティングデバイスがクライアントと通信できるか否かを示すために使用される。このビットの意図的な使用は、キーボードが無線リンクを使ってクライアントと通信できる時を示すためである。ビット7は、ポインティングデバイスをクライアントに接続することができないことをビット6から0が示すのであればゼロレベルに設定される。従って、一つの実施形態では、ビット7の値が0であれば、ポインティングデバイスとクライアントは通信することができず、ビット7の値が1であれば、ポインティングデバイスとクライアントとは、互いに通信できることを認める。
コンテンツ保護タイプフィールド(2バイト)は、ディスプレイによってサポートされるデジタルコンテンツ保護のタイプを示すフラグのセットを含む。現在、ビット位置0は、いつDTCPがサポートされているのかを示すために使用され、ビット位置1はいつHDCPがサポートされているのかを示すために使用され、ビット位置2から15は所望されるように、又は使用可能なように他の保護方式での使用のために予約されているため、それらは現在ゼロに設定されている。
Mfrネームフィールド(ここでは2バイト)は、製造者のEISA 3キャラクタIDを含み、VESA EDID仕様と同じ手法で3つの5ビットキャラクタにパックされる。キャラクタ‘A’は、00001バイナリとして表され、キャラクタ‘Z’は、11010バイナリとして表される。そして、‘A’と‘Z’の間の全ての文字は、‘A’と‘Z’の間のアルファベットシーケンスに対応したシーケンシャルなバイナリ値として表される。Mfrネームフィールドの最上位ビットは、将来の実装において使用されるまで使用されず、今のところ一般に論理ゼロに設定される。例:文字列“XYZ”によって表される製造者は、0x663aのMfrネーム値を持つ。もしもこのフィールドがクライアントによってサポートされていないのであれば、一般にゼロに設定される。プロダクトコードフィールドは、2バイトを使い、ディスプレイ製造者によって割り当てられたプロダクトコードを含む。もしもこのフィールドがクライアントによってサポートされていないのであれば、一般にゼロに設定される。
予約1フィールド、予約2フィールド、及び予約3フィールド(ここでは、それぞれ2バイト)は、関連する情報における将来の使用のために予約されている。このフィールド内の全てのビットは、一般に論理ゼロレベルに設定される。このようなフィールドの目的は、続く全ての2バイトフィールドを、16ビットワードアドレスに並べさせ、4バイトフィールドを、32ビットワードアドレスに並べさせることである。
ファイルされたシリアル番号は、この実施形態では、数値形式によるディスプレイのシリアル番号を特定するために4バイトを用いる。このフィールドがクライアントによってサポートされていないのであれば、一般にゼロに設定される。製造フィールドの週は、ディスプレイの製造週を定義するために1バイトを用いる。この値は、クライアントによってサポートされているのであれば、典型的には、1から53の範囲にある。このフィールドがクライアントによってサポートされていなければ、ゼロに設定される。製造フィールドの年は、ディスプレイの製造年を定義する1バイトである。この値は、1990年からのオフセットである。このフィールドによって、1991年から2245年の範囲が表現可能である。例:2003年は、13の値を持つ製造年に対応する。このフィールドがクライアントによってサポートされていないのであれば、ゼロに設定される。
CRCフィールド(ここでは2バイト)は、パケット長を含むパケット内の全バイトからなる16ビットCRCを含む。
G.クライアント要求及びステータスパケット
逆方向リンク要求フィールド(3バイト)は、クライアントが、ホストに情報を送信するために次のサブフレームの逆方向リンクで必要とするバイト数を指定する。
CRCエラーカウントフィールド(1バイト)は、メディアフレームの開始以来どのくらいの数のCRCエラーが発生したのかを示す。CRCカウントは、ゼロというサブフレームカウントがついたブフレームヘッダパケットが送信されるとリセットされる。CRCエラーの実際の数が255を超えると、この値は通常255で飽和する。
機能変更フィールドは、クライアントの機能の変化を示すために1バイトを使用する。これは、ユーザが、マイク、キーボード、又はディスプレイ、あるいは何らかの他の理由から周辺装置を接続する場合に発生するであろう。ビット「7:0」が0に等しいときには、機能は最後のクライアント機能パケットが送信されて以来変化しなかった。しかしながら、ビット[7:0]が1から255に等しいとき、機能は変更した。クライアント機能パケットは、新しい表示特性を決定するために調べられる。
クライアントビジーフラグフィールドは、クライアントが特定の機能を実行しており、その機能に関する別のパケットを受け付ける準備ができていないことを示すために2バイトを使用する。論理1レベル又は論理1値に設定されたビットは、クライアントによって特定の機能が現在実行されており、クライアント内の関連する機能がビジーであることを示す。もしもクライアント内の関連する機能の準備ができていれば、ビットは、論理ゼロに設定される。クライアントは、クライアント内でサポートされていない全ての機能のために、ビジーステータス(1に設定されたビット)を返すべきである。
一つの実施形態では、これらのバイトは、次の関係に従って解釈される。すなわち、もしもビット0が‘1’であれば、ビットマップブロック転送機能がビジーとなる。一方、ビット1が‘1’であれば、ビットマップ領域塗りつぶし機能がビジーとなる。もしもビット2が‘1’であれば、ビットマップパターン塗りつぶし機能がビジーとなる。同時に、ビット3が‘1’であれば、グラフィックサブシステムはビジーであり、クライアント内のフレームバッファの利用を必要とする動作を実行する。フレームバッファの利用を必要とするその他のグラフィック機能は、ビットが論理1値に設定されるまで始まらない。
今のところ、ビット4から15は、将来の使用のために予約され、これらのビットが将来割り当てられた場合に、ビジーステータスを示すために、一般に、論理1レベル又は状態に設定される。
H.ビットブロック転送パケットの場合
ウィンドウ左上座標X値フィールドとY値フィールドは、移動するウィンドウの左上角の座標のX値とY値を指定するために、それぞれ2バイトを使用する。ウィンドウ幅フィールドとウィンドウ高さフィールドは、移動するウィンドウの幅と高さを指定するためにそれぞれ2バイトを使用する。ウィンドウX移動フィールドとY移動フィールドは、ウィンドウがそれぞれ水平と垂直に移動されるピクセル数を指定するために、それぞれ2バイトを使用する。Yの正の値はウィンドウを下方に移動させ、負の値は上方に移動させるが、通常、これらの座標は、Xの正の値によりウィンドウが右に移動し、負の値により左に移動するように構成されている。
I.ビットマップ領域塗りつぶしパケット
ウィンドウ左上座標X値フィールドとY値フィールドは、塗りつぶすウィンドウの左上角の座標のX値とY値を指定するためにそれぞれ2バイトを使用する。ウィンドウ幅フィールドとウィンドウ高さフィールド(各2バイト)は、塗りつぶされるウィンドウの幅と高さを指定する。ビデオデータフォーマット記述子フィールド(2バイト)は、ピクセル領域塗りつぶし値のフォーマットを指定する。フォーマットはビデオストリームパケット内の同じフィールドと同じである。ピクセル領域塗りつぶし値フィールド(4バイト)は、前述されたフィールドによって指定されたウィンドウの中に充填されるピクセル値を含む。このピクセルのフォーマットは、ビデオデータフォーマット記述子フィールドに指定される。
J.ビットマップパターン塗りつぶしパケット
ウィンドウ左上座標X値フィールドとY値フィールドは、塗りつぶされるウィンドウの左上角の座標のX値とY値を指定するためにそれぞれ2バイトを使用する。ウィンドウ幅フィールドと高さフィールド(各2バイト)は、塗りつぶされるウィンドウの幅と高さを指定する。パターン幅フィールドとパターン高さフィールド(各2バイト)は塗りつぶしパターンの幅と高さをそれぞれ指定する。水平パターンオフセットフィールド(2バイト)は、塗りつぶされる特定のウィンドウの左端から、ピクセルデータパターンの水平オフセットを特定する。特定されている値は、パターン幅フィールド内の値よりも小さくなるであろう。垂直パターンオフセットフィールド(2バイト)は、塗りつぶされると特定のウィンドウの上端から、ピクセルデータパターンの垂直オフセットを特定する。特定されている値は、パターン高さフィールド内の値よりも小さくなるであろう。
2バイトのビデオデータフォーマット記述子フィールドは、ピクセル領域塗りつぶし値のフォーマットを指定する。図11は、ビデオデータフォーマット記述子がどのようにしてコーディングされるのかを示す。フォーマットはビデオストリームパケットの同じフィールドと同じである。
パラメータCRCフィールド(2バイト)は、パケット長からビデオフォーマット記述子までのすべてのバイトのCRCを含む。このCRCがチェックできない場合には、パケット全体が廃棄される。パターンピクセルデータフィールドはビデオデータフォーマット記述子により指定されるフォーマットの塗りつぶしパターンを指定する未処理ビデオ情報を含む。データはバイトにパックされ、各行の第1のピクセルはバイト位置合わせされる。塗りつぶしパターンデータは一度に一行ずつ送信される。パターンピクセルデータCRCフィールド(2バイト)はパターンピクセルデータだけのCRCを含む。このCRCがチェックできない場合、パターンピクセルデータは依然として使用できるが、CRCエラーコンテンツは増分される。
K.通信リンクデータチャネルパケット
パラメータCRCフィールド(2バイト)は、パケット長からパケットタイプまでのすべてのバイトの16ビットCRCを含む。このCRCがチェックできない場合は、パケット全体が廃棄される。
通信リンクデータフィールドは、通信チャネルからの未処理データを含む。このデータは単にディスプレイのコンピュータデバイスに渡される。
通信リンクデータCRCフィールド(2バイト)は、通信リンクデータだけの16ビットCRCを含む。このCRCがチェックできない場合、通信リンクデータは依然として使用されるあるいは有効であるが、CRCエラーカウントは増分される。
L.順方向音声チャネルイネーブルパケット
音声チャネルイネーブルマスクフィールド(1バイト)は、どの音声チャネルがクライアントでイネーブルされなければならないのかを示すフラグのグループを含む。1に設定されるビットは、対応するチャネルをイネーブルし、ゼロに設定されるビットは対応するチャネルをディスエーブルする。ビット0から5は、それぞれ左前チャネル、右前チャネル、左後チャネル、右後チャネル、前中心チャネル、及びサブウーファーチャネルをアドレス指定するチャネル0から5を指定する。ビット6と7は、将来の使用のために予約されており、当面は通常ゼロに等しく設定されている。
M.逆方向音声サンプルレートパッケージ
音声サンプルレートフィールド(1バイト)はデジタル音声サンプルレートを指定する。このフィールドの値は様々な速度に割り当てられ、0、1、2、3、4、5、6、7、及び8という値は8,000、16,000、24,000、32,000、40,000、48,000、11,025、22,050、及び44,100毎秒サンプル(SPS)を示すために使用され、9から254という値は、所望されるように代替速度と使用するために予約されているため、それらは現在は「0」に設定されている。255という値は逆方向リンク音声ストリームをディスエーブルするために使用される。
サンプルフォーマットフィールド(1バイト)は、デジタル音声サンプルのフォーマットを指定する。ビット[1:0]が[0]に等しいとき、デジタル音声サンプルは線形フォーマットを取り、それらが1に等しい時には、デジタル音声サンプルはμ法則フォーマットを取る。それらが2に等しいとき、デジタル音声サンプルはA−法則フォーマットである。ビット[7:2]は、所望されるように、音声フォーマットを指定する上での代替使用に予約されており、通常はゼロに等しく設定されている。
N.デジタルコンテンツ保護オーバヘッドパケット用
コンテンツ保護タイプフィールド(1バイト)は、使用されるデジタルコンテンツ保護方法を指定する。1という値は高帯域幅デジタルコンテンツ保護システム(HDCP)を示すが、「0」という値はデジタル伝送コンテンツ保護(DTCP)を示す。2から255という値は、現在指定されていいないが、所望されるように代替保護方式との使用のために予約されている。コンテンツ保護オーバヘッドメッセージフィールドは、ホストとクライアントの間で送信されるコンテンツ保護メッセージを含む可変長のフィールドである。
O.透明色イネーブルパケット
透明色イネーブルフィールド(1バイト)は、透明色モードがいつイネーブルされる、あるいはディスエーブルされるのかを指定する。ビット0が0に等しい場合、透明色モードはディスエーブルされ、それが1に等しい場合、透明色モードはイネーブルされ、透明色は以下の2つのパラメータによって指定される。このバイトのビット1から7は、将来の使用のために予約され、通常ゼロに等しく設定されている。
ビデオデータフォーマット記述子フィールド(2バイト)は、ピクセル領域塗りつぶし値のフォーマットを指定する。図11は、ビデオデータフォーマット記述子がどのようにしてコーディングされるのかを示す。フォーマットは、通常ビデオストリームパケット内の同じフィールドと同じである。
ピクセル領域塗りつぶし値フィールドは、前記に指定されるウィンドウの中に充填されるピクセル値のために割り当てられる4バイトを使用する。このピクセルのフォーマットはビデオデータフォーマット記述子フィールドに指定されている。
P.往復遅延測定パケット
2バイトのパケット長フィールドは、パケット長フィールドを含まないパケット内のバイト総数を指定し、一実施形態では、159という固定長を有するように選択されている。このパケットタイプを82という値で識別する2バイトのパケットタイプフィールドは、往復遅延測定パケットとしてパケットを識別する。hClient IDフィールドは、前記のように、クライアントIDとして将来使用するために予約されており、通常ゼロに設定されている。
一実施形態では、パラメータCRCフィールド(2バイト)は、パケット長からパケットタイプまでのすべてのバイトの16ビットCRCを含む。このCRCがチェックできない場合、パケット全体が廃棄される。
ガード時間1フィールド(ここでは64バイト)は、クライアントのMDDI_Dataラインドライバが、ホストのラインドライバがディスエーブルされる前にイネーブルできるようにするために使用される。クライアントは、ガード時間1のビット0の間にそのMDDI_Dataラインドライバをイネーブルし、ホストはガード時間1の最後のビットの前に完全にディスエーブルされるようにそのラインドライバをディスエーブルする。ホストとクライアントは、それらがディスエーブルされていないとき、共にガード時間1の間に論理ゼロレベルを駆動する。このフィールドの別の目的は、すべてのMDDI_Data信号が、クライアントが、ホストのラインドライバをディスエーブルする前にMDDI_Stbだけを使用して、クロック又はクロック信号の回復を開始できるほど十分な時間論理ゼロレベルにあることを保証することである。
測定期間フィールドは、クライアントが、順方向リンクで使用されるデータレートの半分で、0xffという2つのバイト、及び0x00という30バイトに応答できるようにするために使用される64バイトのウィンドウである。このデータレートは1という逆方向リンクレート除数に相当する。クライアントは、それが測定期間の始まりであると知覚するとただちにこの応答を返す。このクライアントからの応答は、正確にリンクの往復遅延に、ホストでの測定期間の第1のビットの開始後のクライアントの論理遅延を加えたもので、ホストで受信される。
全ゼロフィールド(2バイト)は、ホストとクライアント内のMDDI_Dataラインドライバが、MDDI_Dataが常に駆動されるように重複できるようにするためにゼロを含んでいる。ホストは全てゼロの1フィールドのビット0の間にMDDI_Dataラインドライバをイネーブルし、クライアントも測定期間の最後でそれが行ったように、論理ゼロレベルに信号を駆動し続ける。
ガード時間2フィールド(64バイト)の値は、往復遅延が測定期間で測定できる最大量であるときにクライアントによって駆動される測定期間の重複を可能にする。クライアントはそのラインドライバをガード時間2のビット0の間にディスエーブルし、ホストはガード時間2の最後のビットの直後にそのラインドライバをイネーブルする。ホストとクライアントの両者とも、それらがディスエーブルされていないときガード時間2の間に論理ゼロレベルを駆動する。このフィールドの別の目的は、すべてのMDDI_Data信号が、クライアントが、ホストのラインドライバをイネーブルした後に、MDDI_Data0とMDDI_Stbの両方を使用してクロック信号の回復を開始できるほど十分な時間論理ゼロレベルにいることを保証することである。
Q.順方向リンク歪み校正パケット
一実施形態では、パラメータCRCフィールド(2バイト)は、パケット長からパケットタイプまでのすべてのバイトの16ビットCRCを含む。このCRCがチェックできないと、パケット全体が廃棄される。
全てゼロの1フィールドは、構成データシーケンスフィールドの始まりにおいて、MDDI_Stb上の遷移があることを保証するために、8バイトを用いる。一般に、これらバイトは、ゼロに等しい8ビット符号なし整数を適用する。これはまた、クライアントコアロジックが、MDDI_Stb及びMDDI_0のXORを用いることから、MDDI_Stb又は回復されたクロックとしてMDDI_Stb信号を単に用いることにクロック回復回路のモードを変更するための十分な時間を与える。
校正データシーケンスフィールドは、MDDI_Data信号をデータ期間ごとにトグルさせるデータシーケンスを含む。校正データシーケンスフィールドの長さは、順方向リンク上で使用されているインタフェースによって決定される。校正データシーケンスの処理中、MDDIホストコントローラはすべてのMDDI_Data信号をストローブ信号に等しく設定する。校正データシーケンスフィールドはクライアントによって受信されているが、クライアントクロック回復回路は、データクロックを回復するためにMDDI_Stb XorMDDI_Data0よりむしろMDDI_Stbだけを使用するべきである。校正データシーケンスフィールドの始まりのMDDI_Stb信号の正確な位相に応じて、校正データシーケンスは通常、このパケットが送信されるときに使用されるインタフェースタイプに基づいて、以下の1つとなる。
1型−(64バイトデータシーケンス)0xaa,0xaa,・・・又は0x55,0x55・・・
2型−(128バイトデータシーケンス)0xcc,0xcc,・・・又は0x33,0x33・・・
3型−(256バイトデータシーケンス)0xf0,0xf0,・・・又は0x0f,0x0f・・・
4型−(512バイトデータシーケンス)0xff,0x00,0xff,0x00・・・又は0x00,0xff,0x00,0xff・・・
全てゼロの2フィールドは、8バイトを使用して、クライアントコアロジックが、クロック回復回路のモードをオリジナル状態に戻すのに、回復したクロックとしてのMDDI_Stb信号を用いることから、MDDI_StbとMDDI_0とのXORを用いることに変更するのに十分な時間を与える。
1型インタフェースと2型インタフェース両方のためのMDDI_Data波形とMDDI_Stb波形の例は、それぞれ図62Aと図62Bに示されている。
XVII.結論
本発明の多様な実施形態は前述されてきたが、それらが例証としてのみ提示され、制限ではないことが理解されるべきである。したがって、本発明の幅及び範囲は、前述された例示的な実施形態のいずれによっても制限されるべきではなく、添付請求項及びその同等物に従ってのみ定義されるべきである。
ポータブルコンピュータ又は他のデータ処理装置と関連する、マイクロディスプレイ装置又はプロジェクタの使用を含む、本発明の実施形態が動作する可能性がある基本的な環境を示す図である。 マイクロディスプレイ装置又はプロジェクタ、及び無線トランシーバと関連して使用される音声プレゼンテーション要素の使用を含む、本発明の実施形態が動作する可能性のある基本的な環境を示す図である。 ポータブルコンピュータで使用される内蔵ディスプレイ又は音声プレゼンテーション装置の使用を含む、本発明の実施形態が動作する可能性のある基本的な環境を示す図である。 無線トランシーバで使用される内蔵ディスプレイ要素又は音声プレゼンテーション要素の使用を含む、本発明が動作する可能性のある基本的な環境を示す図である。 ホストとクライアント相互接続のモバイルデジタルデータインタフェースの全体的な概念を示す図である。 クライアントデバイスからホストデバイスへのデータ転送を実現するために有効なパケットの構造を示す図である。 MDDIリンクコントローラの使用、及びI型インタフェース用物理データリンク導線上でのホストとクライアント間で受け渡される信号の種類を示す図である。 MDDIリンクコントローラの使用、及び2型インタフェース、3型インタフェース、及び4型インタフェース用の物理データリンク導線上で、ホストとクライアントの間で受け渡される信号の種類を示す図である。 インタフェースプロトコルを実現するために使用されるフレームとサブフレームの構造を示す図である。 インタフェースプロトコルを実現するために使用されるパケットの一般構造を示す図である。 サブフレームヘッダパケットのフォーマットを示す図である。 フィラーパケットのフォーマット及びコンテンツを示す図である。 ビデオストリームパケットのフォーマットを示す図である。 図11で使用されるビデオデータフォーマット記述子のフォーマットとコンテンツを示す図である。 データのパックフォーマットとアンパックフォーマットの使用を示す図である。 音声ストリームパケットのフォーマットを示す図である。 データのためのバイト位置合わせされたPCMフォーマットとパックされたPCMフォーマットの使用を示す図である。 ユーザにより定義されるストリームパケットのフォーマットを示す図である。 カラーマップパケットのフォーマットを示す図である。 逆方向リンクカプセル化パケットのフォーマットを示す図である。 クライアント機能パケットのフォーマットを示す図である。 キーボードデータパケットのフォーマットを示す図である。 ポインティングデバイスデータパケットのフォーマットを示す図である。 リンクシャットダウンパケットのフォーマットを示す図である。 クライアント要求ステータスパケットのフォーマットを示す図である。 ビットブロック転送パケットのフォーマットを示す図である。 ビットマップ領域塗りつぶしパケットのフォーマットを示す図である。 ビットマップパターン塗りつぶしパケットのフォーマットを示す図である。 通信リンクデータチャネルパケットのフォーマットを示す図である。 ディスプレイ電力ステータスパケットのフォーマットを示す図である。 実行型ハンドオフパケットのフォーマットを示す図である。 順方向音声チャネルイネーブルパケットのフォーマットを示す図である。 逆方向音声サンプルレートパケットのフォーマットを示す図である。 デジタルコンテンツ保護オーバヘッドパケットのフォーマットを示す図である。 透明色イネーブルパケットのフォーマットを示す図である。 往復遅延測定パケットのフォーマットを示す図である。 往復遅延測定パケットの間のイベントのタイミングを示す図である。 本発明を実現するために有効なCRCジェネレータ及びチェッカのサンプルインプリメンテーションを示す図である。 データパケットを送信するときの図36の装置のCRC信号のタイミングを示す図である。 データパケットを受信するときの図36の装置のCRC信号のタイミングを示す図である。 競合のない典型的なサービス要求のための処理ステップを示す図である。 リンク起動を競合する、リンク再起動シーケンスが開始した後に確かめられた典型的なサービス要求の処理ステップを示す図である。 DATA−STB符号化を使用してどのようにしてデータシーケンスを送信できるかを示す図である。 ホストで入力データからDATA信号とSTB信号を発生させ、その後クライアントでデータを回復するために有効な回路網を示す図である。 一実施形態を実現するために有効なドライバと終端レジスタを示す図である。 ハイバーネーションに入るタイミングを示す図である。 ホストからサービスを提供するためにホストによって利用されるステップ及び信号レベルを示す図である。 ホストからサービスを保証するためにクライアントによって、及びこのようなサービスを提供するためにホストによって利用されるステップ及び信号レベルを示す図である。 Data0、他のデータライン(DataX)、及びストローブライン(Stb)での遷移間の相対的な間隔を示す図である。 ホストが、パケット転送後にホストドライバをディスエーブルするときに発生することがある応答の遅延の存在を示す図である。 ホストが、ホストドライバがパケットを転送できるようにイネーブルするときに発生することがある応答の遅延の存在を示す図である。 リーク電流分析を示す図である。 ホスト出力とクライアント出力とのイネーブル時間及びディスエーブル時間の相対的なタイミング関係と切り替え特性とを示す図である。 状態機械を使用して同期を実現できる信号処理ステップと条件の高水準図である。 MDDIを利用するシステムでの順方向経路と逆方向経路での信号処理について遭遇される典型的な遅延量を示す図である。 境界の往復遅延測定を示す図である。 逆方向リンクデータレート変化を示す図である。 改良された逆方向データサンプリングの例を示す図である。 逆方向速度除数対順方向リンクデータレートの値のグラフィック表現を示す図である。 インタフェースの動作で講じられるステップを示す図である。 インタフェースの動作で講じられるステップを示す図である。 インタフェース装置処理パケットの概要を示す図である。 順方向リンクパケットのフォーマットを示す図である。 I型リンクインタフェースの伝搬遅延及び歪みの典型的な値を示す図である。 インタフェースを通じた例示的な信号処理のためのI型リンクのData、Stb、及びクロック回復タイミングを示す図である。 2型、3型又は4型リンクインタフェースの伝搬遅延及び歪みのための典型的な値を示す図である。 理想的である早いデータ信号と、互いに関するMDDI_Stbのタイミングのための様々な可能性を示す図である。 理想的である遅いデータ信号と、互いに関するMDDI_Stbのタイミングのための様々な可能性を示す図である。 理想的である遅いデータ信号と、互いに関するMDDI_Stbのタイミングのための様々な可能性を示す図である。 I型/2型インタフェースと共に使用されるインタフェースピン割り当て例示的なコネクタを示す図である。 1型インタフェースのための考えられるMDDI_Data波形とMDDI_Stb波形を示す図である。 2型インタフェースのための考えられるMDDI_Data波形とMDDI_Stb波形を示す図である。 状態機械を使用して同期を実現できる代替の信号処理ステップと条件の高水準図を示す図である。 一連のクロックサイクルの間の相対的なタイミングと、多様な逆方向リンクパケットビットと除数値のタイミングとを示す図である。 例示的なエラーコード転送処理を示す図である。 エラーコード転送処理に有効な装置を示す図である。 コード過負荷のためのエラーコード転送処理を示す図である。 コード受信のためのエラーコード転送処理を示す図である。 ホストによって起動されるウェークアップのための処理ステップを示す図である。 クライアントによって起動されるウェークアップのための処理ステップを示す図である。 ホストと、競合状態のあるクライアントによって起動されるウェークアップのための処理ステップを示す図である。 要求VCP特徴パケットのフォーマットを示す図である。 VCP特徴応答パケットのフォーマットを示す図である。 VCP特徴応答パケットリストのフォーマットを示す図である。 セットVCP特徴応答パケットのフォーマットを示す図である。 要求有効パラメータパケットのフォーマットを示す図である。 有効パラメータ応答パケットのフォーマットを示す図である。 スケーリング済みのビデオストリーム機能パケットのフォーマットを示す図である。 スケーリング済みのビデオストリームセットアップパケットのフォーマットを示す図である。 スケーリング済みのビデオストリーム肯定応答パケットのフォーマットを示す図である。 スケーリング済みのビデオストリームパケットのフォーマットを示す図である。 特殊ステータス要求パケットのフォーマットを示す図である。 有効ステータス応答リストパケットのフォーマットを示す図である。 パーソナルディスプレイ機能パケットのフォーマットを示す図である。 フィールド曲率リストのポイントにおける要素を示す図である。 クライアントエラーレポートパケットのフォーマットを示す図である。 エラーレポートリストアイテムのフォーマットを示す図である。 クライアント識別パケットのフォーマットを示す図である。 代替表示機能パケットのフォーマットを示す図である。 レジスタアクセスパケットのフォーマットを示す図である。 可視アーチファクトを削減するための2つのディスプレイバッファの使用を示す図である。 可視アーチファクトを削減するための2つのディスプレイバッファの使用を示す図である。 可視アーチファクトを削減するための2つのディスプレイバッファの使用を示す図である。 画像転送より高速のディスプレイリフレッシュ付きの2つのバッファを示す図である。 画像転送より低速のディスプレイリフレッシュ付きの2つのバッファを示す図である。 画像転送よりはるかに高速のディスプレイリフレッシュ付きの2つのバッファを示す図である。 画像転送より高速のディスプレイリフレッシュ付きの3つのバッファを示す図である。 画像転送より低速のディスプレイリフレッシュ付きの3つのバッファを示す図である。 画像転送より高速のディスプレイリフレッシュ付きの1つのバッファを示す図である。 デイジーチェーンとハブを介するホスト−クライアント接続を示す図である。 ハブとデイジーチェーンの組み合わせを介して接続されるクライアントデバイスを示す図である。 カラーマップを示す図である。

Claims (33)

  1. 通信経路上、ホストデバイスとクライアントデバイスの間において、高速でデジタルプレゼンテーションデータを転送するためのデジタルデータインタフェースであって、
    前記通信経路上、ホストとクライアント間でデジタル制御データとデジタルプレゼンテーションデータの事前に選択されたセットを通信するための通信プロトコルを形成するために、共にリンクされる複数のパケット構造と、
    前記通信経路を通って前記クライアントに結合され、前記通信プロトコルを形成するパケットを生成、送信、及び受信し、デジタルプレゼンテーションデータを1つ又は複数のタイプのデータパケットに形成するように構成される、前記ホストデバイスに常駐する少なくとも1台のリンクコントローラと、
    を備える、デジタルデータインタフェース。
  2. 前記ホストとクライアントの間で通信され、異なる可変長を有する所定数の前記パケットを備える、所定の固定長を有する、メディアフレーム内で共にグループ化される前記パケットをさらに備える、請求項1に記載のインタフェース。
  3. 前記ホストからのパケットの転送の始めに配置されるサブフレームヘッダパケットをさらに備える、請求項1に記載のインタフェース。
  4. 具体的なクライアントに関連したハードウェアを低電力状態にするディスプレイ電力ステータスパケットを更に備えた請求項1に記載のインタフェース。
  5. 前記リンクコントローラはホストリンクコントローラであって、前記通信経路を通って前記ホストに結合される前記クライアントデバイスに常駐する少なくとも1台のクライアントリンクコントローラをさらに備え、前記通信プロトコルを形成するパケットを生成、送信及び受信し、デジタルプレゼンテーションデータを1つ又は複数のタイプのデータパケットに形成するように構成される、請求項1に記載のインタフェース。
  6. それぞれが既定の期間に並列でデータの異なる最大数のビットの転送を可能にする複数の転送モードであって、各モードが前記ホストリンクドライバとクライアントリンクドライバの間の交渉により選択可能である、複数の転送モードをさらに備え、
    前記転送モードはデータの転送中に前記モードの間で動的に調整可能である、
    請求項2に記載のインタフェース。
  7. 前記通信経路上、どちらかの方向でデータの転送を終了するために、前記ホストによる前記クライアントに対する伝送のためのリンクシャットダウンタイプパケットをさらに備える、請求項1に記載のインタフェース。
  8. 前記クライアントがハイバネーション状態から前記ホストをスリープ解除するための手段をさらに備える、請求項1に記載のインタフェース。
  9. ユーザへのプレゼンテーションのために通信経路上、ホストデバイスとクライアントデバイスの間において高速でデジタルデータを転送する方法であって、
    複数の所定のパケット構造の内の1つ又は複数を生成し、所定の通信プロトコルを形成するためにそれらを共にリンクすることと、
    前記通信プロトコルを使用して、前記通信経路上、前記ホストと前記クライアントデバイスの間で、デジタル制御データとデジタルプレゼンテーションデータの事前に選択されたセットを通信することと、
    前記通信プロトコルを形成するパケットを生成、送信及び受信し、1つ又は複数のタイプのデータパケットにデジタルプレゼンテーションデータを形成するように構成される、前記ホストデバイスに常駐する少なくとも1台のホストリンクコントローラを、前記通信経路を通して前記クライアントデバイスに結合することと、
    前記リンクコントローラを使用して前記通信経路上でパケットの形を取るデータを転送することと、
    を備える、方法。
  10. 前記ホストとクライアント間の通信のために、異なる可変長を有する所定数の前記パケットを備える、所定の固定長を有するメディアフレーム内で、前記パケットを共にグループ化することをさらに備える、請求項9に記載の方法。
  11. サブフレームヘッダタイプパケットを用いる前記ホストからのパケットの転送を開始することをさらに備える、請求項9に記載の方法。
  12. 前記通信経路を通して前記ホストデバイスに結合された前記クライアントデバイスに常駐する少なくとも1台のクライアントリンクコントローラを通じて前記通信プロトコルを形成するパケットを生成し、送信し、受信することをさらに備える、請求項9に記載の方法。
  13. ホストリンクドライバとクライアントリンクドライバの間で、それぞれが既定の期間において並列で異なる最大ビット数のデータの転送を可能にする、各方向での複数の転送モードの1つの使用を交渉することと、
    データの転送中、前記転送モードの間で動的に調整することと、
    をさらに備える、請求項12に記載の方法。
  14. 前記クライアントへの前記ホストによる伝送のために、リンクシャットダウンタイプのパケットを使用して前記通信経路においてどちらかの方向でデータの転送を終了することをさらに備える、請求項9に記載の方法。
  15. 前記クライアントとの通信によりハイバネーション状態から前記ホストをスリープ解除することをさらに備える、請求項9に記載の方法。
  16. 具体的なクライアントハードウェアを低電力状態にするディスプレイ電力ステータスパケットを生成することを更に備えた請求項9に記載の方法。
  17. ユーザへのプレゼンテーションのために通信経路上、ホストデバイスとクライアントデバイスの間において高速でデジタルデータを転送するための装置であって、
    複数の所定のパケット構造の1つ又は複数を生成し、所定の通信プロトコルを形成するためにそれらを共にリンクするために、及び前記通信プロトコルを使用して前記通信経路上、前記ホストデバイスと前記クライアントデバイスの間でデジタル制御データとデジタルプレゼンテーションデータの事前に選択されたセットを通信するために、前記ホストデバイス内に配置される少なくとも1台のホストリンクコントローラと、
    前記クライアントデバイスに配置され、前記通信経路を通して前記ホストリンクコントローラに結合される、少なくとも1台のクライアントコントローラと、
    前記通信プロトコルを形成するパケットを生成、送信及び受信し、デジタルプレゼンテーションデータを1つ又は複数のタイプのデータパケットに形成するように構成される、各リンクコントローラと、
    を備える、装置。
  18. 前記ホストコントローラは状態機械を備える、請求項17に記載の装置。
  19. 前記ホストコントローラは汎用信号プロセッサを備える、請求項17に記載の装置。
  20. 前記ホストからのパケットの転送の開始時にサブフレームヘッダタイプパケットをさらに備える、請求項17に記載の装置。
  21. 前記ホストコントローラは1台又は複数台の差動ラインドライバを備え、前記クライアントレシーバは前記通信経路に結合される1台又は複数台の差動ラインレシーバを備える、請求項17に記載の装置。
  22. 前記ホストリンクコントローラとクライアントリンクコントローラは、それぞれが既定の期間において、並列で異なる最大ビット数のデータの転送を可能にする、各方向での複数の転送モードの1つを使用するように構成され、データの転送中、前記転送モードの間で動的に調整することができる、請求項17に記載の装置。
  23. 前記ホストコントローラは、前記通信経路上、どちらかの方向でデータの転送を終了するために、前記クライアント手段にリンクシャットダウンタイプのパケットを送信するように構成される、請求項17に記載の装置。
  24. 前記ホストコントローラは、具体的なディスプレイコントローラハードウェアを、低電力状態にするディスプレイ電力ステータスパケットを生成するように構成される請求項17に記載の装置。
  25. ユーザに対するプレゼンテーションのために通信経路上、ホストデバイスとクライアントデバイスの間において、高速でデジタルデータを転送するための電子システムでの使用のために、
    アプリケーションプログラムを前記コンピュータシステム上で実行させるために、前記媒体で具現化されるコンピュータ読み取り可能プログラムコード手段を有するコンピュータ使用可能な媒体を備える、コンピュータプログラム製品であって、前記コンピュータ読み取り可能プログラムコード手段は、
    コンピュータシステムに複数の所定のパケット構造の1つ又は複数を生成させ、所定の通信プロトコルを形成するために、それらを共にリンクさせるためのコンピュータ読み取り可能第1プログラムコード手段と、
    前記コンピュータシステムに、前記通信プロトコルを使用して前記通信経路上、前記ホストデバイスと前記クライアントデバイスの間で、デジタル制御データとデジタルプレゼンテーションデータの事前に選択されたセットを通信させるための、コンピュータ読み取り可能第2プログラムコード手段と、
    前記コンピュータシステムに、前記通信経路を通して、前記ホストデバイスに配置される少なくとも1台のホストリンクコントローラを、前記クライアントデバイスに配置される少なくとも1台のクライアントコントローラに結合させるようにするための、コンピュータ読み取り可能第3プログラムコード手段であって、前記リンクコントローラは、前記通信プロトコルを形成するパケットを生成、送信及び受信し、1つ又は複数のタイプのデータパケットにデジタルプレゼンテーションデータを形成するように構成される、コンピュータ読み取り可能第3プログラムコード手段と、
    前記リンクコントローラを使用して前記通信経路上、パケットの形をしたデータをコンピュータシステムに転送させるためのコンピュータ読み取り可能第4プログラムコード手段と、
    を備える、コンピュータプログラム製品。
  26. 前記コンピュータシステムに対して、予め定義されたパケット構造を生成させ、それらを共に接続して予め定義された通信プロトコルを生成させるコンピュータ読み取り可能プログラムコード手段を備えた請求項25に記載のコンピュータプログラム製品。
  27. ユーザに対するプレゼンテーションのために、通信経路上、ホストデバイスとクライアントデバイスの間において、高速でデジタルデータを転送するための装置であって、
    複数の所定のパケット構造の1つ又は複数を生成し、所定の通信プロトコルを形成するためにそれらを共にリンクするための手段と、
    前記通信プロトコルを使用して前記通信経路で前記ホストデバイスと前記クライアントデバイスの間で、事前に選択されたデジタル制御データ及びデジタルプレゼンテーションデータを通信するための手段と、
    前記ホストとクライアントのそれぞれに1つ、それぞれが前記通信プロトコルを形成するパケットを生成、送信及び受信し、デジタルプレゼンテーションデータを1つ又は複数のタイプのデータパケットに形成するように構成される、少なくとも2台のリンクコントローラを、前記通信経路を通して共に結合するための手段と、
    前記リンクコントローラを使用して前記通信経路上、パケットの形をとるデータを転送するための手段と、
    を備える、装置。
  28. サブフレームヘッダタイプパケットを用いて、前記ホストからパケットの転送を開始するための手段をさらに備える、請求項27に記載の装置。
  29. 具体的なハードウェアを、低電力状態にするように構成されたディスプレイ電力ステータスパケットを生成することを備える手段を更に備えた請求項27に記載の装置。
  30. 前記クライアントが前記インタフェースを通してどのようなタイプのデータとデータレートに対処できるのかを決定するために、ホストリンクコントローラによってクライアントから表示機能情報を要求するための手段をさらに備える、請求項27に記載の装置。
  31. 通信経路上、ホストデバイスとクライアントデバイスの間において、高速でデジタルデータを転送するための電子システムで使用するためのプロセッサであって、複数の所定のパケット構造の1つ又は複数を生成し、所定の通信プロトコルを形成するためにそれらを共にリンクし、デジタルプレゼンテーションデータを1つ又は複数のタイプのデータパケットに形成し、前記通信プロトコルを使用して前記通信経路上、前記ホストデバイスと前記クライアントデバイスの間で、デジタル制御データとデジタルプレゼンテーションデータの事前に選択されたセットを通信し、前記通信経路上でパケットの形をしたデータを転送するように構成された、プロセッサ。
  32. 通信経路上、ホストデバイスとクライアントデバイスの間において、高速でデジタルデータを転送する電子システム内で同期を取る際に使用するための状態機械であって、少なくとも1つの非同期フレーム状態同期状態、少なくとも2つの同期状態獲得同期状態、及び少なくとも3つの同期中状態同期状態を有するように構成される、状態機械。
  33. 通信経路上、ホストデバイスとクライアントデバイスの間において、高速でデジタルデータを転送する電子システム内で同期を取る際に使用するための状態機械であって、少なくとも1つの同期状態獲得動機状態と、少なくとも2つの同期中状態同期状態とを有するように構成される、状態機械。
JP2007504084A 2004-03-17 2005-03-17 高速データレートインタフェース装置及び方法 Expired - Fee Related JP4519903B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US55430904P 2004-03-17 2004-03-17
US55634504P 2004-03-24 2004-03-24
PCT/US2005/008832 WO2005091593A1 (en) 2004-03-17 2005-03-17 High data rate interface apparatus and method

Publications (3)

Publication Number Publication Date
JP2007534232A true JP2007534232A (ja) 2007-11-22
JP2007534232A5 JP2007534232A5 (ja) 2008-04-03
JP4519903B2 JP4519903B2 (ja) 2010-08-04

Family

ID=34963557

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007504084A Expired - Fee Related JP4519903B2 (ja) 2004-03-17 2005-03-17 高速データレートインタフェース装置及び方法

Country Status (12)

Country Link
US (1) US8705521B2 (ja)
EP (1) EP1735986B1 (ja)
JP (1) JP4519903B2 (ja)
KR (2) KR101245962B1 (ja)
AU (1) AU2005223960B2 (ja)
BR (1) BRPI0508923A (ja)
CA (1) CA2560067C (ja)
IL (1) IL178132A0 (ja)
MX (1) MXPA06010647A (ja)
RU (1) RU2355121C2 (ja)
TW (1) TWI384811B (ja)
WO (1) WO2005091593A1 (ja)

Families Citing this family (64)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6760772B2 (en) 2000-12-15 2004-07-06 Qualcomm, Inc. Generating and implementing a communication protocol and interface for high data rate signal transfer
US8812706B1 (en) 2001-09-06 2014-08-19 Qualcomm Incorporated Method and apparatus for compensating for mismatched delays in signals of a mobile display interface (MDDI) system
CN101938493B (zh) 2003-06-02 2013-10-16 高通股份有限公司 生成并实施一用于更高数据率的讯号协议和接口
CN101194482B (zh) 2003-08-13 2015-11-25 高通股份有限公司 一种使通信系统中的主机与客户机间读写至少一个寄存器的方法与系统
TWI345404B (en) 2003-09-10 2011-07-11 Qualcomm Inc High data rate interface
CN1894931A (zh) 2003-10-15 2007-01-10 高通股份有限公司 高数据速率接口
AU2004307162A1 (en) 2003-10-29 2005-05-12 Qualcomm Incorporated High data rate interface
EP2242231A1 (en) 2003-11-12 2010-10-20 Qualcomm Incorporated High data rate interface with improved link control
WO2005053272A1 (en) 2003-11-25 2005-06-09 Qualcomm Incorporated High data rate interface with improved link synchronization
EP2247068B1 (en) 2003-12-08 2013-09-25 Qualcomm Incorporated High data rate interface with improved link synchronization
AU2003292275A1 (en) * 2003-12-19 2005-07-05 Nokia Corporation Selection of radio resources in a wireless communication device
BRPI0508582A (pt) 2004-03-10 2007-08-14 Qualcomm Inc equipamento e método de interface de alta taxa de dados
WO2005091593A1 (en) 2004-03-17 2005-09-29 Qualcomm Incorporated High data rate interface apparatus and method
US8645566B2 (en) 2004-03-24 2014-02-04 Qualcomm Incorporated High data rate interface apparatus and method
US7103512B2 (en) * 2004-05-26 2006-09-05 Microchip Technology Incorporated USB eye pattern test mode
US8650304B2 (en) 2004-06-04 2014-02-11 Qualcomm Incorporated Determining a pre skew and post skew calibration data rate in a mobile display digital interface (MDDI) communication system
ATE518343T1 (de) 2004-06-04 2011-08-15 Qualcomm Inc Schnittstellenvorrichtung und -verfahren für hohe datenraten
US8667363B2 (en) 2004-11-24 2014-03-04 Qualcomm Incorporated Systems and methods for implementing cyclic redundancy checks
US8723705B2 (en) 2004-11-24 2014-05-13 Qualcomm Incorporated Low output skew double data rate serial encoder
US8873584B2 (en) 2004-11-24 2014-10-28 Qualcomm Incorporated Digital data interface device
US8539119B2 (en) 2004-11-24 2013-09-17 Qualcomm Incorporated Methods and apparatus for exchanging messages having a digital data interface device message format
US8692838B2 (en) 2004-11-24 2014-04-08 Qualcomm Incorporated Methods and systems for updating a buffer
US8699330B2 (en) 2004-11-24 2014-04-15 Qualcomm Incorporated Systems and methods for digital data transmission rate control
EP1871075B1 (en) * 2004-12-24 2015-03-04 IZUTSU, Masahiro Mobile information communication apparatus, connection unit for mobile information communication apparatus, and external input/output unit for mobile information communication apparatus
KR100685664B1 (ko) * 2005-08-12 2007-02-26 삼성전자주식회사 호스트 및 클라이언트로 구성된 데이터 통신 시스템 및데이터 통신 시스템의 작동 방법
US8730069B2 (en) 2005-11-23 2014-05-20 Qualcomm Incorporated Double data rate serial encoder
US8692839B2 (en) 2005-11-23 2014-04-08 Qualcomm Incorporated Methods and systems for updating a buffer
US7643430B2 (en) * 2005-11-30 2010-01-05 Cisco Technology, Inc. Methods and apparatus for determining reverse path delay
KR100917889B1 (ko) * 2006-11-01 2009-09-16 삼성전자주식회사 무선 통신 장치 및 방법
KR101109904B1 (ko) * 2007-05-08 2012-02-06 콸콤 인코포레이티드 모바일 디스플레이 디지털 인터페이스를 위한 패킷 구조
US8356331B2 (en) * 2007-05-08 2013-01-15 Qualcomm Incorporated Packet structure for a mobile display digital interface
US8031626B2 (en) * 2007-11-13 2011-10-04 Qualcomm Incorporated Packet structure for a mobile display digital interface
US8850070B2 (en) * 2008-03-07 2014-09-30 Citrix Systems, Inc. Systems and methods for content injection
US8855062B2 (en) 2009-05-28 2014-10-07 Qualcomm Incorporated Dynamic selection of subframe formats in a wireless network
KR101451132B1 (ko) * 2010-01-29 2014-10-15 삼성테크윈 주식회사 통신 라인의 종단이 설정되는 감시 시스템
EP2611237B1 (en) 2010-08-26 2019-05-22 Nec Corporation Communication system comprising a femto base station and an information processing device for controlling user equipment functions
PL3352380T3 (pl) * 2010-10-04 2019-11-29 Samsung Electronics Co Ltd Sposób i urządzenie do wysyłania i odbierania bitmapy ograniczenia podzbioru zestawu kodowego
US8774010B2 (en) 2010-11-02 2014-07-08 Cisco Technology, Inc. System and method for providing proactive fault monitoring in a network environment
US8559341B2 (en) 2010-11-08 2013-10-15 Cisco Technology, Inc. System and method for providing a loop free topology in a network environment
JP2014508995A (ja) * 2011-01-21 2014-04-10 クゥアルコム・インコーポレイテッド ワイヤレスディスプレイのためのユーザ入力バックチャネル
US20130013318A1 (en) 2011-01-21 2013-01-10 Qualcomm Incorporated User input back channel for wireless displays
US9787725B2 (en) 2011-01-21 2017-10-10 Qualcomm Incorporated User input back channel for wireless displays
US9413803B2 (en) 2011-01-21 2016-08-09 Qualcomm Incorporated User input back channel for wireless displays
US10135900B2 (en) 2011-01-21 2018-11-20 Qualcomm Incorporated User input back channel for wireless displays
US8982733B2 (en) 2011-03-04 2015-03-17 Cisco Technology, Inc. System and method for managing topology changes in a network environment
US8670326B1 (en) 2011-03-31 2014-03-11 Cisco Technology, Inc. System and method for probing multiple paths in a network environment
US8724517B1 (en) 2011-06-02 2014-05-13 Cisco Technology, Inc. System and method for managing network traffic disruption
US8830875B1 (en) 2011-06-15 2014-09-09 Cisco Technology, Inc. System and method for providing a loop free topology in a network environment
JP5933601B2 (ja) * 2012-02-02 2016-06-15 三菱電機株式会社 表示装置
US8938551B2 (en) * 2012-04-10 2015-01-20 Intel Mobile Communications GmbH Data processing device
US9450846B1 (en) 2012-10-17 2016-09-20 Cisco Technology, Inc. System and method for tracking packets in a network environment
US9565637B2 (en) 2013-03-14 2017-02-07 T-Mobile Usa, Inc. High power channel state notification for mobile applications
RU2544786C2 (ru) * 2013-06-03 2015-03-20 Государственное казенное образовательное учреждение высшего профессионального образования Академия Федеральной службы охраны Российской Федерации (Академия ФСО России) Способ формирования защищенной системы связи, интегрированной с единой сетью электросвязи в условиях внешних деструктивных воздействий
US10635296B2 (en) 2014-09-24 2020-04-28 Microsoft Technology Licensing, Llc Partitioned application presentation across devices
US9769227B2 (en) * 2014-09-24 2017-09-19 Microsoft Technology Licensing, Llc Presentation of computing environment on multiple devices
US10448111B2 (en) 2014-09-24 2019-10-15 Microsoft Technology Licensing, Llc Content projection
US10025684B2 (en) 2014-09-24 2018-07-17 Microsoft Technology Licensing, Llc Lending target device resources to host device computing environment
KR102237026B1 (ko) * 2014-11-05 2021-04-06 주식회사 실리콘웍스 디스플레이 장치
CN106897239A (zh) * 2015-12-21 2017-06-27 小米科技有限责任公司 状态切换方法及装置
EP3491879B1 (en) * 2016-07-26 2021-08-25 IPCom GmbH & Co. KG Connection of wearable devices
US10114782B2 (en) * 2016-09-27 2018-10-30 Nxp B.V. USB type C dual-role-port unattached duty cycle randomization
CN111950222B (zh) * 2019-04-29 2024-05-24 瑞昱半导体股份有限公司 使用模拟软件产生电路布局的方法
US20220248258A1 (en) * 2021-02-03 2022-08-04 Samsung Electronics Co., Ltd. Eht release 2 device indication
US11265358B1 (en) * 2021-06-22 2022-03-01 Cabin Management Solutions, Llc Audio video over internet protocol (AVoIP) communication system

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06124147A (ja) * 1992-10-13 1994-05-06 Sanyo Electric Co Ltd 情報処理装置
JPH10312370A (ja) * 1997-05-12 1998-11-24 Hitachi Ltd 省電力機能を有するネットワークシステム
JP2003009035A (ja) * 2001-03-26 2003-01-10 Matsushita Electric Ind Co Ltd 電源制御装置
JP2003198550A (ja) * 2001-12-25 2003-07-11 Matsushita Electric Ind Co Ltd 通信装置及び通信方法
JP2004007356A (ja) * 2002-04-23 2004-01-08 Sony Corp 情報処理システム、情報処理装置および方法、プログラム格納媒体、並びにプログラム
JP2004046324A (ja) * 2002-07-09 2004-02-12 Mitsubishi Electric Corp 待機モード付情報処理装置およびその待機モード開始方法と待機モード解除方法

Family Cites Families (458)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7274652B1 (en) 2000-06-02 2007-09-25 Conexant, Inc. Dual packet configuration for wireless communications
US3594304A (en) 1970-04-13 1971-07-20 Sun Oil Co Thermal liquefaction of coal
US4042783A (en) 1976-08-11 1977-08-16 International Business Machines Corporation Method and apparatus for byte and frame synchronization on a loop system coupling a CPU channel to bulk storage devices
US4393444A (en) 1980-11-06 1983-07-12 Rca Corporation Memory addressing circuit for converting sequential input data to interleaved output data sequence using multiple memories
US4363123A (en) 1980-12-01 1982-12-07 Northern Telecom Limited Method of and apparatus for monitoring digital transmission systems in which line transmission errors are detected
JPS57136833A (en) * 1981-02-17 1982-08-24 Sony Corp Time-division multiplex data transmitting method
US4660096A (en) * 1984-12-11 1987-04-21 Rca Corporation Dividing high-resolution-camera video signal response into sub-image blocks individually raster scanned
DE3531809A1 (de) * 1985-09-06 1987-03-26 Kraftwerk Union Ag Katalysatormaterial zur reduktion von stickoxiden
US4769761A (en) 1986-10-09 1988-09-06 International Business Machines Corporation Apparatus and method for isolating and predicting errors in a local area network
JPS63226762A (ja) 1987-03-16 1988-09-21 Hitachi Ltd デ−タ処理方式
US4764805A (en) 1987-06-02 1988-08-16 Eastman Kodak Company Image transmission system with line averaging preview mode using two-pass block-edge interpolation
US4821296A (en) * 1987-08-26 1989-04-11 Bell Communications Research, Inc. Digital phase aligner with outrigger sampling
US5227783A (en) 1987-10-13 1993-07-13 The Regents Of New Mexico State University Telemetry apparatus and method with digital to analog converter internally integrated within C.P.U.
JPH0727571B2 (ja) 1987-10-26 1995-03-29 テクトロニックス・インコーポレイテッド ラスタ走査表示装置及び図形データ転送方法
US5155590A (en) 1990-03-20 1992-10-13 Scientific-Atlanta, Inc. System for data channel level control
US4891805A (en) * 1988-06-13 1990-01-02 Racal Data Communications Inc. Multiplexer with dynamic bandwidth allocation
US5167035A (en) 1988-09-08 1992-11-24 Digital Equipment Corporation Transferring messages between nodes in a network
US5136717A (en) 1988-11-23 1992-08-04 Flavors Technology Inc. Realtime systolic, multiple-instruction, single-data parallel computer system
US5079693A (en) * 1989-02-28 1992-01-07 Integrated Device Technology, Inc. Bidirectional FIFO buffer having reread and rewrite means
US6014705A (en) * 1991-10-01 2000-01-11 Intermec Ip Corp. Modular portable data processing terminal having a higher layer and lower layer partitioned communication protocol stack for use in a radio frequency communications network
US5224213A (en) 1989-09-05 1993-06-29 International Business Machines Corporation Ping-pong data buffer for transferring data from one data bus to another data bus
US5495482A (en) 1989-09-29 1996-02-27 Motorola Inc. Packet transmission system and method utilizing both a data bus and dedicated control lines
US5543939A (en) 1989-12-28 1996-08-06 Massachusetts Institute Of Technology Video telephone systems
US5138616A (en) 1990-03-19 1992-08-11 The United States Of America As Represented By The Secretary Of The Army Continuous on-line link error rate detector utilizing the frame bit error rate
JPH0465711A (ja) 1990-07-05 1992-03-02 Nippon Avionics Co Ltd 表示装置の表示制御方式
US5111455A (en) 1990-08-24 1992-05-05 Avantek, Inc. Interleaved time-division multiplexor with phase-compensated frequency doublers
US5131012A (en) 1990-09-18 1992-07-14 At&T Bell Laboratories Synchronization for cylic redundancy check based, broadband communications network
GB2249460B (en) 1990-09-19 1994-06-29 Intel Corp Network providing common access to dissimilar hardware interfaces
GB2250668B (en) 1990-11-21 1994-07-20 Apple Computer Tear-free updates of computer graphical output displays
IL100213A (en) 1990-12-07 1995-03-30 Qualcomm Inc Mikrata Kedma phone system and its antenna distribution system
US5359595A (en) 1991-01-09 1994-10-25 Rockwell International Corporation Skywave adaptable network transceiver apparatus and method using a stable probe and traffic protocol
US5345542A (en) 1991-06-27 1994-09-06 At&T Bell Laboratories Proportional replication mapping system
US5231636A (en) 1991-09-13 1993-07-27 National Semiconductor Corporation Asynchronous glitchless digital MUX
EP0606396B1 (en) * 1991-10-01 2002-06-12 Norand Corporation A radio frequency local area network
US5396636A (en) * 1991-10-21 1995-03-07 International Business Machines Corporation Remote power control via data link
US5751445A (en) 1991-11-11 1998-05-12 Canon Kk Image transmission system and terminal device
CA2064541C (en) 1992-03-31 1998-09-15 Thomas A. Gray Cycling error count for link maintenance
US5331642A (en) 1992-09-01 1994-07-19 International Business Machines Corporation Management of FDDI physical link errors
JP3305769B2 (ja) 1992-09-18 2002-07-24 株式会社東芝 通信装置
GB9222282D0 (en) * 1992-10-22 1992-12-09 Hewlett Packard Co Monitoring network status
US5513185A (en) * 1992-11-23 1996-04-30 At&T Corp. Method and apparatus for transmission link error rate monitoring
US5867501A (en) * 1992-12-17 1999-02-02 Tandem Computers Incorporated Encoding for communicating data and commands
US5619650A (en) * 1992-12-31 1997-04-08 International Business Machines Corporation Network processor for transforming a message transported from an I/O channel to a network by adding a message identifier and then converting the message
GB9304638D0 (en) * 1993-03-06 1993-04-21 Ncr Int Inc Wireless data communication system having power saving function
JPH06332664A (ja) 1993-03-23 1994-12-02 Toshiba Corp 表示制御システム
US5418452A (en) 1993-03-25 1995-05-23 Fujitsu Limited Apparatus for testing integrated circuits using time division multiplexing
WO1994024200A1 (en) 1993-04-16 1994-10-27 Akzo Nobel N.V. Liquid stabilizer comprising metal soap and solubilized metal perchlorate
JP3197679B2 (ja) 1993-04-30 2001-08-13 富士写真フイルム株式会社 写真撮影システムおよび方法
US5420858A (en) 1993-05-05 1995-05-30 Synoptics Communications, Inc. Method and apparatus for communications from a non-ATM communication medium to an ATM communication medium
US5519830A (en) 1993-06-10 1996-05-21 Adc Telecommunications, Inc. Point-to-multipoint performance monitoring and failure isolation system
JP2768621B2 (ja) 1993-06-25 1998-06-25 沖電気工業株式会社 分散送信される畳み込み符号の復号装置
US5477534A (en) 1993-07-30 1995-12-19 Kyocera Corporation Acoustic echo canceller
US5430486A (en) 1993-08-17 1995-07-04 Rgb Technology High resolution video image transmission and storage
US5426694A (en) 1993-10-08 1995-06-20 Excel, Inc. Telecommunication switch having programmable network protocols and communications services
US5490247A (en) 1993-11-24 1996-02-06 Intel Corporation Video subsystem for computer-based conferencing system
US5510832A (en) * 1993-12-01 1996-04-23 Medi-Vision Technologies, Inc. Synthesized stereoscopic imaging system and method
US5583562A (en) * 1993-12-03 1996-12-10 Scientific-Atlanta, Inc. System and method for transmitting a plurality of digital services including imaging services
US5565957A (en) 1993-12-27 1996-10-15 Nikon Corporation Camera
US5724536A (en) * 1994-01-04 1998-03-03 Intel Corporation Method and apparatus for blocking execution of and storing load operations during their execution
US5844606A (en) 1994-03-03 1998-12-01 Fuji Photo Film Co., Ltd. Videocamera having a multiconnector connectable to a variety of accessories
JP2790034B2 (ja) 1994-03-28 1998-08-27 日本電気株式会社 非運用系メモリ更新方式
US5483185A (en) * 1994-06-09 1996-01-09 Intel Corporation Method and apparatus for dynamically switching between asynchronous signals without generating glitches
JP3329076B2 (ja) 1994-06-27 2002-09-30 ソニー株式会社 ディジタル信号伝送方法、ディジタル信号伝送装置、ディジタル信号受信方法及びディジタル信号受信装置
US5560022A (en) * 1994-07-19 1996-09-24 Intel Corporation Power management coordinator system and interface
US5748891A (en) 1994-07-22 1998-05-05 Aether Wire & Location Spread spectrum localizers
EP0772937B1 (de) 1994-07-25 1998-10-28 Siemens Aktiengesellschaft Verfahren zum verbindungsaufbau und zum steuern der bildtelefonkommunikation
US5664948A (en) 1994-07-29 1997-09-09 Seiko Communications Holding N.V. Delivery of data including preloaded advertising data
US5733131A (en) * 1994-07-29 1998-03-31 Seiko Communications Holding N.V. Education and entertainment device with dynamic configuration and operation
JP3592376B2 (ja) 1994-08-10 2004-11-24 株式会社アドバンテスト 時間間隔測定装置
US5816921A (en) 1994-09-27 1998-10-06 Sega Enterprises, Ltd. Data transferring device and video game apparatus using the same
GB2296123B (en) * 1994-12-13 1998-08-12 Ibm Midi playback system
US5745364A (en) * 1994-12-28 1998-04-28 Nec Corporation Method of producing semiconductor wafer
US5559459A (en) 1994-12-29 1996-09-24 Stratus Computer, Inc. Clock signal generation arrangement including digital noise reduction circuit for reducing noise in a digital clocking signal
FR2729528A1 (fr) 1995-01-13 1996-07-19 Suisse Electronique Microtech Circuit de multiplexage
GB2298109B (en) 1995-02-14 1999-09-01 Nokia Mobile Phones Ltd Data interface
US5530704A (en) 1995-02-16 1996-06-25 Motorola, Inc. Method and apparatus for synchronizing radio ports in a commnuication system
US5646947A (en) 1995-03-27 1997-07-08 Westinghouse Electric Corporation Mobile telephone single channel per carrier superframe lock subsystem
US6117681A (en) 1995-03-29 2000-09-12 Bavarian Nordic Research Inst. A/S Pseudotyped retroviral particles
KR100411372B1 (ko) 1995-04-11 2004-05-06 마츠시타 덴끼 산교 가부시키가이샤 비디오정보조정장치,비디오정보송신장치및비디오정보수신장치
US5521907A (en) 1995-04-25 1996-05-28 Visual Networks, Inc. Method and apparatus for non-intrusive measurement of round trip delay in communications networks
US5963564A (en) 1995-06-13 1999-10-05 Telefonaktiebolaget Lm Ericsson Synchronizing the transmission of data via a two-way link
SE506540C2 (sv) * 1995-06-13 1998-01-12 Ericsson Telefon Ab L M Synkronisering av överföring av data via en dubbelriktad länk
JPH0923243A (ja) 1995-07-10 1997-01-21 Hitachi Ltd 電子紙面情報配信システム
WO1997003508A1 (fr) 1995-07-13 1997-01-30 Sony Corporation Procede, appareil et systeme de transmission de donnees
JPH0936871A (ja) 1995-07-17 1997-02-07 Sony Corp データ伝送システムおよびデータ伝送方法
US5604450A (en) * 1995-07-27 1997-02-18 Intel Corporation High speed bidirectional signaling scheme
JPH0955667A (ja) * 1995-08-10 1997-02-25 Mitsubishi Electric Corp マルチプレクサ,及びデマルチプレクサ
US5742840A (en) 1995-08-16 1998-04-21 Microunity Systems Engineering, Inc. General purpose, multiple precision parallel operation, programmable media processor
JPH11503258A (ja) 1995-09-19 1999-03-23 マイクロチップ テクノロジー インコーポレイテッド ディジタル的にプログラム可能な閾値を有するマイクロコントローラ起立機能
US5748642A (en) 1995-09-25 1998-05-05 Credence Systems Corporation Parallel processing integrated circuit tester
US5732352A (en) * 1995-09-29 1998-03-24 Motorola, Inc. Method and apparatus for performing handoff in a wireless communication system
US5550489A (en) 1995-09-29 1996-08-27 Quantum Corporation Secondary clock source for low power, fast response clocking
US5818255A (en) 1995-09-29 1998-10-06 Xilinx, Inc. Method and circuit for using a function generator of a programmable logic device to implement carry logic functions
US5751951A (en) 1995-10-30 1998-05-12 Mitsubishi Electric Information Technology Center America, Inc. Network interface
EP0772119A3 (en) 1995-10-31 1997-12-29 Cirrus Logic, Inc. Automatic graphics operation
US5958006A (en) 1995-11-13 1999-09-28 Motorola, Inc. Method and apparatus for communicating summarized data
US7003796B1 (en) * 1995-11-22 2006-02-21 Samsung Information Systems America Method and apparatus for recovering data stream clock
US5790551A (en) 1995-11-28 1998-08-04 At&T Wireless Services Inc. Packet data transmission using dynamic channel assignment
US5844918A (en) 1995-11-28 1998-12-01 Sanyo Electric Co., Ltd. Digital transmission/receiving method, digital communications method, and data receiving apparatus
US6865610B2 (en) * 1995-12-08 2005-03-08 Microsoft Corporation Wire protocol for a media server system
EP0781068A1 (en) 1995-12-20 1997-06-25 International Business Machines Corporation Method and system for adaptive bandwidth allocation in a high speed data network
JP3427149B2 (ja) 1996-01-26 2003-07-14 三菱電機株式会社 符号化信号の復号回路及びその同期制御方法, 同期検出回路及び同期検出方法
US5903281A (en) 1996-03-07 1999-05-11 Powertv, Inc. List controlled video operations
US6243596B1 (en) 1996-04-10 2001-06-05 Lextron Systems, Inc. Method and apparatus for modifying and integrating a cellular phone with the capability to access and browse the internet
US5815507A (en) 1996-04-15 1998-09-29 Motorola, Inc. Error detector circuit for digital receiver using variable threshold based on signal quality
US6130602A (en) 1996-05-13 2000-10-10 Micron Technology, Inc. Radio frequency data communications device
JPH09307457A (ja) 1996-05-14 1997-11-28 Sony Corp パラレルシリアル変換回路
US5982362A (en) 1996-05-30 1999-11-09 Control Technology Corporation Video interface architecture for programmable industrial control systems
US5983261A (en) 1996-07-01 1999-11-09 Apple Computer, Inc. Method and apparatus for allocating bandwidth in teleconferencing applications using bandwidth control
GB9614561D0 (en) 1996-07-11 1996-09-04 4Links Ltd Communication system with improved code
US6298387B1 (en) 1996-07-12 2001-10-02 Philips Electronics North America Corp System for detecting a data packet in a bitstream by storing data from the bitstream in a buffer and comparing data at different locations in the buffer to predetermined data
KR100221028B1 (ko) 1996-07-23 1999-09-15 윤종용 그래픽 가속기 및 이를 이용한 메모리 프리패치 방법
US6185601B1 (en) * 1996-08-02 2001-02-06 Hewlett-Packard Company Dynamic load balancing of a network of client and server computers
US6886035B2 (en) 1996-08-02 2005-04-26 Hewlett-Packard Development Company, L.P. Dynamic load balancing of a network of client and server computer
US5969750A (en) 1996-09-04 1999-10-19 Winbcnd Electronics Corporation Moving picture camera with universal serial bus interface
CA2214743C (en) 1996-09-20 2002-03-05 Ntt Mobile Communications Network Inc. A frame synchronization circuit and communications system
US5990852A (en) 1996-10-31 1999-11-23 Fujitsu Limited Display screen duplication system and method
US5864546A (en) * 1996-11-05 1999-01-26 Worldspace International Network, Inc. System for formatting broadcast data for satellite transmission and radio reception
US6308239B1 (en) 1996-11-07 2001-10-23 Hitachi, Ltd. Interface switching apparatus and switching control method
US6078361A (en) 1996-11-18 2000-06-20 Sage, Inc Video adapter circuit for conversion of an analog video signal to a digital display image
US6002709A (en) 1996-11-21 1999-12-14 Dsp Group, Inc. Verification of PN synchronization in a direct-sequence spread-spectrum digital communications system
KR100211918B1 (ko) 1996-11-30 1999-08-02 김영환 비동기식전송모드셀 경계 식별장치
US5862160A (en) * 1996-12-31 1999-01-19 Ericsson, Inc. Secondary channel for communication networks
US5995512A (en) 1997-01-17 1999-11-30 Delco Electronics Corporation High speed multimedia data network
US6064649A (en) 1997-01-31 2000-05-16 Nec Usa, Inc. Network interface card for wireless asynchronous transfer mode networks
US6081513A (en) 1997-02-10 2000-06-27 At&T Corp. Providing multimedia conferencing services over a wide area network interconnecting nonguaranteed quality of services LANs
EP0859326A3 (en) 1997-02-14 1999-05-12 Canon Kabushiki Kaisha Data transmission apparatus, system and method, and image processing apparatus
US6359923B1 (en) 1997-12-18 2002-03-19 At&T Wireless Services, Inc. Highly bandwidth efficient communications
US6584144B2 (en) 1997-02-24 2003-06-24 At&T Wireless Services, Inc. Vertical adaptive antenna array for a discrete multitone spread spectrum communications system
DE19733005B4 (de) 1997-03-12 2007-06-21 Storz Endoskop Gmbh Einrichtung zur zentralen Überwachung und/oder Steuerung wenigstens eines Gerätes
US6480521B1 (en) 1997-03-26 2002-11-12 Qualcomm Incorporated Method and apparatus for transmitting high speed data in a spread spectrum communications system
US7143177B1 (en) 1997-03-31 2006-11-28 West Corporation Providing a presentation on a network having a plurality of synchronized media types
US5963557A (en) 1997-04-11 1999-10-05 Eng; John W. High capacity reservation multiple access network with multiple shared unidirectional paths
US6405111B2 (en) 1997-05-16 2002-06-11 Snap-On Technologies, Inc. System and method for distributed computer automotive service equipment
US5867510A (en) * 1997-05-30 1999-02-02 Motorola, Inc. Method of and apparatus for decoding and processing messages
JP3143079B2 (ja) 1997-05-30 2001-03-07 松下電器産業株式会社 辞書索引作成装置と文書検索装置
KR100550190B1 (ko) * 1997-06-03 2006-04-21 소니 가부시끼 가이샤 휴대용정보처리장치의제어방법,및휴대용정보처리장치
US6236647B1 (en) 1998-02-24 2001-05-22 Tantivy Communications, Inc. Dynamic frame size adjustment and selective reject on a multi-link channel to improve effective throughput and bit error rate
US6314479B1 (en) 1997-08-04 2001-11-06 Compaq Computer Corporation Universal multi-pin plug and display connector for standardizing signals transmitted between a computer and a display for a PC theatre interconnectivity system
WO1999010719A1 (en) 1997-08-29 1999-03-04 The Regents Of The University Of California Method and apparatus for hybrid coding of speech at 4kbps
US6288739B1 (en) 1997-09-05 2001-09-11 Intelect Systems Corporation Distributed video communications system
US6574661B1 (en) 1997-09-26 2003-06-03 Mci Communications Corporation Integrated proxy interface for web based telecommunication toll-free network management using a network manager for downloading a call routing tree to client
JP4426093B2 (ja) 1997-10-14 2010-03-03 サイプレス セミコンダクター コーポレイション ディジタル無線周波数トランシーバー
US6894994B1 (en) 1997-11-03 2005-05-17 Qualcomm Incorporated High data rate wireless packet data communications system
US6574211B2 (en) 1997-11-03 2003-06-03 Qualcomm Incorporated Method and apparatus for high rate packet data transmission
TW408315B (en) 1997-11-07 2000-10-11 Sharp Kk Magnetic recording device, magnetic recording and reproducing device, and magnetic recording method
US6246876B1 (en) 1997-11-13 2001-06-12 Telefonaktiebolaget L M Ericsson (Publ) Synchronization messages for hand-off operations
US6091709A (en) 1997-11-25 2000-07-18 International Business Machines Corporation Quality of service management for packet switched networks
US20010012293A1 (en) 1997-12-02 2001-08-09 Lars-Goran Petersen Simultaneous transmission of voice and non-voice data on a single narrowband connection
US6049837A (en) 1997-12-08 2000-04-11 International Business Machines Corporation Programmable output interface for lower level open system interconnection architecture
US6393008B1 (en) 1997-12-23 2002-05-21 Nokia Movile Phones Ltd. Control structures for contention-based packet data services in wideband CDMA
KR100286080B1 (ko) 1997-12-30 2001-04-16 윤종용 데이터링크를이용한데이터송신및수신방법
KR100251963B1 (ko) * 1997-12-31 2000-04-15 윤종용 종합정보통신망과 연동 가능한 비동기전송모드 망 접속영상전화 단말장치
TW459184B (en) 1998-01-23 2001-10-11 Shiu Ming Wei Multimedia message processing system
WO1999042889A1 (en) 1998-02-20 1999-08-26 Power Beat International Limited A multi-layer display and a method for displaying images on such a display
JP3004618B2 (ja) 1998-02-27 2000-01-31 キヤノン株式会社 画像入力装置及び画像入力システム及び画像送受信システム及び画像入力方法及び記憶媒体
JPH11249987A (ja) 1998-03-05 1999-09-17 Nec Corp メッセージ処理装置およびその方法ならびにメッセージ処理制御プログラムを格納した記憶媒体
TR200002649T2 (tr) 1998-03-16 2000-11-21 Jazio Inc. VLSI CMOS arayüz devreleri için yüksek hızlı sinyal üretimi.
EP0944275B1 (en) 1998-03-19 2005-09-14 Hitachi, Ltd. Broadcast information delivering system
US6243761B1 (en) 1998-03-26 2001-06-05 Digital Equipment Corporation Method for dynamically adjusting multimedia content of a web page by a server in accordance to network path characteristics between client and server
US6199169B1 (en) * 1998-03-31 2001-03-06 Compaq Computer Corporation System and method for synchronizing time across a computer cluster
EP1414180A3 (en) 1998-04-01 2004-05-06 Matsushita Graphic Communication Systems, Inc. Activation of multiple xDSL modems with implicit channel probe
US6252888B1 (en) 1998-04-14 2001-06-26 Nortel Networks Corporation Method and apparatus providing network communications between devices using frames with multiple formats
US6101601A (en) 1998-04-20 2000-08-08 International Business Machines Corporation Method and apparatus for hibernation within a distributed data processing system
US6430196B1 (en) 1998-05-01 2002-08-06 Cisco Technology, Inc. Transmitting delay sensitive information over IP over frame relay
KR100413417B1 (ko) 1998-05-04 2004-02-14 엘지전자 주식회사 이동통신시스템에서 단말기의 호 접속 제어 방법.
US6611503B1 (en) 1998-05-22 2003-08-26 Tandberg Telecom As Method and apparatus for multimedia conferencing with dynamic bandwidth allocation
JP3792894B2 (ja) 1998-05-27 2006-07-05 キヤノン株式会社 固体撮像素子及び固体撮像装置
US6043693A (en) 1998-06-01 2000-03-28 3Dfx Interactive, Incorporated Multiplexed synchronization circuits for switching frequency synthesized signals
US6850282B1 (en) * 1998-06-02 2005-02-01 Canon Kabushiki Kaisha Remote control of image sensing apparatus
JP3475081B2 (ja) 1998-06-03 2003-12-08 三洋電機株式会社 立体映像再生方法
US6092231A (en) 1998-06-12 2000-07-18 Qlogic Corporation Circuit and method for rapid checking of error correction codes using cyclic redundancy check
JP4267092B2 (ja) 1998-07-07 2009-05-27 富士通株式会社 時刻同期方法
US6510503B2 (en) 1998-07-27 2003-01-21 Mosaid Technologies Incorporated High bandwidth memory interface
US6359479B1 (en) * 1998-08-04 2002-03-19 Juniper Networks, Inc. Synchronizing data transfers between two distinct clock domains
US6532506B1 (en) * 1998-08-12 2003-03-11 Intel Corporation Communicating with devices over a bus and negotiating the transfer rate over the same
US6728263B2 (en) 1998-08-18 2004-04-27 Microsoft Corporation Dynamic sizing of data packets
EP1112642A2 (en) 1998-09-11 2001-07-04 Sharewave, Inc. Method and apparatus for controlling communication within a computer network
US6513085B1 (en) 1998-10-13 2003-01-28 Texas Instruments Incorporated Link/transaction layer controller with integral microcontroller emulation
US6332004B1 (en) 1998-10-30 2001-12-18 Broadcom Corporation Analog discrete-time filtering for unshielded twisted pair data communication
US7180951B2 (en) * 1998-10-30 2007-02-20 Broadcom Corporation Reduction of aggregate EMI emissions of multiple transmitters
US6421735B1 (en) 1998-10-30 2002-07-16 Advanced Micro Devices, Inc. Apparatus and method for automatically selecting a network port for a home network station
US6836829B2 (en) 1998-11-20 2004-12-28 Via Technologies, Inc. Peripheral device interface chip cache and data synchronization method
TW466410B (en) 2000-06-16 2001-12-01 Via Tech Inc Cache device inside peripheral component interface chipset and data synchronous method to externals
US6545979B1 (en) 1998-11-27 2003-04-08 Alcatel Canada Inc. Round trip delay measurement
AU750979B2 (en) 1998-12-07 2002-08-01 Samsung Electronics Co., Ltd. Device and method for gating transmission in a CDMA mobile communication system
US6791379B1 (en) 1998-12-07 2004-09-14 Broadcom Corporation Low jitter high phase resolution PLL-based timing recovery system
US6363439B1 (en) * 1998-12-07 2002-03-26 Compaq Computer Corporation System and method for point-to-point serial communication between a system interface device and a bus interface device in a computer system
US6297684B1 (en) 1998-12-14 2001-10-02 Seiko Epson Corporation Circuit and method for switching between digital signals that have different signal rates
JP3557975B2 (ja) 1998-12-14 2004-08-25 セイコーエプソン株式会社 信号切り替え回路及び信号切り替え方法
US6252526B1 (en) 1998-12-14 2001-06-26 Seiko Epson Corporation Circuit and method for fast parallel data strobe encoding
JP2000196986A (ja) 1998-12-25 2000-07-14 Olympus Optical Co Ltd 電子的撮像装置
US6950428B1 (en) 1998-12-30 2005-09-27 Hewlett-Packard Development Company, L.P. System and method for configuring adaptive sets of links between routers in a system area network (SAN)
US6549538B1 (en) 1998-12-31 2003-04-15 Compaq Information Technologies Group, L.P. Computer method and apparatus for managing network ports cluster-wide using a lookaside list
US6836469B1 (en) 1999-01-15 2004-12-28 Industrial Technology Research Institute Medium access control protocol for a multi-channel communication system
US6636508B1 (en) 1999-02-12 2003-10-21 Nortel Networks Limted Network resource conservation system
US6493824B1 (en) 1999-02-19 2002-12-10 Compaq Information Technologies Group, L.P. Secure system for remotely waking a computer in a power-down state
JP2002539531A (ja) 1999-03-05 2002-11-19 アクセンチュア・リミテッド・ライアビリティ・パートナーシップ 高度モバイル通信のためのシステム、方法、及び製造品
US6199099B1 (en) 1999-03-05 2001-03-06 Ac Properties B.V. System, method and article of manufacture for a mobile communication network utilizing a distributed communication network
JP4181685B2 (ja) * 1999-03-12 2008-11-19 富士通株式会社 電力制御方法及び電子機器並びに記録媒体
US6429867B1 (en) 1999-03-15 2002-08-06 Sun Microsystems, Inc. System and method for generating and playback of three-dimensional movies
US6609167B1 (en) 1999-03-17 2003-08-19 Adaptec, Inc. Host and device serial communication protocols and communication packet formats
US6636922B1 (en) 1999-03-17 2003-10-21 Adaptec, Inc. Methods and apparatus for implementing a host side advanced serial protocol
FI107424B (fi) 1999-03-22 2001-07-31 Nokia Mobile Phones Ltd Menetelmä ja järjestelmä multimediaan liittyvän informaation välittämiseen valmistautumiseksi pakettikytkentäisessä solukkoradioverkossa
JP2000278141A (ja) 1999-03-26 2000-10-06 Mitsubishi Electric Corp マルチプレクサ
KR100350607B1 (ko) 1999-03-31 2002-08-28 삼성전자 주식회사 음성 및 화상 송수신을 위한 휴대용 복합 통신단말기 및 그 동작방법과 통신시스템
US6222677B1 (en) 1999-04-12 2001-04-24 International Business Machines Corporation Compact optical system for use in virtual display applications
JP2000358033A (ja) 1999-06-14 2000-12-26 Canon Inc データ通信システム及びデータ通信方法
US6618360B1 (en) 1999-06-15 2003-09-09 Hewlett-Packard Development Company, L.P. Method for testing data path of peripheral server devices
US6457090B1 (en) 1999-06-30 2002-09-24 Adaptec, Inc. Structure and method for automatic configuration for SCSI Synchronous data transfers
JP2001025010A (ja) 1999-07-09 2001-01-26 Mitsubishi Electric Corp マルチメディア情報通信装置およびその方法
US6865609B1 (en) * 1999-08-17 2005-03-08 Sharewave, Inc. Multimedia extensions for wireless local area network
US6597197B1 (en) 1999-08-27 2003-07-22 Intel Corporation I2C repeater with voltage translation
KR20010019734A (ko) 1999-08-30 2001-03-15 윤종용 유무선 통신을 이용한 컴퓨터 교육용 시스템
US7010607B1 (en) * 1999-09-15 2006-03-07 Hewlett-Packard Development Company, L.P. Method for training a communication link between ports to correct for errors
JP3116090B1 (ja) 1999-09-17 2000-12-11 郵政省通信総合研究所長 通信システム、送信装置、受信装置、送信方法、受信方法、および、情報記録媒体
JP4207329B2 (ja) * 1999-09-20 2009-01-14 富士通株式会社 フレーム同期回路
US6782277B1 (en) 1999-09-30 2004-08-24 Qualcomm Incorporated Wireless communication system with base station beam sweeping
US6643787B1 (en) 1999-10-19 2003-11-04 Rambus Inc. Bus system optimization
US6662322B1 (en) 1999-10-29 2003-12-09 International Business Machines Corporation Systems, methods, and computer program products for controlling the error rate in a communication device by adjusting the distance between signal constellation points
JP2004516689A (ja) 1999-11-11 2004-06-03 アスコム・パワーライン・コミニユケーシヨンズ・アクチエンゲゼルシヤフト 特に屋内用の通信システム
US6438363B1 (en) 1999-11-15 2002-08-20 Lucent Technologies Inc. Wireless modem alignment in a multi-cell environment
EP1232604B1 (en) 1999-11-16 2003-10-15 Broadcom Corporation Method and network switch with data serialization using hazard-free multilevel glitchless multiplexing
GB2372606B (en) 1999-11-22 2004-06-02 Seagate Technology Llc Peer to peer interconnect diagnostics
TW513636B (en) 2000-06-30 2002-12-11 Via Tech Inc Bus data interface for transmitting data on PCI bus, the structure and the operating method thereof
US6804257B1 (en) 1999-11-25 2004-10-12 International Business Machines Corporation System and method for framing and protecting variable-lenght packet streams
JP4058888B2 (ja) * 1999-11-29 2008-03-12 セイコーエプソン株式会社 Ram内蔵ドライバ並びにそれを用いた表示ユニットおよび電子機器
JP4191869B2 (ja) 1999-12-20 2008-12-03 富士フイルム株式会社 ディジタルカメラを用いたコンピュータシステム
US7383350B1 (en) 2000-02-03 2008-06-03 International Business Machines Corporation User input based allocation of bandwidth on a data link
US6778493B1 (en) 2000-02-07 2004-08-17 Sharp Laboratories Of America, Inc. Real-time media content synchronization and transmission in packet network apparatus and method
JP3490368B2 (ja) 2000-02-07 2004-01-26 インターナショナル・ビジネス・マシーンズ・コーポレーション 信号出力装置、ドライバ回路、信号伝送システム、および信号伝送方法
JP2001236304A (ja) 2000-02-21 2001-08-31 Mitsubishi Electric Corp マイクロコンピュータ
JP4449141B2 (ja) 2000-02-22 2010-04-14 ソニー株式会社 電源制御装置、電源制御システム
CA2813536C (en) 2000-03-03 2015-08-25 Qualcomm Incorporated Method and apparatus for participating in group communication services in an existing communication system
US6477150B1 (en) 2000-03-03 2002-11-05 Qualcomm, Inc. System and method for providing group communication services in an existing communication system
JP2001282714A (ja) 2000-03-30 2001-10-12 Olympus Optical Co Ltd マルチカメラデータ転送方式及びデータ転送方式
JP2001292146A (ja) 2000-04-07 2001-10-19 Sony Corp 電子機器およびディジタルシリアルデータのインタフェース装置のバス初期化フェーズにおける処理方法
US6882361B1 (en) 2000-04-19 2005-04-19 Pixelworks, Inc. Imager linked with image processing station
JP2001306428A (ja) 2000-04-25 2001-11-02 Canon Inc ネットワーク機器、ネットワークシステム、通信方法及び記録媒体
JP2001319745A (ja) 2000-05-08 2001-11-16 Honda Tsushin Kogyo Co Ltd 変換用アダプタ
JP2001320280A (ja) * 2000-05-10 2001-11-16 Mitsubishi Electric Corp 並列−直列変換回路
US6760722B1 (en) 2000-05-16 2004-07-06 International Business Machines Corporation Computer implemented automated remote support
JP4292685B2 (ja) 2000-05-23 2009-07-08 日本電気株式会社 データ転送システム、データ送受信システム、データ送受信方法、フォーマット変換装置、フォーマット変換方法およびフォーマット変換プログラムを記録したコンピュータ読み取り可能な記録媒体
KR100360622B1 (ko) 2000-06-12 2002-11-13 주식회사 문화방송 엠펙 데이터 프레임과 이를 이용한 송수신 시스템
US6754179B1 (en) 2000-06-13 2004-06-22 Lsi Logic Corporation Real time control of pause frame transmissions for improved bandwidth utilization
US6714233B2 (en) * 2000-06-21 2004-03-30 Seiko Epson Corporation Mobile video telephone system
JP3415567B2 (ja) 2000-06-21 2003-06-09 エヌイーシーマイクロシステム株式会社 Usb転送制御方法およびusbコントローラ
US6999432B2 (en) * 2000-07-13 2006-02-14 Microsoft Corporation Channel and quality of service adaptation for multimedia over wireless networks
JP2004506350A (ja) 2000-08-08 2004-02-26 リプレイティブィ・インコーポレーテッド リモートテレビジョン再生制御
JP4825372B2 (ja) 2000-08-09 2011-11-30 エスケーテレコム株式会社 逆方向同期伝送方式を支援する無線通信システムにおけるハンドオーバ方法
US6784941B1 (en) 2000-08-09 2004-08-31 Sunplus Technology Co., Ltd. Digital camera with video input
JP2002062990A (ja) 2000-08-15 2002-02-28 Fujitsu Media Device Kk インターフェイス装置
US6725412B1 (en) 2000-08-15 2004-04-20 Dolby Laboratories Licensing Corporation Low latency data encoder
GB2366926A (en) 2000-09-06 2002-03-20 Sony Uk Ltd Combining material and data
US7138989B2 (en) * 2000-09-15 2006-11-21 Silicon Graphics, Inc. Display capable of displaying images in response to signals of a plurality of signal formats
US6747964B1 (en) 2000-09-15 2004-06-08 Qualcomm Incorporated Method and apparatus for high data rate transmission in a wireless communication system
US7466978B1 (en) 2000-09-18 2008-12-16 International Business Machines Corporation Telephone network node device
JP4146991B2 (ja) * 2000-09-18 2008-09-10 キヤノン株式会社 電子カメラシステム、電子カメラ及び電子カメラシステムの制御方法
US6760882B1 (en) 2000-09-19 2004-07-06 Intel Corporation Mode selection for data transmission in wireless communication channels based on statistical parameters
US6738344B1 (en) 2000-09-27 2004-05-18 Hewlett-Packard Development Company, L.P. Link extenders with link alive propagation
US7336613B2 (en) * 2000-10-17 2008-02-26 Avaya Technology Corp. Method and apparatus for the assessment and optimization of network traffic
US6690655B1 (en) 2000-10-19 2004-02-10 Motorola, Inc. Low-powered communication system and method of operation
US7869067B2 (en) 2000-10-20 2011-01-11 Visioneer, Inc. Combination scanner and image data reader system including image management and software
US7278069B2 (en) 2000-10-31 2007-10-02 Igor Anatolievich Abrosimov Data transmission apparatus for high-speed transmission of digital data and method for automatic skew calibration
US8996698B1 (en) 2000-11-03 2015-03-31 Truphone Limited Cooperative network for mobile internet access
CA2397323C (en) 2000-11-17 2006-04-11 Samsung Electronics Co., Ltd. Apparatus and method for measuring propagation delay in an nb-tdd cdma mobile communication system
US7464877B2 (en) * 2003-11-13 2008-12-16 Metrologic Instruments, Inc. Digital imaging-based bar code symbol reading system employing image cropping pattern generator and automatic cropped image processor
FI115802B (fi) 2000-12-04 2005-07-15 Nokia Corp Kuvakehyksien päivittäminen muistillisessa näytössä
GB2397675B (en) * 2000-12-06 2004-09-29 Fujitsu Ltd Verification circuitry
US6973039B2 (en) * 2000-12-08 2005-12-06 Bbnt Solutions Llc Mechanism for performing energy-based routing in wireless networks
US6760772B2 (en) * 2000-12-15 2004-07-06 Qualcomm, Inc. Generating and implementing a communication protocol and interface for high data rate signal transfer
IL156385A0 (en) * 2000-12-15 2004-01-04 Qualcomm Inc Generating and implementing a communication protocol and interface for high data rate signal transfer
US7023924B1 (en) 2000-12-28 2006-04-04 Emc Corporation Method of pausing an MPEG coded video stream
JP2002208844A (ja) 2001-01-12 2002-07-26 Nec Eng Ltd グリッチ除去回路
US6947436B2 (en) 2001-02-01 2005-09-20 Motorola, Inc. Method for optimizing forward link data transmission rates in spread-spectrum communications systems
US7301968B2 (en) 2001-03-02 2007-11-27 Pmc-Sierra Israel Ltd. Communication protocol for passive optical network topologies
KR20020071226A (ko) 2001-03-05 2002-09-12 삼성전자 주식회사 이동통신 시스템에서 역방향 링크 송신 제어 장치 및 방법
CN1165141C (zh) 2001-03-27 2004-09-01 华为技术有限公司 路由器接口驱动数据转发过程的方法
JP2002300299A (ja) 2001-03-29 2002-10-11 Shunichi Toyoda 携帯電話材のメモリを利用した情報端末装置による教育システム
CN1159935C (zh) 2001-03-30 2004-07-28 华为技术有限公司 一种提高市区环境下蜂窝移动台定位精度的方法和装置
JP3497834B2 (ja) 2001-03-30 2004-02-16 株式会社東芝 ルートリピータ、usb通信システム、usb通信制御方法
JP2002359774A (ja) 2001-03-30 2002-12-13 Fuji Photo Film Co Ltd 電子カメラ
US20020159458A1 (en) 2001-04-27 2002-10-31 Foster Michael S. Method and system for reserved addressing in a communications network
US6889056B2 (en) 2001-04-30 2005-05-03 Ntt Docomo, Inc. Transmission control scheme
JP3884322B2 (ja) 2001-05-16 2007-02-21 株式会社リコー ネットワークインターフェース
US7392541B2 (en) 2001-05-17 2008-06-24 Vir2Us, Inc. Computer system architecture and method providing operating-system independent virus-, hacker-, and cyber-terror-immune processing environments
JP2002351689A (ja) 2001-05-30 2002-12-06 Nec Corp データ転送システム
US7191281B2 (en) * 2001-06-13 2007-03-13 Intel Corporation Mobile computer system having a navigation mode to optimize system performance and power management for mobile applications
US7165112B2 (en) * 2001-06-22 2007-01-16 Motorola, Inc. Method and apparatus for transmitting data in a communication system
JP2003006143A (ja) 2001-06-22 2003-01-10 Nec Corp バス共有化システムと装置及び方法
US6745364B2 (en) 2001-06-28 2004-06-01 Microsoft Corporation Negotiated/dynamic error correction for streamed media
JP2003046595A (ja) 2001-07-06 2003-02-14 Texas Instruments Inc データ通信の方法および装置
US7051218B1 (en) 2001-07-18 2006-05-23 Advanced Micro Devices, Inc. Message based power management
KR100895559B1 (ko) 2001-07-23 2009-04-29 파나소닉 주식회사 정보기록매체, 정보기록매체에 정보를 기록하는 장치 및방법
WO2003013080A1 (en) * 2001-07-31 2003-02-13 Comverse Ltd. Email protocol for a mobile environment and gateway using same
US7184408B2 (en) * 2001-07-31 2007-02-27 Denton I Claude Method and apparatus for programmable generation of traffic streams
JP2003044184A (ja) 2001-08-01 2003-02-14 Canon Inc データ処理装置及び電力制御方法
GB2415314B (en) * 2001-08-08 2006-05-03 Adder Tech Ltd Video switch
US6758678B2 (en) * 2001-08-14 2004-07-06 Disney Enterprises, Inc. Computer enhanced play set and method
JP4733877B2 (ja) 2001-08-15 2011-07-27 富士通セミコンダクター株式会社 半導体装置
JP2003069544A (ja) 2001-08-23 2003-03-07 Hitachi Kokusai Electric Inc 通信制御方法及び通信制御装置
JP4322451B2 (ja) 2001-09-05 2009-09-02 日本電気株式会社 Dspメモリ間あるいはdspメモリとcpu用メモリ(dpram)間データ転送方式
US8812706B1 (en) * 2001-09-06 2014-08-19 Qualcomm Incorporated Method and apparatus for compensating for mismatched delays in signals of a mobile display interface (MDDI) system
WO2003023587A2 (en) * 2001-09-06 2003-03-20 Qualcomm, Incorporated Generating and implementing a communication protocol and interface for high data rate signal transfer
DE10145722A1 (de) 2001-09-17 2003-04-24 Infineon Technologies Ag Konzept zur sicheren Datenkommunikation zwischen elektronischen Bausteinen
US20030061431A1 (en) * 2001-09-21 2003-03-27 Intel Corporation Multiple channel interface for communications between devices
KR100408299B1 (ko) 2001-09-29 2003-12-01 삼성전자주식회사 모드 판단 장치 및 방법
JP3633538B2 (ja) 2001-10-02 2005-03-30 日本電気株式会社 輻輳制御システム
US7570668B2 (en) 2001-10-03 2009-08-04 Nokia Corporation Data synchronization
KR100408525B1 (ko) 2001-10-31 2003-12-06 삼성전자주식회사 네트워크에 적응적인 실시간 멀티미디어 스트리밍 시스템및 방법
US20030125040A1 (en) 2001-11-06 2003-07-03 Walton Jay R. Multiple-access multiple-input multiple-output (MIMO) communication system
US7126945B2 (en) * 2001-11-07 2006-10-24 Symbol Technologies, Inc. Power saving function for wireless LANS: methods, system and program products
US6990549B2 (en) * 2001-11-09 2006-01-24 Texas Instruments Incorporated Low pin count (LPC) I/O bridge
US7536598B2 (en) 2001-11-19 2009-05-19 Vir2Us, Inc. Computer system capable of supporting a plurality of independent computing environments
US6891545B2 (en) 2001-11-20 2005-05-10 Koninklijke Philips Electronics N.V. Color burst queue for a shared memory controller in a color sequential display system
GB2382502B (en) 2001-11-23 2005-10-19 Actix Ltd Network testing systems
JP2003167680A (ja) 2001-11-30 2003-06-13 Hitachi Ltd ディスク装置
US20030112758A1 (en) 2001-12-03 2003-06-19 Pang Jon Laurent Methods and systems for managing variable delays in packet transmission
US7486693B2 (en) 2001-12-14 2009-02-03 General Electric Company Time slot protocol
US6993393B2 (en) * 2001-12-19 2006-01-31 Cardiac Pacemakers, Inc. Telemetry duty cycle management system for an implantable medical device
KR100428767B1 (ko) 2002-01-11 2004-04-28 삼성전자주식회사 트래픽 정보를 이용한 가입자 라우팅 설정 방법 및 이를위한 기록매체
US20030144006A1 (en) 2002-01-25 2003-07-31 Mikael Johansson Methods, systems, and computer program products for determining the location of a mobile terminal based on delays in receiving data packets from transmitters having known locations
US20050120208A1 (en) 2002-01-25 2005-06-02 Albert Dobson Robert W. Data transmission systems
US6690201B1 (en) * 2002-01-28 2004-02-10 Xilinx, Inc. Method and apparatus for locating data transition regions
US6797891B1 (en) 2002-03-18 2004-09-28 Applied Micro Circuits Corporation Flexible interconnect cable with high frequency electrical transmission line
US7145411B1 (en) 2002-03-18 2006-12-05 Applied Micro Circuits Corporation Flexible differential interconnect cable with isolated high frequency electrical transmission line
US6867668B1 (en) * 2002-03-18 2005-03-15 Applied Micro Circuits Corporation High frequency signal transmission from the surface of a circuit substrate to a flexible interconnect cable
US7336139B2 (en) * 2002-03-18 2008-02-26 Applied Micro Circuits Corporation Flexible interconnect cable with grounded coplanar waveguide
US20030185220A1 (en) 2002-03-27 2003-10-02 Moshe Valenci Dynamically loading parsing capabilities
US7425986B2 (en) 2002-03-29 2008-09-16 Canon Kabushiki Kaisha Conversion apparatus for image data delivery
US7310535B1 (en) 2002-03-29 2007-12-18 Good Technology, Inc. Apparatus and method for reducing power consumption in a wireless device
JP2003303068A (ja) 2002-04-10 2003-10-24 Ricoh Co Ltd 画像出力システム、画像出力方法、プログラム及び記憶媒体
US7430001B2 (en) 2002-04-12 2008-09-30 Canon Kabushiki Kaisha Image sensing system, communication apparatus and image sensing apparatus having remote control function, and their control method
TWI235917B (en) 2002-04-15 2005-07-11 Via Tech Inc High speed data transmitter and transmission method thereof
US7158539B2 (en) * 2002-04-16 2007-01-02 Microsoft Corporation Error resilient windows media audio coding
US7599689B2 (en) 2002-04-22 2009-10-06 Nokia Corporation System and method for bookmarking radio stations and associated internet addresses
US7284181B1 (en) 2002-04-24 2007-10-16 Juniper Networks, Inc. Systems and methods for implementing end-to-end checksum
US7206516B2 (en) * 2002-04-30 2007-04-17 Pivotal Decisions Llc Apparatus and method for measuring the dispersion of a fiber span
US7574113B2 (en) 2002-05-06 2009-08-11 Sony Corporation Video and audio data recording apparatus, video and audio data recording method, video and audio data reproducing apparatus, and video and audio data reproducing method
US20050091593A1 (en) 2002-05-10 2005-04-28 General Electric Company Method and system for coordinated transfer of control of a remote controlled locomotive
US6886067B2 (en) 2002-05-23 2005-04-26 Seiko Epson Corporation 32 Bit generic asynchronous bus interface using read/write strobe byte enables
US7036066B2 (en) 2002-05-24 2006-04-25 Sun Microsystems, Inc. Error detection using data block mapping
US7269153B1 (en) * 2002-05-24 2007-09-11 Conexant Systems, Inc. Method for minimizing time critical transmit processing for a personal computer implementation of a wireless local area network adapter
US7543326B2 (en) 2002-06-10 2009-06-02 Microsoft Corporation Dynamic rate control
JP2003098583A (ja) 2002-06-10 2003-04-03 Nikon Corp 書換え可能なメモリを使用するカメラ
JP2004021613A (ja) * 2002-06-17 2004-01-22 Seiko Epson Corp データ転送制御装置、電子機器及びデータ転送制御方法
DE60212104T2 (de) 2002-06-18 2006-10-19 Matsushita Electric Industrial Co., Ltd., Kadoma Auf Empfänger basierte Umlaufzeitmessung in TCP
KR100469427B1 (ko) * 2002-06-24 2005-02-02 엘지전자 주식회사 이동통신 시스템의 동영상 재생 방법
US7486696B2 (en) 2002-06-25 2009-02-03 Avaya, Inc. System and method for providing bandwidth management for VPNs
DE10234991B4 (de) * 2002-07-31 2008-07-31 Advanced Micro Devices, Inc., Sunnyvale Hostcontrollerdiagnose für einen seriellen Bus
US7403511B2 (en) 2002-08-02 2008-07-22 Texas Instruments Incorporated Low power packet detector for low power WLAN devices
US6611221B1 (en) 2002-08-26 2003-08-26 Texas Instruments Incorporated Multi-bit sigma-delta modulator employing dynamic element matching using adaptively randomized data-weighted averaging
CN100401782C (zh) * 2002-09-05 2008-07-09 新加坡科技研究局 控制视频序列速率的方法和装置及视频编码装置
AU2003272468A1 (en) 2002-09-13 2004-04-30 Digimarc Id Systems, Llc Enhanced shadow reduction system and related techniques for digital image capture
US7257087B2 (en) 2002-10-04 2007-08-14 Agilent Technologies, Inc. System and method to calculate round trip delay for real time protocol packet streams
CN1266976C (zh) 2002-10-15 2006-07-26 华为技术有限公司 一种移动台定位方法及其直放站
US20040082383A1 (en) 2002-10-24 2004-04-29 Motorola, Inc Methodology and wireless device for interactive gaming
JP4028356B2 (ja) 2002-10-31 2007-12-26 京セラ株式会社 通信システム、無線通信端末、データ配信装置及び通信方法
US7949777B2 (en) 2002-11-01 2011-05-24 Avid Technology, Inc. Communication protocol for controlling transfer of temporal data over a bus between devices in synchronization with a periodic reference signal
GB0226014D0 (en) 2002-11-08 2002-12-18 Nokia Corp Camera-LSI and information device
US7336667B2 (en) * 2002-11-21 2008-02-26 International Business Machines Corporation Apparatus, method and program product to generate and use CRC in communications network
US7327735B2 (en) * 2002-11-27 2008-02-05 Alcatel Canada Inc. System and method for detecting lost messages transmitted between modules in a communication device
JP3642332B2 (ja) 2002-12-20 2005-04-27 松下電器産業株式会社 折り畳み式携帯電話装置
US7191349B2 (en) * 2002-12-26 2007-03-13 Intel Corporation Mechanism for processor power state aware distribution of lowest priority interrupt
US6765506B1 (en) 2003-01-06 2004-07-20 Via Technologies Inc. Scrambler, de-scrambler, and related method
GB2397709B (en) 2003-01-27 2005-12-28 Evangelos Arkas Period-to-digital converter
US7047475B2 (en) 2003-02-04 2006-05-16 Hewlett-Packard Development Company, L.P. CRC encoding scheme for conveying status information
JP4119764B2 (ja) 2003-02-13 2008-07-16 京セラ株式会社 カメラ付き携帯端末
US20040176065A1 (en) * 2003-02-20 2004-09-09 Bo Liu Low power operation in a personal area network communication system
US7787886B2 (en) * 2003-02-24 2010-08-31 Invisitrack, Inc. System and method for locating a target using RFID
US6944136B2 (en) 2003-02-28 2005-09-13 On-Demand Technologies, Inc. Two-way audio/video conferencing system
US20040184450A1 (en) 2003-03-19 2004-09-23 Abdu H. Omran Method and system for transport and routing of packets over frame-based networks
JP4112414B2 (ja) 2003-03-28 2008-07-02 京セラ株式会社 携帯端末装置
US7260087B2 (en) 2003-04-02 2007-08-21 Cellco Partnership Implementation methodology for client initiated parameter negotiation for PTT/VoIP type services
JP2004309623A (ja) 2003-04-03 2004-11-04 Konica Minolta Opto Inc 撮像装置及び携帯端末並びに撮像装置製造方法
JP4288994B2 (ja) * 2003-04-10 2009-07-01 株式会社日立製作所 端末装置、配信サーバ、映像データの受信方法及び映像データの送信方法
US7403487B1 (en) 2003-04-10 2008-07-22 At&T Corporation Method and system for dynamically adjusting QOS
WO2004093451A2 (en) * 2003-04-17 2004-10-28 Thomson Licensing Data requesting and transmitting devices and processes
US20040221315A1 (en) 2003-05-01 2004-11-04 Genesis Microchip Inc. Video interface arranged to provide pixel data independent of a link character clock
US6895410B2 (en) 2003-05-02 2005-05-17 Nokia Corporation Method and apparatus for providing a multimedia data stream
US7477604B2 (en) 2003-05-14 2009-01-13 Ntt Docomo, Inc. Packet communications system
EP1645082A2 (en) 2003-05-28 2006-04-12 Artimi Ltd Ultra-wideband network, device, device controller, method and data packet for establishing a mesh network and forwarding packets on another channel
US7110420B2 (en) 2003-05-30 2006-09-19 North Carolina State University Integrated circuit devices having on-chip adaptive bandwidth buses and related methods
JP4278439B2 (ja) 2003-06-02 2009-06-17 パイオニア株式会社 情報通信装置、そのシステム、その方法、そのプログラム、および、そのプログラムを記録した記録媒体
CN101938493B (zh) * 2003-06-02 2013-10-16 高通股份有限公司 生成并实施一用于更高数据率的讯号协议和接口
US6975145B1 (en) 2003-06-02 2005-12-13 Xilinx, Inc. Glitchless dynamic multiplexer with synchronous and asynchronous controls
US20040260823A1 (en) 2003-06-17 2004-12-23 General Instrument Corporation Simultaneously transporting multiple MPEG-2 transport streams
JP3834819B2 (ja) * 2003-07-17 2006-10-18 船井電機株式会社 プロジェクタ
KR100538226B1 (ko) 2003-07-18 2005-12-21 삼성전자주식회사 복수의 아날로그 입력 신호를 고속으로 처리하는아날로그/디지털 변환 장치 및 이를 이용한 디스플레이 장치
US7526350B2 (en) * 2003-08-06 2009-04-28 Creative Technology Ltd Method and device to process digital media streams
CN101194482B (zh) 2003-08-13 2015-11-25 高通股份有限公司 一种使通信系统中的主机与客户机间读写至少一个寄存器的方法与系统
TWI345404B (en) * 2003-09-10 2011-07-11 Qualcomm Inc High data rate interface
US7467202B2 (en) * 2003-09-10 2008-12-16 Fidelis Security Systems High-performance network content analysis platform
US7015838B1 (en) * 2003-09-11 2006-03-21 Xilinx, Inc. Programmable serializing data path
KR20050028396A (ko) 2003-09-17 2005-03-23 삼성전자주식회사 멀티 세션 방식을 이용한 데이터 기록 방법 및 그정보저장매체
JP2005107683A (ja) 2003-09-29 2005-04-21 Sharp Corp 通信コントローラ、通信システム、通信機器、および通信方法
US7315520B2 (en) * 2003-10-08 2008-01-01 Research In Motion Limited Method and apparatus for dynamic packet transport in CDMA2000 networks
CN1894931A (zh) 2003-10-15 2007-01-10 高通股份有限公司 高数据速率接口
AU2004307162A1 (en) 2003-10-29 2005-05-12 Qualcomm Incorporated High data rate interface
EP2242231A1 (en) 2003-11-12 2010-10-20 Qualcomm Incorporated High data rate interface with improved link control
US7219294B2 (en) 2003-11-14 2007-05-15 Intel Corporation Early CRC delivery for partial frame
US7447953B2 (en) 2003-11-14 2008-11-04 Intel Corporation Lane testing with variable mapping
US7143207B2 (en) 2003-11-14 2006-11-28 Intel Corporation Data accumulation between data path having redrive circuit and memory device
WO2005053272A1 (en) 2003-11-25 2005-06-09 Qualcomm Incorporated High data rate interface with improved link synchronization
EP2247068B1 (en) 2003-12-08 2013-09-25 Qualcomm Incorporated High data rate interface with improved link synchronization
US7451362B2 (en) 2003-12-12 2008-11-11 Broadcom Corporation Method and system for onboard bit error rate (BER) estimation in a port bypass controller
US7340548B2 (en) * 2003-12-17 2008-03-04 Microsoft Corporation On-chip bus
US20050163085A1 (en) * 2003-12-24 2005-07-28 International Business Machines Corporation System and method for autonomic wireless presence ping
US7317754B1 (en) * 2004-01-12 2008-01-08 Verizon Services Corp. Rate agile rate-adaptive digital subscriber line
JP2007519968A (ja) 2004-01-28 2007-07-19 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ マトリクスディスプレイにおける表示
US7158536B2 (en) * 2004-01-28 2007-01-02 Rambus Inc. Adaptive-allocation of I/O bandwidth using a configurable interconnect topology
US7868890B2 (en) 2004-02-24 2011-01-11 Qualcomm Incorporated Display processor for a wireless device
JP3786120B2 (ja) 2004-03-09 2006-06-14 セイコーエプソン株式会社 データ転送制御装置及び電子機器
BRPI0508582A (pt) 2004-03-10 2007-08-14 Qualcomm Inc equipamento e método de interface de alta taxa de dados
WO2005091593A1 (en) 2004-03-17 2005-09-29 Qualcomm Incorporated High data rate interface apparatus and method
US8645566B2 (en) 2004-03-24 2014-02-04 Qualcomm Incorporated High data rate interface apparatus and method
DE102004014973B3 (de) 2004-03-26 2005-11-03 Infineon Technologies Ag Parallel-Seriell-Umsetzer
KR100678164B1 (ko) 2004-04-21 2007-02-02 삼성전자주식회사 휴대단말기의 멀티 데이터 처리장치
US20050265333A1 (en) * 2004-06-01 2005-12-01 Texas Instruments Incorporated Method for enabling efficient multicast transmission in a packet-based network
US7088294B2 (en) 2004-06-02 2006-08-08 Research In Motion Limited Mobile wireless communications device comprising a top-mounted auxiliary input/output device and a bottom-mounted antenna
US8650304B2 (en) * 2004-06-04 2014-02-11 Qualcomm Incorporated Determining a pre skew and post skew calibration data rate in a mobile display digital interface (MDDI) communication system
US20060034301A1 (en) * 2004-06-04 2006-02-16 Anderson Jon J High data rate interface apparatus and method
ATE518343T1 (de) 2004-06-04 2011-08-15 Qualcomm Inc Schnittstellenvorrichtung und -verfahren für hohe datenraten
US7383399B2 (en) * 2004-06-30 2008-06-03 Intel Corporation Method and apparatus for memory compression
US7095435B1 (en) 2004-07-21 2006-08-22 Hartman Richard L Programmable multifunction electronic camera
ES2353394T3 (es) 2004-07-22 2011-03-01 Ucb Pharma, S.A. Derivados de indolona, procedimientos para prepararlos y sus usos.
CN101041989A (zh) 2004-08-05 2007-09-26 邱则有 一种钢筋砼立体承力结构楼盖
KR100604323B1 (ko) 2004-08-28 2006-07-24 삼성테크윈 주식회사 내장형 카메라 장치 및 이를 구비한 휴대폰
KR100624311B1 (ko) 2004-08-30 2006-09-19 삼성에스디아이 주식회사 프레임 메모리 제어 방법 및 그것을 이용한 표시 장치
US7161846B2 (en) * 2004-11-16 2007-01-09 Seiko Epson Corporation Dual-edge triggered multiplexer flip-flop and method
US6990335B1 (en) * 2004-11-18 2006-01-24 Charles G. Shamoon Ubiquitous connectivity and control system for remote locations
CN101103326B (zh) 2004-11-24 2012-02-15 高通股份有限公司 用于在通信链路上同步执行命令的方法
US8699330B2 (en) 2004-11-24 2014-04-15 Qualcomm Incorporated Systems and methods for digital data transmission rate control
US8539119B2 (en) 2004-11-24 2013-09-17 Qualcomm Incorporated Methods and apparatus for exchanging messages having a digital data interface device message format
US8873584B2 (en) 2004-11-24 2014-10-28 Qualcomm Incorporated Digital data interface device
US8667363B2 (en) 2004-11-24 2014-03-04 Qualcomm Incorporated Systems and methods for implementing cyclic redundancy checks
US8692838B2 (en) 2004-11-24 2014-04-08 Qualcomm Incorporated Methods and systems for updating a buffer
US8723705B2 (en) * 2004-11-24 2014-05-13 Qualcomm Incorporated Low output skew double data rate serial encoder
US7315265B2 (en) * 2004-11-24 2008-01-01 Qualcomm Incorporated Double data rate serial encoder
EP2317688A3 (en) 2004-11-24 2012-03-21 QUALCOMM Incorporated System and methods for implementing cyclic redundancy checks
US20060161691A1 (en) 2004-11-24 2006-07-20 Behnam Katibian Methods and systems for synchronous execution of commands across a communication link
KR100672987B1 (ko) 2004-12-20 2007-01-24 삼성전자주식회사 고속 아날로그 인벨롭 디텍터
JP2006211394A (ja) 2005-01-28 2006-08-10 Toshiba Corp 折り畳み型携帯端末装置
US7412642B2 (en) 2005-03-09 2008-08-12 Sun Microsystems, Inc. System and method for tolerating communication lane failures
JP4428272B2 (ja) 2005-03-28 2010-03-10 セイコーエプソン株式会社 表示ドライバ及び電子機器
US7605837B2 (en) 2005-06-02 2009-10-20 Lao Chan Yuen Display system and method
JP2007012937A (ja) 2005-06-30 2007-01-18 Seiko Epson Corp 表示ドライバ
JP4756950B2 (ja) 2005-08-08 2011-08-24 キヤノン株式会社 撮像装置及びその制御方法
US7302510B2 (en) * 2005-09-29 2007-11-27 International Business Machines Corporation Fair hierarchical arbiter
US20070098002A1 (en) 2005-10-28 2007-05-03 Inventec Corporation Media center operating mode selection control method and system
US8692839B2 (en) 2005-11-23 2014-04-08 Qualcomm Incorporated Methods and systems for updating a buffer
US8730069B2 (en) 2005-11-23 2014-05-20 Qualcomm Incorporated Double data rate serial encoder
US7813451B2 (en) 2006-01-11 2010-10-12 Mobileaccess Networks Ltd. Apparatus and method for frequency shifting of a wireless signal and systems using frequency shifting
US7893990B1 (en) 2006-07-31 2011-02-22 Cisco Technology, Inc. Digital video camera with retractable data connector and resident software application
JP4250648B2 (ja) 2006-09-21 2009-04-08 株式会社東芝 情報処理装置
US7912503B2 (en) * 2007-07-16 2011-03-22 Microsoft Corporation Smart interface system for mobile communications devices
JP2009284281A (ja) 2008-05-23 2009-12-03 Nec Electronics Corp 無線通信機器、及び無線通信状態表示方法
KR200469360Y1 (ko) 2008-12-26 2013-10-11 대성전기공업 주식회사 시트 온도 조절 스위치 장치

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06124147A (ja) * 1992-10-13 1994-05-06 Sanyo Electric Co Ltd 情報処理装置
JPH10312370A (ja) * 1997-05-12 1998-11-24 Hitachi Ltd 省電力機能を有するネットワークシステム
JP2003009035A (ja) * 2001-03-26 2003-01-10 Matsushita Electric Ind Co Ltd 電源制御装置
JP2003198550A (ja) * 2001-12-25 2003-07-11 Matsushita Electric Ind Co Ltd 通信装置及び通信方法
JP2004007356A (ja) * 2002-04-23 2004-01-08 Sony Corp 情報処理システム、情報処理装置および方法、プログラム格納媒体、並びにプログラム
JP2004046324A (ja) * 2002-07-09 2004-02-12 Mitsubishi Electric Corp 待機モード付情報処理装置およびその待機モード開始方法と待機モード解除方法

Also Published As

Publication number Publication date
KR101245962B1 (ko) 2013-03-21
RU2355121C2 (ru) 2009-05-10
TWI384811B (zh) 2013-02-01
EP1735986A1 (en) 2006-12-27
KR20060130749A (ko) 2006-12-19
EP1735986B1 (en) 2013-05-22
AU2005223960A1 (en) 2005-09-29
JP4519903B2 (ja) 2010-08-04
IL178132A0 (en) 2006-12-31
KR20090068298A (ko) 2009-06-25
TW200614751A (en) 2006-05-01
US8705521B2 (en) 2014-04-22
AU2005223960B2 (en) 2009-04-09
MXPA06010647A (es) 2007-01-17
CA2560067A1 (en) 2005-09-29
US20050216599A1 (en) 2005-09-29
WO2005091593A1 (en) 2005-09-29
RU2006136427A (ru) 2008-04-27
CA2560067C (en) 2011-08-23
BRPI0508923A (pt) 2007-08-14

Similar Documents

Publication Publication Date Title
JP4519903B2 (ja) 高速データレートインタフェース装置及び方法
JP4902355B2 (ja) 改良されたリンク同期を備えた高速データレートインタフェース
JP5275284B2 (ja) 高速データレートインタフェース装置及び方法
JP5129318B2 (ja) 高速データレートインタフェース
JP5453197B2 (ja) 高データレートインターフェース装置および方法
JP5237319B2 (ja) 高速データレートインタフェース
JP4782694B2 (ja) 改善されたリンク制御を有する高速データレートインタフェース
JP6138860B2 (ja) より高速なデータレート用の信号インタフェース
JP2007512785A (ja) 改良されたリンク同期を備えた高速データレートインタフェース
JP2013258691A (ja) 高データレートインタフェース装置及び方法

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080218

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20090824

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090915

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20091215

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20091218

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20091222

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20100420

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100519

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130528

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130528

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees