JP4266226B2 - 選択的に有効にされるチェッカーを用いた設計検証システムおよび方法 - Google Patents

Description

本発明は、概して電子装置の設計に関し、より詳しくは、集積回路のような装置の設計を検証するための環境の効率を改善するためのシステムおよび方法に関する。

電子装置はより複雑になっている。電子装置の複雑さが増すに連れて、欠陥が装置の正常動作を損なったり妨げたりする可能性が高い。したがって、これらの装置の検査は、より重要になっている。

装置の検査は、装置の設計において、装置の製造において、装置の動作において、を含む種々の段階で重要であり得る。設計段階における検査は、設計が、概念上、しっかりしたものであることを保証する。試作品の検査は、概念上の設計が、製作された装置へと正しく変換されていることを保証する。製造段階での検査は、装置の製造に用いられた製造工程が所望の結果を実現することを保証するために実行され得る。装置が製造された後でさえも、装置は、正常使用における早い段階で故障することが見込まれる装置を特定するために、通電テスト（burn in）期間に亘って検査される。

装置がある特定の設計に従って組み立てられた場合にどのように動作するかを判断するために、装置の設計段階で検査が実行される。よって、この検査は、設計検証テストと称され得る。設計検証テストの間に設計欠陥を特定することによって、欠陥が設計に先立って修正されることが可能である。これによって、試作機を作るために生産体制を整え、欠陥の発見のために試作機を製作および検査し、別の試作機を作るために生産体制を再度整える費用を負担することを回避できる。

設計検証検査は、典型的に、装置をシミュレートするためのモデルを生成し、種々の入力を装置に供給し、シミュレーションによって生成された出力を予想される出力の組と比べる、ことを含む。シミュレートされた出力が、予想通りであった場合、設計が正しかったとの確認がなされ、装置の製造が続行する。シミュレートされた出力が予想通りでなかった場合、シミュレートされた出力において異常を引き起こした設計の欠陥が修正され、設計が再検証される。

従来の設計検証検査システムは、装置をシミュレートする手段、シミュレートされる装置への入力を生成する手段、シミュレートされた出力が予想通りであるかどうかを判定する手段、を含んでいる。電子装置をシミュレートする多くの市販のツールがある。これらのツールは、典型的には、ハードウェア記述言語によって記載された装置の記述を用いて、装置内の種々の要素の振る舞いのモデルを作成する（model）。そして、検証ツールが、検査ケースを取り上げ、シミュレートされた装置についての対応する入力の組を生成する。この入力は、装置のモデルに供給され、出力の組が生成される。次に、検証ツールは、これらの出力を予想される出力と比較して、シミュレートされた装置が期待通りに動作しているかを判定する。

シミュレートされた出力を予想される出力と比較することは、検証ツール内のチェッカーの組によって実行される。典型的には、各チェッカーは、シミュレートされた装置内でのある特徴をチェックするように構成されている。例えば、ある特定のチェッカーは、アトミックメモリアクセス（atomic memory access）を検証するかもしれない。別のチェッカーは、浮動小数点処理ユニットの動作を検証するかもしれない。チェッカーは、典型的には、１つ以上の表明（予想される結果または条件）および検査されている設計の実際の振る舞いをこの表明（assertion）と比較する手段を含む。検査中の同じ時点で、装置内の全ての特徴を検査することが必要であり得るので、従来の検証ツールは、全てのチェッカーを包含している。チェッカーは、典型的には、ソフトウェアモジュールで実現されているので、検証ツールがアクセス可能な、全てのチェッカーモジュールを１つの集約物（compilation）へと組み込むことが必要である。

典型的な装置（例えば、プロセッサコア）の全ての特徴を検証するのに必要な全ての多くのチェッカーゆえに、この集約物は非常に大きくなり得る。また、全てのチェッカーが、これらが実際に必要またはそうでなかろうと実行されるため、多くの場合、必須でないチェッカーモジュールの実行において非常に多くの処理時間が使用される。これらの問題は、従来の設計検証システムでは、複数の縮小されたチェッカーモジュール集約物を集約することによって対処されている。しかしながら、複数の縮小された集約物を有することは、１つの集約モジュールよりも多くの記憶領域を必要とし、また、縮小された集約物であっても、必要ではなく且つ検証時間中の処理資源を浪費するだけのチェッカーモジュールを含んでいる。

したがって、検査を実行し且つ検証ツールのモジュールを格納するのに従来システムほど多くの資源を必要としない、設計検証検査システムおよび方法を提供することが望まれる。

上で概要を説明した１つ以上の問題は、本発明の種々の実施形態によって解決され得る。大まかには、本発明は、テストケースが分析されてテスト対象のモジュール（ＭＵＴ）内で対応するテストケースによって検証されるであろう特性を決定し、特定された特性が用いられて設計検証ツールの所望の要素がテストケースと関係させられた特性を検証するのに必要なものとして選択的に有効および無効にされる、設計検証検査を実行するためのシステムおよび方法を含む。

ある実施形態は、テストケース分析器およびチェッカー選択器を含むシステムを具備する。テストケース分析器は、１つ以上のテストケースを分析し且つ各テストケースと関連付けされたテストケース特性を特定するように構成されている。チェッカー選択器は、テストケース分析器と接続され、テストケース分析器からのテストケース特性のＩＤ（identification）を受け取るように構成されている。次に、チェッカー選択器は、各テストケースに関して特定されたテストケース特性に基づいて、選択的に設計検証チェッカーの第１組を有効にするとともに第２組を無効にする。

ある実施形態では、テストケース分析器は、それぞれが特定のテストケース特性に対応する識別子を各テストケースに関連付けするように構成されている。各設計検証チェッカーは、１つ以上のテストケース特性識別子とも関連付けされ得る。そして、チェッカー選択器は、テストケース分析器からテストケースの特性として供給されたテストケース特性識別子と関連付けされた設計検証チェッカーの幾つかを有効にするように構成されている。このシステムは、動的ローダブルオブジェクト（dynamically loadable object）を選択的に読み出すことによりチェッカーを有効にするように構成され得る。このシステムは、また、各テストケースについて有効にされたチェッカーを特定する情報を含む検証カバレージデータを使用者に供給するように構成され得る。

他の実施形態は、設計検証環境において実施される方法を具備し、テストケースの組と関連付けされた特性を特定することと、テストケースと関連する特定された特性に基づいて設計検証チェッカーの第１組を有効にするとともにチェッカーの第２組を無効にすることと、を含む。テストケースと関連付けされた特性は、ある特定の特性に対応するタグまたは他の識別子を各テストケースに関連付けすることによって特定されることができる。これらの識別子が設計検証チェッカーと関連付けされて各チェッカーによって検証された特性を特定することもできる。次いで、テストケース識別子と関連付けされたチェッカーが選択的に有効にされる。チェッカーは、例えば、対応する動的ローダブルオブジェクトを読み出すことによって有効にされることができる。テストケースがシミュレートされる際、各テストケースについて有効にされたチェッカーを特定する情報を含む検証カバレージデータが、使用者に供給され得る。

別の他の実施形態は、コンピューティングシステムによって読み出し可能な記憶メディアを具備するソフトウェアプログラム製品を具備する。記憶メディアは、コンピューティングシステムに上記したような方法を実行させるように構成された１つ以上の命令を含んでいる。

また、多くの付加的な実施形態が可能である。

本発明の他の目的および利点は、以下の詳細な記載を読むことによって、また添付の図面の参照によって、より明らかになり得る。

本発明は、種々の変形および代替形態に従っているが、これらの具体的な実施形態は図面およびこれに付随する詳細な記載において一例として示されている。これらの図面および詳細な記載は、本発明を記載された具体的な実施形態に限定することを意図されていないことに留意されるべきである。その代わりに、この記載は、添付の請求の範囲によって規定されている本発明の範疇に含まれる全ての変形例、等価物、代替物を網羅するものと意図される。

本発明の１つ以上の実施形態が以下に記載される。以下に記載されるこれらの実施形態および他のあらゆる実施形態は、例示的であり、限定よりむしろ、本発明の例示であることを意図されていることに留意されるべきである。

概して、本発明は、設計検証検査を実行するためのシステムおよび方法を含んでいる。検査される可能性のある全ての特徴に対応するチェッカーモジュールを検証ツールにまとめるよりむしろ、本システムおよび方法は、テストケースの組を分析して検査されるであろう特徴を判断し、次いで、特定された特徴の検査に必要なチェッカーモジュールのみを選択的に有効にする。

ある実施形態は、設計検証環境から構成される。この環境が用いられて集積回路の設計が検証される。この検証環境は、テストケース生成器、検証ツール、論理シミュレータ、を含んでいる。検査対象のモジュールは、この検査環境の一部とみなされ得る。

検証ツールは、テストケース分析器およびチェッカー選択器を含んでいる。テストケース分析器は、テストケース生成器から受け取ったテストケースを分析し且つ各テストケースと関連付けされたテストケース特性を特定するように構成されている。テストケース分析器は、各テストケースの特性を示す識別子をテストケースに付する。チェッカー選択器は、テストケース特性のＩＤをテストケース分析器から受け取るように構成されている。次いで、チェッカー選択器は、テストケースについての特定されたテストケース特性に基づいて設計検証チェッカーの第１組を選択的に有効にするとともに第２組を無効にする。換言すれば、チェッカー選択器は、テストケースと関連づけされた特性を検証するように構成されたチェッカーを有効にするとともに、このテストケースの検証に必要でないチェッカーを無効にする。テストケースがシミュレートされる際、検証ツールは、その出力において、各テストケースにおいてどのチェッカーが活性であるかとどのチェッカーが不活性であるかの表示を含んでいる。

図１に、典型的なシミュレーション環境の要素を図示する図が示される。この実施形態では、シミュレーション環境１００は、テストケース生成器１１０、検証ツール１２０、論理シミュレータ１３０、テスト対象のモジュール（ＭＵＴ）１４０を含んでいる。シミュレーション環境１１０が用いられて、論理シミュレータ１３０およびＭＵＴ１４０によってモデル化された１つ（または複数）の装置の振る舞いが検査される。テストケース生成器１１０は、１つ以上のテストのシナリオを検証ツール１２０に供給する。次に、検証ツール１２０は、これらのシナリオを、論理シミュレータ１３０（およびＭＵＴ１４０）に供給される入力へと変換する。論理シミュレータ１３０（およびＭＵＴ１４０）によって生成される出力は、検証ツール１２０に返される。検証ツール１２０は、これらの出力を処理し、その結果としてのテスト出力（例えば、検証カバレージデータ）を使用者に提供する。

テストケース生成器１１０は、使用者によって供給されたテスト入力に基づいて、自動的に、テストシナリオまたはテストケースを生成し得る。これらのテスト入力は、論理シミュレータ１３０およびＭＵＴ１４０による規定のように設計された装置のテストのために生成されることを使用者が望むシナリオのタイプを規定する。このテスト入力は、使用者が検査を望む特徴のリスト程度の簡単なもの（例えば、アトミックメモリアクセス（atomic memory access）、モードのアドレス指定等）でもよいし、またはテストシナリオの具体的な詳細（例えば、検査される具体的なメモリ位置、実行される具体的な命令等）を規定するより複雑なものであってもよい。テストケース生成器１１０は、設計検証検査の分野で公知の種々の方法によって構成され得る。テストケース生成器の設計および構成はよく知られているので、本明細書では詳説しない。

テストケース生成器を用いてテストケースを自動で生成することに代わる方法として、テストケースが手動で生成され得ることに留意されたい。手動で生成されたテストケースは、テストケース１１０によって自動で生成されるテストケースと同様のやり方で、入力として検証ツール１２０に供給されることができる。

自動または手動で生成されたテストケースは、検証ツール１２０に入力として供給される。ある実施形態では、検証ツール１２０は、検証プログラム１２５を実行するコンピューティングシステムから構成される。検証プログラム１２５は、テストケースを論理シミュレータ１３０およびＭＵＴ１４０のための刺激へと変換するように構成されたモジュール含んでいる。換言すれば、これらのモジュールは、論理シミュレータ１３０およびＭＵＴ１４０に供給されてテストケースによって規定されたシナリオ内で論理シミュレータおよびＭＵＴによって代理される装置が受信する信号をシミュレートする。検証プログラム１２５は、論理シミュレータ１３０およびＭＵＴ１４０によって生成された出力信号を受け取り且つこの信号を検証するように構成されたモジュール（チェッカーと称する）を含んでいる。すなわち、これらのモジュールは、生成された出力信号を調べて、これらを予想される信号と比較してモデル化された装置の設計が予想される振る舞いを提供するかを判断する。

