JP3766035B2 - Apparatus and method for storing instruction set information - Google Patents

Description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【０１５３】
特定の実施例について説明してきたが、本発明はそれに限定されるものではなく、発明の範囲内で多くの修正および追加を行えることは明らかである。例えば、本発明の範囲を逸脱することなく従属項の特徴を独立項の特徴とさまざまに組み合わせることができる。
【図面の簡単な説明】
【図１】オンチップトレーシング機構を提供するデータ処理システムを示す略図である。
【図２】図１のオンチップトレースモジュール内に設けられる素子の詳細を示すブロック図である。
【図３】命令セット情報に命令アドレスを取り入れるために本発明の好ましい実施例において使用される符号化を示す略図である。
【図４】図３に示す方法に従って符号化されたアドレスが本発明の好ましい実施例に従ってどのように圧縮されるかを示す略図である。
【図５】３命令系列の例に対する圧縮論理の出力を示す略図である。
【図６】本発明の好ましい実施例に従って使用される符号化および圧縮論理を略示するブロック図である。
【図７】図６の３３−ビットセクターの動作を示す略図である。
【図８】図６に示す比較器の１つの構造を示す略図である。
【図９】図６に示す連続ビット発生器を実現するために好ましい実施例で使用される論理を示す図である。
【図１０】好ましい実施例の圧縮符号化命令アドレス発生器により実施されるプロセスを示す略図である。
【符号の説明】
２ データ処理システム
４ 集積回路
６ マイクロプロセッサコア
８ キャッシュメモリ
１０ オンチップトレースモジュールコントローラ
１２ オンチップトレースバァッファ
１４ 外部メモリ
１６ 汎用コンピュータ
１８ 外部記憶装置
１００ 同期論理
１１０ トリガー
１２０ 制御論理
６１０，８００，８２０ レジスタ
６２０ ３３−ビットセクター論理
６３０ ラッチ
６２２，６２３，６２４，６２５ ７−ビット幅バス
６４０，６５０，６６０，６７０ 比較器
６８０ 連続ビット発生器
６９０ 圧縮符号化命令アドレス発生器
７００ マルチプレクサ
８３０ 比較器論理
９１０，９２０，９３０ ＯＲゲート[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a data processing apparatus. In particular, the present invention relates to a data processing apparatus and method for storing instruction set information.
[0002]
[Prior art]
The data processing apparatus can be provided with processing circuitry that can execute processing instructions from several different instruction sets. There are some situations where it is desirable to keep track of the processing performed by the processing circuitry, and in such situations it may be desirable to be able to identify which instruction set is being used at any given time. For example, such information is useful during the development of data processing systems, where it is often desirable to track processing circuit activity. An example of a tool that can be used to assist such a process is a tracing tool.
[0003]
Tracking the activity of a data processing system generates a trace stream containing data representing the activity of each step in the system, making it a very useful tool in system development. However, general movement towards deeper embedded processor cores makes it more difficult to track the state of the processor via externally accessible pins. Therefore, not only an off-chip tracing mechanism that captures and analyzes trace data but also an increased tracing function is arranged on-chip. An example of such an on-chip tracing mechanism is the embedded trace macrocell provided by ARM, Cambridge, UK in connection with ARM7 and ARM9 processors.
[0004]
Such a tracing mechanism creates in real time a trace stream of data representing the activity of the data processing system that is desired to be traced. This trace stream can then be used to facilitate debugging of processing instruction sequences executed by the data processing system.
[0005]
It is known to provide a tracing and debugging mechanism that incorporates trigger points that serve to control tracing and debugging operations such as starting or stopping tracing when a particular register, address or data value is accessed. Such a mechanism is very useful for diagnosing specific parts of the system or type of operation. As an example, if a particular system bug is associated with an exception behavior, the only thing that is really needed is the tracing of the exception behavior triggered when accessing the appropriate exception handling vector. Creates inconveniently large amounts of data.
[0006]
While it is also desirable to reduce the development time for new systems, there is a need to improve the debugging and tracing tools and mechanisms that can be used during the development of data processing systems due to the increased complexity of data processing systems.
[0007]
In situations where the processing circuitry can execute processing instructions from any of several different instruction sets, it is desirable for the tracing mechanism to keep track of that instruction set information as well. However, it is also desirable to reduce the amount of data that needs to be traced whenever possible.
[0008]
[Problems to be solved by the invention]
Accordingly, it is an object of the present invention to provide an efficient technique for storing such instruction set information.
[0009]
[Means for Solving the Problems]
Viewed from a first aspect, the present invention provides a data processing apparatus, wherein any of the plurality of sets of processing instructions each processing instruction is designated by an instruction address identifying the location of that processing instruction in memory. A processing circuit that executes a processing instruction from the above, which needs to specify a different number of instruction address bits in an instruction address for a processing instruction in a different instruction set, and display of the instruction set corresponding to the instruction Encoding logic that encodes an instruction address having a n-bit encoded instruction address, wherein the encoding logic is specified by prepending a bit pattern to the specified instruction address bits Encoding is performed by performing a calculation equivalent to extending the instruction address bits to n-bits. It is, bit patterns that are prepended being dependent on the instruction set corresponding to that instruction.
[0010]
In situations where multiple instruction sets can be used by a processing circuit in accordance with the present invention, it is known that it is often necessary to specify a different number of instruction address bits in an instruction address for instructions in different instruction sets. The present invention utilizes this to enable efficient encoding of instruction set information having an instruction address.
[0011]
In particular, a code that generates an n-bit encoded instruction address by performing a calculation equivalent to extending the specified instruction address bit to n-bit by prepending a bit pattern to the specified instruction address bit. And the prepended bit pattern depends on the instruction set corresponding to that instruction.
[0012]
As an example, consider a situation where an instruction address is specified by 32 bits. For the first instruction set, the instruction can start at any bit position in memory, so all 32 bits must be specified for the instruction address associated with this instruction set. However, for the second instruction set, instructions may be constrained to start at a subset of all available locations in memory, eg, every other bit position. Similarly, the third instruction set may be subject to different constraints on where the instructions can be placed in memory, for example every third bit position. In such a situation, it is clear that the least significant bit of the instruction address for instructions in the second and third instruction sets always has the same value and therefore does not need to be specified. For example, an instruction in the second instruction set can start at every other bit position in memory, and an instruction in the third instruction set can start at every third bit position in memory. Obviously, if possible, the least significant bit for the instruction address of the second instruction set can be ignored and the least significant 2 bits for the instruction address of the third instruction set can be ignored. Thus, it is clear that in this situation, it is necessary to specify a different number of instruction address bits for instruction addresses in different instruction sets, even if all are typically represented as 32-bit addresses. It is.
[0013]
It will be appreciated that there are a number of different ways in which the function of the encoding logic can be implemented. For example, each instruction address that is encoded can be right shifted by the appropriate number of bits depending on the instruction set with which the instruction is associated to separate only the instruction address bits that need to be specified, with different bit patterns being Prepended to an appropriately shifted instruction address to form an n-bit encoded instruction address.
[0014]
Thus, considering the previous example where the instruction address is specified by 32-bits, the instructions in the first instruction set must specify all 32 bits and the instructions in the second instruction set have 31 bits. Must be specified, instructions in the third instruction set must specify 30 bits, the instruction address associated with the first instruction set is not right-shifted, and the instruction address associated with the second instruction set It can be seen that 1 is right shifted by 1 bit and the instruction address associated with the third instruction set is right shifted by 2 bits. A different bit pattern can then be prepended to the shifted instruction address so that the encoded instruction addresses are the same length. Different bit patterns within the most significant bit positions of the encoded instruction addresses implicitly provide information about the instruction set with which these instruction addresses are associated.
[0015]
It can be seen that there is no need for correspondence between different bit patterns prepended depending on the instruction set. However, in the preferred embodiment, for each instruction set, the bit pattern prepended to the designated instruction address bit of the instruction address from that instruction set is assigned to the instruction address of the different instruction set by the shifted pattern. Associated with the bit pattern prepended to the instruction address bits. For example, given the precedent of three instruction sets, a bit pattern “1” can be added to the instruction address of the first instruction set and a bit pattern “01” can be added to the instruction address of the second instruction set. The bit pattern “001” can be added to the instruction address of the third instruction set.
[0016]
Obviously, any computation equivalent to generating the encoded instruction address described above can be used. For example, a predetermined bit pattern can be prepended to a designated instruction address bit to form an intermediate value, and then n bits are selected from the intermediate value as an encoded instruction address. Clearly, there are several different ways in which the n bits forming the encoded instruction address can be selected. For example, if all instruction addresses are represented by the same number of bits in the intermediate value regardless of the associated instruction set (ie, all address bits are included, not just the bits that need to be specified), the instruction address is associated Different selections of n bits are made depending on the instruction set to be performed. For example, considering the previous example, if the instruction address is associated with the third instruction set and the least significant 2 bits are irrelevant, the least significant bit of the n-bit selected as the encoded instruction address is the bit position. 2. Also, if only instruction address bits that need to be specified when generating an intermediate value are used, the encoded instruction address is always the lowest n of the intermediate value, regardless of which instruction the instruction address is associated with. Obviously, it is formed by selecting a bit.
[0017]
As noted above, the preferred embodiment of the present invention is a necessary and efficient technique for encoding instruction set information having instruction addresses, and therefore any implementation in which it is desirable to track instruction set information having instruction addresses. Provide useful technology in If there is a general desire to reduce the amount of data that is tracked whenever possible, it would be beneficial to provide a technique that more efficiently represents the encoded instruction address generated by the present invention.
[0018]
Thus, in a preferred embodiment, the apparatus further divides the encoded instruction address into a plurality of x-bit sections and compares each x-bit section with the corresponding x-bit section of the preceding encoded instruction address; Performs a calculation equivalent to output with any lower-order x-bit section, with the most significant x-bit section different from the corresponding x-bit section of the preceding encoded instruction address as the compressed encoded instruction address. Thus, compression logic for compressing the encoded instruction address is included. In the preferred embodiment, the least significant x-bit section is always output.
[0019]
Often, any particular instruction address is only slightly different from the previous instruction address, and therefore the most significant bits of the instruction address are often identical, which typically results in significant compression of the encoded instruction address. In accordance with the present invention, the most significant bit of the encoded instruction address implicitly identifies the instruction set used, but it varies fairly irregularly, so that the compression technique described above significantly compresses many encoded instruction addresses. I understand that I can do it.
[0020]
Furthermore, due to the way the encoded instruction address is generated, any unrelated address bits may be discarded, so this is the total instruction with the instruction address bits that need to be specified in the instruction address. It can be seen that it helps to improve the compression efficiency for any instruction address associated with an instruction set that is less than the number of address bits. Returning to the previous example, if the instruction address from instruction set 3 only needs to specify 30 bits, the least significant 2 bits of the instruction address are omitted before compression is applied, so this is It turns out to help increase efficiency.
[0021]
One potential problem with the compression technique described above is determining when each compressed encoded instruction address begins and ends, which is the number of x-bit sections that form each compressed encoded instruction address. This is because it varies depending on the degree of similarity with the preceding encoded instruction address of the specific encoded instruction address to be compressed.
[0022]
In order to solve this potential problem, in the preferred embodiment, the compression logic determines in each x-bit section output from it whether it is the last x-bit section output as a compression encoded instruction address. An associated flag is shown. In the preferred embodiment, when multiple x-bit sections are output from the compression logic, the multiple x-bit sections are output sequentially starting with the least significant x-bit section.
[0023]
It can be seen that the flags can be output as separate signals to each x-bit section as long as it can be determined which flag is associated with which x-bit section. However, in the preferred embodiment, the compression logic is further adapted to expand each x-bit section output therefrom to y bits, with the most significant y-x bits including a flag. Thus, in such a preferred embodiment, a flag is effectively included in each output section, such that the output from the compression logic is a y-bit section sequence in which the most significant xy bits contain the flag.
[0024]
As you can see, flags can be specified using any number of bits. However, in the preferred embodiment, the flag is a single bit. In particular, in the preferred embodiment, y is 8 such that the compression encoded instruction address includes an 8-bit section sequence where the most significant bit identifies whether the section is the last section of the compression encoded instruction address. x is 7.
[0025]
It can be seen that the encoding logic can take a variety of forms. For example, as described above, it can include shift logic that confirms an appropriate right shift in response to an indication of the instruction set and applies it to each input instruction address, if any. A predetermined bit pattern can then be prepended to an appropriately shifted instruction address, after which the least significant n-bit is output as the encoded instruction address. Given different right shifts applied depending on the instruction set, it can be seen that there are different bit patterns at the most significant bit position of the encoded instruction address depending on the instruction set with which the instruction address is associated.
[0026]
However, in the preferred embodiment, the encoding logic includes n-bit sector logic that receives an identifier signal that identifies an intermediate value and an instruction set associated with an instruction address contained within the intermediate value, where the n-bit sector is an identifier signal. In response to this, a predetermined n-bit of an intermediate value is output. In such an embodiment, it is contemplated that the intermediate value is generated without performing any right shift on the instruction address, and that an appropriate selection of n-bits from the intermediate value is made in response to the identifier signal. It can be seen that such a process generates the same encoded instruction address that is generated by performing an appropriate right shift of the individual instruction address followed by outputting the least significant n-bit.
[0027]
In the preferred embodiment, the compression logic includes a plurality of comparators, each comparator adapted to receive a corresponding x-bit section of the encoded instruction address, and further corresponding x of the preceding encoded instruction address. A temporary storage device for storing the bit sections, the comparator being adapted to compare the two x-bit sections and generate a difference signal which is set if they are different; In the preferred embodiment, the temporary storage takes the form of a register, which is also used to store the current x-bit section. The outputs from the two registers are then compared to generate the appropriate difference signal.
[0028]
Further, in the preferred embodiment, the comparison logic is adapted to generate a flag based on a predetermined combination of difference signals generated by a plurality of comparators for each x-bit section output from the compression logic. A flag for a particular x-bit section is set if a higher-order x-bit section is also output, including flag generator logic. Thus, in such an embodiment, the flag is set to indicate that another x-bit section follows that x-bit section, and the corresponding x-bit section is output as the compression-coded instruction address. If it is the last section, the flag is left unset. It should be understood that the flag generator logic can be formed by any suitable wiring of logic gates. However, in the preferred embodiment, an OR gate string is used to ensure that a flag for a particular x-bit section is set when the corresponding difference signal or the difference signal of a higher x-bit section is set. used.
[0029]
Preferably, the comparison logic further generates a compression encoded instruction address by prepending its corresponding flag to each output x-bit section, and generates a y-bit section sequence as the output compression encoded instruction address. Includes output generator. It will be appreciated that the output generator can be configured in various ways. However, in the preferred embodiment, the function of the output generator is implemented directly by the appropriate hard wiring of the flags generated by the flag generator logic and the corresponding x-bit section.
[0030]
It will be appreciated that the above-described encoding and compression logic of the present invention can be beneficially utilized in any implementation that wishes to track instruction set information having an instruction address. However, in the preferred embodiment, the encoding and compression logic is provided in a trace module used to track the activity of the processing circuit.
[0031]
Accordingly, in accordance with a second aspect of the present invention, a tracing tool for a data processing device is provided, the data processing device having a processing circuit for executing a processing instruction from any of a plurality of instruction sets of processing instructions, A processing instruction is specified by an instruction address that identifies the location of that processing instruction in memory, and for a processing instruction in a different instruction set, a different number of instruction address bits must be specified in the instruction address. Includes encoding logic that encodes an instruction address having an instruction set indication corresponding to the instruction to generate an x-bit encoded instruction address, the encoding logic prepending a bit pattern to the specified instruction address bits By performing a calculation equivalent to extending the instruction address bits specified by x to x-bits. Being adapted to implement the reduction, the pattern of bits prepended being dependent on the instruction set corresponding to that instruction.
[0032]
In a preferred embodiment, the tracing tool further divides the encoded instruction address into a plurality of x-bit sections and compares each x-bit section with the corresponding x-bit section of the preceding encoded instruction address; Performs a calculation equivalent to outputting the most significant x-bit section different from the corresponding x-bit section of the preceding encoded instruction address as the compression encoded instruction address, along with any lower-order x-bit sections. This includes compression logic for compressing the encoded instruction address.
[0033]
Viewed from a third aspect, the present invention provides a method for storing instruction set information, wherein a processing circuit is configured to execute a processing instruction from any of a plurality of instruction sets of processing instructions. The instruction is specified by an instruction address that identifies the location of the processing instruction in memory, and for a processing instruction in a different instruction set, it is necessary to specify a different number of instruction address bits in the instruction address. An instruction address having an indication of the instruction set corresponding to the instruction by performing a calculation equivalent to extending the specified instruction address bit to n-bit by prepending to the specified instruction address bit. Encoding to generate an n-bit encoded instruction address, wherein the prepended bit pattern corresponds to the instruction. Determined by the instruction set.
[0034]
In a preferred embodiment of the invention, the method further comprises (a) dividing the encoded instruction address into a plurality of x-bit sections, and (b) corresponding each x-bit section to the preceding encoded instruction address. Compared with the x-bit section, (c) the most significant x-bit section different from the corresponding x-bit section of the preceding encoded instruction address as the compressed encoded instruction address is replaced with any lower x-bit section. And a step of compressing the encoded instruction address by performing a calculation equivalent to output.
[0035]
The present invention (i) determines the number of x-bit sections forming a compressed encoded instruction address and (ii) incorporates additional x-bit sections derived from the corresponding x-bit section of the preceding encoded instruction address. Is generated according to the method of the third aspect of the present invention by performing a calculation equivalent to creating the encoded instruction address by expanding the compressed encoded instruction address to n-bit as necessary. It also relates to a method for decompressing a compression-encoded instruction address.
[0036]
In a preferred embodiment, the method is further equivalent to determining an instruction set associated with an instruction address from a predetermined bit pattern and removing the predetermined bit pattern to obtain a specified instruction address bit. Decoding the encoded instruction address by performing the following calculation.
[0037]
Viewed from a fourth aspect, the present invention provides a computer program product comprising a computer program for controlling an apparatus according to the method of the third aspect.
[0038]
DETAILED DESCRIPTION OF THE INVENTION
For purposes of describing the preferred embodiment of the present invention, on-chip tracing techniques and tracing of instruction set information with traced instruction addresses will be described.
[0039]
FIG. 1 schematically illustrates a data processing system 2 that provides an on-chip tracing mechanism. The integrated circuit 4 includes a microprocessor core 6, a cache memory 8, an on-chip trace module controller 10, and an on-chip trace buffer 12. The integrated circuit 4 is connected to an external memory 14 that is accessed when a cache miss occurs in the cache memory 8. A general purpose computer 16 is connected to the on-chip trace module controller 10 and on-chip trace buffer 12 and serves to recover and analyze the stream of tracing data from these elements using software running on the general purpose computer 16. .
[0040]
Often, the processor core 6 may need to access more data processing instructions and data during operation than the space actually present in the external memory 14. For example, the external memory 14 can have a size of 1 MB, but the processor core 6 can typically specify a 32-bit address, and thus can specify 4 GB of instructions and data. Therefore, all the instructions and data required by the processor core 6 are stored in the external storage device 18, for example, a hard disk, and when the processor core 6 operates in a specific operating state, the related instructions and data for that operating state are stored. It is loaded into the external memory 14.
[0041]
FIG. 2 is a block diagram illustrating in more detail components provided within the on-chip trace module of FIG. The on-chip trace module 10 is configured to receive overpass 105 data indicating processing performed by the processor core 6. With respect to FIG. 1, this includes core 6, cache, along with additional control type data received directly from the core (eg, an indication that the instruction address is indexed, an indication that the condition code failed for some instruction, etc.) 8 and on-chip trace module 10 can be received from the connecting bus.
[0042]
Synchronization logic 100 is adapted to convert the incoming signal into an internal version of the appropriate signal for use in the on-chip trace module. These internal versions are then sent to the trigger 110 and control logic 120, but it will be appreciated that the trigger 110 and control logic 120 need not necessarily receive the same signal. Basically, the trigger 110 needs to receive data related to triggerable events, such as instruction addresses, data values, register accesses, and the like. Control logic 120 needs to receive any data that needs to be traced in response to an enable signal emitted by trigger 110. The control logic 120 is further adapted to receive configuration information from the general purpose computer 16 via path 125 and then signals to the trigger 110 via path 115 to set up the trigger logic configuration. Has been.
[0043]
Whenever it detects an event that must cause a trace stream to occur, trigger 110 sends an enable signal to control logic 120 via path 135 to turn the trace on and off. The control logic reacts by outputting the necessary trace data to the trace buffer via path 145. It can be seen that various enable signals can be provided via path 135 to identify the type of signal to be traced, such as trace-only instructions, trace instructions and data, and the like.
[0044]
In the preferred embodiment, the control logic 120 of the on-chip trace module 10 encodes instruction set information having an instruction address, and then outputs such encoded instruction address via path 145 to the trace buffer. Additional logic is provided to allow compression.
[0045]
The encoding performed within the control logic 120 is shown schematically in FIG. 3, and the three different instruction sets used by the processor core 6 are named “ARM”, “Thumb” and “Java”. Has been identified. In the preferred embodiment of the present invention, the instruction address is 32 bits long. A Java instruction can start at any address location in memory, so all 32 bits must be specified in the Java instruction address 220. However, the Thumb instruction can only start at an even address location in memory, eg, location 0, location 2, location 4, location 6, etc. Therefore, bit position 0 in 32-bit Thumb instruction address 210 is always zero.
[0046]
Similarly, an ARM instruction can only start at every third address location in memory, eg, location 0, location 4, location 8, location C, etc. Therefore, the least significant 2 bits of the 32-bit ARM instruction address 200 are always zero.
[0047]
In an embodiment of the present invention, a logical 1 value is pre-pended (ie, placed in bit position 32) as the 33rd bit of each instruction address. The encoded instruction address is then created by applying an appropriate right shift to remove any unrelated least significant bits of the instruction address. Since all 32 bits need to be specified for a Java instruction, no right shift is performed, and the encoded instruction address 250 is simply 33 given by prepending a logical 1 value to the original 32-bit Java instruction address 220. Bit value. For Thumb instructions, a right shift of 1 is applied to remove the least significant bits, thereby creating a 33 bit encoded instruction address 240 with the most significant 2 bits being "01". Finally, for ARM instructions, a right shift of 2 bit positions is applied to remove the least significant 2 bits, thereby creating a 33 bit encoded instruction address 230 with the most significant 3 bits being “001”. It is.
[0048]
Thus, it can be seen that the instruction set associated with the instruction address is given by the most significant 3 bits of the 33-bit encoded instruction address. In particular, “001” in the most significant 3 bits identifies the instruction as an ARM instruction, “01x” identifies the instruction as a Thumb instruction (x indicates an arbitrary value), and “1xx” as the most significant 3 bits is an instruction. Is identified as a Java instruction.
[0049]
In the preferred embodiment, the 33-bit encoded instruction address is compressed using the technique schematically illustrated in FIG. 4 before being output to the trace buffer via path 145.
[0050]
As shown in FIG. 4, the 33-bit encoded instruction address 300 (which can be any of the encoded instruction addresses 230, 240, 250 shown in FIG. 3) is divided into 7-bit sections, with the most significant 5 bits. Is expanded to a 7-bit section by prepending two logical zero values to 5 bits. Each 7-bit section output as a compression encoded instruction address is a byte by prepending a flag indicating whether the corresponding 7-bit section is the last 7-bit section output as a compression encoded instruction address. (Ie 8 bits). In the preferred embodiment, the flag takes the form of consecutive bits, which are set to a logical one value to indicate that another section is to be output, and set to a logical zero value so that the corresponding section is a compressed encoded instruction address. Indicates the last section of.
[0051]
To determine if any particular 7-bit section should be output as part of the compressed encoded instruction address, that 7-bit section is preceded by the preceding encoded instruction address, typically immediately before. Is compared with the corresponding 7-bit section of the encoded instruction address to determine if it differs from the preceding 7-bit section. If it is different, it is output as part of the compressed encoded instruction address and the corresponding consecutive bit is set to 1 and if it is identical to the preceding 7-bit section, the corresponding section of the preceding encoded instruction address Only output if there is a higher 7-bit section different from. The only exception is the first 7-bit section associated with the least significant bit, which is always output.
[0052]
From FIG. 4, it can be seen that if the encoded instruction address is completely different from the preceding one, as occurs when there is a switch between instruction sets, the compressed encoded instruction address is actually more bits than the original encoded instruction address. use. In particular, for FIG. 4, it can be seen that if five sections 310, 320, 330, 340, 350 need to be output, 40 bits are required for the compression encoded instruction address. Nevertheless, switching between instruction sets typically occurs relatively infrequently, and instruction addresses are often very similar to the immediately preceding instruction addresses, so most encoded instruction addresses are shown in FIG. As a result of using the compression technique shown, significant compression can be achieved.
[0053]
Next, looking at section 350 of FIG. 4, it can be seen that the bit strings within that section implicitly identify the instruction set. In particular, column 360 identifies the ARM instruction set, column 370 identifies the Thumb instruction set, and column 380 identifies the Java instruction set.
[0054]
FIG. 5 is a representative sequence of three instructions 400, 410, 420 showing the compression encoded instruction address produced in accordance with the preferred embodiment of the present invention. Instruction address 400 is associated with the ARM instruction and is written in hexadecimal notation. Referring to FIG. 3, it can be seen that the lowest two “0” bits are removed as a result of the encoding and the pattern “001” is added as the most significant 3 bits. When a compression technique is applied to such an encoded instruction address, a compressed encoded instruction address 430 is generated. In the example of FIG. 5, the next instruction 410 is a Thumb instruction, so the least significant “0” bit is removed and the pattern “01” is added as the most significant 2 bits before compression. Next, a compression-encoded instruction address 440 is generated as a result of applying the compression technique. At this stage, the information about the instruction set is efficiently encoded by the instruction address, but the compression process is not saved at all because one ARM instruction is followed by one Thumb instruction.
[0055]
However, if the next instruction is a Thumb instruction 420, a compression-encoded instruction address 450 is created. Thus, the 32-bit instruction address is represented by 2 bytes, ie 16 bits, with information about the instruction set, which is very efficient for generating both the instruction address and the instruction set to be stored in the trace buffer. Represents a typical method. It can be seen that any Thumb instruction address following instruction address 420 is likely to be significantly compressed.
[0056]
FIG. 6 is a block diagram of the logic that can be provided in the control logic 120 of the on-chip trace module 10 according to a preferred embodiment of the present invention that performs the required encoding and compression. A register 610 is provided and its most significant 3 bits 607 store a predetermined bit pattern, "001" in the preferred embodiment. The least significant 32 bits of register 610 receive 32-bit instruction address 605 via path 602. In addition, a latch 630 is provided that stores an instruction set identifier that identifies the instruction associated with the 32-bit instruction address passed through path 603 and stored in register 610.
[0057]
33-bit sector logic 620 receives the contents of register 610 and the output of latch 630 and is adapted to select a predetermined 33-bit string from the 35-bits in register 610 in response to the instruction set identifier. An example of 33-bit sector logic 620 is shown in FIG.
[0058]
As can be seen from FIG. 7, the 33-bit sector 620 preferably includes a multiplexer 700 that receives three separate inputs 701, 702, 703. Input 701 receives the most significant 33 bits from register 610, input 702 receives 1-33 bits, and input 703 receives the least significant 33 bits. Multiplexer 700 outputs one of its 33-bit inputs on path 710 depending on the value of the instruction set identifier. In particular, if the instruction set identifier identifies the instruction as an ARM instruction, the multiplexer 700 outputs the input received via path 701 and the instruction set identifier identifies the instruction as a Thumb instruction. , Multiplexer 700 outputs the input received via path 702 and, if the instruction set identifier identifies the instruction as a Java instruction, multiplexer 700 receives the input received via path 703 via path 710. Output.
[0059]
Returning to FIG. 6, it can be seen that the 33-bit value output via path 710 is split into five different sections. In the preferred embodiment, this is done by dividing the 33-bit wide bus 710 into only four 7-bit wide buses 622, 623, 624 and 625 and one 5-bit wide bus 626. The least significant 7 bits of the output from the multiplexer 700 are passed directly to the compression encoded instruction address generator since the least significant 7 bits are always output. The next least significant 7 bits are passed to comparator 670 via path 623, the next least significant 7 bits are passed to comparator 660 via path 624, and the next least significant 7 bits are passed to path 625. To the comparator 650 and to the comparator 640 via the most significant 5-bit path 626.
[0060]
The structure of each comparator is schematically shown in FIG. The comparator shown in FIG. 8 is adapted to process 7-bit numbers and is therefore used for comparators 650, 660 and 670. Comparator 640 is structurally similar to the comparator of FIG. 8, but handles a 5-bit number instead of a 7-bit number.
[0061]
When a new 7-bit section is received by the comparator, it is temporarily stored in register 800. It is then output to comparator logic 830. At this time, the comparator logic 830 is also adapted to receive from the register 820 the corresponding 7-bit section of the traced instruction address that immediately precedes it. Comparator 830 compares whether the two 7-bit values are the same, and if so, comparator logic 830 generates a logic zero value as the difference signal. Otherwise, the comparator logic 830 generates a logic 1 value as a difference signal indicating that the current 7-bit section is different from the previous 7-bit section. When the next 7-bit section is received, it is stored in register 800 and the previous contents of register 800 are passed to register 820 for use in the next process.
[0062]
Returning to FIG. 6, each of the different signals produced by the four comparators 640, 650, 660 and 670 generates a continuous bit associated with each section output as part of the compression encoded instruction address. It is passed to the continuous bit generator 680 used. An example of logic that can be used to form the continuous bit generator 680 is shown in FIG.
[0063]
As can be seen from FIG. 9, this logic basically receives the corresponding difference signal along with the output from any other OR gate processing the difference signal associated with the higher section of the 33-bit encoded instruction address. A series of OR gates 910, 920 and 930 are included. Thus, the difference signal emanating from comparator 640 via path 686 is output directly via path 950 to form successive bits for the 7-bit section output from 33-bit sector 620 via path 625. The consecutive bits for the most significant section output that is output from the 33-bit sector 620 via path 626 is always a logic zero value, which is the last section when that section always outputs a compression-coded instruction address. Because. Thus, path 940 is hardwired to logic 0 to provide a continuous bit for that section.
[0064]
The OR gate 930 is adapted to receive the difference signal via paths 685 and 686, and if the difference signal on path 685 or 686 is a logic one value, a continuous bit having a logic one value is obtained via path 960. appear. This successive bit via path 960 is used to qualify the 7-bit section output by the 33-bit sector 620 via path 624.
[0065]
OR gates 920 and 910 behave similarly when their corresponding difference signal is set or a difference signal associated with a comparison performed in any higher section of the encoded instruction address is set. , Ensure that the corresponding consecutive bits are set to a logical one value. The continuous bits output via path 970 are used in conjunction with the 7-bit section output via path 623, and the continuous bits output via path 980 are output 7- Used with bit sections.
[0066]
Returning to FIG. 6, all that is required is to form a compression-encoded instruction address by combining consecutive bits with its associated section output by a 33-bit sector starting with the least significant 7-bit section, and then compressing the code. This is to determine how much of the instruction address to output to the trace buffer 12. As soon as a logical 0 continuous bit is encountered, there is no need to output more sections to the trace buffer. This function is performed by the compression encoded instruction address generator 690 shown in FIG. This process is shown schematically in FIG. As shown in FIG. 10, starting with the least significant 7-bit section, the 7-bit section 1000 is converted to an 8-bit section and output as the most significant bit by adding 1010 to the appropriate consecutive bits. This process is repeated one after the other for each 7-bit section.
[0067]
The 5-bit value 1020 corresponding to the most significant 5-bit is expanded to an 8-bit output by prepending two logical values 1040 and 1050 with consecutive bits 1060. As described above, this section is always the last section of the compression-encoded instruction address, so in this case, consecutive bits are always a logical 0 value.
[0068]
The 40-bit value resulting from the process is then output from the compression encoded instruction address generator, and the enable bits previously generated by the continuous bit generator 680 are used to produce a length value, which is 40- Used to determine how many 8-bit sections in the bit value are output to the trace buffer 12. For example, if the enable bit on path 682 and the output from OR gate 910 are set, the two most significant 8-bit sections are output to the trace buffer 12 as compression encoded instruction addresses.
[0069]
From the above description of the preferred embodiment, it can be seen that an efficient technique has been described that incorporates an instruction address into the instruction set information and compresses the encoded instruction address to provide an efficient representation for storage. Will. In the preferred embodiment, this technique is applied to a tracing mechanism and the compressed data is stored in the trace buffer 12. Next, decompression logic for decompressing the compression-encoded instruction address can be provided in the general purpose computer 16. Since detailed discussions on compression techniques have already been made, those skilled in the art will readily understand how decompression works. In brief, the decompressor reads an 8-bit section sequence representing a compression-encoded instruction address and from one 8-bit section indicated by the value of consecutive bits in the most significant bit position of each 8-bit section. The sequence varies up to five 8-bit sections.
[0070]
For a compressed encoded instruction address consisting of five 8-bit sections, the encoded instruction address strips consecutive bits from each 8-bit section, then starts with the least significant 7-bit section and then the 7-bit section. Can be reconfigured. The least significant 33-bit now represents the encoded instruction address, and the most significant 3-bit pattern of the 33-bit value identifies the instruction set. If the instruction is a Java instruction, the 32-bit instruction address can be reproduced simply by outputting the least significant 32-bit of the encoded instruction address. If the instruction is a Thumb instruction, the original instruction address is given by shifting the encoded instruction address one position to the left and outputting the least significant 32-bit, with the least significant bit having a logic zero value. Similarly, if the instruction is an ARM instruction, the original ARM instruction can be output by shifting the encoded instruction address to the left by 2 positions and outputting the least significant 32 bits. 0 value.
[0071]
For subsequent compressed encoded instruction addresses consisting of 4 sections or less, consecutive bits can be removed from each section contained within the compressed encoded instruction address, with the least significant bit of the instruction address starting at the least significant section. Can be reconstructed by combining any such sections. Depending on the number of sections in the compression encoded instruction address, this results in the first 7, 14, 21, or 28 bits of the instruction address. Since the remaining bits are the same as the preceding decompression instruction address, they can be determined from the previous decompression instruction address.
[0072]
A detailed description of the tracing technique of the least preferred embodiment of the present invention is given in the actuator description below to be read along with the Embedded Trace Macrocell (REV1) description publicly available from ARM, Cambridge, UK .
1.1
This document uses the following terms and abbreviations:

[0073]
range
This document specifies the functions of ETM10. ETM10 is a real-time trace module capable of instruction and data tracing. The functionality is similar to that of conventional ETM implementations for ARM7 and ARM9. The reader should be familiar with the original ETM specification outlined in the Embedded Trace Macrocell Specification (ARM IHI 0014D). This specification does not attempt to restate the common actuator features between ETM10 and conventional ETM versions, but considers the parts of the ETM specification that are changed with respect to ETM10. Most of these changes are related to the generation of a new ETM protocol that can properly trace the ARM1020E. This protocol can be extended to trace future ARM cores as well.
[0074]
Introduction
Embedded Trace Macrocell is an ARM realm that includes an ETM, a trace port analyzer, and a software debugger (such as ADW).
It is an integral part of the Time Debug solution.
[0075]
The Embedded Trace Macrocell consists of two parts, a trace block and a trigger block. The trace block generates a compressed trace and outputs it across a narrow trace port. The trigger block contains programmable resources that allow the user to specify the trigger state. The trigger block resource is also used as a filter to control which instructions and which data transfers are traced. All ETM configuration registers (including trigger block resources) are programmed via the JTAG interface. The user accesses these registers using a software debugger. Once the trace is captured, the debugger is also responsible for decompressing the trace and providing the user with a complete breakdown of the executed code. Because the debugger software cannot process the ETM trace port output in real time, the trace is first captured in an external Trace Port Analyzer (TPA). The TPA can be a fully functional logic analyzer or a specific ETM device such as an Agilent nTracebox. When a trigger condition occurs and the debug run is complete, the debugger extracts trace information from the TPA. At this high level of description, ETM10 is functionally identical to ETM7 and ETM9.
[0076]
Changes required for Etm10
From the user's point of view, ETM10 provides instruction and data tracing capabilities equivalent to those provided by ETM7 and ETM9, with minor differences that are not important. This section explains the changes made to the ETM architecture for ETM10 and why they are changed. Many changes only affect decompression software and are invisible to the rest of the trace toolkit software as well as the end user. However, some changes will affect the programmer's model or make a small difference in the tracing behavior from ETM7 and ETM9. Such changes are indicated in this chapter. Any changes to ETM10 that require a thorough explanation of the new protocol will be dealt with more thoroughly in the protocol description in Chapter 5.
[0077]
1.2 Branching phantom tracing
ARM 10 implements “branch folding”, which means that it can predict a branch, pull it from the regular instruction stream, and effectively execute it in parallel with the next instruction in the program. These folded branches are called branch phantoms. PIPESTAT encoding within the old protocol only considers one instruction executed per cycle. In order for the branch phantom to be traced, a new encoding is added to the PIPESTAT field representing the branch convolved in parallel with the instruction. A new PIPESTAT is given in the ETM10 protocol specification in Chapter 5.
[0078]
Folded branches also require changes to trigger blocks. When the branch is folded, two instructions are effectively executed in parallel. Since the PC values for these two instructions are not guaranteed to have any identifiable relationship, two address comparisons must be made in each cycle. This means that each address register requires two comparators. Both comparator outputs are taken into account when determining whether tracing is enabled. (If either of these two instructions is traced, tracing is enabled in that cycle). Special care is taken to ensure that at most one additional instruction is traced due to branch folding. In general, the user does not need to know when a branch is folded and executed in parallel with the next instruction in order to properly program TraceEnable or ViewData.
[0079]
For events, parallel execution of instructions allows to have slightly different behavior from ETM10 vs. ETM7 / 9. Here it does not feel that there is a lot of loss of functionality due to the way events are typically used. The counter can only count down once per cycle, but counting provides an accurate count of accesses when a single address comparator is used. In addition, there is no loss of functionality to the Trigger, TraceEnable, ViewData or ExtOut events, which are active during the desired operation when an instruction or data transfer is individually activating it. If the sequencer receives multiple transition requests within the same cycle, no transition is made and the sequencer remains in its original state. This operation is the same as that of ETM7 and ETM9. However, as ARM10 supports more parallel execution, ETM10 may have more occurrences of multiple transition requests within a cycle. Users need to know this behavior when programming the sequencer, but there is a workaround for simple events. If the desired action is a transition from state 1-> 2 based on event A and state 2-> 3 based on event B, program 1-> 2 occurs on event (A & IB) and 2-> 3 Occurs on event B and 1-> 3 occurs on event (A & B). Programming the sequence in this manner ensures proper handling of event A and event B simultaneously.
[0080]
1.3 Load misses and exception tracing
ARM 10 has a non-blocking data cache that allows other instructions, including other memory instructions, to execute under a single significant miss, and the data cache can return data back to the core in a crazy order. This feature is a load data tracking problem because the current protocol expects load data to be placed in the FIFO in the correct order. Data packets are prefixed by some header bytes and contain out of order load miss data. The header byte is described in detail in Chapter 5.
[0081]
Non-blocking cache support also requires changes to the data comparator. Like ETM7 and ETM9, ETM10 has a data comparator that is used with a pair of address comparators. In use, the comparator only triggers a match if the data also matches. Since other memory accesses can occur under a miss, a bit is added to each comparator to keep track of whether the address for the missed load request matched. When load miss data is returned, a data value comparison is made and the stored address match bits are used to limit the comparison result. The match bit is then cleared. In some cases, the user may not want to wait for missed data to be returned to enable the comparator. Instead, you may want to ensure that load misses are always traced based only on data assembly. In order to support both user models, a bit has been added to the address access type register that allows the user to specify which model is enabled for each comparator. If waiting for load miss data in the comparison is desired, the user must set bit 8 of the address access type register, the Exatx Match bit. (See Reference 1 for more information on access type registers). When data values are used to generate triggers or other events, it is useful to wait for a data comparison to occur. If the comparator is used for trace filtering and irrelevant tracing is not an issue, a tracing load miss based only on the address is useful. Since load data can be returned in crazy order, the user must use the data value to know that generating an event, such as a sequencer transition, can result in crazy events. . This feature can be disabled in the core via a write to the cp15 configuration register (r1) if the user is concerned that the ARM 10 non-blocking cache may affect the programmed event. it can. See ART1010E TRM (Ref 3) for more information.
[0082]
Bit 7 of the access type register is used to specify the comparator operation when an interrupt, interrupt, or soft reset occurs. These states are generally called exceptions. If data access is interrupted and bit 7 is asserted, the comparator will not be a match output regardless of whether a data match is required. When the comparator is tied to the instruction address, the exact match bit is used to prevent a match on an instruction marked as an exception. This is often desirable when the comparator fires only once, since exceptional command and data requests are usually retried when the interrupt or interrupt condition is resolved. In the data access case, if bit 7 is not asserted, the data value is presumed invalid and is a purely address based match due to interrupted access.
[0083]
Since the desired operation is typically the same for both cases, the same Exact Match bit is used to determine the proper handling of load misses and data breaks. The default value of the Exact Match bit is zero.
[0084]
1.4 ARM10 data tracing
ARM1020E has a 64-bit data bus that can return 64 bits of data in a single cycle. In order to support this 64-bit data bus, ETM 10 must be able to trace two adjacent data values within a single cycle. Two ViewData outputs are generated to support tracing of only one or the other value. However, there is still only one output for events and one output for TraceEnable. Having one event output affects the counter and sequencer logic because two adjacent 32-bit requests accessed in the same cycle cause only one decrement of the counter or only one state change by the sequencer There is. The user has to take this into account when programming the event logic, but that doesn't seem to be an important issue.
[0085]
1.5 LSM tracing
ARM 1020E has an independent load / store unit that allows other instructions to be executed under multiple instruction loads or stores, hereinafter referred to as LSM, while the load / store unit repeats data access. it can. (Ie, running LSM does not stop the core). In order to support this, some changes to the address comparator output and TraceEnable assertion are required. Whenever it actively traces an LSM instruction while iterating, it remains active until LSM completes, regardless of whether TraceEnable remains asserted. (The only exception to this rule is the overflow case). This rule has the side effect that other instructions executed under LSM will be traced regardless of whether they are originally traced. However, by definition, instructions that run under LSM cannot be data instructions, so it does not result in extra data packets. Whenever a comparator is activated on an LSM instruction address, the ViewData output of that comparator remains asserted until all instructions are complete. This is because the user's intention is to trace all data packets associated with this command. Similarly, ViewData and Event range outputs remain asserted until completion of the LSM instruction. The event single address comparator output does not remain asserted because by definition only asserts a single cycle.
If a data transfer associated with LSM is being traced, subsequent transfers associated with that instruction that are not normally traced will have a placeholder packet output (see Untraced Values-Chapter 5). These placeholder packets need to see which words were traced.
[0086]
The ETM protocol allows for instruction tracing to be enabled based on load / store data addresses (and data values). On ARM10, LSM instructions may no longer be in the core execution stage when a tracing enabling event occurs, so this instruction address needs to be kept around and broadcast in a special way to support this feature There is. This is accomplished using LSM in Progress TFO packets. The Trace Packet Offset is described in 5.2.4.
[0087]
1.6 Auxiliary data tracing
The addition of data headers to the protocol also considers the tracing of auxiliary data types (ie, tracing of data values other than load, store, and CPRT instructions). This auxiliary data type tracing means considering the extension of ETM tracing, which can include tracing of external ASIC data in future versions of ETM. More information on ancillary data tracing is given in the data header review in Chapter 5.
[0088]
1.7 CONTEXTID tracing
Context IDs are broadcast whenever they are updated and whenever TFO packets are needed for synchronization. For ETM10, CONTEXT ID values are output when they are updated with simple data tracing for CPRT instructions that result in a CONTEXT ID change. The unique data header for this data packet allows the decompressor to recognize that the data is a new Context ID value (the data header is discussed in Chapter 5). The ETM also broadcasts the current Context ID value whenever trace is enabled and during the trace synchronization cycle described in section 5.2.4. The CONTEXT ID update instruction is MCR c15,0, rd, c13, c0,1.
[0089]
Instead of requiring another 32-bit port on the ARM10 <-> ETM10 interface, the ETM10 recognizes the CONTEXT ID update and maintains the current TEXT ID value in an internal shadow register. In order to maintain coherency properly, this register is always updated, even when the ETM is in POWERDOWN mode (ETM register 0x4, bit 0 is asserted).
[0090]
The use of a CONTEXT ID value for trace filtering is added as an additional feature to ETM10. This is accomplished through a new set of programmable registers in the ETM that can specify the expected CONTEXT ID value.
[Table 1]

The same mask is used for each CONTEXT ID comparator and works similarly to the data comparator mask.
[0091]
Bits 9: 8 of the address comparator access type register indicate whether a CONTEXT ID comparator is used. A value of 00 causes the Context ID comparator to be ignored. A value of 01, 10 or 11 will cause the address comparator to match only after the current TEXT ID matches that in the CONTEXT ID comparator 1, 2, or 3, respectively, after considering the CONTEXT ID mask.
[0092]
New event resources are allocated so that the CONTEXT ID comparator can be accessed directly from within the event block (see 3.3.4 of ARM IHI 0014D). These new resources are mapped to 0x58-0x5A.
[Table 2]

A new field is added to the ETM configuration code register to indicate the number of CONTEXT ID comparators present (see 4.2.2 in ARM IHI 0014D).
[Table 3]

[0093]
1.8 Trace output frequency
The ARM1020E Macrocell can operate at core frequencies in excess of 300 MHz. Conventional ETM implementations do not exceed 200 MHz in frequency. The maximum output frequency obtained for the ETM trace output is determined by the maximum sample frequency of the trace analyzer and the maximum output frequency obtained at the pad. Agileen and Tektronix analyzers can capture at maximum frequencies of 333 MHz and 400 MHz, respectively. However, any CMOS pad obtained from an ARM partner is very likely to provide a clean and traceable signal at this frequency. Thus, the pad is considered a speed limiting factor. Larger pad and / or board level buffering can be used to obtain some speed improvements. These techniques allow us to perform reliable tracing at 200 MHz. There are two options for faster tracing. The pin count can be doubled and the frequency halved (demultiplexed trace port), or an on-chip trace buffer can be used. Both techniques have advantages and disadvantages.
[0094]
Doubling the pin count is not an attractive option for some partners due to package limitations and the high cost of additional pins. This technique also requires a change in TPA and possibly the addition of a second microconnector, which takes up more area and adds cost. Furthermore, this technique also has a 400 MHz speed limit. ARM10 processors made with thermal processes probably exceed these speeds.
[0095]
The on-chip buffer has the advantage of requiring no reliable tracing at core clock speed and no additional pins. In fact, if all trace capture is done using an on-chip buffer, the external visible ETM port can be eliminated because the on-chip buffer is downloaded via Multi-ICE via the JTAG port. . The disadvantage of this solution is that the size of the on-chip buffer is typically very small, on the order of 8-16 KB. Therefore, the tracing depth is limited. Large on-chip trace buffers are possible, but have a direct impact on the size of the ASIC, and even a small trace buffer may use more silicon space than is provided by the same design.
[0096]
As the advantages and disadvantages of each method vary, it is planned to support both options described above. The ARM10200 rev 1 test chip is built with a demultiplexed trace port for high speed tracing. The on-chip trace buffer is not part of the ARM10200 rev 1 test chip.
[0097]
An on-chip trace buffer specification for ETM9 has been created and implementation is in progress. An unimportant change that supports the new 4-bit PIPESTAT encoding described in Section 5.2 can generate an ETM10 compatible on-chip trace buffer from this design. See Reference 4 for detailed information on what Trace Capture Device changes are required to support ETM10. Depending on the time scale, the ETM10 compatible on-chip trace buffer can provide additional features, such as dynamic trace compression, and in fact can be integrated directly into the ETM10 design as a FIFO replacement.
[0098]
1.9 Synchronization register
In conventional ETM implementations, synchronization occurs via a 5-byte instruction every 1024 cycles and via a 5-byte data address every 1024 cycles. For ETM10, these synchronization points can be configured via a new 12-bit programmable register. Configurable synchronization makes it easy to use the full range of trace buffer sizes. Small trace buffers, such as on-chip trace buffers, can be synchronized frequently to avoid throwing out large portions of the trace, and large trace buffers are occasionally used to avoid unnecessary synchronization throughput. Can be synchronized. The default counter value is 1024 cycles. To prevent data address and instruction address synchronization from occurring simultaneously, data address synchronization occurs when the counter reaches its midpoint value and instruction address synchronization occurs when the counter reaches zero. The address for the new sync register is 0x78.
[0099]
1.10 Memory map decoder
External memory map resource inputs that existed in conventional ETM implementations are not supported for ETM10. The extra complexity present in the ARM10 architecture makes it more difficult to implement support for the outer decoder. External events can still control tracing by using EXTIN, which is a cycle accumulate (discussed in 4.15).
[0100]
1.11 Range out
Conventional ETM implementations can use the data value comparison register in the Embedded ICE logic as an extra external register resource. This function is performed using the RANGEOUT output coming from the Embedded-ICE. The ARM10 debug unit does not have these RANGEOUT outputs because it does not have a data value comparison function. Therefore, this resource reuse is not possible for ETM10. Since these resources are no longer programmed, their impact on the programmer's model is small.
[0101]
1.12 Branch to interrupt vector
The current protocol specifies that direct branches to entries in the interrupt vector table must be traced as indirect branches. This is no longer always possible because phantom branches cannot be converted to indirect branches within the proposed protocol. Thus, regardless of whether the direct branch was a branch phantom, the direct branch to the interrupt vector is no longer traced as an indirect branch for consistency and simplicity. Branches to the PABORT, FIQ, IRQ, DABORT, and RESET vectors can be detected by special encoding of address byte 5 as described in section 5.3.1.
[0102]
1.13 Protocol version
The 4-bit ETM protocol version field present in the configuration code register (register 0x01) on ETM7 and ETM9 has been found to be insufficient to support future protocol versions for ETM. Thus, a new ETM ID register is defined that includes a field that specifies the intended ARM core as well as minor and major correction numbers. This register is mapped to register address 0x79 and is considered valid whenever bit 31 in the configuration register is set. This allows ETM7 and ETM9 to use protocol variants 0-7 without the need for an ID register. The ETM ID register contains a 32-bit value distributed into the following fields:
[Table 4]

ETM rev0 has an ID value of 0x41012100.
[0103]
1.14 Trace start / stop resources
A new event resource is provided that gives the current state of the TraceEnable start / stop logic. This is given a resource number 101 1111 (see chapter 3.3.4 of ARMIHI 0014D) and must be asserted whenever Trace Start / Stop is active. ETM versions that support start / stop resources also assert bit 23 in the ETM control register.
[0104]
1.15 TPA change
All TPAs require minor changes to support new trigger and trace disable state values for ARM10. That is, they must ensure that PIPESTAT [3] / TRACESYNC is low to detect TR and TD PIPESTATs. Agilent Trace also requires minor hardware changes. In order to support high-speed tracing through a demultiplexed, half-speed ETM port, the TPA must be able to capture two core cycles of trace data within each cycle. This data is broadcast across the Mictor connector. Therefore, support for multiple connectors is also necessary. See Reference 4 for more detailed information on these changes.
[0105]
1.16 Precision events
In ETM7 and ETM9, events generated via the Event block are not precise, meaning that the user was not guaranteed to trace the instruction that generated the data access or event. This is no longer the case for ETM10. The ViewData and TraceEnable assertions are always precise regardless of how it is generated.
[0106]
1.17 FIFOFULL level register
For ETM7 and ETM9 registers, 0x0B was used to set the level that the FIFO must reach before FIFOFULL is asserted. For ETM10, FIFOFULL, this register is not used, but instead, when enabled, FIFOFULL is asserted whenever a new packet is placed in it. ETM10 is pipelined deeper than ETM7 / 9, and FIFOFULL can only be asserted fast enough to be useful when used in this way. In ETM10, the FIFOFULL register is reused as a read-only register that specifies the FIFO size. The FIFO size is a size that cannot be determined by software within ETM7 / 9.
[0107]
1.18 Trigger output
DBGRQ is ignored if the processor is in monitor debug mode. Therefore, it is useful to have other mechanisms that can recognize that a trigger is occurring. For this purpose, a single bit TRIGGER output has been added to the ETM interface for ETM10. The TRIGGER output is asserted whenever the 4-bit TRIGGER state is driven on the PIPESTAT bus. This signal can then be used by the interrupt controller to signal the triggering core via an assertion of the interrupt. The TRIGGER output can be left unadded if not needed.
[0108]
1.19 Counter event
For ETM7 / 9, the counter event register has an extra bit 17 that can be used to continuously count. This bit is removed because its operation is difficult to verify with redundancy. If a continuous counter is desired, the user simply programs an event equal to the external resource 15, which is a hardwire that should always be active.
[0109]
ETM10 trace port
1.20 ETM10 port signal
The ETM10 trace port consists of two signals, PIPESTAT and TRACEPKT, both valid at the rising edge of TRACECLK (having the same frequency as GCLK). PIPESTAT has been extended from 3 bit to 4 bit signal to ETM 10 to add a coding space for the branch phantom. TRACEPKT is unchanged from the conventional ETM version and can be 4, 8 or 16 bits depending on the configuration. Since synchronization is achieved through another mechanism, the TRACSYNC pin has been removed from the protocol. The overall result is a trace port with the same pin count as the traditional ETM implementation.
[0110]
1.21 PIPESTAT encoding
[Table 5]

[0111]
1.21.1 Branching phantom PIPESTATs
Eight new branch phantoms are added to allow for branch phantoms that execute in parallel with the following instructions: These encodings must always be interpreted as a branch instruction that is the first of the execution stream. Only direct branches are predicted, and the branch phantom does not place data packets in the FIFO. Since any instruction executed in parallel is from the illegal instruction stream and is therefore canceled, a mispredicted convolution branch results in a legitimate IE / IN PIPESTAT.
[0112]
1.21.2 Data PIPESTATs
All mnemonics starting with 'D' mean that certain data packets are placed in the cycling FIFO and will eventually be output on the TRACEPKT pin. Note that the word 'packet' for the new protocol refers to the amount of bytes placed in the FIFO, not a single byte in the FIFO. The data packet can be a branch address, load / store transfer, CPRT transfer, or auxiliary data packet. ETM10 places a maximum of three data packets in the FIFO within one cycle (two LDST / CPRT transfers and one branch address packet). Three packets in one cycle are not a protocol but a hardware restriction. The need for separate data and branch PIPESTATs has been eliminated by adding packet header bytes to the protocol. Data packets can be added to any cycle by adding DW and DN state values. This addition means that a coprocessor map that determines the length of LDSs / STCs is no longer needed, and tracing of variable length LDC / STC instructions is supported. The packet header byte is described in more detail in section 5.3.
[0113]
1.21.3 Instruction PIPESTAT
The non-waiting PIPESTAT value, i.e. indicating that the instruction has been executed, is always given on the first cycle in which the instruction is executed. This distinction is important for LSM instructions that execute and return data for several cycles. This operation is different from the conventional protocol version which gives the executed PIPESTAT value for the LAST cycle in which the LSM was executed.
[0114]
“Non-executed” PIPESTATs (IN / DN) occur for two reasons. The instruction failed its condition code or was not executed due to an exception. As noted above, possible exceptions include interrupts, prefetch interruptions, and reset assertions. Since a load / store instruction that causes data interruption is considered to be executed, the IN / DN state cannot be given. The decompressor needs to know when an exception prevents execution of the instruction. This information is used to prevent late data packets from previous LSM instructions from being appended to the exception instruction. (The only data packet in which an instruction with “not executed” PIPESTAT is considered is a branch address).
[0115]
1.21.4 TD states and TFOs
The TD state means that there is no trace FIFO data on TRACEPKT for this cycle. There are two reasons why it happens.
There is no data traced in the FIFO (if the FIFO is not empty, the state is WT). In particular, it occurs immediately after the trace is disabled until the next time it is enabled.
• TFO is broadcast for ETM synchronization.
[0116]
Given a TD state on PIPESTAT, the decompression software needs to look at TRECEPKT to see if the TFO is being broadcast. TRECEPKT [0] is used to distinguish between cycle-accurate and non-cycle accurate traces, as is done in conventional ETM implementations. As before, Trace Capture Devices can discard the TD cycle if TRECEPKT [0] = 0. When TRECEPKT [0] is asserted, TRECEPKT [3: 1] is used to specify whether the TFO is broadcast. When the TFO is broadcast, TRECEPKT [7: 4] specifies the lower 4 bits of the TFO value. TRECEPKT [3: 1] specifies the remainder of the TFO value as given in the table below. The TFO is encoded in this way to maximize the range of valid TFO values.
[Table 6]

[0117]
TFO or Trace FIFOOffset is used when the trace information is expanded to synchronize between the pipeline state (PIPESTAT) and the FIFO output (TRACEPKT). A TFO is generated when the trace is first enabled and whenever the instruction synchronization counter reaches zero. Trace FIFO offset replaces address packet offset (APO) information used in conventional ETM implementations. Rather than counting branches, the TFO counts the number of bytes currently in the FIFO. Such synchronization eliminates the need for the TRACSYNC pin in the protocol. Also, there is no need to start tracing with BE PIPESTAT and continue two dead cycles for the APO value.
[0118]
The IE PIPESTAT value is included whenever a TFO is broadcast for synchronization while tracing is already enabled. When the TFO is broadcast and starts tracing, PIPESTAT is not included and PIPESTAT for the first traced instruction is given in the following cycle.
[0119]
A synchronous TFO is generated whenever all of the following criteria are met:
The cycle counter, typically initialized to 1024, reaches zero
The current instruction has a PIPESTAT value of 'IE'
[0120]
When a synchronization request is displayed, the TFO cycle counter is reset to the value programmed into the instruction synchronization register (default value is 1024) and counting is resumed. In the case where the second synchronization request is made before the first synchronization request is serviced, the ETM is forced to overflow as a way to force synchronization. In this scenario, some traces are lost, but if that happens, the processor is not likely to be a problem because it is likely to be stuck in an infinite loop. Therefore, no significant trace is lost. The only case where this is not the case is when the sync counter is set to a tremendously low number. It is therefore not recommended to set the sync value too low (less than 50 cycles).
[0121]
When a TFO cycle occurs, several bytes of data are placed on the cycling FIFO. This data is called a TFO packet and typically consists of a special header byte, the current CONTEXT ID, and the full instruction address. A suitable format for TFO packets is given in section 5.4.
[0122]
In 4-bit TRACEPKT configuration, if a TFO occurs when the second nibble of a byte is expected, an extra nibble of value '0x6' is output on TRACEPKT [3: 0] immediately following the TFO value. The This nibble is necessary because the TFO value specifies synchronization in bytes rather than nibbles. By outputting this extra nibble, ETM 10 ensures that the current top of the FIFO indicated by the TFO value is always byte matched. It is important for the decompressor to know that this extra nibble will appear on TRACEPKT [3: 0] for cases where synchronization is not required. Regardless of whether the TFO is due to synchronization or Trace enabled, the decompressor must expect this extra nibble whenever a TFO is generated on an odd nibble. The FIFO output is delayed until the complete TFO value (and, if desired, the extra nibble) is output on TRACEPKT [3: 0].
[0123]
1.21.5 Trigger status
The trigger state (TR) implies that the actual 4-bit state for this cycle is placed on TRACEPKT [3: 0] and the FIFO output is delayed by one cycle. The operation is the same as ETM7 and ETM9. If the trigger and TFO are to occur simultaneously, the PIPESTAT value on TRACEPKT [3: 0] is TD. Since WT pipestat is not converted to TD pipestat when a trigger occurs, it can be uniquely identified as a true TFO. In the 4-bit port case, if it is desired to trigger within the second cycle of TFO broadcast (or gap cycle), the trigger occurs and the FIFO output is delayed by an extra cycle to output the remaining TFO nibble. Therefore, the trigger is guaranteed to be output as soon as it occurs without being delayed.
[0124]
1.22 Packet header encoding
With PIPESTAT with 'D' encoding, the packet is placed in the FIFO. Up to 3 packets (2 data packets and 1 branch packet) can be placed in the FIFO within a single cycle. The encoding for the packet header value is as follows.
[Table 7]

[0125]
The C bit on the data header is used to inform the decompressor how many packets are inserted into the FIFO within a single cycle. The C bit is asserted for each inserted packet that does not include the last packet. This is necessary for the decompressor to know which packet is to be tied to which cycle and hence which instruction. This C bit should not be confused with the address continuation bit indicated by a lower case 'c'.
[0126]
1.22.1 Branch address
The branch address is encoded in the same way as in a conventional ETM implementation. The branch packet is still 1-5 bytes long, and the decompression tool must expect more bytes whenever the C bit is enabled. However, bit 0 of the branch address is no longer used to distinguish between Thum and ARM states. Instead, all branch addresses are prefixed with a 1 in the 33rd bit position and precompressed. When compressed, all branch addresses are suffixed with a 1 in the 0th bit position. Bit 0 1 identifies the packet as a branch address and bit 33 1 is used to help distinguish between ARM and Thumb addresses. Since the ARM address must be word aligned, only bits [31: 2] of the ARM address are broadcast. Since the Thumb address is limited to a half word, only bits [31: 1] need be broadcast. By broadcasting a different number of bits for the combined ARM and Thumb address and having the pre-compression with the 33rd bit always asserted, a complete 5-byte address is broadcast on transitions between ARM and Thumb states. Guarantee that. Furthermore, as shown in the table below, ARM and Thumb addresses can always be uniquely identified by the higher order bits of the fifth address byte.
[Table 8]

[0127]
If present, the branch target address is always the last item placed in the FIFO in a given cycle. Therefore, packet continuation bits (C bits) are unnecessary. Since the reason code is given as part of the TFO packet header, it is no longer broadcast with address bits 6: 4 in the fifth byte, which is discussed in section 5.4. Bit 6 of the fifth byte is used to indicate the exception branch address (indicated by 'E' in the table above). This bit is set on any branch by an interrupt, interrupt, or soft reset. This is useful to allow the decompressor to recognize and indicate to the user that these interrupted instructions were not actually executed. Bit 7 and bit 5 of the fifth address byte remain reserved for future use.
[0128]
1.22.2 Regular data
The regular data header is used for all load and store data packets that do not miss in the cache. If CPRT data tracing is enabled, it is also used for CPRT data packets. If data address tracing is enabled, the data address is broadcast after the header packet and before the data value, if present. The data address is broadcast using the same compression technique as the instruction branch address and therefore consists of 1-5 bytes. As with conventional ETM implementations, whether a data address is traced must be determined statically before tracing begins. If two regular data packets are given within a single cycle (by 64-bit data transfer), only the first packet contains the data address. When data for an LSM instruction is broadcast, the data address is broadcast only in the first data packet, even if subsequent data packets are transferred in different cycles. The 'A' bit in the canonical data header is used to specify that it is the first data packet for a particular instruction, and therefore a data address must be expected (address tracing is enabled) If). The availability of this information in the header byte allows the decompressor to maintain synchronization when tracing a non-expandable section of code (ie, any region where binary is not available). The 'A' bit is not asserted on CPRT packets.
[0129]
The 'MSS' bit in regular data encoding is used for data value compression. If the M bit is low, the SS bit specifies the size of the data value to be transferred. Leading zeros are removed as a simple form of data compression. Preliminary experiments show that this compression technique yields approximately 20-30% compression, which is sufficient to offset the additional bandwidth cost of header bytes. The encoding with the M bit set is preserved for future compression techniques. The exact encoding for the MSS bits is given in the table below.
[Table 9]

