JP2007072604A - 論理回路検証装置及びその制御方法、コンピュータプログラム及び記憶媒体 - Google Patents

Abstract

【課題】
論理回路の検証を行う際に、シミュレーション時間を短縮し、リグレッションテストを効果的に実行可能とする。
【解決手段】
論理回路の検証項目のセットを複数登録する登録手段と、前記検証項目について前記論理回路をシミュレーションするシミュレーション手段と、複数の前記セットのいずれかにそれぞれ割り当てられ、前記シミュレーションにおいて前記検証項目に対応する前記論理回路の動作をモニタリングする複数のモニタリング手段と、前記モニタリングにより動作が確認された検証項目を保持する保持手段と、前記保持手段に、前記セットに含まれる検証項目の全てが保持された場合に、該セットに割り当てられた前記モニタリング手段の動作を停止する制御手段とを備えることを特徴とする。
【選択図】図１

Description

本発明は、論理回路検証装置及びその制御方法、コンピュータプログラム及び記憶媒体に関する。

ＬＳＩを含む論理回路の規模は、年毎に増加している。それに伴い、論理回路の検証にかかる工数も増加している。一方、市場には消費者が欲するときに製品を投入しなければならず、ＬＳＩを始めとした論理回路の開発期間は短くなっている。そのため、論理回路の設計・検証の効率向上を図る必要が生じている。

こうした中、ＬＳＩの論理検証に関して、テストの信頼性、網羅性を測る手段として機能カバレッジが知られている（特許文献１参照）。機能カバレッジとは、論理回路が所定の機能を実行したことを証明するために行うべき検証項目である。論理検証者はＬＳＩの仕様書からテストすべき項目を抽出し、テストアイテムリストを作成する。そして、リスト中のテストアイテム毎にどのようなパラメータの値を網羅すべきかをピックアップし、検証項目としての機能カバレッジを明確化する。論理検証者はまた、テスト用のプログラムを作成し、これを用いてシミュレーションを行う。その際、機能カバレッジを指標として、注目するパラメータの全ての値が網羅されるまでシミュレーションを行い、論理回路の機能を保証する。

より具体的には、論理回路が機能カバレッジに対応する所定の機能が実行されたか否かは、フラグを利用して判定することができる。即ち、論理回路の機能を検証するためのテストを実行し、それより論理回路の所定機能が実行されるとフラグがセットされ（例えば、フラグ値が“１”となる）、所定機能が実行されなければフラグはセットされない（例えば、フラグ値は“０”のままとなる）。従って、テストの実行後にフラグをチェックし、フラグがセットされていれば機能が実行されたことが証明され、フラグが立たなければ機能は実行されておらず検証が充分ではないことになる。

更に具体的に説明すると、例えばある回路が仕様として転送長１、２、４、８のトランザクションを起こす場合を想定する。これら全ての種類のトランザクションを機能カバレッジとして定義すれば、１、２、４、８のトランザクションが指標になる。ここで、あるテストを実行した場合に、１、２、８についてのみフラグがセットされたとすれば、該テストにより１、２、８については機能が実行されたことが証明される。しかし、該テストでは転送長が４の機能カバレッジについては検証が不十分となるので、更に転送長４についての検証を行うために、追加のテストを行うこととなる。追加テストの結果、転送長４についてフラグがセットされれば、検証が完了する。

ＬＳＩの論理検証においてはまた、各モジュールの機能および機能間でのプロトコル違反をチェックするためにモニタを繋げてシミュレーションを実行し、論理回路の不具合を発見したならば論理回路の不具合を修正している。更に、行った修正による不具合が生じていないかを確かめるための、リグレッションテストを繰り返し行っている。

ここで、リグレッションテストとは、ある回路にバグが見つかった場合に、そのバグを直したことで、回路がデグレードしていないかどうかを確かめるためのテストである。このテストにより、既存のテストを再度実行した際に、それまでは実行されていた機能が影響を受けていないかが検証される。
特開2001-101250号公報

以上のようにして論理回路の検証は行われるものであるが、近年は回路規模の増大により機能カバレッジの項目数が増加し、検証に必要とされるモニタの数も増えている。モニタを接続するとクロックの毎サイクルにおいて処理出力データを監視しなければならない。よって、モニタ数が増えれば増えるほど監視する回数、処理量が多くなりシミュレーション時間に影響を与え、シミュレーションの速度が低下する。そのため、リグレッションを終了するのにより多くの時間を要することとなる。これにより、一定期間内に満足のいく回数だけのテストを実行しきれないという問題があった。

本発明は、上記課題を鑑みてなされたものであり、論理回路の検証を行う際に、シミュレーション時間を短縮し、リグレッションテストを効果的に実行可能とすることを目的とする。