検証ツール１２０は、上記のように検査されている装置設計の振る舞いをモデル化する論理シミュレータ１３０およびＭＵＴ１４０と相互に通信する。検査されている設計の詳細は、例えばＶＨＤＬ、Ｖｅｒｉｌｏｇ等の従来の設計言語で、論理シミュレータ１３０に供給される。論理シミュレータ１３０は、この情報を解釈し、装置の振る舞いをシミュレートする刺激に対する応答を提供する。この環境では、ＭＵＴ１４０は、検査の主要な焦点である設計である。ＭＵＴ１４０は、設計のソフトウェアシミュレーションであり得るし、実際のハードウェアであり得る。論理シミュレータ１３０は、ＭＵＴ１４０と相互通信するであろう構成要素の振る舞いをシミュレートする。論理シミュレータ１３０は、典型的にはソフトウェア内でシミュレートされるが、ハードウェアの構成要素を含み得る。論理シミュレータ１３０は、本実施形態でＭＵＴ１４０から分離して描かれているが、別の検証環境は、論理シミュレータ１３０またはＭＵＴを個別に（すなわち、一方を他方無しに）用い得る。

シミュレーション環境１００の動作は、図２のフロー図で示されるように要約される。この図に示されるように、テストケースの組がまず生成される（ブロック２０５）。次に、テストケースは、検証ツールに供給される（ブロック２１０）。テストケースは、検証ツール内のドライバによって、モデル化された装置のための刺激へと変換される（ブロック２１５）。次に、これらの刺激は、検証ツールからシミュレータおよび（または）ＭＵＴに供給される（ブロック２２０）。次に、シミュレータおよび（または）ＭＵＴは、受信した刺激を処理し（ブロック２２５）、対応する出力の組を生成し、この出力の組が検証ツールに供給される（ブロック２３０）。次に、検証ツール内のチェッカーモジュールは、シミュレータおよび（または）ＭＵＴから受け取った出力を調べ、これらの出力をテストケースについて予想される結果と比較する（ブロック２３５）。検査が完了していない場合、ステップ２１５乃至２３５が繰り返される（ブロック２４０）。次に、検証ツールは１つ以上の出力を生成し、この出力は解析、デバッグ等のために使用者に提供される（ブロック２４５）。

刺激の生成、ＭＵＴのシミュレーション、出力信号を取得すること、出力を予想値と比較すること（図２のブロック２２０乃至２３５）は、テストケースレベル、または各テストケース内のステップレベルで起こっていると見られることができる。テストケースレベルでは、刺激の生成の全て、シミュレーション、出力の生成は、出力が予想値に対してチェックされる前に行われ得る。各テストケース内で図２の工程を繰り返し実行することがより一般的である。例えば、クロックサイクル毎に、刺激が生成され得、ＭＵＴがシミュレートされ得、出力が取得され得る。次に、これらの出力は、各サイクルにおいて予想値に対してチェックされる。

本システムおよび方法では、検証ツール内のチェッカーモジュールは、テストケースによって検証されるシミュレートされた装置の特徴に応じて選択的に有効にされる。ある実施形態では、テストケースが分析されてテストケースによって実行されるシミュレートされた装置の特徴が判断される。次に、テストケースによって実行される特徴を検証するチェッカーのみが有効にされる。この実施形態において、残りのチェッカーは無効にされる。シミュレーション環境内でのＭＵＴの特徴とチェッカーとの間の特定可能な関連性は、容易には見つからないかもしれないことに留意されたい。したがって、ある特定のテストケースについて特定される具体的な特徴と無関係に、幾つかのチェッカーを有効または無効にすることがより実用的である。これらのチェッカーは、手動で有効、無効にされてもよいし、常にオンとされていてもよい。

テストケースによって実行される特徴を検証するのに必要なこれらのチェッカーのみを選択的に有効にすることによって、本システムおよび方法は、チェッカーモジュールの集約物を格納するのに必要な総スペースの量も、テストケースの結果の検証に際してこれらのチェッカーモジュールを実行するのに必要な処理資源も減ずることができる。また、特定のチェッカーモジュールを選択的に有効にすることは、検証システムによって誤って不良が特定されることを減じ得る。

本システムおよび方法の利点は、従来の設計検証環境において、チェッカーは環境に静的に繋げられており且つ常に有効とされているという事実に起因している。従って、テストケースが実行されているときはいつでも、全てのチェッカーは、これらがテストケースに関係していようとなかろうと実行されている。この結果、不要のチェッカーは、検証環境内でシミュレートされた装置の出力を継続的に監視してテストケースによる検査を意図されていない特徴および特性をチェックする。このことは、処理資源を浪費し、テストケースの実行時間を増加させる。

さらに、幾つかのテストケースは異常な条件を扱うように設計されることになり得るので、誤って不良の発見がなされ得る。例えば、装置が違法（illegal）アクセスフラグ信号を正しく有効にするかを判断するために、メモリのキャッシュ禁止部分へのキャッシュ線フェッチ動作等の違法なメモリアクセスが図られ得る。装置は、テストケースによって実際に実行されない限り、フラグを有効にしてはならない。チェッカーがただフラグを見て装置がフラグを有効にしていないことを確認した場合、チェッカーは、違法メモリアクセスを意図的に実行するテストケースについて誤って不良を報告するであろう。換言すれば、違法アクセスフラグ信号は、通常、エラーの状態を示しているが、この特徴が検査されている場合、フラグ信号が有効になっていると予想され、フラグの不在はテストケースの不成功を意味する。もちろん、チェッカーは、フラグが有効で且つそのような違法アクセスがなかった場合に不良を報告するように機能拡張されることができるが、このことは、大半のテストケースが違法アクセスを実行しない場合に過大な開発労力を要求する。代わりに、チェッカーは、違法アクセスを実行する少数のテストケースがシミュレートされているとき、無効にされるべきである。

処理資源の不必要な使用に関しては、従来の設計検証環境ではチェッカーモジュールの集約物を、数個、保持し、集約物の１つは全てのチェッカーモジュールを含み得るが、他の集約物は削減されたモジュールの組を含むことが一般的である。削減された集約物の１つを設計環境に繋げることによって、使用されていないチェッカーの幾つかが排除され、これによって、これらのチェッカーを実行するのに必要な処理時間が除去される。

