JP3747020B2 - クロスバー調停システム - Google Patents
クロスバー調停システム Download PDFInfo
- Publication number
- JP3747020B2 JP3747020B2 JP2002263058A JP2002263058A JP3747020B2 JP 3747020 B2 JP3747020 B2 JP 3747020B2 JP 2002263058 A JP2002263058 A JP 2002263058A JP 2002263058 A JP2002263058 A JP 2002263058A JP 3747020 B2 JP3747020 B2 JP 3747020B2
- Authority
- JP
- Japan
- Prior art keywords
- request
- arbitration
- buffer
- ownership
- port
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Multi Processors (AREA)
- Bus Control (AREA)
- Information Transfer Systems (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、クロスバー調停システムに関し、特に、複数のリクエスト型式に柔軟に対応できるクロスバー調停システムに関する。
【０００２】
【従来の技術】
従来の特許文献１記載の技術は、リクエスト調停手段が、送受信のリクエストを受け付ける緩衝バッファのみを持ち、リクエストに対する通信の許可を確認した段階でネットワークへのデータの送出を開始することでデータ蓄積用の緩衝バッファを不要とし、クラスタ数の増加に伴う緩衝バッファの増加分の削減を図るものである。また、この技術は、データ転送元クラスタとデータ転送先クラスタとの間で一定期間データパスを占有しデータ転送する方式とし、リクエスト調停手段がデータパスの空き状況を管理し、クラスタ間のデータ転送を行う時、データパス間の競合は発生しないようにし、緩衝バッファ量の削減を可能としている。
【０００３】
この技術は、さらに、データ転送要求をしている間にデータ転送要求元の自クラスタ内のメモリからデータをロードし、転送許可が通知された場合に即座に他クラスタへのデータ転送を開始することで、効率よくデータ転送を行うことを可能としている。
【０００４】
【特許文献１】
特開２００１−２０９６２６号公報
【０００５】
【発明が解決しようとする課題】
上述した特許文献１記載の技術においては、以下のような「先頭フレームが到着したら調停に参加する方法（リクエスト型式）」、「リクエストの全フレームの到着を待ち合わせてから調停参加する方法（リクエスト型式）」を混在制御する構成になっていないので、性能が向上しないという問題がある。
【０００６】
従来の技術のクロスバー調停では、各ポートから入力された非連続な複数フレームから成るリクエストを調停して送信先へ送信する時、性能を重視してリクエストの先頭フレームが到着したら調停に参加する方法が採用される。しかし、この方法では後続フレームが調停後すぐに受け付けられるのか、あるいはまだ受信できていないのか、といった状態を判断することができず、リクエストが分断して後続フレームの受信待ち状態となる受信ポートが存在すると調停中であるリクエストを完了できずに調停途中のままデッドロックする可能性がある。
【０００７】
一方、リクエストの分断する可能性がある受信ポートを救済するためにリクエストの全フレームの到着を待ち合わせてから調停参加する方法を採用すると、本来リクエスト分断の可能性がない受信ポートも待ち合わせをすることになり性能が低下してしまう。また、前記２つの方法に共通して、送信ポートのビジー等により調停がリクエスト処理途中で停止すると、後続リクエストが他の送信先であった場合に直接関係のない調停処理中リクエストの影響で調停参加が待たされてしまうという欠点がある。
【０００８】
本発明の目的は、調停参加に際してリクエストの最初のフレーム到着で調停参加する方法とリクエストの全フレームの到着を保証してから調停参加する方法の何れかをリクエストの特性に応じてポート単位に任意選択可能な手段と、調停後の経路上にリクエストを構成する最大フレーム数の登録を保証する緩衝バッファとを設けることによって前記欠点を解決することである。
【０００９】
【課題を解決するための手段】
本発明の第１のクロスバー調停システムは、複数の受信ポートから複数の送信ポートの何れかに対して複数個のフレームにより構成されるリクエストを転送するクロスバー調停システムであって、
リクエストのクロスバー調停システムへの調停参加に際してリクエストの最初のフレーム到着で調停参加する第１のリクエスト形式とリクエストの全フレームの到着を保証してから調停参加する第２のリクエス形式との何れかによる調停参加を、リクエスト元となるポート単位に選択可能な第１の手段と、前記第１の手段により選択されたリクエスト形式が第１のリクエスト形式の場合はリクエストの最初のフレーム到着で調停を行い、第２のリクエスト形式の場合はリクエストの全フレームの到着を保証してから調停を行う第２の手段と、前記第２の手段による調停後の経路上に設置され、リクエストを構成する最大フレーム数の登録を保証して前記第２の手段により調停され出力されたリクエストの全フレームを登録可能にする緩衝バッファとを有する。
【００１０】
本発明の第２のクロスバー調停システムは、受信ポートからのフレームで構成されるリクエストを格納する受信ポート対応のリクエストバッファと、
前記受信ポートごとに調停参加に際してリクエストの最初のフレーム到着で調停参加する第１のリクエスト型式とリクエストの全フレームの到着を保証してから調停参加する第２のリクエスト型式との何れかを示す値が外部から設定される前記リクエストバッファ対応の調停方法選択回路と、
前記調停方法選択回路からの前記受信ポートごとの値に基づいて、値が第１のリクエスト形式を示せば、前記リクエストバッファからのリクエストの最初のフレーム到着でそのリクエストの調停参加のための調停要求を出し、値が第２のリクエスト形式を示せば、前記リクエストバッファからのリクエストの全フレームの到着を保証してからそのリクエストの調停参加のための調停要求を出す前記リクエストバッファ対応のリクエスト要求生成回路と、
前記リクエスト要求生成回路からの調停要求によりオーナー権を判定しオーナー権を獲得した受信ポートを示す値を出力する送信ポート対応の調停オーナー権判定回路と、
前記調停オーナー権判定回路からのオーナー権を獲得した受信ポートを示す値を保持する送信ポート対応の調停オーナー権保持レジスタと、
前記調停オーナー権保持レジスタからのオーナー権を獲得した受信ポートを示す値により前記受信ポート対応のリクエストバッファからのリクエストを選択する送信ポート対応の調停回路とを有する。
【００１１】
本発明の第３のクロスバー調停システムは、受信ポートからのフレームで構成されるリクエストを格納する受信ポート対応のリクエストバッファと、
前記受信ポートごとに調停参加に際してリクエストの最初のフレーム到着で調停参加する第１のリクエスト型式とリクエストの全フレームの到着を保証してから調停参加する第２のリクエスト型式との何れかを示す値が外部から設定される前記リクエストバッファ対応の調停方法選択回路と、
前記調停方法選択回路からの前記受信ポートごとの値に基づいて、値が第１のリクエスト形式を示せば、前記リクエストバッファからのリクエストの最初のフレーム到着でそのリクエストの調停参加のための調停要求を出し、値が第２のリクエスト形式を示せば、前記リクエストバッファからのリクエストの全フレームの到着を保証してからそのリクエストの調停参加のための調停要求を出す前記リクエストバッファ対応のリクエスト要求生成回路と、
前記リクエスト要求生成回路からの調停要求によりオーナー権を判定しオーナー権を獲得した受信ポートを示す値を出力する送信ポート対応の調停オーナー権判定回路と、
前記調停オーナー権判定回路からのオーナー権を獲得した受信ポートを示す値を保持する送信ポート対応の調停オーナー権保持レジスタと、
前記調停オーナー権保持レジスタからのオーナー権を獲得した受信ポートを示す値により前記受信ポート対応のリクエストバッファからのリクエストを選択する送信ポート対応の調停回路と、
前記送信ポート対応の調停回路からのリクエストの最大数のフレームを格納する送信ポート対応の緩衝バッファとを有する。
【００１２】
本発明の第４のクロスバー調停システムは、受信ポートからのフレームで構成されるリクエストを格納する受信ポート対応のリクエストバッファと、
前記受信ポートごとに調停参加に際してリクエストの最初のフレーム到着で調停参加する第１のリクエスト型式とリクエストの全フレームの到着を保証してから調停参加する第２のリクエスト型式との何れかを示す値が外部から設定される前記リクエストバッファ対応の調停方法選択回路と、
リクエストを構成するフレームのうち最終フレームを前記リクエストバッファに登録すると１加算され、調停によりリクエストが読み出されると１減算される前記リクエストバッファ対応の最終フレーム数監視カウンタと、
前記調停方法選択回路からの前記受信ポートごとの値に基づいて、値が第１のリクエスト形式を示せば、前記リクエストバッファからのリクエストの最初のフレーム到着でそのリクエストの調停参加のための調停要求を出し、値が第２のリクエスト形式を示せば、前記最終フレーム数監視カウンタの値を参照し、前記リクエストバッファからのリクエストの全フレームの到着を保証してからそのリクエストの調停参加のための調停要求を出す前記リクエストバッファ対応のリクエスト要求生成回路と、
前記リクエスト要求生成回路からの調停要求によりオーナー権を判定しオーナー権を獲得した受信ポートを示す値を出力する送信ポート対応の調停オーナー権判定回路と、
前記調停オーナー権判定回路からのオーナー権を獲得した受信ポートを示す値を保持する送信ポート対応の調停オーナー権保持レジスタと、
前記調停オーナー権保持レジスタからのオーナー権を獲得した受信ポートを示す値により前記受信ポート対応のリクエストバッファからのリクエストを選択する送信ポート対応の調停回路と、
前記送信ポート対応の調停回路からのリクエストの最大数のフレームを格納する送信ポート対応の緩衝バッファとを有する。
【００１３】
本発明の第５のクロスバー調停システムは、受信ポートからのフレームで構成されるリクエストを格納し、リクエストの先頭フレームの場合にリクエスト先頭フレーム識別信号を出力する受信ポート対応のリクエストバッファと、
前記受信ポートごとに調停参加に際してリクエストの最初のフレーム到着で調停参加する第１のリクエスト型式とリクエストの全フレームの到着を保証してから調停参加する第２のリクエスト型式との何れかを示す値が外部から設定される前記リクエストバッファ対応の調停方法選択回路と、
リクエストを構成するフレームのうち最終フレームを前記リクエストバッファに登録すると１加算され、調停によりリクエストが読み出されると１減算される前記リクエストバッファ対応の最終フレーム数監視カウンタと、
前記調停方法選択回路に第２のリクエスト型式を示す値が設定されている場合は、前記最終フレーム数監視カウンタの値が０より大きく、かつ、リクエスト先頭フレーム識別信号が通知されると前記リクエストバッファからのリクエストの調停参加のための調停要求を出し、前記調停方法選択回路に第１のリクエスト型式を示す値が設定されている場合は、リクエスト先頭フレーム識別信号が通知されると前記リクエストバッファからのリクエストの調停参加のための調停要求を出す前記リクエストバッファ対応のリクエスト要求生成回路と、
前記リクエスト要求生成回路からの調停要求によりオーナー権を判定しオーナー権を獲得した受信ポートを示す値を出力する送信ポート対応の調停オーナー権判定回路と、
前記調停オーナー権判定回路からのオーナー権を獲得した受信ポートを示す値を保持する送信ポート対応の調停オーナー権保持レジスタと、
前記調停オーナー権保持レジスタからのオーナー権を獲得した受信ポートを示す値により前記受信ポート対応のリクエストバッファからのリクエストを選択する送信ポート対応の調停回路と、
前記送信ポート対応の調停回路からのリクエストの最大数のフレームを格納する送信ポート対応の緩衝バッファとを有する。
【００１４】
本発明の第６のクロスバー調停システムは、受信ポートからのフレームで構成されるリクエストを格納し、リクエストの先頭フレームの場合にリクエスト先頭フレーム識別信号を出力する受信ポート対応のリクエストバッファと、
前記受信ポートごとに調停参加に際してリクエストの最初のフレーム到着で調停参加する第１のリクエスト型式とリクエストの全フレームの到着を保証してから調停参加する第２のリクエスト型式との何れかを示す値が外部から設定される前記リクエストバッファ対応の調停方法選択回路と、
リクエストを構成するフレームのうち最終フレームを前記リクエストバッファに登録すると１加算され、調停によりリクエストが読み出されると１減算される前記リクエストバッファ対応の最終フレーム数監視カウンタと、
前記調停方法選択回路に第２のリクエスト型式を示す値が設定されている場合は、前記最終フレーム数監視カウンタの値が０より大きく、かつ、リクエスト先頭フレーム識別信号が通知されると前記リクエストバッファからのリクエストの調停参加のための調停要求を出し、前記調停方法選択回路に第１のリクエスト型式を示す値が設定されている場合は、リクエスト先頭フレーム識別信号が通知されると前記リクエストバッファからのリクエストの調停参加のための調停要求を出す前記リクエストバッファ対応のリクエスト要求生成回路と、
前記リクエスト要求生成回路からの調停要求、オーナー権の判定・停止要求信号によりオーナー権を判定しオーナー権を獲得した受信ポートを示す値を出力する送信ポート対応の調停オーナー権判定回路と、
前記調停オーナー権判定回路からのオーナー権を獲得した受信ポートを示す値を保持する送信ポート対応の調停オーナー権保持レジスタと、
前記調停オーナー権保持レジスタからのオーナー権を獲得した受信ポートを示す値により前記受信ポート対応のリクエストバッファからのリクエストを選択する送信ポート対応の調停回路と、
前記送信ポート対応の調停回路からのリクエストの最大数のフレームを格納する送信ポート対応の緩衝バッファと、
前記調停回路が送出したフレームが前記緩衝バッファに登録される毎に１加算され次の登録位置を示す緩衝バッファ登録ポインタと、
前記緩衝バッファからフレームが読み出される毎に１加算され次の読み出し位置を示す緩衝バッファ索引ポインタと、
前記緩衝バッファに対して、最大登録数から予め存在しうるリクエストの最大フレーム数を減じた値が外部から設定される緩衝バッファ閾値レジスタと、
前記緩衝バッファ登録ポインタの値、緩衝バッファ索引ポインタの値、緩衝バッファ閾値レジスタの値に基づいて前記調停オーナー権判定回路にオーナー権の判定・停止要求信号を出力する前記緩衝バッファ対応の緩衝バッファ空き容量判定回路とを有することを特徴とするクロスバー調停システム。
【００１５】
【発明の実施の形態】
次に、本発明の実施の形態について図面を参照して詳細に説明する。
【００１６】
ネットワーク等で用いられるクロスバーでは、各ポートから入力された非連続な複数フレームから成るリクエストを調停して送信先へ送信する時、通常は性能を重視してリクエストの先頭フレームが到着したら調停に参加する方法が採用される。しかし、この方法では後続フレームが調停後すぐに受け付けられるのか、あるいはまだ受信できていないのか、といった状態を判断することができず、リクエストが分断して後続フレームが到着しなくなるような受信ポートが存在すると調停中であるリクエストを完了できずに調停途中のままデッドロックする可能性がある。
【００１７】
一方、リクエストの分断する可能性がある受信ポートを救済するためにリクエストの全フレームの到着を待ち合わせてから調停参加する方法を採用すると、本来リクエスト分断の可能性がない受信ポートも待ち合わせをすることになり性能が低下してしまう。また、前記２つの方法に共通して、送信ポートのビジー等により調停がリクエスト処理途中で停止すると、後続リクエストが他の送信先であった場合に直接関係のない調停処理中リクエストの影響で調停参加が待たされてしまう欠点がある。よって、クロスバーでは受信ポートの特性に応じて前記２つの方法を使い分けることが重要であるが、本発明は、調停参加に際してリクエストの最初のフレーム到着で調停参加する方法とリクエストの全フレームの到着を保証してから調停参加する方法の何れかをリクエストの特性に応じてポート単位に任意選択設定可能な手段と、調停後の経路上にリクエストを構成する最大フレーム数の登録を保証する緩衝手段とを設けることによって前記欠点を解決する。
【００１８】
図１は、本発明の実施の形態の構成を示すブロック図である。
【００１９】
図１を参照すると、本発明の実施の形態は、受信ポート０、受信ポート１、受信ポート２、…、受信ポートｎ毎にリクエストを受信して調停に参加する受信ポート０、受信ポート１、受信ポート２、…、受信ポートｎのリクエストを格納するリクエストバッファ０００、リクエストバッファ１００、リクエストバッファ２００、…、リクエストバッファｎ００と、調停への参加方法を選択する受信ポート０、受信ポート１、受信ポート２、…、受信ポートｎの調停方法選択回路００４、調停方法選択回路１０４、調停方法選択回路２０４、調停方法選択回路ｎ０４と、送信ポート０、送信ポート１、送信ポート２、…、送信ポートｎ毎に受信ポート０、受信ポート１、受信ポート２、…、受信ポートｎからのリクエスト調停を行う送信ポート０、送信ポート１、送信ポート２、…、送信ポートｎの調停回路００１、調停回路１０１、調停回路２０１、…、調停回路ｎ０１と、調停する時にはリクエストを構成する全フレームの登録を保証する送信ポート０、送信ポート１、送信ポート２、…、送信ポートｎの緩衝バッファ００２、緩衝バッファ１０２、緩衝バッファ２０２、…、緩衝バッファｎ０２と、リクエストを外部に送信し、送信不可の時は緩衝バッファ００２、緩衝バッファ１０２、緩衝バッファ２０２、…、緩衝バッファｎ０２の読み出しを停止する送信ポート０、送信ポート１、送信ポート２、…、送信ポートｎの出力制御部００３、出力制御部１０３、出力制御部２０３、…、出力制御部ｎ０３とから構成される。
【００２０】
図１に示す（ｎ＋１）ポート×（ｎ＋１）ポートのクロスバーは、受信ポート０、受信ポート１、受信ポート２、…、受信ポートｎのリクエストバッファ０００、リクエストバッファ１００、リクエストバッファ２００、…、リクエストバッファｎ００が受信する複数個のフレームから成るリクエストを、送信ポート０、送信ポート１、送信ポート２、…、送信ポートｎ毎に調停回路００１、調停回路１０１、調停回路２０１、…、調停回路ｎ０１で調停する機能を備えており、緩衝バッファ００２、緩衝バッファ１０２、緩衝バッファ２０２、…、緩衝バッファｎ０２は、調停の際にリクエストの最大フレーム数の登録を保証し、登録できない場合にはリクエスト単位で調停動作を停止する機能を備える。
【００２１】
送信ポート０、送信ポート１、送信ポート２、…、送信ポートｎの出力制御部００３、出力制御部１０３、出力制御部２０３、…、出力制御部ｎ０３は、それぞれ、緩衝バッファ００２、緩衝バッファ１０２、緩衝バッファ２０２、緩衝バッファｎ０２より受け取ったリクエストを外部に送信可能かどうかを監視し、送信できない場合はビジーによって緩衝バッファ００２、緩衝バッファ１０２、緩衝バッファ２０２、緩衝バッファｎ０２からの読み出しを停止する。
【００２２】
受信ポート０、受信ポート１、受信ポート２、…、受信ポートｎの調停方法選択回路００４、調停方法選択回路１０４、調停方法選択回路２０４、…、調停方法選択回路ｎ０４には、それぞれ受信ポートの特性に応じてリクエストを構成する全フレームの到着を保証してから調停参加する方法（以下、方法Ａと呼ぶ）と、リクエストの最初のフレーム到着で調停参加を開始する方法（以下、方法Ｂと呼ぶ）とを示す値が、キーボード等外部操作により選択して設定される。
【００２３】
方法Ａは、障害等によるリクエスト分断で、調停が解除されなくなるデッドロックの回避を想定し、確実なリクエスト送信を必要とするポートに設定し、方法Ｂはリクエスト分断の可能性がなく性能を重視したいポートに設定される。
【００２４】
次に、本発明の実施の形態の動作について図面を参照して説明する。
【００２５】
受信ポート０のリクエストバッファ０００に対して調停方法選択回路００４が方法Ａを、受信ポート１のリクエストバッファ１００に対して調停方法選択回路１０４が方法Ｂをそれぞれ選択し、共に送信ポート２の調停回路２０１へ調停参加するケースについて説明する。方法Ａのリクエストバッファ０００は外部から受信するリクエストを格納するが、リクエストが分断しないようにリクエストを構成する非連続なフレームの全ての到着を待ち合わせてから調停回路２０１に調停要求を行うように調停方法選択回路１０４で制御される。
【００２６】
調停回路２０１は、リクエストバッファ０００からのリクエストの調停要求を受け付けて一旦調停動作に入ると、リクエストバッファ０００内に既に格納済みのリクエストの全フレームを連続して調停処理し、送信ポート２の緩衝バッファ２０２へ登録を完了させる。緩衝バッファ２０２はリクエストを構成する最大フレーム数の登録を保証するだけの空き容量が確保しているため、調停したリクエストの全フレームを登録しても緩衝バッファ２０２が溢れることはない。すなわち、緩衝バッファ２０２の空き容量がリクエストを構成する最大フレーム数分の容量に満たない場合には、調停回路２０１は、リクエストを受け付けず、調停を行わない。
【００２７】
よって、調停回路２０１は、リクエスト単位で動作し、調停したリクエストのフレーム数に等しい占有時間で必ず解放されるので、出力制御部２０３がリクエストを送信できずにビジーとなって緩衝バッファ２０２からの読み出しを停止し、これを受けて緩衝バッファ２０２が空き容量不足で調停停止するような場合でも、調停回路２０１を占有し続けることはない。すなわち、調停回路２０１でリクエスト分断により調停が解除されなくなる可能性を排除しデッドロックを回避できることになる。
【００２８】
さらに詳細に、本発明の実施の形態の動作について図面を参照して説明する。
【００２９】
図２は、本発明の実施の形態の動作を示すブロック図である。
【００３０】
図２を参照すると、リクエストバッファ０００が調停要求したポート０→２リクエストＲ０２（受信ポート０から送信ポート２へのリクエスト）が、調停回路２０１で受け付けられて、緩衝バッファ２０２に格納される。緩衝バッファ２０２には、すでに緩衝バッファ２０２に滞在中のリクエストＲ０１があり、読み出しを待たされているとする。緩衝バッファ２０２は、調停回路２０１で調停された新たなポート０→２リクエストＲ０２を格納したことで、空き容量がリクエストの最大フレーム数分の容量に満たなくなり、緩衝バッファ２０２への登録後に調停回路２０１へのリスエスとの受け付けを停止する。
【００３１】
この時、ポート０→２リクエストＲ０２は、全フレームを緩衝バッファ２０２へ登録完了されているため、リクエストバッファ０００に、送信ポート２以外へ送信するリクエスト、たとえば、ポート０→１リクエストＲ０３（受信ポート０から送信ポート１へのリクエスト）が存在する場合、ポート０→１リクエストＲ０３は、停止している調停回路２０１の影響を受けずに調停回路１０１へ調停参加することが可能となる。
【００３２】
一方、性能を重視してリクエストの先頭フレームが到着したら調停に参加する方法Ｂを方法Ａと混在してポート単位に任意指定し制御可能にする。
【００３３】
たとえば、受信ポート１のリクエストバッファ１００は、調停方法選択回路１０４により、性能を重視した最速なフレーム送信のためにリクエストの先頭フレーム到着で調停回路２０１に調停参加するが、調停要求を受けて調停を開始すると、リクエストを構成する全フレームを緩衝バッファ２０２に登録するまで調停を占有する。
【００３４】
この時、調停回路２０１は、リクエストの全フレームが保証されているかは意識せずに調停したフレームを緩衝バッファ２０２に登録するだけでよく、各フレームが連続であれば最速で緩衝バッファ２０２に登録できる。仮にフレーム間で間隔が空いたとしてもポート１は、リクエスト分断の可能性がないポートであり必ず全フレームが到着するので、調停回路２０１は方法Ａと方法Ｂとを何ら変わりなく調停することができ、また、前記二つの調停方法をポート単位に任意選択設定してリクエストの特性に応じた混在調停をすることができる。
【００３５】
次に、調停の制御について図面を参照して詳細に説明する。
【００３６】
図３は、受信ポート０から送信ポート２への調停の制御を示す説明図である。
【００３７】
図３を参照すると、受信ポート０に対応して、調停方法選択回路００４、最終フレーム数監視カウンタ０１０、リクエスト要求生成回路０１１が設けられる。また、送信ポート２に対応して、調停オーナー権判定回路２１２、調停オーナー権保持レジスタ２１３、緩衝バッファ登録ポインタ２１４、緩衝バッファ索引ポインタ２１５、緩衝バッファ閾値レジスタ２１６、緩衝バッファ空き容量判定回路２１７が設けられる。
【００３８】
まず、調停方法選択回路００４に、方法Ａが設定された場合の動作について説明する。
【００３９】
リクエストバッファ０００は、リクエストを構成する非連続なフレームの待ち合わせを監視するために最終フレーム数監視カウンタ０１０を装備する。最終フレーム数監視カウンタ０１０は、リクエストを構成するフレームのうち最終フレームをリクエストバッファ０００に登録すると＋１され、調停によりリクエストが読み出されると−１される。
【００４０】
すなわち、最終フレーム数監視カウンタ０１０の値が０より大きい場合、リクエストバッファ０００には全フレームを待ち合わせ、かつ、登録完了したリクエストが少なくとも１つ以上はあることになる。リクエストバッファ０００は、最初の読み出しフレームがリクエストの先頭フレームの場合に、リクエスト先頭フレーム識別信号０１２をリクエスト要求生成回路０１１に通知し、調停による読み出しを待ち合わせる。リクエスト要求生成回路０１１は、調停方法選択回路００４に方法Ａが設定されており、かつ、最終フレーム数監視カウンタ０１０が、０より大きい場合に、リクエスト先頭フレーム識別信号０１２が通知されたならば、調停オーナー権判定回路２１２に対して調停要求を行う。
【００４１】
調停オーナー権判定回路２１２は、単数、または、複数の受信ポートより受信した調停要求をもとに調停オーナー権を判定し、調停オーナー権保持レジスタ２１３にセットする。たとえば、調停オーナー権判定回路２１２が、受信ポート０の調停オーナー権を獲得し、調停オーナー権保持レジスタ２１３に受信ポート０に対応する値をセットすると、リクエストバッファ０００からリクエストフレームの読み出しを開始し、調停回路２０１によって緩衝バッファ２０２へ送出するとともに、最終フレーム数監視カウンタ０１０を−１する。
【００４２】
調停オーナー権保持レジスタ２１３、および、調停回路２０１によりリクエストは構成する全フレームが読み出されるが、最終フレームを読み出した際に調停オーナー権保持レジスタ２１３をリセットするので、リクエストバッファ０００には、次のリクエストの先頭フレームが待機可能となり、次の調停要求動作に遷移できる。
【００４３】
図４は、方法Ａの動作を示すタイミングチャートである。
【００４４】
図４を参照すると、サイクルＴ１、Ｔ２、Ｔ４、Ｔ６と非連続で受け付けたリクエストのフレーム（先頭フレーム＝先、第２フレーム＝２、第３フレーム＝３、第４フレーム＝４）は、それぞれ、サイクルＴ２、Ｔ３、Ｔ５、Ｔ７においてリクエストバッファ０００に登録される。リクエスト先頭フレーム識別信号０１２は、リクエストバッファ０００の最初の読み出しフレームがリクエストの先頭フレームである場合に有効となり、そのリクエストの最終フレーム（＝第４フレーム）の到着まで待ち合わせを行っている。
【００４５】
サイクルＴ７において、最終フレームがリクエストバッファ０００に登録されると、最終フレーム数監視カウンタ０１０が＋１されて、一つのリクエストがリクエストバッファ０００に揃ったことを示し、リクエスト要求生成回路０１１が、調停要求を開始する。更に、同サイクルＴ７において、調停オーナー権判定回路２１２が調停オーナー権を獲得すると、サイクルＴ８において、調停オーナー権保持レジスタ２１３に受信ポート０に対応する値をセットすることで、調停回路２０１が調停オーナー権を獲得した受信ポート０のリクエストを選択できるように固定され、サイクルＴ８、Ｔ９、Ｔ１０、Ｔ１１において、連続でリクエストフレームを読み出す。
【００４６】
調停オーナー権保持レジスタ２１３をセットした後のサイクルＴ９においては、最終フレーム数監視カウンタ０１０が−１され、調停回路２０１が最終フレームを送出した後のサイクルＴ１２においては、調停オーナー権保持レジスタ２１３がリセットされる。
【００４７】
次に、図３を参照して、調停方法選択回路００４に方法Ｂを設定した時の動作について説明する。
【００４８】
方法Ｂでは、最終フレーム数監視カウンタ０１０を無効化し、リクエスト要求生成回路０１１は、リクエスト先頭フレーム識別信号０１２のみによって調停要求を行う。調停オーナー権判定回路２１２は、単数、または、複数の受信ポートより受信した調停要求をもとに調停オーナー権を判定し、調停オーナー権保持レジスタ２１３にセットする。たとえば、調停オーナー権判定回路２１２が受信ポート０の調停オーナー権を獲得し調停オーナー権保持レジスタ２１３にセットすると、リクエストバッファ０００からリクエストフレームの読み出しを開始し調停回路２０１によって緩衝バッファ２０２へ送出する。
【００４９】
調停オーナー権保持レジスタ２１３、および、調停回路２０１によりリクエストは構成する全フレームを読み出すが、方法Ｂにおいては、リクエストを構成する全フレームがリクエストバッファ０００に到着しているとは限らないので到着するまでの間も調停オーナー権保持レジスタ２１３を保持し続けていて、最終フレームがリクエストバッファ０００に到着し、調停回路２０１を経て緩衝バッファ２０２への送出が完了した時点でリセットする。リクエストバッファ０００の最初の読み出しフレームに再び次のリクエストの先頭フレームが到着すると、すぐに次の調停要求動作に遷移する。
【００５０】
図５は、方法Ｂの動作を示すタイミングチャートである。
【００５１】
図５を参照すると、サイクルＴ１、Ｔ２、Ｔ４、Ｔ７において非連続で受け付けたリクエストのフレーム（先頭フレーム＝先、第２フレーム＝２、第３フレーム＝３、第４フレーム＝４）は、それぞれサイクルＴ２、Ｔ３、Ｔ５、Ｔ８において、リクエストバッファ０００に登録される。リクエスト先頭フレーム識別信号０１２は、リクエストバッファ０００の最初の読み出しフレームがリクエストの先頭フレームである場合に有効となり、サイクルＴ２において、リクエスト要求生成回路０１１がそのリクエストの最終フレーム（＝第４フレーム）の到着を待たずに調停要求を開始する。
【００５２】
更に、サイクルＴ２において、調停オーナー権判定回路２１２が調停オーナー権を獲得すると、調停オーナー権保持レジスタ２１３に受信ポート０に対応する値をセットすることで、調停回路２０１が調停オーナー権を獲得した受信ポート０のリクエストを選択できるよう固定され、サイクルＴ３、Ｔ４、Ｔ５、Ｔ８においてリクエストフレームをその到着サイクルに依存して非連続に読み出す。調停回路２０１が最終フレームを送出した後のサイクルＴ９においては、調停オーナー権保持レジスタ２１３がリセットされる。
【００５３】
次に、緩衝バッファ２０２の動作について図３を用いて説明する。
【００５４】
たとえば、緩衝バッファ２０２に対して、その最大登録数から予め存在しうるリクエストの最大フレーム数を減じた値がキーボード等外部操作により緩衝バッファ閾値レジスタ２１６に設定される。緩衝バッファ登録ポインタ２１４は、調停回路２０１が送出したフレームを緩衝バッファ２０２に登録する毎に＋１されて、次の登録位置を示し、緩衝バッファ索引ポインタ２１５は、緩衝バッファ２０２からフレームを読み出す毎に＋１されて、次の読み出し位置を示す。
【００５５】
緩衝バッファ２０２が常にリクエストを全フレーム分登録できるためには、調停の際にリクエストの取りうる最大フレーム数分の空きを確保されていることが条件であり、この判定を緩衝バッファ空き容量判定回路２１７が、緩衝バッファ登録ポインタ２１４の値から緩衝バッファ索引ポインタ２１５の値を減じて得られる現在の緩衝バッファ登録フレーム数と、緩衝バッファ閾値レジスタ２１６の値を比較することにより行っている。
【００５６】
もし、緩衝バッファ２０２の空き容量がリクエストの最大フレーム数に満たない場合、緩衝バッファ空き容量判定回路２１７は、調停オーナー権判定回路２１２の調停オーナー権の判定を停止し、緩衝バッファ２０２の空き容量がリクエストの最大フレーム数を確保されている場合は、調停オーナー権判定回路２１２は、調停要求に応じて調停オーナー権を判定する。これにより、調停回路２０１が調停動作する時は、調停したリクエストの全フレームを必ず緩衝バッファ２０２に登録できることを保証している。
【００５７】
なお、緩衝バッファ登録フレーム数の算出は、緩衝バッファ登録ポインタ２１４の値と緩衝バッファ索引ポインタ２１５の値との差分で算出せず、緩衝バッファ登録で＋１し、緩衝バッファ読み出しで−１するようなカウンタで実現することも可能である。
【００５８】
【発明の効果】
本発明の第１の効果は、リクエストが分断した際の調停デッドロックを回避し、かつ、その受信ポートの次リクエストが異なる出力ポートへ調停参加する場合に、調停参加の遅れをなくせることである。
【００５９】
その理由は、送信ポートの状態に依らず、調停した受信ポートからのリクエストの全フレームを緩衝バッファに登録するからである。
【００６０】
第２の効果は、リクエストの特性に応じた混在調停が柔軟に実施できることである。
【００６１】
その理由は、リクエスト分断の可能性があるケースに対しリクエストの要素である全フレームの到着を保証してから調停参加する方法と、予め何らかの手段でリクエスト分断しないことが保証されたケースに対し性能を重視してリクエストの最初のフレーム到着で調停参加する方法の二つの方法を採用し、この二つの調停方法をポート単位に任意に選択可能な手段と、調停後の経路上にリクエストを構成する最大フレーム数の登録を保証する緩衝バッファとを設けるからである。
【図面の簡単な説明】
【図１】本発明の実施の形態の構成を示すブロック図である。
【図２】本発明の実施の形態の動作を示すブロック図である。
【図３】受信ポートから送信ポートへの調停の制御を示す説明図である。
【図４】方法Ａの動作を示すタイミングチャートである。
【図５】方法Ｂの動作を示すタイミングチャートである。
【符号の説明】
０００ リクエストバッファ
００１ 調停回路
００２ 緩衝バッファ
００３ 出力制御部
００４ 調停方法選択回路
０１０ 最終フレーム数監視カウンタ
０１１ リクエスト要求生成回路
０１２ リクエスト先頭フレーム識別信号
１００ リクエストバッファ
１０１ 調停回路
１０２ 緩衝バッファ
１０３ 出力制御部
１０４ 調停方法選択回路
２００ リクエストバッファ
２０１ 調停回路
２０２ 緩衝バッファ
２０３ 出力制御部
２０４ 調停方法選択回路
２１２ 調停オーナー権判定回路
２１３ 調停オーナー権保持レジスタ
２１４ 緩衝バッファ登録ポインタ
２１５ 緩衝バッファ索引ポインタ
２１６ 緩衝バッファ閾値レジスタ
２１７ 緩衝バッファ空き容量判定回路
ｎ００ リクエストバッファ
ｎ０１ 調停回路
ｎ０２ 緩衝バッファ
ｎ０３ 出力制御部
ｎ０４ 調停方法選択回路
【発明の属する技術分野】
本発明は、クロスバー調停システムに関し、特に、複数のリクエスト型式に柔軟に対応できるクロスバー調停システムに関する。
【０００２】
【従来の技術】
従来の特許文献１記載の技術は、リクエスト調停手段が、送受信のリクエストを受け付ける緩衝バッファのみを持ち、リクエストに対する通信の許可を確認した段階でネットワークへのデータの送出を開始することでデータ蓄積用の緩衝バッファを不要とし、クラスタ数の増加に伴う緩衝バッファの増加分の削減を図るものである。また、この技術は、データ転送元クラスタとデータ転送先クラスタとの間で一定期間データパスを占有しデータ転送する方式とし、リクエスト調停手段がデータパスの空き状況を管理し、クラスタ間のデータ転送を行う時、データパス間の競合は発生しないようにし、緩衝バッファ量の削減を可能としている。
【０００３】
この技術は、さらに、データ転送要求をしている間にデータ転送要求元の自クラスタ内のメモリからデータをロードし、転送許可が通知された場合に即座に他クラスタへのデータ転送を開始することで、効率よくデータ転送を行うことを可能としている。
【０００４】
【特許文献１】
特開２００１−２０９６２６号公報
【０００５】
【発明が解決しようとする課題】
上述した特許文献１記載の技術においては、以下のような「先頭フレームが到着したら調停に参加する方法（リクエスト型式）」、「リクエストの全フレームの到着を待ち合わせてから調停参加する方法（リクエスト型式）」を混在制御する構成になっていないので、性能が向上しないという問題がある。
【０００６】
従来の技術のクロスバー調停では、各ポートから入力された非連続な複数フレームから成るリクエストを調停して送信先へ送信する時、性能を重視してリクエストの先頭フレームが到着したら調停に参加する方法が採用される。しかし、この方法では後続フレームが調停後すぐに受け付けられるのか、あるいはまだ受信できていないのか、といった状態を判断することができず、リクエストが分断して後続フレームの受信待ち状態となる受信ポートが存在すると調停中であるリクエストを完了できずに調停途中のままデッドロックする可能性がある。
【０００７】
一方、リクエストの分断する可能性がある受信ポートを救済するためにリクエストの全フレームの到着を待ち合わせてから調停参加する方法を採用すると、本来リクエスト分断の可能性がない受信ポートも待ち合わせをすることになり性能が低下してしまう。また、前記２つの方法に共通して、送信ポートのビジー等により調停がリクエスト処理途中で停止すると、後続リクエストが他の送信先であった場合に直接関係のない調停処理中リクエストの影響で調停参加が待たされてしまうという欠点がある。
【０００８】
本発明の目的は、調停参加に際してリクエストの最初のフレーム到着で調停参加する方法とリクエストの全フレームの到着を保証してから調停参加する方法の何れかをリクエストの特性に応じてポート単位に任意選択可能な手段と、調停後の経路上にリクエストを構成する最大フレーム数の登録を保証する緩衝バッファとを設けることによって前記欠点を解決することである。
【０００９】
【課題を解決するための手段】
本発明の第１のクロスバー調停システムは、複数の受信ポートから複数の送信ポートの何れかに対して複数個のフレームにより構成されるリクエストを転送するクロスバー調停システムであって、
リクエストのクロスバー調停システムへの調停参加に際してリクエストの最初のフレーム到着で調停参加する第１のリクエスト形式とリクエストの全フレームの到着を保証してから調停参加する第２のリクエス形式との何れかによる調停参加を、リクエスト元となるポート単位に選択可能な第１の手段と、前記第１の手段により選択されたリクエスト形式が第１のリクエスト形式の場合はリクエストの最初のフレーム到着で調停を行い、第２のリクエスト形式の場合はリクエストの全フレームの到着を保証してから調停を行う第２の手段と、前記第２の手段による調停後の経路上に設置され、リクエストを構成する最大フレーム数の登録を保証して前記第２の手段により調停され出力されたリクエストの全フレームを登録可能にする緩衝バッファとを有する。
【００１０】
本発明の第２のクロスバー調停システムは、受信ポートからのフレームで構成されるリクエストを格納する受信ポート対応のリクエストバッファと、
前記受信ポートごとに調停参加に際してリクエストの最初のフレーム到着で調停参加する第１のリクエスト型式とリクエストの全フレームの到着を保証してから調停参加する第２のリクエスト型式との何れかを示す値が外部から設定される前記リクエストバッファ対応の調停方法選択回路と、
前記調停方法選択回路からの前記受信ポートごとの値に基づいて、値が第１のリクエスト形式を示せば、前記リクエストバッファからのリクエストの最初のフレーム到着でそのリクエストの調停参加のための調停要求を出し、値が第２のリクエスト形式を示せば、前記リクエストバッファからのリクエストの全フレームの到着を保証してからそのリクエストの調停参加のための調停要求を出す前記リクエストバッファ対応のリクエスト要求生成回路と、
前記リクエスト要求生成回路からの調停要求によりオーナー権を判定しオーナー権を獲得した受信ポートを示す値を出力する送信ポート対応の調停オーナー権判定回路と、
前記調停オーナー権判定回路からのオーナー権を獲得した受信ポートを示す値を保持する送信ポート対応の調停オーナー権保持レジスタと、
前記調停オーナー権保持レジスタからのオーナー権を獲得した受信ポートを示す値により前記受信ポート対応のリクエストバッファからのリクエストを選択する送信ポート対応の調停回路とを有する。
【００１１】
本発明の第３のクロスバー調停システムは、受信ポートからのフレームで構成されるリクエストを格納する受信ポート対応のリクエストバッファと、
前記受信ポートごとに調停参加に際してリクエストの最初のフレーム到着で調停参加する第１のリクエスト型式とリクエストの全フレームの到着を保証してから調停参加する第２のリクエスト型式との何れかを示す値が外部から設定される前記リクエストバッファ対応の調停方法選択回路と、
前記調停方法選択回路からの前記受信ポートごとの値に基づいて、値が第１のリクエスト形式を示せば、前記リクエストバッファからのリクエストの最初のフレーム到着でそのリクエストの調停参加のための調停要求を出し、値が第２のリクエスト形式を示せば、前記リクエストバッファからのリクエストの全フレームの到着を保証してからそのリクエストの調停参加のための調停要求を出す前記リクエストバッファ対応のリクエスト要求生成回路と、
前記リクエスト要求生成回路からの調停要求によりオーナー権を判定しオーナー権を獲得した受信ポートを示す値を出力する送信ポート対応の調停オーナー権判定回路と、
前記調停オーナー権判定回路からのオーナー権を獲得した受信ポートを示す値を保持する送信ポート対応の調停オーナー権保持レジスタと、
前記調停オーナー権保持レジスタからのオーナー権を獲得した受信ポートを示す値により前記受信ポート対応のリクエストバッファからのリクエストを選択する送信ポート対応の調停回路と、
前記送信ポート対応の調停回路からのリクエストの最大数のフレームを格納する送信ポート対応の緩衝バッファとを有する。
【００１２】
本発明の第４のクロスバー調停システムは、受信ポートからのフレームで構成されるリクエストを格納する受信ポート対応のリクエストバッファと、
前記受信ポートごとに調停参加に際してリクエストの最初のフレーム到着で調停参加する第１のリクエスト型式とリクエストの全フレームの到着を保証してから調停参加する第２のリクエスト型式との何れかを示す値が外部から設定される前記リクエストバッファ対応の調停方法選択回路と、
リクエストを構成するフレームのうち最終フレームを前記リクエストバッファに登録すると１加算され、調停によりリクエストが読み出されると１減算される前記リクエストバッファ対応の最終フレーム数監視カウンタと、
前記調停方法選択回路からの前記受信ポートごとの値に基づいて、値が第１のリクエスト形式を示せば、前記リクエストバッファからのリクエストの最初のフレーム到着でそのリクエストの調停参加のための調停要求を出し、値が第２のリクエスト形式を示せば、前記最終フレーム数監視カウンタの値を参照し、前記リクエストバッファからのリクエストの全フレームの到着を保証してからそのリクエストの調停参加のための調停要求を出す前記リクエストバッファ対応のリクエスト要求生成回路と、
前記リクエスト要求生成回路からの調停要求によりオーナー権を判定しオーナー権を獲得した受信ポートを示す値を出力する送信ポート対応の調停オーナー権判定回路と、
前記調停オーナー権判定回路からのオーナー権を獲得した受信ポートを示す値を保持する送信ポート対応の調停オーナー権保持レジスタと、
前記調停オーナー権保持レジスタからのオーナー権を獲得した受信ポートを示す値により前記受信ポート対応のリクエストバッファからのリクエストを選択する送信ポート対応の調停回路と、
前記送信ポート対応の調停回路からのリクエストの最大数のフレームを格納する送信ポート対応の緩衝バッファとを有する。
【００１３】
本発明の第５のクロスバー調停システムは、受信ポートからのフレームで構成されるリクエストを格納し、リクエストの先頭フレームの場合にリクエスト先頭フレーム識別信号を出力する受信ポート対応のリクエストバッファと、
前記受信ポートごとに調停参加に際してリクエストの最初のフレーム到着で調停参加する第１のリクエスト型式とリクエストの全フレームの到着を保証してから調停参加する第２のリクエスト型式との何れかを示す値が外部から設定される前記リクエストバッファ対応の調停方法選択回路と、
リクエストを構成するフレームのうち最終フレームを前記リクエストバッファに登録すると１加算され、調停によりリクエストが読み出されると１減算される前記リクエストバッファ対応の最終フレーム数監視カウンタと、
前記調停方法選択回路に第２のリクエスト型式を示す値が設定されている場合は、前記最終フレーム数監視カウンタの値が０より大きく、かつ、リクエスト先頭フレーム識別信号が通知されると前記リクエストバッファからのリクエストの調停参加のための調停要求を出し、前記調停方法選択回路に第１のリクエスト型式を示す値が設定されている場合は、リクエスト先頭フレーム識別信号が通知されると前記リクエストバッファからのリクエストの調停参加のための調停要求を出す前記リクエストバッファ対応のリクエスト要求生成回路と、
前記リクエスト要求生成回路からの調停要求によりオーナー権を判定しオーナー権を獲得した受信ポートを示す値を出力する送信ポート対応の調停オーナー権判定回路と、
前記調停オーナー権判定回路からのオーナー権を獲得した受信ポートを示す値を保持する送信ポート対応の調停オーナー権保持レジスタと、
前記調停オーナー権保持レジスタからのオーナー権を獲得した受信ポートを示す値により前記受信ポート対応のリクエストバッファからのリクエストを選択する送信ポート対応の調停回路と、
前記送信ポート対応の調停回路からのリクエストの最大数のフレームを格納する送信ポート対応の緩衝バッファとを有する。
【００１４】
本発明の第６のクロスバー調停システムは、受信ポートからのフレームで構成されるリクエストを格納し、リクエストの先頭フレームの場合にリクエスト先頭フレーム識別信号を出力する受信ポート対応のリクエストバッファと、
前記受信ポートごとに調停参加に際してリクエストの最初のフレーム到着で調停参加する第１のリクエスト型式とリクエストの全フレームの到着を保証してから調停参加する第２のリクエスト型式との何れかを示す値が外部から設定される前記リクエストバッファ対応の調停方法選択回路と、
リクエストを構成するフレームのうち最終フレームを前記リクエストバッファに登録すると１加算され、調停によりリクエストが読み出されると１減算される前記リクエストバッファ対応の最終フレーム数監視カウンタと、
前記調停方法選択回路に第２のリクエスト型式を示す値が設定されている場合は、前記最終フレーム数監視カウンタの値が０より大きく、かつ、リクエスト先頭フレーム識別信号が通知されると前記リクエストバッファからのリクエストの調停参加のための調停要求を出し、前記調停方法選択回路に第１のリクエスト型式を示す値が設定されている場合は、リクエスト先頭フレーム識別信号が通知されると前記リクエストバッファからのリクエストの調停参加のための調停要求を出す前記リクエストバッファ対応のリクエスト要求生成回路と、
前記リクエスト要求生成回路からの調停要求、オーナー権の判定・停止要求信号によりオーナー権を判定しオーナー権を獲得した受信ポートを示す値を出力する送信ポート対応の調停オーナー権判定回路と、
前記調停オーナー権判定回路からのオーナー権を獲得した受信ポートを示す値を保持する送信ポート対応の調停オーナー権保持レジスタと、
前記調停オーナー権保持レジスタからのオーナー権を獲得した受信ポートを示す値により前記受信ポート対応のリクエストバッファからのリクエストを選択する送信ポート対応の調停回路と、
前記送信ポート対応の調停回路からのリクエストの最大数のフレームを格納する送信ポート対応の緩衝バッファと、
前記調停回路が送出したフレームが前記緩衝バッファに登録される毎に１加算され次の登録位置を示す緩衝バッファ登録ポインタと、
前記緩衝バッファからフレームが読み出される毎に１加算され次の読み出し位置を示す緩衝バッファ索引ポインタと、
前記緩衝バッファに対して、最大登録数から予め存在しうるリクエストの最大フレーム数を減じた値が外部から設定される緩衝バッファ閾値レジスタと、
前記緩衝バッファ登録ポインタの値、緩衝バッファ索引ポインタの値、緩衝バッファ閾値レジスタの値に基づいて前記調停オーナー権判定回路にオーナー権の判定・停止要求信号を出力する前記緩衝バッファ対応の緩衝バッファ空き容量判定回路とを有することを特徴とするクロスバー調停システム。
【００１５】
【発明の実施の形態】
次に、本発明の実施の形態について図面を参照して詳細に説明する。
【００１６】
ネットワーク等で用いられるクロスバーでは、各ポートから入力された非連続な複数フレームから成るリクエストを調停して送信先へ送信する時、通常は性能を重視してリクエストの先頭フレームが到着したら調停に参加する方法が採用される。しかし、この方法では後続フレームが調停後すぐに受け付けられるのか、あるいはまだ受信できていないのか、といった状態を判断することができず、リクエストが分断して後続フレームが到着しなくなるような受信ポートが存在すると調停中であるリクエストを完了できずに調停途中のままデッドロックする可能性がある。
【００１７】
一方、リクエストの分断する可能性がある受信ポートを救済するためにリクエストの全フレームの到着を待ち合わせてから調停参加する方法を採用すると、本来リクエスト分断の可能性がない受信ポートも待ち合わせをすることになり性能が低下してしまう。また、前記２つの方法に共通して、送信ポートのビジー等により調停がリクエスト処理途中で停止すると、後続リクエストが他の送信先であった場合に直接関係のない調停処理中リクエストの影響で調停参加が待たされてしまう欠点がある。よって、クロスバーでは受信ポートの特性に応じて前記２つの方法を使い分けることが重要であるが、本発明は、調停参加に際してリクエストの最初のフレーム到着で調停参加する方法とリクエストの全フレームの到着を保証してから調停参加する方法の何れかをリクエストの特性に応じてポート単位に任意選択設定可能な手段と、調停後の経路上にリクエストを構成する最大フレーム数の登録を保証する緩衝手段とを設けることによって前記欠点を解決する。
【００１８】
図１は、本発明の実施の形態の構成を示すブロック図である。
【００１９】
図１を参照すると、本発明の実施の形態は、受信ポート０、受信ポート１、受信ポート２、…、受信ポートｎ毎にリクエストを受信して調停に参加する受信ポート０、受信ポート１、受信ポート２、…、受信ポートｎのリクエストを格納するリクエストバッファ０００、リクエストバッファ１００、リクエストバッファ２００、…、リクエストバッファｎ００と、調停への参加方法を選択する受信ポート０、受信ポート１、受信ポート２、…、受信ポートｎの調停方法選択回路００４、調停方法選択回路１０４、調停方法選択回路２０４、調停方法選択回路ｎ０４と、送信ポート０、送信ポート１、送信ポート２、…、送信ポートｎ毎に受信ポート０、受信ポート１、受信ポート２、…、受信ポートｎからのリクエスト調停を行う送信ポート０、送信ポート１、送信ポート２、…、送信ポートｎの調停回路００１、調停回路１０１、調停回路２０１、…、調停回路ｎ０１と、調停する時にはリクエストを構成する全フレームの登録を保証する送信ポート０、送信ポート１、送信ポート２、…、送信ポートｎの緩衝バッファ００２、緩衝バッファ１０２、緩衝バッファ２０２、…、緩衝バッファｎ０２と、リクエストを外部に送信し、送信不可の時は緩衝バッファ００２、緩衝バッファ１０２、緩衝バッファ２０２、…、緩衝バッファｎ０２の読み出しを停止する送信ポート０、送信ポート１、送信ポート２、…、送信ポートｎの出力制御部００３、出力制御部１０３、出力制御部２０３、…、出力制御部ｎ０３とから構成される。
【００２０】
図１に示す（ｎ＋１）ポート×（ｎ＋１）ポートのクロスバーは、受信ポート０、受信ポート１、受信ポート２、…、受信ポートｎのリクエストバッファ０００、リクエストバッファ１００、リクエストバッファ２００、…、リクエストバッファｎ００が受信する複数個のフレームから成るリクエストを、送信ポート０、送信ポート１、送信ポート２、…、送信ポートｎ毎に調停回路００１、調停回路１０１、調停回路２０１、…、調停回路ｎ０１で調停する機能を備えており、緩衝バッファ００２、緩衝バッファ１０２、緩衝バッファ２０２、…、緩衝バッファｎ０２は、調停の際にリクエストの最大フレーム数の登録を保証し、登録できない場合にはリクエスト単位で調停動作を停止する機能を備える。
【００２１】
送信ポート０、送信ポート１、送信ポート２、…、送信ポートｎの出力制御部００３、出力制御部１０３、出力制御部２０３、…、出力制御部ｎ０３は、それぞれ、緩衝バッファ００２、緩衝バッファ１０２、緩衝バッファ２０２、緩衝バッファｎ０２より受け取ったリクエストを外部に送信可能かどうかを監視し、送信できない場合はビジーによって緩衝バッファ００２、緩衝バッファ１０２、緩衝バッファ２０２、緩衝バッファｎ０２からの読み出しを停止する。
【００２２】
受信ポート０、受信ポート１、受信ポート２、…、受信ポートｎの調停方法選択回路００４、調停方法選択回路１０４、調停方法選択回路２０４、…、調停方法選択回路ｎ０４には、それぞれ受信ポートの特性に応じてリクエストを構成する全フレームの到着を保証してから調停参加する方法（以下、方法Ａと呼ぶ）と、リクエストの最初のフレーム到着で調停参加を開始する方法（以下、方法Ｂと呼ぶ）とを示す値が、キーボード等外部操作により選択して設定される。
【００２３】
方法Ａは、障害等によるリクエスト分断で、調停が解除されなくなるデッドロックの回避を想定し、確実なリクエスト送信を必要とするポートに設定し、方法Ｂはリクエスト分断の可能性がなく性能を重視したいポートに設定される。
【００２４】
次に、本発明の実施の形態の動作について図面を参照して説明する。
【００２５】
受信ポート０のリクエストバッファ０００に対して調停方法選択回路００４が方法Ａを、受信ポート１のリクエストバッファ１００に対して調停方法選択回路１０４が方法Ｂをそれぞれ選択し、共に送信ポート２の調停回路２０１へ調停参加するケースについて説明する。方法Ａのリクエストバッファ０００は外部から受信するリクエストを格納するが、リクエストが分断しないようにリクエストを構成する非連続なフレームの全ての到着を待ち合わせてから調停回路２０１に調停要求を行うように調停方法選択回路１０４で制御される。
【００２６】
調停回路２０１は、リクエストバッファ０００からのリクエストの調停要求を受け付けて一旦調停動作に入ると、リクエストバッファ０００内に既に格納済みのリクエストの全フレームを連続して調停処理し、送信ポート２の緩衝バッファ２０２へ登録を完了させる。緩衝バッファ２０２はリクエストを構成する最大フレーム数の登録を保証するだけの空き容量が確保しているため、調停したリクエストの全フレームを登録しても緩衝バッファ２０２が溢れることはない。すなわち、緩衝バッファ２０２の空き容量がリクエストを構成する最大フレーム数分の容量に満たない場合には、調停回路２０１は、リクエストを受け付けず、調停を行わない。
【００２７】
よって、調停回路２０１は、リクエスト単位で動作し、調停したリクエストのフレーム数に等しい占有時間で必ず解放されるので、出力制御部２０３がリクエストを送信できずにビジーとなって緩衝バッファ２０２からの読み出しを停止し、これを受けて緩衝バッファ２０２が空き容量不足で調停停止するような場合でも、調停回路２０１を占有し続けることはない。すなわち、調停回路２０１でリクエスト分断により調停が解除されなくなる可能性を排除しデッドロックを回避できることになる。
【００２８】
さらに詳細に、本発明の実施の形態の動作について図面を参照して説明する。
【００２９】
図２は、本発明の実施の形態の動作を示すブロック図である。
【００３０】
図２を参照すると、リクエストバッファ０００が調停要求したポート０→２リクエストＲ０２（受信ポート０から送信ポート２へのリクエスト）が、調停回路２０１で受け付けられて、緩衝バッファ２０２に格納される。緩衝バッファ２０２には、すでに緩衝バッファ２０２に滞在中のリクエストＲ０１があり、読み出しを待たされているとする。緩衝バッファ２０２は、調停回路２０１で調停された新たなポート０→２リクエストＲ０２を格納したことで、空き容量がリクエストの最大フレーム数分の容量に満たなくなり、緩衝バッファ２０２への登録後に調停回路２０１へのリスエスとの受け付けを停止する。
【００３１】
この時、ポート０→２リクエストＲ０２は、全フレームを緩衝バッファ２０２へ登録完了されているため、リクエストバッファ０００に、送信ポート２以外へ送信するリクエスト、たとえば、ポート０→１リクエストＲ０３（受信ポート０から送信ポート１へのリクエスト）が存在する場合、ポート０→１リクエストＲ０３は、停止している調停回路２０１の影響を受けずに調停回路１０１へ調停参加することが可能となる。
【００３２】
一方、性能を重視してリクエストの先頭フレームが到着したら調停に参加する方法Ｂを方法Ａと混在してポート単位に任意指定し制御可能にする。
【００３３】
たとえば、受信ポート１のリクエストバッファ１００は、調停方法選択回路１０４により、性能を重視した最速なフレーム送信のためにリクエストの先頭フレーム到着で調停回路２０１に調停参加するが、調停要求を受けて調停を開始すると、リクエストを構成する全フレームを緩衝バッファ２０２に登録するまで調停を占有する。
【００３４】
この時、調停回路２０１は、リクエストの全フレームが保証されているかは意識せずに調停したフレームを緩衝バッファ２０２に登録するだけでよく、各フレームが連続であれば最速で緩衝バッファ２０２に登録できる。仮にフレーム間で間隔が空いたとしてもポート１は、リクエスト分断の可能性がないポートであり必ず全フレームが到着するので、調停回路２０１は方法Ａと方法Ｂとを何ら変わりなく調停することができ、また、前記二つの調停方法をポート単位に任意選択設定してリクエストの特性に応じた混在調停をすることができる。
【００３５】
次に、調停の制御について図面を参照して詳細に説明する。
【００３６】
図３は、受信ポート０から送信ポート２への調停の制御を示す説明図である。
【００３７】
図３を参照すると、受信ポート０に対応して、調停方法選択回路００４、最終フレーム数監視カウンタ０１０、リクエスト要求生成回路０１１が設けられる。また、送信ポート２に対応して、調停オーナー権判定回路２１２、調停オーナー権保持レジスタ２１３、緩衝バッファ登録ポインタ２１４、緩衝バッファ索引ポインタ２１５、緩衝バッファ閾値レジスタ２１６、緩衝バッファ空き容量判定回路２１７が設けられる。
【００３８】
まず、調停方法選択回路００４に、方法Ａが設定された場合の動作について説明する。
【００３９】
リクエストバッファ０００は、リクエストを構成する非連続なフレームの待ち合わせを監視するために最終フレーム数監視カウンタ０１０を装備する。最終フレーム数監視カウンタ０１０は、リクエストを構成するフレームのうち最終フレームをリクエストバッファ０００に登録すると＋１され、調停によりリクエストが読み出されると−１される。
【００４０】
すなわち、最終フレーム数監視カウンタ０１０の値が０より大きい場合、リクエストバッファ０００には全フレームを待ち合わせ、かつ、登録完了したリクエストが少なくとも１つ以上はあることになる。リクエストバッファ０００は、最初の読み出しフレームがリクエストの先頭フレームの場合に、リクエスト先頭フレーム識別信号０１２をリクエスト要求生成回路０１１に通知し、調停による読み出しを待ち合わせる。リクエスト要求生成回路０１１は、調停方法選択回路００４に方法Ａが設定されており、かつ、最終フレーム数監視カウンタ０１０が、０より大きい場合に、リクエスト先頭フレーム識別信号０１２が通知されたならば、調停オーナー権判定回路２１２に対して調停要求を行う。
【００４１】
調停オーナー権判定回路２１２は、単数、または、複数の受信ポートより受信した調停要求をもとに調停オーナー権を判定し、調停オーナー権保持レジスタ２１３にセットする。たとえば、調停オーナー権判定回路２１２が、受信ポート０の調停オーナー権を獲得し、調停オーナー権保持レジスタ２１３に受信ポート０に対応する値をセットすると、リクエストバッファ０００からリクエストフレームの読み出しを開始し、調停回路２０１によって緩衝バッファ２０２へ送出するとともに、最終フレーム数監視カウンタ０１０を−１する。
【００４２】
調停オーナー権保持レジスタ２１３、および、調停回路２０１によりリクエストは構成する全フレームが読み出されるが、最終フレームを読み出した際に調停オーナー権保持レジスタ２１３をリセットするので、リクエストバッファ０００には、次のリクエストの先頭フレームが待機可能となり、次の調停要求動作に遷移できる。
【００４３】
図４は、方法Ａの動作を示すタイミングチャートである。
【００４４】
図４を参照すると、サイクルＴ１、Ｔ２、Ｔ４、Ｔ６と非連続で受け付けたリクエストのフレーム（先頭フレーム＝先、第２フレーム＝２、第３フレーム＝３、第４フレーム＝４）は、それぞれ、サイクルＴ２、Ｔ３、Ｔ５、Ｔ７においてリクエストバッファ０００に登録される。リクエスト先頭フレーム識別信号０１２は、リクエストバッファ０００の最初の読み出しフレームがリクエストの先頭フレームである場合に有効となり、そのリクエストの最終フレーム（＝第４フレーム）の到着まで待ち合わせを行っている。
【００４５】
サイクルＴ７において、最終フレームがリクエストバッファ０００に登録されると、最終フレーム数監視カウンタ０１０が＋１されて、一つのリクエストがリクエストバッファ０００に揃ったことを示し、リクエスト要求生成回路０１１が、調停要求を開始する。更に、同サイクルＴ７において、調停オーナー権判定回路２１２が調停オーナー権を獲得すると、サイクルＴ８において、調停オーナー権保持レジスタ２１３に受信ポート０に対応する値をセットすることで、調停回路２０１が調停オーナー権を獲得した受信ポート０のリクエストを選択できるように固定され、サイクルＴ８、Ｔ９、Ｔ１０、Ｔ１１において、連続でリクエストフレームを読み出す。
【００４６】
調停オーナー権保持レジスタ２１３をセットした後のサイクルＴ９においては、最終フレーム数監視カウンタ０１０が−１され、調停回路２０１が最終フレームを送出した後のサイクルＴ１２においては、調停オーナー権保持レジスタ２１３がリセットされる。
【００４７】
次に、図３を参照して、調停方法選択回路００４に方法Ｂを設定した時の動作について説明する。
【００４８】
方法Ｂでは、最終フレーム数監視カウンタ０１０を無効化し、リクエスト要求生成回路０１１は、リクエスト先頭フレーム識別信号０１２のみによって調停要求を行う。調停オーナー権判定回路２１２は、単数、または、複数の受信ポートより受信した調停要求をもとに調停オーナー権を判定し、調停オーナー権保持レジスタ２１３にセットする。たとえば、調停オーナー権判定回路２１２が受信ポート０の調停オーナー権を獲得し調停オーナー権保持レジスタ２１３にセットすると、リクエストバッファ０００からリクエストフレームの読み出しを開始し調停回路２０１によって緩衝バッファ２０２へ送出する。
【００４９】
調停オーナー権保持レジスタ２１３、および、調停回路２０１によりリクエストは構成する全フレームを読み出すが、方法Ｂにおいては、リクエストを構成する全フレームがリクエストバッファ０００に到着しているとは限らないので到着するまでの間も調停オーナー権保持レジスタ２１３を保持し続けていて、最終フレームがリクエストバッファ０００に到着し、調停回路２０１を経て緩衝バッファ２０２への送出が完了した時点でリセットする。リクエストバッファ０００の最初の読み出しフレームに再び次のリクエストの先頭フレームが到着すると、すぐに次の調停要求動作に遷移する。
【００５０】
図５は、方法Ｂの動作を示すタイミングチャートである。
【００５１】
図５を参照すると、サイクルＴ１、Ｔ２、Ｔ４、Ｔ７において非連続で受け付けたリクエストのフレーム（先頭フレーム＝先、第２フレーム＝２、第３フレーム＝３、第４フレーム＝４）は、それぞれサイクルＴ２、Ｔ３、Ｔ５、Ｔ８において、リクエストバッファ０００に登録される。リクエスト先頭フレーム識別信号０１２は、リクエストバッファ０００の最初の読み出しフレームがリクエストの先頭フレームである場合に有効となり、サイクルＴ２において、リクエスト要求生成回路０１１がそのリクエストの最終フレーム（＝第４フレーム）の到着を待たずに調停要求を開始する。
【００５２】
更に、サイクルＴ２において、調停オーナー権判定回路２１２が調停オーナー権を獲得すると、調停オーナー権保持レジスタ２１３に受信ポート０に対応する値をセットすることで、調停回路２０１が調停オーナー権を獲得した受信ポート０のリクエストを選択できるよう固定され、サイクルＴ３、Ｔ４、Ｔ５、Ｔ８においてリクエストフレームをその到着サイクルに依存して非連続に読み出す。調停回路２０１が最終フレームを送出した後のサイクルＴ９においては、調停オーナー権保持レジスタ２１３がリセットされる。
【００５３】
次に、緩衝バッファ２０２の動作について図３を用いて説明する。
【００５４】
たとえば、緩衝バッファ２０２に対して、その最大登録数から予め存在しうるリクエストの最大フレーム数を減じた値がキーボード等外部操作により緩衝バッファ閾値レジスタ２１６に設定される。緩衝バッファ登録ポインタ２１４は、調停回路２０１が送出したフレームを緩衝バッファ２０２に登録する毎に＋１されて、次の登録位置を示し、緩衝バッファ索引ポインタ２１５は、緩衝バッファ２０２からフレームを読み出す毎に＋１されて、次の読み出し位置を示す。
【００５５】
緩衝バッファ２０２が常にリクエストを全フレーム分登録できるためには、調停の際にリクエストの取りうる最大フレーム数分の空きを確保されていることが条件であり、この判定を緩衝バッファ空き容量判定回路２１７が、緩衝バッファ登録ポインタ２１４の値から緩衝バッファ索引ポインタ２１５の値を減じて得られる現在の緩衝バッファ登録フレーム数と、緩衝バッファ閾値レジスタ２１６の値を比較することにより行っている。
【００５６】
もし、緩衝バッファ２０２の空き容量がリクエストの最大フレーム数に満たない場合、緩衝バッファ空き容量判定回路２１７は、調停オーナー権判定回路２１２の調停オーナー権の判定を停止し、緩衝バッファ２０２の空き容量がリクエストの最大フレーム数を確保されている場合は、調停オーナー権判定回路２１２は、調停要求に応じて調停オーナー権を判定する。これにより、調停回路２０１が調停動作する時は、調停したリクエストの全フレームを必ず緩衝バッファ２０２に登録できることを保証している。
【００５７】
なお、緩衝バッファ登録フレーム数の算出は、緩衝バッファ登録ポインタ２１４の値と緩衝バッファ索引ポインタ２１５の値との差分で算出せず、緩衝バッファ登録で＋１し、緩衝バッファ読み出しで−１するようなカウンタで実現することも可能である。
【００５８】
【発明の効果】
本発明の第１の効果は、リクエストが分断した際の調停デッドロックを回避し、かつ、その受信ポートの次リクエストが異なる出力ポートへ調停参加する場合に、調停参加の遅れをなくせることである。
【００５９】
その理由は、送信ポートの状態に依らず、調停した受信ポートからのリクエストの全フレームを緩衝バッファに登録するからである。
【００６０】
第２の効果は、リクエストの特性に応じた混在調停が柔軟に実施できることである。
【００６１】
その理由は、リクエスト分断の可能性があるケースに対しリクエストの要素である全フレームの到着を保証してから調停参加する方法と、予め何らかの手段でリクエスト分断しないことが保証されたケースに対し性能を重視してリクエストの最初のフレーム到着で調停参加する方法の二つの方法を採用し、この二つの調停方法をポート単位に任意に選択可能な手段と、調停後の経路上にリクエストを構成する最大フレーム数の登録を保証する緩衝バッファとを設けるからである。
【図面の簡単な説明】
【図１】本発明の実施の形態の構成を示すブロック図である。
【図２】本発明の実施の形態の動作を示すブロック図である。
【図３】受信ポートから送信ポートへの調停の制御を示す説明図である。
【図４】方法Ａの動作を示すタイミングチャートである。
【図５】方法Ｂの動作を示すタイミングチャートである。
【符号の説明】
０００ リクエストバッファ
００１ 調停回路
００２ 緩衝バッファ
００３ 出力制御部
００４ 調停方法選択回路
０１０ 最終フレーム数監視カウンタ
０１１ リクエスト要求生成回路
０１２ リクエスト先頭フレーム識別信号
１００ リクエストバッファ
１０１ 調停回路
１０２ 緩衝バッファ
１０３ 出力制御部
１０４ 調停方法選択回路
２００ リクエストバッファ
２０１ 調停回路
２０２ 緩衝バッファ
２０３ 出力制御部
２０４ 調停方法選択回路
２１２ 調停オーナー権判定回路
２１３ 調停オーナー権保持レジスタ
２１４ 緩衝バッファ登録ポインタ
２１５ 緩衝バッファ索引ポインタ
２１６ 緩衝バッファ閾値レジスタ
２１７ 緩衝バッファ空き容量判定回路
ｎ００ リクエストバッファ
ｎ０１ 調停回路
ｎ０２ 緩衝バッファ
ｎ０３ 出力制御部
ｎ０４ 調停方法選択回路
Claims (6)
- 複数の受信ポートから複数の送信ポートの何れかに対して複数個のフレームにより構成されるリクエストを転送するクロスバー調停システムであって、
リクエストのクロスバー調停システムへの調停参加に際してリクエストの最初のフレーム到着で調停参加する第１のリクエスト形式とリクエストの全フレームの到着を保証してから調停参加する第２のリクエス形式との何れかによる調停参加を、リクエスト元となるポート単位に選択可能な第１の手段と、前記第１の手段により選択されたリクエスト形式が第１のリクエスト形式の場合はリクエストの最初のフレーム到着で調停を行い、第２のリクエスト形式の場合はリクエストの全フレームの到着を保証してから調停を行う第２の手段と、前記第２の手段による調停後の経路上に設置され、リクエストを構成する最大フレーム数の登録を保証して前記第２の手段により調停され出力されたリクエストの全フレームを登録可能にする緩衝バッファとを有することを特徴とするクロスバー調停システム。 - 受信ポートからのフレームで構成されるリクエストを格納する受信ポート対応のリクエストバッファと、
前記受信ポートごとに調停参加に際してリクエストの最初のフレーム到着で調停参加する第１のリクエスト型式とリクエストの全フレームの到着を保証してから調停参加する第２のリクエスト型式との何れかを示す値が外部から設定される前記リクエストバッファ対応の調停方法選択回路と、
前記調停方法選択回路からの前記受信ポートごとの値に基づいて、値が第１のリクエスト形式を示せば、前記リクエストバッファからのリクエストの最初のフレーム到着でそのリクエストの調停参加のための調停要求を出し、値が第２のリクエスト形式を示せば、前記リクエストバッファからのリクエストの全フレームの到着を保証してからそのリクエストの調停参加のための調停要求を出す前記リクエストバッファ対応のリクエスト要求生成回路と、
前記リクエスト要求生成回路からの調停要求によりオーナー権を判定しオーナー権を獲得した受信ポートを示す値を出力する送信ポート対応の調停オーナー権判定回路と、
前記調停オーナー権判定回路からのオーナー権を獲得した受信ポートを示す値を保持する送信ポート対応の調停オーナー権保持レジスタと、
前記調停オーナー権保持レジスタからのオーナー権を獲得した受信ポートを示す値により前記受信ポート対応のリクエストバッファからのリクエストを選択する送信ポート対応の調停回路とを有することを特徴とするクロスバー調停システム。 - 受信ポートからのフレームで構成されるリクエストを格納する受信ポート対応のリクエストバッファと、
前記受信ポートごとに調停参加に際してリクエストの最初のフレーム到着で調停参加する第１のリクエスト型式とリクエストの全フレームの到着を保証してから調停参加する第２のリクエスト型式との何れかを示す値が外部から設定される前記リクエストバッファ対応の調停方法選択回路と、
前記調停方法選択回路からの前記受信ポートごとの値に基づいて、値が第１のリクエスト形式を示せば、前記リクエストバッファからのリクエストの最初のフレーム到着でそのリクエストの調停参加のための調停要求を出し、値が第２のリクエスト形式を示せば、前記リクエストバッファからのリクエストの全フレームの到着を保証してからそのリクエストの調停参加のための調停要求を出す前記リクエストバッファ対応のリクエスト要求生成回路と、
前記リクエスト要求生成回路からの調停要求によりオーナー権を判定しオーナー権を獲得した受信ポートを示す値を出力する送信ポート対応の調停オーナー権判定回路と、
前記調停オーナー権判定回路からのオーナー権を獲得した受信ポートを示す値を保持する送信ポート対応の調停オーナー権保持レジスタと、
前記調停オーナー権保持レジスタからのオーナー権を獲得した受信ポートを示す値により前記受信ポート対応のリクエストバッファからのリクエストを選択する送信ポート対応の調停回路と、
前記送信ポート対応の調停回路からのリクエストの最大数のフレームを格納する送信ポート対応の緩衝バッファとを有することを特徴とするクロスバー調停システム。 - 受信ポートからのフレームで構成されるリクエストを格納する受信ポート対応のリクエストバッファと、
前記受信ポートごとに調停参加に際してリクエストの最初のフレーム到着で調停参加する第１のリクエスト型式とリクエストの全フレームの到着を保証してから調停参加する第２のリクエスト型式との何れかを示す値が外部から設定される前記リクエストバッファ対応の調停方法選択回路と、
リクエストを構成するフレームのうち最終フレームを前記リクエストバッファに登録すると１加算され、調停によりリクエストが読み出されると１減算される前記リクエストバッファ対応の最終フレーム数監視カウンタと、
前記調停方法選択回路からの前記受信ポートごとの値に基づいて、値が第１のリクエスト形式を示せば、前記リクエストバッファからのリクエストの最初のフレーム到着でそのリクエストの調停参加のための調停要求を出し、値が第２のリクエスト形式を示せば、前記最終フレーム数監視カウンタの値を参照し、前記リクエストバッファからのリクエストの全フレームの到着を保証してからそのリクエストの調停参加のための調停要求を出す前記リクエストバッファ対応のリクエスト要求生成回路と、
前記リクエスト要求生成回路からの調停要求によりオーナー権を判定しオーナー権を獲得した受信ポートを示す値を出力する送信ポート対応の調停オーナー権判定回路と、
前記調停オーナー権判定回路からのオーナー権を獲得した受信ポートを示す値を保持する送信ポート対応の調停オーナー権保持レジスタと、
前記調停オーナー権保持レジスタからのオーナー権を獲得した受信ポートを示す値により前記受信ポート対応のリクエストバッファからのリクエストを選択する送信ポート対応の調停回路と、
前記送信ポート対応の調停回路からのリクエストの最大数のフレームを格納する送信ポート対応の緩衝バッファとを有することを特徴とするクロスバー調停システム。 - 受信ポートからのフレームで構成されるリクエストを格納し、リクエストの先頭フレームの場合にリクエスト先頭フレーム識別信号を出力する受信ポート対応のリクエストバッファと、
前記受信ポートごとに調停参加に際してリクエストの最初のフレーム到着で調停参加する第１のリクエスト型式とリクエストの全フレームの到着を保証してから調停参加する第２のリクエスト型式との何れかを示す値が外部から設定される前記リクエストバッファ対応の調停方法選択回路と、
リクエストを構成するフレームのうち最終フレームを前記リクエストバッファに登録すると１加算され、調停によりリクエストが読み出されると１減算される前記リクエストバッファ対応の最終フレーム数監視カウンタと、
前記調停方法選択回路に第２のリクエスト型式を示す値が設定されている場合は、前記最終フレーム数監視カウンタの値が０より大きく、かつ、リクエスト先頭フレーム識別信号が通知されると前記リクエストバッファからのリクエストの調停参加のための調停要求を出し、前記調停方法選択回路に第１のリクエスト型式を示す値が設定されている場合は、リクエスト先頭フレーム識別信号が通知されると前記リクエストバッファからのリクエストの調停参加のための調停要求を出す前記リクエストバッファ対応のリクエスト要求生成回路と、
前記リクエスト要求生成回路からの調停要求によりオーナー権を判定しオーナー権を獲得した受信ポートを示す値を出力する送信ポート対応の調停オーナー権判定回路と、
前記調停オーナー権判定回路からのオーナー権を獲得した受信ポートを示す値を保持する送信ポート対応の調停オーナー権保持レジスタと、
前記調停オーナー権保持レジスタからのオーナー権を獲得した受信ポートを示す値により前記受信ポート対応のリクエストバッファからのリクエストを選択する送信ポート対応の調停回路と、
前記送信ポート対応の調停回路からのリクエストの最大数のフレームを格納する送信ポート対応の緩衝バッファとを有することを特徴とするクロスバー調停システム。 - 受信ポートからのフレームで構成されるリクエストを格納し、リクエストの先頭フレームの場合にリクエスト先頭フレーム識別信号を出力する受信ポート対応のリクエストバッファと、
前記受信ポートごとに調停参加に際してリクエストの最初のフレーム到着で調停参加する第１のリクエスト型式とリクエストの全フレームの到着を保証してから調停参加する第２のリクエスト型式との何れかを示す値が外部から設定される前記リクエストバッファ対応の調停方法選択回路と、
リクエストを構成するフレームのうち最終フレームを前記リクエストバッファに登録すると１加算され、調停によりリクエストが読み出されると１減算される前記リクエストバッファ対応の最終フレーム数監視カウンタと、
前記調停方法選択回路に第２のリクエスト型式を示す値が設定されている場合は、前記最終フレーム数監視カウンタの値が０より大きく、かつ、リクエスト先頭フレーム識別信号が通知されると前記リクエストバッファからのリクエストの調停参加のための調停要求を出し、前記調停方法選択回路に第１のリクエスト型式を示す値が設定されている場合は、リクエスト先頭フレーム識別信号が通知されると前記リクエストバッファからのリクエストの調停参加のための調停要求を出す前記リクエストバッファ対応のリクエスト要求生成回路と、
前記リクエスト要求生成回路からの調停要求、オーナー権の判定・停止要求信号によりオーナー権を判定しオーナー権を獲得した受信ポートを示す値を出力する送信ポート対応の調停オーナー権判定回路と、
前記調停オーナー権判定回路からのオーナー権を獲得した受信ポートを示す値を保持する送信ポート対応の調停オーナー権保持レジスタと、
前記調停オーナー権保持レジスタからのオーナー権を獲得した受信ポートを示す値により前記受信ポート対応のリクエストバッファからのリクエストを選択する送信ポート対応の調停回路と、
前記送信ポート対応の調停回路からのリクエストの最大数のフレームを格納する送信ポート対応の緩衝バッファと、
前記調停回路が送出したフレームが前記緩衝バッファに登録される毎に１加算され次の登録位置を示す緩衝バッファ登録ポインタと、
前記緩衝バッファからフレームが読み出される毎に１加算され次の読み出し位置を示す緩衝バッファ索引ポインタと、
前記緩衝バッファに対して、最大登録数から予め存在しうるリクエストの最大フレーム数を減じた値が外部から設定される緩衝バッファ閾値レジスタと、
前記緩衝バッファ登録ポインタの値、緩衝バッファ索引ポインタの値、緩衝バッファ閾値レジスタの値に基づいて前記調停オーナー権判定回路にオーナー権の判定・停止要求信号を出力する前記緩衝バッファ対応の緩衝バッファ空き容量判定回路とを有することを特徴とするクロスバー調停システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002263058A JP3747020B2 (ja) | 2002-09-09 | 2002-09-09 | クロスバー調停システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002263058A JP3747020B2 (ja) | 2002-09-09 | 2002-09-09 | クロスバー調停システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004102607A JP2004102607A (ja) | 2004-04-02 |
| JP3747020B2 true JP3747020B2 (ja) | 2006-02-22 |
Family
ID=32262920
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002263058A Expired - Fee Related JP3747020B2 (ja) | 2002-09-09 | 2002-09-09 | クロスバー調停システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3747020B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4546380B2 (ja) | 2005-10-04 | 2010-09-15 | エヌイーシーコンピュータテクノ株式会社 | クロスバースイッチ、情報処理装置および転送方法 |
| EP2416254A4 (en) * | 2009-03-31 | 2012-10-17 | Fujitsu Ltd | ARBITRATION PROCEDURE, ARBITRATION SWITCHING AND ARBITRATION SWITCHING DEVICE |
-
2002
- 2002-09-09 JP JP2002263058A patent/JP3747020B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004102607A (ja) | 2004-04-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4024875B2 (ja) | 異なるデータ・レートで動作するネットワーク・ポートに関して、共用メモリへのアクセスを調停する方法および装置 | |
| JP3084218B2 (ja) | 通信方法及び同期通信システム | |
| US7450606B2 (en) | Bit slice arbiter | |
| KR100905802B1 (ko) | 컴퓨터 시스템의 입력/출력 노드에서 태깅 및 중재 매카니즘 | |
| JP2005505855A (ja) | コンピュータ・システムの入出力ノード | |
| JP3747020B2 (ja) | クロスバー調停システム | |
| EP1302050A1 (en) | Communication control method and device | |
| US20050228914A1 (en) | Matrix type bus connection system | |
| JP4669174B2 (ja) | チューナブルブロードキャスト／ポイントツーポイントパケットアービトレーション | |
| US7167939B2 (en) | Asynchronous system bus adapter for a computer system having a hierarchical bus structure | |
| US7047284B1 (en) | Transfer request bus node for transfer controller with hub and ports | |
| JP3667504B2 (ja) | 調停回路 | |
| JP3481445B2 (ja) | 競合調停方法 | |
| US20050273535A1 (en) | Write transaction interleaving | |
| JP3317150B2 (ja) | 情報処理装置 | |
| US7747806B2 (en) | Resource use management device, resource use management system, and control method for a resource use management device | |
| JPH11184805A (ja) | バスシステム | |
| JP4679601B2 (ja) | パケット制御回路、パケット処理装置、および、パケット処理方法 | |
| JPH10222462A (ja) | 調停装置 | |
| JP3214461B2 (ja) | バス制御装置 | |
| JP2006065453A (ja) | データ処理装置 | |
| JPH04104540A (ja) | 多重化装置 | |
| EP1459191B1 (en) | Communication bus system | |
| JP2935457B1 (ja) | 調停装置及びこれを用いた通信装置 | |
| JP2011248564A (ja) | 中継装置およびプロセッサーシステム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040423 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050304 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20050314 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050426 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050624 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050802 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050913 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20051108 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20051125 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |