JP2000156696A - デ―タ通信システム用のトランズアクションインタ―フェ―ス - Google Patents

Abstract

(57)【要約】 （修正有） 【課題】 １３９４スタンダードに準拠した高速直列バ
ス用のシステムアーキテクチュアを提供する。 【解決手段】 メモリ資源の割り当てを行い且つ多様な
タスク及びサービスの開始のためカーネル／スケジュー
ラ／ディスパッチャを使用する。タスク及びサービスは
１３９４レイヤに関連するトランスポートレイヤ及びア
プリケーションレイヤで使用されるプロトコルで異な
る。各タスクはステートマシンの進捗状態に従って動作
する。インターフェースはタスクからのデータ情報を受
付け且つ１３９４バスへ送るためのパケットを形成す
る。パケットは初期的には関連するハードウエアレジス
タを介して送られるが、ビジーの場合は、インターフェ
ースは他の使用可能なレジスタに対しポーリングを行
う。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、データ通信システ
ムへ接続されている装置間での通信に関するものであ
る。更に詳細には、本発明は、高速直列バスへ結合され
ているノード内のタスク及びサービスからデータを受取
り且つ該データを高速直列バス上に配置させるトランズ
アクションインターフェースに関するものである。更
に、本発明は、バスからデータパケットを受取り且つト
ランズアクションインターフェースが存在するノードに
おいて使用するためにそれらをフォーマット化する技術
に関するものである。

【０００２】

【従来の技術】一般的に、２つのタイプのデータバス、
即ち直列バスと並列バスとが存在している。並列バス
は、典型的に、容量及び速度で評価される。並列バス幅
容量はバイトが使用され且つ速度はＭＨｚ即ちバイト／
秒が通常使用される。例えば、ポピュラなペリフェラル
コンポーネントインターコネクト（ＰＣＩ）バスは３２
ビット幅で最大で３３ＭＨｚで動作する並列バスであ
る。この周波数においては、毎秒１ギガビット（１Ｇｂ
ｐｓ）を超えるレート即ち速度でデータを搬送すること
が可能である。並列バスの顕著な特徴は、その幅内の全
てのビットが同時的に送信されるというものであり、例
えば、ＰＣＩバスにおいては、３２ビットの全てが１つ
のサイクル期間中に同時に送信される。このことは少な
くともバス内においてその幅と同じ数の信号線を必要と
し、且つアドレッシング、電力及びその他の信号のため
に付加的な線を必要とする。ＰＣＩバスはほぼ５０本の
信号線を有している。信号線は、通常、プリント回路ボ
ード上のトレース又はワイヤとして実現される。並列バ
スにおける多数の信号線はそれを実現することを高価な
ものとしている。更に、ＰＣＩバス上のデバイス即ち装
置数が制限され且つ各装置はカードを必要とすると共に
バスへプラグインするためにオープンな対応するカード
スロットを必要とする。

【０００３】一方、直列バスは一度に１ビットのデータ
を転送する。このことは直列バスに対して必要とされる
線数を減少するものであるが、それは並列バスと比較し
てデータを転送するのに必要な時間を著しく増加させ
る。例えば、同一の周波数で動作している場合には、Ｐ
ＣＩバスが３２個のビットを送信するのと同じ時間にお
いて直列バスは単に１ビットのデータを送信するに過ぎ
ない。直列バスの１例はユニバーサルシリアルバス（Ｕ
ＳＢ）である。このバスは４本のワイヤを有しており、
且つ最大で毎秒１２メガビット（Ｍｂｐｓ）のデータレ
ートを有している。ワイヤの数が少ないということはケ
ーブルを介してデバイス即ち装置を相互接続するのに直
列バスを理想的なものとしている。何故ならば、ケーブ
ルは安価に製造することが可能だからである。然しなが
ら、データ集約的な適用例は迅速に大量のデータを移動
させることを必要とするので、製造業者等はデータ集約
的な装置を相互接続するためには直列バスではなく通常
並列バスに依存する。このようなデータ集約的な装置を
使用する適用例としては、例えば、ビデオ及びオーディ
オ再生、及び例えばハードディスクドライブ等の高速格
納（記憶）メカニズム等）がある。

【０００４】現在までのところ、バスを介してデータを
移動させるシステムの設計者等は高速且つ高価な並列バ
ス又は低速且つ安価な直列バスの間で選択をせねばなら
なかった。最近になって、高速直列バス用の仕様が米国
電気及び電子技術者協会（ＩＥＥＥ）によって採用され
た。その仕様であるＩＥＥＥ１３９４−１９９５は「フ
ァイヤワイヤ（Ｆｉｒｅ Ｗｉｒｅ）」又は単に１３９
４として知られる幾つかのプロトコルスタンダードのう
ちの１つである。１３９４仕様は単に２対のデータワイ
ヤと１対の電力用のワイヤとを使用する最大で４００Ｍ
ｂｐｓのデータ転送レート用のスタンダードを包含して
いる。このデータレートはビデオ、オーディオ及び高速
格納（記憶）のデータ集約的な必要性を受付けるのに充
分に高速なものである。将来の必要性は１Ｇｂｐｓを超
えるデータレートを有する別の提案されている１３９４
スタンダードによって満足される。従って、１３９４ス
タンダードバスを使用することによって、並列バスを使
用することの欠点なしで、データ集約的なタスクを直列
バス上において廉価に実現することが可能である。１３
９４バスはピアツーピアアーキテクチュアを使用してい
る。６導体ケーブルによって物理的及び論理的ノードが
１３９４バスへ取付けられる。最大で６３個までのノー
ドが各独立したバスブリッジ上に接続することが可能で
あり、且つ１，０２３個のブリッジがシステム内におい
て許容され、全部で６５，０００個を超える装置が１個
の１３９４システム上に設けることが可能である。コン
ピュータにおいて１３９４バスが使用される場合には、
多分、オープンホストコントローラインターフェース
（ＯＨＣＩ）スタンダードを使用する１３９４対ＰＣＩ
インターフェースが使用される可能性がある。然しなが
ら、厳格に言えば、１３９４バスは接続ケーブルを介し
て関連する装置を一体的に結合させることによってコン
ピュータとは独立的に動作することが可能である。ケー
ブル仕様に加えて、バックプレーン仕様が１３９４バス
に対して設けられている。このバックプレーン仕様はコ
ンピュータ又は何等かのその他の自立システム内におけ
るバスに対して使用される蓋然性が高い。本明細書にお
いて記載するトランズアクションインターフェースはケ
ーブル環境又はバックプレーン環境のいずれにおいても
動作する。

【０００５】１３９４スタンダードは３つの「レイヤ
（ｌａｙｅｒ）」即ち層を特定しており、即ち、物理レ
イヤと、リンクレイヤと、トランズアクションレイヤで
ある。物理レイヤは直列バスに沿って電気信号を送信
し、一度に１個のノードのみがデータを送信することを
確保することによってバスの調停を行い、且つバスから
検知した電気信号をリンクレイヤ用のデータ信号へ変換
する。リンクレイヤはバスから検索されたデータ信号を
データパケットへ組立て、且つ例えばアドレッシング、
データチェック、タイミング及び同期のために使用され
る「サイクル」信号の発生等のサービスを提供する。ト
ランズアクションレイヤはリンクレイヤからのデータパ
ケットを受付け且つ読取、書込、ロックを包含するコマ
ンドステータスレジスタ（ＣＳＲ）アーキテクチュアを
サポートするために必要なバストランズアクション即ち
バス取扱い部を有している。幾つかのその他のバスはＣ
ＳＲスタンダードを使用し且つ１３９４がＣＳＲスタン
ダードに準拠せねばならないことを特定することは１３
９４バスをこれらのその他のバスへ適合させるか又は接
続することを容易なものとさせる。一般的に、制限され
た数のトランズアクション機能のみならず物理レイヤ及
びリンクレイヤがハードウエアにおいて表われる。トラ
ンズアクションレイヤ機能の残部はソフトウエアで実施
される。

【０００６】有用なものであるためには、付加的な通信
レイヤが１３９４レイヤと通信を行い且つその上方で動
作するものでなければならない。例えば、トランズアク
ションレイヤのすぐ上はトランスポートレイヤであり、
それは、例えば、ファンクショナルコントロールプロト
コル（ＦＣＰ）即ち機能的制御プロトコルと呼ばれる直
列バスプロトコル２（ＳＢＰ−２）又はスタンダードＩ
ＥＣ６１８８３ＦＣＰ／ＣＭＰを使用する。これらのス
タンダードは高性能直列バスを介してのコマンド及びデ
ータのトランスポート即ち搬送を行うためのプロトコル
を定義する。更に、トランスポートレイヤの上方には例
えばレデューストブロックコマンド（ＲＢＣ）、プリン
タワーキンググループ（ＰＷＧ）又はインターネットプ
ロトコル（ＩＰ）等のプロトコルスタンダードを使用す
るアプリケーションレイヤが存在している。これらのレ
イヤの相互のインタラクション及び１３９４仕様のレイ
ヤとのインタラクション即ち相互作用について更に詳細
に説明する。

【０００７】従って、各ノードが１３９４仕様において
概説されている全ての任務を便利な態様で実施すること
を助けるトランズアクションインターフェースを提供す
ることが所望されている。又、このようなトランズアク
ションインターフェースはそれに対して送られるデータ
を最も効果的な態様でルーチング即ち経路付けすること
が望ましい。

【０００８】

【発明が解決しようとする課題】本発明は、以上の点に
鑑みなされたものであって、上述した如き従来の技術の
欠点を解消し、高速の直列バスに接続されているノード
におけるタスク及びサービスからのデータを受取り且つ
そのデータを高速直列バスへ送る改良したトランズアク
ションインターフェースを提供することを目的とする。
本発明の別の目的とするところは、１３９４スタンダー
ドに準拠した高速直列バス用のインターフェース及びデ
ータ処理方法を提供することである。

【０００９】

【課題を解決するための手段】例えば１３９４バスシス
テム等のデータ通信システムにおいて、トランズアクシ
ョンインターフェースはバス上の論理ノードにおいて動
作する。パケットがトランズアクションインターフェー
スが設けられている特定のノードに向かってバス上を送
られると、そのトランズアクションインターフェースは
そのパケットの内容を更なる操作を行うために制御ブロ
ックへデコードする。その更なる操作は、局所的なノー
ドにおいて動作するアプケーションによる実行を包含す
ることが可能である。更に、該アプリケーションはバス
上の別のノードへデータを送信することを要求する場合
がある。この場合には、該アプリケーションはメッセー
ジ制御ブロックを介してトランズアクションインターフ
ェースと通信を行い、それは、次いで、データ信号へ変
換され且つデスティネーション（宛先）ノードで受取ら
れるべくバス上に配置される。

【００１０】本発明の１つの側面によれば、高速シリア
ルバス即ち直列バスへ結合されるトランズアクションイ
ンターフェースが提供される。本トランズアクションイ
ンターフェースは直列バスへ取付けられるトランズアク
ションハードウエアへ結合されている。本トランズアク
ションインターフェースはメッセージ制御ブロックを受
付けるキュー（待ち行列）を有しており、それは組織化
したデータと、該メッセージ制御ブロックを読取り且つ
それらをデータパケットへ変換する変換エンジンと、該
データパケットをバス上へ配置されるべき送信ベイへ通
過させる出力ポートとを有している。

【００１１】本発明の別の実施例においては、複数個の
レジスタがハードウエア内に設けられており且つトラン
ズアクションインターフェースは最も便利な態様でデー
タを送るためにオープン即ち開いているレジスタをポー
ルする。

【００１２】本発明の別の側面においては、直列バスに
対してデータのトランズアクション即ち取扱いを行う方
法が提供される。本方法は、バスへ送られるべきデータ
を受付け、該送られるべきデータを１つ又はそれ以上の
パケットへフォーマットし、メッセージ制御ブロック内
に含まれているその他のデータをパケット用のパケット
ヘッダへフォーマットし、該パケット及び該パケットヘ
ッダを直列バスに対するハードウエアインターフェース
へ書込む各ステップを有している。

【００１３】本発明の更に別の実施例においては、ハー
ドウエアインターフェースに対してパケット及びパケッ
トヘッダを書込む場合に、データ構造を評価して、ハー
ドウエアレジスタのうちのいずれかが現在使用可能であ
るか否かを決定し、且つ使用可能でない場合には、その
中にデータを有することのないハードウエアレジスタが
見つかるまで、順番に、ハードウエアレジスタの全てを
逐次的に評価することを包含している。

【００１４】

【発明の実施の形態】図１は１３９４バスアーキテクチ
ュアを実現する１つの方法を示している。バス１００は
３個のローカルバス、即ちＡ，Ｂ，Ｃに分割されてい
る。ローカルバスＡ及びローカルバスＣは、両方とも、
ローカルバスＢへ接続するためのブリッジ１１０を使用
している。デバイス即ち装置がローカルバス上のノード
として存在している。以下に説明するレイヤ構造にはバ
ス上のノードの全ての中に含まれている。該装置は、例
えば第一ハードディスクドライブ１２０、第二ハードデ
ィスクドライブ１２２、又はプリンタ１２４等のデータ
を発生し、受付け又は送信するために使用される任意の
装置とすることが可能である。各ローカルバスは最大で
６３個のノードを有することが可能であるが、バスブリ
ッジを使用することによって、１３９４バスシステムは
６５，０００個を超えるノードを有することが可能であ
る。典型的に、データトラフィックはローカルバスに制
限されており、従って、例えば、ローカルバスＣ上の装
置はローカルバスＡ上を通過するデータを見ることは不
可能である。このことはそのローカルバスに向けられて
いるローカルバス上のデータのみを通過させることによ
ってバスシステムの帯域幅を増加させている。バスブリ
ッジ１１０は、それに取付けられているローカルバス上
のバストラフィックをモニタし、別のローカルバス上の
ノードに対して意図されているデータを探し出す。この
ようなデータが検知されると、バスブリッジ１１０はそ
のデータを所望のバスへ転送する。従って、ローカルバ
スＡ上のプリンタ１２４はハードディスクドライブ１２
０（ローカルバスＡの上）か又はローカルバスブリッジ
１１０を介してハードディスクドライブ１２２（ローカ
ルバスＢの上）のいずれかからデータを受取ることが可
能である。更に、バスブリッジ１１０は１３９４バスを
例えばＰＣＩバス（不図示）等のコンピュータにおいて
典型的に使用されているバスへ結合させることが可能で
ある。

【００１５】図２は直列バス管理を含む１３９４のレイ
ヤ構造２の概略的な全体図を示している。このレイヤ構
造はローカル１３９４バスに取付けられている全てのノ
ードにおいて存在している。レイヤ構造には、トランズ
アクションレイヤ１０と、リンクレイヤ２０と、物理レ
イヤ３０と、直列バス管理４０とを有している。１３９
４レイヤに関連して、トランスポートレイヤ８０及びア
プリケーションレイヤ９０も上述した如くに使用されて
いる。レイヤ１０，２０，３０と直列バス管理４０及び
レイヤ８０及び９０との間の通信は双方向レイヤ間通信
５０を介して行われ、それは１つを超える通信経路を包
含することが可能である。通信５０はデータバスとする
ことは必要ではないが、例えば信号ワイヤ、共用メモリ
資源等の多数の通信方法のうちのいずれか又はその他の
手段とすることが可能である。図２に示したように、ト
ランズアクションレイヤ１０はリンクレイヤ２０、バス
マネジャ５５と直接的に通信を行い且つアイソクロノス
（等時性）信号を直列バス管理４０内に含まれているア
イソクロノス資源マネジャ６５へ通過させる。

【００１６】１３９４バス等の通信システムにおけるレ
イヤは、それらの周りのレイヤから独立しているがそれ
らと関連して動作すべく位置されている。一般的に、例
えば１３９４バスのデータワイヤ等のようにレイヤがハ
ードウエアから遠ければ遠い程、その次数は一層高い。
一層高い次数のレイヤはより高い次数の機能を実施する
ことが可能である。例えば、１３９４仕様のトランズア
クションレイヤ１０は読取／書込及びロック機能を実施
するに過ぎない。トランスポートレイヤ８０はトランズ
アクションレイヤ１０と通信を行い且つより高い次数の
コマンドを有している。使用される特定のトランスポー
トレイヤのスタンダードがそのコマンドを決定する。例
えば、ＳＢＰ−２トランスポートレイヤにおいては、例
えばログイン、再接続、及びパスワード設定等のコマン
ドを使用することが可能である。トランスポートレイヤ
８０より高いアプリケーションレイヤ９０は例えばＲＢ
Ｃ、ＰＷＧ又はＩＰ等のプロトコルを使用する。アプリ
ケーションレイヤ９０は所望のアプリケーションを実施
するためにソフトウエアに関連して動作する。

【００１７】１３９４仕様は２つの基本的なデータ転送
サービス、即ちアイソクロノス（等時性）データ転送及
び非同期データ転送を有している。アイソクロノスデー
タ転送仕様は規則的なインターバル即ち間隔で高速直列
バスに沿ってパケットを送信させる。典型的に、アイソ
クロノスデータ転送サービスはデータ発生器と例えばデ
ジタルビデオカメラ及びビデオディスプレイ等のマルチ
メディアエレクトロニクス又はビデオ編集器等のデータ
受信器との間で搬送される大量のデータに対して使用さ
れる。アイソクロノスデータ転送はリンクレイヤ２０と
直接的に通信を行い且つトランズアクションレイヤ１０
をバイパスする。トランズアクションレイヤは非同期デ
ータ転送のためにのみ使用される。１３９４仕様内の大
部分の帯域幅はアイソクロノスデータ転送のために予約
されており、その帯域幅の２０％が非同期データ転送の
ためである。

【００１８】ノード制御器７５がリンクレイヤ及び物理
レイヤへ直接接続されている。バスマネジャ５５、アイ
ソクロノス資源マネジャ６５及びノード制御器７５は、
各々、ＣＳＲスタンダードＩＥＥＥ１２１２−１９９１
に従って駆動される。その他のタイプのバスもこのＣＳ
Ｒスタンダードを使用し、１３９４バスの接続性を拡張
させている。ＣＳＲは直列バス管理４０内に位置されて
おり且つ管理ＣＳＲ５７、アイソクロノスＣＳＲ６７、
及びスタンダードＣＳＲ７７として表わされている。

【００１９】直列バス管理４０を有するレイヤ構造２は
バスに沿っての各ノード内に存在している。然しなが
ら、ローカルバス上において１つのバスマネジャ５５及
び１つのアイソクロノス資源マネジャ６５のみがアクテ
ィブ即ち活性状態である。これらのマネジャは全体的な
ローカルバスにわたって管理責任を実施する。各ローカ
ルバスは１個のバスマネジャ５５及び１個のアイソクロ
ノス資源マネジャ６５を必要とするに過ぎず（且つそれ
を有することが可能であるに過ぎないので）、他のノー
ドはそれらの夫々のバスマネジャ及びアイソクロノス資
源マネジャをディスエーブル即ち動作不能状態とさせ
る。ノード制御器７５は全ての動作可能なノードに対し
てアクティブ即ち活性状態にある。

【００２０】上述したように、リンクレイヤ２０及び物
理レイヤ３０は、通常、例えば、シリコンシステムデザ
イン、インポートレイテッドから入手可能であるか又は
テキサスイントルメンツ、インコーポレイテッドから入
手可能なチップ等のハードウエアで具体化されている。
トランズアクションレイヤ１０、トランスポートレイヤ
８０、アプリケーションレイヤ９０、及びその他のトラ
ンスポートインターフェースの機能は、通常、ソフトウ
エアの形態で実現され、即ちそれがメモリ内にロードさ
れた場合に実行されるソフトウエアプログラムとして実
現される。好適実施例においては、これらのレイヤ及び
機能はファームウエアとして格納され、例えば、リード
オンリメモリ（ＲＯＭ）、プログラマブルロジックアレ
イ（ＰＬＡ）又はディスクドライブオーバーレイ等のプ
ログラム可能な格納（記憶）装置内にプログラムしたコ
ードとして格納される。更に、これらのレイヤ及び機能
は当該技術分野において公知の方法によって応用特定集
積回路（ＡＳＩＣ）内にプログラムすることが可能であ
る。一般的に、上にリストしたような一群の動作はソフ
トウエアよりもハードウエアにおいてより高速に動作す
るが、ソフトウエアプログラムは変更、補正及び更新を
する場合により簡単である。ファームウエアの好適実施
例はハードウエアとソフトウエアの両方の利点を結合し
た点である。図３は本発明の１実施例を示している。ト
ランスポートプロトコルインターフェース２００が例え
ば図１に示したプリンタ１２４におけるか又はハードデ
ィスクドライブ１２０，１２２におけるようにバス上の
各ノードにおいて存在している。トランズアクションイ
ンターフェース２１０は図２に示したコンポーネントの
うちの幾つかを具体化している。図３に示したコンポー
ネントを参照すると、トランズアクションハードウエア
２０５を具体化したチップは前述したシリコンシステム
デザイン又はテキサスインストルメンツによるチップと
することが可能である。トランズアクションインターフ
ェース２１０は１３９４トランズアクションレイヤを実
現する。直列バス管理タスク２３５は例えばリセット又
はパワーオンリセット等のバス管理機能を実現する。図
３に示した表示のうちの残部は例えばＲＢＣ等のアプリ
ケーションレイヤと関連して例えばＳＢＰ−２等のトラ
ンスポートレイヤによって決定される機能及びコマンド
を実現する。

【００２１】トランズアクションハードウエア２０５を
除いて、図３における表示は２つの種類、即ちサービス
とタスクとに分割することが可能である。タスクはその
他のタスクをスケジュールするか又はサービスをコール
することが可能である。サービスはタスクによってコー
ルされた場合にのみ応答することが可能であり、且つ完
了すると、コールを発生したタスクへリターンする。ト
ランズアクションインターフェース２１０はカーネル／
スケージューラ／ディスパッチャ２２０と共にサービス
である。図３に示した表示の残りは以下に説明するよう
にタスクである。

【００２２】トランズアクションハードウエア２０５は
１３９４バスをモニタし且つバスから検知した電気信号
をデータパケットへ変換する。トランズアクションイン
ターフェース２１０はトランズアクションハードウエア
２０５から受取ったデータパケットをデコードする。こ
れらのデータパケットは解析されてタスクがスケジュー
ルされるべきであるか否か、サービスをコールすべきで
あるか否かを、又は何等アクションが必要とされないか
否かを決定する。タスク又はサービスが開始されること
を必要とする場合には、トランズアクションインターフ
ェース２１０はデータパケットの内容に基づいてメッセ
ージ制御ブロック（ＭＣＢ）を発生し且つ所望のタスク
をスケジュールするか又は所望のサービスをコールす
る。メッセージ制御ブロックは全てのタスク又はサービ
ス間の通信に対して使用され且つ以下に更に詳細に説明
する。

【００２３】トランズアクションインターフェース２１
０が処理することの可能なデータの最も小さな単位は１
個のデータパケットである。データパケットは１つのグ
ループのデータである。その最も低い要素において、デ
ジタルデータは１又は０のいずれかである。各個別的な
データはビットと呼ばれる。８個のビットからなる集ま
りはバイトと呼ばれ、且つ４バイト（３２ビット）の集
まりはクワドレットと呼ばれる。非同期パケットは少な
くとも４個のクワドレット、即ち１２８ビットの長さで
なければならない。最初の１２８ビットはパケットヘッ
ダと呼ばれる。非同期パケットは、更に、データブロッ
クを有することも可能である。データブロックの寸法は
夫々異なるが、１３９４バスが動作する速度に基づいて
絶対的な絶対値に制限される。１３９４バスは９８．３
０４Ｍｂｐｓ、１９６．６０８Ｍｂｐｓ、又は３９３．
２１６Ｍｂｐｓにおいて動作する仕様を包含している。
これらの速度は、しばしば、夫々、１００，２００，４
００Ｍｂｐｓへまるめられ且つＳ１００，Ｓ２００，Ｓ
４００のラベルが付けられる。Ｓ１００の速度で動作す
る場合には、最大ブロック寸法は５１２バイト（又は１
２８クワドレット）である。Ｓ２００及びＳ４００で動
作している場合には、最大ブロック寸法は、夫々、１０
２４バイト及び２０４８バイトである。より高いバス速
度スタンダードが認められる場合には、多分最大ブロッ
クサンプルも増加する。

【００２４】トランズアクションインターフェース２１
０は１３９４バスからデータを受取り１３９４バスへデ
ータを送信する。図２のトランズアクションレイヤ１０
に関して、バスに沿ってパケット内に送られ且つトラン
ズアクションインターフェース２１０によって処理され
る３つの主要な機能が存在している。それらは読取、書
込及びロック機能である。これらの機能のうちの各々に
対して、２つの主要な操作、即ちリクエスト（要求）及
びレスポンス（応答）が存在している。リクエスト（要
求）は読取、書込又はロックが行われることを依頼する
ものであり、且つレスポンス（応答）は読取、書込又は
ロックが試みられたことを表わし且つ結果を有してい
る。

【００２５】トランズアクションインターフェース２１
０が存在しているターゲットノードに対して送られるべ
きパケットはイニシエータ（開始体）によって１３９４
バス上に配置される。その特定のノードアドレスに対し
て経路付けされたパケットはトランズアクションハード
ウエア２０５における受信ベイにおいて受取られ且つト
ランズアクションインターフェース２１０に対してイン
タラプトが発生される。トランズアクションインターフ
ェース２１０がその現在のタスクを完了すると、インタ
ラプトサービスルーチンにエンターする。１実施例にお
いては、インタラプトを発生する７つのタイプのパケッ
トがパケットヘッダ内に含まれている４ビットトランズ
アクションコードによって識別される。本発明のこの実
施例に対するトランズアクションコードは以下のように
定義される。

【００２６】 表 １ トランズアクションコード 意 味 ０ データクワドレットに対する書込要求 １ データブロックに対する書込要求 ２ 書込応答 ４ データクワドレットに対する読取要求 ５ データブロックに対する読取要求 ６ データクワドレットに対する読取応答 ７ データブロックに対する読取応答 Ｂ ロック応答 上述したように、クワドレットは４バイトであり且つブ
ロックはそのバスが動作する速度に依存して５１２、１
０２４又は２０４８バイトのいずれかである。データブ
ロックに対する書込要求は、特定のノードにおける特定
したデスティネーションメモリアドレスに対してデータ
ブロックを書込むことを依頼することである。データク
ワドレットに対する書込要求はデータブロックに対する
書込要求と同じであるが、特定したデスティネーション
アドレスに対して書込まれるべきデータの量は１つのデ
ータクワドレット内におさまる。データブロックに対す
る読取要求及びデータクワドレットに対する読取要求は
特定したノードにおける特定したデスティネーションメ
モリアドレスからのデータを検索することの要求であ
る。

【００２７】書込要求及び読取要求はデータクワドレッ
ト及びデータブロックの両方に対する読取及び書込の両
方の応答を包含する応答を送ることによって応答され
る。データクワドレットに対する読取応答はデータクワ
ドレットに対する読取要求に対する回答において送ら
れ、要求されたデータはデータヘッダ内においてパスさ
れる。データブロックに対する読取応答はデータクワド
レットに対する読取応答と同様であるが、より多くのデ
ータがパスされる。何らかの理由で、読取要求を実施す
ることが不可能である場合には、データが送られること
はないが、エラーステータスが要求を発生したノードへ
送ることが可能である。書込応答はデータクワドレット
又はデータブロックのいずれかに対する書込要求に対す
る回答として送られる。該応答は書込が成功したか否か
を表わす応答コードを送り、且つ成功しなかった場合に
は、何故失敗したかの特定の理由を中継する。書込応答
において、パケットヘッダはこの応答コードを包含して
いる。

【００２８】ロック要求及び応答は、アドレスと、引き
数値と、要求されたデータとを送ることにより、且つ応
答においてデータを送ることによって同様に動作する。

【００２９】図３を参照すると、トランズアクションイ
ンターフェース２１０及びカーネル／スケジューラ／デ
ィスパッチャ２２０は本発明の全ての実施例に対して存
在している。更に、図２に示したトランスポートレイヤ
８０及びアプリケーションレイヤ９０に対してどのプロ
トコルが使用されるかに依存して、１個又はそれ以上の
タスクが存在する。図３に示した実施例においては、７
個のタスクが示されている。これらのタスクは、トラン
スポートレイヤ８０に対してＳＢＰ−２プロトコルを使
用する場合に必要とされる機能を実施する構成とされて
いる。従って、本発明は任意の使用されるプロトコルを
受付けるべくスケーラブル即ち拡縮可能である。例え
ば、図１０に示した実施例はＦＣＰに対して最適化され
たタスクを示している。従って、所望の任意のプロトコ
ルを実現するために１個又はそれ以上のタスクを使用す
ることが可能である。

【００３０】図３においては、図示されている７つのタ
スクが本発明をＳＢＰ−２プロトコルと共に動作するこ
とを可能としている。トランズアクションインターフェ
ース２１０は受信するトランズアクションコードに依存
して異なる動作を行う。例えば、データクワドレット又
はデータブロックに対する書込要求又はデータクワドレ
ット又はデータブロックに対する読取要求がトランズア
クションインターフェース２１０によって受取られる
と、トランズアクションインターフェースは１つ又はそ
れ以上のタスクのスケジューリングが関与する順番付け
された１組の動作を実施する。

【００３１】図３に示したサービス及びタスクはそれら
のサービス及びタスクに関連するキュー（待ち行列）内
に配置されたメッセージ制御ブロック（ＭＣＢ）を介し
て互いに通信を行う。図３に示した各タスクは少なくと
も１つの夫々の関連するキュー即ち待ち行列を有してい
る。タスク間で転送される情報はＭＣＢを介してのみで
ある。各特定のタスクはそのタスクが動作するために特
に必要とされるデータを含むそれ自身のタイプの制御ブ
ロックを有している。図３に示したものは７つのタスク
であり、即ちコマンドメッセージ制御（ＣＭＣ）ブロッ
クを使用するコマンドＯＲＢ実行タスク２４５と、フェ
ッチ管理メッセージ制御（ＦＭＣ）ブロックを使用する
フェッチ管理タスク２１５と、ＯＲＢフェッチメッセー
ジ制御（ＯＭＣ）ブロックを使用するＯＲＢフェッチタ
スク２５５と、非請求（ｕｎｓｏｌｉｃｉｔｅｄ）ステ
ータス管理制御（ＵＭＣ）ブロックを使用する非請求ス
テータスタスク２６５と、管理エージェントメッセージ
制御（ＭＭＣ）ブロックを使用する管理エージェントタ
スク２２５と、直列バスメッセージ制御（ＳＭＣ）ブロ
ックを使用する直列バス管理タスクと、アプリケーショ
ンメッセージ制御（ＡＭＣ）ブロックを使用するアプケ
ーションタスク２７５とである。該サービスは、又、特
にそれらに対してのＭＣＢも有している。ディスパッチ
ャ２２０はディスパッチメッセージ制御（ＤＭＣ）ブロ
ックを使用し且つトランズアクションインターフェース
２１０はトランズアクションメッセージ制御（ＴＭＣ）
ブロックを使用する。更に、各タスク及びサービスは少
なくとも１個のキュー即ち待ち行列を有しており、その
中に夫々のＭＣＢが配置される。例えば、管理エージェ
ントタスク２２５はＭＭＣブロックを受取る構成とされ
ている管理エージェントタスクキュー（待ち行列）を有
している。アーキテクチュア内のいずれもがタスク及び
キュー（待ち行列）の関連付けを制限するものではな
い。例えば、１つのタスクは多数のキュー（待ち行列）
を有することが可能であり又は１つのキュー（待ち行
列）は多数のタスクと関連することが可能である。タス
クとキュー（待ち行列）との間の任意の程度の関連付け
が可能である。

【００３２】１つのタイプのＭＣＢの例として、図４は
管理エージェントメッセージ制御（ＭＭＣ）ブロックを
示している。全てのＭＣＢは異なるものであるから、ス
タンダードメッセージ制御ブロックのようなものは存在
しないが、ＭＭＣブロックはＭＣＢ内に含まれるタイプ
のデータの代表的なものである。タスクが管理エージェ
ントタスク２２５をスケジュールすることを望む場合に
は、スケジュール用タスクがＭＭＣブロックを構築し且
つそれをＭＭＣキュー（待ち行列）内に配置させる。図
４に示したＭＭＣブロック３００は４４バイトのデータ
を有している。各バイトは参照用に左側に沿って番号付
けされており且つ０−１５の番号が付けられているバイ
トオフセットは各ラインの２つのバイトを構成する個々
のビットを表わしている。タスクにとって有用なデータ
は図４に示したようにＭＣＢ内に配置される。例えば、
バスが動作する速度はＭＭＣブロックの最初の２つのバ
イトのビット８，９，１０（７，８，９のオフセットを
有している）を占有する。管理操作要求ブロック（ＯＲ
Ｂ）に対するアドレスは６バイトの長さであり且つバイ
ト４−９を有している。このデータは操作期間中管理エ
ージェントタスク２２５によって必要とされ且つ使用さ
れる。

【００３３】タスクをスケジュールするか又は別のタス
クからサービスをコールするために、幾つかのステップ
が取られる。最初に、特定のタスク又はサービスに対し
てＭＣＢが形成される。次いで、そのＭＣＢはその特定
のタスク又はサービスに関連するキュー即ち待ち行列内
に配置され且つリターンコードが発信元のタスクへ送ら
れる。次いで、発信元のタスクはリターンコードをチェ
ックする。そのリターンコードが、ＭＣＢがキュー即ち
待ち行列のトップ即ち一番上にないことを表わす場合に
は、このことはそのタスクが現在稼動中であることを意
味し且つ発信元のタスクはそれ以上のことをすることは
ない。何らのアクションもとられない。何故ならば、一
度開始されると、タスクはそのキュー即ち待ち行列が空
になるまでそのキュー即ち待ち行列内の全てのＭＣＢに
関して動作を行うからである。従って、そのタスクのキ
ュー即ち待ち行列内に現在配置されているＭＣＢは、そ
れがそのキュー即ち待ち行列のトップ即ち一番上に昇っ
た場合に、究極的に動作される。然しながら、そのリタ
ーンコードが、そのタスクのキュー即ち待ち行列内に今
配置されたＭＣＢが既にそのキュー即ち待ち行列のトッ
プ即ち一番上にあることを表わす場合、即ちそのタスク
のキュー即ち待ち行列内にはその他のＭＣＢが存在しな
い場合には、このことはスケジュールされたタスクは既
に稼動中ではなく且つ開始されねばならないことを発信
元のタスクに告知する。

【００３４】タスクを開始させるためには、発信元のタ
スクはディスパッチャ２２０に対してディスパッチメッ
セージ制御（ＤＭＣ）ブロックを形成する。このＤＭＣ
ブロックは、どのタスクが開始されるべきであるか且つ
どのような優先度がＤＭＣブロックに対して与えられる
べきであるかを表わす。ディスパッチャ２２０はエント
リに対して継続的にチェックが行われる関連するキュー
即ち待ち行列を有している。エントリが所望のタスクを
開始させるためにスケジューラ２２０によって受取られ
ると、それらは優先度に従ってディスパッチャキュー
（待ち行列）内に配置され、最も高い優先度のものがそ
のキュー即ち待ち行列内の最も高い位置に配置される。
全てのキューの場合におけるように、該ディスパッチャ
又はタスクは、より高い優先度を有するＭＣＢがそのキ
ュー即ち待ち行列内に配置される場合であっても、その
現在のＭＣＢに関する動作が中断されることはない。そ
の代わりに、スケジューラ２２０は、現在処理中のＤＭ
Ｃブロックではなく、ＤＭＣキュー（待ち行列）内に現
在未処理のブロック及び新たなブロックの優先度に基づ
いてＤＭＣブロックの順番付けを行う。ＤＭＣブロック
がＤＭＣキュー（待ち行列）のトップ即ち一番上に到達
すると、ディスパッチャ２２０はそのＤＭＣブロックの
中を見てどのタスクがコールされるべきであるかを判別
し、次いで、コールされたタスクに対して処理されるこ
とを待機しているそれ自身のキュー即ち待ち行列内に位
置しているＭＣＢが存在していることを通知する。この
ことは、スケジュールされたタスクが動作を開始させ
る。従って、１つのタスクが別のタスクをスケジュール
するか又はサービスをコールするためには、１つ又は２
つのＭＣＢが形成されねばならない。最初に、特に、ス
ケジュールされたタスクに対してＭＣＢが形成され且つ
それと関連するキュー即ち待ち行列内に配置される。次
いで、発信元のタスクによってリターンコードがチェッ
クされる。そのリターンコードが、ＭＣＢがそのキュー
即ち待ち行列内に配置されたがそのキューのトップ即ち
一番上にないことを表わす場合には、スケジュールされ
たタスクが既に稼動中であり且つそれがキュー即ち待ち
行列のヘッド即ち一番上に移動した場合にそのＭＣＢに
ついて処理が行われるので、開始用のタスクはそれ以上
のことをすることはない。然しながら、リターンコード
が、ＭＣＢがスケジュールされたタスクに対するキュー
即ち待ち行列のトップ即ち一番上に配置されたことを表
わす場合には、発信元のタスクによってＤＭＣブロック
が発生され、それはどのタスクがスケジュールされるべ
きか又はどのサービスがコールされるべきかを表わし、
且つどの優先度がＤＭＣブロックに与えられるべきであ
るかを表わす。次いで、スケジューラ２２０はそのＤＭ
ＣブロックをＤＭＣキュー即ち待ち行列内の適宜の位置
に優先度による順番付けに従って配置させる。そのＤＭ
ＣブロックがＤＭＣキュー即ち待ち行列のトップ即ち一
番上に到達すると、そのキュー即ち待ち行列内にＭＣＢ
が存在しており且つ動作を開始すべきあることをスケジ
ュールされたタスク又はコールされたサービスに告知す
る。次いで、所望のタスク又はサービスが開始され、そ
のＤＭＣブロックをフリー即ち自由なメッセージブロッ
クプールへリターンさせ、次いでそれ自身のキュー即ち
待ち行列のトップ即ち一番上にあるＭＣＢについて動作
を行う。