上記課題を解決するための本発明は、集積回路の動作につき検証すべき検証項目を定義し、前記検証項目を検証する複数のモニタを用意し、前記検証項目を複数のモニタの何れかに割り当ててその検証項目についての動作を前記モニタに検証させ、夫々のモニタが担当すべき検証項目の検証が終了したとき、そのモニタの活動を停止させることを特徴とする。

本発明によれば、論理回路の検証を行う際に、シミュレーション時間を短縮し、リグレッションテストを効果的に行うことができる。

以下、図面を参照しながら本発明の実施形態を説明する。

図１は本発明の代表的な実施形態である、ハードウェア記述言語で記述した論理回路を検証するための論理回路検証装置１００の概略図である。

図１において、検証項目保持部１０には、モニタとしてのデザイン観測部１１が取得すべき機能カバレッジ（検査指標）が定義され、蓄積されている。デザイン観測部１１は、本実施形態におけるモニタとして機能し、機能カバレッジに対応する各論理回路の動作（機能）が実行されたか否かを観測（モニタリング）する。モニタ結果保持部１２は、デザイン観測部１１において観測された機能カバレッジを保持する。これにより、該機能カバレッジに対応する機能が実行されたことを示すフラグが設定されることとなる。

比較部１３は、検証項目保持部１０に蓄積された機能カバレッジと、モニタ結果保持部１２に保持されている機能カバレッジとを比較して、機能カバレッジの全項目がすべて取得されたか否かを判定する。モニタリング制御部１４は、デザイン観測部１１を制御し、検証項目保持部１０に定義された機能カバレッジの全項目が取得されたと比較部１３により判定された場合に、デザイン観測部１１によるモニタリングを停止する。

図２を参照して、本実施形態に対応する論理回路検証装置１００における論理回路検証処理の一例を説明する。

ステップＳ２０１において、シミュレーションを行うＬＳＩ論理回路の仕様書から論理検証者が抽出したＬＳＩの検証項目に基づき、機能カバレッジの項目が定義される。定義された機能カバレッジ項目は、検証項目保持部１０に蓄積される。ステップＳ２０２では、ステップＳ２０１において定義された機能カバレッジをモニタリングするために、デザイン観測部１１に各種モニタを設定し、設定されたモニタにカバーする複数の機能カバレッジのセットが割当てられる。

ステップＳ２０３では、ステップＳ２０２において設定された全てのモニタを接続し、シミュレーションを開始する。ステップＳ２０４では、デザイン観測部１１において、モニタリングを継続中のモニタの機能カバレッジの取得状況のチェックを開始する。ここで、デザイン観測部１１は、モニタリング制御部１４の制御に基づきシミュレータ又は実際に組まれた論理回路について論理動作をモニタリングし、実行が検知された論理動作に対応する機能カバレッジは、モニタ結果保持部１２に保持される。

ステップＳ２０５では、モニタ結果保持部１２に保持された機能カバレッジにも基づき、検証項目保持部１０に蓄積された各モニタに割り当てられた機能カバレッジのセットの全てを取得したモニタが存在するか否かが、比較部１３により判定される。もし、取得すべき機能カバレッジの全てを取得したモニタが存在すると判定された場合には（ステップＳ２０５において「ＹＥＳ」）、ステップＳ２０７に移行して、モニタリング制御部１４の制御に基づいて対応するモニタの動作を停止させる。

一方、そのようなモニタが存在しない場合には（ステップＳ２０５において「ＮＯ」）、ステップＳ２０６に移行して、モニタリングが継続される。続いて、ステップＳ２０８では、各モニタの機能カバレッジ取得状況のチェックを終了する。但し、この時点でモニタリングが停止されていないモニタは、モニタリングを継続する。

続くステップＳ２０９では、全てのモニタが停止の状態になっているかいなかを判定する。もし、全てのモニタが停止状態にあると判定された場合には（ステップＳ２０９において「ＹＥＳ」）、ステップＳ２１０に移行してシミュレーションを停止する。一方、全てのモニタが停止状態にないと判定された場合には（ステップＳ２０９において「ＮＯ」）、ステップＳ２０４に戻って、機能カバレッジの取得状況のチェックを再開する。

次に、本発明をメモリコントローラに適用した場合のモニタの動作の実施形態を、図３から図８を参照して説明する。

まず、図３は、メモリコントローラ２２の構成の一例を示す図である。メモリコントローラ２２は、メモリ２３に繋がるバス１又は２上のマスターモデル（２０又は２１）からの要求に対してメモリ２３へデータを書き込み、メモリ２３からデータを読み出してマスターモデル（２０又は２１）側にデータを返す役割を担っている。図３においてマスターモデル１（２０）及びマスターモデル２(２１)は、メモリコントローラ２２とそれぞれバス１、バス２で接続され、メモリコントローラ２２を介してメモリ２３に対してライトまたはリード動作を行う。

