(57)【要約】【課題】本発明は、システムＬＳＩ検証装置において、シミュレーションによってどの検証項目が実際にテストされたかを機械的に、かつ、確実に確認できるようにすることを最も主要な特徴とする。【解決手段】たとえば、テストプログラム２３を命令レベル・シミュレータ２５により検証した結果と、動作仕様に関する検証項目１１をイベントで表現したイベント情報にもとづいて、ＨＤＬ１３を検証した機能シミュレータ１７の結果とを機能チェッカー２９により比較する。その結果が一致する場合には、カバレッジチェッカー３１によって、機能シミュレータ１７の検証結果にもとづくイベント情報をもとに、検証項目１１が満たされたかどうかをチェックする構成となっている。【選択図】　　図１
2004086838.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも、マイクロプロセッサーを備えるシステムの検証装置において、
前記システムに対するテストプログラムを検証する第１のシミュレータと、
前記システムの動作仕様に関する検証項目をイベントで表現した第１のイベント情報にもとづいて、前記システムの機能を検証する第２のシミュレータと、
前記第２のシミュレータによる検証結果と、前記第１のシミュレータによる検証結果とを比較する比較手段と、
前記比較手段によって、前記第１のシミュレータによる検証結果と前記第２のシミュレータによる検証結果との一致が確認された場合に、前記第２のシミュレータによる検証結果にもとづく第２のイベント情報と前記第１のイベント情報とをもとに、前記検証項目が満たされたかどうかをチェックするチェック手段と
を具備したことを特徴とするシステムの検証装置。
【請求項２】
前記テストプログラムは、乱数を用いて作成されたランダムテストプログラムであることを特徴とする請求項１に記載のシステムの検証装置。
【請求項３】
前記第１のイベント情報は、イベントの順序や、過去と将来のイベントを参照するためのタイムバウンドシーケンスや条件など、本システムの動作仕様に対するイベントに関する情報を記述したアノテーションデータであることを特徴とする請求項１に記載のシステムの検証装置。
【請求項４】
前記チェック手段は、前記検証項目の洗い出しや前記システムのカバレッジの調査などを行うものであることを特徴とする請求項１に記載のシステムの検証装置。
【請求項５】
前記第１のイベント情報を格納するための第１のデータベース、前記第１のシミュレータによる検証結果を格納するための第２のデータベース、前記第２のシミュレータによる検証結果を格納するための第３のデータベース、前記第２のイベント情報を格納するための第４のデータベース、および、前記チェック手段によるチェック結果を格納するための第５のデータベースを、さらに備えることを特徴とする請求項１に記載のシステムの検証装置。
【請求項６】
少なくとも、マイクロプロセッサーを備えるシステムの検証方法において、
第１のシミュレータによって、前記システムに対するテストプログラムを検証する工程と、
前記システムの動作仕様に関する検証項目をイベントで表現した第１のイベント情報にもとづいて、第２のシミュレータにより、前記システムの機能を検証する工程と、
比較手段によって、前記第２のシミュレータによる検証結果と、前記第１のシミュレータによる検証結果とを比較する工程と、
前記比較手段によって、前記第１のシミュレータによる検証結果と前記第２のシミュレータによる検証結果との一致が確認された場合に、チェック手段により、前記第２のシミュレータによる検証結果にもとづく第２のイベント情報と前記第１のイベント情報とをもとに、前記検証項目が満たされたかどうかをチェックする工程と
を備えたことを特徴とするシステムの検証方法。
【請求項７】
前記テストプログラムはランダムテストプログラムであり、乱数を用いて作成されることを特徴とする請求項６に記載のシステムの検証方法。
【請求項８】
前記第１のイベント情報は、イベントの順序や、過去と将来のイベントを参照するためのタイムバウンドシーケンスや条件など、本システムの動作仕様に対するイベントに関する情報を記述したアノテーションデータであることを特徴とする請求項６に記載のシステムの検証方法。
【請求項９】
前記検証項目が満たされたかどうかをチェックする工程は、前記検証項目の洗い出しや前記システムのカバレッジの調査などを行うものであることを特徴とする請求項６に記載のシステムの検証方法。
【請求項１０】
前記第１のイベント情報を第１のデータベースに記憶する工程、前記第１のシミュレータによる検証結果を第２のデータベースに記憶する工程、前記第２のシミュレータによる検証結果を第３のデータベースに記憶する工程、前記第２のイベント情報を第４のデータベースに記憶する工程、および、前記チェック手段によるチェック結果を第５のデータベースに記憶する工程を、さらに備えることを特徴とする請求項６に記載のシステムの検証方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、システムの検証装置および検証方法に関するもので、特に、マイクロプロセッサーやメモリなどを備えるシステムＬＳＩ（半導体集積回路）検証装置に関する。
【０００２】
【従来の技術】
近年、システムの複雑化に伴い、ＬＳＩは高集積化、大規模化されている。このため、開発期間全体の７０％を占めるといわれる程、その検証作業には莫大なコストが必要となっている。とりわけ、検証のボトルネックとなる要因の一つがテストプログラムの作成である。
【０００３】
図６に、真のデータ依存関係を検証する、すなわち、任意の命令が先行命令ｄｉｖにより生成された実行結果を用いる場合、先行命令ｄｉｖが実行結果を生成するまでは後続の命令の実行を遅らせる必要があることを検証するためのアルゴリズムの一例を示してある。図７に、ＭＩＰＳ（Ｒ）ライクのアセンブラでインプリメントしたテストプログラムの一例を示す。我々は、通常、このようなテストプログラムをマニュアルで作成している。
【０００４】
このように、マニュアルで作成されたテストプログラムは機能を検証するためには大変効果的である。マイクロプロセッサーの複雑度が増加するにつれて、作成しなければならないテストシナリオは増大し、検証作業のボトルネックとなっている。
【０００５】
この問題を解決するための１つの解は、ランダムテストを用いることである。ランダムテストは小さなシーメンスをランダムに並べることによって、テストシーケンスを作成する。そして、デザインと機能モデルとの結果を比較することによって、機能性をチェックする。
【０００６】
ランダムに並べられたテストシーケンスは、システムの機能性と信頼性とを徹底的に検証するのには極めて効果的である。時には、検証エンジニアがプログラミングに時間を費やさずには考えられないような、非常に難しく、複雑なテストシナリオが作成できることもある。
【０００７】
しかしながら、テストシナリオはランダムシーケンスによって何がカバーされているのか分からない。そのため、メインの検証作業にはなりえなかった。したがって、図７に示したようなテストプログラムをマニュアルで作成しなければならなかった。通常、システムＬＳＩの開発においては、数十万から数百万もの、このようなテストプログラムを作成する必要がある。
【０００８】
これに対し、設計した論理回路がイベントの前後に成立している条件や常に満たされている条件などが、システムの動作仕様を満たしているかどうかを検証するための検証ツールとして、アサーション・ベースの検証ツール（以下、単にアサーションと略記する）が注目されている。このアサーションを利用すると、ＨＤＬ（ハードウエア記述言語）でコーディングされるテストプログラムよりも記述量が少なくて済み、内容も理解しやすい。また、デザインバグを示す可能性があるプログラムのチェックが容易である上に、ランダムテストを行う場合に比べ、設計全体の可観測性とデザイン動作の可視性とが改善する。このような理由から、アサーションを用いた検証方法が注目されつつある。
【０００９】
【発明が解決しようとする課題】
しかしながら、アサーションは、そもそも、禁止動作条件を記述するための言語であり、一般に、バグの検出効率の改善やデバッグ効率を大幅に改善できるものの、依然、テストプログラムを作成する作業は必要である。したがって、検証作業のうち、最もコストのかかるテストプログラムの作成作業を十分に軽減することはできなかった。
【００１０】
システムの機能検証はＬＳＩの開発と並行して進められ、ソフトウェア開発を行うために作成された命令レベル・シミュレータ（命令セットに関するシミュレータ）を用いることで、期待値データの設定については自動化が可能である。また、命令をランダムに発生するプログラムを用いることで、バグの８０％以上は検証できることから、従来のランダムテストを有効に活用したい。しかしながら、ランダムテストによる検証では、どの検証項目が検証されたかという判別は困難である。
【００１１】
そこで、この発明は、テストプログラムの作成にかかる作業を軽減できるとともに、シミュレーションによってどの検証項目が検証されたかを機械的に、かつ、確実に確認することが可能なシステムの検証装置および検証方法を提供することを目的としている。
【００１２】
【課題を解決するための手段】
上記の目的を達成するために、この発明のシステムの検証装置にあっては、少なくとも、マイクロプロセッサーを備えるものにおいて、前記システムに対するテストプログラムを検証する第１のシミュレータと、前記システムの動作仕様に関する検証項目をイベントで表現した第１のイベント情報にもとづいて、前記システムの機能を検証する第２のシミュレータと、前記第２のシミュレータによる検証結果と、前記第１のシミュレータによる検証結果とを比較する比較手段と、前記比較手段によって、前記第１のシミュレータによる検証結果と前記第２のシミュレータによる検証結果との一致が確認された場合に、前記第２のシミュレータによる検証結果にもとづく第２のイベント情報と前記第１のイベント情報とをもとに、前記検証項目が満たされたかどうかをチェックするチェック手段とを具備したことを特徴とする。
【００１３】
また、この発明のシステムの検証方法にあっては、少なくとも、マイクロプロセッサーを備える場合において、第１のシミュレータによって、前記システムに対するテストプログラムを検証する工程と、前記システムの動作仕様に関する検証項目をイベントで表現した第１のイベント情報にもとづいて、第２のシミュレータにより、前記システムの機能を検証する工程と、比較手段によって、前記第２のシミュレータによる検証結果と、前記第１のシミュレータによる検証結果とを比較する工程と、前記比較手段によって、前記第１のシミュレータによる検証結果と前記第２のシミュレータによる検証結果との一致が確認された場合に、チェック手段により、前記第２のシミュレータによる検証結果にもとづく第２のイベント情報と前記第１のイベント情報とをもとに、前記検証項目が満たされたかどうかをチェックする工程とを備えたことを特徴とする。
【００１４】
この発明のシステムの検証装置および検証方法によれば、システムで起こり得るイベント情報と、テストプログラムによるシミュレーションの結果とを照らし合わせることで、検証項目の可視性および検証能力を定量化できるようにしている。これにより、どの検証項目が検証されたかを容易に確認できるようになるだけでなく、検証のためのテストプログラムの作成コストをも軽減することが可能となるものである。
【００１５】
また、システムの動作仕様（機能記述）の変更によって意味がなくなった検証項目や修正を必要とする検証項目を容易に検出すること、さらには、機能記述が再利用された場合においても、テストされた検証項目を明確にすることが可能となるものである。
【００１６】
【発明の実施の形態】
以下、この発明の実施の形態について図面を参照して説明する。
【００１７】
図１は、本発明の一実施形態にかかるシステムＬＳＩ検証装置の構成例を示すものである。
【００１８】
図１において、検証項目１１は、システムＬＳＩ機能記述により記述されたＨＤＬ１３によって表されるイベントの順序や、過去と将来のイベントを参照するためのタイムバウンドシーケンスや条件など、本システムＬＳＩの動作仕様に対するイベントに関する情報である。
【００１９】
アノテーションデータベース（第１のデータベース）１５は、上記検証項目１１から抽出されたイベントより命令などに関する信号を取り出して、テスト項目が重なってないかなどの最適化を施した情報（第１のイベント情報）を格納するものである。このアノテーションデータベース１５は、たとえば、任意の情報を時系列で保持したまま格納するようになっている。
【００２０】
機能シミュレータ（第２のシミュレータ）１７は、テストプログラム２３を用いてすべてのデザインレベルのＨＤＬ１３をシミュレーションするものである。
【００２１】
機能検証結果データベース（第３のデータベース）１９は、上記機能シミュレータ１７での検証結果を格納するものである。
【００２２】
イベントデータベース（第４のデータベース）２１は、上記機能シミュレータ１７での検証結果より生じるイベント情報（第２のイベント情報）を格納するものである。
【００２３】
テストプログラム２３は、命令列をランダムに発生するようなソフトウェアプログラムから生成されたテストプログラムである。
【００２４】
命令レベル・シミュレータ（第１のシミュレータ）２５は、システムＬＳＩにおけるターゲットとなるアーキテクチャを、上記機能シミュレータ１７と同様に、上記テストプログラム２３を用いて検証を行うものである。
【００２５】
シミュレーション結果データベース（第２のデータベース）２７は、上記テストプログラム２３を上記命令レベル・シミュレータ２５によって検証した結果を格納するものである。
【００２６】
機能チェッカー（比較手段）２９は、上記機能検証結果データベース１９に格納された検証結果と、上記シミュレーション結果データベース２７に格納された検証結果とを比較し、両者が一致するかどうかを確認するものである。たとえば、機能チェッカー２９は、プログラムカウンタの値とレジスタの値とを比較する。
【００２７】
カバレッジチェッカー（チェック手段）３１は、上記イベントデータベース２１内のイベント情報を、上記アノテーションデータベース１５内のイベント情報と照らし合わせ、本検証で確認されたテスト項目の洗い出しやシステムＬＳＩのカバレッジの調査などを行うものである。
【００２８】
カバレッジデータベース（第５のデータベース）３３は、上記カバレッジチェッカー３１によるチェック結果を格納するものである。
【００２９】
このように、カバレッジチェッカー３１を用いれば、たとえランダムテストプログラムによって行われたテストであっても、どのような検証項目１１を検証できたかが自動的に解析できる。さらに、意図しなかったテスト項目により偶然検証できた他の検証項目１１も確認できるので、大変有益である。勿論、アノテーションデータベース１５の内容とイベントデータベース２１の内容とを比較することにより、検証されていないテスト項目についても容易に理解することが可能である。さらには、的を射ていない（不要な）テストプログラムか否かということもわかり、無駄な検証を行わなくても済むようになる。
【００３０】
次に、図２（ａ），（ｂ）に示すフローチャートを用いて、検証方法にかかる処理の流れについて具体的に説明する。
【００３１】
ここでは、たとえば図３に示すように、プロセッサー（Ｐｒｏｃｅｓｓｏｒ）４１、メモリ（Ｍｅｍｏｒｙ）４２、ブリッジ回路（ｂｒｉｄｇｅ）４３、および、入出力インターフェイス（Ｉ／Ｏ）４４，４５，４６を備えるシステムＬＳＩにおいて、便宜上、テストプログラムはＭＩＰＳ（Ｒ）ライクなアセンブラとし、かつ、上記プロセッサー４１が４段のパイプライン（命令フェッチ（ステージＦ）、デコード（ステージＤ）、命令実行（ステージＸｎ，ステージＥ）、書き込み（ステージＷ））構造を有して構成されていると仮定する。後掲する表１に、このシステムＬＳＩの各パイプラインステージで何が起きたかを示している。
【００３２】
【表１】
2004086838.tif 000003
【００３３】
また、本システムＬＳＩ中のプロセッサー４１は、除算器がコ・プロセッサとして、プロセッサー本体と切り離されており、たとえば図４（ａ）に示すように、除算（ＤＩＶ）命令の実行（ステージＥ）が他の命令のように１サイクルでは終了せず、ステージＸ１，ステージＸ２，ステージＸ３，ステージＸ４の４サイクルを必要とし、その後、書き込み（ステージＷ）が起こるものとする。
【００３４】
除算命令が他の算術演算よりも時間がかかることは非常に一般的であり、仮に後続の命令が先に実行された除算命令の結果を利用するにしても、除算命令が終了し、正しい結果が得られるまで、後続の命令は待たなければならない。
【００３５】
このＤＩＶ命令の演算結果を、たとえば後続の加算（ＡＤＤ）命令が使用する場合、先に述べたように、ＤＩＶ命令のステージＷが実行されるまで、後続のＡＤＤ命令をステージＷで待機（ストール）させる必要がある（図４（ｂ）参照）。すなわち、このような動作仕様、つまり、「ＤＩＶ命令が実行され、ステージＸ１〜ステージＸ４の間、依存関係があるＡＤＤ命令はステージＥでストールする」というテスト項目が、図１に示した検証項目１１の一つとして洗い出される。
【００３６】
そこで、本実施形態においては、まず、このような検証項目１１からアノテーションを作成する（ステップＳＴ１００）。たとえば、図３のシステムＬＳＩにおけるクロック信号をｃｌｋ、レジスタｒ３１へのアクセス信号をａｃｃｅｓｓ＿ｒ３１、レジスタｒ３１へのアクセス要求信号をｒｅｑ＿ｒ３１、ＤＩＶ命令に対するストール信号をｓｔａｌｌ＿ｅ、ＤＩＶ命令の実行状況を観測する信号をｃｈｅｃｋ＿ｄｉｖとし、イベント情報の記述にＯＶＬを使用した場合、図５に示すようなイベント情報が自動的に生成されて、アノテーションデータベース１５に格納される。
【００３７】
このようなイベント情報は、マニュアルで作成しなければなかった従来のテストプログラム（図７参照）に比して、記述量が少なくて済み、内容も理解しやすい。
【００３８】
次に、シミュレーションを実施する（ステップＳＴ２００）。たとえば、計算機上でコンパイルしたテストプログラム２３を、命令レベル・シミュレータ２５によって検証し、その結果をシミュレーション結果データベース２７に格納する（ステップＳＴ２０１）。
【００３９】
また、アノテーションデータベース１５に格納されているイベント情報にもとづいて、機能シミュレータ１７によってＨＤＬ１３をシミュレーションし、その結果を機能検証結果データベース１９に格納する。さらに、その機能検証によって生じたイベント情報を、イベントデータベース２１に格納する（ステップＳＴ２０２）。
【００４０】
このシミュレーションによる検証を行った後に、機能チェッカー２９により、機能検証結果データベース１９に格納されたシミュレーション結果と、シミュレーション結果データベース２７に格納されたシミュレーション結果とを比較する（ステップＳＴ２０３）。
【００４１】
もし、シミュレーション結果が一致するのであれば（ステップＳＴ３００）、カバレッジチェッカー３１により、イベントデータベース２１に格納された第２のイベント情報をアノテーションデータベース１５内の第１のイベント情報と照らし合わせ、それ以外で確認されたテスト項目、たとえば、どの命令がどのくらい実行されたかなどの検証項目１１の洗い出しなどを行う（ステップＳＴ４００）。
【００４２】
その後、確認された検証項目１１をカバレッジデータベース３３に格納し（ステップＳＴ５００）、一連の処理を終了する。
【００４３】
上記したように、システムＬＳＩで起こり得るイベント情報と、テストプログラムによるシミュレーションの結果とを照らし合わせることにより、検証項目の可視性および検証能力を定量化できるようになる。すなわち、シミュレーションの結果によって、設計者が設定した検証項目が実際にテストされたかどうかを機械的に、かつ、確実に確認できるようにしている。これにより、どの検証項目が検証されたかを容易に確認できるとともに、検証のためのテストプログラムの作成コストをも軽減することが可能となるものである。
【００４４】
また、設計対象ＬＳＩの機能記述を変更した場合に、意味がなくなってしまったテストプログラムや修正する必要があるテストプログラムを容易に検出することも可能となる。さらには、機能記述が再利用された場合において、テストされた項目、すなわち使用された機能や動作を明確にすることが可能となる。
【００４５】
なお、上述の実施形態においては、機能検証結果データベースやシミュレーション結果データベースを設けるようにした場合について説明した。これに限らず、たとえば機能チェッカーをリアルタイムで実行する場合には、それらを省略することもできる。
【００４６】
また、上記イベント情報（図５参照）に関して、たとえば、
ａｓｓｅｒｔ＿ｔｉｍｅ　＃（０，３，０）　ｒｅｑ＿ａｃｃｅｓｓ＿ｔｅｓｔ（／＊　ｓｙｓｔｅｍ＿ｃｌｏｃｋ＿ｎａｍｅ　＊／、／＊　ｒｅｓｅｔ　ｓｉｇｎａｌ　ｎａｍｅ　＊／、／＊　ｓｔａｌｌ＿ｓｉｇｎａｌ＿ｎａｍｅ　＊／＝＝１、
（（／＊　ａｃｃｅｓｓ＿ｒｅｇｉｓｔｅｒ＿ｎａｍｅ　＊／＝＝１）　＆＆　（／＊　ｒｅｑｕｅｓｔ＿ｓｉｇｎａｌ＿ｎａｍｅ　＊／＝＝１）　＆＆　（／＊　ｃｈｅｃｋ＿ｓｉｇｎａｌ＿ｎａｍｅ　＊／＝＝１）、
（（／＊　ａｃｃｅｓｓ＿ｒｅｇｉｓｔｅｒ＿ｎａｍｅ　＊／＝＝１）　＆＆　（／＊　ｒｅｑｕｅｓｔ＿ｓｉｇｎａｌ＿ｎａｍｅ　＊／＝＝０）　＆＆　（／＊　ｃｈｅｃｋ＿ｓｉｇｎａｌ＿ｎａｍｅ　＊／＝＝０））；
のように、／＊　＊／で囲まれている部分については、テストプログラムと動作仕様とから対応する信号が自動的に埋められるようなテンプレート、および、「‘ｄｅｆｉｎｅ　ｃｌｋ　ｓｙｓｔｅｍ＿ｃｌｏｃｋ＿ｎａｍｅ　」などの信号リストがあれば、それを自動的に作成することも可能である。
【００４７】
さらには、マイクロプロセッサーやメモリなどを備えるシステムＬＳＩに限らず、たとえば、このような構成のシステムＬＳＩを備える各種のシステムにも同様に適用できる。
【００４８】
その他、本発明は、上記（各）実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。さらに、上記（各）実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適宜な組み合わせにより種々の発明が抽出され得る。たとえば、（各）実施形態に示される全構成要件からいくつかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題（の少なくとも一つ）が解決でき、発明の効果の欄で述べられている効果（の少なくとも一つ）が得られる場合には、その構成要件が削除された構成が発明として抽出され得る。
【００４９】
【発明の効果】
以上、詳述したようにこの発明によれば、テストプログラムの作成にかかる作業を軽減できるとともに、シミュレーションによってどの検証項目が検証されたかを機械的に、かつ、確実に確認することが可能なシステムの検証装置および検証方法を提供できる。
【図面の簡単な説明】
【図１】本発明の一実施形態にかかるシステムＬＳＩ検証装置の基本構成を示すブロック図。
【図２】図１のシステムＬＳＩ検証装置において、検証方法にかかる処理の流れを説明するために示すフローチャート。
【図３】本発明にかかるシステムＬＳＩの構成例を示すブロック図。
【図４】図３のシステムＬＳＩにおけるテストプログラムの命令パイプライン処理を示す概念図。
【図５】図１のシステムＬＳＩ検証装置のアノテーションデータベースに格納されるイベント情報の一例を示す図。
【図６】任意の命令が先行命令ｄｉｖにより生成された実行結果を用いる場合、先行命令ｄｉｖが実行結果を生成するまでは後続の命令の実行を遅らせる必要があることを検証するためのアルゴリズムの一例を示すフローチャート。
【図７】図６のフローチャートに対応するテストプログラムを、ＭＩＰＳ（Ｒ）６４の命令セットを用いて作成した場合を例に示す図。
【符号の説明】
１１…検証項目
１３…ＨＤＬ
１５…アノテーションデータベース
１７…機能シミュレータ
１９…機能検証結果データベース
２１…イベントデータベース
２３…テストプログラム
２５…命令レベル・シミュレータ
２７…シミュレーション結果データベース
２９…機能チェッカー
３１…カバレッジチェッカー
３３…カバレッジデータベース
４１…プロセッサー
４２…メモリ
４３…ブリッジ回路
４４，４５，４６…入出力インターフェイス
Ｆ…命令フェッチ
Ｄ…デコード
Ｅ，Ｘｎ…命令実行
Ｗ…書き込み
ＤＩＶ…除算命令
ＡＤＤ…加算命令
【図１】
2004086838.tif 000004
【図２】
2004086838.tif 000005
【図３】
2004086838.tif 000006
【図４】
2004086838.tif 000007
【図５】
2004086838.tif 000008
【図６】
2004086838.tif 000009
【図７】
2004086838.tif 000010