【００３５】全てのＭＣＢに対して資源の共通プールが
存在している。メッセージブロックプールはカーネル２
２０によって管理される。該プールはＭＣＢを形成する
ことが可能な有限のメモリ空間から構成されている。よ
り多くのＭＣＢが形成されると、プール内に残されるメ
モリ空間の量が減少する。フリー即ち自由なブロックの
プール内においてメモリ空間が残存していない場合に
は、更なる資源が供給されるまで新たなＭＣＢを発生さ
せることは不可能である。ＭＣＢが処理された後で且つ
最早必要とされない場合、即ち、それらがキュー即ち待
ち行列から除去されると、ＭＣＢをプールへリターンさ
せることによって資源が供給される。タスク又はサービ
スが以前にそのキュー即ち待ち行列内にあるＭＣＢを使
用して完了されると、それはカーネル２２０をコール
し、ＭＣＢをフリー即ち自由なブロッックのプールに戻
すことを要求する。次いで、それは次のフリー即ち自由
なＭＣＢをそのキュー即ち待ち行列のトップ即ち一番上
へ移動させる。更に、ＤＭＣブロックがタスク又はサー
ビスを開始するために必要である場合には、コールされ
たタスク又はサービスはそれ自身のＭＣＢを処理する前
に、そのＤＭＣをフリー即ち自由なメモリブロックプー
ルへすぐさまリターンさせる。フリー即ち自由なメモリ
ブロックのプールの寸法は使用可能なメモリの量によっ
て決定され、いずれかのＭＣＢが割り当てられる前には
固定されている。

【００３６】ディスパッチキュー（待ち行列）を管理し
且つフリー即ち自由なメッセージブロックのプールを管
理することに加えて、カーネル／スケジューラ／ディス
パッチャ２２０は、又、１３９４バストランズアクショ
ンにおけるその他の機能を実施する。カーネル２２０は
データ構造、タイマ及びインタラプトベクトルを初期化
させる。計時される全てのタスクはタイマを必要とす
る。カーネル２２０はタイマに基づいてインタラプトを
開始させ、停止させ、再開始させ、チェックし、削除
し、供給するようなタイマ管理サービスを提供する。タ
イマはカーネルサービスへのコールを介してタスクによ
って要求される場合に割当てられる。現在アクティブ即
ち活性状態にある各タイマは全てのクロックサイクルで
調節される。１実施例においては、タイマは与えられた
数で初期化され、それは各クロックサイクルでデクリメ
ントされる。タイマ値がゼロに到達すると、そのタイマ
に関連するタスクに対して通知が送られる。

【００３７】上述したように、トランズアクションイン
ターフェース２１０及びカーネル／スケジューラ／ディ
スパッチャ２２０と共に動作すべく選択された特定のタ
スクは特定のシステムにおいて使用されるトランスポー
トレイヤ８０に依存する。図３に示した実施例において
は、トランスポートレイヤに対するＳＢＰ−２プロトコ
ルと共に動作すべくタスクが選択されている。その他の
トランスポートレイヤプロトコルが使用される場合に
は、他のタスクが存在するか又は図３に示したタスクの
幾つかが存在しない場合がある。このように、トランス
ポートプロトコルインターフェース２００は極めて柔軟
性があり且つスケーラブル即ち拡縮自在であって、所望
により出来るだけカスタム化することを可能としてい
る。

【００３８】図３に示した実施例において示されるよう
に、コマンドＯＲＢ実行タスク２４５はアプリケーショ
ンタスク２７５と典型的に異なるノードに位置されてい
るイニシエータ（開始体）との間のデータ及びステータ
スのトランズアクション即ちやり取りを処理する。動作
について説明すると、イニシエータはアプリケーション
タスク２７５へデータを送るか又はそれからデータを受
取る。コマンドＯＲＢ実行タスク２４５はそれらの間の
データ及びステータスメッセージに対する主要な経路で
ある。フェッチ管理タスク２１５は、特定のノードにお
いて受取られた操作がそのノードに対して意図されたも
のであったことを確保する。その操作が正しいノードに
ある場合には、フェッチ管理タスク２１５はエージェン
トの現在の状態を表わすために使用される変数をアップ
デート即ち更新する。ＯＲＢフェッチタスク２５５はイ
ニシエータからのコマンドを含む幾つかのＯＲＢを受取
り、且つそれらを実行するためにアプリケーションタス
ク２７５へパスする。非請求ステータスタスク２６５は
その他のタスクのうちの１つによって要求される場合に
イニシエータに対してステータスメッセージを送る。管
理エージェントタスク２２５はイニシエータによって要
求された管理型の機能を実施し、例えばアクセス要求、
ログイン、パスワード設定等である。直列バス管理タス
ク２３５は１３９４バスのノード上の直列バス管理４０
と直列バス管理タスクが存在している同一のノードに対
するアプリケーションタスク２７５との間のインターフ
ェースとして機能する。最後に、アプリケーションタス
ク２７５は図１のアプリケーションレイヤ９０における
上部プロトコルコマンドを実行すべく動作する。アプリ
ケーションタスク２７５は１３９４バスに沿って転送さ
れる大多数のデータの究極的な発信元又はデスティネー
ション（宛先）である。

【００３９】トランズアクションインターフェース２１
０は、上述したようにローカルノードに対して送られる
べきパケットを受取ることに加えて、他のノードに対し
て送られるべきパケットを用意する。用意されると、ト
ランズアクションインターフェース２１０はそのパケッ
トをリンクレイヤ２０へ転送し、そこでそれらのパケッ
トは同期され且つバス上に配置されるべき電気信号へ変
換するために物理層１０へ送られる。トランズアクショ
ンインターフェース２１０から送られるべきデータのタ
イプ及び量に依存して、送信ベイ、ペイロードデータ送
信ベイ及び／又は直接メモリアドレス（ＤＭＡ）チャン
ネルを使用することが可能である。トランズアクション
インターフェース２１０から送られるべきデータの量が
多い場合には、それをバス上に配置すべき幾つかのパケ
ットへ分解することが可能である。各パケットが用意さ
れ、次いで、バスに沿って送られる。

【００４０】タスクが位置しているノード以外のノード
へデータを送ることを所望するタスクは、そのデータを
トランズアクションインターフェース２１０の送信部分
を介して送る。トランズアクションインターフェース２
１０はＴＭＣブロックを保持するために少なくとも２つ
のキュー即ち待ち行列を有しており、即ち時間に対して
クリチカル即ち臨界的なトランズアクションに対して１
つと、時間に対してクリチカルでない即ち非臨界的なト
ランズアクションに対して１つとである。バスに沿って
送られるべきデータはＴＭＣブロックにパッケージ化さ
れ且つ所望により時間に関して臨界的であるか又は時間
に関して臨界的でないキュー内に配置される。時間に関
して臨界的でないＴＭＣキュー（待ち行列）はデータブ
ロック転送要求及び応答に対して使用され、一方時間に
関して臨界的なＴＭＣキュー即ち待ち行列は分割トラン
ズアクションサブアクション内の要求に対する応答のた
めに使用される。時間に関して臨界的でないＴＭＣブロ
ック要求を完了するためには複数個のトランズアクショ
ンが行われる場合がある。トランズアクションが完了す
ると、トランズアクションインターフェース２１０はデ
ータを送っているタスクに対してタスクが完了したこと
の通知を送る。

【００４１】トランズアクションインターフェース２１
０によって開始される各トランズアクションはそれと関
連するハードウエアタイマを有している。ハードウエア
タイマはトランズアクションタイムアウトの時間を管理
するために使用される。ＴＭＣブロックのリトライ即ち
再試行カウントフィールドは、データ転送が不成功であ
った場合にインクリメントされる。リトライカウントが
プログラム可能な最大数のエントリより低い限り、トラ
ンズアクションインターフェース２１０は再度データを
送ることを試みる。最大リトライカウントを超えると、
ステータスメッセージがコールを発生したタスクへ送ら
れ、失敗したことを告知する。トランズアクションが完
了すると、即ちトランズアクションインターフェース２
１０がデータを送っているノードからアクノレッジメン
ト（肯定応答）を受取ると、トランズアクションインタ
ーフェース２１０はコールしたタスクに対してトランズ
アクション完了ステータス又はその他の応答データをリ
タンーンするためのスケジュールを行う。そのデータは
ＤＭＣブロック内に配置され且つコールを発生したタス
クへディスパッチャ２２０を介して送られる。

【００４２】図５Ａはトランズアクションメモリ制御
（ＴＭＣ）ブロック３１０に対する構成を示している。
図４を参照して説明したように、全てのＭＣＢは異なっ
ており且つそれが関連するタスク又はサービスに対して
特定のデータを包含している。ＴＭＣブロックはトラン
ズアクションインターフェース２１０と関連している。
トランスポートプロトコルインターフェース２００のい
ずれかのタスク又はサービスがトランズアクションイン
ターフェース２１０へデータを送ることを必要とする場
合には、それはカーネル２２０からメッセージ制御ブロ
ックを要求し且つ図５Ａ−５Ｉに示したデータ仕様に従
って且つ本明細書に説明するようにＴＭＣブロックをフ
ォーマットする。

【００４３】ワード０に位置されているＴＭＣブロック
３１０のビット８−１５は「ｔａｓｋ＿ＩＤ」である。
このフィールドは要求するタスクのＩＤ、即ち図３に示
したタスクのうちの１つを識別するために使用される。
それはトランズアクションインターフェース２１０によ
って使用されて識別されたタスクに対するトランズアク
ション要求のステータスをリターンする。又、ワード０
において、ビット７は「ｇｒｐ」ビットである。このビ
ットは、特定のＴＭＣブロックが１つのグループにおい
て他のＴＭＣブロックとリンクされているか否かを表わ
す。ビット６は、トランズアクションインターフェース
２１０がサブアクションを完了した場合に、完了ステー
タス又は確認が要求されることを表わすためのインジケ
ータ「ｃｏｎｆ」を有している。ＴＭＣブロックがリン
クされているＴＭＣブロックのグループのメンバである
場合には、最後のＴＭＣブロックにおける唯１つの「ｃ
ｏｎｆ」ビットは１へセットすべきである。ワード０の
ビット５は、アボート（中止）機能が受取られた場合を
表わすために使用される。「ａｂｒｔ」ビットを有する
ＴＭＣブロックは処理されることはない。ビット４にお
ける「ｄｔａ」ビットは、それがＴＭＣブロック３１０
において送信しているデータがカプセル化されているデ
ータであることを表わすために要求するタスクによって
使用される。ワード０のビット０−３における「ｔｒａ
ｎｓａｃｔｉｏｎ＿ｃｏｕｎｔ」はトランズアクション
インターフェース２１０が未処理のトランズアクション
要求の数を追跡することを可能とする。トランズアクシ
ョンインターフェース２１０が直列バスへデータパケッ
トを送るたびに、それはｔｒａｎｓａｃｔｉｏｎ＿ｃｏ
ｕｎｔをインクリメントさせる。トランズアクションイ
ンターフェース２１０がデータパケットが送られたノー
ドからトランズアクション応答を受取るたびに、トラン
ズアクションインターフェースはｔｒａｎｓａｃｔｉｏ
ｎ＿ｃｏｕｎｔをデクリメントさせる。このように、ト
ランズアクションインターフェース２１０は、常に、そ
れが待機している未処理のトランズアクション応答が幾
つあるかを知得している。

【００４４】ＴＭＣブロック３１０のワード１の全体は
「ｌｏｇｉｎ＿ＩＤ」フィールドを有している。これは
その特定のログインＩＤを有するイニシエータによって
アボートコマンドが送られた場合にどのＴＭＣブロック
をアボート即ち中止すべきかを決定することを助けるた
めにトランズアクションインターフェース２１０によっ
て使用される。ワード２において、ビット１１−１５及
び３−７は後で使用するために予約されている。ビット
８−１０は「ｒｅｔｒｙ＿ｃｏｕｎｔ」フィールドを識
別し、そのフィールドはエラーが宣告される前にトラン
ズアクションインターフェース２１０は何回データを送
るための試みを行うべきかを特定する。又、ワード２に
おいて、ビット０−２は、どの速度で１３９４バスが動
作するかを特定する。このフィールドにおける０の値は
Ｓ１００を表わし、１はＳ２００を表わし、且つ２はＳ
４００を表わす。残りの使用可能なデータ値、即ち値３
−７はその他の１３９４仕様が採用される場合に特定さ
れる。

【００４５】ＴＭＣブロック３１０のワード３の全部は
「ｍａｘ＿ｄａｔａ＿ｔｒａｎｓｆｅｒｒｅｄ＿ｌｅｎ
ｇｔｈ」である。このフィールドはデータパケットに対
する最大のデータ転送長を特定する。ワード４は「ｄｅ
ｓｔｉｎａｔｉｏｎ＿ＩＤ」フィールドを特定し、それ
はこの特定のＴＭＣブロックと関連しているデスティネ
ーション（宛先）アドレスを表わす。ワード５におい
て、ビット１０−１５は「ｔｒａｎｓａｃｔｉｏｎ＿ｌ
ａｂｅｌ」フィールドを特定する。このフィールドは要
求パケット及び回答パケットの両方において使用され
る。要求パケットにおいては、要求するタスクがこのフ
ィールドをブランクのままとし且つトランズアクション
インターフェース２１０はその要求を一意的に識別する
このフィールド内に配置されるべき値を発生する。回答
パケットにおいては、要求するタスクがこのフィールド
をそれが回答するパケットのｔｒａｎｓａｃｔｉｏｎ＿
ｌａｂｅｌで充填する。この値は初期的な要求を送った
ノード上の別のトランズアクションインターフェースに
よって発生されており、且つその回答を未処理の要求に
対してマッチングさせるためにトランズアクションイン
ターフェースによって使用される。ワード５において
は、ビット８−９は予約されている。ビット４−７は
「ｔｒａｎｓａｃｔｉｏｎ＿ｃｏｄｅ」を特定する。こ
れらのコードは表１に示したものと同じである。ワード
５のビット０−３は優先度を設定することを可能とする
が、このフィールドはバックプレーンにおいてのみ意味
を有しケーブル環境において意味を有するものではな
い。そのデータの残部、即ちＴＭＣブロック３１０のワ
ード６−３０はトランズアクションインターフェース２
１０へ送られるパケットのタイプに依存する。異なるパ
ケットはトランズアクションインターフェースによって
どのタイプのトランズアクションが要求されるかに依存
して、例えばデータブロックに対する書込要求、データ
ブロックに対する読取要求等に依存して異なる。図５Ｂ
−５ＩはＴＭＣブロック３１０内において使用するため
にパケット依存性データの異なるタイプを示している。

【００４６】図５Ｂは、ＴＭＣブロック３１０の「ｄｔ
ａ」ビットが０にセットされる場合の、データブロック
パケットに対する書込要求又はデータブロックパケット
に対する読取要求に対するパケット情報３１２を示して
いる。「ｄｔａ」ビットを０にセットすることは、送信
されたデータがＴＭＣブロック内にカプセル化されてお
らず、そうではなく、そのデータはデータバッファ内に
あることを表わす。図５Ｂのパケット依存性情報３１２
は、タスクがホストへデータを送ること又はホストから
データを読取ることを所望する場合に使用される。実際
のデータはデータバッファ内にあり且つＴＭＣブロック
パケット内にはないので、データそれ自身ではなく殆ど
の場合にアドレスが送られる。例えば、ワード６−８は
ホストに対してどこにデータを書込むべきであるか又は
ホストからどこのデータを読取るべきかのオフセットア
ドレスを有している。ワード１１及び１２はペイロード
バッファの開始アドレスを表わし、一方ワード１３及び
１４は全ペイロードが幾つのバイトを有するかを表わ
す。上述した如く、１３９４バスの速度に依存してデー
タパケットがどれ程大きくなることが可能であるかの最
大寸法が存在している。Ｓ１００においては、データブ
ロック当たりの最大データ転送長は５１２バイトに過ぎ
ない。読取又は書込要求はこれよりもかなり大きなもの
とすることが可能であり、数百倍又は数千倍大きなもの
とすることが可能である。パケット情報３１２内に維持
されているアドレス及びカウントデータはトランズアク
ションインターフェース２１０が以下に説明するように
どれ程のデータが送られた又は受取ったかを追跡するこ
とを可能とする。

【００４７】図５Ｃは、ＴＭＣブロック３１０の「ｄｔ
ａ」ビットが１にセットされる場合にデータブロックパ
ケットに対する書込要求に対するパケット依存性情報３
１４を示している。「ｄｔａ」ビットをセットすること
は、実際に送信中のデータがワード１５−３０内におけ
るＴＭＣブロック３１０内においてカプセル化されてい
ることを表わす。パケット依存性情報３１４内に格納さ
れているフィールドの残部は図５Ｂに示したものと同様
である。

【００４８】図５Ｄはデータクワドレットに対する書込
要求のトランズアクションに対するパケット依存性情報
３１６を示している。上述したように、データクワドレ
ットは単に３２ビットの情報を有するものであって、且
つこの要求はパケット情報３１６のワード９及び１０内
に格納される。図５Ｅは書込応答パケットに対するパケ
ット依存性情報３１８を示している。書込要求に続いて
書込応答が発生される。読取応答と異なり、書込応答は
何ら書込まれたデータをリターンするものではないの
で、書込応答は書込が成功したか又はエラーが発生した
かを表わすことが必要であるに過ぎない。この情報はワ
ード６のビット１２−１５内に格納され、一方パケット
依存性情報３１８のその他のビットは全て予約されてい
る。図５Ｆはデータクワドレットに対する読取要求に対
してのパケット依存性情報３２０を示している。読取要
求はそれが読取ることを所望するデータのアドレスを有
するに過ぎないので、パケット依存性情報３２０におい
て要求される情報はこの場合には非常に短いものであ
り、ワード６−８を構成するに過ぎない。

【００４９】図５Ｇはデータブロックに対する読取応答
に対してのパケット依存性情報３２２を示している。デ
ータブロックに対する読取応答は要求を発生したものに
対して大量のデータをリターンする。大量のデータが要
求されるので、直接メモリアドレス（ＤＭＡ）チャンネ
ルが使用される。ＤＭＡチャンネルは当該技術分野にお
いて公知の如く、最小のオーバーヘッドでもって大量の
データを迅速に転送することを可能とする。このタイプ
のトランズアクションに対するパケット依存性情報３２
２は、トランズアクションインターフェース２１０が以
下に説明するように読取応答においてどれだけのデータ
を送ったかを追跡することのメカニズムを与えている。

【００５０】図５Ｈはデータクワドレットに対する読取
応答に対してのパケット依存性情報３２４を示してい
る。図５Ｇに示したデータブロックに対する読取応答と
異なり、データクワドレットに対する読取応答は非常に
短く、且つ全体がパケット情報３２４のワード９及び１
０内に納まる。図５Ｉはロック応答に対するパケット依
存性情報３２６を示している。１３９４仕様によって要
求されるように、ロックされたデータの古い値の４個の
ワードがロック応答と共に送られる。これらの古い値は
パケット情報３２６のワード１１−１４内に納められ
る。

【００５１】図６は図３に示したトランズアクションハ
ードウエア２０５とトランズアクションインターフェー
ス２１０との通信チャンネルを示している。好適実施例
においては、トランズアクションインターフェース２１
０は３つのキュー（待ち行列）３３２，３３４，３３６
のうちの１つにおいて図３のタスク及びサービスからＴ
ＭＣブロックを受取る。それに対応して、トランズアク
ションハードウエア２０５は３個の送信ベイ、即ち送信
ベイ０、送信ベイ１、送信ベイ２を有している。これら
の送信ベイは、典型的に、ハードウエアで実現され、例
えば、前述したリンクチップにおいて実現されている。
ハードウエアレジスタはトランズアクションハードウエ
ア２０５とトランズアクションインターフェース２１０
との間のインターフェースとして作用する。更に、夫々
の送信ベイに関連してＤＭＡチャンネルが存在してい
る。これらのＤＭＡチャンネルは大量のデータを搬送す
るために使用され、例えば、ＤＭＡチャンネルを介して
送られる各データブロックは前述した如く１３９４バス
の速度によって許容される最大のものである。このこと
は少量のデータ（例えば、１６バイト）を送信するもの
であり且つ１３９４バスの速度がどのようなものであっ
ても同一の寸法である送信ベイと対比される。送信ベイ
２にとって独特なことはペイロードデータ送信ベイと呼
ばれる付加的なハードウエアが設けられていることであ
る。このペイロードデータ送信ベイは、トランズアクシ
ョンインターフェース２１０が１３９４バスを介してイ
ニシエータに対しロック応答を送る場合に使用される。
ペイロードデータ送信ベイは制限されたデータを搬送す
ることが可能であるに過ぎない送信ベイ２と同時に１３
９４バス上に付加的なデータを配置させることを可能と
する。それは、送信ベイのうちの１つの中に納まるより
も多いものであるがＤＭＡチャンネルを充填するのに充
分に大きなものではないデータを１３９４バス上のノー
ドへ送らねばならない場合に使用される。

【００５２】更に、トランズアクションハードウエア２
０５は受信ベイを有しており、そこではトランズアクシ
ョンインターフェース２１０が位置しているノードに対
して宛先としているパケットがトランズアクションハー
ドウエア２０５によって受信される。これらのパケット
はトランズアクションインターフェース２１０によって
読取られ且つ前述したようにＤＭＣブロック３３８を要
求し且つそれを充填することにより図３の適宜のタスク
に対して経路付けされる。

【００５３】図６に示した好適実施例においては、トラ
ンズアクションインターフェース２１０は３個の送信ベ
イをサポートしている。各送信ベイは、特定の要求機能
を受取るそれ自身の夫々のＴＭＣキュー（待ち行列）を
有している。ＴＭＣキュー（待ち行列）３３２，３３
４，３３６は優先度が異なっており、即ち、トランズア
クションインターフェース２１０のサービスを要求する
図３のタスクはそのＴＭＣブロックをその要求の優先度
に対して適切なキュー（待ち行列）内に配置させる。送
信ベイ０及び対応するキュー（待ち行列）０は時間的に
臨界的でない要求、例えば、ホストに対する又はホスト
からの通常のデータ要求に対して使用される。送信ベイ
１及びそれに対応するＴＭＣキュー（待ち行列）１は短
い時間的に臨界的でない要求に対して使用され、例え
ば、後に説明するように、ホストからの頁テーブルの読
取等に対して使用される。最後に、送信ベイ２及びそれ
に対応するキュー（待ち行列）２は例えば分割トランズ
アクション応答要求等の時間的に臨界的な要求に対して
使用される。分割トランズアクション応答要求は、例え
ば、イニシエータからのＣＳＲ書込又はＣＳＲ読取要求
において使用される。ローカルノードがＣＳＲ書込又は
ＣＳＲ読取に応答している場合には、最初に、そのＣＳ
Ｒ読取又は書込が未処理であることのアクノレッジメン
ト即ち肯定応答がイニシエータへ送られる。それは分割
トランズアクションの最初のアクション即ち動作であ
る。アクノレッジメント即ち肯定応答が送られた後に、
ＣＳＲ書込又は読取のアドレスがフェッチ管理タスク２
１５において検証され、次いで、応答がイニシエータへ
送られる。アクノレッジメント即ち肯定応答が送られる
時と実際のデータが送られる時との間には最大時間仕様
が存在しているので、これらの分割トランズアクション
は最も高い優先度を受取る。従って、送信ベイ２及び対
応するキュー（待ち行列）２は特にこの目的のために使
用される。

【００５４】キュー即ち待ち行列のうちの１つからＴＭ
Ｃブロック３１０において受取られたデータを１３９４
バス上へ送るべく行われる準備は以下のようにして実施
される。最初に、トランズアクションインターフェース
２１０がそのキュー（待ち行列）において受取られたＴ
ＭＣブロックをデコードして１３９４バスへ送られるべ
きデータの量及び種類を決定する。次いで、そのデータ
はパケットヘッダ内にフォーマットされ、必要な場合に
は、１３９４バス仕様に従ってデータパケットにフォー
マット化される。データの量が１つのデータブロックに
おいて送ることが可能なものよりも大きい場合には、ト
ランズアクションインターフェース２１０は第一データ
ブロックを用意し、それを適宜のＤＭＡチャンネル内へ
ロードし、そこでトランズアクションハードウエア２０
５は第一データブロックを１３９４バス上に配置させ
る。その後のデータブロックは、要求されたデータの量
全てがイニシエータへ送られるまで、逐次的に用意され
且つＤＭＡチャンネル内へロードされる。データブロッ
クがトランズアクションハードウエア２０５のＤＭＡチ
ャンネル内へロードされる時と次のデータブロックが同
じＤＭＡチャンネル内へロードすることが可能な時との
間には遅延時間が必ず存在している。トランズアクショ
ンハードウエア２０５のＤＭＡチャンネルがロードされ
る時及び再度新たなデータを受け付けるために自由であ
る時との間の遅延期間は短いものであるが、多数の遅延
期間が寄せ集まるとトランズアクションインターフェー
ス２１０から１３９４バスへの効率的なデータ転送を阻
止する。そのために、トランズアクションインターフェ
ース２１０は、現在使用中でないトランズアクションハ
ードウエア２０５のその他の送信ベイ及びＤＭＡチャン
ネルを使用するように設計されている。

【００５５】このトランズアクションハードウエア２０
５の複数個のＤＭＡチャンネルを使用することが可能で
あることは、時間を節約している。何故ならば、それは
データをトランズアクションハードウエア２０５のＤＭ
Ａチャンネル内へ配置させる時から次のブロックのデー
タを配置させることが可能である時までの全体的な遅延
時間を減少させるからである。例えば、１０個のブロッ
クのデータを１３９４バスへ送るためにトランズアクシ
ョンインターフェース２１０のキュー即ち待ち行列のう
ちの１つを介して要求が来るものと仮定する。１つのキ
ュー（待ち行列）から受取った各ブロックのデータがそ
のキューの夫々のＤＭＡチャンネルを介して送られるこ
とが必要とされる場合には、１０個全てのブロックを送
るためには少なくとも９個の遅延期間が必要とされる。
ＤＭＡチャンネルが最初のデータブロックに対してオー
プン即ち開かれていると仮定すると、そのＤＭＡチャン
ネルを介して第一データブロックを送る上で遅延時間は
存在しない。然しながら、第一データブロックを送るこ
とと第二データブロックを送ることとの間において第一
遅延期間が発生する。第二データブロックを送ることと
第三データブロックを送ることとの間において第二遅延
時間が発生し、且つ１０番目のデータブロックを送るま
で以下同様である。本発明のトランズアクションインタ
ーフェース２１０は任意のキュー（待ち行列）から受取
られたデータブロックがトランズアクションハードウエ
ア２０５の任意の使用可能なＤＭＡチャンネルを利用す
ることを可能とする。前の例を使用すると、トランズア
クションインターフェース２１０から１０個のデータブ
ロックを送らねばならないと仮定する。又、３個のＤＭ
Ａチャンネルの全てが使用可能であると仮定すると、第
一データブロックはそれを介してデータ送信要求が受取
られたキュー（待ち行列）に関連するＤＭＡチャンネル
内にロードされる。トランズアクションインターフェー
ス２１０がトランズアクションハードウエア２０５のＤ
ＭＡチャンネルがそのデータを１３９４バス上へ送るこ
とを待機している間に、トランズアクションインターフ
ェースは、その他のＤＭＡチャンネルが使用可能である
かを判別するためのチェックを行う。そうである場合に
は、これらのＤＭＡチャンネルはすぐさまロードされ
る。トランズアクションハードウエア２０５のＤＭＡチ
ャンネルがロードされるや否や、データブロックは１３
９４バスを介して送られる。データをＤＭＡチャンネル
内へロードすることとＤＭＡチャンネルが次に続くブロ
ックでロードされる準備がなされていることをトランズ
アクションハードウエア２０５から表示を受取ることと
の間に未だ遅延時間が存在しているが、本発明トランズ
アクションインターフェース２１０は全体的な遅延時間
の量を３倍程度減少させる。トランズアクションインタ
ーフェース２１０が、ＤＭＡチャンネルが再度使用可能
であることの通知を受取ると、ブロック４，５，６がロ
ードされる。第二遅延時間に続いて、ブロック７，８，
９がロードされ且つ送られる。１つの付加的な遅延に続
いて、ブロック１０が関連するＤＭＡチャンネル内にロ
ードされ且つ送られる。比較として、単に１つのＤＭＡ
チャンネルを使用して１０個のブロックを送る場合には
最小でも９個の遅延時間のペナルティを有するものであ
るが、この例におけるように使用可能なＤＭＡチャンネ
ルの全てを並列的に使用することは遅延時間を３（ブロ
ック３の後の１つと、ブロック６の後の１つと、ブロッ
ク９の後の１つ）へ制限することが可能である。

【００５６】トランズアクションハードウエア２０５の
全てのＤＭＡチャンネルはトランズアクションインター
フェース２１０によって必要とされる場合に必ずしも使
用可能であるとは限らない。然しながら、使用可能であ
る場合にはフリー即ち自由なＤＭＡ資源を使用すること
を可能とするダイナミックシステムを使用することは、
トランズアクションハードウエア２０５を可及的に最も
効率的な態様で使用することになる。

【００５７】トランズアクションインターフェース２１
０の動作に対するスタンダードの手順は、各夫々のＴＭ
Ｃキュー（待ち行列）３３２，３３４，３３６がそれ自
身の送信ベイを使用することであり、即ちキュー（待ち
行列）０が送信ベイ０を使用し、キュー（待ち行列）１
が送信ベイ１を使用し、且つキュー（待ち行列）２が送
信ベイ２を使用する。然しながら、前述したように、ト
ランズアクションインターフェース２１０は、ＤＭＡチ
ャンネルがそれら自身のキュー（待ち行列）によって使
用されていない場合にそれらのキュー（待ち行列）がト
ランズアクションハードウエア２０５の他のＤＭＡチャ
ンネルを使用することが可能である場合にはより一層効
率的なものとすることが可能である。好適実施例におい
ては、単に１つのペイロード送信ベイが存在するに過ぎ
ず、且つキュー（待ち行列）に関連している。従って、
ペイロードデータ送信ベイを使用するトランズアクショ
ンインターフェース２１０を介して送られるデータはキ
ュー（待ち行列）２（３３６）を介して送られねばなら
ない。キュー（待ち行列）０又はキュー（待ち行列）１
と関連するハードウエアはペイロードデータ送信ベイを
有するものではないので、ペイロードデータ送信ベイを
利用するメッセージは送信ベイ２を介して送られねばな
らない。トランズアクションインターフェース２１０の
好適実施例及びそのトランズアクションハードウエア２
０５との相互接続の説明は単に例示的なものに過ぎず、
種々の変形例は本発明の範囲内に含まれるものであるこ
とを理解すべきである。例えば、キュー（待ち行列）及
び送信ベイの数は任意の数とすることが可能であり、且
つトランズアクションインターフェース２１０に対して
使用可能な資源及びハードウエアによってのみ制限され
る。更に、１つを超える数の送信ベイがペイロードデー
タ送信ベイを有することが可能であり、その場合にはこ
れらのタイプのトランズアクションをキュー（待ち行
列）のうちの任意のものへ送ることを可能とする。

【００５８】図７Ａはキュー（待ち行列）のうちの１つ
を介してどのようにしてデータがＴＭＣブロック３１０
におけるトランズアクションインターフェース２１０へ
供給され且つ究極的に送信ベイへ送られるかを示してい
る。図７Ａに示した例においては、要求するタスクはト
ランズアクションインターフェース２１０がＤＭＡチャ
ンネル又はペイロードデータ送信ベイではなく送信ベイ
のみを使用してデータを送信することを依頼する。タス
クがトランズアクションインターフェース２１０が非常
にわずかなデータを送る場合に送信ベイのみを使用して
データを送ることを要求する。何故ならば、送られるデ
ータ全てが非常に短いパケットデータ内に納まらねばな
らないからである。このために、送信ベイのみを使用す
るタイプの要求は書込応答要求又はデータクワドレット
に対する読取要求である。これらの要求に対して図５Ａ
のＴＭＣブロックのワード６−３０内に包含されるパケ
ット依存性データを、夫々、図５Ｅ及び図５Ｆに示して
ある。要求するタスクはこれらの図に示した送信ベイ情
報をＴＭＣブロック３１０内に書込む。次いで、トラン
ズアクションインターフェース２１０はその送信ベイ情
報を使用可能な送信ベイ内にロードし且つトランズアク
ションハードウエア２０５におけるトリガビットをセッ
トする。このトリガビットはトランズアクションハード
ウエア２０５内に組込まれ且つ送信ベイ内に包含されて
いるデータをいつ１３９４バスへ送るべきかを決定する
ためにトランズアクションハードウエアによって使用さ
れる。上述した如く、ＴＭＣブロック３１０からの情報
がロードされる特定の送信ベイは、どの送信ベイが使用
可能であるかに依存する。最初に、それを介して特定の
ＴＭＣブロックが送られたキュー（待ち行列）と関連す
る送信ベイが使用可能であるかチェックされる。その送
信ベイが使用可能である場合には、それが使用される。
そうではなく、その関連する送信ベイがビジーである場
合には、残りの送信ベイが使用可能であるかチェックさ
れる。それらの送信ベイのうちの別の１つが使用可能で
ある場合には、その使用可能な送信ベイが使用される。
このことは、トランズアクションインターフェース２１
０が効率的な態様でデータを１３９４バスへ送ることを
可能とする。その送信ベイにおけるデータが１３９４バ
スへ送られると、そのデータが送られたノードから該デ
ータが受取られたことを表わす応答が送られる。次い
で、トランズアクションインターフェース２１０は送信
することを所望した情報が実際に送られたことの確認通
知を要求するタスクへ送る。

【００５９】図７Ｂは送信ベイとペイロードデータ送信
ベイの両方を使用する送信要求を示している。ペイロー
ドデータ送信ベイを使用するこのタイプの要求は１３９
４仕様からのロック応答である。この応答に対するトラ
ンズアクションコードは表１にリストしてある。ロック
応答に対するＴＭＣブロック３１０のパケット情報は図
５Ｉを参照して説明した。特に、ペイロードデータ送信
ベイ内に包含されるデータはＴＭＣブロック３１０のワ
ード１１−１４においてトランズアクションインターフ
ェース２１０へ送られる。トランズアクションインター
フェース２１０がロック応答に対する要求を受取ると、
それは同時的に送信ベイ情報を送信ベイ内へロードし且
つその送信データをペイロードデータ送信ベイ内にロー
ドし、次いでトランズアクションハードウエア２０５に
おけるトリガビットをセットしてデータを１３９４バス
を介して送る準備がされていることをトランズアクショ
ンハードウエアに対して表示する。上述した如く、ロッ
ク応答に対する要求はキュー２（３３６）を介して送ら
れねばならない。何故ならば、送信ベイ２はペイロード
データ送信ベイを有する唯一の送信ベイだからである。

【００６０】図７Ｃはデータブロックに対する書込要
求、読取要求又は読取応答内に含まれるデータがどのよ
うにして要求するタスクからトランズアクションインタ
ーフェース２１０へ且つ１３９４バスへ送られるかを示
している。要求するタスクは図５Ｂ及び５Ｇに示したこ
とにしたがって、ＴＭＣブロック３１０のパケット依存
性情報をデータで充填する。図５Ｂを参照すると、図７
ＣにおけるＴＭＣブロック３１０の送信ベイ情報を構成
している情報のいくらかがワード６−１０内に包含され
ている。バッファ開始アドレスがワード１１及び１２内
に包含されており且つバイト単位でのデータの全部の量
がワード１３及び１４において送られる。この情報が与
えられると、トランズアクションインターフェース２１
０は送信ベイ内にロードされるべき第一パケットヘッダ
及び第一データブロック、即ちデータブロック１を組立
てる。このデータブロックは１３９４バスの速度によっ
て制限されるが、１つのパケット内において送ることが
可能であるだけのデータを包含する。要求するタスクは
図７Ｃに示したようにＴＭＣブロック３１０における最
大ペイロード寸法を送る。トランズアクションインター
フェース２１０がトランズアクション要求を完了するの
に必要なデータブロックの全てをフォーマットする。第
一データブロックは第二データブロックと同じく最大の
許容可能な寸法を送り、且つ３番目は、要求するタスク
によって送られるデータの全てがデータブロック内に取
り入れられるまでである。特定の要求からのデータを含
む最後のデータブロックであるデータブロックｎは（ペ
イロードの全寸法−（ｎ×最大ペイロード寸法））バイ
トを有している。上述した如く、データブロック１，
２，ｎは最も効率的な態様でトランズアクションハード
ウエア２０５を介して送られる。

【００６１】要求するタスクが非連続的なメモリ位置へ
データを送る場合、即ちデータが断片化されたメモリへ
送られる場合には、要求するタスクは頁テーブルにおけ
る各セグメント当たり１個のＴＭＣブロックをフォーマ
ットする。ＴＭＣブロックをフォーマットする前に、要
求するタスクは断片化されたメモリに対するマップとし
て頁テーブルを要求する。従って、各頁テーブルセグメ
ント当たり１個のＴＭＣブロックである複数個のＴＭＣ
ブロックをフォーマットすることは要求するタスクの任
務である。頁テーブルセグメント内に含まれているデー
タがグループ化されている場合には、要求するタスクは
「ｇｒｐ」ビット、ワード７、ビット７乃至１をセット
して、別個のＴＭＣブロックにおけるデータがリンクさ
れていることをトランズアクションインターフェース２
１０に対して表示する。要求するタスクは、又、確認ビ
ット、ワード０、ビット６を最後の頁テーブルセグメン
トのＴＭＣブロックにおいて１にセットする。従って、
トランズアクションインターフェース２１０は不連続な
メモリ位置を計算することは必要ではなく、その代わり
に、要求するタスクはトランズアクションインターフェ
ースに対してメモリ位置を供給する。

