JP2006127017A

JP2006127017A - 論理検証手法

Info

Publication number: JP2006127017A
Application number: JP2004312273A
Authority: JP
Inventors: Nobuyuki Yuasa; 信之湯浅
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2004-10-27
Filing date: 2004-10-27
Publication date: 2006-05-18

Abstract

【課題】複雑な設定無しで容易に動作を開始させる事が出来る、システムＬＳＩ開発における論理検証手法を確立する。
【解決手段】実際に接続される論理回路の代わりにマスタモデルやスレーブモデルを使用する事で、複雑な設定無しで容易に動作を開始させる事が出来、しかも、転送開始時間を制御する事も可能となり、設計者が意図していなかった複雑な状況を発生させ、実際以上に厳しい条件での検証を行うことを可能とした。
【選択図】図１

Description

システムＬＳＩ開発、特に論理検証手法に関するものである。

従来、ＣＰＵを内蔵するシステムＬＳＩ開発では、実際の論理回路を使用し、また実機で動作するソフトウェアを使用してシミュレーションを行う事で論理検証していた。

又、別の従来例としては、テストベンチ上に実際に起こるよりも厳しい条件を簡単に発生させ、検証対象回路のバグ出しを行ない設計品質の向上を図る課題に対して、テストベンチ上に実際の回路とは異なるマスタモデルやスレーブモデルを複数配置し各種データ転送をランダムに発生させる論理検証手法（例えば特許文献１参照）をあげることが出来る。
特開２００３−１５７１８２号公報

しかしながら、実際の論理回路では、動作を発生させる迄に詳細な設定を行なう必要があり、任意のタイミングで所望の動作を発生させる事は不可能であった。従って、設計対象となる論理回路に対して与える外部変化を十分に発生させる事が非常に困難で、潜在的な問題を持ったまま製造される事にもなっていた。また、シミュレーションの実行時間も非常にかかり、検証に時間がかかりすぎるという問題点もあった。

本発明は、以上の点に着目して成されたもので、実際に接続される論理回路の代わりにマスタモデルやスレーブモデルを使用する事で、複雑な設定無しで容易に動作を開始させる事が出来、しかも、転送開始時間を制御する事も可能となり、設計者が意図していなかった複雑な状況を発生させ、実際以上に厳しい条件での検証を行うことが可能となる。

また、設計者が意図していなかった状況を検証する事で、論理回路のバグを早期発見出来る。また、実際以上に厳しい条件で検証する事で、潜在バグを発見する事も可能になる。

また、更に本発明の論理検証手法を用いる事で、バグのない高品質のシステムＬＳＩを開発する事が可能となる論理検証手法を提供することを目的とする。

本発明を用いると、実際のＣＰＵの代わりにバスファンクションモデルを使用する事で、該ＣＰＵ用のソフトウェアがなくてもシミュレーションを実行でき、論理検証が可能となる。またＣＰＵ以外のＤＭＡコントローラ回路の代わりにバスマスターモデルを使用する事で、ＤＭＡコントローラ固有の面倒な設定を省いて同様の動作を発生させる事が可能となり、容易に動作検証を行う事が出来る。また、検証対象の回路の外部に存在すべき論理回路が未だ完成していない状態でもシミュレーションを実行して論理検証が可能となる。

また、実際のＤＭＡコントローラ等が発生するバス動作には、ある特定のパターンを持った転送が発生し易く、複雑な状況が発生する確率は低いが、本発明による能動モデルを使用する事で、特定のパターンを持たないランダムな転送を発生する事が可能となり、設計者が意図していなかった複雑な状況が発生する確率が高くなり、より正確、厳格な検証が可能となる。

更に、実際のＤＭＡコントローラ等では、１サイクル単位での制御は困難であるが、能動モデルは１サイクル単位で転送の発生を制御可能であり、複数の能動モデルからの転送を１サイクル単位でずらしてぶつけるようなスイープテストも可能となる。また任意のサイクルで転送を発生する事が可能な為、複数の能動モデルからのコンカレントな転送を容易に発生させて複雑な状況を検証する事が可能となる。またスレーブモデルを用いる事でスレーブからの応答を任意に、或いはランダムに発生させる事で、更に複雑な状況を検証する事が可能となる。

以下に、テストおよびモデルの記述例、またテストベンチの例を用いて、上記手法を詳述する。

まず図１に、モデルを用いない従来例によるメモリーコントローラ、Ｉ／Ｏインターフェイス、バスブリッジなどの回路の論理検証を行うためのテストの記述例を示す。この場合、図７に示すように実際に検証対象に接続されるＣＰＵやＤＭＡコントローラなどの回路を用いてテストを行う。その時の、テストコードの主な流れを以下に示す。１．検証テストベンチ全体の初期化（ｓｔｅｐ１．１）、２．検証対象に接続される実回路の初期化（ｓｔｅｐ１．２）、３．検証対象の初期化（ｓｔｅｐ１．３）、４．検証対象に接続される実回路のデータ転送用の設定（ｓｔｅｐ１．４）、５．検証対象に接続される実回路のデータ転送の起動（ｓｔｅｐ１．５）、６．転送終了後の検証対象に接続される実回路の終了手続き（ｓｔｅｐ１．６）、７．検証対象の終了手続き（ｓｔｅｐ１．７）、８．検証テストベンチ全体の終了手続き（ｓｔｅｐ１．８）。ここで、１，２には、ＣＰＵにて処理されるプログラムのメモリからのフェッチ、ＤＭＡの初期設定などが含まれる。ここで、２，４，５，６は検証対象に接続される実回路を操作するために必要な処理であり、大規模化するＬＳＩにおいては、この処理がより複雑になる傾向にあり、検証対象をテストする際にこの処理は、シミュレーション時のオーバーヘッドとなる。また、その部分に不具合があり所望の動作をさせることができない場合、検証対象をテストすることが困難になる。また、データの転送もＤＭＡであれば、バスにより規定されているすべての転送形態を起こし、そのような状況下で検証対象をテストすることは難しい。また、転送する際に必要となるアドレスを自由に選択したり、好きな順番に並べたりすることはＤＭＡの設定だけで行うのは難しい。

次に、従来例に対するモデルを用いた本発明によるテストの記述例を図２に示す。本手法においては、図８に示すように実際のＣＰＵおよび実際の回路を用いる代わりに、回路的に検証対象にできるだけ近い位置で接続されるマスタモデルを用いる。これにより、図２に示すように、従来の手法では必要であったｓｔｅｐ１．２，ｓｔｅｐ１．４，ｓｔｅｐ１．６など検証対象に接続される回路の前処理、後処理を省くことができる。

次に、図２〜９に、従来手法に対する本発明の手法、記述例を示す。本手法においては、図８に示すように実際のＣＰＵおよび実際の回路を用いる代わりに、回路的に検証対象にできるだけ近い位置で接続されるマスタモデルを用いる。これにより、図２に示すように、従来の手法では必要であったｓｔｅｐ１．２，ｓｔｅｐ１．４，ｓｔｅｐ１．６など検証対象に接続される回路の前処理、後処理を省くことができ、シミュレーションの高速化を計ることができる。

また、実際にＣＰＵで実行されるソフトウェアにおけるアドレス領域の制限やＤＭＡに対する設定におけるアドレスの制限をする必要がなく、アドレスを任意に選ぶことができる。

次に、検証対象が接続されるバスのバスマスタ、バススレーブ間のデータの通信形態として例えば図５に示すような転送の形態を考える。ここで、データの転送はクロック信号ｃｌｋに同期して行われるものとする。転送手順として、第１にバスマスタは、転送要求としてｒｅｑ信号をアサートする、それに対しバススレーブやアービタなど何らかの手段で、転送許可をバスマスタに対して与えるため、ｇｎｔ信号をアサートする。第２にバスマスタは、ｇｎｔ信号がアサートされたのを確認した後、転送開始として、ｓｔｒ信号を１ｃｙｃｌｅの間アサートする。バスマスタは、ｓｔｒ信号をアサートするのと同時に、転送データ数を提示するｂｕｒｓｔ信号、転送アドレスを提示するａｄｄｒ信号、転送データｄａｔａをアサートする。ｂｕｒｓｔ，ａｄｄｒ，ｄａｔａ信号は、転送が完了するまでアサートされ続けるものとする。第３にバススレーブは、転送されるデータを受け取れる準備ができた時点で、ｒｄｙ信号をアサートし、データを取得する。また、ｒｄｙ信号は、ｂｕｒｓｔ信号で提示される数のクロックサイクルの間、連続してアサートされ、データを連続して取得するものとする。また、バスマスタがアサートする転送開始信号ｓｔｒに対して、バススレーブが何らかの理由で、転送をうまく受け取れないときは、ｒｄｙ信号の代わりにｅｒｒ信号を、または今は受け取れないが、もう少し立てば受け取れる場合は、再送要求としてｒｔｒ信号をアサートすることとする。

