JP2006293725A - Ｌｓｉシステム向けデバッグ装置 - Google Patents

Abstract

【課題】ソフトウェアの不具合に起因するＤＭＡの誤転送が発生し、このためにハードウェアモジュールの設定が変更され、ソフトウェア開発者の意図したとおりにソフトウェア・ハードウェアが動作しない場合のデバッグにおいて、従来のデバッガでは、アクセス元となったＤＭＡを直接突き止めることが出来ず、問題の解決には至らない。ＣＰＵ以外のハードウェアによるアクセスについて、アクセス元を特定することが出来ない。
【解決手段】デバッガは、ターゲットの各ＤＭＡ仕様情報と、自己の持つＣＰＵトレース情報から、各ＤＭＡの現在の設定状況を管理する。その上で、各ＤＭＡの設定状況から、問題のアクセスを発行しうるＤＭＡを判定する。
【選択図】図１

Description

本発明は、ソフトウェア不具合解析を目的としたデバッグ装置（デバッガ）に関するものである。

従来のデバッグ機構としては、ＬＳＩシステムのバスを観測するにあたり、ＬＳＩシステム自身にバスアドレス一致検出部を搭載することで、ロジックアナライザ等を用意せずとも、バスアクセスを観測可能とするものがあった（例えば、特許文献１参照）。

図１２は、特許文献１に記載された従来のデバッグ機構を示すものである。図１２において、１２０８は、設定アドレスレジスタ１２０８ａに予め設定されている一致検出したいアドレス値と、アドレス／データバス１２０４上のアドレス値とを常に一致検出判断して、アドレス／データバス１２０４上のアドレス値を常にモニタするための一致検出部である。１２０８は監視アドレスと一致検出したいアドレスが一致すると、割り込み信号を１２０７経由でＭＰＵ１２１２へ送出し、アドレス一致検出したことをＭＰＵ１２１２へ通知する。信号１２０５はＤＭＡコントローラ１２０２からの転送状態信号であり、１２０５と１２０６が共に「Ｈｉ」であるとき、割り込み信号１２０７がＭＰＵ１２１２へ入力される。
特開平２−２２８７４１号公報（第４頁、図１）

しかしながら、前記従来デバッグ機構では、例えばソフトウェアの不具合に起因するＤＭＡの誤転送が発生し、このためにハードウェアモジュールの設定が変更され、ソフトウェア開発者の意図したとおりにソフトウェア・ハードウェアが動作しない場合のデバッグにおいては、アクセス元となったＤＭＡを直接突き止めることが出来ず、問題の解決には至らない。

つまり、従来のデバッガでは、ＣＰＵ以外のハードウェアによるアクセスについて、アクセス元を特定することが出来ないという課題を有していた。

本発明は、前記従来の課題を解決するもので、バスアクセスを発行したＤＭＡを特定可能なデバッガを提供することを目的としている。

前記従来の課題を解決するために、本発明のデバッガは、デバッグ対象（ターゲット）の各ＤＭＡ仕様情報と、各ＤＭＡの現在の設定状況を管理する。その上で、各ＤＭＡの設定状況から、問題のアクセスを発行しうるＤＭＡを判定する。

本構成によって、従来デバッガでは不可能だった、バスアクセスを発行したＤＭＡの特定が可能になる。

本発明のデバッガによれば、問題となるバスアクセス元がＤＭＡであっても、このＤＭＡの特定が可能。従来デバッガで同等の成果を挙げるには、ターゲットに精通した解析者による、各ＤＭＡ仕様とＣＰＵトレース情報の照合が必要だった。つまりデバッガの性能向上、ひいてはソフトウェア開発の効率が向上する。

以下本発明の実施の形態について、図面を参照しながら説明する。

（実施の形態１）
図１は、本発明の実施の形態１におけるデバッガを含む、デバッグシステムの構成図である。

デバッガ１０１はユーザＩ／Ｆ１０４を持つ。またデバッガ１０１内部にはデバッガ制御用ＣＰＵ１０３ならびに、ＣＰＵトレース情報およびターゲットの各ＤＭＡ情報を蓄積するメモリ１０２が存在する。デバッガ１０１とターゲット１０５は、デバッガ・ターゲット間の双方向通信路ならびに、ターゲットからのトリガ信号により接続される。ターゲット１０５の内部は、ＣＰＵ１０６、バス制御装置およびバス監視機構１０７、メモリ１０８、回路Ａ１０９、回路Ｂ１１０と、各回路間を接続するバスで構成される。

バス制御措置およびバス監視機構１０７について、詳細を図２に記す。ターゲットＣＰＵ１０６が発行したバスアクセスが、期待値アクセスパターンに一致すると、トリガ信号をデバッガへ向けて発信する機能を保有する。具体的には、メモリ２０４および２０５に予め設定されたアクセスパターン（アドレスおよびデータ）とＣＰＵの発行したアクセスを、そのパラメータごとに比較器２０１および２０２でパターンを判断し、パターン一致すればＨｉ信号がＡＮＤ回路２０３に入力される。ＡＮＤ回路２０３の出力がＨｉ信号となれば、デバッガはこれを受けて、ＣＰＵが期待値アクセスパターンを発行したことを検知する。期待値パターンを保持するメモリ２０４および２０５は、ターゲットＣＰＵ１０６からメモリマップされた空間に存在し、ターゲットＣＰＵ１０６によりその値の設定が可能である。

また、バスアクセス分配装置２０６は、入力されたアクセスのアドレスに応じて、アクセスバスを選択し、入力アクセスを選択したバスに伝えるものである。

ここで、図１の回路Ａ１０９に対して、ソフトウェア開発者の意図しないｗｒｉｔｅアクセスが観測され、これのアクセス元を特定する場合のフローチャートを図３、図４、図５に示す。各フローチャートにおいては、ユーザＩ／Ｆ１０４を介してデバッガ１０１を操作するユーザ、デバッガ１０１自身、およびターゲット１０５相互の挙動が分かるよう、同一の時間軸に３者を並べて記述した。

図３においては、３０１に示すように、ユーザがデバッガに対して、ターゲットＤＭＡの仕様情報を入力する。仕様情報とはレジスタ仕様のことであり、図１３に示すように、転送先アドレス設定レジスタ、転送元アドレス設定レジスタ、転送サイズ設定レジスタの、各アドレスの情報である。これはターゲットの種類ごとに固有の情報であり、デバッガまたはターゲットのベンダなどにより、予め用意されているものとする。

次に、３０３に示すように、問題となっているバスアクセスを特定するためのパラメータとして、アクセス先アドレスと、そのデータをターゲットに設定する。設定の方法はデバッガ経由でターゲットＣＰＵを操作しても良いし、ターゲットＣＰＵ上のソフトウェアから直接設定しても良い。ターゲットはこれを受けて、自身が持つバスアクセス監視機構に、前記アドレスとデータをセットする。

ここまでがデバッグ前の準備段階であり、次にターゲット動作ならびにデバッガの動作が開始する。この間、デバッガはターゲットＣＰＵの過去一定期間分のトレース情報を自己の持つメモリに蓄積し続け、ターゲットのバス制御装置およびバス監視機構１０７は、予め設定されたバスアクセスパターンとバスアクセスとの比較、監視を続ける。

ここでターゲットのバス制御装置およびバス監視機構１０７が、予め設定されたアクセスパターンを検出し、トリガ信号をデバッガに出力したとして、図４に移る。

図４においては、デバッガが、自己の管理するターゲットの各ＤＭＡ仕様情報と、ＣＰＵトレース情報（＝ＣＰＵのアクセス履歴）全てについて、総当りでチェックを行い、ターゲットの各ＤＭＡの設定状況をデバッガ内に生成する。

具体的には、デバッガの持つ、ターゲットＣＰＵのｗｒｉｔｅアクセス履歴について、アクセス先がＤＭＡ制御レジスタであるか否か判定し（４０４）、例えばこれがＤＭＡ３の転送先アドレス設定レジスタへのｗｒｉｔｅであると判定された場合には、ＤＭＡ３の転送先アドレス情報を、ｗｒｉｔｅアクセスのデータの通りに更新する。これにより、デバッガは、現在のターゲット内の各ＤＭＡについて、設定状況（＝転送パラメータ、転送先アドレス、転送元アドレス、転送サイズ）を知ることが出来る。

これが終了すると、フローは図５に移る。

図５においては、ターゲット内で検出されたｗｒｉｔｅアクセスについて、これを発行しうるＤＭＡを、デバッガの持つ各ＤＭＡの設定状況から判断する。

具体的には、例えばターゲット内にＤＭＡが合計２０チャンネルあるとすれば、その２０チャンネルの各ＤＭＡについて、転送先空間に問題となっているｗｒｉｔｅアクセスのアドレスが含まれるかどうか（５０４）、含まれるのであれば、さらに、ＤＭＡの転送元空間に、問題となっているｗｒｉｔｅアクセスのデータが含まれるかどうかをチェックする。ＤＭＡの転送先空間、転送元空間については、そのＤＭＡの転送先アドレスおよび転送元アドレス、転送サイズの設定状況から算出が可能である。このアドレスならびにデータの２条件が一致すれば、該ＤＭＡがバスアクセス元であるとデバッガは判断する。ちなみにこの例はアドレス・データ両方が該当することがバスアクセス元特定の条件としたが、アドレスの該当のみ、またはデータの該当のみだけでバスアクセス元としての判定を行っても構わない。

また、バスアクセス元としての判定条件に該当するＤＭＡが存在しなかった場合は、デバッガは、問題のバスアクセス元として該当するＤＭＡは無い、との判定を行う。この結果は、従来のＣＰＵトレース機能と組み合わせた場合に、問題となるバスアクセス発行元がＣＰＵではなく、さらにＤＭＡでもないという情報をユーザに提供することになり、これはこれでデバッグを進める上で有益な情報になる。

さらに、図５のフローチャート上では、バスアクセス元と判定されたＤＭＡが１つ見つかればフロー終了としているが、５０７から５０８に制御を移すことで、全ＤＭＡについてバスアクセス元の可能性をチェックし、疑わしいＤＭＡを全て列挙することも考えられる。

また、本実施の形態では、問題となるアクセスがｗｒｉｔｅアクセスであると限定したが、開発者の意図しないｒｅａｄアクセスにより不具合が生じた場合の、ｒｅａｄアクセス発行元の解析においても同様で、各ＤＭＡ設定情報から、転送元空間にｒｅａｄアドレスが含まれるか否かで、注目するＤＭＡがアクセス発行元であることを判断することが出来る。

なお、本実施の形態においては、上述のように、ターゲット内の全ＤＭＡの仕様情報をデバッガに入力させるに当たっては、ターゲット固有の設定ファイルをデバッガへ入力するほかに、前記設定ファイルに相当する情報がターゲット内部に情報テーブルとして用意され、デバッガ初期化の段階で、デバッガがターゲットからこの情報を読み出し、自己の持つメモリ上で管理する方式が考えられる。

（実施の形態２）
図６は、実施の形態１に比較して、バス監視機能がターゲット外部に存在する場合を想定している。実施の形態１におけるバス制御装置およびバス監視機構１０７は、本実施の形態においては信号観測装置６０２としてその機能が代替されている。信号観測装置６０２は、具体的には、ロジックアナライザを用いることが考えられる。このロジックアナライザは、図８に示すように、特定のバスパターンを検出すると、ＡＮＤ回路８０３より検出信号を外部に発信することが可能であり、図６においてこの信号は、トリガ信号としてデバッガ１０１に入力されている。図６の各構成について、図２と同様の構成のものは省略するが、図２と異なる点は、ユーザＩ／Ｆ機能８０６を保有している点である。ユーザは監視したいバスアクセスパターンを、この８０６経由で信号観測装置６０２に設定する。

ここで、図６の回路Ａ１０９に対して、ソフトウェア開発者の意図しないｗｒｉｔｅアクセスが観測されたとすると、これのアクセス元を特定する場合のフローチャートは図９、図４、図５となる。図４、図５についての説明は実施の形態１と同様であるので省略し、図３と図９の差分について説明する。図９において図３と異なるのは、信号観測装置６０２が監視すべきアクセスパターンを、ユーザが、図８に示すユーザＩ／Ｆ機能８０６を用いて設定する点（９０５）と、ターゲット動作開始・デバッガ動作開始と共に、信号観測装置６０２も観測開始させる点（９０９）である。

