JP2003534603A

JP2003534603A - オブジェクト指向を用いた電子回路設計のモデリングとシミュレーション環境を高める方法及び装置

Info

Publication number: JP2003534603A
Application number: JP2001587278A
Authority: JP
Inventors: ジャン、フランソワ、デュボック; フレデリック、マレ; フェルナン、ボエリ
Original assignee: Philips Electronics NV
Current assignee: Koninklijke Philips NV
Priority date: 2000-05-24
Filing date: 2001-03-22
Publication date: 2003-11-18
Also published as: WO2001090961A2; EP1290588A2; WO2001090961A3

Abstract

(57)【要約】装置、プログラムプロダクト及び方法が、特にオブジェクト指向を用いたモデリング及びシミュレーションの領域で、コンピュータ上で電子回路設計のモデリング及びシミュレーションを高める。多重化コミュニケーションポート１３０が提供され、それは、そのポート１３０に導かれた１つのイベントに応じて多数の信号に対する値の伝送をサポートする。しがたって、論理的に合わせられた多数の信号パスは１つの論理パスに一緒にされる。さらに、動的な命令デコーダの生成１６０が提供され、その結果、処理システムモデルによって実行されることのできる命令を定める命令定義が、命令の実行をシミュレートする処理システムモデルに対して命令デコーダ回路コンポーネント１５０’を構成するのに利用される。

Description

【発明の詳細な説明】

【０００１】本発明の技術の分野本発明は、集積回路及びその他の電子回路の設計及びモデリングに関する。よ
り詳しくは、本発明は、プロトタイピング評価及び性能評価のための集積回路及
びその他の電子回路を、ソフトウェアに基づいて設計及びモデリングすることに
関する。

【０００２】本発明の背景半導体製造技術が進歩するにつれて、それを取り入れる集積回路及び電子回路
の設計者は、１つの集積回路デバイス、すなわちちチップに、ますます多くの機
能を統合することが可能になった。かつてはサーキットボードあるいはモジュー
ルに電気的に互いに接続されるいくつかの集積回路が必要であった電子的な設計
は、現在では１つの集積回路に統合され、それによってパフォーマンスが向上し
コストは低下している。

【０００３】しかしながら、回路の複雑さが増すにつれ、設計プロセス及び回路設計のテス
トプロセスはますます複雑になり時間がかかるようになってきている。その結果
、コンピュータは、設計及び回路設計のテストを自動化するのにますます重要に
なってきた。

【０００４】通常、電子回路設計はまず比較的高度に抽象化されて定められる。これは、し
ばしばどんなソフトウェアデザインツールをも用いずに行われる。基本的な実行
機能や所望の性能はしばしば設計者のチームによって決定される。ひとたび高レ
ベルの仕様が決定されると、その設計からなるハードウェアの定義がＶＨＤＬや
Ｖｅｒｉｌｏｇのようなハードウェア記述言語を用いて開発される。そのハード
ウェアの定義に基づいてロジックシミュレーションがしばしばその設計の機能を
確認するために実行される。ひとたびその機能性が確認されると、その設計にに
よる個々の回路コンポーネントの物理的なレイアウトがなされる。これは、しば
しば統合ツール(synthesis tool)を用いて行われる。さらに詳細なシミュレーシ
ョンとタイミング分析が、統合された設計において次に実行され、その設計に伴
ういかなる詳細な問題をも発見し修正する。ひとたびその設計が確認されるとそ
の設計は、通常は製造部品の製造及び最終テストの準備に付される。

【０００５】設計の再利用や抽象化のかなりの進歩により、開発者は、新しい設計の開発に
おいて先にある設計を活用することができるようになってきた。先に設計されテ
ストされた回路コンポーネントは、集積回路の設計を定めるのに、例えば修正さ
れ及び（あるいは）共に組み立てられる。したがって、開発者が、スクラッチか
らそれぞれの設計を始める必要を取り除くことができる。さらに、再利用できる
回路コンポーネントが既にテストされ、しばしば特定の機能に最適化されている
ので、統合化やシミュレーションに伴う多くの困難を回避することができる。

【０００６】再利用できる回路コンポーネントにカプセル化される機能はさらに増えてきた
。再利用できる回路コンポーネントはかつては、マルチプレクサやレジスタのよ
うな簡易なロジックコンポーネントに代表される簡易な回路ブロックに制限され
ていたが、エンタイア(entire)プロセッサのコア、メモリ、デジタルシグナルプ
ロセッサのコア等の比較的複雑な回路コンポーネントを組み込んだより進歩した
コンポーネントが開発されてきた。

【０００７】抽象化や設計の再利用は、かつてないほどに多い複雑な回路設計に際して合理
的な開発サイクルを維持するのに共に重要な一因である。それにもかかわらず技
術の変化が速く、集積回路の設計に対する製品化までの時間は追い立てられ続け
ており、したがって、設計の自動化におけるさらなる進歩が必要となっている。

【０００８】しばしば設計をやり直して修正した設計を再テストする努力が変化によってさ
らに必要とされるように、開発サイクルは、機能や手段(implementation)に対す
る変化によってかなり影響を受ける。その結果、開発プロセスにおいてはできる
だけ早く基本的な設計パラメータを評価し決定するのがしばしば極めて望ましい
。

【０００９】設計パラメータを早く評価するのをサポートするために、オブジェクト指向を
用いたラピッド・プロトタイピング(object-oriented rapid prototyping)が、
集積回路の設計、特に、内蔵されたプロセッサのコア、デジタルシグナルプロセ
ッサ（ＤＳＰ）のコア、メモリシステム等のような複雑な特徴を組み込んでいる
デジタルアーキテクチャの設計において早いプロセスでの評価を提供するために
提案されている。オブジェクト指向を用いた高速なプロトタイピングにより、回
路コンポーネントは、オブジェクト指向のソフトウェア言語を用いてモデル化さ
れる。抽象化やカプセル化、再利用、継承、多態性のような伝統的なオブジェク
ト指向の概念は回路コンポーネントのライブラリを構築するのに用いられる。回
路コンポーネントは、究極的には１つ以上の総称コンポーネントオブジェクトに
基づけられる。それ故に、ある設計を創案するために、現存するコンポーネント
が共に集められ、且つ（あるいは）、新たなコンポーネントが、現存するコンポ
ーネントの機能を修正あるいは拡張することによって組み立てられる。

【００１０】オブジェクト指向を用いたラピッド・プロトタイピング環境や、他のモデリン
グ及びシミュレーション環境は、設計プロセスにおいて極めて早く新しい回路設
計の高レベルな仕様を評価し決定する能力を、回路の開発者に提供すると思われ
、したがって、多くの場合において開発サイクルを短くするのに役立つ。しかし
ながら、オブジェクト指向を用いたモデリングやシミュレーションを実行するた
めに提案されているソフトウェアのツールは機能において制限されている。この
ように、電子回路設計についての開発等をさらに加速するために、オブジェクト
指向を用いたモデリングやシミュレーションの概念を実行し向上させるソフトウ
ェア自動化ツールに対する技術の必要性がある。

【００１１】本発明の要約本発明は、特にオブジェクト指向を用いたモデリング及びシミュレーション
の領域で、コンピュータ上で電子回路設計のモデリング及びシミュレーションを
高める装置、プログラムプロダクト及び方法を提供することによって、従来技術
に関連するこれらの及びその他の問題を検討する。

【００１２】本発明の１つの特徴に関連して、モデリング及びシミュレーションは、電子設
計モデルの回路コンポーネント内での多重化ポートに対するサポートを介して高
められる。本発明にかかる多重化ポートは、ポートに導かれたイベントに応答し
て多数の信号に対する値の伝送をサポートする。したがって、論理的に結合した
多数の信号パスは１つの論理パスに一緒にされる。他の利益として、モデルが、
コンピュータ上でグラフィカルユーザーインターフェース環境で表されるとき、
多重化ポートを表す１つの論理パスは、そのポートを介して伝送されることので
きる個々の信号に対する分離パスの代わりに表示され、それによって、表示の散
乱が減り、モデルの理解が容易なる。

【００１３】例として、本発明のこの特徴にかかる方法において、電子回路設計が、それぞ
れ第１及び第２のポートを有する第１及び第２のオブジェクト指向の回路コンポ
ーネントからモデルを構成し、第１及び第２の回路コンポーネントを第１及び第
２のポートを介して互いにインターフェースをとることによって、コンピュータ
上でモデル化される。第１及び第２のポートは、第１及び第２のポートの少なく
とも１つに導かれたイベントに応答して、第１の信号に対する第１の値と、第２
の信号に対する第２の値との両方を、第１及び第２のポート間で伝送するように
構成されている。

【００１４】本発明の別の特徴に関連して、電子回路設計のモデリング及びシミュレーショ
ンは、電子回路設計を表す処理システムモデル内で実行される命令をデコードす
るのに、動的に生成される命令デコーダ回路コンポーネントを提供することによ
って高められる。本発明に係る命令デコーダ回路コンポーネントの生成は、処理
システムモデルによって実行されることのできる命令を定める命令定義を少なく
とも１つ受け取ることを含む。さらに、命令の実行をシミュレートするための処
理システムモデルに対して命令デコーダ回路コンポーネントを構成するために、
命令定義を処理することを含む。

【００１５】本発明を特徴づけるこれらの及びその他の利点及び特徴は、ここに添付された
クレームに述べられている。しかしながら、本発明、及びその使用を介して得ら
れる利点及び目的をより理解するために、図面及び付加された説明が参照される
べきであり、そこにおいては本発明の典型的な実施例が述べられている。

【００１６】詳細な説明ハードウェア及びソフトウェア環境図面に示すように種々の図面の全体にわたりパーツが符号により示されている
。図１は、本発明にかかるオブジェクト指向を用いたモデリング及びシミュレー
ションを実行するのに用いるコンピュータシステム１０を示す。コンピュータシ
ステム１０は、１つ以上のクライアントコンピュータ１２，１４，２０（例えば
、デスクトップあるいはＰＣベースのコンピュータ、ワークステーション等）を
含むネットワークコンピュータシステムとして示されており、クライアントコン
ピュータ１２，１４，２０はネットワーク１８を介してサーバ１６（例えば、Ｐ
Ｃベースのサーバ、ミニコンピュータ、ミッドレンジコンピュータ、メインフレ
ームコンピュータ等）に接続されている。ネットワーク１８は実際には任意のタ
イプのネットワーク相互接合を表しており、ローカルエリアネットワーク、ワイ
ドエリアネットワーク、ワイヤレスネットワーク、パブリックネットワーク（例
えばインターネット）を含む。さらに、任意の数のコンピュータ及び他のデバイ
ス、例えばマルチプルサーバが、ネットワーク１８を介してネットワーク接続さ
れる。

【００１７】クライアントコンピュータ２０は、コンピュータ１２，１４と同様に、中央演
算処理装置（ＣＰＵ）２１、コンピュータディスプレイ２２のような多くの周辺
コンポーネント、ストレージデバイス２３、プリンタ２４、種々の入力デバイス
（例えばマウス２６、キーボード２７）、を特に有する。サーバコンピュータ１
６は、周知なように、より優れた処理性能及びストレージキャパシティを通常備
えてはいるが同様に構成されている。

