JP2004510258A - ハードウェアとソフトウェアを備えた電子システムの性能レベルモデリング及びシミュレーション - Google Patents

Abstract

【課題】ハードウェア及びソフトウェアの両方を備えた電子システムの性能レベルモデルを評価し、所望の動作仕様に準拠した異なるアーキテクチャ設計の実施及び試験が可能な方法及びシステムを提供する。
【解決手段】動作及びアーキテクチャを収集し（ステップ１０、１５）、アーキテクチャコンポーネントにマッピングする（ステップ２０）。マッピングされたシステムをシミュレーションし（ステップ２５）、ハードウェア及びソフトウェアのコンポーネントをエクスポートし（ステップ３０）、ハードウェア及びソフトウェアのコンポーネントを別々に検証し（ステップ３５〜５０）、得られたシステムを協調検証ツールを用いて検証する（ステップ５５）。
【選択図】図１

Description

【０００１】
【発明の属する技術分野】
本発明は、広くは電子システムの性能レベルモデルの設計と評価に関し、特に、システムレベルで電子システムのモデルを生成し、シミュレーションする方法に関する。
【０００２】
【従来の技術】
従来の電子システム（ｅｌｅｃｔｒｏｎｉｃ ｓｙｓｔｅｍ）の設計プロセスでは、動作（ｂｅｈａｖｉｏｒ）及びアーキテクチャの仕様（ｓｐｅｃｉｆｉｃａｔｉｏｎ）を決定した後に、ハードウェア及びソフトウェアの設計を行う。設計フローにおいて機能性能とアーキテクチャ性能のトレードオフを検討することは、余りにも遅すぎるため、時間的にも費用効率の面でも、最早変更することはできない。
【０００３】
これらの電子システムに対する製品（ｐｒｏｄｕｃｔｓ）の設計プロセスには、数多くの制約がある。第１の制約は、電力、性能及びコストの観点から、これらの製品はシリコン又は他のハードウェアプラットホーム内に実装（ｉｍｐｌｅｍｅｎｔ）しなければならない点である。第２の制約は、これらの製品には、高度に専門化したシステムチームが同時実行可能なプログラミングシステム（ｅｘｅｃｕｔａｂｌｅ ｃｏｎｃｕｒｒｅｎｔ ｐｒｏｇｒａｍｍｉｎｇ ｐａｒａｄｉｇｍｓ）の観点から考案したシステムが実装されるが、このシステムは、今日のハードウェア設計者にはよく理解されていない点である。実際に、殆どの電子システムでは、機能をハードウェアとソフトウェアに分ける分け方は、解析によるものではなく、設計者の過去の経験に依存している。そして、分けられた仕様は、超高速集積回路（Ｖｅｒｙ Ｈｉｇｈ Ｓｐｅｅｄ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ：以下、ＶＨＳＩＣという）用のハードウェア記述言語（ＶＨＤＬ）のような特定のハードウェア記述言語（ｈａｒｄｗａｒｅ ｄｅｓｃｒｉｐｔｉｏｎ ｌａｎｇｕａｇｅ：以下、ＨＤＬという）又はハードウェアコンポーネント用のＶｅｒｉｌｏｇと、Ｃ言語のようなソフトウェア記述言語又はソフトウェアコンポーネント用のアセンブラ言語とに翻訳される。ハードウェアとソフトウェアは密接に関係しているが、ハードウェア設計とソフトウェア設計は別々に行われる。電子システムが組み立てられた後になってから、初めてソフトウェアとハードウェアが一緒に動作する。設計の結果が、最適な設計から遠く離れていたり、さらには間違っていることもあり、設計からサイクルを再度やり直さなければならないこともある。
【０００４】
電子システムの設計と実現（ｉｍｐｌｅｍｅｎｔａｔｉｏｎ）間のこのギャップは、この種の製品及び電子システムの設計プロセスにおいて、急速に最大のボトルネックとなりつつある。同時に、製品を市場を投入するまでの時間を短縮しなければならないという状況では、製品を迅速に設計する必要がある。したがって、設計にかかる時間は長くなっているが、ビジネスサイクルにおいて設計に許容される時間は、絶えず短くなっている。設計時間を短縮する主な手法は、設計プロセスを速くするために、ハードウェア／ソフトウェア協調設計法（ｃｏ−ｄｅｓｉｇｎ ｐｒｏｃｅｄｕｒｅ）の実行を試み、電子システムのハードウェアとソフトウェアを同時（ｃｏｎｃｕｒｒｅｎｔｌｙ）に設計することである。しかしながら、効率の良い協調設計方法論（ｍｅｔｈｏｄｏｌｏｇｙ）又は手法（ａｐｐｒｏａｃｈ）は、容易に考案又は実現されていない。この理由の１つは、ハードウェア設計及びソフトウェア設計の方法論にはそれぞれ独自の手法があり、それらは協調させるのが困難であるという点である。
【０００５】
真の協調設計方法論を構築するために、幾つかの手法が試みられている。１つの既知の手法は、協調検証手法（ｃｏ−ｖｅｒｉｆｉｃａｔｉｏｎ ａｐｐｒｏａｃｈ）であり、協調検証シミュレータを利用して、設計されたハードウェアとソフトウェアを一緒に検証する。この手法の問題は、協調検証の時点で、全てのハードウェアをサイクル精度のレベル（ｃｙｃｌｅ ａｃｃｕｒａｔｅ ｌｅｖｅｌ）まで構築及び設計しておかなければならず、そのため、協調検証中に何らかの問題が起きても、問題がハードウェアの再設計に関わる場合、既にハードウェアは設計され、実現されているので、再設計は困難である。同様に、システムのソフトウェアは、協調検証の前にコンパイルしておかなければならない。
【０００６】
協調設計のもう１つの手法は、命令セット（ｉｎｓｔｒｕｃｔｉｏｎ ｓｅｔ：以下、ＩＳＳという）のコシミュレーション（ｃｏ−ｓｉｍｕｌａｔｉｏｎ）である。この手法では、電子システムのＨＤＬ記述及び命令セットのモデルを利用して、プロセッサと関連するコンポーネントについての命令セットを同時にシミュレーションする。この手法は、有効なコシミュレーションを提供するが、依然として、機能的に完全なハードウェアのモデルを利用しているため、ハードウェアコンポーネントの置換えや実質的な再設計は困難である。また、この手法は、生成する（ｃｒｅａｔｅ）のが困難である複雑なプロセッサモデルを必要とし、したがって、種々のプロセッサの開発（ｅｘｐｌｏｒａｔｉｏｎ）に対しては障壁が高い。この手法も、ハードウェアの過大設計（ｈａｒｄｗａｒｅ ｏｖｅｒ−ｄｅｓｉｇｎ）となり、それに関連して、コストが上がり、電力消費が増え、電子システム内に占める面積が大きくなる。
【０００７】
【発明が解決しようとする課題】
したがって、ハードウェアが完全には設計されていないレベルで、シミュレーションができるとともに、ハードウェアコンポーネントを容易に再設計することができるハードウェア／ソフトウェア協調設計方法論が望まれている。
【０００８】
電子システムの設計におけるもう１つの問題は、前に設計された電子システムにおいて使用されているコンポーネントを再利用できるかである。電子システムの設計プロセスは、コンポーネントを再利用できなければならず、したがって、再利用可能な設計方法論をサポートする必要がある。既に設計されたコンポーネントを再利用することにおける問題は、それらが使用している通信プロトコルが固定であることにあり、異なるプロトコルを使用する異なったコンポーネントとインタフェースする場合、プロトコルの変換が必要となる。実際に、電子システムをこれから構築するときには、全設計の半分以上が再利用される。
【０００９】
今日、プロトコルの選択は、コンポーネントを設計しながら行われ、機能の動作と通信の動作は、本質的に混じり合っている。しかしながら、プロトコルの良い選択は、通信に関わる全てのコンポーネントが既知の場合にのみ可能である。したがって、電子システムの設計環境は、最初からコンポーネントを純粋に機能的な表現で記述すべきである。後に、コンポーネントを電子システムで（再）使用するときに、設計環境は、コンポーネントを最も適切な通信の動作にプラグインできるようにする。この手法は、通信の動作と機能の動作が混じり合っている現在のハードウェア設計方法とは対照的である。
【００１０】
コンポーネントを再利用できるようにするためには、コンポーネントをモジュール化する必要がある。モジュール設計（ｍｏｄｕｌａｒ ｄｅｓｉｇｎｓ）において、電子システムの全ての機能（ｃｏｍｐｌｅｔｅ ｓｙｓｔｅｍ ｆｕｎｃｔｉｏｎａｌｉｔｙ）は、複雑さが処理しやすい通信コンポーネントに分割される。この手法の利点は、コンポーネントを再利用することができるとともに、電子システムへの適応と保守がより容易な点である。
【００１１】
また、ハードウェア／ソフトウェアシステム設計環境において、以下の要件を検討すべきである。（１）モジュール化は、複雑さを減らすのに不可欠である。（２）複数の記述言語を一緒にして、各システムコンポーネントを最も適切なシステム内に記述できるようにしなければならない。（３）設計環境は、異質な概念的仕様（ｈｅｔｅｒｏｇｅｎｅｏｕｓ ｃｏｎｃｅｐｔｕａｌ ｓｐｅｃｉｆｉｃａｔｉｏｎ）、得られる異質なアーキテクチャ、及び中間の全ての改良化（ｒｅｆｉｎｅｍｅｎｔ）のステップをモデル化できるようにしなければならない。（４）在庫コンポーネント及び関連する設計環境をモデル化すべきである。
【００１２】
【課題を解決するための手段】
本発明は、ハードウェア及びソフトウェアのコンポーネントの両方を備えた電子システムの性能レベルモデルを生成し、評価する方法及びシステムに関する。本発明は、システム設計者がシステムの機能コンポーネントを定め、そして、特定したコンポーネントを用いてマッピングし、マッピングされたシステムモデルを評価できるようにする簡単な方法を提供する。
【００１３】
一具体例において、本発明は、ハードウェア及びソフトウェアの要素の両方を備えた電子システムをモデル化する電子システムモデル化方法に関する。この電子システムモデル化方法は、複数の動作を生成するステップと、複数の動作の各動作を適切なアーキテクチャコンポーネントに関連付けるステップと、動作を実行するために、アーキテクチャコンポーネント間の通信を必要とする要求するアーキテクチャコンポーネント間の通信パターンを生成するステップとを有する。
【００１４】
他の具体例において、本発明は、ハードウェア及びソフトウェアのコンポーネントを備えた電子システムの動作モデルを生成する動作モデル生成システムに関する。この動作モデル生成システムは、電子システムの一部として実行可能なコンポーネントに対応する複数のアーキテクチャコンポーネントと、ユーザが定めた動作を実行するために、アーキテクチャコンポーネント間の通信を必要とするアーキテクチャコンポーネント間の通信パターンを生成する手段とを備える。
【００１５】
更なる具体例において、本発明は、ハードウェア及びソフトウェアの要素を備えた電子システムの性能レベルモデルに関する。この電子システムの性能レベルモデルは、入力情報を提供する入力機能と、電子システムの第１のアーキテクチャコンポーネントによって実行される機能を表す第１のサービスと、電子システムの第２のアーキテクチャコンポーネントによって実行される機能を表す第２のサービスと、第１のサービスと第２のサービス間の通信を容易にする少なくとも１つのアプリケーションプログラミングインタフェースと、電子システムの性能レベルモデルの出力情報を受信する出力機能とを備える。
【００１６】
本発明の側面の目的は、設計者が、高い抽象レベルで、大きな、より複雑な回路及びシステムを働かせることができるようにするシステムレベルのシミュレーション機能を提供することである。
【００１７】
本発明の側面の更なる目的は、設計システムの所望の動作仕様に準拠した幾つかの異なるアーキテクチャ設計を容易に実行し、試験する技術を提供することである。
【００１８】
本発明の側面のもう１つの目的は、設計の妥当性検証（ｖａｌｉｄａｔｉｏｎ）のレベルをシステムレベルに引き上げることである。
【００１９】
本発明の側面の追加的な目的は、より標準化した設計環境を提供し、これによって、異なる設計プラットホーム間のクロストレーニングの必要性を軽減し、リソースをより設計及び実行に向けられるようにすることである。
【００２０】
本発明の側面の更にもう一つの目的は、複雑なデジタル電子システムを設計する、直感的で対話的な（ｉｎｔｅｒａｃｔｉｖｅ）技術を提供することである。
【００２１】
本発明の更なる目的は、複雑なデジタル電子システム設計を高いレベルで繰り返して改良することができる技術を提供することである。
【００２２】
したがって、本発明の利点は、ハードウェア及びソフトウェアの要素の両方を備えた電子システムをモデル化する電子システムモデル化方法を提供する。この電子システムモデル化方法は、モデル化されるシステムによって実行される動作に対応した複数の動作を収集するステップと、アーキテクチャプラットホーム内部に含まれる複数のハードウェア及びソフトウェアのアーキテクチャコンポーネントを収集するステップと、収集された複数の動作の各々を、動作を実行する選択されたアーキテクチャコンポーネントにマッピングするステップと、動作を実行するために、アーキテクチャコンポーネント間で通信を要求するアーキテクチャコンポーネント間の通信パターンを認識して収集するステップと、動作間の各通信インスタンスを収集されたパターンのインスタンスにマッピングするステップとを有する。
【００２３】
本発明のもう１つの利点は、ハードウェア及びソフトウェアのコンポーネントを備えた電子システムの動作モデルを生成する動作モデル生成システムを提供する。この動作モデル生成システムは、電子システムの一部として実行可能なコンポーネントにそれぞれ対応した複数のアーキテクチャコンポーネントと、ユーザが定めた動作を実行するために、アーキテクチャコンポーネント間で通信を要求するアーキテクチャコンポーネント間において、動作を実行するアーキテクチャコンポーネント間で通信するのに必要とされる介在アーキテクチャコンポーネント間の通信を含む通信パターンを生成する手段とを備える。
【００２４】
更に本発明のもう１つの利点は、ハードウェア及びソフトウェアのコンポーネントを備えた電子システムの動作間における通信の性能レベルモデルを提供する。通信の性能レベルモデルは、１つ以上の送信先（ｄｅｓｔｉｎａｔｉｏｎ）動作に転送されるデータを供給する第１の動作用のアプリケーションプログラミングインタフェースと、動作通信がマッピングされるパターンによりサポートされる、複数のサービスの中に含まれ、通信プロトコルの性能をモデル化するアプリケーションプログラミングインタフェースを実行する第１のサービスと、第１の動作がマッピングされるアーキテクチャコンポーネントの記号によりサポートされる複数のサービス宣言の中に含まれ、第１のサービスにより使用されて、アーキテクチャプラットホームの性能をモデル化する１つ以上のアプリケーションプログラミングインタフェースと、アーキテクチャコンポーネントの性能モデルにより特定される複数のサービス定義によって、アーキテクチャコンポーネントの記号においてサポートされるサービス宣言と、第２のアーキテクチャコンポーネントによって実行可能な機能に対応する複数の第２のサービスの１つであり、電子システムの第１のコンポーネントにトポロジー的に接続され、第２のアーキテクチャコンポーネントによって実行される機能を表す第２のアプリケーションインタフェースと、送信元（ｓｏｕｒｃｅ）動作から送信先動作への通信が完成するように、電子システムの性能レベルモデル出力情報を受信する送信先動作用の入力アプリケーションインタフェースとを備える。
【００２５】
本発明の上述した利点及び他の利点は、図面を参照して本発明の好ましい実施の形態を説明する詳細な記述から更に明らかとなる。
【００２６】
【発明の実施の形態】
本発明は、種々の変形形態、代替形態が可能であるが、特定の実施の形態を例として図示し、以下詳細に説明する。しかしながら、詳細な説明は、本発明を特定の形態に限定することを意図するものではない。むしろ、本発明は、特許請求の範囲に記載するように、本発明の趣旨及び範囲を逸脱することなく、全ての変形形態、均等形態及び代替形態を含むことを意図している。
【００２７】
本発明により、ユーザは、システムが何をするかを特定する動作モデル（ｂｅｈａｖｉｏｒ ｍｏｄｅｌ）と、システムを実現する（ｉｍｐｌｅｍｅｎｔ）コンポーネントを特定するアーキテクチャモデルとを明白に区別することができる。システムの機能とアーキテクチャ間のこの明白な区別により、システム設計者は、設計サイクルの初期段階において、複数の異なるアーキテクチャ上で実行される動作の性能効果をシミュレーションすることができる。
【００２８】
ハードウェア要素とソフトウェア要素を有するシステムを設計する際、解析すべき幾つかの重要な要因がある。このような要因には、システムプロセッサにおいて実行される動作の遅延と、オペレーティングシステムのスケジューラのオーバヘッド及び機能と、システムの特定用途向け集積回路（ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ：以下ＡＳＩＣという）又はオンチップカスタムハードウェアの実行遅延と、ハードウェア及びソフトウェアのコンポーネント間の通信経路及びタイミングと、バス及びメモリのアクセス遅延と、命令及びデータのフェッチタイミングとが含まれる。更に、システムレベルのシミュレーションでは、リソース間の競合の問題も起こることがあり、したがって、この問題は、設計プロセスの初期段階に対処しなければならない。
【００２９】
図１に示すように、ステップ１０において、ユーザは所望のシステムの動作を入力する。次にステップ１５において、ユーザは、システムを実行するアーキテクチャコンポーネントを入力する。次にステップ２０において、ユーザが入力した動作が、適切なアーキテクチャコンポーネントにマッピングされる。動作がアーキテクチャコンポーネントに一旦マッピングされると、次にステップ２５において、マッピングされたシステムの性能をシミュレーションすることができる。性能のシミュレーションでは、マッピングされた特定のシステムの設計に対して、システムのタイミングがユーザ仕様を満たしているかが判定される。ユーザ仕様を満たしていないときは、ユーザは、動作ブロック（ｂｅｈａｖｉｏｒａｌ ｂｌｏｃｋ）の一部を異なるアーキテクチャブロックにマッピングすることができ、これにより、これらの設計（ｉｍｐｌｅｍｅｎｔａｔｉｏｎ）をハードウェアとソフトウェア間で動かすことができる。設計は、例えば、埋込プロセッサ、メモリ及びカスタムハードウェアを備えたシステムオンチップとして行うことができ、あるいはディスクリートのプロセッサ、メモリ及びシステムオンチップ（ＳＯＣ）として行うことができる。ステップ３０において、設計が十分に改良されたレベルに達し、その性能がシステム仕様を満足するようになると、ユーザは、設計をソフトウェアとハードウェアの設計としてエクスポートすることができる。次にステップ３５において、ハードウェア設計は、ＨＤＬシミュレーション、フロアプラン（ｆｌｏｏｒ ｐｌａｎｎｉｎｇ）及び論理合成（ｌｏｇｉｃ ｓｙｎｔｈｅｓｉｓ）の準備が整う。ステップ４５において、ソフトウェアモデルは、ＲＴＯＳにリンクさせる準備が整う。次にステップ４０、５０において、ハードウェアコンポーネントとソフトウェアコンポーネントは別々に検証される。更に、ステップ５５において、エクスポートされた設計のハードウェアコンポーネントとソフトウェアコンポーネントを協調検証ツールにより一緒に検証することができる。
【００３０】
図２に示すように、ステップ１００において、複数の動作がユーザにより生成される。ユーザは、動作をＣ＋＋オブジェクトとして入力し、動作のデータベースから選択し、ブロック図に階層的に構成し、ダイアログボックスに入力し、あるいは他の方法で生成することができる。動作は、設計者がシステムに実行を要求する、システムの所望の機能を記述している。
【００３１】
ステップ１１０において、複数のアーキテクチャコンポーネントがユーザにより生成される。ユーザは、アーキテクチャコンポーネントを入力し、アーキテクチャのデータベースから選択し、アーキテクチャ図に階層的に構成し、ダイアログボックスに入力し、あるいはそれ以外の方法で生成することができる。本明細書において使用するように、アーキテクチャコンポーネントは、実際のシステムで実現可能なコンポーネントであるアーキテクチャ要素（ａｒｃｈｉｔｅｃｔｕｒｅ ｅｌｅｍｅｎｔ）のモデルを参照する。アーキテクチャ要素の例としては、バス、ＣＰＵ、実時間オペレーティングシステム（ｒｅａｌ ｔｉｍｅ ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ：以下ＲＴＯＳという）、スケジューラ、ＡＳＩＣ等が含まれる。アーキテクチャコンポーネントは、各サービスがアーキテクチャ要素によって実行される特定の機能に関係した案複数のサービスを含んでいる。例えば、ＲＴＯＳは、スケジューラアプリケーション、標準Ｃライブラリ等によりモデル化される。
【００３２】
ステップ１２０において、動作のインスタンスを適切なアーキテクチャコンポーネント（例えば、ＲＴＯＳ又はＡＳＩＣ）にマッピングすることにより、動作をハードウェアとソフトウェアに分ける。ステップ１３０において、ユーザは、この特定の分割の影響（ｉｍｐａｃｔ）をモデル化したこれらのシステムの性能解析を実行することができる。ユーザは、システムが性能仕様を満足するようになるまで分割ステップを繰り返す。
【００３３】
一旦分割が完了すると、ステップ１４０において、ユーザは、動作設計における複数のネットについて通信パターンを選択することにより、マッピングされた設計を改良することができる。通信パターンは、個別のアーキテクチャコンポーネント間の通信を実行するのに必要なタイミング、速度及びプロトコルを含む。通信パターンを選択した後、ステップ１５０において、動作を再びシミュレーションする。この場合、性能シミュレーションは、計算と共に通信の性能への影響をモデル化しているので、より正確なものになる。例えば、ハードウェアとソフトウェア間の通信は、レジスタ（ｒｅｇｉｓｔｅｒ）又は共有メモリ（ｓｈａｒｅｄ ｍｅｍｏｒｙ）にマッピングすることができる。ユーザは、システムが性能仕様を満足するようになるまでマッピングステップを繰り返す。
【００３４】
シミュレーション後、返されたパラメータが所望の動作パラメータ内にないときは、設計者は、マッピングされたモデルの任意の特性（ａｓｐｅｃｔ）を容易に変更することができる。すなわち、アーキテクチャコンポーネントの種類を変更し、アーキテクチャコンポーネントを追加又は除去し、様々なアーキテクチャコンポーネント間の接続を変更し、アーキテクチャに対する動作のマッピングを変更して、通信パターンを変更することができる。
【００３５】
更に、設計者は、マッピングされた設計で特定される性能の制約内で動作を実行できることを確かめるために、所望の全ての動作を連続的に実行することができる。この方法により、高レベルで繰返し設計プロセスが可能となり、コンポーネントレベルでの設計作業が減少し、設計プロセスが大幅に高速化される。
【００３６】
図３に示すように、送信元動作（ｓｏｕｒｃｅ ｂｅｈａｖｉｏｒ）２００は、送信先動作（ｄｅｓｔｉｎａｔｉｏｎ ｂｅｈａｖｉｏｒ）２１０を制御し、送信先動作２１０は、送信元動作２００が生成した命令又は情報を必要とする。図３に示すマッピングされた具体例において、送信元動作２００は、ＲＴＯＳ２２０によって実行され、送信先動作２１０は、ＡＳＩＣ２３０によって実行され、例えば圧縮初期化プロシージャ（ｃｏｍｐｒｅｓｓｉｏｎ ｉｎｉｔｉａｔｉｏｎ ｐｒｏｃｅｄｕｒｅ）では、圧縮初期化プロシージャはＲＴＯＳ２２０により初期化され、ＡＳＩＣ２３０によって実行される。送信元動作２００及び送信先動作２１０のマッピングは、実行される機能により定まり、ユーザにより決定される。
【００３７】
図４に示すように、アーキテクチャコンポーネント、この具体例ではＲＴＯＳは、複数のサービス、例えばＣライブラリ２５２、スケジューラ２５４、ミューテックス（Ｍｕｔｅｘ）２５６等を含んでいる。各サービスは、アーキテクチャコンポーネントによって実行される異なる機能に対応している。このようにして、各アーキテクチャコンポーネントは複数の機能に分割されて、アーキテクチャコンポーネント間でのサービスのモジュール性を増大し、再利用性を促進する。例えば、全てのＲＴＯＳによって使用されるスケジューリングアルゴリズムの数は、ほんの僅かな数しかない。ラウンドロビンスケジューリングのサービスは、一旦定義されると、多くのＲＴＯＳコンポーネントで使用される。サービスとその機能は、モデル化されるアーキテクチャコンポーネントを提供するベンダーにより提供されるアーキテクチャコンポーネントの仕様に基づいて定められている。
【００３８】
各サービスを、サービス宣言と１つ以上のサービス定義により、定義するとよい。サービス宣言は、Ｃ＋＋のヘッダファイルに１つ以上のＣ＋＋機能（Ｃ＋＋ ｆｕｎｃｔｉｏｎｓ）を宣言する。サービス定義は、ヘッダファイルで宣言したＣ＋＋機能の本体を提供する。この方法の利点として、Ｃ＋＋は、機能宣言と定義の分離をサポートした標準のオブジェクト指向言語である。
【００３９】
各アーキテクチャコンポーネント毎のサービス定義は、ライブラリ又は他のデータベースから選択され、このデータベースはアーキテクチャコンポーネントにより表されるコンポーネント製造業者により、又は業界主導の標準ライブラリにより提供され、あるいはシステムユーザにより生成される。この方法は、組み合わされ、整合されるアーキテクチャコンポーネントをモデル化する業界標準を促進し、更にはシステム設計者によるアーキテクチャ設計の開発を促進する。
【００４０】
各アーキテクチャコンポーネント毎のサービス定義２６０は、ライブラリ又は他のデータベースから選択され、このデータベースはアーキテクチャコンポーネントにより表されるコンポーネント製造業者により提供されるか、あるいはシステムユーザにより生成される。この方法の利点として、異なるベンダーからのコンポーネントは、ＡＰＩを整合することによってサービスを実行する限り、一緒に動作することができる。更に、ＩＰベンダーから定義が提供されているときには、複雑な詳細はサービス内部にカプセル化されているので、システム設計者は、その全てを理解する必要はない。この方法のもう１つの利点として、同一のインタフェースを保持したままで、多数のサービス定義を書き、性能精度を異なるレベルでモデル化することができる。システム設計者は、性能解析において、より高いレベルの精度に容易かつ徐々に進むことができ、設計は更に改良される。
【００４１】
ＲＴＯＳの具体例として、ＲＴＯＳは、例えば標準Ｃライブラリ（ＳｔａｎｄａｒｄＣＬｉｂｒａｒｙ）のサービスをサポートしている。このサービスは、「ｍｅｍｃｐｙ」及び「ｍｅｍｓｅｔ」に対する機能プロトタイプを宣言する。このサービスを実行することにより、これらの２つの機能の機能性及び性能の影響を定義する。
【００４２】
ｍｅｍｃｐｙ及びｍｅｍｓｅｔに対する機能プロトタイプは以下の通りである。
【００４３】
ｖｉｒｔｕａｌ ｖｃｃＡｄｄｒｅｓｓ＊ ｍｅｍｃｐｙ（ｖｃｃＡｄｄｒｅｓｓ＊ ｓ１， ｃｏｎｓｔ ｖｃｃＡｄｄｒｅｓｓ＊ ｓ２， ｓｉｚｅ＿ｔ ｎ， ｖｃｃＩｎｓｔａｎｓｅ＊） ＝ ０；
ｖｉｒｔｕａｌ ｖｃｃＡｄｄｒｅｓｓ＊ ｍｅｍｓｅｔ（ｖｃｃＡｄｄｒｅｓｓ＊ ｓ， ｉｎｔ ｃ， ｓｉｚｅ＿ｔ ｎ， ｖｃｃＩｎｓｔａｎｃｅ＊）＝０
更に追加の指針として、ｍｅｍｃｐｙ及びｍｅｍｓｅｔに対する好ましいＣ＋＋コードは以下の通りである。
／＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
名称：　ｍｅｍｃｐｙ
説明：　メモリアドレスｓ１からｓ２にｎバイトをコピーする。この実行は、アドレスがメモリ語境界にあることを想定する。何ら実際のデータは記憶又は読み出されるように計画されていない。メモリトランザクションは、性能のみの理由で、生成される。
【００４４】
リターン：　常にｓ１を返す。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊／
ｖｃｃＡｄｄｒｅｓｓ＊ＣＰＰ＿ＭＯＤＥＬ＿ＩＭＰＬＥＭＥＮＴＡＴＴＯＮ：：ｍｅｍｃｐｙ（ｖｃｃＡｄｄｒｅｓｓ＊ ｔｏ， ｃｏｎｓｔ ｖｃｃＡｄｄｒｅｓｓ＊ ｆｒｏｍ，
ｓｉｚｅ＿ｔ ｎ， ｖｃｃＩｎｓｔａｎｃｅ＊ ｉｎｓｔ）
｛
ｉｆ（ｎ ＝＝ ０）
ｒｅｔｕｒｎ ｔｏ；
Ｉｎｉｔ（）；
ｕｎｓｉｇｎｅｄ ｒｅｑＴｒａｎｓ ＝ ｎ／ｂｙｔｅｓＰｅｒＷｏｒｄ＿；
ｒｅｑＴｒａｎｓ ＝ （（ｒｅｑＴｒａｎｓ ＝＝ ０）？１：ｒｅｑＴｒａｎｓ）；
ｕｎｓｉｇｎｅｄ ｒｅｍＴｒａｎｓ ＝ ｒｅｑＴｒａｎｓ；
ｔｈｅＢｅｇｉｎ：
ｉｆ（ｒｅｍＴｒａｎｓ ＝＝ ０）ｇｏｔｏ ｔｈｅＥｎｄ；
｛
ｍｅｍＡｃｃｅｓｓ．ｒｅｆｅｒｅｎｃｅ（＊ｆｒｏｍ， ｂｙｔｅｓＰｅｒＷｏｒｄ＿， ｒｗＲｅａｄ，ｉｎｓｔ，ｔｒｕｅ）；
ｍｅｍＡｃｃｅｓｓ．ｒｅｆｅｒｅｎｃｅ（＊ｔｏ， ｂｙｔｅｓＰｅｒＷｏｒｄ＿， ｒｗＷｒｉｔｅ，ｉｎｓｔ，ｔｒｕｅ）；
｝
ｒｅｍＴｒａｎｓ−−；
ｇｏｔｏ ｔｈｅＢｉｇｉｎ；
ｔｈｅＥｎｄ：
ｒｅｔｕｒｎ ｔｏ；
｝
／＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
名称：　ｍｅｍｓｅｔ
説明：　アドレスｓのメモリの最初のｎバイトを値ｃ（符号なし整数値（ｕｎｓｉｇｎｅｄ ｃｈａｒ）に変換される）セットする。メモリトランザクションは、性能のみの理由で、生成される。
【００４５】
リターン：　常にｓを返す。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊／
ｖｃｃＡｄｄｒｅｓｓ＊ＣＰＰ＿ＭＯＤＥＬ＿ＩＭＰＬＥＭＥＮＴＡＴＴＯＮ：：ｍｅｍｓｅｔ （ｖｃｃＡｄｄｒｅｓｓ＊ ｓ， ｉｎｔ ｃ， ｓｉｚｅ＿ｔ ｎ，
ｖｃｃＩｎｓｔａｎｃｅ＊ ｉｎｓｔ）
｛
ｉｆ（ｎ ＝＝ ０）
ｒｅｔｕｒｎ ｓ；
Ｉｎｉｔ（）；
ｖｃｃＡｄｄｒｅｓｓ＊ ｔｏ ＝ ｓ；
ｕｎｓｉｇｎｅｄ ｒｅｍＴｒａｎｓ ＝ ｎ；
ｔｈｅＢｅｇｉｎ：
ｉｆ（ｒｅｍＴｒａｎｓ ＝＝ ０）ｇｏｔｏ ｔｈｅＥｎｄ；
｛
ｍｅｍＡｃｃｅｓｓ．ｒｅｆｅｒｅｎｃｅ（＊ｔｏ， ｂｙｔｅｓＰｅｒＷｏｒｄ＿， ｒｗＷｒｉｔｅ，ｉｎｓｔ，ｔｒｕｅ）；
｝
ｒｅｍＴｒａｎｓ−−；
ｇｏｔｏ ｔｈｅＢｉｇｉｎ；
ｔｈｅＥｎｄ：
ｒｅｔｕｒｎ ｓ；
｝
図５に示すように、通信パターンの具体例が、２つの動作ブロック３００、３１０間に示されており、この通信パターンは、適切なアーキテクチャコンポーネント、この具体例ではＲＴＯＳ３２０にマッピングされる。２つの動作ブロック３００、３１０間の通信の弧（ｃｏｍｍｕｎｉｃａｔｉｏｎ−ａｒｃ）は、適切なパターン、この具体例ではセマフォ（Ｓｅｍａｐｈｏｒｅ）パターン３３０にマッピングされる。セマフォパターン３３０は、通信パターン３３０の各端部にそれぞれ設けられた一対のパターンサービス３４０（「送信側（ｓｅｎｄｅｒ）」）、３５０（「受信側（ｒｅｃｅｉｖｅｒ）」）とから構成される通信プロトコルを実行する。「送信側」パターンサービス３４０は、ミューテックス（ｍｕｔｅｘ）のロック（ｌｏｃｋｉｎｇ）、データの書込、ミューテックスのロック解除（ｕｎｌｏｃｋｉｎｇ）、送信先動作に対するトリガ（ｔｒｉｇｇｅｒ）の送信をモデル化する。「受信側」パターンサービス３５０は、ミューテックスのロック、データの読出し、ミューテックスのロック解除をモデル化する。
【００４６】
パターンサービス３４０、３５０は、アーキテクチャコンポーネントに直接マッピングしないのが好ましい。代わりに、各パターンサービス３４０、３５０のマッピングは、アーキテクチャブロックに対する動作ブロックのマッピングにより暗示される。すなわち、パターンサービス３４０、３５０は、動作の一部を実行又は改良するので、動作ブロック３００又は動作ブロック３１０を実行するするアーキテクチャコンポーネントのリソース又はサービスを使用する。パターンサービスは、システムのアーキテクチャコンポーネントのサービスを用いる。この具体例において、ミューテックスのロック及びロック解除は、ＲＴＯＳ上のサービスによりサポートされる。
【００４７】
パターンサービスの実行は、アーキテクチャ関与子（ａｒｃｈｉｔｅｃｔｕｒａｌ ｐａｒｔｉｃｉｐａｎｔｓ）を介して、データを１つの動作から別の動作に伝搬する、ある種のシーケンスのイベントをもたらす。第１の動作は、データをその出力ポートに「通知（Ｐｏｓｔ）」し、第２の動作は、入力ポート上の「イネーブル（Ｅｎａｂｌｅｄ）」及び「値（Ｖａｌｕｅ）」の機能を用いて、この新たに送信されてきたデータをアクセスする。パターンは、「送信側」パターンと「受信側」パターンの組合せであり、通信の両側を実行する。「送信側」パターンサービスは、「通知」機能をインプリメントし、「受信側」パターンサービスは、「イネーブル」及び「値」の機能を実行する。パターンサービスは、パターン自体からは独立したサービスとして、他のパターンでも再利用できるようにするのが好ましい。パターンサービスのそれぞれは、プロトコルを完全には実行せず、代わりに、アーキテクチャによってサポートされているサービスを呼び出す。各通信プロトコルは層のスタック（ｓｔａｃｋ）である。最上位層は、既存のリソースの観点からは、プロトコルの機能を実行するのに必要な動作を特定する。より下位の層は、リソース（例えば、一般的な（ｇｅｎｅｒｉｃ）ソフトウェア機能のライブラリ、ＣＰＵ、バス）のタイミング動作をエミュレートする。
【００４８】
図６に示すように、第１の動作ブロック４００と第２の動作ブロック４１０を用いて、ユーザが定義した動作を実行する。第１の動作ブロック４００をＲＴＯＳアーキテクチャコンポーネント４５０にマッピングし、第２の動作ブロック４１０をＡＳＩＣアーキテクチャコンポーネント４６０にマッピングする。そして、第１の動作ブロック４００と第２の動作ブロック間の通信パターン４２０をレジスタマッピングされた（ｒｅｇｉｓｔｅｒ ｍａｐｐｅｄ）通信パターンとなるように決定し、これにより、送信側パターンサービス４３０と受信側パターンサービス４４０を共にレジスタマッピングされたパターンサービスとする。ＲＴＯＳアーキテクチャコンポーネント４５０は、ＣＰＵアーキテクチャコンポーネント４７０を制御するソフトウェアコンポーネントであるので、ＲＴＯＳアーキテクチャコンポーネント４５０とＡＳＩＣアーキテクチャコンポーネント４６０間の通信を容易にするために、ＣＰＵアーキテクチャコンポーネント４７０とバスアーキテクチャコンポーネント４８０も呼び出される。
【００４９】
通信パターンを開始するために、第１の動作ブロック４００の内部から通知機能（ｐｏｓｔ ｆｕｎｃｔｉｏｎ）４９０が呼び出される。通知機能４９０は、通信パターン４２０の送信側パターンサービス５００に入力を提供する。レジスタマッピングされた送信側は、ソフトウェアからＡＳＩＣ（これに第１の動作ブロック４１０がマッピングされる）上のレジスタへのデータ転送をモデル化する。この具体例では、第１の動作ブロック４１０がＡＳＩＣアーキテクチャコンポーネント４６０にマッピングされる。送信側パターンサービス４３０は、ＲＴＯＳアーキテクチャコンポーネント４５０の「標準Ｃライブラリ」サービスにより提供される「ｍｅｍｃｐｙ」機能を用いて、データ転送を実行する。各サービスは、サービス宣言のセットを用いることを宣言し、各サービスのサービス定義は、接続されたアーキテクチャコンポーネント上に存在しなければならない。送信側パターンサービス４３０は、送信元動作（４００）がマッピングされるアーキテクチャコンポーネントにより提供されるサービスを使用することができる。この場合、標準ＣライブラリはＲＴＯＳアーキテクチャコンポーネント４５０上にある。ＲＴＯＳアーキテクチャコンポーネント４５０は、標準Ｃライブラリサービスの実行を提供し、この場合、メモリアクセスインタフェースを使用してデータをＡＳＩＣアーキテクチャコンポーネント４６０上のレジスタに書き込む。ＲＴＯＳアーキテクチャコンポーネント４５０は、メモリアクセスサービスが割り当てられたプロセッサから提供されるサービスを利用できるので、メモリアクセスサービスの定義は、ＣＰＵアーキテクチャコンポーネント４７０上にある。ＣＰＵのメモリアクセスサービス５４０は、ＣＰＵのポート上にあるバスアダプタモデル５５０を使用する。バスアダプタモデル５５０は、バスアーキテクチャコンポーネント４８０上のバス裁定サービス（ｂｕｓ ａｒｂｉｔｅｒ ｓｅｒｖｉｃｅ）を使用し、一旦バスの所有権が許可されると、ＡＳＩＣアーキテクチャコンポーネント４６０のポート上の、ＡＳＩＣのバス通信をモデル化したサービスであるスレーブアダプタサービス５６０を使用する。スレーブイブアダプタサービス５６０は、ＡＳＩＣアーキテクチャコンポーネント４６０上のスレーブサービスを使用してデータをローカルレジスタに記憶する。レジスタマッピングされた受信側５８０は、通信パターンの他の側から、値及びイネーブル機能５９０を実行し、スレーブサービスを使用して書き込まれたデータを検索し、これにより、通信パターンプロトコルを完了する。
【００５０】
この方法の利点として、通信パターンは、モジュールサービス、その再利用可能なサービスを提供する各コンポーネントのアーキテクチャトポロジーに基づくものである。この方法は、システムレベルにおけるアーキテクチャ探査（ａｒｃｈｉｔｅｃｔｕｒａｌ ｅｘｐｌｏｒａｔｉｏｎ）のプロセスを提供する。
【００５１】
接続されたアーキテクチャコンポーネント上のパターンサービスの検索（ｓｅａｒｃｈｉｎｇ）は、コンポーネント間で単一の通信しかない場合には良好に働く。バスは、通信の多数対に対する媒体であるので、本質的にこの原理に反する。図７に示すように、動作６００をＲＴＯＳ６２０にマッピングし、動作６１０をＡＳＩＣ６６０にマッピングする。通信パターンは、ＲＴＯＳ６２０、ＣＰＵ６３０、バス６４０及びＡＳＩＣ６６０上のサービスを利用する。ＣＰＵ６３０上の汎用バスアダプタ６３５は、このメッセージはＡＳＩＣ２（６６０）上のスレーブアダプタ６６５に送り、他のメッセージはバス６４０上の他のスレーブ装置（ＡＳＩＣ６５０）に送るべきであるという区別を行う必要がある。各スレーブ装置は、同じスレーブアダプタをサポートしているので、この区別は、整合サービス定義（ｍａｔｃｈｉｎｇ ｓｅｒｖｉｃｅ ｄｅｆｉｎｉｔｉｏｎ）に対する検索に頼ることはできない。記号アドレス（ｓｙｍｂｏｌｉｃ ａｄｄｒｅｓｓ）を各バストランザクションと一緒に送って、正しいスレーブアダプタサービス向けであることを示すのが好ましい。この方法において、記号アドレスは、アーキテクチャのインスタンス名（ａｒｃｈｉｔｅｃｔｕｒｅ ｉｎｓｔａｎｃｅ ｎａｍｅ）と、オフセットとからなる。各スレーブアダプタは、そのスレーブアダプタサービスをインスタンス名によりバスレジストリに登録する。通信パターンがメッセージを送るとき、メッセージのアドレスを供給して、このアドレスをレジストリで直ちに参照することにより、適切なスレーブアダプタを見つけることができる。パターンの送信側及び受信側のサービスは、パターンプロトコルを完了するのに必要なメッセージシーケンスを、例えば、
Ｐａｔｈ：＜ｐａｔｈＮａｍｅ＞＜ｓｏｕｒｃｅＡｒｃｈＩｎｓｔ＞＜ｄｅｓｔＡｒｃｈＩｎｓｔ＞＜ｏｆｆｓｅｔｐａｒａｍ＞＜ｄａｔａＴｙｐｅ＞
のような経路仕様（ｐａｔｈ ｓｐｅｃｉｆｉｃａｔｉｏｎ）として宣言しなければならない。
【００５２】
各メッセージの送信元及び送信先は、動作がマッピングされるアーキテクチャコンポーネントであることもある。例えばレジスタマッピングされたパターンにおいて、送信側はＲＴＯＳ６２０からＡＳＩＣ２（６６０）にデータを送り、これらは、ｂｅｈ１とｂｅｈ２がマッピングされたアーキテクチャコンポーネントである。他の具体例では、第３のアーキテクチャコンポーネントがメッセージシーケンスに関与（ｐａｒｔｉｃｉｐａｔｅ）する。例えば、パターンがレジスタマッピングされた共有メモリにおいて、データは、先ずＲＡＭコンポーネントに書き込まれる。上述のｓｏｕｒｃｅＡｒｃｈＩｎｓｔ及びｄｅｓｔＡｒｃｈＩｎｓｔは、キーワードｖｃｃＡｒｃｈＯｆＳｒｃＢｅｈａｖ又はｖｃｃＡｒｃｈＯｆＤｅｓｔＢｅｈａｖを参照することができ、あるいはパターンサービスのパラメータを参照することができ、更にこのパラメータをパターンインスタンスにエクスポートして、エンドユーザがマッピングプロセス中に特定できるようにすることがことが好ましい。後者の具体例では、エンドユーザは、共有メモリパターンのそれぞれの使用（ｕｓａｇｅ）において、アーキテクチャ図（ａｒｃｈｉｔｅｃｔｕｒｅ ｄｉａｇｒａｍ）におけるメモリセットからメモリ関与子（ｍｅｍｏｒｙ ｐａｒｔｉｃｉｐａｎｔ）を選択する。上述のｄａｔａＴｙｐｅは、メッセージがネット上にデータを送信するか又は単なるトリガであるかを特定する。この情報は、転送されるデータサイズを正確に表しているので、これを用いてバスに対する性能の影響を求める。この方法の利点は、異なるアーキテクチャに亘ってパターンを再利用できる点である。
【００５３】
図８に示すように、動作はＲＴＯＳ７２０とＡＳＩＣ２（７８０）にマッピングされる。この具体例では、メッセージは、ＲＴＯＳ７２０からＢＵＳ１（７４０）を通り、バスブリッジ１（７６０）を介し、バス２（７７０）を経て最後にＡＳＩＣ２（７８０）に送られる。バスブリッジ７６０は、バス１（７４０）からバス２（７７０）へのバストランザクションの変換を容易にする。バスブリッジ７６０は、バス２上の全てのスレーブサービスをバス１（７４０）のレジストリに登録するのが好ましい。アーキテクチャインスタンス（アーキテクチャ図に亘って固有である）を用いることにより、バス２（７７０）上のスレーブサービスがバス１（７４０）上のスレーブサービスと競合しないことを保証する。この結果、記号アドレスはインスタンス名「ＡＳＩＣ２」を参照し、バス１（７４０）のレジストリには、バスブリッジ７６０のスレーブアダプタが登録されていることになる。また、バスブリッジ７６０は、第１のポート上にスレーブアダプタ７６５を、第２のポート上にマスタアダプタ７７５を有することが好ましい。バス１に接続されたスレーブアダプタ７６５がバス要求を受信すると、第２のポート上のバスマスタアダプタ７７５は、この要求をバス２（７７０）を介して再送信し、これにより、ＡＳＩＣ２（７８０）はこの転送を処理（ｈａｎｄｌｅ）する。バスブリッジは、２つ以上のポートを有することができ、各スレーブポートは、それがデータを再送信するマスタポートを、ポート属性（ｐｏｒｔ ａｔｔｒｉｂｕｔｅ）によって識別できることが好ましい。この方法の利点は、アーキテクチャ図をバスとブリッジの周りで容易に拡張又は再構成でき、システム全体の性能を最適化できる点である。
【００５４】
何らかのキーを用いて検索することができるパターンのデータベースであるプロトコルレジストリを用いることにより、動作コンポーネントを一旦マッピングした後、システム設計者に必要なことは、パターンのリストから選択することだけである。本明細書で説明する好ましいパターンは例示の目的のみであり、如何なる意味においても制限を意図していない。
【００５５】
通信のパターンは、送信側／受信側に対して選択した実現がＡＳＩＣ（以下、ＨＷという）であるか、個別のＳＷタスク（以下、ＳＷタスク間という）であるか、同じＳＷタスク内部（以下、ＳＷタスク内という）であるか、通信がイベントの存在（以下、トリガという）の送信のみを扱うか又はデータも含むかに依存して、基本的なグループに分類される。各グループについて可能なパターンの選択肢がある。
１）ＨＷ−ＨＷ：　　　　　　　　（ａ）直接接続、（ｂ）レジスタマッピングされた、（ｃ）共有メモリ
２）ＨＷ−ＨＷトリガ：　　　　　（ａ）直接接続、（ｂ）レジスタマッピングされた
３）ＨＷ−ＳＷ：　　　　　　　　（ａ）割込レジスタマッピングされた、（ｂ）割込共有メモリ、（ｃ）ポーリングレジスタマッピングされた、（ｄ）ポーリング共有メモリ
４）ＨＷ−ＳＷトリガ：　　　　　（ａ）割込、（ｂ）ポーリングレジスタマッピングされた、（ｃ）ポーリング共有メモリ
５）ＳＷ−ＨＷ：　　　　　　　　（ａ）レジスタマッピングされた、（ｂ）共有メモリ
６）ＳＷ−ＨＷトリガ：　　　　　（ａ）レジスタマッピングされた
７）ＳＷ−ＳＷタスク間：　　　　（ａ）保護なし、（ｂ）セマフォ保護、（ｃ）割込不可保護
８）ＳＷ−ＳＷタスク間トリガ：　（ａ）保護なし
９）ＳＷ−ＳＷタスク内：　　　　（ａ）保護なし
１０）ＳＷ−ＳＷタスク内トリガ：（ａ）保護なし
１１）ＳＷ−＞メモリ：　　　　　（ａ）ＳＷ直接メモリアクセス、（ｂ）ＳＷＤＭＡアクセス
１２）ＨＷ−＞メモリ：　　　　　（ａ）ＨＷＤＭＡ（ｂ）ＨＷＤＭＡアクセス
１３）ＳＷ−＞タイマ：　　　　　（ａ）ＳＷ仮想タイマ
１４）ＨＷ−＞タイマ：　　　　　（ａ）ＡＳＩＣ内部タイマ
パターンを分類する利点は、通信の弧を、弧のデータタイプのサイズのみならず、動作コンポーネントのマッピングに基づいて、各グループにカテゴリー化できる点である。ユーザが基本グループの各々についてデフォルトパターンを一旦選択すると、マッピングされていない弧は自動的にこれらのデフォルトに割り当てられるので、マッピングプロセスの時間を節約することができる。ユーザは、常に明示的にマッピングすることができ、又はマッピングを異なる選択に変更することができるが、デフォルトに大部分の時間がかかるはずである。
【００５６】
図９に示すように、第１の動作ブロック８００は、通信パターン８２０を用いてイベントを第２の動作ブロック８１０に送る。通信パターン８２０は、送信側にサービスＰ１、・・・、Ｐｎを、受信側にサービスＱ１、・・・、Ｑｎを有する。第１の動作ブロック８００における出力ポート８３０と第２の動作ブロック８１０における入力ポート８４０は、通信パターン８２０を開始し、終了する。通信パターン８２０の制御の流れは以下の通りである。第１の動作ブロック８００の遅延モデルが動作ブロック８００を呼び出し、動作ブロック８００がＰ１の機能によって実行される通知機能を呼び出す。Ｐ１は、Ｐ２の幾つかの機能を呼び出し、Ｐ２は、Ｐ３の幾つかの機能を呼び出し、以下同様である。通知の実行の終わりに、入力変更機能への呼出があり、この入力変更機能が所要の遅延でイベントを第２の動作ブロック８１０に通知する。その後、この通知により、第２の動作ブロック８１０の遅延モデルが起動され、この遅延モデルは、先ず、１番目の受信側パターンサービスＱ１を呼び出してＱ１のインスタンス内の値及びイベントのバッファを設定し、そして、Ｑ１の幾つかの機能を順次呼び出すイネーブル機能を呼び出す、第２の動作ブロック８１０の適切なサービスを呼び出す。Ｑ１は、Ｑ２の幾つかの機能を呼び出し、Ｑ２は、Ｑ３の幾つかの機能を呼び出し、以下同様にして、最後に、Ｅｎａｂｌｅｄ（）が結果を返す。この処理は、値及びオペレーションが追加されると、繰り返される。本明細書で述べる遅延モデルとは、スケジューリング、バッファリング等のための動作を実行するアーキテクチャコンポーネントでの遅延のことである。
【００５７】
図９に示すように、通信パターン８２０は、ネットではなく、ポート、例えばポート８３０、８４０に接続（ｂｏｕｎｄ ｔｏ）されるのが好ましい。多数のファンアウトを有するネットの場合には、各アーキテクチャコンポーネントからのネットは、全てのファンアウトに対して同じ通信パターンを使用するのが好ましいが、各送信先ポートを異なる通信パターンに関連付けてもよい。異なる通信パターンを用いるＮ個のファンアウトを有する通信ネットにおいては、動作ブロック内の通知機能に対する呼出は、各通信パターンのための通知機能の種々の実行に対するＮ回の呼出のシーケンスとして実行される。
【００５８】
これは、好ましくは、送信側の動作ブロックと送信側の１番目のパターンサービス（ｔｏｐ ｐａｔｔｅｒｎ ｓｅｒｖｉｃｅ）との間にコードの中間層を必要とする。すなわち、動作モデルから呼び出される通知機能の実行は、ファンアウト上でループとなり、各ファンアウトについて、そのファンアウトに関連するパターンによって使用されるサービスにより提供される通知機能の実行を呼び出す。シミュレーションにおいて、Ｃ＋＋動作ブロックは、サービス内の通知機能の実行を直接呼び出す。モデルから通知を受信したコード層がパターンにあり、コード層を各パターンに分解（ｕｎｒａｖｅｌ）する。この分解は、特定のサービスの内部で実行され、この特定のサービスは、実際のサービスのリストを、呼出を必要とするファンアウト当たり１サービスずつ受信する。このディスパッチャサービス（ｄｉｓｐａｔｃｈｅｒ ｓｅｒｖｉｃｅ）は、ネットの全てのファンアウトで１つの通信パターンが使用する場合には、停止（ｄｒｏｐｐｅｄ）される。
【００５９】
再び図９に示すように、シミュレーションにおける通知機能８３０から値機能８４０へのデータ伝送は、入力変更機能の呼出によって自動的に実行されるので、本質的に安全である。転送のより詳細なシミュレーションは、タイミングの側面を取り扱うのみであり、コンテンツではない。
【００６０】
以上、本発明の実施例、応用例及び効果について、図示し、説明したが、本明細書において説明及び図示した本発明の趣旨から逸脱することなく、多数の実施例、応用例及び効果が可能である。本発明は、特許請求の範囲の趣旨に基づいてのみ限定されるべきであり、上述した実施の形態、発明の詳細な説明、図面では制限されるものではない。例えば、上述したパターンは動作ポート間の通信を表す。動作は動作メモリやタイマと通信してもよい。更に、パターンはアーキテクチャプラットホームに基づき、これらの通信の性能への影響をモデル化するのにも利用できる。
【図面の簡単な説明】
【図１】
本発明の好ましい具体例に基づく設計プロセスを示すフローチャートである。
【図２】
本発明の好ましい具体例に基づく動作及び性能モデルを生成する方法を示すフローチャートである。
【図３】
本発明の好ましい具体例に基づくマッピングプロセイジャを示すブロック図である。
【図４】
本発明の好ましい具体例に基づく例示的アーキテクチャコンポーネントを示すブロック図である。
【図５】
本発明の好ましい具体例に基づく通信パターンを示すブロック図である。
【図６】
本発明の好ましい具体例に基づく、対応するパターン及びアーキテクチャコンポーネントサービスを有する通信パターンを示すブロック図である。
【図７】
本発明の好ましい具体例に基づく、バスを介した通信サービス間の相互作用を示すブロック図である。
【図８】
本発明の好ましい具体例に基づく、バスブリッジを介した通信サービス間の相互作用を示すブロック図である。
【図９】
本発明の好ましい具体例に基づく、サービスの性能モデル間の相互作用を示すブロック図である。