ここで、メモリコントローラ２２の検証を行う場合、複数のモニタを付けて、メモリコントローラ２２に繋がる各マスターモデル（２０又は２１）からメモリ２３に対してリード・ライトアクセスが行えるか等の機能を検証する。

本実施形態では、メモリコントローラ２２の検証の際に確認すべき項目がリストアップされ、取得すべき各機能カバレッジを各モニタに割り当てることになる。

図４に、メモリコントローラ２２の検証の際に必要なモニタを全て接続した状態を表す一例を示す。図４において、バス１モニタ３０はメモリコントローラ２２とマスターモデル１（２０）とを繋ぐバス１上で起こるべき機能カバレッジを取得するためのモニタである。バス２モニタ３１は、メモリコントローラ２２とマスターモデル２（２１）とを繋ぐバス２上で起こるべき機能カバレッジを取得するためのモニタである。レジスタモニタ３２はメモリコントローラ２２内のレジスタへの設定値を観測するためのモニタである。

バッファ１モニタ３３は、マスターモデル１（２０）から送られたデータもしくマスターモデル１（２０）へ送るデータを保持するバッファを監視するためのモニタである。バッファ２モニタ３４は、マスターモデル２（２１）から送られたデータもしくマスターモデル２（２１）に送るデータを保持するメモリコントローラ２２内のバッファを監視するためのモニタである。

アービタモニタ３５は、メモリコントローラ２２内のバッファ１からのデータ送信要求とメモリコントローラ２２内のバッファ２からのデータ送信要求に対して、どちらのデータをトランザクションキューに入れるかを判断するためのモニタである。トランザクションキューモニタ３６は、キューの中でのデータの順番の入れ替え等を監視するためのモニタである。メモリモニタ３７はメモリコントローラ２２からメモリ２３に対して送信されるデータもしくはコマンド等を監視するモニタである。

図４に示したバス１モニタ（３０）に定義された機能カバレッジのセットの一例を図５に示す。

機能カバレッジセット５００において、バイトレーン５０１、バースト転送長５０２、ディレクション５０３、バイトレーン＆バースト転送長のクロス５０４、バイトレーン＆ディレクションのクロス５０５等の項目及び検証範囲が登録されている。また、各項目についての値を保存するための変数が登録されている。該変数には、byte_enable_cov５０６、Length_cov５０７、Direction_cov５０８、Byte_enable_length_cov５０９及びByte_enable_dir_cov５１０がある。

バイトレーン５０１は、例えばバス幅が３２ビット時に１バイトの転送を行う際、どのデータを有効にするかを示す信号であり、００００〜１１１１の１６種類の全ての事象が起きることがバス１モニタには機能カバレッジとして定義されている。従って、byte_enable_cov５０６は００００〜１１１１までのすべて事象が起きるまでテストが実行されることとなる。例えば、１回目のテストでカバーされた値が(０００１, ００１１, １０１１)で、２回目のテストでカバーされた値(００００, ０１０１, １１００, １１１０)とする。更に、３回目のテストでカバーされた値(００１０, １０００)で、４回目のテストでカバーされた値(０１１１, ０１１０, １１０１, ０１００, １００１)、更に５回目のテストでカバーされた値(１０１０, １０１１, １１１１)とする。以上で、byte_enable_cov５０６が取るべき値がすべて埋まったこととなり、バイトレーン５０１については取得すべき機能カバレッジがすべて取得されたこととなる。

また、バースト転送長５０２は、データを連続して転送する回数を示しており、図４においては１、２、４、８が定義されている。ディレクション５０３は、データをメモリ２３へ書き込む際のアドレスの方向を示している。

バイトレーンとバースト転送長のクロス５０４は、上述したバイトレーン５０１とバースト転送長５０２の各々の全ての組合せを示す。同様に、バイトレーンとディレクションのクロス５０５も上述したバイトレーン５０１とディレクション５０３の各々の全ての組合せを示す。

また、本実施形態に対応する他の機能カバレッジセットの一例として、メモリモニタ３７で定義されるものを図６に示す。図６において、メモリモニタ３７には、以下のようなメモリへのコマンドが機能カバレッジセット６００として定義されている。モードレジスタセット６０１、エクステンドモードレジスタセット６０２、アクティブコマンド６０３、プリチャージコマンド６０４。また、ライトコマンド６０５、ライトオートプリチャージコマンド６０６などである。また、mrs_cov６０７、emrs_cov６０８、active_cov６０９、pre_cov６１０、write_cov６１１及びwritea_cov６１２等の、各項目についての値を保存するための変数が登録されている。メモリモニタ３７は、各種コマンドが起こるたびに、機能カバレッジを取得し全てのコマンドの機能カバレッジが取得できるまでモニタリングを継続することになる。

