JP5239862B2 - デバッガ及びデバッグ方法 - Google Patents

Description

本発明はマイクロプロセッサ・コアとコプロセッサやハードウェア・アクセラレータ等の所定の機能を実現する付加ハードウェアとが混載されたＳｏＣ（System on Chip：システム・オン・チップ）デバイスをデバッグするためのデバッガ及びデバッグ方法に関する。

近年、半導体プロセス技術が進歩した結果、半導体チップ上に多数のトランジスタを集積できるようになり、システム全体を１チップ内に納める、いわゆるＳｏＣと呼ばれるＬＳＩデバイスが実現できるようになった。

ＳｏＣデバイスには、高い性能を実現すると共に、新しい仕様や要求に対応する柔軟性も求められる。そこで、ＳｏＣデバイスでは、汎用マイクロプロセッサ・コア（以下、単にプロセッサ・コアと称す）をベースに備え、コプロセッサやハードウェア・アクセラレータ（以下、単にアクセラレータと称す）の追加及びマルチコア化等によって高性能化を図ると共に、プロセッサ・コアに格納されたソフトウェア（ユーザ・プログラム）によりコプロセッサやアクセラレータを制御することで柔軟性を実現するアーキテクチャが一般的に採用されている。

例えば、非特許文献１（Ricardo E. Gonzalez, "Xtensa: A Configurable and Extensible Processor," IEEE MICRO Magazine, Volume 20, Issue 2, March-April 2000, pp. 60〜70.）、非特許文献２（Steve Leibson/James Kim, "Configurable Processors: A New Era in Chip Design," IEEE Computer Magazine, Volume 38, Issue 7, July 2005, pp. 51〜59.）及び特許文献１（特開２００４−２８８２０３号公報）には、コプロセッサやアクセラレータを付加することでＳｏＣデバイスとしての機能拡張を認めるプロセッサ・コアが例示されている。

このようなＳｏＣデバイスをデバッグする場合、プロセッサ・コアを動作させるためのソフトウェア（ユーザ・プログラム）と、所定の機能を実現するコプロセッサやアクセラレータ等の付加ハードウェアとを同時にデバッグしなければならない。ソフトウェア（ユーザ・プログラム）のデバッグに用いるツールとしてはＩＣＥ（In-Circuit Emulator）が知られている。また、ハードウェアのデバッグに用いるツールとしてはロジック・アナライザが知られている。

ＩＣＥは、ＳｏＣデバイスに搭載されたプロセッサ・コアをプログラミング・モデル・レベルで抽象化したデバッグ環境を提供する。具体的には、非特許文献３（山本繁寿/有末一寿、「組み込み機器とデバッグ環境」、インターフェース、２００２年３月号、４９〜５３頁、ＣＱ出版社）に記載されているように、プロセッサ・コアが備える内部レジスタの読み書き、システム・メモリの読み書き、実行制御（指定アドレスからの実行開始やブレーク・ポイントによる停止）等の機能を提供する。なお、ＩＣＥではハードウェアレベルの情報はユーザから隠蔽されている。

典型的なＩＣＥの構成について図１を用いて説明する。

図１はユーザ・プログラムのデバッガとして用いられる従来のＩＣＥの構成を示すブロック図である。

図１に示すように、ＩＣＥ部６はプロセッサ・コア２の実行制御を実現するためにブレーク検出回路７を備えている。ブレーク検出回路７は、プロセッサ・コア２のプログラム・カウンタの値や実行している命令語等、プロセッサ・コア２の状態（以下、単にプロセッサ状態と称す）を監視する。そして、プロセッサ状態が予め設定したブレーク条件と一致したとき、すなわち、プログラム・カウンタの値が予め設定した値に到達した場合や周知のトラップ命令が実行された場合にブレーク信号を出力することで（以下、ブレーク信号を発生することを「ソフトウェア的イベント」と呼ぶ）、プロセッサ・コア２をユーザ・プログラムの実行状態から該ユーザ・プログラムのデバッグが可能な状態（デバッグ状態）に遷移させる。なお、トラップ命令は、ソフトウェア割り込み命令、デバッグ命令、ブレーク命令等と呼ばれることもある。

ＩＣＥ ＵＩ（User Interface）８は、ユーザからの指示にしたがってブレーク検出回路７にブレーク信号を出力させるためのブレーク条件を設定する。また、ＩＣＥ ＵＩ８は、ユーザからの指示にしたがってデバッグ状態にあるプロセッサ・コア２の内部レジスタの読み書きを実行する。このとき、ＩＣＥ部６は、デバッグ状態に遷移したプロセッサ・コア２の内部レジスタあるいはシステム・メモリの読み書きを行うためのソフトウェアにしたがって処理を実行することで、ユーザによるユーザ・プログラムのデバッグを支援する。

