特開 2015-96997 論理検証方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】特開2015-96997(P2015-96997A)

(43)【公開日】2015年5月21日

(54)【発明の名称】論理検証方法

(51)【国際特許分類】

   G06F 17/50 20060101AFI20150424BHJP

【ＦＩ】

   G06F17/50 664L

【審査請求】未請求

【請求項の数】4

【出願形態】ＯＬ

【全頁数】14

(21)【出願番号】特願2013-236458(P2013-236458)

(22)【出願日】2013年11月15日

(71)【出願人】

【識別番号】591128453

【氏名又は名称】株式会社メガチップス

(74)【代理人】

【識別番号】100088672

【弁理士】

【氏名又は名称】吉竹 英俊

(74)【代理人】

【識別番号】100088845

【弁理士】

【氏名又は名称】有田 貴弘

(72)【発明者】

【氏名】安井 基晃

【テーマコード（参考）】

5B046

【Ｆターム（参考）】

5B046AA08

5B046BA02

5B046JA05

(57)【要約】

【課題】ブロック検証環境およびチップ検証環境の設計を簡略化して、論理検証に費やす時間を短縮した論理検証方法を提供する。
【解決手段】複数の機能ブロックのそれぞれを検証する複数のブロック検証環境と、半導体集積回路全体を検証するチップ検証環境とで共通して使用されるモジュールおよびタスクを含む共通検証環境を設計するステップ（ａ）と、共通検証環境を利用することで構築される複数のブロック検証環境を用いて、複数の機能ブロックのそれぞれの論理を検証するステップ（ｂ）と、ステップ（ｂ）の後、共通検証環境を利用することで構築されるチップ検証環境を用いて、半導体集積回路全体の論理を検証するステップ（ｃ）とを備えている。
【選択図】図２

【特許請求の範囲】

【請求項1】

複数の機能ブロックを有した半導体集積回路の論理を検証する論理検証方法であって、
（ａ）前記複数の機能ブロックのそれぞれを検証する複数のブロック検証環境と、前記半導体集積回路全体を検証するチップ検証環境とで共通して使用されるモジュールおよびタスクを含む共通検証環境を設計するステップと、
（ｂ）前記共通検証環境を利用することで構築される前記複数のブロック検証環境を用いて、前記複数の機能ブロックのそれぞれの論理を検証するステップと、
（ｃ）前記ステップ（ｂ）の後、前記共通検証環境を利用することで構築される前記チップ検証環境を用いて、前記半導体集積回路全体の論理を検証するステップと、を備える、論理検証方法。

【請求項2】

前記ステップ（ｂ）の後、
（ｄ）前記ステップ（ｂ）で不具合が発見された機能ブロックについて、前記モジュールおよび前記タスクの修正を行うステップと、
前記ステップ（ｃ）の後、
（ｅ）前記ステップ（ｃ）で不具合が発見された前記半導体集積回路について、前記モジュールおよび前記タスクの修正を行うステップと、を備え、
前記ステップ（ｄ）および（ｅ）は、前記共通検証環境を構成する前記モジュールおよび前記タスクを修正する、請求項１記載の論理検証方法。

【請求項3】

前記ステップ（ｄ）は、
前記共通検証環境を介して、前記複数のブロック検証環境間で前記不具合の情報を互いにフィードバックするステップを含む、請求項２記載の論理検証方法。

【請求項4】

前記複数のブロック検証環境および前記チップ検証環境は、同じファイル構成を有する、請求項１〜請求項３の何れか１項に記載の論理検証方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ハードウェア記述言語等で設計された論理回路を検証する論理検証方法に関する。

【背景技術】

【0002】

電子機器等に用いられている半導体集積回路（ＬＳＩ：Large Scale Integration）は、一般的にＲＴＬ（Register Transfer Level）などのＨＤＬ（Hardware Description Language）によって設計されているが、設計されたＬＳＩが正常に動作するか否かを確認するために論理検証が行われる。

【0003】

この論理検証は、例えば、コンピューター上に構築されたシミュレータの論理検証環境上で行われ、仕様書等に基づいたテストパターンを準備し、当該テストパターンに基づいて、シミュレータ上で検証対象の半導体集積回路を構築して検証するが、半導体集積回路の集積度が向上し、論理回路の規模が大きくなるに従って、論理回路の機能を保証するための検証項目が増大し、検証に費やす時間が長期化する傾向にある。この論理検証に費やす時間を短縮することが、半導体集積回路の開発期間の短縮につながることから、論理検証時間の短縮が求められている。

【0004】

論理検証時間の短縮を目的として、例えば特許文献１には、テストベンチのコマンドに対して、インターフェースを変更するようなコマンドラッパーを被せることで、テストコードの大部分を全く変更することなく再利用できるようにする技術が開示されている。