【００１８】図２は、本発明にかかる装置３０に対する模範的なハードウェア及びソフトウ
ェア環境を別の手段にて示す。本発明の目的に対して、装置３０は、実際には、
任意のタイプのコンピュータ、コンピュータシステムあるいは他のプログラム制
御できる電子デバイスを表しており、クライアントコンピュータ（例えば図１の
コンピュータ１２，１４，２０と同様なもの）、サーバコンピュータ（例えば図
１のサーバ１６と同様なもの）、ポータブルコンピュータ、ハンドヘルドコンピ
ュータ、埋め込み式コントローラ等を含む。装置３０は、図１に示されるような
ネットワークに接続されても、あるいは代わりにスタンドアロンデバイスでもよ
い。装置３０は以下において“コンピュータ”として言及される。とはいえ、“
装置”は、本発明に係る他の適当なプログラム制御可能な電子デバイスを含むと
いうことが理解されるべきである。

【００１９】コンピュータ３０は、通常、メモリ３２に接続された少なくとも１つのプロセ
ッサ３１を有する。プロセッサ３１は１つ以上のプロセッサ（例えばマイクロプ
ロセッサ）を表し、メモリ３２は、コンピュータ３０のメインストレージを構成
するランダムアクセスメモリ（ＲＡＭ）の他、キャッシュメモリ、不揮発性ある
いはバックアップメモリ（例えばプログラマブルメモリあるいはフラッシュメモ
リ）、読み出し専用メモリ等を表す。さらに、メモリ３２は、コンピュータ３０
の他のどこかに物理的に置かれたメモリストレージ、例えばプロセッサ３１の任
意のキャッシュメモリの他、仮想メモリとして用いられる任意のストレージキャ
パシタを含むと考えられる。これは、例えばマスストレージデバイス３５にスト
レージされるような、あるいはネットワーク３６を介してコンピュータ３０に接
続された別のコンピュータにストレージされるようなものである。

【００２０】さらに、コンピュータ３０は、通常、多くの入力と出力を外部と情報を伝達す
るために受け取る。ユーザーやオペレータとのインターフェースのためにコンピ
ュータ３０は通常１つ以上のユーザーインプットデバイス３３（例えば特にキー
ボード、マウス、トラックボール、ジョイスティック、タッチパッド及び（ある
いは）マイクロフォン）やディスプレイ３４（例えば特にＣＲＴモニタ、ＬＣＤ
ディスプレイパネル、及び（あるいは）スピーカー）を含む。

【００２１】追加のストレージのために、さらにコンピュータ３０は、１つ以上のマススト
レージデバイス３５、例えば特にフロッピー（登録商標）ドライブあるいは他の
リムーバブルディスクドライブ、ハードディスクドライブ、ダイレクトアクセス
ストレージデバイス（ＤＡＳＤ）、オプティカルドライブ（例えばＣＤドライブ
、ＤＶＤドライブ等）及び（あるいは）テープドライブを含む。さらにコンピュ
ータ３０は、１つ以上のネットワーク３６（例えば特にＬＡＮ、ＷＡＮ、ワイヤ
レスネットワーク及び（あるいは）インターネット）とのインターフェースを含
み、ネットワークに接続された他のコンピュータとの情報の伝達を可能に構成さ
れている。通常、コンピュータ３０は、周知なように、コンポーネント３２，３
３，３４，３５，３６のそれぞれとプロセッサ３１との間に適当なアナログイン
ターフェース及び（あるいは）デジタルインターフェースを含んでいることが理
解されるべきである。

【００２２】コンピュータ３０は、オペレーティングシステム４０の制御の下で動作し、種
々のコンピュータソフトウェアアプリケーション、コンポーネント、プログラム
、オブジェクト、モジュール、データストラクチャ等を実行し、あるいはそうで
なければこれらに依存する（例えば、とりわけ、シミュレータ４２、コンパイラ
４４、ユーザーインターフェース４６、コンポーネントライブラリ４８、を組み
込んだシミュレーション環境４１をモデリングするラピッド・プロトタイピング
）。さらに、種々のアプリケーション、コンポーネント、プログラム、オブジェ
クト、モジュール等は、ネットワーク３６を介してコンピュータ３０に接続され
た別のコンピュータにおける１つ以上のプロセッサで、例えば、分散コンピュー
ティング環境やクライアント−サーバコンピューティング環境で実行される。そ
れによって、コンピュータプログラムの機能を実行するのに必要とされるプロセ
シングはネットワーク上の多くのコンピュータに割り当てられる。

【００２３】通常、本発明の実施例で実行されるルーチンは、オペレーティングシステムの
一部として、あるいは、特定のアプリケーション、コンポーネント、プログラム
、オブジェクト、モジュールもしくは命令の連続として実施されようとも、ここ
において“コンピュータプログラム”あるいは単に“プログラム”と呼ばれる。
コンピュータプログラムは通常１つ以上の命令を有し、命令は、コンピューター
内の種々のメモリやストレージデバイスにいろいろな時にとどまり、しかも、コ
ンピュータ内の１つ以上のプロセッサによって読み込まれ実行されるときに、コ
ンピュータに、本発明の種々の特徴を実施するステップあるいはエレメントの実
行の必要なステップを実行させる。さらに、本発明は、完全に動作しているコン
ピュータ及びコンピュータシステムの状況において述べられるが、当業者ならば
、本発明の種々の実施例が種々の形態におけるプログラムプロダクトとして割り
当てられることが可能であり、本発明は、その割り当てを実際に実行するのに用
いられる信号担媒体（signal bearing media)の特定のタイプに関係なく等しく
適用されることが理解されよう。信号担媒体の例は、特に揮発性あるいは不揮発
性メモリデバイス、フロッピーディスク及び他のリムーバブルディスク、ハード
ディスクドライブ、磁気テープ、オプティカルディスク（例えばＣＤ−ＲＯＭや
ＤＶＤ等）のような記録可能型メディアや、デジタルとアナログの伝達をリンク
するようなトランスミッションタイプメディアを含むがこれに制限されない。

【００２４】さらに、この後に述べられる種々のプログラムは、本発明の特定の実施例でそれ
らが実行されるアプリケーションに基づいて識別される。しかしながら、以下の
任意の特定のプログラム用語は単に便宜上用いられるだけであり、したがって本
発明は、そのような用語によって識別され及び（あるいは）意味される任意の特
定のアプリケーションにおいてのみ用いることに制限されないということが理解
されるべきである。

【００２５】当業者であれば、図１及び２に示される模範的な環境が本発明を制限するもの
ではないことが理解されよう。さらに言えば、当業者であれば、他の代わりのハ
ードウェア及び（あるいは）ソフトウェア環境が本発明の範囲から外れることな
く用いられることが理解されよう。

【００２６】高められたオブジェクト指向を用いたラピッド・プロトタイピング環境図３は、本発明に係るオブジェクト指向を用いたモデリング及びシミュレーシ
ョンを組み込んだラピッド・プロトタイピング環境４１を実行するための主要な
コンポーネントを示す。本実施例において、ラピッド・プロトタイピング環境４
１は、サンマイクロシステムのＪａｖａプログラミング言語のようなオブジェク
ト指向プログラミング言語を用いて実行される。ラピッド・プロトタイピング環
境は他のオブジェクト指向プログラミング言語、例えばｃ＋＋、Ｓｍａｌｌｔａ
ｌｋ等においても実施可能であることが理解されよう。さらに、本発明は、ラピ
ッド・プロトタイピング以外のモデリング及び（あるいは）シミュレーションの
アプリケーションにおいても適用できることが理解されよう。それ故に、本発明
はここにおいて述べられる特定の実施に制限されない。

【００２７】図３に示されるように、ラピッド・プロトタイピング環境４１において、Ｊａ
ｖａベースのシミュレータ４２がＪａｖａコンパイラ４４、ユーザーインターフ
ェース４６、コンポーネントライブラリ４８と相互に作用する。さらにユーザー
インターフェース内には、アーキテクチャウィンドウコンポーネント５０とデバ
ッグウィンドウコンポーネント５２がある。

【００２８】環境４１におけるモデリング及びシミュレーションの機能の主要な管理はＪａ
ｖａシミュレータ４２によってなされる。新たなあるいは現存する集積回路の設
計すなわちアーキテクチャのモデリングを開始するために、Ｊａｖａシミュレー
タ４２はアーキテクチャウィンドウコンポーネント５０を呼び出し、シミューレ
トされる所望のアーキテクチャを示すモデルを構築する開発者と互いにやりとり
するためのユーザーインターフェースを提供する。

【００２９】アーキテクチャウィンドウはコンポーネントライブラリ４８から回路コンポー
ネントを引き出し、そのコンポーネントを共に組み立て及び（あるいは）そのコ
ンポーネントのインスタンスを修正して、コンポーネントライブラリに戻される
（store back)される新しいコンポーネントを生成させることができる。オブジ
ェクト指向のフレームワークに基づいて、ライブラリにおけるそれぞれの回路コ
ンポーネントは、通常、チャイルドコンポーネントのコレクションによって表さ
れる。これらのコンポーネントの間のリンクはライブラリによってＪａｖａコン
パイラ４４に与えられ、アーキテクチャウィンドウ５０を介してユーザーによっ
て生成させられたコンパイルコマンドに応じて、コンパイルされたモデルが生成
させる。それ故に、このコンテクストにおける回路コンポーネントは任意のデー
タストラクチャ、ソースコード、インタープリタコード及び（あるいは）実行可
能プログラムによって表され、電子回路あるいはそれらの一部の動作を機能的に
モデリングするのに役立つことが理解されよう。

【００３０】いったんシミューレートされるモデルがＪａｖａコンパイラ４４によってコン
パイルされると、シミュレーションがＪａｖａシミュレータ４２によってモデル
上で走らされることが可能になる。モデルをコンパイルすることに加えて、さら
にＪａｖａシミュレータ４２は、どんな情報が観測されるべきかを示すシミュレ
ーションパラメータのみならず、所望の命令セットをシミュレートするのに適切
な命令デコーダ情報を受け取ることができる。このシミュレーションパラメータ
に基づいてデバッグ情報がシミュレーションの間に生成され、ユーザーに表示す
るためのデバッグウィンドウコンポーネント５２に出力される。

【００３１】本実施例において、環境及び開発コンポーネント（例えばシミュレータ４２や
ウィンドウ５０，５２）や、シミュレートされるモデルを表す回路コンポーネン
ト（例えばコンポーネントライブラリ４８の内部にある）の両方ともＪａｖａプ
ログラミング言語を用いて実施され、通常のＪａｖａベースのプラットフォーム
においてコンパイルされ解釈される。しかしながら、他のプログラミング環境が
、非オブジェクト指向のプラットフォームを含めて、基本的なモデリング及び（
あるいは）シミュレーション環境を実行するのに用いられることが理解されよう
。

【００３２】回路コンポーネントのオブジェクト指向モデリング上述したように、環境４１で開発されたモデルは、そのモデルの基本的な機能
を表す多くの回路コンポーネントを共に組み合わせることによって主として構成
される。本実施例においてモデルで用いられる全てのコンポーネントは総称コン
ポーネントモデル、例えば図４のＵＭＬ表記で表される総称コンポーネントモデ
ル６０に基づいている。

