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

Description

本発明は、キャッシュメモリを有するホストＣＰＵ（中央処理装置：Central Processing Unit ）を使用して、キャッシュメモリの動作を考慮しながら、半導体装置に搭載されるハードウェア及びソフトウェアの協調検証（Co-verification ）を実行する際に必要となるソフトウェアの検証モデルを生成するためのソフトウェア検証モデル生成方法に関する。
ここで、キャッシュメモリとは、ホストＣＰＵと主記憶装置（メインメモリ）との間で、ホストＣＰＵが頻繁に読み書きするデータの転送を高速にて行う目的で当該データをため込むためのメモリを指している。

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

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

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

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

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

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

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

図２のバジェット追加部（バジェット追加ツールとも呼ばれる）では、ソフトウェア部品の検証モデルを生成する場合、実行時間追加前のＣベース・モデルの中からＡＮＳＩ−Ｃ記述のみによるソースコードの部分（Ｃコードの部分と呼ばれる）を取り出し、図３に示すようなタイミングバジェット（Timing Budget）追加処理を行っている。このタイミングバジェット（Timing 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（登録商標）プロセッサ）を意味する。

換言すれば、図３及び図４に示したようなバジェット処理追加によりソフトウェア部品の検証モデルを生成する場合、Ｃコードの部分のBasic Block を認識して制御点を挿入し、各々の制御点間の実行時間をパラメータとする実行時間挿入文を追加して得られるＣベース言語記述の検証モデルをコンパイルして生成されたホストＣＰＵ用バイナリ・コードをホストＣＰＵで実行させるようにしている。このようなソフトウェア検証モデル生成方法では、命令コードの一命令ごとにその命令内容を解釈してシミュレーションを実行する従来のＩＳＳ（Instruction Set Simulator）を利用したシミュレーションの場合に比較して、シミュレーション性能（命令数／秒）が１００〜１０００倍程度向上し、ハードウェア／ソフトウェア協調検証におけるシミュレーションの高速化を図ることができる。

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

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

さらに、他の先行技術文献（特許文献２）の特願平2004−107207号（平成16年３月31日出願）では、Ｃコードの部分のBasic Block に挿入された各々の制御点間の実行時間を算出すると共に、当該実行時間を積算して得られる積算値が指定値以上であると判定された場合にのみ、当該積算値をパラメータとするwaitfor 文をソフトウェア部品に追加するようにしている。このような方法によって、前述の特許文献１の場合に比べてwaitfor 文の追加頻度が節減され、特許文献１の場合よりもシミュレーションの実行速度が速くなってシミュレーション性能が向上する。この場合、当該積算値が指定値以上であると判定された場合に当該積算値をパラメータとするwaitfor 文を追加し、Ｃベース・シミュレータが当該waitfor 文を解釈して命令実行時間の管理を行うことができるので、特許文献１の場合に比べてシミュレーション精度がそれほど低下することはない。

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

特願2003−024706号（平成15年１月31日出願） 特願2004-107207号（平成16年３月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.

一般に、ＡＲＭプロセッサ又はＳＨプロセッサ等のターゲットＣＰＵを用いた組み込みシステムにおいては、主記憶装置(メインメモリ)との命令コードやデータのアクセスを高速化するために、キャッシュメモリをホストＣＰＵ側に設けることが多い。このキャッシュメモリは、通常、ターゲットＣＰＵに内蔵されて使用される。

しかしながら、前述の特許文献１又は特許文献２等に記載されているような従来のハードウェア／ソフトウェア協調検証方法においては、ターゲットＣＰＵにより生成された検証モデルに基づき、ホストＣＰＵを使用してＣベース・シミュレーションを実行した場合の実行時間を算出する際に、キャッシュメモリの動作の統計的処理を行うのみでキャッシュメモリのキャッシュミス等に起因する詳細な動作は考慮していなかった。このため、キャッシュメモリを内蔵したターゲットＣＰＵの実行時間の見積りを行った場合、特にキャッシュメモリのキャッシュミス等が頻繁に発生したときは、実行時間の見積りの精度が低くなってシミュレーション精度が低下するという問題が生じてきた。

本発明は、上記問題点に鑑みてなされたものであり、ターゲットＣＰＵにより生成された検証モデルに基づいてＣベース・シミュレーションを実行した場合の実行時間を算出する際に、キャッシュメモリのキャッシュミス等を考慮することによって従来方法よりもシミュレーション精度を向上させることを可能にするようなソフトウェア検証モデル生成方法を提供することを目的とするものである。

上記目的を達成するために、本発明の第１の態様によれば、命令キャッシュメモリを有するホストＣＰＵを使用して、一つのターゲットＣＰＵ及び一つのＯＳが少なくとも搭載される半導体装置のハードウェア及びソフトウェアの協調検証を実行するために、ソフトウェアの検証モデルを生成する場合に、Ｃベース言語記述のソフトウェア部品を入力してＡＮＳＩ−Ｃ記述によるソースコードの部分を取り出し、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 の各々について、当該Basic Block の制御点間の実行時間を算出するステップと、上記実行時間をパラメータとする実行時間挿入文を当該Basic Block の後の制御点に追加するステップと、当該Basic Block の単位で命令キャッシュメモリがヒットしているか否かの判定を行うための手続き呼び出しを当該Basic Block の後の制御点に挿入するステップと、上記ＡＮＳＩ−Ｃ記述によるソースコードにてデータのアクセスが必要な部分で、データキャッシュメモリがヒットしているか否かの判定を行うための手続きの呼び出しを挿入するステップと、命令キャッシュメモリ及びデータキャッシュメモリの無効化を行うアセンブラコードを、命令キャッシュ無効化手続き及びデータキャッシュメモリ無効化手続きの呼び出しを行うＡＮＳＩ−Ｃ記述によるソースコードに変換するステップとを有するソフトウェア検証モデル生成方法が提供される。

さらに、上記のソフトウェア検証モデル生成方法は、上記命令キャッシュメモリ内に保持されている命令タグメモリ部を用いて当該命令キャッシュメモリがヒットしているか否かの判定を行い、当該命令キャッシュメモリがヒットしていないことが検出されたときに、キャッシュラインフィルを実行するための実行時間を加算する命令キャッシュヒット判定機能を有する手続きを提供するステップと、上記データキャッシュメモリ内に保持されているデータタグメモリ部を用いて当該データキャッシュメモリがヒットしているか否かの判定を行い、当該データキャッシュメモリがヒットしていないことが検出されたときに、キャッシュラインフィルを実行するための実行時間を追加するデータキャッシュヒット判定機能を有する手続きを提供するステップと、上記命令キャッシュ無効化手続き及び上記データキャッシュメモリ無効化手続きが実行されたときに、上記命令タグメモリ部及び上記データタグメモリ部のエントリを無効化するステップと、上記の一連のステップで得られたＣベース言語記述のソフトウェア部品を上記検証モデルとして出力するステップとを有する。

好ましくは、本発明の第３の態様に係るソフトウェア検証モデル生成方法は、命令アドレスを仮想アドレスから物理アドレスに変換するための命令アドレス変換用バッファが上記ターゲットＣＰＵ内に設けられている場合に、上記Basic Block の単位で上記命令アドレスが上記命令アドレス変換用バッファ内に存在するか否かの判定を行い、上記命令アドレスが上記命令アドレス変換用バッファ内に存在しないことが検出されたときに、命令アドレス変換のエントリを上記命令アドレス変換用バッファにロードする時間を加算するステップと、データアドレスを仮想アドレスから物理アドレスに変換するためのデータアドレス変換用バッファが上記ターゲットＣＰＵ内に設けられている場合に、上記ＡＮＳＩ−Ｃ記述によるソースコードにてデータのアクセスが必要な部分で、上記データアドレスが上記データアドレス変換用バッファ内に存在するか否かの判定を行い、上記データアドレスが上記データアドレス変換用バッファ内に存在しないことが検出されたときに、データアドレス変換のエントリを上記データアドレス変換用バッファにロードする時間を加算するステップとをさらに有する。

さらに、好ましくは、本発明の第３の態様に係るソフトウェア検証モデル生成方法は、上記命令アドレスの保護機能の有無をチェックし、上記命令アドレス変換用バッファのアクセス保護に対する違反が検出された場合に、上記命令アドレス変換用バッファのアクセス保護の例外が発生したことを知らせるステップと、上記データアドレスの保護機能の有無をチェックし、上記データアドレス変換用バッファのアクセス保護に対する違反が検出された場合に、上記データアドレス変換用バッファのアクセス保護の例外が発生したことを知らせるステップとをさらに有する。

要約すれば、本発明では、第１に、Ｃベース言語記述のソフトウェア部品のBasic Block に挿入された各々の制御点間の実行時間を算出すると共に、Basic Block の単位で、ターゲットＣＰＵに内蔵の命令キャッシュメモリがヒットしているか否かを判定し、キャッシュミス（命令キャッシュメモリがヒットしていないこと）が検出された場合にキャッシュラインフィルを実行するための実行時間を加算する手続き呼び出しをソースコードに挿入し、上記のような命令キャッシュヒット判定を行う手続きを用意して当該ソースコードと一緒にコンパイルし、ハードウェア及びソフトウェアの協調検証におけるシミュレーションを実行するようにしている。このように、命令キャッシュメモリがターゲットＣＰＵに内蔵されている場合に、命令キャッシュメモリのキャッシュミスの際にキャッシュラインフィルを実行するための実行時間を加算することによって、従来方法よりも実行時間の見積りの精度が高くなり、シミュレーションの精度が向上する。

この場合、命令キャッシュメモリがヒットしているか否かの判定を命令単位ではなく、Basic Block の単位で行うので、シミュレーション全体の動作を制御するＣベース・シミュレータ等における処理負荷を軽減することが可能になる。

さらに、本発明では、第２に、命令アドレス変換用バッファ（例えば、ＴＬＢ（トランスレーション・ルックアサイド・バッファ：Translation Look-aside Buffer ））がターゲットＣＰＵ内に設けられている場合に、命令アドレス変換用バッファのミス（命令アドレスが当該命令アドレス変換用バッファ内に存在しないこと）が検出されたときに、命令アドレス変換のエントリを命令アドレス変換用バッファにロードする時間を加算するようにしている。それゆえに、命令アドレス変換用バッファのミスの際に命令アドレス変換のエントリをロードする時間を含めた高精度のシミュレーションを実行することが可能になる。

さらに、本発明では、第３に、命令アドレス変換用バッファのアクセス保護に対する違反が検出された場合に、命令アドレス変換用バッファのアクセス保護の例外が発生したことをＣベース・シミュレータ等に知らせることによって、シミュレーションの実行時に命令アドレス変換用バッファのアクセス保護に対する違反を確実に検出することが可能になる。

