JPWO2006003702A1 - 検証支援装置、検証支援方法、および検証支援プログラム - Google Patents

Abstract

検証支援装置（４００）は、概念モデル生成部（４０２）による、顧客の要求仕様に着目した概念モデルを生成することにより、設計の初期段階で仕様のミスや誤解を解消する。また、機能モデル検証部（４０４）による、並列、並行な機能モデルの検証によって、機能モジュール分割の妥当性、並列、並行性の正しさを検証する。また、動作モデル検証部（４０８）による動作モデルの検証によってアーキテクチャの設計の妥当性、性能要件に満足しているかどうかを検証する。また、ＩＣＡモデル検証部（４１０）によってインターフェース設計の正しさを検証する。このように、段階的に検証を導入することによって、これまで、ＲＴＬを生成しないと発見できなかった問題を、設計の早期段階に摘出してそのリスクを回避することができる。

Description

本発明は、ＬＳＩの検証を支援する検証支援装置、検証支援方法、検証支援プログラムおよび記録媒体に関する。

ＬＳＩ設計では、ＬＳＩが正常に動作するか否かを検証する検証作業が必要不可欠であり、特に、大規模化、高機能化、高速化および低消費電力化が要求されているＬＳＩについては、高品質を維持するためにもこの検証作業は重要である一方、従来から設計期間の短縮による作業効率化が要求されている。

特に、近年は、ソフトウェアとハードウェアが混在しており、従来型のＡＳＩＣによる単機能のハードウェアだけではなく、ソフトウェアも含めたシステム・オン・チップ（ＳｏＣ）が主流となっている。また、ＭＰＥＧやＪＰＥＧなど、本来アプリケーションソフトウェアで実現される機能がハードウェアで実現するようになっているため、ＬＳＩの機能が複雑化している。

ここで、従来のＬＳＩの開発処理について説明する。図３８は、従来のＬＳＩの開発処理手順を示すフローチャートである。図３８において、ステップＳ３８０１〜ステップＳ３８０５が、ＬＳＩの設計をおこなう設計フローであり、ステップＳ３８０６〜ステップＳ３８０９が、設計されたＬＳＩの検証をおこなう検証フローである。

まず、設計フローでは、ステップＳ３８０１において、概念設計をおこなう。概念設計では、顧客からの設計要求に基づいて設計者が要求仕様書３８１０を自然言語によって作成する。または、顧客から自然言語で記述された要求仕様書３８１０を受け取る。

つぎに、ステップＳ３８０２において、機能設計をおこなう。機能設計では、要求仕様書３８１０に記述された内容から、設計対象となるＬＳＩを機能ブロックごとに分けて、各機能ブロックの内容を記述した機能仕様書３８２０を作成する。

つぎに、ステップＳ３８０３において、構造設計をおこなう。構造設計では、機能仕様書３８２０からハードウェア設計をおこなって構造仕様書３８３０を作成する。具体的には、どのようなアーキテクチャを導入すれば機能仕様書３８２０に記述された機能を実現できるか、という設計をおこなうことである。

たとえば、各機能ブロックのうち、ある機能ブロックのアーキテクチャについてはソフトウェアによって実現し、ある機能ブロックのアーキテクチャについてはＩＰ（Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ）を購入して実現し、ある機能ブロックのアーキテクチャについては設計者が作成し、ある機能ブロックのアーキテクチャについては、アンダーバスによって実現するということである。

つぎに、ステップＳ３８０４において、ユニット設計をおこなう。ユニット設計では、構造仕様書３８３０に記述された各ハードウェアモジュールを複数のモジュールに分割して詳細に設計することによってユニット仕様書３８４０を作成する。

つぎに、ステップＳ３８０５において、実装をおこなう。実装では、インターフェースのタイミングチャートを用い、また、内部ロジックを考慮することにより、最終的な設計対象となるＲＴＬ（Ｒｅｇｉｓｔｅｒ Ｔｒａｎｓｆｅｒ Ｌｅｖｅｌ）３８５０のＨＤＬ（Ｈａｒｄｗａｒｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）を用いて実装をおこなう。

つぎに、ステップＳ３８０６において、ユニット検証をおこなう。ユニット検証では、ユニット検証項目３８６０にしたがって、ユニット設計によって設計されたユニットごとのユニット仕様書３８４０の検証、すなわち、デバッグをおこなう。

つぎに、ステップＳ３８０７において、結合検証をおこなう。結合検証では、結合検証項目３８７０にしたがって、ユニット検証によって検証された各ユニットのインターフェースを結合して、正常に動作するかを検証する。

つぎに、ステップＳ３８０８において、機能検証をおこなう。機能検証では、機能検証項目３８８０にしたがって、設計対象となるシステムの機能要求を満たすかどうかを検証する。

最後に、ステップＳ３８０９において、実機検証をおこなう。実機検証では、ＲＴＬ３８５０を用いて実際にチップ上にＬＳＩを実装して、実際に動作するかどうかを検証する。顧客からの要求仕様書３８１０が、要求検証項目３８９０を満足しているかどうかを判断する。

しかしながら、上述した設計処理では、実装（ステップＳ３８０５）しなければ、ＬＳＩの検証（ステップＳ３８０６〜Ｓ３８０９）をおこなうことができなかった。

これにより、設計フローの上流のいずれかのステップにおいて仕様書の誤り、記述の曖昧さ、設計者の誤解釈のためにミスが生じると、そのステップ以降のステップにおいてミスが累積されてしまうという問題があった。

また、構造設計においては、机上でアーキテクチャを決定しており、その妥当性を確かめる手法が存在していなかった。したがって、開発リスクの増大によって開発プロジェクトの破綻も生じ、開発時間および開発労力が無駄になるという問題があった。

また、ＲＴＬ３８５０のＨＤＬに対してシミュレーションをおこなうために特別なシミュレータ(ＶＣＳ、ＮＣ−ＳｉｍなどのＥＤＡベンダーのツール)が必要であるが、シミュレーションスピードが遅いために検証効率が低下し、設計期間の長期化を招くという問題があった。特に、設計対象が大規模な場合、シミュレーションスピードがネックとなって、所定の期間内に検証作業を収束させることができない場合があった。

一方、シミュレータより何千倍のスピードで動くエミュレータを導入してシミュレーションの速度の向上を図ることも考えられるが、エミュレータが非常に高価であり、検証費用が増大するとともに、環境の構築が困難な上に問題発生時にデバッグが難しいために結果的に検証期間が増加して、設計期間の長期化を招くという問題があった。

本発明は、上記問題点に鑑みてなされたものであって、ＬＳＩの設計精度の向上および検証期間の短縮化を、容易かつ効率的に実現することができる検証支援装置、検証支援方法、検証支援プログラムおよび該プログラムを記録した記録媒体を提供することを目的とする。

上述した課題を解決し、目的を達成するため、本発明の検証支援装置、検証支援方法、検証支援プログラムおよび該プログラムを記録した記録媒体は、ＬＳＩの設計対象に関する要求仕様の分析結果を示す分析情報を入力し、入力された分析情報に基づいて、前記設計対象の基本機能がモデル化され、かつ、前記設計対象の物理的なアーキテクチャおよび時間の概念が抽象化された概念モデルを生成し、入力された分析情報に基づいて、前記設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性を抽出することによってモデル化された機能モデルを生成し、生成された機能モデルについて、前記設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性が正当であるかどうかを、生成された概念モデルに基づいて検証することを特徴とする。

また、上記発明は、前記機能モデルが正当であることが検証された場合、複数種類の物理的なアーキテクチャに関する情報から任意のアーキテクチャに関する情報を抽出し、抽出されたアーキテクチャに関する情報を、正当であることが検証された機能モデルにマッピングすることにより、前記設計対象の動作をモデル化した動作モデルを生成し、生成された動作モデルによりモデル化された設計対象を構成するモジュールの動作タイミングが、正当であるかどうかを検証することを特徴とする。

さらに、上記発明は、前記動作モデルが正当であることが検証された場合、前記機能モデルによってモデル化された設計対象を構成するモジュール間の抽象度が異なる箇所に、当該モジュール間に所定のクロックサイクル精度のインターフェースを挿入することによりＩＣＡモデルを生成し、生成されたＩＣＡモデルに挿入されたインターフェースのクロックサイクル精度が正当であるかどうかを、生成された概念モデルに基づいて検証することを特徴とする。

また、前記動作モデルが正当であることが検証された場合、前記機能モデルによってモデル化された設計対象に基づいて、ソフトウェアによって実行可能なタスクを含むようにモデル化されたソフトウェアモデルを生成し、生成されたソフトウェアモデルに含まれているタスクが正当であるかどうかを、生成された概念モデルに基づいて検証することを特徴とする。

この発明の検証支援装置、検証支援方法、検証支援プログラムおよび記録媒体によれば、段階的に検証を導入することによって、これまで、ＲＴＬを生成しないと発見できなかった問題を、設計の早期段階に摘出してそのリスクを回避することができる。したがって、ＬＳＩの設計精度の向上および検証期間の短縮化を、容易かつ効率的に実現することができるという効果を奏する。

この発明の実施の形態にかかる検証支援の概念図である。 図１に示した各モデルの抽象度をあらわすグラフである。 この発明の実施の形態にかかる検証支援装置のハードウェア構成を示すブロック図である。 この発明の実施の形態にかかる検証支援装置の機能的構成を示すブロック図である。 この発明の実施の形態にかかる検証支援装置の検証支援処理手順を示すフローチャートである。 この発明の実施の形態にかかる設計対象を含むシステムＬＳＩのハードウェア構成を示すブロック図である。 外部装置のインターフェースであるバスの仕様（ライト時のタイミングチャート）を示す説明図である。 外部装置のインターフェースであるバスの仕様（リード時のタイミングチャート）を示す説明図である。 外部装置のインターフェースである送信器の仕様を示す説明図である。 外部装置のインターフェースである受信器の仕様を示す説明図である。 ＣＰＵで送受信されるパケットの構成を示す説明図である。 送信パケットの構成を示す説明図である。 要求定義であるシステムＬＳＩの要求項目リストを示す説明図である。 要求定義であるシステムＬＳＩのユースケース図である。 要求定義された結果物であるシステムＬＳＩの分析クラス図である。 要求定義された結果物であるシステムＬＳＩのシーケンス図である。 シリアル送受信システムを含むシステムＬＳＩの設計クラス図である。 概念モデルの実装コードを示す説明図である。 シリアル送受信システムを含むシステムＬＳＩの検証項目を示す説明図である。 シリアル送受信システムを含むシステムＬＳＩの検証シナリオを示す説明図である。 シリアル送受信システムを含むシステムＬＳＩの機能モデルの実装コード生成処理手順を示すフローチャートである。 図１７に示した設計クラス図を分割することによって得られた分割設計クラス図を示す説明図である。 分割設計クラス図によってあらわされるモジュール間を接続する通信路を示す説明図である。 シリアル送受信システムを含むシステムＬＳＩの機能モデルの実装コードの生成例を示す説明図である。 シリアル送受信システムを含むシステムＬＳＩのアーキテクチャモデルのクラス図の一例を示す説明図である。 機能モデルとアーキテクチャモデルとのマッピングを示す説明図である。 シリアル送受信システムを含むシステムＬＳＩの動作モデルの実装コード生成処理手順を示すフローチャートである。 属性内の記述がバスモデルの記述に置き換えられた分割設計クラス図を示す説明図である。 各モジュールの見積もり処理時間の実装コードへの追加例を示す説明図である。 シリアル送受信システムを含むシステムＬＳＩのＩＣＡモデルの実装コード生成処理手順を示すフローチャートである。 シリアル送受信システムを含むシステムＬＳＩの通信路が決定された機能モデルを示す構造図である。 図３１に示した構造図内の通信路にインターフェースラッパを挿入した構造図である。 ＩＣＡモデルのエンコーダモジュールの内部構造の一例を示す説明図である。 ＩＣＡモデルのエンコーダモジュールの実装コードの一例を示す説明図である。 シリアル送受信システムを含むシステムＬＳＩのソフトウェアモデルの実装コード生成処理手順を示すフローチャートである。 アーキテクチャモデルに機能モデルの一部をソフトウェアによりマッピングをおこなった例を示す説明図である。 ソフトウェアモデルにおける設計クラス図を示す説明図である。 従来のＬＳＩの開発処理手順を示すフローチャートである。

符号の説明

１００ 要求仕様
１０１ 概念モデル
１０２ 機能モデル
１０３ アーキテクチャモデル
１０４ 動作モデル
１０５ ＩＣＡモデル
１０６ ソフトウェアモデル
４０１ 分析情報入力部
４０２ 概念モデル生成部
４０３ 機能モデル生成部
４０４ 機能モデル検証部
４０５ アーキテクチャ情報記憶部
４０６ アーキテクチャ情報抽出部
４０７ 動作モデル生成部
４０８ 動作モデル検証部
４０９ ＩＣＡモデル生成部
４１０ ＩＣＡモデル検証部
４１１ ソフトウェアモデル生成部
４１２ ソフトウェアモデル検証部

（実施の形態）
以下に、本発明の実施の形態にかかる検証支援装置、検証支援方法、検証支援プログラムおよび該プログラムを記録した記録媒体について図面を参照しつつ詳細に説明する。

（検証支援の概念）
まず、この発明の実施の形態にかかる検証支援の概念について説明する。図１は、この発明の実施の形態にかかる検証支援の概念図である。

図１において、設計者は、設計対象を含むシステムＬＳＩの顧客からの要求仕様１００について、ＵＭＬ（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ）を用いてオブジェクト指向分析をおこない、その分析結果を概念モデル１０１としてモデリングする。概念モデル１０１とは、設計対象の概念的な分析結果をあらわすモデルである。概念モデル１０１は、完全に実装依存しないモデルであり、具体的には、物理的なアーキテクチャや時間の概念が抽象化され、設計対象の基本機能を中心にモデリングされたものである。

概念モデル１０１は、具体的には、システムＬＳＩの要求仕様の分析結果を、ＵＭＬやＣ＋＋でモデリングした結果物であり、ＵＭＬモデル、Ｃ＋＋モデル、および検証シナリオのすべてを含めた総称である。この概念モデル１０１では、要求仕様１００の誤解やミス、またはアルゴリズムの検証をおこなうことができる。

また、機能モデル１０２は、概念モデル１０１から、設計対象であるシステムＬＳＩを構成するモジュールの分割、分割されたモジュールの並行または並列性を抽出することによって構築されたモデルである。機能モデル１０２は、時間の概念が存在しない。この機能モデルでは、モジュール分割の正当性や、並列、並行性の正確さを検証することができる。

また、アーキテクチャモデル１０３は、バスやＩＰ（Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ）などの既存設計の物理的なハードウェア部品をあらわすモデルである。アーキテクチャモデル１０３は、具体的には、処理リソースと、通信リソースとに大別される。処理リソースは、機能モデル１０２のモジュールをマッピングするためのモデルである。たとえば、ハードウェア処理モジュール、プロセッサ、ＲＴＯＳ、ＤＳＰなどが挙げられる。

一方、通信リソースは、機能モデルのモジュール間の通信を実現するためのチャンネルをモデリングしたモデルである。たとえば、バス、メモリ、ハードウェアモジュール間の信号線などが挙げられる。このアーキテクチャモデル１０３では、既存設計の物理的なハードウェア部品を用いているため、検証をおこなう必要はない。

また、動作モデル１０４は、概念的に、機能モデル１０２をアーキテクチャモデル１０３にマッピングした結果物である。具体的には、機能モデル１０２のプロセスをアーキテクチャモデル１０３の処理リソースにマッピングし、機能の通信チャンネルは、通信リソースを用いて組み立てる。この動作モデル１０４では、顧客が要求した動作（性能）を満足するかどうかの検証をおこなうことができる。

つぎに、動作モデル１０４についてＨＷ／ＳＷ分割をおこない、ハードウェア実装をあらわすＩＣＡ（Ｉｎｔｅｒｆａｃｅ Ｃｙｃｌｅ Ａｃｃｕｒａｔｅ）モデル１０５とソフトウェア実装をあらわすソフトウェアモデル１０６とを生成する。

ＩＣＡモデル１０５は、モジュール外のインターフェースについてはサイクル精度によって、モジュール内部は動作レベルによって構築したモデルである。このＩＣＡモデル１０５を高位合成することによってＲＴＬ記述１０７を生成する。このＩＣＡモデル１０５では、インターフェースの正確さの検証をおこなうことができる。

また、ソフトウェアモデル１０６は、設計対象を含むシステムＬＳＩを構成するソフトウェアのタスク分割をおこない、仮想ＯＳ上に実行するモデルである。このソフトウェアモデル１０６についてコード生成処理をおこなうことによって、実装コード１０８を生成する。このソフトウェアモデル１０６では、ソフトウェアの機能を検証することができる。

（各モデルの抽象度）
つぎに、図１に示した各モデルの抽象度について説明する。図２は、図１に示した各モデル１０１〜１０６の抽象度をあらわすグラフである。図２のグラフは、原点を中心とした３軸によって構成されている。各軸は、それぞれ「機能」の抽象度、「構造」の抽象度、「時間」の抽象度をあらわしており、原点から離れるにしたがって抽象度が高くなる。

（検証支援装置のハードウェア構成）
つぎに、この発明の実施の形態にかかる検証支援装置のハードウェア構成について説明する。図３は、この発明の実施の形態にかかる検証支援装置のハードウェア構成を示すブロック図である。

図３において、検証支援装置は、ＣＰＵ３０１と、ＲＯＭ３０２と、ＲＡＭ３０３と、ＨＤＤ（ハードディスクドライブ）３０４と、ＨＤ（ハードディスク）３０５と、ＦＤＤ（フレキシブルディスクドライブ）３０６と、着脱可能な記録媒体の一例としてのＦＤ（フレキシブルディスク）３０７と、ディスプレイ３０８と、Ｉ／Ｆ（インターフェース）３０９と、キーボード３１０と、マウス３１１と、スキャナ３１２と、プリンタ３１３と、を備えている。また、各構成部はバス３００によってそれぞれ接続されている。

ここで、ＣＰＵ３０１は、検証支援装置の全体の制御を司る。ＲＯＭ３０２は、ブートプログラムなどのプログラムを記憶している。ＲＡＭ３０３は、ＣＰＵ３０１のワークエリアとして使用される。ＨＤＤ３０４は、ＣＰＵ３０１の制御にしたがってＨＤ３０５に対するデータのリード／ライトを制御する。ＨＤ３０５は、ＨＤＤ３０４の制御で書き込まれたデータを記憶する。

ＦＤＤ３０６は、ＣＰＵ３０１の制御にしたがってＦＤ３０７に対するデータのリード／ライトを制御する。ＦＤ３０７は、ＦＤＤ３０６の制御で書き込まれたデータを記憶したり、ＦＤ３０７に記憶されたデータを検証支援装置に読み取らせたりする。

