JP5287132B2 - 設計支援プログラム、設計支援装置、およびシミュレーションモデル - Google Patents

Description

この発明は、測定ポイントからのリクエストを測定対象に与えて当該リクエストに応じたシミュレーションを実行する設計支援プログラム、設計支援装置、およびシミュレーションモデルに関する。

一般に、被測定モデルのシミュレーションでは、外部からのリクエストから外部へのレスポンスを出力するまでの間、被測定モデルは時間経過に沿って途中処理の入出力を発生する。システム性能とは、これらの処理時間（要求から応答までのレイテンシ）や途中発生するトラフィックが、他のハードウェア部品と相互に影響を及ぼしあいながら決定されるものである。

したがって、被測定モデルが途中処理のために入出力をおこなった場合、システム上において、バスなどの共有するデバイス上でこの入出力が他のハードウェア部品の入出力と衝突した場合、順番待ちが発生することにより、応答性能は間延びしていく。このため、システム性能としては、着目した被測定モデルは、他のハードウェア部品との相互作用がない理想的な状態に比べて、待ち時間によるオーバーヘッドを発生する。さらにこのオーバーヘッドが、他の部品の動作の挙動をみだし、他の部品の乱された挙動が、再び被測定モデルの挙動に影響を与える。

また、このような相互作用の結果、極端にオーバーヘッドが大きくなるような部分は、システム性能のボトルネックとして捉えられ、チューニングの対象となる。オーバーヘッドを測定するため、もっとも正確な値を得るには実際のデバイスを利用し、現物のシステムを構築、測定することになる。

しかし、この測定を実施するためには、コストと時間をかけデバイスの配線を行い、工場を稼動させシリコンを引き上げ、評価ボード環境を開発しなければならない。ここで得られた結果に問題があった場合、再度設計からやりなおし、再びシリコンの段階へもどらなければならない。そこで、近年、システムＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ）の開発時におけるシミュレーションによる設計技術が進められている。主にこれはＥＳＬ（Ｅｌｅｃｔｒｏｎｉｃ Ｓｙｓｔｅｍ Ｌｅｖｅｌ）技術と呼ばれ、システムＬＳＩの設計を、段階ごとに詳細性（抽象性）を変えながら設計を行う技術である。

図１６は、ＥＳＬ技術の開発工程を示す説明図である。ＥＳＬでは、（Ａ）システム全体設計、（Ｂ）ハードウェア（ＨＷ）設計、（Ｃ）ＨＷ実装、（Ｄ）ソフトウェア（ＳＷ）設計およびＳＷ実装の順に開発がおこなわれる。また、図１６において、抽象度が低いほど詳細化される。Ｆｕｎｃｔｉｏｎ／Ｉｎｓｔｒｕｃｔｉｏｎ Ｌｅｖｅｌが最も抽象度が高く、Ａｃｃｕｒａｃｙ Ｌｅｖｅｌが中程度、そして、Ｃｙｃｌｅ Ｌｅｖｅｌが最も低い抽象度である。

（Ａ）システム全体設計は高い抽象度から低い抽象度まで網羅する。具体的には、機能、結線レベルのシミュレーションを実行し、概略的な性能や傾向をつかむ。（Ｂ）ＨＷ設計では、抽象度が必ずしもＣｙｃｌｅ Ｌｅｖｅｌである必要はなく、論理設計の補助として実施される。（Ａ）よりも高い精度で設計を詰めることとなる。

（Ｃ）ＨＷ実装では、ＲＴＬ（Ｒｅｇｉｓｔｅｒ Ｔｒａｎｓｆｅｒ Ｌｅｖｅｌ）論理シミュレーション検証フェーズに対して、１００％に近い精度で検証することができる。すなわち、（Ｃ）では実装の正しさが検証されるため、曖昧性はなく、最も低い抽象度が求められる。（Ｄ）ＳＷ設計およびＳＷ実装は、機能検証のためにおこなわれるフェーズであり、高速シミュレーションが求められる。（Ｄ）ではソフトウェアのフェーズであるため、ハードウェアの詳細な動作は関係ないため、曖昧さがあってもよい。

このように、従来では、異なる抽象度のシミュレーションが必要になった場合、大別して以下の３つの手法を用いていた。
（１）最も抽象度の低い（精度の高い）シミュレーションモデルを準備し、すべての設計フェーズに適用をおこなう。
（２）ＲＴＬ設計データなどの実設計データから、翻訳ツールを用いてＥＳＬシミュレーションモデルをコンパイルにより生成する。
（３）（Ａ）〜（Ｃ）個々のフェーズで必要とされる抽象度をもつシミュレーションモデルを別々に作成する。

また、各種抽象度を用いた設計技術については、下記特許文献１〜４が開示されている。
特開２００７−１１４７７号公報 特開２０００−２５９６８３号公報 特開平１０−２４０５８２号公報 特開２００６−２２１４７４号公報

しかしながら、上述した従来手法（１）では、ソフトウェアの大局的な動作をトレースしたい場合、必要以上の精度でシミュレーションが動作してしまうこととなり、シミュレーション自体の時間がかかってしまう。たとえば、（Ａ）や（Ｂ）のフェーズにおいて（Ｃ）の抽象度のシミュレーションモデルを使用すると、詳細なシミュレーション結果は得られるが、シミュレーション速度が低下する。（Ａ）や（Ｂ）のフェーズでは、システム全体の動作がわかれば十分であり、詳細な情報は不要であるため、シミュレーション時間がかかり、本来のＥＳＬシミュレーションの目的とする高抽象度動作における高速性を生かすことができないという問題があった。

また、上述した従来手法（２）では、ＲＴＬ設計データを準備することが必須であり、ＲＴＬ設計データが存在しない場合には適用することができない。本来、ＥＳＬシミュレーションではＲＴＬ設計を完成させるために実施するためのシミュレーションであるが、従来手法（２）では、ＲＴＬ設計を完了してあることが前提となるため、設計工数が増大するという問題があった。

また、上述した従来手法（３）では、最も単純で所望の抽象度のシミュレーションモデルを得ることができるが、シミュレーションモデルの開発者は個々のフェーズに対して、個々のシミュレーションモデルを開発する必要性がある。したがって、フェーズごとに当該フェーズに応じた抽象度のシミュレーションモデルを作成すると、その抽象度モデルの作成に負担や工数がかかるという問題があった。

また、上述した特許文献１〜４の技術では、すべての抽象度には対応していないため、上述した従来手法（１）〜（３）と同様の問題が生じることとなる。このように、（Ａ）〜（Ｃ）のフェーズにおいて、不足している抽象度のシミュレーションモデルをあらたに作成しても、また、既存の抽象度のシミュレーションモデルを他のフェーズに流用しても、設計期間が長期化するという問題があった。

本開示技術は、上述した従来技術による問題点を解消するため、シミュレーション段階での抽象度変更に柔軟に対応して設計期間の短縮化を図ることができる設計支援プログラム、設計支援装置、およびシミュレーションモデルを提供することを目的とする。

上述した課題を解決し、目的を達成するため、この設計支援プログラム、設計支援装置、およびシミュレーションモデルは、測定対象に測定ポイントからのリクエストを与えて当該リクエストに応じたシミュレーションを実行するにあたって、前記リクエストを解析し、前記リクエストの解析内容および開発工程に関する抽象度から選ばれた任意の抽象度に応じて、前記シミュレーションにおける各処理の演算結果に関する擬似トラフィックを生成し、前記選ばれた任意の抽象度が特定の抽象度である場合、リクエスト種別に応じたトラフィックに関する出力波形を記憶するデータベースの中から、前記リクエストに該当する前記測定対象からの平均化された出力波形を抽出することにより、当該平均化された出力波形に応じた擬似トラフィックを生成し、前記各処理の所要時間を当該所要時間よりも短い所要時間に設定し、前記リクエストにより前記シミュレーションが開始された場合、前記各処理の演算結果を前記測定対象に読み書きさせ、生成された擬似トラフィックおよび前記リクエストに対する前記測定対象からのレスポンスを入力して、前記短い所要時間の積算時間経過後でかつ前記擬似トラフィックの出力終了後に前記レスポンスを出力することを要件とする。

