JP3766035B2 - 命令セットの情報を格納するための装置及び方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明はデータ処理装置に関する。特に、本発明は命令セットの情報を格納するデータ処理装置および方法に関する。
【０００２】
【従来の技術】
データ処理装置にはいくつかの異なる命令セットからの処理命令を実行することができる処理回路を設けることができる。処理回路により実施される処理を追跡し続けることが望ましいいくつかの状況があり、このような状況では任意の時点においてどの命令セットが使用されているを識別できることが望ましいことがある。例えば、このような情報は、処理回路のアクティビティ（活動）を追跡することがしばしば望ましい、データ処理システムの開発中に有用である。このようなプロセスをアシストするのに使用することができるツールの例はトレーシングツールである。
【０００３】
データ処理システムのアクティビティを追跡するとシステム内のステップ毎のアクティビティを表わすデータを含むトレースストリームが発生されてシステム開発における非常に有用なツールとなる。しかしながら、より深いく埋め込まれたプロセッサコアへ向かう一般的な動きにより、外部アクセス可能ピンを介してプロセッサの状態を追跡することが一層困難となる。したがって、トレースデータを捕捉して解析するオフチップトレーシング機構だけでなく、増量されたトレーシング機能がオンチップ配置されている。このようなオンチップトレーシング機構の例はＡＲＭ７およびＡＲＭ９プロセッサと関連した英国、キャンブリッジ、ＡＲＭ社から提供される埋込トレースマクロセルである。
【０００４】
このようなトレーシング機構はトレースしたいデータ処理システムのアクティビティを表わすデータのトレースストリームをリアルタイムで作り出す。次に、このトレースストリームを使用してデータ処理システムにより実行される処理命令系列のデバッギングを容易にすることができる。
【０００５】
特定のレジスタ、アドレスまたはデータ値にアクセスしたらトレーシングの開始または停止等のトレーシングおよびデバッギング操作を制御するように働くトリガポイントを取り入れるトレーシングおよびデバッギング機構を提供することが知られている。このような機構はシステムの特定部分または動作のタイプを診断するのに非常に有用である。例として、特定のシステムバグが例外動作に関連しておれば、本当に必要なものが適切な例外処理ベクトルへアクセスした時にトリガーされる例外動作のトレーシングである時に、システムの全操作のトレーシングにより不便なほど大量のデータが作り出される。
【０００６】
新しいシステムの開発時間を短縮することも望ましいがデータ処理システムは複雑さが増すため、データ処理システムの開発中に使用することができるデバッグおよびトレーシングツールおよび機構を改善する必要性がある。
【０００７】
処理回路がいくつかの異なる命令セットのいずれかからの処理命令を実行することができる状況では、トレーシング機構はその命令セット情報も追跡し続けることが望ましい。しかしながら、可能であれば常にトレースする必要があるデータ量を低減することも望ましい。
【０００８】
【発明が解決しようとする課題】
したがって、このような命令セット情報を格納するための効率的な技術を提供することが本発明の目的である。
【０００９】
【課題を解決するための手段】
第１の側面から見て、本発明はデータ処理装置を提供し、前記装置は各処理命令がメモリ内のその処理命令の場所を識別する命令アドレスにより指定される処理命令の複数のセットのいずれかからの処理命令を実行する処理回路であって、異なる命令セット内の処理命令に対する命令アドレス内に異なる命令アドレスビット数を指定する必要がある処理回路と、その命令に対応する命令セットの表示を有する命令アドレスを符号化してｎ−ビット符号化命令アドレスを発生する符号化論理とを含み、符号化論理は指定された命令アドレスビットへビットパターンをプリペンディング（ｐｒｅｐｅｎｄｉｎｇ）することにより指定された命令アドレスビットをｎ−ビットへ拡張するのと等価の計算を実施することにより符号化を実施するようにされており、プリペンドされるビットパターンはその命令に対応する命令セットによって決まる。
【００１０】
本発明に従って、複数の命令セットを処理回路により使用できる状況では、しばしば異なる命令セット内の命令に対して命令アドレス内で異なる命令アドレスビット数を指定する必要があることが知られている。本発明はこれを利用して命令アドレスを有する命令セット情報の効率的な符号化を可能にするものである。
【００１１】
特に、指定された命令アドレスビットへビットパターンをプリペンドすることにより指定された命令アドレスビットをｎ−ビットへ拡張するのと等価の計算を実施することによりｎ−ビット符号化命令アドレスを発生する符号化論理が提供され、プリペンドされるビットパターンはその命令に対応する命令セットによって決まる。
【００１２】
例として、命令アドレスが３２ビットにより指定される状況を考える。第１の命令セットに対して、命令はメモリ内の任意のビット位置で開始することができ、したがって、この命令セットに関連する命令アドレスに対しては３２ビットを全て指定する必要がある。しかしながら、第２の命令セットに対しては、命令はメモリ内の利用できる全ての場所のサブセット、例えば、一つおきのビット位置で開始するよう制約されることがある。同様に、第３の命令セットは命令をメモリ内のどこに、例えば、３ビット位置おきに配置できるかについて異なる制約を受けることがある。このような状況では、第２および第３の命令セット内の命令に対する命令アドレスの最下位１ビット以上が常に同じ値を有し、したがって指定する必要がないことは明らかである。例えば、第２の命令セット内の命令がメモリ内の一つおきのビット位置で開始することができ、第３の命令セット内の命令がメモリ内の３つおきのビット位置で開始することができる場合には、第２の命令セットの命令アドレスに対する最下位ビットは無視することができ、第３の命令セットの命令アドレスに対する最下位２ビットは無視することができることは明らかである。したがって、このような状況では、たとえ標準的に全てが３２ビットアドレスとして表わされる場合であっても、異なる命令セット内の命令アドレスに対して異なる命令アドレスビット数を指定する必要があることは明らかである。
【００１３】
符号化論理の機能を実施することができるいくつかの異なる方法があることがお判りであろう。例えば、符号化される各命令アドレスはその命令が関連する命令セットに応じて適切なビット数だけ右シフトして、指定する必要がある命令アドレスビットだけを分離することができ、異なるビットパターンは適切にシフトされた命令アドレスへプリペンドされてｎ−ビット符号化命令アドレスを形成する。
【００１４】
したがって、命令アドレスが３２−ビットにより指定される前の例を考えると、第１の命令セット内の命令は３２ビット全てを指定する必要があり、第２の命令セット内の命令は３１ビットを指定する必要があり、第３の命令セット内の命令は３０ビットを指定する必要があり、第１の命令セットに関連する命令アドレスは右シフトされず、第２の命令セットに関連する命令アドレスは１ビット右シフトされ、第３の命令セットに関連する命令アドレスは２ビット右シフトされることが判る。次に、符号化された命令アドレスが同じ長さとなるように異なるビットパターンをシフトされた命令アドレスへプリペンドすることができる。符号化命令アドレスの最上位ビット位置内の異なるビットパターンはこれらの命令アドレスが関連する命令セットに関する情報を暗黙的に提供する。
【００１５】
命令セットに応じてプリペンドされる異なるビットパターン間の対応性は必要ないことが判る。しかしながら、好ましい実施例では、各命令セットに対してその命令セットからの命令アドレスの指定された命令アドレスビットへプリペンドされたビットパターンは、シフトされたパターンにより異なる命令セットの命令アドレスの指定された命令アドレスビットへプリペンドされたビットパターンと関連づけられる。例えば、３つの命令セットの前例を考えると、ビットパターン“１”を第１の命令セットの命令アドレスへ加えることができ、ビットパターン“０１”を第２の命令セットの命令アドレスへ加えることができ、ビットパターン“００１”を第３の命令セットの命令アドレスへ加えることができる。
【００１６】
前記した符号化命令アドレスを発生するのと等価の任意の計算を使用できることは明らかである。例えば、予め定められたビットパターンを指定された命令アドレスビットへプリペンドして中間値を形成することができ、次にｎビットが中間値から符号化命令アドレスとして選択される。符号化命令アドレスを形成するｎビットを選択することができるいくつかの異なる方法があることは明らかである。例えば、関連する命令セット（すなわち、指定する必要があるビットだけでなく、全アドレスビットが含まれる）に無関係に、全命令アドレスが中間値内で同じビット数で表わされる場合、命令アドレスが関連する命令セットに応じてｎビットの異なる選択が行われる。例えば、前の例を考えると、命令アドレスが第３の命令セットに関連し最下位２ビットは無関係である場合には、符号化命令アドレスとして選択されるｎ−ビットの最下位ビットはビット位置２である。また、中間値を発生する時に指定する必要がある命令アドレスビットしか使用されない場合には、命令アドレスがどの命令に関連するかに無関係に、符号化された命令アドレスは常に中間値の最下位ｎビットを選択することにより形成されることは明らかである。
【００１７】
前記したように、本発明の好ましい実施例は命令アドレスを有する命令セット情報を符号化するための必要な効率的な技術、したがって、命令アドレスを有する命令セット情報を追跡することが望ましい任意のインプリメンテーションにおいて有益な技術を提供する。可能であれば常に追跡されるデータの量を低減する一般的な要望があれば、本発明により発生される符号化命令アドレスをより効率的に表わす技術を提供するのが有益である。
【００１８】
したがって、好ましい実施例では、本装置はさらにその符号化命令アドレスを複数のｘ−ビットセクションへ分割し、各ｘ−ビットセクションを先行する符号化命令アドレスの対応するｘ−ビットセクションと比較し、先行する符号化命令アドレスの対応するｘ−ビットセクションとは異なる最上位ｘ−ビットセクションを圧縮符号化命令アドレスとして、任意のより下位のｘ−ビットセクションと共に、出力するのと等価の計算を実施することにより前記符号化命令アドレスを圧縮する圧縮論理を含んでいる。好ましい実施例では、最下位ｘ−ビットセクションは常に出力される。
【００１９】
しばしば任意の特定の命令アドレスは前の命令アドレスと僅かしか違わず、したがって、命令アドレスの最上位数ビットはしばしば同一であるため、典型的にそれにより符号化命令アドレスの著しい圧縮が行われる。本発明に従って、符号化命令アドレスの最上位ビットは使用される命令セットを暗黙的に識別するが、それはかなり不規則的に変化するため、前記した圧縮技術により多くの符号化命令アドレスを著しく圧縮できることが判る。
【００２０】
さらに、符号化命令アドレスが発生される方法により、任意の無関係なアドレスビットが廃棄されていることがあり、したがって、これは指定する必要がある命令アドレスビットが命令アドレス内に与えられた総命令アドレスビット数よりも少ない命令セットに関連する任意の命令アドレスに対する圧縮効率を改善するのを助けることが判る。前の例に戻って、命令セット３からの命令アドレスが３０ビットしか指定する必要がなければ、命令アドレスの最下位２ビットは圧縮が適用される前に省かれ、したがって、これは圧縮技術の効率を高めるのを助けることが判る。
【００２１】
前記した圧縮技術の潜在的な一つの問題点は各圧縮符号化命令アドレスがいつ開始および終了するかを決定することであり、それは各圧縮された符号化命令アドレスを形成するｘ−ビットセクション数は、圧縮される特定の符号化命令アドレスの先行する符号化命令アドレスと類似する程度に応じて変動するためである。
【００２２】
この潜在的問題を解決するために、好ましい実施例では、圧縮論理はそこから出力される各ｘ−ビットセクションにそれが圧縮符号化命令アドレスとして出力される最後のｘ−ビットセクションであるかを示すフラグを関連付けるようにされている。好ましい実施例では、圧縮論理から複数のｘ−ビットセクションが出力される場合には、複数のｘ−ビットセクションは最下位ｘ−ビットセクションで開始して逐次出力される。
【００２３】
どのフラグがどのｘ−ビットセクションに関連するかを決定できるかぎり、フラグは各ｘ−ビットセクションへ別々の信号として出力できることが判る。しかしながら、好ましい実施例では、圧縮論理はさらにそこから出力される各ｘ−ビットセクションをｙビットへ拡張するようにされており、最上位ｙ−ｘビットはフラグを含んでいる。したがって、このような好ましい実施例では、圧縮論理からの出力は最上位ｙ−ｘビットがフラグを含むｙ−ビットセクション系列であるように、フラグは実際上各出力セクション内に含まれる。
【００２４】
任意数のビットを使用してフラグを指定できることがお判りであろう。しかしながら、好ましい実施例では、フラグは単一ビットである。特に、好ましい実施例では、圧縮符号化命令アドレスはそのセクションが圧縮符号化命令アドレスの最後のセクションであるかどうかを最上位ビットが識別する８−ビットセクション系列を含むようにｙは８でありｘは７である。
【００２５】
符号化論理はさまざまな形式をとることができることが判る。例えば、前記したように、それは命令セットの表示に応答して適切な右シフトを確認し、もしあれば、それを各入力命令アドレスへ適用するシフト論理を含むことができる。次に、予め定められたビットパターンを適切にシフトされた命令アドレスへプリペンドすることができ、その後最下位ｎ−ビットが符号化命令アドレスとして出力される。命令セットに応じて適用される異なる右シフトが与えられると、命令アドレスが関連する命令セットに応じて、符号化命令アドレスの最上位ビット位置に異なるビットパターンが存在することが判る。
【００２６】
しかしながら、好ましい実施例では、符号化論理は中間値および中間値内に含まれる命令アドレスに関連する命令セットを識別する識別子信号を受信するｎ−ビットセクター論理を含み、ｎ−ビットセクターは識別子信号に応じて中間値の予め定められたｎ−ビットを出力するようにされている。このような実施例では、中間値は命令アドレスに対していかなる右シフトも実施することなく発生され、中間値からのｎ−ビットの適切な選択は識別子信号に応じてなされることが考えられる。このようなプロセスにより、個別命令アドレスの適切な右シフトを実施し続いて最下位ｎ−ビットを出力して発生されるのと同じ符号化命令アドレスが発生されることが判る。
【００２７】
好ましい実施例では、圧縮論理は複数の比較器を含み、各比較器が符号化命令アドレスの対応するｘ−ビットセクションを受信するようにされており、さらに先行する符号化命令アドレスの対応するｘ−ビットセクションを格納するための一時記憶装置を含み、比較器は２つのｘ−ビットセクションを比較してそれらが異なる場合にセットされる差信号を発生するようにされている。好ましい実施例では、一時記憶装置はレジスタの形状をとり、レジスタは現在ｘ−ビットセクションを格納するのにも使用される。次に、２つのレジスタからの出力は適切な差信号を発生するために比較される。
【００２８】
さらに、好ましい実施例では、比較論理は圧縮論理から出力される各ｘ−ビットセクションに対して複数の比較器により発生される差信号の予め定められた組合せに基づくフラグを発生するようにされたフラグ発生器論理を含み、より上位のｘ−ビットセクションも出力される場合には特定のｘ−ビットセクションに対するフラグがセットされるようにされる。したがって、このような実施例では、フラグはもう一つのｘ−ビットセクションがそのｘ−ビットセクションに続くことを示すようにセットされ、対応するｘ−ビットセクションが圧縮符号化命令アドレスとして出力される最後のセクションであればフラグはセットされないままとされる。フラグ発生器論理は論理ゲートの任意適切な配線により形成できることをお判り願いたい。しかしながら、好ましい実施例では、対応する差信号またはより上位のｘ−ビットセクションの差信号がセットされる場合に特定のｘ−ビットセクションに対するフラグがセットされるのを保証するのにＯＲゲート列が使用される。
【００２９】
好ましくは、さらに、比較論理は出力される各ｘ−ビットセクションにその対応するフラグをプリペンドすることにより圧縮符号化命令アドレスを発生し、出力圧縮符号化命令アドレスとしてｙ−ビットセクション系列を発生する出力発生器を含んでいる。出力発生器はさまざまな方法で構成できることがお判りであろう。しかしながら、好ましい実施例では、出力発生器の機能はフラグ発生器論理および対応するｘ−ビットセクションにより発生されるフラグの適切なハードワイヤリングにより直接実施される。
【００３０】
本発明の前記した符号化論理および圧縮論理は命令アドレスを有する命令セット情報を追跡したい任意のインプリメンテーションにおいて有益に利用できることがお判りであろう。しかしながら、好ましい実施例では、符号化論理および圧縮論理は処理回路のアクティビティを追跡するのに使用されるトレースモジュール内に設けられる。
【００３１】
したがって、本発明の第２の側面に従って、データ処理装置用トレーシングツールが提供され、データ処理装置は処理命令の複数の命令セットのいずれかからの処理命令を実行する処理回路を有し、各処理命令はメモリ内のその処理命令の場所を識別する命令アドレスにより指定され、異なる命令セット内の処理命令に対して命令アドレス内に異なる命令アドレスビット数を指定する必要があり、トレーシングツールはその命令に対応する命令セットの表示を有する命令アドレスを符号化してｘ−ビット符号化命令アドレスを発生する符号化論理を含み、符号化論理はビットパターンを指定された命令アドレスビットへプリペンドすることにより指定された命令アドレスビットをｘ−ビットへ拡張するのと等価の計算を実施することにより符号化を実施するようにされており、プリペンドされるビットパターンはその命令に対応する命令セットによって決まる。
【００３２】
好ましい実施例では、トレーシングツールは、さらに、符号化命令アドレスを複数のｘ−ビットセクションへ分割し、各ｘ−ビットセクションを先行する符号化命令アドレスの対応するｘ−ビットセクションと比較し、圧縮符号化命令アドレスとして先行する符号化命令アドレスの対応するｘ−ビットセクションとは異なる最上位ｘ−ビットセクションを、任意のより下位のｘ−ビットセクションと共に、出力するのと等価の計算を実施することにより符号化命令アドレスを圧縮する圧縮論理を含んでいる。
【００３３】
第３の側面から見て、本発明は命令セット情報を格納する方法を提供し、処理回路が処理命令の複数の命令セットのいずれかからの処理命令を実行するようにされており、各処理命令はメモリ内のその処理命令の場所を識別する命令アドレスにより指定され、異なる命令セット内の処理命令に対して命令アドレス内に異なる命令アドレスビット数を指定する必要があり、前記方法はビットパターンを指定された命令アドレスビットへプリペンドすることにより指定された命令アドレスビットをｎ−ビットへ拡張するのと等価の計算を実施することにより、その命令に対応する命令セットの表示を有する命令アドレスを符号化してｎ−ビット符号化命令アドレスを発生するステップを含み、プリペンドされるビットパターンはその命令に対応する命令セットによって決まる。
【００３４】
本発明の好ましい実施例では、前記方法は、さらに、（ａ）符号化命令アドレスを複数のｘ−ビットセクションへ分割し、（ｂ）各ｘ−ビットセクションを先行する符号化命令アドレスの対応するｘ−ビットセクションと比較し、（ｃ）圧縮符号化命令アドレスとして先行する符号化命令アドレスの対応するｘ−ビットセクションとは異なる最上位ｘ−ビットセクションを、任意のより下位のｘ−ビットセクションと共に、出力するのと等価の計算を実施することにより前記符号化命令アドレスを圧縮するステップを含んでいる。
【００３５】
本発明は（ｉ）圧縮符号化命令アドレスを形成するｘ−ビットセクション数を決定し、（ｉｉ）先行する符号化命令アドレスの対応するｘ−ビットセクションから得られる追加ｘ−ビットセクションを取り入れることにより、必要に応じて、圧縮符号化命令アドレスをｎ−ビットへ拡張して符号化命令アドレスを作り出すのと等価の計算を実施することにより、本発明の第３の側面の方法に従って発生される圧縮符号化命令アドレスを伸張する方法にも関連している。
【００３６】
好ましい実施例では、前記方法は、さらに、予め定められたビットパターンから命令アドレスが関連する命令セットを決定し、予め定められたビットパターンを除去して指定された命令アドレスビットを得るのと等価の計算を実施することにより符号化命令アドレスを復号するステップを含んでいる。
【００３７】
第４の側面から見て、本発明はその第３の側面の方法に従って装置を制御するコンピュータプログラムを備えたコンピュータプログラムプロダクトを提供する。
【００３８】
【発明の実施の形態】
本発明の好ましい実施例を記述する目的で、オンチップトレーシング技術、およびトレースされる命令アドレスを有する命令セット情報のトレーシングについて説明する。
【００３９】
図１はオンチップトレーシング機構を提供するデータ処理システム２を略示している。集積回路４はマイクロプロセッサコア６、キャッシュメモリ８、オンチップトレースモジュールコントローラ１０およびオンチップトレースバァッファ１２を含んでいる。集積回路４はキャッシュメモリ８内でキャッシュミスが生じる時にアクセスされる外部メモリ１４に接続されている。汎用コンピュータ１６がオンチップトレースモジュールコントローラ１０およびオンチップトレースバァッファ１２に接続され、汎用コンピュータ１６で実行するソフトウェアを使用してこれらの要素からのトレーシングデータのストリームを回復および解析するように働く。
【００４０】
しばしば、プロセッサコア６は動作中に外部メモリ１４内に実際に存在するスペースよりも多くのデータ処理命令およびデータにアクセスすることが必要となることがある。例えば、外部メモリ１４は１ＭＢのサイズを有することができるが、プロセッサコア６は典型的に３２−ビットアドレスを指定することができ、そのため４ＧＢの命令およびデータを指定することができる。したがって、プロセッサコア６により必要とされる全命令およびデータが外部記憶装置１８、例えばハードディスク、内に格納され、プロセッサコア６が特定の動作状態で動作する時にその動作状態に対する関連する命令およびデータが外部メモリ１４内へロードされる。
【００４１】
図２は図１のオンチップトレースモジュール内に設けられるコンポーネントをより詳細に示すブロック図である。オンチップトレースモジュール１０はプロセッサコア６により実施される処理を示すオーバーパス１０５データを受信するようにされている。図１に関して、これはコアから直接受信される追加コントロールタイプデータ（例えば、命令アドレスがインデクスされている表示、ある命令がある理由によりその条件コードに失敗した表示、等）と共に、コア６、キャッシュ８、およびオンチップトレースモジュール１０を接続するバスから受信することができる。
【００４２】
同期論理１００が着信信号をオンチップトレースモジュール内で使用するのにより適切な信号の内部バージョンへ変換するようにされている。次に、これらの内部バージョンはトリガー１１０および制御論理１２０へ送られるが、トリガー１１０および制御論理１２０は必ずしも同じ信号を受信する必要はないことがお判りであろう。基本的に、トリガー１１０はトリガー可能なイベント、例えば、命令アドレス、データ値、レジスタアクセス、等に関連するデータを受信する必要がある。制御論理１２０はトリガー１１０により発せられるイネーブル信号に応じてトレースする必要がある任意のデータを受信する必要がある。制御論理１２０は、さらに、汎用コンピュータ１６からパス１２５を介して構成情報を受信するようにされており、次に、トリガー論理構成をセットアップするために、パス１１５を介してトリガー１１０へ信号を発するようにされている。
【００４３】
トレースストリームの発生を来たさなければならないイベントを検出する時は常に、トリガー１１０はパス１３５を介して制御論理１２０へイネーブル信号を送ってトレースをターンオンオフさせる。制御論理はパス１４５を介して必要なトレースデータをトレースバァッファへ出力することにより反応する。パス１３５を介して多様なイネーブル信号を提供してトレースすべき信号のタイプ、例えば、トレースオンリー命令、トレース命令およびデータ等を識別できることが判る。
【００４４】
好ましい実施例では、オンチップトレースモジュール１０の制御論理１２０には命令アドレスを有する命令セット情報を符号化し、次にこのような符号化命令アドレスをパス１４５を介してトレースバァッファへ出力する前に圧縮できるようにする追加論理が提供される。
【００４５】
制御論理１２０内で実施される符号化が図３に略示されており、プロセッサコア６により使用される３つの異なる命令セットは“ＡＲＭ”，“Ｔｈｕｍｂ”および“Ｊａｖａ（登録商標）”の名称で識別されている。本発明の好ましい実施例では、命令アドレスは３２ビット長である。Ｊａｖａ命令はメモリ内の任意のアドレス位置で開始することができ、したがって、３２ビット全てをＪａｖａ命令アドレス２２０内で指定する必要がある。しかしながら、Ｔｈｕｍｂ命令はメモリ内の偶アドレス位置、例えば、位置０，位置２，位置４，位置６，等でしか開始することができない。したがって、３２ビットＴｈｕｍｂ命令アドレス２１０内のビット位置０は常にゼロである。
【００４６】
同様に、ＡＲＭ命令はメモリ内の３つおきのアドレス位置、例えば、位置０，位置４，位置８，位置Ｃ，等でしか開始することができない。したがって、３２ビットＡＲＭ命令アドレス２００の最下位２ビットは常にゼロである。
【００４７】
本発明の実施例では、論理１値は各命令アドレスの第３３ビットとしてプリペンド（ｐｒｅ−ｐｅｎｄｅｄ）される（すなわち、ビット位置３２に配置される）。次に、命令アドレスの任意の無関係な最下位ビットを除去するための適切な右シフトを適用することにより符号化命令アドレスが作り出される。Ｊａｖａ命令に対しては、３２ビット全てを指定する必要があるため、右シフトは実施されず、符号化命令アドレス２５０は論理１値をオリジナル３２ビットＪａｖａ命令アドレス２２０へプリペンドして与えられる単なる３３ビット値である。Ｔｈｕｍｂ命令に対しては、最下位ビットを除去するために１の右シフトが適用され、それにより最上位２ビットが“０１”である３３ビット符号化命令アドレス２４０が作り出される。最後に、ＡＲＭ命令に対しては、最下位２ビットを除去するために２ビット位置の右シフトが適用され、それにより最上位３ビットが“００１”である３３ビット符号化命令アドレス２３０が作り出される。
【００４８】
したがって、命令アドレスが関連する命令セットの表示が３３ビット符号化命令アドレスの最上位３ビットにより与えられることがお判りであろう。特に、最上位３ビットの“００１”は命令をＡＲＭ命令として識別し、“０１ｘ”は命令をＴｈｕｍｂ命令として識別し（ｘは任意値を示す）、最上位３ビットとしての“１ｘｘ”は命令をＪａｖａ命令として識別する。
【００４９】
好ましい実施例では、３３−ビット符号化命令アドレスはパス１４５を介してトレースバァッファへ出力される前に、図４に略示された技術を使用して、圧縮される。
【００５０】
図４に示すように、３３−ビット符号化命令アドレス３００（図３に示す符号化命令アドレス２３０，２４０，２５０のいずれかとすることができる）は７−ビットセクションへ分割され、最上位５ビットは２つの論理ゼロ値を５ビットへプリペンドすることにより７−ビットセクションへ拡張されている。圧縮符号化命令アドレスとして出力される各７−ビットセクションは対応する７−ビットセクションが圧縮符号化命令アドレスとして出力される最後の７−ビットセクションであるかどうかを示すフラグをプリペンドすることによりバイト（すなわち、８ビット）へ拡張される。好ましい実施例では、フラグは連続ビットの形状をとり、それは論理１値にセットされてもう一つのセクションが出力されることを示し、論理０値にセットされて対応するセクションが圧縮符号化命令アドレスの最後のセクションであることを示す。
【００５１】
任意特定の７−ビットセクションを圧縮符号化命令アドレスの一部として出力しなければならないかを判断するために、その７−ビットセクションは先行する符号化命令アドレス、典型的にはすぐ前を先行する符号化命令アドレス、の対応する７−ビットセクションと比較されて先行する７−ビットセクションと異なるかどうかが確認される。異なる場合には、それは圧縮符号化命令アドレスの一部として出力され、対応する連続ビットは１にセットされ、先行する７−ビットセクションと同一であれば、先行する符号化命令アドレスの対応するセクションとは異なるより上位の７−ビットセクションがある場合しか出力されない。その唯一の例外は最下位ビットに関連する最初の７−ビットセクションであり、それは常に出力される。
【００５２】
図４から、命令セット間にスイッチがある場合に生じるように、符号化命令アドレスが先行するそれと完全に異なる場合には、圧縮符号化命令アドレスは実際上オリジナル符号化命令アドレスよりも多くのビットを使う。特に、図４について、５つのセクション３１０，３２０，３３０，３４０，３５０を出力する必要がある場合には、圧縮符号化命令アドレスに対して４０ビットが必要であることが判る。それにもかかわらず、命令セット間のスイッチは典型的には比較的まれに生じ、命令アドレスはしばしばすぐ前を先行する命令アドレスに極めて類似しており、したがって大概の符号化命令アドレスは図４に示す圧縮技術を使用する結果著しく圧縮することができる。
【００５３】
次に、図４のセクション３５０を見ると、そのセクション内のビット列は命令セットを暗黙的に識別することが判る。特に、列３６０はＡＲＭ命令セットを識別し、列３７０はＴｈｕｍｂ命令セットを識別し、列３８０はＪａｖａ命令セットを識別する。
【００５４】
図５は３つの命令４００，４１０，４２０の代表的な系列であり、本発明の好ましい実施例に従って作り出される圧縮符号化命令アドレスを示す。命令アドレス４００はＡＲＭ命令に関連しており、１６進記法で書かれる。図３に関して、符号化の結果最下位の２つの“０”ビットが除去され、パターン“００１”が最上位の３ビットとして加えられることが判る。このような符号化命令アドレスに圧縮技術が適用されると、圧縮符号化命令アドレス４３０が生じる。図５の例では、次の命令４１０はＴｈｕｍｂ命令であり、したがって最下位の“０”ビットが除去され、パターン“０１”が圧縮の前に最上位の２ビットとして加えられる。次に、圧縮技術を適用する結果として圧縮符号化命令アドレス４４０が発生される。この段階において、命令セットに関する情報は命令アドレスにより効率的に符号化されているが、１つのＡＲＭ命令に１つのＴｈｕｍｂ命令が続くため、圧縮プロセスはなんら節減されていない。
【００５５】
しかしながら、次の命令がＴｈｕｍｂ命令４２０であれば、圧縮符号化命令アドレス４５０が作り出される。したがって、その３２−ビット命令アドレスはその命令セットに関する情報と共に２バイト、すなわち１６ビット、により表現され、これはトレースバァッファ内に格納する命令アドレスおよび命令セットの両方を発生するための非常に効率的な方法を表わしている。命令アドレス４２０に続く任意のＴｈｕｍｂ命令アドレスに対しても著しく圧縮される見込みがあることが判る。
【００５６】
図６は所要の符号化および圧縮を行う本発明の好ましい実施例に従ったオンチップトレースモジュール１０の制御論理１２０内に設けることができる論理のブロック図である。レジスタ６１０が設けられその最上位３ビット６０７は予め定められたビットパターン、好ましい実施例では“００１”、を格納する。レジスタ６１０の最下位３２ビットはパス６０２を介して３２−ビット命令アドレス６０５を受信する。さらに、パス６０３を介して通されレジスタ６１０内に格納された３２−ビット命令アドレスが関連する命令を識別する命令セット識別子を格納するラッチ６３０が設けられる。
【００５７】
３３−ビットセクター論理６２０がレジスタ６１０の内容およびラッチ６３０の出力を受信し、命令セット識別子に応じてレジスタ６１０内の３５−ビットから予め定められた３３−ビット列を選択するようにされる。３３−ビットセクター論理６２０の一例を図７に示す。
【００５８】
図７から判るように、３３−ビットセクター６２０は好ましくは３つの別々の入力７０１，７０２，７０３を受信するマルチプレクサ７００を含んでいる。入力７０１はレジスタ６１０から最上位の３３ビットを受信し、入力７０２は１−３３ビットを受信し、入力７０３は最下位の３３ビットを受信する。マルチプレクサ７００は命令セット識別子の値に応じてその３３−ビット入力の一つをパス７１０上に出力する。特に、命令セット識別子が命令はＡＲＭ命令であると識別する場合には、マルチプレクサ７００はパス７０１を介して受信した入力を出力し、命令セット識別子が命令はＴｈｕｍｂ命令であると識別する場合には、マルチプレクサ７００はパス７０２を介して受信した入力を出力し、命令セット識別子が命令はＪａｖａ命令であると識別する場合には、マルチプレクサ７００はパス７０３を介して受信した入力をパス７１０を介して出力する。
【００５９】
図６に戻って、パス７１０を介して出力された３３−ビット値は５つの異なるセクションへ分割されることが判る。好ましい実施例では、これは３３−ビット幅バス７１０を単に４つの７−ビット幅バス６２２，６２３，６２４および６２５と１つの５−ビット幅バス６２６へ分割して行われる。マルチプレクサ７００からの出力の最下位７ビットは、最下位７ビットは常に出力されるため、直接圧縮符号化命令アドレス発生器へ通される。次の最下位７ビットはパス６２３を介して比較器６７０へ通され、その次の最下位７ビットはパス６２４を介して比較器６６０へ通され、さらにその次の最下位７ビットはパス６２５を介して比較器６５０へ通され、最上位５ビットパス６２６を介して比較器６４０へ通される。
【００６０】
各比較器の構造を図８に略示する。図８に示す比較器は７−ビット数を処理するようにされており、したがって比較器６５０，６６０および６７０用に使用される。比較器６４０は構造的に図８の比較器に類似しているが、７ビット数ではなく５ビット数を処理する。
【００６１】
新しい７−ビットセクションは比較器により受信されると、レジスタ８００内に一時的に格納される。次に、それは比較器論理８３０へ出力される。この時、比較器論理８３０もすぐ前を先行するトレースされた命令アドレスの対応する７−ビットセクションをレジスタ８２０から受信するようにされる。比較器８３０は２つの７−ビット値が同一であるかどうか比較し、同一であれば比較器論理８３０は差信号として論理０値を発生する。そうでなければ、比較器論理８３０は差信号として現在の７−ビットセクションが前の７−ビットセクションとは異なることを示す論理１値を発生する。次の７−ビットセクションが受信されると、それはレジスタ８００内に格納され、レジスタ８００の前の内容は次のプロセスで使用するためにレジスタ８２０へ通される。
【００６２】
図６に戻って、４つの比較器６４０，６５０，６６０および６７０により作り出される異なる信号の各々が、圧縮符号化命令アドレスの一部として出力される各セクションに関連づけられる連続ビットを発生するのに使用される連続ビット発生器６８０へ通される。連続ビット発生器６８０を形成するのに使用することができる論理の例が図９に示されている。
【００６３】
図９から判るように、この論理は基本的に３３−ビット符号化命令アドレスのより上位セクションに関連する差信号を処理している任意他のＯＲゲートからの出力と共に対応する差信号を受信するようにされた一連のＯＲゲート９１０，９２０および９３０を含んでいる。したがって、比較器６４０からパス６８６を介して発せられる差信号はパス９５０を介して直接出力され、パス６２５を介した３３−ビットセクター６２０からの７−ビットセクション出力に対する連続ビットを形成する。パス６２６を介して３３−ビットセクター６２０から出力される最上位セクション出力に対する連続ビットは常に論理０値であり、それはそのセクションが常に圧縮符号化命令アドレスが出力される場合の最後のセクションであるためである。したがって、パス９４０は論理０へハードワイヤされてそのセクションに対する連続ビットを提供する。
【００６４】
ＯＲゲート９３０はパス６８５および６８６を介して差信号を受信するようにされており、パス６８５または６８６上の差信号が論理１値であればパス９６０を介して論理１値を有する連続ビットを発生する。パス９６０を介したこの連続ビットはパス６２４を介して３３−ビットセクター６２０により出力される７−ビットセクションを修飾する（ｑｕａｌｉｆｙ）のに使用される。
【００６５】
ＯＲゲート９２０および９１０は似た働きをし、その対応する差信号がセットされるかまたは符号化命令アドレスの任意のより上位のセクションで実施される比較に関連する差信号がセットされる場合に、対応する連続ビットが論理１値にセットされることを保証する。パス９７０を介して出力される連続ビットはパス６２３を介して出力される７−ビットセクションと一緒に使用され、パス９８０を介して出力される連続ビットはパス６２２を介して出力される７−ビットセクションと一緒に使用される。
【００６６】
図６に戻って、現在必要なのは連続ビットを最下位７−ビットセクションで始まる３３−ビットセクターにより出力されるその関連するセクションと結合することにより圧縮符号化命令アドレスを形成し、次に圧縮符号化命令アドレスのどれだけをトレースバァッファ１２へ出力するかを決定することである。論理０連続ビットに遭遇するとすぐに、トレースバァッファへさらにセクションを出力する必要がなくなる。この機能は図６に示す圧縮符号化命令アドレス発生器６９０により実施される。このプロセスは図１０に略示されている。図１０に示すように、最下位７−ビットセクションで開始して、７−ビットセクション１０００は８−ビットセクションへ変換され適切な連続ビットへ１０１０を加えることにより最上位ビットとして出力される。このプロセスは各７−ビットセクションに対して次々に繰り返される。
【００６７】
最上位５−ビットに対応する５−ビット値１０２０は連続ビット１０６０と共に２つの論理値１０４０および１０５０をプリペンドすることにより８−ビット出力へ拡張される。前記したように、このセクションは必ず圧縮符号化命令アドレスの最後のセクションであるため、この場合連続ビットは常に論理０値である。
【００６８】
次に、前記プロセスから生じる４０−ビット値が圧縮符号化命令アドレス発生器から出力され、前に連続ビット発生器６８０により発生されたイネーブルビットが長さ値を作り出すのに使用され、それは４０−ビット値内のどれだけ多くの８−ビットセクションをトレースバァッファ１２へ出力するかを決定するのに使用される。例えば、パス６８２上のイネーブルビットおよびＯＲゲート９１０からの出力がセットされると、２つの最上位８−ビットセクションが圧縮符号化命令アドレスとしてトレースバァッファ１２へ出力される。
【００６９】
好ましい実施例の前記説明から、命令セット情報に命令アドレスを取り入れ、その符号化命令アドレスを圧縮して格納のための効率的な表現を提供する効率的な技術が記述されたきたことがお判りであろう。好ましい実施例では、この技術はトレーシング機構に応用され、圧縮データはトレースバァッファ１２内に格納される。次に、圧縮符号化命令アドレスを伸張するための伸張論理を汎用コンピュータ１６内に設けることができる。圧縮技術に関する詳細な検討が既になされているため、当業者ならば伸張がどのように働くかが容易にお判りであろう。簡単に言えば、伸張器が圧縮符号化命令アドレスを表わす８−ビットセクション系列を読出し、各８−ビットセクションの最上位ビット位置内の連続ビットの値により示される、１つの８−ビットセクションから５つの８−ビットセクションまで系列は変動する。
【００７０】
５つの８−ビットセクションからなる圧縮符号化命令アドレスに対して、符号化命令アドレスは各８−ビットセクションから連続ビットを剥ぎ取り、次に最下位７−ビットセクションで開始して７−ビットセクションを連結することにより再構成することができる。最下位３３−ビットは符号化命令アドレスを表わすようになり、その３３−ビット値の最上位３−ビットパターンが命令セットを識別する。命令がＪａｖａ命令であれば、符号化命令アドレスの最下位３２−ビットを出力するだけで３２−ビット命令アドレスを再生することができる。命令がＴｈｕｍｂ命令であれば、符号化命令アドレスを１位置だけ左へシフトさせ最下位３２−ビットを出力することによりオリジナル命令アドレスが与えられ、最下位ビットは論理０値となる。同様に、命令がＡＲＭ命令であれば、符号化命令アドレスを２位置だけ左へシフトさせ最下位３２ビットを出力することによりオリジナルＡＲＭ命令を出力することができ、この場合最下位２ビットが論理０値となる。
【００７１】
４セクション以下からなる後続圧縮符号化命令アドレスに対しては、圧縮符号化命令アドレス内に含まれる各セクションから連続ビットを除去することができ、命令アドレスの最下位ビットは最下位セクションで開始される任意のこのようなセクションを結合することにより再構成される。圧縮符号化命令アドレス内のセクション数に応じて、これにより命令アドレスの第１の７，１４，２１または２８ビットが生じる。残りのビットは先行する伸張命令アドレスと同一であるため、その前の伸張命令アドレスから決定することができる。
【００７２】
本発明の最も好ましくない実施例のトレーシング技術の詳細な説明は、英国、キャンブリッジ、ＡＲＭ社から公然と入手できるＥｍｂｅｄｄｅｄ ＴｒａｃｅＭａｃｒｏｃｅｌｌ（ＲＥＶ１）記述と一緒に読むべき下記のアクチュエータ記述に与えられている。
１．１
このドキュメントは下記の用語および略語を使用する。

【００７３】
範囲
このドキュメントはＥＴＭ１０の機能を指定するものである。ＥＴＭ１０は命令およびデータトレーシングが可能なリアルタイムトレースモジュールである。機能はＡＲＭ７およびＡＲＭ９に対する従来のＥＴＭインプリメンテーションのそれと同様である。読者はＥｍｂｅｄｄｅｄ Ｔｒａｃｅ ＭａｃｒｏｃｅｌｌＳｐｅｃｉｆｉｃａｔｉｏｎ（ＡＲＭ ＩＨＩ ００１４Ｄ）に概説されているオリジナルＥＴＭ仕様に精通しているものとする。この仕様はＥＴＭ１０と従来のＥＴＭバージョン間の共通のアクチュエータ特徴を再び述べようとするものではなく、ＥＴＭ仕様のＥＴＭ１０に対して変更される部分を検討するものである。これらの変更の大部分はＡＲＭ１０２０Ｅを適切にトレーシングすることができる新ＥＴＭプロトコルの生成に関係している。このプロトコルは将来のＡＲＭコアもトレーシングするために拡張可能とされる。
【００７４】
序説
Ｅｍｂｅｄｄｅｄ Ｔｒａｃｅ ＭａｃｒｏｃｅｌｌはＥＴＭ，トレースポート解析器、およびソフトウェアデバッガー（ＡＤＷ等）を含むＡＲＭのＲｅａｌ
Ｔｉｍｅ Ｄｅｂｕｇソリューションの一体部である。
【００７５】
Ｅｍｂｅｄｄｅｄ Ｔｒａｃｅ Ｍａｃｒｏｃｅｌｌは２つの部分、トレースブロックおよびトリガーブロックからなる。トレースブロックは圧縮トレースを生成し狭いトレースポートを横切ってそれを出力する。トリガーブロックはユーザがトリガー状態を指定できるようにするプログラマブルリソースを含んでいる。トリガーブロックリソースはどの命令およびどのデータ転送がトレースされるかを制御するフィルタとしても使用される。全てのＥＴＭ構成レジスタ（トリガーブロックリソースを含む）がＪＴＡＧインターフェイスを介してプログラムされる。ユーザはソフトウェアデバッガーを使用してこれらのレジスタにアクセスする。トレースが捕捉されると、デバッガーにはトレースを伸張してユーザに実行されたコードの全分解を提供する責任もある。デバッガーソフトウェアはＥＴＭトレースポート出力をリアルタイムで処理することができないため、トレースは最初に外部Ｔｒａｃｅ Ｐｏｒｔ Ａｎａｌｙｓｅｒ（ＴＰＡ）内へ捕捉される。ＴＰＡは完全に機能的な論理解析器、またはＡｇｉｌｅｎｔ ｎＴｒａｃｅｂｏｘ等の特定ＥＴＭデバイスとすることができる。トリガー状態が生じてデバッグランが完了すると、デバッガーはＴＰＡからトレース情報を抽出する。説明のこのハイレベルにおいて、ＥＴＭ１０はＥＴＭ７およびＥＴＭ９と機能的に同一である。
【００７６】
Ｅｔｍ１０に必要な変更
ユーザの観点から、ＥＴＭ１０は重要ではない僅かな違いはあるがＥＴＭ７およびＥＴＭ９により提供されるのと等価の命令およびデータトレーシング能力を提供する。この章はＥＴＭ１０に対するＥＴＭアーキテクチュアに対してなされる変更およびなぜ変更されるかを説明する。多くの変更は伸張ソフトウェアにしか影響を及ぼさず、エンドユーザだけでなく残りのトレースツールキットソフトウェアには不可視である。しかしながら、ある変更はプログラマーのモデルに影響を及ぼすかあるいはＥＴＭ７およびＥＴＭ９からのトレーシング動作に小さな差を生じる。このような変更がこの章で指示される。新プロトコルの徹底的な説明を必要とするＥＴＭ１０に対する任意の変更は５章のプロトコル説明においてより徹底的に扱われる。
【００７７】
１．２ 分岐ファントムトレーシング
ＡＲＭ１０は“分岐畳込み（ｂｒａｎｃｈ ｆｏｌｄｉｎｇ）”を実現し、それは分岐を予測し、正規の命令ストリームから引出し、プログラム内の次の命令と並列に有効に実行できることを意味する。これらの畳み込まれた分岐は分岐ファントムと呼ばれる。旧プロトコル内のＰＩＰＥＳＴＡＴ符号化はサイクル当たり実行される１命令しか考慮しない。分岐ファントムがトレースされるようにするために、命令と並列に畳み込まれた分岐を表わすＰＩＰＥＳＴＡＴフィールドに新符号化が追加される。５章のＥＴＭ１０プロトコル仕様内に新ＰＩＰＥＳＴＡＴが与えられている。
【００７８】
畳み込まれた分岐はトリガーブロックへの変更も必要とする。分岐が畳み込まれると、有効に２つの命令が並列に実行される。これら２つの命令に対するＰＣ値は任意の識別可能な関係を有することが保証されないため、２つのアドレス比較を各サイクルで行わなければならない。これは各アドレスレジスタが２つの比較器を必要とすることを意味する。トレーシングがイネーブルされるかどうかを決定する時に、両方の比較器出力が考慮される。（これら２つの命令のいずれかがトレースされる場合には、トレーシングはそのサイクルでイネーブルされる）。分岐畳込みによりせいぜい１つの追加命令しかトレースされないことを保証するために特別な注意がなされる。一般的に、ユーザはＴｒａｃｅＥｎａｂｌｅまたはＶｉｅｗＤａｔａを適切にプログラムするためにいつ分岐が畳み込まれ次の命令と一緒に並列に実行されるかを知っている必要がない。
【００７９】
イベントに対して、命令の並列実行はＥＴＭ１０対ＥＴＭ７／９からの僅かに異なる動作を有することを可能とする。ここでは、イベントが典型的に使用される方法による機能の多くの損失があるとは感じられない。カウンタはサイクル当たり１回しかカウントダウンできないが、単一アドレス比較器が使用される場合にはカウンティングはアクセスの正確なカウントを与えている。さらに、Ｔｒｉｇｇｅｒ，ＴｒａｃｅＥｎａｂｌｅ，ＶｉｅｗＤａｔａまたはＥｘｔＯｕｔイベントへの機能の損失はなく、イベントは命令またはデータ転送が個別にそれをアクティブとしている、所望の動作時にアクティブである。シーケンサーが同じサイクル内に多数の遷移要求を受信する場合には、遷移はなされずシーケンサーはオリジナル状態にとどまる。この動作はＥＴＭ７およびＥＴＭ９のそれと同一である。しかしながら、ＡＲＭ１０がより多くの並列実行をサポートするため、ＥＴＭ１０はサイクル内で多数の遷移要求のより多くの発生を有することがある。ユーザはシーケンサーをプログラミングする時にこの動作を知る必要があるが、単純なイベントに対するワークアラウンドがある。所望の動作がイベントＡに基づいた状態１−〉２およびイベントＢに基づいた状態２−〉３からの遷移であれば、プログラム１−〉２がイベント（Ａ＆ＩＢ）上に生じ、２−〉３がイベントＢ上に生じ、１−〉３がイベント（Ａ＆Ｂ）上に生じる。このようにシーケンスをプログラミングすることによりイベントＡおよびイベントＢの同時発生の適切な処理が保証される。
【００８０】
１．３ ロードミスおよび例外トレーシング
ＡＲＭ１０は他のメモリ命令を含む他の命令を単一の顕著なミスの下で実行できるようにする非ブロッキングデータキャッシュを有し、データキャッシュは狂った順でデータをコアへ戻すことができる。現在プロトコルはロードデータが正しい順でＦＩＦＯに配置されることを期待するため、この特徴はロードデータ追跡問題である。データパケットは一部ヘッダーバイトによりプレフィクスされて狂った順のロードミスデータを収容する。ヘッダーバイトは５章に詳細に説明されている。
【００８１】
非ブロッキングキャッシュのサポートはデータ比較器への変更も必要とする。ＥＴＭ７およびＥＴＭ９と同様に、ＥＴＭ１０は一対のアドレス比較器と一緒に使用されるデータ比較器を有する。使用時に、比較器はデータもマッチする場合のマッチしかトリガーしない。他のメモリアクセスはミスの下で生じることがあるため、ミスとなるロード要求に対するアドレスがマッチしたかどうかを記憶にとどめるために各比較器にビットが追加される。ロードミスデータが戻されると、データ値比較がなされ、比較結果を限定するために保存されたアドレスマッチビットが使用される。次に、このマッチビットはクリアされる。場合によっては、ユーザは比較器をイネーブルするためにミスデータが戻されるのを待機したくないことがある。替わりに、ロードミスが常にデータアセンブリだけに基づいてトレースされるようにしたいことがある。両方のユーザモデルをサポートするために、各比較器に対してどのモデルがイネーブルされるかをユーザが指定できるようにするビットがアドレスアクセスタイプレジスタへ加えられている。比較におけるロードミスデータに対する待機が望まれる場合には、ユーザはアドレスアクセス型レジスタのビット８、Ｅｘａｔｘ Ｍａｔｃｈビット、をセットしなければならない。（アクセスタイプレジスタの詳しい情報については参照１を参照されたい）。トリガーその他のイベントを生成するためにデータ値が使用される場合には、データ比較が生じるのを待機することは有用である。比較器がトレースフィルタリングに使用されある無関係なトレーシングが問題とされない場合には、アドレスのみに基づいたトレーシングロードミスが有用である。ロードデータは狂った順で戻されることがあるため、ユーザはデータ値を使用して、シーケンサ遷移等の、イベントを生成することにより狂った順のイベントが生じることがあることを知らなければならない。ＡＲＭ１０の非ブロッキングキャッシュがプログラムされたイベントに影響を及ぼすことがあることにユーザが関係する場合には、この特徴はｃｐ１５構成レジスタ（ｒ１）へのライトを介してコア内でディセーブルすることができる。詳細な情報についてはＡＲＴ１０１０Ｅ ＴＲＭ（参照３）を参照されたい。
【００８２】
アクセスタイプレジスタのビット７は中断、割込み、またはソフトリセットが生じる時の比較器動作を指定するのに使用される。これらの状態は一般的に例外と呼ばれる。データアクセスが中断されビット７が表明されると、データマッチが要求されるかどうかに無関係に、比較器はマッチ出力とはならない。比較器が命令アドレスと結ばれる場合には、例外とマークされる命令でのマッチを防止するのに正確なマッチビットが使用される。例外となる命令およびデータ要求は通常中断または割込み状態が解決されると再試行されるため、比較器が１回しか点火しない場合にこの動作が望ましい場合が多い。データアクセスケースでは、ビット７が表明されない場合には、データ値は無効と推定されるため中断されたアクセスにより純粋にアドレスに基づくマッチとなる。
【００８３】
所望の動作は典型的には両方のケースに対して同じであるため、同じＥｘａｃｔ Ｍａｔｃｈビットがロードミスおよびデータ中断の適切な処理を決定するのに使用される。Ｅｘａｃｔ Ｍａｔｃｈビットのデフォルト値は０である。
【００８４】
１．４ ＡＲＭ１０データトレーシング
ＡＲＭ１０２０Ｅは単一サイクル内でデータの６４ビットを戻すことができる６４ビットデータバスを有する。この６４ビットデータバスをサポートするために、ＥＴＭ１０は単一サイクル内に２つの隣接データ値をトレーシングできなければならない。一方または他方の値だけのトレーシングをサポートするために、２つのＶｉｅｗＤａｔａ出力が発生される。しかしながら、まだイベント用の１つの出力とＴｒａｃｅＥｎａｂｌｅ用の１つの出力しかない。同じサイクル内にアクセスされる２つの隣接３２ビット要求によりカウンタの１減分またはシーケンサによる１つだけの状態変化しか生じないため、１つのイベント出力を有することはカウンタおよびシーケンサ論理に影響を及ぼすことがある。イベント論理をプログラミングする時にユーザはこれを考慮しなければならないが、それは重要な問題とは思われない。
【００８５】
１．５ ＬＳＭトレーシング
ＡＲＭ１０２０Ｅは独立したロード／ストアユニットを有し、それによりロード／ストアユニットがデータアクセスを反復する間に、以後ＬＳＭと呼ぶ、多数の命令のロードまたはストアの下で他の命令を実行することができる。（すなわち、ＬＳＭの実行はコアを停止させない）。これをサポートするために、アドレス比較器出力およびＴｒａｃｅＥｎａｂｌｅの表明へのある変更が必要である。・ＬＳＭ命令を反復しながらそれをアクティブにトレーシングする時は常に、ＴｒａｃｅＥｎａｂｌｅが表明されたままであるかどうかにかかわらず、ＬＳＭが完了するまでそれはアクティブのままである。（このルールの唯一の例外はオーバフローケースである）。このルールにはＬＳＭの下で実行された他の命令が、本来トレースされるものかどうかにかかわらず、トレースされてしまうという副作用がある。しかしながら、定義によりＬＳＭの下で実行する命令はデータ命令であるはずがないため、それにより余分なデータパケットが生じることはない。・比較器がＬＳＭの命令アドレス上で活性化される時は常に、その比較器のＶｉｅｗＤａｔａ出力は全命令が完了するまで表明されたままである。それはユーザの意図がこの命令に関連する全てのデータパケットをトレースすることであるためである。同様に、ＶｉｅｗＤａｔａおよびＥｖｅｎｔ範囲出力はＬＳＭ命令の完了まで表明されたままである。イベント単一アドレス比較器出力は定義により単一サイクルしか表明しないため、表明されたままではない。
・ＬＳＭに関連するデータ転送がトレースされていると、通常トレースされないその命令に関連する後続転送はプレースホルダーパケット出力を有する（トレースされない値−５章参照）。これらのプレースホルダーパケットはどの語がトレースされたかを確認する必要がある。
【００８６】
ＥＴＭプロトコルは命令トレーシングがロード／ストアデータアドレス（およびデータ値）に基づいて命令トレーシングがイネーブルされることを考慮する。ＡＲＭ１０上で、ＬＳＭ命令はトレーシングイネーブリングイベントが生じる時にもはやコアの実行段階にはないことがあるため、この命令アドレスは周りに維持して特殊な方法で同報してこの特徴をサポートする必要がある。これはＰｒｏｇｒｅｓｓ ＴＦＯパケット内のＬＳＭを使用して遂行される。Ｔｒａｃｅ Ｐａｃｋｅｔ Ｏｆｆｓｅｔは５．２．４に記載されている。
【００８７】
１．６ 補助データトレーシング
プロトコルへのデータヘッダーの追加は補助データタイプのトレーシングも考慮する（すなわち、ロード、ストア、およびＣＰＲＴ命令以外のデータ値のトレーシング）。この補助データタイプトレーシングはＥＴＭトレーシングの拡張を考慮することを意味し、それはＥＴＭの将来バージョンにおける外部ＡＳＩＣデータのトレーシングを含むことができる。補助データトレーシングのより多くの情報が５章のデータヘッダー検討に与えられている。
【００８８】
１．７ ＣＯＮＴＥＸＴＩＤトレーシング
ＣＯＮＴＥＸＴ ＩＤはそれらが更新される時および同期化のためにＴＦＯパケットが必要である時は常に同報される。ＥＴＭ１０に対して、ＣＯＮＴＥＸＴＩＤ値はそれらがＣＯＮＴＥＸＴ ＩＤ変化となるＣＰＲＴ命令に対するデータトレーシングを単純にイネーブルして更新される時に出力される。このデータパケットに対する一意的データヘッダーにより伸張器はデータが新しいＣＯＮＴＥＸＴ ＩＤ値であることを認識することができる（データヘッダーは５章で検討される）。ＥＴＭはまたトレースがイネーブルされる時は常に、また５．２．４章で説明されるトレース同期サイクル中に現在ＣＯＮＴＥＸＴ ＩＤ値を同報する。ＣＯＮＴＥＸＴ ＩＤ更新命令はＭＣＲ ｃ１５，０，ｒｄ，ｃ１３，ｃ０，１である。
【００８９】
ＡＲＭ１０〈−〉ＥＴＭ１０インターフェイス上のもう一つの３２ビットポートを必要とする替わりに、ＥＴＭ１０はＣＯＮＴＥＸＴ ＩＤ更新を認識して現在ＣＯＮＴＥＸＴ ＩＤ値を内部シャドーレジスタ内に維持する。コヒーレンシを適切に維持するために、ＥＴＭがＰＯＷＥＲＤＯＷＮモードである時でも（ＥＴＭレジスタ０×４、ビット０が表明される）このレジスタは常に更新される。
【００９０】
トレースフィルタリング用のＣＯＮＴＥＸＴ ＩＤ値を使用することがＥＴＭ１０に対する追加特徴として加えられる。これは予期ＣＯＮＴＥＸＴ ＩＤ値を指定することができるＥＴＭ内の新しいプログラマブルレジスタセットを介して実現される。
【表１】