着脱可能な記録媒体として、ＦＤ３０７のほか、ＣＤ−ＲＯＭ（ＣＤ−Ｒ、ＣＤ−ＲＷ）、ＭＯ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、メモリーカードなどであってもよい。ディスプレイ３０８は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。このディスプレイ３０８は、たとえば、ＣＲＴ、ＴＦＴ液晶ディスプレイ、プラズマディスプレイなどを採用することができる。

Ｉ／Ｆ３０９は、通信回線を通じてインターネットなどのネットワークに接続され、このネットワークを介して他の装置に接続される。そして、Ｉ／Ｆ３０９は、ネットワークと内部のインターフェースを司り、外部装置からのデータの入出力を制御する。Ｉ／Ｆ３０９には、たとえばモデムやＬＡＮアダプタなどを採用することができる。

キーボード３１０は、文字、数字、各種指示などの入力のためのキーを備え、データの入力をおこなう。また、タッチパネル式の入力パッドやテンキーなどであってもよい。マウス３１１は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などをおこなう。ポインティングデバイスとして同様に機能を備えるものであれば、トラックボールやジョイスティックなどであってもよい。

スキャナ３１２は、画像を光学的に読み取り、検証支援装置内に画像データを取り込む。なお、スキャナ３１２は、ＯＣＲ機能を持たせてもよい。また、プリンタ３１３は、画像データや文書データを印刷する。プリンタ３１３には、たとえば、レーザプリンタやインクジェットプリンタを採用することができる。

（検証支援装置の機能的構成）
つぎに、この発明の実施の形態にかかる検証支援装置の機能的構成について説明する。図４は、この発明の実施の形態にかかる検証支援装置の機能的構成を示すブロック図である。

図４において、検証支援装置４００は、分析情報入力部４０１と、概念モデル生成部４０２と、機能モデル生成部４０３と、機能モデル検証部４０４と、アーキテクチャ情報記憶部４０５と、アーキテクチャ抽出部４０６と、動作モデル生成部４０７と、動作モデル検証部４０８と、ＩＣＡモデル生成部４０９と、ＩＣＡモデル検証部４１０と、ソフトウェアモデル生成部４１１と、ソフトウェアモデル検証部４１２と、から構成されている。

分析情報入力部４０１は、設計対象を含むシステムＬＳＩの顧客からの要求仕様の分析結果を示す情報（分析情報）の入力を受け付ける。ここで、分析情報とは、たとえば、ＵＭＬによって記述された設計対象のユースケース図、シーケンス図、クラス図や、設計対象に要求される基本機能項目など、コンピュータによって読取り可能な情報が挙げられる。

また、概念モデル生成部４０２は、分析情報入力部４０１によって入力された分析情報に基づいて、設計対象の基本機能がモデル化され、かつ、設計対象の物理的なアーキテクチャおよび時間の概念が抽象化された概念モデル、すなわち、図１に示した概念モデル１０１を生成する。

具体的には、概念モデル生成部４０２は、ユースケース図などの分析情報を解析して、設計対象の実装コードや、設計対象について検証すべき項目（検証項目）、回路シミュレーションによる検証処理手順を示す検証シナリオを生成する。この生成された実装コード、検証項目および検証シナリオが、図１に示した概念モデル１０１となる。

また、機能モデル生成部４０３は、分析情報入力部４０１によって入力された分析情報に基づいて、設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性を抽出することによってモデル化された機能モデルを生成する。たとえば、分析情報であるクラス図に基づいて、設計対象の機能をあらわす機能モデルを生成する。

具体的には、概念モデル生成部４０２に入力されたクラス図を機能ごとに複数に分割し、分割されたクラス図（分割クラス図）ごとに、実装コードを生成する。この生成された分割クラス図ごとの実装コードが、図１に示した機能モデル１０２となる。

機能モデル検証部４０４は、機能モデル生成部４０３によって生成された機能モデルについて、設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性が正当であるかどうかを、概念モデル生成部４０２によって生成された概念モデルに基づいて検証する。

具体的には、分割クラス図ごとの実装コードのシミュレーション結果が、概念モデルの実装コードを概念モデルの検証シナリオでシミュレーションしたシミュレーション結果と一致するかどうかを判定することによって、機能モデルの正当性を検証する。ここで、シミュレーション結果とは、ある入力データに対してどのような出力データが得られるか、ということである。

より具体的には、分割クラス図ごとの実装コードのシミュレーション結果が一致する場合は、機能モデルが正当となる。一方、不一致の場合は、機能モデルの分割、並行、並列性が正しくないため、機能モデル生成部４０３は、機能モデルの実装コードを修正する。

また、アーキテクチャ情報記憶部４０５は、バスやＩＰ（Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ）などの既存設計の物理的なハードウェア部品に関する情報を記憶する。アーキテクチャ情報記憶部４０５は、具体的には、たとえば、図３に示したＲＯＭ３０２、ＲＡＭ３０３、ＨＤ３０５、ＦＤ３０７などによってその機能を実現する。

アーキテクチャ情報抽出部４０６は、アーキテクチャ情報記憶部４０５に記憶されているアーキテクチャ情報を抽出する。処理リソースに関しては、たとえば、ハードウェア処理モジュール、プロセッサ、ＲＴＯＳ、ＤＳＰなどを抽出する。一方、通信リソースに関しては、バス、メモリ、ハードウェアモジュール間の信号線などを抽出する。このアーキテクチャ情報抽出部４０６によって抽出されたアーキテクチャ情報が、図１に示したアーキテクチャモデル１０３に相当する。

動作モデル生成部４０７は、アーキテクチャ情報抽出部４０６によって抽出されたアーキテクチャに関する情報を、機能モデル検証部４０４によって正当であることが検証された機能モデルにマッピングすることにより、設計対象の動作をモデル化した動作モデルを生成する。

具体的には、機能モデル１０２をアーキテクチャモデル１０３にマッピングすることによって、設計対象の動作モデル１０４を生成する。具体的には、機能モデル１０２のプロセスをアーキテクチャモデル１０３の処理リソースにマッピングし、機能の通信チャンネルは、通信リソースを用いて組み立てる。この組み立てにより、マッピングによって得られたモジュールの処理時間を考慮した実装コードを生成する。この生成された実装コードが、図１に示した動作モデル１０４に相当する。

動作モデル検証部４０８は、動作モデル生成部４０７によって生成された動作モデルによりモデル化された設計対象を構成するモジュールの動作タイミングが、正当であるかどうかを検証する。

具体的には、動作モデル生成部４０７によって生成された実装コードのシミュレーション結果が、概念モデルの実装コードを概念モデルの検証シナリオでシミュレーションしたシミュレーション結果と一致するかどうかを判定することによって、動作モデルの正当性を検証する。ここで、シミュレーション結果とは、ある入力データに対してどのような出力データが得られるか、ということである。

そして、一致する場合は、動作モデルが正当となり、顧客が要求した動作（性能）を満足していることとなる。一方、不一致の場合は、動作モデルが、顧客が要求した動作（性能）を満足していないこととなる。この場合、動作モデル生成部４０７は、動作モデルの実装コードを修正する。

ＩＣＡモデル生成部４０９は、動作モデル検証部４０８によって正当であることが検証された場合、機能モデルによってモデル化された設計対象を構成するモジュール間の抽象度が異なる箇所に、当該モジュール間に所定のクロックサイクル精度のインターフェースを挿入することによりＩＣＡモデルを生成する。

具体的には、動作モデル１０４についてＨＷ／ＳＷ分割をおこない、ハードウェア実装をあらわすＩＣＡモデル１０５を生成する。たとえば、モジュール間の抽象度が異なる場合に、当該モジュール間の抽象度が同等となるように、クラス図に示された、モジュール間の通信路をインターフェースラッパに置換する。

そして、インターフェースラッパに置換されたクラス図の実装コードを生成する。この生成された実装コードが、図１に示したＩＣＡモデル１０５となる。そして、このＩＣＡモデル１０５の実装コードを高位合成することにより、ＲＴＬ記述１０７を生成することができる。

ＩＣＡモデル検証部４１０は、ＩＣＡモデル生成部４０９によって生成されたＩＣＡモデル１０５に挿入されたインターフェースのクロックサイクル精度が正当であるかどうかを、概念モデル生成部４０２によって生成された概念モデル１０１に基づいて検証する。

具体的には、ＩＣＡモデル生成部４０９によって生成された実装コードのシミュレーション結果が、概念モデルの実装コードを概念モデルの検証シナリオでシミュレーションしたシミュレーション結果と一致するかどうかを判定することによって、機能モデルの正当性を検証する。ここで、シミュレーション結果とは、ある入力データに対してどのような出力データが得られるか、ということである。

そして、一致する場合は、ＩＣＡモデルが正当となる。具体的には、置換されたインターフェースラッパによってあらわされるインターフェースが正確であることとなる。一方、不一致の場合は、置換されたインターフェースラッパが不正確となる。この場合、ＩＣＡモデル生成部４０９は、ＩＣＡモデルの実装コードを修正する。

ソフトウェアモデル生成部４１１は、動作モデル検証部４０８によって正当であることが検証された場合、機能モデルによってモデル化された設計対象に基づいて、ソフトウェアによって実行可能なタスクを含むようにモデル化されたソフトウェアモデルを生成する。

具体的には、動作モデル１０４についてＨＷ／ＳＷ分割をおこない、ソフトウェア実装をあらわすソフトウェアモデル１０６（図１を参照。）を生成する。たとえば、設計対象を含むシステムＬＳＩを構成するソフトウェアのタスク分割をおこない、仮想ＯＳ上に実行可能な実装コードを生成する。

ソフトウェアモデル検証部４１２は、ソフトウェアモデル生成部４１１によって生成されたソフトウェアモデルに含まれているタスクが、正当であるかどうかを、概念モデル生成部４０２によって生成された概念モデルに基づいて検証する。

具体的には、ソフトウェアモデル生成部４１１によって生成された実装コードのシミュレーション結果が、概念モデルの実装コードを概念モデルの検証シナリオでシミュレーションしたシミュレーション結果と一致するかどうかを判定することによって、ソフトウェアモデル１０６の正当性を検証する。ここで、シミュレーション結果とは、ある入力データに対してどのような出力データが得られるか、ということである。

そして、一致する場合は、ソフトウェアモデル１０６の実装コードによってあらわされる機能が正当となる。そして、このソフトウェアモデル１０６の実装コードを取り込んだ、設計対象全体の実装コード１０８（図１を参照。）を生成する。一方、不一致の場合は、ソフトウェアモデル１０６の実装コードによってあらわされる機能が不正確となる。この場合、ソフトウェアモデル生成部４１１は、ソフトウェアモデルの実装コードを修正する。

なお、上述した分析情報入力部４０１、概念モデル生成部４０２、機能モデル生成部４０３、機能モデル検証部４０４、アーキテクチャ情報抽出部４０６、動作モデル生成部４０７、動作モデル検証部４０８、ＩＣＡモデル生成部４０９、ＩＣＡモデル検証部４１０、ソフトウェアモデル生成部４１１およびソフトウェアモデル検証部４１２は、具体的には、たとえば、図３に示したＲＯＭ３０２、ＲＡＭ３０３、ＨＤ３０５、ＦＤ３０７などに記録されたプログラムをＣＰＵ３０１が実行することによって、またはＩ／Ｆ３０９によって、その機能を実現する。

（検証支援装置の検証支援処理手順）
つぎに、この発明の実施の形態にかかる検証支援装置の検証支援処理手順について説明する。図５は、この発明の実施の形態にかかる検証支援装置の検証支援処理手順を示すフローチャートである。

図５において、まず、設計者は、設計対象を含むシステムＬＳＩの顧客からの要求仕様１００を分析して、分析結果をあらわす分析情報を入力する（ステップＳ５０１）。

つぎに、入力された分析情報に基づいて、設計対象の実装コードや、設計対象について検証すべき項目（検証項目）、回路シミュレーションによる検証処理手順を示す検証シナリオなどの概念モデル１０１を生成する（ステップＳ５０２）。生成された概念モデル１０１の正当性については、設計者が検証する。

つぎに、設計対象の機能デモル１０２を生成する（ステップＳ５０３）。具体的には、概念モデル生成部４０２に入力されたクラス図を機能ごとに複数に分割し、分割されたクラス図（分割クラス図）ごとに、機能モデル１０２の実装コードを生成する。

そして、概念モデル１０１の実装コードと機能モデル１０２の実装コードのシミュレーションをおこなう（ステップＳ５０４）。つぎに、概念モデル１０１の実装コードのシミュレーション結果と、機能モデル１０２の実装コードのシミュレーション結果とが、一致するかどうかの判定、すなわち、機能モデル検証をおこなう（ステップＳ５０５）。

不一致の場合（ステップＳ５０５：Ｎｏ）、機能モデル１０２を修正する（ステップＳ５０６）。具体的には、たとえば、概念モデル１０１のクラス図を再度、分割しなおして、分割クラス図を生成し、その分割クラス図ごとに実装コードを生成する。そして、ステップＳ５０４に移行する。

一方、一致する場合（ステップＳ５０５：Ｙｅｓ）、機能モデル１０２が正当であると判断される。そして、正当性が検証された検証済みの機能モデル１０２に、アーキテクチャモデル１０３をマッピングして、動作モデル１０４を生成する（ステップＳ５０７）。そして、動作モデル１０４の実装コードのシミュレーションをおこなう（ステップＳ５０８）。

つぎに、概念モデル１０１の実装コードのシミュレーション結果と、動作モデル１０４の実装コードのシミュレーション結果とが、一致するかどうかの判定、すなわち、動作モデル検証をおこなう（ステップＳ５０９）。

不一致の場合（ステップＳ５０９：Ｎｏ）、動作モデル１０４を修正する（ステップＳ５１０）。具体的には、たとえば、アーキテクチャ情報記憶部４０５から再度アーキテクチャ情報を抽出して、正当性が検証された検証済の機能モデル１０２に、あらたなアーキテクチャモデル１０３をマッピングして、動作モデル１０４を生成する。そして、ステップＳ５０８に移行する。

一方、一致する場合（ステップＳ５０９：Ｙｅｓ）、動作モデル１０４が正当であると判断される。そして、正当性が検証された検証済の動作モデル１０４に対しＨＷ／ＳＷ分割をおこない、ＩＣＡモデル１０５とソフトウェアモデル１０６を生成する（ステップＳ５１１、ステップＳ５１６）。

そして、生成されたＩＣＡモデル１０５の実装コードのシミュレーションをおこなう（ステップＳ５１２）。つぎに、概念モデル１０１の実装コードのシミュレーション結果と、ＩＣＡモデル１０５の実装コードのシミュレーション結果とが、一致するかどうかの判定、すなわち、ＩＣＡモデル検証をおこなう（ステップＳ５１３）。

不一致の場合（ステップＳ５１３：Ｎｏ）、ＩＣＡモデル１０５を修正する（ステップＳ５１４）。具体的には、たとえば、インターフェースラッパの内容を変更することによって、ＩＣＡモデル１０５を修正する。そして、ステップＳ５１２に移行する。

一方、一致する場合（ステップＳ５１３：Ｙｅｓ）、ＩＣＡモデル１０５が正当であると判断される。そして、高位合成をおこなって（ステップＳ５１５）、ＲＴＬ記述を生成する。

また、生成されたソフトウェアモデル１０６の実装コードのシミュレーションをおこなう（ステップＳ５１７）。つぎに、概念モデル１０１の実装コードのシミュレーション結果と、ソフトウェアモデル１０６の実装コードのシミュレーション結果とが、一致するかどうかの判定、すなわち、ソフトウェアモデル検証をおこなう（ステップＳ５１８）。

不一致の場合（ステップＳ５１８：Ｎｏ）、ソフトウェアモデル１０６を修正する（ステップＳ５１９）。具体的には、たとえば、設計対象を含むシステムＬＳＩを構成するソフトウェアのタスク分割を再度おこない、仮想ＯＳ上に実行可能な実装コードを生成する。

一方、一致する場合（ステップＳ５１８：Ｙｅｓ）、ソフトウェアモデル１０６が正当であると判断される。そして、正当であることが検証された検証済のソフトウェアモデル１０６の実装コードを取り込んだ、設計対象全体の実装コード１０８を生成する（ステップＳ５２０）。

この検証処理手順によれば、モデルごとに、段階的に検証をおこなうため、直前までに検証されたモデルについては、検証のやり直しをおこなうことなく、有効なモデルとして活用することができるため、検証処理において手戻りが発生せず、検証処理の効率化を図ることができる。

なお、上述した図５のフローチャートでは、ステップＳ５１１〜５１５までの処理手順と、ステップＳ５１６〜５２０までの処理手順とを並列に実行することとしているが、ステップＳ５１１〜５１５までの処理手順のあとに、ステップＳ５１６〜５２０までの処理手順を実行することとしてもよく、また、ステップＳ５１６〜５２０までの処理手順のあとに、ステップＳ５１１〜５１５までの処理手順を実行することとしてもよい。

（検証処理の具体例）
つぎに、上述した検証処理の具体例について説明する。

（システムＬＳＩのハードウェア構成）
まず、設計対象を含むシステムＬＳＩのハードウェア構成について説明する。図６は、この発明の実施の形態にかかる設計対象を含むシステムＬＳＩのハードウェア構成を示すブロック図である。この設計対象は、たとえば、顧客から設計業務を引き受けた情報であり、ここでは、その設計対象を、シリアル送受信システムとして説明する。

図６において、システムＬＳＩ６００は、設計対象の一例として挙げられたシリアル送受信システム６０１と、受信器６０２と、送信器６０３と、ＣＰＵ６０４と、その他デバイス６０５と、これらを接続するバス６０６と、によって構成されている。

ここで、受信器６０２は、受信パケット６１１を受信し、シリアル送受信システム６０１に供給する。送信器６０３は、シリアル送受信システム６０１から供給された情報を送信パケット６１２として図示しない外部機器に送信する。シリアル送受信システム６０１は、たとえば、ＢＣＨ（６２，４８）で符号化および復号化をおこなう。

そして、受信器６０２からの受信パケット６１１を復号し、この復号したパケット６１３をＣＰＵ６０４に供給する。また、ＣＰＵ６０４からのパケット６１４を符号化する。ＣＰＵ６０４は、シリアル送受信システム６０１からのパケット６１３を用いて、その他デバイス６０５とともにシステムＬＳＩ６００の機能を実行する。

（外部装置のインターフェース仕様）
つぎに、外部装置（受信器６０２、送信器６０３、ＣＰＵ６０４、その他デバイス６０５）のインターフェース仕様について説明する。図７および図８は、外部装置のインターフェースであるバスの仕様を示す説明図である。特に、図７は、ライト時のタイミングチャートであり、図８は、リード時のタイミングチャートである。

図７および図８において、「ＰＣＬＫ」は、ビット幅１の入力クロック信号である。「ＰＡＤＤＲ」は、ビット幅３２のアドレス出力信号である。「ＰＷＲＩＴＥ」は、ビット幅１のリード／ライト制御出力信号である。「ＰＳＥＬ」は、ビット幅１のチップセレクト出力信号である。「ＰＥＮＡＢＬＥ」は、ビット幅１の出力イネーブル信号である。「ＰＲＤＡＴＡ」は、ビット幅３２のデータ入出力信号である。ＣＰＵ６０４に対するバスの仕様は、バス標準プロトコルに準拠しており、ＣＰＵ６０４について組み込みプロセッサコアを採用することとしている。

図９は、外部装置のインターフェースである送信器６０３の仕様を示す説明図である。図９において、「ｃｌｋ」は、ビット幅１の入力クロック信号である。「ＩＳＴＡＲＴ」は、ビット幅１のスタートパルス入力信号である。「ＩＤＡＴＡ」は、ビット幅１のデータ入力信号である。シリアル送受信システム６０１から送信器６０３への入力仕様は、スタートパルス入力信号のｉクロックのパルスを検出すると同時に、送信器６０３がクロックのポジティブエッジごとに１ビットずつデータを取り込むという仕様である。また、入力クロック周波数は、１００ＭＨｚとしている。

図１０は、外部装置のインターフェースである受信器６０２の仕様を示す説明図である。図１０において、「ｃｌｋ」は、ビット幅１の出力クロック信号である。「ＯＳＴＡＲＴ」は、ビット幅１のスタートパルス出力信号である。「ＯＤＡＴＡ」は、ビット幅１のデータ出力信号である。

（シリアル送受信システムに要求される基本機能）
つぎに、設計対象であるシリアル送受信システム６０１に要求される基本機能について説明する。シリアル送受信システム６０１に要求される基本機能は、（１）パケットの送信機能と、（２）パケットの受信機能と、（３）初期化機能である。

（１）パケットの送信機能は、以下のとおりである。
（ｉ）ＣＰＵ６０４が作成したパケット６１４をＢＣＨ（６２，４８）で符号化して送信器６０３に転送する転送機能。
（ii）ＣＰＵ６０４が作成したパケット６１４の不正を検出してＣＰＵ６０４にエラーを知らせる不正検出機能。
（iii）ＣＰＵ６０４から連続的に大量なパケット６１４が送信されてきた際に処理が間に合わないとき、ＣＰＵ６０４にエラーを知らせ、送信パケット６１２を破棄するパケット破棄機能。
（ｖi）送信器６０３への出力スループット：０〜１Ｍｂｐｓ
また、（２）パケットの受信機能は、以下の通りである。
（ｖii）ＢＣＨ（６２，４８）で受信器６０２から連続して符号化された受信パケット６１１を受信し、受信パケット６１１を復号してＣＰＵ６０４に通知し、復号したパケット６１３をＣＰＵ６０４に受信させる復号機能。
（ｖiii）受信器６０２から大量の受信パケット６１１を送ってきた際に処理が間に合わない場合は受信パケット６１１の廃棄を許容するパケット廃棄許容機能。
（iｘ）受信パケット６１１の中に誤り訂正ができないパケットが存在する場合、ＣＰＵ６０４にエラーを知らせ、受信パケット６１１を破棄するパケット破棄機能。
（ｘ）受信パケット６１１に対して２ビットまで訂正可能、４ビットまでエラーの検出可能とする訂正・検出機能。
（ｘi）受信器６０２からの入力スループット：０〜１Ｍｂｐｓ
さらに、（３）初期化機能は、以下の通りである。
（ｘii）ＣＰＵ６０４から初期化指示するソフトリセット機能。
（ｘiii）リセット信号からも初期化指示するハードリセット機能。

（パケットの構成）
つぎに、ＣＰＵ６０４で送受信されるパケット６１３，６１４の構成について説明する。図１１は、ＣＰＵ６０４で送受信されるパケット６１３，６１４の構成を示す説明図であり、図１２は、送信パケット６１２の構成を示す説明図である。図１１において、パケット６１３，６１４は、１６ビットのヘッダ部１１０１と、３２ビットのデータ部１１０２から構成されている。ヘッダ部１１０１はパケット識別番号（１０１０１０１０１０１０１０１０）２とされている。

また、図１２において、送信パケット６１２は、図１１に示した１６ビットのヘッダ部１１０１および３２ビットのデータ部１１０２に、ＢＣＨ（６２，４８）で符号化された１４ビットの冗長符号部１２０１が付加された構成である。また、受信パケット６１１は、図示はしないが、送信パケット６１２との構成にさらに通信路によるエラービットが付加された構成である。この図６から図１２までの情報の内容が、顧客が要求する要求仕様１００となる。

（要求定義の内容）
つぎに、図６から図１２までに示した要求仕様の内容を定義した要求定義について説明する。図１３は、要求定義であるシステムＬＳＩ６００の要求項目リストを示す説明図であり、図１４は、要求定義であるシステムＬＳＩ６００のユースケース図である。

図１３に示した要求項目リスト１３００において、このシステムＬＳＩ６００には、「受信パケットを最大２重誤り訂正できる」（項目１３０１）、「受信パケットの４重誤りまで検出できる」（項目１３０２）、「受信パケットを受信器経由で受信できる」（項目１３０３）、「受信パケットをＢＣＨ（６０，４８）で復号化できる」（項目１３０４）、「ＣＰＵから初期化できる」（項目１３０５）、「リセット信号から初期化できる」（項目１３０６）、「送信パケットを送信器経由で送信できる」（項目１３０７）、「送信パケットをＢＣＨ（６２，４８）で符号化できる」（項目１３０８）の機能が要求される。

また、図１４に示したユースケース図１４００は、図１３に示した要求項目リスト１３００によって要求されている機能を図表化したものであり、ＵＭＬにしたがって記述された図表である。図１４において、図６に示したシリアル送受信システム６０１は、ユースケース１４０１〜１４０３によってあらわされる機能「パケットを受信する」、「初期化する」および「パケットを送信する」を備えている。また、ユースケース図１４００には、シリアル送受信システム６０１に関連するアクターとして、ＣＰＵ１４１１、リセット信号１４１２、受信器１４１３および送信器１４１４が図表化されている。

図１４に示したユースケース図１４００において、ユースケース１４０１は、アクター１４１３からパケットを受信する。そして、受信したパケットをアクター１４１１に送信する。また、ユースケース１４０２は、アクター１４１１およびアクター１４１２から初期化する。さらに、ユースケース１４０３は、アクター１４１１からパケットを受信して、アクター１４１４に送信する。

（分析情報の内容）
つぎに、図１３および図１４に示した要求定義（要求項目リスト１３００、ユースケース図１４００）の分析結果を示す分析情報について説明する。図１５は、要求定義された結果物であるシステムＬＳＩ６００の分析クラス図であり、図１６は、要求定義された結果物であるシステムＬＳＩ６００のシーケンス図である。

図１５に示した分析クラス図１５００には、シリアル送受信システム６０１に必要なデータや手順などを管理する《control》クラス１５０１と、シリアル送受信システム６０１内部で当該システム特有の処理を担当する<Entity>クラス１５０２〜１５０８が記述されている。《control》クラス１５０１は、シリアス送受信システム６０１をあらわしている。《entity》クラス１５０２〜１５０８は、送信パケット６１２、受信パケット６１１、パケット６１３，６１４、冗長符号部１２０１、エラービット、ヘッダ部１１０１、データ部１１０２をあらわしている。

図１５に示した分析クラス図１５００において、《control》クラス１５０１（シリアル送受信システム６０１）は、アクター１４１４（送信器６０３）からパケットを送信する。また、アクター１４１１（ＣＰＵ６０４）との間で送受信／初期化をおこなう。さらに、《entity》クラス１５０２（送信パケット６１２）の送信、《entity》クラス１５０３（受信パケット６１１）の受信、アクター１４１２（リセット信号）からの初期化をおこなう。また、《entity》クラス１５０３（受信パケット６１１）を受信したアクター１４１３（受信器６０２）からパケットを受信する。

また、図１５に示した分析クラス図１５００において、《entity》クラス１５０２（送信パケット６１２）は、《entity》クラス１５０４（パケット６１３，６１４）および《entity》クラス１５０５（冗長符号部１２０１）を集約している。また、《entity》クラス１５０３（受信パケット６１１）は、《entity》クラス１５０５（冗長符号部１２０１）および《entity》クラス１５０６（エラービット）を集約している。さらに、《entity》クラス１５０４（パケット６１３、６１４）は、《entity》クラス１５０７（ヘッダ部１１０１）および《entity》クラス１５０８（データ部１１０２）を集約している。これにより、アクター１４１１（ＣＰＵ６０４）は、《entity》クラス１５０４（パケット６１３、６１４）の作成／受信をおこなっていることがわかる。

また、図１６に示したシーケンス図１６００は、パケットを正常に送信する場合の動作を示している。このシーケンス図１６００では、シーケンス番号順、すなわち、シーケンス番号１．０（「パケットを作成する（）」）→シーケンス番号１．１（「パケットを受信する（）」）、→シーケンス番号１．２（「パケットを符号化する（）」）、→シーケンス番号１．３（「送信パケットを作成する（）」）、シーケンス番号１．４（「送信パケットを送信する（）」）の順に送信処理がおこなわれることを示している。

つぎに、このシリアル送受信システムを含むシステムＬＳＩの設計クラス図について説明する。図１７は、シリアル送受信システムを含むシステムＬＳＩの設計クラス図である。

この設計クラス図１７００において、クラス１７０１は、シリアル送受信システムを示す名称「ＥＣＣ＿ＳＩＯ」が記述されているクラス名１７０２と、クラス１７０１が持つ静的な性質を示す属性１７０３（メンバ変数）と、クラス１７０１が持つ動的な性質を示す操作１７０４（メンバ関数）と、を含んでいる。操作１７０４は、ＣＰＵを示すクラス１７０５と符号化を示すクラス１７０６に働きかけている。この図１７に示した設計クラス図１７００を元にして、概念モデル１０１の実装コードが生成される。図１７に概念モデル１０１の実装コードの一記述例を示す。図１８は、概念モデル１０１の実装コード１８００を示す説明図である。この実装コード１８００は、Ｃ＋＋言語によってモデル化されているコードである。

（検証項目の内容）
つぎに、シリアル送受信システムを含むシステムＬＳＩの検証項目について説明する。図１９は、シリアル送受信システムを含むシステムＬＳＩの検証項目を示す説明図である。

図１９では、対象ユースケースを、図１４で示したユースケース１４０１に着目している。この検証項目１９００において、項目『シーケンス』の「基本パス」とは、パケットの正常な送信処理、すなわち、図１６に示したシーケンス番号１．０〜１．１までの処理を示している。

（検証シナリオの内容）
つぎに、シリアル送受信システムを含むシステムＬＳＩの検証シナリオについて説明する。図２０は、シリアル送受信システムを含むシステムＬＳＩの検証シナリオを示す説明図である。この検証シナリオ２０００は、図１５に示したシーケンス図１５００と図１９に示した検証項目１９００を用いて生成される。

この検証シナリオ２０００を用いたシミュレーションによって検出された仕様上のミスについて、例を挙げて説明する。ＣＰＵに常にエラーの通知を行っているという検証結果が得られた場合、パケット受信エラーが発生したときにシリアル送受信システムをエラー状態にしたが、次のパケットを正常に受信してもシステムがエラー状態のままとなる仕様上のミスが検出される。このため、修正処理として、ＣＰＵがエラー受信した後にシリアル送受信システムのエラー状態をクリアすることとする。これにより、仕様ミスを解消することができる。

（機能モデルの実装コード生成処理手順）
つぎに、シリアル送受信システムを含むシステムＬＳＩの機能モデルの検証処理手順について説明する。図２１は、シリアル送受信システムを含むシステムＬＳＩの機能モデルの実装コード生成処理手順を示すフローチャートである。図２１に示す処理手順は、図５のステップＳ５０３に示した処理ステップの詳細な処理手順を示している。

まず、ステップＳ５０２において生成された概念モデルの設計クラス図（図１７を参照。）を、並行、並列なモジュールに分割する（ステップＳ２１０１）。図２２は、図１７に示した設計クラス図を分割することによって得られた分割設計クラス図を示す説明図である。

図１７に示した設計クラス図は、図２２において、トップモジュールに関する分割設計クラス図２２１０と、コントローラモジュールに関する分割設計クラス図２２２０と、エンコーダモジュールに関する分割設計クラス図２２３０と、デコーダモジュールに関する分割設計クラス図２２４０と、に分割されている。

そして、この分割設計クラス図２２１０〜２２４０によってあらわされるモジュール間を接続する通信路を決定する（ステップＳ２１０２）。図２３は、分割設計クラス図によってあらわされるモジュール間を接続する通信路を示す説明図である。

トップモジュール２３０１は、ポート２３１１〜２３１５を有している。このポート２３１１〜２３１５は、トップモジュールに関する分割設計クラス図２２１０の属性２２１１に記述されている。具体的には、ポート２３１１は「packet_i:sc_fifo_in<Packet>」を示しており、ＣＰＵからのパケット<Packet>を入力する入力ポートである。ポート２３１２は「packet_o:sc_fifo_out<Packet>」を示しており、パケット<Packet>をＣＰＵに出力する出力ポートである。ポート２３１３は「error_o:sc_fifo_out<ERR_TYPE>」を示しており、エラータイプ情報<ERR_TYPE>をＣＰＵに出力する出力ポートである。

また、ポート２３１４は「encoded_packet_o:sc_fifo_out<EncodedPacket>」を示しており、符号化されたパケット<EncodedPacket>を出力する出力ポートである。ポート２３１５は「received_packet_i:sc_fifo_in<ReceivedPacket>」を示しており、外部から受信されたパケット<ReceivedPacket>を入力する入力ポートである。

コントローラモジュール２３０２は、ポート２３２１〜２３２７を有している。このポート２３２１〜２３２７は、コントローラモジュール２３０２に関する分割設計クラス図２２２０の属性２２２１に記述されている。具体的には、ポート２３２１は「cpu_packet_i:sc_fifo_in<Packet>」を示しており、ＣＰＵからのパケット<Packet>を入力する入力ポートである。ポート２３２２は「cpu_packet_o:sc_fifo_out<Packet>」を示しており、パケット<Packet>をＣＰＵに出力する出力ポートである。ポート２３２３は「error_o:sc_fifo_out<ERR_TYPE>」を示しており、エラータイプ情報<ERR_TYPE>をＣＰＵに出力する出力ポートである。

また、ポート２３２４は「encoder_packet_o:sc_fifo_out<Packet>」を示しており、パケット<Packet>をエンコーダモジュールに出力する出力ポートである。ポート２３２５は「encoder_status_i:sc_fifo_in<bool>」を示しており、エンコーダモジュール２３０３のステータス情報<bool>を入力する入力ポートである。ポート２３２６は「decoder_packet_i:sc_fifo_in<Packet>」を示しており、デコーダモジュールからパケット<Packet>を入力する入力ポートである。ポート２３２７は「decoder_error_i:sc_fifo_in<ERR_TYPE>」を示しており、デコーダモジュールからエラータイプ情報<ERR_TYPE>を入力する入力ポートである。

エンコーダモジュール２３０３は、ポート２３３１〜２３３３を有している。このポート２３３１〜２３３３は、エンコーダモジュール２３０３に関する分割設計クラス図２２３０の属性２２３１に記述されている。具体的には、ポート２３３１は「packet_i:sc_fifo_in_if<Packet>」を示しており、パケット<Packet>を入力する入力ポートである。ポート２３３２は「status_o:sc_fifo_out<bool>」を示しており、エンコーダモジュール２３０３のステータス情報<bool>を出力する出力ポートである。ポート２３３３は「packet_o:sc_fifo_out_if<EncodedPacket>」を示しており、エンコーダモジュール２３０３によって符号化されたパケット<EncodedPacket>を出力する出力ポートである。

デコーダモジュール２３０４は、ポート２３４１〜２３４３を有している。このポート２３４１〜２３４３は、デコーダモジュール２３０４に関する分割設計クラス図２２４０の属性２２４１に記述されている。具体的には、ポート２３４１は「packet_o:sc_fifo_out<Packet>」を示しており、パケット<Packet>を出力する出力ポートである。ポート２３４２は「error_o:sc_fifo_out<ERR_TYPE>」を示しており、エラータイプ情報<ERR_TYPE>を出力する出力ポートである。ポート２３４３は「packet_i:sc_fifo_in<ReceivedPacket>」を示しており、受信されたパケット<ReceivedPacket>を入力する入力ポートである。

このように、分割設計クラス図２２１０〜２２４０の属性を用いて、ポート２３１１〜２３１５、ポート２３２１〜２３２７、ポート２３３１〜２３３３、ポート２３４１〜２３４３どうしを接続して、通信路２３５１〜２３５９を決定する。この通信路２３５１〜２３５９は、具体的にはＦＩＦＯ方式で通信をおこなう通信路である。

また、図２１において、通信路を決定した後、機能モデルの実装コードを生成する（ステップＳ２１０３）。ここで、シリアル送受信システムを含むシステムＬＳＩの機能モデルの実装コードの生成例について説明する。図２４は、シリアル送受信システムを含むシステムＬＳＩの機能モデルの実装コードの生成例を示す説明図である。

図２４では、エンコーダモジュール２３０３に関する分割設計クラス図２２３０から生成した、エンコーダモジュール２３０３の実装コード２４００を示している。なお、図示はしないが、トップモジュールに関する分割設計クラス図２２１０、コントローラモジュール２３０２に関する分割設計クラス図２２２０、およびデコーダモジュール２３０４に関する分割設計クラス図２２４０についても、それぞれ実装コードを生成する。そして、図５のステップＳ５０４では、各分割設計クラス図２２１０〜２２４０の実装コードのシミュレーションを実行することとなる。

このあと、図５のステップＳ５０５において、このシミュレーション結果と、概念モデルの実装コードのシミュレーション結果との一致判定をおこない、一致する場合（ステップＳ５０５：Ｙｅｓ）、図２２に示したモジュール分割が正当であり、また、モジュール分割の並列、並行性が正確であることとなる。

一方、一致しない場合（ステップＳ５０５：Ｎｏ）、図２２に示したモジュール分割が正当でなく、また、モジュール分割の並列、並行性が不正確であるとして、図５のステップＳ５０６において、図２１のステップＳ２１０３で生成された実装コードの修正処理をおこなう。この機能モデル検証により、概念モデルと同一の検証結果になることを確認することができる。

（シリアル送受信システムを含むシステムＬＳＩのアーキテクチャモデル）
つぎに、シリアル送受信システムを含むシステムＬＳＩのアーキテクチャモデルについて説明する。図２５は、シリアル送受信システムを含むシステムＬＳＩのアーキテクチャモデルのクラス図の一例を示す説明図である。アーキテクチャモデルは、バスやＩＰなどの既存設計の物理的なハードウェア部品をあらわすモデルであり、ここでは、バスモデルをあらわしている。

アーキテクチャモデルは、基本的に事前に用意され、検証済みのライブラリとして提供され、図２５では、検証済みのバスモデルが記述されている。このように、このアーキテクチャモデルでは、既存設計の物理的なハードウェア部品を用いているため、検証をおこなう必要はない。

