(57)【要約】【課題】トランザクションの調停を適切に処理して命令フェッチされた命令の枯渇等を抑制し、処理効率を向上させたデータ処理装置及びバス調停方法を提供すること。【解決手段】命令フェッチ及びデータアクセスの各トランザクションに伴う優先度情報に従い各トランザクションを調停してリソースへ接続する接続処理部３０と、を有するデータ処理装置１００において、命令フェッチされ第１のバッファ３１に記憶されている命令数を検出する第１の検出部２８と、第１のバッファに記憶されている命令数に応じて、命令フェッチのトランザクションに伴う優先度情報を変更する第１の優先度情報変更部３４と、第２のバッファに記憶されているデータの数を検出する第２の検出部と、データアクセスのトランザクションに伴う優先度情報を変更する第２の優先度情報変更部と、を有することを特徴とする。【選択図】図１
2010020599.tif 000002
【特許請求の範囲】
【請求項１】
命令をフェッチする命令フェッチ部と、データをリソースに格納するデータアクセス部と、命令フェッチ及びデータアクセスの各トランザクションに伴う優先度情報に従い各トランザクションを調停してリソースへ接続する接続処理部と、を有するデータ処理装置において、
命令フェッチされ第１のバッファに記憶されている命令数を検出する第１の検出部と、
第１のバッファに記憶されている命令数に応じて、命令フェッチのトランザクションに伴う前記優先度情報を変更する第１の優先度情報変更部と、
データをリソースに格納するまでの間、第２のバッファに記憶されているデータの数を検出する第２の検出部と、
第２のバッファに記憶されているデータ数に応じて、データアクセスのトランザクションに伴う前記優先度情報を変更する第２の優先度情報変更部と、
を有することを特徴とするデータ処理装置。
【請求項２】
第１のバッファに記憶されている命令数が所定の閾値Ａ未満の場合、
第１の優先度情報変更部は、命令フェッチのトランザクションの優先度が、データアクセスのトランザクションの優先度よりも高くなるよう、命令フェッチのトランザクションに伴う前記優先度情報を変更する、
ことを特徴とする請求項１記載のデータ処理装置。
【請求項３】
第２のバッファに記憶されているデータの数が所定の閾値C未満の場合、
第２の優先度情報変更部は、データアクセスのトランザクションの優先度が、命令フェッチのトランザクションの優先度よりも高くなるよう、データアクセスのトランザクションに伴う前記優先度情報を変更する、
ことを特徴とする請求項１記載のデータ処理装置。
【請求項４】
前記優先度情報は、
命令フェッチ部又はデータアクセス部を識別する識別情報のビット列の先頭に、
第１のバッファに記憶されている命令数が所定の閾値A未満であること、を示すビットと、
第２のバッファに記憶されているデータ数が所定の閾値C未満であること、を示すビットの、２つのビットを追加したビット列である、
ことを特徴とする請求項１〜３いずれか1項記載のデータ処理装置。
【請求項５】
命令フェッチのトランザクションの優先度が、データアクセスのトランザクションの優先度よりも高くなるように変更された前記優先度情報のトランザクションを、前記接続処理部が、連続して所定回数以上接続した場合、
トランザクションの調停論理を変更する調停論理変更部、
を有することを特徴とする請求項２記載のデータ処理装置。
【請求項６】
データアクセスのトランザクションの優先度が、命令フェッチのトランザクションの優先度よりも高くなるように変更された前記優先度情報のトランザクションを、前記接続処理部が、連続して所定回数以上接続した場合、
トランザクションの調停論理を変更する調停論理変更部、
を有することを特徴とする請求項３記載のデータ処理装置。
【請求項７】
変更前の調停論理は単純優先制御であり、変更後の調停論理は重み付きラウンドロビン方式制御である、
ことを特徴とする請求項５又は６記載のデータ処理装置。
【請求項８】
命令をフェッチする命令フェッチ部と、データをリソースに格納するデータアクセス部と、命令フェッチ及びデータアクセスの各トランザクションに伴う優先度情報に従い各トランザクションを調停してリソースへ接続する接続処理部と、を有するデータ処理装置のバス調停方法において、
第１の検出部が、命令フェッチされ第１のバッファに記憶されている命令数を検出するステップと、
第１の優先度情報変更部が、第１のバッファに記憶されている命令数に応じて、命令フェッチのトランザクションに伴う前記優先度情報を変更するステップと、
第２の検出部が、データをリソースに格納するまでの間、第２のバッファに記憶されているデータの数を検出するステップと、
第２の優先度情報変更部が、第２のバッファに記憶されているデータ数に応じて、データアクセスのトランザクションに伴う前記優先度情報を変更するステップと、
を有することを特徴とするバス調停方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、命令フェッチ、データアクセスのトランザクションを調停してそれぞれ並行に実行可能なデータ処理装置等に関し、特に、優先度に基づき複数のトランザクションを調停するデータ処理装置及びバス調停方法に関する。
【背景技術】
【０００２】
ＣＰＵの一般的な実行手順は、メモリに記憶されたプログラムが含む命令及びデータを順番にフェッチ（読み出し）して、デコード（解析、オペコードの取り出し）し、実行（命令に従った演算）し、ストア（メモリへの格納）する、という各ステップを経る。ここでメモリとＣＰＵはバスを介して接続されているが、ＣＰＵの性能の向上や複雑化、マルチＣＰＵ化等により、バスがボトルネックとなることがある。このため、バスの使用権を調停するバスアービタは、バスアクセスを要求するトランザクションと、予め定めた調停方法（例えば、固定優先度、変動優先度）に従い、優先的にバスを使用するトランザクションを決定する。しかしながら、かかる従来の調停方法では処理効率が低下する等の不都合が多く種々の技術が提案されている（例えば、特許文献１〜３参照。）。
【０００３】
特許文献１には、トランザクションをキューイングした順番にメモリアクセスを許可するメモリアクセス制御回路において、待ち時間に応じて処理効率に影響を与えるとトランザクションがキューイングされたことを検出して、該トランザクションに優先的にメモリアクセスを許可する技術が記載されている。これにより、待ち時間に応じて処理に影響を与えるトランザクションがキューイングされても全体の処理効率の低下を防止しうるとしている。
【０００４】
また、特許文献２には、キャッシュメモリを書き換える変更トランザクションは、書き換えない非変更トランザクションよりも頻繁にメモリにアクセスするという前提の下、変更トランザクションを非変更トランザクションよりも優先してメモリへのアクセスを許可するトランザクション・スケジューリング方法が記載されている。
【０００５】
しかしながら、トランザクションは命令の実行状況、周辺機器の状態等に応じて優先度が変化するものであるため、特許文献１及び２のように、各トランザクションの優先度を予め定めておくと処理効率が低下する場合がある。
【０００６】
また、特許文献３には、トランザクションを抱える複数の処理部のデータ処理状況、具体的にはパイプラインで実行中の各ステージを処理する処理部の状態をフラグで判定し、待ち状態になる可能性が低い処理部のトランザクションに対しバスアクセスを許可するデータ処理装置が記載されている。これにより、パイプライン全体の処理効率を損ねることなくメモリに対するアクセス要求を調停することができるとしている。
【０００７】
しかしながら、特許文献３記載のデータ処理装置のようにパイプラインを採用したシステムでは、パイプライン処理に伴う種々のハザード要因（処理依存性、分岐制御等）の影響を受けるため、処理部の判定結果が適切とは限らない。
【０００８】
図９は、従来のプロセッサ１０００におけるブロック図の一例を示す。近年のプロセッサでは、ＣＰＵコア２００とバスとのインターフェイス部を分離したハーバードアーキテクチャが採用されることがある。
【０００９】
プロセッサの高機能化・態様化に伴いプロセッサのＩ／Ｏ５００の数が増加し、これによりバストポロジの複雑化だけでなく、プロトコル（マルチレイヤバスやパケットベースバス）も複雑化してきている。図示するインターコネクト部３００は、ＣＰＵコア２００とメモリ４００及び複数のI／O５００を多対多で接続する。
【００１０】
プロセッサ１０００は、命令実行をいくつかのステージに分け同時並行に各ステージを実行するパイプライン型の実行制御を実装している。また、この実行制御による高速化を更に活かすため、ＣＰＵコア２００はプリフェッチ機能や分岐予測機能を実装しており、フェッチされた命令が枯渇しないような制御を備える（ストールの抑制）。
【００１１】
このため、インターコネクト部３００は、命令をフェッチするフェッチ部２０２よりも、データをロード又はストアするロードストア部２０３のトランザクションを優先する、調停方法（バス調停ロジック）を採用した方が処理効率が高いと考えられている。
【特許文献１】特開２００６−１８５１９８号公報
【特許文献２】特開２０００−２３１５３６号公報
【特許文献３】特開２００６−６５４５３号公報
【発明の開示】
【発明が解決しようとする課題】
【００１２】
しかしながら、パイプライン処理を採用した場合、よく知られているように分岐予測を常に１００％とすることは困難であるため、命令実行の分岐処理によりパイプラインがフラッシュされる（空にされた場合）ことがある。フラッシュされると、分岐先の新たな番地から命令をフェッチして、パイプラインの各ステージに命令を詰め込む作業を再開するため、処理効率が大きく低下する。すなわち、フラッシュすると命令が枯渇するおそれがある。
【００１３】
また、制御系や処理時間コミット系（ある決められた時間以内に処理することが保証された処理）を採用したシステムでは、分岐予測の成否やプリフェッチした命令のヒット率のような不確定要素を排除するため、そもそも分岐予測やプリフェッチ機能を採用しない場合もある。この場合、命令が分岐するとすぐに命令が枯渇する。
【００１４】
したがって、ロードストア部２０３のトランザクションを、フェッチ部２０２よりも単に優先するだけでは、プロセッサ１０００の処理効率が低下するおそれが生じるという問題がある。
【００１５】
本発明は、上記課題に鑑み、トランザクションの調停を適切に処理してフェッチされた命令の枯渇等を抑制し、処理効率を向上させたデータ処理装置及びバス調停方法を提供することを目的とする。
【課題を解決するための手段】
【００１６】
上記課題に鑑み、本発明は、命令をフェッチする命令フェッチ部（例えば、フェッチ部２１）と、データをリソースに格納するデータアクセス部（例えば、ロードストア部２６）と、命令フェッチ及びデータアクセスの各トランザクションに伴う優先度情報（例えば、トランザクションＩＤ）に従い各トランザクションを調停してリソースへ接続する接続処理部（例えば、インターコネクト部３０）と、を有するデータ処理装置において、命令フェッチされ第１のバッファ（例えば、プリフェッチバッファ３１）に記憶されている命令数を検出する第１の検出部（例えば、命令数検出部２８）と、第１のバッファに記憶されている命令数に応じて、命令フェッチのトランザクションに伴う優先度情報を変更する第１の優先度情報変更部（例えば、ＩサイドＩ／Ｆ３４）と、データをリソースに格納するまでの間、第２のバッファ（例えば、ストアバッファ３３）に記憶されているデータの数を検出する第２の検出部（例えば、データ数検出部２９）と、第２のバッファに記憶されているデータ数に応じて、データアクセスのトランザクションに伴う優先度情報を変更する第２の優先度情報変更部（例えば、Ｄ再度Ｉ／Ｆ３５）と、を有することを特徴とする。
【００１７】
本発明によれば、第１のバッファに記憶されている命令数が少なくなると、命令フェッチのトランザクションに伴う優先度を高くできるので、命令の枯渇を抑制できる。特に、パイプライン制御の処理効率の低下を抑制できる。
【発明の効果】
【００１８】
トランザクションの調停を適切に処理してフェッチされた命令の枯渇等を抑制し、処理効率を向上させたデータ処理装置及びバス調停方法を提供することができる。
【発明を実施するための最良の形態】
【００１９】
以下、本発明を実施するための最良の形態について図面を参照しながら説明する。
【００２０】
図１は、データ処理装置１００によるバス調停方法の概略を説明する図である。データ処理装置１００は、予めＣＰＵコアに命令フェッチした命令を記憶しておくプリフェッチバッファ３１、予めＣＰＵコアに読み出したデータを記憶しておくロードバッファ３２、及び、メモリにストアするデータを記憶しておくストアバッファ３３を有する。
【００２１】
データ処理装置１００は、ＣＰＵコアのバスアクセスをトランザクション毎に調停しており、トランザクションにはその優先度を定めるトランザクションＩＤがトランザクションと一体又は対応づけて付与されている。したがって、トランザクションＩＤを調整すれば、命令フェッチのトランザクションとロード／ストアのトランザクションの優先度を可変とすることができる。
【００２２】
本実施形態のデータ処理装置１００は、プリフェッチバッファ３１に記憶された命令の命令数が少なくなると、命令フェッチのトランザクションの優先度を上げ（トランザクションＩＤを大きくする）、データバッファに記憶されたデータＬｎ（ｎ：自然数。以下、単にデータＬという）のデータ数又はストアバッファ３３に記憶されたデータＳｎ（ｎ：自然数。以下、単にデータＳという）のデータ数が多くなると、データＬのロードのトランザクション又はデータＳのストアのトランザクションの優先度を上げる（トランザクションＩＤを大きくする）。
【００２３】
したがって、プリフェッチバッファ３１に記憶された命令数が少なくなれば、優先的に命令フェッチできるので、例えばパイプラインがフラッシュされても、多くの場合はプリフェッチバッファ３１から読み出すことができ、処理効率の低下を最小限に抑制できる。また、ロードバッファ３２、又は、ストアバッファ３３に記憶されたデータの数が多い場合には、優先的にストアすることができるので、ロードバッファ３２又はストアバッファ３３にデータが滞るといったことを防止できる（キャッシュコヒーレンシの防止）。
【００２４】
図２は、データ処理装置１００の機能ブロック図の一例を示す。データ処理装置１００は、プロセッサをワンチップに集積した半導体装置であって、主に組み込み機器の制御やデータ加工に用いられるマイクロコントローラである。データ処理装置１００は、ＣＰＵコア２０、インターコネクト部３０、ＲＯＭ４０、ＲＡＭ５０、Ｉ／Ｏブリッジ６０、Ｉ／Ｏ７０及びバス８０を有する。ＣＰＵコア２０は、命令フェッチ、デコード、実行、ライトバックを繰り返し、インターコネクト部３０は命令フェッチ、データのロード／ストアに伴う、ＲＯＭ４０，ＲＡＭ５０及びＩ／Ｏブリッジ６０（以下、リソースという）へのＣＰＵコア２０のアクセスを調停する。また、ＲＯＭ４０はプログラムやパラメータを記憶し、ＲＡＭ５０はプログラムを実行する際の作業メモリとなる。Ｉ／Ｏブリッジ６０は、種々のＩ／Ｏ７０（外部機器との入出力インターフェイス、内部のＡＳＩＣ等とのインターフェイス、スイッチ素子等）とバス８０を介して接続されており、これらＩ／Ｏ７０に対する通信（データ）を中継する。
【００２５】
なお、図２ではＣＰＵコア２０を１つのみ記載したが、２以上のＣＰＵコア２０をインターコネクト部３０に接続してもよい。この場合、インターコネクト部３０の後述するコントローラ４４を、ＣＰＵコア２０の数に応じて設ければよい。
【００２６】
〔ＣＰＵコア２０〕
ＣＰＵコア２０は、パイプライン機能を実装しており１クロックで、フェッチ部２１、デコード部２２、レジスタフェッチ部２３、ＡＬＵ（Arithmetic  and  Logic  Unit）２４、及び、ライトバック部２５が、それぞれのステージに定められた処理を実行する。
【００２７】
フェッチ部２１は、プログラムカウンタが示すアドレスの命令をプリフェッチバッファ３１から読み出す。デコード部２２は、読み出された命令からオペランドとオペコードを取り出し、オペコードのビット列に応じて予め定められている演算（加算、減算、シフト、ジャンプ等）を決定する。レジスタフェッチ部２３は、演算がレジスタに格納されているデータを必要とする場合にそのレジスタからデータを読み出す。ＡＬＵ２４は、レジスタから読み出したデータやオペランドが示すデータバッファに記憶されたアドレスのデータに、オペコードに従って四則演算や論理演算など算術的な演算を施す。そして、ライトバック部２５は、演算結果をレジスタ又は必要であればロードスストア部２６のストアバッファ３３に書き込む。
【００２８】
フェッチ部２１等は、１つの命令の実行が終了する前に、次の命令に対し定められたステージの処理を１クロック毎に実行するので、１クロック毎に１つの命令の実行結果が得られるようになる。なお、図２の機能ブロックはパイプラインのステージ数（段数）と一致するものではなく、ステージ数は例えば５〜３０等でもよく、本実施形態のデータ処理装置１００において制約はない。また、各ステージで複数の命令を同時に処理するスーパースケーラを採用してもよい。
【００２９】
＜トランザクション＞
トランザクションについて説明する。本実施形態においてトランザクションは、比較的広い意味で用いられており、１つは、ＣＰＵコア２０がリソースにアクセスするという動作又はその要求をいい、もう１つは、その動作に伴うデータ（以下、区別するためパケットという）をいう。トランザクションは、Ｉ（Instruction）サイドＩ／Ｆ３４によるトランザクションＩと、Ｄ（Ｄａｔａ）サイドＩ／Ｆ３５によるトランザクションＤとがある。トランザクションＩとトランザクションＤは、便宜的に称呼を区別しただけであって、フォーマットは共通である。
【００３０】
トランザクションＩは、命令フェッチにかかるアクセスなので、トランザクションＩのパケットには命令のアドレス等が格納される。また、トランザクションＤは、データの読み込み（ロード）及び書き込み（ストア）にかかるアクセスなので、トランザクションＤのパケットには読み込まれるデータ（インターコネクト部３０からロードストア部２６へ）又は書き込むためのデータ（ロードストア部２６からインターコネクト部３０へ）が格納される。
【００３１】
＜トランザクションＩＤ＞
そして、トランザクションＩ及びＤには図１で説明したトランザクションＩＤが付与される。図３は、トランザクションＩＤの一例を示す図である。トランザクションＩＤの全長（ビット数）は予め定められており、２つの識別情報と２つのアラームビットから構成されている。このうち、識別情報の一方はSource-IDであって、トランザクションを発行した例えばＩサイドＩ／Ｆ３４又はＤサイドＩ／Ｆ３５を識別する番号が格納される。また、識別情報の他方はDestination-IDであって、トランザクションの要求先となるリソースのＲＯＭ４０，ＲＡＭ５０又はＩ／Ｏブリッジ６０を識別する番号が格納される。
【００３２】
そして、トランザクションＩ及びＤの優先度は、トランザクションＩＤを数値に変換してその数値に応じて（例えば、数値の大きい方又は小さい方）判定される。
【００３３】
従来であれば、これら２つの識別情報のみにより、インターコネクト部３０はそのトランザクションの優先度を判別していた。分岐予測機能やプリフェッチ機能を採用している本実施形態のデータ処理装置１００の場合、命令フェッチされた命令が枯渇する可能性がそれほど大きくない。このため、トランザクションＤがトランザクションＩよりも優先されるよう、ＤサイドＩ／Ｆ３５を識別する番号は、ＩサイドＩ／Ｆ３４を識別する番号よりも大きいとする（数値の大きい方が優先の場合。数値の小さい方が優先の場合は逆になる。）。
【００３４】
これに加え、本実施形態のデータ処理装置１００は、２つのアラームビットを追加して、ＣＰＵコア２０の状態に応じてトランザクションＩ又はＤの優先度を可変とする。
【００３５】
具体的には、トランザクションＩＤのＭＳＢ（Most  Significant  Bit）をＤサイドＩ／Ｆ３５使用するビットとし、ＭＳＢから２番目のビットがＩサイドＩ／Ｆ３４が使用するビットとする（以下、それぞれを、第１ビットと第２ビットという）。
【００３６】
２つのアラームビットの常態はいずれも「０」である。そして、トランザクションＩの優先度を上げたい場合、ＩサイドＩ／Ｆ３４は第２ビットに「１」を設定し、トランザクションＤの優先度を上げたい場合、ＤサイドＩ／Ｆ３５は第１ビットに「１」を設定する。したがって、２つのアラームビットは「００」「０１」「１０」のいずれかの状態を取る。
【００３７】
このため、トランザクションＩＤを数値に変換し、数値が大きいほど優先度が高いと判定する場合、「第１ビットが「１」のトランザクションＤ＞第２ビットが「１」のトランザクションＩ  ＞  常態のトランザクションＤ＞常態のトランザクションＩ」のように、優先度を規定することができる。すなわち、第１ビットをＤサイドＩ／Ｆ３５が使用するビットとしたので、アラームビットで拡張しても常態と同様にトランザクションＤをトランザクションＩよりも優先することができる。
【００３８】
なお、図１では、トランザクションＩＤをトランザクションのパケットよりも上位ビットに設けているが、トランザクションＩＤをトランザクションのパケットよりも下位ビットに設けてもよい。また、図３では、アラームビットをトランザクションＩＤの上位２ビットに設けたが、アラームビットはトランザクションＩＤの下位２ビットに設けてもよい。この場合、トランザクションＩＤの下位２ビットのいずれかに「１」があれば、「１」のあるビットに応じて優先度を判定すればよく、ない場合にはトランザクションＩＤの数値の大きさにより判定すればよい。
【００３９】
＜アラームの通知及び解除＞
フェッチ部２１及びロードストア部２６は、トランザクションＩＤ生成部２７にアラームを通知し、また、アラームの解除を通知する（以下、単に「解除する」という）。このアラームの通知又は解除に従い、トランザクションＩＤ生成部２７がアラームビットに「１」を設定する。アラームの通知又は解除は、例えば所定の信号線のＨｉ／Ｌｏｗを切り替えてもよいし、トランザクションに含めてもよい。
・フェッチ部２１によるアラームの通知及び解除
アラームビットの通知又は解除手順について説明する。上述したようにプリフェッチバッファ３１には命令フェッチされた命令が格納される。フェッチ部２１の命令数検出部２８はプリフェッチバッファ３１に記憶されている命令数を検出し、フェッチ部２１は、命令数が閾値Ａよりも少なくなった場合にＩサイドＩ／Ｆ３４にアラームを通知する。
【００４０】
なお、いったん通知したアラームを解除しないと、プリフェッチバッファ３１に記憶された命令数が十分になっても第２ビットが「１」のままになってしまうので、フェッチ部２１は格納されている命令数が閾値Ｂ（＞閾値Ａ）よりも大きくなった場合に、アラーム解除を通知する。
【００４１】
図４は、フェッチ部２１がアラームを通知又は解除する手順を示すフローチャート図の一例である。図４のフローチャート図は、例えばプリフェッチバッファ３１から命令を読み出される毎に実行される。なお、図４の処理による処理負荷の増大を抑制するため、ＣＰＵコア２０の１クロックで図４の全ステップを実行できることが好ましい。
【００４２】
まず、フェッチ部２１は、アラームを通知した状態か、解除した状態かを判定する（Ｓ１０）。フェッチ部２１は例えばフラグ（フリップフロップ）によりアラームを通知したか解除したかを記憶している。
【００４３】
アラームを通知していない場合（Ｓ１０のＹｅｓ）、フェッチ部２１は閾値Ａと命令数検出部２８が検出した命令数を比較して、命令数が閾値Aよりも少ないか否かを判定する（Ｓ２０）。
【００４４】
命令数が閾値Aよりも少ない場合（Ｓ２０のＹｅｓ）、フェッチ部２１はＩサイドＩ／Ｆ３４にアラームを通知する（Ｓ３０）。命令数が閾値Aよりも少なくない場合（Ｓ２０のＮｏ）、フェッチ部２１はアラームを通知せず処理を終了する。
【００４５】
ステップＳ１０に戻り、アラームを通知した状態の場合（Ｓ１０のＮｏ）、フェッチ部２１は閾値Bと命令数検出部２８が検出した命令数を比較して、命令数が閾値Ｂよりも多いか否かを判定する（Ｓ４０）。
【００４６】
命令数が閾値Ｂよりも多い場合（Ｓ４０のＹｅｓ）、フェッチ部２１はＩサイドＩ／Ｆ３４にアラームの解除を通知する（Ｓ５０）。命令数が閾値Ｂよりも多くない場合（Ｓ４０のＮｏ）、フェッチ部２１はアラームを解除せず処理を終了する。
【００４７】
図４では、閾値Ａ＜閾値Ｂなので、アラームを通知した後はプリフェッチバッファ３１に記憶されている命令数が閾値Ａ以上となっても閾値Ｂ以上となるまでアラームは解除されない、というヒステレシス条件が採用されている。これにより、頻繁なアラームの通知を回避している。
・ロードストア部２６によるアラームの通知及び解除
ロードストア部２６のデータ数検出部２９はロードバッファ３２及びストアバッファ３３に記憶されているデータの数を検出し、ロードストア部２６は、それらの数が閾値Cよりも多くなった場合にDサイドＩ／Ｆ３５にアラームを通知する。
【００４８】
なお、いったん通知したアラームを解除しないと、データＬ及びデータＳの数が少なくなっても第１ビットが「１」のままになってしまうので、ロードストア部２６は格納されているデータ数が閾値Ｄ（＜閾値Ｃ）よりも少なくなった場合に、アラーム解除を通知する。フェッチ部２１と同様にヒステレシス条件を採用している。
【００４９】
閾値Ｃ、Ｄと比較されるデータＬの数及びデータＳの数について説明する。ロードバッファ３２にロードされたデータＬはこれから演算に使用されるデータである。したがって、データＬの数はプリフェッチバッファ３１に記憶された命令と同じ増減傾向を示すか、又は、ロードバッファ３２をキャッシュメモリと兼用する場合には一定である。これに対し、ストアバッファ３３に記憶されたデータＳは演算結果のデータであるので、プリフェッチバッファ３１に記憶された命令と逆の増減傾向を示す場合が多い。
【００５０】
したがって、データＬの数よりも、ストアバッファ３３に記憶されたデータＳの数が多くなった場合、キャッシュコヒーレンシを抑制する観点から、トランザクションＤを優先すべきと考えられる。
【００５１】
以上から、データ数検出部２９が検出する閾値Ｃ又はＤと比較されるデータＬ及びデータＳの数は、好ましくはデータＳの数であり、又は、データＬの数とデータＳの数を加算した数である。
【００５２】
図５は、ロードストア部２６がアラームを通知又は解除する手順を示すフローチャート図の一例である。図５のフローチャート図は、例えばロードバッファ３２又はストアバッファ３３に新たにデータＬ又はデータＳが蓄積される毎に実行される。図４と同様に、ＣＰＵコア２０の１クロックで図５の全ステップを実行できることが好ましい。
【００５３】
まず、ロードストア部２６は、アラームを通知した状態か、解除した状態かを判定する（Ｓ１０）。ロードストア部２６は例えばフラグ（フリップフロップ）によりアラームを通知したか解除したかを記憶している。
【００５４】
アラームを通知していない場合（Ｓ１０のＹｅｓ）、ロードストア部２６は、データ数検出部２９が検出したデータＬの数とデータＳの数を加算したデータ数（以下、データ数という）と、閾値Ｃとを比較して、データ数が閾値Ｃよりも多いか否かを判定する（Ｓ２１）。
【００５５】
データ数が閾値Ｃよりも多い場合（Ｓ２１のＹｅｓ）、ロードストア部２６はＤサイドＩ／Ｆ３５にアラームを通知する（Ｓ３０）。データ数が閾値Ｃよりも多くない場合（Ｓ２１のＮｏ）、ロードストア部２６はアラームを通知せず処理を終了する。
【００５６】
ステップＳ１０に戻り、アラームを通知している場合（Ｓ１０のＮｏ）、ロードストア部２６は閾値Ｄとデータ数と、を比較して、データ数が閾値Ｄよりも少ないか否かを判定する（Ｓ４１）。
【００５７】
データ数が閾値Ｄよりも少ない場合（Ｓ４１のＹｅｓ）、ロードストア部２６はＤサイドＩ／Ｆ３５にアラームの解除を通知する（Ｓ５０）。データ数が閾値Ｄよりも少なくない場合（Ｓ４１のＮｏ）、ロードストア部２６はアラームを解除せず処理を終了する。
【００５８】
以上のようして、トランザクションＩＤ生成部２７にアラームを通知し、また解除することができる。
【００５９】
＜トランザクションＩＤの生成＞
トランザクションＩＤ生成部２７のＩサイドＩ／Ｆ３４は、フェッチ部２１から送信されたトランザクションＩのパケットにトランザクションＩＤを付与し、ＤサイドＩ／Ｆ３５は、ロードストア部２６から送信されたトランザクションＤのパケットにトランザクションＩＤを付与する。
【００６０】
トランザクションＩＤ生成部２７は、Source-IDに、トランザクションを要求したフェッチ部２１又はロードストア部２６の識別情報を格納し、Destination-IDに、フェッチ部２１又はロードストア部２６の要求に従いリソースの識別情報を格納する。
【００６１】
そして、IサイドＩ／Ｆ３４は、フェッチ部２１のアラームの通知又は解除に応じて、トランザクションＩＤの第２ビットに「１」又は「０」を設定し、ＤサイドＩ／Ｆ３５は、ロードストア部２６のアラームの通知又は解除に応じて、トランザクションＩＤの第１ビットに「１」又は「０」を設定する。
【００６２】
〔インターコネクト部３０〕
図６は、インターコネクト部３０の概略構成図の一例を示す。インターコネクト部３０は、ＩサイドＩ／Ｆ３４からリソースへのトランザクションＩ、ＤサイドＩ／Ｆ３５からリソースへのトランザクションＤを、それぞれ時間的に並行に処理するマルチレイヤ処理を実装している。
【００６３】
インターコネクト部３０は、バスサイクル毎に調停の必要の有無を判定し、必要がなければ複数（この場合は２つ）のトランザクションＩとトランザクションＤを並行に処理し、必要があれば優先度を判定してそれらを調停する。
【００６４】
調停には、例えばバスサイクルの当初にリクエスト信号（トランザクションＩＤを含む）が使用される。トランザクションＩがＲＡＭ５０へのアクセスで、トランザクションＤがＩ／Ｏブリッジ６０へのアクセスの場合、２つのトランザクションに調停の必要はない。この場合、コントローラ４４ｂは、コントローラ４１ａからリクエスト信号を受信するがコントローラ４１ｂからはリクエスト信号を受信しない。このため、コントローラ４１ａとコントローラ４４ｂは、ノード４２ａ及びノード４３ｂを結ぶバスを占有し、１以上のバスサイクルで、トランザクションＩ（パケット）を送信する。また、時間的に並行して、コントローラ４１ｂはコントローラ４４ｃにトランザクションＤ（パケット）を送信する。
【００６５】
また、例えば、トランザクションＩとトランザクションＤが共にＲＡＭ５０へのアクセスの場合、インターコネクト部３０は２つのトランザクションＩとトランザクションＤを調停する。この場合、コントローラ４４ｂは２つのリクエスト信号を受信するので、２つのトランザクションＩＤのうち大きい方に送信権を与える。例えばトランザクションＤの方がトランザクションＩＤが大きい場合、１回目のバスサイクルでトランザクションＤ（パケット）が送信され、次のバスサイクルでトランザクションＩ（パケット）が送信されることになる。
【００６６】
〔調停論理の制御〕
これまでは、調停論理をトランザクションＩＤの大小による単純優先制御としたが、かかる調停論理では、優先度の高いトランザクションが連続する間は優先度が低いトランザクションは処理されないという不都合がある。
【００６７】
調停論理としてラウンドロビン（以下、ＲＲという）があるが、ＲＲは全てのトランザクションＩ及びＤに順番に送信権を認める調停論理であるので、トランザクションの優先度を考慮できなくなってしまう。
【００６８】
これに対し、ＲＲを拡張したＷＲＲ（Weighted  Round  Robin）では、予め定められた重み付けにしたがって、トランザクションＩ及びトランザクションＤに対して送信権を認めることができる。例えば、重み付けを１対２とした場合は優先度の高い方に２回送信権を与えると優先度の低い方に１回だけ送信権を与えることができる。
【００６９】
ＷＲＲを採用した場合、コントローラ４４ａ〜４４ｃ（以下、区別しない場合、コントローラ４４という）は偏りを検出するためのカウンタを備える。ここで、カウンタする対象として２つ考えられる。対象の１つは、トランザクションＩ及びトランザクションＤであって、もう１つは第１ビット及び第２ビットである。
【００７０】
どちらをカウントしても、送信するトランザクションＩ又はＤが偏ったことを検出できるが、本実施形態の場合、アラームビットにより送信が偏ったことを検出することで、アラームビットの数をカウントして調停論理を変更することで、アラームビットを付与すること対するフェールセーフとすることができる。
【００７１】
すなわち、上述したアラームビットが付与されたトランザクションＩＤの作用を最大にする場合には単純優先制御とすることが好ましいが、アラームビットに「１」を含むトランザクションＩＤが連続すると、単純優先制御のデメリットが露呈する。このため、トランザクションＩＤのアラームビットを監視して、これが連続した場合にＷＲＲに切り替えることで、アラームビットが付与されたトランザクションＩＤの作用を活かしながら、優先度が低いトランザクションの処理も可能とすることができる。
【００７２】
インターコネクト部３０は、かかる考え方に基づき第１ビット又は第２ビットが所定数以上連続した場合に、調停論理を単純優先制御からＷＲＲに切り替える。ここで、アラームビットではあっても第１ビットと第２ビットが交互に連続した場合は、一方のトランザクションＩ又はＤだけが送信されていないので、調停論理を切り替える必要はない。したがって、例えば、第１ビットがｍ回連続した場合、第２ビットがｎ回連続した場合に、インターコネクト部３０は調停論理を切り替える。ｍとｎは、ｍ＞ｎ、ｎ＜ｍ、ｍ＝ｎのいずれの組み合わせでもよい。
【００７３】
図７は、インターコネクト部３０が第１ビット及び第２ビットがそれぞれｍ回又はｎ回連続したか否かを判定する手順を、図８は調停論理の切り替え手順を、それぞれフローチャート図の一例である。
【００７４】
コントローラ４４は、送信したトランザクションのトランザクションＩＤを参照して第１ビットが「１」か否かを判定する（Ｓ１１０）。
【００７５】
第１ビットが「１」の場合（Ｓ１１０のＹｅｓ）、第２ビットが連続して「１」でないことになるので（第１ビットと第２ビットは同時に「１」にならない）、コントローラ４４は第２ビットのカウンタをリセットする（Ｓ１２０）。そして、第１ビットのカウンタをインクリメントする（Ｓ１３０）。
【００７６】
ついで、コントローラ４４は、第１ビットのカウンタがｍ以上になったか否かを判定する（Ｓ１４０）。第１ビットのカウンタがｍ以上でなければ（Ｓ１４０のＮｏ）、そのまま処理を終了する。
【００７７】
第１ビットのカウンタがｍ以上の場合（Ｓ１４０のＹｅｓ）、コントローラ４４は、エラーフラグをセットする（Ｓ１５０）。
【００７８】
ステップＳ１１０に戻り、第１ビットが「１」でない場合（Ｓ１１０のＮｏ）、コントローラ４４は第２ビットが「１」か否かを判定する（Ｓ１６０）。第２ビットが「１」の場合（Ｓ１６０のＹｅｓ）、第１ビットが連続して「１」でないことになるので、コントローラ４４は第１ビットのカウンタをリセットする（Ｓ１７０）。そして、第２ビットのカウンタをインクリメントする（Ｓ１８０）。
【００７９】
ついで、コントローラ４４は、第２ビットのカウンタがｎ以上になったか否かを判定する（Ｓ１９０）。第２ビットのカウンタがｎ以上でなければ（Ｓ１９０のＮｏ）、そのまま処理を終了する。
【００８０】
第２ビットのカウンタがｎ以上の場合（Ｓ１９０のＹｅｓ）、コントローラ４４は、エラーフラグをセットする（Ｓ２００）。
【００８１】
かかる手順により、アラームビットによりトランザクションＩをｎ回、トランザクションＤをｍ回、それぞれ連続して送信したことを検出できる。
【００８２】
そして、コントローラ４４は、エラーフラグを参照して調停論理を切り替える。コントローラ４４は、例えばバスサイクル毎にエラーフラグがセットされているか否かを判定する（Ｓ２１０）。
【００８３】
エラーフラグがセットされていなければ（Ｓ２１０のＹｅｓ）、コントローラ４４は単純優先制御を調停論理に採用し（Ｓ２２０）、エラーフラグがセットされている場合（Ｓ２１０のＮｏ）、コントローラ４４はＷＲＲを調停論理に採用する（Ｓ２３０）。
【００８４】
例えば、１対３の重み付けの下、ＷＲＲを採用した場合、第１ビット及び第２ビットに応じて、次のようにトランザクションＩとＤを調停する。
・第１ビットがｍ回連続した場合（トランザクションＤが優先的だった場合）
トランザクションＤを３回送信したら、トランザクションＩを１回送信する。
・第２ビットがｎ回連続した場合（トランザクションＩが優先的だった場合）
トランザクションＩを３回送信したら、トランザクションＤを１回送信する。
【００８５】
したがって、アラームビット（第１ビット、第２ビット）の連続数に応じて、調停論理を切り替えることで、アラームビットに従い一方のトランザクションを優先的に送信しながら、非優先的なトランザクションの送信も確保できる。すなわち、アラームビットにより送信するトランザクションが偏っても、フェールセーブ機構を作動させることができるようになる。
【００８６】
以上説明したように、本実施形態のデータ処理装置１００は、プリフェッチバッファ３１に記憶された命令数が少なくなると、命令フェッチのトランザクションの優先度を上げることで、命令の枯渇を回避することができる。
【００８７】
また、かかる優先度の調整により通信するトランザクションＩ又はＤが偏った場合には、調停論理を変更するので、非優先的なトランザクションの送信を確保することができる。
【図面の簡単な説明】
【００８８】
【図１】データ処理装置によるバス調停方法の概略を説明する図である。
【図２】データ処理装置の機能ブロック図の一例である。
【図３】トランザクションＩＤの一例を示す図である。
【図４】フェッチ部がアラームを通知又は解除する手順を示すフローチャート図の一例である。
【図５】ロードストア部がアラームを通知又は解除する手順を示すフローチャート図の一例である。
【図６】インターコネクト部の概略構成図の一例である。
【図７】インターコネクト部が、第１ビット及び第２ビットがそれぞれｍ回又はｎ回連続したか否かを判定する手順を示すフローチャート図の一例である。
【図８】調停論理の切り替え手順を示すフローチャート図の一例である。
【図９】従来のプロセッサにおけるブロック図の一例である。
【符号の説明】
【００８９】
２０      ＣＰＵコア
２１      フェッチ部
２６      ロードストア部
２７      トランザクションＩＤ生成部
３０      インターコネクト部
３１      プリフェッチバッファ
３２      ロードバッファ
３３      ストアバッファ
３４      ＩサイドＩ／Ｆ
３５      ＤサイドＩ／Ｆ
１００    データ処理装置
【図１】
2010020599.tif 000003
【図２】
2010020599.tif 000004
【図３】
2010020599.tif 000005
【図４】
2010020599.tif 000006
【図５】
2010020599.tif 000007
【図６】
2010020599.tif 000008
【図７】
2010020599.tif 000009
【図８】
2010020599.tif 000010
【図９】
2010020599.tif 000011