【００６２】図８は複数個の送信ベイをサポートするた
めのトランズアクションインターフェース２１０とトラ
ンズアクションハードウエア２０５との間の通信をサポ
ートするために使用されるデータ構造を示している。デ
ータ構造３５０はトランズアクションハードウエア２０
５における各送信ベイに対して１つの要素を有してい
る。各要素は、更に、３つのフィールド、即ち「現在実
行中のＴＭＣキュー番号」、「リトライカウント」、
「デフォルトキューヘッドポインタ」に分割されてい
る。「現在実行中ＴＭＣキュー番号」フィールドは、各
特定の要素に対してどのキュー（待ち行列）が現在送信
ベイへアクセスしているかを表わす。例えば、送信ベイ
０が現在元々キュー１（３３４）を介してトランズアク
ションインターフェース２１０へ送られたデータ転送に
対する要求を実施している場合には、キュー（待ち行
列）１を表わす番号が要素０に対する「現在実行中ＴＭ
Ｃキュー番号」内にエンターされる。完了すると、この
フィールドは初期値で充填される。この初期値が存在す
ることを検知することは、特定の送信ベイが現在使用中
であるか否かを表わす。「リトライカウント」フィール
ドは、トランズアクションインターフェースがリトライ
即ち再試行を試みるたびにインクリメントされる。リト
ライカウントフィールドがワード２、ＴＭＣブロック３
１０のビット８−１０内に含まれている「ｒｅｔｒｙ＿
ｃｏｕｎｔ」と等しくなると、最早リトライは行われず
且つトランズアクションインターフェース２１０は現在
のトランズアクションを終了する。次いで、エラーが要
求するタスクに対して報告される。エラーが報告される
と、データ構造３５０のリトライカウントフィールドは
初期値にリセットされる。最後に、各要素のデフォルト
キューヘッドポインタが各要素に対する最後のフィール
ド内に格納される。このデータ構造３５０における値は
通常動作期間中にトランズアクションインターフェース
２１０によってアップデートされる。

【００６３】トランズアクションインターフェース２１
０がデータバスに沿ってパケットを送ると、それからデ
ータが送られたノードに対するトランズアクションハー
ドウエア２０５の受信ベイ部分によって応答が受取られ
る。この応答はトランズアクションインターフェース２
１０における送信インタラプタハンドラによってデコー
ドされる。トランズアクションインターフェース２１０
が受取ることの可能な応答コードはアボート条件、トラ
ンズアクション完了、肯定応答受信、調停喪失、肯定応
答ミス及びサブアクションギャップである。これらの応
答コードはトランズアクションインターフェース２１０
がどのような応答を要求するタスクに対して行うべきか
を決定するためにワード０、ＴＭＣブロック３１０のビ
ット０−３に位置されている「ｔｒａｎｓａｃｔｉｏｎ
＿ｃｏｕｎｔ」と結合して使用される。「ｔｒａｎｓａ
ｃｔｉｏｎ＿ｃｏｕｎｔ」エントリは特定のＴＭＣブロ
ックに対する未処理のトランズアクション要求の数を記
録する。例えば、要求するタスクが別のノードに対して
１０個のブロックを送る場合には、各ブロックがトラン
ズアクションハードウエア２０５によって送られた後
に、「ｔｒａｎｓａｃｔｉｏｎ＿ｃｏｕｎｔ」が１だけ
インクリメントされる。トランズアクション応答がその
ＴＭＣブロックに対して受取られるたびに、「ｔｒａｎ
ｓａｃｔｉｏｎ＿ｃｏｕｎｔ」は１だけデクリメントさ
れる。従って、ＴＭＣブロック３１０内の「ｔｒａｎｓ
ａｃｔｉｏｎ＿ｃｏｕｎｔ」フィールドが０以外の何か
である場合には、１３９４バス上のノードに対してパケ
ットが送られたが応答が受取られていないことを意味す
る。

【００６４】トランズアクションインターフェース２１
０の送信インタラプトハンドラがアボート条件を表わす
トランズアクション応答を受取ると、ＴＭＣブロック３
１０に対する「ｔｒａｎｓａｃｔｉｏｎ＿ｃｏｕｎｔ」
フィールドがチェックされる。「ｔｒａｎｓａｃｔｉｏ
ｎ＿ｃｏｕｎｔ」が０であり、全ての送信したパケット
が考慮されていることを表わす場合には、トランズアク
ションインターフェース２１０に対するキュー（待ち行
列）における現在のＴＭＣブロックが取除かれる。アボ
ート条件応答が受取られたが「ｔｒａｎｓａｃｔｉｏｎ
＿ｃｏｕｎｔ」が０より大きい場合には、トランズアク
ションインターフェース２１０は未処理のトランズアク
ション応答の全てを受取ることを待機し、即ち、「ｔｒ
ａｎｓａｃｔｉｏｎ＿ｃｏｕｎｔ」が０と等しくなるま
で待機する。「ｔｒａｎｓａｃｔｉｏｎ＿ｃｏｕｎｔ」
が０と等しくなると、現在のＴＭＣブロック３１０がト
ランズアクションインターフェース２１０のキュー（待
ち行列）から取除かれる。トランズアクション応答が、
そのトランズアクションが完了したことを表わす場合に
は、ＴＭＣブロック３１０の「ｔｒａｎｓａｃｔｉｏｎ
＿ｃｏｕｎｔ」及びペイロードバイトカウントフィール
ドがチェックされる。ペイロードバイトカウントが０よ
り大きい場合には、パケットが送られるべく残ってお
り、且つトランズアクションインターフェース２１０は
継続して次のデータパケットを送る。ペイロードバイト
カウントが０であるが「ｔｒａｎｓａｃｔｉｏｎ＿ｃｏ
ｕｎｔ」が０より大きい場合には、トランズアクション
インターフェース２１０は「ｔｒａｎｓａｃｔｉｏｎ＿
ｃｏｕｎｔ」が上述した如く０へリターンするのを待機
する。ペイロードバイトカウントも「ｔｒａｎｓａｃｔ
ｉｏｎ＿ｃｏｕｎｔ」も０である場合には、その要求は
完了しており且つトランズアクションインターフェース
２１０はそのトランズアクションがエラーなしで完了し
たことの応答を要求するタスクへ送る。

【００６５】トランズアクション応答が、肯定応答が受
取られたことである場合には、トランズアクションイン
ターフェース２１０はそのトランズアクションがエラー
なしで完了したことを要求するタスクに知らせる。トラ
ンズアクション応答が、バス上での調停が喪失されたこ
とを表わす場合には、トランズアクションインターフェ
ース２１０はトランズアクションが完了したがエラーが
発生したことを要求するタスクに知らせる。トランズア
クション応答が、肯定応答がミスしているか又はサブア
クションギャップが大き過ぎることを表わす場合には、
リトライカウントフィールドがチェックされる。データ
構造３５０のリトライカウントフィールドがワード２の
「ｒｅｔｒｙ＿ｃｏｕｎｔ」、ＴＭＣブロック３１０の
ビット８−１０の限界未満である場合には、トランズア
クションインターフェース２１０はそのトランズアクシ
ョンのリトライ即ち再試行を試みる。逆に、リトライカ
ウントがリトライ数に対する「ｒｅｔｒｙ＿ｃｏｕｎ
ｔ」限界以上である場合には、要求するタスクに対して
エラーが報告される。

【００６６】上述した如く、トランズアクションハード
ウエア２０５は受信ベイを有している。受信ベイは１３
９４バスからのデータパケットを受付け且つ図３に示し
たどのタスクがデータパケットからのデータを受取るべ
きかを決定する。図９は、トランズアクションハードウ
エア２０５の受信ベイにおいて受信パケットが受取られ
た場合の実行の流れ３６０を示したフローチャートであ
る。この実行の流れはデータパケットが受取られた場合
に活性化するインタラプトサービスルーチンを介して実
行される。時間において予測不可能なイベントが発生す
る場合にインタラプトサービスルーチンを使用すること
は当該技術分野において公知である。ステップ３６２に
おいてトランズアクションハードウエア２０５の受信ベ
イにおいて１３９４バスからデータパケットが受取られ
る。このデータはトランズアクションインターフェース
２１０における手順へ送られる。トランズアクションイ
ンターフェース２１０はカーネル２２０からメモリ制御
ブロックを要求する。メモリ資源が使用可能でない場合
には、トランズアクションインターフェース２１０はカ
ーネル２２０における特別のルーチンをコールする。カ
ーネル２２０はそれが次に使用可能なＭＣＢをトランズ
アクションインターフェース２１０へ与えることを了知
する。このことは、上述したタスク及びサービスに対す
るメモリ資源割り当てと異なっている。何故ならば、他
のタスクがＭＣＢを要求し且つどれも使用可能でない場
合には、どのタスクが次のＭＣＢを受取るかの順番を決
めるリストが維持されるからである。好適実施例におい
ては、トランズアクションハードウエア２０５において
１個の受信ベイが存在するに過ぎないので、トランズア
クションインターフェース２１０は、受信ベイ内にデー
タが存在する場合には、その他の全てのタスクを上回る
優先度を獲得しカーネル２２０から次に使用可能なメモ
リ制御ブロックを受取る。該データが受信ベイ内にあり
且つどのＭＣＢも使用可能でない間は、その他のデータ
パケットはトランズアクションハードウエア２０５の受
信ベイハードウエアによって受取ることは不可能であ
る。

【００６７】ＭＣＢがステップ３６４において成功裡に
割り当てられると、トランズアクションインターフェー
ス２１０はデータパケット内をチェックしてローカルノ
ードのどのメモリ位置をアクセスすることが所望されて
いるかを決定する。２つの異なるタイプの操作に対する
アドレスが維持される。第一に、デスティネーション
（宛先）オフセット（受信されたパケットによって送ら
れる）がステップ３６８においてフェッチエージェント
アドレスのテーブルに対してマッチングされる。該アド
レスがマッチ即ち一致する場合には、ＦＭＣブロックが
要求され、トランズアクションインターフェース２１０
によって充填され、次いで図３のフェッチ管理タスク２
１５がステップ３７０においてスケジューラ２２０を介
してスケジューリングされる。スケジューリングされる
と、トランズアクションインターフェース２１０はその
他のデータを受付けるためにステップ３７２において受
信ベイをクリアする。ステップ３７４において、トラン
ズアクションインターフェース２１０の受信要求ハンド
ラがインタラプトからリターンし且つ処理を継続して行
う。

【００６８】その代わりに、ステップ３６８が、フェッ
チエージェント操作を受取らなかったことを表わす場合
には、受取ったデータパケットのデスティネーションオ
フセットがステップ３７６においてターゲットの管理エ
ージェントレジスタに対してマッチングされる。そのデ
ータパケットが管理エージェント書込動作である場合に
は、ＭＭＣブロックがカーネル２２０から要求され且つ
図３の管理エージェントタスク２２５がステップ３７８
においてスケジューリングされる。管理エージェントタ
スク２２５がステップ３７８においてスケジューリング
されると、受信ベイがステップ３７２においてクリアさ
れ且つインタラプトサービスルーチンはステップ３７４
においてリターンする。

【００６９】その代わりに、デスティネーションオフセ
ットがフェッチエージェントアドレス及び管理エージェ
ントレジスタの両方の範囲外に該当する場合には、パケ
ットがＣＳＲ動作であると仮定される。従って、ステッ
プ３８０において、ＳＭＣブロックがカーネル２２０か
ら要求され且つ図３の直列バス管理タスク３２５がスケ
ジューリングされる。再度、受信ベイがステップ３７２
においてクリアされ且つインタラプトサービスルーチン
がステップ３７４においてリターンする。トランズアク
ションインターフェース２１０のインタラプトサービス
ルーチン部分はデータパケット内に受取られたデータの
有効性をチェックするものではない。その代わりに、イ
ンタラプトサービスルーチンは以下に説明するようにそ
れ自身のデータチェッキングを実施する適宜のタスクの
スケジューリングを行う。

【００７０】次に、図３に示したタスクの特定のインス
タンスの幾つかについて説明すると、管理エージェント
タスク２２５はイニシエータからの管理型要求に応答す
る。イニシエータノードによって送られた管理エージェ
ントＣＳＲ書込に応答して、管理エージェントタスク２
２５はイシニエータから管理ＯＲＢをフェッチし且つ次
いでＯＲＢ機能を実行する。ＯＲＢ機能の例としては、
ログイン、パスワード設定、再接続、タスク終了等があ
る。管理エージェントタスク２２５がイニシエータへ通
信せねばならない場合には、それはトランズアクション
インターフェース２１０の送信部分を使用する。

【００７１】管理エージェントタスク２２５は、イニシ
エータへデータを送るタスクの後に、該タスクは、次い
で、トランズアクションインターフェース２１０からの
通知があるまで中断状態となる。トランズアクションイ
ンターフェース２１０がイニシエータとのデータトラン
ズアクションを完了すると、トランズアクションインタ
ーフェースはスケジューラ２２０に対してシステムコー
ルを行うことにより管理エージェントタスク２２５をウ
ェイクアップさせる。次いで、管理エージェントタスク
２２５はそのタスクに対する管理ＯＲＢの実行を継続し
て行う。完了すると、管理エージェントタスク２２５は
そのキュー（待ち行列）のトップ即ち一番上からＭＭＣ
ブロックを廃棄し、カーネルをコールしてＭＭＣブロッ
クをフリー即ち自由なメモリプールへリターンさせ、且
つ、存在する場合には、そのキュー（待ち行列）内の次
のＭＭＣブロックに関しての動作を開始する。管理ＯＲ
Ｂはログインコマンドを包含しており、管理エージェン
トタスク２２５はＯＭＣブロック及びログイン記述子リ
ストを形成する。ＯＭＣブロック及びログイン記述子リ
ストはイニシエータがログアウトした後に除去される。

【００７２】アプリケーションタスク２７５は１３９４
バス上のノードのうちの１つにおいて動作するアプリケ
ーション、例えば、高速プリンタ、高速格納部（記憶
部）又はオーディオビジュアルアプリケーションを表わ
している。アプリケーションは例えばハードディスクド
ライブ用のレデューストブロックコマンド（ＲＢＣ）、
プリンタ用のプリンタワーキンググループ（ＰＷＧ）又
はネットワーク用のインタ−ネットプロトコル（ＩＰ）
等の特定のアプリケーションプロトコルを使用してそれ
らの固有のプロトコルを介して通信を行う。幾つかのア
プリケーションは任意の与えられたノード上で一度に動
作することが可能である。各アプリケーションはそれに
対して送給されたコマンドをデコードし、有効性を評価
し、且つ実行する。各別個のアプリケーションは幾つの
アプリケーションが稼動しているかに基づく番号によっ
て識別される別個のキュー（待ち行列）を有している。

【００７３】ＯＲＢフェッチタスク２２５は一度に１個
のイニシエータから複数個のコマンドＯＲＢを検索すべ
く機能し、カプセル化されているコマンドを実行するた
めにアプリケーションタスク２７５へパスする。全ての
新たなフェッチに対し、システムコールが行われて、そ
のフェッチを要求するＡＭＣブロックアドレスを決定す
る。このブロックアドレスは、次いで、開始用のタスク
に対応するＯＭＣブロック内に保存される。そのＯＲＢ
アドレスはＯＭＣブロックから検索される。次いで、ト
ランズアクションインターフェース２１０はコマンドＯ
ＲＢを読取り且つリターンすべくスケジューリングされ
る。そのデータがエラーなしでやってくる場合には、Ａ
ＭＣブロックが発生され且つＡＭＣキュー（待ち行列）
内に配置され、検索されたデータを適切なアプリケーシ
ョンタスクへ送る。幾つのイニシエータが存在している
かに依存して、ＯＲＢフェッチタスク２５５は公正なア
ービトレイション（調停）を与えるために各フェッチに
おけるＯＲＢの総数を制限する場合がある。

【００７４】コマンドＯＲＢ実行タスク２４５はアプリ
ケーションタスク２７５の代わりにデータ転送要求及び
ステータスデリバリ（送給）を与える。コマンドＯＲＢ
実行タスク２４５はアプリケーションタスク２７５によ
ってＣＭＣキュー（待ち行列）内に配置されたコマンド
メッセージ制御（ＣＭＣ）ブロックから実行すべきコマ
ンドを検索する。コマンドＯＲＢ実行タスク２４５は指
示された通りにデータ又はステータスを送るか又は検索
するためにトランズアクションインターフェース２１０
のスケジューリングを行う。完了すると、トランズアク
ションインターフェース２１０はコマンドＯＲＢ実行タ
スク２４５をウェイクアップさせ、それは、次いで、Ｏ
ＲＢ実行のステータスをそれが作業を行っている特定の
アプリケーションタスク２７５に対して通知するか又は
要求されたデータを供給する。

【００７５】フェッチ管理タスク２１５は２つの特別の
書込要求を処理する。いずれの場合においても、フェッ
チ管理タスク２１５はＯＭＣブロック内のフィールドを
アップデートする。

【００７６】最後に、非請求ステータスタスク２６５は
例え要求されていなくとも、ステータス信号を別のノー
ドにおけるイニシエータへ送るべく動作する。このタス
クは、例えば、そのノードをリセットする前にログイン
されたイニシエータに通知すべく動作する。

【００７７】本発明の重要な特徴は、上述したタスクの
各々が予め定めた一連の命令に従って動作するというこ
とである。タスクは、それらの複雑性に依存して、１個
又は多数の論理状態を有する場合がある。各状態はその
タスクに対する一時的な停止用の場所を表わす。各タス
クは、その挙動が現在のデータ（そのＭＣＢ内に含まれ
ている）及びそのタスクの現在の状態から決定される順
序回路として考えることが可能である。ある状態にエン
ターした後に受取られる新たなデータに依存して、１つ
の状態にあるタスクは異なる状態へ変化する。その新た
なデータを受取った後に、その状態は更なるデータがそ
のタスクによって獲得されるまで現在の状態に留まるこ
とも可能である。

【００７８】上述したタスクのような順序回路の動作は
ステートテーブル即ち状態図を使用して記述することが
可能である。状態図は順序回路の現在の状態及びそれが
次の状態へ進行するための条件をリストする。該条件が
満足されない限り、その順序回路は状態を変化させるこ
とはない。状態図の１つの例を図１５Ａ−１５Ｅに示し
てあり、それらは上述した如く管理エージェントタスク
２２５に対する状態を示している。同様に、順序回路の
異なる状態は状態図に示すことが可能であり、例えば、
図１１はコマンドＯＲＢ実行タスク２４５の異なる状態
を示している。これらの状態図において、一般的には、
安定な状態は円として示され且つ１つの状態から別の状
態へ変化する条件は矢印として示される。又、逐次的な
マシンの初期状態を示すために典型的に何等かの表示が
使用される。この場合には、初期状態は二重の円で表わ
してある。

【００７９】図１１は図３において導入したコマンドＯ
ＲＢ実行タスク２４５に対する状態図４００を示してい
る。上述したように、状態図上の円は定常状態を表わし
ており、且つ矢印は状態を変化するために必要な条件を
示している。上述したように、初期状態は二重円として
示してある。コマンドＯＲＢ実行タスク２４５の場合に
は、初期データ状態は４０５として示してある。

【００８０】上述したように、コマンドＯＲＢ実行タス
ク２４５は、通常、アプリケーションタスク２７５と通
常１３９４バスの異なるノードに位置しているイニシエ
ータとの間でのデータ及びステータスのトランズアクシ
ョン即ちやり取りに関する動作を行う。前述したよう
に、コマンドＯＲＢ実行タスク２４５は、ＣＭＣブロッ
クをフォーマットし且つそれをコマンドＯＲＢ実行タス
クのキュー（待ち行列）内に配置させることによってア
プリケーションタスク２７５によってコールされる。そ
の特定のＣＭＣブロックが該キュー（待ち行列）のヘッ
ド即ち一番上にある場合には、コマンドＯＲＢ実行タス
ク２４５が初期状態４０５にエンターする。これは、図
１１に示したように、初期データ転送状態及び初期ステ
ータス転送状態の両方である。

【００８１】コマンドＯＲＢ実行タスク２４５が最初に
行われねばならない決定は、ＣＭＣブロックがデータ転
送又はステータス転送動作を包含しているか否かであ
る。この情報はＣＭＣブロック内に含まれており且つコ
マンドＯＲＢ実行タスク２４５によって簡単にデコード
される。コマンドＯＲＢ実行タスク２４５がデータ転送
のためにコールされていると、次にどの状態へ移行する
かを決定するためにＣＭＣブロックから更なる情報を解
析せねばならない。ＣＭＣブロック内のデータが、頁テ
ーブルフェッチが要求されていることを表わす場合に
は、コマンドＯＲＢ実行タスク２４５は頁テーブルフェ
ッチを実施し、次いで、状態４１５へ変化する。然しな
がら、頁テーブルフェッチが必要でない場合には、コマ
ンドＯＲＢ実行タスクはデータの転送を開始し、且つ直
接的に状態４１０へ進行する。メモリ資源がフラグメン
ト即ち断片化されているか又は大きなブロックで使用可
能でない場合に、当該技術分野において公知の如く、頁
テーブルフェッチが要求される。頁テーブルフェッチは
コマンドＯＲＢ実行タスク２４５によって達成され、そ
れはＴＭＣブロックを要求し、それをブロック読取要求
を実施するのに必要なデータで充填し、次いでＴＭＣブ
ロックをトランズアクションインターフェース２１０用
のキュー（待ち行列）内に配置させる。コマンドＯＲＢ
実行タスク２４５はイニシエータからブロックの形態で
データを要求せねばならないのでブロック読取要求を実
施することが必要である。このブロックはコマンドＯＲ
Ｂ実行タスク２４５のデータ転送を実施するために必要
な頁テーブルデータを包含している。２つの状態の間、
例えば状態４０５と状態４１６との間の矢印の上に示さ
れている円は、適宜のＭＣＢが用意されねばならず且つ
他のタスク又はサービスのうちの１つがディスパッチャ
２１０を介してコールされていることを表わす。ＴＭＣ
資源が使用可能でない場合、即ちメモリ資源に対するメ
モリ空間の全てがカ−ネル２２０によって割り当てられ
ている場合には、コマンドＯＲＢ実行タスク２４５は状
態４２０へエンターし、そこで、それは適宜の資源を待
機する。該状態の殆どにおいて、付加的又は異なるデー
タが該タスクに対して供給されるまで、該タスクは更な
る動作から中断される。

【００８２】中断された状態とは、中断されたタスクに
対するキュー（待ち行列）の現在トップ即ち一番上にあ
るＭＣＢがそのキュー（待ち行列）のトップ即ち一番上
に留まることを意味している。中断されたタスクはその
タスクがタイムアウトするか又はカーネル２２０によっ
てウェイクアップされるまで中断された状態に留まる。
中断された状態にある間は、その中断されたタスクはカ
ウントダウンタイマを開始させる。与えられた時間期間
の後に、そのタイマはゼロに到達するまでデクリメント
される。カウントダウンタイマが０に到達すると、エラ
ー条件が発生される。このエラーはタイムアウトしたタ
スクをコールしたタスクに対して報告され且つ当該技術
分野において公知の如く、エラーログ内に格納すること
が可能である。そのエラーが壊滅的なものでない場合に
は、タイムアウトしたタスクは現在そのキュー（待ち行
列）のトップ即ち一番上にあるＭＣＢを除去し、且つ次
に高いＭＣＢに関しての動作を開始する。

【００８３】図１１に戻って説明すると、頁テーブルが
状態４１５においてフェッチされると、カーネル２２０
はコマンドＯＲＢ実行タスク２４５をウェイクアップさ
せる。このことは、該タスクを動作可能なものとさせる
べくスケジューリングすることによって行われ、次いで
カーネル２２０はそのタスクをコールする。コマンドＯ
ＲＢ実行タスク２４５は、それが中断された時の状態を
記憶している。頁テーブルがフェッチされると、コマン
ドＯＲＢ実行タスク２４５は、頁テーブル内に表示され
ている位置から所望のブロックのデータを要求する。こ
のステップは状態４１５と４１０との間の矢印として示
されている。上述した如く、この動作はＴＭＣブロック
を要求すること、ＴＭＣブロックをデータで充填するこ
と、且つＴＭＣブロックをトランズアクションインター
フェース２１０用の適宜のキュー（待ち行列）内に配置
することを包含している。上述した如く、このことはデ
ィスパッチャ２２０を使用するので、状態４１５と４１
０との間の矢印は円を有している。メモリ資源がＴＭＣ
ブロックに対して使用可能でない場合には、コマンドＯ
ＲＢ実行タスク２４５は状態４２０にエンターし、そこ
でこのような資源を待機する。

【００８４】コマンドＯＲＢ実行タスク２４５は、状態
４１５から状態４１０へエンターする場合には、頁テー
ブルフェッチに続くデータ転送の後に状態４１０へエン
ターし、又、状態４０５から状態４１０へエンターする
場合には、読取／書込データ転送を実施した後に状態４
１０へエンターする。状態４１０にある間に、コマンド
ＯＲＢ実行タスクは、それが転送すべき付加的なデータ
を有しているか否かを決定する。上述した如く、アプリ
ケーションタスク２７５によって転送することが要求さ
れているデータの寸法が非同期データパケットに取付け
ることの可能な最大のデータブロックよりも大きい場合
には、転送すべき付加的なデータが存在している。状態
４１０から、コマンドＯＲＢ実行タスク２４５はコール
を発生したタスクへリターンすることが可能であり、又
は、別の頁テーブルフェッチが必要であることが決定さ
れている場合には、再度処理を開始するために初期状態
４０５へ進行する。別の頁テーブルフェッチが必要であ
る場合には、上述した如く、状態４０５を介して状態４
１５へエンターする。コマンドＯＲＢ実行タスク２４５
がそのデータ転送を完了すると、そのタスクは状態４１
０からコールを発生したタスクへリターンする。

【００８５】コマンドＯＲＢ実行タスク２４５はステー
タス転送を送る任務を果たすことも可能である。ステー
タス転送が要求されると、ＴＭＣブロックが要求され且
つ適宜のデータで充填される。次いで、ＴＭＣブロック
がトランズアクションインターフェース２１０用のキュ
ー（待ち行列）内に配置される。ステータス転送がコー
ルを発生したタスクによって要求されていることが確認
されない場合には、コマンドＯＲＢ実行タスク２４５は
その機能を完了し且つコールを発生したタスクへリター
ンする。そうではなく、ステータス転送がコールを発生
したタスクによって要求されたことが確認されると、コ
マンドＯＲＢ実行タスク２４５は状態４１０へ進行しそ
の確認を待機する。トランズアクションインターフェー
ス２１０から確認が来ると、コマンドＯＲＢ実行タスク
２４５はコールしたタスクへリターンする。上述したよ
うに、メモリ資源がＴＭＣブロックを割り当てるために
現在使用可能でない場合には、コマンドＯＲＢ実行タス
クは状態４２０へ進行し、そこでこのような資源を待機
する。使用可能となると、そのステータスはトランズア
クションインターフェースを介して１３９４バス上の所
望のノードへ送られる。

【００８６】各タスクが該タスクの幾つかに対し幾つか
の中断状態を包含する多数の状態を具備するステートマ
シンとして動作させることによって、トランスポートプ
ロトコルインターフェース２００は一度に複数個のタス
ク、即ちマルチタスクを実施することが可能である。典
型的に、１３９４バス上の別のノードからデータが必要
であるために特定の機能の一部が中断状態に保持されて
いる場合には、その現在の機能の他の部分又は別の機能
が他のタスクのうちの１つによって動作させることが可
能である。このように、トランスポートプロトコルイン
ターフェース２００によって同時に１つを超える数の機
能を実施することが可能である。更に、中断した状態を
有することによって、カーネル２２０は他のタスクを実
施することが可能であり、そのことはシステムの性能を
改善させる。タスクはステートマシンによって駆動され
るので、プロセサ時間はタスク間において公平に分布さ
れ最適化される。

【００８７】図１２はフェッチ管理タスク２１５に対す
る状態図４３０を示している。図１２においては、更
に、本明細書において説明するように、フェッチ管理タ
スク２１５に対する実行の流れ４５０が示されている。
フェッチ管理タスク２１５は、レジスタのうちの１つが
以下に説明するようにアクセスされるべき場合に、直列
バス管理タスク２３５によってコールされる。更に、管
理エージェントタスク２２５はアボート条件及びリセッ
ト条件に対してフェッチ管理タスク２１５をコールす
る。最後に、トランズアクションインターフェース２１
０は、１３９４バス上の別のノードによって指示される
場合に、フェッチ管理タスク２１５をコールすることが
可能である。

【００８８】状態図４３０における初期状態は状態４３
５である。フェッチ管理タスク２１５が究極的にトラン
ズアクションインターフェース２１０をコールすること
は確かなことであるので、ＴＭＣブロックはフェッチ管
理タスク２１５におけるその他の動作が実施される前に
カーネル２２０からすぐさま要求される。メモリ資源が
使用可能でない場合には、フェッチ管理タスク２１５は
状態４４０へエンターしてこのような資源を待機する。
資源がＴＭＣブロックに対して使用可能となると、フェ
ッチ管理タスク２１５は点線で示した実行の流れ４５０
にエンターする。実行の流れ４５０内において、フェッ
チ管理タスク２１５内において発生するイベントが示さ
れている。これらのイベントはステートマシン自身の状
態ではなく、フェッチ管理タスク２１５のプログラムの
流れを示した表示である。初期的には、ステップ４５２
はフェッチ管理タスク２１５がＦＭＣブロックからとら
れたＣＳＲ動作をデコードする場合である。上述したよ
うに、フェッチ管理タスク２１５が現在作業しているＦ
ＭＣブロックはフェッチ管理タスク用の関連するキュー
内に配置されている。

【００８９】ＣＳＲオペレーション即ち動作がステップ
４５２においてデコードされると、フェッチ管理タスク
２１５はどのＣＳＲがアクセスされるかを、そのメモリ
位置に基づいて決定する。ＣＳＲ動作は多数のレジスタ
のうちの１つへアクセスすることが可能であり、例え
ば、それはエージェント状態ＣＳＲ４５４、エージェン
トリセットＣＳＲ４５６、ＯＲＢポインタＣＳＲ４５
８、ドアベルＣＳＲ４６０又は非請求ステータスＣＳＲ
４６２に対するＣＳＲ動作とすることが可能である。
又、ステップ４５２から直接ステップ４６４へ進む矢印
によって示されるように、ＣＳＲは特定のメモリ位置と
マッチング即ち一致しない可能性もある。そのステップ
においては、動作要求、例えば読取又は書込要求がその
要求のイニシエータがホストにログインしたか否かを決
定するために有効化される。その動作がログインしたイ
ニシエータの読取要求である場合には、フェッチエージ
ェントレジスタがステップ４６６において読取られる。
その動作要求がログインしたイニシエータからの書込要
求である場合には、フェッチエージェントレジスタがス
テップ４６８において書込まれる。その動作が有効な読
取要求であるがホストがログインしていない場合には、
ボックス４７２に示したようなデフォルト値を包含する
読取デフォルトがそれを要求したものへ供給される。こ
れらのデフォルト値は使用されている特定のトランスポ
ートプロトコルによって規定され、例えば、ＳＢＰ−２
トランスポートプロトコルにおいては、ログインしてい
ない要求するものからの有効な読取要求に対するデフォ
ルト値は全て０である。ステップ４６４において、規則
違反のために読取書込要求が拒否されると、例えば、イ
ニシエータがリードオンリメモリの位置への書込又はラ
イトオンリメモリ位置からの読取を行おうとする場合に
は、フェッチ管理タスク２１５の実行の流れ４５０は以
下に説明するようにオペレーション即ち動作４７４へ移
行する。更に、ログインされていないイニシエータが書
込要求を実施しようとする場合には、フェッチ管理タス
ク２１５はその要求を拒否し且つ実行の流れをステップ
４６４から直接的にステップ４７４へ移動させる。ステ
ップ４７４において、読取又は書込エージェントレジス
タ又は読取又は書込要求が拒否された場合にはエラーメ
ッセージが状態４３５によって最初に要求されたＴＭＣ
ブロック内にパッケージ化される。次いで、そのＴＭＣ
ブロックはステップ４７６においてトランズアクション
インターフェース２１０のキュー（待ち行列）内に配置
される。

【００９０】前と同じく、フェッチ管理タスク２１５
が、今キュー即ち待ち行列に配置されたＴＭＣブロック
がトランズアクションインターフェース２１０用のキュ
ー（待ち行列）のヘッド即ち一番上にあることの通知を
フェッチ管理タスク２１５が受取ると、そのことはトラ
ンズアクションインターフェースが現在稼動中でないこ
とを意味する。従って、トランズアクションインターフ
ェース２１０が現在稼動中ではないので、トランズアク
ションインターフェースはステップ４７８においてカー
ネル２２０を介してスケジューリングが行われる。ステ
ップ４７６から、ＴＭＣブロックがＴＭＣキュー（待ち
行列）内に配置された後に、ＯＲＢフェッチタスク２５
５からのフェッチエンジンが開始されるか又は再開始さ
れねばならないか否かの決定が行われる。ＯＲＢフェッ
チタスク２５５に関して何等のアクションが必要でない
場合には、フェッチ管理タスク２１５は実行の流れ４５
０のステップ４７６から初期のＦＭＣ状態４３５へ直接
的にリターンする。然しながら、ＯＲＢフェッチタスク
２５５が開始されるか又は再開始されねばならない場合
には、ＯＭＣブロックがステップ４８０に示されるよう
に発生されねばならない。前と同じく、ＯＭＣブロック
を形成するためにメモリ資源が使用可能でない場合に
は、フェッチ管理タスク２１５は状態４８５にエンター
し、そこで適切なメモリ資源に対して待機する。フェッ
チ管理タスク２１５が適切なメモリ資源を有している場
合には、ＯＭＣブロックはステップ４８２においてキュ
ー化即ち待ち行列化される。通常そうであるように、フ
ェッチ管理タスク２１５がＯＲＢフェッチタスク２５５
が既に稼動中でないことの通知を受取ると、ＯＲＢフェ
ッチタスクはステップ４８４においてスケジューリング
される。フェッチ管理タスク２１５がその実行の流れ４
５０から初期のＦＭＣ状態４３５へリターンすると、そ
れはそれ自身のキュー即ち待ち行列をチェックして、稼
動を継続して行うか否かを決定する。フェッチ管理タス
ク２１５に対するキュー（待ち行列）内にエントリが存
在しない場合には、フェッチ管理タスクはシャットダウ
ンする。然しながら、フェッチ管理タスク２１５用のキ
ュー（待ち行列）内に付加的なエントリが存在している
場合には、次のエントリがデコードされ且つフェッチ管
理タスク２１５に対する処理は再度初期のＦＭＣ状態４
３５において開始する。

【００９１】図１３はＯＲＢフェッチタスク２５５に対
する状態図５００を示している。上述した如く、ＯＲＢ
フェッチタスク２５５は一度に１つのイニシエータから
複数個のコマンドＯＲＢを受取り、且つカプセル化した
コマンドをアプリケーションタスク２７５内において動
作している特定の論理ユニット番号（ＬＵＮ）へパスす
る。ＯＲＢフェッチタスク２５５は初期状態５０５で開
始する。その最初のアクションはコマンドＯＲＢフェッ
チを要求するＡＭＣブロックアドレスを決定することで
ある。どのＡＭＣ資源も使用可能でない場合には、それ
は動作を開始する前にそれらが使用可能となるのを待機
せねばならない。そのブロックアドレスが既知である
と、ＴＭＣブロックが形成されて、コマンドＯＲＢがイ
ニシエータから検索されることを依頼する。前述したよ
うに、ＴＭＣ資源が使用可能でない場合には、ＯＲＢフ
ェッチタスク２５５は状態５１０へ移動してこれらの資
源を待機する。該資源が使用可能であると、ＯＲＢフェ
ッチタスク２５５は状態５１５へ進行し、そこでコマン
ドＯＲＢ応答を待機する。状態５１５において、コマン
ドＯＲＢ応答が成功し且つ更なるコマンドＯＲＢが検索
されることが要求されない場合には、ＯＲＢフェッチタ
スク２５５はこの状態５１５を出ることが可能である。
然しながら、フェッチすべき更なるＯＲＢが存在する場
合には、ＯＲＢフェッチタスク２５５は初期状態５０５
へ進行して更なるＯＲＢをフェッチし且つ処理を継続し
て行う。

【００９２】ＯＲＢフェッチタスク２５５に対するキュ
ー（待ち行列）はそれが循環型であるという点で独特で
ある。アプリケーションタスク内のどの１つのＬＵＮも
トランスポートプロトコルインターフェース２００の資
源を独占することがないように、公平なアービトレイシ
ョン即ち調停を可能とするために、任意の１つの時刻に
おいてフェッチされることが可能とされるコマンドＯＲ
Ｂの最大数が存在している。この数はプログラム可能で
あり、且つ、典型的に、例えば３等のかなり小さい数に
設定され、従ってどのＬＵＮもシステムを他のＬＵＮを
排除してそれ自身のために接続させることはない。ＯＭ
Ｃブロックが最初に、例えば、１０個のコマンドＯＲＢ
を要求すると、ＯＲＢフェッチタスク２５５はその初期
の動作においてコマンドＯＲＢを３個フェッチする。そ
のＯＭＣブロックは、７個の未処理のコマンドＯＲＢ要
求と共に、該キュー（待ち行列）のトップ即ち一番上か
ら該キュー（待ち行列）の底部へ移動され、従って他の
ＯＭＣブロックを動作させることが可能となる。全部
で、１０個のコマンドＯＲＢを要求したＯＭＣブロック
はＯＲＢフェッチタスク２５５の初期状態５０５へ合計
で４回エンターすることとなり、最初の３回の各々にお
いては、３個のコマンドＯＲＢをフェッチし、且つ４番
目においては、１個のコマンドＯＲＢをフェッチする。
フェッチされると、ＯＲＢフェッチタスク２５５は状態
５１５となる。前述したように、フェッチすべき更なる
コマンドＯＲＢが存在しない場合には、ＯＲＢフェッチ
タスク２５５は状態５１５からそれをコールするタスク
へリターンする。