Claims (28)

1. ハードウェア及びソフトウェアの要素を備えた電子システムをモデル化する電子システムモデル化方法において、
   モデル化される電子システムによって実行される動作に対応した複数の動作を収集するステップと、
   アーキテクチャプラットホーム内部に含まれる複数のハードウェア及びソフトウェアのアーキテクチャコンポーネントを収集するステップと、
   上記収集された複数の動作の各々を、動作を実行する選択されたアーキテクチャコンポーネントにマッピングするステップと、
   上記動作を実行するために、アーキテクチャコンポーネント間で通信を要求する上記アーキテクチャコンポーネント間の通信パターンを認識して収集するステップと、
   上記動作間の各通信インスタンスを上記収集されたパターンのインスタンスにマッピングするステップとを有する電子システムモデル化方法。
2. 上記各アーキテクチャコンポーネントは、上記アーキテクチャコンポーネントの特定の機能にそれぞれ対応した複数のサービスを有することを特徴とする請求項１記載の電子システムモデル化方法。
3. 上記各サービスは、サービスのインタフェース及び本体に対応した宣言及び定義を有することを特徴とする請求項２記載の電子システムモデル化方法。
4. 上記各サービス定義は、他のサービス宣言を使用することを特徴とする請求項３記載の電子システムモデル化方法。
5. 上記アーキテクチャプラットホームを収集するステップは、上記複数のアーキテクチャコンポーネントのそれぞれに対して、性能モデルを選択するステップを有し、
   １つのアーキテクチャコンポーネントのサービスは、上記プラットホームにトポロジー的に接続されている他のサービスを使用することを特徴とする請求項１記載の電子システムモデル化方法。
6. 更に、上記ハードウェア又はソフトウェアの動作として収集された複数の動作の各動作を分割するステップを有する請求項１記載の電子システムモデル化方法。
7. 上記通信パターンを収集するステップは、動作がマッピングされたアーキテクチャコンポーネントによってサポートされる他のサービス宣言をそれぞれ使用する複数のサービスを有することを特徴とする請求項１記載の電子システムモデル化方法。
8. 更に、上記複数の動作の少なくとも１つの動作を変更し、又は他の動作と前にマッピングされたアーキテクチャコンポーネントとの関連付けを維持しながら、少なくとも１つの動作を新しい適切なアーキテクチャコンポーネントに関連付けるステップを有する請求項１記載の電子システムモデル化方法。
9. 更に、上記複数の動作の少なくとも１つの動作を新しいアーキテクチャコンポーネントに関連付けるとともに、前に収集された他の通信パターンを維持しながら、１つ以上の新しい通信パターンを認識して収集するステップを有する請求項１記載の電子システムモデル化方法。
10. 更に、前に収集された他の通信パターンを維持しながら、１つ以上のパターンマッピングの選択を変更するステップを有する請求項１記載の電子システムモデル化方法。
11. 更に、他のアーキテクチャコンポーネント間の関連付け及び変更されたコンポーネントとの間の通信パターンを維持しながら、上記プラットホーム内の複数のアーキテクチャコンポーネントの少なくとも１つのアーキテクチャコンポーネントを、コンポーネントの交換、パラメータ設定に対する調整又は性能モデルの異なる選択により、変更するステップを有する請求項１記載の電子システムモデル化方法。
12. 更に、前に収集された動作マッピング及び通信パターンを維持しながら、上記アーキテクチャに含まれる複数のアーキテクチャコンポーネントを変更するステップを有する請求項１記載の電子システムモデル化方法。
13. 更に、他のアーキテクチャコンポーネントにおけるサービスの再利用、他のアーキテクチャプラットホームにおけるアーキテクチャコンポーネントの再利用、他の電子システムにおけるアーキテクチャプラットホームの再利用から成るグループの中の少なくとも１つを行うステップを有する請求項１記載の電子システムモデル化方法。
14. 更に、アーキテクチャプラットホームを変更して、他の電子システムにおけるパターンを再利用するステップを有する請求項１記載の電子システムモデル化方法。
15. 更に、上記複数の動作を実行するときに、上記マッピングされた動作のアーキテクチャサービス及びオプションとして選択されたパターンサービスを用いて、上記電子システムの動作をシミュレーションするステップを有する請求項１記載の電子システムモデル化方法。
16. 上記アーキテクチャサービスの利用は、追加的な設計の決定がなされて性能モデルがより正確になされることにより、連続して改良されることを特徴とする請求項１５記載の電子システムモデル化方法。
17. ハードウェア及びソフトウェアのコンポーネントを備えた電子システムの動作モデルを生成する動作モデル生成システムにおいて、
    上記電子システムの一部として実行可能なコンポーネントにそれぞれ対応した複数のアーキテクチャコンポーネントと、
    ユーザが定めた動作を実行するために、上記アーキテクチャコンポーネント間で通信を要求するアーキテクチャコンポーネント間において、動作を実行するアーキテクチャコンポーネント間で通信するのに必要とされる介在アーキテクチャコンポーネント間の通信を含む通信パターンを生成する手段とを備える動作モデル生成システム。
18. 上記各アーキテクチャコンポーネントは、該アーキテクチャコンポーネントの特定の機能にそれぞれ対応した複数のサービスを有することを特徴とする請求項１７記載の動作モデル生成システム。
19. 上記アーキテクチャコンポーネント間の通信パターンを生成する手段は、上記アーキテクチャコンポーネント間の通信を実行するのに必要な複数のサービスの中から、適切なサービスを選択する手段を有することを特徴とする請求項１７記載の動作モデル生成システム。
20. 更に、上記複数の動作の各動作を適切なアーキテクチャコンポーネントに関連付ける手段を備える請求項１７記載の動作モデル生成システム。
21. 上記複数の動作の各動作を関連付ける手段は、予め定義されたアーキテクチャコンポーネントモデルのグループの中の１つであるアーキテクチャコンポーネントモデルを選択する手段を有することを特徴とする請求項２０記載の動作モデル生成システム。
22. 更に、上記電子システムによって実行される複数の動作の各動作をハードウェア又はソフトウェアの動作に分類する手段を備える請求項１７記載の動作モデル生成システム。
23. 更に、変更されていない他の動作と前にマッピングされたアーキテクチャコンポーネントとの関連付けを維持しながら、少なくとも１つの変更された動作を新しい適切なアーキテクチャコンポーネントに関連付ける手段を備える請求項１７記載の動作モデル生成システム。
24. 更に、上記複数の動作の少なくとも１つの動作を新しいアーキテクチャコンポーネントに関連付ける手段を備える請求項１７記載の動作モデル生成システム。
25. 更に、前に生成された他の通信パターンを維持しながら、上記新しいアーキテクチャコンポーネントと他のアーキテクチャコンポーネントとの間に１つ以上の新しい通信パターンを生成する手段を備える請求項２４記載の動作モデル生成システム。
26. 更に　上記複数の動作を実行するときに、上記生成された通信パターンを用いて、上記電子システムの動作をシミュレーションするシミュレーションアプリケーションを備える請求項１７記載の動作モデル生成システム。
27. ハードウェア及びソフトウェアのコンポーネントを備えた電子システムの動作間における通信の性能レベルモデルにおいて、
    １つ以上の送信先動作に転送されるデータを供給する第１の動作用のアプリケーションプログラミングインタフェースと、
    動作通信がマッピングされるパターンによってサポートされる複数のサービスの中に含まれ、通信プロトコルの性能をモデル化する上記アプリケーションプログラミングインタフェースを実行する第１のサービスと、
    上記第１の動作がマッピングされるアーキテクチャコンポーネントの記号によりサポートされる複数のサービス宣言の中に含まれ、上記第１のサービスにより使用されて、アーキテクチャプラットホームの性能をモデル化する１つ以上のアプリケーションプログラミングインタフェースと、
    上記アーキテクチャコンポーネントの性能モデルにより特定される複数のサービス定義の中に含まれるサービス定義によって、上記アーキテクチャコンポーネントの記号においてサポートされるサービス宣言と、
    第２のアーキテクチャコンポーネントによって実行可能な機能に対応する複数の第２のサービスの１つであり、上記電子システムの第１のコンポーネントにトポロジー的に接続され、該第２のアーキテクチャコンポーネントによって実行される機能を表す第２のアプリケーションインタフェースと、
    送信元動作から送信先動作への通信が完成するように、上記電子システムの性能レベルモデルの出力情報を受信する送信先動作用の入力アプリケーションインタフェースとを備える性能レベルモデル。
28. 更に、第３のアーキテクチャコンポーネントによって実行される機能に対応する複数のサービスの１つであり、上記電子システムの該第３のアーキテクチャコンポーネントによって実行される機能を表す第３のサービスと、
    トポロジー的に接続された上記第１及び第２のアーキテクチャコンポーネント間における通信動作のモデルである第１のアプリケーションプログラミングインタフェースと、トポロジー的に接続された上記第２及び第３のアーキテクチャコンポーネント間における通信動作のモデルである第２のアプリケーションプログラミングインタフェースとを含む少なくとも１つのアプリケーションプログラミングインタフェースとを備える請求項２７記載の性能レベルモデル。

Images