JP2654281B2 - 共通バスの単独競合モジュール・アービトレーション機構 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明は、広くバス通信システ
ムに関し、特にデータを転送するために共通バスにアク
セスしようと競い合うデバイスによるバス制御アービト
レーションに関する。

【０００２】

【従来の技術】共通バスが複数の通信モジュールに接続
された高速通信システムでは、競合するモジュールのア
ービトレーションとメッセージの転送による遅れが大き
な問題になる。複数の通信モジュールが同時に共通デー
タを競うときは、要求するモジュールに優先度をつけて
バスへのアクセスを得るモジュールを選択するために、
アービトレーション・コードが必要である。

【０００３】バス取得システムについては、Rickard に
よる米国特許出願第４７３６３６６号を、バス・トラン
シーバについては同氏による米国特許出願第４７５６０
０６号を参照されたい。

【０００４】代表的な通信システムでは、共通バスを競
う通信モジュールが最大３２個にもなる。モジュール３
２個には１２８の論理優先レベルを付加することができ
る。アービトレーション・シーケンス（データ・バス上
で生じる）は、優先するモジュールの論理／物理ＩＤを
決定するのに８バス・サイクルかかる。バスを競うモジ
ュールが１個しかない場合がある。ある時間にバスを競
うモジュールが１個しかないのが一般的であるとして
も、そのモジュールは、アービトレーション・シーケン
ス８サイクルの遅れを被ることになる。

【０００５】遅れの小さいアービトレーションを実現す
る手法としては、アービトレーション・シーケンスの先
頭に２サイクル追加し、モジュールがバスの制御を競っ
ているかどうかを判定するのが望ましい。バスを競うモ
ジュールが１個しかない場合は、８サイクルのアービト
レーション・シーケンスを継続する必要はなく、そのモ
ジュールがバスへ即座にアクセスできるようにするのが
よい。

【０００６】

【発明が解決しようとする課題】この発明の目的は、ア
ービトレーション・サイクルの遅れを少なくする改良さ
れたバス・アービトレーション・システムを提供するこ
とにある。

【０００７】この発明の目的には、エラーを検出するバ
ス・アービトレーション機能を提供することも含まれ
る。

【０００８】この発明の目的には、エラーの検出または
訂正ができるように、３２ビット・バス上で２重化また
は３重化できる改良されたバス・アービトレーション・
コードを提供することも含まれる。

【０００９】

【課題を解決するための手段】この発明は、共通バス通
信システム内のアービトレーションを判定する方法であ
り、この方法ではモジュールＩＤが真補（true and com
plement） 形式で書かれる。モジュールはすべて、バス
から集約（ワイアＯＲ）アイドル・バス・コードを受け
取った後に、チェック・コードを計算することによっ
て、競合するモジュールの個数を判定する。競合するモ
ジュールの個数が１に等しい場合は、優先するモジュー
ルが決定しており、アービトレーションは終了する。競
合するモジュールの個数が１より大きい場合、競合シー
ケンスは継続し、最終的にどのモジュールがを優先する
かが決定される。

【００１０】

【実施例】図１に示した通信ユニット１０は、共通バス
１２を使用し、複数の通信モジュール１４を備える。通
信モジュールは各々、０ないし３１の物理ＩＤを持ち、
バス・インタフェース・ユニット（ＢＩＵ）１６、中央
処理ユニット（ＣＰＵ）１８、及びメモリ・ユニット２
０を含む。ＢＩＵ１６はバスと通信モジュールのインタ
フェースをとる。ＣＰＵ１８は通信モジュールを制御
し、メモリ・ユニット２０へのデータの格納を指示し、
ＢＩＵ１６を介して共通バスへデータを送出する。

【００１１】モジュールが２個以上バスを要求した場
合、バスを競うモジュールのうちどのモジュールがバス
の制御を得るかを決定するためにアービトレーション・
コードが用いられる。この方法として一般的なのは、競
合する各モジュール１４に、その一意の５ビット物理Ｉ
Ｄに対応する０ないし３１のコードを出力させることで
ある。０ないし３１の数を表わすには５ビット必要であ
る。各モジュールのコードは、バス（ＬＯＷアクティ
ブ）上でワイアＯＲが取られ、集約アービトレーション
・コードが得られる。次にこの３２ビットの集約コード
がチェックされ、アクティブなビットの個数が求められ
る。１ビットしかアクティブでない場合、バスの保有権
を対応するモジュールに引き渡すことができる。ビット
が２個以上アクティブなら、通常のアービトレーション
方式が用いられる。ただし、このコードをチェックして
アクティブなビットの個数を求めるには、かなりのロジ
ックが必要である。このロジックは普通、駆動／シンク
電流の大きいオープン・コレクタ・バイポーラである。
多数の比較器が必要である。コードを供給するには３２
ビットのデータ・バス全体が必要なので、エラーの検出
は、不可能ではないとしても困難である。