【0005】

ここで、図５を用いて従来の論理検証方法について説明する。図５は、従来の論理検証方法の一例を示すフローチャートである。

【0006】

図５に示すように、論理回路の仕様を決定すると、仕様に従って、論理回路を構成するブロックごとにモジュールを設計する。図５の例では、論理回路がブロックＡおよびブロックＢを有している場合を示しており、ブロックＡおよびＢは、互いに、検証シナリオおよび検証項目が異なったブロックである。

【0007】

ステップＳ１０１でブロックＡのモジュールを設計し、ステップＳ１０２でブロックＢのモジュールを設計する。

【0008】

そして、各ブロックに合わせて検証環境を設計し、ステップＳ１０３では、ブロックＡの検証環境を設計し、ステップＳ１０４では、ブロックＢの検証環境を設計する。

【0009】

その後、ブロックＡの検証環境を用いてブロックＡの論理検証を行い（ステップＳ１０５）、ブロックＡの動作の不具合の有無を確認し（ステップＳ１０６）、不具合があればフィードバックをかけてブロックＡの該当箇所を修正する（ステップＳ１０７）。一方、不具合がなければステップＳ１１１に進む。

【0010】

同様に、ブロックＢの検証環境を用いてブロックＢの論理検証を行い（ステップＳ１０８）、ブロックＢの不具合の有無を確認し（ステップＳ１０９）、不具合があればフィードバックをかけてブロックＢの該当箇所を修正する（ステップＳ１１０）。一方、不具合がなければステップＳ１１１に進む。

【0011】

このように、ステップＳ１０５、Ｓ１０６およびＳ１０７の繰り返し、およびステップＳ１０８、Ｓ１０９およびＳ１１０の繰り返しにより、それぞれブロックＡおよびブロックＢの不具合を修正する。

【0012】

ステップＳ１１１では、ブロックＡおよびＢを含む半導体集積回路（チップ）全体の検証環境を設計する。そして、設計したチップ検証環境を用いてチップの検証を行う（ステップＳ１１２）。なお、チップ検証では、ブロックＡおよびＢの単体動作だけでなく、両者の連携動作についても検証を行う。

【0013】

そして、ブロックＡの動作の不具合の有無を確認し（ステップＳ１１３）、不具合があればフィードバックをかけてブロックＡの該当箇所を修正する（ステップＳ１１６）。一方、不具合がなければステップＳ１１４に進み、ブロックＢの動作の不具合の有無を確認し、不具合があればフィードバックをかけてブロックＢの該当箇所を修正する（ステップＳ１１７）。一方、不具合がなければステップＳ１１５に進む。

【0014】

ステップＳ１１５では、ブロックＡとブロックＢとの連携動作についての不具合の有無を確認し、連携動作に不具合があれば、フィードバックをかけて連携部分を修正する（ステップＳ１１８）。一方、不具合がなければ検証作業を終了する。

【先行技術文献】

【特許文献】

【0015】

【特許文献1】特開２００６−１２７１０８号公報

【発明の概要】

【発明が解決しようとする課題】

【0016】

以上説明した従来の論理検証方法によれば、検証シナリオ、検証項目が異なる場合、ブロックごとにブロック検証環境を設計する必要があり、また、チップ検証環境も別途に設計する必要がある。

【0017】

また、ブロック検証環境（設定ファイル、シナリオ記述）を移植してチップ検証環境を設計しようとしても、ブロック検証とチップ検証とでは検証環境が違うため、移植工数が多大となる可能性が高い。

【0018】

と言って、ブロック検証をチップ検証環境で行うと、ブロック単位の細かい検証ができず、検証効率および検証カバレッジが低くなる。

【0019】

また、ステップＳ１１３、Ｓ１１４で示されるように、チップ検証でブロックの不具合が判明した場合、不具合の内容によってはステップＳ１０７、Ｓ１１０に戻ってブロック検証を再度行う必要があるが、ブロック検証とチップ検証とで環境が異なるので、修正および再検証に手間と時間がかかる。

【0020】

本発明は上記のような問題を解決するためになされたもので、ブロック検証環境およびチップ検証環境の設計を簡略化して、論理検証に費やす時間を短縮した論理検証方法を提供することを目的とする。

【課題を解決するための手段】

【0021】