（シリアル送受信システムを含むシステムＬＳＩの動作モデル）
つぎに、シリアル送受信システムを含むシステムＬＳＩの動作モデルについて説明する。動作モデルは、上述したように、概念的に、機能モデルをアーキテクチャモデルにマッピングした結果物である。図２６は、機能モデルとアーキテクチャモデルとのマッピングを示す説明図である。

図２６において、機能モデル２６００は、図２３に示したように、外部から受信したパケットをデコーダ２６０２が入力して復号し、コントローラ２６０３に供給する。コントローラ２６０３は復号されたパケットをエンコーダ２６０４に出力し、エンコーダ２６０４はパケットを符号化する。

アーキテクチャモデル２６１０は、バスやＩＰなどの既存設計の物理的なハードウェア部品をあらわすモデルであり、ここでは、プロセッサ２６１１、メモリ２６１２、外部入力Ｉ／Ｆ２６１３、外部出力Ｉ／Ｆ２６１４、ハードウェア２６１５、ハードウェア２６１６、ハードウェア２６１７、およびこれらを接続するバス２６１８から構成されている。

そして、このアーキテクチャモデル２６１０に、機能モデル２６００をマッピングする。具体的には、デコーダ２６０２をハードウェア２６１５に、コントローラ２６０３をハードウェア２６１６に、エンコーダ２６０４をハードウェア２６１７にマッピングする。この図２５および図２６を用いて説明した内容は、図５のステップＳ５０７に示した処理ステップに相当する内容である。

（シリアル送受信システムを含むシステムＬＳＩの動作モデルの実装コード生成処理手順）
つぎに、シリアル送受信システムを含むシステムＬＳＩの動作モデルの実装コード生成処理手順について説明する。図２７は、シリアル送受信システムを含むシステムＬＳＩの動作モデルの実装コード生成処理手順を示すフローチャートである。この図２７に示す処理手順は、図５のステップＳ５０７に示した処理ステップの詳細な処理手順を示している。

まず、図２６に示したマッピングを実現するため、図２２に示した分割設計クラス図２２１０〜２２４０の属性２２１１〜２２４１内の記述を、図２５に示したバスモデルの記述に置き換える（ステップＳ２７０１）。図２８は、属性２２１１内の記述がバスモデルの記述に置き換えられた分割設計クラス図２２１０を示す説明図である。図２８中、アンダーラインの記述箇所において、通信路が、ＦＩＦＯ方式の記述からバスモデルの記述に置き換えられている。

つぎに、バスモデルの記述に置き換えられた分割設計クラス図２２１０〜２２４０から、機能モデルの実装コードを生成する（ステップＳ２７０２）。そして、生成された機能モデルの実装コードに、各モジュールの見積もり処理時間を追加する（ステップＳ２７０３）。

図２９は、各モジュールの見積もり処理時間の実装コードへの追加例を示す説明図である。たとえば、図２９に示した図表２９００により、デコーダ２６０２およびエンコーダ２６０４の見積もり処理時間を、それぞれ６００［ｎｓ］とすると、機能モデルの実装コード（たとえば、図２４に示した実装コード２４００）に、図表２９００に示した処理時間に関する記述２９０１を追加する。これにより、動作モデルの実装コード２９０２が生成される。そして、図５のステップＳ５０８では、動作モデルの実装コード２９０２のシミュレーションを実行することとなる。

このあと、図５のステップＳ５０８において、このシミュレーション結果と、概念モデルの実装コードのシミュレーション結果との一致判定をおこない、一致する場合（ステップＳ５０９：Ｙｅｓ）、動作モデルの実装コード２９０２のシミュレーション結果が、図１３に示した要求項目リスト１３００のすべての要求項目１３０１〜１３０８を満足することとなり、機能モデルとアーキテクチャモデルとのマッピングが正当であることとなる。

一方、一致しない場合（ステップＳ５０９：Ｎｏ）、動作モデルの実装コード２９０２のシミュレーション結果が、図１３に示した要求項目リスト１３００のすべての要求項目１３０１〜１３０８を満足しておらず、機能モデルとアーキテクチャモデルとのマッピングが正当でないこととなる。この場合、図５のステップＳ５１０において、動作モデルの実装コード２９０２の修正処理をおこなうこととなる。これにより、顧客が要求した動作（性能）を満足するかどうかの検証をおこなうことができる。

（シリアル送受信システムを含むシステムＬＳＩのＩＣＡモデルの実装コード生成処理手順）
つぎに、シリアル送受信システムを含むシステムＬＳＩのＩＣＡモデルの実装コード生成処理手順について説明する。図３０は、シリアル送受信システムを含むシステムＬＳＩのＩＣＡモデルの実装コード生成処理手順を示すフローチャートである。この図３０に示す処理手順は、図５のステップＳ５１１に示した処理ステップの詳細な処理手順を示している。

ＩＣＡモデルは、上述したように、モジュール外のインターフェースについてはサイクル精度によって、モジュール内部は動作レベルによって構築したモデルである。このＩＣＡモデルを高位合成することによってＲＴＬ記述を生成する。このＩＣＡモデルでは、インターフェースの正確さの検証をおこなうことができる。

まず、通信路が決定された機能モデルの構造図から、抽象度の異なるモジュール間を通信する通信路を検出する（ステップＳ３００１）。図３１は、シリアル送受信システムを含むシステムＬＳＩの通信路が決定された機能モデルを示す構造図である。

図３１において、シリアル送受信システムは、図１７に示した設計クラス図を、並行、並列なモジュールに分割された結果（図２１のステップＳ２１０１を参照。）、トップモジュール２３０１と、ＣＰＵモジュール３１０１と、送信器モジュール３１０２と、受信器モジュール３１０３とが、ＦＩＦＯ方式の通信路３１１１〜３１１５によって接続されたシステムである。また、トップモジュール２３０１の内部は、図２３に示した構造図と同一内容である。これらのモジュールの接続関係から、抽象度の異なるモジュール間を通信する通信路を検出する。

つぎに、検出された通信路を、インターフェースラッパに置換する（ステップＳ３００２）。図３２は、図３１に示した構造図内の通信路にインターフェースラッパを挿入した構造図である。図３２では、図３１において、エンコーダモジュール２３０２の抽象度と送信器モジュール３１０２の抽象度が異なっているため、このモジュール２３０２、３１０２間の通信路３１１４をインターフェースラッパ３２０１に挿入し、トップモジュール２３０１の抽象度を変換する。

インターフェースラッパ３２０１は、送信器モジュール３１０２のトランザクションレベルのポート３１０２ａと接続されるトランザクションレベルインターフェース３２０２と、トップモジュール２３０１に接続される２つの信号レベルポート３２０３，３２０４を備えている。このため、トランザクションレベルのポート２３１４を、送信レベルポート３２１０、３２１１に置き換える。

また、トップモジュール２３０１内部のエンコーダモジュール２３０３のトランザクションレベルのポート２３３１〜２３３３も、信号レベルのポート３２１２〜３２１６に置き換える。このポート変換により、コントローラモジュール２３０２のトランザクションレベルのポート２３２４、２３２５も、信号レベルのポート３２１７〜３２１９に変換される。

このように、エンコーダモジュール２３０３のポート数が変更されるため、図３１に示したエンコーダモジュール２３０３をＩＣＡモデルのエンコーダモジュールに変換し（ステップＳ３００３）、エンコーダモジュール２３０３自体の抽象度を変換する。図３３は、ＩＣＡモデルのエンコーダモジュールの内部構造の一例を示す説明図である。

図３３において、ＩＣＡモデルのエンコーダモジュール３３００は、図３１に示したエンコーダモジュール２３０３およびポート２３３１〜２３３３を備えている。そして、ポート２３３１、２３３２と、ポート３２１２〜３２１４との間の通信を可能とするため、各種ラッパやポートが挿入されている。同様に、ポート２３３３と、ポート３２１５、３２１６との間の通信も可能とするため、各種ラッパやポートが挿入されている。

このあと、ＩＣＡモデルのエンコーダモジュール３３００の実装コードを生成する（ステップＳ３００４）。図３４は、ＩＣＡモデルのエンコーダモジュール３３００の実装コードの一例を示す説明図である。そして、図５のステップＳ５１２では、ＩＣＡモデルの実装コード３４００のシミュレーションを実行することとなる。

このあと、図５のステップＳ５１３において、ＩＣＡモデルの実装コード３４００のシミュレーション結果と、概念モデルの実装コードのシミュレーション結果との一致判定をおこない、一致する場合（ステップＳ５１３：Ｙｅｓ）、ＩＣＡモデルの実装コード３４００のシミュレーション結果が、図１３に示した要求項目リスト１３００のすべての要求項目１３０１〜１３０８を満足することとなり、インターフェースラッパの挿入が正当であることとなる。

一方、一致しない場合（ステップＳ５１３：Ｎｏ）、ＩＣＡモデルの実装コード３４００のシミュレーション結果が、図１３に示した要求項目リスト１３００のすべての要求項目１３０１〜１３０８を満足しておらず、インターフェースラッパの挿入が正当でないこととなる。

そして、図５に示したステップＳ５１４において、ＩＣＡモデルの実装コード３４００の修正処理をおこなうこととなる。これにより、インターフェースの正確さの検証をおこなうことができる。

（シリアル送受信システムを含むシステムＬＳＩのソフトウェアモデルの実装コード生成処理手順）
つぎに、シリアル送受信システムを含むシステムＬＳＩのソフトウェアモデルの実装コード生成処理手順について説明する。図３５は、シリアル送受信システムを含むシステムＬＳＩのソフトウェアモデルの実装コード生成処理手順を示すフローチャートである。この図３５に示す処理手順は、図５のステップＳ５１６に示した処理ステップの詳細な処理手順を示している。

ソフトウェアモデルは、上述したように、シリアル送受信システムを含むシステムＬＳＩを構成するソフトウェアのタスク分割をおこない、仮想ＯＳ上に実行するモデルである。図３５において、まず、アーキテクチャモデルに機能モデルの一部をソフトウェアによりマッピングする（ステップＳ３５０１）。

図３６は、アーキテクチャモデルに機能モデルの一部をソフトウェアによりマッピングをおこなった例を示す説明図である。具体的には、図２６に示したように、デコーダ２６０２はハードウェア２６１５にマッピングし、エンコーダ２６０４はハードウェア２６１７にマッピングする。一方、ＣＰＵ２６０１およびコントローラ２６０３は、プロセッサ２６１１にマッピングする。

つぎに、このマッピングにより、ソフトウェアモデルにおける設計クラス図を生成する（ステップＳ３５０２）。図３７は、ソフトウェアモデルにおける設計クラス図を示す説明図である。図３７において、ソフトウェアモデルにおける設計クラス図３７００は、図２２に示した分割設計クラス図２２１０〜２２４０を元にして生成される。

ソフトウェアモデルにおける設計クラス図３７００は、トップモジュールに関する分割設計クラス図３７０１と、デコーダモジュールに関する分割設計クラス図３７０２と、エンコーダモジュールに関する分割設計クラス図３７０３のほかに、仮想ＯＳモデルに関する分割設計クラス図３７０４を含んでいる。そして、設計クラス図３７０１〜３７０４ごとに、ソフトウェアモデルの実装コードを生成する（ステップＳ３５０３）。

このあと、図５のステップＳ５１７において、ソフトウェアモデルの実装コードのシミュレーションを実行することとなる。そして、図５のステップＳ５１８において、ソフトウェアモデルの実装コードのシミュレーション結果と、概念モデルの実装コードのシミュレーション結果との一致判定をおこなう。そして、一致する場合（ステップＳ５１８：Ｙｅｓ）、ソフトウェアモデルの実装コードのシミュレーション結果が、図１３に示した要求項目リスト１３００のすべての要求項目１３０１〜１３０８を満足することとなり、ソフトウェアのタスク分割が正当であることとなる。

一方、一致しない場合（ステップＳ５１８：Ｎｏ）、ソフトウェアモデルの実装コードのシミュレーション結果が、図１３に示した要求項目リスト１３００のすべての要求項目１３０１〜１３０８を満足しておらず、ソフトウェアのタスク分割が正当でないこととなる。

そして、図５に示したステップＳ５１９において、ソフトウェアモデルの実装コードの修正処理をおこなうこととなる。これにより、ソフトウェアのタスク分割の正確さの検証をおこなうことができる。

この発明の実施の形態にかかる検証支援装置および検証支援方法によれば、仕様リスクの早期回避を図ることができる。具体的には、顧客要求をＵＭＬで分析した上で、実行可能なモデルを用いて顧客の機能要求に満足するかどうかを検証することができ、仕様の誤解やミスを早期に発見することができ、誤った仕様に基づくシステムＬＳＩの設計を防止することができる。

また、この発明の実施の形態にかかる検証支援装置および検証支援方法によれば、シミュレーションスピードネックの解決を図ることができる。具体的には、従来の検証手法ではＲＴＬのシミュレータを用いてシミュレーションおこなうため、シミュレーション速度が非常に遅いという問題があったが、この実施の形態では、より抽象度の高いモデルを用いてシミュレーションを実行するため、ＲＴＬのシミュレータに比べて数百倍の速度でシミュレーションを実行することができる。したがって、このシミュレーション速度の向上により、検証作業を含めた設計期間の短縮化を図ることができる。

さらに、この発明の実施の形態にかかる検証支援装置および検証支援方法によれば、コストの削減を図ることができる。具体的には、従来の検証手法では大規模なＬＳＩの場合に高価なエミュレータを導入する必要があったが、この発明の実施の形態では、抽象度の高いモデルの検証によりエミュレータの利用頻度を大幅に減少することができ、コストの削減を図ることができる。また、エミュレータの利用は基本的に時間単位でお金に換算されるケースが多いため、検証時間の短縮化によって費用の低減を図ることができる。

また、この発明の実施の形態にかかる検証支援装置および検証支援方法によれば、早期仕様のミスをなくすことによって検証工程の短縮化を図ることができる。

また、従来手法に対するより効果的な改善点として、従来手法ではＲＴＬが完成されていないと検証工程をおこなうことができなかったが、この発明の実施の形態では、設計の初期の段階から検証を開始することができる。また、設計の詳細度に応じて各モデルに対してその正当性を検証することができる。これにより、従来における設計終了⇒検証スタートという手法に対して、大幅の設計工程の短縮化を図ることができる。

さらに、この発明の実施の形態にかかる検証支援装置および検証支援方法によれば、定量的なアーキテクチャ評価をおこなうことができる。具体的には、従来手法ではＲＴＬのＨＤＬを完成しない限り、性能評価できないという問題点があったが、ＲＴＬのＨＤＬを完成してから性能に満足しないという理由で設計変更をおこなうと、非常に高いコストがかかることとなる。

これに対し、この発明の実施の形態では、早期の段階でＲＴＬによる抽象度の高い動作モデルに対してラフな性能（動作）を見積ることができ、性能（動作）に満足しないというリスクの低減を図ることができる。

また、上述した具体例では、シリアル送受信システムを含むシステムＬＳＩを例に挙げて説明したが、このシステムＬＳＩには限定されることはなく、各種システムＬＳＩに適用することができる。

なお、この実施の形態で説明した検証支援方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション、ＣＡＤ等のコンピュータで実行することにより実現することができる。このプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。またこのプログラムは、インターネット等のネットワークを介して配布することが可能な伝送媒体であってもよい。

以上のように本発明は、たとえば、ＬＳＩの設計データの検証をおこなうシステムやツールを提供することに適している。

本発明は、ＬＳＩの検証を支援する検証支援装置、検証支援方法、検証支援プログラムおよび記録媒体に関する。

ＬＳＩ設計では、ＬＳＩが正常に動作するか否かを検証する検証作業が必要不可欠であり、特に、大規模化、高機能化、高速化および低消費電力化が要求されているＬＳＩについては、高品質を維持するためにもこの検証作業は重要である一方、従来から設計期間の短縮による作業効率化が要求されている。

特に、近年は、ソフトウェアとハードウェアが混在しており、従来型のＡＳＩＣによる単機能のハードウェアだけではなく、ソフトウェアも含めたシステム・オン・チップ（ＳｏＣ）が主流となっている。また、ＭＰＥＧやＪＰＥＧなど、本来アプリケーションソフトウェアで実現される機能がハードウェアで実現するようになっているため、ＬＳＩの機能が複雑化している。

ここで、従来のＬＳＩの開発処理について説明する。図３８は、従来のＬＳＩの開発処理手順を示すフローチャートである。図３８において、ステップＳ３８０１〜ステップＳ３８０５が、ＬＳＩの設計をおこなう設計フローであり、ステップＳ３８０６〜ステップＳ３８０９が、設計されたＬＳＩの検証をおこなう検証フローである。

まず、設計フローでは、ステップＳ３８０１において、概念設計をおこなう。概念設計では、顧客からの設計要求に基づいて設計者が要求仕様書３８１０を自然言語によって作成する。または、顧客から自然言語で記述された要求仕様書３８１０を受け取る。

つぎに、ステップＳ３８０２において、機能設計をおこなう。機能設計では、要求仕様書３８１０に記述された内容から、設計対象となるＬＳＩを機能ブロックごとに分けて、各機能ブロックの内容を記述した機能仕様書３８２０を作成する。

つぎに、ステップＳ３８０３において、構造設計をおこなう。構造設計では、機能仕様書３８２０からハードウェア設計をおこなって構造仕様書３８３０を作成する。具体的には、どのようなアーキテクチャを導入すれば機能仕様書３８２０に記述された機能を実現できるか、という設計をおこなうことである。

たとえば、各機能ブロックのうち、ある機能ブロックのアーキテクチャについてはソフトウェアによって実現し、ある機能ブロックのアーキテクチャについてはＩＰ（Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ）を購入して実現し、ある機能ブロックのアーキテクチャについては設計者が作成し、ある機能ブロックのアーキテクチャについては、アンダーバスによって実現するということである。

つぎに、ステップＳ３８０４において、ユニット設計をおこなう。ユニット設計では、構造仕様書３８３０に記述された各ハードウェアモジュールを複数のモジュールに分割して詳細に設計することによってユニット仕様書３８４０を作成する。

つぎに、ステップＳ３８０５において、実装をおこなう。実装では、インターフェースのタイミングチャートを用い、また、内部ロジックを考慮することにより、最終的な設計対象となるＲＴＬ（Ｒｅｇｉｓｔｅｒ Ｔｒａｎｓｆｅｒ Ｌｅｖｅｌ）３８５０のＨＤＬ（Ｈａｒｄｗａｒｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）を用いて実装をおこなう。

つぎに、ステップＳ３８０６において、ユニット検証をおこなう。ユニット検証では、ユニット検証項目３８６０にしたがって、ユニット設計によって設計されたユニットごとのユニット仕様書３８４０の検証、すなわち、デバッグをおこなう。

つぎに、ステップＳ３８０７において、結合検証をおこなう。結合検証では、結合検証項目３８７０にしたがって、ユニット検証によって検証された各ユニットのインターフェースを結合して、正常に動作するかを検証する。

つぎに、ステップＳ３８０８において、機能検証をおこなう。機能検証では、機能検証項目３８８０にしたがって、設計対象となるシステムの機能要求を満たすかどうかを検証する。

