JP2011232917A

JP2011232917A - 半導体集積回路、及びリクエスト制御方法

Info

Publication number: JP2011232917A
Application number: JP2010101863A
Authority: JP
Inventors: Daisuke Kawakami; 大輔川上
Original assignee: Renesas Electronics Corp
Current assignee: Renesas Electronics Corp
Priority date: 2010-04-27
Filing date: 2010-04-27
Publication date: 2011-11-17

Abstract

【課題】論理規模を増大させることなく、複数のバスマスタからのリクエスト発行数を増加させる。
【解決手段】本発明による半導体集積回路１００は、複数のキュー３３０と、複数のバスマスタ１、２から発行されたリクエストのアクセス先のアドレスに基づいて、リクエストを複数のキュー３３０のいずれかに振り分けるリクエスト振り分け部３０１と、複数のキュー３３０から選択したキュー内のリクエストを、外部デバイス５に発行するリクエストセレクタ３０２とを具備する。
【選択図】図５

Description

本発明は、半導体集積回路、及びリクエスト制御方法に関し、特に複数のバスマスタと外部デバイスとの間のリクエスト制御方法に関する。

図１は、従来技術における半導体集積回路（ＬＳＩ：ＬａｒｇｅＳｃａｌｅＩｎｔｅｇｒａｔｉｏｎ）の構成の一例を示す図である。図１を参照して、ＬＳＩは、システムバス４０を介して相互に接続されたＣＰＵ１０、ＤＭＡコントローラ２０、複数のスレーブ６０−１、６０−２、アドレス依存比較器７０を具備する。ＣＰＵ１０やＤＭＡ（ＤｉｒｅｃｔＭｅｍｏｒｙＡｃｃｅｓｓ）コントローラ２０は、システムバス４０のバスマスタとして機能し、外部バスブリッジ回路に例示されるスレーブ６０−１、６０−２を介して、外部デバイス（例示：メモリ、入出力インタフェース（Ｉ／Ｏ）、図示なし）に対してリクエストを発行する。アドレス依存比較器７０は、外部デバイスに発行されるリクエストと、それに先行するリクエストとのアドレス依存関係を確認する。アドレス依存比較器７０は、バスマスタからのリクエストと同一アドレスにアクセスする先行リクエストが完了しない場合、当該バスマスタからのリクエストの発行を待機させる。

以上のようなアドレス依存比較器７０を利用したリクエスト制御を行う技術が、例えば特開２００８−９７６３に記載されている（特許文献１参照）。

図２は、従来技術による半導体集積回路の構成の他の一例を示す図である。図２に示す半導体集積回路は、図１に示すスレーブ６０として、外部デバイス５０（例示：メモリ、Ｉ／Ｏ）に接続する外部バスブリッジ３０を具備する。外部バスブリッジ３０は、システムバスリクエスト受信回路３１、システムバスリクエスト送信回路３２、コマンドキュー３３、及びレスポンスキュー３２を備える。

システムバス４０のバスマスタとなるＣＰＵ１０、ＤＭＡコントローラ２０から発行されたリクエストは、コマンドキュー３３に一旦格納される。この際、コマンドキュー３３への格納制御は、システムバスリクエスト受信回路３１によって制御される。コマンドキュー３３にはシステムバス４０からのリクエストがインオーダに格納される。コマンドキュー３３に格納された（積まれた）リクエストは、格納順に外部デバイス５０に対して発行されて処理される。一方、外部デバイス５０からのリクエスト完了通知は、レスポンスキュー３４に格納され、システムバスリクエスト送信部３２による制御によってＣＰＵ１０やＤＭＡ２０に発行される。

外部デバイス５０に対するリクエストのオーダは、スレーブ（外部バスブリッジ３０）へのリクエストの到着順で守られる。例えば、本一例では、先行リクエスト（例えばライトリクエスト）の外部デバイス５０への発行を待ってから、後続のリクエスト（例えばリードリクエスト）が発行されることになる。この場合、リードリクエストに対するレスポンス応答が悪くなることがある。特に、ＱｏＳが必要な処理を行わせる場合に問題が顕著化する。

このような問題を解決するため、図３に示す半導体集積回路のように、コマンドキューとしてリードキュー３５とライトキュー３６を備える構成が知られている。

特開２００８−９７６３

図３に示す半導体集積回路では、リードとライトのリクエストを別々に発行できるため、図２に示す一例に比べて処理性能は向上する。しかし、メモリの排他制御を行うような場合においては、リードとライトのリクエスト発行オーダを保証する必要がある。例えば、ＣＰＵ１０が、アドレス“０Ｘ４０００”にライトリクエストを発行し、その後に当該アドレスに対してリードリクエストを発行する場合、ライトがリードよりも先に完了する必要がある。この場合、リードキュー３５とライトキュー３６に格納されたリクエストのどちらを先に外部デバイス５０に発行するかを判定するための機構（データ依存関係の判定機構）を、リードキュー３５とライトキュー３６との間に設ける必要がある。

このため、図３に示す半導体集積回路では、性能向上のためにキューの段数を増加させる場合、増加した段数に応じたエントリのデータ依存性関係を比較する必要がある。この場合、半導体集積回路の論理規模が大きくなり、動作周波数を上げることができない等の実装上の問題が顕著化する。

上記の課題を解決するために、本発明は、以下に述べられる手段を採用する。その手段を構成する技術的事項の記述には、［特許請求の範囲］の記載と［発明を実施するための形態］の記載との対応関係を明らかにするために、［発明を実施するための形態］で使用される番号・符号が付加されている。ただし、付加された番号・符号は、［特許請求の範囲］に記載されている発明の技術的範囲を限定的に解釈するために用いてはならない。

