半導体集積回路、及びリクエスト制御方法
【課題】論理規模を増大させることなく、複数のバスマスタからのリクエスト発行数を増加させる。
【解決手段】本発明による半導体集積回路100は、複数のキュー330と、複数のバスマスタ1、2から発行されたリクエストのアクセス先のアドレスに基づいて、リクエストを複数のキュー330のいずれかに振り分けるリクエスト振り分け部301と、複数のキュー330から選択したキュー内のリクエストを、外部デバイス5に発行するリクエストセレクタ302とを具備する。
【解決手段】本発明による半導体集積回路100は、複数のキュー330と、複数のバスマスタ1、2から発行されたリクエストのアクセス先のアドレスに基づいて、リクエストを複数のキュー330のいずれかに振り分けるリクエスト振り分け部301と、複数のキュー330から選択したキュー内のリクエストを、外部デバイス5に発行するリクエストセレクタ302とを具備する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、半導体集積回路、及びリクエスト制御方法に関し、特に複数のバスマスタと外部デバイスとの間のリクエスト制御方法に関する。
【背景技術】
【0002】
図1は、従来技術における半導体集積回路(LSI:Large Scale Integration)の構成の一例を示す図である。図1を参照して、LSIは、システムバス40を介して相互に接続されたCPU10、DMAコントローラ20、複数のスレーブ60−1、60−2、アドレス依存比較器70を具備する。CPU10やDMA(Direct Memory Access)コントローラ20は、システムバス40のバスマスタとして機能し、外部バスブリッジ回路に例示されるスレーブ60−1、60−2を介して、外部デバイス(例示:メモリ、入出力インタフェース(I/O)、図示なし)に対してリクエストを発行する。アドレス依存比較器70は、外部デバイスに発行されるリクエストと、それに先行するリクエストとのアドレス依存関係を確認する。アドレス依存比較器70は、バスマスタからのリクエストと同一アドレスにアクセスする先行リクエストが完了しない場合、当該バスマスタからのリクエストの発行を待機させる。
【0003】
以上のようなアドレス依存比較器70を利用したリクエスト制御を行う技術が、例えば特開2008−9763に記載されている(特許文献1参照)。
【0004】
図2は、従来技術による半導体集積回路の構成の他の一例を示す図である。図2に示す半導体集積回路は、図1に示すスレーブ60として、外部デバイス50(例示:メモリ、I/O)に接続する外部バスブリッジ30を具備する。外部バスブリッジ30は、システムバスリクエスト受信回路31、システムバスリクエスト送信回路32、コマンドキュー33、及びレスポンスキュー32を備える。
【0005】
システムバス40のバスマスタとなるCPU10、DMAコントローラ20から発行されたリクエストは、コマンドキュー33に一旦格納される。この際、コマンドキュー33への格納制御は、システムバスリクエスト受信回路31によって制御される。コマンドキュー33にはシステムバス40からのリクエストがインオーダに格納される。コマンドキュー33に格納された(積まれた)リクエストは、格納順に外部デバイス50に対して発行されて処理される。一方、外部デバイス50からのリクエスト完了通知は、レスポンスキュー34に格納され、システムバスリクエスト送信部32による制御によってCPU10やDMA20に発行される。
【0006】
外部デバイス50に対するリクエストのオーダは、スレーブ(外部バスブリッジ30)へのリクエストの到着順で守られる。例えば、本一例では、先行リクエスト(例えばライトリクエスト)の外部デバイス50への発行を待ってから、後続のリクエスト(例えばリードリクエスト)が発行されることになる。この場合、リードリクエストに対するレスポンス応答が悪くなることがある。特に、QoSが必要な処理を行わせる場合に問題が顕著化する。
【0007】
このような問題を解決するため、図3に示す半導体集積回路のように、コマンドキューとしてリードキュー35とライトキュー36を備える構成が知られている。
【先行技術文献】
【特許文献】
【0008】
【特許文献1】特開2008−9763
【発明の概要】
【発明が解決しようとする課題】
【0009】
図3に示す半導体集積回路では、リードとライトのリクエストを別々に発行できるため、図2に示す一例に比べて処理性能は向上する。しかし、メモリの排他制御を行うような場合においては、リードとライトのリクエスト発行オーダを保証する必要がある。例えば、CPU10が、アドレス“0X4000”にライトリクエストを発行し、その後に当該アドレスに対してリードリクエストを発行する場合、ライトがリードよりも先に完了する必要がある。この場合、リードキュー35とライトキュー36に格納されたリクエストのどちらを先に外部デバイス50に発行するかを判定するための機構(データ依存関係の判定機構)を、リードキュー35とライトキュー36との間に設ける必要がある。
【0010】
このため、図3に示す半導体集積回路では、性能向上のためにキューの段数を増加させる場合、増加した段数に応じたエントリのデータ依存性関係を比較する必要がある。この場合、半導体集積回路の論理規模が大きくなり、動作周波数を上げることができない等の実装上の問題が顕著化する。
【課題を解決するための手段】
【0011】
上記の課題を解決するために、本発明は、以下に述べられる手段を採用する。その手段を構成する技術的事項の記述には、[特許請求の範囲]の記載と[発明を実施するための形態]の記載との対応関係を明らかにするために、[発明を実施するための形態]で使用される番号・符号が付加されている。ただし、付加された番号・符号は、[特許請求の範囲]に記載されている発明の技術的範囲を限定的に解釈するために用いてはならない。
【0012】
本発明による半導体集積回路(100)は、複数のキュー(330)と、複数のバスマスタ(1、2)から発行されたリクエストのアクセス先のアドレスに基づいて、リクエストを複数のキュー(330)のいずれかに振り分けるリクエスト振り分け部(301)と、複数のキュー(330)から選択したキュー内のリクエストを、外部デバイス(5)に発行するリクエストセレクタ(302)とを具備する。
【0013】
本発明によるリクエスト制御方法は、複数のキュー(330)を用意するステップと、複数のバスマスタ(1、2)から発行されたリクエストのアクセス先のアドレスに基づいて、リクエストを複数のキュー(330)のいずれかに振り分けるステップと、複数のキュー(330)から選択したキュー内のリクエストを外部デバイス(5)に発行するステップとを具備する。
【0014】
本発明では、リクエストアドレスに基づいてバスマスタからのリクエストを複数のキューのいずれかに振り分けているため、キューに格納された時点で、キュー間(リクエスト間)のアドレス依存関係は解消される。すなわち、本発明では、キュー間のアドレス依存関係を比較する論理を必要としない。
【発明の効果】
【0015】
従って、本発明によれば、論理規模の増大を抑制しつつ、複数のバスマスタからのリクエスト発行数を増加させることができる。
【0016】
又、複数のバスマスタから発行されたリクエストのアドレス依存関係及び優先処理を保証しつつ、リクエスト発行数を増加させることができる。
【0017】
更に、複数のバスマスタから発行されたリクエストのアドレス依存関係及びQoS制御を保証しつつ、リクエスト発行数を増加させることができる。
【図面の簡単な説明】
【0018】
【図1】図1は、従来技術による半導体集積回路の構成の一例を示す図である。
【図2】図2は、従来技術による半導体集積回路の構成の他の一例を示す図である。
【図3】図3は、従来技術による半導体集積回路の構成の更に他の一例を示す図である。
【図4】図4は、本発明による半導体集積回路の実施の形態における構成を示す図である。
【図5】図5は、本発明による外部バスブリッジの実施の形態における構成を示す図である。
【図6】図6は、本発明によるリクエスト振り分け部の構成とウインドウの構造の一例を示す図である。
【図7】図7は、本発明によるウインドウの構造の一例を示す図である。
【図8】図8は、本発明によるリクエストセレクタの構成の一例を示す図である。
【図9A】図9Aは、本発明によるリクエスト制御動作の一例を示すフロー図である。
【図9B】図9Bは、本発明によるリクエスト制御動作の一例を示すフロー図である。
【発明を実施するための形態】
【0019】
以下、添付図面を参照しながら本発明の実施の形態を説明する。図面において同一、又は類似の参照符号は、同一、類似、又は等価な構成要素を示す。
【0020】
図4から図9A、Bを参照して、本発明による半導体集積回路の実施の形態を説明する。図4は、本発明による半導体集積回路の構成の一例を示す図である。図4を参照して、本発明による半導体集積回路は、LSIに例示され、システムバス4を介して相互に接続されたCPU1、DMAコントローラ2、及び外部バスブリッジ3を具備する。
【0021】
CPU1、DMAコントローラ2は、システムバス4のバスマスタとして機能し、外部バスブリッジ3を介して外部デバイス5(複数の外部デバイス5−1〜5−3)に対してリクエストを発行する。外部デバイス5は外部バスを介して外部バスブリッジ3に接続され、USB(Universal Serial Bus)やPCI Expressに例示されるI/Oインタフェースや、RAM(Random Access Memory)に例示されるメモリである。
【0022】
外部バスブリッジ3は、システムバス4と外部デバイス5(外部バス)との間の接続を制御し、システムバス4のスレーブとして機能する。外部バスブリッジ3は、バスマスタ(CPU1、DMAコントローラ2)が外部デバイス5に対して発行するリクエスト(リクエストコマンド、リクエストアドレス(アクセス先のアドレス))やデータを、外部デバイス5に転送する。又、外部バスブリッジ3は、外部デバイス5から発行されるリクエスト(リクエストコマンド、リクエストアドレス)やデータをバスマスタ(CPU1、DMAコントローラ2)に転送する。
【0023】
本発明による外部バスブリッジ3は、リクエスト優先処理機構を有する。図5を参照して、本発明による外部バスブリッジ3の構成の詳細を説明する。
【0024】
外部バスブリッジ3は、システムバスリクエスト受信回路として機能するリクエスト振り分け部301、送信用キュー群330、リクエストセレクタ302、受信部303、受信用キュー群320、及びシステムバスリクエスト送信回路304を具備する。
【0025】
リクエスト振り分け部301は、システムバス4を介してバスマスタ(例示:CPU1、以下、バスマスタとしてCPU1を例に説明する)から発行されるリクエストをデコードし、そのデコード結果(転送アドレスやコマンドタイプ)に従って当該リクエストを、後段の送信用キュー群330に振り分けて格納(エンキュー)する。
【0026】
送信用キュー群330は、複数のキュー331、332、333を備える。複数のキュー331、332、333にはそれぞれ異なる優先度が付与されていることが好ましい。この場合、リクエストセレクタ302は、優先度の高いキューを優先して選択し、選択したキューからリクエストを抽出して外部デバイス5に発行する。
【0027】
送信用キュー群330のうち、いくつかのキューは、リクエストの完了通知を待たずに次のリクエストを発行可能なリクエストを格納する第1キュー(以下、高優先キューと称す)に設定されることが好ましい。例えば、メモリへのアクセスのためのリクエストは、リクエストの完了(例えばリードリクエストに対するリードデータ)を待たずに発行できる。このため、メモリアクセスのためのリクエストを、高優先キューに格納するようにリクエスト振り分け部301に設定することが好ましい。又、送信用キュー群330のうちの他のキューは、次のリクエストを発行するために前のリクエストの完了通知を受ける必要があるリクエストを格納する第2キュー(以下、シーケンシャルキューと称す)に設定されることが好ましい。例えば、I/Oインタフェースへのリクエストは、リクエストの完了を待ってから次のリクエストを発行する必要がある。このため、I/Oインタフェースに発行するリクエストを、シーケンシャルキューに格納するようにリクエスト振り分け部301に設定することが好ましい。
【0028】
ここで、高優先キューは、シーケンシャルキューよりも優先的に外部デバイス5に発行される。又、複数のキューが高優先キューに設定された場合、それぞれに異なる優先度が付与されることが好ましい。本実施の形態では、キュー331、332が高優先キューとして設定され、キュー331に優先度“0”が付与され、キュー332に優先度“1”が付与されるものとする。尚、優先度“0”は優先度“1”よりも高い優先度であるものとする。又、本実施の形態では、キュー333がシーケンシャルキューに設定されるものとする。
【0029】
図6は、本発明によるリクエスト振り分け部301の構成とウインドウの構造の一例を示す図である。図6を参照して、リクエスト振り分け部301の構成の詳細を説明する。
【0030】
図6(b)を参照して、リクエスト振り分け部301は、ウインドウレジスタ310と振り分け回路314を備える。
【0031】
振り分け回路314は、システムバス4から入力されたリクエストをデコードし、デコード結果がリクエストウインドウ300にヒットする場合、ヒットしたウインドウに設定された格納先キューに当該リクエストをエンキュー(格納)する。リクエストウインドウ300は、リクエストアドレスに対応するアドレスが割り当てられた複数のウインドウを有し、それぞれにコマンド種、格納先のキューを指定する情報が設定される。
【0032】
デコードされたリクエストにはリクエストアドレス(アクセス先のアドレス)やリクエストコマンドが含まれており、リクエストアドレスに一致するアドレスが設定されたウインドウが存在(ヒット)した場合や、リクエストコマンドと同じコマンド種が設定されたウインドウが存在(ヒット)する場合、ヒットしたウインドウに設定された格納先キューに当該リクエストが格納される。
【0033】
ウインドウレジスタ310は、ベースレジスタ311、サイズレジスタ312、リクエストレジスタ313を備え、それぞれのレジスタに設定された値によって図6(a)に示すリクエストウインドウ300を設定する。ベースレジスタ311、サイズレジスタ312、リクエストレジスタ313のそれぞれは、リクエストウインドウ300に設定する複数のウインドウに対応する数だけ用意される。例えば、複数のウインドウ#0、#1、#2を有するリクエストウインドウ300を設定する場合、それぞれ3つのベースレジスタ311、サイズレジスタ312、リクエストレジスタ313が用意される。
【0034】
ウインドウ#0、#1、#2のアドレス範囲は、ベースレジスタ311及びサイズレジスタ312によって設定される。
【0035】
ベースレジスタ311には、ウインドウの先頭アドレスを指定する値が設定される。すなわち、ベースレジスタ311によって、ウインドウ#0、#1、#2のそれぞれの先頭アドレスが設定される。例えば、ウインドウ#0の先頭アドレスは“0X0000”、ウインドウ#1の先頭アドレスは“0X1000”、ウインドウ#2の先頭アドレスは“0X2000”に設定される。
【0036】
サイズレジスタ312には、ウインドウのサイズを指定する値が設定される。すなわち、サイズレジスタ312によって、ウインドウ#0、#1、#2のそれぞれのサイズが設定される。例えば、ウインドウ#0、#1、#2のそれぞれのサイズが“0X1000”に設定される。
【0037】
リクエストレジスタ313には、システムバス4からのリクエストがウインドウにヒットした場合、どのキューにエンキューするかを決める情報(格納先キュー)や、ウインドウに設定するリクエストタイプ(コマンド種)が設定される。すなわち、リクエストレジスタ313によって、ウインドウ#0、#1、#2のそれぞれにヒットしたリクエストの格納先となるキューが設定されるとともに、ウインドウのリクエストタイプ(コマンド種)が設定される。
【0038】
図7は、本発明によるウインドウ#0、#1、#2の構造の一例を示す図である。図7を参照して、リクエストウインドウ300に基づいたリクエストの振り分け処理の詳細を説明する。
【0039】
図7(a)に示す一例では、アドレス範囲が“0x0000”〜“0x0FFF”及び格納先キューが“キュー331”のウインドウ#0、アドレス範囲が“0x1000”〜“0x1FFF”及び格納先キューが“キュー331”のウインドウ#1、アドレス範囲が“0x2000”〜“0x2FFF”及び格納先キューが“キュー332”のウインドウ#2がリクエストウインドウ300として設定される。本一例では、ウインドウ#0、#1、#2のいずれにもコマンド種は設定されていない。
【0040】
図7(a)のように、リクエストウインドウ300にコマンド種が設定されていない場合、振り分け回路314は、デコードしたリクエストアドレスが一致するウインドウを検索し、ヒット(一致)したウインドウに基づいてリクエストの格納先を決定する。例えば、リクエストアドレスが“0X1005である場合、リクエストはウインドウ#1にヒットする。この場合、振り分け回路314は、ウインドウ#1の格納先キューに設定されているキュー331(優先度“0”)に当該リクエストをエンキュー(格納)する。あるいは、リクエストアドレスが“0X2010である場合、リクエストはウインドウ#2にヒットする。この場合、振り分け回路314は、ウインドウ#2の格納先キューに設定されているキュー332(優先度“1”)に当該リクエストをエンキュー(格納)する。更に、リクエストアドレスがリクエストウインドウ300に設定されていないアドレスである場合(例えば“0X3000”)、リクエストにヒットするウインドウは存在しない。この場合、振り分け回路314は、リクエストをキュー333(シーケンシャルキュー)にエンキュー(格納)する。
【0041】
ウインドウにヒットするか否かの判定は、ウインドウ番号の若い順から行われる。例えば、誤って、複数のウインドウ#0、#1に同じアドレスが設定されていても、アドレスが小さいウインドウ#0から順に判定されるため、リクエストが複数のウインドウに重複してヒットすることはない。すなわち、リクエストがヒットするウインドウの検索順に優先順位をつけることで、ウインドウの設定ミスによる誤動作を防止することができる。
【0042】
図7(b)に示す一例では、コマンド種が“メモリリード”、アドレス範囲が“0x0000”〜“0x0FFF”及び格納先キューが“キュー331”のウインドウ#0、コマンド種が“I/Oアクセス”、アドレス範囲が“0x1000”〜“0x1FFF”及び及び格納先キューが“キュー332”のウインドウ#1、
アドレス範囲が“0x2000”〜“0x2FFF”及び格納先キューが“キュー333”のウインドウ#2がリクエストウインドウ300として設定される。
【0043】
図7(b)のように、振り分け回路314は、デコードしたリクエストアドレス又は/及びコマンド種と一致するウインドウを検索し、ヒット(一致)したウインドウに基づいてリクエストの格納先を決定する。例えば、リクエストアドレスが“0X0100であり、コマンド種がメモリアクセスである場合、リクエストはウインドウ#0にヒットする。この場合、振り分け回路314は、ウインドウ#0の格納先キューに設定されているキュー331(優先度“0”)に当該リクエストをエンキュー(格納)する。ウインドウ#0やウインドウ#1にヒットするためには、アドレス及びコマンド種が一致しなければならない。一方、リクエストアドレスが“0X2010である場合、コマンド種に関係なくリクエストはウインドウ#2にヒットする。この場合、振り分け回路314は、ウインドウ#2の格納先キューに設定されているキュー333(シーケンシャルキュー)に当該リクエストをエンキュー(格納)する。
【0044】
更に、リクエストアドレスがリクエストウインドウ300に設定されていないアドレス(例えば“0X3000”)の場合、アドレスが一致してもコマンド種がリクエストウインドウ300に設定されたコマンドと異なる場合、あるいは、コマンド種が一致してもリクエストアドレスがリクエストウインドウ300に設定されたアドレスと異なる場合は、リクエストにヒットするウインドウは存在しないと判定される。この場合、振り分け回路314は、リクエストをキュー333(シーケンシャルキュー)にエンキュー(格納)する。例えば、リクエストのアドレスが0x0100でI/Oアクセスの場合、ヒットするウインドウは存在せず、当該リクエストはキュー333に格納される。
【0045】
図7(c)に示す一例では、アドレス範囲が“0x0000”〜“0x0FFF”及び格納先キューが“キュー331”のウインドウ#0、コマンド種が“メモリリード”及び格納先キューが“キュー332”のウインドウ#1、コマンド種が“I/Oアクセス”及び格納先キューが“キュー333”のウインドウ#2がリクエストウインドウ300として設定される。本一例では、ウインドウ#1、#2にアドレス範囲は設定されない。
【0046】
図7(c)のように、振り分け回路314は、デコードしたリクエストアドレス又はコマンド種と一致するウインドウを検索し、ヒット(一致)したウインドウに基づいてリクエストの格納先を決定する。例えば、リクエストアドレスが“0X0100である場合、リクエストはウインドウ#0にヒットする。この場合、振り分け回路314は、ウインドウ#0の格納先キューに設定されているキュー331(優先度“0”)に当該リクエストをエンキュー(格納)する。あるいは、リクエストアドレスが任意であり、コマンド種がメモリリードである場合、リクエストはウインドウ#1にヒットする。この場合、振り分け回路314は、ウインドウ#1の格納先キューに設定されているキュー332(優先度“1”)に当該リクエストをエンキュー(格納)する。更に、リクエストアドレスがリクエストウインドウ300に設定されていないアドレス(例えば“0X3000”)の場合、リクエストにヒットするウインドウは存在しない。この場合、振り分け回路314は、リクエストをキュー333(シーケンシャルキュー)にエンキュー(格納)する。リクエストがリクエストウインドウ300にヒットするか否かが、コマンド種(例えばメモリアクセス、I/Oアクセス)でしか判断できない場合、当該リクエストの転送先アドレスとして、システムバス4からのリクエストアドレスが割り当てられる。
【0047】
以上のように、ウインドウに設定するアドレスやコマンド種を、実行するプロセスに応じて設定することで、アクセス先のアドレスや実行するコマンドに応じた格納先キューを変更することができる。尚、ウインドウにヒットしないリクエストがある場合、エラーを返しても良いし、当該リクエストを破棄しても良い。
【0048】
本発明によるリクエスト振り分け部301は、リクエスト間のアドレスを比較することなく、入力されたリクエストアドレスやコマンド種に応じて格納先のキューを決定することができる。すなわち、本発明では、各キューにエンキューされた時点で、アドレス依存関係は解消されている。このため、後段のリクエストセレクタ302は、アドレス依存関係や、コマンドの発行順を気にすることなく処理対象のキューを選択することができる。
【0049】
リクエストセレクタ302は、送信用キュー群330から選択したキュー内のリクエストを外部デバイス5に発行する。リクエストセレクタ302は、優先度の高いキューを優先的に選択し、選択したキュー内のリクエストを外部デバイス5に発行することが好ましい。
【0050】
リクエストセレクタ302は、高優先キュー(キュー331、332)からリクエストを抽出して発行する場合、外部デバイス5に発行したリクエストの完了通知を受けることなく、高優先キューから次のリクエストを抽出して発行することが好ましい。詳細には、リクエストセレクタ302は、高優先キュー(キュー331、332)内のリクエストを発行する際、受信部303に高優先リクエストの発行を通知する。受信部303は、高優先リクエストの発行通知に応じてACK信号(コマンドアクノリッジ)を返却する。リクエストセレクタ302は、受信部303からのACK信号に応じて次のリクエストを高優先キューから抽出して発行する。これにより、高優先キューに格納された次のリクエストは、前に発行されたリクエストの完了を待たずに発行され得る。例えば、リクエストセレクタ302は、リードコマンドに対するリードレスポンス(リードデータ)が返却される前に、高優先キュー内の次のリクエストを発行することができる。
【0051】
一方、リクエストセレクタ302は、シーケンシャルキュー(キュー333)からリクエストを抽出して発行する場合、発行したリクエストの受信完了通知を受けてから次ぎのリクエストを発行する。詳細には、リクエストセレクタ302は、シーケンシャルキュー(キュー333)内のリクエストを通常通り発行する。受信部303は、外部デバイス5から当該リクエストの完了通知を受け取るとリクエストセレクタ302にACK信号(コマンドアクノリッジ)を出力する。リクエストセレクタ302は、受信部303からのACK信号に応じて次のリクエストをシーケンシャルキューから抽出して発行する。これにより、シーケンシャルキューに格納された次のリクエストは、前に発行されたリクエストの完了に応じて発行されることになる。例えば、リクエストセレクタ302は、リードコマンドに対するリードレスポンス(リードデータ)が受信部303に返却されるまで、シーケンシャルキュー内の次のリクエストを発行せずに待機する。
【0052】
図8は、本発明によるリクエストセレクタ302の構成の一例を示す図である。図8を参照して、リクエストセレクタ302は、FULL判定用フラグ321、優先処理判定回路322、セレクタ323を備える。
【0053】
優先処理判定回路322は、優先処理判定回路322は、各キューにエンキュー(格納)されたリクエスト数に応じて優先処理判定を行い、処理対象となるキューを決定する。この際、優先処理判定回路322は、優先度の高いキューから順に格納状況を確認し、高い優先度のキュー331にリクエストが格納されていない場合、次に優先度の高いキューを処理対象としてセレクタ323に指定する。尚、シーケンシャルキューは最も優先度が低いものとする。又、優先処理判定回路322は、高優先キューがリクエストによって満たされた(FULLとなる)場合、当該キュー内のリクエストを全て発行した後、次に優先度の高いキューを処理対象としてセレクタ323に指定する。
【0054】
FULL判定用フラグ321は、高優先キューがリクエストによってFULLとなったか否かを示すフラグである。FULL判定用フラグ321は、高優先キューに設定されたキュー331、332のそれぞれに対応して設けられる。例えば、リクエストによってFULLとなったキューのFULL判定用フラグ321に“1”がセットされる。優先処理判定回路322は、FULL判定用フラグ321によってFULLとなったキューを確認できる。
【0055】
セレクタ323は、優先処理判定回路322によって処理対象として指定されたキューからリクエストを抽出し、リクエストの内容に応じた外部デバイス5に当該リクエストを発行する。
【0056】
以上のような構成により、リクエストセレクタ302は、高優先キューがリクエストによって満たされる(FULLになる)まで当該高優先キューを処理する。本発明では、高優先のキューがFULLになったことをトリガとして、優先度の低いキューが処理される。これにより、優先度の低いキューに格納されたリクエストが発行されずに、システムがライブロックとなることを防止することができる。
【0057】
図9A及び図9Bを参照して、リクエストセレクタ302による優先処理制御方法の詳細を説明する。図9A及び図9Bは、本発明によるリクエスト制御動作の一例を示すフロー図である。
【0058】
リクエストセレクタ302は、先ず、用意された送信用キュー群330の中で最も優先度の高いキュー331(優先度“0”)にリクエストが積まれている(格納されている)か否かを確認する(ステップS101)。キュー331にリクエストが積まれている(格納されている)場合、リクエストセレクタ302は、キュー331のリクエストを外部デバイス5に発行する(ステップS101Yes、S102)。
【0059】
次に、リクエストセレクタ302は、FULL判定用フラグ321を参照して、キュー331がリクエストによってFULLになったかを確認する(ステップS103)。ここで、キュー331がFULLでない場合、ステップS101に移行する(ステップS103No)。一方、キュー331がFULLとなった場合、キュー331に対応するFULL判定用フラグ321にFULLを示す“1”がセットされ、リクエストセレクタ302は、その時点でキュー331内に格納されたリクエストを全て外部デバイス5に発行するまで処理を続ける(ステップS103Yes、S104、S105No)。
【0060】
優先処理キュー331にリクエストが積まれていない場合(ステップS101No)、あるいは、FULLとなったキュー331内の全てのリクエストを処理した場合(ステップS105Yes)、リクエストセレクタ302は、次に優先度の高いキュー332(優先度“1”)にリクエストが積まれている(格納されている)か否かを確認する(ステップS201)。
【0061】
キュー332にリクエストが積まれている場合、リクエストセレクタ302は、キュー332のリクエストを外部デバイス5に発行する(ステップS201Yes、S202)。
【0062】
次に、リクエストセレクタ302は、FULL判定用フラグ321を参照して、キュー332より優先度の高いキュー331のFULL判定用フラグ321にFULLを示す“1”がセットされているかを確認する(ステップS203)。ここで、キュー331のFULL判定用フラグ321にFULLを示す“1”がセットされていない場合、ステップS101に移行する(ステップS203No)。すなわち、優先度の高いキュー331にリクエストがないことをトリガとしてキュー332を処理する場合、リクエストセレクタ302は、キュー332の処理後、優先度の高いキュー331を優先的に処理するように制御される。
【0063】
ステップS203において、FULLを示す“1”がセットされている場合、リクエストセレクタ302は、FULL判定用フラグ321を参照して、キュー332がFULLになったかを確認する(ステップS203Yes、S204)。
【0064】
ステップS204において、キュー332がFULLでない場合、ステップS201に移行する(ステップS204No)。すなわち、優先度の高いキュー331がFULLとなったことをトリガとしてキュー332を処理する場合、リクエストセレクタ302は、キュー332の処理又はキュー332より低い優先度の処理を継続する。
【0065】
一方、キュー332がFULLとなった場合、キュー332に対応するFULL判定用フラグ321にFULLを示す“1”がセットされ、リクエストセレクタ302は、その時点でキュー332内に格納されたリクエストを全て外部デバイス5に発行するまで処理を続ける(ステップS204Yes、S205、S206No)。
【0066】
優先処理キュー332にリクエストが積まれていない場合(ステップS201No)、あるいは、FULLとなったキュー332内の全てのリクエストを処理した場合(ステップS206Yes)、リクエストセレクタ302は、次に優先度の高いキュー(ここではシーケンシャルキュー(キュー333))にリクエストが積まれているか否かを確認する(ステップS301)。
【0067】
キュー333にリクエストが積まれている場合、リクエストセレクタ302は、キュー333のリクエストを外部デバイス5に発行する(ステップS301Yes、S302)。一方、キュー333にリクエストが積まれていない場合、ステップS101に以降する(ステップS301No)。
【0068】
ステップS302においてキュー333に対する処理を行ったリクエストセレクタ302は、FULL判定用フラグ321を参照して、キュー333より優先度の高いキュー331、332のFULL判定用フラグ321にFULLを示す“1”がセットされているかを確認する(ステップS303、S304)。ここで、キュー331、332のFULL判定用フラグ321にFULLを示す“1”がセットされていない場合、ステップS101に移行する(ステップS303No、S304No)。すなわち、高優先キュー(キュー331、332)にリクエストがないことをトリガとしてシーケンシャルキュー(キュー333)を処理する場合、リクエストセレクタ302は、キュー333の処理後、最も優先度の高いキュー331を優先的に処理するように制御される。
【0069】
ステップS303、S304において、キュー331、332のFULL判定用フラグ321の両方にFULLを示す“1”がセットされている場合、リクエストセレクタ302は、キュー333内にリクエストが格納されていない(empty)ことを確認する(ステップS303Yes、S304Yes、S305)。
【0070】
ステップS305において、キュー332がemptyでない場合、ステップS302に移行する(ステップS305No)。すなわち、優先度の高いキュー331、332がFULLとなったことをトリガとしてキュー333を処理する場合、リクエストセレクタ302は、キュー333内の全てのリクエストを発行するまで、キュー333に対する処理を継続する。
【0071】
一方、キュー333がemptyとなった場合、リクエストセレクタ302は、全ての高優先キュー(キュー331、332)のFULL判定用フラグ321に設定された“1”を“0”にクリアする(ステップS305Yes、S306)。FULL判定用フラグ321をクリア後、ステップS101に移行し、リクエストセレクタ302は、再度、優先度の高いキューを優先して処理を行う。
【0072】
以上のように、本発明では、複数のキューのうち、どのキューからリクエストを選択するかを、優先処理判定回路322によって決定している。このため、各キュー間のリクエストは、アウトオブオーダーで発行される。ただし、キュー内のリクエストは、リクエストに積まれた順(エンキュー順)に処理されるためインオーダで発行される。
【0073】
優先処理判定回路322は、FULL判定用フラグ321を利用することで、高優先キューがFULLとなったことをトリガとして、低優先キューやシーケンシャルキューを処理対象として選択する。これにより、優先度の低いキューに格納されたリクエストが発行されずに、システムがライブロックとなることを防止することができる。
【0074】
受信部303は、外部デバイス5からのリクエスト(リクエストコマンド、リクエストアドレス)を受信し、受信用キュー群320に格納する。受信用キュー群320は、ライトリクエストを格納するライトキュー341と、リードリクエストを格納するリードキュー342を備える。受信部303は、外部デバイス5からのライトリクエストをライトキュー341に格納し、外部デバイス5からのリードリクエストをリードキュー342に格納する。ライトキュー341内のリクエストは、リードキュー342に優先してシステムバスリクエスト送信回路304に出力される。これは、一般的なPCIで規定された機能であるため、詳細な説明は省略する。
【0075】
システムバスリクエスト送信回路304は、ライトキュー341又はリードキュー342の一方から出力されたリクエストを、システムバス4を介してバスマスタであるCPU1、又はDMAコントローラ2に発行する。
【0076】
本発明によるリクエスト振り分け部301は、リクエスト間のアドレス依存関係をキューにエンキューする前に解決し、複数のキューに振り分けている。このため、キュー間のアドレス依存関係を比較する必要がなくなり、システムバス4からのリクエストを直ぐにエンキューすることができる。又、複数のキューにエンキューされたリクエストは、既にアドレス依存関係が解消されているため、処理対象となるキュー任意に選択しても、アクセス先が競合することなくリクエストを発行することができる。このため、実装上の問題を気にすることなくスケーラブルにキューの段数を増やすことが可能となる。
【0077】
更に、各キューに優先度が付与されており、リクエストセレクタ302はその優先度に従って処理対象となるキューを選択する。これにより、発行元のリクエストやコマンド種に優先順位を付与することが可能となり、優先処理させたいリクエストを外部バスブリッジ3に留めることなく、発行することが可能となる。例えば、リードリクエストを優先度の高いキューに格納し、ライトリクエストを優先度の低いキューに格納することで、先にマスタから発行されたライトリクエストよりも先に、リードリクエストを外部デバイス5に発行することできる。従って本発明によれば、従来構成で問題となっていたリードレイテンシを改善することができる。
【0078】
又、コマンド種として、特定処理(例えば、音声処理や画像処理)に阿智するリクエストを優先度の高いキューにエンキューすることで、特定処理に対する優先処理が可能となる。I/Oリクエスト等、発行オーダの保証が必要なリクエストは、シーケンシャルキュー(キュー333)に格納することで、従来と同様に発行オーダを保証することができる。
【0079】
本発明では、複数のキューにリクエストを格納する前にアドレス依存関係を解消しているため、従来技術のように論理規模を増大させることなく、複数のバスマスタからのリクエスト発行数を増加させることができる。
【0080】
又、複数のバスマスタから発行されたリクエストのアドレス依存関係及び優先処理を保証しつつ、リクエスト発行数を増加させることができる。
【0081】
更に、複数のバスマスタから発行されたリクエストのアドレス依存関係及びQoS制御を保証しつつ、リクエスト発行数を増加させることができる。
【0082】
以上、本発明の実施の形態を詳述してきたが、具体的な構成は上記実施の形態に限られるものではなく、本発明の要旨を逸脱しない範囲の変更があっても本発明に含まれる。上述の実施の形態では、送信用キューとして3つのキュー331、332、333を備える外部バスブリッジ3を一例に説明したが、その数や優先度やシーケンシャルキューの設定はこれに限らない。
【符号の説明】
【0083】
1 :CPU
2 :DMAコントローラ
3 :外部バスブリッジ
4 :システムバス
5 :外部デバイス
100:半導体集積回路
300:リクエストウインドウ
301:リクエスト振り分け部
302:リクエストセレクタ
303:受信部
304:システムバスリクエスト送信回路
310:ウインドウレジスタ
311:ベースレジスタ
312:サイズレジスタ
313:リクエストレジスタ
314:振り分け回路
320:受信用キュー群
321:FULL判定用フラグ
322:優先処理判定回路
323:セレクタ
330:送信用キュー群
331〜333:キュー
341:ライトキュー
342:リードキュー
【技術分野】
【0001】
本発明は、半導体集積回路、及びリクエスト制御方法に関し、特に複数のバスマスタと外部デバイスとの間のリクエスト制御方法に関する。
【背景技術】
【0002】
図1は、従来技術における半導体集積回路(LSI:Large Scale Integration)の構成の一例を示す図である。図1を参照して、LSIは、システムバス40を介して相互に接続されたCPU10、DMAコントローラ20、複数のスレーブ60−1、60−2、アドレス依存比較器70を具備する。CPU10やDMA(Direct Memory Access)コントローラ20は、システムバス40のバスマスタとして機能し、外部バスブリッジ回路に例示されるスレーブ60−1、60−2を介して、外部デバイス(例示:メモリ、入出力インタフェース(I/O)、図示なし)に対してリクエストを発行する。アドレス依存比較器70は、外部デバイスに発行されるリクエストと、それに先行するリクエストとのアドレス依存関係を確認する。アドレス依存比較器70は、バスマスタからのリクエストと同一アドレスにアクセスする先行リクエストが完了しない場合、当該バスマスタからのリクエストの発行を待機させる。
【0003】
以上のようなアドレス依存比較器70を利用したリクエスト制御を行う技術が、例えば特開2008−9763に記載されている(特許文献1参照)。
【0004】
図2は、従来技術による半導体集積回路の構成の他の一例を示す図である。図2に示す半導体集積回路は、図1に示すスレーブ60として、外部デバイス50(例示:メモリ、I/O)に接続する外部バスブリッジ30を具備する。外部バスブリッジ30は、システムバスリクエスト受信回路31、システムバスリクエスト送信回路32、コマンドキュー33、及びレスポンスキュー32を備える。
【0005】
システムバス40のバスマスタとなるCPU10、DMAコントローラ20から発行されたリクエストは、コマンドキュー33に一旦格納される。この際、コマンドキュー33への格納制御は、システムバスリクエスト受信回路31によって制御される。コマンドキュー33にはシステムバス40からのリクエストがインオーダに格納される。コマンドキュー33に格納された(積まれた)リクエストは、格納順に外部デバイス50に対して発行されて処理される。一方、外部デバイス50からのリクエスト完了通知は、レスポンスキュー34に格納され、システムバスリクエスト送信部32による制御によってCPU10やDMA20に発行される。
【0006】
外部デバイス50に対するリクエストのオーダは、スレーブ(外部バスブリッジ30)へのリクエストの到着順で守られる。例えば、本一例では、先行リクエスト(例えばライトリクエスト)の外部デバイス50への発行を待ってから、後続のリクエスト(例えばリードリクエスト)が発行されることになる。この場合、リードリクエストに対するレスポンス応答が悪くなることがある。特に、QoSが必要な処理を行わせる場合に問題が顕著化する。
【0007】
このような問題を解決するため、図3に示す半導体集積回路のように、コマンドキューとしてリードキュー35とライトキュー36を備える構成が知られている。
【先行技術文献】
【特許文献】
【0008】
【特許文献1】特開2008−9763
【発明の概要】
【発明が解決しようとする課題】
【0009】
図3に示す半導体集積回路では、リードとライトのリクエストを別々に発行できるため、図2に示す一例に比べて処理性能は向上する。しかし、メモリの排他制御を行うような場合においては、リードとライトのリクエスト発行オーダを保証する必要がある。例えば、CPU10が、アドレス“0X4000”にライトリクエストを発行し、その後に当該アドレスに対してリードリクエストを発行する場合、ライトがリードよりも先に完了する必要がある。この場合、リードキュー35とライトキュー36に格納されたリクエストのどちらを先に外部デバイス50に発行するかを判定するための機構(データ依存関係の判定機構)を、リードキュー35とライトキュー36との間に設ける必要がある。
【0010】
このため、図3に示す半導体集積回路では、性能向上のためにキューの段数を増加させる場合、増加した段数に応じたエントリのデータ依存性関係を比較する必要がある。この場合、半導体集積回路の論理規模が大きくなり、動作周波数を上げることができない等の実装上の問題が顕著化する。
【課題を解決するための手段】
【0011】
上記の課題を解決するために、本発明は、以下に述べられる手段を採用する。その手段を構成する技術的事項の記述には、[特許請求の範囲]の記載と[発明を実施するための形態]の記載との対応関係を明らかにするために、[発明を実施するための形態]で使用される番号・符号が付加されている。ただし、付加された番号・符号は、[特許請求の範囲]に記載されている発明の技術的範囲を限定的に解釈するために用いてはならない。
【0012】
本発明による半導体集積回路(100)は、複数のキュー(330)と、複数のバスマスタ(1、2)から発行されたリクエストのアクセス先のアドレスに基づいて、リクエストを複数のキュー(330)のいずれかに振り分けるリクエスト振り分け部(301)と、複数のキュー(330)から選択したキュー内のリクエストを、外部デバイス(5)に発行するリクエストセレクタ(302)とを具備する。
【0013】
本発明によるリクエスト制御方法は、複数のキュー(330)を用意するステップと、複数のバスマスタ(1、2)から発行されたリクエストのアクセス先のアドレスに基づいて、リクエストを複数のキュー(330)のいずれかに振り分けるステップと、複数のキュー(330)から選択したキュー内のリクエストを外部デバイス(5)に発行するステップとを具備する。
【0014】
本発明では、リクエストアドレスに基づいてバスマスタからのリクエストを複数のキューのいずれかに振り分けているため、キューに格納された時点で、キュー間(リクエスト間)のアドレス依存関係は解消される。すなわち、本発明では、キュー間のアドレス依存関係を比較する論理を必要としない。
【発明の効果】
【0015】
従って、本発明によれば、論理規模の増大を抑制しつつ、複数のバスマスタからのリクエスト発行数を増加させることができる。
【0016】
又、複数のバスマスタから発行されたリクエストのアドレス依存関係及び優先処理を保証しつつ、リクエスト発行数を増加させることができる。
【0017】
更に、複数のバスマスタから発行されたリクエストのアドレス依存関係及びQoS制御を保証しつつ、リクエスト発行数を増加させることができる。
【図面の簡単な説明】
【0018】
【図1】図1は、従来技術による半導体集積回路の構成の一例を示す図である。
【図2】図2は、従来技術による半導体集積回路の構成の他の一例を示す図である。
【図3】図3は、従来技術による半導体集積回路の構成の更に他の一例を示す図である。
【図4】図4は、本発明による半導体集積回路の実施の形態における構成を示す図である。
【図5】図5は、本発明による外部バスブリッジの実施の形態における構成を示す図である。
【図6】図6は、本発明によるリクエスト振り分け部の構成とウインドウの構造の一例を示す図である。
【図7】図7は、本発明によるウインドウの構造の一例を示す図である。
【図8】図8は、本発明によるリクエストセレクタの構成の一例を示す図である。
【図9A】図9Aは、本発明によるリクエスト制御動作の一例を示すフロー図である。
【図9B】図9Bは、本発明によるリクエスト制御動作の一例を示すフロー図である。
【発明を実施するための形態】
【0019】
以下、添付図面を参照しながら本発明の実施の形態を説明する。図面において同一、又は類似の参照符号は、同一、類似、又は等価な構成要素を示す。
【0020】
図4から図9A、Bを参照して、本発明による半導体集積回路の実施の形態を説明する。図4は、本発明による半導体集積回路の構成の一例を示す図である。図4を参照して、本発明による半導体集積回路は、LSIに例示され、システムバス4を介して相互に接続されたCPU1、DMAコントローラ2、及び外部バスブリッジ3を具備する。
【0021】
CPU1、DMAコントローラ2は、システムバス4のバスマスタとして機能し、外部バスブリッジ3を介して外部デバイス5(複数の外部デバイス5−1〜5−3)に対してリクエストを発行する。外部デバイス5は外部バスを介して外部バスブリッジ3に接続され、USB(Universal Serial Bus)やPCI Expressに例示されるI/Oインタフェースや、RAM(Random Access Memory)に例示されるメモリである。
【0022】
外部バスブリッジ3は、システムバス4と外部デバイス5(外部バス)との間の接続を制御し、システムバス4のスレーブとして機能する。外部バスブリッジ3は、バスマスタ(CPU1、DMAコントローラ2)が外部デバイス5に対して発行するリクエスト(リクエストコマンド、リクエストアドレス(アクセス先のアドレス))やデータを、外部デバイス5に転送する。又、外部バスブリッジ3は、外部デバイス5から発行されるリクエスト(リクエストコマンド、リクエストアドレス)やデータをバスマスタ(CPU1、DMAコントローラ2)に転送する。
【0023】
本発明による外部バスブリッジ3は、リクエスト優先処理機構を有する。図5を参照して、本発明による外部バスブリッジ3の構成の詳細を説明する。
【0024】
外部バスブリッジ3は、システムバスリクエスト受信回路として機能するリクエスト振り分け部301、送信用キュー群330、リクエストセレクタ302、受信部303、受信用キュー群320、及びシステムバスリクエスト送信回路304を具備する。
【0025】
リクエスト振り分け部301は、システムバス4を介してバスマスタ(例示:CPU1、以下、バスマスタとしてCPU1を例に説明する)から発行されるリクエストをデコードし、そのデコード結果(転送アドレスやコマンドタイプ)に従って当該リクエストを、後段の送信用キュー群330に振り分けて格納(エンキュー)する。
【0026】
送信用キュー群330は、複数のキュー331、332、333を備える。複数のキュー331、332、333にはそれぞれ異なる優先度が付与されていることが好ましい。この場合、リクエストセレクタ302は、優先度の高いキューを優先して選択し、選択したキューからリクエストを抽出して外部デバイス5に発行する。
【0027】
送信用キュー群330のうち、いくつかのキューは、リクエストの完了通知を待たずに次のリクエストを発行可能なリクエストを格納する第1キュー(以下、高優先キューと称す)に設定されることが好ましい。例えば、メモリへのアクセスのためのリクエストは、リクエストの完了(例えばリードリクエストに対するリードデータ)を待たずに発行できる。このため、メモリアクセスのためのリクエストを、高優先キューに格納するようにリクエスト振り分け部301に設定することが好ましい。又、送信用キュー群330のうちの他のキューは、次のリクエストを発行するために前のリクエストの完了通知を受ける必要があるリクエストを格納する第2キュー(以下、シーケンシャルキューと称す)に設定されることが好ましい。例えば、I/Oインタフェースへのリクエストは、リクエストの完了を待ってから次のリクエストを発行する必要がある。このため、I/Oインタフェースに発行するリクエストを、シーケンシャルキューに格納するようにリクエスト振り分け部301に設定することが好ましい。
【0028】
ここで、高優先キューは、シーケンシャルキューよりも優先的に外部デバイス5に発行される。又、複数のキューが高優先キューに設定された場合、それぞれに異なる優先度が付与されることが好ましい。本実施の形態では、キュー331、332が高優先キューとして設定され、キュー331に優先度“0”が付与され、キュー332に優先度“1”が付与されるものとする。尚、優先度“0”は優先度“1”よりも高い優先度であるものとする。又、本実施の形態では、キュー333がシーケンシャルキューに設定されるものとする。
【0029】
図6は、本発明によるリクエスト振り分け部301の構成とウインドウの構造の一例を示す図である。図6を参照して、リクエスト振り分け部301の構成の詳細を説明する。
【0030】
図6(b)を参照して、リクエスト振り分け部301は、ウインドウレジスタ310と振り分け回路314を備える。
【0031】
振り分け回路314は、システムバス4から入力されたリクエストをデコードし、デコード結果がリクエストウインドウ300にヒットする場合、ヒットしたウインドウに設定された格納先キューに当該リクエストをエンキュー(格納)する。リクエストウインドウ300は、リクエストアドレスに対応するアドレスが割り当てられた複数のウインドウを有し、それぞれにコマンド種、格納先のキューを指定する情報が設定される。
【0032】
デコードされたリクエストにはリクエストアドレス(アクセス先のアドレス)やリクエストコマンドが含まれており、リクエストアドレスに一致するアドレスが設定されたウインドウが存在(ヒット)した場合や、リクエストコマンドと同じコマンド種が設定されたウインドウが存在(ヒット)する場合、ヒットしたウインドウに設定された格納先キューに当該リクエストが格納される。
【0033】
ウインドウレジスタ310は、ベースレジスタ311、サイズレジスタ312、リクエストレジスタ313を備え、それぞれのレジスタに設定された値によって図6(a)に示すリクエストウインドウ300を設定する。ベースレジスタ311、サイズレジスタ312、リクエストレジスタ313のそれぞれは、リクエストウインドウ300に設定する複数のウインドウに対応する数だけ用意される。例えば、複数のウインドウ#0、#1、#2を有するリクエストウインドウ300を設定する場合、それぞれ3つのベースレジスタ311、サイズレジスタ312、リクエストレジスタ313が用意される。
【0034】
ウインドウ#0、#1、#2のアドレス範囲は、ベースレジスタ311及びサイズレジスタ312によって設定される。
【0035】
ベースレジスタ311には、ウインドウの先頭アドレスを指定する値が設定される。すなわち、ベースレジスタ311によって、ウインドウ#0、#1、#2のそれぞれの先頭アドレスが設定される。例えば、ウインドウ#0の先頭アドレスは“0X0000”、ウインドウ#1の先頭アドレスは“0X1000”、ウインドウ#2の先頭アドレスは“0X2000”に設定される。
【0036】
サイズレジスタ312には、ウインドウのサイズを指定する値が設定される。すなわち、サイズレジスタ312によって、ウインドウ#0、#1、#2のそれぞれのサイズが設定される。例えば、ウインドウ#0、#1、#2のそれぞれのサイズが“0X1000”に設定される。
【0037】
リクエストレジスタ313には、システムバス4からのリクエストがウインドウにヒットした場合、どのキューにエンキューするかを決める情報(格納先キュー)や、ウインドウに設定するリクエストタイプ(コマンド種)が設定される。すなわち、リクエストレジスタ313によって、ウインドウ#0、#1、#2のそれぞれにヒットしたリクエストの格納先となるキューが設定されるとともに、ウインドウのリクエストタイプ(コマンド種)が設定される。
【0038】
図7は、本発明によるウインドウ#0、#1、#2の構造の一例を示す図である。図7を参照して、リクエストウインドウ300に基づいたリクエストの振り分け処理の詳細を説明する。
【0039】
図7(a)に示す一例では、アドレス範囲が“0x0000”〜“0x0FFF”及び格納先キューが“キュー331”のウインドウ#0、アドレス範囲が“0x1000”〜“0x1FFF”及び格納先キューが“キュー331”のウインドウ#1、アドレス範囲が“0x2000”〜“0x2FFF”及び格納先キューが“キュー332”のウインドウ#2がリクエストウインドウ300として設定される。本一例では、ウインドウ#0、#1、#2のいずれにもコマンド種は設定されていない。
【0040】
図7(a)のように、リクエストウインドウ300にコマンド種が設定されていない場合、振り分け回路314は、デコードしたリクエストアドレスが一致するウインドウを検索し、ヒット(一致)したウインドウに基づいてリクエストの格納先を決定する。例えば、リクエストアドレスが“0X1005である場合、リクエストはウインドウ#1にヒットする。この場合、振り分け回路314は、ウインドウ#1の格納先キューに設定されているキュー331(優先度“0”)に当該リクエストをエンキュー(格納)する。あるいは、リクエストアドレスが“0X2010である場合、リクエストはウインドウ#2にヒットする。この場合、振り分け回路314は、ウインドウ#2の格納先キューに設定されているキュー332(優先度“1”)に当該リクエストをエンキュー(格納)する。更に、リクエストアドレスがリクエストウインドウ300に設定されていないアドレスである場合(例えば“0X3000”)、リクエストにヒットするウインドウは存在しない。この場合、振り分け回路314は、リクエストをキュー333(シーケンシャルキュー)にエンキュー(格納)する。
【0041】
ウインドウにヒットするか否かの判定は、ウインドウ番号の若い順から行われる。例えば、誤って、複数のウインドウ#0、#1に同じアドレスが設定されていても、アドレスが小さいウインドウ#0から順に判定されるため、リクエストが複数のウインドウに重複してヒットすることはない。すなわち、リクエストがヒットするウインドウの検索順に優先順位をつけることで、ウインドウの設定ミスによる誤動作を防止することができる。
【0042】
図7(b)に示す一例では、コマンド種が“メモリリード”、アドレス範囲が“0x0000”〜“0x0FFF”及び格納先キューが“キュー331”のウインドウ#0、コマンド種が“I/Oアクセス”、アドレス範囲が“0x1000”〜“0x1FFF”及び及び格納先キューが“キュー332”のウインドウ#1、
アドレス範囲が“0x2000”〜“0x2FFF”及び格納先キューが“キュー333”のウインドウ#2がリクエストウインドウ300として設定される。
【0043】
図7(b)のように、振り分け回路314は、デコードしたリクエストアドレス又は/及びコマンド種と一致するウインドウを検索し、ヒット(一致)したウインドウに基づいてリクエストの格納先を決定する。例えば、リクエストアドレスが“0X0100であり、コマンド種がメモリアクセスである場合、リクエストはウインドウ#0にヒットする。この場合、振り分け回路314は、ウインドウ#0の格納先キューに設定されているキュー331(優先度“0”)に当該リクエストをエンキュー(格納)する。ウインドウ#0やウインドウ#1にヒットするためには、アドレス及びコマンド種が一致しなければならない。一方、リクエストアドレスが“0X2010である場合、コマンド種に関係なくリクエストはウインドウ#2にヒットする。この場合、振り分け回路314は、ウインドウ#2の格納先キューに設定されているキュー333(シーケンシャルキュー)に当該リクエストをエンキュー(格納)する。
【0044】
更に、リクエストアドレスがリクエストウインドウ300に設定されていないアドレス(例えば“0X3000”)の場合、アドレスが一致してもコマンド種がリクエストウインドウ300に設定されたコマンドと異なる場合、あるいは、コマンド種が一致してもリクエストアドレスがリクエストウインドウ300に設定されたアドレスと異なる場合は、リクエストにヒットするウインドウは存在しないと判定される。この場合、振り分け回路314は、リクエストをキュー333(シーケンシャルキュー)にエンキュー(格納)する。例えば、リクエストのアドレスが0x0100でI/Oアクセスの場合、ヒットするウインドウは存在せず、当該リクエストはキュー333に格納される。
【0045】
図7(c)に示す一例では、アドレス範囲が“0x0000”〜“0x0FFF”及び格納先キューが“キュー331”のウインドウ#0、コマンド種が“メモリリード”及び格納先キューが“キュー332”のウインドウ#1、コマンド種が“I/Oアクセス”及び格納先キューが“キュー333”のウインドウ#2がリクエストウインドウ300として設定される。本一例では、ウインドウ#1、#2にアドレス範囲は設定されない。
【0046】
図7(c)のように、振り分け回路314は、デコードしたリクエストアドレス又はコマンド種と一致するウインドウを検索し、ヒット(一致)したウインドウに基づいてリクエストの格納先を決定する。例えば、リクエストアドレスが“0X0100である場合、リクエストはウインドウ#0にヒットする。この場合、振り分け回路314は、ウインドウ#0の格納先キューに設定されているキュー331(優先度“0”)に当該リクエストをエンキュー(格納)する。あるいは、リクエストアドレスが任意であり、コマンド種がメモリリードである場合、リクエストはウインドウ#1にヒットする。この場合、振り分け回路314は、ウインドウ#1の格納先キューに設定されているキュー332(優先度“1”)に当該リクエストをエンキュー(格納)する。更に、リクエストアドレスがリクエストウインドウ300に設定されていないアドレス(例えば“0X3000”)の場合、リクエストにヒットするウインドウは存在しない。この場合、振り分け回路314は、リクエストをキュー333(シーケンシャルキュー)にエンキュー(格納)する。リクエストがリクエストウインドウ300にヒットするか否かが、コマンド種(例えばメモリアクセス、I/Oアクセス)でしか判断できない場合、当該リクエストの転送先アドレスとして、システムバス4からのリクエストアドレスが割り当てられる。
【0047】
以上のように、ウインドウに設定するアドレスやコマンド種を、実行するプロセスに応じて設定することで、アクセス先のアドレスや実行するコマンドに応じた格納先キューを変更することができる。尚、ウインドウにヒットしないリクエストがある場合、エラーを返しても良いし、当該リクエストを破棄しても良い。
【0048】
本発明によるリクエスト振り分け部301は、リクエスト間のアドレスを比較することなく、入力されたリクエストアドレスやコマンド種に応じて格納先のキューを決定することができる。すなわち、本発明では、各キューにエンキューされた時点で、アドレス依存関係は解消されている。このため、後段のリクエストセレクタ302は、アドレス依存関係や、コマンドの発行順を気にすることなく処理対象のキューを選択することができる。
【0049】
リクエストセレクタ302は、送信用キュー群330から選択したキュー内のリクエストを外部デバイス5に発行する。リクエストセレクタ302は、優先度の高いキューを優先的に選択し、選択したキュー内のリクエストを外部デバイス5に発行することが好ましい。
【0050】
リクエストセレクタ302は、高優先キュー(キュー331、332)からリクエストを抽出して発行する場合、外部デバイス5に発行したリクエストの完了通知を受けることなく、高優先キューから次のリクエストを抽出して発行することが好ましい。詳細には、リクエストセレクタ302は、高優先キュー(キュー331、332)内のリクエストを発行する際、受信部303に高優先リクエストの発行を通知する。受信部303は、高優先リクエストの発行通知に応じてACK信号(コマンドアクノリッジ)を返却する。リクエストセレクタ302は、受信部303からのACK信号に応じて次のリクエストを高優先キューから抽出して発行する。これにより、高優先キューに格納された次のリクエストは、前に発行されたリクエストの完了を待たずに発行され得る。例えば、リクエストセレクタ302は、リードコマンドに対するリードレスポンス(リードデータ)が返却される前に、高優先キュー内の次のリクエストを発行することができる。
【0051】
一方、リクエストセレクタ302は、シーケンシャルキュー(キュー333)からリクエストを抽出して発行する場合、発行したリクエストの受信完了通知を受けてから次ぎのリクエストを発行する。詳細には、リクエストセレクタ302は、シーケンシャルキュー(キュー333)内のリクエストを通常通り発行する。受信部303は、外部デバイス5から当該リクエストの完了通知を受け取るとリクエストセレクタ302にACK信号(コマンドアクノリッジ)を出力する。リクエストセレクタ302は、受信部303からのACK信号に応じて次のリクエストをシーケンシャルキューから抽出して発行する。これにより、シーケンシャルキューに格納された次のリクエストは、前に発行されたリクエストの完了に応じて発行されることになる。例えば、リクエストセレクタ302は、リードコマンドに対するリードレスポンス(リードデータ)が受信部303に返却されるまで、シーケンシャルキュー内の次のリクエストを発行せずに待機する。
【0052】
図8は、本発明によるリクエストセレクタ302の構成の一例を示す図である。図8を参照して、リクエストセレクタ302は、FULL判定用フラグ321、優先処理判定回路322、セレクタ323を備える。
【0053】
優先処理判定回路322は、優先処理判定回路322は、各キューにエンキュー(格納)されたリクエスト数に応じて優先処理判定を行い、処理対象となるキューを決定する。この際、優先処理判定回路322は、優先度の高いキューから順に格納状況を確認し、高い優先度のキュー331にリクエストが格納されていない場合、次に優先度の高いキューを処理対象としてセレクタ323に指定する。尚、シーケンシャルキューは最も優先度が低いものとする。又、優先処理判定回路322は、高優先キューがリクエストによって満たされた(FULLとなる)場合、当該キュー内のリクエストを全て発行した後、次に優先度の高いキューを処理対象としてセレクタ323に指定する。
【0054】
FULL判定用フラグ321は、高優先キューがリクエストによってFULLとなったか否かを示すフラグである。FULL判定用フラグ321は、高優先キューに設定されたキュー331、332のそれぞれに対応して設けられる。例えば、リクエストによってFULLとなったキューのFULL判定用フラグ321に“1”がセットされる。優先処理判定回路322は、FULL判定用フラグ321によってFULLとなったキューを確認できる。
【0055】
セレクタ323は、優先処理判定回路322によって処理対象として指定されたキューからリクエストを抽出し、リクエストの内容に応じた外部デバイス5に当該リクエストを発行する。
【0056】
以上のような構成により、リクエストセレクタ302は、高優先キューがリクエストによって満たされる(FULLになる)まで当該高優先キューを処理する。本発明では、高優先のキューがFULLになったことをトリガとして、優先度の低いキューが処理される。これにより、優先度の低いキューに格納されたリクエストが発行されずに、システムがライブロックとなることを防止することができる。
【0057】
図9A及び図9Bを参照して、リクエストセレクタ302による優先処理制御方法の詳細を説明する。図9A及び図9Bは、本発明によるリクエスト制御動作の一例を示すフロー図である。
【0058】
リクエストセレクタ302は、先ず、用意された送信用キュー群330の中で最も優先度の高いキュー331(優先度“0”)にリクエストが積まれている(格納されている)か否かを確認する(ステップS101)。キュー331にリクエストが積まれている(格納されている)場合、リクエストセレクタ302は、キュー331のリクエストを外部デバイス5に発行する(ステップS101Yes、S102)。
【0059】
次に、リクエストセレクタ302は、FULL判定用フラグ321を参照して、キュー331がリクエストによってFULLになったかを確認する(ステップS103)。ここで、キュー331がFULLでない場合、ステップS101に移行する(ステップS103No)。一方、キュー331がFULLとなった場合、キュー331に対応するFULL判定用フラグ321にFULLを示す“1”がセットされ、リクエストセレクタ302は、その時点でキュー331内に格納されたリクエストを全て外部デバイス5に発行するまで処理を続ける(ステップS103Yes、S104、S105No)。
【0060】
優先処理キュー331にリクエストが積まれていない場合(ステップS101No)、あるいは、FULLとなったキュー331内の全てのリクエストを処理した場合(ステップS105Yes)、リクエストセレクタ302は、次に優先度の高いキュー332(優先度“1”)にリクエストが積まれている(格納されている)か否かを確認する(ステップS201)。
【0061】
キュー332にリクエストが積まれている場合、リクエストセレクタ302は、キュー332のリクエストを外部デバイス5に発行する(ステップS201Yes、S202)。
【0062】
次に、リクエストセレクタ302は、FULL判定用フラグ321を参照して、キュー332より優先度の高いキュー331のFULL判定用フラグ321にFULLを示す“1”がセットされているかを確認する(ステップS203)。ここで、キュー331のFULL判定用フラグ321にFULLを示す“1”がセットされていない場合、ステップS101に移行する(ステップS203No)。すなわち、優先度の高いキュー331にリクエストがないことをトリガとしてキュー332を処理する場合、リクエストセレクタ302は、キュー332の処理後、優先度の高いキュー331を優先的に処理するように制御される。
【0063】
ステップS203において、FULLを示す“1”がセットされている場合、リクエストセレクタ302は、FULL判定用フラグ321を参照して、キュー332がFULLになったかを確認する(ステップS203Yes、S204)。
【0064】
ステップS204において、キュー332がFULLでない場合、ステップS201に移行する(ステップS204No)。すなわち、優先度の高いキュー331がFULLとなったことをトリガとしてキュー332を処理する場合、リクエストセレクタ302は、キュー332の処理又はキュー332より低い優先度の処理を継続する。
【0065】
一方、キュー332がFULLとなった場合、キュー332に対応するFULL判定用フラグ321にFULLを示す“1”がセットされ、リクエストセレクタ302は、その時点でキュー332内に格納されたリクエストを全て外部デバイス5に発行するまで処理を続ける(ステップS204Yes、S205、S206No)。
【0066】
優先処理キュー332にリクエストが積まれていない場合(ステップS201No)、あるいは、FULLとなったキュー332内の全てのリクエストを処理した場合(ステップS206Yes)、リクエストセレクタ302は、次に優先度の高いキュー(ここではシーケンシャルキュー(キュー333))にリクエストが積まれているか否かを確認する(ステップS301)。
【0067】
キュー333にリクエストが積まれている場合、リクエストセレクタ302は、キュー333のリクエストを外部デバイス5に発行する(ステップS301Yes、S302)。一方、キュー333にリクエストが積まれていない場合、ステップS101に以降する(ステップS301No)。
【0068】
ステップS302においてキュー333に対する処理を行ったリクエストセレクタ302は、FULL判定用フラグ321を参照して、キュー333より優先度の高いキュー331、332のFULL判定用フラグ321にFULLを示す“1”がセットされているかを確認する(ステップS303、S304)。ここで、キュー331、332のFULL判定用フラグ321にFULLを示す“1”がセットされていない場合、ステップS101に移行する(ステップS303No、S304No)。すなわち、高優先キュー(キュー331、332)にリクエストがないことをトリガとしてシーケンシャルキュー(キュー333)を処理する場合、リクエストセレクタ302は、キュー333の処理後、最も優先度の高いキュー331を優先的に処理するように制御される。
【0069】
ステップS303、S304において、キュー331、332のFULL判定用フラグ321の両方にFULLを示す“1”がセットされている場合、リクエストセレクタ302は、キュー333内にリクエストが格納されていない(empty)ことを確認する(ステップS303Yes、S304Yes、S305)。
【0070】
ステップS305において、キュー332がemptyでない場合、ステップS302に移行する(ステップS305No)。すなわち、優先度の高いキュー331、332がFULLとなったことをトリガとしてキュー333を処理する場合、リクエストセレクタ302は、キュー333内の全てのリクエストを発行するまで、キュー333に対する処理を継続する。
【0071】
一方、キュー333がemptyとなった場合、リクエストセレクタ302は、全ての高優先キュー(キュー331、332)のFULL判定用フラグ321に設定された“1”を“0”にクリアする(ステップS305Yes、S306)。FULL判定用フラグ321をクリア後、ステップS101に移行し、リクエストセレクタ302は、再度、優先度の高いキューを優先して処理を行う。
【0072】
以上のように、本発明では、複数のキューのうち、どのキューからリクエストを選択するかを、優先処理判定回路322によって決定している。このため、各キュー間のリクエストは、アウトオブオーダーで発行される。ただし、キュー内のリクエストは、リクエストに積まれた順(エンキュー順)に処理されるためインオーダで発行される。
【0073】
優先処理判定回路322は、FULL判定用フラグ321を利用することで、高優先キューがFULLとなったことをトリガとして、低優先キューやシーケンシャルキューを処理対象として選択する。これにより、優先度の低いキューに格納されたリクエストが発行されずに、システムがライブロックとなることを防止することができる。
【0074】
受信部303は、外部デバイス5からのリクエスト(リクエストコマンド、リクエストアドレス)を受信し、受信用キュー群320に格納する。受信用キュー群320は、ライトリクエストを格納するライトキュー341と、リードリクエストを格納するリードキュー342を備える。受信部303は、外部デバイス5からのライトリクエストをライトキュー341に格納し、外部デバイス5からのリードリクエストをリードキュー342に格納する。ライトキュー341内のリクエストは、リードキュー342に優先してシステムバスリクエスト送信回路304に出力される。これは、一般的なPCIで規定された機能であるため、詳細な説明は省略する。
【0075】
システムバスリクエスト送信回路304は、ライトキュー341又はリードキュー342の一方から出力されたリクエストを、システムバス4を介してバスマスタであるCPU1、又はDMAコントローラ2に発行する。
【0076】
本発明によるリクエスト振り分け部301は、リクエスト間のアドレス依存関係をキューにエンキューする前に解決し、複数のキューに振り分けている。このため、キュー間のアドレス依存関係を比較する必要がなくなり、システムバス4からのリクエストを直ぐにエンキューすることができる。又、複数のキューにエンキューされたリクエストは、既にアドレス依存関係が解消されているため、処理対象となるキュー任意に選択しても、アクセス先が競合することなくリクエストを発行することができる。このため、実装上の問題を気にすることなくスケーラブルにキューの段数を増やすことが可能となる。
【0077】
更に、各キューに優先度が付与されており、リクエストセレクタ302はその優先度に従って処理対象となるキューを選択する。これにより、発行元のリクエストやコマンド種に優先順位を付与することが可能となり、優先処理させたいリクエストを外部バスブリッジ3に留めることなく、発行することが可能となる。例えば、リードリクエストを優先度の高いキューに格納し、ライトリクエストを優先度の低いキューに格納することで、先にマスタから発行されたライトリクエストよりも先に、リードリクエストを外部デバイス5に発行することできる。従って本発明によれば、従来構成で問題となっていたリードレイテンシを改善することができる。
【0078】
又、コマンド種として、特定処理(例えば、音声処理や画像処理)に阿智するリクエストを優先度の高いキューにエンキューすることで、特定処理に対する優先処理が可能となる。I/Oリクエスト等、発行オーダの保証が必要なリクエストは、シーケンシャルキュー(キュー333)に格納することで、従来と同様に発行オーダを保証することができる。
【0079】
本発明では、複数のキューにリクエストを格納する前にアドレス依存関係を解消しているため、従来技術のように論理規模を増大させることなく、複数のバスマスタからのリクエスト発行数を増加させることができる。
【0080】
又、複数のバスマスタから発行されたリクエストのアドレス依存関係及び優先処理を保証しつつ、リクエスト発行数を増加させることができる。
【0081】
更に、複数のバスマスタから発行されたリクエストのアドレス依存関係及びQoS制御を保証しつつ、リクエスト発行数を増加させることができる。
【0082】
以上、本発明の実施の形態を詳述してきたが、具体的な構成は上記実施の形態に限られるものではなく、本発明の要旨を逸脱しない範囲の変更があっても本発明に含まれる。上述の実施の形態では、送信用キューとして3つのキュー331、332、333を備える外部バスブリッジ3を一例に説明したが、その数や優先度やシーケンシャルキューの設定はこれに限らない。
【符号の説明】
【0083】
1 :CPU
2 :DMAコントローラ
3 :外部バスブリッジ
4 :システムバス
5 :外部デバイス
100:半導体集積回路
300:リクエストウインドウ
301:リクエスト振り分け部
302:リクエストセレクタ
303:受信部
304:システムバスリクエスト送信回路
310:ウインドウレジスタ
311:ベースレジスタ
312:サイズレジスタ
313:リクエストレジスタ
314:振り分け回路
320:受信用キュー群
321:FULL判定用フラグ
322:優先処理判定回路
323:セレクタ
330:送信用キュー群
331〜333:キュー
341:ライトキュー
342:リードキュー
【特許請求の範囲】
【請求項1】
複数のキューと、
複数のバスマスタから発行されたリクエストのアクセス先のアドレスに基づいて、前記リクエストを前記複数のキューのいずれかに振り分けるリクエスト振り分け部と、
前記複数のキューから選択したキュー内のリクエストを、外部デバイスに発行するリクエストセレクタと
を具備する
半導体集積回路。
【請求項2】
請求項1に記載の半導体集積回路において、
前記リクエスト振り分け部は、前記リクエストのコマンド種に基づいて、前記リクエストを前記複数のキューのいずれかに振り分ける
半導体集積回路。
【請求項3】
請求項1又は2に記載の半導体集積回路において、
前記振り分け部は、それぞれが、所定のアドレス範囲が設定されるともに、前記複数のキューのいずれかに対応付けられた複数のウインドウと、リクエストアドレスに一致するアドレスが設定されたウインドウを、前記複数のウインドウから検索する振り分け回路とを備え、
前記振り分け回路は、リクエストアドレスに一致するアドレスが設定されたウインドウに対応するキューに、前記リクエストを格納する
半導体集積回路。
【請求項4】
請求項3に記載の半導体集積回路において、
前記複数のウインドウのそれぞれは、所定のコマンド種が設定され、
前記振り分け回路は、リクエストコマンドに一致するコマンド種が設定されたウインドウを、前記複数のウインドウから検索する
前記振り分け回路は、リクエストコマンドに一致するコマンド種が設定されたウインドウに対応するキューに、前記リクエストを格納する
半導体集積回路。
【請求項5】
請求項3又は4に記載の半導体集積回路において、
前記振り分け回路は、複数のウインドウを所定の順で検索し、前記リクエストに最初にヒットしたウインドウに基づいて、リクエストの格納先のキューを決定する
半導体集積回路。
【請求項6】
請求項1から5のいずれか1項に記載の半導体集積回路において、
前記複数のキューのそれぞれには、異なる優先度が付与され、
前記リクエストセレクタは、前記優先度の高いキュー内のリクエストを優先して選択して外部デバイスに発行する
半導体集積回路。
【請求項7】
請求項6に記載の半導体集積回路において、
前記リクエスト振り分け部は、トランザクションの完了を待たずに出力可能なリクエストを第1キューに格納し、トランザクションの完了を待ってから出力するリクエストを前記第1キューより優先度の低い第2キューに格納する
半導体集積回路。
【請求項8】
請求項7に記載の半導体集積回路において、
前記リクエスト振り分け部は、メモリへのアクセスリクエストを前記第1キューに格納する
半導体集積回路。
【請求項9】
請求項7又は8に記載の半導体集積回路において、
前記リクエスト振り分け部は、外部インタフェースへのアクセスリクエストを前記第2キューに格納する
半導体集積回路。
【請求項10】
請求項7から9のいずれか1項に記載の半導体集積回路において、
前記第1キューから選択されて発行されたリクエストに応じて第1応答信号を出力する受信部を更に具備し、
前記リクエストセレクタは、前記第1応答信号に応じて前記第1キューから次のリクエストを抽出して、外部デバイスに発行する
半導体集積回路。
【請求項11】
請求項10に記載の半導体集積回路において、
前記受信部は、前記第2キューから選択されて発行されたリクエストの完了通知を外部デバイスから受信し、前記完了通知に応じて第2応答信号を出力し、
前記リクエストセレクタは、前記第2応答信号に応じて前記第2キューから次のリクエストを抽出して、外部デバイスに発行する
半導体集積回路。
【請求項12】
請求項6から11のいずれか1項に記載の半導体集積回路において、
前記リクエストセレクタは、前記優先度の高いキュー内にリクエストが格納されている場合、前記優先度の高いキュー内のリクエストがなくなるまで、前記優先度の高いキュー内のリクエストを選択して外部デバイスに発行する
半導体集積回路。
【請求項13】
請求項12に記載の半導体集積回路において、
前記リクエストセレクタは、前記優先度の高いキューの全てにリクエストが格納されている場合、前記格納されたリクエストの全てを発行した後、前記優先度の高いキューより低い優先度のキュー内のリクエストを選択して外部デバイスに発行する
半導体集積回路。
【請求項14】
複数のキューを用意するステップと、
複数のバスマスタから発行されたリクエストのアクセス先のアドレスに基づいて、前記リクエストを複数のキューのいずれかに振り分けるステップと、
前記複数のキューから選択したキュー内のリクエストを外部デバイスに発行するステップと
を具備する
リクエスト制御方法。
【請求項15】
請求項14に記載のリクエスト制御方法において、
前記振り分けるステップは、前記リクエストのコマンド種に基づいて、前記リクエストを前記複数のキューのいずれかに振り分けるステップを備える
リクエスト制御方法。
【請求項16】
請求項14又は15に記載のリクエスト制御方法において、
前記複数のキューのそれぞれには、異なる優先度が付与され、
前記リクエストを外部デバイスに発行するステップは、前記優先度の高いキュー内のリクエストを優先して選択して外部デバイスに発行するステップを備える
リクエスト制御方法。
【請求項17】
請求項16に記載のリクエスト制御方法において、
前記振り分けるステップは、トランザクションの完了を待たずに出力可能なリクエストを第1キューに格納するステップと、トランザクションの完了を待ってから出力するリクエストを前記第1キューより優先度の低い第2キューに格納するステップとを備える
リクエスト制御方法。
【請求項18】
請求項17に記載のリクエスト制御方法において、
受信部が、前記第1キューから選択されて発行されたリクエストに応じて第1応答信号を出力するステップと、
前記第1応答信号に応じて前記第1キューから次のリクエストを抽出して、外部デバイスに発行するステップと
を更に具備する
リクエスト制御方法。
【請求項19】
請求項18に記載のリクエスト制御方法において、
前記受信部が、前記第2キューから選択されて発行されたリクエストの完了通知を外部デバイスから受信するステップと、
前記受信部が、前記完了通知に応じて第2応答信号を出力するステップと、
前記第2応答信号に応じて前記第2キューから次のリクエストを抽出して、外部デバイスに発行するステップと
を更に具備する
リクエスト制御方法。
【請求項20】
請求項16から19のいずれか1項に記載のリクエスト制御方法において、
前記優先度の高いキュー内にリクエストが格納されている場合、前記優先度の高いキュー内のリクエストがなくなるまで、前記優先度の高いキュー内のリクエストを選択して外部デバイスに発行するステップを更に具備する
リクエスト制御方法。
【請求項21】
請求項20に記載のリクエスト制御方法において、
前記優先度の高いキューの全てにリクエストが格納されている場合、前記格納されたリクエストの全てを発行した後、前記優先度の高いキューより低い優先度のキュー内のリクエストを選択して外部デバイスに発行するステップを更に具備する
リクエスト制御方法。
【請求項1】
複数のキューと、
複数のバスマスタから発行されたリクエストのアクセス先のアドレスに基づいて、前記リクエストを前記複数のキューのいずれかに振り分けるリクエスト振り分け部と、
前記複数のキューから選択したキュー内のリクエストを、外部デバイスに発行するリクエストセレクタと
を具備する
半導体集積回路。
【請求項2】
請求項1に記載の半導体集積回路において、
前記リクエスト振り分け部は、前記リクエストのコマンド種に基づいて、前記リクエストを前記複数のキューのいずれかに振り分ける
半導体集積回路。
【請求項3】
請求項1又は2に記載の半導体集積回路において、
前記振り分け部は、それぞれが、所定のアドレス範囲が設定されるともに、前記複数のキューのいずれかに対応付けられた複数のウインドウと、リクエストアドレスに一致するアドレスが設定されたウインドウを、前記複数のウインドウから検索する振り分け回路とを備え、
前記振り分け回路は、リクエストアドレスに一致するアドレスが設定されたウインドウに対応するキューに、前記リクエストを格納する
半導体集積回路。
【請求項4】
請求項3に記載の半導体集積回路において、
前記複数のウインドウのそれぞれは、所定のコマンド種が設定され、
前記振り分け回路は、リクエストコマンドに一致するコマンド種が設定されたウインドウを、前記複数のウインドウから検索する
前記振り分け回路は、リクエストコマンドに一致するコマンド種が設定されたウインドウに対応するキューに、前記リクエストを格納する
半導体集積回路。
【請求項5】
請求項3又は4に記載の半導体集積回路において、
前記振り分け回路は、複数のウインドウを所定の順で検索し、前記リクエストに最初にヒットしたウインドウに基づいて、リクエストの格納先のキューを決定する
半導体集積回路。
【請求項6】
請求項1から5のいずれか1項に記載の半導体集積回路において、
前記複数のキューのそれぞれには、異なる優先度が付与され、
前記リクエストセレクタは、前記優先度の高いキュー内のリクエストを優先して選択して外部デバイスに発行する
半導体集積回路。
【請求項7】
請求項6に記載の半導体集積回路において、
前記リクエスト振り分け部は、トランザクションの完了を待たずに出力可能なリクエストを第1キューに格納し、トランザクションの完了を待ってから出力するリクエストを前記第1キューより優先度の低い第2キューに格納する
半導体集積回路。
【請求項8】
請求項7に記載の半導体集積回路において、
前記リクエスト振り分け部は、メモリへのアクセスリクエストを前記第1キューに格納する
半導体集積回路。
【請求項9】
請求項7又は8に記載の半導体集積回路において、
前記リクエスト振り分け部は、外部インタフェースへのアクセスリクエストを前記第2キューに格納する
半導体集積回路。
【請求項10】
請求項7から9のいずれか1項に記載の半導体集積回路において、
前記第1キューから選択されて発行されたリクエストに応じて第1応答信号を出力する受信部を更に具備し、
前記リクエストセレクタは、前記第1応答信号に応じて前記第1キューから次のリクエストを抽出して、外部デバイスに発行する
半導体集積回路。
【請求項11】
請求項10に記載の半導体集積回路において、
前記受信部は、前記第2キューから選択されて発行されたリクエストの完了通知を外部デバイスから受信し、前記完了通知に応じて第2応答信号を出力し、
前記リクエストセレクタは、前記第2応答信号に応じて前記第2キューから次のリクエストを抽出して、外部デバイスに発行する
半導体集積回路。
【請求項12】
請求項6から11のいずれか1項に記載の半導体集積回路において、
前記リクエストセレクタは、前記優先度の高いキュー内にリクエストが格納されている場合、前記優先度の高いキュー内のリクエストがなくなるまで、前記優先度の高いキュー内のリクエストを選択して外部デバイスに発行する
半導体集積回路。
【請求項13】
請求項12に記載の半導体集積回路において、
前記リクエストセレクタは、前記優先度の高いキューの全てにリクエストが格納されている場合、前記格納されたリクエストの全てを発行した後、前記優先度の高いキューより低い優先度のキュー内のリクエストを選択して外部デバイスに発行する
半導体集積回路。
【請求項14】
複数のキューを用意するステップと、
複数のバスマスタから発行されたリクエストのアクセス先のアドレスに基づいて、前記リクエストを複数のキューのいずれかに振り分けるステップと、
前記複数のキューから選択したキュー内のリクエストを外部デバイスに発行するステップと
を具備する
リクエスト制御方法。
【請求項15】
請求項14に記載のリクエスト制御方法において、
前記振り分けるステップは、前記リクエストのコマンド種に基づいて、前記リクエストを前記複数のキューのいずれかに振り分けるステップを備える
リクエスト制御方法。
【請求項16】
請求項14又は15に記載のリクエスト制御方法において、
前記複数のキューのそれぞれには、異なる優先度が付与され、
前記リクエストを外部デバイスに発行するステップは、前記優先度の高いキュー内のリクエストを優先して選択して外部デバイスに発行するステップを備える
リクエスト制御方法。
【請求項17】
請求項16に記載のリクエスト制御方法において、
前記振り分けるステップは、トランザクションの完了を待たずに出力可能なリクエストを第1キューに格納するステップと、トランザクションの完了を待ってから出力するリクエストを前記第1キューより優先度の低い第2キューに格納するステップとを備える
リクエスト制御方法。
【請求項18】
請求項17に記載のリクエスト制御方法において、
受信部が、前記第1キューから選択されて発行されたリクエストに応じて第1応答信号を出力するステップと、
前記第1応答信号に応じて前記第1キューから次のリクエストを抽出して、外部デバイスに発行するステップと
を更に具備する
リクエスト制御方法。
【請求項19】
請求項18に記載のリクエスト制御方法において、
前記受信部が、前記第2キューから選択されて発行されたリクエストの完了通知を外部デバイスから受信するステップと、
前記受信部が、前記完了通知に応じて第2応答信号を出力するステップと、
前記第2応答信号に応じて前記第2キューから次のリクエストを抽出して、外部デバイスに発行するステップと
を更に具備する
リクエスト制御方法。
【請求項20】
請求項16から19のいずれか1項に記載のリクエスト制御方法において、
前記優先度の高いキュー内にリクエストが格納されている場合、前記優先度の高いキュー内のリクエストがなくなるまで、前記優先度の高いキュー内のリクエストを選択して外部デバイスに発行するステップを更に具備する
リクエスト制御方法。
【請求項21】
請求項20に記載のリクエスト制御方法において、
前記優先度の高いキューの全てにリクエストが格納されている場合、前記格納されたリクエストの全てを発行した後、前記優先度の高いキューより低い優先度のキュー内のリクエストを選択して外部デバイスに発行するステップを更に具備する
リクエスト制御方法。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9A】
【図9B】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9A】
【図9B】
【公開番号】特開2011−232917(P2011−232917A)
【公開日】平成23年11月17日(2011.11.17)
【国際特許分類】
【出願番号】特願2010−101863(P2010−101863)
【出願日】平成22年4月27日(2010.4.27)
【出願人】(302062931)ルネサスエレクトロニクス株式会社 (8,021)
【Fターム(参考)】
【公開日】平成23年11月17日(2011.11.17)
【国際特許分類】
【出願日】平成22年4月27日(2010.4.27)
【出願人】(302062931)ルネサスエレクトロニクス株式会社 (8,021)
【Fターム(参考)】
[ Back to top ]