最後に、ステップＳ３８０９において、実機検証をおこなう。実機検証では、ＲＴＬ３８５０を用いて実際にチップ上にＬＳＩを実装して、実際に動作するかどうかを検証する。顧客からの要求仕様書３８１０が、要求検証項目３８９０を満足しているかどうかを判断する。

しかしながら、上述した設計処理では、実装（ステップＳ３８０５）しなければ、ＬＳＩの検証（ステップＳ３８０６〜Ｓ３８０９）をおこなうことができなかった。

これにより、設計フローの上流のいずれかのステップにおいて仕様書の誤り、記述の曖昧さ、設計者の誤解釈のためにミスが生じると、そのステップ以降のステップにおいてミスが累積されてしまうという問題があった。

また、構造設計においては、机上でアーキテクチャを決定しており、その妥当性を確かめる手法が存在していなかった。したがって、開発リスクの増大によって開発プロジェクトの破綻も生じ、開発時間および開発労力が無駄になるという問題があった。

また、ＲＴＬ３８５０のＨＤＬに対してシミュレーションをおこなうために特別なシミュレータ(ＶＣＳ、ＮＣ−ＳｉｍなどのＥＤＡベンダーのツール)が必要であるが、シミュレーションスピードが遅いために検証効率が低下し、設計期間の長期化を招くという問題があった。特に、設計対象が大規模な場合、シミュレーションスピードがネックとなって、所定の期間内に検証作業を収束させることができない場合があった。

一方、シミュレータより何千倍のスピードで動くエミュレータを導入してシミュレーションの速度の向上を図ることも考えられるが、エミュレータが非常に高価であり、検証費用が増大するとともに、環境の構築が困難な上に問題発生時にデバッグが難しいために結果的に検証期間が増加して、設計期間の長期化を招くという問題があった。

本発明は、上記問題点に鑑みてなされたものであって、ＬＳＩの設計精度の向上および検証期間の短縮化を、容易かつ効率的に実現することができる検証支援装置、検証支援方法、検証支援プログラムおよび該プログラムを記録した記録媒体を提供することを目的とする。

上述した課題を解決し、目的を達成するため、本発明の検証支援装置、検証支援方法、および検証支援プログラムは、ＬＳＩの設計対象に関する要求仕様の分析結果を示す分析情報を入力し、入力された分析情報に基づいて、前記設計対象の基本機能がモデル化され、かつ、前記設計対象の物理的なアーキテクチャおよび時間の概念が抽象化された概念モデルを生成し、入力された分析情報に基づいて、前記設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性を抽出することによってモデル化された機能モデルを生成し、生成された機能モデルについて、前記設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性が正当であるかどうかを、生成された概念モデルに基づいて検証することを特徴とする。

また、上記発明は、前記機能モデルが正当であることが検証された場合、複数種類の物理的なアーキテクチャに関する情報から任意のアーキテクチャに関する情報を抽出し、抽出されたアーキテクチャに関する情報を、正当であることが検証された機能モデルにマッピングすることにより、前記設計対象の動作をモデル化した動作モデルを生成し、生成された動作モデルによりモデル化された設計対象を構成するモジュールの動作タイミングが、正当であるかどうかを検証することを特徴とする。

さらに、上記発明は、前記動作モデルが正当であることが検証された場合、前記機能モデルによってモデル化された設計対象を構成するモジュール間の抽象度が異なる箇所に、当該モジュール間に所定のクロックサイクル精度のインターフェースを挿入することによりＩＣＡモデルを生成し、生成されたＩＣＡモデルに挿入されたインターフェースのクロックサイクル精度が正当であるかどうかを、生成された概念モデルに基づいて検証することを特徴とする。

また、前記動作モデルが正当であることが検証された場合、前記機能モデルによってモデル化された設計対象に基づいて、ソフトウェアによって実行可能なタスクを含むようにモデル化されたソフトウェアモデルを生成し、生成されたソフトウェアモデルに含まれているタスクが正当であるかどうかを、生成された概念モデルに基づいて検証することを特徴とする。

この発明の検証支援装置、検証支援方法、および検証支援プログラムによれば、段階的に検証を導入することによって、これまで、ＲＴＬを生成しないと発見できなかった問題を、設計の早期段階に摘出してそのリスクを回避することができる。したがって、ＬＳＩの設計精度の向上および検証期間の短縮化を、容易かつ効率的に実現することができるという効果を奏する。

（実施の形態）
以下に、本発明の実施の形態にかかる検証支援装置、検証支援方法、検証支援プログラムおよび該プログラムを記録した記録媒体について図面を参照しつつ詳細に説明する。

（検証支援の概念）
まず、この発明の実施の形態にかかる検証支援の概念について説明する。図１は、この発明の実施の形態にかかる検証支援の概念図である。

図１において、設計者は、設計対象を含むシステムＬＳＩの顧客からの要求仕様１００について、ＵＭＬ（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ）を用いてオブジェクト指向分析をおこない、その分析結果を概念モデル１０１としてモデリングする。概念モデル１０１とは、設計対象の概念的な分析結果をあらわすモデルである。概念モデル１０１は、完全に実装依存しないモデルであり、具体的には、物理的なアーキテクチャや時間の概念が抽象化され、設計対象の基本機能を中心にモデリングされたものである。

概念モデル１０１は、具体的には、システムＬＳＩの要求仕様の分析結果を、ＵＭＬやＣ＋＋でモデリングした結果物であり、ＵＭＬモデル、Ｃ＋＋モデル、および検証シナリオのすべてを含めた総称である。この概念モデル１０１では、要求仕様１００の誤解やミス、またはアルゴリズムの検証をおこなうことができる。

また、機能モデル１０２は、概念モデル１０１から、設計対象であるシステムＬＳＩを構成するモジュールの分割、分割されたモジュールの並行または並列性を抽出することによって構築されたモデルである。機能モデル１０２は、時間の概念が存在しない。この機能モデルでは、モジュール分割の正当性や、並列、並行性の正確さを検証することができる。

また、アーキテクチャモデル１０３は、バスやＩＰ（Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ）などの既存設計の物理的なハードウェア部品をあらわすモデルである。アーキテクチャモデル１０３は、具体的には、処理リソースと、通信リソースとに大別される。処理リソースは、機能モデル１０２のモジュールをマッピングするためのモデルである。たとえば、ハードウェア処理モジュール、プロセッサ、ＲＴＯＳ、ＤＳＰなどが挙げられる。

一方、通信リソースは、機能モデルのモジュール間の通信を実現するためのチャンネルをモデリングしたモデルである。たとえば、バス、メモリ、ハードウェアモジュール間の信号線などが挙げられる。このアーキテクチャモデル１０３では、既存設計の物理的なハードウェア部品を用いているため、検証をおこなう必要はない。

また、動作モデル１０４は、概念的に、機能モデル１０２をアーキテクチャモデル１０３にマッピングした結果物である。具体的には、機能モデル１０２のプロセスをアーキテクチャモデル１０３の処理リソースにマッピングし、機能の通信チャンネルは、通信リソースを用いて組み立てる。この動作モデル１０４では、顧客が要求した動作（性能）を満足するかどうかの検証をおこなうことができる。

つぎに、動作モデル１０４についてＨＷ／ＳＷ分割をおこない、ハードウェア実装をあらわすＩＣＡ（Ｉｎｔｅｒｆａｃｅ Ｃｙｃｌｅ Ａｃｃｕｒａｔｅ）モデル１０５とソフトウェア実装をあらわすソフトウェアモデル１０６とを生成する。

ＩＣＡモデル１０５は、モジュール外のインターフェースについてはサイクル精度によって、モジュール内部は動作レベルによって構築したモデルである。このＩＣＡモデル１０５を高位合成することによってＲＴＬ記述１０７を生成する。このＩＣＡモデル１０５では、インターフェースの正確さの検証をおこなうことができる。

また、ソフトウェアモデル１０６は、設計対象を含むシステムＬＳＩを構成するソフトウェアのタスク分割をおこない、仮想ＯＳ上に実行するモデルである。このソフトウェアモデル１０６についてコード生成処理をおこなうことによって、実装コード１０８を生成する。このソフトウェアモデル１０６では、ソフトウェアの機能を検証することができる。

（各モデルの抽象度）
つぎに、図１に示した各モデルの抽象度について説明する。図２は、図１に示した各モデル１０１〜１０６の抽象度をあらわすグラフである。図２のグラフは、原点を中心とした３軸によって構成されている。各軸は、それぞれ「機能」の抽象度、「構造」の抽象度、「時間」の抽象度をあらわしており、原点から離れるにしたがって抽象度が高くなる。

（検証支援装置のハードウェア構成）
つぎに、この発明の実施の形態にかかる検証支援装置のハードウェア構成について説明する。図３は、この発明の実施の形態にかかる検証支援装置のハードウェア構成を示すブロック図である。

図３において、検証支援装置は、ＣＰＵ３０１と、ＲＯＭ３０２と、ＲＡＭ３０３と、ＨＤＤ（ハードディスクドライブ）３０４と、ＨＤ（ハードディスク）３０５と、ＦＤＤ（フレキシブルディスクドライブ）３０６と、着脱可能な記録媒体の一例としてのＦＤ（フレキシブルディスク）３０７と、ディスプレイ３０８と、Ｉ／Ｆ（インターフェース）３０９と、キーボード３１０と、マウス３１１と、スキャナ３１２と、プリンタ３１３と、を備えている。また、各構成部はバス３００によってそれぞれ接続されている。

ここで、ＣＰＵ３０１は、検証支援装置の全体の制御を司る。ＲＯＭ３０２は、ブートプログラムなどのプログラムを記憶している。ＲＡＭ３０３は、ＣＰＵ３０１のワークエリアとして使用される。ＨＤＤ３０４は、ＣＰＵ３０１の制御にしたがってＨＤ３０５に対するデータのリード／ライトを制御する。ＨＤ３０５は、ＨＤＤ３０４の制御で書き込まれたデータを記憶する。

ＦＤＤ３０６は、ＣＰＵ３０１の制御にしたがってＦＤ３０７に対するデータのリード／ライトを制御する。ＦＤ３０７は、ＦＤＤ３０６の制御で書き込まれたデータを記憶したり、ＦＤ３０７に記憶されたデータを検証支援装置に読み取らせたりする。

着脱可能な記録媒体として、ＦＤ３０７のほか、ＣＤ−ＲＯＭ（ＣＤ−Ｒ、ＣＤ−ＲＷ）、ＭＯ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、メモリーカードなどであってもよい。ディスプレイ３０８は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。このディスプレイ３０８は、たとえば、ＣＲＴ、ＴＦＴ液晶ディスプレイ、プラズマディスプレイなどを採用することができる。

Ｉ／Ｆ３０９は、通信回線を通じてインターネットなどのネットワークに接続され、このネットワークを介して他の装置に接続される。そして、Ｉ／Ｆ３０９は、ネットワークと内部のインターフェースを司り、外部装置からのデータの入出力を制御する。Ｉ／Ｆ３０９には、たとえばモデムやＬＡＮアダプタなどを採用することができる。

キーボード３１０は、文字、数字、各種指示などの入力のためのキーを備え、データの入力をおこなう。また、タッチパネル式の入力パッドやテンキーなどであってもよい。マウス３１１は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などをおこなう。ポインティングデバイスとして同様に機能を備えるものであれば、トラックボールやジョイスティックなどであってもよい。

スキャナ３１２は、画像を光学的に読み取り、検証支援装置内に画像データを取り込む。なお、スキャナ３１２は、ＯＣＲ機能を持たせてもよい。また、プリンタ３１３は、画像データや文書データを印刷する。プリンタ３１３には、たとえば、レーザプリンタやインクジェットプリンタを採用することができる。

（検証支援装置の機能的構成）
つぎに、この発明の実施の形態にかかる検証支援装置の機能的構成について説明する。図４は、この発明の実施の形態にかかる検証支援装置の機能的構成を示すブロック図である。

図４において、検証支援装置４００は、分析情報入力部４０１と、概念モデル生成部４０２と、機能モデル生成部４０３と、機能モデル検証部４０４と、アーキテクチャ情報記憶部４０５と、アーキテクチャ抽出部４０６と、動作モデル生成部４０７と、動作モデル検証部４０８と、ＩＣＡモデル生成部４０９と、ＩＣＡモデル検証部４１０と、ソフトウェアモデル生成部４１１と、ソフトウェアモデル検証部４１２と、から構成されている。

分析情報入力部４０１は、設計対象を含むシステムＬＳＩの顧客からの要求仕様の分析結果を示す情報（分析情報）の入力を受け付ける。ここで、分析情報とは、たとえば、ＵＭＬによって記述された設計対象のユースケース図、シーケンス図、クラス図や、設計対象に要求される基本機能項目など、コンピュータによって読取り可能な情報が挙げられる。

また、概念モデル生成部４０２は、分析情報入力部４０１によって入力された分析情報に基づいて、設計対象の基本機能がモデル化され、かつ、設計対象の物理的なアーキテクチャおよび時間の概念が抽象化された概念モデル、すなわち、図１に示した概念モデル１０１を生成する。

具体的には、概念モデル生成部４０２は、ユースケース図などの分析情報を解析して、設計対象の実装コードや、設計対象について検証すべき項目（検証項目）、回路シミュレーションによる検証処理手順を示す検証シナリオを生成する。この生成された実装コード、検証項目および検証シナリオが、図１に示した概念モデル１０１となる。

また、機能モデル生成部４０３は、分析情報入力部４０１によって入力された分析情報に基づいて、設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性を抽出することによってモデル化された機能モデルを生成する。たとえば、分析情報であるクラス図に基づいて、設計対象の機能をあらわす機能モデルを生成する。

具体的には、概念モデル生成部４０２に入力されたクラス図を機能ごとに複数に分割し、分割されたクラス図（分割クラス図）ごとに、実装コードを生成する。この生成された分割クラス図ごとの実装コードが、図１に示した機能モデル１０２となる。

機能モデル検証部４０４は、機能モデル生成部４０３によって生成された機能モデルについて、設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性が正当であるかどうかを、概念モデル生成部４０２によって生成された概念モデルに基づいて検証する。

具体的には、分割クラス図ごとの実装コードのシミュレーション結果が、概念モデルの実装コードを概念モデルの検証シナリオでシミュレーションしたシミュレーション結果と一致するかどうかを判定することによって、機能モデルの正当性を検証する。ここで、シミュレーション結果とは、ある入力データに対してどのような出力データが得られるか、ということである。

より具体的には、分割クラス図ごとの実装コードのシミュレーション結果が一致する場合は、機能モデルが正当となる。一方、不一致の場合は、機能モデルの分割、並行、並列性が正しくないため、機能モデル生成部４０３は、機能モデルの実装コードを修正する。

また、アーキテクチャ情報記憶部４０５は、バスやＩＰ（Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ）などの既存設計の物理的なハードウェア部品に関する情報を記憶する。アーキテクチャ情報記憶部４０５は、具体的には、たとえば、図３に示したＲＯＭ３０２、ＲＡＭ３０３、ＨＤ３０５、ＦＤ３０７などによってその機能を実現する。

アーキテクチャ情報抽出部４０６は、アーキテクチャ情報記憶部４０５に記憶されているアーキテクチャ情報を抽出する。処理リソースに関しては、たとえば、ハードウェア処理モジュール、プロセッサ、ＲＴＯＳ、ＤＳＰなどを抽出する。一方、通信リソースに関しては、バス、メモリ、ハードウェアモジュール間の信号線などを抽出する。このアーキテクチャ情報抽出部４０６によって抽出されたアーキテクチャ情報が、図１に示したアーキテクチャモデル１０３に相当する。

動作モデル生成部４０７は、アーキテクチャ情報抽出部４０６によって抽出されたアーキテクチャに関する情報を、機能モデル検証部４０４によって正当であることが検証された機能モデルにマッピングすることにより、設計対象の動作をモデル化した動作モデルを生成する。

具体的には、機能モデル１０２をアーキテクチャモデル１０３にマッピングすることによって、設計対象の動作モデル１０４を生成する。具体的には、機能モデル１０２のプロセスをアーキテクチャモデル１０３の処理リソースにマッピングし、機能の通信チャンネルは、通信リソースを用いて組み立てる。この組み立てにより、マッピングによって得られたモジュールの処理時間を考慮した実装コードを生成する。この生成された実装コードが、図１に示した動作モデル１０４に相当する。

動作モデル検証部４０８は、動作モデル生成部４０７によって生成された動作モデルによりモデル化された設計対象を構成するモジュールの動作タイミングが、正当であるかどうかを検証する。

具体的には、動作モデル生成部４０７によって生成された実装コードのシミュレーション結果が、概念モデルの実装コードを概念モデルの検証シナリオでシミュレーションしたシミュレーション結果と一致するかどうかを判定することによって、動作モデルの正当性を検証する。ここで、シミュレーション結果とは、ある入力データに対してどのような出力データが得られるか、ということである。

そして、一致する場合は、動作モデルが正当となり、顧客が要求した動作（性能）を満足していることとなる。一方、不一致の場合は、動作モデルが、顧客が要求した動作（性能）を満足していないこととなる。この場合、動作モデル生成部４０７は、動作モデルの実装コードを修正する。

ＩＣＡモデル生成部４０９は、動作モデル検証部４０８によって正当であることが検証された場合、機能モデルによってモデル化された設計対象を構成するモジュール間の抽象度が異なる箇所に、当該モジュール間に所定のクロックサイクル精度のインターフェースを挿入することによりＩＣＡモデルを生成する。

具体的には、動作モデル１０４についてＨＷ／ＳＷ分割をおこない、ハードウェア実装をあらわすＩＣＡモデル１０５を生成する。たとえば、モジュール間の抽象度が異なる場合に、当該モジュール間の抽象度が同等となるように、クラス図に示された、モジュール間の通信路をインターフェースラッパに置換する。

そして、インターフェースラッパに置換されたクラス図の実装コードを生成する。この生成された実装コードが、図１に示したＩＣＡモデル１０５となる。そして、このＩＣＡモデル１０５の実装コードを高位合成することにより、ＲＴＬ記述１０７を生成することができる。

ＩＣＡモデル検証部４１０は、ＩＣＡモデル生成部４０９によって生成されたＩＣＡモデル１０５に挿入されたインターフェースのクロックサイクル精度が正当であるかどうかを、概念モデル生成部４０２によって生成された概念モデル１０１に基づいて検証する。

具体的には、ＩＣＡモデル生成部４０９によって生成された実装コードのシミュレーション結果が、概念モデルの実装コードを概念モデルの検証シナリオでシミュレーションしたシミュレーション結果と一致するかどうかを判定することによって、機能モデルの正当性を検証する。ここで、シミュレーション結果とは、ある入力データに対してどのような出力データが得られるか、ということである。

そして、一致する場合は、ＩＣＡモデルが正当となる。具体的には、置換されたインターフェースラッパによってあらわされるインターフェースが正確であることとなる。一方、不一致の場合は、置換されたインターフェースラッパが不正確となる。この場合、ＩＣＡモデル生成部４０９は、ＩＣＡモデルの実装コードを修正する。