本発明による半導体集積回路（１００）は、複数のキュー（３３０）と、複数のバスマスタ（１、２）から発行されたリクエストのアクセス先のアドレスに基づいて、リクエストを複数のキュー（３３０）のいずれかに振り分けるリクエスト振り分け部（３０１）と、複数のキュー（３３０）から選択したキュー内のリクエストを、外部デバイス（５）に発行するリクエストセレクタ（３０２）とを具備する。

本発明によるリクエスト制御方法は、複数のキュー（３３０）を用意するステップと、複数のバスマスタ（１、２）から発行されたリクエストのアクセス先のアドレスに基づいて、リクエストを複数のキュー（３３０）のいずれかに振り分けるステップと、複数のキュー（３３０）から選択したキュー内のリクエストを外部デバイス（５）に発行するステップとを具備する。

本発明では、リクエストアドレスに基づいてバスマスタからのリクエストを複数のキューのいずれかに振り分けているため、キューに格納された時点で、キュー間（リクエスト間）のアドレス依存関係は解消される。すなわち、本発明では、キュー間のアドレス依存関係を比較する論理を必要としない。

従って、本発明によれば、論理規模の増大を抑制しつつ、複数のバスマスタからのリクエスト発行数を増加させることができる。

又、複数のバスマスタから発行されたリクエストのアドレス依存関係及び優先処理を保証しつつ、リクエスト発行数を増加させることができる。

更に、複数のバスマスタから発行されたリクエストのアドレス依存関係及びＱｏＳ制御を保証しつつ、リクエスト発行数を増加させることができる。

図１は、従来技術による半導体集積回路の構成の一例を示す図である。図２は、従来技術による半導体集積回路の構成の他の一例を示す図である。図３は、従来技術による半導体集積回路の構成の更に他の一例を示す図である。図４は、本発明による半導体集積回路の実施の形態における構成を示す図である。図５は、本発明による外部バスブリッジの実施の形態における構成を示す図である。図６は、本発明によるリクエスト振り分け部の構成とウインドウの構造の一例を示す図である。図７は、本発明によるウインドウの構造の一例を示す図である。図８は、本発明によるリクエストセレクタの構成の一例を示す図である。図９Ａは、本発明によるリクエスト制御動作の一例を示すフロー図である。図９Ｂは、本発明によるリクエスト制御動作の一例を示すフロー図である。

以下、添付図面を参照しながら本発明の実施の形態を説明する。図面において同一、又は類似の参照符号は、同一、類似、又は等価な構成要素を示す。

図４から図９Ａ、Ｂを参照して、本発明による半導体集積回路の実施の形態を説明する。図４は、本発明による半導体集積回路の構成の一例を示す図である。図４を参照して、本発明による半導体集積回路は、ＬＳＩに例示され、システムバス４を介して相互に接続されたＣＰＵ１、ＤＭＡコントローラ２、及び外部バスブリッジ３を具備する。

ＣＰＵ１、ＤＭＡコントローラ２は、システムバス４のバスマスタとして機能し、外部バスブリッジ３を介して外部デバイス５（複数の外部デバイス５−１〜５−３）に対してリクエストを発行する。外部デバイス５は外部バスを介して外部バスブリッジ３に接続され、ＵＳＢ（ＵｎｉｖｅｒｓａｌＳｅｒｉａｌＢｕｓ）やＰＣＩＥｘｐｒｅｓｓに例示されるＩ／Ｏインタフェースや、ＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）に例示されるメモリである。

外部バスブリッジ３は、システムバス４と外部デバイス５（外部バス）との間の接続を制御し、システムバス４のスレーブとして機能する。外部バスブリッジ３は、バスマスタ（ＣＰＵ１、ＤＭＡコントローラ２）が外部デバイス５に対して発行するリクエスト（リクエストコマンド、リクエストアドレス（アクセス先のアドレス））やデータを、外部デバイス５に転送する。又、外部バスブリッジ３は、外部デバイス５から発行されるリクエスト（リクエストコマンド、リクエストアドレス）やデータをバスマスタ（ＣＰＵ１、ＤＭＡコントローラ２）に転送する。

本発明による外部バスブリッジ３は、リクエスト優先処理機構を有する。図５を参照して、本発明による外部バスブリッジ３の構成の詳細を説明する。

外部バスブリッジ３は、システムバスリクエスト受信回路として機能するリクエスト振り分け部３０１、送信用キュー群３３０、リクエストセレクタ３０２、受信部３０３、受信用キュー群３２０、及びシステムバスリクエスト送信回路３０４を具備する。

リクエスト振り分け部３０１は、システムバス４を介してバスマスタ（例示：ＣＰＵ１、以下、バスマスタとしてＣＰＵ１を例に説明する）から発行されるリクエストをデコードし、そのデコード結果（転送アドレスやコマンドタイプ）に従って当該リクエストを、後段の送信用キュー群３３０に振り分けて格納（エンキュー）する。

送信用キュー群３３０は、複数のキュー３３１、３３２、３３３を備える。複数のキュー３３１、３３２、３３３にはそれぞれ異なる優先度が付与されていることが好ましい。この場合、リクエストセレクタ３０２は、優先度の高いキューを優先して選択し、選択したキューからリクエストを抽出して外部デバイス５に発行する。

送信用キュー群３３０のうち、いくつかのキューは、リクエストの完了通知を待たずに次のリクエストを発行可能なリクエストを格納する第１キュー（以下、高優先キューと称す）に設定されることが好ましい。例えば、メモリへのアクセスのためのリクエストは、リクエストの完了（例えばリードリクエストに対するリードデータ）を待たずに発行できる。このため、メモリアクセスのためのリクエストを、高優先キューに格納するようにリクエスト振り分け部３０１に設定することが好ましい。又、送信用キュー群３３０のうちの他のキューは、次のリクエストを発行するために前のリクエストの完了通知を受ける必要があるリクエストを格納する第２キュー（以下、シーケンシャルキューと称す）に設定されることが好ましい。例えば、Ｉ／Ｏインタフェースへのリクエストは、リクエストの完了を待ってから次のリクエストを発行する必要がある。このため、Ｉ／Ｏインタフェースに発行するリクエストを、シーケンシャルキューに格納するようにリクエスト振り分け部３０１に設定することが好ましい。

ここで、高優先キューは、シーケンシャルキューよりも優先的に外部デバイス５に発行される。又、複数のキューが高優先キューに設定された場合、それぞれに異なる優先度が付与されることが好ましい。本実施の形態では、キュー３３１、３３２が高優先キューとして設定され、キュー３３１に優先度“０”が付与され、キュー３３２に優先度“１”が付与されるものとする。尚、優先度“０”は優先度“１”よりも高い優先度であるものとする。又、本実施の形態では、キュー３３３がシーケンシャルキューに設定されるものとする。

図６は、本発明によるリクエスト振り分け部３０１の構成とウインドウの構造の一例を示す図である。図６を参照して、リクエスト振り分け部３０１の構成の詳細を説明する。

図６（ｂ）を参照して、リクエスト振り分け部３０１は、ウインドウレジスタ３１０と振り分け回路３１４を備える。

振り分け回路３１４は、システムバス４から入力されたリクエストをデコードし、デコード結果がリクエストウインドウ３００にヒットする場合、ヒットしたウインドウに設定された格納先キューに当該リクエストをエンキュー（格納）する。リクエストウインドウ３００は、リクエストアドレスに対応するアドレスが割り当てられた複数のウインドウを有し、それぞれにコマンド種、格納先のキューを指定する情報が設定される。

デコードされたリクエストにはリクエストアドレス（アクセス先のアドレス）やリクエストコマンドが含まれており、リクエストアドレスに一致するアドレスが設定されたウインドウが存在（ヒット）した場合や、リクエストコマンドと同じコマンド種が設定されたウインドウが存在（ヒット）する場合、ヒットしたウインドウに設定された格納先キューに当該リクエストが格納される。

ウインドウレジスタ３１０は、ベースレジスタ３１１、サイズレジスタ３１２、リクエストレジスタ３１３を備え、それぞれのレジスタに設定された値によって図６（ａ）に示すリクエストウインドウ３００を設定する。ベースレジスタ３１１、サイズレジスタ３１２、リクエストレジスタ３１３のそれぞれは、リクエストウインドウ３００に設定する複数のウインドウに対応する数だけ用意される。例えば、複数のウインドウ＃０、＃１、＃２を有するリクエストウインドウ３００を設定する場合、それぞれ３つのベースレジスタ３１１、サイズレジスタ３１２、リクエストレジスタ３１３が用意される。

ウインドウ＃０、＃１、＃２のアドレス範囲は、ベースレジスタ３１１及びサイズレジスタ３１２によって設定される。

ベースレジスタ３１１には、ウインドウの先頭アドレスを指定する値が設定される。すなわち、ベースレジスタ３１１によって、ウインドウ＃０、＃１、＃２のそれぞれの先頭アドレスが設定される。例えば、ウインドウ＃０の先頭アドレスは“０Ｘ００００”、ウインドウ＃１の先頭アドレスは“０Ｘ１０００”、ウインドウ＃２の先頭アドレスは“０Ｘ２０００”に設定される。

サイズレジスタ３１２には、ウインドウのサイズを指定する値が設定される。すなわち、サイズレジスタ３１２によって、ウインドウ＃０、＃１、＃２のそれぞれのサイズが設定される。例えば、ウインドウ＃０、＃１、＃２のそれぞれのサイズが“０Ｘ１０００”に設定される。

リクエストレジスタ３１３には、システムバス４からのリクエストがウインドウにヒットした場合、どのキューにエンキューするかを決める情報（格納先キュー）や、ウインドウに設定するリクエストタイプ（コマンド種）が設定される。すなわち、リクエストレジスタ３１３によって、ウインドウ＃０、＃１、＃２のそれぞれにヒットしたリクエストの格納先となるキューが設定されるとともに、ウインドウのリクエストタイプ（コマンド種）が設定される。

図７は、本発明によるウインドウ＃０、＃１、＃２の構造の一例を示す図である。図７を参照して、リクエストウインドウ３００に基づいたリクエストの振り分け処理の詳細を説明する。

図７（ａ）に示す一例では、アドレス範囲が“０ｘ００００”〜“０ｘ０ＦＦＦ”及び格納先キューが“キュー３３１”のウインドウ＃０、アドレス範囲が“０ｘ１０００”〜“０ｘ１ＦＦＦ”及び格納先キューが“キュー３３１”のウインドウ＃１、アドレス範囲が“０ｘ２０００”〜“０ｘ２ＦＦＦ”及び格納先キューが“キュー３３２”のウインドウ＃２がリクエストウインドウ３００として設定される。本一例では、ウインドウ＃０、＃１、＃２のいずれにもコマンド種は設定されていない。

図７（ａ）のように、リクエストウインドウ３００にコマンド種が設定されていない場合、振り分け回路３１４は、デコードしたリクエストアドレスが一致するウインドウを検索し、ヒット（一致）したウインドウに基づいてリクエストの格納先を決定する。例えば、リクエストアドレスが“０Ｘ１００５である場合、リクエストはウインドウ＃１にヒットする。この場合、振り分け回路３１４は、ウインドウ＃１の格納先キューに設定されているキュー３３１（優先度“０”）に当該リクエストをエンキュー（格納）する。あるいは、リクエストアドレスが“０Ｘ２０１０である場合、リクエストはウインドウ＃２にヒットする。この場合、振り分け回路３１４は、ウインドウ＃２の格納先キューに設定されているキュー３３２（優先度“１”）に当該リクエストをエンキュー（格納）する。更に、リクエストアドレスがリクエストウインドウ３００に設定されていないアドレスである場合（例えば“０Ｘ３０００”）、リクエストにヒットするウインドウは存在しない。この場合、振り分け回路３１４は、リクエストをキュー３３３（シーケンシャルキュー）にエンキュー（格納）する。

ウインドウにヒットするか否かの判定は、ウインドウ番号の若い順から行われる。例えば、誤って、複数のウインドウ＃０、＃１に同じアドレスが設定されていても、アドレスが小さいウインドウ＃０から順に判定されるため、リクエストが複数のウインドウに重複してヒットすることはない。すなわち、リクエストがヒットするウインドウの検索順に優先順位をつけることで、ウインドウの設定ミスによる誤動作を防止することができる。

図７（ｂ）に示す一例では、コマンド種が“メモリリード”、アドレス範囲が“０ｘ００００”〜“０ｘ０ＦＦＦ”及び格納先キューが“キュー３３１”のウインドウ＃０、コマンド種が“Ｉ／Ｏアクセス”、アドレス範囲が“０ｘ１０００”〜“０ｘ１ＦＦＦ”及び及び格納先キューが“キュー３３２”のウインドウ＃１、
アドレス範囲が“０ｘ２０００”〜“０ｘ２ＦＦＦ”及び格納先キューが“キュー３３３”のウインドウ＃２がリクエストウインドウ３００として設定される。

図７（ｂ）のように、振り分け回路３１４は、デコードしたリクエストアドレス又は／及びコマンド種と一致するウインドウを検索し、ヒット（一致）したウインドウに基づいてリクエストの格納先を決定する。例えば、リクエストアドレスが“０Ｘ０１００であり、コマンド種がメモリアクセスである場合、リクエストはウインドウ＃０にヒットする。この場合、振り分け回路３１４は、ウインドウ＃０の格納先キューに設定されているキュー３３１（優先度“０”）に当該リクエストをエンキュー（格納）する。ウインドウ＃０やウインドウ＃１にヒットするためには、アドレス及びコマンド種が一致しなければならない。一方、リクエストアドレスが“０Ｘ２０１０である場合、コマンド種に関係なくリクエストはウインドウ＃２にヒットする。この場合、振り分け回路３１４は、ウインドウ＃２の格納先キューに設定されているキュー３３３（シーケンシャルキュー）に当該リクエストをエンキュー（格納）する。

更に、リクエストアドレスがリクエストウインドウ３００に設定されていないアドレス（例えば“０Ｘ３０００”）の場合、アドレスが一致してもコマンド種がリクエストウインドウ３００に設定されたコマンドと異なる場合、あるいは、コマンド種が一致してもリクエストアドレスがリクエストウインドウ３００に設定されたアドレスと異なる場合は、リクエストにヒットするウインドウは存在しないと判定される。この場合、振り分け回路３１４は、リクエストをキュー３３３（シーケンシャルキュー）にエンキュー（格納）する。例えば、リクエストのアドレスが０ｘ０１００でＩ／Ｏアクセスの場合、ヒットするウインドウは存在せず、当該リクエストはキュー３３３に格納される。

図７（ｃ）に示す一例では、アドレス範囲が“０ｘ００００”〜“０ｘ０ＦＦＦ”及び格納先キューが“キュー３３１”のウインドウ＃０、コマンド種が“メモリリード”及び格納先キューが“キュー３３２”のウインドウ＃１、コマンド種が“Ｉ／Ｏアクセス”及び格納先キューが“キュー３３３”のウインドウ＃２がリクエストウインドウ３００として設定される。本一例では、ウインドウ＃１、＃２にアドレス範囲は設定されない。

図７（ｃ）のように、振り分け回路３１４は、デコードしたリクエストアドレス又はコマンド種と一致するウインドウを検索し、ヒット（一致）したウインドウに基づいてリクエストの格納先を決定する。例えば、リクエストアドレスが“０Ｘ０１００である場合、リクエストはウインドウ＃０にヒットする。この場合、振り分け回路３１４は、ウインドウ＃０の格納先キューに設定されているキュー３３１（優先度“０”）に当該リクエストをエンキュー（格納）する。あるいは、リクエストアドレスが任意であり、コマンド種がメモリリードである場合、リクエストはウインドウ＃１にヒットする。この場合、振り分け回路３１４は、ウインドウ＃１の格納先キューに設定されているキュー３３２（優先度“１”）に当該リクエストをエンキュー（格納）する。更に、リクエストアドレスがリクエストウインドウ３００に設定されていないアドレス（例えば“０Ｘ３０００”）の場合、リクエストにヒットするウインドウは存在しない。この場合、振り分け回路３１４は、リクエストをキュー３３３（シーケンシャルキュー）にエンキュー（格納）する。リクエストがリクエストウインドウ３００にヒットするか否かが、コマンド種（例えばメモリアクセス、Ｉ／Ｏアクセス）でしか判断できない場合、当該リクエストの転送先アドレスとして、システムバス４からのリクエストアドレスが割り当てられる。

以上のように、ウインドウに設定するアドレスやコマンド種を、実行するプロセスに応じて設定することで、アクセス先のアドレスや実行するコマンドに応じた格納先キューを変更することができる。尚、ウインドウにヒットしないリクエストがある場合、エラーを返しても良いし、当該リクエストを破棄しても良い。

本発明によるリクエスト振り分け部３０１は、リクエスト間のアドレスを比較することなく、入力されたリクエストアドレスやコマンド種に応じて格納先のキューを決定することができる。すなわち、本発明では、各キューにエンキューされた時点で、アドレス依存関係は解消されている。このため、後段のリクエストセレクタ３０２は、アドレス依存関係や、コマンドの発行順を気にすることなく処理対象のキューを選択することができる。

リクエストセレクタ３０２は、送信用キュー群３３０から選択したキュー内のリクエストを外部デバイス５に発行する。リクエストセレクタ３０２は、優先度の高いキューを優先的に選択し、選択したキュー内のリクエストを外部デバイス５に発行することが好ましい。

リクエストセレクタ３０２は、高優先キュー（キュー３３１、３３２）からリクエストを抽出して発行する場合、外部デバイス５に発行したリクエストの完了通知を受けることなく、高優先キューから次のリクエストを抽出して発行することが好ましい。詳細には、リクエストセレクタ３０２は、高優先キュー（キュー３３１、３３２）内のリクエストを発行する際、受信部３０３に高優先リクエストの発行を通知する。受信部３０３は、高優先リクエストの発行通知に応じてＡＣＫ信号（コマンドアクノリッジ）を返却する。リクエストセレクタ３０２は、受信部３０３からのＡＣＫ信号に応じて次のリクエストを高優先キューから抽出して発行する。これにより、高優先キューに格納された次のリクエストは、前に発行されたリクエストの完了を待たずに発行され得る。例えば、リクエストセレクタ３０２は、リードコマンドに対するリードレスポンス（リードデータ）が返却される前に、高優先キュー内の次のリクエストを発行することができる。

一方、リクエストセレクタ３０２は、シーケンシャルキュー（キュー３３３）からリクエストを抽出して発行する場合、発行したリクエストの受信完了通知を受けてから次ぎのリクエストを発行する。詳細には、リクエストセレクタ３０２は、シーケンシャルキュー（キュー３３３）内のリクエストを通常通り発行する。受信部３０３は、外部デバイス５から当該リクエストの完了通知を受け取るとリクエストセレクタ３０２にＡＣＫ信号（コマンドアクノリッジ）を出力する。リクエストセレクタ３０２は、受信部３０３からのＡＣＫ信号に応じて次のリクエストをシーケンシャルキューから抽出して発行する。これにより、シーケンシャルキューに格納された次のリクエストは、前に発行されたリクエストの完了に応じて発行されることになる。例えば、リクエストセレクタ３０２は、リードコマンドに対するリードレスポンス（リードデータ）が受信部３０３に返却されるまで、シーケンシャルキュー内の次のリクエストを発行せずに待機する。

図８は、本発明によるリクエストセレクタ３０２の構成の一例を示す図である。図８を参照して、リクエストセレクタ３０２は、ＦＵＬＬ判定用フラグ３２１、優先処理判定回路３２２、セレクタ３２３を備える。

優先処理判定回路３２２は、優先処理判定回路３２２は、各キューにエンキュー（格納）されたリクエスト数に応じて優先処理判定を行い、処理対象となるキューを決定する。この際、優先処理判定回路３２２は、優先度の高いキューから順に格納状況を確認し、高い優先度のキュー３３１にリクエストが格納されていない場合、次に優先度の高いキューを処理対象としてセレクタ３２３に指定する。尚、シーケンシャルキューは最も優先度が低いものとする。又、優先処理判定回路３２２は、高優先キューがリクエストによって満たされた（ＦＵＬＬとなる）場合、当該キュー内のリクエストを全て発行した後、次に優先度の高いキューを処理対象としてセレクタ３２３に指定する。

ＦＵＬＬ判定用フラグ３２１は、高優先キューがリクエストによってＦＵＬＬとなったか否かを示すフラグである。ＦＵＬＬ判定用フラグ３２１は、高優先キューに設定されたキュー３３１、３３２のそれぞれに対応して設けられる。例えば、リクエストによってＦＵＬＬとなったキューのＦＵＬＬ判定用フラグ３２１に“１”がセットされる。優先処理判定回路３２２は、ＦＵＬＬ判定用フラグ３２１によってＦＵＬＬとなったキューを確認できる。

セレクタ３２３は、優先処理判定回路３２２によって処理対象として指定されたキューからリクエストを抽出し、リクエストの内容に応じた外部デバイス５に当該リクエストを発行する。

以上のような構成により、リクエストセレクタ３０２は、高優先キューがリクエストによって満たされる（ＦＵＬＬになる）まで当該高優先キューを処理する。本発明では、高優先のキューがＦＵＬＬになったことをトリガとして、優先度の低いキューが処理される。これにより、優先度の低いキューに格納されたリクエストが発行されずに、システムがライブロックとなることを防止することができる。

図９Ａ及び図９Ｂを参照して、リクエストセレクタ３０２による優先処理制御方法の詳細を説明する。図９Ａ及び図９Ｂは、本発明によるリクエスト制御動作の一例を示すフロー図である。

リクエストセレクタ３０２は、先ず、用意された送信用キュー群３３０の中で最も優先度の高いキュー３３１（優先度“０”）にリクエストが積まれている（格納されている）か否かを確認する（ステップＳ１０１）。キュー３３１にリクエストが積まれている（格納されている）場合、リクエストセレクタ３０２は、キュー３３１のリクエストを外部デバイス５に発行する（ステップＳ１０１Ｙｅｓ、Ｓ１０２）。