【００９３】図１４は非請求ステータスタスク２６５に
対する状態図を示している。前述したように、このタス
クはアプリケーション又はトランスポートプロトコルイ
ンターフェース２００が位置しているノードがシャット
ダウンされていることの通知をイニシエータへ送る。状
態図５２０は、非請求ステータスタスク２６５が５２５
において初期状態を有していることを示している。非請
求ステータスタスク２６５の動作は、ホストのメモリ内
にデータを書込むことである。従って、１３９４バスに
沿ってホストのメモリへ送られるべきこのデータを有す
るＴＭＣブロックが発生されねばならない。いつも通
り、どのメモリ資源もＴＭＣブロックを発生するために
使用可能でない場合には、非請求ステータスタスク２６
５は状態５３０へ進行し、そこでメモリ資源を待機す
る。ＴＭＣブロックが使用可能であると、そのステータ
スが送られ且つ非請求ステータスタスク２６５は状態５
３５へエンターし、そこでエラーなしで１３９４バスに
沿ってステータスが送信されたことの確認を待機する。
非請求ステータスタスク２６５がそのステータスタスク
がエラーなしで送られたことが通知されると、非ステー
タスタスクは状態５３５から抜け出しそれをコールした
タスク即ち発信元のタスクへリターンする。

【００９４】図１５Ａ−１５Ｅは管理エージェントタス
ク２２５に対する状態変化決定テーブル５５０を示して
いる。管理エージェントタスク５２５が存在している現
在の状態は左側に示されており、一方管理エージェント
タスク２２５が移行する次の状態は決定テーブル５５０
の右側に示してある。状態は太線によって状態変化決定
テーブル５５０において互いに分離されている。状態変
化決定テーブル５５０の上部近くには管理エージェント
タスク２２５がその現在の状態から次の状態へ変化する
ために満足されねばならない条件が示されている。

【００９５】上述したように、管理エージェントタスク
２２５はアクセス要求及びタスク管理要求を包含するイ
ニシエータからの管理要求を取扱う。一般的に、図４に
示したように、ＭＭＣブロックは管理ＯＲＢ又はタスク
ＯＲＢを包含している。管理ＯＲＢ又はタスクＯＲＢを
送ったイニシエータは、管理エージェントタスク２２５
がそのＯＲＢを受取ったことを陳述する応答を予測す
る。従って、管理エージェントタスク２２５の初期状態
は図１５Ａの状態変化決定テーブル５５０に示したよう
に、「管理エージェント書込」状態である。この管理エ
ージェント書込状態は最も上側の状態である。更に、
「ＯＲＢ書込応答送信」の条件の下のボクッス内にｘが
存在している。状態変化決定テーブル５５０は、管理エ
ージェントタスク２２５が管理エージェント書込状態に
あり且つＯＲＢ書込応答送信条件が満足される場合に次
の状態が「ＯＲＢ書込応答待機」の情報を供給する。管
理エージェントタスク２２５の１実施例においては、Ｏ
ＲＢ書込応答送信の条件は常にセットされており、従っ
て管理エージェントタスク２２５がその初期状態にエン
ターする場合には、それは、常にＯＲＢ書込応答を送信
する。

【００９６】前のタスクの場合のように、状態変化決定
テーブル５５０上において「自由なＴＭＣブロックな
し」条件として示されるフリーな即ち自由なメモリ資源
が存在しない場合には、管理エージェントタスク２２５
に対する次の状態は「ＴＭＣ資源待機」である。管理エ
ージェント書込状態から去るために他の２つの方法が存
在している。分割トランズアクションタイムアウトが存
在しており且つ別のＭＭＣブロックが使用可能である場
合には、管理エージェントタスク２２５は現在のＭＭＣ
ブロックを廃棄し且つそのキュー（待ち行列）内の次の
ＭＭＣブロックへ移行する。分割トランズアクションタ
イムアウトは、管理エージェントタスク２２５がイニシ
エータへ書込中のデータがエラーなしでイニシエータに
よって受取られたことの通知を受取らない場合に発生す
る。この状態においては、管理エ−ジェントタスク２２
５はそれがＯＲＢを受取ったことを表わす応答を送るだ
けであったので、このエラーに関して更なるアクション
を取ることは必要ではないが、１３９４バス上で問題が
あることを表わす場合がある。管理エージェントタスク
２２５の管理エージェント書込状態から抜け出る４番目
の態様は、分割トランズアクションタイムアウトが存在
しているがそのキュー（待ち行列）において更なるＭＭ
Ｃブロックが使用可能でない場合である。これらの条件
が満足される場合には、管理エージェントタスクは何も
することが出来ず、カーネル２２０へリターンする。

【００９７】状態変化決定テーブル５５０上で示されて
いる次の状態は「ＯＲＢ書込応答待機」である。管理エ
ージェントタスク２２５がこの状態にあり且つ「ホスト
からの管理ＯＲＢフェッチ」に対する条件が満足される
場合には、エンターされる次の状態は以下に記載する
「ＯＲＢフェッチ待機」である。上述したように、フリ
ーなＴＭＣブロックが使用可能でない場合には、次の状
態はＴＭＣ資源待機である。更に、上述したのと同様
に、「エラーなしでトランズアクション完了」の条件が
満足され且つ管理エージェントタスク２２５用のキュー
（待ち行列）内において更なるＭＭＣブロックが使用可
能である場合には、管理エージェントタスクはその現在
のブロックを配置し且つ次のものに関する動作を開始す
る。管理エージェントタスク２２５がＯＲＢに対する要
求を送ろうとして失敗した場合には、「エラーでトラン
ズアクション完了」の条件が発生する。ＯＲＢ書込応答
状態待機から抜け出る最後の態様は、トランズアクショ
ンがエラーで完了したが更なるＭＭＣブロックが使用可
能でない場合であり、その場合には、管理エージェント
タスクはカーネル２２０へリターンする。

【００９８】状態変化決定テーブル５５０から理解され
るように、多数の状態に対する「次の状態」において類
似性が存在している。それらについては上において充分
に説明したので、簡潔性を旨とするために、「ＴＭＣ資
源待機」、「管理エージェント書込」、「（ｄｏｎｅ、
即ち終了）」状態に対する遷移については管理エージェ
ントタスク２２５の状態の残部に対しての説明は割愛す
るが、標準状態遷移として言及する。

【００９９】図１５Ａ上の状態変化決定テーブル５５０
に示されている３番目の状態は「ＯＲＢフェッチ待機」
状態である。この状態はＯＲＢフェッチタスク２５５か
らのＯＲＢフェッチを要求した場合に管理エージェント
タスク２２５によってエンターされる。ＴＭＣ資源待機
を除いて、標準状態遷移が適用される。状態変化決定テ
ーブル５５０における「ＯＲＢフェッチ待機」状態は図
１５Ａの殆どと、図１５Ｂの全てと、図１５Ｃの殆どと
をカバーしている。然しながら、この状態はホストから
リターンする場合にＯＲＢからデコードすることが可能
な多数の機能に分解されている。ＯＲＢがホストからリ
ターンすると、管理エージェントタスク２２５はステー
タスをホストへ送り、管理エージェントタスクがＯＲＢ
を受信したことを表わす。管理エージェントタスク２２
５がそのＯＲＢをデコードした後に、それは解析され
て、機能を含むか否かを判別し、且つそうである場合に
は、どの機能であるかを判別する。それが「ログイン」
機能を含んでおり且つその条件が「ＥＵＩ−６４がホス
トから読取られるべき」を表わす場合には、管理エージ
ェントタスク２２５がエンターする次の状態は「ログイ
ンＥＵＩ待機」である。ＥＵＩ−６４はホストが維持す
るログイン識別子である。ＯＲＢフェッチ待機状態のロ
グイン機能に対して標準状態遷移が適用される。

【０１００】ＯＲＢからデコードされた機能が「クエリ
ィログイン」であると、応答がホストへ送られ、且つ次
の状態は「クエリィログイン応答送信」である。いつも
の通り、フリーなＴＭＣブロックが存在しない場合に
は、次の状態はＴＭＣ資源待機である。

【０１０１】ＯＲＢからデコードした機能が「パスワー
ド設定」及び「パスワード要求読取」条件がセットされ
ている場合には、このことは、ホストがパスワードを変
更することを望んでいることを表わし、従って管理エー
ジェントタスク２２５は「パスワード設定待機」状態へ
進行する。ＯＲＢ機能が完了するが、エラーを有してい
る場合、例えば、パスワードが誤ったフォーマットであ
った場合には、管理エージェントタスクは存在する場合
に次に使用可能なＭＭＣブロックへ移動する。ＯＲＢ機
能がエラーなしで完了した場合に同一の結果が発生す
る。

【０１０２】図１５Ａに示した最後の機能は「ログアウ
ト」である。この機能のために送られることが必要なも
のは簡単な応答である。従って、管理エージェントタス
ク２２５が進行することが可能な状態は標準状態のみで
ある。

【０１０３】図１５Ｂにおいて、１３９４バスがリセッ
トした後に「再接続」機能が送られる。この機能に対し
ては、管理エージェントタスク２２５はホストからのＥ
ＵＩ−６４を再度読取る。標準状態遷移が適用される。
次の機能は「終了」である。管理エージェントタスク２
２５はこの機能に応答して単にステータスを送り戻し且
つ標準状態遷移が適用される。次の機能は「タスク中
止」であり且つ図１５Ｂに示した残りの機能、即ち「タ
スク中止セット」及び「タスククリアセット」に関連し
ている。従って、これらの機能については一緒に検討す
る。アボート（中止）コマンドが管理エージェントタス
ク２２５によって受取られ且つ管理ＯＲＢからデコード
されると、管理エージェントタスク２２５によってアプ
リケーションタスク２７５へ通知が送られてアプリケー
ションタスクからＯＲＢを除去する。このことは別の状
態遷移を必要とするものではなく、且つ管理エージェン
トタスク２２５の実行の流れの一部である。タスク中止
及びタスク中止セットの機能の場合には、それ以上のも
のが行われることはなく、且つ標準の次の状態以外の次
の状態は存在しない。タスククリアセット機能の場合に
は、非請求ステータスタスク２６５が喚起されてホスト
へメッセージを送る。フリーなＵＭＣブロックが存在し
ない場合には、管理エージェントタスク２２５の次の状
態は「ＣＴＳＵＭＣブロックを待機」である。

【０１０４】図１５Ｃに示した次の機能は「論理ユニッ
トリセット」である。アプリケーションタスク２７５は
１つを超える論理ユニットを有している。ホストは論理
ユニットがリセットされたことが告げられねばならない
ので、非請求スターテスタスク２６５が使用される。フ
リーなＵＭＣブロックが存在しない場合には、次の状態
は「論理ユニットリセットＵＭＣブロック待機」とな
る。論理ユニットリセット機能に対するその他の状態は
標準状態である。

【０１０５】コマンドＯＲＢからデコードされた機能が
「ターゲットリセット」である場合には、１つの特定の
ターゲットに対する論理ユニットの全てがリセットされ
る。このことは、論理ユニットリセットに類似している
が範囲がより広い。標準状態遷移が適用され、ＵＭＣブ
ロックが使用可能でない場合には「ターゲットリセット
ＵＭＣブロック待機」の状態が付加される。

【０１０６】図１５Ｃに示した管理エージェントタスク
の次の現在の状態は「ログインＥＵＩ待機」である。こ
の状態は図１５Ａに示したＯＲＢフェッチ待機状態のロ
グイン関数からエンターされたものである。「ログイン
応答送信」条件が満足される場合には、管理エージェン
トタスク２２５に対する次の状態は「ログイン送信」で
ある。パスワード要求を読取るための条件が存在してい
る場合には、次の状態は「ログインパスワード待機」と
なる。これらの状態の残部は標準的なものである。

【０１０７】図１５Ｃに示した次の状態は「ログイン応
答送信」である。この状態においては、管理エージェン
トタスク２２５がハンドシェーキングの形態としてホス
トへアクノレッジメント即ち肯定応答を送る。標準の次
の状態のみが使用される。

【０１０８】図１５Ｃに示した最後の現在の状態は「ロ
グインパスワード待機」である。「ログイン応答送信」
条件が満足されると、次の状態はすぐその上に記載され
ている「ログイン応答送信」状態である。該状態遷移の
残部は標準状態である。

【０１０９】図１５Ｄに示した最初の状態は「クエリィ
ログイン応答送信」状態である。この状態の場合には、
管理エージェントタスク２２５が単に要求するものに対
してステータスを送信する。標準状態遷移のみが適用さ
れる。

【０１１０】図１５Ｄに示した現在の状態の残部は全て
管理エージェントタスク２２５が何かがリターンされる
ことを待機する状態である。現在の状態「パスワード設
定待機」、「再接続ＥＵＩ待機」、「ＴＭＣ資源待機」
の場合には、標準状態遷移のみが適用され、従って、更
に何かを説明する必要はない。「ＣＴＳＵＭＣ待機」、
「ＬＵＲＵＭＣ待機」、「ＴＲＵＭＣ待機」の状態の場
合には、標準遷移に加えて状態遷移のみが上述したよう
にＵＭＣブロックが待機しているものである。図１５Ｅ
に示した現在の状態は図１５Ｄから持ち越された「ＴＭ
Ｃ資源待機」である。この状態において、トランズアク
ション確認が要求された場合には、その確認要求が送ら
れ且つ次の状態は「ＴＭＣ資源待機」状態にエンターし
たもののすぐ後の状態である。

【０１１１】次に、直列バス管理タスク２３５について
検討する。上述したように、直列バス管理タスク２３５
は図２の直列バス管理４０と同一のノード上のアプリケ
ーションタスク２７５との間のインターフェースとして
機能する。直列バス管理タスク２３５用の状態図５６０
を図１６に示してある。初期状態５６５がＣＳＲプロセ
スを開始する。このＣＳＲプロセスは、ホストがＣＳＲ
レジスタを読取ることを試みる場合に喚起される。直列
バス管理タスク２３５はこのデータを含むホストに対し
読取応答を送る。典型的であるが、初期状態５６５はＴ
ＭＣブロックを確保しようとする。ＴＭＣブロックが使
用可能でない場合には、ＴＭＣブロックが受取られるま
で状態５７０へエンターする。ＴＭＣブロックが受取ら
れ且つ適宜のデータで充填されると、状態５７５へエン
ターする。この状態も、ＴＭＣブロックが元々使用可能
であった場合には、初期状態５６５によって直接的にエ
ンターすることが可能である。状態５７５において、直
列バス管理タスク２３５はトランズアクションインター
フェース２１０からの適宜の応答を待機し、ＣＳＲ読取
応答がホストによって受取られたことを表わす。直列バ
ス管理タスク２３５が、ＣＳＲ読取応答が受取られたこ
との表示を受取ると、それはそのコールしたタスク即ち
発信元のタスクへ状態５７５から直接的にリターンす
る。

【０１１２】図１７はアプリケーションタスク２７５の
状態図５８０を示している。アプリケーションタスク２
７５内において、状態図５８０はアプリケーションタス
ク２７５内に含まれる全てのＬＵＮに対して繰り返され
る。上述したように、アプリケーションタスク２７５は
ハイレベルコマンドを受取り且つそれらを実行する。ア
プリケーションタスク２７５は１３９４バス上の他のノ
ードへデータ及びステータス転送を送るためにコマンド
ＯＲＢ実行タスク２４５を使用する。

【０１１３】状態図５８０の初期状態は状態５８５であ
る。この状態において、ＯＲＢフェッチタスク２５５に
よって送給されたコマンドが処理される。そのコマンド
が有効なコマンドである場合には、コマンドＯＲＢ実行
タスク２４５を介してデータがイニシエータへ送られ
る。このことはＣＭＣブロックを必要とする。どのメモ
リ資源も使用可能でない場合には、アプリケーションタ
スク２７５は状態５９０へ進行し、そこでメモリ資源を
待機する。ＣＭＣブロックが使用可能であると、データ
が転送され且つアプリケーションタスク２７５は状態５
９５へ進行し、そこでデータ転送のステータスを待機す
る。データ転送の各サブセットが完了すると、アプリケ
ーションタスク２７５は状態６００へ変化し、そこで転
送結果が処理される。更なるデータ転送が必要である場
合には、それらはコマンドＯＲＢ実行タスク２４５を介
して送られ、それに対して所要のＣＭＣブロックが得ら
れねばならない。どのメモリ資源も使用可能でない場合
には、アプリケーションタスク２７５はそれらが使用可
能となるまで状態６０５へ移動する。次いで、次の転送
が実行され且つアプリケーションタスク２７５は転送結
果を待機するために状態５９５へリターンする。データ
転送の全てが完了すると、ステータスが状態５９５から
イニシエータへ送られる。このステップもＣＭＣメモリ
ブロックの形成を必要とするので、いずれも使用可能で
ない場合には、アプリケーションタスク２７５は、ＣＭ
Ｃブロックが使用可能となるまで状態６１０へ変化す
る。ステータスが送られると、状態６１５にエンター
し、そこでステータス結果が待機される。エラーが発生
すると、アプリケーションタスク２７５は動作を終了さ
せるが、その結果が満足のいくものである場合には、そ
のコンマンドが完了され且つ再度初期状態５８５にエン
ターしてアプリケーションタスク２７５用のキュー（待
ち行列）のトップ即ち一番上にある別のＡＭＣブロック
に関して動作を行う。

【０１１４】状態５８５，５９０，５９５から点線を介
して示したものは、管理エージェントタスク２２５によ
ってアボート即ち中止すべく指示された場合に、アプリ
ケーションタスク２７５が何を行うかの表示である。管
理エージェントタスクがアプリケーションタスク２７５
のアボート（中止）機能をコールすると、アプリケーシ
ョンタスクはすぐさま状態６１５へ進行し、そこでステ
ータス結果を待機する。アプリケーションタスク２７５
はこの状態からアボート即ち中止する。

【０１１５】動作中の１３９４バスアーキテクチュアの
１例はサービス及びタスクの相互の動作の更なる理解を
与えるものである。タスクのうちの幾つかを使用する例
は管理ログインＯＲＢを介してホストへログインする動
作である。このことは、例えば、プリンタが１３９４バ
スへプラグインされる場合に発生する。図３を参照する
と、ローカルでないノード上のイニシエータでログイン
が始まる。イニシエータがローカルノード上のトランズ
アクションインターフェース２１０へ１個又はそれ以上
のデータパケットを送り、該ノードにおいて、ハードウ
エア受信ベイによりそれが受信され且つデコードされ
る。トランズアクションインターフェース２１０は該パ
ケットからのトランズアクションコードをデコードし且
つ開始用のタスクがローカルノード上で見つかったデス
ティネーション（宛先）アドレスにデータを書込むこと
を要求するか否かを判別するためにそれをデコードする
（ホストへのログイン）。この特定の動作は管理エージ
ェント書込動作であり、最初に管理エージェントタスク
２２５を使用する。

