(57)【要約】【課題】  ＬＳＩの論理検証において、ＬＳＩの論理検証にかかる時間を、検証の信頼性を確保しつつ短縮する事である。【解決手段】  ひとつのパラメータの取りうる値の範囲を全て網羅した第１のパラメータリストから無作為に値を抜き取るステップと、前記パラメータをテストに設定するステップと、前記テストをＲＴＬよりも抽象度の高いモデルに対して実施し、前記モデルのソースコードカバレッジを取得するステップと、前記取得したソースコードカバレッジを解析するステップと、前記カバレッジ解析結果により前記抜き取ったパラメータの値を取捨選択し、第２のパラメータリストを作成するステップと、前記全てのステップを前記第１のパラメータのリストがなくなるまで繰り返し、これにより作成された第２のパラメータのリストを用いてＲＴＬデザインに対してシミュレーションを行うステップからなる。【選択図】  図１
2007026183.tif 000002
【特許請求の範囲】
【請求項１】
LSIの論理検証において、RTLよりも抽象度の高いモデルに対して第１のテストを実施し、前期モデルのソースコードカバレッジを取得するステップと、ソースコードカバレッジ結果によりテストに用いるパラメータの値の範囲を制限するステップと、該制限されたパラメータを用いてRTLデザインに対して第２のテストを実施するステップからなる論理検証方法。
【請求項２】
前記テストに用いるパラメータの範囲を制限するステップにおいて、テストに用いるひとつのパラメータの取りうる値すべてを網羅した第１のパラメータリストから、ひとつづつ値を抜き取り、前記第１のテストを実施し、判定基準により該パラメータ値の取捨選択を行い、第２のパラメータリストを作成する事を特徴とする、請求項１記載の論理検証方法。
【請求項３】
前記第１のパラメータリストから、ひとつの値を抜き取る際に、無作為に抜き取る事を特徴とする、請求項１記載の論理検証方法。
【請求項４】
前記取捨選択の判定基準において、前記カバレッジ解析結果により、既に第2のパラメータリストに登録された同一のソースコードを活性化させるパラメータの値と比較し、最小値となる場合、もしくは最大値となる場合に採用し、前記第2のパラメータリストに新たに登録する事を特徴とする、請求項１記載の論理検証方法。
【請求項５】
前記第2のパラメータリストに新たな値が採用、登録された場合に、前記第2のパラメータリストに既に登録されたパラメータの値のうちから、同一のソースコードを活性化させるパラメータの値の内から、最大値、もしくは最小値とならなくなった値を削除する事を特徴とする、請求項1記載の論理検証方法。
【請求項６】
前記第2のパラメータリストに新たな値が採用、登録された場合に、前記新たな値と同一のソースコードを活性化させるパラメータの最大値、もしくは最小値と、前期新たな値との間にあるパラメータの値を、前記第1のパラメータリストから削除する事を特徴とする、請求項1記載の論理検証方法。
【請求項７】
前記RTLよりも抽象度の高いモデルを時間概念の無い動作モデルとした事を特徴とする、請求項1記載の論理検証方法。
【請求項８】
前記RTLよりも抽象度の高いモデルをデータ転送レベルとした事を特徴とする、請求項1記載の論理検証方法。
【請求項９】
前記第2のパラメータリストを作成するステップにおいて、前記テストに用いる複数のパラメータに対して実施し、前期複数のパラメータに対して作成された複数の第2のパラメータリストを用いて、前記RTLデザインに対してテストを行う事を特徴とする、請求項1記載の論理検証方法。
【請求項１０】
LSIの論理検証において、検証対象論理回路のリファレンスモデルと、検証対象回路のパラメータが取りうる値を網羅した第1のパラメータリストと、前記検証対象論理回路を論理検証するためのテストと、前記リファレンスモデルに対してテストを実行するリファレンスモデルシミュレータと、前記リファレンスモデルシミュレータが出力するリファレンスモデルのソースコードカバレッジと、前記ソースコードカバレッジを解析する解析部と、前記解析部により作成された第2のパラメータリストと、検証対象の論理回路と、前記検証対象の論理回路に対してテストを実行するシミュレータを具備する事を特徴とする論理検証システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、LSIの論理検証に関して、その信頼性を確保しつつ論理検証期間を短縮する技術に関するものである。
【背景技術】
【０００２】
近年、LSIの集積度が飛躍的に向上し、１チップに搭載できる論理回路が膨大になっている。これに伴い、論理回路の検証に要する期間が非常に長期化しており、LSIの開発期間を短縮する観点から、検証期間を短縮しつつ、かつ検証の信頼性を確保することへの要求が高まっている。
【０００３】
こうした中、LSIの論理検証に関して、テストの信頼性、網羅性を測る手段として機能カバレッジや、RTLのソースコードカバレッジが知られている。
【０００４】
まず、機能カバレッジについて説明する。論理検証者はLSIの仕様書からテストすべき項目を抽出し、テストアイテムリストを作成する。また、このテストアイテムリストのテストアイテムごとにどのようなパラメータの値を網羅すべきかをピックアップし、機能カバレッジ項目を明確にする。論理検証者はテストを作成し、シミュレーションを行った際に、この機能カバレッジを指標として、注目するパラメータの全ての値が網羅されるまでシミュレーションを行い、論理回路の機能を保証する。
【０００５】
また、RTLのソースコードカバレッジは、作成したテストにテスト漏れが無いことを確認する事ができる。作成した全てのテストを流し、検証対象のRTLソースコードの各行が実施されたか、つまり活性化されたかどうかを調べるのがソースコードカバレッジである。このとき、活性化されないソースコードがあった場合にはそのソースコードが実現している機能が検証できていない事であり、テスト漏れを発見、及びこれに対してテストを追加する事ができ、より信頼性の高いテストセットを作成する事ができる。もしくは活性化されなかったソースコードはLSI仕様書に書かれていない機能を実現してしまったソースコード、あるいは冗長なソースコードであることが分かり、作成したテストセットの信頼性を確認する事ができる。
【０００６】
又、従来例としては、例えば特許文献１と特許文献２をあげることが出来る。
【特許文献１】特開２００３−１０８４０５号公報
【特許文献２】特開２００１−１４３６５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
従来の例では、ある機能を保証するためにはピックアップされたパラメータについて、とりうる全ての値を網羅しなくてはならないとしているが、この値の中にはある機能を保証するために冗長なものが含まれる可能性がある。これら冗長なパラメータの値を網羅するということにより不必要にシミュレーション時間を長くしてしまうという問題点があった。また、パラメータによってはとりうる値を網羅することが、有限時間内では非常に困難であり、また、その値の遷移条件や他のパラメータとの組み合わせ条件なども網羅することを考慮すると、事実上網羅することが不可能になるという問題があった。また、これに対し、検証期間を短縮するためにパラメータの中から特徴を見つけ出し、例えばパラメータAが０から３１までの値を取りうる場合には、桁上がりを境界とし、0から31まで全てを網羅するのではなく、[0] [1] [2] [4] [8] [16] [31]の様にカバーすべき値を限定してしまう方法や、もしくは[0] [1] [2..3] [4..7] [8..15] [16..31]のようにあるレンジを設けて、それぞれのレンジの中で1つでもカバーされればそのレンジがカバーされた事にするという方法が行われているが、これら境界は回路に実装された境界とは異なる可能性があり、機能的に網羅されたとは言えないという問題があった。
【課題を解決するための手段】
【０００８】
上記問題点を解決するために本発明の検証方法は、以下のようなステップから構成されている。
【０００９】
LSIの論理検証において、RTLよりも抽象度の高いモデルに対して第１のテストを実施し、前期モデルのソースコードカバレッジを取得するステップと、ソースコードカバレッジ結果によりテストに用いるパラメータの値の範囲を制限するステップと、該制限されたパラメータを用いてRTLデザインに対して第２のテストを実施するステップからなる事を特徴とする。
【００１０】
（作用）
本発明の検証方法による作用は、網羅すべきパラメータの値を限定する作業を、仕様を基に実装された、既に正しく動作する事が確認されたモデルを使用して行う事ができ、この結果網羅すべきパラメータのとりうる値の範囲を削減する事ができるため、LSIの論理検証にかかる時間を、信頼性を確保しつつ短縮する事ができることである。
【発明の効果】
【００１１】
以上のように本発明の論理検証法によれば、検証すべきパラメータの値を絞り込む作業をリファレンスモデルを動作させて行うので、リファレンスモデルは実際に動作させてその機能が確認されたものであるため、仕様書を基にパラメータの値を絞り込む事に比較してより信頼性の高いパラメータ値を得る事ができる。このためRTLデザインに対して十分な検証を、より短期間で行う事を実現する事ができる。また、この絞込み作業自体もRTLデザインでシミュレーションを行うのに先駆けてシミュレーション速度が高速なモデルで行うため、短期間で行う事ができる。これらの効果によりLSIの論理検証期間を短縮する事ができ、ひいてはLSI開発のコストを削減する事ができる。
【発明を実施するための最良の形態】
【００１２】
（実施例１）
図1は本発明の論理検証システムの構成を示す一実施形態である。LSIの開発は、一般的に次のような工程からなる。まず初めに、所望の機能を実現するために必要とする要素を洗い出し、その要求仕様を作成する。次に前記要求仕様に基づき、前記所望の機能を実現するアルゴリズムを検討するため、実際に比較的抽象度の高い言語を用いてモデルを作成し、これを動作させて仕様をさらに詳細に落とし込んで詳細仕様を作成する。この詳細仕様を受け、回路設計者はRTL(Register Transfer Level)の設計を行う。一方論理検証者は同様に前記詳細仕様を基に、検証プランを立て、テストを作成し、検証を行う。この工程において、アルゴリズムを検討する際に作成した抽象度の高い言語を用いて作成したモデル（抽象度の高いモデル）をリファレンスモデル(ゴールデンモデル)とし、すなわちこのリファレンスモデルが出力する値を期待値（答）として論理検証を行う方法が一般に知られている。図1に示す１１０ Reference Modelがこれにあたる。ここでReference ModelはRTLレベルよりも抽象度の高いモデルとし、時間概念を持たないUntimed Model（UT）であっても、また、信号転送レベルTransfer Level Model（TL）であっても構わない。本発明における論理検証システムは、この１１０ Reference Modelと、論理検証のために作成した１２０ テストと、テストすべきパラメータの取りうる値全てを網羅した１００ Parameter List １と、これら１１０，１２０，１００を入力とし、Simulationを実行する１３０ Reference Model Simulatorと、このReference Model Simulatorが出力する１４０ Source Code Coverageと、該Source Code Coverageと１００ Parameter List １を入力として解析を行う１３１Parameter & Coverage解析部と、該解析部により解析された結果により作成された１０１Parameter List ２と、設計されたRTL回路１１１RTL Designと、これら１０１，１１１、及び前記１２０Testを入力とし、Simulationを実行する１３２RTL Simulatorから構成される。
【００１３】
図３は、図1に示す論理回路検証システムを用いて本発明の論理検証方法を実現するフローを示した一実施例である。図３に基づき、本発明の論理検証方法を説明する。まず、作成したあるテストで使用する、ある1つのパラメータに注目する。このパラメータが取りうる値を網羅したリストを作成する。このリストが図1に示す１００ Parameter List １である。また、このParameter List 1から図1における１０１Parameter List 2を作成する過程における2つのParameter Listの内容の変化の様子を図2に示す。図2の２００に示すように、このパラメータは「０」から「３１」までを取るものとし、図に示されたように「０」から「３１」までの値全ての値がリストの中に存在する。このリスト２００の中から無作為に値を一つ選択してリストから削除し（３０１）、テストにこのパラメータの値を設定する（３０２）。そしてReference Modelを使用してSimulationを実施する（３０３）。図2の例ではリスト２００から無作為に選択された値は１であり、リスト２０１で値「１」が削除されているのがわかる。Simulationを実施するのと並行して、このテストでReference Modelのソースコードのどの行が活性化されたか（ソースコードカバレッジ）を記録する（３０３）。次に出力されたソースコードカバレッジの解析を行う（３０４）。ここでは1回目のテストであるため比較すべきソースコードカバレッジが無い。すなわち、このテストを実行した際に、Reference Modelソースコードの複数の行が活性化されるが、選択されたパラメータの値が、この活性化された行のうち、どの行を活性させたのかをこの時点では知る事ができない。このため図2の２１１リストに示すようにParameter List ２に選択されたパラメータの値１を記録することと、活性化したソースコードの情報の記録を行う。Parameter List 1にパラメータの値が存在するかを確認し（３２０）、パラメータの値が存在するのでParameter List 1から無作為に値を選択するステップ３０１へ戻る。
【００１４】
次に選択された値が「８」であった場合、Parameter List 1は図2のリスト２０２の様になる。再度ステップ３０２、３０３を実施し、出力されたソースコードカバレッジ結果を前回までのカバレッジ結果と比較する（３０４）。変化が見られた場合（３１０）は今回選択されたパラメータの値を、リファレンスモデルに対して今まで選択されたパラメータの値（この場合は「1」）とは別の影響を与える値として認識することができ、すなわちパラメータの値を別のカテゴリーとして分類する事ができる。新たなカテゴリーを定義し、カテゴリーと共にこの値をParameter List 2に登録する（３１１）。この様子を図2のリスト212に示している。値「８」はCategory Bとして登録されている。また、この時、前回選択された値「1」は、値「8」とは別のカテゴリーであり、パラメータの値「８」が活性化させたソースコードから値「１」が活性化させたソースコードがどこであるかを知る事ができ、はじめてカテゴリーを定義する事ができる。ここではパラメータの値「１」に対してCategory Aと定義している。各Categoryはリファレンスモデルの特定のソースコードに対応して存在する。再びParameter List 1にパラメータが存在するかを確認し（３２０）、パラメータが存在するのでParameter List 1から無作為に値を選択するステップ３０１へ戻る。
【００１５】
次に選択された値が「４」であった場合、Parameter List 1は図2のParameter List 1の２０３の様になる。再度ステップ３０２、３０３を実施し、出力されたソースコードカバレッジ結果を前回までのカバレッジ結果と比較する（３０４）。新たな変化点が無い（３１０）ため既に定義されたCategoryに属すると判断される（３１２）。ソースコードカバレッジ結果より、Category Aに属すると判断し（３１３）、Category Aに登録済みのパラメータの値「１」と比較する（３１３）。パラメータの値「４」はCategory Aの値の中で最大値となる（３１４）ので、Parameter List ２のCategory Aにパラメータの値「４」を追加する（３１５）。このときパラメータの値の取捨選択のルールは以下のとおりとする。各カテゴリーにおいて、そのCategoryに属すると判断された最大値、及び最小値のみをListに残す。（すなわち、最終的に同一のソースコードを活性化させるパラメータの値の内、他のソースコードを活性化させるパラメータとの境界値のみが、Parameter List 2に残る事になる。）ここで、Category Aに「１と４」が登録された事により、これらの値の間にある「２と３」はCategory Aに属するという事が予測できる。このためパラメータの値「２と３」はParameter List １から削除する事ができる（３１７）。このことにより冗長なパラメータの値を使用したシミュレーションを削減する事ができ、Parameter List ２を作成する期間を短縮する事ができる。
【００１６】
これらの値「２，３」を削除し、再びParameter List 1にパラメータが存在するため（３２０）、Parameter List 1から無作為に値を選択し（３０１）、今度はパラメータの値「６」が選択された場合のParameter List １の様子が図2のリスト２０４に示されている。再度ステップ３０２、３０３を実施し、出力されたソースコードカバレッジ結果を前回までのカバレッジ結果と比較する（３０４）。新たな変化点が無い（３１０）ため既に定義されたCategoryに属すると判断される（３１２）。ソースコードカバレッジ結果より、Category Aに属すると判断し、Category Aに登録済みのパラメータの値「１、４」と比較する（３１３）。パラメータの値「６」はCategory Aの値の中で最大値となる（３１４）ので、Parameter List ２のCategory Aにパラメータの値「６」を追加する（３１５）。このときParameter List 2のCategory Aに既に登録された値「４」は、Category Aの中の最大値ではなくなる。このため、値「４」をParameter List Aから削除する（３１６）。この時のParameter List 2の様子が図2の２１４に示されている。さらにCategory Aに値「６」が新たに登録された事により、この値と削除された値「４」の間にある値「５」はCategory Aに属するという事が予測できる。このためパラメータの値「５」はParameter List １から削除する事ができる（３１７）。
【００１７】
以上の様に、Parameter List １から無作為に値を選択し、その値を用いてReference Modelでシミュレーションを行い、ソースコードカバレッジ結果からパラメータの値をカテゴライズするという行為をParameter List １がなくなるまで行う（図2。Parameter List 1の２０６）。この結果得られたParameter List ２は例えば図2のParameter List 2の２１６の様になる。この例では当初パラメータの数が３２個あったのに対して、6個まで減らす事ができている。RTLデザインに対しての論理検証はこの6個のパラメータのみを使用して行う（３２１）のみで、機能検証の面からは十分であり、論理検証の信頼性を確保しつつ大幅な論理検証期間の短縮を図ることができる。
【００１８】
この例では1つのパラメータについてのみ説明したが、1つのテストについて複数のパラメータを網羅する必要があるものもある。この場合も同様に1つずつのパラメータについて、前記のようにパラメータの値の絞込みを行い、絞り込まれたパラメータについてのみRTLデザインに対してテストを行えばよい。パラメータが削減されるため、パラメータ同士の組み合わせ（Combination）検証についてもより短期間で網羅しやすくなり、より検証の確実性を上げる事ができる。
【図面の簡単な説明】
【００１９】
【図１】本発明の論理検証システムの一実施例の構成図。
【図２】本発明の実施例におけるParameter Listの変化の様子を図示したもの。
【図３】本発明の論理検証方法の一実施例を示すシーケンス図。
【図１】
2007026183.tif 000003
【図２】
2007026183.tif 000004
【図３】
2007026183.tif 000005