この時、マスタＩ／Ｆがｒｅｑ信号をアサートし、転送許可としてｇｎｔ信号がアサートされてから、ｓｔｒ信号がアサートされるまでのタイミングが一意に規定されていない場合、接続されるモジュールもしくはモードによってタイミングが異なる場合が考えられるが、このような場合も図３に示すように、マスタモデルに簡単にそのタイミングを変えて転送を実行する機能を持たせることにより、簡単に転送プロトコルに定義された可能なタイミングで転送を行うことができ、そのプロトコルに準拠したより厳密な検証を行うことができる。そのようなマスタモデルを用意した場合のテストの記述例を図６に示す。このテストにおいては、タイミングをランダムに選択しながら行うテストシーケンス、およびタイミングを１サイクルずつずらしながら実行するテストシーケンスの記述例を示す。

次に、図９に示すように、ＤＭＡコントローラ、バスブリッジなどのマスタＩ／Ｆに対する検証を行う場合を考える。図８により説明したマスタモデルを用いる場合と同様に接続される実スレーブＩ／Ｆを用いずに、スレーブモデルを用いる。これにより、面倒な実スレーブＩ／Ｆの前処理、後処理を行わずに済む。更に、転送プロトコルにて、信号の変化するタイミングがある範囲で任意であるものに対して、そのすべての場合が実現できるように例えば図４に示すように、スレーブモデルを作成することにより、簡単に転送プロトコルに定義された可能なタイミングで転送を行うことができ、そのプロトコルに準拠したより厳密な検証を行うことができる。

次に、これらマスタモデル、スレーブモデルを組み合わせて用いることによる効果について、説明する。

メモリーコントローラ、Ｉ／Ｏインターフェイス回路、バスブリッジなどのスレーブＩ／Ｆに対する検証を行う場合、転送プロトコルにおいて、前後の転送と重なりを許す場合、または、検証対象において、複数の転送要求に同時に対応するために、複数のスレーブＩ／Ｆが動作し、検証対象内部でアービトレーションが行われている場合などのときは、図１０に示すように、複数のマスタモデルを使用して検証を行う。これにより、重なり合い更に連続した転送、重なり合った転送のうち、片方がエラー転送であるなどの複雑な動作を確認できる。

同様に、図１１に示すように、複数のスレーブモデルを用いることにより、複数の転送要求に同時に対応することができる。重なり合った転送を容易に確認することができ、エラー応答と通常応答を組み合わせるなど、さまざまな状況を容易に実現することができる。

そして、これらの仕組みを組み合わせることによって、更に複雑な動作を検証することができるようになる。図１２に示すように、転送の衝突、競合、複数プロセスの同時実行をしたときの振る舞い、エラーと通常転送が重なった場合、リソースの管理、更には、予測できない事象を発生させ、そのときの振る舞いを確認することもできる。

よって、本発明は上記のように、バスブリッジ、メモリーコントローラ、汎用バスに接続されるモジュール、バスアービタなど、システムＬＳＩを構成する多くの機能ブロックの検証に対して有効である。

以上のように、本発明は下記の構成によって前記課題を解決できた。

（１）システムＬＳＩ開発における論理検証の為のテストベンチにおいて、実際の論理回路として存在しないモデルを用いる事を特徴とする論理検証手法。

（２）モデルは実際の論理回路よりも厳しい条件を生成する事を特徴とする前記（１）記載の論理検証手法。

（３）モデルにはマスタモデルとスレーブモデルがある事を特徴とする前記（１）記載の論理検証手法。

（４）マスタモデルは実際の論理回路よりも容易に動作を開始できる事を特徴とする前記（３）記載の論理検証手法。

（５）スレーブモデルはマスタからの要求に対してランダムな時間を経て応答する事を特徴とする前記（３）記載の論理検証手法。