[0130]
1.22.3 Road mistake
The Load Miss Occurred and Load Miss Data header types handle missed load requests in the data cache. When a load miss occurs, a Load Miss Accured packet is placed in the FIFO where the data value is expected. When data address tracing is enabled, the packet contains a data address. Otherwise, the packet consists only of the Load Miss Accured header byte. When a Load Miss Occurred packet is read, the decompression software knows that the data value is a significant miss and it is returned later. When the data is returned, the PIPESTAT value for that cycle is modified to the '+ DATA' version and a Load Miss Data packet consisting of the Load Miss Data header byte and the actual data value is placed in the FIFO. The Load Miss Data packet does not contain a data address. Since the load / store unit must have a free cycle back to the Load Miss data, this data will not be returned in the same cycle as the data for another load or store request.
[0131]
The 'TT' bit in the Load Miss header type is used as a tag to identify each load miss. A Load Miss Accured packet always has the same tag value as its corresponding Load Miss Data packet. ARM 1020E supports only one significant load miss at a time, but can broadcast a second load miss packet before data for the first miss is returned. Thus, tag values 2'b00 and 2'b01 are supported on ETM10 rev0 to uniquely identify all load misses. Two bits are assigned to the tag field to support future processors that can tolerate more significant mistakes. In addition, ARM1020E always returns missed data in order (as opposed to other load misses), but this tagging mechanism supports future processors that can return missed data out of order.
[0132]
If a miss occurs on the 64-bit load value, two Load Miss packets are placed in the FIFO within the same cycle. Because both packets have the same tag value and are placed in the FIFO within the same cycle, the decompressor knows that these two misses are for a single 64-bit value. Similar to the regular data packet, the data address exists only in the first Load Miss packet, and does not exist when a mistake occurs in the middle of the LSM already broadcasting the data packet. When Load Miss data is returned for the 64-bit case, it is always returned as two separate Load Miss Data packets given in the same cycle. Both packets have the same mistag.
[0133]
Load miss data packets use MSS bits for size information and data compression performed on regular data. If the decompressor receives an unexpected Load Miss data packet (ie, a missed data packet is given without a pending missed packet with the same tag), it will skip over the specified number of bytes given in size. There must be. If tracing is disabled before significant miss data is returned, this data item is placed in a FIFO with 'DW' PIPESTAT as soon as it becomes available. If tracing is enabled due to an overflow or exit debug reason code, the decompressor must cancel any pending Load Miss packet.
[0134]
1.22.4 Auxiliary and full visibility data tracing
Auxiliary and full visibility data header encoding is a reserved slot reserved for extensibility within the protocol. These packet types can be used to trace auxiliary data internal and external to the processor (full visibility is to trace all register file updates). As with other data packets, the auxiliary data packet uses SS bits for size information. Full visibility data tracing also supports M bits for further compression. These packet types are not used on ETM10rev0.
[0135]
1.22.5 ContextID
The Context ID header byte is used only when the Context ID is modified via the Context ID update command, MCR c15,0, rd, c13, c0,1. The size of the data value is statically determined by the Context ID size specified in the ETM10 control register (register 0x0, bits [15:14]). Only the specified number of bytes is traced, even if the new value is greater than the specified number of bytes. If the size is specified as zero, the Context ID update is not traced. Even if the Context ID update instruction is MCR, the Context ID value tracing is completely independent of the tracing data values from other CPRT instructions. It is not affected by the Monitor CPRT bit in the ETM10 control register (register 0x0, bit [1]). By using a unique header value for the Context ID update, the decompressor recognizes the Context ID change even when tracing a non-decompressable code region (ie, any region where binary is not available). it can.
[0136]
1.22.6 Untraced values
Conventional ETM implementations are only able to trace all data values for LSM operations, and none can be traced, and this determination is made at the first transfer. This behavior is undesirable because today's compilers combine adjacent LDR / STR operations into the least noticeable LSM to the user. With the addition of Value Not Traced packets, we have added the ability to partially trace the LSM and output only data values that closely match the trigger criteria.
[0137]
Whenever the first data value associated with the LSM is traced, it is legal in the FIFO containing the data address (if address tracing is enabled) and the data value (if data value tracing is enabled). A data packet is placed. All subsequent data transfers for this LSM place the packet in the FIFO. If subsequent values are traced, regular data packets that give only data values are traced. If subsequent data transfers should not be traced, a Value Not Traced packet is placed on the FIFO for these transfers. A Value Not Traced packet consists only of Value Not Traced header bytes. The decompression software then uses Value Not Traced packets in combination with regular data packets to determine which LSM values are traced and which are not being traced by going backwards from the last data transfer. As noted above, when tracing begins on an LSM instruction, it should be understood that if TraceEnable is asserted before the instruction is completed, it will continue until LSM is complete.
[0138]
1.22.7 Save
There are a total of 10 saved slots remaining in the data header encoding. All of these slots can be utilized to enhance the protocol as needed and / or to be used in future ETM implementations. Even if more header types are required by future ETM implementations, the M bits in Normal Data and Full-Visibility Trace encoding may be used for new data header encoding instead of compression. it can.
[0139]
1.23 TFO packet header encoding
TFO packets are placed in the FIFO by TFO cycles (as described in section 5.2.4). Because the decompressor knows when a packet is placed in the FIFO by the TFO, the TFO packet has its own header byte encoding, which is completely independent of the encoding space used by the PIPESTAT data packet . TFO packet header encoding is shown below.
[Table 10]

[0140]
1.23.1 Instruction address
TRACEPKT [1: 0] for the first byte of the TFO packet! If = 2′b10, this TFO packet consists only of an instruction address. Since a complete address is always required, no compression is attempted and the address is always output as a 4-byte value. Bit 0 of the address specifies whether it is a Thumb or ARM instruction address. If a TFO packet consists only of an instruction address,
CONTEXT ID value is not traced (determined by ContextIDSize, ETM Control register bits [15:14])
-TFO reason code is 2'b00, normal synchronization
Means that.
If the reason code is non-zero or the TEXT ID value is traced, one of the following TFO packets is required: TFO packets consisting only of addresses are not strictly required for protocol compliance, and ETM10
Not implemented on rev0.
[0141]
1.23.2 Regular TFO packet
A regular TFO packet consists of header bytes followed by 0-4 bytes of CONTEXT ID, followed by a 4-byte instruction address. The number of TEXTID bytes traced is statically determined by the ETM Control register bits [15:14]. The instruction address is always 4 bytes and is not compressed. Bit 0 specifies the Thumb bit. The TFO header byte contains a 2-bit reason code (labeled RR in the table above). These reason codes are consistent with those used by ETM7 and ETM9 in protocol versions 0 and 1. Reason codes are given in the table below.
[Table 11]