各ＣＯＮＴＥＸＴ ＩＤ比較器に対して同じマスクが使用され、データ比較器マスクと同様に働く。
【００９１】
アドレス比較器アクセスタイプレジスタのビット９：８はＣＯＮＴＥＸＴ ＩＤ比較器が使用されるかどうかを示す。００の値によりＣＯＮＴＥＸＴ ＩＤ比較器は無視される。０１，１０または１１の値によりアドレス比較器は、ＣＯＮＴＥＸＴ ＩＤマスクを考慮した後で、現在ＣＯＮＴＥＸＴ ＩＤがそれぞれＣＯＮＴＥＸＴ ＩＤ比較器１，２または３内のそれとマッチする時だけマッチするようにされる。
【００９２】
ＣＯＮＴＥＸＴ ＩＤ比較器がイベントブロック内から直接アクセスできるように新しいイベントリソースが割り当てられる（ＡＲＭ ＩＨＩ ００１４Ｄの３．３．４参照）。これらの新しいリソースは０×５８−０×５Ａへマッピングされる。
【表２】

新しいフィールドがＥＴＭ構成コードレジスタに加えられて存在するＣＯＮＴＥＸＴ ＩＤ比較器数を示す（ＡＲＭ ＩＨＩ ００１４Ｄの４．２．２参照）。
【表３】