（作用）
本発明によれば、先ず、実際のＣＰＵの代わりにバスファンクションモデルを使用する事で実際のソフトウェアがない状態でも、検証対象の論理回路にとって興味深い動作を発生させる事が出来ると同時に、実際のソフトウェアでは実現できないランダムな種類でランダムな値のデータ転送を発生させる事が出来る。これにより、設計者が意図していなかった状況をシミュレーションで検証が可能である。

また、本発明によれば、マスタモデル、スレーブモデルを複数インスタンスする事で、実際のソフトウェアでは実現できないランダムな種類でランダムな値のデータ転送を発生させる事が出来る。これにより、設計者が意図していなかった状況をシミュレーションで検証が可能である。

以上説明したように本発明によれば先ず、実際に接続される論理回路の代わりにマスタモデルやスレーブモデルを使用する事で、複雑な設定無しで容易に動作を開始させる事が出来、しかも、転送開始時間を制御する事も可能となり、設計者が意図していなかった複雑な状況を発生させる等、実際以上に厳しい条件での検証が可能となる。

設計者が意図していなかった状況を検証する事で、論理回路のバグを早期発見出来る。また、実際以上に厳しい条件で検証する事で、潜在バグを発見する事も可能になる。

本発明の論理検証手法を用いる事で、バグのない高品質のシステムＬＳＩを開発する事が可能となる。

また、本発明の論理検証手法を用いることで、バグのない高品質の機能ブロックを開発することが可能となり、各機能ブロック再利用時の不具合の発生を無くすことができる。

（第１の実施例）
以下、図１３〜図１８に基づき、本発明による論理検証手法を説明する。

本発明の第１の実施例を示す図１３において、１は回路全体を制御するＣＰＵのバス動作のみを発生するＢｕｓＦｕｎｃｔｉｏｎｍｏｄｅｌ、２は回路内の様々なバスを結び、バス間のデータ転送をつかさどるＢｕｓＢｒｉｄｇｅ、３は記憶装置であるＭｅｍｏｒｙ、４は記憶装置への読み書きを制御するＭｅｍｏｒｙＣｏｎｔｒｏｌｌｅｒ、５は回路内で各種入出力機器やデバイスとの間のデータ転送でデータの通り道であるＩＯ−Ｂｕｓ、６はこの回路に接続されるＩＯ装置とのデータ転送を制御するＩＯ１Ｉｎｔｅｒｆａｃｅ、７はこの回路に接続されるＩＯ装置とのデータ転送を制御するＩＯ２Ｉｎｔｅｒｆａｃｅ、８はこの回路に接続されるＩＯ装置とのデータ転送を制御するＩＯ３Ｉｎｔｅｒｆａｃｅ、９は実際の回路の代わりにデータ転送を発生するＩＯ−Ｂｕｓｍａｓｔｅｒｍｏｄｅｌ１、１０は実際の回路の代わりにデータ転送を発生するＩＯ−Ｂｕｓｍａｓｔｅｒｍｏｄｅｌ２、１１は内部の論理回路間でデータ転送を行う際のデータの通り道であるＤｅｖｉｃｅ・Ｂｕｓ、１２は圧縮・伸長などの論理機能を有するＤｅｖｉｃｅ１、１３は圧縮・伸長などの論理機能を有するＤｅｖｉｃｅ２、１４は実際の回路の代わりにデータ転送を発生するＤｅｖｉｃｅ−Ｂｕｓｍａｓｔｅｒｍｏｄｅｌ１、１５は実際の回路の代わりにデータ転送を発生するＤｅｖｉｃｅ・Ｂｕｓｍａｓｔｅｒｍｏｄｅｌ２、１６は実際の回路の代わりにマスタからのデータ転送要求に応答するＩＯ−Ｂｕｓｓｌａｖｅｍｏｄｅｌ１、１７は実際の回路の代わりにマスタからのデータ転送要求に応答するＩＯ−Ｂｕｓｓｌａｖｅｍｏｄｅｌ２、１８は実際の回路の代わりにマスタからのデータ転送要求に応答するＤｅｖｉｃｅ−Ｂｕｓｓｌａｖｅｍｏｄｅｌ１、１９は実際の回路の代わりにマスタからのデータ転送要求に応答するＤｅｖｉｃｅ−Ｂｕｓｓｌａｖｅｍｏｄｅｌ２である。