チェッカー数を削減された集約物を使用することは、設計検証環境の処理要件をある程度緩和する利点をもたらす。しかしながら、典型的には、これらの削減された集約物はわずかであるため、各々の集約物は、あるテストケースの実施の際に使用されないチェッカーモジュールを依然として多く含んでいる。テストされ得る特徴の、あり得る組み合わせが多いため、検査され得る特徴のあり得る組み合わせのそれぞれについて異なるチェッカー集約物を用意することは、これらの集約物のために非常に大きな記憶領域が必要とされるため、非実用的である。個数削減された集約物がほんのわずかだけ残された場合でも、これらの集約物の格納のための要件は、全てのチェッカーモジュールを含んだ１つの集約物に対するものよりずっと大きい。

選択的に有効にされるチェッカーモジュールのライブラリを１つ残し、そしてあるテストケースのために必要とされる特定のチェッカーのみを有効にすることによって、設計検証環境をサポートするのに必要な記憶領域の大きさを増やすことなく、処理時間が短縮されるという利点を実現できる。

図３のように、一実施形態に従った設計検証ツールの構造を示す機能ブロック図が示される。この図に示されるように、検証ツール３００は、ドライバ３１０の組、テストケース分析器３２０、チェッカーモジュール選択器３３０、チェッカーモジュールの組３４０を含んでいる。ある実施形態では、ドライバ３１０、テストケース分析器３２０、チェッカーモジュール選択器３３０、チェッカーモジュール３４０は、検証プログラムのソフトウェア成分として実現されるが、他の実施形態では、１つ以上のこれらの成分がハードウェアで実現されてもよい。

図３に示されるように、テストケースは、検証ツール３００によって受け取られ、ドライバ３１０およびテストケース分析器３２０の両方に送られる。ドライバ３１０は、従来の検証ツールと同様に機能する。換言すれば、ドライバ３１０は、テストケースを１つ以上の信号に変換し、この信号は論理シミュレータ（図３では図示せず）に入力として供給される。

テストケースがテストケース分析器３２０によって受け取られると、テストケースが分析されて各テストケースによって実行されるであろう特徴が決定される。ある実施形態では、テストケース分析器３２０は、各テストケースのタイプを描写する、各テストケースの属性または特徴を特定する。テストケースの分析は、パターンマッチングアルゴリズム、テスト記述ルール、発見的アルゴリズム、または他のあらゆる適当な情報分析技術を用いて等、種々の方法で行われることが可能である。例えば、テストケースが、マイクロプロセッサ命令のシーケンスから構成されている場合、格納命令後のロード命令を有する特徴を識別するためにパターンマッチング技術が適用されることができる。または、発見的技術が命令のシーケンスに適用されて、テストケース（命令のシーケンス）がメモリ集約的（intensive）、ＡＬＵ集約的、一般的、であるかが決定されてもよい。

この実施形態では、テストケースが分析された後、このテストケースについて特定されたテストケース特性は、このテストケースと関連付けされる。ある実施形態では、テストケース分析器は、テスト特性をテストケースと関連付けるように構成された相関器要素を含み得る。テストケース特性は、狭くても広くてもよい。テストケースとテストケース特性との間の相関は、一対一、または一体多、または多対多とされてよい。テストケースとのテスト特性の関連付けは、各ケースが分析される度に発生してもよいし、関連付けは、テストケースの全ての分析が完了した後になされてもよい。テスト特性の特定のテストケースとの関連付けは、このテストケースのシミュレーションの前または最中に行われる必要がある。

特性を対応するテストケースと関連付けることは、種々の方法で達成され得る。例えば、各テストケースは、このテストケースと関連付けされた１つ以上のテスト特性を特定する文字列を付されることができる。または、テストケースは、対応するテストケース特性によって分類されたグループ内に納されてもよい。他の代替の実施形態は、識別されたテストケース特性のそれぞれに、これらの特性を含んだテストケースの名前を付することであり得る。テストケースおよびテスト特性を関連付けする方法は、フレキシブルに行われることができる。ゆえに、テストケース特性はテストケースから参照されることができ、またはテストケース特性はテストケースから参照されることができる。テスト特性をテストケースと関連付けするための機構を、単純なファイル命名規則、ディレクトリ構造、記号リンク、データベース、関連型データベース（ＲＤＢ）、または他の適当な技術を用いて実現することができる。

本実施形態ではテストケース分析器３２０が検証ツール３００の一部として実現されているが、他の実施形態では異なった方法で実現され得ることに留意されたい。例えば、テストケース分析器は、代わりに、テストケース生成器（図３では図示せず）の一部として実現され得る。この場合、テスト特性は、テストケースが生成され、テストケースが検証ツールに供給される前にテストケースと関連付けされる際に、特定される。さらに別の実施形態では、テストケース分析器３２０は、テストケース生成器および検証ツール３００から独立した機構として実現され得る。このような実施形態では、テストケースは、生成され、テストケース分析器に供給され、テストケースおよび関連付けされたテスト特性は、検証ツールに供給されることができる。テストケース分析器は、ハードウェアまたはソフトウェアで実現され得、テスト特性は、テストケースのシミュレーションの前または最中に生成され且つテストケースと関連付けされることができる。

図３のように、テストケースが分析された後、テストケース特性情報はテストケース分析器３２０からチェッカー選択器３３０に渡される。チェッカー選択器３３０は、テストケース特性情報を用いてどのチェッカーが有効にされるべきか、およびどのチェッカーが無効にされるべきかを決定する。これを行うために、チェッカー選択器３３０は、テストケース特性を種々のチェッカーに相関させるための機構を実現する。

ある実施形態では、各チェッカーは、テストケースが特性と関連付けされるのと同じ方法で、１つ以上のテストケース特性と関連付けされる。各チェッカーは、分類されるか或いは特定のテストケース特性と関連付けされて、チェッカーが有効とされる目的であるテストケース特性が特定されることができる。これは、属性データ等の識別子を各チェッカーに付けることによって、命名規則の実施によって、チェッカーとテスト特性との間のマッピングの実施によって、特性をチェッカーに相関させる他のあらゆる適当な機構を用いることによって、なされることができる。

チェッカーは、肯定的にテスト特性と関連付けされ（すなわち、テストケースが特定された際にチェッカーが有効とされるべき）でもよいし、または否定的にテスト特性と関連付けされ（すなわち、テストケースが特定された際にチェッカーが無効とされるべき）てもよい。例えば、チェッカーは、パワーダウンモード、メモリマップド入力／出力（ＭＭＩＯ）コマンド、ロード・ヒット・ストア（load-hit-store）シーケンス等については有効として特定されることができ、またはこれらの特性に関して無効であると特定されることができる。各チェッカーは、１つのテスト特性、または複数のテスト特性、について有効／無効として特定されることができる。