この設計支援プログラム、設計支援装置、およびシミュレーションモデルによれば、指定された抽象度に応じたシミュレーションを１種のシミュレーションモデルで実行することができる。

この設計支援プログラム、設計支援装置、およびシミュレーションモデルによれば、シミュレーション段階での抽象度変更に柔軟に対応して設計期間の短縮化を図ることができるという効果を奏する。

以下に添付図面を参照して、この設計支援プログラム、設計支援装置、およびシミュレーションモデルの好適な実施の形態を詳細に説明する。

（本実施の形態の概要）
図１は、本実施の形態の概要を示す説明図である。図１において、設計対象であるシステムＬＳＩモデル１００では、被測定モデル１０１と測定ポイント（バスや周辺ハードウェアモデル）１０２とがバス１０３を介して接続されている。被測定モデル１０１とは、本実施の形態での測定対象となるハードウェアモデルである。測定ポイント１０２とは、被測定モデル１０１以外のハードウェアモデルであり、被測定モデル１０１におけるシミュレーションの挙動を観測する。すなわち、被測定モデル１０１に対してリクエストを送信したり、被測定モデル１０１からのレスポンスを受信する。

本実施の形態では、被測定モデル１０１とバス１０３との間に可変抽象ラッパ１０４を挿入する。可変抽象ラッパ１０４とは、被測定モデル１０１をラッピングするシミュレーションモデルである。可変抽象ラッパ１０４は、高抽象度（Ｆｕｎｃｔｉｏｎ／Ｉｎｓｔｒｕｃｔｉｏｎ Ｌｅｖｅｌ）、中抽象度（Ａｃｃｕｒａｃｙ Ｌｅｖｅｌ）、低抽象度（Ｃｙｃｌｅ Ｌｅｖｅｌ）のどの抽象度にも可変可能なシミュレーションモデルである。抽象度は、ユーザ操作により設定される。

この可変抽象ラッパ１０４にあらかじめ抽象度を指定しておき、測定ポイント１０２から被測定モデル１０１にリクエストを送信すると、可変抽象ラッパ１０４が被測定モデル１０１にリクエストを出力する。被測定モデル１０１では、リクエストに応じたシミュレーションが実行される。一方、可変抽象ラッパ１０４はリクエストを解析して、リクエストに応じたシミュレーションの擬似トラフィックを測定ポイント１０２に返す。その後、可変抽象ラッパ１０４は、被測定モデル１０１からの最終演算結果をレスポンスとして測定ポイント１０２に返す。

この可変抽象ラッパ１０４は、ライブラリに保存されており、ユーザ操作によりユーザが操作するシミュレータ内の記憶装置に書き込む。また、被測定モデル１０１と測定ポイント１０２とバス１０３を含むシステムＬＳＩモデル１００も記憶装置に読み込んでおき、抽象度を指定することで、シミュレータによりシミュレーションを実行することとなる。

（可変抽象ラッパ１０４）
図２は、可変抽象ラッパ１０４の機能的構成を示すブロック図である。各ブロックは、ハードウェアをモデル化したＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）などのソフトウェア部品である。可変抽象ラッパ１０４は、トラフィック制御器２０１とトラフィック生成器２０２と内部メモリ２０３とを含む構成である。

トラフィック制御器２０１は、被測定モデル１０１と測定ポイント１０２との間の通信（入出力）を制御する機能を有する。トラフィック制御器２０１は、具体的には、測定ポイント１０２からの信号を分解出力するデマルチプレクサの機能を有する。たとえば、測定ポイント１０２から被測定モデル１０１へのリクエストが受信されると、被測定モデル１０１に出力するとともに、トラフィック生成器２０２にも出力する。

また、トラフィック制御器２０１は、具体的には、トラフィック生成器２０２と被測定モデル１０１とからの信号を合成出力するマルチプレクサの機能を有する。たとえば、トラフィック生成器２０２からの擬似トラフィックを優先して測定ポイント１０２に送信し、擬似トラフィックの送信が終了すると、被測定モデル１０１の最終演算結果であるレスポンスを測定ポイント１０２に送信する。

トラフィック生成器２０２は、パーサ２２１とトラフィックデータベース（ＤＢ）２２２とシーケンサ２２３とＩ／Ｏジェネレータ２２４とを備える。パーサ２２１はトラフィック制御器２０１からのリクエストを解析する。トラフィックＤＢ２２２は、リクエスト種別後との波形データを記憶する。シーケンサ２２３は基本クロックを出力する。Ｉ／Ｏジェネレータ２２４はトラフィックＤＢ２２２から抽出された波形データと基本クロックを合成して擬似トラフィックを生成する。

また、内部メモリ２０３は、被測定モデル１０１が発生する実トラフィックを吸収する役割を持つハードウェアモデルである。内部メモリ２０３は、被測定モデル１０１の実トラフィックをリード／ライトする機能を有する。また、シミュレーションが終了すると内部メモリに書き込まれた最終演算結果をレスポンスとしてトラフィック制御器２０１に出力する。

＜トラフィックＤＢ２２２＞
図３は、トラフィックデータベース（ＤＢ）の記憶内容を示す説明図である。トラフィックＤＢ２２２は、リクエストＩＤと波形データとをフィールド項目として有する。また、波形データのフィールド項目は、中抽象度と低抽象度とをサブフィールド項目として有する。そして、レコードごとに、リクエストについてのリクエストＩＤ：ｉ、中抽象度の波形データＷｉ、低抽象度の波形データｗｉとを記憶する。これにより、リクエストＩＤと抽象度が特定されれば、それに応じた波形データを抽出することができる。なお、以降、リクエストＩＤ：ｉのリクエストを「リクエストｉ」と表記する。

また、すでに開発済みの被測定モデル１０１に対しては、改版などを実施する場合は、ＲＴＬまたは実機で計測した波形データｗｉを記憶しておくことができ、また、これから開発する被測定モデル１０１については、仕様書で計画されている入出力のトラフィックの期待値を波形データｗｉとして記憶しておくことになる。

たとえば、実際に与えられる波形データｗｉのデータ構成は、以下のような形式となる。

大分類：被測定モデル１０１が外部のバス１０３などから要求されるデータコマンド
例）０ｘ００００ ０ｘ０１：オフセット００００に対して、０ｘ０１（処理Ｘ）を示す命令
・小分類：コマンドに対して生成する内部データ授受のための外部アクセス
例）０ｘ００１０ ０ｘ００：レイテンシ＋０ｘ１０サイクルで０ｘ００（リードリクエスト）
・小分類：コマンドに対して生成する内部データ授受のための外部アクセス
例）０ｘ０００５ ０ｘ０１：さらに＋０ｘ０５サイクルで０ｘ０１（ライトリクエスト）
・小分類：コマンドに対して生成する内部データ授受のための外部アクセス
例）０ｘ００ｆｆ ０ｘｆｆ：レイテンシ＋０ｘ００ｆｆサイクルで０ｘｆｆ（終了コード）発行

