JP5056493B2 - 仮想ソフトウェア生成装置 - Google Patents

Description

本発明は、ハードウェアに実装されるソフトウェアを、負荷を生成するソースコードで置き換えた仮想ソフトウェアを生成する仮想ソフトウェア生成装置に関する。

近年、システムＬＳＩ（Large Scale Integration）の開発時におけるシミュレーションによる設計技術が進められている。主に、これはＥＳＬ（Electronic System Level）技術と呼ばれ、システムＬＳＩの設計を段階ごとに詳細性（抽象性）を変えながら設計を行う技術である。

抽象度の高い設計段階では、ハードウェアをブロック図表記で行い、その高速動作性から全体構成の検討に用いたり、ＣＰＵ（Central Processing Unit）が組み込まれたＳｏＣ（System On Chip）などの設計では、実際にソフトウェアをシミュレータ上で動作させながらシステム全体の挙動を解析する目的に用いられる。一方で、抽象度の低い構成では、処理速度は遅いが実際のハードウェアロジックに近いハード詳細設計の段階で用いられる。

従来のＥＳＬツールやソフトウェア開発環境では、ハードウェアとソフトウェアとは独立した環境で開発されていた。

例えばＰＣ（Personal Computer）のように、予め決められたアーキテクチャが存在する場合は、ソフトウェアは既存のハードウェアを元に構築して行けばよいが、多様な機能を１システムで実現させるような組込システムにおけるシステムＬＳＩ上のソフトウェアを開発する場合、対象となるハードウェアであるシステムＬＳＩが実装されて後に実際のソフトウェアの開発として具体的に設計開発をして定量評価を行っていた。

また、従来のＥＳＬツールの用途は、ハードウェアアーキテクチャを設計する場合には、論理回路をハードウェア記述言語で詳細に設計するＲＴＬ（Register Transfer Level）設計ではなく、設計の詳細度合いに応じて論理回路の挙動だけを表現したＳｙｓｔｅｍＣなどの言語によって記述した抽象的な表現でシミュレーションが行われていた。一方で、ソフトウェアについては、開発したソフトウェアを実装して検証していた。

ソフトウェアの検証を行うマイコンシミュレータとハードウェアシミュレータとを備え、マイコンシミュレータにおいてハードウェアシミュレータで検証されたハードウェアの検証結果を適時に利用することによって、演算量が膨大となるハードウェアシミュレータでの処理結果を再度取得するまでの時間を短縮するようにした技術が知られている。
特開２０００−３５８９８号公報

上記従来のシミュレーション方法では、ソフトウェア検証用のマイコンシミュレータとハードウェア検証用のハードウェアシミュレータとはＩ／Ｆモデルで連携する手法であり、検証するためのシミュレータはそれぞれ別のものであるため、一のシステムＬＳＩとしてハードウェアシミュレータ上で検証することができないといった問題があった。

例えば、ＥＳＬツールは、実際のシステムＬＳＩを開発する前にシミュレーション環境による構築を補助し、実際のチップ環境を準備することなく、シミュレーション上でソフトウェアの開発に用いるために利用されている。

しかしながら、ＥＳＬ環境が整備されたとしても、システムＬＳＩのアーキテクチャやトポロジーなどが変化した場合には、それが原因となって対象とするソフトウェアが正常に動作せず、ソフトウェアを改造した後にシミュレーションモデル上でソフトウェアを移植しなおすという作業が発生していた。

よって、本発明の目的は、ハードウェアに実装されるソフトウェアをハードウェアに依存しないモジュール構成に置き換えて、システムＬＳＩ全体の挙動を実際のハードウェア及び実際のソフトウェアを開発する前に評価可能とする仮想ソフトウェアを生成する仮想ソフトウェア生成装置を提供することである。

上記課題を解決するため、ソフトウェアを構成する複数のモジュール間のデータ入出力とを解析してモジュールツリー構造を作成するモジュールツリー構造作成手段と、前記モジュール毎に負荷の程度を示す負荷テーブルを作成する負荷テーブル作成手段と、前記モジュールツリー構造の各モジュールを前記負荷テーブルによって示される前記負荷の程度を発生させる仮想ソフトウェアモジュールで置き換える置換手段と、前記モジュールが前記仮想ソフトウェアモジュールに置き換えられた前記モジュールツリー構造に基づいて仮想ソフトウェアを生成する仮想ソフトウェア生成手段と、を有するようにした仮想ソフトウェア生成装置を提供する。

上記課題を解決するため手段として、上記仮想ソフトウェア生成装置での処理を行う仮想ソフトウェア生成方法、又は、コンピュータに上記仮想ソフトウェア生成装置の各手段として機能させるためのプログラムとすることもできる。

開示の仮想ソフトウェア生成装置は、ソフトウェアを構成する各モジュールが行うと予測される処理の負荷の程度を発生させるモジュールで仮想化を行い、ハードウェアを検証するシミュレーション上で抽象化されたハードウェアと連携させることによって一のシステムとして評価及び設計を行うことができる。

以下、本発明の実施の形態を図面に基づいて説明する。

多様な機能を実現するための電子部品及びそれらを制御するＣＰＵを組み込んだＳｏＣを検証するＥＳＬツールでは、各電子部品、ＣＰＵ、及びＳｏｃに接続される周辺部品の挙動を抽象化してシミュレートして、各電子部品及び周辺部品の検証を行っている。本実施例では、実装に近いソフトウェアの負荷量に置き換えた仮想ソフトウェアを用いてＥＳＬツールを用いて検証することによって、ハードウェア及びソフトウェアの検証を同時に行えるようにする。以下、ＳｏＣとそのＳｏＣを動作させるソフトウェアとをシステムＬＳＩと言う。

図１は、本発明の一実施例に係るシミュレータ装置の機能構成例を示す図である。図１において、シミュレータ装置１００は、主に、仮想化処理部１０とＥＳＬツール２０とで構成される。仮想化処理部１０は、評価対象のシステムＬＳＩ７のソフトウェア（以下、評価対象ソフトウェア３と言う）を構成するモジュール毎に負荷量を予測し、その予測負荷量を用いて仮想化する処理部であり、構造解析部１１と、シナリオジェネレータ１２と、置換部１３と、モジュール選択部１４と、仮想ソフトウェア生成部１５とを有する。

仮想化処理部１０に入力される評価対象ソフトウェア３は、システムＬＳＩ７に搭載しようとしているソフトウェアのソースコード又は仕様書などである。仕様書の場合、他のツールによってＵＭＬ（Unified Modeling Language）やフローチャートなどの仕様表現言語で記述されたデータに変換する。

構造解析部１１は、評価対象ソフトウェア３の関数毎にモジュールを構成し、各モジュール間のデータの入出力（以下に述べるＩ／Ｏトラフィック）に係る情報に基づいてモジュールツリー構造１１ａを作成する。また、構造解析部１１は、ストーリーパーサー１１ｂを用いてモジュールツリー構造１１ａを作成する過程で取得した種々のデータに基づいてストーリーデータ４３を作成する。

シナリオジェネレータ１２は、フラグメントパーツ１２ａを用いて、仮想ソフトウェアモジュール１２ｂを作成する。フラグメントパーツ１２ａは、負荷量に係るパラメータの値を持たない空のシナリオ原案モジュールを予め備えており、シナリオジェネレータ１２から、モジュールツリー構造１１ａに基づいて評価対象ソフトウェア３のモジュール毎に負荷量に係るパラメータ値が与えられることによって、モジュール単位に仮想ソフトウェアモジュール１２ｂを生成する。

置換部１３は、モジュールツリー構造１１ａに対して、各モジュールを仮想ソフトウェアモジュール１２ｂで置換する。

仮想ソフトウェア生成部１６は、置き換え後のモジュールツリー構造１５ａに基づくソフトウェアコードでなる一つの仮想ソフトウェア２１ｂを生成し、ＥＳＬツール２０内のＥＳＬモデル２１へ出力する。仮想ソフトウェア２１ｂはコンパイルされたオブジェクトコードで出力される。仮想ソフトウェア２１ｂをＥＳＬツール２０に取り込むことで早期の段階でシステムＬＳＩ７を検証することができる。

また、モジュール選択部１４は、ユーザによるモジュールの選択を可能とする処理部である。例えば、評価対象ソフトウェア３の一部又は全体が完成している場合、ユーザが仮想ソフトウェアモジュール１２ｂで置き換える又は置き換えないモジュールを選択することによって、置換部１３が指定されたモジュールに応じて、仮想ソフトウェアモジュール１２ｂで置き換えないようにすることができる。この場合、仮想ソフトウェアモジュール１２ｂで置き換えないモジュールに対しては、評価対象ソフトウェア３の指定されたモジュールのソースコードがそのまま採用される。置換するモジュール又は置換しないモジュールを個々或いはグループ単位でユーザが指定できるようなインタフェースとしてもよい。

このような機能を備えることによって、仮想化処理部１０から出力される仮想ソフトウェア２１ｂは、ソフトウェアの実体のモジュールと、予測した負荷量に基づく仮想化したモジュールとを混在させることができる。従って、本実施例では、ＥＳＬツール２０にソフトウェアの実体のモジュールと仮想化したモジュールとを混在させて動作させることができる。既存のソフトウェアの完成度の高いモジュールを流用して評価することが可能となる。また、ユーザは、特に詳細な挙動の分析を行いたいモジュールについては置換を行わない指定をすることができ、ＥＳＬツール２０上でシミュレーションする際には置換されなかったモジュールの機能部分について詳細な分析を行うことができる。

一方、評価対象ハードウェア２は、ＥＳＬツール２０を用いて抽象化された抽象化ハードウェア２１ａとして生成される。ＥＳＬモデル２０は、この抽象化ハードウェア２１ａと仮想ソフトウェア２１ｂとで構成される。

ユーザは、ＥＳＬツール２０を用いてＥＳＬモデル２１を評価する際には、評価対象ハードウェア２と評価対象ソフトウェア３とを同時に評価することができ、また、システムＬＳＩ７全体の評価結果（フィードバック）に基づいて評価対象ハードウェア２と評価対象ソフトウェア３とを夫々見直すことができる。

上述したような機能を実現するシミュレータ装置１００は、コンピュータ装置であって、図２に示すハードウェア構成を成す。図２は、シミュレータ装置のハードウェア構成例を示す図である。図２において、シミュレータ装置１００は、コンピュータによって制御される端末であって、ＣＰＵ３１と、メモリユニット３２と、表示ユニット３３と、出力ユニット３４と、入力ユニット３５と、通信ユニット３６と、記憶装置３７と、ドライバ３８とで構成され、システムバスＢに接続される。

ＣＰＵ３１は、メモリユニット３２に格納されたプログラムに従ってシミュレータ装置１００を制御する。メモリユニット３２は、ＲＡＭ（Random Access Memory）及びＲＯＭ（Read-Only Memory）等にて構成され、ＣＰＵ３１にて実行されるプログラム、ＣＰＵ３１での処理に必要なデータ、ＣＰＵ３１での処理にて得られたデータ等を格納する。また、メモリユニット３２の一部の領域が、ＣＰＵ３１での処理に利用されるワークエリアとして割り付けられている。

表示ユニット３３は、ＣＰＵ３１の制御のもとに必要な各種情報を表示する。出力ユニット３４は、プリンタ等を有し、ユーザからの指示に応じて各種情報を出力するために用いられる。入力ユニット３５は、マウス、キーボード等を有し、ユーザがシミュレータ装置１００が処理を行なうための必要な各種情報を入力するために用いられる。通信ユニット３６は、シミュレータ装置１００が例えばインターネット、ＬＡＮ（Local Area Network）等を介してシミュレータ装置１００と接続する場合に、シミュレータ装置１００との間の通信制御をするための装置である。記憶装置３７は、例えば、ハードディスクユニットにて構成され、各種処理を実行するプログラム等のデータを格納する。

シミュレータ装置１００よって行われる仮想ソフトウェア２１ｂを生成するプログラムは、例えば、ＣＤ−ＲＯＭ（Compact Disc Read-Only Memory）等の記憶媒体３９によってシミュレータ装置１００に提供される。即ち、プログラムが保存された記憶媒体３９がドライバ３８にセットされると、ドライバ３８が記憶媒体３９からプログラムを読み出し、その読み出されたプログラムがシステムバスＢを介して記憶装置３７にインストールされる。そして、プログラムが起動されると、記憶装置３７にインストールされたプログラムに従ってＣＰＵ３１がその処理を開始する。尚、プログラムを格納する媒体としてＣＤ−ＲＯＭに限定するものではなく、コンピュータが読み取り可能な媒体であればよい。本発明に係る処理を実現するプログラムは、通信ユニット３６によってネットワークを介してダウンロードし、記憶装置３７にインストールするようにしても良い。

図３は、仮想化処理部による処理を説明するためのフローチャート図である。図３において、ユーザによって評価対象ソフトウェア３が仮想化処理部１０に入力される（ステップＳ１）。入力される評価対象ソフトウェア３は、ソースコード、仕様書等である。評価対象ソフトウェア３が入力されると、仮想化処理部１０は、評価対象ソフトウェア３がソースコードであるのか又は仕様書であるのかを判断する（ステップＳ２）。評価対象ソフトウェア３のファイル識別子で判断するようにすればよい。仕様書であると判断した場合、仮想化処理部１０は、一般に用いられているツールを利用してＵＭＬやフローチャートなどの仕様表現言語で記述したデータに変換して、ソフトモジュール構成グラフリスト４１とモジュール処理サイクルに係る情報を含むＩ／Ｏトラフィックリスト４２とを出力する。

一方、ソースコードであると判断した場合、構造解析部１１は、コンパイルのための前処理を実行するプリプロセッシングを行い（ステップＳ３）、ソースコードを読み出しながら、その実行トレースをスタックしておき、実行後に関数などのモジュールレベルにおける、演算量、その関数がどのようなリソースを使用したか（アクセス元及びアクセス先）を示す情報、アクセスの対象となるデータ量、モジュール処理サイクルを示す情報等をレポート出力するプロファイリングを行って（ステップＳ４）、評価対象ソフトウェア３を構成する複数のモジュールを実際に実行させることなく、各モジュールの挙動に係るデータを収集する。本実施例では、このプリプロセッシングとプロファイリングとを含めてプリプロファイリングと言い、各モジュールの挙動を実際に実行させることなくデータを収集ことである。プリプロファイリングを行うステップ４での処理をプリプロファイラと言う。

本実施例におけるプリプロファイリングではソフトウェアそのもののアルゴリズムには関与しないため、モジュールの挙動に係るデータは、そのモジュールが使用すると想定されるハードウェアリソースを示す情報などである。プリプロファイリングで生成された情報はＩ／Ｏトラフィックリスト４２として蓄積される。

また、ステップＳ４では、構造解析部１１は、評価対象ソフトウェア３に対してツリー解析を行うことによって、関数名を用いてモジュールの特定を行い、モジュール間のＩ／Ｏトラフィックで関連付けられるモジュールツリー構造１１ａを生成する。モジュールツリー構造１１ａは、モジュールを特定する関数名とモジュール間のＩ／Ｏトラフィックに係る情報とを対応付けた構成グラフリスト４１で表現される。

更に、構造解析部１１は、リストパーサー機能を用いて構成グラフリスト４１とＩ／Ｏトラフィックリスト４２とからストーリーデータ４３を作成するストーリーパーサーを実行する（ステップＳ５）。ストーリーデータ４３は、構成グラフリスト４１に基づく複数のモジュールが実行される処理手順毎に、実行するモジュールを特定する情報、そのモジュールの演算量、アクセス元、アクセス先、データ量、モジュール処理サイクルに基づいて分類したアクセスパターン等の、各モジュールの負荷量に係るパラメータ値を対応させたテーブルである。このようなストーリーデータ４３によって、各モジュールが、どのくらいの演算量で、どこからどこへ、どのくらいの量のデータをどのようなアクセスパターンで実行するかが示される。

次に、構造解析部１１によってストーリーデータ４３が作成されると、シナリオジェネレータ１２は、ストーリーデータ４３を参照して、モジュール毎に、負荷量に係るパラメータ値を持たない空のシナリオ原案モジュールとして予め用意してあるフラグメントパーツ１２ａに各パラメータ値を設定して仮想ソフトウェアモジュール１２ｂを作成する（ステップＳ６）。

つまり、パラメータ値が設定されたフラグメントパーツ１２ａは、評価対象ソフトウェア３のモジュールの挙動を示すアルゴリズム的な意味はなく、そのモジュールの実体が動作した場合と同等のアクセスパターン及び負荷量を持った仮想ソフトウェアモジュール１２ｂとなる。各仮想ソフトウェアモジュール１２ｂは、システムＬＳＩ７のＣＰＵの演算量とＩ／Ｏパターンを示すアクセスパターンのみを挙動の実体とするため、特定のアルゴリズムやデバイスの影響を受けないハードウェア非依存のソフトウェアモジュールとすることができる。

仮想ソフトウェアモジュール１２ｂの内部構造は本来目的とする挙動を行う内容ではないため、評価対象ソフトウェア３の関数名や引数などについては、評価対象ソフトウェア３の形態を引き継ぐものとする。

置換部１３は、評価対象ソフトウェア３の構造解析後に得られたモジュールツリー構造１１ａに対して、シナリオジェネレータ１２によって作成された仮想ソフトウェアモジュール１２ｂで置き換えを行う（ステップＳ７）。実際にモジュールをそのまま置き換えるのではない。ソースコード上、関数名から、例えば、Ｃ言語系の記述であれば関数処理の開始を示す「｛」と、終了を示す「｝」の間を置換していくことによって、元の評価対象ソフトウェア３の関数名及び引数を維持する。計算結果による条件分岐処理については、従来の分岐予測手法を用いて、求める分岐比率に従った分岐を生成して置換する。

一方、仮想化レベル情報１８にはモジュール選択部１４を用いたユーザのモジュールの選択に係る情報が格納されており、置換を行わないモジュールが存在する場合には、そのモジュールに対する仮想ソフトウェアモジュール１２ｂによる置き換えは抑止される。また、仮想化レベル情報１８には、画像処理装置のコンフィグ情報なども含まれる。コンフィグ情報は、所定フレーム数単位で取り込める画素数、１ファイル当たりのアクセスデータ量、表示解像度など示す。

置換部１３による処理後、仮想ソフトウェア生成部１５は、モジュールツリー構造１１ａに対して仮想ソフトウェアモジュール１２ｂで置き換えたモジュールツリー構造１５ａを用いて、評価対象ハードウェア２のシミュレーション環境で動作する実際のソフトウェアコードを出力する（ステップＳ８）。

次に、ユーザは、ＥＳＬツール２０を用いて評価対象ハードウェア２の抽象化ハードウェア２１ａを作成した後、抽象化ハードウェア２１ａと仮想化処理部１０から出力された仮想ソフトウェア２１ｂとで成るＥＳＬモデル２１を、ＥＳＬツール２０上でシミュレーションすることによって検証して（ステップＳ９）、ソフト要求仕様を満たすか否かを判断する（ステップＳ１０）。ユーザが、ソフト要求仕様を満たすと判断した場合には評価が完了したと判断する（ステップＳ１２）。

一方、ソフト要求仕様を満たさないと判断した場合には、ユーザはストーリーデータ４３を表示ユニット３３に表示させ、項目の値を変更して調整する（ステップＳ１１）。又は、構成グラフリスト４１とＩ／Ｏトラフィックリスト４２とに格納されている情報を変更する。構造解析部１１は、構成グラフリスト４１又はＩ／Ｏトラフィックリスト４２の変更に応じてリストパーサーを実行してストーリーデータ４３を更新する。以後上述したような処理を繰り返すことによって、評価対象ソフトウェア３をどのように改善すべきかを検証することができる。

このように、ユーザは、ハードウェアシミュレータとしてのＥＳＬツール２０を用いて、評価対象ハードウェア２の挙動をシミュレートすると共に評価対象ソフトウェア３の挙動を分析することができる。

次に、上述したシミュレータ装置１００を用いた検証例について説明する。例えば、システムＬＳＩ７として動画及び静止画を撮影するために画像処理部をＳｏＣ化した画像処理装置を検証する例を説明する。図４は、ＥＳＬツール２０を用いて作成した画像処理装置の抽象化ハードウェア２１ａの例を示す図である。図４において、ＥＳＬツール２０を用いて作成された抽象化ハードウェア２１ａでは、画像処理装置は、この装置の中心となるプロセッサとしてのデバイスＡと画像処理を補助するアクセラレータとしてのデバイスＢとを内蔵した画像処理ＳｏＣ６と、プロセッサ動作時に使用されるメモリとしてのデバイスＣと、画像を取り込むカメラ６４としてのデバイスＤと、データを保存するメモリカード６５としてのデバイスＥと、表示用のＬＣＤパネル６６としてのデバイスＦと、その他汎用に用いられる汎用インタフェースとしてのデバイスＧとで構成される。図中、抽象化ハードウェア２１ａは各デバイスＡからＧの機能を表現するロジックを持たせたブロックで表現される。

ユーザは、ＥＳＬツール２０を用いて作成した画像処理装置の抽象化ハードウェア２１ａを表示ユニット３３に表示させ、動画及び静止画を処理する装置として大画面化を要求した場合に画像処理ＳｏＣ６に求められる仕様を探求していく。

図５は、画像処理装置に係る評価対象ソフトウェア３のモジュールツリー構造１１ａの例を示す図である。図５において、画像処理装置６に係る評価対象ソフトウェア３が、カメラドライバとして機能するモジュール１と、画像前処理として機能するモジュール２と、アクセラレータドライバとして機能するモジュール３と、データ後処理として機能するモジュール４と、メモリカードドライバとして機能するモジュール５と、ＬＣＤパネルドライバとして機能するモジュール６と、ＤＳＰファームウェアとして機能するモジュール７とを有し、モジュール間のＩ／Ｏトラフィックを示す接続によってモジュールツリー構造１１ａを構成する。

仮想化処理部１０へ入力される評価対象ソフトウェア３がソースコードの場合、構造解析部１１によってモジュールツリー構造１１ａが作成される。ＵＭＬなどによる仕様書図が入力された場合にはモジュールツリー構造１１ａを作成するのに必要なソースコードの解析が簡略化される。

図６は、評価対象ソフトウェア３の処理フローの例を示す図である。図６において、構造解析部１１のプリプロファイリングによって解析された処理フローの結果を示し、処理フローにおける処理毎に図５に示すモジュールを便宜的に対応させて示している。

処理Ｐ１において、モジュール１のカメラドライバがデバイスＤのカメラからデバイスＣのメモリへの連続データ取り込みを行うと、処理Ｐ２において、デバイスＡのプロセッサ内部にて演算が実行されてモジュール２の画像前処理が行われ、その処理によってデバイスＣのメモリへのランダムアクセスが発生する。

前処理が終了すると、処理Ｐ３において、モジュール６のパネルドライバがデバイスＦのＬＣＤパネルへデータを転送して画像を表示させる。処理Ｐ４において、撮影状態であるか否かが判断され、撮影状態でない場合は処理Ｐ１へと戻り上記同様の処理が繰り返される。撮影状態である場合、処理Ｐ５において、モジュール３のアクセラレータドライバがデバイスＣのメモリからデバイスＢのアクセラレータへとデータを転送する。

デバイスＢのアクセラレータへのデータ転送に応じて、処理Ｐ６において、デバイスＡのプロセッサ内部にて演算が実行されてモジュール４のデータ後処理が行われ、その処理によってデバイスＣのメモリへのランダムアクセスが発生する。

その後、処理Ｐ７において、モジュール５のメモリカードドライバによってデバイスＣのメモリからデバイスＥのメモリカードへのランダムアクセスがなされ動画又は静止画を格納する。

このようにプリプロファイリングによって、各処理Ｐ１からＰ７においてどのような挙動がソースコードで記述されているかが解析され、出力される。

図７は、構造解析結果に基づいて作成されるストーリーデータ４３の例を示す図である。図７において、ストーリーデータ４３は、モジュール番号、モジュール名、演算量、アクセス元、アクセス先、データ量、アクセスパターン等の項目で構成されるテーブルである。モジュール番号は、図５に示すモジュールツリー構造１１ａの作成時に生成されたモジュール番号に相当する。演算量によって負荷の程度を示している。モジュールがデータ転送を行う場合には、構成グラフリスト４１が参照され、データが転送されるアクセス元とアクセス先とがデバイス名（又はデバイスＡ、Ｂ、Ｃ．．．等のデバイスを特定できるデバイス識別情報）で示される。

データ量はアクセス元からアクセス先へのデータ転送量を示す。仮想化レベル情報１８に格納されているコンフィグ情報などに基づいて決定される。また、演算量、アクセスパターンは、プリプロファイラ（ステップＳ４）のプロファイリングによるサイクル測定に基づいて決定される。

アクセスパターンは、アクセス先に対して連続であるのか、断続であるのか、ランダムであるのかを分類して示している。「連続」に分類されるアクセスパターンは、連続したアドレス空間に対してアクセスを行うパターンであることを示す。「断続」に分類されるアクセスパターンは、アドレス空間において不連続であるが、一定の間隔を持ちながらアクセスを行うパターンであることを示す。「ランダム」に分類されるアクセスパターンは、「連続」及び「断続」のいずれのアクセスパターンにも分類されない不連続で任意のアドレスにアクセスを行うパターンであることを示す。

図８は、画像処理装置のＥＳＬモデル２１の例を示す図である。図８に示すシステムＬＳＩ７を抽象化したＥＳＬモデル２１は、前述したように抽象化ハードウェア２１ａと仮想ソフトウェア２１ｂとで構成される。仮想ソフトウェア２１ｂを構成するモジュール１から７の実体は、演算量とデータ量とアクセスパターンとによる負荷を与えることのみを目的としている。

従って、ストーリーデータ４３に示されるように、モジュール１は連続アクセスで２５７ＭＢ／ｓのデータ量の負荷を与えるソースコードである。モジュール２は１０ＭＢのランダムアクセス毎に１０ＭＩＰＳの演算量の負荷を与えるソースコードである。モジュール３は１０ＭＢのランダムアクセス毎に１ＭＩＰＳの演算量の負荷を与えるソースコードである。モジュール４は１ＭＢのランダムアクセス毎に１０ＭＩＰＳの演算量の負荷を与えるソースコードである。モジュール５は１ＭＢの断続アクセスの負荷を与える。モジュール６は２８ＭＢ／ｓの連続アクセスの負荷を与えるソースコードである。モジュール７は１ＭＢのランダムアクセスの負荷を与えるソースコードである。この例では、仮想ソフトウェア２１ｂを構成する全モジュールを仮想化した場合を示しているが、１以上のモジュールを仮想化せず、そのモジュールの挙動を実現するソースコードそのものを含めてもよい。

次に、ユーザがＥＳＬ２０を操作しつつ検証する例について図９及び図１０で説明する。例えば、１世代前の製品に対して画像サイズを２倍にすることによって性能を２倍とする製品を企画した場合について説明する。図９（Ａ）には、１世代前のハードウェア構成に対して２倍の画像サイズの属性が与えられ抽象化された抽象化ハードウェア２２ａを示す。ＥＳＬ２０を用いてこのような抽象化ハードウェア２２ａを評価する際に、ユーザは、１世代前のソフトウェアを評価対象ソフトウェア３として仮想化処理部１０へ入力して仮想ソフトウェア２１ｂを作成し、画像サイズを２倍にしつつも処理速度を保つためにシステムクロックを２倍するコンフィグ設定を行う。その値が仮想化レベル１８に格納される。ユーザは、抽象化ハードウェア２２ａと仮想ソフトウェア２１ｂとで成るＥＳＬモデル２１でシミュレーションを実行する。

ＥＳＬ２０によるシミュレーションの結果は、例えば図９（Ｂ）のように表示ユニット３３に表示される。ユーザは、シミュレーションの結果を検証すると、目標性能を達成することが分かるものの、必要最小限のクロックでＥＳＬモデル２１をシミュレーションさせ、図９（Ｂ）のシミュレーションのログ表示を参照してデバイスＦ及びＥに係るシミュレーション部分２７を解析すると、デバイスＥのメモリカードへのアクセスがデバイスＦのＬＣＤパネルの動作をブロックする現象が起こることが予測できた。この場合、デバイスＥのメモリカードにアクセスしている間、デバイスＦのＬＣＤパネルに表示されている画像が一瞬消えてしまう現象が発生してしまう。このことから、ユーザは、要求性能を満たすカメラ機能を実現するために必要な性能を見積もったつもりであったが、単純にシステムクロックを２倍にしただけでは不十分である等、の判断をすることができる。

目標性能を満足するためにクロックを更にＮ倍にすると消費電力が大きくなるため、単純にクロックのみを大きくしていくわけにはいかない等を考慮しつつ、ユーザは、ＥＳＬツール２０上でハードウェア構成を組み替えて、データのアクセス経路を整理した抽象化ハードウェア２２ａを構築しなおす等の考察を行う。再構築の観点としては、例えば図１０（Ａ）に示す抽象化ハードウェア２２ａ’ように、ユーザは、高速大量・連続アクセスするデバイスＤのカメラ及びデバイスＦのＬＣＤパネルと、少量データや断続的にアクセスするデバイスＥのメモリカードと、デバイスＢのアクセラレータとへのデータアクセス制御が画像処理ＳｏＣ６内部で分割されるようにバス等の組み合わせの変更及び配置変更によるアーキテクチャを構築する。また、デバイスＢのアクセラレータはメモリ呼び出しをするものではなく、デバイスＡのプロセッサからパイプライン式にデータを流し込めるようにデバイスｈのＦＩＦＯを追加する変更を行い、これら内部構成変更に伴い周辺の接続形態も変更する。

このように再構築した抽象化ハードウェア２２ａ’でシミュレーションを行う場合であっても、評価対象ソフトウェア３のソースコードそのものを変更することなく、既に作成してある仮想ソフトウェア２１ｂをそのまま用いて再シミュレーションを行うことができる。つまり、上述した再構築の例ではハードウェアの構成上、デバイスｈのＦＩＦＯをデバイスＡのプロセッサとデバイスＢのアクセラレータとの間に追加配置したが、デバイスＡのプロセッサとデバイスＢのアクセラレータとの間のソフトウェアの処理の流れ、及び、各モジュールの負荷に変更を及ぼすものではないためである。

仮想ソフトウェア２１ｂでは負荷の程度でソフトウェアの挙動を表現するため、改善されたハードウェアのアーキテクチャで同じ仮想ソフトウェア２１ｂで評価することができる。従って、アーキテクチャを探求するための評価対象ソフトウェア３の改善毎に実装して検証し直すといった工数を大幅に削減することができる。

上記再構築によるシミュレーション結果を示すログ（図１０（Ｂ））を詳細に検証して、デバイスＤのメモリのアクセス部にはアクセス形跡を示すログを確認する等によって、デバイスＥのメモリカードへのアクセスが分散している状態を評価でき、クロックをおさえつつ安定したシステムＬＳＩ７を構築できることを、評価対象ソフトウェア３の実体（ソースコード又はロードモジュール）をポーティング実装することなくシステムＬＳＩ７の挙動を確認することができる。

その他の検証として、システムクロックを２倍にしてデバイスＡのプロセッサの性能が２倍にならないことを予測した場合、デバイスＣのメモリを増量することでデバイスＡのプロセッサの処理速度が１．５倍であってもシステムＬＳＩ７全体の性能が２倍にできる可能性を容易に検証することができる。

また、既存のハードウェア及びソフトウェアを再構築してカメラをテレビ信号受信機に置き換えた別製品を開発するような場合、本来カメラから取り込んだ画像処理とテレビ信号を取り込んで行う画像処理とはソフトウェア上の処理において異なるロジックであるが、デバイスＡのプロセッサへの負荷の程度が同様である場合、接続されるデバイスの特性に依存しない仮想ソフトウェア２１ｂをそのまま用いて検証することが可能となる。つまり、仮想ソフトウェア２１ｂを生成する元となった動画又は静止画を撮影する装置に搭載されるソフトウェアを改造する以前の段階において早期に検証でき改造すべき項目をソフトウェア開発者へフィードバックすることができる。同時に、抽象化ハードウェア２２ａのデバイスＤのカメラをテレビ信号受信機に変更して検証するのみであるので、実ハードウェアの実装を待つことなくテレビ信号受信機に変更された抽象化ハードウェア２２ａをシミュレーションし、その結果をハードウェア開発者へフィードバックすることができる。この場合、デバイスを特定するための識別情報（例えば「デバイスＤ」）は変更せずデバイスの特性がテレビ信号受信機に変更すればよく、又は、ストーリーデータ４３のアクセス元又はアクセス先の値を変更すればよく、また、仮想ソフトウェア２１ｂにおけるモジュール間のＩ／Ｏトラフィックにも変更がないことによる。

仮想化ソフトウェア２１ｂを用いた場合の開発サイクルについて図１１で説明する。図１１は、開発サイクルを示す図である。図１１中、実線で示されるフローが本発明に係る仮想化ソフトウェア２１ｂを用いた場合の開発サイクルである。図１１において、開発製品としてのシステムＬＳＩ７に対する要求仕様を作成し（ステップＳ８１）、システム構成を設計する（ステップＳ８２）。設計されたシステム構成に基づいてハードウェア設計を行う（ステップＳ８３）。

ハードウェア設計に基づいて実ハードウェアの開発及び実装を行う（ステップＳ８３−２）。一方でハードウェア設計に基づく抽象化ハードウェア２１ａと仮想ソフトウェア２１ｂとによるＥＳＬモデルをシミュレータ装置１００に実装して、ＥＳＬツール２０によってハードウェア検証を行い（ステップＳ８４）、ハード要求仕様を満たすか否かを検証する（ステップＳ８５）。

ユーザがハード要求仕様を満たさないと判断した場合、ステップＳ８４に戻り抽象化ハードウェア２１ａを変更してＥＳＬモデルを更新し、ステップＳ８５にて再度ハード要求仕様を満たすか否かを検証する処理を繰り返す。また、検証結果をステップＳ８３−２における実ハードウェア（評価対象ハードウェア２）の開発に反映させる。ステップＳ８３−２と、ステップＳ８４及び８５とは、平行して行われ実ハードウェアの開発及びシステムＬＳＩ７としての実装が行われる。

ハード要求仕様を満たすと判断した場合、仮想ソフトウェア２１ｂを用いてソフトウェア検証を行い（ステップＳ８６）、ソフト要求仕様を満たすか否かを判断する（ステップＳ８７）。ユーザがソフト要求仕様を満たさないと判断した場合、ストーリーデータ４３を変更してステップＳ８６へ戻り再度ソフトウェア検証をして、ステップＳ８７にて再度ソフト要求仕様を満たすか否かを検証する処理を繰り返す。一方で、検証結果を反映したソフト開発を行う。

ソフト要求仕様を満たすと判断した場合、実ハードウェア（抽象化ハードウェア２１ａの検証結果が反映された評価対象ハードウェア２）が実装されているシステムＬＳＩ７に実ソフトウェア（仮想ソフトウェア２１ｂの検証結果が反映された評価対象ソフトウェア３）を移植し（ステップＳ８８）、システムＬＳＩ７を実機上で検証する（ステップＳ８９）。システムＬＳＩ７としての要求仕様を満たすか否かを判断し（ステップＳ９０）、要求仕様を満たすと判断した場合、システムＬＳＩ７の開発を完了する（ステップＳ９１）。一方、システムＬＳＩ７としての要求仕様を満たさないと判断した場合、ステップＳ８２へ戻りシステムＬＳＩ７のシステム構成の設計を見直し、上記同様の処理を繰り返す。

図１１において、従来の開発サイクルでは、ソフトウェア検証（ステップＳ８６）を行うためにはハード要求仕様を満たした時点（ステップＳ８５）で評価対象ソフトウェア３を移植し（点線で示すステップＳ８５−２）する必要があった。ソフトウェア検証後にソフト要求仕様を満たさないと判断した場合には、評価対象ソフトウェア３を検証結果に基づいて改造して再度移植作業を行って（ステップＳ８５−２）、ソフトウェア検証（ステップＳ８７）及びソフト要求仕様を満たすか否かの判断（ステップＳ８７）を繰り返す必要があった。

このように従来の開発サイクルでは、評価対象ソフトウェア３に問題があるとその問題を解決してからでないと、ソフトウェア検証を進めることができなかった。一方、本発明に係るシミュレータ装置１００を用いた場合、ハードウェアを検証するＥＳＬツール２０上で評価対象ソフトウェア３の検証を継続して行えることにより、少ない改造及び移植回数でより多くの検証を一度に行うことが可能となる。

次に、仮想化レベル毎におけるベンチマークで性能評価をした場合の傾向について図１２及び図１３で説明する。図１２は、仮想化レベルの例を示す図である。図１２では、例えば、評価対象ソフトウェア３がＧＵＩ（Graphical User Interface）３Ａ、処理エンジン３Ｂ、デバイスドライバ３Ｃで構成される場合の仮想化レベルが例示されている。評価対象ソフトウェア３はＯＳ（Operating System）４上で動作させ、ＡＰＩ（Application Program Interface）を介してベンチマークアプリで性能評価される。

図１２（Ａ）は、評価対象ソフトウェア３のＧＵＩ３Ａ、処理エンジン３Ｂ、デバイスドライバ３Ｃを仮想ソフトウェアモジュール７ａ、編集後仮想ソフトウェアモジュール７ｂ、仮想ソフトウェアモジュール７ｃで置き換えて全て仮想化したレベルを示している。ここで、編集後仮想ソフトウェアモジュール７ｂは、ソフト要求仕様を満たすためにストーリーデータ４３を編集後に置き換えられた仮想ソフトウェアモジュールであることを示す。図１２（Ｂ）は、デバイスドライバ３Ｃを仮想ソフトウェアモジュールに置き換えなかった場合の凡そ５０％の仮想化レベルを示している。また、図１２（Ｃ）は、全てを評価対象ソフトウェア３の実体（ソースコード）のままとし、仮想ソフトウェアモジュールで置き換えなかった実ソフトウェア（０％の仮想化レベル）を示している。

図１３は、仮想化レベル毎のベンチマークによる評価の傾向を示すグラフ図である。図１３において、グラフの縦軸はベンチマークでの評価による性能の高さを示す点数を示し、グラフの横軸はベンチマークのテスト番号を示し、便宜的に要求される性能の低いものから高いものへと並べて示している。図１３中、折れ線９ａが図１２（Ａ）の全仮想化のレベルに相当し、折れ線９ｂが図１２（Ｂ）の５０％仮想化のレベルに相当し、折れ線９ｃが図１２（Ｃ）の実ソフトウェアのレベルに相当し、実測値を示す。

図１３のグラフから分かるように、全仮想化の折れ線９ａはテスト全般において実ソフトウェアの折れ線９ｃ及び５０％仮想化の折れ線９ｂより低めの評価点となるが、概ね実ソフトウェアの折れ線９ｃと同様の傾向を示す。従って、ソフト開発の初期段階で評価対象ソフトウェア３の完成後の特性傾向を把握するには十分である。

このように、ハードウェア設計で部品の入れ替えや構成変更に応じて、デバイスドライバが変更した場合、デバイスドライバの負荷の程度に係るストーリーデータ４３を変更するのみで、デバイスドライバのソースコードの変更やその変更による評価対象ソフトウェア３全体の移植作業を行わずに、ソフト開発の初期段階でソフト要求仕様を検証することができる。また、異なる処理アルゴリズムを持った未実装の処理エンジンやＧＵＩに入れ替えるソフト設計となった場合、これらに相当する既存のモジュールの負荷の程度に応じた仮想ソフトウェアモジュールで、ソフト開発の初期段階でソフト要求仕様を検証することができる。更に、ソフトウェアが設計の段階であり実装できない状態であっても、ハードウェアの全体のスループット、挙動などの評価を、既存のソフトウェアを評価対象ソフトウェア３として利用して置き換えた仮想ソフトウェア２１ｂを用いて行うことができる。

以上の説明に関し、更に以下の項を開示する。
（付記１）
ソフトウェアを構成する複数のモジュール間のデータ入出力を解析してモジュールツリー構造を作成するモジュールツリー構造作成手段と、
前記モジュール毎に負荷の程度を示す負荷テーブルを作成する負荷テーブル作成手段と、
前記モジュールツリー構造の各モジュールを前記負荷テーブルによって示される前記負荷の程度を発生させる仮想ソフトウェアモジュールで置き換える置換手段と、
前記モジュールが前記仮想ソフトウェアモジュールに置き換えられた前記モジュールツリー構造に基づいて仮想ソフトウェアを生成する仮想ソフトウェア生成手段と、
を有するようにした仮想ソフトウェア生成装置。
（付記２）
前記負荷テーブル作成手段は、前記負荷テーブルを作成する際に、演算量、データ量、データ入出力先の項目と、モジュール毎にデータ入出力及びデータ量を解析して生成したトラフィックリストを用いて、連続、断続、ランダムに分類した該データ入出力に係るアクセスパターンの項目とによって前記負荷の程度を示すようにした付記１記載の仮想ソフトウェア生成装置。
（付記３）
前記負荷テーブルを用いて、前記負荷の程度をパラメータとするフラグメントパーツに前記モジュールの該負荷の程度をパラメータ値として与えて前記仮想ソフトウェアモジュールを生成する仮想ソフトウェアモジュール生成手段を更に有するようにした付記１又は２記載の仮想ソフトウェア生成装置。
（付記４）
前記ソフトウェアを構成する複数のモジュールに対してユーザによって前記仮想ソフトウェアモジュールに置き換える又は置き換えないことを選択させるモジュール選択手段を更に備え、
前記置換手段は、置き換えないモジュールに対しては、該モジュールのソースコードを用いるようにした付記１又は３のいずれか一項記載の仮想ソフトウェア生成装置。
（付記５）
前記仮想ソフトウェア生成手段は、ハードウェアのシミュレーション環境上で動作可能な前記仮想ソフトウェアを生成して出力するようにした付記１乃至付記４のいずれか一項記載の仮想ソフトウェア生成装置。
（付記６）
前記負荷テーブル作成手段によって作成された負荷テーブルは、ユーザによって変更可能であり、
前記負荷テーブルの変更に応じて、前記置換手段と前記仮想ソフトウェア生成手段とが再実行されるようにした付記１乃至付記５のいずれか一項記載の仮想ソフトウェア生成装置。
（付記７）
ハードウェアをシミュレーションするシミュレータ装置であって、
前記ハードウェアを抽象化して表現した抽象化ハードウェアを作成する抽象化手段と、
ソフトウェアを実行した際の負荷の程度で仮想化した仮想ソフトウェアを生成し出力する仮想ソフトウェア生成手段と、
前記仮想ソフトウェア生成手段から出力された前記仮想ソフトウェアと前記抽象化ハードウェアとでなるシミュレーションモデルをシミュレートするシミュレート手段と、
を有するようにしたシミュレータ装置。
（付記８）
前記仮想ソフトウェア生成手段は、更に、
前記ソフトウェアを構成する複数のモジュール間のデータ入出力とを解析してモジュールツリー構造を作成するモジュールツリー構造作成手段と、
前記モジュール毎に負荷の程度を示す負荷テーブルを作成する負荷テーブル作成手段と、
前記モジュールツリー構造の各モジュールを前記負荷テーブルによって示される前記負荷の程度を発生させる仮想ソフトウェアモジュールで置き換える置換手段と、
前記モジュールが前記仮想ソフトウェアモジュールに置き換えられた前記モジュールツリー構造に基づいて仮想ソフトウェアを生成する仮想ソフトウェア生成手段と、
を有するようにした付記７記載のシミュレータ装置。
（付記９）
前記ソフトウェアを構成する複数のモジュール間のデータ入出力とを解析してモジュールツリー構造を作成するモジュールツリー構造作成手順と、
前記モジュール毎に負荷の程度を示す負荷テーブルを作成する負荷テーブル作成手順と、
前記モジュールツリー構造の各モジュールを前記負荷テーブルによって示される前記負荷の程度を発生させる仮想ソフトウェアモジュールで置き換える置換手順と、
前記モジュールが前記仮想ソフトウェアモジュールに置き換えられた前記モジュールツリー構造に基づいて仮想ソフトウェアを生成する仮想ソフトウェア生成手順と、
をコンピュータが実行する仮想ソフトウェア生成方法。
（付記１０）
ソフトウェアを構成する複数のモジュール間のデータ入出力とを解析してモジュールツリー構造を作成するモジュールツリー構造作成手段と、
前記モジュール毎に負荷の程度を示す負荷テーブルを作成する負荷テーブル作成手段と、
前記モジュールツリー構造の各モジュールを前記負荷テーブルによって示される前記負荷の程度を発生させる仮想ソフトウェアモジュールで置き換える置換手段と、
前記モジュールが前記仮想ソフトウェアモジュールに置き換えられた前記モジュールツリー構造に基づいて仮想ソフトウェアを生成する仮想ソフトウェア生成手段としてコンピュータに機能させるためのプログラム。

本発明は、具体的に開示された実施例に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。

本発明の一実施例に係るシミュレータ装置の機能構成例を示す図である。 シミュレータ装置のハードウェア構成例を示す図である。 仮想化処理部による処理を説明するためのフローチャート図である。 ＥＳＬツールを用いて作成した画像処理装置の抽象化ハードウェアの例を示す図である。 画像処理装置に係る評価対象ソフトウェアのモジュールツリー構造の例を示す図である。 評価対象ソフトウェアの処理フローの例を示す図である。 構造解析結果に基づいて作成されるストーリーデータの例を示す図である。 画像処理装置のＥＳＬモデルの例を示す図である。 ユーザがＥＳＬを操作しつつ検証する例を示す図である。 ユーザがＥＳＬを操作しつつ検証する例を示す図である。 開発サイクルを示す図である。 仮想化レベルの例を示す図である。 仮想化レベル毎のベンチマークによる評価の傾向を示すグラフ図である。

符号の説明

２ 評価対象ハードウェア
３ 評価対象ソフトウェア
６ 画像処理ＳｏＣ
７ システムＬＳＩ
１０ 仮想化処理部
１１ 構造解析部
１１ａ モジュールツリー構造
１１ｂ ストーリーパーサー
１２ シナリオジェネレータ
１２ａ フラグメントパーツ
１２ｂ 仮想ソフトウェアモジュール
１３ 置換部
１４ モジュール選択部
１５ 仮想ソフトウェア生成部
１５ａ モジュールツリー構造
１８ 仮想化レベル
２０ ＥＳＬツール
２１ａ 抽象化ハードウェア
２１ｂ 仮想ソフトウェア
３１ ＣＰＵ
３２ メモリユニット
３３ 表示ユニット
３４ 出力ユニット
３５ 入力ユニット
３６ 通信ユニット
３７ 記憶装置
３８ ドライバ
３９ 記憶媒体
４１ 構成グラフリスト
４２ Ｉ／Ｏトラフィックリスト
４３ ストーリーデータ
１００ シミュレータ装置

Claims (5)

1. ソフトウェアを構成する複数のモジュール間のデータ入出力を解析してモジュールツリー構造を作成するモジュールツリー構造作成手段と、
   前記モジュール毎に負荷の程度を示す負荷テーブルを作成する負荷テーブル作成手段と、
   前記モジュールツリー構造の各モジュールを前記負荷テーブルによって示される前記負荷の程度を発生させる仮想ソフトウェアモジュールで置き換える置換手段と、
   前記モジュールが前記仮想ソフトウェアモジュールに置き換えられた前記モジュールツリー構造に基づいて仮想ソフトウェアを生成する仮想ソフトウェア生成手段と、
   を有するようにした仮想ソフトウェア生成装置。
2. 前記負荷テーブル作成手段は、前記負荷テーブルを作成する際に、演算量、データ量、データ入出力先の項目と、モジュール毎にデータ入出力及びデータ量を解析して生成したトラフィックリストを用いて、連続、断続、ランダムに分類した該データ入出力に係るアクセスパターンの項目とによって前記負荷の程度を示すようにした請求項１記載の仮想ソフトウェア生成装置。
3. 前記負荷テーブルを用いて、前記負荷の程度をパラメータとするフラグメントパーツに前記モジュールの該負荷の程度をパラメータ値として与えて前記仮想ソフトウェアモジュールを生成する仮想ソフトウェアモジュール生成手段を更に有するようにした請求項１又は２記載の仮想ソフトウェア生成装置。
4. 前記ソフトウェアを構成する複数のモジュールに対してユーザによって前記仮想ソフトウェアモジュールに置き換える又は置き換えないことを選択させるモジュール選択手段を更に備え、
   前記置換手段は、置き換えないモジュールに対しては、該モジュールのソースコードを用いるようにした請求項１乃至３のいずれか一項記載の仮想ソフトウェア生成装置。
5. 前記仮想ソフトウェア生成手段は、ハードウェアのシミュレーション環境上で動作可能な前記仮想ソフトウェアを生成して出力するようにした請求項１乃至４のいずれか一項記載の仮想ソフトウェア生成装置。