本発明に係る論理検証方法の第１の態様は、複数の機能ブロックを有した半導体集積回路の論理を検証する論理検証方法であって、前記複数の機能ブロックのそれぞれを検証する複数のブロック検証環境と、前記半導体集積回路全体を検証するチップ検証環境とで共通して使用されるモジュールおよびタスクを含む共通検証環境を設計するステップ（ａ）と、前記共通検証環境を利用することで構築される前記複数のブロック検証環境を用いて、前記複数の機能ブロックのそれぞれの論理を検証するステップ（ｂ）と、前記ステップ（ｂ）の後、前記共通検証環境を利用することで構築される前記チップ検証環境を用いて、前記半導体集積回路全体の論理を検証するステップ（ｃ）とを備えている。

【0022】

本発明に係る論理検証方法の第２の態様は、前記ステップ（ｂ）の後、前記ステップ（ｂ）で不具合が発見された機能ブロックについて、前記モジュールおよび前記タスクの修正を行うステップ（ｄ）と、前記ステップ（ｃ）の後、前記ステップ（ｃ）で不具合が発見された前記半導体集積回路について、前記モジュールおよび前記タスクの修正を行うステップ（ｅ）とを備え、前記ステップ（ｄ）および（ｅ）は、前記共通検証環境を構成する前記モジュールおよび前記タスクを修正する。

【0023】

本発明に係る論理検証方法の第３の態様は、前記ステップ（ｄ）が、前記共通検証環境を介して、前記複数のブロック検証環境間で前記不具合の情報を互いにフィードバックするステップを含んでいる。

【0024】

本発明に係る論理検証方法の第４の態様は、前記複数のブロック検証環境および前記チップ検証環境が、同じファイル構成を有している。

【発明の効果】

【0025】

本発明によれば、共通検証環境を利用することで複数のブロック検証環境およびチップ検証環境を構築するので、ブロック検証環境およびチップ検証環境の設計を簡略化して、論理検証に費やす時間を短縮することができる。

【図面の簡単な説明】

【0026】

【図1】本発明に係る論理検証方法を実行するテストベンチの構成を示す図である。

【図2】本発明に係る論理検証方法により検証環境を作成する方法を説明する概念図である。

【図3】本発明に係る論理検証方法を説明するフローチャートである。

【図4】ファイル構成の一例を説明する図である。

【図5】従来の論理検証方法を説明するフローチャートである。

【発明を実施するための形態】

【0027】

＜実施の形態＞
＜テストベンチの構成＞
まず、図１を用いて、本発明に係る論理検証方法を実行するテストベンチＴＢの構成について説明する。

【0028】

図１に示すテストベンチＴＢは、検証対象となるチップ１０と、チップ１０に対するテストシナリオを与えるテストコントローラ１、チップ１０に対して、実在する素子をシミュレーションのためにモデル化したデバイスモデル２およびチップ１０における信号をモニタする信号モニタ３とを備えている。

【0029】

チップ１０は、ＣＰＵ（Central Processing Unit）１１、簡易的なメモリモデルである通常メモリモデル１２、ＤＵＴ（Device Under Test）１３およびバスの混雑状況を作り出すバスストレスメモリモデル１４を有し、それぞれが、システムバス１５に接続されている。

【0030】

また、ＣＰＵ１１は、簡易的なＣＰＵ動作モデルであるＢＦＭ（Bus Functional Model）２１と、実際のクロックサイクルベースでＣＰＵの動作をシミュレーションするＤＳＭ（Design Simulation Model）２２とを、有している。

【0031】

なお、上述したテストベンチＴＢの各構成は、ＨＤＬ等で記述されている。

【0032】

ＢＦＭ２１は、レジスタのリード、ライトなど簡易な動作をシミュレーションするモデルであり、主に画像処理のモジュールなどのブロック検証およびチップ検証で使用され、ＤＳＭ２２は、主にＣＰＵのブートモジュールのブロック検証やチップ検証などのメインシナリオで使用するモデルである。

【0033】

通常メモリモデル１２は、主にブロック検証で使用され、バスストレスメモリモデル１４は、主にブロック検証のバスインターフェース検証シナリオ等で使用される。

【0034】

また、システムバス１５としては、バスのデータ幅やバスプロトコルが異なる複数のバリエーションを準備することで、幅広いモジュール仕様に対応することができる。

【0035】

＜論理検証方法＞
次に、以上説明したテストベンチＴＢを用いて論理検証を行う論理検証方法について、図２〜図４を用いて説明する。

【0036】

＜検証環境作成の概念＞
図２は、本発明に係る論理検証方法により検証環境を作成する方法を説明する概念図である。なお、以下では、検証対象の半導体集積回路（チップ）として、ＩＳＰ（Image Signal Processing）モジュールおよび動画圧縮規格の１つであるＨ.２６４に基づいて画像処理を行うＨ２６４モジュールを有しているチップを例に採って説明する。

【0037】

図２に示すように、本発明に係る論理検証方法では、様々な検証シナリオ、検証項目に共通して使用できる共通検証環境１００を準備することとし、ＩＳＰとして動作する機能ブロック（ＩＳＰブロック）およびＨ.２６４に基づいて画像処理を行う機能ブロック（Ｈ２６４ブロック）に対応する検証環境の構築に際しては、共通検証環境１００をリンク（参照）することで、それぞれに必要な、モジュールやテストシナリオを利用して、それぞれＩＳＰブロック検証環境２００およびＨ２６４ブロック検証環境３００を構築する構成となっている。

【0038】

また、チップ検証環境の構築に際しても、共通検証環境１００をリンクすることで、それぞれに必要な、モジュールやテストシナリオを利用してチップ検証環境４００を構築する構成となっている。この場合、チップ検証環境とブロック検証環境とでファイル構成を共通化することでブロック検証環境の移植を容易としている。なお、ファイル構成の共通化については、後に、図４を用いて説明する。

【0039】

図２において、共通検証環境１００は、共通ブロック検証環境１０１と、ＩＳＰモジュール１３０と、Ｈ２６４モジュール１４０と、ＩＳＰタスク１５０と、Ｈ２６４タスク１６０とを有している。

【0040】

共通ブロック検証環境１０１は、共通モジュール１１０および共通タスク１２０を有し、共通モジュール１１０は、ＣＰＵモジュール１１１およびメモリモジュール１１２を含んでいる。また、共通タスク１２０は、レジスタＲ／Ｗタスク１２１およびメモリＲ／Ｗタスク１２２を含んでいる。

【0041】

ここで、レジスタＲ／Ｗタスク１２１は、ＢＦＭレジスタＲ／Ｗタスク１２１１およびＤＳＭレジスタＲ／Ｗタスク１２１２を含んでいる。

【0042】

ＢＦＭレジスタＲ／Ｗタスク１２１１およびＤＳＭレジスタＲ／Ｗタスク１２１２の一例としては、８ｂｉｔ、１６ｂｉｔ、３２ｂｉｔおよび６４ｂｉｔで、１回だけレジスタに対するリードまたはライトを行うシングルアクセスを実行させるタスク、６４ｂｉｔで、１回の命令で複数回のリードまたはライトを行うバーストアクセスを実行させるタスクなどが挙げられる。

【0043】

また、メモリＲ／Ｗタスク１２２は、通常メモリＲ／Ｗタスク１２２１およびバスストレスメモリＲ／Ｗタスク１２２２を含んでいる。

【0044】

通常メモリＲ／Ｗタスク１２２１の一例としては、論物変換を行わず、受けたデータをそのままメモリに書き込むタスク、面順次の画像データを点順次の画像データに変換する面点変換のタスク、点順次の画像データを面順次の画像データに変換する点面変換のタスク、フレーム構造からフィールド構造への変換タスク、フィールド構造からフレーム構造への変換タスク、ベイヤ配列の１２ｂｉｔから１６ｂｉｔへの変換タスクおよびベイヤ配列の１６ｂｉｔから１２ｂｉｔへの変換タスクなどが挙げられる。

【0045】

ＣＰＵモジュール１１１は、ＢＦＭモジュール１１１１およびＤＳＭモジュール１１１２を含み、メモリモジュール１１２は、通常メモリモジュール１１２１およびバスストレスメモリモジュール１１２２を含んでいる。

【0046】

また、ＩＳＰモジュール１３０は、ＩＳＰデバイス１３１を含み、Ｈ２６４モジュール１４０は、Ｈ２６４デバイス１４１を含んでいる。なお、ＩＳＰデバイス１３１およびＨ２６４デバイス１４１は、図１に示したＤＵＴ１３に構築される。

【0047】

ＩＳＰタスク１５０は、ＩＳＰデバイス１３１における各種処理の検証を行うための複数のタスクを含んでいる。図２では、ＩＳＰ入力画像設定タスク１５１、ＩＳＰフィルタ設定タスク１５２、ＩＳＰ拡大縮小設定タスク１５３およびＩＳＰ出力画像取得タスク１５４を含む例を示しているが、これら以外にも、ダイナミックレンジ設定タスク、オートフォーカス設定タスク、バッファアドレス設定タスクなどを含む場合もある。

【0048】

なお、ＩＳＰ入力画像設定タスク１５１は、共通タスク１２０のメモリＲ／Ｗタスク１２２をリンクして利用し、ＩＳＰフィルタ設定タスク１５２、ＩＳＰ拡大縮小設定タスク１５３およびＩＳＰ出力画像取得タスク１５４は、共通タスク１２０のレジスタＲ／Ｗタスク１２１をリンクして利用することが示されている。

【0049】