図１４は従来例を示しており、２０は回路全体を制御するＣＰＵ、２１はプログラム等を記憶しておくＲＯＭ（ＲｅａｄｏｎｌｙＭｅｍｏｒｙ）、２〜８及び１１〜１３は図１と同様である。

図１４で示した従来例では、実際の回路で使われる機能のみで構成されており、ＣＰＵ２０はプログラムを例えばＲＯＭ２１から読み込んできて実行し、その内容をＭｅｍｏｒｙ３に転送した後、Ｍｅｍｏｒｙ３から命令を読み出して実行を行う。この場合ＣＰＵ２０は次に何を実行するかは、読み出してくる命令によって決定される為、何らかのデータの転送を行う場合でも、必ず命令の読み込み（ＩｎｓｔｒｕｃｔｉｏｎＦｅｔｃｈ）が発生する。但し、ＣＰＵ２０内部のキャッシュに命令がヒットしている間はこの限りではない。

以上述べてきたような事から、論理回路の検証を行う際、実際のソフトウェアを記述してＲＯＭイメージを作成して、シミュレーションを実行しなければならない。ところが、所望の機能ブロックの検証を行うためのステイミュラスを実際のソフトウェアで記述する事は容易な事ではなく、ＣＰＵ等様々な部分の初期化も必要であり、簡単に検証を行う事は困難である。更に、シミュレーションでは実際のＣＰＵを使用すると、実行に非常に時間を要してしまう。実機で１０秒程度で終了する事でもシミュレーションでは２４時間を要する事もある。

図１３におけるＢｕｓＦｕｎｃｔｉｏｎｍｏｄｅｌ１は、実際のＣＰＵの機能のうち、バス上に現れる信号の変化だけをコマンドによって発生する事が出来る。この場合、ＣＰＵ２０が行うような命令の読み込みは不要である。従って、余分な転送無しで所望のデータ転送を発生させる事が容易に実現できる。例えば、Ｍｅｍｏｒｙ３等のあるアドレスヘデータを書き込む場合は、ｗｒｉｔｅ（ａｄｄｒｅｓｓ，ｄａｔａ）；のようなＢｕｓＦｕｎｃｔｉｏｎｍｏｄｅｌ１が有するコマンドを発行すれば良い。

次に、図１３の従来例では、ＣＰＵ２０以外からデータ転送を開始させる為には、ＩＯ１Ｉｎｔｅｒｆａｃｅ１等に対して設定を行ってＤＭＡ（ＤｉｒｅｃｔＭｅｍｏｒｙＡｃｃｅｓｓ）を起動する必要がある。この場合、ＩＯ毎に設定方法も異なるし、転送レートもＩＯの種類によって決まってしまう。

従って、設定自体が複雑な上に、そこで発生させる転送の種類も限定されてしまう。そうなると、次から次へと転送を発生させる事も出来ず、色々な事が重なる複雑な状況を発生させる事が出来ない。従って、十分な検証を行う事が困難である。

図１３におけるＩＯ−Ｂｕｓｍａｓｔｅｒｍｏｄｅｌ１９やＩＯ−Ｂｕｓｍａｓｔｅｒｍｏｄｅｌ２１０は、ＩＯ−Ｂｕｓ５上で様々なデータ転送を複雑な設定を行う必要がなく発生させる事が出来る。この場合も、ｉｏ＿ｗｒｉｔｅ（ａｄｄｒｅｓｓ，ｄａｔａ）；のようなコマンドを発行するだけで良い。Ｄｅｖｉｃｅ−Ｂｕｓｍａｓｔｅｒｍｏｄｅｌ１１４やＤｅｖｉｃｅ−Ｂｕｓｍａｓｔｅｒｍｏｄｅｌ２１５も同様である。

ＩＯ−Ｂｕｓｓｌａｖｅｍｏｄｅｌ１１６やＩＯ−Ｂｕｓｓｌａｖｅｍｏｄｅｌ２１７は、ＢｕｓＦｕｎｃｔｉｏｎｍｏｄｅｌ１やＩＯ−Ｂｕｓｍａｓｔｅｒｍｏｄｅｌ１９等のマスタモデルからの転送要求に対して応答するスレーブモデルであり、決まったサイクルで応答するだけでなくランダムなサイクルだけ待って応答する事も可能である。またこれらのスレーブモデルからデータを送出する場合もランダムデータを生成する。また、バスエラーやリトライといった通常動作以外の動作時に論理回路のバグが存在する事が多く、これらのスレーブにバスエラーやリトライで応答させる事も出来、論理回路のバグ発見にも役立つ。Ｄｅｖｉｃｅ−Ｂｕｓｓｌａｖｅｍｏｄｅｌ１１８やＤｅｖｉｃｅ−Ｂｕｓｓｌａｖｅｍｏｄｅｌ２１９についても同様である。

