(57)【要約】  検証支援装置（４００）は、概念モデル生成部（４０２）による、顧客の要求仕様に着目した概念モデルを生成することにより、設計の初期段階で仕様のミスや誤解を解消する。また、機能モデル検証部（４０４）による、並列、並行な機能モデルの検証によって、機能モジュール分割の妥当性、並列、並行性の正しさを検証する。また、動作モデル検証部（４０８）による動作モデルの検証によってアーキテクチャの設計の妥当性、性能要件に満足しているかどうかを検証する。また、ＩＣＡモデル検証部（４１０）によってインターフェース設計の正しさを検証する。このように、段階的に検証を導入することによって、これまで、ＲＴＬを生成しないと発見できなかった問題を、設計の早期段階に摘出してそのリスクを回避することができる。【特許請求の範囲】
【請求項１】
ＬＳＩの設計対象に関する要求仕様の分析結果を示す分析情報の入力を受け付ける分析情報入力手段と、
前記分析情報入力手段によって入力された分析情報に基づいて、前記設計対象の基本機能がモデル化され、かつ、前記設計対象の物理的なアーキテクチャおよび時間の概念が抽象化された概念モデルを生成する概念モデル生成手段と、
前記分析情報入力手段によって入力された分析情報に基づいて、前記設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性を抽出することによってモデル化された機能モデルを生成する機能モデル生成手段と、
前記機能モデル生成手段によって生成された機能モデルについて、前記設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性が正当であるかどうかを、前記概念モデル生成手段によって生成された概念モデルに基づいて検証する機能モデル検証手段と、
を備えることを特徴とする検証支援装置。
【請求項２】
複数種類の物理的なアーキテクチャに関する情報を記憶する記憶手段と、
前記機能モデル検証手段によって正当であることが検証された場合、前記記憶手段から任意のアーキテクチャに関する情報を抽出する抽出手段と、
前記抽出手段によって抽出されたアーキテクチャに関する情報を、前記機能モデル検証手段によって正当であることが検証された機能モデルにマッピングすることにより、前記設計対象の動作をモデル化した動作モデルを生成する動作モデル生成手段と、
前記動作モデル生成手段によって生成された動作モデルによりモデル化された設計対象を構成するモジュールの動作タイミングが、正当であるかどうかを検証する動作モデル検証手段と、
を備えることを特徴とする請求項１に記載の検証支援装置。
【請求項３】
前記動作モデル検証手段によって正当であることが検証された場合、前記機能モデルによってモデル化された設計対象を構成するモジュール間の抽象度が異なる箇所に、当該モジュール間に所定のクロックサイクル精度のインターフェースを挿入することによりＩＣＡモデルを生成するＩＣＡモデル生成手段と、
前記ＩＣＡモデル生成手段によって生成されたＩＣＡモデルに挿入されたインターフェースのクロックサイクル精度が正当であるかどうかを、前記概念モデル生成手段によって生成された概念モデルに基づいて検証するＩＣＡモデル検証手段と、
を備えることを特徴とする請求項２に記載の検証支援装置。
【請求項４】
前記動作モデル検証手段によって正当であることが検証された場合、前記機能モデルによってモデル化された設計対象に基づいて、ソフトウェアによって実行可能なタスクを含むようにモデル化されたソフトウェアモデルを生成するソフトウェアモデル生成手段と、
前記ソフトウェアモデル生成手段によって生成されたソフトウェアモデルに含まれているタスクが正当であるかどうかを、前記概念モデル生成手段によって生成された概念モデルに基づいて検証するソフトウェアモデル検証手段と、
を備えることを特徴とする請求項２または３に記載の検証支援装置。
【請求項５】
ＬＳＩの設計対象に関する要求仕様の分析結果を示す分析情報を入力する分析情報入力工程と、
前記分析情報入力工程によって入力された分析情報に基づいて、前記設計対象の基本機能がモデル化され、かつ、前記設計対象の物理的なアーキテクチャおよび時間の概念が抽象化された概念モデルを生成する概念モデル生成工程と、
前記分析情報入力工程によって入力された分析情報に基づいて、前記設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性を抽出することによってモデル化された機能モデルを生成する機能モデル生成工程と、
前記機能モデル生成工程によって生成された機能モデルについて、前記設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性が正当であるかどうかを、前記概念モデル生成工程によって生成された概念モデルに基づいて検証する機能モデル検証工程と、
を含んだことを特徴とする検証支援方法。
【請求項６】
前記機能モデル検証工程によって正当であることが検証された場合、複数種類の物理的なアーキテクチャに関する情報の中から、任意のアーキテクチャに関する情報を抽出する抽出工程と、
前記抽出工程によって抽出されたアーキテクチャに関する情報を、前記機能モデル検証工程によって正当であることが検証された機能モデルにマッピングすることにより、前記設計対象の動作をモデル化した動作モデルを生成する動作モデル生成工程と、
前記動作モデル生成工程によって生成された動作モデルによりモデル化された設計対象を構成するモジュールの動作タイミングが、正当であるかどうかを検証する動作モデル検証工程と、
を含んだことを特徴とする請求項５に記載の検証支援方法。
【請求項７】
前記動作モデル検証工程によって正当であることが検証された場合、前記機能モデルによってモデル化された設計対象を構成するモジュール間の抽象度が異なる箇所に、当該モジュール間に所定のクロックサイクル精度のインターフェースを挿入することによりＩＣＡモデルを生成するＩＣＡモデル生成工程と、
前記ＩＣＡモデル生成工程によって生成されたＩＣＡモデルに挿入されたインターフェースのクロックサイクル精度が正当であるかどうかを、前記概念モデル生成工程によって生成された概念モデルに基づいて検証するＩＣＡモデル検証工程と、
を含んだことを特徴とする請求項６に記載の検証支援方法。
【請求項８】
前記動作モデル検証工程によって正当であることが検証された場合、前記機能モデルによってモデル化された設計対象に基づいて、ソフトウェアによって実行可能なタスクを含むようにモデル化されたソフトウェアモデルを生成するソフトウェアモデル生成工程と、
前記ソフトウェアモデル生成工程によって生成されたソフトウェアモデルに含まれているタスクが正当であるかどうかを、前記概念モデル生成工程によって生成された概念モデルに基づいて検証するソフトウェアモデル検証工程と、
を含んだことを特徴とする請求項６または７に記載の検証支援方法。
【請求項９】
ＬＳＩの設計対象に関する要求仕様の分析結果を示す分析情報を入力させる分析情報入力工程と、
前記分析情報入力工程によって入力された分析情報に基づいて、前記設計対象の基本機能がモデル化され、かつ、前記設計対象の物理的なアーキテクチャおよび時間の概念が抽象化された概念モデルを生成させる概念モデル生成工程と、
前記分析情報入力工程によって入力された分析情報に基づいて、前記設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性を抽出することによってモデル化された機能モデルを生成させる機能モデル生成工程と、
前記機能モデル生成工程によって生成された機能モデルについて、前記設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性が正当であるかどうかを、前記概念モデル生成工程によって生成された概念モデルに基づいて検証させる機能モデル検証工程と、
をコンピュータに実行させることを特徴とする検証支援プログラム。
【請求項１０】
前記機能モデル検証工程によって正当であることが検証された場合、複数種類の物理的なアーキテクチャに関する情報の中から、任意のアーキテクチャに関する情報を抽出させる抽出工程と、
前記抽出工程によって抽出されたアーキテクチャに関する情報を、前記機能モデル検証工程によって正当であることが検証された機能モデルにマッピングすることにより、前記設計対象の動作をモデル化した動作モデルを生成させる動作モデル生成工程と、
前記動作モデル生成工程によって生成された動作モデルによりモデル化された設計対象を構成するモジュールの動作タイミングが、正当であるかどうかを検証させる動作モデル検証工程と、
を含んだことを特徴とする請求項９に記載の検証支援プログラム。
【請求項１１】
前記動作モデル検証工程によって正当であることが検証された場合、前記機能モデルによってモデル化された設計対象を構成するモジュール間の抽象度が異なる箇所に、当該モジュール間に所定のクロックサイクル精度のインターフェースを挿入することによりＩＣＡモデルを生成させるＩＣＡモデル生成工程と、
前記ＩＣＡモデル生成工程によって生成されたＩＣＡモデルに挿入されたインターフェースのクロックサイクル精度が正当であるかどうかを、前記概念モデル生成工程によって生成された概念モデルに基づいて検証させるＩＣＡモデル検証工程と、
を含んだことを特徴とする請求項１０に記載の検証支援プログラム。
【請求項１２】
前記動作モデル検証工程によって正当であることが検証された場合、前記機能モデルによってモデル化された設計対象に基づいて、ソフトウェアによって実行可能なタスクを含むようにモデル化されたソフトウェアモデルを生成させるソフトウェアモデル生成工程と、
前記ソフトウェアモデル生成工程によって生成されたソフトウェアモデルに含まれているタスクが正当であるかどうかを、前記概念モデル生成工程によって生成された概念モデルに基づいて検証させるソフトウェアモデル検証工程と、
を含んだことを特徴とする請求項１０または１１に記載の検証支援プログラム。
【請求項１３】
請求項９〜１２のいずれか一つに記載の検証支援プログラムを記録したコンピュータ読取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＬＳＩの検証を支援する検証支援装置、検証支援方法、検証支援プログラムおよび記録媒体に関する。
【背景技術】
【０００２】
ＬＳＩ設計では、ＬＳＩが正常に動作するか否かを検証する検証作業が必要不可欠であり、特に、大規模化、高機能化、高速化および低消費電力化が要求されているＬＳＩについては、高品質を維持するためにもこの検証作業は重要である一方、従来から設計期間の短縮による作業効率化が要求されている。【０００３】
特に、近年は、ソフトウェアとハードウェアが混在しており、従来型のＡＳＩＣによる単機能のハードウェアだけではなく、ソフトウェアも含めたシステム・オン・チップ（ＳｏＣ）が主流となっている。また、ＭＰＥＧやＪＰＥＧなど、本来アプリケーションソフトウェアで実現される機能がハードウェアで実現するようになっているため、ＬＳＩの機能が複雑化している。【０００４】
ここで、従来のＬＳＩの開発処理について説明する。図３８は、従来のＬＳＩの開発処理手順を示すフローチャートである。図３８において、ステップＳ３８０１〜ステップＳ３８０５が、ＬＳＩの設計をおこなう設計フローであり、ステップＳ３８０６〜ステップＳ３８０９が、設計されたＬＳＩの検証をおこなう検証フローである。【０００５】
まず、設計フローでは、ステップＳ３８０１において、概念設計をおこなう。概念設計では、顧客からの設計要求に基づいて設計者が要求仕様書３８１０を自然言語によって作成する。または、顧客から自然言語で記述された要求仕様書３８１０を受け取る。【０００６】
つぎに、ステップＳ３８０２において、機能設計をおこなう。機能設計では、要求仕様書３８１０に記述された内容から、設計対象となるＬＳＩを機能ブロックごとに分けて、各機能ブロックの内容を記述した機能仕様書３８２０を作成する。【０００７】
つぎに、ステップＳ３８０３において、構造設計をおこなう。構造設計では、機能仕様書３８２０からハードウェア設計をおこなって構造仕様書３８３０を作成する。具体的には、どのようなアーキテクチャを導入すれば機能仕様書３８２０に記述された機能を実現できるか、という設計をおこなうことである。【０００８】
たとえば、各機能ブロックのうち、ある機能ブロックのアーキテクチャについてはソフトウェアによって実現し、ある機能ブロックのアーキテクチャについてはＩＰ（Ｉｎｔｅｌｌｅｃｔｕａｌ  Ｐｒｏｐｅｒｔｙ）を購入して実現し、ある機能ブロックのアーキテクチャについては設計者が作成し、ある機能ブロックのアーキテクチャについては、アンダーバスによって実現するということである。【０００９】
つぎに、ステップＳ３８０４において、ユニット設計をおこなう。ユニット設計では、構造仕様書３８３０に記述された各ハードウェアモジュールを複数のモジュールに分割して詳細に設計することによってユニット仕様書３８４０を作成する。【００１０】
つぎに、ステップＳ３８０５において、実装をおこなう。実装では、インターフェースのタイミングチャートを用い、また、内部ロジックを考慮することにより、最終的な設計対象となるＲＴＬ（Ｒｅｇｉｓｔｅｒ  Ｔｒａｎｓｆｅｒ  Ｌｅｖｅｌ）３８５０のＨＤＬ（Ｈａｒｄｗａｒｅ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ）を用いて実装をおこなう。【００１１】
つぎに、ステップＳ３８０６において、ユニット検証をおこなう。ユニット検証では、ユニット検証項目３８６０にしたがって、ユニット設計によって設計されたユニットごとのユニット仕様書３８４０の検証、すなわち、デバッグをおこなう。【００１２】
つぎに、ステップＳ３８０７において、結合検証をおこなう。結合検証では、結合検証項目３８７０にしたがって、ユニット検証によって検証された各ユニットのインターフェースを結合して、正常に動作するかを検証する。【００１３】
つぎに、ステップＳ３８０８において、機能検証をおこなう。機能検証では、機能検証項目３８８０にしたがって、設計対象となるシステムの機能要求を満たすかどうかを検証する。【００１４】
最後に、ステップＳ３８０９において、実機検証をおこなう。実機検証では、ＲＴＬ３８５０を用いて実際にチップ上にＬＳＩを実装して、実際に動作するかどうかを検証する。顧客からの要求仕様書３８１０が、要求検証項目３８９０を満足しているかどうかを判断する。
【発明の開示】
【発明が解決しようとする課題】
【００１５】
しかしながら、上述した設計処理では、実装（ステップＳ３８０５）しなければ、ＬＳＩの検証（ステップＳ３８０６〜Ｓ３８０９）をおこなうことができなかった。【００１６】
これにより、設計フローの上流のいずれかのステップにおいて仕様書の誤り、記述の曖昧さ、設計者の誤解釈のためにミスが生じると、そのステップ以降のステップにおいてミスが累積されてしまうという問題があった。【００１７】
また、構造設計においては、机上でアーキテクチャを決定しており、その妥当性を確かめる手法が存在していなかった。したがって、開発リスクの増大によって開発プロジェクトの破綻も生じ、開発時間および開発労力が無駄になるという問題があった。【００１８】
また、ＲＴＬ３８５０のＨＤＬに対してシミュレーションをおこなうために特別なシミュレータ(ＶＣＳ、ＮＣ−ＳｉｍなどのＥＤＡベンダーのツール)が必要であるが、シミュレーションスピードが遅いために検証効率が低下し、設計期間の長期化を招くという問題があった。特に、設計対象が大規模な場合、シミュレーションスピードがネックとなって、所定の期間内に検証作業を収束させることができない場合があった。【００１９】
一方、シミュレータより何千倍のスピードで動くエミュレータを導入してシミュレーションの速度の向上を図ることも考えられるが、エミュレータが非常に高価であり、検証費用が増大するとともに、環境の構築が困難な上に問題発生時にデバッグが難しいために結果的に検証期間が増加して、設計期間の長期化を招くという問題があった。【００２０】
本発明は、上記問題点に鑑みてなされたものであって、ＬＳＩの設計精度の向上および検証期間の短縮化を、容易かつ効率的に実現することができる検証支援装置、検証支援方法、検証支援プログラムおよび該プログラムを記録した記録媒体を提供することを目的とする。
【課題を解決するための手段】
【００２１】
上述した課題を解決し、目的を達成するため、本発明の検証支援装置、検証支援方法、検証支援プログラムおよび該プログラムを記録した記録媒体は、ＬＳＩの設計対象に関する要求仕様の分析結果を示す分析情報を入力し、入力された分析情報に基づいて、前記設計対象の基本機能がモデル化され、かつ、前記設計対象の物理的なアーキテクチャおよび時間の概念が抽象化された概念モデルを生成し、入力された分析情報に基づいて、前記設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性を抽出することによってモデル化された機能モデルを生成し、生成された機能モデルについて、前記設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性が正当であるかどうかを、生成された概念モデルに基づいて検証することを特徴とする。【００２２】
また、上記発明は、前記機能モデルが正当であることが検証された場合、複数種類の物理的なアーキテクチャに関する情報から任意のアーキテクチャに関する情報を抽出し、抽出されたアーキテクチャに関する情報を、正当であることが検証された機能モデルにマッピングすることにより、前記設計対象の動作をモデル化した動作モデルを生成し、生成された動作モデルによりモデル化された設計対象を構成するモジュールの動作タイミングが、正当であるかどうかを検証することを特徴とする。【００２３】
さらに、上記発明は、前記動作モデルが正当であることが検証された場合、前記機能モデルによってモデル化された設計対象を構成するモジュール間の抽象度が異なる箇所に、当該モジュール間に所定のクロックサイクル精度のインターフェースを挿入することによりＩＣＡモデルを生成し、生成されたＩＣＡモデルに挿入されたインターフェースのクロックサイクル精度が正当であるかどうかを、生成された概念モデルに基づいて検証することを特徴とする。【００２４】
また、前記動作モデルが正当であることが検証された場合、前記機能モデルによってモデル化された設計対象に基づいて、ソフトウェアによって実行可能なタスクを含むようにモデル化されたソフトウェアモデルを生成し、生成されたソフトウェアモデルに含まれているタスクが正当であるかどうかを、生成された概念モデルに基づいて検証することを特徴とする。
【発明の効果】
【００２５】
この発明の検証支援装置、検証支援方法、検証支援プログラムおよび記録媒体によれば、段階的に検証を導入することによって、これまで、ＲＴＬを生成しないと発見できなかった問題を、設計の早期段階に摘出してそのリスクを回避することができる。したがって、ＬＳＩの設計精度の向上および検証期間の短縮化を、容易かつ効率的に実現することができるという効果を奏する。
【図面の簡単な説明】
【００２６】
【図１】この発明の実施の形態にかかる検証支援の概念図である。
【図２】図１に示した各モデルの抽象度をあらわすグラフである。
【図３】この発明の実施の形態にかかる検証支援装置のハードウェア構成を示すブロック図である。
【図４】この発明の実施の形態にかかる検証支援装置の機能的構成を示すブロック図である。
【図５】この発明の実施の形態にかかる検証支援装置の検証支援処理手順を示すフローチャートである。
【図６】この発明の実施の形態にかかる設計対象を含むシステムＬＳＩのハードウェア構成を示すブロック図である。
【図７】外部装置のインターフェースであるバスの仕様（ライト時のタイミングチャート）を示す説明図である。
【図８】外部装置のインターフェースであるバスの仕様（リード時のタイミングチャート）を示す説明図である。
【図９】外部装置のインターフェースである送信器の仕様を示す説明図である。
【図１０】外部装置のインターフェースである受信器の仕様を示す説明図である。
【図１１】ＣＰＵで送受信されるパケットの構成を示す説明図である。
【図１２】送信パケットの構成を示す説明図である。
【図１３】要求定義であるシステムＬＳＩの要求項目リストを示す説明図である。
【図１４】要求定義であるシステムＬＳＩのユースケース図である。
【図１５】要求定義された結果物であるシステムＬＳＩの分析クラス図である。
【図１６】要求定義された結果物であるシステムＬＳＩのシーケンス図である。
【図１７】シリアル送受信システムを含むシステムＬＳＩの設計クラス図である。
【図１８】概念モデルの実装コードを示す説明図である。
【図１９】シリアル送受信システムを含むシステムＬＳＩの検証項目を示す説明図である。
【図２０】シリアル送受信システムを含むシステムＬＳＩの検証シナリオを示す説明図である。
【図２１】シリアル送受信システムを含むシステムＬＳＩの機能モデルの実装コード生成処理手順を示すフローチャートである。
【図２２】図１７に示した設計クラス図を分割することによって得られた分割設計クラス図を示す説明図である。
【図２３】分割設計クラス図によってあらわされるモジュール間を接続する通信路を示す説明図である。
【図２４】シリアル送受信システムを含むシステムＬＳＩの機能モデルの実装コードの生成例を示す説明図である。
【図２５】シリアル送受信システムを含むシステムＬＳＩのアーキテクチャモデルのクラス図の一例を示す説明図である。
【図２６】機能モデルとアーキテクチャモデルとのマッピングを示す説明図である。
【図２７】シリアル送受信システムを含むシステムＬＳＩの動作モデルの実装コード生成処理手順を示すフローチャートである。
【図２８】属性内の記述がバスモデルの記述に置き換えられた分割設計クラス図を示す説明図である。
【図２９】各モジュールの見積もり処理時間の実装コードへの追加例を示す説明図である。
【図３０】シリアル送受信システムを含むシステムＬＳＩのＩＣＡモデルの実装コード生成処理手順を示すフローチャートである。
【図３１】シリアル送受信システムを含むシステムＬＳＩの通信路が決定された機能モデルを示す構造図である。
【図３２】図３１に示した構造図内の通信路にインターフェースラッパを挿入した構造図である。
【図３３】ＩＣＡモデルのエンコーダモジュールの内部構造の一例を示す説明図である。
【図３４】ＩＣＡモデルのエンコーダモジュールの実装コードの一例を示す説明図である。
【図３５】シリアル送受信システムを含むシステムＬＳＩのソフトウェアモデルの実装コード生成処理手順を示すフローチャートである。
【図３６】アーキテクチャモデルに機能モデルの一部をソフトウェアによりマッピングをおこなった例を示す説明図である。
【図３７】ソフトウェアモデルにおける設計クラス図を示す説明図である。
【図３８】従来のＬＳＩの開発処理手順を示すフローチャートである。
【符号の説明】
【００２７】
１００  要求仕様
１０１  概念モデル
１０２  機能モデル
１０３  アーキテクチャモデル
１０４  動作モデル
１０５  ＩＣＡモデル
１０６  ソフトウェアモデル
４０１  分析情報入力部
４０２  概念モデル生成部
４０３  機能モデル生成部
４０４  機能モデル検証部
４０５  アーキテクチャ情報記憶部
４０６  アーキテクチャ情報抽出部
４０７  動作モデル生成部
４０８  動作モデル検証部
４０９  ＩＣＡモデル生成部
４１０  ＩＣＡモデル検証部
４１１  ソフトウェアモデル生成部
４１２  ソフトウェアモデル検証部
【発明を実施するための最良の形態】
【００２８】
（実施の形態）
以下に、本発明の実施の形態にかかる検証支援装置、検証支援方法、検証支援プログラムおよび該プログラムを記録した記録媒体について図面を参照しつつ詳細に説明する。【００２９】
（検証支援の概念）
まず、この発明の実施の形態にかかる検証支援の概念について説明する。図１は、この発明の実施の形態にかかる検証支援の概念図である。【００３０】
図１において、設計者は、設計対象を含むシステムＬＳＩの顧客からの要求仕様１００について、ＵＭＬ（Ｕｎｉｆｉｅｄ  Ｍｏｄｅｌｉｎｇ  Ｌａｎｇｕａｇｅ）を用いてオブジェクト指向分析をおこない、その分析結果を概念モデル１０１としてモデリングする。概念モデル１０１とは、設計対象の概念的な分析結果をあらわすモデルである。概念モデル１０１は、完全に実装依存しないモデルであり、具体的には、物理的なアーキテクチャや時間の概念が抽象化され、設計対象の基本機能を中心にモデリングされたものである。【００３１】
概念モデル１０１は、具体的には、システムＬＳＩの要求仕様の分析結果を、ＵＭＬやＣ＋＋でモデリングした結果物であり、ＵＭＬモデル、Ｃ＋＋モデル、および検証シナリオのすべてを含めた総称である。この概念モデル１０１では、要求仕様１００の誤解やミス、またはアルゴリズムの検証をおこなうことができる。【００３２】
また、機能モデル１０２は、概念モデル１０１から、設計対象であるシステムＬＳＩを構成するモジュールの分割、分割されたモジュールの並行または並列性を抽出することによって構築されたモデルである。機能モデル１０２は、時間の概念が存在しない。この機能モデルでは、モジュール分割の正当性や、並列、並行性の正確さを検証することができる。【００３３】
また、アーキテクチャモデル１０３は、バスやＩＰ（Ｉｎｔｅｌｌｅｃｔｕａｌ  Ｐｒｏｐｅｒｔｙ）などの既存設計の物理的なハードウェア部品をあらわすモデルである。アーキテクチャモデル１０３は、具体的には、処理リソースと、通信リソースとに大別される。処理リソースは、機能モデル１０２のモジュールをマッピングするためのモデルである。たとえば、ハードウェア処理モジュール、プロセッサ、ＲＴＯＳ、ＤＳＰなどが挙げられる。【００３４】
一方、通信リソースは、機能モデルのモジュール間の通信を実現するためのチャンネルをモデリングしたモデルである。たとえば、バス、メモリ、ハードウェアモジュール間の信号線などが挙げられる。このアーキテクチャモデル１０３では、既存設計の物理的なハードウェア部品を用いているため、検証をおこなう必要はない。【００３５】
また、動作モデル１０４は、概念的に、機能モデル１０２をアーキテクチャモデル１０３にマッピングした結果物である。具体的には、機能モデル１０２のプロセスをアーキテクチャモデル１０３の処理リソースにマッピングし、機能の通信チャンネルは、通信リソースを用いて組み立てる。この動作モデル１０４では、顧客が要求した動作（性能）を満足するかどうかの検証をおこなうことができる。【００３６】
つぎに、動作モデル１０４についてＨＷ／ＳＷ分割をおこない、ハードウェア実装をあらわすＩＣＡ（Ｉｎｔｅｒｆａｃｅ  Ｃｙｃｌｅ  Ａｃｃｕｒａｔｅ）モデル１０５とソフトウェア実装をあらわすソフトウェアモデル１０６とを生成する。【００３７】
ＩＣＡモデル１０５は、モジュール外のインターフェースについてはサイクル精度によって、モジュール内部は動作レベルによって構築したモデルである。このＩＣＡモデル１０５を高位合成することによってＲＴＬ記述１０７を生成する。このＩＣＡモデル１０５では、インターフェースの正確さの検証をおこなうことができる。【００３８】
また、ソフトウェアモデル１０６は、設計対象を含むシステムＬＳＩを構成するソフトウェアのタスク分割をおこない、仮想ＯＳ上に実行するモデルである。このソフトウェアモデル１０６についてコード生成処理をおこなうことによって、実装コード１０８を生成する。このソフトウェアモデル１０６では、ソフトウェアの機能を検証することができる。【００３９】
（各モデルの抽象度）
つぎに、図１に示した各モデルの抽象度について説明する。図２は、図１に示した各モデル１０１〜１０６の抽象度をあらわすグラフである。図２のグラフは、原点を中心とした３軸によって構成されている。各軸は、それぞれ「機能」の抽象度、「構造」の抽象度、「時間」の抽象度をあらわしており、原点から離れるにしたがって抽象度が高くなる。【００４０】
（検証支援装置のハードウェア構成）
つぎに、この発明の実施の形態にかかる検証支援装置のハードウェア構成について説明する。図３は、この発明の実施の形態にかかる検証支援装置のハードウェア構成を示すブロック図である。【００４１】
図３において、検証支援装置は、ＣＰＵ３０１と、ＲＯＭ３０２と、ＲＡＭ３０３と、ＨＤＤ（ハードディスクドライブ）３０４と、ＨＤ（ハードディスク）３０５と、ＦＤＤ（フレキシブルディスクドライブ）３０６と、着脱可能な記録媒体の一例としてのＦＤ（フレキシブルディスク）３０７と、ディスプレイ３０８と、Ｉ／Ｆ（インターフェース）３０９と、キーボード３１０と、マウス３１１と、スキャナ３１２と、プリンタ３１３と、を備えている。また、各構成部はバス３００によってそれぞれ接続されている。【００４２】
ここで、ＣＰＵ３０１は、検証支援装置の全体の制御を司る。ＲＯＭ３０２は、ブートプログラムなどのプログラムを記憶している。ＲＡＭ３０３は、ＣＰＵ３０１のワークエリアとして使用される。ＨＤＤ３０４は、ＣＰＵ３０１の制御にしたがってＨＤ３０５に対するデータのリード／ライトを制御する。ＨＤ３０５は、ＨＤＤ３０４の制御で書き込まれたデータを記憶する。【００４３】
ＦＤＤ３０６は、ＣＰＵ３０１の制御にしたがってＦＤ３０７に対するデータのリード／ライトを制御する。ＦＤ３０７は、ＦＤＤ３０６の制御で書き込まれたデータを記憶したり、ＦＤ３０７に記憶されたデータを検証支援装置に読み取らせたりする。【００４４】
着脱可能な記録媒体として、ＦＤ３０７のほか、ＣＤ−ＲＯＭ（ＣＤ−Ｒ、ＣＤ−ＲＷ）、ＭＯ、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｋ）、メモリーカードなどであってもよい。ディスプレイ３０８は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。このディスプレイ３０８は、たとえば、ＣＲＴ、ＴＦＴ液晶ディスプレイ、プラズマディスプレイなどを採用することができる。【００４５】
Ｉ／Ｆ３０９は、通信回線を通じてインターネットなどのネットワークに接続され、このネットワークを介して他の装置に接続される。そして、Ｉ／Ｆ３０９は、ネットワークと内部のインターフェースを司り、外部装置からのデータの入出力を制御する。Ｉ／Ｆ３０９には、たとえばモデムやＬＡＮアダプタなどを採用することができる。【００４６】
キーボード３１０は、文字、数字、各種指示などの入力のためのキーを備え、データの入力をおこなう。また、タッチパネル式の入力パッドやテンキーなどであってもよい。マウス３１１は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などをおこなう。ポインティングデバイスとして同様に機能を備えるものであれば、トラックボールやジョイスティックなどであってもよい。【００４７】
スキャナ３１２は、画像を光学的に読み取り、検証支援装置内に画像データを取り込む。なお、スキャナ３１２は、ＯＣＲ機能を持たせてもよい。また、プリンタ３１３は、画像データや文書データを印刷する。プリンタ３１３には、たとえば、レーザプリンタやインクジェットプリンタを採用することができる。【００４８】
（検証支援装置の機能的構成）
つぎに、この発明の実施の形態にかかる検証支援装置の機能的構成について説明する。図４は、この発明の実施の形態にかかる検証支援装置の機能的構成を示すブロック図である。【００４９】
図４において、検証支援装置４００は、分析情報入力部４０１と、概念モデル生成部４０２と、機能モデル生成部４０３と、機能モデル検証部４０４と、アーキテクチャ情報記憶部４０５と、アーキテクチャ抽出部４０６と、動作モデル生成部４０７と、動作モデル検証部４０８と、ＩＣＡモデル生成部４０９と、ＩＣＡモデル検証部４１０と、ソフトウェアモデル生成部４１１と、ソフトウェアモデル検証部４１２と、から構成されている。【００５０】
分析情報入力部４０１は、設計対象を含むシステムＬＳＩの顧客からの要求仕様の分析結果を示す情報（分析情報）の入力を受け付ける。ここで、分析情報とは、たとえば、ＵＭＬによって記述された設計対象のユースケース図、シーケンス図、クラス図や、設計対象に要求される基本機能項目など、コンピュータによって読取り可能な情報が挙げられる。【００５１】
また、概念モデル生成部４０２は、分析情報入力部４０１によって入力された分析情報に基づいて、設計対象の基本機能がモデル化され、かつ、設計対象の物理的なアーキテクチャおよび時間の概念が抽象化された概念モデル、すなわち、図１に示した概念モデル１０１を生成する。【００５２】
具体的には、概念モデル生成部４０２は、ユースケース図などの分析情報を解析して、設計対象の実装コードや、設計対象について検証すべき項目（検証項目）、回路シミュレーションによる検証処理手順を示す検証シナリオを生成する。この生成された実装コード、検証項目および検証シナリオが、図１に示した概念モデル１０１となる。【００５３】
また、機能モデル生成部４０３は、分析情報入力部４０１によって入力された分析情報に基づいて、設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性を抽出することによってモデル化された機能モデルを生成する。たとえば、分析情報であるクラス図に基づいて、設計対象の機能をあらわす機能モデルを生成する。【００５４】
具体的には、概念モデル生成部４０２に入力されたクラス図を機能ごとに複数に分割し、分割されたクラス図（分割クラス図）ごとに、実装コードを生成する。この生成された分割クラス図ごとの実装コードが、図１に示した機能モデル１０２となる。【００５５】
機能モデル検証部４０４は、機能モデル生成部４０３によって生成された機能モデルについて、設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性が正当であるかどうかを、概念モデル生成部４０２によって生成された概念モデルに基づいて検証する。【００５６】
具体的には、分割クラス図ごとの実装コードのシミュレーション結果が、概念モデルの実装コードを概念モデルの検証シナリオでシミュレーションしたシミュレーション結果と一致するかどうかを判定することによって、機能モデルの正当性を検証する。ここで、シミュレーション結果とは、ある入力データに対してどのような出力データが得られるか、ということである。【００５７】
より具体的には、分割クラス図ごとの実装コードのシミュレーション結果が一致する場合は、機能モデルが正当となる。一方、不一致の場合は、機能モデルの分割、並行、並列性が正しくないため、機能モデル生成部４０３は、機能モデルの実装コードを修正する。【００５８】
また、アーキテクチャ情報記憶部４０５は、バスやＩＰ（Ｉｎｔｅｌｌｅｃｔｕａｌ  Ｐｒｏｐｅｒｔｙ）などの既存設計の物理的なハードウェア部品に関する情報を記憶する。アーキテクチャ情報記憶部４０５は、具体的には、たとえば、図３に示したＲＯＭ３０２、ＲＡＭ３０３、ＨＤ３０５、ＦＤ３０７などによってその機能を実現する。【００５９】
アーキテクチャ情報抽出部４０６は、アーキテクチャ情報記憶部４０５に記憶されているアーキテクチャ情報を抽出する。処理リソースに関しては、たとえば、ハードウェア処理モジュール、プロセッサ、ＲＴＯＳ、ＤＳＰなどを抽出する。一方、通信リソースに関しては、バス、メモリ、ハードウェアモジュール間の信号線などを抽出する。このアーキテクチャ情報抽出部４０６によって抽出されたアーキテクチャ情報が、図１に示したアーキテクチャモデル１０３に相当する。【００６０】
動作モデル生成部４０７は、アーキテクチャ情報抽出部４０６によって抽出されたアーキテクチャに関する情報を、機能モデル検証部４０４によって正当であることが検証された機能モデルにマッピングすることにより、設計対象の動作をモデル化した動作モデルを生成する。【００６１】
具体的には、機能モデル１０２をアーキテクチャモデル１０３にマッピングすることによって、設計対象の動作モデル１０４を生成する。具体的には、機能モデル１０２のプロセスをアーキテクチャモデル１０３の処理リソースにマッピングし、機能の通信チャンネルは、通信リソースを用いて組み立てる。この組み立てにより、マッピングによって得られたモジュールの処理時間を考慮した実装コードを生成する。この生成された実装コードが、図１に示した動作モデル１０４に相当する。【００６２】
動作モデル検証部４０８は、動作モデル生成部４０７によって生成された動作モデルによりモデル化された設計対象を構成するモジュールの動作タイミングが、正当であるかどうかを検証する。【００６３】
具体的には、動作モデル生成部４０７によって生成された実装コードのシミュレーション結果が、概念モデルの実装コードを概念モデルの検証シナリオでシミュレーションしたシミュレーション結果と一致するかどうかを判定することによって、動作モデルの正当性を検証する。ここで、シミュレーション結果とは、ある入力データに対してどのような出力データが得られるか、ということである。【００６４】
そして、一致する場合は、動作モデルが正当となり、顧客が要求した動作（性能）を満足していることとなる。一方、不一致の場合は、動作モデルが、顧客が要求した動作（性能）を満足していないこととなる。この場合、動作モデル生成部４０７は、動作モデルの実装コードを修正する。【００６５】
ＩＣＡモデル生成部４０９は、動作モデル検証部４０８によって正当であることが検証された場合、機能モデルによってモデル化された設計対象を構成するモジュール間の抽象度が異なる箇所に、当該モジュール間に所定のクロックサイクル精度のインターフェースを挿入することによりＩＣＡモデルを生成する。【００６６】
具体的には、動作モデル１０４についてＨＷ／ＳＷ分割をおこない、ハードウェア実装をあらわすＩＣＡモデル１０５を生成する。たとえば、モジュール間の抽象度が異なる場合に、当該モジュール間の抽象度が同等となるように、クラス図に示された、モジュール間の通信路をインターフェースラッパに置換する。【００６７】
そして、インターフェースラッパに置換されたクラス図の実装コードを生成する。この生成された実装コードが、図１に示したＩＣＡモデル１０５となる。そして、このＩＣＡモデル１０５の実装コードを高位合成することにより、ＲＴＬ記述１０７を生成することができる。【００６８】
ＩＣＡモデル検証部４１０は、ＩＣＡモデル生成部４０９によって生成されたＩＣＡモデル１０５に挿入されたインターフェースのクロックサイクル精度が正当であるかどうかを、概念モデル生成部４０２によって生成された概念モデル１０１に基づいて検証する。【００６９】
具体的には、ＩＣＡモデル生成部４０９によって生成された実装コードのシミュレーション結果が、概念モデルの実装コードを概念モデルの検証シナリオでシミュレーションしたシミュレーション結果と一致するかどうかを判定することによって、機能モデルの正当性を検証する。ここで、シミュレーション結果とは、ある入力データに対してどのような出力データが得られるか、ということである。【００７０】
そして、一致する場合は、ＩＣＡモデルが正当となる。具体的には、置換されたインターフェースラッパによってあらわされるインターフェースが正確であることとなる。一方、不一致の場合は、置換されたインターフェースラッパが不正確となる。この場合、ＩＣＡモデル生成部４０９は、ＩＣＡモデルの実装コードを修正する。【００７１】
ソフトウェアモデル生成部４１１は、動作モデル検証部４０８によって正当であることが検証された場合、機能モデルによってモデル化された設計対象に基づいて、ソフトウェアによって実行可能なタスクを含むようにモデル化されたソフトウェアモデルを生成する。【００７２】
具体的には、動作モデル１０４についてＨＷ／ＳＷ分割をおこない、ソフトウェア実装をあらわすソフトウェアモデル１０６（図１を参照。）を生成する。たとえば、設計対象を含むシステムＬＳＩを構成するソフトウェアのタスク分割をおこない、仮想ＯＳ上に実行可能な実装コードを生成する。【００７３】
ソフトウェアモデル検証部４１２は、ソフトウェアモデル生成部４１１によって生成されたソフトウェアモデルに含まれているタスクが、正当であるかどうかを、概念モデル生成部４０２によって生成された概念モデルに基づいて検証する。【００７４】
具体的には、ソフトウェアモデル生成部４１１によって生成された実装コードのシミュレーション結果が、概念モデルの実装コードを概念モデルの検証シナリオでシミュレーションしたシミュレーション結果と一致するかどうかを判定することによって、ソフトウェアモデル１０６の正当性を検証する。ここで、シミュレーション結果とは、ある入力データに対してどのような出力データが得られるか、ということである。【００７５】
そして、一致する場合は、ソフトウェアモデル１０６の実装コードによってあらわされる機能が正当となる。そして、このソフトウェアモデル１０６の実装コードを取り込んだ、設計対象全体の実装コード１０８（図１を参照。）を生成する。一方、不一致の場合は、ソフトウェアモデル１０６の実装コードによってあらわされる機能が不正確となる。この場合、ソフトウェアモデル生成部４１１は、ソフトウェアモデルの実装コードを修正する。【００７６】
なお、上述した分析情報入力部４０１、概念モデル生成部４０２、機能モデル生成部４０３、機能モデル検証部４０４、アーキテクチャ情報抽出部４０６、動作モデル生成部４０７、動作モデル検証部４０８、ＩＣＡモデル生成部４０９、ＩＣＡモデル検証部４１０、ソフトウェアモデル生成部４１１およびソフトウェアモデル検証部４１２は、具体的には、たとえば、図３に示したＲＯＭ３０２、ＲＡＭ３０３、ＨＤ３０５、ＦＤ３０７などに記録されたプログラムをＣＰＵ３０１が実行することによって、またはＩ／Ｆ３０９によって、その機能を実現する。【００７７】
（検証支援装置の検証支援処理手順）
つぎに、この発明の実施の形態にかかる検証支援装置の検証支援処理手順について説明する。図５は、この発明の実施の形態にかかる検証支援装置の検証支援処理手順を示すフローチャートである。【００７８】
図５において、まず、設計者は、設計対象を含むシステムＬＳＩの顧客からの要求仕様１００を分析して、分析結果をあらわす分析情報を入力する（ステップＳ５０１）。【００７９】
つぎに、入力された分析情報に基づいて、設計対象の実装コードや、設計対象について検証すべき項目（検証項目）、回路シミュレーションによる検証処理手順を示す検証シナリオなどの概念モデル１０１を生成する（ステップＳ５０２）。生成された概念モデル１０１の正当性については、設計者が検証する。【００８０】
つぎに、設計対象の機能デモル１０２を生成する（ステップＳ５０３）。具体的には、概念モデル生成部４０２に入力されたクラス図を機能ごとに複数に分割し、分割されたクラス図（分割クラス図）ごとに、機能モデル１０２の実装コードを生成する。【００８１】
そして、概念モデル１０１の実装コードと機能モデル１０２の実装コードのシミュレーションをおこなう（ステップＳ５０４）。つぎに、概念モデル１０１の実装コードのシミュレーション結果と、機能モデル１０２の実装コードのシミュレーション結果とが、一致するかどうかの判定、すなわち、機能モデル検証をおこなう（ステップＳ５０５）。【００８２】
不一致の場合（ステップＳ５０５：Ｎｏ）、機能モデル１０２を修正する（ステップＳ５０６）。具体的には、たとえば、概念モデル１０１のクラス図を再度、分割しなおして、分割クラス図を生成し、その分割クラス図ごとに実装コードを生成する。そして、ステップＳ５０４に移行する。【００８３】
一方、一致する場合（ステップＳ５０５：Ｙｅｓ）、機能モデル１０２が正当であると判断される。そして、正当性が検証された検証済みの機能モデル１０２に、アーキテクチャモデル１０３をマッピングして、動作モデル１０４を生成する（ステップＳ５０７）。そして、動作モデル１０４の実装コードのシミュレーションをおこなう（ステップＳ５０８）。【００８４】
つぎに、概念モデル１０１の実装コードのシミュレーション結果と、動作モデル１０４の実装コードのシミュレーション結果とが、一致するかどうかの判定、すなわち、動作モデル検証をおこなう（ステップＳ５０９）。【００８５】
不一致の場合（ステップＳ５０９：Ｎｏ）、動作モデル１０４を修正する（ステップＳ５１０）。具体的には、たとえば、アーキテクチャ情報記憶部４０５から再度アーキテクチャ情報を抽出して、正当性が検証された検証済の機能モデル１０２に、あらたなアーキテクチャモデル１０３をマッピングして、動作モデル１０４を生成する。そして、ステップＳ５０８に移行する。【００８６】
一方、一致する場合（ステップＳ５０９：Ｙｅｓ）、動作モデル１０４が正当であると判断される。そして、正当性が検証された検証済の動作モデル１０４に対しＨＷ／ＳＷ分割をおこない、ＩＣＡモデル１０５とソフトウェアモデル１０６を生成する（ステップＳ５１１、ステップＳ５１６）。【００８７】
そして、生成されたＩＣＡモデル１０５の実装コードのシミュレーションをおこなう（ステップＳ５１２）。つぎに、概念モデル１０１の実装コードのシミュレーション結果と、ＩＣＡモデル１０５の実装コードのシミュレーション結果とが、一致するかどうかの判定、すなわち、ＩＣＡモデル検証をおこなう（ステップＳ５１３）。【００８８】
不一致の場合（ステップＳ５１３：Ｎｏ）、ＩＣＡモデル１０５を修正する（ステップＳ５１４）。具体的には、たとえば、インターフェースラッパの内容を変更することによって、ＩＣＡモデル１０５を修正する。そして、ステップＳ５１２に移行する。【００８９】
一方、一致する場合（ステップＳ５１３：Ｙｅｓ）、ＩＣＡモデル１０５が正当であると判断される。そして、高位合成をおこなって（ステップＳ５１５）、ＲＴＬ記述を生成する。【００９０】
また、生成されたソフトウェアモデル１０６の実装コードのシミュレーションをおこなう（ステップＳ５１７）。つぎに、概念モデル１０１の実装コードのシミュレーション結果と、ソフトウェアモデル１０６の実装コードのシミュレーション結果とが、一致するかどうかの判定、すなわち、ソフトウェアモデル検証をおこなう（ステップＳ５１８）。【００９１】
不一致の場合（ステップＳ５１８：Ｎｏ）、ソフトウェアモデル１０６を修正する（ステップＳ５１９）。具体的には、たとえば、設計対象を含むシステムＬＳＩを構成するソフトウェアのタスク分割を再度おこない、仮想ＯＳ上に実行可能な実装コードを生成する。【００９２】
一方、一致する場合（ステップＳ５１８：Ｙｅｓ）、ソフトウェアモデル１０６が正当であると判断される。そして、正当であることが検証された検証済のソフトウェアモデル１０６の実装コードを取り込んだ、設計対象全体の実装コード１０８を生成する（ステップＳ５２０）。【００９３】
この検証処理手順によれば、モデルごとに、段階的に検証をおこなうため、直前までに検証されたモデルについては、検証のやり直しをおこなうことなく、有効なモデルとして活用することができるため、検証処理において手戻りが発生せず、検証処理の効率化を図ることができる。【００９４】
なお、上述した図５のフローチャートでは、ステップＳ５１１〜５１５までの処理手順と、ステップＳ５１６〜５２０までの処理手順とを並列に実行することとしているが、ステップＳ５１１〜５１５までの処理手順のあとに、ステップＳ５１６〜５２０までの処理手順を実行することとしてもよく、また、ステップＳ５１６〜５２０までの処理手順のあとに、ステップＳ５１１〜５１５までの処理手順を実行することとしてもよい。【００９５】
（検証処理の具体例）
つぎに、上述した検証処理の具体例について説明する。【００９６】
（システムＬＳＩのハードウェア構成）
まず、設計対象を含むシステムＬＳＩのハードウェア構成について説明する。図６は、この発明の実施の形態にかかる設計対象を含むシステムＬＳＩのハードウェア構成を示すブロック図である。この設計対象は、たとえば、顧客から設計業務を引き受けた情報であり、ここでは、その設計対象を、シリアル送受信システムとして説明する。【００９７】
図６において、システムＬＳＩ６００は、設計対象の一例として挙げられたシリアル送受信システム６０１と、受信器６０２と、送信器６０３と、ＣＰＵ６０４と、その他デバイス６０５と、これらを接続するバス６０６と、によって構成されている。【００９８】
ここで、受信器６０２は、受信パケット６１１を受信し、シリアル送受信システム６０１に供給する。送信器６０３は、シリアル送受信システム６０１から供給された情報を送信パケット６１２として図示しない外部機器に送信する。シリアル送受信システム６０１は、たとえば、ＢＣＨ（６２，４８）で符号化および復号化をおこなう。【００９９】
そして、受信器６０２からの受信パケット６１１を復号し、この復号したパケット６１３をＣＰＵ６０４に供給する。また、ＣＰＵ６０４からのパケット６１４を符号化する。ＣＰＵ６０４は、シリアル送受信システム６０１からのパケット６１３を用いて、その他デバイス６０５とともにシステムＬＳＩ６００の機能を実行する。【０１００】
（外部装置のインターフェース仕様）
つぎに、外部装置（受信器６０２、送信器６０３、ＣＰＵ６０４、その他デバイス６０５）のインターフェース仕様について説明する。図７および図８は、外部装置のインターフェースであるバスの仕様を示す説明図である。特に、図７は、ライト時のタイミングチャートであり、図８は、リード時のタイミングチャートである。【０１０１】
図７および図８において、「ＰＣＬＫ」は、ビット幅１の入力クロック信号である。「ＰＡＤＤＲ」は、ビット幅３２のアドレス出力信号である。「ＰＷＲＩＴＥ」は、ビット幅１のリード／ライト制御出力信号である。「ＰＳＥＬ」は、ビット幅１のチップセレクト出力信号である。「ＰＥＮＡＢＬＥ」は、ビット幅１の出力イネーブル信号である。「ＰＲＤＡＴＡ」は、ビット幅３２のデータ入出力信号である。ＣＰＵ６０４に対するバスの仕様は、バス標準プロトコルに準拠しており、ＣＰＵ６０４について組み込みプロセッサコアを採用することとしている。【０１０２】
図９は、外部装置のインターフェースである送信器６０３の仕様を示す説明図である。図９において、「ｃｌｋ」は、ビット幅１の入力クロック信号である。「ＩＳＴＡＲＴ」は、ビット幅１のスタートパルス入力信号である。「ＩＤＡＴＡ」は、ビット幅１のデータ入力信号である。シリアル送受信システム６０１から送信器６０３への入力仕様は、スタートパルス入力信号のｉクロックのパルスを検出すると同時に、送信器６０３がクロックのポジティブエッジごとに１ビットずつデータを取り込むという仕様である。また、入力クロック周波数は、１００ＭＨｚとしている。【０１０３】
図１０は、外部装置のインターフェースである受信器６０２の仕様を示す説明図である。図１０において、「ｃｌｋ」は、ビット幅１の出力クロック信号である。「ＯＳＴＡＲＴ」は、ビット幅１のスタートパルス出力信号である。「ＯＤＡＴＡ」は、ビット幅１のデータ出力信号である。【０１０４】
（シリアル送受信システムに要求される基本機能）
つぎに、設計対象であるシリアル送受信システム６０１に要求される基本機能について説明する。シリアル送受信システム６０１に要求される基本機能は、（１）パケットの送信機能と、（２）パケットの受信機能と、（３）初期化機能である。【０１０５】
（１）パケットの送信機能は、以下のとおりである。
（ｉ）ＣＰＵ６０４が作成したパケット６１４をＢＣＨ（６２，４８）で符号化して送信器６０３に転送する転送機能。
（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>を入力する入力ポートである。【０１３３】
このように、分割設計クラス図２２１０〜２２４０の属性を用いて、ポート２３１１〜２３１５、ポート２３２１〜２３２７、ポート２３３１〜２３３３、ポート２３４１〜２３４３どうしを接続して、通信路２３５１〜２３５９を決定する。この通信路２３５１〜２３５９は、具体的にはＦＩＦＯ方式で通信をおこなう通信路である。【０１３４】
また、図２１において、通信路を決定した後、機能モデルの実装コードを生成する（ステップＳ２１０３）。ここで、シリアル送受信システムを含むシステムＬＳＩの機能モデルの実装コードの生成例について説明する。図２４は、シリアル送受信システムを含むシステムＬＳＩの機能モデルの実装コードの生成例を示す説明図である。【０１３５】
図２４では、エンコーダモジュール２３０３に関する分割設計クラス図２２３０から生成した、エンコーダモジュール２３０３の実装コード２４００を示している。なお、図示はしないが、トップモジュールに関する分割設計クラス図２２１０、コントローラモジュール２３０２に関する分割設計クラス図２２２０、およびデコーダモジュール２３０４に関する分割設計クラス図２２４０についても、それぞれ実装コードを生成する。そして、図５のステップＳ５０４では、各分割設計クラス図２２１０〜２２４０の実装コードのシミュレーションを実行することとなる。【０１３６】
このあと、図５のステップＳ５０５において、このシミュレーション結果と、概念モデルの実装コードのシミュレーション結果との一致判定をおこない、一致する場合（ステップＳ５０５：Ｙｅｓ）、図２２に示したモジュール分割が正当であり、また、モジュール分割の並列、並行性が正確であることとなる。【０１３７】
一方、一致しない場合（ステップＳ５０５：Ｎｏ）、図２２に示したモジュール分割が正当でなく、また、モジュール分割の並列、並行性が不正確であるとして、図５のステップＳ５０６において、図２１のステップＳ２１０３で生成された実装コードの修正処理をおこなう。この機能モデル検証により、概念モデルと同一の検証結果になることを確認することができる。【０１３８】
（シリアル送受信システムを含むシステムＬＳＩのアーキテクチャモデル）
つぎに、シリアル送受信システムを含むシステムＬＳＩのアーキテクチャモデルについて説明する。図２５は、シリアル送受信システムを含むシステムＬＳＩのアーキテクチャモデルのクラス図の一例を示す説明図である。アーキテクチャモデルは、バスやＩＰなどの既存設計の物理的なハードウェア部品をあらわすモデルであり、ここでは、バスモデルをあらわしている。【０１３９】
アーキテクチャモデルは、基本的に事前に用意され、検証済みのライブラリとして提供され、図２５では、検証済みのバスモデルが記述されている。このように、このアーキテクチャモデルでは、既存設計の物理的なハードウェア部品を用いているため、検証をおこなう必要はない。【０１４０】
（シリアル送受信システムを含むシステムＬＳＩの動作モデル）
つぎに、シリアル送受信システムを含むシステムＬＳＩの動作モデルについて説明する。動作モデルは、上述したように、概念的に、機能モデルをアーキテクチャモデルにマッピングした結果物である。図２６は、機能モデルとアーキテクチャモデルとのマッピングを示す説明図である。【０１４１】
図２６において、機能モデル２６００は、図２３に示したように、外部から受信したパケットをデコーダ２６０２が入力して復号し、コントローラ２６０３に供給する。コントローラ２６０３は復号されたパケットをエンコーダ２６０４に出力し、エンコーダ２６０４はパケットを符号化する。【０１４２】
アーキテクチャモデル２６１０は、バスやＩＰなどの既存設計の物理的なハードウェア部品をあらわすモデルであり、ここでは、プロセッサ２６１１、メモリ２６１２、外部入力Ｉ／Ｆ２６１３、外部出力Ｉ／Ｆ２６１４、ハードウェア２６１５、ハードウェア２６１６、ハードウェア２６１７、およびこれらを接続するバス２６１８から構成されている。【０１４３】
そして、このアーキテクチャモデル２６１０に、機能モデル２６００をマッピングする。具体的には、デコーダ２６０２をハードウェア２６１５に、コントローラ２６０３をハードウェア２６１６に、エンコーダ２６０４をハードウェア２６１７にマッピングする。この図２５および図２６を用いて説明した内容は、図５のステップＳ５０７に示した処理ステップに相当する内容である。【０１４４】
（シリアル送受信システムを含むシステムＬＳＩの動作モデルの実装コード生成処理手順）
つぎに、シリアル送受信システムを含むシステムＬＳＩの動作モデルの実装コード生成処理手順について説明する。図２７は、シリアル送受信システムを含むシステムＬＳＩの動作モデルの実装コード生成処理手順を示すフローチャートである。この図２７に示す処理手順は、図５のステップＳ５０７に示した処理ステップの詳細な処理手順を示している。【０１４５】
まず、図２６に示したマッピングを実現するため、図２２に示した分割設計クラス図２２１０〜２２４０の属性２２１１〜２２４１内の記述を、図２５に示したバスモデルの記述に置き換える（ステップＳ２７０１）。図２８は、属性２２１１内の記述がバスモデルの記述に置き換えられた分割設計クラス図２２１０を示す説明図である。図２８中、アンダーラインの記述箇所において、通信路が、ＦＩＦＯ方式の記述からバスモデルの記述に置き換えられている。【０１４６】
つぎに、バスモデルの記述に置き換えられた分割設計クラス図２２１０〜２２４０から、機能モデルの実装コードを生成する（ステップＳ２７０２）。そして、生成された機能モデルの実装コードに、各モジュールの見積もり処理時間を追加する（ステップＳ２７０３）。【０１４７】
図２９は、各モジュールの見積もり処理時間の実装コードへの追加例を示す説明図である。たとえば、図２９に示した図表２９００により、デコーダ２６０２およびエンコーダ２６０４の見積もり処理時間を、それぞれ６００［ｎｓ］とすると、機能モデルの実装コード（たとえば、図２４に示した実装コード２４００）に、図表２９００に示した処理時間に関する記述２９０１を追加する。これにより、動作モデルの実装コード２９０２が生成される。そして、図５のステップＳ５０８では、動作モデルの実装コード２９０２のシミュレーションを実行することとなる。【０１４８】
このあと、図５のステップＳ５０８において、このシミュレーション結果と、概念モデルの実装コードのシミュレーション結果との一致判定をおこない、一致する場合（ステップＳ５０９：Ｙｅｓ）、動作モデルの実装コード２９０２のシミュレーション結果が、図１３に示した要求項目リスト１３００のすべての要求項目１３０１〜１３０８を満足することとなり、機能モデルとアーキテクチャモデルとのマッピングが正当であることとなる。【０１４９】
一方、一致しない場合（ステップＳ５０９：Ｎｏ）、動作モデルの実装コード２９０２のシミュレーション結果が、図１３に示した要求項目リスト１３００のすべての要求項目１３０１〜１３０８を満足しておらず、機能モデルとアーキテクチャモデルとのマッピングが正当でないこととなる。この場合、図５のステップＳ５１０において、動作モデルの実装コード２９０２の修正処理をおこなうこととなる。これにより、顧客が要求した動作（性能）を満足するかどうかの検証をおこなうことができる。【０１５０】
（シリアル送受信システムを含むシステムＬＳＩのＩＣＡモデルの実装コード生成処理手順）
つぎに、シリアル送受信システムを含むシステムＬＳＩのＩＣＡモデルの実装コード生成処理手順について説明する。図３０は、シリアル送受信システムを含むシステムＬＳＩのＩＣＡモデルの実装コード生成処理手順を示すフローチャートである。この図３０に示す処理手順は、図５のステップＳ５１１に示した処理ステップの詳細な処理手順を示している。【０１５１】
ＩＣＡモデルは、上述したように、モジュール外のインターフェースについてはサイクル精度によって、モジュール内部は動作レベルによって構築したモデルである。このＩＣＡモデルを高位合成することによってＲＴＬ記述を生成する。このＩＣＡモデルでは、インターフェースの正確さの検証をおこなうことができる。【０１５２】
まず、通信路が決定された機能モデルの構造図から、抽象度の異なるモジュール間を通信する通信路を検出する（ステップＳ３００１）。図３１は、シリアル送受信システムを含むシステムＬＳＩの通信路が決定された機能モデルを示す構造図である。【０１５３】
図３１において、シリアル送受信システムは、図１７に示した設計クラス図を、並行、並列なモジュールに分割された結果（図２１のステップＳ２１０１を参照。）、トップモジュール２３０１と、ＣＰＵモジュール３１０１と、送信器モジュール３１０２と、受信器モジュール３１０３とが、ＦＩＦＯ方式の通信路３１１１〜３１１５によって接続されたシステムである。また、トップモジュール２３０１の内部は、図２３に示した構造図と同一内容である。これらのモジュールの接続関係から、抽象度の異なるモジュール間を通信する通信路を検出する。【０１５４】
つぎに、検出された通信路を、インターフェースラッパに置換する（ステップＳ３００２）。図３２は、図３１に示した構造図内の通信路にインターフェースラッパを挿入した構造図である。図３２では、図３１において、エンコーダモジュール２３０２の抽象度と送信器モジュール３１０２の抽象度が異なっているため、このモジュール２３０２、３１０２間の通信路３１１４をインターフェースラッパ３２０１に挿入し、トップモジュール２３０１の抽象度を変換する。【０１５５】
インターフェースラッパ３２０１は、送信器モジュール３１０２のトランザクションレベルのポート３１０２ａと接続されるトランザクションレベルインターフェース３２０２と、トップモジュール２３０１に接続される２つの信号レベルポート３２０３，３２０４を備えている。このため、トランザクションレベルのポート２３１４を、送信レベルポート３２１０、３２１１に置き換える。【０１５６】
また、トップモジュール２３０１内部のエンコーダモジュール２３０３のトランザクションレベルのポート２３３１〜２３３３も、信号レベルのポート３２１２〜３２１６に置き換える。このポート変換により、コントローラモジュール２３０２のトランザクションレベルのポート２３２４、２３２５も、信号レベルのポート３２１７〜３２１９に変換される。【０１５７】
このように、エンコーダモジュール２３０３のポート数が変更されるため、図３１に示したエンコーダモジュール２３０３をＩＣＡモデルのエンコーダモジュールに変換し（ステップＳ３００３）、エンコーダモジュール２３０３自体の抽象度を変換する。図３３は、ＩＣＡモデルのエンコーダモジュールの内部構造の一例を示す説明図である。【０１５８】
図３３において、ＩＣＡモデルのエンコーダモジュール３３００は、図３１に示したエンコーダモジュール２３０３およびポート２３３１〜２３３３を備えている。そして、ポート２３３１、２３３２と、ポート３２１２〜３２１４との間の通信を可能とするため、各種ラッパやポートが挿入されている。同様に、ポート２３３３と、ポート３２１５、３２１６との間の通信も可能とするため、各種ラッパやポートが挿入されている。【０１５９】
このあと、ＩＣＡモデルのエンコーダモジュール３３００の実装コードを生成する（ステップＳ３００４）。図３４は、ＩＣＡモデルのエンコーダモジュール３３００の実装コードの一例を示す説明図である。そして、図５のステップＳ５１２では、ＩＣＡモデルの実装コード３４００のシミュレーションを実行することとなる。【０１６０】
このあと、図５のステップＳ５１３において、ＩＣＡモデルの実装コード３４００のシミュレーション結果と、概念モデルの実装コードのシミュレーション結果との一致判定をおこない、一致する場合（ステップＳ５１３：Ｙｅｓ）、ＩＣＡモデルの実装コード３４００のシミュレーション結果が、図１３に示した要求項目リスト１３００のすべての要求項目１３０１〜１３０８を満足することとなり、インターフェースラッパの挿入が正当であることとなる。【０１６１】
一方、一致しない場合（ステップＳ５１３：Ｎｏ）、ＩＣＡモデルの実装コード３４００のシミュレーション結果が、図１３に示した要求項目リスト１３００のすべての要求項目１３０１〜１３０８を満足しておらず、インターフェースラッパの挿入が正当でないこととなる。【０１６２】
そして、図５に示したステップＳ５１４において、ＩＣＡモデルの実装コード３４００の修正処理をおこなうこととなる。これにより、インターフェースの正確さの検証をおこなうことができる。【０１６３】
（シリアル送受信システムを含むシステムＬＳＩのソフトウェアモデルの実装コード生成処理手順）
つぎに、シリアル送受信システムを含むシステムＬＳＩのソフトウェアモデルの実装コード生成処理手順について説明する。図３５は、シリアル送受信システムを含むシステムＬＳＩのソフトウェアモデルの実装コード生成処理手順を示すフローチャートである。この図３５に示す処理手順は、図５のステップＳ５１６に示した処理ステップの詳細な処理手順を示している。【０１６４】
ソフトウェアモデルは、上述したように、シリアル送受信システムを含むシステムＬＳＩを構成するソフトウェアのタスク分割をおこない、仮想ＯＳ上に実行するモデルである。図３５において、まず、アーキテクチャモデルに機能モデルの一部をソフトウェアによりマッピングする（ステップＳ３５０１）。【０１６５】
図３６は、アーキテクチャモデルに機能モデルの一部をソフトウェアによりマッピングをおこなった例を示す説明図である。具体的には、図２６に示したように、デコーダ２６０２はハードウェア２６１５にマッピングし、エンコーダ２６０４はハードウェア２６１７にマッピングする。一方、ＣＰＵ２６０１およびコントローラ２６０３は、プロセッサ２６１１にマッピングする。【０１６６】
つぎに、このマッピングにより、ソフトウェアモデルにおける設計クラス図を生成する（ステップＳ３５０２）。図３７は、ソフトウェアモデルにおける設計クラス図を示す説明図である。図３７において、ソフトウェアモデルにおける設計クラス図３７００は、図２２に示した分割設計クラス図２２１０〜２２４０を元にして生成される。【０１６７】
ソフトウェアモデルにおける設計クラス図３７００は、トップモジュールに関する分割設計クラス図３７０１と、デコーダモジュールに関する分割設計クラス図３７０２と、エンコーダモジュールに関する分割設計クラス図３７０３のほかに、仮想ＯＳモデルに関する分割設計クラス図３７０４を含んでいる。そして、設計クラス図３７０１〜３７０４ごとに、ソフトウェアモデルの実装コードを生成する（ステップＳ３５０３）。【０１６８】
このあと、図５のステップＳ５１７において、ソフトウェアモデルの実装コードのシミュレーションを実行することとなる。そして、図５のステップＳ５１８において、ソフトウェアモデルの実装コードのシミュレーション結果と、概念モデルの実装コードのシミュレーション結果との一致判定をおこなう。そして、一致する場合（ステップＳ５１８：Ｙｅｓ）、ソフトウェアモデルの実装コードのシミュレーション結果が、図１３に示した要求項目リスト１３００のすべての要求項目１３０１〜１３０８を満足することとなり、ソフトウェアのタスク分割が正当であることとなる。【０１６９】
一方、一致しない場合（ステップＳ５１８：Ｎｏ）、ソフトウェアモデルの実装コードのシミュレーション結果が、図１３に示した要求項目リスト１３００のすべての要求項目１３０１〜１３０８を満足しておらず、ソフトウェアのタスク分割が正当でないこととなる。【０１７０】
そして、図５に示したステップＳ５１９において、ソフトウェアモデルの実装コードの修正処理をおこなうこととなる。これにより、ソフトウェアのタスク分割の正確さの検証をおこなうことができる。【０１７１】
この発明の実施の形態にかかる検証支援装置および検証支援方法によれば、仕様リスクの早期回避を図ることができる。具体的には、顧客要求をＵＭＬで分析した上で、実行可能なモデルを用いて顧客の機能要求に満足するかどうかを検証することができ、仕様の誤解やミスを早期に発見することができ、誤った仕様に基づくシステムＬＳＩの設計を防止することができる。【０１７２】
また、この発明の実施の形態にかかる検証支援装置および検証支援方法によれば、シミュレーションスピードネックの解決を図ることができる。具体的には、従来の検証手法ではＲＴＬのシミュレータを用いてシミュレーションおこなうため、シミュレーション速度が非常に遅いという問題があったが、この実施の形態では、より抽象度の高いモデルを用いてシミュレーションを実行するため、ＲＴＬのシミュレータに比べて数百倍の速度でシミュレーションを実行することができる。したがって、このシミュレーション速度の向上により、検証作業を含めた設計期間の短縮化を図ることができる。【０１７３】
さらに、この発明の実施の形態にかかる検証支援装置および検証支援方法によれば、コストの削減を図ることができる。具体的には、従来の検証手法では大規模なＬＳＩの場合に高価なエミュレータを導入する必要があったが、この発明の実施の形態では、抽象度の高いモデルの検証によりエミュレータの利用頻度を大幅に減少することができ、コストの削減を図ることができる。また、エミュレータの利用は基本的に時間単位でお金に換算されるケースが多いため、検証時間の短縮化によって費用の低減を図ることができる。【０１７４】
また、この発明の実施の形態にかかる検証支援装置および検証支援方法によれば、早期仕様のミスをなくすことによって検証工程の短縮化を図ることができる。【０１７５】
また、従来手法に対するより効果的な改善点として、従来手法ではＲＴＬが完成されていないと検証工程をおこなうことができなかったが、この発明の実施の形態では、設計の初期の段階から検証を開始することができる。また、設計の詳細度に応じて各モデルに対してその正当性を検証することができる。これにより、従来における設計終了⇒検証スタートという手法に対して、大幅の設計工程の短縮化を図ることができる。【０１７６】
さらに、この発明の実施の形態にかかる検証支援装置および検証支援方法によれば、定量的なアーキテクチャ評価をおこなうことができる。具体的には、従来手法ではＲＴＬのＨＤＬを完成しない限り、性能評価できないという問題点があったが、ＲＴＬのＨＤＬを完成してから性能に満足しないという理由で設計変更をおこなうと、非常に高いコストがかかることとなる。【０１７７】
これに対し、この発明の実施の形態では、早期の段階でＲＴＬによる抽象度の高い動作モデルに対してラフな性能（動作）を見積ることができ、性能（動作）に満足しないというリスクの低減を図ることができる。【０１７８】
また、上述した具体例では、シリアル送受信システムを含むシステムＬＳＩを例に挙げて説明したが、このシステムＬＳＩには限定されることはなく、各種システムＬＳＩに適用することができる。【０１７９】
なお、この実施の形態で説明した検証支援方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション、ＣＡＤ等のコンピュータで実行することにより実現することができる。このプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。またこのプログラムは、インターネット等のネットワークを介して配布することが可能な伝送媒体であってもよい。
【産業上の利用可能性】
【０１８０】
以上のように本発明は、たとえば、ＬＳＩの設計データの検証をおこなうシステムやツールを提供することに適している。
【図１】
2006003702.tif 000002
【図２】
2006003702.tif 000003
【図３】
2006003702.tif 000004
【図４】
2006003702.tif 000005
【図５】
2006003702.tif 000006
【図６】
2006003702.tif 000007
【図７】
2006003702.tif 000008
【図８】
2006003702.tif 000009
【図９】
2006003702.tif 000010
【図１０】
2006003702.tif 000011
【図１１】
2006003702.tif 000012
【図１２】
2006003702.tif 000013
【図１３】
2006003702.tif 000014
【図１４】
2006003702.tif 000015
【図１５】
2006003702.tif 000016
【図１６】
2006003702.tif 000017
【図１７】
2006003702.tif 000018
【図１８】
2006003702.tif 000019
【図１９】
2006003702.tif 000020
【図２０】
2006003702.tif 000021
【図２１】
2006003702.tif 000022
【図２２】
2006003702.tif 000023
【図２３】
2006003702.tif 000024
【図２４】
2006003702.tif 000025
【図２５】
2006003702.tif 000026
【図２６】
2006003702.tif 000027
【図２７】
2006003702.tif 000028
【図２８】
2006003702.tif 000029
【図２９】
2006003702.tif 000030
【図３０】
2006003702.tif 000031
【図３１】
2006003702.tif 000032
【図３２】
2006003702.tif 000033
【図３３】
2006003702.tif 000034
【図３４】
2006003702.tif 000035
【図３５】
2006003702.tif 000036
【図３６】
2006003702.tif 000037
【図３７】
2006003702.tif 000038
【図３８】
2006003702.tif 000039
【手続補正書】
【提出日】平成19年1月31日(2007.1.31)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ＬＳＩの設計対象に関する要求仕様の分析結果を示す分析情報の入力を受け付ける分析情報入力手段と、
前記分析情報入力手段によって入力された分析情報に基づいて、前記設計対象の基本機能がモデル化され、かつ、前記設計対象の物理的なアーキテクチャおよび時間の概念が抽象化された概念モデルを生成する概念モデル生成手段と、
前記分析情報入力手段によって入力された分析情報に基づいて、前記設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性を抽出することによってモデル化された機能モデルを生成する機能モデル生成手段と、
前記機能モデル生成手段によって生成された機能モデルについて、前記設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性が正当であるかどうかを、前記概念モデル生成手段によって生成された概念モデルに基づいて検証する機能モデル検証手段と、
を備えることを特徴とする検証支援装置。
【請求項２】
複数種類の物理的なアーキテクチャに関する情報を記憶する記憶手段と、
前記機能モデル検証手段によって正当であることが検証された場合、前記記憶手段から任意のアーキテクチャに関する情報を抽出する抽出手段と、
前記抽出手段によって抽出されたアーキテクチャに関する情報を、前記機能モデル検証手段によって正当であることが検証された機能モデルにマッピングすることにより、前記設計対象の動作をモデル化した動作モデルを生成する動作モデル生成手段と、
前記動作モデル生成手段によって生成された動作モデルによりモデル化された設計対象を構成するモジュールの動作タイミングが、正当であるかどうかを検証する動作モデル検証手段と、
を備えることを特徴とする請求項１に記載の検証支援装置。
【請求項３】
前記動作モデル検証手段によって正当であることが検証された場合、前記機能モデルによってモデル化された設計対象を構成するモジュール間の抽象度が異なる箇所に、当該モジュール間に所定のクロックサイクル精度のインターフェースを挿入することによりＩＣＡモデルを生成するＩＣＡモデル生成手段と、
前記ＩＣＡモデル生成手段によって生成されたＩＣＡモデルに挿入されたインターフェースのクロックサイクル精度が正当であるかどうかを、前記概念モデル生成手段によって生成された概念モデルに基づいて検証するＩＣＡモデル検証手段と、
を備えることを特徴とする請求項２に記載の検証支援装置。
【請求項４】
前記動作モデル検証手段によって正当であることが検証された場合、前記機能モデルによってモデル化された設計対象に基づいて、ソフトウェアによって実行可能なタスクを含むようにモデル化されたソフトウェアモデルを生成するソフトウェアモデル生成手段と、
前記ソフトウェアモデル生成手段によって生成されたソフトウェアモデルに含まれているタスクが正当であるかどうかを、前記概念モデル生成手段によって生成された概念モデルに基づいて検証するソフトウェアモデル検証手段と、
を備えることを特徴とする請求項２または３に記載の検証支援装置。
【請求項５】
ＬＳＩの設計対象に関する要求仕様の分析結果を示す分析情報を入力する分析情報入力工程と、
前記分析情報入力工程によって入力された分析情報に基づいて、前記設計対象の基本機能がモデル化され、かつ、前記設計対象の物理的なアーキテクチャおよび時間の概念が抽象化された概念モデルを生成する概念モデル生成工程と、
前記分析情報入力工程によって入力された分析情報に基づいて、前記設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性を抽出することによってモデル化された機能モデルを生成する機能モデル生成工程と、
前記機能モデル生成工程によって生成された機能モデルについて、前記設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性が正当であるかどうかを、前記概念モデル生成工程によって生成された概念モデルに基づいて検証する機能モデル検証工程と、
を含んだことを特徴とする検証支援方法。
【請求項６】
前記機能モデル検証工程によって正当であることが検証された場合、複数種類の物理的なアーキテクチャに関する情報の中から、任意のアーキテクチャに関する情報を抽出する抽出工程と、
前記抽出工程によって抽出されたアーキテクチャに関する情報を、前記機能モデル検証工程によって正当であることが検証された機能モデルにマッピングすることにより、前記設計対象の動作をモデル化した動作モデルを生成する動作モデル生成工程と、
前記動作モデル生成工程によって生成された動作モデルによりモデル化された設計対象を構成するモジュールの動作タイミングが、正当であるかどうかを検証する動作モデル検証工程と、
を含んだことを特徴とする請求項５に記載の検証支援方法。
【請求項７】
前記動作モデル検証工程によって正当であることが検証された場合、前記機能モデルによってモデル化された設計対象を構成するモジュール間の抽象度が異なる箇所に、当該モジュール間に所定のクロックサイクル精度のインターフェースを挿入することによりＩＣＡモデルを生成するＩＣＡモデル生成工程と、
前記ＩＣＡモデル生成工程によって生成されたＩＣＡモデルに挿入されたインターフェースのクロックサイクル精度が正当であるかどうかを、前記概念モデル生成工程によって生成された概念モデルに基づいて検証するＩＣＡモデル検証工程と、
を含んだことを特徴とする請求項６に記載の検証支援方法。
【請求項８】
ＬＳＩの設計対象に関する要求仕様の分析結果を示す分析情報を入力させる分析情報入力工程と、
前記分析情報入力工程によって入力された分析情報に基づいて、前記設計対象の基本機能がモデル化され、かつ、前記設計対象の物理的なアーキテクチャおよび時間の概念が抽象化された概念モデルを生成させる概念モデル生成工程と、
前記分析情報入力工程によって入力された分析情報に基づいて、前記設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性を抽出することによってモデル化された機能モデルを生成させる機能モデル生成工程と、
前記機能モデル生成工程によって生成された機能モデルについて、前記設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性が正当であるかどうかを、前記概念モデル生成工程によって生成された概念モデルに基づいて検証させる機能モデル検証工程と、
をコンピュータに実行させることを特徴とする検証支援プログラム。
【請求項９】
前記機能モデル検証工程によって正当であることが検証された場合、複数種類の物理的なアーキテクチャに関する情報の中から、任意のアーキテクチャに関する情報を抽出させる抽出工程と、
前記抽出工程によって抽出されたアーキテクチャに関する情報を、前記機能モデル検証工程によって正当であることが検証された機能モデルにマッピングすることにより、前記設計対象の動作をモデル化した動作モデルを生成させる動作モデル生成工程と、
前記動作モデル生成工程によって生成された動作モデルによりモデル化された設計対象を構成するモジュールの動作タイミングが、正当であるかどうかを検証させる動作モデル検証工程と、
を含んだことを特徴とする請求項８に記載の検証支援プログラム。
【請求項１０】
前記動作モデル検証工程によって正当であることが検証された場合、前記機能モデルによってモデル化された設計対象を構成するモジュール間の抽象度が異なる箇所に、当該モジュール間に所定のクロックサイクル精度のインターフェースを挿入することによりＩＣＡモデルを生成させるＩＣＡモデル生成工程と、
前記ＩＣＡモデル生成工程によって生成されたＩＣＡモデルに挿入されたインターフェースのクロックサイクル精度が正当であるかどうかを、前記概念モデル生成工程によって生成された概念モデルに基づいて検証させるＩＣＡモデル検証工程と、
を含んだことを特徴とする請求項９に記載の検証支援プログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＬＳＩの検証を支援する検証支援装置、検証支援方法、検証支援プログラムおよび記録媒体に関する。
【背景技術】
【０００２】
ＬＳＩ設計では、ＬＳＩが正常に動作するか否かを検証する検証作業が必要不可欠であり、特に、大規模化、高機能化、高速化および低消費電力化が要求されているＬＳＩについては、高品質を維持するためにもこの検証作業は重要である一方、従来から設計期間の短縮による作業効率化が要求されている。
【０００３】
特に、近年は、ソフトウェアとハードウェアが混在しており、従来型のＡＳＩＣによる単機能のハードウェアだけではなく、ソフトウェアも含めたシステム・オン・チップ（ＳｏＣ）が主流となっている。また、ＭＰＥＧやＪＰＥＧなど、本来アプリケーションソフトウェアで実現される機能がハードウェアで実現するようになっているため、ＬＳＩの機能が複雑化している。
【０００４】
ここで、従来のＬＳＩの開発処理について説明する。図３８は、従来のＬＳＩの開発処理手順を示すフローチャートである。図３８において、ステップＳ３８０１〜ステップＳ３８０５が、ＬＳＩの設計をおこなう設計フローであり、ステップＳ３８０６〜ステップＳ３８０９が、設計されたＬＳＩの検証をおこなう検証フローである。
【０００５】
まず、設計フローでは、ステップＳ３８０１において、概念設計をおこなう。概念設計では、顧客からの設計要求に基づいて設計者が要求仕様書３８１０を自然言語によって作成する。または、顧客から自然言語で記述された要求仕様書３８１０を受け取る。
【０００６】
つぎに、ステップＳ３８０２において、機能設計をおこなう。機能設計では、要求仕様書３８１０に記述された内容から、設計対象となるＬＳＩを機能ブロックごとに分けて、各機能ブロックの内容を記述した機能仕様書３８２０を作成する。
【０００７】
つぎに、ステップＳ３８０３において、構造設計をおこなう。構造設計では、機能仕様書３８２０からハードウェア設計をおこなって構造仕様書３８３０を作成する。具体的には、どのようなアーキテクチャを導入すれば機能仕様書３８２０に記述された機能を実現できるか、という設計をおこなうことである。
【０００８】
たとえば、各機能ブロックのうち、ある機能ブロックのアーキテクチャについてはソフトウェアによって実現し、ある機能ブロックのアーキテクチャについてはＩＰ（Ｉｎｔｅｌｌｅｃｔｕａｌ  Ｐｒｏｐｅｒｔｙ）を購入して実現し、ある機能ブロックのアーキテクチャについては設計者が作成し、ある機能ブロックのアーキテクチャについては、アンダーバスによって実現するということである。
【０００９】
つぎに、ステップＳ３８０４において、ユニット設計をおこなう。ユニット設計では、構造仕様書３８３０に記述された各ハードウェアモジュールを複数のモジュールに分割して詳細に設計することによってユニット仕様書３８４０を作成する。
【００１０】
つぎに、ステップＳ３８０５において、実装をおこなう。実装では、インターフェースのタイミングチャートを用い、また、内部ロジックを考慮することにより、最終的な設計対象となるＲＴＬ（Ｒｅｇｉｓｔｅｒ  Ｔｒａｎｓｆｅｒ  Ｌｅｖｅｌ）３８５０のＨＤＬ（Ｈａｒｄｗａｒｅ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ）を用いて実装をおこなう。
【００１１】
つぎに、ステップＳ３８０６において、ユニット検証をおこなう。ユニット検証では、ユニット検証項目３８６０にしたがって、ユニット設計によって設計されたユニットごとのユニット仕様書３８４０の検証、すなわち、デバッグをおこなう。
【００１２】
つぎに、ステップＳ３８０７において、結合検証をおこなう。結合検証では、結合検証項目３８７０にしたがって、ユニット検証によって検証された各ユニットのインターフェースを結合して、正常に動作するかを検証する。
【００１３】
つぎに、ステップＳ３８０８において、機能検証をおこなう。機能検証では、機能検証項目３８８０にしたがって、設計対象となるシステムの機能要求を満たすかどうかを検証する。
【００１４】
最後に、ステップＳ３８０９において、実機検証をおこなう。実機検証では、ＲＴＬ３８５０を用いて実際にチップ上にＬＳＩを実装して、実際に動作するかどうかを検証する。顧客からの要求仕様書３８１０が、要求検証項目３８９０を満足しているかどうかを判断する。
【発明の開示】
【発明が解決しようとする課題】
【００１５】
しかしながら、上述した設計処理では、実装（ステップＳ３８０５）しなければ、ＬＳＩの検証（ステップＳ３８０６〜Ｓ３８０９）をおこなうことができなかった。
【００１６】
これにより、設計フローの上流のいずれかのステップにおいて仕様書の誤り、記述の曖昧さ、設計者の誤解釈のためにミスが生じると、そのステップ以降のステップにおいてミスが累積されてしまうという問題があった。
【００１７】
また、構造設計においては、机上でアーキテクチャを決定しており、その妥当性を確かめる手法が存在していなかった。したがって、開発リスクの増大によって開発プロジェクトの破綻も生じ、開発時間および開発労力が無駄になるという問題があった。
【００１８】
また、ＲＴＬ３８５０のＨＤＬに対してシミュレーションをおこなうために特別なシミュレータ(ＶＣＳ、ＮＣ−ＳｉｍなどのＥＤＡベンダーのツール)が必要であるが、シミュレーションスピードが遅いために検証効率が低下し、設計期間の長期化を招くという問題があった。特に、設計対象が大規模な場合、シミュレーションスピードがネックとなって、所定の期間内に検証作業を収束させることができない場合があった。
【００１９】
一方、シミュレータより何千倍のスピードで動くエミュレータを導入してシミュレーションの速度の向上を図ることも考えられるが、エミュレータが非常に高価であり、検証費用が増大するとともに、環境の構築が困難な上に問題発生時にデバッグが難しいために結果的に検証期間が増加して、設計期間の長期化を招くという問題があった。
【００２０】
本発明は、上記問題点に鑑みてなされたものであって、ＬＳＩの設計精度の向上および検証期間の短縮化を、容易かつ効率的に実現することができる検証支援装置、検証支援方法、検証支援プログラムおよび該プログラムを記録した記録媒体を提供することを目的とする。
【課題を解決するための手段】
【００２１】
上述した課題を解決し、目的を達成するため、本発明の検証支援装置、検証支援方法、および検証支援プログラムは、ＬＳＩの設計対象に関する要求仕様の分析結果を示す分析情報を入力し、入力された分析情報に基づいて、前記設計対象の基本機能がモデル化され、かつ、前記設計対象の物理的なアーキテクチャおよび時間の概念が抽象化された概念モデルを生成し、入力された分析情報に基づいて、前記設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性を抽出することによってモデル化された機能モデルを生成し、生成された機能モデルについて、前記設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性が正当であるかどうかを、生成された概念モデルに基づいて検証することを特徴とする。
【００２２】
また、上記発明は、前記機能モデルが正当であることが検証された場合、複数種類の物理的なアーキテクチャに関する情報から任意のアーキテクチャに関する情報を抽出し、抽出されたアーキテクチャに関する情報を、正当であることが検証された機能モデルにマッピングすることにより、前記設計対象の動作をモデル化した動作モデルを生成し、生成された動作モデルによりモデル化された設計対象を構成するモジュールの動作タイミングが、正当であるかどうかを検証することを特徴とする。
【００２３】
さらに、上記発明は、前記動作モデルが正当であることが検証された場合、前記機能モデルによってモデル化された設計対象を構成するモジュール間の抽象度が異なる箇所に、当該モジュール間に所定のクロックサイクル精度のインターフェースを挿入することによりＩＣＡモデルを生成し、生成されたＩＣＡモデルに挿入されたインターフェースのクロックサイクル精度が正当であるかどうかを、生成された概念モデルに基づいて検証することを特徴とする。
【００２４】
また、前記動作モデルが正当であることが検証された場合、前記機能モデルによってモデル化された設計対象に基づいて、ソフトウェアによって実行可能なタスクを含むようにモデル化されたソフトウェアモデルを生成し、生成されたソフトウェアモデルに含まれているタスクが正当であるかどうかを、生成された概念モデルに基づいて検証することを特徴とする。
【発明の効果】
【００２５】
この発明の検証支援装置、検証支援方法、および検証支援プログラムによれば、段階的に検証を導入することによって、これまで、ＲＴＬを生成しないと発見できなかった問題を、設計の早期段階に摘出してそのリスクを回避することができる。したがって、ＬＳＩの設計精度の向上および検証期間の短縮化を、容易かつ効率的に実現することができるという効果を奏する。
【発明を実施するための最良の形態】
【００２６】
（実施の形態）
以下に、本発明の実施の形態にかかる検証支援装置、検証支援方法、検証支援プログラムおよび該プログラムを記録した記録媒体について図面を参照しつつ詳細に説明する。
【００２７】
（検証支援の概念）
まず、この発明の実施の形態にかかる検証支援の概念について説明する。図１は、この発明の実施の形態にかかる検証支援の概念図である。
【００２８】
図１において、設計者は、設計対象を含むシステムＬＳＩの顧客からの要求仕様１００について、ＵＭＬ（Ｕｎｉｆｉｅｄ  Ｍｏｄｅｌｉｎｇ  Ｌａｎｇｕａｇｅ）を用いてオブジェクト指向分析をおこない、その分析結果を概念モデル１０１としてモデリングする。概念モデル１０１とは、設計対象の概念的な分析結果をあらわすモデルである。概念モデル１０１は、完全に実装依存しないモデルであり、具体的には、物理的なアーキテクチャや時間の概念が抽象化され、設計対象の基本機能を中心にモデリングされたものである。
【００２９】
概念モデル１０１は、具体的には、システムＬＳＩの要求仕様の分析結果を、ＵＭＬやＣ＋＋でモデリングした結果物であり、ＵＭＬモデル、Ｃ＋＋モデル、および検証シナリオのすべてを含めた総称である。この概念モデル１０１では、要求仕様１００の誤解やミス、またはアルゴリズムの検証をおこなうことができる。
【００３０】
また、機能モデル１０２は、概念モデル１０１から、設計対象であるシステムＬＳＩを構成するモジュールの分割、分割されたモジュールの並行または並列性を抽出することによって構築されたモデルである。機能モデル１０２は、時間の概念が存在しない。この機能モデルでは、モジュール分割の正当性や、並列、並行性の正確さを検証することができる。
【００３１】
また、アーキテクチャモデル１０３は、バスやＩＰ（Ｉｎｔｅｌｌｅｃｔｕａｌ  Ｐｒｏｐｅｒｔｙ）などの既存設計の物理的なハードウェア部品をあらわすモデルである。アーキテクチャモデル１０３は、具体的には、処理リソースと、通信リソースとに大別される。処理リソースは、機能モデル１０２のモジュールをマッピングするためのモデルである。たとえば、ハードウェア処理モジュール、プロセッサ、ＲＴＯＳ、ＤＳＰなどが挙げられる。
【００３２】
一方、通信リソースは、機能モデルのモジュール間の通信を実現するためのチャンネルをモデリングしたモデルである。たとえば、バス、メモリ、ハードウェアモジュール間の信号線などが挙げられる。このアーキテクチャモデル１０３では、既存設計の物理的なハードウェア部品を用いているため、検証をおこなう必要はない。
【００３３】
また、動作モデル１０４は、概念的に、機能モデル１０２をアーキテクチャモデル１０３にマッピングした結果物である。具体的には、機能モデル１０２のプロセスをアーキテクチャモデル１０３の処理リソースにマッピングし、機能の通信チャンネルは、通信リソースを用いて組み立てる。この動作モデル１０４では、顧客が要求した動作（性能）を満足するかどうかの検証をおこなうことができる。
【００３４】
つぎに、動作モデル１０４についてＨＷ／ＳＷ分割をおこない、ハードウェア実装をあらわすＩＣＡ（Ｉｎｔｅｒｆａｃｅ  Ｃｙｃｌｅ  Ａｃｃｕｒａｔｅ）モデル１０５とソフトウェア実装をあらわすソフトウェアモデル１０６とを生成する。
【００３５】
ＩＣＡモデル１０５は、モジュール外のインターフェースについてはサイクル精度によって、モジュール内部は動作レベルによって構築したモデルである。このＩＣＡモデル１０５を高位合成することによってＲＴＬ記述１０７を生成する。このＩＣＡモデル１０５では、インターフェースの正確さの検証をおこなうことができる。
【００３６】
また、ソフトウェアモデル１０６は、設計対象を含むシステムＬＳＩを構成するソフトウェアのタスク分割をおこない、仮想ＯＳ上に実行するモデルである。このソフトウェアモデル１０６についてコード生成処理をおこなうことによって、実装コード１０８を生成する。このソフトウェアモデル１０６では、ソフトウェアの機能を検証することができる。
【００３７】
（各モデルの抽象度）
つぎに、図１に示した各モデルの抽象度について説明する。図２は、図１に示した各モデル１０１〜１０６の抽象度をあらわすグラフである。図２のグラフは、原点を中心とした３軸によって構成されている。各軸は、それぞれ「機能」の抽象度、「構造」の抽象度、「時間」の抽象度をあらわしており、原点から離れるにしたがって抽象度が高くなる。
【００３８】
（検証支援装置のハードウェア構成）
つぎに、この発明の実施の形態にかかる検証支援装置のハードウェア構成について説明する。図３は、この発明の実施の形態にかかる検証支援装置のハードウェア構成を示すブロック図である。
【００３９】
図３において、検証支援装置は、ＣＰＵ３０１と、ＲＯＭ３０２と、ＲＡＭ３０３と、ＨＤＤ（ハードディスクドライブ）３０４と、ＨＤ（ハードディスク）３０５と、ＦＤＤ（フレキシブルディスクドライブ）３０６と、着脱可能な記録媒体の一例としてのＦＤ（フレキシブルディスク）３０７と、ディスプレイ３０８と、Ｉ／Ｆ（インターフェース）３０９と、キーボード３１０と、マウス３１１と、スキャナ３１２と、プリンタ３１３と、を備えている。また、各構成部はバス３００によってそれぞれ接続されている。
【００４０】
ここで、ＣＰＵ３０１は、検証支援装置の全体の制御を司る。ＲＯＭ３０２は、ブートプログラムなどのプログラムを記憶している。ＲＡＭ３０３は、ＣＰＵ３０１のワークエリアとして使用される。ＨＤＤ３０４は、ＣＰＵ３０１の制御にしたがってＨＤ３０５に対するデータのリード／ライトを制御する。ＨＤ３０５は、ＨＤＤ３０４の制御で書き込まれたデータを記憶する。
【００４１】
ＦＤＤ３０６は、ＣＰＵ３０１の制御にしたがってＦＤ３０７に対するデータのリード／ライトを制御する。ＦＤ３０７は、ＦＤＤ３０６の制御で書き込まれたデータを記憶したり、ＦＤ３０７に記憶されたデータを検証支援装置に読み取らせたりする。
【００４２】
着脱可能な記録媒体として、ＦＤ３０７のほか、ＣＤ−ＲＯＭ（ＣＤ−Ｒ、ＣＤ−ＲＷ）、ＭＯ、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｋ）、メモリーカードなどであってもよい。ディスプレイ３０８は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。このディスプレイ３０８は、たとえば、ＣＲＴ、ＴＦＴ液晶ディスプレイ、プラズマディスプレイなどを採用することができる。
【００４３】
Ｉ／Ｆ３０９は、通信回線を通じてインターネットなどのネットワークに接続され、このネットワークを介して他の装置に接続される。そして、Ｉ／Ｆ３０９は、ネットワークと内部のインターフェースを司り、外部装置からのデータの入出力を制御する。Ｉ／Ｆ３０９には、たとえばモデムやＬＡＮアダプタなどを採用することができる。
【００４４】
キーボード３１０は、文字、数字、各種指示などの入力のためのキーを備え、データの入力をおこなう。また、タッチパネル式の入力パッドやテンキーなどであってもよい。マウス３１１は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などをおこなう。ポインティングデバイスとして同様に機能を備えるものであれば、トラックボールやジョイスティックなどであってもよい。
【００４５】
スキャナ３１２は、画像を光学的に読み取り、検証支援装置内に画像データを取り込む。なお、スキャナ３１２は、ＯＣＲ機能を持たせてもよい。また、プリンタ３１３は、画像データや文書データを印刷する。プリンタ３１３には、たとえば、レーザプリンタやインクジェットプリンタを採用することができる。
【００４６】
（検証支援装置の機能的構成）
つぎに、この発明の実施の形態にかかる検証支援装置の機能的構成について説明する。図４は、この発明の実施の形態にかかる検証支援装置の機能的構成を示すブロック図である。
【００４７】
図４において、検証支援装置４００は、分析情報入力部４０１と、概念モデル生成部４０２と、機能モデル生成部４０３と、機能モデル検証部４０４と、アーキテクチャ情報記憶部４０５と、アーキテクチャ抽出部４０６と、動作モデル生成部４０７と、動作モデル検証部４０８と、ＩＣＡモデル生成部４０９と、ＩＣＡモデル検証部４１０と、ソフトウェアモデル生成部４１１と、ソフトウェアモデル検証部４１２と、から構成されている。
【００４８】
分析情報入力部４０１は、設計対象を含むシステムＬＳＩの顧客からの要求仕様の分析結果を示す情報（分析情報）の入力を受け付ける。ここで、分析情報とは、たとえば、ＵＭＬによって記述された設計対象のユースケース図、シーケンス図、クラス図や、設計対象に要求される基本機能項目など、コンピュータによって読取り可能な情報が挙げられる。
【００４９】
また、概念モデル生成部４０２は、分析情報入力部４０１によって入力された分析情報に基づいて、設計対象の基本機能がモデル化され、かつ、設計対象の物理的なアーキテクチャおよび時間の概念が抽象化された概念モデル、すなわち、図１に示した概念モデル１０１を生成する。
【００５０】
具体的には、概念モデル生成部４０２は、ユースケース図などの分析情報を解析して、設計対象の実装コードや、設計対象について検証すべき項目（検証項目）、回路シミュレーションによる検証処理手順を示す検証シナリオを生成する。この生成された実装コード、検証項目および検証シナリオが、図１に示した概念モデル１０１となる。
【００５１】
また、機能モデル生成部４０３は、分析情報入力部４０１によって入力された分析情報に基づいて、設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性を抽出することによってモデル化された機能モデルを生成する。たとえば、分析情報であるクラス図に基づいて、設計対象の機能をあらわす機能モデルを生成する。
【００５２】
具体的には、概念モデル生成部４０２に入力されたクラス図を機能ごとに複数に分割し、分割されたクラス図（分割クラス図）ごとに、実装コードを生成する。この生成された分割クラス図ごとの実装コードが、図１に示した機能モデル１０２となる。
【００５３】
機能モデル検証部４０４は、機能モデル生成部４０３によって生成された機能モデルについて、設計対象を構成するモジュールの分割、および分割されたモジュールの並行または並列性が正当であるかどうかを、概念モデル生成部４０２によって生成された概念モデルに基づいて検証する。
【００５４】
具体的には、分割クラス図ごとの実装コードのシミュレーション結果が、概念モデルの実装コードを概念モデルの検証シナリオでシミュレーションしたシミュレーション結果と一致するかどうかを判定することによって、機能モデルの正当性を検証する。ここで、シミュレーション結果とは、ある入力データに対してどのような出力データが得られるか、ということである。
【００５５】
より具体的には、分割クラス図ごとの実装コードのシミュレーション結果が一致する場合は、機能モデルが正当となる。一方、不一致の場合は、機能モデルの分割、並行、並列性が正しくないため、機能モデル生成部４０３は、機能モデルの実装コードを修正する。
【００５６】
また、アーキテクチャ情報記憶部４０５は、バスやＩＰ（Ｉｎｔｅｌｌｅｃｔｕａｌ  Ｐｒｏｐｅｒｔｙ）などの既存設計の物理的なハードウェア部品に関する情報を記憶する。アーキテクチャ情報記憶部４０５は、具体的には、たとえば、図３に示したＲＯＭ３０２、ＲＡＭ３０３、ＨＤ３０５、ＦＤ３０７などによってその機能を実現する。
【００５７】
アーキテクチャ情報抽出部４０６は、アーキテクチャ情報記憶部４０５に記憶されているアーキテクチャ情報を抽出する。処理リソースに関しては、たとえば、ハードウェア処理モジュール、プロセッサ、ＲＴＯＳ、ＤＳＰなどを抽出する。一方、通信リソースに関しては、バス、メモリ、ハードウェアモジュール間の信号線などを抽出する。このアーキテクチャ情報抽出部４０６によって抽出されたアーキテクチャ情報が、図１に示したアーキテクチャモデル１０３に相当する。
【００５８】
動作モデル生成部４０７は、アーキテクチャ情報抽出部４０６によって抽出されたアーキテクチャに関する情報を、機能モデル検証部４０４によって正当であることが検証された機能モデルにマッピングすることにより、設計対象の動作をモデル化した動作モデルを生成する。
【００５９】
具体的には、機能モデル１０２をアーキテクチャモデル１０３にマッピングすることによって、設計対象の動作モデル１０４を生成する。具体的には、機能モデル１０２のプロセスをアーキテクチャモデル１０３の処理リソースにマッピングし、機能の通信チャンネルは、通信リソースを用いて組み立てる。この組み立てにより、マッピングによって得られたモジュールの処理時間を考慮した実装コードを生成する。この生成された実装コードが、図１に示した動作モデル１０４に相当する。
【００６０】
動作モデル検証部４０８は、動作モデル生成部４０７によって生成された動作モデルによりモデル化された設計対象を構成するモジュールの動作タイミングが、正当であるかどうかを検証する。
【００６１】
具体的には、動作モデル生成部４０７によって生成された実装コードのシミュレーション結果が、概念モデルの実装コードを概念モデルの検証シナリオでシミュレーションしたシミュレーション結果と一致するかどうかを判定することによって、動作モデルの正当性を検証する。ここで、シミュレーション結果とは、ある入力データに対してどのような出力データが得られるか、ということである。
【００６２】
そして、一致する場合は、動作モデルが正当となり、顧客が要求した動作（性能）を満足していることとなる。一方、不一致の場合は、動作モデルが、顧客が要求した動作（性能）を満足していないこととなる。この場合、動作モデル生成部４０７は、動作モデルの実装コードを修正する。
【００６３】
ＩＣＡモデル生成部４０９は、動作モデル検証部４０８によって正当であることが検証された場合、機能モデルによってモデル化された設計対象を構成するモジュール間の抽象度が異なる箇所に、当該モジュール間に所定のクロックサイクル精度のインターフェースを挿入することによりＩＣＡモデルを生成する。
【００６４】
具体的には、動作モデル１０４についてＨＷ／ＳＷ分割をおこない、ハードウェア実装をあらわすＩＣＡモデル１０５を生成する。たとえば、モジュール間の抽象度が異なる場合に、当該モジュール間の抽象度が同等となるように、クラス図に示された、モジュール間の通信路をインターフェースラッパに置換する。
【００６５】
そして、インターフェースラッパに置換されたクラス図の実装コードを生成する。この生成された実装コードが、図１に示したＩＣＡモデル１０５となる。そして、このＩＣＡモデル１０５の実装コードを高位合成することにより、ＲＴＬ記述１０７を生成することができる。
【００６６】
ＩＣＡモデル検証部４１０は、ＩＣＡモデル生成部４０９によって生成されたＩＣＡモデル１０５に挿入されたインターフェースのクロックサイクル精度が正当であるかどうかを、概念モデル生成部４０２によって生成された概念モデル１０１に基づいて検証する。
【００６７】
具体的には、ＩＣＡモデル生成部４０９によって生成された実装コードのシミュレーション結果が、概念モデルの実装コードを概念モデルの検証シナリオでシミュレーションしたシミュレーション結果と一致するかどうかを判定することによって、機能モデルの正当性を検証する。ここで、シミュレーション結果とは、ある入力データに対してどのような出力データが得られるか、ということである。
【００６８】
そして、一致する場合は、ＩＣＡモデルが正当となる。具体的には、置換されたインターフェースラッパによってあらわされるインターフェースが正確であることとなる。一方、不一致の場合は、置換されたインターフェースラッパが不正確となる。この場合、ＩＣＡモデル生成部４０９は、ＩＣＡモデルの実装コードを修正する。
【００６９】
ソフトウェアモデル生成部４１１は、動作モデル検証部４０８によって正当であることが検証された場合、機能モデルによってモデル化された設計対象に基づいて、ソフトウェアによって実行可能なタスクを含むようにモデル化されたソフトウェアモデルを生成する。
【００７０】
具体的には、動作モデル１０４についてＨＷ／ＳＷ分割をおこない、ソフトウェア実装をあらわすソフトウェアモデル１０６（図１を参照。）を生成する。たとえば、設計対象を含むシステムＬＳＩを構成するソフトウェアのタスク分割をおこない、仮想ＯＳ上に実行可能な実装コードを生成する。
【００７１】
ソフトウェアモデル検証部４１２は、ソフトウェアモデル生成部４１１によって生成されたソフトウェアモデルに含まれているタスクが、正当であるかどうかを、概念モデル生成部４０２によって生成された概念モデルに基づいて検証する。
【００７２】
具体的には、ソフトウェアモデル生成部４１１によって生成された実装コードのシミュレーション結果が、概念モデルの実装コードを概念モデルの検証シナリオでシミュレーションしたシミュレーション結果と一致するかどうかを判定することによって、ソフトウェアモデル１０６の正当性を検証する。ここで、シミュレーション結果とは、ある入力データに対してどのような出力データが得られるか、ということである。
【００７３】
そして、一致する場合は、ソフトウェアモデル１０６の実装コードによってあらわされる機能が正当となる。そして、このソフトウェアモデル１０６の実装コードを取り込んだ、設計対象全体の実装コード１０８（図１を参照。）を生成する。一方、不一致の場合は、ソフトウェアモデル１０６の実装コードによってあらわされる機能が不正確となる。この場合、ソフトウェアモデル生成部４１１は、ソフトウェアモデルの実装コードを修正する。
【００７４】
なお、上述した分析情報入力部４０１、概念モデル生成部４０２、機能モデル生成部４０３、機能モデル検証部４０４、アーキテクチャ情報抽出部４０６、動作モデル生成部４０７、動作モデル検証部４０８、ＩＣＡモデル生成部４０９、ＩＣＡモデル検証部４１０、ソフトウェアモデル生成部４１１およびソフトウェアモデル検証部４１２は、具体的には、たとえば、図３に示したＲＯＭ３０２、ＲＡＭ３０３、ＨＤ３０５、ＦＤ３０７などに記録されたプログラムをＣＰＵ３０１が実行することによって、またはＩ／Ｆ３０９によって、その機能を実現する。
【００７５】
（検証支援装置の検証支援処理手順）
つぎに、この発明の実施の形態にかかる検証支援装置の検証支援処理手順について説明する。図５は、この発明の実施の形態にかかる検証支援装置の検証支援処理手順を示すフローチャートである。
【００７６】
図５において、まず、設計者は、設計対象を含むシステムＬＳＩの顧客からの要求仕様１００を分析して、分析結果をあらわす分析情報を入力する（ステップＳ５０１）。
【００７７】
つぎに、入力された分析情報に基づいて、設計対象の実装コードや、設計対象について検証すべき項目（検証項目）、回路シミュレーションによる検証処理手順を示す検証シナリオなどの概念モデル１０１を生成する（ステップＳ５０２）。生成された概念モデル１０１の正当性については、設計者が検証する。
【００７８】
つぎに、設計対象の機能デモル１０２を生成する（ステップＳ５０３）。具体的には、概念モデル生成部４０２に入力されたクラス図を機能ごとに複数に分割し、分割されたクラス図（分割クラス図）ごとに、機能モデル１０２の実装コードを生成する。
【００７９】
そして、概念モデル１０１の実装コードと機能モデル１０２の実装コードのシミュレーションをおこなう（ステップＳ５０４）。つぎに、概念モデル１０１の実装コードのシミュレーション結果と、機能モデル１０２の実装コードのシミュレーション結果とが、一致するかどうかの判定、すなわち、機能モデル検証をおこなう（ステップＳ５０５）。
【００８０】
不一致の場合（ステップＳ５０５：Ｎｏ）、機能モデル１０２を修正する（ステップＳ５０６）。具体的には、たとえば、概念モデル１０１のクラス図を再度、分割しなおして、分割クラス図を生成し、その分割クラス図ごとに実装コードを生成する。そして、ステップＳ５０４に移行する。
【００８１】
一方、一致する場合（ステップＳ５０５：Ｙｅｓ）、機能モデル１０２が正当であると判断される。そして、正当性が検証された検証済みの機能モデル１０２に、アーキテクチャモデル１０３をマッピングして、動作モデル１０４を生成する（ステップＳ５０７）。そして、動作モデル１０４の実装コードのシミュレーションをおこなう（ステップＳ５０８）。
【００８２】
つぎに、概念モデル１０１の実装コードのシミュレーション結果と、動作モデル１０４の実装コードのシミュレーション結果とが、一致するかどうかの判定、すなわち、動作モデル検証をおこなう（ステップＳ５０９）。
【００８３】
不一致の場合（ステップＳ５０９：Ｎｏ）、動作モデル１０４を修正する（ステップＳ５１０）。具体的には、たとえば、アーキテクチャ情報記憶部４０５から再度アーキテクチャ情報を抽出して、正当性が検証された検証済の機能モデル１０２に、あらたなアーキテクチャモデル１０３をマッピングして、動作モデル１０４を生成する。そして、ステップＳ５０８に移行する。
【００８４】
一方、一致する場合（ステップＳ５０９：Ｙｅｓ）、動作モデル１０４が正当であると判断される。そして、正当性が検証された検証済の動作モデル１０４に対しＨＷ／ＳＷ分割をおこない、ＩＣＡモデル１０５とソフトウェアモデル１０６を生成する（ステップＳ５１１、ステップＳ５１６）。
【００８５】
そして、生成されたＩＣＡモデル１０５の実装コードのシミュレーションをおこなう（ステップＳ５１２）。つぎに、概念モデル１０１の実装コードのシミュレーション結果と、ＩＣＡモデル１０５の実装コードのシミュレーション結果とが、一致するかどうかの判定、すなわち、ＩＣＡモデル検証をおこなう（ステップＳ５１３）。
【００８６】
不一致の場合（ステップＳ５１３：Ｎｏ）、ＩＣＡモデル１０５を修正する（ステップＳ５１４）。具体的には、たとえば、インターフェースラッパの内容を変更することによって、ＩＣＡモデル１０５を修正する。そして、ステップＳ５１２に移行する。
【００８７】
一方、一致する場合（ステップＳ５１３：Ｙｅｓ）、ＩＣＡモデル１０５が正当であると判断される。そして、高位合成をおこなって（ステップＳ５１５）、ＲＴＬ記述を生成する。
【００８８】
また、生成されたソフトウェアモデル１０６の実装コードのシミュレーションをおこなう（ステップＳ５１７）。つぎに、概念モデル１０１の実装コードのシミュレーション結果と、ソフトウェアモデル１０６の実装コードのシミュレーション結果とが、一致するかどうかの判定、すなわち、ソフトウェアモデル検証をおこなう（ステップＳ５１８）。
【００８９】
不一致の場合（ステップＳ５１８：Ｎｏ）、ソフトウェアモデル１０６を修正する（ステップＳ５１９）。具体的には、たとえば、設計対象を含むシステムＬＳＩを構成するソフトウェアのタスク分割を再度おこない、仮想ＯＳ上に実行可能な実装コードを生成する。
【００９０】
一方、一致する場合（ステップＳ５１８：Ｙｅｓ）、ソフトウェアモデル１０６が正当であると判断される。そして、正当であることが検証された検証済のソフトウェアモデル１０６の実装コードを取り込んだ、設計対象全体の実装コード１０８を生成する（ステップＳ５２０）。
【００９１】
この検証処理手順によれば、モデルごとに、段階的に検証をおこなうため、直前までに検証されたモデルについては、検証のやり直しをおこなうことなく、有効なモデルとして活用することができるため、検証処理において手戻りが発生せず、検証処理の効率化を図ることができる。
【００９２】
なお、上述した図５のフローチャートでは、ステップＳ５１１〜５１５までの処理手順と、ステップＳ５１６〜５２０までの処理手順とを並列に実行することとしているが、ステップＳ５１１〜５１５までの処理手順のあとに、ステップＳ５１６〜５２０までの処理手順を実行することとしてもよく、また、ステップＳ５１６〜５２０までの処理手順のあとに、ステップＳ５１１〜５１５までの処理手順を実行することとしてもよい。
【００９３】
（検証処理の具体例）
つぎに、上述した検証処理の具体例について説明する。
【００９４】
（システムＬＳＩのハードウェア構成）
まず、設計対象を含むシステムＬＳＩのハードウェア構成について説明する。図６は、この発明の実施の形態にかかる設計対象を含むシステムＬＳＩのハードウェア構成を示すブロック図である。この設計対象は、たとえば、顧客から設計業務を引き受けた情報であり、ここでは、その設計対象を、シリアル送受信システムとして説明する。
【００９５】
図６において、システムＬＳＩ６００は、設計対象の一例として挙げられたシリアル送受信システム６０１と、受信器６０２と、送信器６０３と、ＣＰＵ６０４と、その他デバイス６０５と、これらを接続するバス６０６と、によって構成されている。
【００９６】
ここで、受信器６０２は、受信パケット６１１を受信し、シリアル送受信システム６０１に供給する。送信器６０３は、シリアル送受信システム６０１から供給された情報を送信パケット６１２として図示しない外部機器に送信する。シリアル送受信システム６０１は、たとえば、ＢＣＨ（６２，４８）で符号化および復号化をおこなう。
【００９７】
そして、受信器６０２からの受信パケット６１１を復号し、この復号したパケット６１３をＣＰＵ６０４に供給する。また、ＣＰＵ６０４からのパケット６１４を符号化する。ＣＰＵ６０４は、シリアル送受信システム６０１からのパケット６１３を用いて、その他デバイス６０５とともにシステムＬＳＩ６００の機能を実行する。
【００９８】
（外部装置のインターフェース仕様）
つぎに、外部装置（受信器６０２、送信器６０３、ＣＰＵ６０４、その他デバイス６０５）のインターフェース仕様について説明する。図７および図８は、外部装置のインターフェースであるバスの仕様を示す説明図である。特に、図７は、ライト時のタイミングチャートであり、図８は、リード時のタイミングチャートである。
【００９９】
図７および図８において、「ＰＣＬＫ」は、ビット幅１の入力クロック信号である。「ＰＡＤＤＲ」は、ビット幅３２のアドレス出力信号である。「ＰＷＲＩＴＥ」は、ビット幅１のリード／ライト制御出力信号である。「ＰＳＥＬ」は、ビット幅１のチップセレクト出力信号である。「ＰＥＮＡＢＬＥ」は、ビット幅１の出力イネーブル信号である。「ＰＲＤＡＴＡ」は、ビット幅３２のデータ入出力信号である。ＣＰＵ６０４に対するバスの仕様は、バス標準プロトコルに準拠しており、ＣＰＵ６０４について組み込みプロセッサコアを採用することとしている。
【０１００】
図９は、外部装置のインターフェースである送信器６０３の仕様を示す説明図である。図９において、「ｃｌｋ」は、ビット幅１の入力クロック信号である。「ＩＳＴＡＲＴ」は、ビット幅１のスタートパルス入力信号である。「ＩＤＡＴＡ」は、ビット幅１のデータ入力信号である。シリアル送受信システム６０１から送信器６０３への入力仕様は、スタートパルス入力信号のｉクロックのパルスを検出すると同時に、送信器６０３がクロックのポジティブエッジごとに１ビットずつデータを取り込むという仕様である。また、入力クロック周波数は、１００ＭＨｚとしている。
【０１０１】
図１０は、外部装置のインターフェースである受信器６０２の仕様を示す説明図である。図１０において、「ｃｌｋ」は、ビット幅１の出力クロック信号である。「ＯＳＴＡＲＴ」は、ビット幅１のスタートパルス出力信号である。「ＯＤＡＴＡ」は、ビット幅１のデータ出力信号である。
【０１０２】
（シリアル送受信システムに要求される基本機能）
つぎに、設計対象であるシリアル送受信システム６０１に要求される基本機能について説明する。シリアル送受信システム６０１に要求される基本機能は、（１）パケットの送信機能と、（２）パケットの受信機能と、（３）初期化機能である。
【０１０３】
（１）パケットの送信機能は、以下のとおりである。
（ｉ）ＣＰＵ６０４が作成したパケット６１４をＢＣＨ（６２，４８）で符号化して送信器６０３に転送する転送機能。
（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>を入力する入力ポートである。
【０１３１】
このように、分割設計クラス図２２１０〜２２４０の属性を用いて、ポート２３１１〜２３１５、ポート２３２１〜２３２７、ポート２３３１〜２３３３、ポート２３４１〜２３４３どうしを接続して、通信路２３５１〜２３５９を決定する。この通信路２３５１〜２３５９は、具体的にはＦＩＦＯ方式で通信をおこなう通信路である。
【０１３２】
また、図２１において、通信路を決定した後、機能モデルの実装コードを生成する（ステップＳ２１０３）。ここで、シリアル送受信システムを含むシステムＬＳＩの機能モデルの実装コードの生成例について説明する。図２４は、シリアル送受信システムを含むシステムＬＳＩの機能モデルの実装コードの生成例を示す説明図である。
【０１３３】
図２４では、エンコーダモジュール２３０３に関する分割設計クラス図２２３０から生成した、エンコーダモジュール２３０３の実装コード２４００を示している。なお、図示はしないが、トップモジュールに関する分割設計クラス図２２１０、コントローラモジュール２３０２に関する分割設計クラス図２２２０、およびデコーダモジュール２３０４に関する分割設計クラス図２２４０についても、それぞれ実装コードを生成する。そして、図５のステップＳ５０４では、各分割設計クラス図２２１０〜２２４０の実装コードのシミュレーションを実行することとなる。
【０１３４】
このあと、図５のステップＳ５０５において、このシミュレーション結果と、概念モデルの実装コードのシミュレーション結果との一致判定をおこない、一致する場合（ステップＳ５０５：Ｙｅｓ）、図２２に示したモジュール分割が正当であり、また、モジュール分割の並列、並行性が正確であることとなる。
【０１３５】
一方、一致しない場合（ステップＳ５０５：Ｎｏ）、図２２に示したモジュール分割が正当でなく、また、モジュール分割の並列、並行性が不正確であるとして、図５のステップＳ５０６において、図２１のステップＳ２１０３で生成された実装コードの修正処理をおこなう。この機能モデル検証により、概念モデルと同一の検証結果になることを確認することができる。
【０１３６】
（シリアル送受信システムを含むシステムＬＳＩのアーキテクチャモデル）
つぎに、シリアル送受信システムを含むシステムＬＳＩのアーキテクチャモデルについて説明する。図２５は、シリアル送受信システムを含むシステムＬＳＩのアーキテクチャモデルのクラス図の一例を示す説明図である。アーキテクチャモデルは、バスやＩＰなどの既存設計の物理的なハードウェア部品をあらわすモデルであり、ここでは、バスモデルをあらわしている。
【０１３７】
アーキテクチャモデルは、基本的に事前に用意され、検証済みのライブラリとして提供され、図２５では、検証済みのバスモデルが記述されている。このように、このアーキテクチャモデルでは、既存設計の物理的なハードウェア部品を用いているため、検証をおこなう必要はない。
【０１３８】
（シリアル送受信システムを含むシステムＬＳＩの動作モデル）
つぎに、シリアル送受信システムを含むシステムＬＳＩの動作モデルについて説明する。動作モデルは、上述したように、概念的に、機能モデルをアーキテクチャモデルにマッピングした結果物である。図２６は、機能モデルとアーキテクチャモデルとのマッピングを示す説明図である。
【０１３９】
図２６において、機能モデル２６００は、図２３に示したように、外部から受信したパケットをデコーダ２６０２が入力して復号し、コントローラ２６０３に供給する。コントローラ２６０３は復号されたパケットをエンコーダ２６０４に出力し、エンコーダ２６０４はパケットを符号化する。
【０１４０】
アーキテクチャモデル２６１０は、バスやＩＰなどの既存設計の物理的なハードウェア部品をあらわすモデルであり、ここでは、プロセッサ２６１１、メモリ２６１２、外部入力Ｉ／Ｆ２６１３、外部出力Ｉ／Ｆ２６１４、ハードウェア２６１５、ハードウェア２６１６、ハードウェア２６１７、およびこれらを接続するバス２６１８から構成されている。
【０１４１】
そして、このアーキテクチャモデル２６１０に、機能モデル２６００をマッピングする。具体的には、デコーダ２６０２をハードウェア２６１５に、コントローラ２６０３をハードウェア２６１６に、エンコーダ２６０４をハードウェア２６１７にマッピングする。この図２５および図２６を用いて説明した内容は、図５のステップＳ５０７に示した処理ステップに相当する内容である。
【０１４２】
（シリアル送受信システムを含むシステムＬＳＩの動作モデルの実装コード生成処理手順）
つぎに、シリアル送受信システムを含むシステムＬＳＩの動作モデルの実装コード生成処理手順について説明する。図２７は、シリアル送受信システムを含むシステムＬＳＩの動作モデルの実装コード生成処理手順を示すフローチャートである。この図２７に示す処理手順は、図５のステップＳ５０７に示した処理ステップの詳細な処理手順を示している。
【０１４３】
まず、図２６に示したマッピングを実現するため、図２２に示した分割設計クラス図２２１０〜２２４０の属性２２１１〜２２４１内の記述を、図２５に示したバスモデルの記述に置き換える（ステップＳ２７０１）。図２８は、属性２２１１内の記述がバスモデルの記述に置き換えられた分割設計クラス図２２１０を示す説明図である。図２８中、アンダーラインの記述箇所において、通信路が、ＦＩＦＯ方式の記述からバスモデルの記述に置き換えられている。
【０１４４】
つぎに、バスモデルの記述に置き換えられた分割設計クラス図２２１０〜２２４０から、機能モデルの実装コードを生成する（ステップＳ２７０２）。そして、生成された機能モデルの実装コードに、各モジュールの見積もり処理時間を追加する（ステップＳ２７０３）。
【０１４５】
図２９は、各モジュールの見積もり処理時間の実装コードへの追加例を示す説明図である。たとえば、図２９に示した図表２９００により、デコーダ２６０２およびエンコーダ２６０４の見積もり処理時間を、それぞれ６００［ｎｓ］とすると、機能モデルの実装コード（たとえば、図２４に示した実装コード２４００）に、図表２９００に示した処理時間に関する記述２９０１を追加する。これにより、動作モデルの実装コード２９０２が生成される。そして、図５のステップＳ５０８では、動作モデルの実装コード２９０２のシミュレーションを実行することとなる。
【０１４６】
このあと、図５のステップＳ５０８において、このシミュレーション結果と、概念モデルの実装コードのシミュレーション結果との一致判定をおこない、一致する場合（ステップＳ５０９：Ｙｅｓ）、動作モデルの実装コード２９０２のシミュレーション結果が、図１３に示した要求項目リスト１３００のすべての要求項目１３０１〜１３０８を満足することとなり、機能モデルとアーキテクチャモデルとのマッピングが正当であることとなる。
【０１４７】
一方、一致しない場合（ステップＳ５０９：Ｎｏ）、動作モデルの実装コード２９０２のシミュレーション結果が、図１３に示した要求項目リスト１３００のすべての要求項目１３０１〜１３０８を満足しておらず、機能モデルとアーキテクチャモデルとのマッピングが正当でないこととなる。この場合、図５のステップＳ５１０において、動作モデルの実装コード２９０２の修正処理をおこなうこととなる。これにより、顧客が要求した動作（性能）を満足するかどうかの検証をおこなうことができる。
【０１４８】
（シリアル送受信システムを含むシステムＬＳＩのＩＣＡモデルの実装コード生成処理手順）
つぎに、シリアル送受信システムを含むシステムＬＳＩのＩＣＡモデルの実装コード生成処理手順について説明する。図３０は、シリアル送受信システムを含むシステムＬＳＩのＩＣＡモデルの実装コード生成処理手順を示すフローチャートである。この図３０に示す処理手順は、図５のステップＳ５１１に示した処理ステップの詳細な処理手順を示している。
【０１４９】
ＩＣＡモデルは、上述したように、モジュール外のインターフェースについてはサイクル精度によって、モジュール内部は動作レベルによって構築したモデルである。このＩＣＡモデルを高位合成することによってＲＴＬ記述を生成する。このＩＣＡモデルでは、インターフェースの正確さの検証をおこなうことができる。
【０１５０】
まず、通信路が決定された機能モデルの構造図から、抽象度の異なるモジュール間を通信する通信路を検出する（ステップＳ３００１）。図３１は、シリアル送受信システムを含むシステムＬＳＩの通信路が決定された機能モデルを示す構造図である。
【０１５１】
図３１において、シリアル送受信システムは、図１７に示した設計クラス図を、並行、並列なモジュールに分割された結果（図２１のステップＳ２１０１を参照。）、トップモジュール２３０１と、ＣＰＵモジュール３１０１と、送信器モジュール３１０２と、受信器モジュール３１０３とが、ＦＩＦＯ方式の通信路３１１１〜３１１５によって接続されたシステムである。また、トップモジュール２３０１の内部は、図２３に示した構造図と同一内容である。これらのモジュールの接続関係から、抽象度の異なるモジュール間を通信する通信路を検出する。
【０１５２】
つぎに、検出された通信路を、インターフェースラッパに置換する（ステップＳ３００２）。図３２は、図３１に示した構造図内の通信路にインターフェースラッパを挿入した構造図である。図３２では、図３１において、エンコーダモジュール２３０２の抽象度と送信器モジュール３１０２の抽象度が異なっているため、このモジュール２３０２、３１０２間の通信路３１１４をインターフェースラッパ３２０１に挿入し、トップモジュール２３０１の抽象度を変換する。
【０１５３】
インターフェースラッパ３２０１は、送信器モジュール３１０２のトランザクションレベルのポート３１０２ａと接続されるトランザクションレベルインターフェース３２０２と、トップモジュール２３０１に接続される２つの信号レベルポート３２０３，３２０４を備えている。このため、トランザクションレベルのポート２３１４を、送信レベルポート３２１０、３２１１に置き換える。
【０１５４】
また、トップモジュール２３０１内部のエンコーダモジュール２３０３のトランザクションレベルのポート２３３１〜２３３３も、信号レベルのポート３２１２〜３２１６に置き換える。このポート変換により、コントローラモジュール２３０２のトランザクションレベルのポート２３２４、２３２５も、信号レベルのポート３２１７〜３２１９に変換される。
【０１５５】
このように、エンコーダモジュール２３０３のポート数が変更されるため、図３１に示したエンコーダモジュール２３０３をＩＣＡモデルのエンコーダモジュールに変換し（ステップＳ３００３）、エンコーダモジュール２３０３自体の抽象度を変換する。図３３は、ＩＣＡモデルのエンコーダモジュールの内部構造の一例を示す説明図である。
【０１５６】
図３３において、ＩＣＡモデルのエンコーダモジュール３３００は、図３１に示したエンコーダモジュール２３０３およびポート２３３１〜２３３３を備えている。そして、ポート２３３１、２３３２と、ポート３２１２〜３２１４との間の通信を可能とするため、各種ラッパやポートが挿入されている。同様に、ポート２３３３と、ポート３２１５、３２１６との間の通信も可能とするため、各種ラッパやポートが挿入されている。
【０１５７】
このあと、ＩＣＡモデルのエンコーダモジュール３３００の実装コードを生成する（ステップＳ３００４）。図３４は、ＩＣＡモデルのエンコーダモジュール３３００の実装コードの一例を示す説明図である。そして、図５のステップＳ５１２では、ＩＣＡモデルの実装コード３４００のシミュレーションを実行することとなる。
【０１５８】
このあと、図５のステップＳ５１３において、ＩＣＡモデルの実装コード３４００のシミュレーション結果と、概念モデルの実装コードのシミュレーション結果との一致判定をおこない、一致する場合（ステップＳ５１３：Ｙｅｓ）、ＩＣＡモデルの実装コード３４００のシミュレーション結果が、図１３に示した要求項目リスト１３００のすべての要求項目１３０１〜１３０８を満足することとなり、インターフェースラッパの挿入が正当であることとなる。
【０１５９】
一方、一致しない場合（ステップＳ５１３：Ｎｏ）、ＩＣＡモデルの実装コード３４００のシミュレーション結果が、図１３に示した要求項目リスト１３００のすべての要求項目１３０１〜１３０８を満足しておらず、インターフェースラッパの挿入が正当でないこととなる。
【０１６０】
そして、図５に示したステップＳ５１４において、ＩＣＡモデルの実装コード３４００の修正処理をおこなうこととなる。これにより、インターフェースの正確さの検証をおこなうことができる。
【０１６１】
（シリアル送受信システムを含むシステムＬＳＩのソフトウェアモデルの実装コード生成処理手順）
つぎに、シリアル送受信システムを含むシステムＬＳＩのソフトウェアモデルの実装コード生成処理手順について説明する。図３５は、シリアル送受信システムを含むシステムＬＳＩのソフトウェアモデルの実装コード生成処理手順を示すフローチャートである。この図３５に示す処理手順は、図５のステップＳ５１６に示した処理ステップの詳細な処理手順を示している。
【０１６２】
ソフトウェアモデルは、上述したように、シリアル送受信システムを含むシステムＬＳＩを構成するソフトウェアのタスク分割をおこない、仮想ＯＳ上に実行するモデルである。図３５において、まず、アーキテクチャモデルに機能モデルの一部をソフトウェアによりマッピングする（ステップＳ３５０１）。
【０１６３】
図３６は、アーキテクチャモデルに機能モデルの一部をソフトウェアによりマッピングをおこなった例を示す説明図である。具体的には、図２６に示したように、デコーダ２６０２はハードウェア２６１５にマッピングし、エンコーダ２６０４はハードウェア２６１７にマッピングする。一方、ＣＰＵ２６０１およびコントローラ２６０３は、プロセッサ２６１１にマッピングする。
【０１６４】
つぎに、このマッピングにより、ソフトウェアモデルにおける設計クラス図を生成する（ステップＳ３５０２）。図３７は、ソフトウェアモデルにおける設計クラス図を示す説明図である。図３７において、ソフトウェアモデルにおける設計クラス図３７００は、図２２に示した分割設計クラス図２２１０〜２２４０を元にして生成される。
【０１６５】
ソフトウェアモデルにおける設計クラス図３７００は、トップモジュールに関する分割設計クラス図３７０１と、デコーダモジュールに関する分割設計クラス図３７０２と、エンコーダモジュールに関する分割設計クラス図３７０３のほかに、仮想ＯＳモデルに関する分割設計クラス図３７０４を含んでいる。そして、設計クラス図３７０１〜３７０４ごとに、ソフトウェアモデルの実装コードを生成する（ステップＳ３５０３）。
【０１６６】
このあと、図５のステップＳ５１７において、ソフトウェアモデルの実装コードのシミュレーションを実行することとなる。そして、図５のステップＳ５１８において、ソフトウェアモデルの実装コードのシミュレーション結果と、概念モデルの実装コードのシミュレーション結果との一致判定をおこなう。そして、一致する場合（ステップＳ５１８：Ｙｅｓ）、ソフトウェアモデルの実装コードのシミュレーション結果が、図１３に示した要求項目リスト１３００のすべての要求項目１３０１〜１３０８を満足することとなり、ソフトウェアのタスク分割が正当であることとなる。
【０１６７】
一方、一致しない場合（ステップＳ５１８：Ｎｏ）、ソフトウェアモデルの実装コードのシミュレーション結果が、図１３に示した要求項目リスト１３００のすべての要求項目１３０１〜１３０８を満足しておらず、ソフトウェアのタスク分割が正当でないこととなる。
【０１６８】
そして、図５に示したステップＳ５１９において、ソフトウェアモデルの実装コードの修正処理をおこなうこととなる。これにより、ソフトウェアのタスク分割の正確さの検証をおこなうことができる。
【０１６９】
この発明の実施の形態にかかる検証支援装置および検証支援方法によれば、仕様リスクの早期回避を図ることができる。具体的には、顧客要求をＵＭＬで分析した上で、実行可能なモデルを用いて顧客の機能要求に満足するかどうかを検証することができ、仕様の誤解やミスを早期に発見することができ、誤った仕様に基づくシステムＬＳＩの設計を防止することができる。
【０１７０】
また、この発明の実施の形態にかかる検証支援装置および検証支援方法によれば、シミュレーションスピードネックの解決を図ることができる。具体的には、従来の検証手法ではＲＴＬのシミュレータを用いてシミュレーションおこなうため、シミュレーション速度が非常に遅いという問題があったが、この実施の形態では、より抽象度の高いモデルを用いてシミュレーションを実行するため、ＲＴＬのシミュレータに比べて数百倍の速度でシミュレーションを実行することができる。したがって、このシミュレーション速度の向上により、検証作業を含めた設計期間の短縮化を図ることができる。
【０１７１】
さらに、この発明の実施の形態にかかる検証支援装置および検証支援方法によれば、コストの削減を図ることができる。具体的には、従来の検証手法では大規模なＬＳＩの場合に高価なエミュレータを導入する必要があったが、この発明の実施の形態では、抽象度の高いモデルの検証によりエミュレータの利用頻度を大幅に減少することができ、コストの削減を図ることができる。また、エミュレータの利用は基本的に時間単位でお金に換算されるケースが多いため、検証時間の短縮化によって費用の低減を図ることができる。
【０１７２】
また、この発明の実施の形態にかかる検証支援装置および検証支援方法によれば、早期仕様のミスをなくすことによって検証工程の短縮化を図ることができる。
【０１７３】
また、従来手法に対するより効果的な改善点として、従来手法ではＲＴＬが完成されていないと検証工程をおこなうことができなかったが、この発明の実施の形態では、設計の初期の段階から検証を開始することができる。また、設計の詳細度に応じて各モデルに対してその正当性を検証することができる。これにより、従来における設計終了⇒検証スタートという手法に対して、大幅の設計工程の短縮化を図ることができる。
【０１７４】
さらに、この発明の実施の形態にかかる検証支援装置および検証支援方法によれば、定量的なアーキテクチャ評価をおこなうことができる。具体的には、従来手法ではＲＴＬのＨＤＬを完成しない限り、性能評価できないという問題点があったが、ＲＴＬのＨＤＬを完成してから性能に満足しないという理由で設計変更をおこなうと、非常に高いコストがかかることとなる。
【０１７５】
これに対し、この発明の実施の形態では、早期の段階でＲＴＬによる抽象度の高い動作モデルに対してラフな性能（動作）を見積ることができ、性能（動作）に満足しないというリスクの低減を図ることができる。
【０１７６】
また、上述した具体例では、シリアル送受信システムを含むシステムＬＳＩを例に挙げて説明したが、このシステムＬＳＩには限定されることはなく、各種システムＬＳＩに適用することができる。
【０１７７】
なお、この実施の形態で説明した検証支援方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション、ＣＡＤ等のコンピュータで実行することにより実現することができる。このプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。またこのプログラムは、インターネット等のネットワークを介して配布することが可能な伝送媒体であってもよい。
【産業上の利用可能性】
【０１７８】
以上のように本発明は、たとえば、ＬＳＩの設計データの検証をおこなうシステムやツールを提供することに適している。
【図面の簡単な説明】
【０１７９】
【図１】この発明の実施の形態にかかる検証支援の概念図である。
【図２】図１に示した各モデルの抽象度をあらわすグラフである。
【図３】この発明の実施の形態にかかる検証支援装置のハードウェア構成を示すブロック図である。
【図４】この発明の実施の形態にかかる検証支援装置の機能的構成を示すブロック図である。
【図５】この発明の実施の形態にかかる検証支援装置の検証支援処理手順を示すフローチャートである。
【図６】この発明の実施の形態にかかる設計対象を含むシステムＬＳＩのハードウェア構成を示すブロック図である。
【図７】外部装置のインターフェースであるバスの仕様（ライト時のタイミングチャート）を示す説明図である。
【図８】外部装置のインターフェースであるバスの仕様（リード時のタイミングチャート）を示す説明図である。
【図９】外部装置のインターフェースである送信器の仕様を示す説明図である。
【図１０】外部装置のインターフェースである受信器の仕様を示す説明図である。
【図１１】ＣＰＵで送受信されるパケットの構成を示す説明図である。
【図１２】送信パケットの構成を示す説明図である。
【図１３】要求定義であるシステムＬＳＩの要求項目リストを示す説明図である。
【図１４】要求定義であるシステムＬＳＩのユースケース図である。
【図１５】要求定義された結果物であるシステムＬＳＩの分析クラス図である。
【図１６】要求定義された結果物であるシステムＬＳＩのシーケンス図である。
【図１７】シリアル送受信システムを含むシステムＬＳＩの設計クラス図である。
【図１８】概念モデルの実装コードを示す説明図である。
【図１９】シリアル送受信システムを含むシステムＬＳＩの検証項目を示す説明図である。
【図２０】シリアル送受信システムを含むシステムＬＳＩの検証シナリオを示す説明図である。
【図２１】シリアル送受信システムを含むシステムＬＳＩの機能モデルの実装コード生成処理手順を示すフローチャートである。
【図２２】図１７に示した設計クラス図を分割することによって得られた分割設計クラス図を示す説明図である。
【図２３】分割設計クラス図によってあらわされるモジュール間を接続する通信路を示す説明図である。
【図２４】シリアル送受信システムを含むシステムＬＳＩの機能モデルの実装コードの生成例を示す説明図である。
【図２５】シリアル送受信システムを含むシステムＬＳＩのアーキテクチャモデルのクラス図の一例を示す説明図である。
【図２６】機能モデルとアーキテクチャモデルとのマッピングを示す説明図である。
【図２７】シリアル送受信システムを含むシステムＬＳＩの動作モデルの実装コード生成処理手順を示すフローチャートである。
【図２８】属性内の記述がバスモデルの記述に置き換えられた分割設計クラス図を示す説明図である。
【図２９】各モジュールの見積もり処理時間の実装コードへの追加例を示す説明図である。
【図３０】シリアル送受信システムを含むシステムＬＳＩのＩＣＡモデルの実装コード生成処理手順を示すフローチャートである。
【図３１】シリアル送受信システムを含むシステムＬＳＩの通信路が決定された機能モデルを示す構造図である。
【図３２】図３１に示した構造図内の通信路にインターフェースラッパを挿入した構造図である。
【図３３】ＩＣＡモデルのエンコーダモジュールの内部構造の一例を示す説明図である。
【図３４】ＩＣＡモデルのエンコーダモジュールの実装コードの一例を示す説明図である。
【図３５】シリアル送受信システムを含むシステムＬＳＩのソフトウェアモデルの実装コード生成処理手順を示すフローチャートである。
【図３６】アーキテクチャモデルに機能モデルの一部をソフトウェアによりマッピングをおこなった例を示す説明図である。
【図３７】ソフトウェアモデルにおける設計クラス図を示す説明図である。
【図３８】従来のＬＳＩの開発処理手順を示すフローチャートである。
【符号の説明】
【０１８０】
１００  要求仕様
１０１  概念モデル
１０２  機能モデル
１０３  アーキテクチャモデル
１０４  動作モデル
１０５  ＩＣＡモデル
１０６  ソフトウェアモデル
４０１  分析情報入力部
４０２  概念モデル生成部
４０３  機能モデル生成部
４０４  機能モデル検証部
４０５  アーキテクチャ情報記憶部
４０６  アーキテクチャ情報抽出部
４０７  動作モデル生成部
４０８  動作モデル検証部
４０９  ＩＣＡモデル生成部
４１０  ＩＣＡモデル検証部
４１１  ソフトウェアモデル生成部
４１２  ソフトウェアモデル検証部                                                                               
【国際調査報告】
2006003702.tif 000040
2006003702.tif 000041