(57)【特許請求の範囲】
【請求項１】
アプリケーションプログラムのプロセッサにおける動作をシミュレートするシミュレータを有するシステムであって、
前記プロセッサは、汎用処理を複数のパイプラインステージにより実行する汎用処理部と、
特定のデータ処理に特化した専用処理部であって、前記汎用処理部のパイプラインステージとは異なるデータパスを含む専用処理部とを備えており、
前記シミュレータは、
前記アプリケーションプログラムに含まれる命令が、前記汎用処理部における処理を規定する汎用命令であれば、その汎用命令を前記汎用処理部のそれぞれのパイプラインステージのモデルに変換する汎用命令ライブラリと、
前記アプリケーションプログラムに含まれる命令が、前記専用処理部における処理を規定する専用命令であれば、その専用命令を前記汎用処理部の前記パイプラインステージのサイクルに対応する情報を供給するモデルに変換する専用命令ライブラリと、
前記汎用命令ライブラリおよび前記専用命令ライブラリから提供される前記モデルを用いて、前記アプリケーションプログラムの動作を前記汎用処理部の前記パイプラインステージのサイクルでシミュレートするサイクルシミュレート手段とを有する、データ処理システム。
【請求項２】
請求項１において、前記汎用命令ライブラリは、前記汎用命令を、前記汎用処理部の前記パイプラインステージのそれぞれの第１のモデルと、前記パイプラインステージに共通する第２のモデルとに変換する、データ処理システム。
【請求項３】
請求項１において、前記専用命令ライブラリは、前記専用命令を、前記専用命令により前記専用処理部において消費される前記サイクルの数を含む前記情報を供給する前記モデルに変換する、データ処理システム。
【請求項４】
請求項１において、前記専用命令ライブラリは、前記専用命令を、前記情報として、前記専用処理部の状態を前記サイクルの単位で供給する前記モデルに変換する、データ処理システム。
【請求項５】
請求項１において、前記シミュレータは、前記アプリケーションプログラムに含まれる命令が、前記プロセッサでは実行されない疑似命令セットであれば、その疑似命令を、前記サイクルシミュレート手段において、前記サイクルをカウントしない処理を実行するための命令に変換する疑似命令ライブラリをさらに有する、データ処理システム。
【請求項６】
請求項５において、前記疑似命令は、前記汎用処理部および／または前記専用処理部の処理をシミュレートした結果を前記サイクルをカウントしないで評価する処理を規定する、データ処理システム。
【請求項７】
シミュレータが、アプリケーションプログラムのプロセッサにおける動作をシミュレートする方法であって、
前記プロセッサは、汎用処理を複数のパイプラインステージにより実行する汎用処理部と、
特定のデータ処理に特化した専用処理部であって、前記汎用処理部のパイプラインステージとは異なるデータパスを含む専用処理部とを備えており、
当該方法は、
前記アプリケーションプログラムに含まれる命令が、前記汎用処理部における処理を規定する汎用命令であれば、その汎用命令を前記汎用処理部のそれぞれのパイプラインステージのモデルに変換する第１の変換工程と、
前記アプリケーションプログラムに含まれる命令が、前記専用処理部における処理を規定する専用命令であれば、その専用命令を前記汎用処理部の前記パイプラインステージのサイクルに対応する情報を供給するモデルに変換する第２の変換工程と、
前記第１の変換工程および前記第２の変換工程により得られる前記モデルを用いて、前記アプリケーションプログラムによる前記プロセッサの動作を前記汎用処理部の前記パイプラインステージのサイクルでシミュレートするサイクルレベル・シミュレーション工程とを有する、方法。
【請求項８】
請求項７において、前記第１の変換工程では、前記汎用命令を、前記汎用処理部の前記パイプラインステージのそれぞれの第１のモデルと、前記パイプラインステージに共通する第２のモデルとに変換する、方法。
【請求項９】
請求項７において、前記第２の変換工程では、前記専用命令を、前記専用命令により前記専用処理部において消費される前記サイクルの数を含む前記情報を供給するモデルに変換する、方法。
【請求項１０】
請求項７において、前記第２の変換工程では、前記専用命令を、前記情報として、前記専用処理部の状態を前記サイクルの単位で供給する前記モデルに変換する、方法。
【請求項１１】
請求項７において、前記アプリケーションプログラムに含まれる命令が、前記プロセッサでは実行されない疑似命令セットであれば、その疑似命令セットを前記サイクルレベル・シミュレーション工程において、前記サイクルをカウントしない処理を実行するための命令に変換する第３の変換工程を、さらに有する、方法。
【請求項１２】
請求項１１において、前記疑似命令セットは、前記汎用処理部および／または専用処理部の処理をシミュレートした結果を前記サイクルをカウントしないで評価する処理を規定する、方法。
【請求項１３】
請求項７において、第１のシミュレート段階と第２のシミュレート段階とを有し、
前記第１のシミュレート段階では、前記アプリケーションプログラムは、前記プロセッサの動作を規定する仕様に基づく前記汎用命令と、前記疑似命令とを含み、
前記第２のシミュレート段階では、前記アプリケーションプログラムは、前記専用命令により実行される範囲が前記専用命令に置き換えられている、方法。
【請求項１４】
コンピュータにより、アプリケーションプログラムのプロセッサにおける動作をシミュレートするためのプログラムであって、
前記プロセッサは、汎用処理を複数のパイプラインステージにより実行する汎用処理部と、
特定のデータ処理に特化した専用処理部であって、前記汎用処理部のパイプラインステージとは異なるデータパスを含む専用処理部とを備えており、
前記コンピュータは、
前記汎用処理部における処理を規定する汎用命令を前記汎用処理部のそれぞれのパイプラインステージのモデルに変換する汎用命令ライブラリと、
前記専用処理部における処理を規定する専用命令を前記汎用処理部の前記パイプラインステージのサイクルに対応する情報を供給するモデルに変換する専用命令ライブラリとを含み、
当該プログラムは、
前記アプリケーションプログラムに含まれる命令が、前記汎用命令であれば、前記汎用命令ライブラリにより、その汎用命令を前記汎用処理部のそれぞれのパイプラインステージのモデルに変換する第１の変換処理と、
前記アプリケーションプログラムに含まれる命令が、前記専用命令であれば、前記汎用命令ライブラリにより、その専用命令を前記汎用処理部の前記パイプラインステージのサイクルに対応する情報を供給するモデルに変換する第２の変換処理と、
前記汎用命令ライブラリおよび前記専用命令ライブラリから提供される前記モデルを用いて、前記アプリケーションプログラムの動作を前記汎用処理部の前記パイプラインステージのサイクルでシミュレートするサイクルレベル・シミュレーション処理とを前記コンピュータが実行するための命令を有する、プログラム。
【請求項１５】
請求項１４において、前記第１の変換処理は、前記汎用命令を、前記汎用処理部の前記パイプラインステージのそれぞれの第１のモデルと、前記パイプラインステージに共通する第２のモデルとに変換する、プログラム。
【請求項１６】
請求項１４において、前記コンピュータは、前記プロセッサでは実行されない疑似命令セットであれば、その疑似命令を、前記サイクルレベル・シミュレーション処理において、前記サイクルをカウントしない処理を実行するための命令に変換する疑似命令ライブラリをさらに有し、
当該プログラムは、前記アプリケーションプログラムに含まれる命令が、前記疑似命令セットであれば、前記疑似命令ライブラリにより、その疑似命令を、前記サイクルをカウントしない処理を実行するための命令に変換する第３の変換処理を実行するための命令をさらに有する、プログラム。
【請求項１７】
請求項１６において、前記疑似命令は、前記汎用処理部および／または専用処理部の処理をシミュレートした結果を前記サイクルをカウントしないで評価する処理を規定する、プログラム。
【請求項１８】
請求項１４において、前記第２の変換処理では、前記専用命令を、前記情報として、前記パイプラインステージのサイクルに対応する情報であって、前記専用命令により前記専用処理部において消費されるサイクルの数を含む情報を供給する前記モデルに変換する、プログラム。
【請求項１９】
請求項１４において、前記第２の変換処理では、前記専用命令を、前記情報として、前記専用処理部の状態を、前記サイクルの単位で供給する前記モデルに変換する、プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、プロセッサにおける動作をシミュレーションするシステムに関するものである。
【０００２】
【従来の技術】
ハードウェアを設計する際の設計言語として、１９９０年代にレジスタベースの記述言語ＲＴＬが普及した。ＶｅｒｉｌｏｇやＶＨＤＬが代表的な言語である。これらのＲＴＬは、レジスタをハードウェアのベースとしたレジスタ間の信号伝達や信号処理を、プラスやマイナスや乗算や除算といった算術演算、ＡＮＤやＯＲといった論理演算、「ＩＦ  ＴＨＥＮ  ＥＬＳＥ」といった条件文や代入文により論理的に記述することにより設計することができる。したがって、ＲＴＬにより、その当時としては論理回路の設計の抽象度を向上することができ、プロセッサなどの設計効率を高めることができた。
【０００３】
その後、１９９０年代後半からは動作レベルと称される、一層抽象度を高めた設計言語が使用されるようになってきた。これらの言語はＶｅｒｉｌｏｇやＶＨＤＬといったレジスタベースの言語の発展系とも考えられ、実際、ＶｅｒｉｌｏｇやＶＨＤＬには動作レベルの記述形式が包含されている。
【０００４】
その一方、動作レベルにおいてはレジスタという概念は無く、算術演算、論理演算、条件文、代入文といった記述に集約される。したがって、一般のソフトウェア記述言語もその範疇であり、１９９０年代後半からはＣ言語によるハードウェア設計が模索され始めた。Ｃ言語であれば、より一般的でありソフトウェア資源が多いことに加え、レジスタベースの言語は、たとえそれを動作記述に絞ったとしても、シミュレーション速度が遅い。たとえば、Ｃ言語で記述された仕様と、ＲＴＬで記述された仕様では、シミュレーション速度は、Ｃ言語の方が数１０００倍から１０万倍程度速く、速度の差が非常に大きい。このシミュレーション速度の違いは、ＲＴＬはハードウェアを設計するための言語であり、Ｃ言語はソフトウェアを設計するための言語である所に起因する。
【０００５】
【発明が解決しようとする課題】
近年、ソフトウェアを記述するＣ言語でプロセッサにより実行するアプリケーションの仕様を初期設計し、最終的にはハードウェアを記述するＲＴＬに変換してプロセッサの設計を検証する方式が生まれてきている。さらに、Ｃ言語により与えられた仕様を実現するプロセッサを開発および設計する際に、その仕様を直にハードウェアに変換するのではなく、仕様の一部を専用プロセッサを介してハードウェア化する方式が提案されている。本願の出願人は、たとえば、特開２０００−２０７２０２号にカスタマイズ可能な専用命令を装着できるデータ処理装置を開示している。このようなプロセッサの設計方式では、命令セット（インストラクションセット）ベースの記述、あるいはアセンブラベースの記述とも言える記述がＣ言語とＲＴＬとの間に存在することになる。命令セットによる記述は、単に論理ベースの記述でしかないＣ言語による仕様に比べるとより正確にプロセッサにおける実行状況をシミュレートできる。したがって、命令形式での記述（命令レベル）のシミュレータが近年開発されており、インストラクションセットシミュレータ（ＩＳＳ）と称されている。
【０００６】
しかしながら、従来のＩＳＳは命令列、たとえば、アセンブラ命令の実行をシミュレーションするものであり、ハードウェアそのものをシミュレーションするものではなかった。したがって、入出力（ＩＯ）信号のリード・ライトや割り込み等のリアルタイムの処理に関しては、それらの機能が実行されるか否かという点では正しいシミュレーションができても、必ずしもハードウェア的に正しいシミュレーションが行われているわけではない。たとえば、クロックサイクルのレベルではプロセッサの実動作から多少外れるシミュレーションが行われることになる。本来、ＩＳＳは、命令列のシミュレーションであるのでそれでも構わないのであるが、シミュレーションの対象となっているアプリケーションプログラムがプロセッサ上で動作する際のハードウェアをシミュレーションしようとする観点からすればそれでは不十分である。したがって、現状のＩＳＳは、シミュレータ自体はＣ言語で記述することができるので命令セットベースの実行状況を高速でシミュレートできるのであるが、ハードウェアシミュレーションのツールとしては不十分である。
【０００７】
したがって、ハードウェアシミュレーションを行うためには、やはりＲＴＬベースのシミュレータが必要となる。しかしながら、上述したように、ＲＴＬによるシミュレーションは速度が非常に遅く、ハードウェアレベルでのシミュレーションがプロセッサを設計する期間を短縮しようとしたときの大きなボトルネックとなっている。
【０００８】
特に、Ｃ言語からの設計自動化ツールとして、「ＣｔｏＲＴＬ」と称されている動作合成ツールが利用可能になっており、設計の自動化はＲＴＬからＣへと進みつつある現状では、シミュレーション検証の問題を解決することが重要となっている。
【０００９】
このＣｔｏＲＴＬツールとは、仕様を記述したＣ言語を入力として、クロック周波数をパラメータとして与えることにより、レジスタで構成されたＲＴＬを出力するツールである。入力となるＣ言語には、上述したように、クロックもしくはサイクルという概念は無い。そのため、そこに与えられたクロック周波数に応じて、レジスタを割り当てて仕様を満足させる解を得るようになっている。その際、仕様に記述されている算術演算や論理演算を実行する演算器を割り当てる必要があり、いかに少ない演算器で、Ｃ言語で与えられた仕様通りの動作を実現するかというリソースシェアリングと、仕様にて記述された実行順序をいかに少ないクロック数で実現するかのスケジューリングがこの合成ツールの決め手であると言える。したがって、ＣｔｏＲＴＬツールのパフォーマンスを評価あるいは検証することも重要となっている。また、Ｃ言語からＲＴＬを自動合成するので、Ｃ言語の仕様がそのままＲＴＬ化されてしまい、Ｃ言語では冗長なビットがそのまま自動合成に反映されてしまうという問題もある。
【００１０】
また、専用プロセッサを設けたプロセッサを用いたアプリケーションプログラムにおいては、専用プロセッサのデータパス系を用いて特定の処理を行う専用命令を汎用命令と共に装着することになる。しかしながら、従来のＩＳＳでは機能的にはシミュレートできてもハードウェア的にはシミュレートできない。すなわち、データパス系の命令を実行する際に消費するクロック数と汎用命令との関係が不明であり、従来のＩＳＳではデータパス系の命令（専用命令）の機能を確認できるだけである。
【００１１】
そこで、本発明においては、高速でハードウェアシミュレーションを行うことができる新しいシミュレータを提供することを目的としている。さらに、データパス系の専用命令と、汎用プロセッサを動作させる汎用命令との実行状況をハードウェアレベルで高速にシミュレーションできるシミュレータを提供することを目的としている。
【００１２】
【課題を解決するための手段】
レジスタレベルのＲＴＬによるシミュレータはハードウェアを記述するためにクロックサイクルという概念があるが、これに対し、Ｃ言語によるシミュレータはクロックという概念がなく動作を記述できる点が利点になっている。これに対し、本発明においては、ＩＳＳでシミュレートされる命令セットをサイクルベースに分割することにより、ハードウェアをシミュレーションするツールとしてＩＳＳを利用できるようにしている。このサイクルレベルのＩＳＳは、Ｃ言語そのもののシミュレーションよりは速度が低下するとは言うものの、シミュレーション速度をＲＴＬベースのシミュレータの数百倍から数千倍程度まで高速化でき、さらに、ＲＴＬでシミュレーションするのと同等の結果が得られる。このため、プロセッサの設計効率を大幅に改善することが可能となる。
【００１３】
本発明の一態様は、アプリケーションプログラムのプロセッサにおける動作をシミュレートするシミュレータを有するシステムであって、前記プロセッサは、汎用処理を複数のパイプラインステージにより実行する汎用処理部と、特定のデータ処理に特化した専用処理部であって、前記汎用処理部のパイプラインステージとは異なるデータパスを含む専用処理部とを備えており、前記シミュレータは、前記アプリケーションプログラムに含まれる命令が、前記汎用処理部における処理を規定する汎用命令であれば、その汎用命令を前記汎用処理部のそれぞれのパイプラインステージのモデルに変換する汎用命令ライブラリと、前記アプリケーションプログラムに含まれる命令が、前記専用処理部における処理を規定する専用命令であれば、その専用命令を前記汎用処理部の前記パイプラインステージのサイクルに対応する情報を供給するモデルに変換する専用命令ライブラリと、前記汎用命令ライブラリおよび前記専用命令ライブラリから提供される前記モデルを用いて、前記アプリケーションプログラムの動作を前記汎用処理部の前記パイプラインステージのサイクルでシミュレートするサイクルシミュレート手段とを有する、データ処理システムである。
本発明の異なる一態様は、シミュレータが、アプリケーションプログラムのプロセッサにおける動作をシミュレートする方法であって、前記プロセッサは、汎用処理を複数のパイプラインステージにより実行する汎用処理部と、特定のデータ処理に特化した専用処理部であって、前記汎用処理部のパイプラインステージとは異なるデータパスを含む専用処理部とを備えており、当該方法は、前記アプリケーションプログラムに含まれる命令が、前記汎用処理部における処理を規定する汎用命令であれば、その汎用命令を前記汎用処理部のそれぞれのパイプラインステージのモデルに変換する第１の変換工程と、前記アプリケーションプログラムに含まれる命令が、前記専用処理部における処理を規定する専用命令であれば、その専用命令を前記汎用処理部の前記パイプラインステージのサイクルに対応する情報を供給するモデルに変換する第２の変換工程と、前記第１の変換工程および前記第２の変換工程により得られる前記モデルを用いて、前記アプリケーションプログラムによる前記プロセッサの動作を前記汎用処理部の前記パイプラインステージのサイクルでシミュレートするサイクルレベル・シミュレーション工程とを有する、方法である。
本発明のさらに異なる一態様は、コンピュータにより、アプリケーションプログラムのプロセッサにおける動作をシミュレートするためのプログラムであって、前記プロセッサは、汎用処理を複数のパイプラインステージにより実行する汎用処理部と、特定のデータ処理に特化した専用処理部であって、前記汎用処理部のパイプラインステージとは異なるデータパスを含む専用処理部とを備えており、前記コンピュータは、前記汎用処理部における処理を規定する汎用命令を前記汎用処理部のそれぞれのパイプラインステージのモデルに変換する汎用命令ライブラリと、前記専用処理部における処理を規定する専用命令を前記汎用処理部の前記パイプラインステージのサイクルに対応する情報を供給するモデルに変換する専用命令ライブラリとを含み、当該プログラムは、前記アプリケーションプログラムに含まれる命令が、前記汎用命令であれば、前記汎用命令ライブラリにより、その汎用命令を前記汎用処理部のそれぞれのパイプラインステージのモデルに変換する第１の変換処理と、前記アプリケーションプログラムに含まれる命令が、前記専用命令であれば、前記汎用命令ライブラリにより、その専用命令を前記汎用処理部の前記パイプラインステージのサイクルに対応する情報を供給するモデルに変換する第２の変換処理と、前記汎用命令ライブラリおよび前記専用命令ライブラリから提供される前記モデルを用いて、前記アプリケーションプログラムの動作を前記汎用処理部の前記パイプラインステージのサイクルでシミュレートするサイクルレベル・シミュレーション処理とを前記コンピュータが実行するための命令を有する、プログラムである。
アプリケーションプログラムの動作をパイプラインステージのサイクルでシミュレートする手段（サイクルレベル・シミュレーション手段であり、サイクルレベル・シミュレータ本体あるいはＩＳＳ本体として説明している）を有するデータ処理システムは、本明細書の実施の形態ではシミュレータあるいはシミュレーションシステムとして説明されているものである。このデータ処理システムを採用することにより、ＬＳＩを自動設計するための一連の自動設計システムを提供することが可能となる。また、本発明のシミュレータは、命令サイクルが複数のパイプラインステージにより実行される複数の命令セットを備えたアプリケーションプログラムのプロセッサにおける動作をシミュレートするプログラムであって、アプリケーションプログラムの動作をパイプラインステージのサイクルでシミュレートするサイクルレベル・シミュレーション処理を実行するための命令を有するプログラムとして提供することが可能であり、ＣＤ−ＲＯＭなどの適当な記録媒体に記録したり、コンピュータネットワークなどの媒体を通じて供給することができる。
【００１４】
従来のＩＳＳでは、命令セット単位にシミュレーションモデルが記述かつ管理されていた。これに対し、本発明では、命令セットをパイプラインのサイクル単位に分解し、命令セットをサイクル単位にモデル化して管理する。命令セットをサイクル単位にモデル化するのは、サイクルレベル・シミュレーション工程あるいは手段で行っても良いし、あるいは、事前にコンパイラーなどで命令セットをサイクル単位に分解したシミュレーションモデルを形成しておき、それを実行しても良い。本発明では、サイクル単位で命令セットの実行と、それに起因する、あるいはしないその他の処理、たとえば、割り込み動作とが正しくモデル化して管理できる。したがって、ＲＴＬでなくても、Ｃ言語あるいはその他の高級言語によるシミュレータにより、ハードウェアのシミュレーションをサイクルベースで正しく行うことが可能となる。このため、高速でハードウェアをシミュレーションできる。
【００１５】
本発明では、命令セットの一連の命令サイクル、すなわち、フェッチ、デコード、実行およびライトバックを、それに対応した各々のパイプラインステージ毎（パイプラインステージのサイクル毎）の処理に分けてシミュレートする。各命令の各パイプラインステージにおける処理を個別にモデル化しても良い。しかしながら、これらの各命令、あるいは各パイプラインステージの処理で共通なものは共通に管理できるようにモデル化した方がハードウェア資源を節約でき、シミュレータ用のプログラムを短期間に低コストで開発することができる。
【００１６】
サイクル単位のモデルは、大きくふたつの記述部分に別けることができる。ひとつは、その命令セットの固有の記述であり、例えば、ＡＮＤ命令の１つのパイプラインステージである実行（ＥＸＥＣＵＴＩＯＮ）サイクルの機能（機構および／またはタイミングなど）を記述する部分である。もうひとつは、各命令セットの各パイプラインステージを実行する際の共通な記述であり、例えば、割り込み信号に対する処置に関する記述である。そこで、本発明においては、サイクル単位でシミュレートする前に、命令セットの各パイプラインステージをサイクルレベルでシミュレートする手段（ＩＳＳ本体）あるいはそこにおける処理で管理可能な第１の情報に変換するライブラリを設ける。これにより、命令セットあるいはその命令セットのパイプラインステージが与えられれば、ＩＳＳ本体における処理あるいはＩＳＳ本体で管理されるモデルはライブラリで与えられる。また、ＩＳＳ本体あるいはその処理では、各パイプラインステージに共通する処理あるいはモデルを記述しておき、その共通の処理に関わる第２の情報に基づき第１の情報によりシミュレートするようにすると、第１の情報は個々のパイプラインステージの処理のうち、固有の処理に対応する情報に限定できる。
【００１７】
したがって、本発明では、シミュレーションする際に、命令セットをサイクル単位に分解され、サイクルレベル・シミュレーション手段であるＩＳＳ本体にはサイクル単位に時間管理する機能を設けられる。各サイクルにおいて命令固有な部分は、命令セットのサイクル毎の処理記述あるいはモデルとしてライブラリに記述される。また、各サイクルにおいて割り込み等の外部信号に対する共通の処理記述あるいはモデルはＩＳＳ本体に記述される。したがって、簡易な構成のハードウェアで、シミュレートできるシステムあるいは環境を提供できる。そして、アプリケーションプログラムが供給されると、それをシミュレーションの対象となるプロセッサで実行されたときのように、個々の命令セットを個々のパイプラインステージに分割し、サイクル単位でシミュレートすることができる。また、命令サイクルが複数のパイプラインステージにより実行される複数の命令セットを備えたアプリケーションプログラムを、命令セットが、パイプラインステージに分割された記述で表されたシミュレーションモデルに変換する処理を実行可能な命令を有するプログラムにより、アプリケーションプログラムを本発明のＩＳＳ本体に適したシミュレーションモデルに変換してシミュレーションの時間をさらに短縮するようにしても良い。
【００１８】
本明細書におけるアプリケーションプログラムとは、ソースプログラム、オブジェクトプログラム（オブジェクトコード）あるいは中間段階のプログラムなどの、プロセッサに対して動作あるいは処理を指示する命令セットを含むすべてのレベルのプログラムを意味し、シミュレーションの対象となるすべてのプログラムを含むものである。
【００１９】
シミュレーションの対象となるプロセッサが専用のデータパスを備えている場合は、そのデータパスを用いた処理と、汎用プロセッサにおけるパイプラインステージの処理とでは、サイクルの管理が異なる。したがって、プロセッサが、汎用処理を実行可能な汎用処理部および特定のデータ処理に特化した専用処理部を備えている場合は、アプリケーションプログラムに含まれる命令セットのうち、汎用処理部における処理を規定する汎用命令セットが、命令サイクルが複数のパイプラインステージにより実行される命令セットであり、汎用命令セットの各パイプラインステージをシミュレートする手段で管理可能な情報に変換する汎用命令ライブラリと、アプリケーションプログラムに含まれる命令セットのうち、専用処理部における処理を規定する専用命令セットをシミュレートする手段で管理可能な情報に変換する専用命令ライブラリとを設けることが望ましい。汎用命令セットと専用命令セットとを、異なる変換処理（第１の変換処理および第２の変換処理）でそれぞれ異なるライブラリを用いて変換し、サイクルレベルでシミュレーションを行う手段（ＩＳＳ本体）に提供することにより、汎用処理ユニットと専用処理ユニットとを有するプロセッサの動作を、パイプライン処理をベースにモデル化できる。これらの変換を行うライブラリプログラムは１つのプログラムとして提供しても良いが、異なるライブラリプログラムとして提供することにより、汎用命令セットについてはシミュレータ提供者が供給し、専用命令セットについては専用処理部を設計したユーザが供給するといった体制を取ることができる。
【００２０】
また、専用命令ライブラリで、専用処理部の処理を適切にモデル化することができる。専用命令ライブラリから専用命令セットにより消費されるサイクルの情報を何らかの信号あるいは情報としてシミュレートする手段であるＩＳＳ本体あるいはその処理に返すことにより、専用処理部の実行状態をＩＳＳ本体におけるシミュレーションに反映できる。また、専用命令ライブラリは専用処理部の状態をサイクルの単位でＩＳＳ本体あるいはその処理に返すことによっても専用処理部の状態をシミュレーションに反映できる。
【００２１】
このように、本発明によりサイクル単位で高速にハードウェアをシミュレーションできるツールを提供することができる。したがって、Ｃ言語で記述された仕様を実現し、高速で処理可能な複数の専用回路を用いた分散処理タイプのシステムＬＳＩをさらに短期間に、経済的に設計し供給することができる。そして、プロセッサの設計・開発において、Ｃ言語からＲＴＬに移行する中間の段階で、サイクルあるいはクロックの概念を持たせながらシミュレーションすることができる。この新たな設計インフラストラクチャ・レイヤの導入はシミュレーション速度を速めて設計の効率化を図るだけでなく、他にも様々なメリットがある。
【００２２】
その１つは、上述したように、汎用命令セットと専用命令セットで駆動されるプロセッサにおいて、専用命令セットで駆動される専用処理部（専用目的処理部あるいは専用回路部）の動作をＲＴＬではなく、Ｃ言語レベルに近い状態でシミュレーションすることができることである。加えて、サイクルベースのＩＳＳ本体で管理できる情報に変換されていれば良いので、Ｃ言語そのものである必要はなく、専用処理部の動作を記述するのにさらに適した言語があれば、Ｃ言語の仕様をその新たな言語に変換してからコンパイルして専用命令ライブラリを作成することができる。
【００２３】
たとえば、プロセッサの仕様は、現在最もポピュラーなＡＮＳＩ−Ｃが使用されているが、記述できる変数のデータ長が限定されており、１６ビット、３２ビットおよび６４ビットに限定される。これに対し、ユーザ命令として実装される仕様では、これらのデータ長が常に採用されることは少なく、２４ビットあればよいなどの仕様はごく普通である。ＡＮＳＩ−Ｃでは、このような仕様を忠実に再現することはできず、結局、このような仕様を盛り込んだＲＴＬのシミュレーションとは異なった結果をもたらす可能性があり、最終的にはＲＴＬのシミュレーションを繰り返す必要がでてきてしまう。しかしながら、他の言語、たとえばＣ＋＋であれば、クラスライブラリを使用して変数の型宣言を行うことによりデータ長はバリアブルになる。したがって、Ｃ言語の仕様をＣ＋＋に変換してコンパイルし、専用命令ライブラリを作成すれば、冗長なビットを削除することが可能となり、ＲＴＬと同レベルのシミュレーションをサイクルベースのＩＳＳ本体およびそれを備えたシミュレーションシステムで高速に実行することが可能となる。
【００２４】
もう１つのメリットは、シミュレーションの評価のために、あるいは他の目的で、プロセッサで実行されない疑似命令セット（擬似命令セット）をアプリケーションプログラムに追加し、サイクルベースのＩＳＳシミュレーションのシミュレーション対象にすることができることである。プロセッサで実行されない疑似命令セットは、たとえば、ＩＳＳ本体でサイクル数をカウントしないで処理を行うことを命令するものであり、疑似命令セットをシミュレータが管理可能な情報に変換する疑似命令ライブラリを、上記の専用命令ライブラリと同じレベルで用意すればサイクルベースのＩＳＳ本体あるいはそれを用いたシミュレーションシステムに組み込むことができる。動作を評価（テストあるいはデバック）する疑似命令セットとしては、データファイルの入出力をモニタする処理を実行させる命令がある。
【００２５】
このサイクルベースのシミュレーション手段を利用したシミュレーションでは専用処理部を備えたプロセッサをシミュレーションする作業を、幾つかの段階に分けることができる。第１のシミュレーション段階は、Ｃ言語などで与えられた仕様から専用命令で実行する部分を除かないで、ＩＳＳ、できればサイクルベースのＩＳＳ本体でシミュレートすることである。この段階で、疑似命令セットを導入しておけば、それ以降の評価の基準となる入力データや出力期待値などを得ることができる。次の第２のシミュレーション段階は、仕様から専用処理部で実行する部分を抽出して専用命令セットに置き換え、一方、その抽出した部分から専用命令ライブラリを作成しておいて、本発明のサイクルベースのＩＳＳ本体でシミュレートすることである。本発明のサイクルベースのＩＳＳ本体であれば、専用処理部も含めてサイクルベースでシミュレートできるので、この段階でプロセッサの開発の大部分を行うことができる。また、疑似命令セットを利用し、この段階で得られるデータを、先に求めた入力データや出力期待値と照らし合わせることにより、大きな設計上の間違えを犯すことなくスムーズに短時間でプロセッサを開発することができる。
【００２６】
さらに、第３のシミュレーション段階として、専用命令ライブラリをＲＴＬ化した後に、サイクルベースのＩＳＳ本体でシミュレートする段階を設けることも可能である。実際にＲＴＬに変換したときの機能を確認することが可能であり、汎用処理部の側もサイクルベースのＩＳＳ本体で稼動させられるので、ＲＴＬとマッチングさせて高精度のシミュレーションを行うことができる。
【００２７】
【発明の実施の形態】
以下に図面を参照しながら本発明についてさらに説明する。図１に、特定のデータ処理に特化したデータパス部２０を備えた専用処理ユニット（専用命令実行ユニットあるいは専用目的処理ユニット、以降ではＶＵ）１と、汎用的な構成の汎用処理ユニット（汎用命令実行ユニット、汎用目的処理ユニットあるいはプロセスユニット、以降ではＰＵ）２とを備えたデータ処理装置１０の概要を示してある。このデータ処理装置１０は、専用回路を備えたプログラマブルなプロセッサであり、実行形式の制御プログラム（オブジェクトプログラム、オブジェクトコード、マイクロプログラムコード）４ａを内蔵したコードＲＡＭ４から命令をフェッチし、専用データ処理ユニット１および汎用データ処理ユニット２にデコードされた制御信号を提供するフェッチユニット５を備えている。このフェッチユニット５は、前の命令あるいはステートレジスタ６の状態、割り込み信号φｉなどによって決まる所定のコードＲＡＭ４の所定のアドレスから命令をフェッチするフェッチ部７と、フェッチされた専用命令あるいは汎用命令（一般命令）をデコードするデコード部８とを備えている。デコード部８は、専用命令をデコードした制御信号（デコーデド・コントロール・シグナル；Decoded Control Signal）φｖおよび汎用命令をデコードした制御信号φｐを、専用データ処理ユニットＶＵ１および汎用データ処理ユニットＰＵ２にそれぞれ供給する。さらに、ＰＵ２からは実行状態を示すステータス信号φｓが返えされ、ＰＵ２およびＶＵ１の状態がステートレジスタ６に反映される。
【００２８】
本例のＰＵ２は、汎用レジスタ、フラグレジスタおよび演算ユニット（ＡＬＵ）などから構成される汎用性の高い実行ユニット１１を備えており、実行した結果をデータＲＡＭ１５などに出力しながら汎用処理を次々と実行できる構成となっている。すなわち、本例のＰＵ２においては、１つの汎用命令セットは、フェッチおよびデコードするステージ、実行するステージ、結果をメモリに書き込むステージなどの複数のパイプラインステージに分かれて実行される。また、これらのフェッチユニットＦＵ５、汎用データ処理ユニットＰＵ２、コードＲＡＭ４、データＲＡＭ１５を有する構成は、個々の機能は異なるが一般的なプロセッサユニットと類似なものである。したがって、ＦＵ５、ＰＵ２、コードＲＡＭ４およびデータＲＡＭ１５を有する構成をプロセッサユニット３と称することも可能であり、プロセッサユニット（ＰＵＸ）３からＶＵ１を制御するような概念で本例のデータ処理装置１０を構成あるいは設計することができる。
【００２９】
ＦＵ５からの専用命令φｖを実行する専用データ処理ユニットＶＵ１は、ＦＵ５が供給する命令がＶＵ命令φｖであるかなどをデコードするユニット２２と、予め特定のデータ処理を行うように制御信号をハードウェア的に出力するシーケンサ（ＦＳＭ（Finite State Machine）、ファイナイトステートマシン）２１と、このシーケンサ２１からの制御信号に従って特定のデータ処理を行うようにデザインされたデータパス部２０を備えている。また、ＶＵ１は、ＰＵ２からアクセス可能なレジスタ２３を備えており、データパス部２０の処理に必要なデータをインターフェイスレジスタ２３を介してＰＵ２で制御したり、ＶＵ１の内部状態をレジスタ２３を介してＰＵ２で参照できるようになっている。また、データパス部２０で処理された結果はＰＵ２に供給され、ＰＵ２ではその結果を利用した処理が行われる。
【００３０】
このデータ処理装置１０は、コードＲＡＭ４に、汎用命令（ＰＵ命令）および専用命令（ＶＵ命令）を含んだプログラムが記憶されており、それがフェッチユニット５でフェッチされ、デコードされた制御信号φｐまたはφｖとしてＶＵ１およびＰＵ２に供給される。ＶＵ１は、制御信号φｐおよびφｖのうち、自己を起動する専用命令の制御信号φｖが供給されると稼動する。一方、ＰＵ２には、汎用命令がデコードされた制御信号φｐだけが供給されるようになっており、ＶＵ命令をデコードした制御信号φｖはＰＵ２には発行されず、その代わりに、実行を伴わないｎｏｐ命令を示す制御信号が発行され、ＰＵ２の処理はスキップされる。ＶＵ１は、アプリケーションなどによって変更されるものであり、ＶＵ１に指示を出す専用命令もアプリケーションによって変わることが多い。ＶＵ１は、アプリケーションに特化したデータパスあるいは専用回路であり、ＶＵ命令をデコードした制御信号を解釈するように設計することは容易である。一方、ＰＵ２は、ｎｏｐ命令が出力されることにより、ＶＵ１用に特化した命令に対処する必要がなく、基本命令あるいは汎用命令を解釈して実行できる機能があればよく、汎用性を犠牲にすることなく様々なアプリケーションに対応したＶＵ１と共存し、これらを制御したり、その演算結果を用いて処理を行うことができる。
【００３１】
したがって、図１に示したデータ処理装置１０は、リアルタイム応答などの特殊な演算が要求される処理を実現できる専用回路を備えたＶＵ１と、汎用性があるＰＵ２とを有するものであり、以降においてはＶＵＰＵと称することにする。このＶＵＰＵ１０は、リアルタイム応答性を犠牲にすることなく、設計および開発期間を短縮でき、さらに、その後の変更や修正にも柔軟に対処できるものである。また、ＶＵ１は、１つに限定されることはなく、アプリケーションで要求される専用処理を処理できるように複数のＶＵ１を用意し、それぞれのＶＵ１を稼動する複数の専用命令をプログラムコードに含めることが可能である。さらに、本例のＶＵ１は、特殊な演算処理だけでなく、プログラム中の特定のプログラムファンクションを専用回路化してプログラムを効率良く可動させることができる。したがって、ＶＵＰＵ１０を複数備えたデータ処理システムは適応可能な範囲が非常に広いアーキテクチャである。
【００３２】
図２に、このアーキテクチャのプロセッサを開発する流れを示してある。Ｃ言語で記述された仕様あるいはプログラム３１を実行するために、プログラム中の特定のプロセスあるいはプログラムファンクションＣｓを専用回路化してプログラムを効率良く可動させる。すなわち、仕様３１は、Ｃ言語によるアプリケーションプログラム３２と、専用回路化するファンクション３３とに分けられ、アプリケーションプログラム３２は汎用処理を行う命令（ＰＵ命令）からなる部分Ｃｇ３４と、専用回路を起動する命令（ＶＵ命令）とを含むものとなる。そして、このアプリケーションプログラム３２はＣ−コンパイラ３５により、プロセッサで実行可能なアセンブラの命令セットに変換され、実行用のプログラムコード４ａが生成される。一方、抽出されたプログラムファンクション３３は、そのファンクションの処理に必要な動作が解析され（動作合成３６）、専用のデータパスが設計あるいは開発される。このようにして、基本プロセッサであるＰＵＸ３と専用回路ＶＵ１を備えたＶＵＰＵ１０と、このＶＵＰＵ１０で実行されるプログラムコード４ａが生成される。
【００３３】
したがって、開発されたＶＵＰＵ１０における実行用のプログラムコード（以降ではこの状態もアプリケーションプログラムに含められる）４ａの動作をシミュレーションするためには、ＰＵＸ３の機能をモデル化したＲＴＬと、ＶＵ１の機能をモデル化したＲＴＬとを生成し、これらをプラットフォームとしてプログラム４ａをシミュレーションすることができる。本明細書においては、アプリケーションプログラムとは、プロセッサを動作させる命令セットを含んだすべての段階のプログラムを意味し、コンパイル前、コンパイル後およびその過程の中間のプログラムも含む。すなわち、アプリケーションプログラムとはシミュレーションの対象になるすべてのプログラムを意味する
しかしながら、上述したように、ＲＴＬをベースとしたシミュレーションは非常に時間がかかるので実際的でない。一方、アセンブラのレベル、すなわち、命令セットのレベルでシミュレーションすると、プログラム４ａの機能は確認できるが、実際にＶＵＰＵ１０でサイクルあるいはクロック毎にどのように状態が変化しているかも含めてはシミュレートできない。これが第１の問題である。
【００３４】
第２の問題は、ＶＵ１として専用回路化された処理を実行するためのデータパス命令（ＶＵ命令）は、例えば、画像処理やネットワーク処理において信号列の中から「ある特定のビットパターンを検出する」といった命令である。したがって、このような命令の場合には、専用回路で使用または消費されるサイクル数はデータ依存であり、あらかじめ知ることができない。このため、ＲＴＬをプラットフォームとしたシミュレータでもシミュレートは難しい。
【００３５】
まず、最初の問題をもう少し説明すると、図３に示すように、基本プロセッサであるＰＵＸ３では、ＡＤＤなどの１つの命令セットの命令サイクルは複数のパイプラインステージに分割して処理される。図３（ａ）は、３段のパイプライン型ＲＩＳＣの命令サイクルを示してあり、１つの命令セットは、フェッチとデコードするサイクル（Ｆ＆ＤサイクルまたはＦ＆Ｄステージ）５１、実行するサイクル（実行サイクルまたは実行ステージ）５２、メモリなどにライトバックするサイクル（ＷＢサイクルまたはＷＢステージ）５３に分割して処理される。また、図３（ｂ）に示すように、４段のパイプライン型ＲＩＳＣであれば、フェッチとデコードサイクル５１がさらにフェッチサイクル５１ａとデコードサイクル５１ｂに分けて実行される。以降では、簡単のために３段のパイプライン型ＲＩＳＣを基本プロセッサＰＵＸ３として採用した例を説明する。この場合、ＰＵＸ３では、ｎ番目の命令Ｉ（ｎ）のＦ＆Ｄサイクル５１と共に、ｎ−１番目の命令Ｉ（ｎ−１）の実行サイクル５２と、ｎ−２番目の命令Ｉ（ｎ−２）のＷＢサイクル５３が進行する。
【００３６】
図４（ａ）は、従来のインストラクションセットシミュレータ（ＩＳＳ）の命令モデルを示しており、１番目の命令セットＩ（１）からＩ（６）までが順番に並んで処理されるモデルである。命令セットが、その機能どおりに実行されることをシミュレーションするのであれば問題はない。しかしながら、ＰＵＸ３に対し外部あるいはＶＵ１からのＩ／Ｏ５９が発生したときの処理を評価しようとすると、とたんに状態が不確かのものになる。すなわち、図４（ｂ）に示すように各命令セットは３つのパイプラインステージに分割され、部分的にオーバーラップしながらサイクル単位（クロック単位）で処理されている。そして、クロック単位で記述されるＩ／Ｏ５９が入ると、命令毎にＩ／Ｏ５９が発生するとしたときに図４（ａ）のモデルでは６つのタイミングしか記述できないのに対し、現実のプロセッサでは図４（ｂ）のモデルに示すように、８つのタイミングがあり得る。そして、それぞれのタイミングでその後の処理が変わる可能性がある。
【００３７】
たとえば、図５（ａ）に示す処理では、処理を開始した２サイクル目でＩ／Ｏからの入力信号５９が生じた場合の動作を示す。図５（ａ）では、１番目の命令Ｉ（１）の実行サイクル５２でＩ／Ｏ信号５９が入力され、２番目の命令Ｉ（２）で処理して、３番目の命令Ｉ（３）のＷＢサイクル５３で結果をＩ／Ｏ信号５９で出力する。これに対し、図５（ｂ）は、命令セットの単位のモデルであり、命令の先頭をＦ＆Ｄサイクル５１に合わせている。このケース１では、２番目の命令Ｉ（２）はＩ／Ｏ信号を捕らえることができないので、上記のような処理が実現されない。図５（ｃ）は、命令の先頭を実行サイクル５２に合わせたケース（ケース２）であり、１番目の命令を実行中にＩ／Ｏ信号５９を受けて、その結果として２番目および３番目の命令を通じてＩ／Ｏ信号５９を出力することができるが、３番目の命令で出力する信号のタイミングが異なる。図５（ｄ）は、命令の先頭をＷＢサイクル５３に合わせたケース（ケース３）であるが、２番目の命令Ｉ（２）はＩＯ信号５９の入力そのものを感知することができない。
【００３８】
このように、Ｉ／Ｏ信号５９や割り込みはすべてクロック同期またはクロックサイクルベース、すなわちパイプラインのサイクルベースで起動されるので、これらの信号を正しく取り扱うには、そのサイクルベースで命令が分解されてモデル化されている必要がある。そこで、本発明においては、図６に示すように、サイクル単位で管理することができるＩＳＳ本体６１を備えたシミュレータ６０を提供することにより、パイプラインのサイクルベース分解された命令モデルに基づくシミュレーションを行えるようにしている。すなわち、図７に示すように、従来のＩＳＳでは命令単位でその機能がＣ言語によりモデル化されていた。これに対し、本発明のシミュレータ６０では、命令セットＩをサイクル単位、すなわち、Ｆ＆Ｄ部５１と、実行部５２と、ＷＢ部５３とに分けてそれぞれのパイプラインステージをＣ言語によりモデル化する。そして、ＩＳＳ本体６１で各命令セットＩの各サイクルを評価しながらシミュレーションする。したがって、３段パイプラインＲＩＳＣを対象としたシミュレーションでは、１つのサイクルで常に３つの命令セットを評価することになる。このため、従来のＩＳＳよりもシミュレーション速度は低下する原因とはなるが、Ｃ言語のシミュレータによるアセンブラコードのシミュレーションではなく、そのアセンブラコードで記述されたアプリケーションプログラム４ａがハードウェア上で実際に動作する様子をシミュレーションすることができる。
【００３９】
ＩＳＳ本体６１でサイクル単位で命令モデルを管理する場合、図８に示すように、各命令セットの各パイプラインステージ毎に、その各命令セットの各ステージ毎に固有のＣ言語によるモデル（第１の情報）５７と、各命令セットの各ステージに共通のＣ言語によるモデル（第２の情報）５８とを記述しても良い。たとえば、共通のモデルとしてＩ／Ｏ信号に関するモデルを各サイクル毎に記述することにより、Ｉ／Ｏ信号による動作をサイクルバウンダリーに対し正しくシミュレーションすることができる。しかしながら、この方法では、共通部分である第２の情報の記述量が増えることになる。そこで、本例のシミュレータ６０においては、ＩＳＳ本体６１に、サイクル単位にシミュレーションを行うためのサイクル単位で時間を管理する機構６１ａと、Ｉ／Ｏ信号などに対する処理などのサイクルあるいはパイプラインステージに共通な第２の情報を記述した部分６１ｂと、その第２の情報に基づいて応答する機構６１ｃとを設けている。
【００４０】
さらに、命令セットＩが決まれば、その命令セットＩの各パイプラインステージ毎の固有のモデル（第１の情報）も決まる。したがって、本例のシミュレータ６０では、各命令セット毎に各パイプラインステージ毎のモデルを提供するＰＵ命令ライブラリ６２を設け、各命令の各パイプラインステージをＩＳＳ本体６１で管理可能なモデル、すなわち第１の情報に変換している。このため、シミュレータ６０に提供されるアプリケーションプログラムは命令セットの状態であるいが、シミュレーションはサイクル単位で分割して行うことができる。また、シミュレーションの対象となるモデルがサイクル単位で分割して記述されている場合でも、ＰＵ命令ライブラリ６２により、そのシミュレーションモデル自身が記述すべき量を削減できる。
【００４１】
このため、図６に示した本例のシミュレータ６０であれば、アセンブラコードで記述されたアプリケーションプログラム４ａに基づき、サイクル単位のシミュレータモデルをＰＵ命令ライブラリ６２を参照しながらＩＳＳ本体６１で構築し、サイクル単位で管理しながらシミュレーションを行うことができる。ＩＳＳ本体６１の負荷を低減して実行速度を速くするためには、命令セットであるアセンブラコードをパイプラインステージに分割された記述で表されたシミュレーションモデル６６に変換できるコンパイラあるいはコンパイラプログラム６５を用い、命令セットがサイクル単位で記述されたシミュレーションモデル６６を事前に用意しておくことが望ましい。
【００４２】
本例のシミュレータ６０は、さらに、ＶＵ命令により起動するＶＵ１における処理をＩＳＳ本体６１においてサイクル単位で管理可能な情報として提供するＶＵ命令ライブラリ６３を備えている。したがって、ＶＵ命令ライブラリ６３でＶＵ命令で消費されるサイクル数を定義することにより、上述したもう１つの問題、すなわち、画像処理やネットワーク処理において信号列の中から「ある特定のビットパターンを検出する」といったＶＵ命令が実行されたときに、その命令で使用あるいは消費されるサイクル数をあらかじめ知ることができないという問題を簡単に解決することができる。このため、本例のシミュレータ６０においては、ＰＵ命令はＰＵ命令ライブラリ６２から供給されるパイプラインステージ毎のモデルをサイクル単位で管理することによりサイクル単位でシミュレートでき、ＶＵ命令はＶＵ命令ライブラリ６３でＶＵ１において消費されるサイクル数がシミュレートできる。
【００４３】
したがって、本例のシミュレータ６０により、ＶＵＰＵ１０の内部におけるＶＵ１とＰＵ２とのＩ／Ｏあるいは割込み処理、さらには、外部とＩ／Ｏあるいは割込み処理などをサイクルあるいはクロック単位でＣ言語によりモデルで完全にシミュレートすることが可能となる。このため、高速でハードウェアの動作をシミュレートできるシミュレータを提供することが可能となる。
【００４４】
さらに、本例のシミュレータ６０は、ＰＵ命令ライブラリ６２と、ＶＵ命令ライブラリ６３とを別に設けている。ＰＵ命令ライブラリ６２は、ＶＵＰＵ１０を実現するときの埋め込みプロセッサとなる基本プロセッサＰＵＸ３における処理をサイクル単位で記述するためのライブラリであり、ほぼフィックスされたものとなる。
【００４５】
これに対し、ＶＵ命令ライブラリ６３は、ＶＵＰＵ１０で実現しようとするユーザの仕様によって可変なＶＵ１における処理が反映されるものであり、その都度、異なる可能性が高い。したがって、ＶＵ命令ライブラリ６３をユーザ単位で、あるいはユーザ自身が設計できるように分離することにより、シミュレータ６０に殆ど影響を与えずにユーザの仕様を組み込むことができる。このため、本例の構成により、ＶＵＰＵ１０をシミュレートできるシミュレータ６０を短期間に経済的に開発することができる。
【００４６】
また、本例のＶＵ命令ライブラリ６３は、Ｃ言語で記述されている仕様あるいはプログラムファンクションＣｓの部分をＣ＋＋言語に変換されたもの、あるいはそれがコンパイルされたものである。したがって、変数の型宣言を行うことにより、取り扱えるデータ長はバリアブルとなり、Ｃ言語で記述された際の冗長なビット長を削除することができる。このため、ＶＵ命令ライブラリ６３は、機能的にＶＵ１として実現するＲＴＬと置換可能なものとなる。したがって、より精度良く、実機に近い条件で、さらにＲＴＬシミュレータよりも高速でＶＵＰＵ１０をシミュレートすることができる。ＶＵ命令ライブラリ６３は、ＰＵ命令ライブラリ６２も同様であるが、ＩＳＳ本体６１がＣコンパイラあるいはＣ＋＋コンパイラを内蔵していれば、Ｃ言語あるいはＣ＋＋言語で記載されたライブラリでよく、ＩＳＳ本体６１がコンパイラを内蔵していないのであれば、事前にコンパイルしておく必要がある。
【００４７】
さらに、シミュレータ６０は、実際のプロセッサでは実行されない疑似（擬似）命令用のライブラリ６４を備えている。この疑似命令は主に評価用に利用され、取扱い上はＶＵ命令と同じであるので疑似ＶＵ命令（擬似ＶＵ命令）と称することにする。疑似ＶＵ命令は、シミュレーションの過程あるいは結果を評価するためにＩＳＳ本体６１にデータを入力したり、期待値を出力させたりする処理を規定するものであり、この間、ＶＵＰＵのシミュレーションをホールドする。すなわち、ＩＳＳ本体６１は、サイクル数のカウントを停止し、ゼロサイクルで疑似ＶＵ命令を実行する。この疑似命令ライブラリ６４は、ＰＵ命令のシミュレーションに対してゼロサイクルの専用命令として捉えることも可能であるので、シミュレータ６０の内部ではＶＵ命令ライブラリ６３と同等に取り扱われる。したがって、このシミュレータ６０はＶＵに加えて、デバック用の疑似ＶＵの機能が装着されているということができる。疑似ＶＵ命令は、実際のプロセッサ１０においても疑似ＶＵ命令として取り扱われるので、この疑似命令（Ｅ命令）をフェッチしたときはＰＵ２に対してはＮＯＰ命令が出力されるだけである。また、ＶＵ１は自己宛てのＶＵ命令ではないので、処理を行わない。したがって、シミュレーションが終了した後にあえて取り除かなくても良い命令となっている。
【００４８】
図９に、疑似ＶＵ命令を導入した場合の設計手法の概要を示してある。ここでも、Ｃ言語による全体記述３１の第３層（レイヤ３）と、サイクルベースのＩＳＳによるシミュレータ６０の第２層（レイヤ２）と、ＶＵＰＵ１０の第１層（レイヤ１）とに分けて考えることができ、Ｃ言語（レイヤ３）とＲＴＬによるＶＵＰＵ１０（レイヤ１）との間に、サイクルベースのＩＳＳ６１によるシミュレーション（レイヤ２）を導入できることによる効果を示している。本例では、Ｃ言語（ＡＮＳＩ−Ｃを想定）による全体記述３１には、テスト記述、即ちデータファイルの入力とか出力値と期待値との一致比較といった記述も含まれる。目視によるデバッグが有効であるのならば、グラフィック出力ルーチンといった機能も、このテスト機能あるいはデバッグ機能を定義するテスト記述に含められる。
【００４９】
このテスト記述Ｃｅの部分は、シリコンへの実装形態であるＶＵＰＵ１０にはマッピングされない部分であり、ＩＳＳでのみ実行される疑似ＶＵとして装着される部分である。疑似ＶＵ命令でカバーする範囲は、ＶＵ命令でカバーする範囲と同様に、Ｃ記述３１から抽出され、Ｃコンパイラ１００を介してコンパイルされて疑似ＶＵ命令ライブラリ６４あるいはオブジェクトとしてＩＳＳ本体６１が走行するシミュレータ６０に組み込まれる。したがって、疑似ＶＵ命令ライブラリ６４は、ＩＳＳ６１が走行する計算機環境上のＣコンパイラ１００の出力である。そして、ＰＵ命令でカバーされる範囲ＣｇとのインターフェイスＩＦｅが疑似ＶＵ命令となる。
【００５０】
ＰＵ命令で記述される範囲Ｃｇは、図２などで説明したように、基本プロセッサＰＵ２で走行する部分のＣ言語による記述であり、ＰＵ用のＣコンパイラ１０１によりコンパイルされてＩＳＳ６１で実行されるシミュレーションレベルのプログラム４ａとなる。このプログラム４ａがバイナリーに変換したものが、基本プロセッサＰＵがＲＴＬの形式にて提供された時に使用されることになる。すなわち、ＶＵＰＵ１０のオブジェクトプログラムとなる。
【００５１】
ＶＵ命令でカバーされる記述範囲Ｃｓは、全体記述３１から抽出された後に、これがビット冗長を持つときには、Ｃ記述をＣ＋＋記述に変換して変数の型宣言により（Class Libraryを使用して）ビット冗長を取り除き、最適なビット記述のライブラリ１０２とする。その後、Ｃ＋＋コンパイラ１０３でコンパイルしてシミュレータ６０に組み込まれるＶＵ命令ライブラリ６３を生成する。ＰＵ命令でカバーされる範囲ＣｇとのインターフェイスＩＦｓは、ＶＵ命令であり、これはＶＵＰＵ１０においても同様である。
【００５２】
また、ビット冗長を取り除いたＣ＋＋記述のライブラリ１０２はＣｔｏＲＴＬ動作合成ツール１０４の入力スタイルの規定にあったＣ言語に変換されて動作合成の入力となる。ＣｔｏＲＴＬツール１０４は、通常、変換されたＲＴＬを出力し、そのＲＴＬのサイクル数も出力するので、ＶＵ命令ライブラリ６３はレポートされたサイクル数も取り込み、ビット冗長を取り除いたＣ＋＋記述による機能にサイクル数を加えた情報を、ＩＳＳ本体６１に提供し、ＶＵ１を含めたサイクルベースのシミュレーションを可能とする。
【００５３】
このようにして設計を進めて行き、最後に生成されたＶＵ１のＲＴＬをＩＳＳ６１とリンクさせてシミュレーションすることも可能である。設計の最終段階における検証フェーズとして有効である。
【００５４】
図１０は、疑似ＶＵ命令を含めたＣ記述３１を分解してサイクルベースのＩＳＳシミュレーションを実行する過程を示してある。この図では、全体記述３１の一部が２つの疑似ＶＵ命令と、１つのＶＵ命令に置き換えられている。疑似ＶＵ命令に置き換えられたテスト記述３７の内容は、例えば、最初が入力ファイルをオープンしてテストデータを読み込む記述であり、次が、出力された結果と期待値との一致比較照合を取る記述である。また、ＶＵ命令に置き換えられた部分３３は、例えば、専用のハードウエアで処理することにより高速化を図りたい信号処理のＣ記述部分である。その他のＰＵ命令として実行される部分３４は、一般的なソフト処理対象となる記述であり、ＰＵ命令と、ＶＵ命令と、疑似ＶＵ命令とを含んだプログラム３２として生成される。したがって、ＰＵ用のコンパイラ１０１でコンパイルされて、その際、ＶＵ命令も疑似ＶＵ命令もアセンブラコールされているから、コンパイルされた結果はＰＵ命令とＶＵ命令（疑似含む）の混在リスト４ａとなり、ＩＳＳ本体６１に順次読み込まれて実行されることになる。
【００５５】
テスト記述３７はＩＳＳ６１でのみ実行される疑似ＶＵとして装備されることが望ましい。これらテスト記述は、シミュレーションおよびデバッグ上必要であるが、通常は、ハードウェア化する対象外だからである。従って、サイクル数はゼロを設定し、テスト機能のみをゼロサイクルで実行できる形態が望ましい。テスト記述３７は、ＩＳＳ６１が開発され、走行する計算機環境により決定されるコンパイラ１００でコンパイルされる。例えば、あるＯＳ上でＩＳＳ６１が走行しているのであれば、テスト記述は、そのＯＳにて走行するＣコンパイラ（例えばサン社のＯＳであればフリーウェアのｇｃｃがある）でコンパイルされ、ＩＳＳ６１に疑似ＶＵライブラリ６４として装着される。装着された疑似ＶＵライブラリ６４は、ＰＵ側からはＶＵ命令と同様に処理される疑似ＶＵ命令でコールされ、リターンされる。
【００５６】
専用命令としてハードウェア化されるＶＵ命令のＣ記述３３は、ＶＵＰＵプロセッサを開発する場でユーザが定義する命令であるが、上述した方法でライブラリ６３の形式で装着される。このようにして、疑似ＶＵ命令ライブラリ６４と、ＶＵ命令ライブラリ６３が用意されると、ＩＳＳ本体６１は、アセンブラ化されたコード４ａの命令セットを順番に読み込んで、ＰＵ命令であれば、予めサイクルモデルとして用意されているＰＵライブラリ６２を読み、ＶＵ命令であれば、ＶＵライブラリ６３を読み込んで、実行する。同様に疑似ＶＵ命令であれば、疑似ＶＵライブラリ６４を読み込んで実行する。
【００５７】
図１１に、シミュレータ６０を実現するためのプログラムにおける主な処理をフローチャートにより示してある。ＩＳＳ本体６１を実現するためのプログラムがスタートすると、ステップ７１でシミュレートする対象のアプリケーションプログラム４ａのｎ番目の命令セットを取得する。ステップ７９で、その命令セットＩが疑似ＶＵ命令であれば、ステップ７９ａで疑似ＶＵをスタートする処理を行う。疑似ＶＵはＩＳＳ本体６１だけで稼動するＶＵであるが、上述したように疑似ＶＵ命令ライブラリ６４を参照することによりデバック処理用の入出力あるいはその他の処理が行われる。
【００５８】
この疑似ＶＵの処理では、サイクルはカウントしないので、疑似ＶＵが終了すると、他のＶＵＰＵの状態をシミュレートする処理は行われず、ステップ７１に戻って次の命令をフェッチする。したがって、ＶＵ１あるいはＰＵ２の状態に影響を与えずに、それらの状態を評価することができる。そして、疑似ＶＵ命令をＶＵ命令およびＰＵ命令と同じレベルでプログラムコード４ａに挿入することができるので、シミュレーション上で評価する状態をプログラムレベルで規定することが可能である。このため、シミュレーションの評価を効率良く、容易に行うことができる。
【００５９】
ステップ７２で、その命令セットＩがＶＵ命令であれば、ステップ７３でＶＵ１をスタートする処理を行う。図１１に示すように、ＶＵ命令ライブラリ６３としての機能を提供するプログラムがＶＵ１におけるサイクルをカウントするだけのプログラムであれば、ステップ７３においては、そのカウンタ数Ｃをクリアしてカウントを開始する。
【００６０】
ＶＵ命令ライブラリ６３のプログラムは、カウンタ数Ｃを初期化するステップ９１と、カウント数Ｃをサイクルのタイミングでカウントアップするステップ９２と、カウント数ＣがＶＵ１における処理が完了するＣ０に達したことを判断するステップ９３を備えており、カウント中であればＶＵ１が稼動中であること示す情報をＩＳＳ本体６１に返すステップ９４と、カウントが終了していればＶＵ１が停止中である情報をＩＳＳ本体６１に返すステップ９５を備えている。したがって、ＩＳＳ本体６１のプログラムでは、ステップ７２に続いて、ステップ７４においてＶＵ命令ライブラリ６３に問い合わせることにより、そのサイクルにおけるＶＵ１の状況を管理することができる。
【００６１】
さらに、ＩＳＳ本体６１は、ステップ７５で取得した命令セットＩがＰＵ命令であれば、ステップ７６でそのｎ番目のＰＵ命令のＦ＆Ｄサイクルのモデル（第１の情報）をＰＵ命令ライブラリ６２に用意されているＣモデル８１から取得し、そのステージ固有のモデルを実行する。それと共に、それに関わる外部入出力やＶＵからの入出力などに対するステージに共通のモデル（第２の情報）を実行する。次に、ステップ７７で、ｎ−１番目のＰＵ命令の実行サイクルのモデルをＰＵ命令ライブラリ６２のＣモデル８１から取得し、そのステージ固有のモデルと、共通のモデルを実行する。さらに、ステップ７８で、ｎ−２番目のＰＵ命令のＷＢサイクルのモデルをＰＵ命令ライブラリ６２のＣモデル８１から取得し、そのステージ固有のモデルと、共通のモデルを実行する。これらステップ７６、７７および７８の処理の前後は問わない。またこれらの処理は並列に行われても良い。
【００６２】
このように、本例のシミュレータ６０においては、ＩＳＳ本体６１において、ｎ番目、ｎ−１番目およびｎ−２番目の命令セットの各パイプラインステージにおけるモデルを実行することにより、１つのサイクルのシミュレーションを行う。したがって、シミュレータ６０では、サイクル分解されたシミュレーションモデルをＩＳＳ本体６１においてサイクルベースでシミュレーションすることになり、従来のＲＴＬをベースとしたシミュレータと同等のサイクル単位での精度を維持しつつ、実行速度の速いＣ言語による高速シミュレーションが可能となる。このため、数百倍高速でハードウェアをシミュレーションできるシミュレータを提供することが可能となる。
【００６３】
さらに、ＩＳＳ本体６１として機能するシミュレーションプログラムに対し、命令セットの各パイプラインステージ毎に、そのパイプラインステージをシミュレートプログラムで管理可能な情報、すなわちモデルに変換する処理を提供するＰＵ命令ライブラリ６２のプログラムを設けてある。ライブラリプログラムを用いて、パイプラインステージをシミュレートする前に、そのパイプラインステージを管理するためのモデルを取得することができる。また、ライブラリプログラムを用意することにより、アプリケーションプログラムに記述する量を大幅に削減することが可能である。各パイプラインステージのモデルを取得する処理は、本例のように、各パイプラインステージのモデルを実行する直前に取得しても良いし、シミュレートする命令毎、あるいはシミュレートするサイクル毎に一括してモデルを取得することも可能である。あるいは、ライブラリから各パイプラインステージ毎のモデルをアプリケーションプログラム単位で取得してすべてのパイプラインの情報を含むシミュレーションモデルを事前に生成することも可能である。
【００６４】
さらに、本例のシミュレータ６０では、ＩＳＳ本体６１で各パイプラインステージに共通する処理に関するモデルを用意し、各パイプラインステージのモデルと共にサイクル単位で実行している。この方法によりステージ単位のモデルの記述を削減することができるが、共通の処理を含んだモデルをＰＵ命令ライブラリ６２として提供することも可能である。
【００６５】
そして、シミュレータ６０は、ＰＵ命令ライブラリ６２に加えて、ＶＵ命令ライブラリ６３を備えている。したがって、ＶＵＰＵ１０のようなデータパスに特化した専用処理部ＶＵ１を備えたプロセッサにおいて、ＶＵ１でＶＵ命令が消費するサイクル数がデータ依存であるような場合においても、ＶＵ命令で消費されるサイクル数をＶＵ命令ライブラリ６３でカウントしてＩＳＳ本体６１に通知することが可能である。したがって、ＶＵ１の状態もＩＳＳ本体６１においてサイクル単位で管理することができる情報に変換することができる。ＶＵ命令ライブラリ６３がシミュレートするＶＵ１の状態をＩＳＳ本体６１が知る方法は幾つかあり、ＩＳＳ本体６１がサイクル事象をＶＵ命令ライブラリ６３に通知することによりＶＵ命令ライブラリ６３の側でサイクル数のカウントを返したり、またはＶＵ１における処理が終了したことをＶＵ命令ライブラリ６３からＩＳＳ本体６１に通知するだけでも結果としてＶＵ１におけるサイクル数の管理を行うことができる。
【００６６】
たとえば、図１２に示したシミュレータ６０においては、ＶＵ命令ライブラリ６３が各サイクル毎のＶＵ１の状態をＩＳＳ本体６１に返すルーチン６３ａを備えている。したがって、ＩＳＳ本体６１の側でＶＵ１の状態をサイクル単位で監視し、終了までのサイクル数をカウントするなど方法でＶＵ１をサイクル単位で管理できる。このため、ＶＵ１の処理の終了情報だけをＶＵ命令ライブラリ６３からＩＳＳ本体６１に通知させ、サイクル数のカウントはＩＳＳ本体６１またはデータパス命令側であるＶＵ命令ライブラリ６３のどちらでもできることとなる。もちろん、ＶＵ命令ライブラリ６３からＩＳＳ本体６１に供給されるＶＵ１の状態は終了情報に限られる必要はなく、ＰＵ命令の処理に影響を及ぼすＶＵ１の処理の途中経過をＩＳＳ本体６１に通知してさらに精度の高いシミュレーションを行うことも可能である。また、図１２に示したシミュレータ６０では、疑似ＶＵ命令ライブラリを用意していないが、疑似ＶＵ命令ライブラリがない場合でも、サイクルベースのＩＳＳ６１によりＲＴＬモデルを用いなくても、それと等価のシミュレーションを数桁高速で行うことができることは変わりない。
【００６７】
図１３に、本発明による設計の手順詳細を示す。これらの手順を実行可能な手段あるいは処理を備えたシステムあるいはプログラムは、適当な計算機環境で動作する自動設計システムあるいは自動設計プログラムとして提供することが可能である。このため、本発明により、システムＬＳＩにおける、Ｃ言語あるいはＪＡＶＡ（登録商標）言語などの高級言語から自動設計システムの構築が可能となる。
【００６８】
最初の設計ステージ１１１では、初期の仕様を記載したＣ記述３１の出力期待値を作成しておき、後段の設計作業におけるテスト機能の元とする。この段階におけるコンパイラは、汎用のＣコンパイラ（ｇｃｃ）である。
【００６９】
次の設計ステージ１１２は、ＰＵへの移植である。Ｃ記述３１をＰＵ２（ＰＵＸ３）のＣコンパイラであるｐｃｃ１０１でコンパイルする。この際、ステップ１２１で出力期待値との比較照合のようなテスト記述を、疑似ＶＵ命令としてｐｃｃ１０１でコンパイルされるプログラムに装着させることが可能である。疑似ＶＵ命令は他の命令と共にｐｃｃ１０１でコンパイルされるが、疑似ＶＵ命令で実行させる機能（疑似ＶＵ）、すなわちテスト記述された機能は、汎用のコンパイラ（ｇｃｃ）１００でコンパイルし、疑似ＶＵライブラリを生成する。
【００７０】
こうして疑似ＶＵ命令により動作するテスト回路（疑似ＶＵ）を内蔵させたプログラム（Ｃ記述）を、ＩＳＳ６１を用いてステップ１２２で検証する。疑似ＶＵ命令によりテスト機能が移植されているので、正しくｐｃｃ１０１でコンパイルされるプログラムに移植が行われたか否かは直ちに判明する。この設計ステージ１１２では、ＩＳＳ６１がＩＳＳプロファイラとしてレポートする各Ｃソースコード上でのクロック消費数情報（ＩＳＳプロファイラ）から、どの部分をＶＵ化（即ちハードウェア化）して高速化を図るかを検討し判断する。
【００７１】
次の設計ステージ１１３は、ＶＵ１に適した部分の抽出とＶＵ化、すなわち、ＶＵ命令ライブラリの作成である。このため、ステップ１２３でＶＵ化する部分を抽出し、ステップ１２４でその部分をＶＵ命令に置き換え、ＶＵ命令、ＰＵ命令および疑似ＶＵ命令からなる、ｐｃｃ１０１でコンパイル可能なプログラムとする。一方、抽出した部分をステップ１２５でライブラリ化する。Ｃ言語のままでもＩＳＳ６１にて走行可能なＶＵ命令ライブラリは生成可能であるので、この段階でシミュレーションのステップ１２６を挿入しているが、必要がなければスキップして次の段階でのみシミュレーションするだけでも良い。なお、ステップ１２６でＶＵ命令ライブラリを利用するために使用するコンパイラは、汎用のＣコンパイラ、例えばｇｃｃである。この段階でも、疑似ＶＵ命令はテスト記述としてそのまま利用される。
【００７２】
設計ステージ１１４では、ステップ１２７でＣ＋＋言語を用いて冗長ビットを削除し、削除した結果のＣ＋＋のＶＵ命令ライブラリ６３をステップ１２８でシミュレータ６０に装着してＩＳＳ６１を走行させて消費サイクル数を確認する。その為には、ＶＵ１のサイクル数を知る必要があり、次の設計ステージ１１５を実行させてサイクル数を知り、ＶＵ命令ライブラリ６３にフィードバックをかける。この段階でも、疑似ＶＵ命令はテスト記述としてそのまま利用される。
【００７３】
上述したように、通常のＣ言語ではデータ長が、例えば３２ビットに取られ、３２ビット長の範囲内で仕様となるアルゴリズムの開発と検証が行われる。しかしながら、実際に稼動させるハードウエアシステムでは３２ビットは必要ない、といった場合が極めて多い。この場合には冗長を削除しないと、無駄なハードウェアを持った実行回路を生成してしまうことになる。したがって、この設計ステージ１１４で、Ｃ言語と異なる言語、ここではＣ＋＋言語にて冗長を取り除く事は極めて重要である。
【００７４】
加えて、冗長を取り除いたＣ＋＋言語のライブラリ６３で検証を行うことが重要である。冗長を取り除きすぎていないかどうかは、シミュレーションによって確認する必要があり、このステージ１１４でサイクルベースのＩＳＳ６１を用いて確認できる意義は極めて大きい。というのも、もし、サイクルベースのＩＳＳ６１がなければ、この確認はＲＴＬベースのシミュレーションにて行うしかなく、それはサイクルベースのＩＳＳ６１によるシミュレーションに比べ約１、０００倍時間がかかるシミュレーションだからである。
【００７５】
当初の仕様３１を最初からＣ＋＋言語として記述し、冗長を加味しない形式で最初から設計すればよい、との考え方もある。それもひとつの考え方であるが、次のようなデメリットがある。まず、オブジェクト指向の言語であるＣ＋＋言語と通常の手続き型言語であるＣ言語とでは、生成されるオブジェクトのサイズに違いがでる。つまり、オブジェクト指向言語のオブジェクトサイズは通常に比べ３０〜５０％くらい大きくなってしまう欠点がある。これは、ＰＵ化するプログラム、すなわち、ＰＵコンパイラ１０１でコンパイルする部分のオブジェクトサイズが非常に大きくなってしまうことになる。
【００７６】
ＶＵＰＵ１０のような、組み込み型のプロセッサにとっては、シリコン上のメモリサイズをいかに小さくするかが、コストと消費電力上極めて重要な要因となり、この点、Ｃ言語で初期設計する設計方法のメリットは大きい。これに対し、ＶＵ化される記述は、ハードウェアとなるので、たとえＣ＋＋言語を経由したとしても前に述べたようなオブジェクトサイズの増大には繋がらない。むしろ、型変換を通じて冗長なビット長が削除できた状態でシミュレーションできるメリットが大きい。
【００７７】
次の設計ステージ１１５は、ＣｔｏＲＴＬツールによる動作合成である。ＩＳＳシミュレーションにより検討されたＣ＋＋言語のライブラリ６３を、ステップ１２９で動作合成可能なＣ記述に変換し、ステップ１３０で合成をかける。結果としてＲＴＬとサイクル数がレポートされるので、サイクル数は、上述したように上流のＩＳＳシミュレーション（ステップ１２８または１２６）へフィードバックする。このステージ１１５でレポートされるサイクル数まで埋め込んだＶＵライブラリ６３はＣｔｏＲＴＬ動作合成ツールにて生成されたＲＴＬと置換可能なものになる。
【００７８】
設計ステージ１１６は、最終段階であり、ＶＵ１のＲＴＬと、ＰＵ命令、ＶＵ命令および疑似ＶＵ命令が含まれるプログラムとを、ステップ１３１でＩＳＳ６１を使用して混合あるいは協調シミュレーションし、できあがったＶＵ１のＲＴＬの最終的な検証を行う。通常、このシミュレーションにおいては、親はＲＴＬとなる。即ち、親となるＲＴＬを起し、子となるＩＳＳと、子となるＶＵ部のＲＴＬを親のレベルで接続させてシミュレーションを行うことも可能である。この段階のシミュレーションは、ＲＴＬが含まれるのでシミュレーション速度は低下する。しかしながら、最終確認を行う意味で一回検証する意味はある。加えて、ＩＳＳ６１ではプログラムに組み込まれている疑似ＶＵ命令がそのまま動作するので、テスト環境は同一のものが使用できるメリットがある。
【００７９】
最終的に動作が確認されたＶＵ１のＲＴＬは、ステップ１３２で論理合成され、ステップ１３３でネットリストとして出力されシリコン化（回路化）される。
【００８０】
このように、上記の一連のステージでは、ＩＳＳ６１を用いて何段階かのシミュレーション（ステップ１２２、１２６、１２８および１３１）を繰り返しているが、最初のステージ１１１のステップ１２１で導入された疑似ＶＵ命令によるテスト記述、特に期待値照合といった機能がシミュレートされるプログラムに装着されたまま、ＲＴＬの最終検証のフェーズであるステージ１１６まで活かされる。したがって、この複数のシミュレーション段階を備えた設計方法において、同一のテスト記述が設計段階の最初から最後まで利用できることは、各ステージですこしづつ変化していく実装の形態を検証する上で極めて有効であり、大きく回路を間違えて設計を押しすすめる心配がないという大きなメリットがある。
【００８１】
なお、上記では本発明に係るシミュレーション方法をシミュレーションプログラムで実現可能なシミュレータ６０に基づき説明しているが、ハードワイヤードロジックなどの他の実現手段で本発明のシミュレーション方法を実行することも可能である。しかしながら、本発明のシミュレーション方法は、Ｃ言語あるいはＪＡＶＡ（登録商標）などの他の高級言語で記述された高速実行可能なシミュレーションプログラムとして提供できることが重要であり、ＣＤ−ＲＯＭなどの適当な記録媒体に記録されたり、インターネットなどのコンピュータネットワークを介して提供される本発明に係るシミュレーションプログラムをパーソナルコンピュータやワークステーションなどの適当なハードウェア資源にインストールすることによりＶＵＰＵ１０の機能を高速でシミュレートすることができる。
【００８２】
ＶＵＰＵ１０は、汎用的なプロセッサであるＰＵと、専用回路化したＶＵとを備えており、全ての仕様を専用回路化する従来のカスタムＬＳＩと比較すると、短期間に低コストで従来と同等以上の性能のカスタムＬＳＩを提供できるものであり、本発明のシミュレータを採用することにより、さらに開発期間を短縮することができる。また、本発明のシミュレータは、ＶＵＰＵに限らず、汎用的なプロセッサの設計開発、あるいはプロセッサで実行する全てのプログラム（本明細書ではアプリケーションプログラムと称している）の設計開発にも適用可能なものであり、シミュレーションの精度を向上し、シミュレーションの期間を短縮することができる。
【００８３】
【発明の効果】
以上に説明したように、本発明においては、命令セットをパイプラインサイクルに分解したモデルでシミュレートすることができるサイクルベースのＩＳＳ本体を備えたシミュレータを提供しており、Ｃ言語などの高級言語で記述された高速実行可能なシミュレータによりサイクルベースでハードウェアのシミュレーションを行うことができる。したがって、本発明のシミュレーション方法により、精度は従来のＲＴＬベースのシミュレータと同等に、サイクル単位を維持しつつ、シミュレーション速度を数百倍から数千倍高速にできるシミュレータあるいはシミュレータとしての機能を有するデータ処理システムを提供できる。したがって、本発明によりプロセッサの設計期間を大幅に短縮でき、設計品質も向上する。したがって、設計物のコスト競争力に極めて多大な効果を発揮する。
【００８４】
さらに、本発明のシミュレーション方法では、ＶＵＰＵのようなデータパスに特化した専用処理部を備えたプロセッサにおいても、専用処理部で専用命令が消費するサイクル数をライブラリという形でサイクル単位でカウントして管理することが可能であり、サイクルベースでのハードウェアシミュレーションが可能となる。
【００８５】
さらに、プロセッサでは実行されない疑似ＶＵ命令、特にゼロサイクルの疑似ＶＵ命令を導入することにより、評価および検証に有効なテスト回路を疑似ＶＵ命令として初期設計段階から最終のＲＴＬ生成段階まで利用できる。また、ＶＵ命令による処理をライブラリ化することにより、そのライブラリを他の言語、上記ではＣ＋＋で変換して冗長ビットの削減を極めて簡単に行うことが可能となる。そして、本発明のシミュレータは、サイクルベースのＩＳＳであるので、最終段階で生成されたＲＴＬとも接続させてシミュレーションすることが可能であり、最終検証までをフォローすることができる。
【図面の簡単な説明】
【図１】ＰＵおよびＶＵを備えたデータ処理装置（ＶＵＰＵ）の概要を示す図である。
【図２】Ｃ言語により記述された仕様に基づきＶＵＰＵを開発する様子を示す図である。
【図３】命令セットをパイプラインステージに分けて実行する様子を示す図である。
【図４】命令セットを命令単位で評価する場合と、パイプラインステージに分けてサイクル単位で評価する場合を示す図である。
【図５】命令セットを命令単位で評価する場合の幾つかのケースを、サイクル単位で評価する場合と比較して示す図である。
【図６】本発明のシミュレータの概要を示す図である。
【図７】命令セットのモデルを、命令単位のモデルと、パイプラインステージ単位のモデルにした場合とを比較して示す図である。
【図８】パイプラインステージ単位のモデルをステージ個別のモデルと、共通のモデルとに分けて示した図である。
【図９】疑似ＶＵ命令を導入した設計手法の概要を示す図である。
【図１０】疑似ＶＵ命令を導入してＣ言語により記述された仕様に基づきＶＵＰＵを開発する様子を示す図である。
【図１１】図６に示したシミュレータのＩＳＳ本体およびライブラリとしての機能を示すフローチャートである。
【図１２】本発明の異なるシミュレータの例を示す図である。
【図１３】本発明に係る設計手順の概要を示す図である。
【符号の説明】
１    専用処理ユニット（ＶＵ）
２    汎用処理ユニット（ＰＵ）
３    汎用プロセッサ（ＰＵＸ）
４    コードＲＡＭ
４ａ    アプリケーションプログラム
５    フェッチユニットＦＵ
１０    データ処理装置（ＶＵＰＵ）
１１    実行ユニット
６０    シミュレータ
６１    ＩＳＳ本体
６２    ＰＵ命令ライブラリ
６３    ＶＵ命令ライブラリ
【図１】
0004152659.tif 000002
【図２】
0004152659.tif 000003
【図３】
0004152659.tif 000004
【図４】
0004152659.tif 000005
【図５】
0004152659.tif 000006
【図６】
0004152659.tif 000007
【図７】
0004152659.tif 000008
【図８】
0004152659.tif 000009
【図９】
0004152659.tif 000010
【図１０】
0004152659.tif 000011
【図１１】
0004152659.tif 000012
【図１２】
0004152659.tif 000013
【図１３】
0004152659.tif 000014