入力に対しては、内部レジスタなどの相対アドレス、外部アクセスに対しては、特定のアクセス先アドレスを保有せず、単にリードやライトリクエストがどのタイミングで出て行くかを記述したものである。実際には、リクエストが発行される間隔には、被測定モデル１０１が内部処理する時間が積まれていることになり、たとえば上述の例であれば、処理Ｘを要するのに、被測定モデル１０１が内部処理のために最初のリードリクエストを発行するまでに０ｘ１０サイクルを要することをシミュレートしていることになる。

このリクエストの間隔はあくまで理想的な時間で応答を示した場合を意味し、たとえば他のデバイスとの相互影響でリクエスト発行が遅れた場合、最初のリードリクエストは０ｘ１０サイクルから相互作用によって遅らせられるだけの時間の間隔があくことになる。

このような遅延は、ＥＳＬシミュレーションそのものの機構により実現されるもので、本実施の形態の可変抽象ラッパ１０４では、上記例に従うと、０ｘ１０サイクル目にリクエストを発行し、最低０ｘ０５のクロックを消費しつつ、外部の影響を受けながら、次のリクエストを発行することになる。

図４は、波形データの一例を示す説明図である。（Ａ）は、リクエストｉにおいて実際に測定された波形データｗｉの一例である。波形データｗｉは、実際のシミュレーションを完全再現しており、低抽象度が指定された場合に抽出される波形データである。

（Ｂ）は、波形データｗｉを平均化した波形データＷｉである。（Ａ）では時刻１０までの間にアクセス発生を示すパルスが５回発生しているため、時刻２間隔でパルスが発生した波形データＷｉに変換される。中抽象度が指定された場合に抽出される波形データである。

（Ｃ）は（Ｂ）の波形データＷｉを圧縮化した波形データＶｉである。波形データＶｉは波形データＷｉの基本周期分の波形であり、反復回数（この場合は５回）も記憶する。（Ｃ）のように記憶させておく場合、中抽象度が指定されると、（Ｂ）の波形データＷｉに展開される。

図４に示した波形データｗｉは、時刻０から処理を開始し、時刻３前後でアクセスが集中的に発生し、時刻９で終了するパターンを表現している。この場合、各時刻単位で完全再現をおこなう場合、擬似トラフィックとしては波形データｗｉをそのまま生成することになるが、より長い時間の観点、すなわち、上記の時刻単位が［ｎｓ］であり、測定を行いたい範囲が［ｍｓ］の場合、１０⁶の単位差があるため、このような詳細なパターンである波形データｗｉから擬似トラフィックを生成することが不必要なケースが生じる。また、詳細なパターンが不要なだけでなく、完全再現することによるシミュレーション時間の増大という問題も出てくる。

このような場合、上述したように、単純な平均値を求めて波形データＷｉの擬似トラフィックを簡略化することで、より高速に動作させ、かつ、所望の精度で結果を得ることができる。上記のパターンでは、アクセスは時刻１０までの間に５回でているため、単純に１０÷５＝２を実施することで、時刻２単位で１つのアクセスを発生するようなシナリオに変換する。

これにより、波形データＷｉの擬似トラフィックを生成するときには、リクエスト送出のタイミングを計測する必要がなくなるので、シミュレーション速度が向上する。精度は完全再現の波形データｗｉよりも低いが、トラフィック総量が同じであることと、大域的に捉えた場合のおおまかな挙動を把握するには十分な精度をもたせることができる。

また、指定された抽象度が高抽象度である場合、すなわち、リクエストに対して、時間概念を加味せずレスポンスのみを返すようなシミュレーションに用いられる場合、トラフィックＤＢ２２２から波形データＷｉ，ｗｉのいずれも抽出されない。この場合は、擬似トラフィックが生成されないこととなる。

＜トラフィック生成器２０２＞
図５は、トラフィック生成器２０２の内部構成を示すブロック図である。トラフィック生成器２０２は、パーサ２２１とＩ／Ｏ（ＩＮＰＵＴ／ＯＵＴＰＵＴ）ジェネレータ２２４とを含む構成である。パーサ２２１は、トラフィック制御器２０１からのリクエストの内容を解析する。具体的には、たとえば、リクエストに埋め込まれているリクエストＩＤを抽出して、該当する波形データをトラフィックＤＢ２２２から検索する。

シーケンサ２２３は、基本クロックｃｌｋをＩ／Ｏジェネレータ２２４に供給する機能を有する。Ｉ／Ｏジェネレータ２２４は合成器２２５を備え、パーサ２２１によりトラフィックＤＢ２２２から抽出された対象波形データを基本クロックに同期させる。そして、この同期後の波形データ上のアクセス発生を示すパルスを擬似トラフィックとして時系列に出力する。

図６は、擬似トラフィックに着目したシーケンス図である。縦軸は時間軸であり、下に行くほど時間が経過する。また時間軸上の矩形は、各ハードウェアモデルの処理に要した所要時間を示しており、長いほど時間がかかっていることを示す。所要時間ｔａは、測定ポイント１０２におけるリクエストの処理に要した時間である。所要時間ｔｂは、トラフィック制御器２０１のデマルチプレクサの処理に要した時間である。所要時間ｔｃは、被測定モデル１０１におけるシミュレーションの各処理に要した所要時間の総所要時間（積算時間）である。図６では便宜上、若干の時間を要しているが、後述する内部メモリ２０３の処理により、総所要時間を０［ｎｓｅｃ］とすることができる。

所要時間ｔｄは、トラフィック制御器２０１からの擬似トラフィックＴの送信に要した時間である。所要時間ｔｅは、トラフィック制御器２０１のマルチプレクサの処理、すなわち、被測定モデル１０１からのレスポンスの処理に要した時間である。所要時間ｔｆは、測定ポイント１０２におけるレスポンスの処理に要した時間である。図６に示したように、所要時間ｔｂの経過後、擬似トラフィックＴを生成すると、被測定モデル１０１の挙動にかかわらず、所要時間ｔｄの間、トラフィック制御器２０１が独立して擬似トラフィックＴを出力する。

トラフィック制御器２０１は、被測定モデル１０１からレスポンスを受けると、マルチプレクサとして動作し、擬似トラフィックＴとレスポンスとを調停する。擬似トラフィックＴは、トータルの出力時間、すなわち、所要時間ｔｄがトラフィックＤＢ２２２において既知であるため、その所要時間ｔｄが経過するまでは、擬似トラフィックＴの出力を継続し、その所要時間ｔｄが経過した時点で、レスポンスが受け付けられている場合、そのレスポンスを測定ポイント１０２に出力する。所要時間ｔｄの経過時点でレスポンスが受け付けられていない場合、レスポンスが受け付けられるまで待機することとなる。

このように、擬似トラフィックＴは与えられた抽象度により、動作中の擬似トラフィックＴの挙動を変える。測定ポイント１０２から見た場合、擬似トラフィックＴが被測定モデル１０１から直接出力されていることとなる。このとき、擬似トラフィックＴに相当する部分は途中演算結果や処理の中間データであるため、測定ポイント１０２からすると単なる負荷でしかなく、擬似トラフィックＴの内部がランダムなデータであっても問題はない。

＜内部メモリ２０３＞
内部メモリ２０３は、被測定モデル１０１が発生する入出力信号を吸収させる役割を持つハードウェアモデルである。具体的には、たとえば、メモリ内のアドレス空間として定義される。内部メモリ２０３は、被測定モデル１０１のシミュレーション中の演算結果が書き込まれたり、読み出されたりする。

図７は、内部メモリ２０３の動作に着目したシーケンス図である。図６と同一所要時間には同一符号を付し、その説明を省略する。内部メモリ２０３は、レイテンシ０となる理想的なデバイスとして機能させることができる。このため、実トラフィックＤは内部メモリ２０３に吸収されるが、所要時間ｔｃは０とみなされ、高速に動作する。

具体的には、たとえば、被測定モデル１０１がシミュレーション動作した場合、可変抽象ラッパ１０４の外部へのアクセスに対しても、動作時間を計上していくシミュレーションを実行するが、内部では動作時間ごとに下記式（１）のような計算を実行する。

Δ＝∫ｔＤ（ｔ）×δｄｔ・・・（１）

ただし、Δは、外部に対する１アクセスに要するレイテンシであり、上述した動作時間となる。また、δは、外部接続されたバス１０３の単位転送量に対するレイテンシである。また、Ｄ（ｔ）は、時刻ｔにおける外部のバス１０３へのアクセス量である。

シミュレーションでは、このレイテンシΔをすべて積算した上で、最終的な演算結果を返すこととなるが、可変抽象ラッパ１０４では、被測定モデル１０１のデータアクセスを隠蔽するために、内部メモリ２０３を理想的なメモリとして、常にレイテンシΔがΔ＝０となるように設定する。これはＳｙｓｔｅｍＣの記述特有の性質であり、この内部メモリ２０３ではこの性質を利用することで、シミュレーション速度の高速化を図る。

具体的には、理想的な内部メモリ２０３への経路では、δ＝０が成り立ち、Δ＝０が成り立つ。ＳｙｓｔｅｍＣは一種のＣ言語であり、コンパイラによる翻訳が行われる。このときコンパイラは一般的な最適化を行うため、係数であるδ＝０の演算を省略し、固定値としてΔ＝０を直接定数として返すことになる。したがって、積算演算を行わない（所要時間ｔｃ＝０）こととなる。これにより、被測定モデル１０１は高速動作することになる。

特に、指定された抽象度が低抽象度の場合では、被測定モデル１０１では、正確な波形出力をおこなうこととなるため、シミュレーション時間が長大になり、全体の挙動を把握したいような場合には不向きとなる。しかしながら、上述したレイテンシΔの設定処理により、被測定モデル１０１からの中間トラフィックを吸収するだけでなく、この内部メモリ２０３がシミュレーションとしてレイテンシΔ＝０の理想的なメモリとして動作することになる。したがって、被測定モデル１０１のシミュレーション時間そのものを短くさせる働きをもたせることができる。

（設計支援装置）
つぎに、本実施の形態の設計支援装置について説明する。設計支援装置とは、被測定モデル１０１と測定ポイント１０２との間に可変抽象ラッパ１０４を挿入して被測定モデル１０１をシミュレーションするシミュレータである。

＜設計支援装置のハードウェア構成＞
図８は、実施の形態にかかる設計支援装置のハードウェア構成を示すブロック図である。図８において、設計支援装置は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）８０１と、ＲＯＭ（Ｒｅａｄ‐Ｏｎｌｙ Ｍｅｍｏｒｙ）８０２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）８０３と、磁気ディスクドライブ８０４と、磁気ディスク８０５と、光ディスクドライブ８０６と、光ディスク８０７と、ディスプレイ８０８と、Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）８０９と、キーボード８１０と、マウス８１１と、スキャナ８１２と、プリンタ８１３と、を備えている。また、各構成部はバス８００によってそれぞれ接続されている。

ここで、ＣＰＵ８０１は、設計支援装置の全体の制御を司る。ＲＯＭ８０２は、ブートプログラムなどのプログラムを記憶している。ＲＡＭ８０３は、ＣＰＵ８０１のワークエリアとして使用される。磁気ディスクドライブ８０４は、ＣＰＵ８０１の制御にしたがって磁気ディスク８０５に対するデータのリード／ライトを制御する。磁気ディスク８０５は、磁気ディスクドライブ８０４の制御で書き込まれたデータを記憶する。

光ディスクドライブ８０６は、ＣＰＵ８０１の制御にしたがって光ディスク８０７に対するデータのリード／ライトを制御する。光ディスク８０７は、光ディスクドライブ８０６の制御で書き込まれたデータを記憶したり、光ディスク８０７に記憶されたデータをコンピュータに読み取らせたりする。

ディスプレイ８０８は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。このディスプレイ８０８は、たとえば、ＣＲＴ、ＴＦＴ液晶ディスプレイ、プラズマディスプレイなどを採用することができる。

インターフェース（以下、「Ｉ／Ｆ」と略する。）８０９は、通信回線を通じてＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどのネットワーク８１４に接続され、このネットワーク８１４を介して他の装置に接続される。そして、Ｉ／Ｆ８０９は、ネットワーク８１４と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。Ｉ／Ｆ８０９には、たとえばモデムやＬＡＮアダプタなどを採用することができる。

キーボード８１０は、文字、数字、各種指示などの入力のためのキーを備え、データの入力をおこなう。また、タッチパネル式の入力パッドやテンキーなどであってもよい。マウス８１１は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などをおこなう。ポインティングデバイスとして同様に機能を備えるものであれば、トラックボールやジョイスティックなどであってもよい。

スキャナ８１２は、画像を光学的に読み取り、設計支援装置内に画像データを取り込む。なお、スキャナ８１２は、ＯＣＲ（Ｏｐｔｉｃａｌ Ｃｈａｒａｃｔｅｒ Ｒｅａｄｅｒ）機能を持たせてもよい。また、プリンタ８１３は、画像データや文書データを印刷する。プリンタ８１３には、たとえば、レーザプリンタやインクジェットプリンタを採用することができる。

＜設計支援装置の機能的構成＞
図９は、本実施の形態にかかる設計支援装置の機能的構成を示すブロック図である。図９において、設計支援装置９００は、指定部９０１と、解析部９０２と、生成部９０３と、設定部９０４と、記憶部９０５と、制御部９０６と、を含む構成である。これら各機能は、具体的には、たとえば、図８に示したＲＯＭ８０２、ＲＡＭ８０３、磁気ディスク８０５、光ディスク８０７などの記憶装置に記憶されたプログラムを、ＣＰＵ８０１に実行させることにより、またはＩ／Ｆ８０９により、その機能を実現する。

被測定モデル１０１および測定ポイント１０２は、図８に示したＲＯＭ８０２、ＲＡＭ８０３、磁気ディスク８０５、光ディスク８０７などの記憶装置内の所定の記憶領域上に展開されたシミュレーションモデルである。

指定部９０１は、開発工程に関する抽象度の指定を受け付ける機能を有する。具体的には、たとえば、キーボード８１０やマウス８１１を捜査することで抽象度の指定を受け付ける。この抽象度とは、上述した高抽象度（Ｆｕｎｃｔｉｏｎ／Ｉｎｓｔｒｕｃｔｉｏｎ Ｌｅｖｅｌ）、中抽象度（Ａｃｃｕｒａｃｙ Ｌｅｖｅｌ）、低抽象度（Ｃｙｃｌｅ Ｌｅｖｅｌ）の３種の抽象度である。指定された抽象度は、図８に示したＲＯＭ８０２、ＲＡＭ８０３、磁気ディスク８０５、光ディスク８０７などの記憶装置に保持される。

解析部９０２は、測定ポイント１０２からのリクエストを解析する機能を有する。この解析部９０２は、上述した可変抽象ラッパ１０４のパーサ２２１に相当する機能であり、図８に示したＲＯＭ８０２、ＲＡＭ８０３、磁気ディスク８０５、光ディスク８０７などの記憶装置内の所定の記憶領域上に可変抽象ラッパ１０４が展開されることにより実行可能である。解析結果は、図８に示したＲＯＭ８０２、ＲＡＭ８０３、磁気ディスク８０５、光ディスク８０７などの記憶装置に保持される。