例えば、非特許文献４（"ARM1156T2F-S Technical Reference Manual, Revision: r0p0," ARM Limited, 2005, インターネット＜URL: http://www.arm.com/pdfs/DDI0290C_arm1156t2fs_r0p0_trm.pdf＞）の１３−４０頁には、組込み用のプロセッサ・コアとして知られる英国ＡＲＭ社のプロセッサにおいて、「デバッグ例外（Debug exception）」と呼ばれる割り込み信号が発生すると、「モニタ・ターゲット（Monitor target）」と呼ばれるソフトウェアによる制御へ移行することでＩＣＥ部としての機能を実現することが記載されている。

ロジック・アナライザは、例えば非特許文献５（荒井信隆、「ロジック・アナライザの動作原理」,トランジスタ技術、２００３年７月号、１２８〜１３４頁、ＣＱ出版社）に記載されているように、ユーザによって指定された所定の信号（観測信号）の時間変化（波形）を監視・記録する装置である。典型的なロジック・アナライザの構成について図２を用いて説明する。

図２は従来のハードウェアのデバッガとして用いられるロジック・アナライザの構成を示すブロック図である。

図２に示すように、ロジック・アナライザ部２０は、トリガ検出回路１２、トレース・メモリ１３及びロジック・アナライザＵＩ１４を有する構成である。

トリガ検出回路１２は、ユーザによって設定されたトリガ条件と所定の入力信号とを比較し、それらが一致した場合にトリガ信号を生成する（以下、このトリガ信号の発生を「ハードウェア的イベント」と呼ぶ）。

トレース・メモリ１３には、付加ハードウェア３から出力される観測信号のうち、トリガ信号の発生前後の観測信号が、ほぼそのまま格納される。但し、トレース・メモリ１３へ格納する観測信号に対しては、予め設定されたしきい値電圧との比較結果に応じて波形整形を実施したり、所定のサンプリング・クロックに同期化させる等の最低限の処理を実施することもある。

ロジック・アナライザＵＩ（User Interface）１４は、ユーザからの指示にしたがってトリガ検出回路１２にトリガ信号を生成させるためのトリガ条件を設定する。また、ロジック・アナライザＵＩ１４はトレース・メモリ１３に格納された信号を表示する。

ＳｏＣデバイス１に搭載されたプロセッサ・コア２上で動作するソフトウェア（ユーザ・プログラム）と付加ハードウェア３とを既存のＩＣＥ及びロジック・アナライザを用いてデバッグする様子を図３に示す。図３ではＳｏＣデバイス１に搭載されたプロセッサ・コア２からＩＣＥ部６によりプロセッサ状態が読み出され、コプロセッサ４やアクセラレータ５等の付加ハードウェア３からロジック・アナライザ部２０により観測対象の信号（観測信号）がモニタされる様子を示している。

このようなＩＣＥ部６とロジック・アナライザ部２０とを用いた同時デバッグでは、ＩＣＥ部６及びロジック・アナライザ部２０が独立した装置であるため、それらの連携が不充分であり、ＩＣＥ部６とロジック・アナライザ部２０の動作を統合した効率のよいデバッグが困難であるという問題がある。

ＩＣＥ部６とロジック・アナライザ部２０とを連携して用いる例として、例えば非特許文献６（「ロジック・アナライザとＩＣＥの連携によるデバッグ」、インターフェース、２０００年１０月号、１０８頁、ＣＱ出版社）に記載された技術が知られている。非特許文献６には、ＩＣＥから出力された、コプロセッサをブレークさせるための信号をロジック・アナライザのトリガ信号として使用し、ＩＣＥで保存している実行履歴（非特許文献６中では「WATCHPOINTのヒストリウィンドウ」）に対応する時刻を観測信号の信号波形と共にロジック・アナライザで表示する例が記載されている。

上述したように従来のデバッガでは、ユーザ・プログラムのデバッグに用いるＩＣＥとハードウェアのデバッグに用いるロジック・アナライザとが独立した装置であり、それらの装置の連携が不充分であるため、それらの動作を統合した効率のよいデバッグが困難であるという問題がある。

また、上記非特許文献６では、ソフトウェア的イベントをロジック・アナライザのトリガ信号として用いる例が記載されているが、ハードウェア的イベントをＩＣＥ部のブレーク信号として用いるための方法については何ら示していない。そのため、付加ハードウェアの内部信号や外部信号が特定の状態になったときにプロセッサ・コアをデバッグ状態に遷移させてシステム全体の動作を停止させたい場合でも、そのような処理が実行できないという問題がある。

このように、現状のＩＣＥとロジック・アナライザとは連携が不十分であるため、ハードウェアとソフトウェア（ユーザ・プログラム）とが協調して動作するＳｏＣデバイスのデバッグが困難であるという問題があった。

そこで、本発明は、マイクロプロセッサ・コアと所定の機能を実現する付加ハードウェアとが混載されたＳｏＣデバイスを効率よくデバッグできるデバッガ及びデバッグ方法を提供することを目的とする。

上記目的を達成するため本発明では、マイクロプロセッサ・コアの状態が予め設定されたブレーク条件と一致するとき、ソフトウェア的イベントの発生を示すブレーク要求信号を生成し、付加ハードウェアの所定の信号が予め設定されたトリガ条件と一致するとき、ハードウェア的イベントの発生を示すトリガ要求信号を生成する。そして、ブレーク要求信号が発生したとき、システム・オン・チップ・デバイスに対して所定の信号をロジック・アナライザにより観測するためのトリガ信号を出力し、マイクロプロセッサ・コア及び付加ハードウェアに対する、マイクロプロセッサ・コア及び付加ハードウェアを通常動作させるためのクロックの供給を停止する。
また、マイクロプロセッサ・コア及び付加ハードウェアに対するクロックの供給を停止しているとき、マイクロプロセッサ・コアに対するデバッグ状態への遷移指示を受け取ると、トリガ信号の出力を停止し、システム・オン・チップ・デバイスに対して、マイクロプロセッサ・コアをデバッグ状態に遷移させるためのブレーク信号を出力すると共に、マイクロプロセッサ・コア及び付加ハードウェアに対するクロックの供給を再開する。

図１はユーザ・プログラムのデバッガとして用いられる従来のＩＣＥの構成を示すブロック図である。 図２は従来のハードウェアのデバッガとして用いられるロジック・アナライザの構成を示すブロック図である。 図３は図１に示したＩＣＥ部と図２に示したロジック・アナライザ部とを用いてＳｏＣデバイスをデバッグしている様子を示すブロック図である。 図４は本発明のデバッガの一構成例を示すブロック図である。 図５Ａは、本発明のデバッグ方法の第１の実施の形態の処理を示すフロー・チャートである。 図５Ｂは、本発明のデバッグ方法の第１の実施の形態の処理を示すタイミング・チャートである。 図６Ａは本発明のデバッグ方法の第２の実施の形態の処理を示すフロー・チャートである。 図６Ｂは本発明のデバッグ方法の第２の実施の形態の処理を示すタイミング・チャートである。 図７Ａは本発明のデバッグ方法の第３の実施の形態の処理を示すフロー・チャートである。 図７Ｂは本発明のデバッグ方法の第３の実施の形態の処理を示すタイミング・チャートである。 図８は図４に示したＳｏＣデバイスの動作状態を示す状態遷移図である。

次に本発明について図面を参照して説明する。

（第１の実施の形態）
図４は本発明のデバッガの一構成例を示すブロック図である。

本発明のデバッガ１２１は、プロセッサ・コア１０２と付加ハードウェア１０３とが混載されたＳｏＣデバイス１０１をデバッグするための装置である。付加ハードウェア１０３は、コプロセッサ１０４やアクセラレータ１０５等のようにプロセッサ・コア１０２と協調して動作するハードウェア回路の総称である。付加ハードウェア１０３は、プロセッサ・コア１０２と協調して動作すればよく、プロセッサ・コア１０２と同一の半導体チップに搭載されている必要はない。また、プロセッサ・コア１０２が同一のプリント基板に搭載された他の装置または同一のシステム内の他の装置と協調して動作するとき、それらの装置もデバッガ１２１によるデバッグ対象に含むことができる。

図４に示すように、本発明のデバッガ１２１は、ＩＣＥ部１０６、ロジック・アナライザ部１２０及び実行制御回路１１８を備えている。

ＳｏＣデバイス１０１が備えるプロセッサ・コア１０２には、デバッガ１２１が備えるＩＣＥ部１０６が接続され、付加ハードウェア１０３にはロジック・アナライザ部１２０が接続される。

ＩＣＥ部１０６は、ブレーク検出回路１０７及びＩＣＥ ＵＩ（ＩＣＥユーザ・インターフェース）１０８を備えている。また、ロジック・アナライザ部１１０は、トリガ検出回路１１２、トレース・メモリ１１３及びロジック・アナライザＵＩ１１４を備えている。

