JPH06161932A

JPH06161932A - 入力／出力制御装置および方法

Info

Publication number: JPH06161932A
Application number: JP5167394A
Authority: JP
Inventors: Carl Ellison; カール・エリソン; Randy Sybel; ランディー・シベル; William D Snapper; ウィリアム・ディー・スナッパー; Jonathan West; ジョナサン・ウェスト
Original assignee: Stratus Computer Inc
Current assignee: Ascend Communications Inc
Priority date: 1992-06-15
Filing date: 1993-06-15
Publication date: 1994-06-10
Anticipated expiration: 2017-05-13
Also published as: EP0578013A1; DE69317481T2; DE69317481D1; JP3280759B2; CA2098350A1; ATE164243T1; EP0578013B1; US5475860A; AU4124993A

Abstract

(57)【要約】【目的】ディジタルデータ処理装置、特にディジタル
データ処理機能ユニット間において情報を転送するため
の装置および方法を提供する。【構成】ディジタルデータ処理装置は、二つの機能ユ
ニットおよびコントローラを備えており、それらの間で
情報が転送される。各機能ユニットは、ランダムアクセ
スメインメモリのような関連するメモリ要素を有してい
る。第１の機能ユニットは、データが転送送出されるべ
き関連するメモリ内の１または複数のアドレスを特定す
るメッセージ記述子ブロック（ＭＤＢ）送信信号を発生
する送信要素（センダ）を備える。コントローラは、選
択されたＭＤＢ受信信号に整合するＭＤＢ送信信号を識
別し、整合しているＭＤＢ信号により特定される第１お
よび第２機能ユニットの対応するメモリ位置間に置いて
データの転送を実行する信号を発生する。本発明による
と、ディジタルデータ処理機能ユニット間における情報
の転送効率が向上される。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、ディジタルデータ処理
に関し、特定すると、ディジタルデータ処理機能ユニッ
ト間にいて情報を転送するための方法および装置に関す
る。本発明は、例えば、ホストメインフレームコンピュ
ータと周辺デバイスとの間の情報転送に応用可能性を有
する。

【０００２】

【従来技術】ホストデバイスから周辺デバイスにデータ
を転送するための入力／出力コントローラは周知であ
る。本発明の譲受人に譲渡された米国特許第4,926,315
号は、入力／出力コントローラがデュアルバス構造体を
介して周辺デバイスと接続されるコンピュータシステム
を例示している。コントローラは、二重ストローブ信号
をバスに供給し、それによりユニット間におけるデータ
（および制御）信号の転送のタイミングを定める。各周
辺デバイスは、タイミング信号を監視し、バス上に受信
される情報の処理を開始させる。

【０００３】米国特許第4,939,643 号に従うと、入力／
出力コントローラは、バス構造体を介してサイクル開始
信号を伝送することによって、周辺デバイス間における
データ転送サイクルを開始させる。同時に、入力／出力
コントローラは周辺デバイスアドレス信号を転送する。
伝送中フォルト（障害）が起こると、周辺デバイスはWA
IT（待ち）信号を発生し、そしてこの信号は、バス上に
おけるコントローラによる後続の転送を遅延させる。

【０００４】目下出願中の一緒に譲渡された米国特許出
願第743,992 号は、直接メモリアクセス（ＤＭＡ）およ
びプロセッサ命令（ＰＩＤ）両モードで周辺デバイスで
情報を転送する入力／出力コントローラを開示してい
る。コントローラは、DMA 転送中一緒に働くDMA 回路お
よびPIO 回路を有しており、局部的プロセッサの介入な
しでデータと命令の伝送をインターリーブ、すなわち交
互配置させる。

【０００５】

【発明の課題】上述の特許および特許出願に記述される
コントローラは非常に有効であることが分かったが、例
えば入力／出力コントローラで使用できるさらに良いデ
ータ転送装置の必要性はなお存在する。

【０００６】したがって、本発明の目的は、ディジタル
データ処理機能ユニット間において情報を転送するため
の改良された方法および装置を提供することである。

【０００７】本発明の特定の目的は、付随するソフトウ
ェアおよびハードウェア機構の複雑性を最小化しなが
ら、周辺装置のような機能ユニットへのデータの迅速な
転送を容易にする改良された入力／出力制御装置および
方法を提供することである。

【０００８】本発明の他の特定の目的は、タイミングエ
ラーに対する不感知性が改善された機能ユニット間デー
タ転送機構を提供することである。本発明の他の目的
は、以下の説明から明らかとなろう。

【０００９】

【課題を解決するための手段】これらおよびその他の目
的は、本発明の一側面においては、二つの機能ユニット
（例えばホスト処理部と周辺デバイス）を有するディジ
タルデータ処理装置と両者間において情報を転送するた
めのコントローラを提供することにより達成される。第
１機能ユニットは、メッセージ送信記述子（ディスクリ
プタ）ブロック（「ＭＤＢ」）送信信号を発生し、これ
によりデータが送出転送されるべき関連する局部メモリ
内の１または複数のアドレスを特定する。第２機能ユニ
ットは、データが転送されるべきその関連する局部メモ
リ内の１または複数の位置を特定するＭＤＢ信号を発生
する。

【００１０】コントローラは、ＭＤＢ送信および受信信
号、特に同じ論理または仮想チャンネルを特定するもの
を整合させる。一度整合が見いだされると、コントロー
ラは、第１および第２機能ユニットのそれぞれのメモリ
間においてデータを転送する。

【００１１】上述のコントローラは、ホストおよび周辺
プロセッサ間において、それらのそれぞれの「メモリス
ペース」のデータに直接的にアクセスすることによって
データを転送する。かくして、本発明の１側面に従がう
と、ホストプロセッサおよび周辺デバイスは、そうでな
い場合は相互に隔絶されている。すなわち、ホストプロ
セッサおよび周辺装置は、いずれもが他のメモリを直接
読んだり書き込んだりできないように構成される。当技
術に精通したものであれば、そのように構成されたシス
テムは、違法なデータアクセスと関連する障害を受けに
くいことを理解できよう。

【００１２】本発明の他の側面に従うと、送信要素（セ
ンダ）および受信要素（レシーバ）は、通信が行われる
べきチャンネルを特定する仮想チャンネル番号を含め
て、それらのそれぞれのＭＤＢ信号を発生する。

【００１３】一度仮想チャンネルが設定されると、コン
トローラの仮想チャンネル回路は、受信中、類似の仮想
チャンネル番号を有するＭＤＢ送信または受信信号より
それぞれ成る各非整合のＭＤＢ送信または受信信号を記
憶する。本発明の一側面に従うと、仮想チャンネル番号
は、連結リストヘッド配列に対するインデックスであ
る。かかる各リストは、そのチャンネルに対する非整合
ＭＤＢのFIFOとして作用する。連結リストヘッドは、連
結リストヘッドの第１および最後の要素へのポインタを
含む構造体であり、ブロックを最小の努力で終端に取り
つけかつ前部から除去することができるようになされて
いる。

【００１４】上述の仮想チャンネル機能を有するコント
ローラは、コントローラを各機能ユニットに接続するの
に単一の物理的通信路（またはバス）しか存在しないに
拘わらず、複数のそれぞれの仮想チャンネルを介して複
数の通信トランザクションを処理することができる。

【００１５】関連する側面として、上述のコントローラ
は、機能ユニット間に仮想チャンネルを創成し、破壊
し、維持するための仮想チャンネル管理装置を備え得
る。詳述すると、各機能ユニットは、他の機能ユニット
と通信のための新しい仮想チャンネルの創成を要求する
MDB 信号を発生し得る。仮想チャンネル管理装置は、そ
の要求に応答して、かかるチャンネルを開き、チャンネ
ル番号を割り当て、要求中の機能ユニットに、割り当て
られた番号について報知し得る。その仮想チャンネル管
理装置は、それ自体、仮想チャンネルを介して要求中の
機能ユニットと接続され得る。

【００１６】本発明に従うシステムは、さらに、第１お
よび第２機能ユニット間において特定の形式の情報を転
送するための予定されたドライバ制御仮想チャンネルを
含む。そのチャンネルは、例えば、第２機能ユニット
に、特定の通信トランザクションが行われるべき新しい
仮想チャンネルについて信号するために、第１の機能ユ
ニットにより使用できる。

【００１７】他の関連する側面として、本発明に従うシ
ステムは、コントローラと機能ユニット間に診断および
エラーメッセージを転送するための予定された保守およ
び診断チャンネル、ならびにユニット間でデバッグ信号
を転送するための予定されたデバッガチャンネルを組み
込むことができる。

【００１８】本発明の他の側面によると、上述の形式の
ディジタルデータプロセッサであって、コントローラ
が、一度要求された情報転送が完了すると、MDB を信号
中の機能ユニットに戻すための要素を備えるディジタル
データプロセッサが提供される。さらに詳しく言うと、
戻されたＭＤＢは、ＭＤＢを発した機能ユニット内のFI
FOバッファに戻される。

【００１９】本発明の他の側面においては、機能ユニッ
トの送信および受信ユニットは、それらのそれぞれのＭ
ＤＢの復帰の際実行されるべき動作を特定し得る。かく
して、例えば、第１機能ユニットの送信要素は、そのMD
B で、対応する転送の完了の際、例えば転送に関係しそ
のコードのみに関係するかかるMDB データに取り付けら
れ得るあるコードが実行されるべきことを特定し得る。

【００２０】

【実施例の説明】以下図面を参照して本発明を好ましい
実施例について説明する。図１は、本発明の好ましい実
施例に従って構成された障害許容周辺入力／出力システ
ムをもつディジタルデータ処理システム５’を示してい
る。このシステム５’は、通信のためにシステムバス２
２’を介して接続された組になった中央処理装置１０’
及び１２’と、組になったランダムアクセスメモリユニ
ット１４’及び１６’と、組になった入力／出力コント
ローラ１８’及び２０’とを含んでいる。

【００２１】フラッシュバス１９’を介して結合される
入力／出力コントローラ１８’及び２０’は、システム
バス２２’により表されるシステムバックプレーンと一
つあるいはそれ以上の周辺デバイス２４’、２６’及び
２８’との間での情報及び制御信号の転送を制御する。
これらの周辺デバイスは、永久記憶媒体（例えば、ディ
スク及びテープドライブ）と、通信コントローラと、ネ
ットワークインタフェースと、その他とを含むことがで
きる。

【００２２】周辺デバイスの制御及び情報信号の転送
は、デュアル入力／出力バス３０Ａ’及び３０Ｂ’を含
む周辺バス３０’を介して生じる。これらのバスを介し
て転送される信号は、ゲートアレイ３２’、３４’、３
６’、３８’、４０’、４２’とアダプタ４４’、４
６’、４８’とを介して周辺デバイス２４’、２６’、
２８’へ転送(route) される。

【００２３】図示されるように、各周辺デバイス（例え
ば、装置２４’）は、ゲートアレイのペア（例えば、ア
レイ３２’及び３４’）と、アダプタ（例えば、アダプ
タ４４’）とに結合される。対になったゲートアレイ
（例えば、アレイ３２’及び３４’）は、（図のよう
に）通信線路によって相互接続される。

【００２４】さらに、各ゲートアレイは、線路５６
Ａ’、５６Ｂ’、５８Ａ’、５８Ｂ’、６０Ａ’、６０
Ｂ’で示されるアダプタバスによってその関連するアダ
プタと接続される。続いて、アダプタ４４’、４６’、
４８’は、局部的周辺線路を介して各関連する周辺デバ
イス２４’、２６’、２８’と結合される。

【００２５】周辺バス３０’、特に第一及び第二の入力
／出力バス３０Ａ’、３０Ｂ’は、ターミネータ６
２’、６４’によって終端される。

【００２６】好ましい実施例によれば、入力／出力バス
３０Ａ’及び３０Ｂ’は、冗長信号キャリアとして働
く。すなわち、バス３０Ａ’及び３０Ｂ’は、全く同様
の情報信号を同期的かつ同時に転送する。この配線が、
転送障害の検出を容易にして、障害のないバスを介して
連続で割り込みのない処理と通信とを可能にする。

【００２７】好ましい実施例によれば、各バス３０Ａ’
及び３０Ｂ’は、データ信号用と、制御信号用と、パリ
ティ信号用と、ストローブ信号用と、「待ち」信号用と
の導線を含んでいる。物理的に、バス３０’は、各々の
ケーブルがより合わされた３０対の二本のケーブルを使
って実行できる。この実行が、一方のケーブルを使用し
て転送４ＭＨｚでの冗長８ビット転送、あるいは別に両
方のケーブルを使用して４ＭＨｚでの冗長１６ビット転
送を可能にする。バス３０’に沿う情報の転送は、２５
０ナノ秒のサイクル速度で生じて、４メガバイト／秒の
８ビット転送と、８メガバイト／秒の１６ビット転送と
を提供する。

【００２８】各入力／出力線路３０Ａ’及び３０Ｂ’の
データ信号用と、制御信号用と、パリティ信号用と、待
ち信号用との線路は、オープンコレクタ導線であり、例
えばモトローラ社製の２６Ｓ１０トランシーバによって
駆動される。二本のストローブ線路が、各バス３０Ａ’
及び３０Ｂ’に備わっている。これら対の線路は、入力
／出力コントローラ１８’、２０’において駆動され、
ターミネータ６２’、６４’で受け取られる異なる信号
キャリアとして働く。

【００２９】単一の板上に備えつけできるゲートアレイ
のペアは、アダプタのシャーシ（図示なし）のスロット
内に挿入される。各スロットは、関連する周辺デバイス
のアドレスを定義するslot−idと関連づけられる。一つ
の実施例において、シャーシは、最端のターミネータ６
２’、６４’が最後の二つのスロットを占めて、１６個
のこのアドレス指定可能なスロットを維持する。

【００３０】ディジタルデータプロセッサ５’をもっと
完全に理解することは、本願の譲受人に譲渡された次の
特許及び特許出願を参照することで達成できる。これら
の技術は、参照によって本願に組み込まれている。Wolf
f 他の「COMPUTER PERIFERAL CONTROL APPARATUS」と題
する米国特許第4,486,826 号；「FAULT-TOLERANT COMPU
TER SYSTEM HAVING EXPANDABLE PROCESSOR」と題するWi
lliamsの米国特許第4,816,990 号；「DIGITAL DATA PRO
PCESSING APPARATUS WITH PIPELINED MEMORY CYCLES 」
と題するReidの米国特許第4,866,604 号；「FAULT-TOLE
RANT DIGITAL TIMING APPARATUS AND METHOD」と題する
Batyの米国特許第4,920,540 号；「METHOD AND APPARAT
US FOR DETECTING SELECTED ABSENCE OF DIGITAL LOGIC
SYNCHRONISM」と題するWilliamsの米国特許第5,020,024
号；「COMPUTER PERIFERAL CONTROL APPARATUS」と題
するWolff 他の米国特許第4,486,826 号；「DIGITAL DA
TA PROCESSOR WITH FAULT TOLERANT PERIPHERAL BUS CO
MMUNICATION 」と題するLong他の米国特許第4,926,315
号；「CENTRAL PROCESSING APPARATUS」と題するReidの
米国特許第4,453,215 号；「DIGITAL DATA PROCESSOR W
ITH HIGH RELIABILITY」と題するSamson他の米国特許第
4,654,857 号；「DIGITAL DATA PROCESSOR WITH FAULT
TOLERANT BUS PROTOCOL 」と題するGardner 他の米国特
許第4,750,177 号；「METHOD AND APPARATUS FOR MONIT
ORING PERIPHERAL DEVICE COMMUNICATION」と題するBat
y他の米国特許第4,931,922 号；「FAULT TOLERANT DIGI
TAL DATA PROCESSOR WITH IMPROVED BUS PROTOCOL」と
題するLongの米国特許第4,939,643 号；「FAULT TOLERA
NT DIGITAL DATA PROCESSOR WITH IMPROVED INPUTB／OU
TPUT CONTROLLER 」と題するLongの米国特許第4,974,15
0 号；「FAULT TOLERANT DIGITAL DATA PROCESSOR WITH
IMPROVED PERIPHERAL DEVICE INTERFACE 」と題するLo
ngの米国特許第4,974,144 号；「EMI CABINET WITH IMP
ROVED INTERFACE SUPRESSION」と題するVowlesの米国特
許第5,049,701 号；１９９２年５月８日に出願された米
国特許第07／884,257 号（Attorney Docket No.SCM-050
CN）のために放棄された「OPTIMIZED INTERCONNECT NET
WORKS 」と題して１９８９年５月１９日に出願されたBa
ty他の米国特許出願第354,139 号；「FAULT-TOLERANT U
NIX-TYPE DIGITAL DATA PROCESSING METHOD AND APPARA
TUS 」と題して１９９１年２月２１日に出願されたYama
da他の米国特許出願第659,597 号；「HIERARCHICAL MEM
ORY MANAGEMENT APPARATUS AND METHOD 」と題して１９
９１年５月２日に出願されたStonerの米国特許出願第69
4,556 号；「FAULT TOLERANT PROCESSING SECTION WITH
DYNAMICALLY RECONFIGURABLE VOTING」と題して１９９
１年５月６日に出願されたCheungの米国特許出願第696,
129 号；「DIGITAL DATA PROCESSOR WITH MAINTENANCE
AND DIAGNOSTIC SYSTEM 」と題して１９９１年６月２８
日に出願されたBullisの米国特許出願第723,065 号；
「FAULT-TOLERANT UNIX-TYPE DIGITAL DATA PROCESSING
METHOD AND APPARATUS 」と題して１９９１年７月１日
に出願されたYamada他の米国特許出願第723,803 号；
「I/O CONTROLLER APPARATUS AND METHOD FOR TRANSFER
RING DATA BETWEEN AHOST PROCESSOR AND MULTIPLE I/O
UNITS 」と題して１９９１年８月１２日に出願されたL
ambの米国特許出願第743,992 号；「PROGRAMMABLE INTE
RRUPT PRIORITY ENCODER METHOD AND APPARATUS」と題
して１９９１年８月１２日に出願されたLambの米国特許
出願第743,691 号；「FAULT TOLERANT PROCESSING SECT
ION WITH DYNAMICALLY RECONFIGURABLE VOTING」と題し
て１９９２年５月１３日に出願されたCheungの米国特許
出願第07/882,474号（Attorney Docket No. SCM-082CN
）