【００９３】
１．８ トレース出力周波数
ＡＲＭ１０２０Ｅ Ｍａｃｒｏｃｅｌｌは３００ＭＨｚを越えるコア周波数で動作することができる。従来のＥＴＭインプリメンテーションは周波数が２００ＭＨｚを越えることがない。ＥＴＭトレース出力に対して得られる最大出力周波数はトレース解析器の最大サンプル周波数およびパッドで得られる最大出力周波数によって決まる。ＡｇｉｌｅｎおよびＴｅｋｔｒｏｎｉｘ解析器は、それぞれ、３３３ＭＨｚおよび４００ＭＨｚの最大周波数で捕捉することができる。しかしながら、ＡＲＭパートナーから得られる任意のＣＭＯＳパッドはこの周波数においてクリーンで、トレース可能な信号を供給できる可能性が非常に高い。したがって、パッドは速度制限要因と考えられる。より大きなパッドおよび／またはボードレベルバァッファリングを使用してある速度改善を得ることができる。これらの技術により我々は２００ＭＨｚにおいて信頼できるトレースを行うことができる。より高速のトレーシングに対しては、２つのオプションがある。ピンカウントを２倍にし周波数を半分にすることができる（デマルチプレクストレースポート）、あるいはオンチップトレースバァッファを利用することができる。両方の技術に利点および欠点がある。
【００９４】
ピンカウントを２倍にすることはパッケージ制限および追加ピンの高いコストによりあるパートナーにとって魅力的なオプションではない。また、この技術はＴＰＡの変更および、恐らくは、第２のマイクロコネクタの追加が必要であり、それはより広い面積をとりさらにコストが加算される。さらに、この技術にはやはり４００ＭＨｚの速度制限がある。熱工程で作られたＡＲＭ１０プロセッサは恐らくこれらの速度を越える。
【００９５】
オンチップバァッファにはコアクロック速度で信頼できるトレーシングおよび追加ピンをなんら必要としない利点がある。事実、全てのトレース捕捉がオンチップバァッファを利用して行われる場合には、オンチップバァッファがＪＴＡＧポートを介したＭｕｌｔｉ−ＩＣＥを経てダウンロードされるため外部可視ＥＴＭポートは解消することができる。このソリューションの欠点はオンチップバァッファのサイズが典型的に極めて小さく、８−１６ＫＢ程度であることである。したがって、トレーシング深さが制限される。大きなオンチップトレースバァッファが可能であるが、ＡＳＩＣのサイズに直接インパクトを与え、小さなトレースバァッファであっても同じ設計で与えられるよりも多くのシリコンスペースを使用することがある。
【００９６】
各方法の利点および欠点が変動するため、前記した両オプションがサポートされるように計画される。高速トレーシング用デマルチプレクスドトレースポートによりＡＲＭ１０２００ ｒｅｖ １テストチップが造られる。オンチップトレースバァッファはＡＲＭ１０２００ ｒｅｖ １テストチップの一部ではない。
【００９７】
ＥＴＭ９用オンチップトレースバァッファの仕様が作成されており、インプリメンテーションが進行中である。５．２章に記載されている新４ビットＰＩＰＥＳＴＡＴ符号化をサポートする重要ではない変更により、この設計からＥＴＭ１０コンパチブルオンチップトレースバァッファを生成することができる。ＥＴＭ１０をサポートするのにどんなＴｒａｃｅ Ｃａｐｔｕｒｅ Ｄｅｖｉｃｅ変更が必要であるかの詳細な情報については参照４を参照されたい。タイムスケールに応じて、ＥＴＭ１０コンパチブルオンチップトレースバァッファは、ダイナミックトレース圧縮等の、追加特徴を提供することができ、事実ＦＩＦＯ置換として直接ＥＴＭ１０設計内に一体化することができる。
【００９８】
１．９ 同期レジスタ
従来のＥＴＭインプリメンテーションでは、同期は１０２４サイクル毎に５−バイト命令を介して、また１０２４サイクル毎に５−バイトデータアドレスを介して生じる。ＥＴＭ１０に対しては、これらの同期点は新しい１２ビットプログラマブルレジスタを介して構成することができる。構成可能な同期によりトレースバァッファサイズの全範囲を利用するのが容易になる。オンチップトレースバァッファ等の小型トレースバァッファはトレースの大きな部分を投げ出すのを回避するために頻繁に同期することができ、大型トレースバァッファは不要同期の無駄なトレーススループットを回避するためにたまに同期することができる。デフォルトカウンタ値は１０２４サイクルである。データアドレスおよび命令アドレス同期が同時に生じるのを防止するために、データアドレス同期はカウンタがその中点値に達する時に生じ命令アドレス同期はカウンタが０に達する時に生じる。新しい同期レジスタに対するアドレスは０×７８である。
【００９９】
１．１０ メモリマップデコーダ
従来のＥＴＭインプリメンテーション内に存在した外部メモリマップリソース入力はＥＴＭ１０に対してサポートされない。ＡＲＭ１０アーキテクチュア内に存在する余分な複雑さにより外部デコーダに対するサポートの実現はより困難となる。外部イベントはＥＸＴＩＮを利用することによりまだトレーシングを制御することができ、それはｃｙｃｌｅ ａｃｃｕｒａｔｅとなる（４．１５で検討されている）。
【０１００】
１．１１ レンジアウト
従来のＥＴＭインプリメンテーションはＥｍｂｅｄｄｅｄ ＩＣＥ論理内のデータ値比較レジスタを余分な外部レジスタリソースとして使用することができる。この機能はＥｍｂｅｄｄｅｄ−ＩＣＥから来るＲＡＮＧＥＯＵＴ出力を使用して遂行される。ＡＲＭ１０デバッグユニットにはデータ値比較機能がないためこれらのＲＡＮＧＥＯＵＴ出力はない。したがって、このリソース再使用はＥＴＭ１０に対しては不可能である。これらのリソースはもはやプログラムされないためプログラマーのモデルへのそのインパクトは少ない。
【０１０１】
１．１２ 割込みベクトルへの分岐
現在プロトコルは割込みベクトルテーブル内のエントリーへの直接分岐は間接分岐としてトレースしなければならないと指定している。ファントム分岐は提案されたプロトコル内で間接分岐へ変換することができないため、もはやこれは常に可能ではない。したがって、直接分岐が分岐ファントムであったかどうかに無関係に、一貫性および単純性のために割込みベクトルへの直接分岐はもはや間接分岐としてトレースされない。５．３．１章に記載されているアドレスバイト５の特殊な符号化によりＰＡＢＯＲＴ，ＦＩＱ，ＩＲＱ，ＤＡＢＯＲＴ，およびＲＥＳＥＴベクトルへの分岐を検出することができる。
【０１０２】
１．１３ プロトコルバージョン
ＥＴＭ７およびＥＴＭ９上の構成コードレジスタ（レジスタ０×０１）内に存在する４−ビットＥＴＭプロトコルバージョンフィールドはＥＴＭ用の将来のプロトコルバージョンをサポートするのに不十分であることが確認されている。したがって、マイナーおよびメジャー訂正番号だけでなく意図するＡＲＭコアを指定するフィールドを含む新しいＥＴＭ ＩＤレジスタが定義されている。このレジスタはレジスタアドレス０×７９へマッピングされ、構成レジスタ内のビット３１がセットされる時は常に有効と見なされる。それによりＥＴＭ７およびＥＴＭ９はＩＤレジスタを必要とせずにプロトコルバリアント０−７を使用することができる。ＥＴＭ ＩＤレジスタは下記のフィールド内へ分散される３２ビット値を含む。
【表４】

