JP6362277B2 - マルチフォーマットオーディオシステムにおけるロック保証のための確率的方法に基づく汎用同期エンジン - Google Patents
マルチフォーマットオーディオシステムにおけるロック保証のための確率的方法に基づく汎用同期エンジン Download PDFInfo
- Publication number
- JP6362277B2 JP6362277B2 JP2015514293A JP2015514293A JP6362277B2 JP 6362277 B2 JP6362277 B2 JP 6362277B2 JP 2015514293 A JP2015514293 A JP 2015514293A JP 2015514293 A JP2015514293 A JP 2015514293A JP 6362277 B2 JP6362277 B2 JP 6362277B2
- Authority
- JP
- Japan
- Prior art keywords
- synchronization
- data
- mode
- bus
- bit
- 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.)
- Active
Links
- 238000000034 method Methods 0.000 title claims description 703
- 238000004891 communication Methods 0.000 claims description 291
- 230000005540 biological transmission Effects 0.000 claims description 74
- 238000000926 separation method Methods 0.000 claims description 34
- 125000004122 cyclic group Chemical group 0.000 claims description 5
- 238000004590 computer program Methods 0.000 claims description 3
- 230000004807 localization Effects 0.000 claims description 2
- 108091006146 Channels Proteins 0.000 description 867
- 230000006870 function Effects 0.000 description 176
- 238000012546 transfer Methods 0.000 description 88
- 230000008569 process Effects 0.000 description 79
- 230000008859 change Effects 0.000 description 71
- 238000010586 diagram Methods 0.000 description 51
- 230000009471 action Effects 0.000 description 48
- 230000000875 corresponding effect Effects 0.000 description 39
- 230000001360 synchronised effect Effects 0.000 description 38
- 230000007704 transition Effects 0.000 description 34
- 230000008901 benefit Effects 0.000 description 30
- 238000005070 sampling Methods 0.000 description 30
- 230000000694 effects Effects 0.000 description 24
- 230000002829 reductive effect Effects 0.000 description 22
- 238000007667 floating Methods 0.000 description 21
- 230000003321 amplification Effects 0.000 description 20
- 238000003199 nucleic acid amplification method Methods 0.000 description 20
- 230000011664 signaling Effects 0.000 description 20
- 239000002609 medium Substances 0.000 description 18
- 238000012545 processing Methods 0.000 description 17
- 230000004913 activation Effects 0.000 description 16
- 230000003111 delayed effect Effects 0.000 description 15
- 238000012544 monitoring process Methods 0.000 description 14
- 238000012360 testing method Methods 0.000 description 14
- 238000012790 confirmation Methods 0.000 description 12
- 239000000872 buffer Substances 0.000 description 11
- 229920000729 poly(L-lysine) polymer Polymers 0.000 description 11
- 230000000630 rising effect Effects 0.000 description 11
- 230000003068 static effect Effects 0.000 description 11
- 230000003213 activating effect Effects 0.000 description 10
- 238000004422 calculation algorithm Methods 0.000 description 10
- 239000013078 crystal Substances 0.000 description 10
- 230000009286 beneficial effect Effects 0.000 description 9
- 230000002441 reversible effect Effects 0.000 description 9
- 238000006243 chemical reaction Methods 0.000 description 8
- 230000006835 compression Effects 0.000 description 8
- 238000007906 compression Methods 0.000 description 8
- 230000001934 delay Effects 0.000 description 8
- 230000009467 reduction Effects 0.000 description 8
- 238000005259 measurement Methods 0.000 description 7
- 238000012795 verification Methods 0.000 description 7
- 238000004364 calculation method Methods 0.000 description 6
- 229910052799 carbon Inorganic materials 0.000 description 6
- 230000004044 response Effects 0.000 description 6
- 238000013459 approach Methods 0.000 description 5
- 230000008878 coupling Effects 0.000 description 5
- 238000010168 coupling process Methods 0.000 description 5
- 238000005859 coupling reaction Methods 0.000 description 5
- 230000036039 immunity Effects 0.000 description 5
- 230000003287 optical effect Effects 0.000 description 5
- 239000003990 capacitor Substances 0.000 description 4
- 238000001514 detection method Methods 0.000 description 4
- 230000001976 improved effect Effects 0.000 description 4
- 238000011068 loading method Methods 0.000 description 4
- 238000013507 mapping Methods 0.000 description 4
- 238000012806 monitoring device Methods 0.000 description 4
- 230000036961 partial effect Effects 0.000 description 4
- 101710170231 Antimicrobial peptide 2 Proteins 0.000 description 3
- XUIMIQQOPSSXEZ-UHFFFAOYSA-N Silicon Chemical compound [Si] XUIMIQQOPSSXEZ-UHFFFAOYSA-N 0.000 description 3
- 230000001413 cellular effect Effects 0.000 description 3
- 230000000295 complement effect Effects 0.000 description 3
- 230000000670 limiting effect Effects 0.000 description 3
- 230000007257 malfunction Effects 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 238000002156 mixing Methods 0.000 description 3
- 230000010355 oscillation Effects 0.000 description 3
- 230000008054 signal transmission Effects 0.000 description 3
- 229910052710 silicon Inorganic materials 0.000 description 3
- 239000010703 silicon Substances 0.000 description 3
- 238000003860 storage Methods 0.000 description 3
- 230000032258 transport Effects 0.000 description 3
- 230000005641 tunneling Effects 0.000 description 3
- 101710170230 Antimicrobial peptide 1 Proteins 0.000 description 2
- CURLTUGMZLYLDI-UHFFFAOYSA-N Carbon dioxide Chemical compound O=C=O CURLTUGMZLYLDI-UHFFFAOYSA-N 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 238000007599 discharging Methods 0.000 description 2
- 210000000883 ear external Anatomy 0.000 description 2
- 210000003027 ear inner Anatomy 0.000 description 2
- 238000009432 framing Methods 0.000 description 2
- 238000003780 insertion Methods 0.000 description 2
- 230000037431 insertion Effects 0.000 description 2
- 238000002955 isolation Methods 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 239000011159 matrix material Substances 0.000 description 2
- 230000003278 mimic effect Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000003071 parasitic effect Effects 0.000 description 2
- 238000013139 quantization Methods 0.000 description 2
- 230000000717 retained effect Effects 0.000 description 2
- 238000000638 solvent extraction Methods 0.000 description 2
- 230000008093 supporting effect Effects 0.000 description 2
- 230000001052 transient effect Effects 0.000 description 2
- YSGQGNQWBLYHPE-CFUSNLFHSA-N (7r,8r,9s,10r,13s,14s,17s)-17-hydroxy-7,13-dimethyl-2,6,7,8,9,10,11,12,14,15,16,17-dodecahydro-1h-cyclopenta[a]phenanthren-3-one Chemical compound C1C[C@]2(C)[C@@H](O)CC[C@H]2[C@@H]2[C@H](C)CC3=CC(=O)CC[C@@H]3[C@H]21 YSGQGNQWBLYHPE-CFUSNLFHSA-N 0.000 description 1
- 208000032368 Device malfunction Diseases 0.000 description 1
- 235000015429 Mirabilis expansa Nutrition 0.000 description 1
- 244000294411 Mirabilis expansa Species 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 229910002092 carbon dioxide Inorganic materials 0.000 description 1
- 239000001569 carbon dioxide Substances 0.000 description 1
- 239000002131 composite material Substances 0.000 description 1
- 230000001010 compromised effect Effects 0.000 description 1
- 239000012141 concentrate Substances 0.000 description 1
- 230000001276 controlling effect Effects 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 230000009849 deactivation Effects 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 230000002950 deficient Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000008571 general function Effects 0.000 description 1
- 230000006698 induction Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000001788 irregular Effects 0.000 description 1
- 230000033001 locomotion Effects 0.000 description 1
- 230000000873 masking effect Effects 0.000 description 1
- 238000007620 mathematical function Methods 0.000 description 1
- 239000002184 metal Substances 0.000 description 1
- 235000013536 miso Nutrition 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000003032 molecular docking Methods 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 238000013021 overheating Methods 0.000 description 1
- 238000012856 packing Methods 0.000 description 1
- 239000002245 particle Substances 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000000053 physical method Methods 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 230000001681 protective effect Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000003252 repetitive effect Effects 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 238000010845 search algorithm Methods 0.000 description 1
- 230000035945 sensitivity Effects 0.000 description 1
- 230000005236 sound signal Effects 0.000 description 1
- 230000000087 stabilizing effect Effects 0.000 description 1
- 238000010561 standard procedure Methods 0.000 description 1
- HODRFAVLXIFVTR-RKDXNWHRSA-N tevenel Chemical compound NS(=O)(=O)C1=CC=C([C@@H](O)[C@@H](CO)NC(=O)C(Cl)Cl)C=C1 HODRFAVLXIFVTR-RKDXNWHRSA-N 0.000 description 1
- 239000006163 transport media Substances 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
- 238000004804 winding Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/14—Handling requests for interconnection or transfer
- G06F13/36—Handling requests for interconnection or transfer for access to common bus or bus system
- G06F13/362—Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control
- G06F13/3625—Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control using a time dependent access
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
- G06F1/04—Generating or distributing clock signals or signals derived directly therefrom
- G06F1/12—Synchronisation of different clock signals provided by a plurality of clock generators
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04J—MULTIPLEX COMMUNICATION
- H04J3/00—Time-division multiplex systems
- H04J3/02—Details
- H04J3/06—Synchronising arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/24—Testing correct operation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L7/00—Arrangements for synchronising receiver with transmitter
- H04L7/04—Speed or phase control by synchronisation signals
- H04L7/041—Speed or phase control by synchronisation signals using special codes as synchronising signal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L7/00—Arrangements for synchronising receiver with transmitter
- H04L7/04—Speed or phase control by synchronisation signals
- H04L7/041—Speed or phase control by synchronisation signals using special codes as synchronising signal
- H04L7/042—Detectors therefor, e.g. correlators, state machines
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L7/00—Arrangements for synchronising receiver with transmitter
- H04L7/04—Speed or phase control by synchronisation signals
- H04L7/048—Speed or phase control by synchronisation signals using the properties of error detecting or error correcting codes, e.g. parity as synchronisation signal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L7/00—Arrangements for synchronising receiver with transmitter
- H04L7/04—Speed or phase control by synchronisation signals
- H04L7/10—Arrangements for initial synchronisation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04J—MULTIPLEX COMMUNICATION
- H04J3/00—Time-division multiplex systems
- H04J3/02—Details
- H04J3/06—Synchronising arrangements
- H04J3/0635—Clock or time synchronisation in a network
- H04J3/0638—Clock or time synchronisation among nodes; Internode synchronisation
- H04J3/0658—Clock or time synchronisation among packet nodes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L2001/0092—Error control systems characterised by the topology of the transmission link
- H04L2001/0094—Bus
Description
本明細書で説明される種々の実施形態は、概して、マルチフォーマットまたは統一通信プロトコルに同期化する方法、デバイス、およびシステムに関する。
コンピュータまたはプロセッサアーキテクチャでは、バスは、電子デバイス内のデバイスの間でデータを転送するか、または電子デバイスの間でデータを転送するサブシステムである。バスアーキテクチャはまた、互と通信し得るデバイスの各セットの間で別個の接続を有するよりもむしろ、複数のデバイスのための共通データ信号伝達経路で使用される。換言すると、バス構造は、１つ以上のスレーブデバイスが１つ以上のマスタデバイスと通信することを可能にするために使用されることができる。
一側面では、本明細書で説明される少なくとも１つの実施形態は、第１および第２の動作モードを有する統一バス通信プロトコルを使用して通信するマスタデバイスにスレーブデバイスを同期化する方法を提供する。本方法は、統一バス通信プロトコルに対して第１の動作モードを仮定することと、第１の動作モードに従って、伝送されているデータの中の１つ以上の場所で同期化パターンを検索することと、動作モードに対する少なくとも１つの同期化規則に従って、場所が特定された同期化パターンが検証された場合、同期化を取得することと、第１の動作モードを仮定して同期化が取得されない場合、統一バス通信プロトコルのための第２の動作モードを仮定し、第２の動作モードに従って、伝送されているデータ上で検索することおよび取得することを実行することとを含む。
少なくとも１つの実施形態では、同期化パターンは、一定同期部分と、動的同期部分とを備え、検索することは、一定同期部分を検索することを含む。
少なくとも１つの実施形態では、一定同期部分は、第１および第２の動作モードについて異なる。
少なくとも１つの実施形態では、動的同期部分は、２つの連続する同期化パターンの動的同期部分が異なるように、決定論的方法によって生成される。
少なくとも１つの実施形態では、決定論的方法は、周期的冗長カウンタ（ＣＲＣ）を採用する。
少なくとも１つの実施形態では、第１の動作モードは、ワードモードであり、第２の動作モードは、ビットストリームモードであり、または、第１の動作モードは、ビットストリームモードであり、第２の動作モードは、ワードモードである。
少なくとも１つの実施形態では、ワードモードを動作モードとして仮定する場合、検索することは、同期化パターンが以前に場所を特定されていない限り、最大フレーム長までを含む、種々の開始タイムスロット位置に対して伝送されているデータ上で行われる。
少なくとも１つの実施形態では、ビットストリームモードを動作モードとして仮定する場合、検索することは、最大フレーム長までを含む、種々の開始タイムスロット位置に対して伝送されているデータ上で行われ、これは、同期化パターンが以前に場所を特定されていない限り、フレームチャネルの最大数について繰り返される。
少なくとも１つの実施形態では、同期化パターンの場所が特定されると、検索することおよび取得することは、統一バス通信プロトコルによって使用されているフレーム長を決定するために、次の同期化パターンを検索することを含む。
少なくとも１つの実施形態では、少なくとも１つの同期化規則は、決定されたフレーム長が正しいことを検証するために、検索することおよび取得することを数回行うことを含む。
少なくとも１つの実施形態では、検索することおよび取得することは、場所が特定されている一定同期部分に関連付けられた現在の動的同期部分を読み取ることを含み、少なくとも１つの同期化規則は、決定論的方法および現在の動的同期部分に基づいて、期待動的同期部分を計算することと、次の一定同期部分の場所を特定することと、誤った同期化の可能性を低減させるために、次の一定同期部分に関連付けられた動的同期部分を、期待動的同期部分と比較することとを含む。
少なくとも１つの実施形態では、少なくとも１つの同期化規則は、誤った同期化の可能性をさらに低減させるために、計算すること、場所を特定すること、および比較することを１回以上繰り返すことを含む。
少なくとも１つの実施形態では、少なくとも１つの同期化規則は、バストラフィック上の雑音が多い条件下で同期化の可能性を向上させるために、場所を特定すること、および取得することにおいてランダム成分を追加することを含む。
少なくとも１つの実施形態では、ランダム成分は、ある期間にわたってバストラフィックのパリティを読み取ることと、現在場所が特定されている同期化パターンが真のパターンであるか、または偽のパターンであるかを決定することに役立つように、パリティ情報を使用することとを含む。
少なくとも１つの実施形態では、ランダム成分は、同期化パターンが１つ以上のエラーの下で場所を特定されている場合に使用される。
少なくとも１つの実施形態では、第１の動作モードは、ビットストリームモードであり、クロックゲーティングは、同期化パターンのビットが存在すると仮定されないフレームチャネルからのデータをスキップするために使用される。
少なくとも１つの実施形態では、本方法は、クロックゲーティング、およびワードモードおよびビットストリーム動作モードの両方の下で同期化パターンを検索するための共通検索構造を採用する。
少なくとも１つの実施形態では、スレーブデバイスが同期化から外れた場合、スレーブデバイスは、以前の成功した同期化試行中に決定されたフレーム長およびフレーム形式を仮定し、同期化を再獲得しようとする。
少なくとも１つの実施形態では、次の一定同期部分に関連付けられた動的同期部分が、期待動的同期部分に合致しない場合、本方法はさらに、期待動的同期部分に合致する動的同期部分を伴う一定同期部分を検索し続けることを含む。
少なくとも１つの実施形態では、期待動的同期部分に合致する動的同期部分の場所を特定するために一定同期部分が検索されて場所を特定される数に制限が課せられる。
少なくとも１つの実施形態では、合致を見出すことなく制限に達する場合、方法はさらに、有効な同期部分として場所が特定された一定同期部分のうちのいずれかを選択することを含む。
少なくとも１つの実施形態では、同期化が達成された後、本方法はさらに、以前の場所が特定された同期化パターンからの決定されたフレーム長の距離の近傍にある、伝送されているデータの中の位置を検討することによって、同期化を維持することを含む。
少なくとも１つの実施形態では、本方法はさらに、検索が最大フレーム長を超えるまで、期待動的同期部分と実際の動的同期部分との間の合致を見出さないことにかかわらず、現在の場所が特定された一定同期部分を維持することを含み、検索が最大フレーム長を超えた時点で、現在の場所が特定された一定同期部分が破棄され、次の一定同期部分が現在の場所が特定された一定同期部分として使用され、合致の検索は、継続される。
少なくとも１つの実施形態では、本方法はさらに、最大データ長内に位置する全ての有効な一定同期部分に対応する、動的同期部分の表を生成することと、実際のフレーム長を決定するために、連続位置の間の分離における反復のために、期待動的同期部分に合致する動的同期部分の位置を分析することと、同期化を取得するために実際のフレーム長を使用することとを含む。
別の側面では、本明細書で説明される少なくとも１つの実施形態は、第１および第２の動作モードを有する統一バス通信プロトコルを使用して通信するマスタデバイスに同期化する方法を提供する。本方法は、統一バス通信プロトコルに対して第１および第２の動作モードを仮定することと、第１および第２の動作モードに従って伝送されているデータの中の１つ以上の場所で同期化パターンを同時に検索することと、第１および第２の動作モードのうちの１つのための少なくとも１つの同期化規則に従って、場所が特定された同期化パターンが検証された場合、同期化を取得することと、同期化が取得されない場合、統一バス通信プロトコルに従って、伝送されているデータ上で第１および第２の動作モードに従って、検索することおよび取得することを実行することとを含む。
少なくとも１つの実施形態では、本方法は、種々の方法の実施形態について上記で説明される特徴のうちの１つ以上を組み込み得る。
さらに別の側面では、本明細書で説明される少なくとも１つの実施形態は、ビットストリームフレーム形式を使用して通信するマスタデバイスにスレーブデバイスを同期化する方法を提供する。本方法は、ビットストリームフレーム形式に従って、伝送されているデータの中の１つ以上の場所で同期化パターンを検索することと、動作モードに対する少なくとも１つの同期化規則に従って、場所が特定された同期化パターンが検証された場合、同期化を取得することと、同期化が取得されない場合、新たに伝送されているデータ上で検索することおよび取得することを繰り返し実行することとを含み、ビットストリームフレーム形式では、同期化パターンは、他の伝送されているデータと一度に１ビットで多重化される。
少なくとも１つの実施形態では、本方法は、種々の方法の実施形態について上記で説明される特徴のうちの１つ以上を組み込み得る。
さらに別の側面では、本明細書で説明される少なくとも１つの実施形態は、ワードフレーム形式を使用して通信するマスタデバイスにスレーブデバイスを同期化する方法を提供する。本方法は、ワードフレーム形式に従って、伝送されているデータの中の１つ以上の場所で同期化パターンを検索することと、動作モードに対する少なくとも１つの同期化規則に従って、場所が特定された同期化パターンが検証された場合、同期化を取得することと、同期化が取得されない場合、新たに伝送されているデータ上で検索することおよび取得することを繰り返し実行することとを含み、ワードフレーム形式では、同期化パターンは、データの全フレームにおいて、連続ビットで伝送される。
少なくとも１つの実施形態では、本方法は、種々の方法の実施形態について上記で説明される特徴のうちの１つ以上を組み込み得る。
さらに別の側面では、本明細書で説明される少なくとも１つの実施形態は、第１および第２の動作モードを有する統一バス通信プロトコルに従って通信する電子デバイスを提供する。本デバイスは、信号を送受信するためのインターフェースと、インターフェースに連結されている多重化および同期エンジンとを備え、多重化および同期エンジンは、統一バス通信プロトコルに対して第１の動作モードを仮定すること、第１の動作モードに従って、伝送されているデータの中の１つ以上の場所で同期化パターンを検索すること、動作モードに対する少なくとも１つの同期化規則に従って、場所が特定された同期化パターンが検証された場合、同期化を取得すること、および第１の動作モードを仮定して同期化が取得されない場合、統一バス通信プロトコルのための第２の動作モードを仮定し、第２の動作モードに従って、伝送されているデータ上で検索することおよび取得することを実行することによって、電子デバイスを第２の電子デバイスと同期化するように構成され、電子デバイスは、スレーブデバイスであり、第２の電子デバイスは、マスタデバイスである。
少なくとも１つの実施形態では、本デバイスは、種々の方法の実施形態について上記で説明される特徴のうちの１つ以上を組み込み得る。
さらに別の側面では、本明細書で説明される少なくとも１つの実施形態は、第１および第２の動作モードを有する統一バス通信プロトコルに従って通信する電子デバイスを提供する。本デバイスは、信号を送受信するためのインターフェースと、インターフェースに連結されている多重化および同期エンジンとを備え、多重化および同期エンジンは、統一バス通信プロトコルに対して第１および第２の動作モードを仮定すること、第１および第２の動作モードに従って伝送されているデータの中の１つ以上の場所で同期化パターンを同時に検索すること、第１および第２の動作モードのうちの１つのための少なくとも１つの同期化規則に従って、場所が特定された同期化パターンが検証された場合、同期化を取得すること、同期化が取得されない場合、統一バス通信プロトコルに従って、伝送されているデータ上で第１および第２の動作モードに従って、検索することおよび取得することを実行することによって、電子デバイスを第２の電子デバイスと同期化するように構成され、電子デバイスは、スレーブデバイスであり、第２の電子デバイスは、マスタデバイスである。
少なくとも１つの実施形態では、本デバイスは、種々の方法の実施形態について上記で説明される特徴のうちの１つ以上を組み込み得る。
さらに別の側面では、本明細書で説明される少なくとも１つの実施形態は、ビットストリームフレーム形式に従って通信する電子デバイスを提供する。本デバイスは、信号を送受信するためのインターフェースと、インターフェースに連結されている多重化および同期エンジンとを備え、多重化および同期エンジンは、ビットストリームフレーム形式に従って、伝送されているデータの中の１つ以上の場所で同期化パターンを検索すること、動作モードに対する少なくとも１つの同期化規則に従って、場所が特定された同期化パターンが検証された場合、同期化を取得すること、同期化が取得されない場合、新たに伝送されているデータ上で検索することおよび取得することを繰り返し実行することによって、電子デバイスを第２の電子デバイスと同期化するように構成され、ビットストリームフレーム形式では、同期化パターンは、他の伝送されているデータと一度に１ビットで多重化され、電子デバイスは、スレーブデバイスであり、第２の電子デバイスは、マスタデバイスである。
少なくとも１つの実施形態では、本デバイスは、種々の方法の実施形態について上記で説明される特徴のうちの１つ以上を組み込み得る。
さらに別の側面では、本明細書で説明される少なくとも１つの実施形態は、ワードフレーム形式に従って通信する電子デバイスを提供する。本デバイスは、信号を送受信するためのインターフェースと、インターフェースに連結されている多重化および同期エンジンとを備え、多重化および同期エンジンは、ワードフレーム形式に従って、伝送されているデータの中の１つ以上の場所で同期化パターンを検索すること、動作モードに対する少なくとも１つの同期化規則に従って、場所が特定された同期化パターンが検証された場合、同期化を取得すること、同期化が取得されない場合、新たに伝送されているデータ上で検索することおよび取得することを繰り返し実行することによって、電子デバイスを第２の電子デバイスと同期化するように構成され、ワードフレーム形式では、同期化パターンは、データの全フレームにおいて、連続ビットで伝送され、電子デバイスは、スレーブデバイスであり、第２の電子デバイスは、マスタデバイスである。
少なくとも１つの実施形態では、本デバイスは、種々の方法の実施形態について上記で説明される特徴のうちの１つ以上を組み込み得る。
さらに別の側面では、本明細書で説明される少なくとも１つの実施形態は、第１および第２の動作モードを有する統一バス通信プロトコルを使用して通信するマスタデバイスにスレーブデバイスを同期化する方法を実装するようにマイクロプロセッサを適合させるための、スレーブデバイスのマイクロプロセッサ上で実行可能な複数の命令を備えているコンピュータ読み取り可能な媒体を提供し、本方法は、統一バス通信プロトコルに対して第１の動作モードを仮定することと、第１の動作モードに従って、伝送されているデータの中の１つ以上の場所で同期化パターンを検索することと、動作モードに対する少なくとも１つの同期化規則に従って、場所が特定された同期化パターンが検証された場合、同期化を取得することと、第１の動作モードを仮定して同期化が取得されない場合、統一バス通信プロトコルのための第２の動作モードを仮定し、第２の動作モードに従って、伝送されているデータ上で検索することおよび取得することを実行することとを含む。
少なくとも１つの実施形態では、コンピュータ読み取り可能な媒体は、種々の方法の実施形態について上記で説明される特徴のうちの１つ以上を組み込み得る。
さらに別の側面では、本明細書で説明される少なくとも１つの実施形態は、第１および第２の動作モードを有する統一バス通信プロトコルを使用して通信するマスタデバイスにスレーブデバイスを同期化する方法を実装するようにマイクロプロセッサを適合させるための、スレーブデバイスのマイクロプロセッサ上で実行可能な複数の命令を備えているコンピュータ読み取り可能な媒体を提供し、本方法は、統一バス通信プロトコルに対して第１および第２の動作モードを仮定することと、第１および第２の動作モードに従って伝送されているデータの中の１つ以上の場所で同期化パターンを同時に検索することと、第１および第２の動作モードのうちの１つのための少なくとも１つの同期化規則に従って、場所が特定された同期化パターンが検証された場合、同期化を取得することと、同期化が取得されない場合、統一バス通信プロトコルに従って、伝送されているデータ上で第１および第２の動作モードに従って、検索することおよび取得することを実行することとを含む。
少なくとも１つの実施形態では、コンピュータ読み取り可能な媒体は、種々の方法の実施形態について上記で説明される特徴のうちの１つ以上を組み込み得る。
さらに別の側面では、本明細書で説明される少なくとも１つの実施形態は、ビットストリームフレーム形式を使用して通信するマスタデバイスにスレーブデバイスを同期化する方法を実装するようにマイクロプロセッサを適合させるための、スレーブデバイスのマイクロプロセッサ上で実行可能な複数の命令を備えているコンピュータ読み取り可能な媒体を提供し、本方法は、ビットストリームフレーム形式に従って、伝送されているデータの中の１つ以上の場所で同期化パターンを検索することと、動作モードに対する少なくとも１つの同期化規則に従って、場所が特定された同期化パターンが検証された場合、同期化を取得することと、同期化が取得されない場合、新たに伝送されているデータ上で検索することおよび取得することを繰り返し実行することとを含み、ビットストリームフレーム形式で、同期化パターンは、他の伝送されているデータと一度に１ビットで多重化される。
少なくとも１つの実施形態では、コンピュータ読み取り可能な媒体は、種々の方法の実施形態について上記で説明される特徴のうちの１つ以上を組み込み得る。
さらに別の側面では、本明細書で説明される少なくとも１つの実施形態は、ワードフレーム形式を使用して通信するマスタデバイスにスレーブデバイスを同期化する方法を実装するようにマイクロプロセッサを適合させるための、スレーブデバイスのマイクロプロセッサ上で実行可能な複数の命令を備えているコンピュータ読み取り可能な媒体を提供し、本方法は、ワードフレーム形式に従って、伝送されているデータの中の１つ以上の場所で同期化パターンを検索することと、動作モードに対する少なくとも１つの同期化規則に従って、場所が特定された同期化パターンが検証された場合、同期化を取得することと、同期化が取得されない場合、新たに伝送されているデータ上で検索することおよび取得することを繰り返し実行することとを含み、ワードフレーム形式では、同期化パターンは、データの全フレームにおいて、連続ビットで伝送される。
少なくとも１つの実施形態では、コンピュータ読み取り可能な媒体は、種々の方法の実施形態について上記で説明される特徴のうちの１つ以上を組み込み得る。
例えば、本願発明は以下の項目を提供する。
（項目１）
第１および第２の動作モードを有する統一バス通信プロトコルを使用して通信するマスタデバイスにスレーブデバイスを同期化する方法であって、
前記統一バス通信プロトコルに対して前記第１の動作モードを仮定することと、
前記第１の動作モードに従って、伝送されているデータの中の１つ以上の場所で同期化パターンを検索することと、
前記動作モードに対する少なくとも１つの同期化規則に従って、場所が特定された同期化パターンが検証された場合、同期化を取得することと、
前記第１の動作モードを仮定して同期化が取得されない場合、前記統一バス通信プロトコルに対して前記第２の動作モードを仮定し、前記第２の動作モードに従って、前記伝送されているデータ上で前記検索すること、および取得することを実行することと
を含む、方法。
（項目２）
前記同期化パターンは、一定同期部分と、動的同期部分とを備え、前記検索することは、前記一定同期部分を検索することを含む、項目１に記載の方法。
（項目３）
前記一定同期部分は、前記第１および第２の動作モードについて異なる、項目１または項目２に記載の方法。
（項目４）
前記動的同期部分は、２つの連続する同期化パターンの前記動的同期部分が異なるように、決定論的方法によって生成される、項目２または項目３に記載の方法。
（項目５）
前記決定論的方法は、周期的冗長カウンタ（ＣＲＣ）を採用する、項目４に記載の方法。
（項目６）
前記第１の動作モードは、ワードモードであり、前記第２の動作モードは、ビットストリームモードであり、または前記第１の動作モードは、ビットストリームモードであり、前記第２の動作モードは、ワードモードである、項目１〜５のいずれか一項に記載の方法。
（項目７）
ワードモードを前記動作モードとして仮定する場合、前記検索することは、前記同期化パターンが以前に場所を特定されていない限り、最大フレーム長までを含む、種々の開始タイムスロット位置に対して前記伝送されているデータ上で行われる、項目１〜６のいずれか一項に記載の方法。
（項目８）
ビットストリームモードを前記動作モードとして仮定する場合、前記検索することは、最大フレーム長までを含む、種々の開始タイムスロット位置に対して前記伝送されているデータ上で行われ、これは、前記同期化パターンが以前に場所を特定されていない限り、フレームチャネルの最大数について繰り返される、項目１〜７のいずれか一項に記載の方法。
（項目９）
前記同期化パターンの場所が特定されると、前記検索すること、および取得することは、前記統一バス通信プロトコルによって使用されているフレーム長を決定するために、次の同期化パターンを検索することを含む、項目１〜８のいずれか一項に記載の方法。
（項目１０）
前記少なくとも１つの同期化規則は、前記決定されたフレーム長が正しいことを検証するために、前記検索すること、および取得することを数回行うことを含む、項目９に記載の方法。
（項目１１）
前記検索すること、および取得することは、場所が特定されている一定同期部分に関連付けられた現在の動的同期部分を読み取ることを含み、前記少なくとも１つの同期化規則は、前記決定論的方法および前記現在の動的同期部分に基づいて、期待動的同期部分を計算することと、次の一定同期部分の場所を特定することと、誤った同期化の可能性を低減させるために、前記次の一定同期部分に関連付けられた動的同期部分を、前記期待動的同期部分と比較することとを含む、項目４に記載の方法。
（項目１２）
前記少なくとも１つの同期化規則は、誤った同期化の可能性をさらに低減させるために、前記計算すること、場所を特定すること、および比較することを１回以上繰り返すことを含む、項目１１に記載の方法。
（項目１３）
前記少なくとも１つの同期化規則は、バストラフィック上の雑音が多い条件下で同期化の可能性を向上させるために、前記場所を特定すること、および取得することにおいてランダム成分を追加することを含む、項目１〜１２のいずれか一項に記載の方法。
（項目１４）
前記ランダム成分は、ある期間にわたって前記バストラフィックのパリティを読み取ることと、前記現在場所が特定されている同期化パターンが真のパターンであるか、または偽のパターンであるかを決定することに役立つように、前記パリティ情報を使用することとを含む、項目１３に記載の方法。
（項目１５）
前記ランダム成分は、前記同期化パターンが１つ以上のエラーの下で場所を特定されている場合に使用される、項目１３に記載の方法。
（項目１６）
前記第１の動作モードは、ビットストリームモードであり、クロックゲーティングは、前記同期化パターンのビットが存在すると仮定されないフレームチャネルからのデータをスキップするために使用される、項目１〜１５のいずれか一項に記載の方法。
（項目１７）
前記方法は、クロックゲーティング、および、ワードモードおよびビットストリーム動作モードの両方の下で前記同期化パターンを検索するための共通検索構造を採用する、項目１〜１５のいずれか一項に記載の方法。
（項目１８）
前記スレーブデバイスが同期化から外れた場合、前記スレーブデバイスは、以前の成功した同期化試行中に決定されたフレーム長およびフレーム形式を仮定し、同期化を再獲得しようとする、項目１〜１７のいずれか一項に記載の方法。
（項目１９）
前記次の一定同期部分に関連付けられた前記動的同期部分が、前記期待動的同期部分に合致しない場合、前記方法は、前記期待動的同期部分に合致する動的同期部分を伴う一定同期部分を検索し続けることをさらに含む、項目１１に記載の方法。
（項目２０）
前記期待動的同期部分に合致する前記動的同期部分の場所を特定するために一定同期部分が検索されて場所を特定される数に制限が課せられる、項目１９に記載の方法。
（項目２１）
前記合致を見出すことなく前記制限に達する場合、前記方法は、有効な同期部分として前記場所が特定された一定同期部分のうちのいずれかを選択することをさらに含む、項目２０に記載の方法。
（項目２２）
同期化が達成された後、前記方法は、以前の場所が特定された同期化パターンからの決定されたフレーム長の距離の近傍にある、前記伝送されているデータの中の位置を検討することによって、同期化を維持することをさらに含む、項目１〜２１のいずれか一項に記載の方法。
（項目２３）
前記方法は、前記検索が最大フレーム長を超えるまで、期待動的同期部分と実際の動的同期部分との間の合致を見出さないことにかかわらず、前記現在の場所が特定された一定同期部分を維持することをさらに含み、前記検索が最大フレーム長を超えた時点で、現在の場所が特定された一定同期部分が破棄され、次の一定同期部分が前記現在の場所が特定された一定同期部分として使用され、前記合致に対する前記検索は、継続される、項目１１に記載の方法。
（項目２４）
前記方法は、最大データ長内に位置する全ての有効な一定同期部分に対応する、前記動的同期部分の表を生成することと、実際のフレーム長を決定するために、連続位置の間の分離における反復に対する期待動的同期部分に合致する前記動的同期部分の位置を分析することと、同期化を取得するために前記実際のフレーム長を使用することとをさらに含む、項目２に記載の方法。
（項目２５）
第１および第２の動作モードを有する統一バス通信プロトコルに従って通信する電子デバイスであって、前記デバイスは、
信号を送受信するためのインターフェースと、
前記インターフェースに連結されている多重化および同期エンジンと
を備え、
前記多重化および同期エンジンは、前記統一バス通信プロトコルに対して前記第１の動作モードを仮定することと、前記第１の動作モードに従って、伝送されているデータの中の１つ以上の場所で同期化パターンを検索することと、前記動作モードに対する少なくとも１つの同期化規則に従って、場所が特定された同期化パターンが検証された場合、同期化を取得することと、前記第１の動作モードを仮定して同期化が取得されない場合、前記統一バス通信プロトコルに対して前記第２の動作モードを仮定し、前記第２の動作モードに従って、前記伝送されているデータ上で前記検索すること、および取得することを実行することとによって、前記電子デバイスを第２の電子デバイスと同期化するように構成され、
前記電子デバイスは、スレーブデバイスであり、前記第２の電子デバイスは、マスタデバイスである、デバイス。
（項目２６）
前記多重化および同期エンジンは、項目２〜２４のいずれか一項に記載の方法を行うようにさらに構成されている、項目２５に記載の電子デバイス。
（項目２７）
第１および第２の動作モードを有する統一バス通信プロトコルを使用して通信するマスタデバイスにスレーブデバイスを同期化する方法を実装するようにマイクロプロセッサを適合させるための、前記スレーブデバイスの前記マイクロプロセッサ上で実行可能な複数の命令を備えているコンピュータ読み取り可能な媒体であって、前記方法は、
前記統一バス通信プロトコルに対して前記第１の動作モードを仮定することと、
前記第１の動作モードに従って、伝送されているデータの中の１つ以上の場所で同期化パターンを検索することと、
前記動作モードに対する少なくとも１つの同期化規則に従って、場所が特定された同期化パターンが検証された場合、同期化を取得することと、
前記第１の動作モードを仮定して同期化が取得されない場合、前記統一バス通信プロトコルに対して前記第２の動作モードを仮定し、前記第２の動作モードに従って、前記伝送されているデータ上で前記検索すること、および取得することを実行することと
を含む、コンピュータ読み取り可能な媒体。
（項目２８）
前記方法は、項目２〜２４のいずれか一項に従ってさらに定義される、項目２７に記載のコンピュータ読み取り可能な媒体。
例えば、本願発明は以下の項目を提供する。
（項目１）
第１および第２の動作モードを有する統一バス通信プロトコルを使用して通信するマスタデバイスにスレーブデバイスを同期化する方法であって、
前記統一バス通信プロトコルに対して前記第１の動作モードを仮定することと、
前記第１の動作モードに従って、伝送されているデータの中の１つ以上の場所で同期化パターンを検索することと、
前記動作モードに対する少なくとも１つの同期化規則に従って、場所が特定された同期化パターンが検証された場合、同期化を取得することと、
前記第１の動作モードを仮定して同期化が取得されない場合、前記統一バス通信プロトコルに対して前記第２の動作モードを仮定し、前記第２の動作モードに従って、前記伝送されているデータ上で前記検索すること、および取得することを実行することと
を含む、方法。
（項目２）
前記同期化パターンは、一定同期部分と、動的同期部分とを備え、前記検索することは、前記一定同期部分を検索することを含む、項目１に記載の方法。
（項目３）
前記一定同期部分は、前記第１および第２の動作モードについて異なる、項目１または項目２に記載の方法。
（項目４）
前記動的同期部分は、２つの連続する同期化パターンの前記動的同期部分が異なるように、決定論的方法によって生成される、項目２または項目３に記載の方法。
（項目５）
前記決定論的方法は、周期的冗長カウンタ（ＣＲＣ）を採用する、項目４に記載の方法。
（項目６）
前記第１の動作モードは、ワードモードであり、前記第２の動作モードは、ビットストリームモードであり、または前記第１の動作モードは、ビットストリームモードであり、前記第２の動作モードは、ワードモードである、項目１〜５のいずれか一項に記載の方法。
（項目７）
ワードモードを前記動作モードとして仮定する場合、前記検索することは、前記同期化パターンが以前に場所を特定されていない限り、最大フレーム長までを含む、種々の開始タイムスロット位置に対して前記伝送されているデータ上で行われる、項目１〜６のいずれか一項に記載の方法。
（項目８）
ビットストリームモードを前記動作モードとして仮定する場合、前記検索することは、最大フレーム長までを含む、種々の開始タイムスロット位置に対して前記伝送されているデータ上で行われ、これは、前記同期化パターンが以前に場所を特定されていない限り、フレームチャネルの最大数について繰り返される、項目１〜７のいずれか一項に記載の方法。
（項目９）
前記同期化パターンの場所が特定されると、前記検索すること、および取得することは、前記統一バス通信プロトコルによって使用されているフレーム長を決定するために、次の同期化パターンを検索することを含む、項目１〜８のいずれか一項に記載の方法。
（項目１０）
前記少なくとも１つの同期化規則は、前記決定されたフレーム長が正しいことを検証するために、前記検索すること、および取得することを数回行うことを含む、項目９に記載の方法。
（項目１１）
前記検索すること、および取得することは、場所が特定されている一定同期部分に関連付けられた現在の動的同期部分を読み取ることを含み、前記少なくとも１つの同期化規則は、前記決定論的方法および前記現在の動的同期部分に基づいて、期待動的同期部分を計算することと、次の一定同期部分の場所を特定することと、誤った同期化の可能性を低減させるために、前記次の一定同期部分に関連付けられた動的同期部分を、前記期待動的同期部分と比較することとを含む、項目４に記載の方法。
（項目１２）
前記少なくとも１つの同期化規則は、誤った同期化の可能性をさらに低減させるために、前記計算すること、場所を特定すること、および比較することを１回以上繰り返すことを含む、項目１１に記載の方法。
（項目１３）
前記少なくとも１つの同期化規則は、バストラフィック上の雑音が多い条件下で同期化の可能性を向上させるために、前記場所を特定すること、および取得することにおいてランダム成分を追加することを含む、項目１〜１２のいずれか一項に記載の方法。
（項目１４）
前記ランダム成分は、ある期間にわたって前記バストラフィックのパリティを読み取ることと、前記現在場所が特定されている同期化パターンが真のパターンであるか、または偽のパターンであるかを決定することに役立つように、前記パリティ情報を使用することとを含む、項目１３に記載の方法。
（項目１５）
前記ランダム成分は、前記同期化パターンが１つ以上のエラーの下で場所を特定されている場合に使用される、項目１３に記載の方法。
（項目１６）
前記第１の動作モードは、ビットストリームモードであり、クロックゲーティングは、前記同期化パターンのビットが存在すると仮定されないフレームチャネルからのデータをスキップするために使用される、項目１〜１５のいずれか一項に記載の方法。
（項目１７）
前記方法は、クロックゲーティング、および、ワードモードおよびビットストリーム動作モードの両方の下で前記同期化パターンを検索するための共通検索構造を採用する、項目１〜１５のいずれか一項に記載の方法。
（項目１８）
前記スレーブデバイスが同期化から外れた場合、前記スレーブデバイスは、以前の成功した同期化試行中に決定されたフレーム長およびフレーム形式を仮定し、同期化を再獲得しようとする、項目１〜１７のいずれか一項に記載の方法。
（項目１９）
前記次の一定同期部分に関連付けられた前記動的同期部分が、前記期待動的同期部分に合致しない場合、前記方法は、前記期待動的同期部分に合致する動的同期部分を伴う一定同期部分を検索し続けることをさらに含む、項目１１に記載の方法。
（項目２０）
前記期待動的同期部分に合致する前記動的同期部分の場所を特定するために一定同期部分が検索されて場所を特定される数に制限が課せられる、項目１９に記載の方法。
（項目２１）
前記合致を見出すことなく前記制限に達する場合、前記方法は、有効な同期部分として前記場所が特定された一定同期部分のうちのいずれかを選択することをさらに含む、項目２０に記載の方法。
（項目２２）
同期化が達成された後、前記方法は、以前の場所が特定された同期化パターンからの決定されたフレーム長の距離の近傍にある、前記伝送されているデータの中の位置を検討することによって、同期化を維持することをさらに含む、項目１〜２１のいずれか一項に記載の方法。
（項目２３）
前記方法は、前記検索が最大フレーム長を超えるまで、期待動的同期部分と実際の動的同期部分との間の合致を見出さないことにかかわらず、前記現在の場所が特定された一定同期部分を維持することをさらに含み、前記検索が最大フレーム長を超えた時点で、現在の場所が特定された一定同期部分が破棄され、次の一定同期部分が前記現在の場所が特定された一定同期部分として使用され、前記合致に対する前記検索は、継続される、項目１１に記載の方法。
（項目２４）
前記方法は、最大データ長内に位置する全ての有効な一定同期部分に対応する、前記動的同期部分の表を生成することと、実際のフレーム長を決定するために、連続位置の間の分離における反復に対する期待動的同期部分に合致する前記動的同期部分の位置を分析することと、同期化を取得するために前記実際のフレーム長を使用することとをさらに含む、項目２に記載の方法。
（項目２５）
第１および第２の動作モードを有する統一バス通信プロトコルに従って通信する電子デバイスであって、前記デバイスは、
信号を送受信するためのインターフェースと、
前記インターフェースに連結されている多重化および同期エンジンと
を備え、
前記多重化および同期エンジンは、前記統一バス通信プロトコルに対して前記第１の動作モードを仮定することと、前記第１の動作モードに従って、伝送されているデータの中の１つ以上の場所で同期化パターンを検索することと、前記動作モードに対する少なくとも１つの同期化規則に従って、場所が特定された同期化パターンが検証された場合、同期化を取得することと、前記第１の動作モードを仮定して同期化が取得されない場合、前記統一バス通信プロトコルに対して前記第２の動作モードを仮定し、前記第２の動作モードに従って、前記伝送されているデータ上で前記検索すること、および取得することを実行することとによって、前記電子デバイスを第２の電子デバイスと同期化するように構成され、
前記電子デバイスは、スレーブデバイスであり、前記第２の電子デバイスは、マスタデバイスである、デバイス。
（項目２６）
前記多重化および同期エンジンは、項目２〜２４のいずれか一項に記載の方法を行うようにさらに構成されている、項目２５に記載の電子デバイス。
（項目２７）
第１および第２の動作モードを有する統一バス通信プロトコルを使用して通信するマスタデバイスにスレーブデバイスを同期化する方法を実装するようにマイクロプロセッサを適合させるための、前記スレーブデバイスの前記マイクロプロセッサ上で実行可能な複数の命令を備えているコンピュータ読み取り可能な媒体であって、前記方法は、
前記統一バス通信プロトコルに対して前記第１の動作モードを仮定することと、
前記第１の動作モードに従って、伝送されているデータの中の１つ以上の場所で同期化パターンを検索することと、
前記動作モードに対する少なくとも１つの同期化規則に従って、場所が特定された同期化パターンが検証された場合、同期化を取得することと、
前記第１の動作モードを仮定して同期化が取得されない場合、前記統一バス通信プロトコルに対して前記第２の動作モードを仮定し、前記第２の動作モードに従って、前記伝送されているデータ上で前記検索すること、および取得することを実行することと
を含む、コンピュータ読み取り可能な媒体。
（項目２８）
前記方法は、項目２〜２４のいずれか一項に従ってさらに定義される、項目２７に記載のコンピュータ読み取り可能な媒体。
本明細書で説明される種々の実施形態のより良い理解のために、およびこれらの種々の実施形態がどのようにして実行に移され得るかをより明確に示すために、一例として、少なくとも１つの例示的実施形態を示す、添付図面が参照されるであろう。
図１は、可搬性電子デバイスの斜視図である。
図２は、可搬性電子デバイスの一部分のブロック図である。
図３ａは、バスシステムの例示的実施形態の概略図である。
図３ｂは、マスタデバイスをバスに連結するためのインターフェース回路の実施例を示す、図３ａのバスシステムの概略図である。
図３ｃは、２ワイヤバスシステムの例示的実施形態のブロック図である。
図４ａは、スレーブデバイスが単一ワイヤバス上に「０１１０」を書き込む、バス上のトランザクションの例示的タイミング図である。
図４ｂは、２本のワイヤを使用してバスが実装されるときの例示的タイミング図である。
図５は、同期化ワードのためのフィールドおよびビット割付の例示的実施形態の略図である。
図６は、ワードモードでのＳワードのデータ同期化フィールドへのデータ動作を示す、例示的タイミング図である。
図７は、異なるコマンド動作に基づいてマスタデバイスおよびスレーブデバイスによって行われ得る、パリティおよび確認計算の実施例である。
図８は、コマンド動作（ＰＩＮＧ、ＲＥＡＤ、およびＷＲＩＴＥ）、割り込みマスクビットの値、Ｓ０ ＤＥＬＡＹビット、講じられるべき措置の種々の組み合わせを示す。
図９ａは、種々のコマンド動作のためのＸコマンドワードの例示的実施形態のための種々のフィールドおよびビット割付を示す。
図９ｂは、種々のコマンド動作のためのＸコマンドワードの別の例示的実施形態のための種々のフィールドおよびビット割付を示す。
図１０は、種々のコマンド動作のためのＹコマンドワードの例示的実施形態のための種々のフィールドおよびビット割付を示す。
図１１ａは、Ｘワードで設定され得る、関数および対応するビット設定の例示的リストを示す。
図１１ｂは、固定アドレスを使用する２つの端子を使用して、デバイス中の位置情報を符号化する実施例を示し、この構成はまた、レガシーシステムと適合性がある。
図１１ｃは、リングトポロジーに基づいて、固定アドレスまたは可変アドレス０−Ｎのいずれかを使用して、デバイス中の位置情報を符号化する実施例を示し、この構成はまた、レガシーシステムと適合性がある。
図１１ｄは、標準レイアウトおよび完全位置情報を伴うデジタルマイクロホンのレイアウトの実施例を示す。
図１１ｅは、弱い出力ドライバおよびフィードバックを使用することによって、ＧＮＤ、ＶＤＤ、およびＦＬＯＡＴ状態の間を区別することが可能である、ＩＯセルを示す。
図１２は、マスタデバイスまたはスレーブデバイスの能力情報を取得するためのＦＵＮＣＴＩＯＮ ＣＡＰＡＢＩＬＩＴＹを起動した後にレジスタから読み取る実施例を示す。
図１３は、統一バス通信プロトコルの例示的実施形態でサポートされることができる、種々のデータ形式の実施例を示す。
図１４は、関数ＲＥＡＤ ＬＡＳＴ ＥＲＲＯＲの実行後にデータレジスタから読み取られた状態の実施例を示す。
図１５は、統一バス通信プロトコルの例示的実施例で使用され得る、エラーコードの実施例を示す。
図１６ａは、統一バス通信プロトコルの例示的実施形態のためのマスタデバイスまたはスレーブデバイスに使用されることができる、レジスタの定義の実施例である。
図１６ｂは、統一バス通信プロトコルの例示的実施形態のためのマスタデバイスまたはスレーブデバイスに使用されることができる、レジスタの定義の別の実施例である。
図１７は、統一バス通信プロトコルの例示的実施形態でポートまたはデバイスのために設定されることができる、種々の電力消費レベルまたは電力管理モードの実施例である。
図１８は、統一バス通信プロトコルを使用して２つのスレーブデバイスと通信する、マスタデバイスの例示的実施形態を示し、デバイスは、種々のチャネルに割り付けられるポートを有する。
図１９は、チャネル間の例示的マッピング、およびポートのどのチャネルが通信に使用されるかを説明するチャネル選択フィールドを示す。
図２０は、アドレスおよびＲＥＡＤおよびＷＲＩＴＥ動作中のバンク選択に関する例示的動作を示す。
図２１は、ワードモードでフレーム中で１回以上繰り返されている、単一のポートからのデータの実施例を示す。
図２２ａは、所与のフレーム中の等時性、非同期、およびマルチフレーム転送の使用に応じて設定される、種々のフィールド値の実施例を示す。
図２２ｂは、図１６ａのＰＣＬＫＤフィールドを符号化するために使用されることができる、圧縮形式の実施例を示す。
図２２ｃは、所与のフレーム中の等時性、非同期、およびマルチフレーム転送の使用に応じて設定される、種々のフィールド値の代替実施形態の実施例を示す。
図２３は、ワードモードで低遅延を達成するために、同一のポートからのチャネル間の分割を伴う複数のデータチャネルを使用するときのフレーム形式の実施例を示す。
図２４は、複数のデータチャネルからのデータが、ワードモードでフレーム中で数回繰り返されるときのフレーム設定の実施例を示す。
図２５ａは、統一バス通信プロトコルで使用されるフレームタイプに応じた、ＣＯＭＭＡＮＤ ＳＥＰＡＲＡＴＩＯＮフィールドの定義の実施例を示す。
図２５ｂは、同期化のための時間を削減するためにビットストリームモードで使用されることができる、おくつかのサブフレーム長の例示的定義を示す。
図２５ｃは、統一バス通信プロトコルで使用されるフレームタイプに応じた、ＣＯＭＭＡＮＤ ＳＥＰＡＲＡＴＩＯＮフィールドの定義の代替実施例を示す。
図２６ａおよび２６ｂは、ビットストリームモードでＨＳＴＡＲＴおよびＶＳＴＡＲＴフィールドの異なる値を使用することによって達成されることができる、異なるフレーム形式の実施例を示す。
図２７は、ビットストリームモードでの例示的実施形態のためのＨＳＰＡＣＩＮＧおよびＶＳＰＡＣＩＮＧフィールドのＬＳＢ、ＭＳＢ、およびＬＳＢ＋１ビットの定義を示す。
図２８ａは、統一バス通信プロトコルを使用する、電流および電圧感知を伴うステレオシステムの例示的実施形態を示す。
図２８ｂは、図２８ａのステレオシステムに使用されることができる、ビットストリームフレーム形式の実施例を示す。
図２８ｃは、図２８ａのステレオシステムに使用することができ、感知信号のためにより少ない帯域幅を使用する、ビットストリームフレーム形式の別の実施例を示す。
図２８ｄは、より少ない帯域幅が音声データと比較して制御データ上で使用されるように、オーディオデータと制御データとの間の帯域幅が変化させられる、ビットストリームモードでＨＳＴＡＲＴ、ＶＳＴＡＲＴ、ＨＳＰＡＣＩＮＧ、およびＶＳＰＡＣＩＮＧフィールドの値を設定することによって達成されることができる、ビットストリームフレーム形式の実施例を示す。
図２９ａは、マスタデバイスに使用されることができる、レジスタの定義の例示的実施形態である。
図２９ｂは、マスタデバイスに使用されることができる、レジスタの定義の別の例示的実施形態である。
図２９ｃは、第１の段階のためのサンプリング率の定義の実施例である。
図２９ｄは、随意的な段階のためのサンプリング率の定義の実施例である。
図２９ｅは、第２の段階のためのサンプリング率の定義の実施例である。
図２９ｆは、第３の段階のためのサンプリング率の定義の実施例である。
図２９ｇは、複数のサンプル率比に好適であり得る、マルチフォーマットデシメータシステムの実施例である。
図２９ｈは、複数のサンプル率比に好適であり得る、マルチフォーマット補間器システムの実施例である。
図２９ｉは、ＦＲＡＭＥ ＣＯＮＴＲＯＬフィールドへの書き込みの解釈の実施例である。
図３０は、例示的実施形態における、ＦＲＡＭＥ ＣＯＮＴＲＯＬフィールドに基づくＷＲＩＴＥおよびＲＥＡＤ動作、ならびにＦＲＡＭＥ ＣＯＮＴＲＯＬフィールドの値に応じて監視されることができる、例示的動作の組み合わせを示す。
図３１は、別の例示的実施形態における、ＦＲＡＭＥ ＣＯＮＴＲＯＬフィールドに基づくＷＲＩＴＥおよびＲＥＡＤ動作、ならびにＦＲＡＭＥ ＣＯＮＴＲＯＬフィールドの値に応じて監視されることができる、例示的動作の組み合わせを示す。
図３２ａは、ＩＮＴＥＲＦＡＣＥ ＣＯＮＴＲＯＬレジスタの構成要素の例示的実施形態を示す。
図３２ｂは、ＩＮＴＥＲＦＡＣＥ ＣＯＮＴＲＯＬレジスタの構成要素の別の例示的実施形態を示す。
図３３ａは、図２９ａのレジスタ定義に対応する少なくとも１つの例示的実施形態において、どのようにしてＭＣＬＫＤフィールドが符号化されることができるかという実施例を示す。
図３３ｂは、図２９ｂのレジスタ定義に対応する少なくとも１つの例示的実施形態において、バスに対するクロック信号を生成するために使用され得る、例示的周波数分割を示す。
図３４ａは、ＩＲＱ ＭＡＳＫレジスタで使用されることができる、サブフィールドの例示的実施形態を示す。
図３４ｂは、ＩＲＱ ＭＡＳＫレジスタで使用されることができる、サブフィールドの別の例示的実施形態を示す。
図３５は、ＦＲＡＭＥ ＤＯＮＥ ＭＡＳＫフィールドを変更するための例示的タイミング図を示す。
図３６ａは、ＩＮＴＥＲＦＡＣＥ ＳＴＡＴＵＳレジスタの構成要素の例示的実施形態を示す。
図３６ｂは、ＩＮＴＥＲＦＡＣＥ ＳＴＡＴＵＳレジスタの構成要素の別の例示的実施形態を示す。
図３７は、スレーブ状態レジスタの例示的定義を示す。
図３８ａは、スレーブデバイスのデバイスＩＤを符号化するために使用されることができる、コンパクトな符号化形式の例示的実施形態を示す。
図３８ｂは、スレーブデバイスのデバイスＩＤを符号化するために使用されることができる、一般的な符号化形式の例示的実施形態を示す。
図３９は、単一の時間フレームに対するワードモードで使用される、一般的なワードフレームを使用する。
図４０は、単一の時間フレームに対するワードフレーム形式の例示的実施形態を示す。
図４１は、単一の時間フレームに対するワードフレーム形式の別の例示的実施形態を示す。
図４２は、単一の時間フレームに対するビットストリームフレーム形式の例示的実施形態を示す。
図４３は、単一の時間フレームに対する統一フレーム形式の例示的実施形態を示す。
図４４は、単一の時間フレームに対する統一フレーム形式の別の例示的実施形態を示す。
図４５ａおよび４５ｂは、ワードモードで動作するときの統一バス通信プロトコルに対するバス周波数、チャネルの数およびタイプの例示的組み合わせの表を示す。
図４５ａおよび４５ｂは、ワードモードで動作するときの統一バス通信プロトコルに対するバス周波数、チャネルの数およびタイプの例示的組み合わせの表を示す。
図４６ａおよび４６ｂは、ビットストリームモードで動作し、ビットストリームフレーム形式を使用するときの統一バス通信プロトコルに対するバス周波数、チャネルの数、およびオーバーサンプリングレートの例示的組み合わせの表を示す。
図４６ａおよび４６ｂは、ビットストリームモードで動作し、ビットストリームフレーム形式を使用するときの統一バス通信プロトコルに対するバス周波数、チャネルの数、およびオーバーサンプリングレートの例示的組み合わせの表を示す。
図４７は、ハイブリッドワードモードで動作するときの統一バス通信プロトコルに対するバス周波数、チャネルの数およびタイプの例示的組み合わせの表を示す。
図４８ａ、４８ｂ、および４８ｃは、ビットストリームモードで動作し、統一ビットストリームフレーム形式を使用するときの統一バス通信プロトコルに対するバス周波数、チャネルの数およびタイプの例示的組み合わせの表を示す。
図４８ａ、４８ｂ、および４８ｃは、ビットストリームモードで動作し、統一ビットストリームフレーム形式を使用するときの統一バス通信プロトコルに対するバス周波数、チャネルの数およびタイプの例示的組み合わせの表を示す。
図４８ａ、４８ｂ、および４８ｃは、ビットストリームモードで動作し、統一ビットストリームフレーム形式を使用するときの統一バス通信プロトコルに対するバス周波数、チャネルの数およびタイプの例示的組み合わせの表を示す。
図４９ａは、統一バス通信プロトコルにおいてデジタルワード形式でＮビットを符号化するための一般的形式の例示的実施形態を示す。
図４９ｂは、携帯電話システムのためのビットストリーム符号化形式とともに使用されることができる、いくつかの一般的オーバーサンプリング係数の実施例を示す。
図４９ｃは、文字列符号化形式の可能な組み合わせの実施例を示す。
図５０ａは、フラクショナルフローを実装するために使用されることができるアルゴリズムの例示的実施形態を示す。
図５０ｂは、例示的シナリオに対する図５０ａのアルゴリズムの計算の実施例を示す。
図５０ｃは、種々の再生シナリオに対するフラクショナルフローに使用されることができる種々の値の実施例を示す。
図５１ａは、統一バス通信プロトコルを使用するディスプレイを伴う制御システムの例示的実施形態を示す。
図５１ｂは、統一バス通信プロトコルを使用する携帯電話システムの例示的実施形態を示す。
図５２ａは、統一バス通信プロトコルを使用する住宅用安全システムの例示的実施形態を示す。
図５２ｂは、統一バス通信プロトコルを使用する家庭用娯楽システムの例示的実施形態を示す。
図５２ｃは、統一バス通信プロトコルを使用する家庭用娯楽システムの例示的実施形態を示す。
図５２ｄは、統一バス通信プロトコルを使用する計装システムの例示的実施形態を示す。
図５２ｅは、統一バス通信プロトコルを使用して通信することができる、電子キーの例示的実施形態を示す。
図５２ｆは、統一バス通信プロトコルを使用して通信することができる、メモリスティックの例示的実施形態を示す。
図５２ｇは、統一バス通信プロトコルを使用して通信することができる、加入者識別モジュール（ＳＩＭ）カードの例示的実施形態を示す。
図５２ｈは、統一バス通信プロトコルを使用して通信することができる暗号化クレジットカードの例示的実施形態を示す。
図５２ｉは、統一バス通信プロトコルを使用する心拍数モニタシステムの例示的実施形態を示す。
図５３は、統一バス通信プロトコルに従ってバスを動作させる方法の例示的実施形態を示す。
図５４は、汎用同期化方法の例示的実施形態の略図である。
図５５ａおよび５５ｂは、それぞれ、真の同期化パターンが伝送されたデータ中で送信される第１のシナリオ、ならびに真および偽の同期化パターンが伝送されたデータ中で送信される第２のシナリオの略図である。
図５５ａおよび５５ｂは、それぞれ、真の同期化パターンが伝送されたデータ中で送信される第１のシナリオ、ならびに真および偽の同期化パターンが伝送されたデータ中で送信される第２のシナリオの略図である。
図５６は、並列実装を利用する汎用同期化方法の別の例示的実施形態の略図である。
図５７は、汎用同期化方法とともに使用されることができる、ワードモード同期化方法の例示的実施形態の略図である。
図５８ａは、欠落した同期化パターンを取り扱うために使用され、かつ図７のワードモード同期化方法とともに使用され得る、方法の例示的実施形態の略図である。
図５８ｂは、現在の検索位置がフレームまたはチャネルの最大長を超えるかどうかをチェックするために図５７の方法とともに使用され得る、方法の例示的実施形態の略図である。
図５９は、汎用同期化方法とともに使用されることができる、ビットストリームモード同期化方法の例示的実施形態の略図である。
図６０は、汎用同期化方法の別の例示的実施形態の略図である。
図６１ａは、欠落した同期化パターンをチェックするために使用されることができ、かつ図６０の汎用同期化方法とともに使用され得る、別の方法の例示的実施形態の略図である。
図６１ｂは、フレームオーバーラン（すなわち、フレーム内で可能であるよりも長期間にわたる同期化パターンの欠如）をチェックするために使用されることができ、かつ図６０の方法とともに使用され得る、方法の例示的実施形態の略図である。
図６２は、図６０の汎用同期化方法とともに使用され得る、ビットストリームモード同期化方法の別の例示的実施形態の略図である。
図６３は、図６２のビットストリームモード同期化方法とともに使用され得る、ビットストリーム更新方法の例示的実施形態の略図である。
図６４は、迅速再同期化方法の例示的実施形態の略図である。
図６５は、図６０の汎用同期化方法とともに使用されることができる、クロックゲーティング方法の例示的実施形態の略図である。
図６６は、無線通信で統一バス通信プロトコルの種々の実施形態をどのようにして使用されることができるかという実施例を示す。
図６７は、同期化ワードのためのフィールドおよびビット割付の別の例示的実施形態の略図である。
図６８は、ワードモードでの図６７のＳワードのデータ同期化フィールドへのデータ動作を示す、別の例示的タイミング図である。
図６９ａは、統一バス通信プロトコルの例示的実施形態に対するマスタデバイスまたはスレーブデバイスに使用されることができる、レジスタの定義の別の実施例である。
図６９ｂは、サブグループ当り使用されることができる、種々の最大チャネルを示す実施例である。
図６９ｃは、１つのデバイスグループアドレスに割り当てられたデバイスを有する、システムの例示的実施形態の略図である。
図６９ｄは、３つのデバイスグループアドレスに割り当てられたデバイスを有する、システムの例示的実施形態の略図である。
図７０は、Ｘワードで設定され得る、関数および対応するビット設定の別の例示的リストを示す。
図７１は、デバイスをバスに連結するためにリングトポロジーを使用するシステムの例示的実施形態であり、本システムは、統一バス通信プロトコルを使用する。
図７２は、デバイスをバスに連結するためにパイプトポロジーを使用するシステムの例示的実施形態であり、本システムは、統一バス通信プロトコルを使用する。
図７３は、多くのデバイスをバスに連結するためにパイプ制御を使用するシステムの例示的実施形態であり、本システムは、統一バス通信プロトコルを使用する。
図７４は、デバイスをバスに連結するために１次元交互リングトポロジーを使用するシステムの例示的実施形態であり、本システムは、統一バス通信プロトコルを使用する。
図７５は、デバイスをバスに連結するために２次元リングトポロジーを使用するシステムの例示的実施形態であり、本システムは、統一バス通信プロトコルを使用する。
図７６は、多くのデバイスをバスに連結するためにパイプ制御を使用するシステムの別の例示的実施形態であり、本システムは、統一バス通信プロトコルを使用する。
図７７ａは、２Ｘオーバークロックデータスロットの実施例のタイミング図である。
図７７ｂは、オーバークロックデータスロットを利用するデバイスに使用され得る、タイミングパラメータ値の例示的実施形態を示す表である。
図７７ｃは、２倍のオーバークロッキングがある実施例に対するバス上のデータ転送およびタイミングの説明図である。
図７７ｄは、レジスタがオーバークロッキングを実装するための例示的設定、および関連節電の推定値の表である。
図７８ａは、１度にデータの複数のビットを送信するためのタイミングおよび電圧レベルスキームを示す。
図７８ｂは、オーバークロッキングモードを使用して、デバイスがデータスロット中で複数のパックしたビットを送信するときに使用され得る、例示的符号化の表である。
図７９は、ＭＡＳＴＥＲ ＩＮＩＴＩＡＴＥＤ ＤＥＶＩＣＥ ＷＡＫＥ ＵＰ ＦＲＯＭ ＳＬＥＥＰモード中にスレーブデバイスによって見られるデータの実施例である。
図８０ａは、統一バス通信プロトコルを使用してポートまたはデバイスのために設定することができる、種々の電力消費レベルまたは電力管理モードの代替実施形態の実施例である。
図８０ｂは、例示的ＵＡＲＴタイミング仕様の表である。
図８１ａは、同期化に２つのスロット、データに１つのスロットを利用する、単一ワイヤ信号伝達システムの実施例である。
図８１ｂは、同期化に２つのスロット、データに４つのスロットを利用して、クロックおよびデータ情報の両方を転送する単一ワイヤ信号伝達システムの実施例である。
図８１ｃは、同期化に１つのスロット、データに４つのスロットを利用し、それによって、帯域幅を増加させ、電力消費を低減させる単一ワイヤ信号伝達システムの実施例である。
ここで、概念の１つ以上の実施形態の実施例を提供するように、種々のシステムまたはプロセスを以下で説明する。以下で説明される実施形態は、請求項のうちのいずれも限定せず、請求項のうちのいずれかは、以下で説明されるものとは異なるプロセスまたはシステムを対象とし得る。請求された特徴は、以下で説明されるいずれか１つのシステムまたはプロセスの特徴の全てを有するシステムまたはプロセスに、あるいは以下で説明されるシステムまたはプロセスの複数または全てに共通する特徴に限定されない。以下で説明されるシステムまたはプロセスは、請求項のうちのいずれかに記載される実施形態ではない可能性がある。本書で請求されていない、以下で説明されるシステムまたはプロセスで開示される任意の概念が、別の保護機器、例えば、継続特許出願の主題であり得、出願者、発明者、または所有者らは、本書でのその説明によって、任意のそのような概念を放棄し、否定し、または一般公開に捧げることを意図しない。
さらに、例証を簡単および明確にするために、適切であると見なされる場合、参照数字が、対応または類似する要素を示すように図の間で繰り返され得ることが理解されるであろう。加えて、本明細書で説明される実施形態の徹底的な理解を提供するために、多数の具体的詳細が記載される。しかしながら、これらの具体的詳細を伴わずに、本明細書で説明される実施形態が実践され得ることが、当業者によって理解されるであろう。他の場合において、周知の方法、手順、および構成要素は、本明細書で説明される実施形態を曖昧にしないよう詳細に説明されていない。また、本説明は、本明細書で説明される実施形態の範囲を限定すると見なされるものではない。
また、本明細書で使用される場合、連結されるという用語は、用語が使用される文脈に応じて、いくつかの異なる意味を有することができることにも留意されたい。例えば、連結という用語は、機械的、電気的、光学的、または通信的な意味合いを有することができる。例えば、いくつかの文脈では、連結という用語は、２つの要素またはデバイスを互に物理的に接続できるか、または例えば、ワイヤまたはケーブル等の物理的連結を介して、１つ以上の中間要素またはデバイスを通して互に接続できることを示す。いくつかの文脈では、連結という用語は、無線信号または光学信号等の他の手段を通して、２つの要素またはデバイスを接続できることを示す。いくつかの文脈では、連結という用語は、例えば、電気、光学、または無線信号等の信号を通して、要素またはデバイスが通信可能に互に接続され得ることを示す。さらに、「通信連結」という用語は、要素またはデバイスが、電気的に、光学的に、または無線で、データを別の要素またはデバイスに送信するとともに、別の要素またはデバイスからデータを受信できることを示す。
また、本明細書で使用される場合、「マスタ」および「スレーブ」という用語は、純粋に技術的な観点から意図され、具体的には、１つの要素またはデバイスが命令または制御信号を別の要素またはデバイスに提供するホストデバイスまたは要素と、周辺デバイスまたは要素との間の技術的関係を表すことにも留意されたい。したがって、本明細書で使用される場合、「マスタ」および「スレーブ」という用語の使用は、ここで与えられる技術的意味を超えるどんな意味合いをも持つように意図されていない。
また、通信プロトコルは、バス通信プロトコルとして説明され、要素を一緒に連結する物理的バスを示す、種々の例示的実施形態が提供されるが、本明細書で説明される通信プロトコルの種々の実施形態はまた、無線または光学インターフェース等の非物理的インターフェースを経由して実装されることができることにも留意されたい。
本明細書で使用される場合、「実質的に」、「約」、「おおよそ」および「ほぼ」等の程度の用語が、最終結果が著しく変更されないような修正用語の合理的な量の偏差を意味することに留意されたい。これらの程度の用語は、この偏差が、それが修正する用語の意味を無効にしないであろう場合、修正用語の最大で±１０％の偏差を含むものと解釈されることが可能である。また、本明細書で使用される場合、要素は、１つ以上の機能を行うように「構成」または「適合」されているとして説明され得る。概して、機能を行うように構成または適合されている要素は、その機能を行うために適しているか、その機能を行うように動作可能であるか、またはその機能を行うことが可能である。さらに、用語「ｃｕｒｒｅｎｔ」は、本明細書において、「電流」（単位アンペアで測定される量）を意味するために使用されるが、これが、現在、今生じているイベントを指す場合があり得、特別な場合におけるその意味は、文脈から概ね明らかである。
さらに、以下の節おいて、実施形態の異なる側面が、より詳細に定義される。定義される各側面は、それとは反対に明確に示されない限り、任意の他の側面と結合され得る。特に、好ましい、または有利であるとして示される任意の特徴は、好ましい、または有利であるとして示される少なくとも１つの他の特徴と結合され得る。好ましい、または有利であり得る特徴または構成要素は、必ずしも不可欠ではない。
発明を実施するための形態は、モバイルデバイスの一般的説明から始まり、次いで、異なるタイプのデータ形式をサポートすることができる一方で、より少ない数のワイヤを用いてデバイスを連結するために使用されることができる、統一バス通信プロトコルの例示的実施形態を続けて説明する。したがって、統一バス通信プロトコルは、異なる形式で数値データを生成するが、同一のバスに連結されることができる、デバイス用の統一インターフェースとしての役割を果たす。
統一バス通信プロトコルは、マスタデバイスとスレーブデバイスとの間、２つのマスタデバイスの間、２つのスレーブデバイスの間、およびマスタデバイスと１つより多くのスレーブデバイスとの間等の少なくとも２つのデバイスの間の通信を可能にする。デバイス間のデータ通信は、概して、特に指定がない限り、連続クロックを利用し、通信は、特に指定がない限り、双方向であり得る。
数値データは、オーディオデータ、または電流、電圧、圧力、温度等の測定データであり得る。数値データは、最初に、ビットストリーム形式またはデジタルワード形式でデバイスによって生成されることができる。デジタルワードは、２進コード化ワード、および浮動小数点ワード（すなわち、符号なし、または２の補完ワード）を対象とするように意図されている。
ワードモードでは、デジタルワードは、別の形式に変換されることなく、バスに沿って伝送されることができる。ビットストリームモードでは、データは、ビットストリームフレーム形式、または一種のビットストリームフレーム形式である統一フレーム形式のいずれかを使用して、パッケージ化される。ビットストリームフレーム形式では、ビットストリームが、フレームチャネルを使用して、異なるビットストリームデータチャネルから１度に１ビット伝送される。ビットストリームデータという用語の代わりに、パルス密度変調データ（ＰＤＭ）データというよう用語が時として使用されることに留意されたい。
データチャネルという用語は、概して、ある形式でデータを生成または受信するチャネルを指す。したがって、ワードデータチャネルは、デジタルワードデータを備え、ビットストリームデータチャネルは、ビットストリームデータを備える。
フレームチャネルという用語は、フレームチャネルが多重化され、フレーム中であるタイムスロットが与えられる、ビットストリームフレームまたは統一ビットストリームフレーム中のデータのチャネルを定義するために使用される。
統一フレーム形式では、少なくとも１つのワードデータチャネルに対するデジタルワードが、ビットストリームに変換され、１度に１ビット伝送される、少なくとも１つの仮想フレームチャネルがある。統一フレーム形式では、１つ以上のビットストリームデータチャネルからビットストリームデータを受信する、少なくとも１つのビットストリームフレームチャネルもあり得る。ビットストリームフレーム形式および統一フレーム形式は、制御フレームチャネル中にコマンドワードのビットストリームを含み、これは、削減された数の端子の使用により費用削減をもたらす。これらのフレーム形式を、本説明において以降でさらに詳細に説明する。
ビットストリームデータは、一連のビットとして伝送され、パルス密度変調（ＰＤＭ）データと称されることもある、データである。それらは、典型的には、デルタシグマ変換器の出力等のオーバーサンプリングされたシステムの出力として生成される。オーバーサンプルレートは、サンプリングクロックとデシメーション後の最終出力サンプルレートとの間の比（または補間については逆も同様）を示すために使用される。ビットストリームは、電気通信およびオーディオ用途においてデータを転送するため、および（例えば、スーパーオーディオＣＤ（ＳＡＣＤ）上で）記憶形式として使用される。
デジタルワードは、デジタル形式でアナログ値を表すために使用される、ある分解能を有する０および１のシーケンスである。例えば、１６ビットデジタルワードは、各ビットが０または１であり得る、１６ビットを有する。デジタルワードは、パルス符号変調（ＰＣＭ）と呼ばれる方法を使用して生成されることができ、その場合、デジタルワードは、ＰＣＭワードまたは（オーディオ用途については）オーディオワードと称される。ＰＣＭワードは、ＣＤ、Ｂｌｕ−ｒａｙ（登録商標）プレーヤ、ＤＶＤプレーヤ、コンピュータ、スマートフォン、ラップトップ、タブレット等を含む、種々のデバイスでのデジタルオーディオに使用される。
バス上で通信されるデータは、同期化データ、制御データ、数値データ、およびクロック信号を含む。電力もまた、バスを経由して伝送されることができる。統一バス通信プロトコルは、バスに使用され得るワイヤの数の削減を可能にし、概して、詳細に説明されるように、単一ワイヤバスまたは２ワイヤバス上で実装されることができる。単一ワイヤバスは、同期化データ、制御データ、数値データ、クロック信号、および電力を伝送するために、１本のワイヤを使用する。２ワイヤバスは、同期化データ、制御データ、数値データ、および電力を伝送するために第１のワイヤを、クロック信号を伝送するために第２のワイヤを使用することができる。したがって、バスおよび関連統一バス通信プロトコルは、ピンまたはワイヤの数が限定される動作、または雑音排除性に関する高い信頼性が所望される動作に使用され得る。本明細書で説明されるバスおよび関連統一バス通信プロトコルは、特に指定がない限り、同一のクロック信号によって全て同期化され、通信リンクを提供するために、フレーム形式に従って特定の瞬間にバスを放電する、可変数のデバイスの連続動作を可能にする。システムクロック周波数が低い実施形態では、バス上の帯電を維持するように、１つ以上のバスホルダを追加することができる。
発明を実施するための形態の第２の部分は、マスタデバイスと、または本明細書で説明される統一バス通信プロトコルの種々の実施形態のうちの少なくとも１つを利用するバスと同期化するためにスレーブデバイスによって使用されることができる、同期化方法の種々の例示的実施形態を提供する。同期化方法は、概して、ワードモードで順次に順番付けられ得る、一連のデータビット（すなわち、１および０）である、特定の同期化パターンを検索するための技法を伴い、または同期化パターンのビットは、他のデータビットと多重化または連動され得るが、依然としてビットストリームモードで、同一の順番で伝送される。
一般に、同期化方法のうちの少なくとも１つは、バスが初期化され、ある期間にわたって動作した後に、スレーブデバイスがバスにアタッチすることを有利に可能にするために使用され得る。これは、ホットプラグインと称される。したがって、スレーブデバイスは、この情報を伝えられることなく、どのような動作モードおよびフレーム形式がバス通信プロトコルに使用されているかを自力で決定することができ、これは、有利であり、概して、従来のバス通信プロトコルに対して行われていない。
バスアーキテクチャでは、多くの場合、デバイスが、例えば、使用されている間にバスを使用する必要があるときを、ならびに、数値データおよびコマンド命令の伝送のため等の使用の性質を信号伝達するための機構がある。しかしながら、バス制御は、多数の非同期プロセスが効率的にバスを共有しようとしているとき、ならびにこれらのプロセスがビットストリームデータおよびデジタルワードデータ等の異なるデータ形式を使用するときに、極めて複雑になり得る。例えば、従来のバスシステムでは、異なるインターフェースが、種々の種類のデータをサポートするために必要とされる。実施例として、ＰＣＭインターフェースは、ビットストリームデータではなくデジタルワードデータをサポートし、ビットストリームインターフェースは、デジタルワードデータをサポートしない。いくつかの用途では、センサが、バイナリワードを使用するナイキスト型変換器（例えば、温度センサ、加速度計、およびディスプレイ）を使用し、いくつかの用途では、ビットストリームインターフェースが、ビーム形成、能動雑音消去、または低遅延制御用途等の低遅延制御用途に使用されるため、多くの場合、両方のタイプのデータを使用するシステムがある。従来のバスシステムは、デジタルワードデータを通信する１つのインターフェース（４本のバスワイヤを必要とするＭｃＢＳＰインターフェース等）、ビットストリームデータを通信する別のインターフェース（さらに４本のバスワイヤを必要とする少なくとも１つのＭｃＰＤＭインターフェース等）、および制御データ用の別のインターフェース（さらに２本のバスワイヤを必要とするＩ２Ｃ等）を使用し、合計で少なくとも３つのインターフェースならびに少なくとも１０本のバスワイヤおよび端子を使用する。これは、関与する構成要素に対する費用および余分な空間要件を追加するとともに、電力消費を増加させる。さらに、そのようなシステムが外部デバイスとともに使用されるとき、複数のコネクタが使用され、より広い空間要件をもたらす。
したがって、本明細書で説明される少なくとも１つの実施形態では、本明細書で説明される統一バス通信プロトコルの一側面は、より少数のワイヤ、したがって、より少数の端子を使用しながら、ビットストリームデータ、デジタルワードデータ、および制御データを取り扱うことができる統一インターフェースの提供である。低遅延および高速過渡応答等のビットストリーム処理の利点は、デジタルワード形式の使用を回避することによって維持されることができる。したがって、本明細書で説明される統一インターフェースの少なくとも１つの実施形態の側面は、ビットストリーム処理のための同一の待ち時間（すなわち、１ビット待ち時間）を達成するために、ビットストリームデータを多重化できることである。さらに、デジタルワードデータは、１度に１ビット伝送されることができ、各ビットがビットストリームデータと多重化され、デジタルワードデータインターフェースの使用を排除する。加えて、同期化データおよびコマンドデータ等の制御データは、ビットストリーム形式に変換され、統一バス通信プロトコルを使用して多重化データの一部として組み込まれることができ、これは、外部インターフェース（例えば、Ｉ２Ｃ）の使用を排除し、また、ロボットプログラム可能マルチフォーマットデータインターフェースも提供する。したがって、統一バス通信プロトコルの少なくとも１つの実施形態の側面は、ＰＣＭ／ＴＤＭ／Ｉ２Ｃストリームをトンネリングするため、および低遅延でビットストリームを伝送するためのサポートを含む。
クロックデータはまた、（１ワイヤバス実施形態では）制御データに組み込まれることもでき、またはそれは、（２ワイヤバス実施形態では）別個のワイヤを使用して提供されることができる。別のワイヤ上でクロック信号を伝送することにより、スレーブデバイスの実装が単純化されることを可能にし、また、クロックジッタへの影響も低減させる。
したがって、統一バス通信プロトコルは、システムの具体的要件に応じて、１本または２本のワイヤを使用して実装されることができる（例えば、ヘッドセットインターフェースとして、または一般的なバスシステムとして）。しかしながら、代替実施形態では、本明細書で説明される統一バス通信プロトコルは、２本より多くのワイヤを有するバスとともに使用されることができることに留意されたい。バスが１本より多くのワイヤを使用する実施形態は、より高い帯域幅、および物理層でのいくつかの単純化を可能にすることができる。
デジタルワードデータをビットストリームデータと多重化するために、本明細書で説明される少なくとも１つの実施形態では、統一インターフェース中の１つ以上のフレームチャネルを仮想フレームチャネルとして割り付けることができ、デジタルワードデータは、データチャネルに対するデータの適正な順番を維持しながら、ビットストリームデータとともに１度に１ビット多重化される（すなわち、インターリーブまたはインターレースされる）。また、特定の実施形態に応じて、帯域幅制御と、異なるサンプリングレートでサンプリングされるデータを組み合わせることとのうちの少なくとも１つを可能にする、ビットストリームデータを使用するフレームチャネルとデジタルワードデータを使用するフレームチャネルとの間のプログラム可能な組み合わせがある実施形態もあり得る。制御データを他のタイプのデータとともに１度に１ビット多重化またはインターレースすることができるように、統一インターフェースの少なくとも１つの実施形態では、制御チャネルも割り付けられる。
本明細書で説明される少なくとも１つの実施形態では、統一バス通信プロトコルの側面は、例えば、より効率的に、電気通信用途（例えば、１９．２および１３．０ＭＨｚ）で一般的に使用されているもの等の種々のクロック周波数およびサンプルレートをサポートすることをより容易にする、変動フレーム長の使用である。さらに、統一バス通信プロトコルは、ＳＬＩＭｂｕｓバス通信プロトコルのために選択され、１２．２８８ＭＨｚ用途に適している、７６８ビットのフレーム長等の他の一般的に使用されているフレーム長に適応することができる。統一バス通信プロトコルによって提供される制御機能性は、Ｉ２Ｃバス通信プロトコルより幅広い機能性を有し、例えば、少なくともいくつかの実施形態では、オーディオに使用されるもの等の特別な機能をサポートする。統一バス通信プロトコルの少なくとも１つの実施形態は、制御データと同時に、低遅延を伴うビットストリームデータの等時性転送をサポートする。
さらに、本明細書で説明される少なくとも１つの実施形態では、バス構造は、統合、電力消費、および経済的理由で低ゲート総数が有利である、センサ用途およびオーディオ用途で使用するために好適である、低複雑性を有する。低ゲート総数は、本明細書で説明される統一バス通信プロトコルの種々の実施形態に従って通信および同期化するために、同期エンジンおよび関連ハードウェアを使用する、マスタおよびスレーブデバイスの両方について達成されることができる。低ゲート総数はまた、集積回路（ＩＣ）実装において、より低いドライバ複雑性、より小さいシリコン面積、およびより低い費用ももたらす。さらに、統一バス通信プロトコルがＩ２Ｃトンネリングに適しているため、レガシーシステムは、わずかな努力でサポートされ続けることができる。
本明細書で説明される少なくとも１つの実施形態では、統一バス通信プロトコルの側面は、スレーブデバイスの状態の連続監視のためのサポートである。これは、いかなるハンドシェイキングも伴わずに、スレーブデバイスのホットプラグインおよび除去を可能にする。これはまた、可能な限りバスを妨げないために、エラーの場合にスレーブデバイスがバスから自ら退場することも可能にする。したがって、スレーブデバイスが統一バス通信プロトコルを使用してバスを停滞させることは可能ではなく、これは、Ｉ２Ｃバス通信プロトコルの場合には当てはまらない。さらに、エラーの検出および補正は、本明細書で説明される統一バス通信プロトコルの少なくともいくつかの実施形態では、ＳＭｂｕｓ通信プロトコルと比較してはるかに速く実装されることができる。例えば、ＳＭｂｕｓは、エラーを検出する前に約３５〜４０ミリ秒を要し得る。停滞したバスの検出は、内部タイムアウト機能によって起動される（バス上にアクティビティがない場合）。この状況は、本明細書で説明される統一バス通信プロトコルの少なくとも１つの実施形態を使用して、はるかに速く発見されることができる。いくつかの最悪のシナリオでは、スレーブデバイスがバスとの同期化に戻るため約５０〜１００ミリ秒を要し得るが、典型的には、本明細書で説明される統一バス通信プロトコルの少なくとも１つの実施形態については、約１〜１０ミリ秒を要するであろう。
ここで図１を参照すると、可搬性電子デバイス１０の斜視図が示されている。本実施例では、可搬性電子デバイス１０は、携帯電話またはスマートフォン等の移動通信デバイスである。しかしながら、本明細書で説明される実施形態は、電話に限定されず、異なるデータ形式用の統一インターフェースを提供するバス通信プロトコルから利益を享受することができる、任意の電子デバイスに拡張されることができることを理解されたい。そのような電子デバイスの実施例は、概して、携帯電話無線オーガナイザ、携帯情報端子、コンピュータ、ラップトップ、ハンドヘルド無線通信デバイス、無線対応ノートブックコンピュータ、タブレットコンピュータまたは電子書籍リーダ、電子セキュリティデバイス、無線インターネットアプライアンス等の任意の可搬性電子デバイスを含む。他の実施例が、本説明の全体を通して提供される。移動式である、本明細書に記載される電子デバイスは、概して、可搬性であり、したがって、バッテリ電源型であり、限られた処理能力を有し得、その場合、本明細書で説明される統一バス通信プロトコルの実施形態のうちの少なくとも１つ等の統一データインターフェースを提供するバス通信プロトコルを使用することが有益である。
可搬性電子デバイス１０は、表示画面１４と、キーボード／キーパッド１６と、一式のボタン１８と、トラックパッドまたはトラックボール等のユーザ入力デバイス２０とを含む、本体１２を有する。ユーザ入力デバイス２０は、ジョイスティック、スクロールホイール、ローラホイール、マウスまたはタッチパッド等、または別のボタンとして提供されることもできる、ユーザ動作型ポインティングまたは入力デバイスを表すことが理解されるであろう。可搬性電子デバイス１０は、当業者に周知であるため、示されていない、または説明されていない他の部品を含む。可搬性電子デバイス１０はまた、ジャックを受け取るための少なくとも１つのポートも含むが、これは図１に示されていない。
ここで図２を参照すると、可搬性電子デバイス１０の一部分のブロック図が示されている。可搬性電子デバイス１０はさらに、可搬性電子デバイス１０内に統合されるヘッドセットまたはヘッドホンインターフェースチップ等のチップ３２に接続される、コントローラ３０を含む。コントローラ３０は、プロセッサまたは専用回路を使用して実装されることができる。チップ３２は、ビデオケーブルまたはヘッドセットケーブル等のケーブル４０に関連付けられるジャック３８を受け取るためのポート３６と統合される、スイッチマトリクスおよびジャック構成検出部分３４を含む。スイッチマトリクス３４は、ジャック３８内の対応するワイヤまたはライン４４ａから４４ｄを用いて信号を受信および伝送するための複数の個々の入力および出力ポート４２を含む。
ジャック３８内のワイヤ４４ａから４４ｄは、オーディオおよびビデオライン等の信号ラインを表す。一式の個々のライン、典型的には、４本のラインは、他の数のワイヤを伴う他のジャック構成が考慮されるが、可搬性電子デバイス１０と、ヘッドセット等、ケーブルの他方の側に位置するデバイスとの間の通信を可能にする。一実施形態では、ワイヤ４４ａおよび４４ｂは、一対のオーディオラインであり得、ワイヤ４４ｃは、接地ラインであり得、ワイヤ４４ｄは、マイクロホンラインであり得る。しかしながら、ラインのうちの１本のみが通信に使用され、それによって、単一ワイヤバス実施形態のための通信バスとしての機能を果たす。残りのラインは、他の機能性に使用され得る。典型的には、１本のラインが、接地に使用されるであろう一方で、残りの２本のラインは、ヘッドホン出力に使用され得る。別の構成では、１本のラインがバス通信に使用され得、１本が接地に使用され得、第３のラインが電力に使用され得、最後のラインが、ビデオ信号の伝送のため、または他の機能性のための別個のクロックラインとして等、他の目的で残される。他の実施形態では、単一ワイヤバスが、デバイス間のデジタルまたはアナログ伝送で使用され得る。代替として、２ワイヤバス実施形態は、以下でさらに詳細に説明されるように、２つのチップの間で通信を提供するために有用である。
ここで図３ａを参照すると、バスシステム５０の例示的実施形態の概略図が示されている。バスシステム５０は、可搬性電子デバイスまたは可搬性電子デバイス内のヘッドセットインターフェースチップ等のマスタデバイス５２と、ヘッドセット等のスレーブデバイス５４とを含む。１つだけのスレーブデバイス５４が示されているが、複数のスレーブデバイスがマスタデバイス５２との通信のためにバスシステム５０に連結され得ることが理解されるであろう。したがって、スレーブデバイス５４について本明細書で提供される説明は、概して、バスシステム５０に接続される他のスレーブデバイスに適用されることができる。
マスタデバイス５２またはスレーブデバイス５４は、ベースバンドプロセッサまたは移動処理ユニットに接続される、集積回路間（Ｉ２Ｃ）インターフェース５６を含み得る。マスタデバイス５２またはスレーブデバイス５４はまた、デジタルオーディオデータ用のＩ２Ｃインターフェースを含み得る。Ｉ２Ｃインターフェース５６およびシリアルインターフェース５８への入力または入力信号６０は、外部クロック信号６０ａ（ＥＸＴ ＣＬＫ）、Ｉ２Ｃクロック信号６０ｂ（Ｉ２Ｃ ＣＬＫ）、およびＩ２Ｃデータ信号６０ｃ（Ｉ２Ｃ ＤＡＴ）を含み得るが、それらに限定されない。低速シリアルインターフェース５８の出力は、同軸ケーブル等のケーブル６２を介して、スレーブデバイス５４に接続される。上記で説明されるように、ケーブル６２内のワイヤまたはラインのうちの１本は、スレーブデバイス５４とマスタデバイス５２との間の通信に使用されるバス６４を提供し、単一ワイヤバスとして見なすことができる。バス６４は、ピンまたはワイヤの数が限定される場合に、または雑音排除性に関する高い信頼性のために使用され得る。他の実施形態では、２ワイヤバスを使用することができる。
単一ワイヤバス実施形態では、単一のワイヤが、単一のバスサイクルでのクロックおよびデータの両方の伝送を含むが、それに限定されない、複数の機能を組み合わせ得る。動作時に、Ｉ２Ｃインターフェース５６は、バス６４を経由してデータを取り出し、スレーブデバイス５４に送信する。他の実施形態では、バス６４を経由した通信は、ベースバンドプロセッサまたは別の処理ユニットへの接続を介して制御され得る。したがって、マスタデバイス５２の制御は、Ｉ２Ｃインターフェース５６を介したもの、別の制御インターフェースを通したもの、または限定されないが、ＰＩＮＧ、ＲＥＡＤ、ＷＲＩＴＥ、およびＦＵＮＣＴＩＯＮコマンドまたは動作等の種々の動作をマスタデバイス５２に行わせる、ベースバンドプロセッサまたは他の処理ユニットへの接続の一部としてのものであり得る。本明細書で説明される少なくとも１つの実施形態では、各フレームが１つだけの動作によって定義されるため、ＰＩＮＧ、ＲＥＡＤ、ＷＲＩＴＥ、およびＦＵＮＣＴＩＯＮコマンドは、同一のフレーム中で起こらないであろう。これらの動作を、本説明の全体を通してさらに詳細に説明する。
マスタデバイス５２は、スレーブデバイス５４または複数のスレーブデバイスがバス６４に同期化されることを可能にするために、フレーミング情報を生成する。一実施形態では、フレーム長は、コマンドデータの各ブロックの開始間の分離距離を提供する、８ビットレジスタによって決定される。別の実施形態では、測定単位は、４ビットに等しいニブルである。フレーム長は、コマンドパターンによって決定され、一実施形態では、ワードモードで、２８ニブルのデフォルト同期分離値を伴う４８ビットであり得、それによって、３８４ビットのフレーム長をもたらす。
動作時に、同期化（同期）信号、情報の制御信号、データ、クロック信号、および電力が、バス６４を経由してマスタデバイス５２とスレーブデバイス５４との間で伝送される。したがって、バス６４は、いくつかの外部デバイスの連続動作を可能にし、全てのデバイスは、同一のクロック信号によって同期化される。クロック信号は、シグマデルタ変換器等の内部回路のため、または複雑な論理回路の連続動作のために、サンプリングクロックとして使用されることができる。他の実施形態では、以下でさらに詳細に説明されるように、バス６４上にアクティビティがないときに電力を節約するように、クロック信号が静的低論理レベルまたは静的高論理レベル等の定常レベルで保たれる場合があり得る。
バス６４を経由して通信する構成要素のサイズは、本明細書で説明される統一バス通信プロトコルの少なくとも１つの実施形態を使用することによって減少させられ得る。例えば、図２の可搬性電子デバイス１０で実装される場合、統一バス通信プロトコルは、バス６４が単一のワイヤを経由してクロック信号およびデータを伝送することを可能にし、これは、チップ３２中で占有されるピンの数を削減し、それによって、他のピンポート４２が、他の機能性に使用されること、またはプリント回路基板（ＰＣＢ）レベルでチップの全ピン総数、シリコン面積、または費用を削減することを可能にする。
ここで図３ｂを参照すると、マスタデバイス５２をバス６４に連結するためのインターフェース回路７０の実施例を示す、バスシステム５０の概略図が示されている。この概略図は、主にバスの単一ワイヤバージョンに対するものであるが、また、２ワイヤバージョンにおけるデータラインに使用することもできる。スレーブデバイス５４をバス６４に連結するために、同様の回路を使用することができる。インターフェース回路７０は、充電トランジスタ７２と、放電トランジスタ７４と、電力トランジスタ７６と、抵抗器Ｒ１とを含む。充電トランジスタ７２は、バス６４上で論理「１」をアサートするために使用され、放電トランジスタ７４は、バス６４上で論理「０」をアサートするために使用される。電力トランジスタは、通常は直列終端抵抗器Ｒ１を通して提供される電流よりも多くの電流が使用されるときに、迅速にスレーブデバイス（例えば、バッテリ）を充電するために使用され得る。この配列では、バス６４は、信号伝達速度が、電力消費、雑音排除性、および帯域幅の間の妥協である、オープンコレクタおよびオープンドレインタイプ等の時間制約型実装に悩まされない。電力トランジスタ７６は、随意的であり、デバイスを充電し、通信がない時に外部デバイスに電力供給するために、いくつかの実施形態に含まれ得る。電力トランジスタ７６は、レジスタによって制御され、フレームの開始時に更新され得る。
この特定の例示的実施形態では、充電トランジスタ７２および電力トランジスタ７６が、ＰＭＯＳトランジスタである一方で、放電トランジスタ７４は、ＮＭＯＳトランジスタである。充電トランジスタ７２のソースノードは、供給電圧ＶＳＳに連結され、充電トランジスタ７２のゲートノードは、低速シリアルインターフェース５８の第１のピンに連結され、充電トランジスタ７２のドレインノードは、放電トランジスタ７４のドレインノードに連結される。放電トランジスタ７４のゲートノードは、低速シリアルインターフェース５８の第２のピンに連結され、放電トランジスタ７４のドレインノードは、接地に連結される。電力トランジスタ７６のゲートノードは、低速シリアルインターフェース５８の第３のピンに連結され、電力トランジスタ７６のドレインノードは、供給電圧ＶＳＳに連結され、電力トランジスタ７６のソースノードは、低速シリアルインターフェース５８の第４のピンおよびバス６４の第１のノードに連結される。抵抗器Ｒ１の１つのノードは、充電トランジスタ７２のソースノードおよび放電トランジスタ７４のソースノードに連結され、抵抗器Ｒ１の第２のノードは、バス６４の第１のノードに連結される。例示的実施形態では、抵抗器Ｒ１の抵抗は、インターフェース回路７０の出力抵抗が、概して、約７５オームであり、供給電圧ＶＳＳが３Ｖであり得るように、選択されることができる。
充電トランジスタ７２に接続される低速シリアルインターフェース５８のノードは、充電トランジスタ７２が全バスサイクルの開始時にバス６４を充電し得るように、低い電圧を印加する。その後、バス６４は、充電トランジスタ７２を動作停止することによって、浮動したままにされる。次いで、マスタデバイス５２は、バス６４を放電するであろう高い電圧を放電トランジスタ７４のゲートに印加することによって、放電トランジスタ７４を起動することによってバス６４を駆動し得る。抵抗器Ｒ１の後のバス６４の接続は、バス６４からデータを受信するために使用される（場合によっては、向上した設定／ホールドタイミングのマージンのために遅延が含まれ得る）。電力トランジスタ７６に連結される低速シリアルインターフェース５８のノードは、抵抗器Ｒ１を通して利用可能であるバス６４により大きい電力を供給するために使用される。これは、トランジスタ７２が起動された後に最初に全電力を印加すること（これが共鳴を減少させるであろう）等のある措置が講じられない限り、いくらかの初期共鳴につながり得る。
一実施形態では、バス６４は、低・高・浮動周期パターンを使用して実装されるが、代替として、高・低・浮動パターンとして実装され得る。データの実際の転送が、浮動期間中に起こる一方で、低・高（または高・低）期間は、電力を伝達するため、およびクロック同期化に使用される。スレーブデバイス５４またはマスタデバイス５２が論理ゼロを信号伝達したい場合、その特定のデバイスは、バス６４を以前と同一の状態で、すなわち、バス６４上に同一の値を伴って浮動したままにするであろう。スレーブデバイス５４またはマスタデバイス５２は、浮動期間中にバス６４を放電し、それによって、バス６４の状態を反対の論理レベルに変化させることによって、論理１を信号伝達し得る。信号伝達スキームの実施例は、スレーブデバイス５４が「０１１０」を書き込む、バス６４上のトランザクションのタイミング図を示す、図４ａに示されている。外部クロック信号は、典型的には、マスタデバイス５２に提供される（代替的な場合では、マスタデバイス５２がクロック信号を生成し得る）。マスタデバイス５２またはスレーブデバイス５４が３状態モードになるとき、これは、例証目的で図４ａに鎖線として描かれている。実践では、出力電圧は、バス６４上に残された残りの電荷によって決定されるであろう。しかしながら、バス６４が放電されると、何度デバイスがこの放電を試行しようとしても、さらなる電荷がないであろう。したがって、バス６４が放電されると、後続のデバイスによるバス６４の放電が検出されず、バス衝突が可能ではないので、この信号伝達スキームは、複数のデバイスが同時にバス６４を経由して信号伝達または通信しようとするときに、バス競合または混雑の低減または回避を可能にする。
図４ａの実施例によって見ることができるように、バス６４が４つの時間間隔において時間多重化されるように、タイミングがバス６４上で実装される。代替実施形態では、別の数の時間間隔を使用することが可能であり得る。図４ａの実施例については、第１の時間間隔では、マスタデバイス５２は、クロック周期の最初の２５％（すなわち、４分の１）の間、バス６４をアクティブローに駆動する。第２の時間間隔では、マスタデバイス５２は、クロック周期の第２の２５％の間、バス６４をアクティブハイに駆動する。低・高クロック遷移は、連続サンプリングクロック信号として使用され得る。第３および第４の時間間隔では、マスタデバイス５２は、スレーブデバイス５４またはマスタデバイス５２がバスをローにプルし、「１」を信号伝達しない限り、残りのクロック周期にわたってバス６４を浮動状態のままにする。例えば、第３の間隔では、スレーブデバイス５４は、例えば、クロック周期の５０〜６２％の間で始まって、バス６４をアクティブローにプルし得る。バス６４は、典型的には、クロック周期が完了する前に完全に安定化させられ得る。バス値は、クロック周期の終了間際で、例えば、クロック周期の８８〜１００％で、第４の間隔においてサンプリングされ、その後、マスタデバイス５２は、バス６４を再度アクティブローに駆動し始めるであろう。一実施形態では、クロックサイクルの最初の半分が、クロック信号に使用され得る一方で、クロックサイクルの第２の半分は、データ伝送に使用され得る。しかしながら、例えば、クロック信号については６７％、次いで、データ伝送については３３％等の、クロックサイクルの第１の割合がクロック信号に使用され、クロックサイクルの第２の割合がデータ伝送に使用される、クロックサイクルの他の分割が考慮される。
図４ａの実施例では、バス６４は、最初に、クロックサイクルの開始時にアクティブローである。特定の期間後、バス６４は、マスタデバイス５２によってアクティブハイに駆動される。スレーブデバイス５４が「０」を伝送することを希望すると、スレーブデバイス５４は、バス６４に何も行わない。次いで、「０」の値がマスタデバイス５２によって読み取られ、マスタデバイス５２の前のスレーブデバイス５４が、次のクロックサイクルに先立ってバス６４をアクティブローに駆動する。第２のクロックサイクル中に、マスタデバイス５２は、特定の期間後にバス６４をアクティブハイに駆動する。スレーブデバイス５４が「１」を伝送することを希望すると、スレーブデバイス５４は、バス６４をアクティブローにプルするか、または駆動し、次いで、値は、マスタデバイス５２およびスレーブデバイス５４によって読み取られる。バス６４がアクティブローであると、マスタデバイス５２は、バス６４をアクティブローに駆動しないが、図４ａに示されるように、その機能を果たし得る。第３のクロックサイクルでは、特定の期間後に、マスタデバイス５２は、バス６４をアクティブハイに駆動する。スレーブデバイス５４が「１」を伝送することを希望すると、スレーブデバイス５４は、バス６４をアクティブローにプルするか、または駆動し、次いで、値は、マスタデバイス５２およびスレーブデバイス５４によって読み取られる。第４のクロックサイクルの開始時に、バス６４はアクティブローであり、特定の期間後、マスタデバイス５２によってアクティブハイに駆動される。スレーブデバイス５４が「０」を伝送することを希望すると、値が読み取られた後まで、バス６４上にアクティビティがなく、次いで、マスタデバイス５２は、次のクロックサイクルに備えてバス６４をアクティブローに駆動する。
バスタイミングは、マスタデバイス５２がバス６４をアクティブローに駆動する期間中に、スレーブデバイス５４がバス６４をアクティブローにプルし続けることを可能にする。したがって、スレーブデバイス５４の出力ドライバの解放タイミングは、あまり厳密ではない。しかしながら、スレーブデバイス５４は、ライン遅延を含んで、マスタデバイス５２がバス６４をアクティブハイに駆動するときに、浮動出力を生成する。浮動期間がアクティブロー期間およびアクティブハイ期間より長い理由は、スレーブデバイス５４がマスタデバイス５２のタイミングに依存するので、スレーブデバイス５４がマスタデバイス５２と同一の時間量でバス６４をアクティブローに駆動することを可能にし、起動が開始するとき、その瞬間に対してある公差を許可するためである。さらに、バス６４上に遅延がある。
バス６４がマスタデバイス５２によってローにプルされるときのタイミングは、間違ったデータがマスタデバイス５２またはスレーブデバイス５４によってサンプリングされないように、特定の期間後である。したがって、スレーブデバイス５４は、マスタデバイス５２がバス６４をハイにプルするときに浮動出力を有する。
マスタデバイス５２またはスレーブデバイス５４が３状態になるとき、これは、たとえ実際の電圧がバス６４に書き込まれた以前の値によって決定されようとも、鎖線によって表される。バス６４が浮動する期間は、非常に短いため、バス６４に連結された寄生静電容量により、安定して保たれ得るか、またはシステム５０内に少なくとも１つのバスホルダを含むことによって、より長い期間にわたって安定して保たれ得る。したがって、バス６４上の電荷および電圧は、静的にアンロードされるか、または高インピーダンスによってロードされる場合に、安定していると見なされ得る。
スレーブデバイス５４は、ある時間間隔でバス６４を起動し、これは、ＰＬＬ、遅延ロックループ（ＤＬＬ）、または単純遅延回路を使用して、ローカルクロックを実装することによって行われることができる。遅延回路は、固定電流によって交互に充電され、次いで、バス６４が起動およびサンプリングされるべき点を決定するためにコンデンサ上の充電電圧を使用している、２つのコンデンサを備え得る。これら２つのコンデンサは、１つの固定クロックエッジから次の固定クロックエッジまで充電され、このサイクルを開始する前に放電され得る。情報が転送されていない長い期間中、クロック信号を高いレベルまでゲート制御することによって、バス６４をアイドル状態にさせることが可能である。この場合、バス６４を再起動するために、わずかな遅延が生じるであろう。マスタデバイス５２がタイミングを制御するため、概して、いかなるアナログ制御遅延も使用されない。
一般に、浮動または３状態期間中のバス６４の状態の読み取りが一意的に定義されるように、十分に小さいバス静電容量、および十分に高いクロック周波数が使用される。バスシステム５０がプリント回路基板上で実装される場合、いくつかの実施形態では、データエラーから保護するように十分大きい電荷を提供するために、小型コンデンサが使用され得る。この場合、小型であるが有限のバス静電容量が使用されるか、または代替として、安定したバス値を維持するようにバスホルダを使用して（例えば、背面連結された２つのインバータを使用して）実装される。この方法は、わずかな漏出電流がバス６４上に残された任意の電荷をゆっくりと放電し得るが、バスホルダが値を安定して保つであろう、バス６４の低周波数動作のために選択され得る。バスホルダは、通常、その動作に関連付けられる電力効率損失を制限するように、マスタデバイス５２で実装されるであろうが、また、データ完全性目的でスレーブデバイス５４に実装されることもできる。バス６４が単一のワイヤを使用して実装されるときの例示的実施形態のタイミング特性が、表１に示されている。
ここで図３ｃを参照すると、２ワイヤバスシステムの例示的実施形態が示されている。本実施例では、マスタデバイス１は、低速シリアルインターフェースを通して、Ｉ２Ｃインターフェース、ＴＤＭインターフェース、ビットストリームインターフェース、およびＩ２Ｓインターフェースに連結される。次いで、マスタデバイス１は、本明細書で説明される統一バス通信プロトコルの実施形態のうちの少なくとも１つに従って動作し得る、２ワイヤバスを介して、スレーブデバイス１、スレーブデバイス２、およびマスタデバイス２に連結される。２ワイヤバスは、クロック情報を搬送する第１のワイヤと、データ、同期化、およびコマンド情報を搬送する第２のワイヤとを有する。本実施例では、スレーブデバイス１および２ならびにマスタデバイス２の各々は、低速シリアルインターフェースを介してバスに連結される。スレーブデバイス１はまた、第２のビットストリームインターフェースにも連結される。スレーブデバイス２はまた、第２のＩ２Ｓインターフェースにも連結される。マスタデバイス２はまた、第２のＩ２Ｃインターフェースおよび第２のＴＤＭインターフェースにも連結される。
別個のクロックおよびデータラインを伴う２ワイヤバスが使用されるとき、クロック信号は、ＤＡＴＡライン上で信号伝達されるような情報が有効であるか、または有効ではないときについてのタイミング情報を提供するにすぎないであろう。場合によっては、情報は、単一のクロックエッジ上で、または両方のクロックエッジ上で転送され得る。場合によっては、ＤＡＴＡライン上の情報は、クロックラインの電力消費を削減するために、単一のクロックサイクル内で２回以上変化し得る。
ここで図４ｂを参照すると、２本のワイヤを使用してバス６４が実装されるときの例示的タイミング図が示されている。２本のワイヤとともにプロトコルを使用するとき、１つのクロックエッジ上のみ（立ち上がりまたは立ち下がりのいずれか）で、または両方のクロックエッジ上でデータを転送することが可能である。両方のクロックエッジを使用することの利点は、より高い帯域幅およびより低い電流消費を可能にすることである。しかしながら、インターフェースの物理的特性が選択されると、バス半径に制約がある。１つだけのクロックエッジが使用される場合、クロック周波数が低減される限り、非常に長いバス半径を使用することが可能である。しかしながら、２つのクロックエッジが使用されるとき、マスタデバイス５２の近くに位置するスレーブデバイスは、マスタデバイス５２からより遠く離れて位置するスレーブデバイスからサンプリングされる前にデータを出力し始め得る。この問題を解決する１つの方法は、以前のデータスロット中で３状態にさせられていたデバイスに対してデータがバス６４で有効にされる前の時間が、デバイスがデータ状態から３状態になるために要する時間より長いことを確実にすることである。さらに、データがクロックエッジ上で即時にバス６４から時間記録されている間、バス６４へのデータの出力クロッキングを少し遅延させることによって、タイミングのマージンが向上させられ得る。いくつかの実施形態では、高い周波数、または大型バス直径での動作を可能にするために、タイミングのマージンは、クロック周波数に依存するように調整され得る。例として、データは、より低い動作周波数のために、クロック遷移後に、より長時間にわたって安定して保たれることができる。他の場合において、タイミングのマージンの固定パラメータを使用し、２つのスレーブデバイスが異なる時間にクロック信号を受信するときの問題（マスタデバイス５２の近くに位置する１つのスレーブデバイスに、マスタデバイス５２から遠く離れて位置するスレーブデバイスからの結果を上書きさせ得る）を回避するために、大型バス直径を伴うシステムについて、１つおきのチャネルが空である（効果的に３状態にさせられている）ビットストリームモードを使用することが決定され得る。代替実施形態では、スレーブデバイス５４をバス６４に接続するために、例えば、リング構造またはパイプ構造等の異なる構造を使用することができる。これらの構造は、図７１から７６に関してより詳細に説明される。いくつかの実施形態では、マスタデバイス５２は、パイプまたはリング構造への直接接続を含み得る。他の実施形態では、ハブデバイスが、１ワイヤまたは２ワイヤ多重ドロップバスと代替的なパイプまたはリングトポロジーとの間のインターフェースの役割を果たし得る。
この２ワイヤバスの実装は、Ｉ２Ｃ実装および同様のオープンコレクタ構造実装と比較して電力消費を削減し、Ｉ２Ｃおよび同様のオープンコレクタ構造実装の場合のように、帯域幅と電力消費との間の妥協を推断しない。場合によっては、統一バス通信プロトコルを使用するバス６４の２ワイヤ実施形態は、ＳＬＩＭｂｕｓより４０％低い電力消費、および２倍の帯域幅をもたらす。さらに、いくつかの実施形態では、統一バス通信プロトコルを実装するために、ＳＬＩＭｂｕｓで使用されるのと同一の物理層を使用することができる。
少なくともいくつかの実施形態では、バスホルダをマスタデバイス５２で実装することができる。これは、スレーブデバイスがほとんど存在しない状況および多くのスレーブデバイスが存在する状況で、予測可能な雑音性能をもたらす。バス６４に接続されたデバイスに電力が印加されないとき、たとえ電力を伴わないデバイスがバス６４に依然として接続されていたとしても、バス６４を動作させることが依然として可能であるべきである（例えば、電力が印加されていないときに、（静電放電）ＥＳＤ構造がバス６４を停滞させるべきではない）。２本のワイヤを使用するときのバス６４の例示的実施形態の電気的特性が、表３に示されている。
電力効率が、バス６４にアタッチされたデバイスの数とともに直線的に劣化するため、可能な限り少ないデバイスをバス６４に接続させることが、電力に関してより効率的なはずであることに留意されたい。複数のデバイスが単一のバスラインにアタッチされ得る場合、結果として生じる電力消費を低下させるように、各デバイスの入力静電容量を低減させることが有利である。代替として、デバイスのうちのいくつかが１つのバスに連結され、他のデバイスが別のバスに連結され、マスタデバイス等の両方のバスに共通するデバイスがあるように、１つより多くのバスが使用される実施形態があり得る。
一般に、スレーブデバイス５４は、ＰＩＮＧ動作中に信号を能動的にプルダウンすることによって、マスタデバイス５２と通信することを希望することを示すことができる。次いで、この場合、ＲＥＡＤ、ＷＲＩＴＥ、またはＦＵＮＣＴＩＯＮ動作を介して、スレーブデバイス５４とマスタデバイス５２との間でデータを伝送することができる。マスタデバイス５２はまた、独力でＲＥＡＤ、ＷＲＩＴＥ、またはＦＵＮＣＴＩＯＮ動作を開始することもできる。通信を開始するために、マスタデバイス５２およびスレーブデバイス５４は、以下でさらに詳細に説明されるように、互に同期化される。
統一バス通信プロトコルの例示的実施形態では、フレームは、３つの制御ワード、すなわち、同期化ワード（すなわち、Ｓワード）、および、スレーブデバイスへおよびスレーブデバイスからのコマンドを通信するための２つのコマンドワード（すなわち、ＸワードおよびＹワード）を含むように定義される。制御ワードは、長さ１６ビットであり得、概して、全フレーム中に送信される。他の実施形態では、制御ワードの長さは、何らかの他の長さ、例えば、８ビットであり得、フレーム中の制御ワードの数は、３とは異なり得る。しかしながら、制御ワードは、動作モード、すなわち、ワードモードおよびビットストリームモードに応じて、フレーム中に異なって伝送されることができる。例えば、ワードモードでは、異なるオーバーサンプル率およびクロック周波数のサポートを可能にする、制御ワードの間の距離が変化し得る。ビットストリームモードでは、データビットは、各制御ワードにおいて個々のビットの間にインターリーブされ、このデータインターリービングの１つの利益は、複数の低遅延ビットストリームデータチャネルのサポートである。
例示的実施形態では、マスタデバイス５２は、状態監視（すなわち、ＰＩＮＧ動作）、レジスタを読み取ること（すなわち、ＲＥＡＤ動作）、レジスタに書き込むこと（すなわち、ＷＲＩＴＥ動作）、および関数を実行すること（すなわち、ＦＵＮＣＴＩＯＮ動作）を含む、いくつかの制御機能を果たす。動作のタイプは、マスタデバイス５２によって決定される。いくつかの実施形態では、マスタデバイス５２は、システムコントローラ（図示せず）によって制御される。これらの場合、マスタデバイス５２とシステムコントローラとの間のインターフェースは、Ｉ２Ｃバスを使用して、またはこれら２つのシステム構成要素を１つのデバイス（すなわち、プロセッサ）に組み込むことによって実装されることができる。
スレーブデバイス５４と通信するために、マスタデバイス５２は、スレーブデバイス５４（または複数のデバイス）が、それらの内部タイミングまたはクロックをマスタデバイス５２と、および結果としてバス６４とも同期化するために使用し得る、同期化データを有する同期化（すなわち、同期またはＳ）ワードを伝送する。一般に、マスタデバイス５２がフレーム中で伝送する第１の制御ワードは、Ｓワードである。したがって、Ｓワードは、フレームを開始するために使用されることができる。伝送される第１のビットは、Ｓ１４ビット等が後に続く、Ｓ１５ビットである。ワードモードにおいて、ビットが互の直後に伝送されるであろう一方で、ビットストリームモードにおいて、これらのビットの伝送の間に一定の間隙が生じるであろう。入出力（Ｉ／Ｏ）方向（例えば、ｒ／ｗ）が、マスタデバイス５２に関して与えられる。
ここで図５を参照すると、Ｓワードのフィールドおよびビット割付の例示的実施形態の略図が示されている。本実施例では、Ｓワードは、４つのフィールド、すなわち、ＤＡＴＡ ＳＹＮＣＨＲＯＮＩＺＡＴＩＯＮフィールド、９ビットＣＯＮＳＴＡＮＴ ＳＹＮＣ ＳＹＭＢＯＬフィールド、ＤＹＮＡＭＩＣ ＳＹＮＣ ＳＹＭＢＯＬフィールド、およびＩＮＴＥＲＲＵＰＴフィールドから成る。他の実施形態は、Ｓワードに他のフィールド、または図５に示されるフィールドより多いまたは少ないビットを使用し得る。これらのフィールドは、レジスタの１つ以上のビットを使用して実装されることができる。代替実施形態では、異なる実装をこれらのフィールドに使用することができ、フィールドが異なって順序付けられ得、または使用される他のフィールド、あるいは使用される他のレジスタがあり得る。
ＳワードのＤＡＴＡ ＳＹＮＣＨＲＯＮＩＺＡＴＩＯＮフィールドは、パリティビットＰＡＲ（Ｓ１５）と、確認ビットＡＣＫ（Ｓ１４）とを含む。パリティビットの計算は、新しいパリティビットを書き込む前に、最後のビットまでを含んで書き込まれる最後のパリティビットを含む、バス６４上で遭遇する全てのトラフィックに基づく（すなわち、パリティが完全フレームについて計算され得る）。パリティビットは、フレーム中の１に等しいビットの総数が偶数である場合に１であるように設定され、そうでなければ、パリティビットは、ゼロであるように設定される。電源投入時のマスタデバイス５２の初期パリティ値は、ゼロである。少なくとも１つの実施形態では、マスタデバイス５２は、バス６４にアタッチされる任意のデバイスが、信号完全性問題またはデータ衝突を検出できることを確実にするように、全ての動作（ＰＩＮＧ、ＲＥＡＤ、ＷＲＩＴＥ、およびＦＵＮＣＴＩＯＮ）に対してパリティ情報を書き込み得る。
確認ビットは、最後のフレーム中のバス６４上のトラフィックに基づいて計算される。スレーブデバイス５４は、スレーブデバイス５４へのＲＥＡＤ、ＷＲＩＴＥ、およびＦＵＮＣＴＩＯＮ動作中にデータ伝送が破損された場合に、論理低を信号伝達するべきである。パリティにエラーがない場合、スレーブデバイス５４は、論理１で応答するであろう。これは、Ｉ／Ｏ ＷＲＩＴＥ ＯＰＥＲＡＴＩＯＮＳ中の追加セキュリティのために有用である。スレーブデバイス５４は、エラーが発生した場合、例えば、パリティビットが間違っていた、またはバスエラーが発生したことを把握しているので、スレーブデバイス５４は、過去の動作に基づいて確認ビットを設定する。スレーブデバイスがバス６４上に存在しない場合、問題を示すバス信号伝達スキームの性質によって、論理低がバス６４からマスタデバイス５２に返されるであろう。以前の動作がＰＩＮＧ動作であった場合、パリティビットおよび過去のフレームのアクティビティ全体に基づいてエラーを検出した任意のスレーブデバイスは、このビットをアクティブにし得る（すなわち、論理１を書き込む）。これは、確認ビットがＰＩＮＧ動作中に効果的に反転させられることを意味する（論理ゼロはエラーなしを意味する）。エラーが検出された場合、マスタデバイス５２は、ＲＥＡＤ、ＷＲＩＴＥ、およびＦＵＮＣＴＩＯＮ動作後の欠落したＡＣＫビットについてはＩＯ ＥＲＲＯＲビット、ＰＩＮＧ動作中のＮＡＣＫについてはＢＵＳ ＥＲＲＯＲをアクティブにし得る。ワードモードでのＳワードのＤＡＴＡ ＳＹＮＣＲＨＯＮＩＺＡＴＩＯＮフィールドへの動作を示すタイミング図である、図６に示される実施例では、マスタデバイス５２は、タイムスロット０−９５中のアクティビティに基づいて、タイムスロット９６に偶数パリティを書き込む。スレーブデバイス５４は、タイムスロット９７中で応答する。ＲＥＡＤ、ＷＲＩＴＥ、およびＦＵＮＣＴＩＯＮ動作中に、スレーブデバイス５４は、エラーの場合に応答する（すなわち、ＮＡＣＫによって）のみであろう。
ここで図７を参照すると、異なるコマンド動作に基づいてマスタデバイス５２およびスレーブデバイス５４によって行われる、パリティおよび確認計算の例示的実施形態が示されている。パリティにエラーがない場合、アドレス指定されているデバイスが、論理１で応答する（すなわち、アクションをアクティブにする）であろう。これは、Ｉ／Ｏ ＷＲＩＴＥ動作中の追加セキュリティのために有用である。マスタデバイス５２からスレーブデバイス５４へのＷＲＩＴＥ動作中にパリティエラーがある場合、スレーブデバイス５４は、パリティエラーがあれば内部でＷＲＩＴＥ動作を完了せず、マスタデバイス５２は、ＩＯ ＥＲＲＯＲ割り込みでバスコントローラに応答するであろう。スレーブデバイス５４からのＲＥＡＤ動作中にパリティエラーがある場合、マスタデバイス５２がＩＯ ＥＲＲＯＲ ＩＲＱを生成するであろう一方で、スレーブデバイス５４は、マスタデバイス５２がアクティブＡＣＫを受信しなければ何もしないであろう。デバイスレジスタおよび最後に書き込まれたワードを読み取ることによって、どのデバイスが問題になっているかを識別することが可能である。新しいＲＥＡＤ、ＷＲＩＴＥ、またはＦＵＮＣＴＩＯＮ動作を行う前に、一実施形態では、現在のＩＯ動作が完了するまで待機すること、およびＩＯ ＥＲＲＯＲビットの状態をチェックすることが可能である。この方法論は、よりロバストなエラー性能を提供する。
したがって、統一バス通信プロトコルの少なくとも１つの実施形態の側面は、フレーム内の伝送される全てのデータを監視し、伝送されるデータのパリティを計算し、動作を行うためのコマンドを受信したバス６４にアタッチされた１つ以上のスレーブデバイスからのＲＥＡＤ／ＷＲＩＴＥ／ＦＵＮＣＴＩＯＮ動作の確認をチェックすることによって、データ完全性サポートを提供することである。マスタデバイス５２は、監視し、パリティを計算し、およびチェックするアクションを行うことができる。
いくつかの動作中、例えば、ＰＩＮＧ動作中に、特に１つのデバイスもアドレス指定されない。したがって、任意のデバイスがパリティエラーを検出することができる。次いで、マスタデバイス５２は、フレームの読み取りを完了すると、パリティビットに書き込み、パリティエラーを検出する任意のデバイスは、ＮＡＣＫ（否定応答）と同一の有効な機能を有する、論理１で応答するであろう。これは、１ワイヤおよび２ワイヤ実装の両方におけるバス６４が接続または機能性を可能にするので、複数のデバイスが同時に応答することを可能にする。一般に、特定のデバイスまたはデバイス群へのＲＥＡＤおよびＷＲＩＴＥ動作のように扱われ得る関数データを使用するコマンドを除いて、ＦＵＮＣＴＩＯＮ動作は、ＰＩＮＧ動作のように扱われ得る。
したがって、統一バス通信プロトコルの少なくとも１つの実施形態の側面は、フレーム内の伝送される全てのデータを監視し、伝送されるデータのパリティを計算し、動作を行うためのコマンドを受信した、バスにアタッチされた１つ以上のスレーブデバイスからのＲＥＡＤ、ＷＲＩＴＥ、またはＦＵＮＣＴＩＯＮ動作以外の動作に対する否定応答メッセージをチェックすることによって、データ完全性サポートを提供することである。マスタデバイス５２は、監視し、パリティを計算し、およびチェックするアクションを行うことができる。
少なくともいくつかの実施形態では、フレーム内のほとんどの誤った同期化位置を迅速に排除するために、ＣＯＮＳＴＡＮＴ ＳＹＮＣ ＳＹＭＢＯＬフィールド（Ｓ１３：Ｓ５）がスレーブデバイス５４によって使用されることができる一方で、現在の位置が確かにフレームの開始であることを検証するために、ＤＹＮＡＭＩＣ ＳＹＮＣ ＳＹＭＢＯＬフィールド（Ｓ４：Ｓ１）が使用される（本明細書で使用される命名法Ｓ１３：Ｓ１は、ビットＳ１３、Ｓ１２、Ｓ１１、Ｓ１０、Ｓ９、Ｓ８、Ｓ７、Ｓ６、Ｓ５、Ｓ４、Ｓ３、Ｓ２、およびＳ１を示すことに留意されたい）。このアプローチは、迅速なロック時間を得て、スレーブデバイス５４が、バス６４上のランダムな静的データによって生成される誤った開始にロックすることを防止するために役立つために使用される。例えば、次の９ビット｛Ｓ１３：Ｓ５｝＝“１０１１０００１１”は、スレーブデバイス５４によってランダムバスデータ上で迅速な初期同期化を取得するために使用されることができる定数である。したがって、Ｓワードの一定同期部分は、フレーム中の誤ったＳワードの可能性を低減させるために、スレーブデバイス５４によって使用される。例えば、Ｓワードであるように見えるデータが、他のスレーブデバイスによってバス６４を経由して伝送され得るが、マスタデバイス５２によって伝送されていないので、それは、誤っており、接続されていないスレーブデバイスによって無視されるべきである。したがって、Ｓワードの一定部分（すなわち、ＣＯＮＳＴＡＮＴ ＳＹＮＣ ＳＹＭＢＯＬフィールド）の値の選択は、Ｓワードとしてのその使用が損なわれないように、デジタルワード、オーディオデータ、またはビットストリームデータにおいて通常発生しないビットのパターンであるようなものである。
ＤＹＮＡＭＩＣ ＳＹＮＣ ＳＹＭＢＯＬフィールド（Ｓ４：Ｓ１）は、例えば、スレーブデバイス５４によって同期化にも使用される、ジェネレータ多項式Ｘ４＋Ｘ＋１、Ｘ８＋Ｘ５＋Ｘ４＋１、またはＸ１５＋Ｘ１４＋Ｘ１０＋Ｘ８＋Ｘ７＋Ｘ４＋Ｘ３＋１を用いて、周期的冗長チェック（ＣＲＣ）ジェネレータ等の疑似ランダムカウンタによって実装されることができる疑似ランダム値を備える。例えば、ＤＹＮＡＭＩＣ ＳＹＮＣ ＳＹＭＢＯＬフィールドは：｛Ｓ４，Ｓ３，Ｓ２，Ｓ１｝＝｛Ｓ３，Ｓ２，Ｓ１，（Ｓ４ ＸＯＲ Ｓ３）｝（最上位ビット（ＭＳＢ）が最初）のように更新されることができる。本実施例では、ＤＹＮＡＭＩＣ ＳＹＮＣ ＳＹＭＢＯＬフィールドは、リセット時に「１１１１」に初期化される。「００００」条件は使用されず、遭遇した場合には次のサイクル中に「１１１１」状態をもたらすものとする。１６進数でのシーケンス全体は、以下の通り、すなわち、｛Ｆ，Ｅ，Ｃ，８，１，２，４，９，３，６，Ｄ，Ａ，５，Ｂ，７｝である。
少なくともいくつかの実施形態では、疑似ランダム値はまた、同期化にも使用されることができ、これは、より迅速なロック時間を可能にし、スレーブデバイス５４がバス６４上のランダムデータによって生成される誤ったＳワードにロックする可能性を低減させるであろう。少なくとも１つの実施形態では、スレーブデバイス５４は、バス６４にロックする前に、疑似ランダムパターンを複数回検証することができる。少なくとも１つの実施形態では、スレーブデバイス５４は、バス６４上で通信することを可能にする前に、同期生成サイクル全体を検証するまで待機することができる。マスタデバイス５２との同期化を取得したことを決定するまで、スレーブデバイスが検出に使用し得る同期化パターンの数は、誤った同期化のエラーのどれほど低い確率が容認可能であるかという問題である。例えば、ロックが容認される前に、スレーブデバイス５４がＮ個のフレームを使用する場合には、これがランダムデータによって起こる可能性は１５−（Ｎ）であり、これは、非常に小さい確率であり、一定同期部分は、通常は一様に離間され、同期化中にも見出されるので、実践ではさらに低い。したがって、同期化（すなわち、ロック）が安全と見なされることを宣言する前に、より少ないまたは多い数の同期化パターン（したがってフレーム）が、異なる用途で使用され得る。代替実施形態では、スレーブデバイス５４は、バス６４にロックするために７つのフレームを使用し得る。他の実施形態では、異なる数のビットを一定同期部分および動的同期部分に使用することができる。代替実施形態では、ＤＹＮＡＭＩＣ ＳＹＮＣ ＳＹＭＢＯＬフィールドのコンテンツを生成するために、他の技法を使用することができる。
例えば、デジタルワードデータの伝送、ビットストリームデータの伝送等のためのバス６４の使用に応じて、ＣＯＮＳＴＡＮＴ ＳＹＮＣ ＳＹＭＢＯＬフィールドおよび／またはＤＹＮＡＭＩＣ ＳＹＮＣ ＳＹＭＢＯＬフィールドの値を生成するために、異なる値またはスキームが使用され得る。実施例として、Ｓワードに対する一定部分は、バス６４がワードモードで使用されるときには０ｘＢ２５（１６進数）であり得、Ｓワードに対する一定部分は、バス６４がビットストリームモードで使用されるときには０ｘＦＦＥであり得る。
ＩＮＴＥＲＲＵＰＴフィールド（ＩＲＱＳ（Ｓ０））は、優先的な割り込み制御を実装するためにＳワード中に含まれ、多くの使用シナリオに対する割り込み要求への高速応答を可能にすることができる。スレーブデバイス５４は、フレーム中にマスタデバイス５２への割り込みを生成することができる。スレーブデバイス５４は、即時注意を求める場合、ＩＮＴＥＲＲＵＰＴフィールド中で論理「１」レベルを信号伝達し、これは、この例示的実施形態ではＳワードの最後のビット中である。ＩＲＱビットは、一般的な割り込み制御として使用され、任意のフレーム中に任意のスレーブデバイスによってアクティブにされることができる。例えば、スレーブデバイス５４が送信すべき重要な状態メッセージを有する場合、ＩＲＱＳビットは、ＲＥＡＤ、ＷＲＩＴＥ、またはＦＵＮＣＴＩＯＮ動作を遅延させるために使用されることができる。これは、ＩＮＴＥＲＲＵＰＴフィールド中のビットをアクティブにすることによって行われる。いかなるスレーブデバイスもこのビットをアクティブにしていない場合（論理「１」がアクティブにすることを意味する）、またはＩＲＱＳ中断がＩＲＱマスクビットＢ４によって無効にされている場合（Ｓ０ ＤＥＬＡＹ ＥＮＡＢＬＥ、図２９ａおよび２９ｂ参照）、ＲＥＡＤ、ＷＲＩＴＥ、またはＦＵＮＣＴＩＯＮ動作が続行するであろう。この遅延は、スレーブデバイス５４が「１０」または「１１」に等しい状態レベルを有する場合にアクティブにされる（これは以下でさらに詳細に説明される）。したがって、スレーブデバイス５４は、フレーム中のこのＩＲＱＳビットに対するタイムスロット中に、その状態レジスタ（スレーブ状態ビットを保持する）のＭＳＢのコンテンツをバス６４上にコピーすることができる。スレーブ状態ビットは、ＸおよびＹワードの説明でさらに議論される。ＸおよびＹワードの部分中にスレーブ状態データを含むことにより、他のスレーブデバイスからのデータが収集されることを可能にする一方で、スレーブデバイスのうちの１つがエラーを有する場合にバス６４を無効にしない。一方で、ＩＲＱＳビットの値が非アクティブである場合、またはＩＲＱがＩＲＱマスクビットによって決定されるように許可されない場合（その場合、バス６４に連結されたバスの状態は、ＰＩＮＧ動作を使用してポーリングされる）、ＲＥＡＤ、ＷＲＩＴＥ、またはＦＵＮＣＴＩＯＮトランザクション／動作は、続行することを可能にされる。図８は、コマンド動作（ＰＩＮＧ、ＲＥＡＤ、ＷＲＩＴＥ、およびＦＵＮＣＴＩＯＮ）、割り込みマスクビットの値、および講じられるべき措置の種々の組み合わせを示す。
フレーム内の制御動作のタイプ（すなわち、ＰＩＮＧ、ＲＥＡＤ、ＷＲＩＴＥ、またはＦＵＮＣＴＩＯＮ動作）は、この例示的実施形態ではＸワードの最初の３つのビットによって決定される。これらのビットの後には、特定の動作によって使用される情報が続く。ＰＩＮＧ動作の場合、レジスタバンク選択ビットが、スレーブデバイス５４用の構成モードを決定するために使用され得、オーディオ用途については、これは、異なるオーディオモード間のシームレスな転送に使用することができるオーディオモードと称されることができ、この転送は、結果として生じるオーディオで不可聴である。データ同期化ビットは、スレーブデバイス５４中の少しのハードウェアを用いて、奇数サンプルレートおよび非同期転送をサポートするように含まれ得る。後続のビットは、ペアでグループ化され、バス６４にアタッチされた全てのデバイスの現在の状態を読み取るために使用される。他の実施形態では、別のマスタデバイスによってアクティブにすることができるＲＥＱＵＥＳＴ ＦＯＲ ＢＵＳビット、およびバス６４へのアクセスを許可するＲＥＬＡＳＥ ＢＵＳビットを含むことによって、マルチマスタ動作に対するサポートが達成される。このタイプの動作では、両方のマスタデバイスが同時にＸおよびＹワードでコマンドを書き込むことができるため、真のマルチマスタ動作が可能である。バス衝突がある場合、ゼロを書き込むが１をリードバックするデバイスが、アービトレーションを失うであろう。ＰＩＮＧ動作を「０００」に割り付けることによって、真のマルチマスタ動作をバス６４の連続監視と組み合わせることが可能である（すなわち、ＰＩＮＧ動作を行うマスタデバイスは、別のマスタデバイスがＲＥＡＤ／ＷＲＩＴＥまたはＦＵＮＣＴＩＯＮを要求する場合にアービトレーションを失うであろう）。
ＲＥＡＤ、ＷＲＩＴＥ、およびＦＵＮＣＴＩＯＮ動作は、情報をバス６４にアタッチされた１つの特定のデバイスに送信する。固有のスレーブアドレスに割り付けられたビット数は、この例示的実施形態では４ビットである。他の実施形態は、スレーブアドレスにより多いまたは少ないビットを使用することができる。実際のアドレスは、アドレス衝突が起こることを防止するように、すなわち、（通常は最大１１個のデバイスが使用されるが）多くても１６個のデバイスが同時にバス６４にアタッチされている限り、電源投入後に動的に割り当てられることができる。４ビットの後には、レジスタアドレスおよびデータ情報が続く。アドレスおよびデータフィールド長は、概して、動作のタイプ（８または１６ビットデータ）に依存し、Ｙワードに及ぶであろう。マスタデバイス５２は、現在のデータ転送に基づいて計算したパリティを書き込み、スレーブデバイス５４は、動作が成功したことを確認する。マスタデバイス５２およびスレーブデバイス５４の両方が、他方のデバイスが正しいデータの受信に失敗したかどうかを知るであろうため、このパリティ検証のためのアプローチは、余分なセキュリティを与える。
ＦＵＮＣＴＩＯＮ動作は、種々の目的で使用されることができる。例えば、少なくとも１つの実施形態では、ＦＵＮＣＴＩＯＮ動作は、ある状態にスレーブデバイス５４を設定するため、特定のデバイスについての情報を要求するため、または試験のために使用される。
ここで図９ａを参照すると、その中に、種々のコマンド動作のためのＸコマンドワードに対する種々のフィールドおよびビット割付が示されている。これらのフィールドは、レジスタの１つ以上のビットを使用して実装されることができる。代替実施形態では、異なる実装をこれらのフィールドに使用することができ、フィールドが異なって順序付けられ得、または使用される他のフィールド、あるいは使用される他のレジスタがあり得る。読み取り（ｒ）および書き込み（ｗ）方向は、マスタデバイス５２に対して定義され、すなわち、（ｗ）は、データフローの方向（すなわち、転送または伝送）が、マスタデバイス５２からスレーブデバイス５４であることを意味し、（ｒ）は、（ｗ）動作と比較してデータフローの反対方向を意味する。Ｘワードの構造は、どのような動作が現在進行中であるかに依存するであろう。図９ａは、いくつかの例示的組み合わせを提供する。本実施例では、Ｘコマンドワードは、ＣＯＭＭＡＮＤフィールドと、２つのＤＡＴＡ ＳＹＮＣＨＲＯＮＩＺＡＴＩＯＮフィールドと、ＳＬＡＶＥ ＤＥＶＩＣＥフィールドと、ＢＡＮＫ ＳＥＬＥＣＴフィールドと、ＡＤＤＲＥＳＳフィールドと、ＳＬＡＶＥ ＳＴＡＴＵＳ フィールドと、ＦＵＮＣＴＩＯＮフィールドとを備える。フィールドのうちのいくつかは、説明されるように、あるコマンド動作中にのみ使用される。ＦＵＮＣＴＩＯＮ動作が以下で議論されるときに、ＦＵＮＣＴＩＯＮフィールドを説明する。一般に、最初の３つのビット（Ｘ１５−１３）が、ＲＥＡＤ、ＷＲＩＴＥ、ＰＩＮＧ、ＦＵＮＣＴＩＯＮ、またはＯＴＨＥＲコマンド等のマスタデバイス５２によって発行されているコマンドを示す、コマンドフィールドの一部である一方で、残りのビットの構造は、選択されたコマンドに依存するであろう。図９ｂは、使用され得るＸワードの代替実施形態を提供する。この符号化は、ＢＡＮＫビットの復号および起動におけるいくらかの複雑性を犠牲にして、任意の動作モード（ＰＩＮＧ／ＲＥＡＤ／ＷＲＩＴＥ／ＦＵＮＣＴＩＯＮ）で非同期、分数、またはマルチフレームデータ転送を行うことが可能であるという利点を有する。
ＣＯＭＭＡＮＤフィールド（Ｘ１５：Ｘ１３）に関して、少なくともいくつかの実施形態では、コマンドは、この例示的実施形態では８または１６ビットＲＥＡＤ／ＷＲＩＴＥ、ＰＩＮＧ動作、またはＦＵＮＣＴＩＯＮ動作であり得る（より多いまたは少ないビットが他の実施形態で使用され得る）。一般に、ＰＩＮＧコマンドは、マスタデバイス５２がＲＥＡＤ、ＷＲＩＴＥ、またはＦＵＮＣＴＩＯＮコマンドを受信し、それを現在処理していない限り、常にアクティブである。
いくつかの実施形態では、Ｘ１２ビットは、ＰＩＮＧ動作中に使用されるＢＡＮＫビットまたはＢＡＮＫフィールドであり得る。ＰＩＮＧコマンドが発行されるとき、マスタデバイス５２は、データ転送の内部タイミングのために、どのレジスタバンクが全てのデバイスに使用されるべきかを示すためにＢＡＮＫビットを使用する。オーディオ用途では、ＢＡＮＫフィールドは、２つのレジスタバンクの間で切り替えて、オーディオモードを変更しながら再生中にいかなる誤作動も回避するために使用されることができる。一般に、ＢＡＮＫフィールドは、フレーム中のデータ伝送に使用することができる、異なるデータモードに対する異なるフレーム形式を特定する、異なるレジスタバンクの間で切り替えるために使用されることができる。異なるデータモードは、異なるオーディオシナリオに対して、異なるサンプリングレート、異なるチャネル選択、異なるポート選択、ビットストリームモードまたはワードモードを使用すること等を特定することができる。例えば、１つのデータモードでは、データチャネルからのデータは、フレーム中のタイムスロットの第１のセット中に配置されるように定義されることができ、第２のデータモードでは、同一のデータチャネルからのデータは、フレーム中のタイムスロットの第２のセット中に配置されるように定義することができる。ＰＩＮＧ動作を使用しないフレームに、ＢＡＮＫフィールドの以前の値が、レジスタ選択に使用され得る。スレーブデバイス５４は、アドレス指定されているとき、どのレジスタバンク上でＲＥＡＤ、ＷＲＩＴＥ、またはＦＵＮＣＴＩＯＮ動作を行うかを選択するために、ＢＡＮＫフィールドを使用する。スレーブデバイス５４は、１つより多くのデータ動作モードで変化する、全てのレジスタに対する少なくとも１つのシャドウレジスタを使用し得る。それは、内部レジスタおよび／または内部プログラムの間で選択するために使用され得る。エラーに対するロバスト性を提供するために、ＢＡＮＫフィールドは、変化が起こる前に、同一の値を伴って、２回等の１回以上読み取られることができる。
少なくとも１つの実施形態では、エラーに対するロバスト性を提供するために、ＢＡＮＫ ＳＥＬＥＣＴフィールドは、変化が起こる前に、少なくとも２つの連続フレーム中のこのフィールド内に同一の値があることを確実にするために、２回等の１回以上読み取ることができ、すなわち、本実施例では、レジスタバンクの変化は、少なくとも２つのフレームを要するであろう。
ＳＬＡＶＥ ＤＥＶＩＣＥフィールド（Ｘ１１：Ｘ８）は、ＲＥＡＤ、ＷＲＩＴＥ、またはＦＵＮＣＴＩＯＮ動作中に使用される。ＳＬＡＶＥ ＤＥＶＩＣＥフィールドは、バス６４にアタッチされるスレーブデバイスのアドレスを特定する。全てのスレーブデバイスは、電源投入後にゼロのアドレスを使用して、マスタデバイス５２と通信し始め、その後、それらは、マスタデバイス５２によって新しいアドレスを割り当てられるであろう。アドレス０−１２を伴うスレーブデバイスは、完全状態情報をマスタデバイス５２に通信することができる。この例示的実施形態では、アドレス１５は、バス６４にアタッチされるデバイスの全てへの情報のブロードキャストのために保留される。このブロードキャストは、例えば、全てのスレーブデバイスをリセットするように１つのコマンドを使用するために有用であり得る。
ＤＡＴＡ ＳＹＮＣＨＲＯＮＩＺＡＴＩＯＮフィールド（Ｘ１１−１０中のＤＳ０−ＤＳ１）は、いくつかのフレームにわたってデータを同期化するために使用され得、ＰＩＮＧ動作中に伝送される。スレーブデバイス５４は、データが伝送され始めるときを選択する、内部カウンタの開始を同期化するために、このフィールドを選択し得る。スレーブデバイス５４がデータ同期化ビットＤＳ０またはＤＳ１を使用する場合、それが１に設定される場合、スレーブデバイス５４は、その内部カウンタをリセットし（通常のフレーム開始時に起こり得る）、そうではなく、ＤＳ０またはＤＳ１ビットが０に設定される場合、これらの内部カウンタはリセットされない。これは、例えば、フラクショナルフローに対して、いくつかのフレームに最良適合するデータの伝送を同期化するために有用である。
ビットＲＥＱＵＥＳＴ（ＲＥＱ）ＢＵＳ ＡＣＣＥＳＳ（Ｘ９）は、ＰＩＮＧ動作中に使用される。このビットをアクティブにする（それを１に等しく設定する）ことによって、別のマスタデバイスは、バス６４へのアクセスを要求することができる。
ビットＲＥＬＥＡＳＥ（ＲＥＬ）ＢＵＳ（Ｘ８）は、ＰＩＮＧ動作中に使用される。現在のマスタデバイスがこのビットを起動する場合（反転論理については論理値０）、別のマスタデバイスが、コマンドをバス６４に送信し始めることを可能にされる。現在のマスタデバイス５２は、そうするように選択する場合、コマンドを同時に送信し得る。データアービトレーションは、２つのマスタデバイスの間に競合がある場合、どちらが特定のコマンドに対する要求を獲得するかを決定するであろう。別のマスタデバイスがＲＥＬＥＡＳＥ ＢＵＳビットを無視し、このフィールドが非アクティブ（例えば、論理１）であるときにコマンドワードに書き込み始める場合、これは、バスエラーと見なされるであろう。
代替実施形態では、Ｘ１２−Ｘ９ビットは、上記で説明されるようにデータ同期化（ＤＳ０−ＤＳ３）に使用されることができる。さらに、Ｘ８ビットを上記で説明されるようにＢＡＮＫビットとして使用することができる（例えば、図９ｂ参照）。
ＡＤＤＲＥＳＳフィールド（Ｘ７：Ｘ０）は、ＲＥＡＤ、ＷＲＩＴＥ動作、およびいくつかのＦＵＮＣＴＩＯＮ動作中に使用され、スレーブデバイス５４の内側で特定のレジスタアドレスを選択するために使用される、下位８ビットアドレスである。１６ビット動作が使用される場合、上位８ビットは、ゼロであると仮定され得る。
ＳＬＡＶＥ ＳＴＡＴＵＳフィールド（Ｘ７：Ｘ０）は、ＰＩＮＧ動作中に使用され、スレーブデバイスＳＴ１１からＳＴ８の部分に対する状態を提供する（残りの状態情報は、説明されるようにＹワードで提供される）。この例示的実施形態では、全てのスレーブデバイスは、２ビットから成る状態レジスタを含む。状態レジスタの値は、マスタデバイス５２が所与のスレーブデバイスに講じるべき措置を決定するために使用される。各スレーブデバイスは、ＸおよびＹワードで各スレーブデバイスに対する専用タイムスロットに書き込むことによって、状態情報で応答する。本実施例では、状態ビットの総数は２４であり、スレーブデバイスは、最初に最上位状態ビットを伝送する。状態ビットは、割り込みマスクビットの値に応じて、マスク割り込みを生成し得る。電源投入リセットイベント後に、全てのスレーブデバイスは、それらがバス６４にちょうどアタッチされたことを信号伝達するように、スレーブアドレスゼロで応答し始めるであろう。他の実施形態では、スレーブデバイスの状態レジスタは、使用される、より多くの状態レベルがある場合に、２つより多くのビットを有し得る。
この例示的実施形態では、２ビットを使用して、スレーブデバイス５４は、４つの異なる状態レベルを有することができる。「００」の状態レベルは、最低状態レベルであり、スレーブデバイス５４が最初にバス６４にアタッチされるが、バス６４にロックされない（すなわち、マスタデバイス５２に同期化されない）ときのスレーブデバイス５４の内側の初期値である。論理１のみが、（この例示的実施形態で使用される信号伝達スキームにより）バス６４の物理的動作に影響を及ぼすため、この状態値は、バス６４を不変のままにするであろう。「０１」の状態レベルは、スレーブデバイス５４がバス６４にロックしていることを信号伝達し、スレーブデバイス５４がバス６４に接続するとき、およびそこから接続解除するときを検出するために使用されることができる。これは、スレーブ状態レベルを読み取り、ＡＴＴＡＣＨＭＥＮＴビットを使用して割り込みを有効にすることによって監視され得る。この値は、ＰＩＮＧ動作に影響を及ぼす。「１０」の状態レベルは、バス６４にロックした後、スレーブデバイス５４への注意を要求するため（例えば、バッファレベルまたはエラー条件に起因して）に使用される。この条件は、ＡＴＴＥＮＴＩＯＮ割り込みマスクビットを有効にすることによって監視され得る。この状態レベルは、Ｓ０およびＳ０ ＤＥＬＡＹ ＩＲＱマスクビットが同時にアクティブ（すなわち、「１」）である場合に、ＲＥＡＤ、ＷＲＩＴＥ、またはＦＵＮＣＴＩＯＮ動作を遅延させるであろう。「１１」の状態レベルは、スレーブデバイス５４が、限定されないが、スレーブデバイス５４の温度が高すぎること、またはスレーブデバイス５４に危機的な電圧不足または過電圧があること等の迅速に対処される必要があり得る緊急事態を有することを信号伝達する。この条件は、ＡＴＴＥＮＴＩＯＮ ＩＲＱマスクビットを有効にすることによって監視され得る。この状態レベルもまた、Ｓ０ビットおよびＳ０ ＤＥＬＡＹ ＩＲＱマスクビットが同時にアクティブである（すなわち、論理レベル「１」に設定される）場合に、ＲＥＡＤ、ＷＲＩＴＥ、またはＦＵＮＣＴＩＯＮ動作を遅延させるであろう。
ここで図１０を参照すると、種々のコマンド動作のためのＹコマンドワードに対する種々のフィールドおよびビット割付が示されている。Ｙワードの構造もまた、どのような動作が現在進行中であるかに依存するであろう。一般に、Ｙワードは、マスタデバイス５２と１つ以上のスレーブデバイス５４との間で、データおよびおそらくアドレス情報を通信するために使用される。図１０は、いくつかの例示的組み合わせを提供する。この例示的実施形態では、Ｙコマンドワードは、ＡＤＤＲＥＳＳフィールドと、ＷＲＩＴＥ ＤＡＴＡフィールドと、ＲＥＡＤ ＤＡＴＡフィールドと、ＦＵＮＣＴＩＯＮフィールドとを備える。フィールドのうちのいくつかは、説明されるように、あるコマンド動作中にのみ使用される。これらのフィールドは、レジスタの１つ以上のビットを使用して実装されることができる。代替実施形態では、異なる実装をこれらのフィールドに使用することができ、フィールドが異なって順序付けられ得、または使用される他のフィールド、あるいは使用される他のレジスタがあり得る。ＦＵＮＣＴＩＯＮフィールドについては、ＦＵＮＣＴＩＯＮ動作が議論されるときに説明する。
ＡＤＤＲＥＳＳフィールド（ＡＤＤＲ７−０）は、スレーブデバイス５４に対する１６ビットアドレスを形成するために、Ｘワードでアドレスフィールドと一緒に使用され得る、８ビットアドレスである。
ＷＲＩＴＥ ＤＡＴＡフィールド（ＷＤ１５：０）は、スレーブデバイス５４中のレジスタに書き込まれるべき、マスタデバイス５２からのデータを含む。１６ビットＷＲＩＴＥ動作については、ワードＷＤ１５：０全体が使用される。８ビットＷＲＩＴＥ動作については、ＷＤ７：０のみが使用される。レジスタＷＤ１５：０は、マスタデバイス５２の外部制御によって設定されることができる。
ＲＥＡＤ ＤＡＴＡフィールド（ＲＤ１５：０）は、スレーブデバイス５４からマスタデバイス５２への読み取られるべきデータを含む。１６ビットＲＥＡＤ動作については、ワードＲＤ１５：０全体が使用される。８ビットＲＥＡＤ動作については、ＲＤ７：０のみが使用される。レジスタＲＤ１５：０は、マスタデバイス５２の外部制御によって読み取られることができる。
ここで図１１ａを参照すると、Ｘワードでの関数および対応するビット設定の例示的リストが示されている。他の実施形態では、他の関数および／またはビット設定を使用することができる。例えば、図１１ａに記載される関数の異なる部分的組み合わせを使用する、他の実施形態があり得る。これらの実施形態は、他の関数を追加し、ある関数を除去し、またはいくつかの関数の追加および他の関数の除去の両方を行うことができる。ＦＵＮＣＴＩＯＮ動作は、システム機能性の制御およびデバイス制御のために有用である、特別なコマンドの実行を開始するために使用され得る。いくつかの関数は、ブロードキャストをサポートし、すなわち、全てのポート（例えば、スレーブデバイス）が、このコマンドによる影響を受ける。ＸワードでのＦＵＮＣＴＩＯＮフィールド（Ｘ７：Ｘ４）の上位ビットは、図１１ａで定義される全ての関数について００００に等しい。関数が実装されていない場合、スレーブデバイス５４は、マスタデバイス５２からの対応する要求を確認（ＡＣＫ）するべきではない。マスタデバイス５２が複数のスレーブデバイスに書き込んでいる場合、スレーブデバイスは、この例示的実施形態では、代わりに否定応答（ＮＡＣＫ）を使用することができる。
ＲＥＱＵＥＳＴ ＩＤ関数（Ｘ３：Ｘ０＝００００）の実行は、システムで使用されるマスタデバイス５２を一意的に識別するため、または、マスタデバイス５２がこれらのスレーブデバイスを区別し、それらの各々に固有の個々のスレーブ番号（例えば、１−１４）を割り当てることができるようにバス６４にアタッチされた複数のスレーブデバイスを区別するために使用される。これは、同時にバス６４を介してマスタデバイス５２に接続されるいくつかのスレーブデバイスに対するサポートを可能にし、アドレス衝突問題（典型的にはＩ２Ｃバスプロトコルで見られる）を回避する。各スレーブデバイスは、製造業者部品ＩＤを有する。この名称は、製造業者コードおよび部品番号から成るであろう。少なくとも１つの実施形態では、製造業者コードは、個々のデバイスアドレスをバス６４に接続される各スレーブデバイスに割り当てるために、アービトレーション中に使用される。同一の部品番号を有するスレーブデバイスの状況は、以下で説明されるように、位置情報を追加することによって対処することができる。
リセットイベントがバス６４上で起こった後、全てのスレーブデバイスは、スレーブアドレスゼロ（すなわち、レジスタアドレス０ｘ００００）で設定情報を探すことから始めるであろう。マスタデバイス５２は、次いで、本説明において以降で説明される動的アドレス割当プロセスで説明されるように、アドレスゼロに書き込み、このアドレスから読み取ることによって、アドレスアービトレーションプロセスを開始するであろう。単一のマスタデバイス５２のみがあるので、位置フィールドは、マスタデバイス５２から読み取るときに「００００」に等しいであろう。
電源投入リセットイベント後、全てのスレーブデバイスは、それらのデバイスアドレスをゼロに設定し、マスタデバイス５２は、スレーブデバイスと通信してアドレスをそれらに割り当てる。スレーブデバイス５４は、バス６４にロックした後、ＰＩＮＧ動作中に「０１」以上の状態を示し、マスタデバイス５２は、新しいデバイスがバス６４にちょうどアタッチされたことを発見するであろう。マスタデバイス５２は、ＲＥＱＵＥＳＴ ＩＤ関数をアクティブにすることによって、アービトレーションプロセスを開始するであろう。スレーブデバイス５４は、この要求を受信すると、スレーブデバイス５４に関連付けられた内部識別（すなわち、固有の名称）を符号化するために使用される内部名称文字カウンタを有効にする。この瞬間にバス６４にロックされていないスレーブデバイスは、起動されず、このアービトレーションサイクル中に応答しないであろう。さらに、いかなるスレーブデバイスもバス６４に現在接続されていない場合、マスタデバイス５２は、フレームを完成させ続け、次いで、次のフレームサイクルでさらなるＰＩＮＧ動作を発行する。
後に、マスタデバイス５２は、スレーブデバイスゼロからのレジスタアドレスゼロから読み取るであろう。これは、特定の実装に応じて、１６ビットまたは８ビットＲＥＡＤ動作を使用して行われることができる。返される値は、スレーブデバイスアドレスゼロを伴ってバス６４にアタッチされた任意のスレーブデバイスの最高値部品ＩＤ（すなわち、固有の名称）の部品番号であろう。マスタデバイス５２は、固有のアドレスが割り当てられそうである全てのスレーブデバイスの固有の名称の第１のビットを読み取る。次いで、各スレーブデバイスの固有の名称の第１のビットが再検討される。それらが全て同一である、すなわち、全て「１」または全て「０」である場合、マスタデバイス５２は、スレーブデバイス名の次のビットに進むか、またはそれをポーリングする。「０」および「１」の組み合わせがある場合には、マスタデバイス５２は、バス６４の動的性質によりバス値を決定するであろうため、「１」を有する固有の名称のみを伴って継続する。換言すると、バス６４にアタッチされた１つより多くのスレーブデバイスがある場合、論理０を書き込もうとするが、論理１をリードバックする、任意のスレーブデバイスは、バックオフし、次のアービトレーションサイクルが始まることを待つであろう。マスタデバイス５２は、部品ＩＤが完全であることをスレーブデバイス５４が示すまで、アドレスゼロから読み取り続ける。これは、ゼロバイト、すなわち、０ｘ００によって示されることができる。次いで、マスタデバイス５２は、データビット３：０を設定することにより、所望のデバイス番号をレジスタアドレスゼロに書き込むことによって、個々のデバイスアドレスをこのスレーブデバイスに割り当てる。マスタデバイス５２は、現在のデバイスアドレスに書き込み、レジスタアドレスゼロでビット３：０を所望の値に設定することによって、スレーブデバイスのデバイスアドレスを以降で変更することができる。ＩＤを符号化するためのみに４バイトを使用する、短い符号化形式を使用することができる。スレーブデバイスが、読み取りシーケンスを完了する前に、アドレスゼロからの読み取り以外のＩＯ要求を受信する場合、バックオフしてプロセスを終了させ得る。
動的アドレス割当プロセスは、「アルファベット順」で、マスタデバイス５２がデバイスの固有の名称を再検討することを可能にし、より高い数値の名称値を伴うスレーブデバイスは、より低い数値の名称値を伴うスレーブデバイスの前または後のスレーブアドレスを割り当てられる。スレーブデバイス名の数値は、２進数として読み取られている値を用いた検索に基づくソーティングから決定される。単一の「１」値のみがある場合には、マスタデバイス５２は、この固有の名称に関連付けられるスレーブデバイスを第１のデバイスとして割り当て、それに固有のスレーブ値１−１４を割り当てる。少なくともいくつかの実施形態では、デバイス値１−１１のみが、全てのアタッチされたデバイスの連続監視を可能にするために使用されるが、デバイス値１２−１４は、デバイスグループ化のために保留される。次いで、それは、続けてバス通信に戻り、アドレスを必要とする次のスレーブデバイスに遭遇し、第１のスレーブデバイスとは異なるスレーブデバイスアドレスを割り当てるであろう。このアドレス割当は、バス６４にアタッチされた、割り当てられていないスレーブデバイスがなくなるまで継続する。各スレーブデバイスが固有の名称を有するので、マスタデバイス５２が、どのスレーブデバイスを現在のデバイスアドレスに関連付けるべきかを把握していないいかなる状況も生じないであろう。スレーブデバイスへの後続のＲＥＡＤ、ＷＲＩＴＥ、およびＦＵＮＣＴＩＯＮ動作では、割り当てられたスレーブアドレス１−１４は、スレーブデバイスを識別するために使用されるであろう。
２つ以上のスレーブデバイスが同一のチップを含む場合、これらのデバイスは、異なるＰＯＳＩＴＩＯＮ情報でプログラムされるか、または、位置に対して符号化すべき追加の端子を有し得る。単純な実施例として、単一の入力端子が、左右のチャネルの間で情報を提供することができる。１つの代わりに２つの端子を追加することによって、これらの端子の各々をＧＮＤ、ＶＤＤ、またはＦＬＯＡＴ（すなわち、接続されていない、または３状態、Ｚ）に接続することにより、最大９つの異なる位置を割り当てることが可能である（図１１ｂ−１１ｅ参照）。両方の端子は、最初に、入力端子と見なされる。図１１ｄでは、出力端子が浮動している（すなわち、オープン出力端子）場合には、１が入力端子に基づいてアドレスを送信することができる。出力浮動条件は、図１１ｅに示されるような回路によって決定されることができる。典型的には、値Ｘが内部状態マシンによって駆動されるであろう一方で、ＴＥＳＴは外部端子であり、Ｙは試験結果である。このＩ／Ｏ回路は、９つ全ての組み合わせを取得するために、ＳＥＬ＿ＩＮおよびＳＥＬ＿ＯＵＴ端子の両方に使用され得る。他の実施形態では、ＦＬＯＡＴ（Ｚ）条件に対する試験が除去され得、リング構造が依然として利用され得る。高値プルダウン抵抗器が、入力端子ＴＥＳＴへの接続を伴わずに電力消費を削減するように含まれ得るが、電力消費が問題ではない場合は随意的であり得る。入力Ｘに続くインバータからの出力が、典型的には、アクティブである場合には、代替として、２ｋΩ抵抗器が値を増加させられ、１００ｋΩ抵抗器が省略され得る。デジタルマイクロホン用のレガシーシステムとも適合性がある、例示的ピン構成が図１１ｄに示されている。図１１ｂおよび１１ｃに示されるような例示的符号化は、いかなるプログラミングも伴わず、かつ物理的レイアウトの変更を伴わずに、少なくとも９つの位置、および現在のレガシーシステムとの適合性を可能にする。図１１ｃに示されるように符号化されるリングトポロジーは、第１のデバイスを固定入力値に接続し、全ての後続のデバイスは、入力端子ＳＥＬ＿ＩＮを前のデバイスのＳＥＬ＿ＯＵＴ端子に接続するであろう。起動中、デバイスは、第１の値（０）から、Ｎ−１と番号付けされるであろう最後のデバイス（すなわち、リングトポロジーにおいてＮ個のデバイスが接続されている）まで増分することによって、それら自体を自動構成するであろう。このトポロジーは、９つより多くの位置を取得することができるという利点を有するが、単一のデバイスが故障した場合に、列挙も失敗するであろうという不利点を有する。したがって、それは、本実施例では０−８の固定アドレスを使用する（他の実施形態では他の範囲を使用することができる）図１１ｂの構成と比較して、よりエラーの傾向があり、あまりロバストではない。両方の場合において、デバイスは、最初に、内部位置の列挙が完了した後に、バス６４にアタッチされるべきである。各デバイスが、典型的には、前のデバイスから情報を受信するか、またはそれがリング内の第１のデバイスであることを確認するまで待機するため、このプロセスは、リングトポロジーについて、より長くかかるであろう。
実施形態では、スレーブデバイス５４がハードウェアエラー状態になり、リセットされる場合、そのスレーブアドレスは、ゼロのデフォルト値に設定される。スレーブデバイス５４がマスタデバイス５２との同期化を失う場合、その出力を無効にし、マスタデバイス５２との同期化を再獲得しようとする。スレーブデバイス５４は、その現在のデバイスアドレスを保ち、最後に取得されたコマンド分離値（本書において以降で説明される）を使用して検索し始めるべきである。同期化を再獲得した後、スレーブデバイス５４は、そのデバイス状態を「１０」に設定することによって、バスエラーを信号伝達し得る。次いで、マスタデバイス５２は、エラータイプについてスレーブデバイス５４に尋ね、それは、デバイスアドレスゼロ、レジスタアドレスゼロにおいて、ＳＬＡＶＥ＿ＳＹＮＣ＿ＥＲＲＯＲまたは「０ｘＦＦ」で応答し得る。スレーブデバイス５４が、読み取りシーケンスを完了する前に、アドレスゼロからＲＥＡＤ動作以外のＩＯ要求を受信する場合、バックオフしてプロセスを終了させるべきである。実施形態では、スレーブデバイス５４が動作中に同期化を失い、再同期化することができない場合には、マスタデバイス５２は、ＰＩＮＧ動作の使用によって２つのフレーム内でこのイベントについて知り、次いで、マスタデバイス５２の内側でＳＴＡＴＵＳレジスタの内側の値を変更し、ＡＴＴＡＣＨＭＥＮＴビットを設定するであろう。
要約すると、スレーブデバイス５４は、以下の状況下で、すなわち、電源投入リセット後、スレーブデバイス５４がバス６４にロックされていないとき、スレーブデバイス５４がマスタデバイス５２との同期化を失ったとき、別のスレーブデバイスがアービトレーションを獲得したとき、およびスレーブデバイス５４が各自の名称ＩＤの出力を完了したときに、スレーブアドレスの出力を非アクティブにする。
スレーブデバイス５４は、各自のレジスタをリセットし、マスタデバイス５２がＦＵＮＣＴＩＯＮ ＲＥＱＵＥＳＴ＿ＩＤを開始し、マスタデバイス５２によって書き込まれたデバイスアドレスがスレーブデバイス５４に等しいとき、そのＩＤの読み取りを準備する。別のスレーブデバイスが、このイベントが起こった後にバス６４にロックする場合、ＲＥＱＵＥＳＴ＿ＩＤコマンドを受信していないので、たとえそのデバイスアドレスがマスタデバイスアドレスに合致したとしても、アービトレートを開始するべきではない。したがって、電源投入リセット後、またはスレーブデバイスが自らをバス６４にアタッチした直後、スレーブデバイスは、マスタデバイス５２からこのコマンドを受信していない限り、アービトレーションに参加することを可能にされるべきではない。
ＨＡＲＤ ＲＥＳＥＴ関数（Ｘ３：Ｘ０＝０００１）の実行は、スレーブデバイス全体をリセットするために使用され得、これは、電源投入リセット動作に類似する。
ＳＯＦＴ ＲＥＳＥＴ関数（Ｘ３：Ｘ０＝００１０）の実行は、以前のプログラムされたデバイスアドレスおよび同期化エンジンを除いて、全ての機能性をリセットするために使用され得る。一般に、スレーブデバイス用の内部レジスタおよび機能性は、スレーブデバイスがすでにバス６４にロックされており、すでにアドレスを割り当てられていることを除いて、電源投入リセットイベント後と同一であろう。これは、スレーブデバイスがバス６４にすでにアタッチされ、ゼロとは異なるアドレスがすでに割り当てられていることを除いて、スレーブデバイスは、電源投入リセットイベント後、そうしていたであろうように挙動するであろうことを意味する。これは、スレーブデバイスが再度プログラムされることができる前に、スレーブデバイスの内側の全てのレジスタをリセットし、スレーブデバイスをバス６４にロックさせ、次いで、アドレスを割り当てる場合よりも速く、内部または外部エラーを補正するために使用することができる。
ＲＥＱＵＥＳＴ ＣＡＰＡＢＩＬＩＴＹ ＩＮＦＯＲＭＡＴＩＯＮ関数（Ｘ３：Ｘ０＝０１０１）の実行は、マスタデバイス５２またはスレーブデバイス５４の能力についての情報を得るために使用され得る。これは、ポートを自動的に設定するために使用されることができる。この関数は、ＲＥＱＵＥＳＴ ＩＤ関数のように、レジスタ０およびレジスタ１から値を読み取ることによって機能する。返される情報は、アドレス指定されているポートに対応する。ポートに接続されたチャネルからの全ての情報が読み取られたとき、代わりに、情報の終了を示すゼロが返されることができる。この例示的実施形態では、ポートが連続的に定義される。
マスタデバイス５２またはスレーブデバイス５４の能力情報を取得するレジスタ０ｘ００００の実施例が、図１２に挙げられている。レジスタ０ｘ００００から読み取ると、スレーブデバイスの内側のポートの能力が与えられるであろう。ポートの能力を読み取ると、ゼロ終端文字列が返されるであろう。この文字列は、このポートについての情報を含むであろう。ポートの能力は、それがどの方向にあるか（すなわち、入力ポートまたは出力ポート）、それがいくつのチャネルを有するか、およびこれらのチャネルに対するデータ形式がどのようなものであるかを伝えるであろう。全てのポートが読み取られた後、次の読み取りは、値０ｘ００を返すであろう。ＤＡＴＡレジスタ０ｘ００００（ならびに０ｘ０００１）は、主に、データ（場合によっては大量のデータであり得る）を転送するために使用され、例えば、文字列、ＡＤＤＲＥＳＳ ＩＤ、較正データ等を読み取るために使用される。アドレス０ｘ００００が、ＤＡＴＡレジスタの下位バイトである一方で、アドレス０ｘ０００１は、上位バイトである。別のレジスタ０ｘ０Ｃ−０ｘ０Ｄは、アドレスを転送するために使用されることができ、ＡＤＤＲＥＳＳレジスタと呼ばれる。アドレスは、マスタデバイス５２からの要求に応答して転送される。
ＤＡＴＡレジスタ０ｘ００００は、概して、ＴＹＰＥフィールドと、ＣＨＡＮＮＥＬ ＩＮＦＯフィールドと、ＤＡＴＡ ＦＯＲＭＡＴフィールドとを含む。これらのフィールドは、レジスタの１つ以上のビットを使用して実装されることができる。代替実施形態では、異なる実装をこれらのフィールドに使用することができ、フィールドが異なって順序付けられ得、または使用される他のフィールド、あるいは使用される他のレジスタがあり得る。
ＴＹＰＥフィールド（Ｂ７）は、データ転送の方向を示すために使用され得、例えば、入力動作（すなわち、バス６４からデータを読み取る）を示すために０を使用することができ、出力動作（すなわち、データをバス６４に出力するか、または書き込む）を示すために１を使用されることができる。入力および出力の両方をサポートするチャネルを２つの別個のポートに接続することができ、この例示的実施形態では、これらのポートのうちの一方は、入力ポートとして定義され、これらのポートのうちの他方は、出力ポートとして定義される。少なくともいくつかの実施形態では、１つのポートに接続された全てのチャネルが、同一のデータ形式および同一のサンプルレートを共有する。
ＣＨＡＮＮＥＬ ＩＮＦＯフィールド（Ｂ６：Ｂ４）は、このポートに関連付けられるチャネルの数を定義するために使用され得る。各ポートは、１つ以上のチャネルに関連付けられ得る。ＣＨＡＮＮＥＬ ＩＮＦＯフィールドは、ＰＯＲＴフィールド値によって定義されるポート数とともに、所与のスレーブデバイスからのチャネルの総数を返すであろう。実施形態では、ＰＯＲＴフィールド値は、２進マイナス１で符号化されることができ、その場合、「０００」は、１つのチャネルまたはチャネル１を意味し、「１０１」は、６つのチャネルを意味する等である。ＣＨＡＮＮＥＬ ＩＮＦＯフィールドに書き込むことによって、能力に対する次のＲＥＡＤ動作が、ＧＥＮＥＲＡＬ ＩＮＦＯフィールドのそのチャネルについての情報を生じるであろう。実施形態では、ポートにつき使用されるチャネルの数は、８であり得、ポート内の各チャネルに対するサンプルレートは、同一である。複数のサンプルレートが使用される場合、チャネルは、同一のサンプルレートを有する、より小さいグループにグループ化されることができる。
ＤＡＴＡ ＦＯＲＭＡＴフィールド（Ｂ３：Ｂ０）は、データの形式を示すために使用され得る。例えば、バイナリ、ビットストリーム、文字列、および浮動小数点等の種々のデータタイプを使用することができる。種々のデータ形式およびＤＡＴＡ ＦＯＲＭＡＴフィールド中のそれらの対応する表現の実施例が、統一バス通信プロトコルの例示的実施形態について図１３に示されている。
図１１ａをもう１度参照すると、ＲＥＡＤ ＩＲＱ ＳＯＵＲＣＥ関数（Ｘ３：Ｘ０＝００１１）の実行は、この関数が最後に実行されてからの第１のＩＲＱソースを返すために使用され得る。これは、バスエラーが起こったフレーム内のビット位置についての情報、センサからの状態情報等を返すことができる。ＩＲＱイベントが起こった場合、エラーコードが、図１４に示されるようにＤＡＴＡレジスタ０ｘ００００および０ｘ０００１において報告される。図１４は、統一バス通信プロトコルの実施形態に対する関数ＲＥＡＤ ＬＡＳＴ ＥＲＲＯＲの実行後にＤＡＴＡレジスタから読み取られた状態の実施例を示す。ＩＲＱイベントが起こらない限り、いかなるエラーコードも報告されないであろう。統一バス通信プロトコルの少なくとも１つの実施形態で使用されることができる、種々のエラーコードの実施例が図１５に示されている。他の実施形態では、より多いまたは少ないエラーコードを使用することができる。
図１１ａを再度参照すると、ＲＥＱＵＥＳＴ ＲＥＬＡＴＩＶＥ ＣＡＬＩＢＲＡＴＩＯＮ ＤＡＴＡ関数（Ｘ３：Ｘ０＝０１１０）の実行は、構成要素の製造差異を減少させるために使用され得る。較正係数が、構成要素の典型的な性能に関して測定される。較正データは、ビットストリーム用の１６ビットデジタルワードを除いて、ポートによって特定されたものと同じデータ形式を使用して、データフィールド中で返される。実施形態では、デジタルワードは、−４．０に等しいＭＳＢを伴う２補数表現で符号付き分数（ｆｒａｃｔｉｏｎ）として符号化され得る（例えば、０ｘ８０ ００は−４．００００であり、０ｘ７Ｆ ＦＦは３．９９９８８である）。デジタルワードが、現在の選択されているポートに接続される全チャネルについて返されるであろう。返される第１のワードは、フルスケールと比較した測定の相対精度を示すであろう。実施例として、返された値が２．００である場合には、ポートからの値は、この構成要素についてデータシートで記述されるような典型的な値であるものより２倍高い。値は、係数が１６符号付きデジタルワードとして記憶され得る、ビットストリームを除いて、ポートデータと同一のデータ形式で記憶される。いくつかの実施形態では、デジタルワードは、０から２５％の間の値を伴う符号なし整数、すなわち、測定精度がフルスケールの約３．１２５％であることを意味する、「０００１００００００００００００」として記憶され得る。
ＲＥＱＵＥＳＴ ＡＢＳＯＬＵＴＥ ＣＡＬＩＢＲＡＴＩＯＮ ＤＡＴＡ関数（Ｘ３：Ｘ０＝０１１１）の実行は、ＳＩ単位での出力量による絶対較正情報を取得するために使用され得る。これは、補間を用いて達成される。例えば、線形、多項式、スプライン、およびクレンショウ等の種々の補間技法を使用することができる。この関数は、測定された物理的パラメータのオフセットおよびスケーリングについての較正情報を返すために使用されることができる。返される第１のワードは、ＲＥＱＵＥＳＴ ＡＢＳＯＬＵＴＥ ＣＡＬＩＢＲＡＴＩＯＮ ＤＡＴＡ関数について上記で説明されるように、フルスケールと比較した測定の絶対精度を示すであろう。いくつかの実施形態では、絶対および相対較正データ関数は、単一のコマンドに組み込まれ得、アドレス指定されたスレーブデバイスは、これらの値のいずれか（すなわち、相対または絶対較正データ）で応答するように要求されるであろうか、またはどのタイプの較正情報が利用可能であるかをそれ自体がマスタデバイスに伝え得る。
ＲＥＡＤ ＡＮＤ ＩＮＣＲＥＭＥＮＴ ＡＤＤＲＥＳＳ関数（Ｘ３：Ｘ０＝１０００）の実行は、スレーブデバイス５４の内側のレジスタＡＤＤＲＥＳＳによって特定されるような１６ビットデータを読み取り、このレジスタのコンテンツをＹワードに転送するために使用され得る。その後、スレーブデバイス５４の内側のＡＤＤＲＥＳＳレジスタの値は、１だけ増分される。
ＷＲＩＴＥ ＡＮＤ ＩＮＣＲＥＭＥＮＴ ＡＤＤＲＥＳＳ関数（Ｘ３：Ｘ０＝１００１）の実行は、Ｙワードで１６ビットデータを取り込み、このデータをスレーブデバイス５４の内側のレジスタＡＤＤＲＥＳＳによって特定されるアドレスに書き込むために使用され得る。その後、スレーブデバイス５４の内側のＡＤＤＲＥＳＳレジスタの値は、１だけ増分される。
ＥＸＥＣＵＴＥ ＦＵＮＣＴＩＯＮ ＡＴ ＡＤＤＲＥＳＳ関数（Ｘ３：Ｘ０＝１０１０）の実行は、スレーブデバイス５４がプロセッサを備える場合に使用され得、その場合、このプロセッサは、次のフレームの開始時に、Ｙワードによって定義される１６ビットアドレスを用いて、サブルーチンへのジャンプ動作を行うであろう。
ＥＸＥＣＵＴＥ ＦＵＮＣＴＩＯＮ ＡＴ ＡＤＤＲＥＳＳ ＩＮＤＩＲＥＣＴ関数（Ｘ３：Ｘ０＝１０１１）の実行は、スレーブデバイス５４がプロセッサを備える場合に使用され得、その場合、プロセッサは、次のフレームの開始時に、Ｙワードによって定義されるメモリセルの内側に含まれるアドレスを用いて、サブルーチンへのジャンプを行うであろう。
ＰＥＲＦＯＲＭ ＤＥＶＩＣＥ ＳＥＬＦ ＴＥＳＴ関数（Ｘ３：Ｘ０＝０１００）の実行は、例えば、デバッギングおよび製造試験のために行われ得る、デバイス自己試験を行うために使用され得る。自己試験の結果は、エラーコードをもたらすか、またはいかなるエラーコードももたらさないであろう。エラーコードについては、ＲＥＡＤ ＬＡＳＴ ＥＲＲＯＲ関数の説明を参照されたい。低レベル割り込みが、自己試験の終了時にアクティブにされるであろう。エラーコード「デバイス自己試験」は、デバイス試験が完了したときに報告されるであろう。
ＳＥＴ ＧＡＩＮ関数（Ｘ３：Ｘ０＝１１００）の実行は、チャネルの利得を所望の値に設定するために使用され得る。
ＳＥＴ ＤＥＬＡＹ関数（Ｘ３：Ｘ０＝１１０１）の実行は、ポートまたは個々のチャネルに対して、サンプルの数の遅延を所望の値に設定するために使用され得る。個々のチャネルが選択される場合、チャネル数が特定される必要があろう。これは、ＣＨＡＮＮＥＬ ＳＥＬＥＣＴＩＯＮレジスタを使用して行われることができる。いくつかの実施形態では、遅延は、より細かい遅延精度のために、わずかな数のサンプルで特定され得る。
ＳＥＴ ＰＯＷＥＲ関数（Ｘ３：Ｘ０＝１１１０）の実行は、ポート、またはビットＢ２：Ｂ０を伴うデバイスの電力消費を設定するために使用され得る。これの実施例が、ビットＢ２：Ｂ０を使用して、図１７に示されている。別の実施形態では、異なる数のビットまたは異なる符号化が使用され得る。
マスタデバイス５２およびスレーブデバイス５４は、バス６４を経由したデバイスの転送をサポートすることができるように通信チャネルを設定する。マスタデバイス５２への入力は、処理された無線データから、プロセッサから、またはＴＤＭあるいはＩ２Ｓベースのチャネル等の何らかの他のデジタル通信リンクを通してもたらされ得る。マスタデバイス５２またはスレーブデバイス５４によって使用される各ポートには、バス６４上で伝送されるデータ中の正しいデータスロット（すなわち、タイムスロット）にトラフィックをダイレクトするレジスタが関連付けられる。例えば、マスタデバイス５２およびスレーブデバイス５４は、コマンドによってポートアクティビティを設定する、８つのレジスタを含むことができる（別の数のレジスタを代替実施形態で使用されることができる）。複数のチャネルが、データポートにおいて一緒に割り付けまたはグループ化され、プログラムされることができ、次いで、選択されたチャネルがアクティブにされることができる。これは、スレーブデバイス５４がバス６４にロックした（すなわち、同期化された）後にマスタデバイス５２によって為されるとができる。これらのデータチャネルから、またはそこへのデータは、フレーム中で２回以上生じるように、または例えば、本説明において以降でさらに詳細に説明されるであろう、ＳＫＩＰおよびＲＥＰＥＡＴ等の種々のパラメータを使用することによって、フレーム中で異なる間隔を有するようにプログラムされることができる。
実施形態では、４つのタイプの動作が、これらのレジスタに関連付けられ、動作は、データポート（Ｄａｔａ Ｐｏｒｔ）、設定（Ｓｅｔｕｐ）、チャネルのアクティブ化（Ａｃｔｉｖａｔｅ ｃｈａｎｎｅｌ）、および能力（Ｃａｐａｂｉｌｉｔｙ）である。代替実施形態では、他の動作を使用することができる。加えて、マスタデバイス５２は、レジスタ０ｘ０Ｃ−０ｘ０Ｄに位置するアドレスポートを有する。スレーブデバイス５４は、随意に、例えば、アドレスにジャンプする機能等の特殊機能のサポートのために、アドレスレジスタを含み得る。レジスタは、バイトベースであり、アドレスゼロからの１６ビットワードＲＥＡＤ動作は、最下位ビット（ＬＳＢ）におけるレジスタアドレス０のコンテンツ、および最上位ビット（ＭＳＢ）におけるレジスタアドレス１のコンテンツを返すであろう。レジスタアドレスは、１６ビットモードを使用するときに２で乗算される。
ポート番号は、概して、デバイス上のハードウェアにおいて固定される。特定のポート番号に関連付けられるオーディオまたはデータストリームは、デバイス特有である。ポート番号の実施例は、本説明のポート定義の節で挙げられる。マスタデバイス５２のレジスタマップに（例えば、Ｉ２Ｃを通して）直接アクセスすることができる一方で、スレーブデバイス５４のレジスタマップは、マスタデバイス５２によってプログラムされることができる。チャネル情報は、統一バス通信プロトコルを使用して、データスロット（すなわち、タイムスロット）を割り当てるために使用される。チャネル割当は、変更されることができ、システムおよび使用事例に依存する。チャネル割当は、デバイスからのどのポートが、バス６４上の特定のタイムスロットを割り当てられるかを定義する。実施形態では、マスタデバイス５２は、少なくとも２つの入力および２つの出力ポートを有することができ、各々が最大３２ビットワードを取り扱うことができる。他の実施形態では、異なる数の入力ポートまたは出力ポート、および異なるサイズのデータをマスタデバイス５２に使用することができる。一般に、スレーブデバイスは、ポートに対するいかなる要件も有さない。これらの動作へのレジスタマップは、統一バス通信プロトコルの少なくとも１つの実施形態では、マスタデバイス５２またはスレーブデバイス５４に使用されることができる、レジスタ定義の実施例である図１６ａに示されている。レジスタマップの別の実施例が、図１６ｂに示されている。これらのフィールドは、１つ以上のレジスタの１つ以上のビットを使用して実装されることができる。代替実施形態では、異なる実装をこれらのフィールドに使用することができ、フィールドが異なって順序付けられ得、または使用される他のフィールド、あるいは使用される他のレジスタがあり得る。アドレスＯＦＦＳＥＴが、マスタデバイス５２に対する絶対レジスタアドレスに追加され得る。次いで、ＯＦＦＳＥＴ＋ＡＤＤＲＥＳＳを使用して、実際のアドレスを計算することができる。スレーブデバイスについては、ＯＦＦＳＥＴは、０ｘ００である。これは、マスタデバイス５２がどのアドレスを読み取るか、どのアドレスに書き込むかを知るように、スレーブデバイスが主要バスレジスタ（０ｘ００−０ｘ０７）に対する絶対アドレスを使用するであろうことを意味する。しかしながら、マスタデバイス５２は、すでにそれ自体についての情報を有するので、そのレジスタマップでゼロとは異なるオフセットをそれ自体が使用し得る。しかしながら、レジスタのシーケンスは、ソフトウェアの簡単のために同一であり得る。他の実施形態では、マスタデバイス５２およびスレーブデバイスに対するレジスタのシーケンスは、異なり得る。
ＤＡＴＡ ＰＯＲＴ関数は、１つまたは２つの８ビットレジスタによって表すことができる。これらのレジスタからＲＥＡＤ動作を行うとき、８または１６ビットワードがＹワードで返されるであろう。これらのレジスタへのＷＲＩＴＥ動作（８または１６ビット）を行うとき、値が更新されるであろう。これらのレジスタのデフォルト値は、電源投入リセット動作後に０ｘ００００である。ＤＡＴＡフィールド（ｒｅｇ．０ｘ００、Ｂ７：０）は、１６ビットエンティティの下位８ビットを表す。一実施形態では、１６ビットデータ転送中に、上位アドレスビットは、ゼロであると仮定される（すなわち、１６ビットデータは、簡単にするために偶数アドレスにのみ書き込むことができる）。ＤＡＴＡフィールド（ｒｅｇ．０ｘ０１、Ｂ１５：８）は、１６ビットデータエンティティの上位８ビットを表す。
設定ポート関数に関連付けられるレジスタは、マスタデバイス５２およびスレーブデバイス５４が、統一バス通信プロトコルを使用して、バス６４上で伝送されるデータ中の所望のデータスロット（すなわち、タイムスロット）に情報を伝送することができるように、値を割り当てられる。割当の詳細の実施例は、図１６ａに示される種々のフィールドの説明によって挙げられる。
ＡＣＴＩＶＡＴＥフィールド（ｒｅｇ．０ｘ０３、Ｂ７）は、データストリームの機能、およびそれがどのようにして制御されるかを定義するために使用され得る。入力ストリームが非アクティブにされる場合、出力はゼロになるであろう。出力ストリームが非アクティブにされる場合、何もバス６４に書き込まれないであろう。
ＰＲＥＰＡＲＥビット（ｒｅｇ．０ｘ０３、Ｂ６）は、オンにされるであろう、現在の選択されているポートに関連付けられる回路を定義するために使用され得る。このビットから読み取るとき、ポートの現在の状態が返されるであろう（論理１は、ポートがデータ転送を始める準備ができていることを意味する）。これは、全ての回路が準備できており、データ転送が始まるときに故障が起こらないことを確実にするために使用されることができる。
代替実施形態（例えば、図１６ｂ）では、ＰＯＷＥＲ ＬＥＶＥＬフィールド（ｒｅｇ．０ｘ０２、Ｂ６：Ｂ４）は、システムの電力消費を最適化するために、個々のデバイス、ポート、およびチャネルの電力消費および動作モードを設定するように使用され得る。システム構成要素は、電力消費を最小化するために使用されることができる、いくつかのモードで動作することができる。例えば、ＣＨＡＮＮＥＬ ＳＥＬＥＣＴＩＯＮフィールドを使用して、個々のチャネルを選択することができる。選択されていないチャネルは、電力を節約するために、低電力モードで設定され得る。例えば、統一バス通信プロトコルの１つの使用法では、ＰＲＥＰＡＲＥビットがアクティブにされるまで、全てのチャネルが低電力動作モードにあり得る。ＰＲＥＰＡＲＥビットがアクティブにされた後、ＣＨＡＮＮＥＬ ＳＥＬＥＣＴＩＯＮフィールドで選択されているチャネルは、通常動作モードにされ得る。ＰＲＥＰＡＲＥビットの状態を読み取ることによって、選択されているチャネルがデータを受信または伝送する準備ができており（限定されないが、例えば、いくらかのデバイス依存性初期電源投入遅延後等に）、ＡＣＴＩＶＡＴＥビットを使用することによってアクティブにされることができるときを知ることが可能である（すなわち、全ての選択されたチャネルが準備できているときにＰＲＥＰＡＲＥビットは論理１レベルになるであろう）。
少なくとも１つの実施形態では、電力がデバイスに印加されないとき、バス６４は、依然として動作を継続することが可能であり得、すなわち、ＥＳＤ構造は、電力がスレーブデバイス５４またはマスタデバイス５２に印加されないときに、バス６４を停滞させるべきではない。
ここで図１７を参照すると、例示的実施形態での種々の電力消費レベルの実施例が示されている。本実施例では、電力消費スケーリングは、関数によって定義され、絶対的ではない。換言すると、図１７に示される正確な電力レベルは、異なるスレーブデバイスについて変化し得る。さらに、Ｂ６：Ｂ４＝０１１から１１１によって定義される電力消費レベルについては、ポートまたはデバイスは、完全に機能的であり得るか、またはそうではない場合がある。デバイス全体の電力消費が設定される場合、ブロードキャストのためのポート（１５）が使用され得る。ポートまたはデバイスは、いくつかの電力レベルのみをサポートし得る。例示的実施形態では、マスタデバイス５２がスレーブデバイス５４によってサポートされていないＰＯＷＥＲ ＬＥＶＥＬの値を書き込む場合、それは、サポートされる最も近い値にマップされることができる。ＰＯＷＥＲ ＬＥＶＥＬフィールドのデフォルト値は、０１０（すなわち、ＳＬＥＥＰモード）である。
図１６ａを再度参照すると、ＩＲＱ２３ ＭＡＳＫフィールド（ｒｅｇ．０ｘ０３、Ｂ５）は、通常はＳ０ビットをアクティブにするであろうスレーブ状態レベル「１０」および「１１」として、バス６４を経由して通信される、スレーブデバイスからの割り込みを有効または無効にするために使用される。ＩＲＱ２３ ＭＡＳＫフィールドが１に等しいとき、スレーブデバイス５４は、スレーブ状態レベルがレベル２またはレベル３であることを内部論理が示すときに、高レベル割り込みを発行するであろう（すなわち、スレーブデバイス５４が割り込みを要求しており、かつバス６４にこの割り込みを承認することを可能にされる）。このビットがゼロに等しいとき、何も起こらず、示されたスレーブ状態レベルは、Ｓ０ビットに影響を及ぼさないであろう。ＩＲＱ２３ ＭＡＳＫフィールドのデフォルト値は、１である（すなわち、通常は割り込みが有効にされる）。
ＩＲＱＦ ＭＡＳＫフィールド（ｒｅｇ．０ｘ０３、Ｂ４）は、スレーブマスタデバイス５２がこのスレーブデバイスに行うように要求する所与のＦＵＮＣＴＩＯＮをデバイスがサポートしない場合に生成される、割り込みを有効にするために使用される。ＩＲＱＦ ＭＡＳＫフィールドが１に等しいとき、マスタデバイス５２が、それがサポートしないＦＵＮＣＴＩＯＮ動作を実行するようにスレーブデバイス５４に求めるとき、スレーブデバイス５４は、低レベル割り込みに設定されるであろう。これは、自動的にＳ０割り込みビットを設定するであろう。スレーブデバイス５４がすでに、割り込みが保留中である状況にある場合、新しいことは何も起こらないであろう。ＩＲＱＦ ＭＡＳＫフィールドがゼロに等しいときは、何も起こらない。ＩＲＱＦ ＭＡＳＫフィールドのデフォルト値は、１である。
ＰＯＲＴフィールド（ｒｅｇ．０ｘ０３、Ｂ３：Ｂ０）は、デバイス内のどのポートがアドレス指定されているかを示す。この例示的実施形態では、ポート番号は、番号１５がブロードキャスティングのために保留される（すなわち、全てのポートがマスタデバイス５２からのコマンドをリッスンする）、０−１５であり得る。ポートは、ゼロから最大８つのチャネルのいずれかと接続されることができ、このマッピングは、配線接続されている。代替実施形態では、ポートは、８つより多くのチャネルと接続されることができる。全てのチャネルは、それらが同一のデータ形式を有するように特定のポートに接続される。スレーブデバイス５４またはマスタデバイス５２は、複数のポートを有することができる。ブロードキャストコマンド中、全てのポートは、例えば、ＡＣＴＩＶＡＴＥおよびＢＡＮＫ等のある関数への変更をリッスンするであろう。ポートを使用するために、アクティブにされるであろうチャネルが、最初に選択されるべきである。次いで、データが準備できる前にデバイスがいくらかの時間を要する場合に、ＰＲＥＰＡＲＥビットがアクティブにされるべきであり、適切なフレームおよびデータ形式が選択されるべきであり、最終的に、ＡＣＴＩＶＡＴＥフィールドを真に設定することによって、ポートがアクティブにされるべきである。
ここで図１８を参照すると、統一バス通信プロトコルを使用して２つのスレーブデバイス５４ａおよび５４ｂと通信する、マスタデバイス５２’の例示的実施形態が示されており、スレーブデバイス５４ａおよび５４ｂは、種々のチャネルに割り付けられるポートを有する。種々のオーディオおよびデータチャネルに対するポート番号が、各論理ブロック内に示されている。これらのポート番号、チャネル、およびインターフェースは、一例のみとして提供され、ポート番号、チャネル、およびインターフェースの種々の組み合わせを伴う種々の他の実施形態があり得る。
マスタデバイス５２’は、多重化および同期エンジン１００と、ポート１０２から１１０とを含む。多重化および同期エンジン１００は、使用されている統一バス通信プロトコルのフレーム形式に従って、データを生成し、バス６４上のあるタイムスロット中にデータを配置するために使用される。多重化および同期エンジン１００はまた、統一バス通信プロトコルに対する同期化情報を生成するためにも使用される。ワードフレーム形式は、バス６４上の通信がワードモード下で行われるときに使用され、ビットストリームフレーム形式は、バス６４上の通信がビットストリームモード下で行われるときに使用される。これらの形式の両方を、本明細書において以降でさらに詳細に説明する。本実施例では、伝送されるデータの一部が、ポート１０４〜１１０から受信される。
一般に、プロセッサを使用して、多重化および同期エンジンを実装することができる。しかしながら、多重化および同期エンジンのために、およそ２Ｋゲート総数があるので、状態マシンまたは他の専用回路も実装に使用されることができる。例えば、典型的な０．１８μｍプロセスでは、マスタデバイス用の同期エンジンは、０．０４ｍｍ２で実装されることができる。完全オーディオサポートを伴う完全なマスタデバイスは、いくぶん大型であり得るが、０．１ｍｍ２未満であり得る。スレーブデバイス用の同期エンジンは、両方の場合において同様のサイズであり得る。これは、小さいサイズが、より単純なデバイスドライバ、およびハードウェア実装のより良好な試験を意味するため、有益である。代替実施形態では、携帯電話またはスマートフォン用のベースバンドプロセッサ等のマスタデバイス５２’を含む電子デバイス用のメインプロセッサを使用して、マスタデバイス５２’を実装することができ、その場合、制御情報は、マスタデバイス５２’によって内部で生成され得、ポート１０４から１１０は、随意的であり得る。
ポート１０２は、情報をバス６４に接続される全てのデバイスのポートに伝送するために使用される、ブロードキャストポートである。それは、全ての他のポートのレジスタマップに接続され、１度に全てのポートを制御するために使用される。それは通常、オーディオデータ転送には使用されない。ポート１０４は、１つの方向へＩ２Ｓ形式に従って情報を転送するように、Ｉ２Ｓインターフェースに連結される（例えば、伝送機の役割を果たす）。ポート１０６は、反対方向へＩ２Ｓ形式に従って情報を転送するように、別のＩ２Ｓインターフェースに連結される（例えば、受信機の役割を果たす）。ポート１０８は、ＭｃＢＳＰ ＴＤＭ形式に従って情報を転送するように、ＭｃＢＳＰインターフェースに連結される。ポート１１０は、Ｉ２Ｃ形式に従って制御情報を受信するように、Ｉ２Ｃインターフェースに連結される。
スレーブデバイス５４ａは、多重化および同期エンジン１２０と、ポート１２２から１２６と、アナログ／デジタル変換器（ＡＤＣ）１２８と、デジタル／アナログ変換器（ＤＡＣ）１３０とを備える。ＡＤＣ１２８およびＤＡＣ１３０は両方とも、本実施例では２つのチャネルを有する。スレーブデバイス５４ａの多重化および同期エンジン１２０は、以下でさらに詳細に説明されるように、マスタデバイス５２’に同期化するために使用される。ポート１２２は、ブロードキャストポートである。本実施例では、ポートアドレス１５は、コマンドのブロードキャストに使用され、すなわち、アドレス１５に送信される任意のコマンドは、特定のスレーブデバイスに接続される全てのポートに影響を及ぼすであろう。さらに、スレーブアドレス１５もまた、ブロードキャスティングのために保留され、すなわち、このアドレスへのＷＲＩＴＥ動作は、全てのスレーブデバイスに影響を及ぼすであろう。したがって、スレーブアドレス１５およびポート１５への書き込みは、システム内の全てのデバイスおよび全てのポートに影響を及ぼすであろう（例えば、同時にデータの動作停止または同時起動のために）。ポート１２４は、ＡＤＣ１２８の２つのチャネルに接続されるカスタムポート（全データビットに直接ワイヤを使用する並列接続のためのＩ２ＣまたはＩ２Ｓ等の非標準インターフェースを備えることを意味する）である。代替実施形態では、２つより多くのチャネルがあり得、ポート１２４は、２つより多くのチャネルに接続され得る。ＡＤＣ１２８は、マイクロホン、電流センサ、電圧センサ、圧力センサ、温度センサ等のデータを生成する１つ以上のデバイスに接続される。異なる場所に位置付けられた２つのマイクロホン等の２つの同一のタイプのデバイスがＡＤＣ１２８に接続される、実施形態があり得る。ポート１２６は、ＤＡＣ１２８の２つのチャネルに接続される。代替実施形態では、２つより多くのチャネルがあり得、ポート１２６は、２つより多くのチャネルに接続され得る。ＤＡＣ１２６は、限定されないが、例えば、出力スピーカ、デジタルＦＭ受信機、デジタルＦＭ伝送機、Ｂｌｕｅｔｏｏｔｈ（登録商標）インターフェース、振動器、温度センサ、バッテリの充電状態を監視するセンサ、加速度計、ジャイロスコープ、ＧＰＳ受信機、またはデジタルコンパス等のデータを受信する１つ以上のデバイスに接続される。
スレーブデバイス５４ｂは、多重化および同期エンジン１４０と、ポート１４２から１５２と、ＡＤＣ１５４と、ＤＡＣ１５６と、Ｉ／Ｏ１５８および１６０とを備える。Ｉ／Ｏ１５８および１６０は、それぞれ、例えば、ステレオＡＤＣ（２つのチャネルとして表される）、および４チャネルＤＡＣ（４つのチャネルとして表される）であり得る。ポート１４２から１４８、ＡＤＣ１５４およびＤＡＣ１５６は、ポート１２４およびＡＤＣ１２８と比較して、より多くのチャネルがポート１４６およびＡＤＣ１５に使用されることを除いて、ポート１２２から１２６、ＡＤＣ１２８、およびＤＡＣ１３０に類似する。ポート１５０は、Ｉ２Ｓプロトコルに従って、順にＩ２Ｓインターフェースに接続されるＩ／Ｏ１５８にデータを送信または受信するように構成される。ポート１５２は、Ｉ２Ｃプロトコルに従って、順にＩ２Ｃインターフェースに接続されるＩ／Ｏ１６０にデータを送信または受信するように構成される。ポート１５０は、物理的Ｉ２Ｓインターフェースに接続され、左右に２つのオーディオチャネルを含む。２つのチャネルは、両方ではなく、入力または出力のいずれかであり得る。ポート１５０は、マルチフォーマットバス６４からデータを捕捉し、データをＩ２Ｓ形式に転送するか、または反対方向に逆も同様に行うであろう。ポート１５２は、Ｉ２Ｃインターフェースに接続され、Ｉ２ＣマスタデバイスまたはＩ２Ｃスレーブデバイスとして機能することができる。適切なタイミングを使用することによって、Ｉ２Ｃコマンドは、マルチフォーマットバス６４を経由して通信され、Ｉ２Ｃインターフェースに書き込まれるか、またはＩ２Ｃインターフェースから読み取られることができ（スレーブデバイスとして動作されるとき）、Ｉ２Ｃコマンドは、マルチフォーマットバス６４からレジスタデータを要求し、それによって、起こっている他のアクティビティの全てと同時に、マルチフォーマットバス６４を経由してＩ２Ｃアクティビティをトンネリングするために使用することができ。
場合によっては、スレーブデバイス５４ｂは、代わりに、フレーミング能力（すなわち、フレーム形式を設定する能力）がない追加のマスタデバイスとして実装され得、それによって、元のマスタデバイス５２’からのいかなる介入も伴わずに、他のデバイスのレジスタにアクセスするために、これらのレジスタへの直接アクセスを得る。コマンドの符号化（例えば、ＰＩＮＧはコマンドフィールド内で０００として符号化される）により、任意のＰＩＮＧコマンドは、代替コマンドに変更されることができる（これが起こることを主要マスタデバイス５２’が可能にする場合）。
場合によっては、データ帯域幅が単一のワイヤにわたって十分ではない場合、１つより多くのデータラインがデータを転送するために使用され得るか、または２つの別個のバスがマスタデバイスとスレーブデバイスとの間で使用され得る。これは、いくつかのデバイスが、低帯域幅（例えば、大抵は制御または低速等時性転送に使用される）のみを使用し、本システムの他の部品、例えば、デジタルスピーカまたはマイクロホンがより高いクロック周波数を使用し得る場合に有益である。本システムを低帯域幅部分および高帯域幅部分に分割することによって、電力消費を削減することができ、場合によっては配線をより単純にすることができる。
もう１度図１６ａを参照すると、ＣＨＡＮＮＥＬ ＳＥＬＥＣＴＩＯＮフィールド（ｒｅｇ．０ｘ０２、Ｂ７：０）は、所与のポートがアクティブにされるときに、所与のポートからのどのチャネルが使用に選択されるかを決定するために使用され得る。ポートからのチャネルの数は、固定され、ＣＨＡＮＮＥＬ ＳＥＬＥＣＴＩＯＮフィールドは、どのチャネルが、ワード開始、チャネル長、およびスキップフィールドを含む種々のパラメータの影響を受けるかを選択するために使用される。アクティブにされるように選択されるチャネルは、ＣＨＡＮＮＥＬ ＳＥＬＥＣＴＩＯＮフィールド中で１に設定された対応するビットを有する。チャネル間のマッピング、およびポートのどのチャネルが通信に使用されるかを説明するＣＨＡＮＮＥＬ ＳＥＬＥＣＴＩＯＮフィールドの実施例が、図１９に示されている。代替実施形態では、図１９に示されるような７から０の順序付けよりもむしろ、０から７のチャネルの直接的な順序付けを使用することができる。簡単にするために、降順が使用されるが、他の実施形態では他の順序付けを使用することができる。アクティブにされないチャネルからのデータは、バス６４に出現しないであろう。
例示的実施形態では、ＣＨＡＮＮＥＬ ＳＥＬＥＣＴＩＯＮフィールドによって定義される全てのチャネルは、同一のサンプリング周波数を有し、実装を単純化するように同時にサンプリングされるであろう。サンプリングは、これらの値をデジタル信号に変換するときに、アナログドメイン内で行われる。同様に、複数のデジタル・アナログ変換器を含むポートは、フレーム内で同一の遅延を有するべきであり、その結果として、同一の信号が全てのチャネルに印加される場合、これらのアナログ信号が同一に見える（たとえこの情報がバスを経由して順次に転送されたとしても）。サンプルがフレームにつき１回配置されるとき、サンプリングイベントは、フレームの開始として受け止められる。１つより多くのサンプルが存在する場合、それらは、フレームの開始を第１のサンプルとして等距離で離間され得る。フラクショナルフローを使用するとき等、サンプリングが全フレームにわたって同一ではない場合、複数のフレームにわたってサンプリングを同期化するために、同期化ビットＤＳ０からＤＳ１をサンプリング基準として使用することができる。各ポートは、各自のＣＨＡＮＮＥＬ ＳＥＬＥＣＴＩＯＮフィールドを有し、アクティブであるポートは、ｒｅｇ．０ｘ０２でＰＯＲＴフィールドによって選択される。
もう１度図１６ａを参照すると、ＳＴＡＲＴフィールド（ｒｅｇ．０ｘ０４、Ｂ７：Ｂ０）は、フレーム中の第１のタイムスロットを定義するために使用され得、その時点で、ポートが定義され、時間基準としてコマンドワードを使用して、データを伝送または受信する。実施形態では、この値は、符号なし２進数で半ニブル（半ニブルは２ビットである）の単位で与えられる。例として、ＳＴＡＲＴフィールドに対する半ニブルでの「００００１０００」という値は、コマンドワードの終了後にデータが１６ビットを開始することを示す。
ＣＵＲＲＥＮＴ ＢＡＮＫフィールド（ｒｅｇ．０ｘ０Ｆ、Ｂ４）（図２９ａ参照）は、どのレジスタが次のＲＥＡＤ、ＷＲＩＴＥ、またはＦＵＮＣＴＩＯＮ動作に使用されるかを選択するために使用され得る。ＰＩＮＧ動作を伴う全フレーム中に、アクティブなメモリバンクが出力されるであろう。しかしながら、少なくとも１つの実施形態では、バス６４にアタッチされたデバイスは、最初に、単一ビットエラーから守るように、２つのフレームの遅延後にそのレジスタバンクを変更するであろう。これは、出力または入力故障を伴わずに、２つの動作モードの間でシームレスな変更を可能にする。ＣＵＲＲＥＮＴ ＢＡＮＫビットは、アクティブなレジスタバンクを選択するためにマスタデバイス５２によって使用される。
従来、これらの異なるデータモードの間の切り替えは、量を減少させ、レジスタの設定を変更し、次いで、量を増加させることによって行われることに留意されたい。有利には、統一バス通信プロトコルの側面は、レジスタを切り替えることができ、アクティブなレジスタがＰＩＮＧ動作で示されているため、データを即時に切り替える能力であり、例えば、オーディオ出力においてクリックを伴わずにオーディオシナリオを変更することが可能である。
図１６ｂの代替実施形態では、ＢＡＮＫ ＭＯＤＥフィールド（ｒｅｇ．０ｘ０５、Ｂ７）は、ＢＡＮＫ ＳＥＬＥＣＴビットの解釈を決定するために使用され得る。ＢＡＮＫ ＭＯＤＥフィールドがゼロに等しいとき、ＢＡＮＫ ＳＥＬＥＣＴビットは、Ｉ／Ｏ動作中、最上位アドレスビットに取って代わる。さらに、（Ｉ／Ｏ動作中にマスタデバイス５２によって与えられるような）Ｉ／Ｏアドレスの最上位ビットは、現在のバンクを選択するために使用される。ＢＡＮＫ ＭＯＤＥフィールドが１に等しいとき、ＢＡＮＫ ＳＥＬＥＣＴビットは、どのバンクに次のＩ／Ｏ動作が影響を及ぼすかを選択するであろう。種々の可能性が図２０に示され、図２０は、例示的実施形態におけるＢＡＮＫ ＭＯＤＥフィールドおよびＢＡＮＫ ＳＥＬＥＣＴフィールドに応じて、ＲＥＡＤまたはＷＲＩＴＥ動作中に選択されるバンクおよびアドレスの例を示す。
図１６ｂの代替実施形態を再度参照すると、ＢＡＮＫ ＳＥＬＥＣＴフィールド（ｒｅｇ．０ｘ０５、Ｂ６）は、どのレジスタが次のＲＥＡＤまたはＷＲＩＴＥ動作に使用されるかを選択するために使用され得る。ＰＩＮＧ動作を伴う全フレーム中に、アクティブなメモリバンクが出力されるであろう。しかしながら、実施形態では、バス６４にアタッチされたデバイスは、最初に、例えば、単一ビットエラーを防止するために役立つため等、ある数のフレームの遅延後に、ＢＡＮＫ ＭＯＤＥフィールドを変更するであろう。この場合、ＣＵＲＲＥＮＴ ＢＡＮＫビットは、アクティブなレジスタバンクを選択するためにマスタデバイス５２によって使用される。ＢＡＮＫ ＭＯＤＥフィールドは、図２０に示されるようなＢＡＮＫ ＳＥＬＥＣＴフィールドの解釈を決定する。
図１６ａをもう１度参照すると、ＬＥＮＧＴＨフィールド（ｒｅｇ．０ｘ０６、Ｂ５：Ｂ０）は、半ニブルの数（すなわち、２ビットの単位）で、各チャネルのデータサイズを定義するために使用され得る。例示的実施形態では、ＬＥＮＧＴＨフィールド中の値は、２進マイナス１で符号化され、２ビットの単位で求められる（例えば、“０１０１１”＝０ｘ０Ｂは、１１＋１＝１２×２ビットまたは２４ビットデータ幅として解釈される）。本実施例では１２８ビットである、最大チャネル幅も定義される。最大チャネル幅以上が量（例えば、ＩＥＥＥクアッド精度複素数）を表すために使用される場合、これは、２つのチャネルをポートにマージすることによって達成することができる。ＳＵＢＧＲＯＵＰフィールドを使用して、マージされたチャネルの間に間隔を追加することが依然として可能である。ＬＥＮＧＴＨフィールドは、チャネルサイズがビットストリームデータに対して１ビットであるため、ビットストリームデータを転送するポートについては無視される。ビットストリームモードでは、チャネルの長さは１である。
ＳＫＩＰフィールド（ｒｅｇ．０ｘ０６、Ｂ７：Ｂ６）は、ＲＥＰＥＡＴフィールドがアクティブであるときにスキップされる、タイムスロットまたはデータスロットの数を定義するために使用され得る。本実施例では、ＳＫＩＰフィールド中の値は、２進数で符号化され得る（例えば、「０００００」は、ポートが繰り返される場合にスキップがないことを意味し、「００００１」は、同一のポートからのデータの次のブロックが、前のブロックの１６ビット後に来ることを意味する）。これは、本説明において以下でさらに説明されるように、サブフレームにおいて複数のポートからのデータを混合するために使用することができる。ＳＫＩＰフィールドを使用することの実施例は、図２１に示さ、図２１では、使用されている１のスキップがあり、ワードモードが使用されているため、単一のポートからのデータがサブフレーム中で２回以上繰り返される（すなわち、２つのコマンドワードの間で）。各ポートは、各自のＳＫＩＰフィールドを有し、アクティブであるポートは、レジスタ０ｘ０２でＰＯＲＴフィールドによって選択される。
図１６ａをもう１度参照すると、ＳＹＮＣＨＲＯＮＩＺＥフィールド（ｒｅｇ．０ｘ０５、Ｂ７：Ｂ６）は、等時性転送、非同期転送、マルチフレーム転送の間で選択するために使用される。例示的実施形態による、所与のフレームにおける等時性、非同期、マルチフレーム転送の使用に応じて設定される、種々のフィールド値が、図２２ａに示されている（図２２ｃは、場合によっては使用され得る代替実施形態を示す）。
図１６ａをもう１度参照すると、フィールドＰＣＬＫＤ（ｒｅｇ．０ｘ０７、Ｂ７：Ｂ４）は、スレーブデバイス中のポートのバスクロックとサンプリングクロックとの間の比を設定する。２６．００ＭＨｚに対するサポートが提供されない限り、分数オプションによる除算（例えば、両方のエッジ上のクロック、２．５、６．５、および１２．５による除算）をコードする必要はない。スペースを節約するために、フィールドは、図２２ｂに示されるように、圧縮様式で符号化されることができる。少なくともいくつかの実施形態では、各ポートは、各自のＰＣＬＫＤフィールドを有することができ、アクティブであるポートは、レジスタ０ｘ０２でＰＯＲＴフィールドによって選択される。
ここで図２２ａを参照すると、構成１は、デフォルト構成であり、等時性データ転送をもたらすであろう（すなわち、データは、全サブフレーム中で有効である）。構成２は、ポートの第１のチャネルからのデータの前に２つの状態ビットを追加することによって、非同期転送を取り扱う。第１の状態ビットは、後に続くポートデータが有効であるかどうかを示し（非同期データ転送では、準備ができていないデータは無効と見なされて破棄される）、第２の状態ビットは、受信デバイスがそれらを受け入れることができるかどうかを示す。代替実施形態では、データに先行する１ビットは、伝送デバイスが新しいデータを有し、受信デバイスがそれらを受け入れなければならないことを示すために使用されることができる。代替として、データに先行する１ビットは、スレーブデバイスがデータを受け入れる準備ができていることを示すために使用されることができ、このデータは、すでにマスタデバイスまたは別の伝送デバイスから入手可能なはずである。構成２は、帯域幅がこれらのビットに利用可能である場合、複数非同期チャネルに有用である。
構成３および４は、分数同期化に使用され、例えば、４８ｋＨｚチャネル中で４４．１ｋＨｚにおいてサンプリングされるデータに対して使用される。この場合、伝送デバイスは、単一のポートからのデータの伝送をいくつかのフレーム中へ拡張し得る。この場合、ＤＳ０およびＤＳ１ビットは、２つおきのフレームで有効であり、これらのビットがアクティブではないときに、サンプルが有効であるか否かを決定するために使用される、内部分数相加算器（分数カウンタ）をリセットするために使用される。この伝送の開始は、ＤＳ０またはＤＳ１ビットを論理１に設定することによって、信号伝達される。マスタデバイス５２またはスレーブデバイス５４の中に位置する伝送機は、ＤＳ０およびＤＳ１ビットをアクティブにすることによって、データの流れを制御することができる。
図１６ａをもう１度参照すると、ＳＵＢＧＲＯＵＰフィールド（ｒｅｇ．０ｘ０５、Ｂ５：Ｂ３）は、所与のポートからのチャネルをいくつかのサブグループにグループ化することにより、サブグループ中のチャネルに対するデータを提供するソースの待ち時間を低減させるために使用され得る。伝送されるチャネルの数がＳＵＢＧＲＯＵＰフィールドの値に等しいとき、これらのチャネルからのデータの伝送は、ＳＫＩＰフィールド中で特定されるニブル数に等しい、いくつかのタイムスロットに対して停止し、次いで、繰り返されるであろう。ＳＵＢＧＲＯＵＰフィールドが「１１１」に等しい場合には、ＳＵＢＧＲＯＵＰフィールドは無視され、ポート中のチャネルからのデータは、１つのグループ中で伝送されるであろう（例えば、いかなるサブグループもないであろう）。デフォルト値は、「１１１」である。
図２３は、ワードモードで低遅延を達成するために、同一のポートからのチャネル間の分割を伴う複数のデータチャネルを使用するときのフレーム設定（すなわち、フレーム形式）の実施例を示し、ＳＵＢＧＲＯＵＰフィールドは、ポートのチャネルからのデータをいくつかのサブグループに分割するために使用される。ＳＵＢＧＲＯＵＰフィールドは、それぞれ、Ｂ３およびＢ４：Ｂ５によって特定される２つの乗数から成る。ＳＫＩＰが起こる前に伝送されるチャネルの数は、フィールドＢ３とＢ４：Ｂ５とによって定義される積に等しい。図２３の実施例から分かるように、ＳＵＢＧＲＯＵＰフィールドは、いくつのチャネルがサブグループにおいて一緒にグループ化されるかを特定し、これは、ポートに対する全てのアクティブなチャネルについて行われ得る。したがって、一例では、図２３のポートが、オーディオ０、オーディオ１、オーディオ２、およびオーディオ３を提供する、４つのチャネルを有する場合には、オーディオ０およびオーディオ１に対するチャネルは、第１のサブグループを形成し、オーディオ２およびオーディオ３に対するチャネルは、第２のサブグループを形成する。図２３は、単一のサブフレームの構造のみを示すことに留意されたい。この構造は、フレームを完成させるように２回以上繰り返されるであろう。したがって、サブフレームは、次の制御ワードに先立って起こるデータが後に続く制御ワードを備えるフレームの一部分であるようにワードモードで定義される。
図１６ａを再度参照すると、ＲＥＰＥＡＴフィールド（ｒｅｇ．０ｘ０５、Ｂ２：Ｂ０）は、ポートからのデータがサブフレーム内で何回繰り返されるかを決定するために使用され得る。ＲＥＰＥＡＴフィールドのデフォルト値は、「０００」である。ＲＥＰＥＡＴフィールドを使用して、複数のデータチャネルからのデータがワードモードで数回繰り返されるときのフレーム設定の実施例が、図２４に示されている。実施形態では、ＲＥＰＥＡＴフィールドは、２つの乗数、すなわち、Ｂ０およびＢ１：Ｂ２から成る。ＣＨＡＮＮＥＬ ＳＥＬＥＣＴＩＯＮフィールドによって定義されるチャネルがフレーム中に伝送される回数は、ＲＥＰＥＡＴフィールドのフィールドＢ０とＢ１：Ｂ２とによって定義されるような積に等しい。したがって、図２４の実施例では、ポートの２つのデータチャネル（オーディオ０およびオーディオ１）からのデータが使用される。ＳＴＡＲＴフィールドは、ニブル単位で８に設定され、ＬＥＮＧＴＨフィールドは、ニブル単位で４に設定され、ＲＥＰＥＡＴフィールドは、ニブル単位で「００１」であり、ＣＨＡＮＮＥＬ ＳＥＬＥＣＴＩＯＮフィールドは、「００００００１１」であり、ＳＵＢＧＲＯＵＰフィールドは、（ニブル単位で）「０００」であり、ＣＯＭＭＡＮＤ ＳＥＰＡＲＡＴＩＯＮフィールドは、ニブル単位で１１２／４＝２８である（ニブル単位の全ての値は、１０をベースとする形式で値を得るために２で乗算されることを思い出されたい）。図２４の実施例では、チャネルオーディオ０およびオーディオ１からのデータは、サブグループ中で一緒にグループ化され、３回繰り返され、ＳＫＩＰフィールドが０の値を有するため、サブグループの間に間隙がないことが分かる。ビット１１２−１２７におけるデータチャネルオーディオ１からのデータの後に、ビット０からビット１２７の構造が、フレームを完成させるように２回以上繰り返されるであろうことに留意されたい。したがって、図２４は、単一のサブフレームを示し、３つのサブフレームが、フレームを完成させるために使用される。
全てのデータワードが転送される前にサブフレームが完成した場合、伝送を終了させることができ、その場合、たとえプログラミングエラーが生じたとしても、マスタデバイス５２またはスレーブデバイス５４は、Ｓ、Ｘ、またはＹワードに書き込むことを可能にされない。したがって、本実施例では、３つのデータペアの終了後に続く他のデータがないので、「０１０」より大きい任意のＲＥＰＥＡＴ値によって、図２４に示されるものと同じ構成が取得されることができる。各ポートは、各自のＲＥＰＥＡＴフィールドを有し、アクティブであるポートは、ｒｅｇ．０ｘ０２でＰＯＲＴフィールドによって選択される。
ビットストリームモードでは、データは、１度に１ビット転送され、データは、１度に１つのデータチャネルで各データチャネルから全てのデータを伝送する代わりに、異なるデータチャネルから多重化される。ビットストリームモードを実装するために、いくつかのフィールドの定義が、この例示的実施形態で変化する。例えば、ポートのビットストリームデータチャネルからデータを転送するとき、以下のフィールド、すなわち、ＬＥＮＧＴＨ、ＳＫＩＰ、およびＳＹＮＣＨＲＯＮＩＺＥは、現在使用されていない。ＳＴＡＲＴ、ＲＥＰＥＡＴ、およびＳＵＢＧＲＯＵＰフィールドの解釈は、多重化ビットストリームの性質に適合するように修正される。全ての他のフィールドは不変である。
図１６ａを再度参照すると、ビットストリームモードで、ＳＴＡＲＴフィールドは、２つのフィールド（ＨＳＴＡＲＴおよびＶＳＴＡＲＴ）に分割され、ビットストリームデータを転送するポート、または（本説明において以降で説明されるように）ビットストリームデータに変換されるデジタルワードデータを転送するポートに使用される、ＳＴＡＲＴ ＩＮ ＢＩＴＳＴＲＥＡＭ ＭＯＤＥフィールド（ｒｅｇ．０ｘ０４、Ｂ７：Ｂ０）であるように修正され得る。ＨＳＴＡＲＴフィールド（ｒｅｇ．０ｘ０４、Ｂ７：Ｂ４）の値は、単一のサブフレーム内のポートからのチャネルデータの開始を与え、２進数でコードされることができる。ＶＳＴＡＲＴフィールド（ｒｅｇ．０ｘ０４、Ｂ３：Ｂ０）中の値は、フレームにおける垂直方向への、ポートからのチャネルデータの開始を与える。
ビットストリームモードでは、ＳＵＢＧＲＯＵＰＡＮＤ ＲＥＰＥＡＴフィールドは、２つのフィールドに分割される、ビットストリームモードでのＶＳＰＡＣＩＮＧおよびＨＳＰＡＣＩＮＧフィールド（ｒｅｇ．０ｘ０５、Ｂ５：Ｂ０）であるように修正され得る。ＨＳＰＡＣＩＮＧフィールド（Ｂ２：Ｂ０）中の値は、単一のサブフレーム内のビットストリームの反復間の距離を与える。ビットストリームモードでは、サブフレームの内側の制御ワードが個々のビットに分割されるため、サブフレームは、３つの制御ワードＳ、Ｘ、およびＹのうちの１つのビット（例えば、Ｓ１５、Ｘ１５、Ｙ１５）から定義される間隔、ならびに制御ワードＳ、Ｘ、およびＹのうちの１つからの次のビット（例えば、Ｓ１４、Ｘ１４、Ｙ１４）の開始である。ＶＳＰＡＣＩＮＧフィールド（Ｂ５：Ｂ３）中の値は、垂直方向へのビットストリームの反復間の距離を与える。
ビットストリームモードで使用される構造は、図２６ａから２８ｄの実施例で理解することができる。
ここで図２６ａおよび２６ｂを参照すると、ビットストリームモードでＨＳＴＡＲＴおよびＶＳＴＡＲＴフィールドの異なる値を使用することによって達成することができる、異なるフレーム形式の実施例が示されている。両方の場合において、ＣＨＡＮＮＥＬ ＳＥＬＥＣＴＩＯＮフィールドは、００００００１１に設定される（すなわち、ポートから最初の２つのビットストリームデータチャネルを選択する）。ビットは、左上の隅から始まって、行に沿って行の終了まで移動し、次いで、次の行の最左ビットまで移動し、行の終了まで等、フレームに対するデータの全てが伝送されるまで継続して、伝送される。ビットストリームフレーム形式は、フレーム中の種々のビットに対するタイムスロットを定義することに留意されたい。ビットは、実際には、そのビットに対するデータを有する対応するデバイスによって送信される。例えば、図２６ａでは、Ｓ１５ビットは、マスタデバイス５２によって送信され、ビットストリームデータチャネルＭ０からの第１のビットは、そのチャネルを有するスレーブデバイスによって送信される。
図２６ａでは、０００１の値が、ＨＳＴＡＲＴフィールド中にあり、００００の値が、ＶＳＴＡＲＴフィールド中にあり、０００の値が、ＶＳＰＡＣＩＮＧフィールド中にあり（反復率が１となり、すなわち、間隙がないことを意味する）、１１１の値が、ＨＳＰＡＣＩＮＧフィールド中にある（１つだけのチャネルを有するであろうことを意味する）（これらの値は、図２７に従って符号化される）。示されるように、フレームは、ＳワードのＳ１５ビット、次いで、ポートの第１のデータチャネルＭ０からの第１のビット、およびポートの第２のデータチャネルＭ１からの第１のビットで始まる。Ｓワードからの次のビットＳ１４が送信され、その後に、ポートの第１のデータチャネルＭ０からの第２のビット、およびポートの第２のデータチャネルＭ２からの第２のビットが続く。このパターンは、フレームのＳワードからのビットの全てが送信されるまで継続し、その時に、フレームのＸワードからのビットが、データチャネルＭ０およびＭ１のビットが続くＳワードのビットと同様の方法で送信される。このパターンは、フレームのＸワードからのビットの全てが送信されるまで継続し、その時に、フレームのＹワードからのビットが、データチャネルＭ０およびＭ１のビットが続く同様の方法で送信される。この時点で、完全フレームが、バス６４上で送信されている。
図２６ｂでは、０００１の値が、ＨＳＴＡＲＴフィールド中にあり、００００の値が、ＶＳＴＡＲＴフィールド中にあり、０１０＝２ｘ１の値が、ＨＳＰＡＣＩＮＧフィールド中にあり、０００の値が、ＶＳＰＡＣＩＮＧフィールド中にある（値は図２７に示される表から導出される）。示されるように、フレームは、ＳワードのＳ１５ビット、次いで、ポートの第１のデータチャネルＭ０からの第１のビット、およびポートの第２のデータチャネルＭ１からの第１のビットで始まる。しかしながら、この時点で、ポートのデータチャネルからのデータは、繰り返される。したがって、ＨＳＰＡＣＩＮＧフィールドが２の値を有するので、データチャネルＭ０からの第２のビットが送信され、その後に、データチャネルＭ１からの第２のビットが続く。これは、最大数のビットストリームに達するまでＨＳＰＡＣＩＮＧ列の後にポートのデータチャネルからデータを繰り返し、次いで、コマンドワードから次のビットを送信すると考えることができる。次いで、Ｓワードからの次のビットＳ１４が送信され、その後に、それぞれ、データチャネルＭ０およびＭ１からの第３のビットが続き、その後に、再度、ポートのデータチャネルＭ０およびＭ１が続く。このパターンは、フレームのＳワードからのビットの全てが送信されるまで継続し、その時に、フレームのＸワードからのビット、それに続いて、データチャネルＭ０およびＭ１のビット２回が、Ｓワードのビットと同様に送信される。このパターンは、フレームのＸワードからのビットの全てが送信されるまで継続し、その時に、フレームのＹワードからのビット、それに続いて、データチャネルＭ０およびＭ１のビット２回が同様に送信される。いくつかの実施形態では、ＶＳＰＡＣＩＮＧおよびＨＳＰＡＣＩＮＧの符号化は、異なって、例えば、各フィールドに４ビットを使用し、情報の圧縮が使用されない、直接２進符号化を用いて、行われ得る。
概して、コマンドチャネルとして使用されるビットストリームフレーム中のビットストリームチャネルに書き込むことは違法である。なぜなら、これがバス６４をクラッシュするからである。したがって、少なくとも１つの実施形態では、００００の値がＨＳＴＡＲＴフィールドに書き込まれる場合には、いかなるデータ出力もバス６４上で許可されるべきではない。
少なくとも１つの実施形態では、ビットストリームモードでは、ＨＳＰＡＣＩＮＧおよびＶＳＰＡＣＩＮＧフィールド中のＬＳＢ値が、図２７の第１の表に示されるように定義される一方で、ＨＳＰＡＣＩＮＧおよびＶＳＰＡＣＩＮＧフィールド中のＭＳＢおよびＬＳＢ＋１値は、図２７の第２の表に示されるように定義される。全てのビットがＨＳＰＡＣＩＮＧおよびＶＳＰＡＣＩＮＧフィールドのうちの１つ中で１に設定される場合には、そのフィールドは無視されるであろう。そうでなければ、ビットストリームデータチャネルからのビットストリームは、ＬＳＢによって定義される乗数と、ＭＳＢおよびＬＳＢ＋１によって定義される乗数との積である距離で繰り返されるであろう。ＨＳＰＡＣＩＮＧフィールドの値が１１１である場合には、これは、ポートのビットストリームデータチャネルからのビットストリームが水平方向に繰り返されないであろうことを意味する。ＶＳＰＡＣＩＮＧフィールドの値が１１１である場合には、ポートのビットストリームデータチャネルからのビットストリームが垂直方向へ中断を伴わずに送信されるであろうことを意味する。これの実施例が、図２８ｄに示されている。別の実施形態では、ビットストリームモードでＴＤＭワードを転送するとき、ＶＳＰＡＣＩＮＧフィールドは、ポート情報（値が符号なし２進プラス１で符号化される、１から８の範囲内の値）を搬送するためにいくつのビットストリームが使用されるかを示すために使用することができ、ＨＳＰＡＣＩＮＧフィールドは、これらのビットストリームのうちの第１のものを示すために使用することができる。
ＨＳＴＡＲＴ、ＶＳＴＡＲＴ、ＨＳＰＡＣＩＮＧ、およびＶＳＰＡＣＩＮＧフィールドは、以下の実施例から分かるように、デバイスの各ポートについて含まれるデータチャネルに対して特定されることに留意されたい。
ここで図２８ａを参照すると、統一バス通信プロトコルを使用する、電流（Ｉ）および電圧（Ｖ）感知を伴うステレオシステム１７０の例示的実施形態が示されている。ステレオシステム１７０は、ベースバンドプロセッサ１７２と、第１のスピーカ１７６を伴う第１の増幅ユニット１７４と、第２のスピーカ１８０を伴う第２の増幅ユニット１７８と、バス１８２とを備える。第１の増幅ユニット１７４およびスピーカ１７６は、ステレオシステム１７０用の左オーディオチャネルであると見なすことができる一方で、第２の増幅ユニット１７８およびスピーカ１８０は、ステレオシステム１７０用の右オーディオチャネルであると見なすことができる。バス１８２は、ベースバンドプロセッサ１７２を第１および第２の増幅器ユニット１７４および１７８と連結する。バス１８２上の伝送は、統一バス通信プロトコルに従っている。
ベースバンドプロセッサ１７２は、処理ユニット１８４と、多重化および同期エンジン１８６と、メモリ１８８とを備える。処理ユニット１８４は、ＤＳＰ等のプロセッサ、または専用ハードウェア回路であり得る。多重化および同期エンジン１８６は、統一バス通信プロトコルに従ってバス１８２を経由して第１および第２の増幅ユニット１７４および１７８と通信し、その動作を制御することができるように、ベースバンドプロセッサ１７２がマスタデバイスとしての役割を果たすように構成される。
第１の増幅ユニット１７４は、制御ユニット１９０と、多重化および同期エンジン１９２と、デルタシグマ変換器１９４と、増幅器１９６と、電流センサ１９８と、電圧センサ２００とを備える。多重化および同期エンジン１９２は、第１の増幅ユニット１７４がスレーブデバイスとしての役割を果たすように構成され、統一バス通信プロトコルに従ってバス１８２を経由してベースバンドプロセッサ１７２と通信することができる。制御ユニット１９０は、第１の増幅ユニット１７４の動作を制御する、プロセッサまたは専用ハードウェアおよびファームウェアによって実装されることができる。動作時に、オーディオデータは、増幅のためにベースバンドプロセッサ１７２から第１の増幅ユニット１７４へ伝送される。オーディオデータは、変換器１９４を介してアナログ形式に変換され、増幅器１９６によって増幅され、スピーカ１７６によって出力される。増幅ユニット１７４の動作に関係する電流および電圧情報は、それぞれ、電流センサ１９８および電圧センサ２００によって測定され、増幅ユニット１７４の動作条件を監視するためにベースバンドプロセッサ１７２に伝送される。増幅ユニット１７４が、過熱、過電流、または電圧不足等の危険な状態にあることを監視が示す場合、ベースバンドプロセッサ１７２は、当業者によって理解されるように、危険な状態に対処するように制御命令を増幅ユニット１７４に送信することができる。
第２の増幅ユニット１７８は、制御ユニット２０２と、多重化および同期エンジン２０４と、デルタシグマ変換器２０６と、増幅器２０８と、電流センサ２１０と、電圧センサ２１２とを備える。多重化および同期エンジン２０４は、第２の増幅ユニット１７８がスレーブデバイスとしての役割を果たすように構成され、統一バス通信プロトコルに従ってバス１８２を経由してベースバンドプロセッサ１７２と通信することができる。制御ユニット２０２は、制御ユニット１９０と同様に実装されることができる。動作時に、第２の増幅ユニット１７８は、第１のオーディオ増幅ユニット１７４と同様に動作する。
多重化および同期エンジンブロック１９２および２０４は、ハードウェアブロックとして実装されることができることに留意されたい。さらに、代替実施形態では、制御ユニット１９０および２０２は、それぞれ、多重化および同期エンジン１９２および２０４と統合されることができる。
ここで図２８ｂを参照すると、図２８ａのステレオシステムに使用することができるビットストリームフレーム形式の例が示されている。このビットストリームフレーム形式では、水平次元のみが、ビットストリームデータチャネルを多重化するために使用される。この場合、使用される８つのフレームチャネルがある。第１のフレームチャネルは、制御ワードに対する制御ビットを伝送するために制御チャネルとして使用される。第２のフレームチャネルは、左ステレオチャネルに対するオーディオデータを伝送するために使用される。第３のフレームチャネルは、左ステレオチャネルに対する電圧情報を伝送するために使用される。第４のフレームチャネルは、左ステレオチャネルに対する電流情報を伝送するために使用される。第５のフレームチャネルは、データを伝送するために使用されない。これの理由は、現在のシステムと適合性がある動作周波数をサポートするために、７つの代わりに８つのビットストリームを使用することができ、それによって、１つのチャネルを空のままにすることである。第６のフレームチャネルは、右ステレオチャネルに対するオーディオデータを伝送するために使用される。第７のフレームチャネルは、右ステレオチャネルに対する電圧情報を伝送するために使用される。第８のフレームチャネルは、右ステレオチャネルに対する電流情報を伝送するために使用される。各フレームチャネルに対するデータは、１度に１ビット送信され、他のフレームチャネルと時間多重化される。このビットストリームフレーム形式は、合計３８４ビットに対して、４８ビットの長さおよび８ビットの幅を有する。実施例では、クロックレートは、４８ｋＨｚ×６４×７＝７×３．０７２Ｍｂｉｔであり、したがって、ｆｃｌｏｃｋ＝１２．２８８ＭＨｚである（両方のクロックエッジを使用し、最も近い共通クロック周波数に切り上げることによって求められる）。どれだけ多くの帯域幅を使用するかを決定するために、出力サンプルレートをオーバーサンプリングレートおよびビットストリームフレームチャネルの数で乗算することができる。例えば、４８ｋＨｚ出力サンプルレート、６４に等しいオーバーサンプリングレート、および７つのチャネルを仮定すると、これは、２１．５０４ＭＨｚに等しいであろう。しかしながら、これを１２．２８８ＭＨｚシステムと適合性があるようにするために、１つの空のチャネルが使用され得、２４．５７６ＭＨｚクロックシステムが使用される。データがクロックの両方のエッジ上で転送される場合、１２．２８８ＭＨｚクロックが使用される。
しかしながら、オーディオビットストリームチャネルＬおよびＲに使用される全オーディオ帯域幅は、電流および電圧感知には使用されない。これは、スピーカ１７６および１８０の機械的共鳴が全オーディオ帯域幅よりはるかに低いためである。加えて、熱時定数は、オーディオデータの変化よりはるかに長い。したがって、インピーダンスモデリングがオーディオデータほど多くの帯域幅を使用しないため、より小さい帯域幅を電流および電圧感知／制御データに使用することができる。
図２８ａの例示的システムでは、所与のフレームチャネル内で多重化することによって、帯域幅の使用を向上させることができる。この概念は、本実施例と同様に、種々のデータの帯域幅の差がある、オーディオ用途以外の他のタイプの用途に使用されることができる。共通フレームチャネル内の多重化は、帯域幅の使用の低減をもたらす、複数のデータチャネルの間でビットストリームフレームチャネルを共有することによって、達成される。換言すると、１つより多くのデータチャネルを単一のフレームチャネルに割り当てることは、オーバーサンプリング、および帯域幅の使用の変化を効果的にもたらす。これは、いくつかのカウンタおよびバッファを使用することによって、容易に実装されることができる。
ここで図２８ｃを参照すると、いくつかのデータチャネルが共通フレームチャネル（例えば、第３のフレームチャネル）に多重化される、図２８ａのステレオシステムに使用することができる、ビットストリームフレーム形式の別の実施例が示されている。これは、本実施例では、図２８ｂで使用されるフレーム形式に対するクロック周波数の半分である、より低いクロック周波数を使用して、同一のデータがバス１８２を経由して伝送されることを可能にする。
図２８ｃの実施例では、使用される４つのフレームチャネルがある。第１のフレームチャネルは、制御ワードに対する制御ビットを伝送するために制御チャネルとして使用される。第２のフレームチャネルは、左ステレオチャネルに対するオーディオデータを伝送するために使用される。第３のフレームチャネルは、左右のステレオチャネルに対する電圧および電流情報を伝送するために使用される。第４のフレームチャネルは、右ステレオチャネルに対するオーディオデータを伝送するために使用される。もう１度、各フレームチャネルに対するデータは、１度に１ビット送信され、他のフレームチャネルと時間多重化される。このビットストリームフレーム形式は、合計１９２ビットに対して、４８ビットの長さ（または行数）および４ビットの幅を有する。行数は、フレームチャネル中のデータがいくつかのフレームにわたって区分化される（これは、ＤＳ０−ＤＳ１ビットを使用することによって行われることができる）場合に、４８より長くあり得る。本実施例では、クロックレートは、４８ｋＨｚ×６４×（３＋１）＝４×３．０７２Ｍｂａｕｄ＝６．１４４ＭＨｚである。出力サンプルレートは、４８ｋＨｚであり、オーバーサンプルレートは、６４倍高く（すなわち、ビットストリームが出力サンプルにつき６４ビットを占有する）、１つの制御フレームチャネルを加えた３つのビットストリームフレームチャネルがある。したがって、これが占有する総帯域幅は、両方のデータエッジ上のサンプリングが使用される場合、４８ｋ／ｓ×６４ビット×４＝１２．２８８Ｍｂａｕｄ（Ｍｂｉｔ／ｓ＝Ｍｂａｕｄ）または６．１４４ＭＨｚである。
第３のフレームチャネルは、左オーディオチャネルに対する電圧情報のためのデータチャネルからのデータ、左オーディオチャネルに対する電流情報のためのデータチャネルからのデータ、右オーディオチャネルに対する電圧情報のためのデータチャネルからのデータ、および右オーディオチャネルに対する電流情報のためのデータチャネルからのデータが、垂直方向へ共通フレームチャネル中で一緒に多重化される、多重化フレームチャネルの実施例である。
この帯域幅制御の概念は、データチャネルからのデータを繰り返すように、追加のフレームチャネルをビットストリームフレーム形式に追加することによって、制御チャネルの帯域幅を制御するように拡張されることもできる。換言すると、ビットストリームフレーム形式の水平方向へビットストリームデータチャネルからのデータを繰り返すことによって、制御フレームチャネルに割り付けられた帯域幅を低減させることができ、したがって、制御ワードの伝送に使用される帯域幅は、より小さい。これの実施例は、制御フレームチャネルが、１／４＝２５％の帯域幅については４つのビットストリームフレームチャネルのうちの１つである、図２８ｃの実施例と比較して、制御フレームチャネルが、１／６＝１６．７％の帯域幅については６つのビットストリームフレームチャネルのうちの１つである、図２８ｄに示されている。この場合、クロックレートは、４８ｋＨｚ×（２００／３）×（２＋１）＝９．６Ｍｂｉｔ＝４．８ＭＨｚである（２００／３は、オーバーサンプリング率であり、２＋１は、オーディオデータに対する２つのチャネル、および他のデータに対する１つのチャネルを表す）。
ここで図２８ｄを参照すると、例示的実施形態においてビットストリームモードでＨＳＴＡＲＴ、ＶＳＴＡＲＴ、ＨＳＰＡＣＩＮＧ、およびＶＳＰＡＣＩＮＧフィールドの値を設定することによって達成することができる、ビットストリームフレーム形式の実施例が示されている。増幅ユニット１７４は、スレーブＤ１として指定され、増幅ユニット１７８は、スレーブＤ２として指定される。スレーブＤ１は、左オーディオチャネル用の第１のポートを提供し、ビットストリームフィールドに対する以下の設定、すなわち、ＨＳＴＡＲＴ＝０００１（すなわち、コマンドチャネル後の第１のビットストリームチャネル）、ＶＳＴＡＲＴ＝００００（すなわち、フレームの先頭から開始する）、ＨＳＰＡＣＩＮＧ＝００１＝１×３（すなわち、水平方向へ３ビット後に繰り返す）、およびＶＳＰＡＣＩＮＧ＝０００（すなわち、垂直方向へ次のビットの直後に繰り返す）を有する。スレーブＤ１は、ＩＶ感知用の第２のポートを提供し、ビットストリームフィールドに対する以下の設定、すなわち、ＨＳＴＡＲＴ＝００１１（すなわち、コマンドチャネル後の第３のビットストリームチャネル）、ＶＳＴＡＲＴ＝００００（すなわち、フレームの先頭から開始する）、ＨＳＰＡＣＩＮＧ＝１１１（すなわち、水平方向に繰り返さない）、およびＶＳＰＡＣＩＮＧ＝１００（すなわち、垂直方向へ４ビット後にポートからデータを繰り返す）を有する。スレーブＤ２は、右オーディオチャネル用の第１のポートを提供し、ビットストリームフィールドに対する以下の設定、すなわち、ＨＳＴＡＲＴ＝００１０（すなわち、コマンドチャネル後の第２のビットストリーム）、ＶＳＴＡＲＴ＝００００（すなわち、フレームの先頭から開始する）、ＨＳＰＡＣＩＮＧ＝００１＝１×３（すなわち、水平方向へ３ビット後に繰り返す）、およびＶＳＰＡＣＩＮＧ＝０００（垂直方向に間隙がない）を有する。スレーブＤ２もまた、ＩＶ感知用の第２のポートを提供し、ビットストリームフィールドに対する以下の設定、すなわち、ＨＳＴＡＲＴ＝００１１（すなわち、コマンドチャネル後の第３のビットストリームチャネル）、ＶＳＴＡＲＴ＝００１０（すなわち、第３のビットストリームチャネル中のフレームの先頭の下方で２ビットを開始する）、ＨＳＰＡＣＩＮＧ＝１１１（すなわち、水平方向に繰り返さない）、およびＶＳＰＡＣＩＮＧ＝１００＝４ｘ１（すなわち、垂直方向へ４つビットをスキップした後に繰り返す）を有する。
ＨＳＰＡＣＩＮＧおよびＶＳＰＡＣＩＮＧのパラメータを変化させることによって、制御チャネルに割り付けられる帯域幅の割合と比較して、等時性ビットストリームフレームチャネルに割り付けられる帯域幅の割合を変化させることができることが分かる。チャネルが、多くの場合、水平方向へ繰り返される（すなわち、ＨＳＰＡＣＩＮＧの低い値）場合には、より多くの帯域幅が、制御チャネルと比較して等時性チャネルに割り付けられる。ＶＳＰＡＣＩＮＧが大きい場合、より少ない帯域幅が、制御チャネルと比較して等時性チャネルに割り付けられる。本実施例は、４．８ＭＨｚで動作する両エッジサンプリングデータラインを使用することによって、２００／３（６４に近い）倍でオーバーサンプリングされる、２つのオーディオビットストリームチャネルを依然として転送し、その上、フィードバック用途に適した４つのデータチャネルも持つことができることを示す。ＳＬＩＭｂｕｓを用いて同じことをしようとすることは、２４．５７６ＭＨｚのシステムクロックを必要とするであろう。本実施例では、バスクロック周波数は、完全ステレオオーディオ、デバイス制御、およびＩＶ感知を伴って、わずか４．８ＭＨｚである。したがって、統一バス通信プロトコルの少なくとも１つの実施形態とともに、ビットストリームフレームチャネルの帯域幅制御を使用するという可能性によって、相当量の節電が得られる。
したがって、異なるビットストリームデータチャネルからのデータを共通フレームチャネルに組み込むこと、および異なるフレームチャネルへのビットストリームデータチャネルの割付を繰り返すことのうちの少なくとも１つを行うことによって、より効率的な帯域幅の使用、したがって、より効率的なデータ伝送のために、特定の用途に応じて、種々のデータチャネルおよび制御フレームチャネルの帯域幅を変化させることができる。
少なくともいくつかの実施形態では、ビットストリームモードでＴＤＭワードを転送することが可能である。この場合、ＳＵＢＧＲＯＵＰフィールドは、異なる解釈を有する。ＴＤＭワードは、他の列（すなわち、フレームチャネル）が存在しなかったかのように、単一の列（すなわち、単一のフレームチャネル）中で転送されるであろう。図１６ａを再度参照すると、次いで、ビットストリームモードで、ＳＵＢＧＲＯＵＰフィールドは、ビットストリームモードフィールド（ｒｅｇ．０ｘ０５、Ｂ５：Ｂ３）中でＴＤＭ ＷＯＲＤＳ ＴＲＡＮＳＦＥＲＲＥＤになるように修正される。次いで、ＳＵＢＧＲＯＵＰパラメータの以前の定義が可能ではなく、全てのポートは、これらのデータチャネルの間でいかなる中断も伴わずに、全ての選択されたチャネルから全てのデータを転送するであろう。ビットストリームモードフィールド中のＴＤＭ ＷＯＲＤＳ ＴＲＡＮＳＦＥＲＲＥＤは、ビットストリームフレーム形式で、どのビットストリームフレームチャネルがワードデータを転送するために使用されるかを示す。実施形態では、時分割多重化（ＴＤＭ）データを転送するために、ビットストリームフレームチャネル０−７を使用することができる。
ＴＤＭデータは、説明されるように、ビットストリームモードでサポートされることができるデジタルワードである。ビットストリームフレームチャネル０は、制御チャネルとして使用され、この例示的実施形態ではＳワード、Ｘワード、またはＹワードからビットを送信するためにのみ使用されるため、いかなるデータ出力にもマップされない。ビットストリームモードでは、ＤＳ０ビットは、単一のビットストリームフレームチャネル内の多数のデータチャネルをサポートするため、または制御チャネル中に間隙を伴わずに、各フレーム中でＳワード、Ｘワード、またはＹワードを送信することにより、この例示的実施形態では４８ビットであり、これらのワードが各々１６ビットである、ビットストリームフレーム長と適合性がないデータ長をサポートするために、データ伝送の開始を示すように使用されることができる。例えば、合計で６４ビットに等しい、１６ビットをそれぞれ有する、４つのデータチャネルが、ビットストリームモードで１つのフレームチャネル中で送信される必要があるとき、これは、いくつかのフレームにわたってデータ同期化を使用して行われることができる。他の実施形態では、ビットストリームチャネル中に配置されるＴＤＭワードのより良好な同期化を可能にするように、ビットストリームモードでさえも、制御ワードの間に間隔があり得る。
ここで図２９ａを参照すると、マスタデバイス５２に使用されることができるレジスタの定義の実施例が示されている。代替実施形態が図２９ｂに示されているが、以下の説明は、主に図２９ａに関係する実施形態に焦点を合わせる。レジスタは、概して、以下の機能、すなわち、アドレスポート、コマンドポート、および設定ポートを提供する、３つのグループに分離される。レジスタは、ここで説明される複数のフィールドの値を提供する。代替実施形態では、他のレジスタを定義することができ、レジスタの１つ以上のビットを使用して、これらのフィールドを実装することができることに留意されたい。代替実施形態では、異なる実装をこれらのフィールドに使用することができ、フィールドが異なって順序付けられ得、または使用される他のフィールド、あるいは使用される他のレジスタがあり得る。
ＣＯＭＭＡＮＤ ＳＥＰＡＲＡＴＩＯＮフィールド（ｒｅｇ．０ｘ０８、Ｂ７：Ｂ０）は、実施形態では、長さ８ビットであり、符号なし整数を表す。コマンド分離レジスタの機能は、図２５ａに示されるようなフレーム形式タイプの値に依存するであろう。図２５ｃは、統一バス通信プロトコルの実施形態で使用されるフレームタイプに応じた、ＣＯＭＭＡＮＤ ＳＥＰＡＲＡＴＩＯＮフィールドの定義の代替実施形態の実施例を示す。図２５ｃは、図２９ｂと併せて使用される。
フレームタイプがワードモードに設定される場合、ワードフレーム形式が使用され、コマンド分離距離は、ニブル（すなわち、４ビット）の単位で特定され、コマンドワード自体を含まない、２つのコマンドワードの間の距離を与える。分離値は、ゼロであり得、その場合、コマンド情報のみがバス６４に転送される（これは図４０に示されている）。デフォルト値は、レジスタをプログラミングするために帯域幅の増加を可能にする、４８ビットのデフォルトフレーム長と同等あるように設定されることができ、それによって、バス６４が迅速に設定され、アタッチされたスレーブデバイスがマスタデバイス５４との同期化を迅速に取得することを可能にする。
フレームタイプがビットストリームモードに設定される場合、ビットストリームフレーム形式が使用され、制御ビットは、データビットストリームの間でインターレースされるであろう。このモードでは、コマンド分離レジスタは、コマンドビットの間のデータビット数を与えるであろう。例えば、ＣＯＭＭＡＮＤ ＳＥＰＡＲＡＴＩＯＮフィールド中の３の値は、４ビットごとにコマンドビットが遭遇されるであろう（すなわち、コマンドビットは、データビットまたは空のタイムスロットであり得る、３ビットによって分離されるであろう）ことを意味する。ビットストリームモードでは、Ｓ、Ｘ、およびＹワードは、ビットストリームデータの間で離間され、ビットストリームに対する低遅延をもたらす。ビットストリームモードが使用される場合、少なくとも１つの実施形態では、スレーブデバイスの全てに対するロック時間を短縮するために、全てのスレーブデバイスがマスタデバイス５２との同期化を取得するまで、マスタデバイス５２がデータ通信を開始し、全てのデータスロット中でゼロを送信する前に、１つのアドレスが、最初に全てのスレーブデバイスに割り当てられ得る。スレーブデバイス５４がマスタデバイス５２とのロックから外れる場合、スレーブデバイス５４は、より長い全同期化検索を回避するために、ＣＯＭＭＡＮＤ ＳＥＰＡＲＡＴＩＯＮフィールドの以前の値および同一のフレームタイプとの同期化を再獲得しようとし得る。フレームタイプを制御する内部レジスタは、それが書き込まれる次のフレームの開始時に更新されるであろう。実施形態では、ＣＯＭＭＡＮＤ ＳＥＰＡＲＡＴＩＯＮフィールドのデフォルト値は、電源投入時に、３８４ビットのデフォルトフレーム長と同等である、０ｘ１Ｃであり得る。ビットストリームモードでコマンドワードの間に間隔を追加することが可能である。検索時間を制限するため、および単純化の目的で、いくつかの実施形態では、図２５ｂに示されるように、限定数のサブフレーム長が使用される。
少なくともいくつかの実施形態では、スレーブデバイスが、データ転送においていかなる中断も伴わずに、制御チャネルに割り付けられた帯域幅の割合およびフレーム形式を同時に変更することができない限り、このレジスタは、スレーブデバイスの内側で使用されない。他の場合において、スレーブデバイスの内部同期化エンジンは、必要な情報を提供され得る。いくつかの実施形態では、ＣＯＭＭＡＮＤ ＳＥＰＡＲＡＴＩＯＮフィールドは、全てのポートに対して共有されることができるが、各バンクレジスタに対するＣＯＭＭＡＮＤ ＳＥＰＡＲＡＴＩＯＮフィールドがあり得、ＢＡＮＫビットによってアクティブなフィールドを選択することができる。いくつかの実施形態では、フレームタイプビットを含む、ＣＯＭＭＡＮＤ ＳＥＰＡＲＡＴＩＯＮフィールドは、ＦＲＡＭＥ ＳＴＲＵＣＴＵＲＥフィールドによって置き換えられることができる。これらの構造の両方は、コマンドワードの間の分離、およびワードモードまたはビットストリーム数がデータを搬送するために使用されるかどうかについての情報を含む。
ＳＡＭＰＬＥ ＲＡＴＥ ＲＡＴＩＯフィールド（ｒｅｇ．０ｘ０９）は、ＴＤＭ出力を伴うシグマデルタ変換器に対するオーバーサンプリングレートを示すために使用され得る。このレジスタは、単純な方法でデシメーションおよび補間フィルタを設定するために、およびマルチフレーム同期化のサポートのために使用され得る。この情報は、多くの場合、ＣＯＭＭＡＮＤ ＳＥＰＡＲＡＴＩＯＮ値（ＦＲＡＭＥ ＳＴＲＵＣＴＵＲＥ値とも称することができる、図６９ａ参照）およびＲＥＰＥＡＴパラメータから、またはＦＲＡＣＴＩＯＮＡＬレジスタから直接推測することができる。しかしながら、データチャネルについて定義されるようなバスクロック周波数と出力サンプルの周波数との間の比を直接プログラムすることが便利である、場合がある（例えば、現在のＢＡＮＫの変更中、およびＲＥＰＥＡＴを使用してパラメータが６回以上繰り返される場合）。これは、ＳＡＭＰＬＥ ＲＡＴＥ ＲＡＴＩＯレジスタを使用することによって、達成される。加えて、このレジスタは、いくつかの実施形態では、マルチフレーム同期化のために保留されるフィールドを備え得る。この例示的実施形態では、ＳＡＭＰＬＥ ＲＡＴＥ ＲＡＴＩＯフィールドは、ＭＵＬＴＩ ＦＲＡＭＥ、ＦＩＲＳＴ ＳＴＡＧＥ、ＯＰＴＩＯＮＡＬ ＳＴＡＧＥ、ＳＥＣＯＮＤ ＳＴＡＧＥ、およびＴＨＩＲＤ ＳＴＡＧＥというサブフィールドを備える。
ＭＵＬＴＩ ＦＲＡＭＥフィールド（ｒｅｇ．０ｘ０９、Ｂ７）は、サブフレーム同期化の代わりに、ＤＳ０およびＤＳ１ビットによる同期化を選択するために使用され得る。ポート情報は、通常、Ｓ、Ｘ、およびＹワードの最後のビットに関して定義される。しかしながら、場合によっては、効率的なデータ転送のために、サブフレームの開始よりもむしろ、異なるタイミング基準、例えば、１つおきのサブフレームの開始が使用される。これは、ＭＵＬＴＩ ＦＲＡＭＥビットを真に設定し、同期化のソースとしてＤＳ０ビットまたはＤＳ１ビットのいずれかを選択すること（これはＳＹＮＣＨＲＯＮＩＺＥを「１０」または「１１」に等しく設定することによって行われる）によって、達成することができる。ＭＵＬＴＩ ＦＲＡＭＥビットが偽であるか、またはこのレジスタが欠落している場合、ＤＳ０およびＤＳ１ビットが同期化に使用されるときに分数転送のみがサポートされる。
ＦＩＲＳＴ ＳＴＡＧＥフィールド（ｒｅｇ．０ｘ０９、Ｂ６：Ｂ５）は、多段同期サンプルレート変換器の第１の段階に対するサンプルレート変換率を定義するために使用され得る。ＦＩＲＳＴ ＳＴＡＧＥフィールドがどのようにして符号化され得るかという実施例が、図２９ｃに示されている。サンプルレート変換率は、図２９ｃ−２９ｅに示されるように、フィールドの結果によって見出される。
ＯＰＴＩＯＮＡＬ ＳＴＡＧＥフィールド（ｒｅｇ．０ｘ０９、Ｂ４：Ｂ３）は、多段同期サンプルレート変換器の随意的な段階に対するサンプルレート変換率を定義するために使用され得る。この段階は、必要であれば、２６．００ＭＨｚ周波数の直接サポートに使用することができる。スペースを節約するために、ＯＰＴＩＯＮＡＬ ＳＴＡＧＥフィールドがどのようにして符号化され得るかという実施例が、図２９ｄに示されている。
ＳＥＣＯＮＤ ＳＴＡＧＥフィールド（ｒｅｇ．０ｘ０９、Ｂ２）は、多段同期サンプルレート変換器の第２または第３の段階に対するサンプルレート変換率を定義するために使用され得る。このセクションは、セクション１および３の反対側で実装することができ、すなわち、全体的なアクションがデシメーションである場合、第２の段階は、補間を行うことができ、全体的なアクションが補間である場合、第２の段階は、所与の係数によるデシメーションを行うことができる。これは、いくつかのシステム構成で、より良好な性能を可能にする。スペースを節約するために、ＳＥＣＯＮＤ ＳＴＡＧＥフィールドがどのようにして符号化され得るかという実施例が、図２９ｅに示されている。
ＴＨＩＲＤ ＳＴＡＧＥフィールド（ｒｅｇ．０ｘ０９、Ｂ１：Ｂ０）は、多段同期サンプルレート変換器の最後の段階に対するサンプルレート変換率を定義するために使用され得る。スペースを節約するために、ＴＨＩＲＤ ＳＴＡＧＥフィールドがどのようにして符号化され得るかという実施例が、図２９ｆに示されている。図２９ｇおよび２９ｈは、完全なマルチフォーマットデシメータおよび補間器システムを示す。具体的には、図２９ｇは、複数のサンプル率比および種々のクロック周波数との適合性に好適である、マルチフォーマットデシメータシステムの実施例を示す。各サンプルレート変換セクションは、選択されたサンプル率比にかかわらず、全体的な利得が一定であるように、倍率が先行するか、または後に続き得る。図２９ｈは、複数のサンプル率比および種々のクロック周波数との適合性に好適である、マルチフォーマット補間器システムの実施例を示す。各サンプルレート変換セクションは、選択されたサンプル率比にかかわらず、全体的な利得が一定であるように、倍率が先行するか、または後に続き得る。これが有益であれば、セクションの順番を変更すること、またはサンプルレート変換器の総利得が一定であることを確実にするようにセクションの間にスケーリングを追加することが可能である。
ＦＲＡＣＴＩＯＮＡＬフィールドは、２つのサブフィールド、すなわち、ＦＲＡＣＴＩＯＮＡＬ ＬＯＷ（ｒｅｇ．０ｘ０Ａ、Ｂ７：Ｂ０）およびＦＲＡＣＴＩＯＮＡＬ ＨＩＧＨ（ｒｅｇ．０ｘ０Ｂ、Ｂ７：Ｂ０）を有し、フラクショナルフローのデータ伝送に使用され得る。これは、システムクロックと、（ＲＥＰＥＡＴフィールドによって特定される）フレームあたりのサンプル数および（ＬＥＮＧＴＨフィールドによって特定される）フレームあたりのクロックサイクル数との間の比がすでに定義されているためである。ＦＲＡＣＴＩＯＮＡＬフィールドを設定することによって、分数オーバーサンプリング率Ｙ／Ｘが、ＦＲＡＣＴＩＯＮＡＬ ＨＩＧＨ（すなわち、Ｙ）フィールドとＦＲＡＣＴＩＯＮＡＬ ＬＯＷ（すなわち、Ｘ）フィールドとの間の比として定義される。マスタデバイス５２については、この機能は、分数データフローを制御するために使用され、随意的である。デフォルト値は全てゼロである。ＦＲＡＣＴＩＯＮＡＬ ＨＩＧＨ（Ｘ）フィールドおよびＦＲＡＣＴＩＯＮＡＬ ＬＯＷ（Ｙ）フィールドはまた、デシメータおよび補間器によって使用されるオーバーサンプリング率を定義するために使用され得る。他の実施形態では、このフィールドの符号化は、異なり得るが、依然として２つの２進符号化ワードの間の比を示すために使用される。
ＡＤＤＲＥＳＳフィールド（レジスタ０ｘ０Ｃおよび０ｘ０Ｄ）は、どのレジスタ上で、マスタデバイス５２、および随意にスレーブデバイス５４が、ＲＥＡＤ、ＷＲＩＴＥ、またはＦＵＮＣＴＩＯＮ動作を行うかを選択するために使用され得る。それはまた、内部関数を実行するときにスレーブデバイスによって使用されることもできる。
ＦＵＮＣＴＩＯＮフィールド（ｒｅｇ．０ｘ０Ｅ）は、ＦＲＡＭＥ ＣＯＮＴＲＯＬレジスタを使用してＦＵＮＣＴＩＯＮ動作を開始するときに、どのような動作が開始されるかを定義するために使用され得る。
以下のフィールド、すなわち、ＦＲＡＭＥ ＣＯＮＴＲＯＬ、ＣＵＲＲＥＮＴ ＢＡＮＫ、およびＳＬＡＶＥ ＤＥＶＩＣＥ ＡＤＤＲＥＳＳを有する、フレーム制御レジスタフィールド（ｒｅｇ．０ｘ０Ｆ）が使用され得る。これらのフィールドは、レジスタの１つ以上のビットを使用して、実装されることができる。代替実施形態では、異なる実装をこれらのフィールドに使用することができ、フィールドが異なって順序付けられ得、または使用される他のフィールド、あるいは使用される他のレジスタがあり得る。例えば、代替実施形態では、フレーム制御レジスタフィールドは、ＤＡＴＡ ＳＩＺＥおよびＰＯＷＥＲフィールドを備え得る。
ＦＲＡＭＥ ＣＯＮＴＲＯＬフィールド（ｒｅｇ．０ｘ０Ｆ、Ｂ７：Ｂ５）は、ＲＥＡＤ／ＷＲＩＴＥ／ＦＵＮＣＴＩＯＮ動作を開始するため、およびＷＲＩＴＥ動作の進行を監視するために使用され得る。このフィールドへの書き込みの解釈の実施例が、図２９ｉに示されている。このフィールドから読み取るとき、返される値は、現在のフレーム動作に等しいであろう。このフィールドに書き込んだ後、所望の動作が１回実行されることができる。この後、動作は、この例示的実施形態ではＰＩＮＧ動作であり得る。ＦＲＡＭＥ ＣＯＮＴＲＯＬレジスタは、次のフレームに対する動作モードを選択する。したがって、ＲＥＡＤ動作を開始するために、ＲＥＡＤ動作に対する正しい３ビットコード定数（８または１６ビット読み取りデータのいずれか）が、マスタデバイス５２の内側のＦＲＡＭＥ ＣＯＮＴＲＯＬレジスタに書き込まれ、その後に、デバイスレジスタＲＥＡＤ動作が次のフレーム中で始まるであろう。
ＣＵＲＲＥＮＴ ＢＡＮＫフィールド（ｒｅｇ．０ｘ０Ｆ、Ｂ４）は、データ転送のパラメータを特定するためにスレーブデバイス５４が使用するべきである、現在のレジスタバンクを選択するために使用され得る。このフィールドは、ＰＩＮＧおよび他の動作中に異なる意味を有する。デフォルト値はゼロである。ＰＩＮＧ動作中、このフィールドは、スレーブデバイス５４を制御するためにどのメモリバンクが使用されるかを選択するために使用することができる。したがって、フレーム形式またはオーディオモードを変更するために、バス６４にアタッチされたデバイスが異なるメモリバンクを使用し得るように、ＣＵＲＲＥＮＴ ＢＡＮＫビットを変更するＰＩＮＧコマンドが最初に発行される。例えば、ＲＥＡＤ、ＷＲＩＴＥ、およびＦＵＮＣＴＩＯＮ動作等の他の動作中、このフィールドは、どのメモリバンクに現在の動作（すなわち、ＲＥＡＤ、ＷＲＩＴＥ、またはＦＵＮＣＴＩＯＮ）が適用されるかを選択するために使用されることができる。これは、オーディオ出力においていかなる故障も伴わずに２つの異なるオーディオモードの間で切り替えること等の、出力においていかなる故障も伴わずに２つの異なるデータモードの間でシームレスに切り替えるように、２つの交互レジスタセットの間で選択するために使用されることができる。スレーブデバイス５４は、新しい設定が次のフレームの開始時に使用されるように、各自のレジスタを内部で更新するべきである。これを行う１つの方法は、ＢＡＮＫフィールド（Ｘ１２）上にＣＵＲＲＥＮＴ ＢＡＮＫビットをビットコピーすることである。スレーブレジスタ０ｘ０２から０ｘ０７中の全ての値は、Ｘ１２タイムスロットによって（すなわち、Ｘワードで）選択される。例示的実施形態では、全てのスレーブデバイスは、ポートへのデータおよびポートからのデータのストリーミングのために２つの動作モードを有することができる。データモード間の実際の変化は、Ｘコマンドワードの伝送後の２つのフレーム境界後に起こるであろう（すなわち、スレーブデバイスは、例えば、Ｘ１２ビットの２つの等しい読み取り値が取得されたときに、最初にその内部バンクを変更することができる）。これは、ＢＡＮＫビットが、１つの値、例えば、ゼロから、別の値、例えば、１に変化しているときに、スレーブデバイスが、以前に使用された値とは異なる値とともに補助レジスタバンク（例えば、レジスタ０ｘ０２−０ｘ０７の代替セット）を使用するであろうことを意味する。この変化は、ＢＡＮＫビットがＰＩＮＧフレーム中で変化した第２のフレームの後に、全てのスレーブデバイスで起こる。２つのレジスタバンクは、同一のＢＡＮＫビットによって、ＲＥＡＤ、ＷＲＩＴＥ、およびＦＵＮＣＴＩＯＮ動作中に選択される。ＣＵＲＲＥＮＴ ＢＡＮＫビットは、次のフレームに対するＸ１２（ＢＡＮＫ）ビットの値を決定するために、マスタデバイス５２によって使用される。
ＳＬＡＶＥ ＤＥＶＩＣＥ ＡＤＤＲＥＳＳフィールド（ｒｅｇ．０ｘ０Ｆ、Ｂ３：Ｂ０）は、最上位ビットとしてＢ３を有し、選択されるスレーブデバイスアドレスを特定するために使用され得る。リセット後のデフォルト値は、「００００」である。スレーブデバイスアドレス「１１１１」が使用されるとき、コマンドが全てのデバイスにブロードキャストされるであろう。しかしながら、同時に複数のデバイスから読み取る場合に曖昧性をもたらし得るため、ブロードキャストコマンドの使用については注意するべきである。また、以下でさらに詳細に説明されるように、いくつかのデバイスを同時に選択することができるように、マスタデバイス５２によって選択される特定のデバイス群を定義することができる、実施形態があり得る。
ＩＮＴＥＲＦＡＣＥ ＣＯＮＴＲＯＬレジスタ（ｒｅｇ．０ｘ０１０）は、動作周波数、クロックソース、およびマルチマスタデバイス動作の選択を設定すること等のバス６４の基本動作を制御するために使用され得る。例示的実施形態では、ＩＮＴＥＲＦＡＣＥ ＣＯＮＴＲＯＬレジスタは、以下のサブフィールド、すなわち、図３２ａにも示される、ＭＣＬＫＤ、ＣＬＯＣＫ ＳＯＵＲＣＥ、ＥＮＡＢＬＥ ＭＵＬＴＩ ＭＡＳＴＥＲ、ＥＮＡＢＬＥ ＭＡＳＴＥＲ ＩＲＱ、およびＲＥＱＵＥＳＴ ＭＵＬＴＩ ＭＡＳＴＥＲを備える（図２９ｂに対応する代替実施形態が図３２ｂに示されている）。これらのフィールドは、レジスタの１つ以上のビットを使用して、実装されることができる。代替実施形態では、異なる実装をこれらのフィールドに使用することができ、フィールドが異なって順序付けられ得、または使用される他のフィールド、あるいは使用される他のレジスタがあり得る。リセットイベント後のＩＮＴＥＲＦＡＣＥ ＣＯＮＴＲＯＬフィールドのデフォルト値は、「０００１００００」に設定される。
ＭＣＬＫＤクロック分割フィールド（ｒｅｇ．０ｘ１０、Ｂ７：Ｂ４）は、バス６４に使用されるクロック信号（すなわち、クロックバス信号）の周波数を設定するために使用され得る。実施形態では、バスクロック信号の周波数は、周波数分割を使用することによって、外部クロックソース信号（ＥＸＴＣＬＫ）から導出され得る。周波数分割は、ＩＮＴＥＲＦＡＣＥ ＣＯＮＴＲＯＬフィールドのＭＣＬＫＤフィールドによって決定される。例示的実施形態では、外部バスクロック信号は、単一の立ち上がりエッジのみを有するが、マスタデバイス５２の内部回路は、少なくとも２つの立ち上がりエッジを使用する。したがって、全ての分割率は、２という因数に基づく。図３３ａは、少なくとも１つの例示的実施形態では、スペースを節約するために、どのようにしてＭＣＬＫＤフィールドが符号化され得るかという実施例を示す。図３３ｂは、図２９ｂに対応する実施形態で使用され得る、周波数分割を示し、その場合、周波数分割に使用される因数は、単一ワイヤバス実施形態については最後から２番目の列、２ワイヤバス実施形態については最後の列で特定される。クロック分割率が「００００」であるとき、バスクロック信号が停止し、クロック出力が低く駆動されるであろう。ＰＬＬを採用するシステムは、動作モード、例えば、低または高周波数動作、あるいは分数ＰＬＬクロックシステムに対する約数を設定するために、カスタムレジスタを使用することができる。ＭＣＬＫＤフィールドのデフォルト値は、「０００１」に設定される。
少なくともいくつかの実施形態では、クロック信号ラインもまた、電力を節約するように、静的レベル（例えば、低論理または高論理値のいずれか）で保たれ得る。この場合、クロック分割器は、分割率が整数ではない場合を除いて、立ち上がりクロックエッジ上の出力を変化させる。したがって、電力低下モードに整数除算値を使用することが利点である。加えて、クロック変化は、フレームの開始時に起こる。クロック分割因数が０である場合、いかなるクロック出力もない。この条件で、マルチマスタモードが有効にされない場合には、変化がクロックライン上で起こる前にデータラインが変化すれば、クロックが再び再起動する。これは、非常に低電力の動作に使用されることができる。いくつかの実施形態では、本システムは、完全バッファ状態を信号伝達し得るＵＡＲＴコントローラからの要求に迅速に応答することができるように、クロックを再び開始する明確に定義された時間、例えば、１マイクロ秒を有するであろう。データラインが変化した後に供給される初期クロック信号は、約１マイクロ秒であり得る、非常に迅速な起動時間という利点を有する、ＲＣ駆動型緩和発振器等の通常使用される（典型的には、水晶発振器）ほど正確ではないクロック信号であり得る。緩和発振器は、高品質水晶発振器よりかなり多くのジッタを有し、サンプリングイベントで精度の増加があり得る、高品質オーディオ目的に適していない。後に、主要水晶発振器が完全に安定化したとき、マスタデバイス５２は、クロックソースをこの他のソースに変更し得る。このスキームを使用することによって、低電力モードから回復するときに、ＵＡＲＴコントローラからデータを迅速に捕捉し、それによって、いかなるデータも損失しないように、高速起動時間を有するとともに、精密オーディオ目的で高品質の低ジッタクロック信号を依然として供給することが可能である。
ＣＬＯＣＫ ＳＯＵＲＣＥフィールド（ｒｅｇ．０ｘ１０、Ｂ３）は、２つの異なるクロックソースの間で選択するために使用され得る。マスタデバイス５２がこの特徴をサポートすることは随意的である。高周波数クロック、例えば、オーディオ用途のための１９．２０ＭＨｚ、および低周波数クロック、例えば、低電力動作に使用される３２．７６８ｋＨｚがあり得る。これらの場合において、マスタデバイス５２は、データにおいていかなる故障も起こらないように、これらのクロックソースの間でゲート制御するか、または切り替える。クロックソース間の変更は、クロック信号が低であるときにフレームの終了時に行われることができる。別の実施形態では、マスタデバイス５２は、クロックを無効にし、別のデバイスがクロックを駆動することができるという可能性のために、バスホルダを使用してクロックラインを低いままにさせることができる。いくつかの実施形態では、クロック発振器のうちの１つは、高品質クロックソースであり得、他方は、より不良なジッタ性能を伴う高速安定化クロックソースであり得る。
ＥＮＡＢＬＥ ＭＵＬＴＩ ＭＡＳＴＥＲフィールド（ｒｅｇ．０ｘ１０、Ｂ２）は、複数のマスタデバイスの使用を有効にするために使用され得、１に設定されるときにアクティブである。マスタデバイスがこのビットを１に設定する場合、別のマスタデバイスは、コマンドフィールドセクション中にコマンドを書き込み始めることができる。それは、ＰＩＮＧ動作中にＸ８ビットの値を決定するために使用される。このビットから読み取るとき、それは、最後に読み取られたＸ９ビットの状態を返すであろう。このビットは、バスクロック信号を生成するマスタデバイスによってアクティブにされることができる。デフォルト設定は１である（すなわち、有効にされる）。
ＥＮＡＢＬＥ ＭＡＳＴＥＲ ＩＲＱ ＭＡＳＫフィールド（ｒｅｇ．０ｘ１０、Ｂ１）は、ＰＩＮＧ動作中のＸ９ビットのアクティブ化に基づいて、割り込みを有効にするために使用され得る。１に設定されるとき、Ｘ９ビットは、マスタデバイス５２へのＩＲＱを生成するであろう。さらに、Ｘ９ビットは、スレーブデバイスからのＩＲＱのように扱われることができる（すなわち、Ｓ０ビットがこの例示的実施形態で設定されるべきである）。デフォルト設定はゼロである（すなわち、無効にされる）。
ＲＥＱＵＥＳＴ ＭＵＬＴＩ ＭＡＳＴＥＲフィールド（ｒｅｇ．０ｘ１０、Ｂ０）は、Ｘ９ビット上にコピーされ得、マルチマスタ動作に対する要求を信号伝達するために使用され得る。許可された場合、それは、このビットを再度解放するべきである（すなわち、それをゼロに設定する）。このビットを読み取るとき、それは、バス６４から読み取られた最後のＸ９ビットの状態を与えるであろう。
ＩＲＱ ＭＡＳＫレジスタ（ｒｅｇ．０ｘ１１）は、どのイベントがマスタデバイス５２への割り込み要求を生成することを可能にされるかを決定するために使用され得る。図３４ａは、ＩＲＱ ＭＡＳＫレジスタで使用されることができるサブフィールドの実施例を示す（代替実施形態が図２９ｂに対応する図３４ｂに示されている）。図３４ｂの実施形態では、サブフィールドは、ＢＵＳ ＥＲＲＯＲ ＭＡＳＫフィールド、ＩＯ ＥＲＲＯＲ ＭＡＳＫフィールド、ＡＴＴＥＮＴＩＯＮ ＭＡＳＫフィールド、Ｓ０ ＤＥＬＡＹ ＥＮＡＢＬＥフィールド、ＡＴＴＡＣＨＭＥＮＴ ＭＡＳＫフィールド、ＷＲＣ ＭＡＳＫフィールド、ＲＤＣ ＭＡＳＫフィールド、およびＦＲＡＭＥ ＤＯＮＥ ＭＡＳＫフィールドを含む。これらのフィールドは、レジスタの１つ以上のビットを使用して、実装されることができる。代替実施形態では、異なる実装をこれらのフィールドに使用することができ、フィールドが異なって順序付けられ得、または使用される他のフィールド、あるいは使用される他のレジスタがあり得る。ＩＲＱ ＭＡＳＫフィールド内のビットの各々は、マスタデバイス５２によって読み取られるか、または書き込まれる。スレーブデバイスは、例えば、「１０」以上のスレーブ状態レベルを示して、またはデバイス状態レベルを変更することによって、これらのビットのうちのいくつかを間接的に設定または消去し得る。代替実施形態（すなわち、図３４ａ）では、ＷＲＣおよびＲＤＣビットが、ＩＯＣ（ＩＯ動作完了）ビットおよび（マルチマスタ動作に使用される、ＸおよびＹワードの変化を監視する）ＣＯＭＭＡＮＤ ＥＲＲＯＲビット、ならびに対応するマスクビットによって置換されるであろう。
ＢＵＳ ＥＲＲＯＲ ＭＡＳＫフィールド（ｒｅｇ．０ｘ１１、Ｂ７）は、マスタ割り込みを有効または無効にするために使用され得る。このフィールドが高に設定されるとき、状態レジスタ中のアクティブなバスエラービットに基づいて割り込みを有効にするであろう。この割り込みは、アクティブローレベル出力によって信号伝達され、状態レジスタ０ｘ１２を読み取るときに消去される。
ＩＯ ＥＲＲＯＲ ＭＡＳＫフィールド（ｒｅｇ．０ｘ１１、Ｂ６）は、Ｉ２Ｃ割り込みを有効または無効にするために使用され得る。このフィールドが高に設定されるとき、状態レジスタ中のアクティブなＩＯエラービットに基づいて割り込みを有効にするであろう（すなわち、ＲＥＡＤ／ＷＲＩＴＥ／ＦＵＮＣＴＩＯＮコマンドに続く確認ビットＳ１４が設定されない）。この割り込みは、アクティブローレベル出力によって信号伝達され、状態レジスタを読み取るときに消去される。
ＡＴＴＥＮＴＩＯＮ ＭＡＳＫフィールド（ｒｅｇ．０ｘ１１、Ｂ５）は、Ｓ０ビットをアクティブにすることによって、スレーブデバイス注意要求に基づいてマスタ割り込みを有効または無効にするために使用され得る。このフィールドが高に設定されるとき、「１０」または「１１」のスレーブ状態レベルに基づいて割り込みを有効にするであろう。換言すると、ＡＴＴＥＮＴＩＯＮ ＭＡＳＫフィールドが有効にされるとき、マスタデバイス５２は、スレーブデバイス５４が注意を要求するときはいつでも割り込みを生成するであろう。割り込みは、アクティブローレベル出力として、マスタデバイス５２によってコントローラに信号伝達され、状態レジスタを読み取るときに消去される。スレーブデバイス５４が依然として注意を要求しており、ＡＴＴＥＮＴＩＯＮ ＭＡＳＫフィールドが依然として次のフレーム中で有効にされる場合、新しい割り込みが生成されるであろう。マスタデバイス５２は、複数の割り込みが生成されることを回避するように、ＩＲＱが起こるときにＡＴＴＥＮＴＩＯＮ ＭＡＳＫフィールドを消去することができる。
Ｓ０ ＤＥＬＡＹ ＥＮＡＢＬＥフィールド（ｒｅｇ．０ｘ１１、Ｂ４）は、スレーブデバイス５４が注意を要求するときに、ＲＥＡＤ、ＷＲＩＴＥ、またはＦＵＮＣＴＩＯＮ動作の遅延を有効または無効にするために使用され得る。Ｓ０ ＤＥＬＡＹ ＥＮＡＢＬＥフィールドが高に設定されるとき、Ｓ０タイムスロット中にバス６４から読み取られる値に基づいて、強制ＰＩＮＧ動作を有効にするであろう。スレーブデバイス５４は、「１０」または「１１」のスレーブデバイス状態を有するときに、注意の必要性を信号伝達するようにＳ０ビットをアクティブにすることができる（すなわち、スレーブデバイス５４は、Ｓ０タイムスロット中にその状態レジスタのＭＳＢをコピーすることができる）。現在の動作がＲＥＡＤ、ＷＲＩＴＥ、またはＦＵＮＣＴＩＯＮ動作である場合、次のフレームまで遅延させられ、Ｓ０ ＤＥＬＡＹ ＥＮＡＢＬＥフィールドおよびＳ０ビットが１に等しければＰＩＮＧ動作によって置換されるであろう。次のフレームの開始時に、ＲＥＡＤ、ＷＲＩＴＥ、またはＦＵＮＣＴＩＯＮ動作が再試行されるであろう。ＰＩＮＧ動作は、Ｓ０ビットの値にかかわらず、不変に続行するであろう。Ｓ０ ＤＥＬＡＹ ＥＮＡＢＬＥフィールドを有効にすることによって、任意のスレーブデバイスが注意を必要とする場合に、多くても１つのフレームの待ち時間が生じるであろう。コマンドワード以外のデータトラフィックが、デバイス状態を読み取りながら、依然として継続することができる。Ｓ０ ＤＥＬＡＹ ＥＮＡＢＬＥフィールドが「０」である場合、Ｓ０ビットの値にかかわらず、任意のＲＥＡＤ、ＷＲＩＴＥ、またはＦＵＮＣＴＩＯＮトランザクションが続行する。マスタデバイス５２は、スレーブレジスタの読み取りまたは書き込みを阻止することを回避するように、ＩＲＱが信号伝達されるときにＳ０ ＤＥＬＡＹ ＥＮＡＢＬＥフィールドを消去することができる。
ＡＴＴＡＣＨＭＥＮＴ ＭＡＳＫビット（ｒｅｇ．０ｘ１１、Ｂ３）は、これらの割り込みを有効または無効にすることによって、デバイスアタッチ監視を制御するために使用され得る。このビットが低であるとき、アクティブなＡＴＴＡＣＨＭＥＮＴビットによる任意の割り込みが無効にされる。このフィールドが高に設定されるとき、アタッチされている、またはバス６４から除去されているデバイスに基づいて、割り込みを有効にし、それによって、ＡＴＴＡＣＨＭＥＮＴビットを高に設定するであろう。スレーブデバイスがその状態値を変化させる場合、またはスレーブデバイスがバス６４から除去される（それによって、その状態値を効果的に変化させるＰＩＮＧ動作中に信号伝達しない）場合、またはスレーブデバイスがもはやマスタデバイスと同期しなくなり、それによって、信号伝達を停止する場合、または（物理的アタッチ後または同期化が取得された後に）スレーブデバイスがマスタデバイスと同期し、この状態値がＰＩＮＧ動作によって読み取られた場合に、これが起こり得る。ＡＴＴＡＣＨＭＥＮＴ割り込みは、状態レジスタ０ｘ１２（すなわち、ＡＴＴＡＣＨＭＥＮＴビットを含むレジスタ）を読み取るときに消去される。読み取られる状態値がマスタデバイス５２からの介入の必要性を示す（すなわち、状態値が「１０」または「１１」である）場合、マスタデバイス５２のコントローラに対する通常動作は、割り込みのソースを見出すように、スレーブ状態レジスタからデバイス状態値をリードバックすることであろう。これが完了した後、注意を必要とするスレーブデバイスへのレジスタ制御コマンドを書き込むことによって、任意の必要なアクションを実行することができる。
ＷＲＣ ＭＡＳＫフィールド（ｒｅｇ．０ｘ１１、Ｂ２）は、割り込みを有効または無効にするために使用され得る。ＩＲＱ ＭＡＳＫレジスタ０ｘ１１は、外部または内部の専用（すなわち、物理的）割り込みラインを通ってマスタデバイス５２に直接向かう、割り込みを有効または無効にする。これらの割り込みは、典型的には、ＷＲＩＴＥ動作が完了した後に、バス６４を経由し、マスタデバイス５２からの専用ラインを通らずに通信される、スレーブデバイスからの割り込みと同一ではない。割り込みは、専用ラインを通ってマスタバスコントローラから直接通信される。このフィールドが高に設定されるとき、アクティブなＷＲＩＴＥ動作の完了に基づいて、割り込みを有効にするであろう。これは、ＷＲＣビット上の高・低遷移から見出されることができる。割り込みは、アクティブローレベル出力によって信号伝達されることができる。割り込みは、状態レジスタ０ｘ１２を読み取るときに消去されることができる。代替実施形態（すなわち、図３４ａ）では、このビットは、ＩＯ動作の完了をマスクするため、およびＩＯ動作（ＲＥＡＤ／ＷＲＩＴＥ／ＦＵＮＣＴＩＯＮ）が完了したときに割り込みを有効にするために使用され得る。割り込みのマスキングは、ＷＲＣ ＭＡＳＫフィールドに類似するであろう。
ＲＤＣ ＭＡＳＫフィールド（ｒｅｇ．０ｘ１１、Ｂ１）は、ＷＲＣ ＭＡＳＫフィールドについて上記で説明されたものと同様に、ＲＥＡＤ動作が完了した後に、マスタデバイスからの割り込みを有効または無効にするために使用され得る。このフィールドが高に設定されるとき、アクティブなＲＥＡＤ動作の完了に基づいて、割り込みを有効にするであろう。これは、ＲＤＣビット上の高・低遷移から見出すことができる。割り込みは、アクティブローレベル出力によって信号伝達されることができる。割り込みは、状態レジスタ０ｘ１２を読み取るときに消去されることができる。代替実施形態（すなわち、図３４ａ）では、このビットは、ＣＯＭＭＡＮＤ ＥＲＲＯＲ割り込み、すなわち、主要マスタデバイス以外のデバイスによって行われる、ＸおよびＹワードに位置するビットの変化をマスクするために使用され得る。このビットは、アクティブハイである。これは、マルチマスタモードが許可されないときに、安全対策として使用され得る。このＩＲＱマスクビットは、マルチマスタ動作モードでは無効にされるべきである。
ＦＲＡＭＥ ＤＯＮＥ ＭＡＳＫフィールド（ｒｅｇ．０ｘ１１、Ｂ０）は、立ち上がりクロックエッジ上のフレームの完了時にアクティブにされる、マスタ割り込み（代替実施形態では専用ラインを通して、またはＩ２Ｃを通して信号伝達される）を有効または無効にするために使用され得る。このフィールドが高に設定されるとき、内部フレームカウンタの完了に基づいて、割り込みを有効にするであろう。マスタデバイス５２中の内部フレームカウンタは、ＦＲＡＭＥ ＤＯＮＥ ＭＡＳＫフィールドを変更するための例示的タイミング図を示す、図３５に示されるように、変更モード中に依然として作動しているべきである。変更モードでは、インターフェース７０中の電力トランジスタ７６（図３ｂ参照）はオンにされる。
図３６ａを参照すると、例示的実施形態では、ＩＮＴＥＲＦＡＣＥ ＳＴＡＴＵＳレジスタ（ｒｅｇ．０ｘ１２）は、いくつかのサブフィールドを備える（代替実施形態が図２９ｂに対応する図３６ｂに示されている）。図３６ｂの例示的実施形態では、ＩＮＴＥＲＦＡＣＥ ＳＴＡＴＵＳレジスタは、ＢＵＳ ＥＲＲＯＲフィールド、ＩＯ ＥＲＲＯＲフィールド、ＳＴＡＴＵＳ１およびＳＴＡＴＵＳ０フィールド、ＡＴＴＡＣＨＭＥＮＴフィールド、ＷＲＣフィールド、ＲＤＣフィールド、ＦＲＡＭＥ ＤＯＮＥフィールド、およびＳＬＡＶＥ ＳＴＡＴＵＳフィールドを備える。これらのフィールドは、レジスタの１つ以上のビットを使用して、実装されることができる。代替実施形態では、異なる実装をこれらのフィールドに使用することができ、フィールドが異なって順序付けられ得、または使用される他のフィールド、あるいは使用される他のレジスタがあり得る。リセットイベント後のＩＮＴＥＲＦＡＣＥ ＳＴＡＴＵＳレジスタのデフォルト値は、「００００００００」であり得る。一般に、ＩＮＴＥＲＦＡＣＥ ＳＴＡＴＵＳレジスタは、バス６４からの状態情報を有し、ＩＲＱを制御するために使用される。代替実施形態（すなわち、図３６ａ）では、ＷＲＣおよびＲＤＣビットは、ＩＯＣ（ＩＯ動作完了）ビットおよび（マルチマスタ動作に使用される、ＸおよびＹワードの変化を監視する）ＣＯＭＭＡＮＤ ＥＲＲＯＲビット、ならびに対応するマスクビットによって置換されるであろう。マルチマスタ動作は、ＰＩＮＧ動作中に、これらのビットの両方、ならびにＸ９およびＸ８制御ビットを使用し得る。これは、複数のＩ２Ｃ接続を伴う状況で、または試験目的で使用することができ、外部ユニットが、システムハードウェアまたはソフトウェアへの変更を必要とすることなく、バス６４に接続されたデバイスの内部状態をリードバックし得る。
動作中に、ＩＮＴＥＲＦＡＣＥ ＳＴＡＴＵＳフィールドは、バス６４からの状態情報を提供し、マスタデバイス５２へのＩＲＱをアクティブにするために使用され得る。それは、マスタデバイス５２またはスレーブデバイス５４による、ＲＥＡＤ、ＷＲＩＴＥ、ＰＩＮＧ、およびＦＵＮＣＴＩＯＮ動作によって制御される。ＩＮＴＥＲＦＡＣＥ ＳＴＡＴＵＳレジスタ内のビットの各々は、マスタデバイス５２によって読み取られ、使用されることができる。このフィールドは、マスタデバイス５２とスレーブデバイス５４との間のデータ通信を制御することを支援し、また、バスにアタッチされたスレーブデバイスの状態を監視するために使用されることもできる。
ＢＵＳ ＥＲＲＯＲフィールド（ｒｅｇ．０ｘ１２、Ｂ７）は、アクティブハイであるときに違法バス動作が起こったことを示すために使用され得る。この条件は、バス６４上の値が、マスタデバイス５２がバス６４を駆動している（例えば、スレーブデバイスが同期化パターンと対立している）ときにあるべき値とは異なる場合に、検出されることができる。違法バス動作が検出されると、それは、ＢＵＳ ＥＲＲＯＲフィールドが読み取られるまで設定されたままとなるであろう。違法バス動作が観察され、対応するＩＲＱ ＭＡＳＫビットが有効にされる（すなわち、高に設定される）場合に、割り込みが生成されるであろう。マルチマスタ動作状態が許可された（ＰＩＮＧ動作におけるＲＥＬＥＡＳＥ ＢＵＳビット（Ｘ８）がゼロである）とき、コマンドワードのＸおよびＹフィールド中の任意のバス対立は、別のマスタデバイスによって引き起こされると仮定されるため、これらは無視されるべきである。この場合、他のマスタデバイス５２がパリティビットを書き込むであろう。
ＩＯ ＥＲＲＯＲフィールド（ｒｅｇ．０ｘ１２、Ｂ６）は、ＲＥＡＤ／ＷＲＩＴＥ／ＦＵＮＣＴＩＯＮ動作中のエラー、またはＰＩＮＧ動作中のパリティエラー（すなわち、データ中のエラー）を示すために使用され得る。ＩＯ ＥＲＲＯＲフィールドは、スレーブデバイス５４がＲＥＡＤ、ＷＲＩＴＥ、またはＦＵＮＣＴＩＯＮコマンドを確認しない場合に設定されるであろう。例えば、ＲＥＡＤまたはＷＲＩＴＥ、あるいはいくつかのＦＵＮＣＴＩＯＮコマンドに続く確認ビットＳ１４が、アドレス指定されたスレーブデバイスによってアクティブにされない場合には、ＩＯ ＥＲＲＯＲフィールドが設定され、確認ビットＳ１４がＰＩＮＧまたはいくつかのＦＵＮＣＴＩＯＮコマンドの完了に続いてアクティブにされる場合にも、ＩＯ ＥＲＲＯＲフィールドが設定されるであろう。ＩＯ ＥＲＲＯＲフィールドは、状態レジスタ０ｘ１２を読み取るとリセットされる。このスキームは、単一のレジスタを読み取ることによって、バス６４上の全てのバストラフィックがエラーについてチェックされることを可能にする。
ＳＴＡＴＵＳ１およびＳＴＡＴＵＳ０フィールド（ｒｅｇ．０ｘ１２、Ｂ５：Ｂ４）は、バス６４にアタッチされる任意のスレーブデバイスから読み取られる最高状態レベルを記憶するために使用され得る。任意のスレーブデバイスが、ＳＴＡＴＵＳ１およびＳＴＡＴＵＳ０フィールドによって示されるよりも高い状態レベルを有する場合、これらのフィールドは、次のＰＩＮＧ動作中に、この新しい値に更新されるであろう。ＩＮＴＥＲＦＡＣＥ ＳＴＡＴＵＳレジスタの読み取りは、ＳＴＡＴＵＳ１およびＳＴＡＴＵＳ０フィールドを消去しないであろう。これらのフィールドは、全ＰＩＮＧ動作および電源投入リセットイベント中に更新され、したがって、有効である。実施例として、スレーブ状態値は、リセット後に「００」であり、スレーブデバイスがバス６４にアタッチされた後は「０１」である。次いで、スレーブデバイスが緊急の注意を必要とし、ＰＩＮＧ動作中にスレーブ状態として「１１」を信号伝達すると仮定すると、次いで、ＳＴＡＴＵＳ１およびＳＴＡＴＵＳ０フィールドは、この値に更新される。スレーブ状態レジスタを読み取った後、値は依然として「１１」である。次のフレーム中に、最高スレーブ状態レベルが「１０」であると仮定されたい。このＰＩＮＧ動作の終了時に、ＳＴＡＴＵＳ１およびＳＴＡＴＵＳ０フィールドは、この新しい値（「１０」）に更新されるであろう。これは、スレーブデバイスがこのような場合を示すときに、エラーが最初に消去されるように行われる。対応するＩＮＴＥＲＲＵＰＴ ＭＡＳＫビットが有効にされ、注意を要求するスレーブデバイスの結果として割り込みが生成された場合、ＩＮＴＥＲＦＡＣＥ ＳＴＡＴＵＳレジスタを読み取ると、マスタデバイス５２からコントローラへのＩＲＱラインが消去されるであろう。スレーブデバイスが依然として注意を要求し、割り込みマスクビットが設定される場合、新しい割り込みが、次のＰＩＮＧ動作中に生成されるであろう。通常動作中に、このフィールドからの読み取りは、「０１」を返すであろう、すなわち、１つ以上のスレーブデバイスがバス６４にアタッチされ、特殊サービスの要求はない。したがって、ＳＴＡＴＵＳ１およびＳＴＡＴＵＳ０フィールドは、任意のスレーブデバイスがバス６４にアタッチされているかどうかを決定するため、または低い優先度（例えば、「１０」の状態レベル）あるいは高い優先度（例えば、「１１」の状態レベル）を伴う注意を必要とするスレーブデバイスを区別するための両方に使用されることができる。いかなるスレーブデバイスもバス６４にアタッチされていない場合、ＳＴＡＴＵＳ１およびＳＴＡＴＵＳ０フィールドは、「００」に設定されるであろう。
ＡＴＴＡＣＨＭＥＮＴフィールド（ｒｅｇ．０ｘ１２、Ｂ３）は、最後のＰＩＮＧ動作以降に、スレーブデバイスが接続解除、またはバス６４に接続した場合を示すように、アクティブハイに設定され得る。ＡＴＴＡＣＨＭＥＮＴフィールドの値は、ＰＩＮＧ動作中にＸおよびＹワードで示されるスレーブデバイスの状態レベルを、スレーブデバイスの以前の状態レベルと比較することによって、見出されることができる。任意のスレーブデバイスの状態レベルが｛“０１”，”１０”，”１１”｝から“００”に変化した（すなわち、スレーブデバイスがバス６４から接続解除した）場合、ＡＴＴＡＣＨＭＥＮＴフィールドは、低に設定されるであろう。１つより多くのマスタデバイスがある場合、任意の二次マスタデバイスが、任意のスレーブデバイスのようにバス６４にアタッチされ、スレーブデバイスと同様にデバイスアドレスを用いて列挙されるであろう。状態が“００”から｛“０１”，”１０”，”１１”｝に変化した（すなわち、スレーブデバイスがバス６４にアタッチされた）場合、ＡＴＴＡＣＨＭＥＮＴフィールドはまた、高に設定されるであろう。ＡＴＴＡＣＨＭＥＮＴフィールドは、その瞬間に消去される、ＩＮＴＥＲＦＡＣＥ ＳＴＡＴＵＳレジスタが読み取られるまで、設定された後に高（「１」）のままとなるであろう。任意の他の場合において、ＡＴＴＡＣＨＭＥＮＴフィールドは、低のままとなるであろう。リセットイベント後のＡＴＴＡＣＨＭＥＮＴフィールドのデフォルト値は、「０」である。
ＷＲＣフィールド（ｒｅｇ．０ｘ１２、Ｂ２）は、ＷＲＩＴＥ動作の完了を示すために使用され得る。このビットは、ＷＲＩＴＥ動作のアクティブ化を表し、アクティブハイである。それは、ＦＲＡＭＥ ＣＯＮＴＲＯＬレジスタへの書き込み後にアクティブにされる。それは、Ｓ１４（確認）ビットが書き込まれた直後のＷＲＩＴＥ動作の終了まで高のままとなるであろう。ＩＯエラーが起こった場合（例えば、否定応答）、状態レジスタが読み取られた後まで、このビットはリセットされない。ＷＲＩＴＥ動作を行う試行は、次のフレーム中で開始するであろう。デバイス割り込みによって遅延させられない限り（すなわち、Ｓ０ビットおよびＳ０ ＤＥＬＡＹの両方がアクティブにされる）、ＷＲＩＴＥ動作が続行し、そうでなければ、次のフレームまで遅延させられ、再度試行されるであろう。ＷＲＩＴＥ動作が完了した後、このビットは、Ｓ１４における有効ＡＣＫの直後に設定されるであろう。スレーブデバイスがＷＲＩＴＥ動作を確認しない場合には、ＩＯ ＥＲＲＯＲフィールドが設定され、ＷＲＣフィールドがリセットされないであろう。この場合、それは最初に、このレジスタを読み取った後にリセットされるであろう。代替実施形態（すなわち、図３６ａ）では、このビットは、ＩＯ動作の完了を示すため、およびＩＯ動作（ＲＥＡＤ／ＷＲＩＴＥ／ＦＵＮＣＴＩＯＮ）が完了したときに割り込みを有効にするために使用され得る。ビットは、アクティブハイであり得る。
ＲＤＣフィールド（ｒｅｇ．０ｘ１２、Ｂ１）は、ＲＥＡＤ動作の完了を示すために使用され得る。このビットは、ＲＥＡＤ動作のアクティブ化を表し、アクティブハイである。それは、ＦＲＡＭＥ ＣＯＮＴＲＯＬレジスタへの書き込み後に高に設定される。それは、Ｓ１４（確認）ビットが書き込まれた直後のＲＥＡＤ動作の終了まで高のままとなるであろう。ＩＯエラーが起こった場合（例えば、否定応答）、状態レジスタが読み取られた後まで、このビットはリセットされない。デバイス割り込みによって遅延させられない限り（すなわち、Ｓ０ビットおよびＳ０ ＤＥＬＡＹの両方がアクティブにされる）、ＲＥＡＤ動作が続行し、そうでなければ、次のフレームまで遅延させられ、再度試行されるであろう。ＲＥＡＤ動作が完了した後、このビットは、Ｓ１４における有効ＡＣＫの直後に再度リセットされるであろう。スレーブデバイスがＲＥＡＤ動作を確認しない場合、ＥＲＲＯＲ ＩＯフィールドが設定され、ＷＲＣフィールドは、低にならないであろう。この場合、それは最初に、このレジスタを読み取った後にリセットされるであろう。代替実施形態では、このビットは、主要マスタデバイス以外のデバイスによって行われる、ＸおよびＹワード内の任意のビット（例えば、ＣＯＭＭＡＮＤ ＥＲＲＯＲ）の変化を示すために使用され得る。このビットは、アクティブハイである。いくつかの実施形態では、コマンドワード（Ｓ、Ｘ、Ｙ）内の任意のビットが、マスタデバイス５２によって許可されるものと適合性がない値に変更された場合に、フィールドＣＯＭＭＡＮＤ ＥＲＲＯＲはアクティブになるであろう。実施例として、Ｓワード内のビットまたはＸワード中のコマンドタイプ（Ｂ１５：Ｂ１３）が変更される場合、これは、電気雑音、またはバス６４を引き継ごうとする別のデバイスの指示である。しかしながら、別のデバイスが（ＲＥＱＵＥＳＴ ＢＵＳコマンドを介して）バス６４を制御できるように要求を行い、マスタデバイスが（ＲＥＬＥＡＳＥ ＢＵＳコマンドを介して）これを許可した場合には、Ｘワードの変更が許可されるべきであり、ＣＯＭＭＡＮＤ ＥＲＲＯＲのアクティブ化をもたらすべきではない。
ＦＲＡＭＥ ＤＯＮＥフィールド（ｒｅｇ．０ｘ１２、Ｂ０）は、フレームが完了したことを示すために使用され得る。ＦＲＡＭＥ ＤＯＮＥフィールドは、フレームの最後のビットにおいてアクティブハイに設定される。したがって、ＦＲＡＭＥ ＤＯＮＥフィールドは、動作をバス６４の基本タイミングと同期化するために使用され得る。実施形態では、ＦＲＡＭＥ ＤＯＮＥフィールドは、デバイスが変更され、いかなるデータ通信もアクティブではなく、フレームカウンタが通常は内部で作動しているときに、依然として有効である。ＦＲＡＭＥ ＤＯＮＥフィールドは、状態レジスタが読み取られるまで設定され続けるであろう。ＦＲＡＭＥ ＤＯＮＥフィールドは、ＰＩＮＧ動作が完了したかどうかを伝えるために、または、全てのデバイスが充電されていることを確実にするように、通信を開始する前に、例えば、ある数のフレームを数えるための基本タイミングのために使用されることができる。対応するＩＲＱ ＭＡＳＫビットが有効にされるとき、割り込みが全フレームの終了時に生成されるであろう。
ＳＬＡＶＥ ＳＴＡＴＵＳレジスタ（ｒｅｇｓ．０ｘ１３から０ｘ１５）は、マスタデバイス５２の内側に存在するレジスタを使用して実装され得、スレーブアドレス０−１１を伴ってバス６４にアタッチされるスレーブデバイスの状態を示すであろう。これらのレジスタは、各々２ビットであり、合計３バイトに対するスレーブデバイス０−１１の状態に対応する１２個の値を含む。いくつかの実施形態では、スレーブデバイス１２−１４（デバイス１５はブロードキャストのために保留される）を直接監視することは可能ではないが、それらは、Ｓ０ビットをアクティブにすることを通して、依然として割り込みを発行することができる。いくつかの代替実施形態では、アドレス１２−１４は、以下でさらに詳細に説明されるように、デバイス群をアドレス指定するために使用される。いずれにしても、状態値がＰＩＮＧ動作中に読み取られる。任意のスレーブデバイスから読み取られる最高状態値は、対応する２ビット符号なし状態ビットと比較される。このスレーブ状態値が、これらのビット中の値より大きい場合、これらのビットは、この新しい値に更新される。ＳＬＡＶＥ ＳＴＡＴＵＳレジスタが読み取られるとき、その値は消去されないが、次のＰＩＮＧ動作中に上書きされるであろう、すなわち、「１１」の最大値が、１つのスレーブデバイスからのＳＬＡＶＥ ＳＴＡＴＵＳレジスタから読み取られ、次のＰＩＮＧ動作中の最大値が「１０」である場合、このデバイスに対するＳＬＡＶＥ ＳＴＡＴＵＳレジスタ値は、次のＰＩＮＧ動作の完了時に「１０」に更新されるであろう。３つ全てのＳＬＡＶＥ ＳＴＡＴＵＳレジスタの初期値は、リセット動作後に「００００００００」である。いかなるスレーブデバイスもバス６４上に存在しない場合、何もアクティブにされず、負の論理信号伝達スキームが、バス６４のこの例示的実施形態に使用されるため、論理ゼロに等しい、一定の高レベルが、バス６４上で読み取られるであろう。
図２９ｂの代替的な例示的実施形態に関して、図２９ａについて示され、説明されるものと比較して、異なるレジスタ定義がある。具体的には、図２９ｂの定義は、ＦＲＡＭＥ ＲＡＴＥフィールド、ＯＶＥＲＳＡＭＰＬＥ（Ｘ）フィールド、ＯＶＥＲＳＡＭＰＬＥ（Ｙ）フィールド、ＭＵＬＴＩ ＭＡＳＴＥＲフィールド、ＰＯＷＥＲ ＣＯＮＴＲＯＬフィールド、およびＣＬＯＣＫ ＤＩＶフィールドを含む。他のフィールドは、図２９ａに示されるものに類似するが、異なるレジスタに位置し、および／またはフィールドに割り当てられた異なるビット数を有し得、概して、図２９ｂに関して議論されない。ＯＶＥＲＳＡＭＰＬＥ（Ｘ）ＯＶＥＲＳＡＭＰＬＥ（Ｙ）フィールドは、図２９ａのＦＲＡＣＴＩＯＮＡＬ（ＬＯＷ）およびＦＲＡＣＴＩＯＮＡＬ（ＨＩＧＨ）フィールドに対応し、議論されない。図２９ｂのＭＵＬＴＩ ＭＡＳＴＥＲフィールドは、後に議論されるように、図２９ａのＥＮＡＢＬＥ ＭＵＬＴＩ ＭＡＳＴＥＲフィールドと比較して異なる意味を有する。ＣＬＯＣＫ ＤＩＶフィールドは、図２９ａのＭＣＬＫＤフィールドに類似し、議論されない。
ＦＲＡＭＥ ＲＡＴＥフィールド（ｒｅｇ．０ｘ００９、Ｂ７：Ｂ０）は、バス６４のシステム周波数を定義するために使用され得る。値は、実施形態では符号なし２進数としてコードされる、２００ｋＨｚの単位で定義することができる。１２．２ＭＨｚおよび１１．２ＭＨｚに対して符号化される値は、１２．２８８および１１．２８９６ＭＨｚとして扱われ得る（その倍数も同様）。
図２９ｂのＦＲＡＭＥ ＣＯＮＴＲＯＬフィールドの例示的実施形態に基づく、ＷＲＩＴＥおよびＲＥＡＤ動作の組み合わせが、図３０に示されている。少なくとも１つの実施形態では、図２９ｂに関して、ＦＲＡＭＥ ＣＯＮＴＲＯＬフィールド中の第１のビット（Ｂ７）は、保留中ＷＲＩＴＥ動作の状態を提供し、アクティブハイである。レジスタＷＲＩＴＥ動作は、コントローラが、マスタデバイス５２のデータレジスタ（ＷＤ１５：ＷＤ０またはＷＤ７：ＷＤ０）に、次いで、マスタデバイス５２のアドレスレジスタ（ＡＤＤＲ６−０、および随意に８ビットＷＲＩＴＥ動作についてはＲＥＧ７−０）に書き込むことによって、開始し得る。次いで、コントローラは、ＩＯ ＣＯＮＴＲＯＬ ＲＥＧＩＳＴＥＲ（ＩＯＣ）に書き込み、Ｂ７：Ｂ６＝”１０”を設定することによって、実際のＷＲＩＴＥ動作を開始し得る。次いで、ＷＲＩＴＥレジスタ動作を行うことの試行が、次のフレーム中で開始し得る。デバイス割り込みによって遅延させられない限り、ＷＲＩＴＥ動作は続行し、そうでなければ、次のフレームまで遅延させられ、再度試行されるであろう。ＷＲＩＴＥ動作が完了した後、ＦＲＡＭＥ ＣＯＮＴＲＯＬフィールドは、エラー状態中を除いて、Ｙワードの最後のビットが書き込まれた後に、即時に「００」に再度リセットされるであろう。ＩＯ ＥＲＲＯＲがある場合、ＦＲＡＭＥ ＣＯＮＴＲＯＬフィールドの第１のビットは、ＩＯ ＥＲＲＯＲビットが読み取られて消去されるまで、高のままとなり続けるであろう。これは、マスタデバイス５２がＩＯ ＥＲＲＯＲのソースを見出すことを可能にする。ＷＲＩＴＥ ＣＯＮＴＲＯＬビット（ｒｅｇ．０ｘ００Ｆ、Ｂ７、すなわち、ＦＲＡＭＥ ＣＯＮＴＲＯＬフィールドの第１のビット）が高のとき、新しいＲＥＡＤまたはＷＲＩＴＥ動作は、ＷＲＩＴＥ ＣＯＮＴＲＯＬビットが低に戻るまで、開始されるべきではない。
実施形態では、同一の動作においてＷＲＩＴＥ ＣＯＮＴＲＯＬおよびＲＥＡＤ ＣＯＮＴＲＯＬビットの両方をアクティブにすることは違法である。この条件は、マスタデバイス５２によって無視され、この場合、ビットＢ７：Ｂ６の以前の状態が維持されることができる。この場合、マスタデバイス５２は、ＰＩＮＧ動作（すなわち、変化なし）であるようにこの条件を符号化することができる。
少なくとも１つの実施形態では、図２９ｂのＦＲＡＭＥ ＣＯＮＴＲＯＬフィールドのＲＥＡＤ ＣＯＮＴＲＯＬビット（ｒｅｇ．０ｘ００Ｆ、Ｂ６）は、動作を開始するため、およびこれらの動作の進行を監視するために使用され得、その実施例は、図３１に示されている。ＲＥＡＤ ＣＯＮＴＲＯＬビットからの読み取りは、任意の保留中動作の状態を与えるであろう。ＤＡＴＡおよびＡＤＤＲＥＳＳレジスタが、ＲＥＡＤおよびＷＲＩＴＥ動作に使用されるであろう。動作が完了した後、このＲＥＡＤ ＣＯＮＴＲＯＬビットが、再度リセットされるであろう。ＩＯ ＥＲＲＯＲがある場合、ＲＥＡＤ ＣＯＮＴＲＯＬビットは、ＩＯ ＥＲＲＯＲビットが読み取られて消去されるまで、高のままであり続けるであろう。これは、マスタデバイス５２がＩＯ ＥＲＲＯＲのソースを見出すことを可能にする。他の実施形態では、動作のタイプ（すなわち、ＰＩＮＧ／ＦＵＮＣＴＩＯＮ／ＷＲＩＴＥ８ビット／ＲＥＡＤ８ビット／ＷＲＩＴＥ１６ビット／ＲＥＡＤ１６ビット）が、レジスタ０ｘ００ＦのビットＢ７−Ｂ５によって決定され得る。
動作が進行中であるとき、新しい動作は開始されない。ＦＲＡＭＥ ＣＯＮＴＲＯＬフィールド＝‘１１’であるとき、ＦＵＮＣＴＩＯＮ動作が開始される。ＦＵＮＣＴＩＯＮ ＤＡＴＡフィールドを利用する関数は、（ＦＲＡＭＥ ＣＯＮＴＲＯＬフィールドからの読み取りに関して）ＲＥＡＤ／ＷＲＩＴＥ動作のように扱われるであろう。行われるＦＵＮＣＴＩＯＮ動作のタイプは、ＦＵＮＣＴＩＯＮレジスタ（０ｘ１５）によって決定されるであろう。
ＤＡＴＡ ＳＩＺＥ（ｒｅｇ．０ｘ００Ｆ、Ｂ５）フィールドは、ＲＥＡＤおよびＷＲＩＴＥ動作に対するデータ幅を選択するために使用され得る。ＤＡＴＡ ＳＩＺＥフィールド中の論理０は、８ビットデータをもたらし、ＤＡＴＡ ＳＩＺＥフィールド中の論理１は、１６ビットデータ動作をもたらす。電源投入リセットイベント後のデフォルト値は、「０」、すなわち、８ビット動作である。
図２９ｂのＥＮＡＢＬＥ ＭＵＬＴＩフィールド（ｒｅｇ．０ｘ１５、Ｂ７）は、マルチフレーム同期化（すなわち、複数のフレームにわたって伝送されるデータを同期化する）のためのＤＳ０ビットの使用を有効にするために使用され得る。ＥＮＡＢＬＥ ＭＵＬＴＩフィールドが１に設定されるとき、マルチフレーム同期化が有効にされ、ＣＬＯＣＫ ＤＩＶＩＤＥＲフィールドは、ＤＳ０ビットが１（通常は０）に設定され得る、フレーム数中で距離を選択するために使用され得る。これは、スレーブデバイス５４によって、いくつかのデータ動作モードで、より効率的なデータ転送に使用されることができる。ＥＮＡＢＬＥ ＭＵＬＴＩフィールドが１に設定されるとき、ＣＬＯＣＫ ＤＩＶＩＤＥＲフィールドは更新されないであろう。ＥＮＡＢＬＥ ＭＵＬＴＩフィールドを０から１に変更した後、後に続く第１のフレームは、１に設定されたＤＳ０ビットを有するであろう。ＤＳ０ビットのアクティブ化は、ＳＥＴ ＯＶＥＲＳＡＭＰＬＥ ＲＡＴＩＯ関数を使用して、オーバーサンプル率をデータレジスタに書き込むことによって行われる。実施例として、レジスタ０ｘ００００が０ｘ０２に設定され、レジスタ０ｘ０００１が０ｘ０１に設定される（これらのレジスタについては図１６ｂを参照）場合には、ＤＳ０ビットは、１つおきのフレーム中で１に等しく設定されるであろう。
図２９ｂのＰＯＷＥＲ ＣＯＮＴＲＯＬフィールド（ｒｅｇ．０ｘ１５、Ｂ５）は、単一ワイヤ実施形態に対するバス６４の動作を制御するために使用され得る。ＰＯＷＥＲ ＣＯＮＴＲＯＬフィールドが０に設定される場合には、データがバス６４上で伝送されるときに、スレーブデバイスの充電がない。ＰＯＷＥＲ ＣＯＮＴＲＯＬフィールドが１に設定される場合には、バス上にデータ転送がないときに、スレーブデバイスの充電がある。ＰＯＷＥＲ ＣＯＮＴＲＯＬフィールドは、この情報がＩ２Ｃコマンドから受信される時間にかかわらず、フレームの最後のビットにおいて内部で更新されることができる。
図９ａ、１６ａ、２２ａ、２２ｂ、２５ａ、２５ｂ、２９ａ、２９ｃ−２９ｉ、３２ａ、３３ａ、３４ａ、および３６ａに示される例示的実施形態は、第１の代替的な例示的実施形態で一緒に使用されることができる一方で、図９ｂ、１６ｂ、１７、２２ｃ、２５ｃ、２９ｂ、３０、３１、３２ｂ、３３ｂ、３４ｂ、および３６ｂに示される例示的実施形態は、第２の代替的な例示的実施形態で一緒に使用されることができることに留意されたい。この段落で記述されない、他の図に示される例示的実施形態は、第１および第２の代替的な例示的実施形態の両方とともに使用されることができる。
少なくとも１つの実施形態では、最大で１２個のスレーブデバイス（０−１１）が、状態データで応答し得る。マスタデバイス１２によるＳＬＡＶＥ ＳＴＡＴＵＳレジスタへの任意の書き込みは、無視される（アクションなし）。ＳＬＡＶＥ ＳＴＡＴＵＳレジスタの例示的定義が、図３７に示されているが、他の定義および別の数のスレーブデバイスを他の実施形態で使用されることができる。
少なくとも１つの実施形態では、部品ＩＤ中の製造業者符号化シーケンスは、バス６４に最初にアタッチするスレーブデバイスへのアドレスの動的アドレス割付で使用される。これは、ここで説明されるように、圧縮符号化形式、または一般符号化形式を使用することによって為されることができる。
例示的実施形態では、圧縮符号化形式は、部品ＩＤを、スレーブデバイス５４のデバイスＩＤとして使用されることができる３２ビットに符号化する。形式は、図３８ａに示されるように、位置符号化、製造業者名、および部品番号を含む。この例示的実施形態では、位置符号化は、最大で１５の値（１−１５）を許容し、製造業者名は、２文字として符号化され、部品番号は、２進数で符号化され、１０進５桁を許容する（位置符号化は本説明において以降で説明される）。製造業者名で使用される文字は、各文字にＡＳＣＩＩ文字コードの５つの最下位ビット、すなわち、Ａ＝”０００００１”、Ｂ＝”００００１０”等を使用する。製造業者名に対する２文字は、固有の２文字の頭字語をもたらすように選択される。マスタデバイス５２は、圧縮符号化形式を使用するときに、４バイトの情報を読み取ることができる。１６ビットＲＥＡＤ動作がマスタデバイス５２によって使用される場合、２バイトが全ＲＥＡＤ動作中に返されるであろう。最上位バイトが、第１のバイトを表す一方で、最下位バイトは、第２のバイトを表す。
圧縮符号化形式の実施例が以下に続く。製造業者ＸＭＣＯがＸＭ００７０００と名付けられた部品をコードしたいと仮定する。最初の２つの文字は、製造業者コード「ＸＭ」であり、部品番号は、「０７０００」であり、位置情報はない。圧縮符号化は、Ｂ３１＝’０’を使用する。位置情報がないため、これは、Ｂ３０：Ｂ２７＝“００００”をもたらす。文字「Ｘ」は、８８のＡＳＣＩＩコードを有し、文字「Ｍ」は、７７のＡＳＣＩＩコードを有する。ＡＳＣＩＩコードは、元の値から６４を差し引くことによって、８ビットから５ビットまで圧縮することができる。したがって、ビットＢ２６：Ｂ１７は、｛‘Ｘ’−６４，‘Ｍ’−６４｝＝｛２４，１３｝＝｛“１１０００”，”０１１０１”｝に等しい。代替として、値は、５ビットを得るように０ｘ１Ｆで論理的にＡＮＤ演算される、ＡＳＣＩＩコードから見出されることができる。次いで、部品番号は、２進数に変換され、すなわち、“０７０００”＝“０ｘ１Ｂ５８”＝０．０００１．１０１１．０１０１．１０００である。したがって、圧縮符号化形式での３２ビットＩＤは、｛Ｂ３１，Ｂ３０：Ｂ２７，Ｂ２６：Ｂ１７，Ｂ１６：Ｂ０｝＝“００００．０１１０．０００１．１０１０．０００１．１０１１．０１０１．１０００”｝＝０ｘ０６１Ａ．１Ｂ５８である。
例示的実施形態では、一般符号化形式は、スレーブデバイス５４のデバイスＩＤを符号化するように、一連のＡＳＣＩＩ文字として部品番号を定義し、その実施例は、図３８ｂに示されている。部品番号は、ＮＵＬＬ文字（すなわち、ゼロに等しいバイト）によって終端されるＡＳＣＩＩ文字として表すことができる、任意の名称を有し得る。第１のバイトは、形式（すなわち、短い符号化または一般符号化）、部品等級、および随意的な位置情報を符号化するために使用される。第２のバイトは、バスのバージョンおよびチップのバージョンを示すために使用される。第２のバイトに続く文字は、ＡＳＣＩＩ値を使用した部品名として解釈される。部品等級は、異なる量のタイプの特定の部品を区別するために使用されることができる。バスバージョンは、バージョン１．００と同等のバージョン「０００１」で始まり得る。チップバージョンは、バージョン「００００」で始まり、後続のバージョンに対して増分し得る。チップバージョン番号の増分は、単一ステップである必要はない。例えば、第１のバージョンは、「００００」であり得、「００００」、「００００１」、「００１０」等を数える代わりに、その後に、「０００１」、「００１１」、「０１１１」という以降のバージョンが続き、最終的に、最後のバージョンに「１１１１」が使用される。このスキームは、実用的な理由で（メタルマスク変更にとってより容易である）使用されることができるが、より大きい数は、概して、より新しいバージョンに対応する。１６ビットＲＥＡＤ動作がマスタデバイス５２によって使用される場合には、２バイトが全ＲＥＡＤ動作中に返されるであろう。８つの最上位ビットは、第１のバイトを表し、８つの最下位ビットは、第２のバイトを表す。文字列が奇数のバイトを有するとき、それは、１６ビットデータ読み取りに適合しないであろう。したがって、単一のバイトが文字列を終端すると予期され、ワードが読み取られる場合、最上位バイトが使用され、例えば、シーケンスがワード境界の中央で終端されるとき、最上位バイトはゼロである。シーケンスが早期に終端されないことを確実にするために、このモードでは、ＩＤ中にゼロに等しいバイトがない。また、部品を符号化するときに、実際の製造業者以外の製造業者名は使用されない。
一般符号化形式の実施例が以下に続く。製造業者ＡＤＩが、部品名「ＡＤＩ−ＳＳＭ２３７７ＡＣＢＺ−ＲＬ」を伴うチップを符号化したい。チップは、位置情報を有さず、「Ａ」という部品等級を有する。バスバージョンは、第１の公式バージョン１．００＝“０００１”である。チップのバージョンは、第１のバージョン＝“００００”である。一般符号化は、ＡＳＣＩＩで符号化される部品番号が後に続く、１６ビット圧縮情報フィールドによって行われる。符号化は、以下のように行われ、すなわち、Ｂ７＝‘１’（一般符号化）、Ｂ６：Ｂ３＝“００００”（位置情報なし）、Ｂ２：Ｂ０＝“０００”（部品等級Ａ）であり、すなわち、読み取られる第１のバイトは０ｘ８０である。第２のバイトは、チップバージョンが後に続くバスバージョンであり、すなわち、“０００１”および“００００”＝０ｘ１０である。アドレスゼロからの複数の読み取りを使用して読み取られる、完全部品名は（実際の文字が示され、返された値はこれらのＡＳＣＩＩ符号化である）、｛‘Ａ’，’Ｄ’，‘Ｉ’，‘−‘，’Ｓ’，’Ｓ’，’Ｍ’，’２’，’３’，’７’，’７’，’Ａ’，’Ｃ’，’Ｂ’，’Ｚ’，’−‘，’Ｒ’，’Ｌ’｝である。読み取られる最後のバイトは、ＮＵＬＬ：Ｂ７：Ｂ０＝“００００００００”である。このデバイスが最高アービトレーション優先度を有すると仮定して、アドレス０から読み取り、デバイス０は、以下の値のシーケンス、すなわち、｛０ｘ８０，０ｘ１０，０ｘ４１，０ｘ４４，０ｘ４９，０ｘ２Ｄ，０ｘ５３，０ｘ５３，０ｘ４Ｄ，０ｘ３２，０ｘ３３，０ｘ３７，０ｘ３７，０ｘ４１，０ｘ４３，０ｘ４２，０ｘ５Ａ，０ｘ２Ｄ，０ｘ５２，０ｘ４Ｃ，０ｘ００｝をもたらすであろう。
時として、これらのデバイスが同一の部品情報を含み得るため、それらの位置的配置に基づいて、いくつかの同一の部品を区別する必要がある。この場合、固有のスレーブアドレスをこれらのデバイスに割り当てることができるように、それらを区別するために、追加のフィールドが使用される。位置フィールドが、この目的で使用される。実施形態では、位置フィールドは、１６の異なる値を有することができる。値「００００」は、位置情報が利用可能でない場合、または必要ではない場合のために保留される。残りの１５の値は、位置を示すために使用される。
デバイスの番号付けは、種々の方法で特定されることができる。例えば、ハンドヘルドユニット中に６つのマイクロホン（以下のように定義される）がある場合、主要マイクロホンには、位置１を割り当てることができ、左マイクロホンには、位置２を割り当てることができ、右マイクロホンには、位置３を割り当てることができ、後方の雑音マイクロホンには、位置４を割り当てることができ、第２の雑音マイクロホンには、位置５を割り当てることができ、ラウドスピーカの隣のマイクロホンには、位置６を割り当てることができる。
別の実施例として、ヘッドセットの内側で複数のマイクロホンを使用するとき、以下の番号付けスキームが使用され得る。左主要マイクロホンは、位置１を割り当てられ得、右マイクロホンは、位置２を割り当てられ得、左耳外部マイクロホンは、位置３を割り当てられ得、右耳外部マイクロホンは、位置４を割り当てられ得、左耳内部マイクロホンは、位置５を割り当てられ得、右耳内部マイクロホンは、位置６を割り当てられ得、追加の左マイクロホンは、位置７を割り当てられ得る。
別の実施例として、ＤＯＬＢＹＴＭサラウンド音響マルチスピーカシステムについては、以下の番号付けスキームが使用され得る。左前スピーカは、位置１を割り当てられ得、右前スピーカは、位置２を割り当てられ得、中央スピーカは、位置３を割り当てられ得、左後スピーカは、位置４を割り当てられ得、右後スピーカは、位置５を割り当てられ得、サブウーファスピーカは、位置６を割り当てられ得、左脇スピーカは、位置７を割り当てられ得、右脇スピーカは、位置８を割り当てられ得る。
少なくとも１つの実施形態では、一般的な位置割当は、要素の場所に基づいて、複数の要素に行われることができる。例えば、最初に、要素を左から右に（左が最初である）ソートすることができ、次いで、要素を前から後に（前が最初である）ソートすることができ、次いで、要素を上から下に（上が最初である）ソートすることができ、次いで、要素を最大から最小（最大が最初である）にソートすることができる。
前述のように、統一バス通信プロトコルは、動作モードに基づいて、異なるフレーム形式を有する。動作のワードモードでは、ワードフレーム形式が使用される。動作のビットストリームモードでは、ビットストリームフレーム形式または統一フレーム形式が使用される。ワード、ビットストリーム、および統一フレーム形式の実施例が続く。
ここで図３９を参照すると、単一の時間フレームに対して、ワードモードで使用される一般的なワードフレームが示されている。マスタデバイス５２とスレーブデバイス５４との間の通信は、Ｓワードで始まり、その後にＸワード、次いで、Ｙワードが続く、フレーム中に起こる。Ｓワードとコマンドワードとの間には、使用シナリオに応じて、データ伝送に割り付けられた空の空間があり得る。空の空間の長さは、ＣＯＭＭＡＮＤ ＳＥＰＡＲＡＴＩＯＮレジスタによって定義される。
マスタデバイス５２によるＳワードの伝送は、バス６４に物理的に接続されるスレーブデバイスが、マスタデバイス５２と通信するためにロックされる（すなわち、同期化される）ことを可能にする（同期化する方法は、本説明において以降でさらに詳細に説明される）。Ｓワードの伝送はまた、注意を必要とする任意の割り込みが設定されているかどうかをマスタデバイス５２が決定することも可能にする。
Ｓワードの伝送とＸワードの伝送との間に、スレーブデバイス５４またはマスタデバイス５２のうちの少なくとも１つによってピックアップされることができる、ランダムデータまたは情報が、バス６４を経由して伝送され得る。この情報は、ビットストリーム、オーディオデータ、または例えば、センサデータ等の他の数値データを含むが、それらに限定されない。Ｘワードの伝送は、マスタデバイス５２およびスレーブデバイス５４が、任意の特定の機能が実行されるべき場合を決定すること、またはスレーブデバイスのうちのいくつかの状態を決定すること、または動作のためのアドレスの一部分を特定することを可能にする。（いかなる割り込みも設定されなかったと仮定して）Ｘワードの伝送後に、前述のように、さらなるデータが、バス６４を経由して伝送され得る。次いで、動作に応じて、スレーブデバイスのうちの少なくともいくつかに対する動作または状態情報のために、さらなるアドレス情報またはデータ情報を提供する、Ｙワードが伝送される。
ここで図４０を参照すると、単一の時間フレームに対して、ワードフレーム形式の例示的実施形態が示されている。本実施例では、制御ワードが次々に続き、フレーム長が３＊（４＊コマンド分離値＋１６）＝３＊（４＊０＋１６）＝４８ビットであるため、コマンド分離は、最小分離値である、０ビットである。図４０の表の最上行および第１の列によって定義されるビット番号は、どのタイムスロット中で、ビットがバス６４上で伝送されるかを示し、例えば、タイムスロット０ｘ０２Ｅは、ビットＹ１を含む。このフレーム形式は、制御データのみが転送されるか、または制御データに対する非常に高い帯域幅が短い時間量にわたって使用される、状況に有用である。ＣＵＲＲＥＮＴ ＢＡＮＫレジスタビットは、必要であれば、このデータモードへ、およびそこから変化するために使用されることができる。
ここで図４１を参照すると、ワードモードで単一の時間フレームに使用されるワードフレーム形式の別の例示的実施形態が示されている。本実施例では、コマンド分離は、４＊２８＝１１２ビットであり、フレーム長は、３＊（４＊２８＋１６）＝３＊（１２８）＝３８４ビットである。本実施例は、５つのオーディオデータチャネル（Ａ、Ｂ、Ｃ、Ｄ、およびＥ）、および１６ビットを有する各チャネルを伴う２つの未使用データチャネルを示す。本実施例は、６．１４４ＭＨｚバスクロックおよび４８ｋＨｚサンプル周波数と良好に適合する。値が「Ｚ」（すなわち、３状態）である場合、マスタデバイス５２は、「０−１−Ｚ−Ｚ」パターンを駆動するであろう。値が「０」である場合、マスタデバイス５２は、「０−１−０−０」パターンを駆動するであろう。値が「１」である場合、マスタデバイス５２は、「０−１−Ｚ−Ｚ」パターンを駆動するであろう。値がスレーブデバイス５４によって決定される場合、マスタデバイス５２が、「０−１−Ｚ−Ｚ」パターンを駆動するであろう一方で、スレーブデバイス５４は、スレーブデバイス５４が伝送しているビットの値に応じて、単一ワイヤ事例に対して「Ｚ−Ｚ−Ｕ−０」パターンまたは「Ｚ−Ｚ−Ｚ−Ｚ」パターンのいずれかを駆動するであろう。示されたデータ形式は、１２．２８８ＭＨｚ導出バスクロックと良好に適合し、５つのアクティブなオーディオソースが示さされている。しかしながら、このデータ形式が最大で７つのアクティブなソースを同時に可能にするため、フレーム中に２つの未使用チャネルまたは空のチャネルがある。
ここで図４２を参照すると、ビットストリームモードでの単一のフレームのためのビットストリームフレーム形式の例示的実施形態が示されている。本実施例では、ビットストリームフレーム形式は、４つのビットストリームフレームチャネル、すなわち、制御チャネル（フレームチャネル０）および３つのビットストリームデータチャネル（フレームチャネル１から３）を備える。ビットストリームフレームチャネルのセットは、各行のビット０、４、８、およびＣから開始し、各ビットストリームフレームチャネルに対して１度に１ビット送信される。制御チャネルは、Ｓワードからのビット、その後にＸワードからのビット、その後にＹワードからのビットを送信するために使用され。ビットストリームデータフレームチャネルは、異なるビットストリームデータチャネルからビットを送信するために使用される。本実施例では、１ビットが制御フレームチャネルから送信され、その後にビットストリームデータフレームチャネル１からの１ビットが続き、その後にビットストリームデータフレームチャネル２からの１ビットが続き、その後にビットストリームデータフレームチャネル３からの１ビットが続く。したがって、コマンド分離値は、３ビットに等しい（すなわち、第４ビットごとに、伝送されるＳワード、Ｘワード、またはＹワードのいずれかからのコマンドビットがある）。フレーム長は、４＊４８＝１９２ビットである。
図４２に示されるフレームのフレーム構造は、実際には、４８行および３列である。しかしながら、フレームは、ビットがバス６４上で伝送されるタイムスロットに対応する、ビット番号に従って示される。このフレームに対するタイムスロットは、最上行の左隅から開始し、最上行の端まで、次いで、次の行の左側からその行の端まで等、継続することを理解されたい。
データが図４２に示されるフレーム形式で構造化される、典型的なシナリオは、デジタル入力およびデジタルマイクロホンを伴う２つのクラスＤ増幅器があり、増幅器およびマイクロホンが各々、ビットストリームデータを生成するときである。別のシナリオは、ビットストリームデータを生成する、３つのデジタルマイクロホンである。この場合、３つのデジタルマイクロホンは、３．０７２ＭＨｚでサンプリングされることができ、バスクロック周波数は、例えば、６．１４４ＭＨｚであり得る。したがって、このフレーム形式は、伝送機および受信機の両方に対する複数のビットストリームデータチャネルにインターレースするために好適である。バス６４を経由して伝送されるビットストリームデータチャネルの各々の間に１ビットの待ち時間のみがあるため、このビットストリームフレーム形式は、処理においてわずかな遅延を可能にする。また、任意の値によるデシメーションが、システムによって以降で使用されることができるため、ビットストリームを生成するために使用されるシグマデルタ変換器のオーバーサンプリング率は、このスキームを使用する特定の値に制限されない。実践では、１２．２８８、１９．２０、および２６．００ＭＨｚクロックシステムをサポートするために、有限数のオーバーサンプリング率が使用される。
ここで図４３を参照すると、ビットストリームモードで使用することができる、単一の時間フレームに対する統一フレーム形式の例示的実施形態が示されている。本実施例では、統一フレーム形式は、制御チャネル（フレームチャネル０）、５つのビットストリームデータチャネル（フレームチャネル１から５）、および２つの仮想フレームチャネル（フレームチャネル６および７）を備える。統一フレーム形式は、少なくとも１つの仮想フレームチャネルを使用する、フレーム形式である。仮想フレームチャネルは、デジタルワードデータから変換されている（すなわち、入力データの場合）、またはデジタルワードデータに変換されるであろう（すなわち、出力データの場合）、データを伝送するために使用される。デジタルワードデータは、対応する仮想フレームチャネルによって指定されるタイムスロットにおいてデジタルワードを１度に１ビット伝送することによって、ビットストリームに変換される。
本実施例では、フレームチャネルは、各行のビット０および８から開始し、各フレームチャネルから１度に１ビット送信される。したがって、コマンド分離値は、７ビットに等しい（すなわち、８ビットごとにＳワード、Ｘワード、またはＹワードからのコマンドビットがある）。フレーム長は、８＊４８＝３８４ビットである。このフレームのフレーム構造は、実際には、２４行および８列である。しかしながら、フレームは、以前に説明されたように、ビット数に従って示される。
データが図４３に示される形式で構造化される、典型的なシナリオは、ビットストリームデータを生成する、５つのデジタルマイクロホンと、ビットストリームデータを受信するか、または仮想フレームチャネルによって提供されるビットストリームデータからデジタルワードデータを再構築することができるかのいずれかである、２つのスピーカとがあるときである。本実施例では、５つのデジタルマイクロホンチャネル（フレームチャネルＭ０からＭ４）は、７６８ｋＨｚ（４８のデシメーション率を伴う１６ｋＨｚサンプリング周波数と同等である）であり得、２つの仮想フレームチャネル（フレームチャネルＡおよびＢ）は各々、１６ビットバイナリワードを伴って４８ｋＨｚであり得る、２つのオーディオチャネルである。バスクロック周波数は、６．１４４ＭＨｚであり得る。
ここで図４４を参照すると、ビットストリームモードで使用するための単一の時間フレームに対する統一フレーム形式の別の例示的実施形態が示されている。本実施例では、統一フレーム形式は、制御チャネル（フレームチャネル０）と、５つのビットストリームデータチャネル（フレームチャネル１から５）と、２つの仮想フレームチャネル（フレームチャネル６および７）とを備える。しかしながら、本実施例では、各仮想フレームチャネルは、２つのワードデータチャネルに対するデータを有する。したがって、本実施例では、２つの仮想フレームチャネルは、４つのワードデータチャネルからのデータを搬送するために使用される。例えば、フレームチャネル６は、ワードデータチャネルＣおよびワードデータチャネルＡに対応する、ビットストリームデータを有する。フレームチャネル６は、ワードデータチャネルＣを使用するデバイスへのデータの受信または伝送、およびワードデータチャネルＡを使用するデバイスへのデータの受信または送信を行うために使用される。タイムスロットは、最初にワードデータチャネルＣのために、次いで、ワードデータチャネルＡのために使用される。加えて、フレームチャネル７は、タイムスロットが、最初にワードデータチャネルＤ、次いで、ワードデータチャネルＢに使用される、ワードデータチャネルＤおよびワードデータチャネルＢのために対応するビットストリームデータを有する。この場合、仮想フレームチャネル中のデータは、バス６４上で送信される際に、デジタルワードデータのビットストリームバージョンである。データ同期化ビット（ＤＳ０）は、データチャネルに対するデータが開始および停止する（例えば、ＡまたはＣ）ときについての曖昧性を回避するように、いくつかのフレームにわたってワードデータに対応するビットストリームデータを同期化するために使用され得る。空間を節約するために、ＤＳ０およびＤＳ１ビットは、ＰＩＮＧフレームの中央（すなわち、フレームが開始する直前ではなく）で転送される。これらのビットは、次いで、その後の全サブフレーム中の所与の段階によって増分される、既知の値（例えば、ゼロ）に分数カウンタをリセットするために使用される。次いで、オーバーフロービットは、それがソース（すなわち、データチャネル）ＡまたはソースＣからのデータであるかどうかを選択するために使用される。フレームは、Ｓワードの後の第１のビットから始まり、その時、対応する１つ以上のスレーブデバイスが、レジスタバンク選択およびデータ同期化について更新されている。ワードデータチャネルを使用する種々のデバイスにおいて、デジタルワードデータが、バス６４上での伝送のためにビットストリームデータと多重化されるか、または統一ビットストリームバージョンから、それがデバイスによって使用されるワードデータに逆多重化される。実施例として、システムは、ビットストリームデータを受信する２つのデジタル増幅器、およびＢｌｕｅｔｏｏｔｈ（登録商標）またはデジタルＦＭ受信機あるいは伝送機への接続を含むことができる。第１のスレーブデバイス（すなわち、増幅器）が、ビットストリームデータまたは多重化ＴＤＭデータを使用するであろう一方で、他のデバイスは、多重化ＴＤＭデータを使用するであろう。
本実施例では、フレームチャネルは、各行のビット０および８から始まり、各フレームチャネルから１度に１ビット送信される。したがって、コマンド分離値は、７ビットに等しい（すなわち、８ビットごとにＳワード、Ｘワード、またはＹワードのいずれかからのコマンドビットがある）。フレーム長は、８＊４８＝３８４ビットである。このフレームのフレーム構造は、実際には、２４行および８列である。しかしながら、フレームは、前述のようにビット番号に従って示される。データが図４４に示される形式で構造化される、典型的なシナリオは、デジタルワードデータを生成または使用するデバイスのために、ビットストリームデータを生成する５つのデジタルマイクロホンと、４つの補助オーディオチャネルとがあるときである。例えば、５つのデジタルマイクロホンチャネル（フレームチャネルＭ０からＭ４）は、１．５３６ＭＨｚのデータレート（６４のデシメーション率を伴う２４ｋＨｚサンプリング周波数と同等である）を有することができ、４つのデジタルワードチャネル（Ａ、Ｂ、Ｃ、およびＤ）は各々、１６ビットのワード長を伴って４８ｋＨｚでサンプリングされる、単一のオーディオチャネルを表す。バスクロック周波数は、１２．２８８ＭＨｚであり得る。
ここで図４５ａから４８ｃを参照すると、統一バス通信プロトコルに対するバス周波数、チャネルの数およびタイプの有用な組み合わせの実施例が示されている。これらの図中の表は、バス６４に対する参照クロック信号として使用される、外部クロック周波数に従ってソートされている。奇数分割比を伴う構成を、２ワイヤバス実施形態で、または記載される周波数の２倍である外部クロッック信号とともに、使用することができる。利用可能な制御帯域幅は、高速モードＩ２Ｃバスとほぼ同一である。１６ビットデータを使用する４００ｋＨｚ Ｉ２Ｃバスは、毎秒１２．５ｋＨｚ動作に対応する。
ここで図４５ａおよび４５ｂを参照すると、ワードモードで動作するときの統一バス通信プロトコルの実施形態に対するバス周波数、チャネルの数およびタイプの例示的組み合わせの表が示されている。これらの表は、図４５ａの表の第６の行中の実施例を見ることによって理解することができる。この場合、サブフレーム長が５＊２４＊２＋１６＝２５６ビットであり、１６ビットの追加がサブフレーム中の制御ワードのためのものであるように、各々２４ビット長であり、２回繰り返される、５つのオーディオチャネルがある。反復は、２つのデジタルワードが、各サブフレーム中のチャネルの各々から得られることを意味する。反復は、データチャネルＡ、Ｂ、Ｃ、Ｄ、およびＥからのデータに対するＡ−Ａ−Ｂ−Ｂ−Ｃ−Ｃ−Ｄ−Ｄ−Ｅ−Ｅに従って行われることができるが、低遅延のためには、反復Ａ−Ｂ−Ｃ−Ｄ−Ｅ−Ａ−Ｂ−Ｃ−Ｄ−Ｅが使用され得る。サブフレーム中の制御データに使用される帯域幅は、サブフレームにおいて１６制御ビットがあるため、１６／２５６＝６．３％である。図４５ａの行３に示される実施例は、Ｓ／ＰＤＩＦ適合性に非常に適している。
図４５ａに関して、行１中の実施例は、ワードモードでサブフレーム中で３回繰り返される、１つのオーディオチャネルを有する。行２中の実施例は、ワードモードでサブフレーム中で１回繰り返される１つのオーディオチャネルを有する。行３中の実施例は、ワードモードでサブフレーム中で２回繰り返される、２つのオーディオチャネルを有する。行４中の実施例は、ワードモードでサブフレーム中で１回繰り返される、３つのオーディオチャネルを有する。行５中の実施例は、ワードモードでサブフレーム中で４回繰り返される、３つのオーディオチャネルを有する。行６中の実施例は、ワードモードでサブフレーム中で２回繰り返される、５つのオーディオチャネルを有する。行７中の実施例は、ワードモードでサブフレーム中で２回繰り返される、６つのオーディオチャネルを有する。行８中の実施例は、ワードモードでサブフレーム中で１回繰り返される、１２個のオーディオチャネルを有する。これらの実施形態では、制御チャネルの帯域幅は、データに対するフレーム中に割り付けられるフレームチャネルの数、およびフレームチャネルの幅に応じて、減少させられることができる。
図４５ｂに関して、行１中の実施例は、ワードモードでサブフレーム中で４回繰り返される、４つのオーディオチャネルを有する。行２中の実施例は、ワードモードでサブフレーム中で４回繰り返される、６つのオーディオチャネルを有する。行３中の実施例は、ワードモードでサブフレーム中で２回繰り返される、８つのオーディオチャネルを有する。行４中の実施例は、ワードモードでサブフレーム中で２回繰り返される、１２個のオーディオチャネルを有する。これらの実施例では、制御チャネルの帯域幅は、１２個のオーディオチャネルの各々の帯域幅の半分である。
ここで図４６ａおよび４６ｂを参照すると、ビットストリームモードで動作し、ビットストリームフレーム形式を使用するときの統一バス通信プロトコルの実施形態に対するバス周波数、オーバーサンプリングレート、チャネルの数およびタイプの例示的組み合わせの表が示されている。これらの組み合わせは、例えば、いくつかのデジタルマイクロホンの組み合わせに使用されることができる。また、インターリーブされたビットストリームチャネルを使用して、ビットストリームチャネルの帯域幅を拡張することも可能であり、例えば、４８ｋＨｚサンプル周波数は、以下に示されるように、同一のクロッキング要件に対して、各々が１６ｋＨｚで３つのビットストリームチャネルを使用する。したがって、インターリーブされたビットストリームチャネルを用いて、（図中の列として示されるような）１つのビットストリームチャネルは、１つより多くのデバイスに関連付けられるビットストリームデータを有することができる。この文脈では、「に関連付けられる」という語句は、データがポートによって生成されるか、またはデバイスのポートによって使用され、これを、１つのデバイスのための複数のポート、または１つより多くのデバイスのための複数のポートへ拡張できることを意味する。図２８ｃおよび２８ｄは、複数のソース／ポートの間でビットストリームフレームチャネル（すなわち、列）を共有する実施例を示す。
図４６ａおよび４６ｂの表は、図４６ａの表の第３の行中の実施例を見ることによって理解することができる。この場合、これらのフレームチャネルのうちの３つがオーディオデータに使用され、フレームチャネルのうちの１つが制御チャネルとして使用される、ビットストリームフレーム形式で合計４つのビットストリームフレームチャネルがある。したがって、制御データに使用される帯域幅は、１／４＝２５％である。実際のサンプルレートは、図４６ａおよび４６ｂに示される実施例に対して変化する。実際のサンプルレートは、出力サンプル周波数をオーバーサンプリングレートで乗算することから求めることができ、すなわち、図４６ａの第１の行に対する実際のサンプルレートは、１６＊４８＝７６８ｋＨｚであろう。シグマデルタ変換器からの出力ビットストリームが、このサンプルレート（７６８ｋＨｚ）である一方で、出力サンプルレートは、どのようなデシメーションフィルタが使用されているかに応じて、１６ｋＨｚとは異なり得る。例えば、デシメーションフィルタが４８倍デシメートする場合には、出力サンプル周波数は、第１の行に示されるように１６ｋＨｚであろう。フレーム制御チャネルに対する制御データも１６ｋＨｚでサンプリングされるが、これらのサンプリングレートが異なる実施例もある。図４６ａおよび４６ｂの実施例の全ては、ビットストリームフレーム形式を利用し、チャネルは、サブフレーム中で１回繰り返されるのみである。ビットストリームモードでは、サブフレームは、制御ビットから始まり、次の制御ビットの前まで続くビットを含むビットを有する、フレームの部分として定義される。２００／３のオーバーサンプリング率を伴う図４６ｂの行２に示される実施例は、（オーバーサンプリング率が６４に近いため）１９．２０ＭＨｚシステム周波数を伴うデジタルマイクロホンに非常に適している。
図４６ａに関して、行１および２中の実施例は、フレームチャネルのうちの一方がビットストリームデータチャネルに使用され、他方のチャネルが制御チャネルに使用される、２つのビットストリームフレームチャネルを有する。行３および４中の実施例は、フレームチャネルのうちの３つがビットストリームデータチャネルに使用され、他のチャネルが制御チャネルに使用される、４つのビットストリームフレームチャネルを有する。行５中の実施例は、フレームチャネルのうちの５つがビットストリームデータチャネルに使用され、他のフレームチャネルが制御チャネルに使用される、６つのビットストリームフレームチャネルを有する。行６中の実施例は、フレームチャネルのうちの７つがビットストリームデータチャネルに使用され、他のフレームチャネルが制御チャネルに使用される、８つのビットストリームフレームチャネルを有する。行７中の実施例は、フレームチャネルのうちの１１個がビットストリームデータチャネルに使用され、他のフレームチャネルが制御チャネルに使用される、１２個のビットストリームフレームチャネルを有する。行８中の実施例は、フレームチャネルのうちの１５個がビットストリームデータチャネルに使用され、他のフレームチャネルが制御チャネルに使用される、１６個のビットストリームフレームチャネルを有する。制御チャネルに対する帯域幅は、図４６ａの帯域幅列に示されるようなビットストリームフレームチャネルの数に応じて変化する。
図４６ｂに関して、行１中の実施例は、フレームチャネルのうちの一方がビットストリームデータチャネルに使用され、他方のフレームチャネルが制御チャネルに使用される、２つのビットストリームフレームチャネルを有する。行２中の実施例は、フレームチャネルのうちの２つがビットストリームデータチャネルに使用され、他のフレームチャネルが制御チャネルに使用される、３つのビットストリームフレームチャネルを有する。行３中の実施例は、フレームチャネルのうちの３つがビットストリームデータチャネルに使用され、他のフレームチャネルが制御チャネルに使用される、４つのビットストリームフレームチャネルを有する。行４および５中の実施例は、フレームチャネルのうちの５つがビットストリームデータチャネルに使用され、他のフレームチャネルが制御チャネルに使用される、６つのビットストリームフレームチャネルを有する。行６中の実施例は、フレームチャネルのうちの１１個がビットストリームデータチャネルに使用され、他のフレームチャネルが制御チャネルに使用される、１２個のビットストリームフレームチャネルを有する。制御チャネルに対する帯域幅は、図４６ｂの帯域幅列に示されるようなビットストリームフレームチャネルの数に応じて変化する。
ここで図４７を参照すると、ハイブリッドワードモードで動作するときの統一バス通信プロトコルの実施形態に対するバス周波数、ならびにチャネルの数およびタイプの例示的組み合わせの表が示されている。この表は、異なるサンプルレートおよび異なる帯域幅の組み合わせを示す（すなわち、異なるソースからのデータが異なる帯域幅を用いて伝送される）。ハイブリッドワードモードは、異なるサンプル周波数が使用される状況（例えば、Ｄｏｌｂｙ ５．１形式、または音声通話および音楽がミキシングに使用されるシナリオ、例えば、同時に８および４８ｋＨｚ）、または異なるワード長が同時に利用可能である場合に有用である。ＲＥＰＥＡＴパラメータが１未満であるとき、データ同期化ビット（ＤＳ０およびＤＳ１）が使用される。図４７の行１中の実施例は、３２０ビットのサブフレーム長を伴うＤｏｌｂｙ ５．１オーディオ転送に好適である。それは、２４ｋＨｚ帯域幅と同等である４８ｋＨｚのサンプル周波数を伴う５つのオーディオチャネル（典型的には、左、右、中央、左後、および右後）と、１．６ｋＨｚ帯域幅と同等である３．２ｋＨｚでサンプリングされる１つのチャネル（典型的にはサブウーファ）とを示す。５の反復値は、７としてコードされるであろう（すなわち、ＤＳ０同期化を使用したフレームの終了までの連続反復）。これは、各々２４ビット分解能を用いて、４８ｋＨｚにおいてＴＤＭワードを伴う５つのチャネルがあり、各チャネルは、６４０ビットの単一の長いサブフレーム中で５回繰り返されることを意味する。単一のチャネルは、２４ビット分解能、および９．６ｋＨｚサンプル周波数を有するであろう。フレーム周波数は、９．６ｋＨｚ／３、すなわち、３．２ｋＨｚである。行２中の実施例は、全てのチャネルが１６ビット分解能を有する、４８ｋＨｚでサンプリングされる２つのチャネル、および８ｋＨｚでサンプリングされる２つのチャネルがあることを意味する。行３中の実施例は、全てのチャネルが１６ビット分解能を有する、４８ｋＨｚでサンプリングされる２つのチャネル、および８ｋＨｚでサンプリングされる３つのチャネルがあることを意味する。制御チャネルに割り付けられる帯域幅を変化させることによって、同一のクロック周波数を使用するときに、より多くのオーディオ／データチャネルを取得できることが分かる。
ここで図４８ａ、４８ｂ、および４８ｃを参照すると、ビットストリームモードで動作し、統一ビットストリームフレーム形式を使用するときの統一バス通信プロトコルの実施形態に対するバス周波数、チャネルの数およびタイプの例示的組み合わせの表が示されている。
図４８ａに関して、この組み合わせは、ビットストリームデータチャネルを使用するポートからの入力データ、およびワードデータチャネルを使用するポートに提供される出力データがあるときに有用である。例えば、図４８ａの形式は、いくつかのマイクロホン（すなわち、ビットストリームデータチャネル）からの入力、および２つ以上のスピーカへのデジタルワードデータ（すなわち、ワードデータチャネル）での出力があるときに使用されることができる。この場合、ビットストリームチャネルのうちのいくつかは、統一フレーム形式に従ってデジタルワードデータをビットストリームデータとして伝送するために使用される。本実施例は、１０個のビットストリームチャネル（すなわち、１０列）へのデータのグループ化を示す。第１の列は、コマンドワードによって占められる制御フレームチャネルである。次の５列は、各々１．２ＭＨｚでサンプリングされ、サンプリング係数が５０である場合に２４ｋＨｚの期待出力サンプル周波数を伴う、５つのオーディオビットストリームによって占められるビットストリームフレームチャネルである。最後の４つの列は、各々４８ｋＨｚで動作し、２０ビット分解能を伴う、５つのＴＤＭデジタルワードストリームを搬送することが予期される、仮想ビットストリームフレームチャネルである。５つのＴＤＭチャネルは、インターレースされる４つの仮想フレームチャネルを経由して転送される（すなわち、最初に５つ全てのＭＳＢが送信され、次いで、５つ全てのＭＳＢ−１が送信される等）。ＤＳ０またはＤＳ１ビットは、同期化に使用されることができる。これは、ビットストリームモードで異なる解釈を有する、ＳＵＢＧＲＯＵＰおよびＲＥＰＥＡＴフィールドをプログラムすることによって行われることができる。ＲＥＰＥＡＴフィールドは、ＴＤＭ転送に割り付けられたビットストリームの数（すなわち、０１１として符号化される、本実施例では４）を示し、ＳＵＢＧＲＯＵＰフィールドは、（０−７の番号付けスキームが使用されるときに）使用される第１のビットストリームを示すであろう。通常、ＴＤＭデータチャネルは、１つのビットストリームチャネルの内側で転送される。しかしながら、少なくとも１つの実施形態では、ＴＤＭワードを伝送するために使用されるフレームチャネルの数がＴＤＭデータチャネルの数より少ない（例えば、ＶＳＰＡＣＩＮＧ定義をＴＤＭワードのために変更することができる）、ビットストリームモードでのＴＤＭワードの使用を取り扱うように、特殊な場合が追加されることができる。
図４８ｂに関して、行１中の実施例は、フレームチャネルのうちの１つがビットストリームデータチャネルに使用され、フレームチャネルのうちの２つがビットストリームデータチャネルに変換されるワードデータチャネルに対する仮想フレームチャネルとして使用され、他のフレームチャネルが制御チャネルに使用される、４つのビットストリームフレームチャネルを有する。行２中の実施例は、フレームチャネルのうちの３つがビットストリームチャネルデータに使用され、フレームチャネルのうちの４つがビットストリームデータに変換されるワードデータチャネルに使用され、他のフレームチャネルが制御チャネルに使用される、８つのビットストリームフレームチャネルを有する。行３中の実施例は、チャネルのうちの３つがビットストリームチャネルデータに使用され、チャネルのうちの４つがビットストリームデータに変換されるワードデータに対する仮想フレームチャネルとして使用され、別のフレームチャネルが制御チャネルとして使用される、８つのビットストリームフレームチャネルを有する。この場合、２つのビットストリームフレームチャネルが、各ＴＤＭデータチャネルを搬送するために使用される。行４中の実施例は、フレームチャネルのうちの４つがビットストリームチャネルデータに使用され、フレームチャネルのうちの３つがビットストリームデータに変換されるワードデータに対する仮想フレームチャネルとして使用され、他のフレームチャネルが制御チャネルとして使用される、８つのビットストリームフレームチャネルを有する。行５中の実施例は、フレームチャネルのうちの４つがビットストリームチャネルデータに使用され、フレームチャネルのうちの３つがビットストリームデータに変換されるワードデータに対する仮想フレームチャネルとして使用され、他のフレームチャネルが制御チャネルとして使用される、８つのビットストリームフレームチャネルを有する。本実施例では、３つのＴＤＭデータチャネルは、３つのビットストリームフレームチャネルに分散される。行６中の実施例は、フレームチャネルのうちの５つがビットストリームチャネルデータに使用され、フレームチャネルのうちの２つがビットストリームデータに変換されるワードデータに対する仮想フレームチャネルとして使用され、他のフレームチャネルが制御チャネルとして使用される、８つのビットストリームフレームチャネルを有する。行８中の実施例は、フレームチャネルのうちの６つがビットストリームチャネルデータに使用され、フレームチャネルのうちの１つがビットストリームデータに変換されるワードデータに対する仮想フレームチャネルとして使用され、別のフレームチャネルが制御チャネルとして使用される、８つのビットストリームフレームチャネルを有する。第３および第５の実施例については、データ同期化ビットが使用される。データ同期化ビットは、マルチフレームサイクルの開始時にアクティブにされることができ、伝送機および受信機の両方がフラクショナルフローの間の同期化を取得するために同一の分数カウンタを使用する。実施例として、分数カウンタの比は、１／２であり得、すなわち、データは、１つおきのサブフレーム中で開始し、データは、チャネルＡから開始する。次いで、次のサブフレーム中で、データは、フレーム境界がなかったかのように出力され続ける。次いで、第３のサブフレーム中で、このプロセスが再び新たに開始する。これの全ては、１つおきのフレームで分数カウンタをリセットする、ＤＳ０ビットによって開始される。このシナリオでは、分数カウンタは、０、１／２、１−＞０、１／２、１−＞０等を数える。伝送機を伴うデバイスは、ＤＳ０ビットを制御するであろう。
図４８ｃに関して、行１中の実施例では、フレーム形式は、８つのビットストリームに分割される。１つのビットストリームフレームチャネルが、制御情報を搬送するために使用され、ビットストリームフレームチャネルのうちの３つが、オーバーサンプリングされた情報（例えば、３つのデータビットストリーム）を搬送するために使用され、４つの残りのビットストリームフレームチャネルが、これらのチャネルの間で多重化されるＴＤＭ情報を伴う５つのワードデータチャネルを搬送するために使用される。行２中の実施例では、１つのビットストリームフレームチャネルが、制御情報に使用され、３つのビットストリームフレームチャネルが、オーバーサンプリングされたデータ（例えば、３つのデータビットストリーム）に使用され、残りの４つのビットストリームフレームチャネルが、各々２０ビットの精度を伴う１０個の多重化ＴＤＭ（ワードデータ）オーディオチャネルを搬送するために使用される。行３の実施例では、１つのビットストリームフレームが、制御情報を搬送するために使用され、５つのビットストリームフレームチャネルが、オーバーサンプリングされたデータ（例えば、５つのデータビットストリーム）を搬送するために使用され、残りの２つのビットストリームフレームチャネルが、５つの多重化ＴＤＭワードデータチャネルを搬送するために使用される。
図４５ａから４７ｃの例示的組み合わせは、オーディオワードデータ、例えば、場合によっては、ワード形式、ビットストリーム形式、または統一ビットストリーム形式である計装またはセンサデータ等の異なるタイプのワードデータとともに使用できることに留意されたい。
統一バス通信プロトコルはまた、種々のデータ形式をサポートすることもできる。少なくとも１つの実施形態では、統一バス通信プロトコルは、これらの異なる形式のデータに対するトランスポート媒体を提供することによって、４つの異なるデータ形式、すなわち、バイナリワード、ビットストリーム、文字列、および浮動小数点をサポートすることができる。他の実施形態では、これらのデータ形式の異なる組み合わせをサポートすることができる。
バイナリワード形式は、ワードモード中にバス６４上で伝送されるワードデータを表すために使用されることができる。ＭＳＢが最初である、２の補数形式を使用して、２進符号化を行うことができる。この場合、数は、１という最大数値を有するように拡大縮小されているものとして解釈されることができる。統一バス通信プロトコルの実施形態に対するバイナリワード形式でＮビットを符号化するための一般的形式の実施例が、図４９ａに示されている。このデータ形式は、Ｉ２ＳおよびＴＤＭ符号化と直接適合性がある。
ビットストリーム符号化形式は、ビットストリームモード中にバス６４上で伝送される、オーバーサンプリングされたデータを表すために使用されることができる。オーバーサンプリングされたデータは、典型的には、限定されないが、例えば、デジタルマイクロホンからの出力等のシグマデルタ変換器からの出力として導出される。いくつかのクラスＤ増幅器はまた、オーバーサンプリングされたデータを入力データとしてサポートする。オーバーサンプリングされたデータは、未加工形態で処理されることができるか、またはベースバンドデータを取得するように以降でデシメートされることができる。使用されるオーバーサンプリング係数は、概して、システム要件に依存する。電話システム用のビットストリーム符号化形式携帯電話とうまく連動する、いくつかの共通オーバーサンプリング係数の実施例が、図４９ｂに示されている。
ビットストリーム符号化形式は、帯域幅効率があまり良くなく、したがって、低遅延のために、またはＰＣＢライン上で使用されることができ、その場合、帯域幅がより高くあり得る。例えば、ビットストリーム形式がヘッドセットインターフェースに使用される場合、１６ｋＨｚ等の４８ｋＨｚより低いサンプルレートを使用することができ、１６ｋＨｚサンプルレートは、例えば、６４のオーバーサンプリング率（ＯＳＲ）で１．０２４ＭＨｚ帯域幅要求をもたらす。整数サンプルレート変換と同時に４４．１および４８ｋＨｚサンプルレートをサポートすることができるため、７．０５６ＭＨｚが特別な周波数であることに留意されたい。したがって、この周波数は、（非整数アップサンプリングおよびミキシングが過渡歪みをもたらし得るが、）可能な限り最高のオーディオ品質をサポートすることができる。デシメーションプロセスの一部として３倍の補間を行うことによって、６６．６７倍のデシメーションを達成することができる。この構成は、１９．２００ＭＨｚクロックシステムに使用されることができる。
文字列符号化形式は、ＡＳＣＩＩ形式を使用し、長さ１バイトの全ての文字が許容される。例示的実施形態では、第１の文字が１に等しい場合、文字列がその後に続き、ゼロで終端されるであろう。第１のバイトが２５４に等しい場合、次の８バイトは文字列の長さを示すであろう。文字列が無制限長を有する場合、第１の文字は２５５に等しいであろう。文字配列が終了した場合、ゼロを使用することができる。統一バス通信プロトコルの実施形態に対する文字列符号化形式のための可能な組み合わせの実施例が、図４９ｃに示されている。
文字列符号化形式は、マスタデバイス５２がスレーブデバイス５４から読み取り、およびスレーブデバイス５４に書き込むときの両方に使用されることができる。文字列の開始の定義は、チャネルのアクティブ化からであり、スレーブデバイス５４がこのコマンドを受信した後に、Ｘワードの後の次のフレームの開始時に始まる。マスタデバイス５２は、文字列を解釈しないが、これらの文字列をトランスポートするにすぎない。変数がＢＣＤ形式（すなわち、２進コード化デジタル形式、例えば、「３４」は「００１１０１００」としてコード化される）で符号化される場合、文字列形式が使用され得る。ＢＣＤ形式でデータを受信するデバイスは、プリアンブルを除去することができる。
例示的実施形態では、浮動小数点形式は、浮動小数点数の形式を表すために、ＩＥＥＥ数値規格７５４−２００８を使用する。圧縮符号化形式が使用されるとき、変数が単精度であろう一方で、一般符号化形式での精度は、符号化において特定される精度と同一であろう。ポートから読み取られる第１のバイト、またはポートに書き込まれる第１のバイトは、最上位ワードであり得る。少なくとも１つの実施形態では、マスタデバイス５２をサポートするドライバは、以下のＩＥＥＥ浮動小数点形式、すなわち、ｂｉｎａｒｙ３２、ｂｉｎａｒｙ６４、ｄｅｃｉｍａｌ３２、およびｄｅｃｉｍａｌ６４を符号化および復号するように構成されることができる。
場合によっては、バス６４に使用されるクロックレートに正確に合致するデータフローを転送することが可能ではない場合があることに留意されたい。実施例として、４８ｋＨｚ接続を経由して４４．１ｋＨｚコンテンツを転送することが必要であり得る。両方のサンプルレートが同一のクロックソースに同期化される場合、２つのサンプルレートの間の比（すなわち、４４．１／４８）は整数ではない。しかしながら、それは、正確な分数（１４７／１６０）であり、バス６４を経由したトランスポートは、非同期プッシュ／プルを用いることなく制御されることができる。このタイプのトランスポートは、フラクショナルフロート呼ばれ、少なくとも１つの実施形態ではマスタデバイス５２によって制御されることができる。フラクショナルフローは、上記のシナリオの単純かつ効率的なサポートを可能にする。ＤＳ０およびＤＳ１ビットは、フラクショナルフローを制御するために使用されることができ、全ての動作中に定義される。
ＤＳ０ビットを設定する１つの方法は、位相累算器を使用し、ＤＳ０ビットを制御するためにオーバーフロー搬送を使用することであり得る。実施例として、ＤＳ０またはＤＳ１ビットへの書き込みは、８ビット分数位相累算器（ＡＣＣ）を使用して制御されることができる。分数位相累算器は、原理上、有限量の位相Δф＝２π（Ｘ／Ｙ）を総位相фに加算し、фが２πより大きいときはいつでも、фから２πを差し引き、ＳＹＮＣフラグを高に設定することによって機能する。図５０ａに示されるアルゴリズムは、少なくとも１つの実施形態では、統一バス通信プロトコルのこのプロセスを実装するために使用されることができる。しかしながら、量（２Ｎ−Ｙ）が最初に計算される場合、単一の加算器が使用されるように、アルゴリズムを訂正することが可能である。
実施例として、Ｘ＝１４７、Ｙ＝１６０、Ｎ＝８（これは４８ｋＨｚチャネル上の４４．１ｋＨｚデータフローに合致する）、および８ビット累算器があると仮定する。サイクル毎に、値Ｘが累算器ＡＣＣに加算され、ＡＣＣ値がＹより大きいとき、次いで、Ｙが累算器ＡＣＣ値から差し引かれるであろう。この例示的シナリオの下での計算が、図５０ｂに示されている。加算は、（８ビット累算器については）２５６を法とする整数値を使用して示されていることに留意されたい。いくつかの実施形態では、一般的に、１６ビット累算器を使用することができる。他の実施形態では、一方の変数に対する１０ビットおよび他方に対する６ビット等の他の分解能を使用することもできる。場合によっては、変数は、この目的で割り付けられるビットの使用と交換され得る。
種々の再生シナリオに対するＸおよびＹのいくつかの典型的な値の実施例が、図５０ｃに示されている。特別なシステム周波数（例えば、２６．０００または２７．０００ＭＨｚ）が使用され得る場合には、次いで、時間基準として使用することができる、１．００または２．００ＭＨｚまで落とすために、クロック分割器が使用され得る。このようにして、たとえば８ビットだけの分解能がＸおよびＹに対して提供されたとしても、分数分割器は、依然として種々の周波数をサポートすることができる。
本明細書で説明される統一バス通信プロトコルの種々の実施形態は、種々の異なる用途で使用されることができる。例えば、統一バス通信プロトコルは、チップ間通信を促進するために使用されることができ、その実施例は、図５１ａおよび５１ｂに示されている。統一バス通信プロトコルはまた、種々のデバイスの間の通信を促進するために使用することもでき、その実施例は、図５２ａから５２ｉに示されている。
ここで図５１ａを参照すると、統一バス通信プロトコルを使用するディスプレイを伴う制御システム２２０の例示的実施形態が示されている。制御システム２２０は、処理ユニット２２２と、ＡＤＣ２２４と、ＡＤＣ２２６と、ＤＡＣ２２８と、ディスプレイ２３０と、これらの要素の全てを一緒に連結するバス２３２とを備える。処理ユニット２２２は、プロセッサ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、または当業者によって公知であるような何らかの他の処理回路であり得る。本実施例では、バス２３２は、１本のワイヤが、クロック信号を伝送するために使用され、別のワイヤが、データ、同期化、およびコマンドデータを伝送するために使用される、２ワイヤ実装を有する。本実施例では、処理ユニット２２２は、マスタデバイスとしての役割を果たし、スレーブデバイスは、ＡＤＣ２２４、ＡＤＣ２２６、ＤＡＣ２２８、ディスプレイ２３０である。
ここで図５１ｂを参照すると、統一バス通信プロトコルを使用する携帯電話システム２５０の例示的実施形態が示されている。携帯電話システム２５０は、例えば、携帯電話またはスマートフォンであり得る。携帯電話システム２５０は、ベースバンドプロセッサ２５２と、ＣＯＤＥＣ２５４と、クラスＤ増幅器２５６と、容量センサ２５８と、ＩＲセンサ２６０と、クラスＤ増幅器２６２と、ＦＭラジオ２６４と、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール２６６と、４つのマイクロホン２６８から２７４と、２つのバス２７６および２７８とを備える。バス２７６は、要素２５２から２６６を連結するために使用され、バス２７８は、要素２５２、２５４、および２６８から２７４を連結するために使用される。本実施例では、バス２７６および２７８は、以前に説明されたように、２ワイヤバス実施形態を使用して実装される。さらに、本実施例では、ベースバンドプロセッサ２５２は、マスタデバイスとしての役割を果たし、他の要素２５４から２７４は、スレーブデバイスとしての役割を果たす。多くのデバイスが同一のバスに連結されるとき、容量損失の増加、およびより低いエネルギー効率が生じるであろうため、システムをよりエネルギー効率的にするために、１つより多くのバスが使用される、用途があり得る。加えて、異なるバスは、より低いクロック速度がよりエネルギー効率的である、異なるクロック速度を有することができる。統一バス通信プロトコルの別の側面は、それが、低費用デジタル付属品を携帯電話システム２５０に接続するバス上で使用され得ることである。
ここで図５２ａを参照すると、統一バス通信プロトコルを使用する住宅用安全システム３００の例示的実施形態が示されている。住宅用安全システム３００は、コントローラ３０２と、無線モデム３０４と、電話線３０６と、ガスセンサ３０８と、二酸化炭素（ＣＯ２）センサ３１０と、スイッチ３１２から３１８と、バス３２０とを備える。スイッチ３１２から３１８は各々、スイッチの状態（例えば、窓またはドアが開いている、または閉じている）に応じて、論理０出力または論理１出力を与えるように、スレーブデバイスに接続される。たとえセンサの各々を伴うスレーブデバイスを含むことのわずかな追加の費用が生じたとしても、これは、より安価な設置費用によって相殺され、それが、スレーブデバイスの追加費用を多大に超え得る。コントローラ３０２は、本明細書で説明される任意の処理ユニットによって実装されることができる。バス３２０は、クロック、データ、コマンド、および同期化情報が同一のバスライン上で送信される、単一ワイヤ実施形態として実装されることができる。バス３２０は、コントローラ３０２を要素３０８から３１８に連結する。コントローラ３０２は、マスタデバイスとしての役割を果たし、要素３０８から３１８は、スレーブデバイスとしての役割を果たす。無線モデムおよび電話線３０６は、線の状態を直接チェックし、警告が着信するときに適切な権限者に報告する（例えば、ある条件が発生するときに、所有者、消防署、警察等に電話する）ことができる、監視中央ステーションまたは家の所有者と通信するために使用され得る。無線モデム３０４は、電話線３０６が故障または破損している場合に、バックアップとしての機能を果たすことができる。
ここで図５２ｂを参照すると、統一バス通信プロトコルを使用する家庭用娯楽システム３５０の例示的実施形態が示されている。家庭用娯楽システム３５０は、ＤＶＤプレーヤ３５２と、増幅器３５４と、スピーカ３５６から３６２と、バス３６４とを備える。バス３６４は、ＤＶＤプレーヤ３５２を増幅器３５４に連結する。バス３６４は、例えば、標準デジタルケーブルにおいて、単一のワイヤとして実装されることができる。本実施例では、ＤＶＤプレーヤ３５２は、マスタデバイスとしての役割を果たし、増幅器３５４は、４つのスピーカ３５６から３６２に対する４つのオーディオチャネルとともに、スレーブデバイスとしての役割を果たす。
ここで図５２ｃを参照すると、統一バス通信プロトコルを使用する家庭用娯楽システム４００の別の例示的実施形態が示されている。家庭用娯楽システム４００は、ＤＶＤプレーヤ４０２と、ＨＤ ＴＶセット４０４と、スピーカ４０６から４１２と、バス４１４とを備える。バス４１４は、ＤＶＤプレーヤ４０２をＨＤ ＴＶ４０４に連結する。バス４１４は、例えば、標準デジタルケーブルにおいて、単一のワイヤとして実装されることができる。本実施例では、ＤＶＤプレーヤ４０２は、マスタデバイスとしての役割を果たし、ＨＤ ＴＶ４０４は、４つのスピーカ４０６から４１２に対する４つのオーディオチャネルとともに、スレーブデバイスとしての役割を果たす。
ここで図５２ｄを参照すると、統一バス通信プロトコルを使用する計装システム４５０の例示的実施形態が示されている。計装システム４５０は、マルチメータ４５２と、センサ４５４と、これら２つの要素を連結するバス４５６とを備える。バス４５６は、例えば、標準デジタルケーブルにおいて、単一のワイヤとして実装されることができる。本実施例では、マルチメータ４５２は、マスタデバイスとしての役割を果たし、センサ４５４は、スレーブデバイスとしての役割を果たす。
ここで図５２ｅを参照すると、統一バス通信プロトコルを使用して通信することができる、電子キー５００の例示的実施形態が示されている。この場合、電子キー５００は、ＩＤを電子キー５００から読み取ることができるように、統一バス通信プロトコルを使用するバス（図示せず）に接続されることができる、２つの端子５０２および５０４を有する。より高い機械的ロバスト性のために、端子は、代替実施形態では、電子キー５００の反対側に実装されることができる。電子キー５００は、スレーブデバイスとしての役割を果たす。
ここで図５２ｆを参照すると、統一バス通信プロトコルを使用して通信することができる、メモリスティック５５０の例示的実施形態が示されている。メモリスティック５５０は、３つの端子、すなわち、正の端子５５２、負の端子５５４、およびデータ端子５５６を有する。データ端子５５６は、統一バス通信プロトコルを使用するバス（図示せず）に接続されることができる。メモリスティック５５０は、スレーブデバイスとしての役割を果たす。
ここで図５２ｇを参照すると、統一バス通信プロトコルを使用して通信することができる、加入者識別モジュール（ＳＩＭ）カード６００の例示的実施形態が示されている。ＳＩＭカード６００は、チップ６０２、および端子６０４から６０８を有する。ＳＩＭカード６００は、電流消費を数ｍＡ以下に保つことができる場合、２つの端子とともに実装されることができる。代替として、ＳＩＭカード６００は、図５２ｇに示されるように、より高い所要電力のために３つの端子を使用して実装されることができ、その場合、端子６０４から６０８のうちの１つは、電力に使用され、端子６０４から６０８のうちの他の２つは、情報を通信するために使用される。
ここで図５２ｈを参照すると、統一バス通信プロトコルを使用して通信することができる、暗号化クレジットカード６５０の例示的実施形態が示されている。暗号化クレジットカード６５０は、チップ６５２、および３つの端子６５４から６５８を有する。統一バス通信プロトコルの使用は、暗号化クレジットカード３５０が、より少ない端子とともに実装されることを可能にする。端子６５４から６５８のうちの１つは、電力に使用され得、端子６５４から６５８のうちの他の２つは、情報を通信するために使用され得る。クレジットカードチップ６５２の電力消費が十分に低い（例えば、３ｍＡを下回る）場合には、電力を移送するために使用される端子が使用されなくてもよく、単一ワイヤ物理層が代わりに使用され得る。
他の実施形態では、本明細書で説明されるような統一バス通信プロトコルは、無線通信に使用され得る。一実施形態では、クレジットカードは、例えば、１３．８ＭＨｚに位置する搬送波を使用して、情報の無線転送のための誘導に基づく回路を含み得、次いで、転送は、ＲＦ場をロードまたはアンロードすることによって取り扱われる。次いで、マスタデバイスが、磁場を変化させることによってスレーブデバイスと通信することができる一方で、スレーブデバイスは、磁場の異なるローディングによって信号伝達し得る。本明細書で説明される統一バス通信プロトコルの種々の実施形態の無線バージョンもまた、他の用途に使用されることができる。
カード読み取り機が、商取引を取り扱うために使用され、したがって、データセキュリティが、不正コピーおよび盗用から守るために使用される。統一バス通信プロトコルの一側面は、デジタル転送データの暗号化の使用による、これらの状況での安全な解決策の実施可能性である。アナログ信号が直接利用可能ではなく、適切な暗号化キーなしでデジタル符号化信号を復号することが可能ではないため、これは、カード読み取り機からアナログ出力信号をコピーする可能性を無効にするであろう。
ここで図５２ｉを参照すると、統一バス通信プロトコルを使用する心拍数モニタシステム７００の例示的実施形態が示されている。心拍数モニタシステム７００は、監視デバイス７０２と、例えば、指クリップセンサ等の心拍数センサ７０４と、それらを一緒に連結するバス７０６とを備える。バス７０６は、単一のワイヤを使用して実装されることができる。本実施例では、監視デバイス７０２は、マスタデバイスとしての役割を果たし、センサ７０４は、スレーブデバイスとしての役割を果たす。一実施形態では、監視デバイス７０２は、指クリップセンサ７０４によって測定される情報に基づいて、心拍数情報を計算する、特殊ソフトウェアアプリケーションを実行する、スマートフォンであり得る。代替実施形態では、特殊ハードウェアおよびファームウェアは、監視デバイス７０２を実装するために使用されることができる。代替実施形態では、心拍数情報を決定するために使用される、生理学的情報を測定するために、他のタイプのセンサを使用することができる。
統一バス通信プロトコルを使用することができるデバイスの他の実施例は、バッテリモニタ、ディスプレイを伴うヘッドセット、雑音低減のための複数のマイクロホンを伴うヘッドセット、ステレオ録音能力を伴うヘッドセット、感度および／または同調を報告するヘッドセット、完全デジタルインターフェースを伴うヘッドセット、低費用センサインターフェース等を備える。バッテリモニタの場合、スマートバッテリは、典型的には、３つの端子、すなわち、正電圧端子、負電圧端子、ならびにバッテリＩＤおよび他の情報がスマートバッテリから読み取られることを可能にするデータラインを有する。したがって、統一バス通信プロトコルは、スマートバッテリと通信し、例えば、温度等のバッテリパラメータを監視するために使用されることができる。
ここで図５３を参照すると、本明細書で説明される統一バス通信プロトコルの１つ以上の実施形態形に従ってバス６４を動作させる方法８００の例示的実施形態が示されている。
８０２では、統一バス通信プロトコルが、マスタデバイス５２によってアクティブにされる。これは、電源投入イベント、リセットイベント後に起こるか、または、何らかの他のイベントによって開始されることができ、その後に、例えば、コントローラまたは状態マシンが、マスタデバイス５２をプログラムし始めるであろう。８０２では、マスタデバイス５２によって使用される種々のレジスタが、初期化され、統一バス通信プロトコルを使用してバス６４を経由して通信することができるように適正な値に設定される。これは、コントローラ等の別のデバイスによって行われ得、またはマスタデバイス５２が、例えば、メモリからこれらの設定にアクセスすることができる。
８０４では、動作モードが構成される。この動作モードは、バスを経由して通信するために使用されるフレーム形式に対する種々のパラメータを選択することを含む。例えば、この時に、マスタデバイス５２は、ワードモードまたはビットストリームモードを使用することの間で選択することができる。
８０６では、次いで、マスタデバイス５２が、ワードフレーム形式、ビットストリームフレーム形式、または統一ビットストリームフレーム形式のうちの１つから、選択されたモードに使用されるフレーム形式を構成することができる。この時に、少なくともいくつかの実施形態では、マスタデバイス５２はまた、データ伝送において故障を引き起こすことなく、マスタデバイス５２が動作中に通信の異なるデータモードの間でシームレスに切り替え得るように、種々のバンクレジスタに通信の異なるデータモードを保存することもできる。異なるデータモードは、限定されないが、異なるサンプリングレート、異なるチャネル選択、異なるポート選択、所与のポートの種々の選択されたチャネルに対するフレームチャネルの異なる割付、フレームチャネルの割付におけるポートチャネルの異なるサブグループ、フレームチャネルの割付におけるポートチャネルの異なる反復、および共通フレームチャネルへの異なるチャネルからのデータの多重化のうちの１つ以上の組み合わせ等の選択されたフレーム形式に対する種々のパラメータを特定することができる。いくつかの実施形態では、マスタデバイス５２は、高速安定化発振器がＵＡＲＴデバイスをより良好にサポートすることを可能にすることによって、低電力モード完了後の高速起動を可能にし得る。
８０８では、バス６４を経由して通信したいスレーブデバイスが、マスタデバイス５２と同期化する。これは、Ｓワードデータの伝送に対してバス６４上のアクティビティを監視することによって、スレーブデバイスによって行われる。ワードモードでは、Ｓワードのビットが、バス６４上で連続的に伝送される。ビットストリームモードでは、Ｓワードのビットは、連続的に伝送されないが、むしろ他のフレームチャネルからのビットと時間多重化される。しかしながら、両方の場合において、少なくとも１つの実施形態では、スレーブデバイス５４は、Ｓワードを認識するとともに、同期化プロセス中にフレーム長およびフレーム構造を決定する。フレーム構造は、同期化プロセスの一部としてスレーブデバイス５４によって認識されるが、同期化（すなわち、ロック）を失うことなく、スレーブデバイス５４が１つのフレーム形式から別のフレーム形式へ即時に変化し、それによって、フレーム形式の即時変化を可能にする時間がある場合、次のフレーム形式がどのようなものになるであろうかを示すために、スレーブデバイス５４の内側のレジスタが含まれることができる。この情報は、ＣＯＭＭＡＮＤ ＳＥＰＡＲＡＴＩＯＮレジスタ中に含まれ得、同期化後にマスタデバイス５２によってスレーブデバイス５４においてプログラムされることができる。ワードおよびビットストリームモードの両方で、スレーブデバイス５４は、バス６４上のアクティビティを監視し、Ｓワードのビットが連続的に送信されるか、または他のデータビットと時間多重化されるかを決定することによって、同期化を試行する。
少なくとも１つの実施形態では、Ｓワードの動的同期部分が決定論的方法を使用して生成されるので、スレーブデバイス５４は、所与のＳワードの一定同期部分を検索し、Ｓワードの動的同期部分に着目し、次のＳワードの動的同期部分を計算することによって、バス６４上のアクティビティを監視する。少なくとも１つの実施形態では、決定論的方法は、例えば、ＣＲＣカウンタであり得るが、それに限定されない。ＣＲＣカウンタは、典型的には値ゼロに遭遇しないようにプロビジョンを使用する（その場合、ゼロで止められるであろう）。これは、この値についてゲート制御し、ゼロの値が発生する場合にＣＲＣカウンタを別の値に設定することによって行われることができる。別の実施形態では、ＣＲＣワードは、適切な出力パターンを生成するようにコード化される論理ゲートを伴うバイナリカウンタからの出力として生成されることができる。少なくとも１つの実施形態では、異なる一定部分が、ワードモードおよびビットストリームモードのためのＳワードに対して使用されることができる。少なくとも１つの実施形態では、異なる一定部分はまた、統一ビットストリームフレーム形式が使用されるときのＳワードに対して使用されることもできる。
同期化プロセスをよりロバストにするために、少なくとも１つの実施形態では、スレーブデバイス５４は、Ｓワードの一定部分を検索し、Ｓワードの動的部分に注意し、次のＳワードの動的部分を数回計算することができる。これら３つのステップは、同期化チェックプロセスと称することができる。この同期化チェックプロセスがより多くの回数で繰り返されるほど、同期化プロセスがよりロバストになるであろう。なぜなら、スレーブデバイス５４が、ワードモードが使用されているか、ビットストリームモードが使用されているかを適正に検出し、例えば、ポート等のバス６４にアタッチされる他のデバイスによって生成される誤った同期化パターンに同期化するよりもむしろ、マスタデバイス５２と同期化する可能性が高くなるからである。しかしながら、同期化チェックプロセスの反復を増加させることと、同期化のための時間を短縮することとの間のトレードオフがある。同期化を達成する種々の方法が、本説明において以降でさらに詳細に議論される。
８１０では、マスタデバイス５２は、スレーブデバイスが挿入されているか、または除去されているか、換言すると、スレーブデバイスがバス６４と接続しようとしているか、またはバス６４から接続解除しつつあるかを検出する。バス６４がすでに動作を開始した後に、デバイスからバス６４への物理的接続が起こる場合、これは、ホット挿入と称される。これは、スレーブデバイス５２がバス６４にアタッチされる前に受電するか、または電力が印加されないときでさえも、別様にバス６４に影響を及ぼさないかのいずれかある限り、本明細書で説明される統一バス通信プロトコルのうちの少なくとも１つで可能である。さらに、バス６４は、バス６４がアクティブであるときでさえも、デバイスが物理的に除去されることを可能にし、これは、ホット除去と称される。少なくとも１つの実施形態では、これは、ＰＩＮＧコマンドを発行することによって、マスタデバイス５２によって行われることができる。ＰＩＮＧコマンドが発行された後、マスタデバイス５２と同期化し、バス６４にロックされている各スレーブデバイスは、ＸおよびＹコマンドワードがバス６４を経由して伝送されるときに、あるタイムスロット中でデータを伝送することによって、そのスレーブ状態を伝送することができる（実施例については図９ａ、９ｂ、および１０、ならびに関連説明を参照）。次いで、マスタデバイス５２は、どのスレーブデバイスがバス６２に接続しようとしているかを決定するために、ＸおよびＹコマンドワード中のスレーブ状態フィールドの値を読み取ることができる。実施形態では、これは、スレーブデバイスがスレーブ状態として「０１」、「１０」、または「１１」の値を書き込んでいる場合に決定されることができる。スレーブデバイスがバスから接続解除する場合、それが占有していたアドレスは、利用可能になり、別のスレーブデバイスに対して使用されることができるか、または、マスタデバイス５２およびバス６４と再度同期化されるまで、同じスレーブデバイスのために保留されたままとなることができる。
少なくとも１つの実施形態では、割り込みビット（ＩＲＱ）が、Ｓワードに関連付けられたタイムスロットに書き込まれることができ、それは、スレーブデバイスのうちの１つが注意を必要とすることをマスタデバイス５２に通知し、その時点で、マスタデバイス５２は、ＰＩＮＧコマンドを発行し、バス６４に接続しようとしているスレーブデバイスの状態を決定することができる。少なくとも１つの実施形態では、割り込みビット（ＩＲＱ）は、スレーブデバイスの状態がある様式で変化する場合に、自動的に発行されることができる。
８１２では、マスタデバイス５２は、バス６４に接続しようとしており、マスタデバイス５２と同期化しているスレーブデバイスにアドレスを割り当てる。実施形態では、これらのスレーブデバイスは、ゼロのデバイスアドレスを有することになり、マスタデバイス５２は、ＲＥＱＵＥＳＴ ＩＤ関数を発行することによって、これらのスレーブデバイスを検出する（実施例については図１１ａおよび関連説明を参照）。この瞬間にバス６４にロックされていないスレーブデバイスは、アクティブにされず、ＲＥＱＵＥＳＴ ＩＤ関数に応答しないであろう。少なくとも１つの実施形態では、複数のスレーブデバイスが、電力上昇イベントまたはリセットイベント後にゼロのデバイスアドレスを有することができるので、次いで、マスタデバイス５２は、異なるアドレスをこれらのスレーブデバイスに割り当てるために、本説明で以前に説明された動的アドレス割付方法を行うことができる。したがって、例えば、Ｉ２Ｃ等の他のバス通信プロトコルと異なり、スレーブデバイスのデフォルトアドレスは、統一バス通信プロトコルを用いて固定される必要がない。これは、多くの場合、Ｉ２Ｃ（７ビットが使用される）において遭遇される、デバイスアドレス衝突に関する問題を有することなく、相対的（例えば、４ビット）アドレス空間の使用を可能にする。この問題を解決するために、Ｉ２Ｃデバイスのデバイス製造業者は、多くの場合、代替的なアドレスのための余分なピンを含むが、これは、余分な費用および空間を追加するか、または同一のチップのプログラムされた変異形を作成し、それによって、運搬上の問題につながる。これは、本明細書で説明される統一バス通信プロトコルの種々の実施形態とともに動的アドレス割付方法を使用することによって、回避されることができる。
８１４では、マスタデバイス５２は、バス６４とちょうど同期化され、連結され、所与のデバイスアドレスが与えられているスレーブデバイスを構成する。この構成は、ポートプログラミング、および選択されたフレーム形式に従った選択されたデータチャネルからのデータに対するタイムスロットの割当等の種々の動作を含むことができる。一般に、この構成は、データ伝送のために、同期化されたスレーブデバイスのうちの少なくとも１つの少なくとも１つのポートから、データチャネルを選択することを伴う。
少なくとも１つの実施形態では、マスタデバイス５２は、そのポートプログラミングについてスレーブデバイス５４に指示する。これは、第１のポートへの入力データを受信するデータチャネルを一緒にグループ化することと、出力データを第２のポートに伝送するデータチャネルを一緒にグループ化することとを含むことができる。少なくとも１つの実施形態では、グループ化はまた、所与のポートのチャネルが、同一の周波数でサンプリングされるデータを有するように行われることもできる。マスタデバイス５２はまた、番号を、スレーブデバイス５４に対して定義されている種々のポートに割り当てることもできる。
少なくとも１つの実施形態では、たとえいくつかのデータチャネルがポートに割り当てられことができても、データチャネルの全てが使用されないこともある。したがって、マスタデバイス５２は、データ伝送またはデータ受信のためにアクティブになるであろう、ポートのデータチャネルの一部分を選択することができる。少なくとも１つの実施形態では、これは、ＣＨＡＮＮＥＬ ＳＥＬＥＣＴＩＯＮフィールドを使用して行われることができる（実施例については図１６および関連説明を参照）。例えば、８つのデータチャネルを伴うポートは、「００００１１００」に設定されたＣＨＡＮＮＥＬ ＳＥＬＥＣＴＩＯＮフィールドを有することができ、その場合、データチャネル２および３が、（データチャネル番号付けが７から始まる場合）アクティブなデータチャネルであるように選択される。
少なくとも１つの実施形態では、次いで、マスタデバイス５２は、統一バス通信プロトコルとともに使用するために選択されているフレーム形式に基づいて、プログラムされたポートに対してデータが配置されるべき場所（すなわち、どのタイムスロットが使用されるか）をスレーブデバイスに指示する。少なくとも１つの実施形態では、ポートは、それがビットストリームを搬送するか、ＴＤＭデータを搬送するかに関して定義され、異なるポートが、異なるデータ形式目的に対して使用される。
ワードモードの場合、２つのコマンドワードの間の最小距離と、コマンドワードの後に、データが最初に配置されるタイムスロットとが特定されることができる。少なくとも１つの実施形態では、これは、ＳＴＡＲＴフィールドによって特定されることができる。各データチャネルのデータ幅も特定することができ、それは、少なくとも１つの実施形態では、ＬＥＮＧＴＨフィールドを使用することによって行われることができる。
ワードモードでは、少なくとも１つの実施形態では、データの転送を微調整することが可能であり、これは、複数のサンプルレートが、１つ以上のスレーブデバイスの１つ以上のポートに対する異なるデータチャネルに同時に使用されるときに、有益かつ効率的である。例えば、少なくとも１つの実施形態では、サブフレーム中のデータチャネルに対するデータの間に間隙があり得る（実施例については図２１および２３ならびに関連説明を参照）。少なくとも１つの実施形態では、サブフレーム中の異なるデータチャネルの種々のグループ化があり得る（実施例については図２１、２３、および２４ならびに関連説明を参照）。少なくとも１つの実施形態では、サブフレーム中の異なるデータチャネルのグループ化の反復があり得る（実施例については図２１、２３、および２４ならびに関連説明を参照）。少なくとも１つの実施形態では、単一のデータチャネルのみが、サブフレーム中で繰り返され得る。少なくとも１つの実施形態では、ＲＥＰＥＡＴ、ＳＵＢＧＲＯＵＰ、およびＳＫＩＰフィールドを使用することによって、サブフレーム中のデータチャネルのこれらの異なる構成を達成されることができる。これらの特徴のうちの少なくとも２つ、およびこれらの特徴の全てを含む、これらの特徴の種々の組み合わせがあり得る、実施形態もあり得る。
ワードモードでは、非同期データ転送を効率的にサポートすることも可能である。少なくとも１つの実施形態では、これは、このデータ伝送に使用される第１のフレーム中で、データチャネルからのデータに先行する２ビットを追加することによって、達成されることができる。ビットのうちの１つは、伝送デバイスが、有効である伝送すべき新しいデータを有するかどうかを示すために使用され得、ビットのうちの１つは、受信デバイスが伝送された新しいデータを受信したかどうかを示すために使用され得る。
ワードモードでは、少なくとも１つの実施形態では、例えば、４４．１ｋＨｚでサンプリングされるデータが４８ｋＨｚ経路を経由して伝送されるとき等に、分数性質であるデータフローをサポートすることも可能であり得る。少なくとも１つの実施形態では、いくつかのフレームにわたるデータ転送を示すために、マスタデバイス５２中の相加算器およびＸコマンドワード中に位置するビットを使用することによって、分数データフローをサポートすることができる。
ビットストリームモードの場合、ワードモードについて行われたように、同様の情報が特定されることができるが、これは、ビットストリームモードで使用される異なるフレーム形式により、わずかに異なって行われる。例えば、ビットストリームフレーム形式を使用することと、統一ビットストリームフレーム形式を使用することとの間で区別がなされることができる。両方の場合において、２つの制御ビットの間の最小距離、ならびにフレームチャネルの数、フレームチャネルの長さ、フレームチャネルへのデータチャネルの割付、および制御チャネルとしてのフレームチャネルの割付が特定されることができる。各フレームチャネルのデータ幅は、１ビットである。
統一ビットストリームフレーム形式では、少なくとも１つのフレームチャネルが、デジタルワードデータを１度に１ビット伝送するために使用される、仮想フレームチャネルとして割り付けられる。これは、ビットストリームデータチャネルおよびワードデータチャネルの両方を同時にサポートすることができる共通フレーム形式を可能にする。したがって、ＴＤＭ信号伝達またはＴＤＭデータ転送を、ビットストリームモードでサポートすることができる。実施形態では、これは、ＴＤＭ ＷＯＲＤＳ ＴＲＡＮＳＦＥＲＲＥＤ ＩＮ ＢＩＴＳＴＲＥＡＭ ＭＯＤＥフィールドを使用することによって達成されることができる。
少なくとも１つの実施形態では、ビットストリームフレーム形式および統一フレーム形式の両方に対するフレームチャネルのうちの少なくとも１つは、異なるデータチャネルからのビットが、多重化フレームチャネルと称することができる共通フレームチャネル中で多重化される多重化フレームチャネルとして割り付けられることができる（図２８ｃおよび２８ｄならびに説明の関連節が実施例を提供する）。これは、異なるフレームチャネルに割り付けられたデータチャネルが、異なるサンプリングレートを使用するときに行われることができ、それによって、より低いサンプリングレートを伴うデータチャネルは、多重化フレームチャネル中で（多重化フレームチャネルの垂直方向へ）インターレースされることができる。
少なくとも１つの実施形態では、ビットストリームフレーム形式および統一フレーム形式の両方について、データチャネルに割り付けられるフレームチャネルの数は、データ伝送中の制御フレームチャネルおよび１つ以上のデータチャネルによって使用される帯域幅を変化させるように、変化させられることができる。
少なくとも１つの実施形態では、ビットストリームフレーム形式および統一フレーム形式の両方について、データの転送を微調整することが可能であり、これは、複数のサンプルレートがチャネルデータに同時に使用されるときに、有益かつ効率的である。例えば、少なくとも１つの実施形態では、フレーム中のデータチャネルに割り付けられるフレームチャネルの間に間隙があり得る（実施例については図２８ｂおよび関連説明を参照）。少なくとも１つの実施形態では、フレーム中の異なるデータチャネルに割り付けられるフレームチャネルの種々のグループ化があり得る（実施例については２６ｂおよび２８ｄならびに関連説明を参照）。少なくとも１つの実施形態では、フレーム中の異なるデータチャネルのグループに割り付けられるフレームチャネルの反復があり得る（実施例については図２６ｂおよび２８ｂならびに関連説明を参照）。少なくとも１つの実施形態では、サブフレーム中のデータチャネルへのフレームチャネルのこれらの異なる構成および割付は、ＨＳＴＡＲＴ、ＶＳＴＡＲＴ、ＨＳＰＡＣＩＮＧ、およびＶＳＰＡＣＩＮＧフィールドを使用することによって、達成されることができる。
少なくとも１つの実施形態では、ワードモードについて説明されたのと同様に、ビットストリームモードで非同期データ転送を効率的にサポートすることが可能である。これは、フラクショナルフローをサポートしたチャネル／ポートが使用された場合に可能であり得る。例えば、そのようなチャネルは、３．０７２ＭＨｚチャネルで４４．１ｋＨｚｘ６４ビットストリームデータを転送するために使用されることができる。
図５３をもう１度参照すると、８１６で、少なくとも１つのデータの伝送機および少なくとも１つのデータの受信機上の選択されたデータチャネルが、アクティブにされる。少なくとも１つの実施形態では、これは、ＡＣＴＩＶＡＴＥフィールドに書き込むことによって行われることができる（実施例については図１６および関連説明を参照）。これらの選択されたデータチャネルは、１つ以上のスレーブデバイスの１つ以上のポートからの１つ以上のデータチャネルであり得る。
８１８では、選択されたデータチャネルに関連付けられたデータがバス６４上で転送される。入力データチャネルである、選択されたデータチャネルについては、これらのデータチャネルからのデータは、バス６４を経由して対応するスレーブデバイスから受信される。出力データチャネルである、選択されたデータチャネルについては、これらの選択されたデータチャネルに対するデータは、バス６４を経由して対応するスレーブデバイスに送信される。一般に、８１８でのデータ転送は、バス６４に連結される少なくとも２つのデバイスの間でデータを伝送することを含み、転送されるデータは、数値データ、制御データ、およびクロックデータのうちの少なくとも１つを備える。
８２０では、データが所与の選択されたデータチャネルに送信されるか、またはそこから受信される必要がない場合、選択されたデータチャネルのうちの少なくとも１つを非アクティブにされることができる。少なくとも１つの実施形態では、選択されたチャネルは、対応するポートのＡＣＴＩＶＡＴＥフィールドを非アクティブにすることによって、非アクティブにされることができる。
次いで、方法８００は、８０４に戻ることができ、そこで、動作モードまたはフレーム形式が変更される必要があり得るかどうかが決定されることができる。例えば、サンプリングレート等のデータチャネルのいくつかのパラメータが変更されるため、例えば、フレーム形式がオンザフライで変更される事例があり得る。他のシナリオでは、データの伝送機および受信機が変化し得る。例えば、オーディオ用途において、１つのシナリオでは、オーディオデータが、ヘッドホンジャックに向けられる一方で、別のシナリオでは、オーディオデータは、受信機、スピーカ、または複合受信機／スピーカに向けられる。いくつかのシナリオでは、１つの信号ソースから別の信号ソースへ徐々に変化すること等のいくつかのミキシング状況を可能にするために、利得変化が複数のデバイスにおいて同時に起こり得る。この時点で、方法８００は、作用８０６から８２０までループする。実施形態では、このループは、統一バス通信プロトコルが非アクティブにされるまで繰り返し行われることができる。例えば、ループは、外部イベントがオーディオセクション等の特定のアプリケーションを終了させる（例えば、通話の終了）場合に、終了することができ、その場合、デバイスは、低電力モードに設定され、クロックは、アイドル状態に設定されるであろう（例えば、ＭＣＬＫＤ＝００００）。
少なくとも１つの実施形態では、マスタデバイス５２の種々のレジスタは、方法８００においてスレーブデバイスについて説明されたように構成されることができる。
本明細書で説明される統一バス通信プロトコルの少なくとも１つの実施形態は、ビットストリームデータ、（例えば、Ｉ２ＳまたはＳＰＤＩＦに接続するための）デジタルワードデータ、ＴＤＭデータ、および制御データ、ならびにＩ２ＣおよびＩ２Ｓ能力のうちの少なくとも１つに対する共通インターフェースサポートを提供する。したがって、本明細書で説明される統一バス通信プロトコルの種々の実施形態は、種々の標準インターフェースの間のデジタルハブとして使用されることができ、または場合によっては、本明細書で説明される統一バス通信プロトコルの少なくとも１つの実施形態は、ＳＬＩＭｂｕｓ、ＭｃＢＳＰ、ＭｃＰＤＭ、およびＭＩＳＯバス通信プロトコルのうちの少なくとも１つに取って代わるために使用されることができる。
本明細書で説明される統一バス通信プロトコルの少なくとも１つの実施形態で行われるように、ビットストリームデータとともに制御データを取り扱う能力は、ビットストリームデータに対する制御情報の転送のための標準方法が、従来のビットストリームバス通信プロトコルではまだ合意されていないため、有益である。さらに、従来の制御方法は、場合によってはクリック音のように鳴るオーディオデータへの妨害をもたらす。さらに、従来のビットストリームインターフェースは、２つより多くのビットストリームデータチャネルがバスを経由して伝送される時に、より多くの端子を必要とする。従来、これは、より多くのデータラインを追加することによって（各データラインがチャネル数を２つだけ増加させるであろう）、または、例えば、ＭｃＰＤＭインターフェースで実装されるように、専用フレーム同期端子を追加し、ビットストリームチャネルを多重化することによって達成されることができる。しかしながら、複数のビットストリームデータチャネルに対するデータを取り扱うために、多重化ビットストリームフレームチャネルが使用されることができ、余分な端子が同期化のために使用されないので、これは、統一バス通信プロトコルには当てはまらない。
本明細書で説明される統一バス通信プロトコルの少なくとも１つの実施形態の側面は、制御データと同時に低遅延を伴うビットストリームデータの等時性転送のサポート、ならびに非同期データストリームに対するサポートである。例えば、ビットストリームモードで達成される低遅延は、ビーム形成、能動雑音消去、近接性感知、漏出補償、一般的制御動作、または他の低遅延用途を含む、種々の用途を可能にする。
また、本明細書で説明される統一バス通信プロトコルの少なくとも１つの実施形態では、プロトコルの全ての特徴をサポートするわけではない、少なくとも１つのスレーブデバイスがあり得ることにも留意されたい。これは、スレーブデバイスがサポートしない機能を実行するようにそれらに要求しないことにより、統一バス通信プロトコルによって取り扱われる。
本明細書で説明される統一バス通信プロトコルの少なくとも１つの実施形態の側面は、内部電力消費を増加させることなく（すなわち、チャネルの数とは無関係の電力消費）、複数のビットストリームデータチャネルに対するサポートを可能にする、スレーブデバイス中のゲートクロックの使用である。この場合、スレーブデバイスは、コマンドデータが利用可能であるとき、およびスレーブデバイスがそれに割り付けられる専用空間にデータを入力または出力するときを除いて、それらの内部クロックを無効にする。これは、たとえビットストリームの数が増加しても、内部クロッキング周波数が同じであり、この特定のフレーム構造をサポートすることができる小さい値であり得ることを意味する。完全システムクロックにおいて作動する必要があり得るスレーブデバイスの一部は、ビットストリーム同期化をチェックするスレーブデバイスのわずかな部分であろう。しかしながら、外部切り替え損失が、より高いシステムクロックとともに増加するであろう。
本明細書で説明される統一バス通信プロトコルの少なくとも１つの実施形態の一側面は、より効率的なデータパッキング、より良好なクロックサポート、および帯域幅に関するさらなる融通性のうちの少なくとも１つのための広い部類のフレーム構造に対するサポートである。例えば、用途および取り扱われているデータのタイプに応じて、ワードフレーム形式、ビットストリームフレーム形式、または統一フレーム形式を使用することができる。少なくともいくつかの実施形態では、ビットストリームフレーム形式および統一フレーム形式において、ビットストリームデータチャネルは、より良いデータ伝送および帯域幅効率のために、フレームチャネル中で種々の方法で組み合わせられることができる。少なくともいくつかの実施形態では、統一ビットストリーム形式は、より良いデータ伝送および帯域幅効率のために、ビットストリームデータチャネルとともにワードデータチャネルを伝送するために使用されることができる。少なくともいくつかの実施形態では、ビットストリームモードで、種々のチャネルからのデータは、データ伝送および帯域幅効率を向上させるように、一緒にグループ化されて繰り返されること等の種々の方法で組み合わせられることができる。
本明細書で説明される統一バス通信プロトコルの少なくとも１つの実施形態の側面は、２つのフレーム形式（すなわち、データモード）の間の瞬間的変化（例えば、オンザフライの変化）のサポートである。それは、プロトコルがこの変化に先立ってスレーブデバイスの準備を可能にすることができるからであり、データにおける故障を回避するであろう。これは、種々のデータモードを追跡するために１つより多くのレジスタを使用することによって達成されることができる。例えば、２つの異なるデータモードが、異なるクロック周波数またはフレーム形式を使用されることができる。
本明細書で説明される統一バス通信プロトコルの少なくとも１つの実施形態の側面は、ハンドシェイキングプロセスを使用しないバス６４へのスレーブデバイスのホット挿入およびホット除去のサポートである。スレーブデバイスは、バス６４が動作を開始した後にバス６４にアタッチされることができる。バス６４は、この場合、クラッシュせず、マスタデバイス５２は、それがアドレスゼロに存在し、バス６４に接続してマスタデバイス５２に同期化するために注意を必要とするという通知をスレーブデバイスから受信するであろう。同様に、マスタデバイス５２への事前通知を伴わずに、スレーブデバイスは、バス６４から物理的に除去されることができる。スレーブデバイスは、それがバス６４から接続解除していることを示すように、その状態レベルを変化させることができ、次いで、状態レベルの変化は、マスタデバイス５２に通信されるであろう。
本明細書で説明される統一バス通信プロトコルの少なくとも１つの実施形態の側面は、以下の特徴のうちの少なくとも１つを実装することによる、内部または外部エラーに対するプロビジョンまたはエラー処理である。例えば、スレーブ状態は、例えば、少なくとも１つの実施形態ではＳワードのビットで表されることができる、スレーブデバイスからの緊急要求を監視することによって、同期化の損失または別の問題を検出するために、連続的に監視されることができる。サポートされ得る別の特徴は、全てのＲＥＡＤ、ＷＲＩＴＥ、およびＦＵＮＣＴＩＯＮ動作が、パリティチェックを含むことができることである。サポートされ得る別の特徴は、全てのＲＥＡＤ、ＷＲＩＴＥ、およびＦＵＮＣＴＩＯＮ動作が、いかなるエラーも伴わずに動作が起こったことを確認するために、データおよび／または命令を受信するデバイスからの確認を含むことができることである。サポートされ得る別の特徴は、クラッシュするバスに接続されるデバイス、または違法データスロットに不慮に書き込むこと（本明細書で説明されるように種々のレジスタビットをチェックすることによって検出されることができる）の発見である。例えば、場合によっては、スレーブデバイスは、独力でバックオフし、バス６４は、いくつかのフレーム以内で再起動するであろう（例えば、自己回復エラー処理）。したがって、Ｉ２Ｃバス通信プロトコルとは異なり、バス６４は、統一バス通信プロトコルでは無期限にクラッシュすることは不可能である。
ここで、本発明を実施するための形態の次の節は、マスタデバイスに、または統一バス通信プロトコル、ワードフレーム形式、またはビットストリームフレーム形式に従って通信するバスに、スレーブデバイスを同期化することの話題について議論する。
いくつかの従来のバス通信プロトコルでは、バス上でデータを伝送するために使用されるフレーム形式のフレーム長は、固定され、同期化を促進するために同一の値にとどまる。例えば、ＳＰＤＩＦ／ＴＯＳＬＩＮＫ、ＡＣ−９７、およびＳＬＩＭｂｕｓバス通信プロトコルは全て、固定フレーム長を使用する。したがって、これらのプロトコルを使用して、限られた数のワイヤを経由してオーディオデータを伝送するとき、固定フレーム長が使用され、特定のクロック周波数およびサンプリングレートを効率的にサポートすることを困難にする。したがって、これらの特定のクロック周波数およびサンプリングレートでの動作は、増加した電力消費、および増加した帯域幅消費をもたらす。例えば、ＳＬＩＭｂｕｓプロトコルは、電気通信用途で使用される標準周波数である、１９．２ＭＨｚの周波数を効率的にサポートする限定された能力を有する。さらに、固定フレーム長を使用し、非同期的にフレーム形式に適合しないバスを経由して任意のデータを伝送することは困難である。このシナリオは、余分な帯域幅、余分なバッファ、および余分な電力消費を伴うであろう。場合によっては、非同期サンプルレートを使用することが可能であり得るが、これは、余分なシリコン面積および電力消費を必要とし、オーディオ用途のためのオーディオ品質の低下をもたらす。
フレーム形式に可変フレーム長を使用する、Ｉ２Ｓ、ＭｃＢＳＰ、ＭｃＰＤＭ、および類似プロトコル等のいくつかの従来のバス通信プロトコルがある。しかしながら、これらのプロトコルは、同期化目的でフレーム同期信号を伝送するために、バス用の別個のワイヤまたはバスラインの使用を必要とする。これは、余分なハードウェア費用および余分な空間を必要とし、余分なワイヤを追加することが可能である、これらの状況のみで使用されることができる。さらに、それらは、例えば、充電器の場合等で、無線媒体または２つの電力端子を経由したデータ伝送に適していない。
場合によっては、可能な解決策は、特別な明確に定義された起動シーケンスを使用することであり、全てのスレーブデバイスが、バスを経由して通信することができるように、起動時にバスに接続され、フレーム長およびフレーム形式情報を受信する。しかしながら、この従来のスキームは、デバイスのホットプラグイン（すなわち、バスがアクティブにされた後の以降の時間に、スレーブデバイスがバスに接続する）、およびデバイスのホット除去（すなわち、バスが非アクティブにされる前にスレーブデバイスがバスから接続解除する）とも称される、バスに動的に接続され、かつバスから動的に接続解除されることができる、スレーブデバイスと適合性がない。また、スレーブデバイスの不具合またはバスの不具合の場合、この従来のスキームでは、特別な起動シーケンスを経由するために、バスが非アクティブにされ、次いで、再びアクティブにされない限り、再度スレーブデバイスがバスと再同期化する方法がない。最終的に、リングベースのバス構造は、故障する単一のデバイスに続いて、全てのデバイスの全不具合を受ける傾向があり、リングベース構造では、バスが起動される前に全てのデバイスがアタッチされる。
加えて、費用、空間、および電力の理由で、フレーム同期化信号がビットストリームデータに組み込まれたときに、多重化ビットストリームシーケンスに同期化することができる、従来のバス同期化アルゴリズムがない。多重化ビットストリームは、バスに使用されるワイヤまたはラインの数を削減しながら、能動雑音消去、ビーム形成、および低遅延用途のために有用である。唯一の従来の解決策は、費用、面積、および電力消費を増加させる、フレーム同期信号のための余分なワイヤを追加することである。これに加えて、これらの従来の方法は、リセット、制御、およびデバイス監視のための追加のワイヤ、ならびにサポートする論理を必要とする。バスに使用されるラインの数を削減しながらの同期化の問題は、マルチフォーマットまたは統一バス通信プロトコルが使用されているときに、さらに複雑な問題になり、フレーム長およびフレーム形式自体の両方が、動作中に変化し得、これらのパラメータは、同期化プロセスの開始時に不明である。
ここで、汎用同期化方法の種々の例示的実施形態が説明され、方法は、フレーム長、フレーム形式、およびフレームタイプが、動作中に変化し得、同期化プロセスの開始時に不明である場合、本明細書で説明されるような統一バス通信プロトコルが使用されるときに、スレーブデバイスをバス６４に同期化するために使用されることができる。例えば、フレーム形式は、ワードフレーム形式（すなわち、ワードモードで）、ビットストリームフレーム形式、または統一ビットストリームフレーム形式（すなわち、両方ともビットストリームモードで）であり得る。別の側面では、本明細書で説明される汎用同期化方法の種々の例示的実施形態のうちの少なくとも１つは、バスに使用されるバスラインまたはワイヤの削減をサポートする。他の側面が、本明細書の汎用同期化方法の種々の例示的実施形態の説明中に明白となるであろう。
一般に、本明細書で説明される汎用同期化方法の種々の例示的実施形態は、バス６４上で伝送されるデータにおいて少なくとも１つの同期化パターンを検索することを伴う。スレーブデバイス５４が同期化パターンを見出すと、スレーブデバイスは、バス６４上でマスタデバイス５２と通信し、フレーム形式、および統一バス通信プロトコルによって使用されている動作モードに従った動作のために構成される。以下でさらに詳細に説明されるように、同期化パターンを見出すための種々の代替案がある。少なくともいくつかの場合において、汎用同期化方法の種々の例示的実施形態は、スレーブデバイス５４の同期エンジンによって実装されることができる。以前に説明されたように、同期エンジンは、目前の特定の用途のためにより好適であるどんなものにも応じて、プロセッサ、状態マシン、または他の専用回路を使用して実装されることができる。
本明細書で説明される汎用同期化方法の少なくとも１つの実施形態では、同期化パターンを検索することは、Ｓワードの一定同期化シンボルまたは一定同期部分を検索することを含む。同期化パターンのビットは、ワードモードのように、バス６４を経由して連続的に伝送され得るか、またはビットストリームモードのように、他のデータビットと多重化またはインターレースされながら１度に１ビット伝送され得る。
本明細書で説明される汎用同期化方法の少なくとも１つの実施形態では、同期化パターンを検索する前に、ワードモード等の２つの動作モードのうちの１つが仮定されることができる。同期化パターンがフレームの最大許容長内で場所を特定されない場合には、他の動作モードを仮定し得、同期化パターンがもう１度検索される。同期化パターンが場所を特定されない場合には、他の動作モードをもう１度仮定し得、同期化パターンが再度検索される。異なるモードの間で前後に交代するこのプロセスは、同期化（すなわち、ロック）が達成されるまで行われることができる。異なるモードに基づく検索間のこの切り替えは、以下でさらに詳細に説明されるように、よりロバストな検索プロセスをもたらす。
本明細書で使用され、文脈に従う場合、「仮定する」または「仮定すること」という動作は、人間が行い得るような考え方を採用することを意味しないことに留意されたい。むしろ、「仮定すること」という動作は、機械が行い得るように、動作または挙動すること、あるいは動作または挙動しようとすること、または試行することを指し得る。「動作モードを仮定すること」等の語句は、例えば、必ずしも最初に、その動作または挙動に関連し得る、特定の事実または機能性あるいは任意の他の条件を検証すること、または正当性を立証することなく、動作のプロトコルまたは慣例または規格または方法に従って、動作または挙動することを指し得る。この文脈では、「第１の動作モードを仮定すること」は、第１の動作モードが、有効で機能的であり、実践では正しくないことが判明し得る結果を達成する良好な方法であるかように、口語的に動作することと考えられ得る。したがって、方法の特定の作用が、特定のパラメータの特定の値を仮定すること、または特定の条件を仮定することとして表されるとき、それは、概して、特定のパラメータの初期値または特定の条件が有効であるものとして選択されることを意味する。特定の実施形態に応じて、次いで、この選択された値は、それが正しいかどうかを確認するようにチェックされ得、もしそうでなければ、次いで、例えば、別の値を選択すること等の別の措置が講じられ得る。
本明細書で説明される汎用同期化方法の少なくとも１つの実施形態では、並行実装を使用することができ、動作モードを仮定する一方の実装は、ワードモードであり、動作モードを仮定する他方の実装は、ビットストリームモードである。次いで、実装は、同期化が達成されるまで、仮定された動作モード下で同時に同期化パターンを検索する。この場合、同期化パターンが、所与の実装について場所を特定されないとき、同一のモードが仮定され得、検索が再度実行される。再度、これは、以下でさらに詳細に説明されるように、よりロバストな検索プロセスをもたらす。
本明細書で説明される汎用同期化方法の少なくとも１つの実施形態では、同期化パターンの第１のインスタンスの場所が特定されると、使用されているフレーム長を決定するために、同期化パターンの次のインスタンスについて、新しい検索が行われるであろう。いくつかの実施形態では、これは、決定されたフレーム長が正しいことを検証するために、数回行われ得る。フレーム長が決定されると、後続の検索は、決定されたフレーム長を使用して、同期化パターンを検索するであろう。少なくとも１つの実施形態では、バス６４上でデータの全フレーム中に同期化パターンが伝送されることができることに留意されたい。
本明細書で説明される汎用同期化方法の少なくとも１つの実施形態では、マスタデバイス５２とスレーブデバイス５４との間の誤った同期化の可能性を低減させるために、同期化パターンは、一定同期部分および動的同期部分を有することができる。動的同期部分を生成するために、決定論的方法が使用されることができ、動的同期部分は、バス６４上で伝送される２つの連続Ｓワードの動的部分の間等、２つの連続する同期化パターンの間で異なる。最初に一定同期部分の場所が特定されると、対応する現在の動的同期部分（すなわち、現在の動的同期部分）が読み取られる。次いで、決定論的方法が、現在の動的同期部分に基づいて、次の期待動的同期部分を計算するために使用される。次に一定同期部分の場所が特定されると、対応する動的同期部分が読み取られ、誤った同期化パターンに仮定されるように、真の同期化パターンの場所が特定されたことを検証するために、計算された上記次の期待動的同期部分と比較される。一定同期部分および動的同期部分の両方に合致する誤った同期化パターンの確率は、単に一定同期部分を検索するより低いので、この場合、大抵の誤った同期化パターンは、無視されるであろう。この検索プロセスは、誤った同期化（すなわち、実際にそうでないときにパターンを有効な同期化パターンとして識別する）の可能性をさらに低減させるために、および、フレーム長を正しく決定するために１回以上繰り返され得、それは、汎用同期化方法のロバスト性も増加させる。少なくともいくつかの実施形態では、動的同期部分を生成するために使用される決定論的方法は、周期的冗長チェック（ＣＲＣ）カウンタまたはジェネレータであり得る。
少なくとも１つの実施形態では、バスからのバストラフィックに基づく、または何らかの他のソースから取得されるランダムな量が、同期化プロセス中に決定を行うために使用され得る。初期同期化中、同期シンボルパターンに合致するバス上の第１のデータが本当にフレームの開始であるかどうかが分かっていない。したがって、ＣＲＣチェックが失敗するとき、それがフレームの開始を表す一定同期部分の第１の合致であるか、第２の合致であるか、またはこれらの合致のうちのいずれもフレームの開始を表さないかどうかが分かっていない。この曖昧性を低減させるために、同期化方法が、誤った同期パターンと真の同期パターンとの間で連続的に切り替わり、同期化（すなわち、ロック）を達成するために苦労する状況が起こる可能性を低減させるのに役立つように、異なる開始位置をランダムに試すために、ランダム成分が初期同期化プロセス中に使用され得る。これは、例えば、常に一定同期部分に合致するデータトラフィックを有する、１つ以上のチャネルがある場合に起こり得る。
本明細書で説明される汎用同期化方法の少なくとも１つの実施形態では、誤った同期化パターンに同期化する可能性をさらに低減させるために、同期化が達成されると、または同期化プロセスの後期に（すなわち、いくつかの真の同期化パターンが見出された後に）、他の同期化パターンを検索するために、決定されたフレーム長が使用されることができる。連続同期化パターンの間の距離は、同期化パターンの長さを引いた決定されたフレーム長であるので、この距離未満で見出される同期化パターンは、誤った同期化パターンであると見なされ、排除されることができる。
本明細書で説明される汎用同期化方法の少なくとも１つの実施形態では、使用される一定同期化シンボルに合致する静的データバストラフィックの条件下で同期化の可能性を向上させるために、ランダム成分が同期化パターンの検索で使用され得る。ランダム成分の使用は、検索されている同期化パターンに密接に合致するランダムバストラフィックに起因して同期化エラーが起こる場合に有益である。
本明細書で説明される同期化方法の少なくとも１つの実施形態では、汎用同期化方法のランダム成分は、ある期間にわたってバストラフィックのパリティを読み取ることと、現在、場所を特定されている同期化パターンが有効な／真の同期化パターンであるか、または誤った同期化パターンであるかを決定することに役立つように、パリティ情報を使用することとを含み得る。パリティ情報は、バス６４に接続され、データをバス６４に提供している、マイクロホン、温度センサ、圧力センサ等の物理的センサがある限り、ランダムであり得る。他の実施形態では、バストラフィックからの入力を利用するＣＲＣジェネレータ、およびＣＲＣジェネレータの動作の過去の履歴が、ランダム成分を生成するために使用され得る。例えば、少なくとも１つの実施形態では、バストラフィックからの１または０の数を加算し、それによって、バストラフィックからランダム成分を生成するために、オーバーフローラッピングを利用する有限のワードサイズを伴う加算器（例えば、単純２進カウンタ）を使用することができる。他の実施形態では、ランダム成分を生成するために、バストラフィックの過去の履歴、関数ジェネレータの内側のコンテンツ、および１つ以上の数学演算子の使用に基づく、一般関数ジェネレータが使用され得る。これらの種々の方法の各々から取得されるランダム成分は、同期化プロセスの開始時にフレームの開始がどこにあるかが最初に分かっていないため、同期化方法が有効および無効同期位置（すなわち、同期パターン）の間で連続的に切り替わる状況で、行き詰まることを回避するために使用され得る。他の実施形態では、既知の状態で起動され得、バスは、誤った同期パターンが存在しないが、この実施形態は、バスが起動した後に別のデバイスが同期化を取得することを可能にしないであろう。したがって、このスキームでは、新しいデバイスがバスに接続しようとする場合に、バスが再起動する必要があろう。したがって、この解決策が選択される場合、いかなるオーディオ妨害も伴わないホットプラグインが可能ではない。
２つの一定同期部分の合致に加えて、動的同期部分に対する合致があることをチェックすることに加え、少なくともいくつかの実施形態では、２つの一定同期パターンの間の距離が一定のままであるかどうかをチェックすることも可能である。これは、有効フレーム形式に当てはまる。したがって、有効な動的同期部分を伴う２つの同期化パターンの間の距離もまた、一定の距離（例えば、２つの同期化パターンの開始または終了間のビットの数で）を有することをチェックすることが可能である。そのようなチェックを行うために、比較されることができる２つの距離を計算することができるように、少なくとも３つの有効な一定同期部分が場所を特定される。
本明細書で説明される同期化方法の少なくとも１つの実施形態では、一定同期部分の場所が特定されているが、１つ以上のエラーがあるとき（ちょうど見出された同期化パターンに基づいて決定される現在のフレーム長が、以前に場所が特定された同期化パターンに基づいて決定された以前のフレーム長と同一ではない等）、ランダム成分が使用されることができる。無効な同期位置を破棄するために、この追加の情報が使用されることができる。
本明細書で説明される汎用同期化方法の少なくとも１つの実施形態では、ビットストリームモードで同期化パターンを検索する汎用同期化方法の部分は、同期化パターンのビットが存在しないと仮定される、チャネルからのデータをスキップするために、クロックゲーティングを利用することができる（例えば、１つおきのビットのみからの情報を使用して、ロックがすでに達成されている場合に、１つおきのビットを無視する）。クロックゲーティングを使用することの１つの利益は、それが電力消費の削減を可能にし、それによって、同期化方法をよりエネルギー効率的にするであろうことである。なぜなら、いくつかのフレームチャネルが同期化パターンのビットを有すると仮定されないので処理されないからである。クロックゲーティングを使用することの別の利益は、以下でさらに詳細に説明されるように、クロックゲーティングが、本質的に、ビットストリームフレームデータがワードデータと同様に処理されることを可能にするので、共通検索構造が、動作のワードおよびビットストリームモードの両方の下で同期化パターンを検索するために使用されることができることである。
一般に、本明細書で説明される種々の汎用同期化方法は、同期化までの時間を短縮するために、上限を採用するであろう。例えば、バス６４がワードモードで動作し、同期化パターンを検索していると仮定するとき、上限をフレーム長に課することができる。したがって、同期化パターンの場所を特定するたように検索されるビット数が、最大定義フレーム長より長く、同期化パターンが見出されていない場合、検索は、ビットストリームモードに切り替わり、同期化エンジンは、同期シンボルパターンが他の情報と多重化されていることを仮定し、同期化を達成するために、正しいチャネル位置、チャネル内の位置、およびチャネルの数を検索するであろう。代替として、少なくとも１つの他の実施形態では、検索方法は、ビットストリームモードに切り替わる前に、ワードモードで１回以上、再度試行し得る。
少なくとも１つの実施形態では、バスがビットストリームモードで動作していると仮定するとき、同期化パターンを検索する前に、フレーム形式でのフレームチャネルの数に上限を課すことができる。例えば、フレームチャネルの最大数がＡｍａｘであると仮定される場合には、本明細書で説明される同期化方法のための検索時間は、Ａｍａｘ３にほぼ比例する。Ａｍａｘを１６以下に設定することが、同期化を取得するための許容可能な時間量をもたらすことが分かっている。しかしながら、同期化を取得するための時間が容認可能である、より高いクロック周波数、より高い処理能力、または両方の条件下で、Ａｍａｘのより高い値を使用することが可能であり得る。全ての可能な数のビットストリームチャネル、およびこれらのチャネルの各々の内側の同期化位置を試行した後に、同期化が取得されていない場合、同期化方法は、再度、ワードモードに戻り、検索プロセスを再び新たに始め得る。これは、マスタデバイスが同期化パターンを伝送する準備がまだできていない、またはマスタデバイスが何らかの機能不全により、または節電目的でアイドル状態であるため、マスタデバイスがバスにアタッチされる前にスレーブデバイスがバスにアタッチされ、スレーブデバイスがクロック信号を受信しているが、いかなる同期化パターンも受信していない場合に有益であり得る。
本明細書で説明される種々の同期化方法の少なくとも１つの実施形態では、例えば、クロック信号上の故障により、スレーブデバイス５４がマスタデバイス５２とのロックから外れる（すなわち、同期化から外れる）場合、スレーブデバイス５４は、完全でより長い同期化検索を回避するために、以前に決定されたフレーム長および同一のフレーム形式を仮定して、同期化を再獲得しようとすることができる。これが成功しない場合、スレーブデバイス５４は、この同一の仮定を使用して、同期化を数回再試行することができる。これが依然として成功しない場合には、スレーブデバイス５４は、マスタデバイス５２が、バス６４上で通信するために異なるフレーム形式または動作モードを使用することに切り替わっていると仮定することができ、次いで、スレーブデバイスがマスタデバイスと同期化されることを可能にするために、完全同期化検索が使用されることができる。
代替実施形態では、本明細書で説明される汎用同期化方法の種々の例示的実施形態のステップが、異なる順番で実装され得ることに留意されたい。例えば、最初にワードモードを仮定して同期化パターンの検索を実行するよりもむしろ、最初にビットストリームモードを仮定し得る。
本明細書で説明される種々の同期化方法のうちの少なくとも１つの利益は、場合によっては、６ＭＨｚクロックレートを仮定して、約６０ミリ秒以下等で極めて迅速に同期化を達成できることである。平均ロック時間は、この値よりはるかに速くあり得る。いくつかの実施形態では、検索時間を減少させるために、チャネルおよびフレーム長の数の全ての組み合わせが可能にされるわけではない。
一側面では、本明細書で説明される汎用同期化方法の種々の例示的実施形態のうちの少なくとも１つの利益は、動作中のバス６４へのスレーブデバイスのホットプラグインおよびホット除去に対するサポートである。したがって、スレーブデバイス５４は、フレーム形式および動作モードを独力で決定し、それがアタッチされ、バス通信プロトコルに従って通信する準備ができていることをマスタデバイス５２に伝えることができる。これは、スレーブデバイス５４が、動作モード、フレーム形式、サブフレーム長、およびフレームの開始位置を決定することを伴うことができる。
一側面では、本明細書で説明される汎用同期化方法の種々の例示的実施形態のうちの少なくとも１つの利益は、スレーブデバイス５４、バス６４、およびこれらのシステム構成要素の間の物理的リンクを表すハードウェアが、物理的に破損されない限り、スレーブデバイス５４が起動する条件、またはバス６４の初期または以降の条件にかかわらず、スレーブデバイス５４がバス６４と同期化し、バス通信プロトコルに従って通信できることである。これは、バス上で発生する雑音の場合、ならびに内部レジスタ状態を変化させるアルファ粒子、またはデバイス自体の制御を超える内部状態の他の変化等のランダムなイベントによるデバイスの機能不全の場合に、同期化のための増加したロバスト性を提供する。さらに、デバイスが不良な実装により故障する場合、この故障後に、このデバイスへのアクセスを得ることが依然として可能である。なぜなら、内部同期化エンジンが、（同期化の欠如、または繰り返されるバス衝突のいずれかによる）エラー後にデバイスがバス６４からバックオフすることを確実にし、次いで、同期化に再度戻ろうとするからである。マスタデバイス５２からの助けを借りずに、スレーブデバイス５４がそれ自体をバス６４にアタッチすることができるという事実が、本システムをよりロバストにする。
一側面では、本明細書で説明される汎用同期化方法の種々の例示的実施形態のうちの少なくとも１つの利益は、バスの動作中にフレーム形式パラメータおよび／または動作モードが変更されることができ、スレーブデバイス５４がまだバス６４にアタッチされていない場合に依然として同期化を達成できることである。
汎用同期化方法の種々の実施形態の以下の説明では、説明される同期化パターンは、Ｓワードであり得、（一定同期部分としても知られている）同期定数は、ＳワードのＣＯＮＳＴＡＮＴ ＳＹＮＣ ＳＹＭＢＯＬフィールド中のデータであり得、動的同期部分は、ＳワードのＤＹＮＡＭＩＣ ＳＹＮＣ ＳＹＭＢＯＬフィールド中のデータであり得ることを理解されたい。代替として、同期化パターンが、ＣＯＮＳＴＡＮＴ ＳＹＮＣ ＳＹＭＢＯＬフィールドからのデータ、ＤＹＮＡＭＩＣ ＳＹＮＣ ＳＹＭＢＯＬフィールドからのデータ、またはＣＯＮＳＴＡＮＴ ＳＹＮＣ ＳＹＭＢＯＬフィールドおよびＤＹＮＡＭＩＣ ＳＹＮＣ ＳＹＭＢＯＬフィールドからのデータの組み合わせを備え得る、実施形態があり得る。他の実施形態では、一定同期シンボルまたは動的同期シンボルは、同期化目的で、単独で、または他の組み合わせで使用されることができ、例えば、フレーム内で１回以上使用されることができる。
同期化は、いくつかの異なる方法で達成されることができ、ここで説明される実施形態は、低ゲート総数で実装されることができることに留意されたい。代替として、より高いゲート総数を使用することによって、より高速の同期化スキームが実装されることができる。
ここで図５４を参照すると、汎用同期化方法９００の例示的実施形態の略図が示されている。汎用同期化方法９００の側面のうちの１つは、バス６４を経由して通信するために使用される統一バス通信プロトコルに使用されている動作モードおよびフレーム形式にかかわらず、バス６４がアクティブにされた後に、スレーブデバイス５４がマスタデバイス５２に同期化するための能力である。
９０２では、方法９００が、統一バス通信プロトコルに対する第１の動作モードを仮定する。したがって、方法９００は、正しい動作モードがワード形式またはビットストリーム形式のいずれかであることを仮定し、次いで、この仮定に基づいて、続いて同期化パターンの場所を特定することに進む。本実施例では、方法９００は、最初に、動作のワードモードを仮定する。
９０４では、方法９００が、第１の動作モードに従って、バス６４を経由して伝送されたデータ中の１つ以上の場所で同期化パターンを検索する。同期化パターンが、一定同期部分および動的同期部分を備える場合、作用９０４は、一定同期部分を検索することを含む。少なくとも１つの実施形態では、一定同期部分は、第１または第２の動作モードについて異なり得る。代替として、別の実施形態では、同期化パターンが固定部分および動的部分を備える場合には、作用９０４は、動的同期部分を検索することを含む。
代替として、少なくとも１つの実施形態では、方法９００は、動的同期部分が決定論的方法によって決定されることができる限り、同期化パターンが一定同期部分を備えるかどうかに関わらず、同期化パターン全体を検索することができる。少なくとも１つの実施形態では、動的同期部分は、２つの連続する同期化パターンの動的同期部分が異なるが決定可能であるように、決定論的方法によって生成されることができる。少なくとも１つの実施形態では、決定論的方法は、ＣＲＣジェネレータ、または以前に説明された変形例のうちの１つを採用し得る。
少なくとも１つの実施形態では、使用されるいくつかの同期化パターンがあり得、作用９０４は、伝送されたデータをこれらの同期化パターンの各々と比較することによって、これらの同期化パターンのうちの１つに対して検索することを含むことができる。
少なくとも１つの実施形態では、異なる同期化パターンは、定義された順番で起こることができ、方法９００は、定義された順番を使用して、異なる同期化パターンを検索することができる。
９０４では、ワードモードが仮定されるとき、方法９００は、同期化パターンの開始タイムスロットとして、伝送されたデータに対するあるタイムスロットを選ぶことを含む。次いで、長さが、検索されている同期化パターンと同一の長さであるように、開始タイムスロットから終了タイムスロットまでの伝送されたデータが、バストラフィックから読み取られ、検索されている同期化パターンと比較される。この例示的実施形態では、検索されている同期化パターンは、一定同期部分である。他の代替実施形態では、異なるデータ長が読み取られ、同期化パターン全体、動的同期部分のみ、または一定同期部分および動的同期部分の両方を含む、同期化パターンの異なる部分と比較されることができる。いかなる合致もない場合には、開始タイムスロットを１つのタイムスロットだけ前進させ、プロセスを繰り返すことができる。並行実装では、並行して、いくつかの開始タイムスロットを選び、バストラフィックからデータを読み取り、読み取られたデータを（ちょうど説明されたような）同期化パターンの一部分または全体と比較することが可能であり得る。
９０４では、ビットストリームモードが仮定されるとき、方法９００は、同期化パターンの開始タイムスロットとして、伝送されたデータに対するあるタイムスロットを選ぶことを含む。次に、ビットストリームフレームチャネルの数が仮定される。次いで、ビットストリームフレームチャネルの仮定された数と各フレームチャネルに対するデータ長とに基づいて、フレーム長を計算することができる。例えば、制御フレームチャネルがＳワードを備え、その後に、各ワードが１６ビットである、ＸワードおよびＹワードが続く、以前に説明されたビットストリームフレーム形式を使用する場合、各フレームチャネルに対するデータ長は、４８ビットであり、フレーム長は、ビット単位で４８＊（仮定ビットストリームフレームチャネルの数）として計算される。いくつかの実施形態では、Ｓ、Ｘ、およびＹワードの間にいくらかの間隔があり得る。ビットストリームフレームチャネルの最大数が定義され、検索は、伝送されたデータを反復して検索することを含む。これは、最初に、多重化されるチャネルのある数を仮定することによって行われる。次いで、有効な同期化パターンが取得されるか、または取得されないまで、全ての有効な位置でこれらのチャネルの各々を検索することが可能である。いかなる同期化パターンも見出されなかった場合、次のチャネルが試行され、全てのチャネルが試行された場合、多重化されていると仮定されたチャネルの数が増加させられ、同一の手順が繰り返されるであろう。このプロセスは、バス６４に対して定義されるチャネルの最大数を超えるまで継続され得、その場合、本プロセスは、再び新たに始まるか、またはワードモードで再度始まるかのいずれかであり得る。この検索は、１つのビットストリームフレームチャネルを仮定することによって始まり得る。本説明のこの部分では、ビットストリームフレームチャネルという用語は、制御フレームチャネル、ビットストリームフレームチャネル、仮想フレームチャネル、および多重化フレームチャネルを対象とするか、または含むように意図されていることに留意されたい。
例えば、ビットストリームフレームチャネルの最大数が３であると仮定すると、１つのビットストリームフレームチャネルがあると仮定することによって、検索が始まり、これは、（制御ワードの間の空間も許容されない限り）フレームがいかなるデータも伴わないフレーム制御チャネルのみを備える場合であろう。この場合、同期化パターンのビットは、ビットごとに発生する。以前に説明されたＳワード、Ｘワード、およびＹワードスキームを仮定すると、この場合にフレームに対して伝送されるビットは、Ｓワードビット１５、Ｓワードビット１４、・・・、Ｓワードビット０、Ｘワードビット１５、Ｘワードビット１４、・・・、Ｘワードビット０、Ｙワードビット１５、Ｙワードビット１４、・・・、およびＹワードビット０を備えるはずである（制御ワードの数、ビット数、ならびにこれらのビットおよびワードの順序付けが、代替実施形態では異なり得ることに留意されたい）。開始タイムスロット位置から始まり、同期化パターンに合致するかどうかを決定するために、次のＭ個の伝送されたデータビットが読み取られ、Ｍは、検索されている同期化パターンのビット数である。いかなる合致もない場合には、開始タイムスロット位置が、１位置、前方に移動させられ、初期の最初のビットが破棄され、次の伝送されたビットが読み取られ、Ｍビット比較が再度繰り返される。いかなる合致もない場合、開始タイムスロット位置を移動させ、比較を行うこのプロセスは、同期化パターンの場所が特定されるか、または最大フレームチャネル長に達するまで繰り返される。同期化パターンが見出されていない場合には、２つのビットストリームフレームチャネルがあると仮定して、この検索プロセスが繰り返される。１つのビットストリームフレームチャネルに対する検索プロセスは、ワードモード下で行われる検索と同一であることに留意されたい。代替的な並行実施形態では、同期化パターンとの比較のために使用される、伝送されたデータを読み取って通過するために、ＦＩＦＯ構造を使用することができるが、通常は、シリアルシフトレジスタが比較のために使用され得る。
ここで、フレーム形式で２つのビットストリームフレームチャネルがあると仮定すると、この場合、同期化パターンのビットが２ビットごとまたは２つのタイムスロットごとに発生するため、方法９００は、伝送されたデータの２ビットごとに検索する。以前に説明されたＳワード、Ｘワード、およびＹワードスキームを仮定すると、この場合、フレームに対して伝送されるビットは、Ｓワードビット１５、データチャネル１ビット０、Ｓワードビット１４、データチャネル１ビット１、・・・、Ｙワードビット０、およびデータチャネル１ビット４７を備えているはずである。もう１度、開始タイムスロット位置から始まり、同期化パターンに合致するかどうかを決定するために、次のＭ個の伝送されたデータビット（各々１ビットによって分離される）が読み取られる。いかなる合致もない場合には、開始タイムスロット位置が、２位置、前方に移動させられ、次のＭ個の伝送されたデータビットが読み取られ、比較が繰り返される。これは、ワードモードで合致を見出すために使用されるアルゴリズムが再利用されるが、この時、１ビットおきにのみアクティブであるようにクロックゲート制御（またはクロック有効化）される場合、ハードウェアにおいて的確に行われることができる。このようにして、１ビットおきにスキップすることは、次の位置で検索し、１つおきの位置に対してクロックゲーティングを追加することと同等である。これは、２ビットをスキップすることと同等である。したがって、チャネルの数がＮであると仮定され、Ｎ−１個の位置でクロックを無効にすることによって、Ｎ−１個のチャネルをスキップし、調査される次のビットが、調査された最後の位置の後のＮ個目の位置であるビットである、単純な統一アルゴリズムが作成されることができる。いかなる合致もない場合には、開始タイムスロット位置を移動させ、比較を行うこのプロセスは、同期化パターンの場所が特定されるか、または最大フレーム長に達するまで繰り返される。最大フレーム長は、ビットストリームフレームチャネルの仮定された数で乗算される最大チャネル長である。同期化パターンが見出されていない場合には、２つのビットストリームフレームチャネルがあると依然として仮定するが、１ビットだけ開始位置を遅延させて、この検索プロセスが繰り返される。この遅延は、単一のクロックサイクルをスキップし、それによって、全ての検索を次のフレームチャネルまで移動させることによって行われることができる。前述の検索プロセスは、同期化パターンが見出されるか、または最大フレームチャネル長に達するまで繰り返される。同期化パターンが見出されていない場合には、３つのビットストリームフレームチャネルがあると仮定して、この検索プロセスが繰り返される。
ここで、フレーム形式で３つのビットストリームフレームチャネルがあると仮定すると、この場合、同期化パターンのビットが３ビットごとまたは３つのタイムスロットごとに発生するため、方法９００は、伝送されたデータの３ビットごとに検索する。以前に説明されたＳワード、Ｘワード、およびＹワードスキームを仮定すると、この場合、フレームに対して伝送されるビットは、Ｓワードビット１５、データチャネル１ビット０、データチャネル２ビット１、Ｓワードビット１４、データチャネル１ビット１、データチャネル２ビット１、・・・、Ｙワードビット０、データチャネル１ビット４７、およびデータチャネル２ビット４７を備えているはずである。もう１度、開始タイムスロット位置から始まり、同期化パターンに合致するかどうかを決定するために、次のＭ個の伝送されたデータビット（それぞれ、２ビット、または１を引いた仮定ビットストリームフレームチャネルの数によって分離される）が読み取られる。いかなる合致もない場合には、開始タイムスロット位置が、３位置、前方に（または前方に仮定ビットストリームフレームチャネルの数で）移動させられる。この場合に前方に移動するために、少なくとも１つの実施形態では、ワードモード検索アルゴリズムへのクロック信号は、典型的には、２つのクロック周期にわたって無効にされるか、またはゲート制御され得、それによって、次のクロック周期を次のビットに等しくする（それによって、同一のアルゴリズムを再利用する）。次いで、第１の伝送されたビットが破棄され、次いで、伝送されたデータビットが読み取られ、比較が繰り返される。いかなる合致もない場合には、開始タイムスロット位置を移動させ、比較を行うこのプロセスは、同期化パターンの場所を特定されるか、または最大フレーム長に達するまで繰り返される。同期化パターンが見出されていない場合には、３つのビットストリームフレームチャネルがあると依然として仮定するが、１ビットだけ開始位置を遅延させて、この検索プロセスが繰り返され、１クロックサイクルをスキップすることによって再度行われることができる。前述の検索プロセスは、同期化パターンが見出されるか、または最大フレームチャネル長に達するまで繰り返される。同期化パターンが見出されていない場合には、３つのビットストリームフレームチャネルがあると仮定するが、１ビットだけ開始位置を遅延させて、この検索プロセスが繰り返される。前述の検索プロセスは、同期化パターンが見出されるか、または最大フレームチャネル長に達するまで繰り返される。本実施例では、３つのチャネル間隔を使用して、本方法がフレームチャネルの全てを通して検索されているため、同期化が取得されている場合がある。しかしながら、同期化パターンが見出されておらず、バスに許容されたチャネルの最大数を超えている場合、モードはワードモードに変更され、または単一のチャネルを再度仮定して、プロセス全体が再び新たに開始される（これは、マスタデバイス５２がいかなる同期化情報も送信していなかった場合に有益であり得る）。
一般に、ビットストリームモードの仮定の下で検索するとき、検索は、最大Ａ個のビットストリームフレームチャネル、Ｑビットのチャネル長を仮定すること、および同期化パターンを検索するためにデータの数回の経由を潜在的に行うこと（並行ハードウェアが存在する場合、単一の経由が使用され得る）を含む。フレームチャネルの現在の数Ｃが設定され、現在のフレームチャネル指数Ｂが１に設定される。ＴＳ０の開始タイムスロットが定義され、Ｂ番目の経由の下で、同期化パターンは、Ｂ番目のビットストリームフレームチャネル中にあると仮定される。例えば、Ａが４であると仮定すると、次いで、Ｃが１に設定され、Ｂが１に設定され、第１のビットストリームチャネルが検索される。同期化パターンが見出されない場合には、２つのビットストリームフレームチャネルがあると仮定され、Ｃが２に設定され、Ｂが１に設定され、開始タイムスロットが１だけ遅延させられ、第１のビットストリームチャネルが検索される。同期化パターンが見出されない場合には、Ｂが２に設定され、１つのタイムスロットをスキップし、第２のチャネル中で開始することによって、検索が第２のビットストリームフレームチャネルについて繰り返される。同期化パターンが見出されない場合には、３つのビットストリームフレームチャネルがあると仮定され、Ｃが３に設定され、Ｂが１に設定され、開始タイムスロットが再度１だけ遅延させられ、第１のビットストリームチャネルが検索される。同期化パターンが見出されない場合には、Ｂが２に設定され、検索が第２のビットストリームフレームチャネルについて繰り返される。同期化パターンが見出されない場合には、Ｂが３に設定され、検索が第３のビットストリームフレームチャネルについて繰り返されることが仮定される。同期化パターンが見出されない場合には、４つのビットストリームフレームチャネルがあると仮定され、Ｃが４に設定され、Ｂが１に設定され、開始タイムスロットが再度１だけ遅延させられ、第１のビットストリームチャネルが検索される。同期化パターンが見出されない場合には、Ｂが２に設定され、検索が第２のビットストリームフレームチャネルについて繰り返される。同期化パターンが見出されない場合には、Ｂが３に設定され、検索が第３のビットストリームフレームチャネルについて繰り返される。同期化パターンが見出されない場合には、Ｂが４に設定され、検索が第４のビットストリームフレームチャネルについて繰り返される。同期化パターンが見出されない場合には、Ｂ＝Ｃ＝Ａであるため、ビットストリームフレームチャネルの最大数が検索されており、方法９００は９０８に移動する。代替として、方法９００は、同期化パターンの場所が特定されると、上記のアクションの全てを経由する必要はない。
異なるデータ長を読み取り、同期化パターンの異なる部分と比較することができるワードモードについて前述されたように、ビットストリームモードを検索するための種々の代替実施形態があり得る。加えて、並行して、いくつかの開始タイムスロットを選び、バストラフィックからデータを読み取り、読み取られたデータを同期化パターンの一部分または全体と比較することが可能であり得る並列実装が使用される実施形態があり得る。実施例として、ビットストリームの数が２Ｎに限定される場合、同期化パターンの場所が特定されるか、またはビットストリームフレームチャネルの最大数が検索されるまで、最初に単一のチャネルを読み取り、これが完了したときに、並行して（各々１つのスロットによってオフセットされる）２つのチャネルを読み取り、これが完了したときに、並行して３つのチャネルを読み取ること等によって、検索時間を約（Ｎ＋１）倍短縮することが可能である。
ワードモードおよびビットストリームモードの下で検索することの間の類似性により、少なくとも１つの実施形態では、ビットストリームモードの下で検索するときにクロックゲーティングを使用することによって、動作のワードモードおよびビットストリームモードの両方の下で同期化パターンを検索するための共通検索構造（すなわち、コンピュータコードまたは状態マシン等の論理構造）を使用することが可能である。クロックゲーティングは、同期化パターンのビットが存在すると仮定されないフレームチャネルからのデータをスキップするために使用される。例えば、３つのビットストリームフレームチャネルがあると仮定すると、ＴＳ０の開始タイムスロットを仮定して、第１の経由の下で、同期化パターンは、タイムスロットＴＳ０、ＴＳ３、ＴＳ６等で伝送されるビットを有する、第１のビットストリームフレームチャネル中に存在すると仮定される。したがって、クロックゲーティングは、これらのタイムスロットで伝送されるデータを選び、タイムスロットＴＳ１、ＴＳ２、ＴＳ４、ＴＳ５等で伝送されるデータを無視するために使用されることができる。同期化パターンが第１の経由中に見出されなかった場合、始点が１つのタイムスロットだけ遅延させられ、検索が繰り返される。したがって、同期化パターンは、タイムスロットＴＳ１、ＴＳ４、ＴＳ７等で伝送されるビットを有する、第２のビットストリームフレームチャネル中に存在すると仮定される。したがって、クロックゲーティングは、これらのタイムスロットで伝送されるデータを選び、タイムスロットＴＳ０、ＴＳ２、ＴＳ３、ＴＳ５等で伝送されるデータを無視するために使用されることができる。同期化パターンが第２の経由中に見出されなかった場合、始点が１つのタイムスロットだけ遅延させられ、検索が繰り返される。したがって、同期化パターンは、タイムスロットＴＳ２、ＴＳ５、ＴＳ８等で伝送されるビットを有する、第３のビットストリームフレームチャネル中に存在すると仮定される。したがって、クロックゲーティングは、これらのタイムスロットで伝送されるデータを選び、タイムスロットＴＳ０、ＴＳ１、ＴＳ３、ＴＳ４等で伝送されるデータを無視するために使用されることができる。
いくつかの実施形態では、ビットストリームモードで並列実装を使用することによって、検索時間を短縮することが可能であり得る。例えば、１度に１つのビットストリームフレーム形式を仮定して、伝送されたデータを検索する代わりに、同時に複数のビットストリームフレーム形式を仮定して、伝送されたデータを検索することが可能であり得る。これは、より高いゲート総数および複雑性をもたらすが、同期化を達成する短縮された時間をもたらすであろう。
９０６では、説明されるような特定の実施形態に依存する、同期化パターンが見出された場合、方法９００は９１０へ移動する。しかしながら、同期化パターンが見出されていない場合、方法９００は９０８へ移動する。動作モードとしてワードモードを仮定するとき、同期化パターンの場所が早期に特定されていない限り、最大フレーム長までを含む種々の開始タイムスロット位置に対して、伝送されたデータで検索作用が行われる。動作モードとしてビットストリームモードを仮定するとき、最大フレーム長までを含む、種々の開始タイムスロット位置に対して、伝送されたデータで検索作用が行われ、これは、同期化パターンの場所が早期に特定されていない限り、フレームチャネルの最大数までの任意の数のフレームチャネルについて繰り返される。いくつかの実施形態では、同期化を達成する時間を短縮するために、フレーム長およびチャネル数の限定された一部のみを検索することが選択され得る。
ビットストリームモードまたはワードモードでは、検索は、新しい伝送されたデータ上で行われることができるか、または伝送されたデータの一部分が保存され、同期化パターンが見出されるか、または検索限界に達するまで、検索が保存されたデータ上で反復されることができる。これら２つの実装の間の選択は、スレーブデバイス５４が同期化パターンの検索に専念させることができる、メモリの量に依存する。例えば、１つだけのバッファが検索のために使用されることができる場合、説明された検索の第１の方法が使用される。この第１の方法の利点は、より小さいチップサイズ、より低い費用、およびより単純な実装である。
９０８では、第１の動作モード（すなわち、ワードモード）を仮定して同期化が取得されていないため、統一バス通信プロトコルのために第２の動作モード（すなわち、ビットストリームモード）が仮定される。次いで、方法９００は、第２の動作モードに従って、伝送されたデータ上で、検索する作用９０４および９０６、ならびに取得する作用９１０を行う。より一般的に、作用９０８は、他のフレーム形式に切り替わることを含む。したがって、検索する作用９０４および９０６がビットストリームモードの下で成功していない場合には、９０８で、もう１度ワードモードを仮定し、同期化パターンが９０４および９０６で再度検索される。異なるフレーム形式の間のこの切り替えは、同期化が取得されるまで繰り返される。通常の条件下で、スレーブデバイスは、異なる状態であるようにプログラムされるまで、この検索を行い続けるであろう。たとえすでに１回完了していたとしても、スレーブデバイスが検索を再度行い続けるべきである理由は、マスタデバイス５２が、何らかの機能不全により一時的に機能停止し得るか、またはスレーブデバイスよりも電源を入れることが遅くあり得ることである。したがって、ロバスト性のために、スレーブデバイスは、単純に検索を継続するべきである。検索を停止することが所望される場合、マスタデバイス５２は、随意に、バスクロックをゲート制御し、それによって、スレーブデバイスが同期化の検索を繰り返し行うことを停止させることができる。
９１０では、方法９００は、使用される特定の実施形態に依存する、少なくとも１つの同期化規則に従って、場所を特定された同期化パターンが検証された場合に同期化を取得することを含む。一般に、少なくとも１つの同期化規則は、９１０で検証を１回以上行うことを伴うことができる。
例えば、少なくとも１つの実施形態では、同期化パターンの場所が特定されると、検索する作用９０４および９０６、ならびに取得する作用９１０は、統一バス通信プロトコルによって使用されているフレーム長を決定するために、次の同期化パターン（すなわち、連続同期化パターン）を検索することを含む。次いで、同期化規則は、決定されたフレーム長が正しいことを検証するために、検索する作用９０４および９０６、ならびに取得する作用９１０を数回行うことを含むことができる。例えば、２つのフレーム長が計算されるように、３つの連続同期化パターンが見出される場合には、２つのフレーム長が異なる場合にエラーがある。代替として、２つのフレーム長が同一である場合には、これは、場合によっては検証として使用され得る。フレーム長が見出されると、フレーム長を３で除算することによって、例えば、２進分割によって、またはこのカウンタがフレーム長に等しくなる（次いで、増分の数がサブフレーム長に等しくなる）までカウンタを３だけ増分することによって、コマンドワードの間の間隔を見出すことができる。
少なくとも１つの実施形態では、検証は、同期化パターンの動的部分を使用することを含む。例えば、検索する作用９０４および９０６、ならびに取得する作用９１０は、現在場所を特定されている同期化パターンに対する一定同期部分に関連付けられる現在の動的同期部分を読み取ることを含み得、同期化規則は、決定論的方法および現在の動的同期部分に基づいて、期待動的同期部分を計算することと、次の一定同期部分の場所を特定することと、誤った同期化の可能性を低減させるために、次の一定同期部分に関連付けられた動的同期部分を期待動的同期部分と比較することとを含む。
期待動的同期部分が次の動的同期部分に等しくない場合には、２つの同期化パターン（すなわち、現在および以前の同期化パターン）のうちの少なくとも１つが不正確であり得る。少なくとも１つの実施形態では、期待動的同期部分が次の動的同期部分に等しくない場合には、現在場所が特定されている同期化パターンは無効であると仮定されることができる。少なくとも１つの代替実施形態では、期待動的同期部分が次の動的同期部分に等しくない場合には、以前に場所が特定された同期化パターンは無効であると仮定されることができ、現在場所が特定されている同期化パターンは有効であると仮定されることができる。これらの選択のうちのいずれかの間で選択することは、以下でさらに詳細に説明されるように、決定プロセスにランダム成分を含むこと等の追加の情報に基づいて行われることができる。
少なくとも１つの代替実施形態では、同期化規則は、方法９００に、計算された動的同期部分に合致する動的同期部分を有する同期化パターンに対して検索し、この場所が特定された同期化パターンが真のパターンであると見なし続けさせることを含むことができる。計算された動的同期部分に合致する動的同期部分を有するかどうかを決定するために、検索される同期化パターンの数に制限（ＦＬ）を課すことができる。この制限が到達された場合、方法９５０は、最後のＦＬの場所が特定された同期化パターンのうちのいずれかを真の同期化パターンとしてランダムに選択するか、または次に来る同期化パターンのうちの１つを真の同期化パターンとしてランダムに選択し、次のＦＬの場所が特定された同期化パターンを見ることによって、更新された動的同期部分に基づいて次の同期化パターンを検索し始めることができる。
少なくとも１つの実施形態では、決定論的方法は、連続同期化パターンがＣＲＣの連続状態に基づく動的部分を有するように、１５個の状態を定義する４ビットを有するＣＲＣジェネレータ（すなわち、ＬＲＳを利用するフィードバックを伴うシフトレジスタ、すなわち、線形反復シーケンス）を使用することを含み得る。１つの状態が現在の動的部分のために配置されている場合、決定論的方法を使用して、次の動的部分のための次の状態が計算されることができる。少なくとも１つの代替実施形態では、異なるビット数を伴うＣＲＣを使用することができる。少なくとも１つの代替実施形態では、限定されないが、８、１６、または異なる数のビットを利用するＬＲＳトポロジーに基づくＣＲＣジェネレータ等の他の決定論的方法を使用することができる。別の実施例として、単純な加算器を使用することができるが、カウンタが１だけ増分された場合に、全反復中に変化するビット数が限定されるであろうという不利点を有するであろう。一般的な実施形態では、ジェネレータＸｎ＋１＝Ｆ（Ｘｎ）を使用して、一連の値が求められ得、ジェネレータ関数Ｆは、値Ｘｎから異なる値Ｘｎ＋１までのマッピングをもたらし、これは、同時に全ステップで可能な限り多くのビットをランダムに変化させながら、所与の間隔内の可能な限り多くの値が利用されるように、数学関数を利用して行われ得る。これを達成する候補実施例は、閉鎖間隔にわたって一様に分布するランダムな離散数字を生成するように書かれる、数学アルゴリズムである。これらのランダムな数字は、全てではないがほとんどの無効な同期位置を排除し、それによって、同期化プロセスを加速することを目的としている、単一または有限数の同期定数に加えて、バス６４上で伝送され得る。
例えば、ＣＲＣジェネレータが、動的同期部分を計算するために、以下の演算、すなわち、｛Ｓ４，Ｓ３，Ｓ２，Ｓ１｝＝｛Ｓ３，Ｓ２，Ｓ１，（Ｓ４ ＸＯＲ Ｓ３）｝を行うと仮定されたい。本実施例では、動的同期部分は、リセット時に「１１１１」に初期化されることができる。少なくとも１つの実施形態では、「００００」状態は使用されず、それに遭遇した場合には、次のサイクル中に「１１１１」状態をもたらすものとする。これの理由は、ＣＲＣカウンタがＬＲＳ構造を使用する少量の論理とともに実装される場合、ＣＲＣカウンタがエラーによってゼロ状態に遭遇すれば、この状態から抜け出せないであろうということである。したがって、「００００」というこの値が、ゼロとは異なる少なくとも１ビットを伴う値に自動的にマップされない限り、（少なくとも伝送機については）回復するために苦労し得る。同様に、４とは異なるビット数がＣＲＣジェネレータで使用される場合、ジェネレータをとどまらせるであろう値（典型的にはゼロ）をチェッックし、これらを別の値にマップする必要がある。次いで、この実施例に対する１６進数でのシーケンス全体は、｛Ｆ，Ｅ，Ｃ，８，１，２，４，９，３，６，Ｄ，Ａ，５，Ｂ，７｝となるであろう。疑似ランダム値である、動的同期部分は、より迅速なロック時間を可能にし、スレーブデバイス５４が、ランダムバストラフィックによって生成され得る、誤った同期化パターンにロックする可能性を低減させる。
一般に、検証は、同期化プロセスをエラーに対してよりロバストにするように、数回行われ得る。例えば、同期化規則は、誤った同期化の可能性をさらに低減させるために、種々の実施形態の計算する作用、場所を特定する作用、比較する作用を１回以上繰り返すことを含み得る。別の実施例として、ＣＲＣジェネレータを使用した検証は、２回、７回、または８回、あるいは例えば、ＣＲＣジェネレータによって生成することができる状態の数まで行われ得る。少なくとも１つの実施形態では、スレーブデバイス５４がマスタデバイス５２と連続的にロックしていることを確実にするために、スレーブデバイス５２は、同期化が確立された後の全フレーム中、ＣＲＣチェックを行い、同期一定部分の発生をチェックし続け得る。
少なくとも１つの実施形態では、同期化規則は、バストラフィック上の雑音が多い条件下で、およびバストラフィックが同期化パターンに密接に類似するときに、同期化の可能性を向上させるために、場所を特定する作用９０４および９０６、ならびに取得する作用９１０中でランダム成分を追加することを含み得る。
例えば、少なくとも１つの実施形態では、ランダム成分は、ある期間にわたってバストラフィックのパリティを読み取ることと、現在場所が特定されている同期化パターンが真のパターンであるか、または誤ったパターンであるかどうかに関してランダムな選択を行うためにパリティ情報を使用することとを含む。このようにして、同期化方法は、例えば、１つおきの場所が特定された一定同期化パターンが有効であり、他の１つおきのものが無効であり、それによって、全てのＣＲＣチェックを無効にする場合に、サイクルから抜け出せなくならないであろう。少なくとも１つの実施形態では、期間は、伝送されたデータの１つのフレームであり得る。
別の実施例として、少なくとも１つの実施形態では、同期化パターンが間違った場所（すなわち、フレームの始めではない）で場所を特定され、それによって、同期化プロセス中に１つ以上のエラーをもたらすときに、ランダム成分が使用され得る。例えば、これらのエラーは、検索されている同期化パターンのように見え得るが、実際には誤った同期化パターンである、バス６４上の伝送されたデータをもたらす状況があるという事実によるものであり得る。誤った同期化パターンが、真のランダムなデータトラフィックの結果である場合、それらは通常、短時間にわたって同期化プロセスを妨害するのみであり、それらが消滅するとき、方法９００は、真の同期化パターンを見出し、スレーブデバイス５４は、バス６４に同期化されるであろう。しかしながら、一定同期部分を検索するとき、例えば、一定同期部分に合致する、温度センサによって提供される一定温度データ等の一定のアクティビティをもたらす状況があり得る。これは、たとえ一定同期部分が多くのビットの長さであることが可能であっても起こり得る。この場合、これらの誤った同期化パターンは、同期化プロセスを妨害するであろう長時間にわたって、バス６４上で伝送されたデータ中に出現し得る。
ここで図５５ａおよび５５ｂを参照すると、それぞれ、真の同期化パターンが伝送されるデータ中で送信される第１のシナリオ、ならびに真および偽の同期化パターンが伝送されるデータ中で送信される第２のシナリオの略図が示されている。本実施例では、（制御データ以外の）伝送されるデータは、オーディオデータである。しかしながら、本実施例はまた、計装データ（すなわち、センサデータ）等の他のタイプのデータにも当てはまり得る。図５５ａでは、制御データは、オーディオデータを備えるデータ部分によって分離される、Ｓワード、Ｘワード、およびＹワードを備える。Ｓワードは、真の同期化パターンを備える。図５５ｂでは、制御データは、図５５ａに示されたものと同じ一般構成要素を備える。しかしながら、ここでは、データ部分中で送信される、３つの誤った同期化パターン（すなわち、３つの誤ったＳワード）がある。代替的な場合において、誤った同期化パターンは、データ部分の始めまたは終わりのより近くに存在することができ、サブフレームのうちのいくつかの中のみにあり得、および／またはおそらく連続データ部分内の異なる場所にあり得る。誤ったＳワードは、真の同期化パターンに対応するデータビットを含む。しかしながら、それらは、フレームの始めにおける正しい場所（すなわち、正しい同期位置）になく、したがって、誤っている。したがって、これらの誤ったＳワードは、真の場所が把握されると、それらの場所に基づいて決定され得る。代替として、これらの誤ったＳワードは、それらが前述のように期待動的同期部分に合致するかどうかを決定するために、これらの誤ったＳワードの動的同期部分をチェックすることによって決定されることができる。
誤った同期化パターンの状況は、汎用同期化方法９００でランダム成分を使用して取り扱うことができる。ランダム成分は、ランダム変数を使用することによって取得される。少なくとも１つの例示的実施形態では、ランダム変数は、ある期間にわたる伝送されるデータのパリティであり得る。例えば、パリティは、最後の同期化パターン以降の１の数が偶数である場合には１に設定されることができ、そうでなければ０に設定され、または逆も同様である。パリティは、２を法とするビットの総数の整数値であるが、他の類似ランダム量を定義することができ、例えば、４を法とするビットの総数の整数値（すなわち、加算するときの最後の２ビット）である。少なくとも１つの実施形態では、最後のフレーム同期化パターン以降の全てのバストラフィックに基づく、追加のＣＲＣジェネレータが使用され得る。ＣＲＣジェネレータは、ＣＲＣジェネレータ自体からの出力を入力として取り、それとバス６４からの入力とのＸＯＲ演算を行うことができる（レジスタ値ゼロを何らかの他の値にマップするように、特別な規定が作成されるべきである）。バストラフィック中の１または０の数を数えることは、量子化プロセス自体が、物理的測定に存在する熱雑音（例えば、量子・電気雑音または量子・機械雑音）により、ランダムなプロセスであるため、ランダムなプロセスである。次いで、この計算に基づいて、ランダムな決定が行われる。少なくとも１つの実施形態では、決定は、以前の同期化パターンを真のパターンとして保つこと、および次の真の同期化パターンを検索し続けること、または現在の同期化パターンを真のパターンとして保つこと、および次の真の同期化パターンを検索し続けることのいずれかであり得る。この決定は、計算されたパリティが０に等しいかどうかをチェックすることによって行われることができる。代替として、この決定は、計算されたパリティが１に等しいかどうかをチェックすることによって行われ得る。各場合において、同期位置の変化の確率は１／２である。一般的な場合において、ランダム変数に基づいて現在の位置にとどまる確率は、ｐとなり、新しい位置に変化する可能性は、（１−ｐ）であろう。以前の同期化パターンまたは現在の同期化パターンが真の同期化パターンとして保持されるかどうかにかかわらず、この方法論を用いて、遅かれ早かれ正しい真の同期化パターンが選択されるであろう。少なくとも１つの実施形態では、現在の同期化パターンを真の同期化パターンとして単に保持する代わりに、方法９００が、次の場所が特定された同期化パターンを真の同期化パターンと見なす前に、現在の同期化パターンから始まる、ランダムであるが有限数の同期化パターンが破棄されることができる。
真の同期化パターンとしての以前に場所が特定された同期化パターンの選択は、ｐという確率を有するものとして表されることができ、真の同期化パターンとしての現在場所が特定されている同期化パターンの選択は、選択されたランダム変数（すなわち、一実施形態で議論されるようなパリティ）に基づいて１−ｐという確率を有するものとして表されることができる。次いで、方法９００は、次の一定同期部分を検索し、関連動的同期部分を期待動的同期部分と比較し続ける。場合によっては、一定同期シンボルのように見える、多くのバストラフィックがある場合、方法が２つのフレーム開始位置の間の正しい同期位置にとどまる可能性は、ｐＮであり、Ｎは、誤った同期位置の数である。しかしながら、正しい同期位置が見出されると、検索方法は、誤った位置を破棄し、正しい位置のみを見るであろう。
少なくとも１つの実施形態では、検索プロセスを完全に決定論的にしようとして、有効な同期定数に関連付けられる最後のＣＲＣ値のリストを作成し、それによって、このリストからの任意の位置に合致する動的同期部分を有さない、以降の同期定数合致を迅速に排除することによって、この同期化検索を加速することが可能であり得る（これは、バス６４上の全ての起こり得る妨害に対処するほど十分に長いリストを伴い得る）。
少なくとも１つの実施形態では、２つの場所が特定された一定同期部分の間にいくつのタイムスロット（すなわち、同期分離値）があるかを観察することによって、多くの誤った同期化パターンを排除することが可能であり得る。次の場所が特定された一定同期部分に対する間隔の下端は、少なくとも（ワードモードで）同期分離値となるはずである。検索方法がＬという２つの同期シンボルの間の距離にすでに遭遇している場合、距離が２つの以降で見出された同期シンボルの間のＬより短ければ、これらの同期シンボルのうちの少なくとも１つは誤っている（同期シンボルという用語は、同期パターンまたは同期部分という用語に類似することに留意されたい）。
少なくとも１つの代替実施形態では、真の同期化パターンが見出されると、本方法は、最大フレーム長に達するか、または場所が特定された同期化パターンの動的同期部分が期待動的同期部分に合致するまで、前方に検索し続けることを含む。この後者の条件が有効である場合には、本方法は、この現在の同期化パターンと以前の同期化パターンとの間の間隔を使用して、将来の同期化パターンを検索し続ける。これは、誤った同期位置であること、または（一定同期部分および動的同期部分の両方がチェックに合格するため）有効な同期位置の良好な候補であることが証明されるまで、所与の第１の同期位置を維持し続けるであろうという点で、以前の方法とは異なる。これは、不確かであるときに２つの同期位置の間でランダムに選択する技法とは対照的である。所与の位置が有効な同期位置ではあり得ないことが証明される場合、同期化方法は、可能性として考えられる有効な同期シンボルをもたらす、次の同期位置まで移動するか、または最大フレーム長を超え得る。この同期化方法が、検証に使用される同期化パターンの数を見出せない場合には、本方法は、最後に場所が特定された同期化パターンを真の同期化パターンとして使用し始めることができるが、これは、行うためにいくらかのメモリを伴い得る。後者の条件が真であり、最大フレーム長に達する場合、同期化方法が新たに始まり、次の真の同期化パターンを検索し始める。この方法は、より高速の同期化を提供すると考えられ得るが、本方法が、（素数の位置、例えば、１１個の位置をスキップするために役立ち得るが）ランダムデータの構造により、真の同期位置をスキップし続け得るため、同期化が達成されない場合があるリスクがある。したがって、この方法が機能するために、全ての同期位置を記憶し、この情報と連動すること、またはいくらかのランダム性を本方法に追加すること、例えば、合致する一定同期シンボルおよび合致する動的同期シンボルを再度検索し始める前に、ランダムな数の同期シンボルをスキップすることのいずれかが必要であり得る。本方法は、並列ハードウェア実装に最も適していると考えられる。これが利用可能である場合、いくつかの検索エンジンを実装し、それによって、アルゴリズム全体を非常に速く確実に稼働させることが可能である。Ｎ個全ての同期エンジンが起動されるまで、第１の同期エンジンは、最初に求められた同期定数への合致する動的同期シンボルを探し得、第２の同期エンジンは、第２の同期位置への合致する動的同期シンボルを探し得る等である。本方法は、いかなる問題にも遭遇することなく、２つのフレーム開始位置の間に最大でＮ−１個の誤った同期位置を許容するであろう。
少なくとも１つの代替実施形態では、最大データ長内で見出されている、全ての有効な一定同期部分に対応する動的同期部分から表を作成することができる。これらの場所が特定された動的同期部分の位置もまた、表に記録される。次に、期待動的同期部分に合致する、表中の動的同期部分の位置は、位置のリスト中に記録されることができる。位置のリスト中の連続位置の分離に反復がある場合には、これらの位置の間の距離は、実際のフレーム長となり、これらの位置は、同期化を取得するために使用されることができる。この方法に関する主要な問題は、ハードウェアオーバーヘッドであり、別の面では、ロバストな同期化を提供する。
上記の変形例のいずれかでは、同期化が達成される場合には、方法９００が作用９１２を行う。同期化が達成されず、動作モードが依然として正しいと仮定される場合には、方法９００は、検索する作用９０４および９０６を再度行い、１つ以上のパラメータをリセットし得る。
本明細書で説明されている同期化規則のうちの少なくとも２つを使用する実施形態があり得ることに留意されたい。また、本明細書で説明されている同期化規則の種々の組み合わせを使用する実施形態もあり得ることにも留意されたい。さらに、本明細書で説明されている同期化規則のうちの少なくとも１つを使用する実施形態があり得ることに留意されたい。
９１２では、同期化がスレーブデバイス５４によって達成されている。統一バス通信プロトコルの特定の実装に応じて、スレーブデバイス５４は、ロック（すなわち、同期化）を達成したことを信号伝達するように、何らかの情報をマスタデバイス５２に返送することを可能にされ得る。その時点で、マスタデバイス５２は、統一バス通信プロトコルに従って通信し、有効にされる、少なくとも１つのポートの１つ以上の入力チャネル、１つ以上の出力チャネル、または１つ以上の入力および出力チャネルを有することができるようにスレーブデバイス５４を構成するために、例えば、種々のパラメータデータをスレーブデバイス５４に送信すること等の種々のアクションを行い得る。少なくとも１つの実施形態では、スレーブデバイス５４は、バス６４にアタッチされたいかなるポートも有さず、バス６４は、スレーブデバイス５４内のレジスタＲＥＡＤ／ＷＲＩＴＥ動作またはＦＵＮＣＴＩＯＮＳのアクティブ化等の制御目的で使用されるにすぎないであろう。代替実施形態では、スレーブデバイス５４によって、または例えば、マスタデバイス５２およびスレーブデバイス５４を伴うイベントの組み合わせによって、設定も行われることができる。少なくとも１つの実施形態では、別のマスタデバイスが、スレーブデバイス設定の全てまたはいくつかを設定することに関与することができる。
同期化が達成されると、方法９００が同期化を維持するように行われ続ける、実施形態があり得ることに留意されたい。エラーがあり、同期化パターンの１つのインスタンスのみに対して同期化が失われる場合において、方法９００は、そのパラメータの全てがリセットされる完全同期化プロセスを方法９００が受ける必要がないように、動作モードおよびフレーム形式パラメータが同一であると仮定することを伴うことができる。例えば、フレーム長およびフレーム形式が決定されているため、同期化が達成されると、同期化を維持するとき、伝送されるデータ中の他の位置は、それらが、最後の同期化パターンからの決定されたフレーム長の距離の近傍にない限り調査されない。これは、方法９００が、同期化パターンの間で伝送されるデータブロック中で発生する、任意の誤った同期化パターンを無視することを可能にする。代替として、同期化が長期間にわたって失われる場合には、最初から同期化プロセスを開始するように、そのパラメータが完全にリセットされた状態で、方法９００が再開され得る。実施例として、スレーブデバイス５４が、最大限可能なフレーム長より長く同期化パターンを受信していない場合、不具合があり、スレーブデバイス５４は、アクティブである任意のポートを非アクティブにし、同期化プロセスを再開するべきである。
また、いずれかの動作モードが、方法９００のために最初に仮定され得ることにも留意されたい。例えば、第１の動作モードは、ワードモードであると仮定され得、第２の動作モードは、ビットストリームモードであると仮定され得る（ワードモードを仮定して同期化が達成されない場合）。しかしながら、代替実施形態では、第１の動作モードは、ビットストリームモードであると仮定され得、第２の動作モードは、ワードモードであると仮定され得る。
ここで図５６を参照すると、統一バス通信プロトコルを使用して通信するマスタデバイスに同期するための汎用同期化方法９５０の別の例示的実施形態の略図が示されている。汎用同期化方法９５０は、並列実装を利用する。９５２で、方法９５０が、統一バス通信プロトコルのために第１および第２の動作モード（すなわち、ワードモードおよびビットストリームモード）の両方を仮定し、仮定動作モードのうちの１つの下で同期化パターンを同時に検索する、２つの別個の同期エンジン（すなわち、一方の同期エンジンは、ワードモードの仮定の下で同期化パターンを検索し、他方の同期エンジンは、ビットストリームモードの仮定の下で同期化パターンを検索する）を使用することを除いて、汎用同期化方法９５０は、方法９００について説明される種々の代替案とともに、汎用同期化方法９００に類似する。したがって、作用９５４は、第１および第２の動作モードに従って伝送されるデータ中の１つ以上の場所で、同期化パターンを同時に検索することを含む。同様に、作用９６０は、同期化パターンが第１および第２の動作モードのうちの１つのための少なくとも１つ同期化規則に従って検証された場合、同期化を取得することを含む。したがって、作用９５４、９５６、９６０、および９６２は、作用９０４、９０６、９１０、および９１２に類似する。
９５８で、同期化が取得されない場合、方法９５０が、統一バス通信プロトコルに従って、伝送されたデータ上で第１および第２の動作モードの両方に従って検索および取得する作用を実行するので、作用９５８は作用９０８とは異なる。同時に両方の動作モードに従って検索するために並列実装が使用されるので、動作モードの間での切り替えは、方法９５０については行われない。
作用９５８から作用９５４への折り返しは、よりロバストな同期化方法をもたらす。なぜなら、検索の第１のインスタンスにおいて、検索の結果に影響を及ぼしたエラーが発生した可能性があり得るため、同一の検索プロセスが両方の動作モードで繰り返されることができ、異なる結果が達成されることができるためである。例えば、バスエラーが生じた可能性があり得、マスタデバイス５２が適正に起動または初期化されていない場合があり、または同期化方法９５０の以前のインスタンスが実行されていたときにバス衝突等が生じた可能性があり得る。場合によっては、同期化方法９５０が行われるときに、スレーブデバイス５４とバス６４との間に欠陥のある物理的接続があり得、例えば、最初にスレーブデバイス５４をバス６４に物理的に接続するときに、適正な物理的接続がなかった場合があり、したがって、適切な電気的接続が起こるために遅延があった。これらの条件の全てが、同期化方法９５０の反復において、解消するか、または解決されるであろう。したがって、同期化方法９５０を繰り返すことにより、よりロバストな同期化プロセスを提供する。同じことが同期化方法９００に言える。したがって、作用９０８で他のモードに切り替わる前に、検索が仮定動作モードの下で１回以上繰り返される、同期化方法９００の代替実施形態があり得る。
ここで図５７を参照すると、統一バス通信プロトコルがワードモードの下で動作しているときに同期化パターンの場所を特定して検証するために、汎用同期化方法とともに使用されることができるワードモード同期化方法１０００の例示的実施形態の略図が示されている。しかしながら、方法１０００は、以下でさらに詳細に説明されるように、クロックゲーティングが使用される場合、ビットストリームモードの下で動作するときにも使用されることができる。
１００２では、方法１０００のインスタンス化が初期化される。方法１０００への関数呼び出しが、方法１０００のインスタンス化を引き起こす。１００４では、同期化パターンを検索し、場所を特定し、検証するために使用される、パラメータ、状態、およびカウンタが初期化される。
１００６では、方法１０００がクロックと同期化する。換言すると、方法１０００の残りの作用が、バス６４のための新しいクロックサイクルで開始する。例えば、作用１００６は、クロック信号が低の論理値から高の論理値まで上昇する（すなわち、上昇クロック信号）場合、方法１０００の残りの作用が行われるように、構成されることができる。代替として、方法１０００は、下降クロック信号に同期化されることができる。さらに別の実施形態では、本デバイスは、立ち上がりおよび立ち下がりエッジの両方に同期化することができる。
１００７では、フレーム内の現在の位置が増分させられる。
１００８では、方法１０００は、バス６４上の伝送されたデータの一部分が、方法９００および９５０について説明されたように、一定同期部分に合致するかどうかを決定する。合致がない場合には、方法１０００は１０１１へ進む。合致がある場合には、方法１０００は１０１０へ進む。
１０１０では、方法１０００は、カウンタ状態が０に等しいかどうかを決定する。状態は、どの程度まで方法１０００が同期化プロセスに沿っているかを数えるために使用される。例えば、状態値が最大状態値に等しい場合には、同期化が達成されている。状態が、現在、０に等しい場合には、これは、一定同期部分の第１の場所に対応し、方法１０００は１０１２へ進む。状態が、現在、０に等しくない場合には、これは、一定同期部分の後続の場所に対応し、方法１０００は１０１４へ進む。
１０１１では、方法１０００は、少なくとも２つの合致する同期シンボル（すなわち、同期化パターン）が取得されているかどうか、および現在の検索位置がフレーム開始（すなわち、フレームの開始）であるかどうかを決定する。このような場合には、方法１０００は、この位置で同期化パターンを見出すことを期待し、エラーがあり、その場合、方法１０００は、１０５０へ進んで、欠落した同期化パターンがあるかどうかをチェックするであろう。そうでなければ、方法１０００は、１０７０へ進み、１００６に戻る前にフレームオーバーランをチェックする。
１０１２では、方法１０００は、状態を１に設定し、決定論的方法および現在の同期動的部分を使用することによって、次の一定同期部分について期待される同期動的部分を計算する。ＣＲＣカウンタを伴う決定論的方法の一実施例は、以前に説明された。次いで、方法１０００は、１０７０へ進んでフレームオーバーランをチェックし、次いで、１００６に戻って次の一定同期部分を検索する。
次いで、１０１４では、方法１０００は、一定同期部分が以前に１度すでに見出されているかどうか、または現在の検索位置が期待フレーム開始位置にあるかどうかをチェックする。この条件が真である場合、方法１０００は１０１６へ進み、そこで、現在の位置がフレームの開始に設定される。１０１４での比較が偽である場合、現在の場所が特定された一定同期部分は無視され、方法１０００は、１０７０へ進んでフレームオーバーランをチェックし、次いで、１００６に戻る。
次いで、１０１８では、方法１０００は、計算された動的同期部分が、現在場所が特定されている一定同期部分に関連付けられる動的同期部分に合致するかどうかをチェックする（この場合、関連付けられるという用語は、一定同期部分に関連付けられる動的同期部分が、同一の同期化パターンまたはＳワードの一部であることを意味する）。１０１８での比較が真である場合には、方法１０００は１０２０へ進む。１０１８での比較が偽である場合には、方法１０００は１０２８へ進む。
１０２０では、計算された動的同期部分と場所が特定された動的同期部分との間に合致がある場合、方法１０００は、現在場所が特定されている一定同期部分を有効と見なし、フレーム長を更新し、次の動的同期部分を計算する。フレーム長は、以前の一定同期部分を含んだ同期化パターンの開始と、現在の一定同期部分を含む同期化パターンの開始との間の距離を計算することによって更新される。次いで、方法１０００は１０２２へ進む。
次いで、１０２２では、方法１０００は、状態が、同期化を達成するために同期化ワードを見出すことが成功している状態の数である、最大状態に等しいかどうかをチェックする。最大状態の値は、誤ったロックの低い確率とロックを取得するためのより長い時間との間の妥協として選択される。最大状態パラメータをより高い数に設定することは、同期化が達成されているように、十分な同期化パターンの場所が特定されていることを方法１０００が決定できる前に、方法１０００のさらなる反復をもたらす。したがって、１０２２での比較が真である場合には、方法１０００は１０２４へ進み、その時点で同期化が達成されている。この場合、方法１０００は、将来の同期化パターンをチェックすることによって同期化を維持するために、１０７０へ、次いで、１００６へ進む。１０２２での比較が偽である場合には、方法１０００は１０２６へ進み、そこで、状態カウンタが１だけ増分させられる。この場合、次いで、方法１０００は、１０７０および１００６へ進んで、同期化を達成することを目指すために次の一定同期部分を検索する。
１０２８では、方法１０００は、最初に状態カウンタの値をチェックする。いくつかの有効な一定同期化シンボルの場所が特定されている場合、現在の動的同期シンボルエラーは無視され、方法１０００は、続行して以前の位置（すなわち、最後に場所が特定された有効な同期化パターンの位置）を基準として保つであろう。次の動的同期シンボルは、無効と見なされる、現在の場所が特定された一定同期部分に関連付けられるものではなく、最後の場所が特定された一定同期部分に関連付けられるものに基づくであろう。代替として、ほんの数個の同期シンボルの場所の特定しか成功していない場合、方法１０００は、同期化を取得することに近づくために、バス６４上の伝送されたデータのランダム性が使用される、１０２９へ進むであろう。現在場所が特定されている一定同期部分に関連付けられる動的同期部分が、以前に場所が特定された一定同期部分に関連付けられる動的同期部分および決定論的方法に基づく、計算された動的同期部分に合致しないため、この比較が行われる。したがって、以前の一定同期部分および現在の一定同期部分のうちの１つは、無効であり、作用１０２９は、以前の一定同期部分を有効な一定同期部分として保つか、または現在の一定同期部分を有効な一定同期部分として保つかを決定しようとする。作用１０２９は、（例えば、パリティを使用することによる方法９００および９５０について以前に説明されたような）バストラフィックのランダム性、ならびに状態カウンタの値に基づいて、この決定を行おうとする。
１０２８で、状態カウンタの値が最大状態値に近い（例えば、状態カウンタの値が、一実施形態では最大状態値より１小さい、または別の実施形態では最大状態値より２小さい、または別の実施形態では最大状態値の少なくとも半分である）と決定される場合には、方法１０００は、同期化を達成する寸前であり、よって、方法１０００は、現在の一定同期部分を１回限りのエラーと見なし、以前の場所が特定された一定同期部分が有効であると仮定し、１０３２へ移動し、そこで、状態カウンタの値を１だけ減少させ、次いで、１００６へ進むことによって、次の一定同期部分をチェックする。しかしながら、１０２９でのランダム性に基づくチェックが偽であり、状態カウンタの値が、方法１０００が同期化を達成する寸前ではないことを示す場合には、以前の一定同期位置を有効な位置として保つか、または新しい一定同期位置を有効な位置として使用するか、ランダムな決定が行われる。次いで、方法１０００は、１０３０へ進み、以前のフレーム長および状態情報を破棄し、次の動的同期部分を計算し、次いで、１０７０および１００６へ進んで、次の一定同期部分を検索し続ける。
ここで図５８ａを参照すると、欠落した同期化パターンを取り扱うために使用され、かつワードモード同期化方法１０００とともに使用されることができる、方法１０５０の例示的実施形態の略図が示されている。具体的には、方法１０５０は、同期化が一瞬失われた場合、方法１０００がそのパラメータを最初期化してワードモードの下で同期化パターンを探すべきかどうか、または方法１０００が古い検索パラメータを継続すべきかどうかを決定しようとする。
１０５２では、方法１０５０が、フレームの始めに潜在的な欠落した同期シンボルのインスタンスを取り扱うように呼び出される。
１０５４では、現在のフレーム位置が、欠落した同期シンボルのインスタンスおよび方法１０００のリセットの両方を網羅するためにリセットされる。
１０５６では、方法１０５０は、状態カウンタの現在の値が最大状態値に等しいかどうかを決定する。この条件が真である場合には、一時的であり得る、発生した１つだけのエラーがあった可能性があり、その場合、方法１０５０は１０５８へ進み、そこで、状態カウンタの値が１だけ減少させられ、次の動的同期部分が計算される。次いで、方法１０５０は１０６２へ進み、そこで、方法１０００に戻り、次の同期化パターンを探し続ける。しかしながら、１０５６での条件が偽である場合には、方法１０５０は１０６０へ進み、その時点で、状態カウンタおよびフレーム長パラメータは、０にリセットされ、方法１０５０は１０６２へ進み、そこで、方法１０００に戻って、依然としてワードモードを仮定して、始めから同期化プロセスを再開する。
ここで図５８ｂを参照すると、現在の検索位置がフレームまたはチャネルの最大長を超えるかどうかをチェックするために方法１０００とともに使用され得る、方法１０７０の例示的実施形態の略図が示されている（すなわち、方法１０７０はフレームオーバーランをチェックする）。
１０７４では、方法１０７０は、現在のモードがビットストリームモードであり、かつ現在のフレームチャネル検索が完了しているかどうかを決定する。この比較が真である場合には、方法１０７０は、１０８０へ進んで、状態カウンタ、フレーム長、および検索位置をリセットする。次いで、方法１０７０は１０８２へ進み、そこで、方法１０７０を呼び出した検索方法に戻ることによって、新しい検索が開始される。１０７４での検索が真ではない場合には、方法１０７０は１０７６へ進む。
１０７６では、方法１０７０は、現在の検索位置が最大限可能フレーム長を超えるかどうかを決定する。この比較が真である場合には、いかなる同期化パターンもワードモードで見出されておらず、方法１０７０は１０７８へ進む。１０７６でのこの比較が真ではない場合、依然として、同期化パターンを見出す可能性があり、方法１０７０は１０８２へ直接進み、そこで、方法１０７０を呼び出した検索方法に戻る。
１０７８では、方法１０７０が、仮定動作モードをビットストリームモードに変更し、１０８０へ、次いで、１０８２へ進むことによって新しい検索を開始する。
１０８０では、現在の位置、フレーム長、および状態値をリセットすることによって、新しい検索が開始される。
１０８２では、方法１０７０が終了し、それを呼び出した方法に戻る。
ここで図５９を参照すると、統一バス通信プロトコルがビットストリームモードの下で動作しているときに、同期化パターンの場所を特定して検証するために汎用同期化方法とともに使用されることができる、ビットストリームモード同期化方法１１００の例示的実施形態の略図が示されている。
１１０２では、方法１１００のインスタンス化が初期化される。方法１１００への関数呼び出しが、方法１１００のインスタンス化を引き起こす。１１０４では、同期化パターンを検索し、場所を特定し、検証するために使用される、パラメータ、状態、およびカウンタが初期化される。例えば、初期化は、ビットストリームフレームチャネルの最大数および最大フレーム長を定義することを含む。１１０６では、方法１１００は、方法１１００の残りのアクションがバス６４のための新しいクロックサイクルで開始するために、以前に説明されたようにクロックと同期化する。
１１０８では、方法１１００は、バス６４上の伝送されたデータの一部分が、方法９００および９５０のビットストリーム部分について説明されたように、一定同期部分に合致するかどうかを決定する。これは、ビットストリームフレームチャネルの現在仮定されている数を通して、１度に１つのチャネルで検索することによって行われる。代替として、並列実装では、これらのチャネルの全てを同時に検索することができる。
１１１０では、方法１１００は、有効な一定同期部分の場所が特定されているかどうかを決定する。これは、現在場所が特定されている一定同期部分の動的同期部分を計算された動的同期部分と比較することによって行われることができる。条件が真である場合には、方法１１００は１１１３へ進む。条件が偽である場合には、方法１１００は１１１２へ進む。１１１０での比較は、一定同期部分の第１の場所では行われず、その場合、一定同期部分が有効であると仮定される。
１１１３では、方法１１００は、現在の場所が特定されている一定同期部分に関連付けられる現在の動的同期部分および決定論的方法に基づいて、次の動的同期部分を計算する。ビットストリーム定義が保持され、検索位置が次の一定同期部分を検索するようにリセットされる。
１１１４では、方法１１００は、状態カウンタの値が最大状態値に等しいかどうかを決定する。もしそうであれば、同期化が達成されている。しかしながら、方法１１００は、同期化が維持されていることを確実にするように、同期化パターンを検索し続ける。したがって、方法１１００は１１１６へ移動する。方法１１００は、ビットストリームフレームチャネルの現在仮定されている数を保ち、次の一定同期部分を検索するように検索位置をリセットし、１１０６へ進む。
この時点で、方法１１００における変形例は、どのビットストリームフレームチャネルにおいて最後の一定同期部分の場所が特定されたかに着目することと、検索の次の反復のための検索時間を短縮するために、一定同期部分の次の位置を推定するためにこの情報を使用することとを含む。これは、少なくとも１つの一定同期部分の場所が特定された場合に行われ得る。代替として、これは、２つ以上のフレームにおいて同じフレームチャネル場所で一定同期部分を見出した後に行われ得る。
１１１４での条件が偽であった場合には、方法１１００は１１１８へ進み、その時点で、状態カウンタの値を１だけ増加させ、１１０６へ進む。この場合、場所が特定された一定同期部分は有効であったが、同期化を達成するように場所が特定された十分な有効一定同期部分がなかったため、方法１１００は、検索をもう１度繰り返して、次の一定同期部分を検索する。
１１１２では、一定同期部分が見出されていなかった場合には、仮定ビットストリームフレームチャネルの数が１だけ増加させられ、検索位置がリセットされる。次いで、方法１１００は１１２０へ進み、そこで、ビットストリームフレームチャネルの仮定数がビットストリームフレームチャネルの最大数より大きいかどうかを決定する。この条件が偽である場合には、方法１１００は１１０６へ進み、そこで、ビットストリームフレームチャネルの新たに定義された数に対するビットストリームフレームチャネル中で同期化パターンを検索する。１１２０での条件が真である場合には、方法１１００は１１２２へ進み、そこで、動作モードがビットストリームモードではないと仮定し、ワードモードに切り替わり、１１２４へ進み、そこで、続けてワードモードの下で同期化パターンを検索する検索方法を使用する（そのような方法の実施例の説明については図５７を参照）。
ここで図６０を参照すると、統一バス通信プロトコルがワードモードの下で動作しているときに、同期化パターンの場所を特定して検証するために汎用同期化方法とともに使用されることができる、汎用同期化方法１１５０の例示的実施形態の略図が示されている。しかしながら、方法１１５０はまた、クロックゲーティングを使用することによって、ビットストリームモードの下で同期化パターンを検索するために使用することもできる。
１１５２では、方法１１５０のインスタンス化が初期化される。
１１５３では、方法１１５０は、フレームオーバーランの可能性、すなわち、方法１１５３を呼び出すことによって、現在の最大フレーム長内でいかなる同期シンボルにも遭遇していないことをチェックする（図６１ｂ参照）。方法１１５３への関数呼び出しが、１２１２で方法１１５３のインスタンス化を引き起こす。
ここで図６１ｂを参照すると、１２１４で、方法１１５３は、検索のために仮定される動作モードがビットストリームモードであるかどうか、および現在のチャネルを通した検索が完了していることを決定する（これは、再同期フラグが真に設定されるときに示される）。この条件が真である場合、方法１１５３は、新しい検索を準備するために１２１６へ進む。１２１６では、現在の検索位置（Ｌ）は、フレームの開始に設定され（すなわち、Ｌ＝０）、現在のフレームの長さ（Ｌ＿ｏｌｄ）は、０にリセットされ、状態カウンタは、０にリセットされる（ビットストリームモードでは、チャネル位置が同時に増分させられる）。次いで、方法１１５３は、１２２２へ、次いで、方法１１５０の１１５４へ進む。１２１４での条件が真ではない場合、方法１１５３は１２１８へ進む。
１２１８では、方法１１５３は、現在の位置が最大フレーム長より大きいかどうかを決定する。この比較が真である場合には（これは、現在の検索中にいかなる同期シンボルにも遭遇しなかった場合にのみ起こるであろう）、方法１１５３は１２２０へ進み、そこで、ワードモードからビットストリームモードへ、または逆も同様に、仮定動作モードを切り替え、パラメータｓｙｎｃ＿ｂｅｇｉｎ＝１を設定する（これは、ビットストリーム同期化方法によって使用されるカウンタを初期化するために使用される、同期化検索プロセスの開始を示す）。その後、方法１１５３は、１２１６へ進んで、現在の検索位置（Ｌ）をフレームの開始にリセットし、現在のフレームの長さ（Ｌ＿ｏｌｄ）および状態カウンタを０にリセットする。次いで、方法１１５３は、１２２２へ、次いで、方法１１５０の１１５４へ進む。
ここで図６０を再度参照すると、１１５４では、方法１１５０は、パラメータリセットが真（すなわち、１）に設定されているかどうかをチェックする。この条件が真である場合には、方法１１５０は１１５６へ進む。この条件が真ではない場合には、方法１１５０は１１５７へ進む。
１１５６では、変数、カウンタ、およびパラメータが初期化される。例えば、この例示的実施形態では、変数Ｌ＿ｏｌｄは、（以前のフレームからの情報に基づく）現在のフレーム長を表し、Ｌは、フレーム内の現在の位置を表し、ｓｔａｔｅは、（状態カウンタが最大状態値によって値を境界されるが）見出されている有効同期化パターンの数を表す。ＣＲＣは、動的同期部分を生成するために使用されるレジスタを表し、パラメータｓｗｅｅｔ＿ｓｐｏｔは、同期化が取得されているかどうかを表し（すなわち、同期化が取得された後のフレームごとの１つのクロックサイクル中、ｓｗｅｅｔ＿ｓｐｏｔ＝１）、ｂｉｔｓｔｒｅａｍ＿ｍｏｄｅは、検索がワードモード（すなわち、ｂｉｔｓｔｒｅａｍ＿ｍｏｄｅ＝０）またはビットストリームモード（すなわち、ｂｉｔｓｔｒｅａｍ＿ｍｏｄｅ＝１）の下で行われているかどうかを表し、ｓｙｎｃ＿ｂｅｇｉｎは、同期化パターンの検索が始めから再開される必要があるかどうかを表す（すなわち、ｓｙｎｃ＿ｂｅｇｉｎ＝１）。いくつかのパラメータ、カウンタ、変数が、例証を簡単にするために１１５６で示されていないこともある。代替実施形態では、他のパラメータ、カウンタ、変数を使用することができる。初期化後、方法１１５０は１１５７へ進む。
１１５７では、方法１１５０は、パラメータｃｌｏｃｋ＿ｇａｔｅが真（すなわち、１）に設定されているかどうかを決定する。このパラメータは、ワードモードまたはビットストリームモードの下で動作するときに、同一の検索構造を使用することができるように使用される。クロックゲーティングの使用は、電力を節約し、同期化検索方法を実装するために使用される論理を単純化する方法である。クロックゲーティングの利益は、いくつのスレーブデバイスがバス６４と同期化しようとするかにかかわらず、スレーブデバイスにつき同一の電力消費が達成されることができることである。しかしながら、クロックゲーティングは、代替実施形態では、随意的であり得る。
１１５７でのチェック後、方法１１５０は、１１５８へ進んで次のクロック遷移を待機する。別の実施形態では、クロックゲーティングは、クロックイネーブル信号によって置き換えられ得る。この場合、このチェックは、１１６４に入る前に１１６０に続くであろう。これは、クロックゲーティングを使用することと同一の利点、すなわち、同一の方法が、ワードモードおよびビットストリームモードの両方に使用され得るという利点を有するが、消費電力が、真のクロックゲーティングと比較してそれほど大きく削減されないという不利点を有する。それは、クロックゲーティングが利用可能ではない構成で使用されることができる。
１１５８では、方法１１５０は、方法１１５０の残りのアクションがバス６４のための新しいクロックサイクルで開始するために、以前に説明されたようにクロックと同期化する。
１１６０では、方法１１５０は、ｓｙｎｃ＿ｂｅｇｉｎパラメータを０に設定する。これは、全クロックサイクル中にこのフラグを自動的にリセットするように行われるが、フレーム形式が変化するとき（図６１ｂの作用１２２０を参照）、ｓｙｎｃ＿ｂｅｇｉｎは真に設定されるであろう。ｓｙｎｃ＿ｂｅｇｉｎパラメータは、ビットストリームモードで使用されるカウンタをリセットするためのフラグとして使用される。
クロックゲーティングを用いると、ｃｌｏｃｋ＿ｇａｔｅパラメータが１に設定されているときに、伝送されたデータが読み取られる。したがって、ワードモードでは、ｃｌｏｃｋ＿ｇａｔｅパラメータは、通常、１に設定されるが、ビットストリームモードでは、ｃｌｏｃｋ＿ｇａｔｅパラメータは、同期化パターンについて検索されている現在のビットストリームフレームチャネルに対応する、伝送されたデータ中のこれらのビットのみについて１に設定される。これは、両方とも０で始まって参照される、現在検索されているビットストリームチャネル（Ｂ）、および現在のチャネル（全クロックサイクル中に変化するＣ）に依存する。ビットストリームフレーム形式について調査されるチャネルの最大数が、Ａｍａｘである一方で、現在の検索は、Ａに等しい数のチャネルを有するフレーム形式を調査する。パラメータＤＬは、短い形式が使用されることを除いて、Ｌに類似し、サブフレーム内の現在の位置を監視するために使用される。第１のビットストリームフレームチャネル指数（Ｂ＝０）について、およびビットストリームフレームチャネルの現在仮定されている数Ａ（Ｃの位置は０からＡ−１まで変化し得る）については、Ｂの値は、伝送されたデータからデータを読み取るための開始位置を取得するため使用され、Ｃの値は、現在検索されていないチャネルをスキップするために使用される。本実施例では、クロックゲーティングおよびビットストリームモードを用いると、方法１１５０は、位置０で伝送されたデータを読み取り始め、次いで、Ａ回、タイムスロットを先にスキップして、検索されているビットストリームフレームチャネルに対する次の伝送されたデータを読み取る。したがって、本実施例では、ｃｌｏｃｋ＿ｇａｔｅパラメータは、０番目、Ａ番目、２＊Ａ番目等のタイムスロットについては１に設定され、他のタイムスロットについては０に設定される。
１１６４では、パラメータｓｗｅｅｔ＿ｓｐｏｔが０に設定され、現在の位置Ｌが１だけ増分させられる。次いで、方法１１５０は１１６６へ進む。
１１６６では、方法１１５０は、検索されている、現在の伝送されたデータ中の一定同期部分に対する合致があるかどうかを決定する。この作用は、方法９００および９５０について説明された。この条件が真である場合、方法１１５０は１１６８へ進む。この条件が偽である場合、方法１１５０は、１１６９へ進んで、欠落した同期シンボルがあるかどうかをチェックする。
１１６８では、一定同期部分の場所が特定されているので、方法１１５０は、状態カウンタが０に等しいかどうかを決定する。この条件が真である場合には、これは、一定同期部分の場所が特定されている最初の時であり、方法１１５０は１１７０へ進む。この条件が真ではない場合には、方法１１５０は、１１７２へ進んで、場所が特定された一定同期部分が有効であるかどうかをチェックする。
１１６９では、方法１１５０は、状態が少なくとも２であるかどうか、および現在の位置がフレームの長さに合致することを決定する（方法が、２の状態値を有することを意味する、少なくとも２つの一定同期部分を見出した場合、フレームの長さが取得されているであろう）。この場合、方法１１５０は、同期化シンボルを見出すことを期待するが、現在のフレームについては何も見出されていない。したがって、方法１１５０は１１７４へ進み、そこで、欠落した同期方法１２００を呼び出す（図６１ａ参照）。１１６９での比較が真ではない場合、方法１１５０は、同期化パターンが期待される位置にない。したがって、それはエラーではなく、同期化パターンがない。したがって、方法１１５０は、メイン進入点１１５２に戻って、次の一定同期部分を検索し続ける。
１１７０では、方法１１５０は、状態カウンタを１に設定し（同期シンボルが初めて場所を特定されたことを意味する）、現在の位置Ｌを０にリセットし（これはフレームの開始を示す）、場所が特定される次の一定同期シンボルに関連付けられるべきである、次の動的同期シンボル（すなわち、次の期待動的同期シンボル）を計算する。次の動的同期シンボルは、同期定数に続いて、バス６４からの読み取られたＣＲＣ値に基づいて計算され、決定論的方法を使用して、次の値まで増分される。次いで、方法１１５０は、１１５２へ戻って次の同期化パターンを検索する。したがって、リセットパラメータは真に設定されておらず、方法１１５０は１１５７へ進む。
一定同期部分および一定同期シンボルという用語は、互に類似することに留意されたい。また、動的同期部分および動的同期シンボルという用語が、互に類似することにも留意されたい。
１１７２では、方法１１５０は、単一の同期シンボルのみの場所を特定しているかどうか、または現在の位置が期待フレーム長に合致するかどうかを決定する。この条件が真ではない場合、現在の場所が特定されている一定同期シンボルは無視され、方法１１５０は主要ループ１１５２へ戻るであろう。１１７２でチェックされた条件が真である場合、方法１１５０は１１７３へ進む。
１１７３では、方法１１５０は、現在の検索位置（Ｌ）をゼロに設定する。次いで、方法１１５０は１１７６へ進む。
１１７６では、方法１１５０は、現在場所が特定されている一定同期部分に関連付けられる動的同期部分が、計算された期待動的同期部分に等しいかどうかを決定する。条件が真である場合、方法１１５０は１１７８へ進む。条件が偽である場合には、少なくとも１つのエラーがあり、以前の一定同期部分または現在の一定同期部分のうちの少なくとも１つが無効である。次いで、方法１１５０は、１１８６へ進み、以前の一定同期シンボルが見出された位置を選択して、現在の一定同期シンボルを無視するために、ランダム性を使用するか、または現在の一定同期シンボルが見出されている新しい位置を使用し、（それが合致しないため）以前の位置を無視する。
１１７８では、方法１１５０は、現在のフレーム長Ｌ＿ｏｌｄの値を現在の位置Ｌに設定し、現在の動的同期シンボルの値および決定論的方法に基づいて、次の動的同期シンボルを計算する。次いで、方法１１５０は１１８０へ進む。
１１８０では、方法１１５０は、状態カウンタが最大状態値に等しいかどうかを決定する。例えば、最大状態値は、最大ＣＲＣ指数が１５であるときに７に設定されることができる。別の実施形態では、最大状態値は、１５または何らかの他の整数Ｎであり得る。７の値を使用すること（または可能性として考えられる動的同期部分の数の約半分である値を使用すること）は、同期化を達成する時間と同期化方法のロバスト性との間の妥協である。例えば、１５個の値を伴うＣＲＣカウンタに基づいて、９つのバイナリビットが、一定同期部分に使用され得、誤った同期化条件（すなわち、誤った同期化パターンに基づいて同期化を達成する）の可能性は、ランダムなバストラフィックに基づき、同期化パターンをＮ回検証して、（２−９Ｎ）＊（１５−Ｎ）である。しかしながら、同期シンボルに合致するランダムな静的バストラフィックがある場合、この条件が起こる可能性は、１５−Ｎである。Ｎ＝７の場合については、誤った同期化の可能性は、多くても５．９＊１０−９であるが、通常ははるかに低い。
１１８０での条件が真である場合には、同期化が達成されており、方法１１５０は１１８２へ進み、そこで、ｓｗｅｅｔ＿ｓｐｏｔパラメータは、スレーブデバイス５４がマスタデバイス５２およびバス６４と現在同期していることを示すように１に設定される。このフラグは、内部タイミングを追跡するために、スレーブデバイス５４中の他の論理によって使用され得る。サブフレーム長を求めるために、フレーム長は、３という因数で除算され得る。次いで、方法１１５０は、１１５２へ進んで、同期化を維持するように将来の一定同期部分を検索し続ける。
１１８０での条件が真ではない場合には、同期化がまだ達成されておらず、方法１１５０は１１８４へ進み、そこで、状態カウンタが１だけ増分させられる。次いで、方法１１５０は、１１５２へ進んで、次の一定同期部分を検索し、同期化を達成しようとし続ける。
１１８６では、動的同期部分エラーがあり、したがって、以前に場所が特定された一定同期部分または現在場所が特定されている一定同期部分のうちの少なくとも１つが無効である。次いで、方法１１５０は、状態カウンタが４未満であり、かつパリティが０に等しいかどうかを決定する。状態カウンタが４以上である場合、方法１１５０は、いくつかの一定同期部分の場所を特定することにすでに成功しており、同期化中、単一のエラーは許容されるであろう。しかしながら、方法１１５０は、状態値を減少させることによって、以前に場所が特定された同期位置を低信頼で扱う。１１８６での条件が真ではない場合、ランダム成分（例えば、限定されないがパリティビット）は、方法１１５０が最後の同期位置（例えば、１に等しいパリティ）を有効位置として維持すべきこと、または現在の同期位置（例えば、パリティが０に等しい）を有効位置として保つべきであることを示す。４の値は、実際には、ほぼ、２で除算された最大状態値である、中間状態値であることに留意されたい（本実施例では、最大状態値は７に設定される）。他の実施形態では、他の値を最大状態値および中間状態値に使用することができる。バス６４に接続される物理的状態（すなわち、センサが測定データを提供すること、またはアナログ・デジタル変換器が電圧または電流測定値を提供すること）に何かがある限り、パリティの値がフレームによってランダムとなるように、デジタル化プロセスにより、バス６４上で出現するビットに対してランダム成分が生じるであろう。揺動散逸定理が、散逸を伴う任意のシステムに対する揺動を保証するので、この揺動は、量子物理学によって保証される。したがって、全てのバストラフィックが決定論的状態マシンによって生成されない限り、パリティは真にランダムとなるであろう。さらに、他の実施形態では、フレーム中に伝送される０および１の数がランダムであるため、それが１に等しいかどうかを確認するためにパリティがチェックされることができる。１１８６での条件が真である場合、方法１１５０は１１８８へ進む。１１８６での条件が偽である場合、方法１１５０は１１９０へ進む。
１１８８では、方法１１５０は、以前に場所が特定された一定同期部分を拒絶し、いくつかの変数およびカウンタの値をリセットする。ここで、方法１１５０は、現在の位置をフレームの開始として使用するであろう。フレーム内の現在の位置（Ｌ）、計算されたフレーム長（Ｌ＿ｏｌｄ）、および状態カウンタが全てリセットされる。次の動的同期部分は、バス６４から読み取られた最後の動的同期部分に基づいて、決定論的方法を使用して計算される。これは、フレームについての情報がないと言うことと同等であり、フレームが現在の位置から始まると仮定される。方法１１５０は、始めから同期化プロセスを再開することができるように、１１５２へ進む。
１１９０では、方法１１５０は、以前の場所が特定された同期部分を有効として受け入れ、状態カウンタを減少させる。これは、数回の以前の成功したチェックの後に動的同期部分チェックにおけるエラーに遭遇したため、方法１１５０が以前に示されたように現在の位置において低信頼を有することを示す。次いで、次の動的同期部分の値が、バス６４からちょうど取得された動的同期部分ではなく、決定論的方法、および場所が特定された以前の動的同期部分に基づいて計算される。次いで、方法１１５０は、１１５２へ進んで次の一定同期部分を見出す。
ここで図６１ａを参照すると、欠落した同期化パターンをチェックするために使用し、かつ方法１１５０とともに使用されることができる、同期化方法１２００の例示的実施形態の略図が示されている。
方法１２００は、基本的に、エラーがあって同期が達成されていない場合には、同期化プロセスが始めから再開される必要があると決定する。そうでなければ、エラーが発生する前に同期化が達成された場合には、方法１２００は、状態カウンタを１だけ減少させ、同期化プロセス全体を始めから再開するよりもむしろ、何も起こらなかったかのように次の同期シンボルを検索するであろう。
方法１２００が同期シンボルを期待したが、何も見出されなかったため、現在の位置は、１２０４でゼロにリセットされ、すなわち、方法１２００は、たとえ最後の場所が特定された一定同期部分に、例えば、バス６４上の雑音による、エラーがあったとしても、フレームが現在の位置から始まることを仮定する。これは、クロック信号上の故障ではなく、バス６４上の任意のデータエラーに有効となるであろう。
１２０６では、方法１１５０は、スレーブデバイス５４がマスタデバイス５２とロックしているかどうかを決定する。それがロックしている（ｓｔａｔｅ＝ｍａｘ ｓｔａｔｅ）場合、単一のエラーが許容され、状態値が１２０８で減少させられるであろう。この場合、次の動的同期部分が、間違っていると考えられるバス６４上の現在のＣＲＣ値ではなく、バス６４上の以前のＣＲＣ値に基づいて計算される。次いで、以前のＣＲＣ値が更新される。この値がバス６４上の現在のＣＲＣ値に合致しない場合には、この更新されたＣＲＣは、次の読み取られたＣＲＣ値と比較されるように、もう１度更新される。このスキームは、同期化を依然として維持しながら、単一のＣＲＣエラーを許容する（一定同期部分のみにエラーがあると仮定される）。次いで、方法１１５０は、１２１１へ進み、メイン検索方法１１５０の１１５２に戻る。
１２１０では、１つより多くのエラーがあり、またはスレーブデバイス５４がまだマスタデバイス５２と同期していない。したがって、これらの条件が有効同期化位置には起こらないであろうため、あるパラメータをリセットすることによって、再度、検索方法が再開される。次いで、方法１１５０は、１２１１へ進み、メイン検索方法１１５０の１１５２へ戻る。
ここで図６２を参照すると、方法１１５０とともに使用されることができる、ビットストリームモード同期化方法１２５０の例示的実施形態の略図が示されている。
１２５２では、方法１２５０のインスタンス化が初期化される。方法１２５０への関数呼び出しが、方法１２５０のインスタンス化を引き起こす。
１２５４では、方法１２５０は、パラメータリセットが真に（すなわち、１に）設定されているかどうかを決定する。この条件が真である場合には、これは、ビットストリームモードの仮定の下で同期化パターンを検索するために使用される、パラメータ、カウンタ、および変数の全てが、それらの初期値にリセットされ、よって、方法１２５０が１２５６へ進むことを意味する。そうでなければ、１２５４での条件が偽である場合、方法１２５０は１２５８へ進む。
１２５６では、ビットストリームモードの仮定の下で同期化パターンを検索し、場所を特定し、検証するために使用される、パラメータ、状態、およびカウンタが初期化される。例えば、初期化は、ビットストリームフレームチャネルの現在の仮定された数（Ａ）、チャネルが現在検索されていることを示すチャネルカウンタまたは指数（Ｂ）、検索されているチャネルに対するクロックゲーティングをアクティブにするための全てのチャネルを通したカウンタ（Ｃ）、およびフレーム内の現在の位置（Ｌ）に類似するビットストリームチャネル内の現在の位置（ＤＬ）を定義することを含む。チャネルの最大許容数は、Ａｍａｘによって定義され、１つの実装では１６に等しくあり得る。次いで、方法１２５０は１２５８へ進む。
Ａ、Ｂ、およびＣ変数は、０の値から参照されるため、ビットストリームフレームチャネルの現在の数を８に設定することは、Ａ＝７を意味する。これは、レジスタ空間を節約するように行われる。これらの変数がどのようにして使用されるかを理解するために、Ａｍａｘ＝２であるように、３つの最大数のビットストリームフレームチャネルがあると仮定されたい。次いで、カウンタは、Ａ＝０、Ｂ＝０、Ｃ＝０、およびＤＬ＝１に設定される。これは、現在、１つのビットストリームフレームチャネルがあると仮定され（Ａ＝０）、同期化パターンについて検索されている現在のビットストリームフレームチャネルが第１のビットストリームフレームチャネルであり（Ｂ＝０）、全てのチャネルに目を通すカウンタが第１の位置で始まり（Ｃ＝０）、伝送されたデータ中の開始位置が０である（ＤＬ＝１）ことを意味する。
方法１２５０は、ビットストリームフレーム形式の全ての可能な構造を体系的に経由し、各仮定フレーム形式に対する許容チャネルのうちの任意のもので同期化を取得しようとすることによって稼働する。方法１２５０は、どのビットストリームチャネルがバス６４上で現在伝送されているかを示す、チャネル指数カウンタＣを連続的に増分させるであろう。Ｃがフレーム形式に対して定義されるチャネルの数（Ａ）に等しいとき、それがリセットされ、一般検索方法１１５０は、単一のビットを捕捉し、すなわち、バス６４上の多重化信号から単一のビットを取り出し、これが同期化を含むフレームチャネルに属すると仮定するであろう。同時に、チャネル内の現在のビット位置（ＤＬ）が、１だけ前進させられるであろう。同期化がこのチャネル中で取得されない場合、同期化パターンについて検索される現在のチャネル（Ｂ）が１だけ増分させられる。Ｂが、チャネルの現在の数であるＡに等しい場合、検索が、現在の仮定フレーム形式に対するチャネルの現在の仮定された数について完了し、Ａが１だけ増分させられる。ＡがＡｍａｘに等しい場合、方法１２５０は、全ての形式および全てのチャネルを検索しており、そうでなければ、同期化パターンについて別のチャネルを検索するために、Ｃ、ＤＬ、Ｂ、およびＡが、その特定の順番で増分させられるであろう。
１２５８では、方法１２５０は、方法１２５０の残りのアクションがバス６４のための新しいクロックサイクルで開始するために、以前に説明されたようにクロックと同期化する。同期化は、前述のように、立ち上がり、立ち下がり、または両方のクロックエッジのいずれかで行われることができる。
１２６０では、パラメータｒｅ＿ｓｙｎｃが偽（すなわち、０の論理値）に設定される。これは、メイン検索方法１１５０による検索が途切れずに続行することを表す。このパラメータが真に設定されるとき、現在の検索位置Ｌおよび現在のフレーム長Ｌ＿ｏｌｄは、両方ともゼロにリセットされる。これは、検索されている現在のビットストリームチャネル中でいかなる同期化シンボルも見出されなかった場合に起こる。次いで、方法１２５０は１２６２へ進む。
１２６２では、方法１２５０は、パラメータｂｉｔｓｔｒｅａｍ＿ｍｏｄｅが真（すなわち、１の論理値）に設定されているかどうかを決定する。この条件が真である場合には、方法１２５０は１２６６へ進む。この条件が偽である場合には、何も起こらず、方法１２５０はビットストリーム進入点１２５２へ戻る。これは、全ての変数が明確に定義された状態にあり、これが電流消費も低下させるように行われる。これは、いくつかの実施形態では省略されることができる。１２６２で行われるチェックはまた、代替実施形態では方法１２５０において先に行われ得る。
１２６６では、方法１２５０は、パラメータｓｙｎｃ＿ｂｅｇｉｎが真（すなわち、１）に設定されているかどうかを決定する。この条件が真である場合には、これは、同期化パターンの検索がビットストリームモードの下で最初に始まっていることを意味する。方法１２５０は１２６８へ進み、そこで、カウンタおよびパラメータは、１つだけのビットストリームフレームチャネルがあることを仮定するように、それらの初期値にリセットされ、その場合、同期化パターンの検索は、第１のビットストリームフレームチャネル中の第１のビットから始まる。１２６６での条件が偽である場合には、同期化パターンに対する検索プロセスは、最初から始まっておらず、方法１２５０は１２７０へ進む。
１２７０では、方法１２５０は、現在のアクティブなビットストリームチャネル（Ｃ）が、検索されているビットストリームチャネルの現在の仮定された数（Ａ）に等しくないかどうかを決定する。条件が真である場合には、方法１２５０は１２７２へ進み、その時点で、現在のアクティブなビットストリームチャネルは１だけ増加させられ（すなわち、次のチャネルが検索目的でアクティブである）、方法１２５０は１２５２へ進み、その時点で、現在のアクティブなビットストリームチャネルが、現在調査されているチャネル、すなわち、チャネルＢに等しくなるまで待機することによって、同期化パターンの検索が実行される。
１２７０での条件が偽である場合には、これは、現在アクティブであるビットストリームフレームチャネルが、検索されているチャネルであることを意味する。この場合、メイン検索方法１１５０にとってのクロックが有効にされ、方法１１５０が続行することを可能にするように、論理有効フラグが設定されるであろう。したがって、方法１２５０は１２７４へ進み、その時点で、本方法が、アクティブなチャネルが検索されている次の時間を決定することができるように、再度、アクティブなチャネル（Ｃ）が新たにゼロから開始される。同時に、調査されているフレームチャネル内の位置が、１だけ前進させられる（ＤＬ＝ＤＬ＋１）。これは、メイン検索方法１１５０における現在の位置Ｌの増分に類似する。次いで、１２７４では、方法１２５０は、メイン検索方法１１５０によって、伝送されたデータの１ビットがチェックされることを可能にする。次いで、方法１２５０は１２７６へ進む。
１２７６では、同期化パターンが現在のアクティブなフレームチャネル中で見出された場合には、方法１２５０は１２７８へ進み、その時点で、同期している可能性がある。次いで、１２７８では、現在の位置カウンタは、初期位置、例えば、１２８に初期化されるが、また、何らかの他の値、例えば、０でもあり得る。１２７６で行われる比較は、場所が特定された同期部分が有効同期部分であると決定するために、方法９００および９５０について説明されたものと同一であり得る。パラメータＤＬは、１つの同期シンボルが見出された場合に、方法１２５０がより長時間にわたって検索することを可能にするように、この時点で大きい数に設定され得る。次いで、方法１２５０は、１２５２へ進んで、次のビット中で多重化データストリームから読み取る。しかしながら、１２７６での条件が真ではない場合には、方法１２５０は、進入点１３０２へ進んで、残りのビットストリームフレームチャネルを循環するであろう方法を呼び出す。これは、図６３に関して説明される方法１３００等の別の方法によって達成されることができる。
ここで図６３を参照すると、ビットストリームモード同期化方法１２５０とともに使用されることができる、ビットストリーム更新方法１３００の例示的実施形態の略図が示されている。
１３０２では、方法１３００のインスタンス化が初期化される。方法１３００への関数呼び出しが、方法１３００のインスタンス化を引き起こす。
１３０４では、方法１３００は、現在のビットストリーム開始位置ＤＬが最大位置（最大フレーム長より大きいことと同等である）にあるかどうか、かつａｌｌｏｗ＿ｃｈａｎｇｅｓパラメータが１（すなわち、論理真値）であるかどうかを決定する。この条件が真である場合、これは、検索方法が依然として同期化を達成する必要があることを意味し、方法１３００は１３０６へ移動する。これは、現在のフレームチャネル中で同期化が取得されなかったことを意味する。いくつかの実施形態では、最大位置は、１２７の値であり得る。これは、ＤＬの初期値が１２８に設定され、ラップアラウンドで２進計数が使用された場合に達成される最後の値であるが、他の実施形態では、他の最大値を使用することができる。１３０４での条件が偽である場合、これは、方法１２５０が現在のフレームチャネルをチェックすることを完了していないことを意味する。この場合、方法１３００は、１３１８へ移動し、次いで、ビットストリーム検索方法１２５０に戻って、調査されている現在のフレームチャネルからより多くのビットを読み込む。
１３０６では、ｒｅ＿ｓｙｎｃパラメータが１（すなわち、論理真値）に設定され、パラメータＤＬが０に設定されるが、それを何らかの他の初期値に設定することもできる。これは、同期化パターンが現在のビットストリームフレームチャネル中で見出されず、次のビットストリームフレームチャネルが試行されるべきであることを意味する。パラメータｒｅ＿ｓｙｎｃを１に設定することによって、パラメータＬおよびＬ＿ｏｌｄがメイン検索方法１１５０においてリセットされ、それによって、新しい検索を開始するであろう。次いで、方法１３００は１３０８へ進む。
１３０８では、方法１３００は、調査されている現在のフレームチャネル（Ｂ）がフレームチャネルの仮定された数（Ａ）に等しくないかどうかを決定する。この条件が真である場合、チャネルの現在仮定されている数中の全てのチャネルが調査されたわけではない。次いで、方法１３００は１３１０へ進み、そこで、調査されている現在のフレームチャネル（Ｂ）が１だけ増加させられる。次のフレームチャネルは、１３１８で方法１２５０を呼び出すことによって、同期化パターンについて検索されるであろう。１３０８での条件が偽である場合、方法１３００は、現在の仮定されたフレーム形式を伴う全てのチャネル位置が経由されている。パラメータＡは、フレームチャネルの現在の仮定された数を示す。この場合、仮定チャネルの数（Ａ）は、最終的に１だけ増分させられるであろう。方法１３００は１３１２へ進み、そこで、調査されている現在のフレームチャネルが再初期化され、０に設定される。次いで、新しい仮定された数のチャネル内の第１のビットストリームフレームチャネルが検索されることができる。次いで、方法１３００は１３１４へ進む。
１３１４では、方法１３００は、ビットストリームフレームチャネルの現在仮定されている数（Ａ）が、ビットストリームフレームチャネルの最大許容数（Ａｍａｘ）に等しくないかどうかを決定する。条件が真である場合には、方法１３００は１３２０へ進み、そこで、ビットストリームフレームチャネルの現在仮定されている数が１だけ増加させられ、次いで、方法１３００は、続いて、新たに仮定されたフレーム形式を伴う第１のフレームチャネルを検索し、１３１８で方法１２５０を呼び出す。１３１４での条件が偽である場合、これは、全ての許容ビットストリームフレーム形式の位置の全てが検索されており、同期化パターンが見出されていないことを意味する。次いで、方法１３００は１３１６へ進み、そこで、ビットストリームフレームチャネルの現在仮定されている数が０に設定される。次いで、方法１３００は、フレーム内の現在の位置（Ｌ）およびフレーム長（Ｌ＿ｏｌｄ）を初期化し、動作モードを反転させる（すなわち、ビットストリームモードからワードモードへ）。次いで、方法１３００は、１３１８へ、次いで、検索方法１２５０の１２５２へ進む。ワードモードでは、方法１２５０が依然として作動するが、ビットストリームモードが偽であるため、より低い電力消費を伴う（１２６２での決定を参照）。ビットストリーム方法１２５０およびクロックゲートワードモード方法１１５０を並行して作動させられる（すなわち、遂行または実行される）ことができる。
ここで図６４を参照すると、迅速再同期化方法１３５０の例示的実施形態の略図が示されている。迅速再同期化方法１３５０は、同期化がすでに達成されており、同期化を維持するために同期化方法が依然として使用されているときに使用されることができる。例えば、方法１３５０は、方法１１５０および１２５０と並行して作動させられるか、または実行されることができる。
１３５２では、方法１３５０のインスタンス化が初期化される。方法１３５０への関数呼び出しが、方法１３５０のインスタンス化を引き起こす。
１３５４では、方法１３５０は、リセットパラメータが真に設定されているかどうかを決定する。この条件が真である場合、方法１３５０は１３５６へ進み、その時点で、パラメータａｌｌｏｗ＿ｃｈａｎｇｅｓが１（すなわち、真）に設定される。次いで、方法１３５０は１３５８へ進む。しかしながら、１３５４での条件が真ではない場合には、方法１３５０は１３５８へ進む。
１３５８では、方法１３５０は、方法１３５０の残りのアクションがバス６４のための新しいクロックサイクルで開始するために、以前に説明されたようにクロックと同期化する。
１３６０では、方法１３５０は、状態カウンタの値が最大状態値または最大状態値−１（例えば、６および７に設定されることができる）に等しいかどうか、および同期化パターンの検索がビットストリームモードの下で動作しているかどうかを決定する。これは、同期化において単一のエラーを許容するように現在の状態値を２つの異なる状態値と比較する。これが真である場合には、方法１３５０は１３６２へ進み、そこで、パラメータａｌｌｏｗ＿ｃｈａｎｇｅｓの値は、同期化が達成されており、たとえいくつかのエラーが発生しても現在の状態が維持されるべきであることを意味する、０（すなわち、偽）に設定される。これは、たとえエラーがビットストリームモードで発生しても、同期化方法が即時にロックから外れないであろうことを意味する。この条件は、ａｌｌｏｗ＿ｃｈａｎｇｅｓパラメータによって対象とされ、それに従って作用する（換言すると、同期化方法は、単一のエラーに基づいて、ビットストリームモードであると仮定することから、ワードモードであると仮定することに戻って即時に変化することを可能にされない）。次いで、方法１３５０は、１３５２へ進んで、状態値の任意の変化を監視し続ける。しかしながら、１３６０での条件が偽である場合には、方法１３５０は１３６４へ進む。
１３６４では、方法１３５０は、検索が現在のフレーム長を越えているかどうか、または同期化パターンの検索がワードモードの下で動作しているかどうかを決定する。したがって、１つより多くのエラーが発生している状況を見出すために、または同期化検索方法がワードモードの下で動作していることを見出すために、１３６４での条件を使用することができる。１３６４での条件が偽である場合には、方法１３５０は１３５２へ進む。１３６４での条件が真である場合には、方法１３５０は１３６６へ進み、その時点で、ａｌｌｏｗ＿ｃｈａｎｇｅｓパラメータが１に設定されるため、いかなる同期化シンボルも見出されない場合、（方法１３００の作用１３０４の後に）ＢおよびＡの現在の値が変更され得る。
ここで図６５を参照すると、本明細書で説明される方法１１５０、１２５０、および１３５０と並行して使用されることができる、クロックゲーティング方法１４００の例示的実施形態の略図が示されている。クロックゲーティングまたはクロック有効は、ワードモードで常にバスアクティビティを捕捉するように、および以前に説明されたように、監視されている現在のフレームチャネルがビットストリームモードでアクティブである時間中にのみバスアクティビティを捕捉するように、メイン方法１１５０を制御するために使用される。
１４０２では、方法１４００のインスタンス化が初期化される。方法１４００への関数呼び出しが、方法１４００のインスタンス化を引き起こす。
１４０４では、方法１４００は、リセットパラメータが真に設定されているかどうかを決定する。リセットパラメータは、電源オンリセット信号によって、またはバスコントローラによって開始される制御されたリセットイベント等の外部イベントによってのいずれかで、設定される。この条件が真である場合には、方法１４００は１４０６へ進み、その時点で、ｃｌｏｃｋ＿ｇａｔｅパラメータは、１に設定され、それは、デフォルト条件であり、方法１４００を使用している検索方法においてクロックが有効にされるべきであることを意味する。次いで、方法１４００は１４０８へ進む。１４０４での条件が偽である場合には、方法１４００は１４０８へ直接進む。
１４０８では、方法１４００は、方法１４００の残りのアクションがバス６４のための新しいクロックサイクルで開始するために、以前に説明されたようにクロックと同期化する。
１４１０では、方法１４００は、多重化ビットストリームチャネル（Ｃ）内の現在の位置が、監視されている現在のチャネルに等しいかどうか、または本方法がワードモードで動作しているかどうかを決定する。両方の場合において、クロックは、方法１１５０のために有効にされるべきである。１４１０での条件が偽である場合、方法１４００は１４１４へ進み、その時点で、パラメータｃｌｏｃｋ＿ｇａｔｅは、クロックが無効にされていることを意味する０に設定され、方法１１５０は、次のクロック周期中にアイドル状態であり、バス上の現在のデータを無視する。作用１４１２または１４１４の完了時に、方法１４００は、１４０２へ戻って、動作モード（すなわち、ビットストリームモードまたはワードモード）またはＣおよびＢの値が変化したかどうかをチェックする。これは、ＣおよびＢが全クロックサイクルで値を変化させることができるため、全クロックサイクルで行われる。
また、無線リンクを経由して、本明細書で説明される統一バス通信プロトコルの少なくとも１つの実施形態を使用することも可能である。この場合、無線リンクまたは無線インターフェースをバスと見なすことができる。それは、（例えば、ＲＦ−ＩＤ様リンクまたは無線ドッキングステーション等の高速短距離リンクについて）遅延が低い場合、または通信速度が速すぎず、より長い伝搬距離によって制限されている場合の構成に特に適している。例えば、統一バス通信プロトコルの少なくとも１つの実施形態は、低電力磁気リンクシステムで使用されることができ、マスタデバイスは、変調された搬送波信号を伝送し、単一ワイヤバス実施形態について説明されるものと同一のタイムスロットシステムを利用する。スレーブデバイスは、ＲＦ信号を整流し、図６６に示されるように、クロックおよびデータ信号を導出するために、この整流された信号のエンベロープを「バス信号」として使用するであろう。スレーブデバイスがマスタデバイスに通信し返すために、それは、長距離リンク用の別個の伝送機を使用し得るが、単純な磁気リンクについては、伝送される搬送波信号を単純にロードし得る。単一ワイヤバス事例と同様に、伝送される搬送波信号のローディングは、同一の利点（すなわち、受信機が、伝送された搬送波信号から直接、クロックおよびデータを取り出すことができる）を伴ってマスタデバイスに通信し返すための機構として使用されることができる。さらに、プロトコルおよびハードウェアは、実装することが比較的単純である。搬送波信号の伝送およびローディングは、例えば、マスタデバイスおよびスレーブデバイス中のＰＣＢの一部の上のいくつかの円形巻きとして実装される、２つの小型コイルの使用によって達成されることができる。これらのＰＣＢコイルの間隔および巻き数は、特定の動作周波数へのこれらのコイルの同調のために、巻線の間の固有寄生静電容量を利用するように改良され得る。代替実施形態では、２本の連結された伝送線が、高い動作周波数および高速データ転送のために使用され得る。伝送される搬送波信号は、典型的には、データの帯域幅よりはるかに高い周波数を有し、例えば、４３３ＭＨｚまたは２．４ＧＨｚ搬送波信号が、搬送波として使用されることができ、３．０７２ＭＨｚまたは１９．２０ＭＨｚの周波数が、高品質ステレオオーディオの転送速度として使用されることができる。いくつかの実施形態では、特に、例えば、高解像度ビデオ等の広帯域データが転送され得る場合に、２４または６０ＧＨｚ等のはるかに高い搬送波周波数が使用され得る。これらの信号は、密接に連結された伝送線を通して伝送されることができる。さらに、受信機の所要電力が低い場合、ＲＦ−ＩＤデバイスと比較して類似機能を有効にするが、より高い帯域幅およびさらなる機能性の可能性を伴って、（マスタデバイスから送信された）伝送された搬送波信号からの電力によって、このデバイスに電力供給することが可能である。これは、識別情報の転送、または大量の情報、例えば、ファイル、オーディオ、写真、または動画の転送を可能にする。いくつかの実施形態では、データのより高い帯域幅を可能にするために、所与のクロック遷移後、および次のクロック遷移前に、１つより多くのデータビットが転送され得る。データを暗号化することによって、データの安全な取扱を得ることができる。
本説明の次の節は、１つ以上の利益を達成するように修正が行われている、統一バス通信プロトコルの他の例示的実施形態について議論する。
ここで図６７を参照すると、別様にＳワードとして知られている同期化ワードに使用されることができる、フィールドおよびビット割付の別の例示的実施形態の略図が示されている。このＳワードについては、ＩＲＱＳビット（Ｓ１５）は、第１のビット（または第１のタイムスロット）であり、パリティビット（Ｓ１４）は、ここでは第２のビット（または第２のタイムスロット）であり、ＡＣＫビット（Ｓ０）は、ここでは最後のビット（またはＳワードがバス６４上で伝送される最後のタイムスロット）である。このＳワード形式の残りの部分は、図７に示されるものに類似し、議論されない。
例示的実施形態では、バス６４の電源投入時のＳワードのデフォルト値は、“００１０．１１００．０１１１．１１１０”＝０ｘ２Ｃ７Ｅであり得る。これは、「１１１１」の値を伴う疑似ランダムシーケンスを開始することと同等である。
Ｓワードに対するこの異なる構成を用いると、図４０から４４に示されるもの等の本明細書で説明される例示的フレーム形式の多くが、図６７のＳワード中のビットの異なる順序付けにより、変化するであろうことに留意されたい。
ＩＲＱＳビットの目的は、スレーブデバイスが送信する重要な状態メッセージを有する場合、ＲＥＡＤ、ＷＲＩＴＥ、またはＦＵＮＣＴＩＯＮ動作を延期することである。この状態メッセージは、ＩＲＱＳビットをアクティブにすることによって送信されることができる。いかなるスレーブデバイスもＩＲＱＳビットをアクティブにしていない（本実施例では「１」の論理レベルがアクティブにすることを意味する）場合、またはＩＲＱＳ割り込み機能がＳ１５ ＤＥＬＡＹ ＭＡＳＫによって無効にされる場合、ＲＥＡＤ、ＷＲＩＴＥ、またはＦＵＮＣＴＩＯＮ動作が続行するであろう。割り込みは、スレーブデバイスが「１０」または「１１」に等しい状態レベルを有する場合にアクティブにされる。この割り込みを生成するために、スレーブデバイスは、ＩＲＱＳビットがバス上で伝送されているタイムスロット中に、その状態レジスタのＭＳＢのコンテンツをバス６４上にコピーすることができる。前述のように、表７は、いくつかのコマンド動作（すなわち、ＰＩＮＧ、ＦＵＮＣＴＩＯＮ、ＲＥＡＤ、およびＷＲＩＴＥ）ならびにＩＲＱＳおよびＳＯ ＤＥＬＡＹビットの値の種々の組み合わせについて起こる、フレームアクションを示す。
少なくとも１つの実施形態では、ここでは、割り込みが、図５のＳワードの場合のように、Ｓワードの終わりよりもむしろＳワードの始めに起こり得るため、ＩＲＱＳビットはまた、超低電力モードになるために使用され得る。したがって、図６７のＳワードを用いると、バス６４にアタッチされたデバイスは、フレームの始めに起こる、まさにＳワードの始めにスリープモードになるように構成されることができる。スリープモードになるとき、クロック信号は、無効にされ、クロックラインの値は、静的論理０値または静的論理１値であろう。
少なくとも１つの実施形態では、ＩＲＱＳビットはまた、低電力シャットダウン中にバス６４を起動させるために使用され得る。この場合、クロック信号は、高または低論理値状態にしておかれ、データラインの任意の変化は、クロック信号の動作を再開するであろう（すなわち、クロック信号がもはや静的値で保持されなくなるであろう）。データラインは、クロック信号が状態を変化させてアクティブになるまで駆動されることができる。他の実施形態では、スレーブデバイス５４は、クロックライン自体をアクティブにすることによってバス６４を起動させ得、この場合、マスタデバイス５４は、バスホルダを使用してクロックラインを駆動することによって行うことができる、電力低下モード中、クロックラインを弱駆動された静的状態にしておく。
ＰＡＲビットは、図７のＳワードについて説明されたように計算され、ここでは議論されない。
確認ビットＡＣＫは、以前に説明されたように、すなわち、最後のフレーム中のバストラフィックに基づいて計算される。しかしながら、ここでの違いは、ＡＣＫビットが、ＰＡＲビット後のはるかに後の時間で、バス６４上で伝送されることである。これは、より遅いスレーブデバイスに、そのパリティ計算およびＰＡＲビットとの比較に基づいて、ＡＣＫビットを計算するためのより多くの時間を許容するため、有利である。これの実施例は、ワードモードでの図６７のＳワードへのデータ動作を示す、別の例示的タイミング図である、図６８に示されている。マスタデバイス５２は、ビットＳ１４でパリティ値を書き込み、次いで、スレーブデバイス５４は、パリティ値を計算し、マスタデバイス５２によって計算されるパリティ値に等しい、または等しくない場合に、それぞれ、後にＡＣＫまたはＮＡＣＫ１４タイムスロットで応答する。
代替実施形態では、ＳＥＬＥＣＴ ＧＲＯＵＰ ＡＤＤＲＥＳＳ関数を使用して同時にいくつかのデバイスをプログラムするために、ＡＤＤＲＥＳＳフィールドのアドレス１２−１４が使用され得るように、Ｘワードのフィールドが修正されることができる。次いで、このグループアドレスに割り当てられる全てのデバイスは、単一のＷＲＩＴＥ動作を使用して書き込まれることができ、それは、時間効率を増加させ、バス６４の電力効率を増加させる。グループアドレスは、グループアドレス（ＧＲＯＵＰ）の値を、この例示的実施形態でデバイスがサポートする、バス６４にアタッチされた全てのデバイスへのブロードキャスティングと同等である１５に設定することによって、特定のデバイスに対して無効にされ得る。同様に、デフォルトＧＲＯＵＰアドレスは、デバイスが電源投入時に特定のデバイスサブグループに属さないであろうことを示す、１５であり得る。
少なくともいくつかの実施形態では、ＸワードのＡＤＤＲＥＳＳフィールドに行われることができる別の修正は、アドレスフィールドが、バス６４上の全ての他のデータと比較して逆順に符号化されることである。この場合、Ｘ７がＡＤＤＲＥＳＳビット０であり、Ｘ０がＡＤＤＲＥＳＳビット７（図９ａに示されるＸワードの逆数である）である。この逆順序付けは、ビット７が使用されない場合に、スレーブデバイスがより長い内部アクセス時間を有することを可能にする。この場合、最初の１２８ワードのみが８ビットアドレスモード（１６ビットデータ）でプログラムされることができる。
同様に、逆順序付けがＸワード中のＡＤＤＲＥＳＳビットに使用される、これらの実施形態では、逆順序付けはまた、Ｙワード中の８ビットＡＤＤＲＥＳＳフィールドが、１６ビットアドレスを形成するためにＸワードのＡＤＤＲＥＳＳフィールドと一緒に使用され得る、Ｙワード中のＡＤＤＲＥＳＳビットに対しても使用されることができる。逆順序付けについては、Ｙ１５がビット８であり、Ｙ８がビット１５である。ＡＤＤＲＥＳＳフィールド中のこの逆順序付けは、アドレスビット１５が使用されない場合に、スレーブデバイスがより長い内部アクセス時間を有することを可能にする。換言すると、アドレスにおける値が、ＲＥＡＤ動作において等、スレーブデバイスから要求されるとき、なぜなら、要求されたアドレスが、１６ビットの代わりに１５ビットによって表すことができるアドレス値にある場合、スレーブデバイスは、より多くの応答するための時間を有するであろう。なぜなら、デバイスが、ＸおよびＹワード中のＡＤＤＲＥＳＳフィールドに使用される逆順序付けにより、最初にＬＳＢを受信するからである。次いで、ＭＳＢは、ゼロであると仮定される。この場合、スレーブデバイスは、応答するためのもう１つのクロックサイクルを有するであろう。本実施例では、レジスタマップは、１６ビットアドレスモード（８ビットデータ）で３２ｋバイトに限定される。
ここで図６９ａを参照すると、統一バス通信プロトコルの例示的実施形態に対するマスタデバイスまたはスレーブデバイスに使用されることができる、レジスタの定義の別の実施例が示されている。これらのレジスタは、図１６ａに示されるレジスタレイアウトの代替案である。この例示的実施形態では、第２および第３のレジスタが逆転させられていることが分かる。この配列の利点は、レジスタ用のプログラミングのシーケンスが、１６ビットデータおよび８ビットデータを使用する両方の場合に順次的であることであり、すなわち、わずかに不規則なプログラミングシーケンス、すなわち、ｕｐｄａｔｅ ｒｅｇｉｓｔｅｒ＝｛３，２，４，５，６ ｅｔｃ｝を使用する代わりに、最初にレジスタ２がプログラムされ、次いで、レジスタ３がプログラムされ、次いで、レジスタ４がプログラムされる等である。
別の変化は、図１６ａのＩＲＱＦ ＭＡＳＫフィールドの代わりに、ＤＩＲフィールドが使用され得ることである。ＤＩＲフィールドがゼロであるとき、ポート方向は入力である（すなわち、バス６４からのデータがデバイスに伝送されるであろう）。デバイスからのポートが入力をサポートしない場合、いかなるデータもバス６４から得られず、デバイスが出力を可能にしないであろう。ＤＩＲフィールドが１であるとき、ポート方向は出力である（すなわち、デバイスからのデータがバス６４に転送されるであろう）。ポートが出力をサポートしない場合、いかなるデータもバス６４に書き込まれないであろう。双方向ポートが使用される場合、それは、同時に両方ではなく、入力または出力のいずれかとして使用される。このビットを含むことの利点は、これが、単一のポートを使用して、双方向接続に対するサポートを可能にすることである。いくつかの実施形態では、ＤＩＲビットは、一方向ポートによって無視され得る。
加えて、この例示的実施形態では、ｒｅｇ．０ｘ０５が、ＳＵＢＧＲＯＵＰおよびＲＥＰＥＡＴフィールドに使用される一方で、ｒｅｇ．０ｘ０６は、ＳＹＮＣＨＲＯＮＩＺＥおよびＣＨＡＮＮＥＬ ＬＥＮＧＴＨフィールドに使用される。ここで、ｒｅｇ．０ｘ０７は、ＦＵＴＵＲＥ ＥＸＰＡＮＳＩＯＮフィールドおよびＳＫＩＰフィールドに使用される。ここで、ｒｅｇ．０ｘ０８は、ＦＲＡＭＥ ＳＴＲＵＣＴＵＲＥフィールド（図２９ａおよび２９ｂのＣＯＭＭＡＮＤ ＳＥＰＡＲＡＴＩＯＮフィールドと同一である）に使用される。最終的に、ｒｅｇ．０ｘ０９は、ＰＣＬＫＤフィールドおよびＴＤＭビット列フィールドに使用される。図１６ａ、１６ｂ、２９ａ、および２９ｂのものに類似する名称を有するフィールドは、同一の機能を有し、さらに議論されない。図６９ａの例示的レジスタ定義における追加のレジスタビットの包含の利点は、レジスタのプログラミングがより単純であり、ＲＥＰＥＡＴおよびＳＵＢＧＲＯＵＰのより多くの組み合わせが可能にされることである。
この例示的実施形態では、ＦＵＴＵＲＥ ＥＸＰＡＮＳＩＯＮフィールドは、将来の機能のために保留されている。
この例示的実施形態では、ここで、ＳＵＢＧＲＯＵＰフィールドは、データチャネルを一緒にグループ化することのより多くの組み合わせを可能にする、線形符号化を使用して符号化される。
ＴＤＭビット列フィールドは、列（０−１５）ＴＤＭデータが転送され始めることを示すために、ビットストリームモードで使用される。ＴＤＭデータの開始は、ＳＴＡＲＴフィールドによって定義され、垂直方向に与えられる。ＳＴＡＲＴフィールドは、４行の数で与えられた、データを開始する前にスキップする行数を定義する。コマンドワードの終了は、制御ワードを含まない列においてさえも、依然として基準として使用される。コマンドワードを含まない列に対する任意の位置に書き込むことも可能にされる。例えば、列０（コマンドワードを含む列）において、この例示的実施形態では、コマンドワードＳ、Ｘ、およびＹを含む位置に他のデータを書き込むことは、可能にされない。スレーブデバイス５４は、プログラミングエラーによりバス６４をクラッシュすることを回避するために、これらの位置に対する出力を自動的に無効にするべきである。
この例示的実施形態では、ここで、ＦＲＡＭＥ ＳＴＲＵＣＴＵＲＥフィールドは、前のレジスタに含まれるため、図２９ａに示される以降のレジスタに含まれない。しかしながら、図２９ａに示されるレジスタ表の残りの部分は、この例示的実施形態で使用されることができる。
ここで図６９ｂを参照すると、いくつのチャネルがポートの各反復に対して転送されることができるかという定義が示されている。ＳＵＢＧＲＯＵＰパラメータを変化させることによって、２つ以上のポートからの出力をマージし、それによって、ポート間のデータ伝送の待ち時間を低減させることが可能である。実施例として、２つのポートは、１度に１つのチャネルを伝送することによって、それらの出力をマージすることができる（ＳＵＢＧＲＯＵＰ＝０）。このようにして、バス６４上のサンプルは、全出力サンプルに対して２つのサポートの間で交互することができる。
ここで図６９ｃを参照すると、１つのデバイスグループアドレスに割り当てられたデバイスを有する、システム１５００の例示的実施形態の略図が示されている。システム１５００は、メモリ１５０４と、デジタル信号プロセッサ（ＤＳＰ）１５０６と、マスタデバイス１５０８とを含むベースバンドプロセッサ１５０２を備える。システム１５００はまた、４つのマイクロホン１５１０−１５１６も備える。本実施例では、４つのマイクロホン１５１０−１５１６は、アドレス１２を割り当てられるデバイスグループ１に割り当てられる。
ここで図６９ｄを参照すると、３つのデバイスグループアドレスに割り当てられたデバイスを有する、システム１５５０の例示的実施形態の略図が示されている。システム１５５０は、統一バス通信プロトコルを使用する携帯電話システムの例示的実施形態である。システム１５５０は、例えば、携帯電話またはスマートフォンであり得る。システム１５５０は、ベースバンドプロセッサ１５５２と、ＣＯＤＥＣ１５５４と、ＦＭラジオ１５５６と、右チャネルクラスＤ増幅器１５５８と、左チャネルクラスＤ増幅器１５６０と、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール１５６２と、ＩＲセンサ１５６４と、容量センサ１５６６と、４つのマイクロホン１５６８から１５７４と、２つのバス１５７６および１５７８とを備える。バス１５７６は、要素１５５２から１５６６に連結され、バス１５７８は、要素１５５２、１５５４、および１５６８から１５７４に連結される。本実施例では、バス１５７６および１５７８は、以前に説明されたように、２ワイヤバス実施形態を使用して実装される。さらに、本実施例では、ベースバンドプロセッサ１５５２は、マスタデバイスとしての役割を果たし、他の要素１５５４から１５７４は、スレーブデバイスとしての役割を果たす。多くのデバイスが同一のバスに連結されるとき、容量損失の増加、およびより少ないエネルギー効率が生じるであろうため、システムをよりエネルギー効率的にするために、１つより多くのバスが使用される用途があり得る。加えて、異なるバスは、より低いクロック速度がよりエネルギー効率的である、異なるクロック速度を有することができる。統一バス通信プロトコルの別の側面は、それが、低費用デジタル付属品をシステム１５５０に接続する、バス上で使用され得ることである。さらに、デバイスを別個のバスに接続することによって、クロック速度は、デバイスの全てによって使用される全ての帯域幅の合計に基づいて、もはや決定される必要がなくなり得る。これはまた、電力消費を低減させるはずである。
システム１５５０については、バス１５７８に連結された４つのデジタルマイクロホン１５６８から１５７４に対するデバイスアドレスグループ１、およびバス１５７６に連結されたデバイスのうちのいくつかに対するデバイスアドレスグループ１および２がある。デバイスアドレスグループ１および２は、それぞれ、デバイスアドレス１２および１３に対応する。マイクロホン１５６８から１５７４、右チャネルクラスＤ増幅器１５５８、および左チャネルクラスＤ増幅器１５６０は、デバイスアドレスグループ１に割り当てられる。容量センサ１５６６およびＩＲセンサ１５６４は、第２のバスに対するデバイスグループ２に割り当てられる。前述のように、並行してデバイスをプログラムするように、コマンドを各デバイスアドレスグループ中のデバイスに並行して与えることができ、これは、コードの行を削減し、プログラミングに使用される実行時間をほぼ同量だけ減少させる。この設定は、マスタデバイス１５５２が、ステレオ再生状況を迅速に設定すること、複数のセンサを迅速に制御すること、または全てのマイクロホンの利得を同時に制御することを可能にする。
ここで図７０を参照すると、Ｘワードで設定され得る、関数および対応するビット設定の別の例示的リストが示されている。これらの関数の大部分は、図１１ａに示される関数に類似するが、これらの関数のうちのいくつかの順番が変更され得る。ここでは、類似関数については議論しないが、新しい関数、すなわち、ＳＥＬＥＣＴ ＧＲＯＵＰ ＡＤＤＲＥＳＳおよびＩＮＶＥＲＴ ＡＣＴＩＶＥ ＢＡＮＫ関数について議論する。
ＳＥＬＥＣＴ ＧＲＯＵＰ ＡＤＤＲＥＳＳ関数（Ｘ３：Ｘ０＝００１１）の実行は、代替的なアドレスを任意のデバイスに割り当てるために使用され得る。データフィールド（Ｙ１：Ｙ０）における最小の２つのビットは、実際のアドレスを選択し、１２から１５であり得る（例えば、Ｙ１：Ｙ０＝１０である場合には、グループアドレス１４が選択される）。この例示的実施形態で同時に設定することができる、完全に個々のデバイスアドレスグループの最大数は、３｛１２、１３、および１４｝であるが、これは、代替実施形態では変更されることができる。デフォルトグループアドレスは１５である。
ＳＥＬＥＣＴ ＧＲＯＵＰ ＡＤＤＲＥＳＳ関数は、最初に同一のグループアドレスを有するようにいくつかのデバイスを設定し、その後にポートレジスタを設定することによって、同時にいくつかのデバイスを迅速にプログラムにするために使用されることができる。これらのデバイスは、ＲＥＱＵＥＳＴ ＩＤ関数中にプログラムされるような各自の元のアドレスを使用して、依然としてアドレス指定されることができる。たとえデバイスがこの例示的実施形態で異なるグループアドレスを割り当てられていたとしても、ブロードキャストコマンド（すなわち、デバイスアドレス１５）もまた、依然として機能するであろう。ＳＥＬＥＣＴ ＧＲＯＵＰ ＡＤＤＲＥＳＳ関数は、同時に同一のコマンドを受信することができる、同一または類似デバイスを一緒にグループ化するために使用され得る。例えば、データチャネルをプログラムするとき、同一のタイムスロットを使用するように、受信機および伝送機チャネルの両方をプログラムすることができる。代替的なＤＥＶＩＣＥ ＧＲＯＵＰ ＡＤＤＲＥＳＳを、これらの受信機および伝送機チャネルを伴うデバイスに割り当てることによって、これらのデバイスを同時にプログラムすることが可能である。これは、例えば、複数のスピーカまたは複数のマイクロホン等の複数のデバイスが同時に設定されることを可能にするであろうため、より効率的である。
ＳＥＬＥＣＴ ＧＲＯＵＰ ＡＤＤＲＥＳＳ関数を用いると、デバイスの個々のＤＥＶＩＣＥ ＡＤＤＲＥＳＳフィールドが変更される必要はないが、むしろ、デバイスアドレスのうちのいくつかが、複数のデバイス（すなわち、デバイスの１つ以上のグループ）に割り付けられる。現在のＧＲＯＵＰアドレス（１１がブロードキャストアドレスにデフォルト設定されるであろう）を与える２ビットのみが記憶され得、既存の論理の多くが再利用されることができるため、これを実装するためのゲート総数オーバーヘットが低減させられる。
この例示的実施形態では、デバイスアドレス１２−１５は、現在、ＰＩＮＧ動作中に監視されていない。しかしながら、デバイスアドレス１５が使用されるときにコマンドが全てのデバイスに送信されるため、デバイスアドレス１５は、ＢＲＯＡＤＣＡＳＴ機能を有するようにすでに割り当てられている。これは、デバイスアドレス１２から１４を、デバイスグループアドレスとして使用されるようにしている。特定のデバイスに対しているデバイスグループアドレスを示すために、２ビットレジスタが使用され得る。デバイスグループアドレスが、特定のデバイスに割り当てられる必要はないが、アドレス１５にデフォルト設定されるであろうことに留意されたい。
ここで、デバイスグループアドレスをどのようにして使用するかという実施例が続く。マイクロホンおよびビットストリーム受信機は、両方とも第１のデバイスグループアドレスに割り当てられることができる。次いで、同一のコマンドを使用して、第１のデバイスグループアアドレスに割り当てられたデバイスがプログラムされることができる。次いで、マイクロホンが有効にされることができる。次いで、ビットストリーム受信機が有効にされることができる。これは、これらのデバイスのより速い設定をもたらす。本実施例では、デバイスプログラミングは、コードの行数の約半分を用いて行われることができる。
ＩＮＶＥＲＴ ＡＣＴＩＶＥ ＢＡＮＫ関数（Ｘ３：Ｘ０＝０１００）の実行は、ＣＵＲＲＥＮＴ ＢＡＮＫビットを使用することなく、アクティブなバンクを変更するために使用され得る。これは、代替的なバンクにおいて現在の構成を有する、バス６４にアタッチされた全てのデバイスをプログラムする必要なく、単一のデバイスをプログラムするために有用であり得る。ＬＳＢ（Ｙ０ビット）は、アクティブなバンクを決定するであろう。すなわち、Ｙ０＝‘０’である場合には、アクティブなバンクは、ＰＩＮＧコマンド中に発行されるＣＵＲＲＥＮＴ ＢＡＮＫビットによって決定され、Ｙ０＝‘１’である場合には、アクティブなバンクは、ＣＵＲＲＥＮＴ ＢＡＮＫビットの逆値によって決定される。
本明細書で説明される統一バス通信プロトコルの種々の実施形態はまた、汎用非同期受信機／伝送機（ＵＡＲＴ）コントローラとともに使用することもできる。ＵＡＲＴコントローラは、シリアル通信で使用される。例えば、第１のＵＡＲＴコントローラは、順次的にデータのバイトを１度に１ビット伝送することができ、第２のＵＡＲＴコントローラは、これらのビットを受信し、それらをデータの元のバイトに再構築することができる。このシリアル通信は、同期的または非同期的であり得る。
ＵＡＲＴコントローラを、種々の用途に使用されることができる。例えば、ＵＡＲＴコントローラは、従来のシリアルインターフェースに、Ｂｌｕｅｔｏｏｔｈ（登録商標）インターフェースまたはＢｌｕｅｔｏｏｔｈ（登録商標）モデムに、ＦＭ受信機に、ＷｉＦｉ構成要素（利用帯域幅が異なり得る）に、ＵＳＢ（可変帯域幅）通信に、タッチパッドセンサに、低データレートセンサに、および可変データ入力または出力を有する任意の構成要素に利用されることができる。ＵＡＲＴは、典型的には、リアルタイムシステムにおける有限待ち時間を補償するために、ＦＩＦＯ構造を含む。
典型的なＵＡＲＴコントローラは、クロック信号ピン、ＲＥＡＤコマンドピン、ＷＲＩＴＥコマンドピン、データ（０−７）ピン、およびＩＲＱ割り込みピンを含む、いくつかの入力または出力ピンを有する。場合によっては、データがシリアル形式で転送される場合、これは、４本のピン（ＣＬＯＣＫ、ＴＸ ＤＡＴＡ、ＲＸ ＤＡＴＡ、およびＩＲＱ）に削減されることができる。
典型的には、ＵＡＲＴコントローラが低電力消費を有することが所望される。しかしながら、低電力消費を取得するために、多くのシステムは、アイドル期間中に、クロック信号を、論理低値または論理高値等の静的値に結び付ける。クロック信号上にアクティビティがないと、電力消費は非常に低くあり得る。実際の電力消費は、クロック信号がアクティブであるとき、デューティサイクルによって決定される。これは、使用されるデータ帯域幅によって直接決定される。
実施例として、ＳＬＩＭｂｕｓプロトコルは、クロック信号を連続的に作動させること、または未知の待ち時間を伴ってクロックを再開することを伴う。これは、連続クロック要件、したがって、いかなるデータも損失しないという要件により、ＵＡＲＴコントローラの高い電流消費をもたらす。したがって、ＳＬＩＭｂｕｓプロトコルは、低電力消費およびＵＡＲＴ使用に適していない。
低電力消費を達成するために、別個のワイヤをＵＡＲＴコントローラに使用することができる。これは、本明細書で説明される統一バス通信プロトコルの少なくとも１つの実施形態を使用して、２つの端子の端子総額が達成されることができることを意味する。しかしながら、典型的なＵＡＲＴ構成要素が、さらにいくつかの端子（すなわち、ｃｌｋ、ｄａｔａ＿ｉｎ、ｄａｔａ＿ｏｕｔ、ＩＲＱ等）を有するため、専用バスがＵＡＲＴコントローラに割り付けられた場合でさえも、依然としていくつかの節約がある。
さらに、低電力消費を達成するために、統一バス通信プロトコルの少なくとも１つの実施形態では、バス６４は、クロックアイドルモードで設定され、ＵＡＲＴコントローラ中のバッファがある規定閾値に達すると、起動する。閾値は、典型的には、バッファサイズの０から１００％の間である、特定の値にプログラムされることができる。これの後に、ＵＡＲＴバッファが低くなるか、または空になるまで、いくつかのサンプル、例えば、１〜３つが、全フレーム中で転送される。
いくつかの実施形態では、クロック信号は、等時性データ、および時にはＵＡＲＴデータの両方をサポートするために、２つの周波数値の間で変更されることができ、他の実施形態では、クロック信号は、ＵＡＲＴ ＦＩＦＯが新しいデータを有するまで、完全に停止させられるであろう。
ＵＡＲＴコントローラは、データを折々にのみ伝送するために使用されることができ、これは、システムがアイドルモードまたはスリープモードで動作しているときに起こり得る。データが低頻度で伝送されるとき、クロック周波数を低減させることができ、これは、電力消費を減少させるであろう。さらに、クロック周波数が低減されるとき、帯域幅も低減させられる。しかしながら、より多くのデータが伝送される必要があり得るとき、次いで、クロック周波数を増加させることができ、本システムを低電力モードから引き出すことができる。
このスキームはまた、自動帯域幅制御に使用され得る。この場合、伝送機は、全フレームにおいてＣＵＲＲＥＮＴ ＢＡＮＫビットを変化させることを可能にされる。ＣＵＲＲＥＮＴ ＢＡＮＫビットが高に設定されるとき、マスタデバイス５２は、低に設定されるときより高いクロック周波数を使用することができ、変化が、レジスタの変化と同時に起こり得る。これは、使用され得る帯域幅に応じて、ＵＡＲＴコントローラがバス６４の周波数を動的に制御することを可能にする。ビットストリームモードでは、クロック周波数が固定され得る。
電力消費を削減するために使用され得る、種々の他の方法がある。例えば、外部物理層は、多くの場合、制限因子である。したがって、電力消費を削減する１つの効果的な方法は、複数のバスを使用することである。一実施形態では、ビットストリームマイクロホンは、共通ＤＡＴＡライン上でデータを多重化する代わりに、左右のマイクロホン用の別個のＤＡＴＡラインを使用し得る。こうすることによって、外部電力消費をほぼ半減することができる。なぜなら、クロックラインが周波数の半分で作動することができ、各データラインが単一のマイクロホンからの信号によってのみ駆動されるので、容量損失がより低いからである。一実施形態では、このＭＯＮＯモードへの変更は、右／左端子を第３の状態（例えば、浮動）に設定し、接続を決定するために図１１ｅの回路を利用することによって、決定されることができる。この場合、入力端子が浮動していた場合、マイクロホンは、ＭＯＮＯマイクロホンとして接続されることができる（両方のクロック半周期で新しいデータを駆動する）。この構成は、全ての既存のシステムとの適合性を可能にする。
いくつかの実施形態では、クロック信号は、３レベル変換器等の内部マルチレベルデルタシグマ変換器を駆動するために使用され得、次いで、このマルチビット信号は、選択に応じてＳＴＥＲＥＯまたはＭＯＮＯモードのいずれかで、バス上でデータを伝送する前に、２つのレベルに変換される。ＳＴＥＲＥＯおよびＭＯＮＯインターフェースモードの間の選択は、ピン、レジスタ、またはクロック周波数プログラミングによって決定され得る。マルチビット変換器を使用することの利点は、より低いクロック速度および低い電力消費であり得、それは、２レベル変換器を３レベル変換器と比較すると約２倍であり得、有意な電力削減節約をもたらす。デジタルデルタシグマ変換器または特殊論理が、複数のレベルから２レベルビットストリーム出力に変換するために使用され得る。
本明細書で説明される統一バス通信プロトコルの少なくとも１つの実施形態で使用されることができる、電力消費を削減する別の方法は、システムで何も起こっていないときにアイドル状態になるために、アイドル状態になることができるシステムを可能にすることである。
本明細書で説明される統一バス通信プロトコルの少なくとも１つの実施形態で使用されることができる、電力消費を削減する別の方法は、駆動電圧を低下させることであり、これは、多大な電力消費削減をもたらすことができる。また、全オーディオデータスロットにおいて、２ビットを転送するために、複数の信号電圧、例えば、｛０、０．６、１．２、１．８Ｖ｝を使用することも可能であり得る。
本明細書で説明される統一バス通信プロトコルの少なくとも１つの実施形態で使用されることができる、電力消費を削減する別の方法は、クロック信号をデータと統合することである。この方法は、あまり融通性がないクロッキング、特殊クロック回復回路の潜在的な使用、およびおそらく、バスにアタッチされた全てのデバイスに対する電力の一定消費をもたらし得る。しかしながら、物理層の物理的電力消費が優勢である場合、データを伴うクロック信号の包含（例えば、単一のワイヤ、ならびにクロックおよびデータの８／１０ｂまたは類似符号化を使用して行われることができる）により、有意な電力削減が結果として生じ得る。この場合、電力消費は、１ビットにつき約０．５回の遷移（これは、物理的制約によって決定される）まで削減され得る。それは、８／１０ｂ符号化およびランダムデータについては、１ビットにつき０．６２５回の遷移である。いくつかの実施形態では、オーディオチャネルのみが、８／１０ｂ符号化を使用して符号化され得る。
本明細書で説明される統一バス通信プロトコルの少なくとも１つの実施形態で使用されることができる、低電力消費を達成することが可能であり得る別の方法は、２つのモードでシステムを動作させることである。第１のモードでは、システムの特徴の全てが利用可能であり、第２のモードでは、特徴のうちのいくつかのみが利用可能であり、もはやデバイスをプログラムすることが可能ではない。クロック周波数は、必ずしもこれらの異なるモードの間で変更される必要はない。第２のモードは、第１のモードと比較して、より低い電力消費を有する。
実施例として、現在、いくらかの帯域幅が、制御および同期化に割り付けられており、これは、任意のシナリオで割り付けられる。この情報をバス６４にクロックアウトするために電力を費やす。しかしながら、この帯域幅がもはや使用されなくなる場合、特定のモードでバス６４を設定することによって、より低い電力消費が得られ得る。しかしながら、これは、制御がもはや可能ではなくなり、スレーブデバイスおよびマスタデバイスが制御を再獲得するためにシーケンスを使用し得ることを意味する。制御データを含むシナリオから、制御データがないシナリオへ変更することが可能である。制御データが除去された後に同期化を確保することと、必要であれば、スレーブデバイスまたはマスタデバイスが制御シーケンスを開始できることとを保証することに問題がある。制御が除去される場合、デバイスは同期から外れ得る。例えば、クロックライン上の故障によりエラーが発生する場合、同期化情報が除去されているため、これらのデバイスは同期に戻ることができない場合がある。この問題に対する最も単純な解決策は、バス６４上のデバイスの数を２つのデバイスに限定し、クロック信号が高であるときに一方のデバイスにバス６４を駆動させ、クロック信号が低であるときに他方のデバイスにバス６４を駆動させることである。これは、バス６４上のエラーの場合でさえも、同期化の問題を完全に解決する。
制御データを送信しない実施例を依然として続けると、伝送スレーブデバイス（例えば、マイクロホン）は、統一通信プロトコルの一部として事前に決定されたあるシーケンスをマスタデバイス５２に送信することによって、マスタデバイス５２を起動させ得る。このシーケンスは、受信バッファを使用して、マスタデバイス５２にこのシーケンスをフィルタにかけさせることによって、オーディオデータからマスクされるため、オーディオデータが可聴オーディオ信号に変換される状況がある場合に、このシーケンスは聞き取られない。マスタデバイス５２は、強制的にスレーブデバイス５４を制御モードに戻す必要があり得る。これは、例えば、特定の制御シーケンスを提出し、受信機バッファを使用して、受信機においてオーディオデータからこれを取り除くことによって、限定されないが、クラスＤ増幅器等の受信デバイスを用いて行われ得る。しかしながら、受信機が制御を再獲得することを希望するときに、強制的に制御を戻すことはより困難であり得る。マスタデバイス５２が制御を再獲得することを希望する場合、クロック周波数を異なる値に変更し得るが、これは、いくらか時間がかかるであろう。したがって、このアプローチは、遅くあり得、受信機において特殊なハードウェアを使用し得る。
代替として、別の実施形態では、２つのデバイスが同時にバス６４上で信号伝達し、結果として生じるバス対立を動作モードの変更に至らせ、再度、バス６４上で制御データを伝送し始めるように、物理層が修正され得る。これは、ここで説明されているバスシステムとともに使用され得る。例えば、論理０値が、バス６４上に変化がないことによって信号伝達され、論理１値が、バス６４上の値の変化によって信号伝達される。注意を欲する受信機が、伝送機と同時に伝送することによって、バス６４上で変更を強制し、論理１値のみを伝送することができる。これは、伝送される全ての値が、その以前の値から反転させられることをもたらすであろう。これは、バス対立をもたらさないであろうが、伝送機が複数の伝送エラーを受けるであろう。次いで、伝送機は、限定された少数のエラーの後に、バックオフして伝送を停止するであろう。マスタデバイス５２は、バス６４上の任意の信号遷移の欠如によって、この条件を識別することができるであろう。次いで、全てのデバイスは、動作を初期プログラミングモードに戻して変更し、マスタデバイス５２は、バス６４の制御をもう１度再獲得するであろう。
この例示的実施形態では、スレーブデバイスがバス６４とのロックを失う場合、それは、ビットストリームモードで動作する場合、空の列または列全体、あるいは全ての列にさえも書き込み始めることもあり得る。スレーブデバイスが、現在使用されているフレーム形式に従って、空の列に書き込み始める場合、現在使用されているフレーム形式の空の列中に、なんらかのアクティビティがあるとは考えられないので、マスタデバイス５２は、このアクティビティを検出するであろう。スレーブデバイスが、現在使用されているフレーム形式に従って、すでに利用されている列に書き込み始める場合には、リードバック値が書き込まれた値に対応しないであろうため、エラーが１つ以上のスレーブデバイスに対して結果として生じるであろう。これは、基本的に、全ての１を信号伝達することによって、このスレーブデバイスがモード変更を要求していることをマスタデバイスに伝え、それによって、このスレーブデバイスに異常があること、または注意を必要とすることをマスタデバイスに伝えている。このシナリオでは、通常条件下で、ある数の１を信号伝達することは、可能にされない（例えば、１２７個より多くの連続的な１を伝送すること（それによって、シグマデルタ変換器からの出力に制限を設定すること）、これは、ダイナミックレンジの非常にわずかな（例えば、＜０．０７ｄＢ）低減につながるであろう）。
システムが、互からさらに遠く物理的に離間される物理的構成要素を有するとき、バス直径が増加する。遠く離間される構成要素の実施例は、大型画面ＴＶの使用事例である。例えば、１００インチ１６／９ＨＤＴＶは、８７インチ（２２１ｃｍ）の辺長および４９インチ（１２５ｃｍ）の高さを有する。大型画面ＴＶは、スピーカ出力のビーム形成および多重マイクロホンサポートのためのビーム形成等のある機能性を提供することができる。これは、スレーブデバイス（すなわち、スピーカまたはマイクロホン）の間の大きい物理的距離により、より大きいバス直径をもたらす。アナログ信号伝達スキームを使用して、問題を完全に解決することが可能であるが、場合によっては、デジタルオーディオを遠く離間される構成要素に直接転送できることが有益であり得る。
いくつかの従来の場合において、ＳＬＩＭｂｕｓ通信プロトコルが、いくつかの利点を提供するため使用され得る。例えば、ＳＬＩＭｂｕｓプロトコルは、クロック周期の半分以内に安定化するようにデータに要求する。クロック周期の第２の半分は使用されず、したがって、異なるデバイスの間に重複が発生しないように、クロックの周波数を低減させることが可能である。したがって、より低いクロック周波数を使用することにより、より長いバス半径が使用されることを可能にする。
代替として、これまで説明されている統一バス通信プロトコルの種々の実施形態は、データ間の沈黙のクロック周期の半分を有さない。この解決策は、より低い電力消費およびより高い帯域幅を可能にするが、それは、また、高い帯域幅をサポートするために、クロック遷移後のある時間以内に（典型的には約５ナノ秒以内に）、データがバス６４から除去されるべきことも意味する。これは、データを転送するために両方のクロックエッジを使用する場合、２０ＭＨｚクロックについてバス半径を約３０ｃｍ（設計要件による）に限定する。
しかしながら、本明細書で説明される統一バス通信プロトコルの少なくとも１つの実施形態は、長いバスの半径を可能にするように、ＳＬＩＭｂｕｓ物理層を直接模倣することができる。例えば、偶数の列とともにビットストリームモードを使用し、１つおきの列のみを利用することによって、ＳＬＩＭｂｕｓ駆動モード（Ｄ−Ｚ−Ｄ−Ｚ等）を模倣することが可能である。これは、バス構成要素の物理層を変化させることなく、より長いラインを駆動することができるという利点を有する。しかしながら、不利点は、電力消費がＳＬＩＭｂｕｓプロトコルのものと同程度になることである。さらに、非常に長いバスラインを駆動するために、クロック速度が、伝送ライン影響を回避するように低減させられ、データが安定化するための長い時間があり得る。結果は、長いワイヤ長およびあまり効率的ではない信号伝達による、より低い帯域幅である。
いくつかの実施形態では、同一のＩ／Ｏセルを使用してＳＬＩＭｂｕｓおよび説明された統一プロトコルの両方をサポートするように、同一の物理層が実装され得る。
非常に短いワイヤを用いると、伝送ライン影響に関する問題がない。しかしながら、複数のデバイスを同一のバス６４に接続するとき、別様に２地点間高速接続に使用され得る、整合伝送ラインを利用することが困難であり得る。
これらの問題への解決法は、デバイスの全てが同時に駆動されるわけではない、および／またはデバイスの全てが同一のバスにアタッチされるわけではないように、バス６４に接続されるデバイスに代替のトポロジーを使用することによって、可能にされる。パイプまたはリングトポロジー／構造でデバイスを接続することによって、たとえ個々のリンクが単一の伝送機および受信機のみを有するとしても、全てのデバイスがアクセスされることができる。個々のデバイスの間の距離が、はるかに短くあり得るため、伝送速度は、単一の伝送機および単一の受信機を伴うリンクにとって、はるかに高くあり得る。この構造は、合計して単一の大きい数になる代わりに、いくつかのデバイスの間にタイミングのマージンを効果的に分配する。
ここで図７１を参照すると、デバイスをバスに連結するためにリングまたはパイプトポロジーを使用するシステム１６００の例示的実施形態が示されており、本システムは、統一バス通信プロトコルを使用する。システム１６００の構造は、リングまたはパイプをマルチドロップトポロジーに追加することと同等である（マルチドロップという用語は、多くのデバイスが単一のワイヤにアタッチされることを意味する）。システム１６００は、デバイスの全てを接続するために使用される、２つの異なるバス１６０２および１６０４を含む。バス１６０２および１６０４は、クロック信号を送信するために１本のワイヤが使用されることができ、データ、制御情報、および同期化情報を送信するために別のワイヤが使用されることができる２ワイヤ実施形態を使用して実装される。２ワイヤバスを使用することの利点は、ピン数が削減され得、それによって、費用および空間要件も低減され得ることである。
システム１６００は、バス１６０２を通してスレーブデバイス１６０８から１６１４に接続されるマスタデバイス１６０６を含む。スレーブデバイス１６１４はまた、マスタデバイス１６０６をスレーブデバイス（スピーカ）１６１６から１６２２と接続するように、ハブデバイスの役割も果たす。スピーカ１６１６から１６２２のトポロジーは、スレーブデバイス１６０８から１６１４のトポロジーとは異なることに留意されたい。具体的には、スピーカ１６１６から１６２２は各々、クロックラインを受け取るが、データラインは、スピーカ１６１６から１６２２の各々の間で順次に接続される。したがって、動作時に、マスタデバイス１６０６は、バス１６０２を制御し、この特定の実施例については、スレーブハブデバイス１６１４を通して、スピーカデータを伝送する。次いで、スピーカ１６１６は、スレーブデバイス１６１４からデータを受信する。次いで、スピーカ１６１８は、スピーカ１６１６からデータを受信する。次いで、スピーカ１６２０は、スピーカ１６１８からデータを受信し、次いで、スピーカ１６２２は、スピーカ１６２０からデータを受信する。最終的に、スピーカ１６２２からのデータは、スレーブハブデバイス１６１４に返送されることができる。したがって、バス１６０４に接続される構造は、リング構造である（スピーカ１６２２がスレーブハブデバイス１６１４に接続されない場合には、構造はパイプである）。いくつかの実施形態では、クロック信号は、最初に、ハブデバイスからデータを受信するデバイスに送信され、他の実施形態では、クロック信号は、最初に、データをハブデバイスに送信するデバイスに送信され得る。いずれにしても、スピーカ１６１６から１６２２の間の物理的距離、ならびにスピーカ１６１６とハブデバイス１６１４との間の物理的距離、ならびにスピーカ１６２２とスレーブハブデバイス１６１４との間の物理的距離は、データ伝送をデバイス１６１４から１６２２の各々の間で同期化されることができるように、ほぼ同一に選択される。スピーカ１６１６から１６２２の間、ならびにスピーカ１６１６から１６２２とスレーブハブデバイス１６１４との間で送信することができるデータは、リングトポロジーの場合は完全帰還路を使用して、またはパイプ構造の場合は部分帰還路を使用してのいずれかで、所与のスピーカの温度を示すインピーダンス情報または状態情報であり得る。スレーブハブデバイスから、パイプまたはリングにアタッチされたスレーブデバイスへ伝送されるデータは、典型的には、同期化、状態、およびプログラミング情報、ならびに例えば、オーディオ等のデータである。図７１は、マスタデバイス１６０６からスレーブハブデバイス１６１４へ進むオーディオ情報を示すが、情報の流れは、逆方向でもあり得ることに留意されたい。いくつかの実施形態では、スレーブハブデバイス１６１４は、スピーカまたはマイクロホンと組み合わせられ得る。
ここで図７２を参照すると、デバイスをバス（図示せず）に連結するためにパイプトポロジーを使用する、システム１６５０の例示的実施形態が示されており、システム１６５０は、統一バス通信プロトコルを使用する。システム１６５０は、増幅器１６６２、ならびに抵抗器１６６４および１６６６とともに、スレーブハブデバイス１６５２と、スレーブデバイス１６５４から１６６０とを備える。（デジタル入力）増幅器は、オーディオデータの受信機の実施例にすぎない。
図７２に示されるトポロジーの利点は、ハブデバイス１６５２が単一のクロック信号を取り扱うことである。したがって、たとえ最も外側の構成要素の間の大きい距離により、システム１６５０にかなりの遅延があっても、これらの遅延は、全てのデバイスにわたって分散される。また、スレーブハブデバイス１６５２またはマスタデバイス（図示せず）が、データを伝送するために使用される同一のクロック信号にタイミングが従った情報を受信するので、伝送されるクロック信号と受信されるクロック信号との間に差異があるはずがない。
ここで図７３を参照すると、ハブデバイス（ＨＵＢ）を通して多くのデバイスＡＭＰ１、ＡＭＰ２、ＡＭＰ３、およびＡＭＰ４をバスに連結するためにパイプ制御を使用する、システム１７００の例示的実施形態が示されており、システム１７００は、統一バス通信プロトコルを使用する。この場合、データを２つの異なる方向に転送されることができるため、タイミングがより困難である。データの大部分は、左から右へ伝送されるが、右から左へ伝送される何らかのデータ、典型的には、状態または制御データがある。
また、データが正しい時間にデバイスの全てに伝送されるために、隣接するデバイスの間に遅延があり得ることにも留意されたい。これは、レジスタ設定によって定義されることができるある数のクロック周期、ハブデバイスからのビットストリームデータを遅延させることによって行われることができる。遅延は、データが、正しい時間に両方向へ（ハブデバイスからスレーブデバイスへ、およびスレーブデバイスからハブデバイスへ）進むことを可能にする。パイプトポロジーでは、典型的には、例えば、状態情報が、スレーブデバイスからハブデバイスへ転送され得る。システム１７００では、ハブデバイス（ＨＵＢ）が、ビットストリームチャネル６を１つのサンプルだけ遅延させ、第１のスレーブデバイス（ＡＭＰ１）が、ビットストリームチャネル６を１つのサンプルだけ遅延させ、第２のスレーブデバイス（ＡＭＰ２）が、ビットストリームチャネル４から６を１つのサンプルだけ遅延させ、第３のデバイス（ＡＭＰ２）が、ビットストリームチャネル２から６を１つのサンプルだけ遅延させる。パイプの終点は、いかなるサンプルも遅延させない。この例示的実施形態では、ハブデバイスは、マスタデバイスまたはスレーブデバイスであり得る。
ここで図７４を参照すると、デバイスをバス（図示せず）に連結するために１次元交互リングトポロジーを使用する、システム１７５０の例示的実施形態が示されており、システム１７５０は、統一バス通信プロトコルを使用する。システム１７５０は、ハブデバイス１７５２と、スレーブデバイス１７５４から１７６０と、増幅器１７６２と、抵抗器１７６４および１７６６とを備える。抵抗器１７６４および１７６６は、クロック信号の直列または並列終端として使用される。増幅器１７６２は、デジタル入力オーディオ受信機の実施例である。
システム１８００の利点は、両方向へ（ハブデバイスからスレーブデバイスへ、またはスレーブデバイスからハブデバイスへ）の大量の情報の転送が、より単純であることであるが、ハブデバイスは、クロック信号の伝送部分とび受信部分との間のスキューを補償する必要があり得る。リングトポロジーが、隣接するスレーブデバイスの間でほぼ等しい距離を取得するような方法で使用される（これが行われない場合には、信号が完全に安定化させられないため問題があり得る）ため、このトポロジーは、サウンドバー等の大型パネル上で使用されることができる。代替として、システム１８００は、このクロックスキューを調整するために、スレーブデバイス１４においてクロック信号を利用し得る。
図７４に示される例示的実施形態では、物理的デバイスは、スレーブデバイスの間でほぼ等しい物理的距離を取得するように、異なる方法で番号付けされる。この場合、スレーブデバイス１７５４は、スレーブデバイス１７６０に物理的に隣接し、スレーブデバイス１７６０は、スレーブデバイス１７５６に物理的に隣接し、スレーブデバイス１７５６は、スレーブデバイス１７５８に物理的に隣接する。しかしながら、スレーブデバイス１７５４から１７６０は、それらの間に、ならびにスレーブデバイス１７５４とハブデバイス１７５２との間に、およびスレーブデバイス１７６０とハブデバイス１７５２との間に、ほぼ等しい電気的距離があるように、互に電気的に接続される。デバイスのこの物理的配置の利点は、デバイスの間の電気的距離がほぼ同一であり、それによって、これらのデバイスの間で等しくタイミングのマージンを分配することである。不利点は、より複雑な配線パターンである。デバイスのこの物理的配置はまた、リングトポロジーを利用する他のバス通信プロトコルとともに使用され得る。
ここで図７５を参照すると、デバイスをバス（図示せず）に連結するために２次元リングトポロジーを使用する、システム１８００の例示的実施形態が示されており、システム１８００は、統一バス通信プロトコルを使用する。この例示的実施形態では、ハブデバイスは、スレーブデバイスのリングと接続し、各デバイスの間に約２０〜３０ｃｍがある（他の類似する短い小距離も使用することができる）。データが順次にスレーブデバイスの各々を通って進行するため、データは短い時間内に安定化すべきである。このトポロジーは、個々のスレーブデバイスの間の物理的距離が全体的な物理的距離よりはるかに短い場合に、多くの大型構造をサポートすることを可能にし、たとえデバイスによって対象とされる合計の全体的な物理的距離が極めて大きくあり得たとしても、非常に高い速度を依然として達成することができる。クロック信号が、リング構造の始点または終点のいずれかに供給され得る一方で、クロック信号の終端は、リング構造の反対側の端で起こり得る。
図７５のトポロジーを使用する少なくともいくつかの実施形態では、可能な限り最高の伝送スピードを取得するために整合伝送ラインを使用して、クロックおよび／またはデータラインが実装され得る。このアプローチの不利点は、整合目的で、これらのデバイスの伝送機における慎重に調整された出力インピーダンスおよび受信機の入力インピーダンス、ならびにＰＣＢ上の比較的広い物理的空間である。さらに、帯域幅の使用量が非常に高くない限り、この解決策は、他の伝送の方法と比較して過剰な電力消費をもたらすであろう。しかしながら、この解決策は、伝送ライン影響が無視される技法よりもはるかに大きい帯域幅を提供する。
ここで図７６を参照すると、多くのデバイスをバスに連結するためにパイプ制御を使用する、システム１９００の別の例示的実施形態が示されており、システム１９００は、統一バス通信プロトコルを使用する。ここで、タイミングは、データが左から右へ転送されるのみであるため、（図７３の構造と比較して）より単純である。このトポロジーは、パイプトポロジーより大きい帯域幅を有するが、伝送されるクロック信号と受信されるクロック信号との間にいくらかのクロックスキューがあり得るため、ハブデバイスまたはマスタデバイスの受信セクションで追加の処理を使用し得る。パイプリング構造の両方で全てのスレーブデバイスをプログラムし、データをスレーブデバイスの全てに転送することが可能である。両方の構造が、ビーム形成スピーカアレイを作成するために使用され得る。これらの構造はまた、マイクロホンアレイを作成するために使用され得る。この場合、パイプの始めの代わりに、パイプの終わりが、最大帯域幅のためにハブに接続されることができる。このトポロジーはまた、他の信号転送の方法とともに使用することもできる。
通常のシナリオでは、情報の転送がある時間を定義するために、バスクロックエッジが使用される。しかしながら、クロック信号の遷移の数を削減することが可能であり、これは、クロック受信機中の内部クロック乗算器を使用すること、またはクロックおよびデータ信号を組み合わせることを伴い得る。理論的な場合において、平均で全クロックエッジ中の時間の５０％を変化させるデータ信号を制御する、連続クロック信号の場合と比較して、外部電力消費が３倍も削減され得る。しかしながら、入力クロック信号を受信した後にロックを獲得するために、ＰＬＬがいくらかの時間を要するであろうため、デバイスがバス上でオーディオデータの伝送を可能にするためにより長い時間がかかり得、１つのロック条件から別のロック条件へ変化するために、ＰＬＬがいくらかの有限時間を要するであろうため、１つのクロック周波数から別のクロック周波数へ変化するときに、いくつかの制限があり得る。さらに、オーバークロッキングをサポートしないデバイスを含む、任意のデバイスがバス６４にロックすることを可能にするために、（マスタデバイス５２は、クロックエッジの直前に、または代替として、クロックエッジ後のデータの最初の部分で、フレームのデータの最後の部分中で信号を送信し得る（両方のクロックエッジがこの目的で利用されることができるから）。このシナリオでは、マスタデバイス５２は、いかなる他のデバイスもこのタイムスロットの他の部分を利用することを可能にしないことによって、タイムスロット全体を制御し得る。このタイミングは、バス６４にロックされたデバイスが、ちょうど伝送されたフレーム中のＳ、Ｘ、およびＹ情報を読み取り、それに応答することを可能にする。このスキームは、スレーブデバイスとマスタデバイス５２との間でデータを転送するために使用されるが、通常、このオーバークロッキングモードでのタイミング制約により、２つのスレーブデバイスの間でデータを転送するためには使用されないであろう。マスタデバイス５２およびスレーブデバイス５４の両方は、ジッタを低減させるために、内部同期分割器を使用し得る。スレーブデバイス中の内部ＰＬＬは、レジスタマップ中のビットをリセットすることによって、オーバークロッキングが使用されない場合、無効にされ得る。さらに、オーバークロッキング動作モードでは、ＰＬＬジッタによる間違った読み取りを回避するために、バス衝突を回避するために、および電力消費の増加を回避するために、いくらかの空間がオーバクロックデータと固有のジッタとの間に追加される必要があり得るため、合計の可能帯域幅は、通常、オーバークロッキングの使用がない場合よりも低い。
ここで図７７ａを参照すると、２Ｘオーバークロックデータスロットが使用される（すなわち、２というオーバークロッキング因数がある）ときの実施例のタイミング図が示されている。これは、半分のデータを送信するのみである、図４ａに示されるタイミングと対照的である。図７７ａに示されるタイミングを用いると、クロック遷移があるとき、データの１ビットのみよりもむしろ２ビットが送信される。したがって、例えば、図４ａに示されるスキームと同量のデータを送信するために、それほど多くないクロック遷移が使用されるため、節電がある。図７７ａは、データが立ち上がりクロックエッジおよび立ち下がりクロックエッジの両方の上で送信されるため、単一のクロックサイクルについて４つのデータサンプリングイベントがあることを示す。
図７７ａはまた、マスタデバイス５２によって使用されるクロックとスレーブデバイス５４によって使用されるクロックとの間に、どのようにジッタがあり得るかも示す。このジッタは、有効データが示されるようにバス６４上で伝送されない、ある期間に変換される、スレーブデバイスによって使用されるクロック信号の影付き領域として示されている。本実施例は、マスタデバイス５２から書き込まれた１つだけのデータビットを示し、他の場合において、マスタデバイス５２は、他のタイムスロットに書き込むことも可能であり得る。ＰＬＬの有限ロックイン範囲により、このスキームは、典型的には、このスキームが利用されないときよりもはるかに狭い周波数範囲で使用され得る。一般に、クロック信号を用いることなくロックを達成することが可能ではないため、このスキームは、連続クロック信号を使用する。
ここで図７７ｂを参照すると、オーバークロックデータスロットを利用するデバイスに使用され得る、タイミングパラメータ値の例示的実施形態を示す表が示されている。４倍のオーバークロッキングは、半分のクロック周期につき（２つの代わりに）４つのデータスロットを使用して行われ得、６倍のオーバークロッキングは、半分のクロック周期ごとに６つのデータビットを伝送することによって行われ得る。５ナノ秒より長い、出力を無効にする時間（ＴＤＺ）、および９ナノ秒未満である、出力を有効にする時間（ＴＺＤ）を有することのみが可能である場合には、出力電流は、違反期間中に１ｍＡ未満となるべきであることに留意されたい（図７７ｂの＊を参照）。データの任意の重複が、望ましくない電力消費の増加につながるであろう。また、ＰＬＬのＶＣＯ範囲は、内部デバイスタイミングイベントによって必要とされる場合、整数の因数だけより高くあり得る（図７７ｂの＋を参照）。
ここで、いくつかのオーバークロッキング実施例の実際のタイミングについて議論する。８．２ＭＨｚクロックを使用する２Ｘオーバークロッキングについては、設定時間は、方程式１によって与えられる。
ＴＳＥＴＵＰ＝ＴＣＬＫＭＩＮ／２−ＴＺＤ−ＴＣＬＫＳＫＥＷ（ＷＲＩＴＥ）−ＴＣＬＫＳＫＥＷ（ＲＥＡＤ）−ＴＰＣＢ−ＴＳＬＪＩＴＴＥＲ−ＴＭＳＪＩＴＴＥＲ−ＴＤＬＹ （１）
＝（７０／２−１６−２−２−２−４−１−４）ナノ秒＝４ナノ秒、マージン２ナノ秒
ホールド時間は、方程式２によって与えられる。
ＴＳＥＴＵＰ＝ＴＣＬＫＭＩＮ／２−ＴＺＤ−ＴＣＬＫＳＫＥＷ（ＷＲＩＴＥ）−ＴＣＬＫＳＫＥＷ（ＲＥＡＤ）−ＴＰＣＢ−ＴＳＬＪＩＴＴＥＲ−ＴＭＳＪＩＴＴＥＲ−ＴＤＬＹ （１）
＝（７０／２−１６−２−２−２−４−１−４）ナノ秒＝４ナノ秒、マージン２ナノ秒
ホールド時間は、方程式２によって与えられる。
ＴＨＯＬＤ＝ＴＺＤ−ＴＣＬＫＳＫＥＷ＋ＴＰＣＢ−ＴＳＬＪＩＴＴＥＲ−ＴＭＳＪＩＴＴＥＲ＋ＴＤＬＹ （２）
＝（９−２−４−１＋２）ナノ秒＝４ナノ秒、マージン３ナノ秒
バス対立時間は、方程式３によって与えられる。
＝（９−２−４−１＋２）ナノ秒＝４ナノ秒、マージン３ナノ秒
バス対立時間は、方程式３によって与えられる。
ＴＢＵＳ ＣＯＮＦＬＩＣＴ＝ＴＺＤ＋ＴＳＬＪＩＴＴＥＲ（ＭＩＮ）−ＴＤＺ（ＭＡＸ）−ＴＳＬＪＩＴＴＥＲ（ＭＡＸ） （３）
＝（９−２−５−２）ナノ秒＝０ナノ秒（≧０）
８．２ＭＨｚクロックを使用する４Ｘオーバークロッキングについては、設定時間は、方程式４によって与えられる。
ＴＳＥＴＵＰ＝ＴＣＬＫＭＩＮ／４−ＴＺＤ−ＴＣＬＫＳＫＥＷ（ＷＲＩＴＥ）−ＴＣＬＫＳＫＥＷ（ＲＥＡＤ）−ＴＰＣＢ−ＴＳＬＪＩＴＴＥＲ−ＴＭＳＪＩＴＴＥＲ−ＴＤＬＹ（４）
＝（１４０／４−１６−２−２−２−４−１−４）ナノ秒＝４ナノ秒、マージン２ナノ秒
ホールド時間は、方程式５によって与えられる。
＝（９−２−５−２）ナノ秒＝０ナノ秒（≧０）
８．２ＭＨｚクロックを使用する４Ｘオーバークロッキングについては、設定時間は、方程式４によって与えられる。
ＴＳＥＴＵＰ＝ＴＣＬＫＭＩＮ／４−ＴＺＤ−ＴＣＬＫＳＫＥＷ（ＷＲＩＴＥ）−ＴＣＬＫＳＫＥＷ（ＲＥＡＤ）−ＴＰＣＢ−ＴＳＬＪＩＴＴＥＲ−ＴＭＳＪＩＴＴＥＲ−ＴＤＬＹ（４）
＝（１４０／４−１６−２−２−２−４−１−４）ナノ秒＝４ナノ秒、マージン２ナノ秒
ホールド時間は、方程式５によって与えられる。
ＴＨＯＬＤ＝ＴＺＤ−ＴＣＬＫＳＫＥＷ＋ＴＰＣＢ−ＴＳＬＪＩＴＴＥＲ−ＴＭＳＪＩＴＴＥＲ＋ＴＤＬＹ （５）
＝（９−２−４−１＋２）ナノ秒＝４ナノ秒、マージン３ナノ秒
８．２ＭＨｚクロックを使用する６Ｘオーバークロッキングについては、設定時間は、方程式６によって与えられる。
ＴＳＥＴＵＰ＝ＴＣＬＫＭＩＮ／６−ＴＺＤ−ＴＣＬＫＳＫＥＷ（ＷＲＩＴＥ）−ＴＣＬＫＳＫＥＷ（ＲＥＡＤ）−ＴＰＣＢ−ＴＳＬＪＩＴＴＥＲ−ＴＭＳＪＩＴＴＥＲ−ＴＤＬＹ （６）
＝（２０４／６−１６−２−２−２−４−１−４）ナノ秒＝４ナノ秒、マージン２ナノ秒
ホールド時間は、方程式７によって与えられる。
＝（９−２−４−１＋２）ナノ秒＝４ナノ秒、マージン３ナノ秒
８．２ＭＨｚクロックを使用する６Ｘオーバークロッキングについては、設定時間は、方程式６によって与えられる。
ＴＳＥＴＵＰ＝ＴＣＬＫＭＩＮ／６−ＴＺＤ−ＴＣＬＫＳＫＥＷ（ＷＲＩＴＥ）−ＴＣＬＫＳＫＥＷ（ＲＥＡＤ）−ＴＰＣＢ−ＴＳＬＪＩＴＴＥＲ−ＴＭＳＪＩＴＴＥＲ−ＴＤＬＹ （６）
＝（２０４／６−１６−２−２−２−４−１−４）ナノ秒＝４ナノ秒、マージン２ナノ秒
ホールド時間は、方程式７によって与えられる。
ＴＨＯＬＤ＝ＴＺＤ−ＴＣＬＫＳＫＥＷ＋ＴＰＣＢ−ＴＳＬＪＩＴＴＥＲ−ＴＭＳＪＩＴＴＥＲ＋ＴＤＬＹ （７）
＝（９−２−４−１＋２）ナノ秒＝４ナノ秒、マージン３ナノ秒
前述のように、バス６４にアタッチされるデバイスのうちのいくつかが、オーバークロッキングをサポートし、バス６４にアタッチされるデバイスのうちのいくつかがサポートしない場合には、バス衝突のリスクがある。オーバークロッキングをサポートしないデバイスは、データスロット全体（バスクロック周期の半分）を占有し得る。他のデバイスがこのスロットの一部をすでに占有している場合、バス衝突が１つ以上のデバイスによって報告されるであろう。マスタデバイス５２が、クロックエッジの前の最初または最後のスロットを利用しているであろうため、オーバークロッキングをサポートしないデバイスは、多くの状況下でバス６４とロックすることができる。したがって、マスタデバイス５２からの全てのＲＥＡＤ動作が正しいはずである。これは、マスタデータスロットがバス６４上のクロックエッジの前の最後のスロットである、２倍のオーバークロッキングの実施例について、図７７ｃで見ることができる。
＝（９−２−４−１＋２）ナノ秒＝４ナノ秒、マージン３ナノ秒
前述のように、バス６４にアタッチされるデバイスのうちのいくつかが、オーバークロッキングをサポートし、バス６４にアタッチされるデバイスのうちのいくつかがサポートしない場合には、バス衝突のリスクがある。オーバークロッキングをサポートしないデバイスは、データスロット全体（バスクロック周期の半分）を占有し得る。他のデバイスがこのスロットの一部をすでに占有している場合、バス衝突が１つ以上のデバイスによって報告されるであろう。マスタデバイス５２が、クロックエッジの前の最初または最後のスロットを利用しているであろうため、オーバークロッキングをサポートしないデバイスは、多くの状況下でバス６４とロックすることができる。したがって、マスタデバイス５２からの全てのＲＥＡＤ動作が正しいはずである。これは、マスタデータスロットがバス６４上のクロックエッジの前の最後のスロットである、２倍のオーバークロッキングの実施例について、図７７ｃで見ることができる。
ここで図７７ｄを参照すると、オーバークロッキングを実装するために使用されることができる、レジスタ値の実施例が示されている。また、各オーバークロッキングレートを用いて達成され得る、推定節電も示されている。
ここで図７８ａを参照すると、１度にデータの複数のビットを送信するためのタイミングおよび電圧レベルスキームが示されている。本実施例では、２つの電圧レベルの代わりに、使用される４つの電圧レベルがある。４つの電圧レベルは、タイムスロット（すなわち、データスロット）につき２つのデータビットを送信するために使用されることができ、これは、より多くのデータが所与の期間で送信されるため、より高い帯域幅を可能にする。この多重電圧レベルデータスキームはまた、同量のデータを送信するためにより低いクロックレートを使用することができるため、より低い電力消費も可能にする。しかしながら、多重電圧レベルデータスキームは、２電圧レベルデータスキームよりも電磁干渉（ＥＭＩ）に敏感である。
例えば、１．８ボルト電力供給があると仮定して、２電圧レベルデータスキームでは、データを伝送するために０Ｖおよび１．８Ｖの電圧を使用することができ、これは、０．９Ｖの雑音マージンがあることを意味する。４電圧レベルデータスキームを用いると、０Ｖ、０．６Ｖ、１．２Ｖ、および１．８Ｖの電圧が異なる電圧レベルに使用されることができ、これは、０．３Ｖの雑音マージンがあることを意味する。４電圧レベルの場合、０Ｖは「００」を表すことができ、０．６Ｖは「０１」を表すことができ、１．２Ｖは「１０」を表すことができ、１．８Ｖは「１１」を表すことができる。マルチレベル信号伝達が使用されるとき、単一のデバイスのみが１つより多くのビットを決定することができるという点で、軽微な制限があることに留意されたい。したがって、１つより多くのデバイスが書き込むことを望み得る、任意のスロット（例えば、確認または割り込みビット）について、このデータスロットは、マルチレベルではなく２電圧レベル信号伝達を使用する必要があろう。
ここで図７８ｂを参照すると、オーバークロッキングモードを使用して、デバイスがデータスロット中で複数のパックされたビットを送信する（すなわち、マルチレベル信号伝達）ときに使用されることができる、例示的符号化の表が示されている。この場合、受信デバイスは、それに従ってビットを解釈するように構成されるであろう。この符号化は、バス６４上での伝送の数を最小化し、それによって、電力消費を最小化するであろう。実施例として（データスロットにつき６ビットを仮定して）、グループ中のバイナリワードの一部がＢ１７−Ｂ１２＝”１１１００１”を有する場合には、図７８ｂに示される符号化スキームを使用して、“１００１０１”が伝送されるであろう。別の実施例として、バイナリストリームの一部が“１０１０１１”である場合には、図７８ｂに示される符号化スキームを使用して、“１００００１”が伝送されるであろう。符号化されたデータ（例えば、マイクロホンからのビットストリーム）が、そのようなシステム（例えば、通常の範囲内で動作するデルタシグマ変換器）からの典型的な出力に一致する限り、このスキームは、遷移の数を削減し、それによって、電力消費を削減する。
システムは、異なるレベルの電力消費制御を達成するために、以下の動作モードまたは動作の変化の種々の組み合わせを有するように構成されることができる。
通常の動作モードは、デフォルト動作モードとして設定され得る。このモードでは、マスタデバイス５２は、バス６４が有効にされて作動しているように、ある値をプログラムし得る。これを達成するために、マスタデバイス５２は、「０００００」に等しくない値をＭＣＬＫＤフィールドにプログラムし得る。ここで、バス６４が有効にされ、作動する。
少なくとも１つの実施形態では、マスタデバイス５２は、「０００００」等のある値を、例えば、ＭＣＬＫＤフィールドにプログラムすることによって、バス６４を無効にし得る。逆に、マスタデバイス５２はまた、（「０００００」がバス６４を無効にするために使用されるときに）「０００００」以外の何か等のある値を、例えば、ＭＣＬＫＤフィールドにプログラムすることによって、バス６４を起動させ得る。
電力消費を改変するために、バスクロック構成に行われる変更があり得る。例えば、少なくとも１つの実施形態では、マスタクロック分割フィールドＭＣＬＫＤに記憶された値を変更することによって、バス６４の動作周波数を切り替えることが可能である。場合によっては、個々のデバイスポート用のクロック分割器（ＰＣＬＫＤフィールドを参照）もまた、同時に変更される必要があり得る。両方の動作が、非アクティブフィールドＢＡＮＫ中の情報を変更するべきである。全てのデバイスが設定されているとき、動作モードを変更するために、同一の更新されたＣＵＲＲＥＮＴ ＢＡＮＫフィールドを伴う２つのＰＩＮＧ動作が使用され得る。
電力消費を改変するために、バスモード構成に行われる変更があり得る。例えば、ＢＡＮＫフィールドの値の変更中に、フレーム中の列数を変更することが可能であり得る（ＦＲＡＭＥ ＳＴＲＵＣＴＵＲＥフィールドを参照）。これは、帯域幅の動的制御を可能にする。次いで、ＣＯＬＵＭＮ ＷＩＤＴＨフィールドが、非アクティブＢＡＮＫフィールド中で、バス６４にアタッチされた全てのデバイスにおいて変更され得る。この動作が完了したとき、以前の非アクティブＢＡＮＫフィールドに対応する新しいＢＡＮＫ数を伴う２つのＰＩＮＧフレーム（すなわち、動作）を提出することによって、ＣＵＲＲＥＮＴ ＢＡＮＫフィールドが変更され得る。
別の動作モードは、（ＰＩＮＧ動作中に）ＲＥＱＵＥＳＴ ＢＡＮＫ ＣＨＡＮＧＥフィールドをアクティブにすることによって、デバイスがより多くの帯域幅を要求し得る、デバイスＢＡＮＤＷＩＤＴＨ ＣＯＮＴＲＯＬモードである。マスタデバイス５２が、すでにＥＮＡＢＬＥ ＭＯＤＥ ＣＨＡＮＧＥＳフィールドを１に設定している場合、ＢＡＮＫフィールドが次のＰＩＮＧ動作中に変化するであろう。本実施形態では、これは、（ＰＩＮＧ動作中の）ＲＥＱＵＥＳＴ ＢＡＮＫ ＣＨＡＮＧＥフィールドおよびＥＮＡＢＬＥ ＭＯＤＥ ＣＨＡＮＧＥＳフィールドが両方とも１に設定されている限り、継続するであろう。マスタデバイス５２は、元のバンク選択より多くの帯域幅を可能にするように第２のバンクを構成することによって、より多くの帯域幅を可能にし得る。他の実施形態では、デバイスが、電力消費を節約するために、より少ない帯域幅を要求し得る。
別の動作モードは、ＤＥＶＩＣＥ ＡＣＴＩＶＡＴＥＤ ＷＡＫＥ ＵＰ ＦＲＯＭ ＢＵＳ ＳＬＥＥＰモードであり、このモードにおいて、マスタデバイス５２がバス６４へのクロックをオフにしたか、または無効にした後、任意のデバイスが、ＤＡＴＡラインのレベルを変更することにより割り込みを開始することによって、バス６４を起動させることができる。この場合、バス６４が無効にされているとき、それは、３状態モードで保たれ得るが、スレーブデバイスのうちの少なくとも１つがバス起動を開始することができるように、弱い駆動でバスホルダによって駆動され得る。スレーブデバイス５４がデバイス起動を開始するとき、割り込みがマスタデバイス５２に送信され、次いで、マスタデバイス５２は、バス６４に対するクロックを再度アクティブにし始めるであろう。この場合、バス６４は、マスタデバイス５２への入力の役割を果たす。加えて、この場合、バス６４にアタッチされたデバイスの全てが、他の手段によって低電力モードにプログラムされていない限り、起動するであろう。マスタデバイス５２のクロックの電源が切られているか、または単に無効にされているかどうかが不明であるため、この特定の動作のために低遅延を達成することが可能ではない場合がある。具体的には、マスタデバイス５２の電源が切られている場合、発振器で使用される水晶のＱ値に応じて、マスタデバイス５２の主要発振器が再度通常レベルで作動する前に、数千のクロック周期を要し得る。
別の動作モードは、ＭＡＳＴＥＲ ＩＮＩＴＩＡＴＥＤ ＤＥＶＩＣＥ ＷＡＫＥ ＵＰ ＦＲＯＭ ＳＬＥＥＰモードである。非常に低い電力消費のために、デバイスの全てではないにしてもほとんどが、無効にされたそれらのポートを有し得、バス６４が停止させられ得る。しかしながら、それは、通常、バス６４にアタッチされる残りのデバイスと依然として通信することができる一方で、バス６４にアタッチされたいくつかのデバイスに対する電力消費を最小限まで選択的に削減できることは、便利である。これを達成するために、特別な状態（その場合、スレーブデバイスは、フレームを折々のみ監視し、バス６４上の他のトラフィックの全てを破棄するであろう）にスレーブデバイスを設定するために、ＦＵＮＣＴＩＯＮ ＳＥＴ ＰＯＷＥＲ（「０００１」および「００１０」、部分シャットダウン）によって開始される、ＳＬＥＥＰモードが使用され得る（図７９参照）。無視されるであろうフレームの数は、１５個または２５５個のフレームのいずれかであり得、その後に、１つのフレームが監視されるであろう。これらの数は、起こった１６回または２５６回のクロックサイクルを検出することが容易であるため、および両方とも１５で割り切れるため、選択されている。したがって、待機期間は、任意の数のＭ＝Ｎ＊Ｌフレームであり得、Ｎは、正の整数であり、Ｌは、使用される同期化コードの異なる数に基づいて選択され、Ｌは、この例示的実施形態では１５である。この技法では、スリープ状態であるデバイスの内側の疑似ランダムカウンタは、たとえ多数のフレームがスキップされていたとしても、依然として次のフレームに合致するであろう。例えば、依然としてマスタデバイスと同期したままである一方で、電力消費を削減するために１５＊Ｎフレームを無視するスレーブデバイスを示す、図７９を参照されたい。正しく実装されると、このモードが、１ＭＨｚのバスクロック速度で１ｕＡ未満の内部電力消費をもたらし得る一方で、（容量性ローディングによる）外部電力消費は、１桁大きくあり得る。電力消費をさらに低減させるために、バスクロック周波数は、１００ｋＨｚ以下に設定され得る。この動作モードで、マスタデバイス５２は、スリープ状態であるデバイスに通信し返す方法として、ＰＩＮＧ動作を活発に使用し得る。ＤＥＶＩＣＥ ＳＴＡＴＵＳフィールドに書き込むことによって（デフォルト値はゼロであり得る）、マスタデバイス５２は、１（すなわち、高論理値）に等しい最上位ビットを設定することができる。最上位ビットが１に等しい場合、デバイスが再度、起動するべきである一方で、それがゼロである場合、デバイスは、この例示的実施形態では低電力モードを維持するべきである。デバイスがスリープ状態であり、Ｎ＊１５フレームごとにバス６４上のデータをチェックしているのみであるため、次いで、マスタデバイス５２は、デバイスが実際に起動するまで、Ｎ＊１５フレームのためのデバイス起動コマンドを繰り返し送信する必要があり得る。
別の動作モードは、ＤＥＶＩＣＥ ＩＮＩＴＩＡＴＥＤ ＷＡＫＥＵＰ ＦＲＯＭ ＳＬＥＥＰモードである。このモードは、電源を切った後にデータ転送のための低遅延を必要とするデバイスに使用され得る。典型的なシナリオの実施例は、データを待っており、突然、その内部バッファが、データによって迅速に満たされているＵＡＲＴデバイスである。したがって、ＵＡＲＴデバイスは、送信すべき多くのデータを有し得るが、マスタデバイス５２が、電力消費を削減するようにバス６４を非アクティブに設定していることがある。水晶発振器が、Ｑ／ｆ０にほぼ比例する非常に長い起動時間を有するので（Ｑは、水晶の品質係数であり、ｆ０は、動作周波数（例えば、１０ＭＨｚＸＴＡＬ水晶については約１ミリ秒、および３２．７６８ｋＨｚ水晶については１，０００ミリ秒））、水晶発振器を利用することによって、必ずしも低遅延を達成することが可能ではない場合がある。したがって、低遅延を必要とするデバイスは、代わりに、低い既知の起動時間を伴う内部緩和（ＲＣ）発振器を使用し得る（図８０ｂ参照）。マスタデバイス５２は、ＦＵＮＣＴＩＯＮ ＳＥＴ ＰＯＷＥＲを設定することによって、ＵＡＲＴモードのためにデバイスをプログラムし得る。これは、ＵＡＲＴが、使用される帯域幅に応じてバス６４を動的に制御すること、およびデータをマスタデバイス５２に送信することを可能にする。次いで、マスタデバイス５２は、その水晶発振器が安定したときに引き継いでもよい。代替実施形態では、ＬＣ発振器またはリング発振器が、ＲＣ発振器の代わりに使用され得る。これらの異なる発振器は、１つまたはいくつかのクロック周期で再起動することができ、これは、有利であるが、マスタデバイス５２のクロック信号より多くのジッタをもたらし得る。
ＵＡＲＴデバイスが引き継ぐ前にクロック対立を回避するように、マスタデバイス５２がクロックを制御したい場合（例えば、ＵＡＲＴデバイスからの応答がない）において、マスタデバイス５２は、クロックラインを変更することなく、ある遅延を伴って、異なる値をＤＡＴＡラインに１回以上書き込むことができる。これは、マスタデバイス５２が、再度、クロック信号を再アクティブ化したいことをＵＡＲＴに信号伝達し、それによって、バスクロックライン上の潜在的な衝突を回避する。
電力消費を削減するための多くのオプションがあるが、制限因子は、実装で使用される物理層であり得ることに留意されたい。したがって、システムのデバイスの全てが、同一のバス上で実行されなくてもよい。いくつかのデバイスは、他のデバイスよりはるかに高い帯域幅を必要とし得、異なるバス上でこれらのデバイスを作動させることによって、電力が節約され得る。さらに、システムクロック速度は、バス６４にアタッチされるデバイスの数とともに増加し、これは、容量損失を増加させ、したがって、電力消費をさらに増加させる。これに加えて、より低い信号伝達電圧、例えば、１．８０Ｖの代わりに１．２０Ｖを使用することによって、電力損失を有意に最小化することが可能である。
ここで図８０ａを参照すると、統一バス通信プロトコルを使用してポートまたはデバイスのために設定されることができる、種々の電力消費モードまたは電力管理モードの代替実施形態の実施例が示されている。ＦＵＮＣＴＩＯＮ ＳＥＴ ＰＯＷＥＲは、図８０ａに示されるモードのうちのなくとも１つに従って、ポートまたはデバイスの動作モードを設定するために使用されることができる。
この場合、電力消費スケーリングは、関数によって設定され、正確であると見なされるべきではないが、むしろ典型的な値と見なされるべきである。したがって、図８０ａに示される電力レベルは、異なるスレーブデバイスに対して変化し得る。ＦＵＮＣＴＩＯＮ ＳＥＴ ＰＯＷＥＲを使用して変化することができるモードは、依然として、完全制御レジスタマップへのアクセスを有し得るが、アナログ回路の性能に影響を及ぼし得る可能性が高い。デバイスは、電力管理についての以前の節で説明されるように、特別な機構を使用して、シャットダウンモード００００から００１１に戻り得る。少なくとも１つの実施形態では、デバイスが低電力状態から戻されるとき、シャットダウンコマンドが受信される前と同一のモードで動作を再開し得る。
シャットダウン電力モード（００００）では、スレーブデバイスは、完全にシャットダウンされ、バス６４上のアクティビティは、もはやスレーブデバイスによって監視されなくなるであろう。シャットダウン電力モードにされると、マスタデバイス５２がスレーブデバイスを起動させることは可能ではない。スレーブデバイスの起動は、スレーブデバイス自体によって、または完全にシャットダウンしたスレーブデバイスを起動させるために使用される制御信号用の追加の端子を使用することによって、行われる必要があり得る。
ゲートクロックシャットダウン電力モード（０００１および００１０）では、非常に低い電力消費があり、内部回路のクロックゲーティングは、これらのモードのいずれかに置かれたスレーブデバイスに対して使用される。さらに、全てのポートおよび全ての内部関数の電源が切られる。バス６４がもはや監視されなくなるが、Ｍ番目ごとのフレーム中に、スレーブデバイスは、その論理をアクティブにし、１つのフレームに対して起動するであろう（実施例については図７９参照）。スレーブデバイスは、依然として同期しているかどうかを依然としてチェックし、ＸおよびＹワードをチェックし、それに従って応答するであろう。マスタデバイス５２が、このモードでスレーブデバイスを起動させたい場合、スレーブデバイスがメッセージを受信して応答する前に、最大でＭ回、このスレーブデバイスに書き込む必要があり得る。スレーブデバイスが（例えば、スリープ状態であった間のモード変更による）同期化エラーを受ける場合、例えば、２つ等のある数の同期エラー後、再度、同期に戻ろうとし、プロセスにおいてその内部論理の電源を入れるであろう。同期に戻った後、スレーブデバイスは、再度、その内部論理を非アクティブにするであろう。この例示的実施形態に対して、Ｍ＝１６＝１５＋１の値については、疑似ランダム同期カウンタの完全サイクル（すなわち、１５個のフレーム）がスキップされる一方で、Ｍ＝２５６＝１５＊１７＋１については、すなわち、疑似ランダム同期カウンタの１７回のサイクル（すなわち、２７２個のフレーム）がスキップされ、次のフレームが監視されることに留意されたい。
図８０ａを再度参照すると、電力消費モード「００１１」が、ＵＡＲＴクロック停止モードに対して使用され得、ＵＡＲＴは、クロックが停止した後、それ自体でバス６４を起動させることができる。電力消費モード「１０００」は、制御のみの用途に使用され得、全ての内部回路は、統一バスプロトコルに関連付けられる論理を除いてシャットダウンされる。電力消費モード「１００１」から「１１１１」は、通常動作モードに使用され得、種々の電流が内部回路に対して増減し、それによって、デバイスの実際の性能を決定する。これらのモードの間で選択することは、電流消費とスレーブデバイス性能との間の妥協になるであろう。電力消費モード「０１００」から「０１１１」は、現在、定義されておらず、スレーブデバイスにおいて第１の利用可能な低電力モードにマップされ得る。
統一バス通信プロトコルの実施形態を使用してデータ通信を増進する別の方法は、クロック信号がバス６４上で伝送される方法を変更することである。例えば、冗長性をデータ信号に追加し、それによって、データ信号中のデータと多重化されるクロック情報を伝えるために、通常はデータ伝送に使用される１つ以上のタイムスロットを使用することが可能である。したがって、データ自体が、クロックエッジを伝えるために使用される。これは、ここで説明されるように、データ転送のための効率の増加を可能にする。これはまた、より少ない電力消費ももたらし、クロック情報を伝えるために利用される帯域幅を低減させることができる。この技法は、ビットストリームデータが伝送されている場合に、またはワードデータが単一のワイヤを経由して、あるいは単一の伝送チャネルを使用して伝送されている場合に、使用されることができる。この技法はまた、クロック信号を生成する技法が異なるチャネルからのデータを組み合わせないため、各データチャネルが互から独立して制御されることも可能にする。この技法はまた、複数のソースとともに使用することもできる。この技法は、Ｄビットごとにクロック遷移が生じることを保証する。この技法はまた、別個のクロックおよびデータライン用の第２のワイヤを使用することなく、同期化が維持されることも可能にする。
ここで図８１ａを参照すると、単一のワイヤがクロックおよびデータを転送するために使用される、統一データ形式の例示的実施形態が示されている。クロックが、立ち上がりエッジによって定義される一方で、データは、立ち下がりエッジによって定義される。これは、「Ｓｉｎｇｌｅ ｗｉｒｅ ｂｕｓ ｓｙｓｔｅｍ」と題された公開された米国特許出願第２０１２／０１４４０７８号で、さらに説明されている。各データビットは、３つのタイムスロットを使用して伝送され、１つのタイムスロットは、クロック低信号を送信するために使用され、１つのタイムスロットは、クロック高信号を送信するために使用され、１つのタイムスロットは、実際のデータに使用される。したがって、本実施例では、立ち上がりエッジが、クロック情報を伝えるために使用される一方で、立ち下がりエッジは、データ情報を伝えるために使用される。この場合、データ帯域幅は、１／３であり、電力消費は、ビットにつき２回の遷移に関係する（低・高について１回の遷移、および高・低について１回の遷移）。
ここで図８１ｂを参照すると、６つのデータスロットまたはタイムスロットを使用して、４つのデータビットが伝送される、データ転送の第２の実施例が示されている。再度、クロック情報を伝えるために、２つのタイムスロットが利用される（第１のデータスロットが低クロック信号を信号伝達し、第２のデータスロットが高クロック信号を信号伝達する）。この場合、データ帯域幅は、２／３であり、電力消費は、ビットにつき０．８７５回の遷移に関係する。したがって、図８１ａと比較して、データ転送に利用可能な帯域幅がより高いとともに、消費電力がより低い一方で、同期化のための同一の低・高遷移が使用される。
ここで図８１ｃを参照すると、クロックおよびデータ情報をより効率的に伝送するためにビット反転を使用する、データ転送の実施例が示されている。この場合、データビット群のうちの１つのデータビットは、１回繰り返されるが、２回目には別の極性で伝送され（すなわち、ビット反転される）、それによって、全データシンボル群に対するクロック遷移を生成する。換言すると、データ列の第１のビットは、クロック信号のエッジを伝えるために、２回目に反対極性で繰り返される。換言すると、データビットのうちの１つは、全データ群に対するクロック遷移を提供し、バスにロックするために使用する遷移をデバイスに提供するように、１回は反転して、１回は通常で（または逆も同様に）、２回伝送される。したがって、Ｄ０および
図８１ｃの実施例では、データ帯域幅は、５／６（６つのデータスロットにつき５つの伝送されたビット）であり、電力消費は、ビットにつき０．７回の遷移に関係する。この決定を行うために、データビットが相関していないことが仮定される。したがって、
図８１ｂおよび８１ｃのスキームは、高い帯域幅を使用し、低い電力消費を有し、また、情報を伝送するために単一のワイヤまたは媒体を使用する、バスシステムに適している。他の実施形態では、伝送媒体は、光学または無線であり得る。ＰＬＬが、典型的には、データのストリームからクロック情報を抽出するためにデバイスの受信機で使用されるであろうことに留意されたい。さらに、ＩＩＩ型またはＩＶ型位相検出器等の単一のクロックエッジ（例えば、低・高または高・低）遷移を利用するＰＬＬは、全データ群に対する遷移を見出すために、ＸＯＲゲートとともに小遅延ラインを利用し得る。この用途では、遅延は、便宜上、１つのデータスロットにほぼ等しくあり得、直接および遅延信号は、ＸＯＲゲートに供給され得、ＸＯＲゲートからの出力は、位相検出器に提供され得る。
また、ソフトウェアを介して実装される、本明細書で説明される統一バス通信プロトコルの方法および関連同期化技法のうちの少なくとも１つを行うために使用される、要素のうちの少なくともいくつかが、オブジェクト指向プログラミング等の高レベルプロシージャ言語で書かれ得ることにも留意されたい。したがって、プログラムコードは、Ｃ、Ｃ＋＋、または任意の他の好適なプログラミング言語で書かれ得、オブジェクト指向プログラミングの当業者に公知であるように、モジュールまたはクラスを備え得る。代替として、またはそれに加えて、ソフトウェアを介して実装されるこれらの要素のうちの少なくともいくつかは、必要に応じて、アセンブリ言語、機械言語、またはファームウェアで書かれ得る。いずれにしても、プログラムコードは、記憶媒体上に、またはプロセッサ、オペレーティングシステム、および本明細書で説明される統一バス通信プロトコルの方法のうちの少なくとも１つの機能性を実装するために必要である関連ハードウェアおよびソフトウェアを有する、汎用または専用コンピュータデバイスによって読み取り可能である、コンピュータ読み取り可能な媒体上に記憶することができる。プログラムコードは、プロセッサによって読み取られるとき、統一バス通信プロトコルについて本明細書で説明される方法のうちの少なくとも１つを行うために、新しい特定かつ所定の様式で動作するように、プロセッサを構成する。
さらに、本明細書で説明される方法のうちの少なくともいくつかは、１つ以上のプロセッサのためのコンピュータ使用可能命令を持つ、コンピュータ読み取り可能な媒体を備える、コンピュータプログラム製品の中で分散されることが可能である。少なくともいくつかの場合において、コンピュータ読み取り可能な媒体は、非一過性であり得る。媒体は、限定されないが、１つ以上のディスケット、コンパクトディスク、テープ、チップ、ＵＳＢキー、外部ハードドライブ、有線伝送、衛星伝送、インターネット伝送またはダウンロード、磁気および電子記憶媒体、デジタルおよびアナログ信号等の種々の形態で提供され得る。コンピュータ使用可能命令はまた、コンパイラ型および非コンパイラ型コードを含む、種々の形態であり得る。
本明細書で説明される出願者の教示は、例証目的で種々の実施形態と関連するが、出願者の教示がそのような実施形態に限定されることは意図されない。反対に、本明細書で説明および例証される出願者の教示は、その一般的範囲が添付の請求項で定義される、実施形態から逸脱することなく、種々の代替案、修正等を包含する。
Claims (27)
- 第１の動作モードおよび第２の動作モードを有する統一バス通信プロトコルを使用して通信するマスタデバイスにスレーブデバイスを同期化する方法であって、
前記統一バス通信プロトコルに対して前記第１の動作モードを仮定することと、
前記第１の動作モードに従って、伝送されているデータの中の１つ以上の場所で同期化パターンを検索することであって、前記第１の動作モードは、伝送されている同期化ビット間に第１の一定の間隙を有する、ことと、
前記動作モードに対する少なくとも１つの同期化規則に従って、場所が特定された同期化パターンが検証された場合、同期化を取得することと、
前記第１の動作モードを仮定して同期化が取得されない場合、前記統一バス通信プロトコルに対して前記第２の動作モードを仮定し、前記第２の動作モードに従って、前記伝送されているデータ上で前記検索することおよび取得することを実行することであって、前記第２の動作モードは、伝送されている同期化ビット間に第２の一定の間隙を有し、前記第２の一定の間隙は、前記第１の一定の間隙とは異なる、ことと
を含み、
前記同期化パターンは、一定同期部分と、動的同期部分とを備え、前記検索することは、前記一定同期部分を検索することを含む、方法。 - 前記一定同期部分は、前記第１の動作モードおよび前記第２の動作モードについて異なる、請求項１に記載の方法。
- 前記動的同期部分は、２つの連続する同期化パターンの前記動的同期部分が異なるように、決定論的方法によって生成される、請求項２に記載の方法。
- 前記決定論的方法は、周期的冗長チェックカウンタ（ＣＲＣ）を採用する、請求項３に記載の方法。
- 前記第１の動作モードは、ワードモードであり、前記第２の動作モードは、ビットストリームモードであり、または前記第１の動作モードは、ビットストリームモードであり、前記第２の動作モードは、ワードモードである、請求項１〜４のいずれか一項に記載の方法。
- ワードモードを前記動作モードとして仮定する場合、前記検索することは、前記同期化パターンが以前に場所を特定されていない限り、最大フレーム長までを含む、種々の開始タイムスロット位置に対して前記伝送されているデータ上で行われる、請求項１〜５のいずれか一項に記載の方法。
- ビットストリームモードを前記動作モードとして仮定する場合、前記検索することは、最大フレーム長までを含む、種々の開始タイムスロット位置に対して前記伝送されているデータ上で行われ、これは、前記同期化パターンが以前に場所を特定されていない限り、フレームチャネルの最大数について繰り返される、請求項１〜６のいずれか一項に記載の方法。
- 前記同期化パターンの場所が特定されると、前記検索することおよび取得することは、前記統一バス通信プロトコルによって使用されているフレーム長を決定するために、次の同期化パターンを検索することを含む、請求項１〜７のいずれか一項に記載の方法。
- 前記少なくとも１つの同期化規則は、前記決定されたフレーム長が正しいことを検証するために、前記検索することおよび取得することを数回行うことを含む、請求項８に記載の方法。
- 前記検索することおよび取得することは、場所が特定されている一定同期部分に関連付けられた現在の動的同期部分を読み取ることを含み、前記少なくとも１つの同期化規則は、前記決定論的方法および前記現在の動的同期部分に基づいて、期待動的同期部分を計算することと、次の一定同期部分の場所を特定することと、誤った同期化の可能性を低減させるために、前記次の一定同期部分に関連付けられた動的同期部分を、前記期待動的同期部分と比較することとを含む、請求項３に記載の方法。
- 前記少なくとも１つの同期化規則は、誤った同期化の可能性をさらに低減させるために、前記計算すること、場所を特定することおよび比較することを１回以上繰り返すことを含む、請求項１０に記載の方法。
- 前記少なくとも１つの同期化規則は、バストラフィック上の雑音が多い条件下で同期化の可能性を向上させるために、前記場所を特定することおよび取得することにおいてランダム成分を追加することを含む、請求項１〜１１のいずれか一項に記載の方法。
- 前記ランダム成分は、ある期間にわたって前記バストラフィックのパリティを読み取ることと、前記現在場所が特定されている同期化パターンが真のパターンであるか、または偽のパターンであるかを決定することに役立つように、前記パリティ情報を使用することとを含む、請求項１２に記載の方法。
- 前記ランダム成分は、前記同期化パターンが１つ以上のエラーの下で場所を特定されている場合に使用される、請求項１２に記載の方法。
- 前記第１の動作モードは、ビットストリームモードであり、クロックゲーティングは、前記同期化パターンのビットが存在すると仮定されないフレームチャネルからのデータをスキップするために使用される、請求項１〜１４のいずれか一項に記載の方法。
- 前記方法は、クロックゲーティング、および、ワードモードおよびビットストリーム動作モードの両方の下で前記同期化パターンを検索するための共通検索構造を採用する、請求項１〜１４のいずれか一項に記載の方法。
- 前記スレーブデバイスが同期化から外れた場合、前記スレーブデバイスは、以前の成功した同期化試行中に決定されたフレーム長およびフレーム形式を仮定し、同期化を再獲得しようとする、請求項１〜１６のいずれか一項に記載の方法。
- 前記次の一定同期部分に関連付けられた前記動的同期部分が、前記期待動的同期部分に合致しない場合、前記方法は、前記期待動的同期部分に合致する動的同期部分を伴う一定同期部分を検索し続けることをさらに含む、請求項１０に記載の方法。
- 前記期待動的同期部分に合致する前記動的同期部分の場所を特定するために一定同期部分が検索されて場所を特定される数に制限が課せられる、請求項１８に記載の方法。
- 前記合致を見出すことなく前記制限に達する場合、前記方法は、有効な同期部分として前記場所が特定された一定同期部分のうちのいずれかを選択することをさらに含む、請求項１９に記載の方法。
- 同期化が達成された後、前記方法は、以前の場所が特定された同期化パターンからの決定されたフレーム長の距離の近傍にある、前記伝送されているデータの中の位置を検討することによって、同期化を維持することをさらに含む、請求項１〜２０のいずれか一項に記載の方法。
- 前記方法は、前記検索が最大フレーム長を超えるまで、期待動的同期部分と実際の動的同期部分との間の合致を見出さないことにかかわらず、前記現在の場所が特定された一定同期部分を維持することをさらに含み、前記検索が最大フレーム長を超えた時点で、現在の場所が特定された一定同期部分が破棄され、次の一定同期部分が前記現在の場所が特定された一定同期部分として使用されることを確実にし、前記合致に対する前記検索は、継続される、請求項１０に記載の方法。
- 前記方法は、最大データ長内に位置する全ての有効な一定同期部分に対応する、前記動的同期部分の表を生成することと、実際のフレーム長を決定するために、連続位置の間の分離における反復に対する期待動的同期部分に合致する前記動的同期部分の位置を分析することと、同期化を取得するために前記実際のフレーム長を使用することとをさらに含む、請求項１に記載の方法。
- 第１の動作モードおよび第２の動作モードを有する統一バス通信プロトコルに従って通信する電子デバイスであって、前記デバイスは、
信号を送受信するためのインターフェースと、
前記インターフェースに結合されている多重化および同期エンジンと
を備え、
前記多重化および同期エンジンは、前記統一バス通信プロトコルに対して前記第１の動作モードを仮定することと、前記第１の動作モードに従って、伝送されているデータの中の１つ以上の場所で同期化パターンを検索することであって、前記第１の動作モードは、伝送されている同期化ビット間に第１の一定の間隙を有する、ことと、前記動作モードに対する少なくとも１つの同期化規則に従って、場所が特定された同期化パターンが検証された場合、同期化を取得することと、前記第１の動作モードを仮定して同期化が取得されない場合、前記統一バス通信プロトコルに対して前記第２の動作モードを仮定し、前記第２の動作モードに従って、前記伝送されているデータ上で前記検索することおよび取得することを実行することであって、前記第２の動作モードは、伝送されている同期化ビット間に第２の一定の間隙を有し、前記第２の一定の間隙は、前記第１の一定の間隙とは異なる、こととによって、前記電子デバイスを第２の電子デバイスと同期化するように構成され、
前記電子デバイスは、スレーブデバイスであり、前記第２の電子デバイスは、マスタデバイスであり、
前記同期化パターンは、一定同期部分と、動的同期部分とを備え、前記検索することは、前記一定同期部分を検索することを含む、デバイス。 - 前記多重化および同期エンジンは、請求項１〜２３のいずれか一項に記載の方法を行うようにさらに構成されている、請求項２４に記載の電子デバイス。
- コンピュータプログラムを記録したコンピュータ読み取り可能な記録媒体であって、前記コンピュータプログラムは、第１の動作モードおよび第２の動作モードを有する統一バス通信プロトコルを使用して通信するマスタデバイスにスレーブデバイスを同期化する方法を実装するようにマイクロプロセッサを適合させるための、前記スレーブデバイスの前記マイクロプロセッサ上で実行可能な複数の命令を備え、前記方法は、
前記統一バス通信プロトコルに対して前記第１の動作モードを仮定することと、
前記第１の動作モードに従って、伝送されているデータの中の１つ以上の場所で同期化パターンを検索することであって、前記第１の動作モードは、伝送されている同期化ビット間に第１の一定の間隙を有する、ことと、
前記動作モードに対する少なくとも１つの同期化規則に従って、場所が特定された同期化パターンが検証された場合、同期化を取得することと、
前記第１の動作モードを仮定して同期化が取得されない場合、前記統一バス通信プロトコルに対して前記第２の動作モードを仮定し、前記第２の動作モードに従って、前記伝送されているデータ上で前記検索することおよび取得することを実行することであって、前記第２の動作モードは、伝送されている同期化ビット間に第２の一定の間隙を有し、前記第２の一定の間隙は、前記第１の一定の間隙とは異なる、ことと
を含み、
前記同期化パターンは、一定同期部分と、動的同期部分とを備え、前記検索することは、前記一定同期部分を検索することを含む、コンピュータ読み取り可能な記録媒体。 - 前記方法は、請求項１〜２３のいずれか一項に従ってさらに定義される、請求項２６に記載のコンピュータ読み取り可能な記録媒体。
Applications Claiming Priority (7)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201261654287P | 2012-06-01 | 2012-06-01 | |
| US61/654,287 | 2012-06-01 | ||
| US201261714156P | 2012-10-15 | 2012-10-15 | |
| US61/714,156 | 2012-10-15 | ||
| US13/784,457 US9479275B2 (en) | 2012-06-01 | 2013-03-04 | Multiformat digital audio interface |
| US13/784,457 | 2013-03-04 | ||
| PCT/CA2013/000232 WO2013177665A1 (en) | 2012-06-01 | 2013-03-14 | Universal synchronization engine based on probabilistic methods for guarantee of lock in multiformat audio systems |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2015525507A JP2015525507A (ja) | 2015-09-03 |
| JP6362277B2 true JP6362277B2 (ja) | 2018-07-25 |
Family
ID=49670198
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2015514293A Active JP6362277B2 (ja) | 2012-06-01 | 2013-03-14 | マルチフォーマットオーディオシステムにおけるロック保証のための確率的方法に基づく汎用同期エンジン |
Country Status (9)
| Country | Link |
|---|---|
| US (2) | US9252900B2 (ja) |
| EP (1) | EP2856690B1 (ja) |
| JP (1) | JP6362277B2 (ja) |
| KR (1) | KR101733273B1 (ja) |
| CN (1) | CN104541473B (ja) |
| AU (1) | AU2013270397B2 (ja) |
| CA (1) | CA2874899C (ja) |
| HK (1) | HK1203712A1 (ja) |
| WO (1) | WO2013177665A1 (ja) |
Families Citing this family (161)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8150526B2 (en) | 2009-02-09 | 2012-04-03 | Nano-Retina, Inc. | Retinal prosthesis |
| US8706243B2 (en) | 2009-02-09 | 2014-04-22 | Rainbow Medical Ltd. | Retinal prosthesis techniques |
| US8775707B2 (en) | 2010-12-02 | 2014-07-08 | Blackberry Limited | Single wire bus system |
| US8571669B2 (en) | 2011-02-24 | 2013-10-29 | Nano-Retina, Inc. | Retinal prosthesis with efficient processing circuits |
| DE102011054729B4 (de) * | 2011-10-21 | 2013-12-19 | Nsm-Löwen Entertainment Gmbh | Unterhaltungsspielgerät |
| FR2982054B1 (fr) * | 2011-10-28 | 2014-06-20 | Ingenico Sa | Procede et dispositif de gestion d'une matrice de touches, produit programme d'ordinateur et moyen de stockage correspondants. |
| EP2632078B1 (en) * | 2012-02-22 | 2017-11-08 | OCT Circuit Technologies International Limited | Resynchronization method of a received stream of groups of bits |
| US9479275B2 (en) | 2012-06-01 | 2016-10-25 | Blackberry Limited | Multiformat digital audio interface |
| KR101733273B1 (ko) | 2012-06-01 | 2017-05-24 | 블랙베리 리미티드 | 다중 포맷 오디오 시스템들에서의 확률적 로크 보장 방법에 기초한 범용 동기화 엔진 |
| CN102868584B (zh) * | 2012-10-11 | 2015-05-06 | 江苏西电南自智能电力设备有限公司 | 一种采用串行通信接口的同步时分多路复用总线通信方法 |
| US9720477B2 (en) | 2012-11-21 | 2017-08-01 | Nano-Retina, Inc. | Weak power supply operation and control |
| US10121533B2 (en) | 2012-11-21 | 2018-11-06 | Nano-Retina, Inc. | Techniques for data retention in memory cells during power interruption |
| US9461812B2 (en) | 2013-03-04 | 2016-10-04 | Blackberry Limited | Increased bandwidth encoding scheme |
| US9370417B2 (en) | 2013-03-14 | 2016-06-21 | Nano-Retina, Inc. | Foveated retinal prosthesis |
| TWI557727B (zh) | 2013-04-05 | 2016-11-11 | 杜比國際公司 | 音訊處理系統、多媒體處理系統、處理音訊位元流的方法以及電腦程式產品 |
| CN104240710B (zh) * | 2013-06-06 | 2019-01-08 | 腾讯科技（深圳）有限公司 | 一种信息传输的方法、系统及终端设备 |
| WO2015008389A1 (ja) * | 2013-07-19 | 2015-01-22 | 三菱電機株式会社 | リング状同期ネットワークシステムおよびタイムスレーブ局 |
| US9025713B2 (en) * | 2013-10-04 | 2015-05-05 | M31 Technology Corporation | Method for portable device processing data based on clock extracted from data from host |
| US9723640B2 (en) * | 2013-11-07 | 2017-08-01 | Panasonic Intellectual Property Management Co., Ltd. | Terminal device and wireless communication system |
| US9474902B2 (en) | 2013-12-31 | 2016-10-25 | Nano Retina Ltd. | Wearable apparatus for delivery of power to a retinal prosthesis |
| US9217781B2 (en) * | 2014-01-16 | 2015-12-22 | Ford Global Technologies, Llc | Time synchronization between battery controller modules for parameter measurements |
| US9331791B2 (en) * | 2014-01-21 | 2016-05-03 | Nano Retina Ltd. | Transfer of power and data |
| US9369272B2 (en) | 2014-03-27 | 2016-06-14 | Qualcomm Incorporated | Serial time-division-multiplexed bus with bidirectional synchronization/control word line |
| US9473876B2 (en) | 2014-03-31 | 2016-10-18 | Blackberry Limited | Method and system for tunneling messages between two or more devices using different communication protocols |
| US9807343B2 (en) * | 2014-05-08 | 2017-10-31 | Samsung Electronics Co., Ltd | Apparatus and method for changing mode of device |
| DE102014209332A1 (de) * | 2014-05-16 | 2015-11-19 | Senvion Gmbh | Windenergieanlage mit verbessertem Überspannungsschutz |
| TWI712915B (zh) * | 2014-06-12 | 2020-12-11 | 美商密碼研究公司 | 執行一密碼編譯操作之方法，以及電腦可讀非暫時性儲存媒體 |
| US9721625B2 (en) | 2014-06-18 | 2017-08-01 | Qualcomm Incorporated | Time-constrained data copying between storage media |
| US9892073B1 (en) * | 2014-10-06 | 2018-02-13 | Master Lock Company Llc | Bus addressing systems and methods using repurposed bits |
| US9641622B2 (en) | 2014-12-04 | 2017-05-02 | Apple Inc. | Master device for using connection attribute of electronic accessories connections to facilitate locating an accessory |
| US9934178B2 (en) * | 2015-03-04 | 2018-04-03 | Qualcomm Incorporated | Full bandwidth communication buses |
| JP2016178601A (ja) * | 2015-03-23 | 2016-10-06 | セイコーエプソン株式会社 | データ処理回路、物理量検出用回路、物理量検出装置、電子機器及び移動体 |
| US9798684B2 (en) | 2015-04-21 | 2017-10-24 | Blackberry Limited | Bus communications with multi-device messaging |
| US10305671B2 (en) * | 2015-05-21 | 2019-05-28 | Cirrus Logic, Inc. | Synchronous differential signaling protocol |
| US9841940B2 (en) * | 2015-06-05 | 2017-12-12 | Qualcomm Incorporated | Power reduction through clock management |
| US11258679B2 (en) | 2015-07-28 | 2022-02-22 | Spirent Communications, Inc. | Systems and methods for automated testing of MoCA networks |
| US10129102B2 (en) * | 2016-05-11 | 2018-11-13 | Spirent Communications, Inc. | Service based testing |
| US20170075843A1 (en) * | 2015-09-10 | 2017-03-16 | Qualcomm Incorporated | Unified systems and methods for interchip and intrachip node communication |
| JP6836340B2 (ja) * | 2015-09-29 | 2021-02-24 | パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ | 不正検知電子制御ユニット、車載ネットワークシステム及び通信方法 |
| DE102015120242B3 (de) * | 2015-11-23 | 2017-02-09 | Beckhoff Automation Gmbh | Verfahren zum Betreiben eines Kommunikationsnetzwerkes, Kommunikationsnetzwerk, Steuervorrichtung und Datenverarbeitungsvorrichtung |
| US20170168968A1 (en) * | 2015-12-15 | 2017-06-15 | Qualcomm Incorporated | Audio bus interrupts |
| IL243789A0 (en) * | 2016-01-26 | 2016-07-31 | Winbond Electronics Corp | Split calculation of the next state to prevent analysis by energy consumption |
| US10019049B2 (en) * | 2016-01-28 | 2018-07-10 | Dell Products L.P. | Information handling system multiport power management |
| US10139881B2 (en) | 2016-01-28 | 2018-11-27 | Dell Products L.P. | Information handling system port power management and cable detect |
| US10372181B2 (en) | 2016-01-28 | 2019-08-06 | Dell Products L.P. | Information handling system multiple port power source management |
| US10281967B2 (en) | 2016-01-28 | 2019-05-07 | Dell Products L.P. | Information handling system reversible charge port and magnetic charge connector |
| US9965247B2 (en) | 2016-02-22 | 2018-05-08 | Sonos, Inc. | Voice controlled media playback system based on user profile |
| US9947316B2 (en) | 2016-02-22 | 2018-04-17 | Sonos, Inc. | Voice control of a media playback system |
| US10264030B2 (en) | 2016-02-22 | 2019-04-16 | Sonos, Inc. | Networked microphone device control |
| US9826306B2 (en) | 2016-02-22 | 2017-11-21 | Sonos, Inc. | Default playback device designation |
| US10509626B2 (en) | 2016-02-22 | 2019-12-17 | Sonos, Inc | Handling of loss of pairing between networked devices |
| US10095470B2 (en) | 2016-02-22 | 2018-10-09 | Sonos, Inc. | Audio response playback |
| US10536033B2 (en) * | 2016-03-23 | 2020-01-14 | Novanta Corporation | System and method of bi-directional communication for position sensors involving superposition of data over low voltage DC power using two conductors |
| TWI720153B (zh) * | 2016-03-29 | 2021-03-01 | 日商新力股份有限公司 | 送訊裝置、送訊方法、收訊裝置、收訊方法及收送訊系統 |
| US10038569B2 (en) * | 2016-03-29 | 2018-07-31 | Intel IP Corporation | Self-adapting baud rate |
| US10034160B2 (en) * | 2016-04-14 | 2018-07-24 | Lg Electronics Inc. | Method and apparatus for transmitting or receiving data using bluetooth in wireless communication system |
| US10019306B2 (en) | 2016-04-27 | 2018-07-10 | Western Digital Technologies, Inc. | Collision detection for slave storage devices |
| US9978390B2 (en) | 2016-06-09 | 2018-05-22 | Sonos, Inc. | Dynamic player selection for audio signal processing |
| US10152969B2 (en) | 2016-07-15 | 2018-12-11 | Sonos, Inc. | Voice detection by multiple devices |
| US10115400B2 (en) | 2016-08-05 | 2018-10-30 | Sonos, Inc. | Multiple voice services |
| KR102641515B1 (ko) * | 2016-09-19 | 2024-02-28 | 삼성전자주식회사 | 메모리 장치 및 그것의 클록 분배 방법 |
| US9942678B1 (en) | 2016-09-27 | 2018-04-10 | Sonos, Inc. | Audio playback settings for voice interaction |
| US9743204B1 (en) | 2016-09-30 | 2017-08-22 | Sonos, Inc. | Multi-orientation playback device microphones |
| CN109891499B (zh) * | 2016-10-19 | 2022-12-09 | 三菱电机株式会社 | 语音识别装置及语音识别方法 |
| US10181323B2 (en) | 2016-10-19 | 2019-01-15 | Sonos, Inc. | Arbitration-based voice recognition |
| JP6640696B2 (ja) * | 2016-10-20 | 2020-02-05 | キオクシア株式会社 | インターフェースシステム |
| DE102016226136A1 (de) * | 2016-12-23 | 2018-06-28 | Robert Bosch Gmbh | Verfahren zum Betreiben einer Sensoreinrichtung, Sensoreinrichtung |
| KR101923161B1 (ko) * | 2017-01-11 | 2018-11-28 | 울산과학기술원 | 동기화 기반 인코딩을 이용한 데이터 송수신 장치 및 그 방법 |
| US10509759B2 (en) * | 2017-03-31 | 2019-12-17 | Intel Corporation | Multiple storage devices implemented using a common connector |
| US20180317789A1 (en) * | 2017-05-02 | 2018-11-08 | Signature Medical, Inc. | Devices and Methods for Remote Monitoring of Heart Activity |
| JP2019004205A (ja) * | 2017-06-12 | 2019-01-10 | 株式会社村田製作所 | 転送装置 |
| CN107391401B (zh) * | 2017-07-03 | 2019-06-21 | 北京亚华意诺斯新能源科技有限公司 | 一种数据读取方法及系统 |
| US10372663B2 (en) | 2017-07-25 | 2019-08-06 | Qualcomm Incorporated | Short address mode for communicating waveform |
| JP7031961B2 (ja) * | 2017-08-04 | 2022-03-08 | ソニーセミコンダクタソリューションズ株式会社 | 通信装置、通信方法、プログラム、および、通信システム |
| US10475449B2 (en) | 2017-08-07 | 2019-11-12 | Sonos, Inc. | Wake-word detection suppression |
| CN107526421B (zh) * | 2017-08-18 | 2020-06-16 | 苏州浪潮智能科技有限公司 | 一种双压接电源线缆供电系统 |
| US11114112B2 (en) | 2017-09-07 | 2021-09-07 | Google Llc | Low power, high bandwidth, low latency data bus |
| US10048930B1 (en) | 2017-09-08 | 2018-08-14 | Sonos, Inc. | Dynamic computation of system response volume |
| US10446165B2 (en) | 2017-09-27 | 2019-10-15 | Sonos, Inc. | Robust short-time fourier transform acoustic echo cancellation during audio playback |
| US10482868B2 (en) | 2017-09-28 | 2019-11-19 | Sonos, Inc. | Multi-channel acoustic echo cancellation |
| US10621981B2 (en) | 2017-09-28 | 2020-04-14 | Sonos, Inc. | Tone interference cancellation |
| US10466962B2 (en) | 2017-09-29 | 2019-11-05 | Sonos, Inc. | Media playback system with voice assistance |
| JP7082311B2 (ja) * | 2017-11-08 | 2022-06-08 | 株式会社村田製作所 | データ通信装置 |
| JP2019096960A (ja) * | 2017-11-20 | 2019-06-20 | 富士通株式会社 | 伝送装置及び伝送方法 |
| US10880650B2 (en) | 2017-12-10 | 2020-12-29 | Sonos, Inc. | Network microphone devices with automatic do not disturb actuation capabilities |
| US10818290B2 (en) | 2017-12-11 | 2020-10-27 | Sonos, Inc. | Home graph |
| KR102471531B1 (ko) * | 2017-12-21 | 2022-11-28 | 에스케이하이닉스 주식회사 | 저속 동작 환경에서 고속 테스트를 수행할 수 있는 반도체 장치 및 시스템 |
| WO2019152722A1 (en) | 2018-01-31 | 2019-08-08 | Sonos, Inc. | Device designation of playback and network microphone device arrangements |
| US11265717B2 (en) * | 2018-03-26 | 2022-03-01 | University Of Florida Research Foundation, Inc. | Detecting SS7 redirection attacks with audio-based distance bounding |
| US10855527B2 (en) * | 2018-04-03 | 2020-12-01 | Infineon Technologies Ag | Bidirectional communication using edge timing in a signal |
| US10896106B2 (en) | 2018-05-10 | 2021-01-19 | Teradyne, Inc. | Bus synchronization system that aggregates status |
| US11175880B2 (en) | 2018-05-10 | 2021-11-16 | Sonos, Inc. | Systems and methods for voice-assisted media content selection |
| US10847178B2 (en) | 2018-05-18 | 2020-11-24 | Sonos, Inc. | Linear filtering for noise-suppressed speech detection |
| US10959029B2 (en) | 2018-05-25 | 2021-03-23 | Sonos, Inc. | Determining and adapting to changes in microphone performance of playback devices |
| CN109039335B (zh) * | 2018-06-13 | 2021-09-24 | 苏州顺芯半导体有限公司 | 一种音频模数转换芯片阵列帧时钟同步的实现装置及实现方法 |
| US10681460B2 (en) | 2018-06-28 | 2020-06-09 | Sonos, Inc. | Systems and methods for associating playback devices with voice assistant services |
| US10528517B1 (en) | 2018-08-09 | 2020-01-07 | Qualcomm Incorporated | Systems and methods for power conservation in a SOUNDWIRE audio bus through pattern recognition |
| US10359827B1 (en) * | 2018-08-15 | 2019-07-23 | Qualcomm Incorporated | Systems and methods for power conservation in an audio bus |
| US11657010B2 (en) | 2018-08-22 | 2023-05-23 | Google Llc | Dynamic timing calibration systems and methods |
| US11294837B2 (en) * | 2018-08-22 | 2022-04-05 | Google Llc | Dynamic delay calibration of devices attached to bus systems utilizing time-multiplexed clock and data lines |
| US11076035B2 (en) | 2018-08-28 | 2021-07-27 | Sonos, Inc. | Do not disturb feature for audio notifications |
| US10461710B1 (en) | 2018-08-28 | 2019-10-29 | Sonos, Inc. | Media playback system with maximum volume setting |
| US10587430B1 (en) | 2018-09-14 | 2020-03-10 | Sonos, Inc. | Networked devices, systems, and methods for associating playback devices based on sound codes |
| US10878811B2 (en) | 2018-09-14 | 2020-12-29 | Sonos, Inc. | Networked devices, systems, and methods for intelligently deactivating wake-word engines |
| US11024331B2 (en) | 2018-09-21 | 2021-06-01 | Sonos, Inc. | Voice detection optimization using sound metadata |
| US10811015B2 (en) | 2018-09-25 | 2020-10-20 | Sonos, Inc. | Voice detection optimization based on selected voice assistant service |
| US11100923B2 (en) | 2018-09-28 | 2021-08-24 | Sonos, Inc. | Systems and methods for selective wake word detection using neural network models |
| US10692518B2 (en) | 2018-09-29 | 2020-06-23 | Sonos, Inc. | Linear filtering for noise-suppressed speech detection via multiple network microphone devices |
| CN111064686B (zh) * | 2018-10-16 | 2022-05-27 | 力同科技股份有限公司 | 一种符号定时同步方法及其装置 |
| US11899519B2 (en) | 2018-10-23 | 2024-02-13 | Sonos, Inc. | Multiple stage network microphone device with reduced power consumption and processing load |
| EP3654249A1 (en) | 2018-11-15 | 2020-05-20 | Snips | Dilated convolutions and gating for efficient keyword spotting |
| US11183183B2 (en) * | 2018-12-07 | 2021-11-23 | Sonos, Inc. | Systems and methods of operating media playback systems having multiple voice assistant services |
| US11132989B2 (en) | 2018-12-13 | 2021-09-28 | Sonos, Inc. | Networked microphone devices, systems, and methods of localized arbitration |
| TWI706257B (zh) | 2018-12-13 | 2020-10-01 | 新唐科技股份有限公司 | 匯流排系統 |
| US11637546B2 (en) * | 2018-12-14 | 2023-04-25 | Synaptics Incorporated | Pulse density modulation systems and methods |
| US10602268B1 (en) | 2018-12-20 | 2020-03-24 | Sonos, Inc. | Optimization of network microphone devices using noise classification |
| CN109656567B (zh) * | 2018-12-20 | 2022-02-01 | 北京树根互联科技有限公司 | 异质化业务数据处理逻辑的动态方法和系统 |
| US10599601B1 (en) | 2019-01-16 | 2020-03-24 | Qorvo Us, Inc. | Single-wire bus (SuBUS) slave circuit and related apparatus |
| US10867604B2 (en) | 2019-02-08 | 2020-12-15 | Sonos, Inc. | Devices, systems, and methods for distributed voice processing |
| US11315556B2 (en) | 2019-02-08 | 2022-04-26 | Sonos, Inc. | Devices, systems, and methods for distributed voice processing by transmitting sound data associated with a wake word to an appropriate device for identification |
| WO2020174943A1 (ja) * | 2019-02-26 | 2020-09-03 | ソニーセミコンダクタソリューションズ株式会社 | オーディオ信号同期制御装置及びオーディオ装置 |
| US11119958B2 (en) | 2019-04-18 | 2021-09-14 | Qorvo Us, Inc. | Hybrid bus apparatus |
| US11226924B2 (en) * | 2019-04-24 | 2022-01-18 | Qorvo Us, Inc. | Single-wire bus apparatus supporting slave-initiated operation in a master circuit |
| US11120794B2 (en) | 2019-05-03 | 2021-09-14 | Sonos, Inc. | Voice assistant persistence across multiple network microphone devices |
| CN110120822A (zh) * | 2019-05-23 | 2019-08-13 | 温州宝德电气有限公司 | 一种声音加密无线传输设备 |
| US11361756B2 (en) | 2019-06-12 | 2022-06-14 | Sonos, Inc. | Conditional wake word eventing based on environment |
| US11200894B2 (en) | 2019-06-12 | 2021-12-14 | Sonos, Inc. | Network microphone device with command keyword eventing |
| US10586540B1 (en) | 2019-06-12 | 2020-03-10 | Sonos, Inc. | Network microphone device with command keyword conditioning |
| CN110602672B (zh) * | 2019-07-29 | 2021-10-08 | 深圳市万普拉斯科技有限公司 | 蓝牙设备回连方法、装置、终端和计算机可读存储介质 |
| US11138975B2 (en) | 2019-07-31 | 2021-10-05 | Sonos, Inc. | Locally distributed keyword detection |
| US10871943B1 (en) | 2019-07-31 | 2020-12-22 | Sonos, Inc. | Noise classification for event detection |
| US11138969B2 (en) | 2019-07-31 | 2021-10-05 | Sonos, Inc. | Locally distributed keyword detection |
| US11121790B2 (en) * | 2019-08-21 | 2021-09-14 | Arista Networks, Inc. | Latency reduction in ethernet frames |
| DE102019214721A1 (de) * | 2019-09-26 | 2021-04-01 | Robert Bosch Gmbh | Konfliktdetektor für eine Teilnehmerstation eines seriellen Bussystems und Verfahren zur Kommunikation in einem seriellen Bussystem |
| US11189286B2 (en) | 2019-10-22 | 2021-11-30 | Sonos, Inc. | VAS toggle based on device orientation |
| JP7385019B2 (ja) | 2019-11-18 | 2023-11-21 | グーグル エルエルシー | センサー出力サンプルの同期 |
| US10983942B1 (en) | 2019-12-11 | 2021-04-20 | Qorvo Us, Inc. | Multi-master hybrid bus apparatus |
| US11200900B2 (en) | 2019-12-20 | 2021-12-14 | Sonos, Inc. | Offline voice control |
| US11562740B2 (en) | 2020-01-07 | 2023-01-24 | Sonos, Inc. | Voice verification for media playback |
| KR20210089811A (ko) * | 2020-01-08 | 2021-07-19 | 삼성전자주식회사 | 외부 신호에 기초하여, 전력 모드의 변경을 감지하는 전자 장치 |
| CN113138623A (zh) * | 2020-01-20 | 2021-07-20 | 南京深视光点科技有限公司 | 全局时钟同步传输方法 |
| US11556307B2 (en) | 2020-01-31 | 2023-01-17 | Sonos, Inc. | Local voice data processing |
| US11308958B2 (en) | 2020-02-07 | 2022-04-19 | Sonos, Inc. | Localized wakeword verification |
| JP7218313B2 (ja) | 2020-03-03 | 2023-02-06 | 株式会社東芝 | 通信装置、通信システム、および通信方法 |
| US11482224B2 (en) | 2020-05-20 | 2022-10-25 | Sonos, Inc. | Command keywords with input detection windowing |
| US11727919B2 (en) | 2020-05-20 | 2023-08-15 | Sonos, Inc. | Memory allocation for keyword spotting engines |
| US11308962B2 (en) | 2020-05-20 | 2022-04-19 | Sonos, Inc. | Input detection windowing |
| US11698771B2 (en) | 2020-08-25 | 2023-07-11 | Sonos, Inc. | Vocal guidance engines for playback devices |
| US11288216B1 (en) * | 2020-09-30 | 2022-03-29 | Dell Products L.P. | Priority reversing data traffic for latency sensitive peripherals |
| CN112230622B (zh) * | 2020-10-15 | 2021-09-07 | 中汽院汽车技术有限公司 | 一种基于crc校验的can总线通信信息安全增强方法 |
| CN112184084B (zh) * | 2020-11-05 | 2023-08-08 | 北京嘉和海森健康科技有限公司 | 一种病历学习质量评估方法及装置 |
| US11409677B2 (en) | 2020-11-11 | 2022-08-09 | Qorvo Us, Inc. | Bus slave circuit and related single-wire bus apparatus |
| US11489695B2 (en) | 2020-11-24 | 2022-11-01 | Qorvo Us, Inc. | Full-duplex communications over a single-wire bus |
| CN112463691B (zh) * | 2020-12-04 | 2024-04-02 | 威创集团股份有限公司 | 一种基于i2c的线路切换电路和通信系统 |
| US11487495B2 (en) * | 2021-02-12 | 2022-11-01 | Qualcomm Incorporated | Audio flow for internet of things (IOT) devices during power mode transitions |
| CN113934679A (zh) * | 2021-10-08 | 2022-01-14 | 天津津航计算技术研究所 | 一种fpga通用dac接口模块及接口方法 |
| US11880325B2 (en) * | 2021-11-22 | 2024-01-23 | Texas Instruments Incorporated | Detecting and handling a coexistence event |
| US11706048B1 (en) | 2021-12-16 | 2023-07-18 | Qorvo Us, Inc. | Multi-protocol bus circuit |
| CN114461550A (zh) * | 2021-12-16 | 2022-05-10 | 加弘科技咨询(上海)有限公司 | 基于i2c通信的多主控设备访问仲裁系统及方法 |
| US11955981B2 (en) * | 2022-04-19 | 2024-04-09 | Micron Technology, Inc. | Divided quad clock-based inter-die clocking in a three-dimensional stacked memory device |
| CN115174305B (zh) * | 2022-06-28 | 2023-11-03 | 珠海一微半导体股份有限公司 | 基于iis接口的数据转换控制系统及芯片 |
Family Cites Families (127)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US3710262A (en) | 1971-11-02 | 1973-01-09 | Franklin Electric Co Inc | Synchronized counting system for counting symmetrical signals during a time base |
| US3810111A (en) | 1972-12-26 | 1974-05-07 | Ibm | Data coding with stable base line for recording and transmitting binary data |
| FR2217872B1 (ja) | 1973-02-12 | 1976-05-14 | Cit Alcatel | |
| US3995264A (en) | 1974-11-01 | 1976-11-30 | International Business Machines Corporation | Apparatus for encoding and decoding binary data in a modified zero modulation data code |
| US4321483A (en) | 1979-10-12 | 1982-03-23 | Rockwell International Corporation | Apparatus for deriving clock pulses from return-to-zero data pulses |
| US4310922A (en) | 1980-01-10 | 1982-01-12 | Lichtenberger W Wayne | Bit sampling multiplexer apparatus |
| US4402073A (en) | 1980-03-11 | 1983-08-30 | Vanderhoff Communications Ltd. | Speech and data communication network |
| US4298987A (en) * | 1980-03-12 | 1981-11-03 | The United States Of America As Represented By The Administrator, National Aeronautics And Space Administration | Memory-based frame synchronizer |
| JPS5895447A (ja) | 1981-12-02 | 1983-06-07 | Nippon Telegr & Teleph Corp <Ntt> | クロツク再生回路 |
| JPS58101541A (ja) | 1981-12-14 | 1983-06-16 | Mitsubishi Electric Corp | ル−プ状伝送システムのフレ−ム同期制御方式 |
| JPS5895447U (ja) | 1981-12-22 | 1983-06-28 | 鈴木工業株式会社 | コンクリ−ト型枠間隔保持具 |
| JPS58101541U (ja) | 1981-12-28 | 1983-07-11 | 松下電器産業株式会社 | ル−プアンテナ内蔵ラジオ受信機 |
| US4768188A (en) | 1982-05-20 | 1988-08-30 | Hughes Network Systems, Inc. | Optical demand assigned local loop communication system |
| US4530088A (en) | 1983-02-15 | 1985-07-16 | Sperry Corporation | Group coding system for serial data transmission |
| US4592077A (en) | 1983-12-23 | 1986-05-27 | Phillips Petroleum Company | NRZ digital data recovery |
| JPS61242142A (ja) * | 1985-04-18 | 1986-10-28 | Panafacom Ltd | 通信制御方式 |
| DE3627135C2 (de) | 1986-08-09 | 1994-11-24 | Philips Patentverwaltung | Bitsynchronisation eines Datenblocks in einem Empfänger |
| JPS63128838A (ja) * | 1986-11-18 | 1988-06-01 | Fujitsu Ltd | 通信制御装置の異手順接続方式 |
| US4931923A (en) | 1987-03-13 | 1990-06-05 | Apple Computer, Inc. | Computer system for automatically reconfigurating memory space to avoid overlaps of memory reserved for expansion slots |
| JPS63292841A (ja) * | 1987-05-26 | 1988-11-30 | Hitachi Ltd | フレ−ム同期方式 |
| US5060227A (en) | 1988-02-29 | 1991-10-22 | Motorola, Inc. | Digital telephone switch with simultaneous dual PCM format compatibility |
| US4907222A (en) | 1988-08-17 | 1990-03-06 | Nuvatec, Inc. | Vehicle multiplex system |
| US5012240A (en) | 1988-12-28 | 1991-04-30 | Nippon Hoso Kyokai | Parallel to serial converter with complementary bit insertion for disparity reduction |
| US5210846B1 (en) | 1989-05-15 | 1999-06-29 | Dallas Semiconductor | One-wire bus architecture |
| US4972161A (en) | 1989-06-28 | 1990-11-20 | Digital Equipment Corporation | Clock recovery for serial data communications system |
| ES2104629T3 (es) | 1990-04-21 | 1997-10-16 | Sel Alcatel Ag | Metodo de sincronizacion para sistemas sdh y metodo y circuito para reconocer diversas estructuras de datos. |
| EP0489944B1 (de) | 1990-12-08 | 1995-09-20 | Deutsche ITT Industries GmbH | Master-Slave-Datenübertragungsverfahren mit flexiblem Eindraht-Bus |
| US5297181A (en) | 1992-01-17 | 1994-03-22 | Alesis | Method and apparatus for providing a digital audio interface protocol |
| US5689534A (en) | 1992-05-12 | 1997-11-18 | Apple Computer, Inc. | Audio functional unit and system and method for configuring the same |
| US6104724A (en) | 1993-09-20 | 2000-08-15 | Transwitch Corp. | Asynchronous data transfer and source traffic control system |
| US5446726A (en) | 1993-10-20 | 1995-08-29 | Lsi Logic Corporation | Error detection and correction apparatus for an asynchronous transfer mode (ATM) network device |
| US6026088A (en) | 1993-10-20 | 2000-02-15 | Lsi Logic Corporation | Network architecture |
| US5748763A (en) | 1993-11-18 | 1998-05-05 | Digimarc Corporation | Image steganography system featuring perceptually adaptive and globally scalable signal embedding |
| US6944298B1 (en) | 1993-11-18 | 2005-09-13 | Digimare Corporation | Steganographic encoding and decoding of auxiliary codes in media signals |
| US5459722A (en) | 1994-06-30 | 1995-10-17 | At&T Ipm Corp. | Asynchronous transfer mode (ATM) transport of voice-band signals |
| DE69515147T2 (de) * | 1994-07-15 | 2000-09-21 | Thomson Consumer Electronics | Mehrfachprotokoll-Datenbussystem |
| US5574865A (en) | 1994-12-01 | 1996-11-12 | Unisys Corporation | System for data transfer protection during module connection/disconnection onto live bus |
| JP2716392B2 (ja) * | 1995-03-06 | 1998-02-18 | 静岡日本電気株式会社 | フレーム同期回路 |
| US5862354A (en) | 1996-03-05 | 1999-01-19 | Dallas Semiconductor Corporation | Universal asynchronous receiver/transmitter (UART) slave device containing an identifier for communication on a one-wire bus |
| FR2746995B1 (fr) | 1996-03-28 | 1998-05-15 | Sgs Thomson Microelectronics | Procede et dispositif de codage de transmission et utilisation de ce procede |
| US6438434B1 (en) | 1996-05-29 | 2002-08-20 | Yamaha Corporation | Mixing, coding and decoding devices and methods |
| US6182180B1 (en) | 1997-05-13 | 2001-01-30 | Micron Electronics, Inc. | Apparatus for interfacing buses |
| US6111888A (en) | 1997-05-27 | 2000-08-29 | Micro Motion, Inc. | Deterministic serial bus communication system |
| US6904110B2 (en) | 1997-07-31 | 2005-06-07 | Francois Trans | Channel equalization system and method |
| JPH1188313A (ja) * | 1997-09-08 | 1999-03-30 | Oki Electric Ind Co Ltd | 移動体通信システム及び通信方法 |
| US6370158B1 (en) | 1997-11-14 | 2002-04-09 | Wireless Facilities, Inc. | Wireless T/E Transceiver frame signaling subcontroller |
| US6157614A (en) | 1997-10-22 | 2000-12-05 | Netro Corporation | Wireless ATM network with high quality of service scheduling |
| US6009389A (en) | 1997-11-14 | 1999-12-28 | Cirrus Logic, Inc. | Dual processor audio decoder and methods with sustained data pipelining during error conditions |
| US6145007A (en) | 1997-11-14 | 2000-11-07 | Cirrus Logic, Inc. | Interprocessor communication circuitry and methods |
| US6532506B1 (en) | 1998-08-12 | 2003-03-11 | Intel Corporation | Communicating with devices over a bus and negotiating the transfer rate over the same |
| US6539443B1 (en) | 1998-08-12 | 2003-03-25 | Intel Corporation | Bus communication and transfer rate negotiation system |
| US6535505B1 (en) | 1998-09-30 | 2003-03-18 | Cisco Technology, Inc. | Method and apparatus for providing a time-division multiplexing (TDM) interface among a high-speed data stream and multiple processors |
| US6611531B1 (en) | 1998-09-30 | 2003-08-26 | Cisco Technology, Inc. | Method and apparatus for routing integrated data, voice, and video traffic |
| US6205504B1 (en) | 1998-09-30 | 2001-03-20 | International Business Machines Corporation | Externally provided control of an I2C bus |
| ID25532A (id) | 1998-10-29 | 2000-10-12 | Koninkline Philips Electronics | Penanaman data tambahan dalam sinyal informasi |
| JP3783563B2 (ja) * | 1999-01-20 | 2006-06-07 | 松下電器産業株式会社 | データ送信方法、送信装置およびデータ受信方法、受信装置 |
| US6697897B1 (en) | 1999-10-28 | 2004-02-24 | Microchip Technology Incorporated | Data communication interface between host and slave processors |
| US6931370B1 (en) | 1999-11-02 | 2005-08-16 | Digital Theater Systems, Inc. | System and method for providing interactive audio in a multi-channel audio environment |
| US6947893B1 (en) | 1999-11-19 | 2005-09-20 | Nippon Telegraph & Telephone Corporation | Acoustic signal transmission with insertion signal for machine control |
| US6920156B1 (en) | 1999-12-01 | 2005-07-19 | Cisco Technology, Inc. | Method and system for transporting synchronous and asynchronous traffic on a synchronous bus of a telecommunications node |
| US6737957B1 (en) | 2000-02-16 | 2004-05-18 | Verance Corporation | Remote control signaling using audio watermarks |
| JP3636638B2 (ja) * | 2000-06-06 | 2005-04-06 | 三菱電機株式会社 | 通信端末 |
| US7050402B2 (en) * | 2000-06-09 | 2006-05-23 | Texas Instruments Incorporated | Wireless communications with frequency band selection |
| US6694382B1 (en) | 2000-08-21 | 2004-02-17 | Rockwell Collins, Inc. | Flexible I/O subsystem architecture and associated test capability |
| SE522704C2 (sv) | 2000-10-09 | 2004-03-02 | Ericsson Telefon Ab L M | Överföring av ljuddata och icke ljuddata mellan en bärbar ch kommunikationsapparat och en extern terminal |
| KR100370218B1 (ko) | 2000-10-31 | 2003-01-29 | 삼성전자 주식회사 | 비디오/오디오 처리용 집적회로에 적합한 제어 신호 전송및 수신방법 및 이에 적합한 장치들 |
| AU2002218279A1 (en) | 2000-11-08 | 2002-05-21 | Koninklijke Philips Electronics N.V. | Method and device for communicating a command |
| US6879810B2 (en) * | 2000-12-20 | 2005-04-12 | Nokia Corporation | Control of short range RF communication |
| US7099970B1 (en) | 2001-04-03 | 2006-08-29 | Electronic Label Technology, Inc. | Apparatus and method to enhance a one-wire bus |
| US6751685B2 (en) | 2001-04-18 | 2004-06-15 | Telephonics Corporation | E1/T1 to asynchronous communications interface |
| US6766233B2 (en) * | 2001-05-15 | 2004-07-20 | Intellisist, Llc | Modular telematic control unit |
| WO2003096036A1 (en) | 2002-05-08 | 2003-11-20 | Semtech Corporation | Single-wire communication bus for miniature low-power systems |
| NZ520650A (en) * | 2002-08-08 | 2005-08-26 | Tait Electronics Ltd | Improvements relating to radio communication systems |
| US7039734B2 (en) | 2002-09-24 | 2006-05-02 | Hewlett-Packard Development Company, L.P. | System and method of mastering a serial bus |
| JP3949556B2 (ja) * | 2002-10-04 | 2007-07-25 | 株式会社東芝 | 無線データ伝送装置 |
| US7996588B2 (en) | 2002-10-04 | 2011-08-09 | Hewlett-Packard Company | Method and apparatus for real-time transport of multi-media information in a network |
| US7292876B2 (en) | 2002-10-08 | 2007-11-06 | Sonion Nederland B.V. | Digital system bus for use in low power instruments such as hearing aids and listening devices |
| GB0224753D0 (en) * | 2002-10-24 | 2002-12-04 | Koninl Philips Electronics Nv | Beacon channel for frequency hopping wireless devices |
| WO2004086614A1 (en) | 2003-03-21 | 2004-10-07 | D2Audio Corporation | Multi-chip pwm synchronization and communication |
| US7406100B2 (en) | 2003-05-21 | 2008-07-29 | Atmel Corporation | Bi-directional single wire interface |
| ES2357234T3 (es) * | 2003-06-02 | 2011-04-20 | Qualcomm Incorporated | Generación e implementación de un protocolo y una interfaz de señales para velocidades de transferencia de datos elevadas. |
| US7505740B2 (en) | 2003-08-26 | 2009-03-17 | Motorola, Inc. | System and apparatus for antenna identification and control |
| US7181557B1 (en) | 2003-09-15 | 2007-02-20 | National Semiconductor Corporation | Single wire bus for connecting devices and methods of operating the same |
| US7606955B1 (en) | 2003-09-15 | 2009-10-20 | National Semiconductor Corporation | Single wire bus for connecting devices and methods of operating the same |
| WO2005036795A2 (en) | 2003-10-10 | 2005-04-21 | Nokia Corporation | Communication bus having low latency |
| US7200782B2 (en) | 2003-10-23 | 2007-04-03 | Texas Instruments Incorporated | Clock recovery system for encoded serial data with simplified logic and jitter tolerance |
| JP2005217486A (ja) * | 2004-01-27 | 2005-08-11 | Matsushita Electric Ind Co Ltd | ストリーム復号装置 |
| US7590070B1 (en) | 2004-02-03 | 2009-09-15 | Cisco Technology, Inc. | System and method for discretionary multiplexing and compressing in a communications environment |
| US20050259609A1 (en) | 2004-05-20 | 2005-11-24 | Hansquine David W | Single wire bus interface |
| JP4276981B2 (ja) | 2004-06-30 | 2009-06-10 | 株式会社リコー | シリアル通信装置、その通信方法及びそのシリアル通信装置を使用したシステム装置 |
| EP1900127B1 (en) * | 2005-06-28 | 2012-02-08 | TTTech Computertechnik AG | Safe start-up of a network |
| US7395361B2 (en) | 2005-08-19 | 2008-07-01 | Qualcomm Incorporated | Apparatus and methods for weighted bus arbitration among a plurality of master devices based on transfer direction and/or consumed bandwidth |
| US8401219B2 (en) | 2007-01-05 | 2013-03-19 | Apple Inc. | Headset connector |
| KR100736928B1 (ko) | 2005-12-05 | 2007-07-10 | 삼성전자주식회사 | 호스트 디바이스 간의 데이터 통신이 가능한 복합기기 및호스트 디바이스 간의 데이터 통신방법 |
| GB2433364B (en) | 2005-12-16 | 2011-06-08 | Nokia Corp | Interface between a terminal and an asic of a peripheral device |
| JP4940478B2 (ja) | 2005-12-23 | 2012-05-30 | エスティー‐エリクソン、ソシエテ、アノニム | 同期シリアルｔｄｍａバス上のフロー制御方法 |
| WO2007083278A1 (en) | 2006-01-20 | 2007-07-26 | Nokia Corporation | Distributed (modular) internal architecture |
| US7860541B2 (en) | 2006-03-30 | 2010-12-28 | Motorola, Inc. | Apparatus for conveying information in a portable communication device |
| US7743129B2 (en) | 2006-05-01 | 2010-06-22 | International Business Machines Corporation | Methods and arrangements to detect a failure in a communication network |
| EP1860808A1 (en) | 2006-05-25 | 2007-11-28 | STMicroelectronics (Research & Development) Limited | Frame synchronization and clock recovery using preamble data that violates a bi-phase mark coding rule |
| US7983308B1 (en) * | 2006-11-28 | 2011-07-19 | Marvell International Ltd. | Method and apparatus for data frame synchronization |
| US8064826B2 (en) | 2007-01-31 | 2011-11-22 | Broadcom Corporation | Intra-device RF bus and control thereof |
| US7365669B1 (en) | 2007-03-28 | 2008-04-29 | Cirrus Logic, Inc. | Low-delay signal processing based on highly oversampled digital processing |
| KR101116617B1 (ko) | 2007-07-20 | 2012-03-07 | 삼성전자주식회사 | Ｉ２Ｓ（Ｉｎｔｅｒ－ＩＣ Ｓｏｕｎｄ） 형식의 오디오전송과 처리에 관한 방법 및 그 장치 |
| WO2009045904A1 (en) | 2007-10-02 | 2009-04-09 | Openpeak, Inc. | System and method for inter-processor communication |
| TWI338227B (en) | 2007-11-02 | 2011-03-01 | Inventec Corp | Structure compatible with i2c bus and system management bus and timing buffering apparatus therein |
| US8213666B2 (en) | 2008-06-26 | 2012-07-03 | Microsoft Corporation | Headphones with embeddable accessories including a personal media player |
| ATE543139T1 (de) | 2008-07-16 | 2012-02-15 | St Microelectronics Rousset | Schnittstelle zwischen einem doppelleitungsbus und einem einzelleitungsbus |
| US8239597B2 (en) | 2008-07-18 | 2012-08-07 | Intersil Americas Inc. | Device-to-device communication bus for distributed power management |
| FR2934390B1 (fr) | 2008-07-22 | 2010-08-13 | St Microelectronics Rousset | Transmission multicanaux sur un bus unifilaire |
| US9203533B2 (en) | 2008-07-24 | 2015-12-01 | Line 6, Inc. | System and method for real-time wireless transmission of digital audio at multiple radio frequencies |
| WO2010058008A1 (de) * | 2008-11-21 | 2010-05-27 | Continental Tevesag & Co. Ohg | Datenübertragungsprotokoll |
| US8019096B2 (en) | 2009-04-10 | 2011-09-13 | Apple Inc. | Electronic device and external equipment with configurable audio path circuitry |
| JP5235763B2 (ja) * | 2009-04-15 | 2013-07-10 | 三菱電機株式会社 | マルチプロトコル収容装置 |
| WO2010147264A1 (en) | 2009-06-16 | 2010-12-23 | Lg Electronics Inc. | Method of exchanging messages and transmitting and receiving devices |
| GB2478795B (en) | 2010-03-19 | 2013-03-13 | Imagination Tech Ltd | Requests and data handling in a bus architecture |
| US9215529B2 (en) | 2010-07-18 | 2015-12-15 | Bose Corporation | Multi-mode audio device interfacing |
| US8837529B2 (en) | 2010-09-22 | 2014-09-16 | Crestron Electronics Inc. | Digital audio distribution |
| EP2466481A1 (en) | 2010-12-02 | 2012-06-20 | Research In Motion Limited | Single wire bus system |
| US8775707B2 (en) | 2010-12-02 | 2014-07-08 | Blackberry Limited | Single wire bus system |
| US9032131B2 (en) | 2011-02-04 | 2015-05-12 | Blackberry Limited | Systems and methods for encoding control messages in an audio bitstream |
| US8675690B2 (en) * | 2011-04-19 | 2014-03-18 | Honeywell International Inc. | Low latency and self-adjusting frame synchronization algorithm for data streaming applications |
| US20130108068A1 (en) | 2011-10-27 | 2013-05-02 | Research In Motion Limited | Headset with two-way multiplexed communication |
| US9594536B2 (en) | 2011-12-29 | 2017-03-14 | Ati Technologies Ulc | Method and apparatus for electronic device communication |
| US9479275B2 (en) | 2012-06-01 | 2016-10-25 | Blackberry Limited | Multiformat digital audio interface |
| KR101733273B1 (ko) | 2012-06-01 | 2017-05-24 | 블랙베리 리미티드 | 다중 포맷 오디오 시스템들에서의 확률적 로크 보장 방법에 기초한 범용 동기화 엔진 |
| US9461812B2 (en) | 2013-03-04 | 2016-10-04 | Blackberry Limited | Increased bandwidth encoding scheme |
-
2013
- 2013-03-14 KR KR1020147037058A patent/KR101733273B1/ko active IP Right Grant
- 2013-03-14 AU AU2013270397A patent/AU2013270397B2/en active Active
- 2013-03-14 EP EP13796542.2A patent/EP2856690B1/en active Active
- 2013-03-14 CN CN201380040806.7A patent/CN104541473B/zh active Active
- 2013-03-14 CA CA2874899A patent/CA2874899C/en active Active
- 2013-03-14 US US13/803,393 patent/US9252900B2/en active Active
- 2013-03-14 JP JP2015514293A patent/JP6362277B2/ja active Active
- 2013-03-14 WO PCT/CA2013/000232 patent/WO2013177665A1/en active Application Filing
-
2015
- 2015-04-28 HK HK15104091.3A patent/HK1203712A1/xx unknown
-
2016
- 2016-01-29 US US15/011,158 patent/US9672177B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| WO2013177665A8 (en) | 2014-11-27 |
| JP2015525507A (ja) | 2015-09-03 |
| KR101733273B1 (ko) | 2017-05-24 |
| AU2013270397A1 (en) | 2014-12-18 |
| US20130322462A1 (en) | 2013-12-05 |
| US9252900B2 (en) | 2016-02-02 |
| US9672177B2 (en) | 2017-06-06 |
| CN104541473B (zh) | 2017-09-12 |
| CA2874899A1 (en) | 2013-12-05 |
| CN104541473A (zh) | 2015-04-22 |
| US20160147686A1 (en) | 2016-05-26 |
| WO2013177665A1 (en) | 2013-12-05 |
| EP2856690B1 (en) | 2020-12-02 |
| EP2856690A4 (en) | 2016-02-17 |
| KR20150016618A (ko) | 2015-02-12 |
| HK1203712A1 (en) | 2015-10-30 |
| CA2874899C (en) | 2017-07-11 |
| EP2856690A1 (en) | 2015-04-08 |
| AU2013270397B2 (en) | 2015-11-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP6362277B2 (ja) | マルチフォーマットオーディオシステムにおけるロック保証のための確率的方法に基づく汎用同期エンジン | |
| JP6013596B2 (ja) | マルチフォーマットデジタルオーディオインターフェース | |
| US9461812B2 (en) | Increased bandwidth encoding scheme | |
| US8775707B2 (en) | Single wire bus system | |
| US9473876B2 (en) | Method and system for tunneling messages between two or more devices using different communication protocols | |
| KR20160066029A (ko) | 저전력 카메라 제어 인터페이스 버스 및 디바이스들 | |
| US20200272592A1 (en) | Methods and apparatus to transition devices between operational states | |
| US20230396504A1 (en) | Node discovery and configuration in a daisy-chained network | |
| US10171092B2 (en) | Time clock signal processing system and method thereof | |
| US20140040652A1 (en) | Sideband initialization | |
| KR102568225B1 (ko) | 반도체 장치, 반도체 시스템 및 반도체 장치의 동작 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20160115 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20160122 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20160422 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20160916 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20170116 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20170124 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20170310 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20180625 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6362277 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |