JP2006523902A

JP2006523902A - ラウンド・ロビン資源アービトレーション方法とそのための装置

Info

Publication number: JP2006523902A
Application number: JP2006513106A
Authority: JP
Inventors: メイヤー，マイケル・ジェイ; ウィンガード，ドリュー; ウェバー，ウォルフ−ディートリッヒ
Original assignee: ソニックス・インコーポレーテッド
Priority date: 2003-04-18
Filing date: 2004-04-16
Publication date: 2006-10-19
Also published as: WO2004095296A2; WO2004095296A3; KR20060016753A; US20040210696A1

Abstract

ラウンド・ロビン・アービトレーション方式のための方法と装置を説明する。ラウンド・ロビン・アービトレーションを実現する装置は、少なくとも２つのトークン・アービタを備え、各トークン・アービタは、少なくとも２つのサブツリーが接続されるノードに関連付けられ、各サブツリーは、トークン・アービタまたは有限状態マシン・リクエスタを備える。

Description

本発明は、資源アービトレーションに関し、より詳細には、資源アービトレーションのためのラウンド・ロビン方式に関する。

複数のリクエスタによって共有される資源があり、かつ１リクエスタだけが特定の期間（通常は１クロック・サイクル）に資源を使用することができるとき、要求を受諾し、１リクエスタだけが資源の使用を許されることを保証するアービタを有することが必要である。共有資源の例には、ネットワーク、バス、シリコン・バックプレーンが含まれる。共有資源の所有権は、「トークン」の所有権によって指定することができる。ラウンド・ロビン・アービトレーションは、資源への均等かつ公平なアクセスを保証するので、一般的に使用されるアービトレーション・ポリシーである。ラウンド・ロビン・アービトレーション・ポリシーでは、固定された順序の優先順位ローテーションがリクエスタに割り当てられる。例えば、３つのリクエスタの順序は、Ｒ１、Ｒ２、Ｒ３、そしてＲ１に戻る。最後にトークンを付与されたリクエスタは、最低の優先順位であるとみなされ、その後ろのリクエスタが最高の優先順位であるとみなされる。例えば、Ｒ２が要求が許可される最後のユニットである場合、Ｒ３が最高の優先順位となり、その後にＲ１が続き、最後にＲ３となる。Ｒ３がトークンを要求し、トークンを付与された場合、Ｒ３が最低の優先順位となり、したがってアービトレーション順序はＲ１、Ｒ２、次いでＲ３となる。

トークンの所有権は、資源の所有権と最低優先順位のリクエスタを共に示す。共有資源を効率的に使用するために、各サイクルで新しい要求を許可できることが通常は望ましく、そのことは、トークンを任意の所有者から次の所有者に１サイクルで渡すことができなければならないことを意味する。トークンの所有権は、同一サイクルまたは次のサイクルでの共有資源の所有権を意味する。

そのようなトークン・パッシング機構の従来技術の一実装は、図１に示す分散デイジー・チェーンである。この例では、各リクエスタが、トークンを所有するときに「１」である１つの状態ビットを有する。これは、そのリクエスタが資源の使用を許可されており、次のアービトレーション・サイクルでは最低の優先順位であることを意味する。リクエスタがトークンを必要としない場合、トークンは、次の優先順位のリクエスタに提供される。このプロセスは、アクティブなリクエスタが存在するまで、または現トークン所有者に戻るまでリングを周回し続ける。トークンがリクエスタに与えられるとき、その時トークンを所有するリクエスタは最低の優先順位となり、リング内の次のリクエスタは最高の優先順位となる。サイクル中にリクエスタが存在しない場合、トークンは移動しない。しかし、デイジー・チェーン実装は、静的タイミング分析の難しい偽組合せループ(false combinatorial loop)に対処しなければならない。さらに、リングのタイミングは、リング中のリクエスタ数とリングの長さに比例して低下する。

図２に集中型アービトレーション方式を示す。この集中型アービトレーション方式は、すべての要求信号を中央アービトレーション・ユニットに送り、中央アービトレーション・ユニットで、Ｎ個の優先順位エンコーダのうち１つを使用可能にする。この手法での組合せ論理は、リクエスタ数の２乗に比例して増大する。この手法はさらに、要求入力上の著しいファンアウト遅延とｇｒａｎｔ出力上のファンイン遅延を受け、さらに要求信号とｇｒａｎｔ信号を集中型アービタに配信し、集中型アービタから配信するためにそれらの信号に挿入されるリピータからの遅延も受ける。

図８に、４つの要求信号を有する木構造トークン・リングを示す。ツリーは、階層的に互いに接続されたアグリゲータから構成される。葉は、各イニシエータで現トークン・リング状態マシンへのローカル接続だけを有するアグリゲータである。ツリーの頂部（すなわちルート）は、頂部からのｇｒａｎｔ入力が配線され、頂部への要求出力が無視されたアグリゲータである。アグリゲータは、底部からの３つの入力、１つは左に接続する入力、１つは右に接続する入力、残りはローカル・イニシエータに接続する３番目の入力を有するが、機能は２つ以上の入力に対して機能する。各リクエスタは、１ホットの４ビット要求入力を有する。ツリーはｎ個の４ビット要求を有する。ただしｎは、集約すべき低レベルリクエスタ数である。要求入力の４ビットは以下の意味を有する。
ＨＡＶＥＴＯＫＥＮは、トークンと最高優先順位のリクエスタを有する
ＧＥＮＴＯＫＥＮは、トークンを有するが最低優先順位のリクエスタを有する
ＷＡＮＴＴＯＫＥＮは、トークンを有さないがそれを必要としている
ＮＯＴＯＫＥＮは、トークンを有さず、それを必要としていない

ツリー中の各ノードはさらに、以下の式によって実現されるｎ個の単一ビットｇｒａｎｔダウンストリームと１ホットの４ビット要求アップストリームを出力する。各ノードは、アップストリームからの単一ビットｇｒａｎｔの追加の入力をさらに有する。
root[HAVETOKEN]=rightF[HAVETOKEN]
OR localF[HAVETOKEN]
OR leftF[HAVETOKEN]
OR (leftF[GENTOKEN] AND localF[WANTTOKEN])
OR (leftF[GENTOKEN] AND rightF[WANTTOKEN])
OR (localF[GENTOKEN] AND rightF[WANTTOKEN])

root[GENTOKEN]=rightF[GENTOKEN]
OR (localF[GENTOKEN] AND !rightF[WANTTOKEN])
OR (leftF[GENTOKEN] AND !rightF[WANTTOKEN]
AND !localF[WANTTOKEN])

root[WANTTOKEN]=(rightF[WANTTOKEN]
AND (localF[NOTOKEN] OR localFI[WANTTOKEN])
AND (leftF[NOTOKEN] OR leftF[WANTTOKEN]))
OR (localF[WANTTOKEN]
AND (leftF[NOTOKEN] OR leftF[WANTTOKEN])
AND !rightF[HAVETOKEN] AND !rightF[GENTOKEN])
OR (leftF[WANTTOKEN]
AND !localF[HAVETOKEN] AND !locaIF[GENTOKEN]
AND !rightF[HAVETOKEN] AND !rightF[GENTOKEN])

root[NOTOKEN]=rightF[NOTOKEN] AND localF[NOTOKEN]
AND leftF[NOTOKEN]
rootF = root(with fast buffer)
rootS = root(with slow buffer)

rightGnt = rootGnt AND (rightS[HAVETOKEN]
OR (right[SWANTTOKEN] AND localS[GENTOKEN])
OR (rightS[WANTTOKEN] AND localS[NOTOKEN] AND IeftF[GENTOKEN])
OR (rightS[WANTTOKEN] AND localS[NOTOKEN] AND leftS[NOTOKEN])
OR (rightS[GENTOKEN] AND localS[NOTOKEN] AND leftS[NOTOKEN]))

localGnt=rootGnt AND (localS[HAVETOKEN]
OR (localS[WANTTOKEN] AND leftS[GENTOKEN])
OR (localS[WANTTOKEN] AND leftS[NOTOKEN]
AND !rightS[HAVETOKEN])
OR (localS[GENTOKEN] AND leftS[NOTOKEN] AND rightS[NOTOKEN]))

leftGnt=rootGnt AND (leftS[HAVETOKEN]
OR (leftS[WANTTOKEN] AND !localS[HAVETOKEN]
AND !(rightS[WANTTOKEN] AND localS[GENTOKEN])
AND !rightS[HAVETOKEN])
OR (leftS[GENTOKEN] AND localS[NOTOKEN] AND rightS[NOTOKEN]))

トークン・アービタに対する未使用の入力の結合が解かれ、ＮＯＴＯＫＥＮ入力が１に結合され、その他は０に結合される。ルートｇｒａｎｔ信号は１に結びつけられる。

この実装のタイミングを改善するために、要求が２回、ルートに対する要求で使用される高速タイミング（ｒｏｏｔＦ）のための大きなバッファで１回、ｇｒａｎｔｄｏｗｎ論理（ｒｏｏｔＳ）のためのより緩和されたタイミングで１回送信される。したがって、この実装は、要求をツリーの上方に送るために８個の信号を実際には使用する。これにより、他の手法よりも著しく多くの配線が必要となり、したがって不利である。

ラウンド・ロビン資源アービトレーション方式のための方法と装置を説明する。ラウンド・ロビン・トークン・アービトレーションを実現する装置は、少なくとも２つのトークン・アービタを備え、各トークン・アービタは、少なくとも２つのサブツリーが接続されるノードと関連付けられ、各サブツリーは、トークン・アービタまたは有限状態マシン・リクエスタを備える。

本発明を限定的なものではなく、例示的なものとして添付の図面の各図に示す。各図では、同様の参照番号は同様の要素を指す。

ラウンド・ロビン・アービトレーションのための方法と装置を説明する。共有資源についてのアービトレーションは、多くのシステムの性能にとって重要である。ラウンド・ロビン・アービトレーションは、その単純さと公平性のために良いアービトレーション・ポリシーである。リクエスタが分散するとき、要求を受信すると共にその要求のｇｒａｎｔを返すのにかかる時間は、アービトレーションを行うのにかかる時間と同程度に重要となる。

ツリー・ベースのアービトレーション構造は、図３Ａからわかるように、集積回路チップの２−Ｄ構造中の距離を効率的に横切ることができる。例えば、集積回路は、システム・オン・チップ（ＳＯＣ）でよい。

図３Ａのレイアウトは、ルート・ノードＢ１３１０とその補助ノードを示す。図３Ｂに、図３Ａのチップのリクエスタによって形成されるツリー構造を示す。ノードＢ１からＢ１１は、アービタまたはリクエスタを表す。図３Ａでは、アービタは、Ｂ１（ルート）、Ｂ２、Ｂ５、Ｂ３、Ｂ６、Ｂ７である。言い換えれば、（ローカル・リクエスタに加えて）少なくとも１つの補助ノードを有する各ノードはアービタを有する。これを図４により詳細に示す。

ノードの実際の順序付けは、ルートから任意の葉までの最大長を最小限に抑えるように選ぶことができる。したがって、一実施形態では、設計者は、ツリーの平衡を取るようにノードの順序付けを最適化することができる。したがって、設計者は、トークンについての最大移動時間を最小限に抑えるようにルート・ノードとノード間の接続とを選ぶことができる。ここで、最大移動時間は、リクエスタＢ８からルートＢ１、またはリクエスタＢ９からルートＢ１である。Ｂ８からの横断では、トークンは、ノードＢ５、Ｂ２を通ってルートＢ１まで上流に移動し、戻らなければならない。Ｂ９からの横断では、トークンは、ノードＢ６、Ｂ３を通ってルートＢ１まで上流に移動し、戻らなければならない。ツリーのルートは、ルートに接続される２つのサブツリー・クリティカル・パスが同等であるときに最適な位置に配置される。サブツリーの１つのクリティカル・パスが他のサブツリーよりもかなり長い場合、長いサブツリーのルートを全ツリーのルートにすることにより、ツリーの遅延の平衡がより良好に取られることになる可能性が高い。

図４の編成では、どちらのサブツリー・クリティカル・パスも６ステップを必要とする。回路が上述のデイジー・チェーン方法を使用して実装される場合、最大距離は１１ステップとなる。リクエスタの数が２倍になる場合、ツリー構造中のステップ数は２倍に増加すると共に、デイジー・チェーン中のステップ数が２倍になる。

ツリーの各ノードで分散アービトレーションを実行することにより、所望のラウンド・ロビン・アービトレーション論理が実装され、信号がチップを横切るときに信号がバッファリングされる。

図４に、図３に示すチップに関するラウンド・ロビン・アービトレーションを実装するのに必要なアービタ・セルとアービタＦＳＭからなるトークン・ツリー構造を示す。信号が移動しなければならない距離は、トークン・リング構造よりも短い。さらに、ルートまたはハブ４１０を通過する信号の数は、集中型手法よりもかなり少なく、集中型アービタが２２個の信号を必要とする（全１１リクエスタからそれぞれ２個）のに対して、トークン・アービタ４２０とトークン・アービタ４４０からそれぞれ３個である。

分散実装の一態様は、要求信号がツリーの上方に送られるときの、要求信号の符号化である。図４に示すように、要求をツリーの上方に送るのに２つの信号が使用される。第１の信号は、トークンが現在このサブツリー内のリクエスタの１つによって保持され、かつツリーの残りの中のリクエスタよりも高い優先順位である、このサブツリー内のアクティブなリクエスタが存在しないので、トークンがこのサブツリーによってルートに向かって上流に渡されることを示す生成信号（Ｇ）である。第２の信号は、このサブツリーがアクティブなリクエスタを含まず、トークンを保持しないことを示す伝播信号（Ｐ）である。

一実施形態では、ＧとＰの両方は同一サイクルで決して真とならない。このことにより、後述するいくつかの最適化が得られる。

サブツリーに関するＧ信号とＰ信号（ｒｏｏｔＧとｒｏｏｔＰ）をそのローカルとサブツリーのＰ、Ｇ入力から生成することができる。図４では、サブツリーのＰ、Ｇ入力が、ローカル・サブツリーに関するＬｏｃａｌＧとＬｏｃａｌＰ、左サブツリーに関するＬｅｆｔＧとＬｅｆｔＰ、さらに右サブツリーに関するＲｉｇｈｔＧとＲｉｇｈｔＰとして示されている。ローカル・ノードとサブツリーのすべてがトークンを伝搬中である場合、特定のサブツリーはトークンを伝搬中である。サブツリー内のラウンド・ロビン順序は、トークンがサブツリーの下方に渡されるとき、サブツリーのＧ出力の生成とｇｒａｎｔの生成に影響を及ぼす一実施形態では、ラウンド・ロビン順序はローカル、右、次いで左である。

ｇｒａｎｔ（Ｇｎｔ）信号が、最高の優先順位を有するリクエスタまで伝播される。一実施形態では、優先順位は、ローカル、右、次いで左である。したがって、図４に示す例では、ラウンド・ロビン順序は、Ｆ１、Ｆ３、Ｆ１１、Ｆ１０、Ｆ６、Ｆ９、Ｆ２、Ｆ５、Ｆ８、Ｆ４で、そしてＦ１に戻る。

図４は２進木を示すが、より高次のツリーにスケーリングすることができる。具体的には、あるチップ設計では、ローカル・ノードと３つのサブツリーを有するツリーが有用である。例えば、ルートが北側に位置する場合、ローカル・リクエスタに加えて東、西、南に分岐するサブツリーを有することが有用である。２方向または３方向から集中する要求がある場合は特に、ローカル・リクエスタを有さないアービタを有することが有用であることもある。別の実施形態では、ローカル・リクエスタの方向の分岐が不要であるので、ローカル・リクエスタを有さないアービタが不要である。したがって、追加のリクエスタが存在する場合、別のリクエスタでアービトレーション論理を拡張することができ、または別のアービトレーション・ノードを挿入することができる。

ローカル・ノード、左サブツリー、右サブツリーの順序付けは任意であり、アービトレーションの公平性に影響を及ぼさないが、アービタのタイミングには影響を及ぼす。アービトレーションの順序付けは、左サブツリーと右サブツリーからの経路を最適化すべきである。左サブツリーと右サブツリーは通常はリモートであり、それらもサブツリーである場合に余分の論理レベルを含むからである。

図５Ａにトークン・アービタの一実施形態を示す。図示する例では、ラウンド・ロビン順序はローカル、右、次いで左である。この順序付けが与えられると、左が生成し（ＬｅｆｔＧからＵ１へ）、または右がそれを生成してそれを左に伝搬し（Ｕ２）、またはローカルが生成して左と右が共にそれを伝搬する（Ｕ３）ときはいつでも、サブツリーはトークンを生成する。サブツリーのより低いレベルがトークン（Ｕ４）を伝搬するとき、サブツリーはトークンを伝搬する。Ｐは１つの論理レベルを必要とする一方でＧは２つのレベルを必要とするので、ＰはＧよりも速いことに留意されたい。

図５Ａに示すように、トークン・アービトレーション・セルは、左セルからのＲｏｏｔＧ生成を最適化する。左サブツリーが２つのサブツリーのうちの長い方であるという任意の規約を採用することにより、ＲｏｏｔＧを通る経路の平衡が保たれる。ＬｅｆｔＧからＲｏｏｔＧへの経路が唯一の論理レベル（Ｕ１）であり、一方ＲｉｇｈｔＧからＲｏｏｔＧへの経路が２レベル（Ｕ２およびＵ１）であるからである。

この順序付けの１つの結果は、ＬｅｆｔＧｎｔの生成は、ＲｉｇｈｔＧｎｔとＬｏｃａｌＧｎｔの両方より複雑であることである。しかし、この複雑さのタイミングに対する効果は、論理を再構築し、タイミング・クリティカルな信号ＲｏｏｔＧｎｔからの経路を最適化することによって低減することができる。

図５Ｂからわかるように、Ｕ５をＵ５ＡとＵ５Ｂに、Ｕ８をＵ８ＡとＵ８Ｂ、Ｕ１１をＵ１１ＡとＵ１１Ｂに変換することにより、この経路を１つの複雑なゲートまたは２つの単純２入力ゲートに単純化することができる。したがって、ＬｅｆｔＧｎｔに関するタイミングはＲｉｇｈｔＧｎｔと同等である。この最適化をゲート・レベルで直接行うことができ、または論理合成に対するタイミング制約を介して行うことができる。論理合成に対するタイミング制約では、ＲｏｏｔＧｎｔからＬｅｆｔＧｎｔとＲｉｇｈｔＧｎｔへの経路が、他の入力からアービタ・セルへの経路よりもかかる時間が短くなるように制約を受ける。

したがって、図５Ｂに示す論理は以下のようになる。
RootG=LeftG OR (RightG AND LeftP) OR (LocalG AND LeftP AND RightP)
RootP=LeftP OR RightP OR LocalP
LeftGnt=((!LeftP AND RightP AND LocalG) OR (!LeftP AND RightG))
OR ((LocalP AND RightP) AND RootGnt))
RightGnt=(!RightP AND LocalG) OR ((LocalP AND !RightP) AND RootGnt))
LocatGnt=(!LocalP AND RootGnt)

一実施形態では、各トークン・アービタは同様に設計され、ローカル・サブツリー、左サブツリー、右サブツリーを含む。しかし、ある場合には、接続することのできる有限状態マシンまたはアービタのサブセットだけが使用される。その場合、一実施形態では、アービタ・ノードへの未使用のＧ入力とＰ入力がゼロと結びつけられる。これにより、このリクエスタに関連する不要な論理を論理合成中に除去することが可能となる。

従来技術では、トークンＦＳＭがローカル・インターフェースだけに接続された。ＦＳＭを左インターフェースまたは右インターフェースに接続する代わりに、ＦＳＭがアービトレーション・ユニットに接続され、左要求と右要求がゼロに結合される。これらの結び付きとの論理合成は、Ｕ１２を除くアービトレーション・ユニット中のすべてのゲートを除去する。Ｐがアサートされるときアービトレーション・ユニットは決してｇｒａｎｔを受け取らないので、Ｕ１２は不要である。現設計において、一実施形態では、アービトレーション・ユニットは、複数のユニットまたはサブツリーがアービトレーション・ユニットに接続されるときにだけ使用される。これにより、左サブツリーと右サブツリーを有するトークン・アービタごとの２つの論理ゲートが不要となる。

図６Ａは、ルート・ノード・アービタの一実施形態である。図６Ａに示すように、ルート・ノードでの生成信号ＲｏｏｔＧは、許可入力ＲｏｏｔＧｎｔとしてＲｏｏｔＧ自体にフィードバックされる。これによりループが完了し、現位置の後の他のノードがトークンを要求しているときにトークンをツリーの始めで再始動することが可能となる。

しかし、ＲｏｏｔＧのＲｏｏｔＧｎｔへの直接接続は最適ではない。Ｕ８の点で冗長性が存在し、同時に決してアサートされないＲｉｇｈｔＧとＲｉｇｈｔＰが共にＵ８に供給される（Ｕ２とＵ１を介するＲｉｇｈｔＧ）。さらに、ＲｉｇｈｔＧｎｔ信号とＬｏｃａｌＧｎｔ信号を計算するために、システムはまずＲｏｏｔＧｎｔを計算しなければならない。したがって、ＲｉｇｈｔＧｎｔとＬｏｃａｌＧｎｔを計算する前に遅延が存在する。

図６Ｂに、この遅延をなくす、最適化されたルート構造の一実施形態を示す。図からわかるように、この最適化されたルート構造では、すべての出力についての深さは２層だけである。

したがって、図６Ｂに示す論理は以下のようになる。
LeftGnt=(!LeftP AND RightG) OR (!LeftP AND RightP AND LocalG)
OR (LeftG And RightP and LocalP)
RightGnt=(!RightP AND LocalG) OR (!RightP AND LocalP AND LeftG)
OR (RightG AND LeftP AND LocalP)
LocalGnt=(!LocalP AND LeftG) OR (!LocalP AND LeftP AND RightG)
OR (LeftP AND LocalG AND LeftG)

