JP2005293219A - ソフトウェア検証モデル生成方法 - Google Patents

Abstract

【課題】 半導体装置に搭載されるハードウェア／ソフトウェアの協調検証を実行する際に必要なソフトウェア検証モデルを生成する方法に関し、バジェット処理の追加方法を最適化してシミュレーション精度を維持しつつ、その性能を向上させることを目的とする。
【解決手段】 ホストＣＰＵにより半導体装置の協調検証を実行するためにソフトウェアの検証モデルを生成する場合に、ソフトウェア部品のBasic Block を認識して制御点を挿入し、制御点が挿入されたソフトウェア部品をコンパイルしてターゲットＣＰＵ用バイナリ・コードを生成し、Basic Block の制御点間の実行時間を算出し、当該実行時間を積算した積算値が指定値以上であると判定された場合に、当該積算値をパラメータとする実行時間挿入文をBasic Block の後の制御点に追加し、当該積算値をクリアして０にし、上記の一連の処理で得られたＣベース言語のソフトウェア部品を検証モデルとして出力する。
【選択図】 図９

Description

本発明は、ホストＣＰＵ（中央処理装置：Central Processing Unit）を使用して、半導体装置に搭載されるハードウェア及びソフトウェアの協調検証（Co-verification）を実行する際に必要となるソフトウェアの検証モデルを生成するためのソフトウェア検証モデル生成方法に関する。

近年、ＳｏＣを搭載した機器が広く普及してきている。ＳｏＣとは、System on a Chipの略で、コンピュータの主要機能を一つのチップ（半導体装置）に詰め込む技術、あるいは、当該技術によりコンピュータの主要機能を搭載したチップを指している。

図１は、かかるＳｏＣの上流設計フローを示す図である。同図に示されるように、システム・レベルの設計が完了した後、アーキテクチャ・レベルの設計に移行する。アーキテクチャ・レベルの設計では、ＣＰＵ、ＲＴＯＳ（Real-Time Operating System）に代表されるＯＳ（Operating System）、バス（Bus）等の基本部品の選択、アプリケーションのハードウェア及びソフトウェアへの機能分割、並びにハードウェア設計及びソフトウェア設計が行われる。そして、アーキテクチャ・レベルの設計により得られた基本部品、ハードウェア部品及びソフトウェア部品に対し、それらの検証モデルに基づくハードウェア／ソフトウェア協調検証が実行される。

ここで、ＲＴＯＳとは、各種の処理をリアルタイムにて実行することを重視し、そのための機能を実装したＯＳを指している。携帯電話、ディジタル・テレビ等のディジタル機器を制御するコンピュータ等では、応答時間が一定の範囲内にあることが要求されるため、上記のＲＴＯＳに対してもリアルタイム性を実現するための様々な機能が必要とされる。

図２は、従来のハードウェア／ソフトウェア協調検証方法を説明するためのデータ流れ図であり、図３は、従来のバジェット処理追加方法を説明するためのフローチャートである。
一般に、半導体装置に搭載されるハードウェア及びソフトウェアの高速協調シミュレーションを実現するためには、基本部品、ハードウェア部品及びソフトウェア部品をモデル化することによって検証モデルを作成することが必要である。

図２に示すように、ソフトウェア部品のＲＴＯＳは通常、ＡＮＳＩ−Ｃ及びアセンブリ言語で記述されている。このＡＮＳＩ−Ｃ及びアセンブリ言語で記述されたＲＴＯＳのソースコードに基づいて、タスク制御及びデータアクセス制御を実行するためのモデル化やタスク切替えを実行するためのモデル化が、人手により行われ、実行時間追加前のＣベース言語で記述された検証モデル（すなわち、Ｃベース・モデル）が作成される。その後、この実行時間追加前の検証モデルにバジェット（Budget）が追加され、実行時間追加後のＣベース言語で記述された検証モデル（すなわち、Ｃベース・モデル）が生成される。なお、本明細書において、「Ｃベース言語」とは、ＡＮＳＩ−Ｃ／Ｃ＋＋の各種拡張言語、ＳｐｅｃＣ、ＳｙｓｔｅｍＣのいずれかの言語を意味する。

また一方で、ソフトウェア部品のアプリケーション・ソフトウェアは通常、ＡＮＳＩ−Ｃで記述されている。ただし、アプリケーション・ソフトウェアの中の割込みハンドラ及びデバイス・ドライバ等においては、それらの設計論理にＡＮＳＩ−Ｃによる記述に加えてアセンブリ言語による記述が含まれることもある。このＡＮＳＩ−Ｃのみ、又は、ＡＮＳＩ−Ｃ及びアセンブリ言語で記述されたアプリケーション・ソフトウェアのソースコードに基づいて、タスク制御及びデータアクセス制御を実行するためのモデル化やタスク切替えを実行するためのモデル化が、人手により行われ、実行時間追加前のＣベース言語で記述された検証モデル（すなわち、Ｃベース・モデル）が作成される。その後、この実行時間追加前の検証モデルにバジェット（Budget）が追加され、実行時間追加後のＣベース言語で記述された検証モデル（すなわち、Ｃベース・モデル）が生成される。

また一方で、ハードウェア部品に関しては、Ｃベース言語で記述された検証モデル（すなわち、Ｃベース・モデル）が作成される。このＣベース・モデルは、ビヘイビア（Behavior）記述又はＲＴＬ（Register Transfer Level）記述による検証モデルである。なお、ビヘイビア記述とは、回路のふるまいを記述したものであり、一方、ＲＴＬ記述とは、レジスタの値が遷移していく様子を記述したものである。

さらに、ハードウェア部品の検証モデルの作成方法について説明する。基本部品に関しては、ＣＰＵ及びＣＰＵ専用の検証モデルは作成されず、ＩＳＳ（Instruction Set Simulator）における割込み処理部を独立させたＩＲＳ（Interrupt Routine Scheduler）が、ＲＴＯＳの検証モデルの一部として新たに導入される。このＩＲＳはＣベース言語で記述される。又、バスの検証モデルは、Ｃベース言語で新規に作成される。

又、Ｃベース言語を用いて論理設計されたビヘイビア（Behavior）記述のハードウェア部品は、動作合成ツールの拡張機能を利用して、Ｃベース言語記述から Fixed I/O Behavior モデルへと自動的に変換されることにより、その検証モデル（Ｃベース・モデル）が生成される。このFixed I/O Behavior モデル は、Basic Block を利用したハードウェア・モデルと同等のものである。