また、Ｈ２６４タスク１６０は、Ｈ２６４デバイス１４１における各種処理の検証を行うための複数のタスクを含んでいる。図２では、Ｈ２６４入力画像設定タスク１６１、Ｈ２６４動き探索設定タスク１６２、Ｈ２６４量子化設定タスク１６３およびＨ２６４出力ストリーム取得タスク１６４を含む例を示しているが、これら以外にも、エントロピー符号化設定タスク、レート制御設定タスク、バッファアドレス設定タスクなどを含む場合もある。

【0050】

なお、Ｈ２６４入力画像設定タスク１６１、Ｈ２６４動き探索設定タスク１６２およびＨ２６４量子化設定タスク１６３は、共通タスク１２０のレジスタＲ／Ｗタスク１２１をリンクして利用することが示され、Ｈ２６４出力ストリーム取得タスク１６４は、共通タスク１２０のメモリＲ／Ｗタスク１２２をリンクして利用することが示されている。

【0051】

以上説明した共通検証環境１００を利用することで、各種ブロック検証環境だけでなく、チップ検証環境も容易に構築することができる。

【0052】

すなわち、図２に示されるように、ＩＳＰブロック検証環境２００は、モジュール２０１およびＩＳＰテストシナリオ２０２を有しているが、モジュール２０１は、共通検証環境１００の共通モジュール１１０のＣＰＵモジュール１１１およびメモリモジュール１１２をリンクし、また、ＩＳＰモジュール１３０のＩＳＰデバイス１３１をリンクし、それらを利用するように構成されている。

【0053】

また、ＩＳＰテストシナリオ２０２は、共通検証環境１００のＩＳＰタスク１５０のＩＳＰ入力画像設定タスク１５１、ＩＳＰフィルタ設定タスク１５２、ＩＳＰ拡大縮小設定タスク１５３およびＩＳＰ出力画像取得タスク１５４をリンクし、それらを利用するように構成されている。

【0054】

このように構成されたＩＳＰブロック検証環境２００において、ＩＳＰテストシナリオ２０２を実行することで、ＩＳＰブロックを構成するＩＳＰデバイス１３１、ＣＰＵモジュール１１１およびメモリモジュール１１２の論理検証を行うことができる。

【0055】

また、Ｈ２６４ブロック検証環境３００は、モジュール３０１およびＨ２６４テストシナリオ３０２を有しているが、モジュール３０１は、共通検証環境１００の共通モジュール１１０のＣＰＵモジュール１１１およびメモリモジュール１１２をリンクし、また、Ｈ２６４モジュール１４０のＨ２６４デバイス１４１をリンクし、それらを利用するように構成されている。

【0056】

また、Ｈ２６４テストシナリオ２０２は、共通検証環境１００のＨ２６４タスク１６０のＨ２６４入力画像設定タスク１６１、Ｈ２６４動き探索設定タスク１６２、Ｈ２６４量子化設定タスク１６３およびＨ２６４出力ストリーム取得タスク１６４をリンクし、それらを利用するように構成されている。

【0057】

このように構成されたＨ２６４ブロック検証環境３００において、Ｈ２６４テストシナリオ３０２を実行することで、Ｈ２６４ブロックを構成するＨ２６４デバイス１４１、ＣＰＵモジュール１１１およびメモリモジュール１１２の論理検証を行うことができる。

【0058】

また、チップ検証環境４００は、モジュール４０１およびチップテストシナリオ４０２を有しているが、モジュール４０１は、共通検証環境１００の共通モジュール１１０のＣＰＵモジュール１１１およびメモリモジュール１１２をリンクすると共に、ＩＳＰモジュール１３０のＩＳＰデバイス１３１およびＨ２６４モジュール１４０のＨ２６４デバイス１４１をリンクし、それらを利用するように構成されている。

【0059】

チップテストシナリオ４０２は、共通検証環境１００のＩＳＰタスク１５０のＩＳＰ入力画像設定タスク１５１、ＩＳＰフィルタ設定タスク１５２、ＩＳＰ拡大縮小設定タスク１５３、Ｈ２６４タスク１６０のＨ２６４動き探索設定タスク１６２、Ｈ２６４量子化設定タスク１６３およびＨ２６４出力ストリーム取得タスク１６４をリンクし、それらを利用するように構成されている。

【0060】

このように構成されたチップ検証環境４００において、チップテストシナリオ４０２を実行することで、チップを構成するＩＳＰデバイス１３１、Ｈ２６４デバイス１４１、ＣＰＵモジュール１１１およびメモリモジュール１１２の論理検証を行うことができる。

【0061】

なお、チップ検証環境４００では、チップ内の全てのモジュールをインスタンス化（実体化）するのではなく、使用しないモジュールについてはインスタンス化しない。これにより、シミュレーション時間、メモリ使用量を削減できる。