さらに、本発明では、第４に、Ｃベース言語記述のソフトウェア部品のBasic Block に挿入された任意の制御点間の実行時間を算出すると共に、データのアクセスが必要な部分で、ターゲットＣＰＵに内蔵のデータキャッシュメモリがヒットしているか否かを判定し、キャッシュミス（データキャッシュメモリがヒットしていないこと）が検出された場合にキャッシュラインフィルを実行するための実行時間を加算する手続き呼び出しをソースコードに挿入し、上記のようなデータキャッシュヒット判定を行う手続きを用意して当該ソースコードと一緒にコンパイルし、ハードウェア及びソフトウェアの協調検証におけるシミュレーションを実行するようにしている。このように、データキャッシュメモリがターゲットＣＰＵに内蔵されている場合にも、データキャッシュメモリのキャッシュミスの際にキャッシュラインフィルを実行するための実行時間を加算することによって、従来方法よりも実行時間の見積りの精度が高くなり、シミュレーションの精度が向上する。

さらに、本発明では、第５に、データアドレス変換用バッファ（例えば、ＴＬＢ）がターゲットＣＰＵ内に設けられている場合に、データアドレス変換用バッファのミス（データアドレスが当該データアドレス変換用バッファ内に存在しないこと）が検出されたときに、データアドレス変換のエントリをデータアドレス変換用バッファにロードする時間を加算するようにしている。それゆえに、データアドレス変換用バッファのミスの際にデータアドレス変換のエントリをロードする時間を含めた高精度のシミュレーションを実行することが可能になる。

さらに、本発明では、第６に、データアドレス変換用バッファのアクセス保護に対する違反が検出された場合に、データアドレス変換用バッファのアクセス保護の例外が発生したことをＣベース・シミュレータ等に知らせることによって、シミュレーションの実行時にデータアドレス変換用バッファのアクセス保護に対する違反を確実に検出することが可能になる。

さらに、本発明では、第７に、Ｃベース言語記述のソフトウェア部品のBasic Block に挿入された各々の制御点間の実行時間を算出すると共に、Basic Block の単位で、ターゲットＣＰＵに内蔵の命令キャッシュメモリがヒットしているか否かを判定し、キャッシュミスが検出された場合にキャッシュラインフィルを実行するための実行時間を加算する手続き呼び出しをソースコードに挿入し、上記のような命令キャッシュヒット判定を行う手続きを用意して当該ソースコードと一緒にコンパイルし、又一方で、データのアクセスが必要な部分で、ターゲットＣＰＵに内蔵のデータキャッシュメモリがヒットしているか否かを判定し、キャッシュミスが検出された場合にキャッシュラインフィルを実行するための実行時間を加算する手続き呼び出しをソースコードに挿入し、上記のようなデータキャッシュヒット判定を行う手続きを用意して当該ソースコードと一緒にコンパイルし、シミュレーションを実行するようにしている。

上記のように、命令キャッシュメモリ及びデータキャッシュメモリの両方がターゲットＣＰＵに内蔵されている場合にも、命令キャッシュメモリのキャッシュミス、及び、データキャッシュメモリのキャッシュミスの際にキャッシュラインフィルを実行するための実行時間を加算することによって、従来方法よりも実行時間の見積りの精度がさらに高くなり、シミュレーションの精度が顕著に向上する。

さらに、本発明では、第８に、命令アドレス変換用バッファ及びデータアドレス変換用バッファがターゲットＣＰＵ内に設けられている場合に、命令アドレス変換用バッファのミスが検出されたときに、命令アドレス変換のエントリを命令アドレス変換用バッファにロードする時間を加算すると共に、データアドレス変換用バッファのミスが検出されたときに、データアドレス変換のエントリをデータアドレス変換用バッファにロードする時間を加算するようにしている。それゆえに、命令アドレス変換用バッファ及びデータアドレス変換用バッファのミスの際に命令アドレス変換のエントリ及びデータアドレス変換のエントリをロードする時間を含めたより高精度のシミュレーションを実行することが可能になる。

さらに、本発明では、第９に、命令アドレス変換用バッファ及びデータアドレス変換用バッファのアクセス保護に対する違反が検出された場合に、命令アドレス変換用バッファ及びデータアドレス変換用バッファのアクセス保護の例外が発生したことをＣベース・シミュレータ等に知らせることによって、シミュレーションの実行時に命令アドレス変換用バッファ及びデータアドレス変換用バッファのアクセス保護に対する違反をより確実に検出することが可能になる。

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

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

ここでは、本発明に係るソフトウェア検証モデル生成方法を高速にて実行させるために、高性能のホストＣＰＵ９１２が要求される。この要求に応えるために、ホストＣＰＵ９１２と主記憶装置９１４との間にキャッシュメモリ９１６が設けられている。このキャッシュメモリ９１６は、ホストＣＰＵ９１２が主記憶装置９１４に対して頻繁に読み書きするデータを高速にて転送させるために、当該データをホストＣＰＵ９１２からストアして（書き込んで）一時的にため込むか、又は当該データを主記憶装置９１４からロードして（ダウンロードとも呼ばれる）一時的にため込む機能を有している。キャッシュメモリ９１６と主記憶装置９１４とは、バス９１８を介して相互に接続されている。キャッシュメモリ９１６は、図６にて後述するように、命令キャッシュメモリ及びデータキャッシュメモリの少なくとも一方、又は両方を含んでおり、コンピュータ本体９１０に内蔵されている。

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

図６は、ターゲットＣＰＵを用いた組み込みシステムにおける命令キャッシュメモリ及びデータキャッシュメモリの接続例を示すブロック図である。ここでは、命令キャッシュメモリとデータキャッシュメモリを備えた組み込みシステムの展開的な接続例が図示されている。

図６において、キャッシュメモリ１６は、命令（広い意味で「データ」とも呼ばれる）の内容を一時的に格納する命令キャッシュメモリ１６−１、もしくはデータの内容を一時的に格納するデータキャッシュメモリ１６−２、又はその両方を含んでいる。この命令キャッシュメモリ１６−１及びデータキャッシュメモリ１６−２は、好ましくは、ターゲットＣＰＵ１２に内蔵されて使用される。なお、図６に示すような構成では、キャッシュメモリを単に「キャッシュ」と略記したり、命令キャッシュメモリを単に「命令キャッシュ」と略記したり、データキャッシュメモリを単に「データキャッシュ」と略記したりすることもある。

図６のターゲットＣＰＵ１２を用いたハードウェア／ソフトウェア協調検証システムにおいては、バジェット追加ツールによりソフトウェア部品のBasic Block に挿入された各々の制御点間の実行時間を算出する機能が備わっており、かつ、キャッシュメモリ１６（命令キャッシュメモリ１６−１及びデータキャッシュメモリ１６−２）によるエミュレーション機能が追加される。ここで、ターゲットＣＰＵ１２は、キャッシュメモリに対する命令実行において、命令キャッシュメモリ１６−１から命令の内容をフェッチする操作（命令フェッチ操作）を実行したり、データキャッシュメモリ１６−２に対してデータをロードしたりストアしたりするための命令（ロード命令／ストア命令）を実行したりする。

より詳しく説明すると、ターゲットＣＰＵ１２は、命令キャッシュメモリ１６−１がヒットしているか否か（命令キャッシュメモリ内に所望のデータ（命令の内容）が存在するか否か）を判定し、キャッシュミス（命令キャッシュメモリ内に所望のデータが存在しないこと）を検出したときに、主記憶装置１４からデータを読み出し、命令キャッシュメモリ１６−１の命令キャッシュラインへロードする。ここで、命令キャッシュラインは、命令キャッシュメモリ１６−１へのデータのロード単位を表している。既述したように、この命令キャッシュラインへデータをロードする操作をキャッシュラインフィルと称している。この場合、一つの命令キャッシュライン分のデータのキャッシュラインフィルが終了するまで、ターゲットＣＰＵ１２は待ち状態になる。このターゲットＣＰＵ１２の待ち状態に起因する待ち時間は、「キャッシュミスペナルティ」と呼ばれる。

又一方で、ターゲットＣＰＵ１２は、データキャッシュメモリ１６−２がヒットしているか否か（データキャッシュメモリ内に所望のデータが存在するか否か）を判定し、キャッシュミス（データキャッシュメモリ内に所望のデータが存在しないこと）を検出したときに、主記憶装置１４からデータを読み出し、データキャッシュメモリ１６−２のデータキャッシュラインへロードする。ここで、データキャッシュラインは、データキャッシュメモリ１６−２へのデータのロード単位を表している。既述したように、このデータキャッシュラインへデータをロードする操作をキャッシュラインフィルと称している。この場合、一つのデータキャッシュライン分のデータのキャッシュラインフィルが終了するまで、ターゲットＣＰＵ１２は待ち状態になる。このターゲットＣＰＵ１２の待ち状態に起因する待ち時間は、前述の命令キャッシュメモリの場合と同様に、「キャッシュミスペナルティ」と呼ばれる。

図７は、図６の命令キャッシュメモリ１６−１、又は、データキャッシュメモリ１６−２の具体的な構成例を示すブロック図であり、図８は、図７の命令キャッシュメモリ１６−１、又は、データキャッシュメモリ１６−２のキャッシュミスによりキャッシュミスペナルティが発生する様子を説明するためのタイムチャートである。