次に、リクエストセレクタ３０２は、ＦＵＬＬ判定用フラグ３２１を参照して、キュー３３１がリクエストによってＦＵＬＬになったかを確認する（ステップＳ１０３）。ここで、キュー３３１がＦＵＬＬでない場合、ステップＳ１０１に移行する（ステップＳ１０３Ｎｏ）。一方、キュー３３１がＦＵＬＬとなった場合、キュー３３１に対応するＦＵＬＬ判定用フラグ３２１にＦＵＬＬを示す“１”がセットされ、リクエストセレクタ３０２は、その時点でキュー３３１内に格納されたリクエストを全て外部デバイス５に発行するまで処理を続ける（ステップＳ１０３Ｙｅｓ、Ｓ１０４、Ｓ１０５Ｎｏ）。

優先処理キュー３３１にリクエストが積まれていない場合（ステップＳ１０１Ｎｏ）、あるいは、ＦＵＬＬとなったキュー３３１内の全てのリクエストを処理した場合（ステップＳ１０５Ｙｅｓ）、リクエストセレクタ３０２は、次に優先度の高いキュー３３２（優先度“１”）にリクエストが積まれている（格納されている）か否かを確認する（ステップＳ２０１）。

キュー３３２にリクエストが積まれている場合、リクエストセレクタ３０２は、キュー３３２のリクエストを外部デバイス５に発行する（ステップＳ２０１Ｙｅｓ、Ｓ２０２）。

次に、リクエストセレクタ３０２は、ＦＵＬＬ判定用フラグ３２１を参照して、キュー３３２より優先度の高いキュー３３１のＦＵＬＬ判定用フラグ３２１にＦＵＬＬを示す“１”がセットされているかを確認する（ステップＳ２０３）。ここで、キュー３３１のＦＵＬＬ判定用フラグ３２１にＦＵＬＬを示す“１”がセットされていない場合、ステップＳ１０１に移行する（ステップＳ２０３Ｎｏ）。すなわち、優先度の高いキュー３３１にリクエストがないことをトリガとしてキュー３３２を処理する場合、リクエストセレクタ３０２は、キュー３３２の処理後、優先度の高いキュー３３１を優先的に処理するように制御される。

ステップＳ２０３において、ＦＵＬＬを示す“１”がセットされている場合、リクエストセレクタ３０２は、ＦＵＬＬ判定用フラグ３２１を参照して、キュー３３２がＦＵＬＬになったかを確認する（ステップＳ２０３Ｙｅｓ、Ｓ２０４）。

ステップＳ２０４において、キュー３３２がＦＵＬＬでない場合、ステップＳ２０１に移行する（ステップＳ２０４Ｎｏ）。すなわち、優先度の高いキュー３３１がＦＵＬＬとなったことをトリガとしてキュー３３２を処理する場合、リクエストセレクタ３０２は、キュー３３２の処理又はキュー３３２より低い優先度の処理を継続する。

一方、キュー３３２がＦＵＬＬとなった場合、キュー３３２に対応するＦＵＬＬ判定用フラグ３２１にＦＵＬＬを示す“１”がセットされ、リクエストセレクタ３０２は、その時点でキュー３３２内に格納されたリクエストを全て外部デバイス５に発行するまで処理を続ける（ステップＳ２０４Ｙｅｓ、Ｓ２０５、Ｓ２０６Ｎｏ）。

優先処理キュー３３２にリクエストが積まれていない場合（ステップＳ２０１Ｎｏ）、あるいは、ＦＵＬＬとなったキュー３３２内の全てのリクエストを処理した場合（ステップＳ２０６Ｙｅｓ）、リクエストセレクタ３０２は、次に優先度の高いキュー（ここではシーケンシャルキュー（キュー３３３））にリクエストが積まれているか否かを確認する（ステップＳ３０１）。

キュー３３３にリクエストが積まれている場合、リクエストセレクタ３０２は、キュー３３３のリクエストを外部デバイス５に発行する（ステップＳ３０１Ｙｅｓ、Ｓ３０２）。一方、キュー３３３にリクエストが積まれていない場合、ステップＳ１０１に以降する（ステップＳ３０１Ｎｏ）。

ステップＳ３０２においてキュー３３３に対する処理を行ったリクエストセレクタ３０２は、ＦＵＬＬ判定用フラグ３２１を参照して、キュー３３３より優先度の高いキュー３３１、３３２のＦＵＬＬ判定用フラグ３２１にＦＵＬＬを示す“１”がセットされているかを確認する（ステップＳ３０３、Ｓ３０４）。ここで、キュー３３１、３３２のＦＵＬＬ判定用フラグ３２１にＦＵＬＬを示す“１”がセットされていない場合、ステップＳ１０１に移行する（ステップＳ３０３Ｎｏ、Ｓ３０４Ｎｏ）。すなわち、高優先キュー（キュー３３１、３３２）にリクエストがないことをトリガとしてシーケンシャルキュー（キュー３３３）を処理する場合、リクエストセレクタ３０２は、キュー３３３の処理後、最も優先度の高いキュー３３１を優先的に処理するように制御される。

ステップＳ３０３、Ｓ３０４において、キュー３３１、３３２のＦＵＬＬ判定用フラグ３２１の両方にＦＵＬＬを示す“１”がセットされている場合、リクエストセレクタ３０２は、キュー３３３内にリクエストが格納されていない（ｅｍｐｔｙ）ことを確認する（ステップＳ３０３Ｙｅｓ、Ｓ３０４Ｙｅｓ、Ｓ３０５）。

ステップＳ３０５において、キュー３３２がｅｍｐｔｙでない場合、ステップＳ３０２に移行する（ステップＳ３０５Ｎｏ）。すなわち、優先度の高いキュー３３１、３３２がＦＵＬＬとなったことをトリガとしてキュー３３３を処理する場合、リクエストセレクタ３０２は、キュー３３３内の全てのリクエストを発行するまで、キュー３３３に対する処理を継続する。