本実施形態では、図４に示されるように、論理検証開始時は全てのモニタを接続した状態でシミュレーションの実行が開始される。初期の状態は全てのモニタがモニタリングを行っているので、論理回路との間で通信が発生しシミュレーションに時間がかかる。しかしながら、例えばバス１モニタ（３０）が、図５で示した全ての機能カバレッジを取得したならばモニタリング制御部１４の制御に従って、モニタリング機能が停止される。即ち、シミュレーション環境が図７に示すようになり、バス１モニタ（３０）が一つ取れた状態になる。

これによりバス１モニタ（３０）が機能カバレッジを取得するために要した通信時間が、他のモニタのために開放される。

同様にして、メモリモニタ３７が図６に示されるメモリ２３へのコマンド全てについて機能カバレッジを取得すれば、メモリモニタ３７はモニタリング制御部１４の制御に従いモニタリング機能を停止する。この結果、シミュレーション環境は、図８に示されるようになる。これにより、メモリモニタ３７が機能カバレッジを取得するために要した通信時間が他のモニタに開放される。

同様にして、各モニタがそれぞれが取得すべき機能カバレッジを全て取得するたびに、モニタの数が減少していくので、モニタ数の減少に従ってシミュレーションの速度が向上することになる。最終的には、全てのモニタが停止され、検証処理が終了する。

以上説明したように本発明によれば、複数のモニタを利用して論理回路の動作検証を行う場合に、取得すべき機能カバレッジの全てを取得したモニタから順にモニタリング動作を停止させ、処理資源を他のモニタに開放することとしている。これにより、検証が進行するに従いシミュレーション速度を向上させ、一度にかかるテスト時間を短縮化し、一定期間内により多くのテストを実行することが可能となる。また、本発明によれば、論理回路及びそのシステム開発の検証工程に要する時間を短縮化できるので、論理システム開発の効率化に繋げることができる。

［その他の実施形態］
なお、本発明は、複数の機器（例えばホストコンピュータ、インタフェイス機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。

また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（または記録媒体）を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

本発明の実施形態に対応する論理回路検証装置の構成の一例を示す図である。 本発明の実施形態に対応する論理回路検証処理の一例に対応するフローチャートである。 本発明の実施形態に対応するメモリコントローラの構成の一例を示す図である。 本発明の実施形態に対応するメモリコントローラの検証用のモニタの一例を示す図である。 本発明の実施形態に対応するバス１モニタの取得すべき機能カバレッジの一例を示す図である。 本発明におけるメモリモニタの取得すべき機能カバレッジの一例を示した図である。 図４のシミュレーション環境から、バス１モニタのモニタリングが停止された状態を示す図である。 図７のシミュレーション環境から、更にメモリモニタのモニタリングが停止された状態を示す図である。

Claims (6)

1. 論理回路の検証項目のセットを複数登録する登録手段と、
   前記検証項目について前記論理回路をシミュレーションするシミュレーション手段と、
   複数の前記セットのいずれかにそれぞれ割り当てられ、前記シミュレーションにおいて前記検証項目に対応する前記論理回路の動作をモニタリングする複数のモニタリング手段と、
   前記モニタリングにより動作が確認された検証項目を保持する保持手段と、
   前記保持手段に、前記セットに含まれる検証項目の全てが保持された場合に、該セットに割り当てられた前記モニタリング手段の動作を停止する制御手段と、
   を備えることを特徴とする論理回路検証装置。
2. 前記シミュレーション手段は、前記複数のモニタリング手段のすべての動作が停止された場合に、前記シミュレーションを終了することを特徴とする請求項１に記載の論理回路検証装置。
3. 登録部に複数登録された論理回路の検証項目のセットの該検証項目について前記論理回路をシミュレーションするシミュレーション工程と、
   複数の前記セットのいずれかにそれぞれ割り当てられた複数のモニタリング部により、前記シミュレーションにおいて前記検証項目に対応する前記論理回路の動作をモニタリングするモニタリング工程と、
   前記モニタリング工程において動作が確認された前記検証項目を保持部に保持する保持工程と、
   前記保持部に前記セットに含まれる検証項目の全てが保持された場合に、該セットについて割り当てられた前記モニタリング部の動作を停止する制御工程と、
   を備えることを特徴とする論理回路検証装置の制御方法。
4. 前記シミュレーション工程では、前記複数のモニタリング部のすべての動作が停止された場合に、前記シミュレーションが終了されることを特徴とする請求項３に記載の論理回路検証装置の制御方法。
5. 請求項３又は４のいずれかに記載の論理回路検証装置の制御方法をコンピュータに実行させるためのコンピュータプログラム。
6. 請求項５に記載のコンピュータプログラムを格納したコンピュータで読み取り可能な記憶媒体。

Images