【0062】

なお、図２に示す共通検証環境１００、ＩＳＰブロック検証環境２００、Ｈ２６４ブロック検証環境３００およびチップ検証環境４００においては、矢印で示されるような利用およびフィードバックの関係を有している。

【0063】

すなわち、共通検証環境１００に対しては、先に説明したように、ＩＳＰブロック検証環境２００、Ｈ２６４ブロック検証環境３００およびチップ検証環境４００が利用する関係にあると共に、ブロック検証およびチップ検証で発見されたモジュールやテストシナリオの不具合を、共通検証環境１００にフィードバックする関係にある。

【0064】

これにより、トータルの開発工数（検証環境設計、移植時間、検証時間）、開発コストおよび管理の手間を削減できる。

【0065】

また、チップ検証環境４００と、ＩＳＰブロック検証環境２００およびＨ２６４ブロック検証環境３００との間では、互いの不具合をフィードバックする関係にある。

【0066】

例えば、ブロック検証環境からチップ検証環境にフィードバックする情報としては、モジュールの不具合、シナリオの不具合（設定値の間違い、設定不足、設定の順番間違いなど）が挙げられる。

【0067】

一方、チップ検証環境からブロック検証環境にフィードバックする情報としては、モジュール４０１に含まれるＩＳＰデバイス１３１とＨ２６４デバイス１４１との間の連携に関する不具合や、パフォーマンス改善のためのチップテストシナリオ４０２の設定値の変更情報などが挙げられる。

【0068】

また、ＩＳＰブロック検証環境２００およびＨ２６４ブロック検証環境３００との間でも、共通検証環境１００を介して、共通ブロック検証環境１０１の不具合情報などをフィードバックすることができる。

【0069】

なお、図２に示した例では、チップが、ＩＳＰモジュールおよびＨ２６４モジュールを有するものとして説明したが、これら以外に、ＪＰＥＧモジュール、ＧＰＵ（Graphical Processing Unit）モジュール、センサーインターフェース（ＩＦ）モジュール、画像出力モジュール、ＤＳＰ（Digital Signal Processor）モジュール、メモリコントローラモジュール、イーサネット（登録商標）モジュール、ＵＳＢモジュールなどを有する場合もある。

【0070】

＜論理検証方法のフロー＞
次に、図３に示すフローチャートを用いて、本発明に係る論理検証方法について説明する。

【0071】

図３に示すように、論理回路の仕様を決定すると、仕様に従って、論理回路を構成するブロックごとにモジュールを設計する。図３の例では、論理回路がブロックＡおよびブロックＢを有している場合を示しており、ブロックＡおよびＢは、互いに、検証シナリオおよび検証項目が異なったブロックである。

【0072】

ステップＳ１でブロックＡのモジュールを設計し、ステップＳ２でブロックＢのモジュールを設計する。このステップＳ１およびステップＳ２で設計されるモジュールは、ＩＳＰモジュール１３０、Ｈ２６４モジュール１４０、ＩＳＰタスク１５０およびＨ２６４タスク１６０などの各ブロックに固有のモジュールであり、他のブロックとの間で共通化できないモジュールである。

【0073】

また、ステップＳ３では共通検証環境を設計する。このステップＳ３で設計されるのが、例えば、図２に示した共通ブロック検証環境１０１であり、共通利用されるモジュールについてはステップＳ３で設計される。

【0074】

なお、ステップＳ３で設計された共通検証環境を利用することで、ブロックごとの検証環境（ブロックＡの検証環境およびブロックＢの検証環境）を設計する必要がほとんどないので、図３においてはブロックごとに検証環境を設計するステップを省略している。

【0075】

また、同様に、共通検証環境を利用することで、チップ検証環境も設計する必要がほとんどない。すなわち、図２に示したＩＳＰデバイス１３１とＨ２６４デバイス１４１との間の連携部分のみを設計することで足りるので、チップ検証環境を設計するステップを省略している。

【0076】

そして、ステップＳ４では、共通検証環境を利用することで得られたブロックＡの検証環境を用いてブロックＡの論理検証を行い、ブロックＡの動作の不具合の有無を確認し（ステップＳ５）、不具合があればフィードバックをかけてブロックＡの該当箇所を修正する（ステップＳ６）。この場合、モジュールだけの修正に止まらず、タスクやシナリオについても不具合があれば修正する。一方、不具合がなければステップＳ１０に進む。

【0077】

同様に、ステップＳ７では、共通検証環境を利用することで得られたブロックＢの検証環境を用いてブロックＢの論理検証を行い、ブロックＢの不具合の有無を確認し（ステップＳ８）、不具合があればフィードバックをかけてブロックＢの該当箇所を修正する（ステップＳ９）。この場合、モジュールだけの修正に止まらず、タスクやシナリオについても不具合があれば修正する。一方、不具合がなければステップＳ１０に進む。

【0078】

このように、ステップＳ４、Ｓ５およびＳ６の繰り返し、およびステップＳ７、Ｓ８およびＳ９の繰り返しにより、それぞれブロックＡおよびブロックＢの不具合を修正する。

【0079】

ステップＳ１０では、共通検証環境を利用することで得られたチップ検証環境を用いてチップの検証を行う。なお、チップ検証では、ブロックＡおよびＢの単体動作だけでなく、両者の連携動作についても検証を行う。

【0080】

そして、ブロックＡの動作の不具合の有無を確認し（ステップＳ１１）、不具合があればフィードバックをかけてブロックＡの該当箇所を修正する（ステップＳ６）。この場合、モジュールだけの修正に止まらず、タスクやシナリオについても不具合があれば修正する。一方、不具合がなければステップＳ１２に進み、ブロックＢの動作の不具合の有無を確認し、不具合があればフィードバックをかけてブロックＢの該当箇所を修正する（ステップＳ９）。この場合、モジュールだけの修正に止まらず、タスクやシナリオについても不具合があれば修正する。一方、不具合がなければステップＳ１３に進む。

【0081】

ステップＳ１３では、ブロックＡとブロックＢとの連携動作についての不具合の有無を確認し、連携動作に不具合があれば、フィードバックをかけて連携部分を修正する（ステップＳ１４）。この場合、モジュールだけの修正に止まらず、タスクやシナリオについても不具合があれば修正する。一方、不具合がなければ検証作業を終了する。

【0082】

以上説明したように、本発明に係る論理検証方法によれば、ブロックごとに検証環境を設計する必要がほとんどなく、チップ検証環境を設計する必要もほとんどない。

【0083】

また、各ブロックに不具合が見つかった場合でも、それが共通モジュールに含まれるモジュールである場合は、共通検証環境を修正すれば良いので、修正に費やす時間を短縮できる。なお、以上説明した効果は、ブロック数が多くなればなるほど大きくなる。

【0084】

＜ファイル構成の共通化＞
以下、図４を用いてファイル構成の一例について説明する。図４は、ファイル構成を示す一覧表であり、ファイルは５つの階層で構成されている。すなわち、最上位の第１階層は、開発環境ファイル（dev）であることを示し、第２階層は、共通検証環境（common）、チップ検証環境（chip）、サンプル（sample）、ＩＳＰブロック検証環境（isp）およびＨ２６４ブロック検証環境（h264）の項目を示し、第３階層は、第２階層で示されるそれぞれの項目を、ＲＴＬで記述され、ハードウェアを定義するファイル（rtl）か、検証のため（シミュレーションのため）だけのファイル（sim）かを示し、第４階層および第５階層は、rtlおよびsimで分類されるファイルを表している。

【0085】

すなわち、共通検証環境においては、ＣＰＵのＢＦＭモジュール（cpu_bfm）、ＣＰＵのＤＳＭモジュール（cpu_dsm）、通常メモリモジュール（mem_nrm）、バスストレスメモリモジュール（mem_str）、ＩＳＰモジュール（isp）、Ｈ２６４モジュール（h264）がＲＴＬ（rtl）で記述されたファイルであり、タスク（task）は検証のためだけのファイルである。

【0086】

ここで、図４で示されるモジュールとは、それぞれの回路の動作を定義（記述）したファイルであり、例えばＢＦＭモジュールとはＢＦＭの動作を定義したファイルである。また、タスクとは、モジュールの制御内容（モジュールへの設定、モジュールからの応答待ちなど）を定義（記述）したファイルであり、後に説明するシナリオ（scenario）とは、検証のためだけのファイルであり、複数のタスクを含んだテストパターンを定義している。

【0087】

なお、モジュールの制御には、レジスタの設定を含み、タスクにおいてはレジスタ設定部のインターフェースの動作が記述されている。

【0088】

また、モジュールおよびタスクの実体データ（実体部分の記述）は全て共通検証環境上のファイルにあり、チップ検証環境、ＩＳＰブロック検証環境およびＨ２６４ブロック検証環境では、共通検証環境上のファイルを参照することでファイルを共通化している。

【0089】

また、第４階層でタスク（task）に分類されたファイルには、第５階層でＣＰＵのＢＦＭタスク（cpu_bfm）、ＣＰＵのＤＳＭタスク（cpu_dsm）、通常メモリタスク（mem_nrm）、バスストレスメモリタスク（mem_str）、ＩＳＰタスク（isp）、Ｈ２６４タスク（h264）が含まれている。

