LSI開発では、設計仕様を基にRTLで設計された論理回路の機能、動作を、コンピュータを用いた論理シミュレーションを行って検証する。
図1に論理シミュレーション環境の一例を示す。
論理シミュレーション環境は、コンピュータ100を用いて構築される。コンピュータ100は、CPU(Central Processing Unit)101によって装置全体が制御される。CPU101には、バス110を介して、ROM(Read Only Memory)102及びRAM(Random Access Memory)103が接続される。ROM102には、シミュレーションを行う論理回路を制御するファームウェア等のプログラムが格納される。RAM103には、CPU101に実行させるOS(Operating System)のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、RAM103には、CPU101による処理に必要な各種データが格納される。
バス110には、複数の周辺機器が接続される。バス110に接続される周辺機器としては、ハードディスクドライブ(Hard Disk Drive;HDD)104、通信インタフェース105、キーボード106、マウス107等がある。
HDD104は、ハードディスク(Hard Disk;HD)104aに対して磁気的にデータの書き込み及び読み出しを行う。HDD104には、OSのプログラム、アプリケーションプログラム、及び各種データが格納される。通信インタフェース105は、ネットワークに接続され、ネットワークを介して、他のコンピュータ又は通信機器との間でデータの送受信を行う。また、キーボード106やマウス107から送られてくる信号は、バス110を介してCPU101に送信される。尚、マウス107は、ポインティングデバイスの一例であり、タッチパネル、タブレット、タッチパッド、トラックボール等、他のポインティングデバイスを用いることも可能である。
バス110には、更に、その他の周辺機器108が接続されていてもよい。その他の周辺機器108としては、例えば、グラフィック処理装置や光学ドライブ装置等が挙げられる。この場合、グラフィック処理装置には、モニタ(CRT(Cathode Ray Tube)を用いた表示装置や液晶表示装置等)が接続され、グラフィック処理装置は、CPU101からの命令に従って、画像をモニタの画面に表示させる。また、光学ドライブ装置は、レーザ光等を利用して、光ディスク(DVD(Digital Versatile Disc)、DVD−RAM、CD−ROM(Compact Disc Read Only Memory)、CD−R(Recordable)/RW(ReWritable)等)に記録されたデータの読み取りを行う。
このような構成を有するコンピュータ100の、例えばHD104aに、RTLの論理回路(検証対象)の設計データ120、論理シミュレータ130、RTLの論理回路に対する命令を記述したシナリオを組み込んだテストベンチ140等が格納される。コンピュータ100は、HDD104を駆動し、HD104aに格納されたこれらの情報を用いて、検証対象である論理回路の論理シミュレーションを実行する。この論理シミュレーションの結果に基づき、論理回路の機能、動作が適正か否かが検証される。
次に、論理シミュレーションを用いた検証作業の一例について説明する。
図2は検証作業フローの一例を示す図である。
論理シミュレーションを行う検証作業では、まず、検証対象である論理回路の仕様書(設計仕様書)(S10)を基に、検証仕様書が作成される(S11,S12)。そして、作成された検証仕様書からテストベンチの構成が検討され、テストベンチ仕様書が作成される(S13,S14)。このテストベンチ仕様書を基に、テストベンチの開発が行われる(S15,S16)。開発されたテストベンチを用いて論理シミュレーション(検証作業)が行われ、その結果(検証結果)が取得される(S17,S18)。論理シミュレーションで得られる検証結果から、検証対象の論理回路が適正に動作するか否かが、開発者或いはコンピュータ100によって、判定される。
更にテストベンチ開発(S15,S16)に着目して説明する。
図3はテストベンチ開発作業フローの一例を示す図である。
図3のテストベンチ開発作業フローでは、開発者が、テストベンチ仕様書(S20)から更にテストベンチの構成要素となる部品(モデル)毎の仕様を設定し、部品毎に開発を行う(S21〜S23)。図3の例では、チェッカの開発(S21)、トランザクタの開発(S22)、シナリオの開発(S23)を行っている。そして、各部品について単体テストを実施し、問題がないことを確認して、各部品を取得する(S24)。このようにして取得された各部品を、検証対象の論理回路と共に組み上げることで(S25)、テストベンチ(論理回路を含むシミュレーションの全体環境)を取得する(S26)。
テストベンチ開発段階でのテストベンチの構成例を図4に示す。
図4のテストベンチ200は、部品として、シナリオ211及びトランザクタ212を含むモデル210、プロトコルチェッカ220、及び期待値比較チェッカ230を備えている(テストベンチ開発環境)。
シナリオ211には、RTLで設計された検証対象300の論理回路に対する命令の手順が記述されている。シナリオ211は、トランザクタ212の仕様に合わせ、トランザクタ212に対し、検証対象300を制御する(動作させる)命令を与える。
トランザクタ212は、シナリオ211からの命令に従い、検証対象300との間のインタフェース仕様に合わせて信号を制御し、シナリオ211からの命令の情報を検証対象300に伝える。検証対象300は、このトランザクタ212からの情報を受けて、その情報が示す命令の動作を実行する。また、トランザクタ212は、検証対象300から送られてくる情報を受信し、受信した情報をシナリオ211へ通知する。
プロトコルチェッカ220は、プロトコルが存在するインタフェースに対し、関連する入出力端子を参照し、プロトコルに特化したチェックを行う。プロトコルチェッカ220は、プロトコル違反を検出した場合、エラーを報告する。
期待値比較チェッカ230は、検証対象300の入出力端子を参照し、検証対象300の出力端子(データ値、信号制御等)が設計仕様通り動作しているかのチェックを行う。期待値比較チェッカ230は、設計仕様違反を検出した場合、エラーを報告する。
図3のテストベンチ開発作業フローにおいて、このような構成を有するテストベンチを取得(S26)した後は、コンピュータを用い、テストベンチで検証対象の論理回路を動作させ、最終的な動作確認テスト(全体シミュレーション)を行う(S27)。この全体シミュレーションの結果(テストベンチに組み込まれたチェッカによるチェック結果)は、ログファイルとして出力される(S28)。このログファイルの情報から開発者がエラーの発生有無を判断する(S29)。エラーが発生している場合、そのエラー要因を特定するために波形データが必要になる。この波形データを取得する目的で、コンピュータを用いた再シミュレーションを行う(S30,S31)。取得した波形データを開発者が目視で確認し、エラー要因を特定する(S32)。エラー要因は、まず、検証対象の論理回路側にある場合と、テストベンチ側にある場合の2つに分けられる(S33)。
エラー要因が検証対象の論理回路側にある場合には(S33)、開発者が、RTLで設計されたその論理回路の修正を行い(S34)、修正後の論理回路を作成し(S35)、修正後の論理回路と共に、再度テストベンチを取得する(S25,S26)。そして、その再取得したテストベンチを用いて全体シミュレーション(S27)以降の作業を実施する。
一方、エラー要因がテストベンチ側にある場合(S33)、エラー要因は、テストベンチ内のシナリオ、トランザクタ、チェッカ等の部品の、少なくともいずれかに存在している(S36)。例えば、図4のテストベンチ200の場合、シナリオ211、トランザクタ212、プロトコルチェッカ220、期待値比較チェッカ230のいずれかにエラー要因が存在する。
シナリオにエラー要因(シナリオミス)がある場合には(S36)、シナリオ開発(S23)に戻り、シナリオのエラー要因を修正する。トランザクタにエラー要因(トランザクタミス)がある場合には(S36)、トランザクタ開発(S22)に戻り、トランザクタのエラー要因を修正する。チェッカにエラー要因(チェッカミス)がある場合には(S36)、チェッカ開発(S21)に戻り、チェッカのエラー要因を修正する。そして、上記同様、単体テストを実施して各部品を取得し(S24)、テストベンチを取得(S25,S26)して、全体シミュレーション(S27)以降の作業を実施する。
全体シミュレーションでエラーが検出されず(S29)、更に異なる条件で全体シミュレーション(テスト)を行う場合には(S37)、シミュレーション条件を変更してテストを行う(S27)。エラーなく全てのテストが終了すれば(S37)、テストベンチ開発作業は終了となる。開発したテストベンチを用いて、上記図2の論理シミュレーション(検証作業)が行われる(S17,S18)。
テストベンチは、例えば上記図3のような作業フローで開発が可能であるが、以下のような課題もある。
例えば、上記図3の作業フローでは、全体シミュレーションの結果(S27,S28)、チェッカによりエラーが検出された場合(S29)、再シミュレーションで波形データが取得され(S30,S31)、その目視確認が行われる(S32)。
開発済みの適正なテストベンチが用いられている場合、チェッカがエラーを検出すれば、検証対象の論理回路側に問題があると判断できる。しかし、テストベンチの開発段階では、チェッカ自体が適正であるか否かが確定しておらず、その品質に問題が残っているため、検出されたエラーがチェッカ自体のミスによるものである可能性がある。更に、テストベンチの開発段階では、シナリオに問題がある場合も、チェッカによりエラーとして検出されてくる。このようにエラーの要因がシナリオにある場合、その要因の特定には時間がかかる。その理由を、次の図5を参照して説明する。
図5はシナリオ要因のエラー発生例を示す図である。図5において、(A)はテストベンチの一例、(B),(C)は波形データの一例である。
まず、チェッカがエラーを検出するのは、検証対象の出力端子が仕様違反、規格違反した動作に対してであり、検証対象の出力動作は入力パターンで決まる。つまり、検証対象への入力パターン(シナリオの命令)にミスがあると、チェッカによってエラーが検出される。
今、図5(A)のテストベンチ200における一方のモデル210aのシナリオ211aに従い、図5(B)のような入力パターン(出力信号1,2)がトランザクタ212aを介して検証対象300に出力されたものとする。そして、その入力パターンに基づき、検証対象300からは、図5(C)のような出力(出力信号1,2)が得られ、その出力がもう一方のモデル210b(シナリオ211b、トランザクタ212b)に送られるものとする。この検証対象300からの出力に対し、Bプロトコルチェッカ220bがX部にエラーを検出したものとする。即ち、この例では、Bプロトコルチェッカ220bが、出力のX部における、クロックの立ち上がりで出力信号1,2が共にハイ(H)レベルとなるエラーを検出する。このBプロトコルチェッカ220bで検出されたエラーは、シナリオ211aからの入力パターンにおける、Y部の入力パターンミスが根本原因になっている。
このように、検証対象300の出力についてBプロトコルチェッカ220bで検出されるエラー要因が、検証対象300に対する入力パターンにあると、エラーの検出ポイント(X部)と、その要因となる入力パターン(Y部)の間には、時間差Tが生じる。エラー要因がシナリオ211aにあり、その要因を波形データから特定しようとすると、この時間差Tのために、解析が複雑になる場合があり、解析に長時間を要してしまう場合もある。
尚、このような課題に対し、検証対象300への入力パターンの制約違反のチェックを行うチェッカを開発することも考えられる。例えば、Aプロトコルチェッカ220aに検証対象300への入力パターンをチェックするアサーションを実装することで、課題の改善には繋がる。しかし、チェッカ開発工数が増える、チェッカ開発が完了しないとチェックが行えない等、根本的な解決には至らない。
シナリオは、例えば次のような作業フローで開発されている。
図6はシナリオ開発作業フローの一例を示す図である。
図6のシナリオ開発作業フローでは、開発者が、検証対象の設計に用いる仕様書(S40)を基に、シナリオの仕様の検討を行い(S41)、シナリオに設定する設定手順(S42)、シナリオを設定するうえでの制限事項(設定制限事項)(S43)を抽出する。開発者は、抽出したこれらの情報を基に、シナリオを作成し(S44,S45)、それを組み込んだテストベンチを取得する(S46,S47)。そして、取得したテストベンチの動作確認のため、コンピュータを用いてシミュレーションを行い(S48)、その結果(波形データ)を取得する(S49)。
シナリオ開発段階でのテストベンチの構成例を図7に示す。
シナリオ開発段階のシミュレーション(S48)に用いるテストベンチ200Aは、検証対象300、その検証対象300を動作させる、シナリオ211及びトランザクタ212を含むモデル210を備えている(シナリオ開発環境)。
シナリオ開発環境には、検証対象の入出力をチェックする機能が設けられていない。そのため、シミュレーション時(S48)には、波形データを取得し(S49)、その波形データを目視確認することで(S50)、シナリオの動作を確認する。動作確認の結果、シナリオに問題が見つかった場合には、修正したシナリオを作成し(S44,S45)、それを組み込んだテストベンチを取得して(S46,S47)、再度シミュレーションを行い(S48,S49)、その波形データを確認する(S50)。動作確認でシナリオに問題がなく(S50)、更に異なる条件でシミュレーション(テスト)を行う場合には(S51)、シミュレーション条件を変更してテストを行う(S48)。エラーなく全てのテストが終了すれば(S51)、シナリオ開発作業は終了となる。
シナリオは、例えば上記図6のような作業フローで開発が可能であるが、以下のような課題もある。
例えば、上記図6の作業フローでは、シナリオの動作確認を、シミュレーション時(S48)に取得した波形データ(S49)の目視確認によって行っている(S50)。
シナリオは、検証対象の状態やその受信状態よって、生成する入力パターンが変わるため、組み合わせを考慮すると、膨大な入力パターンが存在し得る。それら全ての組み合わせについて、波形データを目視で確認し、シナリオの動作確認を行うことは、困難である。そのため、組み合わせを考慮しない、機能毎の動作確認までしか行わない場合もある。
このようにしてシナリオの動作確認を行い、その開発作業を完了させたとしても、全入力パターンの動作確認が済んでいるわけではないため、シナリオが設定制限事項に違反した入力パターンを生成してしまう等、その後の工程に影響を及ぼしてしまう場合がある。例えば、上記図3のテストベンチ開発作業フローで述べた全体シミュレーション(S27,S28)、更にその結果に基づく再シミュレーション(S29〜S31)において、上記のようなシナリオ要因の問題が発生してしまう場合がある。
以上説明したように、検証対象の論理回路検証に用いるシナリオの開発(及びシナリオを組み込んだテストベンチの開発)においては、検証の早い段階で、適正な、安定した品質のシナリオを取得することが難しい。適正なシナリオを取得するために、開発中のシナリオ、テストベンチを実際に動作させたときの波形データを取得し、それを開発者が目視で確認する作業が必要になるため、開発に時間を要してしまう。
また、以上の説明では、シナリオ(及びシナリオを組み込んだテストベンチ)の開発を例にしたが、論理回路を制御するファームウェアの開発においても同様のことが起こり得る。
即ち、ファームウェアの開発段階では、作成したファームウェアを用いて論理回路を動作させ、エラーが検出された場合には、波形データの目視確認が行われる。このとき、エラー要因が論理回路側にあるのか、ファームウェア側にあるのかの判定に時間がかかってしまう。これは、上記図5において述べたのと同様に、エラーの発生タイミングとそのエラーを引き起こしたファームウェアの命令タイミングに時間差があり、波形データを用いた解析が複雑になるためである。このように論理回路を制御するためのファームウェアでも、その動作確認に時間を要してしまい、論理回路検証の早い段階で、適正な、安定した品質のファームウェアを取得することが難しい。
シナリオ、ファームウェアのいずれの場合においても、それらを実際に動作させたときに取得される波形データの目視確認を行うことが、それらの開発効率を低下させ、更に、検証対象である論理回路の検証作業効率を低下させる一因になっている。
そこで以下では、このような波形データの目視確認によらずに、適正なシナリオ、ファームウェアを効率的に取得する手法について、詳細に説明していく。ここでは主にシナリオを例に説明する。
図8はシナリオ開発作業フローの一例を示す図である。
図8のシナリオ開発作業フローでは、上記図6で述べた作業フロー同様、まず開発者が、検証対象の設計に用いる仕様書(S60)を基に、シナリオの仕様の検討を行い(S61)、シナリオの設定手順(S62)、シナリオの設定制限事項(S63)を抽出する。開発者は、抽出したこれらの情報を基に、シナリオを作成する(S64,S65)。
シナリオの作成後、この図8のシナリオ開発作業フローでは、開発者が、シナリオの仕様検討時に抽出した設定制限事項(S63)、及び作成したシナリオ(S65)を基に、設定制限リストを作成する(S66,S67)。設定制限リストには、例えば、作成したシナリオの所定記述部分の命令実行を制限する、上記設定制限事項の内容に対応した情報(制限情報)や、その記述部分に対応する所定行番号等の情報が含まれる。尚、設定制限リストの詳細については後述する。
そして、コンピュータを用い、このような設定制限リスト(S67)を入力とし、シナリオの動作をチェックするためのシナリオチェッカを自動生成する(S68,S69)。コンピュータは、例えば、設定制限リスト(S67)の内容を、シナリオと同じ言語を用いて、所定記述のシナリオチェッカに書き換える。シナリオチェッカは、例えば、上記したシナリオの所定記述部分の命令が実行されるときに、その命令が上記制限情報を含むか否か、即ち、命令(入力パターン)が設定制限事項に違反していないかをチェックする。尚、この点の詳細については後述する。
設定制限リスト(S67)は、このシナリオチェッカの生成のほか(S68,S69)、シナリオへのシナリオチェッカ組み込み処理に用いられる(S70,S71)。コンピュータは、例えば、設定制限リスト(S67)に示された、上記したシナリオの所定記述部分に対応した行番号を基に、シナリオのその行番号の箇所に、生成したシナリオチェッカ(S69)を呼び出すための命令文を挿入する(S70)。これにより、当該所定記述部分の命令実行時に、生成されたシナリオチェッカ(S69)を呼び出し可能にしたシナリオが取得される(S71)。尚、この点の詳細については後述する。
開発者は、このようにして取得されたシナリオチェッカ(S69)と、そのシナリオチェッカ(S69)を所定記述部分で呼び出し可能なシナリオ(S71)とを組み込んだテストベンチを取得する(S72,S73)。
シナリオ開発段階でのテストベンチの構成例を図9に示す。
シナリオ開発段階のテストベンチ200Aは、検証対象300、その検証対象300を駆動するモデル210であるシナリオ211及びトランザクタ212を備えている(シナリオ開発環境)。このシナリオ211に、シナリオチェッカ213が、所定記述部分で呼び出されるように組み込まれている。
シナリオ211に従って検証対象300を動作させると、シナリオ211の当該所定記述部分でシナリオチェッカ213が呼び出される。呼び出されたシナリオチェッカ213は、シナリオ211からの命令(入力パターン)に上記制限情報が含まれていないか、即ち、設定制限事項に違反した入力パターンが生成されていないか、チェックする。このようなチェックが、続く、コンピュータを用いたシミュレーション(S74)によって行われる。
即ち、取得したテストベンチの動作確認のため、コンピュータを用いたシミュレーションが行われ(S74)、コンピュータが、そのシミュレーション結果の情報(ログファイル)を生成する(S75)。ここで生成されるシミュレーション結果の情報は、テストベンチにシナリオチェッカが組み込まれているため、シナリオチェッカでエラーを検出したか否かを示すログファイルとなる。上記図6で述べた作業フローにおけるように、シミュレーション結果として、必ずしも波形データを取得することを要しない。
開発者は、シミュレーション結果のログファイルの情報を基に、シナリオから検証対象に対し、設定制限事項に違反しない、適正な命令(入力パターン)が入力されたか否かを判断することができ、そのシナリオの動作確認を行うことができる(S76)。従って、シナリオの動作確認のために、上記のような波形データの目視確認を行うことが不要になり、シナリオの動作確認を効率的に行うことができる。
作成したシナリオの動作確認の結果、エラーが検出された場合には、修正したシナリオを作成する(S64,S65)。そして、上記同様、設定制限リストの作成(S66,S67)、シナリオチェッカの生成(S68,S69)及び組み込み(S70,S71)を行い、テストベンチを取得して(S72,S73)、再度シミュレーションを行う(S74,S75)。そのログファイルの情報から、修正したシナリオの動作確認を行う(S76)。
動作確認でエラーが検出されず(S76)、更に異なる条件でシミュレーション(テスト)を行う場合には(S77)、シミュレーション条件を変更してテストを行う(S74)。エラーなく全てのテストが終了すれば(S77)、シナリオ開発作業は終了となる。
更に、シナリオ開発後の工程について説明する。
図10はテストベンチ開発作業フローの一例を示す図である。
図10のテストベンチ開発作業フローでは、上記図3で述べた作業フロー同様、開発者が、テストベンチ仕様書(S80)を基に、テストベンチの構成要素の部品毎に、チェッカの開発(S81)、トランザクタの開発(S82)、シナリオの開発(S83,S60〜S77)を行う。そして、テスト済みの各部品を取得し(S84)、それらを組み込んだテストベンチを取得する(S85,S86)。
テストベンチ開発段階でのテストベンチの構成例を図11に示す。
図11のテストベンチ200は、シナリオ211及びトランザクタ212を含むモデル210、プロトコルチェッカ220、及び期待値比較チェッカ230を備えている(テストベンチ開発環境)。このシナリオ211に、シナリオチェッカ213が組み込まれている。
シナリオ開発(図9)で用いられたシナリオチェッカは、シナリオに組み込まれた構成(呼び出し可能な構成)になっており、テストベンチ開発のテストベンチにおいてもそのまま用いることができる。このようなテストベンチ(S86)を用いて、上記図3で述べた作業フロー同様、検証対象の論理回路を動作させる全体シミュレーションを行う(S87)。この全体シミュレーションの結果は、テストベンチに組み込まれたチェッカ(プロトコルチェッカ、期待値比較チェッカ、シナリオチェッカ)によるチェック結果のログファイルとして出力される(S88)。このログファイルの情報から開発者がエラーの発生有無を判断する(S89)。
ここで、シナリオチェッカによりエラーが検出されている場合には(S89)、シナリオ開発(S83)に戻り、シナリオのエラー要因を修正する。ここではシナリオチェッカを設けているため、このように全体シミュレーション(S87)のログファイルの結果確認段階で、シナリオのエラー(シナリオミス)を検出することが可能になっている。そのため、検証の比較的早い段階でシナリオの修正を行い、適正なシナリオを作成することができる。また、この時点でシナリオチェッカのエラーがなく、その他のチェッカエラーが検出されていれば、そのエラー要因が、検証対象か、テストベンチのシナリオ以外の部品にあると判断することができる。
シナリオ以外についてのエラーが検出されている場合には(S89)、コンピュータを用いた再シミュレーションを行って波形データを取得する(S90,S91)。取得した波形データを開発者が目視で確認し、エラー要因を特定する(S92)。
エラー要因が検証対象の論理回路側にある場合には(S93)、開発者が、その論理回路の修正を行い(S94)、修正後の論理回路を作成し(S95)、修正後の論理回路と共に、再度テストベンチを取得する(S85,S86)。そして、その再取得したテストベンチを用いて全体シミュレーション(S87)以降の作業を実施する。
エラー要因がテストベンチ側にある場合、エラー要因は、テストベンチ内のトランザクタ又はチェッカに分けられる(S96)。トランザクタにエラー要因(トランザクタミス)がある場合には(S96)、トランザクタ開発(S82)に戻り、トランザクタのエラー要因を修正する。チェッカにエラー要因(チェッカミス)がある場合には(S96)、チェッカ開発(S81)に戻り、チェッカのエラー要因を修正する。そして、上記同様、単体テストを実施して各部品を取得し(S84)、テストベンチを取得(S85,S86)して、全体シミュレーション(S87)以降の作業を実施する。
全体シミュレーションでエラーが検出されず(S89)、更に異なる条件で全体シミュレーション(テスト)を行う場合には(S97)、シミュレーション条件を変更してテストを行う(S87)。エラーなく全てのテストが終了すれば(S97)、テストベンチ開発作業は終了となる。
このように、シナリオにシナリオチェッカを組み込むことで、シナリオ開発及びテストベンチ開発において、シナリオミスについては、シミュレーションによる波形データの取得、取得した波形データの目視確認を不要にすることができる。それにより、適正なシナリオを比較的早期に作成することができ、シナリオ開発を効率化し、更に、テストベンチ開発、論理回路検証の効率化を図ることができる。
上記図8のシナリオ開発作業フローには、上記図6の作業フローと異なり、設定制限リストの作成(S66,S67)、シナリオチェッカの生成(S68,S69)、シナリオチェッカの組み込み(S70,S71)、ログファイルの確認(S75,S76)を含む。これらのステップを含むことにより、上記のようなシナリオ開発の効率化が図られている。これらの各ステップは、以下のように行われる。
まず、設定制限リスト作成ステップ(S66,S67)について説明する。
設定制限リスト(S67)の作成は、開発者が行う。設定制限リストの作成は、設定制限事項(S63)及びシナリオ(S65)を入力として行われる。
設定制限事項には、検証対象に対する入力動作(命令)を制限する制限事項の内容が、自然言語で記載されているものとする。また、入力動作を制限する各事項について、対応する番号(No.)が付与されているものとする。シナリオは、トランザクタへの命令を記述したソースコードである。このような設定制限事項及びシナリオを用いて、開発者が設定制限リストを作成する。
図12に設定制限リストのフォーマットの一例を示す。
図12の設定制限リストのフォーマット400aには、各種情報を記入(入力)する欄401a〜406aが設けられている。
欄401aには、設定制限リストからシナリオチェッカ生成ステップ(S68、S69)で生成するシナリオチェッカの名称(チェッカ名)が記入される。チェッカ名の欄401aには、生成するシナリオチェッカの機能を表すような任意の文字列が記入される。この欄401aに記入されたチェッカ名は、シナリオチェッカ生成ステップで生成されるファイル名の一部として使用される。また、このチェッカ名は、チェッカエラー時のメッセージに出力される文字列にも使用される。
欄402aには、シナリオ(S65)の、設定制限事項(S63)に関する入力動作を行う記述がある部分のファイルの名称(参照ファイル名)が記入される。欄403aには、シナリオチェッカ生成ステップで生成されるシナリオチェッカを、上記参照ファイル名のファイル中に挿入する行番号(挿入行番号)が記入される。
欄404aのNo.(番号1〜n)は、シナリオの入力動作についての各設定制限事項に対応して付与されている。入力1〜mの欄405aには、各設定制限事項の入力動作の内容を決定する変数名が記入される。条件1_1〜n_mの欄406aには、各設定制限事項の入力動作の内容を決定する変数名(入力1〜m)に対応した具体的な変数が記入される。欄406aのその他条件1〜mには、入力1〜mの変数名に対応した変数以外の条件が記入される。欄405a、欄406aは、該当する条件がない場合には空欄とされる。
開発者は、設定制限事項(S63)及びシナリオ(S65)を用いて、フォーマット400aの各欄401a〜406aの内容を記入し、設定制限リスト(S67)を作成する。尚、設定制限リストを作成するうえで、行数及び列数は、設定制限事項の数(番号の数)及び変数名の数等に応じて適宜調節される。
続いて、シナリオチェッカ生成ステップ(S68,S69)について説明する。
シナリオチェッカ(S69)の生成は、開発者がシナリオチェッカ生成スクリプトを起動することにより、コンピュータの処理によって行われる。シナリオチェッカの生成は、設定制限リスト(S67)を入力として行われる。
シナリオチェッカは1つ又は2つ以上のチェッカを含むファイルである。設定制限リストを入力としてシナリオチェッカ生成スクリプトを実行することにより、設定制限リストの内容を記述したシナリオチェッカが生成され、ファイルに出力される。このときのファイル名は“[チェッカ名].[拡張子]”となる。拡張子は、テストベンチ(S73)で使用する言語に依存する。
生成されるシナリオチェッカの記述内容は、テストベンチで使用する言語によって異なる。但し、いずれの言語においても、シミュレーションを実行してシナリオチェッカがエラーとなったときに、どの設定制限事項に対してのエラーであるかが判別できるようにする。そのため、ログファイルにエラーの内容と共に、“[チェッカ名]_[番号i]”(i=1〜n)という文字列(ラベル名)を出力するようなシナリオチェッカを生成する。
続いて、シナリオチェッカ組み込みステップ(S70,S71)について説明する。
シナリオチェッカ(S69)の組み込みは、開発者がシナリオチェッカ組み込みスクリプトを起動することにより、コンピュータの処理によって行われる。シナリオチェッカの組み込みは、設定制限リスト(S67)、シナリオチェッカ(S69)、シナリオ(65)を入力として行われる。シナリオチェッカ組み込みスクリプトを実行することで、設定制限リストに記載された参照ファイル名(欄402a)に該当するファイルの、挿入行番号(欄403a)に該当する行番号に、シナリオチェッカ(S69)のファイルのインクルード文が追加される。
続いて、ログファイル確認ステップ(S75,S76)について説明する。
ログファイルの確認は、開発者が行う。ログファイルの確認では、シミュレーションを行った結果が出力されるログファイル(S75)の内容から、シナリオチェッカのエラー出力メッセージの有無を確認し、シナリオ修正の要否が判断される。シミュレーションにおいてシナリオチェッカのエラーが発生した場合、ログファイルには、エラーを検出したチェッカ名と、そのエラーの内容を示す情報(設定制限事項の番号)を含んだラベル名の文字列が出力される。このようなログファイルに含まれる情報を基に、シナリオ修正の要否が判断される。
以下、上記手法を、実施例によって、より具体的に説明する。
まず、第1実施例について説明する。
図13は第1実施例に係る検証対象とシナリオの関係を示す図である。
第1実施例のテストベンチで使用する言語は、SystemVerilogとする。
図13の検証対象300はメモリモデルとなっており、内部にレジスタ領域301を有している。検証対象300への入力動作として、レジスタ領域301への書き込み動作がある。検証対象300には、アドレスADDR(32’h00000000〜32’hFFFFFFFC)とデータDATAを指定した、シナリオ211からの書き込み動作の命令が、トランザクタ212を介して送られる。検証対象300では、指定されたアドレスADDRの示すレジスタ領域301に、指定されたデータDATAが格納される。
即ち、まずシナリオ211において、レジスタ領域301への書き込み動作のアドレスADDRとデータDATAの内容を決定する。次いで、シナリオ211がトランザクタ212に、レジスタ領域301への書き込み動作を行うように、アドレスADDRとデータDATAの情報を与えて命令する。トランザクタ212が検証対象300に対してレジスタ領域301への書き込み動作の入力動作を行い、検証対象300にアドレスADDRとデータDATAの情報を伝える。検証対象300は、トランザクタ212からのレジスタ領域301への書き込み動作の情報を受けて、指定されたアドレスADDRのレジスタ領域301に、指定されたデータDATAを格納する。
第1実施例では、このようなレジスタ領域301への書き込み動作に関し、シナリオ211を設定するうえでの設定制限事項があるものとする。図14は第1実施例に係る設定制限事項の一例を示す図である。図14に例示する設定制限事項500では、まず第1(No.0001)の設定制限事項の内容として、アドレス32’h00000000に対して32’h00000001の書き込み禁止が設定されている。更に、第2(No.0002)の設定制限事項の内容として、top.READYo==0のときアドレス32’h00000004に対して書き込み禁止が設定されている。
図15は第1実施例に係るシナリオの記述部分の一例を示す図である。図15には、第1実施例のシナリオ211に含まれるレジスタ領域301への書き込み動作を行う記述部分(一部)を例示している。第1実施例のシナリオ211には、“scenario.sv”という名称のファイル211faが含まれており、このファイル211faに、レジスタ領域301への書き込み動作を行う記述(write_accessタスク)が含まれている。
上記のような設定制限事項500及びシナリオ211を用いた設定制限リストの作成を、例えば、図16〜図19のような流れで行っていく。
設定制限リスト400の作成では、まず図16のように、生成しようとするシナリオチェッカの機能を表すような任意の文字列、ここでは“WRITE”という文字列を、チェッカ名の欄401(図12のフォーマット400aの欄401a)に記入する。
次いで、図17のように、設定制限事項500に関する入力動作を行う記述のあるファイル211faの名称“scenario.sv”を、参照ファイル名の欄402(図12のフォーマット400aの欄402a)に記入する。更に、後のシナリオチェッカ生成ステップで生成されるファイルを“scenario.sv”内でインクルードする行番号を、挿入行番号の欄403(図12のフォーマット400aの欄403a)に記入する。この第1実施例では、生成されるファイルを、レジスタ領域301に対する書き込み動作の内容(アドレスADDR、データDATA)を参照できる箇所である101行目に挿入することになるため、欄403には“101”を記入する。
次いで、図18のように、入力(変数名)の欄405(図12のフォーマット400aの欄405a(入力1及び入力2))に、変数名を記入する。この第1実施例では、レジスタ領域301に対する書き込み動作の内容を決定する変数がアドレスADDRとデータDATAであるため、欄405に“ADDR”及び“DATA”を記入する。
次いで、設定制限事項500に記載されている内容を解釈して、図19のように、各条件の欄406(図12のフォーマット400aの欄406a)に、具体的な条件を記入する。第1実施例では、No.0001の設定制限事項について、“ADDR”に対して“32’h00000000”を記入し、“DATA”に対して“32’h00000001”を記入し、その他条件は空欄とする。また、No.0002の設定事項については、“ADDR”に対して“32’h00000004”を記入し、“DATA”は空欄とし、その他条件に対して“top.READYo==0”を記入する。
このようにして設定制限リスト400の作成が行われる。
続いて、作成された設定制限リスト400を用いたシナリオチェッカ213の生成について、図20及び図21を参照して説明する。
ここでは、SystemVerilogを用いている場合を例に説明する。SystemVerilogのチェッカのアサーションは、“[ラベル名]:assert([エラー条件])”というフォーマットになる。[ラベル名]は任意の文字列となり、[エラー条件]はSystemVerilogの文法における論理式となる。このチェッカがシミュレーション中に実行されたときに、[エラー条件]の論理式が真を示すと、結果(ログファイル)に、[ラベル名]と共に、エラーであることが記録される。
SystemVerilogの場合のシナリオチェッカ生成では、シナリオチェッカ生成スクリプトを実行することにより、作成された設定制限リスト400を基に、[ラベル名]と[エラー条件]の部分の文字列を生成し、シナリオチェッカ213を生成する。シナリオチェッカ213は、“[チェッカ名].svh”というファイル名で生成する。
図20に、シナリオチェッカ生成スクリプトによる設定制限リストからシナリオチェッカへの変換形式を示す。図20には、設定制限リストのフォーマット400aの記載と、それから生成されるシナリオチェッカ213の記述との対応を示している。
各No.(番号1〜n)について、それぞれ1つのチェッカが生成される。各チェッカの[ラベル名]は、“チェッカ名_番号i”(i=1〜n)という文字列で生成される。[エラー条件]は、例えばNo.0001では、“(入力1==条件1_1)&&(入力2==条件1_2)・・・(入力m==条件1_m)&&(その他条件1)”という文字列で生成される。但し、条件が空欄の場合は、その部分の論理式は生成されない。
第1実施例では次の図21に示すようになる。
図21は第1実施例に係るシナリオチェッカ生成スクリプトによる設定制限リストからシナリオチェッカへの変換例を示す図である。
図21のように、設定制限リスト400より、No.0001については[ラベル名]が“WRITE_0001”、[エラー条件]が“ADDR==32’h00000000)&&(DATA==32’h00000001)”のチェッカ213aが生成される。また、設定制限リスト400より、No.0002については[ラベル名]が“WRITE_0002”、[エラー条件]が“ADDR==32’h00000004)&&(top.READYo==0)”のチェッカ213bが生成される。
このようなチェッカ213a,213bを含むシナリオチェッカ213のファイル名は、“WRITE.svh”となる。
続いて、生成されたシナリオチェッカの組み込みについて、図22を参照して説明する。
図22は第1実施例に係るシナリオチェッカ組み込みスクリプトによるシナリオチェッカのシナリオへの組み込み例を示す図である。
図22のように、シナリオチェッカ組み込みスクリプトを実行することで、設定制限リスト400の情報を基に、シナリオ211の“scenario.sv”のファイル211faの101行目に、“WRITE.svh”のインクルード文211cが挿入される。これにより、図21のようなシナリオチェッカ213がシナリオ211に組み込まれた記述(シナリオチェッカ213を呼び出し可能な記述)が得られる。
このようなシナリオ211を用いたシナリオ開発やテストベンチ開発の段階で行われるシミュレーションの際には、シナリオの“scenario.sv”の記述部分の命令実行時に、“WRITE.svh”のシナリオチェッカ213が呼び出される。そして、呼び出されたシナリオチェッカ213により、シナリオ211が実行する命令に、その実行を制限する制限情報(アドレスADDR、データDATA、その他条件)が含まれるか否か(エラー条件の論理式が真を示すか否か)がチェックされる。シナリオ211の命令実行を制限する制限情報が含まれていればエラーとなる。エラーか否かのチェック結果は、ログファイルとして出力される。
続いて、シナリオチェッカを用いたシミュレーションの結果得られるログファイルについて、図23を参照して説明する。
図23は第1実施例に係るログファイルの出力例である。
第1実施例のシナリオチェッカ213がシミュレーションでエラーを検出した場合、シミュレーションの結果得られるログファイル600には、チェッカ213a,213bの[ラベル名]の文字列が出力される。即ち、この例では、“WRITE_0001”や“WRITE_0002”というラベル名601がログファイル600に出力される。
開発者は、シミュレーションの結果得られるログファイル600を確認し、このようにチェッカ213a,213bの[ラベル名]が出力されている場合は、シナリオ211にエラーがあるとみなし、シナリオ211を修正する工程へ進むことになる。
次に、第2実施例について説明する。
上記第1実施例では、レジスタ領域301への書き込み動作における設定制限事項の場合について例示したが、このような単一の動作に対するもののほか、ある機能の一連の処理全体に対する設定制限事項の場合も同様に、上記手法を適用することができる。このような例を、第2実施例として説明する。
第2実施例の検証対象は、次のような構成を有しているものとする。この検証対象は、DMA(Direct Memory Access)機能を有している。検証対象は、複数のDMA機能設定レジスタを備え、DMA機能設定レジスタに行いたい動作の設定を書き込んでDMA機能が起動されると、DMA機能設定レジスタに書き込まれた設定値に従ってDMA機能の動作を行う。
DMA機能設定レジスタには、転送方向(OUT/IN)、DMAモード(ブロック/デマンド)、バーストモード(SINGLE/INCR)の各設定項目があるものとする。尚、DMAモードのブロックは、1回の転送要求にてブロック単位で1回の転送を行うモードを示し、デマンドは、転送要求がアクティブの期間、転送を行うモードを示す。バーストモードのSINGLEは、1回の転送要求で単独転送を行うモードを示し、INCRは、インクリメント式のバースト転送を行うモードを示す。このほか、DMA機能設定レジスタには更に、総転送数(LENGTH)(16bit)、転送元(SRC)アドレス(32bit)、転送先(DST)アドレス(32bit)の各設定項目があるものとする。
このような検証対象のDMA機能の動作に関し、シナリオ211を設定するうえでの設定制限事項があるものとする。図24は第2実施例に係る設定制限事項の一例を示す図である。図24に例示する設定制限事項510では、まずNo.0001の設定制限事項の内容として、総転送数0でのDMA起動禁止が設定されている。No.0002の設定制限事項の内容として、転送方向がIN且つDMAモードがデマンドでのDMA起動禁止が設定されている。No.0003の設定制限事項の内容として、DMAモードがブロック且つバーストモードがINCRでのDMA起動禁止が設定されている。
図25は第2実施例に係るシナリオの記述部分の一例を示す図である。図25には、第2実施例のシナリオ211に含まれるDMA機能の起動処理を行う記述部分(一部)を例示している。第2実施例のシナリオ211には、“scenario.sv”という名称のファイル211fbが含まれており、このファイル211fbに、DMA機能の起動処理を行う記述(dma_processタスク)が含まれている。dma_processタスクは、入力されたDMA機能設定レジスタの設定項目の情報に従ってレジスタの書き込みを行い、一連のDMA機能の起動処理を行うタスクである。
上記のような設定制限事項510及びシナリオ211を用いて作成される、第2実施例に係る設定制限リストの一例を図26に示す。
図26の設定制限リスト410は、上記第1実施例と同様の手順で作成することができる。この第2実施例の設定制限リスト410では、チェッカ名の欄411(図12のフォーマット400aの欄401a)に“DMA”という文字列が記入される。
参照ファイル名の欄412(図12のフォーマット400aの欄402a)には、DMA機能の起動処理を行う記述のあるファイル211fbの名称“scenario.sv”が記入される。
挿入行番号の欄413(図12のフォーマット400aの欄403a)には、シナリオチェッカ生成ステップで生成されるファイルをインクルードする行番号が記入される。この第2実施例では、生成されるファイルを、DMA機能の起動処理の内容(ディレクトリDIR、DMAモードDMA_MODE、バーストモードBURST_MODE、LENGTH)を参照できる行である“207”が欄413に記入される。
入力(変数名)の欄415(図12のフォーマット400aの欄405a)には、DMA機能の起動処理の内容を決定するディレクトリDIR、DMAモードDMA_MODE、バーストモードBURST_MODE、LENGTHの各変数名が記入される。
各条件の欄416(図12のフォーマット400aの欄406a)には、設定制限事項510の内容が解釈されて具体的な制限情報が記入される。第2実施例では、No.0001の設定制限事項について、“LENGTH”に対して“16’h0000”が記入され、それ以外は空欄とされる。No.0002の設定事項については、“DIR”及び“DMA_MODE”に対して“1’b1”が記入され、それ以外は空欄とされる。No.0003の設定事項については、“DMA_MODE”に対して“1’b0”が記入され、“BURST_MODE”に対して“1’b1”が記入され、それ以外は空欄とされる。
図27は第2実施例に係るシナリオチェッカの一例を示す図である。
上記のような設定制限リスト410を基に、シナリオチェッカ生成スクリプトを実行することで、No.0001,0002,0003の各チェッカ213c,213d,213eを含むシナリオチェッカ213が生成される。各チェッカ213c,213d,213eは、第1実施例同様、“[ラベル名]:assert([エラー条件])”というフォーマットに従って生成される。この第2実施例の場合、生成されるシナリオチェッカ213は、“DMA.svh”というファイル名になる。
そして、上記第1実施例同様、シナリオチェッカ組み込みスクリプトを実行し、設定制限リスト410を基に、これらのチェッカ213c,213d,213eを含むシナリオチェッカ213をファイル211fbの207行目に呼び出すインクルード文を挿入する。それにより、それにより、当該シナリオチェッカ213が、ファイル211fbの207行目で呼び出されるように組み込まれたシナリオ211が得られるようになる。
このようなシナリオ211が用いられてシナリオ開発やテストベンチ開発で行われるシミュレーションでは、エラー検出の際のログファイルに“DMA_0001”、“DMA_0002”、“DMA_0003”の[ラベル名]が出力される。開発者は、シミュレーションの結果得られるログファイルを確認し、このようにチェッカ213c,213d,213eの[ラベル名]が出力されている場合は、シナリオ211にエラーがあるとみなし、シナリオ211を修正する工程へ進む。
以上説明した手法によれば、シナリオ開発段階、テストベンチ開発段階で行われるシミュレーションにおいて、シナリオのエラーの有無及びエラーの内容を示す情報を、ログファイルの確認で行うことができる。そのため、シナリオのエラーが検出されたときに、敢えて波形データを取得することが不要になり、更に、取得した波形データを開発者が目視で確認し解析することによってそのエラー要因を特定するといった作業が不要になる。従って、シナリオ要因のエラーの解析時間を短縮することが可能になる。例えば、テストベンチ開発段階で、シナリオ要因のエラーとそれ以外のエラーがそれぞれ5割の割合で発生していた場合、全体としてのエラーの解析時間がおよそ2分の1になることになる。
更に、以上説明した手法では、シナリオ開発段階でのシナリオの動作確認(検証)をログファイルの確認で行うことができる。一方、シナリオの動作確認を波形データの目視確認によって行うと、時間がかかり、あまり多くの動作について確認が行えない場合があった。上記手法によれば、シナリオの動作確認をログファイルの確認で行え、波形データの目視確認を不要とすることができるため、動作確認に要する時間を短縮できる。その結果、より多くの動作について確認を行うことも可能になり、シナリオの動作確認を十分に行うことが可能になる。
尚、以上の説明では、シナリオ(及びシナリオを組み込んだテストベンチ)の開発を例にしたが、論理回路を制御するファームウェアの開発においても、上記同様の手法を用いることができる。
即ち、検証対象の仕様、ファームウェアの仕様等を基に、ファームウェアの制御動作を設定するうえでの設定制限事項を得る。その設定制限事項を基に、上記シナリオの例に従い、ファームウェアの所定記述部分の命令実行を制限する制限情報を含んだ設定制限リストを作成する。そして、作成した設定制限リストの内容を記述したファームウェアのチェッカを生成し、生成したチェッカを、ファームウェアに対し、その所定記述部分の命令実行時に呼び出せるように組み込む。このファームウェアを用いて論理回路を動作させ、所定記述部分でチェッカを呼び出し、その所定記述部分の命令にその実行を制限する制限情報が含まれるか否かを、呼び出したチェッカによってチェックする。ファームウェアの命令実行を制限する制限情報が含まれていればエラーとなる。エラーの有無及びエラーの内容を示す情報を、ログファイルとして出力する。
このような手法によれば、検出されるエラーがファームウェアによるものであることをログファイルから判定でき、更に、ファームウェア要因のエラーについて、波形データの解析が不要になる。そのため、ファームウェア要因のエラーを波形データの目視確認で行う場合に比べ、エラーの解析時間を短縮することが可能になる。
尚、上記のシナリオ、テストベンチ、及びファームウェア、並びにそれらを用いた対象回路の検証は、コンピュータを用いて実現することができ、その場合、コンピュータが実行する処理機能の内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、光磁気記録媒体、半導体メモリ等がある。磁気記憶装置には、HD、フレキシブルディスク(FD)、磁気テープ等がある。光ディスクには、DVD、DVD−RAM、CD−ROM/RW等がある。光磁気記録媒体には、MO(Magneto-Optical disk)等がある。
プログラムを流通させる場合には、例えば、そのプログラムが記録されたDVD、CD−ROM等の可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラム若しくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。尚、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、ネットワークを介して接続されたサーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
また、上記の処理機能の少なくとも一部を、DSP(Digital Signal Processor)、ASIC(Application Specific Integrated Circuit)、PLD(Programmable Logic Device)等の電子回路で実現することもできる。