(57)【要約】【課題】ＬＳＩの論理機能検証において、試験条件がシミュレーション実行中に確実に発生していることを確認する試験条件充足の測定を、バグ修正や内部インプリメンテーション仕様変更に影響されずに効率よく行うことを可能にするＬＳＩの論理機能検証での試験条件充足測定方法を得ること。【解決手段】意図した試験条件の成立可否を検証する検証データ（チェッカ）として、パターン４の作成時に、その試験内容である試験条件を設計論理６から導出される設計論理内部情報７を含めないで記述した試験条件記号５を作成し、また、設計論理６から設計論理内部情報７を導出して用意し、シミュレーション手段８にて、試験条件記号５を用いて設計論理内部情報７のシミュレーションを実行し、パターン４によって行いたい試験内容がシミュレーション実行中に確実に発生していることを確認する。【選択図】        図１
2007108995.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータ上に構築したシミュレーション環境にて、ＬＳＩの論理機能の検証用に作成したパターンを用いて検証対象である設計論理のシミュレーションを実行し、その動作結果が正しいか否かを確認することで合否判断を行うＬＳＩの論理機能検証において、
意図した試験条件の成立可否を検証する検証データとして、前記パターン作成時に、その試験内容である試験条件を前記設計論理から導出される設計論理内部情報を含めないで記述した試験条件記号を作成する工程と、
前記設計論理から前記設計論理内部情報を導出して用意する工程と、
前記試験条件記号と前記設計論理内部情報とを前記シミュレーション環境に入力して前記試験条件記号を用いた前記設計論理内部情報のシミュレーションを実行し、前記パターンによって行いたい試験内容がシミュレーション実行中に確実に発生していることを確認する試験条件充足測定を行う工程と
を含むことを特徴とするＬＳＩの論理機能検証での試験条件充足測定方法。
【請求項２】
試験条件充足測定を行う工程は、
前記試験条件記号を前記設計論理内部情報に基づきシミュレータに入力可能なＨＤＬ記述に変換する工程と、
得られた前記ＨＤＬ記述によるコードを前記シミュレーション環境に入力して前記確認を行う工程と、
を含むことを特徴とする請求項１に記載のＬＳＩの論理機能検証での試験条件充足測定方法。
【請求項３】
試験条件充足測定を行う工程は、
前記シミュレーション環境に前記試験条件記号の意味を解読するエンジンを用意する工程と、
前記エンジンが、前記試験条件記号と前記設計論理内部情報との入力を受けて、シミュレーション実行中において検証対象である設計論理の内部の観測すべきノードを観測し、それと前記試験条件記号とを照合して前記確認を行う工程と、
を含むことを特徴とする請求項１に記載のＬＳＩの論理機能検証での試験条件充足測定方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ＬＳＩ（大規模集積回路）の論理機能検証での試験条件充足測定方法に関するものである。
【背景技術】
【０００２】
従来から、ＬＳＩの論理設計段階における設計論理の機能検証は、コンピュータ上に構築したシミュレーション環境を使用して行っている。つまり、予め検証用にテストベンチ及びパターンを用意し、それを用いて検証対象である設計論理をシミュレータ上でシミュレーションを行い、そのシミュレーション結果が正しい結果であることを確認することで合否判断を行っている（例えば、特許文献１参照）。
【０００３】
ところで、この機能検証においては、設計する際のリファレンスである仕様書を基にして検証項目を定義し、この検証項目に書かれている検証内容を実現する手段として、前記のテストベンチ及びパターンを作成する。
【０００４】
このテストベンチ及びパターンは、基本的には当該ＬＳＩの設計者が手作業で作成するものである。そのため、作成したテストベンチ及びパターンが不適切であることが起こり得る。この場合は、検証項目で意図していた試験内容がシミュレーション実施時において発生していない可能性が常に存在する。しかし、悪いことに、意図した試験内容が発生していないからと言ってシミュレーション結果が期待された動きにならないとは限らない。つまり、テストベンチ及びパターンが不適切であったために、検証項目で意図していた試験内容がシミュレーション実施時において発生していなくとも、シミュレーション結果が期待された通りに動作し、合否判定において合格と判断される場合があり得る。
【０００５】
この問題に対する解決方法としては、チェッカを用いる方法が採られている。チェッカとは、ある意図した試験条件が成立したか否かをチェックするＨＤＬ（Hardware Description Language：ハードウェア記述言語）で書かれたコード（検証データ）である。
【０００６】
すなわち、検証項目が定義され、検証内容が決まれば、どのような試験条件を発生させたいのかが決まるので、その意図した試験条件が発生したか否かをチェックするＨＤＬで書かれたコード（チェッカ）を、テストベンチやパターンとは別に作成し、シミュレーション環境に入力する。チェッカは、シミュレーション実行中に、検証対象論理の内部ノードをモニタしており、意図した試験条件が発生していることが観測されれば、その旨のメッセージを画面出力などによって検証オペレータに通知する。
【０００７】
検証オペレータは、シミュレーション結果の合否判断として、得られた結果が期待値と一致しているか、チェッカによって意図した試験条件が発生しているかを調べる。得られた結果が期待値と一致し、且つチェッカによって意図した試験条件が発生していることを確認できている場合に、その試験は合格と判断される。
【０００８】
意図した試験条件が発生していない場合は、テストベンチあるいはパターンの不適切により、そもそも行いたい試験ができていないことを意味する。この場合には、得られた結果の期待値との比較自体に意味はないので、期待値との比較結果に関わらず、テストベンチあるいはパターンを適切に修正し、再度シミュレーションを行い、チェッカによる意図した試験条件が発生していることの確認ができるまで、修正とシミュレーションとを行う必要がある。
【０００９】
また、意図した試験条件は発生しているが、シミュレーション結果が期待値と一致していない場合は、テストベンチ及びパターンは適切に試験ができているが、検証対象論理の不具合により不合格となったことを意味する。この場合には、検証対象論理を修正し再度シミュレーションを行い、チェッカによる意図した試験条件が発生していることの確認ができ、且つシミュレーション結果が期待値と一致していることが確認できるまで、これを繰り返すことになる。
【００１０】
【特許文献１】特開平３−６２１７２号公報（論理検証充分性評価方法）
【発明の開示】
【発明が解決しようとする課題】
【００１１】
しかしながら、従来の方法では、意図した試験条件が発生していることをチェックするためのチェッカ作成では、検証対象論理の内部ノード情報をそのまま用いて記述しているので、次のような問題がある。
【００１２】
第１に、チェッカを作成できるのが検証対象論理のコーディングが完了した以降の段階になってしまうので、検証項目が定義された段階においてはチェッカによってチェックすべき試験条件は決定されているのに、検証対象論理のコーディングが完了していないために、チェッカの作成ができない。つまり、従来では、チェッカの作成までにタイムラグが発生する可能性があり、効率的とは言えない。
【００１３】
第２に、検証が進むにつれて検証対象論理のバグ発見による論理の修正が発生する。この場合、従来では、チェッカは検証対象論理の内部ノード情報を直接記述しているので、この論理修正によって多くのチェッカもまた修正する必要が発生する可能性があり、効率的とは言えず、またチェッカの可搬性に欠ける。
【００１４】
第３に、過去において既に開発済みである論理について、外部仕様は変えずに内部ノードの設計を変更するようなケースがある。例えば、同一の機能を有しながら、性能を向上させるような開発である。このような場合では、論理は設計し直しであるので検証も再度実施することとなるが、機能的には既に開発済みの論理と同等であるので、開発済みの論理の機能検証で使用したテストベンチ、パターン及びチェッカがそのまま使用できることが期待されるが、チェッカについてはその多くが修正を必要とする可能性が高い。同様にチェッカの可搬性に欠ける。
【００１５】
この発明は、上記に鑑みてなされたものであり、ＬＳＩの論理機能検証において、試験条件がシミュレーション実行中に確実に発生していることを確認する試験条件充足の測定を、バグ修正や内部インプリメンテーション仕様変更に影響されずに効率よく行うことを可能にするＬＳＩの論理機能検証での試験条件充足測定方法を得ることを目的とする。
【課題を解決するための手段】
【００１６】
上述した目的を達成するために、この発明にかかるＬＳＩの論理機能検証での試験条件充足測定方法は、コンピュータ上に構築したシミュレーション環境にて、ＬＳＩの論理機能の検証用に作成したパターンを用いて検証対象である設計論理のシミュレーションを実行し、その動作結果が正しいか否かを確認することで合否判断を行うＬＳＩの論理機能検証において、意図した試験条件の成立可否を検証する検証データとして、前記パターン作成時に、その試験内容である試験条件を前記設計論理から導出される設計論理内部情報を含めないで記述した試験条件記号を作成する工程と、前記設計論理から前記設計論理内部情報を導出して用意する工程と、前記試験条件記号と前記設計論理内部情報とを前記シミュレーション環境に入力して前記試験条件記号を用いた前記設計論理内部情報のシミュレーションを実行し、前記パターンによって行いたい試験内容がシミュレーション実行中に確実に発生していることを確認する試験条件充足測定を行う工程とを含むことを特徴とする。
【００１７】
この発明によれば、試験条件がシミュレーション実行中に発生していることを確認するための検証データ（チェッカ）は、検証対象論理の内部ノードを直接記述するのではなくパターン作成時に別名を用いて記述を行い、論理設計時に検証対象論理の内部ノード情報を設計論理内部情報として別に準備し、論理シミュレーション実施時に、この別名で記述されたチェッカと設計論理内部情報とを用いて論理シミュレーションを行うことで、試験条件充足の測定を行う。これによれば、チェッカは、論理設計が完了する前に作成することが可能であるので、バグ修正や内部インプリメンテーション仕様変更のために内部ノード情報が変更された場合でも、変更が必要なのは設計論理内部情報のみであり、チェッカの修正は不要である。すなわち、チェッカの可搬性が向上する。
【発明の効果】
【００１８】
この発明によれば、検証データ（チェッカ）の可搬性が向上するので、バグ修正や内部インプリメンテーション仕様変更の影響を受けずに、ＬＳＩの論理機能検証と並行して、試験条件充足の測定を効率よく行うことができるという効果を奏する。
【発明を実施するための最良の形態】
【００１９】
以下に図面を参照して、この発明にかかるＬＳＩの論理機能検証での試験条件充足測定方法の好適な実施の形態を詳細に説明する。
【００２０】
図１は、この発明の一実施の形態による試験条件充足測定方法が実施されるＬＳＩの論理機能検証を説明するフローチャートである。図１に示すように、ＬＳＩの論理機能検証では、まず、設計する際のリファレンスである仕様書１を基に、検証項目２が定義され、また設計論理６が設計される。
【００２１】
そして、この検証項目２から、その検証項目２で意図している試験内容を実現するためのテストベンチ３及びパターン４が作成される他、この実施の形態では、試験条件記号５が作成される。この試験条件記号５は、検証項目２で意図している試験内容、つまり試験条件がシミュレーション実行中に発生していることをチェックするためにそのチェック内容を記述したチェッカである。また、設計論理６から設計論理内部情報７が定義される。このように作成ないしは定義されたテストベンチ３，パターン４，試験条件記号５，設計論理６及び設計論理内部情報７は、シミュレーション手段８に入力される。
【００２２】
シミュレーション手段８は、テストベンチ３及びパターン４を用いて設計論理６のシミュレーションを実行し、その動作結果が正しいか否かを確認して合否判断を行うの用いるミュレーション結果値９を出力する。並行して、シミュレーション手段８は、試験条件記号５を用いて設計論理内部情報７のシミュレーションを実行し、試験条件記号５に記述されている試験条件、つまりパターンによって行いたい試験内容がシミュレーション実行中に発生していることを確認する試験条件充足測定を行うのに用いる試験条件発生結果１０を出力する。
【００２３】
ここで、この試験条件記号５の記述には、検証対象論理の内部コード情報は含まれていない（図４参照）。したがって、試験条件記号５は、検証対象論理のコーディング完了を待たずに記述することが可能であり、効率的である。また、試験条件記号５は、検証対象論理の修正に連動して修正する必要がなく、効率的であり、また可搬性が向上する。
【００２４】
次に、図２〜図６を参照して、実際の試験条件記号及び設計論理内部情報の記述例について説明する。なお、図２は、仕様書１の一仕様例を示す図である。図３は、検証項目２の一例を示す図である。図４は、試験条件記号５の一例を示す図である。図５は、設計論理６の一例を示す図である。図６は、設計論理内部情報７の一例を示す図である。
【００２５】
図２に示すように、「仕様」では、設計論理は、いわゆるステートマシンを持つとして規定されている。図２では、設計論理は、内部で２つの状態Ｓ０，Ｓ１を持ち、現在の内部状態と外部からの入力値ｌ０，ｌ１により、設計論理からの出力値０と次の内部状態とが決定される例が示されている。
【００２６】
図３では、図２に示す仕様例から定義された一つの検証項目の例として、「状態Ｓ１の時に入力ｌ０＝かつｌ１＝１を与えて、その結果が出力０＝０かつ状態Ｓ０になる事を確認する。」が示されている。
【００２７】
図４は、図２に示す仕様例と図３に示す検証項目例とを基に記述された試験条件記号の例である。試験条件記号では、仕様例において定義されるステートマシンの遷移条件と、検証項目例において意図される試験条件とが、記号として明記されている。重要なのは、試験条件記号は、図４に示すように、「State,I0,I1」という一時的な名前「State」のみを使用して記述し、図６に示す検証対象論理の内部ノード名称「Status」を直接記述していないということである。
【００２８】
図５は、図２に示す仕様例を基にした設計論理例である。図６は、図５に示す設計論理例から導き出される設計論理内部情報例である。図６では、試験条件記号例で記述された一時的な名前「State」に対応する設計論理内部のノード名称「Status」が記述されている。この設計論理内部のノード名称「Status」は、検証対象論理のコーディングが完了した時点、あるいは一旦完了した後に修正が入った時点で記述する。
【００２９】
次に、図７と図８は、図１に示すＬＳＩの論理機能検証において実施されるこの発明の一実施の形態による試験条件充足測定方法を説明するフローチャートである。図７、図８に示すように、この実施の形態による試験条件充足測定方法では、試験条件記号と設計論理内部情報とを基にシミュレーション実行中において意図した試験条件が発生していることをチェックすることが行われる。
【００３０】
図７では、試験条件記号をシミュレーション手段に入力可能なＨＤＬコードに変換してからシミュレーションを行う場合が示されている。図７において、ＨＤＬコード生成手段２３は、試験条件記号２１及び設計論理内部情報２２を基に、ＨＤＬコード２４を生成する。この生成されたＨＤＬコード２４は、テストベンチ２５及びパターン２６と共に、シミュレーション手段２７に入力される。ＨＤＬコード２４は、試験条件記号２１に記述されている試験条件がシミュレーション実行中に発生したことをチェックする機能を有するコードである。これによって、シミュレーション手段２７では、シミュレーション実行中に意図した試験条件が発生したか否かのチェックが行われ、図１に示した試験条件発生結果１０がシミュレーション結果値９と共に出力される。
【００３１】
図８では、試験条件記号を直接シミュレーション手段に入力する場合が示されている。図８において、試験条件記号３１及び設計論理内部情報３２とテストベンチ２５及びパターン２６とは、共に、シミュレーション手段２７に入力される。そのうち、試験条件記号３１及び設計論理内部情報３２は、シミュレーション手段２７に設けた試験条件記号の意味を解読するエンジンである試験条件記号解読手段３６に入力される。
【００３２】
試験条件記号解読手段３６は、設計論理内部情報３２からシミュレーション実行中に観測すべき検証対象内部のノード名を取得し、試験条件記号３１からチェックすべき条件を取得することで、シミュレーション実行中において、観測すべき検証対象内部のノードを観測し、それらの値が試験条件記号３１に書かれている条件を満たすか否かをチェックする。これによって、シミュレーション手段３５では、シミュレーション実行中に意図した試験条件が発生したか否かのチェックが行われ、図１に示した試験条件発生結果１０がシミュレーション結果値９と共に出力される。
【００３３】
このように、この実施の形態によれば、試験条件がシミュレーション実行中に発生していることをチェックするためのチェッカとして、検証対象論理の内部ノード情報を持たない試験条件記号で記述するようにし、論理設計時に検証対象論理の内部ノード情報を設計論理内部情報として別に準備するので、設計論理が何時コーディング完了するかに関わらず、検証項目を定義した時点で試験条件記号を記述することが可能である。また、バグ修正や内部インプリメンテーション仕様変更によって、検証対象論理に修正が入ったとしても、それに合わせて修正しなければいけないのは設計論理内部情報のみであり、試験条件記号を修正する必要はなく、チェッカの可搬性が向上する。したがって、バグ修正や内部インプリメンテーション仕様変更の影響を受けずに、ＬＳＩの論理機能検証と並行して、試験条件充足の測定を効率よく行うことができる。
【産業上の利用可能性】
【００３４】
以上のように、この発明にかかるＬＳＩの論理機能検証での試験条件充足測定方法は、ＬＳＩの論理機能検証において、試験条件がシミュレーション実行中に確実に発生していることを確認する試験条件充足の測定を、バグ修正や内部インプリメンテーション仕様変更に影響されずに効率よく行う方法として有用である。
【図面の簡単な説明】
【００３５】
【図１】この発明の一実施の形態による試験条件充足測定方法が実施されるＬＳＩの論理機能検証を説明するフローチャートである。
【図２】図１に示す仕様書の一仕様例を示す図である。
【図３】図１に示す検証項目の一例を示す図である。
【図４】図１に示す試験条件記号の一例を示す図である。
【図５】図１に示す設計論理の一例を示す図である。
【図６】図１に示す設計論理内部情報の一例を示す図である。
【図７】図１に示すＬＳＩの論理機能検証において実施されるこの発明の一実施の形態による試験条件充足測定方法（その１）を説明するフローチャートである。
【図８】図１に示すＬＳＩの論理機能検証において実施されるこの発明の一実施の形態による試験条件充足測定方法（その２）を説明するフローチャートである。
【符号の説明】
【００３６】
１  仕様書
２  検証項目
３，２５，３３  テストベンチ
４，２６，３４  パターン
５，２１，３１  試験条件記号
６  設計論理
７，２２，３２  設計論理内部情報
８，２７，３５  シミュレーション手段
９  シミュレーション結果値
１０  試験条件発生結果
２３  ＨＤＬコード生成手段
２４  ＨＤＬコード
【図１】
2007108995.tif 000003
【図２】
2007108995.tif 000004
【図３】
2007108995.tif 000005
【図４】
2007108995.tif 000006
【図５】
2007108995.tif 000007
【図６】
2007108995.tif 000008
【図７】
2007108995.tif 000009
【図８】
2007108995.tif 000010