【０１１６】トランズアクションインターフェース２１
０はカーネル２２０からフリーなＭＭＣブロックを要求
し、そのＭＭＣブロックを受信したデータパケットから
読取ったデータで初期化し、且つそれを管理エージェン
トタスク２２５の作業用キュー（待ち行列）内にキュー
化させる。トランズアクションインターフェース２１０
へ送られたリターンコードが、このＭＭＣブロックが現
在そのキュー（待ち行列）のトップ即ち一番上にあるこ
とを示す場合には、管理エージェントタスク２２５は現
在動作しておらず且つ開始されねばならない。トランズ
アクションインターフェース２１０はＤＭＣブロックを
構築し且つ管理エージェントタスク２２５を開始するた
めにディスパッチャ２２０をコールする。次いで、ディ
スパッチャ２２０は管理エージェントタスク２２５がそ
のキュー（待ち行列）内にエントリを有するものである
ことを管理エージェントタスク２２５へ通知する。管理
エージェントタスク２２５はそのキュー（待ち行列）内
にあるＭＭＣブロック及びその中に含まれる動作をデコ
ードする。デコードされたオペレーション即ち動作は管
理エージェントタスク２２５に対して、それがホストか
ら管理ＯＲＢを読取らねばならないことを告知する。こ
のことは、トランズアクションインターフェース２１０
から送信することを包含している。ＴＭＣブロックが形
成され、管理ＯＲＢアドレス及びその他のパラメータで
初期化され且つＴＭＣキュー（待ち行列）のうちの１つ
にキュー化される。管理エージェントタスク２２５がＭ
ＭＣブロック内のタスク状態をアップデートし、従っ
て、それはＯＲＢフェッチを待機する。ＴＭＣブロック
がそのキュー（待ち行列）のトップ即ち一番上にあるこ
とをリターンコードが表示する場合には、トランズアク
ションインターフェース２１０はディスパッチャ２２０
を介して開始されねばならない。それが実行を開始した
後に、トランズアクションインターフェース２１０はＴ
ＭＣブロックをデコードして、それが送信をスケジュー
リングせねばならないか否かを判別する。それがスケジ
ューリングされ且つ実行される。

【０１１７】トランズアクションインターフェース２１
０はイニシエータから管理ＯＲＢを受取る。次いで、ト
ランズアクションインターフェース２１０はログインコ
マンドで管理エージェントタスク２２５をコールする。
管理エージェントタスク２２５はイニシエータに対して
ログインを試みる。全てのログイン基準が満足される
と、管理エージェントタスク２２５は新しいＯＭＣブロ
ックを要求する。次いで、そのＯＭＣブロックが関連性
のあるデータで初期化され、且つログイン応答が構築さ
れる。そのログイン応答はＴＭＣキュー（待ち行列）の
うちの１つへＴＭＣブロックをキュー化即ち配置させる
ことによりトランズアクションインターフェース２１０
でスケジューリングされ、ログインが成功したことをイ
ニシエータに告知する。その後に、ＴＭＣブロックをＴ
ＭＣキュー（待ち行列）のうちの１つの中に配置させる
ことによりステータスブロックがイニシエータへ送られ
る。ステータスブロックが送られた後に、オリジナルの
ＭＭＣブロックは割り当て状態から外され、フリーなメ
モリブロックプールへリターンされ、且つ管理エージェ
ントタスク２２５はそのキュー（待ち行列）内の次に高
いＭＭＣブロックについて処理を行う。当業者によって
理解されるように、トランスポートレイヤ８０として使
用されている任意のプロトコルに対する任意の機能をト
ランズアクションインターフェース２１０がコールする
ことの可能なタスクに形成することが可能である。

【０１１８】更なる例として、図１０はそのトランスポ
ートレイヤ８０としてファンクションコントロールプロ
トコル即ち機能制御プロトコルを使用する本発明の実施
例を示している。注意すべきことであるが、トランズア
クションハードウエア２０５、トランズアクションイン
ターフェース２１０、カーネル２２０は図３に示した実
施例と同一の機能を有している。更に、直列バス管理タ
スク２３５及びアプリケーションタスク２７５も図３に
示した実施例と同様である。然しながら、例えばアプリ
ケーション／ＦＣＰコマンド実行タスク２９５等の幾つ
かのタスクは使用されるプロトコル、この場合にはＦＣ
Ｐに対して特別に形成される。ＣＳＲ管理タスク２８５
は１３９４バスを実現するために必要とされるＣＳＲサ
ービスを包含する別の方法である。図３に示した実施例
においては、これらのサービスは直列バス管理タスク２
３５によって取扱われる。

【０１１９】１３９４バスと共に使用する可能性のある
アプリケーション及びプロトコルの幾つかを図１８に示
してある。本明細書に記載したように通信制御器２００
を使用する１３９４バスは殆ど任意のタイプの周辺装置
を互いに接続させることを可能とする。図１８におい
て、１３９４バスは図の底部に示してあり且つそれが非
同期及びアイソクロノス（等時性）の両方の能力を有す
るものであることを示している。１３９４バスの次に上
のレイヤは図２に示したトランスポートレイヤの例を示
している。ＳＢＰ−２、ＦＣＰ及びＳＢＰ−２共通アイ
ソクロノスパケットフォーマットが示されている。トラ
ンスポートレイヤ８０の次に上のレイヤは図２に示した
ようにアプリケーションレイヤ９０の例を示している。
例えばハードディスクドライブ及びデジタルビデオディ
スクドライブに使用されるＭＭＣ−２、プリンタと共に
使用されるプロトコルであるＰＷＧ、ハードディスクド
ライブと共にしばしば使用される別のプロトコルである
ＲＢＣ、民生電子装置に対して使用されるＡＶトランズ
アクションセット等の上位レベルのプロトコルが示され
ている。次に、アプリケーションレイヤ９０の上には、
プリンタ、ハードディスクドライブ、ＤＶＤプレイヤ等
のそれらの下側にリストされているプロトコルを使用す
る装置が示されている。勿論、ここにリストしたもの以
外のその他の周辺装置が効果的に且つ異なるアプリケー
ション又はトランスポートプロトコルと共に１３９４バ
スを使用することが可能である。上述したように、この
ことは１３９４バスのその他のバスとの互換性を拡張さ
せる。

【０１２０】以上、本発明の具体的実施の態様について
詳細に説明したが、本発明は、これら具体例にのみ制限
されるべきものではなく、本発明の技術的範囲を逸脱す
ることなしに種々の変形が可能であることは勿論であ
る。

【図面の簡単な説明】

【図１】 可能性のある１３９４バス形態を示した概略
図。

【図２】 １３９４スタンダードのレイヤ及び１３９４
スタンダードのレイヤと相互作用を行うレイヤを示した
概略図。

【図３】 本発明の１実施例に基づくサービス及びタス
クを示した概略図。

【図４】 メッセージ制御ブロック構造を示した概略
図。

【図５Ａ】 トランズアクションインターフェース用の
メッセージ制御ブロックであって、どのアクションがと
られたかに依存するメッセージ制御ブロックに対する特
定のデータ構造を示した概略図。

【図５Ｂ】 トランズアクションインターフェース用の
メッセージ制御ブロックであって、どのアクションがと
られたかに依存するメッセージ制御ブロックに対する特
定のデータ構造を示した概略図。

【図５Ｃ】 トランズアクションインターフェース用の
メッセージ制御ブロックであって、どのアクションがと
られたかに依存するメッセージ制御ブロックに対する特
定のデータ構造を示した概略図。

【図５Ｄ】 トランズアクションインターフェース用の
メッセージ制御ブロックであって、どのアクションがと
られたかに依存するメッセージ制御ブロックに対する特
定のデータ構造を示した概略図。

【図５Ｅ】 トランズアクションインターフェース用の
メッセージ制御ブロックであって、どのアクションがと
られたかに依存するメッセージ制御ブロックに対する特
定のデータ構造を示した概略図。

【図５Ｆ】 トランズアクションインターフェース用の
メッセージ制御ブロックであって、どのアクションがと
られたかに依存するメッセージ制御ブロックに対する特
定のデータ構造を示した概略図。

【図５Ｇ】 トランズアクションインターフェース用の
メッセージ制御ブロックであって、どのアクションがと
られたかに依存するメッセージ制御ブロックに対する特
定のデータ構造を示した概略図。

【図５Ｈ】 トランズアクションインターフェース用の
メッセージ制御ブロックであって、どのアクションがと
られたかに依存するメッセージ制御ブロックに対する特
定のデータ構造を示した概略図。

【図５Ｉ】 トランズアクションインターフェース用の
メッセージ制御ブロックであって、どのアクションがと
られたかに依存するメッセージ制御ブロックに対する特
定のデータ構造を示した概略図。

【図６】 トランズアクションインターフェースのデー
タの流れを示した概略図。

【図７】 （Ａ），（Ｂ），（Ｃ）は夫々どれだけのデ
ータを送るかに依存してデータがどのようにして送信ベ
イへ供給されるかを示した概略図。

【図８】 １３９４バスへデータを送る場合に使用され
るデータ構造を示した概略図。

【図９】 データパケットが１３９４バス上のノードで
受取られた場合の実行の流れを示したフローチャート。

【図１０】 本発明の別の実施例に基づくサービス及び
タスクを示した概略図。

【図１１】 コマンドＯＲＢ実行タスクの状態を示した
状態図。

【図１２】 フェッチ管理タスクの状態及び実行の流れ
を示した状態図。

【図１３】 ＯＲＢフェッチタスクの状態を示した状態
図。

【図１４】 非請求ステータスタスクの状態を示した状
態図。

【図１５Ａ】 管理エージェントタスクの状態を示すテ
ーブルを示した概略図。

【図１５Ｂ】 管理エージェントタスクの状態を示すテ
ーブルを示した概略図。

【図１５Ｃ】 管理エージェントタスクの状態を示すテ
ーブルを示した概略図。

【図１５Ｄ】 管理エージェントタスクの状態を示すテ
ーブルを示した概略図。

【図１５Ｅ】 管理エージェントタスクの状態を示すテ
ーブルを示した概略図。

【図１６】 直列バス管理タスクの状態を示した状態
図。

【図１７】 アプリケーションタスクの状態を示した状
態図。

【図１８】 １３９４バスと共に使用することの可能な
アプリケーション及びプロトコルを示した概略図。

【符号の説明】

２００ トランスポートプロトコルインターフェース ２０５ トランズアクションハードウエア ２１０ トランズアクションインターフェース ２１５ フェッチ管理タスク ２２０ カーネル／スケジューラ／ディスパッチャ ２２５ 管理エージェントタスク ２３５ 直列バス管理タスク ２４５ コマンドＯＲＢ実行タスク ２５５ ＯＲＢフェッチタスク ２６５ 非請求ステータスタスク ２７５ アプリケーションタスク

───────────────────────────────────────────────────── フロントページの続き (72)発明者 アンソニー フォン アメリカ合衆国， カリフォルニア 94566， プリーザントン， パセオ グ ラナダ 3077 (72)発明者 ピーター グロス アメリカ合衆国， カリフォルニア 95131， サン ノゼ， ティー ローズ サークル 1375 (72)発明者 ジム シー． ツ アメリカ合衆国， カリフォルニア 95051， サンタ クララ， レスター コート 322 (72)発明者 ダニー ケイ． ウイ アメリカ合衆国， カリフォルニア 94560， ニューアーク， ベルヘイブン アベニュー 6048 (72)発明者 ハリー エス． フォストフ アメリカ合衆国， カリフォルニア 95139， サン ノゼ， スコウヒーガン コート 139

Claims (24)

【特許請求の範囲】
1. 【請求項１】 送信ベイを具備するハードウエアを有す
   る直列バス上のノードにおけるトランズアクションイン
   ターフェースにおいて、 各メッセージ制御ブロックが組織化されたデータを含む
   １個又はそれ以上のメッセージ制御ブロックを受付ける
   構成とされているキュー、 前記メッセージ制御ブロックを読取り且つ前記組織化し
   たデータをデータパケットへ変換させる構成とさせてい
   る変換エンジン、 前記データパケットをバス上に配置させるべく前記送信
   ベイへ通過させる構成とされている出力ポート、を有し
   ていることを特徴とするトランズアクションインターフ
   ェース。
2. 【請求項２】 請求項１において、前記データパケット
   が前記送信ベイ内のハードウエアレジスタ内に書込まれ
   ることを特徴とするトランズアクションインターフェー
   ス。
3. 【請求項３】 請求項２において、前記データパケット
   が前記ハードウエアレジスタへ書込まれた後に、前記送
   信ベイ内にデータが存在することを表わすためにトリガ
   ビットがセットされることを特徴とするトランズアクシ
   ョンインターフェース。
4. 【請求項４】 請求項１において、更に、 前記キューにおいて受付けられたブロックよりも一層高
   い優先度を有するメッセージ制御ブロックを受付ける構
   成とされている第二キュー、 前記第二キューにおいて受取られたブロックよりも一層
   高い優先度を有するメッセージ制御ブロックを受付ける
   構成とされている第三キュー、を有していることを特徴
   とするトランズアクションインターフェース。
5. 【請求項５】 請求項１において、更に、複数個の送信
   ベイと出力ポートとを有しており、前記送信ベイの各々
   は前記出力ポートの夫々の１つと関連しており、且つ各
   出力ポートは、各データパケットに対して、それの夫々
   の送信ベイへデータパケットを通過させることを試み、
   且つビジーである場合には、ビジーでない送信ベイが見
   つかるまで前記データパケットを別の送信ベイへ通過さ
   せることを繰返し試みる構成とされていることを特徴と
   するトランズアクションインターフェース。
6. 【請求項６】 請求項５において、トランズアクション
   インターフェースにおける出力ポートの総数及び送信ベ
   イの総数が３であることを特徴とするトランズアクショ
   ンインターフェース。
7. 【請求項７】 請求項１において、前記ハードウエア
   が、更に、ＤＭＡチャンネルを有していることを特徴と
   するトランズアクションインターフェース。
8. 【請求項８】 請求項１において、前記ハードウエア
   が、更に、ペイロードデータ送信ベイを有していること
   を特徴とするトランズアクションインターフェース。
9. 【請求項９】 請求項８において、１３９４プロトコル
   に従うロック応答を有するデータが前記送信ベイ及び前
   記ペイロードデータ装置ベイの両方を使用して前記ノー
   ドによって送給されることを特徴とするトランズアクシ
   ョンインターフェース。
10. 【請求項１０】 請求項１において、更に、前記直列バ
    スからのデータパケットを受取る構成とされている受信
    ハードウエアベイを有していることを特徴とするトラン
    ズアクションインターフェース。
11. 【請求項１１】 請求項１において、前記キューによっ
    て受取られるメッセージ制御ブロックがトランズアクシ
    ョンメッセージ制御ブロックであることを特徴とするト
    ランズアクションインターフェース。
12. 【請求項１２】 少なくとも２個の送信ベイを具備する
    ハードウエアインターフェースを有する直列バス上のノ
    ードにおけるトランズアクションインターフェースにお
    いて、 各メッセージ制御ブロックが組織化されたデータを含ん
    でいる１個又はそれ以上のメッセージ制御ブロックを受
    取る構成とされているキュー、 前記メッセージ制御ブロックを読取り且つ前記組織化さ
    れたデータをデータパケットへ変換させる構成とされて
    いる１組の論理プロセス、 各々が夫々の送信ベイへ関連しており且つ各々が前記デ
    ータパケットをそれの夫々の送信ベイへ又はバス上に配
    置されるべく別の送信ベイへ通過させる構成とされてい
    る少なくとも２個の出力ポート、を有していることを特
    徴とするトランズアクションインターフェース。
13. 【請求項１３】 請求項１２において、前記データパケ
    ットが送信ベイレジスタ内へ書込まれることを特徴とす
    るトランズアクションインターフェース。
14. 【請求項１４】 請求項１２において、更に、 前記キューにおいて受付けられるメッセージ制御ブロッ
    クよりも一層高い優先度を持ったメッセージ制御ブロッ
    クを受付ける構成とされている複数個の優先度キュー、
    を有していることを特徴とするトランズアクションイン
    ターフェース。
15. 【請求項１５】 請求項１２において、前記送信ベイの
    各々が夫々の出力ポートへ関連しており、且つ前記出力
    ポートのうちの１つが前記送信ベイへデータパケットを
    通過させる前に、前記１組の論理プロセスがデータ構造
    をチェックして存在する場合に前記トランズアクション
    インターフェースの送信ベイのうちのいずれがデータを
    それに書込むためにフリーであるかを決定することを特
    徴とするトランズアクションインターフェース。
16. 【請求項１６】 請求項１５において、前記１組の論理
    プロセスがその他の送信ベイをチェックする前に前記出
    力ポートの夫々の送信ベイをチェックすることを特徴と
    するトランズアクションインターフェース。
17. 【請求項１７】 請求項１２において、トランズアクシ
    ョンインターフェースにおける出力ポートの総数及び送
    信ベイの総数が３であることを特徴とするトランズアク
    ションインターフェース。
18. 【請求項１８】 請求項１２において、前記ハードウエ
    アが更にＤＭＡチャンネルを有していることを特徴とす
    るトランズアクションインターフェース。
19. 【請求項１９】 請求項１２において、更に、前記直列
    バスからデータパケットを受取る構成とされているハー
    ドウエア受信ベイを有していることを特徴とするトラン
    ズアクションインターフェース。
20. 【請求項２０】 直列バスに対してデータを取扱う方法
    において、 バスへ送られることとなっているデータを含むメッセー
    ジ制御ブロックをキューにおいて受付け、 送られるべきデータを１個又はそれ以上のパケットへフ
    ォーマットし、 前記メッセージ制御ブロック内に含まれているその他の
    データを前記パケット用のパケットヘッダへフォーマッ
    トし、 前記パケット及び前記パケットヘッダを直列バスへのハ
    ードウエアインターフェースへ書込み、 前記パケットが書込まれたハードウエアインターフェー
    スと通信を行う、ことを特徴とする方法。
21. 【請求項２１】 請求項２０において、ハードウエアイ
    ンターフェースに対して前記パケット及び前記パケット
    ヘッダを書込む場合に、 複数個の出力ノードのうちの１つにおいて、複数個のハ
    ードウエアレジスタのうちの夫々の１つが現在使用可能
    であるか否かを決定するためにデータ構造を評価し、 前記夫々のハードウエアレジスタが使用可能である場合
    には、データパケットを前記ハードウエアレジスタへ書
    込み、 前記夫々のハードウエアレジスタが使用可能でない場合
    には、その中にデータを有することのないハードウエア
    レジスタが見つかるまで順番に前記ハードウエアレジス
    タの全てを逐次的に評価する、ことを特徴とする方法。
22. 【請求項２２】 請求項２０において、メッセージ制御
    ブロックを受付ける場合に、複数個のキューのうちの１
    つにおいてメッセージ制御ブロックを受取り、各キュー
    が他のキューと異なる実行用の優先度を有するものとし
    て指定されていることを特徴とする方法。
23. 【請求項２３】 請求項２０において、１つ又はそれ以
    上のパケットへ送られるべきデータをフォーマットする
    場合に、データをブロックにカプセル化し、該ブロック
    の寸法は直列バスの速度によって制限されることを特徴
    とする方法。
24. 【請求項２４】 請求項２０において、前記ハードウエ
    アインターフェースに対する通信を行う場合に、前記ハ
    ードウエアインターフェースにおけるトリガビットをセ
    ットすることを特徴とする方法。