【００３１】データ転送システム図２は、図１に示すディジタルデータ処理装置５’と結
合して使用する本発明によるデータ転送５としての好ま
しいシステムを示す。この図示したシステム５は、装置
の機能ユニット間のデータ転送を容易にする。さらに詳
しく言うと、このシステム５は、システムバックプレー
ン（図１のシステムバス２２’）と（図１の）周辺デバ
イス２４’、２６’、２８’との間で情報及び制御信号
を転送する。データ転送システム５は、また他の機能ユ
ニット（例えば、中央処理装置）間の通信を容易にする
のに使用できるということは理解されよう。

【００３２】本発明の技術に基づいて、図示したデータ
転送システム５は、特殊な目的のハードウエアと、一般
あるいは特殊な目的のプロセッサでの実施のためのソフ
トウエアとに実行できる。以下に開示する実施例は、本
願で開示する図１のディジタルデータプロセッサ５’と
結合して動作するためのソフトウエアにおいて実行され
る。

【００３３】図示したデータ転送システム５は、例え
ば、図１の入力／出力コントローラ１８’、２０’に対
応する入力／出力コントローラ１０と、図１の中央処理
装置１０’、１２’に対応するホストデバイス４０と、
図１の周辺デバイス２８’とこれに関連づけられたイン
タフェース回路要素（例えば、ゲートアレイ４０’、４
２’及びアダプタ４８’）とに対応する周辺デバイス５
０と、として指示される複数の構成要素を含んでいる。

【００３４】上記の対応する構成要素の動作をよりよく
理解することは、Wolff 他の「COMPUTER PERIFERAL CON
TROL APPARATUS」と題する米国特許第4,486,826 号と、
「I/O CONTROLLER APPARATUS AND METHOD FOR TRANSFER
RING DATA BETWEEN A HOST PROCESSOR AND MULTIPLE I/
O UNITS (Attorney Docket SCM-070) 」と題するLambの
米国特許出願第743,992 号と、「PROGRAMMABLE INTERRU
PT PRIORITY ENCODERMETHOD AND APPARATUS (Attorney
Docket SCM-073)」と題するLambの米国特許出願第743,6
91 号とを参照することによって達成される。

【００３５】図２を参照すると、図示されたホストデバ
イス４０は、コマンドＦＩＦＯ１５と、メッセージ送信
機４１と、メッセージ受信機４２と、メモリ４３と、リ
ターンＦＩＦＯ４４と、コールバックユニット４５とを
含んでいる。図示された入力／出力コントローラ１０
は、仮想チャンネル要素２５と、データ転送要素３０
と、リターン要素３５とを含んでいる。周辺デバイス５
０は、コマンドＦＩＦＯ２０と、メッセージ送信機４９
と、メッセージ受信機５１と、メモリ５３と、リターン
ＦＩＦＯ５４と、コールバックユニット５５とを含んで
いる。

【００３６】ホストプロセッサ４０は、バスを介して入
力／出力コントローラ１０と結合されている。これは、
従来の設計でもよいが、Wolff 他の「COMPUTER PERIFER
AL CONTROL APPARATUS」と題する米国特許第4,486,826
号のバックプレーンバスに関連して開示された設計及び
構成が好ましい。同様に、周辺デバイス５０（及び関連
インタフェース回路要素）も従来のバスを介して入力／
出力制御装置１０と接続できる。この相互接続は、この
同一特許において開示された型の周辺デバイスバスを介
して行われるのが好ましい。

【００３７】インタフェース８０及び９０各々は、入力
／出力コントローラと機能ユニットとの間の通信を扱う
ための三つの経路、（ｉ）ＭＤＢを入力／出力コントロ
ーラへ通信するための経路と、（ｉｉ）（入力／出力コ
ントローラが機能ユニット内のメモリから入力／出力コ
ントローラによって提供されるアドレスを読み出しかつ
書き込みする）読み出し／書き込みメモリバス経路と、
（ｉｉｉ）完了したＭＤＢを機能ユニットへ戻す通信を
行うための経路とを含んでいる。各経路は、他の経路と
独立して動作する。図示した実施例において、機能ユニ
ットがホストの場合、インタフェースはシステムバス
（２２’）を使用し、機能ユニットが周辺デバイスの場
合、インタフェースはＰＱバス（３０’、３２’、３
４’、４４’）を使用する。

【００３８】図示した実施例において、ホストデバイス
４０内のプロセッサ９２は、このインタフェースのプロ
セスのためとこのデバイスの図示した構成要素のための
独立プロセッサとして働く。同様に、入出力コントロー
ラ１０及び周辺デバイス５０（あるいは、関連インタフ
ェース回路）それぞれの局部のプロセッサ９３及び９４
は、これらインタフェースのプロセスとこれらユニット
の各構成要素とを駆動する。

【００３９】プロセッサ９２、９３及び９４は、従来の
汎用型の処理装置にできるけれども、図示したプロセッ
サ９２は、Wolff 他の米国特許第4,486,826 号と、本発
明の譲受人に譲渡された他の上記の特許及び特許出願と
に開示された型の中央処理装置が好ましい。

【００４０】プロセッサ９３及び９４は、Wolff 他の
「COMPUTER PERIFERAL CONTROL APPARATUS」と題する米
国特許第4,486,826 号と、「I/O CONTROLLER APPARATUS
AND METHOD FOR TRANSFERRING DATA BETWEEN A HOST P
ROCESSOR AND MULTIPLE I/O UNITS (Attorney Docket S
CM-070) 」と題するLambの米国特許出願第743,992 号
と、「PROGRAMMABLE INTERRUPT PRIORITY ENCODER METH
OD AND APPARATUS (Attorney Docket SCM-073)」と題す
るLambの米国特許出願第743,691 号とに、入力／出力コ
ントローラと周辺デバイスのアダプタとのそれぞれの構
成要素として開示された型のマイクロプロセッサが好ま
しい。

【００４１】プロセッサ９２、９３及び９４は、「対等
物対等物（ピア−トゥ−ピア）」関係をもつ。このよう
に、主従関係とは対称的に、いずれのプロセッサも、入
力／出力コントローラの初期化中でなければ別（のプロ
セッサ）の動作を直接制御しない。同様に、各プロセッ
サ９２、９３及び９４は、他のプロセッサの速度と独立
した速度で動作する。

【００４２】図示したデータ転送システム５は、何れか
二つの機能ユニット間で情報を転送する。これらは、例
えばホストプロセッサ４０か、周辺デバイス５０か、あ
るいは追加的な論理機能ユニット、例えば入力／出力コ
ントローラ１０内の「接続管理装置」かでよい。これら
の転送は、インタフェース８０及び９０でのメッセージ
の交換を介して行なわれる。これらの転送は、入力／出
力コントローラ１０によって割り当てられる「仮想チャ
ンネル」を介して起こる。交換されるメッセージは、メ
ッセージ記述子ブロック（ＭＤＢ）によって記述され
る。

【００４３】図示した実施例において、記述子ブロック
を指すポインタはＭＤＢ信号を表すのに使用される。Ｍ
ＤＢが、ＭＤＢを発生するデバイス内のメモリのセグメ
ント内あるいはバッファ内に備わっていることは理解さ
れるだろう。かくして、ホストプロセッサ４０によって
発生されるＭＤＢは、例えばメモリ４３内の領域を指
す。同様に、周辺デバイス５０によって発生されるＭＤ
Ｂは、例えばメモリ５３の領域あるいはデバイス５０に
対して局部のバッファを指す。各機能ユニット４０及び
５０は、それ自身のＭＤＢを初期化して割り当てる。

【００４４】局部記憶装置においてデータの転送される
べき転送先あるいは転送もとの指示に加えて、ＭＤＢは
さらにデータ転送と関連づけられた情報を含んでいる。
例えば、以下で説明するように、ＭＤＢは、転送が完了
したとき実行されるべきソフトウエアのルーチン−−
「コールバックルーチン」−−を指示する。使用者の自
由で、これもまた、大きなデータの構造体内に埋め込む
ことができ、続いて、そのコールバックルーチンに関係
のあるデータを含んでいるが、データ転送機構に関係の
ないデータは含んでいない。

【００４５】動作動作における概観として、ホストデバイス４０は、ＭＤ
Ｂ４２Ｓを発生してコマンドＦＩＦＯ１５へ転送する。
黒塗りの円と矢による記号で表されるＭＤＢ４２Ｓは、
メモリ４３から転送されるべきデータの記述（すなわ
ち、アドレスと長さ）と、ＭＤＢが送られるべき仮想チ
ャンネル番号と、転送が完了したときに呼び出されるべ
き「コールバック」ルーチンのアドレスとを含んでい
る。

【００４６】周辺デバイス５０は、同様に、バッファを
同定するＭＤＢ４２Ｒを発生してコマンドＦＩＦＯ２０
へ転送してホストデバイス４０からの入力データを受信
する。ＭＤＢ４２Ｒは、白塗り円と矢による記号で表さ
れる。ＭＤＢ４２Ｒは、また仮想チャンネルと、転送が
完了したときに実行されるべきコールバック手順とを同
定する。

【００４７】メッセージ送信機４１及び４９とメッセー
ジ受信機４２及び５１とコマンドＦＩＦＯ１５及び２０
とは、ソフトウエアにおいて実行されるのが好ましい。
コマンドＦＩＦＯ１５及び２０は、好ましくはメモリの
一部であるが、ハードウエアのＦＩＦＯであってもよ
い。

【００４８】遠隔手順コールを実施するために、対の送
信及び受信ＭＤＢは、同時に（あるいは「アトミック態
様（atomically）」）コマンドＦＩＦＯに置かれなけれ
ばならない。コマンドＦＩＦＯにＭＤＢを位置付けるラ
イブラリルーチンは、アトミック態様で位置付けられる
べきＭＤＢのリストを受け入れるだろう。

【００４９】図示した実施例において、コマンドＦＩＦ
Ｏは、オーバフローに対する連結リストに対して円形に
インデックスされる配列として実施される。オーバフロ
ーの事象において、「オーバフローブレット(overflow
bullet) 」と呼ばれる特殊なＭＤＢは、配列内に待機さ
せられる。この特殊なＭＤＢは、「違法」チャンネル番
号をもつ。配列が仮想チャンネル要素によって空にされ
ていた場合、オーバフローブレットは拒絶される。オー
バフローブレットは「拒絶した（rejected）」とマーク
されて戻り、そのコールバックはオーバフローリストを
無理にコマンドＦＩＦＯに提示させられる。したがっ
て、ＭＤＢをコマンドＦＩＦＯに提示するライブラリル
ーチンはコマンドＦＩＦＯ内に十分な記憶スペースがな
いためにブロック化しない。

【００５０】デバイス４０及び５０は、これらの各ＭＤ
ＢをコマンドＦＩＦＯ１５及び２０上に配置して、そし
て入力／出力コントローラ１０がコマンドＦＩＦＯ１５
及び２０から各ＭＤＢを取り出してこれらを仮想チャン
ネル要素２５へ転送する。そこから、これらは同一チャ
ンネル上で整合するＭＤＢを待って待機させられるかあ
るいは待機していたＭＤＢと整合されて一対としてデー
タ転送要素３０へ与えられる。

【００５１】ＭＤＢの４２Ｓ及び４２Ｒは、仮想チャン
ネル要素２５へ転送され、そして仮想チャンネル要素２
５は、類似の仮想チャンネル番号をもつ送信及び受信Ｍ
ＤＢを整合させる。一度、二つの同様に指示されたＭＤ
Ｂが受信されると、仮想チャンネル要素２５はデータ転
送要素へ信号を送ってデータ転送を開始する。詳述する
と、仮想チャンネル要素２５は、データ転送要素３０に
信号を送ってデータを送信ＤＭＡ内で指示されるアドレ
ス範囲から受信ＤＭＡ内で指示されるアドレス範囲へ転
送する。

【００５２】データ転送要素は、従来の直接メモリアク
セス（ＤＭＡ）の転送デバイスにすることができ、好ま
しくは、「I/O CONTROLLER APPARATUS AND METHOD FOR
TRANSFERRING DATA BETWEEN A HOST PROCESSOR AND MUL
TIPLE I/O UNITS (AttorneyDocket SCM-070) 」と題す
るLambの米国特許出願第743,992 号に開示されている型
のＤＭＡデバイスである。

【００５３】データ転送が完了すると、ＭＤＢ４２Ｓ及
び４２Ｒは、それらの各機能ユニットへ戻される。詳述
すると、ＭＤＢ４２Ｓは入力／出力コントローラ１０に
よってリターンＦＩＦＯ４４へ転送され、他方ＭＤＢ４
２ＲはリターンＦＩＦＯ５４へ転送される。

【００５４】さらに詳しく言うと、一度データ転送が完
了すると、リターン要素３５は整合したＭＤＢ４２Ｒお
よび４２Ｓをマークしてデータ転送の状態を反射する。
ＭＤＢは、対応する入力／出力コントローラのインタフ
ェース８０及び９０を介してホストデバイス４０及び周
辺デバイス５０の両方へ戻される。

【００５５】ホストデバイス４０と周辺デバイス５０の
両方の上に配置されるリターンＦＩＦＯ要素４４、５４
は、これらが入力／出力コントローラ１０から戻される
ようにＭＤＢを受信する。リターンＦＩＦＯ要素は、好
ましくは複数のリターンＦＩＦＯから構成される。これ
に関連して、ＦＩＦＯは、その後現実にはリングをソフ
トウエアで実行する。リターンＦＩＦＯは、好ましくは
割り込みリングか、ポーリングされたリングか、カスタ
ムのポーリングされたリングかのいずれかを含んでい
る。

【００５６】システムがリターンＦＩＦＯ（４４）の一
つをサービスする（「ＦＩＦＯをドレインする」とも呼
ばれる）場合、ＭＤＢはそのＦＩＦＯから取り除かれ
て、後のコールバック処理のために待機させられるか、
あるいは通常の場合には、コールバック要素（４５）が
直ちに呼ばれる。このコールバックルーチンは、追加的
な入力／出力を自由に提示するか、あるいはデータ構造
体を自由に処理するか、あるいはＭＤＢをフリー記憶装
置へ単に戻す。

【００５７】上記の例がホストから周辺デバイスへの単
一の方向での転送としてあるけれど、図示したシステム
は何れか二つの機能ユニット間での転送ができるという
ことは理解できるであろう。

【００５８】仮想チャンネル仮想チャンネルは、入力／出力コントローラ１０によっ
て作成され、そしてこの入力／出力コントローラ１０が
ホストプロセッサ４０あるいは周辺デバイス５０の要求
に基いて新規のチャンネルを割り当てて初期化する。こ
のチャンネルの作成は、この入力／出力プロセッサの
「接続管理装置」のサブセクションによって実行され
る。

【００５９】要求を発生する際に、リクエスタは、所望
チャンネル（例えば、読み出しあるいは書き込み）のの
方向を特定する。チャンネルを確立できると仮定する
と、入力／出力プロセッサ１０は、チャンネル番号を表
す整数をリクエスタへ戻す。図の実施例において、入力
／出力コントローラ１０は、次の内の何れか二つの間で
チャンネルを発生できる：ホストデバイス４０、周辺デ
バイス５０、入力／出力コントローラの接続管理装置。

【００６０】好ましくは、小さい番号のチャンネルは、
前もって割り当てた機能のために保留にされる。こうし
て、チャンネル０及び１は、システムレベル通信のため
に保留にされ；チャンネル２及び３は、常駐デバッガの
ために保留にされ；チャンネル４及び５は、「接続管理
装置」への通信のために保留にされ；チャンネル６及び
７は、ドライバ制御管理装置のために保留にされる。こ
れらの前もって定義したチャンネルは、コードがメッセ
ージの最大のブロックの大きさを定義する各チャンネル
をサービスして、信号ブロックメッセージを運ぶのが好
ましい。

【００６１】前もって定義したチャンネルに加えて、各
機能ユニットは、任意の数の追加的な単一方向のチャン
ネルの作成を要求できる。

【００６２】仮想チャンネルが一旦作成されると、機能
ユニット４０及び５０はチャンネルがフラッシュされる
か、クローズされるか、接続を断たれるかを要求でき
る。ＧＩＺＡエンジンのバックプレーン内に配置された
この接続管理装置は、これらの要求を実行する。チャン
ネルをフラッシュするプロセスは、要求デバイスへ通知
されたいくつかのＭＤＢを戻し、記憶装置要素１５及び
２０内に記憶されてまだ処理されていないいくつかのＭ
ＤＢを検索する。すでに対にされて転送するいくつかの
ＭＤＢは、それらの転送を完了して戻される。

【００６３】チャンネルのいずれかの側の機能ユニット
は、その側とそのチャンネルのその側だけをフラッシュ
できる。これは、システム使用者による入／出力アボー
トコマンドの結果として起こるかもしれない。これはま
たこのチャンネルのクロージングへの前置きとして起こ
るかもしれない。一旦フラッシュ要求が入／出力によっ
て受信されて処理されると、チャンネルは「フラッシン
グ（flushing）」とマークされ、転送されるいくつかの
ＭＤＢのペアは終了可能にされ、整合を待っているフラ
ッシング側からのいくつかのＭＤＢは「フラッシュした
（flushed ）」とマークされてそれらの機能ユニットへ
戻される。ファンダメンタルなデータ駆動プログラミン
グのルールは、フラッシュ動作中にも監視される：与え
られたチャンネルのいずれに対しても全てのＭＤＢはそ
れらが提示された命令で戻される。

【００６４】機能ユニットは、またチャンネルがクロー
ズされることを要求できる。この状態を要求すると、機
能ユニットはそれがＭＤＢをチャンネルへもう提示しな
いだろうことを示す。一つの機能ユニットがクローズさ
れたチャンネルの側を宣言する場合、入力／出力プロセ
ッサ１０は、その機能ユニットからのそのチャンネルに
対するＭＤＢをもう受け取らないだろう。両方の機能ユ
ニットがクローズされたチャンネルを宣言する場合、チ
ャンネルは後の再使用に対するチャンネルのフリープー
ルへ戻される。好ましい実施例において、コーリングデ
バイスは、前もってフラッシュされたチャンネルだけの
クローザーを要求する。

【００６５】接続されてないＭＤＢは、ホストデバイス
４０あるいは周辺デバイス５０の何れか一方から提示で
きるが、しかし、発行される場合、その整数のチャンネ
ル番号によって同定されるチャンネルに同時にチャンネ
ルの両側を無理にフラッシュしてクローズさせる。

【００６６】好ましいシーケンスにおいて、チャンネル
はチャンネルをクローズするあるいはチャンネルの接続
を断つ前にフラッシュされる。しかしながら、チャンネ
ルの使用はまた、例えば入／出力アボート要求の一部と
して通知されたＭＤＢを検索するために、フラッシュコ
ールを介して一時的に割り込みできる。ＭＤＢがいった
ん検索されると、システムドライバは、再開始ライブラ
リルーチンをアクセスすることによってスティルオープ
ンチャンネルを使用して再開できる。前の接続ルーチン
によって発生されるチャンネル番号は、提示されたＭＤ
Ｂを運んで記憶して再開する仮想チャンネル要素２５内
に位置付けられるチャンネルを同定する。

【００６７】図３は、多数のリターンＦＩＦＯもしくは
リングを含んでいる好ましいリターンＦＩＦＯ要素を示
している。

【００６８】ホストデバイス４０と周辺デバイス５０の
両方に含まれるリターンＦＩＦＯには種々のオプション
がある。その理由は、各デバイス４０、５０がリターン
ＦＩＦＯ要素４４、５４内に含まれる多数のリターンＦ
ＩＦＯをもつことを可能にするためである。リターンＦ
ＩＦＯは、（リングが前もって空であれば）ＭＤＢがリ
ング上に位置付けられるとき割り込みリングが割り込み
を報知するように設計されるからその機能ユニットを中
断してもしなくてもよい。中断しない場合、その後、こ
れは機能ユニット内のコードによってポーリングされね
ばならない。通常プロセッササイクルの期間でもっと効
率よいポーリングは、割り込みを処理することが必要と
されるオーバーヘッドに依存して待ち時間が少ない場合
もある。

【００６９】本発明の好ましい実施例は、カスタムポー
リングされたリングもしくはＦＩＦＯとポーリングされ
たリングもしくはＦＩＦＯとを使用する。通常ポーリン
グされないカスタムポーリングされたリングは、特殊な
環境であるかもしれない。例えば、カスタムポーリング
されたリングは、システムが停止されている間のデバッ
ガ状態にある間に試験プログラムに対してだけあるいは
ＣＰＵのＰＲＯＭによって使用されるかもしれない。ポ
ーリングされたリングは、しばしばメインループ内でも
しくはスケジュールコードにおいてシステムをポーリン
グする。

【００７０】図示した実施例をさらに完璧に理解するこ
とは、以下のセクションを参考にすることによって達成
できる。この中で、入力／出力コントローラ（もしく
は、入力／出力プロセッサ、ＩＯＰ）１０の好ましい図
示のデータ転送システム５は、用語「Giza」によって参
照される。

【００７１】入力出力コントローラ（GIZA）は、一つの
アドレススペースから別のスペースへデータのブロック
を転送する時（例えば、Ｉ／ＯアダプタＩＯＡ４８’か
らホスト４０のメインメモリ４３へデータを移動する
時）により効率よい入力／出力コントローラ１８’、２
０’のアーキテクチャを作るメッセージ・パッシング・
ファシリティである。

【００７２】この図示したシステムは、二つの機能ユニ
ットのメモリ間のデータを転送する。これは、二つの
「ハーフ・リクエスト」整合させることとこれらの半分
からの全転送リクエストを形成することとによってこの
転送を制御する。

【００７３】各ハーフ・リクエストは、メモリが転送中
に読み出しあるいは書き込まれるだろう機能ユニットに
よって発生される。従って、ハーフ・リクエストは、チ
ャンネル番号、転送方向（読み出しあるいは書き込み）
及び（さらに以下で記述する）リターンＦＩＦＯ番号の
ような制御パラメータとともにそれぞれのメモリ内の位
置を特定する。

【００７４】コントローラと各機能ユニットとの間は、
であり、上記のハーフ・リクエストを表すメッセージ記
述子ブロック（ＭＤＢ）のアドレスを転送するための二
つもしくはそれ以上のＦＩＦＯそれぞれはコントローラ
と各機能ユニットとの間にある。これらのＦＩＦＯは、
ＭＤＢ自身を転送するのではなくＭＤＢのアドレスを転
送する。簡潔のために、このテキストにおいて、ＭＤＢ
のポインタのＦＩＦＯ内の記憶装置は、これらのＦＩＦ
Ｏ内のＭＤＢ自身の記憶装置として参照できる。

【００７５】コントローラとその機能ユニットの各々と
の間のＦＩＦＯについて、一方は、コマンドＦＩＦＯと
呼ばれ、複数のＭＤＢを機能ユニットからコントローラ
へ運ぶ；もう一方はリターンＦＩＦＯと呼ばれ、複数の
ＭＤＢをコントローラから機能ユニットへ運び戻す。

【００７６】コントローラの動作本発明の技術を考察すると、図示した入力／出力コント
ローラ（そして、他の機能ユニット内の対応する機能）
がハードウエアあるいはソフトウエアにおいて実行でき
ることは理解されるだろう。さらに、コントローラ自身
は、単体ユニットもしくは通信媒体を介して結合される
記述したユニットの収集として実行できる。

【００７７】構わずに、コントローラは三つのステージ
を実行する。１．整合２．データ転送３．結果報告

【００７８】ハードウエアの実行は、これらのセクショ
ンに対して別々のプロセッサを持つことができる。これ
らのプロセッサは、自主的に走り、作業を待つことによ
って一つのセクションから次のセクションへの通信を行
う。ソフトウエアの実行は、単体のプロセッサを使用
し、プログラム制御の転送によって一つのセクションか
ら次のセクションへの通信を行う。

【００７９】ステージ１：整合時間のある点、コントローラは、これに結合された空で
ないコマンドＦＩＦＯからＭＤＢを取り除く。そのＭＤ
Ｂから、チャンネル番号は、抜き出された後、マッチテ
ーブルと呼ばれるメモリの配列へのインデックスとして
使用される。マッチテーブル内の各エントリは、次のこ
とを含む小さなデータ構造体である。

【００８０】好ましいソフトウエアの実施ＭＤＢのリストの先頭を指すポインタ。ＭＤＢのリスト
の後尾を指すポインタ。書き込み側のための機能ユニッ
トのデザインネータと、読み出し側のための機能ユニッ
トのデザインネータと、書き込み側での状態（閉鎖、開
放、フラッシング）と、読み出し側での状態（閉鎖、開
放、フラッシング）と、その側がリストの中に複数のＭ
ＤＢをもつインディケータと、を含む状態の情報。

【００８１】好ましいハードウエアの実施書き込み側のためのＭＤＢのリストの先頭を指すポイン
タ。書き込み側のためのＭＤＢのリストの後尾を指すポ
インタ。読み出し側のためのＭＤＢのリストの先頭を指
すポインタ。読み出し側のためのＭＤＢのリストの後尾
を指すポインタ。データ転送ユニットによって処理され
るべき整合をもつ別の整合テーブルエントリのインデッ
クス。書き込み側のための機能ユニットのデザインネー
タと、読み出し側のための機能ユニットのデザインネー
タと、書き込み側での状態（閉鎖、開放、フラッシン
グ）と、読み出し側での状態（閉鎖、開放、フラッシン
グ）と、その側がリストの中に複数のＭＤＢをもつイン
ディケータと、を含む状態の情報。

【００８２】好ましいマルチピース、説明したハードウエアの実施電流側のためのＭＤＢのリストの先頭を指すポインタ。
電流側のためのＭＤＢのリストの後尾を指すポインタ。
データ転送ユニットによって処理されるべき整合をもつ
別の整合テーブルエントリのインデックス。電流側のた
めの機能ユニットのデザインネータと、残りの側のため
の通信線路のデザイネータと、電流側での状態（閉鎖、
開放、フラッシング）と、残りの側での状態（閉鎖、開
放、）と、転送方向（電流側からの書き込み／電流側へ
の読み出し）と、を含む状態の情報。（電流側からの書き込みの場合）残りの側で待機される
ことを知られるＭＤＢの数の計数。（電流側への読み出しの場合）残りの側へ報告されるこ
とを必要とするＭＤＢの数の計数。

【００８３】ＭＤＢに対するチャンネル番号が違法（定
義した整合テーブルの範囲外）な場合、ＭＤＢはエラー
としてマークされてただちにステージ３、結果報告へ送
られる。さもなければ、このＭＤＢに対するエントリは
試験される。転送方向はＭＤＢから取り出され、整合テ
ーブルエントリの適当なフィールドは試験されてそのチ
ャンネルがその転送方向に対して開放であるかどうかを
決定する。

【００８４】チャンネルが閉鎖の場合、ＭＤＢは、エラ
ー状態であり、ただちにステージ３へ送られる。チャン
ネルがフラッシングの場合、ＭＤＢは「フラッシュされ
た（flushed ）」とマークされて直ちにステージ２へ送
られる。ステージ２では、ＭＤＢはデータ転送を行わず
にそのチャンネルから進歩もしくは依存におけるいくつ
かの転送の後ろで現実に待つ。（コントローラは、プロ
セスを通じていずれかの現存のチャンネルに対するＭＤ
Ｂの命令を保存することを約束する。そのため、ＭＤＢ
は、これらがコマンドＦＩＦＯ上に達する同一命令で選
択したリターンＦＩＦＯを介して戻される。）

【００８５】ＭＤＢがこれらの試験を合格する場合、整
合テーブルエントリは試験されて、適当に連結リスト上
で待機させられるこの側からすでにＭＤＢがあるかどう
かを決定する。もしあれば、このＭＤＢは、（標準的な
単一のスレッド連結リストの方法を使用する）そのリス
トの最後に追加されて、そしてこのＭＤＢのこのステー
ジの処理は終了した。

【００８６】この側にすでに待機させられているＭＤＢ
がない場合、整合テーブルは試験されて他の側のために
待機させられている複数のＭＤＢがあるかどうかを決定
する。もしあれば、このＭＤＢと他の側に待機させられ
ている第一ＭＤＢとは、整合を構成する。これらの内の
二つは、ステージ２（つまり、データ転送）に待機させ
られ、そしてこのステージのこのＭＤＢの処理は終了し
た。

【００８７】いずれかの側に待機されているＭＤＢがな
い場合、このＭＤＢはこっちの側に待機されそしてこの
ＭＤＢのこのステージの処理が終了した。

【００８８】実施が分散される場合（マルチプル−ピー
ス）、その後いつ受信ＭＤＢがチャンネル上で待機され
ても、それについての情報（少なくともそのチャンネル
番号）は、コントローラの適当な他のピースへのメッセ
ージ（整合テーブルを更新する際に使用するメッセー
ジ）として記録される。このようなテーブルは、直ちに
送ることができるか、あるいは、好ましい実施において
は、タイマーが数えだすあるいは更新メッセージが完全
になって送られねばならなくなるまでバッチされる。い
つ送信ＭＤＢが他の側の受信ＭＤＢのノン−ゼロ計数で
一致されても、それは他の側への転送を制御するのに待
機させられる。この転送はＭＤＢによって記述されるメ
ッセージであり、チャンネル番号で前置きされる。いつ
メッセージが他の側から受信されても、この前置きチャ
ンネル番号が最初に受信され、第一受信ＭＤＢはそのチ
ャンネル番号によって示される整合テーブルエントリか
ら取り出されて入力メッセージを記憶するところを制御
するのに使用される。

【００８９】ステージ２：データ転送フラッシュされたＭＤＢを除いて−−実転送の後ろの線
路で単に待機している−−コントローラのデータ転送ス
テージはオーダーしたリストもしくはＦＩＦＯ内の整合
されたペアのＭＤＢを受信する。別の転送を行なう時間
が来ると、リストの先頭のペアは比較されて読み出しＭ
ＤＢの中に示されるメモリの量が書き込みＭＤＢの中に
あるのと少なくとも同量あるかどうかを決定する。もし
そうでない場合には、オバーフローエラーとなりＭＤＢ
はエラーと表示されて転送は実行されない。（分散され
る場合において、この異常なエラーは、転送を初期化し
て、交渉を待機して両方の実施は可能であるがルームが
あるかどうかを決定するのでなく受信エンドでのオーバ
ーフロービットを捨てることによって最前に扱われ
る。）書き込まれる全てを受信するルームがある場合、
転送が実行される。ステージ２の完了において、正常か
異常かのどちらか、ペアのＭＤＢ（あるいは単一のフラ
ッシュされたＭＤＢ）は、ステージ３（結果報告）に沿
って送られる。

【００９０】ステージ３：結果報告データ転送が完了すると、転送の前あるいはその最中に
検出されたいくつかのエラーが両方のＭＤＢにおいて注
釈される。エラーがない場合、それも注釈され、さら
に、少なくとも受信ＭＤＢは現実に書き込まれたデータ
の長さをその中に記録される（メッセージを受信するバ
ッファの長さを特定するフィールドの横側）。（図示し
た実施例において、両方のＭＤＢは移動される実長さを
受信する。）

【００９１】受信したこの状態情報をもつＭＤＢは、Ｍ
ＤＢ内に示されるリターンＦＩＦＯへ戻って書き込まれ
る。このようなリターンＦＩＦＯがない場合、その機能
ユニットに対するＦＩＦＯ番号０が使用される。そのＦ
ＩＦＯは常に存在していなければならない。選択したリ
ターンＦＩＦＯが満杯である場合、そのＦＩＦＯと関連
づけられるＭＤＢの連結リストがオーバーフローのＭＤ
Ｂを保持するのに使用され、そしてＭＤＢは、スペース
が利用できるようになるようにそのリストからＦＩＦＯ
へ定期的に移動される。

【００９２】機能ユニットの動作各機能ユニットにおいて、データ転送を達成するために
二つの動作が実行されねばならない：１．ＭＤＢをコマンドＦＩＦＯに与えること２．リターンＦＩＦＯからＭＤＢをドレインすること

【００９３】ＭＤＢをコマンドＦＩＦＯに与えること図示した実施例では、各機能ユニットにおいて、各機能
ユニットをプログラムされたディジタルデータプロセッ
サであると仮想すると、ＭＤＢのリストを与えられる
「提示（submit）」と呼ばれるライブラリルーチンがあ
る。これらのＭＤＢはそれらのコマンドＦＩＦＯへ提示
されるべきである−すなわち、リストの中のＭＤＢは、
（何か他の提示動作からの）他のＭＤＢがリストの中間
にまき散らされずに、命令でコマンドＦＩＦＯの中に現
れなければならない。

【００９４】この技術に精通したものであれば、遠隔手
続呼び出しが一対のＭＤＢによって実行できるという
（一方はチャンネルへ書き込み他方は別のチャンネルか
ら読み出す、ここのこれら二つのチャンネルは要求を読
み出すための遠隔プロセスと返事を書き込むための遠隔
プロセスとによってそれぞれ使用される）ことに注目す
るだろう。二つのＲＰＣの要求（Ｗ１、Ｒ１）と（Ｗ
２、Ｒ２）が非アトミック態様で提示され、オーダリン
グ（Ｗ１、Ｗ２、Ｒ２、Ｒ１）は、コマンド１に対する
返事がリクエスタ番号２そしてその逆となる発生する。

【００９５】異なる機能ユニットは、異なる特性をも
つ。必要であれば、「提示」は、最小単位のコマンドＦ
ＩＦＯ提示を保存するために、割り込みレベルを不可能
にしロックをセットしなければならないかもしれない。

【００９６】コマンドＦＩＦＯは（ハードウエアの実行
にとって最善であるような）ＭＤＢのリストと、（ソフ
トウエアの実行にとって最善であるとみなされた）個々
のＭＤＢを運ぶことができる。前者の場合であれば、最
小単位がコントローラによって保証される。後者の場合
であれば、機能ユニット内の提示ルーチンによって保証
されねばならない。

【００９７】オーバーフローリストと呼ばれる各コマン
ドＦＩＦＯに関連づけられる連結リストが存在する。提
示ルーチンがコマンドＦＩＦＯがほとんど満杯であると
いうことを発見する場合（現在、これがひとつ以上のＭ
ＤＢをもつとき）、あるいはオーバーフローリストが空
でない場合、提示されたＭＤＢはオーバーフローリスト
の最後に位置付けられる。オーバーフローリストが開始
されると、特別のＭＤＢ（オーバフロートレーサーと呼
ばれる）は、提示されたＭＤＢの代わりにコマンドＦＩ
ＦＯ上に位置付けられる。このオーバーフロートレーサ
は、チャンネル番号が違法となるＭＤＢである（その結
果、コントローラによって直ちに拒絶される）。これ
は、全てのオーバーフローリストを取り出しこれを提示
する（以下に記述する）コールバックルーチンをもつ。
オーバーフローリストと共にコマンドＦＩＦＯは完全に
できないＭＤＢに対して待機機構を提供する。したがっ
て、提示ルーチンはルームを待機することをブロックし
てはならない。

【００９８】リターンＦＩＦＯからＭＤＢをドレインすること異なるリターンＦＩＦＯは、機能ユニットのコードで異
なった位置でドレインされる。その理由は、設計におい
て考慮に入れられる多数のリターンＦＩＦＯが存在する
からである。あるものがドレインされるべき必要がある
各々の位置について一つ存在する。例えば、割り込みレ
ベルにおいてポリングループ（所望されるＸのそれぞれ
の数値に対して異なったＦＩＦＯあらゆるＸ秒）におい
ていくつかのプロセスからポリングされるシステムのレ
ストの正常な動作を中断したデバッガからポリングされ
るドレインされるべきＦＩＦＯの場合がある。

【００９９】好ましい実施では、このようなＦＩＦＯの
要求が六つより少なくてよいことがわかった。多数の機
能ユニットは一つのＦＩＦＯだけ必要であることがわか
った。

【０１００】各々の場合に、リターンＦＩＦＯは、「コ
ールバック」と呼ばれるルーチンのアドレスをそのＭＤ
Ｂから移動しこのルーチンを呼び出して唯一の引き数と
してＭＤＢを指すポインタを与え、ＦＩＦＯの先頭から
一つのＭＤＢを指すポインタを繰り返し移動させること
によってドレインされる。

【０１０１】制限コントローラあるいはそのＦＩＦＯ内の記憶を待機しな
がら、このプロセスのノープレイス（no place）でブロ
ックしている。こうして、コントローラによって処理さ
れるいずれか一つのチャンネルもしくは全セットのチャ
ンネルを待機することができるＭＤＢの数に関する制限
はない（メモリの素のセクションを異なるＭＤＢとそれ
らが記述されるメッセージとに割り当てる必要によって
課せられる制限を除いて）。

【０１０２】チャンネルの数に関して制限がある。これ
は、整合テーブルの大きさによって制限される。整合テ
ーブルエントリは、チャンネルの数が図示した実施例に
よって出会わされた最高のケースにおいて必要とされる
数を容易に越えることができるということを十分小さ
い。整合テーブルが存在する更に多くのチャンネルを持
つことが必要となる場合、標準的な技術を使って単一の
仮想チャンネル以上の多数のサブチャンネルを多重送信
することが可能である。

【０１０３】Ｇｉｚａの範囲図４に示すように、Ｇｉｚａは四つの主要な構成要素を
含んでいる：Ｇｉｚａエンジン（データー・ムーバー）ＧｉｚａサポートルーチンＧｉｚａライブラリルーチン

【０１０４】Ｇｉｚａエンジンハードウエアにおいて実行できる図示されたＧｉｚａエ
ンジンは、ＩＯＰファームウエアの一部としてのソフト
ウエアにおいて実行される。これは、存在するＩＯＰ機
能の横で動作する。

【０１０５】ＧｉｚａサポートルーチンＧｉｚａサポートルーチンは、Ｇｉｚａサポートルーチ
ンがデータの通常の移動で働かないＧｉｚａエンジンと
別個のものである。これらは主に、結合管理、すなわ
ち、核（kernel）とＩＯＡ（もしくはＩ／Ｏコントロー
ラ）との間の開及び閉のＧｉｚａ結合を提供する。

【０１０６】Ｇｉｚａの核ライブラリルーチン核ライブラリは、動作システムの核プログラマーが以下
のことを可能にするプログラム化インターフェースであ
る：Ｇｉｚａ結合をセットアップするこれらの結合に亙
るデータの転送を行うことこれらの結合をブレイクする
ことこのインターフェースは、例えば、出願中に共に譲
渡された１９９１年６月２８日に出願された米国特許出
願第723,065 号と本発明の譲受人により市販されている
ＶＯＳ^TMオペレーティングシステムとに開示されたオペ
レーティングシステムと結合して使用するためのもので
ある。

【０１０７】ＧｉｚａのＩＯＡライブラリルーチンＩＯＡライブラリルーチンは、ＩＯＡプログラマに次の
ことを可能にさせるＩＯＡプログラム化インターフェイ
スである。Ｇｉｚａ結合をセットアップするこれらの結
合に亙るデータの転送を行うことこれらの結合をブレイ
クすること

【０１０８】Gizaの設計 Gizaは、データドリブンプログラミングの概念を使用す
る。データドゥリブンプログラミングは、自律プロセス
の集合体を包含しており、そのプロセスの各集合体はそ
れ自体の機能ユニット（ここで使用されるように、機能
ユニットは例えば独立のプロセッサとし得る）により支
配される。機能ユニットは、一般に、対等物対対等物の
関係を有しており、いずれも他の従属体に対する主体
（マスタ）ではない。各機能ユニットは、他の機能ユニ
ットと独立の速度で動作する。一つが休止したりスピー
ドアップした場合、それはシステム動作の適正性に影響
を及ぼさない。

【０１０９】決定論的結果を補償するため、すなわち所
与の入力がタイミングの如何に拘りなく同じ出力を生ず
ることを補償するために、特定のルールがデータドリブ
ンプログラミングを支配している。かくして、Gizaは、
タイミングバグにより傷つけられないようにこれらのル
ールを使用して設計された。詳述すると、これらのルー
ルとしては下記のものが含まれる。すなわち、１．ＭＤＢは、一度提示されると、撤回することができ
ず、変更されるべきでない。２．任意の単一のチャンネル上の全ＭＤＢは、データ転
送およびコールバック処理中とも、それらが提示された
のと同じ順序で処理される。これは、フラッシュ、クロ
ーズおよび切断のような異状の場合を含む。３．ＭＤＢに対するタイムアウトはない（何故ならば、
これは提示されたＭＤＢの撤回に等しいからである）

【０１１０】Gizaを使用するドライバは、データドリブ
ンプログラミングに従うことを必要としないことに注意
されたい。むしろ、Gizaを使用するドライバは、これら
のルールに従いかつシステムにより提示される機械がル
ールを保っていることを知ることを許容せしめられる。

【０１１１】Gizaエンジンはまた、他のデータ転送シス
テムに優る一群の利点をもたらす。これらの利点の二三
のものを以下に掲げる。

【０１１２】以下、Giza機構の数種の長所について記述
する。〇機能ユニットの対等物対対等物の等価性 GizaはＩＯＡプロセッサおよびホストシステムに対して
同じ視野に立つ通信を提示する。インターフェースは両
側とも本質的に同じである。（ただし、ホストコンピュ
ータ４０は、普通、接続管理に責任を取ることに留意さ
れたい）。〇アドレススペース保護。 Gizaはデータを一つのアドレススペースから他のアドレ
ススペースへ転送する。このプロセスにおいては、Giza
およびそのＤＭＡのみが両アドレスを知る。通信してい
るパートナーのいずれも、他のパートナーのスペースの
アドレスを知らない。かくして、いずれのパートナーも
偶発的に他のスペースにアドレスできない。〇タイミングの非被害性 Gizaはデータドリブンプログラミングを支配するルール
にしたがって設計されているから、タイミングバグによ
り害を受けない。Giza動作に対する競争状態はなく、機
能ユニット速度に問題を引き起こすような変化を生じさ
せる機会もない。各機能ユニットは、例えば独立に作用
する。〇直接的割込みの指令 Gizaは、開発者に対して、送信または受信される各メッ
セージに使用されるべき割込み処理手続きを特定する能
力を提示する。この割込みルーチンは、判断トリーを横
切ることを要せずに直接請求される。〇グラウンドレベル割込みバッチ処理 Gizaは、開発者に、例えばスケジューラがランすると
き、またはストリームスサービスルーチンがランすると
き、割込みをグラウンドレベルでバッチで到来せしめる
ことについての選択を与える。これは、グラウンドレベ
ルでなされるべき仕事に単に待ち行列を作る割込みコー
ドのオーバーヘッドを排除する。

【０１１３】［Gizaメッセージの梗概］Giza メッセー
ジを送信および受信するための手続きは、一つの機能ユ
ニットに、処理のため他側に送信されるべきデータを用
意すべきことを、また他側に必要に応じてデータを受信
し処理するように用意すべきことを要求する。データ
は、Gizaメッセージの一部として、二つの機能ユニット
間を番号付きGizaチャンネルを介して通される。

【０１１４】メッセージ路図２は、Gizaメッセージ路を示している。例示の実施例
は、メッセージを送信および受信するためソフトウェア
リングを使用する。ＭＤＢは、命令（すなわちto Giza
）FIFO１５，２０によりGizaに提示され、応答（すな
わちfrom Giza ）リング上で帰還受信される。各側は、
多数の応答リングを有してよいが、命令リングは唯一つ
である。データを送信する側は、データに対するポイン
タを含むＭＤＢをその命令リングに送り、受信側は、バ
ッファに対するポインタを特定するＭＤＢをその命令リ
ングに送る。

【０１１５】メッセージ通信は、番号付きチャンネルを
介して行なわれる。これらのチャンネル番号は、個々の
Gizaエンジンのみに適用される。メッセージまたはバッ
ファに対するＭＤＢがGizaに提示されるとき、ＭＤＢは
そのことが意図されるチャンネル番号を含む。MDB をGi
zaに提示するライブラリーコール(giza submit()) は特
定のGizaエンジンを含むバックプレインスロットの番号
が与えられる。各Gizaエンジン上の低番号付きチャンネ
ル（ここでは、チャンネル１ないし７）は、予め割り当
てられた機能に対して逆転される。また、特定のGizaエ
ンジンと関連する各I/O アダプタカードは、逆転された
予定されたチャンネルを有する（ここでは、チャンネル
８ないし１１９）。

【０１１６】メッセージ供給プロセスの一般的記述メッセージが、５つの別個の段階で一つの機能ユニット
から他の機能ユニットに供給される。１．機能ユニットＡが、出メッセージについて記述しか
つすでに開かれたチャンネルを特定するＭＤＢをGizaに
供給する。２．機能ユニットＢは、メッセージを受信するためのバ
ッファを記述しかつ機能ユニットＡと同じチャンネルを
特定するＭＤＢをGizaに提示する。注：最初の２つの段階は、いずれの順序でも起こり得
る。また、両側に複数のエントリを作り、それらがパー
トナーＭＤＢが現われるまで待行列化されるすることも
できる。３．両機能ユニットがＭＤＢを供給してしまうと、Giza
はＡからＢへデータ転送を遂行し、各ＭＤＢに完了状態
を記す。４．機能ユニットＡは、Gizaから戻るそのＭＤＢを受信
し、メッセージが特定のチャンネルを介してうまく転送
されたことを確認する。５．機能ユニットＢは、メッセージが特定のチャンネル
を介してうまく到着したことの確認で、Gizaから帰るそ
のＭＤＢを受信する。

【０１１７】Gizaメッセージ供給の概念的基準 Gizaメッセージを利用するI/O ドライバは、ここでI/O
デバイスを遠隔サブルーチンまたはパイプラインとして
想像できる。

【０１１８】図５、６および７は、遠隔サブルーチンモ
デルを示しており、I/O ドライバは、そのパートナーに
メッセージを送り、応答を得て、処理を継続する（サブ
ルーチンからの復帰であるかのように）。

【０１１９】図８は、パイプライン化を許容するモデル
である。パイプラインモデルにおいては、I/O ドライバ
コード送信メッセージ部分は、例えば、エンジンにメッ
セージを提示する。しかし、その後応答を待つ必要はな
く、何か他のことを行い続ける（例えば、他のメッセー
ジをエンジンに提示する）。

【０１２０】Gizaは、パイプラインモデルに基づく、す
なわち、Gizaエンジンは、パイプライン内の１ブロック
と見ることができる。GizaはＭＤＢを取り、それらを保
持し（他の機能ユニットからの整合するＭＤＢが存在す
るまで）あるいはそれらを整合するＭＤＢと対にし、転
送を行なう。究極的に、Gizaエンジンは、ＭＤＢを、ド
ライバコードの最初の部分と恐らく関係のないドライバ
ーコードの他の部分に戻す（例えば、受信コードは、単
にＭＤＢおよびバッファをそのドライバに対するフリー
プールに戻してもよかろう）。同様に、受信側では、Gi
zaにＭＤＢを与えるコードは、単に解放されたバッファ
を取り扱うに過ぎない。充填されたバッファを受信す
るコードは、新しいメッセージを、それらを担持するた
めに提供されたバッファについて懸念することなく、新
しいメッセージとして処理できる。メッセージ記述子ブ
ロックは、ホストデバイス、周辺デバイスおよびGiza間
において転送される信号を表わす。それらの構造は重要
であり、以下の如くである。

【０１２１】Gizaメッセージ記述子ブロック Gizaはメッセージ記述子ブロック(MDB) を採用するが、
これは下記の情報をGizaに提供する構造である。すなわ
ち、〇送信側では、メッセージの記述、受信側では、メッセ
ージを受信するバッファの記述。〇制御情報、例えばGizaチャンネル番号。〇状態情報、例えば実際に転送されるバイト数。〇割込み指示（ベクトング）、コールバックルーチンア
ドレスの形式。