ブレーク検出回路１０７は、プロセッサ・コア１０２のプロセッサ状態を監視し、プロセッサ状態が予め設定された条件と一致したとき、上記ソフトウェア的イベントが発生したとみなしてプロセッサ・コア１０２に対するデバッグ状態への遷移を要求するブレーク要求信号を生成する。ブレーク要求信号の生成条件に用いるプロセッサ状態１０９としては、プログラム・カウンタの値、実行対象の命令語、ロード・ストア対象のアドレス及びデータ値等がある。但し、これら以外にもユーザがプロセッサ・コア１０２のプログラミング・モデルとして参照する信号や内部処理のために生成する信号（ユーザに対して隠蔽される信号であってもよい）等もブレーク要求信号の生成条件に用いるプロセッサ状態としてもよい。なお、ブレーク検出回路１０７は任意の数のブレーク条件を監視できるものとする。ブレーク条件が複数あるとき、ブレーク検出回路１０７で生成するブレーク要求信号は、複数のブレーク条件を統合することで単一の信号線を用いて出力してもよく、各ブレーク条件に対応して設けた信号線を用いて複数のブレーク要求信号を出力してもよい。また、ブレーク検出回路１０７は、複数のブレーク条件を符号化したブレーク要求信号を出力してもよい。

ＩＣＥ ＵＩ（User Interface）１０８は、ユーザからの指示にしたがってブレーク検出回路１０７にブレーク要求信号を出力させるためのブレーク条件を設定する。また、ＩＣＥ
ＵＩ１０８は、ユーザからの指示にしたがってデバッグ状態にあるプロセッサ・コア２の内部レジスタの読み書きを実行する。

付加ハードウェア１０３からの観測信号はトリガ検出回路１１２及びトレース・メモリ１１３に供給される。

トリガ検出回路１１２は、付加ハードウェア１０３と接続された少なくとも１つの観測信号を監視し、観測信号が予め設定された条件と一致したとき、ハードウェア的イベントが発生したとみなして該観測信号の観測を要求するトリガ要求信号を生成する。

トレース・メモリ１１３には、図２に示した従来のロジック・アナライザ部１２０と同様に、トリガ要求信号の発生前後の観測信号が、ほぼそのまま格納される。

ロジック・アナライザＵＩ（User Interface）１１４は、ユーザからの指示にしたがってトリガ検出回路１１２にトリガ要求信号を出力させるためのトリガ条件を設定する。また、ロジック・アナライザＵＩ１１４はトレース・メモリ１１３に格納された信号を表示する。

なお、ＳｏＣデバイス１０１からトリガ検出回路１１２及びトレース・メモリ１１３には、全ての観測信号が送信される必要はなく、トリガ検出回路１１２だけに送信される観測信号があってもよく、トレース・メモリ１１３だけに送信される観測信号があってもよい。

実行制御回路１１８は、ソフトウェア的イベントの発生を示すブレーク要求信号及びハードウェア的イベントの発生を示すトリガ要求信号からプロセッサ・コア１０２をデバッグ状態に遷移させるためのブレーク信号及び観測信号をロジック・アナライザ部１２０により観測するためのトリガ信号を生成する。実行制御回路１１８は、ブレーク要求信号とトリガ要求信号の論理和結果をブレーク信号及びトリガ信号として出力する場合に最も単純な構成となる。なお、ブレーク検出回路１０７、トリガ検出回路１１２、及び実行制御回路１１８には、ブレーク要求信号やトリガ要求信号をブレーク条件やトリガ条件に応じてマスクする機能を備えていてもよい。

次に本実施形態のデバッグ方法について図５Ａ、Ｂを用いて説明する。

図５Ａは、本発明のデバッグ方法の第１の実施の形態の処理を示すフロー・チャートであり、図５Ｂは、本発明のデバッグ方法の第１の実施の形態の処理を示すタイミング・チャートである。なお、図５Ａに示すフロー・チャートは、第１の実施の形態の実行制御回路１１８の処理手順を示し、図５Ｂは実行制御回路１１８の入出力信号のタイミング・チャートの例を示している。

図５Ａに示すように、実行制御回路１１８は、トリガ検出回路１１２によるトリガ要求信号の発生有無を監視し（ステップ２００）、トリガ要求信号が発生すると、トリガ信号及びブレーク信号を生成する（ステップ２０１）。

