(57)【要約】【課題】例えばシステム・オン・チップ（ＳｏＣ）設計の上流段階における各種モデルを、互換性を保ちながら、同一動作を保証できる形式で、段階的に生成可能とする。【解決手段】リファレンスソース内のＳＷ側とＨＷ側が分離され、ＳＷ側がＨＷ側を呼ぶためのＦＷ−ＩＦと、ＦＷ−ＩＦからの呼び出しに対応してＨＷ側の関数や変数へのアクセスを可能とするＨＷ−ＩＦとを備えるマージモデルを生成する手順と、ＳＷ側とＦＷ−ＩＦを実現するＣＰＵモデルと、ＨＷ側を実現するＨＷモデルと、ＣＰＵモデルとＨＷモデルを接続するＨＷ−ＩＦとを備えるＳｏＣモデルを生成する手順とを計算機に実行させる。【選択図】図１
2007310449.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェア／ハードウェア協調設計を行う計算機によって使用されるプログラムであって、
アプリケーション・ソフトウェアとしてのリファレンスソース内のソフトウェア側とハードウェア側とが分離され、前記ソフトウェア側が前記ハードウェア側を呼ぶためのファームウェア・インターフェースと、前記ファームウェア・インターフェースからの呼び出しに対応して前記ハードウェア側の関数または変数へのアクセスを可能とするハードウェア・インターフェースとを備えるマージモデルを生成する手順と、
前記マージモデル内の前記ソフトウェア側と前記ファームウェア・インターフェースとを命令レベルで実行できるシミュレータとしての中央処理装置モデルと、前記ハードウェア側に対応するハードウェアモデルと、前記中央処理装置モデルと前記ハードウェアモデルとを接続する前記ハードウェア・インターフェースとを備えるシステム・オン・チップモデルを生成する手順と
を計算機に実行させることを特徴とするソフトウェア／ハードウェア協調設計のためのモデル生成プログラム。
【請求項２】
前記システム・オン・チップモデルを生成する手順に先立って、
前記中央処理装置モデルを第１の中央処理装置モデルとするとき、前記マージモデルをソフトウェアとして命令レベルで実行できるシミュレータとしての第２の中央処理装置モデルを生成する手順をさらに計算機に実行させることを特徴とする請求項１記載のソフトウェア／ハードウェア協調設計のためのモデル生成プログラム。
【請求項３】
前記マージモデルを生成する手順に先立って、
前記マージモデルを第２のマージモデルとするとき、前記リファレンスソース内のソフトウェア側とハードウェア側とが分離され、前記ソフトウェア側が前記ハードウェア側を呼ぶためのファームウェア・インターフェースを備える第１のマージモデルを生成する手順をさらに計算機に実行させることを特徴とする請求項１記載のソフトウェア／ハードウェア協調設計のためのモデル生成プログラム。
【請求項４】
前記システム・オン・チップモデルを生成する手順の後に、
前記中央処理装置モデル、前記ハードウェアモデルのそれぞれを、現に記述されている言語と異なる言語を用いるシステムで利用するための前処理を行い、前記ハードウェア・インターフェースに相当し、前記異なる言語で記述されたインターフェースによって前記前処理済みの中央処理装置モデルと前記ハードウェアモデルとを接続した性能モデルを生成する手順をさらに計算機に実行させることを特徴とする請求項１記載のソフトウェア／ハードウェア協調設計のためのモデル生成プログラム。
【請求項５】
前記システム・オン・チップモデルを生成する手順の後に、
前記中央処理装置モデル、前記ハードウェアモデルのそれぞれを、現に記述されている言語と異なる言語を用いるシステムで利用するための前処理を行い、前記ハードウェア・インターフェースに相当し、さらに前記異なる言語で記述されたハードウェア側のインターフェースとソフトウェア側のインターフェース、および前記２つのインターフェースを結ぶバスのモデルとを用いて、前記前処理済みの前記中央処理装置モデルと前記ハードウェアモデルとを接続したバス有り性能モデルを生成する手順をさらに計算機に実行させることを特徴とする請求項１記載のソフトウェア／ハードウェア協調設計のためのモデル生成プログラム。
【請求項６】
ソフトウェア／ハードウェア協調設計を行う計算機によって使用されるプログラムであって、
アプリケーション・ソフトウェアとしてのリファレンスソース内のソフトウェア側とハードウェア側とが分離され、前記ソフトウェア側が前記ハードウェア側を呼ぶためのファームウェア・インターフェースを備えるマージモデルを生成する手順と、
前記マージモデルと、前記ファームウェア・インターフェースからの呼び出しに対応して前記ハードウェア側の関数または変数へのアクセスを可能とするハードウェア・インターフェースとを、ソフトウェアとして命令レベルで実行できるシミュレータとしての中央処理装置モデルを生成する手順とを計算機に実行させることを特徴とするソフトウェア／ハードウェア協調設計のためのモデル生成プログラム。
【請求項７】
前記中央処理装置モデルを生成する手順の後に、
前記中央処理装置モデルを第１の中央処理装置モデルとするとき、
前記第１の中央処理装置モデル内の前記ソフトウェア側と前記ファームウェア・インターフェースとを命令レベルで実行できるシミュレータとしての第２の中央処理装置モデルと、
前記ハードウェア側に対応するハードウェアモデルと、
前記第２の中央処理装置モデルと前記ハードウェアモデルとを接続する前記ハードウェア・インターフェースと
を備えるシステム・オン・チップモデルを生成する手順
をさらに計算機に実行させることを特徴とする請求項６記載のソフトウェア／ハードウェア協調設計のためのモデル生成プログラム。
【請求項８】
ソフトウェア／ハードウェア協調設計を行う計算機によって使用されるプログラムであって、
アプリケーション・ソフトウェアとしてのリファレンスソース内のソフトウェア側とハードウェア側とが分離され、前記ソフトウェア側が前記ハードウェア側を呼ぶためのファームウェア・インターフェースと、前記ファームウェア・インターフェースからの呼び出しに対応して前記ハードウェア側の関数または変数へのアクセスを可能とするハードウェア・インターフェースとを備えるマージモデルを生成する手順と、
前記ソフトウェア側、前記ハードウェア側、前記ファームウェア・インターフェース、および前記ハードウェア・インターフェースを、現に記述されている言語と異なる言語を用いるシステムで利用するための前処理を行い、前記前処理済みのファームウェア・インターフェースと前記前処理済みハードウェア・インターフェースとを、さらに前記異なる言語で記述されたインターフェースによって接続した性能マージモデルを生成する手順とを計算機に実行させることを特徴とするソフトウェア／ハードウェア協調設計のためのモデル生成プログラム。
【請求項９】
ソフトウェア／ハードウェア協調設計を行う計算によって使用されるプログラムであって、
アプリケーション・ソフトウェアとしてのリファレンスソース内のソフトウェア側とハードウェア側とが分離され、前記ソフトウェア側が前記ハードウェア側を呼ぶためのファームウェア・インターフェースと、前記ファームウェア・インターフェースからの呼び出しに対応して前記ハードウェア側の関数または変数へのアクセスを可能とするハードウェア・インターフェースとを備えるマージモデルを生成する手順と、
前記ソフトウェア側、前記ハードウェア側、前記ファームウェア・インターフェース、および前記ハードウェア・インターフェースを、現に記述されている言語と異なる言語を用いるシステムで利用するための前処理を行い、前記ファームウェア・インターフェースに接続され、さらに前記異なる言語で記述された第１のインターフェースと、前記ハードウェア・インターフェースに接続され、さらに前記異なる言語で記述された第２のインターフェースとの間を、前記異なる言語で記述されたバスのモデルによって接続したバス有り性能マージモデルを生成する手順とを計算機に実行させることを特徴とするソフトウェア／ハードウェア協調設計のためのモデル生成プログラム。
【請求項１０】
ソフトウェア／ハードウェア協調設計を行うために必要なモデルの生成方法であって、
アプリケーション・ソフトウェアとしてのリファレンスソース内のソフトウェア側とハードウェア側とが分離され、前記ソフトウェア側が前記ハードウェア側を呼ぶためのファームウェア・インターフェースと、前記ファームウェア・インターフェースからの呼び出しに対応して前記ハードウェア側の関数または変数へのアクセスを可能とするハードウェア・インターフェースとを備えるマージモデルを生成し、
前記マージモデル内の前記ソフトウェア側と前記ファームウェア・インターフェースとを命令レベルで実行できるシミュレータとしての中央処理装置モデルと、前記ハードウェア側に対応するハードウェアモデルと、前記中央処理装置モデルと前記ハードウェアモデルとを接続する前記ハードウェア・インターフェースとを備えるシステム・オン・チップモデルを生成することを特徴とするソフトウェア／ハードウェア協調設計のためのモデル生成方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、あるアプリケーションを実行するための大規模集積回路の設計方式に係り、さらに詳しくは、そのアプリケーションのソフトウェアとしてのリファレンスソースから、設計において用いるための各種のモデルを、同一の動作を保証する形式で段階的に生成するためのモデル生成プログラム、およびモデル生成方法に関する。
【背景技術】
【０００２】
最近では１つのアプリケーション、例えばＨ．２６４方式の画像処理を実現するためのＬＳＩとして、ＣＰＵとユーザ・ハードウェアとを１つのチップ上に搭載するシステム・オン・チップ（ＳｏＣ）が広く用いられるようになっている。
【０００３】
このような画像処理を実現する場合にはデータの演算量が膨大となり、処理速度を向上させるためには、大量のデータ処理はハードウェアによって実現し、ＣＰＵには時間管理などの制御動作などを分担させるほうが効率的となる。そこでどの処理をハードウェアに分担させ、またどの処理をソフトウェアに分担させるかというＳＷ／ＨＷ分割を適切に決定するために、ソフトウェア／ハードウェア協調設計と呼ばれる設計手順が用いられている。
【０００４】
図３４は、このようなＳｏＣの開発における上流設計のフローチャートの従来例である。同図においては、顧客要求に対応して概念モデルに対応する仕様書、機能モデルに対応する仕様書、性能モデルに対応する仕様書が作成され、それらの仕様書に基づいて実際の設計モデルとしてのＣ／Ｃ＋＋モデル、機能モデル、および性能モデルが生成され、ＲＴＬ（レジスタ・トランスファー・レベル）レベルの設計が行われていた。なお、これらの仕様書をオブジェクト指向分析設計の標準的な表記言語としてのＵＭＬ（ユニファイド・モデリング・ランゲージ）を用いて記述することも当然可能である。
【０００５】
従来においては、前述のソフトウェア／ハードウェア分割は、例えばアプリケーションに対応する概念モデルの段階で行われ、分割されたソフトウェアブロックとハードウェアブロックの間のインターフェースはその時点で決定されている必要があった。そして概念モデルに対応する仕様書から、例えばＣ／Ｃ＋＋モデルが作成され、機能モデルに対応する仕様書から機能モデルとしてのＣ／Ｃ＋＋モデル、あるいはＳｙｓｔｅｍ  Ｃモデルが生成されていた。この機能モデルは、時間的要素を考慮せずに最も高いレベルで機能が抽出されたアンタイムド・ファンクション・モデル（ＵＴ）である。そして性能モデルに対応する仕様書から性能モデルとしてのＳｙｓｔｅｍ  Ｃモデルが作成されていた。この性能モデルは、各機能ブロックの動作順序やタイミングの関係などが抽出されたタイムド・ファンクション・モデル（ＴＦ）である。
【０００６】
しかしながらこのような従来技術においては、設計に利用される具体的なモデルが各段階の仕様書に基づいて作成されるために、モデルの間の互換性を維持することができず、必ずしも同一の動作が保証されないという問題点があった。例えば、アンタイムド・ファンクション・モデルとしてのＣ／Ｃ＋＋モデルと、タイムド・ファンクション・モデルとしてのＳｙｓｔｅｍ  Ｃモデルとの間の接続ができていないために、必ずしも同一の動作がこれらのモデルに対して保証されないという問題点があった。
【０００７】
このようなソフトウェア／ハードウェア協調設計などに関する従来技術としての特許文献１では、設計の制約を満たすことができず、ハードウェアによる実現の指定を変更する場合に、どの機能ブロックの指定を変更すればハードウェア量を効果的に削減することができるか、あるいは処理時間を効果的に短縮できるかが容易に判定できる設計方式が開示されている。
【０００８】
また特許文献２では、上位設計の段階においてハードウェアとソフトウェアをつなぐバスの処理レートに対するバストラフィックを算出し、バスの性能評価を行うことができる性能評価方法が開示されている。
【０００９】
しかしながらこのような従来技術を用いても、上流設計において用いられる各種のモデルの互換性を保ち、同一動作を保証することができないという問題点を解決することはできなかった。
【特許文献１】特開平９−８１６０４号公報「ソフトウェア／ハードウェア協調設計システム及びその設計方法」
【特許文献２】特開２００１−３４４２８７号公報「アルゴリズム記述におけるバスの性能評価方法
【発明の開示】
【発明が解決しようとする課題】
【００１０】
本発明の課題は、上述の問題点に鑑み、例えばあるアプリケーションに特化したシステム・オン・チップの上流設計において、モデル間の互換性を保ちながら、同一の動作を保証することができる各種のモデルを段階的に生成し、そのモデルを利用したツールによってシステム・オン・チップの設計を容易にすることである。
【課題を解決するための手段】
【００１１】
図１は、本発明のソフトウェア／ハードウェア協調設計のためのモデル生成プログラムの原理的な機能ブロック図である。本発明の実施形態においては、機能モデル、および性能モデルとして多くの種類のモデルが生成されるが、それらのモデルの全てを段階的に生成する必要はなく、最も基本的なモデルの生成順序を図１（ａ）、および（ｂ）の２つとして、課題を解決するための手段を説明する。
【００１２】
図１（ａ）においては、まずステップＳ１でアプリケーション・ソフトウェアとしてのリファレンスソース内のソフトウェア側とハードウェア側とが分離され、ソフトウェア側がハードウェア側を呼ぶためのファームウェア・インターフェースと、ファームウェア・インターフェースからの呼び出しに対応してハードウェア側の関数や変数へのアクセスを可能とするハードウェア・インターフェースを備えるマージモデルを生成する手順が、またステップＳ２でそのマージモデル内のソフトウェア側とファームウェア・インターフェースとを命令レベルで実行できるシミュレータとしての第１の中央処理装置モデルと、ハードウェア側に対応するハードウェアモデルと、第１の中央処理装置モデルとハードウェアモデルとを接続するハードウェア・インターフェースとを備えるシステム・オン・チップモデルを生成する手順とが計算機によって実行される。
【００１３】
発明の実施の形態においては、ステップＳ１とステップＳ２の間に、前述のマージモデルをソフトウェアとして命令レベルで実行できるシミュレータとしての第２の中央処理装置モデルを生成する手順がさらに実行される。
【００１４】
図１（ｂ）においては、ステップＳ６でアプリケーション・ソフトウェアとしてのリファレンスソース内のソフトウェア側とハードウェア側が分離され、ソフトウェア側がハードウェア側を呼ぶためのファームウェア・インターフェースを備えるマージモデルが生成され、ステップＳ７でそのマージモデルと、ファームウェア・インターフェースからの呼び出しに対応してハードウェア側の関数や変数へのアクセスを可能とするハードウェア・インターフェースとをソフトウェアとして命令レベルで実行できるシミュレータとしての中央処理装置モデルを生成する手順が実行される。
【００１５】
発明の実施の形態においては、さらにステップＳ８で前述の中央処理装置モデルを第１の中央処理装置モデルとするとき、第１の中央処理装置モデル内のソフトウェア側とファームウェア・インターフェースとを命令レベルで実行できるシミュレータとしての第２の中央処理装置モデルと、ハードウェア側に対応するハードウェアモデルと、第２の中央処理装置モデルとハードウェアモデルとを接続するハードウェア・インターフェースとを備えるシステム・オン・チップモデルを生成する手順がさらに実行される。
【００１６】
以上のように本発明においては、例えばシステム・オン・チップの上流設計段階において、各種のモデルが互換性が保たれ、同一の動作が保証される形式で段階的に生成され、それらのモデルを利用して設計が行われる。
【発明の効果】
【００１７】
本発明によれば、例えばシステム・オン・チップの上流設計段階において、マージモデル、中央処理装置モデル、システム・オン・チップモデルなど各種のモデルが、モデル間の互換性を保ち、同一の動作が保証される形式で必要に応じて段階的に生成され、それらのモデルを用いた設計が可能となる。
【発明を実施するための最良の形態】
【００１８】
図２は、本発明における機能モデルの段階的な生成方式の説明図である。同図においては、（ａ）モデルとしてのリファレンスソースから、機能モデルが段階的に生成される。ここでリファレンスソースは、リファレンス（Ｒｅｆ）のソースであり、そのコードをリファレンスコードと呼ぶ。本実施形態では、例えばＭＰＥＧ４の規格を満たすアプリケーションとしてのＭＰＥＧ  ＣＯＤＥＣを開発するような場合を対象として発明の実施形態を説明するために、このようなアプリケーションをリファレンスと呼ぶことにする。
【００１９】
図２においては、（ａ）モデルとしてのリファレンスソースから最終的に（ｅ）モデル、すなわちシステム・オン・チップ（ＳｏＣ）モデルが生成される過程をモデリングとして説明する。最終的な（ｅ）モデルはＣＰＵ＋ＨＷモデルとも呼ばれ、このモデルをソフトウェア開発ツールのシミュレータとして組み込むことが可能である。
【００２０】
図２において、まず（ａ）モデルから（ｂ）モデル、または（ｃ）モデルが生成される。（ｂ）モデルはＲｅｆ（ＨＷ＋ＳＷ）モデルとも呼ばれ、リファレンス、すなわちＲｅｆ１をソフトウェア（ＳＷ）側とハードウェア（ＨＷ）側とに、ファームウェア・インターフェース（ＦＷ−ＩＦ）によって分割したモデルである。一般的にシステム・オン・チップ（ＳｏＣ）の設計においては、アプリケーションの実行に必要な処理をどのようにソフトウェア側とハードウェア側とに分割するかが、処理効率を向上させるために非常に重要な問題となる。例えば画像処理などにおいては、大量の画像データを演算したりする処理では、ソフトウェアよりもハードウェアによる処理が高速であり、ソフトウェア側は、例えば時間管理などの制御的な動作を実行する方が効率的となる。いずれにせよ全体の処理をソフトウェア側とハードウェア側とにどのように分割するかは難しい問題であるが、本発明においてはこの分割はすでに決定されているものとして発明の実施形態を説明する。
【００２１】
（ｂ）モデル、すなわちＲｅｆ（ＨＷ＋ＳＷ）モデルでは、ハードウェア側に属する変数、および関数がＲｅｆ（ＨＷ側）３として、ファームウェア・インターフェース（ＦＷ−ＩＦ）４によってＲｅｆ（ＳＷ側）２と分離される。Ｒｅｆ（ＳＷ側）２が、ＦＷ−ＩＦ４のインターフェース関数を呼び出すことによってハードウェア側の関数や変数の処理が行われる。
【００２２】
なおこのようにアプリケーションをソフトウェア側とハードウェア側とに分け、インターフェースによってそれらを接続したモデルを、本実施形態ではマージモデルと呼ぶことにするが、次の（ｃ）モデルもマージモデルであり、（ｂ）モデルを第１のマージモデルと呼ぶことにする。
【００２３】
（ｃ）モデルはＲｅｆ−ＳＷ＋Ｒｅｆ−ＨＷモデルとも呼ばれ、（ｂ）モデルにさらにハードウェア・インターフェース（ＨＷ−ＩＦ）５が追加されたものである。ここでＨＷ−ＩＦ５は、ハードウェア側からメモリやレジスタにアクセスするためのインターフェースであり、また前述のＦＷ−ＩＦ４は、プログラムなどのソフトウェアからメモリやレジスタにアクセスするためのインターフェースである。
【００２４】
すなわち（ｃ）モデル（第２のマージモデル）では、（ｂ）モデルにおけるハードウェア側の関数や変数にアクセスするためのＨＷ−ＩＦ５が定義され、ＦＷ−ＩＦ４がＨＷ−ＩＦ５のアプリケーション・プログラム・インターフェース（ＡＰＩ）関数を呼ぶことにより、ハードウェアへのアクセスであるものと判断され、そのＡＰＩ関数がＲｅｆ（ＨＷ側）３の関数の呼び出しや変数へのアクセスを可能とする。Ｒｅｆ（ＳＷ側）２がＦＷ−ＩＦ４というインターフェースを用いてハードウェア側をコールすることになるが、これがドライバの原型である。
【００２５】
（ｃ）モデルを用いることによってソフトウェア側とハードウェア側とを完全に分離することができ、ソフトウェア側をＣＰＵ上にのせてアルゴリズムの変更など、さらにソフトウェアのチューニングを行うことができる。本実施形態では、このようなチューニングによって、リファレンスソースから変更されたソフトウェアをファームウェア（ＦＷ）と呼ぶことにする。変更がない場合には、これを前述のようにＲｅｆ（ＳＷ側）のままとすることもできる。
【００２６】
なおここで（ｃ）モデルが（ｂ）モデルにハードウェア・インターフェース（ＨＷ−ＩＦ）５が追加されたものとして説明したが、（ｃ）モデルを（ｂ）モデルから生成する代わりに、（ａ）モデルのリファレンスソースから直接に生成することも可能である。すなわち（ｃ）モデルとしての第２のマージモデルを、（ｂ）モデルとしての第１のマージモデルから生成する代わりに、（ａ）モデルのリファレンスソースから直接に生成することも可能である。
【００２７】
（ｄ）モデルはＣＰＵモデルとも呼ばれ、（ｂ）モデル、すなわちＲｅｆ（ＨＷ＋ＳＷ）モデル、または（ｃ）モデル、すなわちＲｅｆ−ＳＷ＋Ｒｅｆ−ＨＷモデルをソフトウェアとしてロードし、動作確認を行うためのモデルである。このＣＰＵモデルでは（ｂ）、（ｃ）モデルのＲｅｆ（ＳＷ側）２として独自のアセンブラを使うこともでき、このためにそのソフトウェアをファームウェアＦＷ（ＳＷ側）６と解釈することもできる。なおＣＰＵモデルは、プログラムを命令レベルで実行できるシミュレータ、例えばインストラクション・セット・シミュレータ（ＩＳＳ）を指すものと考えることもできる。
【００２８】
（ｅ）モデルは、ＣＰＵ＋ＨＷモデル、あるいはシステム・オン・チップ（ＳｏＣ）モデルとも呼ばれる。このモデルは、（ｄ）のＣＰＵモデルから、あるいは（ｃ）モデル、すなわちＲｅｆ−ＳＷ＋Ｒｅｆ−ＨＷモデルから直接に生成することができる。このモデルでは、ソフトウェア、あるいはファームウェアとしてのＦＷ（ＳＷ側）６とＦＷ−ＩＦ４で構成されるＣＰＵモデル８が、ＨＷ−ＩＦ５によってＨＷモデル９と接続される。ＨＷ−ＩＦ５は後述するように、ＳｏＣ全体のメモリ、あるいはＨＷレジスタに対するリード／ライトアクセス時のエンディアンの変換や、メモリなどに対するアクセス頻度の情報収集などを行うものである。またＨＷモデル９は、Ｒｅｆ（ＨＷ側）３を流用したモデルでも良く、また設計しようとするハードウェアのアルゴリズムを実現したモデルでも良い。このモデルは、前述のようにソフトウェア開発ツールにおけるシミュレータとして組み込むことが可能となる。
【００２９】
以上のように本発明では、（ｂ）、（ｃ）のマージモデルが、（ｄ）、（ｅ）モデル上ではＣＰＵモデル上のプログラムに移行できる形式のモデリング手法を用いているために、各モデルに対して同一の動作が保証される。
【００３０】
図２の（ａ）モデルのリファレンスソースから生成された（ｂ）から（ｅ）までのモデルは機能モデルに相当する。そして各モデルの入力に対する出力値が同じ演算結果となるように、各モデルが設計される。これによってソフトウェアのアルゴリズムやコード変更などのソフトウェア開発の検証や、ハードウェアのアルゴリズムやアーキテクチャの変更に対する検証が可能となる。
【００３１】
特に（ｃ）から（ｅ）までの３つのモデルでは、ファームウェア・インターフェース（ＦＷ−ＩＦ）４側でハードウェアの機能を呼ぶか、リファレンスソースを呼ぶかを切り替えることによって、後述するようにＳＷ／ＨＷ協調検証が可能となる。
【００３２】
次に性能モデルの生成について図３から図５を用いて説明する。図３は、図２で説明した機能モデル作成フローと性能モデル作成フローとの関係図である。性能モデルとしては、（ｆ）モデル、すなわちＲｅｆ−ＳＷ＋Ｒｅｆ−ＨＷ（Ｓｙｓｔｅｍ  Ｃ）モデルと、（ｇ）モデル、すなわちＣＰＵ＋ＨＷ（Ｓｙｓｔｅｍ  Ｃ）モデルとの２つがあり、（ｆ）モデルは（ｃ）、すなわちＲｅｆ−ＳＷ＋Ｒｅｆ−ＨＷモデルから生成され、第２のマージモデルから生成されることから性能マージモデルと呼ばれる。また（ｇ）モデルは、（ｅ）モデル、すなわちＣＰＵ＋ＨＷモデルから生成され、シミュレータとして組み込むことができる（ｅ）モデルから生成されることからシミュレータに相当する性能モデルとなる。
【００３３】
図４、および図５は、（ｆ）モデル、すなわち性能マージモデルの概念的な構成図である。このモデルは（ｃ）モデル、すなわちＲｅｆ−ＳＷ＋Ｒｅｆ−ＨＷモデルから生成されるが、（ｃ）モデルのＲｅｆ（ＳＷ側）２とＲｅｆ（ＨＷ側）３とに対してＳｙｓｔｅｍ  Ｃのコードをかぶせること、すなわちＳｙｓｔｅｍ  Ｃラッパーを用いることによって、Ｃ／Ｃ＋＋モデルをＳｙｓｔｅｍ  Ｃモデルに変更し、ＦＷ−ＩＦ４、およびＨＷ−ＩＦ５を、Ｓｙｓｔｅｍ  Ｃインターフェース１０を介して接続し、インターフェースを性能モデル用に拡張したモデルとして生成される。これが図４の（ｆ１）モデルである。
【００３４】
図４（ｂ）は、ＳＷ側とＨＷ側を接続するバスをＣ／Ｃ＋＋、Ｓｙｓｔｅｍ  Ｃで記述したバスモデル１１を用いてバスを含めた並列動作を可能にした（ｆ２）モデルであり、Ｓｙｓｔｅｍ  Ｃインターフェース１０がソフトウェア側の１０ａとハードウェア側の１０ｂとに分割され、ソフトウェア側とハードウェア側とがＳｙｓｔｅｍ  Ｃのバスモデル１１によって接続される。
【００３５】
図６、および図７は、（ｇ）モデルの概念図である。シミュレータに相当する性能モデルとしての（ｇ）モデル、すなわちＣＰＵ＋ＨＷ（Ｓｙｓｔｅｍ  Ｃ）モデルは、システム・オン・チップモデル、すなわち（ｅ）ＣＰＵ＋ＨＷモデルから生成されるが、図４、図５の性能モデルと同様に、バスモデルを含むものと含まないものとの２種類のモデルが作成可能である。
【００３６】
図６は、バスモデルのない（ｇ１）モデルであり、ＣＰＵのＳｙｓｔｅｍ  Ｃモデル１４とＨＷのＳｙｓｔｅｍ  Ｃモデル１５とによって構成される。ＣＰＵのＳｙｓｔｅｍ  Ｃモデル１４は、ＦＷ（ＳＷ側）６とＦＷ−ＩＦ７によって構成されるＣＰＵモデル８と、Ｓｙｓｔｅｍ  ＣのＨＷ−ＩＦ１６ａとが、Ｓｙｓｔｅｍ  ＣラッパーによってＳｙｓｔｅｍ  Ｃのコードがかぶせられた形式となっており、またＨＷのＳｙｓｔｅｍ  Ｃモデル１５は、ＨＷモデル９とＳｙｓｔｅｍ  ＣのＨＷ−ＩＦ１６ｂとにＳｙｓｔｅｍ  Ｃのコードがかぶせられた形式となっている。
【００３７】
図７は、シミュレータに相当するもう一つの性能モデルとしての（ｇ２）モデルの構成図である。同図において図６の（ｇ１）モデルにおいて説明したＣＰＵのＳｙｓｔｅｍ  Ｃモデル１４とＨＷのＳｙｓｔｅｍ  Ｃモデル１５との間が、図５と同様にバスのＳｙｓｔｅｍ  Ｃモデル１９によって接続される形式となっている。
【００３８】
図８は、本実施形態におけるアプリケーションとしてのリファレンスソースから各機能モデル、性能モデルを生成するモデリング処理の全体フロー、すなわちシステム・オン・チップの設計フローである。顧客の要求に対して作成される３つの仕様書、すなわち概念モデルに対応する仕様書、機能モデルに対応する仕様書、および性能モデルに対応する仕様書が全体的に１つのものとして考えられ、（ａ）のリファレンスソースから各機能モデルと性能モデルとが相互に関連を持つ形式で段階的に生成されることによって、モデル間の相関をとることが可能となり、システム・オン・チップのスムーズな設計や検証の環境を提供することが可能となる。
【００３９】
図８において（ａ）から（ｅ）までのモデルは、例えばＣ／Ｃ＋＋モデルであり、性能モデル（ｆ１）、および（ｆ２）モデルはＳｙｓｔｅｍ  Ｃのアンタイムド・ファンクション（ＵＴ）モデルであり、また性能モデルの（ｇ１）モデルと（ｇ２）モデルは、Ｓｙｓｔｅｍ  Ｃのタイムド・ファンクション（ＴＦ）モデルである。またここでは、（ｄ）モデルは省略されているが、図２で説明したように（ｃ）モデルから（ｄ）モデルを生成し、（ｄ）モデルから（ｅ）モデルを生成することも当然可能である。
【００４０】
本実施形態における機能モデルと性能モデルの基本的な生成方式について説明を終わり、以後各モデルの生成とその動作などについてさらに詳細に説明する。図９は、（ｂ）モデル、すなわちＲｅｆ（ＨＷ＋ＳＷ）モデル生成処理のフローチャートである。同図においてアプリケーションなどのソフトウェア、すなわち（ａ）リファレンスソース１に対して、ステップＳ１１でソフトウェア部と分割されるべきハードウェア部の指定が行われる。すなわちＳＷ／ＨＷの分割がアプリケーション上で行われるが、リファレンスソースはもともとソフトウェアであるため、その中でハードウェア部の指定を行うことによって、ＳＷ／ＨＷの分割が行われる。この指定方法しては、リファレンスソースを人手によって書き換える方法と、ハードウェア部とすべき関数をツール上で指定して自動的に行う方法とがあるが、ここでは、例えばツール上で指定することによって自動的に指定されるものとする。
【００４１】
続いてステップＳ１２で、（ｂ）モデル用ファイルの生成が行われる。この生成については次の図１０でさらに説明するが、結果的に生成されるファイルは、図２のＲｅｆ（ＳＷ側）２に相当する、ＦＷ−ＩＦ４が埋め込まれたソースコード２１、ＳＷ／ＨＷ分割のためにハードウェア部を定義するためのヘッダファイル２３、Ｒｅｆ（ＨＷ側）３に相当するファイル２２の３つである。
【００４２】
図１０は、（ｂ）モデル、すなわちＲｅｆ（ＨＷ＋ＳＷ）モデルの生成例の説明図である。図９で説明したように、リファレンスソースの内部のハードウェア（ＨＷ）部とすべき関数、あるいは変数のコードの位置が指定され、ＦＷ−ＩＦ生成ツール２５によってファームウェア・インターフェースが埋め込まれたＲｅｆ（ＳＷ側）２１、ＳＷ／ＨＷ分割のために生成されるヘッダファイル２３、およびＲｅｆ（ＨＷ側）２２が生成される。
【００４３】
このように（ｂ）のＲｅｆ（ＨＷ＋ＳＷ）モデルでは、ハードウェア部としての関数、あるいは変数がインターフェース関数によって指定されて呼び出される形式となる。図１０では、リファレンスソース内で関数ｆｕｎｃＡ（）、および変数ｇがハードウェア部として定義される。ハードウェア側となる変数は、ソフトウェア側から見る時、データに方向性があり、変数は読み出し、すなわちリード変数と、書き込み、すなわちライト変数に分けられる。
【００４４】
図１０においてｆｗｉｆ＿ｇはＳＷ側にとってはＨＷ側からの読み出し変数となる。ａをＳＷ側からＨＷ側にデータを書き込むための変数とするならば
ｆｗｉｆ＿ａ＝ｇ
となる。またＨＷ側となる関数については１つの関数自体をＨＷブロックとして扱うことにする。
【００４５】
変数や関数の名称については、ＨＷ部のみ、またはＳＷ部のみで使用されるものについてはリネームなどの処理は必要がないが、ＳＷ側とＨＷ側で共通に使用される変数、関数については、ＳＷ側とＨＷ側とで別の名称をつけるためのリネームが必要となる。
【００４６】
図１１は、Ｒｅｆ（ＳＷ＋ＨＷ）モデルの動作概念の説明図である。同図においては、ＳＷ側の任意のコード位置でＨＷ側の変数が呼び出され、関数がコールされてＨＷ側の処理が終了するとＳＷ側へのリターンが行われる。
【００４７】
図１２は、図１０と異なり、ファームウェア・インターフェースを元のリファレンスソース内に埋め込む代わりに、異なるファイルとして定義した例である。同図においてＦＷ−ＩＦはＳＷ部と別のファイルに書き込まれ、ＦＷ−ＩＦによって関数コールが行われる。
【００４８】
図１３は、第２のマージモデル、すなわち（ｃ）Ｒｅｆ−ＳＷ＋Ｒｅｆ−ＨＷモデルの作成処理のフローチャートである。同図において、図９におけると同様にアプリケーションなどのリファレンスソース１に対して、ステップＳ１１でＨＷ部がマークによって指定され、ステップＳ１４でこのＨＷ部を指定するアドレスの設定が、例えばアドレス指定ファイル２６の内容を用いて行われる。ここでこのアドレスは、ＨＷ部の中の関数としてのＨＷブロックをＳＷ側から呼び出すために指定すべきアドレスであり、アドレス指定ファイル２６の内容を読み込むことによって自動的に、あるいはＧＵＩによってユーザから指定されることによって、アドレス設定が行われる。
【００４９】
続いてステップＳ１５で（ｃ）モデル用ファイル生成処理が行われ、生成されるファイルは図９におけると同様にＦＷ−ＩＦが埋め込まれたソースコードとしてのＲｅｆ（ＳＷ側）２１、Ｒｅｆ（ＨＷ側）２２、ヘッダファイル２３に加えて、ハードウェア・インターフェース（ＨＷ−ＩＦ）２７である。なおＦＷ−ＩＦ２８は、図１２で説明したように別のファイルとして定義されることもできる。
【００５０】
図１４は、第２のマージモデルとしての（ｃ）Ｒｅｆ−ＳＷ＋Ｒｅｆ−ＨＷモデルの生成例である。図１０におけると同様に、リファレンスソース１から、ＦＷ−ＩＦ生成ツール２５によってＦＷ−ＩＦが埋め込まれたリファレンスソース２１、Ｒｅｆ（ＨＷ側）２２、ヘッダファイル２３が生成され、さらにＨＷ−ＩＦ２７が生成される。ここでＨＷ−ＩＦは、ｖ＿ｒｅｇ＿ｒｅａｄ／ｗｒｉｔｅという関数を用いてレジスタやメモリに対するリード／ライトのアクセスを行うが、このアクセスはアドレスとサイズ、および、例えばデータの型を用いて行われる。
【００５１】
図１５から図１８は、このレジスタ、あるいはメモリへのアクセスの説明図である。図１５は、レジスタアクセスの説明図であり、Ｒｅｆ（ＳＷ側）、あるいはアルゴリズムのチューニングによってリファレンスソースの変更が行われたファームウェア（ＦＷ）側からは、ＦＷ−ＩＦとＨＷ−ＩＦを介して、前述の関数を用いてレジスタアクセスが行われる。Ｒｅｆ（ＨＷ側）、例えばＣモデルのＨＷモデルはレジスタに対して直接アクセスを行う。
【００５２】
図１６は、外部メモリ以外のＳｏＣの内部メモリ、例えばワーク・ラム（ＷＲＡＭ）や、内部メモリのリザーブ領域に対するアクセス方式の説明図である。ＦＷ側からＦＷ−ＩＦを介してＷＲＡＭ、またはリザーブ領域に対しては、後述するようにリトル・エンディアンでアクセスが行われる。ＨＷモデルからはＨＷ−ＩＦを介して、例えば１、２、または４バイト毎のリード／ライトアクセスがステップＳ１７で行われるが、ＷＲＡＭ、またはリザーブ領域に対するアクセスをリトル・エンディアンで行うために、ステップＳ１８でエンディアン変換に相当する処理が行われ、ＷＲＡＭ、またはリザーブ領域へのアクセスが行われる。このエンディアンの変換についてはさらに後述する。
【００５３】
図１７は、図１６で説明したＷＲＡＭ、またはリザーブ領域以外のＳｏＣモデルのメモリに対するアクセス動作の説明図である。例えば、ファームウェアが確保したメモリに対しては、ＦＷはリトル・エンディアンで直接にアクセスし、またＨＷモデルはＨＷ−ＩＦを用いてリトル・エンディアンでＦＷが確保したメモリに対するアクセスを行う。
【００５４】
図１８は、第２のマージモデルにおけるエンディアン変換の説明図である。後述するＣＰＵコアモデル上では、このＣＰＵのエンディアンとしての、例えばビッグ・エンディアンによるアクセスが必要となるが、第２のマージモデルでは、例えばＭｉｃｒｏｓｏｆｔ  Ｖｉｓｕａｌ  Ｃ＋＋（ＶＣ＋＋）の環境で、すべてリトル・エンディアンに統一するものとする。従って、例えば図１６で説明したようにＷＲＡＭやリザーブ領域にアクセスする場合に、ＦＷ側からも、またＨＷ側からもアクセスはともにリトル・エンディアンで行われる。このため必要に応じて、例えばＨＷ側でエンディアン変換の機能が必要となる。
【００５５】
図１９、および図２０は、（ｄ）、すなわちＣＰＵモデル作成のフローチャートでる。図１９では（ｂ）Ｒｅｆ（ＨＷ＋ＳＷ）モデル、図２０では（ｃ）Ｒｅｆ−ＳＷ＋Ｒｅｆ−ＨＷモデルがそれぞれＣＰＵシミュレータ３０に与えられ、これらのモデルはプログラムであるため、直ちにＣＰＵモデル上で実行が可能となる。
【００５６】
このＣＰＵモデル上では（ｂ）、および（ｃ）モデルのＦＷ−ＩＦ４を含めたＳＷ側がＨＷ側とすでに分離されているため、アルゴリズムなどの変更によってさらなる最適化を行うことができる。またＨＷ側も実質的にソフトウェアであり、ＣＰＵモデルの内部で検証が可能である。なおＣＰＵモデルとしては、例えば前述のＩＳＳを利用することができる。
【００５７】
図２１は、（ｅ）ＣＰＵ＋ＨＷモデルの生成処理のフローチャートである。このモデルは、図２で説明したように（ｃ）Ｒｅｆ−ＳＷ＋Ｒｅｆ−ＨＷモデルから直接に、あるいは（ｄ）ＣＰＵモデルを介して生成することができるが、ここでは（ｃ）モデルから直接に生成するものとしてその処理を説明する。
【００５８】
図２１において図１３で説明したソースファイル、すなわちＲｅｆ（ＳＷ側）２１、Ｒｅｆ（ＨＷ側）２２、ヘッダファイル２３、ＨＷ−ＩＦ２７、および例えばソースファイル２１とは別ファイルとして生成されたＦＷ−ＩＦ２８を用いて処理が行われる。ソースファイル２１、およびＦＷ−ＩＦ２８は、ＣＰＵシミュレータ３１、例えばＩＳＳに与えられる。ＨＷ−ＩＦ２７は、ＣＰＵシミュレータ３１とＨＷ−ＩＦ５との間のインターフェースとしてのＣＰＵ  ＡＰＩ（アプリケーション・プログラミング・インターフェース）３２に与えられる。Ｒｅｆ（ＨＷ側）２２はＨＷモデル９に与えられ、アドレス指定ファイル２６は、ＨＷ−ＩＦ５に与えられる。またＨＷ−ＩＦ５はヘッダファイル２３の内容を参照（点線で示す）する。
【００５９】
続いて（ｅ）ＣＰＵ＋ＨＷモデルの動作やメモリアクセスについて、図２２から図２５を用いて説明する。図２２は、ＣＰＵモデル（コア）とＨＷモデル（ユーザ・ハードウェア）９の間の基本動作の説明図である。同図においてＣＰＵモデル８とＨＷモデル９との間には、図２１で説明したＣＰＵ  ＡＰＩ３２に加えて、ＨＷ  ＡＰＩ３３が存在する。
【００６０】
図２２において（１）の経路は、ＣＰＵモデル８側からＨＷレジスタ３４へのライトアクセスの経路を示し、（１）‘はそれに対応するＨＷブロック、すなわち関数の実行を示す。（２）の経路はＨＷレジスタ３４からＣＰＵモデル８へのデータ読み込みの経路を示し、（３）、および（４）はＨＷモデル９内の各ブロックがメモリ３５にアクセスする経路を示している。ＨＷモデル９からＨＷレジスタ３４に対しては（５）、（６）の経路による直接アクセスが行われる。
【００６１】
図２３は、図２２のＣＰＵモデル（コア）８からユーザ・ハードウェア、すなわちＨＷモデル９の内部の各ブロックを起動する動作の例である。ＣＰＵモデル８がＣＰＵ  ＡＰＩ３２、およびＨＷ  ＡＰＩ３３を介してＨＷレジスタ３４にアクセスし、レジスタへの書き込みを行うと、ＨＷモデル９の内部ブロックが起動され、ブロックの実行結果はＨＷ  ＡＰＩ３３、ＣＰＵ  ＡＰＩ３２を介してＣＰＵモデル（コア）８側に返される。
【００６２】
図２４は、ＣＰＵモデル８側からＨＷレジスタ３４のデータを読み込む場合の動作例である。ＣＰＵ  ＡＰＩ３２としてのｒｅａｄ＿ｂｉｍを用いて、ＨＷ  ＡＰＩ３３としてのｖ＿ｒｅｇ＿ｒｅａｄによってＨＷレジスタ３４のデータの読み込みが行われる。
【００６３】
図２５は、ユーザ・ハードウェア、すなわちＨＷブロックからのメモリ３５へのアクセスの説明図である。ＨＷブロックからＨＷ  ＡＰＩ３３としてのｖ＿ｍｅｍ＿ｗｒｉｔｅ、ＣＰＵ  ＡＰＩ３２としてのｍｅｍ＿ｗｒｉｔｅ＿ｒａｗが呼び出され、メモリ領域へのアクセスが行われる。そしてＨＷ  ＡＰＩ３３としてのｍｅｍ＿ｗｒｉｔｅ＿ｒａｗによって、ＳｏＣ全体のメモリマップ内部で、ＣＰＵモデルとしてのＩＳＳのメモリ領域へのデータの反映が行われる。
【００６４】
続いて性能モデルの作成について図２６から図２９を用いて説明する。図２６、および図２７は、図３で説明したように（ｃ）Ｒｅｆ−ＳＷ＋Ｒｅｆ−ＨＷモデルから作られる性能モデル、すなわち（ｆ）Ｒｅｆ−ＳＷ＋Ｒｅｆ−ＨＷ（Ｓｙｓｔｅｍ  Ｃ）モデル生成処理のフローチャートである。
【００６５】
図２６の上側は、図４で説明した（ｆ１）モデル、すなわちバス無し性能モデルの生成処理のフローチャートを示し、例えば図２１と同様にＲｅｆ（ＳＷ側）２１、Ｒｅｆ（ＨＷ側）２２、ヘッダファイル２３、ＨＷ−ＩＦ、およびＦＷ−ＩＦ２８の入力に対応して、ステップＳ２０、Ｓ２１でＳｙｓｔｅｍＣラッパー化処理が行われ、ＳＷ側のＳｙｓｔｅｍ  Ｃラッパー４０、ＨＷ側のＳｙｓｔｅｍ  Ｃラッパー４１とされる。そして図４で説明したＳｙｓｔｅｍ  Ｃ  ＩＦ１０を用いて、入力ファイル内のコードにＳｙｓｔｅｍ  Ｃのコードがかぶせられて（ｆ１）バス無し性能モデルが生成される。このフローチャートは基本的には入力されるファイルを用いてモデルを組み立てるだけの処理であるが、ツールを用いた自動化処理として実行することも当然可能である。
【００６６】
図２６の下側は、図５の（ｆ２）モデル、すなわちバス有り性能モデルの生成を示す。（ｆ１）モデルに対すると同様の各種のファイルが入力され、バスモデル（Ｓｙｓｔｅｍ  Ｃ）１１が用いられてＳＷ側とＨＷ側とが接続され、さらにＳｙｓｔｅｍ  Ｃ  ＩＦ１０はＳＷ側とＨＷ側とに分割されている。
【００６７】
図２７は、（ｆ１）、すなわちバス無し性能モデルの生成の具体例である。同図においては、ＳＷ側ではＲｅｆ（ＳＷ側）２とＦＷ−ＩＦ４とがＳＷ側のＳｙｓｔｅｍ  Ｃラッパー４０に包まれ、またＨＷ側ではＲｅｆ（ＨＷ側）３とＨＷ−ＩＦ５とがＨＷ側のＳｙｓｔｅｍ  Ｃラッパー４１に包まれ、Ｓｙｓｔｅｍ  Ｃ  ＩＦ１０によって接続される形式となる。
【００６８】
図２８は、（ｇ）ＣＰＵ＋ＨＷ（Ｓｙｓｔｅｍ  Ｃ）モデルの生成処理フローチャートである。（ｇ）モデルは図３で説明したように（ｅ）ＣＰＵ＋ＨＷモデルを基に生成され、図６、図７で説明したようにバス無しの（ｇ１）モデルとバス有りの（ｇ２）モデルとがある。
【００６９】
図２８において、図２１において生成された（ｅ）モデルの構成要素としてのＣＰＵシミュレータ（ＩＳＳ）３１、ＣＰＵ  ＡＰＩ３２、ＨＷ−ＩＦ５、およびＨＷモデル９がそれぞれステップＳ２２からステップＳ２４の処理によってＳｙｓｔｅｍ  Ｃラッパー化され、また図２６におけると同様にＳＷ側のＳｙｓｔｅｍ  Ｃラッパー４０、ＨＷ側のＳｙｓｔｅｍ  Ｃラッパー４１とされ、Ｓｙｓｔｅｍ  ＣのＨＷ−ＩＦ１６が与えられて、（ｇ１）バス無し性能モデルが生成される。またさらにバスのＳｙｓｔｅｍ  Ｃモデル１９が与えられることによって、（ｇ２）バス有り性能モデルが生成される。
【００７０】
本実施形態におけるモデルの検証方式について図２９から図３１を用いて説明する。図２９は、第２のマージモデル、すなわち（ｃ）Ｒｅｆ−ＳＷ＋Ｒｅｆ−ＨＷモデルに対する検証方式の説明図である。同図においてＦＷ６、ＦＷ−ＩＦ４、ＨＷ−ＩＦ５、およびＨＷモデル９によって構成される（ｃ）モデルに対して入力データ５０が与えられ、得られた演算結果５１が期待値５２とバイナリーデータとして比較され、検証が行われる。入力データ５０と期待値５２は、リファレンスソースに対して生成されたものと同じであり、第２のマージモデルがブラックボックスとして扱われ、演算結果と期待値を比較することによって検証が行われる。ここでＨＷ−ＩＦ５とＨＷモデル９とは、例えばユーザＨＷライブラリの格納内容から選択されるものとする。なおモデルによっては最終的な演算結果でなく、内部演算結果の検証を行うことも可能である。
【００７１】
図３０、および図３１は、ＣＰＵモデルを利用したＨＷモデル、すなわちユーザ・ハードウェアの検証方式の説明図である。図３０において、例えば（ｃ）モデルから生成された（ｄ）ＣＰＵモデル５５が（ｅ）ＳｏＣモデルのコア側にロードされ、コア上で期待値を生成するとともに、ＨＷモデル９、すなわちユーザ・ハードウェアの処理を実行することによって、ユーザ・ハードウェアの検証が可能となる。
【００７２】
すなわち（ｃ）モデルの構成要素としてのＦＷ（ＳＷ側）６、ＦＷ−ＩＦ４、ＨＷ−ＩＦ５、およびＲｅｆ（ＨＷ側）３がテストベンチとともにＣＰＵモデル５５として形成され、ＨＷモデル９と接続されることによって、ＨＷモデル、すなわちユーザ・ハードウェアの検証が行われる。
【００７３】
図３１は、図３０におけるＨＷモデル、すなわちユーザ・ハードウェアの検証処理のフローチャートである。ＣＰＵモデル上のソフトウェアにおいてアプリケーションがスタートすると、ＦＷ−ＩＦ、すなわちドライバを介してハードウェア・コールが行われ、ＨＷ−ＩＦによってハードウェアが起動され、ＨＷモデル上で処理が行われ、その結果がＣＰＵモデル上のソフトウェア側の検証プログラムに返される。一方、ソフトウェア側ではハードウェア・コールと同時に同じ処理が行われ、その結果がＨＷモデルから返された結果と比較されて検証が行われる。このようなハードウェア・コールが繰り返されて、アプリケーションが終了する時点で、ＨＷモデル、すなわちユーザ・ハードウェアの検証が終了する。
【００７４】
以上詳細に説明したＳｏＣ設計方式を、ＧＵＩを持つ設計ツールとして提供することが可能である。図３２は、そのような設計ツールを用いた処理の全体フローチャートである。同図において右側はツール上の処理を、左側はＧＵＩ側の、例えばユーザによる指定を含む処理を示している。まずＧＵＩ側で、例えばＣ／Ｃ＋＋ソースコード６０に対して、Ｃ／Ｃ＋＋／Ｓｙｓｔｅｍ  Ｃエディタ上でＨＷ部の指定が行われ、そのソースコード６０は、ツール側のステップＳ２５におけるファイル生成実行処理に渡され、生成された各種ファイル６１に対してＧＵＩ側でステップＳ２６でファイルが指定され、ステップＳ２７でコンパイル実行が指示される。ツール側のステップＳ２８においてコンパイル処理が行われ、各種モデル（シミュレータ）６２が生成され、ＧＵＩ側でステップＳ２９で各種モデルの実行とデバッグが行われる。
【００７５】
以上において本発明のＳＷ／ＨＷ協調設計のためのモデル生成プログラム、およびモデル生成方法についてその詳細を説明したが、このようなプログラムをツールとして用いる設計装置は当然一般的なコンピュータシステムを基本として構成することが可能である。図３３はそのようなコンピュータシステム、すなわちハードウェア環境の構成ブロック図である。
【００７６】
図３３においてコンピュータシステムは中央処理装置（ＣＰＵ）７０、リード・オンリ・メモリ（ＲＯＭ）７１、ランダム・アクセス・メモリ（ＲＡＭ）７２、通信インターフェース７３、記憶装置７４、入出力装置７５、可搬型記憶媒体の読取り装置７６、およびこれらの全てが接続されたバス７７によって構成されている。
【００７７】
記憶装置７４としてはハードディスク、磁気ディスクなど様々な形式の記憶装置を使用することができ、このような記憶装置７４、またはＲＯＭ７１に図２、図８、図９、図１３、図１９〜図２１、図２６、図２８などのフローチャートに示されたプログラムや、本発明の特許請求の範囲の請求項１〜９のプログラムなどが格納され、そのようなプログラムがＣＰＵ７０によって実行されることにより、本実施形態における同一の動作を保証できる形式でのモデルの段階的設計、そのモデリング手法を用いるツールによるＳｏＣ設計の容易化などが可能となる。
【００７８】
このようなプログラムは、プログラム提供者７８からネットワーク７９、および通信インターフェース７３を介して、例えば記憶装置７４に格納されることも、また市販され、流通している可搬型記憶媒体８０に格納され、読取り装置７６にセットされて、ＣＰＵ７０によって実行されることも可能である。可搬型記憶媒体８０としてはＣＤ−ＲＯＭ、フレキシブルディスク、光ディスク、光磁気ディスク、ＤＶＤなど様々な形式の記憶媒体を使用することができ、このような記憶媒体に格納されたプログラムが読取り装置７６によって読取られることにより、本実施形態におけるモデル開発、アプリケーションやアルゴリズムの検証などが可能となる。
【００７９】
（付記１）  ソフトウェア／ハードウェア協調設計を行う計算機によって使用されるプログラムであって、
アプリケーション・ソフトウェアとしてのリファレンスソース内のソフトウェア側とハードウェア側とが分離され、前記ソフトウェア側が前記ハードウェア側を呼ぶためのファームウェア・インターフェースと、前記ファームウェア・インターフェースからの呼び出しに対応して前記ハードウェア側の関数または変数へのアクセスを可能とするハードウェア・インターフェースとを備えるマージモデルを生成する手順と、
前記マージモデル内の前記ソフトウェア側と前記ファームウェア・インターフェースとを命令レベルで実行できるシミュレータとしての中央処理装置モデルと、前記ハードウェア側に対応するハードウェアモデルと、前記中央処理装置モデルと前記ハードウェアモデルとを接続する前記ハードウェア・インターフェースとを備えるシステム・オン・チップモデルを生成する手順と
を計算機に実行させることを特徴とするソフトウェア／ハードウェア協調設計のためのモデル生成プログラム。
（付記２）  前記システム・オン・チップモデル生成する手順に先立って、
前記中央処理装置モデルを第１の中央処理装置モデルとするとき、前記マージモデルをソフトウェアとして命令レベルで実行できるシミュレータとしての第２の中央処理装置モデルを生成する手順をさらに計算機に実行させることを特徴とする付記１記載のソフトウェア／ハードウェア協調設計のためのモデル生成プログラム。
（付記３）  前記マージモデルを生成する手順に先立って、
前記マージモデルを第２のマージモデルとするとき、前記リファレンスソース内のソフトウェア側とハードウェア側とが分離され、前記ソフトウェア側が前記ハードウェア側を呼ぶためのファームウェア・インターフェースを備える第１のマージモデルを生成する手順をさらに計算機に実行させることを特徴とする付記１記載のソフトウェア／ハードウェア協調設計のためのモデル生成プログラム。
（付記４）  前記システム・オン・チップモデルを生成する手順の後に、
前記中央処理装置モデル、前記ハードウェアモデルのそれぞれを、現に記述されている言語と異なる言語を用いるシステムで利用するための前処理を行い、前記ハードウェア・インターフェースに相当し、前記異なる言語で記述されたインターフェースによって前記前処理済みの中央処理装置モデルと前記ハードウェアモデルとを接続した性能モデルを生成する手順をさらに計算機に実行させることを特徴とする付記１記載のソフトウェア／ハードウェア協調設計のためのモデル生成プログラム。
（付記５）  前記システム・オン・チップモデルを生成する手順の後に、
前記中央処理装置モデル、前記ハードウェアモデルのそれぞれを、現に記述されている言語と異なる言語を用いるシステムで利用するための前処理を行い、前記ハードウェア・インターフェースに相当し、さらに前記異なる言語で記述されたハードウェア側のインターフェースとソフトウェア側のインターフェース、および前記２つのインターフェースを結ぶバスのモデルとを用いて、前記前処理済みの前記中央処理装置モデルと前記ハードウェアモデルとを接続したバス有り性能モデルを生成する手順をさらに計算機に実行させることを特徴とする付記１記載のソフトウェア／ハードウェア協調設計のためのモデル生成プログラム。
（付記６）  前記ハードウェア・インターフェースが、前記ハードウェア側がデータを転送、記録する際のバイトの並び順を、前記ソフトウェア側を実行する中央処理装置において用いられる並び順に変換するエンディアン変換機能を有することを特徴とする付記１記載のソフトウェア／ハードウェア協調設計のためのモデル生成プログラム。
（付記７）  前記ソフトウェア側と前記ハードウェア側とで共通して用いられる変数、および／または関数を、前記ソフトウェア側と前記ハードウェア側とで異なる変数、および／または関数として定義することを特徴とする付記１記載のソフトウェア／ハードウェア協調設計のためのモデル生成プログラム。
（付記８）  付記１に記載のプログラムによって作成されたシステム・オン・チップモデルを用いるユーザ・ハードウェアの検証方法であって、
前記システム・オン・チップモデルに相当する中央処理装置によって、前記リファレンスソースを実行した結果と、前記ハードウェアモデルの実行結果とを比較して、前記ハードウェアモデルに相当するユーザ・ハードウェアの検証を行うことを特徴とするユーザ・ハードウェア検証方法。
（付記９）  付記１に記載のプログラムを用いる設計シミュレーションツールであって、
前記マージモデルと前記システム・オン・チップモデルとを利用して、ソフトウェア／ハードウェア協調設計シミュレーションを可能とするシミュレーションツール。
（付記１０）  ソフトウェア／ハードウェア協調設計を行う計算機によって使用されるプログラムであって、
アプリケーション・ソフトウェアとしてのリファレンスソース内のソフトウェア側とハードウェア側とが分離され、前記ソフトウェア側が前記ハードウェア側を呼ぶためのファームウェア・インターフェースを備えるマージモデルを生成する手順と、
前記マージモデルと、前記ファームウェア・インターフェースからの呼び出しに対応して前記ハードウェア側の関数または変数へのアクセスを可能とするハードウェア・インターフェースとを、ソフトウェアとして命令レベルで実行できるシミュレータとしての中央処理装置モデルを生成する手順とを計算機に実行させることを特徴とするソフトウェア／ハードウェア協調設計のためのモデル生成プログラム。
（付記１１）  前記中央処理装置モデルを生成する手順の後に、
前記中央処理装置モデルを第１の中央処理装置モデルとするとき、
前記第１の中央処理装置モデル内の前記ソフトウェア側と前記ファームウェア・インターフェースとを命令レベルで実行できるシミュレータとしての第２の中央処理装置モデルと、
前記ハードウェア側に対応するハードウェアモデルと、
前記第２の中央処理装置モデルと前記ハードウェアモデルとを接続する前記ハードウェア・インターフェースとを
備えるシステム・オン・チップモデルを生成する手順
をさらに計算機に実行させることを特徴とする付記１０記載のソフトウェア／ハードウェア協調設計のためのモデル生成プログラム。
（付記１２）  付記１０に記載のプログラムを用いる設計シミュレーションツールであって、
前記マージモデルと前記中央処理装置モデルとを利用して、ソフトウェア／ハードウェア協調設計シミュレーションを可能とするシミュレーションツール。
（付記１３）  ソフトウェア／ハードウェア協調設計を行う計算機によって使用されるプログラムであって、
アプリケーション・ソフトウェアとしてのリファレンスソース内のソフトウェア側とハードウェア側とが分離され、前記ソフトウェア側が前記ハードウェア側を呼ぶためのファームウェア・インターフェースと、前記ファームウェア・インターフェースからの呼び出しに対応して前記ハードウェア側の関数または変数へのアクセスを可能とするハードウェア・インターフェースとを備えるマージモデルを生成する手順と、
前記ソフトウェア側、前記ハードウェア側、前記ファームウェア・インターフェース、および前記ハードウェア・インターフェースを、現に記述されている言語と異なる言語を用いるシステムで利用するための前処理を行い、前記前処理済みのファームウェア・インターフェースと前記前処理済みハードウェア・インターフェースとを、さらに前記異なる言語で記述されたインターフェースによって接続した性能マージモデルを生成する手順とを計算機に実行させることを特徴とするソフトウェア／ハードウェア協調設計のためのモデル生成プログラム。
（付記１４）  付記１３に記載のプログラムを用いる設計シミュレーションツールであって、
前記マージモデルと前記性能マージモデルとを利用して、ソフトウェア／ハードウェア協調設計シミュレーションを可能とするシミュレーションツール。
（付記１５）  ソフトウェア／ハードウェア協調設計を行う計算によって使用されるプログラムであって、
アプリケーション・ソフトウェアとしてのリファレンスソース内のソフトウェア側とハードウェア側とが分離され、前記ソフトウェア側が前記ハードウェア側を呼ぶためのファームウェア・インターフェースと、前記ファームウェア・インターフェースからの呼び出しに対応して前記ハードウェア側の関数または変数へのアクセスを可能とするハードウェア・インターフェースとを備えるマージモデルを生成する手順と、
前記ソフトウェア側、前記ハードウェア側、前記ファームウェア・インターフェース、および前記ハードウェア・インターフェースを、現に記述されている言語と異なる言語を用いるシステムで利用するための前処理を行い、前記ファームウェア・インターフェースに接続され、さらに前記異なる言語で記述された第１のインターフェースと、前記ハードウェア・インターフェースに接続され、さらに前記異なる言語で記述された第２のインターフェースとの間を、前記異なる言語で記述されたバスのモデルによって接続したバス有り性能マージモデルを生成する手順とを計算機に実行させることを特徴とするソフトウェア／ハードウェア協調設計のためのモデル生成プログラム。
（付記１６）  付記１５に記載のプログラムを用いる設計シミュレーションツールであって、
前記マージモデルと前記バス有り性能マージモデルとを利用して、ソフトウェア／ハードウェア協調設計シミュレーションを可能とするシミュレーションツール。
（付記１７）  ソフトウェア／ハードウェア協調設計を行うために必要なモデルの生成方法であって、
アプリケーション・ソフトウェアとしてのリファレンスソース内のソフトウェア側とハードウェア側とが分離され、前記ソフトウェア側が前記ハードウェア側を呼ぶためのファームウェア・インターフェースと、前記ファームウェア・インターフェースからの呼び出しに対応して前記ハードウェア側の関数または変数へのアクセスを可能とするハードウェア・インターフェースとを備えるマージモデルを生成し、
前記マージモデル内の前記ソフトウェア側と前記ファームウェア・インターフェースとを命令レベルで実行できるシミュレータとしての中央処理装置モデルと、前記ハードウェア側に対応するハードウェアモデルと、前記中央処理装置モデルと前記ハードウェアモデルとを接続する前記ハードウェア・インターフェースとを備えるシステム・オン・チップモデルを生成することを特徴とするソフトウェア／ハードウェア協調設計のためのモデル生成方法。
（付記１８）  ソフトウェア／ハードウェア協調設計を行うために必要なモデルの生成方法であって、
アプリケーション・ソフトウェアとしてのリファレンスソース内のソフトウェア側とハードウェア側とが分離され、前記ソフトウェア側が前記ハードウェア側を呼ぶためのファームウェア・インターフェースを備えるマージモデルを生成し、
前記マージモデルと、前記ファームウェア・インターフェースからの呼び出しに対応して前記ハードウェア側の関数、または変数へのアクセスを可能とするハードウェア・インターフェースとを、ソフトウェアとして命令レベルで実行できるシミュレータとしての中央処理装置モデルを生成することを特徴とするソフトウェア／ハードウェア協調設計のためのモデル生成方法。
（付記１９）  ソフトウェア／ハードウェア協調設計を行うために必要なモデルの生成方法であって、
アプリケーション・ソフトウェアとしてのリファレンスソース内のソフトウェア側とハードウェア側とが分離され、前記ソフトウェア側が前記ハードウェア側を呼ぶためのファームウェア・インターフェースと、前記ファームウェア・インターフェースからの呼び出しに対応して前記ハードウェア側の関数、または変数へのアクセスを可能とするハードウェア・インターフェースとを備えるマージモデルを生成し、
前記ソフトウェア側、前記ハードウェア側、前記ファームウェア・インターフェース、および前記ハードウェア・インターフェースを、現に記述されている言語と異なる言語を用いるシステムで利用するための前処理を行い、前記前処理済みのファームウェア・インターフェースと前記ハードウェア・インターフェースとを、さらに前記異なる言語で記述されたインターフェースによって接続した性能マージモデルを生成することを特徴とするソフトウェア／ハードウェア協調設計のためのモデル生成方法。
（付記２０）  ソフトウェア／ハードウェア協調設計を行うために必要なモデルの生成方法であって、
アプリケーション・ソフトウェアとしてのリファレンスソース内のソフトウェア側とハードウェア側とが分離され、前記ソフトウェア側が前記ハードウェア側を呼ぶためのファームウェア・インターフェースと、前記ファームウェア・インターフェースからの呼び出しに対応して前記ハードウェア側の関数、または変数へのアクセスを可能とするハードウェア・インターフェースとを備えるマージモデルを生成し、
前記ソフトウェア側、前記ハードウェア側、前記ファームウェア・インターフェース、および前記ハードウェア・インターフェースを、現に記述されている言語と異なる言語を用いるシステムで利用するための前処理を行い、前記ファームウェア・インターフェースに接続され、さらに前記異なる言語で記述された第１のインターフェースと、前記ハードウェア・インターフェースに接続され、さらに前記異なる言語で記述された第２のインターフェースとの間を、前記異なる言語で記述されたバスのモデルによって接続したバス有り性能マージモデルを生成することを特徴とするソフトウェア／ハードウェア協調設計のためのモデル生成方法。
【図面の簡単な説明】
【００８０】
【図１】本発明のＳＷ／ＨＷ協調設計のためのモデル生成プログラムの原理的な機能ブロック図である。
【図２】本実施形態におけるモデル生成方式の基本処理フローチャートである。
【図３】機能モデル生成フローと性能モデル生成フローとの関係の説明図である。
【図４】性能マージモデルの構成を示す図である。
【図５】バス有り性能マージモデルの構成を示す図である。
【図６】性能モデルの構成を示す図である。
【図７】バス有り性能モデルの構成を示す図である。
【図８】本実施形態における設計方式の基本処理フローチャートである。
【図９】（ｂ）Ｒｅｆ（ＨＷ＋ＳＷ）モデルの生成処理フローチャートである。
【図１０】（ｂ）モデル生成例の説明図である。
【図１１】（ｂ）モデルにおける動作概念の説明図である。
【図１２】ファームウェア・インターフェースを別ファイルとする例の説明図である。
【図１３】（ｃ）Ｒｅｆ−ＳＷ＋Ｒｅｆ−ＨＷモデルの生成処理フローチャートである。
【図１４】（ｃ）モデルの生成例の説明図である。
【図１５】（ｃ）モデルにおけるレジスタアクセス方式の説明図である。
【図１６】（ｃ）モデルにおけるメモリアクセス例（その１）の説明図である。
【図１７】（ｃ）モデルにおけるメモリアクセス例（その２）の説明図である。
【図１８】（ｃ）モデルにおけるエンディアン変換の説明図である。
【図１９】（ｂ）モデルから（ｄ）ＣＰＵモデルを生成する処理のフローチャートである。
【図２０】（ｃ）モデルから（ｄ）ＣＰＵモデルを生成する処理のフローチャートである。
【図２１】（ｃ）モデルから（ｅ）ＣＰＵ＋ＨＷモデルを生成する処理のフローチャートである。
【図２２】（ｅ）モデルにおけるＣＰＵモデルとＨＷモデルとの間の動作の説明図である。
【図２３】（ｅ）モデルにおけるＨＷブロックの起動例の説明図である。
【図２４】（ｅ）モデルにおけるＣＰＵコアからＨＷレジスタへのデータ書き込み例の説明図である。
【図２５】（ｅ）モデルにおけるＨＷブロックからのメモリアクセス例の説明図である。
【図２６】（ｃ）モデルから（ｆ１）性能マージモデル、および（ｆ２）バス有り性能マージモデルを生成する処理のフローチャートである。
【図２７】（ｆ１）性能マージモデルの生成例の説明図である。
【図２８】（ｅ）モデルから（ｇ１）性能モデル、および（ｇ２）バス有り性能モデルを生成する処理のフローチャートである。
【図２９】（ｃ）Ｒｅｆ−ＳＷ＋Ｒｅｆ−ＨＷモデルの検証方式の説明図である。
【図３０】（ｃ）Ｒｅｆ−ＳＷ＋Ｒｅｆ−ＨＷモデルを利用したユーザ・ハードウェアの検証方式の説明図である。
【図３１】図３０における検証処理のフローチャートである。
【図３２】ＧＵＩを備えた設計ツールを用いた処理の説明図である。
【図３３】本発明におけるプログラムのコンピュータへのローディングを説明する図である。
【図３４】従来技術における上流設計のフローチャートである。
【符号の説明】
【００８１】
１  リファレンスソース
２、２１  リファレンス（ソフトウェア側）
３、２２  リファレンス（ハードウェア側）
４、２８  ファームウェア・インターフェース
５、２７  ハードウェア・インターフェース
６  ファームウェア（ソフトウェア側）
７、８  ＣＰＵモデル
９  ハードウェアモデル
１０  Ｓｙｓｔｅｍ  Ｃ  インターフェース
１１  バスモデル（Ｓｙｓｔｅｍ  Ｃ）
１４  ＣＰＵのＳｙｓｔｅｍ  Ｃモデル
１５  ハードウェアのＳｙｓｔｅｍ  Ｃモデル
１６  Ｓｙｓｔｅｍ  Ｃのハードウェア・インターフェース
１９  バスのＳｙｓｔｅｍ  Ｃモデル
２３  ヘッダファイル
２５  ファームウェア・インターフェース生成ツール
２６  アドレス指定ファイル
３１  ＣＰＵシミュレータ（ＩＳＳ）
３２  ＣＰＵ  ＡＰＩ（アプリケーション・プログラミング・インターフェース）
３３  ハードウェア  ＡＰＩ
３４  ハードウェアレジスタ
３５  メモリ
４０  ソフトウェア側のＳｙｓｔｅｍ  Ｃラッパー
４１  ハードウェア側のＳｙｓｔｅｍ  Ｃラッパー
５０  入力データ
５１  演算結果
５２  期待値
５５  ＣＰＵモデル
６０  Ｃ／Ｃ＋＋ソース
６１  各種ファイル
６２  各種モデル（シミュレータ）
７０  中央処理装置（ＣＰＵ）
７１  リード・オンリ・メモリ（ＲＯＭ）
７２  ランダム・アクセス・メモリ（ＲＡＭ）
７３  通信インターフェース
７４  記憶装置
７５  入出力装置
７６  読み取り装置
７７  バス
７８  プログラム提供者
７９  ネットワーク
８０  可搬型記憶媒体
【図１】
2007310449.tif 000003
【図２】
2007310449.tif 000004
【図３】
2007310449.tif 000005
【図４】
2007310449.tif 000006
【図５】
2007310449.tif 000007
【図６】
2007310449.tif 000008
【図７】
2007310449.tif 000009
【図８】
2007310449.tif 000010
【図９】
2007310449.tif 000011
【図１１】
2007310449.tif 000012
【図１２】
2007310449.tif 000013
【図１３】
2007310449.tif 000014
【図１５】
2007310449.tif 000015
【図１６】
2007310449.tif 000016
【図１７】
2007310449.tif 000017
【図１８】
2007310449.tif 000018
【図１９】
2007310449.tif 000019
【図２０】
2007310449.tif 000020
【図２１】
2007310449.tif 000021
【図２３】
2007310449.tif 000022
【図２４】
2007310449.tif 000023
【図２５】
2007310449.tif 000024
【図２６】
2007310449.tif 000025
【図２８】
2007310449.tif 000026
【図２９】
2007310449.tif 000027
【図３０】
2007310449.tif 000028
【図３１】
2007310449.tif 000029
【図３３】
2007310449.tif 000030
【図３４】
2007310449.tif 000031
【図１０】
2007310449.tif 000032
【図１４】
2007310449.tif 000033
【図２２】
2007310449.tif 000034
【図２７】
2007310449.tif 000035
【図３２】
2007310449.tif 000036