又、Verilog/VHDL を用いて論理設計されたＲＴＬ（（Register Transfer Level）記述のハードウェア部品は、HDL Import（CoWare 社製ツール）等を利用して、ＲＴＬ記述からＲＴＬ−Ｃベース言語モデルへと自動的に変換されることにより、その検証モデル（Ｃベース・モデル）が生成される。このＲＴＬ−Ｃベース言語モデルは、ＦＳＭ（有限状態機械：Finite State Machine）の１ステートが１クロックの動作を表現するものである。

以上のようなＣベース・モデルからなる検証モデル（基本部品、ハードウェア部品及びソフトウェア部品）にシミュレーション全体の動作を制御するＣベース・シミュレータを加えることで、図２に示すような従来のハードウェア／ソフトウェア協調検証方法を実行するための協調検証システム（ソフトウェア構成）が構成される。

図２のバジェット追加部では、ソフトウェア部品の検証モデルを生成する場合、実行時間追加前のＣベース・モデルの中からＡＮＳＩ−Ｃ記述のみによるソースコードの部分（Ｃコードの部分と呼ばれる）を取り出し、図３に示すようなバジェット（Budget）処理を行っている。このバジェット（Budget）処理は、以下のような順序で行われる（例えば、先行技術文献（後述の特許文献１）の特願平2003−024706号（平成15年１月31日出願）参照）。

まず第１に、実行時間追加前のＣベース・モデルの中から取り出したＣコードの部分に対して、Basic Block を認識し、制御点を挿入することにより、制御点が挿入されたＣコードを出力する。このBasic Blockは、ＲＴＯＳ及びアプリケーション・ソフトウェアのプログラムがストレートに走行する部分を指すものである。そして、その認識された Basic Block の前後に制御点が挿入される。

より詳しく説明すると、図３の（Ａ）に示されるＣコードの部分に対しては、ノードａ及びノードｂが一つの Basic Block と認識され、ノードｃ、ノードｄ及びノードｅが一つの Basic Block と認識され、ノードｃ及びノードｆが一つの Basic Block と認識され、ノードｇが一つの Basic Block と認識される。そのため、図３の（Ｂ）に示されるように、ノードｂとノードｃとの間、ノードｅとノードｇとの間、ノードｆとノードｇとの間、及びノードｇの後に、それぞれ制御点が挿入される。

第２に、上記の制御点が挿入されたＣコードの部分をコンパイルすることにより、ターゲットＣＰＵ用バイナリ・コードを生成する。なお、本明細書において、「ターゲットＣＰＵ」とは、検証対象のＳｏＣ等の半導体装置に搭載されているＣＰＵ（例えば、ＡＲＭプロセッサ）を意味する。

第３に、前述のようなコンパイルを行った結果、生成されたターゲットＣＰＵ用バイナリ・コード（命令コード）に基づいて、各々の制御点間の実行時間を算出する。その算出は、
ｋΣ［各命令のサイクル数］
なる演算式に基づいて行われる。ここで、係数ｋは、キャッシュ・メモリのミスヒットに起因するオーバヘッド係数であり、統計的処理による実行時間の補正を可能とするために導入されたものである。

第４に、制御点が挿入されたＣコードの部分の各々の制御点へ、算出された実行時間をパラメータとする実行時間挿入文（ＳｐｅｃＣの場合は、waitfor 文である）を追加し、Ｃベース言語記述の検証モデル（実行時間追加後のＣベース・モデル）として出力する。なお、前述の先行技術文献では、実行時間追加前のＣベース・モデルを「Untimedソフトウェア部品」と称し、上記のバジェット処理追加による実行時間追加後のＣベース・モデルを「Timedソフトウェア部品」と称している。

例えば、図３の（Ｂ）に示されるノードａ及びノードｂの実行時間がｔ１と算出され、ノードｃ、ノードｄ及びノードｅ の実行時間がｔ２と算出され、ノードｃ及びノードｆ の実行時間がｔ３と算出され、ノードｇ の実行時間がｔ４と算出されたとする。この場合には、図３の（Ｃ）に示されるように、ノードｂとノードｃとの間の制御点には、実行時間挿入文として waitfor(t1) が追加される。同様に、ノードｅとノードｇとの間の制御点には実行時間挿入文として waitfor(t2) が追加され、ノードｆとノードｇとの間の制御点には実行時間挿入文として waitfor(t3) が追加され、ノードｇの後の制御点には実行時間挿入文として waitfor(t4) が追加されることとなる。

図４は、このようにして作成されたＣベース言語記述の検証モデルに基づくＣベース・シミュレーションについて説明するための模式図である。Ｃベース言語記述の検証モデルをコンパイルしてホストＣＰＵ用バイナリ・コードを生成することにより、ホストＣＰＵにおいてＣベース・シミュレータを使用したＣベース・シミュレーションが可能となる。ここで、「ホストＣＰＵ」とは、協調検証を実行するパーソナル・コンピュータ（ＰＣ）又はワーク・ステーション（ＷＳ）に搭載されているＣＰＵ（例えば、Pentium（登録商標）プロセッサ）を意味する。

換言すれば、Ｃベース言語記述の検証モデルをコンパイルして生成されたホストＣＰＵ用バイナリ・コードをホストＣＰＵで実行させることにより、命令コードの一命令ごとにその命令内容を解釈してシミュレーションを実行するＩＳＳ（Instruction Set Simulator）の場合に比較して、１００〜１０００倍程度の高速化を図ることができる。

また一方で、シミュレーションの過程において、 waitfor 文が出現したところで、シミュレータがその内容を解釈することにより、命令実行時間の管理が可能となるため、タイミングについてのシミュレーション精度も維持することができる。すなわち、ノードｂに相当する命令コードの実行後には、 waitfor(t1) の命令コードを解釈することで累積処理時間Ｔ１＝ｔ１が求められる。同様に、ノードｅに相当する命令コードの実行後には累積処理時間Ｔ２＝ｔ１＋ｔ２が求められる一方、ノードｆに相当する命令コードの実行後には累積処理時間Ｔ２＝ｔ１＋ｔ３が求められる。

そして、ノードｇに相当する命令コードの実行後には、プログラムがノードｃ、ノードｄ及びノードｅのルートを走行した場合には累積処理時間Ｔ３＝ｔ１＋ｔ２＋ｔ４が求められる一方、プログラムがノードｃ及びノードｆのルートを走行した場合には累積処理時間Ｔ３＝ｔ１＋ｔ３＋ｔ４が求められることとなる。

ここで、参考のため、図２〜図４に関連した先行技術文献（特許文献１）以外に、従来のハードウェア／ソフトウェア協調検証方法に関連した幾つかの先行技術文献を挙げておく。
ＩＳＳを使用した協調検証に関する先行技術文献としては、下記特許文献２〜４の他に、下記の非特許文献１及び２が存在する。なお、下記の非特許文献３は、前述の“Basic Block”に関するものであり、非特許文献４〜６は、前述の“Fixed I/O Behaviorモデル”に関するものであり、非特許文献７〜９は、Ｃベース言語の設計及び検証の技術動向に関するものである。

特願2003−024706号（平成15年１月31日出願） 特開2000−259445号公報 特開2001−256072号公報 特開2002−175344号公報 若林一敏：Ｃ言語によるＬＳＩ設計−動作合成とＨＷ／ＳＷ協調検証の実際、NE Embedded Symposium 2002. 黒川、池上、大坪、浅尾、桐ヶ谷、三栖、高橋、川津、新田、笠、若林、友部、高橋、向山、竹中：Ｃ言語ベースの動作合成を利用したシステムＬＳＩ設計手法の効果分析と考察、電子情報通信学会第１５回軽井沢ワークショップ、pp. 131-142、Apr. 2002. Alfred Aho, Ravi Sethi and Jeffrey Ullman, "Compilers: Principals, Techniques and Tools", Addison-Wesley, 1986. D. W. Knapp, T. Ly, D. MacMillen and R. Miller, "Behavioral Synthesis Methodology for HDL-Based Specification and Validation", Proc. Design Automation Conf., June 1995. T. Ly, D. W. Knapp, R. Miller and D. MacMillen, "Scheduling using Behavioral Templates", Proc. Design Automation Conf., June 1995. D. W. Knapp, "Behavioral Synthesis: Digital System Design using the Synopsys Behavioral Compiler", Prentice Hall PTR. L. Gauthier, S. Yoo and A. A. Jerraya, "Automatic Generation and Targeting of Application Specific Operating Systems and Embedded Systems Software", Proc. Design Automation and Test in Europe, Mar. 2001. D. Lyonnard, S. Yoo, A. Baghdadi and A. A. Jerraya, "Automatic Generation of Application-Specific Architectures for Heterogeneous Multiprocessor System-on-Chip", Proc. Design Automation Conf., June 2001. S. Yoo, G. Nicolescu, L. Gauthier and A. A. Jerraya, "Automatic Generation of Fast Timed Simulation Models for Operating Systems in SoC", Proc. Design Automation and Test in Europe, Mar. 2002.

しかしながら、図２〜図４に示したような従来のハードウェア／ソフトウェア協調検証方法において、バジェット処理の追加により実行時間挿入文（waitfor 文）が追加された検証モデルを使用してＣベース・シミュレーションを実行した場合、Ｃコードの１０行程度に対し１回の頻度でwaitfor 文が追加されるようになり、バジェット処理を追加しない場合に比べてwaitfor 文の追加頻度がかなり高くなる。このため、バジェット処理を追加しない場合に比べて、Ｃベース・シミュレーションの実行速度が遅くなってシミュレーション性能が低下するという問題が生じてくる。例えば、「宣教師と人食い人」、「ハノイの塔」等の１０種のサンプルプログラムを対象にして、バジェット処理の追加によりwaitfor 文を追加した場合、バジェット処理を追加しない場合に比べてシミュレーション性能を示すＭＩＰＳ値（Million Instructions Per Second ：シミュレーション時間／実行時間）の平均値が約１／５０に低下するようになる。

本発明は、上記問題点に鑑みてなされたものであり、バジェット処理の追加方法を最適化することでシミュレーション精度を維持しつつ、従来方法よりもシミュレーションの実行速度を速くしてシミュレーション性能を向上させることを可能にするようなソフトウェア検証モデル生成方法を提供することを目的とするものである。

上記目的を達成するために、本発明の第１の面によれば、ホストＣＰＵを使用して、一つのターゲットＣＰＵ及び一つのＯＳが少なくとも搭載される半導体装置のハードウェア及びソフトウェアの協調検証を実行するために、ソフトウェアの検証モデルを生成する場合に、Ｃベース言語記述のソフトウェア部品を入力してＡＮＳＩ−Ｃ記述部分を取り出し、Basic Block を認識し、制御点を挿入するステップと、当該制御点が挿入された上記ＡＮＳＩ−Ｃ記述部分をコンパイルしてターゲットＣＰＵ用バイナリ・コードを生成するステップと、上記Basic Block の各々について、当該Basic Block の制御点間の実行時間を算出するステップと、算出された当該実行時間を積算するステップと、当該実行時間を積算して得られる積算値が予め指定された指定値以上であるか否かを判定するステップと、上記積算値が上記指定値以上であると判定された場合に、上記積算値をパラメータとする実行時間挿入文を当該Basic Block の後の制御点に追加し、上記積算値をクリアして０にするステップと、上記の一連のステップで得られたＣベース言語記述のソフトウェア部品を上記検証モデルとして出力するステップとを有するソフトウェア検証モデル生成方法が提供される。

さらに、本発明の第２の面によれば、ホストＣＰＵを使用して、一つのターゲットＣＰＵ及び一つのＯＳが少なくとも搭載される半導体装置のハードウェア及びソフトウェアの協調検証を実行するために、ソフトウェアの検証モデルを生成する場合に、Ｃベース言語記述のソフトウェア部品を入力してＡＮＳＩ−Ｃ記述部分を取り出し、Basic Block を認識し、制御点を挿入するステップと、当該制御点が挿入された上記ＡＮＳＩ−Ｃ記述部分をコンパイルしてターゲットＣＰＵ用バイナリ・コードを生成するステップと、上記Basic Block の各々について、当該Basic Block の制御点間の実行時間を算出するステップと、算出された当該実行時間を積算するステップと、上記ＯＳに関係するサービス・コールの発行時もしくは受信時のいずれか一方のイベント、又は、上記ハードウェアに関係するイベントが発生する箇所に、上記実行時間を積算して得られる積算値をパラメータとする実行時間挿入文を追加し、上記積算値をクリアして０にするステップと、上記の一連のステップで得られたＣベース言語記述のソフトウェア部品を上記検証モデルとして出力するステップとを有するソフトウェア検証モデル生成方法が提供される。

さらに、本発明の第３の面によれば、ホストＣＰＵを使用して、一つのターゲットＣＰＵ及び一つのＯＳが少なくとも搭載される半導体装置のハードウェア及びソフトウェアの協調検証を実行するために、ソフトウェアの検証モデルを生成する場合に、Ｃベース言語記述のソフトウェア部品を入力してＡＮＳＩ−Ｃ記述部分を取り出し、Basic Block を認識し、制御点を挿入するステップと、当該制御点が挿入された上記ＡＮＳＩ−Ｃ記述部分をコンパイルしてターゲットＣＰＵ用バイナリ・コードを生成するステップと、上記Basic Block の各々について、当該Basic Block の制御点間の実行時間を算出するステップと、算出された当該実行時間を積算するステップと、当該実行時間を積算して得られる積算値が予め指定された指定値以上であるか否かを判定するステップと、上記積算値が上記指定値以上であると判定された場合に、上記積算値をパラメータとする実行時間挿入文を当該Basic Block の後の制御点に追加し、上記積算値をクリアして０にするステップと、上記ＯＳに関係するサービス・コールの発行時もしくは受信時のいずれか一方のイベント、又は、上記ハードウェアに関係するイベントが発生する箇所に、上記積算値をパラメータとする実行時間挿入文を追加し、上記積算値をクリアして０にするステップと、上記の一連のステップで得られたＣベース言語記述のソフトウェア部品を上記検証モデルとして出力するステップとを有するソフトウェア検証モデル生成方法が提供される。

要約すれば、本発明では、Ｃベース言語記述のソフトウェア部品のBasic Block に挿入された各々の制御点間の実行時間を算出すると共に、当該実行時間を積算して得られる積算値が指定値以上であると判定された場合にのみ、当該積算値をパラメータとするwaitfor 文を上記ソフトウェア部品に追加するようにしている（後述のバジェット処理（Budget proc）１）。それゆえに、従来方法に比べてwaitfor 文の追加頻度が節減されるので、従来方法よりもシミュレーションの実行速度が速くなってシミュレーション性能が向上する。この場合、当該積算値が指定値以上であると判定された場合に当該積算値をパラメータとするwaitfor 文を追加し、Ｃベース・シミュレータが当該waitfor 文を解釈して命令実行時間の管理を行うことができるので、従来方法に比べてシミュレーション精度がそれほど低下することはない。

さらに、本発明では、Ｃベース言語記述のソフトウェア部品のBasic Block に挿入された各々の制御点間の実行時間を算出すると共に、当該実行時間を積算して積算値を算出するようにしている（後述のバジェット処理２）。それゆえに、前述のバジェット処理１の場合と同様に、waitfor 文の追加頻度が節減されるので、従来方法よりもシミュレーションの実行速度が速くなってシミュレーション性能が向上する。

また一方で、本発明では、Ｃベース言語記述のソフトウェア部品のBasic Block に挿入された各々の制御点間の実行時間を算出すると共に、当該実行時間を積算して積算値を算出するようにしている（後述のバジェット処理２）。さらに、ＲＴＯＳ等のＯＳに関係するサービス・コールの発行時又は受信時のいずれか一方のイベント、もしくはハードウェアとソフトウェアとの通信に関するイベント（例えば、バス・アクセス時、ディスパッチ時又はＣＰＵ例外・割込み受信時のイベント）が発生する箇所に、現在の積算値をパラメータとするwaitfor 文を追加している（後述のバジェット処理３）。これらのバジェット処理２及びバジェット処理３を組み合せて使用することにより、waitfor 文の追加頻度の最適化を図りつつ従来方法とほぼ同等のシミュレーション精度を維持することが可能になる。

また一方で、本発明では、上記のバジェット処理１及びバジェット処理３を組み合せて使用することにより、waitfor 文の追加頻度の最適化を図りつつ従来方法とほぼ同等のシミュレーション精度を維持することが可能になる。

以下、添付図面を参照して本発明の実施形態について説明する。
図５は、本発明に係るソフトウェア検証モデル生成方法を実施するためのハードウェア環境を例示するブロック図である。なお、これ以降、前述した構成要素と同様のものについては、同一の参照番号を付して表すこととする。

図５に例示されるように、本発明に係るソフトウェア検証モデル生成方法（又はハードウェア／ソフトウェア協調検証方法）は、中央処理装置（ＣＰＵ）１２及び主記憶装置（ＭＳ）１４を有するコンピュータ本体１０、ディスプレイ２０、キーボード２２、マウス２４、ハードディスク装置等からなる外部記憶装置３０を備える通常のパーソナル・コンピュータ（ＰＣ）又はワーク・ステーション（ＷＳ）上で実行可能である。

ＣＰＵ１２は、ソフトウェア検証モデル生成（又はハードウェア／ソフトウェア協調検証）を実行するホストＣＰＵとして動作するものであり、例えば、Pentiumプロセッサである。以下に説明されるソフトウェア検証モデル生成（又はハードウェア／ソフトウェア協調検証）のためのプログラムは、ＣＰＵ１２によって実行される。又、各種のデータ、ファイル等は、外部記憶装置３０から主記憶装置（ＭＳ）１４にロードされて処理される。

図６は、本発明の実施形態に関連するハードウェア／ソフトウェア協調検証システム（ソフトウェア構成）を示すブロック図である。
図６においては、半導体装置に搭載されるハードウェア及びソフトウェアの協調検証を実行するために、ソフトウェア部品（ここでは、説明の便宜上、基本部品のＲＴＯＳをソフトウェア部品に含ませている）４０と、ハードウェア部品６０とがモデル化されている。