図５Ｂに示すように、時刻ｔ０においてトリガ検出回路１１２にてトリガ要求信号が発生すると、実行制御回路１１８は、トレース・メモリ１１３にトリガ信号を送信すると同時にプロセッサ・コア１０２にブレーク信号を送信する。

なお、図５Ａ、Ｂでは、トリガ要求信号が発生した場合に、実行制御回路１１８でプロセッサ・コア１０２の動作を停止するためのブレーク信号及び観測信号を保存するためのトリガ信号を生成する例を示しているが、実行制御回路１１８は、ブレーク要求信号が発生した場合も、同様にブレーク信号及びトリガ信号をそれぞれ生成する。

第１の実施の形態のデバッグ方法では、トリガ検出回路１１２により付加ハードウェア１０３の内部信号や外部信号（観測信号）を監視し、それらの観測信号が予め設定された条件と一致したときも、実行制御回路１１８によりブレーク信号を生成してプロセッサ・コア１０２に出力する。

このとき、ＳｏＣデバイス１０２のプロセッサ・コア１０２は、ブレーク信号によってユーザ・プログラムによる動作を停止してデバッグ状態に遷移するため、ユーザは、ＩＣＥ部１０６を用いてプロセッサ・コア１０２に備えるプログラム・カウンタ、汎用レジスタあるいはメモリの内容を読み書きすることができる。

したがって、本実施形態によれば、ＩＣＥ部１０６でソフトウェア的イベントが発生した場合、及びロジック・アナライザ部１２０でハードウェア的イベントが発生した場合のどちらでもＩＣＥ部１０６をデバッグ状態に遷移させることが可能であり、かつロジック・アナライザ部１２０により観測信号を観測できる。すなわち、ハードウェア的イベントの発生時もプロセッサ・コア１０２をブレークすることが可能であり、ＩＣＥ部１０６とロジック・アナライザ部１２０の動作を統合したデバッグが実現できる。したがって、プロセッサ・コア１０２と付加ハードウェア１０３とが混載されたＳｏＣデバイスを効率よくデバッグできるようになる。

なお、第１の実施の形態のデバッガでは、図５Ｂに示したようにブレーク要求信号やトリガ要求信号の有無にかかわらず、実行制御回路１１８はＳｏＣデバイス１０１に対して常にクロックを供給している。

（第２の実施の形態）
ＳｏＣデバイス１０１は、設計の容易性から原則としてクロックに同期して動作する同期回路で構成され、プロセッサ・コア１０２や所定の機能を実現する付加ハードウェア１０３等の回路ブロック毎に、またはＳｏＣデバイス１０１の回路全体が共通のクロックに同期して動作する。

付加ハードウェア１０３をデバッグする場合、ロジック・アナライザ部１２０によりＳｏＣデバイス１０１から出力される観測信号をクロック単位で記録して調査すると共に、イベント発生時にはＳｏＣデバイス１０１の実行制御をクロック単位で（ＩＣＥ部１０６で実施するブレーク信号による命令単位の実行制御よりも細かく）実施したい場合がある。このようなクロック単位の実行制御は、第１の実施の形態で示した実行制御回路１１８に、イベント発生時にクロックの供給を停止する機能を付加することで実現できる。

第２の実施の形態のデバッガは、実行制御回路１１８の構成及び動作が第１の実施の形態のデバッガと異なっている。その他の構成及び動作は第１の実施の形態と同様であるため、その説明は省略する。

図６Ａは本発明のデバッグ方法の第２の実施の形態の処理を示すフロー・チャートであり、図６Ｂは本発明のデバッグ方法の第２の実施の形態の処理を示すタイミング・チャートである。なお、図６Ａに示すフロー・チャートは、第２の実施の形態の実行制御回路１１８の処理手順を示し、図６Ｂは実行制御回路１１８の入出力信号のタイミング・チャートの例を示している。

図６Ａに示すように、第２の実施の形態の実行制御回路１１８は、ブレーク検出回路１０７によるブレーク要求信号の発生有無を監視し（ステップ２０２）、ブレーク要求信号の発生時、トリガ信号を生成してロジック・アナライザ部１２０による観測信号のモニタを可能にすると共に、ＳｏＣデバイス１０１に対するクロックの供給を停止する。

図６Ｂに示すように、第２の実施の形態の実行制御回路１１８は、時刻ｔ０にてブレーク検出回路１０７からブレーク要求信号を受け取ると、トリガ信号を出力してロジック・アナライザ部１２０による観測信号のモニタを可能にすると共に、ＳｏＣデバイス１０１に対するクロックの供給を停止する。実行制御回路１１８は、ＳｏＣデバイス１０１に対するクロックの供給を、例えばユーザからの指示にしたがって再開する。

