プロセッサシステム
【課題】パイプラインにおける有効な命令の処理率を向上させるプロセッサシステムを提供すること。
【解決手段】本発明の一形態のプロセッサシステムは、パイプラインに、キャッシュメモリ（２）と、複数の命令を格納する命令フェッチバッファ（４１）と、前記キャッシュメモリに対するデータアクセスを要求する実行モジュール（６）と、前記実行モジュールのデータアクセスに係る情報を出力するタグメモリ（３２）と、前記命令フェッチバッファのエントリ情報と、前記タグメモリからのデータアクセスに係る情報とに基づき、前記キャッシュメモリに対するアクセスを調停する調停回路（１）と、を備える。
【解決手段】本発明の一形態のプロセッサシステムは、パイプラインに、キャッシュメモリ（２）と、複数の命令を格納する命令フェッチバッファ（４１）と、前記キャッシュメモリに対するデータアクセスを要求する実行モジュール（６）と、前記実行モジュールのデータアクセスに係る情報を出力するタグメモリ（３２）と、前記命令フェッチバッファのエントリ情報と、前記タグメモリからのデータアクセスに係る情報とに基づき、前記キャッシュメモリに対するアクセスを調停する調停回路（１）と、を備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プロセッサのパイプライン動作において、命令コード及び処理データを統合キャッシュメモリに格納し、アクセス競合時に調停（アービトレーション）を行うプロセッサシステムに関する。
【背景技術】
【０００２】
従来、統合キャッシュメモリへの命令フェッチ、データロード、データストア要求の衝突は、パイプラインの命令供給やキャッシュメモリのヒット／ミスを考慮しない調停ポリシーにより制御されてきた。これにより、命令フェッチ側の命令供給が止まり、パイプラインに無効な命令が流れることで、プロセッサの性能低下を引き起こしていた。
【０００３】
なお特許文献１には、統合されたメモリ・アーキテクチャにおけるアービトレーション・ポリシーが開示されている。
【特許文献１】特表２００２−５３９５０９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
本発明の目的は、パイプラインにおける有効な命令の処理率を向上させるプロセッサシステムを提供することにある。
【課題を解決するための手段】
【０００５】
本発明の一形態のプロセッサシステムは、パイプラインに、キャッシュメモリと、複数の命令を格納する命令フェッチバッファと、前記キャッシュメモリに対するデータアクセスを要求する実行モジュールと、前記実行モジュールのデータアクセスに係る情報を出力するタグメモリと、前記命令フェッチバッファのエントリ情報と、前記タグメモリからのデータアクセスに係る情報とに基づき、前記キャッシュメモリに対するアクセスを調停する調停回路と、を備える。
【発明の効果】
【０００６】
本発明によれば、パイプラインにおける有効な命令の処理率を向上させるプロセッサシステムを提供できる。
【発明を実施するための最良の形態】
【０００７】
以下、本発明の実施の形態を図面を参照して説明する。
【０００８】
本実施の形態では、５段パイプライン（Ｆ(Instruction Fetch)／Ｄ(Decode)／Ｅ(Execute)／Ｍ(Memory Access)／Ｗ(Write Back）)動作を行うプロセッサにおける本発明の適用例を示す。
【０００９】
図１は、統合キャッシュメモリを有する従来のプロセッサシステムのパイプライン動作を示す図である。図１において、５段パイプライン（Ｃ/Ｆ，Ｄ，Ｅ，Ｍ，Ｗ）には調停回路（Arbiter）１を介して統合キャッシュメモリ（Unified Cache Memory）２が接続されている。
【００１０】
図１に示したパイプライン動作中、命令フェッチ(Instruction Fetch)ステージ(Ｆ−Ｓｔａｇｅ)からのメモリアクセスである命令フェッチ要求（Inst Fetch Req）と実行（Execute)ステージ(Ｅ−Ｓｔａｇｅ)からのメモリアクセスであるデータロード／ストア要求（Load/Store Req）とが競合し、調停回路１が実行ステージからのロード／ストア要求を採択したとする。この時、命令フェッチステージの命令フェッチバッファに有効な命令コードが格納されていないと、次サイクルからはデコード（Decode)ステージ（Ｄ−Ｓｔａｇｅ)に無効な命令（バブル）が流れてしまう。
【００１１】
一方、調停回路１が命令フェッチ要求を採択し、実行ステージのロード／ストア要求を待機させた場合、有効な命令コードが命令フェッチステージの命令フェッチバッファに格納されたとしても、後段のロード／ストアが実行されない事に起因するパイプラインストールが発生し、パイプラインの処理は停滞してしまう。
【００１２】
図２は、本実施の形態による統合キャッシュメモリを有するプロセッサシステムのパイプライン動作を示す図である。本実施の形態では、図２のようなパイプラインの構成により、上述したロード／ストア要求を採択したことによる命令フェッチバッファにおける有効な命令コードの枯渇と、命令フェッチ要求を採択したことによるロード／ストア要求の待機に起因するストールの双方の問題を解決する。なお、本実施の形態では、ロード要求とストア要求の扱いは同等とする。
【００１３】
図２において、５段パイプライン（Ｆ，Ｄ，Ｅ，Ｍ，Ｗ）には調停回路１を介して統合キャッシュメモリ２が接続されている。調停回路１は、ロード／ストアバッファ（ＵＣＬＢ：UCLoadBuf／ＵＣＳＢ：UCStoreBuf）１１を備えている。また、Ｄ（Decode)ステージから調停回路１へのパス上にはタグメモリ（Tag Memory）３が設けられている。
【００１４】
まず、本実施の形態における命令フェッチ、データロード／ストアの基本動作と統合キャッシュメモリの定義を説明する。本実施の形態における５段パイプラインでは、命令フェッチステージ(Ｆ−Ｓｔａｇｅ)とデコードステージ（Ｄ−Ｓｔａｇｅ)以降の後段ステージは独立的に動作する。
【００１５】
さらに、後述するように命令フェッチステージ内に複数の命令を格納可能な命令フェッチバッファを有することで、デコードステージ以降がパイプラインストールにより停止中であっても命令フェッチを先行して実行可能である。統合キャッシュメモリ２に対する命令フェッチは、命令フェッチステージの前段（ここではＣステージと呼称）からリクエストが発行され、命令フェッチステージで命令コードが供給される。
【００１６】
一方、統合キャッシュメモリ２に対するデータロード／ストア要求は、実行ステージ(Ｅ−Ｓｔａｇｅ)においてリクエストを発行し、キャッシュヒット時はメモリ（Memory）ステージ(Ｍ−Ｓｔａｇｅ)においてロードデータの取得とメモリに対するデータストアの実行が達成される。
【００１７】
統合キャッシュメモリ２は、命令コード及びデータ格納部に対する命令フェッチ要求とロード／ストア要求を同時には受け付けられない。しかし後述するように、命令フェッチ系統とロード／ストア系統に対する（ヒット／ミスを判定する）タグメモリ領域を独立して保持しているため、アクセス対象のラインに対するヒット／ミスの判定を並列に行うことができる。なお、１つのステージから同時にロード要求とストア要求が発行されることはない。
【００１８】
図２に示した本実施の形態によるパイプライン構成における従来手法によるパイプライン構成との大きな違いとして、以下の項目が挙げられる。
【００１９】
(1)命令フェッチステージ(Ｆ−Ｓｔａｇｅ)内の命令フェッチバッファの有効コード格納状況を調停回路１に伝達するパス。
【００２０】
(2)待機中のロード／ストア要求を保持するバッファ（ＵＣＬＢ／ＵＣＳＢ）１１。すなわち、統合キャッシュメモリ２に対するロードリクエストバッファ(ＵＣＬＢ:Unified Cache memory Load request Buffer)＋統合キャッシュメモリ２に対するストアリクエストバッファ(ＵＣＳＢ:Unified Cache memory Store request Buffer)。
【００２１】
(3)デコードステージ（Ｄ−Ｓｔａｇｅ)からタグメモリ３にアクセスし、ヒット／ミス情報を調停回路１に伝達するパス。
【００２２】
項目(1)のパスは、命令フェッチバッファ内に有効エントリが存在せず、命令が枯渇している事を調停回路１に通知することで、無効な命令がパイプラインを流れないよう調停を実施するために存在する。
【００２３】
項目(2)のＵＣＬＢ／ＵＣＳＢは、実行ステージ(Ｅ−Ｓｔａｇｅ)におけるロード／ストア要求が命令フェッチ要求と衝突した際に、パイプラインストールを発生させることなく、ロード／ストア要求を保持するために存在する。
【００２４】
項目(3)のパスは、従来手法においては統合キャッシュメモリ２へのアクセスと同時に行っていたタグメモリへのアクセスを１段早めることで、実行ステージに達したロード／ストア要求のヒット／ミス情報を調停回路１に通知している。
【００２５】
図３は、上記３つのアーキテクチャ的特徴を含んだ本実施の形態のパイプラインの実装例を示す図である。
【００２６】
図３には、統合キャッシュメモリ（Unified Cache Memory)２、タグメモリ（Ｉ−Ｔａｇ）３１、タグメモリ（Ｄ−Ｔａｇ）３２の３つの領域が存在する。なお、必ずしもタグメモリを命令コード（Ｉ−Ｔａｇ）とデータコード（Ｄ−Ｔａｇ）に分けて実装する必要はない。すなわち、命令コード（Ｉ−Ｔａｇ）とデータコード（Ｄ−Ｔａｇ）を異なるタグメモリで実装することも可能であるし、命令コード（Ｉ−Ｔａｇ）とデータコード（Ｄ−Ｔａｇ）を同一のタグメモリ上で領域を分けて実装することも可能である。
【００２７】
統合キャッシュメモリ２は、命令コード本体とロード／ストア対象となるデータ本体を格納している。タグメモリ３１，３２は、各キャッシュラインに対応したタグ部を格納している。タグメモリ３１は命令コード格納領域に対応するタグ、タグメモリ３２はロード／ストア対象のデータ格納領域に対応するタグを保持している。すなわち、タグメモリ３は２入力２出力構成をなす。
【００２８】
また、処理モジュールとして、命令フェッチモジュール（InstFetch Module）４、デコードモジュール（Decode Module）５、実行モジュール（Execute Module）６、調停及びＵＣアクセスモジュール（APUCA:Arbiter Plus Unified Cache Access Module）１が存在する。
【００２９】
命令フェッチモジュール４は、有効な命令コードを格納するための命令フェッチバッファ（ＩｎｓｔＢｕｆ）４１を複数保持し、デコードモジュール５以降のパイプライン後段のストール時も、統合キャッシュメモリ２から有効な命令コードをフェッチすることができる。デコードモジュール５は、命令フェッチモジュール４からの命令コードをデコードし、いずれ実行モジュール６内でリクエスト発行するロード／ストアを検知して、アドレス計算を行い、データ格納領域のタグ情報を管理するタグメモリ（Ｄ−Ｔａｇ）３２にアクセスする。
【００３０】
なお、データストア要求と命令フェッチ要求の衝突時に、ストア要求をヒット／ミス情報に依らず複数段のストアリクエストバッファ（ＵＣＳＢ）に格納することで命令フェッチ要求を優先し、後にストアリクエストバッファ（ＵＣＳＢ）内のストア要求を統合キャッシュメモリ２にアクセス可能な期間（他のアクセスがない期間）内で処理するアプローチも可能だが、ここではロード／ストア要求共に先行タグアクセスを行うアプローチについて説明する。
【００３１】
タグメモリ（Ｄ−Ｔａｇ）３２から読み出されたロード／ストア要求のヒット／ミス情報は、要求本体が実行モジュール６内の実行ステージ（Ｅ−ｓｔａｇｅ）に達し、実行モジュール６がロード／ストア要求を発行するサイクルと同時に調停及びＵＣアクセスモジュール１に達する。
【００３２】
調停及びＵＣアクセスモジュール１内部のステートマシン１２は、命令フェッチモジュール４からの命令フェッチ要求（InstFetch Req）及び命令フェッチバッファ４１内の有効エントリ情報（InstBuf Info）と、実行モジュール６からのロード／ストア要求（Load/Store Req）と、タグメモリ（Ｄ−Ｔａｇ）３２からのヒット／ミス情報（Hit/Miss Info）とを基に状態遷移を行い、後述する調停ポリシーに従って統合キャッシュメモリ２に発行するリクエストを決定する。
【００３３】
調停及びＵＣアクセスモジュール１における調停で退けられたロード／ストア要求は、後に統合キャッシュメモリ２に発行されるため、一時ロード／ストアバッファ１１に退避される（図中のＳｔａｎｄｂｙパス）。その後、ステートマシン１２によってロード／ストアバッファ１１内のリクエストの発行許可が下りた際に、ロード／ストアバッファ１１から統合キャッシュメモリ２に向けてリクエストを発する（図中のＩｓｓｕｅパス）。
【００３４】
調停後に採択されたリクエストは、１入力１出力の統合キャッシュメモリ（同時に１つしかリクエストを受け付けないメモリ）２に伝達される。ここで、採択されたリクエストが命令フェッチ要求である場合は、事前にタグメモリ参照を行っていないため、同時にタグメモリ（Ｉ−Ｔａｇ）３１に対するアクセスを行う。統合キャッシュメモリ２から調停及びＵＣアクセスモジュール１に返された命令コード(Inst Code)は命令フェッチモジュール４へと、ロードデータ（Load Data）は実行モジュール６へと返される。
【００３５】
ここで、ロード要求がロード／ストアバッファ１１のＵＣＬＢにより一度退避された要求である場合は、実行モジュール６内のメモリステージ（Ｍ−ｓｔａｇｅ）ではなく、ライトバックステージ（Ｗ−ｓｔａｇｅ）にロードデータ（Load Data）が伝達される。実装の方法によっては、クリティカルパス回避のために、ロードデータをライトバックステージに伝達するパスにレジスタ７を挿入することも考えられる（図中では点線でレジスタを表記）。
【００３６】
レジスタ７を挿入した場合、デコードステージ（Ｄ−ｓｔａｇｅ）のレジスタセット（Register Set）５１へのデータ書き込みが１サイクル遅れるため、その後のレジスタ値読み込みとの調整が必要である。
【００３７】
命令フェッチ要求との衝突によりロード要求が待たされ、ロードリクエストバッファ(ＵＣＬＢ)を用いて統合キャッシュメモリ２へのアクセスが行われた場合は、このライトバックステージ（Ｗ−ｓｔａｇｅ）へのパスを通ってロードデータが届く。命令フェッチ要求との衝突がなく、ＵＣＬＢを介さずに通常通りロード要求が実行された場合は、ロードデータはメモリステージ（Ｍ−ｓｔａｇｅ）へのパスを通って届く。
【００３８】
続いて、命令フェッチ要求とロード／ストア要求の調停における基本方針を説明する。基本方針として、以下の項目が挙げられる。
【００３９】
(1)複数存在する命令フェッチバッファによってフェッチレイテンシの隠蔽が可能な際は、ロード／ストア要求を優先する。
【００４０】
(2)命令フェッチバッファ内の有効命令コードが枯渇し、無効な命令がパイプラインに流れる可能性がある局面では命令フェッチ要求を優先する。
【００４１】
(3)実行ステージに達したロード／ストア要求がキャッシュミスを発生する事が既知であれば、ロード／ストア要求を優先する。
【００４２】
調停回路１の基本方針(3)において、キャッシュミスを伴うロード／ストア要求と命令フェッチ要求が衝突した際に（命令フェッチバッファ内の有効命令コードが枯渇時も）ロード／ストア要求を優先する理由を以下に説明する。
【００４３】
図４は、本実施の形態の手法によるキャッシュリフィル時のパイプライン動作を示す図である。図４は、命令フェッチバッファ内の有効命令コードが枯渇した状態で、キャッシュミスを伴うロード要求と命令フェッチ要求が衝突した際に、調停回路１がロード要求を採択した例を示す。説明を簡潔にするため、ここではロード後の命令（ｎ１〜ｎ５）をロード／ストア／分岐命令でないものと仮定する。
【００４４】
図４において、“サイクル（Ｃｙｃｌｅ）１”で命令フェッチ要求を待機させたため、“サイクル２”の命令フェッチステージ(Ｆ−Ｓｔａｇｅ)に無効な命令（バブル）Ｂが挿入されていることが確認できる。その後、“サイクル３”以降ではロード要求（Load）がメモリステージにおいて外部メモリ２０からのリフィル（Ｒｅｆｉｌｌ）待ちのために停滞する（ストール）。この間、統合キャッシュメモリ２に対するロード起因のメモリアクセスは発生しないため、後段のパイプラインと独立した命令フェッチステージは有効な命令コード（ｎ３）を読み出し、先の無効な命令（バブル）Ｂと有効な命令（ｎ３）を交換する（サイクル３）。
【００４５】
さらに、バスレイテンシによるリフィルデータ待ち状態の間に、命令フェッチステージは着々と統合キャッシュメモリ２から命令コード（ｎ４、ｎ５）を読み出し、命令フェッチバッファに格納する（サイクル４，５）。その後、外部バス３０からリフィルデータ（Refill Data）が返された際に統合キャッシュメモリ２にリフィルデータを書き戻し、（クリティカルワードファースト機構等を適用すれば）メモリステージ(Ｍ−Ｓｔａｇｅ)のロード要求(Load）はストール解除される（サイクル６）。その後は、命令フェッチバッファに格納された有効な命令コード（ｎ４、ｎ５）を元にパイプライン動作が再開される（サイクル７、８）。
【００４６】
上記に示した通り、リフィル動作の間に命令フェッチ動作を実現することで、パイプラインに無効な命令を流すことなく、リフィル後のパイプライン動作を実現することができる。仮に、“サイクル１”の段階で命令フェッチを優先させた場合、ロード要求のリフィル開始動作が１サイクル遅れるため、ロード要求の終了もサイクル７からサイクル８へと遅れることになる。
【００４７】
図５は、従来の手法と本実施の形態の手法のパイプライン効率の比較結果を示す図であり、（ａ）は従来の手法、（ｂ）は本実施の形態の手法を示す。図５中の“サイクル（Ｃｙｃｌｅ）１”では、既に命令フェッチバッファ中の有効命令が枯渇しているものとする。
【００４８】
従来手法では、図５の（ａ）に示すように、“サイクル１”において（後段のロードを待機させた場合ストールになる判断から）命令フェッチを待機させたため、“サイクル２”以降で無効な命令Ｂがパイプラインを流れている。ロード要求（Load）の３命令後に位置する「ｎ３」命令は、最終的に“サイクル７”で処理を終える。
【００４９】
一方本実施の形態のパイプラインでは、図５の（ｂ）に示すように、“サイクル１”で命令フェッチを採択し（ロードヒットと仮定）、ロード要求はＵＣＬＢに格納される。そのため、“サイクル２”では有効な命令がパイプラインに供給される。同時に（サイクル２では）ＵＣＬＢからロード要求を統合キャッシュメモリ２に発行し、データをライトバックステージ（Ｗ−ｓｔａｇｅ）で回収する。“サイクル１”の時点で当該ロード要求がヒットすることが既知であるため、ライトバックステージ以降に遅れることはない。
【００５０】
ロード命令の３命令後に位置する「ｎ３」命令は、最終的に“サイクル６”で処理を終える。命令フェッチバッファのビット長を１実行命令のビット長よりも長く設定すれば、“サイクル３”以降も直ぐには命令は枯渇しない。
【００５１】
図５の（ｂ）の“サイクル１”においては、命令フェッチとＥ−ｓｔａｇｅのロード命令が衝突し、命令フェッチが有効になったため、ＵＣＬＢにロード命令が待機するために格納される。その後、“サイクル２”においてロード要求がＵＣＬＢから統合キャッシュメモリ２に発行され、“サイクル３”において、Ｗ−ｓｔａｇｅのロード要求に対してロードデータが返る。
【００５２】
図５の（ｂ）の“サイクル２”において、さらに命令フェッチが発生した場合、Ｅ−ｓｔａｇｅの「ｎ１」命令がロード要求またはストア要求だった場合、統合キャッシュメモリ２へは、１．命令フェッチ、２．「ｎ１」命令がロード要求またはストア要求だった場合の要求、３．ＵＣＬＢ中のロード要求の３つの要求が発生する。
【００５３】
ここで、ＵＣＬＢのロード要求が実行されない場合、Ｍ−ｓｔａｇｅのロード要求は次のステージ（Ｗ−ｓｔａｇｅ）に移行してもロードデータが得られないためＭ−ｓｔａｇｅに留まり、パイプラインはストール(一時停止)する（Ｆ：ｎ３、Ｄ：ｎ２、Ｅ：ｎ１、Ｍ：Ｌｏａｄ、Ｗ：空白）。
【００５４】
その後、ＵＣＬＢ内のロード要求が実行され、次サイクルでロードデータが返る事が判断された段階で、Ｍ−ｓｔａｇｅのロード命令はＷ−ｓｔａｇｅに進み（サイクル３）、ロードデータを受け取り処理を完了する。
【００５５】
図６〜図９は、本実施の形態の手法において命令フェッチ要求、Ｅ−ｓｔａｇｅのロード／ストア要求、ＵＣＬＢ／ＵＣＳＢ要求の３つのアクセス要求が統合キャッシュメモリ２に向けられた際の調停方法を示す図である。なお、図６〜図９では、図５と同様にパイプラインを表記している。
【００５６】
上記の説明においては、始めにロード／ストアバッファ（ＵＣＬＢ／ＵＣＳＢ）１１が空の状態で、調停回路１が命令フェッチ要求、ロード／ストア要求を調停する方法を示した。以下では、ＵＣＬＢ／ＵＣＳＢ中に以前の調停により待機させられているロード/ストア要求が存在する場合の調停方法について説明する。
【００５７】
図６〜図９では、“サイクル１”において、命令フェッチ要求(Fetch Req)、Ｅ−ｓｔａｇｅのロード／ストア要求（Load/Store Req）、Ｅ−ｓｔａｇｅで要求を止められ、ＵＣＬＢ／ＵＣＳＢ中で待機しているロード／ストア要求(要求元のロード／ストア命令はパイプライン中のＭ−ｓｔａｇｅに存在する)の３者のアクセス要求が統合キャッシュメモリ２へ発生している状況を示している。なお、図中「−」は無効な命令(バブル)を示し、「ｎ２…ｎ５」はロード／ストア要求以外の命令群として表記している。
【００５８】
Ｅ−ｓｔａｇｅ／Ｍ−ｓｔａｇｅに存在するロード/ストア要求のＨｉｔ／Ｍｉｓｓの組み合わせは、以下に示すように２×２＝４通りのパターンが存在する。
【００５９】
Ｅ−ｓｔａｇｅ Ｍ−ｓｔａｇｅ
Ａ： Ｍｉｓｓ Ｍｉｓｓ
Ｂ： Ｍｉｓｓ Ｈｉｔ
Ｃ： Ｈｉｔ Ｍｉｓｓ
Ｄ： Ｈｉｔ Ｈｉｔ
パターンＡ，Ｂ，Ｃ，Ｄの何れの場合も、ＵＣＬＢ／ＵＣＳＢ内で待機中のロード/ストア要求からの統合キャッシュメモリ２へのアクセスを通さないと、パイプラインはストール(一時停止)する。よって「ＵＣＬＢ／ＵＣＳＢ中にロード／ストア要求が存在する場合はそれを最優先とする」ポリシーによって、３者のアクセス要求時の調停を行う。なお、図６〜図９において斜線を付けたアクセス要求は、調停の結果、統合キャッシュメモリ２へのアクセスが可能な事を示している。
【００６０】
図６の場合、load0(Miss)に続くload1(Miss)もキャッシュMissを引き起こし、外部バス３０を用いたリフィル（Refill）処理（図４の外部ＲＡＭ２０への処理と同様）を必要とするため、load0のリフィル処理が終わるまで、ＵＣＬＢで待機する。外部バス３０はload0のリフィル終了まで占有される想定であり、load0はリフィルデータが返ってくるまでは、パイプラインのＭ−ｓｔａｇｅに留まり、データの到着を待つ。つまり、ここでパイプラインのストールが発生する。パイプラインは、ロード／ストア要求がＭ−ｓｔａｇｅに存在し、次のステージ（Ｗ−ｓｔａｇｅ）に移行しても処理データが到達できないためにストールする。図６中の“サイクル（Ｃｙｃｌｅ）”の「Ｘ」は、リフィル処理の時間に依存する。
【００６１】
図７の場合、ＵＣＳＢに待機中のstore0(Hit)を処理した後にload1(Miss)の処理に移る。すなわち、Ｍ−ｓｔａｇｅのstore0(Hit)を採択し、パイプライン後段の処理を優先する。命令フェッチ要求(Fetch Req)がされないため、パイプラインに無効な命令(バブル)が流れるが、load1(Miss)の長いリフィル処理中に空いたサイクルを利用して命令フェッチをすることで、パイプライン中のバブルに有効な命令(図７ではｎ４やｎ５)を埋めることが可能になる。
【００６２】
図８の場合、ＵＣＬＢに待機中のload0(Miss)のリフィルの待ちサイクル中に総合キャッシュメモリ２自体が空くため、この空きサイクル２を利用して、load1(Hit)の処理を行う。ただし、load1(Hit)のアクセス先が、load0(Miss)のリフィル処理によってキャッシュの張替え中のラインを対象としている場合はアクセスができないため、待機状態となる(図６のload1(Miss)の待機に近い動作)。なお、load0(Miss)のリフィル処理によるラインでなければ、load1(Hit)は統合キャッシュメモリ２へアクセス可能である。
【００６３】
図９の場合、load0(Hit)もload1(Hit)も統合キャッシュメモリ２を１サイクル間占拠して処理を行うため、空きサイクルはなく、load0→load1→Fetch Reqの順に処理される。
【００６４】
以上のように本実施の形態によれば、パイプライン中の命令フェッチバッファの格納状況（エントリ情報）や、キャッシュメモリへのデータアクセス情報（ヒット／ミス情報）を考慮した上で、命令フェッチ側・データ処理側から統合キャッシュメモリに対して生ずるメモリアクセスを調停することで、パイプラインの有効命令処理率（パイプライン効率）の向上を図ることができる。
【００６５】
本発明は、上記実施の形態のみに限定されず、要旨を変更しない範囲で適宜変形して実施できる。例えば、本発明は上記実施の形態に限らず多用なパイプライン構成に適用できる。
【図面の簡単な説明】
【００６６】
【図１】統合キャッシュメモリを有する従来のプロセッサシステムのパイプライン動作を示す図。
【図２】実施の形態による統合キャッシュメモリを有するプロセッサシステムのパイプライン動作を示す図。
【図３】実施の形態のパイプラインの実装例を示す図。
【図４】実施の形態の手法によるキャッシュリフィル時のパイプライン動作を示す図。
【図５】従来の手法と本実施の形態の手法のパイプライン効率の比較結果を示す図であり、（ａ）は従来の手法、（ｂ）は本実施の形態の手法を示す図。
【図６】実施の形態の手法による３つのキャッシュメモリアクセス発生時のパイプライン動作を示す図。
【図７】実施の形態の手法による３つのキャッシュメモリアクセス発生時のパイプライン動作を示す図。
【図８】実施の形態の手法による３つのキャッシュメモリアクセス発生時のパイプライン動作を示す図。
【図９】実施の形態の手法による３つのキャッシュメモリアクセス発生時のパイプライン動作を示す図。
【符号の説明】
【００６７】
１…調停及びＵＣアクセスモジュール １１…ロード／ストアバッファ １２…ステートマシン ３，３１，３２…タグメモリ ４…命令フェッチモジュール ４１…命令フェッチバッファ ５…デコードモジュール ５１…レジスタセット ６…実行モジュール ７…パス対策レジスタ ２０…外部ＲＡＭ ３０…バス
【技術分野】
【０００１】
本発明は、プロセッサのパイプライン動作において、命令コード及び処理データを統合キャッシュメモリに格納し、アクセス競合時に調停（アービトレーション）を行うプロセッサシステムに関する。
【背景技術】
【０００２】
従来、統合キャッシュメモリへの命令フェッチ、データロード、データストア要求の衝突は、パイプラインの命令供給やキャッシュメモリのヒット／ミスを考慮しない調停ポリシーにより制御されてきた。これにより、命令フェッチ側の命令供給が止まり、パイプラインに無効な命令が流れることで、プロセッサの性能低下を引き起こしていた。
【０００３】
なお特許文献１には、統合されたメモリ・アーキテクチャにおけるアービトレーション・ポリシーが開示されている。
【特許文献１】特表２００２−５３９５０９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
本発明の目的は、パイプラインにおける有効な命令の処理率を向上させるプロセッサシステムを提供することにある。
【課題を解決するための手段】
【０００５】
本発明の一形態のプロセッサシステムは、パイプラインに、キャッシュメモリと、複数の命令を格納する命令フェッチバッファと、前記キャッシュメモリに対するデータアクセスを要求する実行モジュールと、前記実行モジュールのデータアクセスに係る情報を出力するタグメモリと、前記命令フェッチバッファのエントリ情報と、前記タグメモリからのデータアクセスに係る情報とに基づき、前記キャッシュメモリに対するアクセスを調停する調停回路と、を備える。
【発明の効果】
【０００６】
本発明によれば、パイプラインにおける有効な命令の処理率を向上させるプロセッサシステムを提供できる。
【発明を実施するための最良の形態】
【０００７】
以下、本発明の実施の形態を図面を参照して説明する。
【０００８】
本実施の形態では、５段パイプライン（Ｆ(Instruction Fetch)／Ｄ(Decode)／Ｅ(Execute)／Ｍ(Memory Access)／Ｗ(Write Back）)動作を行うプロセッサにおける本発明の適用例を示す。
【０００９】
図１は、統合キャッシュメモリを有する従来のプロセッサシステムのパイプライン動作を示す図である。図１において、５段パイプライン（Ｃ/Ｆ，Ｄ，Ｅ，Ｍ，Ｗ）には調停回路（Arbiter）１を介して統合キャッシュメモリ（Unified Cache Memory）２が接続されている。
【００１０】
図１に示したパイプライン動作中、命令フェッチ(Instruction Fetch)ステージ(Ｆ−Ｓｔａｇｅ)からのメモリアクセスである命令フェッチ要求（Inst Fetch Req）と実行（Execute)ステージ(Ｅ−Ｓｔａｇｅ)からのメモリアクセスであるデータロード／ストア要求（Load/Store Req）とが競合し、調停回路１が実行ステージからのロード／ストア要求を採択したとする。この時、命令フェッチステージの命令フェッチバッファに有効な命令コードが格納されていないと、次サイクルからはデコード（Decode)ステージ（Ｄ−Ｓｔａｇｅ)に無効な命令（バブル）が流れてしまう。
【００１１】
一方、調停回路１が命令フェッチ要求を採択し、実行ステージのロード／ストア要求を待機させた場合、有効な命令コードが命令フェッチステージの命令フェッチバッファに格納されたとしても、後段のロード／ストアが実行されない事に起因するパイプラインストールが発生し、パイプラインの処理は停滞してしまう。
【００１２】
図２は、本実施の形態による統合キャッシュメモリを有するプロセッサシステムのパイプライン動作を示す図である。本実施の形態では、図２のようなパイプラインの構成により、上述したロード／ストア要求を採択したことによる命令フェッチバッファにおける有効な命令コードの枯渇と、命令フェッチ要求を採択したことによるロード／ストア要求の待機に起因するストールの双方の問題を解決する。なお、本実施の形態では、ロード要求とストア要求の扱いは同等とする。
【００１３】
図２において、５段パイプライン（Ｆ，Ｄ，Ｅ，Ｍ，Ｗ）には調停回路１を介して統合キャッシュメモリ２が接続されている。調停回路１は、ロード／ストアバッファ（ＵＣＬＢ：UCLoadBuf／ＵＣＳＢ：UCStoreBuf）１１を備えている。また、Ｄ（Decode)ステージから調停回路１へのパス上にはタグメモリ（Tag Memory）３が設けられている。
【００１４】
まず、本実施の形態における命令フェッチ、データロード／ストアの基本動作と統合キャッシュメモリの定義を説明する。本実施の形態における５段パイプラインでは、命令フェッチステージ(Ｆ−Ｓｔａｇｅ)とデコードステージ（Ｄ−Ｓｔａｇｅ)以降の後段ステージは独立的に動作する。
【００１５】
さらに、後述するように命令フェッチステージ内に複数の命令を格納可能な命令フェッチバッファを有することで、デコードステージ以降がパイプラインストールにより停止中であっても命令フェッチを先行して実行可能である。統合キャッシュメモリ２に対する命令フェッチは、命令フェッチステージの前段（ここではＣステージと呼称）からリクエストが発行され、命令フェッチステージで命令コードが供給される。
【００１６】
一方、統合キャッシュメモリ２に対するデータロード／ストア要求は、実行ステージ(Ｅ−Ｓｔａｇｅ)においてリクエストを発行し、キャッシュヒット時はメモリ（Memory）ステージ(Ｍ−Ｓｔａｇｅ)においてロードデータの取得とメモリに対するデータストアの実行が達成される。
【００１７】
統合キャッシュメモリ２は、命令コード及びデータ格納部に対する命令フェッチ要求とロード／ストア要求を同時には受け付けられない。しかし後述するように、命令フェッチ系統とロード／ストア系統に対する（ヒット／ミスを判定する）タグメモリ領域を独立して保持しているため、アクセス対象のラインに対するヒット／ミスの判定を並列に行うことができる。なお、１つのステージから同時にロード要求とストア要求が発行されることはない。
【００１８】
図２に示した本実施の形態によるパイプライン構成における従来手法によるパイプライン構成との大きな違いとして、以下の項目が挙げられる。
【００１９】
(1)命令フェッチステージ(Ｆ−Ｓｔａｇｅ)内の命令フェッチバッファの有効コード格納状況を調停回路１に伝達するパス。
【００２０】
(2)待機中のロード／ストア要求を保持するバッファ（ＵＣＬＢ／ＵＣＳＢ）１１。すなわち、統合キャッシュメモリ２に対するロードリクエストバッファ(ＵＣＬＢ:Unified Cache memory Load request Buffer)＋統合キャッシュメモリ２に対するストアリクエストバッファ(ＵＣＳＢ:Unified Cache memory Store request Buffer)。
【００２１】
(3)デコードステージ（Ｄ−Ｓｔａｇｅ)からタグメモリ３にアクセスし、ヒット／ミス情報を調停回路１に伝達するパス。
【００２２】
項目(1)のパスは、命令フェッチバッファ内に有効エントリが存在せず、命令が枯渇している事を調停回路１に通知することで、無効な命令がパイプラインを流れないよう調停を実施するために存在する。
【００２３】
項目(2)のＵＣＬＢ／ＵＣＳＢは、実行ステージ(Ｅ−Ｓｔａｇｅ)におけるロード／ストア要求が命令フェッチ要求と衝突した際に、パイプラインストールを発生させることなく、ロード／ストア要求を保持するために存在する。
【００２４】
項目(3)のパスは、従来手法においては統合キャッシュメモリ２へのアクセスと同時に行っていたタグメモリへのアクセスを１段早めることで、実行ステージに達したロード／ストア要求のヒット／ミス情報を調停回路１に通知している。
【００２５】
図３は、上記３つのアーキテクチャ的特徴を含んだ本実施の形態のパイプラインの実装例を示す図である。
【００２６】
図３には、統合キャッシュメモリ（Unified Cache Memory)２、タグメモリ（Ｉ−Ｔａｇ）３１、タグメモリ（Ｄ−Ｔａｇ）３２の３つの領域が存在する。なお、必ずしもタグメモリを命令コード（Ｉ−Ｔａｇ）とデータコード（Ｄ−Ｔａｇ）に分けて実装する必要はない。すなわち、命令コード（Ｉ−Ｔａｇ）とデータコード（Ｄ−Ｔａｇ）を異なるタグメモリで実装することも可能であるし、命令コード（Ｉ−Ｔａｇ）とデータコード（Ｄ−Ｔａｇ）を同一のタグメモリ上で領域を分けて実装することも可能である。
【００２７】
統合キャッシュメモリ２は、命令コード本体とロード／ストア対象となるデータ本体を格納している。タグメモリ３１，３２は、各キャッシュラインに対応したタグ部を格納している。タグメモリ３１は命令コード格納領域に対応するタグ、タグメモリ３２はロード／ストア対象のデータ格納領域に対応するタグを保持している。すなわち、タグメモリ３は２入力２出力構成をなす。
【００２８】
また、処理モジュールとして、命令フェッチモジュール（InstFetch Module）４、デコードモジュール（Decode Module）５、実行モジュール（Execute Module）６、調停及びＵＣアクセスモジュール（APUCA:Arbiter Plus Unified Cache Access Module）１が存在する。
【００２９】
命令フェッチモジュール４は、有効な命令コードを格納するための命令フェッチバッファ（ＩｎｓｔＢｕｆ）４１を複数保持し、デコードモジュール５以降のパイプライン後段のストール時も、統合キャッシュメモリ２から有効な命令コードをフェッチすることができる。デコードモジュール５は、命令フェッチモジュール４からの命令コードをデコードし、いずれ実行モジュール６内でリクエスト発行するロード／ストアを検知して、アドレス計算を行い、データ格納領域のタグ情報を管理するタグメモリ（Ｄ−Ｔａｇ）３２にアクセスする。
【００３０】
なお、データストア要求と命令フェッチ要求の衝突時に、ストア要求をヒット／ミス情報に依らず複数段のストアリクエストバッファ（ＵＣＳＢ）に格納することで命令フェッチ要求を優先し、後にストアリクエストバッファ（ＵＣＳＢ）内のストア要求を統合キャッシュメモリ２にアクセス可能な期間（他のアクセスがない期間）内で処理するアプローチも可能だが、ここではロード／ストア要求共に先行タグアクセスを行うアプローチについて説明する。
【００３１】
タグメモリ（Ｄ−Ｔａｇ）３２から読み出されたロード／ストア要求のヒット／ミス情報は、要求本体が実行モジュール６内の実行ステージ（Ｅ−ｓｔａｇｅ）に達し、実行モジュール６がロード／ストア要求を発行するサイクルと同時に調停及びＵＣアクセスモジュール１に達する。
【００３２】
調停及びＵＣアクセスモジュール１内部のステートマシン１２は、命令フェッチモジュール４からの命令フェッチ要求（InstFetch Req）及び命令フェッチバッファ４１内の有効エントリ情報（InstBuf Info）と、実行モジュール６からのロード／ストア要求（Load/Store Req）と、タグメモリ（Ｄ−Ｔａｇ）３２からのヒット／ミス情報（Hit/Miss Info）とを基に状態遷移を行い、後述する調停ポリシーに従って統合キャッシュメモリ２に発行するリクエストを決定する。
【００３３】
調停及びＵＣアクセスモジュール１における調停で退けられたロード／ストア要求は、後に統合キャッシュメモリ２に発行されるため、一時ロード／ストアバッファ１１に退避される（図中のＳｔａｎｄｂｙパス）。その後、ステートマシン１２によってロード／ストアバッファ１１内のリクエストの発行許可が下りた際に、ロード／ストアバッファ１１から統合キャッシュメモリ２に向けてリクエストを発する（図中のＩｓｓｕｅパス）。
【００３４】
調停後に採択されたリクエストは、１入力１出力の統合キャッシュメモリ（同時に１つしかリクエストを受け付けないメモリ）２に伝達される。ここで、採択されたリクエストが命令フェッチ要求である場合は、事前にタグメモリ参照を行っていないため、同時にタグメモリ（Ｉ−Ｔａｇ）３１に対するアクセスを行う。統合キャッシュメモリ２から調停及びＵＣアクセスモジュール１に返された命令コード(Inst Code)は命令フェッチモジュール４へと、ロードデータ（Load Data）は実行モジュール６へと返される。
【００３５】
ここで、ロード要求がロード／ストアバッファ１１のＵＣＬＢにより一度退避された要求である場合は、実行モジュール６内のメモリステージ（Ｍ−ｓｔａｇｅ）ではなく、ライトバックステージ（Ｗ−ｓｔａｇｅ）にロードデータ（Load Data）が伝達される。実装の方法によっては、クリティカルパス回避のために、ロードデータをライトバックステージに伝達するパスにレジスタ７を挿入することも考えられる（図中では点線でレジスタを表記）。
【００３６】
レジスタ７を挿入した場合、デコードステージ（Ｄ−ｓｔａｇｅ）のレジスタセット（Register Set）５１へのデータ書き込みが１サイクル遅れるため、その後のレジスタ値読み込みとの調整が必要である。
【００３７】
命令フェッチ要求との衝突によりロード要求が待たされ、ロードリクエストバッファ(ＵＣＬＢ)を用いて統合キャッシュメモリ２へのアクセスが行われた場合は、このライトバックステージ（Ｗ−ｓｔａｇｅ）へのパスを通ってロードデータが届く。命令フェッチ要求との衝突がなく、ＵＣＬＢを介さずに通常通りロード要求が実行された場合は、ロードデータはメモリステージ（Ｍ−ｓｔａｇｅ）へのパスを通って届く。
【００３８】
続いて、命令フェッチ要求とロード／ストア要求の調停における基本方針を説明する。基本方針として、以下の項目が挙げられる。
【００３９】
(1)複数存在する命令フェッチバッファによってフェッチレイテンシの隠蔽が可能な際は、ロード／ストア要求を優先する。
【００４０】
(2)命令フェッチバッファ内の有効命令コードが枯渇し、無効な命令がパイプラインに流れる可能性がある局面では命令フェッチ要求を優先する。
【００４１】
(3)実行ステージに達したロード／ストア要求がキャッシュミスを発生する事が既知であれば、ロード／ストア要求を優先する。
【００４２】
調停回路１の基本方針(3)において、キャッシュミスを伴うロード／ストア要求と命令フェッチ要求が衝突した際に（命令フェッチバッファ内の有効命令コードが枯渇時も）ロード／ストア要求を優先する理由を以下に説明する。
【００４３】
図４は、本実施の形態の手法によるキャッシュリフィル時のパイプライン動作を示す図である。図４は、命令フェッチバッファ内の有効命令コードが枯渇した状態で、キャッシュミスを伴うロード要求と命令フェッチ要求が衝突した際に、調停回路１がロード要求を採択した例を示す。説明を簡潔にするため、ここではロード後の命令（ｎ１〜ｎ５）をロード／ストア／分岐命令でないものと仮定する。
【００４４】
図４において、“サイクル（Ｃｙｃｌｅ）１”で命令フェッチ要求を待機させたため、“サイクル２”の命令フェッチステージ(Ｆ−Ｓｔａｇｅ)に無効な命令（バブル）Ｂが挿入されていることが確認できる。その後、“サイクル３”以降ではロード要求（Load）がメモリステージにおいて外部メモリ２０からのリフィル（Ｒｅｆｉｌｌ）待ちのために停滞する（ストール）。この間、統合キャッシュメモリ２に対するロード起因のメモリアクセスは発生しないため、後段のパイプラインと独立した命令フェッチステージは有効な命令コード（ｎ３）を読み出し、先の無効な命令（バブル）Ｂと有効な命令（ｎ３）を交換する（サイクル３）。
【００４５】
さらに、バスレイテンシによるリフィルデータ待ち状態の間に、命令フェッチステージは着々と統合キャッシュメモリ２から命令コード（ｎ４、ｎ５）を読み出し、命令フェッチバッファに格納する（サイクル４，５）。その後、外部バス３０からリフィルデータ（Refill Data）が返された際に統合キャッシュメモリ２にリフィルデータを書き戻し、（クリティカルワードファースト機構等を適用すれば）メモリステージ(Ｍ−Ｓｔａｇｅ)のロード要求(Load）はストール解除される（サイクル６）。その後は、命令フェッチバッファに格納された有効な命令コード（ｎ４、ｎ５）を元にパイプライン動作が再開される（サイクル７、８）。
【００４６】
上記に示した通り、リフィル動作の間に命令フェッチ動作を実現することで、パイプラインに無効な命令を流すことなく、リフィル後のパイプライン動作を実現することができる。仮に、“サイクル１”の段階で命令フェッチを優先させた場合、ロード要求のリフィル開始動作が１サイクル遅れるため、ロード要求の終了もサイクル７からサイクル８へと遅れることになる。
【００４７】
図５は、従来の手法と本実施の形態の手法のパイプライン効率の比較結果を示す図であり、（ａ）は従来の手法、（ｂ）は本実施の形態の手法を示す。図５中の“サイクル（Ｃｙｃｌｅ）１”では、既に命令フェッチバッファ中の有効命令が枯渇しているものとする。
【００４８】
従来手法では、図５の（ａ）に示すように、“サイクル１”において（後段のロードを待機させた場合ストールになる判断から）命令フェッチを待機させたため、“サイクル２”以降で無効な命令Ｂがパイプラインを流れている。ロード要求（Load）の３命令後に位置する「ｎ３」命令は、最終的に“サイクル７”で処理を終える。
【００４９】
一方本実施の形態のパイプラインでは、図５の（ｂ）に示すように、“サイクル１”で命令フェッチを採択し（ロードヒットと仮定）、ロード要求はＵＣＬＢに格納される。そのため、“サイクル２”では有効な命令がパイプラインに供給される。同時に（サイクル２では）ＵＣＬＢからロード要求を統合キャッシュメモリ２に発行し、データをライトバックステージ（Ｗ−ｓｔａｇｅ）で回収する。“サイクル１”の時点で当該ロード要求がヒットすることが既知であるため、ライトバックステージ以降に遅れることはない。
【００５０】
ロード命令の３命令後に位置する「ｎ３」命令は、最終的に“サイクル６”で処理を終える。命令フェッチバッファのビット長を１実行命令のビット長よりも長く設定すれば、“サイクル３”以降も直ぐには命令は枯渇しない。
【００５１】
図５の（ｂ）の“サイクル１”においては、命令フェッチとＥ−ｓｔａｇｅのロード命令が衝突し、命令フェッチが有効になったため、ＵＣＬＢにロード命令が待機するために格納される。その後、“サイクル２”においてロード要求がＵＣＬＢから統合キャッシュメモリ２に発行され、“サイクル３”において、Ｗ−ｓｔａｇｅのロード要求に対してロードデータが返る。
【００５２】
図５の（ｂ）の“サイクル２”において、さらに命令フェッチが発生した場合、Ｅ−ｓｔａｇｅの「ｎ１」命令がロード要求またはストア要求だった場合、統合キャッシュメモリ２へは、１．命令フェッチ、２．「ｎ１」命令がロード要求またはストア要求だった場合の要求、３．ＵＣＬＢ中のロード要求の３つの要求が発生する。
【００５３】
ここで、ＵＣＬＢのロード要求が実行されない場合、Ｍ−ｓｔａｇｅのロード要求は次のステージ（Ｗ−ｓｔａｇｅ）に移行してもロードデータが得られないためＭ−ｓｔａｇｅに留まり、パイプラインはストール(一時停止)する（Ｆ：ｎ３、Ｄ：ｎ２、Ｅ：ｎ１、Ｍ：Ｌｏａｄ、Ｗ：空白）。
【００５４】
その後、ＵＣＬＢ内のロード要求が実行され、次サイクルでロードデータが返る事が判断された段階で、Ｍ−ｓｔａｇｅのロード命令はＷ−ｓｔａｇｅに進み（サイクル３）、ロードデータを受け取り処理を完了する。
【００５５】
図６〜図９は、本実施の形態の手法において命令フェッチ要求、Ｅ−ｓｔａｇｅのロード／ストア要求、ＵＣＬＢ／ＵＣＳＢ要求の３つのアクセス要求が統合キャッシュメモリ２に向けられた際の調停方法を示す図である。なお、図６〜図９では、図５と同様にパイプラインを表記している。
【００５６】
上記の説明においては、始めにロード／ストアバッファ（ＵＣＬＢ／ＵＣＳＢ）１１が空の状態で、調停回路１が命令フェッチ要求、ロード／ストア要求を調停する方法を示した。以下では、ＵＣＬＢ／ＵＣＳＢ中に以前の調停により待機させられているロード/ストア要求が存在する場合の調停方法について説明する。
【００５７】
図６〜図９では、“サイクル１”において、命令フェッチ要求(Fetch Req)、Ｅ−ｓｔａｇｅのロード／ストア要求（Load/Store Req）、Ｅ−ｓｔａｇｅで要求を止められ、ＵＣＬＢ／ＵＣＳＢ中で待機しているロード／ストア要求(要求元のロード／ストア命令はパイプライン中のＭ−ｓｔａｇｅに存在する)の３者のアクセス要求が統合キャッシュメモリ２へ発生している状況を示している。なお、図中「−」は無効な命令(バブル)を示し、「ｎ２…ｎ５」はロード／ストア要求以外の命令群として表記している。
【００５８】
Ｅ−ｓｔａｇｅ／Ｍ−ｓｔａｇｅに存在するロード/ストア要求のＨｉｔ／Ｍｉｓｓの組み合わせは、以下に示すように２×２＝４通りのパターンが存在する。
【００５９】
Ｅ−ｓｔａｇｅ Ｍ−ｓｔａｇｅ
Ａ： Ｍｉｓｓ Ｍｉｓｓ
Ｂ： Ｍｉｓｓ Ｈｉｔ
Ｃ： Ｈｉｔ Ｍｉｓｓ
Ｄ： Ｈｉｔ Ｈｉｔ
パターンＡ，Ｂ，Ｃ，Ｄの何れの場合も、ＵＣＬＢ／ＵＣＳＢ内で待機中のロード/ストア要求からの統合キャッシュメモリ２へのアクセスを通さないと、パイプラインはストール(一時停止)する。よって「ＵＣＬＢ／ＵＣＳＢ中にロード／ストア要求が存在する場合はそれを最優先とする」ポリシーによって、３者のアクセス要求時の調停を行う。なお、図６〜図９において斜線を付けたアクセス要求は、調停の結果、統合キャッシュメモリ２へのアクセスが可能な事を示している。
【００６０】
図６の場合、load0(Miss)に続くload1(Miss)もキャッシュMissを引き起こし、外部バス３０を用いたリフィル（Refill）処理（図４の外部ＲＡＭ２０への処理と同様）を必要とするため、load0のリフィル処理が終わるまで、ＵＣＬＢで待機する。外部バス３０はload0のリフィル終了まで占有される想定であり、load0はリフィルデータが返ってくるまでは、パイプラインのＭ−ｓｔａｇｅに留まり、データの到着を待つ。つまり、ここでパイプラインのストールが発生する。パイプラインは、ロード／ストア要求がＭ−ｓｔａｇｅに存在し、次のステージ（Ｗ−ｓｔａｇｅ）に移行しても処理データが到達できないためにストールする。図６中の“サイクル（Ｃｙｃｌｅ）”の「Ｘ」は、リフィル処理の時間に依存する。
【００６１】
図７の場合、ＵＣＳＢに待機中のstore0(Hit)を処理した後にload1(Miss)の処理に移る。すなわち、Ｍ−ｓｔａｇｅのstore0(Hit)を採択し、パイプライン後段の処理を優先する。命令フェッチ要求(Fetch Req)がされないため、パイプラインに無効な命令(バブル)が流れるが、load1(Miss)の長いリフィル処理中に空いたサイクルを利用して命令フェッチをすることで、パイプライン中のバブルに有効な命令(図７ではｎ４やｎ５)を埋めることが可能になる。
【００６２】
図８の場合、ＵＣＬＢに待機中のload0(Miss)のリフィルの待ちサイクル中に総合キャッシュメモリ２自体が空くため、この空きサイクル２を利用して、load1(Hit)の処理を行う。ただし、load1(Hit)のアクセス先が、load0(Miss)のリフィル処理によってキャッシュの張替え中のラインを対象としている場合はアクセスができないため、待機状態となる(図６のload1(Miss)の待機に近い動作)。なお、load0(Miss)のリフィル処理によるラインでなければ、load1(Hit)は統合キャッシュメモリ２へアクセス可能である。
【００６３】
図９の場合、load0(Hit)もload1(Hit)も統合キャッシュメモリ２を１サイクル間占拠して処理を行うため、空きサイクルはなく、load0→load1→Fetch Reqの順に処理される。
【００６４】
以上のように本実施の形態によれば、パイプライン中の命令フェッチバッファの格納状況（エントリ情報）や、キャッシュメモリへのデータアクセス情報（ヒット／ミス情報）を考慮した上で、命令フェッチ側・データ処理側から統合キャッシュメモリに対して生ずるメモリアクセスを調停することで、パイプラインの有効命令処理率（パイプライン効率）の向上を図ることができる。
【００６５】
本発明は、上記実施の形態のみに限定されず、要旨を変更しない範囲で適宜変形して実施できる。例えば、本発明は上記実施の形態に限らず多用なパイプライン構成に適用できる。
【図面の簡単な説明】
【００６６】
【図１】統合キャッシュメモリを有する従来のプロセッサシステムのパイプライン動作を示す図。
【図２】実施の形態による統合キャッシュメモリを有するプロセッサシステムのパイプライン動作を示す図。
【図３】実施の形態のパイプラインの実装例を示す図。
【図４】実施の形態の手法によるキャッシュリフィル時のパイプライン動作を示す図。
【図５】従来の手法と本実施の形態の手法のパイプライン効率の比較結果を示す図であり、（ａ）は従来の手法、（ｂ）は本実施の形態の手法を示す図。
【図６】実施の形態の手法による３つのキャッシュメモリアクセス発生時のパイプライン動作を示す図。
【図７】実施の形態の手法による３つのキャッシュメモリアクセス発生時のパイプライン動作を示す図。
【図８】実施の形態の手法による３つのキャッシュメモリアクセス発生時のパイプライン動作を示す図。
【図９】実施の形態の手法による３つのキャッシュメモリアクセス発生時のパイプライン動作を示す図。
【符号の説明】
【００６７】
１…調停及びＵＣアクセスモジュール １１…ロード／ストアバッファ １２…ステートマシン ３，３１，３２…タグメモリ ４…命令フェッチモジュール ４１…命令フェッチバッファ ５…デコードモジュール ５１…レジスタセット ６…実行モジュール ７…パス対策レジスタ ２０…外部ＲＡＭ ３０…バス
【特許請求の範囲】
【請求項１】
パイプラインに、
キャッシュメモリと、
複数の命令を格納する命令フェッチバッファと、
前記キャッシュメモリに対するデータアクセスを要求する実行モジュールと、
前記実行モジュールのデータアクセスに係る情報を出力するタグメモリと、
前記命令フェッチバッファのエントリ情報と、前記タグメモリからのデータアクセスに係る情報とに基づき、前記キャッシュメモリに対するアクセスを調停する調停回路と、
を備えたことを特徴とするプロセッサシステム。
【請求項２】
前記データアクセスに係る情報は、ロード要求またはストア要求のヒット／ミス情報であることを特徴とする請求項１に記載のプロセッサシステム。
【請求項３】
前記調停回路は、ストアバッファを有し、命令フェッチ要求とストア要求の衝突時に、前記ストア要求を前記ヒット／ミス情報に関わらず前記ストアバッファに格納し、前記キャッシュメモリに対する他のアクセスがない期間で前記ストア要求を処理することを特徴とする請求項２に記載のプロセッサシステム。
【請求項４】
前記キャッシュメモリはデータ部が１入力１出力構成をとり、前記タグメモリは２入力２出力構成をとることを特徴とする請求項１乃至３のいずれかに記載のプロセッサシステム。
【請求項５】
前記調停回路は、命令フェッチ要求及び前記命令フェッチバッファ内のエントリ情報と、ロード要求またはストア要求と、ヒット／ミス情報とを基に遷移するステートマシンを有することを特徴とする請求項１乃至４のいずれかに記載のプロセッサシステム。
【請求項１】
パイプラインに、
キャッシュメモリと、
複数の命令を格納する命令フェッチバッファと、
前記キャッシュメモリに対するデータアクセスを要求する実行モジュールと、
前記実行モジュールのデータアクセスに係る情報を出力するタグメモリと、
前記命令フェッチバッファのエントリ情報と、前記タグメモリからのデータアクセスに係る情報とに基づき、前記キャッシュメモリに対するアクセスを調停する調停回路と、
を備えたことを特徴とするプロセッサシステム。
【請求項２】
前記データアクセスに係る情報は、ロード要求またはストア要求のヒット／ミス情報であることを特徴とする請求項１に記載のプロセッサシステム。
【請求項３】
前記調停回路は、ストアバッファを有し、命令フェッチ要求とストア要求の衝突時に、前記ストア要求を前記ヒット／ミス情報に関わらず前記ストアバッファに格納し、前記キャッシュメモリに対する他のアクセスがない期間で前記ストア要求を処理することを特徴とする請求項２に記載のプロセッサシステム。
【請求項４】
前記キャッシュメモリはデータ部が１入力１出力構成をとり、前記タグメモリは２入力２出力構成をとることを特徴とする請求項１乃至３のいずれかに記載のプロセッサシステム。
【請求項５】
前記調停回路は、命令フェッチ要求及び前記命令フェッチバッファ内のエントリ情報と、ロード要求またはストア要求と、ヒット／ミス情報とを基に遷移するステートマシンを有することを特徴とする請求項１乃至４のいずれかに記載のプロセッサシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２００８−１９８１２７（Ｐ２００８−１９８１２７Ａ）
【公開日】平成２０年８月２８日（２００８．８．２８）
【国際特許分類】
【出願番号】特願２００７−３５３５３（Ｐ２００７−３５３５３）
【出願日】平成１９年２月１５日（２００７．２．１５）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
【公開日】平成２０年８月２８日（２００８．８．２８）
【国際特許分類】
【出願日】平成１９年２月１５日（２００７．２．１５）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
[ Back to top ]