上述してきたように、実際の回路には存在しないマスタモデルやスレーブモデルを用いる事で、設計者が意図しない状況や複雑な事象の複合動作を検証する事が出来る。

図１５は上述の各種モデルを動作させて検証を行うテストの記述例を示している。ここで、ｆｏｒｋとｊｏｉｎで囲まれる部分は各行に記述されたタスクがコンカレントに動作する。例えば、ｃｐｕ＿ｍａｓｔｅｒ＿ｋｉｃｋとｉｏ１＿ｍａｓｔｅｒ＿ｋｉｃｋは同時に開始される。

例えば、図１５において、ｃｐｕ＿ｍａｓｔｅｒ＿ｋｉｃｋはＢｕｓＦｕｎｃｔｉｏｎａｌｍｏｄｅｌ１１からＭｅｍｏｒｙ３やＩＯ−Ｂｕｓｓｌａｖｅｍｏｄｅｌ１１６等への転送をランダムなシーケンスでランダムなアドレスで発生させるような記述をする。同様に、ｉｏ１＿ｍａｓｔｅｒ＿ｋｉｃｋにはＩＯ−Ｂｕｓｍａｓｔｅｒｍｏｄｅｌ１９からの転送シーケンスを、ｉｏ２＿ｍａｓｔｅｒ＿ｋｉｃｋにはＩＯ−Ｂｕｓｍａｓｔｅｒｍｏｄｅｌ２１０からの転送シーケンスを、ｉｏ１＿ｓｌａｖｅ＿ｋｉｃｋにはＩＯ−Ｂｕｓｓｌａｖｅｍｏｄｅｌ１１６への転送シーケンスを、ｉｏ２＿ｓｌａｖｅ＿ｋｉｃｋにはＩＯ−Ｂｕｓｓｌａｖｅｍｏｄｅｌ２１７への転送シーケンスを、ｄｅｖ１＿ｍａｓｔｅｒ＿ｋｉｃｋにはＤｅｖｉｃｅ−Ｂｕｓｍａｓｔｅｒｍｏｄｅｌ１１４からの転送シーケンスを、ｄｅｖ２＿ｍａｓｔｅｒ＿ｋｉｃｋにはＤｅｖｉｃｅ−Ｂｕｓｍａｓｔｅｒｍｏｄｅｌ２１５からの転送シーケンスを、ｄｅｖ１＿ｓｌａｖｅ＿ｋｉｃｋにはＤｅｖｉｃｅ−Ｂｕｓｓｌａｖｅｍｏｄｅｌ１１８への転送シーケンスを、ｄｅｖ２＿ｓｌａｖｅ＿ｋｉｃｋにはＤｅｖｉｃｅ・Ｂｕｓｓｌａｖｅｍｏｄｅｌ２１９への転送シーケンスを記述する。

このように、各タスクにそれぞれのマスタモデルからのデータ転送を行うシーケンスやＣＰＵからスレーブモデルヘの転送シーケンスを記述しておくと、各マスタモデルからメモリや各スレーブモデルヘの動作が発生し、検証対象の論理回路が、その設計された論理に従って処理を行う。

図１５の例では、ｆｏｒ分がｆｏｒｋ−ｊｏｉｎ分の外側にある為、ｆｏｒｌｏｏｐを１回実行する度に、各動作を同時に開始させ、それぞれのシーケンスが終わった時点で次のｆｏｒｌｏｏｐが行われる。つまり、先に動作を終了したタスクは他の全てのタスクが動作を終了するまで次の動作開始を待つ事になる。