本実施形態によれば、第１の実施の形態と同様の効果に加えて、ＳｏＣデバイス１０１の実行制御をクロック単位で制御できるようになるため、ＳｏＣデバイス１０１が備える付加ハードウェア１０３をより効率的にデバッグできる。

（第３の実施の形態）
第２の実施の形態のデバッガでは、ＳｏＣデバイス１０１に対するクロックの供給停止時、ロジック・アナライザ部１２０の機能は使用できるがＩＣＥ部１０６の機能は使用できない。すなわち、ＳｏＣデバイス１０１から観測信号として引き出した信号はモニタできても、観測信号に含めていない信号、例えばプログラム・カウンタの値や汎用レジスタに格納された情報等のようにＩＣＥ部で一般的に観測できる信号であっても観測信号に含めていなければモニタすることはできない。一般に、ＩＣＥ部１０６の機能は、所定の割り込み信号で起動するプロセッサ・コア１０２に搭載されたソフトウェアによる動作によって実現される。そのため、クロックの供給停止によってプロセッサ・コア１０２の動作が停止すると、ＩＣＥ部１０６の機能が利用できなくなる。

なお、ＳｏＣデバイス１０１へのクロックを停止していても、例えば特開２００５−１８１０６１号公報に記載されているように、共通クロックと異なる書き換え用のクロックを用いて書き換え対象のレジスタの各ビットにデータを格納する回路を付加すれば、プロセッサ・コア１０２の内部レジスタの内容を書き換えることが可能である。しかしながら、このような回路を付加することは、ＳｏＣデバイス１０１の回路設計作業の増大や回路の付加に伴う動作速度の低下を招くため、安易に採用することはできない。

さらに、プロセッサ・コア１０２や付加ハードウェア１０３では、通常、多段パイプライン動作を行っているため、ある信号に依存する派生信号がパイプライン・ステージ毎に存在する。したがって、ＳｏＣデバイス１０１の任意の内部レジスタを書き換える場合、その内部レジスタの値から派生する信号も全て書き換える必要がある。しかしながら、ユーザの手作業により内部レジスタの値とその派生信号の全てを整合させながら書き換えることは困難である。

第３の実施の形態では、クロックの停止状態において、ユーザからの指示にしたがってブレーク信号要求が発生すると、実行制御回路１１８によりＳｏＣデバイス１０１に対するクロックの供給を再開する。

すなわち、第３の実施の形態のデバッガは、実行制御回路１１８の構成及び動作が第２の実施の形態のデバッガと異なっている。その他の構成及び動作は第１及び第２の実施の形態と同様であるため、その説明は省略する。

第３の実施の形態の実行制御回路１１８の動作について図７Ａ、Ｂを用いて説明する。

図７Ａは本発明のデバッグ方法の第３の実施の形態の処理を示すフロー・チャートであり、図７Ｂは本発明のデバッグ方法の第３の実施の形態の処理を示すタイミング・チャートである。なお、図７Ａに示すフロー・チャートは、第３の実施の形態の実行制御回路１１８の処理手順を示し、図７Ｂは実行制御回路１１８の入出力信号のタイミング・チャートの例を示している。

図７Ａに示すように、第３の実施の形態の実行制御回路１１８は、第２の実施の形態と同様に、ブレーク検出回路１０７からのブレーク要求信号の発生有無を監視し（ステップ２０２）、ブレーク要求信号が発生すると、トリガ信号を生成してロジック・アナライザ部１２０における観測信号のモニタを可能にすると共に、ＳｏＣデバイスに対するクロック１１９の供給を停止する（ステップ２０３）。

この状態では、第２の実施の形態と同様に付加ハードウェア１０３から引き出されていない観測信号のモニタは不能であり、上記特開２００５−１８１０６１号公報に記載されたような回路を付加しないかぎりプロセッサ・コア１０２の内部レジスタの書き換えは不能である。

第３の実施の形態の実行制御回路１１８は、クロックの供給停止状態において、ユーザからＩＣＥ ＵＩ１０８を介してデバッグ状態への遷移指示があると（ステップ２０４）、トリガ信号の生成を停止し、ブレーク信号を出力すると共に（ステップ２０５）、ＳｏＣデバイス１０１に対するクロックの供給を再開する（ステップ２０６）。

図７Ｂに示しように、第３の実施の形態の実行制御回路は、時刻ｔ０にてブレーク検出回路１０７からブレーク要求信号を受け取ると、トリガ信号を生成し、ＳｏＣデバイス１０１に対するクロックの供給を停止する。