一方、キュー３３３がｅｍｐｔｙとなった場合、リクエストセレクタ３０２は、全ての高優先キュー（キュー３３１、３３２）のＦＵＬＬ判定用フラグ３２１に設定された“１”を“０”にクリアする（ステップＳ３０５Ｙｅｓ、Ｓ３０６）。ＦＵＬＬ判定用フラグ３２１をクリア後、ステップＳ１０１に移行し、リクエストセレクタ３０２は、再度、優先度の高いキューを優先して処理を行う。

以上のように、本発明では、複数のキューのうち、どのキューからリクエストを選択するかを、優先処理判定回路３２２によって決定している。このため、各キュー間のリクエストは、アウトオブオーダーで発行される。ただし、キュー内のリクエストは、リクエストに積まれた順（エンキュー順）に処理されるためインオーダで発行される。

優先処理判定回路３２２は、ＦＵＬＬ判定用フラグ３２１を利用することで、高優先キューがＦＵＬＬとなったことをトリガとして、低優先キューやシーケンシャルキューを処理対象として選択する。これにより、優先度の低いキューに格納されたリクエストが発行されずに、システムがライブロックとなることを防止することができる。

受信部３０３は、外部デバイス５からのリクエスト（リクエストコマンド、リクエストアドレス）を受信し、受信用キュー群３２０に格納する。受信用キュー群３２０は、ライトリクエストを格納するライトキュー３４１と、リードリクエストを格納するリードキュー３４２を備える。受信部３０３は、外部デバイス５からのライトリクエストをライトキュー３４１に格納し、外部デバイス５からのリードリクエストをリードキュー３４２に格納する。ライトキュー３４１内のリクエストは、リードキュー３４２に優先してシステムバスリクエスト送信回路３０４に出力される。これは、一般的なＰＣＩで規定された機能であるため、詳細な説明は省略する。

システムバスリクエスト送信回路３０４は、ライトキュー３４１又はリードキュー３４２の一方から出力されたリクエストを、システムバス４を介してバスマスタであるＣＰＵ１、又はＤＭＡコントローラ２に発行する。

本発明によるリクエスト振り分け部３０１は、リクエスト間のアドレス依存関係をキューにエンキューする前に解決し、複数のキューに振り分けている。このため、キュー間のアドレス依存関係を比較する必要がなくなり、システムバス４からのリクエストを直ぐにエンキューすることができる。又、複数のキューにエンキューされたリクエストは、既にアドレス依存関係が解消されているため、処理対象となるキュー任意に選択しても、アクセス先が競合することなくリクエストを発行することができる。このため、実装上の問題を気にすることなくスケーラブルにキューの段数を増やすことが可能となる。

更に、各キューに優先度が付与されており、リクエストセレクタ３０２はその優先度に従って処理対象となるキューを選択する。これにより、発行元のリクエストやコマンド種に優先順位を付与することが可能となり、優先処理させたいリクエストを外部バスブリッジ３に留めることなく、発行することが可能となる。例えば、リードリクエストを優先度の高いキューに格納し、ライトリクエストを優先度の低いキューに格納することで、先にマスタから発行されたライトリクエストよりも先に、リードリクエストを外部デバイス５に発行することできる。従って本発明によれば、従来構成で問題となっていたリードレイテンシを改善することができる。

又、コマンド種として、特定処理（例えば、音声処理や画像処理）に阿智するリクエストを優先度の高いキューにエンキューすることで、特定処理に対する優先処理が可能となる。Ｉ／Ｏリクエスト等、発行オーダの保証が必要なリクエストは、シーケンシャルキュー（キュー３３３）に格納することで、従来と同様に発行オーダを保証することができる。

本発明では、複数のキューにリクエストを格納する前にアドレス依存関係を解消しているため、従来技術のように論理規模を増大させることなく、複数のバスマスタからのリクエスト発行数を増加させることができる。

以上、本発明の実施の形態を詳述してきたが、具体的な構成は上記実施の形態に限られるものではなく、本発明の要旨を逸脱しない範囲の変更があっても本発明に含まれる。上述の実施の形態では、送信用キューとして３つのキュー３３１、３３２、３３３を備える外部バスブリッジ３を一例に説明したが、その数や優先度やシーケンシャルキューの設定はこれに限らない。

１：ＣＰＵ
２：ＤＭＡコントローラ
３：外部バスブリッジ
４：システムバス
５：外部デバイス
１００：半導体集積回路
３００：リクエストウインドウ
３０１：リクエスト振り分け部
３０２：リクエストセレクタ
３０３：受信部
３０４：システムバスリクエスト送信回路
３１０：ウインドウレジスタ
３１１：ベースレジスタ
３１２：サイズレジスタ
３１３：リクエストレジスタ
３１４：振り分け回路
３２０：受信用キュー群
３２１：ＦＵＬＬ判定用フラグ
３２２：優先処理判定回路
３２３：セレクタ
３３０：送信用キュー群
３３１〜３３３：キュー
３４１：ライトキュー
３４２：リードキュー

Claims