【００１２】競合する各モジュールに望ましいコードは
次のようになる。

【００１３】物理ＩＤの各論理０について“０１”をバ
スに出力する。次に、物理ＩＤの各論理１について“１
０”をバスに出力する。

【００１４】これにより物理モジュールＩＤの真補が得
られる。競合に参加しないモジュールはバスのどのライ
ンも活動化しない。結果として、５ビットの物理ＩＤの
場合、１０ビットの単独競合モジュール・アービトレー
ション・コードが得られる。以下にこのアービトレーシ
ョン・コードを示す。

【００１５】 表１ アービトレーション・コード例 モジュールＩＤ アービトレーション・コード （４．．．０） （９．．．．．．０） ０００００ ０１０１０１０１０１ ００００１ ０１０１０１０１１０ ０００１０ ０１０１０１１００１ ０００１１ ０１０１０１１０１０ ００１００ ０１０１１００１０１ ．．． ．．． １１１００ １０１０１００１０１ １１１０１ １０１０１００１１０ １１１１０ １０１０１０１００１ １１１１１ １０１０１０１０１０ 集約アービトレーション・コードはバスのワイアＯＲに
よって生成される。たとえば２つのモジュールが競合し
ていて、モジュール０のモジュールＩＤがＭＩＤ＝００
０００、モジュール１がＭＩＤ＝００００１とすると、
得られる集約コードは表２に示すように０１０１０１０
１００になる。

【００１６】 表２ 集約コードのワイアＯＲ モジュール ０出力 ０１０１０１０１０１ モジュール １出力 ０１０１０１０１１０ 集約コード ＝ ０１０１０１０１００ 次式を満たす集約アービトレーション・コードからチェ
ック・コードが導かれる。

【００１７】 ○ チェック・コード（４）＝集約コード（９）＋集約コード（８） （＋ ＝ 論理ＯＲ） ○ チェック・コード（３）＝集約コード（７）＋集約コード（６） ○ チェック・コード（２）＝集約コード（５）＋集約コード（４） ○ チェック・コード（１）＝集約コード（３）＋集約コード（２） ○ チェック・コード（０）＝集約コード（１）＋集約コード（０） チェック・コードに０があれば、バスを競っているモジ
ュールは２個以上である。バスの制御を決定するには通
常のアービトレーション・シーケンスが必要である。チ
ェック・コードの内容がすべて１であれば、バスの制御
は単独で競うモジュールに渡される。表３にモジュール
２個が競い合うときのアービトレーションの結果を、表
４にモジュール１個が競うときのアービトレーションの
結果を示す。表４のチェック・コードはすべて１に等し
いことに注意されたい。

【００１８】 表３ ２モジュール競合 モジュール０コード ＝ ０１０１０１０１０１ モジュール１コード ＝ ０１０１０１０１１０ 集約コード ＝ ０１０１０１０１００ チェック・コード ＝ １ １ １ １ ０ 表４ １モジュール競合 モジュール６コード ＝ ０１０１１０１００１（ＭＩＤ＝００１１０） 集約コード ＝ ０１０１１０１００１ チェック・コード ＝ １ １ １ １ １ この方式では、保有権が８サイクルではなく２サイクル
で割り振られる。このコードをチェックするロジック
は、３２から１つを取るコード・アプローチに比べてか
なりシンプルであり、チップ面積、配線もかなり少なく
てすむ。図２は、２サイクル・アービトレーション・コ
ードのクロック・ステップ・シーケンスである。ステッ
プＡでは、競合するモジュールがすべて、その物理ロケ
ーションＩＤの真補であるアイドル・バス・コード（Ｉ
ＢＣ）を送出（確約）する。ステップＢでは、モジュー
ルがすべて、バスから集約（ワイアＯＲ）アイドル・バ
ス・コードを受け取った後にチェック・コードを計算す
ることによって、競合するモジュールの個数を判定す
る。競合するモジュール数が１に等しいなら、優先する
モジュールは決まっており、競合は終了する。したがっ
てステップＣではバス状態がＨ０となり、これは最初の
メッセージの先頭の０を表す。優先されるモジュールは
そのメッセージの転送を始める。