クロック停止後、時刻ｔ１にてユーザからＩＣＥ ＵＩ１０８を介してデバッグ状態への遷移指示があった場合、実行制御回路１１８によりトリガ信号を解除し、ブレーク信号を出力した後、ＳｏＣデバイス１０１に対するクロックの供給を再開する。

クロックが供給されることで動作が再開すると、プロセッサ・コア１０２は、ブレーク信号が既に出力されているため、デバッグ状態に遷移する。この状態では、ＩＣＥ部１０６の機能を使うことができるため、ユーザは、ＩＣＥ部１０６の機能を利用して、プログラム・カウンタの値や内部レジスタの確認、あるいは内部レジスタの書き換え等が可能になる。

本実施形態によれば、第２の実施の形態で示した効果に加えて、ＳｏＣデバイス１０１に回路を追加することなく、ハードウェア的イベントの発生時であってもプログラム・カウンタや汎用レジスタの読み書き等のＩＣＥ部１０６のデバッグ機能を利用できる。

以上、本発明のデバッガについて説明したが、図４に示したＳｏＣデバイス１０１を本発明のデバッガ１２１を用いてデバッグする場合、ＳｏＣデバイス１０１は図８に示す３つの状態間を遷移する。

図８は図４に示したＳｏＣデバイスの動作状態を示す状態遷移図である。

第１状態は、通常の処理の実行状態を示す「ユーザ・アプリケーション実行状態」である。

第２状態は、ブレーク信号が発生してユーザ・プログラムによる動作を停止し、ＩＣＥ部１０６の機能を実現するためのソフトウェアにしたがって処理を実行している「命令レベル停止状態」（デバッグ状態）である。このとき、ＩＣＥ部１０６の機能を用いてプログラム・カウンタの値の確認、あるいはプロセッサ・コア１０２内部レジスタやシステム・メモリの読み書きが可能である。

第３状態は、トリガ信号が発生したことによる「クロック停止状態」である。

上述した第１の実施の形態のデバッガは、従来のソフトウェア的イベントからブレーク信号を生成していた構成（図１）に、ハードウェア的イベントからもブレーク信号を生成できるようにした構成である。第１の実施の形態のデバッガを用いると、ハードウェア的イベントの発生に対応してＳｏＣデバイス１０１が命令レベル停止状態（デバッグ状態）に遷移するため、プロセッサ・コア１０２に格納されたユーザ・プログラムのデバッグが可能になる。

また、第２の実施の形態のデバッガは、ハードウェア的イベントをロジック・アナライザ部１２０による観測信号のモニタタイミングとして用いるだけではなく、ＳｏＣデバイスに対するクロックの供給を停止することで、ＳｏＣデバイス１０１全体を停止状態に移行させる構成である。

また、第３の実施の形態のデバッガは、クロック停止状態から命令レベル停止状態への遷移を可能にして、クロック停止状態では困難なＩＣＥ部１０６によるデバッグ機能を実現する構成である。

以上、第１の実施の形態から第３の実施の形態で説明したように、本発明によれば、ハードウェア的イベントかソフトウェア的イベントかに係わらず、ロジック・アナライザ部１２０による付加ハードウェア１０３の観測信号のモニタとＩＣＥ部１０６によるプロセッサ・コア１０２のプロセッサ状態の確認や内部レジスタの読み書きが可能になるため、ＩＣＥ部１０６とロジック・アナライザ部１２０の動作を統合したデバッグ環境を提供することが可能であり、ＳｏＣデバイス１０１の開発環境を大幅に改善できる。

なお、上記説明では、デバッガ１２１に、ブレーク検出回路１０７、トレース・メモリ１１３及びトリガ検出回路１１２を備える構成を示しているが、これらの回路はデバッガ１２１に備えている必要はなく、ＳｏＣデバイス１０１に備えていてもよい。

例えば、近年のＳｏＣデバイス１０１は、その高速化に伴って信号周波数が高くなり、付加ハードウェア１０３の近くで信号を観測しなければならない場合がある。そのような場合、ＳｏＣデバイス１０１にトリガ検出回路１１２やトレース・メモリ１１３を備えていれば、トレース・メモリ１１３に対する観測信号の格納ミスやトリガ検出回路１１２からのトリガ信号の誤出力が防止される。

また、ＳｏＣデバイス１０１の機能をＦＰＧＡ（Field Programmable Gate Array）等を用いてエミュレーションする場合は、該ＦＰＧＡに、上記ブレーク検出回路１０７、トレース・メモリ１１３及びトリガ検出回路１１２だけでなく、実行制御回路１１８やＩＣＥ ＵＩ１０８及びロジック・アナライザＵＩ１１４の一部機能を持たせることが可能である。

また、上記説明では、実行制御回路１１８からＳｏＣデバイス１０１にクロックを供給する例を示しているが、ＳｏＣデバイス１０１に対するクロックの供給／停止が制御できれば、実行制御回路１１８からＳｏＣデバイス１０１にクロックを供給する必要はない。例えば、実行制御回路１１８でクロックのイネーブル信号を生成し、該イネーブル信号により、例えばＳｏＣデバイス１０１の内部でクロックの生成やクロックの供給／停止を制御する構成も考えられる。

また、図５Ｂ、図６Ｂ及び図７Ｂに示したタイミング・チャートでは、ブレーク要求信号やトリガ要求信号がＬｏｗレベルからＨｉｇｈレベルに変わったときにトリガ信号やブレーク信号の生成、あるいはクロックの供給停止や再開等の事象が発生する例を示したが、これらの事象はＨｉｇｈレベルからＬｏｗレベルに変わったときに発生してもよい。これらトリガ信号やブレーク信号の生成、あるいはクロックの供給停止や再開等のタイミングは、ブレーク要求信号やトリガ要求信号の立ち上がりまたは立ち下がりで示すかは本質的ではなく、どのように設定してもよい。

この出願は、２００６年８月１４日に出願された特願２００６−２２０９５８号を基礎とする優先権を主張し、その開示の全てをここに取り込む。

Claims (2)

1. マイクロプロセッサ・コアと所定の機能を実現する付加ハードウェアとが混載されたシステム・オン・チップ・デバイスをデバッグするためのデバッガであって、
   前記マイクロプロセッサ・コアの状態が予め設定されたブレーク条件と一致するとき、ソフトウェア的イベントの発生を示すブレーク要求信号を生成するブレーク検出回路と、
   前記付加ハードウェアの所定の信号が予め設定されたトリガ条件と一致するとき、ハードウェア的イベントの発生を示すトリガ要求信号を生成するトリガ検出回路と、
   前記ブレーク要求信号が発生したとき、前記所定の信号をロジック・アナライザにより観測するためのトリガ信号を出力すると共に、前記マイクロプロセッサ・コア及び前記付加ハードウェアに対する、前記マイクロプロセッサ・コア及び前記付加ハードウェアを通常動作させるためのクロックの供給を停止する実行制御回路と、
   を有し、
   前記実行制御回路は、
   前記マイクロプロセッサ・コア及び前記付加ハードウェアに対する前記クロックの供給を停止しているとき、
   外部から前記マイクロプロセッサ・コアに対するデバッグ状態への遷移指示を受け取ると、前記トリガ信号の出力を停止し、前記マイクロプロセッサ・コアを前記デバッグ状態に遷移させるためのブレーク信号を出力すると共に、前記マイクロプロセッサ・コア及び前記付加ハードウェアに対する前記クロックの供給を再開するデバッガ。
2. マイクロプロセッサ・コアと所定の機能を実現する付加ハードウェアとが混載されたシステム・オン・チップ・デバイスをデバッグするためのデバッグ方法であって、
   前記マイクロプロセッサ・コアの状態が予め設定されたブレーク条件と一致するとき、ソフトウェア的イベントの発生を示すブレーク要求信号を生成し、
   前記付加ハードウェアの所定の信号が予め設定されたトリガ条件と一致するとき、ハードウェア的イベントの発生を示すトリガ要求信号を生成し、
   前記ブレーク要求信号が発生したとき、前記システム・オン・チップ・デバイスに対して前記所定の信号をロジック・アナライザにより観測するためのトリガ信号を出力し、前記マイクロプロセッサ・コア及び前記付加ハードウェアに対する、前記マイクロプロセッサ・コア及び前記付加ハードウェアを通常動作させるためのクロックの供給を停止し、
   前記マイクロプロセッサ・コア及び前記付加ハードウェアに対する前記クロックの供給を停止しているとき、
   前記マイクロプロセッサ・コアに対するデバッグ状態への遷移指示を受け取ると、前記トリガ信号の出力を停止し、前記システム・オン・チップ・デバイスに対して、前記マイクロプロセッサ・コアを前記デバッグ状態に遷移させるためのブレーク信号を出力すると共に、前記マイクロプロセッサ・コア及び前記付加ハードウェアに対する前記クロックの供給を再開するデバッグ方法。

Images