信号観測装置６０２が問題のアクセスを検出した場合、信号観測装置６０２からデバッガ１０１へトリガ信号が出力され、フローは図４へ移行する。この後の動作は実施の形態１と同様であるので省略する。

（実施の形態３）
図３、図４、図１０、図１１は、本発明の実施の形態３に関わるフローチャートである。システム構成図は図１の形態となる。ただし、図３ならびに図４の説明は実施の形態１において行ったものと同様であり、ここでは図１０、図１１についてのみ説明を行う。

ターゲット内の各ＤＭＡの設定情報を得るにあたっては、実施の形態１においては、デバッガ内部で情報処理によりこれを生成したのに対して、本実施の形態においては、従来デバッガの機能として、デバッガがターゲットＣＰＵを制御し、ターゲット内各ＤＭＡの制御レジスタ値を読み取ることで、ターゲット内の各ＤＭＡの設定情報を得るものである。

図１０および図１１において、デバッガには既にターゲット内の各ＤＭＡの仕様情報（制御レジスタのアドレス情報）が入力されている。したがって、個々の制御レジスタのアドレス情報に基づいて、１００２や１００５、１００８に示すように、デバッガがＣＰＵを制御してＤＭＡのレジスタ設定値を獲得する。これをターゲット内の全ＤＭＡの制御レジスタに対して行うことで、ターゲット内の全ＤＭＡの設定状況を把握することが出来る。その後の動作は実施の形態１と同様であるので省略する。

本発明にかかるデバッガは、ターゲットの各ＤＭＡ仕様情報と、各ＤＭＡの現在の設定状況を管理する機構を有する。これによって、従来のデバッガでは不可能であった、ＣＰＵ以外のハードウェアによるアクセスについて、アクセス元を直接特定することが可能となる。

本発明にかかるデバッガの対象は、ＤＭＡという限られた分野ではあるが、この類のソフトウェア不具合はバスアクセス元が特定できない点から、解析が非常に困難であり、デバッガ性能の向上、ひいてはデバッグ効率の大幅な改善が期待される。

実現にあたっては、現行デバッガの制御ソフトウェアの更新のみで容易に実現可能であり、今後のデバッガへの導入が予想される。

本発明の実施の形態１におけるデバッグシステム全体構成図 本発明の実施の形態１におけるターゲット内部の、バス制御装置およびバス監視機構の詳細図 本発明の実施の形態１のフローチャート（全３枚中の１枚目）を示す図 本発明の実施の形態１のフローチャート（全３枚中の２枚目）を示す図 本発明の実施の形態１のフローチャート（全３枚中の３枚目）を示す図 本発明の実施の形態２におけるデバッグシステム全体構成図 本発明の実施の形態２におけるターゲット内部の、バス制御装置の詳細図 本発明の実施の形態２における信号観測装置の詳細図 本発明の実施の形態２のフローチャートの一部を示す図 本発明の実施の形態３のフローチャートの一部を示す図 本発明の実施の形態３のフローチャートの一部を示す図 従来のデバッガの構成図 ターゲット内のＤＭＡ仕様情報設定ファイルの記述例を示す図

符号の説明

１０１ デバッガ
１０２ デバッガ内蔵メモリ
１０３ デバッガ制御ＣＰＵ
１０４ デバッガのユーザＩ／Ｆ
１０５ ターゲット
１０６ ターゲットＣＰＵ
１０７ バス制御装置およびバス監視機構
１０８ メモリ
１０９ 回路Ａ
１１０ 回路Ｂ
２０１ 比較器
２０２ 比較器
２０３ ＡＮＤ回路
２０４ メモリ
２０５ メモリ
２０６ バスアクセス分配装置
６０１ バス制御装置
６０２ 信号観測装置
８０１ 比較器
８０２ 比較器
８０３ ＡＮＤ回路
８０４ メモリ
８０５ メモリ
８０６ ユーザＩ／Ｆ機能
１２０１ ＣＰＵ
１２０２ ＤＭＡコントローラ
１２０３ メモリ
１２０４ アドレス／データバス
１２０５ ＤＭＡ転送状態信号
１２０６ アドレス一致信号
１２０７ ＭＰＵへのアドレス一致割り込み信号
１２０８ アドレス一致検出部
１２０８ａ 設定アドレスレジスタ
１２０９ ＡＮＤ回路
１２１１ 被デバッグ対象ターゲットシステム
１２１２ ＭＰＵ
１２１２ａ デバッグモード移行レジスタ
１２１４ ホールドアクノリジ信号