図７において、命令キャッシュメモリ１６−１、又は、データキャッシュメモリ１６−２は、複数の行の命令キャッシュライン、又は、データキャッシュライン(以下、単にキャッシュラインと呼ぶ）からなるウェイの集合体により構成される。一つの行のキャッシュラインは、当該キャッシュラインの内容が有効であるか否かを示す有効ビット（Valid Bit ）と、最初に主記憶装置から当該キャッシュラインにロードされたデータがＣＰＵにより書き替えられているか否か（ダーティの状態になっているか否か）を示すダーティビット（Dirty Bit ）と、当該キャッシュライン内のデータがどのアドレスに属するデータであるかを示すタグ部（図７では、タグ（Tag ）と略記する）とを有する。通常、上記の有効ビット、ダーティビット、及びタグ部は図示するように複数のウェイからなるタグメモリ１６−３に格納される。ただし、命令キャッシュメモリ１６−１では、一度ロードされたデータがＣＰＵにより書き替えられることはないので、実際にはダーティビットは不要である。又一方で、各々のキャッシュラインに対応させてアドレス（命令キャッシュメモリ１６−１、又は、データキャッシュメモリ１６−２に対応して、それぞれ、命令アドレス、又は、データアドレス）３１が設けられている。このアドレス３１には、対応するキャッシュラインがどのアドレスに属するかを示すタグ（Tag ）と、当該キャッシュラインのインデックス値を示すインデックス（Index ）と、キャッシュラインの先頭アドレスの位置からのオフセット値を示すライン内オフセット（Line内Offset）とが含まれる。

図７に示すキャッシュラインメモリ１６−４は、主記憶からロードしたキャッシュラインの内容を格納するメモリであり、各キャッシュラインはタグメモリ１６−３の有効ビットやタグ部と1対1に対応している。この協調検証環境では、シミュレーション中にキャッシュミスが検出された場合に、キャッシュラインフィルに要する実行時間を求めるだけでよいので、実際には、このキャッシュラインメモリ１６−４のシミュレーションモデルは不要である。

図７のタグメモリ１６−３においては、タグメモリ１６−３の各々のウェイに対してコンパレータ３２が設けられている。このコンパレータ３２は、アドレス内に含まれるタグ３１とタグメモリ１６−３から読み出したタグとを比較し、この特定のアドレスに一致するアドレスがあるか否かを判定する機能を有している。

さらに、図７では、キャッシュライン毎にキャッシュメモリがヒットしているか否かを判定するキャッシュヒット検出部３４が設けられている。このキャッシュヒット検出部３４は、コンパレータ３２による判定結果に基づき、キャッシュラインのアドレスをパラメータとしてキャッシュライン毎にキャッシュメモリ内に所望のデータが存在するか否かを判定する機能を有している。

キャッシュヒット検出部３４において、命令キャッシュメモリ１６−１、又は、データキャッシュメモリ１６−２のキャッシュミス（キャッシュメモリ内に所望のデータが存在しないこと）が検出された場合、キャッシュラインのキャッシュラインフィルを実行するための実行時間（キャッシュミスペナルティの発生によるＣＰＵの待ち時間）を追加するようにしている。なお、図７に示されるように、キャッシュラインのキャッシュラインフィルを実行するための実行時間を「ラインフィル時間」と称する場合もある。

このようなキャッシュミスペナルティが発生したときにキャッシュラインフィルが実行される様子（時間（ｔ）に対するキャッシュラインへのデータの転送の様子）を図８に示す。ＡＲＭプロセッサ等のターゲットＣＰＵにより生成されたソフトウェア検証モデルでは、命令キャッシュメモリ１６−１、または、データキャッシュメモリ１６−３のキャッシュミスが検出された場合に、システム動作の基本となるクロックＣＬＫに同期して実行されるキャッシュラインフィルは、キャッシュラインの先頭アドレスから開始される。命令キャッシュメモリ１６−１のインプリメントによっては、途中でキャッシュミスが検出されたアドレスに対応する命令の内容がロードされる際に、キャッシュラインへのロードとＣＰＵによる命令実行とが平行して行われるものもある。この場合は、見かけ上のキャッシュラインフィルの実行時間は、小さくなる。

したがって、命令キャッシュメモリのキャッシュミスペナルティは、次式のように表される。
Ｔinit ＋ Ｔword ＊Line Size − Ｔexe
ここで、Ｔinitは、キャッシュミスが検出されてから最初の先頭ワードのロードを開始するまでの時間、Ｔwordはワード毎のロード時間、Line Size（ラインサイズ）は一つのキャッシュラインのワード数、Ｔexeは、キャッシュミスが検出された命令キャッシュラインのうち、キャッシュラインフィルの動作中にＣＰＵにより実行された命令時間を示す。例えば、ラインサイズが８ワード（＝３２バイト）であり、１回あたりにロードするワード幅が４バイトである場合、ワード単位の命令（先頭ワード、次ワード……）が次々にキャッシュラインメモリ１６−４にロードされ、合わせて８回ロードされることになる。

換言すれば、本発明の実施形態では、図７に示したように、命令キャッシュメモリの命令タグメモリのエミュレーション機能を用意し、命令アドレスをパラメータとして命令キャッシュメモリがヒットしているか否かの判定を行い、命令キャッシュメモリのキャッシュミスの際にキャッシュラインフィルを実行するための実行時間をキャッシュミスペナルティとして追加するようになっている。

また一方で、本発明の実施形態では、データキャッシュメモリのエミュレーション機能を用意し、データアドレスをパラメータとしてデータキャッシュメモリがヒットしているか否かの判定を行い、データキャッシュメモリのキャッシュミスの際にキャッシュラインフィルを実行するための実行時間をキャッシュミスペナルティとして追加するようになっている。

ここで、データキャッシュメモリのキャッシュミスが発生した場合のキャッシュラインフィルの動作は、ストア・スルー（Store Through ）モード又はストア・バック（Store Back）のいずれかのモードで実行される点に注意すべきである。
ここで、「ストア・スルーモード」とは、データキャッシュメモリ１６−２に対するストア(書き込み)動作を行った際に、データキャッシュメモリ１６−２の内容を更新すると同時に主記憶装置の内容も更新するモードを指している。このストア・スルーモードでは、データキャッシュメモリ１６−２及び主記憶装置１４の内容を更新する度にバス１８を使用するので、主記憶装置１４に対するストア動作が終了するまでターゲットＣＰＵ１２は待ち状態になる。したがって、ストア・スルーモードでは、ストア動作を行う度に主記憶装置１４への書き込みのための実行時間だけターゲットＣＰＵの実行を待たせる必要がある。なお、データキャッシュメモリ１６−２のインプリメントによっては、このようなストア動作の要求を一時的に格納しておくストアバッファを用意しているものもある。このような場合には、ストア動作を行う場合に、まだ、ストアバッファにストア要求が残っているときのみターゲットＣＰＵ１２の実行を待たせる必要がある。この場合、キャッシュラインフィルが実行された場合、主記憶装置１４の更新は既に行われているので、アドレス３１のインデックスで示されるウェイから適当なキャッシュラインを選択し、このキャッシュラインに主記憶装置１４からロードしたラインの内容をロードするだけでよいので、データキャッシュメモリのキャッシュミスペナルティは前述の式のように表される。

これに対し、「ストア・バックモード」とは、データキャッシュメモリ１６−２に対するストア動作を行った際に、データキャッシュメモリ１６−２の内容のみを更新し、主記憶装置の内容は元のままにしておくモードを指している。このストア・バックモードでは、データキャッシュラインに対するストア動作が行われた際にダーティビットを“１”にセットしておく。次いで、データキャッシュミスの発生によって、ダーティビットが“１”になっているデータキャッシュラインが置換される場合、まず、更新されたデータキャッシュラインの内容を主記憶装置に追い出す必要がある。この後、キャッシュミスしたデータキャッシュラインの更新後の内容をロードすることによって、データキャッシュラインの置換を行う（ストア・バックの動作）。このように、データキャッシュラインの置換が必要なストア・バックモードにおいては、ストア・スルーモードでキャッシュラインフィルを実行する場合の実行時間以外に、上記のようなストア・バックの動作を実行するための実行時間が追加される。なお、データキャッシュラインのストア・バック要求を保持するストアバッファをインプリメントしている場合には、追い出すデータキャッシュラインの内容をストアバッファに格納した後、直ちに、キャッシュミスしたデータキャッシュラインの内容を主記憶装置１４からロードすることができる。このような場合は、キャッシュラインフィルを実行する場合の実行時間の追加だけでよい。この場合も、既に、ストアバッファに以前のストア・バック要求が残っている場合は、ストアバッファが空になるまで待たされる。

図９は、本発明に係る命令キャッシュヒット判定機能を有する手続きを実行するプログラムの処理手順を説明するためのフローチャートのその１、図１０は、本発明に係る命令キャッシュヒット判定機能を有する手続きを実行するプログラムの処理手順を説明するためのフローチャートのその２、そして、図１１は、本発明に係る命令キャッシュヒット判定機能を有する手続きの追加によるソフトウェア検証モデル生成方法を説明するための模式図である。

以下、図９〜図１１を参照しながら、命令キャッシュメモリ１６−１がターゲットＣＰＵ１２に内蔵されている場合に、Ｃベース言語記述のソフトウェア部品５０に基づいて本発明に係る命令キャッシュヒット判定機能を有する手続きを実行するプログラムの処理手順を説明する。

まず、図９のステップ１０５では、実行時間追加前のＣベース言語で記述されたソフトウェア部品５０を入力して、このソフトウェア部品の中からＡＮＳＩ−Ｃ記述のみによるソースコードの部分（Ｃコードの部分と呼ばれる）を取り出す。次いで、ステップ１１０では、このＣコードの部分に対して、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 の制御点間の実行時間の算出は、
Σ［各命令のサイクル数］
なる演算式に基づいて行われる。

さらに、ステップ１４５では、制御点が挿入されたＣコードの部分の各々の制御点（すなわち、各々のBasic Block の後の制御点）へ、算出された実行時間をパラメータとする実行時間挿入文（ＳｐｅｃＣの場合は、waitfor 文である）を追加し、Ｃベース言語記述の検証モデル（実行時間挿入文追加後のＣベース・モデル）５６として出力する。

例えば、図１１の（Ｂ）のBasic Block の認識と制御点の挿入との関係に基づいて、図１１の（Ｂ）に示されるノードａ及びノードｂの実行時間がｔ１と算出され、ノードｃ、ノードｄ及びノードｅ の実行時間がｔ２と算出され、ノードｃ及びノードｆ の実行時間がｔ３と算出され、ノードｇの実行時間がｔ４と算出されたとする。この場合には、図１１の（Ｃ）のＣベース言語記述の検証モデルに示されるように、ノードｂとノードｃとの間の制御点には、実行時間挿入文として waitfor(t1) が追加される。同様に、ノードｅとノードｇとの間の制御点には実行時間挿入文として waitfor(t2) が追加され、ノードｆとノードｇとの間の制御点には実行時間挿入文として waitfor(t3) が追加され、ノードｇの後の制御点には実行時間挿入文として waitfor(t4) が追加されることとなる。

さらに、図１０のステップ１５０では、図９のステップ１３０で取り出したBasic Block の単位で命令キャッシュメモリがヒットしているか否かの判定（命令キャッシュヒット判定：命令キャッシュメモリのミス判定）を行うための手続きの呼び出しを挿入する。さらに、図１０のステップ１５５では、命令キャッシュメモリのキャッシュミスが検出されたときに命令キャッシュメモリの無効化を行うアセンブラコードを、命令キャッシュメモリの無効化を行うための命令キャッシュ無効化手続きの呼び出しを行うＡＮＳＩ−Ｃ記述のみによるソースコード（すなわち、Ｃコード）に変換する。

さらに、図１０のステップ１６０では、前述のステップ１５０で挿入された手続きに従って命令キャッシュメモリがヒットしているか否かの判定を行い、命令キャッシュヒット判定機能を有する手続きを付与する。この命令キャッシュヒット判定機能においては、命令キャッシュメモリ内に保持されている命令タグメモリ部を用いて当該命令キャッシュメモリがヒットしているか否かの判定を行った場合、当該命令キャッシュメモリのキャッシュミスが検出されたときに、キャッシュラインフィルを実行するための実行時間をキャッシュミスペナルティとして追加するようになっている。

さらに、図１０のステップ１６５では、前述のステップ１５５で呼び出された命令キャッシュ無効化手続きが実行されたときに、命令キャッシュメモリ内に保持されている命令タグメモリ部のエントリを無効化するのに要する実行時間だけＣＰＵを待ち状態にして、当該命令キャッシュメモリの有効ビットの内容をクリアする。

前述の一連のステップ１０５〜１６５によって、Ｃベース言語記述のソフトウェア部品に対して各々のBasic Block の後の制御点に実行時間挿入文が追加されると共に、Basic Block の単位で命令キャッシュヒット判定を行ってキャッシュミスが検出されたときにキャッシュミスペナルティが追加されることになる。最終的に、上記の一連のステップで得られたＣベース言語記述のソフトウェア部品が、前述のＣベース言語記述の検証モデル５６として出力される。

例えば、図１１の（Ｃ）のＣベース言語記述の検証モデルに示されるように、Ｃコードの部分をターゲットＣＰＵの命令にコンパイルし、Basic Block の先頭アドレスＡｉ（ｉは任意の正の整数：ここでは、ｉ＝１〜４）と基本ブロック長Ｌｉとを算出し、各々のBasic Block の後の制御点に既に挿入されている実行時間挿入文（waitfor(t1)〜waitfor(t4)）の直後に、命令フェッチに対する命令キャッシュヒット判定を行うための命令キャッシュヒット判定呼び出し文（fetch_icache (Ai, Li) ：ここでは、ｉ＝１〜４）を挿入する。ここでは、命令キャッシュヒット判定を行った結果としてキャッシュミス（命令アドレスに対応する命令の内容が命令キャッシュメモリ内に存在しないこと）を検出した場合には、キャッシュラインフィルの実行時間（ラインフィル時間）をパラメータとする実行時間挿入文（waitfor 文）の呼び出しが行われる。

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

図１２の左側の部分においては、Ｃベース言語記述のソフトウェア部品のBasic Block の制御点に実行時間挿入文（waitfor(t1)〜waitfor(t4)）を挿入すると共に命令キャッシュヒット判定呼び出し文（fetch_icache (Ai, Li) ：ここでは、ｉ＝１〜４）を挿入することによってＣベース言語記述の検証モデルを作成するようにしている。

又一方で、図１２の右側の部分においては、Basic Block の制御点に挿入された実行時間挿入文に基づいて、各々の制御点間の実行時間を算出すると共に、Basic Block の単位で挿入された命令キャッシュヒット判定呼び出し文に基づいて、命令キャッシュメモリのキャッシュミスを検出したときにキャッシュラインフィルを実行するための実行時間（ラインフィル時間）を加算するようにしている。

換言すれば、命令キャッシュメモリがターゲットＣＰＵに内蔵されている場合、図１１及び図１２に示したような実行時間挿入文（waitfor(t1)〜waitfor(t4)）及び命令キャッシュヒット判定呼び出し文（fetch_icache (Ai, Li) ）に基づいてソフトウェア部品の検証モデルを生成する際に、Ｃコードの部分におけるBasic Block の各々の制御点間の実行時間をパラメータとする実行時間挿入文を追加すると共に、Basic Block の単位で命令キャッシュヒット判定呼び出し文を追加して得られるＣベース言語記述の検証モデルをコンパイルする。このコンパイルにより生成されたホストＣＰＵ用バイナリ・コードをホストＣＰＵで実行させることによって、Ｃベース・シミュレータを使用したＣベース・シミュレーションを実行することが可能になる。

図１２のＣベース・シミュレータを使用し、Basic Block の制御点に挿入された実行時間挿入文及び命令キャッシュヒット判定呼び出し文に基づいてシミュレーションを実行した場合、シミュレーションによる命令実行時間の見積りの精度が従来方法よりも高くなり、命令実行時間の時間管理をより正確に行うことができる。

より詳しく説明すると、図１２の命令キャッシュヒット判定呼び出し文（fetch_icache (Ai, Li) ：ここでは、ｉ＝１〜４）においては、アドレスＡｉ〜Ａｉ＋Ｌｉ−１までの範囲の命令アドレスに対応する命令の内容が命令キャッシュメモリ内に存在するか否かの判定を行い、キャッシュミス（当該命令アドレスに対応する命令の内容が命令キャッシュメモリ内に存在しないこと）を検出した場合には、キャッシュミスが発生した回数だけキャッシュラインフィルの実行時間（ラインフィル時間）のサイクル数を挿入するようになっている。ここでは、ラインフィル時間をパラメータとする実行時間挿入文（waitfor 文）の呼び出しが行われる。

又一方で、シミュレーションの過程において、ノードa及びノードｂに相当する命令コードの実行後に、waitfor(t1) の命令コードを解釈することで実行時間ｔ１が求められ、シミュレーションの時刻を時間ｔ１だけ進めることができる。さらに、fetch_icache (A1, L1) を解釈することで、アドレスＡ１〜Ａ１＋Ｌ１−１までの範囲で命令キャッシュメモリのキャッシュミスを検出した場合に、キャッシュミスが発生した回数だけキャッシュラインフィルの実行時間（ラインフィル時間）を挿入することができる。

同様に、ノードcからノードｅに相当する命令コードの実行後に、waitfor(t2) の命令コードを解釈することで実行時間ｔ２が求められ、シミュレーションの時刻を時間ｔ２だけ進めることができる。さらに、fetch_icache (A2, L2) を解釈することで、アドレスＡ２〜Ａ２＋Ｌ２−１までの範囲で命令キャッシュメモリのキャッシュミスを検出した場合に、キャッシュミスが発生した回数だけラインフィル時間を挿入することができる。

同様に、ノードcとノードｆに相当する命令コードの実行後に、waitfor(t3) の命令コードを解釈することで実行時間ｔ３が求められ、シミュレーションの時刻を時間ｔ３だけ進めることができる。さらに、fetch_icache (A3, L3) を解釈することで、アドレスＡ３〜Ａ３＋Ｌ３−１までの範囲で命令キャッシュメモリのキャッシュミスを検出した場合に、キャッシュミスが発生した回数だけラインフィル時間を挿入することができる。

同様に、ノードｇに相当する命令コードの実行後に、waitfor(t4) の命令コードを解釈することで実行時間ｔ４が求められ、シミュレーションの時刻を時間ｔ４だけ進めることができる。さらに、fetch_icache (A4, L4) を解釈することで、アドレスＡ４〜Ａ４＋Ｌ４−１までの範囲で命令キャッシュメモリのキャッシュミスを検出した場合に、キャッシュミスが発生した回数だけラインフィル時間を挿入することができる。

一般的にいって、命令キャッシュヒット判定呼び出し文（fetch_icache (Ai, Li) ）により命令キャッシュヒット判定を行った際に命令キャッシュメモリのキャッシュミスが検出される確率は、数％にすぎない。この命令キャッシュメモリのキャッシュミスが検出された場合のみ、キャッシュラインフィルの実行時間（ラインフィル時間）をパラメータとする実行時間挿入文（waitfor 文）の呼び出しが行われる。それゆえに、Basic Block の単位で命令キャッシュヒット判定呼び出し文（fetch_icache (Ai, Li) ）を追加挿入した場合でも、従来方法とほぼ同等のシミュレーションの実行速度を維持することが可能になる。

好ましくは、命令キャッシュメモリの命令アドレスを仮想アドレスから物理アドレスに変換するための命令アドレス変換用バッファ（例えば、ＴＬＢ（トランスレーション・ルックアサイド・バッファ））がターゲットＣＰＵ内に設けられている場合に、命令キャッシュヒット判定呼び出し文（fetch_icache (Ai, Li)）において、メモリ管理ユニット機能が追加される。

このメモリ管理ユニット機能においては、Basic Block の単位で命令アドレスが命令アドレス変換用バッファ内に存在するか否かの判定を行い、当該命令アドレスが命令アドレス変換用バッファ内に存在しないことが検出されたときに、命令アドレス変換のエントリを命令アドレス変換用バッファにロードする時間を加算するようにしている。このようなメモリ管理ユニット機能によって、命令アドレス変換用バッファのミスの際に命令アドレス変換のエントリをロードする時間を含めた高精度のシミュレーションを実行することが可能になる。

さらに詳しく説明すると、上記のメモリ管理ユニット機能の追加を可能にするために、命令アドレス変換用バッファの内容を保持したＴＬＢを予め用意すると共に、仮想メモリのマッピング情報の内容を保持したページテーブルを主記憶装置内に予め用意しておく。

上記の命令キャッシュヒット判定呼び出し文（fetch_icache (Ai, Li)）に基づいて、アドレスＡｉ〜Ａｉ＋Ｌｉ−１までの範囲の命令アドレスに対応する命令の内容が命令アドレス変換用バッファ内に存在するか否かの判定を行う。この判定結果として、命令アドレス変換用バッファのキャッシュミス（当該命令アドレスに対応する命令の内容が命令アドレス変換用バッファ内に存在しないこと）を検出した場合には、命令アドレス変換用バッファのエントリの内容を主記憶装置内のページテーブルからロードした値に更新し、命令アドレス変換用バッファのロードのためのサイクル数を挿入するようになっている。ここでは、命令アドレス変換用バッファにロードする時間をパラメータとする実行時間挿入文（waitfor 文）の呼び出しが行われる。

さらに、好ましくは、上記のメモリ管理ユニット機能を実行する際に、命令アドレスの保護機能の有無のチェックが行われる。ここで、命令アドレス変換用バッファにおいてアクセス保護に対する違反が検出された場合には、アクセス保護の例外が発生したことを知らせるようにしている。これによって、シミュレーションの実行時に命令アドレス変換用バッファにおけるアクセス保護に対する違反を確実に検出することが可能になる。

図１３は、本発明に係る命令キャッシュヒット判定に関する手続き呼び出しをＣソースコードに挿入した例を示す図である。ただし、図１３の例は、図１１及び図１２にて説明したようなＣコードの部分の例とは異なっている。

図１３の左上の部分においては、ＡＮＳＩ−Ｃ記述によるＣソースコードの部分が例示されている。このＣソースコードの部分を解析して、特許文献１又は特許文献２に示すように、バジェット追加ツールによって、各々のBasic Block の後の制御点に実行時間挿入文（例えば、図１３の左下の部分に示されるようなwaitfor(2)、 waitfor(4)、及びwaitfor(5) 等のwaitfor 文）を挿入する。つまり、図１３の左上のＣソースコード部分を、同図の右側に示されるようなターゲットＣＰＵのアセンブリ言語記述によるアセンブラ出力に展開するように、クロスコンパイルしている。このアセンブラ出力における分岐先や分岐命令の出現個所を解析することによって、Basic Block（例えば、図１３の右側で複数のブロック（各々のブロックが８バイト〜２０バイトの容量を有する）により囲まれている部分）を認識することができる。このアセンブラ出力の基本ブロックとCのソースコードの照合を行い、Cのソースコードの各Basic Blockの終わりである制御点に実行時間挿入文(waitfor文)を挿入して、Cのソースコードを生成する。

本特許では、この制御点に、実行時間挿入文(waitfor文)と共に、命令キャッシュヒット判定手続きの呼び出し文（fetch_icache呼び出し文）を追加挿入するものである。

つまり、図１３の右側のアセンブラ出力を解析してＣソースコードとの間の照合を行い、Ｃソースコードの各々のBasic Block の後の制御点に、実行時間挿入文(waitfor文)と命令キャッシュヒット判定手続きの呼び出し文（fetch_icache呼び出し文）を追加挿入した後に、図１３の左下の部分に示されるような更新後のＣ言語記述によるＣソースコードの部分（すなわち、Ｃコードの部分）に変換する。この更新後のＣコードの部分は、バジェット追加ツールによって、各々のBasic Block の後の制御点にて命令キャッシュヒット判定呼び出し文（fetch_icache呼び出し文）が追加挿入された形式になっている。より正確にいえば、図１３の左下の部分では、更新後のＣコードの部分をコンパイルすることによって最終的に出力されるＣベース言語記述の検証モデルが図示されている。

より詳しく説明すると、図１３のＣベース言語記述の検証モデルにおいては、各々のBasic Block の後の制御点に挿入されている実行時間挿入文（waitfor(2)、 waitfor(4)、及びwaitfor(5)）の直後に、命令フェッチに対する命令キャッシュヒット判定を行うための命令キャッシュヒット判定呼び出し文（fetch_icache (stringcpy, 8) 、fetch_icache (stringcpy+8, 20)、 fetch_icache (stringcpy+28, 16) 、fetch_icache (stringcpy+44, 8)、 及びfetch_icache (stringcpy+52, 8)）を挿入する。ここで、fetch_icache呼び出しの２つのパラメタは、Basic Bclockの先頭アドレスとその長さ(バイト数)である。各々の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 の制御点間の実行時間を算出する。又一方で、取り出すBasic Block がないと判定された場合は、前述のステップ２０５〜２３５で得られたＣベース言語記述のソフトウェア部品を検証モデル６６として出力し、本プログラムの処理を終了する。

前述のステップ２４０におけるBasic Block の制御点間の実行時間の算出は、
Σ［各命令のサイクル数］
なる演算式に基づいて行われる。

さらに、ステップ２４５では、制御点が挿入されたＣコードの部分の任意の制御点（すなわち、Basic Block の後の任意の制御点）へ、算出された実行時間をパラメータとする実行時間挿入文（ＳｐｅｃＣの場合は、waitfor 文である）を追加し、Ｃベース言語記述の検証モデル（実行時間挿入文追加後のＣベース・モデル）６６として出力する。

この際、図１５のステップ２５０では、前述のコンパイルの結果として生成されたターゲットＣＰＵ用アセンブリコードを解析してデータアクセス命令（ロード命令及びストア命令）を検出し、このロード命令及びストア命令を生成する部分に対応するＣソースコードを認識し、生成されたロード命令及びストア命令に対応するＣコードの部位（すなわち、Ｃコードのデータアクセスが必要な部分）で、データキャッシュメモリがヒットしているか否かの判定（データキャッシュヒット判定：データキャッシュメモリのミス判定）を行うための手続きの呼び出しを挿入する。この際、図１６の（Ｂ）に示すように、ロード命令が生成されるＣソースコード部分には、同図（Ｂ）に示すように、load_dcacheのデータキャッシュヒット判定手続きが挿入され、ストア命令が生成されるＣソースコード部分には、store_dcacheのデータキャッシュヒット判定手続きが挿入される。さらに、図１５のステップ２５５では、データキャッシュメモリのキャッシュミスが検出されたときにデータキャッシュメモリの無効化を行うアセンブラコードを、データキャッシュメモリの無効化を行うためのデータキャッシュ無効化手続きの呼び出しを行うＡＮＳＩ−Ｃ記述のみによるソースコード（すなわち、Ｃコード）に変換する。

さらに、図１５のステップ２６０では、前述のステップ２５０で挿入された手続きに従ってデータキャッシュメモリがヒットしているか否かの判定を行い、ロード命令及びストア命令に対するデータキャッシュヒット判定機能を有する手続きを付与する。このデータキャッシュヒット判定機能においては、データキャッシュメモリ内に保持されているデータタグメモリ部を用いて当該データキャッシュメモリがヒットしているか否かの判定を行った場合、当該データキャッシュメモリのキャッシュミスが検出されたときに、キャッシュラインフィルを実行するための実行時間をキャッシュミスペナルティとして追加するようになっている。

さらに、図１４のステップ２６５では、前述のステップ２５０で呼び出されたデータキャッシュ無効化手続きが実行されたときに、データキャッシュメモリ内に保持されているデータタグメモリ部のエントリを無効化するのに要する実行時間だけＣＰＵを待ち状態にして、当該データキャッシュメモリの有効ビットの内容をクリアする。

前述の一連のステップ２０５〜２６５によって、Ｃベース言語記述のソフトウェア部品に対して、クロスコンパイルによって生成されたロード命令及びストア命令に対応するＣコードの部位でデータキャッシュヒット判定を行ってキャッシュミスが検出されたときにキャッシュミスペナルティが追加されることになる。最終的に、上記の一連のステップで得られたＣベース言語記述のソフトウェア部品が、前述のＣベース言語記述の検証モデル６６として出力される。

例えば、図１６の（Ｃ）のＣベース言語記述の検証モデルに示されるように、Ｃコードの部分をクロスコンパイルし、ロード命令又はストア命令のデータアドレスオペランドＡｉ（ｉは任意の正の整数）とデータ長（バイト数）Ｌｉとを求める。データアドレスオペランドＡｉは、ロード命令やストア命令でロード、又はストアされるＣソースコード内のデータの変数名やスタックのアドレスである。データ長Ｌｉは、ロード命令又はストア命令を行う際のオペランド長である。例えば、ＡＲＭ ＣＰＵアセンブリコードの場合、オペランド長は、ロード命令のニモニックがＬＤＲＢであれば１バイト長であり、ＬＤＲＨであれば２バイト長であり、ＬＤＲＷであれば４バイト長であり、ストア命令のニモニックがＳＴＲＢであれば１バイト長であり、ＳＴＲＨであれば２バイト長であり、ＳＴＲＷであれば４バイト長である。図１６（Ａ）で示す例の場合、ロード命令でロードされる変数名は“ｐ”であり、ストア命令命令でストアされるデータの変数名は“ｑ”である。また、この場合、これらの変数の指すデータ長は４バイトであると仮定している(つまり、図示していないが、ＡＲＭ ＣＰＵのアセンブラ命令の場合はＬＤＲＷやＳＴＲＷ命令が生成されるものとする)。これによって、ロード命令に対するデータキャッシュヒット判定を行うためのデータキャッシュヒット判定呼び出し文（load_dcache (p, 4)）と、ストア命令に対するデータキャッシュヒット判定を行うためのデータキャッシュヒット判定呼び出し文（store_dcache (q, 4)）とが挿入される。ここで、ロード命令及びストア命令に対するデータキャッシュヒット判定を行った結果としてキャッシュミス（データアドレスに対応するデータの内容がデータキャッシュメモリ内に存在しないこと）を検出した場合には、キャッシュラインフィルの実行時間（ラインフィル時間）をパラメータとする実行時間挿入文（waitfor 文）の呼び出しが行われる。

より詳しく説明すると、図１６のロード命令に対するデータキャッシュヒット判定呼び出し文（load_dcache (Ai, Li)）においては、アドレスＡｉ〜Ａｉ＋Ｌｉ−１までの範囲のデータアドレスに対応するデータの内容がデータキャッシュメモリ内に存在するか否かの判定を行い、キャッシュミス（当該データアドレスに対応するデータの内容がデータキャッシュメモリ内に存在しないこと）を検出した場合には、キャッシュミスが発生した回数だけキャッシュラインフィルの実行時間（ラインフィル時間）のサイクル数を挿入するようになっている。ここで、データキャッシュラインの置換が必要なストア・バックモードにおいては、ストア・バックの動作を実行するための実行時間のサイクル数も挿入するようになっている。

又一方で、図１６のストア命令に対するデータキャッシュヒット判定呼び出し文（store_dcache (Ai, Li)）においても、前述のロード命令に対するデータキャッシュヒット判定呼び出し文（load_dcache (Ai, Li)）の場合と同様に、アドレスＡｉ〜Ａｉ＋Ｌｉ−１までの範囲のデータアドレスに対応するデータの内容がデータキャッシュメモリ内に存在するか否かの判定を行い、キャッシュミスを検出した場合には、キャッシュミスが発生した回数だけキャッシュラインフィルの実行時間のサイクル数を挿入するようになっている。

ただし、上記のストア命令に対するデータキャッシュヒット判定呼び出し文（store_dcache (Ai, Li)）は、ストア・スルーモードにも対応可能なように、ロード命令に対するデータキャッシュヒット判定呼び出し文（load_dcache (Ai, Li)）と区別している。

ストア・スルーモードの場合は、データキャッシュラインの置換は行わないが、ストア命令を実行する度にストアバッファフル（ストアバッファ内のメモリがフル（full）になっている状態）になっているか否かのチェックを行うようになっている。このストアバッファフルになっているか否かのチェックは、ストアバッファに所望のデータの値をセットした時刻と現在の時刻との比較を行うことによって実行される。又一方で、ストア・バックモードの場合は、必要に応じてキャッシュラインフィルの動作を実行し、データキャッシュラインのダーティビットをセットする（例えば、ダーティビットを“１”にする）。ＡＲＭプロセッサ等のターゲットＣＰＵにより生成されたＣベース言語記述の検証モデルでは、キャッシュミスが検出された場合に、キャッシュラインフィルが完了するまでは、ＣＰＵは待ち状態になる。

換言すれば、データキャッシュメモリがターゲットＣＰＵに内蔵されている場合、図１４〜図１６にて説明したようなロード命令及びストア命令に対するデータキャッシュヒット判定呼び出し文に基づいてソフトウェア部品の検証モデルを生成する際に、ロード命令に対応するＣコードの部位にデータキャッシュヒット判定呼び出し文（load_dcache (Ai, Li) ）を挿入し、かつ、ストア命令に対応するＣコードの部位にデータキャッシュヒット判定呼び出し文（store_dcache (Ai, Li) ）を挿入して得られるＣベース言語記述の検証モデルをコンパイルする。このコンパイルにより生成されたホストＣＰＵ用バイナリ・コードをホストＣＰＵで実行させることによって、Ｃベース・シミュレータを使用したＣベース・シミュレーションを実行することが可能になる。

このＣベース・シミュレータを使用し、ロード命令及びストア命令に対応するＣコードの部位にそれぞれ挿入されたデータキャッシュヒット判定呼び出し文（load_dcache (Ai, Li)）及びデータキャッシュヒット判定呼び出し文（store_dcache (Ai, Li) ）に基づいてシミュレーションを実行した場合、データキャッシュメモリのキャッシュミスの際にキャッシュラインフィルを実行するための実行時間を加算しているので、シミュレーションによる実行時間の見積りの精度が従来方法よりも高くなり、実行時間の時間管理をより正確に行うことができる。

好ましくは、データキャッシュメモリのデータアドレスを仮想アドレスから物理アドレスに変換するためのデータアドレス変換用バッファ（例えば、ＴＬＢ（トランスレーション・ルックアサイド・バッファ））がターゲットＣＰＵ内に設けられている場合に、ロード命令に対するデータキャッシュヒット判定呼び出し文（load_dcache (Ai, Li) ）、及び、ストア命令に対するデータキャッシュヒット判定呼び出し文（store_dcache (Ai, Li) ）において、メモリ管理ユニット機能が追加される。

このメモリ管理ユニット機能においては、生成されたロード命令及びストア命令に対応するＣコードの部位で、データアドレスがデータアドレス変換用バッファ内に存在するか否かの判定を行い、データアドレスがデータアドレス変換用バッファ内に存在しないことが検出されたときに、データアドレス変換のエントリをデータアドレス変換用バッファにロードする時間を加算するようにしている。それゆえに、データアドレス変換用バッファのミスの際にデータアドレス変換のエントリをロードする時間を含めた高精度のシミュレーションを実行することが可能になる。

さらに詳しく説明すると、上記のメモリ管理ユニット機能の追加を可能にするために、データアドレス変換用バッファの内容を保持したキャッシュメモリを予め用意すると共に、仮想メモリのマッピング情報の内容を保持したページテーブルを主記憶装置内に予め用意しておく。

上記のロード命令に対するデータキャッシュヒット判定呼び出し文（load_dcache (Ai, Li)）に基づいて、アドレスＡｉ〜Ａｉ＋Ｌｉ−１までの範囲のデータアドレスがデータアドレス変換用バッファ内に存在するか否かの判定を行う。この判定結果として、データアドレス変換用バッファのキャッシュミス（当該データアドレスに対応するデータの内容がデータアドレス変換用バッファ内に存在しないこと）を検出した場合には、データアドレス変換用バッファのエントリの内容を主記憶装置内のページテーブルからロードした値に更新し、データアドレス変換用バッファのロードのためのサイクル数を挿入するようになっている。ここでは、データアドレス変換用バッファにロードする時間をパラメータとする実行時間挿入文（waitfor 文）の呼び出しが行われる。

同様にして、ストア命令に対するデータキャッシュヒット判定呼び出し文（store_dcache (Ai, Li) ）に基づいて、アドレスＡｉ〜Ａｉ＋Ｌｉ−１までの範囲のデータアドレスがデータアドレス変換用バッファ内に存在するか否かの判定を行う。この判定結果として、データアドレス変換用バッファのキャッシュミスを検出した場合には、データアドレス変換用バッファのエントリの内容を主記憶装置内のページテーブルからロードした値に更新し、データアドレス変換用バッファのロードのためのサイクル数を挿入するようになっている。この場合も、データアドレス変換用バッファにロードする時間をパラメータとする実行時間挿入文（waitfor 文）の呼び出しが行われる。

さらに、好ましくは、上記のメモリ管理ユニット機能を実行する際に、データアドレスの保護機能の有無のチェックが行われる。ここで、データアドレス変換のアクセス保護に対する違反が検出された場合には、アクセス保護の例外が発生したことを知らせるようにしている。これによって、シミュレーションの実行時にデータアドレス変換のアクセス保護に対する違反を確実に検出することが可能になる。

図１７は、本発明に係るデータキャッシュヒット判定に関するプログラムをＣソースコードに挿入した例を示す図である。ただし、図１７の例は、図１６にて説明したようなＣコードの部分の例とは異なっている。

図１７の左上の部分においては、ＡＮＳＩ−Ｃ記述によるＣソースコードの部分が例示されている。ロード命令やストア命令の生成は、一般に、クロスコンパイラの最適化オプションに依存する。例えば、最適化オプションなしでクロスコンパイルすると、Ｃソースコードに現れる局所変数も、スタック領域に割り当てられ、局所変数にアクセスする度にロード命令やストア命令が生成される。従って、このＣソースコードの部分を見た限りでは、ロード命令及びストア命令を生成する部分に対応するＣソースコードの部分（例えば、図１３の左上で複数のブロックにより囲まれている部分）を認識することは困難であり、ロード命令に対するデータキャッシュヒット判定呼び出し文（load_dcache (Ai, Li)）、及び、ストア命令に対するデータキャッシュヒット判定呼び出し文（store_dcache (Ai, Li) ）を挿入すべき箇所を特定することは困難である。

それゆえに、図１７の左上のＣソースコードの部分をクロスコンパイルして、同図の右側に示されるようなアセンブリ言語記述によるアセンブラ出力に展開するようにしている。このアセンブラ出力を解析することによって、生成されたロード命令及びストア命令に対応する箇所（例えば、図１７の右側で複数のブロックにより囲まれている部分）を認識することができる。このようにして、ロード命令に対するデータキャッシュヒット判定呼び出し文（load_dcache (Ai, Li)）、及び、ストア命令に対するデータキャッシュヒット判定呼び出し文（store_dcache (Ai, Li) ）を挿入すべき箇所を特定することが容易に可能になる。

さらに、図１７の右側のアセンブラ出力において、生成されたロード命令に対応する箇所に、ロード命令に対するデータキャッシュヒット判定呼び出し文（load_dcache (Ai, Li)）を挿入し、かつ、生成されたストア命令に対応する箇所に、ストア命令に対するデータキャッシュヒット判定呼び出し文（store_dcache (Ai, Li) ）を挿入する。その後、図１７の左下の部分に示されるような更新後のＣ言語記述によるＣソースコードの部分（すなわち、Ｃコードの部分）に変換する。この更新後のＣコードの部分は、バジェット追加ツールによって、ロード命令に対するデータキャッシュヒット判定呼び出し文（load_dcache (Ai, Li)）、及び、ストア命令に対するデータキャッシュヒット判定呼び出し文（store_dcache (Ai, Li) ）が挿入された形式になっている。より正確にいえば、図１７の左下の部分では、更新後のＣコードの部分をコンパイルすることによって最終的に出力されるＣベース言語記述の検証モデルが図示されている。

より詳しく説明すると、図１７のＣベース言語記述の検証モデルにおいては、生成されたロード命令（＊ｑ＋＋）に対応するＣコードの部位に、ロード命令に対するデータキャッシュヒット判定呼び出し文（load_dcache (q, 1)）を挿入すると共に、生成されたストア命令（＊ｐ＋＋、＊ｐ）に対応するＣコードの部位に、ストア命令に対するデータキャッシュヒット判定呼び出し文（store_dcache (q, 1) ）を挿入する。ここでは、各々のロード命令及びストア命令に対するキャッシュヒット判定を行った結果としてキャッシュミスを検出した場合には、このキャッシュミスが検出された部分に対応するＣコードの部位に、キャッシュラインフィルの実行時間（ラインフィル時間）をパラメータとする実行時間挿入文の呼び出しが行われる。

次いで、命令キャッシュメモリ及びデータキャッシュメモリの両方がターゲットＣＰＵに内蔵されている場合に、本発明に係る命令キャッシュヒット判定機能及びデータキャッシュヒット判定機能を有する手続きを実行するプログラムの処理手順を説明する。

この場合には、前述の図９及び図１０のフローチャートと図１４及び図１５のフローチャートとを組み合わせたフローチャートに従って、本発明に係る命令キャッシュヒット判定機能及びデータキャッシュヒット判定機能を有するＣベース言語記述の検証モデルが生成される。

より詳しく説明すると、本発明に係る命令キャッシュヒット判定機能及びデータキャッシュヒット判定機能を有するＣベース言語記述の検証モデルは、下記のようなステップ（１）〜ステップ（１１）により生成される。
（１）Ｃベース言語記述のソフトウェア部品を入力してＡＮＳＩ−Ｃ記述によるソースコードの部分を取り出し、Basic Block を認識し、制御点を挿入するステップ
（２）当該制御点が挿入されたＡＮＳＩ−Ｃ記述によるソースコードの部分をコンパイルしてターゲットＣＰＵ用バイナリ・コードを生成するステップ
（３）Basic Block の各々について、当該Basic Block の制御点間の実行時間を算出するステップ
（４）上記実行時間をパラメータとする実行時間挿入文を当該Basic Block の後の制御点に追加するステップ
（５）当該Basic Block の単位で命令キャッシュメモリがヒットしているか否かの判定を行うための手続き呼び出しを挿入するステップ
（６）ＡＮＳＩ−Ｃ記述によるソースコードにてロード命令及びストア命令に対応する部分（データのアクセスが必要な部分）で、データキャッシュメモリがヒットしているか否かの判定を行うための手続きの呼び出しを挿入するステップ

（７）命令キャッシュメモリ及びデータキャッシュメモリの無効化を行うアセンブラコードを、命令キャッシュ無効化手続き及びデータキャッシュメモリ無効化手続きの呼び出しを行うＡＮＳＩ−Ｃ記述によるソースコードに変換するステップ
（８）上記命令キャッシュメモリ内に保持されている命令タグメモリ部を用いて当該命令キャッシュメモリがヒットしているか否かの判定を行い、当該命令キャッシュメモリがヒットしていないことが検出されたときに、キャッシュラインフィルを実行するための実行時間を加算する命令キャッシュヒット判定機能を有する手続きを提供するステップ
（９）上記データキャッシュメモリ内に保持されているデータタグメモリ部を用いて当該データキャッシュメモリがヒットしているか否かの判定を行い、当該データキャッシュメモリがヒットしていないことが検出されたときに、キャッシュラインフィルを実行するための実行時間を追加するデータキャッシュヒット判定機能を有する手続きを提供するステップ
（１０）上記命令キャッシュ無効化手続き及び上記データキャッシュメモリ無効化手続きが実行されたときに、上記命令タグメモリ部及び上記データタグメモリ部のエントリを無効化するステップ
（１１）上記の一連のステップで得られたＣベース言語記述のソフトウェア部品を上記検証モデルとして出力するステップ

上記のような命令キャッシュヒット判定機能及びデータキャッシュヒット判定機能を有するＣベース言語記述の検証モデルでは、Basic Block に挿入された各々の制御点間の実行時間を算出すると共に、Basic Block の単位で、ターゲットＣＰＵに内蔵の命令キャッシュメモリがヒットしているか否かを判定し、キャッシュミスが検出された場合にキャッシュラインフィルを実行するための実行時間を加算する手続き呼び出しをソースコードに挿入し、命令キャッシュヒット判定を行う手続きを用意して当該ソースコードと一緒にコンパイルし、又一方で、データのアクセスが必要な部分で、ターゲットＣＰＵに内蔵のデータキャッシュメモリがヒットしているか否かを判定し、キャッシュミスが検出された場合にキャッシュラインフィルを実行するための実行時間を加算する手続き呼び出しをソースコードに挿入し、データキャッシュヒット判定を行う手続きを用意して当該ソースコードと一緒にコンパイルし、シミュレーションを実行するようにしている。

上記のように、命令キャッシュメモリ及びデータキャッシュメモリの両方がターゲットＣＰＵに内蔵されている場合にも、命令キャッシュメモリのキャッシュミス、及び、データキャッシュメモリのキャッシュミスの際にキャッシュラインフィルを実行するための実行時間を加算することによって、従来方法よりも実行時間の見積りの精度がさらに高くなり、シミュレーションの精度が顕著に向上する。

なお、当然のことではあるが、命令アドレスを仮想アドレスから物理アドレスに変換するための命令アドレス変換用バッファ（例えば、ＴＬＢ）がターゲットＣＰＵ内に設けられ、かつ、データアドレスを仮想アドレスから物理アドレスに変換するためのデータアドレス変換用バッファ（例えば、ＴＬＢ）がターゲットＣＰＵ内に設けられている場合にも、命令キャッシュヒット判定呼び出し文（fetch_icache (Ai, Li)）、ロード命令に対するデータキャッシュヒット判定呼び出し文（load_dcache (Ai, Li) ）、及び、ストア命令に対するデータキャッシュヒット判定呼び出し文（store_dcache (Ai, Li)）において、前述のようなメモリ管理ユニット機能が追加される。

このメモリ管理ユニット機能においては、Basic Block の単位で命令アドレスが命令アドレス変換用バッファ内に存在するか否かの判定を行い、当該命令アドレスが命令アドレス変換用バッファ内に存在しないことが検出されたときに、命令アドレス変換のエントリを命令アドレス変換用バッファにロードする時間を加算し、又一方で、生成されたロード命令及びストア命令に対応するＣコードの部位で、データアドレスがデータアドレス変換用バッファ内に存在するか否かの判定を行い、データアドレスがデータアドレス変換用バッファ内に存在しないことが検出されたときに、データアドレス変換のエントリをデータアドレス変換用バッファにロードする時間を加算するようにしている。それゆえに、命令アドレス変換用バッファ及びデータアドレス変換用バッファのミスの際に命令アドレス変換のエントリ及びデータアドレス変換のエントリをロードする時間を含めたより高精度のシミュレーションを実行することが可能になる。

好ましくは、上記のメモリ管理ユニット機能を実行する際に、命令アドレス及びデータアドレスの保護機能の有無のチェックが行われる。ここで、命令キャッシュメモリ及びデータキャッシュメモリの少なくとも一方のアクセス保護に対する違反が検出された場合には、命令キャッシュメモリ及びデータキャッシュメモリの少なくとも一方のアクセス保護の例外が発生したことを知らせるようにしている。これによって、シミュレーションの実行時に命令キャッシュメモリ及びデータキャッシュメモリのアクセス保護に対する違反をより確実に検出することが可能になる。

図１８は、命令キャッシュメモリ及びデータキャッシュメモリの両方がターゲットＣＰＵに内蔵されている場合に、本発明に係る命令キャッシュヒット判定及びデータキャッシュヒット判定に関するプログラムをＣソースコードに挿入した例を示す図である。

図１８の左上の部分においては、ＡＮＳＩ−Ｃ記述によるＣソースコードの部分が例示されている。このＣソースコードの部分では、前述の図１３の場合と同様に、バジェット追加ツールによって、各々のBasic Block の後の制御点を認識するために、同図の右側に示されるようなアセンブリ言語記述によるアセンブラ出力に展開するようにしている。

このアセンブラ出力を解析することによって、ＣソースコードをBasic Block に分割し、Basic Blockの最後の制御点を認識して、実行時間挿入文（例えば、図１８の左下の部分に示されるようなwaitfor(2)、 waitfor(4)、及びwaitfor(5) 等のwaitfor 文）と命令キャッシュヒット判定呼び出し文（fetch_icache文）を追加挿入する。

この更新後のＣコードの部分は、バジェット追加ツールによって、各々のBasic Block の後の制御点にて命令キャッシュヒット判定呼び出し文（fetch_icache文）が追加挿入された形式になっている。

又一方で、図１８の右側に示されるようなアセンブリ言語記述によるアセンブラ出力を解析することによって、生成されたロード命令及びストア命令に対応する箇所を認識することができる。このようにして、ロード命令に対するデータキャッシュヒット判定呼び出し文（load_dcache (Ai, Li)）、及び、ストア命令に対するデータキャッシュヒット判定呼び出し文（store_dcache (Ai, Li) ）を挿入すべき箇所を特定することが可能になる。

さらに、図１８の右側のアセンブラ出力において、前述の図１７の場合と同様に、生成されたロード命令に対応する箇所に、ロード命令に対するデータキャッシュヒット判定呼び出し文（load_dcache (Ai, Li)）を追加挿入し、かつ、生成されたストア命令に対応する箇所に、ストア命令に対するデータキャッシュヒット判定呼び出し文（store_dcache (Ai, Li) ）を追加挿入する。その後、図１８の左下の部分に示されるような更新後のＣ言語記述によるＣソースコードの部分（すなわち、Ｃコードの部分）に変換する。この更新後のＣコードの部分は、バジェット追加ツールによって、Basic Block の単位で命令キャッシュヒット判定呼び出し文（fetch_icache文）が挿入されると共に、ロード命令に対するデータキャッシュヒット判定呼び出し文（load_dcache (Ai, Li)）、及び、ストア命令に対するデータキャッシュヒット判定呼び出し文（store_dcache (Ai, Li) ）が挿入された形式になっている。より正確にいえば、図１８の左下の部分では、更新後のＣコードの部分をコンパイルすることによって最終的に出力されるＣベース言語記述の検証モデルが図示されている。

より詳しく説明すると、図１８のＣベース言語記述の検証モデルにおいては、前述の図１３の場合と同様に、各々のBasic Block の後の制御点に挿入されている実行時間挿入文（waitfor(2)、 waitfor(4)、及びwaitfor(5)）の直後に、命令キャッシュヒット判定呼び出し文（fetch_icache (stringcpy, 8) 、fetch_icache (stringcpy+8, 20)、 fetch_icache (stringcpy+28, 16) 、fetch_icache (stringcpy+44, 8)、 及びfetch_icache (stringcpy+52, 8)）を挿入する。なお、この例では、for文の終了条件の判定式( i<len の部分)は、ひとつのBasic Blcokと認識されるので、この部分に実行時間制御文(waitfor(2)文)と命令キャッシュヒット判定呼び出し文(fetch_icache (stringcpy+44, 8)文)が、この終了条件判定式の直前に挿入されて、waitfor(2), fetch_icache (stringcpy+44, 8), i<len の終了条件判定式に変換される。ここで、各々のBasic Block に対し命令キャッシュヒット判定を行った結果としてキャッシュミスを検出した場合には、当該Basic Block においてキャッシュラインフィルの実行時間（ラインフィル時間）をパラメータとする実行時間挿入文の呼び出しが行われる。

さらに、図１８のＣベース言語記述の検証モデルにおいては、前述の図１７の場合と同様に、生成されたロード命令（＊ｑ＋＋）に対応するＣコードの部位に、ロード命令に対するデータキャッシュヒット判定呼び出し文（load_dcache (q, 1)）を挿入すると共に、生成されたストア命令（＊ｐ＋＋、＊ｐ）に対応するＣコードの部位に、ストア命令に対するデータキャッシュヒット判定呼び出し文（store_dcache (p, 1) ）を挿入する。ここでも、各々のロード命令及びストア命令に対するキャッシュヒット判定を行った結果としてキャッシュミスを検出した場合には、このキャッシュミスが検出された部分に対応するＣコードの部位に、キャッシュラインフィルの実行時間（ラインフィル時間）をパラメータとする実行時間挿入文の呼び出しが行われる。

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

ＳｏＣの上流設計フローを示すフローチャートである。 従来のハードウェア／ソフトウェア協調検証方法を説明するためのデータ流れ図である。 従来のハードウェア／ソフトウェア協調検証方法によるタイミングバジェット処理追加の様子を説明するための模式図である。 図３にて生成されたＣベース言語記述の検証モデルに基づくＣベース・シミュレーションについて説明するための模式図である。 本発明に係るソフトウェア検証モデル生成方法を実施するためのハードウェア環境を例示するブロック図である。 ターゲットＣＰＵを用いた組み込みシステムにおける命令キャッシュメモリ及びデータキャッシュメモリの接続例を示すブロック図である。 図６の命令キャッシュメモリ、又は、データキャッシュメモリの具体的な構成例を示すブロック図である。 図７の命令キャッシュメモリ、又は、データキャッシュメモリのキャッシュミスによりキャッシュミスペナルティが発生する様子を説明するためのタイムチャートである。 本発明に係る命令キャッシュヒット判定機能を有する手続きを実行するプログラムの処理手順を説明するためのフローチャート（その１）である。 本発明に係る命令キャッシュヒット判定機能を有する手続きを実行するプログラムの処理手順を説明するためのフローチャート（その２）である。 本発明に係る命令キャッシュヒット判定機能を有する手続きの追加によるソフトウェア検証モデル生成方法を説明するための模式図である。 図１１にて生成されたＣベース言語記述の検証モデルに基づくＣベース・シミュレーションについて説明するための模式図である。 本発明に係る命令キャッシュヒット判定に関する手続呼び出しをＣソースコードに挿入した例を示す図である。 本発明に係るデータキャッシュヒット判定機能を有する手続きを実行するプログラムの処理手順を説明するためのフローチャート（その１）である。 本発明に係るデータキャッシュヒット判定機能を有する手続きを実行するプログラムの処理手順を説明するためのフローチャート（その２）である。 本発明に係るデータキャッシュヒット判定機能を有する手続きの追加によるソフトウェア検証モデル生成方法を説明するための模式図である。 本発明に係るデータキャッシュヒット判定に関するプログラムをＣソースコードに挿入した例を示す図である。 本発明に係る命令キャッシュヒット判定及びデータキャッシュヒット判定に関するプログラムをＣソースコードに挿入した例を示す図である。

符号の説明

１２ ターゲットＣＰＵ
１４ 主記憶装置
１６ キャッシュメモリ
１６−１ 命令キャッシュメモリ
１６−２ データキャッシュメモリ
１８ バス
３１ アドレス
３２ コンパレータ
３４ キャッシュヒット検出部
９１０ コンピュータ（ＰＣ又はＷＳ）本体
９１２ ホストＣＰＵ（中央処理装置）
９１４ 主記憶装置（ＭＳ）
９１６ キャッシュメモリ
９１８ バス
９２０ ディスプレイ
９２２ キーボード
９２４ マウス
９３０ 外部記憶装置（ハードディスク装置）

Claims (9)

1. 命令キャッシュメモリを有するホストＣＰＵを使用して、一つのターゲットＣＰＵ及び一つのＯＳが少なくとも搭載される半導体装置のハードウェア及びソフトウェアの協調検証を実行するために、ソフトウェアの検証モデルを生成するソフトウェア検証モデル生成方法であって、
   Ｃベース言語記述のソフトウェア部品を入力してＡＮＳＩ−Ｃ記述によるソースコードの部分を取り出し、Basic Block を認識し、制御点を挿入するステップと、
   該制御点が挿入された前記ＡＮＳＩ−Ｃ記述によるソースコードの部分をコンパイルしてターゲットＣＰＵ用バイナリ・コードを生成するステップと、
   前記Basic Block の各々について、該Basic Block の制御点間の実行時間を算出するステップと、
   前記実行時間をパラメータとする実行時間挿入文を該Basic Block の後の制御点に追加するステップと、
   該Basic Block の単位で命令キャッシュメモリがヒットしているか否かの判定を行うための手続きの呼び出しを該Basic Block の後の制御点に挿入するステップと、
   命令キャッシュメモリの無効化を行うアセンブラコードを、命令キャッシュ無効化手続きの呼び出しを行うＡＮＳＩ−Ｃ記述によるソースコードに変換するステップと、
   前記命令キャッシュメモリ内に保持されている命令タグメモリ部を用いて当該命令キャッシュメモリがヒットしているか否かの判定を行い、当該命令キャッシュメモリがヒットしていないことが検出されたときに、キャッシュラインフィルを実行するための実行時間を加算する命令キャッシュヒット判定機能を有する手続きを提供するステップと、
   前記命令キャッシュ無効化手続きが実行されたときに、前記命令タグメモリ部のエントリを無効化するステップと、
   前記の一連のステップで得られたＣベース言語記述のソフトウェア部品を前記検証モデルとして出力するステップとを有することを特徴とするソフトウェア検証モデル生成方法。
2. 命令アドレスを仮想アドレスから物理アドレスに変換するための命令アドレス変換用バッファが前記ターゲットＣＰＵ内に設けられている場合に、前記Basic Block の単位で前記命令アドレスが前記命令アドレス変換用バッファ内に存在するか否かの判定を行い、前記命令アドレスが前記命令アドレス変換用バッファ内に存在しないことが検出されたときに、命令アドレス変換のエントリを前記命令アドレス変換用バッファにロードする時間を加算するステップをさらに有することを特徴とする請求項１記載のソフトウェア検証モデル生成方法。
3. 前記命令アドレスの保護機能の有無をチェックし、前記命令アドレス変換用バッファのアクセス保護に対する違反が検出された場合に、前記命令アドレス変換用バッファのアクセス保護の例外が発生したことを知らせるステップをさらに有することを特徴とする請求項２記載のソフトウェア検証モデル生成方法。
4. データキャッシュメモリを有するホストＣＰＵを使用して、一つのターゲットＣＰＵ及び一つのＯＳが少なくとも搭載される半導体装置のハードウェア及びソフトウェアの協調検証を実行するために、ソフトウェアの検証モデルを生成するソフトウェア検証モデル生成方法であって、
   Ｃベース言語記述のソフトウェア部品を入力してＡＮＳＩ−Ｃ記述によるソースコードの部分を取り出し、Basic Block を認識し、制御点を挿入するステップと、
   該制御点が挿入された前記ＡＮＳＩ−Ｃ記述によるソースコードの部分をコンパイルしてターゲットＣＰＵ用バイナリ・コードを生成するステップと、
   前記Basic Block の制御点間の実行時間を算出するステップと、
   前記実行時間をパラメータとする実行時間挿入文を該Basic Block の後の制御点に追加するステップと、
   前記ＡＮＳＩ−Ｃ記述によるソースコードにてデータのアクセスが必要な部分で、データキャッシュメモリがヒットしているか否かの判定を行うための手続きの呼び出しを挿入するステップと、
   データキャッシュメモリの無効化を行うアセンブラコードを、データキャッシュ無効化手続きの呼び出しを行うＡＮＳＩ−Ｃ記述によるソースコードに変換するステップと、
   前記データキャッシュメモリ内に保持されているデータタグメモリ部を用いて当該データキャッシュメモリがヒットしているか否かの判定を行い、当該データキャッシュメモリがヒットしていないことが検出されたときに、キャッシュラインフィルを実行するための実行時間を加算するデータキャッシュヒット判定機能を有する手続きを提供するステップと、
   前記データキャッシュ無効化手続きが実行されたときに、前記データタグメモリ部のエントリを無効化するステップと、
   前記の一連のステップで得られたＣベース言語記述のソフトウェア部品を前記検証モデルとして出力するステップとを有することを特徴とするソフトウェア検証モデル生成方法。
5. データアドレスを仮想アドレスから物理アドレスに変換するためのデータアドレス変換用バッファが前記ターゲットＣＰＵ内に設けられている場合に、前記ＡＮＳＩ−Ｃ記述によるソースコードにてデータのアクセスが必要な部分で、前記データアドレスが前記データアドレス変換用バッファ内に存在するか否かの判定を行い、前記データアドレスが前記データアドレス変換用バッファ内に存在しないことが検出されたときに、データアドレス変換のエントリを前記データアドレス変換用バッファにロードする時間を加算するステップをさらに有することを特徴とする請求項４記載のソフトウェア検証モデル生成方法。
6. 前記データアドレスの保護機能の有無をチェックし、前記データアドレス変換用バッファのアクセス保護に対する違反が検出された場合に、前記データアドレス変換用バッファのアクセス保護の例外が発生したことを知らせるステップをさらに有することを特徴とする請求項５記載のソフトウェア検証モデル生成方法。
7. 命令キャッシュメモリ及びデータキャッシュメモリを有するホストＣＰＵを使用して、一つのターゲットＣＰＵ及び一つのＯＳが少なくとも搭載される半導体装置のハードウェア及びソフトウェアの協調検証を実行するために、ソフトウェアの検証モデルを生成するソフトウェア検証モデル生成方法であって、
   Ｃベース言語記述のソフトウェア部品を入力してＡＮＳＩ−Ｃ記述によるソースコードの部分を取り出し、Basic Block を認識し、制御点を挿入するステップと、
   該制御点が挿入された前記ＡＮＳＩ−Ｃ記述によるソースコードの部分をコンパイルしてターゲットＣＰＵ用バイナリ・コードを生成するステップと、
   前記Basic Block の各々について、該Basic Block の制御点間の実行時間を算出するステップと、
   前記実行時間をパラメータとする実行時間挿入文を該Basic Block の後の制御点に追加するステップと、
   該Basic Block の単位で命令キャッシュメモリがヒットしているか否かの判定を行うための手続き呼び出しを該Basic Block の後の制御点に挿入するステップと、
   前記ＡＮＳＩ−Ｃ記述によるソースコードにてデータのアクセスが必要な部分で、データキャッシュメモリがヒットしているか否かの判定を行うための手続きの呼び出しを挿入するステップと、
   命令キャッシュメモリ及びデータキャッシュメモリの無効化を行うアセンブラコードを、命令キャッシュ無効化手続き及びデータキャッシュメモリ無効化手続きの呼び出しを行うＡＮＳＩ−Ｃ記述によるソースコードに変換するステップと、
   前記命令キャッシュメモリ内に保持されている命令タグメモリ部を用いて当該命令キャッシュメモリがヒットしているか否かの判定を行い、当該命令キャッシュメモリがヒットしていないことが検出されたときに、キャッシュラインフィルを実行するための実行時間を加算する命令キャッシュヒット判定機能を有する手続きを提供するステップと、
   前記データキャッシュメモリ内に保持されているデータタグメモリ部を用いて当該データキャッシュメモリがヒットしているか否かの判定を行い、当該データキャッシュメモリがヒットしていないことが検出されたときに、キャッシュラインフィルを実行するための実行時間を追加するデータキャッシュヒット判定機能を有する手続きを提供するステップと、
   前記命令キャッシュ無効化手続きおよび前記データキャッシュメモリ無効化手続きが実行されたときに、前記命令タグメモリ部および前記データタグメモリ部のエントリを無効化するステップと、
   前記の一連のステップで得られたＣベース言語記述のソフトウェア部品を前記検証モデルとして出力するステップとを有することを特徴とするソフトウェア検証モデル生成方法。
8. 命令アドレスを仮想アドレスから物理アドレスに変換するための命令アドレス変換用バッファが前記ターゲットＣＰＵ内に設けられている場合に、前記Basic Block の単位で前記命令アドレスが前記命令アドレス変換用バッファ内に存在するか否かの判定を行い、前記命令アドレスが前記命令アドレス変換用バッファ内に存在しないことが検出されたときに、命令アドレス変換のエントリを前記命令アドレス変換用バッファにロードする時間を加算するステップと、
   データアドレスを仮想アドレスから物理アドレスに変換するためのデータアドレス変換用バッファが前記ターゲットＣＰＵ内に設けられている場合に、前記ＡＮＳＩ−Ｃ記述によるソースコードにてデータのアクセスが必要な部分で、前記データアドレスが前記データアドレス変換用バッファ内に存在するか否かの判定を行い、前記データアドレスが前記データアドレス変換用バッファ内に存在しないことが検出されたときに、データアドレス変換のエントリを前記データアドレス変換用バッファにロードする時間を加算するステップとをさらに有することを特徴とする請求項７記載のソフトウェア検証モデル生成方法。
9. 前記命令アドレスの保護機能の有無をチェックし、前記命令アドレス変換用バッファのアクセス保護に対する違反が検出された場合に、前記命令アドレス変換用バッファのアクセス保護の例外が発生したことを知らせるステップと、
   前記データアドレスの保護機能の有無をチェックし、前記データアドレス変換用バッファのアクセス保護に対する違反が検出された場合に、前記データアドレス変換用バッファのアクセス保護の例外が発生したことを知らせるステップとをさらに有することを特徴とする請求項８記載のソフトウェア検証モデル生成方法。

Images