(57)【特許請求の範囲】
【請求項１】
検証対象であるＬＳＩを構成している複数の機能ブロックに関するＬＳＩ構成情報を格納している第１のデータベースと、上記複数の機能ブロックの機能を検証する試験条件を格納している第２のデータベースとが用意されており、テストケース生成ツールが上記第１のデータベースに格納されているＬＳＩ構成情報を参照して、所定のバスに接続されている複数の機能ブロックを探索し、上記テストケース生成ツールが上記第２のデータベースから上記複数の機能ブロックに対する試験条件を読み出して共通の試験条件をマージし、そのマージした共通の試験条件と上記機能ブロックに固有の試験条件とから上記ＬＳＩの機能を検証するテストケースを生成するテストケース生成方法。
【請求項２】
ＬＳＩを構成している複数の機能ブロックが、データ転送動作を開始するマスタ、転送されるデータが自己の動作条件に該当する場合に所定の動作を開始するスレーブ、または、上記マスタと上記スレーブを接続するバスの何れかに分類されており、第１のデータベースが上記マスタ、上記スレーブ及び上記バスに関するＬＳＩ構成情報を格納し、第２のデータベースが上記マスタ、上記スレーブ及び上記バスの試験条件を格納していることを特徴とする請求項１記載のテストケース生成方法。
【請求項３】
テストケース生成ツールは、機能ブロックに対する試験条件がバスの試験条件と共通していれば、その機能ブロックに対する試験条件を上記バスの試験条件とマージすることを特徴とする請求項１記載のテストケース生成方法。
【請求項４】
機能ブロックが複数のバスに接続されている場合、テストケース生成ツールが機能ブロックに対する試験条件をバスの試験条件とマージする前に、ブリッジ制御部が一方のバスの試験条件を他方のバスの試験条件に合わせて変換することを特徴とする請求項３記載のテストケース生成方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、計算機ＬＳＩの構成要素であるＬＳＩ（集積回路）の動作を確認するためのテストケースを生成するテストケース生成方法に関するものである。
【０００２】
【従来の技術】
ＬＳＩの機能検証方法の一つとして、ＬＳＩ内部のデータバス、制御バス、アドレスバス等のバスに、試験データを送信して試験を行うデータパス試験が行われている。このデータパス試験においては、バスを形成する信号線上のデータ、信号線上の信号の遷移方向、遷移するタイミング、及びバスを取り巻く機能ブロックの動作や状態に関する全体的パラメータを組み合わせることにより、試験条件を決定していた。
しかし、人間が考えてバスや機能ブロックの取り得るパラメータを組み合わせるため、試験条件の決定および管理には自ずから限界があった。
【０００３】
一方では、ＬＳＩの製造技術やマイクロプロセッサの品質の向上に伴い、より多くの機能ブロックをワンチップ化する傾向にあり、機能検証を行うには、非常に多くの機能ブロックに対して条件を設定し組み合わせることが必要となり、試験条件の規模が膨大となりつつある。
【０００４】
さらに、決定された試験条件を実現するための各機能ブロックの状態を設定してテストケースを作成することが困難である上、機能モデルの仕様変更が生じる毎に既製のテストケースの中から仕様変更の影響を受けるものを選別し、それぞれを修正していたため非常に多くの作業時間を必要とした。
【０００５】
また、作成したテストケースによって意図した試験条件が実現されているか否かを確かめるには、シミュレーションを実行した後、目視によって確認する必要もあった。
【０００６】
これらの問題を回避するため、従来のテストケース生成方法では、ＬＳＩを構成している機能ブロックを制御できる専用の回路を付加して、機能検証のためのテストケースを生成したり、機能ブロック単位に回路を分割して個別に試験を実施するようなテストケースを生成していた。
【０００７】
【発明が解決しようとする課題】
従来のテストケース生成方法は以上のように構成されているので、テストケースの作成に多くの時間と手間を掛ける必要があり、また、専用の回路を設置するための大きなスペースをＬＳＩに確保する必要があるとともに、実際の動作時の特性と異なる特性しか測定できない場合があり、特に、機能ブロック単位の試験では、ＬＳＩチップに外部から試験信号を入力することによる実装状態の試験を実行できないなどの課題があった。
【０００８】
この発明は、上記のような課題を解決するためになされたもので、専用の回路を設けることなく、高速かつ容易にテストケースを生成することができるテストケース生成方法を得ることを目的とする。
【０００９】
【課題を解決するための手段】
この発明に係るテストケース生成方法は、テストケース生成ツールが第１のデータベースに格納されているＬＳＩ構成情報を参照して、所定のバスに接続されている複数の機能ブロックを探索し、そのテストケース生成ツールが第２のデータベースから上記複数の機能ブロックに対する試験条件を読み出して共通の試験条件をマージし、そのマージした共通の試験条件と上記機能ブロックに固有の試験条件とからＬＳＩの機能を検証するテストケースを生成するようにしたものである。
【００１０】
この発明に係るテストケース生成方法は、ＬＳＩを構成している複数の機能ブロックが、データ転送動作を開始するマスタ、転送されるデータが自己の動作条件に該当する場合に所定の動作を開始するスレーブ、または、マスタとスレーブを接続するバスの何れかに分類されており、第１のデータベースがマスタ、スレーブ及びバスに関するＬＳＩ構成情報を格納し、第２のデータベースがマスタ、スレーブ及びバスの試験条件を格納するようにしたものである。
【００１１】
この発明に係るテストケース生成方法は、機能ブロックに対する試験条件がバスの試験条件と共通していれば、テストケース生成ツールがその機能ブロックに対する試験条件をバスの試験条件とマージするようにしたものである。
【００１２】
この発明に係るテストケース生成方法は、機能ブロックが複数のバスに接続されている場合、テストケース生成ツールが機能ブロックに対する試験条件をバスの試験条件とマージする前に、ブリッジ制御部が一方のバスの試験条件を他方のバスの試験条件に合わせて変換するようにしたものである。
【００３０】
【発明の実施の形態】
以下、この発明の実施の一形態を説明する。
実施の形態１．
図１はこの発明の実施の形態１によるテストケース生成方法の全体的手順を示すフローチャートであり、図において、１はＬＳＩを構成している複数の機能ブロックであるＬＳＩの各構成要素（以下、「エージェント」と称する）に関するＬＳＩ構成情報を格納するデータベース（第１のデータベース）、２は各エージェントの機能を検証する試験条件を格納するデータベース（第２のデータベース）、３は生成されたテストケースを格納するデータベース、４はテストケースをＬＳＩの機能モデル上でシミュレーションを行った結果を格納するデータベース、５はテストケースを実ＬＳＩ上で実行した結果を格納するデータベースである。
【００３１】
次に動作について説明する。
この実施の形態１のテストケース生成方法においては、データベース１からＬＳＩの各エージェントに関するＬＳＩ構成情報を呼び出し、データベース２から試験条件を呼び出して、Ｃ言語などのコンピュータ言語で形成されているテストケース生成ツールを用いてテストケースを生成し、生成したテストケースをデータベース３に格納する（ステップＳＴ１）。
【００３２】
次に、データベース３から、生成したテストケースを読み出し、ＬＳＩの各エージェントの機能モデルをＶｅｒｉｌｏｇ−ＨＤＬなどの論理シミュレータを用いてシミュレーションを実行し、そのシミュレーション結果をデータベース４に格納する（ステップＳＴ２）。また、データベース３から生成したテストケースを読み出し、実ＬＳＩ上で実行し、その実行結果をデータベース５に格納する（ステップＳＴ３）。
【００３３】
図２は図１のステップＳＴ１におけるテストケース生成の具体的手順を示すフローチャートである。以下、図２のフローチャートを参照しながら、テストケースを生成する具体的手順を説明する。
【００３４】
まず、あるバスに着目し、そのバスに接続されるエージェントで、１回目のマージ処理の対象とされていないエージェントの存否を判定する（ステップＳＴ１１）。ここでマージ処理とは複数の試験条件を組み合わせて共通の試験条件とする処理を指す。
【００３５】
１回目のマージ処理に際し、未済のエージェントが存在している場合には１回目のマージ処理を行う（ステップＳＴ１２）。そして、１回目のマージ処理の対象とされているエージェントの存否を判定する（ステップＳＴ１１）。
このようにして、１回目のマージ処理の未済のエージェントが存在しなくなるまで、エージェントの探索（ステップＳＴ１１）と１回目のマージ処理（ステップＳＴ１２）を繰り返す。
【００３６】
バスに接続されるエージェントのうちで、１回目のマージ処理のなされていないエージェントが存在しなくなった場合には、２回目のマージ処理のなされていないエージェントの存否を判定する（ステップＳＴ１３）。
【００３７】
２回目のマージ処理に際し、未済のエージェントが存在している場合には２回目のマージ処理を行う（ステップＳＴ１４）。そして、２回目のマージ処理の対象とされているエージェントの存否を判定する（ステップＳＴ１３）。
このようにして、２回目のマージ処理の未済のエージェントが存在しなくなるまで、エージェントの探索（ステップＳＴ１３）と２回目のマージ処理（ステップＳＴ１４）を繰り返す。
【００３８】
このようにしてバスに接続されるすべてのエージェントに対して２回目までのマージ処理が終了すると、各エージェントに対するすべての試験条件を満たすための動作条件を決定する（ステップＳＴ１５）。
【００３９】
次に、試験のために各エージェントに行わせる動作条件を満たすオペレーションを決定する（ステップＳＴ１６）。
【００４０】
そして、エージェントの内部状態をオペレーション実行後の状態に更新して（ステップＳＴ１７）、エージェント別にオペレーションを蓄積し、そのオペレーションの初期値とともにテストケースとしてデータベース３に格納する（ステップＳＴ１８）。
ここで、初期値とは、そのエージェントのテストケースを実行する前の状態を指す。
【００４１】
図３はマージ処理の具体的手順を示すフローチャートである。次に、図２のステップＳＴ１２及びＳＴ１４におけるマージ処理の具体的手順を図３のフローチャートを参照しながら説明する。
【００４２】
まず、マージ処理後の共通の試験条件に入力する条件の領域が大きいエージェントを開始エージェントとして設定する（ステップＳＴ２１）。
即ち、条件として大きな条件を有するもの（他の条件を包括する可能性の高いもの）から順次共通のマージ処理を行っていく。
【００４３】
次に、あるエージェントに対して与えられた試験条件を満たすための条件を共通の試験条件にマージするよう依頼する。このマージ処理をバスに接続している全てのエージェントに対して依頼する（ステップＳＴ２２）。
【００４４】
エージェントごとにマージ処理を行うたびに、そのエージェントまでのすべてのエージェントとマージが可能であるか否かを判別し（ステップＳＴ２３）、マージが可能であれば次のエージェントを設定してマージ処理を続行する（ステップＳＴ２８）。
【００４５】
マージが不可能な場合、即ち、条件の重複領域がなくなった場合には、そのエージェントを折り返し地点として一つ前のエージェントを設定する（ステップＳＴ２４）。この折り返しのため、一つ前のエージェントが存在するか否かを判定し（ステップＳＴ２５）、一つ前のエージェントが存在しない場合には、マージ不可能としてスタート時点に復帰する（ステップＳＴ２９）。一つ前のエージェントが存在する場合には、そのエージェントに対し与えられた試験条件を満たすための条件として先ほど共通の試験条件にマージした試験条件とは別の試験条件をマージするよう処理を依頼する（ステップＳＴ２６）。
【００４６】
このとき別の試験条件によるマージ処理の可否を判定し（ステップＳＴ２７）、別の試験条件が存在せず、マージ処理が不可能な場合には、更に一つ前のエージェントを設定し（ステップＳＴ２４）、同様にマージ処理順と逆順に別のマージ処理を要求する。このとき、別のマージ結果を得られず開始エージェントに到達した場合、そのテストオペレーションは実現できない。
また、別のマージ結果を得られた場合、そのエージェントを折り返し地点として、再び順方向にマージ処理を要求する（ステップＳＴ２８）。最後のエージェントから得たマージ結果が空でなかった場合、正常にマージ処理が終了したことになる。
【００４７】
バスはエージェントに接続したエージェントに対してこのマージ処理を２回行う（ステップＳＴ１２及びＳＴ１４）。１周目のマージ処理（ステップＳＴ１２）はエージェントが与えられた試験条件を満たすための共通の試験条件、即ち、最低限必要な条件を獲得するために行い、２周目のマージ処理（ステップＳＴ１４）は１回目のマージ処理を行った結果、共通の試験条件を構成するパラメータの中でデータが空であるパラメータ（特にデータを指定されていないパラメータ）を確定するために行う。
【００４８】
図４は図２のステップＳＴ１２における１周目のマージ処理の手順を示すフローチャートである。次に、この図４のフローチャートを参照しながら、１周目のマージ処理の動作を説明する。
【００４９】
エージェントはバスから１周目のマージ処理要求を受けた場合、エージェントに試験条件が指定されているか否かを判別し（ステップＳＴ３１）、試験条件が与えられている場合には、バスから渡された今までのエージェントのマージ結果とエージェントに与えられた試験条件を満たすための共通な試験条件とをマージし（ステップＳＴ３２）、マージ動作を終了する（ステップＳＴ３３）。エージェントに試験条件が与えられていない場合、特にマージ処理を行わずに処理動作を終了する（ステップＳＴ３４）。
【００５０】
図５は図２のステップＳＴ１４における２周目のマージ処理の手順を示すフローチャートである。次に、この図５のフローチャートを参照しながら、２周目のマージ処理の動作を説明する。
【００５１】
エージェントはバスから２周目のマージ処理要求を受けた場合、１周目のマージ結果に影響を与えることなく、共通な試験条件を構成するすべてのパラメータを確定していく。
即ち、まず、あるエージェントに対してそのエージェントの接続されたバスでの現在のマージ結果がエージェントの対象外か否かを判別する（ステップＳＴ４１）。
【００５２】
マージ結果がエージェントの対象外である場合には、特にエージェントの試験条件をマージすることなく処理を終了するが（ステップＳＴ４２）、マージ結果がエージェントの対象外でない場合には、与えられた試験条件を満たす条件の中で、最初の試験条件を要求されているかを判別する（ステップＳＴ４３）。
【００５３】
そして、最初の試験条件を要求されている場合には、最初の試験条件をマージする処理を実行し（ステップＳＴ４４）、最初の試験条件を要求されていない場合には、今までにバスの共通な試験条件とマージしていない別の試験条件をマージする処理を実行する（ステップＳＴ４５）。
【００５４】
そして、マージ結果が存在する場合には、マージ２周目の処理を終了するが（ステップＳＴ４６，ＳＴ４７）、マージ結果が存在しない場合には、初期化用のオペレーションを生成し（ステップＳＴ４８）、初期化用のオペレーションが生成されると、初期化用のオペレーションを実行し、マージ２周目の処理を終了する（ステップＳＴ４９，ＳＴ５０）。
ただし、初期化用のオペレーションが生成されない場合、エラー処理を実行する（ステップＳＴ５１）。
【００５５】
ここで、この実施の形態１のテストケース生成方法を具体例を用いて、もう少し具体的に説明する。
試験対象のＬＳＩの各構成要素を、図６に示すように、データ転送を開始する能動的な機能ブロックであるマスタＭ１，Ｍ２、あるいは、転送されるデータがエージェントの動作条件に該当する場合に所定の動作を開始する受動的な機能ブロックであるスレーブＳ１，Ｓ２、あるいは、マスタＭ１，Ｍ２とスレーブＳ１，Ｓ２を接続するバスＢ１の何れかに分類する。
【００５６】
例えば、図８に示すようなＬＳＩ１６（１１はメモリ１４から命令を読み込んで実行するＣＰＵ、１２はメモリ間のデータ転送を行うＤＭＡＣ、１３は内部バス、１４はメモリ、１５は外部とのデータのインタフェースを実行するＢＩＵ）と外部バス１７とメモリ１８を試験対象とする場合、図７に示すように、ＣＰＵ１１はマスタＭ１、ＤＭＡＣ１２はマスタＭ２、メモリ１４はスレーブＳ１、メモリ１８はスレーブＳ２、内部バス１３はバスＢ１、外部バス１７はバスＢ２、ＢＩＵ１５はブリッジ１９に分類する。
【００５７】
ただし、ブリッジ１９において、バスＢ１からデータを受け取る機能ブロックはスレーブＳ３、スレーブＳ３が受け取ったデータをバスＢ２に出力する機能ブロックはマスタＭ３、バスＢ２からデータを受け取る機能ブロックはスレーブＳ４、スレーブＳ４が受け取ったデータをバスＢ１に出力する機能ブロックはマスタＭ４に分類する。
【００５８】
マスタとスレーブとバスに割り付けられた試験対象に対しては、実施する試験条件をオペレーション毎に指定する。生成するテストケースのオペレーションの試験条件は、図９に示すように、連続したオペレーションの試験条件の指定を可能とする。指定は、実行順序毎に最初のオペレーションの試験条件４０１に続いて、生成するオペレーション４０１〜４０４の個数分を指定する。
【００５９】
オペレーション毎の試験条件の指定では、ＬＳＩを構成しているマスタＭ１の試験条件４０５とマスタＭ２の試験条件４０６とスレーブＳ１の試験条件４０７とスレーブＳ２の試験条件４０８から構成している。また、各マスタやスレーブの試験条件は、接続しているバスと共通な試験条件ＣＭＮ４０９と、マスタやスレーブなどのエージェント固有な試験条件ＬＯＣＡＬ４１０から構成している。
【００６０】
ただし、試験対象のエージェントに試験条件を設定すればよく、すべてのエージェントに指定する必要はない。また、複数の試験条件を指定した場合には、試験条件をマージしてオペレーションを生成する。
【００６１】
図９で指定された試験条件は、１つのオペレーション単位に、エージェント毎に指定された試験条件がマージされ、バス単位に条件を決定している。
複数のエージェントに指定された共通の試験条件ＣＭＮのマージ例は図１０の通りである。
【００６２】
図１０の例では、共通の試験条件の種類はｎ個あり（ＣＯＮ１からＣＯＮｎの試験条件がある）、マスタＭ１にはＣＯＮ１が指定され、マスタＭ２にはＣＯＮ２とＣＯＮ３が指定され、スレーブＳ１にはＣＯＮ２が指定され、スレーブＳ２にはＣＯＮｎが指定されている。
【００６３】
そして、試験条件をマージする場合には、バスに接続されているエージェントに指定されている試験条件を共通な試験条件にまとめることになる。
即ち、ＣＯＮ１に関しては、マスタＭ１のＣＯＮ１をマージし、ＣＯＮ２に関しては、マスタＭ２のＣＯＮ２とスレーブＳ１のＣＯＮ２をマージし、ＣＯＮ３に関しては、マスタＭ２のＣＯＮ３をマージし、ＣＯＮｎに関しては、スレーブＳ２のＣＯＮｎをマージする。
この結果、バスに対する試験条件の条件はマスタＭ１とＭ２と、スレーブＳ１とＳ２の試験条件をマージした試験条件でオペレーションを生成することになる。
【００６４】
また、試験条件が指定されていない場合には、各マスタやスレーブが持っている試験条件テーブルから、実行されていない試験条件を自動的に選択する。この結果、図１１に示すように、複数のマスタやスレーブに対する試験を実施する場合でも、試験条件を指定しない場合には、最小のオペレーションで各マスタやスレーブの試験が可能になる。
【００６５】
マスタＭ１は、ＳＴ１〜ＳＴ４の４個の条件を持っている。マスタＭ２は、ＳＴ１〜ＳＴ３の３個の条件を持っている。スレーブＳ１は、ＳＴ１〜ＳＴ５の５個の条件を持っている。スレーブＳ２は、ＳＴ１〜ＳＴ５の５個の条件を持っている。この場合は、条件の組み合わせとしては、以下の５種類がある。
（１）Ｍ１：ＳＴ２−Ｍ２：ＳＴ１−Ｓ１：ＳＴ１−Ｓ２：ＳＴ１
（２）Ｍ１：ＳＴ４−Ｍ２：ＳＴ１−Ｓ１：ＳＴ２−Ｓ２：ＳＴ２
（３）Ｍ１：ＳＴ１−Ｍ２：ＳＴ２−Ｓ１：ＳＴ３−Ｓ２：ＳＴ３
（４）Ｍ１：ＳＴ２−Ｍ２：ＳＴ２−Ｓ１：ＳＴ４−Ｓ２：ＳＴ４
（５）Ｍ１：ＳＴ３−Ｍ２：ＳＴ３−Ｓ１：ＳＴ５−Ｓ２：ＳＴ５
【００６６】
指定された試験条件をマージする概念を図１２に示す。指定された試験条件は、個々のエージェントに対して共通の試験条件７０７，７０９と固有の試験条件７０１，７０４として設定される。
【００６７】
指定された試験条件をマージする場合は、まず、共通な試験条件としてマージ前の条件ＢＦＲＣＭＮ７１３，７１５をエージェントに引き渡す。これは、エージェント間に依存関係が起きないようにエージェント間には、共通な試験条件のデータのみを処理情報とする。各エージェントは、マージ前の条件ＢＦＲＣＭＮ７１３，７１５と各エージェントに設定された固有な試験条件７０１，７０４とエージェントの内部状態７０３，７０６から各エージェントの機能に合わせて作成する条件変換部７０２，７０５を通じて、共通の試験条件７０８，７１０に変換する。変換された共通の試験条件７０８，７１０と指定された共通の試験条件７０７，７０９とマージ前のＢＦＲＣＭＮ７１３，７１５を合わせて、共通の試験条件７１１，７１２を生成する。
【００６８】
生成した共通の試験条件７１１，７１２は、エージェントのマージ結果として、ＡＦＴＣＭＮ７１４，７１６として設定される。複数のエージェントがある場合は、設定されたＡＦＴＣＭＮ７１４，７１６を次のエージェントの処理のＢＦＲＣＭＮ７１３，７１５とすることにより、すべてのエージェントに対して処理を繰り返し、バスの動作条件を決定する。決定したバスの動作条件は、マスタでは、動作を開始するオペレーションを決定し、スレーブではオペレーション対象の領域などを決定する。この場合に、次のオペレーションのために、今回、設定したオペレーションによって起きる各エージェントの内部状態の変化も記憶する。
【００６９】
以上で明らかなように、この実施の形態１によれば、ＬＳＩの各機能ブロックを、マスタ、スレーブ又はバスの何れかに分類して、各マスタとスレーブの試験条件を設定することにより、ＬＳＩのテストケースを自動生成するように構成したので、本来人手において作成が困難であったチップ内部の状態に着目したテストケースの作成が可能になる効果を奏する。
また、チップ内部の状態に着目した試験の実施に必要であった特殊な回路を用意することなく、製品出荷時と同じ回路でテストケースを実行することができる効果を奏する。
【００７０】
実施の形態２．
エージェントがブリッジを構成している場合には、１つのバスの条件を設定していく段階で、バス間の条件を変換する必要がある。
このため、エージェントがブリッジを構成する場合には、図１３に示すように、内部バスＢ１に接続されているスレーブＳ３とマスタＭ４、外部バスＢ２に接続されているスレーブＳ４とマスタＭ３の間に、内部バスＢ１と外部バスＢ２の条件を変換するブリッジ制御部Ｃを用意する。
【００７１】
図１４はエージェントがブリッジを構成する場合のマージ処理におけるブリッジ変換機能を示すが、バスＢ１からマージ要求を受けたブリツジは、バスＢ１のプロトコルに基づいた共通の試験条件をバスＢ２のプロトコルに基づいた共通の試験条件に変換して、バスＢ２を中心としたマージ処理を行った結果を、ブリッジのマージ結果としてバスＢ１に返送する（ステップＳＴ６１〜ＳＴ６４）。
一方、バスＢ２からマージ要求を受けたブリツジは、バスＢ２のプロトコルに基づいた共通の試験条件をバスＢ１のプロトコルに基づいた共通の試験条件に変換して、バスＢ１を中心としたマージ処理を行った結果を、ブリッジのマージ結果としてバスＢ２に返送する（ステップＳＴ６１〜ＳＴ６４）。
【００７２】
実施の形態３．
図１５はオペレーション間の試験条件のマージ例を示すが、この例では、設定されるオペレーションの個数は３個（Ｔ１，Ｔ２，Ｔ３）とする。オペレーションは、Ｔ１→Ｔ２→Ｔ３の順番に実行するものとする。
この場合、Ｔ１に対する試験条件があった場合には、設定されている試験条件がｗｒｉｔｅのみなので、特別な初期状態の設定は必要なしとなる。
【００７３】
次に、Ｔ２の試験条件があった場合には、設定されている試験条件が、ｒｅａｄであり、キャッシュｈｉｔでアドレスのマスク条件が００００１０００［１６進数］の００００ｆｆｆ０［１６進数］である。この場合、キャッシュｈｉｔとなる領域がないので、キャッシュをヒットさせるオペレーションＩ２の生成を実行させる必要がある。
この初期設定のオペレーションを生成する場合に、過去に生成したオペレーションの中に、同様な試験条件のオペレーションが存在するか否かをチェックする。
【００７４】
Ｉ２の場合は、Ｔ１が以前に生成したオペレーションであるが、条件が成立しないので、そのままＩ２を初期化オペレーションとする。この場合、Ｔ２は、試験条件を成立させるために、オペレーションを追加したことを示すフラグを設定する。
【００７５】
次に、Ｔ３の試験条件があった場合には、設定されている試験条件が、ｒｅａｄであり、キャッシュｈｉｔでアドレスのマスク条件が００５０１００４［１６進数］のｆｆｆｆｆｆｆｆ［１６進数］である。この場合、Ｉ３として、キャッシュｈｉｔで、アドレスが００５０１００４番地［１６進数］でデータ１００［１６進数］の試験条件を設定するためのオペレーションとなる。
Ｉ３の場合、以前に設定したＴ２にて、ｒｅａｄが行われているため、キャッシュｈｉｔの試験条件が成立している。このため、Ｔ２の試験条件にＩ３の試験条件をマージする。ただし、データが１００［１６進数］という試験条件が成立し、Ｔ２がオペレーションを追加しているため、以前に設定したオペレーションの有無をチェックする。
【００７６】
Ｔ１では、ｗｒｉｔｅ動作なので、Ｉ３のデータ１００［１６進数］の試験条件を設定することができるため、Ｔ１の試験条件にＩ３の試験条件を付加する。これでＩ３としての試験条件のマージは完了するが、Ｔ２のオペレーション追加に対して条件をマージする必要があるため、引き続き、以前に設定した試験条件をチェックし、Ｉ２にて試験条件をマージすることで、処理を完了させる。
【００７７】
テストオペレーション生成時に初期化が必要となった場合のマージ処理フローを図１６に示す。
あるエージェントがテストオペレーションを生成するために必要な初期化オペレーションを生成するようにバスに要求した場合、バスはこのテストオペレーションより以前にあるオペレーション群（テストオペレーションや初期化オペレーション）に対し、実行順序と逆順に初期化して、必要な条件を兼ねるようにマージする（ステップＳＴ７１〜ＳＴ８１）。この機能により、初期化オペレーションの個数を最小限に抑えることができるため、シミュレーションの実行時間を短縮することができる。
ただし、この場合、上記のオペレーション群の実行結果を保持する必要があるが、その際、その実行結果を保持する資源が飽和した場合でも、以後のオペレーションの実行結果を保持することができるようにするため、その資源の一部を開放するオペレーションを新規に生成する。
【００７８】
次に、テストオペレーション生成時に初期化が必要となった場合において、テストオペレーションより以前のオペレーション群から見たマージ処理フローを図１７に示す。
例えば、オペレーション１が初期化で必要な試験条件のすべてをマージできた場合（ステップＳＴ９１〜ＳＴ９４）、新たな初期化オペレーションを生成せずに済む。
【００７９】
しかし、オペレーション１が、それより前の別のオペレーション２によって、はじめて成立する場合、オペレーション２にも、この初期化で必要な試験条件のすべてを反映させなければならない。
一方、オペレーション１が初期化で必要な条件を部分的にマージできる場合（ステップＳＴ９５〜ＳＴ９７）、マージした試験条件を初期化で必要な試験条件の中から削除し、同様の処理を繰り返す。また、オペレーション１の試験条件と、この初期化で必要な試験条件が排他的な場合、試験条件の設定ミスと見なす（ステップＳＴ９８〜ＳＴ９９）。また、初期化で必要な試験条件を全くマージ不可能な場合（ステップＳＴ１００）、特に処理をしない。
【００８０】
次に、マージ処理によって確定した条件を実現するためのデータの中で不確定のデータについては任意のデータが許容されていると判断して、乱数を割り当てる。例えば、メモリアドレスに関して、あるビットだけ指定されており、残りのビットに対しては特に指定を受けていない場合、残りのビットに対して乱数を割り当てることにより、メモリアクセス対象が偏らないようにする（図１８を参照）。
【００８１】
実施の形態４．
図１９は生成したテストケースを示す構造図である。
テストケースは、初期値とオペレーションと期待値から構成する。初期値は、テストケースを実行する前の状態が設定されている。マスタやスレーブによって、初期値の設定できないものもあるが、この場合は、初期状態を設定するオペレーションを生成することで実現している。特に、チップ内部の機能ブロックに対しては、初期状態を設定する際、特別の回路を用意しないとできないため、オペレーション（マスタの動作）によって初期状態を設定することになる。
【００８２】
期待値は、テストケースのオペレーションが終了した段階の状態が設定されている。マスタやスレーブによっては、期待値の状態を確認する方法がない場合があるが、期待値を比較するオペレーションを試験の最後に生成することで、実行結果の確認を実施する。オペレーションでは、前述した通りに、状態を設定する初期化オペレーションと試験を実施する試験用オペレーションと期待値を比較する期待値比較オペレーションから構成している。
【００８３】
この様に、初期状態設定から期待値比較までをオペレーションにて定義することを可能としたことで、チップ内部の機能に対する試験を可能としている。また、オペレーションには、マスタやスレーブに対するオペレーション以外に、バス上で行われるオペレーションに関しても保持する。これは、シミュレーション上で試験を実施する場合の期待値として使用することに加えて、バス上で行われたオペレーションから、どのような試験を実施したかを示す評価データに用いることが可能である。
【００８４】
実施の形態５．
テストケースの生成においては、ＬＳＩを構成する機能ブロックや試験を実行する試験環境によって、テストケース生成を行うためのマスタやスレーブの機能を設定する。図２０の実行環境においては、試験対象であるマスタＭ１，Ｍ２とスレーブＳ１，Ｓ２の他に、マスタＭ１，Ｍ２とスレーブＳ１，Ｓ２を制御する試験用の回路を用意し、その試験用の回路の機能に合わせたテストケースを生成する。また、バスの状態をチェックするためのバスの評価回路Ｂ１，Ｂ２にあわせて、テストケースにバスの期待値を設定する。
【００８５】
同じ試験対象でも、異なる試験環境で実行可能なテストケースを生成する場合には、図２１に示すように、スレーブ８００の構造を、バス側の制御を行うスレーブＳ１と検証環境で実行する試験回路に合わせるＴＳ１の構成とする。試験環境の変更には、試験環境に合ったＴＳ１か、ＴＳ１＿１か、ＴＳ１＿２かを用いることで、テストケースの生成においては、スレーブＳ１が処理を行う。試験環境にあったテストケースを生成するときは、ＴＳ１が処理を行うことで、テストケースの条件設定を変えることなく、異なる試験環境で動作するテストケースの生成が可能となる。
【００８６】
【発明の効果】
以上のように、この発明によれば、テストケース生成ツールが第１のデータベースに格納されているＬＳＩ構成情報を参照して、所定のバスに接続されている複数の機能ブロックを探索し、そのテストケース生成ツールが第２のデータベースから上記複数の機能ブロックに対する試験条件を読み出して共通の試験条件をマージし、そのマージした共通の試験条件と上記機能ブロックに固有の試験条件とからＬＳＩの機能を検証するテストケースを生成するように構成したので、専用の回路を設けることなく、高速かつ容易にテストケースを生成することができる効果がある。
【００８７】
この発明によれば、ＬＳＩを構成している複数の機能ブロックが、データ転送動作を開始するマスタ、転送されるデータが自己の動作条件に該当する場合に所定の動作を開始するスレーブ、または、マスタとスレーブを接続するバスの何れかに分類されており、第１のデータベースがマスタ、スレーブ及びバスに関するＬＳＩ構成情報を格納し、第２のデータベースがマスタ、スレーブ及びバスの試験条件を格納するように構成したので、本来人手において作成が困難であったチップ内部の状態に着目したテストケースの作成が可能になる効果がある。
また、チップ内部の状態に着目した試験の実施に必要であった特殊な回路を用意することなく、製品出荷時と同じ回路でテストケースを実行することができる効果がある。
【００８８】
この発明によれば、機能ブロックに対する試験条件がバスの試験条件と共通していれば、テストケース生成ツールがその機能ブロックに対する試験条件をバスの試験条件とマージするように構成したので、試験条件の設定作業を簡略化することができる効果がある。
【００８９】
この発明によれば、機能ブロックが複数のバスに接続されている場合、テストケース生成ツールが機能ブロックに対する試験条件をバスの試験条件とマージする前に、ブリッジ制御部が一方のバスの試験条件を他方のバスの試験条件に合わせて変換するように構成したので、複数のバスを内蔵するＬＳＩも、単一のバスを内蔵するＬＳＩと同様に取り扱うことができるようになり、その結果、ＬＳＩ全体の試験条件の個数を抑制することができるため、試験の効率化を図ることができる効果がある。
【図面の簡単な説明】
【図１】  この発明の実施の形態１によるテストケース生成方法を示すフローチャートである。
【図２】  テストケース生成の具体的手順を示すフローチャートである。
【図３】  マージ処理の具体的手順を示すフローチャートである。
【図４】  １周目のマージ処理の手順を示すフローチャートである。
【図５】  ２周目のマージ処理の手順を示すフローチャートである。
【図６】  単一のバスのエージェントを示す構成図である。
【図７】  複数のバスのエージェントを示す構成図である。
【図８】  ＬＳＩチップを示す構成図である。
【図９】  パラメータの試験条件を示す構成図である。
【図１０】  試験条件の組み合わせを示す説明図である。
【図１１】  エージェント状態の組み合わせを示す説明図である。
【図１２】  試験条件のマージを示す概念図である。
【図１３】  ブリッジを示す構成図である。
【図１４】  ブリッジのマージ処理を示すフローチャートである。
【図１５】  テストオペレーションの生成処理を示すフローチャートである。
【図１６】  試験条件のマージ処理を示すフローチャートである。
【図１７】  試験条件のマージ処理を示すフローチャートである。
【図１８】  アドレスの決定処理を示すフローチャートである。
【図１９】  テストケースを示す構造図である。
【図２０】  テストケースの実行環境を示す環境図である。
【図２１】  エージェントを示す構造図である。
【符号の説明】
Ｍ１，Ｍ２  マスタ、Ｓ１，Ｓ２  スレーブ、Ｂ１  バス。
【図１】
0003859879.tif 000002
【図２】
0003859879.tif 000003
【図３】
0003859879.tif 000004
【図４】
0003859879.tif 000005
【図５】
0003859879.tif 000006
【図６】
0003859879.tif 000007
【図７】
0003859879.tif 000008
【図８】
0003859879.tif 000009
【図９】
0003859879.tif 000010
【図１０】
0003859879.tif 000011
【図１１】
0003859879.tif 000012
【図１２】
0003859879.tif 000013
【図１３】
0003859879.tif 000014
【図１４】
0003859879.tif 000015
【図１５】
0003859879.tif 000016
【図１６】
0003859879.tif 000017
【図１７】
0003859879.tif 000018
【図１８】
0003859879.tif 000019
【図１９】
0003859879.tif 000020
【図２０】
0003859879.tif 000021
【図２１】
0003859879.tif 000022