Claims (13)

1. ユーザＩ／Ｆ、ＣＰＵトレース機能ならびに、
   外部からの信号入力機構を持つデバッグ装置において、
   デバッグ対象となる半導体システムの保有する各ＤＭＡの仕様情報と、
   前記各ＤＭＡの現在の設定状況を、デバッグ装置内で管理することで、
   デバッグ対象が発行したバスアクセス元がＤＭＡであった場合に、
   そのＤＭＡを特定することが可能なデバッグ装置。
2. デバッグ対象の保有する各ＤＭＡ仕様情報については、
   デバッグ対象の保有する各ＤＭＡの仕様情報を、
   デバッグ装置のユーザＩ／Ｆからデバッグ装置へ入力することを特徴とした、
   請求項１に記載のデバッグ装置。
3. デバッグ対象の各ＤＭＡ仕様情報については、
   デバッグ対象内に、デバッグ対象自身が保有する各ＤＭＡの仕様情報が存在し、
   デバッグ装置が、デバッグ対象からこの情報を獲得することを特徴とした、
   請求項１に記載のデバッグ装置。
4. デバッグ対象が保有する各ＤＭＡの設定状況は、
   デバッグ装置が持つデバッグ対象のＤＭＡ仕様情報と、
   デバッグ装置の持つＣＰＵトレース機能から生成することを特徴とした、
   請求項１に記載のデバッグ装置。
5. デバッグ対象が保有するＤＭＡの現在の設定状況は、
   デバッグ対象のＤＭＡ仕様情報と、
   デバッグ装置の持つＣＰＵ制御機能から生成することを特徴とした、
   請求項１に記載のデバッグ装置。
6. デバッグ装置への信号入力については、
   デバッグ対象が発行する信号を 用いることを特徴とした、
   請求項１に記載のデバッグ装置。
7. デバッグ対象が発行する信号については、
   デバッグ対象自身のバスアクセス監視機構により発行される信号とする、
   請求項６に記載のデバッグ装置。
8. デバッグ装置への信号入力については、
   信号観測装置が出力する信号を用いることを特徴とした、
   請求項１に記載のデバッグ装置。
9. バスアクセス元を特定するにあたっては、
   デバッグ装置、デバッグ対象が保有する各ＤＭＡの設定状況と、
   トリガアクセスのアクセスパラメータを照合することで、
   注目するＤＭＡがバスアクセス元か否かを判定することを特徴とした、
   請求項１から請求項８のいずれか１項に記載のデバッグ装置。
10. バスアクセス元を特定するにあたっては、
    デバッグ対象の保有する各ＤＭＡの設定状況とトリガアドレスの照合の結果、
    トリガアドレスがあるＤＭＡの転送先空間に含まれていれば、
    前記ＤＭＡがバスアクセス元であると判定する、
    請求項９に記載のデバッグ装置。
11. バスアクセス元を特定するにあたっては、
    デバッグ対象の保有する各ＤＭＡの設定状況とトリガデータの照合の結果、
    トリガデータがあるＤＭＡの転送元空間に存在すれば、
    前記ＤＭＡがバスアクセス元であると判定する請求項９に記載のデバッグ装置。
12. バスアクセス元を特定するにあたっては、
    デバッグ対象の保有する各ＤＭＡの設定状況とトリガアドレスの照合の結果、
    トリガアドレスがあるＤＭＡの転送先空間に含まれていることと、
    各ＤＭＡの設定状況とトリガデータの照合の結果、
    トリガデータが前記ＤＭＡの転送元空間に存在することの両条件が揃えば、
    前記ＤＭＡがバスアクセス元であると判定する請求項９に記載のデバッグ装置。
13. バスアクセス元を特定するにあたっては、
    各ＤＭＡの設定状況とトリガアドレスの照合の結果、
    トリガアドレスがあるＤＭＡの転送元空間に含まれていれば、
    前記ＤＭＡがバスアクセス元であると判定する請求項９に記載のデバッグ装置。

Images