JP2637914B2 - テスト・プログラム・ジェネレータ及びテスト・プログラムを生成する方法 - Google Patents
テスト・プログラム・ジェネレータ及びテスト・プログラムを生成する方法Info
- Publication number
- JP2637914B2 JP2637914B2 JP6065989A JP6598994A JP2637914B2 JP 2637914 B2 JP2637914 B2 JP 2637914B2 JP 6065989 A JP6065989 A JP 6065989A JP 6598994 A JP6598994 A JP 6598994A JP 2637914 B2 JP2637914 B2 JP 2637914B2
- Authority
- JP
- Japan
- Prior art keywords
- instruction
- test
- data
- instance
- generating
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 238000000034 method Methods 0.000 title claims description 47
- 238000012360 testing method Methods 0.000 claims description 110
- 230000014509 gene expression Effects 0.000 claims description 52
- 238000007689 inspection Methods 0.000 claims description 21
- 238000012545 processing Methods 0.000 claims description 3
- 230000006870 function Effects 0.000 description 72
- 230000015654 memory Effects 0.000 description 33
- 238000013461 design Methods 0.000 description 20
- 230000007246 mechanism Effects 0.000 description 18
- 230000008569 process Effects 0.000 description 13
- 230000008859 change Effects 0.000 description 9
- 238000013459 approach Methods 0.000 description 7
- 238000010586 diagram Methods 0.000 description 6
- 238000006073 displacement reaction Methods 0.000 description 6
- 230000000694 effects Effects 0.000 description 5
- 230000003068 static effect Effects 0.000 description 4
- 238000013519 translation Methods 0.000 description 4
- 230000014616 translation Effects 0.000 description 4
- 230000006399 behavior Effects 0.000 description 3
- 238000004088 simulation Methods 0.000 description 3
- 101150106235 ISPS gene Proteins 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 238000013468 resource allocation Methods 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 102100036464 Activated RNA polymerase II transcriptional coactivator p15 Human genes 0.000 description 1
- 101000713904 Homo sapiens Activated RNA polymerase II transcriptional coactivator p15 Proteins 0.000 description 1
- 101000654674 Homo sapiens Semaphorin-6A Proteins 0.000 description 1
- 229910004444 SUB1 Inorganic materials 0.000 description 1
- 102100032795 Semaphorin-6A Human genes 0.000 description 1
- 238000004422 calculation algorithm Methods 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000012812 general test Methods 0.000 description 1
- 238000010348 incorporation Methods 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3684—Test management for test design, e.g. generating new test cases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
Description
【０００１】
【産業上の利用分野】本発明は、コンピュータ用ハード
ウェア・プロセッサの設計をチェックするために用いら
れるプログラムを生成するテスト・プログラム・ジェネ
レータに関する。
ウェア・プロセッサの設計をチェックするために用いら
れるプログラムを生成するテスト・プログラム・ジェネ
レータに関する。
【０００２】
【従来の技術】プロセッサ検査の目標は、プロセッサと
そのアーキテクチャ仕様を同等にすることである。この
目標は正規の証明か、または徹底したシミュレーション
によって達成される。しかし、プロセッサの複雑さによ
り、業務用のほとんどのアプリケーションに関して、正
規のアプローチが現実的ではなくなり、テスト空間の大
きさにより徹底したシミュレーションは不可能になる。
そのアーキテクチャ仕様を同等にすることである。この
目標は正規の証明か、または徹底したシミュレーション
によって達成される。しかし、プロセッサの複雑さによ
り、業務用のほとんどのアプリケーションに関して、正
規のアプローチが現実的ではなくなり、テスト空間の大
きさにより徹底したシミュレーションは不可能になる。
【０００３】一般的にアーキテクチャ仕様は、プロセッ
サのリソース、命令群及び命令の実行がプロセッサの状
態に与える効果を非公式に記述したものである。また、
アドレス変換、割込み処理、マルチタスク等の主なハー
ドウェア・メカニズムも記述する。コンピュータのアー
キテクチャは複雑である。典型的なアーキテクチャには
数百の命令がある。リソースは主メモリ、汎用レジス
タ、専用レジスタ等を含めて数十個あり、浮動小数点、
アドレス変換、外部割込みのメカニズム等、複雑な機能
要素がある。典型的なアーキテクチャの記述は数百ペー
ジにも及ぶ。
サのリソース、命令群及び命令の実行がプロセッサの状
態に与える効果を非公式に記述したものである。また、
アドレス変換、割込み処理、マルチタスク等の主なハー
ドウェア・メカニズムも記述する。コンピュータのアー
キテクチャは複雑である。典型的なアーキテクチャには
数百の命令がある。リソースは主メモリ、汎用レジス
タ、専用レジスタ等を含めて数十個あり、浮動小数点、
アドレス変換、外部割込みのメカニズム等、複雑な機能
要素がある。典型的なアーキテクチャの記述は数百ペー
ジにも及ぶ。
【０００４】実際、ハードウェア・プロセッサの設計検
査は、一定の設計パラメータ群を含むハードウェア・シ
ミュレータを用い、アセンブリ・レベルのテスト・プロ
グラム群の動作をシミュレートし、その結果を動作シミ
ュレータによって予測された出力と比較することによっ
て行なわれるのが普通である。
査は、一定の設計パラメータ群を含むハードウェア・シ
ミュレータを用い、アセンブリ・レベルのテスト・プロ
グラム群の動作をシミュレートし、その結果を動作シミ
ュレータによって予測された出力と比較することによっ
て行なわれるのが普通である。
【０００５】ハードウェア・シミュレータは、ＩＥＥＥ
規格ＶＨＤＬ（ＩＥＥＥ規格１０７６−１９８７）等の
ハードウェア記述言語で書かれた設計モデルを入力する
ことができる。もちろんプロトタイプ・ハードウェアが
使用できれば、その上でテスト・プログラムを直接実行
できる。動作シミュレータは普通、ソフトウェアの開発
目的に合わせて実際のハードウェアよりも先に書かれ、
アーキテクチャ仕様が与えられれば、予想されたハード
ウェア動作を示す。
規格ＶＨＤＬ（ＩＥＥＥ規格１０７６−１９８７）等の
ハードウェア記述言語で書かれた設計モデルを入力する
ことができる。もちろんプロトタイプ・ハードウェアが
使用できれば、その上でテスト・プログラムを直接実行
できる。動作シミュレータは普通、ソフトウェアの開発
目的に合わせて実際のハードウェアよりも先に書かれ、
アーキテクチャ仕様が与えられれば、予想されたハード
ウェア動作を示す。
【０００６】従来、このようなテスト・プログラムは人
手で書かれていた。まず、テスト条件のリストがコンパ
イルされる。次にこのリストをカバーするようにテスト
が作成される。アーキテクチャ仕様から導かれた条件で
は普通、全ての命令を通常の境界条件と例外条件下でテ
ストする必要がある。これらの条件を満たすように書か
れたテストは、アーキテクチャ検査プログラム（ＡＶ
Ｐ）と呼ばれ、現実のどのアーキテクチャ上でも正常に
動作することが求められる。第２の条件リストと実施検
査プログラム（ＩＶＰ）を作成するために、クロック・
サイクル、キャッシュ・サイズ等、設計上の基本的な細
目を定義した設計ワークブックと、実際のＨＤＬ設計が
用いられる。ＩＶＰは、通常、キャッシュ、パイプライ
ン及び桁上げルック・アヘッド加算器またはビット・ロ
テータ等のユニットの機能をテストする。
手で書かれていた。まず、テスト条件のリストがコンパ
イルされる。次にこのリストをカバーするようにテスト
が作成される。アーキテクチャ仕様から導かれた条件で
は普通、全ての命令を通常の境界条件と例外条件下でテ
ストする必要がある。これらの条件を満たすように書か
れたテストは、アーキテクチャ検査プログラム（ＡＶ
Ｐ）と呼ばれ、現実のどのアーキテクチャ上でも正常に
動作することが求められる。第２の条件リストと実施検
査プログラム（ＩＶＰ）を作成するために、クロック・
サイクル、キャッシュ・サイズ等、設計上の基本的な細
目を定義した設計ワークブックと、実際のＨＤＬ設計が
用いられる。ＩＶＰは、通常、キャッシュ、パイプライ
ン及び桁上げルック・アヘッド加算器またはビット・ロ
テータ等のユニットの機能をテストする。
【０００７】人手で書かれたテストによる設計検査はコ
スト効率がよくない。このアプローチでは、プロセッサ
の設計労力の大半が検査に費やされる。更に、これらの
テストの多くはかなり単純である。そのためテスト・エ
ンジニアは複雑な状況を定義しにくい。
スト効率がよくない。このアプローチでは、プロセッサ
の設計労力の大半が検査に費やされる。更に、これらの
テストの多くはかなり単純である。そのためテスト・エ
ンジニアは複雑な状況を定義しにくい。
【０００８】プロセッサのアーキテクチャを検査するた
めのこのようなテスト・プログラムの自動生成について
は、A．Aharonらによる"Verification of the IBM RISC
System/6000 By a Dynamic Biased Pseudo-Random Test
Program Generator"（IBM Systems Journal、１９９１
年４月） （以下Ｒ１と呼ぶ）、及び欧州特許出願第４
５３３９４号を参照されたい。テスト・プログラムの生
成を自動化することにより生産性が高まり、近年では品
質の向上もみられる。
めのこのようなテスト・プログラムの自動生成について
は、A．Aharonらによる"Verification of the IBM RISC
System/6000 By a Dynamic Biased Pseudo-Random Test
Program Generator"（IBM Systems Journal、１９９１
年４月） （以下Ｒ１と呼ぶ）、及び欧州特許出願第４
５３３９４号を参照されたい。テスト・プログラムの生
成を自動化することにより生産性が高まり、近年では品
質の向上もみられる。
【０００９】通常、このようなテスト・プログラム・ジ
ェネレータは複雑なソフトウェア・システムである。そ
の１例はプログラム言語Ｃで書かれたＲ１に述べられて
いるが、これはコードが約１５万行にも及ぶ。プロセッ
サ・アーキテクチャの複雑さ（これは現在では数百の命
令と、約十個の機能ユニットを含む）と、その非公式の
記述は、テスト生成システムの複雑さに反映されてい
る。
ェネレータは複雑なソフトウェア・システムである。そ
の１例はプログラム言語Ｃで書かれたＲ１に述べられて
いるが、これはコードが約１５万行にも及ぶ。プロセッ
サ・アーキテクチャの複雑さ（これは現在では数百の命
令と、約十個の機能ユニットを含む）と、その非公式の
記述は、テスト生成システムの複雑さに反映されてい
る。
【００１０】これら従来のテスト・プログラム・ジェネ
レータには、そのプロセスが用いられるアーキテクチャ
毎に新しいテスト・プログラム・ジェネレータを開発し
具体化しなければならないという欠点がある。ジェネレ
ータはアーキテクチャに依存すると言える。
レータには、そのプロセスが用いられるアーキテクチャ
毎に新しいテスト・プログラム・ジェネレータを開発し
具体化しなければならないという欠点がある。ジェネレ
ータはアーキテクチャに依存すると言える。
【００１１】また、アーキテクチャの変化やテスト条件
の変更があれば、ジェネレータのコードを細かく変更す
る必要がある。アーキテクチャがまだ改良されている時
にも設計検査が進行するので、テスト生成システムはし
ばしば変更されるのが普通である。
の変更があれば、ジェネレータのコードを細かく変更す
る必要がある。アーキテクチャがまだ改良されている時
にも設計検査が進行するので、テスト生成システムはし
ばしば変更されるのが普通である。
【００１２】一般的に変更には２つのレベルがある。ア
ーキテクチャ・バージョン内の変更とバージョン間の変
更である。バージョン内では普通、数百の変更仕様があ
り、その多くは変更内容が細かい。アーキテクチャが比
較的安定していれば、アーキテクチャ・バージョンが宣
言される。それは前バージョンより大きく違っているだ
ろう。いずれのレベルでも変更は非公式に記述され、見
分けるのは難しいことが多く、そのテスト・プログラム
・ジェネレータに対する効果が常に明確ではない。ま
た、テスト・ジェネレータに必要な変更仕様の多くは、
検査プロセス自体を通じて蓄積されたテストに関する知
識による。前のテスト結果として、また設計ミスが見つ
けられなかった結果として、新しいテストが頻繁に必要
とされる。
ーキテクチャ・バージョン内の変更とバージョン間の変
更である。バージョン内では普通、数百の変更仕様があ
り、その多くは変更内容が細かい。アーキテクチャが比
較的安定していれば、アーキテクチャ・バージョンが宣
言される。それは前バージョンより大きく違っているだ
ろう。いずれのレベルでも変更は非公式に記述され、見
分けるのは難しいことが多く、そのテスト・プログラム
・ジェネレータに対する効果が常に明確ではない。ま
た、テスト・ジェネレータに必要な変更仕様の多くは、
検査プロセス自体を通じて蓄積されたテストに関する知
識による。前のテスト結果として、また設計ミスが見つ
けられなかった結果として、新しいテストが頻繁に必要
とされる。
【００１３】従来技術では、アーキテクチャの特徴とテ
ストから得られた知識が生成システム内にモデル化され
る。アーキテクチャは有効な命令とテストを生成するの
に必要である。テストに関する知識は、有益な命令やテ
スト、洗練された命令やテスト、或いは有意義な命令や
テストを生成するのに用いられる。アーキテクチャとテ
スト知識の両方のモデルは、手続き的なものであり、互
いに密接に結び付いている。つまり目につきやすいもの
ではない。そのため複雑さや変更可能性の効果が減少す
る。
ストから得られた知識が生成システム内にモデル化され
る。アーキテクチャは有効な命令とテストを生成するの
に必要である。テストに関する知識は、有益な命令やテ
スト、洗練された命令やテスト、或いは有意義な命令や
テストを生成するのに用いられる。アーキテクチャとテ
スト知識の両方のモデルは、手続き的なものであり、互
いに密接に結び付いている。つまり目につきやすいもの
ではない。そのため複雑さや変更可能性の効果が減少す
る。
【００１４】
【発明が解決しようとする課題】本発明は、アーキテク
チャに依存しないテスト・プログラム・ジェネレータに
よって従来技術を改良しようとするものである。これは
部分的には、知識を制御から分けることによって達成さ
れる。言い換えると、アーキテクチャに依存しないジェ
ネレータは、プロセッサ・アーキテクチャが適切にモデ
ル化された、独立した宣言仕様として格納されたデータ
を抽出するために用いられる。
チャに依存しないテスト・プログラム・ジェネレータに
よって従来技術を改良しようとするものである。これは
部分的には、知識を制御から分けることによって達成さ
れる。言い換えると、アーキテクチャに依存しないジェ
ネレータは、プロセッサ・アーキテクチャが適切にモデ
ル化された、独立した宣言仕様として格納されたデータ
を抽出するために用いられる。
【００１５】しかし、適切な外部アーキテクチャ・モデ
ルをまとめるのは容易ではない。１つの方法は、アーキ
テクチャによって規定された命令のシンタックスに、モ
デルが従うようにすることである。このレベルのモデリ
ングには、有益な或いは有意義なテスト・プログラムを
生成するに充分な情報が含まれない。もう１つの極端な
例は、アーキテクチャ・シミュレータに見られるよう
に、命令の実行結果を含めたアーキテクチャのセマンテ
ィクスを完全にモデル化することである。このレベルの
モデリングは極めて複雑であり、このレベルの細目を使
用できるジェネレータを実現するのは極めて難しい。
ルをまとめるのは容易ではない。１つの方法は、アーキ
テクチャによって規定された命令のシンタックスに、モ
デルが従うようにすることである。このレベルのモデリ
ングには、有益な或いは有意義なテスト・プログラムを
生成するに充分な情報が含まれない。もう１つの極端な
例は、アーキテクチャ・シミュレータに見られるよう
に、命令の実行結果を含めたアーキテクチャのセマンテ
ィクスを完全にモデル化することである。このレベルの
モデリングは極めて複雑であり、このレベルの細目を使
用できるジェネレータを実現するのは極めて難しい。
【００１６】本発明に従ったテスト・プログラム・ジェ
ネレータは、ハードウェア・プロセッサ設計の動作をチ
ェックするためのテスト・プログラムを生成するもので
あり、プロセッサの命令群とリソースを表わすデータを
格納するための手段と、後の格納や処理を目的に格納さ
れた前記データからテスト・プログラムを生成する手段
を含む。このジェネレータの特徴は、データが独立した
宣言仕様であること、ジェネレータが格納手段から前記
データを抽出する論理を含むこと、また各命令に関連づ
けられたセマンティック・エンティティ間や、前記セマ
ンティック・エンティティとプロセッサ・リソースの間
の関係が、前記宣言仕様の中にモデル化されるという点
である。
ネレータは、ハードウェア・プロセッサ設計の動作をチ
ェックするためのテスト・プログラムを生成するもので
あり、プロセッサの命令群とリソースを表わすデータを
格納するための手段と、後の格納や処理を目的に格納さ
れた前記データからテスト・プログラムを生成する手段
を含む。このジェネレータの特徴は、データが独立した
宣言仕様であること、ジェネレータが格納手段から前記
データを抽出する論理を含むこと、また各命令に関連づ
けられたセマンティック・エンティティ間や、前記セマ
ンティック・エンティティとプロセッサ・リソースの間
の関係が、前記宣言仕様の中にモデル化されるという点
である。
【００１７】命令と関連づけられたセマンティック・エ
ンティティの関係のモデルは、その命令の実行結果を記
述する必要がなく、セマンティック・エンティティの関
係を正確に定義したものを含む。これは２つの部分で行
なえる。セマンティック・エンティティの定義と、エン
ティティの関係の記述である。エンティティに対する命
令の実行結果の記述を加える必要がない。
ンティティの関係のモデルは、その命令の実行結果を記
述する必要がなく、セマンティック・エンティティの関
係を正確に定義したものを含む。これは２つの部分で行
なえる。セマンティック・エンティティの定義と、エン
ティティの関係の記述である。エンティティに対する命
令の実行結果の記述を加える必要がない。
【００１８】本発明においては、この方法によるモデル
から、有益なテスト・プログラムを生成するのに充分な
パワーが得られると同時に、ジェネレータ及びモデルの
複雑さが合理的な状態に保たれ、テスト・プログラムの
生成に必要な計算時間も合理的な限度内に維持されるこ
とを確認している。
から、有益なテスト・プログラムを生成するのに充分な
パワーが得られると同時に、ジェネレータ及びモデルの
複雑さが合理的な状態に保たれ、テスト・プログラムの
生成に必要な計算時間も合理的な限度内に維持されるこ
とを確認している。
【００１９】つまり本発明は、アーキテクチャに依存し
ないテスト・ジェネレータと、それを駆動する外部アー
キテクチャ・モデルを提供するものである。
ないテスト・ジェネレータと、それを駆動する外部アー
キテクチャ・モデルを提供するものである。
【００２０】
【課題を解決するための手段】独立した宣言仕様は、好
適には、生成論理の外部のデータベースの形をとるが、
例えば、システムの内部ファイルにあってもよく、その
場合でも、ジェネレータから独立しており宣言的であ
る。すなわち手続き群ではなく、データ構造群である。
適には、生成論理の外部のデータベースの形をとるが、
例えば、システムの内部ファイルにあってもよく、その
場合でも、ジェネレータから独立しており宣言的であ
る。すなわち手続き群ではなく、データ構造群である。
【００２１】ある実施例では、独立した宣言仕様の中に
各命令の表現がツリー構造の形で格納される。ツリーの
第１レベルは命令のシンタックスを含み、最後のレベル
はセマンティック・エンティティに可能な値、及びセマ
ンティック・エンティティの関係を含む。この例の場
合、ジェネレータは命令インスタンスを生成する手段
と、ツリー構造を深さ方向にたどり、前の検索ステップ
で行なわれた選択に従って各セマンティック・エンティ
ティのインスタンスを生成する手段を含み、命令インス
タンスの一貫性を維持する。言い換えると、ツリー検索
の早い段階で成された決定をコミットすることによって
一貫性が実現される。
各命令の表現がツリー構造の形で格納される。ツリーの
第１レベルは命令のシンタックスを含み、最後のレベル
はセマンティック・エンティティに可能な値、及びセマ
ンティック・エンティティの関係を含む。この例の場
合、ジェネレータは命令インスタンスを生成する手段
と、ツリー構造を深さ方向にたどり、前の検索ステップ
で行なわれた選択に従って各セマンティック・エンティ
ティのインスタンスを生成する手段を含み、命令インス
タンスの一貫性を維持する。言い換えると、ツリー検索
の早い段階で成された決定をコミットすることによって
一貫性が実現される。
【００２２】有益なテスト・プログラムの生成に関する
テスト知識は、好適には、格納されたデータ内にモデル
化される。これは、好適な実施例では、生成プロセスの
前に定義される生成関数を含む、セマンティック・エン
ティティのインスタンスを生成する手段によって、手続
きモデルを通して達成される。生成関数は、目的のテス
ト・ケースが生成できるようにユーザによって調整され
る。
テスト知識は、好適には、格納されたデータ内にモデル
化される。これは、好適な実施例では、生成プロセスの
前に定義される生成関数を含む、セマンティック・エン
ティティのインスタンスを生成する手段によって、手続
きモデルを通して達成される。生成関数は、目的のテス
ト・ケースが生成できるようにユーザによって調整され
る。
【００２３】ジェネレータにはまた、生成されたセマン
ティック・エンティティ・インスタンスを、検査基準に
従ってテストする手段を加えることができ、これがこの
ジェネレータのもう１つの利点である。検査基準もまた
ユーザが調整できる。セマンティック・エンティティ・
インスタンスの生成は、生成されたインスタンスが複数
の検査基準を、或いは検査基準のそれぞれを満足しない
場合に繰返される。
ティック・エンティティ・インスタンスを、検査基準に
従ってテストする手段を加えることができ、これがこの
ジェネレータのもう１つの利点である。検査基準もまた
ユーザが調整できる。セマンティック・エンティティ・
インスタンスの生成は、生成されたインスタンスが複数
の検査基準を、或いは検査基準のそれぞれを満足しない
場合に繰返される。
【００２４】このような実施例の場合、外部データベー
スに記入するユーザは、生成関数や検査関数を書いて、
進化するテスト知識を取り入れ、目的のテスト・プログ
ラムを生成することができる。
スに記入するユーザは、生成関数や検査関数を書いて、
進化するテスト知識を取り入れ、目的のテスト・プログ
ラムを生成することができる。
【００２５】本発明は、別の角度から見ると、このよう
なテスト・プログラムを生成する方法を提供できるよう
にするものである。この方法は、プロセッサの命令群と
リソースを表わすデータを、独立した宣言仕様に格納す
るステップ（宣言仕様内には、各命令に関連づけられた
セマンティック・エンティティの関係や、セマンティッ
ク・エンティティとプロセッサのリソースの関係がモデ
ル化される）、前記データを記憶装置から抽出するステ
ップ、及び抽出された前記データからテスト・プログラ
ムを生成するステップを含む。
なテスト・プログラムを生成する方法を提供できるよう
にするものである。この方法は、プロセッサの命令群と
リソースを表わすデータを、独立した宣言仕様に格納す
るステップ（宣言仕様内には、各命令に関連づけられた
セマンティック・エンティティの関係や、セマンティッ
ク・エンティティとプロセッサのリソースの関係がモデ
ル化される）、前記データを記憶装置から抽出するステ
ップ、及び抽出された前記データからテスト・プログラ
ムを生成するステップを含む。
【００２６】本発明は、テスト条件が展開されるにつれ
てアーキテクチャ毎にジェネレータを再度実現する必要
性をなくすものである。つまり、新しいアーキテクチャ
のためのジェネレータを開発するコストが大幅に削減さ
れる。モデルはジェネレータの外部にあるため、アーキ
テクチャに変更を加えるための労力も少なくなる。
てアーキテクチャ毎にジェネレータを再度実現する必要
性をなくすものである。つまり、新しいアーキテクチャ
のためのジェネレータを開発するコストが大幅に削減さ
れる。モデルはジェネレータの外部にあるため、アーキ
テクチャに変更を加えるための労力も少なくなる。
【００２７】アーキテクチャに依存しない生成プロセス
は、外部データベースのインタープリタと考えることが
できる。従来の複雑さの問題は、データベースと制御と
をはっきり分けることによって小さくなる。更に、アー
キテクチャ・シミュレータをジェネレータから分離して
おくことで、システムの複雑さの大本が取り除かれる。
目につきにくさ（invisibility）は、アーキテクチャと
テスト知識の正式な宣言モデリングによって小さくな
る。変更可能性の問題は、ほとんどの変更仕様をデータ
ベースに収めることで小さくなる。
は、外部データベースのインタープリタと考えることが
できる。従来の複雑さの問題は、データベースと制御と
をはっきり分けることによって小さくなる。更に、アー
キテクチャ・シミュレータをジェネレータから分離して
おくことで、システムの複雑さの大本が取り除かれる。
目につきにくさ（invisibility）は、アーキテクチャと
テスト知識の正式な宣言モデリングによって小さくな
る。変更可能性の問題は、ほとんどの変更仕様をデータ
ベースに収めることで小さくなる。
【００２８】外部データベースは、テスト知識を表現す
ることによってヒューリスティック知識ベースになる。
ヒューリスティックとはテスト・エンジニアのノウハウ
を表わす。エキスパートはモデルを通して知識をローカ
ルに、比較的簡単に追加することができる。また、蓄積
されたユーザの経験をシステムに取り入れることがで
き、ジェネレータは、テスト・プロセスの展開をたどる
ことができる。モデルをベースにしたテスト生成法で
は、複雑なテスト知識のこのシステムへの組込みが可能
になる。モデルはこのように、アーキテクチャの定義と
重要なテスト・ケースを生成する方法の記述の両方に用
いることができる。更にまた、あるアーキテクチャ及び
設計から別のアーキテクチャ、設計にテスト知識を移行
することもできる。
ることによってヒューリスティック知識ベースになる。
ヒューリスティックとはテスト・エンジニアのノウハウ
を表わす。エキスパートはモデルを通して知識をローカ
ルに、比較的簡単に追加することができる。また、蓄積
されたユーザの経験をシステムに取り入れることがで
き、ジェネレータは、テスト・プロセスの展開をたどる
ことができる。モデルをベースにしたテスト生成法で
は、複雑なテスト知識のこのシステムへの組込みが可能
になる。モデルはこのように、アーキテクチャの定義と
重要なテスト・ケースを生成する方法の記述の両方に用
いることができる。更にまた、あるアーキテクチャ及び
設計から別のアーキテクチャ、設計にテスト知識を移行
することもできる。
【００２９】本発明のアプローチには、前記の他に次の
ような利点がある。すなわち、このアプローチは、設計
の部分しか使用できない初期のプロセッサ開発段階で利
用できる。また生成機構とモデリングを、グラフィック
・エンジン、Ｉ／Ｏコントローラ等の従来型ではないプ
ロセッサのためのジェネレータを開発する時に使用でき
る。
ような利点がある。すなわち、このアプローチは、設計
の部分しか使用できない初期のプロセッサ開発段階で利
用できる。また生成機構とモデリングを、グラフィック
・エンジン、Ｉ／Ｏコントローラ等の従来型ではないプ
ロセッサのためのジェネレータを開発する時に使用でき
る。
【００３０】
【実施例】図１を参照する。このシステムは、アーキテ
クチャ・モデル１０、アーキテクチャ・シミュレータ２
０、アーキテクチャ独立型ジェネレータ３０、及びユー
ザ・インタフェース４０を含む。ジェネレータ３０とユ
ーザ・インタフェース４０はＣで実現され、それぞれの
コードは約３万行に及ぶ。
クチャ・モデル１０、アーキテクチャ・シミュレータ２
０、アーキテクチャ独立型ジェネレータ３０、及びユー
ザ・インタフェース４０を含む。ジェネレータ３０とユ
ーザ・インタフェース４０はＣで実現され、それぞれの
コードは約３万行に及ぶ。
【００３１】アーキテクチャ・モデル１０は、下記の命
令、リソース及びデータ型の仕様を格納する。この情報
はクラスの階層が設計されたオブジェクト指向データベ
ースに格納される。命令、オペランド、フィールド、リ
ソース、データ型、生成関数及び検査関数それぞれのク
ラスが定義される。クラスについて定義される属性は、
各オブジェクトのデータと異なるクラスのオブジェクト
の関係を保持する。Ｃで書かれた生成関数と検査関数
は、アーキテクチャとテスト知識の手続き面を表わす。
命令のオペランドとフィールドを表わす関数及び命令の
ツリー（後述）の他に、アーキテクチャに関する他の側
面もデータベース内にモデル化される。データベースの
クラス階層は図２に示した通りである。
令、リソース及びデータ型の仕様を格納する。この情報
はクラスの階層が設計されたオブジェクト指向データベ
ースに格納される。命令、オペランド、フィールド、リ
ソース、データ型、生成関数及び検査関数それぞれのク
ラスが定義される。クラスについて定義される属性は、
各オブジェクトのデータと異なるクラスのオブジェクト
の関係を保持する。Ｃで書かれた生成関数と検査関数
は、アーキテクチャとテスト知識の手続き面を表わす。
命令のオペランドとフィールドを表わす関数及び命令の
ツリー（後述）の他に、アーキテクチャに関する他の側
面もデータベース内にモデル化される。データベースの
クラス階層は図２に示した通りである。
【００３２】生成関数の定義により生成プロセス時に、
テスト知識をモデルに組込み、ユーザがテスト知識のア
プリケーションを制御することができる。生成関数オブ
ジェクトは、関数の入力と出力のパラメータの仕様を含
む。入力パラメータの値の組合わせは、関数が表わすテ
スト知識の要素に対応する。
テスト知識をモデルに組込み、ユーザがテスト知識のア
プリケーションを制御することができる。生成関数オブ
ジェクトは、関数の入力と出力のパラメータの仕様を含
む。入力パラメータの値の組合わせは、関数が表わすテ
スト知識の要素に対応する。
【００３３】データベースの記入は、例えばアーキテク
チャに詳しい人が行なえる。非公式のアーキテクチャ仕
様は、アーキテクチャ・モデルのソースとして用いられ
る。テスト知識は、例えば、データベース管理者が書込
むか、或いはモデル方式に詳しいテスト・エンジニアが
試すこともできる。
チャに詳しい人が行なえる。非公式のアーキテクチャ仕
様は、アーキテクチャ・モデルのソースとして用いられ
る。テスト知識は、例えば、データベース管理者が書込
むか、或いはモデル方式に詳しいテスト・エンジニアが
試すこともできる。
【００３４】ユーザ・インタフェースとテスト・ジェネ
レータに必要なデータは、抽出プログラム５０によって
検索される。抽出プログラム論理５０は、データをジェ
ネレータとユーザ・インタフェースによって用いられる
内部データ構造に変換する。また、データベースの有効
性をチェックして、足りないデータや一貫性のないデー
タをレポートする。このレポートはデータベース管理者
によってデータベースに記入する時に用いられる。
レータに必要なデータは、抽出プログラム５０によって
検索される。抽出プログラム論理５０は、データをジェ
ネレータとユーザ・インタフェースによって用いられる
内部データ構造に変換する。また、データベースの有効
性をチェックして、足りないデータや一貫性のないデー
タをレポートする。このレポートはデータベース管理者
によってデータベースに記入する時に用いられる。
【００３５】システムは独立した適切なアーキテクチャ
・シミュレータ２０を使用する。このようなシミュレー
タは、一般にはソフトウェアの開発を目的に、プロセッ
サがハードウェアとして使用できるようになる前に設計
される。例えば、オペレーティング・システムや言語コ
ンパイラの開発にシミュレータが用いられる。このよう
なアーキテクチャ・シミュレータは普通、高級言語のコ
ードが２万行乃至５万行にのぼる。シミュレータとジェ
ネレータとの間のインタフェースは、レジスタやメモリ
にアクセスするための手続き、単一命令を実行して、変
更されたリソースのリストを与える手続き、及び命令実
行効果をアンドゥする機能から成る。
・シミュレータ２０を使用する。このようなシミュレー
タは、一般にはソフトウェアの開発を目的に、プロセッ
サがハードウェアとして使用できるようになる前に設計
される。例えば、オペレーティング・システムや言語コ
ンパイラの開発にシミュレータが用いられる。このよう
なアーキテクチャ・シミュレータは普通、高級言語のコ
ードが２万行乃至５万行にのぼる。シミュレータとジェ
ネレータとの間のインタフェースは、レジスタやメモリ
にアクセスするための手続き、単一命令を実行して、変
更されたリソースのリストを与える手続き、及び命令実
行効果をアンドゥする機能から成る。
【００３６】ユーザは Motifベースのユーザ・インタフ
ェース４０により、生成プロセスを広範囲に制御するこ
とができる。各テストの命令数を決定し、リソースを初
期化できる他に、３つの生成レベル、「グローバル」、
「ローカル」、「特定」を指示することができる。これ
らのレベルは、それによって得られる制御の範囲によっ
て特徴づけられる。「グローバル」の選択は生成プロセ
ス全体に関連する。「ローカル」の選択は、命令が生成
された時は常にその全てのインスタンスに適用される。
「特定」レベルの選択は、生成された命令の特定のイン
スタンスに関連する。
ェース４０により、生成プロセスを広範囲に制御するこ
とができる。各テストの命令数を決定し、リソースを初
期化できる他に、３つの生成レベル、「グローバル」、
「ローカル」、「特定」を指示することができる。これ
らのレベルは、それによって得られる制御の範囲によっ
て特徴づけられる。「グローバル」の選択は生成プロセ
ス全体に関連する。「ローカル」の選択は、命令が生成
された時は常にその全てのインスタンスに適用される。
「特定」レベルの選択は、生成された命令の特定のイン
スタンスに関連する。
【００３７】ジェネレータ３０は、ユーザによる多くの
指示内容を生成関数とその入力パラメータの値の選択と
解釈する。これによりユーザは、生成手続き（後述）で
起動された生成関数を制御する。
指示内容を生成関数とその入力パラメータの値の選択と
解釈する。これによりユーザは、生成手続き（後述）で
起動された生成関数を制御する。
【００３８】ユーザはグローバル・レベルでは、リソー
スの割当て方式を選択し、生成される命令をマーキング
し、選択された割込みを有効にし、データが必要な時は
常に用いられるデータ型に生成関数を割当てる。ローカ
ル・レベルでは、ユーザは命令ツリーの経路に従う多く
のセマンティクスの選択を提示される。命令レベルに
は、割込み、条件コード及び特別な目的の結果を考慮し
た生成関数が含まれる。データとアドレスの生成関数は
オペランド・レベルに追加される。
スの割当て方式を選択し、生成される命令をマーキング
し、選択された割込みを有効にし、データが必要な時は
常に用いられるデータ型に生成関数を割当てる。ローカ
ル・レベルでは、ユーザは命令ツリーの経路に従う多く
のセマンティクスの選択を提示される。命令レベルに
は、割込み、条件コード及び特別な目的の結果を考慮し
た生成関数が含まれる。データとアドレスの生成関数は
オペランド・レベルに追加される。
【００３９】特定レベルは特殊な生成モードを成すもの
で、ユーザはこのレベルで、命令の特定のシーケンスを
関連する選択と共に定義することができる。このシーケ
ンスはジェネレータによってたどられ、対応するテスト
が生成される。シーケンスの各命令には、ローカル・レ
ベルのセマンティクス選択の上位群が個別に用意され
る。これには各オペランドの長さ、アドレス、データ・
インスタンス等に対する値の設定が含まれる。また、シ
ンタックスの選択、命令のフィールドへの値の割当ても
可能である。特定レベルにより、目的の細目を指定せず
に、実際にテストのシナリオを書込むことができる。シ
ナリオは他のレベルでの選択内容に応じて、ツールの不
規則性によって完成される。
で、ユーザはこのレベルで、命令の特定のシーケンスを
関連する選択と共に定義することができる。このシーケ
ンスはジェネレータによってたどられ、対応するテスト
が生成される。シーケンスの各命令には、ローカル・レ
ベルのセマンティクス選択の上位群が個別に用意され
る。これには各オペランドの長さ、アドレス、データ・
インスタンス等に対する値の設定が含まれる。また、シ
ンタックスの選択、命令のフィールドへの値の割当ても
可能である。特定レベルにより、目的の細目を指定せず
に、実際にテストのシナリオを書込むことができる。シ
ナリオは他のレベルでの選択内容に応じて、ツールの不
規則性によって完成される。
【００４０】テスト・ジェネレータ３０は、複数のテス
ト・プログラムを含むテスト・ファイルを作成する。後
述するように、各プログラムは個別に生成され、単一命
令ジェネレータを繰返し使用する。またプログラムが生
成される際には、複雑な全体制御が行なわれ、いくつか
のモジュールが用いられる。例えば次の通りである。ユ
ーザ・インタフェースから受取られたユーザの選択は、
命令ジェネレータによって用いられるデータ構造に組込
まれる。アーキテクチャ・シミュレータは、リソースの
初期化、命令のシミュレーション、及び予測結果の取得
に用いられる。プログラム・ジェネレータが、生成され
た命令要素を無視できるように、バックトラッキング支
援メカニズムが用いられる。生成関数を使用する、生成
された命令についての情報を得る、ランダム選択を行な
う、アーキテクチャ・リソースにアクセスする等のため
にルーチン群を利用できる。
ト・プログラムを含むテスト・ファイルを作成する。後
述するように、各プログラムは個別に生成され、単一命
令ジェネレータを繰返し使用する。またプログラムが生
成される際には、複雑な全体制御が行なわれ、いくつか
のモジュールが用いられる。例えば次の通りである。ユ
ーザ・インタフェースから受取られたユーザの選択は、
命令ジェネレータによって用いられるデータ構造に組込
まれる。アーキテクチャ・シミュレータは、リソースの
初期化、命令のシミュレーション、及び予測結果の取得
に用いられる。プログラム・ジェネレータが、生成され
た命令要素を無視できるように、バックトラッキング支
援メカニズムが用いられる。生成関数を使用する、生成
された命令についての情報を得る、ランダム選択を行な
う、アーキテクチャ・リソースにアクセスする等のため
にルーチン群を利用できる。
【００４１】図３にテスト・ジェネレータ３０の構造を
示す。これは生成機構制御論理６０を含む。生成関数７
０と検査関数８０は、インヴォーカ９０を通して生成機
構制御論理６０によって起動される。生成機構の制御は
３つの制約ソルバ（アドレス用１００、長さ用１１０、
データ用）を含む。データの制約はわずかなので、この
データ制約ソルバはデータ・ジェネレータ１２０と呼ば
れる。
示す。これは生成機構制御論理６０を含む。生成関数７
０と検査関数８０は、インヴォーカ９０を通して生成機
構制御論理６０によって起動される。生成機構の制御は
３つの制約ソルバ（アドレス用１００、長さ用１１０、
データ用）を含む。データの制約はわずかなので、この
データ制約ソルバはデータ・ジェネレータ１２０と呼ば
れる。
【００４２】リソース・マネージャとアロケータ１３０
は、リソースの状態とその割当てを管理する。これは図
３に示した３つの主要素、レジスタ・モデリング
（Ｒ）、メモリ・モデリング（Ｍ）、属性メカニズム
（Ａ）を含む。アドレス制約ソルバ１００と長さ制約ソ
ルバ１１０はリソース・マネージャ１３０と通信する。
は、リソースの状態とその割当てを管理する。これは図
３に示した３つの主要素、レジスタ・モデリング
（Ｒ）、メモリ・モデリング（Ｍ）、属性メカニズム
（Ａ）を含む。アドレス制約ソルバ１００と長さ制約ソ
ルバ１１０はリソース・マネージャ１３０と通信する。
【００４３】以下、リソース・マネージャと制約ソルバ
の動作について説明する。
の動作について説明する。
【００４４】リソース・マネージャは、レジスタとメモ
リについての情報を維持する。この情報はユーザが指定
するか、または内部の割当て方式と共にリソースの割当
てに用いられる。
リについての情報を維持する。この情報はユーザが指定
するか、または内部の割当て方式と共にリソースの割当
てに用いられる。
【００４５】リソース・マネージャ１３０は静的情報と
動的情報を保持する。レジスタの場合、静的情報はレジ
スタの空間関係を含む。すなわちレジスタは、別のレジ
スタの１部と同義であってよく、ユーザによって選択さ
れた割当て法（新レジスタを使用する、最後の命令のタ
ーゲットであったレジスタを使用する等）と同義であっ
てもよい。レジスタ用に維持される動的情報は、レジス
タの用法を表わす一連の属性である（初期化済み、最後
の命令のターゲット、結果等）。静的情報も動的情報も
レジスタ割当てインスタンスに応答する時に、レジスタ
・アロケータによって用いられ、目的の方式が有効にな
る。命令ジェネレータは、１つのレジスタまたはレジス
タ群の使用を要求することができる。
動的情報を保持する。レジスタの場合、静的情報はレジ
スタの空間関係を含む。すなわちレジスタは、別のレジ
スタの１部と同義であってよく、ユーザによって選択さ
れた割当て法（新レジスタを使用する、最後の命令のタ
ーゲットであったレジスタを使用する等）と同義であっ
てもよい。レジスタ用に維持される動的情報は、レジス
タの用法を表わす一連の属性である（初期化済み、最後
の命令のターゲット、結果等）。静的情報も動的情報も
レジスタ割当てインスタンスに応答する時に、レジスタ
・アロケータによって用いられ、目的の方式が有効にな
る。命令ジェネレータは、１つのレジスタまたはレジス
タ群の使用を要求することができる。
【００４６】メモリは命令とデータに可能なアドレス範
囲によって、また、NEW、USED-IN-RECENT-ACCESSES 等
の選択されたメモリ割当て法によって特徴づけられる。
情報は、動的には関連するメモリの相当な大きさを考慮
して、テスト・プログラムのメモリ使用状況について保
持される。
囲によって、また、NEW、USED-IN-RECENT-ACCESSES 等
の選択されたメモリ割当て法によって特徴づけられる。
情報は、動的には関連するメモリの相当な大きさを考慮
して、テスト・プログラムのメモリ使用状況について保
持される。
【００４７】ジェネレータによるメモリ割当て要求に答
えるには、目的のメモリ・セグメントの特性を考慮しな
ければならない。つまり所要長、メモリのタイプ、使用
目的（すなわちソースかターゲットか）、アラインメン
ト条件及び複雑な制限、特に、あるベース・アドレスに
対する範囲の要求がある。
えるには、目的のメモリ・セグメントの特性を考慮しな
ければならない。つまり所要長、メモリのタイプ、使用
目的（すなわちソースかターゲットか）、アラインメン
ト条件及び複雑な制限、特に、あるベース・アドレスに
対する範囲の要求がある。
【００４８】特別に重視されるのは自動テスト生成の効
率である。そのため命令ジェネレータの設計では、命令
ジェネレータを効率化するための工夫が施されている。
制約ソルバは長さとアドレスの式によって指定された命
令ツリーのリーフの値の関係に違反することによる余計
なバックトラッキングをなくすために用いられる。ソル
バは命令ツリー内の対応する内部ノードにおいて起動さ
れ、同時に関係違反が起きないようにリーフに値を割当
てる。
率である。そのため命令ジェネレータの設計では、命令
ジェネレータを効率化するための工夫が施されている。
制約ソルバは長さとアドレスの式によって指定された命
令ツリーのリーフの値の関係に違反することによる余計
なバックトラッキングをなくすために用いられる。ソル
バは命令ツリー内の対応する内部ノードにおいて起動さ
れ、同時に関係違反が起きないようにリーフに値を割当
てる。
【００４９】ソルバはそれぞれ、専ら、式言語の特定の
サブセットを解決くために用いられる。ソルバは関連す
るユーザ選択、マシン状態及びアーキテクチャのモデル
からのデータに対処しなければならない。例えば、式、
ADDRESS=CONTENTS（REGISTER（B2））+VALUE（D2）（下
記のAdd-Word命令ツリー内の式）を解く場合には、レジ
スタ・インデックス、そのレジスタの内容、変位フィー
ルドが、このアドレス式が満足されるように選択され
る。このソルバは、シンタックスの性質についてのユー
ザ選択（すなわち変位とレジスタ・インデックスのフィ
ールドの値）と、セマンティクスの性質についての選択
（すなわちアドレスとそこに置かれるデータ）を考慮す
る。更にソルバは、関連するリソースの状態（レジスタ
とメモリ位置）と、変位データ型の定義を考慮しなけれ
ばならない。
サブセットを解決くために用いられる。ソルバは関連す
るユーザ選択、マシン状態及びアーキテクチャのモデル
からのデータに対処しなければならない。例えば、式、
ADDRESS=CONTENTS（REGISTER（B2））+VALUE（D2）（下
記のAdd-Word命令ツリー内の式）を解く場合には、レジ
スタ・インデックス、そのレジスタの内容、変位フィー
ルドが、このアドレス式が満足されるように選択され
る。このソルバは、シンタックスの性質についてのユー
ザ選択（すなわち変位とレジスタ・インデックスのフィ
ールドの値）と、セマンティクスの性質についての選択
（すなわちアドレスとそこに置かれるデータ）を考慮す
る。更にソルバは、関連するリソースの状態（レジスタ
とメモリ位置）と、変位データ型の定義を考慮しなけれ
ばならない。
【００５０】検査タスク: 検査タスクについては、２つの領域（domains） の用語
を用いて説明する。１つは、オペランド、命令、命令シ
ーケンスの領域で演算領域と呼ばれる。もう１つは、リ
ソースと関数ユニット（レジスタ、メモリ、アドレス変
換、キャッシュ、パイプライン等）を含むハードウェア
機構の領域である。タスクによっては、演算領域の属性
や要素のインスタンスが指定され、他のタスクでは、関
数ユニットに関係するリソースや特殊イベントと、演算
領域の要素が関連づけられる（後述）。検査タスクの記
述には、サブタスクに対する基本演算子として数え上げ
と組合わせが用いられる。例えば、サブタスクはアライ
ンメント条件でもあり、組合わせは両方のオペランドの
アラインメント条件になり、数え上げでは、オペランド
をテストするには全てのアラインメントを必要とする。
以下、演算領域の要素に従って説明を分け、オペラン
ド、命令、命令のシーケンスの順に説明する。
を用いて説明する。１つは、オペランド、命令、命令シ
ーケンスの領域で演算領域と呼ばれる。もう１つは、リ
ソースと関数ユニット（レジスタ、メモリ、アドレス変
換、キャッシュ、パイプライン等）を含むハードウェア
機構の領域である。タスクによっては、演算領域の属性
や要素のインスタンスが指定され、他のタスクでは、関
数ユニットに関係するリソースや特殊イベントと、演算
領域の要素が関連づけられる（後述）。検査タスクの記
述には、サブタスクに対する基本演算子として数え上げ
と組合わせが用いられる。例えば、サブタスクはアライ
ンメント条件でもあり、組合わせは両方のオペランドの
アラインメント条件になり、数え上げでは、オペランド
をテストするには全てのアラインメントを必要とする。
以下、演算領域の要素に従って説明を分け、オペラン
ド、命令、命令のシーケンスの順に説明する。
【００５１】オペランドのタスクは、データ、アドレス
またはオペランドの長さに関連する。これの典型を次の
タスクで示す。 ・オペランドの可能な長さを全て使用する。 ・ページ境界に一致するか、ページ境界をまたぐオペラ
ンド・アドレスにアクセスする。 ・ページ・フォルトになるようにオペランド・アドレス
にアクセスする。 ・キャッシュ・ヒットになるようにオペランド・アドレ
スにアクセスする。 ・キャッシュ・ミスになるようにキャッシュ行末で終わ
るオペランドにアクセスする。 ・特定のデータ値（ZERO、MINIMUM、MAXIMUM等）を使用
する。 ・例外となる無効なデータ値（１０進オペランドの非１
０進値等）を使用する。
またはオペランドの長さに関連する。これの典型を次の
タスクで示す。 ・オペランドの可能な長さを全て使用する。 ・ページ境界に一致するか、ページ境界をまたぐオペラ
ンド・アドレスにアクセスする。 ・ページ・フォルトになるようにオペランド・アドレス
にアクセスする。 ・キャッシュ・ヒットになるようにオペランド・アドレ
スにアクセスする。 ・キャッシュ・ミスになるようにキャッシュ行末で終わ
るオペランドにアクセスする。 ・特定のデータ値（ZERO、MINIMUM、MAXIMUM等）を使用
する。 ・例外となる無効なデータ値（１０進オペランドの非１
０進値等）を使用する。
【００５２】命令タスクの特徴はオペランドの組合わせ
を指定することにある。指定は、組合わせ群を暗示的に
記述するか、明示的にオペランドそれぞれに制限を加え
ることができる。
を指定することにある。指定は、組合わせ群を暗示的に
記述するか、明示的にオペランドそれぞれに制限を加え
ることができる。
【００５３】暗示的指定は、命令の実行によって生じる
例外条件にか、または計算される特殊な重要度の結果に
関連する。例外の場合にはしばしばプログラム割込みが
起こる。結果によっては、「条件コード」ビットがセッ
トされる。つまり命令の検査タスクはほとんど、例外、
条件コード及び他の特殊な結果に関連し、これらのイベ
ントの発生を要する。
例外条件にか、または計算される特殊な重要度の結果に
関連する。例外の場合にはしばしばプログラム割込みが
起こる。結果によっては、「条件コード」ビットがセッ
トされる。つまり命令の検査タスクはほとんど、例外、
条件コード及び他の特殊な結果に関連し、これらのイベ
ントの発生を要する。
【００５４】更に命令検査タスク群は、いわゆる例外パ
スと非例外パスのサブセットに分けられる。以下このよ
うなタスクの例を示す。 ・０例外によって除算を起こす。 ・無効な格納オペランド・オーバラップ例外を起こす。 ・全ての条件コード・ビットをセットする。 ・可能なMAXIMAL 値に等しい結果を計算する（例外また
は条件コードはセットされない）。
スと非例外パスのサブセットに分けられる。以下このよ
うなタスクの例を示す。 ・０例外によって除算を起こす。 ・無効な格納オペランド・オーバラップ例外を起こす。 ・全ての条件コード・ビットをセットする。 ・可能なMAXIMAL 値に等しい結果を計算する（例外また
は条件コードはセットされない）。
【００５５】オペランドの関係の明示的指定は主に２つ
のソースから導かれる。命令要素とハードウェア領域の
関係、及び命令に組込まれる演算子のセマンティクスで
ある。このような指定の例を以下に示す。 ・オペランドのデータに与えられた値の組を使用する。 ・値１を除算命令の除数に使用する。 ・２つのオペランドのアラインメントの組合わせを全て
使用する。 ・特定のオペランド長関係（Ｌ１＞Ｌ２、Ｌ１＝Ｌ２
等）を使用する。 ・特定のオペランド長関係と各種データ値（Ｌ１＞Ｌ２
等）及び第２オペランドより小さい第１オペランドのデ
ータを使用する。 ・特定の記憶パーティション境界でオーバラップするオ
ペランド、すなわち共通記憶域を持つオペランドを使用
する。
のソースから導かれる。命令要素とハードウェア領域の
関係、及び命令に組込まれる演算子のセマンティクスで
ある。このような指定の例を以下に示す。 ・オペランドのデータに与えられた値の組を使用する。 ・値１を除算命令の除数に使用する。 ・２つのオペランドのアラインメントの組合わせを全て
使用する。 ・特定のオペランド長関係（Ｌ１＞Ｌ２、Ｌ１＝Ｌ２
等）を使用する。 ・特定のオペランド長関係と各種データ値（Ｌ１＞Ｌ２
等）及び第２オペランドより小さい第１オペランドのデ
ータを使用する。 ・特定の記憶パーティション境界でオーバラップするオ
ペランド、すなわち共通記憶域を持つオペランドを使用
する。
【００５６】シーケンス検査タスクは、通常、２つか３
つの短い命令シーケンスを指定する。タスクは関係する
命令を出来るだけ少なく指定できるが、命令の関係は深
くしなければならない場合がある。
つの短い命令シーケンスを指定する。タスクは関係する
命令を出来るだけ少なく指定できるが、命令の関係は深
くしなければならない場合がある。
【００５７】このような関係は、命令を並列実行するハ
ードウェア領域要素（パイプライン・メカニズム等）か
ら、または複数の計算ユニットから生じる。これらのタ
スクでは、並列実行される演算においてリソースを共有
しなければならないことが多い。例えば、浮動小数点命
令は他の命令と同時に実行することができる。ＡＬＵを
使用する浮動小数点命令は、それを使用しない他の浮動
小数点命令と並列に実行することができる。
ードウェア領域要素（パイプライン・メカニズム等）か
ら、または複数の計算ユニットから生じる。これらのタ
スクでは、並列実行される演算においてリソースを共有
しなければならないことが多い。例えば、浮動小数点命
令は他の命令と同時に実行することができる。ＡＬＵを
使用する浮動小数点命令は、それを使用しない他の浮動
小数点命令と並列に実行することができる。
【００５８】以下に、サイズが２のシーケンスの代表例
を示す（'inst1'、'inst2'）。 ・他の命令に続く全ての命令。 ・'inst1'にレジスタをロードし、その値を使用して'in
st2'の記憶域にアクセスする。 ・'inst1'と'inst2'の両方が、単一ＡＬＵを使用する浮
動小数点命令。 ・'inst1'がページ境界で終わり、次ページが非常駐、
すなわち'inst2'をプリフェッチしてページ・フォルト
になる。 ・'inst2'が分岐命令で、'inst1'によって生じる条件に
より、分岐の実行のタイミングが乱れる。
を示す（'inst1'、'inst2'）。 ・他の命令に続く全ての命令。 ・'inst1'にレジスタをロードし、その値を使用して'in
st2'の記憶域にアクセスする。 ・'inst1'と'inst2'の両方が、単一ＡＬＵを使用する浮
動小数点命令。 ・'inst1'がページ境界で終わり、次ページが非常駐、
すなわち'inst2'をプリフェッチしてページ・フォルト
になる。 ・'inst2'が分岐命令で、'inst1'によって生じる条件に
より、分岐の実行のタイミングが乱れる。
【００５９】短いシーケンスは命令間の短い相互依存チ
ェーンを密閉する。長いシーケンスの検査タスクは、そ
れが必要とする相互依存チェーンの長さに従って分類す
ることができる。短い相互依存チェーンを持つ長いシー
ケンスは、実際には上述の短いシーケンスの延長であ
る。長い相互依存チェーンを持つ長いシーケンスは、複
雑な検査タスクに必要である。このようなタスクは入力
／出力、マルチタスク等に関係し、独立したタスクのク
ラスとみなされる。例えばＩ／Ｏ検査タスクは、演算を
初期化する命令、Ｉ／Ｏ命令それ自体及び関係するファ
シリティの内容が検査される前に演算が完了するように
する遅延時間から成る。
ェーンを密閉する。長いシーケンスの検査タスクは、そ
れが必要とする相互依存チェーンの長さに従って分類す
ることができる。短い相互依存チェーンを持つ長いシー
ケンスは、実際には上述の短いシーケンスの延長であ
る。長い相互依存チェーンを持つ長いシーケンスは、複
雑な検査タスクに必要である。このようなタスクは入力
／出力、マルチタスク等に関係し、独立したタスクのク
ラスとみなされる。例えばＩ／Ｏ検査タスクは、演算を
初期化する命令、Ｉ／Ｏ命令それ自体及び関係するファ
シリティの内容が検査される前に演算が完了するように
する遅延時間から成る。
【００６０】テスト・プログラムは、それに組込まれた
相互依存性の複雑さに従って分類することができる。こ
のような依存性は、複雑さが増す方向に順序づけること
ができる。つまりオペランド内、オペランド間及び命令
間である。後者はまた、短いシーケンスと長いシーケン
スとして順序づけられる。つまり、テスト知識を考慮す
れば、テストに含まれる依存性の複雑さにより、テスト
自体の複雑さが決定される。
相互依存性の複雑さに従って分類することができる。こ
のような依存性は、複雑さが増す方向に順序づけること
ができる。つまりオペランド内、オペランド間及び命令
間である。後者はまた、短いシーケンスと長いシーケン
スとして順序づけられる。つまり、テスト知識を考慮す
れば、テストに含まれる依存性の複雑さにより、テスト
自体の複雑さが決定される。
【００６１】上述の検査タスクは、リソースと命令をモ
デル化する必要があることを示す。検査タスクの多く
は、項をオペランドのアドレスとして、また命令によっ
て行なわれる計算の異なる側面に関連する項を使用す
る。従って命令は、シンタックス的にではなくセマンテ
ィックにモデル化しなければならない。
デル化する必要があることを示す。検査タスクの多く
は、項をオペランドのアドレスとして、また命令によっ
て行なわれる計算の異なる側面に関連する項を使用す
る。従って命令は、シンタックス的にではなくセマンテ
ィックにモデル化しなければならない。
【００６２】タスクはまた、演算領域の要素の重要な属
性を明らかにする。例えば、長さ、アドレス及びデータ
は、オペランドにとって重要である。例外、条件コード
及び特殊結果は命令に関係する。また、オペランドが取
り得るデータ値のデータ型の概念（notion）が暗示され
る。
性を明らかにする。例えば、長さ、アドレス及びデータ
は、オペランドにとって重要である。例外、条件コード
及び特殊結果は命令に関係する。また、オペランドが取
り得るデータ値のデータ型の概念（notion）が暗示され
る。
【００６３】検査タスクは、アーキテクチャ・ブックか
ら異なる特例をテストするように定義される。このよう
な特例の多様なセットのテストを支援するに充分な表現
性は、モデリングによって得られる。つまり、検査タス
ク記述をテスト知識とみなすと、この記述はオープン知
識ベースが得られるようにモデル化される。更に、テス
ト知識は複雑で手続き型であるので、解のオープンネス
と簡素性のトレードオフがある。解はテスト知識の表現
性をある程度まで制限するものである。
ら異なる特例をテストするように定義される。このよう
な特例の多様なセットのテストを支援するに充分な表現
性は、モデリングによって得られる。つまり、検査タス
ク記述をテスト知識とみなすと、この記述はオープン知
識ベースが得られるようにモデル化される。更に、テス
ト知識は複雑で手続き型であるので、解のオープンネス
と簡素性のトレードオフがある。解はテスト知識の表現
性をある程度まで制限するものである。
【００６４】基本的なモデリングと生成： テスト・プログラムは、アーキテクチャのリソースを使
用する命令インスタンスのシーケンスである。ここで
は、リソースと命令の両方のモデル及び基本的な生成機
構について説明する。次節では、モデリングの詳細を詰
め、完全な生成手続きについて述べる。モデルは非公式
に記述される。特に、アドレス、長さ、データの式のセ
マンティクスが記述されるが、正式に定義されることは
なく、オペランド・インスタンスの一貫性は、説明はさ
れるが定義はされない。この２つの節では、命令モデル
の具体例を示し、命令インスタンスの生成について述べ
る。
用する命令インスタンスのシーケンスである。ここで
は、リソースと命令の両方のモデル及び基本的な生成機
構について説明する。次節では、モデリングの詳細を詰
め、完全な生成手続きについて述べる。モデルは非公式
に記述される。特に、アドレス、長さ、データの式のセ
マンティクスが記述されるが、正式に定義されることは
なく、オペランド・インスタンスの一貫性は、説明はさ
れるが定義はされない。この２つの節では、命令モデル
の具体例を示し、命令インスタンスの生成について述べ
る。
【００６５】１.リソース メモリとレジスタのリソースは、ＩＳＰＳメモリ宣言に
よって記述される。このような宣言については、M．R．
BarbacciによるAn Introduction toInstruction-Set Pr
ocessor Specification、in 'Computer Structures： Principles and Examples'、by D．P．Siewiorek、C．
G．Bell、A．Newell、McGraw-Hill、 １９８２年を参照
されたい。メモリ名、メモリ・セルのサイズ及びアドレ
ス範囲が含まれる。メモリ・リソースは複数可能であ
る。 定義：「リソース」は、NAME［LOWER ADDRESS：UPPER A
DDRESS］＜LOWER-BIT：UPPER-BIT＞の５重項である。リ
ソースNAMEの「アドレス」は［LOWER ADDRESS、UPPER-A
DDRESS］の範囲内の整数である。例えば主メモリは、次
のように２48個のアドレス可能バイトとすることができ
る。 Main-Memory［0x000000000000：0xFFFFFFFFFFFF］＜0：7＞ １６進数の前に０ｘがある。ＩＢＭアーキテクチャで
は、ビット・インデックスが左から右へマーキングされ
る（例えば０から７へ）。ワード・レジスタ（第２例）
は、次のように４バイトの記憶ユニットが１６個の配列
とすることができる。 Word-Register［0：15］＜0：31＞ リソースは互いにオーバラップさせることができる。こ
の関係は、プロセッサ仕様の１部とみなされ、アーキテ
クチャをテストする際に考慮される。リソースのオーバ
ラップは、ＩＳＰＳに従って、１組のリソース宣言によ
って定義される。例えば次のように、ワード・レジスタ
上にハーフワード・レジスタを定義できる。 Halfword-Register［0：15］＜0：15＞：=Word-Register［0：15］＜16：31＞
よって記述される。このような宣言については、M．R．
BarbacciによるAn Introduction toInstruction-Set Pr
ocessor Specification、in 'Computer Structures： Principles and Examples'、by D．P．Siewiorek、C．
G．Bell、A．Newell、McGraw-Hill、 １９８２年を参照
されたい。メモリ名、メモリ・セルのサイズ及びアドレ
ス範囲が含まれる。メモリ・リソースは複数可能であ
る。 定義：「リソース」は、NAME［LOWER ADDRESS：UPPER A
DDRESS］＜LOWER-BIT：UPPER-BIT＞の５重項である。リ
ソースNAMEの「アドレス」は［LOWER ADDRESS、UPPER-A
DDRESS］の範囲内の整数である。例えば主メモリは、次
のように２48個のアドレス可能バイトとすることができ
る。 Main-Memory［0x000000000000：0xFFFFFFFFFFFF］＜0：7＞ １６進数の前に０ｘがある。ＩＢＭアーキテクチャで
は、ビット・インデックスが左から右へマーキングされ
る（例えば０から７へ）。ワード・レジスタ（第２例）
は、次のように４バイトの記憶ユニットが１６個の配列
とすることができる。 Word-Register［0：15］＜0：31＞ リソースは互いにオーバラップさせることができる。こ
の関係は、プロセッサ仕様の１部とみなされ、アーキテ
クチャをテストする際に考慮される。リソースのオーバ
ラップは、ＩＳＰＳに従って、１組のリソース宣言によ
って定義される。例えば次のように、ワード・レジスタ
上にハーフワード・レジスタを定義できる。 Halfword-Register［0：15］＜0：15＞：=Word-Register［0：15］＜16：31＞
【００６６】２．命令 命令はプロセッサ・アーキテクチャのセマンティック・
レベルでツリーとしてモデル化される。ただし、この実
施例は、ＣＩＳＣ（Complex InstructionsSets Compute
rs）の自動テスト生成を目指しているので、ツリーを更
に洗練する必要がある。命令は、ルートにフォーマット
とセマンティック・プロシジャを、内部ノードとしてオ
ペランドとサブオペランドを、リーフとしてアドレスと
データの式を持つツリーにより記述される。
レベルでツリーとしてモデル化される。ただし、この実
施例は、ＣＩＳＣ（Complex InstructionsSets Compute
rs）の自動テスト生成を目指しているので、ツリーを更
に洗練する必要がある。命令は、ルートにフォーマット
とセマンティック・プロシジャを、内部ノードとしてオ
ペランドとサブオペランドを、リーフとしてアドレスと
データの式を持つツリーにより記述される。
【００６７】以下は、命令モデルの非公式なボトム・ア
ップ記述である。一意のリテラル群（または識別子）が
想定される。リテラルはフィールドとデータ型の名前と
して、またフィールド値を指示するために用いられる。 定義：「フィールド」は＜NAME、VALUES、REGISTER＞の
３重項であり、NAMEはリテラル（フィールドの名前と呼
ばれる）、VALUESはリテラル群、REGISTERは予約済みリ
テラルNONEまたはレジスタ名（前記の定義参照）であ
る。「フォーマット」はフィールド名の有限集合であ
る。フォーマットをアルファベットとして使用すると、
オペランドに可能なアドレスと長さを表わす２つの言語
は以下のように定義される。 定義：フォーマットＦの「アドレス式」は以下の文法に
よってシンタックス的に記述される。 （１）address-expression：=in-field（field-name1）｜ （２） value（field-name1）｜ （３） register（field-name2）｜ （４） specific-register（register-name、integer）｜ （５） contents（address-expression）｜ （６） address-expression '+' address-expression． 制限： （１）field_name1とfield_name2はＦフォーマット （２）＜field_name1、Values、Register＞でRegisterはNONE （３）＜field_name2、Values、Register＞でRegisterはNONEでない （４）register-nameはリソース名
ップ記述である。一意のリテラル群（または識別子）が
想定される。リテラルはフィールドとデータ型の名前と
して、またフィールド値を指示するために用いられる。 定義：「フィールド」は＜NAME、VALUES、REGISTER＞の
３重項であり、NAMEはリテラル（フィールドの名前と呼
ばれる）、VALUESはリテラル群、REGISTERは予約済みリ
テラルNONEまたはレジスタ名（前記の定義参照）であ
る。「フォーマット」はフィールド名の有限集合であ
る。フォーマットをアルファベットとして使用すると、
オペランドに可能なアドレスと長さを表わす２つの言語
は以下のように定義される。 定義：フォーマットＦの「アドレス式」は以下の文法に
よってシンタックス的に記述される。 （１）address-expression：=in-field（field-name1）｜ （２） value（field-name1）｜ （３） register（field-name2）｜ （４） specific-register（register-name、integer）｜ （５） contents（address-expression）｜ （６） address-expression '+' address-expression． 制限： （１）field_name1とfield_name2はＦフォーマット （２）＜field_name1、Values、Register＞でRegisterはNONE （３）＜field_name2、Values、Register＞でRegisterはNONEでない （４）register-nameはリソース名
【００６８】アドレス式のセマンティック領域は、前記
のように定義されるアドレスから成る。規則（１）は対
応するフィールド（即値フィールドともいう）に直接置
かれるデータを示す。規則（２）はメモリ・アドレスと
解釈されるフィールド値を示す。規則（３）は、レジス
タと解釈されるフィールド値を示す。規則（４）は特定
のレジスタを示す。例えばワード・レジスタ番号９はsp
ecific-register（Word-Register、９）によって指示さ
れる。規則（５）は（内部）address-expressionによっ
て指示されるアドレスの内容を示す。規則（６）のセマ
ンティクスは標準である。 定義：フォーマットＦの「長さ式」は次の文法によって
シンタックス的に記述される。 （１）length-expression：=integer｜ （２） maximum（integer）｜ （３） value（field-name1）｜ （４） contents（address-expression）｜ （５） length-expression '+' length-expression｜ （６） length-expression '*' length-expression． 条件： （１）field_name1はＦフォーマット （２）＜field_name1、Values、Register＞でRegisterはNONE 長さ式のセマンティック領域は正の整数から成る。規則
（１）、（５）、（６）の意味は標準である。規則
（２）は長さが与えられた整数より小さいか等しいこと
を示す。規則（３）は対応するフィールドの値を示す。
規則（４）はaddress-expressionによって指示されるア
ドレスの内容を示す。 定義：「データ式」はデータ型を示すリテラルである。
データ式のセマンティック領域はデータ列であり、この
実施例では２進数か１６進数である。データ型はこのよ
うなデータ列群を、その長さ（固定長か有限の可変長）
と構造によって記述する。アドレス、長さ及びデータ式
は、全体として、当該モデルの基本セマンティック・エ
ンティティであるサブオペランドをモデル化する。サブ
オペランドはオペランドにグループ分けされる。フォー
マット、セマンティック・プロシジャ及びオペランドは
命令モデルを成す。 定義：フォーマットＦの「サブオペランド」は３重項で
あり、Ｆの長さ式、Ｆのアドレス式及びデータ式を保持
する。フォーマットＦの「オペランド」は、Ｆのサブオ
ペランドの有限集合である。セマンティック・プロシジ
ャは、アーキテクチャ・リソースを操作する手続きであ
り、命令によって実行される演算を表わす。「命令ツリ
ー」は３重項であり、フォーマットＦ、セマンティック
・プロシジャ及びＦの有限オペランド群を保持する。
のように定義されるアドレスから成る。規則（１）は対
応するフィールド（即値フィールドともいう）に直接置
かれるデータを示す。規則（２）はメモリ・アドレスと
解釈されるフィールド値を示す。規則（３）は、レジス
タと解釈されるフィールド値を示す。規則（４）は特定
のレジスタを示す。例えばワード・レジスタ番号９はsp
ecific-register（Word-Register、９）によって指示さ
れる。規則（５）は（内部）address-expressionによっ
て指示されるアドレスの内容を示す。規則（６）のセマ
ンティクスは標準である。 定義：フォーマットＦの「長さ式」は次の文法によって
シンタックス的に記述される。 （１）length-expression：=integer｜ （２） maximum（integer）｜ （３） value（field-name1）｜ （４） contents（address-expression）｜ （５） length-expression '+' length-expression｜ （６） length-expression '*' length-expression． 条件： （１）field_name1はＦフォーマット （２）＜field_name1、Values、Register＞でRegisterはNONE 長さ式のセマンティック領域は正の整数から成る。規則
（１）、（５）、（６）の意味は標準である。規則
（２）は長さが与えられた整数より小さいか等しいこと
を示す。規則（３）は対応するフィールドの値を示す。
規則（４）はaddress-expressionによって指示されるア
ドレスの内容を示す。 定義：「データ式」はデータ型を示すリテラルである。
データ式のセマンティック領域はデータ列であり、この
実施例では２進数か１６進数である。データ型はこのよ
うなデータ列群を、その長さ（固定長か有限の可変長）
と構造によって記述する。アドレス、長さ及びデータ式
は、全体として、当該モデルの基本セマンティック・エ
ンティティであるサブオペランドをモデル化する。サブ
オペランドはオペランドにグループ分けされる。フォー
マット、セマンティック・プロシジャ及びオペランドは
命令モデルを成す。 定義：フォーマットＦの「サブオペランド」は３重項で
あり、Ｆの長さ式、Ｆのアドレス式及びデータ式を保持
する。フォーマットＦの「オペランド」は、Ｆのサブオ
ペランドの有限集合である。セマンティック・プロシジ
ャは、アーキテクチャ・リソースを操作する手続きであ
り、命令によって実行される演算を表わす。「命令ツリ
ー」は３重項であり、フォーマットＦ、セマンティック
・プロシジャ及びＦの有限オペランド群を保持する。
【００６９】セマンティック・プロシジャは完全を期し
てここに加えている。実際のシステムでは、セマンティ
ック・プロシジャは独立したアーキテクチャ・レベルの
シミュレータの１部である。サブオペランドとオペラン
ドはセマンティック・エンティティを表わすが、セマン
ティック・プロシジャは命令の実際の意味を表わす。オ
ペランドの関係の表わし方は２通りある。命令の実行結
果は動的関係であり、これはセマンティック・プロシジ
ャによってモデル化される。アドレス、長さ及びデータ
の式によってモデル化されるのは構造関係である。これ
らの関係には、命令の実行前に存在するという特徴があ
る。つまり関係は、テストの自動生成の中心であり、宣
言的にモデル化される。
てここに加えている。実際のシステムでは、セマンティ
ック・プロシジャは独立したアーキテクチャ・レベルの
シミュレータの１部である。サブオペランドとオペラン
ドはセマンティック・エンティティを表わすが、セマン
ティック・プロシジャは命令の実際の意味を表わす。オ
ペランドの関係の表わし方は２通りある。命令の実行結
果は動的関係であり、これはセマンティック・プロシジ
ャによってモデル化される。アドレス、長さ及びデータ
の式によってモデル化されるのは構造関係である。これ
らの関係には、命令の実行前に存在するという特徴があ
る。つまり関係は、テストの自動生成の中心であり、宣
言的にモデル化される。
【００７０】命令の完全なセマンティクスの宣言モデリ
ングは、その複雑さ故に除外されてきた。また、セマン
ティック・エンティティの関係は静的であるが（つまり
変化しない。命令の実行前も実行後も同じである）、セ
マンティクスは動的である（命令の実行の「前」と
「後」について定義しなければならない）。
ングは、その複雑さ故に除外されてきた。また、セマン
ティック・エンティティの関係は静的であるが（つまり
変化しない。命令の実行前も実行後も同じである）、セ
マンティクスは動的である（命令の実行の「前」と
「後」について定義しなければならない）。
【００７１】完全なセマンティクスがモデル化されれ
ば、自動生成は非実用的になるほど複雑になる。ここで
採用されるアプローチでは、有益、有意義なテスト・プ
ログラムを生成するのに充分なパワーが得られると同時
に、ジェネレータとモデルの複雑さが合理的なレベルに
保たれ、有意義なテストの生成に必要な時間が許容限度
内に保たれる。
ば、自動生成は非実用的になるほど複雑になる。ここで
採用されるアプローチでは、有益、有意義なテスト・プ
ログラムを生成するのに充分なパワーが得られると同時
に、ジェネレータとモデルの複雑さが合理的なレベルに
保たれ、有意義なテストの生成に必要な時間が許容限度
内に保たれる。
【００７２】得られる命令モデルは、４レベルのツリー
と見られることから、命令ツリーと呼ばれる。ルート
（第１レベル）は、命令のシンタックス（フォーマッ
ト）とそのセマンティクス（セマンティック・プロシジ
ャ）の両方を含む。内部ノードは命令のセマンティック
要素、つまりツリーの第２レベルのオペランドと、第３
レベルのサブオペランドである。リーフはセマンティッ
ク・エンティティの可能値及びその関係を記述する。こ
れらのリーフ、すなわちアドレス、長さ及びデータの式
がツリーの第４レベルを成す。
と見られることから、命令ツリーと呼ばれる。ルート
（第１レベル）は、命令のシンタックス（フォーマッ
ト）とそのセマンティクス（セマンティック・プロシジ
ャ）の両方を含む。内部ノードは命令のセマンティック
要素、つまりツリーの第２レベルのオペランドと、第３
レベルのサブオペランドである。リーフはセマンティッ
ク・エンティティの可能値及びその関係を記述する。こ
れらのリーフ、すなわちアドレス、長さ及びデータの式
がツリーの第４レベルを成す。
【００７３】３．例：ADD WORD命令ツリー ADD WORDは、代表的なＣＩＳＣアーキテクチャで最も簡
単な命令の１つである。この命令の意味は、非公式には
第２オペランドを第１オペランドに加え、その和を第１
オペランドの位置にセットするものである。命令ツリー
を図４に示す。想定されるリソースは、主メモリ、ベー
ス・レジスタ及びワード・レジスタである。 命令： −セマンティック・プロシジャ：ADD-WORD（）． −フォーマット：AW-OPCODE W1、D2、B2． フィールド： ＜AW-OPCODE、（AW）、None＞、 ＜W1、（0、1、2、．．．、E、F）、Word-Register＞、 ＜D2、（00、01、02、、．．．、FE、FF）、None＞、and ＜B2、（0、1、2、．．．、E、F）、Base-Register＞． この例でセマンティック・エンティティは次の通りであ
る。 １．Word-Register この命令を記述するための記号名
は"Ｗ１"である。"Ｗ１"の可能値は1、2、3、．．．、1
6である。"Word-Register" とは、対象のプロセッサの
リソースの１部としてレジスタ群が定義されているとい
うことである。この群に言及するたびに（リソースを定
義する時も命令を定義する時も）、ここではそれをWord
-Registerと呼ぶ。"Ｗ１"の可能値を1、．．．、16 と
いうのは、このようなレジスタが１６あり、Add Word命
令インスタンスがその１つを選択しなければならないと
いう意味である。
単な命令の１つである。この命令の意味は、非公式には
第２オペランドを第１オペランドに加え、その和を第１
オペランドの位置にセットするものである。命令ツリー
を図４に示す。想定されるリソースは、主メモリ、ベー
ス・レジスタ及びワード・レジスタである。 命令： −セマンティック・プロシジャ：ADD-WORD（）． −フォーマット：AW-OPCODE W1、D2、B2． フィールド： ＜AW-OPCODE、（AW）、None＞、 ＜W1、（0、1、2、．．．、E、F）、Word-Register＞、 ＜D2、（00、01、02、、．．．、FE、FF）、None＞、and ＜B2、（0、1、2、．．．、E、F）、Base-Register＞． この例でセマンティック・エンティティは次の通りであ
る。 １．Word-Register この命令を記述するための記号名
は"Ｗ１"である。"Ｗ１"の可能値は1、2、3、．．．、1
6である。"Word-Register" とは、対象のプロセッサの
リソースの１部としてレジスタ群が定義されているとい
うことである。この群に言及するたびに（リソースを定
義する時も命令を定義する時も）、ここではそれをWord
-Registerと呼ぶ。"Ｗ１"の可能値を1、．．．、16 と
いうのは、このようなレジスタが１６あり、Add Word命
令インスタンスがその１つを選択しなければならないと
いう意味である。
【００７４】エンティティ"Ｗ１"の名前は、Add Word命
令のシンタックスすなわち命令のフォーマットから取ら
れる。 ２．Base-Register この命令を記述するための記号名
は"Ｂ２"である。"Ｂ２" の可能値は1、2、3、．．．、
16 である。 ３．フィールド この命令を記述するための記号名は"
Ｄ２"である。"Ｄ２"の可能値は00、01、02、．．．、F
Fである。「フィールド」とは、このエンティティに対
応するリソースがないことを意味する。命令Add Wordの
インスタンスには、このフィールドに関連する値（00と
FFの間の２つの１６進数）が含まれる。 ４．メモリ内のワード（４バイト）。このエンティティ
は直接は名付けられない（すなわち命令のフォーマット
にこのエンティティをさす項目がない）。セマンティッ
ク・エンティティの関係は次の通りである。このような
関係はAdd Wordに１つしかない。エンティティ番号４は
次のようにエンティティ２、３に関係する。メモリ・ワ
ード（エンティティ４）は、エンティティ２（"Ｂ２"）
の内容プラス、エンティティ３（"Ｄ２"）の値によって
指示される。これはAddress-Expressionで次のように表
わされる。 address_of_entity_4=contents（register（B2））+value（D2） この関係は、命令の実行前及び実行後に存在するもので
ある。Add Word命令のセマンティクスは宣言的にはモデ
ル化されない。そのモデルは命令ツリーのルートに記さ
れるセマンティック・プロシジャADD-WORD（）に記述さ
れるように手続き型である（また、動作シミュレータの
１部でもある）。ADD-WORD命令のセマンティクスの宣言
モデルが命令ツリーに追加される場合は、それは次のよ
うに表わされる。命令実行後のメモリ・ワード（エンテ
ィティ番号４）の内容は、命令実行前のメモリ・ワード
の値プラス、エンティティ１（"Ｗ１"）の内容の和に等
しい。他の全てのエンティティの内容は変更しない。こ
の簡単な例においても、セマンティクスは、エンティテ
ィの関係よりもはるかに複雑である。従ってツリー構造
の下位レベルは次のものを含む。 * 第１オペランド：Add Word命令のソースとターゲット
の両方として用いられる記憶域を表わす −サブオペランド：第１オペランドとして用いられるレ
ジスタをさす * 長さ式：４（すなわちワードは４バイト） * アドレス式：register（W1）（すなわちフィールドＷ
１によって指示されるワード・レジスタ） * データ式：Signed-Binary（すなわちデータ型がSigne
d-Binaryのデータ） * 第２オペランド：Add Word命令のソースとして用いら
れる記憶域を表わす −サブオペランド：第２オペランドとして用いられる実
記憶域を表わす（他のサブオペランドはこのメモリ記憶
ワードのアドレシングに用いられる） * 長さ式：４ * アドレス式：contents（register（B2））+value（D
2）（すなわちメモリ位置は、ベース・レジスタの内容
（フィールドＢ２によって指示される）と変位（フィー
ルドＤ２によって指示される）の和によって指示される * データ式：Signed-Binary −サブオペランド：第２オペランドのアドレシングに用
いられるオフセットを表わす * 長さ式：２ * アドレス式：in-field（D2） * データ式：Displacement-Data-Type −サブオペランド：第２オペランドのアドレシングに用
いられるベース・レジスタを表わす * 長さ式：６ * アドレス式：register（B2）（すなわちフィールドＢ
２によって指示されるベース・レジスタ） * データ式：Address-Data-Type
令のシンタックスすなわち命令のフォーマットから取ら
れる。 ２．Base-Register この命令を記述するための記号名
は"Ｂ２"である。"Ｂ２" の可能値は1、2、3、．．．、
16 である。 ３．フィールド この命令を記述するための記号名は"
Ｄ２"である。"Ｄ２"の可能値は00、01、02、．．．、F
Fである。「フィールド」とは、このエンティティに対
応するリソースがないことを意味する。命令Add Wordの
インスタンスには、このフィールドに関連する値（00と
FFの間の２つの１６進数）が含まれる。 ４．メモリ内のワード（４バイト）。このエンティティ
は直接は名付けられない（すなわち命令のフォーマット
にこのエンティティをさす項目がない）。セマンティッ
ク・エンティティの関係は次の通りである。このような
関係はAdd Wordに１つしかない。エンティティ番号４は
次のようにエンティティ２、３に関係する。メモリ・ワ
ード（エンティティ４）は、エンティティ２（"Ｂ２"）
の内容プラス、エンティティ３（"Ｄ２"）の値によって
指示される。これはAddress-Expressionで次のように表
わされる。 address_of_entity_4=contents（register（B2））+value（D2） この関係は、命令の実行前及び実行後に存在するもので
ある。Add Word命令のセマンティクスは宣言的にはモデ
ル化されない。そのモデルは命令ツリーのルートに記さ
れるセマンティック・プロシジャADD-WORD（）に記述さ
れるように手続き型である（また、動作シミュレータの
１部でもある）。ADD-WORD命令のセマンティクスの宣言
モデルが命令ツリーに追加される場合は、それは次のよ
うに表わされる。命令実行後のメモリ・ワード（エンテ
ィティ番号４）の内容は、命令実行前のメモリ・ワード
の値プラス、エンティティ１（"Ｗ１"）の内容の和に等
しい。他の全てのエンティティの内容は変更しない。こ
の簡単な例においても、セマンティクスは、エンティテ
ィの関係よりもはるかに複雑である。従ってツリー構造
の下位レベルは次のものを含む。 * 第１オペランド：Add Word命令のソースとターゲット
の両方として用いられる記憶域を表わす −サブオペランド：第１オペランドとして用いられるレ
ジスタをさす * 長さ式：４（すなわちワードは４バイト） * アドレス式：register（W1）（すなわちフィールドＷ
１によって指示されるワード・レジスタ） * データ式：Signed-Binary（すなわちデータ型がSigne
d-Binaryのデータ） * 第２オペランド：Add Word命令のソースとして用いら
れる記憶域を表わす −サブオペランド：第２オペランドとして用いられる実
記憶域を表わす（他のサブオペランドはこのメモリ記憶
ワードのアドレシングに用いられる） * 長さ式：４ * アドレス式：contents（register（B2））+value（D
2）（すなわちメモリ位置は、ベース・レジスタの内容
（フィールドＢ２によって指示される）と変位（フィー
ルドＤ２によって指示される）の和によって指示される * データ式：Signed-Binary −サブオペランド：第２オペランドのアドレシングに用
いられるオフセットを表わす * 長さ式：２ * アドレス式：in-field（D2） * データ式：Displacement-Data-Type −サブオペランド：第２オペランドのアドレシングに用
いられるベース・レジスタを表わす * 長さ式：６ * アドレス式：register（B2）（すなわちフィールドＢ
２によって指示されるベース・レジスタ） * データ式：Address-Data-Type
【００７５】４．例：MOVE CHARACTER LONG命令ツリー オペランド間の関係を更に詳しく説明するために、複雑
なＣＩＳＣ命令であるMOVE CHARACTER LONG 命令を考え
る。この命令の効果は、非公式には第２オペランドの内
容を第１オペランドの記憶位置にセットすることであ
る。第２オペランドが第１オペランドよりも短い場合
は、第３オペランドのデータが、第１オペランドの記憶
域に記入するために追加される。第１及び第２のオペラ
ンドのアドレスと長さは記憶位置に与えられる。これら
間接構造は、ベース・レジスタと変位フィールドによっ
て指示される。命令動作は割込み可能である。割込みの
場合、部分的動作を表わすアドレスと長さは間接構造に
記録される。想定されるリソースは、主メモリとベース
・レジスタである。 命令： −セマンティック・プロシジャ：Move-Character-Long（）． −フォーマット：MVCL-OPCODE D1、B1、D2、B2、I3． * 第１オペランド： −サブオペランド： * 長さ式：contents（contents（B1）+value（D1））； * アドレス式：contents（contents（B1）+value（D1）+2）； * データ式：Unsigned-Binary． −サブオペランド： * 長さ式：８； * アドレス式：contents（B1）+value（D1）； * データ式：MVCL-Indirection-Data-Type． −サブオペランド： * 長さ式：２； * アドレス式：in-field（D1）； * データ式：Displacement-Data-Type． −サブオペランド： * 長さ式：６； * アドレス式：register（B1） * データ式：Address-Data-Type． * 第２オペランド：第１オペランドと同様でＢ２、Ｄ２を持つ * 第３オペランド： −サブオペランド： * 長さ式：１； * アドレス式：in-field（I3）； * データ式：Unsigned-Binary．
なＣＩＳＣ命令であるMOVE CHARACTER LONG 命令を考え
る。この命令の効果は、非公式には第２オペランドの内
容を第１オペランドの記憶位置にセットすることであ
る。第２オペランドが第１オペランドよりも短い場合
は、第３オペランドのデータが、第１オペランドの記憶
域に記入するために追加される。第１及び第２のオペラ
ンドのアドレスと長さは記憶位置に与えられる。これら
間接構造は、ベース・レジスタと変位フィールドによっ
て指示される。命令動作は割込み可能である。割込みの
場合、部分的動作を表わすアドレスと長さは間接構造に
記録される。想定されるリソースは、主メモリとベース
・レジスタである。 命令： −セマンティック・プロシジャ：Move-Character-Long（）． −フォーマット：MVCL-OPCODE D1、B1、D2、B2、I3． * 第１オペランド： −サブオペランド： * 長さ式：contents（contents（B1）+value（D1））； * アドレス式：contents（contents（B1）+value（D1）+2）； * データ式：Unsigned-Binary． −サブオペランド： * 長さ式：８； * アドレス式：contents（B1）+value（D1）； * データ式：MVCL-Indirection-Data-Type． −サブオペランド： * 長さ式：２； * アドレス式：in-field（D1）； * データ式：Displacement-Data-Type． −サブオペランド： * 長さ式：６； * アドレス式：register（B1） * データ式：Address-Data-Type． * 第２オペランド：第１オペランドと同様でＢ２、Ｄ２を持つ * 第３オペランド： −サブオペランド： * 長さ式：１； * アドレス式：in-field（I3）； * データ式：Unsigned-Binary．
【００７６】第１サブオペランドの長さとアドレスは両
方とも第２サブオペランドの内容またはデータと関係す
る。第２サブオペランドのアドレスは、残りのサブオペ
ランドのデータと関係する。MOVE CHARACTER LONG はＣ
ＩＳＣ命令の典型例である。その構造は比較的複雑であ
る。そのデータの１部は非標準データ型（MVCL-Indirec
tion-Data-Type 等）に準ずる。その実行はロングにで
き、割込み可能である。
方とも第２サブオペランドの内容またはデータと関係す
る。第２サブオペランドのアドレスは、残りのサブオペ
ランドのデータと関係する。MOVE CHARACTER LONG はＣ
ＩＳＣ命令の典型例である。その構造は比較的複雑であ
る。そのデータの１部は非標準データ型（MVCL-Indirec
tion-Data-Type 等）に準ずる。その実行はロングにで
き、割込み可能である。
【００７７】いずれの例も、このモデル・アプローチが
ＣＩＳＣレパートリの複雑さに充分対応することを示し
ている。このアプローチは明らかに命令があまり複雑で
ないＲＩＳＣアーキテクチャにも適している。
ＣＩＳＣレパートリの複雑さに充分対応することを示し
ている。このアプローチは明らかに命令があまり複雑で
ないＲＩＳＣアーキテクチャにも適している。
【００７８】５．生成 命令ツリーは命令インスタンス群を記述する。モデルの
長さ、アドレス及びデータの式は、長さ、アドレス及び
データのインスタンスに置換えられ、命令インスタンス
が形成される。この置換えは、式によって記述される関
係と整合していなければならない。具体的には、フィー
ルドとリソースがいくつかのサブオペランドによって共
有される場合、それらに選択された値は同一でなければ
ならない。以下では、一貫したインスタンス及びそれを
命令ツリーから生成するプロセスについて述べる。 定義：フィールド＜NAME、VALUES、REGISTER＞の「フィ
ールド・インスタンス」はリテラルＶであり、ＶはVALU
ESのＶになる。フォーマット＜FIELD1、．．、．FIELDn
＞の「フォーマット・インスタンス」は、＜INST1
、．．、．INSTn＞であり、全てのｉについて、INSTｉ
はFIELDｉのフィールド・インスタンスになる。 定義：Address Expression ＡＥ の「アドレス・インス
タンス」はＡＥのセマンティクスのリソース・アドレス
である。Length Expression ＬＥの長さインスタンス
は、ＬＥのセマンティクスの整数である。Data Express
ion ＤＥのデータ・インスタンスは、ＤＥによって指示
されるデータ型のデータである。 定義：サブオペランド＜LE、AE、DE＞の「サブオペラン
ド・インスタンス」は、３重項＜LI、AI、DI＞であり、
ＬＩはＬＥの長さインスタンス、ＡＩはＡＥのアドレス
・インスタンス、ＤＩはＤＥのデータ・インスタンスで
ある。オペランド＜SUB1、．．、．SUBn＞のオペランド
・インスタンスは＜INST1、．．、．INSTn＞であり、全
てのｉについて、 INSTｉはSUBｉの一貫したサブオペラ
ンド・インスタンスである。命令ツリー＜FORMAT、SEMA
NTICS、OPERANDs ＞の命令インスタンスは、組＜FORMAT
-INST、OPERAND-INSTs＞であり、FORMAT-INSTはFORMAT
のインスタンス、全てのOPERAND-INSTsは、OPERANDsの
一貫したインスタンスになる。
長さ、アドレス及びデータの式は、長さ、アドレス及び
データのインスタンスに置換えられ、命令インスタンス
が形成される。この置換えは、式によって記述される関
係と整合していなければならない。具体的には、フィー
ルドとリソースがいくつかのサブオペランドによって共
有される場合、それらに選択された値は同一でなければ
ならない。以下では、一貫したインスタンス及びそれを
命令ツリーから生成するプロセスについて述べる。 定義：フィールド＜NAME、VALUES、REGISTER＞の「フィ
ールド・インスタンス」はリテラルＶであり、ＶはVALU
ESのＶになる。フォーマット＜FIELD1、．．、．FIELDn
＞の「フォーマット・インスタンス」は、＜INST1
、．．、．INSTn＞であり、全てのｉについて、INSTｉ
はFIELDｉのフィールド・インスタンスになる。 定義：Address Expression ＡＥ の「アドレス・インス
タンス」はＡＥのセマンティクスのリソース・アドレス
である。Length Expression ＬＥの長さインスタンス
は、ＬＥのセマンティクスの整数である。Data Express
ion ＤＥのデータ・インスタンスは、ＤＥによって指示
されるデータ型のデータである。 定義：サブオペランド＜LE、AE、DE＞の「サブオペラン
ド・インスタンス」は、３重項＜LI、AI、DI＞であり、
ＬＩはＬＥの長さインスタンス、ＡＩはＡＥのアドレス
・インスタンス、ＤＩはＤＥのデータ・インスタンスで
ある。オペランド＜SUB1、．．、．SUBn＞のオペランド
・インスタンスは＜INST1、．．、．INSTn＞であり、全
てのｉについて、 INSTｉはSUBｉの一貫したサブオペラ
ンド・インスタンスである。命令ツリー＜FORMAT、SEMA
NTICS、OPERANDs ＞の命令インスタンスは、組＜FORMAT
-INST、OPERAND-INSTs＞であり、FORMAT-INSTはFORMAT
のインスタンス、全てのOPERAND-INSTsは、OPERANDsの
一貫したインスタンスになる。
【００７９】命令ツリーは深さの方向にたどられる。ル
ートと内部ノードでは何の処理も行なわれない。リーフ
では、長さ、アドレス及びデータのインスタンスが、す
でに前の選択によってセットされているか、または対応
する式のセマンティクスからランダムに選択される。こ
の機構により、生成された命令インスタンスに一貫性が
保証される。
ートと内部ノードでは何の処理も行なわれない。リーフ
では、長さ、アドレス及びデータのインスタンスが、す
でに前の選択によってセットされているか、または対応
する式のセマンティクスからランダムに選択される。こ
の機構により、生成された命令インスタンスに一貫性が
保証される。
【００８０】６．例：ADD WORD命令インスタンス 命令ツリーは深さの方向にたどられる。このようなADD
WORD命令インスタンスを図５（ノード・ラベルは生成順
序を示す）及び以下のリストで示す。 命令インスタンス： * 第１オペランド： −サブオペランド・インスタンス： * 長さインスタンス：４； * アドレス・インスタンス：７（すなわちワード・レジ
スタ番号７）； * データ・インスタンス：5F93A16B． * 第２オペランド・インスタンス： −サブオペランド・インスタンス： * 長さインスタンス：４； * アドレス・インスタンス：000010008100（すなわち主
メモリ・アドレス）； * データ・インスタンス：15EA917C． −サブオペランド・インスタンス： * 長さインスタンス：２； * アドレス・インスタンス：なし（データがＤ２フィー
ルドにあるため）； * データ・インスタンス：0100． −サブオペランド・インスタンス： * 長さインスタンス：６； * アドレス・インスタンス：９（すなわちベース・レジ
スタ番号９）； * データ・インスタンス：000010008000．
WORD命令インスタンスを図５（ノード・ラベルは生成順
序を示す）及び以下のリストで示す。 命令インスタンス： * 第１オペランド： −サブオペランド・インスタンス： * 長さインスタンス：４； * アドレス・インスタンス：７（すなわちワード・レジ
スタ番号７）； * データ・インスタンス：5F93A16B． * 第２オペランド・インスタンス： −サブオペランド・インスタンス： * 長さインスタンス：４； * アドレス・インスタンス：000010008100（すなわち主
メモリ・アドレス）； * データ・インスタンス：15EA917C． −サブオペランド・インスタンス： * 長さインスタンス：２； * アドレス・インスタンス：なし（データがＤ２フィー
ルドにあるため）； * データ・インスタンス：0100． −サブオペランド・インスタンス： * 長さインスタンス：６； * アドレス・インスタンス：９（すなわちベース・レジ
スタ番号９）； * データ・インスタンス：000010008000．
【００８１】この命令インスタンスは、ADD WORD命令の
シンタックスとセマンティック・エンティティの両方を
セットする。シンタックスはフォーマット・インスタン
スである（AW 7、0100、9）。 セマンティック領域はワ
ード・レジスタ番号７の内容（5F93A16B）、ベース・レ
ジスタ番号９の内容（000010008000）、及び主メモリ・
ワード000010008100の内容（15EA917C）を含む。
シンタックスとセマンティック・エンティティの両方を
セットする。シンタックスはフォーマット・インスタン
スである（AW 7、0100、9）。 セマンティック領域はワ
ード・レジスタ番号７の内容（5F93A16B）、ベース・レ
ジスタ番号９の内容（000010008000）、及び主メモリ・
ワード000010008100の内容（15EA917C）を含む。
【００８２】他のモデルと生成： 前記の基本モデルは、アーキテクチャの複雑な側面を記
述し、テスト知識を取り入れる機能に欠けている。また
基準生成機構は、長さ、アドレス及びデータのインスタ
ンスを選択する際に一貫性がどのように維持されるかを
明らかにしない。このような必要性を考慮したモデリン
グと生成の詳細について以下に述べる。
述し、テスト知識を取り入れる機能に欠けている。また
基準生成機構は、長さ、アドレス及びデータのインスタ
ンスを選択する際に一貫性がどのように維持されるかを
明らかにしない。このような必要性を考慮したモデリン
グと生成の詳細について以下に述べる。
【００８３】１．生成関数と検査関数 生成関数と検査関数は生成機構の基本ブロックとして用
いられる。これらの関数は、命令ツリーに沿って生成／
検査方式を実現するものである。 定義：「生成関数」は＜NODE、FUNCTION、OUTPUTS＞の
３重項であり、１）NODEは命令ツリーのノードであり、
２）FUNCTIONは OUTPUTSの長さ、アドレス及びデータの
インスタンスを生成する関数である。３）OUTPUTSは No
deをルートとするサブツリーの長さ、アドレス及びデー
タの式のリーフ群である。生成関数は命令ツリーを検索
する時に生成機構によって用いられる。ノードがカレン
トになると、それに関連する生成関数が全て起動され
る。これらの関数の出力はカレント・サブツリーのイン
スタンスを生成するために用いられる。生成関数は次の
ような目的を満たす。
いられる。これらの関数は、命令ツリーに沿って生成／
検査方式を実現するものである。 定義：「生成関数」は＜NODE、FUNCTION、OUTPUTS＞の
３重項であり、１）NODEは命令ツリーのノードであり、
２）FUNCTIONは OUTPUTSの長さ、アドレス及びデータの
インスタンスを生成する関数である。３）OUTPUTSは No
deをルートとするサブツリーの長さ、アドレス及びデー
タの式のリーフ群である。生成関数は命令ツリーを検索
する時に生成機構によって用いられる。ノードがカレン
トになると、それに関連する生成関数が全て起動され
る。これらの関数の出力はカレント・サブツリーのイン
スタンスを生成するために用いられる。生成関数は次の
ような目的を満たす。
【００８４】条件コードのモデリング（オペランド間の
検査タスク）： 命令の実行により、条件コード・ビットを設定すること
ができる。この結果は、命令の仕様の１部であり、セマ
ンティック・プロシジャによってモデル化される。ま
た、条件コードは、命令の入力領域を分割する。この入
力分割を用いるのは一般的なテスト知識なので、生成関
数によってオペランドのデータをバイアスして、全ての
条件コードを使用することができる。
検査タスク）： 命令の実行により、条件コード・ビットを設定すること
ができる。この結果は、命令の仕様の１部であり、セマ
ンティック・プロシジャによってモデル化される。ま
た、条件コードは、命令の入力領域を分割する。この入
力分割を用いるのは一般的なテスト知識なので、生成関
数によってオペランドのデータをバイアスして、全ての
条件コードを使用することができる。
【００８５】プログラム例外のモデリング（オペランド
間）： プログラム例外は、命令の実行によって生じる例外条件
である。これらはセマンティック・プロシジャによって
モデル化され、入力分割と見ることができる。
間）： プログラム例外は、命令の実行によって生じる例外条件
である。これらはセマンティック・プロシジャによって
モデル化され、入力分割と見ることができる。
【００８６】リソースの手続き面のモデリング（命令
間）： 上述のリソース・モデルは、現実のアーキテクチャには
余りにも簡単すぎる。特にアドレス変換とキャッシュ・
メカニズムは、コンピュータ・アーキテクチャでは普通
である。生成関数は、これらのメカニズムをテストする
入力をテスト・プログラムに組込むために用いられる。
間）： 上述のリソース・モデルは、現実のアーキテクチャには
余りにも簡単すぎる。特にアドレス変換とキャッシュ・
メカニズムは、コンピュータ・アーキテクチャでは普通
である。生成関数は、これらのメカニズムをテストする
入力をテスト・プログラムに組込むために用いられる。
【００８７】データ型の特殊値（オペランド内）： （型付き）データ・インスタンスの領域も分割すること
ができる。ここでも、全てのデータ型分割の代表をテス
トしなければならないのが普通である。
ができる。ここでも、全てのデータ型分割の代表をテス
トしなければならないのが普通である。
【００８８】適用設計のモデリング： 普通、検査プロセスでは、ハードウェア設計の様々な側
面が考慮される。
面が考慮される。
【００８９】このような側面はアーキテクチャの１部と
はみなされないが、そのテストは重要である。 定義：「検査関数」は＜NODE、FUNCTION、INPUTS＞の３
重項であり、１）NODEは命令ツリーのノード、２）FUNC
TIONはINPUTSの長さ、アドレス及びデータのインスタン
スを読取り、「拒否」または「受理」の応答を返す。
３）INPUTSはNodeをルートとするサブツリーの長さ、ア
ドレス及びデータの式のリーフ群である。
はみなされないが、そのテストは重要である。 定義：「検査関数」は＜NODE、FUNCTION、INPUTS＞の３
重項であり、１）NODEは命令ツリーのノード、２）FUNC
TIONはINPUTSの長さ、アドレス及びデータのインスタン
スを読取り、「拒否」または「受理」の応答を返す。
３）INPUTSはNodeをルートとするサブツリーの長さ、ア
ドレス及びデータの式のリーフ群である。
【００９０】検査関数は生成機構によって用いられる。
サブインスタンスツリーが生成された後、対応するサブ
命令ツリーに関連づけられた検査関数が起動される。そ
れらのいずれかが「拒否」応答を返した場合は、サブツ
リーの生成結果が撤回され、サブツリーが再び検索され
る。検査関数は次の目的を満たす。 ・命令インスタンスの長さ、アドレス及びデータの式に
よってモデル化されていない制限を課す。 ・命令インスタンスによってプログラム例外が発生する
のを防ぐ。 ・型付きデータ・インスタンスを検査する。
サブインスタンスツリーが生成された後、対応するサブ
命令ツリーに関連づけられた検査関数が起動される。そ
れらのいずれかが「拒否」応答を返した場合は、サブツ
リーの生成結果が撤回され、サブツリーが再び検索され
る。検査関数は次の目的を満たす。 ・命令インスタンスの長さ、アドレス及びデータの式に
よってモデル化されていない制限を課す。 ・命令インスタンスによってプログラム例外が発生する
のを防ぐ。 ・型付きデータ・インスタンスを検査する。
【００９１】生成関数と検査関数はオープン・システム
を対象としている。生成関数が単純データ型、すなわち
長さインスタンス、アドレス・インスタンス、データ・
インスタンスしか生成できないという事実から、ユーザ
はそのテスト知識を自然に、ローカルな形で表現するこ
とができる。また、このようなインスタンス群を生成
し、関数を命令、オペランド及びサブオペランドと関連
づけることができるから、これら関数に目的の表現性を
もたせることができる。生成関数は、完全な命令インス
タンスを生成できるなら、ユーザが書込めないほど複雑
になろう。その単純性によってオープンネスが得られ、
進化するテスト知識をモデル化できるのである。
を対象としている。生成関数が単純データ型、すなわち
長さインスタンス、アドレス・インスタンス、データ・
インスタンスしか生成できないという事実から、ユーザ
はそのテスト知識を自然に、ローカルな形で表現するこ
とができる。また、このようなインスタンス群を生成
し、関数を命令、オペランド及びサブオペランドと関連
づけることができるから、これら関数に目的の表現性を
もたせることができる。生成関数は、完全な命令インス
タンスを生成できるなら、ユーザが書込めないほど複雑
になろう。その単純性によってオープンネスが得られ、
進化するテスト知識をモデル化できるのである。
【００９２】２．例：ADD WORD生成関数 ADD WORD命令の生成関数の例を図６に示す。ADD WORD命
令ツリーは生成関数で拡張される。ここから以下のよう
な、生成関数によって満たされる多くの目的があること
がわかる。
令ツリーは生成関数で拡張される。ここから以下のよう
な、生成関数によって満たされる多くの目的があること
がわかる。
【００９３】条件コードのモデリング： Add Wordの実行によって、条件コードがSum０にセット
される。Sumは０より小さいか大きい。関数Generate Su
m Zero for AWは、命令ツリーのルートに関連づけられ
る。これは、対応するサブオペランドについて２つのデ
ータ・インスタンスを生成し、その和は０になる。この
生成を出来るだけランダムにするため、この関数は、ラ
ンダムなデータ・インスタンスを生成し、その否定が第
２のデータ・インスタンスとして与えられる。また、０
に近い結果を与えるデータ・インスタンスを生成するこ
とにより、条件コードが不適当にSum０ にセットされて
いないかどうかを調べることもできる。この条件は、ラ
ンダム生成では明らかに稀にしか生じない。
される。Sumは０より小さいか大きい。関数Generate Su
m Zero for AWは、命令ツリーのルートに関連づけられ
る。これは、対応するサブオペランドについて２つのデ
ータ・インスタンスを生成し、その和は０になる。この
生成を出来るだけランダムにするため、この関数は、ラ
ンダムなデータ・インスタンスを生成し、その否定が第
２のデータ・インスタンスとして与えられる。また、０
に近い結果を与えるデータ・インスタンスを生成するこ
とにより、条件コードが不適当にSum０ にセットされて
いないかどうかを調べることもできる。この条件は、ラ
ンダム生成では明らかに稀にしか生じない。
【００９４】プログラム例外のモデリング： ADD WORDでは、「有効アドレス・オーバフロー」例外が
生じることがある。これは、ベース・レジスタの内容が
１つのメモリ・セグメントをさし、そのレジスタと変位
の加算によって成るアドレスが別のセグメントをさす時
に起こる。生成関数Generate Effective Address Overf
low は、第２オペランドに関連づけられる。これは、Ef
fective Address Overflowの原因となったサブオペラン
ドについて２つのデータ・インスタンスを生成する。
生じることがある。これは、ベース・レジスタの内容が
１つのメモリ・セグメントをさし、そのレジスタと変位
の加算によって成るアドレスが別のセグメントをさす時
に起こる。生成関数Generate Effective Address Overf
low は、第２オペランドに関連づけられる。これは、Ef
fective Address Overflowの原因となったサブオペラン
ドについて２つのデータ・インスタンスを生成する。
【００９５】アドレスのランダム生成がそのような例外
を引起こすことは極めて稀であり、この生成関数によっ
て得られるバイアスは、命令とプログラム例外メカニズ
ムのテストに重要である。
を引起こすことは極めて稀であり、この生成関数によっ
て得られるバイアスは、命令とプログラム例外メカニズ
ムのテストに重要である。
【００９６】リソースの手続き面のモデリング： アドレス・インスタンスは、キャッシュにある（ヒッ
ト）か、キャッシュにない（ミス）のいずれかである。
同様にサブオペランド・インスタンスのアドレスと長さ
のインスタンスは、その最下位バイトをヒットまたはミ
スにすることができる。ヒット／ミスの組合わせを（そ
の最上位バイトと最下位バイトについて）使用するサブ
オペランド・インスタンスは、メモリ・キャッシュ・メ
カニズムをチェックするのに用いられる。関数Generate
Hit Miss は、キャッシュ・メカニズムについての知識
を含み、第２オペランドのメモリ・アドレスに関連づけ
られる。これは、ヒットとミスの組合わせの１つをラン
ダムに使用するアドレスと長さのインスタンスを生成す
る。
ト）か、キャッシュにない（ミス）のいずれかである。
同様にサブオペランド・インスタンスのアドレスと長さ
のインスタンスは、その最下位バイトをヒットまたはミ
スにすることができる。ヒット／ミスの組合わせを（そ
の最上位バイトと最下位バイトについて）使用するサブ
オペランド・インスタンスは、メモリ・キャッシュ・メ
カニズムをチェックするのに用いられる。関数Generate
Hit Miss は、キャッシュ・メカニズムについての知識
を含み、第２オペランドのメモリ・アドレスに関連づけ
られる。これは、ヒットとミスの組合わせの１つをラン
ダムに使用するアドレスと長さのインスタンスを生成す
る。
【００９７】データ型の特殊値： 関数Generate Unsigned Binary Extremes は、２つの符
号なし２進数データ・リーフに関連づけられる。これ
は、値0xFFFFFFFF、0x00000000及び近似値からランダム
に選択されたデータ・インスタンスを生成する。
号なし２進数データ・リーフに関連づけられる。これ
は、値0xFFFFFFFF、0x00000000及び近似値からランダム
に選択されたデータ・インスタンスを生成する。
【００９８】設計情報のモデリング： ルートに関連づけられた生成関数は、桁上げルックアヘ
ッド・メカニズムをテストすることができる。これは、
ルックアヘッド境界で桁上げパターンが異なる、符号な
し２進数リーフのデータ・インスタンスを生成する。例
えば、ハーフワード加算器が２つの場合、データ値0000
FFFFと00000001は、２つの加算器の間で引渡された桁上
げになる。関数Check Half-Word Addersは、ＡＬＵ（算
術論理演算器）の実現についての知識を表わす。
ッド・メカニズムをテストすることができる。これは、
ルックアヘッド境界で桁上げパターンが異なる、符号な
し２進数リーフのデータ・インスタンスを生成する。例
えば、ハーフワード加算器が２つの場合、データ値0000
FFFFと00000001は、２つの加算器の間で引渡された桁上
げになる。関数Check Half-Word Addersは、ＡＬＵ（算
術論理演算器）の実現についての知識を表わす。
【００９９】３．生成 テストの生成は２つの手続き、Generate-TestとGenerat
e に分けられる。前者は、ＲＴＰＧに似た動的プロセス
であり、後者は、命令ツリーの深さ順検索を拡張したも
ので、バックトラッキングを含む。 Generate-Test（N） 最小プロセッサ状態を初期化 while命令数 ＜ N 命令を選択。そのモデルをInstruction-Treeで示す GEN：Instance = Generate（Instruction-Tree、Empty） Simulate Instance by Instruction-Tree．Semantic-Procedure if命令インスタンスが実行可能 then テスト・ファイルに書込む 命令数を増分 else 命令インスタンスを撤回 プロセッサの前の状態を回復 if試行限度を超えない then go-to GEN else 放棄 Successを返す Generate（Node、Kept-Outputs） Nodeに関連する生成関数を起動 その出力をKept-Outputsに追加 if Nodeが内部 then for Nodeの直系の子孫それぞれについて Generate（Descendant、Kept-Outputs）を起動 if「拒否」が返る then Kept-Outputsを回復 if試行限度を超える then Generate（Descendant、Kept-Outputs）を起動 else「拒否」を返す else「受理」を返す else（Nodeがリーフ）: Nodeに関連するKept-Outputsの１つを選択 ifその出力がない then Nodeの式のセマンティクスからインスタンスをランダムに選択 ifそのインスタンスがNodeの式を満足しない then「拒否」を返す else「受理」を返す Nodeに関連する検査関数を起動 if検査関数のいずれかが「拒否」を返す then「拒否」を返す else「受理」を返す
e に分けられる。前者は、ＲＴＰＧに似た動的プロセス
であり、後者は、命令ツリーの深さ順検索を拡張したも
ので、バックトラッキングを含む。 Generate-Test（N） 最小プロセッサ状態を初期化 while命令数 ＜ N 命令を選択。そのモデルをInstruction-Treeで示す GEN：Instance = Generate（Instruction-Tree、Empty） Simulate Instance by Instruction-Tree．Semantic-Procedure if命令インスタンスが実行可能 then テスト・ファイルに書込む 命令数を増分 else 命令インスタンスを撤回 プロセッサの前の状態を回復 if試行限度を超えない then go-to GEN else 放棄 Successを返す Generate（Node、Kept-Outputs） Nodeに関連する生成関数を起動 その出力をKept-Outputsに追加 if Nodeが内部 then for Nodeの直系の子孫それぞれについて Generate（Descendant、Kept-Outputs）を起動 if「拒否」が返る then Kept-Outputsを回復 if試行限度を超える then Generate（Descendant、Kept-Outputs）を起動 else「拒否」を返す else「受理」を返す else（Nodeがリーフ）: Nodeに関連するKept-Outputsの１つを選択 ifその出力がない then Nodeの式のセマンティクスからインスタンスをランダムに選択 ifそのインスタンスがNodeの式を満足しない then「拒否」を返す else「受理」を返す Nodeに関連する検査関数を起動 if検査関数のいずれかが「拒否」を返す then「拒否」を返す else「受理」を返す
【０１００】リソース・マネージャは、生成プロセスの
バックグラウンドに存在する。これは、動的Generate-T
est アルゴリズムにとって重要なプロセッサの状態を管
理する。またGenerate-Test で、アドレス式を解くのに
も重要である。生成関数と検査関数は、リソース・マネ
ージャに、リソースの割当てと内容について照会する。
この情報はリソースの選択と命令ツリー式の検査に用い
られる。
バックグラウンドに存在する。これは、動的Generate-T
est アルゴリズムにとって重要なプロセッサの状態を管
理する。またGenerate-Test で、アドレス式を解くのに
も重要である。生成関数と検査関数は、リソース・マネ
ージャに、リソースの割当てと内容について照会する。
この情報はリソースの選択と命令ツリー式の検査に用い
られる。
【０１０１】結果: 本発明者は、本発明の実施例により、いくつかのプロセ
ッサ・アーキテクチャについてテスト・プログラムを作
成した。ＩＢＭ ＡＳ／４００ ＣＩＳＣプロセッサの
２つのバージョン、ＩＢＭ Ｓｙｓｔｅｍ／３９０プロ
セッサの浮動小数点ユニット及び３種類のＲＩＳＣプロ
セッサを含めて、ＣＩＳＣとＲＩＳＣの両方のアーキテ
クチャが用いられた。ＣＩＳＣとＲＩＳＣのアーキテク
チャについて本発明者が使用した、本発明の実施例によ
って生成されたテスト・プログラムの例を付録Ａに示
す。
ッサ・アーキテクチャについてテスト・プログラムを作
成した。ＩＢＭ ＡＳ／４００ ＣＩＳＣプロセッサの
２つのバージョン、ＩＢＭ Ｓｙｓｔｅｍ／３９０プロ
セッサの浮動小数点ユニット及び３種類のＲＩＳＣプロ
セッサを含めて、ＣＩＳＣとＲＩＳＣの両方のアーキテ
クチャが用いられた。ＣＩＳＣとＲＩＳＣのアーキテク
チャについて本発明者が使用した、本発明の実施例によ
って生成されたテスト・プログラムの例を付録Ａに示
す。
【０１０２】モデル化されたアーキテクチャは、命令の
レパートリと構造、オペランドの関係、リソース及び機
能ユニットが異なる。アーキテクチャは全て、マルチボ
リューム・アーキテクチャ・ブックに指定された数百の
命令から成る複雑なもので、必要な検査も複雑でありコ
ストがかかる。ＲＩＳＣアーキテクチャのモデリング
は、３００以上の命令とテスト知識を表わす４万行のＣ
手続きを含み、そのデータベースは３メガバイトにのぼ
る。システムの開発基盤として用いられたＣＩＳＣアー
キテクチャでは、１００以上の命令と１３，０００行の
テスト知識コードが用いられ、そのデータベースは４メ
ガバイトになった。
レパートリと構造、オペランドの関係、リソース及び機
能ユニットが異なる。アーキテクチャは全て、マルチボ
リューム・アーキテクチャ・ブックに指定された数百の
命令から成る複雑なもので、必要な検査も複雑でありコ
ストがかかる。ＲＩＳＣアーキテクチャのモデリング
は、３００以上の命令とテスト知識を表わす４万行のＣ
手続きを含み、そのデータベースは３メガバイトにのぼ
る。システムの開発基盤として用いられたＣＩＳＣアー
キテクチャでは、１００以上の命令と１３，０００行の
テスト知識コードが用いられ、そのデータベースは４メ
ガバイトになった。
【０１０３】モデル化されたアーキテクチャに対して、
上述の検査タスクに対応する複雑なテスト・プログラム
が生成された。大きいデータ群（数千バイト）を伴う大
きいテスト群（命令インスタンスが数百）は数秒で生成
されるが、このようなテストの品質の方がもっと重要と
みられる。
上述の検査タスクに対応する複雑なテスト・プログラム
が生成された。大きいデータ群（数千バイト）を伴う大
きいテスト群（命令インスタンスが数百）は数秒で生成
されるが、このようなテストの品質の方がもっと重要と
みられる。
【０１０４】命令レベルとオペランド・レベルの検査タ
スク（代表的なデータ・インスタンス、異なるオペラン
ド長、全てのプログラム例外等）は、生成関数を通して
実現される。レジスタとメモリの割当て方式から、命令
間の依存性が複雑になる。このような関数を割当て方式
と共に用いて長い命令ストリームを生成すれば、命令間
検査タスクが実現される。
スク（代表的なデータ・インスタンス、異なるオペラン
ド長、全てのプログラム例外等）は、生成関数を通して
実現される。レジスタとメモリの割当て方式から、命令
間の依存性が複雑になる。このような関数を割当て方式
と共に用いて長い命令ストリームを生成すれば、命令間
検査タスクが実現される。
【０１０５】テスト知識モデルは現在、先に非公式に記
述されたテスト・ノウハウを指定するために用いられて
いる。最初に非公式なテスト条件がコンパイルされる。
次に生成関数が設計／実施される。その意味では、生成
システムはエキスパート・システムとして用いられる。
アーキテクチャから駆動される検査タスクの全て、及び
実施面を表わす多くの検査タスクが、生成関数によって
モデル化されている。この知識により、設計を充分カバ
ーするテスト群を生成することができる。いずれの例で
も、データベースは知識ベースとして用いられ、組織の
ノウハウが取り入れられ、これが正式な再利用可能なも
のにされる。
述されたテスト・ノウハウを指定するために用いられて
いる。最初に非公式なテスト条件がコンパイルされる。
次に生成関数が設計／実施される。その意味では、生成
システムはエキスパート・システムとして用いられる。
アーキテクチャから駆動される検査タスクの全て、及び
実施面を表わす多くの検査タスクが、生成関数によって
モデル化されている。この知識により、設計を充分カバ
ーするテスト群を生成することができる。いずれの例で
も、データベースは知識ベースとして用いられ、組織の
ノウハウが取り入れられ、これが正式な再利用可能なも
のにされる。
【０１０６】また、２進浮動小数点演算に関する３種類
のＡＮＳＩ／ＩＥＥＥ規格の検査によって（５年に及
び）蓄積されたテスト・ノウハウは、本発明者が用いた
実施例のモデルに取り入れられている。これは、同じ規
格の現行版（数件）についてテストを生成するために用
いられている。
のＡＮＳＩ／ＩＥＥＥ規格の検査によって（５年に及
び）蓄積されたテスト・ノウハウは、本発明者が用いた
実施例のモデルに取り入れられている。これは、同じ規
格の現行版（数件）についてテストを生成するために用
いられている。
【０１０７】
【表１】 付録Ａ−テスト・プログラム例： Ａ．１ ＲＩＳＣアーキテクチャ：* INITIALIZATIONS R IAR 0000000000200000 R CR 00000000 R XER 0000000000000020 R FPSCR 0000000000000000 R MSR 00000001 R G18 122BC71CEA5C3B2B R G6 5A2D606A18536A8B R G1 9A639739A5F55A33 D 000000001173B7 33CA81E689516DC4 R G15 0000000000113D7B R G7 5BD24F21A2D94CB6 R G8 267F09AF6415A9BD R G20 1584B4CD8C3D09E0* INSTRUCTIONS I 00000000200000 7E460A15 * add．G18、G6、G1 I 00000000200004 48133104 * b 0x133104 I 00000000333108 E8EF363C * ld G7、0x363C（G15） I 0000000033310C 7E883C36 * srd G8、G20、G7 T 00000000333110* RESULTS R MSR 00000001 R IAR 0000000000333110 R G1 9A639739A5F55A33 R G6 5A2D606A18536A8B R G7 33CA81E689516DC4 R G8 0000000000000000 R G15 0000000000113D7B R G18 F490F7A3BE48C4BE R G20 1584B4CD8C3D09E0 R FPSCR 0000000000000000 R XER 0000000008000020 R CR 80000000 D 000000001173B7 33CA81E689516DC4
【０１０８】
【表２】 付録Ａ−テスト・プログラム例： Ａ．２ ＣＩＳＣアーキテクチャ：* INITIALIZATIONS R A0 100000000000004000000000 R IAR 00000000 R TSW 02000000 D 10000000000000800000F811 BBCD8634230DAC615ADB20A9 R A3 10000000000000800000958A D 10000000000000800000530E BD9C0B R A15 100000000000008000000385 R W10 47039CFD R W11 70C0E376 R W12 2DF087D7 R W14 00006C74 R D14 7EE3FCD2108643A9 D 1000000000000080000084D4 C661E4B652DCE0A6 R A7 100000000000008000002787* INSTRUCTIONS I 100000000000004000000000 781F4F892C236287 * AUC '6287'X（'C'X、A3）、'4F89'X（'3'X、A15） I 100000000000004000000008 60CBA100 * AUWR W10、W11、W12 I 10000000000000400000000C 6BE0F820 * BR W14 I 100000000000004000006C74 E6E75D4D * LD D14、'5D4D'X（A7） T 100000000000004000006C78* RESULTS R W10 9EB16B4D R W11 70C0E376 R W12 2DF087D7 R W14 00006C74 R TSW 02000000 R IAR 00006C78 R H10 6B4D R H11 E376 R H12 87D7 R H14 6C74 R D14 C661E4B652DCE0A6 R B10 4D R B11 76 R B12 D7 R B14 74 R A0 100000000000004000000000 R A3 10000000000000800000958A R A7 100000000000008000002787 R A15 100000000000008000000385 D 10000000000000800000530E BD9C0B D 1000000000000080000084D4 C661E4B652DCE0A6 D 10000000000000800000F811 BBCD8634230DAC615B98BCB4
【図１】システムの要素と相互関係を示す図である。
【図２】クラス階層を示す図である。
【図３】テスト・ジェネレータの構造を示す図である。
【図４】ADD WORDの命令ツリーの１例を示す図である。
【図５】ADD WORDの命令インスタンスの１例を示す図で
ある。
ある。
【図６】ADD WORD生成関数の１例を示す図である。
１０ アーキテクチャ・モデル ２０ アーキテクチャ・シミュレータ ３０ テスト・ジェネレータ ４０ ユーザ・インタフェース ５０ 抽出プログラム論理 ６０ 生成機構制御論理 ７０ 生成関数 ８０ 検査関数 ９０ インヴォーカ １００ アドレス制約ソルバ １１０ 長さ制約ソルバ １２０ データ・ジェネレータ １３０ アロケータ（リソース・マネージャ）
───────────────────────────────────────────────────── フロントページの続き (72)発明者 ヨッシ・リクテンステイン イスラエル52313、ラマ−ガン、ベン− ガリオン・ロード 263 (56)参考文献 特開 平１−226038（ＪＰ，Ａ) 特開 平４−119436（ＪＰ，Ａ) 特開 平２−287737（ＪＰ，Ａ)
Claims (8)
- 【請求項１】ハードウェア・プロセッサの動作をチェッ
クするためのテスト・プログラムを生成するテスト・プ
ログラム・ジェネレータであって、 前記プロセッサの命令群とリソースを表わすデータを格
納する手段と、 前記データを前記格納手段から抽出する手段と、 前記抽出されたデータからテスト・プログラムを生成す
るための手段と、 を含み、 前記データが、独立した宣言仕様であり、該宣言仕様に
おいて、各命令の表現がツリー構造の形で格納され、前
記ツリーの第１レベルが命令のシンタックスを含み、前
記ツリーの最後のレベルがセマンティック・エンティテ
ィの可能値及び前記セマンティック・エンティティ相互
間の関係を含み、 前記テスト・プログラムを生成するための手段が、 命令インスタンスを生成する手段と、 前記ツリー構造を深さ方向にたどり、命令インスタンス
の一貫性を保つために、前記ツリーの前のノードでなさ
れた選択に従って、各セマンティック・エンティティの
インスタンスを生成する手段と、 を含み、 前記命令に関連づけられたセマンティック・エンティテ
ィ相互間や、前記セマンティック・エンティティと前記
プロセッサ・リソースとの間の関係が、前記宣言仕様内
にモデル化されることを特徴とする、テスト・プログラ
ム・ジェネレータ。 - 【請求項２】前記テスト・プログラムの生成に関連する
テスト知識が、前記格納されたデータ内にモデル化され
た、請求項１記載のテスト・プログラム・ジェネレー
タ。 - 【請求項３】前記テスト・プログラムの生成に関連する
テスト知識が、生成関数を含むセマンティック・エンテ
ィティ・インスタンスを生成する手段によって、前記格
納されたデータに手続き的にモデル化され、前記生成関
数が目的のテスト・ケースが生成できるようにユーザに
よって調整可能な、請求項２記載のテスト・プログラム
・ジェネレータ。 - 【請求項４】生成されたセマンティック・エンティティ
・インスタンスを、複数の検査基準に従ってテストする
手段を含み、前記生成されたセマンティック・エンティ
ティ・インスタンスが前記複数の検査基準または各検査
基準を満足しない場合には、前記インスタンスの生成が
繰返される、請求項２または３記載のテスト・プログラ
ム・ジェネレータ。 - 【請求項５】前記検査基準がユーザによって調整可能で
あり、不要なテスト・ケースの生成が防止される、請求
項４記載のテスト・プログラム・ジェネレータ。 - 【請求項６】後の格納または処理を目的に、ハードウェ
ア・プロセッサの動作をチェックするためにテスト・プ
ログラムを生成する方法であって、 前記プロセッサの命令群とリソースを表わすデータを独
立した宣言仕様に格納するステップと、 前記データを記憶域から抽出するステップと、 抽出されたデータからテスト・プログラムを生成するス
テップと、 を含み、 前記独立した宣言仕様において、各命令の表現がツリー
構造の形に格納され、前記ツリーの第１レベルが命令の
構造を含み、前記ツリーの最後のレベルが前記セマンテ
ィック・エンティティの可能値及びセマンティック・エ
ンティティ相互間の関係を含み、 前記生成ステップが、命令インスタンスを生成するステ
ップと、前記ツリー構造を深さ方向にたどり、前記命令
インスタンスの一貫性を保つために、前記ツリーの前の
ノードでなされた選択に従って、各セマンティック・エ
ンティティのインスタンスを生成するステップとを含
み、前記宣言仕様において、各命令に関連づけられたセ
マンティック・エンティティ相互間や、前記セマンティ
ック・エンティティと前記プロセッサ・リソースとの間
の関係がモデル化される、テスト・プログラムを生成す
る方法。 - 【請求項７】前記独立した宣言仕様において、各命令の
表現がツリー構造の形に格納され、前記ツリーの第１レ
ベルが命令の構造を含み、前記ツリーの最後のレベルが
前記セマンティック・エンティティの可能値及び関係を
含み、 前記生成ステップが命令インスタンスを生成するステッ
プと、前記ツリー構造を深さ方向にたどり、各セマンテ
ィック・エンティティのインスタンスを、先の検索ステ
ップで行なわれた選択に従って、前記命令インスタンス
の一貫性を保つために生成するステップとを含む、請求
項６記載の方法。 - 【請求項８】生成関数を格納するステップを含み、前記
セマンティック・エンティティ・インスタンスを生成す
るステップが、前記生成関数の制御下で実行され、前記
生成関数が目的のテスト・ケースが生成されるように存
在する、請求項７記載の方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB9310223.4 | 1993-05-18 | ||
| GB9310223A GB2278213A (en) | 1993-05-18 | 1993-05-18 | Test program generator. |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH06332743A JPH06332743A (ja) | 1994-12-02 |
| JP2637914B2 true JP2637914B2 (ja) | 1997-08-06 |
Family
ID=10735689
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP6065989A Expired - Lifetime JP2637914B2 (ja) | 1993-05-18 | 1994-04-04 | テスト・プログラム・ジェネレータ及びテスト・プログラムを生成する方法 |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US6006028A (ja) |
| EP (1) | EP0628911A3 (ja) |
| JP (1) | JP2637914B2 (ja) |
| GB (1) | GB2278213A (ja) |
Families Citing this family (68)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6397353B1 (en) * | 1998-04-17 | 2002-05-28 | Allied Signal Inc. | Method and apparatus for protecting sensitive data during automatic testing of hardware |
| US6108659A (en) * | 1998-12-22 | 2000-08-22 | Computer Associates Think, Inc. | Method and apparatus for executing stored code objects in a database |
| US6421822B1 (en) | 1998-12-28 | 2002-07-16 | International Business Machines Corporation | Graphical user interface for developing test cases using a test object library |
| US6332211B1 (en) * | 1998-12-28 | 2001-12-18 | International Business Machines Corporation | System and method for developing test cases using a test object library |
| US6493841B1 (en) | 1999-03-31 | 2002-12-10 | Synopsys, Inc. | Method and apparatus for determining expected values during circuit design verification |
| US6499127B1 (en) * | 1999-04-22 | 2002-12-24 | Synopsys, Inc. | Method and apparatus for random stimulus generation |
| US6449745B1 (en) * | 1999-04-22 | 2002-09-10 | Synopsys, Inc. | Method and apparatus for random stimulus generation |
| US6513144B1 (en) | 1999-04-22 | 2003-01-28 | Synopsys, Inc. | Method and apparatus for random stimulus generation |
| US6553531B1 (en) * | 1999-04-22 | 2003-04-22 | Synopsys, Inc. | Method and apparatus for random stimulus generation |
| US6427223B1 (en) | 1999-04-30 | 2002-07-30 | Synopsys, Inc. | Method and apparatus for adaptive verification of circuit designs |
| US6327559B1 (en) * | 1999-05-04 | 2001-12-04 | International Business Machines Corporation | Method for creating a simulation environment for enhanced logic verification of a branch history table |
| US6606721B1 (en) * | 1999-11-12 | 2003-08-12 | Obsidian Software | Method and apparatus that tracks processor resources in a dynamic pseudo-random test program generator |
| JP3488161B2 (ja) * | 2000-01-31 | 2004-01-19 | Ｎｅｃエレクトロニクス株式会社 | プログラム開発装置、プログラム開発方法及びプログラム開発プログラムを記録した記録媒体 |
| US6725230B2 (en) * | 2000-07-18 | 2004-04-20 | Aegis Analytical Corporation | System, method and computer program for assembling process data of multi-database origins using a hierarchical display |
| US6996799B1 (en) | 2000-08-08 | 2006-02-07 | Mobilygen Corporation | Automatic code generation for integrated circuit design |
| US6766267B2 (en) * | 2000-10-13 | 2004-07-20 | Ciena Corporation | Automated monitoring system, virtual oven and method for stress testing logically grouped modules |
| US6684359B2 (en) * | 2000-11-03 | 2004-01-27 | Verisity Ltd. | System and method for test generation with dynamic constraints using static analysis |
| US20020087734A1 (en) * | 2000-12-29 | 2002-07-04 | Marshall Donald Brent | System and method for managing dependencies in a component-based system |
| US6567959B2 (en) * | 2001-03-30 | 2003-05-20 | Intel Corporation | Method and device for verification of VLSI designs |
| US7225110B2 (en) | 2001-08-16 | 2007-05-29 | International Business Machines Corporation | Extending width of performance monitor counters |
| US7627462B2 (en) * | 2001-11-27 | 2009-12-01 | Arm Limited | Hardware simulation using a test scenario manager |
| US20030188044A1 (en) * | 2002-03-28 | 2003-10-02 | International Business Machines Corporation | System and method for verifying superscalar computer architectures |
| US7099813B2 (en) * | 2002-04-09 | 2006-08-29 | Arm Limited | Simulating program instruction execution and hardware device operation |
| US7117484B2 (en) * | 2002-04-16 | 2006-10-03 | International Business Machines Corporation | Recursive use of model based test generation for middleware validation |
| US7007207B2 (en) * | 2002-10-21 | 2006-02-28 | International Business Machines Corporation | Scheduling of transactions in system-level test program generation |
| US7133816B2 (en) * | 2002-11-04 | 2006-11-07 | International Business Machines Corporation | Test quality through resource reallocation |
| US6792581B2 (en) | 2002-11-07 | 2004-09-14 | Intel Corporation | Method and apparatus for cut-point frontier selection and for counter-example generation in formal equivalence verification |
| US7020804B2 (en) * | 2002-12-03 | 2006-03-28 | Lockheed Martin Corporation | Test data generation system for evaluating data cleansing applications |
| US6986110B1 (en) * | 2003-01-02 | 2006-01-10 | Hewlett-Packard Development Company, L.P. | Automated method and system for backtracing of instruction parameters from specified instruction in test cases |
| US20050050524A1 (en) * | 2003-08-25 | 2005-03-03 | Arm Limited | Generating software test information |
| US7051301B2 (en) * | 2003-10-01 | 2006-05-23 | Hewlett-Packard Development Company, L.P. | System and method for building a test case including a summary of instructions |
| CA2452274A1 (en) * | 2003-12-03 | 2005-06-03 | Robert F. Enenkel | System and method of testing and evaluating mathematical functions |
| US7290174B1 (en) * | 2003-12-03 | 2007-10-30 | Altera Corporation | Methods and apparatus for generating test instruction sequences |
| JP4616829B2 (ja) * | 2004-04-28 | 2011-01-19 | 富士通株式会社 | ソースコード作成支援プログラムおよびソースコード作成支援方法 |
| US7502725B2 (en) * | 2004-04-29 | 2009-03-10 | International Business Machines Corporation | Method, system and computer program product for register management in a simulation environment |
| US7370296B2 (en) * | 2004-05-25 | 2008-05-06 | International Business Machines Corporation | Modeling language and method for address translation design mechanisms in test generation |
| US20060115645A1 (en) * | 2004-11-29 | 2006-06-01 | A Major Corporation | Punch pad |
| US7644399B2 (en) | 2004-12-03 | 2010-01-05 | Arm Limited | Forming an executable program from a list of program instructions |
| US20060195681A1 (en) * | 2004-12-06 | 2006-08-31 | Arm Limited | Test program instruction generation |
| US20060150154A1 (en) * | 2004-12-06 | 2006-07-06 | Arm Limited | Test program instruction generation |
| US7630849B2 (en) * | 2005-09-01 | 2009-12-08 | Applied Biosystems, Llc | Method of automated calibration and diagnosis of laboratory instruments |
| US20070065799A1 (en) * | 2005-09-21 | 2007-03-22 | Potts Matthew P | Test replication through renaming |
| US20070168742A1 (en) * | 2005-11-18 | 2007-07-19 | Microsoft Corporation | Isolating code modules |
| US8099559B2 (en) * | 2007-09-11 | 2012-01-17 | International Business Machines Corporation | System and method for generating fast instruction and data interrupts for processor design verification and validation |
| US7992059B2 (en) | 2007-09-11 | 2011-08-02 | International Business Machines Corporation | System and method for testing a large memory area during processor design verification and validation |
| US20090070570A1 (en) * | 2007-09-11 | 2009-03-12 | Shubhodeep Roy Choudhury | System and Method for Efficiently Handling Interrupts |
| US8006221B2 (en) | 2007-09-11 | 2011-08-23 | International Business Machines Corporation | System and method for testing multiple processor modes for processor design verification and validation |
| US7752499B2 (en) * | 2007-09-11 | 2010-07-06 | International Business Machines Corporation | System and method for using resource pools and instruction pools for processor design verification and validation |
| US8019566B2 (en) * | 2007-09-11 | 2011-09-13 | International Business Machines Corporation | System and method for efficiently testing cache congruence classes during processor design verification and validation |
| US8234586B2 (en) * | 2008-03-26 | 2012-07-31 | Microsoft Corporation | User interface framework and techniques |
| US7966521B2 (en) * | 2008-07-14 | 2011-06-21 | International Business Machines Corporation | Light weight and high throughput test case generation methodology for testing cache/TLB intervention and diagnostics |
| US8397217B2 (en) * | 2010-02-22 | 2013-03-12 | International Business Machines Corporation | Integrating templates into tests |
| US8868976B2 (en) | 2010-11-04 | 2014-10-21 | International Business Machines Corporation | System-level testcase generation |
| US20130191689A1 (en) | 2012-01-20 | 2013-07-25 | International Business Machines Corporation | Functional testing of a processor design |
| US9098622B2 (en) * | 2012-02-17 | 2015-08-04 | Infosys Limited | System and method for automated and objective assessment of programming language code |
| US9372770B2 (en) * | 2012-06-04 | 2016-06-21 | Karthick Gururaj | Hardware platform validation |
| US10223246B2 (en) * | 2012-07-30 | 2019-03-05 | Infosys Limited | System and method for functional test case generation of end-to-end business process models |
| CN104246715A (zh) * | 2012-07-31 | 2014-12-24 | 惠普发展公司，有限责任合伙企业 | 构造应用的测试中心模型 |
| US9251023B2 (en) | 2013-03-07 | 2016-02-02 | International Business Machines Corporation | Implementing automated memory address recording in constrained random test generation for verification of processor hardware designs |
| US10061672B2 (en) * | 2013-03-07 | 2018-08-28 | International Business Machines Corporation | Implementing random content of program loops in random test generation for processor verification |
| KR102026662B1 (ko) * | 2013-04-22 | 2019-09-30 | 삼성전자 주식회사 | 프로세서 검증을 위한 테스트 케이스 생성 장치 및 방법과, 검증장치 |
| KR102147172B1 (ko) * | 2014-04-09 | 2020-08-31 | 삼성전자주식회사 | 시스템 온 칩 및 그것의 검증 방법 |
| US9734033B2 (en) | 2014-12-08 | 2017-08-15 | International Business Machines Corporation | Implementing processor functional verification by generating and running constrained random irritator tests for multiple processor system and processor core with multiple threads |
| US9690689B2 (en) | 2015-04-24 | 2017-06-27 | Microsoft Technology Licensing, Llc | Test case generation in a development environment |
| US9690680B1 (en) * | 2016-09-23 | 2017-06-27 | International Business Machines Corporation | Testing hybrid instruction architecture |
| US10496529B1 (en) * | 2018-04-18 | 2019-12-03 | Palantir Technologies Inc. | Data unit test-based data management system |
| CN110175019B (zh) * | 2019-06-04 | 2021-11-16 | 南京大学 | 一种基于中断序列图的中断驱动系统验证方法 |
| CN112988266B (zh) * | 2021-02-10 | 2024-04-19 | 北京奇艺世纪科技有限公司 | 一种资源管理方法、装置、电子设备及存储介质 |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS63181033A (ja) * | 1987-01-23 | 1988-07-26 | Hitachi Ltd | プログラム自動生成方式 |
| JP2527354B2 (ja) * | 1988-03-07 | 1996-08-21 | 富士通株式会社 | テストプログラム自動生成方法 |
| US5067129A (en) * | 1989-08-16 | 1991-11-19 | International Business Machines Corp. | Service processor tester |
-
1993
- 1993-05-18 GB GB9310223A patent/GB2278213A/en not_active Withdrawn
-
1994
- 1994-04-04 JP JP6065989A patent/JP2637914B2/ja not_active Expired - Lifetime
- 1994-05-03 EP EP94303181A patent/EP0628911A3/en not_active Withdrawn
- 1994-05-17 US US08/245,179 patent/US6006028A/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| EP0628911A2 (en) | 1994-12-14 |
| GB9310223D0 (en) | 1993-06-30 |
| JPH06332743A (ja) | 1994-12-02 |
| EP0628911A3 (en) | 1996-12-04 |
| US6006028A (en) | 1999-12-21 |
| GB2278213A (en) | 1994-11-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2637914B2 (ja) | テスト・プログラム・ジェネレータ及びテスト・プログラムを生成する方法 | |
| Chandra et al. | AVPGEN-a test generator for architecture verification | |
| Engels et al. | Building integrated software development environments. Part I: tool specification | |
| US6154876A (en) | Analysis of the effect of program execution of calling components with data variable checkpointing and resource allocation analysis | |
| Gifford et al. | Case study: IBM's system/360-370 architecture | |
| Yu et al. | Building certified libraries for PCC: Dynamic storage allocation | |
| Rizkallah et al. | A framework for the automatic formal verification of refinement from Cogent to C | |
| Kotik et al. | Automating software analysis and testing using a program transformation system | |
| Graham et al. | A software design and evaluation system | |
| Goel et al. | Automated code proofs on a formal model of the x86 | |
| Greve et al. | Efficient execution in an automated reasoning environment | |
| Tolmach et al. | A monadic semantics for core Curry | |
| Wick | Automatic generation of assemblers. | |
| Koopman et al. | Operational machine specification in a functional programming language | |
| Koopman | An architecture for combinator graph reduction | |
| Keppel | Runtime code generation | |
| Wright | Using EventB to create a virtual machine instruction set architecture | |
| McNally | Models for Persistence in Lazy Functional Programming Systems | |
| Hardin et al. | Concepts and Semantics of Programming Languages 1: A Semantical Approach with OCaml and Python | |
| Malka et al. | United States Patent po | |
| Friedman | A characterization of Prolog execution | |
| Goel et al. | Microprocessor Assurance and the Role of Theorem Proving | |
| Batdalov et al. | Implementation of a MIX Emulator: A Case Study of the Scala Programming Language Facilities | |
| Suvanpong | Evaluating Kiama abstract state machines for a Java implementation | |
| Gabbrielli et al. | Control Abstraction |