図１６の例ではｆｏｒｋ−ｊｏｉｎ分の内側で、それぞれのタスクにｆｏｒ分を配置している。この場合、それぞれのタスクは最初の動作開始は同時だが、それぞれのタスクは定められた回数だけｌｏｏｐを繰り返す。つまりそれぞれのタスクの動作は、他のタスクの動作に関わらず、次々と連続で実行される。この場合、ＢｕｓＢｒｉｄｇｅ２は休みなく全方向からの転送を処理する必要があり、実動作以上のストレスをかける事が可能となる。

また、図１７の例ように、各タスクの最初で、先ずランダムな値を生成し、その値分のサイクルを待って動作を開始させる事で、動作が特定のパターン化する事を避ける事が可能である。更に、図１８に示すようにランダムなサイクルを待つ代わりに、ｆｏｒｌｏｏｐを用いて動作開始を１サイクルづつ順に遅らせる事も容易であり、あるタスクの動作開始を他のタスクの動作開始に対してスイープさせる事も容易に実現できる。

このように、テストプログラムの大部分は書き換える事なく、それぞれのタスクの呼び出し方を少し変更する事で、色々な状況や複雑な状況を簡単にシミュレーションで実行可能となる。

従来例によるテストシーケンスの記述例。本発明によるテストシーケンスの記述例。マスタモデルの記述例。スレーブモデルの記述例。モデルが接続するバスのプロトコルの一例。本発明による、バスの転送タイミングに着目したテストシーケンスの記述例。従来例、実回路だけによるテストベンチ。マスタモデルを利用したテストベンチとその利点。スレーブモデルを利用したテストベンチとその利点。マスタモデルを複数利用したテストベンチとその利点。スレーブモデルを複数利用したテストベンチとその利点。マスタモデルとスレーブモデルを複数利用したテストベンチとその利点。本発明の実施例におけるシミュレーション対象のブロック図。従来例のブロック図。本発明の実施例におけるシミュレーションを実行するテストの記述例である。本発明の実施例におけるシミュレーションを実行するテストの記述例である。本発明の実施例におけるシミュレーションを実行するテストの記述例である。本発明の実施例におけるシミュレーションを実行するテストの記述例である。

符号の説明

１ＢｕｓＦｕｎｃｔｉｏｎｍｏｄｅｌ
２ＢｕｓＢｒｉｄｇｅ
３Ｍｅｍｏｒｙ
４ＭｅｍｏｒｙＣｏｎｔｒｏｌｌｅｒ
５ＩＯ−Ｂｕｓ
６ＩＯ１Ｉｎｔｅｒｆａｃｅ
７ＩＯ２Ｉｎｔｅｒｆａｃｅ
８ＩＯ３Ｉｎｔｅｒｆａｃｅ
９ＩＯ−Ｂｕｓｍａｓｔｅｒｍｏｄｅｌ１
１０ＩＯ−Ｂｕｓｍａｓｔｅｒｍｏｄｅｌ２
１１Ｄｅｖｉｃｅ−Ｂｕｓ
１２Ｄｅｖｉｃｅ１
１３Ｄｅｖｉｃｅ２
１４Ｄｅｖｉｃｅ−Ｂｕｓｍａｓｔｅｒｍｏｄｅｌ１
１５Ｄｅｖｉｃｅ−Ｂｕｓｍａｓｔｅｒｍｏｄｅｌ２
１６ＩＯ−Ｂｕｓｓｌａｖｅｍｏｄｅｌ１
１７ＩＯ−Ｂｕｓｓｌａｖｅｍｏｄｅｌ２
１８Ｄｅｖｉｃｅ−Ｂｕｓｓｌａｖｅｍｏｄｅｌ１
１９Ｄｅｖｉｃｅ−Ｂｕｓｓｌａｖｅｍｏｄｅｌ２
２０ＣＰＵ
２１ＲＯＭ

Claims

システムＬＳＩ開発における論理検証の為のテストベンチにおいて、実際の論理回路として存在しないモデルを用いる事を特徴とする論理検証手法。
モデルは実際の論理回路よりも厳しい条件を生成する事を特徴とする請求項１記載の論理検証手法。
モデルにはマスタモデルとスレーブモデルがある事を特徴とする請求項１記載の論理検証手法。
マスタモデルは実際の論理回路よりも容易に動作を開始できる事を特徴とする請求項３記載の論理検証手法。
スレーブモデルはマスタからの要求に対してランダムな時間を経て応答する事を特徴とする請求項３記載の論理検証手法。