[0142]
1.23.3 LSM in Progress TFO packet
LSM in the Progress packet occurs only when tracing is enabled in the middle of a multi-memory access instruction (LDM, STM, LDC, or STC) and another instruction is currently executing. These packets consist of header bytes followed by 0-4 bytes of CONTEXT ID, followed by a 4-byte instruction address for LSM, followed by 1-5 bytes of the compressed address for the currently executing instruction. The LSM instruction is a fixed 4-bit address where bit 0 specifies the Thumb bit. The current instruction address is compressed using the same technique as the branch address (as specified in section 5.3.1). The last instruction address is compressed with respect to the complete address from the LSM instruction. The next instruction PIPESTAT is for the instruction pointed to by the second address, and the trace starts in the normal way from this point in the forward direction. This packet type is necessary to properly trace all instructions that touch a particular data address or data value. Without it, LSM instructions cannot be traced properly based on the data address. Note that even if tracing is programmed to be turned on only during LSM itself, instructions that occur under LSM are traced. Similarly, if the trace is turned on by the instruction address of an instruction that just happens to run under LSM, the LSM in the Progress TFO packet is still output. To further clarify the difference between Normal TFO packets and LSM in Progress TFO packets, the following table shows the expected bytes for each case.
[Table 12]

[0143]
ARM10 TRACE interface
This section describes the signaling interface between ARM1020E and ETM10. Most interfaces are driven into ETM 10 by ARM1020E. The signal description is split into custom data path inputs, synthesis control inputs, and ETM outputs. Although the synthesis control signals can be changed later, they cannot be changed later in the design because custom logic rework is required to change the data path signals. All inputs are stored immediately inside the ETM 10 and all outputs are driven directly from the output of the register. The interface consists of a total of 220 signals, including 213 inputs and 4 outputs from the ETM10 landscape.
[0144]
1.24 ETM Data input
There are four data buses of interest for ETM data tracing: load data, store data, MCR data, and MRC data. All four buses are 64 bits wide. Since only one of these buses may contain valid data in any given cycle, all four buses are messed up in the ARM 1020E and become a 64-bit data bus ETMDATA. ETMDATA is driven into ETM after being stored in ARM1020E. ETMDATA is valid at the write (WR) stage of the ARM1020E pipeline. There are four address buses driven from ARM1020E to ETM10. Three of these buses are for instruction addresses and one is for data addresses. The R15 bus is driven to ETM during the execution (EX) phase of the ARM1020E pipeline while the IA and DA address buses are valid during the memory (ME) phase. All data buses driven to the ETM are given in the table below.
[Table 13]