生成部９０３は、解析部９０２によるリクエストの解析内容および指定部９０１によって指定された抽象度に応じて、シミュレーションにおける各処理の演算結果に関する擬似トラフィックＴを生成する機能を有する。この生成部９０３は、上述したトラフィックＤＢ２２２、シーケンサ２２３、Ｉ／Ｏジェネレータ２２４に相当する機能であり、図８に示したＲＯＭ８０２、ＲＡＭ８０３、磁気ディスク８０５、光ディスク８０７などの記憶装置内の所定の記憶領域上に可変抽象ラッパ１０４が展開されることにより実行可能である。

生成部９０３は、上述したように、解析内容であるリクエストＩＤと指定抽象度によりトラフィックＤＢ２２２から波形データを抽出する。この抽出した波形データを、シミュレーションにおける各処理の演算結果を指定抽象度に応じた擬似トラフィックＴとして測定ポイント１０２に出力することとなる。この擬似トラフィックＴは、図８に示したＲＯＭ８０２、ＲＡＭ８０３、磁気ディスク８０５、光ディスク８０７などの記憶装置に保持され、時系列にしたがって順次出力される。なお、指定抽象度が高抽象度の場合は、擬似トラフィックＴは生成されない。

設定部９０４は、各処理の所要時間を当該所要時間よりも短い所要時間に設定する機能を有する。ここで、処理とは、シミュレーションにおける内部メモリ２０３に対するアクセスであり、所要時間とは一アクセスのレイテンシΔに相当する。各レイテンシΔの値が既知である場合には、その値よりも短く設定することにより、シミュレーション速度の向上を図ることができる。特に、設定部９０４では、このレイテンシΔをΔ＝０とするのが計算上および設定上最も好ましい。レイテンシΔ＝０とすることで、上述したようにシミュレーションの所要時間を０にすることができる。

この設定部９０４は、上述した内部メモリ２０３に相当する機能であり、図８に示したＲＯＭ８０２、ＲＡＭ８０３、磁気ディスク８０５、光ディスク８０７などの記憶装置内の所定の記憶領域上に可変抽象ラッパ１０４が展開されることにより実行可能である。すなわち、内部メモリ２０３に上述したレイテンシΔやレイテンシδの値（＝０）が埋め込まれているため、たとえば、シミュレーションの開始を契機として、被測定モデル１０１にレイテンシδおよびレイテンシΔを渡して、上述した式（１）により動作時間であるレイテンシΔをアクセスごとに被測定モデル１０１が計算することとなる。

記憶部９０５は、リクエストによりシミュレーションが開始された場合、各処理の演算結果を被測定モデル１０１に読み書きさせる機能を有する。この記憶部９０５は、上述した内部メモリ２０３に相当する機能であり、図８に示したＲＯＭ８０２、ＲＡＭ８０３、磁気ディスク８０５、光ディスク８０７などの記憶装置内の所定の記憶領域上に可変抽象ラッパ１０４が展開されることにより実行可能である。

制御部９０６は、入出力を制御する機能を有する。具体的には、たとえば、リクエストを入力して被測定モデル１０１および解析部９０２に出力するデマルチプレクサの機能を有する。より具体的には、リクエストを受け付けると、デマルチプレクサに制御信号を与える。デマルチプレクサでは、制御信号が与えられると、リクエストを分岐して被測定モデル１０１および解析部９０２に出力する。

また、制御部９０６は、マルチプレクサの機能を有する。具体的には、生成部９０３によって生成された擬似トラフィックＴおよびリクエストに対する被測定モデル１０１からのレスポンスを入力して、いずれか一方を測定ポイント１０２に出力する。この調停は、設定部９０４によって設定された短い所要時間の積算時間経過後でかつ擬似トラフィックＴの出力終了後にレスポンスを測定ポイント１０２に出力する。なお測定ポイント１０２に出力された擬似トラフィックＴやレスポンスは、ディスプレイ８０８に送られ表示画面に表示される。また、Ｉ／Ｆ８０９から他のコンピュータに送信してもよい。

設定部９０４によりシミュレーション時間が見かけ上０と計数されるため、レスポンスは早期に返ってくる。このとき、擬似トラフィックＴの出力が終了していない場合は、擬似トラフィックＴを選択出力しつづける。擬似トラフィックＴが出力し終わると、レスポンスを選択出力する。この制御部９０６は、上述したトラフィック制御器２０１に相当する機能であり、図８に示したＲＯＭ８０２、ＲＡＭ８０３、磁気ディスク８０５、光ディスク８０７などの記憶装置内の所定の記憶領域上に可変抽象ラッパ１０４が展開されることにより実行可能である。

＜設計支援処理手順＞
図１０は、本実施の形態にかかる設計支援装置９００による設計支援処理手順を示すフローチャートである。まず、指定部９０１により抽象度が指定されるのを待ち受け（ステップＳ１００１：Ｎｏ）、抽象度が指定された場合（ステップＳ１００１：Ｙｅｓ）、リクエストを待ち受ける（ステップＳ１００２：Ｎｏ）。リクエストが被測定モデル１０１に与えられた場合（ステップＳ１００２：Ｙｅｓ）、被測定モデル１０１のシミュレーションを実行する（ステップＳ１００３）。そして、シミュレーションが終了するのを待ち受け（ステップＳ１００４：Ｎｏ）、シミュレーションが終了した場合（ステップＳ１００４：Ｙｅｓ）、一連の処理を終了する。

図１１は、図１０のステップＳ１００３のシミュレーション時の可変抽象ラッパ１０４の動作を示すシーケンス図である。測定ポイント１０２からトラフィック制御器２０１にリクエストが与えられると、トラフィック制御器２０１はリクエストをパーサ２２１と被測定モデル１０１に分岐出力する。パーサ２２１は、リクエストを解析して、リクエストＩＤと指定抽象度とにより該当する波形データをトラフィックＤＢ２２２から抽出する。

そして、波形データをＩ／Ｏジェネレータ２２４に渡す。Ｉ／Ｏジェネレータ２２４は波形データを元にして擬似トラフィックＴを生成し、トラフィック制御器２０１に出力する。トラフィック制御器２０１では、擬似トラフィックＴが与えられると測定ポイント１０２に擬似トラフィックＴを返す。一方、被測定モデル１０１では、トラフィック制御器２０１からリクエストが与えられると、内部メモリ２０３に対して演算結果をリード／ライトする。

このとき、設定部９０４により、レイテンシΔの積算時間は０となる。これにより、待ち時間によるオーバーヘッドがなくなるため、シミュレーション速度が高速化する。そして最終演算結果であるレスポンスをトラフィック制御器２０１に出力する。トラフィック制御器２０１では、擬似トラフィックＴの出力中は、レスポンスを測定ポイント１０２に出力しない。擬似トラフィックＴが出力し終わると、レスポンスを測定ポイント１０２に出力する。

図１２は、トラフィック制御器２０１の制御動作を示すフローチャートである。図１２では、トラフィック制御器２０１のマルチプレクサの機能に着目して説明する。このマルチプレクサは、擬似トラフィックＴおよびレスポンスの２つの信号を入力していずれか一方を出力する２入力１出力の選択回路モデルであり、２つの制御端子を有する。１本は、選択信号Ｓ１を取り込む第１の制御端子であり、擬似トラフィックＴを選択してＯＮとなる。もう１本は、選択信号Ｓ２を取り込む第２の制御端子であり、レスポンスを選択してＯＮとなる。

初期状態では、選択信号Ｓ１，Ｓ２は取り込まれていないため、いずれも選択されずＯＦＦとなる。なお、この選択回路モデルのＯＮ／ＯＦＦ状態は、テーブル化されて保持されている。したがって、ＯＮ／ＯＦＦの切替はこのテーブルにアクセスすることでおこなわれる。