【0090】

チップ検証環境においては、ＣＰＵモジュール参照（cpu）、メモリモジュール参照（mem）、ＩＳＰモジュール参照(isp)、Ｈ２６４モジュール参照（h264）がＲＴＬ（rtl）で記述されたファイルへのリンクを表している。

【0091】

すなわち、チップ検証環境においてはＲＴＬで記述されたファイルとして、ＣＰＵモジュール、メモリモジュール、ＩＳＰモジュール参照およびＨ２６４モジュールのファイルを使用するが、これらは、共通検証環境にある実体データであるＣＰＵのＢＦＭモジュール、ＣＰＵのＤＳＭモジュール、通常メモリモジュール、バスストレスメモリモジュール、ＩＳＰモジュール、Ｈ２６４モジュールを参照することが記述されたファイルであり、実体データを含んでいない。

【0092】

また、第４階層でタスク（task）に分類された構成には、第５階層でＣＰＵタスク参照（cpu）、メモリタスク参照（mem）、ＩＳＰタスク参照（isp）、Ｈ２６４タスク参照（h264）が割り付けられている。

【0093】

これらも、共通検証環境におけるＣＰＵのＢＦＭタスク、ＣＰＵのＤＳＭタスク、通常メモリタスク、バスストレスメモリタスク、ＩＳＰタスクおよびＨ２６４タスクを参照することが記述されたファイルであり、実体データを含んでいない。

【0094】

また、第４階層でシナリオ（scenario）に分類されたファイルには、第５階層でＣＨＩＰエンコードシナリオ（encode）、ＣＨＩＰデコードシナリオ（decode）が含まれている。

【0095】

これらのシナリオのファイルは、チップ検証環境の複数のタスクファイルで構成されており、チップ検証環境の複数のタスクファイルを呼び出すことで実現されるものであり、タスクのファイルと同様に実体データはほとんど記述されていない。

【0096】

なお、第２階層でサンプル（sample）とされる項目は、ＩＳＰブロック検証環境（isp）およびＨ２６４ブロック検証環境（h264）を構築するためのひな形となるファイルを含んでいる。

【0097】

また、ＩＳＰブロック検証環境（isp）およびＨ２６４ブロック検証環境（h264）においても上記チップ検証環境と同様の階層分けがされており、モジュール、タスクは、それぞれ共通検証環境のモジュールおよびタスクファイルを参照することが記述されたファイルであり、実体データを含んでおらず、シナリオファイルはタスクファイルを呼び出すことで実現されるという点でチップ検証環境と同じであるが、タスクやシナリオについてはＩＳＰブロック、Ｈ２６４ブロックのそれぞれで特有のタスクやシナリオがあるという点ではチップ検証環境とは異なっている。

【0098】

また、図４においては、上述した各ファイルに対して番号が採番されている。例えば、共通検証環境における、ＣＰＵのＢＦＭモジュールには「Ｃ１」、ＣＰＵのＤＳＭモジュールには「Ｃ２」、通常メモリモジュールには「Ｃ３」、バスストレスメモリモジュールには「Ｃ４」、ＩＳＰモジュールには「Ｃ５」、Ｈ２６４モジュールには「Ｃ６」が割り当てられている。

【0099】

また、ＣＰＵのＢＦＭタスクには「Ｃ７」、ＣＰＵのＤＳＭタスクには「Ｃ８」、通常メモリタスクには「Ｃ９」、バスストレスメモリタスクには「Ｃ１０」、ＩＳＰタスクには「Ｃ１１」、Ｈ２６４タスクには「Ｃ１２」が割り当てられている。

【0100】

これら共通検証環境におけるファイルは全て実体データであり、チップ検証環境、ＩＳＰブロック検証環境およびＨ２６４ブロック検証環境は、共通検証環境の実体データを参照して、それぞれの環境を構築することになるので、実体データを少なくして、データ量を削減することができるという効果がある。

【0101】

なお、図４に示す各項目の番号は、図２においても各モジュールや各タスクに付記されている。

【0102】

このように、本発明に係る論理検証方法においては、チップ検証環境とブロック検証環境とでファイル（ディレクトリ）構成を共通化することでブロック検証環境の移植により容易にチップ検証環境を構築することができる。

【0103】

なお、本発明は、その発明の範囲内において、実施の形態を適宜、変形、省略することが可能である。

【符号の説明】

【0104】

１００ 共通検証環境
２００ ＩＳＰブロック検証環境
３００ Ｈ２６４ブロック検証環境
４００ チップ検証環境

【図1】

【図2】

【図3】

【図4】

【図5】