【００３３】モデル６０は、コンポーネント間の最小限のインターフェースを示しており、
マテリアルコンポーネント６２と、アクティブコンポーネント６４及びマテリア
ルコンテナ６６との間で逐次因果モデルコンテナコンポーネントを構成している
。マテリアルコンテナは、マテリアルコンポーネントと信号とをカプセル化する
ためにのみ役立つだけであり、マテリアルコンポーネントに対して構造記述を許
容する。アクティブコンポーネントは、ここではサービスとして言及される、コ
ンポーネントの振る舞いの特徴を取り込んでいるコンポーネントを表す。

【００３４】マテリアルコンポーネントは、信号７０を他のコンポーネントに通過させるの
に用いられる１つ以上のサービスポート６８を介してお互いにインターフェース
が取られており、接続されたポート間で伝達されるべき実データを特徴づける値
７２を有している。値は、特定のデータタイプ、例えば命令、整数、イベント、
ビット値、ハードウェアレベル等に制約されるが、総称モデルレベルでは値によ
って特定されるデータのタイプはタイプが特定されていない。

【００３５】この総称モデルに基づいて回路コンポーネントが、そのモデルを拡張すること
によって、且つ、そのコンポーネントの振る舞い性能をモデリングするためにポ
ートに関連づけられたサービスを定めることによって開発される。さらに、回路
コンポーネントは構造的にチャイルドコンポーネントを組み込むように定められ
ており、チャイルドコンポーネントはその親コンポーネントによってアクセスさ
れることのできる機能、即ちサービスを定める。それ故に、回路コンポーネント
は、統合されたサービス及びそれによってカプセル化されたチャイルドコンポー
ネントに依存して、構造及び振る舞いの両方で表される。

【００３６】例えば、図５は、符号８４で示される振る舞いとインターフェースの取られた
複数のポート８２を組み込んだロード／ストアレジスタ８０を示す。その振る舞
いは、構造的手段あるいは機能的手段のいずれかで表される。

【００３７】例えば、図６に示されるように、同じロード／ストアレジスタの構造的表現９
０が示されている。図５のポート８２に対応するポート９２は、ロード／ストア
レジスタの基本的な振る舞いを表す１組のレジスタ９４とインターフェースが取
られて示されている。それぞれのレジスタコンポーネント９４は、ロード／スト
ア機能を実行するためにロード／ストアレジスタによって利用されるより要素的
なコンポーネントを表している。特に、レジスタコンポーネント９４のゲートポ
ートは、レジスタ９０のロード及びストアポート９２に接続されており、ロード
／ストアコンポーネントに通過させられるロード及びストア信号は、ロード／ス
トアレジスタに対して所望の動作上の振る舞いを実行するための適切なレジスタ
９４にルーティングされる。

【００３８】模範的なロード／ストアレジスタの振る舞いを表す代わりの手段は、機能的な
手段によるもの、例えばＪａｖａプログラミング言語によるものがある。例えば
下記のテーブルＩは、図５のロード／ストアレジスタに対するＪａｖａのソース
コードを表す。

【００３９】

