(57)【特許請求の範囲】
【請求項１】
デジタルシステムをシミュレートするためにコンピュータを動作する方法であって、
（ａ）前記コンピュータ内で、複数のインターフェースユニットと複数の機能ユニットとを具備するシミュレーションモデルを生成するステップを備え、前記複数のインターフェースユニットは前記複数の機能ユニット間でメッセージを送信し、そして前記複数の機能ユニットは、前記メッセージにおけるニブルの数に基づいた設計抽象の複数の異なるレベルで規定されており、前記方法はさらに、
（ｂ）前記シミュレーションモデルの実行の間に前記設計抽象の異なるレベルで前記機能ユニットの間で前記メッセージを受け渡しするために、各インターフェースユニット内で、前記メッセージを設計抽象のより高いレベル又はより低いレベルに自動的に組み立てる又は分解するステップを備え、
前記複数の各インターフェースユニットが設計レベルの一つに対応する複数のコアモジュールを具備し、前記方法がさらに、
（ｃ）前記複数の機能ユニットの内のある特定の設計レベルの一つからのメッセージをパスするステップ、
（ｄ）前記特定の設計レベルより高いレベルの全てのコアモジュールに組立リクエストをパスするステップ、及び
（ｅ）前記特定の設計レベル以下の全てのコアモジュールに分解リクエストをパスするステップを具備することを特徴とする方法。
【請求項２】
前記複数のコアモジュールの少なくとも一つが複数の状態マシンを具備し、各状態マシンが、そのコアモジュールのレベルのデータ項目がそれに分解されるべきより低いデータ項目を表し、この方法がさらに、
（ａ）各状態マシンを、分解リクエストが受信された場合は、これに応答して、より低い設計レベルのモジュールにもう一つの分解リクエストを前記より低いレベルに対して適当なデータ項目とともに送信し、その後、前記もう一つの分解リクエストが前記より低いレベルのモジュールによって受理されるまで待ち、受理された時点で動作を完了するように動作させるステップ、及び
（ｂ）各状態マシンを、組立リクエストが受信された場合は、これに応答して、より低いレベルのモジュールが新たなデータ項目を受理するまで待ち、受理された時点で前記より低いレベルのモジュールからのデータ項目を読み出すように動作させるステップを具備することを特徴とする請求項１の方法。
【請求項３】
さらに、
（ａ）インターフェースユニットによって複数の異なる設計レベルにおいてパスされる複数のメッセージを定義するインターフェース定義を作成するステップ、及び
（ｂ）前記インターフェース定義をコンパイル（翻訳）することで、各インターフェースユニットを生成するステップを具備することを特徴とする請求項１または２に記載の方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はデジタルシステムをシミュレートするための方法に関する。本発明はこれに限定されるものではないが、特にコンピュータハードウエアの設計をシミュレートすることに関する。ただし、本発明は他のシステム、例えば、複合ソフトウエアシステムをシミュレートするために用いることもできる。
【０００２】
【従来の技術】
デジタルシステムの設計を、互いに信号を介して通信する複数の機能ユニットとして規定することを可能にする設計言語が知られており、このような設計言語の一つとして、VHDL［ANSI／IEEE標準１０７６］がある。
【０００３】
このような言語を用いることで、機能ユニットを複合モデルのさまざまな異なるレベルにて規定することができる。通常は、各機能ユニットは、最初は、高い設計レベルにおいて非常に抽象的に定義され、その後、設計の発展とともに、次々と、より低い設計レベルにおいてより詳細に定義される。ところで、しばしば異なるユニットの設計が、異なる速度にて進展することが見かけられる。例えば、コンピュータの設計においては、Ｉ／Ｏユニットを設計する仕事は、ＣＵＰ又は記憶ユニットを設計する仕事より簡単であり、このため、Ｉ／Ｏユニットのより低い（詳細な）レベルのモデルが、他のユニットに対する同程度に詳細なモデルの前に達成される。このために、異なるレベルの異なるユニットから構成されるシミュレーションモデルをいかにしてランするかという問題が発生する。
【０００４】
この問題を解決するための一つの方法においては、異なるレベル間の信号を翻訳するための翻訳プログラムが用いられる。例えば、設計がレベル１のユニットＡとレベル２のユニットＢから構成される場合は、翻訳プログラムを用いて、ユニットＡからの出力信号をレベル２に翻訳することで、ユニットＡがユニットＢと通信できるようにされる。
【０００５】
【発明が解決しようとする課題】
ただし、これら翻訳プログラムは手作業にて作成する必要があり、このプログラムを書いたり検証するためには多大な労力が必要となる。実際、このような翻訳プログラムを書いたり検証するためには、しばしばそのユニット自身に対して要求されるよりも多くの労力が必要となる。
【０００６】
本発明の一つの目的は、この問題を克服することができるコンピュータ化された複数の混ざったレベルを含むシミュレーションモデルを提供することにある。
【０００７】
【課題を解決するための手段】
本発明によって、デジタルシステムに対するコンピュータ化されたシミュレーションモデルが提供される。このモデルは複数の機能ユニット及び前記機能ユニット間でメッセージを送信するための複数のインターフェースユニットを具備している。また、各インターフェースユニットは、メッセージをこの設計のより高い又はより低いレベルに自動的に組み立てる又は分解するための機構を具備している。
【０００８】
各インターフェースユニットは、好ましくはそのインターフェースによって設計の複数の異なるレベルをパスされるメッセージを定義するインターフェース定義をコンパイルすることによっで生成される。
【０００９】
【発明の実施の形態】
以下、本発明による一つのシミュレーションモデルを一例として図面を参照しながら説明する。
【００１０】
（概要）
本発明のこの実施例は、VHDL＋と呼ばれるシミュレーション言語を利用するが、この言語は、周知のVHDL言語の拡張である。VHDL言語では、モデルは、複数の機能ユニットと、これら機能ユニット間でパスされる信号として規定される。他方、VHDL＋においては、モデルは、インターフェースを介して互いに通信し合うセットの機能ユニットであるものとみなされ、これらインターフェースは、これら機能ユニット間をパスされるメッセージを定義する宣言形定義として規定される。
【００１１】
図１は、モデル定義１０を示すが、これは、ここで説明する実施例においては、VHDL＋言語によって記述される。このモデル定義１０が、コンパイラ１１によって処理され、コンパイル（翻訳）されたモデル１２が生成される。ここで、コンパイルされたモデル１２は、この実施例においては従来のVHDL言語にて記述される。こうしてコンパイルされたモデル１２は従来のVHDLライブラリ１３にリンクされる。次に、コンパイルされたモデル１２は、シミュレータ１４上でランされるが、このシミュレータ１４は、この実施例においては、従来のVHDLシミュレータである。
【００１２】
本発明のこの実施例においてはVHDL及びVHDL＋言語が用いられるが、理解できるように他の言語を用いることもできる。例えば、コンパイラは、Ｃ言語又はＣ＋＋言語の他の言語にてコンパイルされたモデル１２を記述することもできる。
【００１３】
図１に示すように、モデル定義１０は、複数のユニット定義１５及び複数のインターフェース定義１６から構成される。ユニット定義１５は、複数の機能ユニットを規定し、他方、インターフェース定義は、インターフェースをこれらユニット間でパスされるメッセージとして規定する。
【００１４】
（一例）
図２は、コンパイルされたモデル定義の一部分を示す。これは、３つの機能ユニットＵ１、Ｕ２、Ｕ３を具備し、これらがインターフェースユニットＩ１によって相互接続される。このケースにおいては、機能ユニットＵ１がメッセージを送信し、このメッセージが、機能ユニットＵ２と機能ユニットＵ３の両方によって受信されるものと想定される。さらに、これら機能ユニットＵ１、Ｕ２、Ｕ３は、全て異なる設計レベルにて定義されているものと想定されるが、このことが図面においては、各機能ユニットの垂直軸上の位置によって示される。機能ユニットＵ２は、最も高い（最も抽象的な）設計レベルにて定義されており、各メッセージを１６個のワードのシーケンスとして扱う。機能ユニットＵ１は、次に高い設計レベルにて定義されており、各ワードを２個のバイトのシーケンスからなるものとみなし、各メッセージを３２個のバイトのシーケンスとして扱う。機能ユニットＵ３は、最も低い（最も詳細な）設計レベルにて定義されており、各バイトが２個のニブルからなるものとみなし、各メッセージを６４個のニブルのシーケンスとして扱う。
【００１５】
後に説明するように、インターフェースユニットＩ１は、これら異なる設計レベルを考慮してメッセージを組み立てたり、分解することができる。より詳細には、この実施例においては、インターフェースユニットＩ１は、機能ユニットＵ１からのバイト本位のメッセージを機能ユニットＵ２に対応するワード本位のメッセージに組み立て、また、これを機能ユニットＵ３に対応するニブル本位のメッセージに分解する。
【００１６】
図３は、インターフェースユニットＩ１に対するVHDL＋にて記述されたインターフェース定義を示す。このインターフェース定義は、BYTE（バイト）メッセージを２個のニブルメッセージ、つまり、NIBBLE(B(0))、NIBBLE(B(1))の複合メッセージとして定義し、WORD（ワード）メッセージを、２個のバイトメッセージ、つまり、BYTE(W(0))、BYTE(W(1))の複合メッセージとして定義する。これら全てのメッセージは、送信部分Ｓから受信部分Ｒに流れるものとして規定される。
【００１７】
図４は、機能ユニットＵ１〜Ｕ３に対するVHDL＋にて記述されたユニット定義を示す。第一の定義は、機能ユニットＵ１がメッセージをインターフェースユニットＩ１の送信部分Ｓにメッセージを送信すべきことと、各メッセージが３２個のバイトのストリングから構成されるべきことを示す。第二の定義は、機能ユニットＵ２がインターフェースユニットＩ１の受信部分Ｒからメッセージを受信すべきことと、各メッセージが１６個のワードのストリングから構成されるべきことを示す。第三の定義は、機能ユニットＵ３がインターフェースユニットＩ１の受信部分Ｒからメッセージを受信すべきことと、各メッセージが６４個のニブルのストリングから構成されるべきことを示す。
【００１８】
（インターフェースユニット）
図５は、図２のインターフェースユニットＩ１の構造をより詳細に示す。
【００１９】
このインターフェースユニットは、トップレベルに位置するプロトコルコアモジュール５１と、インターフェースの各定義レベルに対応する他の複数のコアモジュール５２〜５４を含む。この実施例においては、これらコアモジュールは、ワードコアモジュール５２、バイトコアモジュール５３、ニブルコアモジュール５４から構成される。これらコアモジュール５２〜５４は、自身と関連するアービタ(arbiters)５５〜５７を持ち、これらアービタは、外部リクエスト（REQext）及び内部リクエスト（REQint）を受信する。
【００２０】
これら外部リクエストは、メッセージをこのインターフェースに送信した機能ユニットから送られる。この実施例においては、機能ユニットＵ１は、外部リクエストをバイトレベルのアービタ５６に送信する。各アービタは、一つの外部リクエスト入力のみを持ち、複数の機能ユニットがメッセージをインターフェースに送信した場合は、他のアービタ（図示せず）を用いて、これら外部リクエストが１つに低減される。
【００２１】
内部リクエストは、より高い設計レベルのコアモジュールから送られる。例えば、バイトレベルのアービタ５６は、ワードコアモジュール５２からのリクエストを受信する。一つのアービタに対して複数のリクエスト入力を設けることも考えられる。例えば、インターフェースが他のコアモジュール（図示せず）を具備し、これらコアモジュールもニブルコアモジュール５４にリクエストを送ることも考えられる。
【００２２】
外部リクエストは、２つの値、つまり、Decompose（分解）又はInert（不活性）のいずれか１つを取る。Decomposeリクエストは、送信ユニット（この実施例においては機能ユニット１）からのデータ項目をインターフェースに送信するリクエストである。このリクエストには、送信されるべきデータ項目（この実施例においてはデータのバイト）が付加される。Inert値は、単に、Decomposeリクエストの不在を示す。
【００２３】
内部リクエストは、３つの値、つまり、Compose（組立）、Decompose（分解）、Inert（不活性）のいずれか一つを取る。Composeリクエストは、要求コアモジュールがより高い設計レベルのデータ項目を組み立てる準備ができたことを示し、受信コアモジュールに対して次のより低い設計レベルのデータ項目をこの組み立てのために供給することをリクエストする。例えば、ワードコアモジュール５２からバイトコアモジュール５３に送られるComposeリクエストは、ワードコアモジュール５２がバイトコアモジュール５３からのバイトを、ワードに組み立てるために受信する準備が整ったことを示す。Decomposeリクエストは、要求コアモジュールが、より高い設計レベルのデータ項目を複数のより低い設計レベルの項目に分解していることを示し、このリクエストには、より低い設計レベルのデータ項目の一つが付加される。例えば、バイトコアモジュール５３からニブルコアモジュール５４に送信されるDecomposeリクエストには１つのニブルが付加される。Inert値は、単に、ComposeリクエストもDecomposeリクエストも存在しないことを示す。
【００２４】
アービタの機能は、複数の同時に送信されるリクエストの一つを選択し、選択されたリクエストを関連するデータとともに、関連するコアモジュールにパスすることにある。アービタは、どのリクエストが選択されたかを記憶しており、そのリクエストを発信したコアユニットにACCEPT（受理）信号を送り返す。アービタは、同時に送信されるリクエストを以下のテーブルに従って選択する、
外部リクエスト 内部リクエスト コアへの出力
Inert               all Inert                  Inert
Inert               any Compose, rest Inert    Compose
Inert               any Decompose              Decompose
Decompose           all Inert                  Inert
Decompose           any Compose, rest Inert    Decompose
Decompose           any Decompose              Decompose
【００２５】
これらコアモジュールの一つがアクティブであり、データをインターフェースに送っている場合、そのコアモジュールは、ACTIVE（活動）信号を高値にし、これによって、（存在する場合）同一の設計レベルの受信側機能ユニットに対してデータが存在することを知らせる。ACTIVE信号は、インターフェース内の（存在する場合）より高い設計レベルのコアモジュールにも供給される。この実施例においては、ワードコアモジュール５２はACTIVE信号を受信側機能ユニットＵ２に送信し、バイトコアモジュール５３はACTIVE信号をワードコアモジュール５２に送信し、ニブルコアモジュール５４はACTIVE信号をバイトコアモジュール５３と受信側機能ユニットＵ３に送信する。
【００２６】
（コアモジュール）
図５のコアモジュールは、複合状態マシンであり、より単純な複数の状態マシンを互いに接続することによって形成される。これらより単純な複数の状態マシンは、より低い設計レベルのメッセージを表し、各レベルにおいてメッセージがこれら低い設計レベルのメッセージに分解される。
【００２７】
図６に移り、この実施例においては、ワードコアモジュール５２は、直列に接続されたバイト（０）状態マシン６１とバイト（１）状態マシン６２から構成され、各状態マシンは、ワードがそれに分解される一連の２個のバイトに対応する。同様に、バイトコアモジュール５３は、直列に接続されたニブル（０）状態マシン６３とニブル（１）状態マシン６４から構成され、各状態マシンは、バイトがそれに分解される一連の２個のニブルに対応する。ニブルコアモジュール５４は、この実施例においてはニブルはこれ以上は分解することができないために状態マシンは含まない。
【００２８】
状態マシン間の他の接続パターンも可能であることに注意する。例えば、インターフェース定義が、ワードを、この実施例の場合のように直列ではなく、並列に送信される２個のバイトとして定義する場合は、ワードコアモジュールは、並列に接続された２個のバイト状態マシンから構成し、追加のＡＮＤゲートにより、これら状態マシンの両方とも動作を完了したか否かを決定することも考えられる。別の方法として、インターフェース定義によって、受信された２個のバイトの最初のバイトを送信することが要求される場合は、ワードコアモジュールは、並列に接続された２個のバイト状態マシンから構成し、追加のＯＲゲートにより、これら２個の状態マシンの最初の動作が完了したことを検出することも考えられる。
【００２９】
（一般状態マシン）
これら全ての状態マシン６１〜６４は、図７に示す一般状態マシンのインスタンスであり、この一般状態マシンは、以下の状態、つまり、IDLE、D_REQUESTED、D_STARTED、C_WAITING、C_STARTED、FINISHEDから構成される。
【００３０】
IDLE状態は、状態マシンが最初に喚起されたときに入る状態である。この状態においては、状態マシンは、Decomposeリクエスト又はComposeリクエストを待つ。Decomposeリクエストが受信された場合は、状態マシンは、インターフェースの次に低い設計レベルにDecomposeリクエストをデータ項目とともに送信し、その後、D_REQUESTED状態に移る。Composeリクエストが受信された場合は、状態マシンは、より低い設計レベルにComposeリクエストを送信し、その後、C_WAITING状態に移る。
【００３１】
D_REQUESTED状態においては、状態マシンは、より低い設計レベルからDecomposeリクエストが受理されたことを示すACCEPT信号が返信されるのを待ち、受信された時点でD_STARTED状態に移る。
【００３２】
D_STARTED状態においては、状態マシンは、より低い設計レベルがそのACCEPT 信号を取り消すのを待ち、取り消された時点でFINISHED状態に移る。
【００３３】
C_WAITING状態においては、状態マシンは、より低い設計レベルからのDecomposeリクエスト又はACTIVE信号を待つ。Decomposeリクエストが受信された場合は、状態マシンは、より低い設計レベルにDecomposeリクエストをデータ項目とともに送信し、その後、D_REQUESTED状態に移る。ACTIVE信号が受信された場 合は、状態マシンは、C_STARTED状態に移る。
【００３４】
C_STARTED状態においては、状態マシンは、より低い設計レベルからのACTIVE信号が取り消されるのを待つ。取り消された時点で、状態マシンは、より低い設計レベルからのデータ項目を読み出し、その後、FINISHED状態に移る。
【００３５】
（インターフェースの動作）
インターフェースは、以下のように初期化される。プロトコルコアモジュール５１がComposeリクエストをワードコアモジュール５２に送信する。これに応答して、ワードコアモジュール５２内のバイト（０）状態マシン６１は、Composeリクエストをバイトコアモジュール５３に送信し、その後、バイト（０）状態マシン６１は、C_WAITING状態に移る。今度は、バイトコアモジュール５３内のニブル（０）状態マシン６３が、Composeリクエストをニブルコアモジュール５４に送信し、ニブル（０）状態マシン６３もC_WAITING状態に移る。ニブルコアモジュール５４へのComposeリクエストは、ニブルコアモジュール５４は状態マシンを持たないために破棄される。
【００３６】
機能ユニットＵ１が、機能ユニットＵ２及びＵ３にメッセージを送信したい場合は、機能ユニットＵ１は一連のバイトをインターフェースユニットＩ１のアービタ５６に送信する。各バイトにはDecomposeリクエストが付加される。
【００３７】
第一のDecomposeリクエストに応答して、ニブル（０）状態マシン６３は、ニブルコアモジュール５４に、Decomposeリクエストをバイトの最初のニブルとともに送信し、その後、ニブル（０）状態マシン６３はD_REQUSTED状態に移る。次に、バイトコアモジュール５３がそのACTIVE信号を高値にし、自身が現在アクティブであることを示し、アービタ５６がそのACCEPT信号を高値にし、機能ユニットＵ１に対してリクエストが受理されたことを示す。
【００３８】
バイトコアモジュール５３からACTIVE信号を受信すると、ワードコアモジュール５２内のバイト（０）状態マシン６１はC_STARTED状態に移り、ワードコアモジュール５２はアクティブになる。ワードコアモジュール５２がアクティブになるのを待っていた機能ユニットＵ２は、ここでデータの受信を開始する。
【００３９】
ニブルコアモジュール５４はバイトコアモジュール５３からDecomposeリクエストを受信するとアクティブになる。ニブルコアモジュール５４がアクティブになるのを待っていた機能ユニットＵ３は、ここでデータの受信を開始する。アービタ５７は、そのACCEPT信号を高値にし、Decomposeリクエストが受理されることを示す。
【００４０】
アービタ５７からACCEPT信号が受信されると、ニブル（０）状態マシン６３はD_STARTED状態に移る。次に、ACCEPT信号が取り消されると、ニブル（０）状態 マシン６３はFINISHED状態に移る。これにより、今度は、ニブル（１）状態マシン６４がアクティブになる。
【００４１】
バイトコアモジュール５３は、まだ元のDecomposeリクエストを受信しているために、ニブル（１）状態マシン６４はD_REQUESTED状態に移り、次に、ニブルコアモジュール５４にもう一つのDecomposeリクエストをバイトの第二のニブルとともに送信する。上述と同様に、アービタ５７は、自身のACCEPT信号を高値にすることで、Decomposeリクエストが受理されたことを示す。このACCEPT信号を受信すると、ニブル（１）状態マシン６４はD_STARTED状態に移る。次に、ACCEPT信号が取り消されると、ニブル（１）状態マシン６４はFINISHED状態に移る。
【００４２】
ニブル（１）状態マシン６４の動作が終了すると、バイトコアモジュール５３は、自身のACTIVE信号を取り消すとともに、機能ユニットＵ１へのACCEPT信号も取り消す。ACTIVE信号が取り消されると、バイト（０）状態マシン６１は、第一のバイトをワードコアモジュール５２に送った後にFINISHED状態に移り、バイト（１）状態マシン６２がアクティブとなる。
【００４３】
上記説明から理解できるように、ここまでの動作で、第一のバイトが２個のニブルに分解され、これらが機能ユニットＵ３に送信され、一方ワードコアモジュール５２は、１バイトを読み出している。インターフェースは、ほぼ初期の状態に戻っている。ただし、異なる点として、ワードコアモジュール５２がまだアクティブであり、バイト（１）状態マシン６２がC_WAITING状態にあって、機能ユニットＵ１が第二のバイトを送信するのを待っている。
【００４４】
機能ユニットＵ１が第二のバイトを送信すると上述のステップが反復される。今回は、バイト（１）状態マシン６２がFINISHED状態に移ると、ワードコアモジュール５２は非アクティブとなり、受信機能ユニットＵ２はそのワードの受信を完了する。
【００４５】
上述の動作がメッセージ内の一連のペアのバイトの各々に対して反復される。
【００４６】
（議論）
上記説明から理解できるように、上述のインターフェースは、任意のレベルの機能ユニットが他の任意のレベルの機能ユニットと通信することを可能にする一般的機構を与える。例えば、最も高いレベルの（ワード本位の）機能ユニットがメッセージを最も低いレベルの（ニブル本位の）機能ユニットに送ることを可能にするためにこれと同一のインターフェースを用いることもできる。
【００４７】
このインターフェース内のこれら状態マシンは、それらの現在の環境に従ってメッセージが組み立てられるべきか又は分解されるべきかを自動的に制御し、情報がインターフェースの階層内を上方に及び／又は下方に正しく流れるのを助ける。
【００４８】
（幾つかの可能な変更実施例）
理解できるように上述のシステムに対して多くの変更・修正を本発明の範囲から逸脱することなく行うことができる。例えば、上述とは異なる設計定義言ワード又はシミュレータを用いることもできる。さらに、ワード、バイト、及びニブルに基づく上述のインターフェース階層は、単に一例にすぎず、メッセージを分解するための他の多くの異なる方法を規定することもできる。
【図面の簡単な説明】
【図１】シミュレーションモデル及びこのモデルがモデル定義からコンパイル（翻訳）される方法を示すブロック図である。
【図２】複数の機能ユニットと一つのインターフェースユニットから構成されるモデルの一部分を示すブロック図である。
【図３】図２のインターフェースユニットに対するインターフェース定義を示す。
【図４】図２の機能ユニットに対するセットの機能ユニット定義を示す。
【図５】インターフェースユニットをより詳細に示すブロック図である。
【図６】インターフェースユニットの一部分を形成するコアモジュールの内部構造を示すブロック図である。
【図７】一般状態マシンを示す状態図であるが、この状態マシンの複数のインスタンスが各コアモジュール内で用いられる。
【符号の説明】
１０  モデル定義
１１  コンパイラ
１２  コンパイル（翻訳）されたモデル
１３  VHDLライブラリ
１４  シミュレータ
１５  ユニット定義
１６  インターフェース定義
Ｕ１〜Ｕ３  機能ユニット
Ｉ１  インターフェースユニット
５１  プロトコルコアモジュール
５２  ワードコアモジュール
５３  バイトコアモジュール
５４  ニブルコアモジュール
５５〜５７  アービタ
６１  バイト（０）状態マシン
６２  バイト（１）状態マシン
６３  ニブル（０）状態マシン
６４  ニブル（１）状態マシン
【図１】
0004215876.tif 000002
【図２】
0004215876.tif 000003
【図３】
0004215876.tif 000004
【図４】
0004215876.tif 000005
【図５】
0004215876.tif 000006
【図６】
0004215876.tif 000007
【図７】
0004215876.tif 000008