【００１９】この発明のもう１つの特徴は、コードがコ
ンパクトであるため、３２ビット・バス上で２重化ある
いは３重化でき、エラーの検出または訂正が可能という
ことである。すなわち競合するモジュールのアービトレ
ーション・コードに必要なのは１０ビットだけである。
３２ビットのデータ・バスでは、このアービトレーショ
ン・コードの２重化を３回行うことができる。これは１
／３２コード・アプローチでは不可能である。使用でき
るデータ・バス・ラインがすべて、コードを供給するの
に用いられるからである。エラーの検出はエラー・コー
ドを生成することによって行える。エラー・コードの式
は次のようになる。

【００２０】 ○ エラー・コード（４）＝集約コード（９）＆集約コード（８） （＆ ＝ 論理ＡＮＤ） ○ エラー・コード（３）＝集約コード（７）＆集約コード（６） ○ エラー・コード（２）＝集約コード（５）＆集約コード（４） ○ エラー・コード（１）＝集約コード（３）＆集約コード（２） ○ エラー・コード（０）＝集約コード（１）＆集約コード（０） エラー・コードに１があれば、エラーが発生したとみな
すことができる。対になった集約コード・ビットの各々
が“１１”の組み合わせを含むことはないからである。
表５にエラー・コードの例を示す。

【００２１】 表５ エラー・コード例 集約コード ＝ ０１０１１０１０１１（このコードに該当するＭＩＤは ない） エラー・コード ＝ ０ ０ ０ ０ １ 単独競合モジュールのアービトレーション・コードは多
種多様なバス・プロトコルに適用することができる。こ
のコードをインプリメントして、現在の共通バス・プロ
トコルを拡張あるいはエンハンスすることができる。

【図面の簡単な説明】

【図１】３２個のモジュールが接続された共通バスの図
である。

【図２】単独競合モジュールのアービトレーション・コ
ードを決定するバス・クロックのタイミング図である。

Claims (4)

(57)【特許請求の範囲】
1. 【請求項１】共通データ・バスに接続された競合する通
   信モジュール間の単独競合モジュール・アービトレーシ
   ョンの方法であって、 競合する通信モジュールのモジュールＩＤの各ビットの
   ２進値を０１及び１０でコード化して形成されるアービ
   トレーション・コードを生成するステップと、上記アー
   ビトレーション・コードを競合する通信モジュールから
   上記共通データ・バスに送出するステップと、 送出されたアービトレーション・コードの同位のビット
   を論理的に集約した集約コードを生成するステップと、 上記集約コードの隣接２ビットの論理的組合せより成る
   チェック・コードを生成するステップと、 上記チェック・コードのビット・パターンに従って、競
   合する通信モジュールの個数が１であるかどうかを判定
   するステップとを含む、 アービトレーション方法。
2. 【請求項２】上記共通データ・バスに２つの上記アービ
   トレーション・コードが同時に送出される、請求項１記
   載のアービトレーション方法。
3. 【請求項３】上記集約コードの隣接２ビットの論理ＡＮ
   Ｄを取ることによってエラー・コードが生成される、請
   求項１記載のアービトレーション方法。
4. 【請求項４】共通バスを有し、競合するデータ・モジュ
   ール間に単独競合モジュールのアービトレーション・コ
   ードを使用する通信システムであって、 競合する通信モジュールのモジュールＩＤの各ビットの
   ２進値を０１及び１０でコード化して形成されるアービ
   トレーション・コードを生成する手段と、 上記アービトレーション・コードを競合する通信モジュ
   ールから上記共通データ・バスに送出する手段と、 送出されたアービトレーション・コードの同位のビット
   を論理的に集約した集約コードを生成する手段と、 上記集約コードの隣接２ビットの論理的組合せより成る
   チェック・コードを生成する手段と、 上記チェック・コードのビット・パターンに従って、競
   合する通信モジュールの個数が１であるかどうかを判定
   する手段とを含み、 よって単独で競うモジュールに上記バスへのアクセスが
   与えられる、 通信システム。