ＥＴＭ ｒｅｖ０はＩＤ値０×４１０１２１００を有する。
【０１０３】
１．１４ トレース開始／停止リソース
ＴｒａｃｅＥｎａｂｌｅ開始／停止論理の現在状態を与える新しいイベントリソースが含まれる。これにはリソース番号１０１ １１１１が与えられ（ＡＲＭＩＨＩ ００１４Ｄの３．３．４章参照）、Ｔｒａｃｅ Ｓｔａｒｔ／Ｓｔｏｐがアクティブである時は常に表明しなければならない。開始／停止リソースをサポートするＥＴＭバージョンはＥＴＭ制御レジスタ内のビット２３も表明する。
【０１０４】
１．１５ ＴＰＡ変更
全てのＴＰＡはＡＲＭ１０用の新しいトリガーおよびトレースディセーブル状態値をサポートするためのマイナー変更が必要である。すなわち、それらはＴＲおよびＴＤ ＰＩＰＥＳＴＡＴｓを検出するためにＰＩＰＥＳＴＡＴ［３］／ＴＲＡＣＥＳＹＮＣがローであることを保証しなければならない。ＡｇｉｌｅｎｔｎＴｒａｃｅはマイナーハードウェア変更も必要である。デマルチプレクド、ハーフスピードＥＴＭポートを介した高速トレーシングをサポートするために、ＴＰＡは各サイクル内でトレースデータの２コアサイクル分を捕捉できなければならない。このデータはＭｉｃｔｏｒコネクタを横切って同報される。したがって、多数のコネクタに対するサポートも必要である。これらの変更に関するより詳細な情報については参照４を参照されたい。
【０１０５】
１．１６ 精密イベント
ＥＴＭ７およびＥＴＭ９において、Ｅｖｅｎｔブロックを介して発生されるイベントは精密ではなく、それはユーザはデータアクセスまたはＥｖｅｎｔを発生した命令をトレースすることを保証されなかったことを意味する。ＥＴＭ１０に対してはもはやそうではない。ＶｉｅｗＤａｔａおよびＴｒａｃｅＥｎａｂｌｅの表明はそれがどのように発生されるかにかかわらず常に精密である。
【０１０６】
１．１７ ＦＩＦＯＦＵＬＬレベルレジスタ
ＥＴＭ７およびＥＴＭ９レジスタに対して、ＦＩＦＯＦＵＬＬが表明される前にＦＩＦＯが達しなければならないレベルをセットするのに０×０Ｂが使用された。ＥＴＭ１０、ＦＩＦＯＦＵＬＬに対してこのレジスタは使用されず替わりに、イネーブルされると、ＦＩＦＯＦＵＬＬはその中に新しいパケットが置かれる時は常に表明される。ＥＴＭ１０はＥＴＭ７／９よりも深くパイプラインされ、ＦＩＦＯＦＵＬＬはこのように使用される場合に有用となるのに十分早くしか表明できない。ＥＴＭ１０において、ＦＩＦＯＦＵＬＬレジスタはＦＩＦＯサイズを指定するリードオンリーレジスタとして再使用される。ＦＩＦＯサイズはＥＴＭ７／９内でソフトウェアにより決定することができないサイズである。
【０１０７】
１．１８ トリガー出力
プロセッサがモニターデバッグモードであれば、ＤＢＧＲＱは無視される。したがって、トリガーが生じていることを認識することができる他の機構を有することが有用である。このために、単一ビットＴＲＩＧＧＥＲ出力がＥＴＭ１０用ＥＴＭインターフェイスに追加されている。ＴＲＩＧＧＥＲ出力は４−ビットＴＲＩＧＧＥＲ状態がＰＩＰＥＳＴＡＴバス上で駆動される時は常に表明される。次に、この信号を割込みコントローラが使用して割込みの表明を介してトリガーのコアを知らせることができる。ＴＲＩＧＧＥＲ出力は不要であれば追加しないままとすることができる。
【０１０８】
１．１９ カウンタイベント
ＥＴＭ７／９に対して、カウンタイベントレジスタは連続的にカウントするのに使用することができる余分なビット１７を有する。このビットはその動作が冗長性で検証することが困難であるため除去されている。連続的カウンタが欲しい場合には、ユーザは常にアクティブとかべきハードワイヤである外部リソース１５に等しいイベントを単純にプログラムする。
【０１０９】
ＥＴＭ１０トレースポート
１．２０ ＥＴＭ１０ポート信号
ＥＴＭ１０トレースポートは２つの信号、ＰＩＰＥＳＴＡＴおよびＴＲＡＣＥＰＫＴ、からなり共にＴＲＡＣＥＣＬＫ（ＧＣＬＫと同じ周波数を有する）の立上り縁において有効である。ＰＩＰＥＳＴＡＴは分岐ファントム用符号化スペースを追加するためにＥＴＭ１０に対して３ビットから４ビット信号へ拡張されている。ＴＲＡＣＥＰＫＴは従来のＥＴＭバージョンから変更されておらず、構成に応じて４，８，または１６ビットとすることができる。同期はもう一つの機構を介して達成されるため、ＴＲＡＣＥＳＹＮＣピンはプロトコルから除去されている。全般的結果は従来のＥＴＭインプリメンテーションと同じピンカウントを有するトレースポートとなる。
【０１１０】
１．２１ ＰＩＰＥＳＴＡＴ符号化
【表５】

【０１１１】
１．２１．１ 分岐ファントムＰＩＰＥＳＴＡＴｓ
下記の命令と並列に実行される分岐ファントムを考慮するために８つの新しい分岐ファントムが付加される。これらの符号化は常に実行ストリームの最初である分岐命令として解釈しなければならない。直接分岐だけが予測され、分岐ファントムはＦＩＦＯ内にデータパケットを置くことはない。並列に実行されるいかなる命令も不正命令ストリームからのものでありしたがってキャンセルされるため、誤予測される畳込み分岐により正規のＩＥ／ＩＮ ＰＩＰＥＳＴＡＴが生じる。
【０１１２】
１．２１．２ Ｄａｔａ ＰＩＰＥＳＴＡＴｓ
‘Ｄ’で始まる全てのにニューモニックはある種のデータパケットがサイクルするＦＩＦＯ内に置かれいずれＴＲＡＣＥＰＫＴピン上に出力されることを意味する。新プロトコルに対する‘パケット’という語はＦＩＦＯ内の単一バイトではなくＦＩＦＯに置かれる多バイト量のことであることをお判り願いたい。データパケットは分岐アドレス、ロード／ストア転送、ＣＰＲＴ転送、または補助データパケットとすることができる。ＥＴＭ１０は１サイクル内に最大３つのデータパケットをＦＩＦＯ内に置く（２つのＬＤＳＴ／ＣＰＲＴ転送と１つの分岐アドレスパケット）。１サイクル内３パケットはプロトコルではなくハードウェアの制約である。別々のデータおよび分岐ＰＩＰＥＳＴＡＴｓの必要性はプロトコルにパケットヘッダーバイトを追加することにより除去されている。ＤＷおよびＤＮ状態値を追加することによりに任意のサイクルにデータパケットを付加することができる。この追加はＬＤＳｓ／ＳＴＣｓの長さを決定するコプロセッサマップがもはや不要であり、可変長ＬＤＣ／ＳＴＣ命令のトレーシングがサポートされることを意味する。パケットヘッダーバイトについては５．３章により詳しく説明されている。
【０１１３】
１．２１．３ 命令ＰＩＰＥＳＴＡＴ
非待機ＰＩＰＥＳＴＡＴ値、すなわち命令が実行されたことを示すもの、は常に命令が実行されている第１サイクル上に与えられる。この区別は数サイクルに対してデータを実行して戻すＬＳＭ命令にとって重要である。この動作は、ＬＳＭが実行されたＬＡＳＴサイクルに実行したＰＩＰＥＳＴＡＴ値を与える、従来のプロトコルバージョンとは異なっている。
【０１１４】
“実行されない”ＰＩＰＥＳＴＡＴｓ（ＩＮ／ＤＮ）は２つの理由により生じる。命令がその条件コードに失敗したか、または例外により実行されなかった。前記したように、可能な例外は割込み、プリフェッチ中断、およびリセット表明を含んでいる。データ中断となるロード／ストア命令は実行されていると考えられるためＩＮ／ＤＮ状態を与えられない。伸張器は例外により命令の実行が防止される時を知る必要がある。この情報は前のＬＳＭ命令からの遅いデータパケットが例外命令に付加されるのを防止するのに使用される。（“実行されない”ＰＩＰＥＳＴＡＴを有する命令が考慮される唯一のデータパケットは分岐アドレスである）。
【０１１５】
１．２１．４ ＴＤ状態およびＴＦＯｓ
ＴＤの状態はこのサイクルのＴＲＡＣＥＰＫＴ上にトレースＦＩＦＯデータが存在しないことを意味する。なぜそれが起こるかについて２つの理由がある。
・ＦＩＦＯ内にトレースされるデータがない（ＦＩＦＯが空でなければ、状態はＷＴである）。特に、トレースがディセーブルされるすぐ後で次にイネーブルされるまで生じる。
・ＥＴＭ同期のためにＴＦＯが同報される。
【０１１６】
ＰＩＰＥＳＴＡＴ上にＴＤ状態が与えられると、伸張ソフトウェアはＴＲＥＣＥＰＫＴを見てＴＦＯが同報されているかどうかを確認する必要がある。従来のＥＴＭインプリメンテーションで行われるように、ｃｙｃｌｅ−ａｃｃｕｒａｔｅおよびｎｏｎ−ｃｙｃｌｅ ａｃｃｕｒａｔｅトレース間を区別するのにＴＲＥＣＥＰＫＴ［０］が使用される。前と同様に、Ｔｒａｃｅ Ｃａｐｔｕｒｅ ＤｅｖｉｃｅｓはＴＲＥＣＥＰＫＴ［０］＝０であればＴＤサイクルを廃棄することができる。ＴＲＥＣＥＰＫＴ［０］が表明されると、ＴＦＯが同報されるかどうかを指定するのにＴＲＥＣＥＰＫＴ［３：１］が使用される。ＴＦＯが同報される場合には、ＴＲＥＣＥＰＫＴ［７：４］がＴＦＯ値の下位４ビットを指定する。ＴＲＥＣＥＰＫＴ［３：１］はＴＦＯ値の残りを下記の表に与えられるように指定する。ＴＦＯはこのように符号化されて有効なＴＦＯ値の範囲を最大とする。
【表６】

