(57)【特許請求の範囲】
【請求項１】
複数のブロック回路が直列に接続されている半導体集積回路を検証する半導体集積回路の検証装置であって、
各ブロック回路に対応するブロック回路のログ情報をそれぞれ独立に取得するモニタ手段と、
前記モニタ手段のログ情報をメモリ空間に記憶する記憶手段と、
前記直列に接続されている最後段のブロック回路からの出力データを期待値比較し、前記期待値比較の結果を前記各モニタ手段に伝える動作確認手段と、を有し、
前記各モニタ手段は、前記動作確認手段から伝えられた前記期待値比較の結果にエラーがない場合、次に新しく取得した前記各ブロック回路に対応するログ情報を前記メモリ空間に上書きして記憶させることを特徴とする半導体集積回路の検証装置。
【請求項２】
前記動作確認手段の動作環境を設定する設定手段を更に有し、
該設定手段は、前記動作確認手段が動作確認を行うためのデータサイズを設定し、
前記動作確認手段は、最後のブロック回路から設定されたデータサイズの出力データを得る毎に動作確認を行うことを特徴とする請求項１記載の半導体集積回路の検証装置。
【請求項３】
前記モニタ手段は、内部バスの転送最小サイズで情報共有し、対応するブロック回路のパフォーマンス情報としてデータ量と時間情報を、それぞれが使用する前記メモリ空間に保持することを特徴とする請求項１又は２記載の半導体集積回路の検証装置。
【請求項４】
検証された内容を確認する機能カバレッジを更に有し、
該機能カバレッジは、前記パフォーマンス情報を追加で検証することを特徴とする請求項３記載の半導体集積回路の検証装置。
【請求項５】
前記動作確認手段は、前記期待値比較の結果にエラーがある場合に、その旨を前記モニタ手段に伝え、
前記モニタ手段は、エラーがあった出力データに対応するログ情報について、エラー情報を付加して、前記メモリ空間に記憶させることを特徴とする請求項１から４のいずれか１項記載の半導体集積回路の検証装置。
【請求項６】
前記動作確認手段は、前記期待値比較の結果にエラーがある場合に、エラーが出た出力データがデータ配列における何番目の要素であるかを示す配列情報を前記モニタ手段に伝え、
前記モニタ手段は、エラーがあった出力データに対応するログ情報について、前記配列情報を付加して、前記メモリ空間に記憶させることを特徴とする請求項５項記載の半導体集積回路の検証装置。
【請求項７】
複数のブロック回路が直列に接続している半導体集積回路を検証する半導体集積回路の検証装置による半導体集積回路の検証方法であって、
前記半導体集積回路の検証装置は、複数のモニタ手段と、記憶手段と、動作確認手段とを有し、
前記モニタ手段が、各ブロック回路に対応するブロック回路のログ情報をそれぞれ独立に取得するモニタ工程と、
前記記憶手段が、前記モニタ工程毎に専用のメモリ空間に前記モニタ工程のログ情報を記憶する工程と、
前記動作確認手段が、前記直列に接続されている最後段のブロック回路からの出力データを期待値比較し、前記期待値比較の結果を前記モニタ手段に伝える動作確認工程と、
前記各モニタ手段が、前記動作確認手段から伝えられた前記期待値比較の結果にエラーがない場合、次に新しく取得した前記各ブロック回路に対応するログ情報を前記メモリ空間に上書きして記憶させる工程と、
を有することを特徴とする半導体集積回路の検証方法。
【請求項８】
直列に接続している複数のブロック回路を検証するためのプログラムであって、
複数のモニタ手段と、記憶手段と、動作確認手段とを有する半導体集積回路に、
前記モニタ手段が、各ブロック回路に対応するブロック回路のログ情報をそれぞれ独立に取得するモニタ工程と、
前記記憶手段が、前記モニタ工程毎に専用のメモリ空間に前記モニタ工程のログ情報を記憶する工程と、
前記動作確認手段が、前記直列に接続されている最後段のブロック回路からの出力データを期待値比較し、前記期待値比較の結果を前記モニタ手段に伝える動作確認工程と、
前記各モニタ手段が、前記動作確認手段から伝えられた前記期待値比較の結果にエラーがない場合、次に新しく取得した前記各ブロック回路に対応するログ情報を前記メモリ空間に上書きして記憶させる工程と、
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、半導体集積回路の検証装置、方法及びプログラムに関し、特に、半導体集積回路の検証技術に関する。
【背景技術】
【０００２】
近年、大規模集積回路（以下、ＬＳＩ（Ｌａｒｇｅ  Ｓｃａｌｅ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）と略記する）は、動作速度は高速化し、微細加工技術の向上により多くの機能が１つのＬＳＩに集積される方向にある。そのため、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｅｄ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）を検証するテストベンチの技術向上、精度向上、生産性向上などは、重要な課題となっている。
【０００３】
本発明に関連する技術としては、例えば、特許文献１，２に記載の技術がある。特許文献１に記載の技術は、テストデータと結果データを格納する記憶部が異なり、解析の際に結果データの情報を利用するものである。また、特許文献２に記載の技術は、上述のようなＡＳＩＣを検証するテストベンチの生産性や再利用性を向上させるという目的で、検証対象のＡＳＩＣにテスト動作を実行させるための指示を出すソフトウェア化されたテストシナリオや、ソフトウェア化されたバスモデルを含む発明を提供するものである。
【特許文献１】特開２００４−３６１１７１号公報
【特許文献２】特開２００５−０９３９２９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ＬＳＩの回路構成が複数の機能ブロックでシリアルに接続されている場合、テストベンチで内部バスにモニタモデルを接続し、各機能ブロックの出力をチェックしながらシミュレーションを行い解析を容易にすることは広く知られている。
【０００５】
このとき、シリアル接続されている機能ブロックが、数十段で構成されている場合、各機能ブロックの出力にモニタモデルの機能をつけシミュレーションを実施すると、数十のモニタモデルが同時に演算処理をし、シミュレーション速度が大幅に遅くなり生産性が劣化してしまう。
【０００６】
また、各内部バスのモニタモデルの期待値比較の機能をＯＦＦし、データをＬＯＧデータとして保存しながらシミュレーション速度の劣化を抑え、解析用のデータとして残す方法もある。しかし、単純に数十あるモニタ情報を保存すると、ＡＳＩＣ検証環境に用意されているシステムメモリがオーバーフローしてしまい、すぐに破綻してしまう。
【０００７】
また、システム環境で許されたメモリ容量を分割し、各モニタに割り振った場合、エラーが発生し解析を行うと、エラーとは関係しないＬＯＧ情報も大量に含まれており、各ブロックの機能の組み合わせで、最終出力から遡り各ブロックの出力と対応するデータを割り出すには、多くの解析時間が必要になり、エラー個所を特定するのに大量の時間を必要としてしまい生産性の劣化に繋がっている。
【０００８】
そこで本発明は、上記実情に鑑みて、各モニタがエラー発生時近辺のデータのみを保持することを目的とする。
【課題を解決するための手段】
【０００９】
上記目的を達成するための本発明の第１の態様は、複数のブロック回路が直列に接続されている半導体集積回路を検証する半導体集積回路の検証装置であって、各ブロック回路に対応するブロック回路のログ情報をそれぞれ独立に取得するモニタ手段と、前記モニタ手段のログ情報をメモリ空間に記憶する記憶手段と、前記直列に接続されている最後段のブロック回路からの出力データを期待値比較し、前記期待値比較の結果を前記各モニタ手段に伝える動作確認手段と、を有し、前記各モニタ手段は、前記動作確認手段から伝えられた前記期待値比較の結果にエラーがない場合、次に新しく取得した前記各ブロック回路に対応するログ情報を前記メモリ空間に上書きして記憶させることを特徴とする半導体集積回路の検証装置である。
【００１０】
また、第２の態様は、複数のブロック回路が直列に接続している半導体集積回路を検証する半導体集積回路の検証装置による半導体集積回路の検証方法であって、前記半導体集積回路の検証装置は、複数のモニタ手段と、記憶手段と、動作確認手段とを有し、前記モニタ手段が、各ブロック回路に対応するブロック回路のログ情報をそれぞれ独立に取得するモニタ工程と、前記記憶手段が、前記モニタ工程毎に専用のメモリ空間に前記モニタ工程のログ情報を記憶する工程と、前記動作確認手段が、前記直列に接続されている最後段のブロック回路からの出力データを期待値比較し、前記期待値比較の結果を前記モニタ手段に伝える動作確認工程と、前記各モニタ手段が、前記動作確認手段から伝えられた前記期待値比較の結果にエラーがない場合、次に新しく取得した前記各ブロック回路に対応するログ情報を前記メモリ空間に上書きして記憶させる工程と、を有することを特徴とする半導体集積回路の検証方法である。
【００１１】
また、第３の態様は、直列に接続している複数のブロック回路を検証するためのプログラムであって、複数のモニタ手段と、記憶手段と、動作確認手段とを有する半導体集積回路に、前記モニタ手段が、各ブロック回路に対応するブロック回路のログ情報をそれぞれ独立に取得するモニタ工程と、前記記憶手段が、前記モニタ工程毎に専用のメモリ空間に前記モニタ工程のログ情報を記憶する工程と、前記動作確認手段が、前記直列に接続されている最後段のブロック回路からの出力データを期待値比較し、前記期待値比較の結果を前記モニタ手段に伝える動作確認工程と、前記各モニタ手段が、前記動作確認手段から伝えられた前記期待値比較の結果にエラーがない場合、次に新しく取得した前記各ブロック回路に対応するログ情報を前記メモリ空間に上書きして記憶させる工程と、を実行させるためのプログラムである。
【発明の効果】
【００１２】
本発明によれば、各モニタがエラー発生時近辺のデータのみを保持することが可能となる。
【発明を実施するための最良の形態】
【００１３】
以下、本発明の好適な実施の形態について図面を参照して説明する。以下の実施形態においては、ブロック回路、Ｉ／Ｆ（インターフェース）、バスモデル、テストシナリオを示しているが数を限定するものではない。
【００１４】
本実施形態に係るテストベンチ１００は、コンピュータやワークステーション等のハードウェアと、そのハードウェアに組み込まれるソフトウェアとの協働によって、実現される。例えば、本実施形態は、テストベンチプログラム（ソフトウェア）として提供され、ハードウェアの一時記憶上に展開され、ハードウェアの制御装置によって処理実行されることによって実現することができる。
【００１５】
図１を参照すると、本実施形態に係るテストベンチ１００の構成が、テスト検証対象のＡＳＩＣ２００とともに示されている。ＡＳＩＣ２００は、ブロックＡ，Ｂ，Ｃ，Ｄ（以下、まとめて「ブロック２０１」ということもある）がシリアルに、つまり直列的に接続されている。
【００１６】
テストベンチ１００は、内部に、内部バスモニタＡ，Ｂ，Ｃ（以下、まとめて「内部バスモニタ１０１」ということもある）、ＣＰＵモデル１０３、入力Ｉ／Ｆ（インターフェース）バスモデル１０４、出力Ｉ／Ｆバスモデル１０５、を備える。ＣＰＵモデル１０３は、ＡＳＩＣ２００の設定や動作起動を行う制御装置をソフトウェア化したものである。内部バスモニタ１０１は、ブロック２０１の最後段のブロックを除く全てのブロックに対応して、対応するブロックの動作確認や期待値比較を行う。
【００１７】
入力Ｉ／Ｆバスモデル１０４と出力Ｉ／Ｆバスモデル１０５は、それぞれ、ＡＳＩＣ２００へデータ入力する入力Ｉ／Ｆバス、又は、ＡＳＩＣ２００からのデータ出力を受け取る出力Ｉ／Ｆバスをソフトウェア化したものである。また、出力Ｉ／Ｆバスモデル１０５は、ブロック２０１の最後段のブロック（図１においては、ブロックＤ２０１ｄ）の動作確認や期待値比較を行う機能も有する。
【００１８】
また、テストベンチ１００は、ソフトウェア化されたテストシナリオ１０２も有する。テストシナリオ１０２は、ＣＰＵモデル１０３に起動をかけ、ＣＰＵモデル１０３にＡＳＩＣ２００の設定や動作起動を実行させる。また、テストシナリオ１０２は、入力Ｉ／Ｆバスモデル１０４の動作設定や動作起動も行う。
【００１９】
以上で図１に示す各構成の働きを説明した。次に、テストベンチ１００が１回のテスト動作を行った場合に、これら各構成が、どのような働きをするのかという点について、説明する。
【００２０】
まず、テストシナリオ１０２が、ＣＰＵモデル１０３に起動をかけ、ＡＳＩＣ２００の設定や動作起動をさせる。また、テストシナリオ１０２は、入力Ｉ／Ｆバスモデル１０４の動作設定と動作起動も行う。
【００２１】
入力Ｉ／Ｆバスモデル１０４の動作起動が設定されると、入力Ｉ／Ｆバスモデル１０４は、ＡＳＩＣ２００に対して動作を開始し、ブロックＡ２０１ａにデータを入力する。入力されたデータは、ブロックＢ２０１ｂへと転送出力されると同時に、テストベンチ１００の内部バスモニタＡ１０１ａにも出力される。そして、内部バスモニタＡ１０１ａは、ブロックＡ２０１ａの出力データをモニタして動作確認や期待値比較を行う。
【００２２】
同様に、ブロックＢ２０１ｂとブロックＣ２０１ｃも、それぞれのブロックに対応するバスモニタが出力データをモニタする。しかし、ブロック２０１の中で、最後段に位置するブロックＤ２０１ｄは、その出力データを受け取る出力Ｉ／Ｆバスモデル１０５がバスモニタの機能を兼ねる。したがって、出力Ｉ／Ｆバスモデル１０５は、ブロックＤ２０１ｄからの出力をモニタし、出力データを期待値比較する。
【００２３】
更に、出力Ｉ／Ｆバスモデル１０５は、期待値比較の結果がＯＫになると、各内部バスモニタ１０１に、そのこと（これを以下、「期待値ＯＫ情報」という）を伝える。すると、各内部バスモニタ１０１は、期待値ＯＫ情報に対応するデータ出力が同時にＯＫ（エラーなし）であることがわかる。したがって、各内部バスモニタ１０１は、それぞれが対応するブロック２０１から出力データを受け取ったときに毎回期待値比較する必要がない。
【００２４】
しかしながら、出力Ｉ／Ｆバスモデル１０５の受け取った出力データの期待値比較の結果がＯＫでなかった場合に、検証対象のＡＳＩＣ２００のブロック２０１のうち、どの個所にエラーが発生したため結果がＯＫでなかったのかを知る必要がある。そこで、各内部バスモニタ１０１は、それぞれ別個にメモリ空間を備え、メモリ空間にモニタしているブロックからの出力データを一時的に保存し、検証に役立てる。以下、本実施形態の各内部バスモニタ１０１がメモリ空間に記憶させておくブロックからの出力データ等の、時間による状態遷移について説明し、本実施形態の特徴を述べる。
【００２５】
図２を参照すると、各内部バスモニタ１０１及び出力Ｉ／Ｆバスモデル１０５が得る出力データと時間との関係が示されている。
【００２６】
図２中、モニタＡデータは、内部バスモニタＡ１０１ａが、ブロックＡ２０１ａから得られる出力を、時間軸に沿って表している。Ａ−１から順次Ａ−２、Ａ−３・・・Ａ−７と出力データが時間ともに順次出力されている。これら出力データＡ−１ないしＡ−７は、内部バスモニタＡ１０１ａが使用するメモリ空間にＬＯＧ情報として保持していくが、図３を参照して後述するように、その全てを保持するわけではない。
【００２７】
また、モニタＡデータと同様に、モニタＢデータ、モニタＣデータは、内部バスモニタＢ１０１ｂ、内部バスモニタＣ１０１ｃから順次データ出力されている出力データである。図２における最下段に示されている「出力データ」は、ブロックＤ２０１ｄからの出力であって、出力Ｉ／Ｆバスモデル１０５で期待値比較されているデータである。
【００２８】
図２において、出力１の時間Ｔ１は、出力１の期待値比較がＯＫになった時間を表す。このとき内部バスモニタＡ１０１ａでは、Ａ−１、Ａ−２の出力は終了しており、Ａ−３の出力をメモリ空間上にＬＯＧとして保持している途中である。内部バスモニタＢ１０１ｂでは、Ｂ−３を、内部バスモニタＣ１０１ｃでは、Ｃ−２を、同様にＬＯＧとして保持している途中である。
【００２９】
図２において、Ｔ２、Ｔ３、Ｔ４は、同様に、出力２、３、４の期待値比較がＯＫになった時間を表し、破線矢印と重なっている所が、それぞれ各内部バスモニタ１０１で出力されているデータをＬＯＧとして保持している途中のデータである。
【００３０】
一方で、時間Ｔ１の時点で、出力１に対応するＡ−１、Ｂ−１、Ｃ−１のデータがＯＫである（エラーがない）ことが判明する。したがって、時間Ｔ１を過ぎた時点で、Ａ−１、Ｂ−１、Ｃ−１のデータは失われても構わない。そこで、本実施形態では、必要とするメモリサイズを最小に抑えるために、次のデータから、失われても構わないデータを記憶していたメモリ空間に、次のデータを上書きしていく構成を取る。以下、この構成について、図３を参照して更に詳しく説明する。
【００３１】
図３にメモリ空間にＯＫ状態になったデータに次のデータを上書きしていく流れを示す。モニタＡデータとモニタＢデータは、この例の場合同様になるため、モニタＡデータとモニタＣデータの流れを説明する。
【００３２】
図３中、時間Ｔ１の時点で、メモリ空間にはＡ−１、Ａ−２データとＡ−３の途中までのデータが保持されている。時間Ｔ１は、出力１に対して出力Ｉ／Ｆバスモデル１０５が期待値ＯＫ情報を各内部バスモニタ１０１に発した時間であるから、内部バスモニタＡ１０１ａは、時間Ｔ１の時点で、Ａ−１データがＯＫであることが判る。したがって、内部バスモニタＡ１０１ａの使用するメモリ空間におけるＡ−１が記憶されている空間（以下、「Ａ−１空間」という）は、上書き可能である。そこで、内部バスモニタＡ１０１ａは、次に、Ａ−３データを全て保持し終えると、Ａ−４データをＡ−１空間に上書きする。
【００３３】
同様に、内部バスモニタＡ１０１ａは、Ａ−４データを保持している途中である時間Ｔ２において、Ａ−２データがＯＫであることが判る。そこで、内部バスモニタＡ１０１ａは、Ａ−４データを保持し終えると、次にＡ−５データをＡ−２空間に上書きする。内部バスモニタＡ１０１ａは、時間Ｔ３、Ｔ４においても同様に、ＯＫのデータが判明したら、次のデータを保持する場合にＯＫのデータの上に、次のデータの上書きを繰り返す。
【００３４】
モニタＣデータの場合も同様である。内部バスモニタＣ１０１ｃは、時間Ｔ１の時点で、内部バスモニタＣ１０１ｃが使用するメモリ空間に、Ｃ−１データとＣ−２データの途中までを、保持している。内部バスモニタＣ１０１ｃは、時間Ｔ１において、Ｃ−１データがＯＫであることが判る。したがって、Ｃ−１空間は上書き可能である。そこで、内部バスモニタＣ１０１ｃは、次に、Ｃ−２データを全て保持し終えるとＣ−３データをＣ−１空間に上書きする。
【００３５】
同様に、内部バスモニタＣ１０１ｃは、Ｃ−３データを保持している途中である時間Ｔ２においてＣ−２データがＯＫであることが判る。そこで、内部バスモニタＣ１０１ｃは、Ｃ−３データを保持し終えるとＣ−４データをＣ−２空間に上書きする。また、時間Ｔ３、Ｔ４においても同様に、内部バスモニタＣ１０１ｃは、ＯＫのデータが判明したら、上書きを繰り返す。
【００３６】
これにより、自ブロック以降のブロックでどのような機能の組み合わせになっているか知らなくても、選ばれた機能組み合わせで、自ブロックから出力までの最短の転送量情報がわかり、出力でエラー発生時に、各ブロックで必要な最小のデータのみを保持することができる。つまり、各内部バスモニタは、エラー発生時近辺のデータのみを保持することができるようになる。その結果、解析時も順次関連データを割り出すのに時間が掛からない。したがって、本実施形態の構成と作用は、生産性向上に繋がる。
【００３７】
本実施形態は、更に、次のように構成するとよい。すなわち、テストシナリオ１０２は、出力Ｉ／Ｆバスモデル１０５が期待値ＯＫ情報を出すためのデータサイズを設定し、出力Ｉ／Ｆバスモデル１０５は、設定された出力データ量単位で、期待値ＯＫ情報を各内部バスモニタ１０１に送るよう構成する。つまり、テストシナリオ１０２は、出力Ｉ／Ｆバスモデル１０５の動作環境を設定する設定手段として機能する。これにより、機能に応じて解析しやすいデータサイズでデータを保持することができ、その結果として、解析時間を短縮することができ、また、生産性の向上が実現する。
【００３８】
本実施形態は、更に、次のように構成するとよい。すなわち、各内部バスモニタ１０１は、内部バスの転送最小サイズで情報共有し、そのブロックのパフォーマンス情報としてデータ量と時間情報を、それぞれが使用するメモリ空間に保持する。これにより、各ブロック２０１（ブロック回路）の組み合わせでのパフォーマンスを確認できるようになる。
【００３９】
本実施形態は、更に、次のように構成するとよい。すなわち、テストベンチ１００に、更に、検証された内容を確認する機能カバレッジを備えるよう構成し、その機能カバレッジが上記パフォーマンス情報を追加で検証する。これにより、より品質の高い検証ができるようになり品質向上させることができる。
【００４０】
本実施形態は、更に、次のように構成するとよい。すなわち、出力Ｉ／Ｆバスモデル１０５は、出力データの期待値比較の結果、エラーがある場合には（つまり、エラー発生時には）、期待値ＯＫ情報における場合と同じく、ＮＧ情報としてその旨を、各内部バスモニタ１０１に伝え、情報共有する。そして、各内部バスモニタ１０１は、ＬＯＧ情報にエラー情報を付加して、それぞれが使用するメモリ空間に保持する。これにより、解析を更に容易にすることができる。
【００４１】
本実施形態は、更に、次のように構成するとよい。すなわち、出力Ｉ／Ｆバスモデル１０５は、エラー発生時には、エラーが出た出力データがデータ配列における何番目の要素であるかを示す情報（以下、「配列情報」という）を各内部バスモニタ１０１に伝え、情報共有する。そして、各内部バスモニタ１０１は、ＬＯＧ情報に配列情報を付加して、それぞれが使用するメモリ空間に保持する。これにより、テストを行ったデータ配列における、エラーが発生した出力データの位置が判り、エラー条件を絞り込むための貴重な情報になる。
【００４２】
以上、本発明の好適な実施の形態について説明したが、本発明はこれに限定されるものではなく、要旨を逸脱しない範囲内で種々の変形実施が可能である。また、上記の構成は、いずれも組み合わせて実施することが可能である。
【図面の簡単な説明】
【００４３】
【図１】本発明の実施形態に係るテストベンチと検証対象のＡＳＩＣとを含む構成を示すブロック図である。
【図２】本発明の実施形態に係るテストベンチの各内部バスモニタが取得するデータと時間との関係について説明するための図である。
【図３】本発明の実施形態に係るテストベンチの各内部バスモニタがそれぞれ使用する各メモリ空間の状態遷移を説明するための図である。
【符号の説明】
【００４４】
１００    テストベンチ
１０１    内部バスモニタ
１０２    テストシナリオ
１０３    ＣＰＵモデル
１０４    入力Ｉ／Ｆバスモデル
１０５    出力Ｉ／Ｆバスモデル
２００    ＡＳＩＣ
２０１    ブロック（ブロック回路）
【図１】
0005251086.tif 000002
【図２】
0005251086.tif 000003
【図３】
0005251086.tif 000004