(57)【要約】【課題】ブロック検証環境およびチップ検証環境の設計を簡略化して、論理検証に費やす時間を短縮した論理検証方法を提供する。【解決手段】複数の機能ブロックのそれぞれを検証する複数のブロック検証環境と、半導体集積回路全体を検証するチップ検証環境とで共通して使用されるモジュールおよびタスクを含む共通検証環境を設計するステップ（ａ）と、共通検証環境を利用することで構築される複数のブロック検証環境を用いて、複数の機能ブロックのそれぞれの論理を検証するステップ（ｂ）と、ステップ（ｂ）の後、共通検証環境を利用することで構築されるチップ検証環境を用いて、半導体集積回路全体の論理を検証するステップ（ｃ）とを備えている。【選択図】図２
2015096997.tif 000002
【特許請求の範囲】
【請求項１】
複数の機能ブロックを有した半導体集積回路の論理を検証する論理検証方法であって、
（ａ）前記複数の機能ブロックのそれぞれを検証する複数のブロック検証環境と、前記半導体集積回路全体を検証するチップ検証環境とで共通して使用されるモジュールおよびタスクを含む共通検証環境を設計するステップと、
（ｂ）前記共通検証環境を利用することで構築される前記複数のブロック検証環境を用いて、前記複数の機能ブロックのそれぞれの論理を検証するステップと、
（ｃ）前記ステップ（ｂ）の後、前記共通検証環境を利用することで構築される前記チップ検証環境を用いて、前記半導体集積回路全体の論理を検証するステップと、を備える、論理検証方法。
【請求項２】
前記ステップ（ｂ）の後、
（ｄ）前記ステップ（ｂ）で不具合が発見された機能ブロックについて、前記モジュールおよび前記タスクの修正を行うステップと、
前記ステップ（ｃ）の後、
（ｅ）前記ステップ（ｃ）で不具合が発見された前記半導体集積回路について、前記モジュールおよび前記タスクの修正を行うステップと、を備え、
前記ステップ（ｄ）および（ｅ）は、前記共通検証環境を構成する前記モジュールおよび前記タスクを修正する、請求項１記載の論理検証方法。
【請求項３】
前記ステップ（ｄ）は、
前記共通検証環境を介して、前記複数のブロック検証環境間で前記不具合の情報を互いにフィードバックするステップを含む、請求項２記載の論理検証方法。
【請求項４】
前記複数のブロック検証環境および前記チップ検証環境は、同じファイル構成を有する、請求項１〜請求項３の何れか１項に記載の論理検証方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ハードウェア記述言語等で設計された論理回路を検証する論理検証方法に関する。
【背景技術】
【０００２】
電子機器等に用いられている半導体集積回路（ＬＳＩ：Large Scale Integration）は、一般的にＲＴＬ（Register Transfer Level）などのＨＤＬ（Hardware Description Language）によって設計されているが、設計されたＬＳＩが正常に動作するか否かを確認するために論理検証が行われる。
【０００３】
この論理検証は、例えば、コンピューター上に構築されたシミュレータの論理検証環境上で行われ、仕様書等に基づいたテストパターンを準備し、当該テストパターンに基づいて、シミュレータ上で検証対象の半導体集積回路を構築して検証するが、半導体集積回路の集積度が向上し、論理回路の規模が大きくなるに従って、論理回路の機能を保証するための検証項目が増大し、検証に費やす時間が長期化する傾向にある。この論理検証に費やす時間を短縮することが、半導体集積回路の開発期間の短縮につながることから、論理検証時間の短縮が求められている。
【０００４】
論理検証時間の短縮を目的として、例えば特許文献１には、テストベンチのコマンドに対して、インターフェースを変更するようなコマンドラッパーを被せることで、テストコードの大部分を全く変更することなく再利用できるようにする技術が開示されている。
【０００５】
ここで、図５を用いて従来の論理検証方法について説明する。図５は、従来の論理検証方法の一例を示すフローチャートである。
【０００６】
図５に示すように、論理回路の仕様を決定すると、仕様に従って、論理回路を構成するブロックごとにモジュールを設計する。図５の例では、論理回路がブロックＡおよびブロックＢを有している場合を示しており、ブロックＡおよびＢは、互いに、検証シナリオおよび検証項目が異なったブロックである。
【０００７】
ステップＳ１０１でブロックＡのモジュールを設計し、ステップＳ１０２でブロックＢのモジュールを設計する。
【０００８】
そして、各ブロックに合わせて検証環境を設計し、ステップＳ１０３では、ブロックＡの検証環境を設計し、ステップＳ１０４では、ブロックＢの検証環境を設計する。
【０００９】
その後、ブロックＡの検証環境を用いてブロックＡの論理検証を行い（ステップＳ１０５）、ブロックＡの動作の不具合の有無を確認し（ステップＳ１０６）、不具合があればフィードバックをかけてブロックＡの該当箇所を修正する（ステップＳ１０７）。一方、不具合がなければステップＳ１１１に進む。
【００１０】
同様に、ブロックＢの検証環境を用いてブロックＢの論理検証を行い（ステップＳ１０８）、ブロックＢの不具合の有無を確認し（ステップＳ１０９）、不具合があればフィードバックをかけてブロックＢの該当箇所を修正する（ステップＳ１１０）。一方、不具合がなければステップＳ１１１に進む。
【００１１】
このように、ステップＳ１０５、Ｓ１０６およびＳ１０７の繰り返し、およびステップＳ１０８、Ｓ１０９およびＳ１１０の繰り返しにより、それぞれブロックＡおよびブロックＢの不具合を修正する。
【００１２】
ステップＳ１１１では、ブロックＡおよびＢを含む半導体集積回路（チップ）全体の検証環境を設計する。そして、設計したチップ検証環境を用いてチップの検証を行う（ステップＳ１１２）。なお、チップ検証では、ブロックＡおよびＢの単体動作だけでなく、両者の連携動作についても検証を行う。
【００１３】
そして、ブロックＡの動作の不具合の有無を確認し（ステップＳ１１３）、不具合があればフィードバックをかけてブロックＡの該当箇所を修正する（ステップＳ１１６）。一方、不具合がなければステップＳ１１４に進み、ブロックＢの動作の不具合の有無を確認し、不具合があればフィードバックをかけてブロックＢの該当箇所を修正する（ステップＳ１１７）。一方、不具合がなければステップＳ１１５に進む。
【００１４】
ステップＳ１１５では、ブロックＡとブロックＢとの連携動作についての不具合の有無を確認し、連携動作に不具合があれば、フィードバックをかけて連携部分を修正する（ステップＳ１１８）。一方、不具合がなければ検証作業を終了する。
【先行技術文献】
【特許文献】
【００１５】
【特許文献１】特開２００６−１２７１０８号公報
【発明の概要】
【発明が解決しようとする課題】
【００１６】
以上説明した従来の論理検証方法によれば、検証シナリオ、検証項目が異なる場合、ブロックごとにブロック検証環境を設計する必要があり、また、チップ検証環境も別途に設計する必要がある。
【００１７】
また、ブロック検証環境（設定ファイル、シナリオ記述）を移植してチップ検証環境を設計しようとしても、ブロック検証とチップ検証とでは検証環境が違うため、移植工数が多大となる可能性が高い。
【００１８】
と言って、ブロック検証をチップ検証環境で行うと、ブロック単位の細かい検証ができず、検証効率および検証カバレッジが低くなる。
【００１９】
また、ステップＳ１１３、Ｓ１１４で示されるように、チップ検証でブロックの不具合が判明した場合、不具合の内容によってはステップＳ１０７、Ｓ１１０に戻ってブロック検証を再度行う必要があるが、ブロック検証とチップ検証とで環境が異なるので、修正および再検証に手間と時間がかかる。
【００２０】
本発明は上記のような問題を解決するためになされたもので、ブロック検証環境およびチップ検証環境の設計を簡略化して、論理検証に費やす時間を短縮した論理検証方法を提供することを目的とする。
【課題を解決するための手段】
【００２１】
本発明に係る論理検証方法の第１の態様は、複数の機能ブロックを有した半導体集積回路の論理を検証する論理検証方法であって、前記複数の機能ブロックのそれぞれを検証する複数のブロック検証環境と、前記半導体集積回路全体を検証するチップ検証環境とで共通して使用されるモジュールおよびタスクを含む共通検証環境を設計するステップ（ａ）と、前記共通検証環境を利用することで構築される前記複数のブロック検証環境を用いて、前記複数の機能ブロックのそれぞれの論理を検証するステップ（ｂ）と、前記ステップ（ｂ）の後、前記共通検証環境を利用することで構築される前記チップ検証環境を用いて、前記半導体集積回路全体の論理を検証するステップ（ｃ）とを備えている。
【００２２】
本発明に係る論理検証方法の第２の態様は、前記ステップ（ｂ）の後、前記ステップ（ｂ）で不具合が発見された機能ブロックについて、前記モジュールおよび前記タスクの修正を行うステップ（ｄ）と、前記ステップ（ｃ）の後、前記ステップ（ｃ）で不具合が発見された前記半導体集積回路について、前記モジュールおよび前記タスクの修正を行うステップ（ｅ）とを備え、前記ステップ（ｄ）および（ｅ）は、前記共通検証環境を構成する前記モジュールおよび前記タスクを修正する。
【００２３】
本発明に係る論理検証方法の第３の態様は、前記ステップ（ｄ）が、前記共通検証環境を介して、前記複数のブロック検証環境間で前記不具合の情報を互いにフィードバックするステップを含んでいる。
【００２４】
本発明に係る論理検証方法の第４の態様は、前記複数のブロック検証環境および前記チップ検証環境が、同じファイル構成を有している。
【発明の効果】
【００２５】
本発明によれば、共通検証環境を利用することで複数のブロック検証環境およびチップ検証環境を構築するので、ブロック検証環境およびチップ検証環境の設計を簡略化して、論理検証に費やす時間を短縮することができる。
【図面の簡単な説明】
【００２６】
【図１】本発明に係る論理検証方法を実行するテストベンチの構成を示す図である。
【図２】本発明に係る論理検証方法により検証環境を作成する方法を説明する概念図である。
【図３】本発明に係る論理検証方法を説明するフローチャートである。
【図４】ファイル構成の一例を説明する図である。
【図５】従来の論理検証方法を説明するフローチャートである。
【発明を実施するための形態】
【００２７】
＜実施の形態＞
＜テストベンチの構成＞
まず、図１を用いて、本発明に係る論理検証方法を実行するテストベンチＴＢの構成について説明する。
【００２８】
図１に示すテストベンチＴＢは、検証対象となるチップ１０と、チップ１０に対するテストシナリオを与えるテストコントローラ１、チップ１０に対して、実在する素子をシミュレーションのためにモデル化したデバイスモデル２およびチップ１０における信号をモニタする信号モニタ３とを備えている。
【００２９】
チップ１０は、ＣＰＵ（Central Processing Unit）１１、簡易的なメモリモデルである通常メモリモデル１２、ＤＵＴ（Device Under Test）１３およびバスの混雑状況を作り出すバスストレスメモリモデル１４を有し、それぞれが、システムバス１５に接続されている。
【００３０】
また、ＣＰＵ１１は、簡易的なＣＰＵ動作モデルであるＢＦＭ（Bus Functional Model）２１と、実際のクロックサイクルベースでＣＰＵの動作をシミュレーションするＤＳＭ（Design Simulation Model）２２とを、有している。
【００３１】
なお、上述したテストベンチＴＢの各構成は、ＨＤＬ等で記述されている。
【００３２】
ＢＦＭ２１は、レジスタのリード、ライトなど簡易な動作をシミュレーションするモデルであり、主に画像処理のモジュールなどのブロック検証およびチップ検証で使用され、ＤＳＭ２２は、主にＣＰＵのブートモジュールのブロック検証やチップ検証などのメインシナリオで使用するモデルである。
【００３３】
通常メモリモデル１２は、主にブロック検証で使用され、バスストレスメモリモデル１４は、主にブロック検証のバスインターフェース検証シナリオ等で使用される。
【００３４】
また、システムバス１５としては、バスのデータ幅やバスプロトコルが異なる複数のバリエーションを準備することで、幅広いモジュール仕様に対応することができる。
【００３５】
＜論理検証方法＞
次に、以上説明したテストベンチＴＢを用いて論理検証を行う論理検証方法について、図２〜図４を用いて説明する。
【００３６】
＜検証環境作成の概念＞
図２は、本発明に係る論理検証方法により検証環境を作成する方法を説明する概念図である。なお、以下では、検証対象の半導体集積回路（チップ）として、ＩＳＰ（Image Signal Processing）モジュールおよび動画圧縮規格の１つであるＨ.２６４に基づいて画像処理を行うＨ２６４モジュールを有しているチップを例に採って説明する。
【００３７】
図２に示すように、本発明に係る論理検証方法では、様々な検証シナリオ、検証項目に共通して使用できる共通検証環境１００を準備することとし、ＩＳＰとして動作する機能ブロック（ＩＳＰブロック）およびＨ.２６４に基づいて画像処理を行う機能ブロック（Ｈ２６４ブロック）に対応する検証環境の構築に際しては、共通検証環境１００をリンク（参照）することで、それぞれに必要な、モジュールやテストシナリオを利用して、それぞれＩＳＰブロック検証環境２００およびＨ２６４ブロック検証環境３００を構築する構成となっている。
【００３８】
また、チップ検証環境の構築に際しても、共通検証環境１００をリンクすることで、それぞれに必要な、モジュールやテストシナリオを利用してチップ検証環境４００を構築する構成となっている。この場合、チップ検証環境とブロック検証環境とでファイル構成を共通化することでブロック検証環境の移植を容易としている。なお、ファイル構成の共通化については、後に、図４を用いて説明する。
【００３９】
図２において、共通検証環境１００は、共通ブロック検証環境１０１と、ＩＳＰモジュール１３０と、Ｈ２６４モジュール１４０と、ＩＳＰタスク１５０と、Ｈ２６４タスク１６０とを有している。
【００４０】
共通ブロック検証環境１０１は、共通モジュール１１０および共通タスク１２０を有し、共通モジュール１１０は、ＣＰＵモジュール１１１およびメモリモジュール１１２を含んでいる。また、共通タスク１２０は、レジスタＲ／Ｗタスク１２１およびメモリＲ／Ｗタスク１２２を含んでいる。
【００４１】
ここで、レジスタＲ／Ｗタスク１２１は、ＢＦＭレジスタＲ／Ｗタスク１２１１およびＤＳＭレジスタＲ／Ｗタスク１２１２を含んでいる。
【００４２】
ＢＦＭレジスタＲ／Ｗタスク１２１１およびＤＳＭレジスタＲ／Ｗタスク１２１２の一例としては、８ｂｉｔ、１６ｂｉｔ、３２ｂｉｔおよび６４ｂｉｔで、１回だけレジスタに対するリードまたはライトを行うシングルアクセスを実行させるタスク、６４ｂｉｔで、１回の命令で複数回のリードまたはライトを行うバーストアクセスを実行させるタスクなどが挙げられる。
【００４３】
また、メモリＲ／Ｗタスク１２２は、通常メモリＲ／Ｗタスク１２２１およびバスストレスメモリＲ／Ｗタスク１２２２を含んでいる。
【００４４】
通常メモリＲ／Ｗタスク１２２１の一例としては、論物変換を行わず、受けたデータをそのままメモリに書き込むタスク、面順次の画像データを点順次の画像データに変換する面点変換のタスク、点順次の画像データを面順次の画像データに変換する点面変換のタスク、フレーム構造からフィールド構造への変換タスク、フィールド構造からフレーム構造への変換タスク、ベイヤ配列の１２ｂｉｔから１６ｂｉｔへの変換タスクおよびベイヤ配列の１６ｂｉｔから１２ｂｉｔへの変換タスクなどが挙げられる。
【００４５】
ＣＰＵモジュール１１１は、ＢＦＭモジュール１１１１およびＤＳＭモジュール１１１２を含み、メモリモジュール１１２は、通常メモリモジュール１１２１およびバスストレスメモリモジュール１１２２を含んでいる。
【００４６】
また、ＩＳＰモジュール１３０は、ＩＳＰデバイス１３１を含み、Ｈ２６４モジュール１４０は、Ｈ２６４デバイス１４１を含んでいる。なお、ＩＳＰデバイス１３１およびＨ２６４デバイス１４１は、図１に示したＤＵＴ１３に構築される。
【００４７】
ＩＳＰタスク１５０は、ＩＳＰデバイス１３１における各種処理の検証を行うための複数のタスクを含んでいる。図２では、ＩＳＰ入力画像設定タスク１５１、ＩＳＰフィルタ設定タスク１５２、ＩＳＰ拡大縮小設定タスク１５３およびＩＳＰ出力画像取得タスク１５４を含む例を示しているが、これら以外にも、ダイナミックレンジ設定タスク、オートフォーカス設定タスク、バッファアドレス設定タスクなどを含む場合もある。
【００４８】
なお、ＩＳＰ入力画像設定タスク１５１は、共通タスク１２０のメモリＲ／Ｗタスク１２２をリンクして利用し、ＩＳＰフィルタ設定タスク１５２、ＩＳＰ拡大縮小設定タスク１５３およびＩＳＰ出力画像取得タスク１５４は、共通タスク１２０のレジスタＲ／Ｗタスク１２１をリンクして利用することが示されている。
【００４９】
また、Ｈ２６４タスク１６０は、Ｈ２６４デバイス１４１における各種処理の検証を行うための複数のタスクを含んでいる。図２では、Ｈ２６４入力画像設定タスク１６１、Ｈ２６４動き探索設定タスク１６２、Ｈ２６４量子化設定タスク１６３およびＨ２６４出力ストリーム取得タスク１６４を含む例を示しているが、これら以外にも、エントロピー符号化設定タスク、レート制御設定タスク、バッファアドレス設定タスクなどを含む場合もある。
【００５０】
なお、Ｈ２６４入力画像設定タスク１６１、Ｈ２６４動き探索設定タスク１６２およびＨ２６４量子化設定タスク１６３は、共通タスク１２０のレジスタＲ／Ｗタスク１２１をリンクして利用することが示され、Ｈ２６４出力ストリーム取得タスク１６４は、共通タスク１２０のメモリＲ／Ｗタスク１２２をリンクして利用することが示されている。
【００５１】
以上説明した共通検証環境１００を利用することで、各種ブロック検証環境だけでなく、チップ検証環境も容易に構築することができる。
【００５２】
すなわち、図２に示されるように、ＩＳＰブロック検証環境２００は、モジュール２０１およびＩＳＰテストシナリオ２０２を有しているが、モジュール２０１は、共通検証環境１００の共通モジュール１１０のＣＰＵモジュール１１１およびメモリモジュール１１２をリンクし、また、ＩＳＰモジュール１３０のＩＳＰデバイス１３１をリンクし、それらを利用するように構成されている。
【００５３】
また、ＩＳＰテストシナリオ２０２は、共通検証環境１００のＩＳＰタスク１５０のＩＳＰ入力画像設定タスク１５１、ＩＳＰフィルタ設定タスク１５２、ＩＳＰ拡大縮小設定タスク１５３およびＩＳＰ出力画像取得タスク１５４をリンクし、それらを利用するように構成されている。
【００５４】
このように構成されたＩＳＰブロック検証環境２００において、ＩＳＰテストシナリオ２０２を実行することで、ＩＳＰブロックを構成するＩＳＰデバイス１３１、ＣＰＵモジュール１１１およびメモリモジュール１１２の論理検証を行うことができる。
【００５５】
また、Ｈ２６４ブロック検証環境３００は、モジュール３０１およびＨ２６４テストシナリオ３０２を有しているが、モジュール３０１は、共通検証環境１００の共通モジュール１１０のＣＰＵモジュール１１１およびメモリモジュール１１２をリンクし、また、Ｈ２６４モジュール１４０のＨ２６４デバイス１４１をリンクし、それらを利用するように構成されている。
【００５６】
また、Ｈ２６４テストシナリオ２０２は、共通検証環境１００のＨ２６４タスク１６０のＨ２６４入力画像設定タスク１６１、Ｈ２６４動き探索設定タスク１６２、Ｈ２６４量子化設定タスク１６３およびＨ２６４出力ストリーム取得タスク１６４をリンクし、それらを利用するように構成されている。
【００５７】
このように構成されたＨ２６４ブロック検証環境３００において、Ｈ２６４テストシナリオ３０２を実行することで、Ｈ２６４ブロックを構成するＨ２６４デバイス１４１、ＣＰＵモジュール１１１およびメモリモジュール１１２の論理検証を行うことができる。
【００５８】
また、チップ検証環境４００は、モジュール４０１およびチップテストシナリオ４０２を有しているが、モジュール４０１は、共通検証環境１００の共通モジュール１１０のＣＰＵモジュール１１１およびメモリモジュール１１２をリンクすると共に、ＩＳＰモジュール１３０のＩＳＰデバイス１３１およびＨ２６４モジュール１４０のＨ２６４デバイス１４１をリンクし、それらを利用するように構成されている。
【００５９】
チップテストシナリオ４０２は、共通検証環境１００のＩＳＰタスク１５０のＩＳＰ入力画像設定タスク１５１、ＩＳＰフィルタ設定タスク１５２、ＩＳＰ拡大縮小設定タスク１５３、Ｈ２６４タスク１６０のＨ２６４動き探索設定タスク１６２、Ｈ２６４量子化設定タスク１６３およびＨ２６４出力ストリーム取得タスク１６４をリンクし、それらを利用するように構成されている。
【００６０】
このように構成されたチップ検証環境４００において、チップテストシナリオ４０２を実行することで、チップを構成するＩＳＰデバイス１３１、Ｈ２６４デバイス１４１、ＣＰＵモジュール１１１およびメモリモジュール１１２の論理検証を行うことができる。
【００６１】
なお、チップ検証環境４００では、チップ内の全てのモジュールをインスタンス化（実体化）するのではなく、使用しないモジュールについてはインスタンス化しない。これにより、シミュレーション時間、メモリ使用量を削減できる。
【００６２】
なお、図２に示す共通検証環境１００、ＩＳＰブロック検証環境２００、Ｈ２６４ブロック検証環境３００およびチップ検証環境４００においては、矢印で示されるような利用およびフィードバックの関係を有している。
【００６３】
すなわち、共通検証環境１００に対しては、先に説明したように、ＩＳＰブロック検証環境２００、Ｈ２６４ブロック検証環境３００およびチップ検証環境４００が利用する関係にあると共に、ブロック検証およびチップ検証で発見されたモジュールやテストシナリオの不具合を、共通検証環境１００にフィードバックする関係にある。
【００６４】
これにより、トータルの開発工数（検証環境設計、移植時間、検証時間）、開発コストおよび管理の手間を削減できる。
【００６５】
また、チップ検証環境４００と、ＩＳＰブロック検証環境２００およびＨ２６４ブロック検証環境３００との間では、互いの不具合をフィードバックする関係にある。
【００６６】
例えば、ブロック検証環境からチップ検証環境にフィードバックする情報としては、モジュールの不具合、シナリオの不具合（設定値の間違い、設定不足、設定の順番間違いなど）が挙げられる。
【００６７】
一方、チップ検証環境からブロック検証環境にフィードバックする情報としては、モジュール４０１に含まれるＩＳＰデバイス１３１とＨ２６４デバイス１４１との間の連携に関する不具合や、パフォーマンス改善のためのチップテストシナリオ４０２の設定値の変更情報などが挙げられる。
【００６８】
また、ＩＳＰブロック検証環境２００およびＨ２６４ブロック検証環境３００との間でも、共通検証環境１００を介して、共通ブロック検証環境１０１の不具合情報などをフィードバックすることができる。
【００６９】
なお、図２に示した例では、チップが、ＩＳＰモジュールおよびＨ２６４モジュールを有するものとして説明したが、これら以外に、ＪＰＥＧモジュール、ＧＰＵ（Graphical Processing Unit）モジュール、センサーインターフェース（ＩＦ）モジュール、画像出力モジュール、ＤＳＰ（Digital Signal Processor）モジュール、メモリコントローラモジュール、イーサネット（登録商標）モジュール、ＵＳＢモジュールなどを有する場合もある。
【００７０】
＜論理検証方法のフロー＞
次に、図３に示すフローチャートを用いて、本発明に係る論理検証方法について説明する。
【００７１】
図３に示すように、論理回路の仕様を決定すると、仕様に従って、論理回路を構成するブロックごとにモジュールを設計する。図３の例では、論理回路がブロックＡおよびブロックＢを有している場合を示しており、ブロックＡおよびＢは、互いに、検証シナリオおよび検証項目が異なったブロックである。
【００７２】
ステップＳ１でブロックＡのモジュールを設計し、ステップＳ２でブロックＢのモジュールを設計する。このステップＳ１およびステップＳ２で設計されるモジュールは、ＩＳＰモジュール１３０、Ｈ２６４モジュール１４０、ＩＳＰタスク１５０およびＨ２６４タスク１６０などの各ブロックに固有のモジュールであり、他のブロックとの間で共通化できないモジュールである。
【００７３】
また、ステップＳ３では共通検証環境を設計する。このステップＳ３で設計されるのが、例えば、図２に示した共通ブロック検証環境１０１であり、共通利用されるモジュールについてはステップＳ３で設計される。
【００７４】
なお、ステップＳ３で設計された共通検証環境を利用することで、ブロックごとの検証環境（ブロックＡの検証環境およびブロックＢの検証環境）を設計する必要がほとんどないので、図３においてはブロックごとに検証環境を設計するステップを省略している。
【００７５】
また、同様に、共通検証環境を利用することで、チップ検証環境も設計する必要がほとんどない。すなわち、図２に示したＩＳＰデバイス１３１とＨ２６４デバイス１４１との間の連携部分のみを設計することで足りるので、チップ検証環境を設計するステップを省略している。
【００７６】
そして、ステップＳ４では、共通検証環境を利用することで得られたブロックＡの検証環境を用いてブロックＡの論理検証を行い、ブロックＡの動作の不具合の有無を確認し（ステップＳ５）、不具合があればフィードバックをかけてブロックＡの該当箇所を修正する（ステップＳ６）。この場合、モジュールだけの修正に止まらず、タスクやシナリオについても不具合があれば修正する。一方、不具合がなければステップＳ１０に進む。
【００７７】
同様に、ステップＳ７では、共通検証環境を利用することで得られたブロックＢの検証環境を用いてブロックＢの論理検証を行い、ブロックＢの不具合の有無を確認し（ステップＳ８）、不具合があればフィードバックをかけてブロックＢの該当箇所を修正する（ステップＳ９）。この場合、モジュールだけの修正に止まらず、タスクやシナリオについても不具合があれば修正する。一方、不具合がなければステップＳ１０に進む。
【００７８】
このように、ステップＳ４、Ｓ５およびＳ６の繰り返し、およびステップＳ７、Ｓ８およびＳ９の繰り返しにより、それぞれブロックＡおよびブロックＢの不具合を修正する。
【００７９】
ステップＳ１０では、共通検証環境を利用することで得られたチップ検証環境を用いてチップの検証を行う。なお、チップ検証では、ブロックＡおよびＢの単体動作だけでなく、両者の連携動作についても検証を行う。
【００８０】
そして、ブロックＡの動作の不具合の有無を確認し（ステップＳ１１）、不具合があればフィードバックをかけてブロックＡの該当箇所を修正する（ステップＳ６）。この場合、モジュールだけの修正に止まらず、タスクやシナリオについても不具合があれば修正する。一方、不具合がなければステップＳ１２に進み、ブロックＢの動作の不具合の有無を確認し、不具合があればフィードバックをかけてブロックＢの該当箇所を修正する（ステップＳ９）。この場合、モジュールだけの修正に止まらず、タスクやシナリオについても不具合があれば修正する。一方、不具合がなければステップＳ１３に進む。
【００８１】
ステップＳ１３では、ブロックＡとブロックＢとの連携動作についての不具合の有無を確認し、連携動作に不具合があれば、フィードバックをかけて連携部分を修正する（ステップＳ１４）。この場合、モジュールだけの修正に止まらず、タスクやシナリオについても不具合があれば修正する。一方、不具合がなければ検証作業を終了する。
【００８２】
以上説明したように、本発明に係る論理検証方法によれば、ブロックごとに検証環境を設計する必要がほとんどなく、チップ検証環境を設計する必要もほとんどない。
【００８３】
また、各ブロックに不具合が見つかった場合でも、それが共通モジュールに含まれるモジュールである場合は、共通検証環境を修正すれば良いので、修正に費やす時間を短縮できる。なお、以上説明した効果は、ブロック数が多くなればなるほど大きくなる。
【００８４】
＜ファイル構成の共通化＞
以下、図４を用いてファイル構成の一例について説明する。図４は、ファイル構成を示す一覧表であり、ファイルは５つの階層で構成されている。すなわち、最上位の第１階層は、開発環境ファイル（dev）であることを示し、第２階層は、共通検証環境（common）、チップ検証環境（chip）、サンプル（sample）、ＩＳＰブロック検証環境（isp）およびＨ２６４ブロック検証環境（h264）の項目を示し、第３階層は、第２階層で示されるそれぞれの項目を、ＲＴＬで記述され、ハードウェアを定義するファイル（rtl）か、検証のため（シミュレーションのため）だけのファイル（sim）かを示し、第４階層および第５階層は、rtlおよびsimで分類されるファイルを表している。
【００８５】
すなわち、共通検証環境においては、ＣＰＵのＢＦＭモジュール（cpu_bfm）、ＣＰＵのＤＳＭモジュール（cpu_dsm）、通常メモリモジュール（mem_nrm）、バスストレスメモリモジュール（mem_str）、ＩＳＰモジュール（isp）、Ｈ２６４モジュール（h264）がＲＴＬ（rtl）で記述されたファイルであり、タスク（task）は検証のためだけのファイルである。
【００８６】
ここで、図４で示されるモジュールとは、それぞれの回路の動作を定義（記述）したファイルであり、例えばＢＦＭモジュールとはＢＦＭの動作を定義したファイルである。また、タスクとは、モジュールの制御内容（モジュールへの設定、モジュールからの応答待ちなど）を定義（記述）したファイルであり、後に説明するシナリオ（scenario）とは、検証のためだけのファイルであり、複数のタスクを含んだテストパターンを定義している。
【００８７】
なお、モジュールの制御には、レジスタの設定を含み、タスクにおいてはレジスタ設定部のインターフェースの動作が記述されている。
【００８８】
また、モジュールおよびタスクの実体データ（実体部分の記述）は全て共通検証環境上のファイルにあり、チップ検証環境、ＩＳＰブロック検証環境およびＨ２６４ブロック検証環境では、共通検証環境上のファイルを参照することでファイルを共通化している。
【００８９】
また、第４階層でタスク（task）に分類されたファイルには、第５階層でＣＰＵのＢＦＭタスク（cpu_bfm）、ＣＰＵのＤＳＭタスク（cpu_dsm）、通常メモリタスク（mem_nrm）、バスストレスメモリタスク（mem_str）、ＩＳＰタスク（isp）、Ｈ２６４タスク（h264）が含まれている。
【００９０】
チップ検証環境においては、ＣＰＵモジュール参照（cpu）、メモリモジュール参照（mem）、ＩＳＰモジュール参照(isp)、Ｈ２６４モジュール参照（h264）がＲＴＬ（rtl）で記述されたファイルへのリンクを表している。
【００９１】
すなわち、チップ検証環境においてはＲＴＬで記述されたファイルとして、ＣＰＵモジュール、メモリモジュール、ＩＳＰモジュール参照およびＨ２６４モジュールのファイルを使用するが、これらは、共通検証環境にある実体データであるＣＰＵのＢＦＭモジュール、ＣＰＵのＤＳＭモジュール、通常メモリモジュール、バスストレスメモリモジュール、ＩＳＰモジュール、Ｈ２６４モジュールを参照することが記述されたファイルであり、実体データを含んでいない。
【００９２】
また、第４階層でタスク（task）に分類された構成には、第５階層でＣＰＵタスク参照（cpu）、メモリタスク参照（mem）、ＩＳＰタスク参照（isp）、Ｈ２６４タスク参照（h264）が割り付けられている。
【００９３】
これらも、共通検証環境におけるＣＰＵのＢＦＭタスク、ＣＰＵのＤＳＭタスク、通常メモリタスク、バスストレスメモリタスク、ＩＳＰタスクおよびＨ２６４タスクを参照することが記述されたファイルであり、実体データを含んでいない。
【００９４】
また、第４階層でシナリオ（scenario）に分類されたファイルには、第５階層でＣＨＩＰエンコードシナリオ（encode）、ＣＨＩＰデコードシナリオ（decode）が含まれている。
【００９５】
これらのシナリオのファイルは、チップ検証環境の複数のタスクファイルで構成されており、チップ検証環境の複数のタスクファイルを呼び出すことで実現されるものであり、タスクのファイルと同様に実体データはほとんど記述されていない。
【００９６】
なお、第２階層でサンプル（sample）とされる項目は、ＩＳＰブロック検証環境（isp）およびＨ２６４ブロック検証環境（h264）を構築するためのひな形となるファイルを含んでいる。
【００９７】
また、ＩＳＰブロック検証環境（isp）およびＨ２６４ブロック検証環境（h264）においても上記チップ検証環境と同様の階層分けがされており、モジュール、タスクは、それぞれ共通検証環境のモジュールおよびタスクファイルを参照することが記述されたファイルであり、実体データを含んでおらず、シナリオファイルはタスクファイルを呼び出すことで実現されるという点でチップ検証環境と同じであるが、タスクやシナリオについてはＩＳＰブロック、Ｈ２６４ブロックのそれぞれで特有のタスクやシナリオがあるという点ではチップ検証環境とは異なっている。
【００９８】
また、図４においては、上述した各ファイルに対して番号が採番されている。例えば、共通検証環境における、ＣＰＵのＢＦＭモジュールには「Ｃ１」、ＣＰＵのＤＳＭモジュールには「Ｃ２」、通常メモリモジュールには「Ｃ３」、バスストレスメモリモジュールには「Ｃ４」、ＩＳＰモジュールには「Ｃ５」、Ｈ２６４モジュールには「Ｃ６」が割り当てられている。
【００９９】
また、ＣＰＵのＢＦＭタスクには「Ｃ７」、ＣＰＵのＤＳＭタスクには「Ｃ８」、通常メモリタスクには「Ｃ９」、バスストレスメモリタスクには「Ｃ１０」、ＩＳＰタスクには「Ｃ１１」、Ｈ２６４タスクには「Ｃ１２」が割り当てられている。
【０１００】
これら共通検証環境におけるファイルは全て実体データであり、チップ検証環境、ＩＳＰブロック検証環境およびＨ２６４ブロック検証環境は、共通検証環境の実体データを参照して、それぞれの環境を構築することになるので、実体データを少なくして、データ量を削減することができるという効果がある。
【０１０１】
なお、図４に示す各項目の番号は、図２においても各モジュールや各タスクに付記されている。
【０１０２】
このように、本発明に係る論理検証方法においては、チップ検証環境とブロック検証環境とでファイル（ディレクトリ）構成を共通化することでブロック検証環境の移植により容易にチップ検証環境を構築することができる。
【０１０３】
なお、本発明は、その発明の範囲内において、実施の形態を適宜、変形、省略することが可能である。
【符号の説明】
【０１０４】
１００  共通検証環境
２００  ＩＳＰブロック検証環境
３００  Ｈ２６４ブロック検証環境
４００  チップ検証環境
【図１】
2015096997.tif 000003
【図２】
2015096997.tif 000004
【図３】
2015096997.tif 000005
【図４】
2015096997.tif 000006
【図５】
2015096997.tif 000007