【０１１７】
トレース情報を伸張してパイプライン状態（ＰＩＰＥＳＴＡＴ）とＦＩＦＯ出力（ＴＲＡＣＥＰＫＴ）間を同期させる時にＴＦＯまたはＴｒａｃｅ ＦＩＦＯＯｆｆｓｅｔが使用される。トレースが最初にイネーブルされる時および命令同期カウンタが０に達する時は常にＴＦＯが発生される。Ｔｒａｃｅ ＦＩＦＯｏｆｆｓｅｔは従来のＥＴＭインプリメンテーションにおいて使用されたアドレスパケットオフセット（ＡＰＯ）情報を置換する。分岐をカウントするのではなく、ＴＦＯは現在ＦＩＦＯ内にあるバイト数をカウントする。このような同期によりプロトコル内のＴＲＡＣＥＳＹＮＣピンに対する必要性がなくなる。また、ＢＥ ＰＩＰＥＳＴＡＴでトレーシングを開始してＡＰＯ値に対する２つのデッドサイクルが続く必要性もなくなる。
【０１１８】
トレースが既にイネーブルされている間にＴＦＯが同期のために同報される時は常に、ＩＥのＰＩＰＥＳＴＡＴ値が含まれる。ＴＦＯが同報されてトレーシングを開始する時は、ＰＩＰＥＳＴＡＴは含まれず最初にトレースされた命令に対するＰＩＰＥＳＴＡＴが下記のサイクル内で与えられる。
【０１１９】
下記の全ての規準が満たされる時は常に同期ＴＦＯが発生される。
・典型的に１０２４に初期化されたサイクルカウンタが０に達する
・現在命令が‘ＩＥ’のＰＩＰＥＳＴＡＴ値を有する
【０１２０】
同期要求が表示されると、ＴＦＯサイクルカウンタは命令同期レジスタ内へプログラムされている値へリセットされ（デフォルト値は１０２４）カウンティングを再開する。第１の同期要求がサービスされる前に第２の同期要求がなされるケースでは、強制的に同期を起こさせる方法としてＥＴＭは強制的にオーバフローされる。このシナリォではあるトレースが失われるが、それが起こってもプロセッサは無限ループに張り付いている可能性が高いため問題になるとは思われない。したがって、有意トレースは失われない。そうならない唯一のケースは同期カウンタがある途方もない低い数にセットされる場合である。したがって、同期値をあまり低く（５０サイクルよりも低い）セットすることは勧められない。
【０１２１】
ＴＦＯサイクルが生じると、サイクルするＦＩＦＯ上にデータの数バイトが置かれる。このデータはＴＦＯパケットと呼ばれ、典型的には特殊なヘッダーバイト、現在ＣＯＮＴＥＸＴ ＩＤ、および全命令アドレスからなっている。ＴＦＯパケットに対する適切なフォーマットが５．４章に与えられている。
【０１２２】
４−ビットＴＲＡＣＥＰＫＴ構成において、バイトの第２のニブルが予期される時にＴＦＯが生じると、ＴＦＯ値にすぐ続いてＴＲＡＣＥＰＫＴ［３：０］上に値‘０×６’の余分なニブルが出力される。ＴＦＯ値はニブルではなくバイトで同期を指定するためこのニブルが必要である。この余分なニブルを出力することにより、ＥＴＭ１０はＴＦＯ値により指示されたＦＩＦＯの現在のトップが常にバイト一致されることを保証する。同期が不要であるケースに対してこの余分なニブルはＴＲＡＣＥＰＫＴ［３：０］上に現れることを伸張器が知っていることが重要である。ＴＦＯが同期によるものかあるいはイネーブルされるＴｒａｃｅによるものかにかかわらず、ＴＦＯが奇ニブル上に発生される時は常に伸張器はこの余分なニブルを予期しなければならない。完全なＴＦＯ値（および、所望により、余分なニブル）がＴＲＡＣＥＰＫＴ［３：０］上に出力されるまでＦＩＦＯ出力は遅延される。
【０１２３】
１．２１．５ トリガー状態
トリガー状態（ＴＲ）はこのサイクルに対する実際の４−ビット状態がＴＲＡＣＥＰＫＴ［３：０］上に置かれＦＩＦＯ出力が１サイクルだけ遅延されることを暗示する。動作はＥＴＭ７およびＥＴＭ９と同一である。トリガーおよびＴＦＯを同時に生じさせたい場合には、ＴＲＡＣＥＰＫＴ［３：０］上のＰＩＰＥＳＴＡＴ値はＴＤである。ＷＴ ｐｉｐｅｓｔａｔはトリガーが生じる時にＴＤ ｐｉｐｅｓｔａｔへ変換されることがないため、これは真のＴＦＯとして一意的に識別することができる。４−ビットポートのケースでは、ＴＦＯ同報（またはギャップサイクル）の第２サイクル内でトリガーを生じさせたい場合、トリガーが生じてＦＩＦＯ出力は余分なサイクルだけ遅延され残りのＴＦＯニブルを出力する。したがって、トリガーは遅延されることはなく発生するとすぐに出力されることが保証される。
【０１２４】
１．２２ パケットヘッダー符号化
‘Ｄ’符号化を有するＰＩＰＥＳＴＡＴによりパケットはＦＩＦＯ内に置かれる。単一サイクル内に３パケット（２データパケットおよび１分岐パケット）までをＦＩＦＯ内に置くことができる。パケットヘッダー値に対する符号化は次のようである。
【表７】

【０１２５】
データヘッダー上のＣビットは単一サイクル内にどれだけ多くのパケットがＦＩＦＯ内に挿入されるかを伸張器に知らせるのに使用される。最後のパケットを含まない挿入された各パケットに対してＣビットが表明される。これはどのパケットがどのサイクル、したがって、どの命令と結ばれるべきかを伸張器が知るのに必要である。このＣビットは小文字‘ｃ’で示されるアドレス連続ビットと混同してはならない。
【０１２６】
１．２２．１ 分岐アドレス
分岐アドレスは従来のＥＴＭインプリメンテーションと同様な方法で符号化される。分岐パケットはやはり１−５バイト長であり、Ｃビットがイネーブルされる時は常に伸張ツールはより多くのバイトを予期しなければならない。しかしながら、ＴｈｕｍおよびＡＲＭ状態間を区別するのにもはや分岐アドレスのビット０は使用されない。替わりに、全ての分岐アドレスが第３３ビット位置の１により接頭され、予圧縮される。圧縮されると、全ての分岐アドレスが第０ビット位置の１により接尾される。ビット０の１はパケットを分岐アドレスとして識別し、ビット３３の１はＡＲＭおよびＴｈｕｍｂアドレスを区別するのを助けるために使用される。ＡＲＭアドレスは語整列（ｗｏｒｄ ａｌｉｇｎｅｄ）しなければならないため、ＡＲＭアドレスのビット［３１：２］だけが同報される。Ｔｈｕｍｂアドレスは半語制限されるためビット［３１：１］だけ同報すればよい。組み合わされたＡＲＭおよびＴｈｕｍｂアドレスに対して異なるビット数を同報し第３３ビットが常に表明された予圧縮を有することにより、ＡＲＭおよびＴｈｕｍｂ状態間の遷移で完全な５バイトアドレスが同報されることを保証する。さらに、下記の表に示すように、ＡＲＭおよびＴｈｕｍｂアドレスは第５アドレスバイトの高次ビットにより常に一意的に識別することができる。
【表８】

【０１２７】
存在すれば、分岐目的アドレスは常に所与のサイクルでＦＩＦＯ内へ置かれる最後のアイテムである。したがって、パケット連続ビット（Ｃビット）は不要である。理由コードはＴＦＯパケットヘッダーの一部として与えられるため、もはや第５バイト内のアドレスビット６：４で同報されず、それは５．４章で検討されている。第５バイトのビット６は例外分岐アドレス（上表に‘Ｅ’で示される）を示すのに使用される。このビットは中断、割込み、またはソフトリセットにより任意の分岐上にセットされる。これはこれらの割り込まれた命令が実際には実行されなかったことを伸張器が認識してユーザに示すことができるようにするのに有用である。第５アドレスバイトのビット７およびビット５は将来使用するために保存されたままである。
【０１２８】
１．２２．２ 正規データ
正規データヘッダーはキャッシュ内でミスしない全ロードおよびストアデータパケットに対して使用される。ＣＰＲＴデータトレーシングがイネーブルされれば、それはＣＰＲＴデータパケットにも使用される。データアドレストレーシングがイネーブルされれば、データアドレスはヘッダーパケットの後で、存在する場合の、データ値の前に同報される。データアドレスは命令分岐アドレスと同じ圧縮技術を使用して同報され、したがって１−５バイトからなっている。従来のＥＴＭインプリメンテーションに対してそうであるように、データアドレスがトレースされるかどうかはトレーシングを開始する前に静的に決定しなければならない。単一サイクル内で２つの正規のデータパケットが与えられる（６４ビットデータ転送により）場合には、第１のパケットだけがデータアドレスを含んでいる。ＬＳＭ命令に対するデータが同報される場合には、後続データパケットは異なるサイクルで転送されても、データアドレスは第１のデータパケットだけで同報される。正規データヘッダー内の‘Ａ’ビットはそれが特定の命令に対する第１のデータパケットであることを指定するのに使用され、したがって、データアドレスを予期しなければならない（アドレストレーシングがイネーブルされる場合）。この情報をヘッダーバイト内で利用できることにより、コードの伸張できないセクション（すなわち、２進が利用できない任意の領域）をトレーシングする時に伸張器は同期を維持することができる。‘Ａ’ビットはＣＰＲＴパケット上に表明されない。
【０１２９】
正規のデータ符号化における‘ＭＳＳ’ビットはデータ値圧縮に使用される。Ｍビットがローであれば、ＳＳビットは転送されるデータ値のサイズを指定する。データ圧縮の単純な形式として先導するゼロが除去される。予備実験はこの圧縮技術によりおよそ２０−３０％の圧縮が得られことを示しており、それはヘッダーバイトの追加帯域幅コストをオフセットするのに十分である。Ｍビットセットによる符号化は将来の圧縮技術のために保存される。ＭＳＳビットに対する正確な符号化は下記の表に与えられる。
【表９】