[0145]
1.25 ETM control input
1.25.1 ETMCORECTL [23: 0]
ETMCORECTL contains various control signals that all come from the ARM10 core. All of these signals are stored in the core and coupled to this common bus before being driven to ETM10. The control signals present on this bus and their meanings are given in the table below. All of these are valid in the write phase (WR) of the ARM1020E pipeline, unless otherwise noted.
[Table 14]

[0146]
1.25.2 ETMDATAVALID [1: 0]
This signal limits the data driven on the bus ETMDATA [63: 0]. There is one bit for every half of the data bus.
[0147]
1.26 ETM output
This section describes the output required from and returned to the ARM1020E.
[0148]
1.26.1 FIFOFULL
When enabled, the ETM output FIFOFULL is asserted whenever there are bytes placed in the FIFO, and remains asserted until the FIFO is empty. This behavior is somewhat different from ETM7 / 9, which waited until the FIFO reaches a certain level before asserting FIFOFULL (see chapter 4.16). FIFOFULL is used by the core, here ARM1020E, to stop the ARM pipeline. This prevents ETM overflow and ensures a complete trace, although side effects occur in the core that slightly change the timing of the event. Since the timing is taken into account, the ARM1020E does not stop immediately due to the assertion of FIFOFULL. Thus, although rare, it is possible to have overflow even when FIFOFULL is asserted. When this occurs, the number of missed instructions is small because the processor remains stalled (due to a FIFOFULL assertion) while the FIFO is gradually emptied.
[0149]
1.26.2 PWRDOWN
If high, this indicates that ETM is not currently enabled and the CLK input can be stopped. This is used to reduce power consumption when traces are not used. When reset, PWRDOWN is asserted until ETM10 has been programmed. The ARM10200 test chip must use the PWRDOWN output directly to gate the ETM10 CLK input. As noted above, PWRDOWN is temporarily disabled on CONTEXT ID updates to allow for updates on the ETM10 internal CONTEXT ID shadow register. Except for the CONTEXT ID update case, PWRDOWN is changed synchronously with TCLK and cleared by the ARM debug tool at the beginning of the debug session. Because PWRDOWN changes cycle before the trace is enabled, using the TCLK base signal to gate ETM10 CLK does not cause metastability issues.
[0150]
1.26.3 DBGRQ
Similar to conventional ETM, ETM 10 can be programmed to assert DBGRQ whenever a trigger condition occurs. DBGRQ will remain asserted until DGBACK is observed. DBGRQ must be connected to the ARM1020E external debug request pin EDGRQ. This ETM output does not require extra support from the ARM1020E. Multiple DBGRQ signals can be ORed together if the EDBGRRQ input is already in use by another functional block in the ASIC. Note that enabling debugging in this way does not guarantee that any particular instruction boundary will be encountered. Furthermore, if the ARM 10 is currently in hardware debug mode, the core only recognizes EDGRQ.
[0151]
1.26.4 TDO
ETM10 uses the same TAP interface wiring as the traditional ETM version. The TDO pin is connected to the ARM1020E scan extension input SDOUTBS. The ETM10 register is accessed via the scan chain 6 and programmed in the same way as a conventional ETM implementation. This ETM output does not require extra support from the ARM1020E.
[0152]
Constitution
ETM7 / 9 is available in small, medium and large configurations. Medium and large configurations provide more trigger hardware resources and increased FIFO depth at additional area costs. Different configurations for different ASIC applications can be selected by simply re-synthesizing the new configuration soft macro. ETM10 provides a similar range of configurations. The table below shows the configurations currently presented for ETM10. Most trigger resources are the same as ETM7 and ETM9, with the exception of large data comparators that are reduced from 8 to 4 due to the large size of the 64-bit comparators. The increased FIFO size in each configuration reflects the need to support the higher instruction throughput (ie, performance) of ARM1020E. The FIFO size for each configuration can be increased based on area impact and feedback from performance modeling. The gate count given for the ETM10 configuration is an estimate based on the initial synthesis of the ETM10 rt1 model. These estimated gate counts may differ from those achieved by the final implementation. The large size ETM10 is to be placed on an ARM10200 test chip. The corresponding number of resources for ETM9 within each category is given in parentheses for comparison.
[Table 15]

