(57)【特許請求の範囲】
【請求項１】
（ｉ）処理命令の制御によりデータ値を処理する処理回路と、
（ｉｉ）処理すべきデータ値を記憶するメモリであって、前記処理回路は前記メモリ内に記憶されたデータ値にアクセスするためのデータアクセス命令に応答するものであるメモリと、
（ｉｉｉ）前記処理回路によって実行される処理命令および前記処理回路によってアクセスされるデータ値をそれぞれ識別するデータから成る複数のトレースデータのストリームを発生してトレースバッファに記録させるトレーシング回路とを備え、
（ｉｖ）データアクセス命令は、予め決められた処理サイクル時間内にデータアクセス命令に対応するデータ値をメモリから得ることのできないデータミスを発生させることがあり、
（ｖ）前記トレーシング回路は、データミスが発生すると、前記トレースデータのストリーム内のデータミスが発生しなかった場合にデータ値を識別するデータが置かれるべき位置にデータプレイスホルダーを代わりに発生して前記トレースバッファに記録させ、
データ値を前記予め決められた処理サイクル時間のあとに遅れて得た時に、前記トレーシング回路は遅れて得たデータ値を識別するデータを前記トレースデータのストリーム内の最尾部に挿入する、
データを処理するための装置。
【請求項２】
前記メモリが、キャッシュメモリとメインメモリとを含み、アクセス中のデータ値が前記キャッシュメモリ内に記憶されていない時にデータミスが生じる、請求項１記載の装置。
【請求項３】
前記データプレイスホルダーが前記データプレイスホルダーに対応するタグ値を含み、前記遅れて得たデータ値を識別するデータが前記プレイスホルダーのタグ値に一致するタグ値を含む、請求項１記載の装置。
【請求項４】
複数のデータミスの結果、複数のデータプレイスホルダーが発生された場合、遅れて得たデータ値を識別するデータをデータミスが発生した順序とは異なる順序で発生して前記トレースバッファに記録できる、請求項３記載の装置。
【請求項５】
前記データプレイスホルダーが、トレースの開始から該データプレイスホルダーが生成された時点の間にメモリから得ることのできなかったデータ値の数を示す、請求項１記載の装置。
【請求項６】
前記トレースデータのストリームには周期的に同期化データが挿入され、前記同期化データがトレースの開始から該同期化データが挿入された時点の間にメモリから得ることのできなかったデータ値の数を示すデータを含む、請求項１記載の装置。
【請求項７】
前記トレーシング回路が、１つ以上の前記データ値および該データ値に関連するメモリアドレスに依存するトリガー条件に相当する予め決められた条件の検出によって、トレーシングオペレーションを制御する、請求項１記載の装置。
【請求項８】
前記トレーシング回路が、完全一致信号によって、データミスが発生した場合のそのデータに関連する前記トリガー条件を、
（ｉ）前記データ値を得て、前記トリガー条件に合致することが判るまでトリガーしない完全一致トリガー条件、または
（ｉｉ）データミス時に、将来得られるデータ値が前記トリガー条件に合致すると仮定してトリガーする非完全一致トリガ条件、
のいずれかとする、請求項７記載の装置。
【請求項９】
前記完全一致信号によるトリガー条件（ｉ）または（ｉｉ）がユーザーによって選択可能である、請求項８記載の装置。
【請求項１０】
前記トリガー条件の使用によって、前記完全一致信号がハードウェア制御下に置かれる、請求項８記載の装置。
【請求項１１】
前記完全一致信号が複数の異なる値を持ち、前記トレーシング回路の異なる部分が同時に動作して、それによって前記トリガー条件を、（ｉ）完全一致トリガー条件、または、（ｉｉ）非完全一致トリガ条件のいずれかとする、請求項８記載の装置。
【請求項１２】
（ｉ）処理回路によって、処理命令の制御によりデータ値を処理する工程と、
（ｉｉ）処理すべきデータ値をメモリ内に記憶する工程とを備え、前記処理装置がデータアクセス命令に応答して前記メモリ内に記憶されたデータ値にアクセスし、
（ｉｉｉ）トレーシング回路を使用して、複数トレースデータのストリームを発生する工程であって、各トレースデータは前記処理回路によって実行された処理命令およびアクセスされたデータ値をそれぞれ識別するデータから成り、
（ｉｖ）データアクセス命令は、予め決められた処理サイクル時間内にデータアクセス命令に対応するデータ値をメモリから得ることのできないデータミスを発生させることがあり、
（ｖ）前記トレーシング回路は、データミスが発生すると、前記トレースデータのストリーム内のデータミスが発生しなかった場合にデータ値を識別するデータがおかれるべき位置に、代わりにデータスペースホルダーを発生し、前記データ値を前記予め決められた処理サイクル時間のあとに遅れて得た時に、前記遅れて得たデータ値を識別するデータを前記トレースデータのストリーム内に最尾部に挿入する、
データを処理する方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、データ処理システムに関し、より詳細には、本発明はデータアクセスをトレースできるようにするためのトレーシング機構を提供するデータ処理システムに関する。
【０００２】
【従来の技術】
新システムのための開発時間を短縮したいという要望がある一方で、データ処理システムの複雑性が増すにつれ、データ処理システムの開発中に使用できるデバッグおよびトレーシングツールおよび機構を改善したいという要望が生じている。システム内のステップごとのアクティビティを示すデータを含むトレースストリームを発生するように、データ処理システムのアクティビティをトレースすることは、システム開発において極めて有効なツールとなっている。しかしながら、コアをより深く埋め込むという一般的な動向と共に、外部からアクセス可能なピンを通してコアのステートをトラッキングすることはより困難となっている。従って、トレースデータを捕捉し、分析するためのオフチップトレーシング機構と同じように、チップには多量のトレーシング機能が組み込まれている。かかるオフチップトレーシング機構の例として英国ケンブリッジのＡＲＭリミティッド社により、この会社のＡＲＭ７およびＡＲＭ９プロセッサに関連して提供されている埋め込み型トレースマクロセルがある。
【０００３】
データ処理オペレーションのトレーシングに関連する別の問題は、速度および並列性を追求する際にデータ処理システムの複雑性が高まったことにより、オペレーションをシーケンス化する方法も複雑となったことである。初期のデータ処理システムでは、プロセッサは順に各プログラム命令を実行し、プログラム命令が完了するまで待機し、プログラム命令の完了後、次のプログラム命令の実行を開始していた。しかしながら、プログラム命令の処理スループットを高めるために、次の命令を開始する前に、常に命令を完了していなくてもよいように、またはパイプライン状に、異なる命令をパラレルに実行できるようにする種々の技術が採用されている。このタイプのより複雑な動作の例としては、ロードミスに対するデータ処理システムの応答が挙げられる。
【０００４】
メモリロケーションからデータ値（このデータ値は処理用データまたは命令ワードでよい）をデータ処理システムがロードしたい場合、ロードミスが起こり得る。そのデータ値がローカルキャッシュメモリ内に存在している場合、ロード命令を高速で、可能な場合には１つのクロックサイクル内で完了できる。しかしながら、キャッシュからデータ値のロードを満たすことができず、例えばメインメモリへのより低速の非キャッシュアクセスが必要となるようなロードミスが生じた場合、多数の処理サイクルの間でもデータ値がリターンされないことが起こり得る。後の命令がまだ検索されていないデータ値を必要とすることなく、すなわちまだ検索されていないデータ値に依存しないことを条件に、先のロードミスからのデータを待機しながら、他のプログラム命令の実行を続けることができるＡＲＭ１０２０Ｔプロセッサのようなシステムを提供することが、ホールトデータ処理以外にも知られている。
【０００５】
【発明が解決しようとする課題】
データアクセスミス後にオペレーションの続行をサポートするかかるシステムでは、実行中の命令ストリームがメモリバス上で発見されるようなメモリアクセスからリターンされるデータ値に容易に相関化しないという点で、重要なトレーシングを行う上で問題が生じる。
【０００６】
【課題を解決するための手段】
本発明の１つの特徴によれば、
（ｉ）処理命令の制御によりデータ値を処理するようになっている処理回路と、
（ｉｉ）メモリ内に記憶されたデータ値にアクセスするためのデータアクセス命令に応答自在であり、処理すべきデータ値を記憶するようになっているメモリと、
（ｉｉｉ）前記処理回路によって実行される処理命令および前記処理回路がアクセスするデータ値を識別するトレースデータストリームを発生するようになっているトレーシング回路とを備え、
（ｉｖ）前記データアクセス命令に対応するデータ値が、データミスが生じることなく前記データアクセスが行われた時、そのサイクルの次の処理サイクル時にアクセスされるようなデータミスがデータアクセス命令の結果生じることがあり、
（ｖ）前記トレーシング回路は、前記データミスに応答して、前記データミスが生じなかった場合、前記トレースデータのストリーム内の前記データ値を識別するデータが位置づけられるであろう位置に、データプレースホルダーを発生し、前記データ値に対する前記アクセスが行われた時、前記データ値を識別する後のデータ値をトレースデータの前記ストリーム内の後のポイントに挿入する、データを処理するための装置が提供される。
【０００７】
本発明はデータアクセスミスおよび後にリターンされるデータ値による上記問題を認識し、ミスが生じなかった場合にデータ値をリターンしたはずのポイントを識別するデータプレイスホルダーをトレースデータのストリーム内に挿入し、次にミスから生じた後のデータ値をその後挿入する解決案を提供するものである。データプレイスホルダーと後のデータ値の組み合わせによってデータストリームのその後の分析を可能にし、どのデータ値がどのアクセス命令に対応しているかを正しく識別し、よってデータ処理システムの動作を正しく理解することが可能となる。データ値は命令ワードだけでなく、操作のためのデータでもよく、データ値なる用語は双方の可能性を含むものであることが理解できよう。
【０００８】
本発明は種々の異なる環境内で使用できるが、システム内のアクセスミスが比較的一般的な場所で生じるように、キャッシュメモリとメモリシステムが設けられているシステムに特に適し、アクセスミスに関するシステムの正しい動作を理解することが、かかるシステムを正しくデバッギングする上で重要である。
【０００９】
データプレイスホルダーと後のデータとの間の相関化は種々の異なる方法で行うことができる。１つの好ましい実施例は、タグ値と各データプレイスホルダーとを関連付け、次に対応するタグ値と後の各データ値とを関連付けることである（この機構はそれぞれのプレイスホルダーに異なる順序で後のデータアイテムをリターンさせることをうまく処理することもできる）。従って、トレースデータのストリームの分析時に、後のどのデータ値がどのデータプレイスホルダーに対応しているかを判断するように、それぞれのタグ値を一致させることができる。別の好ましい実施例はトレースされたデータのストリーム内に各データプレイスホルダーを挿入する際に、トレースされたデータのストリームを後に分析する時に、トレースデータの完全なストリームを必要とすることなく、適当な後のデータ値を適当なデータプレイスホルダーに一致させることができるように、そのときにどれだけ多くのペンディング中の後のデータ値が未解決となっているかの表示もなされる。別の好ましい実施例は、トレースされたデータのストリームがその時にどれだけ多くの未解決の後のデータ値を待っているかを示す周期的同期化データを含む例である。従って、途中でトレースされたデータのストリームをピックアップする際に、１つの同期化データ部分を一旦読み出せば、次のデータプレイスホルダーとデータ値を一致させることができる。
【００１０】
データ処理システムのトレーシングオペレーションのコンテキストにおいて、トレーシングウォッチポイントを設けることは公知である。トレーシングオペレーション、例えば単一命令のトレーシング、所定の組の基準が満たされるかどうかに基づくトレースストリームのターンオン、トレースストリームまたはその他のトレーシング動作のターンオフの制御をトリガーするのに、かかるトレーシングウォッチポイントを使用できる。かかるウォッチポイントの基準の一例は、アクセスデータ値が特定の条件に一致しているかどうかということである。一例として、所定量よりも大きいデータ値に対してアクセスがなされる時は常に、トレーシングデータのストリームをスイッチオンするようにトレーシングウォッチポイントを設定できる。これに関連し、アクセスミスは重要な複雑な問題を生じさせることが理解できよう。アクセスミスが生じると、そのアクセスミスに対応するデータ値がトリガー条件に一致するのか一致しないのかは、後の時間まで判らない。この問題は完全に解決することはできないが、本発明の好ましい実施例は後のデータ値がリターンされた時にトリガーが一致するとの仮定でアクセスが生じた時に、トリガー条件がトリガーされることを選択するか、または後のデータ値が実際にリターンされ、一致していると判るまでトリガー条件をトリガーしないことを選択するかのいずれかの能力を提供するものである。これらオプション案の双方を設けることによって、ユーザーが望むように、このような状況に対し、システムの動作を構成できる能力がトレースシステムユーザーに与えられる。２つの動作が必要な場合の状況の例として次の例がある。
【００１１】
（ａ）ウォッチポイントに基づきトレースストリームをターンオンし、オンの状態のままにする。トレースストリームを早期にターンオンしないことが重要であるが、元のアクセスを生じさせた命令をトレースすることは遅すぎることとなる。
（ｂ）ウォッチポイントの基準が満たされた場合にしかトレースストリームをターンオンせず、次に再びターンオフとする。データストリーム内に記憶されるデータ量を少なくするために、データ値の比較を実行するが、ロードミスが生じた場合、データが利用できるようになり、よって一致していると見なされる前にロードミスをトレースするかどうかの判断を行わなければならない。
【００１２】
上記２つの状況はデータが将来の事象をトレースすべきかどうかを判断するか、または当該データがそのデータ自身であるかどうかのいずれかである。
【００１３】
本発明の別の特徴によれば、
（ｉ）処理命令の制御によりデータ値を処理する工程と、
（ｉｉ）処理すべきデータ値を記憶する工程とを備え、データアクセス命令が記憶されたデータ値にアクセスするようになっており、
（ｉｉｉ）実行される処理命令およびアクセスされるデータ値を識別するトレースデータのストリームを発生する工程とを備え、
（ｉｖ）前記データアクセス命令に対応するデータ値が、データミスが生じることなく前記データアクセスが行われた時、そのサイクルの次の処理サイクル時にアクセスされるようなデータミスがデータアクセス命令の結果生じることがあり、
（ｖ）前記トレーシング回路は、前記データミスに応答して、前記データミスが生じなかった場合、前記トレースデータのストリーム内の前記データ値を識別するデータが位置づけられるであろう位置に、データプレースホルダーを発生し、前記データ値に対する前記アクセスが行われた時、前記データ値を識別する後のデータ値をトレースデータの前記ストリーム内の後のポイントに挿入する、データを処理する方法が提供される。
【００１４】
上記トレースデータを発生するための装置、例えばマイクロプロセッサを載せた集積回路および方法を提供するだけでなく、本発明の相補的特徴は、かかる装置およびかかる方法によって発生されるトレースデータのストリームを分析できるシステムを提供することである。かかるコンピュータプログラムは標準的な汎用コンピュータで実行でき、コンピュータプログラム製品として、例えばフロッピー（登録商標）ディスクまたはＣＤ記録媒体として提供できる。
【００１５】
添付図面を参照し、次の実施例の詳細な説明を読めば、本発明の上記以外の目的、特徴および利点が明らかとなろう。
【００１６】
【発明の実施の形態】
図１は、オンチップトレーシング機構を提供するデータ処理システム２を略図で示す。集積回路４は、マイクロプロセッサコア６と、キャッシュメモ８と、オンチップトレースモジュールコントローラ１０と、オンチップトレースバッファ１２とを含む。キャッシュメモリ８内でキャッシュミスが生じた際にアクセスされる外部メモリ１４には集積回路４が接続されている。オンチップトレースモジュールコントローラ１０およびオンチップトレースバッファ１２には汎用コンピュータ１６が結合されており、この汎用コンピュータ１６上で実行されるソフトウェアを使って、これら要素からのトレーシングデータのストリームを回復し、分析するように働く。
【００１７】
オペレーション中に外部メモリ１４にある実際の空間よりも多いデータ処理命令およびデータにプロセッサコア６がアクセスしなければならないようなケースが多い。例えば外部メモリ１４のサイズが１ＭＢであり、一方、プロセッサコア６が一般に３２ビットのアドレスを指定でき、よって４ＧＢの命令およびデータを指定できることがある。従って、プロセッサコア６が必要とする命令およびデータのすべては外部記憶装置１８、例えばハードディスクに記憶され、次にプロセッサコア６が特定のオペレーションステートで作動すべき場合に、そのオペレーションステートのための対応する命令およびデータを外部メモリ１４内にロードする。
【００１８】
図２は図１のシステム内で生じ得るデータアクセス命令への応答時の種々の動作を示す。この場合におけるプロセッサコア６はＡＲＭオブジェクトコード命令を実行するＡＲＭプロセッサである。図２における第１コードシーケンスは別のレジスタＲmに与えられるアドレスによって指定されるメモリロケーションから指定レジスタ内にデータをロードするロード命令１８を示す。この場合、データアクセス命令の結果、キャッシュメモリ８内でヒットが生じ、レジスタＲmによって指定されたアドレスから対応するデータ値が同じサイクルでプロセッサコア６へリターンされる。
【００１９】
第２の例では、同じ命令シーケンスが発生されるが、この場合、命令２０の結果、キャッシュメモリ８内でミスが生じる。集積回路４はこのような動作にうまく対応し、その後の命令がミスの生じたデータを必要としないことを条件に、ミスを発生したロード命令２０の後の命令を実行し続けるようになっている。可変時間後に、アクセスミスに対応するデータはシステムのデータバスにリターンされる。この後のデータは正しいレジスタにルーチングされ、レジスタのインターロッキングはクリアされる。後のデータがリターンされるまでの遅延時間は特定の状況に応じて変わり得ることが理解できよう。集積回路４は更に記憶容量を増すために、より大きく、低速のメインＡＲＭメモリの前に、比較的高速のオフチップキャッシュメモリを含むようなマルチレベルの外部メモリシステムに結合できる。集積回路自体がこのような後の可変遅れデータにうまく対応できるようにするための機構は当技術分野で知られており、本発明の技術は少なくとも好ましい実施例において、データのトレーシングがこのような後にリターンされるデータおよび可変遅れデータにうまく対応できるようにする機構を提供せんとするものである。
【００２０】
図２における第３コードシーケンスは２つのロード命令２２、２４を有し、これら双方の命令の結果、データミスが生じ、これら命令はリターンされる対応する後のデータを有する。この例では、データバスにリターンされた後のデータは、このデータミスを発生させたデータアクセス命令２２、２４のシーケンスの順序からはずれている。従って、第１のミスされたデータアクセス２２は第２の後のデータアイテム２６に対応し、一方第２のミスされたデータアクセス２４は第１の後のデータアイテム２８に対応する。
【００２１】
図３は、データミスを発生するデータアクセス命令に応答するオンチップトレースモジュールコントローラ１０の動作を示す。このオンチップトレースモジュール１０はそのトレースデータを高速でオンチップトレースバッファ１２内に書き込む。これによってプロセッサコア６による命令のフルスピードの実行に対してリアルタイムでペースを合わせながら、トレーシングを発生させることができる。後の時間に汎コンピュータ１６がトレースバッファ１２の内容を読み出し、トレースデータを分析することができる。
【００２２】
図３に示されるように、第１ロード命令３０の結果、キャッシュ命令８内でデータミスが生じる。従って、このミスを発生した命令トレースストリーム内の命令３０に対する対応するポイントにあるデータトレースストリーム内にデータプレイスホルダー３２が挿入される。このデータプレイスホルダー３２は、そのデータプレイスホルダーを識別する関連するタグ値（Ｔａｇ１）を有する。その後の時間に、別のデータアクセス命令３４の結果、同じ処理サイクル内でリターンされ、命令３４に直接一致するポイントにおいてデータトレースストリーム内に入れられたデータ値３６とのヒットが生じる。次の命令３８の結果、別のデータミスが生じ、異なる識別タグ値（Ｔａｇ２）を有する別のデータプレイスホルダー４０が挿入される。
【００２３】
可変時間の後に、データバス上に２つの後のデータ値４２、４４がリターンされ、データトレースストリーム内に挿入される。これら後のデータ値の各々はデータトレースストリーム内で先行する対応するデータプレイスホルダーに一致できるようにする関連したタグ値を有する。この特定の例では、後のデータ値はデータミスを発生したデータミスの順序と異なる順序でリターンされる。従って、リターンされた第１の後のデータ値４２はＴａｇ２のタグ値を有し、データプレイスホルダー４０および命令３８に対応する。第２の後のデータ値４４はＴａｇ１のタグ値を有し、データプレイスホルダー３２および命令３０に対応する。
【００２４】
データプレイスホルダーおよび後のデータ値の分析は汎用コンピュータ１６を使用して集積回路４の外部で行われることが理解できよう。この汎用コンピュータ１６はプログラム制御に従って対応するタグ値を有するデータプレイスホルダーのためにデータトレースストリームをサーチし、命令とリターンされる対応するデータとの間の適性な対応性を引き出すことができるように、これらデータプレイスホルダーを、一致するタグを有する、後に識別された後のデータ値に置換する。フルトレース分析では、タグの一致を使ってこれら後のデータ値を一致する命令に正しく関連付けするようなトレーシング環境内で、リターンの遅延効果も正しく理解できるよう、データ値がリターンされた位置に後のデータ値を残すことができる。
【００２５】
命令トレースストリームおよびデータトレースストリームの動作について定義したので、標準技術および標準集積回路設計ツールに従い、このような機能を提供するオンチップトレースモジュールコントローラ内の制御ロジックを誘導できる。
【００２６】
図４は別の実施例を示す。この実施例では、データプレイスホルダーはタグ値を含まず、代わりに後のデータ値自身をデータトレースストリーム内に挿入する際に未解決となっているペンディング中の後のデータ値の個数を示す。従って、命令４６から生じるデータミスの結果、データプレイスホルダー４８はペンディング中の後のデータ値の個数ゼロを示す。データプレイスホルダー４８に対応する後のデータ値がリターンされる前に、ミスを発生させるような次の命令５０が生じ、従って、データプレイスホルダー５２は既に未解決のペンディング中の後のデータ値があることを表示する。次に、ミスを発生させるような別の命令５６が実行される前に、命令４６に対応する後のデータ値５４がリターンされる。命令５６を実行する際に、未解決の後のデータ値の数はまだ１つであるので、データプレイスホルダー５８はこれを表示するようにマークされる。
【００２７】
図４に示されたデータトレースストリームフォーマットは、このデータストリームを分析することにより可変位置からピックアップされ、トレースストリームのスタートより前のポイントに対しリターンされた後のデータ値による混同を防止することが可能となるが、（図５の実施例で行っているように）ミスは順序通りにリターンされなければならない。
【００２８】
図５は、別の例のトレースストリームフォーマットを示す。この例では、トレースされたデータのストリーム内に同期化データ６０を周期的に挿入する。この同期化データはこの時間ポイントにおいて未解決の後のデータアイテムの数を示す。従って、同期化データアイテム６０はミスしたデータアクセス命令６２に対応する１つのペンディング中の後のデータアイテムを示す。本例におけるデータプレイスホルダーはこれらが対応する命令を指定する別の情報を含まない。
【００２９】
同期化データアイテム６０の次のロード命令６４の結果によってもミスが生じ、データストリーム内に対応するデータプレイスホルダー６６が挿入される。リターンされた第１の後のデータアイテム６８が、ミスを発生しよって正しく分析できないトレースされていない先の命令６２に対応していることを、同期化データ要素６０が示すので、リターンされた第１の後のデータアイテム６８は無視される。次の後のデータアイテム７０がリターンされると、このデータアイテムはロード命令６４に対応していると判断される。
【００３０】
図６は、トレーシング制御オペレーションをトリガーするのに使用できる回路要素７２を示す。この回路要素７２は適当なトレースウォッチポイントをトリガーするために、現在のバスの値とアドレスデータ値とを比較するよう、所定の値、可能な場合には関連するマスクをロードできる複数の比較器を含む。
【００３１】
後にリターンされたデータのコンテキスト内にて、データウォッチポイントは完全一致ウォッチポイントまたは不完全一致ウォッチポイントのいずれかとなるように構成される。後のデータがリターンされ、指定されている基準に一致していることが判るまで、完全一致ウォッチポイントがトリガーされることはない。逆に、不完全一致ウォッチポイントは、後のデータがリターンされた時に、一致を引き起こすと仮定して、そのデータ値に対するデータミスが発生した時にトリガーされる。これら２つの動作のいずれかに対するウォッチポイントのコンフィギュレーションは、トレースシステムのユーザーによって所望するように制御できる。リターンされる後のデータ値とこれら値が関連する対応するアドレスとの間のリンクをするように、ウォッチポイント比較システム内には後のデータ値に対応するタグ値も保持される。
【００３２】
図７および８は、図７のシステムから生じ得る異なるタイプの動作を示す。命令７４の結果、データミスが生じ、データ７６は後の時間にデータバス上に後にリターンされる。
【００３３】
図８は命令７４内で指定されたアドレスに対応するアドレスにウォッチポイントが設定され、従って、指示されたすべての可能性に対してアドレスの一致が生じると仮定している。第１の２つの可能性において、ウォッチポイントは完全一致ウォッチポイントに設定されている。従って、最初の２つの例では、データ７６がリターンされ、一致していることが判るまで、トレーシング事象はトリガーしない。図８の第１の行は、データが一致し、トレーシング起動ポイントが図７内のポイントＰ１となることを示している。図８の第３および第４の行では、ウォッチポイントは不完全ウォッチポイントとして設定されている。従って、これらケースの双方においてデータの一致がその後生じるか否かに関係なく、ポイントＰ２でアドレスの一致が発生する際に、トレースの制御がトリガーされる。第４の行ではその後、データの一致が生じていなくてもトレースポイントがトリガーされていることが理解できよう。
【００３４】
種々の方法、例えば条件に応じて完全一致信号を構成自在とし（この方法が好ましい）、比較を行うべき、用途に応じたハードウェア内で完全一致信号を選択し、比較ハードウェアが同時に双方の動作を提供できるようにし、トレーシング回路の異なる部分内で異なる動作を適当に使用することによって完全一致信号を制御し、使用することができる。
【００３５】
図９は、マイクロプロセッサの集積回路１０４と外部メモリの集積回路１０６とを含むデータ処理システム１０２を示す。マイクロプロセッサの集積回路１０４はその多くの異なる回路要素（そのすべてが図示されているわけではない）のうちにレジスタバンク１０８と、キャッシュメモリ１１０と、乗算器１１２と、シフター１１４と、加算器１１６と、命令デコーダ１１８と、トレースコントローラ１２０と、トレースデータバッファ１２２とを含む。
【００３６】
オペレーション時に、命令デコーダ１１８はプログラム命令ワードを受信し、制御信号を発生する。この制御信号はマイクロプロセッサの集積回路１０４内の他の要素によって使用され、これら要素のオペレーションを制御するようになっている。特定の命令は乗算器１１２、シフター１１４および加算器１１６のうちの１つ以上を使用し、レジスタバンク１０８のレジスタ内に保持されている値に対して代数論理演算の実行に関与し得る。命令デコーダが応答できる別のタイプのデータ処理命令は、マルチワードデータ転送命令である。かかるタイプの命令の一例としては、マイクロプロセッサ、例えばＡＲＭ７およびＡＲＭ９によって提供されるＬＳＭ命令が挙げられる。これら例のマルチワードデータ転送命令のオペレーションの詳細については、上記マイクロプロセッサのデータシートに記載されている。
【００３７】
マイクロプロセッサの集積回路１０４のチップ上にはトレースコントローラ１２０およびトレースデータバッファ１２２が設けられている。このトレースコントローラ１２０は多くの異なるタイプのオペレーションを提供し、これらタイプのオペレーション内にはトレーストリガー条件が検出された時のトレーシングオペレーションの開始が含まれる。トレースコントローラは特定のアドレス値およびデータ値を検出するよう、システム内のアドレスバスおよびデータバスを「スヌープ」できるか、またはレジスタバンク１０８内の特定のアドレスへのアクセスを検出するよう、レジスタバンク１０８を制御する信号に応答できる。これらケースのいずれにおいても、トレースコントローラ１２０は所定の条件が検出された時にトレーシングオペレーションを開始し、トレースデータストリームをトレースデータバッファ１２２内に記憶させるように働くことができる。その後、トレースデータのこのストリームはトレースデータバッファから外部トレースデータバッファ分析システムへダウンロードでき、この分析システム内で、システムをデバッグしたり、またはその分離をより完全に理解することを望む者が検査し、解読できる。
【００３８】
図１０はマルチワードデータ転送命令、すなわち上記ＬＳＭ命令を示す。この命令のオペレーションを制御するフィールド内にはレジスタバンク１０８内のレジスタＲnに対するポインターがあり、このポインターは命令のマルチワード転送をするためのスタートポイントを示すメモリアドレス記憶データ値を制御する。この命令は、レジスタバンク１０８内の１６個のレジスタの各々に１ビットが対応する１６ビットフィールドも含む。特定のビット位置における「１」の値は、そのレジスタに対してデータ転送が行われるべきであることを示し、従って、単一のＬＳＭ命令によって１〜１６までの任意の数のデータ転送を指定できる。図示されている例では、レジスタリストはレジスタＲn内に保持されている値で開始するメモリアドレスと、レジスタＲ０、Ｒ１、Ｒ３、Ｒ７およびＲ１１内に保持されている値でスタートするメモリアドレスとの間で５つのデータワードを転送すべきであることを指定する。この転送は、最小数のレジスタでスタートし、転送ごとに４ビットメモリをインクリメントしながら進む。
【００３９】
図１０に示されるように、データ処理システム１０２の高性能の実施例は、メモリシステム（キャッシュメモリ１１０または外部メモリ１０６のいずれか）からそれらのそれぞれのレジスタへパラレルに２つのデータ値を転送するように働くことができる。これによってＬＳＭ命令をより短時間で完了し、全体の処理をスピードアップすることが可能となる。かかる実施例では、ＬＳＭ命令の実行の途中にインターラプトまたは例外が生じた場合でも、データ転送を逐次行うようなプログラマーのモデルが破られることがないように注意を払わなければならない。
【００４０】
図１１は、図１０の例を発展したものであり、この図１０を使ってマルチワードデータ転送命令ＬＳＭの所定のトレース開始条件のトリガーを部分的に示している。特に、レジスタＲ３とメモリロケーションＡｄｄ＋８との間のデータワードＤＷ3の第３のデータ転送はトリガーを生じさせている。このトリガーは「＃」と表示されているアクセス中の特定のレジスタから、「＊」と表示されている転送中のデータ値から、または「！」と表示されているアクセス中のメモリロケーションから行うことができる。これら多数の条件を同時に満たし、その結果、マルチサイクルのマルチワードデータ転送命令内のそのポイントでトレーストリガーを行うこともできる。
【００４１】
トレースコントローラ１２０はトレーストリガー条件を検出し、トレースをトリガーした転送からスタートし、トレースデータバッファ１２２にトレースデータのトレースデータストリームを書き込むことによってトレーシングオペレーションを開始する。特に、トレースデータストリームにはマルチワードデータ転送自体が書き込まれ、その後、トレーストリガーを生じさせたデータ値およびアドレス値が書き込まれる。マルチワードデータ転送命令（この命令は書き込みまたは読み出しでよい）の終了までの残りのデータ転送の結果、トレースデータストリームにトレースデータが追加される。トレースデータストリームのバンド幅を保留するために、より詳細な情報を含むのではなく、ＬＳＭ命令の終了までのこれら転送の各々に対し、プレースフォルダーデータコードを挿入できる。このプレースフォルダーコードはトリガーを開始したレジスタまでカウントバックし、よって当該レジスタを識別するように、後の分析システムによって使用できる。トレースコントローラ１２０はトリガー転送自体および同じ命令内のその後の転送しかトレースせず、その後の命令の後のトレースは行わないようにするか、または前方のポイントからリターンされたままになっているトレーシングをターンオンするように構成できる。当業者にはこれらのいずれも、また、他の可能な案も明らかであろう。
【００４２】
図１２はトレースコントローラ１２０によって実行できる制御オペレーションを略図で示す。ステップ１２４においてトレースコントローラ１２０はこのコントローラがトレーシングをスタートするようにトリガーされたかどうかを判断するために連続的にチェックを行う。ステップ１２６において、マルチワードデータ転送命令ＬＳＭの実行中にトレースがトリガーされたかどうかのチェックを行う。トレーストリガーがマルチワードデータ転送命令の結果でない場合、処理は他のルーチン１２８に進む。このルーチンについては本技術の解説ではこれ以上説明しない。
【００４３】
ＬＳＭ命令によってトレースがトリガーされたと仮定された場合、ステップ１３０を実行する。このステップではトリガーオペレーションのためのトレースデータストリーム内に命令、データワードおよびメモリアドレスを書き込む。その後の各オペレーションがステップ１３２で検出されると、このオペレーションが同じＬＳＭ命令の一部であるかどうかのチェックをステップ１３４で行う。同じＬＳＭ命令が続いている場合、処理はステップ１３６に進み、このステップでトレースデータストリーム内にプレイスホルダーコードを挿入し、別のデータ転送を表示し、ステップ１３２にリターンする。マルチワードデータ転送命令が終了したことをステップ１３４の判断が示している場合、その命令のトレーシングは終了する。一部の実施例では、トレーシングはオン状態のままとし、その後の命令をトレーシングされたデータストリーム内にトレースするか、または特定のトリガー命令だけをトレースすると設定されていた場合には、トレーシングは終了してもよい。
【００４４】
図１３は上記実施例に従って発生したトレースデータストリームに応答自在なトレースデータ分析システム内で実行し得る処理を略図で示している。ステップ１３８において、トレースデータストリーム（またはトレースデータストリームのうちの少なくとも命令部分）内でＬＳＭマルチワードデータ転送命令に遭遇する。ステップ１４０において、分析システムはトレースデータストリーム内でデータ転送のうちの最終データ転送および総カウントが確立するまで、そのＬＳＭ命令に対し、トレースデータストリーム内にマークされた転送の終了までカウントを行う。
【００４５】
次のアーキテクチャの説明に本発明の少なくとも好ましい実施例のトレーシング技術の更なる説明が記載されており、次のアーキテクチャの説明は英国ケンブリッジのＡＲＭリミティッド社から公に入手できる、埋め込み型トレースマクロセル（Ｒｅｖｌ）と関連して読むべきである。
【００４６】
以上で、添付図面を参照し、本発明の図示した実施例について詳細に説明したが、本発明は本書に説明した実施例のみに限定すべきでなく、当業者であれば特許請求の範囲記載の発明の要旨から逸脱することなく、種々の変形および変更を行うことができよう。
【００４７】
１．１
本書では、次の用語および略語を使用する。
0004038372.tif 000002
【００４８】
範囲
本書はＥＴＭ１０の機能を特定するためのものであり、ＥＴＭ１０は命令およびデータのトレーシングを行うことができるリアルタイムトレースモジュールである。機能はＡＲＭ７およびＡＲＭ９の以前のＥＴＭ実現例の機能に類似している。読者は埋め込み型トレースマクロセルの仕様（ＡＲＭ  ＩＨＩ  ００１４Ｄ）に概略が記載された元のＥＴＭ仕様に精通しているものと見なす。本仕様はＥＴＭ１０と以前のＥＴＭバージョンとの間の共通するアーキテクチャ上の特徴を記述し直すものではなく、むしろＥＴＭ１０に対して変わったＥＴＭ仕様の部分について記述するものである。これら変更のほとんどはＡＲＭ１０２０Ｅを正しくトレーシングできる新しいＥＴＭプロトコルの作成に関連したものであり、このプロトコルは将来のＡＲＭコアも同じようにトレーシングするように拡張可能となっている。
【００４９】
前書き
埋め込み型トレースマクロセルは、ＥＴＭ、トレースポートアナライザおよびソフトデバッガー（例えばＡＤＷ）を含むＡＲＭのリアルタイムデバッグ解決案の不可欠な部分である。
埋め込み型トレースマクロセルは２つの部分、すなわちトレースブロックとトリガーブロックとから成る。トレースブロックは圧縮されたトレースを作成し、狭いトレースポートを通過するようにこれを出力する役割を果たす。トリガーブロックはユーザーがトリガー条件を指定できるようにするプログラマブルリソースを含む。トリガーブロックリソースはどの命令およびどのデータ転送をトレースするかを制御するためのフィルタとしても使用される。（トリガーブロックリソースを含む）すべてのＥＴＭコンフィギュレーションレジスタは、ＪＴＡＧインターフェースを通してプログラムされる。ユーザーはソフトウェアデバッガーを使ってこれらレジスタにアクセスし、一旦トレースがキャプチャーされると、デバッガーはトレースを逆圧縮し、実行したコードのフルディスアセンブリをユーザーに提供する役割を果たす。デバッガー用ソフトウェアはリアルタイムでＥＴＭトレースポート出力を処理できないので、最初は外部トレースポートアナライザ（ＴＰＡ）内にトレースがキャプチャーされる。ＴＰＡは完全に機能的なロジックアナライザまたはＥＴＭ固有のデバイス、例えばAgilent社の n Traceボックスでよい。一旦トリガー条件が発生し、デバッグの実行が完了すると、デバッガーはＴＰＡからトレース情報を抽出する。このハイレベルの記述では、ＥＴＭ１０はＥＴＭ７およびＥＴＭ９に機能的に同一である。
【００５０】
ＥＴＭ１０に必要な変更
ユーザーから見れば、ＥＴＭ１０はＥＴＭ７およびＥＴＭ９が提供する機能に対し、等価的な命令およびデータトレーシング機能を提供するが、違いはわずかである。この章ではＥＴＭ１０のためのＥＴＭアーキテクチャに対して行われた変更およびこれら変更を行った理由について述べる。多くの変更は、逆圧縮ソフトウェアにしか影響せず、トレースツールキットソフトウェアの他の部分と同じように、エンドユーザーには判らない。しかしながら、いくつかの変更点はプログラマーのモデルに影響するか、またはその結果、ＥＴＭ７およびＥＴＭ９とはトレーシングの動作に若干の変更がある。この章では、かかる変更について述べる。新プロトコルのより詳細な説明を必要とするＥＴＭ１０に対する変更は、第５章に示されたプロトコルの説明に、より完全にカバーされている。
【００５１】
１．２    ブランチファントムトレーシング
ＡＲＭ１０は「ブランチフォールディング」を実現する。このことは、通常の命令ストリームからブランチを予測し、引出し、プログラム内の次の命令とパラレルに効果的に実行できることを意味する。これらのフォールディングされたブランチをブランチファントムと称す。旧プロトコルにおけるPIPESTATコーディングは１回のサイクルについて実行される１つの命令しか考慮していない。ブランチファントムのトレースを可能にするために命令とパラレルにフォールディングされたブランチを示すPIPESTATに新しいコーディングが追加される。第５章のＥＴＭ１０のプロトコル仕様には、新PIPESTAT値が記載されている。
フォールディングされたブランチはトリガーブロックの変更も必要とする。ブランチがフォールディングされると、２つの命令がパラレルに効果的に実行される。これら２つの命令に対するＰＣ値は識別可能な関係となるように保証されていないので、サイクルごとに２つのアドレスの比較を行わなければならない。このことは、各アドレスレジスタが２つのコンパレータを必要とすることを意味する。トレーシングがイネーブルかどうか判断する際には、コンパレータの双方の出力を検討する。（これら２つの命令のいずれかをトレースしなければならない場合、そのサイクルでトレーシングをイネーブルする。）ブランチフォールディングにより多くて１つのエキストラ命令をトレースすることを保証するには、特別な注意を払わなければならない。一般にユーザーはブランチがフォールディングされ、TraceEnableまたはVewDataを正しくプログラムするために次の命令とパラレルに実行されていることをユーザーは知っている必要はない。
事象に対し、命令のパラレルな実行によってＥＴＭ１０対ＥＴＭ７／９と若干異なる動作とすることができる。事象を一般に使用する態様に起因し、機能の損失が大きくなることは感じられない。カウンターは１サイクルにつき１回しかカウントダウンできないが、単一アドレスのコンパレータを使用する際には、カウンティングはアクセスの完全カウントしか提供しない。更に、Trigger、TraceEnable、VewData、またはExtOutに対する機能のロスはなく、命令転送またはデータ転送のいずれかが、個々に事象をアクティブにした場合（このことは望ましい動作である）、その事象はアクティブとなる。シーケンサが同じサイクル内で多数の過渡リクエストを受けた場合、過渡現象は発生せず、シーケンサは元の状態のままである。このような動作はＥＴＭ７およびＥＴＭ９の動作と同じである。ＡＲＭ１０は、よりパラレルな実行をサポートするので、ＥＴＭ１０は１サイクル内で多数の過渡リクエストの発生をより多く有し得る。ユーザーはシーケンサをプログラムする際にはこのような動作を知っていなければならないが、単一事象に対してはワークアラウンドがある。望ましい動作が事象Ａに基づくステート１≧２からの、および事象Ｂに基づくステート２≧３からの過渡である場合、事象（Ａ＆！Ｂ）において１≧２が発生し、事象Ｂにおいて２≧３が発生し、および事象（Ａ＆Ｂ）において１≧３が発生するようにプログラムする。このようにシーケンサをプログラムすることによって、事象Ａと事象Ｂの同時発生を正しく処理することが保証できる。
【００５２】
１．３    ロードミスおよび例外トレーシング
ＡＲＭ１０は非ブロッキングデータキャッシュを有し、このデータキャッシュは他のメモリ命令を含む他の命令を単一の未解決ミスの元で実行できるようにするので、データキャッシュはデータをコアへ順不同でリターンすることができるようにする。この機能は、現在のプロトコルはロードデータをＦＩＦＯに順に挿入することを予測しているので、ロードデータをトラッキングする上での問題となっている。データパケットは一部が順序外ロードミスデータに適合するためのヘッダーバイトのプリフィックスが付けられている。ヘッダーバイトについては第５章で詳細に説明する。
非ブロッキングキャッシュをサポートするには、データコンパレータを変更することも必要である。ＥＴＭ７およびＥＴＭ９と同様に、ＥＴＭ１０はデータコンパレータを有し、これらデータコンパレータは一対のアドレスコンパレータと組み合わせて使用される。コンパレータを使用する際に、コンパレータはデータが一致した時の一致しかトリガーしない。ミスの基では他のメモリアクセスも起こり得るので、ミスを生じ、支えたロードリクエストに対するアドレスが一致しているかどうかを思い出すことができるようにするために、各コンパレータに１つのビットを加える。ロードミスデータがリターンされると、データ値の比較を行い、セーブされたアドレス一致ビットを使用して比較の結果の評価を行う。この一致ビットをクリアする。ある場合、ユーザーはコンパレータをイネーブルするためにミスデータが戻されるのを待つのを望まないことがある。その代わりにユーザーはデータアドレスだけに基づき、ロードミスを常にトレースすることを望むことがある。双方の異様モデルをサポートするために、各コンパレータに対し、どのモードをイネーブルするかをユーザーが指定できるようにするために、アドレスアクセスタイプのレジスタに１ビットが加えられている。ユーザーが比較するロードミスデータを待つことを望む場合、アドレスアクセスタイプレジスタのうちのビット８、すなわち完全一致ビットをセットしなければならない。（アクセスタイプのレジスタに関して更に情報が欲しい場合にはレファレンス１を参照されたい。）トリガーおよびその他の事象を発生するために、データ値を使用する際にはデータの比較が生じるのを待つことが有効である。トレースフィルタリングに対し、コンパレータを使用し、余分なトレーシングが問題であると見なされない場合、アドレスだけに基づくロードミスのトレーシングが有効である。ユーザーは事象、例えばシーケンサの変化を生じさせるためにデータ値を使用する結果、ロードデータが順序外データとしてリターンすることができるので、順序外の事象が発生し得ることについて知っていなければならない。ＡＲＭ１０の非ブロッキングキャッシュがプログラムされた事象に影響し得ることをユーザーが気にする場合、この機能はｃｐ１５のコンフィギュレーションレジスタ（ｒ１）への書き込みによりコアでディスエーブルできる。より詳細については、ＡＲＭ１０２０Ｅ  ＴＲＭ（レファレンス３）を参照されたい。
【００５３】
アボート、インターラプトまたはソフトリセットが行われる際の、コンパレータの動作を特定するために、アクセスタイプのレジスタのビット７も使用される。これら条件は包括的に例外と称される。データアクセスがアボートされ、ビット７がアサートされる場合、コンパレータはデータの一致がリクエストされるか否かに拘わらず、ＮＯＴ演算の結果、一致を出力する。コンパレータが命令アドレスに結合されている場合、例外としてマークされた命令に対するノッチを防止するために、完全一致ビットが使用される。例外を生じさせるような命令およびデータリクエストは、一旦アボート条件またはインターラプト条件が解決されると、通常再試行されるので、コンパレータが１回だけファイアーを意味している場合には、このような動作が望まれることが多い。データアクセスのケースではビット７がアサートされないと、データ値は有効でないと見なされるので、アボートされたアクセスは純粋にアドレスに基づく一致を生じさせる。
【００５４】
所望される動作は一般に双方のケースに対して同じであるので、ロードミスおよびデータアボートの適正な取り扱いを判断するのに、同じ完全一致ビットが使用される。四角な一致ビットに対するデフォルト値はゼロである。
【００５５】
１．４    ＡＲＭ１０のデータトレーシング
ＡＲＭ１０２０Ｅは１サイクルで６４ビットのデータをリターンできる６４ビットデータバスを有する。この６４ビットデータバスをサポートするためには、ＥＴＭ１０は１サイクルで２つの隣接するデータ値をトレーシングできなければならない。１つの値またはその他の値のトレーシングをサポートするために次に２つのViewData出力を発生する。しかしながら、複数の事象に対して１つの出力およびTraceEnableに対して１つの出力しかない。同じサイクルでアクセスされる２つの隣接する３２ビットのリクエストの結果、カウンターが１つデクリメントされるか、またはシーケンサにより１つのステート変化しか生じないので、１つの事象出力を設けると、カウンターおよびシーケンサロジックに影響がおよぶ。事象ロジックをプログラムする際にユーザーはこのことを考慮しなければならないが、大きな問題となるとは予想されない。
【００５６】
１．５    ＬＳＭトレーシング
ＡＲＭ１０２０Ｅは独立したロード／記憶ユニットを有する。このロード／記憶ユニットがデータアクセスを繰り返す間（すなわちＬＳＭの実行はコアをストールさせない）、ロードまたは記憶マルチ命令（以下、ＬＳＭと称す）の元でこのユニットによりその他の命令を実行することが可能となる。これをサポートするために、アドレスコンパレータの出力およびTraceEnableのアサーションに若干の変更が必要である。
・ＬＳＭ命令を繰り返しながら、この命令をアクティブにトレーシングする時はいつも、トレーシングはアクティブなままであるが、この状態はTraceEnableがアサートされた状態のままであるか否かにかかわらず、ＬＳＭが完了するまでこのトレーシングのアクティブ状態は続く。（この規則に対する唯一の例外はオーバーフローが生じるケースである。）この規則は、他の命令が他の方法で実行されるか否かにかかわらず、ＬＳＭの元で実行される他の命令をトレーシングする副次的な効果を有する。しかしながら、定義によりＬＳＭの元で実行される命令はデータ命令となり得ないので、余分なデータパケットは生じない。
・ＬＳＭの命令アドレス上でコンパレータが被動される時は常に、全命令が完了するまで、そのコンパレータのViewData出力はアサートされたままに留まる。ユーザーの意図はこの命令に関連するすべてのデータパケットをトレースすることにあるので、このことが行われる。同様に、ＬＳＭ命令が完了するまでViewDataおよび事象レンジ出力はアサートされた状態に留まる。定義により、１サイクルの間、これら出力はアサートされなければならないので、事象の単一アドレスコンパレータの出力はアサートされた状態に留まらない。
・ＬＳＭに関連するデータ転送を一旦トレースすると、通常トレースされないその命令に関連するその後の転送はプレイスホルダーパケット出力（トレースされない値（第５章参照）を有する。どのワードをトレースしたかを判断するには、これらプレイスホルダーパケットが必要である。
ＥＭプロトコルはロード／記憶データアドレス（およびデータ値）に基づき、命令トレーシングをイネーブルできるようにする。ＡＲＭ１０ではトレーシングイネーブル事象が生じた時にＬＳＭ命令はコア実行ステージ内に存在できないので、この機能をサポートするには特別な方法でこの命令アドレスを周辺に維持または一斉送信する必要がある。このことは、プログレスＴＦＯパケット内のＬＳＭを使って行われる。トレースパケットオフセットについては５．２．４章に記載されている。
【００５７】
１．６    補助データトレーシング
プロトコルにデータヘッダーを加えることによって、補助データタイプのトレーシング（すなわちロード、記憶およびＣＰＲＴ命令に対するデータ以外のデータ値のトレーシング）も可能になる。この補助データタイプのトレーシングとは、ＥＴＭの将来のバージョンにおける外部ＡＳＩＣデータのトレーシングを含み得るＥＴＭトレーシングの拡張を可能にすることを意味する。より詳細な情報については第５章におけるデータヘッダーの説明における補助データトレーシングに述べられている。
【００５８】
１．７    ＣＯＮＴＥＸＴ  ＩＤのトレーシング
ＣＯＮＴＥＸＴ  ＩＤ値を更新する時、および同期化のためにＴＦＯパケットが必要とされる時は常に、ＣＯＮＴＥＸＴ  ＩＤ値を一斉送信する必要がある。ＥＴＭ１０の場合、ＣＯＮＴＥＸＴ  ＩＤ変更を生じさせたＣＰＲＴ命令に対するデータトレーシングを単にイネーブルすることによって、ＣＯＮＴＥＸＴ  ＩＤを更新する際にこれらＣＯＮＴＥＸＴ  ＩＤ値を出力する。このデータパケットに対するユニークなデータヘッダーによって、データが新しいＣＯＮＴＥＸＴＩＤ値をデコンプレッサが認識できるようになる（データヘッダーについては第５章に記載されている）。ＥＴＭはトレースがイネーブルされる時は常に、更に５．２．４章に記載されているトレース同期化サイクル中に、現在のＣＯＮＴＥＸＴ  ＩＤ値も一斉送信する。このＣＯＮＴＥＸＴ  ＩＤ更新命令はＭＣＲ  c15、0、rd、c13、c0、1である。
ＥＴＭ１０は、ＡＲＭ１０とＥＴＭ１０とのインターフェース上の別の３２ビットポートを必要とする以外に、ＣＯＮＴＥＸＴ  ＩＤが内部シャドーレジスタ内の現在ＣＯＮＴＥＸＴ  ＩＤ値を更新し、これを維持することを認識する。コヒーレンシーを正しく維持するためにＥＴＭがＰＯＷＥＲＤＯＷＮモードとなっていても、このレジスタは常に更新される。（ＥＴＭレジスタ０×４、ビット０はアサートされる）。
トレースフィルタリングのためにＣＯＮＴＥＸＴ  ＩＤ値を使用することは、ＥＴＭ１０のための別機能として追加される。このことは、予想されるＣＯＮＴＥＸＴ  ＥＤ値を指定できるＥＴＭ内の新しい組のプログラマブルレジスタを介して実行される。
【００５９】
【表１】
0004038372.tif 000003
【００６０】
各ＣＯＮＴＥＸＴ  ＩＤコンパレータに対して同じマスクを使用し、このマスクはデータコンパレータマスクと同じように働く。
アドレスコンパレータのアクセスタイプのレジスタのビット９：８は、ＣＯＮＴＥＸＴ  ＩＤコンパレータを使用していることを表示する。００の値はＣＯＮＴＥＸＴ  ＩＤコンパレータを無視する。ＣＯＮＴＥＸＴ  ＩＤマスクを考慮した後に、現在のＣＯＮＴＥＸＴ  ＩＤがＣＯＮＴＥＸＴ  ＩＤコンパレータ１、２または３内の値に一致している場合に限り、０１、１０または１１の値はアドレスコンパレータを一致させる。
事象ブロック内から直接ＣＯＮＴＥＸＴ  ＩＤコンパレータにアクセスできるように、新しい事象リソースが割り当てられる（ＡＲＭ  ＩＨＩ  ００１４Ｄの３．３．４章参照）。これら新しいリソースは０×５８〜０×５Ａにマッピングされる。
【００６１】
【表２】
0004038372.tif 000004
【００６２】
存在するＣＯＮＴＥＸＴ  ＩＤコンパレータの数を示すように、ＥＴＭコンフィギュレーションコードレジスタに新しいフィールドが追加される（ＡＲＭ  ＩＨＩ  ００１４Ｄの４．２．２章参照）。
【００６３】
【表３】
0004038372.tif 000005
【００６４】
１．８    トレース出力の周波数
ＡＲＭ１０２０Ｅのマクロセルは、３００ＭＨｚを越えるコア周波数で作動できる。以前のＥＴＭの実現では２００ＭＨｚを越える周波数では使用できなかった。ＥＴＭトレース出力で達成できる最大出力周波数はトレースアナラアイザの最大サンプリング周波数およびパッドで達成できる最大出力周波数によって決まる。アギレント社およびテクトロニクス社のアナライザは、それぞれ３３３ＭＨｚおよび４００ＭＨｚの最大周波数で捕捉できる。しかしながら、ＡＲＭ社のパートナーから得られるＣＭＯＳパッドは、この周波数で、クリーンでトレース可能な信号を発生できる可能性は低い。従って、これらパッドはスピードを制限する要素となると予想される。より大きいパッドを使用し、および／またはボードレベルのバッファリングを使用することによって、ある程度の速度の改良を行うことができる。これら技術によって２００ＭＨｚで信頼できるトレーシングが可能となり得る。これより高い速度でトレーシングするには２つのオプションがある。ピンのカウント数を２倍にし、周波数（多重解除トレースポート）を半分にするか、またはオンチップトレースバッファを使用することができる。いずれの技術も肯定的なポイントと否定的なポイントを有する。
【００６５】
ピンカウントを２倍にすることはパッケージの制限および追加ピンの高コストから一部のパートナーには魅力的なオプション案ではない。この技術では、ＴＰＡを変更することも必要となり、更に最も可能性の高いことに、より広い面積を占め、更にコストを増すような第２のミクターコネクタを増設することも必要となる。更に、この技術では４００ＭＨｚのスピード制限がある。ホットプロセスで製造されたＡＲＭ１０プロセッサはこれらスピードを越える可能性が最も高い。
【００６６】
オンチップバッファのオプションにはコアクロック速度で信頼性高くトレーシングでき、かつ余分なピンを必要としないという利点がある。実際、オンチップバッファを使ってすべてのトレースの捕捉を行う場合、オンチップバッファはＪＴＡＧポートを通してマルチＩＣＥを介し、ダウンロードされるので、外部からビジブルなＥＴＭポートを省略できる。この解決案の欠点は、オンチップバッファのサイズが８〜１６ＫＢのオーダーで極めて小さいということである。従って、トレーシング深度が制限される。より大きいオンチップトレースバッファを使用することも可能であるが、これはＡＳＩＣのサイズに直接影響し、小さいトレースバッファでも一部の設計で可能なスペースよりも大きいシリコンスペースを使用し得る。
【００６７】
各方法の利点と欠点が異なっているので、これまで述べたオプションのいずれも、サポートすることが計画されている。ＡＲＭ１０２００ｒｅｖ  １テストチップは、高速トレーシング用の多重解除トレースポートで製造され、オンチップトレースバッファはＡＲＭ１０２００ｒｅｖ  １テストチップの一部とはならない。
【００６８】
ＥＴＭ９用のオンチップトレースバッファ用の仕様については既に記載されており、その実現は進行中である。５．２章に詳細に記載される新しい４ビットのＰＩＰＥＳＴＡＴコーディングをサポートするために、若干の変更をしたこのデザインからＥＴＭ１０とコンパーチブルなオンチップトレースバッファを作成することが可能となる。ＥＴＭ１０をサポートするのにどのトレースキャプチャーデバイスの変更が必要であるかの情報を更に欲しい場合にはレファレンス４を参照されたい。ＥＴＭ１０とコンパーチブルなオンチップトレースバッファはタイムスケールに応じ、別の機能、例えばダイナミックトレース圧縮機能を提供でき、実際にこのバッファはＦＩＦＯの置換回路としてＥＴＭ１０デザイン内に直接集積化できる。
【００６９】
１．９    同期化レジスタ
先のＥＴＭ実現例では１０２４サイクルごとの５バイト命令アドレスを介し、更に１０２４サイクルごとの５バイトデータアドレスを介し、同期化が生じていた。ＥＴＭ１０では、これら同期化ポイントは新しい１２ビットプログラマブルレジスタによって構成できる。構成可能な同期化によってフルレンジのトレースバッファサイズを使用することがより容易となる。より小さいトレースバッファ、例えばオンチップトレースバッファは、トレースの大きい部分を処分することを防止するように頻繁に同期化できるが、より大きいトレースバッファは必要とされない同期時におけるむだなトレーススループットを防止するのに、あまり頻繁には同期化できない。デフォルトカウンター値は１０２４サイクルとなる。データアドレスの同期化と命令アドレスの同期化とが同時に生じるのを防止するために、カウンターが中間値に達したときにデータアドレス同期化が行われ、カウンターが０に達したときに命令アドレスの同期化が行われる。新同期化レジスタに対するアドレスは０×７８となる。
【００７０】
１．１０    メモリマップデコーダ
以前のＥＴＭ実現例で存在していた外部メモリマップリソース入力はＥＴＭ１０に対してサポートされていない。ＡＲＭ１０のアーキテクチャ内に存在する余分な複雑性によって、外部デコーダの実現はより困難となっている。外部事象はサイクルが完全ＥＸＰＩＮ入力を使用することによってまだトレーシングを制御できる（これについては４．１５章に記載されている）。
【００７１】
１．１１    レンジアウト
以前のＥＴＭ実現例はエキストラトリガーリソースとして埋め込み型ＩＣＥロジック内のデータ値比較レジスタを使用することができた。この機能は埋め込み型ＩＣＥからのＲＡＮＧＥＯＵＴ出力を使用することによって達成されていた。ＡＲＭ１０デバッグユニットはデータ値比較機能を全く有しないので、これらＲＡＮＧＥＯＵＴ出力を有していない。従って、ＥＴＭ１０に対してはこのリソースの再使用は不可能である。これらリソースはもはやプログラムできないので、このことはプログラマーモデルに若干影響する。
【００７２】
１．１２    インターラプトベクトルへのブランチ
現在のプロトコルはインターラプトベクトルテーブル内のエントリーへの直接ブランチを間接ブランチとしてトレースしなければならないと指定している。このことは、ファントムブランチを提案されたプロトコル内で間接ブランチに変換できないので、このことは常に可能であるとは言えない。従って、間接ブランチがブランチファントムであるかどうかとは関係なく、一貫性および簡潔性のためにインターラプトベクトルに対する直接ブランチは間接ブランチとしてトレースされない。５．３．１章に記載されているアドレスバイト５の特別コード化に起因し、ＰＡＢＯＲＴ、ＦＩＱ、ＩＲＱ、ＤＡＢＯＲＴおよびＲＥＳＥＴベクトルに対するブランチを検出することが可能である。
【００７３】
１．１３    プロトコルバージョン
ＥＴＭ７およびＥＴＭ９におけるコンフィギュレーションコードレジスタ（レジスタ０×０１）に存在する４ビットのＥＴＭプロトコルバージョンフィールドは、ＥＴＭに対する将来のプロトコルバージョンをサポートするには不十分であると判断されている。従って、マイナーなプロトコルバージョンナンバーだけでなく、主要なプロトコルバージョンナンバー用のＡＲＭコアを指定するフィールドを含む新しいＥＴＭ  ＩＤレジスタが定義されている。このレジスタはレジスタアドレス０×７９にマッピングされ、コンフィギュレーションレジスタにおけるビット３１がセットされる時は常に有効であると見なされる。これによってＥＴＭ７およびＥＴＭ９はＩＤレジスタを必要とすることなく、プロトコル変形例０〜７をまだ使用することが可能となっている。ＥＴＭ  ＩＤレジスタは次のフィールドに分配された３２ビットの値を含む。
【００７４】
【表４】
0004038372.tif 000006
【００７５】
１．１４    トレーススタート／ストップリソース
TraceEnableスタート／ストップロジックの現在ステートを与えるために、新しい事象リソースが含まれる。このリソースにはリソース番号１０１１１１１が与えられ（ＡＲＭ  ＩＨＩ  ００１４Ｄの３．３．４章参照）、トレーススタート／ストップブロックがアクティブな時は常にアサートされる。このスタート／ストップリソースをサポートするＥＴＭバージョンもＥＴＭ制御レジスタ内のビット２３をアサートする。
【００７６】
１．１５    ＴＰＡの変更
ＡＲＭ１０のための新しいトリガーおよびトレースイネーブルステータス値をサポートするために、すべてのＴＰＡはわずかな変更を必要とする。すなわちこれらＴＰＡはＴＲおよびＴＤ  ＰＩＰＥＳＴＡＴを検出するためにＰＩＰＥＳＴＡＴ［３］／ＴＲＡＣＥＳＹＮＣがＬＯＷとなることを保証しなければならない。ロジックアナライザにとってこのことはわずかなソフトウェア変更にすぎない。アギラント社のnTraceは同じようにわずかなハードウェア変更を必要とする。多重解除された半速度ＥＴＭポートを通した高速トーレシングをサポートするには、ＴＰＡはサイクルごとにトレースデータのうちの２つのコアサイクルの価値を捕捉できなければならない。このデータはミクター社の２つのコネクタを通して一斉送信される。従って、マルチコネクタ用のサポートも同じように必要とされる。これら変更に関して更に情報が欲しい場合には、レファレンス４を参照されたい。
【００７７】
１．１６    正確な事象
ＥＴＭ７およびＥＴＭ９では、イベントブロックを介して発生される事象は正確ではなかった。このことは、事象を発生したデータアクセスまたは命令をトレースするのに、ユーザーは保証されていなかったことを意味する。ＥＴＭ１０はもはやこのようなケースとはなっていない。ViewDataおよびTraceEnableのアサーションはそれらがどのように発生されたかにかかわらず、常に正確である。
【００７８】
１．１７    ＦＩＦＯＦＵＬＬレベルレジスタ
ＥＴＭ７およびＥＴＭ９では、ＦＩＦＯＦＵＬＬがアサートされる前にＦＩＦＯが到達しなければならないレベルを設定するのに、レジスタ０×０Ｂが使用されていた。ＥＴＭ１０では、ＦＩＦＯＦＵＬＬのこのレジスタは使用されず、代わりに新しいパケットをＦＩＦＯＦＵＬＬに挿入しなければならない時は常に、イネーブルされたＦＩＦＯＦＵＬＬがアサートされる。ＥＴＭ１０はＥＴＭ７／９よりもより深いパイプライン状となっており、ＦＩＦＯＦＵＬＬはこのように使用される場合に十分有効となるように早期にしかアサートできない。ＥＴＭ１０ではＦＩＦＯＦＵＬＬレジスタはＦＩＦＯサイズを指定するリードオンリーレジスタとして再使用される。ＦＩＦＯサイズはＥＴＭ７／９ではソフトウェアによって決定できないようなサイズとなっている。
【００７９】
１．１８    ＴＲＩＧＧＥＲ出力
プロセッサがモニタデバッグモードの場合、ＤＢＧＲＱは無視される。従って、トリガーが生じたことをコアが認識できるようにするための他の機構を設けることが有効である。この目的のため、ＥＴＭ１０のためのＥＴＭインターフェースには単一ビットのＴＲＩＧＧＥＲ出力が追加されている。ＰＩＰＥＳＴＡＴバス上で４ビットのＴＲＩＧＧＥＲステータスがドライブされる時は常に、ＴＲＩＧＧＥＲ出力がアサートされる。この信号はインターラプトのアサーションによりコアにトリガーを通知するよう、インターラプトコントローラによって使用できる。このＴＲＩＧＧＥＲ出力が必要でない場合、この出力は付属されない状態のままにすることができる。
【００８０】
１．１９    カウンター事象
ＥＴＭ７／９に対してはカウンター事象レジスタは連続的にカウントするのに使用できるエキストラビット１７を有していた。このビットの動作は冗長であり、証明が困難であるので、このビットは除かれている。ユーザーが連続カウンターを望めば、常にアクティブにすべきハードウェアである外部リソース１５に等しくなるように事象を単にプログラムする。
【００８１】
ＥＴＭ１０のトレースポート
１．２０    ＥＴＭ１０のポート信号
ＥＴＭ１０のトレースポートは２つの信号、すなわちＰＩＰＥＳＴＡＴおよびＴＲＡＣＥＰＫＴとから成る。これらはいずれも（ＧＣＬＫと周波数が同じである）ＴＲＡＣＥＣＬＫの立ち上がりエッジで有効である。ＥＴＭ１０に対してＰＩＰＥＳＴＡＴは３ビット信号から４ビット信号に拡張されており、ブランチファントム用のコーディングスペースを増している。ＴＲＡＣＥＰＫＴは先のＥＴＭバージョンからは変更されていない。すなわちこれはコンフィギュレーションに応じて４、８または１６ビットでよい。別の機構を介して同期化が行われるので、プロトコルからＴＲＡＣＥＳＹＮＣピンが除かれている。全体の結果として、トレースポートは先のＥＴＭ実現例と同じピンカウントを有する。
１．２１    ＰＩＰＥＳＴＡＴエンコーディグ
【００８２】
【表５】
0004038372.tif 000007
【００８３】
１．２１．１    ブランチファントムのＰＩＰＥＳＴＡＴ
次の命令とパラレルに実行されるブランチファントムを考慮して８つの新しいブランチファントムエンコーディングが追加されている。このコーディングは実行ストリーム内の最初に存在するブランチ命令として常に解読すべきである。直接ブランチしか予想されないので、ブランチファントムはＦＩＦＯ内にデータパケットを挿入しない。ミス予想されたフォールドブランチの結果、正常なＩＥ／ＩＭ  ＰＩＰＥＳＴＡＴが生じる。その理由は、パラレルに実行された命令は正しくない命令ストリームからのものであるので、キャンセルされるからである。
【００８４】
１．２１．２    データＰＩＰＥＳＴＡＴ
「Ｄ」で始まるすべてのニューモニックは、ＦＩＦＯサイクル内で一部の種類のデータパケットが挿入され、最終的にＴＲＡＣＥＰＫＴピンに出力されることを意味する。新プロトコルに対する「パケット」なるワードはＦＩＦＯ内の単一バイトではなく、ＦＩＦＯ内に挿入されるマルチバイトの量を意味することに留意されたい。データパケットはブランチアドレス、ロード／記憶転送、ＣＰＲＴ転送または補助データパケットでよい。ＥＴＭ１０は１サイクルでＦＩＦＯ内に最大３つのデータパケット（２つのＬＤＳＴ／ＣＰＲＴ転送および１つのブランチアドレスパケット）を挿入する。１サイクルにおいて、３つのパケットがプロトコルではなくハードウェアの限界であることに留意されたい。プロトコルにパケットヘッダーバイトを加えたことにより、別個のデータおよびブランチＰＩＰＥＳＴＡＴが不要となっている。ＤＷおよびＤＭステータス値を加えたことにより、任意のサイクルにデータパケットを付属させることが可能となっている。この値を加えることは、ＬＤＣ／ＳＴＣの長さを決定するための高プロセッサのマップはもはや不要であり、可変長さのＬＤＣ／ＳＴＣ命令のトレーシングがサポートされることを意味する。パケットヘッダーバイトについては５．３章により詳細に記載する。
【００８５】
１．２１．３    命令ＰＩＰＥＳＴＡＴ
非待機ＰＩＰＥＳＴＡＴ値、すなわち命令が実行されたことを示す値は、その命令が実行されている最初のサイクルで常に与えられる。数サイクルの間で実行し、データをリターンするＬＳＭ命令にとってこの違いは重要である。この動作はＬＳＭを実行した最終サイクルで実行されたＰＩＰＥＳＴＡＴ値を与える以前のプロトコルバージョンと異なっていることに留意されたい。
「実行されない」ＰＩＰＥＳＴＡＴ（ＩＮ／ＤＮ）は２つの理由から起こり得る。命令がその条件コードを実行できなかったか、または例外により命令が実行されなかった場合である。先に述べたように、起こり得る例外としてはインターラプト、プリフェッチアボート、リセットアサーションが挙げられる。データアボートを生じさせるようなロード／記憶命令は実行されたと見なされるので、ＩＮ／ＤＮステータスは与えられない。デコンプレッサは例外が命令の実行を阻止していることを認識しなければならない。この情報は先のＬＳＭ命令からの後のデータパケットが例外命令に付属されるのを防止するために使用される。（「実行されない」ＰＩＰＥＳＴＡＴを有する命令に対して認められる唯一のデータパケットはブランチアドレスである。）
【００８６】
１．２１．４    ＴＤステータスおよびＴＦＯ
ＴＤのステータスはＴＲＡＣＥＰＫＴのこのサイクルでトレースＦＩＦＯデータが存在しないことを意味する。このことが起こる理由は２つある。すなわち
・ＦＩＦＯ内にトレースすべきデータがない場合（ＦＩＦＯが空であれば、ステータスはＷＴとなる）。特に、次にイネーブルされるまでトレースがディスエーブルされた直後にこのことが起こる。
・ＴＦＯがＥＴＭの同期化のために一斉送信されている場合。
【００８７】
ＰＩＰＥＳＴＡＴ上にＴＤステータスが示される時には、圧縮解除ソフトウェアはＴＦＯが一斉送信されたかどうかを判断するためにＴＲＡＣＥＰＫＴ値を見なければならなくなる。先のＥＴＭ実現例で行われているように、サイクルに正確なトレースと非サイクル正確なトレースとを区別するために、ＴＲＡＣＥＰＫＴ［０］が使用される。以前と同じようにＴＲＡＣＥＰＫＴ［０］＝０の場合、トレースキャプチャーデバイスはＴＤサイクルを廃棄できる。ＴＲＡＣＥＰＫＴ［０］がアサートされれば、ＴＦＯを送信するかどうかを指定するためにＴＲＡＣＥＰＫＴ［３：１］が使用される。ＴＦＯが一斉送信されると、ＴＲＡＣＥＰＫＴ［７：４］はＴＦＯ値のうちの下位の４ビットを指定する。ＴＲＡＣＥＰＫＴ［３：１］は下記の表に示されるように、他のＴＦＯ値を指定する。有効なＴＦＯ値のレンジを最大にするよう、ＴＦＯはこのようにコード化される。
【００８８】
【表６】
0004038372.tif 000008
【００８９】
パイプラインステータス（ＰＩＰＥＳＴＡＴ）とＦＩＦＯ出力（ＴＲＡＣＥＰＫＴ）とを同期化するために、トレース情報を逆圧縮する際にＴＦＯ、すなわちTraceＦＩＦＯOffsetを使用する。トレースが最初にイネーブルされる時、更に命令同期化カウンターが０に達する時はいつもＴＦＯを発生する。このＴＦＯは以前のＥＴＭ実現例で使用されたアドレスパケットオフセット（ＡＰＯ）情報を置き換える。ＴＦＯはブランチをカウントする代わりに、現在ＦＩＦＯにあるバイト数をカウントする。このように同期化することにより、プロトコル内のＴＲＡＣＥＳＹＮＣピンが不要となる。更に、ＢＥ  ＰＩＰＥＳＴＡＴによるトレーシングのスタートと、それに続くＡＰＯ値のための２つのデッドサイクルも不要となる。
【００９０】
トレースが既にイネーブルされている間、同期化のためにＴＦＯが一斉送信される時は、ＩＥのＰＩＰＥＳＴＡＴ値が示される。トレーシングを開始するためにＴＦＯが一斉送信される際には、ＰＩＰＥＳＴＡＴは示されず、次のサイクルで最初にトレースされた命令に対するＰＩＰＥＳＴＡＴが与えられる。
次の基準のすべてが満たされる時に、同期化のためのＴＦＯが発生される。
・一般に１０２４に初期化されるサイクルカウンターが０に達すること。
・現在の命令が「ＩＥ」のＰＩＰＥＳＴＡＴ値を有すること。
【００９１】
同期化リクエストが一旦表示されている場合、命令同期化レジスタ（デフォルト値は１０２４である）にどんな値がプログラムされていても、ＴＦＯサイクルカウンターはその間にリセットされ、再びカウントを開始する。最初のリクエストの同期化サービスが完了する前に第２の同期化リクエストがなされた場合、同期化を強制的に生じさせるようにＥＴＭはオーバーフローさせられる。このシナリオでは一部のトレースは失われるが、このことが起きた場合、プロセッサは無限ループ内でスタックする可能性が最も高いので、このことは問題であるとは考えられない。従って、重要なトレースは失われない。同期化カウンターがばかげたほど小さい数にリセットされた場合、このようなケースとはならない。従って、同期化値を小さすぎる値（５０サイクルよりも低い値）にセットすることは軽率なことである。
【００９２】
ＴＦＯサイクルが発生すると、このサイクルでＦＩＦＯにデータのいくつかのバイトが挿入される。このデータはＴＦＯパケットと称され、一般に特殊なヘッダーバイトと、現在のＣＯＮＴＥＸＴ  ＩＤと、フル命令アドレスとから成る。ＴＦＫパケットに対する正しいフォーマットは５．４章に示されている。
【００９３】
４ビットのＴＲＡＣＥＰＫＴコンフィギュレーションにおいて、１バイトのうちの第２のニブルが予想される時にＴＦＯが生じた場合、ＴＦＯ値の直後にＴＲＡＣＥＰＫＴ［３：０］に値「０×６」のエクストラニブルが出力される。ＴＦＯ値はニブルではなく、バイトによって同期化を指定するので、このニブルが必要とされる。このエクストラニブルを出力することによって、ＥＴＭ１０はＴＦＯ値によりポイントされるＦＩＦＯの現在のトップのバイトが一致することを保証する。同期化が必要でないケースでは、このエクストラニブルがＴＲＡＣＥＰＫＴ［３：０］に生じることをデコンプレッサが認識していることが重要である。ＴＦＯが同期化によるものか、またはトレースのイネーブルによるものかは関係なく、奇数のニブルでＴＦＯが発生される時に、デコンプレッサは常にこのイクストラニブルを予想しなければならない。ＴＲＡＣＥＰＫＴ［３：０］で完全なＴＦＯ値（および必要な場合にはエクストラニブル）が出力されるまで、ＦＩＦＯ出力は遅延される。
【００９４】
１．２１．５    トリガーステータス
トリガーステータス（ＴＲ）はこのサイクルに対する実際の４ビットのステータスがＴＲＡＣＥＰＫＴ［３：０］に載せられ、ＦＩＦＯ出力が１サイクルだけ遅延されることを意味する。この動作はＥＴＭ７およびＥＴＭ９と同一である。トリガーとＴＦＯが同時に発生したい場合、ＴＲＡＣＥＰＫＴ［３：０］上のＰＩＰＥＳＴＡＴ値はＴＤとなる。トリガーが生じる時にＷＴ  ＰＩＰＥＳＴＡＴは決してＴＤ  ＰＩＰＥＳＴＡＴに変換されないので、ＴＤは真のＴＦＯとして一義的に識別可能である。４ビットポートのケースでは、ＴＦＯ一斉送信の第２サイクル（またはギャップサイクル）においてトリガーが発生したい場合、トリガーが発生し、エクストラサイクルだけＦＩＦＯ出力が遅延され、残りのＴＦＯニブルを出力する。従って、トリガーは遅延されず、発生時に出力されることが保証される。
【００９５】
１．２２    パケットヘッダーエンコーディング
「Ｄ」エンコーディングを有するＰＩＰＥＳＴＡＴ値により、ＦＩＦＯ内にはパケットが挿入される。単一サイクルにおいてＦＩＦＯ内には３つまでのパケット（２つのデータパケットと１つのブランチアドレスパケット）を挿入できる。下記の表にはパケットヘッダー値に対するエンコーディングが示されている。
【００９６】
【表７】
0004038372.tif 000009
【００９７】
データヘッダー上のＣビットは、単一サイクルでどれだけ多くのパケットがＦＩＦＯに挿入されているかを逆圧縮ツールに伝えるために使用される。このＣビットは最終パケットまで挿入され、最終パケットを含まない各パケットに対してアサートされる。このことは、どのパケットをどのサイクル、従ってどの命令に結び付けなければならないかをデコンプレッサが認識するのに必要である。このＣビットは、より低いケース「ｃ」によって表示されるアドレス連続ビットと混同してはならない。
【００９８】
１．２２．１    ブランチアドレス
ブランチアドレスは以前のＥＴＭ実現例と同じようにコード化される。１つのブランチパケットは１〜５ビットの長さでよく、ｃビットがイネーブルされる時は逆圧縮ツールはより多数のバイトを予想しなければならない。しかしながら、ThumbとＡＲＭステートとを区別するのに、ブランチアドレスのビットゼロはもはや使用されない。代わりに、すべてのブランチアドレスにはプレ圧縮により３３番目のビット位置に１のプレフィックスが付けられる。一旦圧縮されると、すべてのブランチアドレスには０番目のビット位置に１がサフィックスとして付けられる。ビット０における１はブランチアドレスとしてパケットを識別するものであり、ビット３３における１はＡＲＭアドレスとthumbアドレスとを区別するために使用される。ＡＲＭアドレスはワードが一致していなければならないので、ＡＲＭアドレスのうちのビット［３１：２］しか一斉送信されない。Thumbアドレスは半ワード一致しているので、ビット［３１：１」を一斉送信するだけでよい。３３番目のビットの、常にアサートされたプレ圧縮と組み合わせて、ＡＲＭアドレスとThumbアドレスに対し、異なる数のビットを一斉送信することにより、ＡＲＭステートとThumbステートとの間の変化時にフルの５バイトのアドレスが一斉送信されることが保証される。更に、ＡＲＭアドレスおよびThumbアドレスは次の表に示されるように、５番目のアドレスバイトの内の高位ビットによって常に一義的に識別できる。
【００９９】
【表８】
0004038372.tif 000010
【０１００】
ブランチターゲットアドレスが存在する場合、このブランチターゲットアドレスは常に所定のサイクルでＦＩＦＯ内に挿入すべき最終アイテムとなる。従って、パケット連続ビット（Ｃビット）は不要である。理由コードは５．４章で説明するＴＦＯパケットヘッダーの一部として与えられるので、このコードは５番目のバイト内のアドレスビット６：４で一斉送信されることはない。５番目のバイトのうちのビット６は（上記表における「Ｅ」によって表示される）例外ブランチアドレスを表示するのに使用される。このビットはアボート、インターラプトまたはソフトリセットに起因し、任意のブランチ上でセットされる。これらインターラプトされた命令が実際には実行されていないことをデコンプレッサが認識し、ユーザーに表示できるように、このビットは有効となっている。５番目のアドレスバイトのうちのビット７およびビット５は将来使用するために留保されたままになっている。
【０１０１】
１．２２．２    通常のデータ
キャッシュ内でミスしないすべてのロードおよび記憶データパケットに対し、通常のデータヘッダーが使用される。このデータヘッダーはＣＰＲＴデータトレーシングがイネーブルされた場合に、ＣＰＲＴデータパケットに対しても使用される。データアドレストレーシングがイネーブルされた場合、ヘッダーパケットの後であって、データ値（存在する場合）の前でデータアドレスが一斉送信される。このデータアドレスは命令ブランチアドレスと同じ圧縮技術を使って一斉送信されるので、１つ〜５つのバイトから成る。以前のＥＴＭ実現例に当てはまるように、トレーシングが開始される前にデータアドレスがトレースされたかどうかを統計的に判断しなければならない。（６４ビットのデータ転送に起因し）単一サイクルで通常の２つのデータパケットが与えられた場合、最初のパケットしかデータアドレスを含まない。ＬＳＭ命令のためのデータが一斉送信されると、次のデータパケットが別のサイクルで転送されるが、データアドレスは最初のデータパケットと共に一斉送信されるだけである。通常のデータヘッダーにおけるＡビットは、これが特定命令に対する最初のデータパケットであることを指定するのに使用され、従って、（アドレストレーシングがイネーブルされる場合）データアドレスを予想しなければならない。ヘッダーバイト内でこの情報を利用可能にすることにより、逆圧縮できないコード部分（すなわち二進法を利用できない領域）を通るトレーシングを行う際に、デコンプレッサは同期状態を維持できるようになる。このＡビットはＣＰＲＴパケット上ではアサートされない。
【０１０２】
通常のデータコーディングにおける「ＭＳＳ」ビットはデータ値の圧縮に使用される。Ｍビットが低レベルであると、ＳＳビットは転送されるデータ値のサイズを指定する。先行するゼロを簡単な形態のデータ圧縮として値から除く予備的な実験によれば、この圧縮は約２０〜３０％の圧縮を可能にすることが判った。この値はヘッダーバイトの追加的バンド幅コストを相殺するのに十分である。将来の圧縮技術のためにＭビットの組によるコーディングが保留されている。次の表にはＭＳＳビットのための正確なコーディングが示されている。
【０１０３】
【表９】
0004038372.tif 000011
【０１０４】
１．２２．３    ロードミス
ロードミス発生ヘッダータイプおよびロードミスデータヘッダータイプは、データキャッシュ内でミスするロードリクエストを取り扱う。ロードミスが生じると、データ値が予想されるＦＩＦＯ内にロードミス発生パケットが挿入される。データアドレストレーシングがイネーブルされた場合、パケットはデータアドレスを含む。イネーブルされない場合、パケットはロードミス発生ヘッダーバイトから成る。ロードミス発生パケットが読み出されると、逆圧縮ソフトウェアはデータ値が現在未解決のミスであることを認識し、このデータ値は後にリターンされる。データが一旦リターンされると、このタイプに対するＰＩＰＥＳＴＡＴ値は「＋ＤＡＴＡ」バージョンに変更され、ＦＩＦＯ内にロードミスデータヘッダーバイトと実際のデータ値とから成るロードミスデータパケットが挿入される。ロードミスデータパケットはデータアドレスを決して含むことはない。ロード／記憶ユニットはロードミスデータをリターンするための自由サイクルを有していなければならないので、このデータは別のロードリクエストまたは記憶リクエストに対するデータと同じサイクルでリターンされることはない。
【０１０５】
ロードミスヘッダータイプにおける「ＴＴ」ビットは、各ロードミスを識別するためのタグとして使用される。ロードミス発生パケットは常に対応するロードミスデータパケットと同じタグ値を常に有する。ＡＲＭ１０２０Ｅは位置度に１つの未解決のロードミスしかサポートせず、第１ミスに対するデータがリターンされる前に第２のロードミスパケットを一斉送信できる。従って、すべてのロードミスを一義的に識別するために、ＥＴＭ１０ｒｅｖ０ではタグ値２’Ｂｂ００および２’Ｂ０１がサポートされている。これら２つのビットはより多数の未解決のミスを許容できる、将来のプロセッサをサポートするために、タグフィールド内に割り当てられている。更に、ＡＲＭ１０２０Ｅはミスデータを（他のロードミスに対して）順にリターンするが、このタグ付け機構はミスデータを順序外でリターンできる将来のプロセッサをサポートする。
【０１０６】
１６ビットのロード値でミスが生じると、同じサイクルでＦＩＦＯ内に２つのロードミスパケットが挿入される。双方のパケットは同じタグ値を有し、同じサイクル内でＦＩＦＯ内に挿入されるので、デコンプレッサはこれら２つのミスが単一の６４ビット値に対するものであることを認識する。通常のデータパケットに関し、データアドレスは最初のロードミスパケットと共に存在するだけであるので、既にデータパケットを一斉送信したＬＳＭの中間でミスが生じた場合、データアドレスは全く存在しないことになる。６４ビットのケースに対し、ロードミスデータがリターンされると、このロードミスは同じサイクルで与えられた２つの別個のロードミスデータパケットとして常にリターンされる。双方のパケットは同じミスタグを有することになる。
【０１０７】
ロードミスデータパケットは通常のデータに対して行われているのと同じようなデータ圧縮およびサイズ情報に対し、ＭＳＳビットを使用する。デコンプレッサが予想しないロードミスデータパケット（例えば同じタグを有するペンディング中のミス発生パケットを有しないミスデータパケットが与えられる）を受信した場合、デコンプレッサはサイズとして示された所定の数のバイトだけスキップしなければならない。未解決のミスデータがリターンされる前にトレースがディスエーブルされるた場合に、利用できるようになるとすぐに「ＤＷ」ＰＩＰＥＳＴＡＴと共にＦＩＦＯ内にこのデータアイテムが挿入される。オーバーフローまたは脱出したデバッグの理由コードによってトレースがイネーブルされた場合、デコンプレッサはペンディング中のロードミスパケットをキャンセルしなければならない。
【０１０８】
１．２２．４    補助およびフル視覚性データトレーシング
補助およびフル視覚性データヘッダーコーディングは、プロトコルを拡張するために保留されたスロットの組である。プロセッサに対し、内部および外部にある補助データをトレーシングするために、これらパケットタイプを使用することが可能である（フル視覚性とは、すべてのレジスタファイルの更新をトレースすることを意味する）。他のデータパケットと同じように補助データパケットはサイズ情報のためにＳＳビットを使用している。フル視覚性データトレーシングは同じように更に圧縮をするためのＭビットをサポートしている。ＥＴＭ１０ｒｅｖ０ではこれらパケットタイプは使用されない。
【０１０９】
１．２２．５    コンテキストＩＤ
コンテキストＩＤヘッダーバイトはコンテキストＩＤ更新命令、すなわちＭＲＣ  ｃ１５、０、ｒｄ、ｃ１３、ｃ０、１によってコンテキストＩＤが変更される時にしか使用されない。データ値のサイズはＥＴＭ１０の制御レジスタ（レジスタ０×０、ビット［１５：１４］）で指定されたコンテキストＩＤサイズによって統計的に決定される。指定されたバイト数よりも新しい値が大きくても、指定された数のバイトしかトレースされない。サイズが０として指定されている場合、コンテキストＩＤ更新はトレースされない。コンテキストＩＤ更新命令がＭＲＣであっても、コンテキストＩＤ値のトレーシングは他のＣＰＲＴ命令からのトレーシングデータ値から完全に独立している。このコンテキストＩＤ値のトレーシングはＥＴＭ１０の制御レジスタ（レジスタ０×０、ビット［１］）内のモニタＣＰＲＴビットによって影響されることはない。コンテキストＩＤ更新に対し、ユニークなヘッダー値を使用することによって、逆圧縮できないコード領域（すなわち二進法を利用できない領域）を通るトレーシングを行う時でも、デコンプレッサはコンテキストＩＤの変更を認識できる。
【０１１０】
１．２２．６    トレースされない値
先のＥＴＭ実現例はＬＳＭオペレーションのためにデータ値のすべてをトレースできるか、または全くトレースできないかのいずれかであった。この判断は、第１転送時に行われていた。今日のコンパイラーは隣接するＬＤＲ／ＳＴＲオペレーションをユーザーに知られていないＬＳＭへ組み合わせることが多いので、このような動作は望ましくない。値がトレースされていないパケットを加えることによって、ＬＳＭを部分的にトレースし、トリガー基準に正しく一致するデータ値を出力する能力を増していた。
ＬＳＭに関連する第１データ値をトレースする時は常に、（アドレストレーシングがイネーブルされている場合の）データアドレスと、（データ値のトレーシングがイネーブルされている場合の）データ値とを含むＦＩＦＯ内に通常のデータパケットが挿入される。このＬＳＭのためのその後のすべてのデータ転送の結果、ＦＩＦＯ内にパケットが挿入される。その後の値をトレースする場合、データ値だけを与える通常のデータパケットがトレースされる。その後のデータ転送をトレースすべきでない場合、値をトレースしないパケットがこれら転送用のＦＩＦＯ内に挿入される。値がトレースされていないパケットは値がトレースされていないヘッダーバイトのみから成る。逆圧縮ソフトウェアは最終データ転送から後方向に作用することにより、どのＬＳＭ値がトレースされ、どの値がトレースされなかったかを判断するために、通常のデータパケットと組み合わせて値をトレースしなかったパケットを使用することができる。ここで、先に述べたように、ＬＳＭ命令でトレーシングが一旦開始すると、このトレーシングは命令の完了前にTraceEnableがデアサートされていても、ＬＳＭが完了するまで続く。
【０１１１】
１．２２．７    保留
データヘッダーコーディング内には保留されたスロットが総計１０個残っている。これらスロットのすべては、必要とされる場合、および／または将来のＥＴＭ実現例が使用するために、プロトコルを補強するのに利用可能とされる。通常のデータおよびフル視覚性トレースコーディング内のＭビットも、将来のＥＴＭ実現例がより多数のヘッダータイプを必要とする場合でも圧縮の代わりに新しいデータヘッダーコーディングのために使用することもできる。
【０１１２】
１．２３    ＴＦＯパケットヘッダーコーディング
（５．２．４章に記載されている）ＴＦＯサイクルによりＦＩＦＯ内にＴＦＯパケットが挿入される。デコンプレッサはＴＦＯによりＦＩＦＯ内にパケットが挿入されたことを知るので、ＴＦＯパケットは自己のヘッダーバイトコーディングを有する。このコーディングはＰＩＰＥＳＴＡＴデータパケットにより使用されるコーディングスペースから完全に独立している。次の表にはＴＦＯパケットヘッダーコーディングが示されている。
【０１１３】
【表１０】
0004038372.tif 000012
【０１１４】
１．２３．１    命令アドレス
ＴＦＯパケットの第１バイトに対し、ＴＲＡＣＥＰＫＴ［１：０］！＝２’ｂ１０である場合、このＴＦＯパケットは１つの命令アドレスから成る。常にフルアドレスが必要とされるので、圧縮は行われず、４バイト値としてアドレスが常に出力される。アドレスのうちのビット０はこのアドレスがThumbまたはＡＲＭ命令アドレスかどうかを指定する。ＴＦＯパケットが命令アドレスから成る時、このことは次のことを意味する。
・（ContextIDSize、ＥＴＭレジスタビット［１５：１４］によって決定されるように）ＣＯＮＴＥＸＴ  ＩＤ値はトレースされない。
・ＴＦＯの理由コードは２’ｂ００、すなわち通常の同期化である。
理由コードがゼロでないか、またはＣＯＮＴＥＸＴ  ＩＤ値がトレース中である場合、次のＴＦＯパケットのうちの１つが必要とされる。１つのアドレスから成るＴＦＯパケットはプロトコルに合わせるためには厳密に必要ではなく、ＥＴＭ１０ｒｅｖ０では実現されない。
【０１１５】
１．２３．２    通常のＴＦＯパケット
通常のＴＦＯパケットはヘッダーバイトと、それに続くＣＯＮＴＥＸＴ  ＩＤのうちの０〜４バイトおよびそれに続く４バイトの命令アドレスから成る。トレースされるＣＯＮＴＥＸＴ  ＩＤバイトの数はＥＴＭ制御レジスタビット［１５：１４］によって統計的に決定される。命令アドレスは常に４バイトであり、圧縮されない。ビット０はThumbビットを指定する。ＴＦＯヘッダーバイトは（上記表においてＲＲと表示された）２ビットの理由コードを含む。これら理由コードはプロトコルバージョン０および１におけるＥＴＭ７およびＥＴＭ９によって使用されるコードと一貫している。これら理由コードは次の表に示されている。
【０１１６】
【表１１】
0004038372.tif 000013
【０１１７】
１．２３．３    進行ＴＦＯパケット内のＬＳＭ
マルチメモリアクセス命令（ＬＤＭ、ＳＴＭ、ＬＤＣまたはＳＴＣ）の中間でトレースがイネーブルされ、別の命令が現在実行中の時に限り進行パケット内のＬＳＭが生じる。これらパケットはヘッダーバイトと、それに続くＣＯＮＴＥＸＴ  ＩＤのうちの０〜４バイト、それに続くＬＳＭのための４バイトの命令アドレス、それに続く現在実行中の命令のための圧縮されたアドレスの１〜５バイトから成る。ＬＳＭ命令はThumbビットを指定するビット０を有する固定された４バイトアドレスである。現在の命令アドレスは（５．３．１章に指定されているように）ブランチアドレスと同じ技術を使用して圧縮される。最終命令アドレスはＬＳＭ命令からのフルアドレスに対して圧縮される。次の命令ＰＩＰＥＳＴＡＴは第２アドレスによりポイントされる命令のためのものであり、このポイントから前方に通常の方法でトレーシングが開始する。このパケットタイプは特定のデータアドレスまたはデータ値にタッチするすべての命令を正しくトレーシングするのに必要である。これがない場合、ＬＳＭ命令はデータアドレスに基づき正しくトレースすることはできない。ＬＳＭ自体の間でのみトレーシングがターンオンするようにプログラムされていても、ＬＳＭ下で発生する命令はトレースされることに留意されたい。同様に、ＬＳＭの元でたまたま実行される命令の命令アドレスによってトレーシングがターンオンされた場合、進行ＴＦＯパケット内のＬＳＭは出力されたままとなる。通常のＴＦＯパケットと進行ＴＦＯパケット内のＬＳＭとの間の差を更に明瞭にするために、次の表は各ケースに対して予想されるはずのバイトを示している。
【０１１８】
【表１２】
0004038372.tif 000014
【０１１９】
ＡＲＭ１０のＴＲＡＣＥインターフェース
この章では、ＡＲＭ１０２０ＥとＥＴＭ１０との間の信号インターフェースが記載されている。このインターフェースの大部分はＡＲＭ１０２０ＥによってＥＴＭ１０にドライブされる。信号の記述はカスタムデータパス入力と、合成された制御入力と、ＥＴＭ出力とに分割されている。合成制御信号は後に変更できるが、データパス信号の変更はカスタムロジックのリワークを必要とするので、これらは設計において後に変更することはできない。すべての入力信号はＥＴＭ１０内に即座に登録され、すべての出力はレジスタの出力端から直接ドライブされる。インターフェースは合計２２０の信号から成り、これら信号は２１３の入力信号と、ＥＴＭ１０パースペクティブからの４つの出力信号とを含む。
【０１２０】
１．２４    ＥＴＭデータパス入力
ＥＴＭデータトレーシング用に関係するデータバスは４つある。すなわちロードデータバスと、記憶データバスと、ＭＣＲデータバスと、ＭＲＣデータバスとがある。これら４つのすべてのバスは幅が６４ビットである。所定サイクルにおいては、これらバスのうちの１つしか有効データを含むことができないので、４つのすべてのバスはＡＲＭ１０２０Ｅ内では１つの６４ビットデータバス、すなわちＥＴＭＤＡＴＡに多重化されている。ＥＴＭＤＡＴＡはＥＴＭにドライブされる前にＡＲＭ１０２０Ｅ内に登録される。このＥＴＭデータはＡＲＭ１０２０Ｅのパイプラインの書き込み（ＷＲ）ステージにおいて有効である。ＡＲＭ１０２０ＥからＥＴＭ１０へドライブされるアドレスバスは４つある。これらバスのうちの３つは命令アドレス用であり、残りの１つはデータアドレス用である。Ｒ１５バスはＡＲＭ１０２０Ｅパイプラインの実行（ＥＸ）ステージ内でＥＴＭにドライブされるが、一方、ＩＡおよびＤＡアドレスバスはメモリ（ＭＥ）内で有効である。ＥＴＭにドライブされるすべてのデータパスバスは次の表に示されている。
【０１２１】
【表１３】
0004038372.tif 000015
【０１２２】
１．２５    ＥＴＭ制御入力
１．２５．１    ＥＴＭＣＯＲＥＣＴＬ［２３：０］
ＥＴＭＣＯＲＥＣＴＬはすべてＡＲＭ１０のコアから来る種々の制御信号を含む。これら信号はすべてコア内に登録され、ＥＴＭ１０にドライブされる前にこの共通バス上で組み合わされる。これらバス上に存在する制御信号およびそれらの意味は次の表に示されている。特に指定されない限り、ＡＲＭ１０２０Ｅのパイプラインの書き込みステージ（ＷＲ）において、これらのいずれもが有効である。
【０１２３】
【表１４】
0004038372.tif 000016
【０１２４】
１．２５．２    ＥＴＭＤＡＴＡＶＡＬＩＤ［１：１］
この信号はバスＥＴＭＤＡＴＡ［６３：０］でドライブされるデータを評価する。データバスのうちの各半分に対し１つのビットがある。
【０１２５】
１．２６    ＥＴＭ出力
この章では、ＡＲＭ１０２０Ｅにフィードバックされる出力およびＡＲＭ１０２０Ｅから必要とされるものについて記載する。
【０１２６】
１．２６．１    ＦＩＦＯＦＵＬＬ
イネーブル時にＦＩＦＯ内に挿入されたバイトがある時は、ＥＴＭ出力のＦＩＦＯＦＵＬＬがアサートされ、ＦＩＦＯが空になるまでアサートされた状態のままとなる。この動作はＦＩＦＯＦＵＬＬをアサートする前にＦＩＦＯが所定の指定されたレベルに達するまで待機するＥＴＭ７／９と若干異なっている（４．１６章を参照）。ＦＩＦＯＦＵＬＬはコア、本例ではＡＲＭ１０２０Ｅによって使用され、ＡＲＭパイプラインを停止させる。これによってＥＴＭのオーバーフローが防止されるので、コア内で生じる事象のタイミングを若干変更する福次的効果により完全なトレースを保証できる。ここで、タイミング要因によりＦＩＦＯＦＵＬＬのアサーションの結果、ＡＲＭ１０２０Ｅの中間ストールは生じない。従って、稀なことであるが、ＦＩＦＯＦＵＬＬがアサートされていても、オーバーフローが生じる可能性が時々ある。このオーバーフローが生じた時に、ミスした命令の数は少ない。その理由は、ＦＩＦＯが排出中である間、（ＦＩＦＯＦＵＬＬのアサーションに起因し）プロセッサは停止された状態のままとなるからである。
【０１２７】
１．２６．２    ＰＷＲＤＯＷＮ
ＨＩＧＨの時、このことはＥＴＭが現在イネーブルされていないことを示すので、ＣＬＫ入力をストップできる。これはトレースを使用していない時の電力消費量を低減するのに使用される。リセット時にＰＷＲＤＯＷＮはＥＴＭ１０がプログラムされるまでアサートされる。ＡＲＭ１０２００のテストチップはＥＴＭ１０のＣＬＫ入力を直接ゲート制御するのにＰＷＲＤＯＷＮ出力を使用しなければならない。以前指摘したように、ＰＷＲＤＯＷＮはＣＯＮＴＥＸＴ  ＩＤの更新時に一時的にディスエーブルされ、ＥＴＭ１０の内部ＣＯＮＴＥＸＴ  ＩＤシャドーレジスタでの更新を可能にする。ＣＯＮＴＥＸＴ  ＩＤ更新のケースを除き、ＰＷＲＤＯＷＮはＴＣＬＫに同期して変更され、デバッグセッションの開始時にＡＲＭデバッグツールによってクリアされる。ＰＷＲＤＯＷＮはトレースがイネーブルされる前に多くのサイクルを変えるので、ＥＴＭ１０のＣＬＫをゲート制御するのにＴＣＬＫに基づく信号を使用しても準安定性問題を生じさせない。
【０１２８】
１．２６．３    ＤＢＧＲＱ
先のＥＴＭの実現例と同じように、トリガー条件が生じた時は常にＤＢＧＲＱをアサートするよう、ＥＴＭ１０をプログラムすることができる。ＤＢＧＲＱはＤＧＢＡＣＫが発見されるまでアサートされたままである。ＤＢＧＲＱはＡＲＭ１０２０Ｅの外部デバッグリクエストピン、すなわちＥＤＢＧＲＱに接続しなければならない。このＥＴＭ出力に対してはＡＲＭ１０２０Ｅからのエキストラサポートは不要である。ＥＤＢＧＲＱ入力がＡＳＩＣ内の他の、ある機能ブロックによって既に使用されている場合には、多数のＤＢＧＲＱ信号を共にＯＲ演算することができる。このようにデバッグをイネーブリングすることは、任意の特定の命令境界に入るように保証されていないことに留意すべきである。更に、ＡＲＭ１０がそのときにハードウェアデバッグモードとなっていいる場合、コアはＥＤＧＢＲＱを認識するにすぎない。
【０１２９】
１．２６．４    ＴＤＯ
ＥＴＭ１０は先のＥＴＭバージョンと同じＴＡＰインターフェース配線を使用する。ＴＤＯピンはＡＲＭ１０２０Ｅのスキャン拡張入力ＳＤＯＵＴＢＳに接続されており、ＥＴＭ１０のレジスタは先のＥＴＭ実現例と同じように、スキャンチェイン６によってアクセスされ、プログラムされる。このＥＴＭ出力に対してはＡＲＭ１０２０Ｅからのエキストラサポートは不要である。
【０１３０】
コンフィギュレーション
ＥＴＭ７／９は小、中および大コンフィギュレーションで利用できていた。中および大コンフィギュレーションは、別のエリアを代償にして、より多数のトリガーハードウェアリソースおよび大きいＦＩＦＯ深さを提供する。新コンフィギュレーションと共にソフトマクロを単に再合成するだけで、異なるＡＳＩＣアプリケーションに対し、異なるコンフィギュレーションを選択できる。ＥＴＭ１０は同様な範囲のコンフィギュレーションを提供する。次の表は現在ＥＴＭ１０に対して提案されているコンフィギュレーションを示す。ほとんどのトリガーリソースはＥＴＭ７およびＥＴＭ９と同一であるが、例外は、６４ビットコンパレータのサイズが大きくなっていることにより、大コンフィギュレーションにおけるデータコンパレータが８つから４つまで減少していることである。各コンフィギュレーションにおける大きいＦＩＦＯサイズはＡＲＭ１０２０Ｅの、より高い命令スループット（すなわち性能）をサポートする必要があることを示している。各コンフィギュレーションに対するＦＩＦＯサイズは面積の影響および性能のモデル化からのフィードバックに基づき増加できる。ＥＴＭ１０のコンフィギュレーションに対して与えられるゲートカウントはＥＴＭ１０のｒｔｌモデルの初期の合成に基づく推定値である。これら推定されたゲートカウントは最終実現例で得られるカウントと異なる可能性が高い。大きいサイズのＥＴＭ１０はＡＲＭ１０２００テストチップに挿入されるものである。各カテゴリーにおけるＥＴＭ９用のリソースの対応する数は比較のために括弧内に示されている。
【０１３１】
【表１５】
0004038372.tif 000017
【図面の簡単な説明】
【図１】オンチップトレーシング機構を提供するデータ処理システムを略図で示す。
【図２】データをトレーシングする際のデータアクセスミスの問題を略図で示す。
【図３】データアクセスミスを取り扱うための３つの異なるシステムのうちの１つを略図で示す。
【図４】データアクセスミスを取り扱うための３つの異なるシステムのうちの１つを略図で示す。
【図５】データアクセスミスを取り扱うための３つの異なるシステムのうちの１つを略図で示す。
【図６】トレーストリガー機構を示す。
【図７】データアクセスミスに対応するように構成できるトレーストリガー機構の動作量を示す。
【図８】データアクセスミスに対応するように構成できるトレーストリガー機構の動作量を示す。
【図９】トレーシング機構およびマルチワードデータ転送命令をサポートするデータ処理システムを略図で示す。
【図１０】マルチワードデータ転送命令を略図で示す。
【図１１】マルチワードデータ転送命令およびその結果生じるトレースデータストリームにより途中で生じるトレーストリガーポイントを略図で示す。
【図１２】オンチップトレーシングハードウェア内の制御フローを示すフローチャートである。
【図１３】図９〜１２のシステムに従って発生されるトレースデータを分析するためのシステム内で実行できる処理オペレーションを略図で示す。
【符号の説明】
２  データ処理システム
４  集積回路
６  マイクロプロセッサコア
８  キャッシュメモリ
１０  オンチップトレースモジュールコントローラ
１２  オンチップトレースバッファ
１４  外部メモリ
１６  プロセッサコア
１８  外部記憶装置
【図１】
0004038372.tif 000018
【図２】
0004038372.tif 000019
【図３】
0004038372.tif 000020
【図４】
0004038372.tif 000021
【図５】
0004038372.tif 000022
【図６】
0004038372.tif 000023
【図７】
0004038372.tif 000024
【図８】
0004038372.tif 000025
【図９】
0004038372.tif 000026
【図１０】
0004038372.tif 000027
【図１１】
0004038372.tif 000028
【図１２】
0004038372.tif 000029
【図１３】
0004038372.tif 000030