チェッカー選択器３３０は、テストケースとテスト特性との間の相関関係、テスト特性とチェッカーとの間の相関関係を用いて、テストケースが実行される際に有効にされる利用可能なチェッカーの適切な１つを選択する。ある実施形態では、これは、ある特定のテストケースについて特定されたテスト特性を決定し、次いでこの特定された特性についてどのチェッカーが有効であるかを決定することによって達成される。チェッカーが、特定されたテスト特性の１つに関して有効である場合、このチェッカーはこのテストケースについて有効にされる。チェッカーが、特定されたテスト特性のいずれについても有効でない場合（または特定されたテスト特性のいずれか１つが無効である場合）、このチェッカーはこのテストケースについて無効とされる。以下の表１は、テストケースで特定された特性とこれらの特性ゆえに選択されたチェッカーの効果との間の、結果生じた相関関係の例を示している。

ある実施形態では、チェッカー選択器３３０は、各テストケースに対して適切な１つのチェッカー３４０を、このテストケースが実行されているときに選択する。換言すれば、個々のチェッカーが、テストケースごとに、有効／無効とされる。したがって、最初のテストケースに対して有効にされたチェッカーの組は、続くテストケースに対して有効にされる組と同じではないかもしれない。他の実施形態では、チェッカーは、バッチごとに有効／無効にされる。ゆえに、一緒に実行されるテストケース（すなわちバッチにおいて）の群に対して同じ組のチェッカーが有効にされる。検証ツールは、選択されたチェッカーを使用者が手動で有効または無効にできるように構成されてもよいことに留意されたい。手動の選択は、チェッカー選択器３００によるチェッカーの自動選択に優先するように構成されてもよいし、自動選択に従属していてもよい。

チェッカー選択器３３０は、種々の方法で実現されることができる。ある実施形態では、スイッチ変数が各チェッカーに割り当てられる。次いで、各チェッカーについてのスイッチ変数は、テストケースについて特定されたテスト特性に従って設定される。スイッチ変数が設定された後に、テストケースのシミュレーションが実行されることができる。シミュレーションの間、利用可能なチェッカーのそれぞれは、それぞれのスイッチ変数に応じてオンされる（有効にされる）またはオフされる（無効にされる）。他の実施形態では、各チェッカーは、ウィンドウズ（登録商標）に基づいたシステムにおけるＤＬＬのような動的ロードオブジェクト、またはＵＮＩＸ（登録商標）に基づいたシステムにおける動的ローダブルオブジェクトとして実現されることができる。他のあらゆる適当なハードウェハまたはソフトウェア技術が用いられて、他の実施形態におけるチェッカーが有効／無効にされてもよい。

適当なチェッカーが選択されると、テストケースのシミュレーションが進行できる。ドライバ３１０は、テストケースに対応する信号を生成し、この信号を論理シミュレータに供給する。論理シミュレータは、検査対象の装置（または設計）の振る舞いを、ドライバ３１０から供給された信号を用いてシミュレートする。シミュレーションの間、チェッカー選択器３３０によって有効にされたチェッカー３４０は、それぞれの機能に対応する事象を監視する。無効にされたチェッカー３４０は、シミュレーションの間、動作しない（すなわち、対応するチェッカープログラムコードは実行されない）。有効にされた個々のチェッカーは、従来のシステムとほぼ同様に機能する。

チェッカーによる、ＭＵＴのシミュレートされた振る舞いと予想される振る舞いとの比較の結果は、幾つかの形態で使用者に提供される。この情報は、検証カバレージデータとして提供される。典型的には、カバレージの事象に関する情報が収集されて、検証プロセスの進行および検証の水準（質）を推定し、検証の失敗等が発見される。検証ツール３００の使用者がある特定のテストケースについてどのチェッカーが有効であったか（およびどれが無効であったか）を知ることは有用であるので、検証カバレージデータは、ある実施形態では、どのチェッカーが各テストケースについて有効または無効であったかを示す情報で補完される。検証カバレージデータおよびチェッカー有効／無効情報から、チェッカーの選択が適正か、および適用可能なテストケースについて実際にチェッカーが有効にされているか、を判断されることができる。

図３とともに上記した検証ツールを用いたシミュレーション環境は、図４のように要約され得る。図４に記載される方法は、テストケースの生成（ブロック４０５）で開始する。テストケースは、自動でまたは手動で生成されることができる。次に、テストケースは、検証ツールに供給される（ブロック４１０）。上記したように、テストケースは、論理シミュレータ用のドライバとテストケース分析器の両方に供給される。

受け取られたテストケースは分析され（ブロック４１５）、これらテストケースのそれぞれと関連づけされたテストケース特性が特定される（ブロック４２０）。各テストケースについて特定されたテストケース特性に基づいて、特定のチェッカーが有効にされ、他のチェッカーが無効にされる（ブロック４２５）。

適当なチェッカーが有効／無効にされると、シミュレーションが進行する。次いで、ドライバは、テストケースに対応する信号を生成し（ブロック４３０）、これらの信号を論理シミュレータに供給する（ブロック４３５）。論理シミュレータは、これらの信号を用いて、テスト対象の装置／設計の振る舞いをモデル化する（ブロック４４０）（上記のように、このシミュレーションは、ＭＵＴのためのソフトウェアシミュレーションおよび実際のハードウェアの動作の両方を含み得る）。論理シミュレータおよび（または）ＭＵＴの動きは、有効にされたチェッカーによってシミュレーションの間監視され、必要な情報および（または）モデル化された装置の出力は、チェッカーに供給される（ブロック４４５）。

チェッカーは、シミュレーションから受け取った信号を予想されるデータと比較して、シミュレートされた装置が予想通りに動作していることを検証する（ブロック４５０）。次に、どのチェッカーが有効／無効であったに関する情報が用いられて、より典型的な検証カバレージデータ（ブロック４５５）が補完され、補完されたデータは使用者に提供される（ブロック４６０）。

図４のステップ４３０乃至４５０は、テストケースの分析および適当なチェッカーの有効化と並行して実行されるものとして示されている。これは、予想値に対する出力のチェックの前に、テストレベルで、刺激を生成し、シミュレーションし、出力を生成することに対応する。しかしながら、これらのステップは、代わりに、各テストケース内でステップレベルで実行されてもよいことに留意されたい。例えば、図２の方法に関しては、クロック周期毎に、刺激が生成され、ＭＵＴがシミュレートされ、出力が取得され、各周期後に予想値に対してチェックされることができる。この場合、ステップ４１５乃至４２５は、ステップ４３０乃至４５０の前に実行されるであろう。そして、ステップ４３０乃至４５０は、検査が完了するまで繰り返し実行される。ステップ４５５および４６０は、サイクル前に、または検査が完了する前に実行され得る。

図５のように、一実施形態に従った設計検証システムの例を示す機能ブロック図が示される。この例では、ＭＵＴは、中央演算処理装置（ＣＰＵ）である。ＭＵＴのためのテストケースは、ＣＰＵによって実行される命令のシーケンスを含んだアセンブラプログラムである。命令のシーケンスは、この例では、使用者によって手書きされる。

検証ツールは、検証プログラムを実行するように構成されたコンピューティングシステムである。検証プログラムは、検証ツールにとって適当な検証言語で記述される。チェッカーは、残りの検証プログラムと同じ検証言語で記述される。

この具体例では、テストケース特性は、命令シーケンスに含まれているＣＰＵ命令のタイプである。命令タイプは、ロード／格納命令、キャッシュ動作命令、論理演算ユニット命令等の比較的広いものであってもよいし、言語命令のロード、浮動小数点付加命令等のより狭いものであってもよい。

この例におけるテストケース分析器は、命令分類器である。命令分類器は、テストケース中の各命令のタイプを、適切なチェッカーが有効または無効にされるように分類する。チェッカー選択器は、対応する命令タイプがテストケース中に存在しているかどうかに応じて、チェッカーをオン、オフすることによってチェッカーを有効または無効にする。

各テストケース特性についての（各ＣＰＵ命令タイプについての）チェッカーは、表明（assertion）として記載される。検証言語は、テストケースに適用される各テストケース特性（命令タイプ）についての表明名を列挙することによって各表明がオンまたはオフされるように定義される。例えば、チェッカーは、以下と同様の言語構造を用いて、テストケースのバッチごとに選択的に有効／無効にされる。

when instruction_loadw_is_used == true enable{
Assertion1_for_instruction_loadw
Assertion2_for_instruction_loadw
Assertion3_for_instruction_loadw
}
when instruction_addf_is_used == true enable{
Assertion1_for_instruction_addf
Assertion2_for_instruction_addf
}
when instruction_br_is_used == false disable{
Assertion1_for_instruction_br
Assertion2_for_instruction_br
}。

ここで、instruction_loadw_is_usedは、“load word”命令が用いられる場合に真であり、そうでない場合に偽であり、instruction_addf_is_usedは、“add floating point”命令が用いられている場合に真であり、そうでない場合に偽であり、instruction_br_is_usedは、分岐命令が用いられる場合に真であり、そうでない場合に偽である。各表明（例えば、Assertion1_for_instruction_loadw）は、対応する命令から生まれる予想される応答又は条件を示す。特定の表明が有効とされる場合、対応するチェッカーはシミュレーションを監視して予想される応答または条件が真であることを検証する。表明が無効とされている場合、チェッカーは、応答および条件が予想されているものであることを検証しない。

他の実施形態では、検証プログラムの一部は、１回に１つのテストケースを読み出し、個々のテストケースについてチェッカーを選択的に有効／無効にするように構成され得る。この実施形態では、チェッカーは、以下の言語構造を用いて有効／無効にされ得る。

instruction_loadw_is_used := true
instruction_addf_is _used := false
instruction_br_is_used := true。

次に、検証プログラムは、新たなテストケースが実行される度に、シミュレートされている個々のテストケースについて適切にチェッカーをオンまたはオフすることができる。

チェッカーが選択される（対応する論理変数instruction_loadw_is_used、instruction_addf_is _used、instruction_br_is_usedを設定することによってオンまたはオフされる）と、テストケースが実行される。検証ツールは、シミュレートされている装置に関する必要な入力を論理シミュレータに供給し、次いで論理シミュレータはＣＰＵ（ＭＵＴ）と相互通信する。このＣＰＵの動作に関する情報は、論理シミュレータにフィードバックされ、次に論理シミュレータは情報を検証ツールに供給する。次に、検証ツールは、どのチェッカーが有効／無効であったかに関する情報を含む検証カバレージデータ
を使用者に提供する。

この検証環境の利点の例が以下に記載される。この例では、上記の設計検証環境が用いられてパワーＰＣプロセッサの動作が検証される。この例は、Reservation on successful Store Conditional命令に関連した、本検証環境の利点を示す。

パワーＰＣプロセッサＩＳＡの同期規格は、メモリへのアトミックアクセス（atomic access）を実現するためにLoad and Reserve命令およびStore Conditional命令を定義する（パワーＰＣアトミックメモリアクセスの仕組みは、市販の種々のパワーＰＣアーキテクチャ教科書に記載されている）。パワーＰＣの仕組みは、これらの目的のために、命令ニーモニックlwarx（Load Word And Reserve Indexed）、ldarx（Load Drooubleword And Reserve Indexed）、stwcx（Store Word Conditional indexed）、stdcx（Store Doubleword Conditional Indexed）を定義する。以下の記載の目的で、ニーモニックlwarxおよびldarxは集合的にＬＡＲＸと称され、stwcxおよびstdcxは集合的にＳＴＣＸと称される。

ＳＴＣＸ命令が首尾よく完了するために、ＳＴＣＸアドレスについての予約がなければならない。この予約は、ＳＴＣＸ命令に先立つＬＡＲＸ命令によって確立される。さらに、ＳＴＣＸ命令の実行時に予約が有効であるために、ＬＡＲＸ命令の実行とＳＴＣＸ命令との間に、同じアドレスに対する他のあらゆる格納があってはならない。

首尾よく完了した各ＳＴＣＸ命令が、（上記のルールに従って）実行時に有効な予約を有していたことを保証するよう構成された「STCXneedsReservation」と命名されたチェッカーがあるとする。これを行うためには、STCXneedsReservationチェッカーは、ＳＴＣＸの完了を見つけるために完了プロセッサのパイプラインを精査しなければならない。