【０１２２】ＭＤＢは、Gizaに対する単なる一組のパラ
メータではない。一度Gizaに提示されるとGizaエンジン
の性質となり、それが戻されるまで（完了またはチャン
ネルフラッシュの際）その性質を留めるメモリブロック
である。１より多いＭＤＢを提示すると、Gizaエンジン
はＭＤＢ中の筋道をランし、各仮想チャンネルに対する
連結リストにおいてそれらを待ち行列化する。

【０１２３】基本のＭＢＤは一つのブロックと一つのセ
グメントを有するが、開発者は、所望に応じてメッセー
ジのデータ部分を構成し得る。例えば、各々異なる長さ
を有し、各々複数のセグメントより成る複数の（マル
チ）ブロックを有するように（拡散−収集ＤＭＡ動作の
ため）。

【０１２４】他の方法に比して、マルチブロックメッセ
ージは、特定の問題を処理する実現可能な方法である。
例えば、ホスト側は、ディスクに4096バイトページのデ
ータを書き込むことを望むものと仮定する。データを核
からＩＯＡに移すため、ホスト側は、２つの単一セグメ
ントブロック（書込み命令に対して一つの16バイトブロ
ック、およびデータに対して一つの4096バイトブロッ
ク）を有するＭＤＢを提示する。

【０１２５】ＩＯＡは、どの程度のバイトが到来してい
るかを知ることはできないから、２ブロックを有するバ
ッファを記述するＭＤＢを提示し（命令に対して一つの
128バイトブロックおよび二つの2048バイトセグメント
を有する第２のブロック）到着するデータを保持する。

【０１２６】ホスト側から到来する命令部分は単に16バ
イトブロックのデータに過ぎないから、ＩＯＡ側におい
ては、単に16バイトしか128 バイトバッファに挿入され
ない。残りは未使用のままの残り、4096バイトのデータ
が二つの2048バイトセグメントを満たす。

【０１２７】例示の具体例において、ＭＤＢは、ヘッ
ダ、ブロックヘッダ、セグメントヘッダ、フィールド記
述子およびデータバッファより成る。下記は、これらの
要素をさらに詳細に記述するものである。ＭＤＢの構成例示の実施例において、ＭＤＢは、ヘッダ(sys mdb hea
der またはioa mdb-header) 、１または複数のブロック
ヘッダ（block header) 、および各ブロックに対する１
または複数のセグメントヘッダ(sys block segmentまた
はioa block segment ）。

【０１２８】ＭＤＢヘッダフィールド例示の実施例において、ＭＤＢヘッダは、GIZAのホスト
およびＩＯＡ側間において異なる。これは、物理的ポイ
ンタがこれらの２機能ユニット間において異なるサイズ
より成ることにもよる。

【０１２９】下記は、ホスト側のＭＤＢヘッダを示す
（データ構造を記述するためＣプログラミング言語フォ
ーマットを使用）。

【表１】 typedef struct LONGMAP sys mdb header { void (*callback)(struct sys mdb header *mdbp); struct sys mdb header *salvage list fp; struct sys mdb header *salvage list bp; struct sys mdb header virt next link; sys phys ptr phys next link; long MDB length; /* For Tarl's FDDI */ channel number channel ID; struct sys mdb header *return ring item; /* this MDB */ giza msg status template message status; giza control template control; unsigned char return ring index; /* choice of ring */ unsigned char number of block; } sys mdb header;

【０１３０】下記はＩＯＡ側ＭＤＢヘッダを示す。

【表２】 typedef PACKED struct SHORTMAP ioa mdb header { void (*callback)(struct ioa mdb header *mdbp); ioa phys ptr phys next link; struct ioa mdb header *return ring item; /* this MDB */ channel number channel ID; giza msg status template message status; giza control template control; unsigned char return ring index; /* choice of ring */ unsigned char number of blocks; } ioa mdb header;

【０１３１】ＭＤＢをGizaに提示すると、発呼者は下記
のヘッダ情報を提供する。

【表３】○callback ○virt next link（１より多いＭＤＢを提示する場合） ○MDB length ○channel ID ○control ○return ring index ○number of blocks

【０１３２】Giza エンジンはmessage statusフィール
ドを充填する。フィールドの記述 Callback データが転送された後にＭＤＢが戻るとき呼ばれるルー
チンのアドレス。 virt next link １以上のＭＤＢを提示する場合の次のＭＤＢの仮想アド
レス。そうでない場合はNull。 MDB length ホスト側における全ＭＤＢのバイト長さ。これは、ＭＤ
Ｂヘッダならびにブロックおよびセグメントヘッダを含
む。 channel ID ＭＤＢが送られるGizaチャンネル番号。 control 下記はＭＤＢヘッダコントロールフィールドに対する値
である。 #define RECEIVE 0x00/*Receiv/ MDB */ #define SEND 0x01 /* Send MDB */ return ring index このＭＤＢが戻る応答リングのインデックス number of blocks ブロックヘッダの数。 message status Gizaエンジンはこのフィルタを充たす。可能な値は下記
に示される。

【０１３３】/* メッセージ状態に対する値 */

【表４】 #define GOOD DMA 0; #define FLUSHED 1; /* ＭＤＢフラッシュ */ #define BLOCK ERROR 2; /* ブロック数誤り */ #define INVALID CHANNEL 3; #define DEAD IOA 4; #define DEAD IOP 5; #define PER BLOCK ERROR 6; /* block header's status 参照 */ #define ILLEAGAL INTERNAL STATE -1;

【０１３４】ブロックヘッダフィールドブロックヘッダは物理的ポインタを全然もたず、それゆ
えホストおよびＩＯＡ側とも同じである。下記はブロッ
クヘッダの構造を示す。

【表５】

【０１３５】発呼者は、ＭＤＢに対して下記のブロック
ヘッダ情報を提供する。 ○status ○block control ○number segments

【０１３６】エンジンは、もし使用されていればblock
checksumを累積する。フィールドの記述 block header.status ブロック状態フィールドに対する値は下記に示される。

【表６】 typedef unsigned char giza blk status template; #define giza blk status template error 0x80 #define giza blk status template verify error 0x40 #define giza blk status template parity error 0x20 #define giza blk status template checksum error 0x10 #define giza blk status template overrun 0x08 #define giza blk status template crossed page boundary 0x04

【０１３７】block header.block control ブロック制御フィールドに対する値は下記に示される。

【表７】 #define giza block control template cache consistent 0x80 #define giza block control template append checksum 0x40 #define giza block control template check checksum 0x20 #define giza block control template gen checksum 0x10 注：ソース（書込み側）は３つ存在するchecksum方法を
定める。すなわち ○append checksum ○check checksum ○gen checksum

【０１３８】append checksum の場合、受信装置は、送
信装置からappended checksum を有するデータを得るこ
とを予期する。そうでなければ、checksumエラーが発生
される。

【０１３９】check checksum 選択の場合、ソースは、
両側に対してデータブロックの終了にてchecksumを提供
する。二つのＭＤＢがなおエンジン内にある間に、エン
ジンは両checksumが整合することを保証する。もしそう
でなければ、checksumエラーが発生される。

【０１４０】gen checksum法は、この時点においては使
用されない。 block header.number segments セグメントヘッダの番号。 block header.block checksum checksumが使用される場合、これは０でなければなら
ぬ。

【０１４１】セグメントヘッダフィールドセグメント記述子は、ホスト側およびＩＯＡ側において
異なる。これは物理的なアドレス長が異なるからであ
る。下記はホスト側セグメント記述子を示す。

【表８】

【０１４２】下記はＩＯＡ側セグメント記述子を示す。

【表９】

【０１４３】発呼者はセグメントヘッダに対して下記の
情報を提供する。 ○sys block segment.address ○sys block segment.seg length

【０１４４】Gizaエンジンは下記を充たす。すなわち、 sys block segment.length moved( またはioa block se
gment.length moved).フィールドの記述 sys block segment.address データバッファの物理的アドレス。 sys block segment.seg length データのバイト長。 sys block segment.length moved 実際に移動されるデータのバイト長。

【０１４５】下記は潜在的システム使用者により開発さ
れるようなサンプルＭＤＢを表わす。サンプルＭＤＢ下記はサンプルＭＤＢを示す。

【表１０】 typedef struct /* 1 ブロックのHost側ＭＤＢ，１セグメント */ { sys mdb header hdr; block header blk; sys block segmen seg; } sys mdb 11; typedef strut /* 1ブロックのIOA 側ＭＤＢ，２セグメント */ { ioa mdb header hdr; block header blk; sys block segmen seg[2]; } sys mdb 12;

【０１４６】例示の実施例において、機能ユニット内の
コードは、ＭＤＢをGizaに提示する。これは、ＭＤＢお
よびその記述されるメッセージの（を変更する許可の）
所有権が、取り決めにより、機能ユニットからGizaデバ
イス与えられることを意味する。GizaはこれらのＭＤＢ
を使用して、メッセージの転送を制御し、そしてこの転
送の完了の際、ＭＤＢの所有権をそれを提示した機能ユ
ニットに戻す。その機能ユニットは、ついでGizaからか
かるＭＤＢを回収する。下記は、これらの提示および回
収走査と関連するライブラリルーチンおよびデータ構造
を表わす。

【０１４７】ＭＤＢを提示、回収するためのライブラリルーチン以下の節は下記に対するGizaインターフェースについて
簡単に記述する。すなわち、 ○GizaにＭＤＢを提示するためのもの。 ○GizaからＭＤＦを回収するためのもの。

【０１４８】ＭＤＢにGizaを提示するためのライブラリルーチン Gizaは一つのライブラリルーチン、giza submit を有し
ており、そしてこれはto giza リングを経て単一のＭＤ
ＢまたはＭＤＢのリストをGizaエンジンに提示すること
を可能にする。

【０１４９】複数機能ユニットが同時点にこの呼びをな
そうとすると、to giza リングはまずロックされる。つ
いで、提示中の機能ユニットがアドレス対応を有する
と、各ＭＤＢに対する物理的アドレスが計算され、to g
iza リングがＭＤＢの全非破壊リストを受け取る。Giza
は、ＭＤＢを順に、すなわちリストの頂部から底部間で
処理し、ここでvirt next リンクはNullとなる。Gizaエ
ンジンは使用される仮想の次のポインタの間に書き込む
ことができるから、このリストは一次的である。

【０１５０】GizaからＭＤＢを回収するためのライブラ
リルーチンおよびマクロス Gizaライブラリは応答リングをチェックしＭＤＢを回収
するための多数のルーチンを有する。すなわち、

【表１１】○giza drain response ring ○giza drain reject list ○giza prep scan ○giza drain array ○giza drain test

【０１５１】giza drain response ringライブラリルー
チンは、ＭＤＢの指示された応答リングを空にし、それ
らの各々に対しコールバックエントリを呼ぶ。

【０１５２】Giza drain reject listは、それがgiza s
ubmit が拒絶するＭＤＢを回収することを除き、giza d
rain response ringと同様である。何故ならば、これら
は重要なフォーマットだからである。

【０１５３】Giza prep scanライブラリルーチンは、周
期的に呼ばれ、アクティブ応答リングに対してポインタ
配列を更新する。ついで、その配列は、giza drain arr
ayマクロを使用して走査して、任意のＭＤＢを放出で
き、あるいはgiza drain test マクロを使用して走査し
て、応答レスポンスリングが任意の未解決のＭＤＢを有
するか否かを試験できる。

【０１５４】ライブラリルーチン呼びシーケンス下記の節は、Gizaメッセージ供給に対するライブラリル
ーチンを記述するものである。ルーチンはアルファベッ
ト順にリストしてある。

【０１５５】short giza prep scan(long rnum, sys gi
za command ring control **rrcpp) 記述 giza prep scan() ライブラリルーチンは、周期的に呼
ばれ、アクティブな応答リングに対するポインタ配列を
更新する。この配列は、ついで、giza drain arrayまた
はgiza drain test macrosを使用して走査できる。rnum
はリング番号である。 rrcpp は、giza prep scan()
により充填されるべきリングポインタ配列である。機能
復帰は、配列rrcpp に見出され装入されているリングの
番号である。

【０１５６】void giza drain reject list(void)記述 giza drain reject list()ライブラリルーチンは、giza
submit が拒絶するＭＤＢを回収する。それらは適正に
ホーマットされていないからである。ホスト側では、こ
れは、未解決の復帰をチェックするため種々の場所、す
なわちスケジューラ、割り込みルーチン、Qrun等から呼
ばれる。

【０１５７】void giza drain response ring(sys giza
response ring control *ringp);記述 giza drain response ring()ライブラリルーチンは、Ｍ
ＤＢの指示された応答リングを空にし、それらの各々に
対するコールバックエントリを呼ぶ。普通、これはgiza
drain array macroからのみ呼ばれる。

【０１５８】コメント設計により、Giza応答リングは「ロック」される、すな
わちマルチプルＣＰＵシステムにおいては、もし一つの
ＣＰＵがロックされたリングからＭＤＢを除去すること
を開始すると、ＣＰＵは、リングが空になるまで全ＭＤ
Ｂを除去する。これは、ＭＤＢの逐次の除去およびコー
ルバックの逐次の処理を保証する。

【０１５９】もしもＭＤＢ処理の順序が重要でなければ
（例えば、コールバックがＭＤＢを山に戻すに過ぎなけ
れば）応答リングはフラグunlocked callback==1を有し
てよい。この選択の場合、リング上のロックはコールバ
ック中解放され、複数機能ユニットにより同時にアンロ
ーディングすることを可能にする。このオプションは、
メッセージ順序が重要でない場合コールバックのために
使用される。

【０１６０】void giza submit /sys mdb header *mdb
p);記述 giza submit() ライブラリルーチンは、ＭＤＢを命令(t
o giza) リングに提示する。この呼びをなしつつあるよ
うな複数の機能ユニットがあると、命令(to giza) リン
グがまずロックされる。ついで、提示中の機能ユニット
がアドレス対応を有すると、各ＭＤＢに対する物理的ア
ドレスが計算される。第１のＭＤＢはto giza リング上
におかれ、後続のＭＤＢは１時に一つずつそのリングに
追加される。

【０１６１】コメントＭＤＢのリストをgiza submit に提示するためには、Ｍ
ＤＢは、それらを所与のＭＤＢの仮想の次のポインタ(m
dbp->virt next link)に渡すことによって提示される。
ＭＤＢは順に、すなわちリストの頂部(mdbp)から底部に
向かって処理され、そしてここでvirt next linkはNULL
となる。このリストは、一次的と仮定されるべきであ
る。Gizaエンジンは、使用される仮想の次のポインタの
間に書き込んでも書き込まなくてもよい。

【０１６２】ホストデバイスおよび周辺デバイス(IOA)
の両者は、ＭＤＢをgiza submit を経てGizaに提示す
る。

【０１６３】命令リング各Gizaエンジンに対して一つのto giza リングがある。
to giza リングは、機能ユニットがGizaエンジンに渡す
ＭＤＢを保持する。Gizaエンジンは、ＭＤＢヲ受け取る
順序で処理する。

【０１６４】ＭＤＢがGizaにより受け取られるとき、コ
ントローラは、ＭＤＢを同じ整数のチャンネル番号と整
合させようとする。下記の論述は、図２の仮想チャンネ
ル要素に関係する。

【０１６５】Gizaチャンネル番号例示の実施例において、Gizaチャンネル番号は32ビット
整数である。高次の８ビットは、使用されるGizaエンジ
ン（すなわちＩＯＰバックパネルスロット）を特定して
いる。残りの２４ビットは、接続管理装置により割り当
てられるGizaテーブルインデックスであり、そしてこれ
はGiza整合テーブルへの書込みアクセスできる。現在、
接続管理装置は、Gizaエンジンを実施するコントローラ
盤（例えばＩＯＰ) 上でランする。

【０１６６】各Gizaエンジン上の低番号チャンネルは、
予め割り当てられた機能のために保留ないし予約され
る。例示の実施例において、ＩＯＰに対して８チャンネ
ル(0....7)が保留され、各ＪＯＡに対して８チャンネル
（8----119、ＩＯＰごとに１４のＩＯＡがあるから）が
保留される。予め定義されたＩＯＡおよびＩＯＰチャンネル

【０１６７】表１２は、例示の実施例におけるこれらの
あらかじめ定義されたチャンネルの利用状態をまとめた
ものである。

