(57)【要約】【課題】ＳｏＣデバイスの検証作業において、ハードウェアモデルシミュレーションにて発生した不具合を早急かつ少ない工数で論理検証において再現させることを可能にする。【解決手段】ハードウェアモデルシミュレーションにて不具合を発生させたテストプログラムにしたがって、そのＳｏＣデバイスのソフトウェアモデルを動作させ、その動作の過程で発生するメモリアクセス、メモリの更新待ち、レジスタアクセス、およびレジスタの更新待ちの各々をＲＴＬに変換しつつその発生順にログに記録する。そして、当該ログをテストタスクとして論理検証を実行する。【選択図】図１
2011145880.tif 000002
【特許請求の範囲】
【請求項１】
検証対象の半導体集積回路が有する機能を実現する論理を所定のハードウェア記述言語で記述した論理回路モデルをＲＴＬで表現されたテストタスクにしたがって動作させ、前記半導体集積回路の出力ピンの信号値の推移と前記半導体回路の内部回路のネットの信号値の推移の何れか一方または両方を検証する論理検証ステップにて使用する前記テストタスクの生成方法において、
前記半導体集積回路と同一の機能を実現するように作成されたハードウェアモデルをテストプログラムにしたがって動作させ、不具合の有無を検証するハードウェアモデルシミュレーションステップと、
前記半導体集積回路の機能を実現するようにプログラムされたソフトウェアモデルを前記ハードウェアモデルシミュレーションステップにて不具合が発見されたテストプログラムにしたがって動作させ、その動作の過程で発生するメモリアクセス、メモリの更新待ち、レジスタアクセス、およびレジスタの更新待ちの各々をＲＴＬに変換しつつその発生順にログに記録し、当該ログを前記テストタスクとして出力するソフトウェアモデルシミュレーションステップと、
を含むことを特徴とする論理検証のテストタスクの生成方法。
【請求項２】
前記ソフトウェアモデルは、前記半導体集積回路が有する各機能に対応する機能モデルと、前記半導体集積回路が有する内蔵ＣＰＵに対応する内蔵ＣＰＵモデルとを含み、前記ソフトウェアモデルシミュレーションステップにおいては、テストプログラムによる各機能モデルへのアクセス過程で発生するメモリアクセス、メモリの更新待ち、レジスタアクセス、およびレジスタの更新待ちの各々と、前記テストプログラムによるアクセスを契機として前記内蔵ＣＰＵモデルが各機能モデルにアクセスする際に発生するメモリアクセス、メモリの更新待ち、レジスタアクセス、およびレジスタの更新待ちの各々と、を区別せずに前記ログに記録することを特徴とする請求項１に記載の論理検証のテストタスクの生成方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、半導体集積回路の検証を支援する技術に関し、特に、論理検証にて使用するテストタスクを生成する技術に関する。
【背景技術】
【０００２】
半導体集積回路の一例として、マイクロコントローラや各種インターフェース回路等を１つの半導体チップに実装したＳｏＣ（System on Chip）デバイスが挙げられる。ＳｏＣデバイスに作り込んだ各種機能が正しく動作するか否かを検証する際の手法としては、論理検証と、ＦＰＧＡ（Field Programmable Gate Array）検証に代表されるハードウェアモデルシミュレーションと、が挙げられる。論理検証とは、ＳｏＣデバイスの機能をハードウェアレジスタと論理回路との間の信号の流れで表現したＲＴＬ（Register Transfer Logic）の検証を行う作業のことである。この論理検証では、論理シミュレータと呼ばれるソフトウェア（例えばＶＣＳ（登録商標）など）を用いて様々な信号パターンをＲＴＬに入力し、出力ピンの信号値と回路内部のネットの信号値の何れか一方または両方のダンプが行われる。そして、このようにしてダンプされる信号値の推移を参考に各種機能が正しく動作しているか否かの検証が行われるのである。一方、ハードウェアモデルシミュレーションでは、ＦＰＧＡなどのプログラマブルロジックデバイスに上記ＳｏＣデバイスの各機能を実現する論理をプログラムし、そのＦＰＧＡの作動制御をテストプログラムにしたがってＣＰＵに行わせることで、それら機能の検証が行われる。例えば、検証対象のＳｏＣデバイスが画像処理デバイス等であれば、ハードウェアモデルシミュレーションの実行過程でＦＰＧＡが描画する画像を確認（本来描画されるべき画像が描画されているか否かの確認等）することで不具合の有無が判断される。また、ＳｏＣデバイスの開発では、論理検証やハードウェアモデルシミュレーションとは別個に、開発しようとするＳｏＣデバイスのソフトウェアモデルを作成し、そのソフトウェアモデルを用いて事前検証が行われることが多い。ここで、ソフトウェアモデルとは、開発しようとするＳｏＣデバイスに実装する機能を実現する論理をＣ言語などの所定のプログラム言語で記述したソフトウェアである。このようなソフトウェアモデルは、事前検証にて使用される他に、そのＳｏＣデバイスに内蔵されるＣＰＵ（以下、内蔵ＣＰＵ）用のファームウェアの開発の際のスタブとして使用されたり、ハードウェアモデルシミュレーションを実行する際の参照モデルとして使用されたりする。
【０００３】
論理検証には、出力ピンや回路内部のネットの信号値のダンプを参考に不具合の内容を詳細に解析することができるといった利点がある一方、その実行に多大な時間を要するといった欠点がある。逆に、ハードウェアモデルシミュレーションの場合は、その実行に要する時間は短いものの、出力ピンや回路内部のネットの信号値といった詳細な情報を得ることができないといった欠点がある。このため、半導体集積回路の検証を行う際には、論理検証とハードウェアモデルシミュレーションの各々の長所／短所を考慮して両者を連携させることが従来より行われている。例えば、まず、ハードウェアモデルシミュレーションを行って不具合の有無を確認し、不具合があった場合には、そのハードウェアモデルシミュレーションにて使用したテストプログラムにしたがって行われるメモリアクセス等を手作業でＲＴＬに記述し直して論理検証を行い、不具合の原因を詳細に検討する、といった具合である。しかし、テストプログラムをＲＴＬに書き直す作業には多大な工数を要するため、より簡便に両者を連携させることが望まれており、そのようなことを可能にする技術が種々提案されている。例えば、特許文献１には、ＦＰＧＡに内部信号ダンプ回路を設け、当該内部信号ダンプ回路の出力を論理シミュレータに与えることが提案されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−２２７９５８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし、特許文献１に開示された技術では、ＦＰＧＡに内部信号ダンプ回路を設ける必要があり、また、検証対象の半導体集積回路に変更が加えられる度に内部信号ダンプ回路にも変更を加えることが必要になり、やはり多大な工数を要することとなる。また、ＦＰＧＡと論理シミュレータとをサイクルレベルで同期させることが必要であり、シミュレーションに時間がかかることに加えて、ＦＰＧＡと論理シミュレータの同期制御が難しいといった問題もある。
本発明は上記課題に鑑みて為されたものであり、ハードウェアモデルシミュレーションにて発生した不具合を早急かつ少ない工数で論理検証において再現することを可能にする技術を提供することを目的とする。
【課題を解決するための手段】
【０００６】
上記課題を解決するために、本発明は、検証対象の半導体集積回路が有する機能を実現する論理を所定のハードウェア記述言語で記述した論理回路モデルをＲＴＬで表現されたテストタスクにしたがって動作させ、前記半導体集積回路の出力ピンの信号値の推移と前記半導体回路の内部回路のネットの信号値の推移の何れか一方または両方を検証する論理検証ステップにて使用する前記テストタスクの生成方法において、前記半導体集積回路と同一の機能を実現するように作成されたハードウェアモデルをテストプログラムにしたがって動作させ、不具合の有無を検証するハードウェアモデルシミュレーションステップと、前記半導体集積回路の機能を実現するようにプログラムされたソフトウェアモデルを前記ハードウェアモデルシミュレーションステップにて不具合が発見されたテストプログラムにしたがって動作させ、その動作の過程で発生するメモリアクセス、メモリの更新待ち、レジスタアクセス、およびレジスタの更新待ちの各々をＲＴＬに変換しつつその発生順にログに記録し、当該ログを前記テストタスクとして出力するソフトウェアモデルシミュレーションステップと、を含むことを特徴とする論理検証のテストタスクの生成方法、を提供する。
【０００７】
このようなテストタスク生成方法においては、ハードウェアモデルシミュレーションステップにて不具合を発生させたメモリアクセス等を含むアクセスパターンがソフトウェアモデルシミュレーションステップにおいてＲＴＬに変換され、その発生順にログに記録され、このようにして記録されたログが論理検証におけるテストタスクとして出力される。このテストタスクには、ハードウェアモデルシミュレーションにて不具合を発生させたアクセスパターンが含まれているため、このテストタスクにしたがって論理検証を実行することで、ハードウェアモデルシミュレーションにて発生した不具合をその論理検証において再現することができる。
【０００８】
より好ましい態様においては、前記ソフトウェアモデルシミュレーションステップにて使用されるソフトウェアモデルは、前記半導体集積回路が有する各機能に対応する機能モデルと、前記半導体集積回路が有する内蔵ＣＰＵに対応する内蔵ＣＰＵモデルとを含み、前記ソフトウェアモデルシミュレーションステップにおいては、テストプログラムによる各機能モデルへのアクセス過程で発生するメモリアクセス、メモリの更新待ち、レジスタアクセス、およびレジスタの更新待ちの各々と、前記テストプログラムによるアクセスを契機として前記内蔵ＣＰＵモデルが各機能モデルにアクセスする際に発生するメモリアクセス、メモリの更新待ち、レジスタアクセス、およびレジスタの更新待ちの各々とを区別せずに前記ログに記録することを特徴とする。テストプログラムにしたがって実行されるアクセスのみをＲＴＬ化すると、そのＲＴＬには論理検証において内蔵ＣＰＵの動作シミュレーションの実行を要するものが含まれることとなる。これに対して本態様によれば、テストプログラムにしたがって直接的に行われるメモリアクセス等に加えて内蔵ＣＰＵモデルの動作の結果発生したメモリアクセス等もＲＴＬ化される。したがって、論理検証においては、内蔵ＣＰＵの動作シミュレーションを省略することができ、この省略の分だけ論理検証の実行に要する時間を短縮することができる。
【図面の簡単な説明】
【０００９】
【図１】本発明の一実施形態であるデバイス検証システム１の構成例を示すブロック図である。
【図２】同デバイス検証システム１を利用してＳｏＣデバイスの検証を行う際の検証手順の流れを表わすフローチャートである。
【発明を実施するための形態】
【００１０】
以下、図面を参照しつつ本発明の実施形態について説明する。
（Ａ：構成）
図１は、本発明の一実施形態のデバイス検証システム１の構成例を示すブロック図である。このデバイス検証システム１は、検証対象のＳｏＣデバイスの検証工程の作業を支援するためのものである。図１に示すように、このデバイス検証システム１には、ＳｏＣデバイスの論理検証を行うための論理シミュレータ１０、ハードウェアモデルシミュレーションを行うためのＦＰＧＡボード２０、およびＳｏＣソフトウェアモデルシミュレータ３０が含まれている。
【００１１】
論理シミュレータ１０は、所謂ＣＡＤ（Computer Aided Design）シミュレータであり、ワークステーション（以下、「ＷＳ」と略記）やパーソナルコンピュータ（以下、「ＰＣ」と略記）などのコンピュータ装置（図１では図示略）にて実行されるソフトウェアである。なお、以下では論理シミュレータ１０を実行するコンピュータ装置のことを「論理検証用端末」と呼ぶ場合がある。この論理シミュレータ１０では、テストタスク１２０にしたがって各種信号パターンの入力信号を論理回路モデル１１０に与え、その動作シミュレーションを行う論理検証が実行される。論理回路モデル１１０とテストタスク１２０は、所定のＨＤＬで記述されたＲＴＬである。図１に示すように論理回路モデル１１０には、検証対象のＳｏＣデバイスが有する各機能を実現する論理をＨＤＬで記述した機能記述ＲＴＬ１１０ａと、そのＳｏＣデバイスに含まれる内蔵ＣＰＵがファームウェアにしたがって実現する機能をＨＤＬで記述した内蔵ＣＰＵ記述ＲＴＬ１１０ｂが含まれている。
【００１２】
ＦＰＧＡボード２０には、ホストＣＰＵ２１０と、ＦＰＧＡ群２２０とが含まれている。ＦＰＧＡ群２２０は、複数のＦＰＧＡの集合体であり、検証対象のＳｏＣデバイスのハードウェアモデルの役割を果たす。ＦＰＧＡとは、論理のプログラムが可能なプログラマブルロジックデバイスである。図１のＦＰＧＡ群２２０を構成する複数のＦＰＧＡの各々は、検証対象のＳｏＣデバイスが有する各機能を実現する論理がプログラムされたもの（図１の機能ブロック２２０ａ）と、そのＳｏＣデバイスに含まれる内蔵ＣＰＵがファームウェアにしたがって実現する機能の論理がプログラムされたもの（図１の内蔵ＣＰＵブロック２２０ｂ）に分類される。図１のホストＣＰＵ２１０は、Ｃ言語などのプログラミング言語で記述されたテストプログラム（より正確には、当該テストプログラムのソースコードをコンパイルして得られるロードモジュール）２１０ａを実行し、当該テストプログラムにしたがってＦＰＧＡ群２２０の作動制御を行う。例えば、検証対象のＳｏＣデバイスが画像処理デバイスである場合には、その画像処理デバイスが有する各機能を実現する論理が予めプログラミングされたＦＰＧＡボードを液晶ディスプレイなどの表示装置に接続し、テストプログラム２１０ａにしたがって実際に画像表示を行わせることで、そのＳｏＣデバイスのハードウェアモデルシミュレーションが実現されるのである。
【００１３】
図１のアクセスライブラリ２１０ｂは、レジスタアクセス（レジスタへのデータの書き込みやレジスタからのデータの読み出し）、メモリアクセス（メモリへのデータの書き込みやメモリからのデータ読み出し）、およびメモリ（或いはレジスタ）の格納内容の変化待ち（例えば、メモリ等に格納されているデータが予め定められた値になるまでウェイトを繰り返す処理）を実現するサブルーチンプログラム（以下、ＡＰＩとも言う）をソフトウェアライブラリ化したものである。テストプログラム２１０ａにしたがって行われるＦＰＧＡの作動制御（すなわち、ハードウェアモデルシミュレーション）の実行過程で発生するレジスタアクセスおよびメモリアクセスはアクセスライブラリ２１０ｂを通じて実現される。例えば、テストプログラム２１０ａにレジスタアクセスまたはメモリアクセスの実行を指示するコードが含まれている場合には、ホストＣＰＵ２１０は当該コードに対応するＡＰＩをアクセスライブラリ２１０ｂから読み出し、そのＡＰＩにしたがった処理を実行することで当該コードの示す処理が実現される。
【００１４】
さて、図１に示すデバイス検証システム１においては、論理シミュレータ１０を用いた論理検証とＦＰＧＡボード２０を用いたハードウェアモデルシミュレーションとを各々別個独立に行うことができることは勿論である。これに加えて、本実施形態のデバイス検証システム１においては、ＳｏＣソフトウェアモデルシミュレータ３０を用いることにより、論理検証とハードウェアモデルシミュレーションとを簡便に連携させることができる。具体的には、ハードウェアモデルシミュレーションにて何らかの不具合が発見された場合に、その不具合を論理検証において再現させることが可能のテストタスクを早急かつ少ない工数で生成することができるのである。以下、本実施形態の特徴を顕著に示すＳｏＣソフトウェアモデルシミュレータ３０を中心に説明する。
【００１５】
図１のＳｏＣソフトウェアモデルシミュレータ３０は、論理シミュレータ１０と同様にＷＳやＰＣなどのコンピュータ装置で実行されるソフトウェアである。以下では、ＳｏＣソフトウェアモデルシミュレータ３０を実行するコンピュータ装置のことを「ソフトウェアモデルシミュレーション端末」と呼ぶ場合がある。このＳｏＣソフトウェアモデルシミュレータ３０では、テストプログラム３２０にしたがってＳｏＣソフトウェアモデル３１０の動作シミュレーションが実行される。
【００１６】
ＳｏＣソフトウェアモデル３１０は、検証対象のＳｏＣデバイスが有する各機能を実現する論理を所定のプログラミング言語（例えば、Ｃ言語）で記述したソフトウェア（すなわち、前述したソフトウェアモデル）である。図１の機能モデル３１０ａは、検証対象のＳｏＣデバイスが有する各機能を実現するソフトウェアモジュール（例えばサブルーチン）であり、内蔵ＣＰＵモデル３１０ｂはそのＳｏＣデバイスに含まれる内蔵ＣＰＵがファームウェアにしたがって実現する機能を再現するソフトウェアモジュールである。前述したように、ＳｏＣソフトウェアモデルは、本来、他の目的（例えばＳｏＣデバイスの内蔵ＣＰＵ用のファームウェアの開発の際のスタブとして使用するため、開発しようとするＳｏＣデバイスについての事前の機能検証のため、或いは、ハードウェアモデルシミュレーションを実行する際の参照モデルとして使用するため等）で作成されることが多い。論理検証とハードウェアモデルシミュレーションの連携を容易にするために新たにＳｏＣソフトウェアモデルを作成するのであれば、その作成に要する工数は膨大であり、必ずしも得策であるとは言えない。しかし、本実施形態では、他の目的で作成されたＳｏＣソフトウェアモデルを流用しているため、少ない工数で論理検証とハードウェアモデルシミュレーションとを連携させることが可能になるのである。
【００１７】
図１に示すＳｏＣソフトウェアモデル３１０は、機能モデル３１０ａおよび内蔵ＣＰＵモデル３１０ｂの他にログ生成部３１０ｃを有しており、このログ生成部３１０ｃは、内蔵ＣＰＵ用のファームウェアの開発のため等の目的で作成されるＳｏＣソフトウェアモデルには含まれていないものである。つまり、本実施形態のＳｏＣソフトウェアモデル３１０は、内蔵ＣＰＵ用のファームウェアの開発のため等の目的で作成されるＳｏＣソフトウェアモデルにログ生成部３１０ｃを追加したものであり、その追加には新たな工数を要する。しかし、ログ生成部３１０ｃの追加に要する工数はＳｏＣソフトウェアモデルを一から新たに作成する際の工数や、ハードウェアモデルシミュレーションにて不具合の発生が確認されたテストプログラムをＲＴＬに書き換える際の工数に比較して遥かに小さく、特段の問題が生じることはない。なお、ログ生成部３１０ｃが担う役割等については後に詳細に説明する。
【００１８】
テストプログラム３２０は、テストプログラム２１０ａのソースコードをソフトウェアモデルシミュレーション端末用に再コンパイルしたものである。この再コンパイルを行う際には、テストプログラム２１０ａのソースコードに改変を加える必要はない。なお、テストプログラム２１０ａがソフトシミュレーション端末においてそのまま実行可能である場合には、上記再コンパイルも不要である。このテストプログラム３２０にしたがって実行される機能モデル３１０ａへのアクセスおよび内蔵ＣＰＵモデル３１０ｂへのアクセスはアクセスライブラリ３３０を通して行われる。アクセスライブラリ３３０は、前述したアクセスライブラリ２１０ｂと同様にレジスタアクセス、メモリアクセス、およびメモリ（或いはレジスタ）の格納内容の変更待ちを実現するＡＰＩをライブラリ化したソフトウェアライブラリである。ただし、これらＡＰＩは、レジスタアクセス等の処理を実行するのみならず、当該ＡＰＩの呼び出しがあったこと、その呼び出しの際の引数（アクセス先のメモリ領域を規定するアドレスや、そのアクセス範囲を規定するマスク等）、およびその呼び出し時刻（テストプログラム３２０の実行開始時点を時刻の起算点とした場合におけるその呼び出しの実行時刻）をログ生成部３１０ｃへ通知する処理を実行する点が前述したアクセスライブラリ２１０ｂに含まれている各ＡＰＩと異なる。
【００１９】
また、図１に示すように、本実施形態では、内蔵ＣＰＵモデル３１０ｂ用のアクセスライブラリも予め用意されており、この内蔵ＣＰＵモデル３１０ｂ用のアクセスライブラリには、ファームウェアの実行過程で発生するレジスタアクセス、メモリアクセス、およびメモリ（或いはレジスタ）の格納内容の変更待ちを実現するＡＰＩが含まれている。そして、内蔵ＣＰＵモデル３１０ｂ用のアクセスライブラリに含まれるＡＰＩもアクセスライブラリ３３０に含まれるものと同様に、当該ＡＰＩの呼び出しがあったこと、およびその呼び出しの際の引数をログ生成部３１０ｃへ通知する処理を実行する。
【００２０】
ログ生成部３１０ｃは、アクセスライブラリ３３０に含まれるＡＰＩ、または内蔵ＣＰＵモデル３１０ｂ用のアクセスライブラリに含まれるＡＰＩからの通知を受け、その通知内容の示すメモリアクセス、レジスタアクセスまたはメモリ（レジスタ）の格納内容の更新待ちを表すＲＴＬを生成し、その通知の受付順（すなわち、それらメモリアクセス等の発生順）に内蔵ＣＰＵ経由であるか否かを区別せずにログに書き出す処理を実行するソフトウェアモジュールである。なお、上記各ＲＴＬをログに書き出す際には、そのＲＴＬにより表されるアクセスの実行時刻（ＡＰＩの呼び出し時刻）を示す時間情報を対応付けて書き出すようにしても良い。つまり、本実施形態では、テストプログラム３２０にしたがって実行される動作シミュレーションの実行過程で発生するメモリアクセス、レジスタアクセス、およびメモリ（レジスタ）の格納内容の更新待ちと、テストプログラム３２０からのアクセスが契機となって内蔵ＣＰＵモデル３１０ｂにて発生するメモリアクセス、レジスタアクセス、およびメモリ（レジスタ）の格納内容の更新待ちがログ生成部３１０ｃにて集約され、そのアクセス内容に応じたＲＴＬがそれらアクセスの発生順にロギングされるのである。このように、内蔵ＣＰＵ経由であるか否かを区別せずにロギングすることとした理由については後に明らかにする。そして、本実施形態ではこのようにして生成されるログを論理検証におけるテストタスクとして使用することで論理検証とハードウェアモデルシミュレーションとの連携が実現されるのである。
以上がデバイス検証システム１の構成である。
【００２１】
（Ｂ：動作）
以下、本実施形態のデバイス検証システム１を利用してハードウェアモデルシミュレーションと論理検証とを連携させる際の手順について図２を参照しつつ説明する。デバイス検証システム１のユーザ（例えば、ＳｏＣデバイスの設計者など）は、最初にＦＰＧＡボード２０を用いてハードウェアモデルシミュレーションを行う（ステップＳＡ０１０）。最初にハードウェアモデルシミュレーションを行うのは、論理検証に比較して所要時間が短く、不具合の発生の有無を容易に判断することができるからである。前述したように検証対象のＳｏＣデバイスが画像処理デバイスである場合には、ＦＰＧＡボード２０に表示装置を接続し、ハードウェアモデルシミュレーションの実行過程でその表示装置に表示される画像に基づいて不具合の発生の有無を判断することができる。
【００２２】
ステップＳＡ０１０のハードウェアモデルシミュレーションにて不具合が発生しなかった場合（ステップＳＡ０２０：Ｎｏ）には、ＳｏＣデバイスの検証作業は終了である。なお、本動作例では、ステップＳＡ０１０のハードウェアモデルシミュレーションにて不具合が発見されない場合には検証手順を終了するとしたが、テストプログラムを変更して更にハードウェアモデルシミュレーションを継続しても勿論良い。これに対して、不具合が発見された場合（ステップＳＡ０２０：Ｙｅｓ）には、ユーザはステップＳＡ０３０の作業を行う。このステップＳＡ０３０の作業は、ハードウェアモデルシミュレーションにて不具合の発生が確認されたテストプログラム２１０ａをソフトウェアモデルシミュレーション端末にて実行可能なものに再コンパイルする作業である。なお、ハードウェアモデルシミュレーションにて使用したテストプログラムのロードモジュールがソフトウェアシミュレーション端末においても実行可能なものである場合には、このステップＳＡ０３０の作業を省略できることは前述した通りである。
【００２３】
次いで、ユーザは、ステップＳＡ０３０の作業により得られたロードモジュールを本実施形態のテストプログラム３２０としてソフトウェアモデルシミュレーション端末にインストールし、ＳｏＣソフトウェアモデルシミュレータ３０による動作シミュレーションを実行する（ステップＳＡ０４０）。このステップＳＡ０４０にて使用されるテストプログラム３２０にしたがって順次行われるメモリアクセス等には、ステップＳＡ０１０のハードウェアモデルシミュレーションにて不具合を発生させたアクセスパターンが含まれている。したがって、ＳｏＣソフトウェアモデル３１０のログ生成部３１０ｃによって生成されるログにはその不具合を引き起こすアクセスパターンに対応するＲＴＬが含まれていることになる。
【００２４】
そして、ユーザは、ステップＳＡ０４０にて生成されたログをテストタスク１２０として論理シミュレーション端末に記憶させ、そのテストタスク１２０にしたがった論理検証を実行する（ステップＳＡ０５０）。前述したように、ステップＳＡ０４０にて生成されたログには、ステップＳＡ０１０のハードウェアモデルシミュレーションにて不具合を発生させたアクセスパターンに対応するものが含まれている。したがって、この論理検証においては、ハードウェアモデルシミュレーションにて発生した不具合が再現され、出力ピンや内部回路のネットの信号値のダンプを参照することで、その不具合の原因を速やかに解明することができるのである。
【００２５】
加えて、本実施形態では、ステップＳ０４０にて生成されるログに含まれているＲＴＬのうち、テストプログラム３２０からのアクセスが契機となって内蔵ＣＰＵモデル３１０ｂにて発生するメモリアクセス、レジスタアクセス、およびメモリ（レジスタ）格納内容の更新待ちに応じたＲＴＬは、その内蔵ＣＰＵモデル３１０ｂの動作結果である。したがって、論理検証の実行過程では内蔵ＣＰＵの動作シミュレーションを行う必要はなく、この動作シミュレーションの所要時間の分だけ論理検証の所要時間を短縮することができる。
以上が本実施形態におけるＳｏＣデバイスの検証手順である。
【００２６】
以上説明したように本実施形態によれば、ハードウェアモデルシミュレーションにて発生した不具合を論理検証にて簡便に再現することが可能になる。加えて、本実施形態では、ＦＰＧＡボード２０に内部信号ダンプ回路を設ける必要はなく、特許文献１に開示された技術に比較して少ない工数で、ハードウェアモデルシミュレーションにて発生した不具合を論理検証にて再現させることが可能になるのである。
【００２７】
（Ｃ：変形）
以上本発明の一実施形態について説明したが、この実施形態を以下のように変形しても勿論良い。
（１）上述した実施形態では、レジスタアクセスおよびメモリアクセス用のＡＰＩをライブラリ化したソフトウェアライブラリであるアクセスライブラリ３３０がソフトウェアモデルシミュレーション端末に予めインストールされていた。しかし、アクセスライブラリ３３０を例えばＣＤ−ＲＯＭ（Compact Disk-Read Only Memory）などのコンピュータ装置読み取り可能な記録媒体に書き込んで配布しても良く、また、インターネットなどの電気通信回線経由のダウンロードによりアクセスライブラリ３３０を配布しても良い。このようにして配布されるアクセスライブラリ３３０をＷＳやＰＣなどの一般的なコンピュータ装置に記憶させ、さらに、そのコンピュータ装置に検証対象のＳｏＣデバイスに応じたＳｏＣソフトウェアモデル、およびそのＳｏＣデバイスのハードウェアモデルシミュレーションの際に使用したテストプログラムをそのコンピュータ装置向けに再コンパイルしたものを記憶させることで、そのコンピュータ装置に上記ソフトウェアモデルシミュレーション端末と同一の機能を付与することが可能になる。
【００２８】
（２）上述した実施形態では、検証対象のＳｏＣデバイスが各種機能を実現する回路の他に１つの内蔵ＣＰＵを有していたが、複数の内蔵ＣＰＵを有するＳｏＣデバイスが検証対象であっても良い。このように検証対象のＳｏＣデバイスが複数の内蔵ＣＰＵを有している場合には、複数の内蔵ＣＰＵの各々によるメモリアクセス（レジスタアクセス）、およびメモリ（レジスタ）格納内容の更新待ちをＲＴＬ変換することが必要になる。
【００２９】
（３）上述した実施形態では、テストプログラム２１０ａ（テストプログラム３２０）のソースコードとＳｏＣソフトウェアモデル３１０のソースコードがともにＣ言語で記述されていたが、Ｃ＋＋やＦｏｒｔｒａｎなどの他のプログラミング言語で記述されていても良く、また、各々の記述言語が異なっていても良い。また、上述した実施形態では、ＳｏＣデバイスの検証作業に本発明を適用したが、他の種類の半導体集積回路の検証作業に本発明を適用しても良いことは言うまでもない。
【符号の説明】
【００３０】
１…デバイス検証システム、１０…論理シミュレータ、２０…ＦＰＧＡボード、３０…ＳｏＣソフトウェアモデルシミュレータ、１１０…論理回路モデル、１１０ａ…機能記述ＲＴＬ、１１０ｂ…内蔵ＣＰＵ記述ＲＴＬ、１２０…テストタスク、２１０…ホストＣＰＵ、２１０ａ…テストプログラム、２１０ｂ…アクセスライブラリ、２２０…ＦＰＧＡ群、２２０ａ…機能ブロック、２２０ｂ…内蔵ＣＰＵブロック、３１０…ＳｏＣソフトウェアモデル、３１０ａ…機能モデル、３１０ｂ…内蔵ＣＰＵモデル、３１０ｃ…ログ生成部、３２０…テストプログラム、３３０…アクセスライブラリ。
【図１】
2011145880.tif 000003
【図２】
2011145880.tif 000004