[0153]
While specific embodiments have been described, it is clear that the invention is not limited thereto and that many modifications and additions can be made within the scope of the invention. For example, the features of the dependent claims can be variously combined with the features of the independent claims without departing from the scope of the invention.
[Brief description of the drawings]
FIG. 1 is a schematic diagram illustrating a data processing system that provides an on-chip tracing mechanism.
FIG. 2 is a block diagram showing details of elements provided in the on-chip trace module of FIG. 1;
FIG. 3 is a schematic diagram illustrating the encoding used in the preferred embodiment of the present invention to incorporate instruction addresses into instruction set information.
FIG. 4 is a schematic diagram showing how addresses encoded according to the method shown in FIG. 3 are compressed according to a preferred embodiment of the present invention.
FIG. 5 is a schematic diagram showing the output of compression logic for an example of a three instruction sequence.
FIG. 6 is a block diagram that schematically illustrates encoding and compression logic used in accordance with a preferred embodiment of the present invention.
7 is a schematic diagram illustrating the operation of the 33-bit sector of FIG. 6;
8 is a schematic diagram showing one structure of the comparator shown in FIG. 6;
FIG. 9 illustrates the logic used in the preferred embodiment to implement the continuous bit generator shown in FIG.
FIG. 10 is a schematic diagram illustrating the process performed by the compression encoded instruction address generator of the preferred embodiment.
[Explanation of symbols]
2 Data processing system
4 Integrated circuits
6 Microprocessor core
8 Cache memory
10 On-chip trace module controller
12 On-chip trace buffer
14 External memory
16 General-purpose computer
18 External storage
100 synchronization logic
110 Trigger
120 Control logic
610,800,820 registers
620 33-bit sector logic
630 latch
622, 623, 624, 625 7-bit wide bus
640, 650, 660, 670 comparator
680 continuous bit generator
690 Compression encoded instruction address generator
700 multiplexer
830 comparator logic
910, 920, 930 OR gate