ソフトウェアモデル生成部４１１は、動作モデル検証部４０８によって正当であることが検証された場合、機能モデルによってモデル化された設計対象に基づいて、ソフトウェアによって実行可能なタスクを含むようにモデル化されたソフトウェアモデルを生成する。

具体的には、動作モデル１０４についてＨＷ／ＳＷ分割をおこない、ソフトウェア実装をあらわすソフトウェアモデル１０６（図１を参照。）を生成する。たとえば、設計対象を含むシステムＬＳＩを構成するソフトウェアのタスク分割をおこない、仮想ＯＳ上に実行可能な実装コードを生成する。

ソフトウェアモデル検証部４１２は、ソフトウェアモデル生成部４１１によって生成されたソフトウェアモデルに含まれているタスクが、正当であるかどうかを、概念モデル生成部４０２によって生成された概念モデルに基づいて検証する。

具体的には、ソフトウェアモデル生成部４１１によって生成された実装コードのシミュレーション結果が、概念モデルの実装コードを概念モデルの検証シナリオでシミュレーションしたシミュレーション結果と一致するかどうかを判定することによって、ソフトウェアモデル１０６の正当性を検証する。ここで、シミュレーション結果とは、ある入力データに対してどのような出力データが得られるか、ということである。

そして、一致する場合は、ソフトウェアモデル１０６の実装コードによってあらわされる機能が正当となる。そして、このソフトウェアモデル１０６の実装コードを取り込んだ、設計対象全体の実装コード１０８（図１を参照。）を生成する。一方、不一致の場合は、ソフトウェアモデル１０６の実装コードによってあらわされる機能が不正確となる。この場合、ソフトウェアモデル生成部４１１は、ソフトウェアモデルの実装コードを修正する。

なお、上述した分析情報入力部４０１、概念モデル生成部４０２、機能モデル生成部４０３、機能モデル検証部４０４、アーキテクチャ情報抽出部４０６、動作モデル生成部４０７、動作モデル検証部４０８、ＩＣＡモデル生成部４０９、ＩＣＡモデル検証部４１０、ソフトウェアモデル生成部４１１およびソフトウェアモデル検証部４１２は、具体的には、たとえば、図３に示したＲＯＭ３０２、ＲＡＭ３０３、ＨＤ３０５、ＦＤ３０７などに記録されたプログラムをＣＰＵ３０１が実行することによって、またはＩ／Ｆ３０９によって、その機能を実現する。

（検証支援装置の検証支援処理手順）
つぎに、この発明の実施の形態にかかる検証支援装置の検証支援処理手順について説明する。図５は、この発明の実施の形態にかかる検証支援装置の検証支援処理手順を示すフローチャートである。

図５において、まず、設計者は、設計対象を含むシステムＬＳＩの顧客からの要求仕様１００を分析して、分析結果をあらわす分析情報を入力する（ステップＳ５０１）。

つぎに、入力された分析情報に基づいて、設計対象の実装コードや、設計対象について検証すべき項目（検証項目）、回路シミュレーションによる検証処理手順を示す検証シナリオなどの概念モデル１０１を生成する（ステップＳ５０２）。生成された概念モデル１０１の正当性については、設計者が検証する。

つぎに、設計対象の機能デモル１０２を生成する（ステップＳ５０３）。具体的には、概念モデル生成部４０２に入力されたクラス図を機能ごとに複数に分割し、分割されたクラス図（分割クラス図）ごとに、機能モデル１０２の実装コードを生成する。

そして、概念モデル１０１の実装コードと機能モデル１０２の実装コードのシミュレーションをおこなう（ステップＳ５０４）。つぎに、概念モデル１０１の実装コードのシミュレーション結果と、機能モデル１０２の実装コードのシミュレーション結果とが、一致するかどうかの判定、すなわち、機能モデル検証をおこなう（ステップＳ５０５）。

不一致の場合（ステップＳ５０５：Ｎｏ）、機能モデル１０２を修正する（ステップＳ５０６）。具体的には、たとえば、概念モデル１０１のクラス図を再度、分割しなおして、分割クラス図を生成し、その分割クラス図ごとに実装コードを生成する。そして、ステップＳ５０４に移行する。

一方、一致する場合（ステップＳ５０５：Ｙｅｓ）、機能モデル１０２が正当であると判断される。そして、正当性が検証された検証済みの機能モデル１０２に、アーキテクチャモデル１０３をマッピングして、動作モデル１０４を生成する（ステップＳ５０７）。そして、動作モデル１０４の実装コードのシミュレーションをおこなう（ステップＳ５０８）。

つぎに、概念モデル１０１の実装コードのシミュレーション結果と、動作モデル１０４の実装コードのシミュレーション結果とが、一致するかどうかの判定、すなわち、動作モデル検証をおこなう（ステップＳ５０９）。

不一致の場合（ステップＳ５０９：Ｎｏ）、動作モデル１０４を修正する（ステップＳ５１０）。具体的には、たとえば、アーキテクチャ情報記憶部４０５から再度アーキテクチャ情報を抽出して、正当性が検証された検証済の機能モデル１０２に、あらたなアーキテクチャモデル１０３をマッピングして、動作モデル１０４を生成する。そして、ステップＳ５０８に移行する。

一方、一致する場合（ステップＳ５０９：Ｙｅｓ）、動作モデル１０４が正当であると判断される。そして、正当性が検証された検証済の動作モデル１０４に対しＨＷ／ＳＷ分割をおこない、ＩＣＡモデル１０５とソフトウェアモデル１０６を生成する（ステップＳ５１１、ステップＳ５１６）。

そして、生成されたＩＣＡモデル１０５の実装コードのシミュレーションをおこなう（ステップＳ５１２）。つぎに、概念モデル１０１の実装コードのシミュレーション結果と、ＩＣＡモデル１０５の実装コードのシミュレーション結果とが、一致するかどうかの判定、すなわち、ＩＣＡモデル検証をおこなう（ステップＳ５１３）。

不一致の場合（ステップＳ５１３：Ｎｏ）、ＩＣＡモデル１０５を修正する（ステップＳ５１４）。具体的には、たとえば、インターフェースラッパの内容を変更することによって、ＩＣＡモデル１０５を修正する。そして、ステップＳ５１２に移行する。

一方、一致する場合（ステップＳ５１３：Ｙｅｓ）、ＩＣＡモデル１０５が正当であると判断される。そして、高位合成をおこなって（ステップＳ５１５）、ＲＴＬ記述を生成する。

また、生成されたソフトウェアモデル１０６の実装コードのシミュレーションをおこなう（ステップＳ５１７）。つぎに、概念モデル１０１の実装コードのシミュレーション結果と、ソフトウェアモデル１０６の実装コードのシミュレーション結果とが、一致するかどうかの判定、すなわち、ソフトウェアモデル検証をおこなう（ステップＳ５１８）。

不一致の場合（ステップＳ５１８：Ｎｏ）、ソフトウェアモデル１０６を修正する（ステップＳ５１９）。具体的には、たとえば、設計対象を含むシステムＬＳＩを構成するソフトウェアのタスク分割を再度おこない、仮想ＯＳ上に実行可能な実装コードを生成する。

一方、一致する場合（ステップＳ５１８：Ｙｅｓ）、ソフトウェアモデル１０６が正当であると判断される。そして、正当であることが検証された検証済のソフトウェアモデル１０６の実装コードを取り込んだ、設計対象全体の実装コード１０８を生成する（ステップＳ５２０）。

この検証処理手順によれば、モデルごとに、段階的に検証をおこなうため、直前までに検証されたモデルについては、検証のやり直しをおこなうことなく、有効なモデルとして活用することができるため、検証処理において手戻りが発生せず、検証処理の効率化を図ることができる。

なお、上述した図５のフローチャートでは、ステップＳ５１１〜５１５までの処理手順と、ステップＳ５１６〜５２０までの処理手順とを並列に実行することとしているが、ステップＳ５１１〜５１５までの処理手順のあとに、ステップＳ５１６〜５２０までの処理手順を実行することとしてもよく、また、ステップＳ５１６〜５２０までの処理手順のあとに、ステップＳ５１１〜５１５までの処理手順を実行することとしてもよい。

（検証処理の具体例）
つぎに、上述した検証処理の具体例について説明する。

（システムＬＳＩのハードウェア構成）
まず、設計対象を含むシステムＬＳＩのハードウェア構成について説明する。図６は、この発明の実施の形態にかかる設計対象を含むシステムＬＳＩのハードウェア構成を示すブロック図である。この設計対象は、たとえば、顧客から設計業務を引き受けた情報であり、ここでは、その設計対象を、シリアル送受信システムとして説明する。

図６において、システムＬＳＩ６００は、設計対象の一例として挙げられたシリアル送受信システム６０１と、受信器６０２と、送信器６０３と、ＣＰＵ６０４と、その他デバイス６０５と、これらを接続するバス６０６と、によって構成されている。

ここで、受信器６０２は、受信パケット６１１を受信し、シリアル送受信システム６０１に供給する。送信器６０３は、シリアル送受信システム６０１から供給された情報を送信パケット６１２として図示しない外部機器に送信する。シリアル送受信システム６０１は、たとえば、ＢＣＨ（６２，４８）で符号化および復号化をおこなう。

そして、受信器６０２からの受信パケット６１１を復号し、この復号したパケット６１３をＣＰＵ６０４に供給する。また、ＣＰＵ６０４からのパケット６１４を符号化する。ＣＰＵ６０４は、シリアル送受信システム６０１からのパケット６１３を用いて、その他デバイス６０５とともにシステムＬＳＩ６００の機能を実行する。

（外部装置のインターフェース仕様）
つぎに、外部装置（受信器６０２、送信器６０３、ＣＰＵ６０４、その他デバイス６０５）のインターフェース仕様について説明する。図７および図８は、外部装置のインターフェースであるバスの仕様を示す説明図である。特に、図７は、ライト時のタイミングチャートであり、図８は、リード時のタイミングチャートである。

図７および図８において、「ＰＣＬＫ」は、ビット幅１の入力クロック信号である。「ＰＡＤＤＲ」は、ビット幅３２のアドレス出力信号である。「ＰＷＲＩＴＥ」は、ビット幅１のリード／ライト制御出力信号である。「ＰＳＥＬ」は、ビット幅１のチップセレクト出力信号である。「ＰＥＮＡＢＬＥ」は、ビット幅１の出力イネーブル信号である。「ＰＲＤＡＴＡ」は、ビット幅３２のデータ入出力信号である。ＣＰＵ６０４に対するバスの仕様は、バス標準プロトコルに準拠しており、ＣＰＵ６０４について組み込みプロセッサコアを採用することとしている。

図９は、外部装置のインターフェースである送信器６０３の仕様を示す説明図である。図９において、「ｃｌｋ」は、ビット幅１の入力クロック信号である。「ＩＳＴＡＲＴ」は、ビット幅１のスタートパルス入力信号である。「ＩＤＡＴＡ」は、ビット幅１のデータ入力信号である。シリアル送受信システム６０１から送信器６０３への入力仕様は、スタートパルス入力信号のｉクロックのパルスを検出すると同時に、送信器６０３がクロックのポジティブエッジごとに１ビットずつデータを取り込むという仕様である。また、入力クロック周波数は、１００ＭＨｚとしている。

図１０は、外部装置のインターフェースである受信器６０２の仕様を示す説明図である。図１０において、「ｃｌｋ」は、ビット幅１の出力クロック信号である。「ＯＳＴＡＲＴ」は、ビット幅１のスタートパルス出力信号である。「ＯＤＡＴＡ」は、ビット幅１のデータ出力信号である。

（シリアル送受信システムに要求される基本機能）
つぎに、設計対象であるシリアル送受信システム６０１に要求される基本機能について説明する。シリアル送受信システム６０１に要求される基本機能は、（１）パケットの送信機能と、（２）パケットの受信機能と、（３）初期化機能である。

（１）パケットの送信機能は、以下のとおりである。
（ｉ）ＣＰＵ６０４が作成したパケット６１４をＢＣＨ（６２，４８）で符号化して送信器６０３に転送する転送機能。
（ii）ＣＰＵ６０４が作成したパケット６１４の不正を検出してＣＰＵ６０４にエラーを知らせる不正検出機能。
（iii）ＣＰＵ６０４から連続的に大量なパケット６１４が送信されてきた際に処理が間に合わないとき、ＣＰＵ６０４にエラーを知らせ、送信パケット６１２を破棄するパケット破棄機能。
（ｖi）送信器６０３への出力スループット：０〜１Ｍｂｐｓ
また、（２）パケットの受信機能は、以下の通りである。
（ｖii）ＢＣＨ（６２，４８）で受信器６０２から連続して符号化された受信パケット６１１を受信し、受信パケット６１１を復号してＣＰＵ６０４に通知し、復号したパケット６１３をＣＰＵ６０４に受信させる復号機能。
（ｖiii）受信器６０２から大量の受信パケット６１１を送ってきた際に処理が間に合わない場合は受信パケット６１１の廃棄を許容するパケット廃棄許容機能。
（iｘ）受信パケット６１１の中に誤り訂正ができないパケットが存在する場合、ＣＰＵ６０４にエラーを知らせ、受信パケット６１１を破棄するパケット破棄機能。
（ｘ）受信パケット６１１に対して２ビットまで訂正可能、４ビットまでエラーの検出可能とする訂正・検出機能。
（ｘi）受信器６０２からの入力スループット：０〜１Ｍｂｐｓ
さらに、（３）初期化機能は、以下の通りである。
（ｘii）ＣＰＵ６０４から初期化指示するソフトリセット機能。
（ｘiii）リセット信号からも初期化指示するハードリセット機能。

（パケットの構成）
つぎに、ＣＰＵ６０４で送受信されるパケット６１３，６１４の構成について説明する。図１１は、ＣＰＵ６０４で送受信されるパケット６１３，６１４の構成を示す説明図であり、図１２は、送信パケット６１２の構成を示す説明図である。図１１において、パケット６１３，６１４は、１６ビットのヘッダ部１１０１と、３２ビットのデータ部１１０２から構成されている。ヘッダ部１１０１はパケット識別番号（１０１０１０１０１０１０１０１０）２とされている。

また、図１２において、送信パケット６１２は、図１１に示した１６ビットのヘッダ部１１０１および３２ビットのデータ部１１０２に、ＢＣＨ（６２，４８）で符号化された１４ビットの冗長符号部１２０１が付加された構成である。また、受信パケット６１１は、図示はしないが、送信パケット６１２との構成にさらに通信路によるエラービットが付加された構成である。この図６から図１２までの情報の内容が、顧客が要求する要求仕様１００となる。

（要求定義の内容）
つぎに、図６から図１２までに示した要求仕様の内容を定義した要求定義について説明する。図１３は、要求定義であるシステムＬＳＩ６００の要求項目リストを示す説明図であり、図１４は、要求定義であるシステムＬＳＩ６００のユースケース図である。

図１３に示した要求項目リスト１３００において、このシステムＬＳＩ６００には、「受信パケットを最大２重誤り訂正できる」（項目１３０１）、「受信パケットの４重誤りまで検出できる」（項目１３０２）、「受信パケットを受信器経由で受信できる」（項目１３０３）、「受信パケットをＢＣＨ（６０，４８）で復号化できる」（項目１３０４）、「ＣＰＵから初期化できる」（項目１３０５）、「リセット信号から初期化できる」（項目１３０６）、「送信パケットを送信器経由で送信できる」（項目１３０７）、「送信パケットをＢＣＨ（６２，４８）で符号化できる」（項目１３０８）の機能が要求される。

また、図１４に示したユースケース図１４００は、図１３に示した要求項目リスト１３００によって要求されている機能を図表化したものであり、ＵＭＬにしたがって記述された図表である。図１４において、図６に示したシリアル送受信システム６０１は、ユースケース１４０１〜１４０３によってあらわされる機能「パケットを受信する」、「初期化する」および「パケットを送信する」を備えている。また、ユースケース図１４００には、シリアル送受信システム６０１に関連するアクターとして、ＣＰＵ１４１１、リセット信号１４１２、受信器１４１３および送信器１４１４が図表化されている。

図１４に示したユースケース図１４００において、ユースケース１４０１は、アクター１４１３からパケットを受信する。そして、受信したパケットをアクター１４１１に送信する。また、ユースケース１４０２は、アクター１４１１およびアクター１４１２から初期化する。さらに、ユースケース１４０３は、アクター１４１１からパケットを受信して、アクター１４１４に送信する。

（分析情報の内容）
つぎに、図１３および図１４に示した要求定義（要求項目リスト１３００、ユースケース図１４００）の分析結果を示す分析情報について説明する。図１５は、要求定義された結果物であるシステムＬＳＩ６００の分析クラス図であり、図１６は、要求定義された結果物であるシステムＬＳＩ６００のシーケンス図である。

図１５に示した分析クラス図１５００には、シリアル送受信システム６０１に必要なデータや手順などを管理する《control》クラス１５０１と、シリアル送受信システム６０１内部で当該システム特有の処理を担当する<Entity>クラス１５０２〜１５０８が記述されている。《control》クラス１５０１は、シリアス送受信システム６０１をあらわしている。《entity》クラス１５０２〜１５０８は、送信パケット６１２、受信パケット６１１、パケット６１３，６１４、冗長符号部１２０１、エラービット、ヘッダ部１１０１、データ部１１０２をあらわしている。

図１５に示した分析クラス図１５００において、《control》クラス１５０１（シリアル送受信システム６０１）は、アクター１４１４（送信器６０３）からパケットを送信する。また、アクター１４１１（ＣＰＵ６０４）との間で送受信／初期化をおこなう。さらに、《entity》クラス１５０２（送信パケット６１２）の送信、《entity》クラス１５０３（受信パケット６１１）の受信、アクター１４１２（リセット信号）からの初期化をおこなう。また、《entity》クラス１５０３（受信パケット６１１）を受信したアクター１４１３（受信器６０２）からパケットを受信する。

また、図１５に示した分析クラス図１５００において、《entity》クラス１５０２（送信パケット６１２）は、《entity》クラス１５０４（パケット６１３，６１４）および《entity》クラス１５０５（冗長符号部１２０１）を集約している。また、《entity》クラス１５０３（受信パケット６１１）は、《entity》クラス１５０５（冗長符号部１２０１）および《entity》クラス１５０６（エラービット）を集約している。さらに、《entity》クラス１５０４（パケット６１３、６１４）は、《entity》クラス１５０７（ヘッダ部１１０１）および《entity》クラス１５０８（データ部１１０２）を集約している。これにより、アクター１４１１（ＣＰＵ６０４）は、《entity》クラス１５０４（パケット６１３、６１４）の作成／受信をおこなっていることがわかる。

また、図１６に示したシーケンス図１６００は、パケットを正常に送信する場合の動作を示している。このシーケンス図１６００では、シーケンス番号順、すなわち、シーケンス番号１．０（「パケットを作成する（）」）→シーケンス番号１．１（「パケットを受信する（）」）、→シーケンス番号１．２（「パケットを符号化する（）」）、→シーケンス番号１．３（「送信パケットを作成する（）」）、シーケンス番号１．４（「送信パケットを送信する（）」）の順に送信処理がおこなわれることを示している。

つぎに、このシリアル送受信システムを含むシステムＬＳＩの設計クラス図について説明する。図１７は、シリアル送受信システムを含むシステムＬＳＩの設計クラス図である。

この設計クラス図１７００において、クラス１７０１は、シリアル送受信システムを示す名称「ＥＣＣ＿ＳＩＯ」が記述されているクラス名１７０２と、クラス１７０１が持つ静的な性質を示す属性１７０３（メンバ変数）と、クラス１７０１が持つ動的な性質を示す操作１７０４（メンバ関数）と、を含んでいる。操作１７０４は、ＣＰＵを示すクラス１７０５と符号化を示すクラス１７０６に働きかけている。この図１７に示した設計クラス図１７００を元にして、概念モデル１０１の実装コードが生成される。図１７に概念モデル１０１の実装コードの一記述例を示す。図１８は、概念モデル１０１の実装コード１８００を示す説明図である。この実装コード１８００は、Ｃ＋＋言語によってモデル化されているコードである。

（検証項目の内容）
つぎに、シリアル送受信システムを含むシステムＬＳＩの検証項目について説明する。図１９は、シリアル送受信システムを含むシステムＬＳＩの検証項目を示す説明図である。

図１９では、対象ユースケースを、図１４で示したユースケース１４０１に着目している。この検証項目１９００において、項目『シーケンス』の「基本パス」とは、パケットの正常な送信処理、すなわち、図１６に示したシーケンス番号１．０〜１．１までの処理を示している。

（検証シナリオの内容）
つぎに、シリアル送受信システムを含むシステムＬＳＩの検証シナリオについて説明する。図２０は、シリアル送受信システムを含むシステムＬＳＩの検証シナリオを示す説明図である。この検証シナリオ２０００は、図１５に示したシーケンス図１５００と図１９に示した検証項目１９００を用いて生成される。

この検証シナリオ２０００を用いたシミュレーションによって検出された仕様上のミスについて、例を挙げて説明する。ＣＰＵに常にエラーの通知を行っているという検証結果が得られた場合、パケット受信エラーが発生したときにシリアル送受信システムをエラー状態にしたが、次のパケットを正常に受信してもシステムがエラー状態のままとなる仕様上のミスが検出される。このため、修正処理として、ＣＰＵがエラー受信した後にシリアル送受信システムのエラー状態をクリアすることとする。これにより、仕様ミスを解消することができる。

（機能モデルの実装コード生成処理手順）
つぎに、シリアル送受信システムを含むシステムＬＳＩの機能モデルの検証処理手順について説明する。図２１は、シリアル送受信システムを含むシステムＬＳＩの機能モデルの実装コード生成処理手順を示すフローチャートである。図２１に示す処理手順は、図５のステップＳ５０３に示した処理ステップの詳細な処理手順を示している。

まず、ステップＳ５０２において生成された概念モデルの設計クラス図（図１７を参照。）を、並行、並列なモジュールに分割する（ステップＳ２１０１）。図２２は、図１７に示した設計クラス図を分割することによって得られた分割設計クラス図を示す説明図で
ある。

図１７に示した設計クラス図は、図２２において、トップモジュールに関する分割設計クラス図２２１０と、コントローラモジュールに関する分割設計クラス図２２２０と、エンコーダモジュールに関する分割設計クラス図２２３０と、デコーダモジュールに関する分割設計クラス図２２４０と、に分割されている。

そして、この分割設計クラス図２２１０〜２２４０によってあらわされるモジュール間を接続する通信路を決定する（ステップＳ２１０２）。図２３は、分割設計クラス図によってあらわされるモジュール間を接続する通信路を示す説明図である。

トップモジュール２３０１は、ポート２３１１〜２３１５を有している。このポート２３１１〜２３１５は、トップモジュールに関する分割設計クラス図２２１０の属性２２１１に記述されている。具体的には、ポート２３１１は「packet_i:sc_fifo_in<Packet>」を示しており、ＣＰＵからのパケット<Packet>を入力する入力ポートである。ポート２３１２は「packet_o:sc_fifo_out<Packet>」を示しており、パケット<Packet>をＣＰＵに出力する出力ポートである。ポート２３１３は「error_o:sc_fifo_out<ERR_TYPE>」を示しており、エラータイプ情報<ERR_TYPE>をＣＰＵに出力する出力ポートである。

また、ポート２３１４は「encoded_packet_o:sc_fifo_out<EncodedPacket>」を示しており、符号化されたパケット<EncodedPacket>を出力する出力ポートである。ポート２３１５は「received_packet_i:sc_fifo_in<ReceivedPacket>」を示しており、外部から受信されたパケット<ReceivedPacket>を入力する入力ポートである。

コントローラモジュール２３０２は、ポート２３２１〜２３２７を有している。このポート２３２１〜２３２７は、コントローラモジュール２３０２に関する分割設計クラス図２２２０の属性２２２１に記述されている。具体的には、ポート２３２１は「cpu_packet_i:sc_fifo_in<Packet>」を示しており、ＣＰＵからのパケット<Packet>を入力する入力ポートである。ポート２３２２は「cpu_packet_o:sc_fifo_out<Packet>」を示しており、パケット<Packet>をＣＰＵに出力する出力ポートである。ポート２３２３は「error_o:sc_fifo_out<ERR_TYPE>」を示しており、エラータイプ情報<ERR_TYPE>をＣＰＵに出力する出力ポートである。

また、ポート２３２４は「encoder_packet_o:sc_fifo_out<Packet>」を示しており、パケット<Packet>をエンコーダモジュールに出力する出力ポートである。ポート２３２５は「encoder_status_i:sc_fifo_in<bool>」を示しており、エンコーダモジュール２３０３
のステータス情報<bool>を入力する入力ポートである。ポート２３２６は「decoder_packet_i:sc_fifo_in<Packet>」を示しており、デコーダモジュールからパケット<Packet>を入力する入力ポートである。ポート２３２７は「decoder_error_i:sc_fifo_in<ERR_TYPE>」を示しており、デコーダモジュールからエラータイプ情報<ERR_TYPE>を入力する入力ポートである。

エンコーダモジュール２３０３は、ポート２３３１〜２３３３を有している。このポート２３３１〜２３３３は、エンコーダモジュール２３０３に関する分割設計クラス図２２３０の属性２２３１に記述されている。具体的には、ポート２３３１は「packet_i:sc_fifo_in_if<Packet>」を示しており、パケット<Packet>を入力する入力ポートである。ポート２３３２は「status_o:sc_fifo_out<bool>」を示しており、エンコーダモジュール２３０３のステータス情報<bool>を出力する出力ポートである。ポート２３３３は「packet_o:sc_fifo_out_if<EncodedPacket>」を示しており、エンコーダモジュール２３０３によって符号化されたパケット<EncodedPacket>を出力する出力ポートである。

デコーダモジュール２３０４は、ポート２３４１〜２３４３を有している。このポート２３４１〜２３４３は、デコーダモジュール２３０４に関する分割設計クラス図２２４０の属性２２４１に記述されている。具体的には、ポート２３４１は「packet_o:sc_fifo_out<Packet>」を示しており、パケット<Packet>を出力する出力ポートである。ポート２３４２は「error_o:sc_fifo_out<ERR_TYPE>」を示しており、エラータイプ情報<ERR_TYPE>を出力する出力ポートである。ポート２３４３は「packet_i:sc_fifo_in<ReceivedPacket>」を示しており、受信されたパケット<ReceivedPacket>を入力する入力ポートである。

このように、分割設計クラス図２２１０〜２２４０の属性を用いて、ポート２３１１〜２３１５、ポート２３２１〜２３２７、ポート２３３１〜２３３３、ポート２３４１〜２３４３どうしを接続して、通信路２３５１〜２３５９を決定する。この通信路２３５１〜２３５９は、具体的にはＦＩＦＯ方式で通信をおこなう通信路である。

また、図２１において、通信路を決定した後、機能モデルの実装コードを生成する（ステップＳ２１０３）。ここで、シリアル送受信システムを含むシステムＬＳＩの機能モデルの実装コードの生成例について説明する。図２４は、シリアル送受信システムを含むシステムＬＳＩの機能モデルの実装コードの生成例を示す説明図である。

図２４では、エンコーダモジュール２３０３に関する分割設計クラス図２２３０から生成した、エンコーダモジュール２３０３の実装コード２４００を示している。なお、図示はしないが、トップモジュールに関する分割設計クラス図２２１０、コントローラモジュール２３０２に関する分割設計クラス図２２２０、およびデコーダモジュール２３０４に関する分割設計クラス図２２４０についても、それぞれ実装コードを生成する。そして、図５のステップＳ５０４では、各分割設計クラス図２２１０〜２２４０の実装コードのシミュレーションを実行することとなる。

このあと、図５のステップＳ５０５において、このシミュレーション結果と、概念モデルの実装コードのシミュレーション結果との一致判定をおこない、一致する場合（ステップＳ５０５：Ｙｅｓ）、図２２に示したモジュール分割が正当であり、また、モジュール分割の並列、並行性が正確であることとなる。

一方、一致しない場合（ステップＳ５０５：Ｎｏ）、図２２に示したモジュール分割が正当でなく、また、モジュール分割の並列、並行性が不正確であるとして、図５のステップＳ５０６において、図２１のステップＳ２１０３で生成された実装コードの修正処理をおこなう。この機能モデル検証により、概念モデルと同一の検証結果になることを確認することができる。

（シリアル送受信システムを含むシステムＬＳＩのアーキテクチャモデル）
つぎに、シリアル送受信システムを含むシステムＬＳＩのアーキテクチャモデルについて説明する。図２５は、シリアル送受信システムを含むシステムＬＳＩのアーキテクチャモデルのクラス図の一例を示す説明図である。アーキテクチャモデルは、バスやＩＰなどの既存設計の物理的なハードウェア部品をあらわすモデルであり、ここでは、バスモデルをあらわしている。

アーキテクチャモデルは、基本的に事前に用意され、検証済みのライブラリとして提供され、図２５では、検証済みのバスモデルが記述されている。このように、このアーキテクチャモデルでは、既存設計の物理的なハードウェア部品を用いているため、検証をおこなう必要はない。

（シリアル送受信システムを含むシステムＬＳＩの動作モデル）
つぎに、シリアル送受信システムを含むシステムＬＳＩの動作モデルについて説明する。動作モデルは、上述したように、概念的に、機能モデルをアーキテクチャモデルにマッピングした結果物である。図２６は、機能モデルとアーキテクチャモデルとのマッピングを示す説明図である。

図２６において、機能モデル２６００は、図２３に示したように、外部から受信したパケットをデコーダ２６０２が入力して復号し、コントローラ２６０３に供給する。コントローラ２６０３は復号されたパケットをエンコーダ２６０４に出力し、エンコーダ２６０４はパケットを符号化する。

アーキテクチャモデル２６１０は、バスやＩＰなどの既存設計の物理的なハードウェア部品をあらわすモデルであり、ここでは、プロセッサ２６１１、メモリ２６１２、外部入力Ｉ／Ｆ２６１３、外部出力Ｉ／Ｆ２６１４、ハードウェア２６１５、ハードウェア２６１６、ハードウェア２６１７、およびこれらを接続するバス２６１８から構成されている。

そして、このアーキテクチャモデル２６１０に、機能モデル２６００をマッピングする。具体的には、デコーダ２６０２をハードウェア２６１５に、コントローラ２６０３をハードウェア２６１６に、エンコーダ２６０４をハードウェア２６１７にマッピングする。この図２５および図２６を用いて説明した内容は、図５のステップＳ５０７に示した処理ステップに相当する内容である。

（シリアル送受信システムを含むシステムＬＳＩの動作モデルの実装コード生成処理手順）
つぎに、シリアル送受信システムを含むシステムＬＳＩの動作モデルの実装コード生成処理手順について説明する。図２７は、シリアル送受信システムを含むシステムＬＳＩの動作モデルの実装コード生成処理手順を示すフローチャートである。この図２７に示す処理手順は、図５のステップＳ５０７に示した処理ステップの詳細な処理手順を示している。

まず、図２６に示したマッピングを実現するため、図２２に示した分割設計クラス図２２１０〜２２４０の属性２２１１〜２２４１内の記述を、図２５に示したバスモデルの記述に置き換える（ステップＳ２７０１）。図２８は、属性２２１１内の記述がバスモデルの記述に置き換えられた分割設計クラス図２２１０を示す説明図である。図２８中、アンダーラインの記述箇所において、通信路が、ＦＩＦＯ方式の記述からバスモデルの記述に置き換えられている。

つぎに、バスモデルの記述に置き換えられた分割設計クラス図２２１０〜２２４０から、機能モデルの実装コードを生成する（ステップＳ２７０２）。そして、生成された機能モデルの実装コードに、各モジュールの見積もり処理時間を追加する（ステップＳ２７０３）。

図２９は、各モジュールの見積もり処理時間の実装コードへの追加例を示す説明図である。たとえば、図２９に示した図表２９００により、デコーダ２６０２およびエンコーダ２６０４の見積もり処理時間を、それぞれ６００［ｎｓ］とすると、機能モデルの実装コード（たとえば、図２４に示した実装コード２４００）に、図表２９００に示した処理時間に関する記述２９０１を追加する。これにより、動作モデルの実装コード２９０２が生成される。そして、図５のステップＳ５０８では、動作モデルの実装コード２９０２のシミュレーションを実行することとなる。

このあと、図５のステップＳ５０８において、このシミュレーション結果と、概念モデルの実装コードのシミュレーション結果との一致判定をおこない、一致する場合（ステップＳ５０９：Ｙｅｓ）、動作モデルの実装コード２９０２のシミュレーション結果が、図１３に示した要求項目リスト１３００のすべての要求項目１３０１〜１３０８を満足することとなり、機能モデルとアーキテクチャモデルとのマッピングが正当であることとなる。

一方、一致しない場合（ステップＳ５０９：Ｎｏ）、動作モデルの実装コード２９０２のシミュレーション結果が、図１３に示した要求項目リスト１３００のすべての要求項目１３０１〜１３０８を満足しておらず、機能モデルとアーキテクチャモデルとのマッピングが正当でないこととなる。この場合、図５のステップＳ５１０において、動作モデルの実装コード２９０２の修正処理をおこなうこととなる。これにより、顧客が要求した動作（性能）を満足するかどうかの検証をおこなうことができる。

（シリアル送受信システムを含むシステムＬＳＩのＩＣＡモデルの実装コード生成処理手順）
つぎに、シリアル送受信システムを含むシステムＬＳＩのＩＣＡモデルの実装コード生成処理手順について説明する。図３０は、シリアル送受信システムを含むシステムＬＳＩのＩＣＡモデルの実装コード生成処理手順を示すフローチャートである。この図３０に示す処理手順は、図５のステップＳ５１１に示した処理ステップの詳細な処理手順を示している。

ＩＣＡモデルは、上述したように、モジュール外のインターフェースについてはサイクル精度によって、モジュール内部は動作レベルによって構築したモデルである。このＩＣＡモデルを高位合成することによってＲＴＬ記述を生成する。このＩＣＡモデルでは、インターフェースの正確さの検証をおこなうことができる。

まず、通信路が決定された機能モデルの構造図から、抽象度の異なるモジュール間を通信する通信路を検出する（ステップＳ３００１）。図３１は、シリアル送受信システムを含むシステムＬＳＩの通信路が決定された機能モデルを示す構造図である。

図３１において、シリアル送受信システムは、図１７に示した設計クラス図を、並行、並列なモジュールに分割された結果（図２１のステップＳ２１０１を参照。）、トップモジュール２３０１と、ＣＰＵモジュール３１０１と、送信器モジュール３１０２と、受信器モジュール３１０３とが、ＦＩＦＯ方式の通信路３１１１〜３１１５によって接続されたシステムである。また、トップモジュール２３０１の内部は、図２３に示した構造図と同一内容である。これらのモジュールの接続関係から、抽象度の異なるモジュール間を通信する通信路を検出する。

つぎに、検出された通信路を、インターフェースラッパに置換する（ステップＳ３００２）。図３２は、図３１に示した構造図内の通信路にインターフェースラッパを挿入した構造図である。図３２では、図３１において、エンコーダモジュール２３０２の抽象度と送信器モジュール３１０２の抽象度が異なっているため、このモジュール２３０２、３１０２間の通信路３１１４をインターフェースラッパ３２０１に挿入し、トップモジュール２３０１の抽象度を変換する。

インターフェースラッパ３２０１は、送信器モジュール３１０２のトランザクションレベルのポート３１０２ａと接続されるトランザクションレベルインターフェース３２０２と、トップモジュール２３０１に接続される２つの信号レベルポート３２０３，３２０４を備えている。このため、トランザクションレベルのポート２３１４を、送信レベルポート３２１０、３２１１に置き換える。

また、トップモジュール２３０１内部のエンコーダモジュール２３０３のトランザクションレベルのポート２３３１〜２３３３も、信号レベルのポート３２１２〜３２１６に置き換える。このポート変換により、コントローラモジュール２３０２のトランザクションレベルのポート２３２４、２３２５も、信号レベルのポート３２１７〜３２１９に変換される。

このように、エンコーダモジュール２３０３のポート数が変更されるため、図３１に示したエンコーダモジュール２３０３をＩＣＡモデルのエンコーダモジュールに変換し（ステップＳ３００３）、エンコーダモジュール２３０３自体の抽象度を変換する。図３３は、ＩＣＡモデルのエンコーダモジュールの内部構造の一例を示す説明図である。

図３３において、ＩＣＡモデルのエンコーダモジュール３３００は、図３１に示したエンコーダモジュール２３０３およびポート２３３１〜２３３３を備えている。そして、ポート２３３１、２３３２と、ポート３２１２〜３２１４との間の通信を可能とするため、各種ラッパやポートが挿入されている。同様に、ポート２３３３と、ポート３２１５、３２１６との間の通信も可能とするため、各種ラッパやポートが挿入されている。

このあと、ＩＣＡモデルのエンコーダモジュール３３００の実装コードを生成する（ステップＳ３００４）。図３４は、ＩＣＡモデルのエンコーダモジュール３３００の実装コードの一例を示す説明図である。そして、図５のステップＳ５１２では、ＩＣＡモデルの実装コード３４００のシミュレーションを実行することとなる。

このあと、図５のステップＳ５１３において、ＩＣＡモデルの実装コード３４００のシミュレーション結果と、概念モデルの実装コードのシミュレーション結果との一致判定をおこない、一致する場合（ステップＳ５１３：Ｙｅｓ）、ＩＣＡモデルの実装コード３４００のシミュレーション結果が、図１３に示した要求項目リスト１３００のすべての要求項目１３０１〜１３０８を満足することとなり、インターフェースラッパの挿入が正当であることとなる。