【表１２】予め定義されたＩＯＡおよびＩＯＰチャンネルの概要チャンネル IOA 側上の IOP 側上の目的番号方向方向０ IOA へ IOP へシステムレベル通信１ IOA から IOP から２ IOA へ IOP へ IOA およびIOP のPROM存在デバッガ３ IOA から IOP からを保留ないし予約４ IOA へ IOP へ Giza接続管理装置５ IOA から IOP から６ IOA へ IOP へドライバ特定メッセージ７ IOA から IOP から（逆転されるが、IOP 側で定義されない。）

【０１６８】ＩＯＰのイニシャライズでこれらの予め定
義されたチャンネルが解放され、解放状態に維持され
る。すべての予め定められたチャンネルは、単一のブロ
ックチャンネルを搬送し、各チャンネル作用するコード
がメッセージの最大ブロック寸法を定める。

【０１６９】システムレベルチャンネル（０および１）システムレベルチャンネル（０および１）上のメッセー
ジプロトコルは、なお定義されているべきである。目的
は、おそらく単にシステムエラーメッセージを送って、
これらのチャンネルをシステムとの通信状態におくこと
である。

【０１７０】デバッガチャンネル（２および３）チャンネル２および３は、ＩＯＡおよびＩＯＰＰＲＯＭ
に存するデバッガに対する標準の一組のデバッガプリミ
ティブに対して予約される。これらのでバッガは下記の
事項をなすように設計される。 ○ブレークポイントをセットおよびクリヤ ○ＩＯＡメモリを読み取り／書き込み。 ○ブレーク時点にレジスタを読み取り／書き込み。 ○コードを通って一段進む。 ○ブレークポイントから継続。 ○マッピングレジスタを読み取り／書き込み。

【０１７１】接続管理装置チャンネル（４および５）チャンネル４および５は、次のチャンネル制御動作のた
めに使用される。 ○チャンネル解放 ○チャンネル閉鎖 ○チャンネルフラッシング ○チャンネル再開 ○チャンネル切断

【０１７２】ＩＯＡドライバ特定チャンネル（６および７）例示の実施例において、ＩＯＡ側において、チャンネル
６および７はドライバ特定チャンネルであり、これは下
記の任意のものに使用できる。 ○ファームウェア構造 ○統計値収集 ○新チャンネル番号を通信 ○チャンネルクリーンアップ ○優先メッセージ

【０１７３】ＩＯＰチャンネル６および７ＩＯＰ側において、チャンネル６および７は保守および
診断（ＭおよびＤ）チャンネルである。

【０１７４】追加のＩＯＡチャンネルの創成 I/O ドライバは、これらの予め定義されたチャンネルの
みを使用することに限定されない。すなわち、任意数の
追加の単一方向チャンネルを各ＩＯＡに対して創成でき
る。ドライバコードを書き込む開発者は、これらの追加
のチャンネルについて必要とされる機能可能性を決定す
る。例えば、開発者は、これはＩＯＡに接続される各物
理的ラインに対してチャンネル対が創成されることを必
要とするＩＯＡドライバを書き込むかもしれない。他の
ものは、単一チャンネルつい、および多重ラインに対す
る多重メッセージを選択するかもしれない。また、他の
ものは、ＩＯＡにアクセスする各ＶＯＳポートまたはＦ
ＴＸ流に対して一つのチャンネル対を創成するかもしれ
ない。

【０１７５】Gizaチャンネルは、数種の異なる状態の一
つにあり得る。下記のライブラリルーチンおよび手続き
は、図２の仮想チャンネル要素および図１０の状態線図
に関係する。

【０１７６】チャンネル操作のためのインターフェース以下の説明は、Gizaチャンネルの操作方法について記述
するものである。節の前半は、チャンネル操作の梗概を
一般的に示し、後半は、関係するライブラリルーチンに
ついて詳細に論述するものである。

【０１７７】Gizaチャンネルは番号が付されており、整
数チャンネル番号は特定のGizaエンジンにのみ適用され
る。すなわち、システムには特定のGizaエンジン形式の
１以上の盤があり得るから、各Gizaエンジンはそれ自体
のリング記述子を有する。前チャンネルＩＤは３２ビッ
ト整数である。高次の８ビットは、使用されているGiza
エンジン（すなわちＩＯＰバックパネルスロット）を特
定する。残りの２４ビットは、接続管理装置により割り
当てられるGizaテーブルインデックスである。これはGi
za整合テーブルに書込みアクセスし得る。ここでは、接
続管理装置は、Gizaエンジンを実施するコントローラ盤
（例えばＩＯＰ）上でランする。

【０１７８】チャンネル操作の梗概以下の分節は、チャンネル操作（すなわち、チャンネル
の創成、フラッシング、再開および閉鎖）についての梗
概である。図１０は、発呼側（すなわち送信側）からGi
zaチャンネルの状態を示す図である。

【０１７９】本発明の例示に実施例において、Gizaチャ
ンネルは４状態、すなわち閉鎖、開放、フラッシングま
たは半閉鎖の一つの状態にあり得る。

【０１８０】チャンネルの創成 Giza転送を実施する各機能ユニットは、giza connect()
ライブラリルーチンを使用して新しいGizaチャンネルを
創成する潜在性を有する。

【０１８１】発呼装置（普通システム内のデバイスドラ
イバ）は下記のものを特定する。〇所望されるチャンネルの方向〇チャンネルの他端における機能ユニット〇雑多な形態情報。ライブラリルーチンは整数チャンネル番号を戻す。

【０１８２】チャンネルのフラッシングチャンネルをフラッシングするプロセスは、掲示された
が処理されなかったＭＤＢを回収する。Gizaチャンネル
の各側にあるドライバは、チャンネルのその側のフラッ
シングを強制し得る。これは、使用者のI/O 打切り（ア
ボート）要求の結果としてあるいはチャンネルを閉鎖す
る準備として起こり得る。チャンネルをフラッシングす
るためには、giza flush()ライブラリルーチンが使用さ
れる。このルーチンは、要求を接続管理装置に送り、そ
してこの装置がチャンネルをフラッシングとしてマーク
し、そのチャンネルに対してGizaエンジンにおいて現在
待ち行列化されているＭＤＢを戻す。戻されたＭＤＢは
エラービットでマークされる（フラッシュング）。

【０１８３】チャンネルが完全にフラッシングされるこ
とを保証するために、要求装置は、ＭＤＢの計数値を維
持するか、「トレーサビュレットＭＤＢ」をチャンネル
に沿って送る。トレーサは、チャンネルが完全にフラッ
シングされたときに戻る。何故ならば、ＭＤＢは、それ
らが通常のデータ伝送、エラーまたはフラッシングによ
り完了されるにせよ、それらが提示されたのと同じ順序
で戻されるからである。

【０１８４】チャンネル使用の再開ドライバが、チャンネルを閉鎖するか、ある未解決の動
作を単に打ち切ることを意図してチャンネルをフラッシ
ングする。チャンネルが閉鎖されるべきでないと、チャ
ンネルは、それが再度使用できる前に、動作を再開する
ようになされねばならない。そうでないと、すべての後
続のＭＤＢは、「フラッシュド」とマークされて戻され
る。Giza resume() ライブラリ機能は、接続管理装置に
メッセージを送り、そしてこの装置が、そのチャンネル
のもはやフラシングしていない側をマークする。

【０１８５】チャンネルの閉鎖ドライバがチャンネルを閉鎖することを決定する場合、
二つの方法がある。すなわち、〇通常の規則正しい方法〇由々しいエラー条件が存在する状況において

【０１８６】この分節は、通常の規則正しい方法を記述
し、以下の分節で、由々しいエラー条件に遭遇したチャ
ンネルの切断について論述する。

【０１８７】チャンネルの通常の閉鎖においては、ドラ
イバは、その対の機能ユニットに、意図されるチャンネ
ルを閉鎖すべきことを報知する。そのとき、各機能ユニ
ットはそのチャンネルをフラッシングする。フラッシン
グ遂行されると、各サイドは、チャンネルを閉鎖するた
めgiza close()ライブラリルーチンを呼ぶ。これによ
り、接続管理装置にメッセージが送られ、問題のチャン
ネルの発呼側を閉鎖する。そのチャンネルは、その側上
のみ「閉鎖」とマークされる。チャンネルが両側上にお
いて「閉鎖」とマークされると、チャンネルは、再使用
のためチャンネルの自由プールに戻される。

【０１８８】チャンネルの切断あるドライバに対する対の機能ユニットが死ぬまたは消
滅されるべき場合（ドライバが関係する限りにおい
て）、そのドライバは、giza disconnect() ライブラリ
ルーチンを使用することによりチャンネルを閉鎖せしめ
ることができる。このルーチンは、接続管理装置にメッ
セージを送り、チャンネルの両側が直ちに閉鎖されるべ
きことを要求する。要求中の機能ユニットは、チャンネ
ルのその側を先ずフラッシングすべきであるが、それは
必要ではない。

【０１８９】チャネル操作ライブラリルーチンの概要表１３はGizaチャンネルを操作するのに使用される標準
セットライブラリルーチンを簡単に叙述する。

【０１９０】

【表１３】

【０１９１】基本的チャンネル操作ライブラリルーチン
のためのパラメータ基本的チャンネル操作ライブラリルーチンの全てが、gi
za connectが以下の入力から提供するところのチャンネ
ル番号識別子(channel number)を受け取る。

【０１９２】

【表１４】 ──────────────────────────────────── 〇 c device id 〇 transfer type 〇 number of blocks ────────────────────────────────────

【０１９３】c device id は以下に示すように、IOP の
スロット番号とIOA のスロット番号とを具備する構造で
ある。

【０１９４】

【表１５】 ──────────────────────────────────── typedef structure { char slot level; /*IOP slot */ char device level; /*IOA slot */ char pad[6]; } c device id; ────────────────────────────────────

【０１９５】接続の時間の間中、永続的ないし不変であ
るtransfer type パラメータは生成されるチャンネルの
タイプを叙述する。それは以下のタイプのうちの一つが
可能である。

【０１９６】

【表１６】 ──────────────────────────────────── # define SEND 0 # define RECEIVE 1 ────────────────────────────────────

【０１９７】ブロックパラメータの番号は、整合テーブ
ルのチャンネル定義部に記録されそして図示の実施例に
おいて、そのチャンネルのために受け入れられるMDB を
限定するのに使用される（すなわち、それらはチャンネ
ルが解放されたとき指示されたブロックの番号を正確に
有さなければならない）。

【０１９８】channel numberパラメータに加えて、チャ
ンネル上でのフラッシュ動作、閉鎖動作、再開動作の際
に、write bit パラメータの設定が、チャンネルの書込
み側( 非ゼロ）または読取り側（０）のいずれが影響さ
れるかどうかを指示する。giza connectライブラリルー
チンもgiza disconnect ライブラリルーチンのいずれも
write bit パラメータを使用しない。

【０１９９】NAL ライブラリルーチンチャンネル操作のためのライブラリルーチンはそれぞれ
何らのメモリ割当てもない代替えルーチンを有する。こ
れら代替えライブラリルーチンを以下に示す。

【０２００】

【表１７】 ──────────────────────────────────── ○ giza close nal ○ giza connect nal ○ giza disconnect nal ○ giza flush nal ○ giza resume nal ────────────────────────────────────

【０２０１】図示の実施例において、これらのルーチン
は以下の理由のために使用可能である。

【０２０２】もしメモリ限界があればその理由（消尽さ
れた自由記憶域を有するシステム）もし発呼側が中断不
可能であればその理由（付属せられる何らのプロセスも
有さない、たとえば、Gizaコールバックにおいてストリ
ームモジュールの中断レベルにある場合など）

【０２０３】パラメータ：giza接続msg および他のrpc msg 基本的チャンネル操作ライブラリルーチンを使用すると
いうパラメータに加ええて、NAL ルーチンは２つのMDB
をコネクション管理部チャンネルへ報知する。一つは所
定のリクエスト（すなわち、接続、閉路、フラッシュ、
再開、または切断すること）を送るためのものであり、
一つはリクエストが成功裡に完了されたという応答を受
け取る（またはもし不成功であればエラーを受け取る）
ためのものである。giza connect nalライブラリルーチ
ンは以下に示されるgiza connect msgを使用する。

【０２０４】

【表１８】 ──────────────────────────────────── ／＊GIZA connection Manager message structures─ with their MDBs＊／ ( GIZA接続管理部メッセージ構造（それらのMDB を付帯） typedef struct LONGMAP unsigned char command; /* the command to which this is response */（これがそれに対する応答であるところのコマンド） unsigned char sequence number; /* the sequence number used */ （使用されるシーケンス番号） unsigned short status; /* 0=good status; else VOS error code */ （０は良好なステータスであり、それ以外はVOS エラーコード） long chan number /* the answer, if this is a connect */ （返答、もしこれが接続であれば） }conman response; typedef struct LONGMAP unsigned char command; /* connection manager command = CONNECT */（接続管理部コマンド＝接続） unsigned char sequence number; /* echoed in the respo nse; not checked*/（応答におけるエコー；チェックされず） unsigned char padb; unsigned char target slot; /* the slot at the oth er end of channel*/ （チャンネルの他方の端部のスロット） unsigned char transfer type; /* kind of transfer(1 of 6*/（転送の種類、６つのうちの一つ） unsigned char number of blocks; /* #blocks in MDBs on the new channel*/ （新規チャンネルのMDB のブロック） unsigned char padw; }connect request; typedef struct LONGMAP } unsigned char command; /* Connection Manager command */（接続管理部コマンド） unsigned char sequence number; /* echoed in the respo nse; not checked*/（応答におけるエコー；チェックされず） unsigned char side; /* =0 means read; not used in disconnect*/ （0 は読取りを意味し、不接続では使用されない） unsigned char pad; long chan number /* GIZA channel number */ （ GIZA のチャンネル番号） }other request; typedef struct $longmap sys mdb 11 rsp mdb ; /*MDB for the response from a connec tion*/（接続からの応答のためのMDB) conman response cmd resp ; /* the response message*/ （応答メッセージ) sys mdb 11 cmd mdb ; /*MDB for the connection request*/（接続リクエストのためのMDB) connect request con request ; /*the connection request message*/（接続リクエストメッセージ） long pid ; /*the process ID of the suspended ca ller */ （保留された発呼側のプロセスＩＤ） unsigned long iop slot ; /*the slot # field to be merged */（マージ（併合）されるスロット番号フィールド） /*cmd resp's chan number*/ /*by the callback from giza connect nal*/ ( giza connect nalからのコールバックによる） }giza connect msg; /* the reply is first in the giza connect msg structure because the wh ole structure is returned to free storage when the reply comes back and at that time, we're given a pointer to resp mdb */（応答は最初giza conne ct msg構造にある。なぜなら、応答が戻ってくるとき構造全体は自由記憶域に戻され、そしてそのとき我々はresp mdbへのポインタが与えられるからである） ────────────────────────────────────

【０２０５】チャンネルをフラッシュし、再開し、閉鎖
しまたは切離すための残余のルーチンは、以下のother
rpc msg を使用する。

【０２０６】

