(57)【要約】【課題】協調検証時間を短縮する協調検証装置、協調検証方法、及びハードウェア・ソフトウェア協調検証プログラムを提供することにある。【解決手段】本発明による協調検証装置１０は、ハードウェアとソフトウェアとを協調させてシミュレーションを行なう演算装置１０１と、記憶装置１０３とを具備する。演算装置１０１は、ソフトウェア側からハードウェア側へ入力される指示信号２９の入力履歴３０を記憶装置１０３に記録する。【選択図】図３
2008282308.tif 000002
【特許請求の範囲】
【請求項１】
ハードウェアとソフトウェアとを協調させてシミュレーションを行なう演算装置と、
記憶装置と、
を具備し、
前記演算装置は、前記ソフトウェア側から前記ハードウェア側へ入力される指示信号の入力履歴を前記記憶装置に記録する
協調検証装置。
【請求項２】
請求項１に記載の協調検証装置において、
前記演算装置は、前記ハードウェア側に入力される前記指示信号と、前記指示信号が入力される端子のアドレスとを対応付けて、前記指示信号の入力順に前記記憶装置に記録する
協調検証装置。
【請求項３】
請求項１又は２に記載の協調検証装置において、
前記演算装置は、任意の時刻における前記ソフトウェアの実行結果を、途中状態情報として前記記憶装置に記録する
協調検証装置。
【請求項４】
請求項３に記載の協調検証装置において、
前記シミュレーションを所定の時刻から再開する際、
前記演算装置は、前記途中状態情報に基づいて、前記所定の時刻における前記ソフトウェアの実行結果を復元し、前記入力履歴に基づいて、前記シミュレーションの開始から前記所定の時刻の間に前記ハードウェア側に入力された指示信号を、前記ソフトウェア側から前記ハードウェア側に送出する
協調検証装置。
【請求項５】
（Ａ）演算装置がハードウェアとソフトウェアとを協調させてシミュレーションを行なうステップと、
（Ｂ）前記演算装置が、前記ソフトウェア側から前記ハードウェア側へ入力された指示信号の入力履歴を記憶装置に記録するステップと、
を具備する協調検証方法。
【請求項６】
請求項５に記載の協調検証方法において、
前記指示信号は、複数の端子のいずれかを介して、前記ハードウェア側に入力され、
前記（Ｂ）ステップは、前記演算装置が、前記ハードウェア側に入力される前記指示信号と、前記指示信号が入力される端子のアドレスとを対応付けて、前記指示信号の入力順に前記記憶装置に記録するステップとを備える
協調検証方法。
【請求項７】
請求項５又は６に記載の協調検証方法において、
前記演算装置が、任意の時刻における前記ソフトウェアの実行結果を途中状態情報として前記記憶装置に記録するステップを更に具備する協調検証方法。
【請求項８】
請求項７に記載の協調検証方法において、
前記シミュレーションを所定の時刻から再開する際、
前記演算装置が、前記途中状態情報に基づいて、前記所定の時刻における前記ソフトウェアの実行結果を復元するステップと、
前記ＣＰＵが、前記入力履歴に基づいて、前記シミュレーションの開始から前記所定の時刻の間に前記ハードウェア側に入力された指示信号を、前記ソフトウェア側から前記ハードウェア側に送出するステップと、
を具備する協調検証方法。
【請求項９】
請求項５から８いずれか１項に記載の協調検証方法をコンピュータに実行させる協調検証プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、回路設計においてソフトウェアとハードウェアの協調検証を行う協調検証装置、協調検証方法、及び協調検証プログラムに関する。
【背景技術】
【０００２】
近年、プロセッサ、メモリ、周辺回路等の複数の機能を１チップに搭載したＳｏＣ（Ｓｙｓｔｅｍ  ｏｎ  Ｃｈｉｐ）が広く利用されている。プロセッサが搭載されているＳｏＣ（例えばシステムＬＳＩ（Ｌａｒｇｅ  Ｓｃａｌｅ  Ｉｎｔｅｇｒａｔｉｏｎ））は、ソフトウェアとハードウェアとで構成されており、ソフトウェアとハードウェアが連携して動作する。このようなＳｏＣを設計する場合、従来では、ソフトウェア開発とハードウェア開発を分離して実施し、ハードウェアの完成後、それぞれを一体化してその動作を検証していた。このような方法では、ハードウェアの設計が完了するまでソフトウェアを検証することができない。又、検証において不具合が発見された場合、その原因を特定することが困難である。特に、ハードウェアの設計をやり直すような不具合が発見されると、開発コストや開発期間が大幅に増大してしまう。
【０００３】
このため、現在では、ハードウェアの完成前に、ハードウェアとソフトウェアとを協調させてシステムの動作を検証するハードウェア／ソフトウェア協調検証（以下、協調検証と称す）が広く利用されている。協調検証では、システム記述言語（例えばＶｅｒｉｌｏｇ−ＸＬ）を利用したＲＴＬ（Ｒｅｇｉｓｔｅｒ  Ｔｒａｎｓｆｅｒ  Ｌｅｖｅｌ）  記述によって生成されたハードウェアモデルと、Ｃ言語等で記述されたプログラム（ソフトウェアモデル）とを連携させて動作させ、システム全体の動作をシミュレーションし、両者の間に不整合がないかが検証される。これにより、システムを分割しないで設計を進めることができ、互いのモデルをテスト環境として利用しながらシステムの動作の検証が可能となる。
【０００４】
【特許文献１】特開平８−１８５３４１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
協調検証の対象となるシステムが大規模化又は複雑化すると、協調検証におけるシミュレーション時間や、シミュレーション上のＯＳ（Ｏｐｅｒａｔｉｏｎ  Ｓｙｓｔｅｍ）の起動時間は増大する。ソフトウェアのみの検証システムの場合、例えば特開平８−１８５３４１号公報に記載されているように、ソフトウェア側の内部状態（レジスタやメモリ内の状態）を保存／再実行することで、シミュレーションの途中状態を再現することができる（特許文献１参照）。このため、ソフトウェアのみの検証システムでは、検証済みのシミュレーションを省略したり、デバック箇所からシミュレーションを開始することができ、効率的な検証を行うことができる。
【０００６】
一方、協調検証のように、シミュレーション環境にハードウェアを組み込む場合、ハードウェア側の途中状態を保存するためには、ハードウェア内部の全てのレジスタの状態、及び信号の状態の途中状態を取り出すための回路を、ハードウェア側に新たに組み入れる必要がある。このような途中状態の保存機能をハードウェア側全体に対して追加するためには、大幅な回路変更が必要となり実現は難しい。このため、論理エミュレータやハードウェアアクセラレータを利用した協調検証では、シミュレーションの途中状態を保存／再実行することは難しく、シミュレーションを途中で中断した場合や、不具合が発生した場合には、シミュレーションを初めからやり直す必要がある。例えば、不具合箇所をデバックする場合、シミュレーションの開始から不具合発生に至るまでの間、デバックに関係のないＯＳの起動や、検証済みのシミュレーションに多くの時間を費やしてしまうため、検証効率が低下する。通常、協調検証方法では、多くの不具合箇所のそれぞれに対してデバックを繰り返す必要がある。このため、上述のように、シミュレーションの途中状態を保存／再実行できない場合、検証時間は大幅に増大する。
【０００７】
しかし、協調検証の検証時間を短縮する要求は高く、特にデバックに関係のないＯＳ起動時間や検証済みのシミュレーション時間を短縮し、効率的なデバック処理が可能な協調検証方法が強く要求されている。
【課題を解決するための手段】
【０００８】
以下に、［発明を実施するための最良の形態］で使用される番号・符号を括弧付きで用いて、［課題を解決するための手段］を説明する。この番号・符号は、［特許請求の範囲］の記載と［発明を実施するための最良の形態］の記載との対応関係を明らかにするために付加されたものであるが、［特許請求の範囲］に記載されている発明の技術的範囲の解釈に用いてはならない。
【０００９】
本発明による協調検証装置（１０）は、ハードウェアとソフトウェアとを協調させてシミュレーションを行なう演算装置（１０１）と、記憶装置（１０３）とを具備する。演算装置（１０１）は、ソフトウェア側からハードウェア側へ入力される指示信号（２９）の入力履歴（３０）を記憶装置（１０３）に記録する。協調検証を所定の時刻から再開する場合、協調検証装置（１０）は、ハードウェア側の指示信号（２９）の入力履歴（３０）を利用して所定の時刻におけるハードウェア側の状態を復元する。ソフトウェア側からハードウェア側への指示信号のみでハードウェア側の途中状態を復元するため、通常のシミュレーションよりも短時間で、所定の時刻におけるハードウェア側の状態を復元することができる。
【００１０】
又、演算装置（１０１）は、任意の時刻におけるソフトウェア（１）の実行結果を、途中状態情報（４０）として記憶装置（１０３）に記録することが好ましい。更に、シミュレーション（協調検証）を所定の時刻から再開する際、演算装置（１０１）は、途中状態情報（４０）に基づいて、所定の時刻におけるソフトウェア（１）の実行結果を復元することが好ましい。又、演算装置（１０１）は、入力履歴（３０）に基づいて、シミュレーション（協調検証）の開始から所定の時刻の間にハードウェア側に入力された指示信号（２９）を、ソフトウェア側からハードウェア側に送出する。これにより所定時刻におけるソフトウェア側及びハードウェア側の途中状態を復元できる。
【００１１】
本発明による協調検証方法は、演算装置（１０１）がハードウェアとソフトウェアとを協調させてシミュレーションを行なうステップと、演算装置（１０１）が、ソフトウェア側からハードウェア側へ入力された指示信号（２９）の入力履歴（３０）を記憶装置（１０３）に記録するステップとを具備する。
【００１２】
又、上述の方法は、コンピュータ（演算装置（１０１））によって実行される協調検証プログラムによって実現されることが好ましい。
【発明の効果】
【００１３】
本発明による協調検証装置、協調検証方法、及び協調検証プログラムによれば、協調検証時間を短縮できる。
【発明を実施するための最良の形態】
【００１４】
以下、添付図面を参照して、本発明による協調検証装置、協調検証方法、及び協調検証プログラムの実施の形態を説明する。本実施の形態では、Ｃ言語で作成されたターゲットプログラム１と、ＲＴＬ記述２に基づきＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）によって形成されたハードウェアとを検証対象とする協調検証装置１０を一例に説明する。
【００１５】
（概要）
本発明による協調検証装置１０は、ソフトウェアとハードウェアとが連携動作するシミュレーションにおいて、ソフトウェア側からハードウェア側に対する指示信号を履歴（入力履歴３０）として記録する。又、協調検証装置１０は、任意の時期のソフトウェア側の内部状態（例えば、ターゲットＣＰＵのレジスタの状態や、メモリの状態）を途中状態情報４０として記録する。協調検証装置１０は、協調検証を所定の時刻から再開する際、所定の時刻における途中状態情報４０に基づいて、所定の時刻におけるソフトウェア（ＣＰＵやメモリ）の内部状態を復元する。又、協調検証装置１０は、協調検証の開始から所定の時刻の間に記録された入力履歴３０に基づいて、所定の時刻におけるハードウェアの状態を復元する。この際、ＣＰＵは、入力履歴３０に記録された指示信号を、履歴の古い順にハードウェア側に対し送出して、ハードウェアの状態を復元する。これにより、シミュレーション開始からデバック対象箇所までに要する時間が短縮される。以下、本発明による協調検証装置、協調検証方法、及び協調検証プログラムの詳細を説明する。
【００１６】
（構成）
図１から図５を参照して本発明による協調検証装置１０の実施の形態における構成を説明する。図１は、協調検証装置１０の構成を示す図である。図１を参照して、本発明による協調検証装置１０は、バス１０６を介して相互に接続されるハードウェアエミュレータ１００と、ＣＰＵ１０１と、メモリ１０２と、記憶装置１０３と、入力装置１０４と、出力装置１０５とを具備する。記憶装置１０３はハードディスクやメモリ等に例示される記憶装置である。入力装置１０４は、キーボードやマウス等に例示され、ユーザ（設計者）によって操作されることで、各種データをＣＰＵ１０１や記憶装置１０３に出力する。出力装置１０５は、モニタやプリンタに例示され、ＣＰＵ１０１から出力される協調検証結果を、ユーザに対し視認可能に出力する。
【００１７】
ＣＰＵ１０１は、入力装置１０４からの入力に応答して、記憶装置１０３内の協調検証プログラム３５を実行し、協調検証処理を行う。この際、記憶装置１０３からの各種データやプログラムはメモリ１０２（例えばＲＡＭ）に一時格納され、ＣＰＵ１０１は、メモリ１０２内のデータを用いて各種処理を実行する。
【００１８】
記憶装置１０３は、ハードディスクやメモリ、光記憶媒体に例示され、入力履歴データベース３１（入力履歴Ｄ／Ｂ３１）、途中状態データベース３２（途中状態Ｄ／Ｂ３２）、ソフトウェアモデルデータベース３３（ソフトウェアモデルＤ／Ｂ３３）、ハードウェアモデルデータベース３４（ハードウェアモデルＤ／Ｂ３４）、協調検証プログラム３５を格納している。ソフトウェアモデルＤ／Ｂ３３及びハードウェアモデルＤ／Ｂ３４は、それぞれターゲットプログラム１及びＲＴＬ記述２を格納している。協調検証プログラム３５は、ソフトウェア及びハードウェアを用いて、ソフトウェアとハードウェアの協調検証のためのシミュレーションを実行する回路シミュレータである。
【００１９】
図２を参照して、協調検証プログラム３５は、ＣＰＵ１０１によって実行されることで、ソフトウェアシミュレータ３５１、ハードウェア復元部３５２、ソフトウェア復元部３５３、協調検証部３５４の各機能を実現する。ソフトウェアシミュレータ３５１は、例えばＣ言語で作成されたターゲットプログラム１を実行し、ソフトウェアのシミュレーションを行う。これにより、ＣＰＵ１０１は、検証対象のターゲットＣＰＵとして動作する。すなわち、ソフトウェアシミュレータ３５１は、検証対象のソフトウェアとして機能する。ハードウェア復元部３５２は、ハードウェアエミュレータ１００を監視し、ソフトウェア側からハードウェア側へ入力される指示信号２９を、入力順に入力履歴３０として入力履歴Ｄ／Ｂ３１に記録する。又、ハードウェア復元部３５２は、シミュレーションを再開する際、入力履歴Ｄ／Ｂ３１から取得した入力履歴３０に基づいて、指示信号２９を履歴の古いものから順にハードウェア側に出力し、ハードウェアの途中状態を復元する。ソフトウェア復元部３５３は、例えば特許文献１のように、任意の時刻、あるいはターゲットプログラム１における任意の地点におけるソフトウェアのシミュレーション状況（内部状態）を、途中状態情報４０として途中状態Ｄ／Ｂ３２に記録する。この際、ソフトウェア復元部３５３は、任意の時刻、あるいはターゲットプログラム１における任意の地点におけるメモリ１０２やレジスタ（図示なし）に格納された情報を取得し、途中状態情報４０として記録する。又、ソフトウェア復元部３５３は、シミュレーションを再開する際、途中状態情報４０に応じてメモリ１０２やレジスタを書き換え、シミュレーション途中のメモリ１０２やレジスタの状態を復元する。
【００２０】
ハードウェアエミュレータ１００は、ハードウェアモデルＤ／Ｂ３４に記録されたＲＴＬ記述２に基づいて、検証対象となるハードウェアモデルを実現する論理エミュレータである。図３を参照して、ハードウェアエミュレータ１００は、ＲＴＬ記述２に応じた論理回路を形成するＦＰＧＡを備える。ＦＰＧＡは、プログラムに応じて論理回路を構成できるため、デバック対象回路として好適に利用される。本実施の形態のＦＰＧＡは、一例としてＩＯ回路１１を構成する。Ｉ／Ｏ回路１１は端子群１２を介して、バス１０６に接続され、ＣＰＵ１０１やメモリ１０２との信号や情報の送受信する。ここでＩＯ回路１１は、ＣＰＵ１０１から入力データを演算（加算及び反転）してできるものとする。
【００２１】
協調検証部３５４は、ソフトウェアシミュレータ３５１とハードウェアエミュレータ１００のそれぞれから、シミュレーション結果を取得し、これらの結果に基づいて、ソフトウェアモデルとハードウェアモデルの設計の妥当性を検証する。又、協調検証部３５４は、検証結果を記憶装置１０３や出力装置１０５に出力する。
【００２２】
以上のような構成により、協調検証装置１０は、図３に示すようなシステムＬＳＩ（以下、ターゲットＬＳＩ２００と称す）に対し協調検証を行う。図３を参照して、ターゲットＬＳＩ２００は、ソフトウェアモデルとして機能するＣＰＵ１０１、メモリ１０２、及びアドレスデコーダ１３と、ハードウェアモデルとして機能するＩ／Ｏ回路１１（ＦＰＧＡ）とを具備する。Ｉ／Ｏ回路１１とＣＰＵ１０１及びメモリ１０２とはバス１０６を介して接続される。バス１０６は、アドレスバス１５、データバス１６、制御バス１７を備える。Ｉ／Ｏ回路１１と、バス１０６とは、端子群１２を介して接続される。
【００２３】
ハードウェア復元部３５２は、Ｉ／Ｏ回路１１とバス１０６との境界にある端子群１２を監視し、ＣＰＵ１０１からＩ／Ｏ回路１１に対して送出されるデータや信号を指示信号２９として取得する。Ｉ／Ｏ回路１１には、ソフトウェア側から、以下に示す指示信号が入力される。すなわち、初期化を指示するリセット信号２１（Ｒｅｓｅｔ）、システムクロック２２（ＣＬＫ）、データの送信先を指示するチップセレクト信号２３（ＣＳ）、データの読み出し又は書き込みを指示するリード／ライト信号２４（Ｒ／Ｗ）、アドレス指定信号２５（Ａ２３〜Ａ０）、データ２６（Ｄｏｕｔ３１〜Ｄｏｕｔ０）が入力される。又、Ｉ／Ｏ回路１１からソフトウェア側には、以下のような信号が出力される。すなわち、レディ信号２７（Ｒｅａｄｙ  ｏｕｔ）、アドレス指定信号２５、データ２８（Ｄｉｎ３１〜Ｄｉｎ０）が出力される。ただし、Ｉ／Ｏ回路１１に対し入出力する信号や情報は、これらに限らないのは言うまでもない。
【００２４】
Ｉ／Ｏ回路１１は、図４及び図５に示すようなアドレスマップを備えている。図４を参照して、Ｉ／Ｏ回路１１に入力される指示信号は、信号種別毎に信号線（端子）のアドレスに対応付けられる。例えば、アドレス０×０００のバスにおける０ビット目の信号線（端子）にはシステムクロック２２（ＣＬＫ）が対応付けられ、４ビット目にはリセット信号２１（Ｒｅｓｅｔ）が対応付けられる。又、アドレス０×００４のバスにおける０ビット目の信号線（端子）にはリード／ライト信号２４（Ｒ／Ｗ）が対応付けられ、４ビット目にはチップセレクト信号２３（ＣＳ）が対応付けられる。更に、アドレス０×００８のバスにおける０ビット目から２３ビット目のそれぞれの信号線（端子）にはアドレス指定信号２５（Ａ０〜Ａ２３）が対応付けられる。更に、アドレス０×００Ｃのバスにおける０ビット目から３１ビット目のそれぞれの信号線（端子）にはデータ２６（Ｄｏｕｔ０〜Ｄｏｕｔ３１）が対応付けられる。図５を参照して、Ｉ／Ｏ回路１１から出力される指示信号は、信号種別毎に信号線（端子）のアドレスに対応付けられる。例えば、アドレス０×１００のバスにおける０ビット目の信号線（端子）にはレディ信号２７（Ｒｅａｄｙ  ｏｕｔ）が対応付けられる。又、アドレス０×００８のバスにおける０ビット目から３１ビット目のそれぞれの信号線（端子）にはデータ２６（Ｄｉｎ０〜Ｄｉｎ３１）が対応付けられる。
【００２５】
次に、本発明による協調検証動作における入力履歴の記録動作の詳細を説明する。
【００２６】
本発明による協調検証装置１０は、協調検証の際、ソフトウェア側からハードウェア側への入力信号を入力履歴として保存する。図６及び図７を参照して、協調検証時における入力履歴の記録動作を説明する。図７を参照して、協調検証装置１０が、ターゲットＬＳＩ２００の検証を開始すると、ハードウェア復元部３５２は、端子群１２の監視を開始する（ステップＳ１）。ここでハードウェア復元部３５２は、端子群１２内において、ソフトウェア側からＩ／Ｏ回路１１への入力信号が通過する端子、すなわち、図４に示されるアドレス０×０００、０×００４、０×００８、０×００Ｃ、・・・に対応するバスを監視する。ソフトウェア側からハードウェア側（Ｉ／Ｏ回路１１）へ指示信号２９が送出された場合（ステップＳ２ＹＥＳ）、ハードウェア復元部３５２は、指示信号２９を、入力された端子のアドレスに対応付けて入力履歴Ｄ／Ｂ３１に記録する（ステップＳ３）。詳細には、端子群１２を監視するハードウェア復元部３５２は、信号レベルが変化した端子から指示信号２９を抽出し、入力履歴Ｄ／Ｂ３１に記録する。一方、ソフトウェア復元部３５３は、協調検証開始から任意の時刻までのソフトウェアのシミュレーション結果を途中状態情報４０として保存する。途中状態情報４０が記録されると（ステップＳ４Ｙｅｓ）、ハードウェア復元部３５２は、途中状態情報４０が記録された時刻までに入力履歴Ｄ／Ｂ３１に記録された入力履歴３０と途中状態情報４０とを対応付ける（ステップＳ５）。途中状態情報４０が記録されない場合（ステップＳ４Ｎｏ）、又はステップＳ５の処理後において、シミュレーション（協調検証）が継続中の場合、ハードウェア復元部３５２は端子群１２の監視（入力履歴３０の記録）を続行する（ステップＳ６Ｎｏ）。又、シミュレーション（協調検証）が終了すると、端子群１２の監視（入力履歴３０の記録）を終了する（ステップＳ６Ｙｅｓ）。すなわち、ハードウェア復元部３５２は、途中状態情報４０の記録の有無に関わらずシミュレーション（協調検証）が終了するまで指示信号２９の記録（入力履歴３０の記録）を繰り返す。以上のように、ハードウェア復元部３５２は、協調検証の開始から終了までの間、ソフトウェア側からハードウェア側へ送出された指示信号２９の履歴（入力履歴３０）を記録する。又、ソフトウェア側のシミュレーション結果（途中状態情報４０）が記録された時刻までに記録された入力履歴３０と当該途中状態情報４０とを対応付けることができる。
【００２７】
図６は、ハードウェア復元部３５２によって記録された入力履歴３０の一例を示す図である。ここでは、協調検証において、ＣＰＵ１０１がターゲットプログラム１を実行して以下の処理を行う場合を一例に説明する。すなわち、ＣＰＵ１０１は、（１）メモリ１０２内の２個のデータを読み出し、（２）読み出した２個のデータをＩ／Ｏ回路１１に書き込み、（３）Ｉ／Ｏ回路１１に対し、加工処理（ここでは２つのデータを加算して反転）の実行指示を発行し、（４）Ｉ／Ｏ回路１１から加工処理の結果データを読み出し、（５）結果データをメモリに保存する。
【００２８】
ハードウェア復元部３５２は、信号レベルの変化した信号線から指示信号２９を順次抽出し、当該信号線のアドレスと対応付けて入力履歴３０として記録する。当初、ＣＰＵ１０１は、Ｉ／Ｏ回路１１を初期化する。ハードウェア復元部３５２は、繰り返し入力される指示信号２９：０×１０、０×１１をアドレス：０×０００に対応付けて順次記録する。次にＣＰＵ１０１は、リセットを解除する。この際、ＣＰＵ１０１からＩ／Ｏ回路１１に入力されるＲｅｓｅｔ２１は、ハイレベル“１”からローレベル“０”に変化する。ハードウェア復元部３５２は、指示信号２９：０×０１を抽出し、アドレス：０Ｘ０００に対応付けて記録する。続いて、ＣＬＫ２２の信号レベルの変化に応じて、指示信号２９：０×００又は０×０１を抽出し、アドレス：０Ｘ０００に対応付けて記録する。
【００２９】
次に、ＣＰＵ１０１は、メモリ１０２内のデータＡ（０×３３３３）を読み出し、Ｉ／Ｏ回路１１におけるワーク用レジスタ（０×２０００）に書き込む。この際、Ｉ／Ｏ回路１１には、指示信号２９としてアドレス信号２５（０×２０００）、データ２６（０×３３３３）、ＣＳ２３及びライト信号２４が順に入力される。ハードウェア復元部３５２は、Ｉ／Ｏ回路１１への入力順に、指示信号２９：０×２０００とアドレス０×００８を対応付けて記録し、指示信号２９：０×３３３３とアドレス０×００Ｃを対応付けて記録し、指示信号２９：０×１０とアドレス：０×００４を対応付けて記録する。Ｉ／Ｏ回路１１は、ワーク用レジスタ（０×２０００）にデータＡを書き込むと、ＣＰＵ１０１に対しレディ信号２７を送出する。
【００３０】
レディ信号２７を受け取ったＣＰＵ１０１は、メモリ１０２内のデータＢ（０×４４４４）を読み出し、Ｉ／Ｏ回路１１におけるワーク用レジスタ（０×２００４）に書き込む。この際、Ｉ／Ｏ回路１１には、指示信号２９としてアドレス信号２５（０×２００４）、データ２６（０×４４４４）、ＣＳ２３及びライト信号２４が順に入力される。ハードウェア復元部３５２は、Ｉ／Ｏ回路１１への入力順に、指示信号２９：０×２００４とアドレス０×００８を対応付けて記録し、指示信号２９：０×４４４４とアドレス０×００Ｃとを対応付けて記録し、指示信号２９：０×１０とアドレス：０×００４を対応付けて記録する。Ｉ／Ｏ回路１１は、ワーク用レジスタ（０×２００４）にデータＢを書き込むと、ＣＰＵ１０１に対しレディ信号２７を送出する。
【００３１】
レディ信号２７を受け取ったＣＰＵ１０１は、Ｉ／Ｏ回路１１内の制御レジスタ（０×２１００）に、データＡとデータＢを加算及び反転するための指示情報（０×ＦＦＦＦ）を書き込む。この際、Ｉ／Ｏ回路１１には、指示信号２９としてアドレス信号２５（０×２１００）、データ２６（０×ＦＦＦＦ）、ＣＳ２３及びライト信号２４が順に入力される。ハードウェア復元部３５２は、Ｉ／Ｏ回路１１への入力順に、指示信号２９：０×２１００とアドレス０×００８を対応付けて記録し、指示信号２９：０×ＦＦＦＦとアドレス０×００Ｃとを対応付けて記録し、指示信号２９：０×１０とアドレス：０×００４を対応付けて記録する。
【００３２】
Ｉ／Ｏ回路１１は、制御用レジスタ内の指示情報（０×ＦＦＦＦ）に基づき、データＡ（０×３３３３）とデータＢ（０×４４４４）とを加算して反転し、結果データ（０×８８８８）を結果レジスタ（０×２２００）に格納する。Ｉ／Ｏ回路１１は、演算が終了し、結果データを格納するとレディ信号２７をＣＰＵ１０１に対し送出する。レディ信号２７を受け取ったＣＰＵ１０１は、Ｉ／Ｏ回路１１内の結果レジスタ（０×２２００）から結果データ（０×８８８８）を読み出し、メモリ１０２に格納する。この際、Ｉ／Ｏ回路１１には、ＣＰＵ１０１からの指示信号２９としてアドレス信号２５（０×２２００）、データ２６（０×ＦＦＦＦ）、ＣＳ２３及びリード信号２４が順に入力される。ハードウェア復元部３５２は、入力履歴３０として、Ｉ／Ｏ回路１１への入力順に、指示信号２９：０×２１００とアドレス０×００８を対応付けて記録し、指示信号２９：０×ＦＦＦＦとアドレス０×００Ｃとを対応付けて記録し、指示信号２９：０×１１とアドレス：０×００４を対応付けて記録する。Ｉ／Ｏ回路１１は、結果レジスタ内のデータ２８（０×ＦＦＦＦ）をＣＰＵ１０１に対し送出する。
【００３３】
以上のような入力履歴３０の記録は、協調検証の開始から協調検証の終了又は中断されるまで行われる。
【００３４】
一方、ソフトウェア復元部３５３は、時刻Ａ（任意の時刻又は、ターゲットプログラムにおける任意の箇所）におけるシミュレーション結果を途中状態情報４０として保存する。例えば、ソフトウェア復元部３５３は、協調検証において不具合が発生した箇所（デバック対象箇所）の手前の時刻や、シミュレーション上のＯＳが終了した時点の途中状態情報４０を途中状態Ｄ／Ｂ３２に記録する。この際、ハードウェア復元部３５２は、時刻Ａまでに記録された入力履歴３０と、時刻Ａに記録された途中状態情報４０とを対応付ける（ステップＳ５）。例えば、データＡとデータＢを加算・反転したデータをメモリ１０２に格納する時点で途中状態情報４０が記録された場合、ハードウェア復元部３５２は、当該途中状態情報４０と、図６に示す入力履歴３０とを対応付ける。
【００３５】
以上のように、本発明によれば、任意の時刻におけるソフトウェアのシミュレーション結果（途中状態情報４０）と、ハードウェア側への指示信号２９の履歴（入力履歴３０）とを対応付けて記録することができる。
【００３６】
次に、本発明による協調検証装置１０において、シミュレーションの途中（時刻Ａ）から再実行する方法について説明する。協調検証装置１０は、時刻Ａからシミュレーションを再実行する際、ソフトウェア復元部３５３によって、時刻Ａにおけるソフトウェア側の内部状態を復元し、ハードウェア復元部３５２によって、時刻Ａにおけるハードウェア側の内部状態を復元する。
【００３７】
ソフトウェア復元部３５３は、時刻Ａに記録した途中状態情報４０を用いてメモリ１０２やＣＰＵ１０１内のレジスタの状態を復元する。ハードウェア復元部３５２は、協調検証の開始から時刻Ａまでに記録した入力履歴３０を参照し、指示信号２９を履歴順（Ｉ／Ｏ回路１１への入力が古い順）にＩ／Ｏ回路１１に対し送出する。例えば、時刻Ａまでに図６に示すような入力履歴３０が記録されている場合、ハードウェア復元部３５２は、リセット解除から結果データのリードまでの指示情報２９を順にＩ／Ｏ回路１１に送出する。これにより、Ｉ／Ｏ回路１１は、時刻ＡまでにＣＰＵ１０１から指示されて実行した処理を再実行し、時刻Ａにおけるシミュレーションの実行結果を復元することができる。本発明では、ハードウェア側（Ｉ／Ｏ回路１１）からソフトウェア側に送出した信号やデータ（例えばレディ信号２７やデータ２８）は省略されているため、ハードウェアの途中状態の復元に要する時間は大幅に短縮される。
【００３８】
以上のように、本発明によれば、ソフトウェア側からハードウェア側への指示信号を用いて、協調検証におけるハードウェア側の途中状態を復元するため、途中状態までのシミュレーション時間を短縮することができる。これにより、デバック箇所までのシミュレーション時間や、シミュレーション上のＯＳの起動時間を短縮することができ、効率のよい協調検証が可能となる。
【００３９】
以上、本発明の実施の形態を詳述してきたが、具体的な構成は上記実施の形態に限られるものではなく、本発明の要旨を逸脱しない範囲の変更があっても本発明に含まれる。実施の形態におけるハードウェア復元部３５２は、ＣＰＵ１０１によって実行されるプログラムによって実現されるが、これに限らず、端子群１２を監視する別装置によって実現しても良い。又、ハードウェア復元部３５２によって指示信号２９を取得するタイミングは、システムクロック２２に応じたタイミングでも別のサンプリングクロック（図示なし）に応じたタイミングでもどちらでも良い。尚、別のサンプリングクロックに応じて指示信号２９を取得する場合、入力履歴３０としてシステムクロック２２を記録する必要はない。更に、ターゲットプログラム１はＣ言語によるプログラムに限定されない。又、ハードウェアモデルとして利用されるハードウェアエミュレータ１００に書き込まれるハードウェア記述は、ＲＴＬ記述に限定されない。
【図面の簡単な説明】
【００４０】
【図１】図１は、本発明による協調検証装置の構成を示す構成図である。
【図２】図２は、本発明による協調検証装置の実施の形態における構成を示すブロック図である。
【図３】図３は、本発明によるターゲットＬＳＩの実施の形態における構成を示すブロック図である。
【図４】図４は、本発明に係るＩ／Ｏ回路への入力側のアドレスマップの構成の一例を示す図である。
【図５】図５は、本発明に係るＩ／Ｏ回路からの出力側のアドレスマップの構成の一例を示す図である。
【図６】図６は、本発明による入力履歴３０の一例を示す図である。
【図７】図７は、本発明による協調検証時の入力履歴の記録動作を示すフロー図である。
【符号の説明】
【００４１】
１０：協調検証装置
１００：ハードウェアエミュレータ
１０１：ＣＰＵ
１０２：メモリ
１０３：記憶装置
１０４：入力装置
１０５：出力装置
１０６：バス
３１：入力履歴Ｄ／Ｂ
３２：途中状態Ｄ／Ｂ
３３：ソフトウェアモデルＤ／Ｂ
３４：ハードウェアモデルＤ／Ｂ
３５：協調検証プログラム
３５１：ソフトウェアシミュレータ
３５２：ハードウェア復元部
３５３：ソフトウェア復元部
３５４：協調検証部
２９：指示信号
３０：入力履歴
４０：途中状態情報
【図１】
2008282308.tif 000003
【図２】
2008282308.tif 000004
【図３】
2008282308.tif 000005
【図４】
2008282308.tif 000006
【図５】
2008282308.tif 000007
【図６】
2008282308.tif 000008
【図７】
2008282308.tif 000009