一般に、ソフトウェア部品のＲＴＯＳは、ＡＮＳＩ−Ｃ及びアセンブリ言語で記述されている。このＡＮＳＩ−Ｃ及びアセンブリ言語で記述されたＲＴＯＳのソースコードに基づいて、タスク制御及びデータアクセス制御を実行するためのモデル化やタスク切替えを実行するためのモデル化が、人手により行われ、実行時間追加前のＣベース言語で記述された検証モデル（すなわち、Ｃベース・モデル）が作成される。その後、この実行時間追加前の検証モデルにバジェット（Budget）が追加され、実行時間追加後のＣベース言語で記述されたＲＴＯＳ４３が、検証モデル（すなわち、Ｃベース・モデル）として生成される。

さらに、ソフトウェア部品のアプリケーション・ソフトウェアは、一般に、ＡＮＳＩ−Ｃで記述されている。ただし、アプリケーション・ソフトウェアの中の割込みハンドラ及びデバイス・ドライバ等においては、それらの設計論理にＡＮＳＩ−Ｃによる記述に加えてアセンブリ言語による記述が含まれることもある。このＡＮＳＩ−Ｃのみ、又は、ＡＮＳＩ−Ｃ及びアセンブリ言語で記述されたアプリケーション・ソフトウェアのソースコードに基づいて、タスク制御及びデータアクセス制御を実行するためのモデル化やタスク切替えを実行するためのモデル化が、人手により行われ、実行時間追加前のＣベース言語で記述された検証モデル（すなわち、Ｃベース・モデル）が作成される。その後、この実行時間追加前の検証モデルにバジェット（Budget）が追加され、実行時間追加後のＣベース言語で記述されたソフトウェア４０が、検証モデル（すなわち、Ｃベース・モデル）として生成される。

このようにして生成されたソフトウェア部品４０は、種々のタスク処理を実行する複数のタスク４１（タスクａ、タスクｂ、…、タスクｘ）と、ＣＰＵ例外処理やＣＰＵ割込み処理等を実行する割込みハンドラ４２と、上記タスクの切替え処理等を実行するディスパッチャ４４と、バス５０を経由してハードウェア部品６０とのデータアクセス（すなわち、バス・アクセス）等を実行する複数のデバイス・ドライバ４５（デバイス・ドライバ１、デバイス・ドライバ２、…、デバイス・ドライバｎ）とを含む。

さらに、本発明に係るソフトウェア部品４０では、後述の図７〜図１５にて詳しく説明するように、バジェット処理１（解決方法♯１）、バジェット処理２及びバジェット処理３の組み合せ（解決方法♯２）、又は、バジェット処理１及びバジェット処理３の組み合せ（解決方法♯３）のいずれか一つが含まれている。

また一方で、複数のハードウェア部品６０（ハードウェア部品１、ハードウェア部品２、…、ハードウェア部品ｎ）は、Ｃベース言語で記述された検証モデルとして作成される。図６では、バス５０は、ハードウェア部品６０から分離されているが、通常は、ハードウェア部品６０に含まれるものである。さらに、ハードウェア部品６０は、Ｃベース言語を用いたビヘイビア（Behavior）記述又はＲＴＬ記述による検証モデルが使用される。上記のハードウェア部品６０の各々は、動作終了時に、割込み信号（割込み１、割込み２、…、割込みｎ）を生成してディスパッチャ４４に送出する。

以上のような検証モデル（ソフトウェア部品４０及びハードウェア部品６０）にシミュレーション全体の動作を制御するＣベース・シミュレータ７０を加えることで、本発明の実施形態に関連するハードウェア／ソフトウェア協調検証システムが構成される。

図７は、Ｃベース言語記述のソフトウェア部品に基づいて本発明に係るバジェット処理１を実行するプログラムの処理手順を説明するためのフローチャートであり、図８は、Ｃベース言語記述のソフトウェア部品に基づいて本発明に係るバジェット処理２を実行するプログラムの処理手順を説明するためのフローチャートである。
さらに、図９は、図７に示されるような本発明に係るバジェット処理１の追加によるソフトウェア検証モデル生成方法を説明するための模式図であり、図１０は、図８に示されるような本発明に係るバジェット処理２の追加によるソフトウェア検証モデル生成方法を説明するための模式図である。

以下、図７及び図９を参照しながら、Ｃベース言語記述のソフトウェア部品８０に基づいて本発明に係るバジェット処理１を実行するプログラムの処理手順を説明する。

まず、図７のステップ１０５では、実行時間追加前のＣベース言語で記述されたソフトウェア部品８０を入力して、このソフトウェア部品の中からＡＮＳＩ−Ｃ記述のみによるソースコードの部分（Ｃコードの部分と呼ばれる）を取り出す。次いで、ステップ１１０では、このＣコードの部分に対して、Basic Block を認識し、制御点を挿入することにより、制御点が挿入されたＣコードの部分８２を出力する。このBasic Blockは、プログラムがストレートに走行する部分を指すものである。そして、その認識された Basic Block の前後に制御点が挿入される。

より詳しく説明すると、図９の（Ａ）に示されるＣコードの部分に対しては、ノードａ及びノードｂが一つの Basic Block と認識され、ノードｃ、ノードｄ及びノードｅが一つの Basic Block と認識され、ノードｃ及びノードｆが一つの Basic Block と認識され、ノードｇが一つの Basic Block と認識される。そのため、図９の（Ｂ）に示されるように、ノードｂとノードｃとの間、ノードｅとノードｇとの間、ノードｆとノードｇとの間、及びノードｇの後に、それぞれ制御点が挿入される。

さらに、ステップ１２０では、かかる制御点が挿入されたＣコードの部分８２をコンパイルすることにより、ターゲットＣＰＵ用のバイナリ・コード８４を生成する。

さらに、ステップ１８０では、Ｃコードの部分８２からBasic Block を順次取り出す。さらに、ステップ１８５では、取り出すBasic Block があるか否かを判定する。取り出すBasic Block があると判定された場合は、さらに、ステップ１９０のバジェット処理１を行い、ステップ１８０に分岐する。一方、取り出すBasic Block がないと判定された場合は、バジェット処理１が追加されたＣベース言語記述のソフトウェア部品を検証モデル８６として出力し、本プログラムの処理を終了する。

図１１は、ステップ１９０のバジェット処理１を実行するプログラムの処理手順を説明するためのフローチャートである。以下、図９および図１１を参照しながら、ステップ１９０のバジェット処理１を実行するプログラムの処理手順を説明する。

