(57)【要約】【課題】リコンフィグ可能な電子デバイスリソースを適切に管理する。【解決手段】実施形態によれば、管理装置は、管理部を含む。管理部は、リコンフィグ可能なリソースに第１の期間において実装されている回路モジュール群のそれぞれの回路モジュールの稼働状況の履歴に基づいて、当該回路モジュールを第１の期間の終了後にリソースから削除する回路モジュールとリソースに維持する回路モジュールとのいずれかとして判定し、判定結果に応じてリソースを管理する。【選択図】図１
2018101267.tif 000002
【特許請求の範囲】
【請求項１】
リコンフィグ可能なリソースに第１の期間において実装されている回路モジュール群のそれぞれの回路モジュールの稼働状況の履歴に基づいて、当該回路モジュールを前記第１の期間の終了後に前記リソースから削除する回路モジュールと前記リソースに維持する回路モジュールとのいずれかとして判定し、判定結果に応じて前記リソースを管理する管理部を具備する、管理装置。
【請求項２】
前記管理部は、前記リソースに実装可能なそれぞれの回路モジュールの稼働状況の履歴に基づいて当該回路モジュールに対する前記リソースの割り当て優先順位を決定し、前記割り当て優先順位のより高い回路モジュールが優先的に前記リソースに実装されるように前記リソースを管理する、請求項１に記載の管理装置。
【請求項３】
前記管理部は、前記回路モジュール群のそれぞれの回路モジュールの前記第１の期間に続く第２の期間での使用要求の有無を判定し、前記第２の期間での使用要求がないと判定した回路モジュールを前記第１の期間の終了後に前記リソースから削除する回路モジュールとして判定する、請求項１に記載の管理装置。
【請求項４】
前記管理部は、前記回路モジュール群のそれぞれの回路モジュールの前記第１の期間に続く第２の期間での使用要求の有無を判定し、前記第２の期間での使用要求がないと判定した回路モジュールの使用頻度に基づいて当該回路モジュールを前記第１の期間の終了後に前記リソースから削除する回路モジュールと前記リソースに維持する回路モジュールとのいずれかとしてさらに判定する、請求項１に記載の管理装置。
【請求項５】
前記管理部は、前記回路モジュール群のそれぞれの回路モジュールの稼働状況を当該回路モジュールのレジスタへのアクセス発生状況に基づいて推定する、請求項１に記載の管理装置。
【請求項６】
前記管理部は、前記第１の期間に続く第２の期間に前記リソースに新規に実装される回路モジュールの設定レジスタへのアクセスをトリガとして当該回路モジュールの実装を開始する、請求項１に記載の管理装置。
【請求項７】
前記リソースに実装可能なそれぞれの回路モジュールは、レジスタと残余のエンジンとに分割され、
前記エンジンは、前記管理部によって前記リソースでの実装／削除を管理され、
前記レジスタは、前記リソースまたは別のリソースに常時実装される、
請求項１に記載の管理装置。
【請求項８】
前記管理部は、前記第１の期間に続く第２の期間に前記リソースに新規に実装される回路モジュールの起動レジスタへのアクセス発生時点で当該回路モジュールの実装が完了していなければ、当該回路モジュールの実装が未完了であることを外部に通知する、請求項１に記載の管理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
実施形態は、リコンフィグ可能な電子デバイスリソースにおける回路モジュールの実装状態の管理に関する。
【背景技術】
【０００２】
ＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）などのプログラム可能な論理デバイスに回路モジュールを実装することで、当該回路モジュールの機能追加、バグ修正などを容易に行うことができる。
【０００３】
さらに、リコンフィグ可能なリソースを有する論理デバイスを複数の異なる回路モジュールで時分割使用することも提案されている。例えば、通信分野において、ＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）で構成されるネットワークプロセッサを、受信データの特性に基づいて自動的にリコンフィグする試みがなされている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１６−０６３３５０号公報
【非特許文献】
【０００５】
【非特許文献１】「消費電力手法ガイド」、第４章、＜ＵＲＬ：  ｈｔｔｐ：／／ｊａｐａｎ．ｘｉｌｉｎｘ．ｃｏｍ／ｓｕｐｐｏｒｔ／ｄｏｃｕｍｅｎｔａｔｉｏｎ／ｓｗ＿ｍａｎｕａｌｓ＿ｊ／ｘｉｌｉｎｘ１３＿１／ｕｇ７８６＿ＰｏｗｅｒＭｅｔｈｏｄｏｌｏｇｙ．ｐｄｆ＞
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、リコンフィグ可能なリソースを有する論理デバイスの従来の用例では、リソースに実装する回路モジュールを変更するために当該リソースの稼働が長時間停止したり、リソースに実装された回路モジュールの稼働時間が少ないなどリソースが十分に使用されないまま放置され無駄な電力を消費し続けたりするなどの問題がある。
【０００７】
実施形態は、リコンフィグ可能な電子デバイスリソースを適切に管理することを目的とする。
【課題を解決するための手段】
【０００８】
実施形態によれば、管理装置は、管理部を含む。管理部は、リコンフィグ可能なリソースに第１の期間において実装されている回路モジュール群のそれぞれの回路モジュールの稼働状況の履歴に基づいて、当該回路モジュールを第１の期間の終了後にリソースから削除する回路モジュールとリソースに維持する回路モジュールとのいずれかとして判定し、判定結果に応じてリソースを管理する。
【図面の簡単な説明】
【０００９】
【図１】第１の実施形態に係るリソース管理装置を例示するブロック図。
【図２】図１の論理デバイスの有するリコンフィグ可能なリソースに実装することのできる回路モジュールの稼働状況を例示する図。
【図３】図１の論理デバイスの有するリコンフィグ可能なリソースに実装することのできる回路モジュールの実装態様の説明図。
【図４】図１の論理デバイスの有するリコンフィグ可能なリソースの時分割使用例の説明図。
【発明を実施するための形態】
【００１０】
以下、図面を参照しながら実施形態の説明が述べられる。尚、以降、説明済みの要素と同一または類似の要素には同一または類似の符号が付され、重複する説明は基本的に省略される。
【００１１】
（第１の実施形態）  
図１には、第１の実施形態に係るリソース管理装置１００が例示される。リソース管理装置１００は、論理デバイス１２０の有するリコンフィグ可能なリソース（リコンフィグ領域）における回路モジュールの実装状態を動的に管理する。
【００１２】
リソース管理装置１００は、制御バス１３０を介して論理デバイス１２０の有するリコンフィグ可能なリソースに実装されたレジスタにアクセスする。また、リソース管理装置１００は、回路モジュールの実装／削除命令を論理デバイス１２０に与えたり、回路モジュールからステータス情報を通知されたりする。ステータス情報は、例えば、回路モジュールが稼働（Ｒｕｎ）状態であるのか非稼働（Ｉｄｌｅ）状態であるのかを示し得る。
【００１３】
論理デバイス１２０は、リコンフィグ可能なリソース（リコンフィグ領域）を有しており、当該リソースにおいて１つ以上の回路モジュールを実装することができる。図１の例では、論理デバイス１２０のリコンフィグ可能なリソースは、回路モジュールのレジスタを実装するためのレジスタ実装領域１２１と、残余のエンジンを実装するためのエンジン実装領域１２２とを含む。
【００１４】
具体的には、図３に例示されるように、論理デバイス１２０の有するリコンフィグ可能なリソースに実装可能なそれぞれの回路モジュールは、レジスタと残余のエンジンとに分割され、レジスタはレジスタ実装領域１２１に常時実装され、エンジンは、リソース管理装置１００からの管理に従い、エンジン実装領域１２２に実装されたりエンジン実装領域１２２から削除されたりする。
【００１５】
すなわち、複数の回路モジュールのエンジンがエンジン実装領域１２２を時分割使用するので、エンジン実装領域１２２の面積は複数の回路モジュールのエンジンの実装時の回路面積の総和よりも小さくてよい。なお、各回路モジュールのエンジンは、実装時の回路面積を調べるために、例えば当該回路モジュールを使用するアプリケーション（機能）のインストール後に速やかにエンジン実装領域１２２に一旦実装されることが好ましい。
【００１６】
回路モジュールのレジスタをレジスタ実装領域１２１に常時実装しておけば、当該回路モジュールのエンジンがエンジン実装領域１２２に未実装の状態であっても、当該回路モジュールのレジスタはホストから当該回路モジュールの設定のためのバスアクセスを受け付けることが可能となる。これによって、各回路モジュールのレジスタは、対応するエンジンの実装状態に関わらずバスアクセスに即時応答し、係るバスアクセスによって制御バス１３０が占有されるのを防止することができる。
【００１７】
故に、ホスト側の制御ソフトウェアは、回路モジュールが論理デバイス１２０の有するリコンフィグ可能なリソースに実装されるのか書き換え不能な専用回路に常時実装されているのか、さらに回路モジュールが現在当該リソースに実装状態にあるのか未実装状態にあるのかを関知する必要がない。従って、この制御ソフトウェアは、例えばＳｏＣ（Ｓｙｓｔｅｍ−ｏｎ−ａ−Ｃｈｉｐ）、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）などの専用回路に実装された回路モジュールを取り扱うための既存の制御ソフトウェアを変更することなく転用可能である。
【００１８】
論理デバイス１２０は、リソース管理装置１００（のリソース管理部１１０）から回路モジュールの実装／削除命令を受け取り、受け取った命令に従って回路モジュールを実装／削除する。具体的には、論理デバイス１２０は、リソース管理装置１００から回路モジュールの実装命令を与えられると、対象の回路モジュールのデータを、データバス１４０を介して実装データ記憶部１５０からロードする。他方、論理デバイス１２０は、リソース管理装置１００から回路モジュールの削除命令を与えられると、当該回路モジュールを実装していた領域を解放する。
【００１９】
リソース管理装置１００は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１１１と、リソース管理回路１１３と、アクセス監視回路１１４とを含む。ＣＰＵ１１１は、図示されないメモリにロードされたリソース管理プログラムを実行することで、リソース管理ソフト１１２として動作することができる。
【００２０】
リソース管理部１１０は、論理デバイス１２０の有するリコンフィグ可能なリソースの複数の回路モジュールによる時分割使用をイベントドリブンで管理する。例えば、リソース管理部１１０は、回路モジュールの使用要求が生じたことを判定すると、当該回路モジュールの実装を試みる。リソースに十分な未実装領域がある場合には、リソース管理部１１０は、使用要求の生じた回路モジュールの実装命令を論理デバイス１２０に与えればよい。他方、リソースに十分な未実装領域がない場合には、リソース管理部１１０は、後述されるように、リソースからどの回路モジュールを削除するか、リソースにどの回路モジュールを維持または新規に実装するか、をそれぞれ決定し、実装／削除命令を論理デバイス１２０に与える。
【００２１】
具体的には、リソース管理部１１０は、論理デバイス１２０の有するリコンフィグ可能なリソースに実装可能なそれぞれの回路モジュールのレジスタへの短期的および長期的なアクセス発生状況ならびに当該回路モジュールのステータス情報を分析することにより、当該回路モジュールの使用要求が生じているか否かを判定したり、当該回路モジュールの稼働状況（例えば、回路モジュールの遊休期間、稼働期間、使用頻度、起動間隔など）を推定したりする。
【００２２】
そして、リソース管理部１１０は、論理デバイス１２０の有するリコンフィグ可能なリソースに実装可能なそれぞれの回路モジュールの稼働状況の履歴と使用要求の有無とに基づいて、当該リソースにおける回路モジュールの実装状態を動的に管理する。例えば、リソース管理部１１０は、このリソースに現行期間に実装されている回路モジュール群のそれぞれの回路モジュールの稼働状況の履歴と現行期間に続く次期間での使用要求の有無とに基づいて、当該回路モジュールを現行期間の終了後に当該リソースから削除する回路モジュールと次期間にも当該リソースに維持するモジュールとのいずれかとして判定してもよい。
【００２３】
また、リソース管理部１１０は、このリソースに実装可能なそれぞれの回路モジュールの稼働状況の履歴に基づいて当該回路モジュールに対するリソースの割り当て優先順位を決定し、割り当て優先順位のより高い回路モジュールが優先的にリソースに実装されるようにリソースを管理してもよい。
【００２４】
リソース管理部１１０は、リソース管理ソフト１１２およびリソース管理回路１１３に機能分割されている。リソース管理ソフト１１２とリソース管理回路１１３との間の機能分担は、ソフトウェアとハードウェアの特性を考慮して定められる。一例として、リソース管理ソフト１１２は、回路モジュールのレジスタに対するアクセス発生状況、回路モジュールのステータス情報に対する統計的な分析を行ったり、分析結果に基づいて論理デバイス１２０の有するリコンフィグ可能なリソースにおける回路モジュールの実装状態をスケジューリング（例えば、後述されるテーブルの管理）したりする。他方、リソース管理回路１１３は、リソース管理ソフト１１２のスケジューリング結果に従って、論理デバイス１２０に対して回路モジュールの実装または削除などの命令を即時に与える。リソース管理ソフト１１２とリソース管理回路１１３とは、制御バス１３０を介したレジスタアクセスを通じて互いに通信可能である。
【００２５】
図２には、２つの回路モジュールＡおよびＢの稼働状況が例示されている。各回路モジュールは、ともに、常時稼働（Ｒｕｎ）状態にあるのではなく、必要時に間欠的に稼働（Ｒｕｎ）している。各回路モジュールは、終了割り込みをＣＰＵに通知後、稼働（Ｒｕｎ）状態から非稼働（Ｉｄｌｅ）状態へと遷移する。他方、各回路モジュールは、対応する設定レジスタおよび起動レジスタの制御バス１３０を通じた書き込み動作（図２中で「設定」として描かれている）が完了すると、非稼働（Ｉｄｌｅ）状態から稼働（Ｒｕｎ）状態へと遷移する。
【００２６】
すなわち、各回路モジュールは、稼働（Ｒｕｎ）状態と非稼働（Ｉｄｌｅ）状態とを繰り返している。但し、各回路モジュールの稼働状況は同一ではなく、頻繁に稼働する必要のある回路モジュールがあれば、滅多に稼働する必要のない回路モジュールもある。故に、リソース管理部１１０は、回路モジュールの稼働状況を分析し、稼働状況の履歴に基づいて回路モジュールの実装／削除を適切に管理する。これによって、論理デバイス１２０の利用効率は向上し、大規模な回路モジュールを論理デバイス１２０の有する小規模なリコンフィグ可能なリソースによって置換することが可能となる。すなわち、リソース管理部１１０の管理能力が優れていれば、論理デバイス１２０を小型化、低コスト化することができる。
【００２７】
リソース管理部１１０は、基本的には、遊休期間（非稼働（Ｉｄｌｅ）状態の期間のうち設定期間を除いた部分）が長い傾向にある回路モジュールを、優先的に削除することで、当該回路モジュールの実装領域を他の回路モジュールの実装のために解放したり、当該回路モジュールを維持するための消費電力（例えば、クロック生成のための消費電力など）を削減したりする。
【００２８】
図２の回路モジュールＡおよび回路モジュールＢを比較すると、回路モジュールＡは、回路モジュールＢに比べて遊休期間が短い傾向にある。故に、リソース管理部１１０は、回路モジュールＡおよび回路モジュールＢのどちらかを削除する必要がある場合には、回路モジュールＢを優先的に削除する。また、リソース管理部１１０は、回路モジュールＢが次期間において不使用となる（現行期間において使用要求が生じていない）場合には、当該回路モジュールＢを積極的に削除してもよい。他方、リソース管理部１１０は、回路モジュールＡおよび回路モジュールＢの使用要求が競合した場合には、回路モジュールＡを優先的に実装する。
【００２９】
アクセス監視回路１１４は、論理デバイス１２０のレジスタ実装領域１２１に対する制御バス１３０を介したアクセスを監視する。具体的には、アクセス監視回路１１４は、タイマを用いてアクセス時刻を計測可能であり、アクセスが生じた場所（アドレス）と時刻との情報を収集する。アクセス監視回路１１４は、短期的なアクセス発生状況の情報と、長期的なアクセス発生状況の情報とをリソース管理部１１０に報告する。
【００３０】
短期的なアクセス発生状況の情報とは、例えば、特定の回路モジュールの設定レジスタへのアクセスが集中していることである。図２に例示されるように、回路モジュールの設定は、当該回路モジュールの設定レジスタに順次書き込みを行い、最後に当該回路モジュールの起動レジスタに書き込みを行うことで実現される。故に、起動レジスタへのアクセスに先行する設定レジスタのアクセス発生状況を監視して報告することで、リソース管理部１１０は、回路モジュールが起動準備状態にあること、すなわち当該回路モジュールの使用要求が生じていることを判定可能となる。
【００３１】
具体的には、アクセス監視回路１１４は、特定の回路モジュールの設定レジスタへのアクセスが規定時間内に規定回数以上生じた場合に、当該設定レジスタへのアクセス時刻をリソース管理部１１０に報告してもよい。このような情報が報告されれば、リソース管理部１１０は特定の回路モジュールへの使用要求を伴わない設定レジスタへの単発的または偶発的なアクセスを使用要求の発生と誤判定するのを防ぐことができる。他方、アクセス監視回路１１４は、特定の回路モジュールの設定レジスタへのアクセスがある毎に、当該設定レジスタへのアクセス時刻をリソース管理部１１０に報告してもよい。このような情報が報告されれば、特定の回路モジュールへの使用要求が生じていることを短時間で判定することができる。
【００３２】
いずれにせよ、回路モジュールの設定レジスタへのアクセスをトリガとして当該回路モジュールの実装を開始することが好ましい。回路モジュールの起動レジスタへの書き込みが完了する前に当該回路モジュールの実装を完了させることができれば、当該回路モジュールは設定完了時点では即座に稼働可能な状態にあるので、当該回路モジュールの実装に伴う遅延をホスト（ＣＰＵ含む）側から隠蔽することができる。他方、回路モジュールの起動レジスタへの書き込みが完了する前に当該回路モジュールの実装を完了することができなければ、当該回路モジュールの設定完了から本当に稼働可能な状態となるまでに遅延が生じるので、リソース管理部１１０は当該回路モジュールの実装が未完了であることを外部（例えばホスト）に通知する。これにより、ホスト（ＣＰＵ含む）側は、使用予定の回路モジュールが未実装であることを検知し、必要な措置を取ることができる。
【００３３】
長期的なアクセス発生状況の情報とは、例えば、特定の回路モジュールの起動レジスタへのアクセスが生じる間隔である。これは、特定の回路モジュールの起動間隔に相当する。例えば、アクセス監視回路１１４は、特定の回路モジュールの起動レジスタへのアクセスが生じると、そのアクセス時刻と当該起動レジスタへの前回のアクセス時刻とを組にしてリソース管理回路１１３に報告してもよい。
【００３４】
回路モジュールの稼働状況の推定は、一般的には回路モジュールのステータス情報を分析することで行われる。しかしながら、各回路モジュールは論理デバイス１２０の有するリコンフィグ可能なリソースに実装されていないこともあるので、信頼性の高いステータス情報を常に得ることは困難である。故に、アクセス監視回路１１４から報告される各回路モジュールのレジスタへのアクセス発生状況を使用することで、リソース管理部１１０は回路モジュールの稼働状況をより的確に推定することができる。
【００３５】
なお、リソース管理部１１０は、各回路モジュールのステータス情報およびリソース管理部１１０から報告される情報の時系列変化を統計的に分析してから、各回路モジュールの稼働状況の推定に用いてもよい。例えば、リソース管理部１１０は、報告された最新の起動間隔をそのまま用いずに、過去の起動間隔と重み付け平均をして用いてもよい。
【００３６】
以下、図４を用いて、論理デバイス１２０の有するリコンフィグ領域の時分割使用例を説明する。図４において、横軸は時間軸を表す。そして、図４は、時間軸上で連続する期間０〜期間８のそれぞれにおいて、論理デバイス１２０の有するリコンフィグ可能なリソースであるリコンフィグ領域１〜３で稼働する回路モジュールと、実装／稼働回路モジュール数の合計と、それらの消費電力とを表している。
【００３７】
なお、説明の簡単化のために、論理デバイス１２０のリコンフィグ可能なリソースは、リコンフィグ領域１〜３に等分割されていることとし、各リコンフィグ領域は、それぞれ同面積かつ同消費電力で実装されるように規格化された回路モジュールＡ〜Ｅのうち選択された１つを実装できることとする。すなわち、論理デバイス１２０は、同時に最大３つの回路モジュールを実装することができる。また、各回路モジュールの起動タイミングは一定周期で発生することとしている。すなわち、各期間の開始タイミングは一定の間隔で現れる。但し、実際には、各回路モジュールの起動タイミングの間隔および頻度は必ずしも一定ではないが、起動間隔を正規化して処理することは実装の簡素化につながる。
【００３８】
期間０において、リコンフィグ領域１およびリコンフィグ領域２ではそれぞれ回路モジュールＡおよび回路モジュールＢが稼働しており、リコンフィグ領域３ではいずれの回路モジュールも実装されていない（未実装期間）。故に、期間０において、実装回路モジュール数および稼働回路モジュール数の合計はいずれも２であって、消費電力は回路モジュール２つ分相当である。
【００３９】
この期間０において、回路モジュールＢ、回路モジュールＣおよび回路モジュールＥの３つから期間０に続く期間１での使用要求が生じたとする。この場合に、リソース管理部１１０は、例えば以下の表１に示すテーブルを用いて、論理デバイス１２０の有するリコンフィグ可能なリソースの複数の回路モジュールに対する割り当て優先順位を管理する。表１は、期間１における各回路モジュールによる領域使用の決定例を示す。
【００４０】
【表１】
2018101267.tif 000003
【００４１】
表１において、ベースアドレスは、制御バス１３０によって割り当てられた、各回路モジュールのレジスタのベースアドレスを表す。リアルタイム性要求フラグは、各回路モジュールの処理にリアルタイム性が要求されるか否か、すなわち、遅延が許容されるか否かを表す。即時削除可能フラグは、各回路モジュールが不使用となる期間に、当該回路モジュールを積極的に削除してリコンフィグ領域を解放することが許されるか否かを表す。なお、実際に回路モジュールを削除する場合には、当該回路モジュールが実装されている期間の終了割り込み時に当該回路モジュールが実装されているリコンフィグ領域の解放の予約がなされ、次期間の開始までに当該回路モジュールが削除される。なお、次期間においてこのリコンフィグ領域に別の回路モジュールが割り当てられていれば、当該リコンフィグ領域は当該別の回路モジュールによって上書きされる。
【００４２】
回路モジュールが不使用となる期間に先立って当該回路モジュールを削除することは、消費電力削減の点では効果的である。反面、使用頻度または稼働比率（遊休期間または全期間に対する稼働期間の比率）の高い回路モジュールは、こまめに削除してもすぐに再実装しなければならないと予想されるので、係る回路モジュールを積極的に削除したとしても消費電力の削減効果が限定的であるばかりでなくスケジュールが複雑化する。
【００４３】
従って、図４の例では、即時削除可能フラグを用意し、回路モジュールが不使用となる期間に先立って当該回路モジュールを一律に削除するのではなく、当該回路モジュールの稼働比率の高低に応じて維持／削除を切り替えるようにしている。
【００４４】
例えば、図４の回路モジュールＣは、使用頻度が高いので、即時削除可能フラグが０に設定され、不使用となる期間にも積極的には削除されない。但し、回路モジュールＣの不使用となる期間に対して使用要求の発生した回路モジュールの数が３以上である場合には、回路モジュールＣの実装されているリコンフィグ領域は別の回路モジュールに上書きされることもある。
【００４５】
これらベースアドレス、リアルタイム性要求フラグおよび即時削除可能フラグは、回路モジュールのセットアップ時（例えば、回路モジュールがスマートフォンの機能拡張によって使用されるならば当該機能のインストール時）に設定される静的な（固定の）情報である。但し、即時削除可能フラグは、例えば稼働比率に応じて事後的に変更できるように設計されてもよい。これら以外のパラメータは、回路モジュールの稼働状況に応じて期間毎に更新可能な動的な（可変の）情報である。
【００４６】
使用頻度とは、単位時間あたりの起動回数、すなわち起動レジスタの書き込み回数であって、起動間隔の逆数に比例する。リソース管理ソフト１１２は、各回路モジュールの直近の稼働状況に基づいて使用頻度を適宜更新する。
【００４７】
規定順位とは、中長期的な視点から決定される、リコンフィグ領域の割り当て時における回路モジュール間の基本的な優劣を決定するための序列である。図４の例では、以下の指針により規定順位を決定している。
【００４８】
（１）  リアルタイム性要求フラグが「１」である回路モジュールには、リアルタイム性要求フラグが「０」である回路モジュールよりも高い規定順位が与えられる。
【００４９】
（２）  リアルタイム性要求フラグが同一である回路モジュール間の序列は、使用頻度の降順に決定される。すなわち、使用頻度の高い回路モジュールには、使用頻度の低い回路モジュールよりも高い規定順位が与えられる。
【００５０】
割り当て優先順位とは、次期間でのリコンフィグ領域の割り当てにおける回路モジュール間の優劣を決定する序列であって、短期的な要因を考慮して規定順位を修正することで得られる。図４の例では、次期間優先フラグを考慮して規定順位をベースに割り当て優先順位を決定している。なお、表１および以降の表では、割り当て優先順位の降順に回路モジュールがソートされている。
【００５１】
ここで次期間優先フラグは、現行期間において使用要求が生じているにも関わらずリコンフィグ領域を割り当てられない回路モジュールに対して「１」が設定される。次期間優先フラグは、期間毎に「０」にリセットされる。
【００５２】
具体的には、次期間優先フラグが前期間「１」に設定された回路モジュールは、現行期間に行われるスケジューリングにおいて規定順位よりも上の割り当て優先順位を与えられることがある。反対に、次期間優先フラグが前期間「０」に設定された回路モジュールは、現行期間に行われるスケジューリングにおいて規定順位よりも低い割り当て優先順位を与えられることがある。例えば、リアルタイム性要求フラグの値が同じである回路モジュール間では、次期間優先フラグが前期間「１」に設定された回路モジュールは、次期間優先フラグが前期間「０」に設定された回路モジュールよりも高い割り当て優先順位を与えられる。リアルタイム性要求フラグおよび次期間優先フラグの前期間の設定値が同じである回路モジュール間の序列は規定順位に従う。
【００５３】
使用要求フラグは、現行期間（表１の場合には期間０）において次期間（表１の場合衣には期間１）での使用要求が生じていれば「１」に設定される。なお、使用要求フラグは、期間毎にリセットされる。すなわち、使用要求フラグが「１」である回路モジュールに現行期間で行われるスケジューリングにおいてリコンフィグ領域が割り当てられなかったとしても、次期間において使用要求が生じていなければ、使用要求フラグは次期間において行われるスケジューリングでは「０」に戻る。なお、このケースでは、次期間において行われるスケジューリングにおいて、回路モジュールの使用要求フラグは「０」に戻るものの次期間優先フラグが「１」に設定されるので、当該回路モジュールはこのスケジューリングでは高い割り当て優先順位を与えられ、リコンフィグ領域を割り当てられやすくなる。
【００５４】
リソース管理部１１０は、以下のアルゴリズムで、次期間におけるリコンフィグ領域の割り当てを決定する。
【００５５】
（１）  リソース管理部１１０は、割り当て優先順位の高い順に回路モジュールを選択し、当該回路モジュールの使用要求フラグが「１」であるか次期間優先フラグが前期間「１」に設定されていたならば、当該回路モジュールをリコンフィグ領域の割り当て対象に加える。但し、割り当て対象に加えられた全ての回路モジュールの実装時の回路面積の合計が、論理デバイス１２０の有するリコンフィグ可能なリソース（図４の例では３つのリコンフィグ領域）を上回るならば、リソース管理部１１０は最後に割り当て対象に加えた回路モジュールを割り当て対象から除外し、リコンフィグ領域を未割り当てとして次期間優先フラグを「１」に設定する。リソース管理部１１０は、割り当て優先順位のより低い回路モジュールにも同様の扱いをする。
【００５６】
（２）  リソース管理部１１０は、（１）において割り当て対象に加えた回路モジュールに対して、以下の指針に従ってリコンフィグ領域を割り当てる。
【００５７】
（２−１）  回路モジュールが現行期間においてリコンフィグ領域を割り当てられている場合には、リソース管理部１１０は、選択した回路モジュールに当該リコンフィグ領域を次期間にも継続して割り当てる。
【００５８】
（２−２）  回路モジュールが現行期間においてリコンフィグ領域を割り当てられていない場合には、リソース管理部１１０は、解放されているリコンフィグ領域を新規に割り当てるように試みる。解放されているリコンフィグ領域が選択した回路モジュールの実装時の回路面積を下回る場合には、リソース管理部１１０は、現行期間において別の回路モジュールが実装されている領域に回路モジュールを上書きする。ここで、リソース管理部１１０は、（１）において割り当て対象に加えなかった回路モジュールを割り当て優先順位の低い順に選択し、選択された回路モジュールの実装されているリコンフィグ領域を上書きの対象とする。
【００５９】
（３）  リソース管理部１１０は、（１）において割り当て対象に加えなかった回路モジュールのうち即時削除可能のフラグが「１」である回路モジュールが現行期間にリコンフィグ領域を割り当てられている場合に、（２−２）で次期間において別の回路モジュールによる上書きの対象とされていなかったとしても、当該回路モジュールを削除してもよい。このような回路モジュールを積極的に削除することで、消費電力の削減効果が見込まれる。
【００６０】
このアルゴリズムに従って、リソース管理部１１０は、期間１におけるリコンフィグ領域の割り当てを以下のように決定する。  
使用要求フラグが「１」であるのは回路モジュールＣ、回路モジュールＢおよび回路モジュールＥであって、次期間優先フラグが前期間「１」に設定されていた回路モジュールはない。また、これら回路モジュールＣ、回路モジュールＢおよび回路モジュールＥの実装時の回路面積の合計は、論理デバイス１２０の有するリコンフィグ可能なリソースを上回らない。故に、リソース管理部１１０は、回路モジュールＣ、回路モジュールＢおよび回路モジュールＥをリコンフィグ領域の割り当て対象に加える。
【００６１】
回路モジュールＢは、期間０においてリコンフィグ領域２を割り当てられている。従って、リソース管理部１１０は、回路モジュールＢにリコンフィグ領域２を継続して割り当てる。また、リソース管理部１１０は、期間０において解放されているリコンフィグ領域３を回路モジュールＣに新規に割り当てる。さらに、リソース管理部１１０は、期間０において回路モジュールＡに割り当てられていたリコンフィグ領域１を、回路モジュールＢによる上書きの対象とする。
【００６２】
次に、全ての回路モジュールの使用要求が生じ、一部の回路モジュールへのリコンフィグ領域の割り当てが不可能となる期間６における各回路モジュールによる領域使用の決定例を表２を用いて説明する。
【００６３】
【表２】
2018101267.tif 000004
【００６４】
期間６では全ての回路モジュールの使用要求フラグが「１」であるから、リソース管理部１１０は、割り当て優先順位の高い順に回路モジュールを選択し、当該回路モジュールをリコンフィグ領域の割り当て対象に加える。但し、割り当て優先順位がそれぞれ１位、２位および３位である回路モジュールＤ、回路モジュールＣおよび回路モジュールＢを割り当て対象に加えた時点で、これらの回路モジュールの実装時の回路面積の合計がリコンフィグ領域の割り当て上限に達する。すなわち、期間６においてこれ以上の回路モジュールを論理デバイス１２０の有するリコンフィグ可能なリソースに実装することはできない。故に、リソース管理部１１０は、割り当て優先順位がそれぞれ４位および５位である回路モジュールＡおよび回路モジュールＢを割り当て対象から除外し、リコンフィグ領域を未割り当てとして次期間優先フラグを「１」に設定する。
【００６５】
リコンフィグ領域の割り当て対象に加えられた回路モジュールＤ、回路モジュールＣおよび回路モジュールＢのうち、回路モジュールＣには期間５においてリコンフィグ領域３が割り当てられている。故に、リソース管理部１１０は、回路モジュールＣにリコンフィグ領域３を継続して割り当てる。また、リソース管理部１１０は、期間５において解放されているリコンフィグ領域２を回路モジュールＤに新規に割り当てる。さらに、リソース管理部１１０は、期間５において回路モジュールＡに割り当てられていたリコンフィグ領域１を、回路モジュールＢによる上書きの対象とする。
【００６６】
次に、期間６に続く期間７における各回路モジュールによる領域使用の決定例を表３を用いて説明する。
【００６７】
【表３】
2018101267.tif 000005
【００６８】
リソース管理部１１０は、期間６（前期間のスケジューリング）において回路モジュールＡおよび回路モジュールＢにはリコンフィグ領域を割り当てられず、次期間優先フラグを「１」に設定した。従って、リソース管理部１１０は、期間７において、回路モジュールＡおよび回路モジュールＢの割り当て優先順位を回路モジュールＣおよび回路モジュールＢに比べて高く設定する。
【００６９】
割り当て優先順位が１位である回路モジュールＤは、使用要求フラグが「０」に設定されており、次期間優先フラグは前期間「０」に設定されていた。故に、リソース管理部１１０は、回路モジュールＤをリコンフィグ領域の割り当て対象に加えない。割り当て優先順位がそれぞれ２位および３位である回路モジュールＡおよび回路モジュールＥは次期間優先フラグが前期間「１」に設定されていたので、リソース管理部１１０は、当該回路モジュールＡおよび回路モジュールＥをリコンフィグ領域の割り当て対象に加える。さらに、割り当て優先順位がそれぞれ４位である回路モジュールＣは使用要求フラグが「１」に設定されているので、リソース管理部１１０は回路モジュールＣをリコンフィグ領域の割り当て対象に加える。この時点で、リコンフィグ領域の割り当て対象に加えられた回路モジュールの実装時の回路面積の合計がリコンフィグ領域の割り当て上限に達する。すなわち、期間７において、これ以上の回路モジュールを論理デバイス１２０の有するリコンフィグ可能なリソースに実装することはできない。故に、リソース管理部１１０は、割り当て優先順位が５位である回路モジュールＢを割り当て対象から除外し、リコンフィグ領域を未割り当てとして次期間優先フラグを「１」に設定する。
【００７０】
リコンフィグ領域の割り当て対象に加えられた回路モジュールＡ、回路モジュールＥおよび回路モジュールＣのうち、回路モジュールＣには期間６においてリコンフィグ領域３が割り当てられている。故に、リソース管理部１１０は、回路モジュールＣにリコンフィグ領域３を継続して割り当てる。また、リソース管理部１１０は、期間６において回路モジュールＢおよび回路モジュールＡにそれぞれ割り当てられていたリコンフィグ領域１およびリコンフィグ領域２を、それぞれ、回路モジュールＥおよび回路モジュールＡによる上書きの対象とする。
【００７１】
このように、複数の回路モジュールの使用要求が集中し、論理デバイス１２０の有するリコンフィグ可能なリソースを超過する規模の回路モジュールの実装が必要となった場合には、リソース管理部１１０が割り当て優先順位の低い回路モジュールの実装を適宜順延することで調停を行う。係る調停によれば、使用要求のピーク時に、割り当て優先順位の低い回路モジュールに一時的に遅延が課されるものの、中長期的に見れば全ての回路モジュールを概ね滞りなく運用することができる。すなわち、論理デバイス１２０の有するリコンフィグ可能なリソースに実装可能な回路モジュールの実装時の回路面積の合計に比較して、当該リソースは小さくて済む。
【００７２】
他方、このような調停を行っても、多数の回路モジュールの使用要求が頻繁に発生すればスケジュールが破綻するおそれがある。このような場合には、リソース管理部１１０は例えば論理デバイス１２０の異常をホスト（ＣＰＵ含む）側に通知し、ホスト（ＣＰＵ含む）側がより高度な調停および管理を行えばよい。
【００７３】
なお、リソース管理部１１０は、各期間において使用要求のあった回路モジュールの実装時の回路面積の合計を分析することで、１期間あたりの必要リソース（リコンフィグ領域の面積）の平均値およびピーク値を算出してもよい。これらの分析結果に基づいて、リソース管理ソフト１１２が更新されたり、リソースの拡張を促したりしてもよい。
【００７４】
以上説明したように、第１の実施形態に係るリソース管理装置は、論理デバイスの有するリコンフィグ可能なリソース（リコンフィグ領域）を動的に管理する。具体的には、このリソース管理装置は、所与の期間においてリソースに実装されている１以上の回路モジュールのそれぞれの稼働状況の履歴（例えば、使用頻度）に基づいて、当該所与の期間の終了後に（次期間の開始に先立って）リソースから削除する回路モジュールとリソースに維持する回路モジュールとを判定し、判定結果に応じてリソースを管理する。従って、このリソース管理装置によれば、所与の期間においてリソースに実装されている回路モジュールの一部が、当該回路モジュールの稼働状況の履歴次第で当該期間の終了後に削除される。この結果、例えば使用頻度の低い回路モジュールを積極的に削除して、無駄な電力の消費を効果的に防止することができる。
【００７５】
なお、第１の実施形態では、回路モジュールのリアルタイム性要求の有無を２値のフラグで表現しているが、代わりに回路モジュールの許容レイテンシを多値の整数値で表現してもよい。そして、例えば、許容レイテンシの範囲内で回路モジュールに対するリソース割り当てを適宜順延できるようにすれば、より高度で柔軟なリソース管理を実現することができる。
【００７６】
第１の実施形態は、論理デバイスの有するリコンフィグ可能なリソースに各回路モジュールのレジスタを常時実装することで、制御バスのフリーズを防止している。しかしながら、レジスタは、このリソースとは別のリソース（例えば、リコンフィグ不可能なリソースまたは別の論理デバイスの有するリコンフィグ可能なリソース）に常時実装されてもよい。或いは、レジスタを常時実装する代わりに、アクセスを一時的に受け付けるためのダミーのバス回路を用意するようにしてもよい。この変形例では、レジスタもエンジンに連動して実装／削除される。換言すれば、回路モジュールをレジスタとエンジンとに分割する必要はない。
【００７７】
第１の実施形態では、ソフトウェアとハードウェアとが協同するハイブリッド型のリソース管理部を説明した。このリソース管理部は、例えば深層学習を利用して、より的確な管理を行うようにグレードアップさせることも可能である。
【００７８】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【００７９】
１００・・・リソース管理装置
１１０・・・リソース管理部
１１１・・・ＣＰＵ
１１２・・・リソース管理ソフト
１１３・・・リソース管理回路
１１４・・・アクセス監視回路
１２０・・・論理デバイス
１２１・・・レジスタ実装領域
１２２・・・エンジン実装領域
１３０・・・制御バス
１４０・・・データバス
１５０・・・実装データ記憶部
【図１】
2018101267.tif 000006
【図２】
2018101267.tif 000007
【図３】
2018101267.tif 000008
【図４】
2018101267.tif 000009