【０１３０】
１．２２．３ ロードミス
Ｌｏａｄ Ｍｉｓｓ ＯｃｃｕｒｒｅｄおよびＬｏａｄ Ｍｉｓｓ Ｄａｔａヘッダータイプはデータキャッシュ内でミスするロード要求を処理する。ロードミスが生じると、データ値が予期されるＦＩＦＯ内にＬｏａｄ Ｍｉｓｓ Ｏｃｃｕｒｒｅｄパケットが置かれる。データアドレストレーシングがイネーブルされると、パケットはデータアドレスを含む。そうでなければ、パケットはＬｏａｄ Ｍｉｓｓ Ｏｃｃｕｒｒｅｄヘッダーバイトだけからなる。Ｌｏａｄ Ｍｉｓｓ Ｏｃｃｕｒｒｅｄパケットが読み出されると、伸張ソフトウェアはデータ値が顕著なミスであることを知り、それは後で戻される。データが戻されると、そのサイクルに対するＰＩＰＥＳＴＡＴ値は‘＋ＤＡＴＡ’バージョンへ修正され、Ｌｏａｄ Ｍｉｓｓ Ｄａｔａヘッダーバイトおよび実際のデータ値からなるＬｏａｄ Ｍｉｓｓ ＤａｔａパケットがＦＩＦＯ内に置かれる。Ｌｏａｄ Ｍｉｓｓ Ｄａｔａパケットはデータアドレスを含むことはない。ロード／ストアユニットはＬｏａｄ Ｍｉｓｓデータへ戻るフリーサイクルを持たなければならないため、このデータはもう一つのロードまたはストア要求に対するデータと同じサイクル内に戻されることはない。
【０１３１】
Ｌｏａｄ Ｍｉｓｓヘッダータイプ内の‘ＴＴ’ビットは各ロードミスを識別するためのタグとして使用される。Ｌｏａｄ Ｍｉｓｓ Ｏｃｃｕｒｒｅｄパケットは常にその対応するＬｏａｄ Ｍｉｓｓ Ｄａｔａパケットと同じタグ値を有する。ＡＲＭ１０２０Ｅは一時に一つの顕著なＬｏａｄ Ｍｉｓｓしかサポートしないが、第１のミスに対するデータが戻さされる前に第２のロードミスパケットを同報することができる。したがって、全てのロードミスを一意的に識別するために、タグ値２’ｂ００および２’ｂ０１がＥＴＭ１０ ｒｅｖ０上でサポートされる。より多くの顕著なミスを許すことができる将来のプロセッサをサポートするためにタグフィールドに２ビットが割り当てられている。さらに、ＡＲＭ１０２０Ｅは常にミスデータを順に戻すが（他のロードミスに対して）、このタギング機構は狂った順でミスデータを戻すことができる将来のプロセッサをサポートする。
【０１３２】
６４ビットロード値上でミスが生じる場合には、同じサイクル内でＦＩＦＯ内に２つのＬｏａｄ Ｍｉｓｓパケットが置かれる。両パケットが同じタグ値を有しかつ同じサイクル内でＦＩＦＯ内に置かれるため、伸張器はこれら２つのミスは単一６４ビット値に対するものであることを知る。正規のデータパケットと同様に、データアドレスは第１のＬｏａｄ Ｍｉｓｓパケットだけで存在し、既にデータパケットを同報しているＬＳＭの中間でミスが生じる場合には存在しない。６４ビットのケースに対してＬｏａｄ Ｍｉｓｓデータが戻される場合には、それは常に同じサイクル内に与えられる２つの別々のＬｏａｄ Ｍｉｓｓ Ｄａｔａパケットとして戻される。両方のパケットが同じミスタグを有する。
【０１３３】
ロードミスデータパケットはサイズ情報に対するＭＳＳビットおよび正規のデータに対して行われるデータ圧縮を使用する。伸張器が予期せぬＬｏａｄ Ｍｉｓｓデータパケットを受信する場合（すなわち、同じタグを有するペンディングミス発生パケット無しでミスデータパケットが与えられる）、それはサイズ内に与えられた指定されたバイト数にわたってスキップしなければならない。顕著なミスデータが戻される前にトレースがディセーブルされる場合には、このデータアイテムは利用できるようになり次第‘ＤＷ’ＰＩＰＥＳＴＡＴを有するＦＩＦＯ内に置かれる。オーバフローまたはエグジットしたデバッグの理由コードによりトレースがイネーブルされる場合、伸張器は任意のペンディングＬｏａｄ Ｍｉｓｓパケットをキャンセルしなければならない。
【０１３４】
１．２２．４ 補助および完全可視性データトレーシング
補助および完全可視性データヘッダー符号化はプロトコル内の拡張性のために取っておく保存されたスロットである。これらのパケットタイプはプロセッサ内部および外部の補助データをトレーシングするのに使用することができる（完全可視性は全レジスタファイル更新をトレーシングすることである）。他のデータパケットと同様に、補助データパケットはサイズ情報に対するＳＳビットを利用する。完全可視性データトレーシングはさらなる圧縮のためのＭビットもサポートする。これらのパケットタイプはＥＴＭ１０ｒｅｖ０上で使用されない。
【０１３５】
１．２２．５ ＣｏｎｔｅｘｔＩＤ
Ｃｏｎｔｅｘｔ ＩＤヘッダーバイトはＣｏｎｔｅｘｔ ＩＤがＣｏｎｔｅｘｔ ＩＤ更新命令、ＭＣＲ ｃ１５，０，ｒｄ，ｃ１３，ｃ０，１を介して修正される時だけ使用される。データ値のサイズはＥＴＭ１０コントロールレジスタ（レジスタ０×０，ビット［１５：１４］）内に指定されたＣｏｎｔｅｘｔ ＩＤサイズにより静的に決定される。新しい値が指定されたバイト数よりも大きい場合でも、指定されたバイト数だけがトレースされる。サイズがゼロとして指定される場合には、Ｃｏｎｔｅｘｔ ＩＤ更新はトレースされない。たとえＣｏｎｔｅｘｔ ＩＤ更新命令がＭＣＲであっても，Ｃｏｎｔｅｘｔ ＩＤ値トレーシングは他のＣＰＲＴ命令からのトレーシングデータ値から完全に独立している。それはＥＴＭ１０コントロールレジスタ（レジスタ０×０，ビット［１］）内のＭｏｎｉｔｏｒ ＣＰＲＴビットにより影響されない。Ｃｏｎｔｅｘｔ ＩＤ更新に対する一意的ヘッダー値を使用することにより伸張器は伸張不能なコード領域（すなわち、２進が利用できない任意の領域）をトレーシングする場合であってもＣｏｎｔｅｘｔ ＩＤ変更を認識することができる。
【０１３６】
１．２２．６ トレースされない値
従来のＥＴＭインプリメンテーションはＬＳＭ操作に対してデータ値を全てトレースできるかどれもトレースできないかだけであり、この判断は最初の転送時になされている。今日のコンパイラーは隣接するＬＤＲ／ＳＴＲ操作を結合してユーザに最も気付かれないＬＳＭとするため、この動作は望ましくない。Ｖａｌｕｅ Ｎｏｔ Ｔｒａｃｅｄパケットの追加により、我々はＬＳＭを部分的にトレースしてトリガー基準に厳密にマッチするデータ値しか出力しない能力を追加した。
【０１３７】
ＬＳＭに関連する第１のデータ値がトレースされる時は常に、データアドレス（アドレストレーシングがイネーブルされる場合）およびデータ値（データ値トレーシングがイネーブルされる場合）を含むＦＩＦＯ内に正規のデータパケットが置かれる。このＬＳＭに対する全ての後続データ転送によりＦＩＦＯ内にパケットが置かれる。後続する値がトレースされる場合には、データ値だけを与える正規のデータパケットがトレースされる。後続データ転送をトレースしてはならない場合には、これらの転送に対してＦＩＦＯ上にＶａｌｕｅ Ｎｏｔ Ｔｒａｃｅｄパケットが置かれる。Ｖａｌｕｅ Ｎｏｔ ＴｒａｃｅｄパケットはＶａｌｕｅ Ｎｏｔ Ｔｒａｃｅｄヘッダーバイトだけからなっている。次に、伸張ソフトウェアは正規のデータパケットと組み合わせてＶａｌｕｅ Ｎｏｔ Ｔｒａｃｅｄパケットを使用して、最終データ転送から後ろ向きに進むことによりどのＬＳＭ値がトレースされどれがトレースされていないかを確認する。前記したように、ＬＳＭ命令上でトレーシングが開始すると、命令が完了する前にＴｒａｃｅＥｎａｂｌｅが表明停止されても、それはＬＳＭが完了するまで続くことをお判り願いたい。
【０１３８】
１．２２．７ 保存
データヘッダー符号化内に残っている合計１０の保存されたスロットがある。これらのスロットは全て必要に応じてプロトコルを強化するためおよび／または将来のＥＴＭインプリメンテーションに使用するために利用することができる。将来のＥＴＭインプリメンテーションによりさらに多くのヘッダータイプが必要とされる場合でも、Ｎｏｒｍａｌ ＤａｔａおよびＦｕｌｌ−Ｖｉｓｉｂｉｌｉｔｙ Ｔｒａｃｅ符号化内のＭビットは圧縮の替わりに新しいデータヘッダー符号化のために使用することもできる。
【０１３９】
１．２３ ＴＦＯパケットヘッダー符号化
ＴＦＯパケットはＴＦＯサイクルによりＦＩＦＯ内に置かれる（５．２．４章に記載されている）。伸張器はＴＦＯによりいつパケットがＦＩＦＯ内に置かれるを知るため、ＴＦＯパケットはそれ自体のヘッダーバイト符号化を有し、それらはＰＩＰＥＳＴＡＴデータパケットにより使用される符号化スペースから完全に独立している。ＴＦＯパケットヘッダー符号化を下記に示す。
【表１０】

【０１４０】
１．２３．１ 命令アドレス
ＴＦＯパケットの第１バイトに対してＴＲＡＣＥＰＫＴ［１：０］！＝２’ｂ１０であれば、このＴＦＯパケットは命令アドレスだけからなっている。完全なアドレスが常に必要とされるため、圧縮は試みられずアドレスは常に４−バイト値として出力される。アドレスのビット０はそれがＴｈｕｍｂまたはＡＲＭ命令アドレスであるかどうかを指定する。ＴＦＯパケットが命令アドレスだけからなる場合、それは、
・ＣＯＮＴＥＸＴ ＩＤ値がトレースされない（ＣｏｎｔｅｘｔＩＤＳｉｚｅ，ＥＴＭ Ｃｏｎｔｒｏｌレジスタビット［１５：１４］により決定される）
・ＴＦＯ理由コードは２’ｂ００，正規同期である
ことを意味する。
理由コードが非ゼロであるかあるいはＣＯＮＴＥＸＴ ＩＤ値がトレースされる場合には、下記のＴＦＯパケットの中の１つが必要である。アドレスだけからなるＴＦＯパケットはプロトコルコンライアンスを厳密には要求されずＥＴＭ１０
ｒｅｖ０上でインプリメントされない。
【０１４１】
１．２３．２ 正規ＴＦＯパケット
正規ＴＦＯパケットはＣＯＮＴＥＸＴ ＩＤの０−４バイトが続き、４−バイト命令アドレスが続くヘッダーバイトからなる。トレースされるＣＯＮＴＥＸＴＩＤバイト数はＥＴＭ Ｃｏｎｔｒｏｌレジスタビット［１５：１４］により静的に決定される。命令アドレスは常に４バイトであり圧縮はされない。ビット０はＴｈｕｍｂビットを指定する。ＴＦＯヘッダーバイトは２−ビット理由コードを含んでいる（前記表においてＲＲとラベルが付されている）。これらの理由コードはプロトコルバージョン０および１においてＥＴＭ７およびＥＴＭ９により使用されるものと一致している。理由コードは下記の表に与えられる。
【表１１】

【０１４２】
１．２３．３ Ｐｒｏｇｒｅｓｓ ＴＦＯパケット内のＬＳＭ
Ｐｒｏｇｒｅｓｓパケット内のＬＳＭはマルチメモリアクセス命令（ＬＤＭ，ＳＴＭ，ＬＤＣ，またはＳＴＣ）の中間でトレースがイネーブルされ、もう一つの命令が現在実行している時だけ生じる。これらのパケットはＣＯＮＴＥＸＴ ＩＤの０−４バイトが続き、ＬＳＭに対する４−バイト命令アドレスが続き、現在実行している命令に対する圧縮されたアドレスの１−５バイトが続くヘッダーバイトからなる。ＬＳＭ命令はビット０がＴｈｕｍｂビットを指定する固定４−ビットアドレスである。現在命令アドレスが分岐アドレスと同じ技術を使用して圧縮される（５．３．１章に指定されているように）。最後の命令アドレスはＬＳＭ命令からの完全なアドレスに関して圧縮される。次の命令ＰＩＰＥＳＴＡＴは第２のアドレスにより指示された命令に対するものであり、トレースはこの点から順方向に正規の方法で開始する。このパケットタイプは特定のデータアドレスまたはデータ値に接触する全ての命令を適切にトレーシングするために必要である。それがないと、ＬＳＭ命令はデータアドレスに基づいて適切にトレースすることができない。たとえトレーシングがＬＳＭ自体の間しかターンオンされないようにプログラムされていても、ＬＳＭの下で生じる命令はトレースされることをお判り願いたい。同様に、たまたまＬＳＭの下で実行するばかりの命令の命令アドレスによりトレースがターンオンされる場合には、Ｐｒｏｇｒｅｓｓ ＴＦＯパケット内のＬＳＭはまだ出力される。Ｎｏｒｍａｌ ＴＦＯパケットとＬＳＭ ｉｎ Ｐｒｏｇｒｅｓｓ ＴＦＯパケットとの間の違いをさらに明瞭にするために、下記の表は各ケースに対して予期すべきバイトを示している。
【表１２】

【０１４３】
ＡＲＭ１０ ＴＲＡＣＥインターフェイス
この章はＡＲＭ１０２０ＥとＥＴＭ１０間の信号インターフェイスについて説明する。大部分のインターフェイスはＡＲＭ１０２０ＥによりＥＴＭ１０内へ駆動される。信号記述はカスタムデータパス入力、合成制御入力、およびＥＴＭ出力へ分割される。合成制御信号は後で変更することができるが、データパス信号変更にはカスタム論理リワークが必要であるため、これらは設計の遅い時期に変更することができない。全入力がＥＴＭ１０のすぐ内側に記憶され、全出力がレジスタの出力から直接駆動される。インターフェイスは合計２２０の信号からなり、それは２１３の入力およびＥＴＭ１０配景からの４出力を含んでいる。
【０１４４】
１．２４ ＥＴＭ Ｄａｔａｐｔｈ入力
ＥＴＭデータトレーシングに対して関心のある４つのデータバス、ロードデータ、ストアデータ、ＭＣＲデータ、およびＭＲＣデータがある。これら４つのバスの全てが６４ビット幅である。任意所与のサイクルにおいてこれらのバスの１つしか有効データを含まないことがあるため、４つのバス全てがＡＲＭ１０２０Ｅ内で台なしにされて６４ビットデータバスＥＴＭＤＡＴＡとなってしまう。ＥＴＭＤＡＴＡはＡＲＭ１０２０Ｅ内に記憶された後でＥＴＭへ駆動される。ＥＴＭＤＡＴＡはＡＲＭ１０２０Ｅパイプラインのライト（ＷＲ）段階で有効である。ＡＲＭ１０２０ＥからＥＴＭ１０へ駆動される４つのアドレスバスがある。これらのバスの中の３つは命令アドレス用であり１つはデータアドレス用である。ＩＡおよびＤＡアドレスバスがメモリ（ＭＥ）段階で有効である間にＲ１５バスはＡＲＭ１０２０Ｅパイプラインの実行（ＥＸ）段階でＥＴＭへ駆動される。ＥＴＭへ駆動される全データバスが下記の表に与えられている。
【表１３】

【０１４５】
１．２５ ＥＴＭ制御入力
１．２５．１ ＥＴＭＣＯＲＥＣＴＬ［２３：０］
ＥＴＭＣＯＲＥＣＴＬは全てがＡＲＭ１０コアから来る多様な制御信号を含んでいる。これらの信号は全てコア内に記憶され、この共通バス上に結合されてからＥＴＭ１０へ駆動される。このバス上に存在する制御信号とそれらの意味は下記の表に与えられている。特記なき限り、これらの全てがＡＲＭ１０２０Ｅパイプラインのライト段階（ＷＲ）において有効である。
【表１４】

【０１４６】
１．２５．２ ＥＴＭＤＡＴＡＶＡＬＩＤ［１：０］
この信号はバスＥＴＭＤＡＴＡ［６３：０］上で駆動されるデータを限定する。データバスの半分毎に１ビットがある。
【０１４７】
１．２６ ＥＴＭ出力
この章はＡＲＭ１０２０Ｅ内へ帰還されそこから要求される出力について説明する。
【０１４８】
１．２６．１ ＦＩＦＯＦＵＬＬ
イネーブルである時に、ＦＩＦＯ内に置かれたバイトがある時は常にＥＴＭ出力ＦＩＦＯＦＵＬＬが表明され、ＦＩＦＯが空になるまで表明されたままである。この動作は、ＦＩＦＯＦＵＬＬを表明する前にＦＩＦＯがある特定レベルに達するまで待機した、ＥＴＭ７／９とは幾分異なる（４．１６章参照）。ＦＩＦＯＦＵＬＬはＡＲＭパイプラインを停止するために、ここではＡＲＭ１０２０Ｅである、コアにより使用される。これはＥＴＭオーバフローを防止し、イベントのタイミングを幾分変える副作用がコア内で生じるが完全なトレースを保証する。タイミングを考慮するため、ＦＩＦＯＦＵＬＬの表明によりＡＲＭ１０２０Ｅが即座に停止することがない。したがって、まれではあるが、ＦＩＦＯＦＵＬＬが表明される時でもオーバフローを有することがありうる。これが生じると、ＦＩＦＯが徐々に空になる間プロセッサは停止したままであるため（ＦＩＦＯＦＵＬＬ表明により）、ミスした命令数は少ない。
【０１４９】
１．２６．２ ＰＷＲＤＯＷＮ
ハイであれば、これはＥＴＭが現在イネーブルされておらずＣＬＫ入力は停止できることを示す。これはトレースが使用されない時に消費電力を低減するのに使用される。リセットされると、ＥＴＭ１０がプログラムされてしまうまでＰＷＲＤＯＷＮが表明される。ＡＲＭ１０２００テストチップはＥＴＭ１０ ＣＬＫ入力をゲートするのに直接ＰＷＲＤＯＷＮ出力を使用しなければならない。前記したように、ＰＷＲＤＯＷＮはＣＯＮＴＥＸＴ ＩＤ更新上で一時的にディセーブルされてＥＴＭ１０の内部ＣＯＮＴＥＸＴ ＩＤシャドーレジスタ上の更新を考慮する。ＣＯＮＴＥＸＴ ＩＤ更新ケースを除けば、ＰＷＲＤＯＷＮはＴＣＬＫに同期して変更されデバッグセッションの始めにＡＲＭデバッグツールによりクリアされる。ＰＷＲＤＯＷＮ変更はトレースがイネーブルされる前に巡回するため、ＥＴＭ１０ ＣＬＫをゲートするのにＴＣＬＫベース信号を使用してもメタ安定性問題は生じない。
【０１５０】
１．２６．３ ＤＢＧＲＱ
従来のＥＴＭと同様に、ＥＴＭ１０はトリガー状態が生じる時は常にＤＢＧＲＱを表明するようにプログラムすることができる。ＤＢＧＲＱはＤＧＢＡＣＫが観察されるまで表明されたままとされる。ＤＢＧＲＱははＡＲＭ１０２０Ｅ外部デバッグ要求ピンＥＤＢＧＲＱに接続しなければならない。このＥＴＭ出力にはＡＲＭ１０２０Ｅからの余分なサポートは不要である。ＡＳＩＣ内の他の機能ブロックによりＥＤＢＧＲＱ入力が既に使用されている場合には、多数のＤＢＧＲＱ信号を一緒にＯＲすることができる。デバッグをこのようにイネーブルしても任意特定の命令境界に遭遇することは保証されないことをお判り願いたい。さらに、ＡＲＭ１０が現在ハードウェアデバッグモードであればコアはＥＤＢＧＲＱを認識するだけである。
【０１５１】
１．２６．４ ＴＤＯ
ＥＴＭ１０は従来のＥＴＭバージョンと同じＴＡＰインターフェイス配線を使用する。ＴＤＯピンがＡＲＭ１０２０Ｅ走査拡張入力ＳＤＯＵＴＢＳに接続されている。ＥＴＭ１０レジスタは走査チェーン６を介してアクセスされ従来のＥＴＭインプリメンテーションと同じ方法でプログラムされる。このＥＴＭ出力にはＡＲＭ１０２０Ｅからの余分なサポートは不要である。
【０１５２】
構成
ＥＴＭ７／９は小型、中型および大型構成で入手することができる。中型および大型構成は追加エリアのコストでより多くのトリガーハードウェアリソースおよび増大されたＦＩＦＯ深さを提供する。新しい構成のソフトマクロを単純に再合成するだけでさまざまなＡＳＩＣアプリケーションに対するさまざまな構成を選択することができる。ＥＴＭ１０は同様な構成範囲を提供する。下記の表はＥＴＭ１０に対して現在提示されている構成を示す。大概のトリガーリソースはＥＴＭ７およびＥＴＭ９と同じであるが、６４ビット比較器の大きなサイズにより８から４へ減少された大型構成のデータ比較器は例外である。各構成における増大したＦＩＦＯサイズはＡＲＭ１０２０Ｅのより高い命令スループット（すなわち、性能）をサポートする必要性を反映している。各構成に対するＦＩＦＯサイズはエリアインパクトおよび性能モデリングからの帰還に基づいて増加することができる。ＥＴＭ１０構成に対して与えられるゲートカウントはＥＴＭ１０ ｒｔ１モデルの初期合成に基づいた推定値である。これらの推定されたゲートカウントは最終インプリメンテーションにより達成されるものとは異なることがある。大きなサイズのＥＴＭ１０はＡＲＭ１０２００テストチップ上に置かれるものである。各カテゴリ内のＥＴＭ９に対する対応するリソース数が比較のために括弧内に与えられている。
【表１５】

【０１５３】
特定の実施例について説明してきたが、本発明はそれに限定されるものではなく、発明の範囲内で多くの修正および追加を行えることは明らかである。例えば、本発明の範囲を逸脱することなく従属項の特徴を独立項の特徴とさまざまに組み合わせることができる。
【図面の簡単な説明】
【図１】オンチップトレーシング機構を提供するデータ処理システムを示す略図である。
【図２】図１のオンチップトレースモジュール内に設けられる素子の詳細を示すブロック図である。
【図３】命令セット情報に命令アドレスを取り入れるために本発明の好ましい実施例において使用される符号化を示す略図である。
【図４】図３に示す方法に従って符号化されたアドレスが本発明の好ましい実施例に従ってどのように圧縮されるかを示す略図である。
【図５】３命令系列の例に対する圧縮論理の出力を示す略図である。
【図６】本発明の好ましい実施例に従って使用される符号化および圧縮論理を略示するブロック図である。
【図７】図６の３３−ビットセクターの動作を示す略図である。
【図８】図６に示す比較器の１つの構造を示す略図である。
【図９】図６に示す連続ビット発生器を実現するために好ましい実施例で使用される論理を示す図である。
【図１０】好ましい実施例の圧縮符号化命令アドレス発生器により実施されるプロセスを示す略図である。
【符号の説明】
２ データ処理システム
４ 集積回路
６ マイクロプロセッサコア
８ キャッシュメモリ
１０ オンチップトレースモジュールコントローラ
１２ オンチップトレースバァッファ
１４ 外部メモリ
１６ 汎用コンピュータ
１８ 外部記憶装置
１００ 同期論理
１１０ トリガー
１２０ 制御論理
６１０，８００，８２０ レジスタ
６２０ ３３−ビットセクター論理
６３０ ラッチ
６２２，６２３，６２４，６２５ ７−ビット幅バス
６４０，６５０，６６０，６７０ 比較器
６８０ 連続ビット発生器
６９０ 圧縮符号化命令アドレス発生器
７００ マルチプレクサ
８３０ 比較器論理
９１０，９２０，９３０ ＯＲゲート

Claims (22)

1. データ処理装置であって、前記装置は、
   処理命令の複数の命令セットのいずれかからの処理命令を実行する処理回路であって、各処理命令はメモリ内でのその処理命令の場所を識別する命令アドレスにより指定され、命令アドレスは関連する処理命令が属する命令セットに無関係に予め定められたビット数を有するが、異なる命令セット内の処理命令を一意的に識別する命令アドレス内に異なる数の最上位命令アドレスビットを指定する必要がある処理回路と、
   その命令に対応する命令セットの表示を有する少なくとも１つの命令アドレスを符号化してn-ビット符号化命令アドレスを発生する符号化論理であって、前記符号化論理は指定される必要のある命令アドレスビットを形成しない任意の最下位ビットを除去し、指定された命令アドレスビットへビットパターンをプリペンドすることにより指定された命令アドレスビットをn-ビットへ拡張するのと等価の計算を実施することにより符号化を実施するようにされており、除去される最下位ビット数およびプリペンドされるビットパターンはその命令に対応する命令セットによって決まる符号化論理と、
   を含む装置。
2. 請求項１記載の装置であって、符号化論理は処理回路のアクティビティをトレースするのに使用されるトレースモジュール内に設けられる装置。
3. 請求項１記載の装置であって、各命令セットに対してその命令セットからの命令アドレスの指定された命令アドレスビットへプリペンドされたビットパターンはシフトされたパターンにより異なる命令セットの命令アドレスの指定された命令アドレスビットへプリペンドされたビットパターンと関連づけられる装置。
4. 請求項１記載の装置であって、符号化論理は命令アドレスの指定された命令アドレスビットへ予め定められたビットパターンをプリペンドし次に符号化命令アドレスとして中間値からｎビットを選択することにより中間値を発生するのと等価の計算を実施することにより符号化を実施するようにされている装置。
5. 請求項１記載の装置であって、さらに、その符号化命令アドレスを複数のｘ-ビットセクションへ分割し、各ｘ-ビットセクションを先行する符号化命令アドレスの対応する各ｘ-ビットセクションと比較し、圧縮符号化命令アドレスとして先行する符号化命令アドレスの対応するｘ-ビットセクションとは異なる最上位ｘ-ビットセクションを任意のより下位のｘ-ビットセクションと共に出力するのと等価の計算を実施することにより前記符号化命令アドレスを圧縮する圧縮論理を含む装置。
6. 請求項５記載の装置であって、圧縮論理はそこから出力される各ｘ-ビットセクションにｘ-ビットセクションが圧縮符号化命令アドレスとして出力される最後のｘ-ビットセクションであるかどうかを示すフラグを関連づけるようにされている装置。
7. 請求項６記載の装置であって、複数のｘ-ビットセクションが圧縮論理から出力される場合には、複数のｘ-ビットセクションは最下位ｘ-ビットセクションで開始して逐次出力される装置。
8. 請求項６記載の装置であって、圧縮論理は、さらに、圧縮論理から出力される各ｘ-ビットセクションをｙビットへ拡張するようにされており、最上位ｙ-ｘビットはフラグを含む装置。
9. 請求項８記載の装置であって、フラグは単一ビットである装置。
10. 請求項９記載の装置であって、ｙは８でありｘは７である装置。
11. 請求項１記載の装置であって、符号化論理は中間値を受信するｎ-ビットセクター論理ユニットおよび中間値内に含まれる命令アドレスに関連づけられた命令セットを識別する識別子信号を含み、ｎ-ビットセクターは識別子信号に応じて中間値の予め定められたｎ-ビットを出力するようにされている装置。
12. 請求項５記載の装置であって、圧縮論理は複数の比較器を含み、各比較器が符号化命令アドレスの対応するｘ-ビットセクションを受信するようにされており、かつ先行する符号化命令アドレスの対応するｘ-ビットセクションを格納する一時記憶装置を含み、比較器は２つのｘ-ビットセクションを比較して２つのｘ-ビットセクションが異なる場合にセットされる差信号を発生するようにされている装置。
13. 請求項１２記載の装置であって、圧縮論理は、さらに、より高位のｘ-ビットセクションも出力される場合に特定のｘ-ビットセクションに対するフラグがセットされるように、複数の比較器により発生される差信号の予め定められた組合せに基づくフラグを圧縮論理から出力される各ｘ-ビットセクションに対して発生するようにされている装置。
14. 請求項１３記載の装置であって、圧縮論理は、さらに、出力される各ｘ-ビットセクションにその対応するフラグをプリペンドすることにより圧縮符号化命令アドレスを発生し、出力圧縮符号化命令アドレスとして一列のｙ-ビットセクションを発生する出力発生器を含む装置。
15. 請求項５記載の装置であって、符号化論理および圧縮論理は処理回路のアクティビティをトレースするのに使用されるトレースモジュール内に設けられる装置。
16. データ処理装置用トレーシングツールであって、データ処理装置は処理命令の複数の命令セットのいずれかからの処理命令を実行する処理回路を有し、各処理命令はメモリ内のその処理命令の場所を識別する命令アドレスにより指定され、命令アドレスは関連する処理命令が属する命令セットに無関係に予め定められたビット数を有するが、異なる命令セット内の処理命令を一意的に識別する命令アドレス内に異なる数の最上位命令アドレスビット数を指定する必要があり、前記トレーシングツールは、
    その命令に対応する命令セットの表示を有する少なくとも１つの命令アドレスを符号化してｎ-ビット符号化命令アドレスを発生する符号化論理を含み、前記符号化論理は指定される必要のある命令アドレスビットを形成しない任意の最下位ビットを除去し、指定された命令アドレスビットにビットパターンをプリペンドすることにより指定された命令アドレスビットをｎ-ビットへ拡張するのと等価の計算を実施することにより符号化を実施するようにされており、除去される最下位ビット数およびプリペンドされるビットパターンはその命令に対応する命令セットによって決まるトレーシングツール。
17. 請求項１６記載の装置であって、さらに、符号化命令アドレスを複数のｘ-ビットセクションへ分割し、各ｘ-ビットセクションを先行する符号化命令アドレスの対応するｘ-ビットセクションと比較し、圧縮符号化命令アドレスとして先行する符号化命令アドレスの対応するｘ-ビットセクションとは異なる最上位ｘ-ビットセクションを任意のより下位のｘ-ビットセクションと共に出力することと等価の計算を実施することにより符号化命令アドレスを圧縮する圧縮論理を含むトレーシングツール。
18. 命令セット情報の格納方法であって、処理回路が処理命令の複数の命令セットのいずれかからの処理命令を実行するようにされており、各処理命令はメモリ内のその処理命令の場所を識別する命令アドレスにより指定され、命令アドレスは関連する処理命令が属する命令セットに無関係に予め定められたビット数を有するが、異なる命令セット内の処理命令を一意的に識別するために命令アドレス内に異なる数の最上位命令アドレスビット数を指定する必要があり、前記方法は、
    指定される必要のある命令アドレスビットを形成しない任意の最下位ビットを除去し、
    ビットパターンを指定された命令アドレスビットにプリペンドすることにより指定された命令アドレスビットをｎ-ビットへ拡張する、
    のと等価の計算を実施することにより、その命令に対応する命令セットの表示を有する少なくとも１つの命令アドレスを符号化してｎ-ビット符号化命令アドレスを発生するステップを含み、
    除去される最下位ビット数およびプリペンドされるビットパターンはその命令に対応する命令セットによって決まる方法。
19. 請求項１８記載の方法であって、さらに、
    （ａ）符号化命令アドレスを複数のｘ-ビットセクションへ分割し、
    （ｂ）各ｘ-ビットセクションを先行する符号化命令アドレスの対応するｘ-ビットセクションと比較し、
    （ｃ）圧縮符号化命令アドレスとして先行する符号化命令アドレスの対応するｘ-ビットセクションとは異なる最上位ｘ-ビットセクションを任意のより下位のｘ-ビットセクションと共に出力する、
    ことと等価の計算を実施することにより前記符号化命令アドレスを圧縮するステップを含む方法。
20. （ｉ）圧縮符号化命令アドレスを形成するｘ-ビットセクション数を決定し、
    （ｉｉ）先行する符号化命令アドレスの対応するｘ-ビットセクションから得られる追加ｘ-ビットセクションを取り入れることにより、必要に応じて圧縮符号化命令アドレスをｎ-ビットへ拡張して符号化命令アドレスを作り出す、
    のと等価の計算を実施することにより請求項１９記載の方法に従って発生される圧縮符号化命令アドレスを伸張する方法。
21. 請求項２０記載の方法であって、さらに、予め定められたビットパターンから命令アドレスが関連する命令セットを決定し、予め定められたビットパターンを除去して指定された命令アドレスビットを得るのと等価の計算を実施することにより符号化命令アドレスを復号するステップを含む方法。
22. 請求項１８記載の方法に従って装置を制御するようコンピュータに読み込まれ動作するコンピュータプログラム。

Images