まず、トラフィック生成器２０２から擬似トラフィックＴが受信されたか否かを判断し（ステップＳ１２０１）、受信された場合（ステップＳ１２０１：Ｙｅｓ）、第１の制御端子がＯＮであるか否かを判断する（ステップＳ１２０２）。ＯＮでない場合（ステップＳ１２０２：Ｎｏ）、選択信号Ｓ１を与えて第１の制御端子をＯＮにして（ステップＳ１２０３）、ステップＳ１２０４に移行する。一方、第１の制御端子がＯＮである場合（ステップＳ１２０２：Ｙｅｓ）も、ステップＳ１２０４に移行する。これにより、擬似トラフィックＴが順次測定ポイント１０２に出力されることとなる。

ステップＳ１２０４では、擬似トラフィックＴが終了したか否かを判断する（ステップＳ１２０４）。擬似トラフィックＴの時間長はトラフィックＤＢ２２２から既知であるため、最初の擬似トラフィックＴを受信した時刻から計時して、その時間長分経過したか否かにより判断する。終了していない場合（ステップＳ１２０４：Ｎｏ）、ステップＳ１２０１に戻る。一方、終了した場合（ステップＳ１２０４：Ｙｅｓ）、第１の制御端子をＯＮからＯＦＦにして（ステップＳ１２０５）、ステップＳ１２０１に戻る。

一方、ステップＳ１２０１において、トラフィック生成器２０２から擬似トラフィックＴが受信されていない場合（ステップＳ１２０１：Ｎｏ）、具体的には、たとえば、受信されていないタイミングにおいて、被測定モデル１０１からレスポンスの受信があったか否かを判断する（ステップＳ１２０６）。

受信されていない場合（ステップＳ１２０６：Ｎｏ）、ステップＳ１２０１に戻る。一方、受信された場合（ステップＳ１２０６：Ｙｅｓ）、第１の制御端子がＯＮか否かを判断する（ステップＳ１２０７）。ＯＮである場合（ステップＳ１２０７：Ｙｅｓ）、擬似トラフィックＴの出力が終了していないため、レスポンスを保持しておき（ステップＳ１２０８）、ステップＳ１２０１に戻る。

一方、第１の制御端子がＯＮでない場合（ステップＳ１２０７：Ｎｏ）、第２の制御端子をＯＮにして（ステップＳ１２０９）、ステップＳ１２０１に戻る。これにより、受信されたレスポンスやすでに受信されて保持されているレスポンスを測定ポイント１０２に出力することができる。

また、高抽象度が指定された場合、擬似トラフィックＴが受信されないため、第１の制御端子はＯＦＦのままである。この場合においても、ステップＳ１２０７により、第２の制御端子をＯＮにすることで、レスポンスを測定ポイント１０２に出力することができる。

また、上述した実施の形態では、トラフィックＤＢ２２２には、波形データｗｉとして、被測定モデル１０１の実測波形データを記憶しておくこととしたが、被測定モデル１０１の仕様書から導き出された期待値となる波形データを記憶させておくこととしてもよい。

この場合、たとえば、動画処理ハードマクロを設計する際に、描画リクエストに対して描画結果を返す動きに対して、描画中の中間処理を外部メモリに一時領域を取りながら出力して動作させるほうがよいのか、内部に一時領域を実装して中間処理を外部に出さないほうがよいのかを検討するようなケースで用いられる。

具体的には、外部メモリに出す場合は可変抽象ラッパ１０４を用いずに被測定モデル１０１のシミュレーションを実行すればよく、外部メモリに出さない場合には、可変抽象ラッパ１０４を挿入して被測定モデル１０１のシミュレーションを実行すればよい。そして、この２つのシミュレーション結果を比較することでいずれを採用すべきかを検討することができる。

また、上述した実施の形態では、被測定モデル１０１として既知のシミュレーションモデルを用いたが、被測定モデル１０１が代替品のシミュレーションモデルであってもよい。この場合、被測定モデル１０１から発生する中間トラフィックが、これから設計をおこなうときの余計な外乱になるケースがある。このとき、代替品のシミュレーションモデルの仕様書から導き出された期待値となる波形データを記憶させておくこととしてもよい。これにより、代替品についても抽象度を可変させてシミュレーションを実行することができる。

また、上述した実施の形態では、測定対象として被測定モデル１０１（シミュレーションモデル）を用いて説明したが、代替のシミュレーションモデルがない、あるいは、ＲＴＬの設計情報もないような場合、実際には外部から購入した評価ボード、あるいは高速動作するＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）環境のような実ハードウェアを用いることとしてもよい。

図１３は、実ハードウェアを適用した場合のシミュレーション例を示す説明図である。図１３の場合、可変抽象ラッパ１０４のリクエストとレスポンスを送受する経路を、ＩＣＥ（ｉｎ ｃｉｒｃｕｉｔ ｅｍｕｌａｔｏｒ）などの外部通信機構１３０２を用いて実ハードウェア１３０１と接続する。

この場合、可変抽象ラッパ１０４の動作により、実ハードウェア１３０１から出力される実トラフィックＤを内部メモリ２０３で隠蔽することができる。したがって、実ハードウェア１３０１の実装を外部のバス１０３への影響度の変化をみながら変更しようとした場合に、擬似トラフィックＴをいろいろ操作することにより、多面的な評価をすることが可能となる。

また、試作段階のデバイスのシステム性能評価に適用することもできる。複数のハードウェア部品から構成されるＳｏＣ（Ｓｙｓｔｅｍ ｏｎ Ｃｈｉｐ）では、採択したハードウェア部品を変更することで、次世代モデルへと改版していく。たとえば、グラフィック処理機能をもつＳｏＣがあり、グラフィックアクセラレータをより高性能なものに変更しようとした場合、かつ、高性能なグラフィックアクセラレータは対象のＳｏＣに対して最適化を求められるようなケースが往々にしてある。

このとき、グラフィックアクセラレータは内部バッファの容量を変更することで性能が変化するが、必ずしもバッファを大容量化することでシステム性能が改善することはない。このような場合、図１３に示した実ハードウェア１３０１としてグラフィックアクセラレータを接続する。この接続方法は一般的であるため言及しない。

実際に動作を行うのは既存のグラフィックアクセラレータであり、本事例で検証を行おうとするバッファ段数の変更はできないものとする。バッファ段数が変化するということは、アクセラレータからグラフィック演算のトラフィックが外部のバス１０３へ出ることを意味する。ユーザはトラフィック生成器２０２に対して、拡張設計をした場合のトラフィックの見積もり量をトラフィックＤＢ２２２に記憶させておく。たとえば、既存のアクセラレータが２５６回のトラフィックを１回のアクセスで発生させる場合、単純なケースでは、バッファを１６段にすれば、１６回（２５６÷１６）、８段にすれば３２回と段階的にトラフィックが変化していく。

すなわち、１回の動作に対する実トラフィックＤを上述したような回数に変化させるようなシナリオをトラフィックＤＢ２２２に格納することになる。つぎに、実際のシミュレーションでは、グラフィックアクセラレータの実トラフィックＤを、既存部品を搭載した評価ボードである内部メモリ２０３（Ｅｖａ ｂｏａｒｄ Ｍｅｍｏｒｙ ｍｏｄｅｌ）に発生させる。一方で、バッファ段数を変化させた擬似トラフィックＴをトラフィック生成器２０２が生成することになる。これらの操作により、既存のハードウェア部品を変更することなく、改版時の設計変更から想定される改版時の動作をシミュレーションすることが可能になる。