Claims (22)

A data processing device, the device comprising:
A processing circuit that executes a processing instruction from any of a plurality of instruction sets of processing instructions, each processing instruction specified by an instruction address that identifies the location of the processing instruction in memory, and the instruction address is associated It has a predetermined number of bits regardless of the instruction set to which the processing instruction belongs, but it is necessary to specify a different number of most significant instruction address bits in the instruction address that uniquely identifies the processing instruction in the different instruction set A processing circuit;
Encoding logic that encodes at least one instruction address having an indication of an instruction set corresponding to the instruction to generate an n-bit encoded instruction address, wherein the encoding logic needs to be specified By performing the equivalent of extending the specified instruction address bits to n- bits by removing any least significant bits that do not form bits and prepending the bit pattern to the specified instruction address bits Encoding logic, wherein the least significant bits removed and the prepended bit pattern are determined by the instruction set corresponding to the instruction;
Including the device. The apparatus of claim 1, wherein the encoding logic is provided in a trace module used to trace processing circuit activity.   2. The apparatus of claim 1, wherein for each instruction set, the bit pattern prepended to the designated instruction address bit of the instruction address from the instruction set is designated by an instruction address of a different instruction set depending on the shifted pattern. Associated with a bit pattern prepended to a designated instruction address bit.   2. The apparatus according to claim 1, wherein the encoding logic prepends a predetermined bit pattern to an instruction address bit designated by an instruction address, and then selects n bits from an intermediate value as an encoded instruction address. An apparatus adapted to perform encoding by performing a calculation equivalent to generating an intermediate value.   The apparatus of claim 1, further comprising: dividing the encoded instruction address into a plurality of x-bit sections and comparing each x-bit section with each corresponding x-bit section of the preceding encoded instruction address. And, as a compressed encoded instruction address, performs a calculation equivalent to outputting the most significant x-bit section different from the corresponding x-bit section of the preceding encoded instruction address together with any lower-order x-bit section. An apparatus including compression logic for compressing the encoded instruction address. 6. The apparatus of claim 5 , wherein the compression logic indicates for each x-bit section output therefrom whether the x-bit section is the last x-bit section output as a compression encoded instruction address. A device that is associated with a flag. 7. The apparatus of claim 6 , wherein when a plurality of x-bit sections are output from the compression logic, the plurality of x-bit sections are sequentially output starting with the least significant x-bit section. 7. The apparatus of claim 6 , wherein the compression logic is further adapted to extend each x-bit section output from the compression logic to y bits, with the most significant y-x bits including a flag. . The apparatus of claim 8 , wherein the flag is a single bit. The apparatus of claim 9 , wherein y is 8 and x is 7.   The apparatus of claim 1, wherein the encoding logic includes an n-bit sector logic unit that receives the intermediate value and an identifier signal that identifies an instruction set associated with the instruction address contained within the intermediate value, A device in which a bit sector outputs a predetermined n-bit of an intermediate value in response to an identifier signal. 6. The apparatus of claim 5 , wherein the compression logic includes a plurality of comparators, each comparator adapted to receive a corresponding x-bit section of the encoded instruction address, and the preceding encoded instruction. Including a temporary storage that stores a corresponding x-bit section of the address, the comparator compares the two x-bit sections and generates a difference signal that is set if the two x-bit sections are different Equipment. 13. The apparatus of claim 12 , wherein the compression logic is further generated by a plurality of comparators such that a flag for a particular x-bit section is set if a higher order x-bit section is also output. An apparatus adapted to generate a flag based on a predetermined combination of difference signals to be generated for each x-bit section output from the compression logic. 14. The apparatus of claim 13 , wherein the compression logic further generates a compressed encoded instruction address by prepending its corresponding flag to each x-bit section to be output, as an output compressed encoded instruction address. An apparatus including an output generator for generating a row of y-bit sections. 6. The apparatus of claim 5 , wherein the encoding logic and compression logic are provided in a trace module used to trace processing circuit activity. A tracing tool for a data processing device, the data processing device having a processing circuit for executing a processing instruction from any of a plurality of instruction sets of processing instructions, each processing instruction being a location of the processing instruction in a memory The instruction address has a predetermined number of bits regardless of the instruction set to which the associated processing instruction belongs, but in the instruction address that uniquely identifies the processing instruction in a different instruction set. It is necessary to specify a different number of most significant instruction address bits, and the tracing tool
Including encoding logic that encodes at least one instruction address having an instruction set indication corresponding to the instruction to generate an n-bit encoded instruction address, the encoding logic being an instruction address bit that needs to be specified Sign by performing a calculation equivalent to extending the specified instruction address bits to n- bits by removing any least significant bits that do not form, and prepending a bit pattern to the specified instruction address bits A tracing tool in which the number of least significant bits to be removed and the prepended bit pattern are determined by the instruction set corresponding to the instruction. The apparatus of claim 16 , further comprising dividing the encoded instruction address into a plurality of x-bit sections and comparing each x-bit section with a corresponding x-bit section of the preceding encoded instruction address; Performing a calculation equivalent to outputting the most significant x-bit section different from the corresponding x-bit section of the preceding encoded instruction address as a compressed encoded instruction address with any lower-order x-bit section. A tracing tool that includes compression logic to compress encoded instruction addresses. A method of storing instruction set information, wherein a processing circuit executes a processing instruction from one of a plurality of instruction sets of processing instructions, and each processing instruction identifies the location of the processing instruction in memory The instruction address has a predetermined number of bits regardless of the instruction set to which the associated processing instruction belongs, but in the instruction address to uniquely identify the processing instruction in a different instruction set. It is necessary to specify a different number of most significant instruction address bits, and the method
Remove any least significant bits that do not form instruction address bits that need to be specified;
Extending the specified instruction address bits to n-bits by prepending the bit pattern to the specified instruction address bits;
Encoding at least one instruction address having an indication of the instruction set corresponding to the instruction to generate an n-bit encoded instruction address by performing a calculation equivalent to
A method in which the number of least significant bits removed and the prepended bit pattern are determined by the instruction set corresponding to the instruction. The method of claim 18 , further comprising:
(A) dividing the encoded instruction address into a plurality of x-bit sections;
(B) compare each x-bit section with the corresponding x-bit section of the preceding encoded instruction address;
(C) outputting the most significant x-bit section different from the corresponding x-bit section of the preceding encoded instruction address as a compressed encoded instruction address together with any lower-order x-bit section;
Compressing the encoded instruction address by performing a calculation equivalent to. (I) determine the number of x-bit sections forming the compression-encoded instruction address;
(Ii) Encoded instruction address by extending the compressed encoded instruction address to n-bits as necessary by incorporating additional x-bit sections derived from the corresponding x-bit section of the preceding encoded instruction address Producing,
20. A method of decompressing a compression-encoded instruction address generated according to the method of claim 19 by performing a calculation equivalent to. 21. The method of claim 20 , further comprising determining an instruction set associated with an instruction address from a predetermined bit pattern and removing the predetermined bit pattern to obtain a specified instruction address bit. Decoding the encoded instruction address by performing an equivalent calculation. 19. A computer program that is loaded into a computer and operates to control the apparatus according to the method of claim 18 .

Images