一方、一致しない場合（ステップＳ５１３：Ｎｏ）、ＩＣＡモデルの実装コード３４００のシミュレーション結果が、図１３に示した要求項目リスト１３００のすべての要求項目１３０１〜１３０８を満足しておらず、インターフェースラッパの挿入が正当でないこととなる。

そして、図５に示したステップＳ５１４において、ＩＣＡモデルの実装コード３４００の修正処理をおこなうこととなる。これにより、インターフェースの正確さの検証をおこなうことができる。

（シリアル送受信システムを含むシステムＬＳＩのソフトウェアモデルの実装コード生成処理手順）
つぎに、シリアル送受信システムを含むシステムＬＳＩのソフトウェアモデルの実装コード生成処理手順について説明する。図３５は、シリアル送受信システムを含むシステムＬＳＩのソフトウェアモデルの実装コード生成処理手順を示すフローチャートである。この図３５に示す処理手順は、図５のステップＳ５１６に示した処理ステップの詳細な処理手順を示している。

ソフトウェアモデルは、上述したように、シリアル送受信システムを含むシステムＬＳＩを構成するソフトウェアのタスク分割をおこない、仮想ＯＳ上に実行するモデルである。図３５において、まず、アーキテクチャモデルに機能モデルの一部をソフトウェアによりマッピングする（ステップＳ３５０１）。

図３６は、アーキテクチャモデルに機能モデルの一部をソフトウェアによりマッピングをおこなった例を示す説明図である。具体的には、図２６に示したように、デコーダ２６０２はハードウェア２６１５にマッピングし、エンコーダ２６０４はハードウェア２６１７にマッピングする。一方、ＣＰＵ２６０１およびコントローラ２６０３は、プロセッサ２６１１にマッピングする。

つぎに、このマッピングにより、ソフトウェアモデルにおける設計クラス図を生成する（ステップＳ３５０２）。図３７は、ソフトウェアモデルにおける設計クラス図を示す説明図である。図３７において、ソフトウェアモデルにおける設計クラス図３７００は、図２２に示した分割設計クラス図２２１０〜２２４０を元にして生成される。

ソフトウェアモデルにおける設計クラス図３７００は、トップモジュールに関する分割設計クラス図３７０１と、デコーダモジュールに関する分割設計クラス図３７０２と、エンコーダモジュールに関する分割設計クラス図３７０３のほかに、仮想ＯＳモデルに関する分割設計クラス図３７０４を含んでいる。そして、設計クラス図３７０１〜３７０４ごとに、ソフトウェアモデルの実装コードを生成する（ステップＳ３５０３）。

このあと、図５のステップＳ５１７において、ソフトウェアモデルの実装コードのシミュレーションを実行することとなる。そして、図５のステップＳ５１８において、ソフトウェアモデルの実装コードのシミュレーション結果と、概念モデルの実装コードのシミュレーション結果との一致判定をおこなう。そして、一致する場合（ステップＳ５１８：Ｙｅｓ）、ソフトウェアモデルの実装コードのシミュレーション結果が、図１３に示した要求項目リスト１３００のすべての要求項目１３０１〜１３０８を満足することとなり、ソフトウェアのタスク分割が正当であることとなる。

一方、一致しない場合（ステップＳ５１８：Ｎｏ）、ソフトウェアモデルの実装コードのシミュレーション結果が、図１３に示した要求項目リスト１３００のすべての要求項目１３０１〜１３０８を満足しておらず、ソフトウェアのタスク分割が正当でないこととなる。

そして、図５に示したステップＳ５１９において、ソフトウェアモデルの実装コードの修正処理をおこなうこととなる。これにより、ソフトウェアのタスク分割の正確さの検証をおこなうことができる。

この発明の実施の形態にかかる検証支援装置および検証支援方法によれば、仕様リスクの早期回避を図ることができる。具体的には、顧客要求をＵＭＬで分析した上で、実行可能なモデルを用いて顧客の機能要求に満足するかどうかを検証することができ、仕様の誤解やミスを早期に発見することができ、誤った仕様に基づくシステムＬＳＩの設計を防止することができる。

また、この発明の実施の形態にかかる検証支援装置および検証支援方法によれば、シミュレーションスピードネックの解決を図ることができる。具体的には、従来の検証手法ではＲＴＬのシミュレータを用いてシミュレーションおこなうため、シミュレーション速度が非常に遅いという問題があったが、この実施の形態では、より抽象度の高いモデルを用いてシミュレーションを実行するため、ＲＴＬのシミュレータに比べて数百倍の速度でシミュレーションを実行することができる。したがって、このシミュレーション速度の向上により、検証作業を含めた設計期間の短縮化を図ることができる。

さらに、この発明の実施の形態にかかる検証支援装置および検証支援方法によれば、コストの削減を図ることができる。具体的には、従来の検証手法では大規模なＬＳＩの場合に高価なエミュレータを導入する必要があったが、この発明の実施の形態では、抽象度の高いモデルの検証によりエミュレータの利用頻度を大幅に減少することができ、コストの削減を図ることができる。また、エミュレータの利用は基本的に時間単位でお金に換算されるケースが多いため、検証時間の短縮化によって費用の低減を図ることができる。

また、この発明の実施の形態にかかる検証支援装置および検証支援方法によれば、早期仕様のミスをなくすことによって検証工程の短縮化を図ることができる。

また、従来手法に対するより効果的な改善点として、従来手法ではＲＴＬが完成されていないと検証工程をおこなうことができなかったが、この発明の実施の形態では、設計の初期の段階から検証を開始することができる。また、設計の詳細度に応じて各モデルに対してその正当性を検証することができる。これにより、従来における設計終了⇒検証スタートという手法に対して、大幅の設計工程の短縮化を図ることができる。

さらに、この発明の実施の形態にかかる検証支援装置および検証支援方法によれば、定量的なアーキテクチャ評価をおこなうことができる。具体的には、従来手法ではＲＴＬのＨＤＬを完成しない限り、性能評価できないという問題点があったが、ＲＴＬのＨＤＬを完成してから性能に満足しないという理由で設計変更をおこなうと、非常に高いコストがかかることとなる。

これに対し、この発明の実施の形態では、早期の段階でＲＴＬによる抽象度の高い動作モデルに対してラフな性能（動作）を見積ることができ、性能（動作）に満足しないというリスクの低減を図ることができる。

また、上述した具体例では、シリアル送受信システムを含むシステムＬＳＩを例に挙げて説明したが、このシステムＬＳＩには限定されることはなく、各種システムＬＳＩに適用することができる。

なお、この実施の形態で説明した検証支援方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション、ＣＡＤ等のコンピュータで実行することにより実現することができる。このプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。またこのプログラムは、インターネット等のネットワークを介して配布することが可能な伝送媒体であってもよい。

以上のように本発明は、たとえば、ＬＳＩの設計データの検証をおこなうシステムやツールを提供することに適している。

この発明の実施の形態にかかる検証支援の概念図である。 図１に示した各モデルの抽象度をあらわすグラフである。 この発明の実施の形態にかかる検証支援装置のハードウェア構成を示すブロック図である。 この発明の実施の形態にかかる検証支援装置の機能的構成を示すブロック図である。 この発明の実施の形態にかかる検証支援装置の検証支援処理手順を示すフローチャートである。 この発明の実施の形態にかかる設計対象を含むシステムＬＳＩのハードウェア構成を示すブロック図である。 外部装置のインターフェースであるバスの仕様（ライト時のタイミングチャート）を示す説明図である。 外部装置のインターフェースであるバスの仕様（リード時のタイミングチャート）を示す説明図である。 外部装置のインターフェースである送信器の仕様を示す説明図である。 外部装置のインターフェースである受信器の仕様を示す説明図である。 ＣＰＵで送受信されるパケットの構成を示す説明図である。 送信パケットの構成を示す説明図である。 要求定義であるシステムＬＳＩの要求項目リストを示す説明図である。 要求定義であるシステムＬＳＩのユースケース図である。 要求定義された結果物であるシステムＬＳＩの分析クラス図である。 要求定義された結果物であるシステムＬＳＩのシーケンス図である。 シリアル送受信システムを含むシステムＬＳＩの設計クラス図である。 概念モデルの実装コードを示す説明図である。 シリアル送受信システムを含むシステムＬＳＩの検証項目を示す説明図である。 シリアル送受信システムを含むシステムＬＳＩの検証シナリオを示す説明図である。 シリアル送受信システムを含むシステムＬＳＩの機能モデルの実装コード生成処理手順を示すフローチャートである。 図１７に示した設計クラス図を分割することによって得られた分割設計クラス図を示す説明図である。 分割設計クラス図によってあらわされるモジュール間を接続する通信路を示す説明図である。 シリアル送受信システムを含むシステムＬＳＩの機能モデルの実装コードの生成例を示す説明図である。 シリアル送受信システムを含むシステムＬＳＩのアーキテクチャモデルのクラス図の一例を示す説明図である。 機能モデルとアーキテクチャモデルとのマッピングを示す説明図である。 シリアル送受信システムを含むシステムＬＳＩの動作モデルの実装コード生成処理手順を示すフローチャートである。 属性内の記述がバスモデルの記述に置き換えられた分割設計クラス図を示す説明図である。 各モジュールの見積もり処理時間の実装コードへの追加例を示す説明図である。 シリアル送受信システムを含むシステムＬＳＩのＩＣＡモデルの実装コード生成処理手順を示すフローチャートである。 シリアル送受信システムを含むシステムＬＳＩの通信路が決定された機能モデルを示す構造図である。 図３１に示した構造図内の通信路にインターフェースラッパを挿入した構造図である。 ＩＣＡモデルのエンコーダモジュールの内部構造の一例を示す説明図である。 ＩＣＡモデルのエンコーダモジュールの実装コードの一例を示す説明図である。 シリアル送受信システムを含むシステムＬＳＩのソフトウェアモデルの実装コード生成処理手順を示すフローチャートである。 アーキテクチャモデルに機能モデルの一部をソフトウェアによりマッピングをおこなった例を示す説明図である。 ソフトウェアモデルにおける設計クラス図を示す説明図である。 従来のＬＳＩの開発処理手順を示すフローチャートである。

符号の説明

１００ 要求仕様
１０１ 概念モデル
１０２ 機能モデル
１０３ アーキテクチャモデル
１０４ 動作モデル
１０５ ＩＣＡモデル
１０６ ソフトウェアモデル
４０１ 分析情報入力部
４０２ 概念モデル生成部
４０３ 機能モデル生成部
４０４ 機能モデル検証部
４０５ アーキテクチャ情報記憶部
４０６ アーキテクチャ情報抽出部
４０７ 動作モデル生成部
４０８ 動作モデル検証部
４０９ ＩＣＡモデル生成部
４１０ ＩＣＡモデル検証部
４１１ ソフトウェアモデル生成部
４１２ ソフトウェアモデル検証部

Claims (13)

1. ＬＳＩの設計対象に関する要求仕様の分析結果を示す分析情報の入力を受け付ける分析情報入力手段と、
   前記分析情報入力手段によって入力された分析情報に基づいて、前記設計対象の基本機能がモデル化され、かつ、前記設計対象の物理的なアーキテクチャおよび時間の概念が抽象化された概念モデルを生成する概念モデル生成手段と、
   前記分析情報入力手段によって入力された分析情報に基づいて、前記設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性を抽出することによってモデル化された機能モデルを生成する機能モデル生成手段と、
   前記機能モデル生成手段によって生成された機能モデルについて、前記設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性が正当であるかどうかを、前記概念モデル生成手段によって生成された概念モデルに基づいて検証する機能モデル検証手段と、
   を備えることを特徴とする検証支援装置。
2. 複数種類の物理的なアーキテクチャに関する情報を記憶する記憶手段と、
   前記機能モデル検証手段によって正当であることが検証された場合、前記記憶手段から任意のアーキテクチャに関する情報を抽出する抽出手段と、
   前記抽出手段によって抽出されたアーキテクチャに関する情報を、前記機能モデル検証手段によって正当であることが検証された機能モデルにマッピングすることにより、前記設計対象の動作をモデル化した動作モデルを生成する動作モデル生成手段と、
   前記動作モデル生成手段によって生成された動作モデルによりモデル化された設計対象を構成するモジュールの動作タイミングが、正当であるかどうかを検証する動作モデル検証手段と、
   を備えることを特徴とする請求項１に記載の検証支援装置。
3. 前記動作モデル検証手段によって正当であることが検証された場合、前記機能モデルによってモデル化された設計対象を構成するモジュール間の抽象度が異なる箇所に、当該モジュール間に所定のクロックサイクル精度のインターフェースを挿入することによりＩＣＡモデルを生成するＩＣＡモデル生成手段と、
   前記ＩＣＡモデル生成手段によって生成されたＩＣＡモデルに挿入されたインターフェースのクロックサイクル精度が正当であるかどうかを、前記概念モデル生成手段によって生成された概念モデルに基づいて検証するＩＣＡモデル検証手段と、
   を備えることを特徴とする請求項２に記載の検証支援装置。
4. 前記動作モデル検証手段によって正当であることが検証された場合、前記機能モデルによってモデル化された設計対象に基づいて、ソフトウェアによって実行可能なタスクを含むようにモデル化されたソフトウェアモデルを生成するソフトウェアモデル生成手段と、
   前記ソフトウェアモデル生成手段によって生成されたソフトウェアモデルに含まれているタスクが正当であるかどうかを、前記概念モデル生成手段によって生成された概念モデルに基づいて検証するソフトウェアモデル検証手段と、
   を備えることを特徴とする請求項２または３に記載の検証支援装置。
5. ＬＳＩの設計対象に関する要求仕様の分析結果を示す分析情報を入力する分析情報入力工程と、
   前記分析情報入力工程によって入力された分析情報に基づいて、前記設計対象の基本機能がモデル化され、かつ、前記設計対象の物理的なアーキテクチャおよび時間の概念が抽象化された概念モデルを生成する概念モデル生成工程と、
   前記分析情報入力工程によって入力された分析情報に基づいて、前記設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性を抽出することによってモデル化された機能モデルを生成する機能モデル生成工程と、
   前記機能モデル生成工程によって生成された機能モデルについて、前記設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性が正当であるかどうかを、前記概念モデル生成工程によって生成された概念モデルに基づいて検証する機能モデル検証工程と、
   を含んだことを特徴とする検証支援方法。
6. 前記機能モデル検証工程によって正当であることが検証された場合、複数種類の物理的なアーキテクチャに関する情報の中から、任意のアーキテクチャに関する情報を抽出する抽出工程と、
   前記抽出工程によって抽出されたアーキテクチャに関する情報を、前記機能モデル検証工程によって正当であることが検証された機能モデルにマッピングすることにより、前記設計対象の動作をモデル化した動作モデルを生成する動作モデル生成工程と、
   前記動作モデル生成工程によって生成された動作モデルによりモデル化された設計対象を構成するモジュールの動作タイミングが、正当であるかどうかを検証する動作モデル検証工程と、
   を含んだことを特徴とする請求項５に記載の検証支援方法。
7. 前記動作モデル検証工程によって正当であることが検証された場合、前記機能モデルによってモデル化された設計対象を構成するモジュール間の抽象度が異なる箇所に、当該モジュール間に所定のクロックサイクル精度のインターフェースを挿入することによりＩＣＡモデルを生成するＩＣＡモデル生成工程と、
   前記ＩＣＡモデル生成工程によって生成されたＩＣＡモデルに挿入されたインターフェースのクロックサイクル精度が正当であるかどうかを、前記概念モデル生成工程によって生成された概念モデルに基づいて検証するＩＣＡモデル検証工程と、
   を含んだことを特徴とする請求項６に記載の検証支援方法。
8. 前記動作モデル検証工程によって正当であることが検証された場合、前記機能モデルによってモデル化された設計対象に基づいて、ソフトウェアによって実行可能なタスクを含むようにモデル化されたソフトウェアモデルを生成するソフトウェアモデル生成工程と、
   前記ソフトウェアモデル生成工程によって生成されたソフトウェアモデルに含まれているタスクが正当であるかどうかを、前記概念モデル生成工程によって生成された概念モデルに基づいて検証するソフトウェアモデル検証工程と、
   を含んだことを特徴とする請求項６または７に記載の検証支援方法。
9. ＬＳＩの設計対象に関する要求仕様の分析結果を示す分析情報を入力させる分析情報入力工程と、
   前記分析情報入力工程によって入力された分析情報に基づいて、前記設計対象の基本機能がモデル化され、かつ、前記設計対象の物理的なアーキテクチャおよび時間の概念が抽象化された概念モデルを生成させる概念モデル生成工程と、
   前記分析情報入力工程によって入力された分析情報に基づいて、前記設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性を抽出することによってモデル化された機能モデルを生成させる機能モデル生成工程と、
   前記機能モデル生成工程によって生成された機能モデルについて、前記設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性が正当であるかどうかを、前記概念モデル生成工程によって生成された概念モデルに基づいて検証させる機能モデル検証工程と、
   をコンピュータに実行させることを特徴とする検証支援プログラム。
10. 前記機能モデル検証工程によって正当であることが検証された場合、複数種類の物理的なアーキテクチャに関する情報の中から、任意のアーキテクチャに関する情報を抽出させる抽出工程と、
    前記抽出工程によって抽出されたアーキテクチャに関する情報を、前記機能モデル検証工程によって正当であることが検証された機能モデルにマッピングすることにより、前記設計対象の動作をモデル化した動作モデルを生成させる動作モデル生成工程と、
    前記動作モデル生成工程によって生成された動作モデルによりモデル化された設計対象を構成するモジュールの動作タイミングが、正当であるかどうかを検証させる動作モデル検証工程と、
    を含んだことを特徴とする請求項９に記載の検証支援プログラム。
11. 前記動作モデル検証工程によって正当であることが検証された場合、前記機能モデルによってモデル化された設計対象を構成するモジュール間の抽象度が異なる箇所に、当該モジュール間に所定のクロックサイクル精度のインターフェースを挿入することによりＩＣＡモデルを生成させるＩＣＡモデル生成工程と、
    前記ＩＣＡモデル生成工程によって生成されたＩＣＡモデルに挿入されたインターフェースのクロックサイクル精度が正当であるかどうかを、前記概念モデル生成工程によって生成された概念モデルに基づいて検証させるＩＣＡモデル検証工程と、
    を含んだことを特徴とする請求項１０に記載の検証支援プログラム。
12. 前記動作モデル検証工程によって正当であることが検証された場合、前記機能モデルによってモデル化された設計対象に基づいて、ソフトウェアによって実行可能なタスクを含むようにモデル化されたソフトウェアモデルを生成させるソフトウェアモデル生成工程と、
    前記ソフトウェアモデル生成工程によって生成されたソフトウェアモデルに含まれているタスクが正当であるかどうかを、前記概念モデル生成工程によって生成された概念モデルに基づいて検証させるソフトウェアモデル検証工程と、
    を含んだことを特徴とする請求項１０または１１に記載の検証支援プログラム。
13. 請求項９〜１２のいずれか一つに記載の検証支援プログラムを記録したコンピュータ読取り可能な記録媒体。

Images