図１４は、内部バッファを増加させた場合のハードウェア部品の性能変化を示すグラフである。図１４では、実際にこのシステムを仮想モデルとしてＥＳＬシミュレーションした結果である。確かにバッファ効果による外部のバス１０３への実トラフィックＤが減少することで、性能が上昇することがグラフから読み取れる。しかし、これらのシミュレーション予測は、従来のＲＴＬシミュレーションなどにより再現することができる。本実施の形態では、より上位の設計工程を想定しており、また、ＲＴＬシミュレーションでは実現不可能なソフト動作と連携した動きをシミュレーションする。

図１５は、内部バッファを増加させることによるシステムの性能変化を示すグラフである。図１５は、図１３に示したシステムを組み上げ、実際にＣＰＵからソフトウェアを動作させることにより、システムとして動作させた総実行時間を測定したものである。バッファ段数を増やすことにより発生する最終のデータフラッシュ（内部データの書き出し処理）がレスポンス時に集中して発生することによるバス１０３の瞬間的なトラフィック増大が、ソフトウェア動作を阻む。これにより、ソフトウェアの処理時間が延び、１６段のときに性能が悪化していく。

一方で、バッファ段数が少ない場合は、１回の処理の間、実トラフィックＤが分散するため、その間にＣＰＵがバス１０３を利用できる。また、グラフィックアクセラレータの処理効率は悪いが、システム全体としては効率的に動作することがわかる。本例は、あまりバッファを増やしても、全体としては効率がよくないことをシステムレベルで検証できた事例である。

このように、図１６に示したＥＳＬ技術の（Ａ）および（Ｂ）のフェーズにおいて、低抽象度であるＲＴＬモデルが用意されている場合、新規に中抽象度のシミュレーションモデルを開発すると、ＲＴＬとは全く異なる開発スキームで実装することとなる。この場合、モデル開発が二重となり開発工数および設計負担が増大するが、本実施の形態の可変抽象ラッパ１０４を適用することで、開発工数および設計負担の低減化を図ることができる。

また、ＥＳＬ技術の（Ａ）および（Ｂ）のフェーズにおいて、低抽象度であるＲＴＬモデルが用意されている場合、このＲＴＬモデルをＡ）および（Ｂ）のフェーズで流用すると、正しい結果は得られるが、シミュレーション時間に多大な時間を要する。特に、ＳｏＣの回路規模が大きくなるとシミュレーションが終了せず全体を見通すことが困難になるが、本実施の形態の可変抽象ラッパ１０４を適用することで、抽象度に応じたシミュレーションが可能となる。したがって、シミュレーション時間の短縮化を図ることができる。

また、ＥＳＬ技術の開発工程の（Ａ）および（Ｂ）のフェーズにおいて、高抽象度のシミュレーションモデルが存在する場合、高抽象度のシミュレーションモデルではファンクション動作しかしない。このため、データフローとタイミングがもたらすシステム状態を再現できないこととなる。また上述したように、新規に中抽象度モデルを開発すると、開発工数および設計負担が増大し、ＲＴＬモデルを流用すると、シミュレーション時間に多大な時間を要する。

したがって、本実施の形態の可変抽象ラッパ１０４を適用することで、高抽象度におけるシステム状態の再現、中抽象度における開発工数および設計負担の低減化、低抽象度におけるシミュレーション時間の短縮化を、単一のシミュレーションモデルで実現することができる。

また、ＥＳＬ技術の（Ｃ）のフェーズでは、低抽象度であるＲＴＬモデルの実装を待つこととなり、新規にモデル開発をおこなう必要がある。このため、モデル開発が二重となり開発工数および設計負担が増大するが、本実施の形態の可変抽象ラッパ１０４を適用することで、開発工数および設計負担の低減化を図ることができる。

以上のことから、本実施の形態にかかる可変抽象ラッパ１０４は、トラフィック生成器２０２による擬似トラフィックＴの生成、内部メモリ２０３による被測定モデル１０１の挙動の隠蔽をはかることができる。したがって、シミュレーション段階での抽象度変更に柔軟に対応して設計期間の短縮化を図ることができる。

なお、本実施の形態で説明した設計支援方法は、あらかじめ用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。このプログラムや可変抽象ラッパ１０４は、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。またこのプログラムや可変抽象ラッパ１０４は、インターネット等のネットワークを介して配布してもよい。

上述した実施の形態に関し、さらに以下の付記を開示する。

（付記１）測定対象に測定ポイントからのリクエストを与えて当該リクエストに応じたシミュレーションを実行するコンピュータを、
前記リクエストを解析する解析手段、
前記解析手段による前記リクエストの解析内容および開発工程に関する抽象度から選ばれた任意の抽象度に応じて、前記シミュレーションにおける各処理の演算結果に関する擬似トラフィックを生成する生成手段、
前記各処理の所要時間を当該所要時間よりも短い所要時間に設定する設定手段、
前記リクエストにより前記シミュレーションが開始された場合、前記各処理の演算結果を前記測定対象に読み書きさせる記憶手段、
前記生成手段によって生成された擬似トラフィックおよび前記リクエストに対する前記測定対象からのレスポンスを入力して、前記設定手段によって設定された前記短い所要時間の積算時間経過後でかつ前記擬似トラフィックの出力終了後に前記レスポンスを出力する制御手段、
として機能させることを特徴とする設計支援プログラム。

（付記２）前記生成手段は、
前記選ばれた任意の抽象度が特定の抽象度よりも低い抽象度である場合、リクエスト種別に応じたトラフィックに関する出力波形を記憶するデータベースの中から、前記リクエストに該当する前記測定対象からのトラフィックに関する出力波形を抽出することにより、当該出力波形に応じた擬似トラフィックを生成することを特徴とする付記１に記載の設計支援プログラム。

（付記３）前記生成手段は、
前記選ばれた任意の抽象度が特定の抽象度よりも高い抽象度である場合、前記擬似トラフィックを生成せず、
前記制御手段は、
前記設定手段によって設定された前記短い所要時間の積算時間経過後に前記レスポンスを出力することを特徴とする付記１に記載の設計支援プログラム。

（付記４）前記生成手段は、
前記選ばれた任意の抽象度が特定の抽象度である場合、リクエスト種別に応じたトラフィックに関する出力波形を記憶するデータベースの中から、前記リクエストに該当する前記測定対象からの平均化された出力波形を抽出することにより、当該平均化された出力波形に応じた擬似トラフィックを生成することを特徴とする付記１に記載の設計支援プログラム。

（付記５）前記制御手段は、
前記リクエストを入力して前記測定対象および前記解析手段に出力することを特徴とする付記１〜４のいずれか一つに記載の設計支援プログラム。

（付記６）前記データベースは、
前記トラフィックに関する測定済みの出力波形を記憶することを特徴とする付記１〜５のいずれか一つに記載の設計支援プログラム。

（付記７）前記測定対象に替えて、当該測定対象に類似する測定対象に前記リクエストを与えて当該リクエストに応じたシミュレーションを実行することを特徴とする付記１〜６のいずれか一つに記載の設計支援プログラム。

（付記８）前記データベースは、
前記設計対象の仕様書から得られる期待値となるトラフィックに関する出力波形を記憶することを特徴とする付記１〜５のいずれか一つに記載の設計支援プログラム。

（付記９）測定対象に測定ポイントからのリクエストを与えて当該リクエストに応じたシミュレーションを実行する設計支援装置であって、
前記リクエストを解析する解析手段と、
前記解析手段による前記リクエストの解析内容および開発工程に関する抽象度から選ばれた任意の抽象度に応じて、前記シミュレーションにおける各処理の演算結果に関する擬似トラフィックを生成する生成手段と、
前記各処理の所要時間を当該所要時間よりも短い所要時間に設定する設定手段と、
前記リクエストにより前記シミュレーションが開始された場合、前記各処理の演算結果を前記測定対象に読み書きさせる記憶手段と、
前記生成手段によって生成された擬似トラフィックおよび前記リクエストに対する前記測定対象からのレスポンスを入力して、前記設定手段によって設定された前記短い所要時間の積算時間経過後でかつ前記擬似トラフィックの出力終了後に前記レスポンスを出力する制御手段と、
を備えることを特徴とする設計支援装置。

