データ・バス特性
データ・フォーマット
デジタル・データは、サポートされる任意の形式で送信することができます。バス上のすべてのデータは、クアドレット(32Bitワード)で整列されなければなりません。 すべての浮動小数点は、IEEE-754浮動小数点形式に準拠しなければなりません。パケットは、また、クアドレット(32Bitワード)でなければならず、クアドレット(32Bitワードで整列)で終了する必要があります。
サポートされるデータ型のサイズの定義については、表1を参照してください。これは、CORBA標準のデータ型が含まれています。
表1 サポートされるデータ型
ビット順序
1394ネットワーク上で送信されるすべてのデータは(バイトおよび、ビット)、ビッグ・エンディアン形式でなければなりません。 ビッグ・エンディアン形式では、Bit 0が最上位ビット(MSB)、Bit 31が最下位ビット(LSB)となります。図4に2つのビット順序の構造を示します。
図4 ビット順序
伝送方法
伝送ビット・レート
伝送ビット・レートは、S100(100Mbps)、S200(200Mbps)、S400(400Mbps)、S800(800Mbps)、S1600(1600Mbps)、S3200(3200Mbps)が許可されています。
パケット・サイズ
非同期ストリーム送信ビット・レートの最大パケット・サイズは、IEEE-1394仕様で規定されるものと一致しなければなりません。「ペイロード・データ領域」を参照してください。
IEEE-1394パケット・フォーマット
データ・パケットのフォーマットは、IEEE-1394規格に適合しなければなりません。サポートされるパケット・フォーマットは次項で説明します。
非同期ストリーム・パケット
非同期ストリーム・パケットは、通常は非同期の時間間隔中に送信されるアイソクロナス・パケットです。 図5は、バス上で見られる、一般的なストリーム・パケットを示しています。これらのパケットは、AS5643仕様書で定義され、 ハードウェアによって挿入される1394ヘッダ、ASMヘッダ、ペイロード・データ・エリア、パケット・トレーラ、ハードウェアによって挿入される1394 CRCから構成されます。
図5 非同期ストリーム・パケット
データ長 [Data Length] |
データ長フィールドは、パケット内のデータのバイト数を指定します。 これは、ASMヘッダ、ペイロード・データ、パケット・トレーラが含まれています。これは、符号なし短整数型(16Bit)でなければなりません。 ペイロード・データ領域にある実際のデータ・バイト数は、ASMヘッダ(16Byte)および、データ長フィールド~パケット・トレーラ(16Byte)のサイズの大きさを引くことによって決定することができます。 |
タグ [Tag] |
タグ・フィールドには、アイソクロナス・パケット(00=フォーマットされた、01-11予約)によって運ばれるデータのフォーマットを示しています。 このフィールドはゼロ(00)に設定します |
チャンネル [Channel] |
チャンネル・フィールドは、非同期ストリームの宛先を識別します。 リモート・ノード・チャンネル番号の割当ての例は、「宛先ノードのチャンネル割当て」で定義されています |
Tコード [Tcode] |
Tコード・フィールドは、非同期ストリーム・パケット・タイプを識別するために、バイナリで1010を設定しなければなりません |
Sy | Syフィールドは、使用されておらず、ゼロ(0)に設定します |
ヘッダCRC /データCRC [Header CRC /Data CRC] |
ヘッダCRCおよび、データCRCフィールドはIEEE-1394リンク層によって生成されます。CRCアルゴリズムは、IEEE-1394-1995仕様を参照してください |
ASM ヘッダ [ASM Header]
パケット・データ領域を含むバス上のすべての非同期ストリーム・パケットは、最初の4つのデータ・ペイロードの32 BitクアドレットとしてASMヘッダと共に送信されなければなりません。 ASMヘッダは、図6のようになります。
図6 ASMヘッダ
メッセージID [Message ID] |
ASMヘッダのWord 0はメッセージID(分解能1の符号なし長整数型)を含みます。メッセージIDは、32Bitパターンで一意でなければなりません。 ビット定義については、「(2) メッセージIDビット定義 [Message ID Digits]」を参照してください。 この要件は、異なるCCチャンネル上で動作する冗長1394ノードに適用されます。 例えば、CC-AネットワークのLRU #1とCC-CネットワークのLRU #2のロード・イメージは、同一の1394出力メッセージを出力します。 LRU #1メッセージは、データ内容が同一であっても、LRU #2メッセージIDとは異なるメッセージIDを持ちます。これは、LRUの入力だけでなく出力にも適用されます。 その結果、LRUはある程度の識別または、入力が#1または#2であるかどうかの判断が必要となります。 |
メッセージID ビット定義 [Message ID Digits] |
メッセージIDは、符号なし長整数型として表され、32Bitの数値でなければいけません。 例では、メッセージが始まるCCブランチを識別するために使用されるメッセージIDの最初の2桁の10進数を利用します:01=ブランチA、02=ブランチB、03=ブランチCなど。 これは、最大41ブランチまで用意されています。次の2 デジットは、論理サブシステム(1394は63チャンネルに制限されています)のチャンネル番号を表します。 残りの6 デジットは、論理サブシステムあたり00~999,999の1,000,000メッセージ番号を表します。 |
セキュリティ [Security] |
ASMヘッダのWord 1は、セキュリティ・フィールドを含みます。ゼロ(0)がセキュリティの最低レベルを示します。 セキュリティが必要とされず、必要に応じて各リモート・ノードによって利用することができます。それが使用されていない場合、セキュリティ・フィールド(0)に設定しなければなりません。 |
ノードID [Node ID] |
ASMヘッダのWord 2は、そのノードのPHYデバイスによって報告されるIEEE-1394ノードID(分解能1の符号なし長整数型)を含みます。 これは16Bitの整数で、一意に相互接続されたバスの、グループ内の他のすべてのノードからノードを区別します。 ノードIDの最上位ビット(MSB)が同一バス上で全て同じになります:この値がバスIDです。ノードIDの6つの最下位ビット(LSB)が同じバス上の各ノードに固有です:この値は物理IDと呼ばれます。 物理アドレスは、バスの初期化の結果として割当てられます。 |
優先度 [Priority] |
Word 3の最上位バイト(FC-AE-ASMで定義される「L」ビット)の最上位ビットはゼロに設定され、使用してはいけません。 ワード3の最上位バイトの残りのビットは、オプションのメッセージ優先度のフィールを含まなければなりません。 これらのビット「0000000」の値は、優先度がフレームに割当てられていないことを示さなければなりません。 残りの値は、昇順で、フレームの相対的な優先順位(例:0x23の優先順位は、0x57の優先順位よりも低い優先度を持つものとします)を示さなければなりません。 |
ペイロード長 [Payload Length] |
Word 3 の最下位3バイトは、ペイロード長(分解能1の符号なし短整数型ワード形式)を含みます。 ペイロード長は、メッセージIDに関連付けられたメッセージ全体のバイト数でなければなりません。 ペイロード長の計算は、ASMヘッダやパケット・トレーラは含まれていませんが、ハートビートとヘルス・ステータス・ワードは含まれます。 したがって、最大ペイロード・サイズは、IEEE-1394b-2002仕様で指定された、32バイトより小さく、最小のペイロード・サイズは、8バイト(ハートビートとヘルス・ステータス・ワード)です。 実際のメッセージ・データ・サイズは、ハートビートとヘルス・ステータスが含まれるため制限されます。 メッセージ・サイズが限られるため、ペイロード長の最下位2バイトを使用しなければなりません。3番目のバイトは0で埋めなければなりません。 これは、符号なし短整数でなければなりません(16Bit)。ペイロード・データ領域の内容については、「ペイロード・データ領域」を参照してください |
ペイロード・データ領域
ペイロード・データ領域は、非同期ストリーム・パケットデータ領域のWord 2から始まります。許容されるデータ型は、「3.2.1 データ・フォーマット」を参照してください。 すべてのペイロード・データは、32Bitアライメントされたデータでなければなりません。図7にパケット・データ領域の内容を示します。
メッセージ・サイズの要件を満たすために、実際のペイロード・データ・サイズが制限されなければなりません。 ASMヘッダ(4クアドレット)、パケット・トレーラ(4クアドレット)、ヘルス・ステータス・ワード(1クアドレット)、ハートビート(1クアドレット)は、IEEE-1394b-2002仕様で指定された最大パケット・サイズから差し引かなければなりません。 これは、仕様の最大値より10クアドレット少ない最大メッセージ・サイズ長になります。
図7 ペイロード・データ・サイズ
(1) ヘルス・ステータス・ワード [Health Status Word]
ペイロード・データ領域のWord 0は、ヘルス・ステータス・ワードを含みます。ヘルス・ステータス・ワードは、32Bitワード(Long Packed Boolean)でなければなりません。
ヘルス・ステータス・ワードは最低限次のことを含まなければなりません:
- パケット・エラー(Packet Error)
- サブシステム・エラー(Subsystem Error)
- ノード・エラー(Node Error)
- ノード上の各ポートのステータス - 接続されているかどうか、受信OKかどうか、ベータ・モードかどうか、スピードをネゴシエートされたかどうか
以下は、必要なステータスの書式設定の例を挙げています。
LSB Bit 31 | パケット・エラー | Packet Error |
Bit 30 | サブシステム・エラー | Subsystem Error |
Bit 29 | ノード・エラー | Node Error |
Bit 28 | STOFオフセットAck | STOF Offset Acknowledge |
Bit 27 | 予備 | Spare |
Bit 26 | 予備 | Spare |
Bit 25 | 予備 | Spare |
Bit 24 | 予備 | Spare |
Bit 23 | ポート0 - 接続 | Port 0 - Connected |
Bit 22 | ポート0 - 受信OK | Port 0 - Receive OK |
Bit 21 | ポート0 - ベータ・モード | Port 0 - Beta Mode |
Bit 20 | ポート0 - スピードBit 0 | Port 0 - Speed Bit 0 |
Bit 19 | ポート0 - スピードBit 1 | Port 0 - Speed Bit 1 |
Bit 18 | ポート0 - スピードBit 2 | Port 0 - Speed Bit 2 |
Bit 17 | ポート0 - 予備 | Port 0 - Spare |
Bit 16 | ポート0 - 予備 | Port 0 - Spare |
Bit 15 | ポート1 - 接続 | Port 1 - Connected |
Bit 14 | ポート1 - 受信OK | Port 1 - Receive OK |
Bit 13 | ポート1 - ベータ・モード | Port 1 - Beta Mode |
Bit 12 | ポート1 - スピードBit 0 | Port 1 - Speed Bit 0 |
Bit 11 | ポート1 - スピードBit 1 | Port 1 - Speed Bit 1 |
Bit 10 | ポート1 - スピードBit 2 | Port 1 - Speed Bit 2 |
Bit 09 | ポート1 - 予備 | Port 1 - Spare |
Bit 08 | ポート1 - 予備 | Port 1 - Spare |
Bit 07 | ポート2 - 接続 | Port 2 - Connected |
Bit 06 | ポート2 - 受信OK | Port 2 - Receive OK |
Bit 05 | ポート2-ベータ・モード | Port 2 - Beta Mode |
Bit 04 | ポート2-スピードBit 0 | Port 2 - Speed Bit 0 |
Bit 03 | ポート2-スピードBit 1 | Port 2 - Speed Bit 1 |
Bit 02 | ポート2-スピードBit 2 | Port 2 - Speed Bit 2 |
Bit 01 | ポート2 - 予備 | Port 2 - Spare |
MSB Bit 00 | ポート2 - 予備 | Port 2 - Spare |
(a) ヘルス・ステータス・ワード [Health Status Word]
「メッセージ整合性管理」のCCおよび、「システム整合性管理」のリモート・ノードで定義されたノード間の前述のメッセージがエラーで受信された場合、
メッセージ・エラー・ビットが1にセットされます。それ以外の場合は、メッセージ・エラー・ビットはゼロにクリアされなければなりません。
(b) サブシステム・エラー [Subsystem Error]
サブシステム・エラー・ビットは、ノードが接続されているサブシステムの故障を示すために1にセットされなければなりません。
それ以外の場合は、サブシステム・エラー・ビットはゼロにクリアされなければなりません。
(c) ノード・エラー [Node Error]
ノード・エラー・ビットは、ノードの故障を示すために1にセットしなければなりません。それ以外の場合は、ノード・エラー・ビットはゼロにクリアされなければなりません。
(d) STOF オフセットAck [STOF Offset Acknowledge]
STOF オフセットAckビットは、リモード・ノードがすべてのSTOFオフセットを受信したことを示すために、1にセットされなければなりません。
リモート・ノードがそのSTOFオフセットのすべてを受信していない場合STOF オフセットAckビットはゼロにクリアされなければなりません。
(e) ポートn 接続 [Port n - Connected]
PHYポートのステータス・レジスタを読み出した結果は、ポートが接続されていることを示す場合、1にセットされなければなりません。
ステータスが、ポートが接続されていないことを示している場合、ビットはゼロにクリアされなければなりません。
(f) ポートn 受信OK [Port n - Receive OK]
PHYポート・ステータス・レジスタを読み出した結果、ポートが受信していることを示す場合、受信OKビットが1に設定されます。
ポートが受信していない場合は、ステータス表示がゼロにクリアされます。
(g) ポートn ベータ・モード [Port n - Beta Mode]
スピード・ビットは、PHYポート・ステータスのスピード・ビット・レジスタから読取った値にしなければなりません。
これらのビットは、IEEE-1394仕様で定義され、そのときのポートが動作しているスピードを示しています。スピード・ビット・デコードについては、表2を参照してください。
(2) ハートビート [Heartbeat]
パケット・ペイロード・データ領域のWord 1は、メッセージを生成するノードのハートビートを含みます。ハートビートは、32Bit Word(符号なし倍長整数型)でイニシャライズで0に初期化され、
新しいデータを格納したフレーム毎に1インクリメントされます。 ハートビートの目的は、通信リモート・ノードが新しいデータを生成していることをCCで実行されているアプリケーションで確認することです。
したがって、ハートビートは、独立したタイマによって挿入されるのでは無く、アプリケーション・ソフトウェアによって生成されなければなりません。
パケット・トレーラ [Packet Trailer]
ペイロードのパケット・データ領域を含むバス上のすべての非同期ストリーム・パケットは、最後の4つの32Bit クアドレットをパケット・トレーラで送信しなければなりません。 パケット・トレーラは、図8のようになります。
図8 パケット・トレーラ
(1) STOF送信オフセット [STOF Transmit Offset]
パケット・トレーラのWord 0には、STOF送信オフセット(符号なし長整数型)が含まれます。STOF送信オフセットは、STOFフレーム・レートの1.0%以上または、100μsecの精度でなければなりません。
STOF送信オフセットの分解能は、1.0%以下であることが定義されています。例えば、100Hzのフレーム・レートは、±100μsecの正確さと、1.0μsecの分解能を必要とします。
「リモート・ノード→CC」メッセージの場合、これは、リモート・ノードが使用しているオフセットになります。
(2) STOF受信オフセット [STOF Receive Offset]
パケット・トレーラのWord 1には、STOF受信オフセット(符号なし長整数型)が含まれます。STOF受信オフセットは、STOFフレーム・レートの1.0%以上または、100μsecの精度でなければなりません。
STOF受信オフセットの分解能は、1.0%以下であることが定義されています。
例えば、100Hzのフレーム・レートの場合は、±100μsecの精度と1.0μsecの分解能が要求されます。
「CC→リモード・ノード」メッセージの場合、これは、ノードへのコマンド・オフセットになり、データがリンク層チップのFIFOで利用できるように期待することができます。
「リモート・ノード→CC」メッセージの場合、これは、リモート・ノードが使用しているオフセットになります。
リモート・ノードに宛てたメッセージは、受信オフセット命令以外のタイミングでバス上に存在することができます。これは、バス上のすべてのデータが適切なオフセットにあるかもしれないことを意味します。
このような理由から、同期外の動作は、バス上でサポートされるべきである。受信オフセット命令は、ループ閉鎖などの待ち時間に依存する操作などに使用されます。
(3) STOFデータポンプ・オフセット [STOF Data pump Offset]
パケット・トレーラのWord 2には、STOFデータポンプ・オフセット(符号なし長整数型)を含まなければなりません。
STOFデータポンプ・オフセットは、STOFフレーム・オフセットまたは100μsec、1.0%精度のいずれか大きい方を持たなければなりません。
STOFデータポンプ・オフセットの分解能は、1.0%以下の精度であるべきです。
例えば、100Hzのフレーム・レートの場合は、±100μsecの精度と1.0μsecの分解能が要求されます。
CCからのリモート・メッセージの場合、これは、ノードに対してオフセット指令され、その時点で送信開始することができます。
「リモート・ノード→CC」メッセージの場合、これは、リモート・ノードが使用しているオフセットになります。
(4) 垂直パリティ・チェック [Vertical Parity Check]
パケット・トレーラのWord 3には、垂直パリティ・チェック(VPC)を含まなければなりません。垂直パリティ・チェックは、符号なし長整数型でなければなりません。
次のように垂直パリティ・チェックを行わなければなりません:
- 垂直パリティ・ワードを除くIEEE-1394パケットのデータ・ペイロードにおいて、32Bitワード毎にビット単位(キャリー無し)の排他的論理和を実行します。
- 排他的論理和の結果のビット単位の否定を実行します。
非同期ストリーム・パケットのVPCを計算する例は次の通りです。
① VPC = ASMヘッダのメッセージID
② VPC = VPC XOR ASMヘッダのセキュリティ・ワード
③ VPC = VPC XOR ASMヘッダのノードID
④ VPC = VPC XOR ASMヘッダの優先度/ペイロード長ワード
⑤ VPC = VPC XOR ペイロード・ヘッダのヘルス・ステータス・ワード
⑥ VPC = VPC XOR ペイロード・ヘッダのハートビート・ワード
⑦ VPC = VPC XOR ペイロード・ヘッダの残りのペーロード・パケット・データ
⑧ VPC = VPC XOR パケット・トレーラのSTOF送信オフセット
⑨ VPC = VPC XOR パケット・トレーラのSTOF受信オフセット
⑩ VPC = VPC XOR パケット・トレーラのSTOFデータポンプ・オフセット
⑪ VPC = ビット単位のNOT演算
非同期トランザクション
非同期トランザクションは、Ackやnegative-Ackが必要な時に使用できます。例として、ソフトウェアのロードまたは、統合サポートのメッセージなどです。非同期パケットのフォーマットを図9に示します。
図9 非同期トランザクション・パケット
宛先ID [Destination ID] |
宛先IDフィールドは、受信ノードのノードIDでなければなりません |
tl |
このトランザクションを識別し、リクエスタが指定したラベル。tlフィールドは、書込み要求サブアクションが属する特定のトランザクションを識別するために、 一意のトランザクション・ラベルでなければなりません。 この値は応答パケットに返信されます |
rt |
rtフィールドは、必要とされるリトライ方法を示すように設定しなくてはなりません |
Tコード [Tcode] |
Tコード・フィールドは、IEEE-1394a-2000仕様で定義されているトランザクション・タイプを識別するために適切な値に設定しなければなりません |
pri |
priフィールドは0にセットしなくてはなりません |
ソースID [Source ID] |
ソースIDフィールドは、送信ノードのノードIDを設定しなければなりません |
宛先オフセット [Destination Offset] |
宛先オフセット・フィールドの下位32 Bitは、書込みを要求された32 Bitオフセットメモリに設定されなければなりません |
データ長 [Data Length] |
データ長フィールドは読込/書込みされるメッセージのバイト数を指定しなければなりません。これは符号なし短整数型(16 Bit)でなければなりません |
拡張Tコード [Extended Tcode] |
拡張Tコードはターゲット・アプリケーションで定義された値を設定しなければなりません |
ペイロード [Payload] |
ペイロード・フィールドは、特定のデータ・メッセージのすべてのデータを含まなければなりません |
ヘッダCRC /データCRC [Header CRC /Data CRC] |
ヘッダおよび、データのCRCフィールドは、IEEE-1394のリンク・レイヤによって生成されます。CRCアルゴリズムはIEEE-1394仕様を参照してください |
Ackパケット
図10に示すように、Ackパケットは、AckコードとAckパリティから構成されます。 「ace_parity」は、「ack_code」の1の補数(0と1を反転させた値)です。Ackコードの仕様は、IEEE-1394仕様を参照してください。
図10 Ackパケット
IEEE-1394bデータ・バス初期化とコンフィグレーション
IEEE-1394bデータ・バスの初期化は、以下の状況下で開始されます:
- PHYの電源状態の変更があった時
- ノードの追加
- ノードの削除
3つの主要な手順は、初期化時に実行する必要があります:
- デバウンス遅延を開始する
- バス・リセットを完了する
- デバイスの構成
デバウンス遅延
各リモート・ノードが接続/電源が投入されると、それらの内部で350msecのデバウンス遅延を生成します。デバウンス遅延が完了すると、バス上にリセット信号を送信します。 すべてのノードが同時に電源投入されるわけではないので、最後のノードの電源がオンになるまで、バスの初期化は継続されます。
バス・リセット
バス・リセットは、次の状況下で開始されます: PHYの電源状態に変更があった時 ノードの追加 ノードの削除 PHYは、ソフトウェアによって開始されるバス・リセット要求の受信 最大アービトレーション・タイムアウトに達した場合 ポート・サスペンド/無効 上記のいずれかの条件がPHYによって検出されると、バス・リセット信号を送ります。バス・リセットの結果、各ポートのトポロジ情報はクリアされ、CRCレジスタ値は影響を受け、いくつかのPHYレジスタ値がディフォルトに戻ります。
IEEE-1394b デバイス・コンフィグレーション
IEEE-1394bデバイスのコンフィグレーションは、ホスト・プロセッサの介入無しにバスの中で局所的に開始されます。 毎回新しいデバイス、またはノードが、バスから取外された、または、取付けられたとき、バス全体がリセットされ、再コンフィグレーションされます。 3つの主要な手順は、コンフィグレーション中に実行する必要があります: ツリー識別 自己識別 スピード・ネゴシエーションの実施
スピード・ネゴシエーション
バス初期化の最後のコンポーネントの間に、ノードが使用可能な最大スピードをネゴシエートするように相互にトーンを送り始めます。
ツリー識別
バス初期化後、ノードはルート・ノードと接続されているすべてのノードのトポロジを識別するために、ツリー識別フェーズを開始します。 階層ツリー構造内のツリー識別処理結果、ループは許可されず、PHYが切断され、図3のようになります。
自己識別
ツリー認識フェーズ完了後、自己識別プロセスが開始されます。このプロセス中にノード・コンフィグレーションが開始されます。 次のアクションは自己識別の間に実行されます: 物理IDを各ノードに割当てる 隣接するノードと送信速度能力の交換 ツリー識別の間に定義されたトポロジは、すべてのノードにブロードキャストを行う バス・コンフィグレーションが完了すると、最も高い番号のノードIDのノードがルート・ノードとなります。最も高い番号付きノードIDを持つノードと、IRM contenderビットがセットされていることは、 アイソクロナス・リソース・マネージャIDのアイソクロナス・パケットが利用していることになります。ルート・ノードから最も離れたノードは、ゼロ(0)のノードIDを持ちます。 ルートに近いノードが連続して高いノードIDを持つことになります。 全体のバス初期化と設定プロセスのタイミング図については、図11を参照してください。
図11 初期化とコンフィグレーション・タイミング
AS5643解説文書【日本語技術資料プレゼント】
AS5643(Mil1394)通信規格の日本語解説書(計52ページ)をIPROSにて配布しており、ダウンロードいただけます。