(57)【要約】【課題】  システムＬＳＩのような半導体装置において、設計検証の工数を削減することができる技術を提供する。【解決手段】  パラメータファイル１０９とイベントファイル１１０から、イニシエータ１０４のトランザクション発行を制御し、また、ターゲットの不要なコントローラ１０７を備えることにより、すべての機能モデルを作成する必要がなくなり、テストパターンが不要となり、様々なシミュレーションシナリオを容易に作成できる半導体装置の設計検証装置である。【選択図】  図１
2006085319.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータにプログラムをロードし、ファイル及びモデルライブラリを入力することにより構築される半導体装置の設計検証装置であって、
前記ファイルの記述に基づいてトランザクションを発行するイニシエータと、
前記トランザクションを受信するコントローラと、
前記イニシエータと前記コントローラとが接続されるバスと、
シミュレーション実行中にリアルタイムに制約違反を監視する判定部と、
前記シミュレーションのプロファイリング情報を集計する機能とを有することを特徴とする半導体装置の設計検証装置。
【請求項２】
請求項１記載の半導体装置の設計検証装置において、
前記コントローラは、ターゲットの機能を包括していることを特徴とする半導体装置の設計検証装置。
【請求項３】
請求項１記載の半導体装置の設計検証装置において、
前記イニシエータが発行する前記トランザクションは、１つのトランザクション内に複数のリクエストを含み、
前記ファイルは、前記リクエスト間の発行タイミングの情報を含むことを特徴とする半導体装置の設計検証装置。
【請求項４】
請求項３記載の半導体装置の設計検証装置において、
前記イニシエータは、前記ファイルの記述に従って、前記リクエストを無作為に生成する機能を有することを特徴とする半導体装置の設計検証装置。
【請求項５】
請求項１記載の半導体装置の設計検証装置において、
前記コントローラがメモリコントローラの場合には、ターゲットメモリのバンク又はロウアドレスのヒット／ミスの判定を行う機能を有することを特徴とする半導体装置の設計検証装置。
【請求項６】
請求項１記載の半導体装置の設計検証装置において、
前記プロファイリング情報の集計結果から制約違反情報を抽出し、前記イニシエータのアービトレーション優先順位を変動させて前記半導体装置のシステム全体の最適パフォーマンスを検出する機能を有することを特徴とする半導体装置の設計検証装置。
【請求項７】
請求項１記載の半導体装置の設計検証装置において、
消費電力解析ライブラリを入力し、前記半導体装置の消費電力解析を行う機能を有することを特徴とする半導体装置の設計検証装置。
【請求項８】
請求項１記載の半導体装置の設計検証装置において、
前記イニシエータと前記バスとの間に接続され、前記イニシエータからのピンレベルの信号をトランザクションレベルのリクエストに変換するアダプタを有することを特徴とする半導体装置の設計検証装置。
【請求項９】
請求項１記載の半導体装置の設計検証装置において、
前記バスに接続され、他の設計検証装置の他のバスと接続するためのアダプタを有することを特徴とする半導体装置の設計検証装置。
【請求項１０】
請求項１記載の半導体装置の設計検証装置において、
前記プロファイリング情報を集計する機能は、前記バス及び／又は前記イニシエータのそれぞれに分散して組み込まれていることを特徴とする半導体装置の設計検証装置。
【請求項１１】
請求項１〜１０のいずれか１項に記載の半導体装置の設計検証装置を使用して、客先でシミュレーションを実行し、前記シミュレーションの実行により出力されるプロファイリング情報の結果の検討を実施し、その結果に基づいて半導体装置のシステム仕様を決定することを特徴とする半導体装置の設計方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、半導体装置の設計検証装置及び設計方法に関し、特にシステムＬＳＩの機能レベルシミュレーションに適用して有効な技術に関するものである。
【背景技術】
【０００２】
本発明者が検討した技術として、例えば、システムＬＳＩのような大規模集積回路の設計検証においては、Ｃ言語をベースにしたハードウェア記述言語で機能モデルを作成し、機能レベルのシミュレーションを行う技術が考えられる（例えば、非特許文献１及び２参照）。
【特許文献１】特開２００３−１５９６８号公報
【非特許文献１】ティ・グロッカ（Ｔ．Ｇｒｏｔｋｅｒ）他，「ＳｙｓｔｅｍＣによるシステム設計」，丸善株式会社，２００３年１月
【非特許文献２】大村正之，深山正幸，「Ｃ／Ｃ＋＋によるＶＬＳＩ設計（ＳｙｓｔｅｍＣによるＪＰＥＧコーデック設計）」，共立出版，２００３年１１月
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ところで、前記のような機能レベルシミュレーションの技術について、本発明者が検討した結果、以下のようなことが明らかとなった。
【０００４】
図２３に、本発明者が本発明の前提として検討した半導体装置の設計検証装置の一例を示す。
【０００５】
図２３の設計検証装置２３０１において、入力となるのは、テストパターン２３０２や制約２３０３と呼ばれるデータ群と、イニシエータやターゲット、バス、ルータ、アービタ、コントローラなどの機能モデルライブラリ２３０４である。これらの入力を元にして、シミュレーションモデル構築部２３０５が、イニシエータ２３０７、バス２３０８、ルータ・アービタ２３０９、コントローラ２３１０、ターゲット２３１１などの各種機能モデルを接続してシミュレーション実行部２３０６を構築する。
【０００６】
そして、シミュレーション実行部２３０６において、各機能モデルが、ピンレベルで通信を行いながら処理を行い、シミュレーションを実行し、シミュレーション結果２３１２が出力される。シミュレーション実行後に、制約違反判定部２３１３がシミュレーション結果２３１２を読込み、システム性能が確保できたか否かのチェックを行い、プロファイリング結果のレポート２３１４が出力される。
【０００７】
ここで、イニシエータとはバスを介して通信要求を発行する部品であり、ターゲットとはイニシエータが通信要求を発行する相手先の部品（メモリ、キャッシュなど）である。イニシエータ・ターゲット共、すべての機能モデルを用意する必要がある。
【０００８】
従来のシステムＬＳＩ設計検証装置は以上のように構成されていたので、すべての機能を持つモデルや、テストパターンを作り込むための工数がかかり過ぎるという問題がある。また、このようにして作成した構成で性能が出なかったとしても、モデルへのシミュレーション結果のフィードバックが困難であり、モデルの作り直しのために、多大な工数を要してしまう。
【０００９】
特許文献１には、バスの構成をフレキシブルに変更可能なトランザクションレベルで動作するバスシミュレータが開示されている。このシミュレータは、バスアーキテクチャの検討を容易とすることを特徴としており、イニシエータ及びターゲットの実装方法については、記載されていない。
【００１０】
そこで、本発明の目的は、システムＬＳＩのような半導体装置において、設計検証の工数を削減することができる技術を提供することにある。
【００１１】
本発明の前記並びにその他の目的と新規な特徴は、本明細書の記述及び添付図面から明らかになるであろう。
【課題を解決するための手段】
【００１２】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、次のとおりである。
【００１３】
すなわち、本発明による半導体装置の設計検証装置は、パラメータファイルとイベントファイルの記述に基づいてトランザクションを発行するイニシエータと、イニシエータが発行したトランザクションを受信するコントローラと、イニシエータとコントローラが接続されるバスと、シミュレーション実行中にリアルタイムに制約違反を監視する判定部と、シミュレーションのプロファイリング情報を集計する機能とを備えることにより、すべての機能モデルを作成する必要がなくなり、テストパターンが不要となり、様々なシミュレーションシナリオを容易に作成できるものである。
【００１４】
また、消費電力解析ライブラリを入力し、シミュレーション中に消費電力解析を実施することにより、半導体装置の低消費電力化を実現するためのボトルネック解析に活用できるものである。
【００１５】
また、ＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）、ＩＳＳ（Ｉｎｓｔｒｕｃｔｉｏｎ  Ｓｅｔ  Ｓｉｍｕｌａｔｏｒ）などの機能モデルを、アダプタを介してイニシエータとして動作させることにより、既存の設計資産の流用が容易となり、新規にモデル開発を行う工数を削減できるものである。
【００１６】
また、本発明による半導体装置の設計方法は、前記半導体装置の設計検証装置を使用して、客先でシミュレーションを実行し、そのシミュレーションの実行により出力されるプロファイリング情報の結果の検討を実施することにより、最適なシステム構成や仕様の決定を、顧客を交えて容易に行うことができるものである。
【発明の効果】
【００１７】
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば、以下のとおりである。
【００１８】
（１）イニシエータをトランザクション発行機能に特化させることにより、すべての機能をモデル化する必要がないため、モデル開発工数を削減できる。
【００１９】
（２）パラメータファイル及びイベントファイルの設定によって、トランザクションを自動発行できるため、テストパターンが不要となり、様々なシミュレーションシナリオを容易に作成できる。
【発明を実施するための最良の形態】
【００２０】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部材には原則として同一の符号を付し、その繰り返しの説明は省略する。
【００２１】
（実施の形態１）
図１は本発明の実施の形態１による半導体装置の設計検証装置の構成を示すブロック図、図２は本実施の形態１による半導体装置の設計検証装置において、イニシエータが発行するトランザクションの一例を示す図、図３はトランザクションを構成するリクエストのデータ構造の一例を示す図、図４はパラメータファイルの記述例を示す図、図５はパラメータファイル内のイニシエータパラメータの一例を示す図、図６はイベントファイルのフォーマット及び記述例を示す図、図７は各イニシエータのリクエストキューの一例を示す図、図８は設計検証装置の処理フローを示すフローチャート、図９はシミュレーション実行により得られるプロファイリング情報の一例を示す図、図１０は制約違反判定の一例を示す図、図１１は波形出力情報を示す図、図１２はアービトレーション優先順位の最適解決定方法の一例を示す図である。
【００２２】
まず、図１により、本実施の形態１による半導体装置の設計検証装置の構成の一例を説明する。本実施の形態１の設計検証装置１０１は、例えばコンピュータにロードされ実行されるプログラム（ソフトウェア）とされ、シミュレーションモデル構築部１０２、シミュレーション実行部１０３などから構成されている。また、シミュレーション実行部１０３は、イニシエータ１０４、バス１０５、ルータ・アービタ１０６、コントローラ１０７、制約違反判定部１０８などからなり、イニシエータ１０４及びルータ・アービタ１０６はバス１０５に接続され、ルータ・アービタ１０６はコントローラ１０７に接続されている。
【００２３】
この設計検証装置１０１において入力となるのは、パラメータファイル１０９やイベントファイル１１０と呼ばれるデータ群と、イニシエータなどの汎用モデルライブラリ１１１、バス・ルータ・アービタ・コントローラなどの製品依存の機能モデルライブラリ１１２、消費電力解析ライブラリ１１３である。この設計検証装置１０１では、メモリなどのターゲットモデルが不要で、コントローラ１０７がターゲットの機能を包括している。コントローラ１０７は、具体的には、例えばメモリコントローラ、キャッシュコントローラなどである。
【００２４】
シミュレーションモデル構築部１０２は、これらの入力を元にしてシミュレーション実行部１０３の構造を構築する。パラメータファイル１０９の記述により、イニシエータ１０４、コントローラ１０７の個数を変えることができる。シミュレーション実行部１０３は、トランザクションレベルで通信を行ってシミュレーションを実行する。シミュレーション実行中は制約違反判定部１０８により、各々の処理が破綻することなくシステム性能を確保できているか否かのリアルタイムチェックを行う。そして、シミュレーション終了後にプロファイリング情報の集計結果のレポート１１４が出力される。
【００２５】
図２に、イニシエータ１０４が発行するトランザクションの一例を示す。制約期間内に１つのトランザクションを発行するものとし、指定されたオフセットとインターバルを考慮して、リクエストを発生させる。最終リクエストを発生し終えたら、制約期間が終了するまで、リクエストの発行を停止して、1つのトランザクションが完結する。その後、続けて次のトランザクションを発行する。
【００２６】
リクエストとリクエストの間の、インターバルの決め方は、イニシエータごとにイベントタイプとしてカスタマイズ可能である。例えば、以下のようなイベントタイプがある。
【００２７】
（１）リクエストを発行した後、アービトレーションを待たずに、設定したインターバルの経過後に、次のリクエストを発行する。
【００２８】
（２）リクエストを発行してアービトレーションによりリクエストが受理された後、設定したインターバルの経過後に、次のリクエストを発行する。
【００２９】
（３）リクエストを発行してアービトレーションによりリクエストが受理された後、さらにはメモリアクセス完了後（レスポンス発行後）、設定したインターバルの経過後に、次のリクエストを発行する。
【００３０】
図３に、トランザクションを構成する各リクエストのデータ構造の一例を示す。各リクエストには、リクエスト本来の情報（発行元イニシエータ識別ＩＤ、リクエストＩＤ、アドレス、データサイズ、リクエスト種別、リクエストの状態）に加えて、プロファイル情報を集計するために、各タイミング情報 （リクエスト発行サイクル、リクエストキューの先頭に来たサイクル、アービタに選択されたサイクル、メモリアクセス開始サイクル、メモリアクセス終了サイクル）が保持されていることが特徴的である。
【００３１】
ルータは、リクエスト内に含まれるアドレス情報から行き先となるコントローラ（ターゲット）を判定して、リクエストを振り分けるルーティング機能を有する。
【００３２】
システム構成の決定方法や各イニシエータのトランザクション発行方法は、パラメータファイル１０９で定義する。パラメータファイル１０９の記述例を図４に示す。パラメータファイル１０９は複数のカテゴリから構成されており、基本パラメータ（％ＢＡＳＩＣ）、イニシエータパラメータ（％ＩＮＩＴＩＡＴＯＲ）、ランダム制御パラメータ（％ＲＡＮＤＯＭ）、アービトレーション設定パラメータ（％ＡＲＢＩＴＥＲ）、コントローラパラメータ（％ＣＯＮＴＲＯＬＬＥＲ）の５種類がある。
【００３３】
基本パラメータカテゴリでは、シミュレーション終了サイクル（ＳＩＭ−ＣＹＣＬＥ）、動作クロック周期（ＢＡＳＥ−ＰＥＲＩＯＤ）など、システム全体に関するパラメータを設定する。
【００３４】
イニシエータパラメータカテゴリでは、各イニシエータ１０４ごとの、トランザクション発行方法に関するパラメータを設定する。図５に、イニシエータパラメータの一例を示す。イニシエータパラメータに含まれているアドレスタイプは、イニシエータ１０４が発行するリクエストに含まれるアドレス情報において、指定された初期アドレスから、各イニシエータ特有の規則性（シーケンシャルやランダム）に基づいて、アドレスを生成するために利用する。この規則性は、入力数式や処理ルーチンをあらかじめパターン化しておき、アドレス生成パターンのタイプを選択して指定する。
【００３５】
ランダム制御パラメータカテゴリでは、各イニシエータ１０４でのトランザクション発行時のランダム制御に関するパラメータを設定する。ランダム制御対象となるのは、トランザクションを構成するリクエストにおける、データサイズ（Ｓｉｚｅ）とデータタイプ（Ｃｏｍ）である。確率（Ｒａｔｉｏ）を指定することで、複数種類のリクエストをランダムに生成できる。
【００３６】
アービトレーション設定パラメータカテゴリでは、各イニシエータ１０４から発行されるリクエスト選択時の優先順位決定に関するパラメータを設定する。固定優先順位、ラウンドロビン、固定優先順位と優先順位内ラウンドロビンの組み合わせなどのアービトレーション方式を容易にカスタマイズできる。
【００３７】
コントローラパラメータカテゴリでは、コントーラ１０７ごとにパラメータを設定する。アドレス範囲（ＡＤＲ−ＭＡＰ）、リクエストキューのサイズ（ＱＵＥ−ＳＩＺＥ）、アドレスのロウサイズ（ＲＯＷ−ＳＩＺＥ）、カラムサイズ（ＣＯＬＵＭＮ−ＳＩＺＥ）、ペナルティサイクル（ＰＥＮＡＬＴＹ−ＣＹＣＬＥ）など、メモリアクセスに関するパラメータを設定する。
【００３８】
あらゆるバスとのインタフェースを考慮して、イニシエータ１０４とバス１０５の幅が異なる場合や、レイテンシが異なる場合でも、イニシエータパラメータ、コントローラパラメータなどのカスタマイズだけで、実際のハードウェアに近い精度での解析が可能となる。
【００３９】
リクエスト発行タイミングに規則性のないイニシエータの場合、図６に示すようなイベントファイル１１０を用意し、そこからリクエスト発行サイクルとリクエストデータを抽出して、図２に示したオフセット、インターバル、ウェイトの代用とすることが可能である。
【００４０】
各イニシエータは、リクエストを格納するためのリクエストキュー（ＦＩＦＯ；Ｆｉｒｓｔ−Ｉｎ  Ｆｉｒｓｔ−Ｏｕｔ）を保持し、パラメータファイル１０９内のイニシエータパラメータ、あるいはイベントファイル１１０に従って発行したリクエストを、このリクエストキューに格納していく。リクエストキューのサイズは、イニシエータパラメータでイニシエータごとに変えることができる（図４のＱＵＥ−ＳＩＺＥ）。
【００４１】
図７に、各イニシエータのリクエスト発行状況の一例を示す。イニシエータ１０４ａ〜ｃは、それぞれ、５段、４段、３段のリクエストキュー７０１ａ〜ｃを持っている。図７の例では、イニシエータ１０４ａには３つのリクエストが登録済、イニシエータ１０４ｂには１つのリクエストが登録済、イニシエータ１０４ｃには２つのリクエストが登録済である状態を示している。また、リクエストがリクエストキュー７０１をオーバーフローした場合は、その旨の警告をアサートする機能も有する。
【００４２】
アービタは、各イニシエータの所有するリクエストキュー７０１に、リクエストが格納されているかどうかをチェックし、リクエストが格納されているイニシエータをアービトレーション対象とする。例えば、図７において、アービトレーション方式がラウンドロビンであって、イニシエータ１０４ａ−イニシエータ１０４ｃ−イニシエータ１０４ｂの順に選択されるとした場合、最初のアービトレーションタイミングではＲｅｑ１−１が選択され、次のタイミングではＲｅｑ３−１、次はＲｅｑ２−１、さらに次はＲｅｑ１−２という順番でリクエストが選択されていく。アービタにより選択されたリクエストは、リクエストキュー７０１から削除されて、コントローラ１０７内のメモリバッファに格納される。
【００４３】
図８の処理フローチャートに、このように構築されたシステムＬＳＩ設計検証装置の基本動作を示す。
【００４４】
まず、ステップＳ８０１において、シミュレーションモデル構築部１０２で、データ群（パラメータファイル１０９、イベントファイル１１０）及びライブラリ（汎用モデルライブラリ１１１、機能モデルライブラリ１１２、消費電力解析ライブラリ１１３）からシミュレーションモデルを構築し、シミュレーション実行部１０３を作成する。
【００４５】
ステップＳ８０２で、パラメータファイル１０９及びイベントファイル１１０に従い、各イニシエータ１０４はトランザクションを発行し、リクエストキュー７０１に格納する。
【００４６】
ステップＳ８０３で、コントローラ１０７が所有するメモリバッファに空きがあるか否かを確認する。メモリバッファに空きがある場合はステップＳ８０４へ進み、空きがない場合はステップＳ８０６へ進む。
【００４７】
ステップＳ８０４で、アービタ（ルータ・アービタ１０６）のアービトレーション方式に基づき、最優先リクエストを選択する。
【００４８】
ステップＳ８０５で、イニシエータ１０４内のリクエストキュー７０１からコントローラ１０７のメモリバッファへ選択されたリクエストを転送する。
【００４９】
ステップＳ８０６で、コントローラ１０７が所有するメモリバッファにリクエストが格納されているか否かを確認する。リクエストが格納されている場合はステップＳ８０７へ進み、格納されていない場合はステップＳ８０２へ戻る。
【００５０】
ステップＳ８０７で、コントローラ１０７のメモリバッファの先頭からリクエストを取り出し、アドレス情報からキャッシュのヒット／ミスを判定する。
【００５１】
ステップＳ８０８で、モデル化方式に基づき、メモリアクセスサイクルを算出し、該当リクエストを発行したイニシエータへレスポンスを返す。
【００５２】
ステップＳ８０９で、各種プロファイリング情報の計算を行い、制約違反判定部１０８で判定した指定制約に対する違反と共に、シミュレーション実行部１０３内のデータベースにこれらの情報を格納する。そして、ステップＳ８０２へ戻り同じ動作を繰り返す。  
【００５３】
図９に、本実施の形態１により得られるプロファイリング情報を示す。各イニシエータごとのプロファリング情報は、処理対象の各リクエストがデータ構造として付加的に内包している各イベントタイミングデータ（図３参照）から、バスモデルがプロファイリング情報を集計して、内部データ構造として情報を蓄積し、制約違反などの情報を一元管理する。コントローラ１０７のプロファイリング情報は、メモリコントローラを忠実にモデル化することで、バンクやロウ（ＲＯＷ）アドレスキャッシュのヒット／ミスの情報を、サイクル精度を維持するために消費サイクルに反映させるとともに、メモリコントローラモデルがプロファイリング情報として集計し、内部データ構造に情報を蓄積する。
【００５４】
図１０に、制約違反判定部１０８における制約違反判定の一例を示す。この図１０の例では、トランザクションが３つのリクエストから構成されている場合で、上側が違反なし、下側が違反ありのケースである。下側のように、最後のＲｅｑ３のメモリアクセス終了時間が、トランザクションの制約期間からはみ出してしまう場合に、制約違反となる。
【００５５】
アービトレーションとコントローラ動作の解析を容易にするため、ＶＣＤ（Ｖａｌｕｅ  Ｃｈａｎｇｅｄ  Ｄｕｍｐ）形式でリアルタイムに各種情報の波形出力が可能である。図１１に、波形に出力できる情報を示す。なお、図１１において、波形名称の”＊”部分はイニシエータＩＤであり、先頭から５つの項目はイニシエータごとに出力される。
【００５６】
シミュレーションの終了条件は、パラメータファイル１０９内のパラメータの１つとして指定するサイクル数で与え（図４のＳＩＭ−ＣＹＣＬＥ）、本実施の形態１による設計検証装置は、このサイクル数に達するまで実行し続ける。
【００５７】
本実施の形態１による設計検証装置では、消費電力解析ライブラリ１１３を入力として、システムＬＳＩの消費電力を求める。消費電力計算方法の一例を以下に示す。
【００５８】
消費電力は、消費電力解析ライブラリ１１３から消費電力パラメータを読込んで、以下の計算により求める。
【００５９】
（１）各イニシエータの消費電力Ｐtr（ｉ）
Ｐtr（ｉ）＝リクエスト発行時の消費電力合計＋レスポンス受信時の消費電力合計
（２）各コントローラ(ターゲット)の消費電力Ｐcntl（ｊ）
Ｐcntl（ｊ）＝外部メモリアクセスごとの消費電力合計
（３）各バス、ルータ、アービタの消費電力Ｐmisc（ｋ）
Ｐmisc（ｋ）＝動作回数に応じた消費電力
（４）トータルの消費電力Ｐ
Ｐ＝ΣＰtr（ｉ）＋ΣＰcntl（ｊ）＋ΣＰmisc（ｋ）
なお、ｉはイニシエータの個数、ｊはコントローラの個数、ｋはバス等の個数である。
【００６０】
本実施の形態１による設計検証装置は、シミュレーション実行後のプロファイリング情報の制約違反をチェックし、最も制約違反の大きかったイニシエータのアービトレーション優先順位をランクアップする機能を有する。シミュレーションの再実行を繰り返して行うことで、全体としての制約違反が最も小さくなるような、各イニシエータの最適な優先順位を決定することが可能である。
【００６１】
図１２は、イニシエータの数が３個で、それぞれに固定順位を割り当てる場合の、最適な優先順位を決定する例である。１回目のシミュレーション実行の結果、制約違反が最も大きいのは優先順位３のイニシエータＣである。そこで、２回目はＣの優先順位を１つ上げて再実行する。その結果、Ｃの制約違反は１０から５、全体の制約違反合計は、１０から８となり、優先順位変更によるシステム全体の効率が向上する。さらに、３回目はＣの優先順位をさらに１つ上げて再実行する。その結果、Ｃの制約違反は５から０となるが、全体の制約違反合計が８から１３となり、逆にシステム全体の効率が低下する。そこで、最適解としては、２回目の実行で用いた優先順位（Ａが１、Ｃが２、Ｂが３）とする。
【００６２】
（実施の形態２）
図１３は本発明の実施の形態２による半導体装置の設計検証装置の構成を示すブロック図、図１４は本実施の形態２による半導体装置の設計検証装置において、アダプタによるピンレベルの信号からトランザクションレベルのリクエストへの変換の一例を示す図、図１５はアダプタの実装方法と接続の一例を示す図、図１６はＦＰＧＡ利用によるソフトウェア実行高速化の一例を示す図、図１７はＦＰＧＡ利用によるハードウェア実行高速化の一例を示す図、図１８は本発明による設計検証装置を２組接続したシステム構成を示すブロック図、図１９は本発明と従来の設計検証装置を接続したシステム構成を示すブロック図である。
【００６３】
本実施の形態２による半導体装置の設計検証装置は、アダプタという部品を介することで、様々なイニシエータや他のバスを、接続可能とする応用例である。利用可能なイニシエータとしては、例えば、ＩＳＳ、Ｃ言語をベースとしたハードウェア記述、ＨＤＬ（Ｈａｒｄｗａｒｅ Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ）、ＦＰＧＡなどがある。
【００６４】
図１３に、ピンレベルのフル機能モデルであるイニシエータ１０４ｄ，１０４ｅを、アダプタ１３０１ａ，１３０１ｂを介してバス１０５に接続する場合のブロック図を示す。アダプタ１３０１の機能により、イニシエータ１０４ｄ，１０４ｅは、ピンレベルの信号をトランザクションレベルのリクエストに変換してトランザクションの発行が可能となる。入力される汎用モデルライブラリ１１１ａには、イニシエータの外、アダプタ１３０１のモデルが含まれている。
【００６５】
アダプタ１３０１は、イニシエータ１０４が生成するピンレベルの各信号を入力として、パターンマッチングを行い、あるパターンと一致する信号の組み合わせが得られるごとに、特定のリクエスト（トランザクション）を生成する。
【００６６】
図１４に、アダプタ１３０１によって、ピンレベルの信号をリクエスト（トランザクション）に変換する一例を示す。この例では、ＲｅｑｕｅｓｔとＡｃｋの信号がハイ（Ｈｉｇｈ）レベルになったタイミングで、ＣｏｍＴｙｐｅとＡｄｄｒｅｓｓなどのデータ値を読み取って、アダプタ１３０１がリクエストを生成している。
【００６７】
図１５に、アダプタ１３０１を実現する具体例を示す。図１５において、ＦＰＧＡ１５０１を搭載したプロトタイピングＦＰＧＡボード１５０２が、イニシエータ１０４に該当する。アダプタ１３０１には、デバイスドライバ１５０３とアプリケーションＩ／Ｆ１５０４が含まれている。本実施の形態２による設計検証装置の実行プログラムは、デスクトップパーソナルコンピュータ（ＰＣ）などのプログラム実行環境装置１５０５のメモリ内にロードされている。ＦＰＧＡボード１５０２からの信号出力は、アダプタ１３０１を介してリクエストに変換されて、プログラム実行環境装置１５０５へ入力される。なお、アダプタ１３０１は、プログラム実行環境装置１５０５の内部に設けてもよい。
【００６８】
次に図１６及び図１７により、アダプタ１３０１を介するイニシエータ１０４として、ＦＰＧＡを利用するケースについて説明する。図１６では、ソフトウェアの実行速度の高速化を見込んで、ＦＰＧＡ１６０１にマッピングしたプロセッサ（ＣＰＵ）を、アダプタ１３０１ｃを介してシミュレーション実行部１０３ｂ内のバス１０５に接続し、一方、ＨＤＬ１６０２のＩＰを、アダプタ１３０１ｄを介してバス１０５に接続している。
【００６９】
図１７では、プロセッサは、ＩＳＳのＣモデル１７０１を、アダプタ１３０１ｅを介してシミュレーション実行部１０３ｃ内のバス１０５に接続し、ハードウェア実行速度の高速化を見込んで、ＦＰＧＡ１７０２にマッピングしたＩＰを、アダプタ１３０１ｆを介してバス１０５に接続している。
【００７０】
図１８に、本発明の設計検証装置を２組接続したシステム構成例を示す。バス１０５ａから見たアダプタ１３０１ｇは、コントローラと同等の位置付けである。ただし、キャッシュへのヒット／ミス判定、あるいはメモリアクセスサイクルの消費は行わない。バス１０５ｂから見たアダプタ１３０１ｇは、イニシエータと同等の位置付けであり、バス１０５ａ経由で転送されてきたリクエストを、もう一方のバス１０５ｂへ発行する。ただし、リクエストがアダプタ１３０１ｇを経由するのに必要なサイクル（パラメータファイルで別途指定）を消費する。
【００７１】
図１９は、本発明の設計検証装置に、従来の検証装置（図２３参照）を接続したシステム構成例である。基本的には図１８の場合と同様であるが、図１４で示したアダプタによる変換手法により、バス２５０８を経由してアダプタ１３０１ｈに発行されてきたピンレベルの信号を、リクエスト（トランザクション）に変換して、バス１０５ｂへ発行する。
【００７２】
したがって、本実施の形態２の設計検証装置によれば、既存の各種設計資産を本発明の設計検証装置に接続可能となり、環境構築が容易となる。また、複数バス構成からなる複雑なアーキテクチャを持つシステムの検証も可能となる。さらにＦＰＧＡを活用することで、シミュレーション速度の高速化が見込める。
【００７３】
すなわち、機能の作り込みを極力行わない、高抽象度なトランザクションレベルのモデリングを主体としつつも、ＦＰＧＡ、ＩＳＳなど機能実装された各種イニシエータモデルを、アダプタを経由して本発明の設計検証装置に接続することが可能であるため、既存の設計資産流用が容易となり、新規にモデル開発を行う工数を削減でき、機能検証（タイミングレベル）にも実用可能となる。
【００７４】
（実施の形態３）
図２０（ａ），（ｂ），（ｃ）は、本発明の実施の形態３において、プロファイル集計機能の組み込み方法の一例を示す図である。
【００７５】
本実施の形態３では、前記実施の形態１による設計検証装置のプロファイリング情報を生成するプロファイル集計機能について説明する。
【００７６】
プロファイリング情報には、図９に示した例のように様々な種類がある。そこで、各プロファイル集計機能ごとに部品化（ライブラリ化）を行い、その組み合わせによって柔軟なプロファイル集計を可能とする。
【００７７】
プロファイル集計機能を組み込み可能な対象は、イニシエータモデルとバスモデルとする。イニシエータモデルにインプリメント（実装）したプロファイル集計機能は、そのイニシエータ固有の機能となり、バスモデルにインプリメントしたプロファイル集計機能は、バスモデルに接続する全イニシエータ共通の機能となる。
【００７８】
どのプロファイル集計機能を、どのモデルに組込むかは、パラメータファイル１０９でカスタマイズを行う。これにより、モデル自体に修正を実施することなく、プロファイル集計方法のカスタマイズが容易となる。
【００７９】
図２０（ａ）では、プロファイル集計機能Ａ，Ｂ，Ｃを、バス１０５のモデルに組込んでいる。全イニシエータ１０４に対して、Ａ，Ｂ，Ｃのプロファイリング情報を得ることができる。
【００８０】
図２０（ｂ）では、プロファイル集計機能Ａをイニシエータ１０４ａに組込み、プロファイル集計機能Ｂをイニシエータ１０４ｂに組込み、プロファイル集計機能Ｃをイニシエータ１０４ｃに組込んでいる。
【００８１】
図２０（ｃ）では、プロファイル集計機能Ａをバス１０５のモデルに組込み、プロファイル集計機能Ｂをイニシエータ１０４ｂに組込み、プロファイル集計機能Ｃをイニシエータ１０４ｃに組込んでいる。イニシエータ１０４ａでは、プロファイル集計機能Ａによるプロファイリング情報を取得でき、イニシエータ１０４ｂでは、プロファイル集計機能ＡとＢによるプロファイリング情報を取得でき、イニシエータ１０４ｃでは、プロファイル集計機能ＡとＣによるプロファイリング情報を取得できる。
【００８２】
（実施の形態４）
図２１は、本発明の実施の形態４において、本発明の設計検証装置の実行環境の一例を示す図、図２２は本発明の設計検証装置によるデモンストレーション実施方法の一例を示す図である。
【００８３】
前記実施の形態１〜３で説明した本発明の設計検証装置の本体は実行プログラム（ソフトウェア）である。この実行プログラム２１０１、及びパラメータファイル・イベントファイル２１０２は、例えばＣＤ−Ｒやフロッピー（登録商標）ディスクなどの記憶媒体２１０３によって提供される。これらのデータを、パーソナルコンピュータなどのプログラム実行環境装置２１０４のメモリにロードして、シミュレーションを実行する。
【００８４】
実行環境装置としてノート型のパーソナルコンピュータ等を用いることでポータビリティが高まり、顧客に対するデモンストテーションが容易となる。これにより、設計早期段階での顧客を交えた仕様決定に有効活用でき、受注拡大効果が期待できる。
【００８５】
図２２に、図２１の環境を利用して、顧客に対するデモンストレーション、及び顧客との仕様決めを行う場合のフローチャートを示す。
【００８６】
まず、記憶媒体２１０３に格納されている本発明の設計検証装置の実行プログラム２１０１とパラメータファイル・イベントファイル２１０２をプログラム実行環境装置（ノート型パーソナルコンピュータ等）２１０４にコピーする（ステップＳ２２０１）。
【００８７】
パラメータファイル・イベントファイル２１０２は、あらかじめ顧客要求仕様に合わせてカスタマイズしたものを用意しておいてもよいし、その場で、システムＬＳＩの構成や、各イニシエータの挙動を定義してもよい（ステップＳ２２０２）。そしてシミュレーションを実行し（ステップＳ２２０３）、実行により出力されるプロファイリング情報の結果の検討を実施する（ステップＳ２２０４）。結果が顧客要求仕様を満足できれば、仕様検討は完了となる。満足できなかった場合は、パラメータファイル・イベントファイルの定義内容を見直して、シミュレーションを再度実行する（ステップＳ２２０５）。このフェーズを繰り返し実施することで、最適なシステム構成や仕様の決定を、顧客を交えて容易に行うことが可能となる。
【００８８】
以上、本発明者によってなされた発明をその実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【００８９】
例えば、前記実施の形態においては、設計検証装置をプログラム（ソフトウェア）本体として説明したが、コンピュータその他のハードウェアで実現することも可能であり、また、ハードウェアとソフトウェアとの組み合わせによって実現することも可能である。
【産業上の利用可能性】
【００９０】
本願において開示される発明は、システムＬＳＩの機能検証、性能評価分野で適用できる。特にＳＯＣ（Ｓｙｓｔｅｍ  Ｏｎ  ａ  Ｃｈｉｐ）においては、大規模化と設計生産性のギャップが拡大しているため、高抽象化、自動化が不可欠であり、本発明の適用による効果が最も大きい。
【図面の簡単な説明】
【００９１】
【図１】本発明の実施の形態１による半導体装置の設計検証装置の構成を示すブロック図である。
【図２】本発明の実施の形態１による半導体装置の設計検証装置において、イニシエータが発行するトランザクションの一例を示す図である。
【図３】本発明の実施の形態１による半導体装置の設計検証装置において、トランザクションを構成する各リクエストのデータ構造の一例を示す図である。
【図４】本発明の実施の形態１による半導体装置の設計検証装置において、パラメータファイルの記述例を示す図である。
【図５】本発明の実施の形態１による半導体装置の設計検証装置において、パラメータファイル内のイニシエータパラメータの一例を示す図である。
【図６】本発明の実施の形態１による半導体装置の設計検証装置において、イベントファイルのフォーマット及び記述例を示す図である。
【図７】本発明の実施の形態１による半導体装置の設計検証装置において、各イニシエータのリクエストキューの一例を示す図である。
【図８】本発明の実施の形態１による半導体装置の設計検証装置の処理フローを示すフローチャートである。
【図９】本発明の実施の形態１による半導体装置の設計検証装置において、シミュレーション実行により得られるプロファイリング情報の一例を示す図である。
【図１０】本発明の実施の形態１による半導体装置の設計検証装置において、制約違反判定の一例を示す図である。
【図１１】本発明の実施の形態１による半導体装置の設計検証装置において、波形出力情報を示す図である。
【図１２】本発明の実施の形態１による半導体装置の設計検証装置において、アービトレーション優先順位の最適解決定方法の一例を示す図である。
【図１３】本発明の実施の形態２による半導体装置の設計検証装置の構成を示すブロック図である。
【図１４】本発明の実施の形態２による半導体装置の設計検証装置において、アダプタによるピンレベルの信号からリクエストへの変換の一例を示す図である。
【図１５】本発明の実施の形態２による半導体装置の設計検証装置において、アダプタの実装方法と接続の一例を示す図である。
【図１６】本発明の実施の形態２による半導体装置の設計検証装置において、ＦＰＧＡ利用によるソフトウェア実行高速化の一例を示す図である。
【図１７】本発明の実施の形態２による半導体装置の設計検証装置において、ＦＰＧＡ利用によるハードウェア実行高速化の一例を示す図である。
【図１８】本発明の実施の形態２において、本発明による設計検証装置を２組接続したシステム構成を示すブロック図である。
【図１９】本発明の実施の形態２において、本発明と従来の設計検証装置を接続したシステム構成を示すブロック図である。
【図２０】（ａ），（ｂ），（ｃ）は、本発明の実施の形態３において、プロファイル集計機能の組み込み方法の一例を示す図である。
【図２１】本発明の実施の形態４において、本発明による設計検証装置の実行環境の一例を示す図である。
【図２２】本発明の実施の形態４において、本発明による設計検証装置を利用したデモンストレーション実施方法の一例を示す図である。
【図２３】本発明者が本発明の前提として検討した半導体装置の設計検証装置の一例を示す図である。
【符号の説明】
【００９２】
１０１，２３０１  設計検証装置
１０２，２３０５  シミュレーションモデル構築部
１０３（ａ〜ｃ），２３０６  シミュレーション実行部
１０４（ａ〜ｅ），２３０７（ａ〜ｃ）  イニシエータ
１０５（ａ〜ｂ），２３０８，２５０８  バス
１０６，２３０９  ルータ・アービタ
１０７（ａ〜ｃ），２３１０（ａ〜ｂ）  コントローラ
１０８，２３１３  制約違反判定部
１０９  パラメータファイル
１１０  イベントファイル
１１１（ａ）  汎用モデルライブラリ
１１２，２３０４（ａ〜ｃ）  機能モデルライブラリ
１１３  消費電力解析ライブラリ
１１４，２３１４  レポート
７０１（ａ〜ｃ）  リクエストキュー
１３０１（ａ〜ｈ）  アダプタ
１５０１  ＦＰＧＡ
１５０２  ＦＰＧＡボード
１５０３  デバイスドライバ
１５０４  アプリケーションＩ／Ｆ
１５０５，２１０４  プログラム実行環境装置
１６０１  ＦＰＧＡ（ＣＰＵ）
１６０２  ＨＤＬ
１７０１  Ｃモデル
１７０２  ＦＰＧＡ（ＩＰ）
２１０１  実行プログラム
２１０２  パラメータファイル・イベントファイル
２１０３  記憶媒体
２３０２  テストパターン
２３０３  制約
２３１１（ａ〜ｂ）  ターゲット
２３１２  シミュレーション結果
【図１】
2006085319.tif 000003
【図２】
2006085319.tif 000004
【図３】
2006085319.tif 000005
【図４】
2006085319.tif 000006
【図５】
2006085319.tif 000007
【図６】
2006085319.tif 000008
【図７】
2006085319.tif 000009
【図８】
2006085319.tif 000010
【図９】
2006085319.tif 000011
【図１０】
2006085319.tif 000012
【図１１】
2006085319.tif 000013
【図１２】
2006085319.tif 000014
【図１３】
2006085319.tif 000015
【図１４】
2006085319.tif 000016
【図１５】
2006085319.tif 000017
【図１６】
2006085319.tif 000018
【図１７】
2006085319.tif 000019
【図１８】
2006085319.tif 000020
【図１９】
2006085319.tif 000021
【図２０】
2006085319.tif 000022
【図２１】
2006085319.tif 000023
【図２２】
2006085319.tif 000024
【図２３】
2006085319.tif 000025