【表１９】 ──────────────────────────────────── /* The following messages have replies, but a different structure from giza connect msg for the request*/（以下のメッセージは応答を有する。しかし、リクエストについてgiza connect msgからは異なる構造） typedef struct { sys mdb 11 rsp mdb ; conman response cmd resp ; sys mdb 11 cmd mdb ; /* MDB */ （ＭＤＢ） other request other request ; /* message */ （メッセージ） long pid ; /* the process ID of the suspended c aller */（保留された発呼側のプロセスＩＤ） } other rpc msg ; /* disconnect, close, flush, resume */(切離し、閉鎖、フラッシュ、再開） ────────────────────────────────────

【０２０７】NAL ルーチンのためエラーコードを抽出するマクロ２つのマクロが、giza connect msgまたはother rpc ms
g と一緒に送られる接続管理部メッセージのペアからの
VOS エラーコード抽出に使用される。これらのマクロは
以下に示すCONMAN ERRおよびNEW CHANである。

【０２０８】

【表２０】 ──────────────────────────────────── /* CONMAN ERR works for both giza connect msg and pther rpc msg becaus e they start the same and this macro references only fields in the first three substructures. CONMAN ERR extracts a VOS error code from the retu rned connection manager message pair.*/ （ CONMAN ERR は giza connect ms g および pther rpc msgについて働く。なぜなら、それらは同じことを始めそしてこのマクロは最初の３つの副構造のフィールドだけを参照するからである。CO NMAN ERRはVOS エラーをコードを戻される接続管理部メッセージのペアから抽出する） ────────────────────────────────────

【０２０９】

【表２１】 ──────────────────────────────────── #define CONMAN ERR(mdbp) (＼ ((((mdbp) - >cmd mdb.hdr.message status) ! =0)＼ ||((((mdbp) - >rsp mdb.hdr.message status) ! =0))?＼ (e$giza connect failed) : ＼ ((((mdbp) - >cmd resp.status)) /*NEW CHAN builds a channel number from the reply to be found in the ret urn MDB. If there was an error, an illegal channel number is created. */ （NEW CHANが戻りMDB に見出される返答からchannel numberを構築する。もしエラーがあったならば、イリーガルチャンネル番号が生成される) 。 #define NEW CHAN(mdbp) ((channel number)＼ ((((mdbp) - >cmd mdb.hdr.message status) ! =0)＼ ||((((mdbp) - >rsp mdb.hdr.message status) ! =0)＼ ||((((mdbp) - >con request.command) ! = (mdbp) - >cmd resp.command))＼ ||((((mdbp) - >con request.sequence number) ＼ ! ((mdbp) - >cmd resp.sequence number))＼ ||((((mdbp) - >cmd resp.status) ! =0))? (0x7fffffff) : ＼ ((mdbp) - >iop slot ＼ |(mdbp) - >cmd resp.chan number)) ────────────────────────────────────

【０２１０】仮想チャンネル要素のチャンネルは図１０
に示されるように種々のステータスで存在することがで
きる。以下は、これら種々の状態がそれによりnal 形式
において影響せられ得るところの態様に関係する。

【０２１１】giza close nal( )発呼シーケンス

【表２２】 ──────────────────────────────────── short giza close nal(channel number *sc、 short *write bit、 other rpc msg *mdbp、 void (*callback)(sys mdb header *) ) ; ────────────────────────────────────

【０２１２】記述 giza close nal( ) のコールはgiza close( ) ライブラ
リールーチンと同様、チャンネルを閉じる。発呼側はも
はやＭＤＢを所定のチャンネルに呈示しないことを約束
する。両方の側が、指示チャンネルが閉じたことを宣言
するときだけ、それは本当にチャンネルの自由プールに
戻される。

【０２１３】入力パラメータ

【表２３】

【０２１４】発呼シーケンス

【表２４】 ──────────────────────────────────── short giza connect nal( c device id*d idp、 short *transfer type、 short *number of blocks、giza connect msg *mdpb、 void (*callback)(sys mdb header *) ); ────────────────────────────────────

【０２１５】記述 giza connect nal( ) ライブラリルーチンは接続管理部
にd idp により指示されるごとく新規なチャンネル（Gi
zaエンジンの新規な整合テーブルエントリ）割り付けそ
してこれを初期化することをリクエストする。このルー
チンの使用者ががNEW CHAN(mdpb)マクロを使用し、結果
を、コールバックでgiza connect msgから戻される。

【０２１６】入力パラメータ

【表２５】 ──────────────────────────────────── c device id 以下に示されるごとくIOP スロット番号およびIO A スロット番号からなる構造 typedef structure { char slot level; /*IOP slot */ char device level; /*IOA slot */ char pad[6]; } c device id; transfer type 接続の間、永続的であり、それは生成されるチャンネルのタイプを叙述する。それは以下のタイプのうちの一つとすることができる。 # define SEND 0 # define RECEIVE 1 number of blocks チャンネルを定義しそしてこれを限定する。 giza connect msg ２つのＭＤＢを包含する。一つはメッセージを送り接続管理部を通じチャンネルを接続し、一つは接続が成功したことの肯定応答またはエラーメッセージのいずれかと一緒にメッセージを戻り受信する。 callback 接続管理部がこのリクエストを完了したときに呼び出されるＣ機能のアドレス。 giza disconnect nal( ) ────────────────────────────────────

【０２１７】発呼シーケンス

【表２６】 ──────────────────────────────────── short giza disconnect nal( c device number *sc、 other rpc msg *mdbp、 void (*callback)(sys mdb header*) ); ────────────────────────────────────

【０２１８】記述 giza disconnect nal( )ライブラリルーチンは（たとえ
ば、IOA が消滅するときなどの）緊急使用のためだけで
ある。それはホストまたはＩＯＡ側のいずれかから発行
できる。しかし、発行されるとき、channel numberパラ
メータにより識別されるチャンネルを強制し、同時に両
方の側をフラッシュしそして閉じる。

【０２１９】入力パラメータ

【表２７】

【０２２０】発呼シーケンス

【表２８】 ──────────────────────────────────── short giza flush nal( channel number *sc、 short *write bit、 other rpc msg *mdbp、void (*callback)(sys mdb header *)); ────────────────────────────────────

【０２２１】記述 giza flush nal( ) ライブラリルーチンはgiza flus
h（）ライブラリコードへの代替え機構である。Ｉ／Ｏ
アボートの部分として使用されるかまたはチャンネルを
閉じるのに備え、それはチャンネルをフラッシュし、発
呼側のいずれのペンディングMDB をも発呼側へ戻される
よう強制する。すべてのMDB がそれらが呈示された順序
で戻る。もしチャンネルがフラッシュできなければ、sy
serrメッセージが発生されそして記録される。

【０２２２】入力パラメータ

【表２９】

【０２２３】フォーマット化

【表３０】 ──────────────────────────────────── short giza resume nal( channel number *sc、 short *write bit、 other rpc msg *mdbp、void (*callback)(sys mdb header *) ); ────────────────────────────────────

【０２２４】記述 giza resume nal( )ライブラリルーチンはgiza resume
（）への代替え機構であり、チャンネルを動作へと戻
す。

【０２２５】チャンネルはそれを閉じる（または切離
す）前に一般にフラッシュされる。ところで、チャンネ
ルの使用もまた一時的に中断され、たとえばＩ／Ｏアボ
ートなどの部分として報知ＭＤＢをフラッシュおよび検
索する。ひとたび報知ＭＤＢが検索されると、ドライバ
は、giza resume( )ライブラリルーチンを呼び出すこと
により依然として解放しているチャンネルを使用し再開
できる。

【０２２６】入力パラメータ

【表３１】

【０２２７】発呼シーケンス

【表３２】 ──────────────────────────────────── short giza close( channel number *sc、 short *write bit ); ────────────────────────────────────

【０２２８】記述 giza close( ) コールはチャンネルを閉じるための標準
機構である。このコールで、発呼側はもはやＭＤＢを所
定チャンネルに送信しないことを約束する。両方が指定
チャンネルが閉じたことを宣言するときだけ、それは本
当にチャンネルの自由プールへ戻される。

【０２２９】入力パラメータ

【表３３】

【０２３０】発呼シーケンス

【表３４】 ──────────────────────────────────── short giza close( c device id *d idp、 short *transfer type、 short *number of blocks、 channel number *sc ); ────────────────────────────────────

【０２３１】記述 giza connect ( )ライブラリルーチンは新規なチャンネ
ル（Gizaエンジンの新規な整合テーブルエントリ）を割
り付けそしてこれを初期化する。

【０２３２】入力パラメータ

【表３５】ｄｅｖｉｃｅｉｄ以下に示されるごとくIOP スロット番
号およびIO A スロット番号からなる構造 typedef structure { char slot level; /*IOP slot */ char device level; /*IOA slot */ char pad[6]; } device id; transfer type 接続の間、永続的であり、それは生成されるチャンネルのタイプを叙述する。それは以下のタイプのうちの一つとすることができる。 # define SEND 0 # define RECEIVE 1 number of blocks チャンネルを定義しそしてこれを限定する。 ────────────────────────────────────

【０２３３】出力パラメータ

【表３６】

【０２３４】発呼シーケンス

【表３７】ｓｈｏｒｔｇｉｚａｄｉｓｃｏｎｎｅｃｔ（ｃｈａｎｎｅｌｎｕｍｂｅ
ｒ＊ｓｃ）； ────────────────────────────────────

【０２３５】記述 giza disconnect ( ) ライブラリルーチンは（たとえ
ば、ＩＯＡが消滅したときなど）緊急使用のためだけで
ある。それはホストまたはＩＯＡ側のいずれかから発行
できる。しかし、発行されるとき、channel numberパラ
メータにより識別されるチャンネルを両側で同時にフラ
ッシュしそして閉じるよう強制する。

【０２３６】入力パラメータ

【表３８】

【０２３７】発呼シーケンス

【表３９】 ──────────────────────────────────── short giza flush( channel number *sc、 short *write bit ); ────────────────────────────────────

【０２３８】記述 giza flush ( )ライブラリルーチンは、Ｉ／Ｏアボート
の部分としてまたはチャンネルを閉じる準備をするのに
使用される。それはチャンネルをフラッシュし、発呼側
のいずれのペンディングＭＤＢも発呼側へ戻されるよう
強制する。全てのＭＤＢはそれらが呈示された順序で戻
る。もしチャンネルがフラッシュできなければ、システ
ムエラーが発生されそして記録される。

【０２３９】入力パラメータ

【表４０】

【０２４０】発呼シーケンス

【表４１】 ──────────────────────────────────── short giza resume( channel number *sc、 short *write bit、 ); ────────────────────────────────────

【０２４１】記述チャンネルはそれを閉じる（または切離す）前に一般に
フラッシュされる。ところで、チャンネルの使用もまた
一時的に中断され、たとえばＩ／Ｏアボートなどの部分
として報知ＭＤＢをフラッシュおよび検索する。ひとた
び報知ＭＤＢが検索されると、ドライバは、giza resum
e( )ライブラリルーチンを呼び出すことにより依然とし
て解放されているチャンネルを使用し再開できる。

【０２４２】入力パラメータ

【表４２】

【０２４３】応答リング GIZAはMDB をそれらの対応する装置へ戻す。MDB はソフ
トウエアリング（応答リング）を介して戻される。以下
は図２に図示されるごとく戻りFIFO要素に関係する。

【０２４４】応答（from giza)リングは、Gizaエンジン
から核（カーネル）またはIOA ファームウエアへ戻るMD
B ポインタのため一時的にFIFOを保持する。あらゆるホ
ストおよびIOA がそれに関連付けられる少くともfrom g
iza リングを有する。ところで、コード設計の際の融通
性を提供するために、たいていの機能ユニットが、そこ
から選択するところの２つ以上の応答リングを有する。
これは種々のＭＤＢの種別に適合する。たとえば、ある
応用ができるだけ最小限の待ち時間でＭＤＢを要求しそ
して（たとえばイーサネットパケットのACK など）の中
断レベルでそれらを取扱うのを選択するかもしれない。
代替え例として、ある応用が待ち時間ではなくＣＰＵの
使用をできるだけ最小限にし、それゆえ、（たとえばポ
ーリングループなどから）バックグラウンドでＭＤＢコ
ールバックを処理したいかも知れない。

【０２４５】多重プロセッサ機能ユニットでは、もしコ
ールバックがリング上で発生するのと同じ順序で完了さ
れることを保証したいと欲するのであれば、これらコー
ルバックを行っている間、リングを一つのプロセッサに
ロックすることが必要である。このロック動作はコール
バックプロセッシングを一度に一つのＣＰＵへ限定す
る。それゆえ、ロックされないリングを有することは一
つのオプションであり、多数のＣＰＵがコールバックを
同時に処理するのを許容する。これらは順序が重要でな
いところのＭＤＢについてだけ使用される。デフォルト
により、順序が重要であると仮定されそれゆえロックさ
れるリングは正規のケースであると仮定される。

【０２４６】この目的のために、以下の議論はGizaリン
グと関連付けられる２つのカテゴリの属性、一方の属性
はMDB が空き応答リングに置かれるときに中断が発生さ
れるかどうかを決定しそして他方は応答リングがロック
されるかどうかを決定する。

【０２４７】表４３はこれらのオプションを例示するた
めに選択される一組のリングを示す。現在計画されてい
るごとく、いずれのシステムでも使用されるようになる
ここに定義されるリングよりも多くのリングがある。

【表４３】

【０２４８】中断および非中断リング一般に、Giza応答リングは以下のタイプのうちの一つで
ある。１）ＭＤＢがそこにおかれたときに機能ユニットで中断
を生ずるようフラッグ処理される中断リング（それは以
前に空き状態であったと仮定する）２）機能ユニットが（たとえばメインループ、スケジュ
ーラコード、カーネル出口で）頻繁にポールするところ
のポールリング３）標準的にはポールされないが、特別の状況でポール
され得るカスタムポールリング。カスタムポールリング
がテストプログラムのためだけにまたはＣＰＵのＰＲＯ
Ｍによりそしてシステム停止の状況でデバッガにおいて
使用され得る。

【０２４９】ロックおよびロックされないリング Gizaリングの他の属性はそれらがロックされるかどうか
を決定する。ロックリングは複数ＣＰＵがそれに同時に
サービスを提供するのを許容しない。これはデフォルト
であり、そしてメッセージの順序が重要でありそして複
数のＣＰＵが同時に同様のリングにサービスを提供しよ
うとするかもしれないときに要求される。ロックされな
いリングは、ＭＤＢの順序が重要でないとき、たとえ
ば、あるＭＤＢがそれを自由リングへ戻す以外なにもし
ないときだけ使用されるのが好ましい。

【０２５０】エラー状態 Gizaが機能ユニット間にブロックを賦与する。Gizaエラ
ーはＩ／Ｏエラーにではなくブロック供給に関係する。
Ｉ／Ｏエラーがデバイスアダプタからもとのドライバへ
と正規Gizaメッセージを通じて報告される。Gizaエラー
は以下のものを含む。１）チェックサムエラー２）宛て先機能ユニットの消滅(death) ３）ブロックのオーバラン４）不存在メモリアドレス５）不存在Gizaチャンネル６）ページの境界を横切る試み

【０２５１】転送エラーが標準的なGizaチャンネルで生
ずるとき、メッセージは供給されず、そしてドライバ書
込み部がいずれのペンディングＭＤＢをどのように取扱
うかを決定する必要がある。転送の相手方が両方とも等
しくエラー報告を受ける。

【０２５２】GIZAエンジンまたは機能ユニットの消滅 GiZAを使用する機能ユニット消滅すれば、パートナーの
機能ユニットのドライバコードは使用されているいずれ
のチャンネルをも切離すことにより消去されねばならな
い。消滅の検出は、もし転送が企図されていたならばGI
ZAエラーを通じて生じそしてGIZAエンジンはもはや機能
ユニットが存在しないことを発見する。代わりに、通信
機能ユニットが周期的に「私は存在している、あなたは
どう？」というコントロールメッセージを互いに送信
し、妥当な時間長さ（数秒から数分）におけるかかるメ
ッセージのないことにより検出されることが推奨され
る。

【０２５３】もし、GIZAエンジンが消滅すれば、チャン
ネルは自動的に閉じられる。なぜなら、それらはGIZAエ
ンジンに属するからである。GIZAエンジンの消滅を検出
するＭ＆Ｄプロセスはライブラリルーチンremove giza
ring db を呼び出し、GIZAエンジンのGIZAリングを除去
した後GIZAエンジンにより所有される全てのＭＤＢを戻
す。これらが戻される間何らのＭＤＢも呈示できない。

【０２５４】管理ライブラリルーチンソフトウエアリングの生成および破壊の過程はGIZAの機
能にとって重要である。結果的に、リングを初期化およ
び発生するコードが存在しなければならない。それゆ
え、以下はソフトウエアリングの発生および破壊に関係
する。この欄は、Gizaリングを初期化および除去するの
に使用される以下のライブラリルーチンを叙述する。 ■ init giza ring db ■ remove giza ring db remove giza ring db(short *iop slot、 short *simple
xed)

【０２５５】このinit giza ring db ライブラリルーチ
ンはスロットiop slotでGIZAエンジンのための一組のリ
ングを割当ておよび初期化する。それはポインタをリン
グディスクリプタデータ構造へ戻す。「シンプレックス
化」されるパラメータは、もし初期化されるGIZAエンジ
ンが（デュプレックス化されるペアであること（これは
Stratus のハードウエアのために設計されている）また
は単独ランするデュプレックス化ペアの半分であること
と対照的に）内在的にシンプレックス化されるのであれ
ば、非ゼロとすべきである。 sys giza db *init giza ring db( short *iop slot、 s
hort *simplexed )

【０２５６】記述ホスト側はinit giza ring db ライブラリルーチンを使
用し、iop slotのIOPのためにGIZAリングを初期化す
る。それはポインタをリングディスクリプタへ戻す。シ
ンプレックス化されるパラメータは、もし初期化される
IOP が（それがデュプレックス化ペアの部分であること
が企図されるとき単独でランするのと対照的に）内在的
にシンプレックス化されるのであれば、非ゼロへ戻るべ
きである。