【表１】前述の説明において、Edge Component class は material component classか
ら継承しており、コンポーネントのポートの１つにエッジイベント（edge event
）が生じたときに起こる振る舞いを説明している。Edge Component classで、そ
れぞれのポートは、異なるタイプのイベント、例えば無反応（insensitive）,立
ち上がりエッジへの反応（sensitive on a rising edge）,立ち下がりエッジへ
の反応（sensitive on falling edge）等への反応に割り当てられている。種々
のaddPort()メソッドは、コンポーネントの異なるタイプのポートを登録するだ
けでなく、そのポートに(setService()メソッドを介して）サービスを関連づけ
るように提供されている。ポート名が、方向表示（例えば、ＬＥＦＴ、ＲＩＧＨ
Ｔ、ＴＯＰ、ＢＯＴＴＯＭ）と共にそれぞれのaddPORT()に与えられる。それは
、コンポーネントのアイコン表示で、ポートがどこに表示されるべきかを示すた
めに用いられる。

【００４０】イベントが、EdgeComponentコンポーネントのセンシティブなポートに発生し
たときに、サービス（即ち、setService()コールで特定されたメソッド）が実行
される。それ故に、センシティビティは、コンポーネントをリアクトにするのに
、即ち付与されたサービスを実行するのに必要とされるイベントの列を表す。い
くつかのサービスの組み合わせがコンポーネントの振る舞いを構成する。

【００４１】コンポーネントの実行で利用されるのに適切なサービスの例として、上記のテ
ーブルＩに示されるロード及びストアサービスが、それぞれ priority()メソッ
ドと emit()メソッドを利用している。priority()メソッドは、競合解消のため
に、異なるサービスに対して相対優先度(relative priority)を定めている。emi
t()メソッドには、ドライブするポートの名が、そのポートにドライブされる信
号値（ここでは、read()メソッドを介してアクセス可能な、そのコンポーネント
の別のポートの状態(current state））とともに与えられている。

【００４２】通常、タイプはポートに結びつけらず、そのようなものなのでポート間のリン
クに制約はなく、それ故に、それぞれのポートとそれぞれのコンポーネントは任
意のデータタイプを受けとる。それぞれのデータは抽象クラス値(abstract clas
s value)から継承しており、別のタイプをマッチするためにミュートする能力を
有しており、それによってコンポーネントの再利用を高めている。

【００４３】例として、ロード／ストアレジスタはいくつかの制約を有している。“ＩＮ”
ポートはいくつかの値を供給(serve)するためにプロデューサを必要としており
、だから“ＩＮ”ポートは、いくつかのデータを出す潜在的プロデューサのない
データバスに接続されることはできない。同様に、システムはそのロードを推定
し、ストアポートはいくつかのレベル値を提供できるポートに接続されなければ
ならない。なぜならそれらはエッジに反応するポート(edge sensitive ports)だ
からである。これは、構造的な確認の第１のステップである。

【００４４】さらに、継承とサブタイピング(subtyping)は値を説明すのに用いられるので
、２以上の演算子が特定の演算に適用される。例として、算術演算論理装置(ALU
)が、２つの入力データポート、１つの入力制御ポート、２つの出力ポートを有
しているコンポーネントとしてとして定められており、結果値及びフラグ結果値
(flag resut)を表す。実際にドライブされるデータタイプが何であれ、そのコン
ポーネントは要求される演算を計算しなければならない。例えば、加算は、整数
加算、浮動加算、文字列の連結あるいはその他のものとして見ることができる。
データは、定められたサブタイプ関係(sub-type relation)に基づいてミュート
する能力を有しているべきである。さらに、正しい演算子はシミューレーション
において動的に推測されるべきである。これは、パラメータ要求にマッチする最
も低い演算子を選択するサブタイプツリーを構文解析することによって実行され
る。もし、推測されうる演算子が無ければ、“ＮＯＮＥ”値が計算され、メッセ
ージが開発者に送られる。これは、記述の完成を必要とする関係のある演算子に
対して適合させられる記述が欠如することによりなされる。これはさらに、いく
つかのデータパスは間違っており正されるべきであるということを示している。

【００４５】コンポーネントは、ポートのセット且つポートのサービスであり、ハードウェ
アコンポーネントの継承は、通常、ポートの継承とサービスの継承を意味し、そ
れらはオーバーライドされることができる。さらには、以下により詳しく述べら
れるが、ポートは、含められたコンポーネント(contained component)によって
提供される多数のサービスの順次及び並列な組み合わせ(composition)を与える
ように設定されており、多くの信号が、あるイベントに応答して、含んでいるコ
ンポーネント(containing component)のポートを介して伝達されることができ、
続いて、そのイベントに応答して多くのサービスを実行するために適切なカプセ
ル化されたコンポーネントに割り当てられることができる。この組み合わせは、
よりハイレベルなサービスと考えられるテキスト的な識別子によって抽象される
。

【００４６】前述のオブジェクトフレームワークに関して、構造的コンポーネントから振る
舞いを継承することができ、簡易な構造的継承よりも強い拡張を与える。コンポ
ーネントを拡張するために用いられる継承は例えば基本レジスタコンポーネント
に基づいたシフトレジスタの定義によって明らかになる。基本レジスタは例えば
下記のテーブルＩＩに示されるように定められ、入力値を出力ポートにロードす
る“ＬＯＡＤ”サービスと、その出力ポートをゼロにセットする“ＲＥＳＥＴ”
サービスを含んでいる。

【００４７】

【表２】基本レジスタから継承するシフトレジスタを定めるために、シフトレジスタク
ラスには、記憶された値を１ビット左に移す“ＳＨＩＦＴ”サービスが付け加え
られている。追加のな“ＣＩＮ”と“ＣＯＵＴ”ポートがキャリービットを操作
するのに設けられている。シフト後、記憶された値に対して新しい上位ビットは
“ＣＩＮ”ポートに割り当てられた値によって定められ、古い下位ビットは“Ｃ
ＯＵＴ”ポートに割り当てられる。テーブルＩＩのレジスタの記述を拡張する、
シフトレジスタの適切な振る舞いの記述が下記のテーブルＩＩＩに示されている
。

【００４８】

【表３】シフトレジスタクラスに対するコンストラクタは新しいポートと新しいシフト
サービスを定めなければならない。基本レジスタが有している他のサービスは受
け継がれる。さらに、基本レジスタコンポーネントのサービスは、もしそのレジ
スタコンポーネントから継承している別のコンポーネントの機能を実行する必要
があるならば、オーバーライドされ得ることが理解されよう。

【００４９】ここに述べられたようなオブジェクト指向を用いたモデリング及びシミュレー
ションのさらなる議論が、１９９８年６月のヨーロッパシミュレーションマルチ
会議における、ＭａｌｌｅｔＦ、ＢｏｅｒｉＦ、ＤｕｂｏｃＪ−Ｆによる
“オブジェクト指向方法を用いたハードウェアモデリング及びシミュレーション
”（１９９８年）のｐ１６６〜１６８で与えられている。この発表は、この中に
リファレンスによって具体化されている。

【００５０】オブジェクト指向のラピッド・プロトタイピング環境によるデジタルアーキテクチャプロトタイピングここで述べられる、ラピッド・プロトタイピング環境４１を用いたプログラム
可能なデジタルアーキテクチャをプロトタイピングするための一連のオペレーシ
ョンは図７の符号９５で示される。通常、所望の設計あるいはアーキテクチャの
表す新しいモデルは、ブロック９６に示されるように、現存するライブラリコン
ポーネントからまず構築される。所望のアーキテクチャがプログラム可能である
とすると、通常、プログラムの命令を実行するのに適当なプロセッサコアあるい
は同種のコンポーネントがモデルに組み込まれる。

【００５１】モデルの設計に続いて、任意のプログラム及び（あるいは）メモリデータがブ
ロック９７に示されるようにシミュレーションで用いるためにイニシャライズさ
れる。特に、プログラム可能なデジタルアーキテクチャに対して、プログラムの
命令は実行されるために、通常、シミュレーションの間メモリにロードされなけ
ればならない。以下により詳しく論じられるように、メモリコンテンツはテキス
ト的なファイル、タブ区切りファイル、又は、ファイルあるいはデータベースに
配列されたデータを表す他の手段を介して定められる。

【００５２】さらに、以下でより明らかになるように、プログラム命令に対して、機能的な
観点から、実際のバイナリオペコードや、実際のメモリにストアされるとともに
モデル化されたデジタルアーキテクチャの実際のハードウェア手段によって実行
される関連のあるバイナリデータを、ストアする必要はない。その代わりに、ハ
イレベルなモデリングとシミュレーションのために、単にアセンブリ言語表示の
命令をメモリにストアし、次いで、その命令の実行を正確にシミュレーションす
るために、これらのアセンブリ言語表示をシミュレーションの間解釈すれば十分
である。

【００５３】いったん任意のメモリがサンプルデータでイニシャライズされると、ブロック
９８に表されるようにユーザーは、シミュレーションの間、レジスタ及び（ある
いは）ポートをモニターに明記する。以下でさらに明らかになるように、シミュ
レーションの間、データを表示するための出力デバイスとしてだけ機能する専用
のディスプレイポートコンポーネントが、モデルのデバッグでアシストになるよ
うにモデルに組み込まれる。さらに、それぞれのコンポーネントで出力サービス
を提供することによって、モデル内の選択されたコンポーネントからの状態情報
の直接の出力をサポートするのが望ましい。このそれぞれのコンポーネントは、
コンポーネントのポートの現在値、あるいはコンポーネントの規定変数(specifi
c variable)がシミュレーションの間ディスプレイに出力されるべきかどうかを
決定するために、ユーザーによって手動で選択可能に構成されている。シミュレ
ーション情報を出力する他の手段が代わりに用いられても良い。

【００５４】いったん表示されるべき情報が特定されると、シミュレーションがブロック９
９で走る。通常、そのシミュレーションは、イベントに基づいたロジックシミュ
レータの他の形式のものと同じようにして進む。シミュレーションサイクルはク
ロックサイクルに基づき、イベントは、モデルの論理的な機能をシミュレートす
るためのクロックサイクルの間、モデルの全体に渡って送られる。ユーザーのセ
ッティングは、シミュレーションのポーズの間に、サイクルと遅延の数を制御す
るように構成され、追加のユーザーの入力により、早くシミュレーションをステ
ップしたり、シミュレーションを途中で止めたり等することが可能になる。

【００５５】次に、ブロック１００に示されるように、シミュレーションが完了すると、受
け入れられるシミュレーション結果が得られたどうか、即ち、モデルが、アーキ
テクチャーに望まれる機能性能に合致していたかどうかが決定される。

【００５６】もしそうでなければ、モデルは、ブロック１０１に示されるように、新しいコ
ンポーネントの追加、及び（あるいは）現存するコンポーネントの修正によって
修正される必要がある。次に、シミュレーションは受け入れられる結果が得られ
るまで再度走らされる。受け入れられる結果を受け取ると、ブロック１０２に示
されるように、作られたモデルは、通常、新しいコンポーネントとしてライブラ
リに収容され、アーキテクチャのプロトタイピングが完成する。

【００５７】ここに述べられたモデリング及びシミュレーションプロセスをさらに明白にす
るために、図８が、ここに述べられるラピッド・プロトタイピング環境４１によ
ってモデリング及びシミュレーションされることのできる典型的な処理システム
アーキテクチャ１０４を示す。処理システムは、ＣＰＵすなわちプロセッサコン
ポーネント１０５、及びＣＰＵによって動かされるプログラムとデータを含むメ
モリ１０６により構成されている。コンポーネント１０５,１０６の両方ともＲ
ＥＳＥＴ信号を受け取ることができ、ＣＰＵは、処理システム環境をシミュレー
トするのに用いるクロック信号を受け取るように構成されている。ＣＰＵはアド
レス（ＡＤＲ）ＢＵＳ上にアドレスを送ることができ、このアドレスはＲＥＡＤ
あるいはＷＲＩＴＥ信号によって同行させられ、データはデータバス上でメモリ
とＣＰＵの間で送られる。メモリは２つの出力部ＵＮＩ及びＵＮＩ＿Ｉを有し、
それらはそれぞれ、メモリがイニシャライズされたかどうかやプログラムがメモ
リにロードされたかどうかを示すために随意に与えられる。その出力は、少なく
ともシミュレーションを実行するのにメモリがプログラムでロードされなければ
ならないということを開発者に示するように用いられる。

【００５８】図９は、ＣＰＵ１０５のアーキテクチャをより詳細に示している。ＣＰＵの計
算部分はＡＬＵ１０７とアキュムレータレジスタ１０８で構成されている。ＣＰ
Ｕの制御部はプログラムカウンタ（ＰＣ）１１０を有し、これは、プロセッサに
よって実行される現在の命令のアドレスを示す命令アドレスを生成するのに用い
られる。命令がフェッチされると、それは命令レジスタ（ＩＲ）１１２に、デー
タバスのＤＡＴＡＩＮラインから与えられ、そこでは命令のデコードが行われ
る。命令がデコードされた後、命令レジスタがコマンド信号をアーキテクチャの
種々のブロックに送る。ブロックにはＡＬＵ１０７、ＰＣ１１０及びコントロー
ラ１１４が含まれる。

【００５９】データバスは、命令レジスタ１１２の他ＡＬＵ１０７の入力部にも接続された
ＤＡＴＡＩＮによりＣＰＵに接続されている。さらに、命令レジスタから制御
信号ＣＯＤＥＯＰがＡＬＵに与えられており、アキュムレータレジスタ（ＡＣＣ
Ｕ）の中身の出力もＡＬＵに与えられている。ＡＬＵの動作結果はアキュムレー
タレジスタ１０８へ出力部を介してフィードバックされる。これは、ＡＬＵの出
力部をデータバスのＤＡＴＡＯＵＴラインに接続するバッファ１１８にもフィ
ードバックされる。ＡＬＵはさらにゼロのフラッグ信号をコントローラ１１４に
与える。

【００６０】コントローラ１１４は、ＣＰＵ内の他のブロックを制御するために多くの制御
信号を出力する。コントローラの第１のタスクは、読み込みあるいは書き込みが
あるクロックサイクルでメモリに実行されるのか、そして、その読み込みあるい
は書き込みは、データ交換（アドレスが命令レジスタ１１２から発する）である
のか、あるいは命令の読み込み（アドレスがプログラムカウンタ１１０から発す
る）であるのかを決定することである。アドレスバスに対する適切なドライバー
の選択は、コントローラ１１４によって、マルチプレクサ１１６へのＶＡＬ＿Ｄ
ＡＴＡ選択信号の主張(assertion)を介してなされる。マルチプレクサ１１６は
命令レジスタとプログラムカウンタの出力をアドレスバスＡＤＲに多重送信する
。

【００６１】さらに、ＬＯＡＤ＿ＡＣＣＵ信号がアキュムレータレジスタ１０８のラッチン
グを制御し、ＥＮＡＢＬＥ＿ＤＡＴＡ信号はＡＬＵ１０７の出力データをバッフ
ァ１１８がキャプチャーするのを可能にする。ＬＯＡＤ＿ＩＮＳＴ信号は命令レ
ジスタ１１２による新しい命令のラッチングを制御し、一方それぞれＰＣを増や
し且つＰＣを新しいアドレスでロードするために、ＩＮＣ＿ＰＣ及びＬＯＡＤ＿
ＰＣ信号がプログラムカウンタ１１０に与えられる。さらに、コントローラ１１
４はＷＲＩＴＥ及びＲＥＡＤ信号を、デコードされた命令に応答したＣＰＵの外
側に出力する。

【００６２】コントローラ１１４は外部クロック信号ＣＬＫをＣＰＵのために受け取る。さ
らに、命令レジスタ１１２、プログラムカウンタ１１０、アキュムレータ１０８
及びコントローラ１１４のそれぞれは、ＣＰＵに与えられたＲＥＳＥＴ信号に応
答する。

【００６３】任意の数のコンピュータユーザーインターフェースが、本発明にかかる前述の
処理システムの適切なオブジェクト指向モデルを開発するに際し、開発者をアシ
ストするために利用される。例えば、ビジュアルなドラッグ−アンド−ドロップ
的なものを用いて、ライブラリからのコンポーネントの組み立てを所望の設計に
するのをサポートするＪａｖａアブストラクトウィンドウツールキット（ＡＷＴ
）等を用いたグラフィカルユーザーインターフェースを用いるのが望ましい。そ
のような環境を用いるとコンポーネントはアイコンによって表され、種々のライ
ブラリからワークスペースにコンポーネントをドロップするのに用いられるドラ
ッグ−アンド−ドロップの機能が用いられている。さらに、コンポーネントは、
単にコンポーネントでクリックして、ポップ−アップメニュー、ダイアログボッ
クス、及び、所望のオプションや他の設定パラメータを設定するのを制御する他
のユーザーインターフェースを用いることによって簡単に設定することができる
。コンポーネントの相互結合は、コンポーネントアイコンに表示されるポートコ
ントロールをクリックすることによって実行され、相互結合は、ラインや他の適
当なグラフィカル表示によって表される。

【００６４】例えば、図１０は、図３のラピッド・プロトタイピング環境４１からの代表的
なアーキテクチャウィンドウ５０を示し、図８の処理システム１０４のオブジェ
クト指向モデルの一部をグラフィカル表示で示したものである。アーキテクチャ
ウィンドウ５０にはワークスペース１２０や種々の利用可能なコンポーネントラ
イブラリを示す複数のタブ１２２が示されており、ユーザーはアーキテクチャモ
デルにドロップされるべき適切なコンポーネントを配置するためにこれらのコン
ポーネントを選択する。ワークスペース１２０にはグラフィカルアイコン１２４
，１２６，１２８が表示されており、これらはそれぞれプログラムカウンタ１１
０、命令レジスタ１１２、コントローラ１１４を模範的な処理システムにおいて
表している。アイコン１２４−１２８はそれぞれポートコントロール１３０を有
しており、これは、結びつけられたコンポーネントによって提供されるそれぞれ
のポートを表す。異なるコンポーネントのポート間での相互接合は、異なるアイ
コンのポートコントロール間を張るライン１３２のような相互結合要素によって
グラフィカルに表されている。

【００６５】回路コンポーネントに加えてさらに、モデルのシミュレーションで役に立つ追
加のコントロール、即ちアイコンをモデルに組み込むのが望ましい。例えば、符
号１３４で表される手動で作動させられるスイッチのようなコンポーネントが、
シミュレーションの前あるいはシミュレーションの間に、種々のポートにストア
された値を手動で制御するのに用いられる。コントロール１３４は、例えばシミ
ュレートされたモデルを初期状態に戻すためにシミュレーションの間にハードリ
セットを発じさせるのに利用される。

【００６６】さらに、出力コンポーネント、例えばディスプレイコンポーネント１３６がモ
デルに組み込まれるとともにいくらかのポートに結ばれ、それぞれのポートの加
えられる信号をシミュレーションの間に出力させる。コントロール１３６は、例
えば命令レジスタにより発せられた、ＣＯＤＥＯＰコントロールライン上の“Ａ
ＤＤ”値の出力を表す。

【００６７】前述のグラフィカルユーザーインターフェース環境の実装は、十分に即座の開
示の利益を有している当業者の能力の範囲内である。Ｊａｖａや他のアプリケー
ションの環境でサポートされる追加のグラフィカル機能がいくつかのアプリケー
ションでさらに用いられても良い。

【００６８】さらに、フォーム・ベースのプログラミング、ラピッド・アプリケーション開
発プログラミングのような種々のソフトウェア開発方法論が、ここで論じられた
ラピッド・プロトタイピング環境によって提供される機能を高めるために用いら
れてもよい。例えば、ユーザーによる任意のアイコンの選択により、ユーザーが
特定のコンポーネントを要望どおりにカスタマイズのに修正する、設定可能な値
及び他のパラメータによるテーブルを組み込んだダイアログボックスが発生する
。例えば、メモリコンポーネントに対して、ユーザーがメモリのサイズ、メモリ
のアドレス空間、メモリのスピード、メモリのタイプ等をダイアログボックス選
択により特定可能にするのが望ましい。さらに、シミュレーションの間に用いら
れるサンプルデータをメモリの内容として与えるために、外部ファイル例えばテ
キストファイルを関連づけるのが望ましい。さらに、ユーザーが、インスタンス
化されたコンポーネントのネーミングを要望どおりに制御できるように、コンポ
ーネントのユニークなネーミングをサポートするのが望ましい。

【００６９】通常、グラフィカルユーザーインターフェースによるパラメータの修正による
コンポーネントの修正に応じて、そのコンポーネントに対するＪａｖａ言語仕様
は、通常、Ｊａｖａシミュレータによって動的に修正される。そのようにするこ
とは、ビジュアルプログラミング環境での動的コード生成に類似しており、その
コンフィギュレーションを用いることはよく知られた技術である。

【００７０】さらに、種々のコンポーネントライブラリの管理オペレーションが本発明に関
連して与えられることが理解されよう。Ｊａｖａや他のオブジェクト指向言語と
して知られている種々のビジュアルあるいはラピッドなアプリケーション開発ツ
ールと同様に、オブジェクトの管理は多くの手段によってサポートされる。例え
ば、オブジェクトはブックマークによって体系づけられる。さらに、種々のアイ
コンが特定のコンポーネントに関連づけられて利用される。さらに、アイコンの
編集もサポートされる。

【００７１】デジタルアーキテクチャのモデリングとシミュレーションを高めるために、多
くのユニークな強化がラピッド・プロトタイピング環境で与えられる。そのよう
な強化の中で、ポートの管理や多重化、動的な命令デコーダーの生成が注目に値
する。これらの強化のそれぞれは以下でさらに詳しく論じられる。

【００７２】ポート管理上述したように、ラピッド・プロトタイピング環境によりサポートされる１つ
の特定の機能は、シミュレーション下でモデル内のコンポーネント間でのデータ
伝送を管理するためのポート管理の機能である。本実施例において、ポートは、
コンポーネント間で信号としての値を伝送し、それに応答してコンポーネントの
中のサービスの実行を開始するのに利用される、データのタイプに依存しない構
成体(construct)である。基本ポートタイプが定められ、これから多くのチャイ
ルドポートクラスが定められる。本実施例においては、例えばサービスポートは
入力ポート、出力ポート、入出力ポート（双方向ポート）及びコミュニケーショ
ンポートとして定められる。以下でより明らかになるように、コミュニケーショ
ンポートは管理可能開発環境を提供するのに重要な特徴であり、そのようなポー
トは、コンポーネント間の共通路を横切って多数の信号の多重化を可能にする。

【００７３】例として、ハードウェア設計は、通常、多くの許可信号すなわちチップ−セレ
クト信号、コンフィギュレーション信号、互換性信号等を有し、それらは性能評
価において競合しない。さらに、制御信号は、例えばマルチプレクサで振る舞っ
ている種々のパスの選択を認めるというような共通の特性でグループ化される。
前述したような階層的手段でモデリングするとき、そのような信号は多くの中継
ポートや信号を生じさせる。個々の信号を運ぶための多くのポートを定め、グラ
フィカル環境でコンポーネント間のそのようなポートの全てを接続することによ
り、過剰な情報がアーキテクチャウィンドウに表示され、ディスプレイが、モデ
ルの理解を難しくさせる多くのラインで散乱させられる。

【００７４】それ故、この難点に取り組むために、コミュニケーションポートは、あるポー
ト内で多くの信号の伝送を受け入れるように定められており、その結果、接続さ
れたコンポーネントにおける１つのポート結合は、コンポーネント間の多くの信
号の伝送を表すように用いられる。多重化されたコミュニケーションポートを用
いることが望ましい状況の例は、命令デコーダをレジスタに接続しているときに
ある。このレジスタは、ソースあるいはＡＬＵによる算術演算の宛先として選択
されることのできる多くのレジスタを組み込んでいる。ソース選択信号と宛先信
号との両方を１つのコミュニケーションポートに多重送信することによって、そ
れぞれのソースと宛先の選択に対する個々のポートは必要とされず、また、その
ようなポート間で張る個々のラインも必要でない。レジスタファイルとデコーダ
内での適切な相互結合は依然として必要とされ、それは、例えばレジスタファイ
ルに対しては、レジスタ選択信号をレジスタファイル内の適切なレジスタにルー
ティングするのに必要とされる。それにもかかわらず、レジスタファイルが１つ
のアイコン（ファイルにカプセル化された個々のレジスタ）として表示されると
きに、深刻な表示の散乱は避けられ、このことは、そのようなコンポーネントが
モデルにドロップされるときに、デコーダとレジスタファイルを相互結合するの
に過度な努力が避けられるのと同様である。

【００７５】本実施例において、それぞれのポートはポート名、アイコン位置（アイコンの
どのエッジにポートが配置されるかを表す）及びポートタイプ（ここでは出力、
入力、あるいはコミュニケーション）を組み込んでいる。それぞれのポートは、
１つ以上のイベント生成プログラムによって生成される１つ以上のイベント（即
ち、“１”、“０”、“立ち上がりエッジ”、“立ち下がりエッジ”）に関連づ
けられ、このイベントに応答してポート上で伝えられるべき値に関連づけられる
。イベント名は、例えば信号名あるいはクロック名である。

【００７６】図１１は、例えば、特定のコンポーネントに対してポートを設定する試みに応
じて、ラピッド・プロトタイピング環境によって実行される設定ポートルーチン
(configure port routine)１４を示す。ルーチン１４０は、例えばコンポーネン
トを選択し、それに対して追加ポート操作を始動することによって新しいポート
を作成する試みに応じて実行される。ルーチン１４０は、さらにユーザーによっ
て選択された現存ポートを編集するユーザーの要求に応じて、現存ポートに対し
ても実行される。

【００７７】ルーチン１４０は、ブロック１４２でポート名、アイコン位置、ポートタイプ
（入力、出力、入出力、コミュニケーション(in,out,inout,communication）を
ユーザーから取得することによって始まる。次に、ブロック１４４ではポートを
作動させるためにイベント名、イベント値、伝送値(propagate value)を取得す
る。前述したように、イベント名は信号を指し、その信号の状態は、ポートを介
して値を伝送するかどうかを決定するためにポーリングされる。イベント値はト
リガー条件を指し、この場合は識別された信号の値は、例えば信号がハイあるい
はローのロジックレベルであるとき、あるいは立ち上がりエッジもしくは立ち下
がりエッジへの移り目が検知されたときに、値の伝送という結果を生じせしめる
。伝送値は、トリガーされたイベントに応答してポートを経由して出力する値を
示す。

【００７８】前述したように、伝送値は、タイプが規定されておらず、ポート上で伝送され
るデータを表す文字列を含む。代案では、伝送される値は、とりわけロジックレ
ベル（例えばハイあるいはロー電圧）、あるいは立ち上がりエッジもしくは立ち
下がりエッジでよい。

【００７９】ブロック１４６に示されるように、伝送値用の別の可能性ある値は、多重化さ
れたコミュニケーションポートを表す“多重化”値であり、ユーザーは、このコ
ミュニケーションポート上で種々の信号を１つのコミュニケーション信号として
多重化するのを望む。多重化要求が検知されると、ブロック１４６で、ユーザー
から、選択されたイベントに応答して同時に送信するための、その信号及び値を
識別する１つ以上の名／値のペアを取得するために、ブロック１４８に制御が渡
される。したがって、伝送されるそれぞれの信号に対して、ユーザーは、その信
号に対して伝送される値と一緒に信号をリストする。ポートの設定はそのとき完
了する。ブロック１４６に戻って、もし伝送値が“多重化”でなければブロック
１４８は無視され、ポートの設定は完了する。

【００８０】ユーザーインターフェース（例えばグラフィカルユーザーインターフェース）
は、ポートの管理と設定を容易にするためにサポートされているということが理
解されよう。例えば、ユーザーはポートを選択した後、“管理”ボタンを選択す
ることを必要とされるかもしれない。それから、種々の利用可能な信号、イベン
ト条件及び伝送値を選択するためのダイアログボックス内でリストボックス、チ
ェックボックスあるいは他のコントロールを利用することを必要とされるかも知
れない。さらに、多重化オプションの選択が、ユーザーがポートを管理している
ときに選択されるダイアログボックスに配置されたボタンによりあるかもしれな
い。他のユーザーインターフェースコントロールが代わりに用いられるかも知れ
ない。

【００８１】シミュレーションの間、イベント、例えばクロック信号、リセット信号、ある
いは他の入力信号の立ち上がりエッジあるいは立ち下がりエッジが、選択された
ポートを介して信号値の伝送を始めるためにポートに伝送される。ポートが多重
化ポートであろうと多重化ポートでなかろうと、イベントの検知とトリガーは概
して同じである。トリガーイベント（多重化されていないポートでの）に応答し
て１つの信号値を伝送する代わりに、多重化ポートは、通常、同イベントに応答
して多くの信号に対する値を伝送する。

【００８２】上述の総称コンポーネントモデルに関連して用いられるとき、多くの制御ポー
トは、モデルを簡単にし、表示されるポートや信号経路の数を減じるために、構
造コンポーネントに抽象化されることができる。さらに、ポートは、バイナリロ
ジックレベルの形態でというよりも、記号やトークンのような信号を送信するこ
とができ、したがって、すぐれた直感性とユーザー理解をシミュレーションの間
に提供することができる。例として、後に述べられる典型的な動的に生成される
命令デコーダに対して、デコードされる命令は、実際のバイナリオペコードを送
るというよりも、例えば“add r0, r1, r3”のように記号あるいは文字列として
デコーダに送られる。基本的なバイナリコードはハイレベルな性能評価に適切で
ないので、アセンブリ言語文字列としての命令の伝送をサポートすることは非常
にシミュレーションの間のデバッグを簡易にする。

【００８３】通常、多重化コミュニケーションポートの相互結合は、１つの相互結合要素例
えば１つのライン（図１０に示されるような相互結合形式）によりモデルのディ
スプレイに表される。２つのコンポーネント間の相互結合を表す他の表示要素が
代わりに用いられ、しかも、そのような表示要素は、相互結合は１つの信号に対
しての相互結合というよりも多重化された経路であるということを示せることが
理解されよう。

【００８４】通常、多重化された信号を多重化ポートから受け取る回路コンポーネントは、
受信コンポーネント内で信号を逆多重化してそのような信号を適切なコンポーネ
ントに渡すために、内部コンポーネントを実行することが必要とされることがさ
らに理解されよう。例えば、逆多重化コンポーネントに対する多重化入力へのど
んな変化も、逆多重化コンポーネントに対して定められた特定の出力部に伝送さ
れるように、コンビネーションの振る舞いが逆多重化コンポーネント内で実行さ
れる。

【００８５】動的な命令デコーダの生成前述したサービスポートの概念は、プロセッサモデルの命令デコーダコンポー
ネントのモデリングにおいてもさらに利用される。特に、上述した典型的なアー
キテクチャを備えたようなプロセッサアーキテクチャのモデルを開発するときに
、しばしば実行に特有のものである重要なコンポーネントは命令デコーダである
。それは、プログラムメモリから命令を実行して、ＣＰＵの演算ユニットと制御
ユニットを制御するのに用いられ、デコーダによって受け取られた命令を実行す
るようにＣＰＵを特に形成する。本実施例において、ユニークな動的な命令デコ
ーダの生成プロセスが与えられており、それによって、カスタムデコーダが命令
セットのテキスト的な定義に応答して動的に生成させられる。

【００８６】カスタムデコーダを生成するために総称デコーダコンポーネントは命令定義セ
ットに応答して動的に修正させられる。図１２は、例えば典型的な処理システム
の命令レジスタアイコン１２６内にカプセル化されたデコーダアイコン１５０を
示しており、ここに開示された手段で動的に修正させられる総称デコーダコンポ
ーネントを表す。総称デコーダコンポーネントはまず３つのポートを有している
。それは、クロック信号、すなわちＬＯＡＤ＿ＩＮＳＴ信号のような命令ロード
信号を受け取る“ＳＲ”ポート、ＲＥＳＥＴ信号を受け取るように構成された“
ＲＥＳＥＴ”ポート、及びデータバスから命令を受け取るように構成された命令
（“ＩＮＳＴＲ”）ポートである。

【００８７】図１３は、ユーザーが、総称コンポーネントからカスタムデコーダを生成する
ために始めるデコーダカスタマイズプロセス１６０を示す。このプロセスは、モ
デル化されたプロセッサによって実行される命令に対する定義を表す命令セット
ファイルを作ることによりブロック１６２で始まる。通常、命令セットファイル
はテキスト的な形式であり、プロセッサに対してアクセス可能なレジスタの定義
の他に、そのような命令の実行に応答して伝送するための信号に結びつけられた
サポートされた命令をも含んでいる。様々な種類の代わりの命令セット形式が用
いられても良く、本発明はここに述べられる特定の実装に制限されない。

【００８８】次に、ブロック１６４で、前述の総称デコーダアイコンが現存の設計にドロッ
プされる。次にブロック１６６で、命令セットファイルがデコーダコンポーネン
トインスタンスにリンクされる。命令セットファイルのリンク付けは、例えばパ
ラメータ設定ウィンドウを開けるために総称デコーダアイコンを選択し、適切な
選択ボックスで命令セットファイルのファイル名を入力することによって行われ
る。命令セットファイル名のデコーダコンポーネントインスタンスへの服従に応
じて、制御はブロック１６８へ進み、例えばユーザーによるパラメータ設定ウィ
ンドウからの退去と同時に生成デコーダルーチンが実行される。したがって、生
成デコーダルーチンは、総称デコーダの命令セットファイルへのリンク付けに応
じて動的に呼ばれる。命令デコーダの動的生成は、いったん命令セットファイル
がそれにリンク付けされると、多くの代わりの手段、例えばデコーダを生成する
ための特定のユーザー入力に応じて実行されうる。

【００８９】以下に論じられるように、生成デコーダルーチンは命令セットファイルを分析
し、適当なポートを有するカスタムデコーダアイコンを作る。このポートは、命
令デコーダによって受け取られる種々の命令に応じて命令デコーダによって選択
的に主張(assert)される信号を表す。いったんカスタマイズされたデコーダが生
成されると、制御はブロック１７０に進み、デコーダは設計の残りに繋がれる。
例えば、ユーザーが、新たに作られたポートを選択し、そのポートを、モデルに
現存するコンポーネント用の適当なポートに接続することによってそうされる。
次に、ブロック１７２に表されるように、ユーザーは、モデルのシミュレーショ
ンを開始する。任意のエラーが生じた結果、ブロック１７４に示されるように、
ユーザーは命令セットファイルを編集し、制御をルーチン１６８に戻すことによ
ってデコーダを再生成する。エラーなしでシミュレーションが止まったらプロセ
ス１６０が完了する。

【００９０】図１４に、生成デコーダルーチン１６８が詳細に説明されている。ルーチン１
６８は、ブロック１８０において、メモリをテーブルに割り当てるためにデコー
ダテーブルをイニシャライズすることによって始まる。次に、ブロック１８２に
おいて、特定された命令セットファイルが開かれ、ブロック１８４において、デ
コーダによってアクセスされる利用可能なレジスタを定めたレジスタ定義命令文
を示す命令セットファイルが読み取られる。示されたレジスタ定義に応じて利用
可能なレジスタが定められる。さらに、もしレジスタ定義命令文が検知されない
ときはエラーが送られる。さらに、もし後に、定義されていないレジスタに命令
がアクセスしようとするとエラーがユーザーに送られる。

【００９１】次に、ブロック１８６において最初の命令定義が命令セットファイルに定めら
れる。ブロック１８８においてそのような定義を見つけようとする試みが成功し
たかどうかが定められる。もしそうであれば、制御はブロック１９０に移り、命
令定義のそれぞれのラインが検索される。本実施例においてそれぞれのラインは
、信号（制御ライン）、及び命令の実行に応じてその信号で伝送するための関連
づけられた値（出力タイプ）を含む。

【００９２】ブロック１９２において、任意のラインが最初の命令定義に対して発見された
かどうかが定められる。もし発見されなければエラーが送られ、ルーチン１６８
は終了する。しかしながらもし少なくとも１つのラインが検知されれば、制御は
ブロック１９４に移り、命令セット定義のラインの第１及び第２のフィールドか
ら制御ラインと出力タイプが得られる。次に、ブロック１９６において制御ライ
ンが既にデコーダテーブルに定められているかどうかが決定される。もしそのよ
うなラインがテーブルに発見されない場合は、制御はブロック１９８に移り、制
御ライン名と出力タイプがテーブルに加えられる。次に制御はブロック２００に
移り、さらなるラインがこの命令定義に存在するかどうかが定められる。もしそ
うであれば、制御はブロック１９４に戻り、命令定義の次のラインが処理される
。

【００９３】いったん命令定義の全てのラインが処理されると、ブロック２００からブロッ
ク２０２に制御が移され、次の命令定義が探される。次に制御はブロック１８８
に移り、そのような定義が発見されたかどうかが定められる。もしそうであれば
、制御はブロック１９０に進み、上述の手段で命令を処理する。しかしながら、
さらなる定義が発見されない場合は、制御はブロック２０４に移り、テーブルが
空（即ち命令定義がファイルに発見されなかった）であるかどうかが定められる
。もしそうであればエラーが送られ、ルーチンは終了させられる。しかしながら
もしそうでなければ、制御はブロック２０６に移り、デコーダテーブルにリスト
された制御ラインのそれぞれに対してポートコントロール及びラベルを有する新
しいデコーダアイコンが作られる。

【００９４】さらにデコーダカスタマイズ処理を説明するために、下記のテーブＩＶに、カ
スタムデコーダを上述の総称デコーダコンポーネントから生成するために用いら
れる典型的な命令セットファイルが示されている。

【００９５】

【表４】図１５に、出来上がったデコーダアイコン１５０’が示されている。ＡＬＵコ
ントロール信号ＡＬＵ＿ＣＯＤＥＯＰに対するポートが示されており、これと共
にレジスタファイルに結合するための３つのレジスタコントロール信号（ＳＯＵ
ＲＣＥ＿１、ＳＯＵＲＣＥ＿２、及びＤＥＳＴ）が総称デコーダアイコンに加え
られている。

【００９６】シミュレーションの間、立ち上がりエッジ信号がデコーダのＳＲ入力ポートに
発生したときに、デコーダはＩＮＳＴＲ入力ポートに表される値をキャプチャー
するように構成されている。キャプチャーされた値のデコードはそのとき実行さ
れる。

【００９７】例えば、“add r2, r3, r7”の値が、上記テーブルＩＶに定められた命令セッ
トを実行する生成されたデコーダのＩＮＳＴＲ入力ポートで取り込まれたと想定
する。デコーダは第１に、受信された命令“add”の第１のフィールドが命令セ
ット定義ファイルに存在するかどうかをチェックするように構成されている。も
し存在しなければ、シミュレーションはエラーフラッグを立ててストップさせら
れる。そうでなければ、“add”値はデコーダのＡＬＵ＿ＣＯＤＯＰ出力ポート
に伝送される。

【００９８】その後、デコーダは、第２のフィールド“r2”が命令セット定義ファイルに存
在するかどうかをチェックするように構成されている。もし存在しなければ、シ
ミュレーションはエラーフラッグを立ててストップさせられる。しかしながらも
し存在すれば、値“r2”は、デコーダのＳＯＵＲＣＥ＿１出力ポートに伝送され
る。同様にして、値“r3”及び“r7”が、デコーダのＳＯＵＲＣＥ＿２及びＤＥ
ＳＴ出力ポートに伝送される。もしレジスタ定義に宣言されていないレジスタ“
r9”が命令に存在すれば、エラーが送られ、シミュレーションは停止させられる
。

【００９９】本実施例において、デコーダコンポーネントはＳＲ入力ポートの立ち上がりエ
ッジイベントに反応するように構成されている。デコーディングは文字列比較に
よって実行され、命令定義形式から任意のミスマッチが発生すると、シミュレー
ションにエラーフラッグと中止の生成が生じる。それによって開発者は開発され
たコードが構文的に正しいということが確信することが可能になる。ここで述べ
られるような命令セット定義に対して文字列命令を比較するために適切なルーチ
ンを開発することは、即座の開示の利益を有する技術における当業者の能力の範
囲内に十分にあることが理解されよう。

【０１００】上述したように、シミュレーションの間、通常、１以上の観測者あるいは出力
コンポーネント（例えば図１０のコンポーネント１３６）が関連ポートに対して
現状態情報(current state information)を出力するのにさらに用いられる。こ
れらのコンポーネントは、関連ポートのイベントを観測したり、この現状態情報
をディスプレイに出力したりするように単に設定されているだけである。さらに
、いくらかの実施例においては、チェックボックスあるいは類似のコントロール
が、上記関連ポートに対しての状態情報がキャプチャーされ、ディスプレイへの
ログのためにデバッグウィンドウに表示されるように、いくつかのコンポーネン
トに選ばれる。

【０１０１】図１６は、シミュレーションデータがユーザー表示される別のメカニズムをさ
らに示す。特に、データメモリやプログラムメモリのようなメモリの内容はテー
ブルやリストの形態でユーザーに、例えばウィンドウ２２０，２２２を介して表
示される。それぞれのウィンドウ２２０，２２２は複数のメモリロケーションエ
ントリーを有し、それぞれのエントリーはメモリロケーション及びそれの内容を
識別する。メモリにアクセスされた現在つまり最後のメモリロケーションは、例
えばハイライトバー２２８，２３０あるいは他の適当な区別可能な表示要素によ
って表される。その結果ユーザーは、例えばプログラムメモリの場合には何の命
令が今現在、シミュレーションの間に実行されているのかを容易に定めることが
できる。実際のバイナリ値はここに述べられるようなモデルのシミュレーション
に対しては実際には必要とされないので、アセンブリ言語命令がテキスト的な形
式でそれぞれのエントリ２２６に表示されることがさらに理解されよう。

【０１０２】前述のデコーダインプリメンテーションの重要な利益は、デコーダ設計の再利
用性、拡張性、最適性にある。なぜなら、命令デコーダコンポーネントは、命令
セットファイルの編集やルーチン１６８による再生成を介するだけで容易に修正
できるからである。それ故、そのような環境により開発者は、命令ファイルに新
しい命令定義を追加し、そのような命令を組み込むためにシミュレーションの間
に用いられるテストプログラムを修正するだけで、現存の設計に新しい命令に対
するサポートを追加する利益を実際に試みることができる。

【０１０３】追加の機能が、命令デコーダを確認するために、動的生成ルーチン及び（ある
いは）シミュレーションルーチンでさらにサポートされる。例えば、新しい命令
が追加された場合、命令によってコマンドされたときに、同時にあるいは連続し
て全てのサービスが物理的に呼ばれることができるかどうかを確認するためにマ
テリアルな依存関係がチェックされる。例えば、いくらかのアーキテクチャは、
多数の独立したメモリポートに対して多数のデータポイントの同時ロードを許容
し、それによって他のアーキテクチャは同メモリポートに対して多くのデータポ
イントリクエストを多重化する。後者のインスタンス(in the latter instance)
では、同メモリポートに対して多数のデータポイントのための同時リクエストは
許容されず、そのようにしようとする命令を組み込むための動的生成に応じてエ
ラーが開発者に伝えられる。

【０１０４】さらに、いくつかのサービスの連続する実行の間にパイプラインステージを表
す遅延を追加することで、シミュレーション用にパイプラインアーキテクチャに
ついての情報を組み込むことが望ましい。そのとき、命令セット定義情報及びそ
のような構造上の制約を結合することによって、サイクルの正確なシミュレーシ
ョンが得られる。

【０１０５】バーチャルコンポーネント上述したように実施例においてはネイティブ回路コンポーネントは通常Ｊａｖ
ａプログラミング言語で定められている。それにもかかわらず、いくつかのアプ
リケーションにおいてはノンネイティブ形式で定められた追加のコンポーネント
の使用をさらにサポートするのが望ましい。例えば、先に存在する回路コンポー
ネントはｃ、Ｅｓｔｅｒｅｌ、ＶＨＤＬ、Ｖｅｒｉｌｏｇ等のような言語で定め
られても良い。そのような先に存在する回路コンポーネントがＪａｖａ形式で再
生されるのを要求するよりは、むしろ“バーチャル”コンポーネントアーキテク
チャをサポートし、それによってノンネイティブコンポーネントを適当なインタ
ーフェイスでカプセル化し、ラピッド・プロトタイピング環境４１へのそのよう
なノンネイティブコンポーネントの統合を可能とするのが望ましい。

【０１０６】特に、Ｊａｖａプログラミング言語は、ユーザーが外部プログラムへ変数を送
りそこから結果をキャプチャーするのを許容する機能をサポートする。そのよう
な機能、しばしば外部関数として言及されるが、を用いるため、開発者は、特定
の外部コンポーネントに変数を送り、外部コンポーネントで実行される関数を呼
び出し、外部コンポーネントによって生成させされる結果をキャプチャーするＪ
ａｖａプログラムを創造することを必要とされる。外部コンポーネントが、変数
型が重要であるｃあるいは別の言語で書かれている場合には、徹底した厳守が、
カプセル化された外部コンポーネントの変数型に与えられなければならない。

【０１０７】図１７は、本発明にかかるバーチャルコンポーネント２４０の基本構造を示す
。外部コンポーネント２４２はバーチャルコンポーネント２４０内でカプセル化
されており、通常ノンネイティブ（例えばＪａｖａでない）言語で書かれている
。変数は、環境４１からポート２４４を介して外部コンポーネントに与えられ、
ポート２４４で変数はフォーマットされ、入力ルーチン２４６によって転送され
る。同様に、関数が、環境４１からポート２４８を介して外部コンポーネントに
先導され、ポート２４８でその関数はフォーマットされ、関数ルーチン２５０に
よって転送される。外部コンポーネントによって生成させられる出力データは出
力ルーチン２５２によってキャプチャーされ、ポート２５４を介してバーチャル
コンポーネントから出力される。

【０１０８】種々の変更が実施例に対して本発明の範囲から外れることなくなされ得る。例
えば、他のユーザーインターフェース方法論及び他のプログラミング環境が代わ
りに用いられ得る。

【０１０９】その他の変更も当業者にとって容易に分かるであろう。しかして、本発明は添
付されたクレームに置かれている。

【図面の簡単な説明】

【図１】本発明に係る、オブジェクト指向を用いたモデリング及びシミュレーションを
実行するのに用いられるコンピュータシステムのブロックダイアグラムである。

【図２】図１のコンピュータシステムからのコンピュータに対して典型的なハードウェ
ア及びソフトウェア環境を示すのブロックダイアグラムである。

【図３】図２のコンピュータで実行されるラピッド・プロトタイピング環境の主要なコ
ンポーネントを示すブロックダイアグラムである。

【図４】図３のラピッド・プロトタイピング環境で用いられる総称コンポーネントモデル
を示すオブジェクトダイアグラムである。

【図５】図４の総称コンポーネントモデルに基づいた典型的なロード／ストアレジスタ
回路コンポーネントの振る舞い表現を示すブロックダイアグラムである。

【図６】図５の典型的なロード／ストアレジスタ回路コンポーネントの構造表現を示す
ブロックダイアグラムである。

【図７】図３のラピッド・プロトタイピング環境を用いてアーキテクチャをプロトタイ
ピングする際に利用される一連のオペレーションを示すフローチャートである。

【図８】図３のラピッド・プロトタイピング環境によってモデル化されることのできる
典型的な処理システム回路コンポーネントを示すブロックダイアグラムである。

【図９】図８の典型的な処理システム回路コンポーネントからプロセッサ回路コンポー
ネントを示すブロックダイアグラムである。

【図１０】図８の典型的な処理システム回路コンポーネントの開発の間に、図３のラピッ
ド・プロトタイピング環境によって表示される典型的なシミュレーションウィン
ドウを示すブロックダイアグラムである。

【図１１】図３のラピッド・プロトタイピング環境を用いてポートを構成するのに利用さ
れる一連のオペレーションを示すフローチャートである。

【図１２】図９のプロセッサ回路コンポーネントから命令デコーダのアイコン表示を示す
ブロックダイアグラムであり、そこに組み込まれた総称デコーダ回路コンポーネ
ントを含む。

【図１３】図３のラピッド・プロトタイピング環境を用いて命令デコーダをカスタマイズ
する際に利用される一連のオペレーションを示すフローチャートである。

【図１４】図１３で参照される生成デコーダルーチンのプログラムフローを示すフローチ
ャートである。

【図１５】図１４の生成デコーダルーチンを用いて典型的な命令セットを組み込むための
動的生成の後の、図１２の総称デコーダ回路コンポーネントのアイコン表示を示
すブロックダイアグラムである。

【図１６】シミュレーションの間に図３のラピッド・プロトタイピング環境によって表示
される典型的なデータ及びプログラムメモリウィンドウを示すブロックダイアグ
ラムである。

【図１７】図３のラピッド・プロトタイピング環境によってモデル化されることのできる
典型的なバーチャルコンポーネントを示すブロックダイアグラムである。

───────────────────────────────────────────────────── フロントページの続き (72)発明者ジャン、フランソワ、デュボックフランス国サン‐ローラン‐デュ‐バール、モワイアンヌ、コルニッシュ、デ、プュジェ、2893 (72)発明者フレデリック、マレフランス国ニース、ブールバール、ラ、パルマ、30 (72)発明者フェルナン、ボエリフランス国ニース、プロムナード、デ、ザングレ、131 Ｆターム(参考） 5B046 AA08 BA03 JA05

Claims

【特許請求の範囲】

【請求項１】コンピュータで電子回路設計をモデリングする方法であって、（ａ）それぞれ第１及び第２のポートを含む、第１及び第２のオブジェクト指
向の回路コンポーネントから電子回路設計のモデルを構成し、（ｂ）前記第１及び第２のポートを介して前記第１及び第２の回路コンポーネ
ントのインターフェースを互いにとり、前記第１及び第２のポートは、前記第１
及び第２のポート間で第１の信号に対する第１の値と第２の信号に対する第２の
値との両方を、前記第１及び第２のポートのうちの少なくとも１つに導かれたイ
ベントに応答して伝送するように構成されている、方法。
【請求項２】（ａ）前記イベントを発生させる工程と、（ｂ）前記第１及び第２の値を、前記イベントに応答して前記第１及び第２の
ポート間で伝える工程と、を含む前記モデルのシミュレーションの実行をさらに有する、請求項１に記載
の方法。
【請求項３】前記イベントはイベント名とイベントトリガーを含み、前記イベントトリガー
は前記イベントをトリガーする前記イベント名に結びつけられた条件を識別する
ものである、請求項１に記載の方法。
【請求項４】前記イベント名は信号識別子を有し、前記イベントトリガーに対する前記条件
は論理値１、論理値０、立ち上がりエッジ、立ち下がりエッジ、及びそれらの結
合からなるグループから選択される、請求項３に記載の方法。
【請求項５】前記モデルを構成することは、（ａ）グラフィカルユーザーインターフェースを介してユーザーインプットを
受け取って、前記第１及び第２の回路コンポーネントをワークスペースに加え、（ｂ）第１及び第２のアイコンをコンピュータディスプレイに表示し、前記第
１及び第２のアイコンはそれぞれ第１及び第２の回路コンポーネントに結びつけ
られており、前記第１及び第２のアイコンはそれぞれ、前記第１及び第２のポー
トに結びつけられた第１及び第２のポートコントロールを含む、ことを含む請求項１に記載の方法。
【請求項６】前記第１及び第２の回路コンポーネントのインターフェースを互いにとること
は、（ａ）前記グラフィカルユーザーインターフェースを介してユーザーインプッ
トを受け取って、前記第１及び第２の回路コンポーネントのインターフェースを
互いにとり、（ｂ）前記ディスプレイに、前記第１及び第２のポートコントロールの間で延
びる相互結合要素を表示して、第１及び第２のポート間での第１及び第２の信号
の伝送をまとめて表す、ことを有する請求項５に記載の方法。
【請求項７】前記相互結合要素は前記第１及び第２のポートコントロールの間で延びる１つ
のグラフィカルラインである、請求項６に記載の方法。
【請求項８】前記第１の回路コンポーネントは第３及び第４の回路コンポーネントをカプセ
ル化し、前記第３及び第４の回路コンポーネントはそれぞれ第３及び第４のポー
トを含んでおり、前記第１のポートは、前記イベントに応答して、前記第１の値を前記第２のポ
ートと前記第３のポートの間で伝えるように、且つ、前記第２の値を前記第２の
ポート及び前記第４のポートの間で伝えるようにさらに構成されている、請求項１に記載の方法。
【請求項９】前記第１の値は記号を含む、請求項１の方法。
【請求項１０】前記第１の値は文字列を含む、請求項９に記載の方法。
【請求項１１】電子回路設計のモデルをストアするように構成されたメモリと、それぞれ第１及び第２のポートを含む第１及び第２のオブジェクト指向の回路
コンポーネントから前記モデルを構成し、前記第１及び第２の回路コンポーネン
トのインターフェースを前記第１及び第２のポートを介して互いにとり、ここで
、前記第１及び第２のポートは、前記第１及び第２のポートのうちの少なくとも
１つに導かれたイベントに応答して、第１の信号に対する第１の値と第２の信号
に対する第２の値との両方を伝送するように構成されている、プログラムと、を有する装置。
【請求項１２】前記プログラムはさらに前記モデルのシミュレーションを実行するように構成
されており、前記モデルのシミュレーションは前記イベントの発生と、前記イベ
ントに応答した前記第１及び第２のポートの間での前記第１及び第２の値の伝送
を含む、請求項１１に記載の装置。
【請求項１３】前記イベントは、信号識別子とイベントトリガーを含み、前記イベントトリガ
ーは、前記イベントをトリガーするイベント名に結びつけられた条件を識別する
ものであり、前記条件は論理値１、論理値０、立ち上がりエッジ、立ち下がりエ
ッジ、及びそれらの結合から構成されるグループから選択されるものである、請求項１１に記載の装置。
【請求項１４】前記プログラムは、ユーザーインプットをグラフィカルユーザーインターフェ
ースを介して受け取とって、ワークスペースに前記第１及び第２の回路コンポー
ネントを加え、コンピュータディスプレイに第１及び第２のアイコンを表示する
ことによって前記モデルを構成するようになっており、前記第１及び第２のアイコンはそれぞれ前記第１及び第２の回路コンポーネン
トに結びつけられ、且つ、前記第１及び第２のアイコンはそれぞれ前記第１及び
第２のポートに結びつけられた第１及び第２のポートコントロールを含んでおり
、前記プログラムは前記グラフィカルユーザーインターフェースを介してユー
ザーインプットを受け取ることによって、且つ、前記ディスプレイに、第１及び
第２のポート間での第１及び第２の信号の伝送をまとめて表すために前記第１及
び第２のポートコントロールの間で延びる相互結合要素を表示することによって
、前記第１及び第２の回路コンポーネントのインターフェースを互いにとるよう
に構成された、請求項１１の装置。
【請求項１５】前記第１の回路コンポーネントは第３及び第４の回路コンポーネントをカプセ
ル化し、前記第３及び第４の回路コンポーネントはそれぞれ第３及び第４のポー
トを含んでおり、前記第１のポートは、前記イベントに応答して、前記第１の値を前記第２のポ
ートと前記第３のポートの間で伝えるように、且つ、前記第２の値を前記第２の
ポート及び前記第４のポートの間で伝えるようにさらに構成されている、請求項１１に記載の方法。
【請求項１６】前記第１の値は文字列を含む、請求項１１の装置。
【請求項１７】（ａ）それぞれ第１及び第２のポートを含む第１及び第２のオブジェクト指向
の回路コンポーネントから電子回路設計のモデルを構成し、前記第１及び第２の
回路コンポーネントのインターフェースを前記第１及び第２のポートを介して互
いにとり、ここで、前記第１及び第２のポートは、前記第１及び第２のポートの
うちの少なくとも１つに導かれたイベントに応答して、第１の信号に対する第１
の値と第２の信号に対する第２の値との両方を伝えるように構成されている、プ
ログラムと、（ｂ）前記プログラムを運ぶ信号担媒体と、を有するプログラムプロダクト。
【請求項１８】前記信号担媒体は、少なくとも記録可能媒体及び伝送媒体のうちの１つを含む
、請求項１７に記載のプログラムプロダクト。
【請求項１９】電子回路設計をコンピュータでモデリングする方法であって、（ａ）処理システムモデルによって実行可能な命令を定める少なくとも１つの
命令定義を受け取り、（ｂ）前記命令定義を処理することで、前記命令の実行をシミュレートするた
めの、前記処理システムモデルに対する命令デコーダ回路コンポーネントを構成
する、方法。
【請求項２０】前記命令定義を処理することは、前記命令デコーダ回路コンポーネントを、総
称命令デコーダ回路コンポーネントから動的に生成することを含む、請求項１９の方法。
【請求項２１】（ａ）前記命令定義に応じて前記総称命令デコーダ回路コンポーネントのアイ
コン表示を修正し、（ｂ）前記修正されたアイコン表示をコンピュータディスプレイに表示する、ことをさらに含む請求項２０の方法。
【請求項２２】前記命令定義は、前記命令の実行に応答した複数の信号に対して伝えられる複
数の値を含む、請求項１９の方法。
【請求項２３】シミュレーションの間、前記命令デコーダ回路コンポーネントによる前記命令
定義に合う命令の受領に応じて前記複数の値を伝えることによって、前記モデル
でシミュレーションを実行することをさらに含む、請求項２２の方法。
【請求項２４】前記命令定義はテキスト文字列によって識別され、前記モデルでシミュレーシ
ョンを実行することは前記テキスト文字列を解釈することを含む、請求項２３の
方法。
【請求項２５】前記命令デコーダ回路コンポーネントは、前記複数の信号からの第１の信号に
関連した第１のポートを含み、前記方法はさらに、前記命令デコーダ回路コンポ
ーネントと、第２のポートを含む第２の回路コンポーネントとのインターフェー
スを前記第１のポートを前記第２のポートに接続することによってとることを含
む、請求項２２の方法。
【請求項２６】前記命令定義は、複数の命令定義を含む命令セット定義ファイル内に定められ
、前記命令定義を処理することは、前記命令セット定義ファイルを処理すること
で、前記複数の命令の実行をシュミレーションするための前記命令デコーダ回路
コンポーネントをつくることを含む、請求項１９の方法。
【請求項２７】前記命令セット定義ファイルはさらにレジスタ定義を含み、前記方法はさらに
、前記レジスタ定義を処理して、前記処理システムで利用可能なレジスタを識別
することを含む、請求項２６の方法。
【請求項２８】前記命令セット定義ファイルへの修正に応じて前記デコーダ回路コンポーネン
トを修正することをさらに含む、請求項２６の方法。
【請求項２９】前記命令デコーダ回路コンポーネントを修正することは、前記命令セット定義
ファイルを、前記命令セット定義ファイルへの修正の後に再処理することを含む
、請求項２８の方法。
【請求項３０】前記命令セット定義ファイルのそれそれの命令は、その命令の実行に応答した
複数の信号のうちの少なくとも１つに対して伝えられるべき少なくとも１つの値
を識別し、前記命令セット定義ファイルを処理することは複数のエントリーを含
むデコーダテーブルを形成し、それぞれのエントリーは前記複数の信号からの１
つの信号を識別するものである、請求項２６の方法。
【請求項３１】前記命令セット定義ファイルのそれぞれの命令定義は、アセンブリ言語形式で
前記命令を識別するテキスト識別子を含む、請求項２６の方法。
【請求項３２】（ａ）処理システムモデルをストアするように構成されたメモリと、（ｂ）処理システムモデルによって実行可能な命令を定める少なくとも１つの
命令定義を受け取り、前記命令定義を処理して、前記処理システムモデルに対す
る命令デコーダ回路コンポーネントをつくり、前記命令の実行をシミュレートす
るように構成されたプログラムと、を有する装置。
【請求項３３】前記プログラムは、前記命令デコーダ回路コンポーネントを総称命令デコーダ
回路コンポーネントから動的に生成することによって前記命令定義を処理するよ
うに構成されている、請求項３２の装置。
【請求項３４】前記プログラムはさらに、前記命令定義に応じて前記総称命令デコーダ回路コ
ンポーネントのアイコン表示を修正し、前記修正されたアイコン表示をコンピュ
ータディスプレイに表示するように構成された、請求項３３の装置。
【請求項３５】前記命令定義は、前記命令の実行に応答した複数の信号に対して伝えられるべ
き複数の値を含む、請求項３２の装置。
【請求項３６】前記プログラムは、シミュレーションの間に前記命令デコーダ回路コンポーネ
ントによる前記命令定義に合う命令の受領に応答して、前記複数の値を伝えるこ
とにより前記モデルでシミュレーションを実行するように構成されている、請求
項３５の装置。
【請求項３７】前記命令定義はテキスト文字列によって識別され、前記プログラムは前記テキ
スト文字列を解釈することにより前記モデル上でシミュレーションを実行するよ
うに構成されている、請求項３６の装置。
【請求項３８】前記命令デコーダ回路コンポーネントは、前記複数の信号からの第１の信号に
関連する第１のポートを含み、前記プログラムは、前記命令デコーダ回路コンポ
ーネントと、第２のポートを含む第２の回路コンポーネントとのインターフェー
スを、前記第１のポートを前記第２のポートに接続することによってとるように
さらに構成されている、請求項３５の装置。
【請求項３９】前記命令定義は、複数の命令定義を含む命令セット定義ファイル内に定められ
、前記プログラムは、前記命令セット定義ファイルを処理することによって前記
命令定義を処理して前記命令デコーダ回路コンポーネントをつくり、前記複数の
命令の実行をシュミレーションするように構成された、請求項３２の装置。
【請求項４０】前記プログラムは、前記命令セット定義ファイルへの修正に応答して前記デコ
ーダ回路コンポーネントを修正するように構成されている、請求項３９の装置。
【請求項４１】前記プログラムは、前記命令セット定義ファイルへの修正の後に、前記命令セ
ット定義ファイルを再処理することによって前記命令デコーダ回路コンポーネン
トを修正するように構成されている、、請求項４０の装置。
【請求項４２】前記命令セット定義ファイルのそれそれの命令は、その命令の実行に応答した
複数の信号のうちの少なくとも１つに対して伝えられる少なくとも１つの値を識
別し、前記プログラムは、複数のエントリーを含むデコーダテーブルを形成する
ことによって前記命令セット定義ファイルを処理するように構成されており、こ
こにそれぞれのエントリーは前記複数の信号からの１つの信号を識別するもので
ある、請求項３９の装置。
【請求項４３】（ａ）処理システムモデルによって実行可能な命令を定める少なくとも１つの
命令定義を受け取り、前記命令定義を処理して前記処理システムモデルに対する
命令デコーダ回路コンポーネントを作り、前記命令の実行をシミュレートするよ
うに構成されたプログラムと、（ｂ）前記プログラムを運ぶ信号担媒体と、を有するプログラムプロダクト。