一実施形態では、信号の一部が移動した距離を処理するために、アービタ・セルの出力がバッファリングされる。一実施形態では、このことが、ＡＮＤとＯＲ出力ゲートをそれぞれＮＡＮＤとＮＯＲゲートで置き換え、次いでこれらのゲートの出力を高出力インバータの入力に供給し、次いでインバータが出力を駆動することによって行われる。アービタ間の実際の配線長が求められると、手動により、あるいは自動論理合成、配置、経路指定、または目標の動作頻度を達成するための他の最適化プログラムにより、追加のバッファリングを追加することができる。

図７に有限状態マシンの一実施形態を示す。一実施形態では、Ｇ信号とＰ信号が、ラウンド・ロビン・アービトレーションに参加している各リクエスタ内に位置するトークン・アービトレーション有限状態マシン（ＰＳＭ）の０／１ホット符号化状態から直接生成される。状態マシンは、入力として、リクエスタからの要求と、アービトレーション・ツリーからのｇｒａｎｔとを取る。

ＮＯＴＯＫＥＮ状態７１０は、ＦＳＭがトークンを有さず、トークンを要求していないことを示す。したがって、Ｇ（生成）はゼロであり、渡すためのトークンがここにはないことを示し、Ｐ（伝播）は１であり、トークンがこのＦＳＭによって必要とされていないことを示す。要求を受け取った場合、状態はＮＯＴＯＫＥＮ７１０からＷＡＮＴＴＯＫＥＮ状態７２０に移る。ＷＡＮＴＴＯＫＥＮ状態７２０は、ＦＳＭがトークンを有さないがトークンを必要としていることを示し、したがってＧはゼロであり、Ｐはゼロである。ＦＳＭは、要求が許可されるまでこの状態にとどまる。一実施形態では、要求が許可されたときのクロック・サイクル中に、現要求が完了する。ｇｒａｎｔがアクティブであるときや、アクティブな要求がないときまたは優先使用がないとき、ＦＳＭはＧＥＮＴＯＫＥＮ状態７３０になる。この状態は、トークンがこのサブツリー内にあり、それに沿って渡す準備ができていることを示す。

ＧＥＮＴＯＫＥＮ状態７３０から、トークンがより高い優先順位のリクエスタに渡される場合、ＦＳＭはトークンを渡し、ＮＯＴＯＫＥＮ状態７１０に移り、要求を再び受け取るまでその状態にとどまる。ＧＥＮＴＯＫＥＮ状態７３０でｇｒａｎｔがアクティブなままである場合（例えば他のリクエスタが存在しない場合）、ｇｒａｎｔはＧＥＮＴＯＫＥＮ状態７３０のままであり、一方、要求を受け取って、要求が許可されない場合、ＦＳＭはＷＡＮＴＴＯＫＥＮ状態７２０に移る。このようにして、ＦＳＭは３つの状態間を移動する。

さらに、一実施形態では、すべてのＦＳＭは、分散された資源からの入力として優先使用信号を受け取ることができる。優先使用信号は、それによって高い優先順位のリクエスタ−ラウンド・ロビン・アービトレーションの一部ではない可能性のあるリクエスタ−が資源へのアクセスの許可を受けることができる機構である。一実施形態では、優先使用の間、ラウンド・ロビンは、トークンを付与する新しい所有者を仲裁するが、優先使用が完了するまでリクエスタの資源の使用を遅延する。優先使用信号は、すべてのリクエスタＦＳＭに配信されるグローバル信号である。ＦＳＭにトークンが付与されている間に優先使用信号がアクティブであり、要求がアクティブである場合、ＷＡＮＴＴＯＫＥＮ７２０であっても、ＧＥＮＴＯＫＥＮ状態７３０であっても、ＦＳＭはＰＲＥＥＭＰＴＥＤ状態７５０に移る。この状態では、ＦＳＭはトークンを所有するが、資源の使用を許可されていない。ＦＳＭは、優先使用と要求がアクティブである間、この状態にとどまり、トークンを保持する。要求が非アクティブになったとき、すなわち、ＦＳＭがトークンを使用することを望まないので優先使用がもはや必要でないとき、ＦＳＭ状態はＧＥＮＴＯＫＥＮ状態７３０に遷移する。