（付記１０）測定対象に測定ポイントからのリクエストを与えて当該リクエストに応じたシミュレーションをコンピュータに実行させるシミュレーションモデルであって、
前記リクエストを解析する解析手段と、
前記解析手段による前記リクエストの解析内容および開発工程に関する抽象度から選ばれた任意の抽象度に応じて、前記シミュレーションにおける各処理の演算結果に関する擬似トラフィックを生成する生成手段と、
前記各処理の所要時間を当該所要時間よりも短い所要時間に設定する設定手段と、
前記リクエストにより前記シミュレーションが開始された場合、前記各処理の演算結果を前記測定対象に読み書きさせる記憶手段と、
前記生成手段によって生成された擬似トラフィックおよび前記リクエストに対する前記測定対象からのレスポンスを入力して、前記設定手段によって設定された前記短い所要時間の積算時間経過後でかつ前記擬似トラフィックの出力終了後に前記レスポンスを出力する制御手段と、
を備えることを特徴とするシミュレーションモデル。

本実施の形態の概要を示す説明図である。 可変抽象ラッパの機能的構成を示すブロック図である。 トラフィックデータベースの記憶内容を示す説明図である。 波形データの一例を示す説明図である。 トラフィック生成器の内部構成を示すブロック図である。 擬似トラフィックに着目したシーケンス図である。 内部メモリの動作に着目したシーケンス図である。 実施の形態にかかる設計支援装置のハードウェア構成を示すブロック図である。 本実施の形態にかかる設計支援装置の機能的構成を示すブロック図である。 本実施の形態にかかる設計支援装置による設計支援処理手順を示すフローチャートである。 図１０のステップＳ１００３のシミュレーション時の可変抽象ラッパの動作を示すシーケンス図である。 トラフィック制御器の制御動作を示すフローチャートである。 実ハードウェアを適用した場合のシミュレーション例を示す説明図である。 内部バッファを増加させた場合のハードウェア部品の性能変化を示すグラフである。 内部バッファを増加させることによるシステムの性能変化を示すグラフである。 ＥＳＬ技術の開発工程を示す説明図である。

符号の説明

１０１ 被測定モデル
１０２ 測定ポイント
１０４ 可変抽象ラッパ
２０１ トラフィック制御器
２０２ トラフィック生成器
２０３ 内部メモリ
２２１ パーサ
２２３ シーケンサ
２２４ Ｉ／Ｏジェネレータ
２２５ 合成器
９００ 設計支援装置
９０１ 指定部
９０２ 解析部
９０３ 生成部
９０４ 設定部
９０５ 記憶部
９０６ 制御部

Claims (5)

1. 測定対象に測定ポイントからのリクエストを与えて当該リクエストに応じたシミュレーションを実行するコンピュータを、
   前記リクエストを解析する解析手段、
   前記解析手段による前記リクエストの解析内容および開発工程に関する抽象度から選ばれた任意の抽象度に応じて、前記シミュレーションにおける各処理の演算結果に関する擬似トラフィックを生成し、前記選ばれた任意の抽象度が特定の抽象度である場合、リクエスト種別に応じたトラフィックに関する出力波形を記憶するデータベースの中から、前記リクエストに該当する前記測定対象からの平均化された出力波形を抽出することにより、当該平均化された出力波形に応じた擬似トラフィックを生成する生成手段、
   前記各処理の所要時間を当該所要時間よりも短い所要時間に設定する設定手段、
   前記リクエストにより前記シミュレーションが開始された場合、前記各処理の演算結果を前記測定対象に読み書きさせる記憶手段、
   前記生成手段によって生成された擬似トラフィックおよび前記リクエストに対する前記測定対象からのレスポンスを入力して、前記設定手段によって設定された前記短い所要時間の積算時間経過後でかつ前記擬似トラフィックの出力終了後に前記レスポンスを出力する制御手段、
   として機能させることを特徴とする設計支援プログラム。
2. 前記生成手段は、
   前記選ばれた任意の抽象度が特定の抽象度よりも低い抽象度である場合、リクエスト種別に応じたトラフィックに関する出力波形を記憶するデータベースの中から、前記リクエストに該当する前記測定対象からのトラフィックに関する出力波形を抽出することにより、当該出力波形に応じた擬似トラフィックを生成することを特徴とする請求項１に記載の設計支援プログラム。
3. 前記生成手段は、
   前記選ばれた任意の抽象度が特定の抽象度よりも高い抽象度である場合、前記擬似トラフィックを生成せず、
   前記制御手段は、
   前記設定手段によって設定された前記短い所要時間の積算時間経過後に前記レスポンスを出力することを特徴とする請求項１に記載の設計支援プログラム。
4. 測定対象に測定ポイントからのリクエストを与えて当該リクエストに応じたシミュレーションを実行する設計支援装置であって、
   前記リクエストを解析する解析手段と、
   前記解析手段による前記リクエストの解析内容および開発工程に関する抽象度から選ばれた任意の抽象度に応じて、前記シミュレーションにおける各処理の演算結果に関する擬似トラフィックを生成し、前記選ばれた任意の抽象度が特定の抽象度である場合、リクエスト種別に応じたトラフィックに関する出力波形を記憶するデータベースの中から、前記リクエストに該当する前記測定対象からの平均化された出力波形を抽出することにより、当該平均化された出力波形に応じた擬似トラフィックを生成する生成手段と、
   前記各処理の所要時間を当該所要時間よりも短い所要時間に設定する設定手段と、
   前記リクエストにより前記シミュレーションが開始された場合、前記各処理の演算結果を前記測定対象に読み書きさせる記憶手段と、
   前記生成手段によって生成された擬似トラフィックおよび前記リクエストに対する前記測定対象からのレスポンスを入力して、前記設定手段によって設定された前記短い所要時間の積算時間経過後でかつ前記擬似トラフィックの出力終了後に前記レスポンスを出力する制御手段と、
   を備えることを特徴とする設計支援装置。
5. 測定対象に測定ポイントからのリクエストを与えて当該リクエストに応じたシミュレーションをコンピュータに実行させるシミュレーションモデルであって、
   前記リクエストを解析する解析手段と、
   前記解析手段による前記リクエストの解析内容および開発工程に関する抽象度から選ばれた任意の抽象度に応じて、前記シミュレーションにおける各処理の演算結果に関する擬似トラフィックを生成し、前記選ばれた任意の抽象度が特定の抽象度である場合、リクエスト種別に応じたトラフィックに関する出力波形を記憶するデータベースの中から、前記リクエストに該当する前記測定対象からの平均化された出力波形を抽出することにより、当該平均化された出力波形に応じた擬似トラフィックを生成する生成手段と、
   前記各処理の所要時間を当該所要時間よりも短い所要時間に設定する設定手段と、
   前記リクエストにより前記シミュレーションが開始された場合、前記各処理の演算結果を前記測定対象に読み書きさせる記憶手段と、
   前記生成手段によって生成された擬似トラフィックおよび前記リクエストに対する前記測定対象からのレスポンスを入力して、前記設定手段によって設定された前記短い所要時間の積算時間経過後でかつ前記擬似トラフィックの出力終了後に前記レスポンスを出力する制御手段と、
   を備えることを特徴とするシミュレーションモデル。

Images