JP4475734B2 - データ処理装置及びデータ処理方法 - Google Patents
データ処理装置及びデータ処理方法 Download PDFInfo
- Publication number
- JP4475734B2 JP4475734B2 JP2000112811A JP2000112811A JP4475734B2 JP 4475734 B2 JP4475734 B2 JP 4475734B2 JP 2000112811 A JP2000112811 A JP 2000112811A JP 2000112811 A JP2000112811 A JP 2000112811A JP 4475734 B2 JP4475734 B2 JP 4475734B2
- Authority
- JP
- Japan
- Prior art keywords
- debug
- coprocessor
- instruction
- register
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3648—Software debugging using additional hardware
Description
【０００１】
【発明の属する技術分野】
本発明は、データ処理システムに関する。特に、本発明は、データ処理システム用のデバッグ機構に関する。
【０００２】
【従来の技術】
デバッグ機構による問題は、通常の動作中に可能なパフォーマンスと干渉又は制限することがあってはならないということである。例えば、公知のデバッグ機構は、プログラミングのブレークポイント（ｂｒｅａｋｐｏｉｎｔ）及びウォッチポイント（ｗａｔｃｈｐｏｉｎｔ）のようなデバッグ機構の構成を可能とするようにデータ処理パス内にマルチプレクサを付加したものをしばしば含む。
【０００３】
【発明が解決しようとする課題】
デバッグ用にのみに必要とされるこれらの付加的な回路要素は、通常の動作中にデータ処理システムのパフォーマンスを制限するクリティカル・データ・パス内に信号伝搬遅延をもたらす恐れがある。
【０００４】
【発明を解決するための手段】
本発明は、一特徴によれば、データ処理装置を提供するものであって、前記装置は、
メイン・プロセッサに入力された命令ストリーム内のメイン・プロセッサ命令に応答してメイン・プロセッサ・オペレーションを実行する前記メイン・プロセッサと、
コプロセッサ・インターフェースを介して前記メイン・プロセッサに接続され、かつ前記命令ストリーム内のコプロセッサ命令に応答してコプロセッサ・オペレーションを実行するコプロセッサとを備え、
前記コプロセッサは、前記データ処理装置をデバッグする診断データの発生を少なくとも部分的に制御するように動作可能なデバッグ・コプロセッサであり、前記コプロセッサ命令は前記デバッグ・コプロセッサのオペレーションを制御するデバッグ・コプロセッサ命令である。
【０００５】
本発明は、コプロセッサに通常使用される機構及び構造を使用して前記システムの通常オペレーションに対する影響を少なくしたデバッグ・システムを提供できることが解る。加えて、前記メイン・プロセッサは、このメイン・プロセッサのパフォーマンスを制限することなく、コプロセッサにより動作し、かつ通信するのを容易にするように、しばしば予め設計される。本発明は、デバッグ・プロセッサ形式によるデバッグ機構を設けることによりこのような特徴を得ている。このデバッグ・プロセッサは、前記メイン・プロセッサの通常パフォーマンスに対して殆ど影響しないように前記コプロセッサ・インターフェースを介して構築することが可能とされる。
【０００６】
前記デバッグ・コプロセッサを構成する特に効果的な方法は、１以上のデバッグ・コプロセッサ・レジスタを介することによる。
【０００７】
メイン・プロセッサ及びコプロセッサ・システムと関連されたコプロセッサ命令セットは、典型的には、コプロセッサ内のレジスタに値を書き込む、又はコプロセッサ内のレジスタから値を読み出すコプロセッサ命令を含む。このようにして、構成データをデバッグ・コプロセッサに書き込むことができ、またデバッグ・コプロセッサから診断データを復元することができる。
【０００８】
非常に有用なデバッグ機構は、ブレークポイント及びウォッチポイント機能を実行できるものである。これらのブレークポイント及びウォッチポイント値は、プログラムされ、かつ記憶される必要がある。この必要性は、所望のブレークポイント及びウォッチポイント値を記憶するようにデバッグ・コプロセッサ内のレジスタを使用することにより、非常に効果的に達成可能とされる。
【０００９】
更に、マスク値、エネーブル（ｅｎａｂｌｅ＝可能状態）ビット及びモード選択値のように、より複雑なブレークポイント及びウォッチポイント・オペレーションに関連された制御データもデバッグ・コプロセッサ内のレジスタを使用して効果的にプログラムし、かつ記憶可能とされる。従って、更に、転送サイズ、（例えば、特権（ｐｒｉｖｉｌｅｇｅｄ）／ユーザ）モード、命令セットを表示するビット（ＡＲＭ Ｔｈｕｍｂ Ｔビット）のようなアドレス属性等に対して比較を行うこともできる。
【００１０】
コプロセッサ・レジスタは、メイン・プロセッサに伝達された命令ストリーム内のコプロセッサ命令を介してアクセス可能とされる。これは、メイン・プロセッサに対して同一の命令を発行することにより、デバッグしているデータ処理システム上を走るソフトウェア、及び外部スキャニング機構の両者がコプロセッサ・レジスタをアクセスしてデバッグ・オペレーションを構成できるようにする。従って、メイン・プロセッサ・コア上を走るソフトウェアは、デバッグ・コプロセッサ用を意図した命令を通常形式によりメイン・プロセッサ・パイプラインにフィードすることができ、これに対してスキャン機構は、命令転送レジスタを通ってデバッグ・コプロセッサ用を意図した命令をスキャン入力することができる。次に、これらのスキャン入力命令は、同一のメイン・プロセッサ・パイプラインへの命令として発行されることにより、フル速度で１度に１つ実行される。
【００１１】
その代わり及び追加として、少なくともいくつかのデバッグ・コプロセッサ・レジスタは、スキャン・チェーン・コントローラの制御により動作する直列スキャン・チェーンを介してアクセスされてもよい。これは、デバッグ・コプロセッサ形式によりデバッグ機構の外部プログラミングを外部ハードウェア及びソフトウェアにより達成可能にする。
【００１２】
スキャン・チェーン機構を介してアクセス可能なレジスタは、命令を直列的にシステムにスキャン入力するのを可能にし、次いでメイン・プロセッサか又はデバッグ・コプロセッサ（又はプロセッサ・インターフェースに取り付けられた浮動小数点ユニット・プロセッサのような他のコプロセッサ）により実行できるようにするレジスタを含む。
【００１３】
同様にして、スキャン・チェーン機構を介してアクセス可能なレジスタは、データ値をシステムにスキャン入力、又はシステムから直列にスキャン出力できる領域を含むことが好ましい。このようにデータ値を適用すること及び復元することは、診断オペレーションにおいて非常に有用である。
【００１４】
好ましい実施例は、このようなデータ値レジスタをアクセスしようとしていると同時に、スキャン・チェーンによりアクセスされていたメイン・プロセッサ又はコプロセッサの潜在的な問題を処理するために、２つのデータ値レジスタ形式、一方は、メイン・プロセッサ又はコプロセッサにより書き込み可能とされ、かつスキャン・チェーンにより読み出し可能とされる形式、また他方は、メイン・プロセッサ又はコプロセッサにより読み出し可能、かつスキャン・チェーンにより書き込み可能とされる形式にあるデータ値レジスタを提供するものである。これは、潜在的なデータ競合を回避する双方向通信チャネルを効果的に形成する。
【００１５】
好ましい実施例により得られるデバッグ・コプロセッサ内の他のレジスタは、読み出し及び書き込みが可能であり、かつデバッグ・モードへのエントリ条件、デバッグ・エネーブル・ビット、及びメイン・プロセッサのベクトル命令トラップ・オペレーションを制御するフラグのような情報を記憶するデバッグ・ステータス制御レジスタである。
【００１６】
デバッグ・コプロセッサは、好ましくは、パイプライン・ドレーン、パイプライン・ホールド及び命令取り消しのような機能を実行するためにシステムの残りに伝達可能とされる制御信号を使用すること、及び発生することができる。
【００１７】
デバッグ・コプロセッサは、典型的には、システム内のメイン・プロセッサ及びその他の全てのコプロセッサと同一のクロック周波数で動作する。これは、デバッグ・コプロセッサがメイン・プロセッサ及び他の全てのコプロセッサの通常的なオペレーション速度に対する影響が軽減されるように、標準的なコプロセッサ・インターフェースを使用して、これらの要素間の対話を容易にする。しかしながら、スキャン・チェーン機構は、異なる典型的には非同期のクロック速度で典型的に動作し、従ってデバッグ・コプロセッサはこれらの要素が異なるクロック領域内で通信できるようにした回路を備える必要がある。これらの付加的な機構は、他のメイン回路要素の通常的なオペレーションとの干渉を避けるようにしてデバッグ・コプロセッサ内で絶縁されてもよい。
【００１８】
本発明は、他の特徴によれば、データ処理方法を提供するものであって、前記方法は、
メイン・プロセッサに入力される命令ストリーム内のメイン・プロセッサ命令に応答して、メイン・プロセッサ・オペレーションを実行するステップと、
前記命令ストリーム内のコプロセッサ命令に応答し、コプロセッサ・インターフェースを介して前記メイン・プロセッサに接続されたコプロセッサを制御してコプロセッサ・オペレーションを実行するステップとを備え、
前記コプロセッサは、データ処理装置のデバッグのための診断データの発生を少なくとも部分的に制御するように動作可能なデバッグ・コプロセッサであり、前記コプロセッサ命令は、前記デバッグ・コプロセッサのオペレーションを制御するデバッグ・コプロセッサ命令である。
【００１９】
以下、添付図面を参照して、本発明を単なる一実施例による概要図により説明する。
【００２０】
【発明の実施の形態】
図１は、メイン・プロセッサ４、デバッグ・コプロセッサ（及びシステム・コプロセッサ）６、及び浮動小数点ユニット・コプロセッサ８を含むデータ処理システム２を示す。メイン・プロセッサ４は、コプロセッサ・バスＣＰの形式にあったコプロセッサ・インターフェースを介してデバッグ・コプロセッサ６及び浮動小数点ユニット・プロセッサ８に接続されている。このコプロセッサ・バスＣＰの形式は、標準的なコプロセッサ・バス、例えば（英国ケンブリッジのＡＲＭ有限会社製造のマイクロプロセッサに使用されている）ＡＲＭコプロセッサ・バスとほぼ同一である。
【００２１】
メイン・プロセッサ４は、データ・バスＤＢと、プリフェッチ・ユニット（ｐｒｅｆｅｔｃｈ ｕｎｉｔ）１０を介して命令バスＩＢとに接続されている。データ・バスＤＢ及び命令バスＩＢの両者は、ブレークポイント及びウォッチポイントをそれぞれ識別するためにデバッグ・コプロセッサ６により監視されるアドレス部を含む。
【００２２】
メイン・プロセッサ４、デバッグ・コプロセッサ６及び浮動小数点ユニット・プロセッサ８は、全てメイン・プロセッサのクロック周波数で共通メイン・プロセッサ・クロック信号ｃｌｋにより駆動される。スキャン・チェーン・コントローラ１２は、更にデバッグ・コプロセッサと共にデバッグ・ロジックの一部を形成する。スキャン・チェーン・コントローラ１２は、メイン・プロセッサ・クロック信号ｃｌｋと典型的に異なる周波数を有するデバッグ・クロック信号ｔｃｋにより駆動され、かつメイン・プロセッサ・クロック信号ｃｌｋと非同期である。
【００２３】
データ転送レジスタ（ｄａｔａ ｔｒａｎｓｆｅｒ ｒｅｇｉｓｔｅｒ）ＤＴＲ及び命令転送レジスタ（ｉｎｓｔｒｕｃｔｉｏｎ ｔｒａｎｓｆｅｒ ｒｅｇｉｓｔｅｒ）ＩＴＲは、いずれも個別的な直列スキャン・チェーンにより書き込み及び読み出しができるようにスキャン・チェーン・コントローラ１２に接続されている。図示していないが、いくつかのモードにおいて、データ転送レジスタＤＴＲ及び命令転送レジスタＩＴＲの個別的なスキャン・チェーンは、単一のスキャン・チェーンを形成するように互いに連結されてもよい。スキャン・チェーン・コントローラ１２は、ＩＥＥＥ１１４９．１ＪＴＡＧ標準において規定された形式のものである。このシステムは、スキャン・チェーン・コントローラ１２がＴＡＰコントローラ・ステート内のＲｕｎ−Ｔｅｓｔステートを通るときはいつも、命令転送レジスタＩＴＲがその内容を、メイン・プロセッサ４のパイプライン１４に伝達されて有効な命令ラインを主張することにより実行される命令として、プリフェッチ・ユニット１０に発行するように制御される。プリフェッチ・ユニット１０からメイン・プロセッサ４に伝達された命令は、メイン・プロセッサ４それ自身により、又はコプロセッサ・バスＣＰを介してメイン・プロセッサ４に接続されたデバッグ・コプロセッサ６、浮動小数点ユニット・コプロセッサ８のうちの１つを意図したものにより、実行される命令であってもよい。
【００２４】
２つの公開命令ＨＡＬＴ及び再起動ＲＥＳＴＡＲＴは、以下で更に説明するようにメイン・プロセッサの通常オペレーションを停止させるため、及び再起動させるために通常のＪＴＡＧ命令に付加された。
【００２５】
図２はデバッグ・コプロセッサ６を更に詳細に示す。メイン・プロセッサ４よりもコプロセッサにより実行することを意図したコプロセッサ命令は、コプロセッサ番号オペランド・フィールドを含む。このようにして、コプロセッサ番号に一致したコプロセッサのみがコプロセッサ命令に応答してこれを実行する。この場合に、デバッグ・コプロセッサにはコプロセッサ番号ＣＰ１４が与えられる。ＡＲＭメイン・プロセッサに通常関連されるシステム・コプロセッサには、コプロセッサ番号ＣＰ１５が与えられ、かつ種々の制御レジスタが含まれる。図２はデバッグ・コプロセッサＣＰ１４を示す。
【００２６】
デバッグ・コプロセッサ６は、１バンクのウォッチポイント・レジスタ１６及び１バンクのブレークポイント・レジスタ１８を含む。デバッグ・コプロセッサ６内のウォッチポイント・レジスタ１６及びブレークポイント・レジスタ１８は、ウォッチポイント及びブレークポイント・アドレスをそれぞれ記憶する。各ウォッチポイント・レジスタ１６及びブレークポイント・レジスタ１８には、それぞれの制御レジスタ２０、２２が関連されている。これらの制御レジスタ２０、２２は、命令バスＩＢ及びデータ・バスＤＢとそれぞれのブレークポイント及びウォッチポイント値との比較のために適用されるマスク値のような制御データを記憶する。更に、これらの制御レジスタは、ブレークポイント又はウォッチポイントが活性となるのはどの動作モードかを表す値と共に、関連されるブレークポイント又はウォッチポイントをエネーブル又はディセーブル（ｄｉｓａｂｌｅ：不能状態）にするフラグを記憶することができる。
【００２７】
ウォッチポイント・レジスタ１６からのウォッチポイント値は、それぞれのウォッチポイント比較器２４によりデータ・バスＤＢ上のデータ・アドレスと比較され、一方、ブレークポイント・レジスタ１８からのブレークポイント値は、ブレークポイント比較器２６により命令バスＩＢ上の命令アドレスと比較される。ウォッチポイントの一致又はブレークポイントの一致が確認されると、これがウォッチポイント・ヒット信号ＷＰＨ又はブレークポイント・ヒット信号ＢＰＨにより残りの回路に通知される。更に、デバッグ・エネーブル信号ＤＥが発生される。ウォッチポイント・ヒット信号ＷＰＨ、ブレークポイント・ヒット信号ＢＰＨに及びデバッグ・エネーブル信号ＤＥは、デバッグ・コプロセッサ６とメイン・プロセッサ４との間に存在するインターフェースの一部とみなすことができ、メイン・プロセッサ・ステータスを示すため、コアは停止すべきことを示すため、又はコアは再起動すべきことを示すために付加的な信号を含めることもできる。
【００２８】
更に、デバッグ・コプロセッサ６は、コプロセッサ・バスＣＰに接続されたデバッグ・ステータス制御レジスタＤＳＣＲを含む。以上で説明したウォッチポイント・レジスタ１６、ブレークポイント・レジスタ１８、制御レジスタ２０、２２、デバッグ・ステータス及び制御レジスタ（ＤＳＣＲ）２８は、全てＡＲＭ ＭＣＲ及びＭＲＣ命令のようなコプロセッサ命令により、書き込み及び読み出しが可能とされる。これは、メイン・プロセッサ４に付加的な回路を追加してこれに関連した潜在性によりクリティカル・パスを低速にすることなく、デバッグ・コプロセッサがコプロセッサ・インターフェースを介して構築されるのを可能にする。
【００２９】
図３はデータ転送レジスタＤＴＲを更に詳細に示す。特に、データ転送レジスタＤＴＲは、２つのレジスタ３０、３２から形成される。第１のレジスタ３０は、スキャン・チェーン入力ｔｄｉを介して書き込み可能であり、かつメイン・プロセッサ４により読み出し可能である。第２のレジスタ３２は、スキャン・チェーン出力ｔｄｏを介して読み出し可能であり、かつメイン・プロセッサ４により書き込み可能である。第１のレジスタ３０及び第２のレジスタ３２は、相互に書き込みの競合が発生し得ない双方向通信チャネルを形成している。
【００３０】
第２のレジスタ３２は、３２ビットのデータを記憶し、かつマルチプレクサ３４により形成された３３番目のビットを有する。マルチプレクサ３４は、コントローラ３６の制御により、４入力のうちの１つを選択するように動作する。第１の入力は、第２のレジスタ３２の主要部からの出力であり、これは、第２のレジスタ３２の主要部の内容を直列にスキャン出力するときに選択される。マルチプレクサ３４に対する他の３入力は、メイン・プロセッサ・クロック信号ｃｌｋ領域において動作しているシステムの一部と、デバッグ・クロック信号ｔｃｋ領域において動作しているシステムの一部との間でハンドシェーキングを取り扱う。特に、これらの信号は、ｔｄｏを介して外部デバッグ回路により読み出せるように調整されて、データ転送レジスタは一杯になる前に外部デバッグ回路に読み出さないようにされ、同様に、データ転送レジスタは正しくロードされるまではメイン・プロセッサ４により読み出さないようにされる。更に、外部デバッグ回路は、更なる試行を行ってデータをデータ転送レジスタＤＴＲにロードする前に、データ転送レジスタＤＴＲ内に配置したデータがメイン・プロセッサ４により使用されたか否かを判断するために、３３番目のビットを読み出すことができる。同一のことは、メイン・プロセッサ４がデータ転送レジスタＤＴＲにデータをロードしようとするのを、外部デバッグ回路により収集される前に、阻止することについてもいえる。更に、ＰｉｐｅＥｍｐｔｙ信号は、メイン・プロセッサ４の命令パイプライン１４が空であり、実行されるべき保留中の命令がないことを判断するために、デバッグ・システムによりポーリング可能な３３番目ビットとしてマルチプレクサ３４により選択されてもよい。
【００３１】
動作において、ラインｔｄｉ上のデータが直列に第１のレジスタ３０にスキャン入力されるに従って、第２のレジスタ３２からのデータ・ビットがラインｔｄｏにスキャン出力される。更に、その逆にデータが第２のレジスタ３２からラインｔｄｏに直列にスキャン出力されるに従って、ラインｔｄｉ上のデータ・ビットが第１のレジスタ３０に入力されることにも云える。従って、データが同時的にデータ転送レジスタＤＴＲから再生され、またこれに書き込まれてもよく、これによってデバッグ・オペレーションの速度が増加する。
【００３２】
図４はスキャン・チェーン・コントローラ１２によりメイン・プロセッサ４に供給されるデバッグ命令の実行を示す。メイン・プロセッサ４はメイン・プロセッサ・クロック信号ｃｌｋにより駆動され続けると共に、スキャン・チェーン・コントローラはデバッグ・クロック信号ｔｃｋにより駆動される。ステップ３８において、ブレークポイント命令の実行、外部的に供給されるブレークポイント信号、又はブレークポイント若しくはウォッチポイント・トリガの検出のように、デバッグ・トリガが発生する。ステップ４０において、デバッグ・トリガは、メイン・プロセッサ４に通常の処理を中断させる。次に、命令パイプライン１４は、ステップ４４、４６から形成されるループにおける１シーケンスのノー・オペレーション命令を実行する前に、ステップ４２において、存在する命令を空にする。ステップ４６は、スキャン・チェーン・コントローラ１２は、（この実施例では、Ｒｕｎ−Ｔｅｓｔ／Ｉｄｌｅステートを通る結果として）命令転送レジスタＩＴＲの内容が命令として命令パイプライン１４に発行されるべきことを示しているか否かを調べる。
【００３３】
ステップ４６を通過する前に、ステップ４８において、デバッグ・クロック信号ｔｃｋの制御により動作しているスキャン・チェーン・システムを含むシステムのデバッグ側は、まず、命令を命令転送レジスタＩＴＲへスキャン入力するために使用される。命令がスキャン入力されたときは、ステップ５０において、キャン・チェーン・コントローラは、Ｒｕｎ／Ｉｄｌｅステートを通って遷移し、システムのメイン・プロセッサ側に対して、命令が命令パイプライン１４を下って発行されるように命令転送レジスタＩＴＲにレディー（ｒｅａｄｙ：実行可能）状態であることを示す。
【００３４】
ステップ５０が完了したときは、ステップ５２が命令を命令転送レジスタＩＴＲから命令パイプライン１４に伝達するように機能し、ステップ５４においてこの命令が実行される。この命令が完了したときは、デバッグ命令完了信号がデバッグ側に返送されので（ステップ５６）、デバッグ側は、命令転送レジスタＩＴＲに配置された命令が完了したこと、更に所望ならば命令を命令転送レジスタＩＴＲに配置できることを知る。ステップ５８において、デバッグ側は、デバッグ命令完了信号の発行を認識し、ステップ６０において、主張した信号をクリアして、命令転送レジスタＩＴＲ内に実行されるのを待機している有効な命令が存在することを表示する。ステップ６２において、メイン・プロセッサ側は、デバッグ側が信号をクリアしたことを認識し、次いで処理をループ４４、４６に戻す。ステップ５６、５８、６０、６２は、異なるクロック領域内で動作する部分間のハンドシェーキング動作を効果的に実行し、これによって周波数差及び未知の位相関係を適合させる。
【００３５】
従って、回路のデバッグ部はデバッグ・クロック信号ｔｃｋにより動作し、一方、回路のメイン・プロセッサ部はメイン・プロセッサ・クロック信号ｃｌｋにより動作し、かつノー・オペレーション命令を実行することにより、及びハンドシェーキング処理により、異なるクロック速度に対処する。
【００３６】
図５はデバッグ命令の多重実行を示す。ステップ６４において、ＡＲＴ ＳＴＣ命令のような命令は、命令転送レジスタＩＴＲにスキャン入力される。ステップ６６において、データ値はデータ転送レジスタＤＴＲにスキャン入力される。ステップ６８において、スキャン・チェーン・コントローラ１２は、Ｒｕｎ−Ｔｅｓｔ／Ｉｄｌｅステートを介して遷移してデバッグ命令発行信号をセットする。メイン・プロセッサ側は、デバッグ命令発行信号のセットを検出し、かつステップ７０において、データ転送レジスタＤＴＲからメモリ（メモリ回路は図示なしの）へデータ値を移動させることにより、命令転送レジスタＩＴＲ（図４を参照すること）に記憶した命令を実行する。この命令が完了したときは、ステップ７２において、これをデバッグ側に知らせ、デバッグ側は更なるデータ値をデータ転送レジスタにスキャン入力する。命令転送レジスタＩＴＲ内に記憶した命令は、外部システムにより変更される必要はなく、従って他の命令の転送に時間が掛からない。次のデータ値が所定位置にあるときは、ステップ７４において、スキャン・チェーン・コントローラ１２は、Ｒｕｎ−Ｔｅｓｔ／Ｉｄｌｅステートを介してを遷移して処理を続ける。ステップ６８及び７０と同一のステップは、ブロック・メモリ転送を効率的に実行するために、多数回実行されてもよい。
【００３７】
図６はデバッグ・コプロセッサ６の一部を他の形式により示す。コプロセッサ命令は、バスＣＰｉｎｓｔｒを介してデバッグ・コプロセッサ６に伝達されて命令レジスタ７６に記録される。ラッチされた命令は、デコーダ７８に伝達され、デコーダ７８は更にデバッグ・コプロセッサ６の種々のレジスタ用及び出力マルチプレクサ８０用の制御信号を発生する。レジスタの書き込みは、ＡＲＭ ＭＣＲ命令に応答して行われ、またレジスタの読み出しは、ＡＲＭ ＭＣＲ命令に応答して行われる。レジスタの書き込みを実行すると、適当なレジスタのレジスタ・エネーブル信号が主張される。レジスタの読み出しを実行しているときは、適当なレジスタ出力がエネーブルされ、かつマルチプレクサ８０は、この出力を選択するように切り換えられる。
【００３８】
レジスタ８２は、システム・コプロセッサＣＰ１５レジスタであり、このレジスタは、デバッグ中にキャッシュ及びＭＭＵオペレーションを実行するために、外部デバッグ回路により使用可能にされている。デバッグ・ステータス制御レジスタ（ＤＳＣＲ）２８は、コプロセッサＣＰ１４レジスタＲ１として取り扱われ、書き込み、及び読み出しが共に可能とされている。命令転送レジスタＩＴＲは、図１に示したスキャン・チェーンのみによって書き込みが可能とされる。データ転送レジスタＤＴＲは、書き込み及び読み出しが可能とされる。データ転送レジスタは、コプロセッサＣＰ１４レジスタＲ５として取り扱われる。
【００３９】
ブレークポイント・レジスタ１８及びウォッチポイント・レジスタ１６は、それぞれ１つが示されている。これらは、それぞれの制御レジスタ２２、２０に関連されている。比較器２４、２６は、これらのレジスタに関連されて、デバッグ・イベント（ｄｅｂｕｇ ｅｖｅｎｔ）信号ＤＥを発生するために用いられる。
【００４０】
図７はスキャン・チェーン・システムの一部を概要的に示す。通常のＪＴＡＧオペレーションに従ってＴＡＰコントローラ８４が設けられている。外部直列データ及び出力は、ラインｔｄｉ及びｔｄｏにより得られる。ＪＴＡＧ命令は、命令レジスタＩＲ８６内に登録されてもよい。特定のスキャン・チェーンは、マルチプレクサ９０、８８に連係して動作するスキャン・チェーン選択レジスタ９２を使用して選択されてもよい。２つの部分のデータ転送レジスタ３０、３２は、相互に単一のスキャン・チェーンを構成している。更に、命令転送レジスタＩＴＲと、デバッグ・ステータス及び制御レジスタＤＳＣＲ２８は、個別的にスキャン・チェーンを形成している。更に、読み出し専用のＩＤＣｏｄｅスキャン・チェーン及びＢｙｐａｓｓスキャン・チェーンも設けられている。
【００４１】
図８は、データ転送レジスタＤＴＲの一部である第２のｗＤＴＲレジスタ３２の制御に係わるハンドシェーキングの一部として、スキャン・チェーン・コントローラ１２とメイン・プロセッサ４との間で伝達される信号のタイミングを１例により示す。図８において、ｓｅｔ ｔｅｒｍ（タームをセット）は、メイン・プロセッサ・クロック信号領域において動作しているメイン・プロセッサ４により制御されており、またｃｌｅａｒ ｔｅｒｍ（タームをクリア）は、デバッグ・クロック信号領域において動作しているスキャン・チェーン・コントローラ１２により制御されている。更に詳細には、ｓｅｔ ｔｅｒｍ及びｃｌｅａｒ ｔｅｒｍは、これら自身４ステートのステート・マシン（ｓｔａｔｅ ｍａｃｈｉｎｅ）によりそれぞれ制御されている（異なるそれらのステートは、図８に２ディジットの２進数により表されている）。
【００４２】
動作において、メイン・プロセッサ４は、まずｗＤＴＲレジスタ３２に書き込み、ｓｅｔ ｔｅｒｍをローからハイに遷移させて、ｗＤＴＲフルを主張させる（ここでは、ＤＴＲレジスタの３３番目ビットとして、ｗＤＴＲフル信号をマルチプレクサ３４により選択することができる）。ｗＤＴＲフル・インジケータの特定バージョンは、ｔｃｋ領域のみに存在する。外部デバッグ回路は、ＤＴＲレジスタの３３番目ビットをポーリングして収集すべきデータが存在することを示すこの遷移について監視する。更に、メイン・プロセッサ４がそのｃｌｋ領域において使用するためのインジケータも存在する。
【００４３】
そこで、デバッグ側は、ｗＤＴＲレジスタ３２を読み出し、これが完了すると、ｃｌｅａｒ ｔｅｒｍがローからハイへ遷移してｓｅｔ ｔｅｒｍステート・マシンに対してデータを読み出したことを表示する。ｃｌｅａｒ ｔｅｒｍにおける遷移は、シンクロナイザを介してｓｅｔ ｔｅｒｍステート・マシンに伝達され、これがｓｅｔ ｔｅｒｍをハイからローに遷移させることにより応答して、ｃｌｅａｒ ｔｅｒｍにおける変化を認識したことをｃｌｅａｒ ｔｅｒｍステート・マシンに対して表示する。ハイからローへのｓｅｔ ｔｅｒｍにおける遷移は、シンクロナイザによりｃｌｅａｒ ｔｅｒｍステート・マシンへ逆に伝達され、ｗＤＴＲレジスタ３２を読み出したという情報が肯定応答されたときに、このステート・マシンがｃｌｅａｒ ｔｅｒｍをハイからローへ遷移させる。ハイからローへのクリア信号の遷移は、最終的にシンクロナイザにより、ｃｌｅａｒ ｔｅｒｍステート・マシンからｓｅｔ ｔｅｒｍステート・マシンへ伝達されて、ｓｅｔ ｔｅｒｍステート・マシンをリセットさせるので、所望のときは他の値をｗＤＴＲレジスタ３２に書き込めるようにメイン・プロセッサ４に対してシステムがレディーとなる。
【００４４】
図３に示すｒＤＴＲＦｕｌｌインジケータは、ｒＤＴＲレジスタ３０に関連し、かつｔｃｋ及びｃｌｋ信号が交換されると共に、読み出し及び書き込みが交換されると同様に作成されてもよい。
【００４５】
図９は、（デバッグＲＥＳＴＡＲＴ命令に応答して）図４及び図５に示すように動作しているデバッグ・ステートからメイン・プロセッサ４を再起動させるときに、メイン・プロセッサ４とデバッグ・システムとの間で伝達されるハンドシェーキング信号のタイミングを示す。
【００４６】
ＲｅｓｔａｒｔＣｏｒｅ信号はｔｃｋ領域に存在し、ＤｂｇＩｎＤｅｂｕｇ及びＣｏｒｅＩｎＤｅｂｕｇ信号はｃｌｋ領域に存在する。再起動オペレーションにおける第１ステップとして、デバッグ制御ロジックは、ＣｏｒｅＲｅｓｔａｒｔｅｄビットを０にセットし、かつＲｅｓｔａｒｔＣｏｒｅ信号をローからハイに遷移することにより、ＲＥＳＡＲＴ信号に対して応答する。ＲｅｓｔａｒｔＣｏｒｅにおけるこの遷移は、シンクロナイザを介してメイン・プロセッサ４に伝達され、メイン・プロセッサ４はＤｂｇＩｎＤｅｂｕｇ信号をハイからローへ遷移させることにより応答する。このビットは、続いてシンクロナイザを通ってデバッグ制御ロジックに逆に伝達され、デバッグ制御ロジックではＣｏｒｅＲｅｓｔａｒｔｅｄ信号を非主張にする。ＣｏｒｅＲｅｓｔａｒｔｅｄビットは、コアが再起動されたことを確認するために外部デバッグ回路によりポーリングされる。ＲｅｓｔａｒｔＣｏｒｅ信号における遷移は、シンクロナイザを介してメイン・プロセッサ４に伝達され、メイン・プロセッサ４はＣｏｒｅＩｎＤｅｂｕｇ信号をハイからローに遷移させることにより応答して、メイン・プロセッサ４をデバッグ・ステートから通常ステートに遷移する。
【００４７】
図８及び９は、メイン・プロセッサ・クロック信号領域において動作しているメイン・プロセッサ側とデバッグ・クロック信号において動作しているデバッグ側との間で伝達されるハンドシェーキング制御信号の２例を示す。同様にして、更なる制御信号間のハンドシェーキングを取り扱うことができる。
【００４８】
以上で説明したデバッグ機構の更に詳細な図は、概要的にＡＲＭ１０マイクロプロセッサ及びＡＲＭマイクロプロセッサのアーキテクチャーに関係する以下のマイクロアーキテクチャー仕様により提供される。
【００４９】
１．０ 基本目的
１）多数の実施を通して展開するＡＲＭプロセッサに対して将来の証明デバッグ・インターフェースを提供する、
２）ＪＴＡＧハードウェア及び対象に基づくソフトウェアからハードウェアデバッグ設備へのアクセスを提供する。
【００５０】
２．０ 背景
ＡＲＭ１０内のデバッグ・ロジックは、イン・サーキット・エミュレータに見られるものと同様の機能をサポートする能力、即ちブレークポイント及びウォッチポイントを設定する能力をユーザに提供して、プロセッサ及びシステム・ステートを点検して変更し、かつ関係するポイント周辺のプロセッサ活動のトレースを調べる。通常、ホスト・コンピュータ上のソフトウェアは、デバッガに対するインターフェースとして機能して、オン・チップ・ロジックが要求する特定のプロトコルからエンド・ユーザを完全に取り除く。
【００５１】
ＡＲＭ１０は、ＡＲＭ７及びＡＲＭ９により提供されるデバッグ・インターフェースをクリーン・アップするための機会である。即ち、未使用の機能を削除し、かつ新しい機能を付加することである。ＡＲＭ１０のパイプラインの複雑性のために、命令をパイプラインに詰め込むＡＲＭ７及びＡＲＭ９の方法は、２つの損失がある。即ち、ＩＣＥｍａｎソフトウェアをより複雑化し、またＡＲＭ１０が避けなければならないハードウェア・クリティカル・パスの包含がある。
【００５２】
ＡＲＭ１０にマスク・レジスタ、チェーン又はレンジ機能は存在しない。データに依存するウォッチポイントやブレークポイントも存在しない。しかしながら、ＡＲＭ１０は、ブレークポイント命令を実施して、ごく一般的な使用をデータ依存性に置き換え、これが命令ストリームにおけるブレークポイントに対するユーザ指定命令を認識させる。われわれはより実際的なブレークポイント・レジスタを利用することによりマスク・レジスタを削除した。
【００５３】
３．０ ＡＲＭ１０デバッグの使用
ＡＲＭ１０についてのデバッグ及び将来マシン（以下単にＡＲＭ１０デバッグと呼ぶ）は、コプロセッサ１４（ＣＰ１４）周辺に集められている。対象について実行されるソフトウェア、即ちデバッグ・モニタ、又はオペレーティング・システム・デバッグ（以下デバッグ・タスクと呼ぶ）は、単にＣＰ１４レジスタに書き込むことによりデバッグ・ハードウェア機能をアクセスすることができる。レジスタ・ブレークポイントは、例外を発生させることができ、対象ハンドラーがレジスタ・ブレークポイントをヒットしたときに制御権を取獲得できるようにする。デバッグ機能は、対象上のソフトウェア及びＪＴＡＧポートの両者を通ってアクセスされる。ＪＴＡＧプログラミングは、１度に１プロセッサ命令を供給することにより実行され、オプションによりデータ・バーストが続く。しかし、デバッグ・ステップに入る、抜け出す及び実行するためのインターフェースは、はるかに明確かつより正確に定義される。
【００５４】
３．１コプロセッサ１４
３．１．１ ＣＰ１４インターフェース
コプロセッサ・インターフェースは、ＡＲＭコアとデバッガとの間の共通機構として動作し、ＣＰ１４及びＣＰ１５の両者のアクセスは、このブロックにより処理される。このコプロセッサ・インターフェースは、ＶＦＰコプロセッサ・インターフェースと同様であるが、しかし少数の制御信号及び狭帯域バスを有する。このインターフェースは、次の信号を含む。
入力： 説明：
ＡＳＴＯＰＣＰＥ 実行中のＡＲＭストール（ｓｔａｌｌ）を表示
ＡＳＴＯＰＣＰＤ デコード中のＡＲＭストールを表示
ＡＣＡＮＣＥＬＣＰ ＣＰでの命令を取り消す
ＡＦＵＬＳＨＣＰ コプロセッサ・パイプラインをフラッシュ
ＬＤＣＭＣＲＤＡＴＡ ＡＲＭコアからの入力データを含むバス
ＣＰＩＮＳＴＲ［３１：０］ ＡＲＭからコプロセッサへの命令
ＣＰＳＵＰＥＲ コプロセッサ・スーパバイザ・モード
ＣＰＬＳＬＥＮ ＬＳＵに対する長さインジケータ
ＣＰＬＳＳＷＡＰ ＬＳＵに対するインジケータを入れ換え
ＣＰＩＮＳＴＲＶ ＣＰに対する有効命令を表示する
ＣＰＲＳＴ コプロセッサのリセット
ＣＰＣＬＫ コプロセッサ・クロック
出力：
ＣＰＢＵＳＹＤ デコードにおけるビジー待機
ＣＰＢＵＳＹＥ 実行中のビジー待機
ＣＰ１５ＳＥＲＩＡＬＩＺＥ コアにデコードにおける命令を強制的にホールドＣＰＢＯＵＮＣＥＥ ＣＰは命令を拒否
ＳＴＣＭＲＣＤＡＴＡ バスはＡＲＭコアに対しての出力データを含む
【００５５】
３．１．２ＣＰ１４レジスタ／マップ
全てのデバッグ・ステートはレジスタとしてＣＰ１４にマッピングされる。３ＣＰ１４レジスタ（Ｒ０、Ｒ１、Ｒ５）は、特権モードにおいてデバッグ・タスクによりアクセス可能とされ、また４レジスタ（Ｒ０、Ｒ１、Ｒ４、Ｒ５）は、スキャン・チェーンとしてアクセス可能である。残りのレジスタは、特権モードでのみデバッグ・タスクからアクセス可能である。空間は１６ブレークポイント及び１６ウォッチポイントまで確保されている。特定の実施計画を２から１６までの任意の数で実施することができる。ＡＲＭ１０のときは、６命令側ブレークポイント及び２データ側ウォッチポイントが存在する。
【００５６】
ブレークポイント・レジスタは、特権モードにおいてリセットから起動し、ディセーブルされる。Ｄｅｂｕｇ ＩＤ Ｒｅｇｉｓｔｅｒ（Ｒ０）は読み出し専用であることに注意すべきである。更に、ブレークポイント及びウォッチポイント・レジスタにおける一致ビットは、プログラマが適当なビットをセットすることにより１フィールド（例えば、サイズ、スーパバイザ／ユーザ）を指定できるようにする符号化を含むことも認識すべきである。ユーザは、一致についてフィールドが考慮されていないときは、ビットを全て１にセットする必要がある。
【００５７】
デバッギングのディセーブルには、２つの方法がある。ＤＳＣＲにおけるＧｌｏｂａｌ Ｅｎａｂｌｅビットは、ソフトウェアを介して全てデバッグ機能をエネーブル又はディセーブルするために使用される。このビットは、リセットによりクリアされ、これは、全てのデバッグ機能がディセーブルされることを意味する。全ての外部デバッグ要求はコアにより無視され、またＢＫＰＴ命令はノー・オペレーションとして処理される。このモードの目的は、オペレーティング・システムがタスク・スイッチング・シーケンスの一部として個々のタスクについてのデバッグ処理を速やかにエネーブル及びディセーブル可能にすることである。加えて、ＤＢＧＥＮピンは、ＡＲＭ１０のデバッグ機能をディセーブル可能にする。デバッグ処理を必要としないときにのみ、この信号をＬＯＷに接続する必要がある。
【００５８】
多数のレジスタをサポートするために、ＣＲｍ及びｏｐｃｏｄｅ２フィールドは、デバッグ・レジスタ番号を符号化するために使用される。ただし、このレジスタ番号は、｛ｏｐｃｏｄｅ２，ＣＲｍ｝である。
【００５９】
Ｒ０：Ｒｅｂｕｇ ＩＤ Ｒｅｇｉｓｔｅｒ
ＤＤＩＲ［３１：２４］ ＣＰ１５ Ｒ０のような設計者コード
ＤＤＩＲ［２３：２０］ ゼロ
ＤＤＩＲ［１９：１６］ デバッグ・アーキテクチャーのバージョン、ＡＲＭ１０＝０ｂ０００
ＤＤＩＲ［１５：１２］ 実施したレジスタ・ブレークポイント数
ＤＤＩＲ［１１：１８］ 実施したウォッチポイント数
ＤＤＩＲ［７：４］ ゼロ
ＤＤＩＲ［３：０］ 改訂番号
【００６０】
このビットは、ｗＤＴＲバッファがデータの書き込みに対してレディーのときにセットされる。ゼロは、デバッガによりデータが未だ読み出されていないことを示す。
ＤＳＣＲ［７］ ｒＤＴＲバッファ・フル−読み出し専用
このビットは、通常、ＪＴＡＧデバッガがこのバッファにデータを書き込んだ結果としてコア用のｒＤＴＲに読み出すデータが存在するときに、セットされる。ゼロはバッファ内に読み出すデータがないことを示す。
ＤＳＣＲ［１５：８］ 予備
ＤＳＣＲ［１６］ ベクトル・トラップ・エネーブル（Ｖｅｃｔｏｒ Ｔｒａｐ Ｅｎａｂｌｅ）−リセット
ｎＴＲＳＴ＝０又はＴＡＰコントローラがリセット状態のときはリセットされる。
ＤＳＣＲ［１７］ ベクトル・トラップ・エネーブル−未定義命令
ｎＴＲＳＴ＝０又はＴＡＰコントローラがリセット状態のときはリセットされる。
ＤＳＣＲ［１８］ ベクトル・トラップ・エネーブル−ＳＷＩ
ｎＴＲＳＴ＝０又はＴＡＰコントローラがリセット状態のときはリセットされる。
ＤＳＣＲ［１９］ ベクトル・トラップ・エネーブル−フェッチ中断（ａｂｏｒｔ）
ｎＴＲＳＴ＝０又はＴＡＰコントローラがリセット状態のときはリセットされる。
ＤＳＣＲ［２０］ ベクトル・トラップ・エネーブル−データ中断
ｎＴＲＳＴ＝０又はＴＡＰコントローラがリセット状態のときはリセットされる。
ＤＳＣＲ［２１］ 予備
ＤＳＣＲ［２２］ ベクトル・トラップ・エネーブル−ＩＲＱ
ｎＴＲＳＴ＝０又はＴＡＰコントローラがリセット状態のときはリセットされる。
ＤＳＣＲ［２３］ ベクトル・トラップ・エネーブル−ＦＩＱ
ｎＴＲＳＴ＝０又はＴＡＰコントローラがリセット状態のときはリセットされる。
ＤＳＣＲ［３０：２４］ 予備
ＤＳＣＲ［３１］ グローバル・デバッグ・エネーブル（Ｇｌｏｂａｌ Ｄｅｂｕｇ Ｅｎａｂｌｅ）−システム・リセットによりリセットされる
０＝全てのデバッグ処理機能（ブレークポイント、ウォッチポイント等）をディセーブルする。
１＝全てのデバッグ処理機能をエネーブルする。
注意：ベクトル捕捉はブレークポイントよりも高い優先順位を有する。
【００６１】
Ｒ２−Ｒ４：予備
Ｒ５：データ転送レジスタ（Ｄａｔａ Ｔｒａｎｓｆｅｒ Ｒｅｇｉｓｔｅｒ）
ＤＴＲ［３１：０］ データ
（注意：ＤＴＲは、物理的に個別的な２レジスタ、即ちｒＤＴＲ（読み出し）及びｗＤＴＲ（書き込み）からなる。これらの使用の説明については３．２．７及び３．２．１０を参照すべきである。）
Ｒ６−Ｒ６３：予備
Ｒ６４−Ｒ７９：レジスタ・ブレークポイント（Ｒｅｇｉｓｔｅｒ Ｂｒｅａｋｐｏｉｎｔ）値
【００６２】
ＢＶ［３１：０］ レジスタ・ブレークポイント値
Ｒ８０−Ｒ９６：レジスタ・ブレークポイント制御レジスタ（Ｒｅｇｉｓｔｅｒ Ｂｒｅａｋｐｏｉｎｔ Ｃｏｎｔｒｏｌ Ｒｅｇｉｓｔｅｒｓ）
ＢＣＲ［０］ システム・リセットによるクリアをエネーブル
０＝レジスタをディセーブル
１＝レジスタをエネーブル
ＢＣＲ［２：１］ スーパバイザ（Ｔｒａｎｓ） アクセス
００−予備
１０−特権付き
０１−ユーザ
１１−不定
ＢＣＲ［４：３］ サム（Ｔｈｕｍｂ）モード
００−予備
１０−ＡＲＭ命令
０１−サム命令
１１−不定
Ｒ９６−Ｒ１１１ ウォッチポイント値
ＷＶ［３１：０］ ウォッチポイント値
Ｒ１１２−Ｒ１２７：ウォッチポイント制御レジスタ
ＷＣＲ［０］ エネーブル
０＝レジスタをディセーブル（システム・リセットによりクリア）
１＝レジスタをエネーブル
ＷＣＲ［２：１］ スーパバイザ（Ｔｒａｎｓ）
００−予備
１０−特権付き
０１−ユーザ
１１−不定
ＷＣＲ［４：３］ ロード／ストア／不定
００−予備
１０−ロード
０１−ストア（Ｓｔｏｒｅ）
１１−不定
ＷＣＲ［７：５］ バイト／ハーフワード／ワード／不定サイズ
０００−予備
００１−バイト
０１０−ハーフワード
０１１−バイト又はハーフワード
１００−ワード
１０１−ワード又はバイト
１１０−ワード又はハーフワード
１１１−任意のサイズ
ＷＣＲ［８］ 予備
ＷＣＲ［１０：９］ Ａｄｄｒ［１：０］へのアドレス・マスク
０＝比較にビットを含む
１＝比較にビットを除外
ＷＣＲ［１１］ 予備
【００６３】
３．１．３ ＣＰ１４命令
下記はＡＲＭ１０におけるＣＰ１４用の適正命令専用である。ＬＤＣ及びＳＴＣ命令は、ＤＴＲレジスタに対してのみ有効である。他の全ての命令は、拒絶（ｂｏｕｎｃｅ）される。
【００６４】
【表１】
【００６５】
３．２ デバッグに対するハードウェア・インターフェース
３．２．１ ホールト（Ｈａｌｔ）・モードへの進行及び抜け出し
ホールト・モードは、ＤＳＣＲの１〜３０ビットを書き込むことによりエネーブルされ、ＪＴＡＧデバッガによってのみ実行可能にされる。このモードがエネーブルにされた場合に、下記の事象のうちの１つが発生したときは、プロセッサはホールトになる（ソフトウェアにおいて例外となることに対比される）。
ａ）ＥＤＢＧＲＱを主張
ｂ）ＪＴＡＧインターフェースを介してＨＡＬＴ命令をスキャン入力した。ＴＡＰコントローラは、コアにＨＡＬＴコマンドを発行するためにＲｕｎ／Ｉｄｌｅを伝達する必要がある。
ｃ）例外が発生し、かつ対応するベクトル・トラップ・エネーブル・ビットをセット
ｄ）レジスタ・ブレークポイントをヒット
ｅ）ウォッチポイントをヒット
ｆ）ＢＫＰＴ命令がＡＲＭパイプラインの実行段に到達
【００６６】
デバッグ・ステートに入ると、ＤＳＣＲにおけるコア・ホールト（Ｃｏｒｅ Ｈａｌｔｅｄ）ビットがセットされる。デバッガは、推定により、このビットがハイになるまで、Ｃａｐｔｕｒｅ−ＤＲ及びＳｈｉｆｔ−ＤＲを通過することによりＤＳＣＲをポーリングする。この時点において、デバッガは、なぜコアはホールトしたのかを判断し、かつマシン・ステートを保存する。ＭＳＲ命令はモードを変更し、マシンに全てバンク済みのレジスタに対するアクセスを獲得をするために使用されてもよい。デバッグ・ステートにある間は、ＰＣは増加されず、外部割り込みは無視され、かつ全ての命令は、命令転送レジスタ（Ｉｎｓｔｒｕｃｔｉｏｎ Ｔｒａｎｓｆｅｒ Ｒｅｇｉｓｔｅｒ）から読み出される（スキャン・チェーン４）。
【００６７】
デバッグ・ステートからの抜け出しは、再起動（ＲＥＳＴＡＲＴ）命令においてＪＴＡＧインターフェースを介してスキャン入力することにより、実行される。デバッガは、再起動する前にコアがデバッグ・ステートに入る方法に従ってＰＣを調整する。下記の表は、コアが各場合についてホールトする時点でＰＣの値を表示する。
【００６８】
【表２】
【００６９】
ステート・マシンがＲｕｎ−Ｔｅｓｔ／Ｉｄｌｅステートに入ると、通常の動作が再開する。ステート・マシンがＲｕｎ−Ｔｅｓｔ／Ｉｄｌｅとなるまで待機する遅延は、マイクロプロセッサ・システムにおける他の装置に、直接影響することなく、条件を設定可能にする。全てのプロセッサは、Ｒｕｎ−Ｔｅｓｔ／Ｉｄｌｅステートに入ると、一斉にオペレーションを再開する。ＲＥＳＴＡＲＴシーケンスを完了すると、コア再起動（Ｃｏｒｅ Ｒｅｓｔａｒｔｅｄ）ビットがセットされる。
【００７０】
コアは、ＲＥＳＴＡＲＴコマンドを発行する前に、「命令完了」（Ｉｎｓｔｒｕｃｔｉｏｎ Ｃｏｍｐｌｅｔｅ）ビット（ｗＤＴＲ［０］）をポーリングして最後の命令を何らの問題（可能とする中断など）なしに完了したことを確認する必要があることに注意すべきである。デバッガは、コアにＲＥＳＴＡＲＴ命令を発行した後に、何か他のことを実行する前は、ポーリングして実際に再起動したことを調べる必要がある。デバッグ・ロジックにはシンクロナイザ及びハンドシェク・ラインが存在し、デバッグ・ロジックはこれらのハンドシェーキング・ラインをクリアできるようにクロック（特に、ＴＣＫ）を備えている必要がある。デバッグ・ロジックがＤｂｄＲｅｓｔａｒｔラインをクリアする機会が来る前に、クロックをターン・オフすれば、コアはデバッグ・ステートにとどまって再度起動しない。コア再起動ビットを読み出す操作は、必要なラインをクリアするのに十分なクロックを供給する。
【００７１】
３．２．２ ＪＴＡＧポート及びテスト・データ・レジスタ
ロジックのＪＴＡＧ部は、ＩＥＥＥ１１４９．１インターフェースを実施し、かつ装置ＩＤレジスタ、バイパス・レジスタ、及び４ビットの命令レジスタをサポートする。加えて、下記の公開命令がサポートされる。
【００７２】
【表３】
【００７３】
デバッグ・レジスタに対するアクセスは、ソフトウェア（ＭＣＲ命令による）又はＪＴＡＧポートを通して得られる。ハードウェア・デバッグ機構は、基本的に、ＡＲＭ７／ＡＲＭ９と同様であるが、しかしＡＲＭ１０デバッグは全てのクロッキングを隠し、かつデバッガからパイプラインの深さを発行する。
【００７４】
ＪＴＡＧ（Ｒ１、Ｒ５）を介してアクセス可能なＣＰ１４内のレジスタは、ＥＸＴＥＳＴ命令を使用して書き込まれる。レジスタＲ０、Ｒ１及びＲ５は、ＩＮＴＥＳＴ又はＥＸＴＥＳＴ命令により読み出される。これは、ＩＮＳＴ命令のみが使用され、かつチェーンにおけるｒ／ｗビットが実行されるべきオペレーションを決定した点でＡＲＭ９と異なる。
【００７５】
３．２．２．１ バイパス・レジスタ
目的：ＴＤＩとＴＤＯとの間にパスを設けることによりスキャン・テスト中の装置をバイパスする。
長さ：１ビット
動作モード：バイパス命令が命令レジスタにおける現在命令であるときは、直列データがＳｈｉｆｔ−ＤＲステートにおける１ＴＣＫサイクルの遅延により、ＴＤＩからＴＤＯへ転送される。バイパス・レジスタからの並列出力は存在しない。ロジック０は、Ｃａｐｕｔｕｒｅ−ＤＲ（ＤＲの捕捉）ステートにおいてバイパス・レジスタの並列入力からロードされる。
順序：ＴＤＩ−［０］−ＴＤ０
【００７６】
３．２．２．２ 装置ＩＤ Ｃｏｄｅ レジスタ
目的：ＡＲＭ７Ｔ及びＡＲＭ９ＴからＡＲＭ１０を識別するために、ＴＡＰコントローラＩＤが固有なので、Ｍｕｌｔｉ−ＩＣＥがどのプロセッサに接続されているのかを容易に調べることができる。このＩＤレジスタは、チップの縁に経路設定されるので、相手側はピンをハイ値又はロー値へ接続することにより、これら自身のＩＤ番号を作成することができる。ＡＲＭ１０２００用の総称ＩＤは、初期的には、０ｘ０１０２０Ｆ０Ｆとなる。全ての相手側−特定装置は、下記形式のＩＤ番号により識別される。
バージョン 部品番号 製造者ＩＤ
ＬＳＢ
［３１：２８］ ［２７：１２］ ［１１：１］ １
【００７７】
長さ：３２ビット
動作モード：ＩＤＣＯＤＥ命令が現在値であるときは、ＴＤＩ及びＴＤＯとの間の直列パスとして、ＩＤレジスタが選択される。ＩＤレジスタからの並列出力は存在しない。３２ビットのＩＤコードは、Ｃａｐｔｕｒｅ−ＤＲステート中に並列入力からレジスタにロードされる。
順序：ＴＤＩ−［３１］［３０］．．．［１］［０］−ＴＤ０
【００７８】
３．２．２．３ 命令レジスタ
目的：現在のＴＡＰ命令を変更する
長さ：４ビット
動作モード：Ｓｈｉｆｔ−ＤＲステートのときは、命令レジスタがＴＤＩとＴＤＯとの間に直列パスとして選択される。Ｃａｐｔｕｒｅ−ＤＲステートでは、０００１二進値がこのレジスタにロードされる。これは、Ｓｈｉｆｔ−Ｉ中に（最下位ビットが最初に）シフト出力され、一方新しい命令が（最下位ビットが最初に）スキャン入力される。Ｕｐｄａｔｅ−ＩＲステートでは、命令レジスタ内の値が現在命令となる。リセットにより、ＩＤＣＯＤＥが現在命令となる。
順序：ＴＤＩ−［３］［２］［１］［０］−ＴＤ０
【００７９】
３．２．２．４ スキャン・チェーン選択（Ｓｃａｎ Ｃｈａｉｎ Ｓｅｌｅｃｔ）レジスタ
目的：現在の活性スキャン・チェーンを変更する。
長さ：５ビット
動作モード：現在命令としてＳＣＡＮ Ｎを選択した後、Ｓｈｉｆｔ−ＤＲステートのときは、ＴＤＩとＴＤＯとの間の直列パスとしてスキャン・チェーン選択レジスタが選択される。Ｃａｐｔｕｒｅ−ＤＲステートでは、１００００二進値がこのレジスタにロードされる。Ｓｈｉｆｔ−ＤＲでは、これが（最下位ビットが最初に）シフト出力され、同時に、（最下位ビットを最初にして）新しい値がシフト入力される。Ｕｐｄａｔｅ−ＤＲステートでは、レジスタ内の値は、レジスタにおける値がスキャン・チェーンを選択して現在活性のスキャン・チェーンになる。ＩＮＴＥＳＴのような更なる全ての命令は、このスキャン・チェーンに適用される。現在の選択されたスキャン・チェーンは、ＳＣＡＮ Ｎ命令が実行されたとき、又はリセットが発生したときにのみ、変更される。リセットにより、スキャン・チェーン３が活性なスキャン・チェーンとして選択される。現在の選択されたスキャン・チェーン数は、ＳＣＲＥＧ［４：０］出力バスに反映される。ＴＡＰコントローラは、ＡＲＭ１０２０マイクロセル内のものに加えて、外部スキャン・チェーンを駆動するために使用されてもよい。外部スキャン・チェーンは、これに対して番号及び制御信号が割り付けられる必要があり、ＳＣＲＥＧ［４：０］、ＩＲ［３：０］、ＴＡＰＳＭ［３：０］、及びＴＣＫから導き出されてもよい。
順序：ＴＤＩ−［４］［３］［２］［１］［０］−ＴＤ０
【００８０】
３．２．２．５ Ｓｃａｎ Ｃｈａｉｎ ０
目的：デバッグ。
長さ：３２ビット
このＳｃａｎ Ｃｈａｉｎは、ＣＰ１４ Ｒｅｇｉｓｔｅｒ ０、ＤｅｂｕｇＩＤ Ｒｅｇｉｓｔｅｒである。
順序：ＴＤＩ−［３１］［３０］．．．［１］［０］−ＴＤ０
【００８１】
３．２．２．６ Ｓｃａｎ Ｃｈａｉｎ １
目的：デバッグ。
長さ：３２ビット
このＳｃａｎ Ｃｈａｉｎは、ＣＰ１４ Ｒｅｇｉｓｔｅｒ １、ＤＳＣＲである。ＤＳＣＲ［１５：０］のみが読み出されることに注意すべきである。下記のビットは、Ｃｈａｉｎ １に対して定義される。
ＤＳＣ［０］ Ｃｏｒｅ Ｈａｌｔｅｄ−読み出し専用
ＤＳＣ［１］ Ｃｏｒｅ Ｒｅｓｔａｒｔｅｄ−読み出し専用
ＤＳＣ［４：２］ デバッグ・エントリ方法−読み出し専用
０００ ＪＴＡＧ ＨＡＬＴ命令が発生
００１ レジスタ・ブレークポイントが発生
０１０ ウォッチポイントが発生
０１１ ＢＫＰＴ命令が発生
１００ 外部デバッグ要求が発生
１０１ ベクトル捕捉が発生
１１０，１１１ 予備
ＤＳＣＲ［５］ 過去にしばしば破棄が発生−ＭＣＲによってのみ書き込み可能
ＭＣＲ このビットは容易ではない。これはＭＣＲによりＭＳＣＲにクリアされ、ここで、このビットは０である。
ｎＴＲＳＴ＝０のとき、又はＴＡＰコントローラがリセット・ステートときはリセット
ＤＳＣＲ［６］ ｗＤＴＲバッファが空−読み出し専用
このビットは、ｗＤＴＲバッファが空であり、コアが更にデータが書き込めることを意味するコアのインジケータである。これは、ＪＴＡＧデバッガがＥＸＴＥＳＴによりＣａｐｔｕｒｅＤＲを通ることによりＤＴＲをポーリングするのか否かを調べる反転ビットである。ＪＴＡＧ信号とコア信号との間のタイミングは異なっているので、デバッガは、このビットを使用してｗＤＴＲが空であるか又はフルであるかを判断してはならない。
ＤＳＣＲ［７］ ｒＤＴＲバッファ・フル−読み出し専用
このビットは、ｒＤＴＲバッファがフルであり、デバッガがこれにデータが書き込んだことを意味するコアのインジケータである。これは、ＪＴＡＧデバッガがＩＮＴＥＳＴによりＣａｐｔｕｒｅＤＲを通ることにより、ＤＴＲをポーリングするのか否かを調べる反転ビットである。ＪＴＡＧ信号とコア信号との間のタイミングは異なっているので、デバッガはこのビットを使用してｗＤＴＲが空であるか又はフルであるかを判断してはならない。
ＤＳＣＲ［１５：８］ 予備
ＤＳＣＲ［１６］ ベクトル・トラップ・エネーブル−リセット−読み出し専用
ｎＴＲＳＴ＝０のときはリセット、ＴＡＰコントローラがリセット・ステートのときは、リセット
ＤＳＣＲ［１７］ ベクトル・トラップ・エネーブル−未定義命令−読み出し専用
ｎＴＲＳＴ＝０のときはリセット、ＴＡＰコントローラがリセット・ステートのときは、リセット
ＤＳＣＲ［１８］ ベクトル・トラップ・エネーブル−ＳＷＩ−読み出し専用ｎＴＲＳＴ＝０又はＴＡＰコントローラがリセット・ステートのときは、リセット
ＤＳＣＲ［１９］ ベクトル・トラップ・エネーブル−プリフェッチ中断（Ｐｒｅｆｅｔｃｈ Ａｂｏｒｔ）−読み出し専用
ｎＴＲＳＴ＝０又はＴＡＰコントローラがリセット・ステートのときは、リセット
ＤＳＣＲ［２０］ ベクトル・トラップ・エネーブル−データ中断−読み出し専用
ｎＴＲＳＴ＝０又はＴＡＰコントローラがリセット・ステートのときは、リセット
ＤＳＣＲ［２１］ ベクトル・トラップ・エネーブル−予備
ＤＳＣＲ［２２］ ベクトル・トラップ・エネーブル−ＩＲＱ−読み出し専用
ｎＴＲＳＴ＝０又はＴＡＰコントローラがリセット・ステートのときは、リセット
ＤＳＣＲ［２３］ ベクトル・トラップ・エネーブル−ＦＩＱ−読み出し専用
ｎＴＲＳＴ＝０又はＴＡＰコントローラがリセット・ステートのときは、リセット
ＤＳＣＲ［２６：２４］ 予備
ＤＳＣＲ［２７］ Ｃｏｍｍｓチャネル・モード
０＝Ｃｏｍｍｓチャネル不作動
１＝Ｃｏｍｍｓチャネル作動
ｎＴＲＳＴ＝０又はＴＡＰコントローラがリセット・ステートのときは、リセット
ＤＳＣＲ［２８］ サム・モード・インジケータ（５．０項を参照のこと）
ＤＳＣＲ［２９］ ＩＴＲ選択において命令を実行
０＝ディセーブル
１＝ＪＴＡＧ状態マシンがＲｕｎ−Ｔｅｓｔ／Ｉｄｌｅを通過するときは、ＩＴＲにおける命令をプリフェッチ・ユニットに送出
ｎＴＲＳＴ＝０のとき、又は、ＴＡＰコントローラがリセット・ステートのときは、セット
ＤＳＣＲ［３０］ Ｈａｌｔ／Ｍｏｎｉｔｏｒ（ホールト／モニタ）モード選択
０＝モニタ・モードをエネーブ
１＝ホールト・モードをエネーブル
ｎＴＲＳＴ＝０又はＴＡＰコントローラがリセット・ステートのときは、リセット
ＤＳＣＲ［３１］ グローバル・デバッグ・エネーブル（Ｇｌｏｂａｌ Ｄｅｂｕｇ Ｅｎａｂｌｅ）−システム・リセットによりクリア
０＝全てのデバッグ処理機能（ブレークポイント、ウォッチポイント等）をディセーブルにする。
１＝全てのデバッグ処理機能をエネーブルにする。
ｎＲＥＳＥＴ＝０のときは、リセット（コアのリセット・ライン）
これらのビットがコア用で、デバッガ用でないＤＳＣＲを反映しているので、通信チャネル・ビット、ｒＤＴＲフル及びｗＤＴＲ空は、デバッガから見えるものの反転であることに注意すべきである。
順序：ＴＤＩ−［３１］［３０］．．．［１］［０］−ＴＤ０
【００８２】
３．２．２．７ Ｓｃａｎ Ｃｈａｉｎ ２
目的：デバッグ
長さ：６５ビット
このスキャン・チェーンは、ＣＰ１４レジスタ４及び５の組み合わせである。レジスタ４内の命令完了（Ｉｎｓｔｒｕｃｔｉｏｎ Ｃｏｍｐｌｅｔｅ）ビットは、このチェーンに含まれないことに注意すべきである。これは、チェーン４にのみ現れる。
順序：ＴＤＩ−Ｒｅｇ４［３２］Ｒｅｇ４［３１］．．．Ｒｅｇ４［１］Ｒｅｇ５［３２］Ｒｅｇ５［３１］．．．Ｒｅｇ５［０］−ＴＤ０
【００８３】
１．２．２．８ Ｓｃａｎ Ｃｈａｉｎ ３
目的：外部境界スキャン・テストに使用できる。装置間テスト（ｉｎｔｅｒ−ｄｅｖｉｃｅ ｔｅｓｔｉｎｇ ：ＥＸＴＥＳＴ）及びコアのテスト（ＩＮＴＥＳＴ）に使用される。
長さ：不定
【００８４】
３．２．２．９ Ｓｃａｎ Ｃｈａｉｎ ４
目的：デバッグ
長さ：３３ビット
このスキャン・チェーンは、命令転送レジスタであり、かつフェッチ・ユニットを介してコアに命令を送出するために使用される。このチェーンは、３２ビットの情報＋付加的なビットからなり、コアに送出された命令の完了を示す。
順序：ＴＤＩ−［３２］［３１］［３０］．．．［１］［０］−ＴＤ０
【００８５】
３．２．２．１０ Ｓｃａｎ Ｃｈａｉｎ ５
目的：デバッグ
長さ：３３ビット
このスキャン・チェーンは、ＣＰ１４ Ｒｅｇｉｓｔｅｒ ５、データ転送レジスタである。このレジスタは、物理的に２つの個別的なレジスタ、即ち読み出し専用レジスタＤＴＲ（ｒＤＴＲ）及び書き込み専用レジスタＤＴＲ（ｗＤＴＲ）からなる。このレジスタは、ソフトウェアによる双方向通信チャネルの作成を容易にするように分離されている。ｒＤＴＲは、ＪＴＡＧポートを介してのみロード可能とされ、かつＭＲＣ命令を介してコアによってのみ読み出し可能とされる。ｗＤＴＲは、ＭＲＣ命令を介してコアによってのみロード可能とされ、まだＪＴＡＧポートを介してのみ読み出し可能とされる。ＴＡＰコントローラの能力から、１レジスタ（Ｃｈａｉｎ ５）のみを認識するが、しかしどの命令を使用するのか（ＩＮＴＥＳＴ又はＥＸＴＥＳＴ）に従って適当なレジスタが選択される。
【００８６】
ｗＤＴＲチェーンそれ自体は、３２ビットの情報＋通信チャネルに関する１付加ビットからなる。ビット０の定義は、現在のＪＴＡＧ命令がＩＮＴＥＳＴであるか、又はＥＸＴＥＳＴであるかに従う。現在の命令がＥＸＴＥＳＴであれば、デバッガはｒＤＴＲに書き込むことができ、またビット０は、キューにまだ有効なデータがあるか否かを表示している。このビットがクリアされていれば、デバッガは新しいデータを書き込むことができる。コアがＤＴＲの読み出しを実行するときは、ビット０が自動的にクリアされる。逆に、ＪＴＡＧ命令がＩＮＴＥＳＴであれば、ビット０は、ｗＤＴＲに読み出す現在有効なデータが存在するか否かを表示している。ビットがセットされていれば、ＪＴＡＧは、ｗＤＴＲの内容を読み出す必要があり、続いてこのビットをクリアする。次いで、このコアは、ビット０をサンプリングすることができ、このビットが再びクリアされると新しいデータを書き込むことができる。ｒＤＴＲチェーンは、３２ビットの情報＋通信チャネルに関する１付加ビットを含む。
順序：ＴＤＩ−ｒＤＴＲ［３２］ｒＤＴＲ［３１］．．．ｒＤＴＲ［１］ｒＤＴＲ［０］
ｗＤＴＲ［３２］ｗＤＴＲ［３１］．．．ｗＤＴＲ［１］ｗＤＴＲ［０］−ＴＤＯ
【００８７】
３．２．２．１１スキャン・チェーン６−１５
予備
【００８８】
３．２．２．１２スキャン・チェーン１６−３１
割り付けなし
【００８９】
３．２．３ コアに対する命令の送出
ＣＰ１４内の２レジスタは、ＡＲＭ１０プロセッサ、命令転送レジスタ（ＩＴＲ）及びデータ転送レジスタ（ＤＴＲ）と通信するために使用される。ＩＴＲは、命令をプロセッサ・パイプラインに詰め込むために使用される。デバッグ状態では、プロセッサの殆どの時間は、ＩＴＲがレディーになるまで、無効命令を効果的に実行することに費やされる。ハードウェア・デバッグ状態では、ＰＣは命令を実行するに従って増加しないが、それでも分岐はＰＣを変化させることになる。
【００９０】
ＤＳＣＲ［２９］は自動実行機能（ａｕｔｏｅｘｃｕｔｅ ｆｕｎｃｔｉｏｎ）を制御する。このビットがセットされると、各ＪＴＡＧ ＴＡＰコントローラは、Ｒｕｎ／Ｉｄｌｅステートに入り、ＩＴＲに現在存在する命令は、コアによる実行のためにプリフェッチ・ユニットに送出される。このビットがクリアされているときは、命令はプリフェッチ・ユニットに送出されない。ＪＴＡＧ ＩＲレジスタ内の命令は、ＩＮＴＥＳＴ又はＥＸＴＥＳＴでなければならない。
【００９１】
自動実行機能は、データの速いアップロード及びダウンロードを可能にさせる。例えば、ダウンロードシーケンスは、下記のいかなるものでもよい。まず、ＳｃａｎＮＲｅｇにスキャン・チェーン２、スキャン・チェーン４及び５の組み合わせを選択し、次いで、書き込みのためにＪＴＡＧ命令をＥＸＴＥＳＴにセットする。コア書き込み命令（ＳＴＣ）及び関連するデータをＩＴＲ及びＤＴＲにそれぞれ直列にスキャン入力する。ＴＡＰコントローラがＲｕｎ−Ｔｅｓｔ／Ｉｄｌｅステートを通過すると、ＩＴＲ内の命令をコアに発行する。次に、スキャン・チェーンをＤＴＲのみ（チェーン５）に切り換え、Ｃａｐｔｕｒｅ−ＤＲステート、次いでＳｈｉｆｔ−ＤＲステートとなることにより、ポーリングする。このステータス・ビットが命令の完了を示すまで、このチェーンにおける最下位ビット、即ちビットｗＤＴＲ［０］を調べる。更に多くのデータをＤＴＲにロードして、命令をＲｕｎ−Ｔｅｓｔ／Ｉｄｌｅを通過することにより再実行することができる。ここで、更に、我々は、アドレスが自動的に更新されるように、ＳＴＣ命令が基本アドレス書き戻しを指定するものと仮定する。
【００９２】
アップロードのパフォーマンスを増加させるためには、同じような機構を使用することができる。第１に、ＪＴＡＧ命令をＥＸＴＥＳＴに変更する。チェーン２を使用して、ＬＤＣのような読み出す命令をＩＴＲにスキャン入力することができる。次に、読み込みのためにＪＴＡＧ命令をＩＮＴＥＳＴに切り換える。そこで、スキャン・チェーンをＤＴＲに切り換えて命令が完了するまでポーリングすることができる。Ｒｕｎ−Ｔｅｓｔ／Ｉｄｌｅステートを通ってＳｈｉｆｔ−ＤＲ（ポーリングのため）となる過程で、コアに対してＩＴＲを発行する。以下、最後のワードを読み出すまで、この処理を繰り返す。
【００９３】
Ｒｕｎ−Ｔｅｓｔ／Ｉｄｌｅを通って命令を実行したことにより、ＪＴＡＧクロックの周波数に接近した周波数にあるコア・クロックを動作させる問題に取り組む。コアに命令を発行し、かつデータが捕捉できないときは、エミュレータは、データが得られるまで、ステート・マシン・ループを単に周りポーリングをする。そのようになると、ステート・マシン・ループをもう一回巡回し、データを捕捉し、次いでこれをスキャン出力させることができる。内側ループにおいて自動実行機構を他のステートに設定すると、他の命令を発送するのを早過ぎるものにし、多分、他のデータを重ね書きするのを強いる。Ｒｕｎ−Ｔｅｓｔ／Ｉｄｌｅは内側ループ外に留まり、１ステート遷移のみとなり、通過することに殆ど不都合はない。プロセッサ・クロックがＪＴＡＧクロックよりもかなり速いシステムでは、通常、ＴＡＰコントローラがＲｕｎ−Ｔｅｓｔ／ＩｄｌｅからＣａｐｔｕｒｅ−ＤＲとなる十分前に、データを得られるので、内側ループを１回通ってデータを捕捉し、次いでスキャン出力する。
【００９４】
ＣＰ１４は、ＡＲＭ９が行うと同様にバスを監視しないので、コアのレジスタ・ファイルの内容を読み出すには、ＬＤＭ／ＳＴＭ命令を使用する代わりに、ＡＲＭレジスタからＣＰ１４レジスタ５に個別的な移動を必要とすることに注意すべきである。そこで、情報をＤＴＲからスキャン出力することができる。
【００９５】
バイト及びハーフワードの転送は、プロセッサにアドレス及びデータの両方を転送し、次に適当なＡＲＭ命令を実行することにより、実行される。
【００９６】
コプロセッサへ及びからの転送は、ＡＲＭレジスタを介してデータを移動することにより実行可能とされる。これは、全てのＡＲＭ１０コプロセッサがＭＲＣ及びＭＣＲを介してアクセス可能な全てのデータを有する必要があるということを意味する（そうでないときは、書き込み可能なメモリにおけるデータ・バッファを使用する必要がある）。
【００９７】
３．２．４ ブレークポイント・レジスタ及びウォッチポイント・レジスタの読み出し及び書き込み
ハードウェア・ブレークポイント及びウォッチポイントは、データをＡＲＭレジスタに転送し、次いでデータを適当なブレークポイント・レジスタ又はウォッチポイント・レジスタに移動させることにより、書き込まれる。たとえばブレークポイントレジスタＲ６４へのロードを考える。
ＩＴＲにスキャン入力：ＭＲＣ ｐ１４，０，Ｒｄ，ｃ０，ｃ３，０
ＤＴＲにスキャン入力：ブレークポイント／レジスタＲ６４にデータをロード
データコマンドを実行
ＩＴＲにスキャン入力：ＭＲＣ ｐ１４，０，Ｒｄ，ｃ０，ｃ０，４
【００９８】
以上の例では、最初のＭＲＣ命令はデータをＤＴＲレジスタ（ＣＰ１４内のＲ５）からＡＲＭ内の他のレジスタに移動する。このデータが移動されると、ＭＣＲ命令はデータをＡＲＭレジスタからブレークポイント・レジスタ（ＣＰ１４内のＲ６４）に転送する。
【００９９】
ブレークポイント・レジスタを読み出すために逆の処理を使用することができる。ブレークポイント・レジスタ及びウォッチポイント・レジスタは、実施コストを最小化するためにスキャン・チェーンから直接アクセス不可能である。
【０１００】
プリフェッチ・ユニットことにより発行された命令アドレスは、常時、ビット０が０にセットされている。サム・モードにおいて、ビット１はアドレスの奇数ワードのアドレスを表している。一方、ＡＲＭモードにおいて、ビット１は常時、０にセットされている。ブレークポイント・レジスタは、サム・モードにおいてブレークポイント及びウォッチポイントに対する比較のために、全３２ビット・フィールドを有するが、ユーザは、このレジスタに絶対に一致しない値、例えばビット０を１とした値にセットしないように注意すべきである。
【０１０１】
ブレークポイント及びウォッチポイント制御レジスタ内のビットは、自明である必要がある。
【０１０２】
３．２．５ ソフトウェア・ロックアウト機能
ＪＴＡＧデバッガが評価ボード又はテスト・システムに取り付けられているときは、その存在は、ＤＳＣＲ内のホールト／モニタ・モード（Ｈａｌｔ／Ｍｏｎｉｔｏｒ Ｍｏｄｅ）をセットすることにより表示される。この場合に、ホールト・モードである間は、デバッガによりブレークポイント・レジスタ及びウォッチポイント・レジスタを書き込み及び読み出すことができる。ブレークポイント・レジスタ及びウォッチポイント・レジスタが構築されてしまうと、デバッガが制御権を保持しているので、ホールト／モニタ・モードのビットがハイのままであれば、ソフトウェアによりプロセッサ側からこれらレジスタを変更することはできない。しかしながら、コアは、依然として通信チャネル・レジスタに書き込み可能である。
【０１０３】
３．２．６ 外部信号
デバッグに関連した１外部信号ＥＤＢＧＲＱが存在し、これによって、システムはＡＲＭ１０２０にデバッグ・ステートに入るように要求する。外部ロジックは、このラインを使用してマルチプロセッサ・システムにおけるＡＲＭ１０２０をホールトするように、又は起動時に直接、プロセッサをデバッグ・ステートに強制設定するように要求してもよい。
【０１０４】
３．２．７ ステートのセーブ及びリストア
デバッグ処理の前に、エミュレータは、制御のセッティング、レジスタ値、又はエミュレーションの過程で変更される恐れのある他のステートをセーブする必要がある。このため、デバッグを抜け出す前に、これらの元のステートに全ての条件をリストアするように考慮する必要がある。デバッグ・エントリ後に読み出されるＰＣ値は、全ての場合でＰＣ＋０Ｘ８となる。即ち、ベクトルは、ＢＫＰＴ命令、レジスタ・ブレークポイント、ＪＴＡＧからのＨＡＬＴ命令等を捕捉する。
【０１０５】
ＤＴＲは２レジスタに分割されたので、ｒＤＴＲ及びｗＤＴＲステート情報をセーブすることが必要がある。セーブ及びリストア・シーケンスは下記のように見える。
（ハードウェアはＪＴＡＧを通ってＨＡＬＴ命令を実行する。）
コアをホールトした（Ｃｏｒｅ Ｈａｌｔｅｄ）が主張されるまで、ポーリングする
主張されれば、ｗＤＴＲを捕捉してスキャン出力する
ＪＴＡＧ ＩＲをＥＸＴＥＳＴへ変更及びジャンク（ｊｕｎｋ）をｗｐｒＤＴＲへスキャン入力−これはｒＤＴＲステータス・ビットを強制的に出力させる。
（他のレジスタをセーブする）
．
．
．
（デバッグ処理を終了）
古いＣＰＳＲをｒＤＴＲにスキャン入力
ＭＲＣによりＩＴＲをロードし、ＭＲＣはｒＤＴＲをＲ０に転送して実行
ＭＳＲによりＩＴＲをロードし、ＭＲＣはＲ０をＣＰＳＲに転送
古いＰＣをｒＤＴＲにスキャン入力
ＭＲＣによりＩＴＲをロードし、ＭＲＣはｒＤＴＲをＲ０に転送して実行
ＭＯＶによりＩＴＲをロードし、ＭＯＶはＲ０をＰＣに転送
古いＲ０をｒＤＴＲにスキャン入力
ＭＲＣによりＩＴＲをロードし、ＭＲＣはｒＤＴＲをＲ０に転送
（レジスタをリストア）
セーブしたｒＤＴＲステータス・ビットがレジスタがフルであったことを示しているときは、古いｒＤＴＲ情報をｒＤＴＲにスキャン入力
ＲＥＳＴＡＲＴコマンドを発行
Ｃｏｒｅ Ｒｅｓｔａｒｔｅｄが主張されるまでポーリング
【０１０６】
３．３ デバッグに対するソフトウェアインタフェース
モニタ・モードは、レジスタのブレークポイント、これらのブレークポイントに対する応答、及び更にコアをホールトを構築するように使用されるこれらのＡＲＭオペレーションを説明する。モニタ・モードは、情報を収集するためにコアをホールトできないときにリアル・タイム・システムにおいても有用である。例には、エンジン制御、及び部品を物理的に損傷することなくコードを停止できないハード・ドライブ・コントローラにおけるサーボ機構がある。命令ストリームに小さな挿入を許容する状況では、モニタ・モードは理想的である。この技術を使用して、ステート情報及び重要な変数をセーブするのに十分な時間割り込みによりコードを一時停止させる事ができる。コードは例外ハンドラーが終了すれば再度続行する。
【０１０７】
３．３．１ モニタ・モードへの進行及び抜け出し
モニタ・モードは、ＤＳＣＲのビット３０に０を書き込むことにより、エネーブルされる。モニタ・モードがエネーブルされたときに、下記の事象のうちの１つが発生すると、プロセッサは（ホールトすることよりも）例外となる。
１）レジスタのブレークポイントをヒット
２）ウォッチポイントをヒット
３）ブレークポイント命令がＡＲＭパイプラインの実行段階に到達
４）例外に行き、対応するベクトル・トラップ・ビットをセット
【０１０８】
ＤＳＣＲ内のグローバル・デバッグ・エネーブル（Ｇｌｏｂａｌ ＤｅｂｕｇＥｎａｂｌｅ）ビットをセットしなければ、無操作となることに注意すべきである。例外ハンドラーからの抜け出しは、通常の形式、例えばプリフェッチ例外のためにＰＣを（Ｒ１４−０Ｘ４）にリストアし、ＢＲＰＴ命令に対してＲ１４をＰＣに移動させることにより、実行する必要がある。なぜならば、これらはスキップ等が実行されるためである。以下の表は、コアが例外となるときのＰＣの値を表示する。
【０１０９】
【表４】
【０１１０】
３．３．２ ブレークポイント・レジスタ及びウォッチポイント・レジスタの読み出し及び書き込み
モニタ・モードのときは、全てのブレークポイント・レジスタ及びウォッチポイント・レジスタを特権処理モードからのＭＣＲ及びＭＣＲ命令により読み出し及び書き込みが可能である。
【０１１１】
レジスタ・フィールドの符号化の説明については、３．１．２項及び３．２．４項を参照されたい。
【０１１２】
３．３．３ ＢＫＰＴ命令
ＡＲＭデバッグ・アーキテクチャーは、ＡＲＭ及びサムの両者に対するブレークポイント命令を定義する。これらの命令のうちの一つの実行は、レジスタ・ブレークポイントをヒットすることと同一の効果を有する。モニタ・モードでは、プリフェッチ中断が実行され、ホールト・モードでは、コアがホールトする。各デバッグ命令は、個々のブレークポイントを識別するためにデバッガことにより使用可能にされた１未使用フィールド、サムに対して８ビット、及びＡＲＭに対して１２ビットを有する。
ＡＲＭのオプコードは３２′ｈＥ１２ｘｘｘ７ｘ、サムのオプコードは１６′ｈｂｅｘｘであり、ｘは未使用フィールドである。
【０１１３】
３．３．４ Ｃｏｍｍｓチャネル
ＡＲＭ１０におけるｃｏｍｍｓ（通信）チャネルは、物理的に独立した２つのデータ転送レジスタ（ＤＴＲ）及び各レジスタを増加するために１ビットを使用し、双方向直列ポートを形成することにより実施された。この付加ビットは、有効データがデータ・レジスタに存在することを表示する。協定により、対象ソフトウェアは、書き込みＤＴＲ（ｗＤＴＲ）を保有し、またホスト・ソフトウェアは、読み出しＤＴＲ（ｒＤＴＲ）を保有する。換言すれば、ｗＤＴＲはコアにより書き込まれ、次いで情報はホストによりＪＴＡＧポートを通ってスキャン出力される。ｗＤＴＲはＴＤＯ接続を有する唯一のレジスタであり、スキャン・チェーン５のビット０は、ＪＴＡＧ命令レジスタにおける現在命令（ＩＮＴＥＳＴ又はＥＸＴＥＳＴ）により選択される。ｃｏｍｍｓチャネルの活動のデバッグをしているときに、ＤＳＣＲのビット２７は、セットされて、ここで、ｗＤＴＲの最下位ビットが命令の完了よりもｃｏｍｍｓチャネル・レジスタのステートを表示していることをデバッグ・ロジックに表示する。
【０１１４】
デバッガがそれを意図するデータを読み出しているときに、ＩＮＴＥＳＴをＩＲにロードしｗＤＴＲの内容をスキャン出力する。３３ビットのデータ・パケットの最下位ビットがセットされていれば、このデータは有効である。次いで、この読み出しによりｗＤＴＲ内のビット０をクリアする。このビットがクリアされており、コアに新しいデータが書き込まれていないことを意味しているときは、デバッガは、コアがホールトしたか否かを調べるためにＤＳＣＲのポーリングを希望することもできる。
【０１１５】
同様に、ＥＸＴＥＳＴは、デバッガによりｒＤＴＲにデータを書き込むために使用され、またこの動作は有効データを示すビット０をこのレジスタ用にセットする。デバッガが見るものは、実際には、このビットの反転であるので、デバッガは更にデータを書き込みをするときに、ビット０は、セットされて、コアがｒＤＴＲを読み出したことを意味しているか否かを見るために、チェックされる必要がある。このビットがゼロであり、ｒＤＴＲが依然としてフルであり、かつコアが古いデータを読み出していなかったときは、シフト入力された新しいデータは、ｒＤＴＲにロードされない。これを多数回行った後に、コアがホールトしたか否かをデバッガがチェックしたいときは、ステータス・ビットは、ｒＤＴＲ内のデータと共に有効に存続する。これは、スキャン出力されて、デバッガが後で単にスキャン入力により戻せるようにセーブしたステート情報と置換される必要がある。データをｒＤＴＲからコア・レジスタに、次いでｗＤＴＲに移動してスキャン出力するこのような操作は、ｒＤＴＲの全ビットを制御しているステート・マシンをクリアすることになる。
【０１１６】
これらの付加ビットは実際にＤＳＣＲに反映されるので、コアはこれらビットを読み出すためにＭＲＣを使用することができる。しかしながら、これらのビットは、コア用なので、デバッガから見えるビットの論理反転である。
【０１１７】
ホールト・モード及びモニタ・モードは、互いに排他的であるので、転送レジスタは、モニタ・モードにおいて他の目的用に使用されていない。
【０１１８】
４．０ デバッグ及び例外、ベクトル捕捉
４．１ 命令ブレークポイント
命令ブレークポイントは、命令データと同時にコアにクロッキングされる。ブレークポイントは、中断がペンディングでないと仮定して、命令がパイプラインの実行段に入ると直ちに処理される。このブレークポイントは、命令がその条件コードに失敗したか否かについて処理される。
【０１１９】
ブレークポイント命令は、これに関連したプリフェッチ中断を有してもよい。その通りであれば、プリフェッチ中断が優先し、ブレークポイントは無視される。ＳＷＩ及び未定義命令は、これにセットされたブレークポイントを有し得る他の命令と同様に処理される。従って、ブレークポイントはＳＷＩ又は未定義命令に対して優先する。
【０１２０】
命令の境界にブレークポイントの命令及び割り込み（ＦＩＱ又はＩＲＱ）が存在するときは、割り込みが実行され、ブレークポイントの命令はすてられる。割り込みがサービスされると、実行フローは元のプログラムに戻される。これは、前にブレークポイントした命令が再びフェッチされたことを意味し、このブレークポイントが依然としてセットされているときに、プロセッサがパイプラインの実行段に到達すれば、プロセッサはデバッグ・ステートに入る。
【０１２１】
４．２ ウォッチポイント
ウォッチポイントのメモリアクセスに続くデバッグ・ステートへのエントリは、命令ストリーム・アクセスと比較して不正確である。これは、パイプラインの性質及びコアに行くウォッチポイント信号のタイミングのためである。プロセッサは、ウォッチポイント・トリガ後に実行される、ウォッチポイントの命令が実行を開始した後の数命令となり得る次の命令で停止することになる。
【０１２２】
ウォッチポイントと共にデータ・アクセスによる中断があると、中断例外エントリ・シーケンスを実行し、次いでプロセッサはデバッグ・ステートに入る。割り込みの待機があると、再び、プロセッサは、例外エントリ・シーケンスが発生できるようにし、デバッグ・ステートに入る。次の命令を中断したときは、中断は実行されない。
【０１２３】
ＣＰ１５内のフォールト・ステータス・レジスタ（Ｆａｕｌｔ ＳｔａｔｕｓＲｅｇｉｓｔｅｒ：ＦＳＲ）は、ＭＭＵとアクセスを中断するデバッグ・システムとの間を区別する。データ中断が発生すると、ＦＳＲ［３：０］フィールドのビット９がゼロに強制設定される。データ中断がなく、ウォッチポイントが発生すると、ＤＦＳＲ［９］を１に強制設定する。
ソフトウェアがこのレジスタを読み出し、かつＤＦＳＲ［９］が１にセットされているのを認識したときは、残りのビットを無視する必要がある。
【０１２４】
４．３ 割り込み
プロセッサがデバッグ・ステートに入れば、更なる割り込みが実行された命令に影響しないことが重要である。このために、プロセッサがデバッグ・ステートに入れば、割り込みがディセーブルされるが、ＰＳＲにおけるＩ及びＦビットのステートは、影響されない。
【０１２５】
４．４ 例外
ＡＲＭ１０コアにおける例外の優先順位は、以下のようである。
【０１２６】
【表５】
【０１２７】
下記の表６は、ホールト及びモニタ・モードの両者におけるデバッグ・ロジックの動きの要約である。
【０１２８】
【表６】
【０１２９】
モニタ・モードにおいて、ブレークポイントをヒットした、又はＢＫＲＰ命令を実行したときは、プリフェッチ中断の例外となる。ウォッチポイントをヒットしたときは、データ中断の例外となる。ＣＰ１５内のフォールト・ステータス・レジスタ（ＦＳＲ）は、ＭＭＵとデバッグ・システムとの間を区別してアクセスを中断するために使用される。ＦＳＲにウォッチポイントヒットを示す符号が加えられる。Ｒ１４ ａｂｏｒｔは実行されなかった命令後の第１の命令をポイントする。２つの異常例、即ち「フェッチ中断上にベクトル・トラップのセット」、又は「データの中断が許可されない」がディセーブルされた。如何なる状況であっても、ＪＴＡＧ ＨＡＬＴ命令を、ソフトウェア・モードにある間に、デバッグ・ロジックがＤｂＨａｌｔライン〜ＤｂｇＩｎＤｅｂｕｇラインをクリアするために使用するハンドシェーク・ラインとして、決して現れない部分にスキャン入力されるようなことがあれば、プロセッサを（現在Ｒｅｖ０ハードウェア実施により）連続的にプリフェッチ中断させることになる。
【０１３０】
ウォッチポイントをセットしたロード／ストア多重命令の場合に、他の命令は、多分（かつ大抵は）その下で動作することができる。デバッガはロード／ストア多重命令のＰＣ値と共に復帰ＰＣ値（ｒｅｔｕｒｎ ＰＣ）を知る必要があるので、ウォッチポイントのデータ・アドレスは、Ｄ側のフォールト・アドレス・レジスタ（ＦＡＲ）に記憶され、ウォッチポイント命令それ自身のＰＣ（＋０Ｘ８）は、Ｉ側ＦＡＲに記憶される。再起動ＰＣは、通常のようにＲ１４に保持される。
【０１３１】
コアがデバッグ・ステートにある間に未定義の命令例外となるときは、即ちデバッグ・ステートにある間に、デバッガが、未定義命令をコアにスキャン入力するときは、コアはモードを変更し、かつＰＣを未定義命令トラップ・ベクトルに変更する。デバッガはこの情報を使用して未定義命令を何時コアが見たかを判断することができる。１例は、与えられた実施に対してサポートされていないために、拒絶するコプロセッサ命令が考えられる。
【０１３２】
４．５ ベクトル捕捉
ＡＲＭ１０デバッグ・ユニットは、例外中にベクトルからフェッチの効率的なトラッピングを可能にするロジックを含む。これは、ＤＳＣＲに位置するベクトル捕捉エネーブル（Ｖｅｃｔｏｒ Ｃａｔｃｈ Ｅｎａｂｌｅ）により制御される。このレジスタ・フィールドにおける複数ビットのうちの１ビットがハイにセットされ、かつ対応する例外が発生すると、プロセッサは、レジスタ・ブレークポイントが関係する例外ベクトルからの命令フェッチにセットされたかのように作動し、次いでホールトする。ベクトル捕捉エネーブルは、ＪＴＡＧ命令からのみ書き込み可能である。
【０１３３】
例えば、プロセッサがホールト・モードにあり、かつＤＳＣＲ［１８］がセットされている間にＳＷＩ命令を実行するときは、ＡＲＭ１０が０Ｘ８から命令をフェッチする。ベクトル捕捉ハードウェアは、このアクセスを検出し、かつ内部ブレークポイント信号をセットしてコアを強制的に停止させる。
【０１３４】
ベクトル捕捉ロジックは例外エントリ中にベクトルからのフェッチに対してのみ感応する。従って、通常のオペレーション中に、コードがベクトル内のアドレスに分岐し、かつ対応するベクトル捕捉エネーブル・ビットがセットされると、プロセッサはデバッグ・ステートに強制されない。レジスタ・ブレークポイントは、ベクトルからの命令フェッチを捕捉するために使用されてもよい。
【０１３５】
ブレークポイントを経由する割り込みのステート優先度は、ＡＲＭ９におけるベクトル捕捉バグの原因であった。ＡＲＭ１０の場合に、ベクトルが捕捉した例外ベクトルからフェッチされた命令の発行中に割り込み要求が発生するときは、コアはベクトル・トラップを最初に処理する。コアが再起動すると、プロセッサは割り込み要求を処理する。
【０１３６】
５．０ サム
デバッグ・ステートにおいて、ＣＰＳＲのＴビットは、デバッガにより読み出され／書き込まれ、かつデバッグ・ステートに入る又は出るときに変更されない。更に、これは、デバッグ・ステートにある間に実行される命令形式に影響されない。デバッグ・ステートを抜け出すときは、ＣＰＳＲ Ｔビットは、ＡＲＭ又はサム命令が実行されるのかを決定する。
【０１３７】
ＤＳＣＲにおけるＴビットは、プリフェッチ・ユニットに送出される各命令と共に送出されるので、コアをホールトすると、デバッガが実行しようとし、かつプロセッサをＡＲＭモード又はサム・モードに強制設定するために使用可能とされる命令形式（ＡＲＭ又はサム）を表示する。換言すれば、ＤＳＣＲにおけるＴビットは、ＩＴＲにおける命令のデコードを制御する。デバッグ・ステートのエントリ後に、デバッガは、ＤＳＣＲにおけるＴビットをクリアしてＡＲＭ１０にＡＲＭ１０命令を発行できることを確認する必要がある。デバッガに対するエントリ・シーケンスは、以下のように見ることになるであろう。
（ホールト・モードによりデバッグ・ステートに入る）
０をＣＰ１４のレジスタ１のＴビットにスキャン入力（ＤＳＣＲ）
ＡＲＭモードによりＣＰＳＲを読み出してＴビット情報を得る（オプション）
ＡＲＭモードによりＭＣＲを実行してＡＲＭステート情報を抽出
・
・
ＭＲＣを使用して全てのＡＲＭをリストア
再起動ＰＣ値をＲ０に移動
ＡＲＭ ＭＯＶ Ｒ０，ＰＣを実行
リストアＲ０
（命令が完了したことを確認するためにポーリング）
（ＪＴＡＧを通ってＲＥＳＴＲＴコマンドを発行することによりデバッグ・ステートを抜け出す）
Ｃｏｒｅ Ｒｅｓｔａｒｔビットをポーリング
【０１３８】
コアは、デバッグ・ステートを抜け出す際に現在モードとしてＣＰＳＲにおけるＴビットを使用する。
【０１３９】
６．０ 実施発行
デバッグ構造は、２クロック領域、即ち高速プロセッサ・クロック及び低速ＪＴＡＧクロックにより実施されることを意図している。大抵のデバッグ・ハードウェアは、高速クロック速度で動作し、両者間の同期は、命令として実行され、データ転送レジスタは、ＪＴＡＧスキャン・チェーンから読み出され、またＪＴＡＧスキャン・チェーンに書き込まれる。これは、コア・クロックより速くＪＴＡＧクロックを動作させることができる。
【０１４０】
データ転送用のソース及び宛先としてＣＰ１４を使用し、ＡＲＭ内の既存のパスを再使用して、データ・バスに付加付加的な入力を追加する必要性をなくしている。ＡＲＭ１０には、フェッチ・ユニットにおける初期命令入力として命令レジスタが設けられている。
【０１４１】
少数のマルチＩＣＥは、ＪＴＡＧハードウェア内の更新機構に付加されるわずかな調整を必要とする設計の過程で発生する。コアに命令を発行する間に、マルチＩＣＥソフトウェアは、前に発行した命令が完了したか否かを検定するためにＣａｐｔｕｒｅＤＲステートを通過後にビットをスキャン出力する。命令が完了していないときは、デバッグ・ロジックは、２つの事象が発生するのを防止する。第１に、ＴＡＰステート・マシンがＵｐｄａｔｅＤＲステートを通過するときに、スキャン・チェーン５にシフトされた値がｒＤＴＲにロードされない。第２に、ＴＡＰステート・マシンがＲｕｎ−Ｔｅｓｔ／Ｉｄｌｅステートを通過して現在ＩＴＲ内の命令を発行するので、この命令がコアに発行されない。ｒＤＴＲの３３番目のビットは、「更新する」（ｄｏ ｕｐｄａｔｅ）ビットを作成するために登録され、この「更新する」ビットは命令の発行及びｒＤＴＲの更新を阻止するために使用される。
【０１４２】
特に、このロジックは以下の場合に使用される。極端に速いダウンロードを試行するために、マルチＩＣＥは、データをｒＤＴＲにスキャン入力して、Ｒｕｎ−Ｔｅｓｔ／Ｉｄｌｅを通ることによりコアに対して書き込みを発行することにより、起動する。次の各書き込みオペレーションにおいて、ｒＤＴＲのビット０を調べて前の命令が完了したか否かを判断する。この命令が完了していないときは、デバッガは再び同一のデータを与える。所定数の試行後に、命令が未だ完了していないときは、デバッガはＤＳＣＲ内の中断発生（Ａｂｏｒｔ Ｏｃｃｕｒｒｅｄ）ビットを調べて中断がどこかの点に発生したのか否かを判断する。メモリ・アクセス中に中断が発生したときは、「更新する」ビットをクリアすることにより、次の命令が実行されてメモリをアクセスしようとする他の可能性を除去する。特に、これは、中断のためにモードが突然変化し、かつユーザ・モードではアクセスできないメモリが特権モードにおいてアクセス可能となるときに、重要となる。
【０１４３】
次に実行すべき命令の後の位置に配置されたＢＫＰＴ命令を使用して、ここで、コードによる単一ステップを実行することが必要となる。更に、レジスタ・ブレークポイントも使用することができる。
【０１４４】
ＬＤＣはワード長のみである。バイト／ハーフワード・アクセスのためにコアに読み出し／書き込みを強制させ、次いでスキャン出力又はその逆のためにデータをＲ５に移動させる。
【０１４５】
７．０ キャッシュ（ＣＰ１５）及びメモリ動作
デバッグ・ユニットは、ＣＰ１４及びＣＰ１５がいくつかの機能を共有しているので、ＴＬＢ情報と共にキャッシュ情報を読み出すことができる。パイプライン・フォロワ及びコプロセッサ・インターフェースは、全て同一ブロック内に存在する。これは、ＣＰ１４がＣＰ１５内のＦＳＲを非常に簡単に更新可能にする。ＣＰ１５は１６のレジスタを含み、その一つ（Ｒ１５）はデバッガ用のインターフェースとして使用される。ＭＲＣ命令及びＭＣＲ命令を使用してＲ１５の読み出し及び書き込みにより、デバッグ・ユニットは、キャッシュの完全な可視性を有する。キャッシュについての更なる情報は、ＡＲＭ１０２０μＡ仕様を参照されたい。
【０１４６】
マシンのステートをデバッグ・ステートに変更した後、メモリからのデータの読み出しにより、Ｉキャッシュ又はＤキャッシュがキャッシュに新しいエントリを挿入させることはない。換言すれば、キャッシュ可能として処理されるアクセスはない。これは、キャッシュをキャッシュ不能、バッファ不能に強制設定することにより達成される。キャッシュ・ミスは、デバッグ・ステートにある間に、ＨＵＭバッファにより無視されるので、ライン・フルは発生しない。
【０１４７】
命令データを変更するプログラム（例えば、自己変更コード）は、一貫性を保持するために、Ｄキャッシュによる書き込み後に、Ｉキャッシュをフラッシュする必要がある。
【０１４８】
デバッグ・モードでは、ユーザ・モードによるメモリ・アクセスがメモリ・システム及びＭＭＵに対するユーザ・モード・アクセスのように見える。特権モードにおけるメモリ・アクセスは、特権アクセスのように見える。
【０１４９】
【表７】
【０１５０】
【表８】
【図面の簡単な説明】
【図１】デバッグ機構を含むデータ処理システムを概要的に示す図である。
【図２】図１のデータ処理システムのデバッグ機構の一部であるデバッグ・コプロセッサを概要的に示す図である。
【図３】図１のデータ処理システムのデバッグ機構の一部であるデータ転送レジスタを概要的に示す図である。
【図４】デバッグ命令の実行を示すフロー・チャートである。
【図５】デバッグ命令の繰り返し実行を示すフロー・チャートである。
【図６】図２のデバッグ・コプロセッサの他の概要ブロック図である。
【図７】図１のデータ処理システムのデバッグ機構の一部であるスキャン・チェーン・コントローラを示す概要ブロック図である。
【図８】図３に示すデータ転送レジスタのハンドシェーキング制御の一部を説明するタイミング図である。
【図９】ハードウェア・デバッグ・モードと通常モードとの間の切り換えを制御しているメイン・プロセッサとデバッグ・システムとの間のハンドシェーキング信号を説明するタイミング図である。
【符号の説明】
２ データ処理システム
４ メイン・プロセッサ（コア）
６ デバッグ・コプロセッサ（コプロセッサ）
１０ プリフェッチ・ユニット
１２ スキャン・チェーン・コントローラ
１４ 命令パイプライン
７８ デコーダ
２８ デバッグ・ステータス及び制御レジスタ（ＤＳＣＲ）
１６ ウォッチポイント・レジスタ
１８ ブレークポイント・レジスタ
【発明の属する技術分野】
本発明は、データ処理システムに関する。特に、本発明は、データ処理システム用のデバッグ機構に関する。
【０００２】
【従来の技術】
デバッグ機構による問題は、通常の動作中に可能なパフォーマンスと干渉又は制限することがあってはならないということである。例えば、公知のデバッグ機構は、プログラミングのブレークポイント（ｂｒｅａｋｐｏｉｎｔ）及びウォッチポイント（ｗａｔｃｈｐｏｉｎｔ）のようなデバッグ機構の構成を可能とするようにデータ処理パス内にマルチプレクサを付加したものをしばしば含む。
【０００３】
【発明が解決しようとする課題】
デバッグ用にのみに必要とされるこれらの付加的な回路要素は、通常の動作中にデータ処理システムのパフォーマンスを制限するクリティカル・データ・パス内に信号伝搬遅延をもたらす恐れがある。
【０００４】
【発明を解決するための手段】
本発明は、一特徴によれば、データ処理装置を提供するものであって、前記装置は、
メイン・プロセッサに入力された命令ストリーム内のメイン・プロセッサ命令に応答してメイン・プロセッサ・オペレーションを実行する前記メイン・プロセッサと、
コプロセッサ・インターフェースを介して前記メイン・プロセッサに接続され、かつ前記命令ストリーム内のコプロセッサ命令に応答してコプロセッサ・オペレーションを実行するコプロセッサとを備え、
前記コプロセッサは、前記データ処理装置をデバッグする診断データの発生を少なくとも部分的に制御するように動作可能なデバッグ・コプロセッサであり、前記コプロセッサ命令は前記デバッグ・コプロセッサのオペレーションを制御するデバッグ・コプロセッサ命令である。
【０００５】
本発明は、コプロセッサに通常使用される機構及び構造を使用して前記システムの通常オペレーションに対する影響を少なくしたデバッグ・システムを提供できることが解る。加えて、前記メイン・プロセッサは、このメイン・プロセッサのパフォーマンスを制限することなく、コプロセッサにより動作し、かつ通信するのを容易にするように、しばしば予め設計される。本発明は、デバッグ・プロセッサ形式によるデバッグ機構を設けることによりこのような特徴を得ている。このデバッグ・プロセッサは、前記メイン・プロセッサの通常パフォーマンスに対して殆ど影響しないように前記コプロセッサ・インターフェースを介して構築することが可能とされる。
【０００６】
前記デバッグ・コプロセッサを構成する特に効果的な方法は、１以上のデバッグ・コプロセッサ・レジスタを介することによる。
【０００７】
メイン・プロセッサ及びコプロセッサ・システムと関連されたコプロセッサ命令セットは、典型的には、コプロセッサ内のレジスタに値を書き込む、又はコプロセッサ内のレジスタから値を読み出すコプロセッサ命令を含む。このようにして、構成データをデバッグ・コプロセッサに書き込むことができ、またデバッグ・コプロセッサから診断データを復元することができる。
【０００８】
非常に有用なデバッグ機構は、ブレークポイント及びウォッチポイント機能を実行できるものである。これらのブレークポイント及びウォッチポイント値は、プログラムされ、かつ記憶される必要がある。この必要性は、所望のブレークポイント及びウォッチポイント値を記憶するようにデバッグ・コプロセッサ内のレジスタを使用することにより、非常に効果的に達成可能とされる。
【０００９】
更に、マスク値、エネーブル（ｅｎａｂｌｅ＝可能状態）ビット及びモード選択値のように、より複雑なブレークポイント及びウォッチポイント・オペレーションに関連された制御データもデバッグ・コプロセッサ内のレジスタを使用して効果的にプログラムし、かつ記憶可能とされる。従って、更に、転送サイズ、（例えば、特権（ｐｒｉｖｉｌｅｇｅｄ）／ユーザ）モード、命令セットを表示するビット（ＡＲＭ Ｔｈｕｍｂ Ｔビット）のようなアドレス属性等に対して比較を行うこともできる。
【００１０】
コプロセッサ・レジスタは、メイン・プロセッサに伝達された命令ストリーム内のコプロセッサ命令を介してアクセス可能とされる。これは、メイン・プロセッサに対して同一の命令を発行することにより、デバッグしているデータ処理システム上を走るソフトウェア、及び外部スキャニング機構の両者がコプロセッサ・レジスタをアクセスしてデバッグ・オペレーションを構成できるようにする。従って、メイン・プロセッサ・コア上を走るソフトウェアは、デバッグ・コプロセッサ用を意図した命令を通常形式によりメイン・プロセッサ・パイプラインにフィードすることができ、これに対してスキャン機構は、命令転送レジスタを通ってデバッグ・コプロセッサ用を意図した命令をスキャン入力することができる。次に、これらのスキャン入力命令は、同一のメイン・プロセッサ・パイプラインへの命令として発行されることにより、フル速度で１度に１つ実行される。
【００１１】
その代わり及び追加として、少なくともいくつかのデバッグ・コプロセッサ・レジスタは、スキャン・チェーン・コントローラの制御により動作する直列スキャン・チェーンを介してアクセスされてもよい。これは、デバッグ・コプロセッサ形式によりデバッグ機構の外部プログラミングを外部ハードウェア及びソフトウェアにより達成可能にする。
【００１２】
スキャン・チェーン機構を介してアクセス可能なレジスタは、命令を直列的にシステムにスキャン入力するのを可能にし、次いでメイン・プロセッサか又はデバッグ・コプロセッサ（又はプロセッサ・インターフェースに取り付けられた浮動小数点ユニット・プロセッサのような他のコプロセッサ）により実行できるようにするレジスタを含む。
【００１３】
同様にして、スキャン・チェーン機構を介してアクセス可能なレジスタは、データ値をシステムにスキャン入力、又はシステムから直列にスキャン出力できる領域を含むことが好ましい。このようにデータ値を適用すること及び復元することは、診断オペレーションにおいて非常に有用である。
【００１４】
好ましい実施例は、このようなデータ値レジスタをアクセスしようとしていると同時に、スキャン・チェーンによりアクセスされていたメイン・プロセッサ又はコプロセッサの潜在的な問題を処理するために、２つのデータ値レジスタ形式、一方は、メイン・プロセッサ又はコプロセッサにより書き込み可能とされ、かつスキャン・チェーンにより読み出し可能とされる形式、また他方は、メイン・プロセッサ又はコプロセッサにより読み出し可能、かつスキャン・チェーンにより書き込み可能とされる形式にあるデータ値レジスタを提供するものである。これは、潜在的なデータ競合を回避する双方向通信チャネルを効果的に形成する。
【００１５】
好ましい実施例により得られるデバッグ・コプロセッサ内の他のレジスタは、読み出し及び書き込みが可能であり、かつデバッグ・モードへのエントリ条件、デバッグ・エネーブル・ビット、及びメイン・プロセッサのベクトル命令トラップ・オペレーションを制御するフラグのような情報を記憶するデバッグ・ステータス制御レジスタである。
【００１６】
デバッグ・コプロセッサは、好ましくは、パイプライン・ドレーン、パイプライン・ホールド及び命令取り消しのような機能を実行するためにシステムの残りに伝達可能とされる制御信号を使用すること、及び発生することができる。
【００１７】
デバッグ・コプロセッサは、典型的には、システム内のメイン・プロセッサ及びその他の全てのコプロセッサと同一のクロック周波数で動作する。これは、デバッグ・コプロセッサがメイン・プロセッサ及び他の全てのコプロセッサの通常的なオペレーション速度に対する影響が軽減されるように、標準的なコプロセッサ・インターフェースを使用して、これらの要素間の対話を容易にする。しかしながら、スキャン・チェーン機構は、異なる典型的には非同期のクロック速度で典型的に動作し、従ってデバッグ・コプロセッサはこれらの要素が異なるクロック領域内で通信できるようにした回路を備える必要がある。これらの付加的な機構は、他のメイン回路要素の通常的なオペレーションとの干渉を避けるようにしてデバッグ・コプロセッサ内で絶縁されてもよい。
【００１８】
本発明は、他の特徴によれば、データ処理方法を提供するものであって、前記方法は、
メイン・プロセッサに入力される命令ストリーム内のメイン・プロセッサ命令に応答して、メイン・プロセッサ・オペレーションを実行するステップと、
前記命令ストリーム内のコプロセッサ命令に応答し、コプロセッサ・インターフェースを介して前記メイン・プロセッサに接続されたコプロセッサを制御してコプロセッサ・オペレーションを実行するステップとを備え、
前記コプロセッサは、データ処理装置のデバッグのための診断データの発生を少なくとも部分的に制御するように動作可能なデバッグ・コプロセッサであり、前記コプロセッサ命令は、前記デバッグ・コプロセッサのオペレーションを制御するデバッグ・コプロセッサ命令である。
【００１９】
以下、添付図面を参照して、本発明を単なる一実施例による概要図により説明する。
【００２０】
【発明の実施の形態】
図１は、メイン・プロセッサ４、デバッグ・コプロセッサ（及びシステム・コプロセッサ）６、及び浮動小数点ユニット・コプロセッサ８を含むデータ処理システム２を示す。メイン・プロセッサ４は、コプロセッサ・バスＣＰの形式にあったコプロセッサ・インターフェースを介してデバッグ・コプロセッサ６及び浮動小数点ユニット・プロセッサ８に接続されている。このコプロセッサ・バスＣＰの形式は、標準的なコプロセッサ・バス、例えば（英国ケンブリッジのＡＲＭ有限会社製造のマイクロプロセッサに使用されている）ＡＲＭコプロセッサ・バスとほぼ同一である。
【００２１】
メイン・プロセッサ４は、データ・バスＤＢと、プリフェッチ・ユニット（ｐｒｅｆｅｔｃｈ ｕｎｉｔ）１０を介して命令バスＩＢとに接続されている。データ・バスＤＢ及び命令バスＩＢの両者は、ブレークポイント及びウォッチポイントをそれぞれ識別するためにデバッグ・コプロセッサ６により監視されるアドレス部を含む。
【００２２】
メイン・プロセッサ４、デバッグ・コプロセッサ６及び浮動小数点ユニット・プロセッサ８は、全てメイン・プロセッサのクロック周波数で共通メイン・プロセッサ・クロック信号ｃｌｋにより駆動される。スキャン・チェーン・コントローラ１２は、更にデバッグ・コプロセッサと共にデバッグ・ロジックの一部を形成する。スキャン・チェーン・コントローラ１２は、メイン・プロセッサ・クロック信号ｃｌｋと典型的に異なる周波数を有するデバッグ・クロック信号ｔｃｋにより駆動され、かつメイン・プロセッサ・クロック信号ｃｌｋと非同期である。
【００２３】
データ転送レジスタ（ｄａｔａ ｔｒａｎｓｆｅｒ ｒｅｇｉｓｔｅｒ）ＤＴＲ及び命令転送レジスタ（ｉｎｓｔｒｕｃｔｉｏｎ ｔｒａｎｓｆｅｒ ｒｅｇｉｓｔｅｒ）ＩＴＲは、いずれも個別的な直列スキャン・チェーンにより書き込み及び読み出しができるようにスキャン・チェーン・コントローラ１２に接続されている。図示していないが、いくつかのモードにおいて、データ転送レジスタＤＴＲ及び命令転送レジスタＩＴＲの個別的なスキャン・チェーンは、単一のスキャン・チェーンを形成するように互いに連結されてもよい。スキャン・チェーン・コントローラ１２は、ＩＥＥＥ１１４９．１ＪＴＡＧ標準において規定された形式のものである。このシステムは、スキャン・チェーン・コントローラ１２がＴＡＰコントローラ・ステート内のＲｕｎ−Ｔｅｓｔステートを通るときはいつも、命令転送レジスタＩＴＲがその内容を、メイン・プロセッサ４のパイプライン１４に伝達されて有効な命令ラインを主張することにより実行される命令として、プリフェッチ・ユニット１０に発行するように制御される。プリフェッチ・ユニット１０からメイン・プロセッサ４に伝達された命令は、メイン・プロセッサ４それ自身により、又はコプロセッサ・バスＣＰを介してメイン・プロセッサ４に接続されたデバッグ・コプロセッサ６、浮動小数点ユニット・コプロセッサ８のうちの１つを意図したものにより、実行される命令であってもよい。
【００２４】
２つの公開命令ＨＡＬＴ及び再起動ＲＥＳＴＡＲＴは、以下で更に説明するようにメイン・プロセッサの通常オペレーションを停止させるため、及び再起動させるために通常のＪＴＡＧ命令に付加された。
【００２５】
図２はデバッグ・コプロセッサ６を更に詳細に示す。メイン・プロセッサ４よりもコプロセッサにより実行することを意図したコプロセッサ命令は、コプロセッサ番号オペランド・フィールドを含む。このようにして、コプロセッサ番号に一致したコプロセッサのみがコプロセッサ命令に応答してこれを実行する。この場合に、デバッグ・コプロセッサにはコプロセッサ番号ＣＰ１４が与えられる。ＡＲＭメイン・プロセッサに通常関連されるシステム・コプロセッサには、コプロセッサ番号ＣＰ１５が与えられ、かつ種々の制御レジスタが含まれる。図２はデバッグ・コプロセッサＣＰ１４を示す。
【００２６】
デバッグ・コプロセッサ６は、１バンクのウォッチポイント・レジスタ１６及び１バンクのブレークポイント・レジスタ１８を含む。デバッグ・コプロセッサ６内のウォッチポイント・レジスタ１６及びブレークポイント・レジスタ１８は、ウォッチポイント及びブレークポイント・アドレスをそれぞれ記憶する。各ウォッチポイント・レジスタ１６及びブレークポイント・レジスタ１８には、それぞれの制御レジスタ２０、２２が関連されている。これらの制御レジスタ２０、２２は、命令バスＩＢ及びデータ・バスＤＢとそれぞれのブレークポイント及びウォッチポイント値との比較のために適用されるマスク値のような制御データを記憶する。更に、これらの制御レジスタは、ブレークポイント又はウォッチポイントが活性となるのはどの動作モードかを表す値と共に、関連されるブレークポイント又はウォッチポイントをエネーブル又はディセーブル（ｄｉｓａｂｌｅ：不能状態）にするフラグを記憶することができる。
【００２７】
ウォッチポイント・レジスタ１６からのウォッチポイント値は、それぞれのウォッチポイント比較器２４によりデータ・バスＤＢ上のデータ・アドレスと比較され、一方、ブレークポイント・レジスタ１８からのブレークポイント値は、ブレークポイント比較器２６により命令バスＩＢ上の命令アドレスと比較される。ウォッチポイントの一致又はブレークポイントの一致が確認されると、これがウォッチポイント・ヒット信号ＷＰＨ又はブレークポイント・ヒット信号ＢＰＨにより残りの回路に通知される。更に、デバッグ・エネーブル信号ＤＥが発生される。ウォッチポイント・ヒット信号ＷＰＨ、ブレークポイント・ヒット信号ＢＰＨに及びデバッグ・エネーブル信号ＤＥは、デバッグ・コプロセッサ６とメイン・プロセッサ４との間に存在するインターフェースの一部とみなすことができ、メイン・プロセッサ・ステータスを示すため、コアは停止すべきことを示すため、又はコアは再起動すべきことを示すために付加的な信号を含めることもできる。
【００２８】
更に、デバッグ・コプロセッサ６は、コプロセッサ・バスＣＰに接続されたデバッグ・ステータス制御レジスタＤＳＣＲを含む。以上で説明したウォッチポイント・レジスタ１６、ブレークポイント・レジスタ１８、制御レジスタ２０、２２、デバッグ・ステータス及び制御レジスタ（ＤＳＣＲ）２８は、全てＡＲＭ ＭＣＲ及びＭＲＣ命令のようなコプロセッサ命令により、書き込み及び読み出しが可能とされる。これは、メイン・プロセッサ４に付加的な回路を追加してこれに関連した潜在性によりクリティカル・パスを低速にすることなく、デバッグ・コプロセッサがコプロセッサ・インターフェースを介して構築されるのを可能にする。
【００２９】
図３はデータ転送レジスタＤＴＲを更に詳細に示す。特に、データ転送レジスタＤＴＲは、２つのレジスタ３０、３２から形成される。第１のレジスタ３０は、スキャン・チェーン入力ｔｄｉを介して書き込み可能であり、かつメイン・プロセッサ４により読み出し可能である。第２のレジスタ３２は、スキャン・チェーン出力ｔｄｏを介して読み出し可能であり、かつメイン・プロセッサ４により書き込み可能である。第１のレジスタ３０及び第２のレジスタ３２は、相互に書き込みの競合が発生し得ない双方向通信チャネルを形成している。
【００３０】
第２のレジスタ３２は、３２ビットのデータを記憶し、かつマルチプレクサ３４により形成された３３番目のビットを有する。マルチプレクサ３４は、コントローラ３６の制御により、４入力のうちの１つを選択するように動作する。第１の入力は、第２のレジスタ３２の主要部からの出力であり、これは、第２のレジスタ３２の主要部の内容を直列にスキャン出力するときに選択される。マルチプレクサ３４に対する他の３入力は、メイン・プロセッサ・クロック信号ｃｌｋ領域において動作しているシステムの一部と、デバッグ・クロック信号ｔｃｋ領域において動作しているシステムの一部との間でハンドシェーキングを取り扱う。特に、これらの信号は、ｔｄｏを介して外部デバッグ回路により読み出せるように調整されて、データ転送レジスタは一杯になる前に外部デバッグ回路に読み出さないようにされ、同様に、データ転送レジスタは正しくロードされるまではメイン・プロセッサ４により読み出さないようにされる。更に、外部デバッグ回路は、更なる試行を行ってデータをデータ転送レジスタＤＴＲにロードする前に、データ転送レジスタＤＴＲ内に配置したデータがメイン・プロセッサ４により使用されたか否かを判断するために、３３番目のビットを読み出すことができる。同一のことは、メイン・プロセッサ４がデータ転送レジスタＤＴＲにデータをロードしようとするのを、外部デバッグ回路により収集される前に、阻止することについてもいえる。更に、ＰｉｐｅＥｍｐｔｙ信号は、メイン・プロセッサ４の命令パイプライン１４が空であり、実行されるべき保留中の命令がないことを判断するために、デバッグ・システムによりポーリング可能な３３番目ビットとしてマルチプレクサ３４により選択されてもよい。
【００３１】
動作において、ラインｔｄｉ上のデータが直列に第１のレジスタ３０にスキャン入力されるに従って、第２のレジスタ３２からのデータ・ビットがラインｔｄｏにスキャン出力される。更に、その逆にデータが第２のレジスタ３２からラインｔｄｏに直列にスキャン出力されるに従って、ラインｔｄｉ上のデータ・ビットが第１のレジスタ３０に入力されることにも云える。従って、データが同時的にデータ転送レジスタＤＴＲから再生され、またこれに書き込まれてもよく、これによってデバッグ・オペレーションの速度が増加する。
【００３２】
図４はスキャン・チェーン・コントローラ１２によりメイン・プロセッサ４に供給されるデバッグ命令の実行を示す。メイン・プロセッサ４はメイン・プロセッサ・クロック信号ｃｌｋにより駆動され続けると共に、スキャン・チェーン・コントローラはデバッグ・クロック信号ｔｃｋにより駆動される。ステップ３８において、ブレークポイント命令の実行、外部的に供給されるブレークポイント信号、又はブレークポイント若しくはウォッチポイント・トリガの検出のように、デバッグ・トリガが発生する。ステップ４０において、デバッグ・トリガは、メイン・プロセッサ４に通常の処理を中断させる。次に、命令パイプライン１４は、ステップ４４、４６から形成されるループにおける１シーケンスのノー・オペレーション命令を実行する前に、ステップ４２において、存在する命令を空にする。ステップ４６は、スキャン・チェーン・コントローラ１２は、（この実施例では、Ｒｕｎ−Ｔｅｓｔ／Ｉｄｌｅステートを通る結果として）命令転送レジスタＩＴＲの内容が命令として命令パイプライン１４に発行されるべきことを示しているか否かを調べる。
【００３３】
ステップ４６を通過する前に、ステップ４８において、デバッグ・クロック信号ｔｃｋの制御により動作しているスキャン・チェーン・システムを含むシステムのデバッグ側は、まず、命令を命令転送レジスタＩＴＲへスキャン入力するために使用される。命令がスキャン入力されたときは、ステップ５０において、キャン・チェーン・コントローラは、Ｒｕｎ／Ｉｄｌｅステートを通って遷移し、システムのメイン・プロセッサ側に対して、命令が命令パイプライン１４を下って発行されるように命令転送レジスタＩＴＲにレディー（ｒｅａｄｙ：実行可能）状態であることを示す。
【００３４】
ステップ５０が完了したときは、ステップ５２が命令を命令転送レジスタＩＴＲから命令パイプライン１４に伝達するように機能し、ステップ５４においてこの命令が実行される。この命令が完了したときは、デバッグ命令完了信号がデバッグ側に返送されので（ステップ５６）、デバッグ側は、命令転送レジスタＩＴＲに配置された命令が完了したこと、更に所望ならば命令を命令転送レジスタＩＴＲに配置できることを知る。ステップ５８において、デバッグ側は、デバッグ命令完了信号の発行を認識し、ステップ６０において、主張した信号をクリアして、命令転送レジスタＩＴＲ内に実行されるのを待機している有効な命令が存在することを表示する。ステップ６２において、メイン・プロセッサ側は、デバッグ側が信号をクリアしたことを認識し、次いで処理をループ４４、４６に戻す。ステップ５６、５８、６０、６２は、異なるクロック領域内で動作する部分間のハンドシェーキング動作を効果的に実行し、これによって周波数差及び未知の位相関係を適合させる。
【００３５】
従って、回路のデバッグ部はデバッグ・クロック信号ｔｃｋにより動作し、一方、回路のメイン・プロセッサ部はメイン・プロセッサ・クロック信号ｃｌｋにより動作し、かつノー・オペレーション命令を実行することにより、及びハンドシェーキング処理により、異なるクロック速度に対処する。
【００３６】
図５はデバッグ命令の多重実行を示す。ステップ６４において、ＡＲＴ ＳＴＣ命令のような命令は、命令転送レジスタＩＴＲにスキャン入力される。ステップ６６において、データ値はデータ転送レジスタＤＴＲにスキャン入力される。ステップ６８において、スキャン・チェーン・コントローラ１２は、Ｒｕｎ−Ｔｅｓｔ／Ｉｄｌｅステートを介して遷移してデバッグ命令発行信号をセットする。メイン・プロセッサ側は、デバッグ命令発行信号のセットを検出し、かつステップ７０において、データ転送レジスタＤＴＲからメモリ（メモリ回路は図示なしの）へデータ値を移動させることにより、命令転送レジスタＩＴＲ（図４を参照すること）に記憶した命令を実行する。この命令が完了したときは、ステップ７２において、これをデバッグ側に知らせ、デバッグ側は更なるデータ値をデータ転送レジスタにスキャン入力する。命令転送レジスタＩＴＲ内に記憶した命令は、外部システムにより変更される必要はなく、従って他の命令の転送に時間が掛からない。次のデータ値が所定位置にあるときは、ステップ７４において、スキャン・チェーン・コントローラ１２は、Ｒｕｎ−Ｔｅｓｔ／Ｉｄｌｅステートを介してを遷移して処理を続ける。ステップ６８及び７０と同一のステップは、ブロック・メモリ転送を効率的に実行するために、多数回実行されてもよい。
【００３７】
図６はデバッグ・コプロセッサ６の一部を他の形式により示す。コプロセッサ命令は、バスＣＰｉｎｓｔｒを介してデバッグ・コプロセッサ６に伝達されて命令レジスタ７６に記録される。ラッチされた命令は、デコーダ７８に伝達され、デコーダ７８は更にデバッグ・コプロセッサ６の種々のレジスタ用及び出力マルチプレクサ８０用の制御信号を発生する。レジスタの書き込みは、ＡＲＭ ＭＣＲ命令に応答して行われ、またレジスタの読み出しは、ＡＲＭ ＭＣＲ命令に応答して行われる。レジスタの書き込みを実行すると、適当なレジスタのレジスタ・エネーブル信号が主張される。レジスタの読み出しを実行しているときは、適当なレジスタ出力がエネーブルされ、かつマルチプレクサ８０は、この出力を選択するように切り換えられる。
【００３８】
レジスタ８２は、システム・コプロセッサＣＰ１５レジスタであり、このレジスタは、デバッグ中にキャッシュ及びＭＭＵオペレーションを実行するために、外部デバッグ回路により使用可能にされている。デバッグ・ステータス制御レジスタ（ＤＳＣＲ）２８は、コプロセッサＣＰ１４レジスタＲ１として取り扱われ、書き込み、及び読み出しが共に可能とされている。命令転送レジスタＩＴＲは、図１に示したスキャン・チェーンのみによって書き込みが可能とされる。データ転送レジスタＤＴＲは、書き込み及び読み出しが可能とされる。データ転送レジスタは、コプロセッサＣＰ１４レジスタＲ５として取り扱われる。
【００３９】
ブレークポイント・レジスタ１８及びウォッチポイント・レジスタ１６は、それぞれ１つが示されている。これらは、それぞれの制御レジスタ２２、２０に関連されている。比較器２４、２６は、これらのレジスタに関連されて、デバッグ・イベント（ｄｅｂｕｇ ｅｖｅｎｔ）信号ＤＥを発生するために用いられる。
【００４０】
図７はスキャン・チェーン・システムの一部を概要的に示す。通常のＪＴＡＧオペレーションに従ってＴＡＰコントローラ８４が設けられている。外部直列データ及び出力は、ラインｔｄｉ及びｔｄｏにより得られる。ＪＴＡＧ命令は、命令レジスタＩＲ８６内に登録されてもよい。特定のスキャン・チェーンは、マルチプレクサ９０、８８に連係して動作するスキャン・チェーン選択レジスタ９２を使用して選択されてもよい。２つの部分のデータ転送レジスタ３０、３２は、相互に単一のスキャン・チェーンを構成している。更に、命令転送レジスタＩＴＲと、デバッグ・ステータス及び制御レジスタＤＳＣＲ２８は、個別的にスキャン・チェーンを形成している。更に、読み出し専用のＩＤＣｏｄｅスキャン・チェーン及びＢｙｐａｓｓスキャン・チェーンも設けられている。
【００４１】
図８は、データ転送レジスタＤＴＲの一部である第２のｗＤＴＲレジスタ３２の制御に係わるハンドシェーキングの一部として、スキャン・チェーン・コントローラ１２とメイン・プロセッサ４との間で伝達される信号のタイミングを１例により示す。図８において、ｓｅｔ ｔｅｒｍ（タームをセット）は、メイン・プロセッサ・クロック信号領域において動作しているメイン・プロセッサ４により制御されており、またｃｌｅａｒ ｔｅｒｍ（タームをクリア）は、デバッグ・クロック信号領域において動作しているスキャン・チェーン・コントローラ１２により制御されている。更に詳細には、ｓｅｔ ｔｅｒｍ及びｃｌｅａｒ ｔｅｒｍは、これら自身４ステートのステート・マシン（ｓｔａｔｅ ｍａｃｈｉｎｅ）によりそれぞれ制御されている（異なるそれらのステートは、図８に２ディジットの２進数により表されている）。
【００４２】
動作において、メイン・プロセッサ４は、まずｗＤＴＲレジスタ３２に書き込み、ｓｅｔ ｔｅｒｍをローからハイに遷移させて、ｗＤＴＲフルを主張させる（ここでは、ＤＴＲレジスタの３３番目ビットとして、ｗＤＴＲフル信号をマルチプレクサ３４により選択することができる）。ｗＤＴＲフル・インジケータの特定バージョンは、ｔｃｋ領域のみに存在する。外部デバッグ回路は、ＤＴＲレジスタの３３番目ビットをポーリングして収集すべきデータが存在することを示すこの遷移について監視する。更に、メイン・プロセッサ４がそのｃｌｋ領域において使用するためのインジケータも存在する。
【００４３】
そこで、デバッグ側は、ｗＤＴＲレジスタ３２を読み出し、これが完了すると、ｃｌｅａｒ ｔｅｒｍがローからハイへ遷移してｓｅｔ ｔｅｒｍステート・マシンに対してデータを読み出したことを表示する。ｃｌｅａｒ ｔｅｒｍにおける遷移は、シンクロナイザを介してｓｅｔ ｔｅｒｍステート・マシンに伝達され、これがｓｅｔ ｔｅｒｍをハイからローに遷移させることにより応答して、ｃｌｅａｒ ｔｅｒｍにおける変化を認識したことをｃｌｅａｒ ｔｅｒｍステート・マシンに対して表示する。ハイからローへのｓｅｔ ｔｅｒｍにおける遷移は、シンクロナイザによりｃｌｅａｒ ｔｅｒｍステート・マシンへ逆に伝達され、ｗＤＴＲレジスタ３２を読み出したという情報が肯定応答されたときに、このステート・マシンがｃｌｅａｒ ｔｅｒｍをハイからローへ遷移させる。ハイからローへのクリア信号の遷移は、最終的にシンクロナイザにより、ｃｌｅａｒ ｔｅｒｍステート・マシンからｓｅｔ ｔｅｒｍステート・マシンへ伝達されて、ｓｅｔ ｔｅｒｍステート・マシンをリセットさせるので、所望のときは他の値をｗＤＴＲレジスタ３２に書き込めるようにメイン・プロセッサ４に対してシステムがレディーとなる。
【００４４】
図３に示すｒＤＴＲＦｕｌｌインジケータは、ｒＤＴＲレジスタ３０に関連し、かつｔｃｋ及びｃｌｋ信号が交換されると共に、読み出し及び書き込みが交換されると同様に作成されてもよい。
【００４５】
図９は、（デバッグＲＥＳＴＡＲＴ命令に応答して）図４及び図５に示すように動作しているデバッグ・ステートからメイン・プロセッサ４を再起動させるときに、メイン・プロセッサ４とデバッグ・システムとの間で伝達されるハンドシェーキング信号のタイミングを示す。
【００４６】
ＲｅｓｔａｒｔＣｏｒｅ信号はｔｃｋ領域に存在し、ＤｂｇＩｎＤｅｂｕｇ及びＣｏｒｅＩｎＤｅｂｕｇ信号はｃｌｋ領域に存在する。再起動オペレーションにおける第１ステップとして、デバッグ制御ロジックは、ＣｏｒｅＲｅｓｔａｒｔｅｄビットを０にセットし、かつＲｅｓｔａｒｔＣｏｒｅ信号をローからハイに遷移することにより、ＲＥＳＡＲＴ信号に対して応答する。ＲｅｓｔａｒｔＣｏｒｅにおけるこの遷移は、シンクロナイザを介してメイン・プロセッサ４に伝達され、メイン・プロセッサ４はＤｂｇＩｎＤｅｂｕｇ信号をハイからローへ遷移させることにより応答する。このビットは、続いてシンクロナイザを通ってデバッグ制御ロジックに逆に伝達され、デバッグ制御ロジックではＣｏｒｅＲｅｓｔａｒｔｅｄ信号を非主張にする。ＣｏｒｅＲｅｓｔａｒｔｅｄビットは、コアが再起動されたことを確認するために外部デバッグ回路によりポーリングされる。ＲｅｓｔａｒｔＣｏｒｅ信号における遷移は、シンクロナイザを介してメイン・プロセッサ４に伝達され、メイン・プロセッサ４はＣｏｒｅＩｎＤｅｂｕｇ信号をハイからローに遷移させることにより応答して、メイン・プロセッサ４をデバッグ・ステートから通常ステートに遷移する。
【００４７】
図８及び９は、メイン・プロセッサ・クロック信号領域において動作しているメイン・プロセッサ側とデバッグ・クロック信号において動作しているデバッグ側との間で伝達されるハンドシェーキング制御信号の２例を示す。同様にして、更なる制御信号間のハンドシェーキングを取り扱うことができる。
【００４８】
以上で説明したデバッグ機構の更に詳細な図は、概要的にＡＲＭ１０マイクロプロセッサ及びＡＲＭマイクロプロセッサのアーキテクチャーに関係する以下のマイクロアーキテクチャー仕様により提供される。
【００４９】
１．０ 基本目的
１）多数の実施を通して展開するＡＲＭプロセッサに対して将来の証明デバッグ・インターフェースを提供する、
２）ＪＴＡＧハードウェア及び対象に基づくソフトウェアからハードウェアデバッグ設備へのアクセスを提供する。
【００５０】
２．０ 背景
ＡＲＭ１０内のデバッグ・ロジックは、イン・サーキット・エミュレータに見られるものと同様の機能をサポートする能力、即ちブレークポイント及びウォッチポイントを設定する能力をユーザに提供して、プロセッサ及びシステム・ステートを点検して変更し、かつ関係するポイント周辺のプロセッサ活動のトレースを調べる。通常、ホスト・コンピュータ上のソフトウェアは、デバッガに対するインターフェースとして機能して、オン・チップ・ロジックが要求する特定のプロトコルからエンド・ユーザを完全に取り除く。
【００５１】
ＡＲＭ１０は、ＡＲＭ７及びＡＲＭ９により提供されるデバッグ・インターフェースをクリーン・アップするための機会である。即ち、未使用の機能を削除し、かつ新しい機能を付加することである。ＡＲＭ１０のパイプラインの複雑性のために、命令をパイプラインに詰め込むＡＲＭ７及びＡＲＭ９の方法は、２つの損失がある。即ち、ＩＣＥｍａｎソフトウェアをより複雑化し、またＡＲＭ１０が避けなければならないハードウェア・クリティカル・パスの包含がある。
【００５２】
ＡＲＭ１０にマスク・レジスタ、チェーン又はレンジ機能は存在しない。データに依存するウォッチポイントやブレークポイントも存在しない。しかしながら、ＡＲＭ１０は、ブレークポイント命令を実施して、ごく一般的な使用をデータ依存性に置き換え、これが命令ストリームにおけるブレークポイントに対するユーザ指定命令を認識させる。われわれはより実際的なブレークポイント・レジスタを利用することによりマスク・レジスタを削除した。
【００５３】
３．０ ＡＲＭ１０デバッグの使用
ＡＲＭ１０についてのデバッグ及び将来マシン（以下単にＡＲＭ１０デバッグと呼ぶ）は、コプロセッサ１４（ＣＰ１４）周辺に集められている。対象について実行されるソフトウェア、即ちデバッグ・モニタ、又はオペレーティング・システム・デバッグ（以下デバッグ・タスクと呼ぶ）は、単にＣＰ１４レジスタに書き込むことによりデバッグ・ハードウェア機能をアクセスすることができる。レジスタ・ブレークポイントは、例外を発生させることができ、対象ハンドラーがレジスタ・ブレークポイントをヒットしたときに制御権を取獲得できるようにする。デバッグ機能は、対象上のソフトウェア及びＪＴＡＧポートの両者を通ってアクセスされる。ＪＴＡＧプログラミングは、１度に１プロセッサ命令を供給することにより実行され、オプションによりデータ・バーストが続く。しかし、デバッグ・ステップに入る、抜け出す及び実行するためのインターフェースは、はるかに明確かつより正確に定義される。
【００５４】
３．１コプロセッサ１４
３．１．１ ＣＰ１４インターフェース
コプロセッサ・インターフェースは、ＡＲＭコアとデバッガとの間の共通機構として動作し、ＣＰ１４及びＣＰ１５の両者のアクセスは、このブロックにより処理される。このコプロセッサ・インターフェースは、ＶＦＰコプロセッサ・インターフェースと同様であるが、しかし少数の制御信号及び狭帯域バスを有する。このインターフェースは、次の信号を含む。
入力： 説明：
ＡＳＴＯＰＣＰＥ 実行中のＡＲＭストール（ｓｔａｌｌ）を表示
ＡＳＴＯＰＣＰＤ デコード中のＡＲＭストールを表示
ＡＣＡＮＣＥＬＣＰ ＣＰでの命令を取り消す
ＡＦＵＬＳＨＣＰ コプロセッサ・パイプラインをフラッシュ
ＬＤＣＭＣＲＤＡＴＡ ＡＲＭコアからの入力データを含むバス
ＣＰＩＮＳＴＲ［３１：０］ ＡＲＭからコプロセッサへの命令
ＣＰＳＵＰＥＲ コプロセッサ・スーパバイザ・モード
ＣＰＬＳＬＥＮ ＬＳＵに対する長さインジケータ
ＣＰＬＳＳＷＡＰ ＬＳＵに対するインジケータを入れ換え
ＣＰＩＮＳＴＲＶ ＣＰに対する有効命令を表示する
ＣＰＲＳＴ コプロセッサのリセット
ＣＰＣＬＫ コプロセッサ・クロック
出力：
ＣＰＢＵＳＹＤ デコードにおけるビジー待機
ＣＰＢＵＳＹＥ 実行中のビジー待機
ＣＰ１５ＳＥＲＩＡＬＩＺＥ コアにデコードにおける命令を強制的にホールドＣＰＢＯＵＮＣＥＥ ＣＰは命令を拒否
ＳＴＣＭＲＣＤＡＴＡ バスはＡＲＭコアに対しての出力データを含む
【００５５】
３．１．２ＣＰ１４レジスタ／マップ
全てのデバッグ・ステートはレジスタとしてＣＰ１４にマッピングされる。３ＣＰ１４レジスタ（Ｒ０、Ｒ１、Ｒ５）は、特権モードにおいてデバッグ・タスクによりアクセス可能とされ、また４レジスタ（Ｒ０、Ｒ１、Ｒ４、Ｒ５）は、スキャン・チェーンとしてアクセス可能である。残りのレジスタは、特権モードでのみデバッグ・タスクからアクセス可能である。空間は１６ブレークポイント及び１６ウォッチポイントまで確保されている。特定の実施計画を２から１６までの任意の数で実施することができる。ＡＲＭ１０のときは、６命令側ブレークポイント及び２データ側ウォッチポイントが存在する。
【００５６】
ブレークポイント・レジスタは、特権モードにおいてリセットから起動し、ディセーブルされる。Ｄｅｂｕｇ ＩＤ Ｒｅｇｉｓｔｅｒ（Ｒ０）は読み出し専用であることに注意すべきである。更に、ブレークポイント及びウォッチポイント・レジスタにおける一致ビットは、プログラマが適当なビットをセットすることにより１フィールド（例えば、サイズ、スーパバイザ／ユーザ）を指定できるようにする符号化を含むことも認識すべきである。ユーザは、一致についてフィールドが考慮されていないときは、ビットを全て１にセットする必要がある。
【００５７】
デバッギングのディセーブルには、２つの方法がある。ＤＳＣＲにおけるＧｌｏｂａｌ Ｅｎａｂｌｅビットは、ソフトウェアを介して全てデバッグ機能をエネーブル又はディセーブルするために使用される。このビットは、リセットによりクリアされ、これは、全てのデバッグ機能がディセーブルされることを意味する。全ての外部デバッグ要求はコアにより無視され、またＢＫＰＴ命令はノー・オペレーションとして処理される。このモードの目的は、オペレーティング・システムがタスク・スイッチング・シーケンスの一部として個々のタスクについてのデバッグ処理を速やかにエネーブル及びディセーブル可能にすることである。加えて、ＤＢＧＥＮピンは、ＡＲＭ１０のデバッグ機能をディセーブル可能にする。デバッグ処理を必要としないときにのみ、この信号をＬＯＷに接続する必要がある。
【００５８】
多数のレジスタをサポートするために、ＣＲｍ及びｏｐｃｏｄｅ２フィールドは、デバッグ・レジスタ番号を符号化するために使用される。ただし、このレジスタ番号は、｛ｏｐｃｏｄｅ２，ＣＲｍ｝である。
【００５９】
Ｒ０：Ｒｅｂｕｇ ＩＤ Ｒｅｇｉｓｔｅｒ
ＤＤＩＲ［３１：２４］ ＣＰ１５ Ｒ０のような設計者コード
ＤＤＩＲ［２３：２０］ ゼロ
ＤＤＩＲ［１９：１６］ デバッグ・アーキテクチャーのバージョン、ＡＲＭ１０＝０ｂ０００
ＤＤＩＲ［１５：１２］ 実施したレジスタ・ブレークポイント数
ＤＤＩＲ［１１：１８］ 実施したウォッチポイント数
ＤＤＩＲ［７：４］ ゼロ
ＤＤＩＲ［３：０］ 改訂番号
【００６０】
ＤＳＣＲ［７］ ｒＤＴＲバッファ・フル−読み出し専用
このビットは、通常、ＪＴＡＧデバッガがこのバッファにデータを書き込んだ結果としてコア用のｒＤＴＲに読み出すデータが存在するときに、セットされる。ゼロはバッファ内に読み出すデータがないことを示す。
ＤＳＣＲ［１５：８］ 予備
ＤＳＣＲ［１６］ ベクトル・トラップ・エネーブル（Ｖｅｃｔｏｒ Ｔｒａｐ Ｅｎａｂｌｅ）−リセット
ｎＴＲＳＴ＝０又はＴＡＰコントローラがリセット状態のときはリセットされる。
ＤＳＣＲ［１７］ ベクトル・トラップ・エネーブル−未定義命令
ｎＴＲＳＴ＝０又はＴＡＰコントローラがリセット状態のときはリセットされる。
ＤＳＣＲ［１８］ ベクトル・トラップ・エネーブル−ＳＷＩ
ｎＴＲＳＴ＝０又はＴＡＰコントローラがリセット状態のときはリセットされる。
ＤＳＣＲ［１９］ ベクトル・トラップ・エネーブル−フェッチ中断（ａｂｏｒｔ）
ｎＴＲＳＴ＝０又はＴＡＰコントローラがリセット状態のときはリセットされる。
ＤＳＣＲ［２０］ ベクトル・トラップ・エネーブル−データ中断
ｎＴＲＳＴ＝０又はＴＡＰコントローラがリセット状態のときはリセットされる。
ＤＳＣＲ［２１］ 予備
ＤＳＣＲ［２２］ ベクトル・トラップ・エネーブル−ＩＲＱ
ｎＴＲＳＴ＝０又はＴＡＰコントローラがリセット状態のときはリセットされる。
ＤＳＣＲ［２３］ ベクトル・トラップ・エネーブル−ＦＩＱ
ｎＴＲＳＴ＝０又はＴＡＰコントローラがリセット状態のときはリセットされる。
ＤＳＣＲ［３０：２４］ 予備
ＤＳＣＲ［３１］ グローバル・デバッグ・エネーブル（Ｇｌｏｂａｌ Ｄｅｂｕｇ Ｅｎａｂｌｅ）−システム・リセットによりリセットされる
０＝全てのデバッグ処理機能（ブレークポイント、ウォッチポイント等）をディセーブルする。
１＝全てのデバッグ処理機能をエネーブルする。
注意：ベクトル捕捉はブレークポイントよりも高い優先順位を有する。
【００６１】
Ｒ２−Ｒ４：予備
Ｒ５：データ転送レジスタ（Ｄａｔａ Ｔｒａｎｓｆｅｒ Ｒｅｇｉｓｔｅｒ）
ＤＴＲ［３１：０］ データ
（注意：ＤＴＲは、物理的に個別的な２レジスタ、即ちｒＤＴＲ（読み出し）及びｗＤＴＲ（書き込み）からなる。これらの使用の説明については３．２．７及び３．２．１０を参照すべきである。）
Ｒ６−Ｒ６３：予備
Ｒ６４−Ｒ７９：レジスタ・ブレークポイント（Ｒｅｇｉｓｔｅｒ Ｂｒｅａｋｐｏｉｎｔ）値
【００６２】
ＢＶ［３１：０］ レジスタ・ブレークポイント値
Ｒ８０−Ｒ９６：レジスタ・ブレークポイント制御レジスタ（Ｒｅｇｉｓｔｅｒ Ｂｒｅａｋｐｏｉｎｔ Ｃｏｎｔｒｏｌ Ｒｅｇｉｓｔｅｒｓ）
ＢＣＲ［０］ システム・リセットによるクリアをエネーブル
０＝レジスタをディセーブル
１＝レジスタをエネーブル
ＢＣＲ［２：１］ スーパバイザ（Ｔｒａｎｓ） アクセス
００−予備
１０−特権付き
０１−ユーザ
１１−不定
ＢＣＲ［４：３］ サム（Ｔｈｕｍｂ）モード
００−予備
１０−ＡＲＭ命令
０１−サム命令
１１−不定
Ｒ９６−Ｒ１１１ ウォッチポイント値
ＷＶ［３１：０］ ウォッチポイント値
Ｒ１１２−Ｒ１２７：ウォッチポイント制御レジスタ
ＷＣＲ［０］ エネーブル
０＝レジスタをディセーブル（システム・リセットによりクリア）
１＝レジスタをエネーブル
ＷＣＲ［２：１］ スーパバイザ（Ｔｒａｎｓ）
００−予備
１０−特権付き
０１−ユーザ
１１−不定
ＷＣＲ［４：３］ ロード／ストア／不定
００−予備
１０−ロード
０１−ストア（Ｓｔｏｒｅ）
１１−不定
ＷＣＲ［７：５］ バイト／ハーフワード／ワード／不定サイズ
０００−予備
００１−バイト
０１０−ハーフワード
０１１−バイト又はハーフワード
１００−ワード
１０１−ワード又はバイト
１１０−ワード又はハーフワード
１１１−任意のサイズ
ＷＣＲ［８］ 予備
ＷＣＲ［１０：９］ Ａｄｄｒ［１：０］へのアドレス・マスク
０＝比較にビットを含む
１＝比較にビットを除外
ＷＣＲ［１１］ 予備
【００６３】
３．１．３ ＣＰ１４命令
下記はＡＲＭ１０におけるＣＰ１４用の適正命令専用である。ＬＤＣ及びＳＴＣ命令は、ＤＴＲレジスタに対してのみ有効である。他の全ての命令は、拒絶（ｂｏｕｎｃｅ）される。
【００６４】
【表１】
３．２ デバッグに対するハードウェア・インターフェース
３．２．１ ホールト（Ｈａｌｔ）・モードへの進行及び抜け出し
ホールト・モードは、ＤＳＣＲの１〜３０ビットを書き込むことによりエネーブルされ、ＪＴＡＧデバッガによってのみ実行可能にされる。このモードがエネーブルにされた場合に、下記の事象のうちの１つが発生したときは、プロセッサはホールトになる（ソフトウェアにおいて例外となることに対比される）。
ａ）ＥＤＢＧＲＱを主張
ｂ）ＪＴＡＧインターフェースを介してＨＡＬＴ命令をスキャン入力した。ＴＡＰコントローラは、コアにＨＡＬＴコマンドを発行するためにＲｕｎ／Ｉｄｌｅを伝達する必要がある。
ｃ）例外が発生し、かつ対応するベクトル・トラップ・エネーブル・ビットをセット
ｄ）レジスタ・ブレークポイントをヒット
ｅ）ウォッチポイントをヒット
ｆ）ＢＫＰＴ命令がＡＲＭパイプラインの実行段に到達
【００６６】
デバッグ・ステートに入ると、ＤＳＣＲにおけるコア・ホールト（Ｃｏｒｅ Ｈａｌｔｅｄ）ビットがセットされる。デバッガは、推定により、このビットがハイになるまで、Ｃａｐｔｕｒｅ−ＤＲ及びＳｈｉｆｔ−ＤＲを通過することによりＤＳＣＲをポーリングする。この時点において、デバッガは、なぜコアはホールトしたのかを判断し、かつマシン・ステートを保存する。ＭＳＲ命令はモードを変更し、マシンに全てバンク済みのレジスタに対するアクセスを獲得をするために使用されてもよい。デバッグ・ステートにある間は、ＰＣは増加されず、外部割り込みは無視され、かつ全ての命令は、命令転送レジスタ（Ｉｎｓｔｒｕｃｔｉｏｎ Ｔｒａｎｓｆｅｒ Ｒｅｇｉｓｔｅｒ）から読み出される（スキャン・チェーン４）。
【００６７】
デバッグ・ステートからの抜け出しは、再起動（ＲＥＳＴＡＲＴ）命令においてＪＴＡＧインターフェースを介してスキャン入力することにより、実行される。デバッガは、再起動する前にコアがデバッグ・ステートに入る方法に従ってＰＣを調整する。下記の表は、コアが各場合についてホールトする時点でＰＣの値を表示する。
【００６８】
【表２】
ステート・マシンがＲｕｎ−Ｔｅｓｔ／Ｉｄｌｅステートに入ると、通常の動作が再開する。ステート・マシンがＲｕｎ−Ｔｅｓｔ／Ｉｄｌｅとなるまで待機する遅延は、マイクロプロセッサ・システムにおける他の装置に、直接影響することなく、条件を設定可能にする。全てのプロセッサは、Ｒｕｎ−Ｔｅｓｔ／Ｉｄｌｅステートに入ると、一斉にオペレーションを再開する。ＲＥＳＴＡＲＴシーケンスを完了すると、コア再起動（Ｃｏｒｅ Ｒｅｓｔａｒｔｅｄ）ビットがセットされる。
【００７０】
コアは、ＲＥＳＴＡＲＴコマンドを発行する前に、「命令完了」（Ｉｎｓｔｒｕｃｔｉｏｎ Ｃｏｍｐｌｅｔｅ）ビット（ｗＤＴＲ［０］）をポーリングして最後の命令を何らの問題（可能とする中断など）なしに完了したことを確認する必要があることに注意すべきである。デバッガは、コアにＲＥＳＴＡＲＴ命令を発行した後に、何か他のことを実行する前は、ポーリングして実際に再起動したことを調べる必要がある。デバッグ・ロジックにはシンクロナイザ及びハンドシェク・ラインが存在し、デバッグ・ロジックはこれらのハンドシェーキング・ラインをクリアできるようにクロック（特に、ＴＣＫ）を備えている必要がある。デバッグ・ロジックがＤｂｄＲｅｓｔａｒｔラインをクリアする機会が来る前に、クロックをターン・オフすれば、コアはデバッグ・ステートにとどまって再度起動しない。コア再起動ビットを読み出す操作は、必要なラインをクリアするのに十分なクロックを供給する。
【００７１】
３．２．２ ＪＴＡＧポート及びテスト・データ・レジスタ
ロジックのＪＴＡＧ部は、ＩＥＥＥ１１４９．１インターフェースを実施し、かつ装置ＩＤレジスタ、バイパス・レジスタ、及び４ビットの命令レジスタをサポートする。加えて、下記の公開命令がサポートされる。
【００７２】
【表３】
デバッグ・レジスタに対するアクセスは、ソフトウェア（ＭＣＲ命令による）又はＪＴＡＧポートを通して得られる。ハードウェア・デバッグ機構は、基本的に、ＡＲＭ７／ＡＲＭ９と同様であるが、しかしＡＲＭ１０デバッグは全てのクロッキングを隠し、かつデバッガからパイプラインの深さを発行する。
【００７４】
ＪＴＡＧ（Ｒ１、Ｒ５）を介してアクセス可能なＣＰ１４内のレジスタは、ＥＸＴＥＳＴ命令を使用して書き込まれる。レジスタＲ０、Ｒ１及びＲ５は、ＩＮＴＥＳＴ又はＥＸＴＥＳＴ命令により読み出される。これは、ＩＮＳＴ命令のみが使用され、かつチェーンにおけるｒ／ｗビットが実行されるべきオペレーションを決定した点でＡＲＭ９と異なる。
【００７５】
３．２．２．１ バイパス・レジスタ
目的：ＴＤＩとＴＤＯとの間にパスを設けることによりスキャン・テスト中の装置をバイパスする。
長さ：１ビット
動作モード：バイパス命令が命令レジスタにおける現在命令であるときは、直列データがＳｈｉｆｔ−ＤＲステートにおける１ＴＣＫサイクルの遅延により、ＴＤＩからＴＤＯへ転送される。バイパス・レジスタからの並列出力は存在しない。ロジック０は、Ｃａｐｕｔｕｒｅ−ＤＲ（ＤＲの捕捉）ステートにおいてバイパス・レジスタの並列入力からロードされる。
順序：ＴＤＩ−［０］−ＴＤ０
【００７６】
３．２．２．２ 装置ＩＤ Ｃｏｄｅ レジスタ
目的：ＡＲＭ７Ｔ及びＡＲＭ９ＴからＡＲＭ１０を識別するために、ＴＡＰコントローラＩＤが固有なので、Ｍｕｌｔｉ−ＩＣＥがどのプロセッサに接続されているのかを容易に調べることができる。このＩＤレジスタは、チップの縁に経路設定されるので、相手側はピンをハイ値又はロー値へ接続することにより、これら自身のＩＤ番号を作成することができる。ＡＲＭ１０２００用の総称ＩＤは、初期的には、０ｘ０１０２０Ｆ０Ｆとなる。全ての相手側−特定装置は、下記形式のＩＤ番号により識別される。
バージョン 部品番号 製造者ＩＤ
ＬＳＢ
［３１：２８］ ［２７：１２］ ［１１：１］ １
【００７７】
長さ：３２ビット
動作モード：ＩＤＣＯＤＥ命令が現在値であるときは、ＴＤＩ及びＴＤＯとの間の直列パスとして、ＩＤレジスタが選択される。ＩＤレジスタからの並列出力は存在しない。３２ビットのＩＤコードは、Ｃａｐｔｕｒｅ−ＤＲステート中に並列入力からレジスタにロードされる。
順序：ＴＤＩ−［３１］［３０］．．．［１］［０］−ＴＤ０
【００７８】
３．２．２．３ 命令レジスタ
目的：現在のＴＡＰ命令を変更する
長さ：４ビット
動作モード：Ｓｈｉｆｔ−ＤＲステートのときは、命令レジスタがＴＤＩとＴＤＯとの間に直列パスとして選択される。Ｃａｐｔｕｒｅ−ＤＲステートでは、０００１二進値がこのレジスタにロードされる。これは、Ｓｈｉｆｔ−Ｉ中に（最下位ビットが最初に）シフト出力され、一方新しい命令が（最下位ビットが最初に）スキャン入力される。Ｕｐｄａｔｅ−ＩＲステートでは、命令レジスタ内の値が現在命令となる。リセットにより、ＩＤＣＯＤＥが現在命令となる。
順序：ＴＤＩ−［３］［２］［１］［０］−ＴＤ０
【００７９】
３．２．２．４ スキャン・チェーン選択（Ｓｃａｎ Ｃｈａｉｎ Ｓｅｌｅｃｔ）レジスタ
目的：現在の活性スキャン・チェーンを変更する。
長さ：５ビット
動作モード：現在命令としてＳＣＡＮ Ｎを選択した後、Ｓｈｉｆｔ−ＤＲステートのときは、ＴＤＩとＴＤＯとの間の直列パスとしてスキャン・チェーン選択レジスタが選択される。Ｃａｐｔｕｒｅ−ＤＲステートでは、１００００二進値がこのレジスタにロードされる。Ｓｈｉｆｔ−ＤＲでは、これが（最下位ビットが最初に）シフト出力され、同時に、（最下位ビットを最初にして）新しい値がシフト入力される。Ｕｐｄａｔｅ−ＤＲステートでは、レジスタ内の値は、レジスタにおける値がスキャン・チェーンを選択して現在活性のスキャン・チェーンになる。ＩＮＴＥＳＴのような更なる全ての命令は、このスキャン・チェーンに適用される。現在の選択されたスキャン・チェーンは、ＳＣＡＮ Ｎ命令が実行されたとき、又はリセットが発生したときにのみ、変更される。リセットにより、スキャン・チェーン３が活性なスキャン・チェーンとして選択される。現在の選択されたスキャン・チェーン数は、ＳＣＲＥＧ［４：０］出力バスに反映される。ＴＡＰコントローラは、ＡＲＭ１０２０マイクロセル内のものに加えて、外部スキャン・チェーンを駆動するために使用されてもよい。外部スキャン・チェーンは、これに対して番号及び制御信号が割り付けられる必要があり、ＳＣＲＥＧ［４：０］、ＩＲ［３：０］、ＴＡＰＳＭ［３：０］、及びＴＣＫから導き出されてもよい。
順序：ＴＤＩ−［４］［３］［２］［１］［０］−ＴＤ０
【００８０】
３．２．２．５ Ｓｃａｎ Ｃｈａｉｎ ０
目的：デバッグ。
長さ：３２ビット
このＳｃａｎ Ｃｈａｉｎは、ＣＰ１４ Ｒｅｇｉｓｔｅｒ ０、ＤｅｂｕｇＩＤ Ｒｅｇｉｓｔｅｒである。
順序：ＴＤＩ−［３１］［３０］．．．［１］［０］−ＴＤ０
【００８１】
３．２．２．６ Ｓｃａｎ Ｃｈａｉｎ １
目的：デバッグ。
長さ：３２ビット
このＳｃａｎ Ｃｈａｉｎは、ＣＰ１４ Ｒｅｇｉｓｔｅｒ １、ＤＳＣＲである。ＤＳＣＲ［１５：０］のみが読み出されることに注意すべきである。下記のビットは、Ｃｈａｉｎ １に対して定義される。
ＤＳＣ［０］ Ｃｏｒｅ Ｈａｌｔｅｄ−読み出し専用
ＤＳＣ［１］ Ｃｏｒｅ Ｒｅｓｔａｒｔｅｄ−読み出し専用
ＤＳＣ［４：２］ デバッグ・エントリ方法−読み出し専用
０００ ＪＴＡＧ ＨＡＬＴ命令が発生
００１ レジスタ・ブレークポイントが発生
０１０ ウォッチポイントが発生
０１１ ＢＫＰＴ命令が発生
１００ 外部デバッグ要求が発生
１０１ ベクトル捕捉が発生
１１０，１１１ 予備
ＤＳＣＲ［５］ 過去にしばしば破棄が発生−ＭＣＲによってのみ書き込み可能
ＭＣＲ このビットは容易ではない。これはＭＣＲによりＭＳＣＲにクリアされ、ここで、このビットは０である。
ｎＴＲＳＴ＝０のとき、又はＴＡＰコントローラがリセット・ステートときはリセット
ＤＳＣＲ［６］ ｗＤＴＲバッファが空−読み出し専用
このビットは、ｗＤＴＲバッファが空であり、コアが更にデータが書き込めることを意味するコアのインジケータである。これは、ＪＴＡＧデバッガがＥＸＴＥＳＴによりＣａｐｔｕｒｅＤＲを通ることによりＤＴＲをポーリングするのか否かを調べる反転ビットである。ＪＴＡＧ信号とコア信号との間のタイミングは異なっているので、デバッガは、このビットを使用してｗＤＴＲが空であるか又はフルであるかを判断してはならない。
ＤＳＣＲ［７］ ｒＤＴＲバッファ・フル−読み出し専用
このビットは、ｒＤＴＲバッファがフルであり、デバッガがこれにデータが書き込んだことを意味するコアのインジケータである。これは、ＪＴＡＧデバッガがＩＮＴＥＳＴによりＣａｐｔｕｒｅＤＲを通ることにより、ＤＴＲをポーリングするのか否かを調べる反転ビットである。ＪＴＡＧ信号とコア信号との間のタイミングは異なっているので、デバッガはこのビットを使用してｗＤＴＲが空であるか又はフルであるかを判断してはならない。
ＤＳＣＲ［１５：８］ 予備
ＤＳＣＲ［１６］ ベクトル・トラップ・エネーブル−リセット−読み出し専用
ｎＴＲＳＴ＝０のときはリセット、ＴＡＰコントローラがリセット・ステートのときは、リセット
ＤＳＣＲ［１７］ ベクトル・トラップ・エネーブル−未定義命令−読み出し専用
ｎＴＲＳＴ＝０のときはリセット、ＴＡＰコントローラがリセット・ステートのときは、リセット
ＤＳＣＲ［１８］ ベクトル・トラップ・エネーブル−ＳＷＩ−読み出し専用ｎＴＲＳＴ＝０又はＴＡＰコントローラがリセット・ステートのときは、リセット
ＤＳＣＲ［１９］ ベクトル・トラップ・エネーブル−プリフェッチ中断（Ｐｒｅｆｅｔｃｈ Ａｂｏｒｔ）−読み出し専用
ｎＴＲＳＴ＝０又はＴＡＰコントローラがリセット・ステートのときは、リセット
ＤＳＣＲ［２０］ ベクトル・トラップ・エネーブル−データ中断−読み出し専用
ｎＴＲＳＴ＝０又はＴＡＰコントローラがリセット・ステートのときは、リセット
ＤＳＣＲ［２１］ ベクトル・トラップ・エネーブル−予備
ＤＳＣＲ［２２］ ベクトル・トラップ・エネーブル−ＩＲＱ−読み出し専用
ｎＴＲＳＴ＝０又はＴＡＰコントローラがリセット・ステートのときは、リセット
ＤＳＣＲ［２３］ ベクトル・トラップ・エネーブル−ＦＩＱ−読み出し専用
ｎＴＲＳＴ＝０又はＴＡＰコントローラがリセット・ステートのときは、リセット
ＤＳＣＲ［２６：２４］ 予備
ＤＳＣＲ［２７］ Ｃｏｍｍｓチャネル・モード
０＝Ｃｏｍｍｓチャネル不作動
１＝Ｃｏｍｍｓチャネル作動
ｎＴＲＳＴ＝０又はＴＡＰコントローラがリセット・ステートのときは、リセット
ＤＳＣＲ［２８］ サム・モード・インジケータ（５．０項を参照のこと）
ＤＳＣＲ［２９］ ＩＴＲ選択において命令を実行
０＝ディセーブル
１＝ＪＴＡＧ状態マシンがＲｕｎ−Ｔｅｓｔ／Ｉｄｌｅを通過するときは、ＩＴＲにおける命令をプリフェッチ・ユニットに送出
ｎＴＲＳＴ＝０のとき、又は、ＴＡＰコントローラがリセット・ステートのときは、セット
ＤＳＣＲ［３０］ Ｈａｌｔ／Ｍｏｎｉｔｏｒ（ホールト／モニタ）モード選択
０＝モニタ・モードをエネーブ
１＝ホールト・モードをエネーブル
ｎＴＲＳＴ＝０又はＴＡＰコントローラがリセット・ステートのときは、リセット
ＤＳＣＲ［３１］ グローバル・デバッグ・エネーブル（Ｇｌｏｂａｌ Ｄｅｂｕｇ Ｅｎａｂｌｅ）−システム・リセットによりクリア
０＝全てのデバッグ処理機能（ブレークポイント、ウォッチポイント等）をディセーブルにする。
１＝全てのデバッグ処理機能をエネーブルにする。
ｎＲＥＳＥＴ＝０のときは、リセット（コアのリセット・ライン）
これらのビットがコア用で、デバッガ用でないＤＳＣＲを反映しているので、通信チャネル・ビット、ｒＤＴＲフル及びｗＤＴＲ空は、デバッガから見えるものの反転であることに注意すべきである。
順序：ＴＤＩ−［３１］［３０］．．．［１］［０］−ＴＤ０
【００８２】
３．２．２．７ Ｓｃａｎ Ｃｈａｉｎ ２
目的：デバッグ
長さ：６５ビット
このスキャン・チェーンは、ＣＰ１４レジスタ４及び５の組み合わせである。レジスタ４内の命令完了（Ｉｎｓｔｒｕｃｔｉｏｎ Ｃｏｍｐｌｅｔｅ）ビットは、このチェーンに含まれないことに注意すべきである。これは、チェーン４にのみ現れる。
順序：ＴＤＩ−Ｒｅｇ４［３２］Ｒｅｇ４［３１］．．．Ｒｅｇ４［１］Ｒｅｇ５［３２］Ｒｅｇ５［３１］．．．Ｒｅｇ５［０］−ＴＤ０
【００８３】
１．２．２．８ Ｓｃａｎ Ｃｈａｉｎ ３
目的：外部境界スキャン・テストに使用できる。装置間テスト（ｉｎｔｅｒ−ｄｅｖｉｃｅ ｔｅｓｔｉｎｇ ：ＥＸＴＥＳＴ）及びコアのテスト（ＩＮＴＥＳＴ）に使用される。
長さ：不定
【００８４】
３．２．２．９ Ｓｃａｎ Ｃｈａｉｎ ４
目的：デバッグ
長さ：３３ビット
このスキャン・チェーンは、命令転送レジスタであり、かつフェッチ・ユニットを介してコアに命令を送出するために使用される。このチェーンは、３２ビットの情報＋付加的なビットからなり、コアに送出された命令の完了を示す。
順序：ＴＤＩ−［３２］［３１］［３０］．．．［１］［０］−ＴＤ０
【００８５】
３．２．２．１０ Ｓｃａｎ Ｃｈａｉｎ ５
目的：デバッグ
長さ：３３ビット
このスキャン・チェーンは、ＣＰ１４ Ｒｅｇｉｓｔｅｒ ５、データ転送レジスタである。このレジスタは、物理的に２つの個別的なレジスタ、即ち読み出し専用レジスタＤＴＲ（ｒＤＴＲ）及び書き込み専用レジスタＤＴＲ（ｗＤＴＲ）からなる。このレジスタは、ソフトウェアによる双方向通信チャネルの作成を容易にするように分離されている。ｒＤＴＲは、ＪＴＡＧポートを介してのみロード可能とされ、かつＭＲＣ命令を介してコアによってのみ読み出し可能とされる。ｗＤＴＲは、ＭＲＣ命令を介してコアによってのみロード可能とされ、まだＪＴＡＧポートを介してのみ読み出し可能とされる。ＴＡＰコントローラの能力から、１レジスタ（Ｃｈａｉｎ ５）のみを認識するが、しかしどの命令を使用するのか（ＩＮＴＥＳＴ又はＥＸＴＥＳＴ）に従って適当なレジスタが選択される。
【００８６】
ｗＤＴＲチェーンそれ自体は、３２ビットの情報＋通信チャネルに関する１付加ビットからなる。ビット０の定義は、現在のＪＴＡＧ命令がＩＮＴＥＳＴであるか、又はＥＸＴＥＳＴであるかに従う。現在の命令がＥＸＴＥＳＴであれば、デバッガはｒＤＴＲに書き込むことができ、またビット０は、キューにまだ有効なデータがあるか否かを表示している。このビットがクリアされていれば、デバッガは新しいデータを書き込むことができる。コアがＤＴＲの読み出しを実行するときは、ビット０が自動的にクリアされる。逆に、ＪＴＡＧ命令がＩＮＴＥＳＴであれば、ビット０は、ｗＤＴＲに読み出す現在有効なデータが存在するか否かを表示している。ビットがセットされていれば、ＪＴＡＧは、ｗＤＴＲの内容を読み出す必要があり、続いてこのビットをクリアする。次いで、このコアは、ビット０をサンプリングすることができ、このビットが再びクリアされると新しいデータを書き込むことができる。ｒＤＴＲチェーンは、３２ビットの情報＋通信チャネルに関する１付加ビットを含む。
順序：ＴＤＩ−ｒＤＴＲ［３２］ｒＤＴＲ［３１］．．．ｒＤＴＲ［１］ｒＤＴＲ［０］
ｗＤＴＲ［３２］ｗＤＴＲ［３１］．．．ｗＤＴＲ［１］ｗＤＴＲ［０］−ＴＤＯ
【００８７】
３．２．２．１１スキャン・チェーン６−１５
予備
【００８８】
３．２．２．１２スキャン・チェーン１６−３１
割り付けなし
【００８９】
３．２．３ コアに対する命令の送出
ＣＰ１４内の２レジスタは、ＡＲＭ１０プロセッサ、命令転送レジスタ（ＩＴＲ）及びデータ転送レジスタ（ＤＴＲ）と通信するために使用される。ＩＴＲは、命令をプロセッサ・パイプラインに詰め込むために使用される。デバッグ状態では、プロセッサの殆どの時間は、ＩＴＲがレディーになるまで、無効命令を効果的に実行することに費やされる。ハードウェア・デバッグ状態では、ＰＣは命令を実行するに従って増加しないが、それでも分岐はＰＣを変化させることになる。
【００９０】
ＤＳＣＲ［２９］は自動実行機能（ａｕｔｏｅｘｃｕｔｅ ｆｕｎｃｔｉｏｎ）を制御する。このビットがセットされると、各ＪＴＡＧ ＴＡＰコントローラは、Ｒｕｎ／Ｉｄｌｅステートに入り、ＩＴＲに現在存在する命令は、コアによる実行のためにプリフェッチ・ユニットに送出される。このビットがクリアされているときは、命令はプリフェッチ・ユニットに送出されない。ＪＴＡＧ ＩＲレジスタ内の命令は、ＩＮＴＥＳＴ又はＥＸＴＥＳＴでなければならない。
【００９１】
自動実行機能は、データの速いアップロード及びダウンロードを可能にさせる。例えば、ダウンロードシーケンスは、下記のいかなるものでもよい。まず、ＳｃａｎＮＲｅｇにスキャン・チェーン２、スキャン・チェーン４及び５の組み合わせを選択し、次いで、書き込みのためにＪＴＡＧ命令をＥＸＴＥＳＴにセットする。コア書き込み命令（ＳＴＣ）及び関連するデータをＩＴＲ及びＤＴＲにそれぞれ直列にスキャン入力する。ＴＡＰコントローラがＲｕｎ−Ｔｅｓｔ／Ｉｄｌｅステートを通過すると、ＩＴＲ内の命令をコアに発行する。次に、スキャン・チェーンをＤＴＲのみ（チェーン５）に切り換え、Ｃａｐｔｕｒｅ−ＤＲステート、次いでＳｈｉｆｔ−ＤＲステートとなることにより、ポーリングする。このステータス・ビットが命令の完了を示すまで、このチェーンにおける最下位ビット、即ちビットｗＤＴＲ［０］を調べる。更に多くのデータをＤＴＲにロードして、命令をＲｕｎ−Ｔｅｓｔ／Ｉｄｌｅを通過することにより再実行することができる。ここで、更に、我々は、アドレスが自動的に更新されるように、ＳＴＣ命令が基本アドレス書き戻しを指定するものと仮定する。
【００９２】
アップロードのパフォーマンスを増加させるためには、同じような機構を使用することができる。第１に、ＪＴＡＧ命令をＥＸＴＥＳＴに変更する。チェーン２を使用して、ＬＤＣのような読み出す命令をＩＴＲにスキャン入力することができる。次に、読み込みのためにＪＴＡＧ命令をＩＮＴＥＳＴに切り換える。そこで、スキャン・チェーンをＤＴＲに切り換えて命令が完了するまでポーリングすることができる。Ｒｕｎ−Ｔｅｓｔ／Ｉｄｌｅステートを通ってＳｈｉｆｔ−ＤＲ（ポーリングのため）となる過程で、コアに対してＩＴＲを発行する。以下、最後のワードを読み出すまで、この処理を繰り返す。
【００９３】
Ｒｕｎ−Ｔｅｓｔ／Ｉｄｌｅを通って命令を実行したことにより、ＪＴＡＧクロックの周波数に接近した周波数にあるコア・クロックを動作させる問題に取り組む。コアに命令を発行し、かつデータが捕捉できないときは、エミュレータは、データが得られるまで、ステート・マシン・ループを単に周りポーリングをする。そのようになると、ステート・マシン・ループをもう一回巡回し、データを捕捉し、次いでこれをスキャン出力させることができる。内側ループにおいて自動実行機構を他のステートに設定すると、他の命令を発送するのを早過ぎるものにし、多分、他のデータを重ね書きするのを強いる。Ｒｕｎ−Ｔｅｓｔ／Ｉｄｌｅは内側ループ外に留まり、１ステート遷移のみとなり、通過することに殆ど不都合はない。プロセッサ・クロックがＪＴＡＧクロックよりもかなり速いシステムでは、通常、ＴＡＰコントローラがＲｕｎ−Ｔｅｓｔ／ＩｄｌｅからＣａｐｔｕｒｅ−ＤＲとなる十分前に、データを得られるので、内側ループを１回通ってデータを捕捉し、次いでスキャン出力する。
【００９４】
ＣＰ１４は、ＡＲＭ９が行うと同様にバスを監視しないので、コアのレジスタ・ファイルの内容を読み出すには、ＬＤＭ／ＳＴＭ命令を使用する代わりに、ＡＲＭレジスタからＣＰ１４レジスタ５に個別的な移動を必要とすることに注意すべきである。そこで、情報をＤＴＲからスキャン出力することができる。
【００９５】
バイト及びハーフワードの転送は、プロセッサにアドレス及びデータの両方を転送し、次に適当なＡＲＭ命令を実行することにより、実行される。
【００９６】
コプロセッサへ及びからの転送は、ＡＲＭレジスタを介してデータを移動することにより実行可能とされる。これは、全てのＡＲＭ１０コプロセッサがＭＲＣ及びＭＣＲを介してアクセス可能な全てのデータを有する必要があるということを意味する（そうでないときは、書き込み可能なメモリにおけるデータ・バッファを使用する必要がある）。
【００９７】
３．２．４ ブレークポイント・レジスタ及びウォッチポイント・レジスタの読み出し及び書き込み
ハードウェア・ブレークポイント及びウォッチポイントは、データをＡＲＭレジスタに転送し、次いでデータを適当なブレークポイント・レジスタ又はウォッチポイント・レジスタに移動させることにより、書き込まれる。たとえばブレークポイントレジスタＲ６４へのロードを考える。
ＩＴＲにスキャン入力：ＭＲＣ ｐ１４，０，Ｒｄ，ｃ０，ｃ３，０
ＤＴＲにスキャン入力：ブレークポイント／レジスタＲ６４にデータをロード
データコマンドを実行
ＩＴＲにスキャン入力：ＭＲＣ ｐ１４，０，Ｒｄ，ｃ０，ｃ０，４
【００９８】
以上の例では、最初のＭＲＣ命令はデータをＤＴＲレジスタ（ＣＰ１４内のＲ５）からＡＲＭ内の他のレジスタに移動する。このデータが移動されると、ＭＣＲ命令はデータをＡＲＭレジスタからブレークポイント・レジスタ（ＣＰ１４内のＲ６４）に転送する。
【００９９】
ブレークポイント・レジスタを読み出すために逆の処理を使用することができる。ブレークポイント・レジスタ及びウォッチポイント・レジスタは、実施コストを最小化するためにスキャン・チェーンから直接アクセス不可能である。
【０１００】
プリフェッチ・ユニットことにより発行された命令アドレスは、常時、ビット０が０にセットされている。サム・モードにおいて、ビット１はアドレスの奇数ワードのアドレスを表している。一方、ＡＲＭモードにおいて、ビット１は常時、０にセットされている。ブレークポイント・レジスタは、サム・モードにおいてブレークポイント及びウォッチポイントに対する比較のために、全３２ビット・フィールドを有するが、ユーザは、このレジスタに絶対に一致しない値、例えばビット０を１とした値にセットしないように注意すべきである。
【０１０１】
ブレークポイント及びウォッチポイント制御レジスタ内のビットは、自明である必要がある。
【０１０２】
３．２．５ ソフトウェア・ロックアウト機能
ＪＴＡＧデバッガが評価ボード又はテスト・システムに取り付けられているときは、その存在は、ＤＳＣＲ内のホールト／モニタ・モード（Ｈａｌｔ／Ｍｏｎｉｔｏｒ Ｍｏｄｅ）をセットすることにより表示される。この場合に、ホールト・モードである間は、デバッガによりブレークポイント・レジスタ及びウォッチポイント・レジスタを書き込み及び読み出すことができる。ブレークポイント・レジスタ及びウォッチポイント・レジスタが構築されてしまうと、デバッガが制御権を保持しているので、ホールト／モニタ・モードのビットがハイのままであれば、ソフトウェアによりプロセッサ側からこれらレジスタを変更することはできない。しかしながら、コアは、依然として通信チャネル・レジスタに書き込み可能である。
【０１０３】
３．２．６ 外部信号
デバッグに関連した１外部信号ＥＤＢＧＲＱが存在し、これによって、システムはＡＲＭ１０２０にデバッグ・ステートに入るように要求する。外部ロジックは、このラインを使用してマルチプロセッサ・システムにおけるＡＲＭ１０２０をホールトするように、又は起動時に直接、プロセッサをデバッグ・ステートに強制設定するように要求してもよい。
【０１０４】
３．２．７ ステートのセーブ及びリストア
デバッグ処理の前に、エミュレータは、制御のセッティング、レジスタ値、又はエミュレーションの過程で変更される恐れのある他のステートをセーブする必要がある。このため、デバッグを抜け出す前に、これらの元のステートに全ての条件をリストアするように考慮する必要がある。デバッグ・エントリ後に読み出されるＰＣ値は、全ての場合でＰＣ＋０Ｘ８となる。即ち、ベクトルは、ＢＫＰＴ命令、レジスタ・ブレークポイント、ＪＴＡＧからのＨＡＬＴ命令等を捕捉する。
【０１０５】
ＤＴＲは２レジスタに分割されたので、ｒＤＴＲ及びｗＤＴＲステート情報をセーブすることが必要がある。セーブ及びリストア・シーケンスは下記のように見える。
（ハードウェアはＪＴＡＧを通ってＨＡＬＴ命令を実行する。）
コアをホールトした（Ｃｏｒｅ Ｈａｌｔｅｄ）が主張されるまで、ポーリングする
主張されれば、ｗＤＴＲを捕捉してスキャン出力する
ＪＴＡＧ ＩＲをＥＸＴＥＳＴへ変更及びジャンク（ｊｕｎｋ）をｗｐｒＤＴＲへスキャン入力−これはｒＤＴＲステータス・ビットを強制的に出力させる。
（他のレジスタをセーブする）
．
．
．
（デバッグ処理を終了）
古いＣＰＳＲをｒＤＴＲにスキャン入力
ＭＲＣによりＩＴＲをロードし、ＭＲＣはｒＤＴＲをＲ０に転送して実行
ＭＳＲによりＩＴＲをロードし、ＭＲＣはＲ０をＣＰＳＲに転送
古いＰＣをｒＤＴＲにスキャン入力
ＭＲＣによりＩＴＲをロードし、ＭＲＣはｒＤＴＲをＲ０に転送して実行
ＭＯＶによりＩＴＲをロードし、ＭＯＶはＲ０をＰＣに転送
古いＲ０をｒＤＴＲにスキャン入力
ＭＲＣによりＩＴＲをロードし、ＭＲＣはｒＤＴＲをＲ０に転送
（レジスタをリストア）
セーブしたｒＤＴＲステータス・ビットがレジスタがフルであったことを示しているときは、古いｒＤＴＲ情報をｒＤＴＲにスキャン入力
ＲＥＳＴＡＲＴコマンドを発行
Ｃｏｒｅ Ｒｅｓｔａｒｔｅｄが主張されるまでポーリング
【０１０６】
３．３ デバッグに対するソフトウェアインタフェース
モニタ・モードは、レジスタのブレークポイント、これらのブレークポイントに対する応答、及び更にコアをホールトを構築するように使用されるこれらのＡＲＭオペレーションを説明する。モニタ・モードは、情報を収集するためにコアをホールトできないときにリアル・タイム・システムにおいても有用である。例には、エンジン制御、及び部品を物理的に損傷することなくコードを停止できないハード・ドライブ・コントローラにおけるサーボ機構がある。命令ストリームに小さな挿入を許容する状況では、モニタ・モードは理想的である。この技術を使用して、ステート情報及び重要な変数をセーブするのに十分な時間割り込みによりコードを一時停止させる事ができる。コードは例外ハンドラーが終了すれば再度続行する。
【０１０７】
３．３．１ モニタ・モードへの進行及び抜け出し
モニタ・モードは、ＤＳＣＲのビット３０に０を書き込むことにより、エネーブルされる。モニタ・モードがエネーブルされたときに、下記の事象のうちの１つが発生すると、プロセッサは（ホールトすることよりも）例外となる。
１）レジスタのブレークポイントをヒット
２）ウォッチポイントをヒット
３）ブレークポイント命令がＡＲＭパイプラインの実行段階に到達
４）例外に行き、対応するベクトル・トラップ・ビットをセット
【０１０８】
ＤＳＣＲ内のグローバル・デバッグ・エネーブル（Ｇｌｏｂａｌ ＤｅｂｕｇＥｎａｂｌｅ）ビットをセットしなければ、無操作となることに注意すべきである。例外ハンドラーからの抜け出しは、通常の形式、例えばプリフェッチ例外のためにＰＣを（Ｒ１４−０Ｘ４）にリストアし、ＢＲＰＴ命令に対してＲ１４をＰＣに移動させることにより、実行する必要がある。なぜならば、これらはスキップ等が実行されるためである。以下の表は、コアが例外となるときのＰＣの値を表示する。
【０１０９】
【表４】
３．３．２ ブレークポイント・レジスタ及びウォッチポイント・レジスタの読み出し及び書き込み
モニタ・モードのときは、全てのブレークポイント・レジスタ及びウォッチポイント・レジスタを特権処理モードからのＭＣＲ及びＭＣＲ命令により読み出し及び書き込みが可能である。
【０１１１】
レジスタ・フィールドの符号化の説明については、３．１．２項及び３．２．４項を参照されたい。
【０１１２】
３．３．３ ＢＫＰＴ命令
ＡＲＭデバッグ・アーキテクチャーは、ＡＲＭ及びサムの両者に対するブレークポイント命令を定義する。これらの命令のうちの一つの実行は、レジスタ・ブレークポイントをヒットすることと同一の効果を有する。モニタ・モードでは、プリフェッチ中断が実行され、ホールト・モードでは、コアがホールトする。各デバッグ命令は、個々のブレークポイントを識別するためにデバッガことにより使用可能にされた１未使用フィールド、サムに対して８ビット、及びＡＲＭに対して１２ビットを有する。
ＡＲＭのオプコードは３２′ｈＥ１２ｘｘｘ７ｘ、サムのオプコードは１６′ｈｂｅｘｘであり、ｘは未使用フィールドである。
【０１１３】
３．３．４ Ｃｏｍｍｓチャネル
ＡＲＭ１０におけるｃｏｍｍｓ（通信）チャネルは、物理的に独立した２つのデータ転送レジスタ（ＤＴＲ）及び各レジスタを増加するために１ビットを使用し、双方向直列ポートを形成することにより実施された。この付加ビットは、有効データがデータ・レジスタに存在することを表示する。協定により、対象ソフトウェアは、書き込みＤＴＲ（ｗＤＴＲ）を保有し、またホスト・ソフトウェアは、読み出しＤＴＲ（ｒＤＴＲ）を保有する。換言すれば、ｗＤＴＲはコアにより書き込まれ、次いで情報はホストによりＪＴＡＧポートを通ってスキャン出力される。ｗＤＴＲはＴＤＯ接続を有する唯一のレジスタであり、スキャン・チェーン５のビット０は、ＪＴＡＧ命令レジスタにおける現在命令（ＩＮＴＥＳＴ又はＥＸＴＥＳＴ）により選択される。ｃｏｍｍｓチャネルの活動のデバッグをしているときに、ＤＳＣＲのビット２７は、セットされて、ここで、ｗＤＴＲの最下位ビットが命令の完了よりもｃｏｍｍｓチャネル・レジスタのステートを表示していることをデバッグ・ロジックに表示する。
【０１１４】
デバッガがそれを意図するデータを読み出しているときに、ＩＮＴＥＳＴをＩＲにロードしｗＤＴＲの内容をスキャン出力する。３３ビットのデータ・パケットの最下位ビットがセットされていれば、このデータは有効である。次いで、この読み出しによりｗＤＴＲ内のビット０をクリアする。このビットがクリアされており、コアに新しいデータが書き込まれていないことを意味しているときは、デバッガは、コアがホールトしたか否かを調べるためにＤＳＣＲのポーリングを希望することもできる。
【０１１５】
同様に、ＥＸＴＥＳＴは、デバッガによりｒＤＴＲにデータを書き込むために使用され、またこの動作は有効データを示すビット０をこのレジスタ用にセットする。デバッガが見るものは、実際には、このビットの反転であるので、デバッガは更にデータを書き込みをするときに、ビット０は、セットされて、コアがｒＤＴＲを読み出したことを意味しているか否かを見るために、チェックされる必要がある。このビットがゼロであり、ｒＤＴＲが依然としてフルであり、かつコアが古いデータを読み出していなかったときは、シフト入力された新しいデータは、ｒＤＴＲにロードされない。これを多数回行った後に、コアがホールトしたか否かをデバッガがチェックしたいときは、ステータス・ビットは、ｒＤＴＲ内のデータと共に有効に存続する。これは、スキャン出力されて、デバッガが後で単にスキャン入力により戻せるようにセーブしたステート情報と置換される必要がある。データをｒＤＴＲからコア・レジスタに、次いでｗＤＴＲに移動してスキャン出力するこのような操作は、ｒＤＴＲの全ビットを制御しているステート・マシンをクリアすることになる。
【０１１６】
これらの付加ビットは実際にＤＳＣＲに反映されるので、コアはこれらビットを読み出すためにＭＲＣを使用することができる。しかしながら、これらのビットは、コア用なので、デバッガから見えるビットの論理反転である。
【０１１７】
ホールト・モード及びモニタ・モードは、互いに排他的であるので、転送レジスタは、モニタ・モードにおいて他の目的用に使用されていない。
【０１１８】
４．０ デバッグ及び例外、ベクトル捕捉
４．１ 命令ブレークポイント
命令ブレークポイントは、命令データと同時にコアにクロッキングされる。ブレークポイントは、中断がペンディングでないと仮定して、命令がパイプラインの実行段に入ると直ちに処理される。このブレークポイントは、命令がその条件コードに失敗したか否かについて処理される。
【０１１９】
ブレークポイント命令は、これに関連したプリフェッチ中断を有してもよい。その通りであれば、プリフェッチ中断が優先し、ブレークポイントは無視される。ＳＷＩ及び未定義命令は、これにセットされたブレークポイントを有し得る他の命令と同様に処理される。従って、ブレークポイントはＳＷＩ又は未定義命令に対して優先する。
【０１２０】
命令の境界にブレークポイントの命令及び割り込み（ＦＩＱ又はＩＲＱ）が存在するときは、割り込みが実行され、ブレークポイントの命令はすてられる。割り込みがサービスされると、実行フローは元のプログラムに戻される。これは、前にブレークポイントした命令が再びフェッチされたことを意味し、このブレークポイントが依然としてセットされているときに、プロセッサがパイプラインの実行段に到達すれば、プロセッサはデバッグ・ステートに入る。
【０１２１】
４．２ ウォッチポイント
ウォッチポイントのメモリアクセスに続くデバッグ・ステートへのエントリは、命令ストリーム・アクセスと比較して不正確である。これは、パイプラインの性質及びコアに行くウォッチポイント信号のタイミングのためである。プロセッサは、ウォッチポイント・トリガ後に実行される、ウォッチポイントの命令が実行を開始した後の数命令となり得る次の命令で停止することになる。
【０１２２】
ウォッチポイントと共にデータ・アクセスによる中断があると、中断例外エントリ・シーケンスを実行し、次いでプロセッサはデバッグ・ステートに入る。割り込みの待機があると、再び、プロセッサは、例外エントリ・シーケンスが発生できるようにし、デバッグ・ステートに入る。次の命令を中断したときは、中断は実行されない。
【０１２３】
ＣＰ１５内のフォールト・ステータス・レジスタ（Ｆａｕｌｔ ＳｔａｔｕｓＲｅｇｉｓｔｅｒ：ＦＳＲ）は、ＭＭＵとアクセスを中断するデバッグ・システムとの間を区別する。データ中断が発生すると、ＦＳＲ［３：０］フィールドのビット９がゼロに強制設定される。データ中断がなく、ウォッチポイントが発生すると、ＤＦＳＲ［９］を１に強制設定する。
ソフトウェアがこのレジスタを読み出し、かつＤＦＳＲ［９］が１にセットされているのを認識したときは、残りのビットを無視する必要がある。
【０１２４】
４．３ 割り込み
プロセッサがデバッグ・ステートに入れば、更なる割り込みが実行された命令に影響しないことが重要である。このために、プロセッサがデバッグ・ステートに入れば、割り込みがディセーブルされるが、ＰＳＲにおけるＩ及びＦビットのステートは、影響されない。
【０１２５】
４．４ 例外
ＡＲＭ１０コアにおける例外の優先順位は、以下のようである。
【０１２６】
【表５】
下記の表６は、ホールト及びモニタ・モードの両者におけるデバッグ・ロジックの動きの要約である。
【０１２８】
【表６】
モニタ・モードにおいて、ブレークポイントをヒットした、又はＢＫＲＰ命令を実行したときは、プリフェッチ中断の例外となる。ウォッチポイントをヒットしたときは、データ中断の例外となる。ＣＰ１５内のフォールト・ステータス・レジスタ（ＦＳＲ）は、ＭＭＵとデバッグ・システムとの間を区別してアクセスを中断するために使用される。ＦＳＲにウォッチポイントヒットを示す符号が加えられる。Ｒ１４ ａｂｏｒｔは実行されなかった命令後の第１の命令をポイントする。２つの異常例、即ち「フェッチ中断上にベクトル・トラップのセット」、又は「データの中断が許可されない」がディセーブルされた。如何なる状況であっても、ＪＴＡＧ ＨＡＬＴ命令を、ソフトウェア・モードにある間に、デバッグ・ロジックがＤｂＨａｌｔライン〜ＤｂｇＩｎＤｅｂｕｇラインをクリアするために使用するハンドシェーク・ラインとして、決して現れない部分にスキャン入力されるようなことがあれば、プロセッサを（現在Ｒｅｖ０ハードウェア実施により）連続的にプリフェッチ中断させることになる。
【０１３０】
ウォッチポイントをセットしたロード／ストア多重命令の場合に、他の命令は、多分（かつ大抵は）その下で動作することができる。デバッガはロード／ストア多重命令のＰＣ値と共に復帰ＰＣ値（ｒｅｔｕｒｎ ＰＣ）を知る必要があるので、ウォッチポイントのデータ・アドレスは、Ｄ側のフォールト・アドレス・レジスタ（ＦＡＲ）に記憶され、ウォッチポイント命令それ自身のＰＣ（＋０Ｘ８）は、Ｉ側ＦＡＲに記憶される。再起動ＰＣは、通常のようにＲ１４に保持される。
【０１３１】
コアがデバッグ・ステートにある間に未定義の命令例外となるときは、即ちデバッグ・ステートにある間に、デバッガが、未定義命令をコアにスキャン入力するときは、コアはモードを変更し、かつＰＣを未定義命令トラップ・ベクトルに変更する。デバッガはこの情報を使用して未定義命令を何時コアが見たかを判断することができる。１例は、与えられた実施に対してサポートされていないために、拒絶するコプロセッサ命令が考えられる。
【０１３２】
４．５ ベクトル捕捉
ＡＲＭ１０デバッグ・ユニットは、例外中にベクトルからフェッチの効率的なトラッピングを可能にするロジックを含む。これは、ＤＳＣＲに位置するベクトル捕捉エネーブル（Ｖｅｃｔｏｒ Ｃａｔｃｈ Ｅｎａｂｌｅ）により制御される。このレジスタ・フィールドにおける複数ビットのうちの１ビットがハイにセットされ、かつ対応する例外が発生すると、プロセッサは、レジスタ・ブレークポイントが関係する例外ベクトルからの命令フェッチにセットされたかのように作動し、次いでホールトする。ベクトル捕捉エネーブルは、ＪＴＡＧ命令からのみ書き込み可能である。
【０１３３】
例えば、プロセッサがホールト・モードにあり、かつＤＳＣＲ［１８］がセットされている間にＳＷＩ命令を実行するときは、ＡＲＭ１０が０Ｘ８から命令をフェッチする。ベクトル捕捉ハードウェアは、このアクセスを検出し、かつ内部ブレークポイント信号をセットしてコアを強制的に停止させる。
【０１３４】
ベクトル捕捉ロジックは例外エントリ中にベクトルからのフェッチに対してのみ感応する。従って、通常のオペレーション中に、コードがベクトル内のアドレスに分岐し、かつ対応するベクトル捕捉エネーブル・ビットがセットされると、プロセッサはデバッグ・ステートに強制されない。レジスタ・ブレークポイントは、ベクトルからの命令フェッチを捕捉するために使用されてもよい。
【０１３５】
ブレークポイントを経由する割り込みのステート優先度は、ＡＲＭ９におけるベクトル捕捉バグの原因であった。ＡＲＭ１０の場合に、ベクトルが捕捉した例外ベクトルからフェッチされた命令の発行中に割り込み要求が発生するときは、コアはベクトル・トラップを最初に処理する。コアが再起動すると、プロセッサは割り込み要求を処理する。
【０１３６】
５．０ サム
デバッグ・ステートにおいて、ＣＰＳＲのＴビットは、デバッガにより読み出され／書き込まれ、かつデバッグ・ステートに入る又は出るときに変更されない。更に、これは、デバッグ・ステートにある間に実行される命令形式に影響されない。デバッグ・ステートを抜け出すときは、ＣＰＳＲ Ｔビットは、ＡＲＭ又はサム命令が実行されるのかを決定する。
【０１３７】
ＤＳＣＲにおけるＴビットは、プリフェッチ・ユニットに送出される各命令と共に送出されるので、コアをホールトすると、デバッガが実行しようとし、かつプロセッサをＡＲＭモード又はサム・モードに強制設定するために使用可能とされる命令形式（ＡＲＭ又はサム）を表示する。換言すれば、ＤＳＣＲにおけるＴビットは、ＩＴＲにおける命令のデコードを制御する。デバッグ・ステートのエントリ後に、デバッガは、ＤＳＣＲにおけるＴビットをクリアしてＡＲＭ１０にＡＲＭ１０命令を発行できることを確認する必要がある。デバッガに対するエントリ・シーケンスは、以下のように見ることになるであろう。
（ホールト・モードによりデバッグ・ステートに入る）
０をＣＰ１４のレジスタ１のＴビットにスキャン入力（ＤＳＣＲ）
ＡＲＭモードによりＣＰＳＲを読み出してＴビット情報を得る（オプション）
ＡＲＭモードによりＭＣＲを実行してＡＲＭステート情報を抽出
・
・
ＭＲＣを使用して全てのＡＲＭをリストア
再起動ＰＣ値をＲ０に移動
ＡＲＭ ＭＯＶ Ｒ０，ＰＣを実行
リストアＲ０
（命令が完了したことを確認するためにポーリング）
（ＪＴＡＧを通ってＲＥＳＴＲＴコマンドを発行することによりデバッグ・ステートを抜け出す）
Ｃｏｒｅ Ｒｅｓｔａｒｔビットをポーリング
【０１３８】
コアは、デバッグ・ステートを抜け出す際に現在モードとしてＣＰＳＲにおけるＴビットを使用する。
【０１３９】
６．０ 実施発行
デバッグ構造は、２クロック領域、即ち高速プロセッサ・クロック及び低速ＪＴＡＧクロックにより実施されることを意図している。大抵のデバッグ・ハードウェアは、高速クロック速度で動作し、両者間の同期は、命令として実行され、データ転送レジスタは、ＪＴＡＧスキャン・チェーンから読み出され、またＪＴＡＧスキャン・チェーンに書き込まれる。これは、コア・クロックより速くＪＴＡＧクロックを動作させることができる。
【０１４０】
データ転送用のソース及び宛先としてＣＰ１４を使用し、ＡＲＭ内の既存のパスを再使用して、データ・バスに付加付加的な入力を追加する必要性をなくしている。ＡＲＭ１０には、フェッチ・ユニットにおける初期命令入力として命令レジスタが設けられている。
【０１４１】
少数のマルチＩＣＥは、ＪＴＡＧハードウェア内の更新機構に付加されるわずかな調整を必要とする設計の過程で発生する。コアに命令を発行する間に、マルチＩＣＥソフトウェアは、前に発行した命令が完了したか否かを検定するためにＣａｐｔｕｒｅＤＲステートを通過後にビットをスキャン出力する。命令が完了していないときは、デバッグ・ロジックは、２つの事象が発生するのを防止する。第１に、ＴＡＰステート・マシンがＵｐｄａｔｅＤＲステートを通過するときに、スキャン・チェーン５にシフトされた値がｒＤＴＲにロードされない。第２に、ＴＡＰステート・マシンがＲｕｎ−Ｔｅｓｔ／Ｉｄｌｅステートを通過して現在ＩＴＲ内の命令を発行するので、この命令がコアに発行されない。ｒＤＴＲの３３番目のビットは、「更新する」（ｄｏ ｕｐｄａｔｅ）ビットを作成するために登録され、この「更新する」ビットは命令の発行及びｒＤＴＲの更新を阻止するために使用される。
【０１４２】
特に、このロジックは以下の場合に使用される。極端に速いダウンロードを試行するために、マルチＩＣＥは、データをｒＤＴＲにスキャン入力して、Ｒｕｎ−Ｔｅｓｔ／Ｉｄｌｅを通ることによりコアに対して書き込みを発行することにより、起動する。次の各書き込みオペレーションにおいて、ｒＤＴＲのビット０を調べて前の命令が完了したか否かを判断する。この命令が完了していないときは、デバッガは再び同一のデータを与える。所定数の試行後に、命令が未だ完了していないときは、デバッガはＤＳＣＲ内の中断発生（Ａｂｏｒｔ Ｏｃｃｕｒｒｅｄ）ビットを調べて中断がどこかの点に発生したのか否かを判断する。メモリ・アクセス中に中断が発生したときは、「更新する」ビットをクリアすることにより、次の命令が実行されてメモリをアクセスしようとする他の可能性を除去する。特に、これは、中断のためにモードが突然変化し、かつユーザ・モードではアクセスできないメモリが特権モードにおいてアクセス可能となるときに、重要となる。
【０１４３】
次に実行すべき命令の後の位置に配置されたＢＫＰＴ命令を使用して、ここで、コードによる単一ステップを実行することが必要となる。更に、レジスタ・ブレークポイントも使用することができる。
【０１４４】
ＬＤＣはワード長のみである。バイト／ハーフワード・アクセスのためにコアに読み出し／書き込みを強制させ、次いでスキャン出力又はその逆のためにデータをＲ５に移動させる。
【０１４５】
７．０ キャッシュ（ＣＰ１５）及びメモリ動作
デバッグ・ユニットは、ＣＰ１４及びＣＰ１５がいくつかの機能を共有しているので、ＴＬＢ情報と共にキャッシュ情報を読み出すことができる。パイプライン・フォロワ及びコプロセッサ・インターフェースは、全て同一ブロック内に存在する。これは、ＣＰ１４がＣＰ１５内のＦＳＲを非常に簡単に更新可能にする。ＣＰ１５は１６のレジスタを含み、その一つ（Ｒ１５）はデバッガ用のインターフェースとして使用される。ＭＲＣ命令及びＭＣＲ命令を使用してＲ１５の読み出し及び書き込みにより、デバッグ・ユニットは、キャッシュの完全な可視性を有する。キャッシュについての更なる情報は、ＡＲＭ１０２０μＡ仕様を参照されたい。
【０１４６】
マシンのステートをデバッグ・ステートに変更した後、メモリからのデータの読み出しにより、Ｉキャッシュ又はＤキャッシュがキャッシュに新しいエントリを挿入させることはない。換言すれば、キャッシュ可能として処理されるアクセスはない。これは、キャッシュをキャッシュ不能、バッファ不能に強制設定することにより達成される。キャッシュ・ミスは、デバッグ・ステートにある間に、ＨＵＭバッファにより無視されるので、ライン・フルは発生しない。
【０１４７】
命令データを変更するプログラム（例えば、自己変更コード）は、一貫性を保持するために、Ｄキャッシュによる書き込み後に、Ｉキャッシュをフラッシュする必要がある。
【０１４８】
デバッグ・モードでは、ユーザ・モードによるメモリ・アクセスがメモリ・システム及びＭＭＵに対するユーザ・モード・アクセスのように見える。特権モードにおけるメモリ・アクセスは、特権アクセスのように見える。
【０１４９】
【表７】
【表８】
【図面の簡単な説明】
【図１】デバッグ機構を含むデータ処理システムを概要的に示す図である。
【図２】図１のデータ処理システムのデバッグ機構の一部であるデバッグ・コプロセッサを概要的に示す図である。
【図３】図１のデータ処理システムのデバッグ機構の一部であるデータ転送レジスタを概要的に示す図である。
【図４】デバッグ命令の実行を示すフロー・チャートである。
【図５】デバッグ命令の繰り返し実行を示すフロー・チャートである。
【図６】図２のデバッグ・コプロセッサの他の概要ブロック図である。
【図７】図１のデータ処理システムのデバッグ機構の一部であるスキャン・チェーン・コントローラを示す概要ブロック図である。
【図８】図３に示すデータ転送レジスタのハンドシェーキング制御の一部を説明するタイミング図である。
【図９】ハードウェア・デバッグ・モードと通常モードとの間の切り換えを制御しているメイン・プロセッサとデバッグ・システムとの間のハンドシェーキング信号を説明するタイミング図である。
【符号の説明】
２ データ処理システム
４ メイン・プロセッサ（コア）
６ デバッグ・コプロセッサ（コプロセッサ）
１０ プリフェッチ・ユニット
１２ スキャン・チェーン・コントローラ
１４ 命令パイプライン
７８ デコーダ
２８ デバッグ・ステータス及び制御レジスタ（ＤＳＣＲ）
１６ ウォッチポイント・レジスタ
１８ ブレークポイント・レジスタ
Claims (17)
- データ処理装置において、
メイン・プロセッサであって、入力される命令ストリーム内のメイン・プロセッサ命令に応答してメイン・プロセッサ・オペレーションを実行する前記メイン・プロセッサと、
コプロセッサ・インターフェースを介して前記メイン・プロセッサに接続され、かつ前記命令ストリーム内のコプロセッサ命令に応答してコプロセッサ・オペレーションを実行するコプロセッサと
を備え、
前記コプロセッサは、前記コプロセッサの外部であり前記コプロセッサに接続する、前記データ処理装置の少なくとも１つの部分をデバッグするための診断データの発生を少なくとも部分的に制御可能なデバッグ・コプロセッサであり、かつ前記コプロセッサ命令は、前記デバッグ・コプロセッサのオペレーションを制御するデバッグ・コプロセッサ命令である
前記装置。 - 前記デバッグ・コプロセッサは、１以上のデバッグ・コプロセッサ・レジスタを備えている請求項１記載の装置。
- 前記メイン・プロセッサは、前記命令ストリーム内の命令に関連され命令アドレスを送信する命令アドレス・バスを備え、前記１以上のデバッグ・コプロセッサ・レジスタは、ブレークポイント値を格納するブレークポイント・レジスタを含み、前記デバッグ・コプロセッサは、前記ブレークポイント値を前記命令アドレス・バス上の前記命令アドレスと比較して前記ブレークポイント値が前記命令アドレス・バス上の前記命令アドレスと一致するときは、ブレークポイント表示信号を発生するブレークポイント比較器を含む
請求項２記載の装置。 - 前記１以上のデバッグ・コプロセッサ・レジスタは、前記ブレークポイント・レジスタに関連され、前記ブレークポイント比較器の動作を制御するパラメータを指定するためのブレークポイント値を格納するブレークポイント制御レジスタを含む請求項３記載の装置。
- 前記パラメータは、マスク値、ブレークポイント・エネーブル・フラグ、及び前記データ処理装置の複数の動作モードのうちのいずれで前記ブレークポイント比較器がアクティブとなるのかについて制御するモード選択値のうちの少なくとも１つを含む請求項４記載の装置。
- 前記メイン・プロセッサは、前記データ処理装置により処理されたデータ値と関連されたデータ・アドレスを送信するデータ・アドレス・バスを備え、前記１以上のデバッグ・コプロセッサ・レジスタはウォッチポイント値を格納するウォッチポイント・レジスタを含み、かつ前記デバッグ・コプロセッサは、前記ウォッチポイント値を前記データ・アドレス・バス上の前記データ・アドレスと比較して、前記ウォッチポイント値が前記データ・アドレス・バス上のデータ・アドレスと一致するときに、ウォッチポイント表示信号を発生するウォッチポイント比較器を含む請求項２から請求項５までのいずれかの項に記載の装置。
- 前記１以上のデバッグ・コプロセッサ・レジスタは、前記ウォッチポイント・レジスタに関連されて、前記ウォッチポイント比較器の動作を制御するパラメータを指定するためのウォッチポイント制御値を格納するウォッチポイント制御レジスタを含む請求項６記載の装置。
- 前記パラメータは、マスク値、ウォッチポイント・エネーブル・フラグ、及び前記データ処理装置の複数の動作モードのうちのいずれで前記ウォッチポイント比較器がアクティブとなるのかについて制御するモード選択値のうちの少なくとも１つを含む請求項７記載の装置。
- 前記１以上のデバッグ・コプロセッサ・レジスタのうちの少なくとも１つは、前記命令ストリーム内のデバッグ・コプロセッサ・レジスタ・アクセス命令に応答してアクセスされる請求項２から請求項８までのいずれかの項に記載の装置。
- 前記１以上のデバッグ・コプロセッサ・レジスタのうちの少なくとも１つは、直列スキャン・チェーン経由でアクセスされ、前記直列スキャン・チェーンは、スキャン・チェーン・コントローラの制御により動作する請求項２から請求項９までのいずれかの項に記載の装置。
- 前記１以上のデバッグ・コプロセッサ・レジスタのうちの少なくとも１つは、前記メイン・プロセッサによってアクセス可能なデータ値を格納するデバッグ・データ値レジスタを含み、前記データ値は、前記直列スキャン・チェーン経由でアクセスされる請求項１０記載の装置。
- 前記デバッグ・データ値レジスタは、前記直列スキャン・チェーンから書き込み可能、かつ前記メイン・プロセッサにより読み出し可能な第１のデバッグ・データ・レジスタと、前記直列スキャン・チェーンにより読み出し可能、かつ前記メイン・プロセッサから書き込み可能な第２のデバッグ・データ・レジスタとを備えた請求項１１記載の装置。
- 前記１以上のデバッグ・コプロセッサ・レジスタは、前記メイン・プロセッサにより実行されるデバッグ命令を格納するデバッグ命令レジスタを含み、前記デバッグ命令は、前記直列スキャン・チェーンにより前記にデバッグ命令レジスタに転送される請求項１０、１１及び１２のうちのいずれかの項記載の装置。
- 前記１以上のデバッグ・コプロセッサ・レジスタは、デバッグ・ステータス制御レジスタを含み、前記デバッグ・ステータス制御レジスタは、デバッグ・モードへのトリガ・エントリの条件、前記デバッグ・コプロセッサをエネーブルするフラグ、及びメイン・プロセッサ・ベクトル命令トラップを制御するフラグのうちの１以上を指定するデータを格納する請求項１０から請求項１３までのうちのいずれかの項記載の装置。
- 前記コプロセッサ・インターフェースは、デバッグ・オペレーション中に、前記メイン・プロセッサのメイン・プロセッサ・パイプライン内の命令処理を停止させる信号、前記コプロセッサ・バスに接続された別のコプロセッサのコプロセッサ・パイプライン内の命令処理を停止させる信号、及び前記別のコプロセッサ内のコプロセッサ動作を取り消させる信号のうちの１つ以上を含む前記デバッグ・コプロセッサにより発生される信号を転送する１本以上の信号ラインを含む前記請求項１から１４までのいずれかの項記載の装置。
- 前記メイン・プロセッサ及び前記デバッグ・コプロセッサは、共通クロック信号により駆動され、前記スキャン・チェーン・コントローラは、非同期スキャン・チェーン・クロック信号により駆動される請求項１０から請求項１５までのうちのいずれかの項記載の装置。
- データ処理方法において、
メイン・プロセッサに入力される命令ストリーム内のメイン・プロセッサ命令に応答して、メイン・プロセッサ・オペレーションを実行するステップと、
前記命令ストリーム内のコプロセッサ命令に応答し、コプロセッサ・インターフェースを介して前記メイン・プロセッサに接続されたコプロセッサを制御してコプロセッサ・オペレーションを実行するステップと
を備え、
前記コプロセッサは、前記コプロセッサの外部であり前記コプロセッサに接続する、前記データ処理装置の少なくとも１つの部分のデバッグのための診断データの発生を少なくとも部分的に制御するように動作可能なデバッグ・コプロセッサであり、前記コプロセッサ命令は、前記デバッグ・コプロセッサのオペレーションを制御するデバッグ・コプロセッサ命令であるデータ処理方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US314020 | 1999-05-19 | ||
| US09/314,020 US6446221B1 (en) | 1999-05-19 | 1999-05-19 | Debug mechanism for data processing systems |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000330825A JP2000330825A (ja) | 2000-11-30 |
| JP4475734B2 true JP4475734B2 (ja) | 2010-06-09 |
Family
ID=23218197
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000112811A Expired - Fee Related JP4475734B2 (ja) | 1999-05-19 | 2000-04-14 | データ処理装置及びデータ処理方法 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US6446221B1 (ja) |
| JP (1) | JP4475734B2 (ja) |
| GB (1) | GB2350216B (ja) |
Families Citing this family (39)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7571366B2 (en) * | 2004-12-02 | 2009-08-04 | Texas Instruments Incorporated | Sequential signals selecting mode and stopping transfers of interface adaptor |
| US6505290B1 (en) * | 1997-09-05 | 2003-01-07 | Motorola, Inc. | Method and apparatus for interfacing a processor to a coprocessor |
| US6820051B1 (en) * | 1999-02-19 | 2004-11-16 | Texas Instruments Incorporated | Software emulation monitor employed with hardware suspend mode |
| DE60028379T2 (de) * | 1999-03-30 | 2007-03-08 | Siemens Energy & Automation, Inc. | Speicherprogrammierbare steuerung |
| US7353368B2 (en) * | 2000-02-15 | 2008-04-01 | Intel Corporation | Method and apparatus for achieving architectural correctness in a multi-mode processor providing floating-point support |
| US6654878B1 (en) * | 2000-09-07 | 2003-11-25 | International Business Machines Corporation | Register bit scanning |
| US6691270B2 (en) * | 2000-12-22 | 2004-02-10 | Arm Limited | Integrated circuit and method of operation of such a circuit employing serial test scan chains |
| DE10139660B4 (de) * | 2001-08-11 | 2007-07-05 | Infineon Technologies Ag | Programmgesteuerte Einheit mit Debug-Ressourcen |
| GB0215033D0 (en) * | 2002-06-28 | 2002-08-07 | Critical Blue Ltd | Instruction set translation method |
| US6895530B2 (en) * | 2003-01-24 | 2005-05-17 | Freescale Semiconductor, Inc. | Method and apparatus for controlling a data processing system during debug |
| US6963963B2 (en) * | 2003-03-25 | 2005-11-08 | Freescale Semiconductor, Inc. | Multiprocessor system having a shared main memory accessible by all processor units |
| US7065691B2 (en) * | 2003-05-19 | 2006-06-20 | Hewlett-Packard Development Company, L.P. | Apparatus and method for saving precise system state following exceptions |
| JP2007500401A (ja) * | 2003-07-25 | 2007-01-11 | ジンガー，アーサー，アール． | ソフトウェアデバッギング用装置とその方法 |
| JP2007535067A (ja) * | 2004-04-29 | 2007-11-29 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | コンピュータにおけるプログラム実行中の侵入検出 |
| US7552360B2 (en) | 2005-03-21 | 2009-06-23 | Texas Instruments Incorporated | Debug and test system with format select register circuitry |
| US20070006042A1 (en) * | 2005-06-30 | 2007-01-04 | International Business Machines Corporation | Software debug support for cache flush with access to external data location(s) through debug port |
| US7665002B1 (en) * | 2005-12-14 | 2010-02-16 | Advanced Micro Devices, Inc. | Multi-core integrated circuit with shared debug port |
| KR101242602B1 (ko) * | 2006-02-08 | 2013-03-19 | 삼성전자주식회사 | 테스트 회로를 내장한 시스템 온 칩 |
| US20070214389A1 (en) * | 2006-03-08 | 2007-09-13 | Severson Matthew L | JTAG power collapse debug |
| US8010774B2 (en) * | 2006-03-13 | 2011-08-30 | Arm Limited | Breakpointing on register access events or I/O port access events |
| US7925862B2 (en) * | 2006-06-27 | 2011-04-12 | Freescale Semiconductor, Inc. | Coprocessor forwarding load and store instructions with displacement to main processor for cache coherent execution when program counter value falls within predetermined ranges |
| US7805590B2 (en) * | 2006-06-27 | 2010-09-28 | Freescale Semiconductor, Inc. | Coprocessor receiving target address to process a function and to send data transfer instructions to main processor for execution to preserve cache coherence |
| US20070300042A1 (en) * | 2006-06-27 | 2007-12-27 | Moyer William C | Method and apparatus for interfacing a processor and coprocessor |
| TWI331278B (en) * | 2007-03-14 | 2010-10-01 | Ind Tech Res Inst | Debug method |
| US8130526B2 (en) * | 2007-08-10 | 2012-03-06 | International Business Machines Corporation | Programming a microchip ID register |
| US7730248B2 (en) * | 2007-12-13 | 2010-06-01 | Texas Instruments Incorporated | Interrupt morphing and configuration, circuits, systems and processes |
| US20090222797A1 (en) * | 2008-02-29 | 2009-09-03 | Infineon Technologies Ag | Apparatus and method for providing a trigger |
| US20100042975A1 (en) | 2008-08-13 | 2010-02-18 | Honeywell International Inc. | Message logging for software applications |
| US8161328B1 (en) * | 2010-05-27 | 2012-04-17 | Western Digital Technologies, Inc. | Debugger interface |
| TW201235833A (en) * | 2011-02-16 | 2012-09-01 | Ind Tech Res Inst | System and method for multi-core synchronous debugging of a multi-core platform |
| US8799713B2 (en) * | 2011-03-01 | 2014-08-05 | Texas Instruments Incorporated | Interruptible non-destructive run-time built-in self-test for field testing |
| US8640007B1 (en) | 2011-09-29 | 2014-01-28 | Western Digital Technologies, Inc. | Method and apparatus for transmitting diagnostic data for a storage device |
| GB2504772A (en) | 2012-08-10 | 2014-02-12 | Ibm | Coprocessor providing service address space for diagnostics collection |
| US9270553B1 (en) | 2014-03-26 | 2016-02-23 | Amazon Technologies, Inc. | Dynamic service debugging in a virtual environment |
| US9626267B2 (en) * | 2015-01-30 | 2017-04-18 | International Business Machines Corporation | Test generation using expected mode of the target hardware device |
| WO2017072664A1 (en) * | 2015-10-27 | 2017-05-04 | Marvell World Trade Ltd. | System and method for establishing a trusted diagnosis/debugging agent over a closed commodity device |
| US10067814B2 (en) | 2016-04-28 | 2018-09-04 | International Business Machines Corporation | Method and system to decrease measured usage license charges for diagnostic data collection |
| US10769051B2 (en) * | 2016-04-28 | 2020-09-08 | International Business Machines Corporation | Method and system to decrease measured usage license charges for diagnostic data collection |
| US11914500B2 (en) | 2022-02-03 | 2024-02-27 | Apple Inc. | Debugging of accelerator circuit for mathematical operations using packet limit breakpoint |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH01297764A (ja) * | 1988-05-25 | 1989-11-30 | Nec Corp | プロセッサ |
| CN1316368C (zh) * | 1994-12-28 | 2007-05-16 | 株式会社东芝 | 微处理器 |
| EP0762280B1 (en) | 1995-08-30 | 2001-11-14 | Motorola, Inc. | Data processor with built-in emulation circuit |
| GB9626401D0 (en) * | 1996-12-19 | 1997-02-05 | Sgs Thomson Microelectronics | Diagnostic procedures in an integrated circuit device |
| GB2326253A (en) * | 1997-06-10 | 1998-12-16 | Advanced Risc Mach Ltd | Coprocessor data access control |
| US5983338A (en) * | 1997-09-05 | 1999-11-09 | Motorola, Inc. | Method and apparatus for interfacing a processor to a coprocessor for communicating register write information |
| US6173386B1 (en) * | 1998-12-14 | 2001-01-09 | Cisco Technology, Inc. | Parallel processor with debug capability |
| US6282592B1 (en) * | 1998-12-14 | 2001-08-28 | Nortel Networks Limited | Method and apparatus for high-speed data transmission bus entrainment |
| US6311302B1 (en) * | 1999-04-01 | 2001-10-30 | Philips Semiconductor, Inc. | Method and arrangement for hierarchical control of multiple test access port control modules |
| WO2001063434A1 (en) * | 2000-02-24 | 2001-08-30 | Bops, Incorporated | Methods and apparatus for dual-use coprocessing/debug interface |
-
1999
- 1999-05-19 US US09/314,020 patent/US6446221B1/en not_active Expired - Lifetime
- 1999-12-10 GB GB9929365A patent/GB2350216B/en not_active Expired - Lifetime
-
2000
- 2000-04-14 JP JP2000112811A patent/JP4475734B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| GB9929365D0 (en) | 2000-02-02 |
| GB2350216A (en) | 2000-11-22 |
| US6446221B1 (en) | 2002-09-03 |
| GB2350216B (en) | 2003-07-16 |
| JP2000330825A (ja) | 2000-11-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4475734B2 (ja) | データ処理装置及びデータ処理方法 | |
| US6343358B1 (en) | Executing multiple debug instructions | |
| US6321329B1 (en) | Executing debug instructions | |
| US6094729A (en) | Debug interface including a compact trace record storage | |
| US5978902A (en) | Debug interface including operating system access of a serial/parallel debug port | |
| JP4190114B2 (ja) | マイクロコンピュータ | |
| US6055649A (en) | Processor test port with scan chains and data streaming | |
| US5970241A (en) | Maintaining synchronism between a processor pipeline and subsystem pipelines during debugging of a data processing system | |
| JP3846939B2 (ja) | データプロセッサ | |
| US6065106A (en) | Resuming normal execution by restoring without refetching instructions in multi-word instruction register interrupted by debug instructions loading and processing | |
| US7017029B2 (en) | Coprocessor instruction loading from port register based on interrupt vector table indication | |
| EP0849674B1 (en) | Method and apparatus for debugging a pipeline microprocessor | |
| US6167536A (en) | Trace cache for a microprocessor-based device | |
| US7185234B1 (en) | Trace control from hardware and software | |
| US6154856A (en) | Debug interface including state machines for timing synchronization and communication | |
| US7506205B2 (en) | Debugging system and method for use with software breakpoint | |
| US20060225050A1 (en) | Dynamic selection of a compression algorithm for trace data | |
| US20110010531A1 (en) | Debuggable microprocessor | |
| US20070180333A1 (en) | External trace synchronization via periodic sampling | |
| US9201749B2 (en) | Diagnosing code using single step execution | |
| US20050240820A1 (en) | Method and apparatus for multiprocessor debug support | |
| JPH0689201A (ja) | アイドルモードをアクセスするラン／ストップピンを有するマイクロプロセッサ及びそれを動作させる方法 | |
| JPH1124959A (ja) | マイクロプロセッサのトレース情報出力方法 | |
| EP0854422B1 (en) | A processor test port with scan chains and data streaming | |
| JPH08335177A (ja) | プロセッサ動作観察方法及び装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060526 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090707 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20091007 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20100226 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100309 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4475734 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130319 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130319 Year of fee payment: 3 |
|
| R154 | Certificate of patent or utility model (reissue) |
Free format text: JAPANESE INTERMEDIATE CODE: R154 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130319 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140319 Year of fee payment: 4 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |