以下、本発明の実施の形態を図面に基づいて説明する。図1は、本実施例に係る全体フローを示す図である。図1において、ステップS10及びS11の処理によるトレースデータ取得工程Aは、開発中のLSIのシミュレーション中にトレースデータを取得する工程であり、後段の再シミュレーション工程Bの準備に相当する。
ステップS10では、シミュレーション実行中においてトレースデータを取得するための記述を開発中のLSI用のプログラムに追加しておく。そして、シミュレーションを実行する(ステップS11)。シミュレーションを行う動作環境として、例えば、ソフトウェアによるシミュレーション方法、実機試験による方法、FPGA(Field Programmable Gate Array)ボードを利用する方法などがあり、それらいずれの方法であっても良い。
このシミュレーションによる結果としてトレースデータ40が出力される。トレースデータ40には、機能トレースデータ41と、VFトレースデータ42とが含まれる。各トレースデータについては後述される。
ステップS12からS15の処理による再シミュレーション工程Bでは、トレースデータ取得工程Aで出力されたトレースデータ40を用いて、シミュレーション中の所定機能を実行する各プロセス及びハードウェアモジュールに関して、同期及び時間とからシーケンス図を生成する(ステップS12)。その際、実行中のプロセス及びモジュールに係る電気的特性を電力ライブラリ45から取得する。そして、各状態に電気的特性を関連付けて、ソフトウェア状態とハードウェア状態とをシーケンス図で表示する。
ユーザよりパラメータ値の変更要求があったか否かを判断する(ステップS13)。パラメータの変更要求がない場合には、この処理を終了する。パラメータの変更要求があった場合には、ユーザからパラメータ値を取得して変更し、パラメータ変更データ47として出力する(ステップS14)。
そして、トレースベースシミュレーションを行い、パラメータ変更を反映したトレースデータ40を生成する(ステップS15)。トレースデータ40を用いて、かつ、変更されたパラメータ値を反映して、シミュレーションが行われる。この場合、必要最小限の機能を持ったOSモデル50と、割り込みハンドラ記述51と、アーキ記述52とを用いて簡易的なシミュレーションが実行される。そのシミュレーション実行結果によって、トレースデータ40が更新され、必要に応じて、ステップS12からS15が繰り返される。
以下に、シミュレーション環境の構成例について例示する。
[第一構成例]
図2は、シミュレーション環境の第一構成例を示す図である。図2では、シミュレーションソフトウェア2aとして、ISS(Instruction Set Simulator)2bと、これに必要な周辺モデル2c及びメモリモデル2dのみが組み込まれた例を示したが、他のハードウェア構成部品が含まれていてもよい。通例、シミュレーション環境を起動して、必要なデータをシミュレーション環境に渡して、シミュレーションが開始される。
図1で説明したトレースデータ取得工程AにおけるステップS11のシミュレーションは、少なくともCPUと、メモリと、記憶装置とを有するコンピュータによって、以下のステップS20からS22の手順で実行される。
コンピュータは、メモリ又は/及び記憶装置(以下、単に記憶領域という)にシミュレーションソフトウェア2aと、開発された検証対象のOS2e及びアプリケーションソフトウェア2fとを格納している。
コンピュータは、シミュレーションソフトウェア2aを起動し(ステップS20)、検証対象のOS2e及びアプリケーションソフトウェア2fをメモリモデル2d上にロードする(ステップS21)。そして、コンピュータは、シミュレーションを実行することによって(ステップS22)、トレースデータ40が記憶領域に出力される。その後、コンピュータは、図1の再シミュレーション工程Bを実行する。
図3は、シミュレーション環境の一般的な利用例を示す図である。図3では、シミュレーション環境を提供するシミュレーションソフトウェア2aと、アプリケーションソフト2fをデバッグするデバッガソフトウェア3aとによって、デバッグシステム3が構成された例を示している。シミュレーションソフトウェア2aとデバッガソフトウェア3aとの間ではプロセス間通信が行われる。
このような環境でトレースデータをとる方法として、ISS2bや周辺モデル2cはPCネイティブのコードを生成するソフトウェアとして記述する。たとえば、PCとこの上で実行されるWindows(登録商標)上で動作させるソフトウェアとして記述される。従って、トレースデータをとりたい関数があれば、その関数の中にデータをファイルに書き込む関数などを入れておけば、トレースデータを取得することができる。
一方、ISS2bにロードされるソフトウェア(OS2eやアプリケーションソフトウェア2f)の関数の中でトレースデータをとる方法としては、周辺モデル2cとしてトレースデータをダンプするトレース部品を実装する方法がある。ある特定アドレスを非キャッシュ対象にし、このアドレスへの書き込みがあった時、トレース部品にデータを渡し、トレース部品は時間とデータをファイルに書き出す。
上記ではダンプすべきデータをトレース部品に送るとしたが、コマンドを送るとしてもよい。トレース部品はコマンドをパーズしそれに見合った処理を行う。例えば、ISS2b上のソフトウェアからトレース部品に対して、ダンプしたいメモリの開始アドレスと終了アドレスを送る。トレース部品は該当のデータをメモリモデル2dよりファイルにコピーする。このようにすればメモリのスナップショットを適宜ダンプすることが可能になる。
デバッガソフトウェア3aとシミュレーションソフトウェア2aとによるデバッグシステム3は、図4に示されるようなコンピュータにて動作する。図4は、コンピュータのハードウェア構成を示す図である。図4において、コンピュータ100は、CPU(Central Processing Unit)11と、メモリユニット12と、表示ユニット13と、出力ユニット14と、入力ユニット15と、通信ユニット16と、記憶装置17と、ドライバ18とを有し 、システムバスBに接続される。
CPU11は、メモリユニット12に格納されたプログラムに従ってコンピュータ100を制御する。メモリユニット12には、RAM(Random Access Memory)及びROM(Read-Only Memory)等が用いられ、CPU11にて実行されるプログラム、CPU11での処理に必要なデータ、CPU11での処理にて得られたデータ等を格納する。また、メモリユニット12の一部の領域が、CPU11での処理に利用されるワークエリアとして割り付けられている。
表示ユニット13は、CPU11の制御のもとに必要な各種情報を表示する。出力ユニット14は、プリンタ等を有し、ユーザからの指示に応じて各種情報を出力するために用いられる。入力ユニット15は、マウス、キーボード等を有し、ユーザがコンピュータ100が処理を行なうための必要な各種情報を入力するために用いられる。通信ユニット16は、例えばインターネット、LAN(Local Area Network)等に接続し、外部装置との間の通信制御をするための装置である。記憶装置17には、例えば、ハードディスクユニットが用いられ、各種処理を実行するプログラム等のデータを格納する。
コンピュータ100によって行われる処理を実現する上述したようなデバッガソフトウェア3aとシミュレーションソフトウェア2aの夫々に係るプログラム等は、例えば、CD−ROM(Compact Disc Read-Only Memory)等の記憶媒体19によってコンピュータ100に提供される。即ち、プログラムが保存された記憶媒体19がドライバ18にセットされると、ドライバ18が記憶媒体19からプログラムを読み出し、その読み出されたプログラムがシステムバスBを介して記憶装置17にインストールされる。そして、プログラムが起動されると、記憶装置17にインストールされたプログラムに従ってCPU11がその処理を開始する。尚、プログラムを格納する媒体としてCD−ROMに限定するものではなく、コンピュータが読み取り可能な媒体であればよい。本実施例に係る処理を実現するプログラムは、通信ユニット16によってネットワークを介してダウンロードし、記憶装置17にインストールするようにしても良い。また、USB対応のコンピュータ100であれば、USB接続可能な外部記憶装置からインストールするようにしても良い。更に、SDカード等のフラッシュメモリ対応のコンピュータ100であれば、そのようなメモリカードからインストールするようにしても良い。
[第二構成例]
図5は、実機ボードを利用する場合のシミュレーション環境の第二構成例を示す図である。図5に示す第二構成例では、コンピュータ4aと実機ボード4cが接続された構成例を示している。実機ボード4cは、実CPU4dと、ログエリア4hを含むメモリ4eと、コンピュータ4aと接続するためのインターフェイス4fとを有し、バス4gで相互に接続される。
コンピュータ4aは、図4に示すコンピュータ100と同様のハードウェア構成を有し、実機ボード4cを制御してデバッグを行うための制御ソフトウェア4bを実装している。
このような環境では、OSによるタスクスイッチのトレース等を実機ボード4cからコンピュータ4aに読み出して、記録する方法がとられる。更に、専用のプリント文を利用してメモリの中に確保したログエリア4hに記録しておき、制御ソフトウェア4bによってこのデータを読み出してコンピュータ4aのメモリ又は記憶装置の記憶領域にトレースデータ40として記録することができる。このようなシミュレーション環境の一構成例は、非特許文献1の5節に示されている。
[第三構成例]
図6は、FPGAボードを利用する場合のシミュレーション環境の第三構成例を示す図である。図6に示す第三構成例では、コンピュータ5aとFPGAボード5cが接続された構成例を示している。FPGAボード5cを例示しているが、ハードウェアエミュレータを利用した場合も同様である。また、実機ボード4cが接続された第二構成例と同様の仕組みでもよい。
FPGAボード5cにはFPGA5dが実装され、FPGA5dは、コンフィギュレーションによりCPU5fとメモリ5gとバス5hが構成されたDUV(Design Under Verification)回路部5eと、DUV回路部5eを動作させるためのクロック制御部5kと、コンピュータ5aと接続するためのインターフェイス5tとを有する。
また、FPGAボード5cでは、追加の回路を搭載することが可能であるため、更に、ログメモリ5qと、CPU5fの内部データを参照してログメモリ5qに書き込むログ書き込み回路5pとを有するように構成する。このような構成によって、欲しいデータを参照し、参照したデータをログメモリ5qに書き込み、そのデータをコンピュータ5aに送ることができる。
コンピュータ5aは、図4に示すコンピュータ100と同様のハードウェア構成を有し、FPGA回路部5eを制御してデバッグを行うための制御ソフトウェア5bを実装している。制御ソフトウェア5bによって、コンピュータ5aからログメモリ5qのデータを抽出し、コンピュータ5aのメモリ又は記憶装置の記憶領域にトレースデータ40として記録することができる。
シミュレーションソフトウェア2aを利用した第一構成例、実機ボード4cを利用した第二構成例、FPGAボード5cを利用した第三構成例のいずれの場合に関しても、トレースのデータをとる機構を用意することが可能である。
[取得データ]
次に、図1のトレースデータ取得工程Aにて取得されるトレースデータ40の内容について説明する。これは、CPUの構成によることもある。ここでは2つのCPU構成例を挙げて、必要なデータを定義する。
[マルチCPUにおける取得データ]
図7は、ターゲットがマルチCPUである場合のCPU構成例を示す図である。図7では、ターゲットとして、CPU0、CPU1、CPU2、及びCPU3が構成されたハードウェア構成例を示している。この構成例におけるソフトウェアアーキテクチャの例を図8で例示する。
図8は、図7のCPU構成例におけるソフトウェアアーキテクチャ例を示す図である。図8では、Kahn Process Networkでソフトウェアプロセスを定義した例である。プロセス0とプロセス1、2、3、及び4のプロセス間はチャネル7aで接続され、プロセス1、2、3、及び4とプロセス5のプロセス間はチャネル7bで接続されている。
このチャネルの記述例を図9に示す。図9は、図8に示すプロセス間のチャネル記述例を示す図である。図9では、プロデューサ・コンシューマ関係で1:1接続しており、セマフォを利用した例を示している。このサンプルプログラムは、Linux上で作成しており、Linuxの標準のpthreadとsemaphore(セマフォ)を使った記述になっている。セマフォはマルチスレッド(マルチタスク)制御に一般的に使われるものであり、リアルタイムOSなどにも組み込まれている機構である。
リアルタイムOSでは、ITRON4.0の場合、メッセージパッシングではデータキューやメールボックスといったOSのサービスを利用するのが一般的である。この場合も、図9のsem_wait、sem_postのようにOSのディスパッチャ、シグナル命令の発行を伴うような関数などOSのスケジューリングを変更する要因を含む関数にトレース関数を入れることになる。このような記述の代表例として、図10を使って説明する。
図10は、ソフトウェア構造をpthreadを使って記述したメイン関数のプログラム例を示す図である。図10に示すメイン関数の記述例では、プロセス0から5がpthreadによって生成される例が示されている。
図11は、図8のプロセス0に対応するプログラム例を示す図である。図11に示すプログラム例では、プロセス0はデータを生成する。ここでは、各チャネルに偶数番目には2を、奇数番目には0から10の値を、チャネル0から3に各々書く処理である。
図12は、図8のプロセス5に対応するプログラム例を示す図である。図12に示すプログラム例では、プロセス5はデータを出力する。プロセス1〜4より結果を受け取って各々の値と合計値を標準出力する処理である。
図13〜図14は各プロセス1〜4に対応している。図13は、図8のプロセス1に対応するプログラム例を示す図である。図14は、図8のプロセス2に対応するプログラム例を示す図である。図15は、図8のプロセス3に対応するプログラム例を示す図である。図16は、図8のプロセス4に対応するプログラム例を示す図である。
図13〜図16において、プロセス1〜4は、いずれも、チャネルより偶数番目と奇数番目の値を取り出して、power_functionまたはpower_function2の第一引数に偶数番目のデータを、第二引数に奇数番目の値を渡している。これらの関数の詳細を図17に示す。
図17は、関数のプログラム例を示す図である。図17において、power_functionは、第一引数を底とし第二引数を指数とする指数計算を行うことがプログラムされている。また、power_function2は、第一引数を底とし第二引数+1を指数とする指数計算を行うことがプログラムされている。
図18は、図11から図17に示すプログラムを実行した結果を示す図である。図18では、プロセス1〜4の各々の値と合計値が、1回の処理毎に出力された例が示されている。このような処理を実行した際のCPUのパフォーマンスが図19で示されている。
図19は、ファイルにリダイレクトした場合の性能表示例を示す図である。図19において、プロセス毎の情報を取得するためのPSコマンド及び現在実行中のプロセスの情報を取得するためのTOPコマンドによる性能表示例が示されている。また、並列に動作させることができており、CPUの使用率19aは340%であることを示している。図19では、ファイルにリダイレクトする標準出力の場合の性能を示しているが、リダイレクトしなかった場合の性能は、図20のように示される。
図20は、ファイルにリダイレクトしなかった場合の性能表示例を示す図である。図20において、PSコマンド及びTOPコマンドによる性能表示例が示されている。標準出力しなかった場合にはCPUの使用率20aは250%台になり、4つのスレッドは20%台まで落ち込む。プロセス5の計算時間がかかっていると予想できる。
従って、理想的には、プロセス0及び5はCPUを占有、プロセス1〜4は60%ぐらいの実行速度とし、電圧を下げて低電力化することが望ましいと考えられる。本発明はこのような検討をより詳細に行うためのものである。
次にOSについて説明する。OSの実装はいろいろあるが、ここでは非特許文献2を例に説明する。非特許文献2ではセマフォの基本概念とそれをサポートするOSの機能について説明されている。セマフォは通例P命令及びV命令を持つ。P命令及びV命令はLinuxのセマフォではそれぞれsem_wait関数、semp_post関数に相当する。
非特許文献2の2章で想定するOSでは、プロセスの状態遷移は図21に示すようになる。図21は、プロセスの状態遷移を示す図である。プロセスには「待ち状態」、「実行可能状態」、及び「実行状態」の3つの状態がある。SIGNAL命令を受けることによって、プロセスは「待ち状態」から「実行可能状態」へと遷移する。「実行可能状態」のプロセスは、CPUが割り当てられると処理を実行する「実行状態」となり、処理終了によってCPUが解放されると「実行可能状態」へと戻る。又は、「実行状態」のプロセスが、WAIT命令を受けると「待ち状態」へと遷移する。
図21では、プロセスの基本的な状態遷移を示すものである。OSは複数のプロセスを扱いもっと複雑な遷移をする。プロセスやスレッド(軽量プロセス)のCPU割り当てや解放なども行う。
このような状態遷移を実現するのは、OSのスケジューリング機能による。図22は、プロセス情報の管理例を示す図である。OSの中では図22のように待ち行列、実行可能列、実行中のステートがあり、実行中のプロセスがWAIT命令を呼び待ち行列に入る、SIGNAL命令により、プロセスを実行可能列により入れる、ディスパッチャにより、実行可能列のうち最も優先度が高い実行可能列の先頭のプロセスを実行中に移す、クオンタムが終了したプロセスをそのプロセスの優先度の実行可能列の末尾に追加し、CPUを解放する処理をする。
また、非特許文献2の第3章5節には「P命令、V命令、ディスパッチャの実現」が解説されている。このOSでは同期機構はセマフォのみであり、P関数(P命令に対応、WAIT命令)、V関数(V命令に対応、SIGNAL命令)、クオンタム終了時によばれるINTERVAL_TIMER_INTERRUPT関数がある。従って、P関数、V関数、INTERVAL_TIMER_INTERRUPT関数にトレース関数を記述することにより、図22の各行列間をプロセスがどのように動くかを再現できるトレースデータを取得することができる。また、非特許文献2では、CPUごとにCPUのID番号をもつ特殊なレジスタをもち、OSはどのCPUで起きた事象かを把握している。
従って、OSの関数にトレースを出力する記述の追加(図1に示す全体フローのステップS10における「トレースデータを取得するための記述を追加」し、第一構成例〜第三構成例のような環境で実行(全体フローのステップS11における「シミュレーション(FPGAボード含む)/実機試験」を実行)することにより、機能トレースデータ41(図1)を生成できる。
例えば、トレースデータを取得するための記述が非特許文献2に基づくOSで実行されたとすると、図23のようなデータを作成することができる。図23は、機能トレースデータ例を示す図である。図23では、プロセスは簡単のためスレッドID(LWP ID)の代わりにプロセス名を、セマフォのID番号の代わりに変数名で表している。
また、電圧、周波数のトレースであるDVトレースデータを作成する。周波数や電源制御する関数があって、これがコールされて変わる仕様であればこれらの関数にトレースデータを取得する記述を追加しておくことによって、取得可能である。もし、このような機能がない場合には初期値を入れる。ここでは後者の場合だったとし、電圧の変更イベントと周波数とをトレースしたVFトレースデータ例を図24に示す。図24は、VFトレースデータ例を示す図である。
一般のリアルタイムOSではメールボックスなどの同期機構があるが、ここでは、非特許文献2に合わせてセマフォを使った例で示す。セマフォは共有リソース管理の一般的な例であり、メールボックス等の関数でも何らかの排他制御がなされているはずである。従って、同様の拡張により対応可能である。
[機能ブロック混在型の回路構成における取得データ]
ASIC(Application Specific Integrated Circuit)やASSP(Application Specific Standard Product)の場合には、通例、CPUとハードウェアで実現した機能ブロック(以下、HWブロックと言う)が混在したSoC(System on Chip)がある。また、CPUとHWブロック間の通信は規格化されていない。しかし、CPUとHWブロック間の通信機構は存在する。従って測定対象が決まればCPUとHWブロック間の通信が決まり、とるべきデータが決まる。
ここでは、例として、通信の一例が示せるような簡単な構成例で説明する。図26のようなタスクパイプラインを構成したい場合を考える。HW/SW分割において、ヘッダの解析はCPUで行い、2つの処理をHWブロックで処理させるとする。図25はこれを実現するためのアーキテクチャ例である。
図25は、ターゲットが機能ブロック混在型である場合の回路構成例を示す図である。図25に例示されるターゲット回路24cには、割り込みキュー(IRQ)24qを有するCPU24dと、メモリ22a及び設定レジスタ22bを有するHWブロック1と、メモリ23a及び設定レジスタ22bを有するHWブロック2と、タイマー24kと、割り込みとなる状態を対応するビットで管理し割り込みキュー24qにキュー待ちさせる割り込み要因レジスタ24pと、実機ボード24cを検証するコンピュータ4a(図5)と接続するためのインターフェイス24fとが実装され、バス24gを介して相互に接続される。
シミュレーションやFPGAボードを利用する場合には、ターゲット回路24cとテストベンチをつなげて実行する。実機ボードの場合には該当の回路が搭載されている。
図26は、タスクのパイプライン構成例を示す図である。図26において、主なタスクとして、CPU24dによって行われるヘッダの解析、HWブロック1の処理、HWブロック2の処理があり、時間T0でCPU24dによるData1のヘッダの解析が行われた後は、時間T1でHWブロック1によってData1の処理が行われ、次に、時間T2でHWブロック2によってData1の処理が行われるように構成される。以降、Data2、Data3、Data4、Data5等についても同様の手順で処理される。
割り込み要因レジスタ24pのレジスタマップは、図27のように定義されるものとする。図27は、レジスタマップの例を示す図である。図27に示すレジスタマップでは、割り込み要因レジスタ24pのビット0、1、2をHWブロック1の各状態に割り当て、ビット3、4、5をHWブロック2の各状態に割り当て、ビット6をコンピュータ4aとのインターフェイスの終了に割り当てている。
割り込み要因レジスタ24p中に1ビットでも1が立っていたら割り込み信号がレベル信号としてCPU24dに送られる。また、CPU24dが定期的にヘッダ解析をするため、タイマー24kが実装されているとする。これは割り込み要因レジスタ24pが発生させる割り込み信号とは別にある構成とする。
HWブロック1、HWブロック2は設定レジスタ22b、23b中の起動レジスタに1を書くことで始まるようになっているとする。実行中1であり、何らかの要因で終了した際に0クリアされるようになっているとする。
概念的には図26のようなタスクパイプラインが行われるように図25に示されるような回路構成を設計したが、実際には図28のように動いたとする。図28は、シーケンス例を示す図である。図28において、CPU24dがインターフェイス24fからData1を取得してから、Data1がHWブロック1による処理、そして、HWブロック2による処理が終了するまでのシーケンスを例示している。図28では、CPU24dは、Data1のヘッダ解析を終了すると、次のData2を取得してヘッダ解析をおこなっており、HWブロック1によるData2の処理中に、HWブロック2によるData1の処理が行われている。
このようなシーケンスにおいて、CPU24dとHWブロック1及び2との間の通信ログをとることを考える。そこで、要因レジスタの値の変化、タイマーイベントの値セットイベントと発火イベント、HWブロックの起動イベントの発生のログをとれば、図29のようなトレースデータを生成することができる。図29は、機能トレースデータ例を示す図である。
図29に示す機能トレースデータ41では、各種イベントが発生した時刻毎に、その時刻に対応させて、割り込み要因レジスタ24pの値を示す要因レジスタ値、タイマーイベント、HWブロック1の起動イベント、HWブロック2の起動イベント、イベントが発生した要因、プロセス、イベントによって動作したCPUのID、そのCPUのイベント後の状態、セマフォ、そのセマフォ値等が記録されている。
また、VFトレースデータ42については、図7に示すマルチCPUの場合と同様に、電源制御、周波数制御は行われなかったとし、VFトレースデータ例を図30に示す。図30は、VFトレースデータ例を示す図である。
図30に示すVFトレースデータ42では、ブロック毎に電圧の変更イベントと周波数とが、初期設定として、時刻「0」で設定されている。例えば、CPU24d、HWブロック1、HWブロック2、共有メモリ24e、インターフェイス24fの各ブロックに対して、1.2[V]から1.2[V]への電圧変更、及び、0[MHz]から100[MHz]への変更が示される。
図29に示す機能トレースデータ41と、図30に示すVFトレースデータ42とは、シミュレーション環境の図2に示す第一構成例及び図6に示す第三構成例において取得可能である。
上述した各種トレースデータ例では、HWブロックに関して、処理のきっかけのみに着目したデータをとったが、後述のタスクの実行時間に関しては、バス競合の待ち時間情報もとればより精度を上げることができるかもしれない。ダブルバッファにするなどしてバス競合がHWブロックの機能の実行をストールさせないようにしている場合には、ストール条件を監視する必要がある。
以下、図25に例示される機能ブロック混在型の回路構成を基本として説明する。一方、後述の再シミュレーション(トレースベースシミュレーション)においては図7に例示されるマルチCPUについても説明する。
[電力ライブラリ]
電力ライブラリ45の作成方法は種々考えられる。本実施例で何らかの方法で作成した以下のデータを電力ライブラリ45として入力された場合を例に説明する。ここでは1つの論理合成シナリオに基づいた結果が入力されたケース(以下、Tech1として示す)を示すが、複数入力して論理合成シナリオ間のトレードオフ(テクノロジ間の違いや使用セルセットの違いなど)を評価するとしてもよい。
電力ライブラリ45には、ブロックごとの電圧とクリティカルパス遅延の相関を示す電圧・遅延相関データ、ブロックごとの時間計算式と充電時間・放電時間データ、容量データ、動的電力データなどが含まれる。
図31は、電圧・遅延相関データ例を示す図である。図31に示す電圧・遅延相関データ45は、ブロック毎に用意される。もし、条件によりクリティカルパスが変わる場合には複数の相関データを用意しておく。また、マルチクロックドメインでクロックの乗り換えが実装されている場合には、クロックドメインごとに算出する。クロックドメイン間のクロック周波数に制約がある場合にはその式を含める。実施例ではシングルクロックの場合を説明する。また、常時動いている部分(例:設定レジスタ。揮発防止のため切らないRAMは含まない)とブロック全体のクリティカルパス遅延が求められた場合を説明する。
図32は、放電時間データ例を示す図である。また、図33は、充電時間データ例を示す図である。図32に示す放電時間データ46と図33に示す充電時間データ47とは、ブロック毎に用意され、ある電圧から任意の電圧に変更されるまでの時間を示している。例えば、HWブロック1に関して、各々の線形近似した放電時間データ46及び充電時間データ47は、n[V]からm[V]にする関数が、
F(充電時間データ, 放電時間データ, m, n)= if (m > n)
then (充電時間データによるm[V]にする時間
― 充電時間データによるn[V]にする時間)
else (放電時間データによるn[V]を0[V]にする時間
― 充電時間データによるm[V]を0[V]にする時間)
end
で与えられたとしたら、前記の条件(m>n)を満たす。以下、この例で説明する。もちろん、これ以外であっても条件を満たすデータと計算式が定義されればよい。
例えば、このHWブロック1を1つの電源ドメインとした場合、容量データが図34のように示される。図34は、容量データ例を示す図である。図34に示す容量データ48は、ブロック毎に容量値を示している。
また、このHWブロック1を1つの電源ドメインとした場合の各ブロックの電力データが図35のように示される。図35は、動的電力基礎データ例を示す図である。図35に示す動的電力基礎データ49は、ブロック毎に電力、周波数、電圧の各値を示している。また、処理を行うHWブロック1、HWブロック2、CPUについては、RUN(実行中)及びIDLE(待ち)の各状態での値が示される。
次に、図1のステップS12における1回目のソフトウェア状態・ハードウェア状態・電力の表示について説明する。
[ソフトウェア状態・ハードウェア状態・電力を表示する(1回目)]
機能トレースデータ41を用いて、ガントチャートを生成することができる。図36は、ガントチャートの一例を示す図である。図36に示すガントチャート6aは、図28に示すシーケンスの一部に相当するが、同様に全体を表すことが可能である。また、ガントチャート6aでは、上段にガントチャート、また、下段に各ブロックの電力波形を時刻に対応させてトレース情報として表示ユニットに表示させている。
更に、CPU24dについては状態RUNの期間にはRUNの電力を、HWブロック1及び2については処理開始から割り込み要因レジスタ24pの対応するビットに1が立つまでの期間にはRUNの電力を、そうではない期間についてはIDLEの電力を表示する。このようにすることでガントチャート6aのような出力を得ることができる。ここでは2状態としたが複数状態あってもよい。図2に例示されるシミュレーション環境の第一構成、及び図6に例示されるシミュレーション環境の第三構成の場合には状態を観測する補助回路をつけてもよい。
また、図7に示すマルチCPUの構成例の場合、プログラムの内容が単純なので定常的な状態に陥る可能性がある。図37は、ガントチャートのその他の例を示す図である。図37に示すガントチャート6bは、コンピュータの表示ユニットに表示され、図7のCPU構成例においけるソフトウェアアーキテクチャにおける動作を表している。ガントチャート6bにおいて、プロセス5がg_ch[8]からg_ch[11]よりデータを消費するのに縛られるような動きになっていることが分かる。煩雑になるため同期関係を示す矢印は省略している。
次に、図1のステップS14におけるパラメータ変更について説明する。
[パラメータ変更]
ユーザは、表示ユニットに表示されたガントチャート6aより、DVFS(Dynamic Voltage and Frequency Scaling)、Power Gating等により電力制御する対象を決める。最初に電源ドメインを決める。電源ドメインは、DVFS可能なドメインとPower Gating可能なドメインで設定する。
例えば、HWブロック1とHWブロック2に1つ、CPU24dに1つ、その他に1つのドメインを割り当てたいとする。D0 = {HWブロック1}, D1={HWブロック2}, D2 = {CPU}, D3 = others を入力する。以下、A及びBが並行動作することを「A || B」と略記する。
(1)D0についてPower GatingのON/OFFや電圧変更するイベントを設定する。
(2)電圧変更の場合、電圧V_newと周波数F_newとして変更したパラメータ値を設定する。
(3)並列実行要件ごとに周波数を計算する。(A || B) の周波数は、min(F_A, F_B)で算出する。例えば、もし、D0={HWブロック1, HWブロック2}だったとすると、(HWブロック1 || HWブロック2)の時には、f1 = min(F_HW1_RUN, F_HW2_RUN)、(HWブロック1 || HWブロック2常時RUN)の時には、f2 = min(F_HW1_RUN, F_HW2_ALWAYS_RUN)を算出する。後者の場合で f2 > F_HW2_RUNの場合、HWブロック2は常時RUN部分へのアクセスのみ受け付けられる。これらを制約式とする。
(4)OSのクオンタムを設定する。
次に、図1のステップS15におけるトレースベースシミュレーションを行い、パラメータ変更を反映したトレースデータを生成する処理について説明する。
[再シミュレーション]
再シミュレーションは、イベントに関する情報をもつトレースデータ(例えば、図23、図24、図29、図30)のイベントの関係が壊れないように設定変更を反映したトレースデータを生成する。この際、HWブロックの周波数変更による割り込みが発生するタイミングや、CPUの周波数変更によりクオンタムを終えるタイミングが変更される。従って、単純にガントチャートの帯を伸ばすだけでは現実に即さない。そこで、イベントと処理時間を使って、OSモデルを使ってクオンタムによるプロセスの変更を再現、また、セマフォ変数の変更も新たに作り直す。セマフォ変数の数値が変わることにより、Wait、Postの条件が変わる。このOSの動作を模擬する。こうすることにより、設定変更前のトレースデータ40とパラメータ変更データ47を使って、設定変更後のトレースデータ40を自動生成することができる。
ここでは、一旦、Wait命令間の相対情報に落としたトレースデータ(以下、Wait命令ベーストレースデータと言う)を作成するフローを示す。Wait命令ベーストレースデータでは、Wait命令間を区切りとしてプロセスが区切られる。もちろん、Wait命令間の相対情報を作成しながら、OSシミュレーションをするとしてもよい。しかし、説明を簡単にするため、Wait命令ベーストレースを作成するフローを提示する。
図38は、再シミュレーションを説明するためのフローチャート図である。図38において、トレースデータ40からWait命令ベーストレースデータ61と、パラメータ変更データ47から変更設定VFトレースデータ62とが作成され、記憶領域に出力される(ステップS31)。
次に、記憶領域から予め用意しておいた、プロセス管理機能のうちクオンタム(分割した時間)をプロセスに割り付ける機能を抽出したOSモデル50と、電圧上昇及び降下の事象を発生させる割り込みハンドラ51と、CPUの構成を表現するアーキ記述52とを用いて、対象回路の動作を再現する(ステップS32)。再現によって得られたトレースデータを加工後トレースデータ49として記憶領域に出力する。
ふるまいが再現される対象回路は、図1のステップS11にてシミュレーションした回路構成と同一でもよいし、このシミュレーション結果の検証後にユーザによって変更(又は調整)された回路構成であってもよい。再シミュレーションの対象回路がアーキ記述52で表現される。
再シミュレーションでは、OSモデル50と、ハンドラ51と、アーキ記述52とによって、ソフトウェアとハードウェアとを含む動作モデルが形成される。従って、ステップS11での実機又はFPGA等による構成を必要とせず、簡易的にシミュレーションすることができる。
ユーザは、動作した結果として得たい電力制御を制約条件として設定でき、また、その目的とする電力制御による動作を簡易的にシミュレーションすることができるため、ソフトウェア及びハードウェアに対して改善するための適切な修正を予め検証することができる。
図39は、一回目の表示例を示す図である。図39では、表示ユニットに表示される一回目のガントチャート38aが例示されている。この例における一回目のガントチャート38aでは、Wait命令ベーストレースデータ61に基づいて作成されるため、Wait命令間でプロセスが区切られる。しかしながら、実施例の説明を簡潔にするための例示であるので、再シミュレーションのためのトレースデータはWait命令ベーストレースデータ61に限定されない。例えば、類似の逐次的に処理するアプローチや、変更箇所のみ同様の計算により、補正をかけるようにしてガントチャートが作成されるようにしてもよい。
図40は、Wait命令ベーストレースデータ例を示す図である。図40に例示されるWait命令ベーストレースデータ61において、時刻t1.5のstart_hw1のレジスタ書き込みのタイミングで、HWブロック1を含むドメインの電圧と周波数を上げる設定をして、安定したらHWブロック1が動作する設定をし、HWI_F0の中からHWブロック1を含むドメインの電圧と周波数を下げる設定をしたとする。
更に、イベントのルールを選択する。ルールとしては「他のHWブロックがアイドルだったら、起動信号が入ったタイミングで昇圧を開始し、昇圧完了時まで遅延して起動信号がHWブロックに届くようにし、更に昇圧が完了するまで他のHWブロックへの起動命令も遅延させ、昇圧完了後と当該ブロックの周波数を変更すると仮定する」や、「HWブロックに降圧命令が発行されたら、他のHWブロックがアイドルだったら降圧を開始し他のHWブロックへの起動を遅延させると仮定する」といったルールを持っておく。
例えば、時刻t1.5で発行された命令に対して、前者の仮定が設定され、HWI_F0の中からHWブロック1に対して発行される降圧命令に対して後者の仮定が設定されたとする。これらをWaitトレースに加えると図41のようになる。
また、HWブロックと同様、転送ブロックに関しても、同様に転送プロセスとスケジューリング(バスのアービトレーション)でモデル化してもよい。
図41は、電力変更イベントを追加したWait命令ベーストレースデータ例を示す図である。図41では、Wait命令ベーストレースデータ61において、プロセスAに対してHWブロック1を昇圧するための"PowerUp"イベントが追加され、また、HWI_F0に対してHWブロック1を降圧するための"PowerDown"イベントが追加されている。更に、VFトレースデータ62からこれら、ユーザによる電力変更に係る追加されたイベントに対応するVFデータ61−2が追加イベントに対応させて記憶される。
更に、図25の構成においてCPU24dを含むドメインの初期電圧が0.9[V]に変更され、更にCPU24dは50MHzに変更された場合、図42のように初期値のみからなるVFトレースデータ42が作成される。
図42は、変更前のVFトレースデータ例を示す図である。図42において、VFトレースデータ42は、変更される前の状態の時刻0の時の電圧及び周波数の値を示している。ユーザが、表示ユニットに表示されたガントチャート及び電圧波形を含むトレース情報から電圧及び周波数をパラメータとする値を変更すると、例えば、図43に示すように、時刻0について変更設定VFトレースデータ62が作成される(図38のステップS31)。
図43は、変更後のVFトレースデータ例を示す図である。図43に例示される変更設定VFトレースデータ62は、時刻0の時の変更設定を示している。CPU24dに対して、電圧を1.2[V]から0.9[V]へ降圧する変更、周波数を0[MHz]から50[MHz]へと変更することがイベントとして設定されている。変更設定VFトレースデータ62は、このように変化するタイミング毎に作成される。
次に、Wait命令ベースデータ61と変更設定VFトレースデータ62とOSモデル50と、割り込みハンドラ記述51と、アーキ記述52とを使って再シミュレーションする。ここで、Wait命令ベースデータ61は明らかに処理時間がわかる。
次に、OSモデル50について説明する。
[OSモデルの作成]
本実施例におけるOSモデル50は、コンピュータ全体を実際に制御するOSからスケジューリングとスケジューリングに関するデータフィールドを抽出して、シミュレーション時間を再現する記述を追加して作成される。ここでは、例えば、非特許文献2の70ページから79ページに記載されるようなOSを一例として以下に説明する。OSモデル50の主な目的は、シーケンスのイベント関係が保持されるようなシミュレーションが可能な環境を提供することである。従って、夫々のプロセスがどのくらいの時間で終わるか、次のイベントがどんなイベントであるかが決まればよい。
図44は、アーキ記述によるプロセスを実行する構成要素の記述例を示す図である。図44に示す記述例では、回路構成でプロセスを実行する構成要素として、CPU、HWブロック1、HWブロック2、及びインターフェイスがある。このうち、通常のOSが実行され、ソフトウェアプロセスが実行されるものは区分を汎用とし、実際には専用ハードウェアであるが、プロセスの時間を表現するために便宜的にソフトウェアプロセスとして表現するものには専用ハードウェアとして定義される。また、どのOSを使うかを示す種別番号を付加する。仮に、CPUとDSPがあり、CPUとDSPで実行されるOSが違う場合には、別の種別が割り振られる。
このようにOSが1種類の場合のOSモデル50の例について図45で説明する。図45は、OSモデル例を示す図である。図45において、OSモデル50は、直近の時刻に移動して、イベントが優先度別に書き込まれている優先度別待ち行列53を参照して優先度の高いイベントを取得する(ステップS71)。OSモデル50は、アーキ記述52(図44の記述例)を参照して、取得したイベントに係るプロセスを実行するOSのIDを調べる(ステップS72)。
次に、OSモデル50は、イベントを調べる(ステップS73)。OSモデル50は、イベントがクオンタムの消費イベントであるか否かを判断し(ステップS74)、クオンタムの消費イベントである場合には、INTERVAL_TIMER_INTERRUPT関数を呼び、ステップS81へと進む。
ステップS81では、OSモデル50は、Wait命令ベーストレースデータ61(後述される再シミュレーション工程Bにて作成される)を照会することにより現在のイベントにより変更があったプロセスに残り時間を書き込んで、ステップS71へと戻る。ここで、イベントがクオンタムの消費イベントである場合、次のイベントまでの残り時間から消費した時間を減算した値を優先度別待ち行列53に書き込む。
一方、ステップS74にて、イベントがクオンタムの消費イベントでないと判断した場合、OSモデル50は、イベントがPostイベントであるか否かを判断し(ステップS76)、Postイベントである場合、V(S)関数を呼び、ステップS81へと進む。
一方、ステップS76にて、Postイベントでないと判断した場合、OSモデル50は、イベントがWaitイベントであるか否かを判断し(ステップS78)、Waitイベントである場合、P(S)関数を呼び、ステップS81へと進む。
一方、ステップS78にて、Postイベントでないと判断した場合、OSモデル50は、割り込み種別を選択して割り込みハンドラを呼び(ステップS80)、ステップS81へと進む。割り込みハンドラは、割り込みハンドラ記述51によって定義される。
このように、本実施例に係るOSモデル50は、プロセスに割り当てられたプロセスの処理時間分、時間を進めながら、イベントを発生させると言った単純な構成で実現される。
次に、同じ種類のOSが複数実行される場合のアーキ記述52の変更例について説明する。例えば、CPU ID「0」から「3」とCPU ID「4」から「7」に分けて、各々OSを動作させる場合、OS ID番号を振り、そのOSが管理するリソースと関係付ける。ただし、仮想マシンソフトウェアのようにOSを切り替えるような機構のものがあれば、仮想マシンソフトウェアを図27にならってモデル化する。つまり、仮想マシンソフトウェアのOS切り替え操作により、OS IDを調べる以降の処理を切り替えるようにする。
もし、アーキが変更された場合、或いは、アーキの利用のされ方が変わった場合はアーキ記述を変更するのが一つの方法として考えられる。一方、仮想マシンソフトウェアのところでも記載した通り、OSがその機能を有する場合がある。アーキの利用のされ方であればOSが制御することもできる。このようにOSがその機能を有している場合にはOS中にそのアルゴリズムは明記されているはずであり、OSのモデル化の範疇となる。しかしながら、そのようなアルゴリズムを記載した文献はなく、本実施例では、アーキ変更、アーキの使い方の変更等はアーキ記述52で行う。
例えば、図44に示すアーキ記述例で当初試したが、スレッドの構成上、複数のCPUで実行すればパフォーマンスの向上が見込めるため、CPU3個で再シミュレーションした場合には、ユーザは、図46に示すようにアーキ記述52を変更すればよい。図46は、アーキ記述の変更例を示す図である。
図46において、図44に示すアーキ記述例に対して、区分「汎用」としてCPU 0、CPU 1、CPU 3が定義される。
例えば、非特許文献2のOSは、OSのアルゴリズム中にCPUのID番号を減算して、遊んでいるCPUのIDに処理を割り当てるアルゴリズムが記載されている。従って、図45のようにモデル化すれば、OSのCPUリソース利用ルールに従ってソフトウェアがCPUに割り当てられて処理速度の変化等を観測することが可能となる。
非特許文献2の71ページには、プロセス管理用の構造体が宣言されている(図47)。本実施例では、OSモデル50でのシミュレーションへの入力は、図40で明らかなようにプロセス(又は軽量プロセス)は処理時間で特徴づけられる。このため、処理時間に関するパラメータが必要である。例えば、図47を参考にすると、図48のようなデータ構造を用意すればよい。
図47は、プロセス管理用の構造体記述例を示す図である。図47に示すプロセス管理用の構造体記述例は、非特許文献2に基づくものである。この構造体記述例から、本実施例において必要な部分のみの記載例は、図48に示すようになる。
図48は、OSモデルにおけるプロセス管理用の構造体記述例を示す図である。図47に示すプロセス管理用の構造体記述例は、本実施例にてOSモデル50のために適用される構造体記述例である。この構造体記述例では、次のイベントまでの残り時間(remain_time)と次のイベントの状態等(next_event_time、p_block() : state(0))が追加される。これら追加した記述は、図45でイベント発生を検出したプロセスに対して、Waitトレースデータ、もしくはクオンタム消費イベントの場合には、remain_timeからクオンタム分の時間を差し引いたものが実行される。
また、図25に示す回路構成に基づいて、例えば、アーキ記述52では、更にリソース毎の割り込み条件が管理され、図49に示すようなアーキ記述によって表現される。図49は、アーキ記述によるリソース毎の割り込み条件の記述例を示す図である。図49に例示されるアーキ記述52では、CPU24d、タイマー24k、HWブロック1、HWブロック2、割り込み要因レジスタ24pのブロック(リソース)毎に割り込み条件式と要因とが対応付けられて記述される。
次に、専用ハードウェアに対応する場合を含むOSモデル50の作成について説明する。非特許文献2ではマルチCPUまでは対応しているが、専用ハードウェアを含むシミュレーション用のCPUのモデルとしては不十分である。そこで、本実施例では、特定のプロセスしか実行できないCPUを加える。例えば、CPUの個数を16とし、8を超えるCPUは特定のプロセスしか実行できないようにする。具体的には、まずプロセスの情報に二つのフィールドを追加する。すなわち、図51に例示されるように、固定CPUに割り当てを固定するためのis_bind_cpuと、どのCPU IDに割り当てるかを指定するためのbind_cpu_idとが追加される。
更に、ACTIVE関数は、PROC_NUMBERが8を超えていた場合、READY_QUEUEの中から該当のPROC_NUMBERに束縛されたPCBのうち最優先のものを選択するように変更する。実際には、OSが実行されたらOSが自分が実行されているCPUのCPU番号レジスタを参照してPROC_NUMBERを取得するが、本実施例に係るOSモデル50では、直近にイベントがあったプロセスが割り当てられていたCPUのID番号で代用する。
この変更により、ハードウェアを模擬するためのCPUは固定のプロセスしか実行できなくなる。つまり、ハードウェアの動作状況を新たなC言語モデルなどで作成してCPUモデルの外に付加するのではなく、OS上で実行される1プロセスとして表現でき、大幅に簡単なモデル化が可能となる。
従って、図46に示すようなアーキテクチャーがあった場合、上記のルールに従い、例えば、図50のようにアーキテクチャーを構成する部品の名称とCPU IDとを対応付けたテーブルを作成することができる。図50は、CPU ID割り当てテーブル例を示す図である。図50に例示されるCPU ID割り当てテーブルでは、例えば、CPU0、1、2に対してCPU ID「0」、「1」、「2」が夫々割り当てられ、HWブロック1、2に対してCPU ID「8」、「9」が夫々割り当てられ、インターフェイスに対してCPU ID「10」が割り当てられた状態を示している。
次に、電圧の昇降動作に関して説明する。非特許文献2では、プロセスが優先度毎にキューイングされる優先度キューになっている。この優先度キューの最優先度キューに電圧の昇降状況を表現するプロセスを追加する仕組みによって、電圧の昇降によるアイドリングが実現できる。OSモデル50は、最優先度なので最初に実行する。また、最優先度なので一般の割り込みなどから保護される。一方、電力制御用の信号変化(つまり、割り込み)に関しては割り込みを許可すれば、降圧中に発生した昇圧イベントや、昇圧中に発生した降圧イベントにも対応できる。また、電圧昇降動作のモデリングさえもOS上で実行される一プロセスとして表現できる。残り時間に関しては、図31及び図32と、図30に例示される電圧変更イベントを使って算出可能である。
次に、ハードウェア割り込みに係るモデル化について説明する。ハードウェア割り込み処理機構は、通常、ハードウェア固有に備えられるものであるため、OSにはない。しかし、本実施例では、HWブロックもOS上のプロセスとして表現しているので、ソフトウェア割り込みと同じ形態になっている。従って、通常のソフトウェア割り込みよりも優先度が高いソフトウェア割り込みとしてモデル化する。このようにして、本実施例に係るOSモデル50は、ハードウェアモデルに対応可能となる。
また、PowerUpイベント、PowerDownイベント等のハードウェア割り込みも同様である。
ハードウェア割り込みのイベントもトレースに従うのも一案である。しかし、シーケンスが同じになる場合には有効であるが、周波数の変更などで、シーケンスが同じにならない場合には有効ではない。そこで含めてハードウェア割り込みのモデル化を行う。
通例、ハードウェア割り込みハンドラは要因などを見て処理を振り分ける、或いは、処理時間上の不都合がなければ、ハードウェア割り込みハンドラ内で処理を行うこともあるかもしれない。そこで、割り込みハンドラ記述51を用いてハードウェア割り込みをモデル化する。
図25の割り込み要因レジスタ24pのようにCPUとHWブロック1及び2の間で共有されるデータ領域をメモリに割り当てる。更に、セマフォを割り当てて排他制御する。MUTEXによる排他制御でも良い。割り込み要因レジスタを操作する処理はクリティカルセクションとなるようにする。
例えば、HWブロックのプロセスでは、図41の例示されるデータのように、HWブロック1に「要因=1」とするようなイベントを発生させるようにすれば良い。
次に、HWブロック1及び2間で起動をかけることが可能である場合について説明する。もし、HWブロック1及び2間で起動をかけることが可能である場合、HWブロック間の通信も記録する。例えばreadyのアサート(つまり wait命令相当)/ startのアサート(つまり、post命令相当)を記録する。リングバッファを介して通信している場合にはセマフォ通信でモデル化する。更に、HWブロック1及び2は、1つのプロセスと、このプロセスのみが利用可能なCPU、タイムシェアリングがないOSでモデリングする(Power Down / Upする場合は後述)。プロセスは、Wait命令のコール(readyのアサート)をして、待ち状態になり、相手HWブロックからのPost命令のコール(startのアサート)により、実行可能になる。このプロセスにはちょうど1個実行可能なCPUが存在するので、割り当てられて処理を開始する。このように、HWブロック1及び2は、CPU−OSのモデリングに対応付けることができる。
更に、CPU24dがパワーダウン/パワーアップするドメインのCPUである場合は、PowerIntとPowerTaskの優先度を加える。PowerIntとPowerTaskの優先度は、ハードウェア(HW)割り込みとソフトウェア(SW)割り込みの関係になるようにする。つまり、PowerTaskのプライオリティを持つタスクが走っている期間であっても、PowerIntの発生を受信する。更に、CPU24dに一対一対応するPowerDownプロセスとPowerUpプロセスを用意する。夫々、該当のCPUをPowerDownする割り込み(イベント)、PowerUpする割り込み(イベント)をWaitするようにしておく。このようにすることで、割り込みが発生したら、これらのプロセスが実行され、パワーダウン/パワーアップの動作が模擬される。
PowerIntとPowerTaskの優先度を通常の優先度より高く設定すると割り込み信号が発生すると即座にパワーダウン/パワーアップする動作が実現できる。もちろん、OSモデルにおいて、PowerIntやPowerTask実行中のディスパッチャ制御に手を加えて、もっときめの細かい制御ができるモデルにしてもよい。
変更設定VFトレースデータ62において、電源電圧の変更を検出した際に、割り込みを発生させ、PowerInt優先度で待機しているプロセスを呼ぶ。このプロセスの中で、割り込み内容が降圧であればPowerDownプロセスを生成させ実行させ、昇圧であればPowerUpプロセスを生成させ実行させる。もし、どちらかのプロセス実行中に割り込みが発生したら、PowerInt優先度の割り込みハンドラは、現在実行中の経過時間と放電時間データと充電時間データを使って、次の昇圧または降圧処理の処理時間を計算して、プロセスを生成実行させる。
具体的に説明する。まず、図42、図43より、今回の周波数と前回の周波数の比が求まる。例えば、CPU24dの場合、0.5が求まる。従って時間は2倍かかる。0時間から始まる動作は、HWI_F1とInterfaceである。Interfaceは周波数の変更がないので、次のイベントは、時刻t1である。一方、CPU24dは周波数変更があるので、t1/0.5=2×t1になる。
時刻0ではプロセスは2個しか走っていない。そこで時刻0よりHWI_F1の相対時刻でのイベントの発生を調べる。イベントは0時点で、Create Process A, Bが起きる。0 + t1 / 0.5 時点でend が起きる。一方、Interfaceプロセスは、0でPost(semA)が、時刻t1でPost(semA), endが起きる。従って、直近のイベントは0のPost(semA)である。OSモデル50は通常のOSと同様、セマフォ値を1加算しシグナル命令を発生し、Wait Process状態にある Process Aが実行待ちキューに入る。次に、時刻t1で Post(semA)が起きる。そこで、更にセマフォ値が1加算される。更にインターフェイスは処理を完了する。Interfaceの次のイベントは時刻で始まっているので、時刻t13でイベントが起きるようにスケジュールする。
次に、2×t1において、HWI_F1は終了する。OSモデル50は通常のOSと同様、ディスパッチャを起動してCPU24dを開放する。更に実行待ちキューの優先度の最も高いプロセスを取り出す。現在、Process Aのみが待っているのでこれをCPU24dに割り当てる。ここで、時刻は、t_pa_0 = 2*t1 である。Process Aのt1から2*t1に変更される。直近の Wait-Wait命令間のイベント、つまり、元の時刻で t1.5で発生する start_hw1, t2で発生するW(semA)は、元の時間で、Waitから抜けて(t1.5 - t1), (t2 - t1)でイベントが起きる。周波数は変更していないので、d_0 = 2 * (t1.5 - t1), d_1 = 2* (t2 - t1)でイベントが発生する。
この時点で、Process Aのみが実行されているので、次の直近のイベントは、t_pa_0 + d_0 で発生するstart_hw1イベントである。従って、このイベントによりOSモデル50は、start_hw1イベントにより、HWブロック1に対応するプロセスを起動する。更に、PowerUp割り込みを発生させる。PowerUpプロセスが実行される。ここで、放電時間データを引いて、所望の電圧になるまでの相対時間を算出する。算出値がd_2だったとする。従って、t_pa_1 = (t_pa_0 + d_0 + d_2)にイベントが起きる。OSはPowerUpプロセスの完了を検出し、周波数が1.2(=120/100)倍になっていることを検出し、HWブロック1を開放する。HWブロック1の開放を待っているHWブロック1プロセスを割り当てる。HWブロック1プロセスの処理時間は (t9 - t1.5)だったので、HWブロック1プロセスの終了イベントは t_pa_6 = (t_pa_1 + 1.2 * (t9 - t1.5))に発生する予定になる。
次に、t_pa_2 = (t_pa_0 + d_1)時点でProcess Aの待ちが発生する。セマフォ値は非0なので、次のWait-Wait間処理が開始される(つまり元時刻のt3 〜t5区間)。同様に計算して、t_pa_3 = t_pa_2 + 2* (t4 - t3)でPost(semB)が起きる。これにより、OSモデル50は通常のOSと同様、セマフォの値を1増加させる。更に、Process Bは実行可能キューに移される。
Process Aは、更に予定では、t_pa_4 = t_pa_2 + 2* (t5 - t3)でWait(semA)が発生する。ここで、(t_pa_3 - t_pa_0) < Quantum < (t_pa_4 - t_pa_0) だったとすると、OSモデル50は通常のOSと同様、Process AはCPUを開放させられる。この時刻を t_pa_3.5 とすると、Process Aは50MHzで(t_pa_4 - t_pa_3.5)分の処理が残っていることを-p_blockオブジェクトに記載し、実行可能キューに移す。OSモデルは、更に、通常のOSと同様、Process Bに処理を割り当てる。従ってt_pa_5 = t_pa_3.5 + 2 * ((t7-t6)+(t12-t11))にWait命令の発生が予定されることになる。
もし、t_pa_6 < t_pa_5だったとすると、t_pa_6 で正常終了し、要因レジスタが1になる。つまり、割り込みが起きる。ここで、Process Bの残り処理時間は、50MHzで(t_pa_6 - t_pa_5)となる。これをp_blockオブジェクトに記載して、Process BにCPUを開放させる。OSモデル50は、OSと同様、割り込みハンドラHWI_F0をCPUに割り当てて、HWI_F0はSWI_F0をコールする。 SWI_F0は、t_pa_7 = t_pa_6 + 2*(t11 - t10)で処理が開始され、t_pa_8 = t_pa_7 + 2 * (t13 - t11)で処理が終了する。
更に、OSモデル50は、通常のOSと同様、ディスパッチャによりCPU24dを開放し、Process BをCPU24dに割り当てる。この際に、現在の周波数を調べる。この例では50MHzのままなので、p_blockオブジェクトに記載された残り時間が利用される(変わっている場合にはスケーリングする)。従って、Process Bは、t_pa_9 = t_pa_8 + (t_pa_6 - t_pa_5)にWait命令の発行が予定される。
もし、t_pa_8 < t_pa_9 だったとすると、InterfaceはP(semA)を実行し、セマフォAは1になる。割り込みは発生しないので、Process Bは予定通り、t_pa_9でWaitする。ここでOSモデル50は通常のOS同様、ディスパッチャによりProcess AをCPU24dに割り当てる。ここで、現在の周波数を調べて、Process Aの次のイベントを算出する。t_pa_10 = (t_pa_9 + (t_pa_4 - t_pa_3.5))でWaitする。
Process AはWaitするもののすでにセマフォAは非0なので生起する。t_pa_10より、従来の時刻のt15から始まっていたProcess Aの処理が行われる。
このようにして、周波数変更による影響を反映したトレースデータを作成することができる。すなわち、新しい機能トレースデータ41とVFトレースデータ42を作成することができる。
[ソフトウェア状態・ハードウェア状態・電力を表示する(2回目)]
再シミュレーションにより生成された新しい機能トレースデータ41とVFトレースデータ42により、変更後の電力、電力量を算出する。
[ユーザ・インターフェイス]
電圧、周波数の変更要因を反映させたトレースを生成する技術について説明しきた。この枠組みを応用するとユーザ・インターフェイスでインタラクティブに要因を変更して、電力量の削減、処理時間の増大等を検査できるようになる。例えば、1回目のシミュレーション(図1のステップS11)による電力計算結果により、図52のようにトレース情報が表示ユニットに表示される。
図52は、図1のステップS11での1回目の表示例を示す図である。図52に例示されるトレース情報の表示画面において、ガントチャートではプロセスの実行状態が処理時間の長さで表されると共に、プロセス間の同期が「sync」の矢印で示されている。また、ガントチャートのプロセスの状態に対応させて電圧波形が表示されている。
更に、この表示画面上で、図53、図54のように周波数、電圧、起動トリガを入れることにより設定変更パラメータを取得することができる。
図53は、周波数の変更例を示す図である。図53では、ユーザは、トレース情報の表示画面のガントチャート上で実行状態のプロセスを選択すると表示される周波数変更画面47aを用いて、周波数の現在の値を参考にして変更値を設定する。
図54は、電圧の変更例を示す図である。図54に示すように、ユーザは、トレース情報の表示画面上のガントチャートで実行状態のプロセスを選択して、電力制御を変更するための降圧イベント48a及び昇圧イベント48bを追加発生させるマウス操作をする。
そして、バックグランドで再シミュレーション工程Bの図38のステップS32での処理を実行して、加工後トレースデータ49を生成することにより、図55のような表示ができる。
図55は、再シミュレーションによる2回目の表示例を示す図である。図55に示す2回目の表示例では、降圧イベント48a及び昇圧イベント48bによって動作できない期間が考慮されたガントチャートと、プロセスの状態に応じた電圧波形とが表示される。
図56は、電力消費データの表示例を示す図である。図56において、「baseline」から「Marker」までの区間の電力消費データが画面50aで示される。
更に、新旧のトレースのイベントの関連付けができるので、同じ区間の電力・電力量を比較できるようなビューを表示することも可能である。以上のように、統合的に見せることにより、性能に加えて、電力、電力量の比較検討を視覚的に行うことが可能になるのである。
上記実施例では、プロセスを例として説明したが、プロセス毎に複数のスレッドとしてもよい。
上述したように、本実施例では、対象回路のシミュレーションによって取得したトレースデータを用いて、電源制御に係る制約条件の変更を適用させた再シミュレーションを行うことができる。ユーザは、動作した結果として得たい電力制御を制約条件として設定でき、また、その目的とする電力制御による動作を、トレースデータを用いて簡易的にシミュレーションすることができるため、経験的な知識を必要とすることなく電力見積もりを行うことができる。
本発明は、具体的に開示された実施例に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。
以上の実施例を含む実施形態に関し、更に以下の付記を開示する。
(付記1)
シミュレーションで取得した対象回路の動作に係る複数のプロセスに関するイベント情報を含む第一トレースデータと該対象回路の動作を再現するための動作モデルとを格納した記憶領域と、
ユーザによる前記複数のプロセス間に対する制約条件の変更設定を適応させて、前記第一トレースデータに基づいて前記動作モデルを用いて再シミュレーションし、該再シミュレーションによる第二トレースデータを出力する再シミュレーション手段と、
を有することを特徴とするシミュレーション装置。
(付記2)
前記第一または第二のトレースデータの前記イベント情報から得られる前記複数のプロセス間の同期と各プロセスの処理時間とを示すトレース情報を作成して表示ユニットに表示させるトレース情報表示手段を有することを特徴とする請求項1記載のシミュレーション装置。
(付記3)
前記トレース情報表示手段は、前記ユーザによって電力制御に関するパラメータ値が変更されると、該パラメータ値を変更するイベントを追加することによって前記制約条件の変更設定を行うことを特徴とする請求項2記載のシミュレーション装置。
(付記4)
前記再シミュレーション手段は、前記制約条件の変更設定に基づいて前記パラメータ値を変更するイベントを追加することによって該制約条件の変更設定を適応させることを特徴とする請求項1乃至3のいずれか一項記載のシミュレーション装置。
(付記5)
前記再シミュレーション手段は、
前記第一トレースデータにおいてWait命令間を区切りとしてプロセスを区切ったWait命令ベーストレースデータを作成し、また、前記制約条件の変更設定を用いて、変化するタイミング毎にブロック毎の前記電力制御を示す電力制御トレースデータを作成するトレースデータ作成手段を有し、
前記パラメータ値を変更するイベントを追加した前記Wait命令ベーストレースデータと、前記電力制御トレースデータとに従って、前記動作モデルをシミュレーションすることによって前記対象回路の動作を簡易的に再現する再現手段とを有することを特徴とする請求項1乃至4のいずれか一項記載のシミュレーション装置。
(付記6)
前記記憶領域は、前記対象回路のブロック毎の電圧・遅延相関データを含む電力ライブラリを格納し、
前記トレース情報表示手段は、
前記電圧・遅延相関データを参照することによって、第一電圧から任意の第二電圧に変更されるまでの時間を算出する算出手段を有し、
前記算出した結果を用いて、前記トレース情報に対応させて電力波形を前記表示ユニットに表示させることを特徴とする請求項1乃至5のいずれか一項記載のシミュレーション装置。