複数のキューと、
複数のバスマスタから発行されたリクエストのアクセス先のアドレスに基づいて、前記リクエストを前記複数のキューのいずれかに振り分けるリクエスト振り分け部と、
前記複数のキューから選択したキュー内のリクエストを、外部デバイスに発行するリクエストセレクタと
を具備する
半導体集積回路。
請求項１に記載の半導体集積回路において、
前記リクエスト振り分け部は、前記リクエストのコマンド種に基づいて、前記リクエストを前記複数のキューのいずれかに振り分ける
半導体集積回路。
請求項１又は２に記載の半導体集積回路において、
前記振り分け部は、それぞれが、所定のアドレス範囲が設定されるともに、前記複数のキューのいずれかに対応付けられた複数のウインドウと、リクエストアドレスに一致するアドレスが設定されたウインドウを、前記複数のウインドウから検索する振り分け回路とを備え、
前記振り分け回路は、リクエストアドレスに一致するアドレスが設定されたウインドウに対応するキューに、前記リクエストを格納する
半導体集積回路。
請求項３に記載の半導体集積回路において、
前記複数のウインドウのそれぞれは、所定のコマンド種が設定され、
前記振り分け回路は、リクエストコマンドに一致するコマンド種が設定されたウインドウを、前記複数のウインドウから検索する
前記振り分け回路は、リクエストコマンドに一致するコマンド種が設定されたウインドウに対応するキューに、前記リクエストを格納する
半導体集積回路。
請求項３又は４に記載の半導体集積回路において、
前記振り分け回路は、複数のウインドウを所定の順で検索し、前記リクエストに最初にヒットしたウインドウに基づいて、リクエストの格納先のキューを決定する
半導体集積回路。
請求項１から５のいずれか１項に記載の半導体集積回路において、
前記複数のキューのそれぞれには、異なる優先度が付与され、
前記リクエストセレクタは、前記優先度の高いキュー内のリクエストを優先して選択して外部デバイスに発行する
半導体集積回路。
請求項６に記載の半導体集積回路において、
前記リクエスト振り分け部は、トランザクションの完了を待たずに出力可能なリクエストを第１キューに格納し、トランザクションの完了を待ってから出力するリクエストを前記第１キューより優先度の低い第２キューに格納する
半導体集積回路。
請求項７に記載の半導体集積回路において、
前記リクエスト振り分け部は、メモリへのアクセスリクエストを前記第１キューに格納する
半導体集積回路。
請求項７又は８に記載の半導体集積回路において、
前記リクエスト振り分け部は、外部インタフェースへのアクセスリクエストを前記第２キューに格納する
半導体集積回路。
請求項７から９のいずれか１項に記載の半導体集積回路において、
前記第１キューから選択されて発行されたリクエストに応じて第１応答信号を出力する受信部を更に具備し、
前記リクエストセレクタは、前記第１応答信号に応じて前記第１キューから次のリクエストを抽出して、外部デバイスに発行する
半導体集積回路。
請求項１０に記載の半導体集積回路において、
前記受信部は、前記第２キューから選択されて発行されたリクエストの完了通知を外部デバイスから受信し、前記完了通知に応じて第２応答信号を出力し、
前記リクエストセレクタは、前記第２応答信号に応じて前記第２キューから次のリクエストを抽出して、外部デバイスに発行する
半導体集積回路。
請求項６から１１のいずれか１項に記載の半導体集積回路において、
前記リクエストセレクタは、前記優先度の高いキュー内にリクエストが格納されている場合、前記優先度の高いキュー内のリクエストがなくなるまで、前記優先度の高いキュー内のリクエストを選択して外部デバイスに発行する
半導体集積回路。
請求項１２に記載の半導体集積回路において、
前記リクエストセレクタは、前記優先度の高いキューの全てにリクエストが格納されている場合、前記格納されたリクエストの全てを発行した後、前記優先度の高いキューより低い優先度のキュー内のリクエストを選択して外部デバイスに発行する
半導体集積回路。
複数のキューを用意するステップと、
複数のバスマスタから発行されたリクエストのアクセス先のアドレスに基づいて、前記リクエストを複数のキューのいずれかに振り分けるステップと、
前記複数のキューから選択したキュー内のリクエストを外部デバイスに発行するステップと
を具備する
リクエスト制御方法。
請求項１４に記載のリクエスト制御方法において、
前記振り分けるステップは、前記リクエストのコマンド種に基づいて、前記リクエストを前記複数のキューのいずれかに振り分けるステップを備える
リクエスト制御方法。
請求項１４又は１５に記載のリクエスト制御方法において、
前記複数のキューのそれぞれには、異なる優先度が付与され、
前記リクエストを外部デバイスに発行するステップは、前記優先度の高いキュー内のリクエストを優先して選択して外部デバイスに発行するステップを備える
リクエスト制御方法。
請求項１６に記載のリクエスト制御方法において、
前記振り分けるステップは、トランザクションの完了を待たずに出力可能なリクエストを第１キューに格納するステップと、トランザクションの完了を待ってから出力するリクエストを前記第１キューより優先度の低い第２キューに格納するステップとを備える
リクエスト制御方法。
請求項１７に記載のリクエスト制御方法において、
受信部が、前記第１キューから選択されて発行されたリクエストに応じて第１応答信号を出力するステップと、
前記第１応答信号に応じて前記第１キューから次のリクエストを抽出して、外部デバイスに発行するステップと
を更に具備する
リクエスト制御方法。
請求項１８に記載のリクエスト制御方法において、
前記受信部が、前記第２キューから選択されて発行されたリクエストの完了通知を外部デバイスから受信するステップと、
前記受信部が、前記完了通知に応じて第２応答信号を出力するステップと、
前記第２応答信号に応じて前記第２キューから次のリクエストを抽出して、外部デバイスに発行するステップと
を更に具備する
リクエスト制御方法。
請求項１６から１９のいずれか１項に記載のリクエスト制御方法において、
前記優先度の高いキュー内にリクエストが格納されている場合、前記優先度の高いキュー内のリクエストがなくなるまで、前記優先度の高いキュー内のリクエストを選択して外部デバイスに発行するステップを更に具備する
リクエスト制御方法。
請求項２０に記載のリクエスト制御方法において、
前記優先度の高いキューの全てにリクエストが格納されている場合、前記格納されたリクエストの全てを発行した後、前記優先度の高いキューより低い優先度のキュー内のリクエストを選択して外部デバイスに発行するステップを更に具備する
リクエスト制御方法。