優先使用が非アクティブになった場合、すなわち、高優先順位アービトレーションが資源をＦＳＭに返すことを終了した場合、ＦＳＭはＰＲＥＥＭＰＴＥＤ状態７５０からＧＥＮＴＯＫＥＮ状態７３０に遷移する。その時点で、要求がまだアクティブである場合、例えばまだサービスされていない要求をＦＳＭがまだ有する場合、ＦＳＭは資源の使用を許可される。要求がアクティブでない場合、ＦＳＭは、許可された資源を使用することなくＧＥＮＴＯＫＥＮ状態７３０に移る。

一実施形態では、機械可読媒体が、本明細書に記載の装置および／または方法を表す情報を格納することができる。機械可読媒体は、マシン（例えばコンピュータ）が読取り可能な形式で情報を提供する（例えば格納し、かつ／または送る）任意の機構を含む。例えば、機械可読媒体は読取り専用メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、磁気ディスク記憶媒体、光記憶媒体、フラッシュ・メモリ・デバイス、ＤＶＤ、電気、光、音響、またはその他の形態の伝播信号（例えば搬送波、赤外線信号、デジタル信号、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＦＬＡＳＨ、磁気または光カード、あるいは電子命令を格納するのに適した任意のタイプの媒体）を含む。低速の媒体を、より高速のより実用的な媒体に対してキャッシュすることができる。機械可読媒体上に格納された装置および／または方法を表す情報を、本明細書に記載の装置および／または方法を作成するプロセスで使用することができる。

上記の明細書では、本発明の特定の例示的実施形態を参照しながら本発明を説明した。しかし、添付の特許請求の範囲に記載の本発明のより広い精神と範囲から逸脱することなく、本発明に対して様々な修正や変更を行えることができることは明らかであろう。したがって、明細書と図面は、限定的にではなく例示的な意味とみなすべきである。

従来技術のデイジー・チェーン・トークン・アービトレーション方式の一実装である。従来技術の集中型トークン・アービトレーション方式の一実装である。本発明のラウンド・ロビン・アービトレーション方式を使用する例示的チップ・レイアウトである。図３Ａのレイアウトを使用して得られるアービトレーション・ツリー構造を示す図である。本発明によるトークン・ツリー構造の一実施形態を示す図である。トークン・リング・アービタ・セルの一実施形態を示す図である。トークン・リング・アービタ・セルの別の実施形態を示す図である。トークン・リング・アービタ・ルート・セルの一実施形態を示す図である。トークン・リング・アービタ・ルート・セルの別の実施形態を示す図である。トークン・リング・アービトレーションを表す有限状態マシンの一実施形態を示す図である。アービタ間で８本のワイヤを使用する分散ツリー構造アービタを示す図である。

Claims