もし、STCXneedsReservationチェッカーが常に有効にされていると、このチェッカーは、実行されているテストケースがＳＴＣＸ命令を含んでいるかによらずプロセッサのパイプラインを周期ごとに精査する。このことは、シミュレーション時間を長くし、ＳＴＣＸ命令がない場合、この時間は無駄である。このチェックの実行に費やされた資源から何の利益も得られない。

このシミュレーション時間は、テストケースにＳＴＣＸ命令が無いことが判断され、STCXneedsReservationチェッカーが無効にされ得れば、割愛され得る。テストケースにＳＴＣＸ命令が存在することは、テストケース分析器内でＳＴＣＸ（ｓｔｗｃｘおよびｓｔｄｃｘ）ニーモニックについてのテストケース（パワーＰＣアセンブラ命令）を探すことによって容易に判断されることができる。これらのニーモニックがテストケースに含まれている場合、テストケースは「includes_STCX」として分類される。含まれていない場合、テストケースは、「includes_NO_STCX」として分類される。「includes_STCX」および「includes_NO_STCX」は、ここで、対応するテストケース特性の識別子として用いられる。（シミュレータのために動的ローダブルオブジェクトとして実現されている）STCXneedsReservationチェッカーを、「includes_STCX」として分類されているテストケースが実行されているときのみシミュレーション環境へと読み出すことによって、結果、STCXneedsReservationチェッカーはチェッカーが有効であるテストケースに対してのみオンされる。STCXneedsReservationチェッカーが有効でないテストケースでは、シミュレーションの実行において処理資源は全く費やされない。

本明細書で用いられている「コンピューティングシステム」は、本明細書で記載されている機能を実行可能なあらゆるタイプのデータ処理または命令処理システムを含むことが意図されている。本明細書で用いられている「コンピューティングシステムによって読み出し可能なメディア」は、コンピューティングシステムによって実行可能なプログラム命令を格納可能なあらゆるメディアを意味し、フロッピー（登録商標）ディスク、ハードディスクドライバ、ＣＤ−ＲＯＭ、ＤＶＤーＲＯＭ、ＲＡＭ、ＲＯＭ、ＤＡＳＤアレイ、磁気テープ、フロッピー（登録商標）ディスケット、光学記憶装置等を含む。

当業者は、情報および信号が、あらゆる、種々の異なった技術および手法を用いて表現され得ることを理解するであろう。例えば、ここまでの記載で使われたデータ、命令、コマンド、情報、信号、ビット、シンボル、チップは、電圧、電流、電磁波、磁場または磁性粒子、光場または光粒子、のいずれかまたはこれらのあらゆる組み合わせによって表現され得る。

当業者は、さらに、本明細書に開示された実施形態との関連において記載された種々の例示的な論理ブロック、モジュール、回路、アルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、のいずれかまたは両者の組み合わせとして実現され得ることを理解するであろう。このハードウェアとソフトウェアの可換性を明確に説明するために、種々の例示的な構成要素、ブロック、モジュール、回路、ステップが、概してそれらの機能の観点から、ここまで記載された。このような機能が、ハードウェアとしてまたはソフトウェアとして実行されるかは、具体的な用途またはシステム全体に課される設計制約に依存する。当業者は、各具体的な用途ごとに種々の方法で、記載された機能を実現し得るが、そのような実現を決定することが本発明の範疇からの逸脱を引き起こすものと解釈されるべきではない。

本明細書に記載の実施形態との関連で記載された種々の例示的な論理ブロック、モジュール、回路は、本明細書に記載された機能を実行可能なように設計されたメインプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、他のプログラム可能論理回路、個別（ディスクリート）ゲートまたはトランジスタ、個別ハードウェア構成要素、の何れかまたはこれらのあらゆる組み合わせによって、実現または実行され得る。メインプロセッサは、あらゆるプロセッサ、コントローラ、マイクロコントローラ、ステートマシン等であり得る。プロセッサは、コンピューティング装置の組み合わせ、例えばＤＳＰとマイクロプロセッサとの組み合わせ、複数のマイクロプロセッサ、ＤＳＰコアとともに用いられる１つ以上のマイクロプロセッサ、または他のこのような構成、として実現され得る。

本明細書に記載されている実施形態との関連で記載された方法またはアルゴリズムのステップは、直接ハードウェア内で、プロセッサによって実行されるソフトウェアモジュール内で、両者を組み合わせたもの内で具現化され得る。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭ、本分野において知られている他のあらゆる形態の記憶メディア内に駐在し得る。例示的な記憶メディアは、プロセッサが記憶メディアから情報を読み出し、記憶メディアに情報を保存できるように、プロセッサと接続される。または、記憶メディアは、プロセッサと一体化され得る。プロセッサおよび記憶メディアは、ＡＳＩＣ内に駐在し得る。ＡＳＩＣは、ユーザの端末内に駐在し得る。または、プロセッサおよび記憶メディアは、ユーザの端末内の個別の構成要素内に駐在し得る。

本発明によって提供され得る利点および効果が、上記の具体的な実施形態に関して記載された。これらの利点および効果、およびこれらを起こし且つより明確にするあらゆる要素および限定は、あらゆる請求項の重要な、または必要な、または必須の特徴として構成されることを意図されない。本明細で用いられている、「具備する」という文言、および他のあらゆる派生語は、これらの文言に続く要素または限定を、非排他的に含むものとして解釈されることが意図される。したがって、要素の組を具備するシステム、または方法、または他の実施形態は、これらの要素のみに限定されず、明示的に列挙されていないまたは主張されている実施形態に固有の他のあらゆる要素を含み得る。

開示された実施形態の上記の記載は、当業者が本発明を実施しまたは用いることを可能にするために提供されている。これらの実施形態に対する種々の変形は、当業者にとって容易に明白とあるであろうし、本明細書に定義されている包括的な原理は、本発明の思想または範疇から逸脱することなく他の実施形態に適用されることができる。したがって、本発明は、本明細書に示されている実施形態に限定されず、本明細書に開示され且つ請求の範囲で述べられている新規な特徴および原理に合致する最も広い範疇に従うことが意図される。

図１は、典型的なシミュレーション環境の要素を示している。 図２は、図１に記載のシミュレーション環境の動作を示している。 図３は、一実施形態に従った設計検証ツールの構造を示す機能ブロック図である。 図４は、図３の実施形態に従ったシミュレーション環境の動作を示すフロー図である。 一実施形態に従った設計検証システムの例を示す機能ブロック図である。

Claims (18)

1. 検査対象のモジュールに実行させる所定の動作の内容を規定するテストケースを分析した結果に基づいて、テストケースを特徴付けるための予め定められた複数のテストケース特性のうちの少なくとも１つと関連付けることを用いて前記テストケースを特徴付け、前記テストケースとこのテストケースを特徴付ける前記テストケース特性との関連を特定可能な情報を含んだテストケース特性情報を生成するように構成されている、テストケース分析部と、
   各々が前記モジュールの特定の動作を検証するように構成されている複数の設計検証チェッカー部と、
   前記テストケース特性情報から前記テストケースに含まれている前記テストケース特性を特定し、前記特定されたテストケース特性に基づいて前記複数の設計検証チェッカー部のうちの前記テストケースによって実行される動作を検証する第１組を有効にするとともに前記テストケースによって実行される動作を検証しない第２組を無効にするように構成されている、チェッカー選択部と、
   を具備する、設計検証システム。
2. 前記テストケース特性情報が、前記テストケースが含んでいる特性に対応する前記テストケース特性を特定するテストケース特性識別子を含んでいる、請求項１の設計検証システム。
3. 複数の前記設計検証チェッカー部のそれぞれが１つ以上の前記テストケース特性識別子と関連付けされており、
   前記チェッカー選択部が、前記テストケース分析部から供給された前記テストケース特性識別子と関連付けされた前記設計検証チェッカー部を有効にするように構成されている、
   請求項２の設計検証システム。
4. 複数の前記設計検証チェッカー部のうちの前記第１組を特定する情報を含んだ検証カバレージ情報を出力するように構成されている、請求項１の設計検証システム。
5. 前記設計検証システムが、集積回路を検査するように構成されている、請求項１の設計検証システム。
6. 複数の前記設計検証チェッカー部のうちの前記第１組に対応する動的ローダブルオブジェクトをロードすることによって前記設計検証チェッカー部のうちの前記第１組を有効にするように構成されている、請求項１の設計検証システム。
7. コンピュータが、検査対象のモジュールに実行させる所定の動作の内容を規定するテストケースを分析した結果に基づいて、テストケースを特徴付けるための予め定められた複数のテストケース特性のうちの少なくとも１つと関連付けることを用いて前記テストケースを特徴付ける工程と、
   コンピュータが、前記テストケースとこのテストケースを特徴付ける前記テストケース特性との関連を特定可能な情報を含んだテストケース特性情報を生成する工程と、
   コンピュータが、前記テストケース特性情報から前記テストケースに含まれている前記テストケース特性を特定する工程と、
   コンピュータが、前記特定されたテストケース特性に基づいて前記複数の設計検証チェッカー部のうちの前記テストケースによって実行される動作を検証する第１組を有効にするとともに前記テストケースによって実行される動作を検証しない第２組を無効にする工程と、
   を具備することを特徴とする、コンピュータ・ソフトウェアによる設計検証方法。
8. 前記テストケース特性情報が、前記テストケースが含んでいる特性に対応する前記テストケース特性を特定するテストケース特性識別子を含んでいる、請求項７の設計検証方法。
9. 複数の前記設計検証チェッカー部のそれぞれが１つ以上の前記テストケース特性識別子と関連付けされており、
   複数の前記設計検証チェッカー部のうちの第１組を有効にするとともに第２組を無効にする工程が、コンピュータが、前記テストケース特性情報内の前記テストケース特性識別子と関連付けられている前記設計検証チェッカー部を有効にする工程を含む、
   請求項８の設計検証方法。
10. コンピュータが複数の前記設計検証チェッカー部のうちの前記第１組を特定する情報を含んだ検証カバレージ情報を出力する工程をさらに具備することをさらに含む、請求項７の設計検証方法。
11. 前記設計検証方法が、集積回路を検査するように構成された設計検証環境内で実施される、請求項７の設計検証方法。
12. 複数の前記設計検証チェッカー部のうちの前記第１組および前記第２組が動的ローダブルオブジェクトとして用意されており、
    複数の前記設計検証チェッカー部のうちの第１組を有効にするとともに第２組を無効にする工程が、コンピュータが、複数の前記設計検証チェッカー部のうちの前記第１組に対応する前記動的ローダブルオブジェクトをロードする工程を含む、
    請求項７の設計検証方法。
13. コンピュータに、
    検査対象のモジュールに実行させる所定の動作の内容を規定するテストケースを分析した結果に基づいて、テストケースを特徴付けるための予め定められた複数のテストケース特性のうちの少なくとも１つと関連付けることを用いて前記テストケースを特徴付ける工程と、
    前記テストケースとこのテストケースを特徴付ける前記テストケース特性との関連を特定可能な情報を含んだテストケース特性情報を生成する工程と、
    前記テストケース特性情報から前記テストケースに含まれている前記テストケース特性を特定する工程と、
    前記特定されたテストケース特性に基づいて前記複数の設計検証チェッカー部のうちの前記テストケースによって実行される動作を検証する第１組を有効にするとともに前記テストケースによって実行される動作を検証しない第２組を無効にする工程と、
    を実現させるためのプログラム。
14. 前記テストケース特性情報が、前記テストケースが含んでいる特性に対応する前記テストケース特性を特定するテストケース特性識別子を含んでいる、請求項１３のプログラム。
15. 複数の前記設計検証チェッカー部のそれぞれが１つ以上の前記テストケース特性識別子と関連付けされており、
    コンピュータに複数の前記設計検証チェッカー部のうちの第１組を有効にするとともに第２組を無効にする工程が、コンピュータに、前記テストケース特性情報内の前記テストケース特性識別子と関連付けられている前記設計検証チェッカー部を有効にする工程を実現させることを含む、
    請求項１４のプログラム。
16. 複数の前記設計検証チェッカー部のうちの前記第１組を特定する情報を含んだ検証カバレージ情報を出力する工程をコンピュータに実現させることをさらに含む、請求項１３のプログラム。
17. 前記プログラムが、集積回路を検査するように構成された設計検証環境内で実行されるように構成されている、請求項１３のプログラム。
18. 複数の前記設計検証チェッカー部のうちの前記第１組および前記第２組が動的ローダブルオブジェクトとして用意されており、
    コンピュータに複数の前記設計検証チェッカー部のうちの第１組を有効にするとともに第２組を無効にする工程が、コンピュータに複数の前記設計検証チェッカー部のうちの前記第１組に対応する前記動的ローダブルオブジェクトをロードする工程を実現させること含む、
    請求項１３のプログラム。

Images