(57)【要約】【課題】構成変更可能なプロセッサ上で実行されるアプリケーションプログラムの処理するデータに応じて、アプリケーションプログラムの並列度を向上させる。【解決手段】設計装置１は、処理データを用いてアプリケーションプログラムをシミュレーションして得られたトレース情報を解析して、プロセッサにおいて使用される１以上のレジスタにストアされるデータのサイズを得る。さらに、設計装置１は、解析して得られたサイズにより決定されるレジスタの第１の分割数が、アプリケーションプログラムにおいて処理データについて定義されたデータサイズにより決定されるレジスタの第２の分割数より大きい場合は、アプリケーションプログラムにおけるデータサイズの定義を第１の分割数に対応するデータサイズに変更し、かつ変更されたデータサイズに応じた並列処理が可能なようにアプリケーションプログラムを書き換える。【選択図】図２
2009271599.tif 000002
【特許請求の範囲】
【請求項１】
構成変更可能なプロセッサの設計装置であって、
前記プロセッサにおいて実行されるアプリケーションプログラムにおいて処理される処理データを用いて前記アプリケーションプログラムをシミュレーションして得られたトレース情報を解析して、前記プロセッサにおいて使用される１以上のレジスタにストアされるデータのサイズを得るトレース情報解析部と、
解析して得られたサイズにより決定されるレジスタの第１の分割数が、前記アプリケーションプログラムにおいて前記処理データについて定義されたデータサイズにより決定されるレジスタの第２の分割数より大きい場合は、前記アプリケーションプログラムにおけるデータサイズの定義を前記第１の分割数に対応するデータサイズに変更し、かつ変更されたデータサイズに応じた並列処理が可能なように前記アプリケーションプログラムを書き換えるアプリケーションプログラム書換部と、
を有することを特徴とする構成変更可能なプロセッサの設計装置。
【請求項２】
前記第１の分割数が前記第２の分割数よりも小さい場合は、コアブロック数を増加するようにコンフィギュレーション情報を変更するコンフィギュレーション情報変更部を有し、
前記アプリケーションプログラム書換部は、前記第１の分割数が前記第２の分割数よりも小さい場合は、前記アプリケーションプログラムにおけるデータサイズの定義を前記第１の分割数に対応するデータサイズに変更し、かつ変更されたデータサイズに応じて並列処理可能なように前記アプリケーションプログラムを書き換えることを特徴とする請求項１に記載の構成変更可能なプロセッサの設計装置。
【請求項３】
前記処理データのデータサイズに応じた、前記レジスタの分割数の情報を記憶した分割情報記憶部を有し、
前記第１の分割数は、前記解析して得られたサイズに基づいて、前記分割情報記憶部を参照して、決定され、
前記第２の分割数は、前記定義されたデータサイズに基づいて、前記分割情報記憶部を参照して、決定されることを特徴とする請求項１又は２に記載の構成変更可能なプロセッサの設計装置。
【請求項４】
前記アプリケーションプログラムは、高級言語で記述されたプログラムであり、
前記アプリケーションプログラム書換部は、前記アプリケーションプログラムを前記高級言語レベルで書き換えることを特徴とする請求項１から３のいずれか１つに記載の構成変更可能なプロセッサの設計装置。
【請求項５】
構成変更可能なプロセッサの設計方法であって、
前記プロセッサにおいて実行されるアプリケーションプログラムにおいて処理される処理データを用いて前記アプリケーションプログラムをシミュレーションして得られたトレース情報を解析して、前記プロセッサにおいて使用される１以上のレジスタにストアされるデータのデータサイズの情報を得、
解析して得られたデータサイズにより決定されるレジスタの第１の分割数が、前記アプリケーションプログラムにおいて前記処理データについて定義されたデータサイズにより決定されるレジスタの第２の分割数より大きい場合は、前記アプリケーションプログラムにおけるデータサイズの定義を前記第１の分割数に対応するデータサイズに変更し、かつ変更されたデータサイズに応じた並列処理が可能なように前記アプリケーションプログラムを書き換える、
ことを特徴とする構成変更可能なプロセッサの設計方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、構成変更可能なプロセッサの設計装置及びその設計方法に関する。
【背景技術】
【０００２】
従来より、例えば、組み込み機器の分野等において使用されるLSI等の半導体装置では、マイクロプロセッサ、メモリ、チップセット、画像処理チップ等の各機能部を１つのチップ上に集積させる手法が採用されている。このようなシステム全体を単一のチップに搭載するような形態の装置は、一般にSoC(System on Chip)と呼ばれる。複数の機能部を１つのチップ上に集積させることによって、同等の機能を実現する複数のチップから構成されたシステムよりも、実装に必要な面積、消費電力を抑えることができる。
【０００３】
SoCに搭載されるこのようなシステムは、巨大化の一途を辿っており、大きくなればなる程、システムに求められる機能の多様化が進み、結果的には、SoCは、生産面から見ると多品種少量生産となる特徴がある。
【０００４】
SoCは、ソフトウェア部分とハードウェア部分の２つの面から見ることができ、ソフトウェアは、マイクロプロセッサ上で実行されるものであるが、一度設計されても、その後修正又は変更がしばしば行われる。一方、マイクロプロセッサ等のハードウェアは、一度設計されて検証されると、その後その製造がされるが、それ以降は変更がなされることはない。すなわち、ソフトウェアはハードウェア側の仕様を鑑みながら、設計、コーディング、最適化のプロセスを経て完成するものであるが、機能に変更があれば、その変更を担うのは専らソフトウェア部分である。
【０００５】
そして、ソフトウェアの最適化はコンパイラ等のソフトウェア開発ツールによって自動的になされる場合もあるが、ソフトウェアの最適化は、開発者がプロファイルを取りながら試行錯誤を繰り返して手作業で行う場合もあり、開発期間、コスト等の制約から十分になされない場合もあり、なされたとしても当然限界がある。
【０００６】
また、ソフトウェアの最適化が十分であるか不十分のままであるかに拘わらず、ソフトウェアの実行環境として常に既存のハードウェアが理想的であるとは限らない。  
そこで、最近、仕様変更に柔軟に変動する役剖をソフトウェア部分だけでなくプロセッサ等のハードウェア部分にも担わせることかできるように考案された、構成変更可能なプロセッサが広く利用されるようになってきている。
【０００７】
構成変更可能なプロセッサは、ユーザがハードウェアをも設計するので、GUI等における開発ツールの使用感と性能が設計作業の生産性に大いに関係すると言われており、そのための開発ツールに関する提案もされている（例えば、特許文献１参照）。
【０００８】
SoCを開発しているベンダーにとっては、多数の機能のバリエーションを持つSoCをいかに早く市場に投入するかは重要課題である。その課題解決のためには、まず設計期間の短縮が求められているが、この要求に対応する為にはシステム仕様の決定の段階からSoCを設計することが望ましい。
【０００９】
ハードウェアについて見ると、従来より、LSIの設計にはハードウェア記述言語（HDL）を用いて開発が行われている。しかしながら、HDLは、クロック単位の動作定義をするため、ハードウェアの設計には適していても、システム仕様の記述には不向きである。システム仕様の記述にはソフトウェアの記述言語として広く使われているC言語の方か望ましい。C言語でシステムを統一的に設計する方法も多く提案されている（例えば、非特許文献１参照）。
【００１０】
ただし、現状では、LSIの設計は、EDAツールによって部分的に自動化されているだけでであり、SoCの提供するシステム全体をC言語によって設計し、以降の開発プロセスを完全に自動化することはできていない。
【００１１】
上述した開発ツールの使用感、及び性能が設計作業の生産性向上のための提案においては、ユーザのコンフィギュレーション情報とプロセッサのコンフィギュレーション情報がEDAツールであるサーチエンジンに入力されるが、サーチエンジンの出力は、SoCにおいてハードウェア側で実現する部分と、ソフトウェア側で実現する部分とが切り分けられた出力である。従って、システム全体として、所望の性能とコストに見合ったSoCが開発できるか否かはこのサーチエンジンの出力の段階でほとんど決定される。  
しかし、EDAツールへ入力するユーザのコンフィグレーション情報には、コアブロック数等の詳細な設定情報が含まれているが、ユーザは、実際にシステム上で実行されるアプリケーションプログラムに最適なハードウェア構成を完全に把握して、コア数の設定等を行っているわけではない。
【００１２】
一方で、システム設計者がハードウェア部分とソフトウェア部分をモデリング等の手法により短時間で協調検証しながら機能の確認が、部分的にできるツールは存在する。しかし、システムの性能を決定する、ハードウェア部分とソフトウェア部分の切り分け作業は経験を積んだ設計者によって試行錯誤で行われ、その作業は時間のかかる作業である。
【００１３】
また、ソフトウェアについては、サーチエンジンは、プログラム言語、アセンブラ／逆アセンブラ、及びシミュレータ／エミュレータの各ソフトウェア開発ツールを生成する。そして、これらの開発ツールを用いて、ユーザのアプリケーションプログラムについての、コンパイル、シミュレーション、及びデバッグ／プロファイリングを含むソフトウェア開発のプロセスによりソフトウェアの最適化が行われる。
【００１４】
他方、ハードウェアについては、サーチエンジンは、ハードウェア用のHDL記述を生成し、生成されたHDLに対して論理合成、及びプロファイリングを含む開発のプロセスを実行することにより、ハードウェアの最適化が行われる。それぞれが別個に最適化の行われたハードウェアとソフトウェアが、最終的に統一されることによって、SoCのシステムが作成される。しかし、別個に最適化が行われたソフトウェアとハードウェアの組み合わせのものが、SoC上のシステム全体としても最適かどうかは不明である。
【００１５】
以上のようにしてSoCのシステムが開発される場合、ソフトウェアの開発者は、ソフトウェアの設計時に、そのソフトウェアにより処理されるデータのデータサイズの定義を行ってアプリケーションプログラムを作成するが、ソフトウェアの設計時に、実際に処理されるデータの内容を全て把握できていない場合も多い。
【００１６】
アプリケーションプログラムにおいてデータサイズが処理データに応じて正しく定義されていないと、アプリケーションプログラムがデータ処理を最適な並列度で行っていないように記述されている場合がある。
【００１７】
しかし、このような場合に、アプリケーションプログラムを修正するには、ユーザが実行結果を見ながら、手作業でかつ試行錯誤でアプリケーションプログラムの修正を行わなければならなかった。
【特許文献１】特開2007-250010号公報
【非特許文献１】ディ・ガジスキ（D. Gajski）他著、「システムデザイン：スペックCによる実用的ガイド」（System Design: A Practical Guide With Spec C）」、スプリンガー社（Springer）、2001年5月
【発明の開示】
【発明が解決しようとする課題】
【００１８】
そこで、本発明は、上述した問題に鑑みてなされたもので、構成変更可能なプロセッサ上で実行されるアプリケーションプログラムの処理するデータに応じて、アプリケーションプログラムの並列度を向上させることができる構成変更可能なプロセッサの設計装置及びその設計方法を提供することを目的とする。
【課題を解決するための手段】
【００１９】
本発明の一態様によれば、構成変更可能なプロセッサの設計装置であって、前記プロセッサにおいて実行されるアプリケーションプログラムにおいて処理される処理データを用いて前記アプリケーションプログラムをシミュレーションして得られたトレース情報を解析して、前記プロセッサにおいて使用される１以上のレジスタにストアされるデータのサイズを得るトレース情報解析部と、解析して得られたサイズにより決定されるレジスタの第１の分割数が、前記アプリケーションプログラムにおいて前記処理データについて定義されたデータサイズにより決定されるレジスタの第２の分割数より大きい場合は、前記アプリケーションプログラムにおけるデータサイズの定義を前記第１の分割数に対応するデータサイズに変更し、かつ変更されたデータサイズに応じた並列処理が可能なように前記アプリケーションプログラムを書き換えるアプリケーションプログラム書換部と、を有する構成変更可能なプロセッサの設計装置を提供することができる。
【発明の効果】
【００２０】
本発明の構成変更可能なプロセッサの設計装置及びその設計方法によれば、プロセッサ上で実行されるアプリケーションプログラムの処理するデータに応じて、アプリケーションプログラムの並列度を向上させることができる。
【発明を実施するための最良の形態】
【００２１】
以下、図面を参照して本発明の実施の形態を説明する。  
まず図１に基づき、本実施の形態に係わる構成変更可能なプロセッサの設計装置の構成を説明する。図１は、本実施の形態に係わる構成変更可能なプロセッサの設計装置の構成を示す構成図である。
【００２２】
図１に示すように、構成変更可能なプロセッサの設計を行う設計装置１は、パーソナルコンピュータ（以下、PCという）、サーバ、ワークステーション等のコンピュータである。設計装置１は、コンピュータ本体１１と、表示装置１２と、ハードディスク装置等の記憶装置１３とを含んで構成される。以下に説明する処理は、記憶装置１３にソフトウェアプログラムとして記憶され、コンピュータ本体１１内のCPUによって読み出されて実行される。表示装置１２の画面上には、プロセッサの開発者であるユーザが各種処理の実行を指示するためのグラフィカルユーザインターフェース（GUI）が表示される。
【００２３】
ユーザは、設計装置１を用いて、SoCのプロセッサである構成変更可能なプロセッサの設計を行う。ユーザは、所望の仕様を決定して、その仕様に関するコンフィギュレーション情報を、設計装置１に入力する。設計装置１には、ベンダーの提供するプロセッサの仕様に関するコンフィギュレーション情報も入力される。設計装置１は、ベンダーの提供する構成変更可能なプロセッサに関して、ユーザの所望する仕様に合致する最適な構成の組み合わせを探索して、ハードウェアとソフトウェアのそれぞれに最適な構成を決定し、決定した情報に対応するハードウェアの設計情報及びソフトウェアに関する各種情報を出力する。
【００２４】
図２は、設計装置１を用いて、本実施の形態に係わる構成変更可能なプロセッサの設計の流れを説明するための図である。  
プロセッサのベンダーから提供されるプロセッサコンフィギュレーション情報２１と、ユーザが与えるユーザコンフィギュレーション情報２２とが、サーチエンジン２３に与えられる。プロセッサコンフィギュレーション情報２１とユーザコンフィギュレーション情報２２は、それぞれテキストデータである。サーチエンジン２３は、プロセッサコンフィギュレーション情報２１と、ユーザコンフィギュレーション情報２２とから、ハードウェアの構成を決定するHDLプログラム２４と、ソフトウェアを開発するためのソフトウェアとしての開発ツール２５を生成して出力する。なお、サーチエンジン２３の処理、及び以下に説明する処理は、コンピュータ本体１１内のCPUにより実行される。
【００２５】
プロセッサコンフィギュレーション情報２１は、プロセッサのベンダーから提供される、構成変更可能なプロセッサに関する構成情報であり、プロセッサのレジスタのサイズ情報等のレジスタ情報２１ａを含む。例えば、レジスタ情報２１ａには、プロセッサの処理単位が３２ビットであり、プロセッサのレジスタは３２ビットのレジスタであるという情報が含まれる。
【００２６】
ユーザコンフィギュレーション情報２２は、設計するプロセッサのシステムに関してユーザが定義するコンフィギュレーション情報であり、分割情報２２ａを含む。  
図３は、分割情報２２ａの例を示す図である。分割情報２２ａは、処理データのデータサイズに応じてレジスタを分割する分割数の情報である。図３に示すように、分割情報２２ａは、例えば、レジスタのサイズが３２ビットである場合、処理データのデータサイズが３２ビットであれば、分割数は１（分割せず）であり、処理データのデータサイズが１６ビットであれば、分割数は２（すなわち２分割）であり、処理データのデータサイズが８ビットであれば、分割数は４（すなわち４分割）である、という内容の情報を含む。
【００２７】
分割情報２２ａは、記憶装置１３の所定の記憶領域に記憶される。よって、記憶装置１３のその記憶領域は、分割情報記憶部を構成する。
【００２８】
図２に戻り、設計装置１は、構成変更可能なプロセッサにおける、ハードウェア部分とソフトウェア部分の情報を別個に生成する。  
ハードウェア部分については、HDLプログラム２４に基づいて、論理合成処理２６、ブロック配置及び配線のルーティングについての処理２７、同期のタイミングを検証するためのタイミング検証処理２８及びプロファイルデータを取得するプロファイル処理２９が順番に実行される。その結果、プロセッサの設計情報に関する種々の情報が出力される。
【００２９】
ソフトウェア部分については、サーチエンジン２３から出力された各種プログラムを含む開発ツール２５とコンパイラ３１によって、ユーザの作成したアプリケーションプログラム（以下、単にアプリケーションという）APに対して、コンパイル処理が実行される。
【００３０】
次に、シミュレータ３２が、コンパイルされて実行可能ファイル形式となったアプリケーションAPとそのアプリケーションAPが処理するデータDAとを用いて、シミュレーション処理を実行する。シミュレータ３２は、シミュレーション処理の結果、トレース情報を含む各種データを生成する。トレース情報は、後述するように、プロセッサにおいてアプリケーションAPの処理に使用するレジスタに書き込まれたあるいはストアされたデータの情報を含む。  
なお、アプリケーションAPとデータDAは、それぞれユーザが用意し、コンパイラ３１とシミュレータ３２が読み込めるように提供される。
【００３１】
また、ユーザは、アプリケーションAP中に、処理されるデータのデータサイズを定義する。そのため、アプリケーションAPには、処理データのデータサイズの定義情報APDが含まれる。
【００３２】
シミュレータ３２によるシミュレーション処理の後、デバッグ及びプロファイル処理３３によって、シミュレーションの結果として得られた種々のデータの履歴等の情報が、デバッグ及びプロファイル情報として、出力される。
【００３３】
さらに、トレース情報解析処理部３４は、シミュレーションの結果得られたトレース情報を解析するトレース情報解析処理を実行する。トレース情報解析部３４は、後述するような解析処理を実行するプログラムである。
【００３４】
トレース情報解析結果の情報から、プログラム書換部３５により、ユーザのアプリケーションAPの書換処理が実行される。アプリケーションAPがC言語で書かれていれば、プログラム書換部３５は、そのC言語のプログラムを書き換える処理を実行するプログラムである。
【００３５】
さらに、トレース情報の解析結果の情報に基づき、コンフィギュレーション変更部３６は、ユーザコンフィギュレーション情報の変更処理を実行する。コンフィギュレーション変更部３６は、テキストデータであるユーザコンフィギュレーション情報２２の書換、追加等の変更処理を実行するプログラムである。
【００３６】
次に、トレース情報解析部３４、プログラム書き換え部３５及びコンフィギュレーション変更部３６の処理について、アプリケーションAPの例を挙げて説明する。  
図４は、ユーザが作成しプロセッサ上で実行させるアプリケーションAPの例を示す図である。アプリケーションAPは、高級言語の一つであるC言語によって記述されている。
【００３７】
図４のアプリケーションAPの例は、画像データの処理に関わるプログラムであり、２つの配列データA[i][j]とA[i][j+1]のそれぞれに所定の定数I[i]を掛けて、演算結果データを所定のレジスタR[i][j]とR[i][j+1]に登録するというループ処理を行うプログラムである。
【００３８】
ユーザは、ここでは、各配列データは１６ビットデータであると想定してアプリケーションAPを作成しているとする。従って、アプリケーションAPの定義情報APD中には、処理データのデータサイズは、１６ビットであると定義されている。SoCのプロセッサのレジスタのサイズは３２ビットであるとする。このプロセッサのレジスタのサイズは３２ビットであるという情報は、プロセッサコンフィギュレーション情報２１に記述されている。従って、３２ビットのレジスタを２つに分け、並列度が２、すなわち２並列処理により、各配列データの演算処理を実行するように、ユーザはアプリケーションAPを記述している。
【００３９】
図５は、シミュレータ３２により得られたトレース情報の例を示す図である。シミュレータ３２は、図５に示すトレース情報TRを含む各種データをシミュレーションの結果情報として出力する。例えば、図５の１行目では、レジスタ＃１に「0x12」という８ビットの数値が書き込まれたことを示している。
【００４０】
このように、トレース情報TRは、各レジスタにどのようなデータが書き込まれ、すなわちストアされたかというレジスタの挙動を示す情報である。
【００４１】
トレース情報解析部３４は、このトレース情報TRを解析して、アプリケーションAPの実行中における、各レジスタにストアされる処理データのサイズを判定することができる。
【００４２】
そして、プログラム書換部３５は、トレース情報解析部３４において判定された処理データのサイズの情報に基づいて、ユーザの書いたアプリケーションAPの書換処理を実行する。
【００４３】
図６は、トレース情報解析部３４とプログラム書換部３５の処理の流れの例を示すフローチャートである。  
まず、CPUは、トレース情報TRを解析して、アプリケーションAPのシミュレーション処理において使用された１以上のレジスタにストアされたデータのサイズを判定する（ステップS1）。ステップS1の処理が、トレース情報解析部３４を構成する。そして、以下に説明するステップS2からS8の処理が、プログラム書換部３５を構成する。
【００４４】
コンパイラ３１は、アプリケーションAPをコンパイルすると、処理に使用するレジスタを割り当てて決定する。トレース情報TRには、コンパイラ３１により割り当てられた１以上のレジスタにストアされた各データが含まれるので、ステップS1では、その各データのサイズ情報を得る。
【００４５】
次に、CPUは、１以上のレジスタで使用された１以上のデータの中で最大サイズを抽出する、すなわち決定する（ステップS2）。  
そして、CPUは、レジスタの使用サイズと分割数を決定する（ステップS3）。
【００４６】
図５の例では、１行目のlw命令でレジスタ＃１に８ビットの値が格納され、２行目のSIMD命令でレジスタ＃１１に一見２４ビットの値が格納されているように見受けられるが、SIMD命令は通常の命令と異なり、２つのデータを同時に並列的に扱うものであり、２行目の命令は「0xcb」と「0xd8」という２つの８ビットの値を処理するものである。
【００４７】
これらの各レジスタにストアされたデータのサイズを確認し（ステップS1）、その中から最大サイズを抽出すると（ステップS2）、図５に示すトレース情報TRにおいては、最大サイズは８ビットである。
【００４８】
図５に示すトレース情報の場合、アプリケーションAPにおいて使用されるデータは、最大８ビットのデータであるので、例えば、３２ビット処理の場合であれば、３２ビットデータに４つのデータを含ませて、その３２ビットデータを４分割して並列処理することができる。
【００４９】
しかし、ユーザは、実際に処理されるデータの正確なデータのサイズを知らないため、処理されるデータのデータサイズが１６ビットであると考え、その前提の下で、アプリケーションAPを記述している。
【００５０】
ところが、実際の処理データを用いてシミュレータ３２により実行させてみると、使用されるレジスタにストアされるデータの最大サイズは、８ビットである。
【００５１】
そのため、ステップS3では、アプリケーションAPについて、SoCのプロセッサにおいてレジスタの使用サイズは、８ビットと決定される。なお、最大サイズが７ビット、６ビット等であっても、レジスタの使用サイズは、８ビットと決定される。また、最大サイズが９ビット、１０ビット等であれば、レジスタの使用サイズは、１６ビットと決定される。すなわち最大サイズに応じた、８ビット、１６ビット、３２ビット等のデータサイズが、使用サイズとして決定される。
【００５２】
ステップS3で、使用サイズが決定されると、さらに、上述した分割情報２２ａを参照して、レジスタの分割数を決定する。図３の分割情報２２ａによれば、レジスタの使用サイズが８ビットであれば、レジスタは４分割可能であるので、分割数は４と決定される。
【００５３】
そして、そのレジスタの使用サイズにより決定された可能な分割数（以下、可能分割数という）が、当初の分割数、すなわちユーザのアプリケーションAPにおいて定義されたデータサイズにより決定された分割数と同じか否かが判定される（ステップS4）。
【００５４】
当初の分割数は、ユーザのアプリケーションAPの定義情報APDにおけるデータサイズと分割情報２２ａとを参照することによって、決定される。例えば、定義情報APDにおいてデータサイズが１６ビットとして定義されていれば、分割情報２２ａを参照すると、その１６ビットに対して２分割という情報が記述されているので、当初の分割数は、２と決定される。
【００５５】
ステップS3において決定された可能分割数と、当初の分割数とが同じであれば、ステップS4でYESとなって、処理は何もしないで、終了する。
【００５６】
ステップS3において決定された可能分割数と、当初の分割数とが一致しない場合は、ステップS4においてNOとなり、可能分割数が当初の分割数よりも大きいか否かが判定される（ステップS5）。例えば、アプリケーションAPで定義されたデータサイズが１６ビットであるため当初の分割数が２であったが、ステップS3で決定された可能分割数が４であった場合は、可能分割数は当初の分割数よりも大きいと判断される。逆に、アプリケーションAPで定義されたデータサイズが１６ビットであるため当初の分割数が２であったが、ステップS3で決定された可能分割数が１であった場合は、可能分割数は当初の分割数よりも小さいと判断される。
【００５７】
ステップS5でYESの場合、すなわち可能分割数が当初の分割数よりも大きい場合、アプリケーションAP中の定義プログラム部分のデータサイズの定義を変更する（ステップS6）。例えば、分割数が２から４に増加すれば、その分割数４に対応するデータサイズである８ビットに、データサイズの定義情報を変更する。
【００５８】
そして、決定された可能分割数に基づき、アプリケーションAPを書き換える（ステップS7）。アプリケーションAPの書換は、アプリケーションAPがC言語等の高級言語のプログラムであれば、高級言語レベルで書き換えられる。
【００５９】
図７は、書き換えられたアプリケーションAP1の例を示す図である。例えば、上述したように、アプリケーションAPで定義されたデータサイズが１６ビットであるため当初の分割数が２であったが、可能分割数が４であった場合、データは８ビットであるため、その分割数に応じた４並列処理のアプリケーションAP1に変更される。
【００６０】
すなわち、処理されるデータを用いてシミュレーションを実行した結果、プロセッサ内のレジスタは、ユーザが当初想定していたデータサイズ（１６ビット）よりも小さい８ビットデータであったので、２並列処理よりも処理速度が速い４並列処理のプログラムになるように、アプリケーションAPが書き換えられる。
【００６１】
例えば、予め分割数に応じた並列処理のプログラムパターンを用意しておき、並列度に応じたパターンを選択することによって、アプリケーションAPの書換処理を実現することができる。
【００６２】
また、ステップS5でNOの場合、すなわち可能分割数が当初の分割数よりも小さい場合、アプリケーションAP中の定義情報APDのデータサイズの定義を変更する（ステップS8）。例えば、分割数が２から１に減少すれば、その分割数１に対応するデータサイズである３２ビットに、データサイズの定義情報を変更する。
【００６３】
図５の後半の例が可能分割数が当初の分割数よりも小さい場合の例である。４行目のlw命令でレジスタ＃２に１６ビットを超過した１７ビットの値が格納されている。５行目のSIMD命令でプログラム作成者は当初、レジスタ＃８に１６ビットの値を２つ格納し同時に並行処理をさせるつもりであったが、「0x10000」が格納された後、別の「0xa2c」を格納した際、上位ビットが上書きされてしまった状態が示されている。データの型を指定する高級言語でプログラム作成した場合は通常コンパイラがエラー検出をするが、アセンブリ言語でプログラムを作成した場合に、多々見受けられるものである。このような場合は分割数を小さくすることが必要である。
【００６４】
そして、処理は、図８のコンフィギュレーション変更部の処理に移行する。図８は、コンフィギュレーション変更部３６の処理の流れの例を示すフローチャートである。  
ステップS8の後、ユーザコンフィギュレーション情報２２中のコアブロック数を増やすように、コアブロック数の変更を行う（ステップS11）。ステップS5において可能分割数が当初の分割数よりも小さい場合は、コアブロックの数を増やすように、ユーザコンフィギュレーション情報２２が変更される。ステップS11の処理が、コンフィギュレーション変更部３６を構成する。
【００６５】
例えば、アプリケーションAPで定義されたデータサイズが１６ビットであるため当初の分割数が２であったが、可能分割数が１であった場合は、可能分割数では並列処理が実行できないことになる。そこで、ステップS5において可能分割数が当初の分割数よりも小さい場合は、コアブロックの数を増やして、ここでは、例えばコアブロック数を２倍にして、２倍の並列処理が実行されるように、ユーザコンフィギュレーション情報２２が変更される。その後、処理は、図６のステップS6に移行する。
【００６６】
なお、ステップS11の処理の後、処理は、ステップS6の処理に自動的に移行してもよいが、ユーザコンフィギュレーション情報２２の中の変更されるコアブロック数の情報を表示装置１２の画面上に表示させて、一旦ユーザにその変更内容を確認させてから、ステップS6の処理へ移行するようにしてもよい。
【００６７】
ステップS11の後、ステップS6に戻ると、アプリケーションAP中の定義情報APDのデータサイズの定義を変更する（ステップS6）。例えば、分割数が２から１に減少すれば、その分割数１に対応するデータサイズである３２ビットに、データサイズの定義を変更する。
【００６８】
そして、変更されたコアブロック数と可能分割数に基づき、アプリケーションAPを書き換える（ステップS7）。例えば、ここでは、コアブロック数は、１から２に変更されたので、２つのコアブロックを用いて並列処理が実行されるように、アプリケーションAPがアプリケーションAP2に書き換えられる。
【００６９】
図９は、その書き換えられたアプリケーションAP2の例を示す図である。例えば、上述したように、アプリケーションAPで定義されたデータサイズが１６ビットであるため当初の分割数が２であったが、可能分割数が１であった場合、データは３２ビットであるため、ブロック数を増やす処理が実行された。その結果、倍になった２つのコアブロックを用いて並列処理が行われるので、アプリケーションAPは、そのコアブロック数に応じた並列処理のアプリケーションAP2に変更される。
【００７０】
すなわち、処理されるデータを用いてシミュレーションを実行した結果、プロセッサ内のレジスタは、ユーザが当初想定していたデータサイズ（１６ビット）よりも大きい３２ビットデータであったので、２つのコアブロックを用いた並列処理プログラムになるように、アプリケーションAPが書き換えられ、アプリケーションAP2に変更される。
【００７１】
そして、可能分割数が、当初の分割数と異なる場合、ステップS7の処理に続いて、トレードオフ情報の表示が行われる（ステップS9）。トレードオフ情報とは、ステップS6、S7、S11におけるアプリケーションAP又はユーザコンフィギュレーション情報２２の変更に起因する、消費電力、チップ面積等のパラメータに関する情報である。ステップS9は、ユーザコンフィギュレーション情報２２の変更に起因するプロセッサの所定のパラメータ情報を出力するパラメータ情報出力部を構成する。
【００７２】
上述したように、アプリケーションAP又はユーザコンフィギュレーション情報２２の書き換えが行われた結果、アプリケーションAP1とAP2では、処理の並列度は上がるので、処理性能は書換前のプログラムAPよりも高くなる。しかし、ユーザコンフィギュレーション情報２２が変更されてコアブロック数が増えた場合、SoCのチップの消費電力は増加するというデメリットが生じ得る。さらにコアブロック数が増えると、SoCのチップ面積も大きくなるというデメリットも生じ得る。
【００７３】
よって、ユーザに、アプリケーションAP又はユーザコンフィギュレーション情報２２の書換後におけるSoCのチップの消費電力、回路面積等の増加の情報を、提示することにより、アプリケーションAP又はユーザコンフィギュレーション情報２２の書換の承認あるいは確認をさせるために、ステップS9において、トレードオフ情報が表示される。
【００７４】
もしも、消費電力の上昇が許されないならば、ユーザは、トレードオフ情報を見て、元のアプリケーションAPと、元のユーザコンフィギュレーション情報２２に基づき生成された設計情報を用いるようにすることができる。
【００７５】
例えば、上述した例であれば、アプリケーションAPで定義されたデータサイズが１６ビットであるため当初の分割数が２であったが、可能分割数が４であった場合、アプリケーションAPが書き換えられ、並列度が高くなり処理性能は高くなるが、ハードウェア構成に変更はなく、ソフトウェアの変更だけである。よって、その場合、アプリケーションAPの書換の前後で、消費電力は変化はなく、かつSoCのチップ面積も変化しない、ということを示すトレードオフ情報が、ユーザに提示される。この提示は、表示装置１３の画面上へのテキスト表示により行われる。
【００７６】
逆に、アプリケーションAPで定義されたデータサイズが１６ビットであるため分割数が２であったが、可能分割数が１であった場合、上述したように、ユーザコンフィギュレーション情報２２とアプリケーションAPが書き換えられ、並列度が高くなり処理性能は高くなるが、ハードウェア構成に追加的な変更がある。よって、その場合、上述した例であれば、コアブロック数が２に増えるため、アプリケーションAPの書換後の消費電力は、アプリケーションAPの書換前よりは増加し、かつSoCのチップ面積も増加する、ということを示すトレードオフ情報が、ユーザに提示される。
【００７７】
以上のように、構成変更可能なプロセッサの設計において、データサイズに応じた構成変更があった場合に、その変更後のスペックの一部であるトレードオフ情報を、ユーザに提示する。この提示を受けることにより、ユーザは、変更後のスペックが許容できるか否かを判断することができる。
【００７８】
なお、上記のトレードオフ情報は、定量的な情報を含むようにしてもよい。例えば、１コアブロック当たりの推定される消費電力量とチップ上の占有面積の情報を予め記憶装置に登録しておき、コアブロック数の増加量に応じた消費電力量と面積の増加分の情報を、数値で、ユーザに提示する。このようにすれば、ユーザは、より詳細なトレードオフ情報に基づいて、変更後のスペックが許容できるか否かを判断することができる。
【００７９】
さらになお、上述した例では、並列度を高くするように、アプリケーションAPが書き換えられているが、アプリケーションAPをデータサイズに応じた専用命令のプログラムに書き換えるようにしてもよい。例えば、特定の処理ルーチンの場合は、専用の命令を定義し、専用命令実行回路にて実行可能なように、ハードウェアを変更するようにしてもよい。そのような場合に、トレードオフ情報の出力も可能である。
【００８０】
以上のように、上述した本実施の形態に係る設計装置は、構成変更可能なプロセッサを設計するに際に利用され、アプリケーションが処理するデータを用いてシミュレーションした結果得られたトレース情報から、ユーザの定義したデータサイズから決定される分割数が適切か否かを判定する。そして、設計装置は、その分割数が適切でないときには、並列度を上げるようにアプリケーションAPを書き換え、さらに必要であれば、ユーザのコンフィギュレーション情報も書き換えるようにした。
【００８１】
従って、上述した実施の形態に係る構成変更可能なプロセッサの設計装置及びその設計方法によれば、プロセッサ上で実行されるアプリケーションプログラムの処理するデータに応じて、アプリケーションプログラムの並列度を向上させることができる。  
設計装置１によれば、データサイズに応じたアプリケーションプログラムの最適化が行われ、結果として、システム全体として、処理速度性能を上げることができる。  
さらに、アプリケーションAP等の書き換えがあった場合には、トレードオフ情報をユーザに提示するようにしたので、ユーザは、システム全体のコストと性能のトレードオフも考慮して、プロセッサを設計することができる。
【００８２】
なお、以上説明した動作を実行するプログラムは、コンピュータプログラム製品として、フレキシブルディスク、ＣＤ−ＲＯＭ等の可搬媒体や、ハードディスク等の記憶媒体に、その全体あるいは一部が記録され、あるいは記憶されている。そのプログラムのコード部がコンピュータにより読み取られて、動作の全部あるいは一部が実行される。あるいは、そのプログラムの全体あるいは一部を通信ネットワークを介して流通または提供することができる。利用者は、通信ネットワークを介してそのプログラムをダウンロードしてコンピュータにインストールしたり、あるいは記録媒体からコンピュータにインストールすることで、容易に本発明の設計装置及び設計方法を実現することができる。  
本発明は、上述した実施の形態に限定されるものではなく、本発明の要旨を変えない範囲において、種々の変更、改変等が可能である。
【図面の簡単な説明】
【００８３】
【図１】本発明の実施の形態に係わる構成変更可能なプロセッサの設計装置の構成を示す構成図である。
【図２】本発明の実施の形態に係わる、構成変更可能なプロセッサの設計の流れを説明するための図である。
【図３】本発明の実施の形態に係わる、分割情報の例を示す図である。
【図４】本発明の実施の形態に係わる、ユーザが作成しプロセッサ上で実行させるアプリケーションプログラムの例を示す図である。
【図５】本発明の実施の形態に係わる、シミュレータにより得られたトレース情報の例を示す図である。
【図６】本発明の実施の形態に係わる、トレース情報解析部とプログラム書換部の処理の流れの例を示すフローチャートである。
【図７】本発明の実施の形態に係わる、書き換えられたアプリケーションプログラムの例を示す図である。
【図８】本発明の実施の形態に係わる、コンフィギュレーション変更部の処理の流れの例を示すフローチャートである。
【図９】本発明の実施の形態に係わる、書き換えられたアプリケーションプログラムの他の例を示す図である。
【符号の説明】
【００８４】
１  設計装置、１１  コンピュータ本体、１２  表示装置、１３  記憶装置
【図１】
2009271599.tif 000003
【図２】
2009271599.tif 000004
【図３】
2009271599.tif 000005
【図４】
2009271599.tif 000006
【図５】
2009271599.tif 000007
【図６】
2009271599.tif 000008
【図７】
2009271599.tif 000009
【図８】
2009271599.tif 000010
【図９】
2009271599.tif 000011