ラウンド・ロビン・トークン・アービトレーションを実現する装置であって、
それぞれがトークン・アービタまたはリクエスタを含む少なくとも２つのサブツリーが接続されたノードにそれぞれ関連する少なくとも２つのトークン・アービタ
を備える装置。
各トークン・アービタが、サブツリーを受け取るように設計された３つのコネクタを有する請求項１に記載の装置。
各アービタが、リクエスタを受け取るように設計された１つのローカル接続を有する請求項１に記載の装置。
各アービタが、ローカル接続、右接続、左接続を含む請求項１に記載の装置。
要求の優先順位が、ローカル、右、左である請求項４に記載の装置。
各アービタが、
サブツリーを受け取るように設計された各コネクタへのＧｒａｎｔ信号の出力と、
前記サブツリーの現状態を示す、各サブツリーからの一対の信号Ｇｅｎｒａｔｅ（Ｇ）とＰｒｏｐａｇａｔｅ（Ｐ）の入力と
を含む請求項１に記載の装置。
各非ルート・アービタが、
トークンがアービタに付与されたことを示すルートｇｒａｎｔ信号の入力と、
前記アービタの現状態を示す一対の信号Ｇ、Ｐの出力アップストリームと
をさらに含む請求項６に記載の装置。
前記一対の信号によって示される状態が、
前記サブツリーがトークンを有さず、前記トークンを必要としていないことを示すＮｏＴｏｋｅｎ状態と、
前記サブツリーが前記トークンを必要としていることを示すＷａｎｔＴｏｋｅｎ状態と、
前記サブツリーが前記トークンを有することを示すＧｅｎＴｏｋｅｎ状態と
を含む請求項６に記載の装置。
リクエスタが、
有限状態マシン・リクエスタがトークンを有さず、前記トークンを必要としていないことを示すＮｏＴｏｋｅｎ状態と、
前記有限状態マシン・リクエスタが前記トークンを必要としていることを示すＷａｎｔＴｏｋｅｎ状態と、
前記有限状態マシン・リクエスタが前記トークンを有することを示すＧｅｎＴｏｋｅｎ状態
という３つの状態を有する有限状態マシン・リクエスタを有する請求項１に記載の装置。
前記有限状態マシン・リクエスタが、
前記有限状態マシン・リクエスタが前記トークンを有することを示すが、前記ラウンド・ロビン・アービトレーションがより高い優先順位アービトレーションによって優先使用されたことを示す優先使用状態
という追加の状態を有する請求項９に記載の装置。
前記アービタとリクエスタがツリー構造内にレイアウトされる請求項１に記載の装置。
前記ツリー構造が、前記ルートから最も遠い葉ノードまでの最大距離を最小限に抑えるように構築される請求項１１に記載の装置。
請求項１に記載の装置を表す情報が格納された機械可読媒体。
システム・オン・チップ（ＳＯＣ）用のアービタであって、
サブツリーを受け取るための少なくとも２つのダウンストリーム・コネクタを有するルート・トークン・アービタと、
前記ルート・トークン・アービタのコネクタの１つに結合され、サブツリーを受け取るための少なくとも２つのダウンストリーム・コネクタを有するトークン・アービタとを有し、
各サブツリーがトークン・アービタまたはリクエスタを有するアービタ。
各ダウンストリーム・コネクタが、
前記コネクタに結合された前記サブツリーに前記トークンが付与されたことを示す出力信号Ｇｒａｎｔと、
前記トークンに結合された前記サブツリーのステータスを示す一対の入力信号Ｇｅｎｒａｔｅ（Ｇ）とＰｒｏｐａｇａｔｅ（Ｐ）と
を含む請求項１４に記載のアービタ。
各トークン・アービタが、アップストリーム・コネクタをさらに備える請求項１５に記載のアービタ。
前記アップストリーム・コネクタが、
前記トークン・アービタ・アップストリームのステータスを示す一対の入力信号Ｇｅｎｒａｔｅ（Ｇ）とＰｒｏｐａｇａｔｅ（Ｐ）と、
前記トークン・アービタに前記トークンが付与されたことを示す入力信号ＲｏｏｔＧｒａｎｔと
を有する請求項１６に記載のアービタ。
バッファリング信号が、前記トークン・アービタに結合された前記サブツリーに出力される請求項１４に記載のアービタ。
前記バッファリング信号が、前記トークン・アービタの出力を駆動する高出力バッファまたはインバータを使用してバッファリングされる請求項１８に記載のアービタ。
ローカル・リクエスタと少なくとも第２のトークン・アービタを受け取る第１トークン・アービタと、
前記第１トークン・アービタに結合され、少なくとも２つのリクエスタを受け取る第２トークン・アービタと
を備えるアービタ。
少なくとも２つのリクエスタの１つがローカル・リクエスタである請求項２０に記載のアービタ。
少なくとも２つのリクエスタの１つがリモート・リクエスタである請求項２０に記載のアービタ。
前記リモート・リクエスタが、第３トークン・アービタを介して前記第２トークン・アービタに結合される請求項２２に記載のアービタ。
複数の論理装置と、
前記複数の論理装置によってアクセスされる共有資源と、
前記共有資源を求める要求を生成し、前記共有資源が利用可能であるときを前記論理装置に示すために、前記複数の論理装置のそれぞれに関連付けられ、かつ
それぞれが前記有限状態マシンまたは別のトークン・アービタを有する少なくとも２つのサブツリーと関連付けられるトークン・アービタを使用してツリー構造で互いに結合される、有限状態マシン
を有し、前記共有資源を仲裁するアービトレーション論理と
を備えるシステム・オン・チップ（ＳＯＣ）。
請求項２４に記載の装置を表す情報が格納された機械可読媒体。
ツリー構造アービタの葉ノードを含む複数の有限状態マシンであって、各有限状態マシンがリクエスタと関連付けられ、２線接続で状態を上流に渡す有限状態マシンと、
ルート・ノードとブランチ・ノードを含む複数のトークン・アービタであって、有限状態マシンからの２線接続を受け、前記トークンを前記有限状態マシンにいつ付与するかを決定するトークン・アービタと
を備えるツリー構造アービタ。
トークン・アービタが、前記トークン・アービタに結合された有限状態マシンを有する請求項２６に記載のアービタ。
トークン・アービタが、トークン・アービタに結合されたドータ・トークン・アービタを有し、前記ドータ・トークン・アービタが、前記ドータ・アービタのサブツリーの状態を示す２線接続を前記トークン・アービタに渡す請求項２６に記載のアービタ。