【０２５７】要約ディジタルデータプロセッシング機能ユニット間で情報
を転送するための新規なシステム（方法および装置の両
方）について説明した。システムは、幅広く、２つの機
能ユニット（たとえば、ホストプロセッシング部および
周辺装置）およびそれらの間で情報を転送するためのコ
ントローラを有するディジタルデータ処理装置を含む。
第１の機能ユニットが、データがそこから転送されると
ころの関連の局部メモリ中の一つまたはそれ以上のアド
レスを指示する送信メッセージディスクリプタブロック
（ＭＤＢ）信号を発生する。第２の機能ユニットが、デ
ータがそこへ転送されるところのその関連の局部メモリ
中の一つまたはそれ以上の場所を指示する受信メッセー
ジディスクリプタブロック（ＭＤＢ）信号を発生する。
コントローラは、送信および受信ＭＤＢ信号、特に同じ
ものを指示するもの、を整合する。

【０２５８】図示のシステムはディジタルデータプロセ
ッシング機能ユニット間の情報の改善された転送を提供
する。それは、たとえば周辺装置などの機能ユニットへ
のデータの迅速な転送を助長しそして付随するソフトウ
エアおよびハードウエア機構の複雑さをできるだけ最小
限にする改善された入力／出力制御を提供するのに使用
できる。特に、システムはタイミングエラーからの改善
された免疫性を提供する。

【０２５９】当業者であれば、本発明の技術思想から逸
脱することなく種々の変更及びおよび修正が可能である
ことは明らかであろう。これらの修正および変更は請求
の範囲に記載の本発明の技術思想内に包摂されるべきも
のである。

【図面の簡単な説明】

【図１】本発明の実施との関係で使用される好ましいデ
ィジタルデータ処理装置の模式図である。

【図２】本発明による好ましいデータ転送システムの模
式図である。

【図３】本発明によるシステムの好ましい戻りＦＩＦＯ
の概念図である。

【図４】本発明による好ましいデータ転送システムの構
造的な概観図である。

【図５】本発明による好ましいデータ転送システムを利
用する遠隔入／出力ドライバの構成で使用するための遠
隔サブルーチンモデルを図示する概念図である。

【図６】本発明による好ましいデータ転送システムを利
用する遠隔入／出力ドライバの構成で使用するための遠
隔サブルーチンモデルを図示する概念図である。

【図７】本発明による好ましいデータ転送システムを利
用する遠隔入／出力ドライバの構成で使用するための遠
隔サブルーチンモデルを図示する概念図である。

【図８】本発明による好ましいデータ転送システムを利
用する遠隔入／出力ドライバの構成で使用するためのパ
イプラインモデルを図示する概念図である。

【図９】本発明による好ましいデータ転送システムで使
用されるあらかじめ定められるチャンネルを図示する模
式図である。

【図１０】本発明による好ましいデータ転送システムで
使用されるチャンネルの状態を図示する模式図である。

【手続補正書】

【提出日】平成５年９月１０日

【手続補正１】

【補正対象書類名】明細書

【補正対象項目名】請求項１６

【補正方法】変更

【補正内容】

───────────────────────────────────────────────────── フロントページの続き (72)発明者ランディー・シベルアメリカ合衆国マサチューセッツ州ブラックストーン、リンカン・ストリート255 (72)発明者ウィリアム・ディー・スナッパーアメリカ合衆国マサチューセッツ州ホリストン、カール・ロード51 (72)発明者ジョナサン・ウェストアメリカ合衆国マサチューセッツ州ノースボロ、チャーチ・ストリート365

Claims

【特許請求の範囲】

【請求項１】少なくとも第１および第２の機能ユニッ
トを有し、その各々が、アドレス可能な位置にデータを
記憶するための関連するメモリ手段を備え、該各メモリ
手段が、読取りモードにおいて、加えられるアドレス信
号に応答して、かかるアドレス信号により特定される位
置に記憶されるデータを表わすデータ信号を発生し、書
込みモードにおいて、加えられるアドレスおよびデータ
信号に応答して、かかるアドレス信号により特定される
位置にかかるデータ信号により特定されるデータを記憶
し、そして前記第１および第２機能ユニットに結合され
て両者間においてデータを転送するためのコントローラ
手段を備える形式のディジタルデータ処理装置におい
て、Ａ．前記第１機能ユニットが、データが転送送出される
べき関連するメモリ手段内の１または複数のアドレスを
特定するＭＤＢ送信信号を発生して前記コントローラに
転送するための送信手段（センダ）を備え、前記第２機能ユニットが、データが転送されるべき関連
するメモリ手段内の１または複数のアドレスを特定する
ＭＤＢ受信信号を発生して前記コントローラに転送する
ための送信手段（レシーバ）を備え、Ｂ．前記コントローラ手段が、前記送信手段および受信
手段に結合されたＭＤＢ整合手段であって、前記ＭＤＢ
送信信号の少なくとも選択された一つの信号を前記ＭＤ
Ｂ受信信号の選択された一つの信号に整合させ、整合中
のＭＤＢ信号により特定される前記第１および第２機能
ユニットのメモリ手段の対応する位置間においてデータ
の転送を実行するための信号を発生するＭＤＢ整合手段
を備え、Ｃ．前記コントローラ手段が、前記ＭＤＢ整合手段およ
び前記第１および第２機能ユニットのメモリ手段に結合
されたデータ転送手段であって、前記転送実行信号に応
答して、 i)前記第１機能ユニットのメモリ手段に、前記ＭＤＢ送
信信号内に特定されるアドレスを表わすアドレス信号を
供給し、そのアドレス信号の供給に応答して該メモリ手
段からそれにより発生されるデータ信号を受信し、 ii) これらのデータ信号を前記第２機能ユニットのメモ
リ手段に、前記ＭＤＢ受信信号に特定されるアドレスを
表わすアドレス信号とともに供給することを特徴とする
ディジタルデータ処理装置。
【請求項２】前記第１および第２機能ユニットの少な
くとも一つが、整合の受信中１または複数のＭＤＢ信号
を記憶するためのFIFO命令手段を備える請求項１記載の
ディジタルデータ処理装置。
【請求項３】前記各FIFO命令手段が、ＭＤＢ信号が、
それらがそのFIFO命令手段により受信された順序でアク
セスされ得るように、前記のそれぞれのＭＤＢ信号を記
憶するための手段を備える請求項２記載のディジタルデ
ータ処理装置。
【請求項４】前記ＭＤＢ整合手段が、前記第１および
第２機能ユニットにより発生されるＭＤＢ信号を複数の
仮想チャンネルに沿って整合させるための仮想チャンネ
ル手段を備える請求項１記載のディジタルデータ処理装
置。
【請求項５】Ａ．前記送信手段および前記受信手段の
各々が、前記整合が起こるべき仮想チャンネルを特定す
る仮想チャンネル番号を含むように、前記のそれぞれの
ＭＤＢ送信信号およびＭＤＢ受信信号を発生するための
手段を備え、Ｂ．前記仮想チャンネル手段が、同様の仮想チャンネル
番号を有するＭＤＢ送信およびＭＤＢ受信信号に応答し
て対応するデータの転送を実行する手段を備える請求項
４記載のディジタルデータ処理装置。
【請求項６】前記仮想チャンネル手段が、次の少なく
とも一つを記憶する、すなわち、Ａ．同様の仮想チャンネル番号を有するＭＤＢ受信信号
の受信中ＭＤＢ送信信号に対する少なくとも一つのポイ
ンタ、およびＢ．同様の仮想チャンネル番号を有するＭＤＢ送信信号
の受信中ＭＤＢ受信信号に対する少なくとも一つのポイ
ンタの少なくとも一つを記憶するための仮想チャンネル
メモリ手段を備える請求項５記載のディジタルデータ処
理装置。
【請求項７】Ａ．前記機能ユニットの少なくとも１つ
のが、仮想チャンネルの創成、フラッシング、閉鎖、切
断および再開の少なくとも一つを要求する信号を発生
し、コントローラに伝送するための手段を備え、Ｂ．前記仮想チャンネル手段が、この信号に応答して、
選択された仮想チャンネルを選択的に創成し、フラッシ
ングし、閉鎖し、再開し、切断するための接続管理手段
を備える請求項４記載のディジタルデータ処理装置。
【請求項８】Ａ．前記送信手段および前記受信手段の
各々が、チャンネルフラッシングまたはチャンネル閉鎖
信号の少なくとも一つを発生するための手段を備え、Ｂ．前記接続管理手段が、該チャンネルフラッシング信
号に応答して、下記の動作の少なくとも一つの動作、す
なわち、(i) 未解決のＭＤＢ信号の特定された仮想チャ
ンネルをクリヤし、(ii)未解決または途中のＭＤＢ信号
を、前記のそれぞれの第１および第２機能ユニットの発
信中のユニットに戻す動作の少なくとも一つの動作を遂
行するためのチャンネルフラッシング手段を備え、Ｃ．前記接続管理手段が、前記チャンネル閉鎖信号に応
答して、特定された仮想チャンネルを、前記ＭＤＢ送信
信号および前記ＭＤＢ受信信号のいずれかの供給から隔
絶するためのチャンネル閉鎖手段を備える請求項７記載
のディジタルデータ処理装置。
【請求項９】前記ＭＤＢ整合手段が、前記コントロー
ラと、前記第１および第２機能ユニットの少なくとも１
つとの間で少なくとも信号を転送するための予め定義さ
れた仮想チャンネルを備える請求項４記載のディジタル
データ処理装置。
【請求項１０】前記ＭＤＢ整合手段が、前記接続管理
手段と、前記第１および第２機能ユニットの少なくとも
一つとの間において接続管理動作およびそれに対する応
答の要求を表わす信号を２方向において転送するため
の、予め定義された１対のCONNECT MANAGER 仮想チャン
ネルを備える請求項９記載のディジタルデータ処理装
置。
【請求項１１】前記ＭＤＢ整合手段が、前記コントロ
ーラ、前記第１機能ユニットおよび前記第２機能ユニッ
トのいずれか二つの間で、下記のいずれか一つ、すなわ
ち、(i) 通信トランザクションが行われるべき仮想チャ
ンネルを指示する信号、および(ii)制御および通信デー
タの少なくとも一つを転送するための、予め定義された
DRIVER CONTROL仮想チャンネルを備える請求項９記載の
ディジタルデータ処理装置。
【請求項１２】前記ＭＤＢ整合手段が、次の一つ、すな
わち、Ａ．前記コントローラ、前記第１機能ユニット、および
前記第２機能ユニットの少なくとも二つの間において診
断およびエラー信号の少なくとも一つを転送するための
予め定義されたMAINTENANCE およびDIAGNOSTC 仮想チャ
ンネル、およびＢ．前記コントローラ、前記第１機能ユニット、および
前記第２機能ユニットの少なくとも二つの間においてデ
バッグ信号を転送するための予め定義されたDEBUGGER仮
想チャンネルの少なくとも一つを含む請求項９記載のデ
ィジタルデータ処理装置。
【請求項１３】前記コントローラが、データの転送の
完了に応答して、対応するＭＤＢ送信および受信信号を
前記第１および第２機能ユニットの対応するものに戻す
返送手段を備える請求項１記載のディジタルデータ処理
装置。
【請求項１４】前記第１および第２機能ユニットの少
なくとも一つが、前記データ転送の完了の際対応するＭ
ＤＢ信号を保持するための少なくとも一つのFIFO返送手
段を備える請求項１記載のディジタルデータ処理装置。
【請求項１５】前記の送信手段および前記受信手段の
各々が、前記のそれぞれのFIFO返送手段のいずれの一つ
にそれぞれのＭＤＢ信号が戻されるべきかを特定するFI
FO返送番号を含むように前記のそれぞれのＭＤＢ送信お
よび受信信号を発生するための手段を含む請求項１４記
載のディジタルデータ処理装置。
【請求項１６】Ａ．前記送信手段および前記受信手段
の少なくとも一つが、前記データ転送の完了の際実行さ
れるべき予定された動作を特定する信号を含むように、
前記ＭＤＢ送信および受信信号の対応する信号を発生す
るための手段を備え、Ｂ．前記の対応する第１および第２の機能ユニットが、
制御の復帰の際、前記の予め決定された動作を実行する
ためのコールバック手段を備える請求項１３記載のディ
ジタルデータ処理装置。
【請求項１７】前記送信手段および受信手段の少なく
とも一つが、前記の予定された動作を、その予定された
動作を実行するためのプログラミング命令を指示するア
ドレスとして特定する前記信号を発生するための手段を
含む請求項１６記載のディジタルデータ処理装置。
【請求項１８】Ａ．前記送信手段が、少なくとも、デ
ータが転送送出されるべき関連するメモリ手段内の１ま
たはそれ以上のアドレスおよび０、１または複数の他の
データを含むＭＤＢ送信信号構造体を発生するための手
段を備え、Ｂ．前記受信手段が、少なくとも、データが転送される
べき関連するメモリ手段内の１または複数のアドレスお
よび０、１またはそれ以上の他のデータを含むＭＤＢ受
信信号構造体を発生するための手段を備え、Ｃ．前記送信および受信手段の各々が、前記ＭＤＢ送信
および受信信号構造体の対応するものに対するポインタ
としてＭＤＢ信号を発生するための手段を備える請求項
１記載のディジタルデータ処理装置。
【請求項１９】前記返送手段が、要求されるデータ転
送の状態を指示する信号を含むように前記ＭＤＢ送信お
よび受信信号をマークするための手段を含む請求項１３
記載のディジタルデータ処理装置。
【請求項２０】前記FIFO返送手段が、ＭＤＢ信号を表
す信号を記憶しかつその受信の際割込みを発生するため
のINTERRUPT バッファ手段を備える請求項１３記載のデ
ィジタルデータ処理装置。
【請求項２１】少なくとも第１および第２の機能ユニッ
トを有し、その各々が、アドレス可能な位置にデータを
記憶するための関連するメモリ手段を備え、該各メモリ
手段が、読取りモードにおいて、加えられるアドレス信
号に応答して、かかるアドレス信号により特定される位
置に記憶されるデータを表わすデータ信号を発生し、書
込みモードにおいて、加えられるアドレスおよびデータ
信号に応答して、かかるアドレス信号により特定される
位置にかかるデータ信号により特定されるデータを記憶
し、そして前記第１および第２機能ユニットに結合され
て両者間においてデータを転送するためのコントローラ
手段を備える形式のディジタルデータ処理装置を操作す
る方法において、Ａ．前記第１機能ユニット内において、データが転送送
出されるべき関連するメモリ手段内の１または複数のア
ドレスを特定するＭＤＢ送信信号を発生し、そのＭＤＢ
送信信号を前記コントローラ手段に転送し、前記第２機
能ユニット内において、データが転送されるべき関連す
るメモリ手段内の１または複数のアドレスを特定するＭ
ＤＢ受信信号を発生し、そのＭＤＢ受信信号を前記コン
トローラ手段に転送し、Ｂ．前記コントローラ手段において、少なくとも選択さ
れたＭＤＢ送信信号を選択されたＭＤＢ受信信号に整合
させ、整合しているＭＤＢ信号により特定される前記第
１および第２機能ユニットのメモリ手段の対応する位置
間においてデータの転送を実行するための信号を発生
し、Ｃ．前記コントローラ手段内において、前記転送実行信
号に応答して、 i)前記第１機能ユニットのメモリ手段に、前記ＭＤＢ送
信信号内に特定されるアドレスを表わすアドレス信号を
供給し、そのアドレス信号の供給に応答して該メモリ手
段からそれにより発生されるデータ信号を受信し、 ii) これらのデータ信号を前記第２機能ユニットのメモ
リ手段に、前記ＭＤＢ受信信号に特定されるアドレスを
表わすアドレス信号とともに供給する諸段階を含むこと
を特徴とするディジタルデータ処理装置操作方法。
【請求項２２】前記第１および第２機能ユニットによ
り発生される前記ＭＤＢ信号を複数の仮想チャンネルに
沿って整合させることを含む請求項２１記載のディジタ
ルデータ処理装置操作方法。
【請求項２３】Ａ．前記整合が行われるべき仮想チャ
ンネルを特定する仮想チャンネル番号を含むように前記
ＭＤＢ送信信号および前記ＭＤＢ受信信号を発生し、Ｂ．前記コントローラ手段内において、同様の仮想チャ
ンネル番号を有するＭＤＢ送信および受信信号の受信に
応答して、前記転送実行信号を発生することを含む請求
項２２記載のディジタルデータ処理装置操作方法。
【請求項２４】Ａ．前記機能ユニットのいずれかにお
いて、仮想チャンネルの創成、フラッシング、切断およ
び再開の少なくとも１つを要求する信号を発生し、Ｂ．この要求信号に応答して、選択された仮想チャン
ネルを選択的に創成し、フラッシングし、閉鎖し、再開
し、切断することを含む請求項２１記載のディジタルデ
ータ処理装置操作方法。