(57)【要約】【課題】  レーシング発生時のデバッグを容易に行うことができる論理シミュレータを得る。【解決手段】  論理シミュレータ１０はハードウェア記述言語（ＨＤＬ）によって記述された論理回路モデルの動作をシミュレーションするものであって、ハードウェア記述言語からシミュレーションの実行に必要なデータを作成するＨＤＬ処理部１００と、データを用いてシミュレーションを実行するシミュレーション実行部１１０を備え、シミュレーション実行部１１０は、同一シミュレーション時刻におけるデルタ遅延付き代入処理を行うためのデルタサイクル数をカウントする。【選択図】        図１
2006011961.tif 000002
【特許請求の範囲】
【請求項１】
ハードウェア記述言語によって記述された論理回路モデルの動作をシミュレーションする論理シミュレータにおいて、
上記ハードウェア記述言語からシミュレーションの実行に必要なデータを作成するハードウェア記述言語処理部と、
上記データを用いてシミュレーションを実行するシミュレーション実行部を備え、
上記シミュレーション実行部は、同一シミュレーション時刻におけるデルタ遅延付き代入処理を行うためのデルタサイクル数をカウントするデルタサイクル数カウント手段を有することを特徴とする論理シミュレータ。
【請求項２】
上記シミュレーション実行部は、デルタサイクル数カウント手段によってカウントされたデルタサイクル数を出力するデルタサイクル数出力手段を備えたことを特徴とする請求項１記載の論理シミュレータ。
【請求項３】
ハードウェア記述言語処理部は、ある変数に対してデルタ遅延付き代入が実行された時のデルタサイクル数を変数毎に保持するデルタカウント数保持手段を備え、
シミュレーション実行部は、上記変数にデルタ遅延付き代入が実行された際に、保持されている前回デルタ遅延付き代入が実行された時のデルタカウント数と現在のデルタカウント数を比較し、２つの値が異なる場合には、警告を通知するデルタカウント数チェック手段を備えたことを特徴とする請求項１記載の論理シミュレータ。
【請求項４】
ハードウェア記述言語処理部は、ある変数に対してデルタ遅延付き代入が実行された時のデルタサイクル数を全変数共通に保持するデルタカウント数保持手段を備え、
上記変数にデルタ遅延付き代入が実行された際に、保持されている前回デルタ遅延付き代入が実行された時のデルタカウント数と現在のデルタカウント数を比較し、２つの値が異なる場合には、警告を通知するデルタカウント数チェック手段を備えたことを特徴とする請求項１記載の論理シミュレータ。
【請求項５】
シミュレーション実行部は、デルタカウント数チェック手段によるデルタカウント数の比較を行うか否か切り替えるデルタカウント数チェック切り替え手段を備えたことを特徴とする請求項３または請求項４記載の論理シミュレータ。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、論理シミュレータに関するものである。
【背景技術】
【０００２】
ハードウェア記述言語（ＨＤＬ言語）によって記述された論理回路のモデルの動作をシミュレーションするための論理シミュレータの方式の１つとして、イベントドリブン方式がある。これは、並列動作の最小単位のモデルであるプロセスと、プロセスの実行によって発生するイベントとを管理し、各イベントの発生時に、そのイベントに関連付けられたプロセスを起動するというものである。
【０００３】
従来のイベントドリブン型論理シミュレータの処理方式の特徴の１つとして、デルタ遅延付き代入処理とそれに伴うデルタサイクル処理がある。デルタ遅延付き代入処理を利用することにより、例えば同時刻のイベントで起動されるプロセスが複数存在し、あるプロセスで０遅延で更新される変数について、他のプロセスでは更新前の値を参照したいような場合に、当該変数の更新処理をデルタ遅延付き代入処理とすることによって、同じデルタサイクル内では、当該他のプロセスで必ず更新前の値が参照されるようにすることができる。１回のデルタサイクルは、プロセスを実行するフェーズと変数を更新するフェーズから構成される。デルタ遅延付き代入が適用される例としては、素子に遅延を付けないレジスタトランスファレベルのモデリングにおける、フリップフロップ等が上げられる。また、デルタ遅延付き代入処理の具体例としては、Ｖｅｒｉｌｏｇ−ＨＤＬにおける遅延指定の無いノンブロッキング代入や、ＳｙｓｔｅｍＣにおけるｓｃ＿ｓｉｇｎａｌ等のプリミティブチャネルへのｗｒｉｔｅがある。
【０００４】
しかし、従来の論理シミュレータでは、同時刻のイベントで起動される各プロセスが、同時刻内の何回目のデルタサイクルで実行されているかについては知る方法がなかった。そのため、プロセス間でデルタ遅延付き代入を介したデータ転送を行うような場合に、それらのプロセスが実行されるデルタサイクルが異なっているためにモデル設計者の意図に反して更新後の変数の値を参照してしまうような現象（レーシング）が発生した際に、デバッグが非常に困難であるという問題があった。
【０００５】
このような問題の解決手段として、例えば特許文献１に記載された従来の論理シミュレーション装置では、順序回路のプロセスを起動する信号（クロック）を予め抽出しておき、クロックを変化させるプロセスを同一時刻内に実行されるプロセスの最初に実行することにより、順序回路のプロセスが必ず同一デルタサイクルで起動されるようにしている。
また、特許文献２に記載された従来の論理シミュレータ装置や、特許文献３に記載された従来の論理シミュレーション方式では、同一時刻におけるプロセスの実行順或いはイベントの処理順をユーザが指定できるようにすることで、ユーザが意図した通りのシミュレーションが実行されるようになっている。
【０００６】
【特許文献１】特開２００３−３６２８３号公報
【特許文献２】特開２００２−２６９１７０号公報
【特許文献３】特開平６−２５９４９５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかし、特許文献１に開示された方法では、ＨＤＬ記述を読み込む際にクロック抽出を行うための余分の解析が必要である。また、クロックを変化させるプロセスを他のプロセスとは異なる扱いとするため、シミュレーション実行時のオーバーヘッドが発生する。また、レジスタトランスファレベルより高位の動作レベルのＨＤＬ記述に対して適用することが困難であるという問題がある。
また、特許文献２および特許文献３に開示された方法では、プロセスやイベントをユーザの指定通りに処理することによるシミュレーション時のオーバーヘッドが発生する。また、プロセスやイベントの処理順をユーザが指定するため、ユーザの負荷が大きいという問題がある。
【０００８】
この発明は上記のような課題を解決するためになされたもので、レーシング発生時のデバッグを容易に行うことができる論理シミュレータを得ることを目的とする。
【課題を解決するための手段】
【０００９】
この発明に係る論理シミュレータは、ハードウェア記述言語によって記述された論理回路モデルの動作をシミュレーションする論理シミュレータであって、ハードウェア記述言語からシミュレーションの実行に必要なデータを作成するハードウェア記述言語処理部と、データを用いてシミュレーションを実行するシミュレーション実行部を備え、シミュレーション実行部は、同一シミュレーション時刻におけるデルタ遅延付き代入処理を行うためのデルタサイクル数をカウントするデルタサイクル数カウント手段を有するものである。
【発明の効果】
【００１０】
この発明によれば、シミュレーション実行部が同時刻におけるデルタサイクル数をカウントするようにしたので、例えば異なる２つのプロセス間でのレーシングが疑われる場合に、それぞれのプロセス実行中のデルタサイクル数によって、レーシングの有無を確認することが可能となり、デバッグを容易に行うことができる。
【発明を実施するための最良の形態】
【００１１】
以下、この発明の実施の様々な形態を説明する。
実施の形態１．
図１は、この発明の実施の形態１による、論理シミュレータ１０の構成を示すブロック図である。図に示すように、論理シミュレータ１０は、ＨＤＬ処理部（ハードウェア記述言語処理部）１００、シミュレーション実行部（デルタサイクル数カウント手段、デルタサイクル数出力手段）１１０、内部データ記憶部１２０を備えている。ＨＤＬ処理部１００、シミュレーション実行部１１０は、論理シミュレータ１０の演算処理装置を構成する部分であり、内部データ記憶部１２０は、論理シミュレータ１０のメモリを構成する部分である。
【００１２】
次に、動作について説明する。
まず、論理シミュレータ１０の動作の概要を説明する。
論理シミュレータ１０は、入力されたＨＤＬ記述２０に従ってシミュレーションを行い、シミュレーション結果をシミュレーション結果ファイル３０として出力するか、ディスプレイ等の出力装置にシミュレーション結果４０として出力する。ＨＤＬ処理部１００は、ＨＤＬ記述２０から内部データを作成し、内部データ記憶部１２０に格納する。
シミュレーション実行部１１０は、内部データ記憶部１２０に格納された内部データを用いてシミュレーションを実行する。
内部データには、プロセス実行コード２００、プロセスリスト２１０、実行可能プロセスリスト２２０、イベントリスト２３０、予約イベントリスト２４０、信号リスト２５０が含まれる。
プロセス実行コード２００は、プロセス毎に生成され、シミュレーション実行部１１０によって実行される。プロセス実行コード２００は、シミュレーション開始後に生成されることはなく、削除されることもない。プロセスリスト２１０は、プロセス毎の管理情報を保持する。ここで管理情報には、対応するプロセス実行コード２００へのポインタ、当該プロセスの起動条件となるイベント、プロセスの実行可能／不可の状態、初期実行の要否などが含まれる。起動条件となるイベントには、ＨＤＬ処理時に静的に決まるものと、シミュレーション実行中に動的に決まるものとがあり、それぞれ静的センシティビティ、動的センシティビティと呼ぶ。
【００１３】
実行可能プロセスリスト２２０は、起動条件となるイベントからの通知により、実行可能状態となったプロセスのリストである。
イベントリスト２３０には、ＨＤＬ記述２０内で明示的に宣言されたイベント、ＨＤＬ処理部１００においてＨＤＬ記述２０から副次的に生成されるイベント、およびシミュレーション実行部１１０におけるプロセス実行時に動的に生成されるイベントが含まれ、イベント毎に、それらが起動するプロセスのリスト、予約通知時刻等が保持されている。
予約イベントリスト２４０は、通知を予約されたイベントのリストであり、予約時刻順にソートされた状態で管理される。
信号リスト２５０は、値の変化によってイベントを発生させるオブジェクトのリストである。例えば、Ｖｅｒｉｌｏｇ−ＨＤＬであれば、ｒｅｇ宣言された変数が、ＳｙｓｔｅｍＣであれば、ｓｃ＿ｓｉｇｎａｌ等のプリミティブチャネルがこれに当たる。
【００１４】
次に、シミュレーション実行部１１０におけるシミュレーションの動作について詳しく説明する。
図２は、実施の形態１による論理シミュレータ１０のシミュレーション実行部１１０の動作のフローチャートである。まず、シミュレーション実行部１１０が保持するシミュレーションの現在時刻を示す変数が０に設定される（ステップＳＴ１）。次に、シミュレーション実行部１１０が保持するデルタカウント値ｄｅｌｔａ＿ｃｏｕｎｔが０に初期化される（ステップＳＴ２）。ｄｅｌｔａ＿ｃｏｕｎｔは、実行したデルタサイクル数をカウントするための変数である。
次に、シミュレーション実行部１１０は、プロセスリスト２１０から初期実行が必要なプロセスを抽出し、実行可能プロセスリスト２２０に登録する（ステップＳＴ３）。初期実行が必要なプロセスとは、例えばＶｅｒｉｌｏｇ−ＨＤＬであれば、ｉｎｉｔｉａｌブロックに記述されたプロセスであり、ＳｙｓｔｅｍＣであれば、ＭＥＴＨＯＤプロセスやＴＨＲＥＡＤプロセスである。
【００１５】
ステップＳＴ４からは３重のループに入る。１段目のループは、ステップＳＴ４〜ステップＳＴ６で構成され、即時実行可能な全プロセスを実行する。２段目のループは、ステップＳＴ４〜ステップＳＴ９（デルタサイクル）で構成され、同一時刻内の全デルタサイクルを実行する。３段目のループは、ステップＳＴ４〜ステップＳＴ１４で構成され、時刻を進めながら終了時刻になるまでシミュレーションを実行する。
【００１６】
ステップＳＴ４では、シミュレーション実行部１１０は、実行可能プロセスリスト２２０に登録されたプロセスの有無をチェックする。プロセスがあればステップＳＴ５に進み、無ければステップＳＴ７に進む。
ステップＳＴ５では、実行可能プロセスリスト２２０からプロセスを１つ選んで実行し、そのプロセスを実行可能プロセスリスト２２０から削除する。プロセスの実行中に、即時通知のイベント、デルタ遅延付きのイベントまたは代入、および一定時間後に通知されるイベントが発生する場合がある。デルタ遅延付き代入では、値の更新及び値の更新によるイベントの通知をすぐに行わず予約しておく。予約された値の更新は、後のステップＳＴ７で実行される。また、一定時間後に通知されるイベントが発生した場合は、そのイベントを予約イベントリスト２４０に加え、予約時刻順にソートしておく。
【００１７】
プロセス実行中に即時通知のイベントが発生した場合には、そのイベントによって起動されるプロセスを直ちに実行可能プロセスリスト２２０に加える（ステップＳＴ６）。処理後はステップＳＴ４に戻る。
ステップＳＴ７では、１段目のループ内のプロセス実行中に発生したデルタ遅延付き代入により予約された値の更新を行い、それに伴い発生するイベントによって起動されるプロセスを、実行可能プロセスリスト２２０に加える。
上述のステップＳＴ４〜ステップＳＴ６を評価フェーズ、ステップＳＴ７を更新フェーズと呼び、デルタサイクルは評価フェーズと更新フェーズからなる。
【００１８】
ステップＳＴ８では、実行可能プロセスリスト２２０に登録されたプロセスの有無をチェックする。プロセスが登録されていれば、１回目のデルタサイクルを終了し、次のデルタサイクルの処理に移る前にｄｅｌｔａ＿ｃｏｕｎｔを１インクリメントし（ステップＳＴ９）、ステップＳＴ４に戻って次のデルタサイクルを実行する。
プロセスが登録されていなければ、２段目のループ（デルタサイクル）を抜け、ステップＳＴ１０に進む。
【００１９】
ステップＳＴ１０では、予約イベントリスト２４０に登録されたイベントの有無をチェックする。予約されたイベントがあればステップＳＴ１１に進み、無ければシミュレーションを終了する。
ステップＳＴ１１では、予約イベントリスト２４０の先頭に登録されているイベントの予約時刻まで現在時刻を進める。
次に、シミュレーション終了時刻が指定されている場合には、現在時刻と指定された終了時刻を比較し、終了時刻に達している場合にはシミュレーションを終了する。そうでない場合にはステップＳＴ１３に進む（ステップＳＴ１２）。
ステップＳＴ１３では、予約時刻と現在時刻とが等しいイベントを予約イベントリスト２４０から削除し、それらのイベントに起動されるプロセスを実行可能プロセスリスト２２０に加える。
ステップＳＴ１４では、当時刻での処理を終了し、次の時刻での処理に移る前にｄｅｌｔａ＿ｃｏｕｎｔを０にクリアする。以下、ステップＳＴ４に戻り、この時刻における処理を開始する。
【００２０】
次に、ｄｅｌｔａ＿ｃｏｕｎｔ値の出力処理について説明する。
図３は、シミュレーション実行部１１０の保持するｄｅｌｔａ＿ｃｏｕｎｔ値を表示させるＨＤＬ記述の例である。Ｖｅｒｉｌｏｇ−ＨＤＬの例では、＄ｄｅｌｔａ＿ｃｏｕｎｔというシステムタスクがｄｅｌｔａ＿ｃｏｕｎｔ値を返している。ＳｙｓｔｅｍＣの例では、ｓｃ＿ｄｅｌｔａ＿ｃｏｕｎｔというグローバル関数がｄｅｌｔａ＿ｃｏｕｎｔ値を返している。ユーザがデバッグを行いたいプロセス内にこれらの記述を追加すると、ＨＤＬ処理部１００はｄｅｌｔａ＿ｃｏｕｎｔを表示するようなプロセス実行コードを生成する。これにより、実行中のプロセスのｄｅｌｔａ＿ｃｏｕｎｔ値をシミュレーション結果ファイル３０として出力したり、ディスプレイ等の出力装置にシミュレーション結果４０として出力することが可能となり、ユーザがｄｅｌｔａ＿ｃｏｕｎｔ値を知ることができる。
【００２１】
以上のように、この実施の形態１によれば、シミュレーション実行部１１０が同時刻におけるデルタサイクル数をカウントし、実行中のプロセスのデルタサイクル数を出力するようにしたので、例えば異なる２つのプロセス間でのレーシングが疑われる場合に、それぞれのプロセス実行中のｄｅｌｔａ＿ｃｏｕｎｔ値によってレーシングの有無を確認することが可能となり、デバッグを容易に行うことができる。
【００２２】
また、さらにレーシングの発生を予防することも可能であり、以下にその応用例について説明する。
図４は、Ｖｅｒｉｌｏｇ−ＨＤＬを用いた実施の形態１の応用例を説明する図である。図中のａｌｗａｙｓブロック（Ｐｒｏｃｅｓｓ１）では、ｃｌｋの最初の立ち上がりで変数Ｂにデルタ遅延付き代入を行っている（ｌｉｎｅ２）。その後１００サイクル待ってからもう一度同じ代入を行う（ｌｉｎｅ５）。ここで重要なのは、１００サイクル待つという動作を、ｃｌｋの立ち上がりエッジを１００回待つのではなく、１００サイクル分の時間を進めるという方法で実現している点である（ｌｉｎｅ３）。つまり、ｃｌｋの立ち上がりエッジを１００回待つ方法では、Ｐｒｏｃｅｓｓ１は待っている間１００回起動されてしまうが、図４に示す方法では一度も起動されることがないため、シミュレーションがより高速に行われる。
シミュレーション実行時の処理を詳細に説明すると、ｌｉｎｅ３の処理時に１００サイクル時間後に通知されるようなイベントを生成し、このプロセスの動的センシティビティにそのイベントを登録した上で、次に起動されるのを待つことになる。
【００２３】
ここで問題となるのは、”ｐｏｓｅｄｇｅ  ｃｌｋ”というイベントで起動された場合（ｌｉｎｅ２実行時）と、動的に生成したイベントで起動された場合（ｌｉｎｅ５実行時）とで、それぞれｄｅｌｔａ＿ｃｏｕｎｔ値が異なっている可能性があるという点である。変数Ｂを参照しているａｌｗａｙｓブロック（Ｐｒｏｃｅｓｓ２）は、ｃｌｋの立ち上がりで起動されるため、変数Ｂの参照時（ｌｉｎｅ６実行時）のｄｅｌｔａ＿ｃｏｕｎｔ値は、ｌｉｎｅ２実行時のｄｅｌｔａ＿ｃｏｕｎｔ値に等しく、ｌｉｎｅ２実行時にはレーシングが発生することはない。しかし、もしｌｉｎｅ５実行時のｄｅｌｔａ＿ｃｏｕｎｔ値がこれより小さいと、Ｐｒｏｃｅｓｓ２では後のデルタサイクルで更新後の値を参照することになり、レーシングが発生する。
【００２４】
そこで、図４の例では、ｌｉｎｅ２の実行前にｄｅｌｔａ＿ｃｏｕｎｔ値を変数ｄｅｌｔａ＿ｃｏｕｎｔ＿ｏｆ＿ｃｌｋに記憶しておき（ｌｉｎｅ１）、ｌｉｎｅ５実行時のｄｅｌｔａ＿ｃｏｕｎｔ値がこれより小さい場合に限り、ｃｌｋの立ち上がりエッジを待つ（ｌｉｎｅ４）ことで、ｌｉｎｅ５実行時のｄｅｌｔａ＿ｃｏｕｎｔ値とｌｉｎｅ２実行時のｄｅｌｔａ＿ｃｏｕｎｔ値を合わせるようにしている。もし、ｌｉｎｅ５実行時とｌｉｎｅ２実行時のｄｅｌｔａ＿ｃｏｕｎｔ値が合っているにも関わらずｃｌｋの立ち上がりエッジを待つと、ｌｉｎｅ５は意図するより１つ後のｃｌｋエッジで実行されてしまう。
以上のようにｄｅｌｔａ＿ｃｏｕｎｔ値を利用することにより、レーシングの発生を予防することができる。
【００２５】
また、実施の形態１によれば、基本的なプロセスやイベントの処理フロー中に、ｄｅｌｔａ＿ｃｏｕｎｔのクリアとインクリメントの処理を追加すればよいので、ユーザに余計な作業負担をかけず、またシミュレーション性能に対するオーバーヘッドを極微にすることができる。また、高位動作モデルからレジスタトランスファレベルまで幅広く適用することができる。
【００２６】
実施の形態２．
実施の形態２による論理シミュレータは、実施の形態１による論理シミュレータ１０と同様の構成であるが、実施の形態２では、デルタ遅延付き代入実行時にｄｅｌｔａ＿ｃｏｕｎｔ値のチェックを行う。
【００２７】
実施の形態２では、ＨＤＬ処理部（デルタカウント数保持手段）１００は、信号リスト２５０内のデルタ遅延付き代入が実行可能な各変数に対し、デルタ遅延付き代入実行時のｄｅｌｔａ＿ｃｏｕｎｔ値を保持する領域ｍ＿ｄｅｌｔａを確保する。このｍ＿ｄｅｌｔａ値は、シミュレーション開始時に−１に初期化される。
また、シミュレーション実行部（デルタカウント数チェック手段、デルタカウント数チェック切り替え手段）１１０において、ｄｅｌｔａ＿ｃｏｕｎｔチェックを行うか否かを表す変数ｄｅｌｔａ＿ｃｈｅｃｋを保持している。ｄｅｌｔａ＿ｃｈｅｃｋ値はシミュレーション開始時にｔｒｕｅに初期化される。
【００２８】
シミュレーション実行部１１０は、プロセス内でデルタ遅延付き代入を実行した際、ｄｅｌｔａ＿ｃｈｅｃｋの値がｔｒｕｅであれば、デルタカウント値のチェック処理を行う。
図５は、実施の形態２による論理シミュレータの、デルタカウント値のチェック処理のフローチャートである。
まず、ステップＳＴ５１で、ｍ＿ｄｅｌｔａと現在のｄｅｌｔａ＿ｃｏｕｎｔ値とを比較する。比較結果が等しければ処理を終了し、等しくなければステップＳＴ５２に進む。
ステップＳＴ５２では、ｍ＿ｄｅｌｔａ値をチェックする。この値が−１であれば、この変数に対する最初のデルタ遅延付き代入であると判断し、ステップＳＴ５３に進んで現在のｄｅｌｔａ＿ｃｏｕｎｔ値をｍ＿ｄｅｌｔａに設定し、処理を終了する。
また、ｍ＿ｄｅｌｔａ値が−１以外の場合は、ステップＳＴ５４に進んでＷａｒｎｉｎｇを出力する。これにより、同じ変数に対し、異なるｄｅｌｔａ＿ｃｏｕｎｔ値でデルタ遅延付き代入が行われたことを検出することができる。
【００２９】
また、実施の形態２では、プロセス内に、ｄｅｌｔａ＿ｃｈｅｃｋ値のＯＮ／ＯＦＦを切り替えるシステムタスク、あるいはプラグマを備える。
図６は、ｄｅｌｔａ＿ｃｈｅｃｋのＯＮ／ＯＦＦを切り替えるＨＤＬの記述例である。図中、Ｖｅｒｉｌｏｇ−ＨＤＬの例では、シミュレータに指示を与えるコメント文であるプラグマを用いている。シミュレーション実行部１１０は、／／ｄｅｌｔａ＿ｃｈｅｃｋ＿ｏｆｆでｄｅｌｔａ＿ｃｈｅｃｋをｆａｌｓｅに設定し、／／ｄｅｌｔａ＿ｃｈｅｃｋ＿ｏｎでｄｅｌｔａ＿ｃｈｅｃｋをｔｒｕｅに設定する。すなわち、／／ｄｅｌｔａ＿ｃｈｅｃｋ＿ｏｎが実行されるまで、デルタカウント値のチェック処理は行われない。
また、ＳｙｓｔｅｍＣの例ではグローバル関数を用いている。シミュレーション実行部１１０は、ｓｃ＿ｄｅｌｔａ＿ｃｈｅｃｋ（ｆａｌｓｅ）でｄｅｌｔａ＿ｃｈｅｃｋをｆａｌｓｅにし、ｓｃ＿ｄｅｌｔａ＿ｃｈｅｃｋ（ｔｒｕｅ）でｄｅｌｔａ＿ｃｈｅｃｋをｔｒｕｅに設定する。すなわち、ｓｃ＿ｄｅｌｔａ＿ｃｈｅｃｋ（ｔｒｕｅ）が実行されるまで、デルタカウント値のチェック処理は行われない。
【００３０】
以上のように、実施の形態２によれば、シミュレーション実行中に、同一の変数に対して異なるｄｅｌｔａ＿ｃｏｕｎｔ値でデルタ遅延付き代入が行われたことが検出可能になる。
同一の変数に対して異なるｄｅｌｔａ＿ｃｏｕｎｔ値でデルタ遅延付き代入が行われることは、その変数に複数のプロセスで代入を行っている場合や、動的センシティビティを用いた場合等に発生する。そしてこれらはほとんどの場合、モデル設計者の意図しない現象であり、波形にて確認することができず、かつレーシングの原因になり易いことは実施の形態１の応用例にて説明した通りである。
このように、実施の形態２による論理シミュレータでは、潜在しているレーシングの可能性を検出することが可能である。しかも、シミュレーション性能にほとんど影響を与えることはなく、ユーザが特別な作業をする必要もない。
さらに、ｄｅｌｔａ＿ｃｈｅｃｋ値のＯＮ／ＯＦＦを切り替える手段を設けたことにより、異なるｄｅｌｔａ＿ｃｏｕｎｔ値での意図的な代入による擬似エラーについては、検出しないようにすることができる。
【００３１】
実施の形態３．
実施の形態３による論理シミュレータは、実施の形態１及び２による論理シミュレータ１０と同様の構成であり、実施の形態２と同様に、デルタ遅延付き代入実行時にｄｅｌｔａ＿ｃｏｕｎｔ値のチェックを行うが、デルタ遅延付き代入が実行可能な各変数毎に保有するｍ＿ｄｅｌｔａの代わりに、全変数共通にデルタ遅延付き代入実行時のｄｅｌｔａ＿ｃｏｕｎｔ値を保持する領域ｇ＿ｄｅｌｔａを確保する。
【００３２】
実施の形態３では、ＨＤＬ処理部１００（デルタカウント数保持手段）は、信号リスト２５０内のデルタ遅延付き代入が実行可能な全変数共通の、デルタ遅延付き代入実行時のｄｅｌｔａ＿ｃｏｕｎｔ値を保持する領域ｇ＿ｄｅｌｔａを確保する。このｇ＿ｄｅｌｔａ値は、シミュレーション開始時に−１に初期化される。
また、シミュレーション実行部（デルタカウント数チェック手段、デルタカウント数チェック切り替え手段）１１０において、ｄｅｌｔａ＿ｃｏｕｎｔチェックを行うか否かを表す変数ｄｅｌｔａ＿ｃｈｅｃｋを保持している。ｄｅｌｔａ＿ｃｈｅｃｋ値はシミュレーション開始時にｔｒｕｅに初期化される。
【００３３】
シミュレーション実行部１１０は、プロセス内でデルタ遅延付き代入を実行した際、ｄｅｌｔａ＿ｃｈｅｃｋの値がｔｒｕｅであれば、デルタカウント値のチェック処理を行う。
実施の形態３による論理シミュレータの、デルタカウント値のチェック処理は、図５に示した実施の形態２におけるデルタカウント値のチェック処理と同様に行われるが、各変数固有のｍ＿ｄｅｌｔａの代わりに、全変数共通のｇ＿ｄｅｌｔａと現在のｄｅｌｔａ＿ｃｏｕｎｔ値とを比較する。これにより、実施の形態２と同様に、同じ変数に対し、異なるｄｅｌｔａ＿ｃｏｕｎｔ値でデルタ遅延付き代入が行われたことを検出することができる。
【００３４】
また、実施の形態３では、実施の形態２と同様に、プロセス内に、ｄｅｌｔａ＿ｃｈｅｃｋ値のＯＮ／ＯＦＦを切り替えるシステムタスク、あるいはプラグマを備える。ｄｅｌｔａ＿ｃｈｅｃｋのＯＮ／ＯＦＦを切り替えるＨＤＬの記述例は、図６に示した実施の形態２と同様である。
【００３５】
以上のように、実施の形態３によれば、シミュレーション実行中に、異なるｄｅｌｔａ＿ｃｏｕｎｔ値でデルタ遅延付き代入が行われたことが検出可能になる。
通常のモデリングにおいては、すべてのデルタ遅延付き代入が同一ｄｅｌｔａ＿ｃｏｕｎｔ値にて実行され、それによってレーシングが発生しないことを期待している場合が多い。しかしながら大規模な設計においては、何らかの理由でプロセスの起動されるデルタサイクルがずれるということもあり得る。しかも従来はこれを検出する手段がなく、レーシングの可能性を潜在化させていた。
実施の形態３による論理シミュレータでは、異なるｄｅｌｔａ＿ｃｏｕｎｔ値でデルタ遅延付き代入が実行されるという、多くの場合に期待されない動作を検出可能にしている。しかもシミュレーション性能にほとんど影響を与えず、ユーザが特別な作業をする必要もない。
さらに、ｄｅｌｔａ＿ｃｈｅｃｋ値のＯＮ／ＯＦＦを切り替える手段を設けたことにより、異なるｄｅｌｔａ＿ｃｏｕｎｔ値での意図的な代入による擬似エラーについては、検出しないようにすることができる。
【図面の簡単な説明】
【００３６】
【図１】この発明の実施の形態１による、論理シミュレータの構成を示すブロック図である。
【図２】この発明の実施の形態１による、論理シミュレータのシミュレーション実行部の動作のフローチャートである。
【図３】この発明の実施の形態１による、デルタカウント値を表示させるＨＤＬ記述の例である。
【図４】この発明の実施の形態１による、Ｖｅｒｉｌｏｇ−ＨＤＬによる応用例である。
【図５】この発明の実施の形態２による、デルタカウント値のチェック処理のフローチャートである。
【図６】この発明の実施の形態２による、デルタカウント値のチェック処理のオンオフを切り替えるＨＤＬ記述の例である。
【符号の説明】
【００３７】
１０  論理シミュレータ、２０  ＨＤＬ記述、３０  シミュレーション結果ファイル、４０  シミュレーション結果、１００  ＨＤＬ処理部（ハードウェア記述言語処理部）、１１０  シミュレーション実行部、１２０  内部データ記憶部、２００  プロセス実行コード、２１０  プロセスリスト、２２０  実行可能プロセスリスト、２３０  イベントリスト、２４０  予約イベントリスト、２５０  信号リスト。
【図１】
2006011961.tif 000003
【図２】
2006011961.tif 000004
【図３】
2006011961.tif 000005
【図４】
2006011961.tif 000006
【図５】
2006011961.tif 000007
【図６】
2006011961.tif 000008