まず、ステップ１３０では、前述のコンパイルの結果、生成されたターゲットＣＰＵ用バイナリ・コード（命令コード）８４に基づいて、ステップ１８０で取り出したBasic Block の制御点間の実行時間を算出する。その算出は、
ｋΣ［各命令のサイクル数］
なる演算式に基づいて行われる。ここで、係数ｋは、キャッシュ・メモリのミスヒットに起因するオーバヘッド係数であり、本実施形態においてはキャッシュ・メモリ・モデルを設けないことから、統計的処理による実行時間の補正を可能とするために導入されたものである。

さらに、ステップ１４０では、ステップ１３０で算出された実行時間を積算する。
さらに、ステップ１５０では、ステップ１４０で実行時間を積算して得られる積算値が予め定められた指定値以上であるか否かを判定する。

さらに、ステップ１６０では、当該積算値が予め定められた指定値以上であると判定された場合に、当該積算値をパラメータとする実行時間挿入文を当該Basic Block の後の制御点に追加する。一方、当該積算値が予め定められた指定値未満であると判定された場合には、本プログラムの処理を終了する。

例えば、ステップ１３０において、図９の（Ｂ）に示されるノードａ及びノードｂの実行時間がｔ１と算出され、ノードｃ、ノードｄ及びノードｅ の実行時間がｔ２と算出され、ノードｃ及びノードｆ の実行時間がｔ３と算出され、ノードｇ の実行時間がｔ４と算出されたとする。

この場合、ステップ１４０において、ノードｂに相当する命令コードの実行後には、積算時間Ｔ１＝ｔ１が算出される。同様に、ノードｅに相当する命令コードの実行後には積算時間Ｔ２＝ｔ１＋ｔ２が算出される一方、ノードｆに相当する命令コードの実行後には積算時間Ｔ２＝ｔ１＋ｔ３が算出される。

そして、ノードｇに相当する命令コードの実行後には、プログラムがノードｃ、ノードｄ及びノードｅ のルートを走行した場合には積算時間Ｔ３＝ｔ１＋ｔ２＋ｔ４が算出される一方、プログラムがノードｃ及びノードｆのルートを走行した場合には積算時間Ｔ３＝ｔ１＋ｔ３＋ｔ４が算出されることとなる。

ここでは、ステップ１５０にて当該実行時間の積算値が予め定められた指定値以上であると判定された制御点に対してのみ、図９の（Ｃ）に示されるように、バジェット処理１を検証モデルに追加することによってwaitfor 文が追加される。この結果、waitfor 文の追加頻度が節減され、シミュレーション性能（シミュレーションの実行速度）が向上する。

最後に、ステップ１７０において、実行時間挿入文を追加した後に当該実行時間の積算値をクリアして０に戻す。

以下、図８及び図１０を参照しながら、Ｃベース言語記述のソフトウェア部品８０に基づいて本発明に係るバジェット処理２を実行するプログラムの処理手順を説明する。

図８のステップ１０５〜ステップ１８０では、前述のステップ１０５〜ステップ１８０の処理の内容と同様の処理が行われる。したがって、ここでは、ステップ１０５〜ステップ１８０に関する再度の説明を省略し、図８で新たに設けたステップ１８６とステップ１９５について説明する。

ステップ１８６では、取り出すBasic Block があるか否かを判定する。取り出すBasic Block があると判定された場合は、さらに、ステップ１９５のバジェット処理２を行い、ステップ１８０に分岐する。一方、取り出すBasic Block がないと判定された場合は、バジェット処理２が追加されたＣベース言語記述のソフトウェア部品を検証モデル８８として出力し、本プログラムの処理を終了する。

図１２は、ステップ１９５のバジェット処理２を実行するプログラムの処理手順を説明するためのフローチャートである。図１２のステップ１３０とステップ１４０では、前述の図１１のステップ１３０とステップ１４０の処理の内容と同様の処理が行われる。したがって、ここでは、ステップ１３０とステップ１４０に関する再度の説明を省略する。

バジェット処理２では、実行時間を積算するのみで、制御点に対してwaitfor 文を追加することはしない。

より詳しく説明すると、図１０の（Ａ）に示されるＣコードの部分に対しては、前述の図９の（Ａ）の場合と同様に、ノードａ及びノードｂが一つの Basic Block と認識され、ノードｃ、ノードｄ及びノードｅが一つの Basic Block と認識され、ノードｃ及びノードｆが一つの Basic Block と認識され、ノードｇが一つの Basic Block と認識される。そのため、図１０の（Ｂ）に示されるように、ノードｂとノードｃとの間、ノードｅとノードｇとの間、ノードｆとノードｇとの間、及びノードｇの後に、それぞれ制御点が挿入される。

上記のバジェット処理２では、図１０の（Ｃ）に示されるように、各々の制御点に関して、ステップ１４０にて算出された当該実行時間を積算する。上記実行時間の積算値は、後述の図１３及び図１４のバジェット処理３を追加する場合に利用される。

図１３は、ＲＴＯＳに関係するイベントやハードウェアに関係するイベントが発生する個所を示すブロック図であり、図１４は、本発明に係るバジェット処理３の追加によるソフトウェア検証モデル生成方法を説明するためのブロック図である。

一般に、図６に示されるようなハードウェア／ソフトウェア協調検証システムにおいて、ＲＴＯＳ４３を使用してタスク制御やデータアクセス制御等の各種の制御を行っている間に、タスクのアプリケーション・ソフトウェア（サービス・コール部４８）から、現在サービス・コール発行時であることを示すイベントが発生する。また一方で、ＲＴＯＳ４３のサービス・コール処理部４６では、現在サービス・コール受信時であることを示すイベントが発生する。

さらに、ディスパッチャ４４により複数のタスクと割込みハンドラ４２との間で切替え処理を実行するときに、現在ディスパッチ時（切替え処理時）であることを示すイベントが発生する。

さらに、バス・アクセス部４９が動作してデバイス・ドライバとハードウェア部品との間でデータアクセスが実行されるときに、現在バス・アクセス時であることを示すイベントが発生する。

さらに、ハードウェアの動作が終了してＣＰＵ例外・割込みのフラグが設定されたときに、ＣＰＵ例外・割込み処理部４７から、現在ＣＰＵ例外・割込み受信時であることを示すイベントが発生する。

換言すれば、上記のイベントは、タスクがサービス・コールを発行したとき、又はＲＴＯＳがサービス・コールを受信したときに対応する箇所（図１３の●の部分）で発生する。また一方で、上記のイベントは、タスクや割込みハンドラのディスパッチを行ったときに対応する（図１３の●の部分）箇所で発生する。また一方で、上記のイベントは、ハードウェア部品とソフトウェア部品との間でバス・アクセスやＣＰＵ例外・割込み等の通信を行ったときに対応する箇所（図１３の●の部分）で発生する。

本発明の実施形態では、図１４に示されるように、上記のようなイベントが発生する箇所に、現在の積算値をパラメータとしてwaitfor 文を追加することにより、本発明に係るバジェット処理３を追加する。このwaitfor 文を追加した後は、現在の積算値をクリアして０に戻す。

イベントが発生する箇所は、ハードウェア／ソフトウェア協調検証を実行する際の実行時間を管理する上で重要であり、当該箇所に現在の積算値をパラメータとするwaitfor 文を追加することによって実行時間を管理するようにしている。このバジェット処理３は、前述のバジェット処理１又はバジェット処理２と組み合せることによって、waitfor 文の追加頻度の最適化が図れるようになり、シミュレーション性能（シミュレーションの実行速度）が向上する。

図１５は、本発明に係る３つの解決方法とその効果を示す図である。
本発明に係る解決方法♯１は、例えば図７、図９及び図１１に示したように、バジェット処理１を追加することによって、Ｃベース言語記述のソフトウェア部品のBasic Block に挿入された各々の制御点間の実行時間を算出すると共に、当該実行時間を積算して得られる積算値が指定値以上であると判定された場合にのみ当該積算値をパラメータとするwaitfor 文を上記ソフトウェア部品に追加する方法である。

本発明に係る解決方法♯２は、例えば図８、図１０、図１２、図１３及び図１４に示したように、バジェット処理２及びバジェット処理３を追加することによって、Ｃベース言語記述のソフトウェア部品のBasic Block に挿入された各々の制御点間の実行時間を算出すると共に、当該実行時間を積算して積算値を算出し、かつ、ＲＴＯＳに関係するサービス・コールの発行時又は受信時のいずれか一方のイベント、もしくはハードウェアに関係するイベントが発生する箇所に、現在の積算値をパラメータとするwaitfor 文を追加する方法である。

本発明に係る解決方法♯３は、例えば図７、図９、図１１、図１３及び図１４に示したように、バジェット処理１及びバジェット処理３を追加することによって、Ｃベース言語記述のソフトウェア部品のBasic Block に挿入された各々の制御点間の実行時間を算出すると共に、当該実行時間を積算して得られる積算値が指定値以上であると判定された場合に、当該Basic Block の後の制御点に当該積算値をパラメータとするwaitfor 文を追加し、又は、ＲＴＯＳに関係するサービス・コールの発行時又は受信時のいずれか一方のイベント、もしくはハードウェアに関係するイベントが発生する箇所に、現在の積算値をパラメータとするwaitfor 文を追加する方法である。

図１５から明らかなように、シミュレーション精度に関しては、例えば図３及び図４に示したような従来方法が最も高精度になっており、従来方法→解決方法♯３→解決方法♯１→解決方法♯２の順に低精度になっていく。

また一方で、シミュレーション性能（シミュレーションの実行速度）に関しては、解決方法♯２が最も高性能になっており、解決方法♯２→解決方法♯１→解決方法♯３→従来方法の順に低性能になっていく。

本発明は、携帯電話、ディジタル・テレビ等のディジタル機器を制御するコンピュータの主要機能を搭載した半導体装置（チップ）の設計が完了した後に、検証モデルに基づいて高性能のハードウェア／ソフトウェア協調検証を実行するためのハードウェア／ソフトウェア協調検証システムに適用することが可能である。

ＳｏＣの上流設計フローを示すフローチャートである。 従来のハードウェア／ソフトウェア協調検証方法を説明するためのデータ流れ図である。 従来のバジェット処理追加方法を説明するための模式図である。 図３にて生成されたＣベース言語記述の検証モデルに基づくＣベース・シミュレーションについて説明するための模式図である。 本発明に係るソフトウェア検証モデル生成方法を実施するためのハードウェア環境を例示するブロック図である。 本発明の実施形態に関連するハードウェア／ソフトウェア協調検証システムの構成（ソフトウェア構成）を示すブロック図である。 Ｃベース言語記述のソフトウェア部品に基づいて本発明に係るバジェット処理１を実行するプログラムの処理手順を説明するためのフローチャートである。 Ｃベース言語記述のソフトウェア部品に基づいて本発明に係るバジェット処理２を実行するプログラムの処理手順を説明するためのフローチャートである。 本発明に係るバジェット処理１の追加によるソフトウェア検証モデル生成方法を説明するための模式図である。 本発明に係るバジェット処理２の追加によるソフトウェア検証モデル生成方法を説明するための模式図である。 図７のステップ１９０のバジェット処理１を実行するプログラムの処理手順を説明するためのフローチャートである。 図８のステップ１９５のバジェット処理２を実行するプログラムの処理手順を説明するためのフローチャートである。 ＲＴＯＳに関係するイベントやハードウェアに関係するイベントが発生する箇所を示すブロック図である。 本発明に係るバジェット処理３の追加によるソフトウェア検証モデル生成方法を説明するためのブロック図である。 本発明に係る３つの解決方法とその効果を示す図である。

符号の説明

１０…コンピュータ（ＰＣ又はＷＳ）本体
１２…中央処理装置（ＣＰＵ）
１４…主記憶装置（ＭＳ）
２０…ディスプレイ
２２…キーボード
２４…マウス
３０…外部記憶装置（ハードディスク装置）
４０…ソフトウェア部品
４１…タスク
４２…割込みハンドラ
４３…リアルタイム・オペレーティングシステム（ＲＴＯＳ）
４４…ディスパッチャ
４５…デバイス・ドライバ
５０…キーボード
６０…ハードウェア部品
７０…Ｃベース・シミュレータ

Claims (5)

