【文献】
垣内洋介 外3名,モニタベース形式検証のための入力制約を考慮したモニタ回路生成手法,電子情報通信学会論文誌D,社団法人電子情報通信学会,2006年 4月 1日,Vol. J89-D, No. 4,pp. 674 - 682
【文献】
松本剛史 外4名,反例を利用した網羅性の高いプロパティ集合生成手法,情報処理学会研究報告,社団法人情報処理学会,2008年11月10日,Vol. 2008, No. 111,pp. 115 - 120
(58)【調査した分野】(Int.Cl.,DB名)
前記入力制約記憶部は、前記動的検証の前記出力結果として、前記動的検証の出力ダンプファイルを変換した入力制約を記憶している、請求項1に記載のフォーマル検証装置。
【発明を実施するための形態】
【0011】
以下、図面を参照して本発明によるフォーマル検証装置およびプログラムの実施形態を説明する。ただし、本発明は以下の実施形態に限定されない。
【0012】
まず、
図1を参照して、本実施形態のフォーマル検証装置100を説明する。
図1(a)に、本実施形態のフォーマル検証装置100の模式図を示す。フォーマル検証装置100は、入力制約記憶部112と、アサーション記憶部114と、論理回路記憶部116と、フォーマル検証部122とを備える。入力制約記憶部112は入力制約を記憶している。アサーション記憶部114は検証用のアサーションを記憶している。論理回路記憶部116は検証用の論理回路を記憶している。フォーマル検証部122は、入力制約記憶部112、アサーション記憶部114および論理回路記憶部116から、入力制約、アサーションおよび論理回路をそれぞれ読み出し、入力制約、アサーションおよび論理回路に基づいてフォーマル検証を行う。
【0013】
フォーマル検証装置100は、入力部130および表示部140をさらに備える。例えば、入力部130は、タッチパネル、キーボードおよび/またはマウスを含む。表示部140はディスプレーを含む。
【0014】
フォーマル検証の結果、エラーがあった場合、表示部140は、ユーザーにエラーを表示する。ユーザーは、表示部140に表示されたエラーに基づき、入力部130を用いて、入力制約記憶部112の入力制約、アサーション記憶部114のアサーション、および、論理回路記憶部116の論理回路のいずれかを修正する。
【0015】
例えば、ユーザーが、エラーが入力制約の不具合または不備に起因していると判定すると、ユーザーは、入力部130を用いて、入力制約記憶部112に記憶された入力制約を修正する。また、ユーザーが、エラーがアサーションの不具合に起因していると判定すると、ユーザーは、入力部130を用いて、アサーション記憶部114に記憶されたアサーションを修正する。あるいは、ユーザーが、エラーが論理回路の不具合に起因していると判定すると、ユーザーは、入力部130を用いて、論理回路記憶部116に記憶された論理回路を修正する。
【0016】
上述したように、入力制約、アサーションおよび論理回路のいずれかを修正した後、フォーマル検証部122は、再び、入力制約記憶部112、アサーション記憶部114および論理回路記憶部116から、入力制約、アサーションおよび論理回路をそれぞれ読み出し、再度、入力制約、アサーションおよび論理回路に基づいてフォーマル検証を行う。フォーマル検証装置100は、フォーマル検証後のエラーが無くなるまで、入力制約、アサーションおよび論理回路のいずれかの修正およびフォーマル検証を繰り返す。
【0017】
記憶部110は、入力制約記憶部112と、アサーション記憶部114と、論理回路記憶部116とを含む。記憶部110は、例えば、ハードディスク、ROM(Read Only Memory)またはRAM(Random Access Memory)を含む。ROMは、例えば、フラッシュメモリー等のPROM(Programmable ROM)である。RAMは、例えば、DRAM(Dynamic RAM)である。典型的には、記憶部110を構成する1つの記憶手段が、入力制約記憶部112、アサーション記憶部114および論理回路記憶部116のすべてを含んでいる。ただし、記憶部110が複数の記憶手段から構成され、入力制約記憶部112、アサーション記憶部114および論理回路記憶部116は分離されていてもよい。
【0018】
制御部120は、フォーマル検証部122を含む。制御部120は、フォーマル検証部122によってフォーマル検証を行うだけでなく、入力部130および表示部140を制御する。制御部120は、CPUによって具現化される。制御部120は、記憶部110に記憶されたデータを用いて、記憶部110に記憶されたプログラムを実行することにより、設計回路のフォーマル検証を行う。
【0019】
例えば、ROMには、制御部120によって実行される各種のコンピュータープログラム(例えば、ソフトウェアまたはファームウェア)が記憶される。制御部120は、実行対象のコンピュータープログラムをハードディスクまたはROMからRAMにロードし、ロードしたプログラムを実行する。
【0020】
本実施形態のフォーマル検証装置100において、入力制約記憶部112は、動的検証の入力条件または動的検証の出力結果を入力制約として記憶している。動的検証の入力条件は、例えば、動的検証のテストベクターである。動的検証の出力結果は、例えば、動的検証のダンプファイルである。動的検証の入力条件または出力結果は、論理回路の検証の終了した入力条件または出力結果であることが好ましい。以上のように、本実施形態のフォーマル検証装置100は、動的検証の入力条件または出力結果を入力制約として利用する。動的検証の入力条件または出力結果は動的検証装置から導出される。
【0021】
図1(b)に、動的検証装置200の模式図を示す。動的検証装置200は、テストベンチ記憶部212と、RTL記憶部214と、動的検証部222と、ダンプファイル生成部224と、入力部230と、表示部240とを備える。例えば、入力部230は、キーボードおよび/またはマウスを含む。表示部240はディスプレーを含む。
【0022】
テストベンチ記憶部212は、動的検証のためのテストベクターを記憶している。RTL記憶部214はレジスター転送レベル(Register Tranfer Level)で記載された論理回路を記憶している。記憶部210は、テストベンチ記憶部212およびRTL記憶部214を含む。
【0023】
動的検証部222は、テストベクターおよび論理回路に基づいて動的検証を行う。動的検証部222による動的検証の結果、テストベクターの各入力値に対して出力値が得られる。ダンプファイル生成部224は、動的検証部222の検証結果に基づきダンプファイルを生成する。ダンプファイルには、テストベクターの入力値と、入力値に対応する出力値とが記述されている。制御部220は、動的検証部222およびダンプファイル生成部224を含む。制御部220は、CPUによって具現化される。制御部220は、記憶部210に記憶されたデータを用いて、記憶部210に記憶されたプログラムを実行することにより、動的検証を実行する。
【0024】
動的検証の結果、エラーがあった場合、表示部240は、エラーが発生したことを表示する。例えば、動的検証を行った後、表示部240は、動的検証の結果を示すログを表示してもよい。また、表示部240は、ダンプファイル生成部224によって生成されたダンプファイルに基づく波形を表示してもよい。
【0025】
動的検証の結果、エラーがあった場合、ユーザーは、入力部230を用いて、テストベンチ記憶部212のテストベクターおよびRTL記憶部214の論理回路のいずれかを修正する。具体的には、ユーザーが、表示部240の表示に基づいて、エラーがテストベクターの不具合に起因していると判定すると、ユーザーは、入力部230を用いて、テストベンチ記憶部212に記憶されたテストベクターを修正する。あるいは、ユーザーが、エラーが論理回路の不具合に起因していると判定すると、ユーザーは、入力部230を用いて、RTL記憶部214に記憶された論理回路を修正する。なお、動的検証の結果、エラーがない場合、論理回路の検証を終了する。
【0026】
本実施形態のフォーマル検証装置100は、動的検証の入力条件または出力結果を利用してフォーマル検証を行う。典型的には、フォーマル検証装置100は、フォーマル検証の前に行われた動的検証の入力条件または出力結果を利用するため、ユーザーは、フォーマル検証および動的検証の両方のアプローチから論理回路を検証できる。
【0027】
本実施形態においてフォーマル検証は、動的検証の入力条件または出力結果に基づいて行われる。以下に、
図1(a)および
図3を参照して本実施形態のフォーマル検証装置100によるフォーマル検証方法を説明するのに先立ち、
図1(b)および
図2を参照して動的検証装置200による動的検証を説明する。
【0028】
ステップS1aにおいて、動的検証部222は、テストベンチ記憶部212からテストベクターを読み出す。また、ステップS1bにおいて、動的検証部222は、RTL記憶部214から論理回路を読み出す。
【0029】
次に、ステップS2において、動的検証部222は動的検証を行う。動的検証部222は、読み出したテストベクターおよび論理回路に基づいて動的検証を行う。動的検証部222が動的検証を行うと、テストベクターの入力値に対応する出力値が得られる。ダンプファイル生成部224は、動的検証部222の検証結果に基づきダンプファイルを生成する。ダンプファイルには、テストベクターの入力値と、入力値に対応する出力値とが記述されている。その後、ステップS3において、ユーザーは、動的検証の検証結果を分析する。
【0030】
ステップS4において、ユーザーは、論理回路の検証を終了すべきか否か判定する。ステップS4において、ユーザーが、論理回路の検証を終了すべきと判定する場合(ステップS4においてYesの場合)、検証を終了する。ステップS4において、ユーザーが、論理回路の検証を終了すべきではないと判定した場合(ステップS4においてNoの場合)、ステップS5においてユーザーは、テストベクターの不具合に起因したエラーがあるか否かを判定する。
【0031】
ユーザーが、ステップS5においてテストベクターの不具合に起因したエラーがあると判定した場合(ステップS5においてYesの場合)、ユーザーは、ステップS6において入力部230を用いてテストベンチ記憶部212に記憶されたテストベクターを修正する。その後、ステップS1a、S1bにおいて、テストベクターおよび論理回路を読み出し、再び、ステップS2において動的検証を実行し、ステップS3において検証結果を分析する。
【0032】
ユーザーが、ステップS5においてテストベクターの不具合に起因したエラーはないと判定した場合(ステップS5においてNoの場合)、ユーザーは、ステップS7において、RTL記憶部214に記憶された論理回路を修正する。その後、ステップS1a、S1bにおいて、テストベクターおよび論理回路を読み出し、再び、ステップS2において動的検証を実行し、ステップS3において検証結果を分析する。なお、テストベクターおよび論理回路の修正は、論理回路の検証が終了するまで繰り返される。以上のようにして動的検証が行われる。
【0033】
次に、
図1(a)および
図3を参照して、本実施形態のフォーマル検証方法を説明する。
【0034】
ステップS11aにおいて、フォーマル検証部122は、入力制約記憶部112から入力制約として、動的検証の入力条件または出力結果を読み出す。ステップS11bにおいて、フォーマル検証部122は、アサーション記憶部114からアサーションを読み出す。ステップS11cにおいて、フォーマル検証部122は、論理回路記憶部116から論理回路を読み出す。
【0035】
次に、ステップS12において、フォーマル検証部122は、フォーマル検証を実行する。フォーマル検証は、入力制約、アサーションおよび論理回路に基づいて行われる。検証結果にエラーがあった場合、表示部140は、エラーがあったことを表示する。その後、ステップS13において、ユーザーは、フォーマル検証の検証結果を分析する。
【0036】
ステップS14において、ユーザーは、論理回路の検証を終了すべきか否か判定する。ステップS14において、ユーザーが、論理回路の検証を終了すべきと判定した場合(ステップS14においてYesの場合)、検証を終了する。ステップS14において、ユーザーが、論理回路の検証を終了すべきではないと判定した場合(ステップS14においてNoの場合)、ステップS15において、ユーザーは、エラーが入力制約の不具合または不備に起因しているか否か(疑似エラーか否か)を判定する。
【0037】
ユーザーが、ステップS15においてエラーが入力制約の不具合または不備に起因していると判定した場合(ステップS15においてYesの場合)、ユーザーは、ステップS16において、入力部130を介して、入力制約記憶部112に記憶された入力制約を修正する。ただし、本実施形態では、入力制約として、動的検証の入力条件または出力結果を用いているため、一般にユーザーが入力制約を作成する場合と比べて、疑似エラーの発生を抑制できる。
【0038】
その後、ステップS11a、ステップS11bおよびステップS11cにおいて、フォーマル検証部122は、入力制約、アサーションおよび論理回路を読み出し、再び、ステップS12においてフォーマル検証を実行し、ステップS13において検証結果を分析する。
【0039】
ユーザーが、ステップS15においてエラーが入力制約の不具合または不備に起因していないと判定した場合(ステップS15においてNoの場合)、ユーザーは、ステップS17において、エラーがアサーションの不具合に起因しているか否かを判定する。ユーザーが、ステップS17においてエラーがアサーションの不具合に起因していると判定した場合(ステップS17においてYesの場合)、ユーザーは、ステップS18において、入力部130を介して、アサーション記憶部114に記憶されたアサーションを修正する。その後、ステップS11a、ステップS11bおよびステップS11cにおいて、フォーマル検証部122は、入力制約、アサーションおよび論理回路を読み出し、再び、ステップS12においてフォーマル検証を実行し、ステップS13において検証結果を分析する。
【0040】
ユーザーが、ステップS17においてエラーがアサーションの不具合に起因していないと判定した場合(ステップS17においてNoの場合)、エラーは入力制約およびアサーションのいずれにも起因していないため、ユーザーは、ステップS19において、入力部130を介して、論理回路記憶部116に記憶された論理回路を修正する。その後、フォーマル検証部122は、ステップS11a、ステップS11bおよびステップS11cにおいて、入力制約、アサーションおよび論理回路を読み出し、再び、ステップS12においてフォーマル検証を実行し、ステップS13において検証結果を分析する。なお、入力制約、アサーションおよび論理回路の修正は、論理回路の検証が終了するまで繰り返される。以上のようにしてフォーマル検証が行われる。
【0041】
なお、本実施形態のフォーマル検証装置100は、少なくとも部分的に動的検証装置200と構成を共有することが好ましい。例えば、本実施形態のフォーマル検証装置100の制御部120は、動的検証装置200の制御部220と同一のCPUによって具現化されてもよい。また、動的検証装置200の制御部220は、動的検証の動的検証の入力条件または出力結果を、自動的に入力制約記憶部112に記憶してもよい。
【0042】
ここで、
図4を参照して、一般的なフォーマル検証における入力制約および動的検証のテストベクターの具体例を説明する。
図4(a)は一般的なフォーマル検証における入力制約の記述の一例を示す。フォーマル検証において、入力制約は、一般に、特性仕様言語(Property Specification Language:PSL)で記述される。
図4(a)に示された入力制約は、intr信号が立ち上がった後、clk信号が2回立ち上がり、iack信号がゼロになることを示している。ここでは、clk信号およびintr信号が入力信号であり、iack信号が出力信号である。
【0043】
これに対して、
図4(b)は動的検証のテストベクターの一例を示す。
図4(b)に示されたテストベクターは、以下のように記述されている。
【0044】
intr信号が立ち上がった場合、clk信号が3回立ち上がるまでサイクルを進める。この場合に、iack信号が立ち上がっていると、アサーションが正しいことを示す記述「Assertion Success」およびそのサイクル(時刻)を表示させ、このブロック内の処理を中止する。
【0045】
一方、iack信号が立ち上がっていないと、clk信号がさらに4回立ち上がるまでサイクルを進め、アサーションが誤っていることを示す記述「Assertion Failuer」およびそのサイクル(時刻)を表示させ、このブロック内の処理を中止する。
【0046】
図4(a)に示した入力制約は
図4(b)に示したテストベクターと等価である。本実施形態では、
図4(b)に示された動的検証のテストベクターがフォーマル検証の入力制約として変換することなく用いられる。
【0047】
なお、
図4(a)および
図4(b)の比較から理解されるように、一般に、動的検証のテストベクターの記述は、対応するフォーマル検証の入力制約の記述と比べると長くなる傾向がある。また、動検証のテストベクターをフォーマル検証の入力制約として用いた場合、ある範囲内において網羅的な検証は行われない。しかしながら、フォーマル検証の入力制約をいきなり適切に作成することは困難であり、本実施形態により、疑似エラーの発生を抑制し、他の箇所でのフォーマル検証による網羅的な検証を効率的に行うことができる。
【0048】
なお、
図4を参照して上述した説明では、フォーマル検証の入力制約として動的検証のテストベクターを用いたが、本発明はこれに限定されない。フォーマル検証の入力制約として動的検証の出力結果を用いてもよい。
【0049】
ここで、
図5(a)を参照して動的検証の出力結果(ダンプファイル)の一例を説明する。
図5(a)は動的検証によって得られたダンプファイルを示す。
【0050】
ここでも、clk信号およびintr信号は入力信号であり、iack信号は出力信号である。
図5(a)に示したダンプファイルでは、入力信号であるclk信号およびintr信号をclk、intrで示しており、出力信号であるiack信号をiackで示している。clk信号、intr信号およびiack信号のそれぞれの値は、サイクルに応じて0または1のいずれかに変化する。
【0051】
図5(a)には、サイクル0〜5の場合の入力信号の値(入力値)および出力信号の値(出力値)が記載されている。サイクル0の場合、clk信号は0であり、intr信号は0であり、iack信号は0である。サイクル1の場合、clk信号は1であり、intr信号は1であり、iack信号は0である。サイクル2の場合、clk信号は0であり、intr信号は1であり、iack信号は0である。サイクル3以降、clk信号、intr信号、iack信号はサイクルに応じて変化する。
【0052】
図5(b)に、
図5(a)のダンプファイルを変換して生成した入力制約を示す。
図5(b)の入力制約は、以下のように記述されている。
【0053】
intr信号が立ち上がった場合、clk信号が3回立ち上がるまでサイクルを進める。この場合、iack信号が立ち上がっていると、アサーションが正しいことを示す記述「Assertion Success」およびそのサイクル(時刻)を表示させ、このブロック内の処理を中止する。
【0054】
一方、iack信号が立ち上がっていないと、clk信号が4回立ち上がるまでサイクルを進め、アサーションが誤っていることを示す記述「Assertion Failure」およびそのサイクル(時刻)を表示させ、このブロック内の処理を中止する。
【0055】
図5(a)に示したダンプファイルは
図5(b)に示した入力制約と等価である。
図5(b)に示したフォーマル検証の入力制約は、
図5(a)に示したダンプファイルから生成可能である。
【0056】
なお、
図4および
図5を参照して上述した動的検証の入力条件および出力結果は一例であり、動的検証の入力条件および出力結果はこれらに限定されないことは言うまでもない。
【0057】
また、上述した説明では、フォーマル検証を開始する前に、動的検証による論理回路の検証は終了していたが、本発明はこれに限定されない。フォーマル検証の一部を開始した後に、動的検証による論理回路の検証を終了するまで実行し、その後、引き続いてフォーマル検証を行ってもよい。