(57)【要約】【課題】バグの混入や設定ミス、設定漏れの発生を抑えた動作合成検証補助装置、動作合成検証補助方法、プログラム、及び記録媒体を提供する。【解決手段】設計仕様書と検証手法DBとを用いて、テストベクタを含む検証環境を自動で生成することにより、ヒューマンエラーの混入を防ぎながら検証精度の高い検証環境を提供することができ、従ってバグの混入や設定ミス、設定漏れの発生を抑えることができる。【選択図】図１
2011053764.tif 000002
【特許請求の範囲】
【請求項１】
外部から設定可能なパラメータと、画像を走査するための副走査方向への処理ループと、主走査方向への処理ループと、を有する画像処理アルゴリズムについて、前記パラメータがレジスタであることを示す情報を追加する追加手段と、
設定されたレジスタ情報を抽出する抽出手段と、
ハードウェア化時に利用するインターフェース情報を入力する利用インターフェース情報、アルゴリズムの主走査ループ処理及び副走査ループ処理を検出し、記述変換ルールに従い前記画像処理アルゴリズムの記述変換を行なう記述変換手段と、
を備えた回路設計補助方法によって得られた回路を検証する環境を生成する装置であって、
設計仕様書と検証手法DBの情報から検証の目的に応じたテストベクタを自動で生成するテストベクタ自動生成手段と検証すべきパラメータ値を決定するための情報が蓄えられている検証手法DBと生成されたDUTと、テストベクタ自動生成手段から生成されたテストベクタと任意のタイミングでDUTへの入出力が行なうことができるバスモデルと入力・期待値データを生成し、バスモデルを制御するテストベンチとそれらの接続を行なうテストベンチトップを含むテスト環境を生成するテスト環境自動生成手段を備えたことを特徴とする動作合成検証補助装置。
【請求項２】
前記テストベクタ自動生成手段は、設計仕様書からのパラメータ情報および生成されたDUTのインターフェース情報を用いてテストベクタを生成することを特徴とする請求項１記載の動作合成検証補助装置。
【請求項３】
設計仕様の情報を元にCアルゴリズムの機能部分に特化したテストベクタとRTL回路でのタイミングを考慮したテストベクタを区別して検証環境を出力することを特徴とする請求項２記載の動作合成検証補助装置。
【請求項４】
Cアルゴリズムの機能部分に特化したテストベクタを生成する場合は、入力されるパラメータ情報は、少なくとも、パラメータ名、パラメータ属性、ビット幅、最小値、最大値の項目を持ち、テストパラメータ自動生成手段は、パラメータ属性、ビット幅、最小値、最大値により、テストパラメータの生成方法を変更することを特徴とする請求項３記載の動作合成検証補助装置。
【請求項５】
テストパラメータ自動生成手段において、RTL回路でのタイミングを考慮したテストベクタを生成する場合は、入力されるパラメータ情報は、少なくとも、パラメータ名、ビット幅、初期値、最小値、最大値の項目を持ち、インターフェース情報はインターフェース信号間のタイミング情報を持ち、テストパラメータ自動生成手段は、パラメータ情報からはパラメータ属性、インターフェース情報からはインターフェース信号間のタイミング情報を用いて、テストパラメータを自動生成することを特徴とする請求項３記載の動作合成検証補助装置。
【請求項６】
パラメータ属性に対するパラメータ値の決定方法をパラメータ情報と、DUTのインターフェースから各インターフェース信号間のタイミング情報と、複数インターフェースがあった場合のインターフェース間のタイミング情報を持つことを特徴とする請求項１記載の動作合成検証補助装置。
【請求項７】
外部から設定可能なパラメータと、画像を走査するための副走査方向への処理ループと、主走査方向への処理ループと、を有する画像処理アルゴリズムについて、前記パラメータがレジスタであることを示す情報を追加する追加手段と、
設定されたレジスタ情報を抽出する抽出手段と、
ハードウェア化時に利用するインターフェース情報を入力する利用インターフェース情報、アルゴリズムの主走査ループ処理及び副走査ループ処理を検出し、記述変換ルールに従い前記画像処理アルゴリズムの記述変換を行なう記述変換手段と、
を備えた回路設計補助方法によって得られた回路を検証する環境を生成する方法であって、
設計仕様書と検証手法DBの情報から検証の目的に応じたテストベクタを自動で生成するテストベクタ自動生成手段と検証すべきパラメータ値を決定するための情報が蓄えられている検証手法DBと生成されたDUTと、テストベクタ自動生成手段から生成されたテストベクタと任意のタイミングでDUTへの入出力が行なうことができるバスモデルと入力・期待値データを生成し、バスモデルを制御するテストベンチとそれらの接続を行なうテストベンチトップを含むテスト環境を生成することを特徴とする動作合成検証補助方法。
【請求項８】
外部から設定可能なパラメータと、画像を走査するための副走査方向への処理ループと、主走査方向への処理ループと、を有する画像処理アルゴリズムについて、前記パラメータがレジスタであることを示す情報を追加する追加手段と、
設定されたレジスタ情報を抽出する抽出手段と、
ハードウェア化時に利用するインターフェース情報を入力する利用インターフェース情報、アルゴリズムの主走査ループ処理及び副走査ループ処理を検出し、記述変換ルールに従い前記画像処理アルゴリズムの記述変換を行なう記述変換手段と、
を備えた回路設計補助方法によって得られた回路を検証する環境を生成する装置を制御するためのプログラムであって、
コンピュータを、
設計仕様書と検証手法DBの情報から検証の目的に応じたテストベクタを自動で生成するテストベクタ自動生成手段と検証すべきパラメータ値を決定するための情報が蓄えられている検証手法DBと生成されたDUTと、テストベクタ自動生成手段から生成されたテストベクタと任意のタイミングでDUTへの入出力が行なうことができるバスモデルと入力・期待値データを生成する手段、
バスモデルを制御するテストベンチとそれらの接続を行なうテストベンチトップを含むテスト環境を生成する手段、
として機能させるためのプログラム。
【請求項９】
請求項８記載のプログラムを記録したことを特徴とする記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、動作合成検証補助装置、動作合成検証補助方法、プログラム、及び記録媒体に関する。
【背景技術】
【０００２】
従来、画像処理アルゴリズムを動作合成可能な記述へ変更した場合は、ハードウェア固有の記述も考慮したうえで生成されたモデルの検証を行なう必要がある。この際、ハードウェア固有の情報を含んだテスト環境を作るのは多くの時間を要する。
また近年の機能集約化による回路規模の増大により、検証環境もより複雑化し、人手によって検証環境を作成することによるバグの混入や、テストの漏れ、テストミスが問題視されてきている。
【０００３】
また従来のようなHDL（ハードウェア記述言語）で作成された回路は、実際のハードウェア構成を直接記述するため、検証する際もどこを検証するべきかを容易に判断できたが、動作合成の場合は、ツールそのものまたはツールの最適化機能により生成される回路が異なるため、従来のような検証するべき場所を特定することが困難である。
【０００４】
この主の問題を解決するための種々の提案がなされている（例えば、特許文献１、２参照。）。
特許文献１には、インターフェースに関する回路を自動生成しならが、自動生成した際のタイミング情報から入力タイミングを考慮したテストベンチを作成することでテストの効率化を図ることが開示されている。
【０００５】
また、特許文献２には、動作アルゴリズムから動作合成時に生成されるマルチプレクサのセレクト信号を利用して、テストベンチを自動で生成することでテストの効率化を図ることが開示されている。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、特許文献１、２に記載の技術では動作記述から情報を取得し、テストを作るという性質上、対象の動作記述が複雑になればなるほどテスト数が増大し、検証そのものの時間がかかってしまい、効率的な検証を行なうことができず、また動作記述からテストベクタを生成するため、動作アルゴリズムを記述した設計者の仕様誤認による不具合を発見できないおそれがある。
【０００７】
そこで、本発明の目的は、バグの混入や設定ミス、設定漏れの発生を抑えた動作合成検証補助装置、動作合成検証補助方法、プログラム、及び記録媒体を提供することにある。
【課題を解決するための手段】
【０００８】
上記課題を解決するため、請求項１記載の発明は、外部から設定可能なパラメータと、画像を走査するための副走査方向への処理ループと、主走査方向への処理ループと、を有する画像処理アルゴリズムについて、前記パラメータがレジスタであることを示す情報を追加する追加手段と、設定されたレジスタ情報を抽出する抽出手段と、ハードウェア化時に利用するインターフェース情報を入力する利用インターフェース情報、アルゴリズムの主走査ループ処理及び副走査ループ処理を検出し、記述変換ルールに従い前記画像処理アルゴリズムの記述変換を行なう記述変換手段と、を備えた回路設計補助方法によって得られた回路を検証する環境を生成する装置であって、設計仕様書と検証手法DBの情報から検証の目的に応じたテストベクタを自動で生成するテストベクタ自動生成手段と検証すべきパラメータ値を決定するための情報が蓄えられている検証手法DBと生成されたDUTと、テストベクタ自動生成手段から生成されたテストベクタと任意のタイミングでDUTへの入出力が行なうことができるバスモデルと入力・期待値データを生成し、バスモデルを制御するテストベンチとそれらの接続を行なうテストベンチトップを含むテスト環境を生成するテスト環境自動生成手段を備えたことを特徴とする動作合成検証補助装置。
【０００９】
請求項２記載の発明は、請求項１記載の発明において、前記テストベクタ自動生成手段は、設計仕様書からのパラメータ情報および生成されたDUTのインターフェース情報を用いてテストベクタを生成することを特徴とする。
【００１０】
請求項３記載の発明は、請求項２記載の発明において、設計仕様の情報を元にCアルゴリズムの機能部分に特化したテストベクタとRTL回路でのタイミングを考慮したテストベクタを区別して検証環境を出力することを特徴とする。
ここで、「Cアルゴリズムの機能部分に特化したテストベクタ」とは、Cアルゴリズムの論理的な部分である。
【００１１】
請求項４記載の発明は、請求項３記載の発明において、Cアルゴリズムの機能部分に特化したテストベクタを生成する場合は、入力されるパラメータ情報は、少なくとも、パラメータ名、パラメータ属性、ビット幅、最小値、最大値の項目を持ち、テストパラメータ自動生成手段は、パラメータ属性、ビット幅、最小値、最大値により、テストパラメータの生成方法を変更することを特徴とする。
【００１２】
請求項５記載の発明は、請求項３記載の発明において、テストパラメータ自動生成手段において、RTL回路でのタイミングを考慮したテストベクタを生成する場合は、入力されるパラメータ情報は、少なくとも、パラメータ名、ビット幅、初期値、最小値、最大値の項目を持ち、インターフェース情報はインターフェース信号間のタイミング情報を持ち、テストパラメータ自動生成手段は、パラメータ情報からはパラメータ属性、インターフェース情報からはインターフェース信号間のタイミング情報を用いて、テストパラメータを自動生成することを特徴とする。
【００１３】
請求項６記載の発明は、請求項１記載の発明において、パラメータ属性に対するパラメータ値の決定方法をパラメータ情報と、DUTのインターフェースから各インターフェース信号間のタイミング情報と、複数インターフェースがあった場合のインターフェース間のタイミング情報を持つことを特徴とする。
【００１４】
請求項７記載の発明は、外部から設定可能なパラメータと、画像を走査するための副走査方向への処理ループと、主走査方向への処理ループと、を有する画像処理アルゴリズムについて、前記パラメータがレジスタであることを示す情報を追加する追加手段と、設定されたレジスタ情報を抽出する抽出手段と、ハードウェア化時に利用するインターフェース情報を入力する利用インターフェース情報、アルゴリズムの主走査ループ処理及び副走査ループ処理を検出し、記述変換ルールに従い前記画像処理アルゴリズムの記述変換を行なう記述変換手段と、を備えた回路設計補助方法によって得られた回路を検証する環境を生成する方法であって、設計仕様書と検証手法DBの情報から検証の目的に応じたテストベクタを自動で生成するテストベクタ自動生成手段と検証すべきパラメータ値を決定するための情報が蓄えられている検証手法DBと生成されたDUTと、テストベクタ自動生成手段から生成されたテストベクタと任意のタイミングでDUTへの入出力が行なうことができるバスモデルと入力・期待値データを生成し、バスモデルを制御するテストベンチとそれらの接続を行なうテストベンチトップを含むテスト環境を生成することを特徴とする。
【００１５】
請求項８記載の発明は、外部から設定可能なパラメータと、画像を走査するための副走査方向への処理ループと、主走査方向への処理ループと、を有する画像処理アルゴリズムについて、前記パラメータがレジスタであることを示す情報を追加する追加手段と、設定されたレジスタ情報を抽出する抽出手段と、ハードウェア化時に利用するインターフェース情報を入力する利用インターフェース情報、アルゴリズムの主走査ループ処理及び副走査ループ処理を検出し、記述変換ルールに従い前記画像処理アルゴリズムの記述変換を行なう記述変換手段と、を備えた回路設計補助方法によって得られた回路を検証する環境を生成する装置を制御するためのプログラムであって、コンピュータを、設計仕様書と検証手法DBの情報から検証の目的に応じたテストベクタを自動で生成するテストベクタ自動生成手段と検証すべきパラメータ値を決定するための情報が蓄えられている検証手法DBと生成されたDUTと、テストベクタ自動生成手段から生成されたテストベクタと任意のタイミングでDUTへの入出力が行なうことができるバスモデルと入力・期待値データを生成する手段、バスモデルを制御するテストベンチとそれらの接続を行なうテストベンチトップを含むテスト環境を生成する手段、として機能させるためのプログラムであることを特徴とする。
【００１６】
請求項９記載の発明は、請求項８記載のプログラムを記録した記録媒体であることを特徴とする。
【発明の効果】
【００１７】
本発明によれば、設計仕様書と検証手法DB(Data Base)とを用いて、テストベクタを含む検証環境を自動で生成することにより、ヒューマンエラーの混入を防ぎながら検証精度の高い検証環境を提供することができ、従ってバグの混入や設定ミス、設定漏れの発生を抑えた動作合成検証補助装置、動作合成検証補助方法、プログラム、及び記録媒体の提供を実現することができる。
【図面の簡単な説明】
【００１８】
【図１】本発明に係る動作合成検証補助方法の一実施の形態を示すフローである。
【図２】本発明に係る動作合成検証補助装置の概要を示すハードウェア構成図である。
【図３】本発明に係る動作合成検証補助装置の構成図の一例である。
【図４】図１に示した動作合成検証補助装置における自動生成のフローの一例である。
【図５】図１に示した動作合成検証補助装置におけるテスタベクタの生成方法を説明するためのフローの一例である。
【図６】図１に示した動作合成検証補助装置におけるパラメータファイルの一例である。
【図７】図１に示した動作合成検証補助装置における制約ファイルの一例である。
【図８】図１に示した動作合成検証補助装置におけるテストベクタの一例である。
【発明を実施するための形態】
【００１９】
本願発明は、本出願人による特願２００８−３１４１１２の改良発明である。
特願２００８−３１４１１２は、「ハードウェア化構成検討」から「機能モデル作成」までの作業を補助するための発明であり、本願発明は、「機能モデル検証」及び「RTL機能・性能検証」を行なうための環境作成の補助を行なうための発明である。
【００２０】
従って、「追加手段」、「抽出手段」、及び「記述変換手段」については、特願２００８−３１４１１２の明細書（特に段落「００１８」）を参照されたい。
【００２１】
本発明の実施の形態について図面を参照して説明する。
図１は、本発明に係る動作合成検証補助方法の一実施の形態を示すフローである。
はじめに図１を参照して動作合成について述べる。
フローは大きく分けて、「アルゴリズム開発フェーズ」（フェーズP1-1）と「動作合成フェーズ」(フェーズP1-2)との二つに分けられる。
「アルゴリズム開発フェーズ」では、アルゴリズムの開発を行なう(ステップS1-1-1,S1-1-2)。アルゴリズムはソフトウェアとして開発される。その後、ハードウェア化を行なうか否かの判断がなされ(ステップS1-1-3)、ハードウェア化を行なう場合(YES)は動作合成フェーズへ移行する。ハードウェア化されない場合(NO)は、そのままソフトウェアとして実装される(ステップS1-1-4)。
【００２２】
「動作合成フェーズ」は、ソフトウェアで実装されたアルゴリズムをハードウェア化するフェーズである。「動作合成フェーズ」は「ハードウェア化構成検討」(ステップS1-2-1)、「機能モデル作成」(ステップS1-2-2)、「機能モデル検証」(ステップS1-2-3)、「RTL(Resister Transistor Logic：抵抗トランジスタ論理)回路生成」(ステップS1-2-4)、「RTL機能、性能検証」(ステップS1-2-5)から構成される。
【００２３】
「ハードウェア化構成検討」(ステップS1-2-1)では、RAM(Random Access Memory)容量やスループット、レイテンシ、パイプラインを考慮したアルゴリズムの書き換え方の検討を行なう。
尚、「スループット」とは、コンピュータの単位時間当たりの処理量である。「レイテンシ」とは、データの転送要求などのリクエストを発してから、リクエストの要求が返ってくるまでにかかる遅延時間のことである。「パイプライン」とは、コンピュータにおける処理要素を直列に連結したものである。
【００２４】
「機能モデル作成」(ステップS1-2-2)では、「ハードウェア化構成検討」で検討された内容にしたがい、機能モデルの作成を行なう。
【００２５】
「機能モデル検証」(ステップS1-2-3)では、「機能モデル作成」で作成した機能モデルが「ハードウェア化構成検討」で検討された結果を満たす否か、また、書き換えによりアルゴリズムの機能に不具合が混入していないか否かを確認する。
【００２６】
「RTL回路生成」(ステップS1-2-4)では、作成された機能モデルからRTLを生成する。動作合成ツールといわれるものはこの部分を行なうものである。
【００２７】
「RTL機能・性能検証」(ステップS1-2-5)では、「RTL回路生成」で生成されたRTLが要求された機能を満たすか否かを確認する。動作モデルが関数の呼び出しによりデータを受け渡す（untimed simulation）のに対し、RTL回路は信号レベルでのデータ受け渡しを行なう(timed simulation)ことになる。よって「RTL機能・性能検証」では信号レベルの受け渡しタイミングの変化により、動作・性能に影響がないかを確かめている。
【００２８】
図２は、本発明に係る動作合成検証補助装置の概要を示すハードウェア構成図である。
10は、検証環境自動生成プログラムを実行するCPU(Central Processing Unit：中央演算処理装置)である。
11は、プログラムへの実行命令およびプログラムの実行結果を出力(表示)する入出力装置である。
12は、検証環境自動生成プログラム実行時に利用するメモリである。
13は、検証手法DBおよび出力される検証環境を保存するHDDである。
14は、検証手法DBである。検証手法DB(14)については、実際の動作説明で詳細を説明する。
15は、出力結果を表示するモニタである。
16は、インターネット接続するためのネットワークである。
検証手法DB(14)や検証環境自動生成プログラム自体もネットワーク上に存在していても良い。
【００２９】
図３は、本発明に係る動作合成検証補助装置の構成図の一例である。
テストベンチトップ（5-14）で囲まれている部分が生成された機能モデル及びRTL回路の機能検証、機能・性能検証を行なう環境であり、今回自動で生成するテスト環境である。
「DUT(Device Under Test)」(5-10)は「機能モデル作成」で作られた機能モデル及び動作合成ツールにより出力されたRTL回路を指す。
「バスモデル」(5-9,5-11)は、DUTの機能や性能を検証するためにDUTとのデータ通信を行なうモデルである。
「テストベンチ」(5-15)は、DUTの機能や性能を検証するための環境である。「テストベンチ」は、「入力データ」(5-5)、「期待値データ」(5-7)、「テストシナリオ」(5-6)、「パラメータ」(5-8)、及び「Cアルゴ（アルゴリズム開発フェーズで作成したアルゴリズムのこと）」(5-4)から構成される。
【００３０】
「入力データ」(5-5)はDUTに対してバスモデル(5-9,5-11)が与えるデータを保持するデータベースである。
「期待値データ」(5-7)はDUTから出力されると予測されるデータを保持するデータベースである。
バスモデル(5-9,5-11)はDUTから出力されたデータと期待値データを比較して、予測通りにデータが出力されたか否かを確認する。
「パラメータ」(5-8)はDUTやバスモデル(5-9,5-11)に対して動作内容の指示を行なうためのデータ群である。
「テストシナリオ」(5-6)は、DUTの動作やバスモデル(5-9,5-11)の動作を指示するテストのためのシナリオである。
【００３１】
「Cアルゴ」(5-4)は、アルゴリズム開発フェーズで作成されたソフトウェアであり、入力データから期待値データを作成する。斜線部分が本動作合成検証補助装置における自動生成プログラム部分である。
「検証手法DB」(5-1)は、検証手法を登録してあるDBである。レジスタの種類やI/F(インターフェース)の種類、FIFO(First In First Out：先入れ先出し)の段数やバス幅をキーとして、効果のある検証手法を引き出すことが可能である。
テストベクタ自動生成手段としての「テストベクタ自動生成装置」(5-2)は、DUTやバスモデル(5-9,5-11)へ与える制御パラメータの組み合わせをテスト仕様書に従い、自動で生成する装置である。詳細は、「変換フロー」で説明する。
「テスト環境自動生成装置」(5-3)は、テストベンチ構成と、テストベンチとDUT、バスモデルの接続を記述するテストベンチトップとを生成する。
「DUT自動生成装置」(5-4)は、設計仕様書およびCアルゴからハードウェアを考慮したC++記述を自動で生成する装置である。
【００３２】
ここで、設計仕様書には「端子情報(回路端子の入出力方向やバス幅)」、「インターフェース情報(回路信号のタイミング情報)」、「レジスタ情報(名前、属性、ビット幅、最小値、最大値、初期値)」が含まれる。
【００３３】
図４は、図１に示した動作合成検証補助装置における自動生成のフローの一例である。
図４を参照して、自動生成のフローを説明する。
初めに、与えられたCアルゴリズム(画像処理アルゴリズム、もしくはC言語で記述されたソースコード)と設計情報とからDUTの生成を行なう(ステップS6-1)。
次に、DUT生成時に抽出された端子情報、パラメータ情報を利用し、テスト環境の自動生成を行なう。はじめに設計仕様からテストを行なうパラメータを抽出する(ステップS6-2)。
パラメータ情報には少なくともパラメータ名、パラメータ属性、ビット幅、最小値、最大値の項目が含まれる。それぞれの情報の詳細は図５で説明する。また、DUTの生成から得られるインターフェース情報を元に検証手法DBからテストパラメータを取得する(ステップS6-3)。
インターフェース情報には、起動トリガ、起動タイミングの情報が含まれる。また、そのインターフェースをテストするためのバスモデルを同時に取得しておく（S6-4）。
【００３４】
次にステップS6-2,S6-3で得られた情報からテストベクタの生成を行う(ステップS6-5)。
テストベクタは機能モデル検証用とRTL機能・性能検証用の少なくとも２種類のテストベクタが生成される。詳細な説明は、図５で行なう。
【００３５】
次に生成されたDUT、取得したバスモデルの接続とシミュレーションを制御するテストベンチの生成を行なう(ステップS6-6)。
バスモデルとDUTとの接続はインターフェースが既知のため接続は容易である。また、バスモデルは入力データや出力データを保持するバッファと接続される。これはソフトウェア上で接続されるため、接続は容易である。また、これらの接続方法がわかれば、テストベンチおよびテストベンチトップ等のテスト環境を構築するのも容易である。最後にテストベクタの組み込みを行なう(ステップS6-8)。
テストベクタの組み込み時は、機能モデル検証とRTL機能・性能検証の両方で利用できるようにフラグを用意する。このフラグは、利用するテストベクタおよびバスモデルの切り替えを行なう。
【００３６】
テストベクタの生成方法について図５を参照して説明する。
図５は、図１に示した動作合成検証補助装置におけるテスタベクタの生成方法を説明するためのフローの一例である。図６は、図１に示した動作合成検証補助装置におけるパラメータファイルの一例である。
【００３７】
はじめにパラメータ情報を利用してパラメータ設定値情報の生成を行なう(ステップS7-1)。
パラメータ情報には図６のようにパラメータ名、属性、ビット幅、初期値、最小値、最大値、分割方法が含まれる。パラメータ名はパラメータの名前である。属性はそのパラメータがどのように使われるかを表す。
設計によりさまざまな種類のパラメータが得られるが、機能の動作モードを設定するパラメータにはそれを示すフラグ(図６でのMODE)、動作を制御するパラメータにはそれを示すフラグ(図６でのPARAM)を指定する。
ビット幅はそのパラメータの持つビット幅である。初期値はそのパラメータがリセット時にセットされる値である。最小値はそのパラメータに設定可能である最小値である。最大値はそのパラメータに設定可能である最大値である。分割方法は、そのパラメータをテストするためにどのような方法でパラメータを設定するかを指定する。これは一般に境界値分析や同値分割などが一般的である。
【００３８】
また、この分割方法はFIFOの段数等のハードウェアの構成に適した分割方法や画像処理アルゴリズムの種類によって必要な分割方法を決定しておくことで、より精度の高いテストベクタを生成することが可能である(ステップS7-2)。
【００３９】
次にパラメータ展開方法について説明する。
はじめに、パラメータ分割方法が記述されているかを確認する。パラメータ分割方法が記述されている場合は、その分割方法に従いパラメータ値の決定を行なう。パラメータ分割方法が記述されていない場合は、パラメータの属性を利用して、検証手法DBから分割方法を取得する。
【００４０】
属性情報をより詳細に決めることで精度の高いテストベクタを生成することが可能である。また、生成したDUTのインターフェース情報からそのインターフェースの検証に必要なパラメータを取得する。これは主にインターフェースの信号間のタイミング情報である。タイミング情報として、複数インターフェースを持つ場合のインターフェース間のタイミング情報やデータ入力とデータ出力のタイミング情報を付加することでさらに精度の高いテストベクタを生成することが可能である。得られたパラメータ設定値情報およびタイミング情報からテストベクタの生成を行なう。このとき、テストベクタを機能検証用テストベクタとRTL機能・パフォーマンス検証用テストベクタの２つのテストベクタの生成を行なう。
【００４１】
機能検証用テストベクタ生成時には、パラメータ設定値情報からパラメータ間の組み合わせを行ない、テストベクタの生成を行なう。
また、RTL・パフォーマンス検証用のテストベクタ生成時はパラメータの属性がMODEであるものと、タイミング情報からアルゴリズムの組み合わせを生成する(ステップS7-3)。
【００４２】
組み合わせの生成方法にはpair-wise法やHAYST法といった一般的な方法から、タイミング情報やパラメータの属性を利用して組み合わせを生成しても良く、必要に応じて最適な組み合わせ生成アルゴリズムを選択するとよい。このとき、効率よいテストベクタを生成するためにパラメータ間の制約条件を付加するとよい。
制約はパラメータ間での成り立たない条件、または必ず成り立つ条件を指定する。たとえば、図７に示すように２パラメータ間の条件を式として記述し、パラメータ設定情報で設定された値をこの制約式に代入することで成り立たない組み合わせを調べることが可能となり、組み合わせの作成時にパターンを減らすことが可能となる。尚、図７は、図１に示した動作合成検証補助装置における制約ファイルの一例である。
【００４３】
また、関連の強い複数のパラメータによりパラメータグループを生成し、組み合わせをグループ内の組み合わせとグループ間の組み合わせからテストベクタを生成することで、関連の強いパラメータ間での検証精度をあげることも可能である。
【００４４】
すなわち、制約展開を行い(ステップS7-3-1)、固定値組合せを解除し(ステップS7-3-2)、グループ組合せ番号を追加し(ステップS7-3-3)、組合せアルゴリズムを作成することで(S7-3-4)、データマージが得られる(ステップS7-3-5)。
【００４５】
このようにして図８に示すようなテストベクタを生成する。図８において、横軸はパラメータ名となり、縦軸はテストベクタとなる。尚、図８は、図１に示した動作合成検証補助装置におけるテストベクタの一例である。
【００４６】
＜プログラム＞
以上で説明した本発明にかかる動作合成検証補助装置は、コンピュータで処理を実行させるプログラムによって実現されている。コンピュータとしては、例えばパーソナルコンピュータやワークステーションなどの汎用的なものが挙げられるが、本発明はこれに限定されるものではない。よって、一例として、プログラムにより本発明を実現する場合の説明を以下で行う。
【００４７】
外部から設定可能なパラメータと、画像を走査するための副走査方向への処理ループと、主走査方向への処理ループと、を有する画像処理アルゴリズムについて、パラメータがレジスタであることを示す情報を追加する追加手段と、
設定されたレジスタ情報を抽出する抽出手段と、
ハードウェア化時に利用するインターフェース情報を入力する利用インターフェース情報、アルゴリズムの主走査ループ処理及び副走査ループ処理を検出し、記述変換ルールに従い画像処理アルゴリズムの記述変換を行なう記述変換手段と、
を備えた回路設計補助方法によって得られた回路を検証する環境を生成する装置を制御するためのプログラムであって、
コンピュータを、
(A)  設計仕様書と検証手法DBの情報から検証の目的に応じたテストベクタを自動で生成するテストベクタ自動生成装置と検証すべきパラメータ値を決定するための情報が蓄えられている検証手法DBと生成されたDUTと、テストベクタ自動生成手段から生成されたテストベクタと任意のタイミングでDUTへの入出力が行なうことができるバスモデルと入力・期待値データを生成する手段、
(B)  バスモデルを制御するテストベンチとそれらの接続を行なうテストベンチトップを含むテスト環境を生成する手段、
として機能させるためのプログラムが挙げられる。
【００４８】
これにより、プログラムが実行可能なコンピュータ環境さえあれば、どこにおいても本発明にかかる動作合成検証補助装置を実現することができる。
このようなプログラムは、コンピュータに読み取り可能な記憶媒体に記憶されていてもよい。
【００４９】
＜記憶媒体＞
ここで、記憶媒体としては、例えば、CD-ROM(Compact Disc Read Only Memory)、フレキシブルディスク(FD)、CD-R(CD Recordable)などのコンピュータで読み取り可能な記憶媒体、フラッシュメモリ、RAM(Random Access Memory)、ROM(Read Only Memory)、FeRAM(強誘電体メモリ)等の半導体メモリやHDD(Hard Disc Drive)が挙げられる。
【００５０】
＜効  果＞
本実施形態によれば、設計仕様書と検証手法DBを用いて、テストベクタを含む検証環境を自動で生成しているので、ヒューマンエラーの混入を防ぎながら検証精度の高い検証環境を提供できる。
【００５１】
また、本実施形態によれば、パラメータ情報および生成されたDUTのインターフェース情報を利用してテストベクタを自動生成するのでCのアルゴリズムだけでなく、DUTの検証環境としても利用できる検証環境を提供できる。
【００５２】
また、本実施形態によれば、検証目的に応じたテストベクタを生成するので、ヒューマンエラーの混入を防ぎながら検証を効率的に進めることができる検証環境を提供できる。
【００５３】
また、本実施形態によれば、機能検証用テストベクタとして、パラメータ情報のみでテストベクタを生成することで、ヒューマンエラーの混入を防ぎながら検証目的に応じた証環境を提供できる。
【００５４】
また、本実施形態によれば、RTL・性能検証用テストベクタとして、パラメータ情報のパラメータ属性およびインターフェース情報からテストベクタを生成しているので、ヒューマンエラーの混入を防ぎながら検証目的に応じた証環境を提供できる。
【００５５】
また、本実施形態によれば、パラメータ属性に応じたパラメータ値決定方法、インターフェースのタイミング情報、複数インターフェースを持つ場合のインターフェース間のタイミング情報を持っているので、パラメータの振り方やタイミングに関して担当者の違いによるテストベクタの違いが軽減され、検証すべきことが行なわれている精度の高い検証環境を提供できる。
【００５６】
なお、上述した実施の形態は、本発明の好適な実施の形態の一例を示すものであり、本発明はそれに限定されることなく、その要旨を逸脱しない範囲内において、種々変形実施が可能である。
【符号の説明】
【００５７】
５−１、１４    検証手法ＤＢ
５−２    テストベクタ自動生成装置
５−３    テスト環境自動生成装置
５−４、５−１３    Ｃアルゴ
５−５    入力データ
５−６    テストシナリオ
５−７    期待値データ
５−８    パラメータ
５−９、５−１１    バスモデル
５−１０    ＤＵＴ
５−１２    ＤＵＴ自動生成装置
５−１４    テストベンチトップ
５−１５    テストベンチ
１０    ＣＰＵ
１１    入出力装置
１２    メモリ
１３    ＨＤＤ
１５    モニタ
１６    ネットワーク
【先行技術文献】
【特許文献】
【００５８】
【特許文献１】特開２００８−１８６２５２号公報
【特許文献２】特開２００５−７８４０２号公報
【図１】
2011053764.tif 000003
【図２】
2011053764.tif 000004
【図３】
2011053764.tif 000005
【図４】
2011053764.tif 000006
【図５】
2011053764.tif 000007
【図６】
2011053764.tif 000008
【図７】
2011053764.tif 000009
【図８】
2011053764.tif 000010