1. ホストＣＰＵを使用して、一つのターゲットＣＰＵ及び一つのＯＳが少なくとも搭載される半導体装置のハードウェア及びソフトウェアの協調検証を実行するために、ソフトウェアの検証モデルを生成するソフトウェア検証モデル生成方法であって、
   Ｃベース言語記述のソフトウェア部品を入力してＡＮＳＩ−Ｃ記述部分を取り出し、Basic Block を認識し、制御点を挿入するステップと、
   該制御点が挿入された前記ＡＮＳＩ−Ｃ記述部分をコンパイルしてターゲットＣＰＵ用バイナリ・コードを生成するステップと、
   前記Basic Block の各々について、該Basic Block の制御点間の実行時間を算出するステップと、
   算出された該実行時間を積算するステップと、
   該実行時間を積算して得られる積算値が予め指定された指定値以上であるか否かを判定するステップと、
   前記積算値が前記指定値以上であると判定された場合に、前記積算値をパラメータとする実行時間挿入文を該Basic Block の後の制御点に追加し、前記積算値をクリアして０にするステップと、
   前記の一連のステップで得られたＣベース言語記述のソフトウェア部品を前記検証モデルとして出力するステップとを有することを特徴とするソフトウェア検証モデル生成方法。
2. ホストＣＰＵを使用して、一つのターゲットＣＰＵ及び一つのＯＳが少なくとも搭載される半導体装置のハードウェア及びソフトウェアの協調検証を実行するために、ソフトウェアの検証モデルを生成するソフトウェア検証モデル生成方法であって、
   Ｃベース言語記述のソフトウェア部品を入力してＡＮＳＩ−Ｃ記述部分を取り出し、Basic Block を認識し、制御点を挿入するステップと、
   該制御点が挿入された前記ＡＮＳＩ−Ｃ記述部分をコンパイルしてターゲットＣＰＵ用バイナリ・コードを生成するステップと、
   前記Basic Block の各々について、該Basic Block の制御点間の実行時間を算出するステップと、
   算出された該実行時間を積算するステップと、
   前記ＯＳに関係するサービス・コールの発行時のイベント、又は、前記ハードウェアに関係するイベントが発生する箇所に、前記実行時間を積算して得られる積算値をパラメータとする実行時間挿入文を追加し、前記積算値をクリアして０にするステップと、
   前記の一連のステップで得られたＣベース言語記述のソフトウェア部品を前記検証モデルとして出力するステップとを有することを特徴とするソフトウェア検証モデル生成方法。
3. ホストＣＰＵを使用して、一つのターゲットＣＰＵ及び一つのＯＳが少なくとも搭載される半導体装置のハードウェア及びソフトウェアの協調検証を実行するために、ソフトウェアの検証モデルを生成するソフトウェア検証モデル生成方法であって、
   Ｃベース言語記述のソフトウェア部品を入力してＡＮＳＩ−Ｃ記述部分を取り出し、Basic Block を認識し、制御点を挿入するステップと、
   該制御点が挿入された前記ＡＮＳＩ−Ｃ記述部分をコンパイルしてターゲットＣＰＵ用バイナリ・コードを生成するステップと、
   前記Basic Block の各々について、該Basic Block の制御点間の実行時間を算出するステップと、
   算出された該実行時間を積算するステップと、
   前記ＯＳに関係するサービス・コールの受信時のイベント、又は、前記ハードウェアに関係するイベントが発生する箇所に、前記実行時間を積算して得られる積算値をパラメータとする実行時間挿入文を追加し、前記積算値をクリアして０にするステップと、
   前記の一連のステップで得られたＣベース言語記述のソフトウェア部品を前記検証モデルとして出力するステップとを有することを特徴とするソフトウェア検証モデル生成方法。
4. ホストＣＰＵを使用して、一つのターゲットＣＰＵ及び一つのＯＳが少なくとも搭載される半導体装置のハードウェア及びソフトウェアの協調検証を実行するために、ソフトウェアの検証モデルを生成するソフトウェア検証モデル生成方法であって、
   Ｃベース言語記述のソフトウェア部品を入力してＡＮＳＩ−Ｃ記述部分を取り出し、Basic Block を認識し、制御点を挿入するステップと、
   該制御点が挿入された前記ＡＮＳＩ−Ｃ記述部分をコンパイルしてターゲットＣＰＵ用バイナリ・コードを生成するステップと、
   前記Basic Block の各々について、該Basic Block の制御点間の実行時間を算出するステップと、
   算出された該実行時間を積算するステップと、
   該実行時間を積算して得られる積算値が予め指定された指定値以上であるか否かを判定するステップと、
   前記積算値が前記指定値以上であると判定された場合に、前記積算値をパラメータとする実行時間挿入文を該Basic Block の後の制御点に追加し、前記積算値をクリアして０にするステップと、
   前記ＯＳに関係するサービス・コールの発行時のイベント、又は、前記ハードウェアに関係するイベントが発生する箇所に、前記積算値をパラメータとする実行時間挿入文を追加し、前記積算値をクリアして０にするステップと、
   前記の一連のステップで得られたＣベース言語記述のソフトウェア部品を前記検証モデルとして出力するステップとを有することを特徴とするソフトウェア検証モデル生成方法。
5. ホストＣＰＵを使用して、一つのターゲットＣＰＵ及び一つのＯＳが少なくとも搭載される半導体装置のハードウェア及びソフトウェアの協調検証を実行するために、ソフトウェアの検証モデルを生成するソフトウェア検証モデル生成方法であって、
   Ｃベース言語記述のソフトウェア部品を入力してＡＮＳＩ−Ｃ記述部分を取り出し、Basic Block を認識し、制御点を挿入するステップと、
   該制御点が挿入された前記ＡＮＳＩ−Ｃ記述部分をコンパイルしてターゲットＣＰＵ用バイナリ・コードを生成するステップと、
   前記Basic Block の各々について、該Basic Block の制御点間の実行時間を算出するステップと、
   算出された該実行時間を積算するステップと、
   該実行時間を積算して得られる積算値が予め指定された指定値以上であるか否かを判定するステップと、
   前記積算値が前記指定値以上であると判定された場合に、前記積算値をパラメータとする実行時間挿入文を該Basic Block の後の制御点に追加し、前記積算値をクリアして０にするステップと、
   前記ＯＳに関係するサービス・コールの受信時のイベント、又は、前記ハードウェアに関係するイベントが発生する箇所に、前記積算値をパラメータとする実行時間挿入文を追加し、前記積算値をクリアして０にするステップと、
   前記の一連のステップで得られたＣベース言語記述のソフトウェア部品を前記検証モデルとして出力するステップとを有することを特徴とするソフトウェア検証モデル生成方法。

Images