JP2003150403A - データプロセッサの観測方法及び装置 - Google Patents
データプロセッサの観測方法及び装置Info
- Publication number
- JP2003150403A JP2003150403A JP2002132057A JP2002132057A JP2003150403A JP 2003150403 A JP2003150403 A JP 2003150403A JP 2002132057 A JP2002132057 A JP 2002132057A JP 2002132057 A JP2002132057 A JP 2002132057A JP 2003150403 A JP2003150403 A JP 2003150403A
- Authority
- JP
- Japan
- Prior art keywords
- data
- unit
- trace
- packet
- rtt
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Landscapes
- Debugging And Monitoring (AREA)
- Test And Diagnosis Of Digital Computers (AREA)
- Microcomputers (AREA)
Abstract
(57)【要約】
【課題】 正確かつ非強制的なトレース及びデバッグ機
能を提供する、一つ以上のデータプロセッサで使用する
ために改良したトレース構造及び方法を提供する。 【解決手段】 一つの態様において、動作中のプロセッ
サからデータと情報を得て、プロセッサ動作の多様な様
相に関連した複数のデータパケットを生成するように適
用された、トレースユニットを含む。例示的な実施例に
おいて、トレースユニットは特定機能を有する複数のデ
ータパケットとしてそれぞれエンコードされる命令、デ
ータ及びタイミングトレースを生成するように適用され
る。パケットは一つ以上のバッファに格納され、これら
のバッファはデバッグポート及びディバイスに関連した
専用パケットポートによりアクセスできる。トレースユ
ニット、プロセッサ、及びバッファは単一の集積回路デ
ィバイスに配置される。他の実施例において、多重プロ
セッサコアとトレースユニットを提案する。データパケ
ット圧縮のための構造も開示する。
能を提供する、一つ以上のデータプロセッサで使用する
ために改良したトレース構造及び方法を提供する。 【解決手段】 一つの態様において、動作中のプロセッ
サからデータと情報を得て、プロセッサ動作の多様な様
相に関連した複数のデータパケットを生成するように適
用された、トレースユニットを含む。例示的な実施例に
おいて、トレースユニットは特定機能を有する複数のデ
ータパケットとしてそれぞれエンコードされる命令、デ
ータ及びタイミングトレースを生成するように適用され
る。パケットは一つ以上のバッファに格納され、これら
のバッファはデバッグポート及びディバイスに関連した
専用パケットポートによりアクセスできる。トレースユ
ニット、プロセッサ、及びバッファは単一の集積回路デ
ィバイスに配置される。他の実施例において、多重プロ
セッサコアとトレースユニットを提案する。データパケ
ット圧縮のための構造も開示する。
Description
【0001】
【発明の属する技術分野】本出願は、2001年11月
6日付けで出願され、発明の名称が“データプロセッサ
の観測方法及び装置“である米国仮特許出願第60/3
38,869号を優先権として主張する。
6日付けで出願され、発明の名称が“データプロセッサ
の観測方法及び装置“である米国仮特許出願第60/3
38,869号を優先権として主張する。
【0002】著作権
この特許文書の開示部分は、著作権の保護を受ける資料
を含んでいる。この著作権者は、特許及び商標庁の特許
ファイルまたは記録物にあるように、特許文書または特
許の開示に関するいかなる者によるファックス複製に対
し異議を申し立てることはないが、いかなる場合も著作
権はすべて保有されている。
を含んでいる。この著作権者は、特許及び商標庁の特許
ファイルまたは記録物にあるように、特許文書または特
許の開示に関するいかなる者によるファックス複製に対
し異議を申し立てることはないが、いかなる場合も著作
権はすべて保有されている。
【0003】発明の背景
本発明は、デジタルデータプロセッサの分野に関するも
ので、より詳細には、このようなプロセッサの動作に関
連したデータ及びコードの観測及びトレース並びにこれ
に関連した構造に関するものである。
ので、より詳細には、このようなプロセッサの動作に関
連したデータ及びコードの観測及びトレース並びにこれ
に関連した構造に関するものである。
【0004】
【関連技術】トレース機能は、特に、設計者またはユー
ザーが一つ以上のデジタルプロセッサまたは他の集積回
路内に発生するソフトウェア動作の実行結果を観測する
ことを可能にするために使われる。トレース機能は、一
般的に、たとえば一つのプログラムの各命令または所定
数の命令の実行以後、メモリの選択された部分、プログ
ラムカウンタ(PC)、及び/または選択された間隔でプロ
セッサのレジスタの状態を提供する。これらの多様な構
成要素の状態を記録することで、トレース機能は、プロ
セッサの内部動作とプログラムの実行に関する詳細な情
報をユーザーに提供する。このような情報を利用して、
多くの形態の設計またはコーディングエラーを確認する
ことができ、後で訂正することができる。これは、アー
キテクチャーまたはコード変換の否定的な影響が、設計
工程がさらに進行する前に容易に決定できるため、プロ
セッサの設計及び開発段階において特に有用である。
ザーが一つ以上のデジタルプロセッサまたは他の集積回
路内に発生するソフトウェア動作の実行結果を観測する
ことを可能にするために使われる。トレース機能は、一
般的に、たとえば一つのプログラムの各命令または所定
数の命令の実行以後、メモリの選択された部分、プログ
ラムカウンタ(PC)、及び/または選択された間隔でプロ
セッサのレジスタの状態を提供する。これらの多様な構
成要素の状態を記録することで、トレース機能は、プロ
セッサの内部動作とプログラムの実行に関する詳細な情
報をユーザーに提供する。このような情報を利用して、
多くの形態の設計またはコーディングエラーを確認する
ことができ、後で訂正することができる。これは、アー
キテクチャーまたはコード変換の否定的な影響が、設計
工程がさらに進行する前に容易に決定できるため、プロ
セッサの設計及び開発段階において特に有用である。
【0005】いわゆる“ブレークポイント”の機能もプ
ロセッサのアーキテクチャーまたはコード内の問題点を
確認し防止するための手段を提供する。ブレークポイン
トの機能は、しばしば一つの命令で実現され、通常オペ
レーションの要求時、いかなる形の直接的な介入なし
で、プロセッサにさらなる命令の実行を中断させる。一
旦ブレークポイント命令がパイプラインにより実行され
ると、プロセッサは、実行を再開すべきことを知らせる
インターラプトのような何らかの外部信号を受信するま
でさらなる処理を中断する。ブレーク中、データは、パ
イプライン、メモリ、多様なレジスタ、またはプログラ
ムの状態を決定するために格納され及び/または検索さ
れ、要素内のエラーの確認を容易にする。
ロセッサのアーキテクチャーまたはコード内の問題点を
確認し防止するための手段を提供する。ブレークポイン
トの機能は、しばしば一つの命令で実現され、通常オペ
レーションの要求時、いかなる形の直接的な介入なし
で、プロセッサにさらなる命令の実行を中断させる。一
旦ブレークポイント命令がパイプラインにより実行され
ると、プロセッサは、実行を再開すべきことを知らせる
インターラプトのような何らかの外部信号を受信するま
でさらなる処理を中断する。ブレーク中、データは、パ
イプライン、メモリ、多様なレジスタ、またはプログラ
ムの状態を決定するために格納され及び/または検索さ
れ、要素内のエラーの確認を容易にする。
【0006】前述したトレース及びブレークポイント機
能は、いずれも従来技術のデータプロセッサ(及び関連
システム)内に統合されてきた。トレース設備を使用す
るために、このような従来技術のアプリケーションでプ
ロセッサを使用するソフトウェアは、通常フォールト処
理手続またはデバッギングモニタープログラムとのイン
ターフェースを提供しなければならない。また、ソフト
ウェアは、多様なトレースモードをイネーブルとし、ト
レース機能を選択的にイネーブルまたは使用不可とする
ために、レジスタとレジスタの制御ビットを処理するこ
とが要求される。
能は、いずれも従来技術のデータプロセッサ(及び関連
システム)内に統合されてきた。トレース設備を使用す
るために、このような従来技術のアプリケーションでプ
ロセッサを使用するソフトウェアは、通常フォールト処
理手続またはデバッギングモニタープログラムとのイン
ターフェースを提供しなければならない。また、ソフト
ウェアは、多様なトレースモードをイネーブルとし、ト
レース機能を選択的にイネーブルまたは使用不可とする
ために、レジスタとレジスタの制御ビットを処理するこ
とが要求される。
【0007】これら従来技術のデバイスのデバッグ機能
は、しばしばプロセッサに通常の動作を中断させ、特定
のデバッグモードまたは例外ルーチンに入ることを要求
する。このようなモードでは、プロセッサは、ノーマル
動作中のように動作しないので、(i)このようなモード
中に観測された故障は、“正常”プロセッサ動作中には
発生しないことがあり、(ii)ノーマル動作中に発生する
故障は、観測又はキャプチャーされないこともある。こ
のような点がデバッグプロセッサに関する重要な障害で
ある。
は、しばしばプロセッサに通常の動作を中断させ、特定
のデバッグモードまたは例外ルーチンに入ることを要求
する。このようなモードでは、プロセッサは、ノーマル
動作中のように動作しないので、(i)このようなモード
中に観測された故障は、“正常”プロセッサ動作中には
発生しないことがあり、(ii)ノーマル動作中に発生する
故障は、観測又はキャプチャーされないこともある。こ
のような点がデバッグプロセッサに関する重要な障害で
ある。
【0008】これに加えて、多くの従来技術のアプロー
チは、トレース及びブレークポイント機能の動作中にプ
ログラムの制御を提供するためにプロセッサにより実行
される内部デバッグプログラムを必要とする。このよう
な制御構造は、本質的に非常に「強制的」であり、従っ
てプロセッサのノーマル動作及びそれに関連した任意の
フォールトまたはバグを観測するのに適切でない。
チは、トレース及びブレークポイント機能の動作中にプ
ログラムの制御を提供するためにプロセッサにより実行
される内部デバッグプログラムを必要とする。このよう
な制御構造は、本質的に非常に「強制的」であり、従っ
てプロセッサのノーマル動作及びそれに関連した任意の
フォールトまたはバグを観測するのに適切でない。
【0009】既存のプロセッサトレース技術に対するも
う一つの障害は、トレースに関する情報がデコードされ
る前に完全なトレースが存在しなければならないという
必要性に関するものである。特に、トレースの開始が何
らかの理由で喪失されると、トレースの残りは、トレー
スの開始時に存在する損失された情報のためデコードす
ることが出来ない。
う一つの障害は、トレースに関する情報がデコードされ
る前に完全なトレースが存在しなければならないという
必要性に関するものである。特に、トレースの開始が何
らかの理由で喪失されると、トレースの残りは、トレー
スの開始時に存在する損失された情報のためデコードす
ることが出来ない。
【0010】さらに、トレースデータが膨大な量のメモ
リ空間を消費するため、既存のトレース手法に関連した
オンチップメモリの要件は高くなる。同様に、トレース
データをチップ外に伝送するのに多大な帯域幅が必要で
あり、このため、トレース動作の速度が低下し、データ
用の膨大な量のチップバッファリングを必要とする。
リ空間を消費するため、既存のトレース手法に関連した
オンチップメモリの要件は高くなる。同様に、トレース
データをチップ外に伝送するのに多大な帯域幅が必要で
あり、このため、トレース動作の速度が低下し、データ
用の膨大な量のチップバッファリングを必要とする。
【0011】したがって、正確で且つ非強制的なトレー
ス及びデバッグ機能を提供する一つ以上のデータプロセ
ッサで使用するための改善されたトレースの構造及び方
法に対する必要性が存在する。このような構造と方法
は、最小限のチップメモリと帯域幅要件をもって、リア
ルタイム観測を可能にし、PC、メモリ及び命令の周期実
行に関連したイベントを含む、一つ以上のプロセッサ内
の重要なイベントの複製を可能にするはずである。この
ような改善された構造及び方法は、構成において非常に
柔軟性があるので、ユーザーは、トレースを特定アプリ
ケーションに適応させることが可能になる。
ス及びデバッグ機能を提供する一つ以上のデータプロセ
ッサで使用するための改善されたトレースの構造及び方
法に対する必要性が存在する。このような構造と方法
は、最小限のチップメモリと帯域幅要件をもって、リア
ルタイム観測を可能にし、PC、メモリ及び命令の周期実
行に関連したイベントを含む、一つ以上のプロセッサ内
の重要なイベントの複製を可能にするはずである。この
ような改善された構造及び方法は、構成において非常に
柔軟性があるので、ユーザーは、トレースを特定アプリ
ケーションに適応させることが可能になる。
【0012】
【発明を解決するための手段】本発明の第1の態様にお
いて、一つ以上のデジタルプロセッサデバイスからデー
タトレースを獲得し格納するための改善された装置が開
示される。例示的な一実施形態において、この装置は、
プロセッサ(単数又は複数)と関連した少なくとも一つ
のトレース要素であり、プロセッサ(単数又は複数)の
動作と関連した多数のトレースデータを生成するように
適用された少なくとも一つのトレース要素と、デバッグ
または他のデータポートと、前記ポート及びプロセッサ
(単数又は複数)とデータ通信するホストデバイスであ
って、トレース要素(単数又は複数)により生成された
多数のトレースデータを格納するように適用されるホス
トデバイスとを含む。また、データバッファが提供され
る、トレースデータは、ホストデバイスに読み取られて
出力される前に、このデータバッファに一時的に格納さ
れる。第2の例示的な実施形態において、この装置は、
第2のデータポート(たとえば、“パケット”ポート)を
介してトレース要素とデータ通信するデータキャプチャ
ー/アナライザーユニットをさらに含む。
いて、一つ以上のデジタルプロセッサデバイスからデー
タトレースを獲得し格納するための改善された装置が開
示される。例示的な一実施形態において、この装置は、
プロセッサ(単数又は複数)と関連した少なくとも一つ
のトレース要素であり、プロセッサ(単数又は複数)の
動作と関連した多数のトレースデータを生成するように
適用された少なくとも一つのトレース要素と、デバッグ
または他のデータポートと、前記ポート及びプロセッサ
(単数又は複数)とデータ通信するホストデバイスであ
って、トレース要素(単数又は複数)により生成された
多数のトレースデータを格納するように適用されるホス
トデバイスとを含む。また、データバッファが提供され
る、トレースデータは、ホストデバイスに読み取られて
出力される前に、このデータバッファに一時的に格納さ
れる。第2の例示的な実施形態において、この装置は、
第2のデータポート(たとえば、“パケット”ポート)を
介してトレース要素とデータ通信するデータキャプチャ
ー/アナライザーユニットをさらに含む。
【0013】本発明の第2の態様において、改善された
集積回路デバイスが開示される。このデバイスは、一般
的に多数の論理ゲートが形成された一つ以上のダイ(di
e)(たとえばシリコンまたは同等な半伝導性基板)を含
む。例示的な一実施形態において、このデバイスは、少
なくとも一つのプロセッサコア、少なくとも一つのトレ
ースユニット、少なくとも一つのプロセッサコアとデー
タ通信するデバッグポートと、トレースユニットとデー
タ通信するパケットポートとが配列された単一のダイIC
(ASICまたはFPGAなど)を含む。また、関連メモリポート
を備えたメモリコントローラーが提供されるが、このよ
うなメモリコントローラーは、プロセッサコアとデータ
通信する。
集積回路デバイスが開示される。このデバイスは、一般
的に多数の論理ゲートが形成された一つ以上のダイ(di
e)(たとえばシリコンまたは同等な半伝導性基板)を含
む。例示的な一実施形態において、このデバイスは、少
なくとも一つのプロセッサコア、少なくとも一つのトレ
ースユニット、少なくとも一つのプロセッサコアとデー
タ通信するデバッグポートと、トレースユニットとデー
タ通信するパケットポートとが配列された単一のダイIC
(ASICまたはFPGAなど)を含む。また、関連メモリポート
を備えたメモリコントローラーが提供されるが、このよ
うなメモリコントローラーは、プロセッサコアとデータ
通信する。
【0014】第2の例示的な実施形態において、ICデバ
イスは、多数のプロセッサコアとトレースユニットとを
含み、トレースユニットと通信するマルチコアトレース
インターフェース(MTI)をさらに含み、MTIは、多数のト
レースユニット(及び関連プロセッサコア)を仲裁し、デ
バイス上に配置されたより少ない数(例えば1つ)のパケ
ットポートとインターフェースする。このデバイスは、
より少ない数のデバッグポート(及び関連デバッグプロ
グラムホスト)とノーマルチコア/トレースユニットイン
ターフェースを許容するマルチコアデバッグインターフ
ェース(MDI)デバイスをさらに含む。
イスは、多数のプロセッサコアとトレースユニットとを
含み、トレースユニットと通信するマルチコアトレース
インターフェース(MTI)をさらに含み、MTIは、多数のト
レースユニット(及び関連プロセッサコア)を仲裁し、デ
バイス上に配置されたより少ない数(例えば1つ)のパケ
ットポートとインターフェースする。このデバイスは、
より少ない数のデバッグポート(及び関連デバッグプロ
グラムホスト)とノーマルチコア/トレースユニットイン
ターフェースを許容するマルチコアデバッグインターフ
ェース(MDI)デバイスをさらに含む。
【0015】本発明の第3の態様において、プログラム
の実行中に一つ以上のプロセッサからトレースデータを
獲得する方法が開示される。この方法は、概略的に、プ
ロセッサからデータを受信するように適用されたトレー
スユニットを提供することと、受信されたデータに基づ
いてプロセッサの動作に関連した多数のパケットを生成
することと、多数のパケットのうち少なくとも一部を格
納デバイスに格納することと、プロセッサの動作に関連
した情報を得るために格納されたパケットの少なくとも
一部を分析することを含む。例示的な一実施形態におい
て、トレースユニットは、プロセッサの動作の多様な他
の態様に関連した4種類の明確なトレース(すなわち、
命令、データ、タイミング及び雑多な、または選択的な
命令、データ、イベント及びタイミングトレース)の生
成のために適用される。一つ以上の内部モニターは、ト
レースユニットに提供するためのプロセッサデータの獲
得を制御する。トレースユニットは、モニターされてい
るプロセッサから受信された入力(たとえば、トレース
ユニットのレジスタ空間に対する記録)と、選択的な外
部及びユーザー入力に基づいてOFF、RUN及びTRIGGERED
動作状態間で転換される。トレースユニットにより生成
されたパケットは、情報の形態及び生成されるトレース
と、ユーザー/設計者から受信された他の入力によって
固有にフォーマットされ、格納デバイスから提供される
パケットストリームの後続の分析を容易にする。
の実行中に一つ以上のプロセッサからトレースデータを
獲得する方法が開示される。この方法は、概略的に、プ
ロセッサからデータを受信するように適用されたトレー
スユニットを提供することと、受信されたデータに基づ
いてプロセッサの動作に関連した多数のパケットを生成
することと、多数のパケットのうち少なくとも一部を格
納デバイスに格納することと、プロセッサの動作に関連
した情報を得るために格納されたパケットの少なくとも
一部を分析することを含む。例示的な一実施形態におい
て、トレースユニットは、プロセッサの動作の多様な他
の態様に関連した4種類の明確なトレース(すなわち、
命令、データ、タイミング及び雑多な、または選択的な
命令、データ、イベント及びタイミングトレース)の生
成のために適用される。一つ以上の内部モニターは、ト
レースユニットに提供するためのプロセッサデータの獲
得を制御する。トレースユニットは、モニターされてい
るプロセッサから受信された入力(たとえば、トレース
ユニットのレジスタ空間に対する記録)と、選択的な外
部及びユーザー入力に基づいてOFF、RUN及びTRIGGERED
動作状態間で転換される。トレースユニットにより生成
されたパケットは、情報の形態及び生成されるトレース
と、ユーザー/設計者から受信された他の入力によって
固有にフォーマットされ、格納デバイスから提供される
パケットストリームの後続の分析を容易にする。
【0016】本発明の第4態様において、前述した一つ
以上のトレースと関連したデータを圧縮するための改善
された方法及び装置が開示される。このような圧縮の使
用は、必要なバッファサイズ及び必要なトレースピンの
帯域幅(格納費用)を有利に減少させる。例示的な一実施
形態において、可変長エンコード技術が使用され、頻度
値の決定されたまたは予め格納された確率分布に基づい
て、高い頻度の値を表すために、制限されたサイズのコ
ードが使用され、低い頻度の値を表すために、大きいコ
ードが使用される。一つの変形した実施形態において、
データの多数の“ニブル(nibble) ” (たとえば4ビッ
ト)としてRTTコードが選択される。
以上のトレースと関連したデータを圧縮するための改善
された方法及び装置が開示される。このような圧縮の使
用は、必要なバッファサイズ及び必要なトレースピンの
帯域幅(格納費用)を有利に減少させる。例示的な一実施
形態において、可変長エンコード技術が使用され、頻度
値の決定されたまたは予め格納された確率分布に基づい
て、高い頻度の値を表すために、制限されたサイズのコ
ードが使用され、低い頻度の値を表すために、大きいコ
ードが使用される。一つの変形した実施形態において、
データの多数の“ニブル(nibble) ” (たとえば4ビッ
ト)としてRTTコードが選択される。
【0017】第2の実施形態において、或る値の一部分
だけを格納するためにデルタエンコーディングが使われ
る。この格納された部分は、トレースにおいて以前にエ
ンコードされた値の参照のために使われる。参照値と他
のニブル(すなわちデルタ)だけがエンコードされる。
だけを格納するためにデルタエンコーディングが使われ
る。この格納された部分は、トレースにおいて以前にエ
ンコードされた値の参照のために使われる。参照値と他
のニブル(すなわちデルタ)だけがエンコードされる。
【0018】第3の実施形態において、ランレングス(r
un-length)エンコードが使われる。このような実現法に
おいて、それぞれの個別イベントを別途に確認し格納す
る反面、繰り返されるイベントは、確認し且つカウント
する。このような技術は、同一形態のイベントのシーケ
ンスまたは実行が存在する時に最も有用である。
un-length)エンコードが使われる。このような実現法に
おいて、それぞれの個別イベントを別途に確認し格納す
る反面、繰り返されるイベントは、確認し且つカウント
する。このような技術は、同一形態のイベントのシーケ
ンスまたは実行が存在する時に最も有用である。
【0019】第4の実施形態において、ソース-コード
参照技術が採用される。このような実現法において、コ
ンパイルされたソースコードのテストにより誘導され得
る情報は格納されないので、格納の諸経費を減少させ
る。
参照技術が採用される。このような実現法において、コ
ンパイルされたソースコードのテストにより誘導され得
る情報は格納されないので、格納の諸経費を減少させ
る。
【0020】本発明の第5の態様において、データパケ
ットローディングの改善された方法が開示される。一実
施形態において、データニブルのビットは、望ましい処
理特性を生成するために所定値に詰め込まれる。
ットローディングの改善された方法が開示される。一実
施形態において、データニブルのビットは、望ましい処
理特性を生成するために所定値に詰め込まれる。
【0021】本発明の第6の態様において、前述したト
レースユニットに使用するための改善されたモニター構
造が開示される。
レースユニットに使用するための改善されたモニター構
造が開示される。
【0022】本発明の第7の態様において、前述したト
レースユニットに使用するための改善されたパケットポ
ート構造が開示される。
レースユニットに使用するための改善されたパケットポ
ート構造が開示される。
【0023】
【発明の実施の形態】以下、図面を参照して説明する。
図面において同じ参照番号は同一の要素を示す。
図面において同じ参照番号は同一の要素を示す。
【0024】ここで使われる用語“プロセッサ”は、本
発明の譲受人により製作されたARCtangentとARCompact
のユーザー構成が可能な、コアのような縮小命令セット
コア(RISC)プロセッサ、中央処理ユニット(CPUs)、及び
デジタル信号プロセッサ(DSPs)を含むが、これに限定さ
れず、少なくとも一つの命令ワードで動作を遂行でき
る、任意の集積回路または他の電子デバイス(またはデ
バイスの集合)を含むことを意味する。このようなデバ
イスのハードウェアは、単一基板(たとえばシリコンダ
イ)上に集積されることができ、又は二つ以上の基板間
で分散されることができる。さらに、プロセッサの多様
な機能的な特性は、プロセッサと関連したソフトウェア
またはファームウエアとして単独で実現されることがで
きる。
発明の譲受人により製作されたARCtangentとARCompact
のユーザー構成が可能な、コアのような縮小命令セット
コア(RISC)プロセッサ、中央処理ユニット(CPUs)、及び
デジタル信号プロセッサ(DSPs)を含むが、これに限定さ
れず、少なくとも一つの命令ワードで動作を遂行でき
る、任意の集積回路または他の電子デバイス(またはデ
バイスの集合)を含むことを意味する。このようなデバ
イスのハードウェアは、単一基板(たとえばシリコンダ
イ)上に集積されることができ、又は二つ以上の基板間
で分散されることができる。さらに、プロセッサの多様
な機能的な特性は、プロセッサと関連したソフトウェア
またはファームウエアとして単独で実現されることがで
きる。
【0025】ARCtangentプロセッサは、ASIC、システム
・オン・チップ(SoC)、及びFPGA集積のためのユーザー
カスタマイズ可能な32ビットRISCコアである。これ
は、合成、構成かつ拡張が可能なので、デベロッパー
は、構造を特定アプリケーションによって一層適切に変
更し拡張することができる。ARCtangentマイクロプロセ
ッサは、4つのステージの実行パイプラインを備えた3
2-ビットRISC構造を含む。命令セット、レジスタファ
イル、条件コード、キャシュ、バス、及び他の構造上の
特性は、ユーザー構成可能で、且つ拡張可能である。マ
イクロプロセッサは、32×32ビットのコアレジスタ
ファイルを備え、これは、アプリケーションが必要とす
れば倍加されることができる。これに加えて、多数の補
助レジスタ(2E32まで)を使用することができる。こ
のようなプロセッサコアの機能要素は、演算論理回路(A
LU)、レジスタファイル(たとえば32×32)、プログ
ラムカウンタ(PC)、命令フェッチ(i-fetch)インターフ
ェース論理回路と共に多様なステージラッチを含む。
・オン・チップ(SoC)、及びFPGA集積のためのユーザー
カスタマイズ可能な32ビットRISCコアである。これ
は、合成、構成かつ拡張が可能なので、デベロッパー
は、構造を特定アプリケーションによって一層適切に変
更し拡張することができる。ARCtangentマイクロプロセ
ッサは、4つのステージの実行パイプラインを備えた3
2-ビットRISC構造を含む。命令セット、レジスタファ
イル、条件コード、キャシュ、バス、及び他の構造上の
特性は、ユーザー構成可能で、且つ拡張可能である。マ
イクロプロセッサは、32×32ビットのコアレジスタ
ファイルを備え、これは、アプリケーションが必要とす
れば倍加されることができる。これに加えて、多数の補
助レジスタ(2E32まで)を使用することができる。こ
のようなプロセッサコアの機能要素は、演算論理回路(A
LU)、レジスタファイル(たとえば32×32)、プログ
ラムカウンタ(PC)、命令フェッチ(i-fetch)インターフ
ェース論理回路と共に多様なステージラッチを含む。
【0026】ARCompactは、設計者に対して32-ビット
のユーザー構成可能なプロセッサ上で16及び32ビッ
ト命令が混合されることを許容する一つの革新的なプロ
セッサ及び命令セット構造(ISA)である。ISAの主要長所
は、SoC(システム・オン・チップ)上のメモリ要件を著
しく減少させて、無線通信及び大量の家電製品のような
広く使われるアプリケーションで低い電力消耗と低いコ
ストのデバイスを実現する能力である。
のユーザー構成可能なプロセッサ上で16及び32ビッ
ト命令が混合されることを許容する一つの革新的なプロ
セッサ及び命令セット構造(ISA)である。ISAの主要長所
は、SoC(システム・オン・チップ)上のメモリ要件を著
しく減少させて、無線通信及び大量の家電製品のような
広く使われるアプリケーションで低い電力消耗と低いコ
ストのデバイスを実現する能力である。
【0027】また、次の説明がVHSICハードウェーア記
述言語(VHDL)に基づく設計合成を言及するが、Verilog
のような他のハードウェア記述言語(HDL)が本発明の多
様な実施形態を成功的に記述するために使用され得るこ
とに注目する必要がある。さらに、デザイン コンパイ
ラ 2000(DC00)のような一つの例示的なSynopsys
合成エンジンが今まで説明した多様な実施形態を合成す
るために使われるが、特にカデンス(Cadence)設計シス
テム社から取得可能なBuildgatesのような他の合成エン
ジンが使われることができる。IEEE標準1076・3-
1997、IEEE標準VHDL合成パッケージは、当業者に有
用であると予見できるハードウェア記述言語基盤の設計
及び合成性能を規定するための産業-許容言語を記述す
る。
述言語(VHDL)に基づく設計合成を言及するが、Verilog
のような他のハードウェア記述言語(HDL)が本発明の多
様な実施形態を成功的に記述するために使用され得るこ
とに注目する必要がある。さらに、デザイン コンパイ
ラ 2000(DC00)のような一つの例示的なSynopsys
合成エンジンが今まで説明した多様な実施形態を合成す
るために使われるが、特にカデンス(Cadence)設計シス
テム社から取得可能なBuildgatesのような他の合成エン
ジンが使われることができる。IEEE標準1076・3-
1997、IEEE標準VHDL合成パッケージは、当業者に有
用であると予見できるハードウェア記述言語基盤の設計
及び合成性能を規定するための産業-許容言語を記述す
る。
【0028】概要
本発明のリアルタイムトレース(RTT)装置及び方法は、
プログラムの実行中に1つのプロセッサ(または多数の
プロセッサ)の非強制的な観測支援を提供する。例示的
な一実施形態において、RTTは、4種類の明確な形態の
トレース情報、すなわち(i)命令トレース、(ii)データ
トレース、(iii)タイミングトレース、(iv)雑多なトレ
ースを捕捉する。
プログラムの実行中に1つのプロセッサ(または多数の
プロセッサ)の非強制的な観測支援を提供する。例示的
な一実施形態において、RTTは、4種類の明確な形態の
トレース情報、すなわち(i)命令トレース、(ii)データ
トレース、(iii)タイミングトレース、(iv)雑多なトレ
ースを捕捉する。
【0029】命令トレースは、プロセッサ内で命令の流
れをトレースするためにプログラムカウンタ(PC)の進行
を記録する。データトレースは、ロード/ストアメモリ
アドレスとメモリデータを記録する。タイミングトレー
スは、命令実行の周期を記録する。雑多なトレースは、
トレース機能性に該当する、選択されたプロセッサ状態
の変化を記録する。
れをトレースするためにプログラムカウンタ(PC)の進行
を記録する。データトレースは、ロード/ストアメモリ
アドレスとメモリデータを記録する。タイミングトレー
スは、命令実行の周期を記録する。雑多なトレースは、
トレース機能性に該当する、選択されたプロセッサ状態
の変化を記録する。
【0030】本発明において、トレース情報は、例えば
一つ以上の“ニブル”を含む可変長パケット形態でエン
コードされる。以下で調査されるプロセスに固有な構造
を条件として他の数のビットの増加でうまく代替できる
としても、ここで使われる用語“ニブル”は、4ビット
よりなる1セットを言及する。可変長パケットは、当業
界によく知られた一般的な形態のチップ上のバッファメ
モリに格納される。しかし、バッファメモリは、パケッ
トをRTTパケットポートとデバッグポートの両者を介し
て伝送するために適用される。バッファメモリは、いか
なる時点でもバッファが完全に満たされることを避ける
ように、RTTパケットポートやデバッグポートを使用し
てパケットを「放出(drain)」する。本発明は、バッフ
ァのサイズ/格納容量、RTTパケットポートのためのピン
数(必要に応じて0に設定できる)、RTTパケットポート
ピンが専用または他の機能との共有(たとえば汎用I/O)
であるか、及びパケットポートと関連したクロック周波
数を含む、RTT及びバッファ構成に関連した多数のパラ
メータを、設計者が選択するのに有利である。クロック
出力ピンを駆動するクロック信号がASIC上の他のデバイ
スまたはピンから導出されることがないならば、パケッ
トポートクロック出力ピンが利用できる。
一つ以上の“ニブル”を含む可変長パケット形態でエン
コードされる。以下で調査されるプロセスに固有な構造
を条件として他の数のビットの増加でうまく代替できる
としても、ここで使われる用語“ニブル”は、4ビット
よりなる1セットを言及する。可変長パケットは、当業
界によく知られた一般的な形態のチップ上のバッファメ
モリに格納される。しかし、バッファメモリは、パケッ
トをRTTパケットポートとデバッグポートの両者を介し
て伝送するために適用される。バッファメモリは、いか
なる時点でもバッファが完全に満たされることを避ける
ように、RTTパケットポートやデバッグポートを使用し
てパケットを「放出(drain)」する。本発明は、バッフ
ァのサイズ/格納容量、RTTパケットポートのためのピン
数(必要に応じて0に設定できる)、RTTパケットポート
ピンが専用または他の機能との共有(たとえば汎用I/O)
であるか、及びパケットポートと関連したクロック周波
数を含む、RTT及びバッファ構成に関連した多数のパラ
メータを、設計者が選択するのに有利である。クロック
出力ピンを駆動するクロック信号がASIC上の他のデバイ
スまたはピンから導出されることがないならば、パケッ
トポートクロック出力ピンが利用できる。
【0031】次に、さらに以下で記述される例示的な一
実施形態において、本発明のRTTユニットは、次の特性
を持ってトレースを生成する。(i)全ての通常のフード
のシーケンスがキャプチャーされる、(ii)実行プログラ
ムのコンパイルされたソースコードが参照可能ならば
(一般に、自己変更コードはこのような要件に合わない
ので、サポートされない)、プログラムの流れは、命令
トレースから再構成され得る、(iii)キャプチャー、圧
縮及び送信方法は、トリガリングまたはフィルタリング
にいかなる制限をも加えない、(iv)トレース情報は、
(チップ上のまたはチップ外の)限定されたメモリに格納
される。もしメモリが満杯となると、新しいトレース情
報が格納されるように、古くなったトレース情報が廃棄
される(すなわちFIFO)か、より最近のトレース情報が優
先的に廃棄され(すなわち、LIFO)、またはトレースがブ
レークされる、(v)トレースをチップ外に伝達するため
の必要帯域幅を最小化させ、チップ上の及び/またはチ
ップ外のメモリの必要サイズを最小化させるために、ト
レースは有利に圧縮される。RTTsのためにイネーブルな
ピンが足りない後で記述される図22のような多重RTTs
(マイクロプロセッサ)を備える装置にとって帯域幅を最
小化させることが特に重要になる、(vi)このトレース
は、トレースの開始が失なわれるとしてもデコードされ
る、(vii)多重プロセッサコアを備えたデバイスがサポ
ートされる。
実施形態において、本発明のRTTユニットは、次の特性
を持ってトレースを生成する。(i)全ての通常のフード
のシーケンスがキャプチャーされる、(ii)実行プログラ
ムのコンパイルされたソースコードが参照可能ならば
(一般に、自己変更コードはこのような要件に合わない
ので、サポートされない)、プログラムの流れは、命令
トレースから再構成され得る、(iii)キャプチャー、圧
縮及び送信方法は、トリガリングまたはフィルタリング
にいかなる制限をも加えない、(iv)トレース情報は、
(チップ上のまたはチップ外の)限定されたメモリに格納
される。もしメモリが満杯となると、新しいトレース情
報が格納されるように、古くなったトレース情報が廃棄
される(すなわちFIFO)か、より最近のトレース情報が優
先的に廃棄され(すなわち、LIFO)、またはトレースがブ
レークされる、(v)トレースをチップ外に伝達するため
の必要帯域幅を最小化させ、チップ上の及び/またはチ
ップ外のメモリの必要サイズを最小化させるために、ト
レースは有利に圧縮される。RTTsのためにイネーブルな
ピンが足りない後で記述される図22のような多重RTTs
(マイクロプロセッサ)を備える装置にとって帯域幅を最
小化させることが特に重要になる、(vi)このトレース
は、トレースの開始が失なわれるとしてもデコードされ
る、(vii)多重プロセッサコアを備えたデバイスがサポ
ートされる。
【0032】本発明のRTTはユーザーが選択可能な多く
の選択事項を含むが、これらの一部は、コアまたはASIC
/FPGAの構成時(“build-time”)に設定され、他のもの
は、構成コア/RTT(s)の実行時に設定される。デバイス
の設計者は、設計構成と関連したレジスタトランスファ
言語(RTL)のソースコードでパラメータ(例えば常数)を
編集することによって、または設置工程の途中で構成パ
ラメータをセットすることで、またはこれら両方を行な
うことによって、構成時のオプションを設定する。デバ
イスユーザーは、RTTの補助レジスタを記録するプロセ
ッサ上のプログラムを実行することによって、または補
助レジスタに記録する外部ホストを備えたデバッグポー
トを使用することによって、実行時のオプションを設定
する。プロセッサ(たとえばARC)によるRTT補助レジスタ
に対する記録は、一実施形態でロック(lock)メカニズム
により資格が与えられる。このようなロックメカニズム
は、プロセッサプログラムが偶然にRTTレジスタに記録
しないことを保障する。大部分の実行時オプションは、
ユーザーに対するインターフェースを単純化するため
に、ホストまたは外部キャプチャーデバイス上に常駐す
るデバッグプログラムにより自動的に処理される。
の選択事項を含むが、これらの一部は、コアまたはASIC
/FPGAの構成時(“build-time”)に設定され、他のもの
は、構成コア/RTT(s)の実行時に設定される。デバイス
の設計者は、設計構成と関連したレジスタトランスファ
言語(RTL)のソースコードでパラメータ(例えば常数)を
編集することによって、または設置工程の途中で構成パ
ラメータをセットすることで、またはこれら両方を行な
うことによって、構成時のオプションを設定する。デバ
イスユーザーは、RTTの補助レジスタを記録するプロセ
ッサ上のプログラムを実行することによって、または補
助レジスタに記録する外部ホストを備えたデバッグポー
トを使用することによって、実行時のオプションを設定
する。プロセッサ(たとえばARC)によるRTT補助レジスタ
に対する記録は、一実施形態でロック(lock)メカニズム
により資格が与えられる。このようなロックメカニズム
は、プロセッサプログラムが偶然にRTTレジスタに記録
しないことを保障する。大部分の実行時オプションは、
ユーザーに対するインターフェースを単純化するため
に、ホストまたは外部キャプチャーデバイス上に常駐す
るデバッグプログラムにより自動的に処理される。
【0033】したがって、本発明に係る一つの例示的な
RTTシステムは、4個の主機能ユニットを含む。すなわ
ち、(i)既存のコア設計に統合される合成可能な論理ブ
ロック、(ii)ホスト制御インターフェースを備えたデー
タキャプチャーハードウェア、(iii)キャプチャーセッ
ションを構成し、結果を見るためのグラフィックユーザ
ーインターフェース、及び(iv)キャプチャーハードウェ
アとGUI間をインターフェースするためのソフトウェア
ドライバーである。
RTTシステムは、4個の主機能ユニットを含む。すなわ
ち、(i)既存のコア設計に統合される合成可能な論理ブ
ロック、(ii)ホスト制御インターフェースを備えたデー
タキャプチャーハードウェア、(iii)キャプチャーセッ
ションを構成し、結果を見るためのグラフィックユーザ
ーインターフェース、及び(iv)キャプチャーハードウェ
アとGUI間をインターフェースするためのソフトウェア
ドライバーである。
【0034】単一プロセッサの構成
図1を参照して、本発明のRTT装置の第1の例示的な実
施形態を詳細に記述する。次の論議が基本的に単一のRI
SCに基づくプロセッサコア構成の概念でなされるが、多
くの特性及び属性が装置の他の構成(図22に関して本
明細書の後で記述されるマルチコアの例のような)及び
形態(たとえばDSPコア、CISC等)に直接適用される。
施形態を詳細に記述する。次の論議が基本的に単一のRI
SCに基づくプロセッサコア構成の概念でなされるが、多
くの特性及び属性が装置の他の構成(図22に関して本
明細書の後で記述されるマルチコアの例のような)及び
形態(たとえばDSPコア、CISC等)に直接適用される。
【0035】図1に示すように、装置100は、一般的
にRTTユニット102、プロセッサコアユニット105
及びメモリコントローラー117を含む特定用途集積回
路ASICまたは現場プログラムが可能なゲートアレイFPGA
のような集積回路デバイス101(または多重分散デバ
イス)を含む。装置100は、デバッグポート/インター
フェース107、メモリポート/インターフェース11
3、及びパケットポート109をさらに含む。RTTユニ
ット102は、トレースキャプチャーユニット140、
モニターユニット142、生成ユニット144、制御ユ
ニット146及び共有バッファ112を含む多様な機能
ユニットを含む。プロセッサ状態情報は、一般的にプロ
セッサコアユニット105からキャプチャー及びモニタ
リングユニット140、142に直接流れ、制御ユニッ
ト146へは、アクションポイントトリガー生成器14
8を介して非直接的に流れる。補助レジスタ読出/書込
動作は、図1に示すように、プロセッサコアユニットコ
ア131とRTT制御ユニット146との間で直接的に行
われる。制御ユニット146は、RTTユニット102の
動作を制御するために使われる補助レジスタ及び状態マ
シンを含む。トレースキャプチャーユニット140は、
プロセッサ状態情報をコアユニット105(および、外
部入力インターフェース160を介してプログラムカウ
ンタ、条件コードレジスタ及び他のプロセッサ状態情報
のような任意の外部入力)から受信し、イネーブルとさ
れたトレースの形態に関する変化を検出し、RTTモニタ
リングユニット142に入力されるトレース信号152
を生成する。モニタリングユニット142は、トレース
情報を生成ユニット144に伝送する前に、これをダイ
ナミックにフィルタリングする。また、モニタリングユ
ニットは、以下で詳細に記述するように、RTT内の多様
な機能を実現させるために、RTT制御ユニット146に
伝達されるトリガー及び/またはイネーブルな信号を生
成する。
にRTTユニット102、プロセッサコアユニット105
及びメモリコントローラー117を含む特定用途集積回
路ASICまたは現場プログラムが可能なゲートアレイFPGA
のような集積回路デバイス101(または多重分散デバ
イス)を含む。装置100は、デバッグポート/インター
フェース107、メモリポート/インターフェース11
3、及びパケットポート109をさらに含む。RTTユニ
ット102は、トレースキャプチャーユニット140、
モニターユニット142、生成ユニット144、制御ユ
ニット146及び共有バッファ112を含む多様な機能
ユニットを含む。プロセッサ状態情報は、一般的にプロ
セッサコアユニット105からキャプチャー及びモニタ
リングユニット140、142に直接流れ、制御ユニッ
ト146へは、アクションポイントトリガー生成器14
8を介して非直接的に流れる。補助レジスタ読出/書込
動作は、図1に示すように、プロセッサコアユニットコ
ア131とRTT制御ユニット146との間で直接的に行
われる。制御ユニット146は、RTTユニット102の
動作を制御するために使われる補助レジスタ及び状態マ
シンを含む。トレースキャプチャーユニット140は、
プロセッサ状態情報をコアユニット105(および、外
部入力インターフェース160を介してプログラムカウ
ンタ、条件コードレジスタ及び他のプロセッサ状態情報
のような任意の外部入力)から受信し、イネーブルとさ
れたトレースの形態に関する変化を検出し、RTTモニタ
リングユニット142に入力されるトレース信号152
を生成する。モニタリングユニット142は、トレース
情報を生成ユニット144に伝送する前に、これをダイ
ナミックにフィルタリングする。また、モニタリングユ
ニットは、以下で詳細に記述するように、RTT内の多様
な機能を実現させるために、RTT制御ユニット146に
伝達されるトリガー及び/またはイネーブルな信号を生
成する。
【0036】モニタリングユニット142は、トレース
信号152を生成ユニット144に提供し、生成ユニッ
トは、内部状態情報(例えばカウンタ)を更新することに
よって、またはパケットを生成することによってトレー
ス情報を記録する。パケットは、後で記述されるプロト
コルによって生成され、RTTの共有バッファ112に提
供される。共有バッファ112は、半導体業界でよく知
られた形態のバッファメモリを含み、パケットがキャプ
チャーデバイス(以下で詳細に記述)によりパケットポー
ト109(または他に、以下で詳細に記述する“内部”
モード動作を使用するデバッグポート)を介して「放出
(drain)」される時まで、生成ユニット144により生
成されたパケットを格納する。オーバーフローインター
ラプト信号は(たとえば“漏水(high water) ”マークま
たはバッファ内に存在する他の条件に基づいて)バッフ
ァ112により生成され、コアユニット105のインタ
ーラプトコントローラー133に提供されるが、ここで
コア131のパイプラインは、選択的に停止されるか、
そうでない場合、バッファオーバーフロー条件を減少あ
るいは緩和するようにコアの動作が変更される。
信号152を生成ユニット144に提供し、生成ユニッ
トは、内部状態情報(例えばカウンタ)を更新することに
よって、またはパケットを生成することによってトレー
ス情報を記録する。パケットは、後で記述されるプロト
コルによって生成され、RTTの共有バッファ112に提
供される。共有バッファ112は、半導体業界でよく知
られた形態のバッファメモリを含み、パケットがキャプ
チャーデバイス(以下で詳細に記述)によりパケットポー
ト109(または他に、以下で詳細に記述する“内部”
モード動作を使用するデバッグポート)を介して「放出
(drain)」される時まで、生成ユニット144により生
成されたパケットを格納する。オーバーフローインター
ラプト信号は(たとえば“漏水(high water) ”マークま
たはバッファ内に存在する他の条件に基づいて)バッフ
ァ112により生成され、コアユニット105のインタ
ーラプトコントローラー133に提供されるが、ここで
コア131のパイプラインは、選択的に停止されるか、
そうでない場合、バッファオーバーフロー条件を減少あ
るいは緩和するようにコアの動作が変更される。
【0037】命令トレース、データトレース及びタイミ
ングトレースは個別的に、静的に、そしてダイナミック
にイネーブルとされる。イネーブルとされるためには、
これらは静的にイネーブルとされ、かつダイナミックに
イネーブルとされる必要がある。第4のトレース(雑多
な)は、静的にのみイネーブルとされる。あらゆるイネ
ーブルビットは、図1に示すように、制御ユニット14
6に格納される。静的イネーブルビットは、ユーザーに
より記録され、ダイナミックイネーブルビットは、モニ
ターユニット142またはユーザーにより記録される。
ングトレースは個別的に、静的に、そしてダイナミック
にイネーブルとされる。イネーブルとされるためには、
これらは静的にイネーブルとされ、かつダイナミックに
イネーブルとされる必要がある。第4のトレース(雑多
な)は、静的にのみイネーブルとされる。あらゆるイネ
ーブルビットは、図1に示すように、制御ユニット14
6に格納される。静的イネーブルビットは、ユーザーに
より記録され、ダイナミックイネーブルビットは、モニ
ターユニット142またはユーザーにより記録される。
【0038】単一構成または多重プロセッサ構成のいず
れにおいても、本発明のRTTは、内部及び外部の2種類
の格納モードを使用する。モードは、後で詳細に記述す
るように、RTT共有バッファが放出する方法を決定す
る。RTTの格納モードは、ユーザーインターフェースを
介し又はデバイスに対する一つ以上の入力を介して、ユ
ーザーにより制御される。
れにおいても、本発明のRTTは、内部及び外部の2種類
の格納モードを使用する。モードは、後で詳細に記述す
るように、RTT共有バッファが放出する方法を決定す
る。RTTの格納モードは、ユーザーインターフェースを
介し又はデバイスに対する一つ以上の入力を介して、ユ
ーザーにより制御される。
【0039】(i) 内部格納モード−図2を参照して、
“内部”格納モードで動作するように構成された本発明
の第1の例示的な実施形態が記述される。図2に示すよ
うに、装置200は、図1を参照して本明細書で前述し
たもので、少なくとも一つのプロセッサコア105と少
なくとも一つのRTTユニット102とを統合するASICま
たはFPGAのような集積回路デバイス101を含む。集積
回路デバイス101は、コンピュータ業界でよく知られ
た通り、回路ボード203(例えばマザーボードまたは
開発ボード)上に配置される。外部ホスト211は、デ
バッグプログラム(例えばSee Codeデバッガー)を駆動さ
せるが、プログラムは、デバイス101のデバッグポー
ト107を用いてプロセッサコア105とRTT102の
レジスタを読出しこれらに書込む。図示された実施形態
において、ホスト211は、パーソナルまたはデスクト
ップコンピュータを含み、ラップトップコンピュータ、
ネットワーク化されたミニコンピュータ、または携帯型
コンピュータまたはPDAのような携帯型デバイスを含む
他のデバイスをも成功的に使われることができる。さら
に他の代案として、ホスト211は、同一基板や他の基
板に配置された、該当技術分野でよく知られた形態のマ
イクロプロセッサ(たとえばインテルのペンティアム
(登録商標)IIIまたはIVシリーズ、またはAMDのK-シリ
ーズデバイス)のような他のプロセッサまたはプロセッ
サの集合を含むことができる。デバッグポート107
は、事実上、本出願の譲受人により共通的に提供される
“標準デバッグポート(たとえばIEEE 標準 1149 J
TAG、または並列ポート)または消費者/ユーザーにより
提供される他のポート構成のようないかなる構成でもな
されることができる。本発明は、標準配線によるデータ
経路、無線インターフェース、または光伝導体をも含む
任意の数の技術を使用してホスト211とデバイス10
1のデバッグポート107間のデータ伝達を観測できる
が、データ通信技術は、周知であり、したがってここで
はさらに説明しない。
“内部”格納モードで動作するように構成された本発明
の第1の例示的な実施形態が記述される。図2に示すよ
うに、装置200は、図1を参照して本明細書で前述し
たもので、少なくとも一つのプロセッサコア105と少
なくとも一つのRTTユニット102とを統合するASICま
たはFPGAのような集積回路デバイス101を含む。集積
回路デバイス101は、コンピュータ業界でよく知られ
た通り、回路ボード203(例えばマザーボードまたは
開発ボード)上に配置される。外部ホスト211は、デ
バッグプログラム(例えばSee Codeデバッガー)を駆動さ
せるが、プログラムは、デバイス101のデバッグポー
ト107を用いてプロセッサコア105とRTT102の
レジスタを読出しこれらに書込む。図示された実施形態
において、ホスト211は、パーソナルまたはデスクト
ップコンピュータを含み、ラップトップコンピュータ、
ネットワーク化されたミニコンピュータ、または携帯型
コンピュータまたはPDAのような携帯型デバイスを含む
他のデバイスをも成功的に使われることができる。さら
に他の代案として、ホスト211は、同一基板や他の基
板に配置された、該当技術分野でよく知られた形態のマ
イクロプロセッサ(たとえばインテルのペンティアム
(登録商標)IIIまたはIVシリーズ、またはAMDのK-シリ
ーズデバイス)のような他のプロセッサまたはプロセッ
サの集合を含むことができる。デバッグポート107
は、事実上、本出願の譲受人により共通的に提供される
“標準デバッグポート(たとえばIEEE 標準 1149 J
TAG、または並列ポート)または消費者/ユーザーにより
提供される他のポート構成のようないかなる構成でもな
されることができる。本発明は、標準配線によるデータ
経路、無線インターフェース、または光伝導体をも含む
任意の数の技術を使用してホスト211とデバイス10
1のデバッグポート107間のデータ伝達を観測できる
が、データ通信技術は、周知であり、したがってここで
はさらに説明しない。
【0040】内部格納モードにおいて、デバイス101
に連結した共有バッファ112は、リアルタイムで放出
されず、デバイスに連結したパケットポートは使われな
い。むしろバッファ112は、デバッグポート107を
介してRTTレジスタを読出す外部ホスト211によりト
レースがキャプチャーされた後、放出される。他に、ト
レースされるプロセッサコア105は、共有バッファ1
12からのパケットの放出を実行させるためにRTTレジ
スタを読出すことができる。
に連結した共有バッファ112は、リアルタイムで放出
されず、デバイスに連結したパケットポートは使われな
い。むしろバッファ112は、デバッグポート107を
介してRTTレジスタを読出す外部ホスト211によりト
レースがキャプチャーされた後、放出される。他に、ト
レースされるプロセッサコア105は、共有バッファ1
12からのパケットの放出を実行させるためにRTTレジ
スタを読出すことができる。
【0041】(ii)外部格納モード−図3を参照して本発
明の外部格納モードが記述される。外部格納モードにお
いて、共有バッファ112は、パケットポートを介して
外部キャプチャーデバイス320にリアルタイムで放出
される(図2の内部モードにおいてホスト211による
バッファの非リアルタイム放出とは異なる)。バッファ
112が新しいトレース情報の獲得/記録に追随できる
のに充分な速さで放出できないとは、2種類の基本的な
オプションが存在する。すなわち、(i)バッファのオー
バーフローは許容され、オーバーフローされたデータは
失なわれる、または(ii)新しいデータ生成の率を減少さ
せるように、プロセッサコアパイプラインが図1のオー
バーフローインターラプト論理を介して停止する。これ
らのオプションは、ユーザー(または設計者)により適し
たものとして選択される。外部キャプチャーデバイス3
20は、全トレースを格納するように構成され得るが、
通常はトレースの一部だけを格納し、初期のトレース情
報は、もはや必要とされないか適切でない時、廃棄され
る。
明の外部格納モードが記述される。外部格納モードにお
いて、共有バッファ112は、パケットポートを介して
外部キャプチャーデバイス320にリアルタイムで放出
される(図2の内部モードにおいてホスト211による
バッファの非リアルタイム放出とは異なる)。バッファ
112が新しいトレース情報の獲得/記録に追随できる
のに充分な速さで放出できないとは、2種類の基本的な
オプションが存在する。すなわち、(i)バッファのオー
バーフローは許容され、オーバーフローされたデータは
失なわれる、または(ii)新しいデータ生成の率を減少さ
せるように、プロセッサコアパイプラインが図1のオー
バーフローインターラプト論理を介して停止する。これ
らのオプションは、ユーザー(または設計者)により適し
たものとして選択される。外部キャプチャーデバイス3
20は、全トレースを格納するように構成され得るが、
通常はトレースの一部だけを格納し、初期のトレース情
報は、もはや必要とされないか適切でない時、廃棄され
る。
【0042】図2の内部格納モードのように、図3の装
置の外部ホスト211は、デバッグポート107を用い
てプロセッサコアとRTTのレジスタを読み書きする。デ
バッガー(たとえばSeeCodeプログラム)を駆動する。外
部ホスト211は、キャプチャーされたトレースをダウ
ンロードするために外部キャプチャーデバイス320と
通信する。外部ホスト211とキャプチャーデバイス3
20間の通信は、図示された実施形態では、データ通信
するホスト211内のネットワークインターフェースカ
ード(NIC)とキャプチャーデバイス320内の対応する
インターフェースアダプター(不図示)を含むIEEE 標準
802“イーサネット(登録商標)”結合を使用して達
成される。しかし、例えば、IEEE 標準 802.11aま
たは802.11bに従う無線LAN、ブルートゥースまた
は、IrDAインターフェース等を含む、ホストとキャプチ
ャーデバイス間のデータ通信の多様な他の手段が使われ
ることが出来ることを認識すべきである。外部キャプチ
ャーデバイス320は、(i)論理アナライザー、または
(ii)トレースキャプチャーユニットの他で、当分野の当
業者に公知された任意の数の他のデバイスを含むことが
できる。本発明は一つのキャプチャーデバイス320
(たとえば論理アナライザーまたはキャプチャーユニッ
ト)と動作するように適用されているが、キャプチャー
デバイス320は、特定のアプリケーションの必要に応
じて、多いか又は少ない機能を有する複数のデバイスを
含むことが出来ることを認識すべきである。一つの変形
において、論理アナライザーは、トレースデータを内部
バッファメモリ(不図示)に格納し、単純なトリガリング
を遂行し、トレースデータのフィルタリングは遂行しな
い。逆に、本発明が予定するトレースキャプチャーユニ
ットは、RTTの動作を支援するために特別に適用された
注文-設計されたユニットである。トレースキャプチャ
ーユニットは、トレースデータを格納するためにDRAMバ
ッファメモリを使用し、任意の複雑なトリガー及びフィ
ルタ機能を提供できる。
置の外部ホスト211は、デバッグポート107を用い
てプロセッサコアとRTTのレジスタを読み書きする。デ
バッガー(たとえばSeeCodeプログラム)を駆動する。外
部ホスト211は、キャプチャーされたトレースをダウ
ンロードするために外部キャプチャーデバイス320と
通信する。外部ホスト211とキャプチャーデバイス3
20間の通信は、図示された実施形態では、データ通信
するホスト211内のネットワークインターフェースカ
ード(NIC)とキャプチャーデバイス320内の対応する
インターフェースアダプター(不図示)を含むIEEE 標準
802“イーサネット(登録商標)”結合を使用して達
成される。しかし、例えば、IEEE 標準 802.11aま
たは802.11bに従う無線LAN、ブルートゥースまた
は、IrDAインターフェース等を含む、ホストとキャプチ
ャーデバイス間のデータ通信の多様な他の手段が使われ
ることが出来ることを認識すべきである。外部キャプチ
ャーデバイス320は、(i)論理アナライザー、または
(ii)トレースキャプチャーユニットの他で、当分野の当
業者に公知された任意の数の他のデバイスを含むことが
できる。本発明は一つのキャプチャーデバイス320
(たとえば論理アナライザーまたはキャプチャーユニッ
ト)と動作するように適用されているが、キャプチャー
デバイス320は、特定のアプリケーションの必要に応
じて、多いか又は少ない機能を有する複数のデバイスを
含むことが出来ることを認識すべきである。一つの変形
において、論理アナライザーは、トレースデータを内部
バッファメモリ(不図示)に格納し、単純なトリガリング
を遂行し、トレースデータのフィルタリングは遂行しな
い。逆に、本発明が予定するトレースキャプチャーユニ
ットは、RTTの動作を支援するために特別に適用された
注文-設計されたユニットである。トレースキャプチャ
ーユニットは、トレースデータを格納するためにDRAMバ
ッファメモリを使用し、任意の複雑なトリガー及びフィ
ルタ機能を提供できる。
【0043】図1に示した実施形態のRTTユニットは、O
FF、RUN及びTRIGGEREDの3種類の動作モードのうちいず
れか1つに置かれる。リセットは、RTTユニット102
をOFF状態とする。トレースされるホストまたはプロセ
ッサコアは、RUN状態に変化させるためにRTTユニット内
の補助レジスタに書込む。トリガーの発生時、RTTユニ
ットは、TRIGGERED状態に転換する。RTTが前述した外部
格納モードにある時、RTTはパケットを生成し、外部キ
ャプチャーデバイス(たとえばアナライザーまたはトレ
ースキャプチャーユニット)に状態の変化を警告する。O
FF状態において、RTTはトレース情報を記録しない。共
有バッファ112には、何も加えられず、バッファから
何も除去・放出されず、何もパケットポート109に伝
達されない。
FF、RUN及びTRIGGEREDの3種類の動作モードのうちいず
れか1つに置かれる。リセットは、RTTユニット102
をOFF状態とする。トレースされるホストまたはプロセ
ッサコアは、RUN状態に変化させるためにRTTユニット内
の補助レジスタに書込む。トリガーの発生時、RTTユニ
ットは、TRIGGERED状態に転換する。RTTが前述した外部
格納モードにある時、RTTはパケットを生成し、外部キ
ャプチャーデバイス(たとえばアナライザーまたはトレ
ースキャプチャーユニット)に状態の変化を警告する。O
FF状態において、RTTはトレース情報を記録しない。共
有バッファ112には、何も加えられず、バッファから
何も除去・放出されず、何もパケットポート109に伝
達されない。
【0044】外部入力信号(またはRTT内の特定のプログ
ラム可能レジスタの書込み)は、RTTユニット102をO
FFからRUNに転換させる。RUN状態でRTTは、イネーブル
とされたトレース形態に対してトレース情報を記録し、
イネーブルとされたトレースに関するパケットを共有バ
ッファ112に格納する。内部格納モードであれば、共
有バッファは新しいパケットのための空間を形成する要
求に応じて放出され、除去されたパケットは廃棄され
る。外部格納モードであれば、共有バッファ112は連
続的に放出され、除去されたパケットは、パケットポー
ト109を介して外部格納デバイスに伝送される。
ラム可能レジスタの書込み)は、RTTユニット102をO
FFからRUNに転換させる。RUN状態でRTTは、イネーブル
とされたトレース形態に対してトレース情報を記録し、
イネーブルとされたトレースに関するパケットを共有バ
ッファ112に格納する。内部格納モードであれば、共
有バッファは新しいパケットのための空間を形成する要
求に応じて放出され、除去されたパケットは廃棄され
る。外部格納モードであれば、共有バッファ112は連
続的に放出され、除去されたパケットは、パケットポー
ト109を介して外部格納デバイスに伝送される。
【0045】トリガーは、RTTユニット102をRUNから
TRIGGEREDモードに転換させる。図示された実施形態に
おいて、トリガーは、(i)アクションポイントトリガー
イベント、(ii)モニタートリガーイベント、(iii)外部
入力信号イベント、または(iv)記録されたRTT制御レジ
スタイベントのうちのひとつを含む。また、本実施形態
は、一つのトリガー信号を生成するために、可能な全て
のトリガーソースを共通に論理OR演算させる。一つのト
リガーは、トレースの実行毎にただ1回発生する。した
がって、RTTユニット102は、他のトレースの実行が
開始される前にリセットされなければならない。
TRIGGEREDモードに転換させる。図示された実施形態に
おいて、トリガーは、(i)アクションポイントトリガー
イベント、(ii)モニタートリガーイベント、(iii)外部
入力信号イベント、または(iv)記録されたRTT制御レジ
スタイベントのうちのひとつを含む。また、本実施形態
は、一つのトリガー信号を生成するために、可能な全て
のトリガーソースを共通に論理OR演算させる。一つのト
リガーは、トレースの実行毎にただ1回発生する。した
がって、RTTユニット102は、他のトレースの実行が
開始される前にリセットされなければならない。
【0046】RTTユニットが、まずTRIGGERED状態に入る
時、ユーザーは、プレ-トリガーされた共有バッファ中
のどの部分がプレ-トリガーされた履歴として保有され
るかを制御できる。仮にユーザーがトリガーイベントの
発生前(“トリガー以前”)のトレースを見ることを希望
したら、全バッファの内容が保有される。仮にユーザー
がトリガーイベント以後(“トリガー以後”)のトレース
を見ることを希望したら、共有バッファの内容のいずれ
も保有されない。仮にユーザーがトリガーの近くまたは
不規則に(“トリガー中央”)トレースを見ることを希望
したら、バッファ内容の一部(たとえば半分)だけ保有さ
れる。
時、ユーザーは、プレ-トリガーされた共有バッファ中
のどの部分がプレ-トリガーされた履歴として保有され
るかを制御できる。仮にユーザーがトリガーイベントの
発生前(“トリガー以前”)のトレースを見ることを希望
したら、全バッファの内容が保有される。仮にユーザー
がトリガーイベント以後(“トリガー以後”)のトレース
を見ることを希望したら、共有バッファの内容のいずれ
も保有されない。仮にユーザーがトリガーの近くまたは
不規則に(“トリガー中央”)トレースを見ることを希望
したら、バッファ内容の一部(たとえば半分)だけ保有さ
れる。
【0047】TRIGGERED状態で、RTTユニットは、イネー
ブルとされたトレース形態に対するトレース情報を記録
し、パケットを共有バッファ112に格納する。内部格
納モードであれば、バッファは放出されず、バッファが
満杯となると、RTTユニット102は、OFF状態に転換す
る。外部格納モードであれば、バッファが連続的に放出
され、除去されたパケットがパケットポート109を介
して外部格納デバイスに伝送される。しかし、ユーザー
は、RTTユニットが格納モードであっても共有バッファ
のオーバーフロー時にRUN状態に転換するように指定す
ることができる。バッファオーバーフロー/動作モード/
状態の他の組合も本発明と符合して使われ得ることを認
識すべきである。
ブルとされたトレース形態に対するトレース情報を記録
し、パケットを共有バッファ112に格納する。内部格
納モードであれば、バッファは放出されず、バッファが
満杯となると、RTTユニット102は、OFF状態に転換す
る。外部格納モードであれば、バッファが連続的に放出
され、除去されたパケットがパケットポート109を介
して外部格納デバイスに伝送される。しかし、ユーザー
は、RTTユニットが格納モードであっても共有バッファ
のオーバーフロー時にRUN状態に転換するように指定す
ることができる。バッファオーバーフロー/動作モード/
状態の他の組合も本発明と符合して使われ得ることを認
識すべきである。
【0048】本発明のRTTユニット102は、設計者が
指定した数の内部モニターを含む。各モニターは、プロ
セッサコアを観測し、トレースキャプチャーをダイナミ
ックに制御するために外部信号を選択する。図示された
実施形態において、各モニターは、ユーザーにより個別
的にイネーブルとなる。ユーザーは、(i)形態、(ii)ア
クション、及び(iii)条件を含むパラメータを有するそ
れぞれのイネーブルのモニターをプログラムする。形態
パラメータは、モニターがトリガーで動作するか、また
はフィルタで動作するかを指定する。“トリガー”の形
態は、RTTの動作状態をRUNからTRIGGEREDに変更させ
る。“フィルタ”形態は、ユーザーが関心のあるトレー
ス情報だけをキャプチャーするように許容する(下記の
フィルタに関する詳細説明参照)。
指定した数の内部モニターを含む。各モニターは、プロ
セッサコアを観測し、トレースキャプチャーをダイナミ
ックに制御するために外部信号を選択する。図示された
実施形態において、各モニターは、ユーザーにより個別
的にイネーブルとなる。ユーザーは、(i)形態、(ii)ア
クション、及び(iii)条件を含むパラメータを有するそ
れぞれのイネーブルのモニターをプログラムする。形態
パラメータは、モニターがトリガーで動作するか、また
はフィルタで動作するかを指定する。“トリガー”の形
態は、RTTの動作状態をRUNからTRIGGEREDに変更させ
る。“フィルタ”形態は、ユーザーが関心のあるトレー
ス情報だけをキャプチャーするように許容する(下記の
フィルタに関する詳細説明参照)。
【0049】アクションパラメータは、モニターが活性
である時、RTTユニット102の応答を指定する。トリ
ガーアクションは、動作状態をRUNからTRIGGEREDに変更
するためのものである。各モニターは、モニターがトリ
ガーとしてプログラムされる時に使われるトリガー信号
を具備する。トリガー出力信号は、RTTのトリガー設備
に伝達される。トリガー信号は、条件が真である時、一
週期の途中に“1”にセットされ、その後モニターはイ
ネーブルとなる。
である時、RTTユニット102の応答を指定する。トリ
ガーアクションは、動作状態をRUNからTRIGGEREDに変更
するためのものである。各モニターは、モニターがトリ
ガーとしてプログラムされる時に使われるトリガー信号
を具備する。トリガー出力信号は、RTTのトリガー設備
に伝達される。トリガー信号は、条件が真である時、一
週期の途中に“1”にセットされ、その後モニターはイ
ネーブルとなる。
【0050】各モニターは、モニターがフィルタとして
プログラムされる時に使われる各トレース形態のための
イネーブルの信号を具備する。フィルタクションは、命
令トレース、データトレース及びタイミングトレースを
含む、最高3つの形態のトレースのダイナミックトレー
スイネーブルビットに適用される。
プログラムされる時に使われる各トレース形態のための
イネーブルの信号を具備する。フィルタクションは、命
令トレース、データトレース及びタイミングトレースを
含む、最高3つの形態のトレースのダイナミックトレー
スイネーブルビットに適用される。
【0051】一つのフィルタは、図示した実施形態で二
つの独立した選択事項、すなわちダイナミックトレース
イネーブル及びレベル/エッジ反応として指定された4
個のアクション中のひとつを有する。4個のアクション
は、表1に示されている。
つの独立した選択事項、すなわちダイナミックトレース
イネーブル及びレベル/エッジ反応として指定された4
個のアクション中のひとつを有する。4個のアクション
は、表1に示されている。
【0052】
【表1】
【0053】一つ以上のフィルタが反対動作で活性化さ
れれば、イネーブルを'1'にセットすることが多くな
る。しかし、一般的に、ユーザーは、相反する動作を有
するフィルタをプログラムすることを避けるべきであ
る。イネーブル状態と非イネーブル状態との間の変換に
関するパケット経費が存在するので、命令トレースと関
連したフィルタに対しても注意しなければならない。ダ
イナミック命令トレースイネーブルビットは、バッファ
のオーバーフローを避けるのに十分に遅い速度で変更さ
れるのが理想的である。
れれば、イネーブルを'1'にセットすることが多くな
る。しかし、一般的に、ユーザーは、相反する動作を有
するフィルタをプログラムすることを避けるべきであ
る。イネーブル状態と非イネーブル状態との間の変換に
関するパケット経費が存在するので、命令トレースと関
連したフィルタに対しても注意しなければならない。ダ
イナミック命令トレースイネーブルビットは、バッファ
のオーバーフローを避けるのに十分に遅い速度で変更さ
れるのが理想的である。
【0054】モニター条件パラメータは、モニターを活
性化させる入力条件を指定する。ユーザーは、それぞれ
のモニターが一つの条件を観測するようにプログラムす
る。本実施形態の条件パラメータは、(i)常数(たとえば
32ビット整数)、(ii)ニブルマスク(たとえば8ビット
整数)、(iii)ソース(常数がテストされることに対する
値を指定)、及び(iv)関係(テスト形態を指定)の4つの
要素からなる。
性化させる入力条件を指定する。ユーザーは、それぞれ
のモニターが一つの条件を観測するようにプログラムす
る。本実施形態の条件パラメータは、(i)常数(たとえば
32ビット整数)、(ii)ニブルマスク(たとえば8ビット
整数)、(iii)ソース(常数がテストされることに対する
値を指定)、及び(iv)関係(テスト形態を指定)の4つの
要素からなる。
【0055】このような構造と関連した可能なソース
は、命令アドレス、データアドレス、データ値、及び選
択外部信号を含む。データアドレスとデータ値のソース
は、動作方向(たとえばロードまたは格納)とアドレス空
間(たとえばメモリまたは補助レジスタ)によりさらに指
定される。可能な関係は、大きいか同じ(≧)、小さい
(<)、同じ(=)、及び異なる(≠)を含む。図示した実施形
態において、値は、ニブルマスクと論理的にAND演算さ
れ、適用可能な関係を使用してソース要素と比較され
る。
は、命令アドレス、データアドレス、データ値、及び選
択外部信号を含む。データアドレスとデータ値のソース
は、動作方向(たとえばロードまたは格納)とアドレス空
間(たとえばメモリまたは補助レジスタ)によりさらに指
定される。可能な関係は、大きいか同じ(≧)、小さい
(<)、同じ(=)、及び異なる(≠)を含む。図示した実施形
態において、値は、ニブルマスクと論理的にAND演算さ
れ、適用可能な関係を使用してソース要素と比較され
る。
【0056】モニターがレベル-反応フィルタ(許容また
は防止)として使われる時、一旦条件が真になれば、モ
ニタリングされる値が条件を偽にする新しい値に変化す
るまで、真のままであることに注目すべきである。
は防止)として使われる時、一旦条件が真になれば、モ
ニタリングされる値が条件を偽にする新しい値に変化す
るまで、真のままであることに注目すべきである。
【0057】内部モニターの図示された実施形態におい
て、フィルタは、仮にこれらが同じ“形態”と“アクシ
ョン”パラメータとしてプログラムされれば、より複雑
なテストを生成するために共に結合(論理的にAND演算)
され有益とすることができる。任意のアドレス範囲は、
たとえば大きいか同じ(≧)関係を有するフィルタと小さ
い(<)関係を有するフィルタとを結合させることによっ
てテストすることができる。特定のデータアドレスに対
するデータ値は、データアドレスを有するフィルタとデ
ータ値を有するフィルタとを結合させることによってテ
ストされる。隣接したフィルタは、フィルタ対(iが0、
2、4等の時、iとi+1)に結合されることができる。隣
接したフィルタ対は、フィルタの4対(iが0、4、8等
の時、i,i+1、i+2、i+3)に結合されることができ
る。
て、フィルタは、仮にこれらが同じ“形態”と“アクシ
ョン”パラメータとしてプログラムされれば、より複雑
なテストを生成するために共に結合(論理的にAND演算)
され有益とすることができる。任意のアドレス範囲は、
たとえば大きいか同じ(≧)関係を有するフィルタと小さ
い(<)関係を有するフィルタとを結合させることによっ
てテストすることができる。特定のデータアドレスに対
するデータ値は、データアドレスを有するフィルタとデ
ータ値を有するフィルタとを結合させることによってテ
ストされる。隣接したフィルタは、フィルタ対(iが0、
2、4等の時、iとi+1)に結合されることができる。隣
接したフィルタ対は、フィルタの4対(iが0、4、8等
の時、i,i+1、i+2、i+3)に結合されることができ
る。
【0058】一つの機能中にトレースを非イネーブルと
するが、呼出した機能は非イネーブルとしないために、
一対のフィルタが結合される。これらは、予防アクショ
ン、命令アドレスソース、及び機能の最初の命令のアド
レスから機能の最後の命令までのアドレス範囲でプログ
ラムされる。一つの機能中にトレースと、呼出したあら
ゆる機能を非イネーブルとするために、本実施形態は、
機能入力ポイントに対するフィルタと、各機能出口ポイ
ントに対するフィルタを使用する。入力ポイントフィル
タは、停止アクション、命令アドレスソース及び機能の
最初の命令のアドレスにプログラムされる。出口地点フ
ィルタはスタートアクション、命令アドレスソース、及
び出口ポイントのアドレスでプログラムされる。
するが、呼出した機能は非イネーブルとしないために、
一対のフィルタが結合される。これらは、予防アクショ
ン、命令アドレスソース、及び機能の最初の命令のアド
レスから機能の最後の命令までのアドレス範囲でプログ
ラムされる。一つの機能中にトレースと、呼出したあら
ゆる機能を非イネーブルとするために、本実施形態は、
機能入力ポイントに対するフィルタと、各機能出口ポイ
ントに対するフィルタを使用する。入力ポイントフィル
タは、停止アクション、命令アドレスソース及び機能の
最初の命令のアドレスにプログラムされる。出口地点フ
ィルタはスタートアクション、命令アドレスソース、及
び出口ポイントのアドレスでプログラムされる。
【0059】ここで前述したRTT102の内部モニター
に加えて、本発明は、外部キャプチャーデバイスが外部
モニターを具現するように構成されることもできる。内
部モニターと比較して、これら外部モニターは、RTTユ
ニットから放出されるリアルタイムパケットストリーム
を観測し、外部キャプチャーデバイス320(図3参照)
のためのフィルタとトリガー動作を行う。外部フィルタ
は、RTTユニット102に対するいかなる直接的な影響
を及ぼすものではなく、これらは、外部キャプチャーデ
バイスのメモリ(たとえばDRAM)に格納されたパケットを
フィルタリングする。外部トリガーは、RTTに対する選
択的な外部入力信号を駆動させることによって、RTTユ
ニット102の動作に間接的に影響を及ぼすことができ
る。
に加えて、本発明は、外部キャプチャーデバイスが外部
モニターを具現するように構成されることもできる。内
部モニターと比較して、これら外部モニターは、RTTユ
ニットから放出されるリアルタイムパケットストリーム
を観測し、外部キャプチャーデバイス320(図3参照)
のためのフィルタとトリガー動作を行う。外部フィルタ
は、RTTユニット102に対するいかなる直接的な影響
を及ぼすものではなく、これらは、外部キャプチャーデ
バイスのメモリ(たとえばDRAM)に格納されたパケットを
フィルタリングする。外部トリガーは、RTTに対する選
択的な外部入力信号を駆動させることによって、RTTユ
ニット102の動作に間接的に影響を及ぼすことができ
る。
【0060】外部モニターを提供する外部キャプチャー
デバイス320は、比較的複雑なデバイスである。デバ
イスは、パケット境界を認識できなければならないし、
圧縮されたパケットストリームをリアルタイムで圧縮解
除させることができなければならない(以下、詳細に記
述)。図示した実施形態において、パケット長は、パケ
ット内のフィールドとしてエンコードされないため、外
部キャプチャーデバイスは、長さを決定するために各生
成されたパケットをテストしなければならない。このよ
うな能力を有する外部キャプチャーデバイスは、典型的
にFPGAまたはASICを使用して具現され、論理アナライザ
ーは、一般的に実用的でない。しかしながら、パケット
長のエンコードが本発明と合わせて使われることがで
き、外部キャプチャーデバイスにおいてこのような複雑
度の必要性を軽減させることを認識しなければならな
い。しかし、この場合は、RTT構造とプログラムの増加
された複雑度はトレードオフの関係にある。なぜなら
(i)パケット長が決定され、(ii)決定されたパケット長
が、各パケット(またはパケットのサブセット)上にエン
コードされるという機構が必要となる。
デバイス320は、比較的複雑なデバイスである。デバ
イスは、パケット境界を認識できなければならないし、
圧縮されたパケットストリームをリアルタイムで圧縮解
除させることができなければならない(以下、詳細に記
述)。図示した実施形態において、パケット長は、パケ
ット内のフィールドとしてエンコードされないため、外
部キャプチャーデバイスは、長さを決定するために各生
成されたパケットをテストしなければならない。このよ
うな能力を有する外部キャプチャーデバイスは、典型的
にFPGAまたはASICを使用して具現され、論理アナライザ
ーは、一般的に実用的でない。しかしながら、パケット
長のエンコードが本発明と合わせて使われることがで
き、外部キャプチャーデバイスにおいてこのような複雑
度の必要性を軽減させることを認識しなければならな
い。しかし、この場合は、RTT構造とプログラムの増加
された複雑度はトレードオフの関係にある。なぜなら
(i)パケット長が決定され、(ii)決定されたパケット長
が、各パケット(またはパケットのサブセット)上にエン
コードされるという機構が必要となる。
【0061】本発明のトレース情報は、パケットに格納
される時に選択的に圧縮される。圧縮の使用は、要求さ
れるバッファサイズ及び要求されるトレースピンの帯域
幅を減少させるのに有効である。ここで詳細に記述され
る次の圧縮技術、すなわち(i)可変長エンコード、(ii)
デルタ-エンコード、(iii) ランレングスコーディン
グ、及び(iv)ソース-コード基準は、以下で詳細に記述
するように、本発明のトレースユニットで個別的にまた
は連携して使われるが、他の形態のトレース/パケット
圧縮も本発明と合わせて使われることが出来ることを認
識しなければならない。
される時に選択的に圧縮される。圧縮の使用は、要求さ
れるバッファサイズ及び要求されるトレースピンの帯域
幅を減少させるのに有効である。ここで詳細に記述され
る次の圧縮技術、すなわち(i)可変長エンコード、(ii)
デルタ-エンコード、(iii) ランレングスコーディン
グ、及び(iv)ソース-コード基準は、以下で詳細に記述
するように、本発明のトレースユニットで個別的にまた
は連携して使われるが、他の形態のトレース/パケット
圧縮も本発明と合わせて使われることが出来ることを認
識しなければならない。
【0062】(i)可変長エンコーディング−可変長イン
コーディングは、高い頻度の値を表すために小さいコー
ドを使用し、低い頻度の値を表すために大きいコードを
使用する。ここで使われる“小さい”コードは、規定さ
れた目的のために保管しておいた全体コードワードに比
べて、より小さい数のビットであり、“大きい”コード
は、より大きい数のビットである。したがって、コード
ワードサイズが8ビットならば、たとえば“小さい”コ
ードは、一つの構造で2ビットを含むもので、“大き
い”コードは、6または7ビットを含むものであり得
る。コードワードサイズのこのような構造下で要求され
るビット数は、表現される項目の数に依存する。可変長
コーディングは、一般的に従来技術のよく知られたハフ
マン(Huffman)コーディングと類似しているが、本発明
のRTTコードは、ハフマンコーディングでのビットより
は多数のニブルである。可変長コーディングの使用は、
値の予見された確率分布の知識に依存する。可変長コー
ディングアルゴリズムは、データ処理技術分野で一般的
によく知られており、したがって当業者によって本発明
のRTTに容易に適用される。
コーディングは、高い頻度の値を表すために小さいコー
ドを使用し、低い頻度の値を表すために大きいコードを
使用する。ここで使われる“小さい”コードは、規定さ
れた目的のために保管しておいた全体コードワードに比
べて、より小さい数のビットであり、“大きい”コード
は、より大きい数のビットである。したがって、コード
ワードサイズが8ビットならば、たとえば“小さい”コ
ードは、一つの構造で2ビットを含むもので、“大き
い”コードは、6または7ビットを含むものであり得
る。コードワードサイズのこのような構造下で要求され
るビット数は、表現される項目の数に依存する。可変長
コーディングは、一般的に従来技術のよく知られたハフ
マン(Huffman)コーディングと類似しているが、本発明
のRTTコードは、ハフマンコーディングでのビットより
は多数のニブルである。可変長コーディングの使用は、
値の予見された確率分布の知識に依存する。可変長コー
ディングアルゴリズムは、データ処理技術分野で一般的
によく知られており、したがって当業者によって本発明
のRTTに容易に適用される。
【0063】(ii)デルタエンコーディング−デルタエン
コーディングは、値の一部分だけを格納する。このコー
ディングは、トレースで以前にエンコードされてきた一
つの値を参照する。基準値と他のニブルだけがエンコー
ドされる。デルタエンコードは、値(時間に対してゆっ
くり変化しようとする値)の一時的な位置を表す値に依
存する。パケットのサイズを減少させるために、命令ア
ドレスまたはデータアドレスの固有な、または“デル
タ”部分だけがパケットに記録される。特に、エンコー
ドされようとする完全なアドレスは、固有な部分を確認
するために、以前に記録された同一形態の完全なアドレ
ス(命令またはデータ)と比較される。二つのアドレスの
うち、多くのニブルが命令及びデータアクセスの空間及
び時間的な位置に起因して、同じ値を持つ。最下位ニブ
ルから最上位ニブルまで非−ゼロニブルだけがパケット
に記録される。したがって、固有な部分は、典型的に完
全なアドレスより少ない(潜在的に非常に少ない)。固有
な部分は、部分的なアドレスとして公知される。図4
は、このような圧縮方法論をグラフィック的に図示す
る。
コーディングは、値の一部分だけを格納する。このコー
ディングは、トレースで以前にエンコードされてきた一
つの値を参照する。基準値と他のニブルだけがエンコー
ドされる。デルタエンコードは、値(時間に対してゆっ
くり変化しようとする値)の一時的な位置を表す値に依
存する。パケットのサイズを減少させるために、命令ア
ドレスまたはデータアドレスの固有な、または“デル
タ”部分だけがパケットに記録される。特に、エンコー
ドされようとする完全なアドレスは、固有な部分を確認
するために、以前に記録された同一形態の完全なアドレ
ス(命令またはデータ)と比較される。二つのアドレスの
うち、多くのニブルが命令及びデータアクセスの空間及
び時間的な位置に起因して、同じ値を持つ。最下位ニブ
ルから最上位ニブルまで非−ゼロニブルだけがパケット
に記録される。したがって、固有な部分は、典型的に完
全なアドレスより少ない(潜在的に非常に少ない)。固有
な部分は、部分的なアドレスとして公知される。図4
は、このような圧縮方法論をグラフィック的に図示す
る。
【0064】記録されたアドレスは、完全又は部分的で
あることができ、部分アドレスは、サイズで可変的なの
で、アドレスは、アドレスに後続するサイズフィールド
と共にパケットにエンコードされる。図示した実施形態
において、完全な命令アドレスは、24ビットであり、
完全なデータアドレスは、32ビット長さであるが、所
望によって他の命令/データアドレス長さが使われるこ
とができる。サイズが完全なアドレスのサイズと同じな
らば、パケットでエンコードされた値は、完全なアドレ
スであり、そうでなければ、部分アドレスである。
あることができ、部分アドレスは、サイズで可変的なの
で、アドレスは、アドレスに後続するサイズフィールド
と共にパケットにエンコードされる。図示した実施形態
において、完全な命令アドレスは、24ビットであり、
完全なデータアドレスは、32ビット長さであるが、所
望によって他の命令/データアドレス長さが使われるこ
とができる。サイズが完全なアドレスのサイズと同じな
らば、パケットでエンコードされた値は、完全なアドレ
スであり、そうでなければ、部分アドレスである。
【0065】図示した実施形態のRTTユニット102
は、チップ上の共有バッファに現在格納された各形態の
アドレスのために最も古くなったアドレス及び一番最近
のアドレスの完全なアドレスを格納するために、4個の
レジスタ(すなわち、最も古くなった命令アドレス及び
一番最近の命令アドレスのために2個のレジスタと、最
も古くなったデータアドレス及び一番最近のデータアド
レスのための他の2個のレジスタ)を使用する。一番最
近のアドレスは、次に記録されたアドレスに対する固有
な部分を算出するために使われる。最も古くなったアド
レスは、部分アドレスと同一形態の完全なアドレスを有
する、最も古くなったパケットよりもっと古くなったバ
ッファ内のパケットに位置した部分アドレスの完全なア
ドレスを決定するために、トレースデコーダによる内部
格納モードで使われる(前述した)。アドレスを有するパ
ケットがバッファから除去されるため、最も古くなった
完全なアドレスは、適切に更新される。
は、チップ上の共有バッファに現在格納された各形態の
アドレスのために最も古くなったアドレス及び一番最近
のアドレスの完全なアドレスを格納するために、4個の
レジスタ(すなわち、最も古くなった命令アドレス及び
一番最近の命令アドレスのために2個のレジスタと、最
も古くなったデータアドレス及び一番最近のデータアド
レスのための他の2個のレジスタ)を使用する。一番最
近のアドレスは、次に記録されたアドレスに対する固有
な部分を算出するために使われる。最も古くなったアド
レスは、部分アドレスと同一形態の完全なアドレスを有
する、最も古くなったパケットよりもっと古くなったバ
ッファ内のパケットに位置した部分アドレスの完全なア
ドレスを決定するために、トレースデコーダによる内部
格納モードで使われる(前述した)。アドレスを有するパ
ケットがバッファから除去されるため、最も古くなった
完全なアドレスは、適切に更新される。
【0066】(iii)ランレングスエンコーディング−ラ
ンレングスインコーディング(RLE)は、繰り返しイベン
トをカウントし、各イベントを別途に格納する代わり
に、イベントのカウント値を格納する。ランレングスエ
ンコーディングは、同一形態の順次的なイベントの実行
に依存する。特に、同一のデータ値で形成されたあらゆ
るストリーム(“ラン”と知らされた繰り返し値)は、
インデックス(カウント数)及び単一値で代替される。こ
のような原理は、繰り返しデータ値のシーケンスが出現
する特定のデータ形態に最適に適用される。たとえば、
RLEは、同一のバイトパターンの多数の連続的な発生を
含むデータファイルに效果的に適用される。RLEは、そ
の内容に関係なくいかなる種類のデータにも使われるこ
とができるが、RLEにより圧縮されるデータは、達成で
きる利得のサイズ(圧縮比率)を決定する。ランレングス
エンコーディング技術は、当業者が容易に理解されるは
ずなので、ここではさらに記述しない。
ンレングスインコーディング(RLE)は、繰り返しイベン
トをカウントし、各イベントを別途に格納する代わり
に、イベントのカウント値を格納する。ランレングスエ
ンコーディングは、同一形態の順次的なイベントの実行
に依存する。特に、同一のデータ値で形成されたあらゆ
るストリーム(“ラン”と知らされた繰り返し値)は、
インデックス(カウント数)及び単一値で代替される。こ
のような原理は、繰り返しデータ値のシーケンスが出現
する特定のデータ形態に最適に適用される。たとえば、
RLEは、同一のバイトパターンの多数の連続的な発生を
含むデータファイルに效果的に適用される。RLEは、そ
の内容に関係なくいかなる種類のデータにも使われるこ
とができるが、RLEにより圧縮されるデータは、達成で
きる利得のサイズ(圧縮比率)を決定する。ランレングス
エンコーディング技術は、当業者が容易に理解されるは
ずなので、ここではさらに記述しない。
【0067】(iv)ソース-コード参照−ソース-コード参
照アプローチは、コンパイルされたソースコードをテス
トすることによって誘導され得る情報の格納を未然に防
止することによって、データ圧縮を達成する。たとえ
ば、プロセッサ分岐命令の目標アドレスは、分岐命令オ
ペコード(コンパイルされたソースコードで有用可能)に
エンコードされるので、トレース内では格納される必要
がない。
照アプローチは、コンパイルされたソースコードをテス
トすることによって誘導され得る情報の格納を未然に防
止することによって、データ圧縮を達成する。たとえ
ば、プロセッサ分岐命令の目標アドレスは、分岐命令オ
ペコード(コンパイルされたソースコードで有用可能)に
エンコードされるので、トレース内では格納される必要
がない。
【0068】本発明のトレースデータは、一連のセグメ
ントで構成される。各セグメントは、独立的にデコード
されることができる。一つのセグメントは、SEGSTARTパ
ケットでスタートし、必要に応じてSEGENDパケットで終
了する(付録I及び以下のパケットプロトコルの論議を参
照)。SEGSTARTパケットは、セグメント内で実行される
第1の命令の完全な24ビットアドレスを含む。データ
アドレスを含むセグメント内の第1のパケットは、完全
な32-ビットアドレスを使用する。これらの完全なア
ドレスを記録することは、後続する部分アドレスが現行
セグメントより前のアドレスを参照することを防止す
る。SEGSTARTパケットには多数のゼロニブル(たとえば
本実施形態では少なくとも4個のニブル)が前行してお
り、外部キャプチャーデバイス320またはトレースデ
コーダにより容易にトレース内に位置されることができ
る。
ントで構成される。各セグメントは、独立的にデコード
されることができる。一つのセグメントは、SEGSTARTパ
ケットでスタートし、必要に応じてSEGENDパケットで終
了する(付録I及び以下のパケットプロトコルの論議を参
照)。SEGSTARTパケットは、セグメント内で実行される
第1の命令の完全な24ビットアドレスを含む。データ
アドレスを含むセグメント内の第1のパケットは、完全
な32-ビットアドレスを使用する。これらの完全なア
ドレスを記録することは、後続する部分アドレスが現行
セグメントより前のアドレスを参照することを防止す
る。SEGSTARTパケットには多数のゼロニブル(たとえば
本実施形態では少なくとも4個のニブル)が前行してお
り、外部キャプチャーデバイス320またはトレースデ
コーダにより容易にトレース内に位置されることができ
る。
【0069】セグメントが終了しカウンタが非ゼロであ
る時、SEGENDパケットは、一つ以上の次の条件に基づく
カウンタ値で生成されるが、これらは、(i)(a)セグメン
ト内でユーザーが指定した命令の限界に到達(外部格納
モードだけ)、(b)バッファオーバーフロー、(c)一時的
に非イネーブルとなった後、タイミングトレースがイネ
ーブルとなる、(d)選択的な外部入力信号により要求さ
れる、及び/または(e)RTT内で制御レジスタを記録する
ことによって要求される理由のうちの一つ以上によりセ
グメントが終了し、新しいセグメントがスタートする;
る時、SEGENDパケットは、一つ以上の次の条件に基づく
カウンタ値で生成されるが、これらは、(i)(a)セグメン
ト内でユーザーが指定した命令の限界に到達(外部格納
モードだけ)、(b)バッファオーバーフロー、(c)一時的
に非イネーブルとなった後、タイミングトレースがイネ
ーブルとなる、(d)選択的な外部入力信号により要求さ
れる、及び/または(e)RTT内で制御レジスタを記録する
ことによって要求される理由のうちの一つ以上によりセ
グメントが終了し、新しいセグメントがスタートする;
【0070】(ii)(a)命令トレースがスタートする、(b)
動作状態がRUNまたはTRIGGEREDであり、命令トレースが
初めてまたはフィルタにより一時的に非イネーブルとな
った後、イネーブルになる、及び/または (c)動作状態
がOFFであり、RUNまたはTRIGGEREDに転換され、命令ト
レースがイネーブルとなる(外部格納モードだけ)ことの
うち一つ以上でセグメントがスタートする;及び/または
動作状態がRUNまたはTRIGGEREDであり、命令トレースが
初めてまたはフィルタにより一時的に非イネーブルとな
った後、イネーブルになる、及び/または (c)動作状態
がOFFであり、RUNまたはTRIGGEREDに転換され、命令ト
レースがイネーブルとなる(外部格納モードだけ)ことの
うち一つ以上でセグメントがスタートする;及び/または
【0071】(iii)(a)命令トレース終了、及び/または
(b)動作状態がRUNまたはTRIGGEREDであり、命令トレー
スがイネーブルから非イネーブルに転換される、であ
る。
(b)動作状態がRUNまたはTRIGGEREDであり、命令トレー
スがイネーブルから非イネーブルに転換される、であ
る。
【0072】外部格納モード(図3)において、トレース
のサイズが外部キャプチャーデバイスのイネーブルなメ
モリのサイズを超過すれば、古くなったトレース情報は
廃棄される。外部キャプチャーデバイス320は、セグ
メント境界に対する知識または考慮することなくトレー
スの開始段階を廃棄する。これは、メモリ内で最も古く
なったセグメントが主としてSEGSTARTパケットを消失
し、デルタアドレスエンコーディングであるためデコー
ドされないことを意味する。したがって、本実施形態に
おいて、このような理由で使用できないトレースの量を
制限するため、セグメントは故意に十分に少ない程度に
作られる。
のサイズが外部キャプチャーデバイスのイネーブルなメ
モリのサイズを超過すれば、古くなったトレース情報は
廃棄される。外部キャプチャーデバイス320は、セグ
メント境界に対する知識または考慮することなくトレー
スの開始段階を廃棄する。これは、メモリ内で最も古く
なったセグメントが主としてSEGSTARTパケットを消失
し、デルタアドレスエンコーディングであるためデコー
ドされないことを意味する。したがって、本実施形態に
おいて、このような理由で使用できないトレースの量を
制限するため、セグメントは故意に十分に少ない程度に
作られる。
【0073】内部格納モード(図2)において、古くなっ
たトレース情報は、トレースのサイズがチップ上の共有
バッファ112のサイズを超過すれば、廃棄される。し
かし、SEGSTARTパケットは、この場合には不要である、
なぜならばRTTは最も古くなった完全な命令アドレスと
現在のデータアドレスをバッファ内に格納するからであ
る。それぞれの完全なアドレスは、自分の補助レジスタ
に格納されるが、必要に応じて他の格納構造を使うこと
もできる。
たトレース情報は、トレースのサイズがチップ上の共有
バッファ112のサイズを超過すれば、廃棄される。し
かし、SEGSTARTパケットは、この場合には不要である、
なぜならばRTTは最も古くなった完全な命令アドレスと
現在のデータアドレスをバッファ内に格納するからであ
る。それぞれの完全なアドレスは、自分の補助レジスタ
に格納されるが、必要に応じて他の格納構造を使うこと
もできる。
【0074】本発明のRTTユニット102は、新しいセ
グメントのスタート時、0にリセットされ、命令が実行
されるたびに増加する15ビットセグメント命令カウン
タ(不図示)をさらに含む。カウンタは、セグメント内に
命令オフセットを生成し、命令トレース及び/またはデ
ータトレースがイネーブルとされている間、一つのセグ
メントが担当する実行命令の最大数を制限するために使
われる。
グメントのスタート時、0にリセットされ、命令が実行
されるたびに増加する15ビットセグメント命令カウン
タ(不図示)をさらに含む。カウンタは、セグメント内に
命令オフセットを生成し、命令トレース及び/またはデ
ータトレースがイネーブルとされている間、一つのセグ
メントが担当する実行命令の最大数を制限するために使
われる。
【0075】RTTユニット102のパケットポート10
9は、一つの内部バッファ112に専用されることがで
き、または選択的に多数のRTTsを有するデバイス(図2
2参照)内の多数の内部バッファ間で共有されることが
できる。パケットポート109の帯域幅は、バッファ1
12がめったにオーバーフローしないように十分に大き
くなければならない。バッファがオーバーフローする
時、ユーザーは、バッファは直ちにクリアされるのか、
またはバッファが特定数(たぶん0)のニブルの放出が許
容されるまで、パケットキャプチャーを非イネーブルと
するのかを制御する。両方の場合、パケットキャプチャ
ーが再開する前に、新しいセグメントがスタートする。
また、ユーザーは、オーバーフローがインターラプトを
生成するか否かを制御するが、このようなインターラプ
トは、RTTと関連した一つ以上のコアのパイプラインを
停止させる。ユーザーは、さらに、RTTユニット制御レ
ジスタに書込むことによって、バッファをクリアするこ
とができる。
9は、一つの内部バッファ112に専用されることがで
き、または選択的に多数のRTTsを有するデバイス(図2
2参照)内の多数の内部バッファ間で共有されることが
できる。パケットポート109の帯域幅は、バッファ1
12がめったにオーバーフローしないように十分に大き
くなければならない。バッファがオーバーフローする
時、ユーザーは、バッファは直ちにクリアされるのか、
またはバッファが特定数(たぶん0)のニブルの放出が許
容されるまで、パケットキャプチャーを非イネーブルと
するのかを制御する。両方の場合、パケットキャプチャ
ーが再開する前に、新しいセグメントがスタートする。
また、ユーザーは、オーバーフローがインターラプトを
生成するか否かを制御するが、このようなインターラプ
トは、RTTと関連した一つ以上のコアのパイプラインを
停止させる。ユーザーは、さらに、RTTユニット制御レ
ジスタに書込むことによって、バッファをクリアするこ
とができる。
【0076】前述したように、本発明のRTTと関連した
パケットは、一つ以上のニブルで構成される。パケット
がパケットポート109(たとえば外部モード)を使用し
て共有バッファ112から放出される時、これらは、ニ
ブルストリームを形成する。図1の実施形態の例示的な
パケットポート109においてピン数は、1、2、4、
8、16または32ピンである。また、パケットデータ
に同期されるクロックピンが要求される。一つの入力信
号を提供することが選択できる。設計者は、帯域幅やピ
ン数の要件及び関連考慮事項を基礎にして適切な数のピ
ンを選択する。
パケットは、一つ以上のニブルで構成される。パケット
がパケットポート109(たとえば外部モード)を使用し
て共有バッファ112から放出される時、これらは、ニ
ブルストリームを形成する。図1の実施形態の例示的な
パケットポート109においてピン数は、1、2、4、
8、16または32ピンである。また、パケットデータ
に同期されるクロックピンが要求される。一つの入力信
号を提供することが選択できる。設計者は、帯域幅やピ
ン数の要件及び関連考慮事項を基礎にして適切な数のピ
ンを選択する。
【0077】パケットは、一般的にスタートフィールド
から最後のフィールドへの順に伝送される。一つのフィ
ールドが一つのニブルより大きいならば、最下位ニブル
がまず伝送される(パケットのヘッダーは最下位ニブル
に存在)。パケットポートが一つのニブル(すなわち、1
または2ビット)より少ないならば、ニブルの最下位ビ
ットがまず伝送される。一つのゼロニブル(全4ビット
がゼロ)は、伝送するパケットがない時、パケットの間
に、パケットポート109上で駆動される。このような
技術は、“パディング”と知られている。一つのパケッ
ト内では、このようなパディングは許容されない。パケ
ットポートが単一のニブルより狭いならば、ゼロニブル
を伝送するために複数の周期が要求される。パケットポ
ートが一つのニブルより広いならば、パケットポート上
の全ピンがゼロとなる充分な“パッド”ニブルが伝送さ
れる。
から最後のフィールドへの順に伝送される。一つのフィ
ールドが一つのニブルより大きいならば、最下位ニブル
がまず伝送される(パケットのヘッダーは最下位ニブル
に存在)。パケットポートが一つのニブル(すなわち、1
または2ビット)より少ないならば、ニブルの最下位ビ
ットがまず伝送される。一つのゼロニブル(全4ビット
がゼロ)は、伝送するパケットがない時、パケットの間
に、パケットポート109上で駆動される。このような
技術は、“パディング”と知られている。一つのパケッ
ト内では、このようなパディングは許容されない。パケ
ットポートが単一のニブルより狭いならば、ゼロニブル
を伝送するために複数の周期が要求される。パケットポ
ートが一つのニブルより広いならば、パケットポート上
の全ピンがゼロとなる充分な“パッド”ニブルが伝送さ
れる。
【0078】“X”個またはより多くのパッドニブルの
シーケンス(本実施形態ではX=4)は、後続する第1の非
ゼロニブルが後続するパケットシーケンスの第1のパケ
ットのスタートであることを確認する。特定のパケット
形態(たとえばTRIG及びSEGSTART)に対するパケット境界
がパケットポート109上で容易に検出されるようにす
るために、一部のパケット形態では、オプションとして
4個以上のパッドニブルが前に付加される。しかし、X
個以上のゼロニブルの列は、一つのトレースパケット内
で自然的に発生できることを注目しなければならない。
このような列がパケットの先頭として誤って確認される
ことを防止するために、本発明のRTTユニットは、パケ
ットポート109上でパケットを伝送する前にニブルス
タッフィングを実行する。ここで使われる用語“ニブル
スタッフィング”は、ニブルのビットに所定の値を割当
ることを意味する。たとえば、X=4の場合、三個の連続
するゼロニブルがパケット内に発生すれば、RTTは、す
べてが1である特別ニブルを後に伴う三個のゼロニブル
を出力する(“スタックされたニブル”の特定の場合)。
外部キャプチャーデバイス320は、スタックされたニ
ブルを除去しない、なぜならば、パケットストリームを
デコードするためにトレースデコーダによりこれらが必
要であるからである。データストリーム内において4個
の第1のパッドニブルに後続するパッドニブルは、外部
キャプチャーデバイス320により廃棄される。4個以
上のパッドニブルの任意のシーケンスの後、第1の非ゼ
ロニブルは、rtt_pktポート109の最下位ビット(LS
B)上で出現する。
シーケンス(本実施形態ではX=4)は、後続する第1の非
ゼロニブルが後続するパケットシーケンスの第1のパケ
ットのスタートであることを確認する。特定のパケット
形態(たとえばTRIG及びSEGSTART)に対するパケット境界
がパケットポート109上で容易に検出されるようにす
るために、一部のパケット形態では、オプションとして
4個以上のパッドニブルが前に付加される。しかし、X
個以上のゼロニブルの列は、一つのトレースパケット内
で自然的に発生できることを注目しなければならない。
このような列がパケットの先頭として誤って確認される
ことを防止するために、本発明のRTTユニットは、パケ
ットポート109上でパケットを伝送する前にニブルス
タッフィングを実行する。ここで使われる用語“ニブル
スタッフィング”は、ニブルのビットに所定の値を割当
ることを意味する。たとえば、X=4の場合、三個の連続
するゼロニブルがパケット内に発生すれば、RTTは、す
べてが1である特別ニブルを後に伴う三個のゼロニブル
を出力する(“スタックされたニブル”の特定の場合)。
外部キャプチャーデバイス320は、スタックされたニ
ブルを除去しない、なぜならば、パケットストリームを
デコードするためにトレースデコーダによりこれらが必
要であるからである。データストリーム内において4個
の第1のパッドニブルに後続するパッドニブルは、外部
キャプチャーデバイス320により廃棄される。4個以
上のパッドニブルの任意のシーケンスの後、第1の非ゼ
ロニブルは、rtt_pktポート109の最下位ビット(LS
B)上で出現する。
【0079】パケットポート109は、選択的なrtt_w
ait入力信号を含むことができる。この入力信号が高い
状態に維持される限り、RTTユニット102は、パケッ
トポート109上で新しい値を駆動出来ない。パケット
ポート109は、各ニブルに対するパケット信号のスタ
ートを含むことができる。これらスタート信号は、これ
らの対応ニブルがパケット内の第1のニブルである時、
アサートされる。これらポートスタート信号は、パケッ
トポートのピンカウント値の別途の経費(たとえば25%
付加経費)によって、通常チップ外で駆動されない。代
りに、これらは、多重RTTユニット(図2参照)からパケ
ット境界の容易な検出を許容するためにMTI204によ
り使われる。次の表2は、これらの信号を要約する。
ait入力信号を含むことができる。この入力信号が高い
状態に維持される限り、RTTユニット102は、パケッ
トポート109上で新しい値を駆動出来ない。パケット
ポート109は、各ニブルに対するパケット信号のスタ
ートを含むことができる。これらスタート信号は、これ
らの対応ニブルがパケット内の第1のニブルである時、
アサートされる。これらポートスタート信号は、パケッ
トポートのピンカウント値の別途の経費(たとえば25%
付加経費)によって、通常チップ外で駆動されない。代
りに、これらは、多重RTTユニット(図2参照)からパケ
ット境界の容易な検出を許容するためにMTI204によ
り使われる。次の表2は、これらの信号を要約する。
【0080】
【表2】
【0081】図5a及び図5bを参照すれば、本発明のRT
Tにより支援されるパケット形態が記述してある。特定
のパケットエンコードが付録Iと関連して後で論議され
る。
Tにより支援されるパケット形態が記述してある。特定
のパケットエンコードが付録Iと関連して後で論議され
る。
【0082】本実施形態において、パケット形態は、与
えられたパケット内で第1フィールドとしてセットされ
る。本発明のパケット形態は、一般的に発生頻度に基づ
いて(i)頻繁、及び(ii)レア(rare)の2種類のカテゴリ
ーに分離される。頻繁なパケット形態は、これらのパケ
ット形態をエンコードするために一つのニブルを使用す
る。レアパケット形態は、これらのパケット形態をエン
コードするために二つのニブルを使用する。このような
アプローチは、より頻繁に発生するパケットがただ一つ
のニブルだけを必要とするので、諸費用を減少させる。
えられたパケット内で第1フィールドとしてセットされ
る。本発明のパケット形態は、一般的に発生頻度に基づ
いて(i)頻繁、及び(ii)レア(rare)の2種類のカテゴリ
ーに分離される。頻繁なパケット形態は、これらのパケ
ット形態をエンコードするために一つのニブルを使用す
る。レアパケット形態は、これらのパケット形態をエン
コードするために二つのニブルを使用する。このような
アプローチは、より頻繁に発生するパケットがただ一つ
のニブルだけを必要とするので、諸費用を減少させる。
【0083】図示した実施形態の頻繁なパケット形態
は、一つ以上の特定コード、たとえば0000及び10
00を使用する。コード0000は、パケット間のパデ
ィングのために使われる。コード1000は、レアパケ
ット形態を指定し、第2のニブルが特別にレアパケット
形態を確認する。一部の頻繁なパケット形態は、4ビッ
ト以下にエンコードされ、残りのビットは、パケット内
容の一部をエンコードするのに使用されるか、または、
必要に応じて他の目的のために使われることができる。
一つのパケットフィールドが一つ以上のニブルを占有す
るとき、まず最下位ニブルがパケットに格納される。
は、一つ以上の特定コード、たとえば0000及び10
00を使用する。コード0000は、パケット間のパデ
ィングのために使われる。コード1000は、レアパケ
ット形態を指定し、第2のニブルが特別にレアパケット
形態を確認する。一部の頻繁なパケット形態は、4ビッ
ト以下にエンコードされ、残りのビットは、パケット内
容の一部をエンコードするのに使用されるか、または、
必要に応じて他の目的のために使われることができる。
一つのパケットフィールドが一つ以上のニブルを占有す
るとき、まず最下位ニブルがパケットに格納される。
【0084】パケット形態のコードは、図5a及び図5b
に図示された。各図面の8つの列は、ニブルの最下位3
ビットに対する可能な2進値を表す。各図面の二つの行
は、ニブルの最上位ビットに対する可能な値を表す。RS
Vは、予約組合せを表す。図5aの2部位にSTALLが位置
することに注目しなければならない。このような特性
は、パケット形態の二つの最上位ビットが他の情報をエ
ンコードするのに使用されるよう許容され有益である。
に図示された。各図面の8つの列は、ニブルの最下位3
ビットに対する可能な2進値を表す。各図面の二つの行
は、ニブルの最上位ビットに対する可能な値を表す。RS
Vは、予約組合せを表す。図5aの2部位にSTALLが位置
することに注目しなければならない。このような特性
は、パケット形態の二つの最上位ビットが他の情報をエ
ンコードするのに使用されるよう許容され有益である。
【0085】前述したように、本発明のRTTユニットに
よりキャプチャーされる4種類のトレースイベント、す
なわち(i)命令トレース、(ii)データトレース、(iii)タ
イミングトレース及び(iv)雑多なトレースが存在する。
これらのトレースをより詳細に記述する。
よりキャプチャーされる4種類のトレースイベント、す
なわち(i)命令トレース、(ii)データトレース、(iii)タ
イミングトレース及び(iv)雑多なトレースが存在する。
これらのトレースをより詳細に記述する。
【0086】(i)命令トレース-命令トレースは、注目す
るコアのプログラムカウンタ(PC)の値を記録する。PCに
対する非順次的な変化は、命令実行に同期(分岐、ジャ
ンプ、ループ、条件付き順次)するか、または命令実行
に非同期的(ゼロオーバーヘッドループトリガーまたイ
ンターラプトの受付け)に発生する。
るコアのプログラムカウンタ(PC)の値を記録する。PCに
対する非順次的な変化は、命令実行に同期(分岐、ジャ
ンプ、ループ、条件付き順次)するか、または命令実行
に非同期的(ゼロオーバーヘッドループトリガーまたイ
ンターラプトの受付け)に発生する。
【0087】同期トレースに関して、同期PCのエンコー
ドは命令の形態に依存して変化する。命令形態は、(1)
条件(たとえば条件付き/無条件)と、(2)命令機能(たと
えば順次/ループ/分岐/直接ジャンプ/間接ジャンプ)の
両属性の組合せを使用して記述される。
ドは命令の形態に依存して変化する。命令形態は、(1)
条件(たとえば条件付き/無条件)と、(2)命令機能(たと
えば順次/ループ/分岐/直接ジャンプ/間接ジャンプ)の
両属性の組合せを使用して記述される。
【0088】条件付き命令は、これらが条件コードテス
トをパスした時にのみ実行する。無条件部命令は、条件
コードテストを全く持たず、したがって常に実行する。
順次命令は、PCを命令のサイズで(たとえば本実施形態
で4または8バイト)増加させる。分岐命令(たとえばBc
c、BLcc及びLPcc)は、符号付き直値の隣接オフセット
をPC値に加える。ループ命令(たとえばLPcc)は、LP_S
TART及びLP_ENDレジスタに記録し、条件が不合格(fai
l)であれば、ループの末尾で、第1の命令に分岐する。
直接ジャンプ命令(たとえば直値へのJcc/JLcc)は、PC
に直値の目標をロードする。間接ジャンプ命令(たとえ
ばレジスタに対するJcc/JLcc)は、PCにプロセッサコア
レジスタからの目標をロードする。
トをパスした時にのみ実行する。無条件部命令は、条件
コードテストを全く持たず、したがって常に実行する。
順次命令は、PCを命令のサイズで(たとえば本実施形態
で4または8バイト)増加させる。分岐命令(たとえばBc
c、BLcc及びLPcc)は、符号付き直値の隣接オフセット
をPC値に加える。ループ命令(たとえばLPcc)は、LP_S
TART及びLP_ENDレジスタに記録し、条件が不合格(fai
l)であれば、ループの末尾で、第1の命令に分岐する。
直接ジャンプ命令(たとえば直値へのJcc/JLcc)は、PC
に直値の目標をロードする。間接ジャンプ命令(たとえ
ばレジスタに対するJcc/JLcc)は、PCにプロセッサコア
レジスタからの目標をロードする。
【0089】図示した実施形態において、パケットを生
成するために、ユーザーは、2種類の同期命令トレース
構造、すなわち(i)最大圧縮及び(ii)外部フィルタの一
方を選択する。図6a及び図6bは、これらの2種類の構
造を各々グラフィック的に図示する。図6aと図6bのい
ずれにおいても、括弧値は、生成されたパケット形態に
対する補助記号を含むことに注目しなければならない。
成するために、ユーザーは、2種類の同期命令トレース
構造、すなわち(i)最大圧縮及び(ii)外部フィルタの一
方を選択する。図6a及び図6bは、これらの2種類の構
造を各々グラフィック的に図示する。図6aと図6bのい
ずれにおいても、括弧値は、生成されたパケット形態に
対する補助記号を含むことに注目しなければならない。
【0090】図6aに示すように、最大圧縮構造は、命
令トレースを記録するために必要な最小数のパケットだ
けを生成する。本発明の譲受人により実行された評価に
基づいて、このような構造は、大部分のアプリケーショ
ンに適している。外部フィルタ構造(図6b)は、いずれ
も実行されたか、または無条件の分岐及びジャンプに対
する目標アドレスを有する一つのパケット(IA)を生成
する。外部フィルタは、一般的に、外部キャプチャーデ
バイス320が使われる時、たとえば外部キャプチャー
デバイス320が外部トリガー及び/またはフィルタ用
途のための機能境界を決定するために、リアルタイムで
パケットをテストする時に適切な構造である。しかしな
がら、また、外部フィルタ構造は、バッファオーバーフ
ローを避けるために要求されるパケットポートの帯域幅
を実際的に増加させることを認識しなければならない。
令トレースを記録するために必要な最小数のパケットだ
けを生成する。本発明の譲受人により実行された評価に
基づいて、このような構造は、大部分のアプリケーショ
ンに適している。外部フィルタ構造(図6b)は、いずれ
も実行されたか、または無条件の分岐及びジャンプに対
する目標アドレスを有する一つのパケット(IA)を生成
する。外部フィルタは、一般的に、外部キャプチャーデ
バイス320が使われる時、たとえば外部キャプチャー
デバイス320が外部トリガー及び/またはフィルタ用
途のための機能境界を決定するために、リアルタイムで
パケットをテストする時に適切な構造である。しかしな
がら、また、外部フィルタ構造は、バッファオーバーフ
ローを避けるために要求されるパケットポートの帯域幅
を実際的に増加させることを認識しなければならない。
【0091】図6aの最大圧縮エンコードが後方への条
件付き分岐命令に選択されると、ユーザーは、2つの選
択的エンコード方法から一つを選択する。第1のエンコ
ード方法は、成功/失敗(パス/フェイル)の結果を記
録するために一つのPF(パス/フェイル状態)パケットを
生成する。第2のエンコード方法は、マルチビットカウ
ンタ(たとえば4または8ビット)を含むが、カウンタ
は、条件付き後方分岐命令が成功するたびに増加し、そ
の値は、条件付き後方分岐命令が失敗する各々の場合の
ためにBCBIC(後方向条件付き分岐命令カウンタ)に記録
される。第2(すなわち、カウンタ)の方法は、第1の方
法と比べて極めて良好な圧縮を提供する。
件付き分岐命令に選択されると、ユーザーは、2つの選
択的エンコード方法から一つを選択する。第1のエンコ
ード方法は、成功/失敗(パス/フェイル)の結果を記
録するために一つのPF(パス/フェイル状態)パケットを
生成する。第2のエンコード方法は、マルチビットカウ
ンタ(たとえば4または8ビット)を含むが、カウンタ
は、条件付き後方分岐命令が成功するたびに増加し、そ
の値は、条件付き後方分岐命令が失敗する各々の場合の
ためにBCBIC(後方向条件付き分岐命令カウンタ)に記録
される。第2(すなわち、カウンタ)の方法は、第1の方
法と比べて極めて良好な圧縮を提供する。
【0092】本実施形態のカウンタ構造は、後方向条件
付き分岐の成功の確率が失敗の確率より著しく高いとい
う仮定に基づく。仮に分岐が成功されるならば、カウン
タは増加し、いかなるパケットも生成されない。仮に分
岐が失敗すると、現在カウンタ値を記録するBCBICパケ
ットが生成され、カウンタは、ゼロにセットされる。付
加的に、次のパケット形態、すなわちIA、STF、STV、LD
A、PF、LPEND、及びINTが生成された後(カウンタ値が1
ならば)、カウンタは、0にセットされる(次のパケット
形態の論議を参照)。カウンタがオーバーフローすれ
ば、BCICOVパケットが生成される。カウンタの値が0で
なく、セグメントが次の理由中の一つで終了すれば、カ
ウンタ値を有するSEGENDパケットが生成され、カウンタ
値はゼロに消去されるが、理由は、(a)セグメント内で
ユーザーが指定した命令限界に到達したり、(b)選択的
な外部入力信号により要求されたり、(c)RTT内の制御レ
ジスタに記録することによって要求されたり、及び/ま
たはd)選択的な状態がRUNまたはTRIGGEREDであり、命令
トレースがイネーブルから非イネーブルに転換されたか
らである。
付き分岐の成功の確率が失敗の確率より著しく高いとい
う仮定に基づく。仮に分岐が成功されるならば、カウン
タは増加し、いかなるパケットも生成されない。仮に分
岐が失敗すると、現在カウンタ値を記録するBCBICパケ
ットが生成され、カウンタは、ゼロにセットされる。付
加的に、次のパケット形態、すなわちIA、STF、STV、LD
A、PF、LPEND、及びINTが生成された後(カウンタ値が1
ならば)、カウンタは、0にセットされる(次のパケット
形態の論議を参照)。カウンタがオーバーフローすれ
ば、BCICOVパケットが生成される。カウンタの値が0で
なく、セグメントが次の理由中の一つで終了すれば、カ
ウンタ値を有するSEGENDパケットが生成され、カウンタ
値はゼロに消去されるが、理由は、(a)セグメント内で
ユーザーが指定した命令限界に到達したり、(b)選択的
な外部入力信号により要求されたり、(c)RTT内の制御レ
ジスタに記録することによって要求されたり、及び/ま
たはd)選択的な状態がRUNまたはTRIGGEREDであり、命令
トレースがイネーブルから非イネーブルに転換されたか
らである。
【0093】非同期的な命令トレースに関して、非同期
的なPC変化のエンコードは、イベントの形態に依存す
る。
的なPC変化のエンコードは、イベントの形態に依存す
る。
【0094】本発明の命令トレースは、ゼロオーバーヘ
ッドループメカニズムをさらに含む。特に、PCがゼロオ
ーバーヘッドループ(LP_END-1)で最後の命令に至った
時、ループメカニズムはトリガーされる。仮に、LP_CO
UNTレジスタが1でなければ、PCは、LP_STARTレジスタ
を介してロードされずに、そうでなければPCは増加す
る。仮に、ループ内の最後の命令が分岐またはジャンプ
命令ならば、ループメカニズムによるPCのローディング
は、分岐またはジャンプのための遅延スロット命令の選
択にのみ影響を及ぼす。
ッドループメカニズムをさらに含む。特に、PCがゼロオ
ーバーヘッドループ(LP_END-1)で最後の命令に至った
時、ループメカニズムはトリガーされる。仮に、LP_CO
UNTレジスタが1でなければ、PCは、LP_STARTレジスタ
を介してロードされずに、そうでなければPCは増加す
る。仮に、ループ内の最後の命令が分岐またはジャンプ
命令ならば、ループメカニズムによるPCのローディング
は、分岐またはジャンプのための遅延スロット命令の選
択にのみ影響を及ぼす。
【0095】RTTは、LP_STARTへの条件付き分岐命令と
共に処理することによって、ゼロオーバーヘッドループ
トリガーの結果を記録する。ループトリガーは、機能を
入力させるのに使われないため、最大の圧縮構造が使わ
れる。任意の生成されたパケットは、ループでの最後の
命令によって生成された任意のパケット以後のトレース
に位置される。
共に処理することによって、ゼロオーバーヘッドループ
トリガーの結果を記録する。ループトリガーは、機能を
入力させるのに使われないため、最大の圧縮構造が使わ
れる。任意の生成されたパケットは、ループでの最後の
命令によって生成された任意のパケット以後のトレース
に位置される。
【0096】トレースデコーダは、LP_START及びLP_E
NDの値がループ命令やSR命令によって現在セグメントに
記録された場合には、値を知ることになる。仮にトレー
スデコーダがLP_START及びLP_ENDの値を知らずにゼロ
オーバーヘッドループが使われれば、RTTは、それらの
値を記録するために、LPSTARTパケットに引き続くLPEND
パケットを生成する。
NDの値がループ命令やSR命令によって現在セグメントに
記録された場合には、値を知ることになる。仮にトレー
スデコーダがLP_START及びLP_ENDの値を知らずにゼロ
オーバーヘッドループが使われれば、RTTは、それらの
値を記録するために、LPSTARTパケットに引き続くLPEND
パケットを生成する。
【0097】インターラプトが使われるたびに、RTTに
よってインターラプト(INT)パケットが生成される。こ
のようなパケットは、現在のPC値と新しいPC値を記録す
る。例示した実施形態では、たとえ新しいPC値を格納/
提供する他のメカニズムが本発明と合わせて使われ得る
ということを知るようになっても、新しいPC値は、イン
ターラプトベクターテーブルに格納される。
よってインターラプト(INT)パケットが生成される。こ
のようなパケットは、現在のPC値と新しいPC値を記録す
る。例示した実施形態では、たとえ新しいPC値を格納/
提供する他のメカニズムが本発明と合わせて使われ得る
ということを知るようになっても、新しいPC値は、イン
ターラプトベクターテーブルに格納される。
【0098】(ii)データトレース:本発明のRTTユニット
のデータトレースは、命令をローディングし格納するた
めのデータ値とデータアドレスをキャプチャーする。ユ
ーザーは、ロードデータ、ロードアドレス、格納アドレ
ス及び格納アドレスキャプチャーがイネーブルまたは非
イネーブルとなるか否かを独立的に選択する。また、ユ
ーザーは、キャプチャーのために活性化されるアドレス
空間(メモリ及び補助レジスタ)を独立的に選択する。
のデータトレースは、命令をローディングし格納するた
めのデータ値とデータアドレスをキャプチャーする。ユ
ーザーは、ロードデータ、ロードアドレス、格納アドレ
ス及び格納アドレスキャプチャーがイネーブルまたは非
イネーブルとなるか否かを独立的に選択する。また、ユ
ーザーは、キャプチャーのために活性化されるアドレス
空間(メモリ及び補助レジスタ)を独立的に選択する。
【0099】ロードアドレス(LDA)パケットは、ロード
命令が実行される時、ロード命令(LDB、LDW、LD、LR)
のために生成される。ロードデータ(LDD)パケットは、
データがレジスタファイルに再び記録される時に生成さ
れる。固定されたデータサイズ格納(STF)または可変的
なデータサイズ格納(STV)パケットは、格納命令が実行
される時、メモリ格納命令(STB、STW、ST、SR)のために
生成される。仮にSRがUSERレジスタならば、USERパケッ
トがSTFパケットの代りに生成される。USER、LP_STAR
T、またはLP_ENDレジスタに対するデータトレースは、
常にイネーブルになる;静的及びダイナミックなデータ
トレースイネーブル値は無視される。
命令が実行される時、ロード命令(LDB、LDW、LD、LR)
のために生成される。ロードデータ(LDD)パケットは、
データがレジスタファイルに再び記録される時に生成さ
れる。固定されたデータサイズ格納(STF)または可変的
なデータサイズ格納(STV)パケットは、格納命令が実行
される時、メモリ格納命令(STB、STW、ST、SR)のために
生成される。仮にSRがUSERレジスタならば、USERパケッ
トがSTFパケットの代りに生成される。USER、LP_STAR
T、またはLP_ENDレジスタに対するデータトレースは、
常にイネーブルになる;静的及びダイナミックなデータ
トレースイネーブル値は無視される。
【0100】仮にデータフィルタリング(本明細書で前
述した)が使われているならば、ロード/格納命令の一部
だけが記録されることができる。特に、仮にデータトレ
ースを実行するためにセットされたアクションパラメー
タ(action parameter)と“データアドレス”または“デ
ータ値”にセットされたソースパラメータを備える、少
なくとも一つのイネーブルフィルタが存在すれば、トレ
ースデコーダは、命令トレースがイネーブルになるとし
ても、キャプチャーされたロード/格納のPCを決定出来
ない。仮にデータフィルタリング及び命令トレースがイ
ネーブルになれば、追加的な情報は、STF/STV/LDAパケ
ットに追加されることによって、それらのPC値を確認す
る。外部格納モードにおいて、これは、セグメント命令
カウンタの値を記録することによって達成される。内部
格納モードでは、セグメントカウンタが使われないの
で、セグメントカウンタは、基準として使われることが
できない。したがって、バッファ内の最も古くなった命
令進入からの命令カウントが代わりに使われる。
述した)が使われているならば、ロード/格納命令の一部
だけが記録されることができる。特に、仮にデータトレ
ースを実行するためにセットされたアクションパラメー
タ(action parameter)と“データアドレス”または“デ
ータ値”にセットされたソースパラメータを備える、少
なくとも一つのイネーブルフィルタが存在すれば、トレ
ースデコーダは、命令トレースがイネーブルになるとし
ても、キャプチャーされたロード/格納のPCを決定出来
ない。仮にデータフィルタリング及び命令トレースがイ
ネーブルになれば、追加的な情報は、STF/STV/LDAパケ
ットに追加されることによって、それらのPC値を確認す
る。外部格納モードにおいて、これは、セグメント命令
カウンタの値を記録することによって達成される。内部
格納モードでは、セグメントカウンタが使われないの
で、セグメントカウンタは、基準として使われることが
できない。したがって、バッファ内の最も古くなった命
令進入からの命令カウントが代わりに使われる。
【0101】(iii)タイミングトレース-本発明のRTTユ
ニット102は、微細な(fine-grained)タイミングの記
録を良好に支援する。微細なタイミングトレースがイネ
ーブルになるので、トレースデコーダは、それぞれの命
令が発行された周期と、命令実行に同期されたイベント
(ロードデータをリターンさせることを含む)が発生した
周期を決定できる。
ニット102は、微細な(fine-grained)タイミングの記
録を良好に支援する。微細なタイミングトレースがイネ
ーブルになるので、トレースデコーダは、それぞれの命
令が発行された周期と、命令実行に同期されたイベント
(ロードデータをリターンさせることを含む)が発生した
周期を決定できる。
【0102】外部キャプチャーデバイス320(図3)
は、概略的な(coarse-grained)タイミングの記録を支援
し、したがってこのデバイスは、外部キャプチャーモー
ドだけで支援される。概略的なタイミングにより、トレ
ースデコーダは、それぞれのパケットがパケットポート
上に送信された周期を決定できる。外部キャプチャーデ
バイスは、それぞれのパケットがパケットポート上に現
れた時、各パケットと関連した周期を記録する。例示の
実施形態で、これはパケットが生成された周期と大きい
相互関連がある。
は、概略的な(coarse-grained)タイミングの記録を支援
し、したがってこのデバイスは、外部キャプチャーモー
ドだけで支援される。概略的なタイミングにより、トレ
ースデコーダは、それぞれのパケットがパケットポート
上に送信された周期を決定できる。外部キャプチャーデ
バイスは、それぞれのパケットがパケットポート上に現
れた時、各パケットと関連した周期を記録する。例示の
実施形態で、これはパケットが生成された周期と大きい
相互関連がある。
【0103】RTTは、追加的なパケット形態の生成とタ
イミング情報及びタイミングスタンピングのEL結合によ
り前述した微細なタイミングを支援する。微細なタイミ
ングをイネーブルとすることは、生成されるパケットの
量を増加させる。微細なタイミングがイネーブルになる
時に生成されるタイミング情報は、トレースデコーダ
が、命令が発送された時、ロードデータがレジスタファ
イルに記録された時、及び命令実行に同期的なイベント
が発生した時の周期を決定できるようにする。
イミング情報及びタイミングスタンピングのEL結合によ
り前述した微細なタイミングを支援する。微細なタイミ
ングをイネーブルとすることは、生成されるパケットの
量を増加させる。微細なタイミングがイネーブルになる
時に生成されるタイミング情報は、トレースデコーダ
が、命令が発送された時、ロードデータがレジスタファ
イルに記録された時、及び命令実行に同期的なイベント
が発生した時の周期を決定できるようにする。
【0104】微細なタイミングが静的に非イネーブルか
ら静的にイネーブルに転換した時、16-ビットタイム-
スタンプが消去される。本実施形態で、そのタイム-ス
タンプは、微細なタイミングが静的にイネーブルとなる
周期毎に増加される。タイム-スタンプは、命令実行(前
述した)に同期されたイベントを記録するために生成さ
れるパケットとSEGSTARTパケットに格納される。タイム
-スタンプがオーバーフローされた時、タイム-スタンプ
オーバーフロー(TSOV)パケットが生成される;図17参
照。
ら静的にイネーブルに転換した時、16-ビットタイム-
スタンプが消去される。本実施形態で、そのタイム-ス
タンプは、微細なタイミングが静的にイネーブルとなる
周期毎に増加される。タイム-スタンプは、命令実行(前
述した)に同期されたイベントを記録するために生成さ
れるパケットとSEGSTARTパケットに格納される。タイム
-スタンプがオーバーフローされた時、タイム-スタンプ
オーバーフロー(TSOV)パケットが生成される;図17参
照。
【0105】微細なタイミングがイネーブルになり、命
令トレースがイネーブルになった時、RTTユニットは、S
TALLパケットとSICOVパケットを生成する。STALLパケッ
トは、トレースされるプロセッサコア(105)が命令を
発行出来ない周期毎に生成される。例示的な実施形態の
STALLパケットは、たとえ他のSTALLパケット構造及びプ
ロトコルが使われ得ることを知るようになっても、4-
ビット周期カウント、4-ビット命令カウント、及び選
択的に停止理由(stall reason)を含む。STALLパケット
の4-ビット周期カウントは、プロセッサコーダー(10
5)が停止する連続的な周期の数を含む。4-ビット命令
カウントは、命令またはデータトレースにより生成され
た最後のパケットが生成されたので、発行される命令の
数を含む。仮に命令カウンタがオーバーフローされれ
ば、SICOVパケットが生成される。命令カウントは、本
明細書で前述したロードデータ(LDD)パケットに存在す
ることになる。LDDパケットにあるこのような命令カウ
ント情報は、命令トレースがイネーブルになる場合、ロ
ードデータがレジスタファイルに記録された周期を、ト
レースデータが決定できるようにする。このような理由
で、命令トレースは、データトレースがイネーブルにな
る時、オプションとしてイネーブルになる。
令トレースがイネーブルになった時、RTTユニットは、S
TALLパケットとSICOVパケットを生成する。STALLパケッ
トは、トレースされるプロセッサコア(105)が命令を
発行出来ない周期毎に生成される。例示的な実施形態の
STALLパケットは、たとえ他のSTALLパケット構造及びプ
ロトコルが使われ得ることを知るようになっても、4-
ビット周期カウント、4-ビット命令カウント、及び選
択的に停止理由(stall reason)を含む。STALLパケット
の4-ビット周期カウントは、プロセッサコーダー(10
5)が停止する連続的な周期の数を含む。4-ビット命令
カウントは、命令またはデータトレースにより生成され
た最後のパケットが生成されたので、発行される命令の
数を含む。仮に命令カウンタがオーバーフローされれ
ば、SICOVパケットが生成される。命令カウントは、本
明細書で前述したロードデータ(LDD)パケットに存在す
ることになる。LDDパケットにあるこのような命令カウ
ント情報は、命令トレースがイネーブルになる場合、ロ
ードデータがレジスタファイルに記録された周期を、ト
レースデータが決定できるようにする。このような理由
で、命令トレースは、データトレースがイネーブルにな
る時、オプションとしてイネーブルになる。
【0106】(iv)雑多なトレース-RTT外部の一つ以上の
信号が値を変更した時、EXTSIGパケットが生成される。
設計者は、どんな信号がモニタリングされるかを限定す
る。USERパケットは、プログラムがRTTユニット102
にあるUSER補助レジスタに対するSR命令を実行させる時
に生成される。記録される値は、USERパケットに格納さ
れる。このようなパケットは、プロセッサコーダー(1
05)上で実行中のプログラムがマーカー(marker)をト
レース内に位置させることができるようにする。
信号が値を変更した時、EXTSIGパケットが生成される。
設計者は、どんな信号がモニタリングされるかを限定す
る。USERパケットは、プログラムがRTTユニット102
にあるUSER補助レジスタに対するSR命令を実行させる時
に生成される。記録される値は、USERパケットに格納さ
れる。このようなパケットは、プロセッサコーダー(1
05)上で実行中のプログラムがマーカー(marker)をト
レース内に位置させることができるようにする。
【0107】APEパケットは、アクションポイントが発
生したことを表す。
生したことを表す。
【0108】次のイネーブルの機能は、例示的な実施形
態のRTTユニット102と関連したプログラム可能なレ
ジスタによって制御される;機能は、次のどんな形態の
トレース情報が潜在的にキャプチャーされるかをユーザ
ーが制御できるようにする:(i)命令トレース(インター
ラプト除外);(ii)インターラプト;(iii)ロードデータ;
(iv)格納データ;(v)ロードアドレス;(vi)格納アドレス;
(vii)メモリや補助レジスタまたは両アドレス空間;(vii
i)微細なタイミング;(ix)タイム-スタンピング;(x)選択
的な外部信号変化の記録;及び(xi)アクションポイント
イベントの記録。
態のRTTユニット102と関連したプログラム可能なレ
ジスタによって制御される;機能は、次のどんな形態の
トレース情報が潜在的にキャプチャーされるかをユーザ
ーが制御できるようにする:(i)命令トレース(インター
ラプト除外);(ii)インターラプト;(iii)ロードデータ;
(iv)格納データ;(v)ロードアドレス;(vi)格納アドレス;
(vii)メモリや補助レジスタまたは両アドレス空間;(vii
i)微細なタイミング;(ix)タイム-スタンピング;(x)選択
的な外部信号変化の記録;及び(xi)アクションポイント
イベントの記録。
【0109】ここで、付録Iは、本発明のRTTと関連した
パケットの例示的な実施形態に対するさらなる詳細な説
明を提供する。本発明のパケットは、そのパケット内の
それぞれの可能なフィールドに対する一つの行と、フィ
ールドサイズ(“b”の表示は、ビットを表し、“n”の
表示は、ニブル(nibble)を表す)だけでなく、フィール
ドの名称/機能を表す一つの列を含む表方式のフォーマ
ットを使用して付録Iで説明されている。このような表
方式のフォーマット内でのフィールドは、第1(最初)の
ニブルから最後のニブルまで順に目録化されている。仮
にパケットのニブルがいろいろなフィールドを含むなら
ば、そのフィールドは、最下位ビットから最上位ビット
まで順に目録化されている。ビット0は、本説明のため
に最下位ビットである。ニブルの境界は、それぞれの表
において拡大した行(水平)線で表示されている。仮にニ
ブルがただ部分的に使われるならば、使われないビット
は、予備的なものと処理され、ゼロ(zero)でエンコード
される。
パケットの例示的な実施形態に対するさらなる詳細な説
明を提供する。本発明のパケットは、そのパケット内の
それぞれの可能なフィールドに対する一つの行と、フィ
ールドサイズ(“b”の表示は、ビットを表し、“n”の
表示は、ニブル(nibble)を表す)だけでなく、フィール
ドの名称/機能を表す一つの列を含む表方式のフォーマ
ットを使用して付録Iで説明されている。このような表
方式のフォーマット内でのフィールドは、第1(最初)の
ニブルから最後のニブルまで順に目録化されている。仮
にパケットのニブルがいろいろなフィールドを含むなら
ば、そのフィールドは、最下位ビットから最上位ビット
まで順に目録化されている。ビット0は、本説明のため
に最下位ビットである。ニブルの境界は、それぞれの表
において拡大した行(水平)線で表示されている。仮にニ
ブルがただ部分的に使われるならば、使われないビット
は、予備的なものと処理され、ゼロ(zero)でエンコード
される。
【0110】また、ビットは、パケットの“次のサイ
ズ”のフィールドが存在するかを表すために使われるこ
とができる。もし存在しないならば、サイズは、(サイ
ズの形態によって)デフォルト値として選択される。本
明細書で説明される例示的な実施形態のデフォルト命令
アドレスのサイズは、2ニブルである。同様に、デフォ
ルトデータアドレスサイズは、1ニブルであり、デフォ
ルトデータ値のサイズは、たとえ他の値が代わりに使わ
れることができるとしても、1ニブルである。パケット
で“次のサイズ”のフィールド以後に位置するサイズフ
ィールドは、一部のパケットの場合、ユーザーのセット
(たとえば、STFパケットに対してはデータアドレスサイ
ズフィールド)によって異なる。この場合、“次のサイ
ズフィールド存在”フラッグは、如何なるサイズのフィ
ールドが次に来てもこれを言及する。一部の場合、これ
は全く存在しない。このパケットサイズは、一実施形態
において、より少ないニブル数としてコーディングされ
る。これは、3-ビットサイズフィールドが1ないし8
ニブルを指定できるようにする。
ズ”のフィールドが存在するかを表すために使われるこ
とができる。もし存在しないならば、サイズは、(サイ
ズの形態によって)デフォルト値として選択される。本
明細書で説明される例示的な実施形態のデフォルト命令
アドレスのサイズは、2ニブルである。同様に、デフォ
ルトデータアドレスサイズは、1ニブルであり、デフォ
ルトデータ値のサイズは、たとえ他の値が代わりに使わ
れることができるとしても、1ニブルである。パケット
で“次のサイズ”のフィールド以後に位置するサイズフ
ィールドは、一部のパケットの場合、ユーザーのセット
(たとえば、STFパケットに対してはデータアドレスサイ
ズフィールド)によって異なる。この場合、“次のサイ
ズフィールド存在”フラッグは、如何なるサイズのフィ
ールドが次に来てもこれを言及する。一部の場合、これ
は全く存在しない。このパケットサイズは、一実施形態
において、より少ないニブル数としてコーディングされ
る。これは、3-ビットサイズフィールドが1ないし8
ニブルを指定できるようにする。
【0111】STF、STV、及びLDAパケットは、セグメン
ト命令カウントフィールドをさらに含むことができる。
例示的な実施形態で、このようなフィールドは、(i)完
全な15-ビットセグメント命令カウント値、又は(ii)
現在の命令セグメントカウントと最後にエンコードされ
たセグメント命令カウントとの間の3-ビット差(常に正
である)の一方としてエンコードされる。パケット内に
含まれた一つのビットフラッグは、どんなエンコード方
法が使われたかを指定する。セグメント命令カウントが
セグメントにエンコードされる最初の瞬間に、完全な値
がエンコードされる。
ト命令カウントフィールドをさらに含むことができる。
例示的な実施形態で、このようなフィールドは、(i)完
全な15-ビットセグメント命令カウント値、又は(ii)
現在の命令セグメントカウントと最後にエンコードされ
たセグメント命令カウントとの間の3-ビット差(常に正
である)の一方としてエンコードされる。パケット内に
含まれた一つのビットフラッグは、どんなエンコード方
法が使われたかを指定する。セグメント命令カウントが
セグメントにエンコードされる最初の瞬間に、完全な値
がエンコードされる。
【0112】他の実施形態図7を参照すれば、本発明の
第2の例示的な実施形態が詳細に説明されている。この
ような第2の実施形態は、前述した図1ないし図6bの
実施形態と共通の多数の特徴を有し、さらに追加的な特
徴及び改善点をも併合する。次の論議では、このような
追加的な特徴及び改善点を詳細に説明する。しかしなが
ら、二つの実施形態(そして実質的に他の実施形態)から
の所望の特徴は、ここに提供される開示が提供されれ
ば、当業者によってRTT発明の注文製作された実施形態
に容易に併合されることができることが分かるだろう。
したがって、図1及び図7の実施形態は、拡大された本
発明の特徴及び属性に対する多くの可能な置換を例示す
るものに過ぎない。
第2の例示的な実施形態が詳細に説明されている。この
ような第2の実施形態は、前述した図1ないし図6bの
実施形態と共通の多数の特徴を有し、さらに追加的な特
徴及び改善点をも併合する。次の論議では、このような
追加的な特徴及び改善点を詳細に説明する。しかしなが
ら、二つの実施形態(そして実質的に他の実施形態)から
の所望の特徴は、ここに提供される開示が提供されれ
ば、当業者によってRTT発明の注文製作された実施形態
に容易に併合されることができることが分かるだろう。
したがって、図1及び図7の実施形態は、拡大された本
発明の特徴及び属性に対する多くの可能な置換を例示す
るものに過ぎない。
【0113】図7の実施形態においてRTTユニット(70
2)は、(i)命令トレース、(ii)データトレース、(iii)
イベントトレース、及び(iv)タイミングトレースを含む
4形態のトレース情報を提供する。後述するように、こ
の実施形態の“イベント”トレースは、命令実行とは関
連のない、選択されたコア状態変化を記録する。また、
タイミングトレースは、命令タイミングトレース及びイ
ベントタイミングトレースのような二つの成分に分けら
れる。命令タイミングトレースは、命令実行の周期を記
録する。イベントタイミングトレースは、イベントの周
期を記録する。
2)は、(i)命令トレース、(ii)データトレース、(iii)
イベントトレース、及び(iv)タイミングトレースを含む
4形態のトレース情報を提供する。後述するように、こ
の実施形態の“イベント”トレースは、命令実行とは関
連のない、選択されたコア状態変化を記録する。また、
タイミングトレースは、命令タイミングトレース及びイ
ベントタイミングトレースのような二つの成分に分けら
れる。命令タイミングトレースは、命令実行の周期を記
録する。イベントタイミングトレースは、イベントの周
期を記録する。
【0114】RTT(702)は、あらゆる正当なコードシ
ーケンス(LOOPENDの場合及びゼロ-費用ループlimmの場
合に対してSRを除外)がキャプチャーされるトレースを
生成する。
ーケンス(LOOPENDの場合及びゼロ-費用ループlimmの場
合に対してSRを除外)がキャプチャーされるトレースを
生成する。
【0115】また、自己−変更コードのカテゴリー下に
あるような格納命令でインターラプトベクター表をロー
ドするプログラムは、それぞれのベクターエントリーの
第1の命令がコンパイルされたソースコードに位置して
いるコードへの無条件的な直接ジャンプの場合に支援さ
れる。
あるような格納命令でインターラプトベクター表をロー
ドするプログラムは、それぞれのベクターエントリーの
第1の命令がコンパイルされたソースコードに位置して
いるコードへの無条件的な直接ジャンプの場合に支援さ
れる。
【0116】図7のRTTで、各パケットのサイズ及び内
容は、有利にもコンパイルされたソースコードへのアク
セス無しに決定されることができる。
容は、有利にもコンパイルされたソースコードへのアク
セス無しに決定されることができる。
【0117】前述した図1のRTTのように、図7のRTT
(702)は、構成時(build-time)でのいくつかの設定
と実行時(run-time)での他の設定のような多くの選択事
項を持つ。設計者は、RTLソースでの常数を編集したり
構成する途中に構成をセットすることで、構成時間選択
事項をセットする。ユーザーは、RTTの補助レジスタに
記録するコア上のプログラムを実行させたり、RTT補助
レジスタに記録する外部ホストを用いてデバッグポート
を使用することによって、実行-時間選択事項をセット
する。コアを介してRTT補助レジスタに記録すること
は、前述したようなロックメカニズム(RTT_LOCKレジス
タ)を介してさらに権限が附与されるが、全的に防止さ
れることもできる(RTT_HOST_CTLレジスタのNAWビッ
ト)。ロックは、コアプログラムがRTTレジスタに誤って
記録する確率を減少させる。大部分の実行-時間選択事
項は、ユーザーに対するインターフェースを単純化させ
るためにデバッグ(たとえば前述したSeeCodeデバッグ)
により自動的に処理される。
(702)は、構成時(build-time)でのいくつかの設定
と実行時(run-time)での他の設定のような多くの選択事
項を持つ。設計者は、RTLソースでの常数を編集したり
構成する途中に構成をセットすることで、構成時間選択
事項をセットする。ユーザーは、RTTの補助レジスタに
記録するコア上のプログラムを実行させたり、RTT補助
レジスタに記録する外部ホストを用いてデバッグポート
を使用することによって、実行-時間選択事項をセット
する。コアを介してRTT補助レジスタに記録すること
は、前述したようなロックメカニズム(RTT_LOCKレジス
タ)を介してさらに権限が附与されるが、全的に防止さ
れることもできる(RTT_HOST_CTLレジスタのNAWビッ
ト)。ロックは、コアプログラムがRTTレジスタに誤って
記録する確率を減少させる。大部分の実行-時間選択事
項は、ユーザーに対するインターフェースを単純化させ
るためにデバッグ(たとえば前述したSeeCodeデバッグ)
により自動的に処理される。
【0118】動作中に、仮にRTTトレースバッファが新
しいトレース情報の記録を続いて維持する程に十分に早
く排出されることができなければ、バッファは、オーバ
ーフローされる。RTTは、バッファがオーバーフローさ
れる時、コアをインターラプトするように構成されるこ
とができる(RTT_BUF_CTLレジスタのI/Oビット)。バッ
ファがオーバーフローされることを完璧に防ぎ、あらゆ
る命令がトレースされることを保障するために、完全な
トレースモードが選択されることができる(RTT_EN_DI
S_CTLレジスタのFTビット)。完全なトレースモード
で、コアは、バッファがオーバーフローされることを防
止するために停止する。
しいトレース情報の記録を続いて維持する程に十分に早
く排出されることができなければ、バッファは、オーバ
ーフローされる。RTTは、バッファがオーバーフローさ
れる時、コアをインターラプトするように構成されるこ
とができる(RTT_BUF_CTLレジスタのI/Oビット)。バッ
ファがオーバーフローされることを完璧に防ぎ、あらゆ
る命令がトレースされることを保障するために、完全な
トレースモードが選択されることができる(RTT_EN_DI
S_CTLレジスタのFTビット)。完全なトレースモード
で、コアは、バッファがオーバーフローされることを防
止するために停止する。
【0119】また、図7の実施形態は、“フラットン(f
latten) ”ユニット(770)を含む。フラットンユニ
ット(770)は、プロセッサを観測し、命令、インタ
ーラプト、ループトリガー及びロードデータイベントが
発生する時を決定する。フラットンユニットの動作は、
以下で詳細に説明する。
latten) ”ユニット(770)を含む。フラットンユニ
ット(770)は、プロセッサを観測し、命令、インタ
ーラプト、ループトリガー及びロードデータイベントが
発生する時を決定する。フラットンユニットの動作は、
以下で詳細に説明する。
【0120】本発明のパケットポートは、格納デバイス
にパケット(信号rtt_pkt_data)を伝送する。もしバッ
ファがオーバーフローされると、インターラプトが選択
的にコアに伝送される。
にパケット(信号rtt_pkt_data)を伝送する。もしバッ
ファがオーバーフローされると、インターラプトが選択
的にコアに伝送される。
【0121】動作中に、ハードウェアの再セットが発生
した時、RTT(702)は、非イネーブルとになるように
セットされ、すなわち非-トリガーされた状態にセット
され、そのバッファは消去される。RTTがイネーブルに
なる時にだけ、生成ユニット(744)はトレース情報を
記録し、モニターユニット(742)はトリガーを監視す
る。バッファ(712)は、バッファ内のパケットをパケ
ットポートに排出する。RTTが非イネーブルの状態から
イネーブルの状態に転換する時、バッファが消去され、
トリガーが消去され(RTTがイネーブルになる同じ瞬間に
セットされなければ)、トレース情報を記録するために
使われた生成ユニット(744)の任意の内部状態が消去
される。トリガーが発生した時、RTTは、出力パケット
ストリームにトリガーを記録して、キャプチャーデバイ
ス(722)がトリガーの発生時に、自分の動作を変更で
きるようにする。仮にキャプチャーデバイスがRTTから
トリガーを検出した時、ポスト-トリガー(post-trigge
r)のためにセットされれば、最小モードがRTT_DIS_CT
LレジスタのMMビットを1にセットすることで、イネー
ブルになることができる。最小モードで、RTTは、自分
がトリガーされない時、極めて低い速度でパケットを生
成し、その後、トリガーされた時、正常的にパケットを
生成する。このモードは、事実上トリガーが発生する前
にバッファがオーバーフローされないということを保障
する。
した時、RTT(702)は、非イネーブルとになるように
セットされ、すなわち非-トリガーされた状態にセット
され、そのバッファは消去される。RTTがイネーブルに
なる時にだけ、生成ユニット(744)はトレース情報を
記録し、モニターユニット(742)はトリガーを監視す
る。バッファ(712)は、バッファ内のパケットをパケ
ットポートに排出する。RTTが非イネーブルの状態から
イネーブルの状態に転換する時、バッファが消去され、
トリガーが消去され(RTTがイネーブルになる同じ瞬間に
セットされなければ)、トレース情報を記録するために
使われた生成ユニット(744)の任意の内部状態が消去
される。トリガーが発生した時、RTTは、出力パケット
ストリームにトリガーを記録して、キャプチャーデバイ
ス(722)がトリガーの発生時に、自分の動作を変更で
きるようにする。仮にキャプチャーデバイスがRTTから
トリガーを検出した時、ポスト-トリガー(post-trigge
r)のためにセットされれば、最小モードがRTT_DIS_CT
LレジスタのMMビットを1にセットすることで、イネー
ブルになることができる。最小モードで、RTTは、自分
がトリガーされない時、極めて低い速度でパケットを生
成し、その後、トリガーされた時、正常的にパケットを
生成する。このモードは、事実上トリガーが発生する前
にバッファがオーバーフローされないということを保障
する。
【0122】RTT_STAT補助レジスタのENビットは、RTT
が現在イネーブルになっているか否かを示す。RTTは、
適当な命令をRTT_CMDレジスタに記録するコアまたはホ
ストにより、または0から1に転換するrtt_en_on及
びrtt_en_off入力信号によりイネーブルになるか非イ
ネーブルとなる。また、モニターは、プログラムされた
状況が発生する時、RTTを非イネーブルにすることがで
きる。
が現在イネーブルになっているか否かを示す。RTTは、
適当な命令をRTT_CMDレジスタに記録するコアまたはホ
ストにより、または0から1に転換するrtt_en_on及
びrtt_en_off入力信号によりイネーブルになるか非イ
ネーブルとなる。また、モニターは、プログラムされた
状況が発生する時、RTTを非イネーブルにすることがで
きる。
【0123】RTT_STAT補助レジスタのTRビットは、RTT
が現在トリガーされているか否かを示す。RTTは、たと
えば(a) 適当な命令をRTT_CMDレジスタに記録するコア
やホスト、(b)トリガー状況を検出するモニター、(c)ア
クションポイントトリガー、または(d)0から1に転換
するrtt_trig_on入力信号によりトリガーされる。
が現在トリガーされているか否かを示す。RTTは、たと
えば(a) 適当な命令をRTT_CMDレジスタに記録するコア
やホスト、(b)トリガー状況を検出するモニター、(c)ア
クションポイントトリガー、または(d)0から1に転換
するrtt_trig_on入力信号によりトリガーされる。
【0124】仮に完全なトレースが非イネーブルになれ
ば、RTTは、バッファのオーバーフローが発生した時、
トレース情報をキャプチャーすることをブレーキし、バ
ッファがプログラム可能な空き値(programmable emptin
ess value)に至った時に再開する。RTT_STAT補助レジ
スタのOVビットは、バッファがオーバーフロー状態にあ
るか否かを表す。仮に完全なトレースがイネーブルにな
れば、RTTは、バッファのオーバーフローを防止するた
めに、コアパイプラインを厳格に停止させる。これは、
一部のアプリケーションでは好ましくないこともある。
ば、RTTは、バッファのオーバーフローが発生した時、
トレース情報をキャプチャーすることをブレーキし、バ
ッファがプログラム可能な空き値(programmable emptin
ess value)に至った時に再開する。RTT_STAT補助レジ
スタのOVビットは、バッファがオーバーフロー状態にあ
るか否かを表す。仮に完全なトレースがイネーブルにな
れば、RTTは、バッファのオーバーフローを防止するた
めに、コアパイプラインを厳格に停止させる。これは、
一部のアプリケーションでは好ましくないこともある。
【0125】また、本実施形態(図7)のRTTは、特定の
数の内部モニターを含む。それぞれのモニターは、ダイ
ナミックにトレースキャプチャーを制御し、トリガーを
検出するために、フラットンユニット(770)からのト
レース情報を観測する。モニターは、トリガー、フィル
タ、または両方で構成される。フィルタは、ユーザー
が、全体プログラムの代りに実行プログラム部分をトレ
ースすることによってキャプチャーされるトレース情報
の量を減少させることができるようにする。
数の内部モニターを含む。それぞれのモニターは、ダイ
ナミックにトレースキャプチャーを制御し、トリガーを
検出するために、フラットンユニット(770)からのト
レース情報を観測する。モニターは、トリガー、フィル
タ、または両方で構成される。フィルタは、ユーザー
が、全体プログラムの代りに実行プログラム部分をトレ
ースすることによってキャプチャーされるトレース情報
の量を減少させることができるようにする。
【0126】それぞれのモニターは、ダイナミックなイ
ネーブルマスク、ソース、相互関連、動作及びトリガー
でプログラムされる。モニターは、RTTが非イネーブル
になる時、プログラムされる。以下で、このような特徴
をより詳細に説明する。
ネーブルマスク、ソース、相互関連、動作及びトリガー
でプログラムされる。モニターは、RTTが非イネーブル
になる時、プログラムされる。以下で、このような特徴
をより詳細に説明する。
【0127】モニターがフィルタ動作を行う時には、ど
のようなダイナミックなイネーブルがフィルタによって
影響を受けるかを指定するダイナミックなイネーブルマ
スクが使われる。命令トレースダイナミックイネーブ
ル;命令タイミングトレースダイナミックイネーブル;デ
ータトレースダイナミックイネーブルを含むそれぞれの
ダイナミックなイネーブルのために1ビットが存在す
る。仮に命令タイミングトレースダイナミックイネーブ
ルやデータトレースダイナミックイネーブルが“1”な
らば、命令トレースダイナミックイネーブルは、“1”
となるように強要される。仮に任意のフィルタがデータ
トレースに影響を与えるように構成されると、データフ
ィルタリングが活性化される。データフィルタリングが
活性化した時、RTTは、DATAパケットにセグメント命令
オフセットを含むように構成されなければならない。こ
れは、トレースデコーダプログラムが、どんなロード/
格納がDATAパケットと関連されるかを決定できるように
するために行われる。
のようなダイナミックなイネーブルがフィルタによって
影響を受けるかを指定するダイナミックなイネーブルマ
スクが使われる。命令トレースダイナミックイネーブ
ル;命令タイミングトレースダイナミックイネーブル;デ
ータトレースダイナミックイネーブルを含むそれぞれの
ダイナミックなイネーブルのために1ビットが存在す
る。仮に命令タイミングトレースダイナミックイネーブ
ルやデータトレースダイナミックイネーブルが“1”な
らば、命令トレースダイナミックイネーブルは、“1”
となるように強要される。仮に任意のフィルタがデータ
トレースに影響を与えるように構成されると、データフ
ィルタリングが活性化される。データフィルタリングが
活性化した時、RTTは、DATAパケットにセグメント命令
オフセットを含むように構成されなければならない。こ
れは、トレースデコーダプログラムが、どんなロード/
格納がDATAパケットと関連されるかを決定できるように
するために行われる。
【0128】ユーザーは、イネーブルに変わる時パケッ
トが生成されるので、命令トレース及び命令タイミング
トレースと関連したフィルタに対して注意すべきであ
る。特に、SEGSTARTパケットは、命令トレースがイネー
ブルになるたびに生成され、ITTDENパケットは、命令タ
イミングのトレースダイナミックイネーブルが値を変え
るたびに生成され、STALLパケットは、ストール周期カ
ウンタがフラッシュ(flush)される必要がある場合、命
令タイミングのトレースダイナミックのイネーブルが非
イネーブルになる時に生成される。SEGSTARTパケット
は、ITTDENパケットよりずっと大きく、したがって、SE
GSTARTパケットは、バッファのオーバーフローにより大
きな悪影響を与えることになる。
トが生成されるので、命令トレース及び命令タイミング
トレースと関連したフィルタに対して注意すべきであ
る。特に、SEGSTARTパケットは、命令トレースがイネー
ブルになるたびに生成され、ITTDENパケットは、命令タ
イミングのトレースダイナミックイネーブルが値を変え
るたびに生成され、STALLパケットは、ストール周期カ
ウンタがフラッシュ(flush)される必要がある場合、命
令タイミングのトレースダイナミックのイネーブルが非
イネーブルになる時に生成される。SEGSTARTパケット
は、ITTDENパケットよりずっと大きく、したがって、SE
GSTARTパケットは、バッファのオーバーフローにより大
きな悪影響を与えることになる。
【0129】本実施形態のモニターソースは、命令アド
レス、データアドレス及びデータ値(ST、SR、LR命令の
み)を含む。データアドレスとデータ値は、方向(ロー
ド、格納、またはいずれか一方)及びアドレス空間(メモ
リ、補助レジスタ、またはいずれか一方)にさらに指定
される。
レス、データアドレス及びデータ値(ST、SR、LR命令の
み)を含む。データアドレスとデータ値は、方向(ロー
ド、格納、またはいずれか一方)及びアドレス空間(メモ
リ、補助レジスタ、またはいずれか一方)にさらに指定
される。
【0130】図1の実施形態のように、許容されたモニ
ター関係は、次の通りである:大きいか同じ(≧)、小さ
い(<)、同じ(=)及び異なる(≠)。その関係は、それぞれ
のモニターに関連した32-ビットのプログラム可能な
値に対してソース値を比較する。しかし、本実施形態で
のモニターアクションは、表3の内容を含む。
ター関係は、次の通りである:大きいか同じ(≧)、小さ
い(<)、同じ(=)及び異なる(≠)。その関係は、それぞれ
のモニターに関連した32-ビットのプログラム可能な
値に対してソース値を比較する。しかし、本実施形態で
のモニターアクションは、表3の内容を含む。
【0131】
【表3】
【0132】それぞれのモニターは、それぞれのダイナ
ミックなイネーブルに対する開始、ブレーキ、許容及び
防止信号を提供する。仮にいろいろなモニターが相反動
作を要求しているならば(開始/停止または許容/防止)、
最も低いインデックスを有するモニターが優勢である
(モニターは、たとえ他のスキームが容易に代替され得
ることが分かるが、本実施形態では、ゼロから1以下の
モニターの数まで番号が付けられる)。
ミックなイネーブルに対する開始、ブレーキ、許容及び
防止信号を提供する。仮にいろいろなモニターが相反動
作を要求しているならば(開始/停止または許容/防止)、
最も低いインデックスを有するモニターが優勢である
(モニターは、たとえ他のスキームが容易に代替され得
ることが分かるが、本実施形態では、ゼロから1以下の
モニターの数まで番号が付けられる)。
【0133】仮に許容/防止アクションが活性化され
ば、このアクションは、ダイナミックなイネーブルの現
在値を無視する。許容/防止動作が非活性になる時、ダ
イナミックなイネーブルの値は、許容/防止が活性化す
る前に存在する値に戻る。
ば、このアクションは、ダイナミックなイネーブルの現
在値を無視する。許容/防止動作が非活性になる時、ダ
イナミックなイネーブルの値は、許容/防止が活性化す
る前に存在する値に戻る。
【0134】それぞれのモニターは、トリガーとしても
構成されることができる。モニターと関連した“トリガ
ー”条件が真である時、RTTは、トリガーされる。図1
の実施形態のように、本実施形態におけるモニターの状
況は、より複雑なテストを生成するために共に結合され
ることができる(論理AND)。それぞれの対(インデックス
2n及び2n+1)が選択的に結合されるか、それぞれの
クワッド(quad)(インデックス4n、4n+1、4n+2及び
4n+3)が選択的に結合されることができる。モニター
が結合された時、それぞれのモニターの条件は、対また
はクワッドのすべての他のモニターも真である場合にの
み、真となる。対またはクワッドのすべての他のモニタ
ーは、固有のアクションを有し、同一にプログラムされ
たフィールドをトリガーする。ソース及び関連フィール
ドは、互いに異なってもよい。
構成されることができる。モニターと関連した“トリガ
ー”条件が真である時、RTTは、トリガーされる。図1
の実施形態のように、本実施形態におけるモニターの状
況は、より複雑なテストを生成するために共に結合され
ることができる(論理AND)。それぞれの対(インデックス
2n及び2n+1)が選択的に結合されるか、それぞれの
クワッド(quad)(インデックス4n、4n+1、4n+2及び
4n+3)が選択的に結合されることができる。モニター
が結合された時、それぞれのモニターの条件は、対また
はクワッドのすべての他のモニターも真である場合にの
み、真となる。対またはクワッドのすべての他のモニタ
ーは、固有のアクションを有し、同一にプログラムされ
たフィールドをトリガーする。ソース及び関連フィール
ドは、互いに異なってもよい。
【0135】任意のアドレス範囲は、“より大きいか同
じ”関係を有する一つのモニターと、“より小さい”関
係を有する第2のモニターとを組合わせることでテスト
することができる。特定のデータアドレスに対するデー
タ値は、データアドレスを有するモニターとデータ値を
有するモニターとを組合わせることでテストされる。ま
た、他のテスト方法も使われることができる。
じ”関係を有する一つのモニターと、“より小さい”関
係を有する第2のモニターとを組合わせることでテスト
することができる。特定のデータアドレスに対するデー
タ値は、データアドレスを有するモニターとデータ値を
有するモニターとを組合わせることでテストされる。ま
た、他のテスト方法も使われることができる。
【0136】機能途中にトレースを非イネーブルとする
ために(しかし、呼出した機能は非イネーブルとしな
い)、モニター対が組合わされる。モニターは、防止動
作、命令アドレスソース及び機能において第1の命令の
アドレスから機能内の最後の命令までのアドレス範囲で
プログラムされる。
ために(しかし、呼出した機能は非イネーブルとしな
い)、モニター対が組合わされる。モニターは、防止動
作、命令アドレスソース及び機能において第1の命令の
アドレスから機能内の最後の命令までのアドレス範囲で
プログラムされる。
【0137】機能途中にトレースを非イネーブルとする
ために(そして呼出したあらゆる機能を非イネーブルと
するために)、モニターは、機能進入点に対して使用
し、モニターは、機能出口点それぞれのために使用す
る。進入点フィルタは、ブレーキ動作、命令アドレスソ
ース及び機能において第1の命令のアドレスでプログラ
ムされる。出口点モニターは、開始アクション、命令ア
ドレスソース、及び出口点のアドレスでプログラムされ
る。
ために(そして呼出したあらゆる機能を非イネーブルと
するために)、モニターは、機能進入点に対して使用
し、モニターは、機能出口点それぞれのために使用す
る。進入点フィルタは、ブレーキ動作、命令アドレスソ
ース及び機能において第1の命令のアドレスでプログラ
ムされる。出口点モニターは、開始アクション、命令ア
ドレスソース、及び出口点のアドレスでプログラムされ
る。
【0138】データエンコーディング下で、本実施形態
のRTTモジュール702は、各形態のアドレス(命令及び
データ)のうち、一番最近にエンコードされたアドレス
の全アドレスを格納するために、2つ(4つに対して)の
レジスタを使用する。これらアドレスは、その次に記録
されるアドレスに対する固有部分を計算するのに使われ
る。
のRTTモジュール702は、各形態のアドレス(命令及び
データ)のうち、一番最近にエンコードされたアドレス
の全アドレスを格納するために、2つ(4つに対して)の
レジスタを使用する。これらアドレスは、その次に記録
されるアドレスに対する固有部分を計算するのに使われ
る。
【0139】以前のように、トレースは、独立的にデコ
ードされるそれぞれのセグメントを有するセグメントと
して構成される。セグメントは、SEGSTARTパケットで始
まり、その次のSEGSTARTパケットで終わる。一般的に、
SEGSTARTパケットは、セグメント内において一番目に実
行されるか、又はインターラプトされる命令の完全な2
4-ビットアドレスを含む。RTTが非イネーブルになる時
に生成されるSEGSTARTパケットは、例外である。このSE
GSTARTパケットは、パイプライン(まだ実行又はインタ
ーラプトされない)での次の命令アドレスを含む。
ードされるそれぞれのセグメントを有するセグメントと
して構成される。セグメントは、SEGSTARTパケットで始
まり、その次のSEGSTARTパケットで終わる。一般的に、
SEGSTARTパケットは、セグメント内において一番目に実
行されるか、又はインターラプトされる命令の完全な2
4-ビットアドレスを含む。RTTが非イネーブルになる時
に生成されるSEGSTARTパケットは、例外である。このSE
GSTARTパケットは、パイプライン(まだ実行又はインタ
ーラプトされない)での次の命令アドレスを含む。
【0140】データアドレスを含むセグメントでの第1
のパケットは、完全なデータアドレス(他の決定因が使
われることもできるが、この場合には、エクスツチル(e
xtutil)RTLソースファイルにあるext_a_幅パラメータ
によって指定されるサイズ)を使用する。これらの完全
なアドレスの記録により、後続する部分アドレスは、現
在セグメント以前のアドレスを参考しない。このSEGSTA
RTパケットは、少なくとも4つのゼロニブルだけ先行す
ることによって、外部キャプチャーデバイスやトレース
デコーダにより一つのトレースで容易に位置することが
できる。
のパケットは、完全なデータアドレス(他の決定因が使
われることもできるが、この場合には、エクスツチル(e
xtutil)RTLソースファイルにあるext_a_幅パラメータ
によって指定されるサイズ)を使用する。これらの完全
なアドレスの記録により、後続する部分アドレスは、現
在セグメント以前のアドレスを参考しない。このSEGSTA
RTパケットは、少なくとも4つのゼロニブルだけ先行す
ることによって、外部キャプチャーデバイスやトレース
デコーダにより一つのトレースで容易に位置することが
できる。
【0141】SEGSTARTは、次のような条件では、RTTに
より生成される:(i)セグメントでユーザーが指定した限
界に到達される(RTT_SEG_CTL。SEGMAX);(ii)バッファ
オーバーフローが消去される;(iii)それが選択的な外部
入力信号(rtt_new_seg)によって要求される;(iv)それ
がCMD_NS命令RTT_CMDレジスタに記録することによっ
て要求される;(v)RTTはトリガーされる;(vi)RTTは非イ
ネーブルになる;(vii)命令トレースが始まる;(viii)RTT
はイネーブルとなり、命令トレースが開始またはフィル
タによって一時的に非イネーブルになった後、イネーブ
ルになる;または(ix)RTTはイネーブルとなり、命令トレ
ースもイネーブルとなること。
より生成される:(i)セグメントでユーザーが指定した限
界に到達される(RTT_SEG_CTL。SEGMAX);(ii)バッファ
オーバーフローが消去される;(iii)それが選択的な外部
入力信号(rtt_new_seg)によって要求される;(iv)それ
がCMD_NS命令RTT_CMDレジスタに記録することによっ
て要求される;(v)RTTはトリガーされる;(vi)RTTは非イ
ネーブルになる;(vii)命令トレースが始まる;(viii)RTT
はイネーブルとなり、命令トレースが開始またはフィル
タによって一時的に非イネーブルになった後、イネーブ
ルになる;または(ix)RTTはイネーブルとなり、命令トレ
ースもイネーブルとなること。
【0142】本実施形態において、あらゆる場合(RTTの
非イネーブル時には除外)に対して生成されるSEGSTART
は、遅延スロットに位置した命令により始まることがで
きない。セグメントの開始は、遅延スロットにない第1
の命令が実行されるか、命令がインターラプトされる時
まで遅延される。RTT702が非イネーブルになる時に
生成されるSEGSTARTは、遅延スロットに関して何らの制
約を有しない。
非イネーブル時には除外)に対して生成されるSEGSTART
は、遅延スロットに位置した命令により始まることがで
きない。セグメントの開始は、遅延スロットにない第1
の命令が実行されるか、命令がインターラプトされる時
まで遅延される。RTT702が非イネーブルになる時に
生成されるSEGSTARTは、遅延スロットに関して何らの制
約を有しない。
【0143】格納デバイスは、一般的に、トレースサイ
ズがその格納容量サイズを超過する場合、既存のトレー
ス情報を廃棄する。格納デバイスは、セグメント境界を
認知せず、トレースの開始を廃棄する。これは、メモリ
内の最も古くなったセグメントが通常自分のSEGSTARTパ
ケットを逃し(missing)、デコードされることができな
いことを意味する。ユーザーは、セグメントが非イネー
ブルなトレースのサイズを制限する程に十分に小さくな
るように、RTTを構成する。しかし、セグメント境界が
決定され考慮されるシステムも、本発明と合わせて具現
されることが出来ることはもちろんである。
ズがその格納容量サイズを超過する場合、既存のトレー
ス情報を廃棄する。格納デバイスは、セグメント境界を
認知せず、トレースの開始を廃棄する。これは、メモリ
内の最も古くなったセグメントが通常自分のSEGSTARTパ
ケットを逃し(missing)、デコードされることができな
いことを意味する。ユーザーは、セグメントが非イネー
ブルなトレースのサイズを制限する程に十分に小さくな
るように、RTTを構成する。しかし、セグメント境界が
決定され考慮されるシステムも、本発明と合わせて具現
されることが出来ることはもちろんである。
【0144】また、本実施形態のRTTは、15-ビットセ
グメント命令オフセットカウンタを含むが、このカウン
タは、新しいセグメントが始まり、命令が実行される時
ごとに増加される時、ゼロにリセットされる。カウンタ
は、命令オフセットをセグメントで生成するために使わ
れ、命令トレース及び/またはデータトレースがイネー
ブルになる途中に、セグメントにより担当になる実行命
令の最大数を制限するために使われる。
グメント命令オフセットカウンタを含むが、このカウン
タは、新しいセグメントが始まり、命令が実行される時
ごとに増加される時、ゼロにリセットされる。カウンタ
は、命令オフセットをセグメントで生成するために使わ
れ、命令トレース及び/またはデータトレースがイネー
ブルになる途中に、セグメントにより担当になる実行命
令の最大数を制限するために使われる。
【0145】図7の実施形態のパケットポートプロトコ
ルを詳細に説明する。
ルを詳細に説明する。
【0146】前述したように、パケットポート709
は、パケットバッファ712を排出させるために使われ
る。パケットポート709の帯域幅は、バッファがほと
んどオーバーフローしない程度に十分に大きくしなけれ
ばならない。バッファがオーバーフローされる時、パケ
ットキャプチャーは、バッファが特定数の自由ニブル
(ゼロでもよい)に排出するように許容される途中に一時
遅延される。新しいセグメントは、パケットキャプチャ
ーが再開する前に始まる。ユーザーは、オーバーフロー
がコアへのインターラプトを発生させるか否かを制御す
る。ユーザーは、CMD_CB命令をRTT_CMDレジスタに記
録することによって、バッファを消去させることができ
る。
は、パケットバッファ712を排出させるために使われ
る。パケットポート709の帯域幅は、バッファがほと
んどオーバーフローしない程度に十分に大きくしなけれ
ばならない。バッファがオーバーフローされる時、パケ
ットキャプチャーは、バッファが特定数の自由ニブル
(ゼロでもよい)に排出するように許容される途中に一時
遅延される。新しいセグメントは、パケットキャプチャ
ーが再開する前に始まる。ユーザーは、オーバーフロー
がコアへのインターラプトを発生させるか否かを制御す
る。ユーザーは、CMD_CB命令をRTT_CMDレジスタに記
録することによって、バッファを消去させることができ
る。
【0147】本実施形態に対するパケットポート幅は、
32ビットである。しかし、4、8、及び16または他
のビット数のパケットポート幅が使われることができ
る。設計者は、帯域幅及びピンカウント値の考慮に基づ
いて適切なビット数を選択する。パケットデータは、RT
T出力信号のrtt_pkt_dataに伝送される。この信号
は、サイズにおいて32ビットであるが、ポート幅が3
2ビットより小さい場合、あらゆるビットが使われる。
この実施形態に使われないビットは、最上位ビットであ
る。
32ビットである。しかし、4、8、及び16または他
のビット数のパケットポート幅が使われることができ
る。設計者は、帯域幅及びピンカウント値の考慮に基づ
いて適切なビット数を選択する。パケットデータは、RT
T出力信号のrtt_pkt_dataに伝送される。この信号
は、サイズにおいて32ビットであるが、ポート幅が3
2ビットより小さい場合、あらゆるビットが使われる。
この実施形態に使われないビットは、最上位ビットであ
る。
【0148】本実施形態のパケットポートプロトコル
は、パケット内部において所定数“X”(たとえば4)ま
たはそれ以上の連続的なゼロニブルシーケンスが決して
存在しないように設計される。仮にトレースデコーダが
4またはそれ以上の連続的なゼロニブルを発見すれば、
それは、その次の非−ゼロニブルが新しいパケットの開
始であることを知ることになる。たとえパケット境界が
知られていないとしても、SEGSTARTパケットの開始が検
出されるように許容するために、SEGSTARTパケットは、
少なくとも4つのゼロニブルを前に付ける(prefix)。
は、パケット内部において所定数“X”(たとえば4)ま
たはそれ以上の連続的なゼロニブルシーケンスが決して
存在しないように設計される。仮にトレースデコーダが
4またはそれ以上の連続的なゼロニブルを発見すれば、
それは、その次の非−ゼロニブルが新しいパケットの開
始であることを知ることになる。たとえパケット境界が
知られていないとしても、SEGSTARTパケットの開始が検
出されるように許容するために、SEGSTARTパケットは、
少なくとも4つのゼロニブルを前に付ける(prefix)。
【0149】4またはそれ以上の連続的なゼロニブルシ
ーケンスがパケット内に現れることを防止するために、
本明細書で前述したようないわゆる“ニブルスタッフィ
ング(nibble stuffing) ”が行われる。特に、3つの連
続的なゼロニブルがパケット内に存在する時ごとに、RT
Tは、3つのゼロ以後にひとつまたはそれ以上のニブル
を追加する。追加される最後のニブルは、0xfの値を
有し、その前に追加される任意の他のニブルは、0x8
の値を有する。トレース格納デバイスは、詰まったニブ
ルを除去せず、むしろトレースデコーダプログラムがそ
れらを除去する。
ーケンスがパケット内に現れることを防止するために、
本明細書で前述したようないわゆる“ニブルスタッフィ
ング(nibble stuffing) ”が行われる。特に、3つの連
続的なゼロニブルがパケット内に存在する時ごとに、RT
Tは、3つのゼロ以後にひとつまたはそれ以上のニブル
を追加する。追加される最後のニブルは、0xfの値を
有し、その前に追加される任意の他のニブルは、0x8
の値を有する。トレース格納デバイスは、詰まったニブ
ルを除去せず、むしろトレースデコーダプログラムがそ
れらを除去する。
【0150】本実施形態のパケットポート772は、rt
t_pkt_holdと呼ばれるポート停止入力信号を支援す
る。この信号がハイ(high)である限り、RTT702は、
パケットポート709上で新しい値を駆動することが出
来ない。また、パケットポートは、rtt_pkt_startと
呼ばれるそれぞれのニブルに対するパケット信号の開始
を含む。これら信号は、それらの対応するニブルがパケ
ットにある第1のニブルである時にアサートされる。こ
のようなポート信号の開始は、典型的にパケットポート
ピンカウントでの追加的な諸費用(たとえば25%)によ
ってチップ外に運搬されない。代りに、それらは、いろ
いろなRTTからパケット境界を容易に検出するために、M
ATI(図22に関連して後述する)により使われる。
t_pkt_holdと呼ばれるポート停止入力信号を支援す
る。この信号がハイ(high)である限り、RTT702は、
パケットポート709上で新しい値を駆動することが出
来ない。また、パケットポートは、rtt_pkt_startと
呼ばれるそれぞれのニブルに対するパケット信号の開始
を含む。これら信号は、それらの対応するニブルがパケ
ットにある第1のニブルである時にアサートされる。こ
のようなポート信号の開始は、典型的にパケットポート
ピンカウントでの追加的な諸費用(たとえば25%)によ
ってチップ外に運搬されない。代りに、それらは、いろ
いろなRTTからパケット境界を容易に検出するために、M
ATI(図22に関連して後述する)により使われる。
【0151】表4及び表5は、本実施形態に使われるパ
ケット形態に対する例示的なパケット形態コードを提供
する。
ケット形態に対する例示的なパケット形態コードを提供
する。
【0152】
【表4】
【0153】
【表5】
【0154】付録IIは、このようなパケット上に追加的
な詳細事項(detail)を提供する。付録IIに対して、完全
な命令アドレスは、24-ビット長さ-ワードアドレスで
ある。フルデータアドレスのサイズは、ext_utilRTLソ
ースファイル(最小32ビットである)でext_a_width
パラメータにより指定される。データアドレスは、バイ
トアドレスである。共通スキームは、パケットにおいて
次のサイズのフィールドが存在する場合を表すために、
ビットを使用することである。もし存在しないならば、
サイズは、サイズ形態によるデフォルト値である。デフ
ォルト命令アドレスのサイズは、2ニブルであり、デフ
ォルトデータアドレスのサイズは、1ニブルであり、デ
フォルトデータ値のサイズは、1ニブルである。次のサ
イズフィールド以後にパケットに位置するサイズフィー
ルドは、一部パケット(たとえば、DATAパケットに対す
るデータアドレスのサイズ)に対するユーザーセットに
依存することができる。この場合、その次のサイズフィ
ールド存在フラッグは、どんなサイズフィールドがその
次であるかを表す。或る場合には、他のサイズフィール
ドが全く存在しないこともあり、フラッグが無視されな
ければならない。サイズは、一般的に1より少ないニブ
ルの数としてエンコードされる。これは、3-ビットサ
イズフィールドが1ないし8ニブルのサイズを指定する
ように許容する。DATAパケットは、セグメント命令オフ
セットフィールドを含むことができる。このフィールド
は、最大15-ビットセグメント命令オフセット値また
は現在の命令セグメントオフセットと最後にエンコード
されたセグメント命令オフセット間の3-ビット差異(常
に正)のいずれか一方としてエンコードされる。パケッ
ト内の1-ビットフラッグは、どんなエンコーディング
方法が使われたかを指定する(1は、3-ビット値と同一
であり、0は、15-ビット値と同一である)。SEGSTART
パケットの生成は、セグメント命令オフセットをゼロに
セットする。SRSPECパケットは、セグメント命令オフセ
ットフィールドを含む。それは、完全な15-ビット値
としてエンコードされる。
な詳細事項(detail)を提供する。付録IIに対して、完全
な命令アドレスは、24-ビット長さ-ワードアドレスで
ある。フルデータアドレスのサイズは、ext_utilRTLソ
ースファイル(最小32ビットである)でext_a_width
パラメータにより指定される。データアドレスは、バイ
トアドレスである。共通スキームは、パケットにおいて
次のサイズのフィールドが存在する場合を表すために、
ビットを使用することである。もし存在しないならば、
サイズは、サイズ形態によるデフォルト値である。デフ
ォルト命令アドレスのサイズは、2ニブルであり、デフ
ォルトデータアドレスのサイズは、1ニブルであり、デ
フォルトデータ値のサイズは、1ニブルである。次のサ
イズフィールド以後にパケットに位置するサイズフィー
ルドは、一部パケット(たとえば、DATAパケットに対す
るデータアドレスのサイズ)に対するユーザーセットに
依存することができる。この場合、その次のサイズフィ
ールド存在フラッグは、どんなサイズフィールドがその
次であるかを表す。或る場合には、他のサイズフィール
ドが全く存在しないこともあり、フラッグが無視されな
ければならない。サイズは、一般的に1より少ないニブ
ルの数としてエンコードされる。これは、3-ビットサ
イズフィールドが1ないし8ニブルのサイズを指定する
ように許容する。DATAパケットは、セグメント命令オフ
セットフィールドを含むことができる。このフィールド
は、最大15-ビットセグメント命令オフセット値また
は現在の命令セグメントオフセットと最後にエンコード
されたセグメント命令オフセット間の3-ビット差異(常
に正)のいずれか一方としてエンコードされる。パケッ
ト内の1-ビットフラッグは、どんなエンコーディング
方法が使われたかを指定する(1は、3-ビット値と同一
であり、0は、15-ビット値と同一である)。SEGSTART
パケットの生成は、セグメント命令オフセットをゼロに
セットする。SRSPECパケットは、セグメント命令オフセ
ットフィールドを含む。それは、完全な15-ビット値
としてエンコードされる。
【0155】前述したように、図7の実施形態のRTTに
よってキャプチャーされるトレースイベントの4形態が
次のように存在する:1)命令トレース、2)データトレ
ース、3)イベントトレース、及び4)タイミングトレー
ス。
よってキャプチャーされるトレースイベントの4形態が
次のように存在する:1)命令トレース、2)データトレ
ース、3)イベントトレース、及び4)タイミングトレー
ス。
【0156】同期的な命令トレースに関して、本実施形
態は、条件付き命令がその命令内に“Q”フィールドを
有することを利用するが、このフィールドは、“alway
s”(0x00)を除外した任意の値にセットされる。無条
件の命令は、その命令内にQフィールドを有しないか、
選択的にQフィールドを有するが、“always”に対する
値にセットされる。拡張命令は、このような命令が条件
的でないことをコアパイプラインに知らせるために、ス
テージ3で命令の最下位5ビット、すなわちxshimm信号
の非−標準コーディングを使用する。RTTは、xshimm信
号を無視することによって、あらゆる拡張命令がQフィ
ールドを有するものと見なす(それらが短い近接データ
を使用しない場合)。
態は、条件付き命令がその命令内に“Q”フィールドを
有することを利用するが、このフィールドは、“alway
s”(0x00)を除外した任意の値にセットされる。無条
件の命令は、その命令内にQフィールドを有しないか、
選択的にQフィールドを有するが、“always”に対する
値にセットされる。拡張命令は、このような命令が条件
的でないことをコアパイプラインに知らせるために、ス
テージ3で命令の最下位5ビット、すなわちxshimm信号
の非−標準コーディングを使用する。RTTは、xshimm信
号を無視することによって、あらゆる拡張命令がQフィ
ールドを有するものと見なす(それらが短い近接データ
を使用しない場合)。
【0157】ハイ及びローの2つの同期命令圧縮モード
が存在する。RTT_PKT_CTLレジスタのLCMビットは、ど
んなモードが活性化されるかを制御する。これら2つの
圧縮モードは、一般的に図1の実施形態に関して本明細
書で前述した最大/最小モードと類似している(図5a及
び図5bに関する論議を参照)。
が存在する。RTT_PKT_CTLレジスタのLCMビットは、ど
んなモードが活性化されるかを制御する。これら2つの
圧縮モードは、一般的に図1の実施形態に関して本明細
書で前述した最大/最小モードと類似している(図5a及
び図5bに関する論議を参照)。
【0158】図1の実施形態と同様に、仮に高い-圧縮
エンコードが後方向条件付き分岐命令のために選択され
れば、図7の実施形態において、RTT_PKT_CTLレジス
タのUPCビットは、追加的に2種類のエンコード方法の
一方(すなわち、PFパケットまたはBCBPCパケットに記録
されるマルチビットカウンタ)を選択する。図1の実施
形態と同様に、カウンタ方法は、PFパケットを使用する
ことより、顕著に良好な圧縮を提供する。本実施形態に
おいて、カウンタは、IA、PF、DATA、SRSPEC、LPPC、LP
PCOV、LPTRIG、またはSTALLパケットが生成された後、
ゼロにセットされる。もしカウンタがオーバーフローさ
れれば、BCBPCOVパケットが生成される。
エンコードが後方向条件付き分岐命令のために選択され
れば、図7の実施形態において、RTT_PKT_CTLレジス
タのUPCビットは、追加的に2種類のエンコード方法の
一方(すなわち、PFパケットまたはBCBPCパケットに記録
されるマルチビットカウンタ)を選択する。図1の実施
形態と同様に、カウンタ方法は、PFパケットを使用する
ことより、顕著に良好な圧縮を提供する。本実施形態に
おいて、カウンタは、IA、PF、DATA、SRSPEC、LPPC、LP
PCOV、LPTRIG、またはSTALLパケットが生成された後、
ゼロにセットされる。もしカウンタがオーバーフローさ
れれば、BCBPCOVパケットが生成される。
【0159】仮にカウンタがゼロではなく且つセグメン
トが終了すれば、カウンタ値は、その次のSEGSTARTパケ
ットに記録され、ゼロにリセットされる。もしINTパケ
ットがインターラプトを記録するために生成されれば、
カウンタ値は、INTパケットに記録され、ゼロにリセッ
トされる。
トが終了すれば、カウンタ値は、その次のSEGSTARTパケ
ットに記録され、ゼロにリセットされる。もしINTパケ
ットがインターラプトを記録するために生成されれば、
カウンタ値は、INTパケットに記録され、ゼロにリセッ
トされる。
【0160】本実施形態において、PC+4がゼロオーバ
ーヘッドループ(LP_END)で最後の命令に至った時、ル
ープメカニズムはトリガーされる。仮にループでの最後
の命令が、使用された分岐やジャンプ命令ならば、ルー
プメカニズムによるPCのローディングは、分岐またはジ
ャンプに対する遅延スロット命令の選択にのみ影響を与
え、PCは、使用された分岐またはジャンプ命令のターゲ
ットにセットされる。
ーヘッドループ(LP_END)で最後の命令に至った時、ル
ープメカニズムはトリガーされる。仮にループでの最後
の命令が、使用された分岐やジャンプ命令ならば、ルー
プメカニズムによるPCのローディングは、分岐またはジ
ャンプに対する遅延スロット命令の選択にのみ影響を与
え、PCは、使用された分岐またはジャンプ命令のターゲ
ットにセットされる。
【0161】もしループがフェイルすれば、カウンタ値
を記録するLPPCパケットが生成され、カウンタは、ゼロ
にセットされる。また、カウンタは、IA、PF、DATA、SR
SPEC、BCBPC、BCBPCOV、LPTRIG、またはSTALLパケット
が生成された後、ゼロにセットされる。もしカウンタが
オーバーフローされれば、LPPCOVパケットが生成され
る。
を記録するLPPCパケットが生成され、カウンタは、ゼロ
にセットされる。また、カウンタは、IA、PF、DATA、SR
SPEC、BCBPC、BCBPCOV、LPTRIG、またはSTALLパケット
が生成された後、ゼロにセットされる。もしカウンタが
オーバーフローされれば、LPPCOVパケットが生成され
る。
【0162】トレースデコーダは、LP_START及びLP_E
NDの値が現在セグメントにループ命令やSR命令によって
記録されたならば、それらの値を知っている。仮にトレ
ースデコーダがLP_START及びLP_ENDの値を知らず、ゼ
ロオーバーヘッドループが使われれば、RTTは、それら
の値を記録するためにLPTRIGパケットを生成する。
NDの値が現在セグメントにループ命令やSR命令によって
記録されたならば、それらの値を知っている。仮にトレ
ースデコーダがLP_START及びLP_ENDの値を知らず、ゼ
ロオーバーヘッドループが使われれば、RTTは、それら
の値を記録するためにLPTRIGパケットを生成する。
【0163】図7の実施形態において、仮にインターラ
プト以後に実行される第1の命令やセグメント内の第1
の命令が無条件のジャンプならば、第1の命令は、IAパ
ケットを使用して記録される。これは、コンパイルされ
たソースコードがインターラプトベクター表(すなわち
自己−変更コード)で命令を含まない場合、デコーダを
援助するために行われる。デコーダは、テーブルで実行
される第1の命令がインターラプト調整機への無条件の
直接ジャンプであると仮定するが、インターラプト調整
機は、コンパイルされたソースコードに位置する。もし
プログラムがこのような規則に従わないならば、それ
は、コンパイルされたソースコードにインターラプトベ
クター表を提供すべきである。
プト以後に実行される第1の命令やセグメント内の第1
の命令が無条件のジャンプならば、第1の命令は、IAパ
ケットを使用して記録される。これは、コンパイルされ
たソースコードがインターラプトベクター表(すなわち
自己−変更コード)で命令を含まない場合、デコーダを
援助するために行われる。デコーダは、テーブルで実行
される第1の命令がインターラプト調整機への無条件の
直接ジャンプであると仮定するが、インターラプト調整
機は、コンパイルされたソースコードに位置する。もし
プログラムがこのような規則に従わないならば、それ
は、コンパイルされたソースコードにインターラプトベ
クター表を提供すべきである。
【0164】デートトレースに関して、メモリロード命
令(LDB、LDW、LD)が実行される時には、DATAパケット
がデータアドレスを記録するために生成される(データ
アドレスキャプチャーがイネーブルになった場合)。遅
延されたロードデータがレジスタファイルに再び記録さ
れる時には、DLDDパケットがデータ値を記録するために
生成される(データ値キャプチャーがイネーブルになる
場合)。
令(LDB、LDW、LD)が実行される時には、DATAパケット
がデータアドレスを記録するために生成される(データ
アドレスキャプチャーがイネーブルになった場合)。遅
延されたロードデータがレジスタファイルに再び記録さ
れる時には、DLDDパケットがデータ値を記録するために
生成される(データ値キャプチャーがイネーブルになる
場合)。
【0165】補助レジスタロード命令(LR)やメモリ格納
命令(STB、STW、ST)が実行される時には、DATAパケッ
トは、データアドレスとデータ値を潜在的に記録するた
めに生成される。
命令(STB、STW、ST)が実行される時には、DATAパケッ
トは、データアドレスとデータ値を潜在的に記録するた
めに生成される。
【0166】補助レジスタ格納命令(SR)が実行されれ
ば、RTTは、パケット形態を決定するためにアドレスを
確認する。仮にアドレスが特定のレジスタに対するもの
ならば、SRSPECパケットが生成され、そうでなければ、
SRがST命令のように処理される。特定レジスタは、RTT
_USER、RTT_PKT_CTL、LPSTART及びLPENDである。RTT
_USERまたはRTT_PKT_CTLレジスタへのSRは、静的及
びダイナミックなイネーブルに関わらずSRSPECパケット
を生成する。LPSTARTまたはLPENDレジスタへのSRは、命
令トレースがイネーブルになる場合、SRSPECパケットを
生成する。
ば、RTTは、パケット形態を決定するためにアドレスを
確認する。仮にアドレスが特定のレジスタに対するもの
ならば、SRSPECパケットが生成され、そうでなければ、
SRがST命令のように処理される。特定レジスタは、RTT
_USER、RTT_PKT_CTL、LPSTART及びLPENDである。RTT
_USERまたはRTT_PKT_CTLレジスタへのSRは、静的及
びダイナミックなイネーブルに関わらずSRSPECパケット
を生成する。LPSTARTまたはLPENDレジスタへのSRは、命
令トレースがイネーブルになる場合、SRSPECパケットを
生成する。
【0167】仮にデータフィルタリングが使われている
ならば、ロード/格納の一部だけが記録されることがで
きる。特に、データトレースに影響を与えるようにセッ
トされた動作を有する、少なくとも一つのイネーブルな
フィルタが存在すれば、トレースデコーダは、たとえ命
令トレースがイネーブルになるとしても、キャプチャー
されたロード/格納のPCを決定することが出来ない。も
しデータフィルタリングが活性化されれば、ユーザー
は、DATAパケットにセグメント命令オフセットを追加す
るようにRTTを構成する。
ならば、ロード/格納の一部だけが記録されることがで
きる。特に、データトレースに影響を与えるようにセッ
トされた動作を有する、少なくとも一つのイネーブルな
フィルタが存在すれば、トレースデコーダは、たとえ命
令トレースがイネーブルになるとしても、キャプチャー
されたロード/格納のPCを決定することが出来ない。も
しデータフィルタリングが活性化されれば、ユーザー
は、DATAパケットにセグメント命令オフセットを追加す
るようにRTTを構成する。
【0168】イベントトレースは、命令実行に関連がな
いコア状態の変化を記録する。
いコア状態の変化を記録する。
【0169】本実施形態において、タイミングトレース
は、(a)命令タイミングトレースと、(b)イベントタイミ
ングトレースとで構成される。命令タイミングトレース
により、トレースデコーダは、それぞれの実行される命
令が退去された周期(コアパイプラインの終端に達した
周期)と、遅延されたロード-データに対するレジスタフ
ァイルへの記録周期を決定できることになる。イベント
タイミングトレースにより、トレースデコーダは、命令
実行に非同期的なイベントが発生した周期を決定できる
ことになる。このような非同期的なイベントには、(1)
アクションポイントトリガー、(2)外部信号変化、(3)
取ったインターラプト、及び(4)新しいセグメントがあ
る。命令タイミング及びイベントタイミングは、個別的
にRTT_PKT_CTLレジスタで静的にイネーブルになり得
る。また、命令タイミングは、モニター設備からのダイ
ナミックなイネーブルにより制御される。
は、(a)命令タイミングトレースと、(b)イベントタイミ
ングトレースとで構成される。命令タイミングトレース
により、トレースデコーダは、それぞれの実行される命
令が退去された周期(コアパイプラインの終端に達した
周期)と、遅延されたロード-データに対するレジスタフ
ァイルへの記録周期を決定できることになる。イベント
タイミングトレースにより、トレースデコーダは、命令
実行に非同期的なイベントが発生した周期を決定できる
ことになる。このような非同期的なイベントには、(1)
アクションポイントトリガー、(2)外部信号変化、(3)
取ったインターラプト、及び(4)新しいセグメントがあ
る。命令タイミング及びイベントタイミングは、個別的
にRTT_PKT_CTLレジスタで静的にイネーブルになり得
る。また、命令タイミングは、モニター設備からのダイ
ナミックなイネーブルにより制御される。
【0170】RTTは、次のような2種類メカニズムによ
るタイミングトレースを支援する:タイムスタンプ及び
タイミングパケット。命令タイミングトレースは、二つ
のメカニズムをいずれも使用するが、イベントタイミン
グトレースは、タイムスタンプメカニズムだけを使用す
る。
るタイミングトレースを支援する:タイムスタンプ及び
タイミングパケット。命令タイミングトレースは、二つ
のメカニズムをいずれも使用するが、イベントタイミン
グトレースは、タイムスタンプメカニズムだけを使用す
る。
【0171】(i)タイムスタンプ-命令タイミングが静的
にイネーブルになる時やイベントタイミングが静的にイ
ネーブルになる時、タイムスタンピングメカニズムは、
イネーブルになる。タイムスタンピングがイネーブルに
なった時には、15-ビットタイムスタンプレジスタが
消去される。タイムスタンプは、タイムスタンピングが
イネーブルになる周期毎に増加する。タイムスタンピン
グがイネーブルになる場合、タイムスタンプは、APE、E
XTSIG、INT、SEGSTART及びSRSPE C RTT_PKT_CTLパケ
ットに格納される。タイムスタンプがオーバーフローさ
れる時には、タイムスタンプを含むパケットがそのよう
な同一周期で生成されない限り、TSOVパケットが生成さ
れる。後者の場合、タイスタンプを含むパケットは、タ
イムスタンプ-オーバーフローされたビットを含むが、
ビットは、1にセットされる。
にイネーブルになる時やイベントタイミングが静的にイ
ネーブルになる時、タイムスタンピングメカニズムは、
イネーブルになる。タイムスタンピングがイネーブルに
なった時には、15-ビットタイムスタンプレジスタが
消去される。タイムスタンプは、タイムスタンピングが
イネーブルになる周期毎に増加する。タイムスタンピン
グがイネーブルになる場合、タイムスタンプは、APE、E
XTSIG、INT、SEGSTART及びSRSPE C RTT_PKT_CTLパケ
ットに格納される。タイムスタンプがオーバーフローさ
れる時には、タイムスタンプを含むパケットがそのよう
な同一周期で生成されない限り、TSOVパケットが生成さ
れる。後者の場合、タイスタンプを含むパケットは、タ
イムスタンプ-オーバーフローされたビットを含むが、
ビットは、1にセットされる。
【0172】(ii)タイミングパケット-命令タイミング
トレース及び命令トレースがイネーブルになった時(二
つのトレースは、静的に且つダイナミックにイネーブル
される)、RTTは、4-ビットストール周期カウンタを用
いて退去された命令間のストール周期をカウントする。
RTTは、ストール周期カウンタがオーバーフローされる
時、すなわち命令タイミングトレースがディセイブル(d
isable)され、カウンタがフラッシュされる必要がある
場合、その次の退去された命令が到着する前の周期にス
トール周期カウンタ値を含むSTALLパケットを出力す
る。STALLパケットの生成は、INTまたはSEGSTARTパケッ
トがハードウェアの費用を減少させるために同一の周期
に生成される場合、防止される。ストール周期カウンタ
値は、失われるが、INT及びSEGSTARTパケットにあるタ
イムスタンプ値は、等価の情報を提供する。
トレース及び命令トレースがイネーブルになった時(二
つのトレースは、静的に且つダイナミックにイネーブル
される)、RTTは、4-ビットストール周期カウンタを用
いて退去された命令間のストール周期をカウントする。
RTTは、ストール周期カウンタがオーバーフローされる
時、すなわち命令タイミングトレースがディセイブル(d
isable)され、カウンタがフラッシュされる必要がある
場合、その次の退去された命令が到着する前の周期にス
トール周期カウンタ値を含むSTALLパケットを出力す
る。STALLパケットの生成は、INTまたはSEGSTARTパケッ
トがハードウェアの費用を減少させるために同一の周期
に生成される場合、防止される。ストール周期カウンタ
値は、失われるが、INT及びSEGSTARTパケットにあるタ
イムスタンプ値は、等価の情報を提供する。
【0173】本実施形態のSTALLパケットは、4-ビット
のストールカウントを含むように構成され、トレースデ
コーダが、PC(すなわち、INT、DATA、PF、IA、BCBPC、B
CBPCOV、LPPC、LPPCOV、SRSPEC、SEGSTART、LPTRIG及び
STALL)を決定することを許容し、それぞれの退去された
命令に対して増加する最後のパケットが生成されたた
め、選択的に4-ビットのストール理由を含む。停止命
令カウントは、退去された命令の数である。このフィー
ルドによりストールを実行させる正確な命令は、たとえ
退去されたあらゆる命令がパケットを生成しないとして
も、決定できることになる。停止命令カウンタにより、
トレースデコーダは、PCを決定でき、任意のパケットが
生成された後には、ゼロにリセットされる。SICOVパケ
ットは、命令カウンタがオーバーフローされるたびに生
成される。
のストールカウントを含むように構成され、トレースデ
コーダが、PC(すなわち、INT、DATA、PF、IA、BCBPC、B
CBPCOV、LPPC、LPPCOV、SRSPEC、SEGSTART、LPTRIG及び
STALL)を決定することを許容し、それぞれの退去された
命令に対して増加する最後のパケットが生成されたた
め、選択的に4-ビットのストール理由を含む。停止命
令カウントは、退去された命令の数である。このフィー
ルドによりストールを実行させる正確な命令は、たとえ
退去されたあらゆる命令がパケットを生成しないとして
も、決定できることになる。停止命令カウンタにより、
トレースデコーダは、PCを決定でき、任意のパケットが
生成された後には、ゼロにリセットされる。SICOVパケ
ットは、命令カウンタがオーバーフローされるたびに生
成される。
【0174】ストールを引き起こすことができる多くの
事件が存在するが、これは、(a) ベチ遅延(たとえば、I
-キャッシュ損失);(b)ロード使用;(c)ロードリターン
(たとえば、3つのポートレジスタファイルのみを使
用);(d)ロード/格納待機行列充満;(e)多重周期命令;(f)
依存性(たとえば、非短縮レジスタ、条件付きジャンプ/
分岐が後続するPELLEKEセット等);(g)インターラプト;
(h)長い-近接データ;(i)死んだ(killed)遅延-スロット
命令;(j)xholdup12またはxholdup123信号を用いた
拡張命令停止;(k)ブレーキ命令又はアクションポイント
トリガー;または(l)単一-段階または命令-段階モードで
のプロセッサを含む。命令がコアパイプラインに移動す
る時、命令は、いろいろなストール理由に出会う。それ
ぞれの命令に対するストールカウント及びストール理由
の完璧な履歴(history)を記録することは、たびたび非
常に大きい。本実施形態の4-ビットストール理由フィ
ールドは、次のような可能なストール理由をキャプチャ
ーする;(a) ベチストール(無効=0);(b)ロード-使用ス
トール;(c)ロード-リターンストール;及び(d)ロード/格
納行列フルストール(メモリコントローラーが使用中、
またはスコアボード充満)。仮に命令がそのストールを
実行させたら、それぞれの理由には、1にセットされる
限り、1ビットが割り当てられる。もし命令がストール
されたが、このような理由中のいかなる理由にも該当し
ないならば、ストール理由フィールドは、ゼロになる。
事件が存在するが、これは、(a) ベチ遅延(たとえば、I
-キャッシュ損失);(b)ロード使用;(c)ロードリターン
(たとえば、3つのポートレジスタファイルのみを使
用);(d)ロード/格納待機行列充満;(e)多重周期命令;(f)
依存性(たとえば、非短縮レジスタ、条件付きジャンプ/
分岐が後続するPELLEKEセット等);(g)インターラプト;
(h)長い-近接データ;(i)死んだ(killed)遅延-スロット
命令;(j)xholdup12またはxholdup123信号を用いた
拡張命令停止;(k)ブレーキ命令又はアクションポイント
トリガー;または(l)単一-段階または命令-段階モードで
のプロセッサを含む。命令がコアパイプラインに移動す
る時、命令は、いろいろなストール理由に出会う。それ
ぞれの命令に対するストールカウント及びストール理由
の完璧な履歴(history)を記録することは、たびたび非
常に大きい。本実施形態の4-ビットストール理由フィ
ールドは、次のような可能なストール理由をキャプチャ
ーする;(a) ベチストール(無効=0);(b)ロード-使用ス
トール;(c)ロード-リターンストール;及び(d)ロード/格
納行列フルストール(メモリコントローラーが使用中、
またはスコアボード充満)。仮に命令がそのストールを
実行させたら、それぞれの理由には、1にセットされる
限り、1ビットが割り当てられる。もし命令がストール
されたが、このような理由中のいかなる理由にも該当し
ないならば、ストール理由フィールドは、ゼロになる。
【0175】前述した4つのストール理由は、それらが
ストールを減少させるための解決策を提示するので、選
択された。特に、ベチストールに対しては、I-キャッシ
ュサイズを増加させる。ロード-使用ストールに対して
は、D-キャッシュサイズを増加させたり、ロードと使用
との間に命令を追加させる。ロード-リターン停止に対
しては、4-ポートレジスタファイルを使用する。ロー
ド/格納待機行列フルストールに対しては、メモリ帯域
幅を増加させる。しかし、他のストールパラメータとビ
ット数が本発明と合わせて使われることができ、前述し
たスキームは、ただ例示的なものに過ぎないことが分か
るだろう。
ストールを減少させるための解決策を提示するので、選
択された。特に、ベチストールに対しては、I-キャッシ
ュサイズを増加させる。ロード-使用ストールに対して
は、D-キャッシュサイズを増加させたり、ロードと使用
との間に命令を追加させる。ロード-リターン停止に対
しては、4-ポートレジスタファイルを使用する。ロー
ド/格納待機行列フルストールに対しては、メモリ帯域
幅を増加させる。しかし、他のストールパラメータとビ
ット数が本発明と合わせて使われることができ、前述し
たスキームは、ただ例示的なものに過ぎないことが分か
るだろう。
【0176】DLDDパケットは、命令-タイミングトレー
スが静的にイネーブルになる時、ストール命令カウント
値と、ストール周期カウント値とを含む。これら値は、
命令タイミング及び命令タイミングトレースがイネーブ
ルになる時にだけ、意味がある(両者とも静的で且つダ
イナミックである)。DLDDパケットのこのような追加的
な値により、トレースデコーダは、ロードデータに対す
るレジスタファイルへの記録周期を決定できることにな
る。
スが静的にイネーブルになる時、ストール命令カウント
値と、ストール周期カウント値とを含む。これら値は、
命令タイミング及び命令タイミングトレースがイネーブ
ルになる時にだけ、意味がある(両者とも静的で且つダ
イナミックである)。DLDDパケットのこのような追加的
な値により、トレースデコーダは、ロードデータに対す
るレジスタファイルへの記録周期を決定できることにな
る。
【0177】付録IIIは、本発明の実施形態と関連したR
TT拡張補助レジスタを詳細に説明する。
TT拡張補助レジスタを詳細に説明する。
【0178】バッファとパケットパイプラインの説明前
述したバッファユニット712の構成及び動作をより詳
細に説明する。
述したバッファユニット712の構成及び動作をより詳
細に説明する。
【0179】バッファ712の主な目的は、生成ユニッ
ト744から外部キャプチャーデバイス772にパケッ
トを伝送するための能力において、短い期間と中間期間
の融通性を提供することにある。トレースキャプチャー
を行う時、パケットは、特定の命令が会う時にだけ生成
され、その後、モニターは、それを許容する時にだけ生
成される。これは、時間によって生成されるデータの量
に対する非常に非均一なバラツキを発生させることがあ
る。生成ユニットにより同時的に生成され得るデータの
幅は、キャプチャーデバイスポートの幅(最小1ニブル)
と比べて非常に大きい(たとえば、前述した例示的な単
一-コア実施形態では、大体最大70ニブル)。これは、
データストリームを平滑(smooth)にさせるためにバッフ
ァが設置されないならば、オーバーフローが頻繁に発生
できること(これにより、トレース情報を損失させる)
を意味する。
ト744から外部キャプチャーデバイス772にパケッ
トを伝送するための能力において、短い期間と中間期間
の融通性を提供することにある。トレースキャプチャー
を行う時、パケットは、特定の命令が会う時にだけ生成
され、その後、モニターは、それを許容する時にだけ生
成される。これは、時間によって生成されるデータの量
に対する非常に非均一なバラツキを発生させることがあ
る。生成ユニットにより同時的に生成され得るデータの
幅は、キャプチャーデバイスポートの幅(最小1ニブル)
と比べて非常に大きい(たとえば、前述した例示的な単
一-コア実施形態では、大体最大70ニブル)。これは、
データストリームを平滑(smooth)にさせるためにバッフ
ァが設置されないならば、オーバーフローが頻繁に発生
できること(これにより、トレース情報を損失させる)
を意味する。
【0180】例示的な実施形態のバッファ712は、次
のような2部分に分けられる:(i)パケットパイプライ
ン;及び(ii)FIFO。パケットパイプライン部は、レジス
タに基づくもので、生成ユニットからの短い期間のデー
タバストをバッファリングするために使われる。FIFO部
は、RAMに基づくもので、パケットパイプラインからの
中間期間データバスト(burst)をバッファリングする。
のような2部分に分けられる:(i)パケットパイプライ
ン;及び(ii)FIFO。パケットパイプライン部は、レジス
タに基づくもので、生成ユニットからの短い期間のデー
タバストをバッファリングするために使われる。FIFO部
は、RAMに基づくもので、パケットパイプラインからの
中間期間データバスト(burst)をバッファリングする。
【0181】バッファ712は、次のような機能と特徴
を提供する;(i)短時間に生成ユニットからの最大出力を
収容する能力;(ii)長時間にコード部を生成する高い帯
域幅を収容する能力;(iii)ゲートカウント(及びそれに
よるICコスト)とバッファリング能力の交換を許容する
構成能力;及び(iv)変換ツールを用いて説明言語(例え
ば、Verilog)への簡単な転換。
を提供する;(i)短時間に生成ユニットからの最大出力を
収容する能力;(ii)長時間にコード部を生成する高い帯
域幅を収容する能力;(iii)ゲートカウント(及びそれに
よるICコスト)とバッファリング能力の交換を許容する
構成能力;及び(iv)変換ツールを用いて説明言語(例え
ば、Verilog)への簡単な転換。
【0182】バッファ712のパケットパイプライン
は、生成ユニット744からの出力をバッファリング
し、FIFOの幅に出力を効果的に“ファンネルダウン(fun
nel down)”するために使われる。これは、比較的大き
いレジスタアレイを用いて示された実施形態で達成さ
れ、その幅及び深さは、デバイス構成瞬間に構成可能に
作られる。
は、生成ユニット744からの出力をバッファリング
し、FIFOの幅に出力を効果的に“ファンネルダウン(fun
nel down)”するために使われる。これは、比較的大き
いレジスタアレイを用いて示された実施形態で達成さ
れ、その幅及び深さは、デバイス構成瞬間に構成可能に
作られる。
【0183】フルデータとタイミングトレース構成が選
択されることによって、生成ユニット744からの出力
は、図示の実施形態において約70ニブル幅である。こ
のような出力は、次のような4つのパケット形態、すな
わち(1)セグメント開始、(2)命令実行、(3)ループト
リガー、及び(4)遅延されたロードデータに分類され
る。
択されることによって、生成ユニット744からの出力
は、図示の実施形態において約70ニブル幅である。こ
のような出力は、次のような4つのパケット形態、すな
わち(1)セグメント開始、(2)命令実行、(3)ループト
リガー、及び(4)遅延されたロードデータに分類され
る。
【0184】合わせて4個のパケットカテゴリーが1ク
ロック周期で生成されることが(望ましくはないが)可能
である。パケットが生成される時、パケット自体、パケ
ットのサイズ、及び“新しい”フラッグが生成ユニット
744から出力される。仮に一つ以上のパケットが同時
に生成されれば、そのパケットは、指定された順序によ
ってパケットパイプラインに入力される。すなわちセグ
メント開始が最初に入力され、次いで、命令実行が入力
され、その後、ループトリガーが入力され、遅延された
ロードデータが最終的に入力される。
ロック周期で生成されることが(望ましくはないが)可能
である。パケットが生成される時、パケット自体、パケ
ットのサイズ、及び“新しい”フラッグが生成ユニット
744から出力される。仮に一つ以上のパケットが同時
に生成されれば、そのパケットは、指定された順序によ
ってパケットパイプラインに入力される。すなわちセグ
メント開始が最初に入力され、次いで、命令実行が入力
され、その後、ループトリガーが入力され、遅延された
ロードデータが最終的に入力される。
【0185】それぞれのパケットは、幅が広いか(図示
した実施形態では、23ニブルまで)、比較的幅が狭く
ても(4ニブル以下)よく、資源の使用を極大化させ、パ
ケットパイプラインアレイ(後述する)のレジスタは、
パケット部分として本明細書で言及した8個のニブルブ
ロックにグループ化される。また、32ビットのデータ
と一緒に、パケット部分は、パケット部分での有効ニブ
ル数に関する情報を含み、パケット境界に関する情報を
制御する。
した実施形態では、23ニブルまで)、比較的幅が狭く
ても(4ニブル以下)よく、資源の使用を極大化させ、パ
ケットパイプラインアレイ(後述する)のレジスタは、
パケット部分として本明細書で言及した8個のニブルブ
ロックにグループ化される。また、32ビットのデータ
と一緒に、パケット部分は、パケット部分での有効ニブ
ル数に関する情報を含み、パケット境界に関する情報を
制御する。
【0186】図8aに示したように、本発明のパケット
パイプライン800の第1の実施形態は、パケット部ア
レイ802で構成される。行804及び列806の数
は、デバイス構成瞬間にユーザーによって構成可能にな
るように有利に作られる。
パイプライン800の第1の実施形態は、パケット部ア
レイ802で構成される。行804及び列806の数
は、デバイス構成瞬間にユーザーによって構成可能にな
るように有利に作られる。
【0187】制御論理回路は、列806のうちどれが生
成ユニットからその次のパケット部分を受信すべきかを
決定するために、第1の行807にポインタを維持す
る。また、ポインタは、どんな列からデータを抽出する
かを決定するために、出力行に維持される。この実施形
態のポインタは、順次的に変わり、たとえ他のアプロー
チが代わりに使われることができるとしても、ポインタ
が最後の列に至った時に循環(wrapping)する。
成ユニットからその次のパケット部分を受信すべきかを
決定するために、第1の行807にポインタを維持す
る。また、ポインタは、どんな列からデータを抽出する
かを決定するために、出力行に維持される。この実施形
態のポインタは、順次的に変わり、たとえ他のアプロー
チが代わりに使われることができるとしても、ポインタ
が最後の列に至った時に循環(wrapping)する。
【0188】その次の行にあるが、同じ列にある部分が
空いていると表示される時、すなわちデータが行からFI
FOに送られている時は、有効部分がパケットパイプライ
ン800に流れる。
空いていると表示される時、すなわちデータが行からFI
FOに送られている時は、有効部分がパケットパイプライ
ン800に流れる。
【0189】パケットパイプラインの最小幅は、(i)FIF
O幅より大きく、または(ii)単一パケットの最大幅で作
られる。最大パケットパイプラインの幅は、共に生成さ
れたあらゆるパケットカテゴリーの最大幅と同じであ
る。深さは、1行から任意のサイズ(たとえば、32)ま
で変わることができるが、唯一の制限点は、消費者によ
って最終ICデバイスに提供可能なゲート数である。
O幅より大きく、または(ii)単一パケットの最大幅で作
られる。最大パケットパイプラインの幅は、共に生成さ
れたあらゆるパケットカテゴリーの最大幅と同じであ
る。深さは、1行から任意のサイズ(たとえば、32)ま
で変わることができるが、唯一の制限点は、消費者によ
って最終ICデバイスに提供可能なゲート数である。
【0190】また、本実施形態のそれぞれのパケットカ
テゴリーは、セット時に、新しいパケットが生成された
ことを表す関連フラッグを有する。このようなパケット
が到着した時、パケットが正確な順序でパケットパイプ
ラインに入るようにするために、ラケットには、マルチ
ビット(たとえば、2-ビット)のタイムスタンプが割り
当てられる。古くなったパケットが除去され、パケット
パイプラインに位置する前に、新しいパケットが生成ユ
ニット出力端に到着した時には、オーバーフローが発生
する。
テゴリーは、セット時に、新しいパケットが生成された
ことを表す関連フラッグを有する。このようなパケット
が到着した時、パケットが正確な順序でパケットパイプ
ラインに入るようにするために、ラケットには、マルチ
ビット(たとえば、2-ビット)のタイムスタンプが割り
当てられる。古くなったパケットが除去され、パケット
パイプラインに位置する前に、新しいパケットが生成ユ
ニット出力端に到着した時には、オーバーフローが発生
する。
【0191】図8bを参照すれば、本発明のパケットア
レイ構造に対する選択的な実施形態が図示されている。
明らかなように、前述した図8aのアレイ構造での資源
使用は、あらゆるパケット部分が同一に使われ、あらゆ
る部分が使用中にある時にだけ、オーバーフローが発生
するという点において最適である。しかし、ひとつの短
所として、パケットパイプライン入力において比較的大
きいサイズの多重化が必要であるという点が挙げられ
る。それぞれのパケット部分は、32-ビット幅を有
し、それぞれのビットは、図示した実施形態で10:1
マルチプレクサ(10:1mux)が必要である。そうした多
重化集約的な設計は、設計者が設計のための配置を生成
しようとする時、潜在的に問題を引き起こすことがあ
る。
レイ構造に対する選択的な実施形態が図示されている。
明らかなように、前述した図8aのアレイ構造での資源
使用は、あらゆるパケット部分が同一に使われ、あらゆ
る部分が使用中にある時にだけ、オーバーフローが発生
するという点において最適である。しかし、ひとつの短
所として、パケットパイプライン入力において比較的大
きいサイズの多重化が必要であるという点が挙げられ
る。それぞれのパケット部分は、32-ビット幅を有
し、それぞれのビットは、図示した実施形態で10:1
マルチプレクサ(10:1mux)が必要である。そうした多
重化集約的な設計は、設計者が設計のための配置を生成
しようとする時、潜在的に問題を引き起こすことがあ
る。
【0192】したがって、図8bの実施形態は、二つの
別途のパケットパイプラインを併合する。本発明の譲受
人によるシミュレーションは、セグメント開始及びルー
トトリガーパケット形態が生成される周波数は、命令実
行及び遅延されたロードデータパケット形態が生成され
る周波数より極めて低いことを示す。したがって、一つ
の構成においては、“低い”頻度の周波数パケットと、
“高い”頻度の周波数パケットは、別途の各パイプライ
ンアレイに分割され、パケットパイプライン入力端で必
要とする多重化の量を效果的に半減する。
別途のパケットパイプラインを併合する。本発明の譲受
人によるシミュレーションは、セグメント開始及びルー
トトリガーパケット形態が生成される周波数は、命令実
行及び遅延されたロードデータパケット形態が生成され
る周波数より極めて低いことを示す。したがって、一つ
の構成においては、“低い”頻度の周波数パケットと、
“高い”頻度の周波数パケットは、別途の各パイプライ
ンアレイに分割され、パケットパイプライン入力端で必
要とする多重化の量を效果的に半減する。
【0193】図9を参照して、パケットパイプラインFI
FOのための一つの例示的な構造900を説明する。本実
施形態のFIFO902は、バッファサイズを大きく増加さ
せるために、オンチップRAMを使用する。RAMは、パケッ
トパイプラインより実質的に“幅が狭く”、したがっ
て、その主要機能は、中間-頻度及び中間-長さのデータ
バストをバッファリングすることである。図9に示した
ように、FIFO902は、該当分野でよく知られている形
態の正しい同期デュアルポートRAMを使用する。RAMの記
録論理は、RTTユニット及びコア705の残りと同じク
ロックで動作し、判読論理は、パケットポート709及
びキャプチャーデバイス772と同じクロックで動作す
る。
FOのための一つの例示的な構造900を説明する。本実
施形態のFIFO902は、バッファサイズを大きく増加さ
せるために、オンチップRAMを使用する。RAMは、パケッ
トパイプラインより実質的に“幅が狭く”、したがっ
て、その主要機能は、中間-頻度及び中間-長さのデータ
バストをバッファリングすることである。図9に示した
ように、FIFO902は、該当分野でよく知られている形
態の正しい同期デュアルポートRAMを使用する。RAMの記
録論理は、RTTユニット及びコア705の残りと同じク
ロックで動作し、判読論理は、パケットポート709及
びキャプチャーデバイス772と同じクロックで動作す
る。
【0194】FIFO902は、固定された幅、すなわち図
示された実施形態では、2パケット部を有するが、深さ
は、ビルドタイム(build-time)に構成可能である。ま
た、深さは、ゼロの値を含むように選択的に構成される
が、それは、FIFOを設計から完璧に除去する。
示された実施形態では、2パケット部を有するが、深さ
は、ビルドタイム(build-time)に構成可能である。ま
た、深さは、ゼロの値を含むように選択的に構成される
が、それは、FIFOを設計から完璧に除去する。
【0195】図8bのパケットパイプラインアレイ構造
を参照することによって、より小さいアレイから情報を
抽出する時を示す制御情報を、マルチプレクサとFIFO間
でも使用することに注目すべきである。これは、より小
さいアレイから判読する前に、多くの部分を主アレイか
らどのように判読するかを表すカウンタを用いて、この
実施形態で達成される。しかし、本発明と合わせて他の
アプローチが共に成功的に使われることができることを
理解すべきである。
を参照することによって、より小さいアレイから情報を
抽出する時を示す制御情報を、マルチプレクサとFIFO間
でも使用することに注目すべきである。これは、より小
さいアレイから判読する前に、多くの部分を主アレイか
らどのように判読するかを表すカウンタを用いて、この
実施形態で達成される。しかし、本発明と合わせて他の
アプローチが共に成功的に使われることができることを
理解すべきである。
【0196】図8bの実施形態は、一般的に、2個のア
レイの相対的サイズを判断するためのメカニズムが存在
する時、最適化できることも理解すべきである。特に、
パケットパイプラインハードウェアに対する最適の使用
を達成するために、二つのアレイは、たとえそれらが満
たされる相対的な速度がトレースによって変わっても、
ほぼ同時にオーバーフローされなければならない。した
がって、ビルドタイム前に行われるシミュレーション
は、最適の相対的のサイズを決定するのに有用である。
レイの相対的サイズを判断するためのメカニズムが存在
する時、最適化できることも理解すべきである。特に、
パケットパイプラインハードウェアに対する最適の使用
を達成するために、二つのアレイは、たとえそれらが満
たされる相対的な速度がトレースによって変わっても、
ほぼ同時にオーバーフローされなければならない。した
がって、ビルドタイム前に行われるシミュレーション
は、最適の相対的のサイズを決定するのに有用である。
【0197】FIFO902は、RTTシステムに常に存在す
るものではないので、パケットパイプラインとFIFO間の
インタフェースは、FIFOとパケットポート間のインタフ
ェースに正確に一致するように作られることができる。
これは、FIFOを必要としない場合、パケットパイプライ
ンが(名前変更ブロック信号として動作するFIFOにより)
パケットポートに直接接続するように許容される。
るものではないので、パケットパイプラインとFIFO間の
インタフェースは、FIFOとパケットポート間のインタフ
ェースに正確に一致するように作られることができる。
これは、FIFOを必要としない場合、パケットパイプライ
ンが(名前変更ブロック信号として動作するFIFOにより)
パケットポートに直接接続するように許容される。
【0198】パケットパイプラインは、オプションの二
つのアレイ部で構成される。一方のアレイは、高い帯域
幅カテゴリーからのパケットを格納し、他方のアレイ
は、低い帯域幅カテゴリーからのパケットを格納する。
このようなアレイのサイズは、一定のサイズで完璧に構
成可能である。高い帯域幅アレイは、典型的により多く
のパケットをバッファリングするのに要求される時、非
常に大きくなる。パケットがパイプラインアレイに入力
・出力される順序は、それらが生成ユニット出力端に到
着する順序と同一である。
つのアレイ部で構成される。一方のアレイは、高い帯域
幅カテゴリーからのパケットを格納し、他方のアレイ
は、低い帯域幅カテゴリーからのパケットを格納する。
このようなアレイのサイズは、一定のサイズで完璧に構
成可能である。高い帯域幅アレイは、典型的により多く
のパケットをバッファリングするのに要求される時、非
常に大きくなる。パケットがパイプラインアレイに入力
・出力される順序は、それらが生成ユニット出力端に到
着する順序と同一である。
【0199】前述したように、任意の周期で最大4つの
パケットを生成することが可能であり、これは、きわめ
て希な場合にだけ発生する。あらゆるパケットは、特定
のカテゴリーに属し、他のカテゴリーからのパケットだ
けが同時に生成されることができる。生成ユニットから
のあらゆる出力は、レジスタから直接的に出て、新しい
パケットが到着しない限り、それらの値を有していなけ
ればならない。
パケットを生成することが可能であり、これは、きわめ
て希な場合にだけ発生する。あらゆるパケットは、特定
のカテゴリーに属し、他のカテゴリーからのパケットだ
けが同時に生成されることができる。生成ユニットから
のあらゆる出力は、レジスタから直接的に出て、新しい
パケットが到着しない限り、それらの値を有していなけ
ればならない。
【0200】表6は、本実施形態の生成ユニットとパケ
ットパイプライン間の例示的なポートインタフェース信
号を目録化したリストである。
ットパイプライン間の例示的なポートインタフェース信
号を目録化したリストである。
【0201】
【表6】
【0202】パケットは、一回にパイプラインアレイの
2部分から抽出され、出力レジスタのFIFOに印加され
る。下記の表7は、パケットパイプラインとFIFOブロッ
ク間のあらゆるポートインタフェース信号を列挙する。
2部分から抽出され、出力レジスタのFIFOに印加され
る。下記の表7は、パケットパイプラインとFIFOブロッ
ク間のあらゆるポートインタフェース信号を列挙する。
【0203】
【表7】
【0204】記述された実施形態で、パケットパイプラ
インに影響を及ぼす唯一の構成レジスタは、バッファ制
御レジスタである。このレジスタのデセイブルバッファ
オーバーフロー(DBO)ビットは、ノーマル動作中にはパ
ケットパイプラインに影響を及ぼさないが、バッファオ
ーバーフロー信号を遮断するための検証の目的だけで使
われる。
インに影響を及ぼす唯一の構成レジスタは、バッファ制
御レジスタである。このレジスタのデセイブルバッファ
オーバーフロー(DBO)ビットは、ノーマル動作中にはパ
ケットパイプラインに影響を及ぼさないが、バッファオ
ーバーフロー信号を遮断するための検証の目的だけで使
われる。
【0205】表8は、本発明に係るコアでの適切なモジ
ュールとパケットパイプライン間のポートインタフェー
ス信号を目録化したリストである。
ュールとパケットパイプライン間のポートインタフェー
ス信号を目録化したリストである。
【0206】
【表8】
【0207】2パイプラインアレイの幅と深さは、rtt
_optionパッケージで規定された常数により本実施形態
で独立的に構成可能である。PIPE_IE_DLD_COLS及びP
IPE_DLD_ROWSは、いずれも高い帯域幅アレイのサイズ
を限定し、このアレイには、命令実行及び遅延されたロ
ードデータカテゴリーからのパケットが格納される。PI
PE_CTL_LP_COLS及びPIPE_CTL_LP_ROWS常数は、低
い帯域幅アレイのサイズを限定し、このアレイには、制
御及びループトリガーカテゴリーからのパケットが格納
される。
_optionパッケージで規定された常数により本実施形態
で独立的に構成可能である。PIPE_IE_DLD_COLS及びP
IPE_DLD_ROWSは、いずれも高い帯域幅アレイのサイズ
を限定し、このアレイには、命令実行及び遅延されたロ
ードデータカテゴリーからのパケットが格納される。PI
PE_CTL_LP_COLS及びPIPE_CTL_LP_ROWS常数は、低
い帯域幅アレイのサイズを限定し、このアレイには、制
御及びループトリガーカテゴリーからのパケットが格納
される。
【0208】行の個数に対する値には(その値が1また
はその以上の値になる限り)何らの制約がない。パケッ
トは、あらゆるパケットが適した場合にだけ、パイプラ
インに受け入れられ、したがって、行の個数が最大パケ
ット幅(部分的に)より大きいか同一になり、又はこのパ
ケットは決して受け入れられない。行の個数は、機能を
向上させないため、二つの最大パケットカテゴリーに対
する総幅(部分的に)を超過せず、かつ、システムのタ
イミング要求を充足することが難しい。
はその以上の値になる限り)何らの制約がない。パケッ
トは、あらゆるパケットが適した場合にだけ、パイプラ
インに受け入れられ、したがって、行の個数が最大パケ
ット幅(部分的に)より大きいか同一になり、又はこのパ
ケットは決して受け入れられない。行の個数は、機能を
向上させないため、二つの最大パケットカテゴリーに対
する総幅(部分的に)を超過せず、かつ、システムのタ
イミング要求を充足することが難しい。
【0209】パケットパイプラインのみがデータ部を処
理する。パケットがより一層管理可能であるようにし、
格納効率、達成可能なタイミング、及び複雑でない制御
論理回路間に良好な折衝を提供するために、RTTの本実
施形態のパケットは、いずれも部分に分けられる。部分
は、図10の例示的な装置に示したように、8ニブルの
データと、1ニブルの制御ビットとで構成される。デー
タがパケットのどんな部分にあっても、データは、その
部分に格納され、制御ビットは、下記の表9の情報を有
する。
理する。パケットがより一層管理可能であるようにし、
格納効率、達成可能なタイミング、及び複雑でない制御
論理回路間に良好な折衝を提供するために、RTTの本実
施形態のパケットは、いずれも部分に分けられる。部分
は、図10の例示的な装置に示したように、8ニブルの
データと、1ニブルの制御ビットとで構成される。デー
タがパケットのどんな部分にあっても、データは、その
部分に格納され、制御ビットは、下記の表9の情報を有
する。
【0210】
【表9】
【0211】パケットポートがSEGSTARTパケット前にゼ
ロにパッドする必要があり、パケットの中間にある任意
のデータとSEGSTARTパケットヘッダーとを区別する必要
があり得るため、パケットの境界が発生する所をデコー
ドできることが望ましい。
ロにパッドする必要があり、パケットの中間にある任意
のデータとSEGSTARTパケットヘッダーとを区別する必要
があり得るため、パケットの境界が発生する所をデコー
ドできることが望ましい。
【0212】パケットが生成ユニットの出力端に到着し
た時(新しい信号で指定されることによって)、このパケ
ットは、次の周期でパケットパイプラインに必ず受け入
れられるものではない。パケットは、パイプラインで空
間が利用可能になるか、又は空間が同一のカテゴリーの
他のパケットによって上書きする時までは、少しの間停
止することにより、バッファのオーバーフローをトリガ
ーさせる。
た時(新しい信号で指定されることによって)、このパケ
ットは、次の周期でパケットパイプラインに必ず受け入
れられるものではない。パケットは、パイプラインで空
間が利用可能になるか、又は空間が同一のカテゴリーの
他のパケットによって上書きする時までは、少しの間停
止することにより、バッファのオーバーフローをトリガ
ーさせる。
【0213】パケットが生成される順序と、このパケッ
トがパケットパイプラインを離れる順序とを保存するた
めに、あらゆる新しいパケットは、初めて到着する時、
エイジタグ(age tag)が割り当てられる。本実施形態に
おいて、このようなエイジタグは、2ビットで構成さ
れ、2ビットは、他の周期で到着するすべて4個のパケ
ットカテゴリーをカバーする。しかし、他のビット番号
及びスキームが使われてもよい。二つ以上の制御エイジ
タグ、すなわちパイプラインにまだ受け入れられない最
も古くなったパケットに対するoldest_ageポイント
と、一番最近に到着したパケットに対するnewest_age
ポイントがシステムにより維持される。
トがパケットパイプラインを離れる順序とを保存するた
めに、あらゆる新しいパケットは、初めて到着する時、
エイジタグ(age tag)が割り当てられる。本実施形態に
おいて、このようなエイジタグは、2ビットで構成さ
れ、2ビットは、他の周期で到着するすべて4個のパケ
ットカテゴリーをカバーする。しかし、他のビット番号
及びスキームが使われてもよい。二つ以上の制御エイジ
タグ、すなわちパイプラインにまだ受け入れられない最
も古くなったパケットに対するoldest_ageポイント
と、一番最近に到着したパケットに対するnewest_age
ポイントがシステムにより維持される。
【0214】newest_ageタグは、新しいパケットが到
着する周期だけで増加する。oldest_age_tagは、その
エイジのあらゆるパケットがパイプラインに受け入れら
れるたびに増加する。記述された実施形態での2エイジ
カウンタは、いずれもモジュールで4演算(modulo N ar
tithmetic)を使用して循環するように作られる。
着する周期だけで増加する。oldest_age_tagは、その
エイジのあらゆるパケットがパイプラインに受け入れら
れるたびに増加する。記述された実施形態での2エイジ
カウンタは、いずれもモジュールで4演算(modulo N ar
tithmetic)を使用して循環するように作られる。
【0215】また、それぞれのパケットパイプラインア
レイは、入力列ポインタと出力列ポインタを有する。こ
れらポインタは、アレイの幅を有するレジスタであり、
次の部分が、そのレジスタがどこに入るか、またはどこ
から抽出されるかを表すために、該当分野によく知られ
ている形態の“1-hot”エンコーディングを使用する。
1-hotシステムは、新しいポインタ値を計算する時、パ
ケットがパイプラインに適合するかに関係なく、制御論
理を簡単にする。たとえば、2進ポインタは、5個の列
よりなるアレイに対してモジュールで5演算(modulo N
artithmetic)を必要とする。
レイは、入力列ポインタと出力列ポインタを有する。こ
れらポインタは、アレイの幅を有するレジスタであり、
次の部分が、そのレジスタがどこに入るか、またはどこ
から抽出されるかを表すために、該当分野によく知られ
ている形態の“1-hot”エンコーディングを使用する。
1-hotシステムは、新しいポインタ値を計算する時、パ
ケットがパイプラインに適合するかに関係なく、制御論
理を簡単にする。たとえば、2進ポインタは、5個の列
よりなるアレイに対してモジュールで5演算(modulo N
artithmetic)を必要とする。
【0216】出力制御論理は、どんなアレイパケットが
その次に除去されなければならないかを決定するための
メカニズムを必要とする。いくつの部分がその特定部分
に先だって高い帯域幅アレイから除去されなければなら
ないかを表す部分カウンタは、低い帯域幅アレイの各部
分と関連する。高い帯域幅アレイから一部が除去される
たびに、出力部分カウンタは増加し、この値が抽出され
るべき次の低い帯域幅部分の部分カウント値に一致する
時、その部分が除去され、カウンタはリセットする。
その次に除去されなければならないかを決定するための
メカニズムを必要とする。いくつの部分がその特定部分
に先だって高い帯域幅アレイから除去されなければなら
ないかを表す部分カウンタは、低い帯域幅アレイの各部
分と関連する。高い帯域幅アレイから一部が除去される
たびに、出力部分カウンタは増加し、この値が抽出され
るべき次の低い帯域幅部分の部分カウント値に一致する
時、その部分が除去され、カウンタはリセットする。
【0217】これに対して、付録IVは、本実施形態のバ
ッファ/パケットパイプラインに用いられる例示的なレ
ジスタの定義を提供する。
ッファ/パケットパイプラインに用いられる例示的なレ
ジスタの定義を提供する。
【0218】ソフトウェアドライバー図11aに示した
ように、本発明は、キャプチャーハードウェアとソフト
ウェアデバッグプログラムとの間をインタフェースする
ために、ソフトウェアドライバーを追加的に使用する。
これにより、キャプチャーセッションは、実行される前
に構成することが可能になる。実行時に、図11aに示
したドライバーの例示的な実施形態は、RTT及び実行レ
ジスタをターゲット地点に構成し、キャプチャーハード
ウェアを初期化し備える。
ように、本発明は、キャプチャーハードウェアとソフト
ウェアデバッグプログラムとの間をインタフェースする
ために、ソフトウェアドライバーを追加的に使用する。
これにより、キャプチャーセッションは、実行される前
に構成することが可能になる。実行時に、図11aに示
したドライバーの例示的な実施形態は、RTT及び実行レ
ジスタをターゲット地点に構成し、キャプチャーハード
ウェアを初期化し備える。
【0219】本発明のRTTドライバーの例示的な実施形
態は、ミニコンピュータ(たとえば、太陽熱で動作するS
un Microsystems workstation)上で実行するように適用
されるが、他のハードウェア及びソフトウェア環境が使
用され得ることがわかる。例えば、マイクロコンピュー
タ(たとえば、WinNT)上で実行される、Microsoft Windo
ws(登録商標)に基づくドライバーアプローチが使われ
ることができる。本明細書で説明された多様な機能は、
本開示に与えられたプログラミング分野の当業者により
ターゲット環境/言語で容易に具現され得ることが分か
る。したがって、次の論議は、任意の特定具現に対する
詳細事項に対照されるもので、ソフトウェアドライバー
特徴の機能に焦点をおく。
態は、ミニコンピュータ(たとえば、太陽熱で動作するS
un Microsystems workstation)上で実行するように適用
されるが、他のハードウェア及びソフトウェア環境が使
用され得ることがわかる。例えば、マイクロコンピュー
タ(たとえば、WinNT)上で実行される、Microsoft Windo
ws(登録商標)に基づくドライバーアプローチが使われ
ることができる。本明細書で説明された多様な機能は、
本開示に与えられたプログラミング分野の当業者により
ターゲット環境/言語で容易に具現され得ることが分か
る。したがって、次の論議は、任意の特定具現に対する
詳細事項に対照されるもので、ソフトウェアドライバー
特徴の機能に焦点をおく。
【0220】本実施形態のドライバーソフトウェアは、
いろいろなデバッグ環境を支援するように設計される。
このような事実をふまえて、ドライバーは、任意の特定
デバッグに関係無しに有利に開発される。ターゲットが
決まったそれぞれのデバッグ環境のために、既存のGUI
インタフェースとRTTドライバーへのリンキングの統合
が要求されるが、そういう統合は、ソフトウェアプログ
ラミング分野の当業者によって容易に行われる。このよ
うなアプローチは、それぞれのデバッグ環境がRTTドラ
イバーソフトウェアとの密接な統合を提供するように保
障する。
いろいろなデバッグ環境を支援するように設計される。
このような事実をふまえて、ドライバーは、任意の特定
デバッグに関係無しに有利に開発される。ターゲットが
決まったそれぞれのデバッグ環境のために、既存のGUI
インタフェースとRTTドライバーへのリンキングの統合
が要求されるが、そういう統合は、ソフトウェアプログ
ラミング分野の当業者によって容易に行われる。このよ
うなアプローチは、それぞれのデバッグ環境がRTTドラ
イバーソフトウェアとの密接な統合を提供するように保
障する。
【0221】また、ドライバーソフトウェアは、単一の
論理アナライザーとインタフェースするように構成され
ることができ、また、ハードウェア変動、他の論理アナ
ライザーブランド、または専用の注文製ハードウェアを
支援するように更新され得るように、開放的で且つ拡張
可能である。任意の数の他のハードウェア環境が支援さ
れ得る。
論理アナライザーとインタフェースするように構成され
ることができ、また、ハードウェア変動、他の論理アナ
ライザーブランド、または専用の注文製ハードウェアを
支援するように更新され得るように、開放的で且つ拡張
可能である。任意の数の他のハードウェア環境が支援さ
れ得る。
【0222】RTTキャプチャーの制御は、例示的な実施
形態において、トレースセッションの概念に基づいて構
成される。トレースセッションは、ユーザーにより限定
されるトレースセットによって実行ターゲットのコード
及びキャプチャートレースの結果を含む。トレースセッ
ションは、それぞれのキャプチャー実行を表す。トレー
スセッションを開始する前に、ユーザーは、1セットの
トレースセットを構成する。構成は、本場合において、
キャプチャーされる情報の形態、トレース開始及び終了
条件、任意のトリガー条件及びそれと関連した動作、及
び適用されるべきフィルタに対する説明を含む。セッシ
ョンセットの詳細事項は、デバッグGUIにより選択的に
キャプチャーされ維持される。したがって、ユーザー
は、必要時に、このようなセットを修正し削除すること
ができる。また、デバッグにより、ユーザーは、現在の
トレースセットを節約するか、以前に節約されたセット
をロードすることができ、このセットは、次のようなも
のを含む: (i)キャプチャーバッファサイズ:ユーザーは、物理的
に利用可能な最大のサイズまで使われるべきトレースバ
ッファのサイズを指定することができる。 (ii)バッファ動作:ユーザーは、キャプチャーバッファ
が循環的なメモリ、又は1回使用メモリとして使われる
か否かを指定することができる。 (iii)ターゲット開始条件:ユーザーは、選択的なプロ
グラムカウンタ(PC)の実行開始値を指定することがで
きる。キャプチャーされたトレースの開始をこのような
PCと同期するためのオプションが提供される。
形態において、トレースセッションの概念に基づいて構
成される。トレースセッションは、ユーザーにより限定
されるトレースセットによって実行ターゲットのコード
及びキャプチャートレースの結果を含む。トレースセッ
ションは、それぞれのキャプチャー実行を表す。トレー
スセッションを開始する前に、ユーザーは、1セットの
トレースセットを構成する。構成は、本場合において、
キャプチャーされる情報の形態、トレース開始及び終了
条件、任意のトリガー条件及びそれと関連した動作、及
び適用されるべきフィルタに対する説明を含む。セッシ
ョンセットの詳細事項は、デバッグGUIにより選択的に
キャプチャーされ維持される。したがって、ユーザー
は、必要時に、このようなセットを修正し削除すること
ができる。また、デバッグにより、ユーザーは、現在の
トレースセットを節約するか、以前に節約されたセット
をロードすることができ、このセットは、次のようなも
のを含む: (i)キャプチャーバッファサイズ:ユーザーは、物理的
に利用可能な最大のサイズまで使われるべきトレースバ
ッファのサイズを指定することができる。 (ii)バッファ動作:ユーザーは、キャプチャーバッファ
が循環的なメモリ、又は1回使用メモリとして使われる
か否かを指定することができる。 (iii)ターゲット開始条件:ユーザーは、選択的なプロ
グラムカウンタ(PC)の実行開始値を指定することがで
きる。キャプチャーされたトレースの開始をこのような
PCと同期するためのオプションが提供される。
【0223】(iv)キャプチャー開始条件:ユーザーは、
トレースが活性化した直後に、トレースキャプチャーを
開始すべきか、又は一つ以上の指定された条件が充足さ
れた直後に開始すべきかを指定することができる。 (v)キャプチャー終了条件:ユーザーは、トレースキャ
プチャーをいつ終了すべきかを指定することができる。
これは、例えば、キャプチャーバッファがフルとなる
か、又は一つ以上の指定された条件がいつ充足されるか
である。 (vi)フィルタ:ユーザーは、特定のアドレス範囲をトレ
ースのために無視すべきかを指定することができる。逆
に、ユーザーは、重要なアドレス範囲を指定できること
によって、PCがその範囲内にある時にだけ、トレースが
キャプチャーされるようにする。
トレースが活性化した直後に、トレースキャプチャーを
開始すべきか、又は一つ以上の指定された条件が充足さ
れた直後に開始すべきかを指定することができる。 (v)キャプチャー終了条件:ユーザーは、トレースキャ
プチャーをいつ終了すべきかを指定することができる。
これは、例えば、キャプチャーバッファがフルとなる
か、又は一つ以上の指定された条件がいつ充足されるか
である。 (vi)フィルタ:ユーザーは、特定のアドレス範囲をトレ
ースのために無視すべきかを指定することができる。逆
に、ユーザーは、重要なアドレス範囲を指定できること
によって、PCがその範囲内にある時にだけ、トレースが
キャプチャーされるようにする。
【0224】キャプチャー開始及び終了のための条件
は、離散的なプログラムカウンタ(PC)値、PC範囲、デー
タ値、データアドレス、またはデータ値とアドレスの結
合を含むが、それらに限定されない。ユーザーは、RTT
ユニットで合成されるモニターの数だけで制限される任
意の数の開始及び条件又はフィルタを有することができ
る。
は、離散的なプログラムカウンタ(PC)値、PC範囲、デー
タ値、データアドレス、またはデータ値とアドレスの結
合を含むが、それらに限定されない。ユーザーは、RTT
ユニットで合成されるモニターの数だけで制限される任
意の数の開始及び条件又はフィルタを有することができ
る。
【0225】一旦トレースセットが定められると、ユー
ザーは、トレースキャプチャー(トレースセッション)
を開始する。それぞれのトレースセッションに対する結
果は、必要に応じて、デバッグGUIに提供されることが
できる。ユーザーは、スクリーン上のいろいろなトレー
ス結果を同時に比較するだけでなく、トレース結果を格
納しロードすることができる。
ザーは、トレースキャプチャー(トレースセッション)
を開始する。それぞれのトレースセッションに対する結
果は、必要に応じて、デバッグGUIに提供されることが
できる。ユーザーは、スクリーン上のいろいろなトレー
ス結果を同時に比較するだけでなく、トレース結果を格
納しロードすることができる。
【0226】本実施形態のソフトウェアドライバーは、
エラー及び例外状況の包括的な処理を提供する。欠陥(f
ault)に対する適切なテキスト説明が、ユーザーインタ
フェース、コンソール出力、またはログファイルにさら
に伝達される。
エラー及び例外状況の包括的な処理を提供する。欠陥(f
ault)に対する適切なテキスト説明が、ユーザーインタ
フェース、コンソール出力、またはログファイルにさら
に伝達される。
【0227】図11bは本発明のRTTドライバーに使わ
れるトレースセットを構成するためのダイアローグGUI
の例示的な実施形態を示す。GUIは拡張可能な数のトレ
ースフィルター及びトリガーを有する。フィルター及び
トリガーは活性の優先順位によって順序を定めることが
できる。フィルター/トリガーは第1“N”フィルター/
トリガーの主要属性が同時に見えるように簡略化したリ
ストビュー(list view)に表れている。フィルター/トリ
ガーの主要属性はリストディスプレーで2度クリックす
ることにより直接編集できる。適切な列で2度クリック
することは開始、停止、格納及び活性属性をトグルさせ
る。完全なエディタを入力させるために、ユーザーは他
の列で2度クリックする。総括的にトレースセッション
に対するセット、例えばバッファサイズ及び形態は別の
タブ区画からアクセスする。選択性の要約ビューが右側
サイドバー上に表れることがある。選択性の要約ビュー
により多様な制御及びビュー区画から選ばれる全てのト
レースセットは一つの場所に要約される。
れるトレースセットを構成するためのダイアローグGUI
の例示的な実施形態を示す。GUIは拡張可能な数のトレ
ースフィルター及びトリガーを有する。フィルター及び
トリガーは活性の優先順位によって順序を定めることが
できる。フィルター/トリガーは第1“N”フィルター/
トリガーの主要属性が同時に見えるように簡略化したリ
ストビュー(list view)に表れている。フィルター/トリ
ガーの主要属性はリストディスプレーで2度クリックす
ることにより直接編集できる。適切な列で2度クリック
することは開始、停止、格納及び活性属性をトグルさせ
る。完全なエディタを入力させるために、ユーザーは他
の列で2度クリックする。総括的にトレースセッション
に対するセット、例えばバッファサイズ及び形態は別の
タブ区画からアクセスする。選択性の要約ビューが右側
サイドバー上に表れることがある。選択性の要約ビュー
により多様な制御及びビュー区画から選ばれる全てのト
レースセットは一つの場所に要約される。
【0228】図11cはフィルター編集者ダイアローグ
GUIの例示的な実施形態を示す。ダイアローグGUIはター
ゲットアドレス値を入力するための多様な方法を提供す
る。アドレスは直接記入するか(例えば、16進数値と
して)、または最近使われたコードラベルリストをプル
ーダウンして入力することによって、アクセスできる。
選択的に、プルーダウンリストの下段にある“mor
e...”のオプションは完全なコードブラウザーをデ
ィスプレーするために選択できる。また、ダイアローグ
GUIによりユーザーは説明的なコメントを書き込むこと
ができるようになる。これは更に多くのフィルター/ト
リガーがトレースセットに追加される時、特に有用であ
る。
GUIの例示的な実施形態を示す。ダイアローグGUIはター
ゲットアドレス値を入力するための多様な方法を提供す
る。アドレスは直接記入するか(例えば、16進数値と
して)、または最近使われたコードラベルリストをプル
ーダウンして入力することによって、アクセスできる。
選択的に、プルーダウンリストの下段にある“mor
e...”のオプションは完全なコードブラウザーをデ
ィスプレーするために選択できる。また、ダイアローグ
GUIによりユーザーは説明的なコメントを書き込むこと
ができるようになる。これは更に多くのフィルター/ト
リガーがトレースセットに追加される時、特に有用であ
る。
【0229】例示的な実施形態のデバッガGUIは現在ロ
ーディングされる全てのトレースセッションを示すディ
スプレーを提供し、ユーザーの要求時には、他の要約ビ
ューの任意のものに対してディスプレーされるようにな
る。要約情報は選択的に、(i)トレースキャプチャの日
時、(ii)キャプチャ時間の期間、(iii)セッションデー
タのサイズ(これはトレースデータの総メモリーサイズ
やレコードの数により行われることができる)、(iv)ト
レースセッションに使われたトレースセット、(v)ディ
スクに格納されるか、そのディスクからロードされる全
てのセッションの結果に対して、ファイル名(ら)を含む
要約、及び(vi)トレースセッションに対するユーザーの
追加説明を含む。
ーディングされる全てのトレースセッションを示すディ
スプレーを提供し、ユーザーの要求時には、他の要約ビ
ューの任意のものに対してディスプレーされるようにな
る。要約情報は選択的に、(i)トレースキャプチャの日
時、(ii)キャプチャ時間の期間、(iii)セッションデー
タのサイズ(これはトレースデータの総メモリーサイズ
やレコードの数により行われることができる)、(iv)ト
レースセッションに使われたトレースセット、(v)ディ
スクに格納されるか、そのディスクからロードされる全
てのセッションの結果に対して、ファイル名(ら)を含む
要約、及び(vi)トレースセッションに対するユーザーの
追加説明を含む。
【0230】デバッガGUIはキャプチャされた全てのト
レースイベントを年代順で示すトレースディスプレービ
ューを提供する。このビューは、RTTライブラリーがキ
ャプチャセッションに対する完全なトレースデータを管
理させるためにダイナミックに生成されるようになり、
これによって活性サブセットのみが常にデバッガで照会
されてディスプレーされるようになる。例示的な実施形
態において、トレースディスプレーは、ビュー領域がト
レースデータから抽出される情報の他のフィールドを示
すように命名された列に分類されるリストビューを含
む。トレースフィールドは、(i)タイムスタンプの情
報、(ii)プログラムカウンタのアドレス、(iii)現在ソ
ースの命令文(例えば、“C”またはアセンブラ言語)、
(iv)データアクセスのアドレス、(v)データのアクセス
値、(vi)実行“C”時間(例えば、評価が用いられる状況
下でオプコード命令が実行される周期の数)、(vii)例え
ば、トレースFIFOがオーバーフローされることのような
例外的なイベントを含むが、それらに限定されるもので
はない。
レースイベントを年代順で示すトレースディスプレービ
ューを提供する。このビューは、RTTライブラリーがキ
ャプチャセッションに対する完全なトレースデータを管
理させるためにダイナミックに生成されるようになり、
これによって活性サブセットのみが常にデバッガで照会
されてディスプレーされるようになる。例示的な実施形
態において、トレースディスプレーは、ビュー領域がト
レースデータから抽出される情報の他のフィールドを示
すように命名された列に分類されるリストビューを含
む。トレースフィールドは、(i)タイムスタンプの情
報、(ii)プログラムカウンタのアドレス、(iii)現在ソ
ースの命令文(例えば、“C”またはアセンブラ言語)、
(iv)データアクセスのアドレス、(v)データのアクセス
値、(vi)実行“C”時間(例えば、評価が用いられる状況
下でオプコード命令が実行される周期の数)、(vii)例え
ば、トレースFIFOがオーバーフローされることのような
例外的なイベントを含むが、それらに限定されるもので
はない。
【0231】トレースディスプレーはディスプレーされ
るフィールドのうち、任意のフィールド上での検索も可
能である。また、ユーザーはキャプチャした2種類のト
レースイベント間の経過時間を測定するためにソフトウ
ェアを使用することができる。また、トレースビューは
命令トレースラインから、一例としてデバッガのソース
コードへのジャンプのためのオプションを具備した、操
作可変付きメニューを使用する他のデバッガビューや隠
れたビューへのリンクを提供するように選択的に構成す
る。
るフィールドのうち、任意のフィールド上での検索も可
能である。また、ユーザーはキャプチャした2種類のト
レースイベント間の経過時間を測定するためにソフトウ
ェアを使用することができる。また、トレースビューは
命令トレースラインから、一例としてデバッガのソース
コードへのジャンプのためのオプションを具備した、操
作可変付きメニューを使用する他のデバッガビューや隠
れたビューへのリンクを提供するように選択的に構成す
る。
【0232】また、デバッガGUIは(1)トレース結果で
キャプチャされる色々なコード機能から消費された時間
の比較を可能にする統計ビュー、及び(2)ユーザーが客
体コードのシンボル表をブラウジングするための便利な
メカニズムを提供するように構成する。図11d及び図
11eはコード及び可変的なブラウジングに対する例を
それぞれ示す。コードブラウザーにおいて、ユーザーは
階層的なツリーから部分または機能名のうち、いずれか
を選択することができ、または現在選択した階層的なノ
ード内から個別的なソースラインを選択することができ
る。また、GUIに対するこの実施形態によりユーザーは
色々なセッション結果をオープンして他のセッションに
対して並べてオープンした等価のビューを見ることがで
きる。図11fは例示的なトレースデータ分析GUIを示
す。
キャプチャされる色々なコード機能から消費された時間
の比較を可能にする統計ビュー、及び(2)ユーザーが客
体コードのシンボル表をブラウジングするための便利な
メカニズムを提供するように構成する。図11d及び図
11eはコード及び可変的なブラウジングに対する例を
それぞれ示す。コードブラウザーにおいて、ユーザーは
階層的なツリーから部分または機能名のうち、いずれか
を選択することができ、または現在選択した階層的なノ
ード内から個別的なソースラインを選択することができ
る。また、GUIに対するこの実施形態によりユーザーは
色々なセッション結果をオープンして他のセッションに
対して並べてオープンした等価のビューを見ることがで
きる。図11fは例示的なトレースデータ分析GUIを示
す。
【0233】他のRTTユーザーインターフェースの特徴
はソースエディタで強調したコードブロックをフィルタ
リングするためのオプションを含む該当ビュー及びダイ
アローグの開示と、強調した対応するカテゴリーを有す
る総合的な統計を見せるためにトレースビューの一つの
ラインから統計ビューへの“迅速なジャンプ”を許す操
作可変付きメニューを含む。
はソースエディタで強調したコードブロックをフィルタ
リングするためのオプションを含む該当ビュー及びダイ
アローグの開示と、強調した対応するカテゴリーを有す
る総合的な統計を見せるためにトレースビューの一つの
ラインから統計ビューへの“迅速なジャンプ”を許す操
作可変付きメニューを含む。
【0234】キャプチャできるトレースデータのサイズ
は潜在的に非常に大きいために、過剰または異質的なデ
ータを隠すための一部メカニズムを提供することが重要
である。“異質的な”データの定義はユーザーにより定
まり、したがって完璧にユーザーの制御下にある。一実
施形態において、このような“データ隠し”は、一例と
して事後−キャプチャフィルターを提供するトレースデ
ータを永久に変える機能の方式に行われる。選択的に、
ビュー−特定のデータ隠しが提供されるが、ここでは一
例として費用がかからない色々なループ繰り返しが、説
明のための単一のトレースディスプレーラインにフォー
ルドされる。このような単一ラインはそれの意味を表す
ためにグラフィック的な表式(例えば、“+”シンボル
やそれと類似なもの)にコメントが付与される。このよ
うなフォールドされた部分は伝統的なユーザーインター
フェースメカニズムを通じてユーザーの意志通りに拡張
及び崩壊される。
は潜在的に非常に大きいために、過剰または異質的なデ
ータを隠すための一部メカニズムを提供することが重要
である。“異質的な”データの定義はユーザーにより定
まり、したがって完璧にユーザーの制御下にある。一実
施形態において、このような“データ隠し”は、一例と
して事後−キャプチャフィルターを提供するトレースデ
ータを永久に変える機能の方式に行われる。選択的に、
ビュー−特定のデータ隠しが提供されるが、ここでは一
例として費用がかからない色々なループ繰り返しが、説
明のための単一のトレースディスプレーラインにフォー
ルドされる。このような単一ラインはそれの意味を表す
ためにグラフィック的な表式(例えば、“+”シンボル
やそれと類似なもの)にコメントが付与される。このよ
うなフォールドされた部分は伝統的なユーザーインター
フェースメカニズムを通じてユーザーの意志通りに拡張
及び崩壊される。
【0235】トレースキャプチャの結果を表示させるた
めの有用な方法は、メモリーブラウザー、レジスタビュ
ー及び従来の隠れたオンラインデバッガビューと、活性
PCをトレースするソースコードビューアーを含む。GUI
制御インターフェースによりユーザーはトレースバッフ
ァを通じて逆方向及び順方向に進むことができ、ターゲ
ットシステムの状態はトレースバッファ内の選択された
地点ですぐ現在ディスプレーされる。
めの有用な方法は、メモリーブラウザー、レジスタビュ
ー及び従来の隠れたオンラインデバッガビューと、活性
PCをトレースするソースコードビューアーを含む。GUI
制御インターフェースによりユーザーはトレースバッフ
ァを通じて逆方向及び順方向に進むことができ、ターゲ
ットシステムの状態はトレースバッファ内の選択された
地点ですぐ現在ディスプレーされる。
【0236】以下、図12を参照して本発明のソフトウ
ェアドライバー構造についての一つの例示的な実施形態
を説明する。この実施形態においては、2つのI/Oイン
ターフェース、すなわちデバッガインターフェースとキ
ャプチャディバイスインターフェースがホストコンピュ
ータに提供されている。前述したように、デバッガイン
ターフェースはコンピュータと遠隔コアホストのデバッ
ガインターフェースとの間に両方向のリンクを提供す
る。キャプチャディバイスインターフェースは外部コン
ピュータと他の処理ディバイス及び、専用RTTキャプチ
ャディバイスとの間に両方向リンクを提供する。例え
ば、図12はインターフェースに結合されたアップスト
リーム及びダウンストリームの通信チャンネルを個別的
なチャンネルで表しているが、このようなチャンネルは
必要に応じて物理的な同一リンク上に構成できることは
勿論である。
ェアドライバー構造についての一つの例示的な実施形態
を説明する。この実施形態においては、2つのI/Oイン
ターフェース、すなわちデバッガインターフェースとキ
ャプチャディバイスインターフェースがホストコンピュ
ータに提供されている。前述したように、デバッガイン
ターフェースはコンピュータと遠隔コアホストのデバッ
ガインターフェースとの間に両方向のリンクを提供す
る。キャプチャディバイスインターフェースは外部コン
ピュータと他の処理ディバイス及び、専用RTTキャプチ
ャディバイスとの間に両方向リンクを提供する。例え
ば、図12はインターフェースに結合されたアップスト
リーム及びダウンストリームの通信チャンネルを個別的
なチャンネルで表しているが、このようなチャンネルは
必要に応じて物理的な同一リンク上に構成できることは
勿論である。
【0237】図12の構造1200はキャプチャディバ
イス1272からホストコンピュータ(例えば、PC)12
74でトレースパケットを伝送する。次に、RTTドライ
バーはパケットが局部メモリー及び/またはディスクに
格納される以前にパケットを圧縮解除する。RTTドライ
バーには圧縮解除のために、オリジナルELFコードファ
イルへのアクセスが提供される。RTTドライバーは実際
に照会されたトレース結果をデバッガソフトウェアに再
び提供するデータベースサーバーの役割をする。ここ
で、RTTドライバーにはオープンされた数個のトレース
セッションからの結果が同時に存在でき、それによりユ
ーザーは色々なトレースセッションの間の視覚的な比較
を行うことができるという点を注目するべきである。さ
らに、RTTドライバーはトレース結果のシリアライゼィ
ションを管理する。デバッガソフトウェアにより促進さ
れるRTTドライバーは、例えばディスクファイルに命名
される格納位置にセッション結果を格納されて、この格
納位置からのセッション結果のロードが可能になる。
イス1272からホストコンピュータ(例えば、PC)12
74でトレースパケットを伝送する。次に、RTTドライ
バーはパケットが局部メモリー及び/またはディスクに
格納される以前にパケットを圧縮解除する。RTTドライ
バーには圧縮解除のために、オリジナルELFコードファ
イルへのアクセスが提供される。RTTドライバーは実際
に照会されたトレース結果をデバッガソフトウェアに再
び提供するデータベースサーバーの役割をする。ここ
で、RTTドライバーにはオープンされた数個のトレース
セッションからの結果が同時に存在でき、それによりユ
ーザーは色々なトレースセッションの間の視覚的な比較
を行うことができるという点を注目するべきである。さ
らに、RTTドライバーはトレース結果のシリアライゼィ
ションを管理する。デバッガソフトウェアにより促進さ
れるRTTドライバーは、例えばディスクファイルに命名
される格納位置にセッション結果を格納されて、この格
納位置からのセッション結果のロードが可能になる。
【0238】また、本発明のRTTドライバーは次の機能
をカバーするように、包括的なアプリケーションプログ
ラミングインターフェース(API)、即ち(i)性能照会、(i
i)ターゲットデバッガインターフェースの登録、(iii)
セッションの構成、(iv)セッションの実行、(v)セッシ
ョンの管理、及び(vi)照会セッションのデータを提供す
る。このような態様について詳細に後述する。
をカバーするように、包括的なアプリケーションプログ
ラミングインターフェース(API)、即ち(i)性能照会、(i
i)ターゲットデバッガインターフェースの登録、(iii)
セッションの構成、(iv)セッションの実行、(v)セッシ
ョンの管理、及び(vi)照会セッションのデータを提供す
る。このような態様について詳細に後述する。
【0239】(i)性能照会−このAPIはRTTシステムのキ
ャプチャ性能に対する情報を総括的にリターンさせる。
この情報は、例示的なこの実施形態においては、合成し
たRTTユニットの仕様だけでなく、使用しているハード
ウェアによっても決定される。合成したRTTユニットの
仕様はターゲットデバッガインターフェースを使用する
ことにより、ターゲット構成レジスタから読み取られる
が、望みの場合には他のアプローチを使用することもで
きる。次のコードはこのような特徴を例示する:
ャプチャ性能に対する情報を総括的にリターンさせる。
この情報は、例示的なこの実施形態においては、合成し
たRTTユニットの仕様だけでなく、使用しているハード
ウェアによっても決定される。合成したRTTユニットの
仕様はターゲットデバッガインターフェースを使用する
ことにより、ターゲット構成レジスタから読み取られる
が、望みの場合には他のアプローチを使用することもで
きる。次のコードはこのような特徴を例示する:
【0240】(ii)ターゲットデバッガインターフェース
の登録−このAPIはデバッガRTTドライバーとのターゲッ
トデバッグインターフェースに対する処理の登録を行
う。記述した実施形態において、このような機能は2種
類の方式に具現できる。一つの方式はDLL/SO処理を利用
し、他の方式は選択的にDLL/SOライブラリーファイルへ
の列の経路を利用する。一例として:
の登録−このAPIはデバッガRTTドライバーとのターゲッ
トデバッグインターフェースに対する処理の登録を行
う。記述した実施形態において、このような機能は2種
類の方式に具現できる。一つの方式はDLL/SO処理を利用
し、他の方式は選択的にDLL/SOライブラリーファイルへ
の列の経路を利用する。一例として:
【0241】(iii)セッションの構成−このAPI機能セッ
トは次のトレースキャプチャセッションを達成させるセ
ットオプションに対する能力を提供する。構成可能なオ
プションは、パケットエンコーディングのどんなユニッ
トがRTTユニットにより使われるかを指定する圧縮スキ
ームを使用する。例示的な実施形態における選択は完全
なアドレスやデルタアドレスのいずれかであるが、本発
明に適当に他の形態のエンコーディングを使用できるこ
とは勿論である。次のコードはこのような機能を例示す
る:
トは次のトレースキャプチャセッションを達成させるセ
ットオプションに対する能力を提供する。構成可能なオ
プションは、パケットエンコーディングのどんなユニッ
トがRTTユニットにより使われるかを指定する圧縮スキ
ームを使用する。例示的な実施形態における選択は完全
なアドレスやデルタアドレスのいずれかであるが、本発
明に適当に他の形態のエンコーディングを使用できるこ
とは勿論である。次のコードはこのような機能を例示す
る:
【0242】また、活性トレースカテゴリーの記述をセ
ッション構成の一部分として提供する。その記述はトレ
ースのどんなカテゴリーがキャプチャされるのかを指定
し、命令、タイムスタンピング、データ及び待機状態の
トレースを含むトレースカテゴリーからの個別的な選択
を可能にする。これは次のコードを例示する:
ッション構成の一部分として提供する。その記述はトレ
ースのどんなカテゴリーがキャプチャされるのかを指定
し、命令、タイムスタンピング、データ及び待機状態の
トレースを含むトレースカテゴリーからの個別的な選択
を可能にする。これは次のコードを例示する:
【0243】また、セッションの構成はキャプチャバッ
ファがどのように使われるかを指定するために選択的に
構成できる。一つの例示的な実施形態に含まれる選択
は、次のコードに示すように、固定使用モードや循環使
用モードのうちいずれかにおけるバッファの使用であ
る:
ファがどのように使われるかを指定するために選択的に
構成できる。一つの例示的な実施形態に含まれる選択
は、次のコードに示すように、固定使用モードや循環使
用モードのうちいずれかにおけるバッファの使用であ
る:
【0244】また、トレースフィルター及びトリガーは
セッション構成の一部としても明示できる。特に、この
APIによりフィルター及びトリガーセットは次の例のよ
うに指定できる:
セッション構成の一部としても明示できる。特に、この
APIによりフィルター及びトリガーセットは次の例のよ
うに指定できる:
【0245】(iv)セッションの実行−このAPIによりト
レースセッションの実行が可能になる。一例は次の通り
である:
レースセッションの実行が可能になる。一例は次の通り
である:
【0246】(v)セッションの管理−このAPI機能のセッ
トによりセッションの結果は格納及びロードでき、要約
情報の照会が可能になる。一例は次の通りである:
トによりセッションの結果は格納及びロードでき、要約
情報の照会が可能になる。一例は次の通りである:
【0247】(vi)照会セッションのデータ−このような
API機能セットによるセッション結果は次の例に示すよ
うに、デバッガで照会及びブラウジングすることが可能
になる:
API機能セットによるセッション結果は次の例に示すよ
うに、デバッガで照会及びブラウジングすることが可能
になる:
【0248】モニターユニット以下、図13ないし図1
6を参照して、本発明のモニターユニット742を詳細
に説明する。前述したように、モニターブロックの一つ
の目的は、望まないトレース情報をフィルタリングして
除去することにより、チップの外でキャプチャディバイ
ス772に供給されるデータの量を減少させることにあ
る。
6を参照して、本発明のモニターユニット742を詳細
に説明する。前述したように、モニターブロックの一つ
の目的は、望まないトレース情報をフィルタリングして
除去することにより、チップの外でキャプチャディバイ
ス772に供給されるデータの量を減少させることにあ
る。
【0249】周知するように、IC上の追加的なI/Oピン
は製作の際、コストが大きく上昇する。しかし、本発明
におけるパケットポートの幅は低いコストのアプリケー
ションのため、できるだけ小さく作ることができる。こ
のようなシステムにおいて、パケットポートはチップの
外にRTTデータを伝送するためにボトルネック現象が生
じる。オーバーフローが発生しない(そして何らの情報
も損失されない)ことを保障する2種類の主要な解決策
が、このようなボトルネック現象に存在する。第1解決
策はバッファを増加させることにより、キャプチャユニ
ットへの伝送が発生する以前に殆どのデータがチップ上
にあるように許すことを含む。これは短いサイズのデー
タバーストから中間サイズのデータバーストに対するオ
ーバーフローは防止できるが、長い期間の高い帯域は、
バッファのサイズを増加させることがパケットポートを
通じて伝送されるデータの量を減少させないため、結局
オーバーフローするようになる。第2方法はユーザーが
モニターを用いて適切でないと決定したデータを廃棄さ
せることを含む。したがって、モニターユニットが記述
の例示的な実施形態で使われる間には、そのようなモニ
ターユニットが更に広範囲な発明を実行するのに必須で
はないということは勿論である。
は製作の際、コストが大きく上昇する。しかし、本発明
におけるパケットポートの幅は低いコストのアプリケー
ションのため、できるだけ小さく作ることができる。こ
のようなシステムにおいて、パケットポートはチップの
外にRTTデータを伝送するためにボトルネック現象が生
じる。オーバーフローが発生しない(そして何らの情報
も損失されない)ことを保障する2種類の主要な解決策
が、このようなボトルネック現象に存在する。第1解決
策はバッファを増加させることにより、キャプチャユニ
ットへの伝送が発生する以前に殆どのデータがチップ上
にあるように許すことを含む。これは短いサイズのデー
タバーストから中間サイズのデータバーストに対するオ
ーバーフローは防止できるが、長い期間の高い帯域は、
バッファのサイズを増加させることがパケットポートを
通じて伝送されるデータの量を減少させないため、結局
オーバーフローするようになる。第2方法はユーザーが
モニターを用いて適切でないと決定したデータを廃棄さ
せることを含む。したがって、モニターユニットが記述
の例示的な実施形態で使われる間には、そのようなモニ
ターユニットが更に広範囲な発明を実行するのに必須で
はないということは勿論である。
【0250】この実施形態のモニターユニット742は
前述したフラットナーユニット770からの出力を用い
て、どんな情報が有効であるかを決定する(また、それ
により生成ユニット744がどんなパケットを生成すべ
きかを決定する)。存在する個別的なモニターの数と、
それによるフィルタリングの複雑度とは、ビルドタイム
(build time)でユーザーにより選択的に構成可能であ
る。それぞれの個別的なモニターの動作は本明細書で詳
細に後述する。
前述したフラットナーユニット770からの出力を用い
て、どんな情報が有効であるかを決定する(また、それ
により生成ユニット744がどんなパケットを生成すべ
きかを決定する)。存在する個別的なモニターの数と、
それによるフィルタリングの複雑度とは、ビルドタイム
(build time)でユーザーにより選択的に構成可能であ
る。それぞれの個別的なモニターの動作は本明細書で詳
細に後述する。
【0251】本実施例のモニターは次のような機能、
即ち(i)プログラム可能な条件とバスとのモニタリン
グ、(ii)条件の充足時に、プログラム可能なアクション
の使用、(iii)範囲指定のフィルターを提供するため
に、例えば動作スクリーニングのような個別的なモニタ
ーの動作を結合する能力、(iv)色々なトレースの形態
(例えば、命令、タイミング及びデータ)の個別的なフィ
ルタリング、及び(v)変換ツールを使用して選択のため
のHDL/合成プログラム(例えば、Verilog)に転換を提供
するように構成する:。
即ち(i)プログラム可能な条件とバスとのモニタリン
グ、(ii)条件の充足時に、プログラム可能なアクション
の使用、(iii)範囲指定のフィルターを提供するため
に、例えば動作スクリーニングのような個別的なモニタ
ーの動作を結合する能力、(iv)色々なトレースの形態
(例えば、命令、タイミング及びデータ)の個別的なフィ
ルタリング、及び(v)変換ツールを使用して選択のため
のHDL/合成プログラム(例えば、Verilog)に転換を提供
するように構成する:。
【0252】一つの例示的な実施形態において、複数の
構成可能なモニターが設計の時提供され、ユーザーは例
えば0、2、4、6または8個のモニターを選択でき
る。仮に一つのモニターも選択されないと、モニターブ
ロックは相変らず存在するが、生成ユニット744に認
可されるダイナミックなイネーブル信号は常に活性され
る。モニターユニット(ら)742からの出力信号はフリ
ップ−フロップから直接駆動される。これは設計の好ま
しい分配を提供し、一般的に更に優れた合成結果を提供
する。しかし、そういうフリップ−フロップの使用は広
範囲な発明において重要なものではない。
構成可能なモニターが設計の時提供され、ユーザーは例
えば0、2、4、6または8個のモニターを選択でき
る。仮に一つのモニターも選択されないと、モニターブ
ロックは相変らず存在するが、生成ユニット744に認
可されるダイナミックなイネーブル信号は常に活性され
る。モニターユニット(ら)742からの出力信号はフリ
ップ−フロップから直接駆動される。これは設計の好ま
しい分配を提供し、一般的に更に優れた合成結果を提供
する。しかし、そういうフリップ−フロップの使用は広
範囲な発明において重要なものではない。
【0253】逆に、モニターブロックへの全ての入力は
登録した出力から流入しなければならない。これはまさ
に平らなブロックからの信号であるが、アクションポイ
ントが設計に併合されなければならないという例外の場
合がある。これは続けて研究するべき事項である。
登録した出力から流入しなければならない。これはまさ
に平らなブロックからの信号であるが、アクションポイ
ントが設計に併合されなければならないという例外の場
合がある。これは続けて研究するべき事項である。
【0254】それぞれのモニターは2つの入力バスで比
較する。一つの例示的な実施形態において、一つのバス
はユーザーがホストインターフェースを通じてプログラ
ムするレジスタ値であり、他のバスは平らなブロックか
らのバス出力に対する選択である。(やはりホストイン
ターフェースからプログラムされるレジスタを通じて)
選択可能な3つのバスは、例えば(i)命令アドレスバ
ス、(ii)データアドレスバス、(iii)LR、SR及びST命令
のためのデータ値がある。図13は第1実施例をグラフ
ィック的に示す。遅延ロードデータ(LD命令からのデー
タ)は一貫性のないリターン回数により本実施例でモニ
タリングされない。
較する。一つの例示的な実施形態において、一つのバス
はユーザーがホストインターフェースを通じてプログラ
ムするレジスタ値であり、他のバスは平らなブロックか
らのバス出力に対する選択である。(やはりホストイン
ターフェースからプログラムされるレジスタを通じて)
選択可能な3つのバスは、例えば(i)命令アドレスバ
ス、(ii)データアドレスバス、(iii)LR、SR及びST命令
のためのデータ値がある。図13は第1実施例をグラフ
ィック的に示す。遅延ロードデータ(LD命令からのデー
タ)は一貫性のないリターン回数により本実施例でモニ
タリングされない。
【0255】マルチプレクサ−の選択によりそれぞれの
モニターは前述した3つのバスのうちいずれかで4種類
の動作、すなわち≧、<、=、≠を行うことができる。
また、モニターによる比較は有効命令上で行われる時に
だけフィルタリングするので、出力は有効フラッグに結
合するべきである。これはこのような有効フラッグを生
成するために信号は平らなブロックからも出すと共に、
できるだけ入力バスのそれぞれに関連するためである。
モニターは前述した3つのバスのうちいずれかで4種類
の動作、すなわち≧、<、=、≠を行うことができる。
また、モニターによる比較は有効命令上で行われる時に
だけフィルタリングするので、出力は有効フラッグに結
合するべきである。これはこのような有効フラッグを生
成するために信号は平らなブロックからも出すと共に、
できるだけ入力バスのそれぞれに関連するためである。
【0256】生成ブロックに出力される3つのダイナミ
ックなイネーブル信号が存在し、それぞれの信号はそれ
ぞれのトレース形態、すなわち命令トレース、命令タイ
ミングトレース、及びデータトレースのためのものであ
る。それぞれのダイナミックなイネーブルはどんなモニ
ターの出力がイネーブルビットを制御するのに使われて
いるかを選択する別の制御レジスタを具備する。モニタ
ーはアドレス範囲の比較(機能を分類するのに有用であ
る)を行うために全て結合することができ、次のような
形態らのうち、いずれかにより作動できる: (i)開始−条件が真の時、イネーブルは停止条件が行わ
れるまで、“1”にセットされる。 (ii)停止−条件が真の時、イネーブルは開始条件が行わ
れるまで、“0”にセットされる。 (iii)許容−条件が真の時、イネーブルは“1”にセッ
トされ、そうでなければデフォルト値を取る(開始/停止
条件により)。 (iv)防止−条件が真の時、イネーブルは“0”にセット
され、そうでなければ(開始/停止条件により)デフォル
ト値を取る。
ックなイネーブル信号が存在し、それぞれの信号はそれ
ぞれのトレース形態、すなわち命令トレース、命令タイ
ミングトレース、及びデータトレースのためのものであ
る。それぞれのダイナミックなイネーブルはどんなモニ
ターの出力がイネーブルビットを制御するのに使われて
いるかを選択する別の制御レジスタを具備する。モニタ
ーはアドレス範囲の比較(機能を分類するのに有用であ
る)を行うために全て結合することができ、次のような
形態らのうち、いずれかにより作動できる: (i)開始−条件が真の時、イネーブルは停止条件が行わ
れるまで、“1”にセットされる。 (ii)停止−条件が真の時、イネーブルは開始条件が行わ
れるまで、“0”にセットされる。 (iii)許容−条件が真の時、イネーブルは“1”にセッ
トされ、そうでなければデフォルト値を取る(開始/停止
条件により)。 (iv)防止−条件が真の時、イネーブルは“0”にセット
され、そうでなければ(開始/停止条件により)デフォル
ト値を取る。
【0257】開始及び停止条件に関するイネーブルの状
態を登録するために一つのフリップ−フロップが使われ
る。論理アナライザーがトリガー上でデータをキャプチ
ャする場合も、同一な方式のトリガー信号が使われる。
トリガーはモニターらのうちいずれか(モニターらの結
合を含む)や外部ソース(アクションポイントブロックも
含む)から生成できる。本明細書で前述したARCコアの例
示的な場合には、データ値及びレジスタファイルの再書
き込みだけでなく命令及びデータアドレスバスをモニタ
リングするのに使われる選択的なデバッグ設備が提供さ
れる。アクションポイントは望みの条件が満たされた時
にコアをブレーキさせることができ、モニターの可能時
に結合されることができる。しかし、このようなアクシ
ョンポイントはモニターとは若干相違する。アクション
ポイントは多くの信号をトレースしてモニターに対する
要件をトレースするのに使われ、平らになったパイプラ
インを確認しない。したがって、PCとの比較においてコ
アをブレーキさせるように構成されたアクションポイン
トは、それがレジスタファイルの再書き込みをブレーキ
させるように構成される同一な瞬間にはトリガーしな
い。
態を登録するために一つのフリップ−フロップが使われ
る。論理アナライザーがトリガー上でデータをキャプチ
ャする場合も、同一な方式のトリガー信号が使われる。
トリガーはモニターらのうちいずれか(モニターらの結
合を含む)や外部ソース(アクションポイントブロックも
含む)から生成できる。本明細書で前述したARCコアの例
示的な場合には、データ値及びレジスタファイルの再書
き込みだけでなく命令及びデータアドレスバスをモニタ
リングするのに使われる選択的なデバッグ設備が提供さ
れる。アクションポイントは望みの条件が満たされた時
にコアをブレーキさせることができ、モニターの可能時
に結合されることができる。しかし、このようなアクシ
ョンポイントはモニターとは若干相違する。アクション
ポイントは多くの信号をトレースしてモニターに対する
要件をトレースするのに使われ、平らになったパイプラ
インを確認しない。したがって、PCとの比較においてコ
アをブレーキさせるように構成されたアクションポイン
トは、それがレジスタファイルの再書き込みをブレーキ
させるように構成される同一な瞬間にはトリガーしな
い。
【0258】前述したように、モニターユニットは、ト
レース実行が行われる以前に、色々な構成レジスタがホ
ストトレースを通じてユーザーにより構成することが必
要である。
レース実行が行われる以前に、色々な構成レジスタがホ
ストトレースを通じてユーザーにより構成することが必
要である。
【0259】モニターブロックに存在することを含ん
で、全てのRTTレジスタは二重にアクセスされ、補助レ
ジスタ空間にマッピングされる。これは、ホスト及びコ
アがレジスタへの他のチャンネルを具備してホストアク
セスが非強制的であるというのを意味する。さらに、こ
のようなレジスタの位置が定まるべきである。それぞれ
のモニターは少なくとも2つのレジスタを必要とする。
一つは構成のためのもので、他の一つは比較値のための
ものである。また、ダイナミックなそれぞれのイネーブ
ルは構成レジスタを必要とするべきである。
で、全てのRTTレジスタは二重にアクセスされ、補助レ
ジスタ空間にマッピングされる。これは、ホスト及びコ
アがレジスタへの他のチャンネルを具備してホストアク
セスが非強制的であるというのを意味する。さらに、こ
のようなレジスタの位置が定まるべきである。それぞれ
のモニターは少なくとも2つのレジスタを必要とする。
一つは構成のためのもので、他の一つは比較値のための
ものである。また、ダイナミックなそれぞれのイネーブ
ルは構成レジスタを必要とするべきである。
【0260】例示的な実施形態において、それぞれのモ
ニターは個別的に構成することができ、それに関連する
2つのレジスタを具備する。第1モニターレジスタはど
んなバスがモニタリングされ、どんな形態の比較が行わ
れるかを選択するために使用する。第2モニターレジス
タは比較値を含む。同一または同一でない動作を行う
時、符号なし32-ビット値がこのレジスタに記録され
なければならない。より大きいか同一及びより小さな動
作を行う時、必要とする値のネガティブが2の補充形態
に書き込まなければならない。これはモニターユニット
がターゲットクロックの速度を達成するようにするため
に必要である。
ニターは個別的に構成することができ、それに関連する
2つのレジスタを具備する。第1モニターレジスタはど
んなバスがモニタリングされ、どんな形態の比較が行わ
れるかを選択するために使用する。第2モニターレジス
タは比較値を含む。同一または同一でない動作を行う
時、符号なし32-ビット値がこのレジスタに記録され
なければならない。より大きいか同一及びより小さな動
作を行う時、必要とする値のネガティブが2の補充形態
に書き込まなければならない。これはモニターユニット
がターゲットクロックの速度を達成するようにするため
に必要である。
【0261】それぞれのダイナミックなケーブルは開
始、停止、許容及び防止のような4個の特性各々に対し
てモニターまたはモニター結合を選択するように構成レ
ジスタをさらに具備する。一つはトリガーのソース(ら)
を選択するためのもので、他の一つはトレースキャプチ
ャ以後にトリガーの発生を識別するためのものである。
始、停止、許容及び防止のような4個の特性各々に対し
てモニターまたはモニター結合を選択するように構成レ
ジスタをさらに具備する。一つはトリガーのソース(ら)
を選択するためのもので、他の一つはトレースキャプチ
ャ以後にトリガーの発生を識別するためのものである。
【0262】また平らなユニット770は実行履歴を再
構成するのに必要とするプロセッサのパイプラインから
必要とする信号を取り、これらを“平らに”して、特定
命令に関連する全ての信号が同一なクロック周期の間に
有効になる。これらの信号を生成ブロックに伝達する前
に、これらの信号はモニターユニット742に伝えられ
るが、ここでは、これらの信号の殆どはモニター自身が
実行のために取ったクロック周期番号により発送され
る。ゲート数についての高いコストを要するとしても、
モニターのダイナミックなフィルタリングが適切な命令
に影響を及ぼすように、これらの全ての信号を発送させ
る必要がある。ユーザーにより要求されるフィルタリン
グを行うために、これらの信号のうち、極めて一部はま
たモニターにより使われる。
構成するのに必要とするプロセッサのパイプラインから
必要とする信号を取り、これらを“平らに”して、特定
命令に関連する全ての信号が同一なクロック周期の間に
有効になる。これらの信号を生成ブロックに伝達する前
に、これらの信号はモニターユニット742に伝えられ
るが、ここでは、これらの信号の殆どはモニター自身が
実行のために取ったクロック周期番号により発送され
る。ゲート数についての高いコストを要するとしても、
モニターのダイナミックなフィルタリングが適切な命令
に影響を及ぼすように、これらの全ての信号を発送させ
る必要がある。ユーザーにより要求されるフィルタリン
グを行うために、これらの信号のうち、極めて一部はま
たモニターにより使われる。
【0263】下の表10はこの実施形態において、平ら
なユニットとモニターユニットの間で使われる例示的な
ポートインターフェース信号を並べたものである。全て
の信号は他に説明されないと登録した入力である。
なユニットとモニターユニットの間で使われる例示的な
ポートインターフェース信号を並べたものである。全て
の信号は他に説明されないと登録した入力である。
【0264】
【表10】
【0265】平らなユニット770からの信号はモニタ
ーユニット742により発送されるが、そうでない場
合、生成ユニット744に伝えられる前に変わらないで
残るようになる。モニターユニットの内部から生成され
る3個の付加的な信号、すなわちトレース形態のそれぞ
れのためのダイナミックイネーブルが存在する。これら
はフィルタリングを制御し、どんなパケット形態が生成
されるかを決定する。
ーユニット742により発送されるが、そうでない場
合、生成ユニット744に伝えられる前に変わらないで
残るようになる。モニターユニットの内部から生成され
る3個の付加的な信号、すなわちトレース形態のそれぞ
れのためのダイナミックイネーブルが存在する。これら
はフィルタリングを制御し、どんなパケット形態が生成
されるかを決定する。
【0266】下の表11はこの実施形態でモニターユニ
ットと生成ユニットの間で使われる例示的なポートイン
ターフェースの信号を並べたものである。
ットと生成ユニットの間で使われる例示的なポートイン
ターフェースの信号を並べたものである。
【0267】
【表11】
【0268】モニターの作用を構成するために使われた
レジスタは全てコア(例、前述したARCtangent A4プロ
セッサ)の補助レジスタ空間にマッピングされる。全て
のレジスタはプロセッサの実行中にホストの非強制アク
セスを許すデュアルアクセス構造である。
レジスタは全てコア(例、前述したARCtangent A4プロ
セッサ)の補助レジスタ空間にマッピングされる。全て
のレジスタはプロセッサの実行中にホストの非強制アク
セスを許すデュアルアクセス構造である。
【0269】表12はこの実施形態でモニターユニット
とコア内の適切なモジュールの間で使われる例示的なポ
ートインターフェース信号をリスト化したリストであ
る。全ての信号は他に説明されないと登録された入力で
ある。
とコア内の適切なモジュールの間で使われる例示的なポ
ートインターフェース信号をリスト化したリストであ
る。全ての信号は他に説明されないと登録された入力で
ある。
【0270】
【表12】
【0271】一つ以上のRTTシステムを実行させる構成
レジスタはRTT_regsと称される別のモジュールで維持
される。このようなレジスタ(またはそれらから誘導さ
れる信号)のうち一部は、生成ユニットが平らなユニッ
ト信号及びダイナミックイネーブルを通じて適時にそれ
らを受信する順序で、モニターを活性化させるのにかか
る適切な周期数を通じて発送されなければならない。表
13を参照しよう。
レジスタはRTT_regsと称される別のモジュールで維持
される。このようなレジスタ(またはそれらから誘導さ
れる信号)のうち一部は、生成ユニットが平らなユニッ
ト信号及びダイナミックイネーブルを通じて適時にそれ
らを受信する順序で、モニターを活性化させるのにかか
る適切な周期数を通じて発送されなければならない。表
13を参照しよう。
【0272】
【表13】
【0273】RTTシステムに存在するモニターの数はこ
の実施形態で2、4、6、または8の値を取れるNUM_M
ONITORS定数(rtt_optionsで定まる)により構成可能で
ある。MONITORS_EXIST定数を“偽り”にセットするこ
とにより、モニターを一つも持たない設計にすることも
可能である。この実施形態において、NUM_MONITORS定
数は2以下には落ちてはならなく、編集通報がコード内
の不正確なループ範囲により発生することもある。しか
し、推論される論理は相変らず正確である。
の実施形態で2、4、6、または8の値を取れるNUM_M
ONITORS定数(rtt_optionsで定まる)により構成可能で
ある。MONITORS_EXIST定数を“偽り”にセットするこ
とにより、モニターを一つも持たない設計にすることも
可能である。この実施形態において、NUM_MONITORS定
数は2以下には落ちてはならなく、編集通報がコード内
の不正確なループ範囲により発生することもある。しか
し、推論される論理は相変らず正確である。
【0274】DATA_TRACE定数は、RTTシステムがデータ
トレースに関するパケットを生成できるかを決定する。
これはモニターユニットのフィルタリング機能に影響を
及ぼす。データトレースのターンオンされることによ
り、モニターは命令アドレスバス、データアドレスバ
ス、及びlr、sr、stデータ値バスとの比較を行うことが
できる。データトレースがターンオフされると、モニタ
ーはひたすら命令アドレスバスとの比較のみを行うこと
ができる。
トレースに関するパケットを生成できるかを決定する。
これはモニターユニットのフィルタリング機能に影響を
及ぼす。データトレースのターンオンされることによ
り、モニターは命令アドレスバス、データアドレスバ
ス、及びlr、sr、stデータ値バスとの比較を行うことが
できる。データトレースがターンオフされると、モニタ
ーはひたすら命令アドレスバスとの比較のみを行うこと
ができる。
【0275】仮に命令タイミングトレースがTIMING_TR
ACE定数でイネーブルにならないと、タイミングトレー
スのダイナミックイネーブルが非活性状態に固定され、
モニターのうちいずれかにより影響を受けないべきであ
る。仮にデータトレースがDATA_TRACE定数にイネーブ
ルにならないならば、データトレースのダイナミックイ
ネーブルが非活性状態に固定されるはずであり、モニタ
ーらのうちいずれによっても影響を受けないべきであ
る。
ACE定数でイネーブルにならないと、タイミングトレー
スのダイナミックイネーブルが非活性状態に固定され、
モニターのうちいずれかにより影響を受けないべきであ
る。仮にデータトレースがDATA_TRACE定数にイネーブ
ルにならないならば、データトレースのダイナミックイ
ネーブルが非活性状態に固定されるはずであり、モニタ
ーらのうちいずれによっても影響を受けないべきであ
る。
【0276】定数MONITORS_PIPELINEDはどれくらい多
くのステージでモニターが実行されているかを決定す
る。セットされた時、モニターは2つのステージを必要
とし、全ての平らなユニット信号はそれによって発送さ
れ、そうでなければモニターは単一つのステージで実行
する。
くのステージでモニターが実行されているかを決定す
る。セットされた時、モニターは2つのステージを必要
とし、全ての平らなユニット信号はそれによって発送さ
れ、そうでなければモニターは単一つのステージで実行
する。
【0277】図14は単一モニターユニット742の構
造1400に対する他の例示的な実施形態を示す。この
実施形態のモニターユニットに対する構造は次のような
2つの異なる部分に分けられる:1)モニター自体のそれ
ぞれによる比較動作部、及び2)モニターが結合される
方式及びモニターがダイナミックなイネーブルレジスタ
上で有する動作部。
造1400に対する他の例示的な実施形態を示す。この
実施形態のモニターユニットに対する構造は次のような
2つの異なる部分に分けられる:1)モニター自体のそれ
ぞれによる比較動作部、及び2)モニターが結合される
方式及びモニターがダイナミックなイネーブルレジスタ
上で有する動作部。
【0278】データトレースがターンオフされた時、有
効な消失に対する比較を行うためにマルチプレクサ−1
402は任意のバスを選択する。比較を行うのに有効な
唯一のバスは命令アドレスバス1404である。
効な消失に対する比較を行うためにマルチプレクサ−1
402は任意のバスを選択する。比較を行うのに有効な
唯一のバスは命令アドレスバス1404である。
【0279】命令デコーダ1406は、モニターが比較
を行うために構成された命令のみによって活性されるこ
とを保障するために必要とする。命令アドレスバスに対
する比較を行う時、モニターの有効信号1408は常に
活性される。データアドレスやデータ値に対する比較を
行う時、モニター有効信号は、現在の命令形態がモニタ
ー条件レジスタ内の、命令形態のフラッグらのうちいず
れかと一致する場合にだけ活性される。
を行うために構成された命令のみによって活性されるこ
とを保障するために必要とする。命令アドレスバスに対
する比較を行う時、モニターの有効信号1408は常に
活性される。データアドレスやデータ値に対する比較を
行う時、モニター有効信号は、現在の命令形態がモニタ
ー条件レジスタ内の、命令形態のフラッグらのうちいず
れかと一致する場合にだけ活性される。
【0280】基準比較値1412はモニターの基準レジ
スタ(レジスタの定義を参照)から取られる、システムの
各モニターに対して一つの32ビットレジスタが存在す
る。
スタ(レジスタの定義を参照)から取られる、システムの
各モニターに対して一つの32ビットレジスタが存在す
る。
【0281】RTTユニットのモニターは図15に示した
ように1組または4組にも結合することができる。マル
チプレクサ−1502により選択された信号はモニター
制御レジスタによって決定されて、これに対しては付録
IIIに提供されていたレジスタ定義により説明する。
ように1組または4組にも結合することができる。マル
チプレクサ−1502により選択された信号はモニター
制御レジスタによって決定されて、これに対しては付録
IIIに提供されていたレジスタ定義により説明する。
【0282】モニター条件レジスタは、モニターがダイ
ナミックイネーブルを実行させることができる方法を決
定する。それには次のような4つのオプションが存在す
る:1)開始、2)停止、3)許容、及び4)遮断。ダイナ
ミックなそれぞれのイネーブルには2つのフリップ−フ
ロップ、すなわちダイナミックイネーブル自体、及びデ
フォルト値を保有するために使われる開始/停止フリッ
プ−フロップが連結される。ダイナミックイネーブル
は、“遮断”モニターが活性される場合には“0”とな
り、“許容”モニターが活性される場合には“1”とな
るべきである。仮に許容または遮断モニターのうち、ど
れも活性されないならば、ダイナミックイネーブルは開
始/停止フリップ−フロップからデフォルト値を取る。
“開始”フィルターは開始/停止フリップ−フロップ活
性をセットし、“停止”は開始/停止フリップ−フロッ
プを非活性にセットするべきである。
ナミックイネーブルを実行させることができる方法を決
定する。それには次のような4つのオプションが存在す
る:1)開始、2)停止、3)許容、及び4)遮断。ダイナ
ミックなそれぞれのイネーブルには2つのフリップ−フ
ロップ、すなわちダイナミックイネーブル自体、及びデ
フォルト値を保有するために使われる開始/停止フリッ
プ−フロップが連結される。ダイナミックイネーブル
は、“遮断”モニターが活性される場合には“0”とな
り、“許容”モニターが活性される場合には“1”とな
るべきである。仮に許容または遮断モニターのうち、ど
れも活性されないならば、ダイナミックイネーブルは開
始/停止フリップ−フロップからデフォルト値を取る。
“開始”フィルターは開始/停止フリップ−フロップ活
性をセットし、“停止”は開始/停止フリップ−フロッ
プを非活性にセットするべきである。
【0283】図16はダイナミックイネーブル上で結合
されたモニターの動作を示す。仮に一つ以上のモニター
が“許容”として動作し、一つ以上のモニターが“遮
断”として動作する所では衝突が起こり(または“開
始”と“停止”に対する衝突が起こる)、その時は最も
低いインデックスを有するモニターが優勢になる。
されたモニターの動作を示す。仮に一つ以上のモニター
が“許容”として動作し、一つ以上のモニターが“遮
断”として動作する所では衝突が起こり(または“開
始”と“停止”に対する衝突が起こる)、その時は最も
低いインデックスを有するモニターが優勢になる。
【0284】前述した実施形態において、また開始モニ
ターはダイナミックイネーブル活性化(開始/停止フリッ
プ−フロップと共に)を行う付加的な特性を持っている
ことにより、“開始”条件の満足とともに、トレースキ
ャプチャが発生する。停止モニターは開始/停止フリッ
プ−フロップにのみ影響を与えて、本質的に開始条件を
充足してから一周期が過ぎた後にトレースキャプチャを
停止させる。これは停止条件を引き起こす命令がトレー
ス(例えば、ある機能のj-リンク出口点)で相変らずキャ
プチャされるというのを意味する。
ターはダイナミックイネーブル活性化(開始/停止フリッ
プ−フロップと共に)を行う付加的な特性を持っている
ことにより、“開始”条件の満足とともに、トレースキ
ャプチャが発生する。停止モニターは開始/停止フリッ
プ−フロップにのみ影響を与えて、本質的に開始条件を
充足してから一周期が過ぎた後にトレースキャプチャを
停止させる。これは停止条件を引き起こす命令がトレー
ス(例えば、ある機能のj-リンク出口点)で相変らずキャ
プチャされるというのを意味する。
【0285】また、プロセッサ自体はモニター制御補助
レジスタに記録を行うことにより、開始/停止フリップ
−フロップに影響を及ぼすことができる。これは他のト
レース形態のデフォルト状態がホストコンピュータまた
はRTT認識運営体制により、トレースキャプチャが発生
する前にセットアップできるようにする。
レジスタに記録を行うことにより、開始/停止フリップ
−フロップに影響を及ぼすことができる。これは他のト
レース形態のデフォルト状態がホストコンピュータまた
はRTT認識運営体制により、トレースキャプチャが発生
する前にセットアップできるようにする。
【0286】付録IIIはこの実施形態で使われる例示的
なモニターレジスタに対する詳細な情報及び定義を提供
している。
なモニターレジスタに対する詳細な情報及び定義を提供
している。
【0287】パケットポート前述したように、パケット
ポート772の主目的はチップの外のトレース情報を一
つ以上の外部キャプチャユニットに伝送することであ
る。パケットポートはバッファからトレース情報を受信
する役割を担い、このトレース情報が所定のプロトコル
に従うようにして外部キャプチャユニットがトレース履
歴を再構成できるようにする。生成ユニットから出力さ
れた全てのトレース情報はキャプチャユニットによって
見られるようになる。
ポート772の主目的はチップの外のトレース情報を一
つ以上の外部キャプチャユニットに伝送することであ
る。パケットポートはバッファからトレース情報を受信
する役割を担い、このトレース情報が所定のプロトコル
に従うようにして外部キャプチャユニットがトレース履
歴を再構成できるようにする。生成ユニットから出力さ
れた全てのトレース情報はキャプチャユニットによって
見られるようになる。
【0288】本発明に係るパケットポートの例示的な実
施形態は(i)構成可能なポートの幅、(ii)キャプチャク
ロックの提供、(iii)データストリームが所定のプロト
コルに符合させる、及び(iv)変換道具を活用して選択し
たHDL/合成プログラム(例、Verilogで翻訳のような機能
性を提供する。また、典型的なパケットポートはまたマ
ルチコアトレースが単一パケットポートを通じてストリ
ーミングできるように設計される。
施形態は(i)構成可能なポートの幅、(ii)キャプチャク
ロックの提供、(iii)データストリームが所定のプロト
コルに符合させる、及び(iv)変換道具を活用して選択し
たHDL/合成プログラム(例、Verilogで翻訳のような機能
性を提供する。また、典型的なパケットポートはまたマ
ルチコアトレースが単一パケットポートを通じてストリ
ーミングできるように設計される。
【0289】更に詳細に後述するように、また、例示的
な実施形態は有利にも少ないプロトコル変更を利用して
パケットポートの幅を1ピンに容易に縮小させる能力を
提供する。
な実施形態は有利にも少ないプロトコル変更を利用して
パケットポートの幅を1ピンに容易に縮小させる能力を
提供する。
【0290】図17に示すように、例示的な実施形態の
パケットポートの構造1700はFIFO902からの出力
を受信し、有効でないデータをフィルタリングする。こ
の構造1700は平行構造で配列された複数ノーマルチ
プレクサ−1704からなり、パケットポートピンの各
ニップルに一つノーマルチプレクサ−が割り当てられ
る。各パケットポートニブルはFIFO出力にあるデータの
各ニブルからの入力、いわゆる“ニブルスタッフィン
グ”を必要とする場合、0xF(“1111”)値を取るこ
とができる。他の構成を用いることもできるが、前述し
た実施形態でポートピンの個数は4の倍数(すなわち、
4、8、16等)でなければならない。
パケットポートの構造1700はFIFO902からの出力
を受信し、有効でないデータをフィルタリングする。こ
の構造1700は平行構造で配列された複数ノーマルチ
プレクサ−1704からなり、パケットポートピンの各
ニップルに一つノーマルチプレクサ−が割り当てられ
る。各パケットポートニブルはFIFO出力にあるデータの
各ニブルからの入力、いわゆる“ニブルスタッフィン
グ”を必要とする場合、0xF(“1111”)値を取るこ
とができる。他の構成を用いることもできるが、前述し
た実施形態でポートピンの個数は4の倍数(すなわち、
4、8、16等)でなければならない。
【0291】RTTデータストリームの圧縮を解除するた
めに、セグメント開始パケットは外部キャッチャ装置に
より認められるように作られる。一つのセグメントにあ
る全ての順次的なパケットはセグメント開始パケットに
ある絶対データ値に対してエンコーディングされたデー
タを持つ。したがって、前述した例示的な構造1700
で4つのゼロ値のニブルはセグメント開始パケットより
前に置かれるようになる。これは後者がデータストリー
ムの中間に埋もれていても、外部キャプチャ装置がセグ
メント開始イベントを認識するように助ける。したがっ
て、例示的なRTTプロトコルで4つのゼロ値のニブルは
絶対トレースパケット内で表れてはだめで、これはニブ
ルスタッフィングによって達成される。具体的に、パケ
ットポートはトレースパケット内で3つの連続的なゼロ
値のニブルと会うようになれば、データストリーム内に
余分のニブル値0xF(“1111”)を挿入する。これは
次(4番目)のニブルがゼロの場合、前述したプロトコル
が違反でないというのを保障するようになる。ニブルス
タッフィングは4番目のニブル値がゼロでもそうでなく
とも発生する。図18はこの工程を図示的に示す。
めに、セグメント開始パケットは外部キャッチャ装置に
より認められるように作られる。一つのセグメントにあ
る全ての順次的なパケットはセグメント開始パケットに
ある絶対データ値に対してエンコーディングされたデー
タを持つ。したがって、前述した例示的な構造1700
で4つのゼロ値のニブルはセグメント開始パケットより
前に置かれるようになる。これは後者がデータストリー
ムの中間に埋もれていても、外部キャプチャ装置がセグ
メント開始イベントを認識するように助ける。したがっ
て、例示的なRTTプロトコルで4つのゼロ値のニブルは
絶対トレースパケット内で表れてはだめで、これはニブ
ルスタッフィングによって達成される。具体的に、パケ
ットポートはトレースパケット内で3つの連続的なゼロ
値のニブルと会うようになれば、データストリーム内に
余分のニブル値0xF(“1111”)を挿入する。これは
次(4番目)のニブルがゼロの場合、前述したプロトコル
が違反でないというのを保障するようになる。ニブルス
タッフィングは4番目のニブル値がゼロでもそうでなく
とも発生する。図18はこの工程を図示的に示す。
【0292】また、例示的な実施形態において、パケッ
トポート772は他の同期スキームが使われることがで
きると認識されても、キャプチャユニットにより提供さ
れたクロック信号に同期化する。システムクロックが既
存のピンに対してモニターできるならば、この信号はデ
ータキャプチャを同期化するためにキャプチャユニット
により使われることができる。ゲートされたクロックは
より“知能的”でないキャプチャ装置からナルデータを
フィルタリングする役割をなくしてくれるパケットポー
トによって選択的に提供されることができる。図19に
示すように、キャプチャクロックはパケットポートピン
に有効なデータがある時にのみ変化する。外部キャプチ
ャユニットはパケットポートクロックの下降エッジでデ
ータをサンプリングする。これはデータが単にクロック
の上昇エッジでだけ変化するために、適切なセット及び
維持時間を保障してくれる。
トポート772は他の同期スキームが使われることがで
きると認識されても、キャプチャユニットにより提供さ
れたクロック信号に同期化する。システムクロックが既
存のピンに対してモニターできるならば、この信号はデ
ータキャプチャを同期化するためにキャプチャユニット
により使われることができる。ゲートされたクロックは
より“知能的”でないキャプチャ装置からナルデータを
フィルタリングする役割をなくしてくれるパケットポー
トによって選択的に提供されることができる。図19に
示すように、キャプチャクロックはパケットポートピン
に有効なデータがある時にのみ変化する。外部キャプチ
ャユニットはパケットポートクロックの下降エッジでデ
ータをサンプリングする。これはデータが単にクロック
の上昇エッジでだけ変化するために、適切なセット及び
維持時間を保障してくれる。
【0293】テスト構造及び方法論本発明のRTTはプロ
グラム実行中にコアの非−妨害の観測を支持する。前述
したように、例示的な実施形態のRTTは命令トレース、
データトレース、イベントトレース及びタイミングトレ
ース情報のような4種類のトレース情報をキャプチャす
る。平らなユニット770は可能なトレース形態と関連
する変化を検出するためにプロセッサの状態を観測して
外部信号を選択する。トレース情報は生成ユニット74
4に伝送する前に、ユーザーセットに対するトレース情
報をダイナミックにフィルタリングするモニターユニッ
ト742に伝送される。また、モニターユニットはトリ
ガーを生成する。生成ユニット744は内部状態(例え
ば、カウンタ)を更新してパケットを生成することによ
りトレース情報を記録する。バッファ712はパケット
を格納して格納装置に伝送する。バッファの格納容量が
多過ぎると、インタラプトがコアに選択的に伝送され
る。制御ユニット746はRTTの動作制御に使われる補
助レジスタ及び状態装置を含む。
グラム実行中にコアの非−妨害の観測を支持する。前述
したように、例示的な実施形態のRTTは命令トレース、
データトレース、イベントトレース及びタイミングトレ
ース情報のような4種類のトレース情報をキャプチャす
る。平らなユニット770は可能なトレース形態と関連
する変化を検出するためにプロセッサの状態を観測して
外部信号を選択する。トレース情報は生成ユニット74
4に伝送する前に、ユーザーセットに対するトレース情
報をダイナミックにフィルタリングするモニターユニッ
ト742に伝送される。また、モニターユニットはトリ
ガーを生成する。生成ユニット744は内部状態(例え
ば、カウンタ)を更新してパケットを生成することによ
りトレース情報を記録する。バッファ712はパケット
を格納して格納装置に伝送する。バッファの格納容量が
多過ぎると、インタラプトがコアに選択的に伝送され
る。制御ユニット746はRTTの動作制御に使われる補
助レジスタ及び状態装置を含む。
【0294】前述したように、平らなユニット770は
コア(例えば、ARC)パイプラインの全てのパイプライン
の効果を除去する。平らなユニット770の出力は本質
的にパイプラインのないプロセッサの出力のように見え
る。平らなユニットは命令またはインタラプトがパイプ
ラインの特別な状態(すなわち、例示的なARCパイプライ
ンで4ステップまたは再書き込みステップ)にある時、
命令またはインタラプトに関連する全ての情報を含む。
コアパイプラインは第1、2及び3ステップで、命令ま
たはインタラプトに関連する情報を生成するが、平らな
ユニットはこの情報を生成する時に格納し、関連命令ま
たはインタラプトがパイプラインに出される時にコアパ
イプラインに出される。
コア(例えば、ARC)パイプラインの全てのパイプライン
の効果を除去する。平らなユニット770の出力は本質
的にパイプラインのないプロセッサの出力のように見え
る。平らなユニットは命令またはインタラプトがパイプ
ラインの特別な状態(すなわち、例示的なARCパイプライ
ンで4ステップまたは再書き込みステップ)にある時、
命令またはインタラプトに関連する全ての情報を含む。
コアパイプラインは第1、2及び3ステップで、命令ま
たはインタラプトに関連する情報を生成するが、平らな
ユニットはこの情報を生成する時に格納し、関連命令ま
たはインタラプトがパイプラインに出される時にコアパ
イプラインに出される。
【0295】RTTの平らなユニット770をテストする
のに使用する例示的なテストコードシナリオは付録Vに
提示する。
のに使用する例示的なテストコードシナリオは付録Vに
提示する。
【0296】RTTのモニターユニット742は平らなユ
ニット770からの出力を取り、情報が有効であるか、
またそれによって生成ユニット744がどんなパケット
を生成しなければならないかを決定する。存在する各モ
ニターの個数及びそれによるフィルタリングの複雑性は
構築時にユーザーによって構成可能である。付録VIは動
作中にRTTモニターユニット742に対して行われる規
定されたテストの例示的なセットを示す。付録VIのテー
ブルにある各列は多様なモニターが反応できる可能な組
合の範囲を提供するために、モニターがどのように構成
されるかを示す一つのテストに該当する。付録VIに示し
たことより、更に多くのフィルター組合が可能だと考え
られるが、示した例示的な組合は機能性及び強度に対し
て優れた範囲を提供する。
ニット770からの出力を取り、情報が有効であるか、
またそれによって生成ユニット744がどんなパケット
を生成しなければならないかを決定する。存在する各モ
ニターの個数及びそれによるフィルタリングの複雑性は
構築時にユーザーによって構成可能である。付録VIは動
作中にRTTモニターユニット742に対して行われる規
定されたテストの例示的なセットを示す。付録VIのテー
ブルにある各列は多様なモニターが反応できる可能な組
合の範囲を提供するために、モニターがどのように構成
されるかを示す一つのテストに該当する。付録VIに示し
たことより、更に多くのフィルター組合が可能だと考え
られるが、示した例示的な組合は機能性及び強度に対し
て優れた範囲を提供する。
【0297】生成ユニット744に対して、テストは付
録VIIに示すように構成される。
録VIIに示すように構成される。
【0298】バッファ712及びパケットポート772
に対して、テストは付録VIIIに示すように構成される。
に対して、テストは付録VIIIに示すように構成される。
【0299】制御ユニット746はRTTユニットにより
使われる全ての補助レジスタからなる。レジスタによっ
て、制御ユニットにあるレジスタには例示的な実施形態
で可能なソース3つまでが書き込まれるが、このソース
はコア、ホスト及びRTTユニットである。制御ユニット
746内で、全ての読み取り/書き込み動作及び各レジ
スタの機能性は選択的にテストされる。HMSL(Hyperscri
pt markup language)またはこれと同様なスクリプトが
ホストポートを通じて全ての制御レジスタに読み取り/
書き込みを行うために例示的な実施形態で使われる。H
MSLはまた“単一ステップ”で使われ、RTTを手動で
再活性化させることができる。しかし、他のスクリプト
または言語を使用して同一な効果を提供することもでき
る。
使われる全ての補助レジスタからなる。レジスタによっ
て、制御ユニットにあるレジスタには例示的な実施形態
で可能なソース3つまでが書き込まれるが、このソース
はコア、ホスト及びRTTユニットである。制御ユニット
746内で、全ての読み取り/書き込み動作及び各レジ
スタの機能性は選択的にテストされる。HMSL(Hyperscri
pt markup language)またはこれと同様なスクリプトが
ホストポートを通じて全ての制御レジスタに読み取り/
書き込みを行うために例示的な実施形態で使われる。H
MSLはまた“単一ステップ”で使われ、RTTを手動で
再活性化させることができる。しかし、他のスクリプト
または言語を使用して同一な効果を提供することもでき
る。
【0300】RTTユニットのために開発されたテストコ
ードはシミュレーション状態で、及び性能観測のための
ハードウェアと共に使われることができる。シミュレー
ションにより生成された結果は同一なテストコードのた
めのハードウェアから生成された結果と比較するのに使
われる。例示的な実施形態において、2つのコア“ビル
ド”はRTTユニットをテストするのに使われる。第1の
構成はコアに対する最小のビルドオプションのみを含
む。第2の構成は最大可能ビルドオプションを含む。し
かし、多様なビルドオプションに対して他の組合が使わ
れることができ、例えば望みの機能及びオプションを相
違にセットした“部分的な”構成を含むこともできるべ
きである。表14はプロセッサコア(例えば、ARC)の例
示的な実施形態におけるビルドオプションを詳細に示
す。この例において、4個の異なるRTTユニット構成が
前述した最小及び最大オプションと共に使われた。
ードはシミュレーション状態で、及び性能観測のための
ハードウェアと共に使われることができる。シミュレー
ションにより生成された結果は同一なテストコードのた
めのハードウェアから生成された結果と比較するのに使
われる。例示的な実施形態において、2つのコア“ビル
ド”はRTTユニットをテストするのに使われる。第1の
構成はコアに対する最小のビルドオプションのみを含
む。第2の構成は最大可能ビルドオプションを含む。し
かし、多様なビルドオプションに対して他の組合が使わ
れることができ、例えば望みの機能及びオプションを相
違にセットした“部分的な”構成を含むこともできるべ
きである。表14はプロセッサコア(例えば、ARC)の例
示的な実施形態におけるビルドオプションを詳細に示
す。この例において、4個の異なるRTTユニット構成が
前述した最小及び最大オプションと共に使われた。
【0301】
【表14】
【0302】表15は例示的なRTTユニットビルドオプ
ションに関連する詳細内容を提供する。総合的に、八つ
(8)個の構成(コア+RTT)がVHDL/Verilog、他のシミュレ
ーター及びAA3/0.18技術と結合して使われることが
できる。この8つの相違するビルド全体はゲートカウン
ト及びクロック速度のために合成されて検証される。ま
た、他のコアのビルドオプションはこの構成らと共に結
合されることができる。
ションに関連する詳細内容を提供する。総合的に、八つ
(8)個の構成(コア+RTT)がVHDL/Verilog、他のシミュレ
ーター及びAA3/0.18技術と結合して使われることが
できる。この8つの相違するビルド全体はゲートカウン
ト及びクロック速度のために合成されて検証される。ま
た、他のコアのビルドオプションはこの構成らと共に結
合されることができる。
【0303】
【表15】
【0304】テストシステム(本発明の譲受人により製
造されたARCTestシステム等)は少なくともRTTテストの
サブセットを支持する。メモリーモジュールはシミュレ
ーションの結果と比較するために、あらかじめ初期化し
た結果を得るのに使われる。このテストは、例えば顧客
の信用確認またはQCを含む多様な用途のために使われる
ことができる。次のテストシステムの一部として含まれ
るこのテストは理想的に次のような全てのサブセットを
テストするように構成する。このサブセットは(i)生成
され記録されたRTTインタラプト、ZeroOverheadLp、条
件付き中止/分岐、データロード及びdldd、制御レジス
タ(ホスト)の読み取り/書き込み、制御レジスタ(コア)
の読み取り/書き込み、HMSLを通じた単一ステッピン
グ、モニターのダイナミック活性化、モニター及びトリ
ガー、及びプールトレースモードを含む。
造されたARCTestシステム等)は少なくともRTTテストの
サブセットを支持する。メモリーモジュールはシミュレ
ーションの結果と比較するために、あらかじめ初期化し
た結果を得るのに使われる。このテストは、例えば顧客
の信用確認またはQCを含む多様な用途のために使われる
ことができる。次のテストシステムの一部として含まれ
るこのテストは理想的に次のような全てのサブセットを
テストするように構成する。このサブセットは(i)生成
され記録されたRTTインタラプト、ZeroOverheadLp、条
件付き中止/分岐、データロード及びdldd、制御レジス
タ(ホスト)の読み取り/書き込み、制御レジスタ(コア)
の読み取り/書き込み、HMSLを通じた単一ステッピン
グ、モニターのダイナミック活性化、モニター及びトリ
ガー、及びプールトレースモードを含む。
【0305】ランダム命令発生機能(“ランダム命令の
生成装置及び方法”という名称で2001年11月5日
に同一の譲受人により出願されて、全文が本明細書に参
照として併合された米国特許仮出願番号第60/33
8、507号に開示された例示的なシステム及び方法
等)は本発明のRTTテストのためのランダム命令を生産す
るのに使われることができる。
生成装置及び方法”という名称で2001年11月5日
に同一の譲受人により出願されて、全文が本明細書に参
照として併合された米国特許仮出願番号第60/33
8、507号に開示された例示的なシステム及び方法
等)は本発明のRTTテストのためのランダム命令を生産す
るのに使われることができる。
【0306】表15に説明された4つのRTT構成は構成
ソフトウェア(例えば、前述した構造ソフトウェア)から
選択可能なデフォルトRTT構成で使われることができ
る。
ソフトウェア(例えば、前述した構造ソフトウェア)から
選択可能なデフォルトRTT構成で使われることができ
る。
【0307】図20はRTTユニットと結合されて使われ
るテストベンチの例示的な一つの構成を示す。テストベ
ンチはシミュレーション下でRTTをテストするのに使わ
れる。図20の“mon”機能2002はコアパイプライ
ン効果を除去し、圧縮解除されたデータをファイル(例
えば、*.atb)に格納する。RTTから得た圧縮されたデー
タは他のファイル(例えば、*.rtt)に格納される。第1
ソフトウェアアプリケーション2004(例えば、図2
0の代表的な例で“rttDisplay”)は圧縮されたRTTデー
タファイルを圧縮解除してテキストファイルの形成にお
いてトレースデータを生成するのに使われる。第2ソフ
トウェアアプリケーション2006(例えば、“atbDisp
lay”は圧縮解除されたデータファイルをテキストファ
イルに変換し、圧縮解除されたデータファイルと圧縮さ
れたファイルの圧縮解除バージョン間の知らされた差
(ら)を除去する。この2つのファイル間の差は複数の状
況で発生することがあるが、この状況は(i)ループが以
前のセグメントでセットアップされる時、多重セグメン
トを横切るゼロオーバーヘッドループ、(ii)タイミング
トレースのない遅延されたロード及び(iii)RTTが非活性
化した後、遅延ロードデータ(DLDD)の復帰(RTTトレース
がDLDDパケットを格納しない)を含む。
るテストベンチの例示的な一つの構成を示す。テストベ
ンチはシミュレーション下でRTTをテストするのに使わ
れる。図20の“mon”機能2002はコアパイプライ
ン効果を除去し、圧縮解除されたデータをファイル(例
えば、*.atb)に格納する。RTTから得た圧縮されたデー
タは他のファイル(例えば、*.rtt)に格納される。第1
ソフトウェアアプリケーション2004(例えば、図2
0の代表的な例で“rttDisplay”)は圧縮されたRTTデー
タファイルを圧縮解除してテキストファイルの形成にお
いてトレースデータを生成するのに使われる。第2ソフ
トウェアアプリケーション2006(例えば、“atbDisp
lay”は圧縮解除されたデータファイルをテキストファ
イルに変換し、圧縮解除されたデータファイルと圧縮さ
れたファイルの圧縮解除バージョン間の知らされた差
(ら)を除去する。この2つのファイル間の差は複数の状
況で発生することがあるが、この状況は(i)ループが以
前のセグメントでセットアップされる時、多重セグメン
トを横切るゼロオーバーヘッドループ、(ii)タイミング
トレースのない遅延されたロード及び(iii)RTTが非活性
化した後、遅延ロードデータ(DLDD)の復帰(RTTトレース
がDLDDパケットを格納しない)を含む。
【0308】ISS2010下で実行するテストコードは
別のソフトウェアアプリケーション(例えば、“scareTo
Atb”ソフトウェアアプリケーション)を使用する圧縮解
除されたデータファイル(例えば、*.atb)に変換された
一つまたはその以上の結果ファイル(例えば、*.iss)を
生成する。この生成された*.atbファイルは最終トレー
ステキストファイルを生成するためにatbDisplayにより
使われる。ScarcToAtbはISSデータから遅延ロードデー
タの効果を除去する。
別のソフトウェアアプリケーション(例えば、“scareTo
Atb”ソフトウェアアプリケーション)を使用する圧縮解
除されたデータファイル(例えば、*.atb)に変換された
一つまたはその以上の結果ファイル(例えば、*.iss)を
生成する。この生成された*.atbファイルは最終トレー
ステキストファイルを生成するためにatbDisplayにより
使われる。ScarcToAtbはISSデータから遅延ロードデー
タの効果を除去する。
【0309】この実施形態ではRTTの立証のために3つ
の相違する参照を使用する。 (i)バッファオーバーフローがない場合、rttDisplay及
びatbDisplayの出力は比較可能である。 (ii)バッファオーバーフローの場合、rttSimアプリケー
ション(RTTと等価のソフトウェア)は*.atbファイルから
*.rttファイルを生成するのに使われ、生成された2つ
のrttファイルは比較可能である。 (iii)ISS2010から生成されたファイルはRTT出力に
比較するための独立の参照経路となる。
の相違する参照を使用する。 (i)バッファオーバーフローがない場合、rttDisplay及
びatbDisplayの出力は比較可能である。 (ii)バッファオーバーフローの場合、rttSimアプリケー
ション(RTTと等価のソフトウェア)は*.atbファイルから
*.rttファイルを生成するのに使われ、生成された2つ
のrttファイルは比較可能である。 (iii)ISS2010から生成されたファイルはRTT出力に
比較するための独立の参照経路となる。
【0310】前述したソフトウェアモジュールは必要と
するトレースデータを生成するために他の命令ラインオ
プションで選択的に構成される。
するトレースデータを生成するために他の命令ラインオ
プションで選択的に構成される。
【0311】シミュレーション下で、独立ブロックレベ
ルテストのために、最小RTTモジュールは平らなユニッ
ト770及び生成ユニット744である。RTT702の
モニターユニット742及びバッファユニット712は
同一なテストのために平らなユニット及び生成ユニット
と共に一つずつ追加することができる。トレース情報は
このキャプチャされたデータを使用して生成されるべき
である。タイミングのトレースがないならば、RTTモジ
ュールはISS下で同一なコードを作動することにより立
証することができる。タイミングトレースに対して、全
てのタイミング情報はISSを獲得したまま結合できる前
述したモニター機能(“mon”)2002を用いて得るこ
とができる。ここに説明された例示的なモニター機能2
002は、他の構成を使用することもできるが、ModelS
im及びVHDLを支持する。したがって、VHDL及びModelSim
シミュレーション下で作動する時、モニター機能200
2から生成された全ての*.atbファイルは保存されるべ
きである。このファイルはVerilogシミュレーションを
含む他のシミュレーター上で追加の比較をする時、基本
となる。
ルテストのために、最小RTTモジュールは平らなユニッ
ト770及び生成ユニット744である。RTT702の
モニターユニット742及びバッファユニット712は
同一なテストのために平らなユニット及び生成ユニット
と共に一つずつ追加することができる。トレース情報は
このキャプチャされたデータを使用して生成されるべき
である。タイミングのトレースがないならば、RTTモジ
ュールはISS下で同一なコードを作動することにより立
証することができる。タイミングトレースに対して、全
てのタイミング情報はISSを獲得したまま結合できる前
述したモニター機能(“mon”)2002を用いて得るこ
とができる。ここに説明された例示的なモニター機能2
002は、他の構成を使用することもできるが、ModelS
im及びVHDLを支持する。したがって、VHDL及びModelSim
シミュレーション下で作動する時、モニター機能200
2から生成された全ての*.atbファイルは保存されるべ
きである。このファイルはVerilogシミュレーションを
含む他のシミュレーター上で追加の比較をする時、基本
となる。
【0312】前述したテストコードは開発ボード(本明
細書の譲受人により製造されるArcangl13TM開発ボー
ド等)上で作動するように、トレースデータをキャプチ
ャするために選択的に使われる論理アナライザーと共に
適用することができる。代案として、注文型キャプチャ
ポートが進んだトレースディスプレーと共に使われるこ
ともできる。
細書の譲受人により製造されるArcangl13TM開発ボー
ド等)上で作動するように、トレースデータをキャプチ
ャするために選択的に使われる論理アナライザーと共に
適用することができる。代案として、注文型キャプチャ
ポートが進んだトレースディスプレーと共に使われるこ
ともできる。
【0313】図21は全てのテストコードと前述したソ
フトウェアアプリケーション/スクリプトが格納された
例示的なデレクトリ構造を示す。テストは毎RTTユニッ
ト(例、平滑、モニター、生成、等)に分類され、これら
のユニットに対する機能性及び“コーナーケース”(“c
orner cases”)(すなわち、性能または他のパラメータ
に影響を及ぼすことができる、半導体工程に関連したこ
とのような、2つ以上のパラメータの組合)。各RTTユニ
ット下のファイルは次の事項を含むように構造化し、こ
れらはTest_name.hex、Test_name.out、Test_name.s
及びTest_name_ISS.atbである。Test_name_ISS.atb
はテストコードのISSシミュレーションから生成された
*.atbファイルであることを注目しなければならない。
共通フォルダーはVector_tableとMakefileのような全
てのテストに共通のファイルを含む。Makefileは全ての
RTTユニットの多様な他のテストコードをコンパイルす
るために全ての命令ラインオプションを含む。
フトウェアアプリケーション/スクリプトが格納された
例示的なデレクトリ構造を示す。テストは毎RTTユニッ
ト(例、平滑、モニター、生成、等)に分類され、これら
のユニットに対する機能性及び“コーナーケース”(“c
orner cases”)(すなわち、性能または他のパラメータ
に影響を及ぼすことができる、半導体工程に関連したこ
とのような、2つ以上のパラメータの組合)。各RTTユニ
ット下のファイルは次の事項を含むように構造化し、こ
れらはTest_name.hex、Test_name.out、Test_name.s
及びTest_name_ISS.atbである。Test_name_ISS.atb
はテストコードのISSシミュレーションから生成された
*.atbファイルであることを注目しなければならない。
共通フォルダーはVector_tableとMakefileのような全
てのテストに共通のファイルを含む。Makefileは全ての
RTTユニットの多様な他のテストコードをコンパイルす
るために全ての命令ラインオプションを含む。
【0314】図21の“汎用”フォルダーはテストシス
テムとRTTに統合されるテストファイルのサブセットを
含む。
テムとRTTに統合されるテストファイルのサブセットを
含む。
【0315】一つの例示的な実施形態において、各コア
の構成は統合された単一つのRTT構成を含んで、コア構
成とRTT構成間の1:1関係を維持する。テストコードは
コア構成デレクトリに統合されないで、他の位置に統合
される。テストコードは他のコア+RTT構成(すなわち、
“1対複数”の関係)のために使われることができる。
リンクはこれらの全てのテストコードを他のコア構成に
付着するために選択的に使われる。
の構成は統合された単一つのRTT構成を含んで、コア構
成とRTT構成間の1:1関係を維持する。テストコードは
コア構成デレクトリに統合されないで、他の位置に統合
される。テストコードは他のコア+RTT構成(すなわち、
“1対複数”の関係)のために使われることができる。
リンクはこれらの全てのテストコードを他のコア構成に
付着するために選択的に使われる。
【0316】デレクトリ構造の実施形態(図21)におい
て、シミュレーション下で実行される全てのテストはテ
ストコードデレクトリ自体(例、“mon.atb”)にその結
果を生成する。完了後、同一なことを他のデレクトリ
(例、BUILD/RTTデレクトリ)にコピーするためにスクリ
プトが使われ、コピー後にはテスト名が付加される。ま
た、生成された他のRTT/mon/ISSファイルの比較から生
成された結果は同一なBUILD/RTTデレクトリに格納され
る。
て、シミュレーション下で実行される全てのテストはテ
ストコードデレクトリ自体(例、“mon.atb”)にその結
果を生成する。完了後、同一なことを他のデレクトリ
(例、BUILD/RTTデレクトリ)にコピーするためにスクリ
プトが使われ、コピー後にはテスト名が付加される。ま
た、生成された他のRTT/mon/ISSファイルの比較から生
成された結果は同一なBUILD/RTTデレクトリに格納され
る。
【0317】また、コード適用範囲の道具がこの実施形
態で提供される。例示的な適用範囲の標準は以下で提供
される。 (i)命令文の適用範囲−テストベンチの実行途中に実行
されるプログラムの命令文の詳細事項を提供。各実行可
能な命令文(通知命令文とコメントは除外)はどれくらい
実行されたかを分かるためにテストされる。まだ実行さ
れていない命令文が識別される。 (ii)分岐の適用範囲−テストベンチにより実行された全
てのプログラム分岐の詳細事項を提供する。分岐は主に
IFとCASEブロックで発生して、これらのブロック内の条
件付き命令文の可能な結果に対応する。まだ実行されて
いない分岐が識別される。 (iii)条件の適用範囲−下位条件のどの組合が命令文を
真となるようにするかを分かるために条件付き命令文内
の特定下位−条件に対する検査が行われる。獲得されて
いないこのような任意の条件が識別される。 (iv)経路の適用範囲−テストベンチにより特定経路がHD
Lを通じて実行されたことを確認する。まだパスされて
いない経路が識別される。 (v)トリガーリングの適用範囲-VHDL内に書き込まれたモ
デルにのみ適用し、PROCESS及びWAIT命令文の認識
リストにある信号を伴う。命令文が変化する単一の信号
により、または信号の組合によりトリガーされるかを分
かるためにテストが行われる。トリガーされていない信
号が識別される。 (vi)信号トレース適用範囲−ユーザーが指定した信号セ
ットの値を含む。実行時間に信号のうち一つが変わるご
とに、モニターされる全ての信号の値が記録される。こ
れは実行途中に生成される信号値の組合の分析を可能と
する。 (vii)トグルの適用範囲−一つの信号が論理0から論理
1に変化した後、再び論理0に変わる時、または論理1
から0に、再び1に変わる時に得られて、行なわれない
回路領域の迅速で易しい識別を許す適用範囲の標準であ
る。 (viii)活動の適用範囲−シミュレーションの間信号が論
理値を変化させる回数のカウント値を提供する。このよ
うな設備は一つの回路内で、他の信号の相対的の活動に
対する情報を提供する。 (ix)排除の適用範囲−テスト下のHDLソースコードの選
択された領域が、テストリストのうち任意のことから排
除される。
態で提供される。例示的な適用範囲の標準は以下で提供
される。 (i)命令文の適用範囲−テストベンチの実行途中に実行
されるプログラムの命令文の詳細事項を提供。各実行可
能な命令文(通知命令文とコメントは除外)はどれくらい
実行されたかを分かるためにテストされる。まだ実行さ
れていない命令文が識別される。 (ii)分岐の適用範囲−テストベンチにより実行された全
てのプログラム分岐の詳細事項を提供する。分岐は主に
IFとCASEブロックで発生して、これらのブロック内の条
件付き命令文の可能な結果に対応する。まだ実行されて
いない分岐が識別される。 (iii)条件の適用範囲−下位条件のどの組合が命令文を
真となるようにするかを分かるために条件付き命令文内
の特定下位−条件に対する検査が行われる。獲得されて
いないこのような任意の条件が識別される。 (iv)経路の適用範囲−テストベンチにより特定経路がHD
Lを通じて実行されたことを確認する。まだパスされて
いない経路が識別される。 (v)トリガーリングの適用範囲-VHDL内に書き込まれたモ
デルにのみ適用し、PROCESS及びWAIT命令文の認識
リストにある信号を伴う。命令文が変化する単一の信号
により、または信号の組合によりトリガーされるかを分
かるためにテストが行われる。トリガーされていない信
号が識別される。 (vi)信号トレース適用範囲−ユーザーが指定した信号セ
ットの値を含む。実行時間に信号のうち一つが変わるご
とに、モニターされる全ての信号の値が記録される。こ
れは実行途中に生成される信号値の組合の分析を可能と
する。 (vii)トグルの適用範囲−一つの信号が論理0から論理
1に変化した後、再び論理0に変わる時、または論理1
から0に、再び1に変わる時に得られて、行なわれない
回路領域の迅速で易しい識別を許す適用範囲の標準であ
る。 (viii)活動の適用範囲−シミュレーションの間信号が論
理値を変化させる回数のカウント値を提供する。このよ
うな設備は一つの回路内で、他の信号の相対的の活動に
対する情報を提供する。 (ix)排除の適用範囲−テスト下のHDLソースコードの選
択された領域が、テストリストのうち任意のことから排
除される。
【0318】RTTモジュール702をテストするために
使われるテストコードは次の条件/イベントの適用範囲
を提供するために適用されるが、これらは(i)インタラ
プト(メモリーエラー、命令エラー、ユーザーインタラ
プト)、(ii)コア/補助/状態レジスタに読み取り/書き込
み、(iii)演算/論理の演算動作、(iv)単一被演算者の命
令、(v)ジャンプ命令、(vi)ジャンプ及び無効(nullify)
遅延スロット命令、(vii)ジャンプ及び実行遅延スロッ
トの命令、(viii)近接アドレスを有するジャンプ、(ix)
フラッグセットを有するジャンプ、(x)条件付きジャン
プ、(xi)分岐、(xii)条件付き分岐、(xiii)s/wブレーキ
ポイント、(xiv)直/間接ジャンプ、(xv)分岐/ジャンプ
及びリンク、(xvi)ゼロオーバーヘッドの単一命令ルー
プ、(xvii)分岐とジャンプを有するゼロオーバーヘッド
ループ、(xviii)ブレーキポイント命令を有するゼロオ
ーバーヘッドループ、(xix)長い/短い近接データを有
し、またループの底でlimmデータを構成するゼロオーバ
ーヘッドループ、(xx)休止命令、(xxi)拡張命令、(xxi
i)ロード/格納動作、(xxiii)補助レジスタ動作、(xxiv)
短い/長い近接データ及び目的地近接データの使用、(xx
v)単一ステップの命令、(xxvi)フラッグとフラッグセッ
トの命令、(xxvii)演算命令に対するインタラプト、(xx
viii)ジャンプ/分岐命令に対するインタラプト、(xxix)
ロード/格納命令に対するインタラプト、(xxx)補助レジ
スタアクセスに対するインタラプト、(xxxi)自己−変更
コード、及び(xxxii)RTTバッファオーバーフローISRsで
ある。
使われるテストコードは次の条件/イベントの適用範囲
を提供するために適用されるが、これらは(i)インタラ
プト(メモリーエラー、命令エラー、ユーザーインタラ
プト)、(ii)コア/補助/状態レジスタに読み取り/書き込
み、(iii)演算/論理の演算動作、(iv)単一被演算者の命
令、(v)ジャンプ命令、(vi)ジャンプ及び無効(nullify)
遅延スロット命令、(vii)ジャンプ及び実行遅延スロッ
トの命令、(viii)近接アドレスを有するジャンプ、(ix)
フラッグセットを有するジャンプ、(x)条件付きジャン
プ、(xi)分岐、(xii)条件付き分岐、(xiii)s/wブレーキ
ポイント、(xiv)直/間接ジャンプ、(xv)分岐/ジャンプ
及びリンク、(xvi)ゼロオーバーヘッドの単一命令ルー
プ、(xvii)分岐とジャンプを有するゼロオーバーヘッド
ループ、(xviii)ブレーキポイント命令を有するゼロオ
ーバーヘッドループ、(xix)長い/短い近接データを有
し、またループの底でlimmデータを構成するゼロオーバ
ーヘッドループ、(xx)休止命令、(xxi)拡張命令、(xxi
i)ロード/格納動作、(xxiii)補助レジスタ動作、(xxiv)
短い/長い近接データ及び目的地近接データの使用、(xx
v)単一ステップの命令、(xxvi)フラッグとフラッグセッ
トの命令、(xxvii)演算命令に対するインタラプト、(xx
viii)ジャンプ/分岐命令に対するインタラプト、(xxix)
ロード/格納命令に対するインタラプト、(xxx)補助レジ
スタアクセスに対するインタラプト、(xxxi)自己−変更
コード、及び(xxxii)RTTバッファオーバーフローISRsで
ある。
【0319】多重プロセッサの構成
以下、図22を参照して、関連する多重RTTs2202を
具備した集積回路2200の一つの例示的な実施形態を
説明する。図22の実施形態がASICまたはFPGAに関して
計画されたことであるが、単一のダイなおかまたは複数
のダイを含むかに関わらず、他の形態の集積回路が本発
明に適当に使われることができるというのを認識するべ
きである。
具備した集積回路2200の一つの例示的な実施形態を
説明する。図22の実施形態がASICまたはFPGAに関して
計画されたことであるが、単一のダイなおかまたは複数
のダイを含むかに関わらず、他の形態の集積回路が本発
明に適当に使われることができるというのを認識するべ
きである。
【0320】図22に示すように、集積回路2200
は、本明細書で前述した複数のRTTユニット2202を
含むが、RTTユニットは関連プロセッサコア要素220
5を含む。MTI(マルチコアトレースインターフェース)
ユニット2204はRTTユニット2202の出力に接続
され、その間でデータ通信するが、ここで仲裁ユニット
2206は各RTT2202からデータを受信し、一つの
チップ上の(または2つ以上のダイに分散された)複数の
RTTが一つ以上のバッファ及び/またはパケットポート
(ら)を共有することを許す。マルチプロセッサチップ
は、チップ上でプロセッサコア2205当たり一つのRT
Tを具備できるが、例えば単一RTTに多重化されたマルチ
コアなどのようなRTTユニット2202とコアの他の組
合が使われることができるということを分かっていなけ
ればならない。
は、本明細書で前述した複数のRTTユニット2202を
含むが、RTTユニットは関連プロセッサコア要素220
5を含む。MTI(マルチコアトレースインターフェース)
ユニット2204はRTTユニット2202の出力に接続
され、その間でデータ通信するが、ここで仲裁ユニット
2206は各RTT2202からデータを受信し、一つの
チップ上の(または2つ以上のダイに分散された)複数の
RTTが一つ以上のバッファ及び/またはパケットポート
(ら)を共有することを許す。マルチプロセッサチップ
は、チップ上でプロセッサコア2205当たり一つのRT
Tを具備できるが、例えば単一RTTに多重化されたマルチ
コアなどのようなRTTユニット2202とコアの他の組
合が使われることができるということを分かっていなけ
ればならない。
【0321】図22に示すように、MTI2204(仲裁ユ
ニット2206を含む)はパケットポート2209とそ
れぞれのRTT2202間で仲裁する。仲裁ユニット22
06は該当RTTを選択し、RTTのバッファ2210からMT
I2204にパケットを“放出”する。放出されたパケ
ットは共有バッファ2212が存在するとここに格納さ
れる。そうでない場合、放出されたパケットは直接MTI
2204のパケットポート2214に伝えられる。
ニット2206を含む)はパケットポート2209とそ
れぞれのRTT2202間で仲裁する。仲裁ユニット22
06は該当RTTを選択し、RTTのバッファ2210からMT
I2204にパケットを“放出”する。放出されたパケ
ットは共有バッファ2212が存在するとここに格納さ
れる。そうでない場合、放出されたパケットは直接MTI
2204のパケットポート2214に伝えられる。
【0322】MTI2204が使われる時、RTTs2202
はパケットポートの各ニブルに対してパケット-開始出
力信号を生成し、ポートストール入力信号を支援するよ
うに構成される。パケット出力信号(ら)の開始(rtt_pk
t_start)はMTI2204がパケット間の境界を容易に決
定するように許す。ポートストールまたは維持入力信号
(rtt_pkt_hold)により、衝突が発生する場合MTIが個
別RTTのパケットポートをストールさせる。
はパケットポートの各ニブルに対してパケット-開始出
力信号を生成し、ポートストール入力信号を支援するよ
うに構成される。パケット出力信号(ら)の開始(rtt_pk
t_start)はMTI2204がパケット間の境界を容易に決
定するように許す。ポートストールまたは維持入力信号
(rtt_pkt_hold)により、衝突が発生する場合MTIが個
別RTTのパケットポートをストールさせる。
【0323】また、MTI2204は各パケットが共有バ
ッファ2212にある時、これらの最終RTT識別フィー
ルドを付加する。識別子フィールドのサイズは一つの例
示的な実施形態において1ニブル(2ないし16RTTsに
対して)及び2ニブル(17ないし256RTTsに対して)
であるが、識別子フィールドの他の形態及び構成(また
は、パケットの発生を識別するための他のメカニズム
も)が使われることができるということを認識しなけれ
ばならない。例えば、識別子は別のビットまたはニブル
を含むことができるが、このような別途費用は他のRTT
−またはコア−が指定した情報を各パケットに関連させ
るために使われる。選択的に、識別子フィールドはパケ
ット境界の開始部(最後の反対となる)に付加できる。多
くの他の変形と置換が本発明に適当に可能である。
ッファ2212にある時、これらの最終RTT識別フィー
ルドを付加する。識別子フィールドのサイズは一つの例
示的な実施形態において1ニブル(2ないし16RTTsに
対して)及び2ニブル(17ないし256RTTsに対して)
であるが、識別子フィールドの他の形態及び構成(また
は、パケットの発生を識別するための他のメカニズム
も)が使われることができるということを認識しなけれ
ばならない。例えば、識別子は別のビットまたはニブル
を含むことができるが、このような別途費用は他のRTT
−またはコア−が指定した情報を各パケットに関連させ
るために使われる。選択的に、識別子フィールドはパケ
ット境界の開始部(最後の反対となる)に付加できる。多
くの他の変形と置換が本発明に適当に可能である。
【0324】本明細書で記述した例示的な集積回路ディ
バイス(実際に、明示的に記述されていない本発明の任
意の他の集積回路の実施形態)に対する設計は当業者に
公知された任意の数の論理合成技術を使用して合成でき
ることを認識できるべきである。ユーザーが注文できる
(すなわち、“soft”)命令セットを具備した集積回路の
論理を合成する一つの例示的な方法は、発明の名称が
“半導体設計の構成及び機能性を管理する方法及び装
置”であって1998年10月14日出願された米国仮
特許出願第60/104、271号を優先権と主張して
同一な発明の名称に1999年10月14日出願された
本出願人の共同係留中である米国特許出願第90/41
8、663号に開示されて、2つの出願明細書はその全
体本が本明細書に参照として併合された。しかし、他の
合成アプローチに代替される場合もある。このような方
法を使用して得られた注文型VHDL設計を使ってディバイ
スが製作され、その後、論理レベル表現に合成され、そ
の次に当業界ではよく知られているコンパイル、配置、
及び製作技術を使用して物理的なディバイスに変換され
る。例えば本発明は0.35、0.18及び0.1ミクロ
ン工程と互換され、窮極的に更に細かいか、他の解決策
の工程に適用されることができる。ディバイスの製作の
ための一つの例示的な工程は他のことも使われることが
できるが、IBM社が提供した0.1ミクロン“Blue Logi
c”Cu-11工程である。
バイス(実際に、明示的に記述されていない本発明の任
意の他の集積回路の実施形態)に対する設計は当業者に
公知された任意の数の論理合成技術を使用して合成でき
ることを認識できるべきである。ユーザーが注文できる
(すなわち、“soft”)命令セットを具備した集積回路の
論理を合成する一つの例示的な方法は、発明の名称が
“半導体設計の構成及び機能性を管理する方法及び装
置”であって1998年10月14日出願された米国仮
特許出願第60/104、271号を優先権と主張して
同一な発明の名称に1999年10月14日出願された
本出願人の共同係留中である米国特許出願第90/41
8、663号に開示されて、2つの出願明細書はその全
体本が本明細書に参照として併合された。しかし、他の
合成アプローチに代替される場合もある。このような方
法を使用して得られた注文型VHDL設計を使ってディバイ
スが製作され、その後、論理レベル表現に合成され、そ
の次に当業界ではよく知られているコンパイル、配置、
及び製作技術を使用して物理的なディバイスに変換され
る。例えば本発明は0.35、0.18及び0.1ミクロ
ン工程と互換され、窮極的に更に細かいか、他の解決策
の工程に適用されることができる。ディバイスの製作の
ための一つの例示的な工程は他のことも使われることが
できるが、IBM社が提供した0.1ミクロン“Blue Logi
c”Cu-11工程である。
【0325】図23は1ミクロン工程を用いて製作され
た例示的な集積回路ディバイスを示す。図23に示すよ
うに、ディバイス2300は特にトレースユニット23
02、パイプラインプロセッサコア2305(例、AR
C)、チップ上の“ローカル”バッファメモリー231
2、外部デバッグインターフェース2307、メモリー
インターフェース2313、及びパケットポート230
9を含む。このディバイスは前述した方法を使用して得
られた注文型VHDL設計を使用して製作され、次に論理レ
ベルの表現に合成され、その後、当業界ではよく知られ
ているコンパイル、配置、及び製作技術を使って物理的
なディバイスに変換される。
た例示的な集積回路ディバイスを示す。図23に示すよ
うに、ディバイス2300は特にトレースユニット23
02、パイプラインプロセッサコア2305(例、AR
C)、チップ上の“ローカル”バッファメモリー231
2、外部デバッグインターフェース2307、メモリー
インターフェース2313、及びパケットポート230
9を含む。このディバイスは前述した方法を使用して得
られた注文型VHDL設計を使用して製作され、次に論理レ
ベルの表現に合成され、その後、当業界ではよく知られ
ているコンパイル、配置、及び製作技術を使って物理的
なディバイスに変換される。
【0326】図23の集積回路ディバイス(本明細書で
後術するもの等もやはり)は、直列通信ディバイス、並
列ポート、タイマー、カウンタ、高電流ドライバー、A/
D変換機、D/A変換機、インタラプト処理機、LCDドライ
バー、ROM及び、他の類似な装置のように共通的に取得
可能な周辺装置を含むことができるということを当業者
であれば認識するべきである。また、プロセッサは他の
注文型またはアプリケーション指定回路を含む場合もあ
る。本発明は方法及び装置を使用して結合されることが
できる周辺装置及び他の回路の形態、数及び複雑度に限
らない。かえって、時間が経過することにより改善され
ている既存の半導体工程の物理的な容量が限定を加える
べきである。したがって、本発明を採用する集積の可能
な複雑度と程度は半導体工程が改善されるより増加する
べきである。
後術するもの等もやはり)は、直列通信ディバイス、並
列ポート、タイマー、カウンタ、高電流ドライバー、A/
D変換機、D/A変換機、インタラプト処理機、LCDドライ
バー、ROM及び、他の類似な装置のように共通的に取得
可能な周辺装置を含むことができるということを当業者
であれば認識するべきである。また、プロセッサは他の
注文型またはアプリケーション指定回路を含む場合もあ
る。本発明は方法及び装置を使用して結合されることが
できる周辺装置及び他の回路の形態、数及び複雑度に限
らない。かえって、時間が経過することにより改善され
ている既存の半導体工程の物理的な容量が限定を加える
べきである。したがって、本発明を採用する集積の可能
な複雑度と程度は半導体工程が改善されるより増加する
べきである。
【0327】多くのIC設計が現在マイクロプロセッサコ
アとDSPコアを使っていることを注目しなければならな
い。しかし、DSPは限定された数のDSP機能、またはICの
速いDMA構造にのみ対して必要とするべきである。本明
細書に開示された本発明はやはりそういう構造と互換さ
れる。更に、ここで開示された観測方法を用いてICのCP
UとDSP機能全てに対して大きい長所が具現される。
アとDSPコアを使っていることを注目しなければならな
い。しかし、DSPは限定された数のDSP機能、またはICの
速いDMA構造にのみ対して必要とするべきである。本明
細書に開示された本発明はやはりそういう構造と互換さ
れる。更に、ここで開示された観測方法を用いてICのCP
UとDSP機能全てに対して大きい長所が具現される。
【0328】方法
以下、図24aを参照して、プログラムの実行中に一つ
以上のプロセッサからトレースデータを獲得する方法が
本発明の前述した概念と記述される。次の説明が図1の
例示的な単一プロセッサRTTの実施形態に関して行われ
るが、他の実施形態(図7または図22のような)を用い
て一般的な方法が具現できるということは勿論である。
以上のプロセッサからトレースデータを獲得する方法が
本発明の前述した概念と記述される。次の説明が図1の
例示的な単一プロセッサRTTの実施形態に関して行われ
るが、他の実施形態(図7または図22のような)を用い
て一般的な方法が具現できるということは勿論である。
【0329】図24aに示すように、この方法は概略的
にまず、評価されるプロセッサからのデータを受信する
ように適用されたトレースユニット102を提供するス
テップを含む(ステップ2402)。またホストが例え
ば、デバッグポートを介してトレースユニット102と
間接的にインターフェースされ、プロセッサコアのホス
トインターフェースが前述したようにトレースされる
(ステップ2404)。その後、プロセッサの動作と関連
する複数のパケットがトレースユニットによりプロセッ
サから受信されたデータに基づいて生成される(ステッ
プ2406)。これらのパケットは共有バッファ112
に格納され(ステップ2408)、後続的にプロセッサの
動作と関連する情報を得るために読み取られて分析され
る(ステップ2410)。前述した方法の例示的な実施形
態において、トレースユニット102が4つの明確なト
レース(すなわち、命令、データ、タイミング及び雑多
な)の生成のために採択される。内部のモニターはトレ
ースユニット102に提供するためにプロセッサデータ
のキャプチャを制御する。トレースユニットはモニター
されるプロセッサから受信された入力(例えば、トレー
スユニットのレジスタ空間に書き込み)と、任意の外部
及びユーザー入力に基づいて、OFF、RUN及びTRIGGERED
動作状態の間で変化する。トレースユニットにより生成
されたパケットは、生成される情報とトレースの形態
と、ユーザー/設計者から受信された他の入力によって
フォーマットされて、共有バッファから誘導されるパケ
ットストリームの後続分析を手軽に行う。
にまず、評価されるプロセッサからのデータを受信する
ように適用されたトレースユニット102を提供するス
テップを含む(ステップ2402)。またホストが例え
ば、デバッグポートを介してトレースユニット102と
間接的にインターフェースされ、プロセッサコアのホス
トインターフェースが前述したようにトレースされる
(ステップ2404)。その後、プロセッサの動作と関連
する複数のパケットがトレースユニットによりプロセッ
サから受信されたデータに基づいて生成される(ステッ
プ2406)。これらのパケットは共有バッファ112
に格納され(ステップ2408)、後続的にプロセッサの
動作と関連する情報を得るために読み取られて分析され
る(ステップ2410)。前述した方法の例示的な実施形
態において、トレースユニット102が4つの明確なト
レース(すなわち、命令、データ、タイミング及び雑多
な)の生成のために採択される。内部のモニターはトレ
ースユニット102に提供するためにプロセッサデータ
のキャプチャを制御する。トレースユニットはモニター
されるプロセッサから受信された入力(例えば、トレー
スユニットのレジスタ空間に書き込み)と、任意の外部
及びユーザー入力に基づいて、OFF、RUN及びTRIGGERED
動作状態の間で変化する。トレースユニットにより生成
されたパケットは、生成される情報とトレースの形態
と、ユーザー/設計者から受信された他の入力によって
フォーマットされて、共有バッファから誘導されるパケ
ットストリームの後続分析を手軽に行う。
【0330】内部の格納ディバイスが使われると(図2
4b)、トレースユニットはRUN状態に置かれ(ステップ
2412)、RTT制御レジスタに書き込み等のトリガーリ
ングイベントに基づいて一つのトレースが共有バッファ
112内でキャプチャされる(ステップ2414)。ステ
ップ2416で、ホストはホストとトレースユニット間
のデバッグインターフェースまたは他のインターフェー
スを介してトレースデータを読み取る(非実時間)。
4b)、トレースユニットはRUN状態に置かれ(ステップ
2412)、RTT制御レジスタに書き込み等のトリガーリ
ングイベントに基づいて一つのトレースが共有バッファ
112内でキャプチャされる(ステップ2414)。ステ
ップ2416で、ホストはホストとトレースユニット間
のデバッグインターフェースまたは他のインターフェー
スを介してトレースデータを読み取る(非実時間)。
【0331】選択的に、外部の格納モードが選ばれると
(図24c)、トレースユニットはRUN状態に置かれ(ステ
ップ2420)、トレースユニット102によりパケッ
トが生成されてパケットポート109に接続されたキャ
プチャディバイスに伝達される(ステップ2422)。そ
の後、トレースがキャプチャされて共有バッファに格納
され(ステップ2424、2426)、共有バッファはパ
ケットポート109を介してキャプチャディバイスに放
出する(ステップ2428)。
(図24c)、トレースユニットはRUN状態に置かれ(ステ
ップ2420)、トレースユニット102によりパケッ
トが生成されてパケットポート109に接続されたキャ
プチャディバイスに伝達される(ステップ2422)。そ
の後、トレースがキャプチャされて共有バッファに格納
され(ステップ2424、2426)、共有バッファはパ
ケットポート109を介してキャプチャディバイスに放
出する(ステップ2428)。
【0332】本発明の特定態様が方法ステップの特定シ
ーケンスに関して記述されたが、これらの説明は本発明
の更に広い方法を例示するだけであり、特定アプリケー
ションが必要に応じて変更することができる。特定ステ
ップは特定状況下で要らないか、オプションになる場合
もある。付加的に特定ステップまたは機能が開示された
実施形態に添加するか、または2つ以上のステップの遂
行順序を置換することもできる。このような全ての変形
は本明細書で開示され、請求された本発明の範疇内に含
まれることと考えられる。
ーケンスに関して記述されたが、これらの説明は本発明
の更に広い方法を例示するだけであり、特定アプリケー
ションが必要に応じて変更することができる。特定ステ
ップは特定状況下で要らないか、オプションになる場合
もある。付加的に特定ステップまたは機能が開示された
実施形態に添加するか、または2つ以上のステップの遂
行順序を置換することもできる。このような全ての変形
は本明細書で開示され、請求された本発明の範疇内に含
まれることと考えられる。
【0333】詳細な説明が多様な実施形態に付加された
本発明の新しい特徴を図示、記述及び指摘したが、本発
明の範疇を外れることがなくても、当業者により示した
ディバイスまたは工程の形態及び詳細事項で多様な省
略、置換及び変更が行われることができるということを
分かることができるべきである。前述した説明は本発明
を行うのにおいて現在考慮される最適のモードである。
本説明は本発明を限定しようとすることではなく、かえ
って本発明の一般的な原理を説明するのに用いられるべ
きである。本発明の範疇は添付された特許請求の範囲を
参照して決定されなければならない。
本発明の新しい特徴を図示、記述及び指摘したが、本発
明の範疇を外れることがなくても、当業者により示した
ディバイスまたは工程の形態及び詳細事項で多様な省
略、置換及び変更が行われることができるということを
分かることができるべきである。前述した説明は本発明
を行うのにおいて現在考慮される最適のモードである。
本説明は本発明を限定しようとすることではなく、かえ
って本発明の一般的な原理を説明するのに用いられるべ
きである。本発明の範疇は添付された特許請求の範囲を
参照して決定されなければならない。
【0334】付録 I
詳細なパケットの説明
IA(命令アドレス)
IAパケットは間接ジャンプのターゲットPCを含む。フル
ターゲットPC値は24ビットだであるが、但し特異な部
分のみ記録される。
ターゲットPC値は24ビットだであるが、但し特異な部
分のみ記録される。
【0335】STF(格納、固定データサイズ)
STFパケットは格納命令に対する全ての情報を含む。こ
れは格納命令の実行時に生成される。現在のトレースオ
プションによって、パケットはデータアドレス、データ
値、セグメント命令のカウンタサイズ、及びセグメント
命令のカウンタを含むことができる。フルデータアドレ
スは32ビットであるが、例示的な実施例において特異
な部分だけ書き込まれる。データ値のサイズはSTB命令
に対して8ビットで、STW命令に対して16ビットで、
及びSTとSR命令に対して32ビットである。 STV(格納、可変データサイズ) STVパケットはデータ値フィールドが可変可能なサイズ
のものを除いてはSTFパケットと類似である。データ値
のサイズはパケット内に明示される。その場合にSTFパ
ケットが使われるはずであるので、データ値は決して8
ニブルではない。
れは格納命令の実行時に生成される。現在のトレースオ
プションによって、パケットはデータアドレス、データ
値、セグメント命令のカウンタサイズ、及びセグメント
命令のカウンタを含むことができる。フルデータアドレ
スは32ビットであるが、例示的な実施例において特異
な部分だけ書き込まれる。データ値のサイズはSTB命令
に対して8ビットで、STW命令に対して16ビットで、
及びSTとSR命令に対して32ビットである。 STV(格納、可変データサイズ) STVパケットはデータ値フィールドが可変可能なサイズ
のものを除いてはSTFパケットと類似である。データ値
のサイズはパケット内に明示される。その場合にSTFパ
ケットが使われるはずであるので、データ値は決して8
ニブルではない。
【0336】LDA(ロードアドレス)
LD(ロードアドレス)パケットはロード命令の実行時に生
成される。現在のトレースオプションよって、パケット
はデータアドレス、セグメント命令カウントの大きさ、
及びセグメント命令カウントを含むことができる。フル
データアドレスは32ビットであるが、但し特異な部分
のみ書き込まれる。
成される。現在のトレースオプションよって、パケット
はデータアドレス、セグメント命令カウントの大きさ、
及びセグメント命令カウントを含むことができる。フル
データアドレスは32ビットであるが、但し特異な部分
のみ書き込まれる。
【0337】LDD(ロードデータ)
LDDパケットはユーザーが、書き込まれるデータ値を使
用することができる場合、ロードデータがレジスタに書
き込まれる時に生成される。ロード命令が指令から外れ
てリターンする場合もあるので、ロード命令に対する宛
先レジスタフィールドを必要とする。もし“使用固定デ
ータ値のサイズ”フィールドが1であれば、ロードのサ
イズは操作符号に暗示され、“データ値のサイズ”フィ
ールドは省略される。暗示データ値のサイズはLDB命令
に対して8ビット、LDW命令に対して16ビット、LD及
びLR命令に対して32ビットである。もし“使用デフォ
ルトデータ値のサイズ”が1であれば、“データ値のサ
イズ”フィールドは省略される。もし“固定データ値の
サイズ”フィールドが1であれば、“使用デフォルトデ
ータ値のサイズ”フィールド値は0である。“ストール
命令カウンタ”フィールドはストール命令カウンタの値
を含む。LDDパケットの生成後にストール命令カウンタ
はゼロにセットされる。このフィールドはタイミングト
レースのイネーブル時に存在する。これにより、トレー
スデコーダはレジスタファイルに書き込まれるロードデ
ータの周期の決定を可能にする。ストール命令カウンタ
に対する更に詳細なことは詳述する微細タイミングの説
明を参照すればよい。
用することができる場合、ロードデータがレジスタに書
き込まれる時に生成される。ロード命令が指令から外れ
てリターンする場合もあるので、ロード命令に対する宛
先レジスタフィールドを必要とする。もし“使用固定デ
ータ値のサイズ”フィールドが1であれば、ロードのサ
イズは操作符号に暗示され、“データ値のサイズ”フィ
ールドは省略される。暗示データ値のサイズはLDB命令
に対して8ビット、LDW命令に対して16ビット、LD及
びLR命令に対して32ビットである。もし“使用デフォ
ルトデータ値のサイズ”が1であれば、“データ値のサ
イズ”フィールドは省略される。もし“固定データ値の
サイズ”フィールドが1であれば、“使用デフォルトデ
ータ値のサイズ”フィールド値は0である。“ストール
命令カウンタ”フィールドはストール命令カウンタの値
を含む。LDDパケットの生成後にストール命令カウンタ
はゼロにセットされる。このフィールドはタイミングト
レースのイネーブル時に存在する。これにより、トレー
スデコーダはレジスタファイルに書き込まれるロードデ
ータの周期の決定を可能にする。ストール命令カウンタ
に対する更に詳細なことは詳述する微細タイミングの説
明を参照すればよい。
【0338】PF(パス/フェイル状態)
PFパケットは条件付き命令のパスまたはフェイルの際、
それの条件コードのテストを示す。パス/フェイル状態
のビットはパスに対して1でフェイルに対して0であ
る。 USER(RTTにおけるUSERレジスタに対するSR) USERパケットはRTTにおけるUSER補助レジスタに対するS
R命令の実行時に生成される。書き込み値はパケットに
保存される。
それの条件コードのテストを示す。パス/フェイル状態
のビットはパスに対して1でフェイルに対して0であ
る。 USER(RTTにおけるUSERレジスタに対するSR) USERパケットはRTTにおけるUSER補助レジスタに対するS
R命令の実行時に生成される。書き込み値はパケットに
保存される。
【0339】STALL
STALLパケットは微細タイミングのイネーブル時コア(co
re)が命令を送り出すことができない毎周期に生成され
る。“命令カウンタ及び“ストール理由”フィールドの
存在はプログラム可能なレジスタにより独立的にイネー
ブルになる。“ストール命令カウンタ”フィールドはス
トール命令カウンタの値を含む。このカウンタは或るパ
ケットの生成時に0にセッティングされてトレースデコ
ーダに対するPC(例えば、IA、イネーブルなデータフィ
ルターリングを有するSTV/STV/LDA、PF、BCBIC、BCBICO
V、USER、SEGSTART、LPEND、またはINT)の決定を可能に
し、送り出された各命令に対して増分される。このフィ
ールドは正確な命令に対して決定されるストールの体験
を可能にする。もしストール命令カウンタがオーバーフ
ローすると、SICOVパケットが生成される。ストールパ
ケットの生成時、このストール命令カウンタはゼロにセ
ットされる。“ストール理由”フィールドのインコーデ
ィングは複数の他の接近を含む。これは命令キャッシュ
ミス、ロード使用(すなわち、データキャッシュミス)、
格納バッファフル、及びマルチ周期命令を含むストール
ソース(複数のソースである)を明示する。周期カウンタ
値は連続的なストール周期に対して増分される。もしス
トール理由が存在すれば、その理由は必ず増分のための
周期カウンタに対して同一でなければならない。周期カ
ウンタが増分またはオーバーフローを中止する時、STAL
Lパケットが生成される。もし、“周期カウンタ=1”の
フィールドが1であれば、“周期カウンタ値=1以下”
のフィールドが省略される。もし“命令カウンタ=1”
のフィールドが1であれば、“周期カウンタ値”のフィ
ールドは省略される。“カウンタ値=1以下”のフィー
ルドは1ないし16周期のストール値をエンコードす
る。
re)が命令を送り出すことができない毎周期に生成され
る。“命令カウンタ及び“ストール理由”フィールドの
存在はプログラム可能なレジスタにより独立的にイネー
ブルになる。“ストール命令カウンタ”フィールドはス
トール命令カウンタの値を含む。このカウンタは或るパ
ケットの生成時に0にセッティングされてトレースデコ
ーダに対するPC(例えば、IA、イネーブルなデータフィ
ルターリングを有するSTV/STV/LDA、PF、BCBIC、BCBICO
V、USER、SEGSTART、LPEND、またはINT)の決定を可能に
し、送り出された各命令に対して増分される。このフィ
ールドは正確な命令に対して決定されるストールの体験
を可能にする。もしストール命令カウンタがオーバーフ
ローすると、SICOVパケットが生成される。ストールパ
ケットの生成時、このストール命令カウンタはゼロにセ
ットされる。“ストール理由”フィールドのインコーデ
ィングは複数の他の接近を含む。これは命令キャッシュ
ミス、ロード使用(すなわち、データキャッシュミス)、
格納バッファフル、及びマルチ周期命令を含むストール
ソース(複数のソースである)を明示する。周期カウンタ
値は連続的なストール周期に対して増分される。もしス
トール理由が存在すれば、その理由は必ず増分のための
周期カウンタに対して同一でなければならない。周期カ
ウンタが増分またはオーバーフローを中止する時、STAL
Lパケットが生成される。もし、“周期カウンタ=1”の
フィールドが1であれば、“周期カウンタ値=1以下”
のフィールドが省略される。もし“命令カウンタ=1”
のフィールドが1であれば、“周期カウンタ値”のフィ
ールドは省略される。“カウンタ値=1以下”のフィー
ルドは1ないし16周期のストール値をエンコードす
る。
【0340】SICOV(オーバーフローされたストール命令
カウンタ) SICOVパケットはオーバーフローしたストール命令カウ
ンタを示す。カウンタの最大値が一定なので、このカウ
ンタの値はパケット内にない。 TSOV(オーバーフローされたタイムスタンプ) TSOVパケットはオーバーフローした16ビットタイムス
タンプを示す。これはタイムスタンピングがイネーブル
な時に生成される。TSOVパケットがパケットポートに伝
送されるに先立って、RTTはその以前に全てのゼロの少
なくとも4個のニブルがあることを保証する。このスキ
ームの実行で、外部キャプチャ装置はTSOVパケットの開
始を容易に見出せる。
カウンタ) SICOVパケットはオーバーフローしたストール命令カウ
ンタを示す。カウンタの最大値が一定なので、このカウ
ンタの値はパケット内にない。 TSOV(オーバーフローされたタイムスタンプ) TSOVパケットはオーバーフローした16ビットタイムス
タンプを示す。これはタイムスタンピングがイネーブル
な時に生成される。TSOVパケットがパケットポートに伝
送されるに先立って、RTTはその以前に全てのゼロの少
なくとも4個のニブルがあることを保証する。このスキ
ームの実行で、外部キャプチャ装置はTSOVパケットの開
始を容易に見出せる。
【0341】BCBIC(後方向条件付きブランチ命令カウン
タ) BCBICパケットはその条件コードのテストにおいて後方
向条件付きブランチ命令がフェイルしたことを示す。こ
のパケットはパスされたが、トレースに記録されていな
い後方向条件付きブランチ命令に対する多数のタイムの
カウントを含む。もし命令トレースが活性であれば、カ
ウンタは増分されるのみである。“カウンタは0”のフ
ィールドが1であれば、“カウンタ値”のフィールドは
省略される。 BCBICOV(オーバーフローされた後方向条件付きブランチ
命令カウンタ) BICICOVパケットはオーバーフローした後方向条件付き
ブランチ命令カウンタを示す。カウンタの最大値が一定
なので、このカウンタの値はパケット内にない。
タ) BCBICパケットはその条件コードのテストにおいて後方
向条件付きブランチ命令がフェイルしたことを示す。こ
のパケットはパスされたが、トレースに記録されていな
い後方向条件付きブランチ命令に対する多数のタイムの
カウントを含む。もし命令トレースが活性であれば、カ
ウンタは増分されるのみである。“カウンタは0”のフ
ィールドが1であれば、“カウンタ値”のフィールドは
省略される。 BCBICOV(オーバーフローされた後方向条件付きブランチ
命令カウンタ) BICICOVパケットはオーバーフローした後方向条件付き
ブランチ命令カウンタを示す。カウンタの最大値が一定
なので、このカウンタの値はパケット内にない。
【0342】APE(アクションポイントイベント)
APEパケットはアクションポイントイベントが発生した
ことを示す。もしタイムスタンピングがイネーブルであ
れば、タイムスタンプフィールドはパケット内に含まれ
る。 EXTSIG(変更された外部信号) EXTSIGパケットはRTTDPに対して選択された一つ以上の
外部信号が変更されたことを示す。設計者はモニターさ
れる信号を規定する。全ての信号値はパケットに保存さ
れる。タイムスタンピングがイネーブルであれば、タイ
ムスタンプフィールドはパケット内に含まれる。
ことを示す。もしタイムスタンピングがイネーブルであ
れば、タイムスタンプフィールドはパケット内に含まれ
る。 EXTSIG(変更された外部信号) EXTSIGパケットはRTTDPに対して選択された一つ以上の
外部信号が変更されたことを示す。設計者はモニターさ
れる信号を規定する。全ての信号値はパケットに保存さ
れる。タイムスタンピングがイネーブルであれば、タイ
ムスタンプフィールドはパケット内に含まれる。
【0343】SEGSTART(セグメントの開始)
SEGSTARTパケットはセグメント内の第1パケットであ
る。これはフルアドレスとして現在のPC値を含む。SEGS
TARTパケットがパケットポートに伝送される前に、RTT
はその以前に全てのゼロの少なくとも4個のニブルがあ
ることを保証する。これが行なわれることにより、トレ
ースデコーダ及び外部キャプチャ装置はパケットストリ
ーム内のどこかでもSEGSTARTパケットの開始を容易に見
出せる。もしタイムスタンピングがイネーブルであれ
ば、そのタイムスタンプフィールドはパケット内に含ま
れる。新しいセグメント理由フィールドはSEGSTARTが何
故パケットに含まれるのかを明示する。一つ以上の理由
が同時に発生すれば、理由は数の上で小さな値に書き込
まれる。可能なケースが以下の表3に書き込まれる。
る。これはフルアドレスとして現在のPC値を含む。SEGS
TARTパケットがパケットポートに伝送される前に、RTT
はその以前に全てのゼロの少なくとも4個のニブルがあ
ることを保証する。これが行なわれることにより、トレ
ースデコーダ及び外部キャプチャ装置はパケットストリ
ーム内のどこかでもSEGSTARTパケットの開始を容易に見
出せる。もしタイムスタンピングがイネーブルであれ
ば、そのタイムスタンプフィールドはパケット内に含ま
れる。新しいセグメント理由フィールドはSEGSTARTが何
故パケットに含まれるのかを明示する。一つ以上の理由
が同時に発生すれば、理由は数の上で小さな値に書き込
まれる。可能なケースが以下の表3に書き込まれる。
【0344】SEGEND(セグメントのエンド)
SEGENDパケットはBCBICカウンタ値が0ではなく、セグ
メントエンドが)以下の理由の中のいずれかである時に
生成される:(i)到達したセグメント内での命令限界がユ
ーザーに明示され、(ii)任意の外部入力信号により要求
され、(iii)RTT内での制御レジスタの書き込みにより要
求され、または(iv)任意の状態がRUNまたはTRIGGEREDで
あり、命令トレースがイネーブルから使用不可にスイッ
チされる。カウンタはフラッシュされた後にゼロにセッ
トされる。 TRIG(トリガー状態への進入) TRIGパケットは外部格納モード及びRUNとTRIGGERED状態
間のRTT変化詩に生成される。TRIGパケットのパケット
ポートへの伝送に先立って、RTTはその以前に全てのゼ
ロの少なくとも4個のニブルがあることを保証する。こ
れが行なわれることにより、外部キャプチャー装置はTR
IGパケットの開始を容易に見出せる。
メントエンドが)以下の理由の中のいずれかである時に
生成される:(i)到達したセグメント内での命令限界がユ
ーザーに明示され、(ii)任意の外部入力信号により要求
され、(iii)RTT内での制御レジスタの書き込みにより要
求され、または(iv)任意の状態がRUNまたはTRIGGEREDで
あり、命令トレースがイネーブルから使用不可にスイッ
チされる。カウンタはフラッシュされた後にゼロにセッ
トされる。 TRIG(トリガー状態への進入) TRIGパケットは外部格納モード及びRUNとTRIGGERED状態
間のRTT変化詩に生成される。TRIGパケットのパケット
ポートへの伝送に先立って、RTTはその以前に全てのゼ
ロの少なくとも4個のニブルがあることを保証する。こ
れが行なわれることにより、外部キャプチャー装置はTR
IGパケットの開始を容易に見出せる。
【0345】LPSTART(ループ開始)
LPSTARTパケットはフル24ビット値に格納されたLP_S
TARTレジスタ値を含む。これはゼロオーバーヘッドルー
プがトリガーされる時及びLP_START値が現在のセグメ
ントに先立ってセットアップする時に生成される。 LPEND(ループエンド) LPENDパケットはフル24ビット値に格納されたLP_END
レジスタ値を含む。これはゼロオーバーヘッドループが
トリガーされる時及びLP_END値が現在のセグメントに
先立ってセットアップする時に生成される。
TARTレジスタ値を含む。これはゼロオーバーヘッドルー
プがトリガーされる時及びLP_START値が現在のセグメ
ントに先立ってセットアップする時に生成される。 LPEND(ループエンド) LPENDパケットはフル24ビット値に格納されたLP_END
レジスタ値を含む。これはゼロオーバーヘッドループが
トリガーされる時及びLP_END値が現在のセグメントに
先立ってセットアップする時に生成される。
【0346】INT(インタラプト取り)
INTパケットはインタラプトが取られる時生成される。
これはインタラプトの時間におけるPC及びインタラプト
ベクターテーブルでの第1命令の新しいPCを含む。フル
PC値はインコードされる。タイムスタンピングがイネー
ブルであれば、タイプスタンプフィールドはパケット内
に含まれる。
これはインタラプトの時間におけるPC及びインタラプト
ベクターテーブルでの第1命令の新しいPCを含む。フル
PC値はインコードされる。タイムスタンピングがイネー
ブルであれば、タイプスタンプフィールドはパケット内
に含まれる。
【0347】付録 II
詳細なパケットの説明(第2実施例)
STALL
STALLパケットはコアの使用が可能であるが、命令タイ
ミングトレースがイネーブルになる時命令を引き戻すこ
とができない毎周期に生成される。“カウンタ値”フィ
ールドはストール値を1から16周期(パケット内のゼ
ロの値は実際に16周期である)までインコードする。
周期カウンタ値は連続的なストール周期に対して増分さ
れる。周期カウンタが増分またはオーバーフローを中止
する時、STALLパケットが生成される。“命令カウン
タ”及び“ストール理由”フィールドの存在で、RTT_P
KT_CTLレジスタにより独立的にイネーブルになる。命
令カウンタが存在しなければ、“命令カウンタ=1”フ
ィールドは0である。“周期カウンタ=1”フィールド
が1であれば、“周期カウンタ値”フィールドは省略さ
れる。“命令カウンタ=1”フィールドが1であれば、
“命令カウンタ値”フィールドは省略される。4ビット
の“ストール理由”フィールドは以下のように規定され
る。
ミングトレースがイネーブルになる時命令を引き戻すこ
とができない毎周期に生成される。“カウンタ値”フィ
ールドはストール値を1から16周期(パケット内のゼ
ロの値は実際に16周期である)までインコードする。
周期カウンタ値は連続的なストール周期に対して増分さ
れる。周期カウンタが増分またはオーバーフローを中止
する時、STALLパケットが生成される。“命令カウン
タ”及び“ストール理由”フィールドの存在で、RTT_P
KT_CTLレジスタにより独立的にイネーブルになる。命
令カウンタが存在しなければ、“命令カウンタ=1”フ
ィールドは0である。“周期カウンタ=1”フィールド
が1であれば、“周期カウンタ値”フィールドは省略さ
れる。“命令カウンタ=1”フィールドが1であれば、
“命令カウンタ値”フィールドは省略される。4ビット
の“ストール理由”フィールドは以下のように規定され
る。
【0348】DATA(データ変換)
DATAパケットは補助レジスタロード(LR命令)に対する全
ての情報、全ての形態の格納(SR、ST、STW、STB命令)、
及びメモリロード(LD、LDW、LDB命令)に対する正しいデ
ータアドレスを含む。これはデータ変換命令の実行時に
生成される。現在のトレースオプションによって、パケ
ットはデータアドレス、データ値、セグメント命令のオ
フセットサイズを含む場合がある。フルデータアドレス
は32ビットであるが、但し特異な部分のみ書き込まれ
る。データ値は可変サイズである。データ値のサイズは
パケットに明記される。データ値の存在フィールドが1
であれば、データ値サイズ、使用デフォルトデータアド
レスサイズ、及びデータ値フィールドは存在する。格納
及び補助ロード命令に対して、データ値のキャプチャが
静的にイネーブルであればデータ値の存在は1である。
メモリロード命令に対して、DLDDパケットがデータ値を
保持しているので、データ値の存在は0である。もしデ
ータアドレスキャプチャーが静的にイネーブルであれ
ば、データアドレスフィールドが存在し、データアドレ
スサイズフィールドが存在し、使用デフォルトデータア
ドレスのサイズが0であればデータ値は存在しない。
ての情報、全ての形態の格納(SR、ST、STW、STB命令)、
及びメモリロード(LD、LDW、LDB命令)に対する正しいデ
ータアドレスを含む。これはデータ変換命令の実行時に
生成される。現在のトレースオプションによって、パケ
ットはデータアドレス、データ値、セグメント命令のオ
フセットサイズを含む場合がある。フルデータアドレス
は32ビットであるが、但し特異な部分のみ書き込まれ
る。データ値は可変サイズである。データ値のサイズは
パケットに明記される。データ値の存在フィールドが1
であれば、データ値サイズ、使用デフォルトデータアド
レスサイズ、及びデータ値フィールドは存在する。格納
及び補助ロード命令に対して、データ値のキャプチャが
静的にイネーブルであればデータ値の存在は1である。
メモリロード命令に対して、DLDDパケットがデータ値を
保持しているので、データ値の存在は0である。もしデ
ータアドレスキャプチャーが静的にイネーブルであれ
ば、データアドレスフィールドが存在し、データアドレ
スサイズフィールドが存在し、使用デフォルトデータア
ドレスのサイズが0であればデータ値は存在しない。
【0349】DLDD(遅延された-ロード データ)
DLDDパケットは遅延ロードデータがレジスタファイルに
再び書き込まれる時にユーザーが書き込まれるロードデ
ータ値を利用できれば生成される。これはメモリロード
命令(LD、LDW、LDB)に対して生成される。遅延ロード命
令が指令から外れてリターンする場合もあるので、この
遅延ロード命令に対する宛先レジスタフィールドを必要
とする。補助レジスタ(LR)からのロードはそれらのロー
ドデータが遅れないのでこのパケットを使用しない。
“ストール周期カウンタ値”と“ストール命令カウンタ
値”フィールドによりトレースレコーダはレジスタファ
イルに書き込まれるロードデータの周期の決定を可能に
する。これらのフィールドは命令タイミングトレースが
静的である時に存在する。DLDDパケットの生成後にSTAL
Lパケットがストール理由フィールドを含まないとカウ
ンタはゼロにセットされる。
再び書き込まれる時にユーザーが書き込まれるロードデ
ータ値を利用できれば生成される。これはメモリロード
命令(LD、LDW、LDB)に対して生成される。遅延ロード命
令が指令から外れてリターンする場合もあるので、この
遅延ロード命令に対する宛先レジスタフィールドを必要
とする。補助レジスタ(LR)からのロードはそれらのロー
ドデータが遅れないのでこのパケットを使用しない。
“ストール周期カウンタ値”と“ストール命令カウンタ
値”フィールドによりトレースレコーダはレジスタファ
イルに書き込まれるロードデータの周期の決定を可能に
する。これらのフィールドは命令タイミングトレースが
静的である時に存在する。DLDDパケットの生成後にSTAL
Lパケットがストール理由フィールドを含まないとカウ
ンタはゼロにセットされる。
【0350】PF(パス/フェイル状態)
PFパケットはその条件コードテストにおいて条件付き命
令のパスまたはフェイルを示す。このパス/フェイル状
態のビットはパスに対して1でフェイルに対しては0で
ある。 IA(命令アドレス) IAパケットは間接ジャンプのターゲットPCまたはインタ
ラプトの発生後に第1命令が実行されれば条件付き直接
ジャンプのターゲットPCを含む。フルターゲットPC値は
24ビットであるが、但し特異な部分のみ書き込まれ
る。
令のパスまたはフェイルを示す。このパス/フェイル状
態のビットはパスに対して1でフェイルに対しては0で
ある。 IA(命令アドレス) IAパケットは間接ジャンプのターゲットPCまたはインタ
ラプトの発生後に第1命令が実行されれば条件付き直接
ジャンプのターゲットPCを含む。フルターゲットPC値は
24ビットであるが、但し特異な部分のみ書き込まれ
る。
【0351】BCBPC(後方向条件付きブランチパスカウン
タ) BCBPCパケットはその条件コードテストにおいて、後方
向条件付きブランチ命令のフェイルを示す。このパケッ
トはパスになるが、トレースに記録されない後方向条件
付きブランチ命令に対する多数の時間のカウントを含
む。このカウンタは命令トレースの活性時にのみ増分さ
れる。“パスカウント=0”フィールドが1であれば、
“パスカウント値”フィールドは省略される。 LPPC(ゼロオーバーヘッドループパスカウンタ) LPPCパケットはゼロオーバーヘッドループトリガーのフ
ェイル(ループの終了)を示す。このパケットはパスされ
るが、トレースに記録されないトリガーに対する多数の
時間のカウントを含む。このカウンタは命令トレースの
活性時にのみ増分される。“パスカウント=0”フィー
ルドが1であれば、“パスカウント値”フィールドは省
略される。
タ) BCBPCパケットはその条件コードテストにおいて、後方
向条件付きブランチ命令のフェイルを示す。このパケッ
トはパスになるが、トレースに記録されない後方向条件
付きブランチ命令に対する多数の時間のカウントを含
む。このカウンタは命令トレースの活性時にのみ増分さ
れる。“パスカウント=0”フィールドが1であれば、
“パスカウント値”フィールドは省略される。 LPPC(ゼロオーバーヘッドループパスカウンタ) LPPCパケットはゼロオーバーヘッドループトリガーのフ
ェイル(ループの終了)を示す。このパケットはパスされ
るが、トレースに記録されないトリガーに対する多数の
時間のカウントを含む。このカウンタは命令トレースの
活性時にのみ増分される。“パスカウント=0”フィー
ルドが1であれば、“パスカウント値”フィールドは省
略される。
【0352】SICOV(オーバーフローされたストール命令
カウンタ) SICOVパケットはストール命令カウンタのオーバーフロ
ーを示す。カウンタの最大値が一定なので、このカウン
タの値はパケットにない。 BCBPCOV(オーバーフローされた後方向条件付きブランチ
パスカウンタ) BCBPCOVパケットは後方向条件付きブランチパスカウン
タのオーバーフローを示す。カウンタの最大値が一定な
ので、このカウンタの値はパケットにない。
カウンタ) SICOVパケットはストール命令カウンタのオーバーフロ
ーを示す。カウンタの最大値が一定なので、このカウン
タの値はパケットにない。 BCBPCOV(オーバーフローされた後方向条件付きブランチ
パスカウンタ) BCBPCOVパケットは後方向条件付きブランチパスカウン
タのオーバーフローを示す。カウンタの最大値が一定な
ので、このカウンタの値はパケットにない。
【0353】LPPCOV(オーバーフローされたゼロオーバ
ーヘッドループパスカウンタ) LPPCOVパケットはゼロオーバーヘッドループパスカウン
タのオーバーフローを示す。カウンタの最大値が一定な
ので、このカウンタの値はパケットにない。 APE(アクションポイント イベント) APEパケットはアクションポイントイベントが発生した
ことを示す。アクションポイントイベントの発生時にタ
イムスタンピングがイネーブルであれば、タイムスタン
プEnは‘1’にセットされ、タイムスタンプフィールド
はパケット内に含まれる。
ーヘッドループパスカウンタ) LPPCOVパケットはゼロオーバーヘッドループパスカウン
タのオーバーフローを示す。カウンタの最大値が一定な
ので、このカウンタの値はパケットにない。 APE(アクションポイント イベント) APEパケットはアクションポイントイベントが発生した
ことを示す。アクションポイントイベントの発生時にタ
イムスタンピングがイネーブルであれば、タイムスタン
プEnは‘1’にセットされ、タイムスタンプフィールド
はパケット内に含まれる。
【0354】EXTSIG(変更された外部信号)
EXTSIGパケットは選ばれた一つ以上の外部信号の値がRT
Tに対して更新されたことを示す。設計者はモニターさ
れる信号を規定する。全ての信号値はパケットに格納さ
れる。外部信号の値が更新される時にタイムスタンピン
グがイネーブルであれば、タイムスタンプEnは‘1’に
セットされ、タイムスタンプはパケット内に含まれる。 INT(インタラプト取り) INTパケットはインタラプトを取る時に生成される。こ
れはインタラプトされた命令(実行されない)のセグメン
ト命令オフセット及びインタラプトベクターテーブルの
第1命令のフルアドレスを含む。インタラプトが静的に
イネーブルで命令トレイシングが使用不可であれば、イ
ンタラプト命令の決定のためにデコーダによりセグメン
ト命令のオフセット値を使用することができなくてもIN
Tパケットは相変らず生成される。タイムスタンピング
がイネーブルであれば、タイムスタンプフィールドはパ
ケット内に含まれる。BCBPC及びLPPCカウンタ値はINTパ
ケットに記録された後にゼロにセットされる。
Tに対して更新されたことを示す。設計者はモニターさ
れる信号を規定する。全ての信号値はパケットに格納さ
れる。外部信号の値が更新される時にタイムスタンピン
グがイネーブルであれば、タイムスタンプEnは‘1’に
セットされ、タイムスタンプはパケット内に含まれる。 INT(インタラプト取り) INTパケットはインタラプトを取る時に生成される。こ
れはインタラプトされた命令(実行されない)のセグメン
ト命令オフセット及びインタラプトベクターテーブルの
第1命令のフルアドレスを含む。インタラプトが静的に
イネーブルで命令トレイシングが使用不可であれば、イ
ンタラプト命令の決定のためにデコーダによりセグメン
ト命令のオフセット値を使用することができなくてもIN
Tパケットは相変らず生成される。タイムスタンピング
がイネーブルであれば、タイムスタンプフィールドはパ
ケット内に含まれる。BCBPC及びLPPCカウンタ値はINTパ
ケットに記録された後にゼロにセットされる。
【0355】LPTRIG(ループトリガー)
LPTRIGパケットはフル24ビット値に保存されたLP_ST
ART及びLP_ENDレジスタを含む。このパケットはゼロオ
ーバーヘッドループがリガーされて取られ、現在のセグ
メントの以前に実行された命令によってLP_START及びL
P_ENDレジスタが書き込まれる時に生成される。 TSOV(オーバーフローされたタイムスタンプ) TSOVパケットは15ビットタイムスタンプのオーバーフ
ローを示す。これはタイムスタンピングがイネーブルな
時に生成される。もし他のパケットがTSOVパケットの生
成に先立って生成された“タイムスタンプオーバーフロ
ー”ビットを含めば、TSOVパケットはそういうオーバー
フローに対して生成されない。
ART及びLP_ENDレジスタを含む。このパケットはゼロオ
ーバーヘッドループがリガーされて取られ、現在のセグ
メントの以前に実行された命令によってLP_START及びL
P_ENDレジスタが書き込まれる時に生成される。 TSOV(オーバーフローされたタイムスタンプ) TSOVパケットは15ビットタイムスタンプのオーバーフ
ローを示す。これはタイムスタンピングがイネーブルな
時に生成される。もし他のパケットがTSOVパケットの生
成に先立って生成された“タイムスタンプオーバーフロ
ー”ビットを含めば、TSOVパケットはそういうオーバー
フローに対して生成されない。
【0356】SEGSTART(セグメントの開始)
SEGSTARTパケットはセグメント内の第1パケットであ
る。これはフルアドレスとして現在のPC値を含む。パケ
ットポートへのSEGSTARTパケットの伝送に先立って、RT
Tはその以前に全てのゼロの少なくとも4個のニブルが
あることを保証する。これが行なわれることにより、ト
レースデコーダと外部キャプチャ装置はSEGSTARTパケッ
トの開始を容易に見出せる。BCBPC及びLPPCカウンタ値
が全て0であれば、それらは省略される。タイムスタン
ピングがイネーブルであれば、タイムスタンプフィール
ドはパケット内に含まれる。SEGSTARTパケットにおいて
パケット制御レジスタ値のコンテンツはタイムスタンピ
ングに対するイネーブルの可否を決定する。
る。これはフルアドレスとして現在のPC値を含む。パケ
ットポートへのSEGSTARTパケットの伝送に先立って、RT
Tはその以前に全てのゼロの少なくとも4個のニブルが
あることを保証する。これが行なわれることにより、ト
レースデコーダと外部キャプチャ装置はSEGSTARTパケッ
トの開始を容易に見出せる。BCBPC及びLPPCカウンタ値
が全て0であれば、それらは省略される。タイムスタン
ピングがイネーブルであれば、タイムスタンプフィール
ドはパケット内に含まれる。SEGSTARTパケットにおいて
パケット制御レジスタ値のコンテンツはタイムスタンピ
ングに対するイネーブルの可否を決定する。
【0357】新しいセグメント理由フィールドはSEGSTA
RTパケットが何故生成されているかを明示する。もし一
つ以上の理由が同時に発生されれば、理由は数の上で小
さい値に書き込まれる。可能なケースは次の通りであ
る。
RTパケットが何故生成されているかを明示する。もし一
つ以上の理由が同時に発生されれば、理由は数の上で小
さい値に書き込まれる。可能なケースは次の通りであ
る。
【0358】SRSPEC(特定のレジスタに対するSR)
SRSPECパケットはプログラムが特定のレジスタに対して
SR命令を実行する時に生成される。特定のレジスタはRT
T_USER、RTT_PKT_CTLの時、LPSTART、及びLPENDであ
る。特定のレジスタ識別子及び書き込まれた値はパケッ
トに格納される。タイムスタンプ及びタイムスタンプオ
ーバーフローフィールドはこのタイムスタンプの使用が
可能であり、SRがRTT_PKT_CTLレジスタに関すること
である時にのみ存在する。
SR命令を実行する時に生成される。特定のレジスタはRT
T_USER、RTT_PKT_CTLの時、LPSTART、及びLPENDであ
る。特定のレジスタ識別子及び書き込まれた値はパケッ
トに格納される。タイムスタンプ及びタイムスタンプオ
ーバーフローフィールドはこのタイムスタンプの使用が
可能であり、SRがRTT_PKT_CTLレジスタに関すること
である時にのみ存在する。
【0359】特定のレジスタ識別子はコードし、各レジ
スタに対するレジスタ値フィールドのサイズは次の通り
である。
スタに対するレジスタ値フィールドのサイズは次の通り
である。
【0360】付録 III - 例示的なレジスタ命令
【0361】“ADDr”列はレジスタの補助アドレスであ
る。“Resister Name”列はこの文書で使用したレジス
タの名前である。“Core WR”、“ホストWR”、及び“R
TT WR”列は各レジスタを書きこくことができるソース
(source)である可能性があるリストである。“EN WR”
列はRTTがイネーブルな間にレジスタの書き込みが可能
であるかを明示する。“RD”列はレジスタの読み取りが
可能であるかを明示する。読み取り可能なレジスタは3
個の全ての可能なソースにより読み取られることができ
る。“Dual”列はレジスタのデュアルアクセスが可能で
あるかを明示する。“Bits”列は各レジスタのサイズを
明示する。未使用及び保存レジスタビットは0と読み取
られ、必ず0と書き込まれる。書き込み専用レジスタに
対する読み取りはコア識別レジスタをリターンさせる。
読み取り専用レジスタに対する書き込みは無視される。
レジスタによって、3個の可能なソース:コア、ホスト
及びRTTまで書き込まれる。コアはSR命令の実行によっ
てレジスタを書き込む。ホストはホストインターフェー
スの使用によりレジスタを書き込む。RTTはこのRTTの初
期状態がレジスタの更新を命令する時にレジスタを書き
込む。RTT_HOST_CTLレジスタのNAWビットが1であれ
ば、RTTレジスタに対して書き込まれるいかなるコアで
も無視される。ホストのみNAWビットの値を制御し、こ
れはコアがRTTレジスタを書き込むとができないことを
保証するのに使用する。NAWビットに対して更に詳述す
るために、以下のRTT_HOST_CTLレジスタの説明を参照
する。NAWビットが0であれば、RTTがRTT_LOCKレジス
タを特定の値に書き込むコアによって、先にアンロクさ
れたことを除いてはRTTレジスタに書き込まれるいかな
るコアでも無視される。これはRTT_LOCKレジスタ自体
に対しては適用されない。ロックメカニズムに対して更
に詳述するために、以下のRTT_LOCKレジスタの説明を
参照する。デュアルアクセスレジスタはコアがイネーブ
ルな間にホストによってアクセスされることができる。
ホスト及びコアによりアクセス可能なデュアルアクセス
レジスタに対して、コア及びホストは同時に同一なRTT
レジスタを書き込むために試みることができる。このよ
うな状況で、ホストの書き込みはウィンであり、コアの
書き込みはローストである。ホスト及びコアにより書き
込みが可能なデュアルアクセスレジスタに対するコアの
書き込みの成功を保証するために、コアは必ずLR命令で
レジスタ値を読み取らなければならなく、これの成功時
までSR/LRを繰り返す。注目する点はRTT_CMDレジスタ
の読み取りは不可である反面、コマンドの成功の可否を
決定するためのRTT_STAT及びRTT_FIFO_STATレジスタ
の読み取りは可能だというものである。もしホストが
(たとえば、レジスタを読み取って、新しい値を計算
し、レジスタを書き込む)コアによって書き込むことが
できるRTTレジスタに対する複数のアクセスを“自動
に”実行することを必要とすれば、NAWビットはコアが
自動動作中にRTTレジスタの書き込みを防止できるいず
れかにセットされなければならない。
る。“Resister Name”列はこの文書で使用したレジス
タの名前である。“Core WR”、“ホストWR”、及び“R
TT WR”列は各レジスタを書きこくことができるソース
(source)である可能性があるリストである。“EN WR”
列はRTTがイネーブルな間にレジスタの書き込みが可能
であるかを明示する。“RD”列はレジスタの読み取りが
可能であるかを明示する。読み取り可能なレジスタは3
個の全ての可能なソースにより読み取られることができ
る。“Dual”列はレジスタのデュアルアクセスが可能で
あるかを明示する。“Bits”列は各レジスタのサイズを
明示する。未使用及び保存レジスタビットは0と読み取
られ、必ず0と書き込まれる。書き込み専用レジスタに
対する読み取りはコア識別レジスタをリターンさせる。
読み取り専用レジスタに対する書き込みは無視される。
レジスタによって、3個の可能なソース:コア、ホスト
及びRTTまで書き込まれる。コアはSR命令の実行によっ
てレジスタを書き込む。ホストはホストインターフェー
スの使用によりレジスタを書き込む。RTTはこのRTTの初
期状態がレジスタの更新を命令する時にレジスタを書き
込む。RTT_HOST_CTLレジスタのNAWビットが1であれ
ば、RTTレジスタに対して書き込まれるいかなるコアで
も無視される。ホストのみNAWビットの値を制御し、こ
れはコアがRTTレジスタを書き込むとができないことを
保証するのに使用する。NAWビットに対して更に詳述す
るために、以下のRTT_HOST_CTLレジスタの説明を参照
する。NAWビットが0であれば、RTTがRTT_LOCKレジス
タを特定の値に書き込むコアによって、先にアンロクさ
れたことを除いてはRTTレジスタに書き込まれるいかな
るコアでも無視される。これはRTT_LOCKレジスタ自体
に対しては適用されない。ロックメカニズムに対して更
に詳述するために、以下のRTT_LOCKレジスタの説明を
参照する。デュアルアクセスレジスタはコアがイネーブ
ルな間にホストによってアクセスされることができる。
ホスト及びコアによりアクセス可能なデュアルアクセス
レジスタに対して、コア及びホストは同時に同一なRTT
レジスタを書き込むために試みることができる。このよ
うな状況で、ホストの書き込みはウィンであり、コアの
書き込みはローストである。ホスト及びコアにより書き
込みが可能なデュアルアクセスレジスタに対するコアの
書き込みの成功を保証するために、コアは必ずLR命令で
レジスタ値を読み取らなければならなく、これの成功時
までSR/LRを繰り返す。注目する点はRTT_CMDレジスタ
の読み取りは不可である反面、コマンドの成功の可否を
決定するためのRTT_STAT及びRTT_FIFO_STATレジスタ
の読み取りは可能だというものである。もしホストが
(たとえば、レジスタを読み取って、新しい値を計算
し、レジスタを書き込む)コアによって書き込むことが
できるRTTレジスタに対する複数のアクセスを“自動
に”実行することを必要とすれば、NAWビットはコアが
自動動作中にRTTレジスタの書き込みを防止できるいず
れかにセットされなければならない。
【0362】RTT_ビルド レジスタ
RTT_ビルドレジスタはRTT組み付け構成を明記する。こ
れはRTTの組み付け構成を決定するために、ホスト及び/
またはARCで実行されるプログラムにより使われる。 VERSIONフィールドはRTTの実行が存在することを明記す
る。値0×1はRTTの現在の実行である。0×0のVERSI
ONはRTTが存在しないことを明記する。他の値は保存さ
れる。NUM_MONフィールドは存在するモニターの数を明
記する。これのインコーディングは次の表によって与え
られる(NUM_MON=モニターの数/2):
れはRTTの組み付け構成を決定するために、ホスト及び/
またはARCで実行されるプログラムにより使われる。 VERSIONフィールドはRTTの実行が存在することを明記す
る。値0×1はRTTの現在の実行である。0×0のVERSI
ONはRTTが存在しないことを明記する。他の値は保存さ
れる。NUM_MONフィールドは存在するモニターの数を明
記する。これのインコーディングは次の表によって与え
られる(NUM_MON=モニターの数/2):
【0363】DTフィールドはデータトレースが設計に存
在すれば1で、それとも0である。TTフィールドはタイ
ミングトレースが設計に存在すれば1で、それとも0で
ある。APEフィールドはアクションポイントイベントがA
PEパケットに書き込まれることができれば1で、それと
も0である。USER_NB_M1フィールドは1以下のRTT_
USERレジスタにおけるニブルの数である。現在5(6ニ
ブル)に固定されているが、以後にRTTバージョンにおけ
る変化は可能である。FIFO_ENTRIESフィールドは現在
のFIFOエントリーの数を明記する。各エントリーは64
ビット幅である。FIFO_ENTRIESは0(FIFO存在しない)
から2048までの範囲を持つ。EXTSIG_NB_M1フィ
ールドはEXTSIGパケットに記録された1以下の外部信号
のニブル数を明記する。この値は何らの外部信号の記録
がない時に0(1ニブル)にデフォルトする。PORT_WIDT
Hフィールドはパケットポートの幅を明記する。これの
インコーディングは次の表によって与えられる:
在すれば1で、それとも0である。TTフィールドはタイ
ミングトレースが設計に存在すれば1で、それとも0で
ある。APEフィールドはアクションポイントイベントがA
PEパケットに書き込まれることができれば1で、それと
も0である。USER_NB_M1フィールドは1以下のRTT_
USERレジスタにおけるニブルの数である。現在5(6ニ
ブル)に固定されているが、以後にRTTバージョンにおけ
る変化は可能である。FIFO_ENTRIESフィールドは現在
のFIFOエントリーの数を明記する。各エントリーは64
ビット幅である。FIFO_ENTRIESは0(FIFO存在しない)
から2048までの範囲を持つ。EXTSIG_NB_M1フィ
ールドはEXTSIGパケットに記録された1以下の外部信号
のニブル数を明記する。この値は何らの外部信号の記録
がない時に0(1ニブル)にデフォルトする。PORT_WIDT
Hフィールドはパケットポートの幅を明記する。これの
インコーディングは次の表によって与えられる:
【0364】RTT_STAT レジスタ
RTT_STATレジスタはRTTの状態を含む。
ENビットはイネーブルになるRTTの一つである。これは
リセット時にゼロにセットされる幾つの周期を取ること
ができる。TRビットはトリガーされるRTTの一つであ
る。これはリセット時にゼロにセットされる。IRQビッ
トはそのインタラプト信号がARCにアサートされるRTTの
一つである。これはリセット時にゼロにセットされる。
0Vビットはオーバーフロー状態にあるRTTバッファの一
つである。これはリセット時にゼロにセットされる。こ
のフィールドはテストの目的のために提供される。TSO
(タイムスタンプオーバーラン)、APO(アクションポイン
トオーバーラン)、及びESO(外部信号オーバーラン)ビッ
トはオーバーランのそれらの相応するメカニズムの一つ
にセットされる。以前のイベントがパケットに書き込ま
れるに先立ってイベントが再発生する時オーバーランが
検知になる。PMTビットはRTTバッファ内のパケットパイ
プラインが空いているか、または0の一つである。TMT
ビットはパケットポートが空いているか、または0の一
つである。これはリセット時に1にセットされる。この
フィールドはテストの目的のために提供される。ULビッ
トはアンロックされるRTTのひとつである。このRTTはRT
T_LOCKレジスタが特定の値に書き込まれる時にアンロ
ックされ、次のST命令の後には再びロックされる。BCBP
Cは後方向条件付きブランチパスカウンタの値を含む。
これはリセット時にゼロにセットされる。このフィール
ドはテストの目的のために提供されている。LPPCはゼロ
オーバーヘッドループパスカウンタの値を含む。これは
リセット時にゼロにセットされる。このフィールドはテ
ストの目的のために提供される。
リセット時にゼロにセットされる幾つの周期を取ること
ができる。TRビットはトリガーされるRTTの一つであ
る。これはリセット時にゼロにセットされる。IRQビッ
トはそのインタラプト信号がARCにアサートされるRTTの
一つである。これはリセット時にゼロにセットされる。
0Vビットはオーバーフロー状態にあるRTTバッファの一
つである。これはリセット時にゼロにセットされる。こ
のフィールドはテストの目的のために提供される。TSO
(タイムスタンプオーバーラン)、APO(アクションポイン
トオーバーラン)、及びESO(外部信号オーバーラン)ビッ
トはオーバーランのそれらの相応するメカニズムの一つ
にセットされる。以前のイベントがパケットに書き込ま
れるに先立ってイベントが再発生する時オーバーランが
検知になる。PMTビットはRTTバッファ内のパケットパイ
プラインが空いているか、または0の一つである。TMT
ビットはパケットポートが空いているか、または0の一
つである。これはリセット時に1にセットされる。この
フィールドはテストの目的のために提供される。ULビッ
トはアンロックされるRTTのひとつである。このRTTはRT
T_LOCKレジスタが特定の値に書き込まれる時にアンロ
ックされ、次のST命令の後には再びロックされる。BCBP
Cは後方向条件付きブランチパスカウンタの値を含む。
これはリセット時にゼロにセットされる。このフィール
ドはテストの目的のために提供されている。LPPCはゼロ
オーバーヘッドループパスカウンタの値を含む。これは
リセット時にゼロにセットされる。このフィールドはテ
ストの目的のために提供される。
【0365】RTT_CMD レジスタ
RTT_CMDレジスタはRTTに対する次のコマンドの一つを
送信するために使われる。 RTT_CMDレジスタのフォーマットは次の通りである: RTT_CMDレジスタがコア上で実行されるSR命令によって
書き込まれれば、コマンドはSR命令後の第1命令やイン
タラプトに影響を与える。CMD_DISコマンドはRTTを使
用不可とする。CMD_EN_コマンドはRTTをイネーブルと
する。CMD_TRIGコマンドはRTTをトリガーする。CMD_E
N_TRIGコマンドはRTTをイネーブル及びトリガーする。
CMD_NSコマンドは次の非遅延スロット命令またはイ
ンタラプト後に新しいセグメントの開始である。CMD_C
Bコマンドはバッファのコンテンツを消去する。これは
テストの目的のために提供されている。CMD_SET_IR
QコマンドはARCに送信されるインタラプト要求信号を
セットする。これはテストの目的のために提供される。
CMD_CLR_IRQコマンドはコアに送信されたインタラ
プト要求信号を消去する。これはノーマル動作で使われ
る。
送信するために使われる。 RTT_CMDレジスタのフォーマットは次の通りである: RTT_CMDレジスタがコア上で実行されるSR命令によって
書き込まれれば、コマンドはSR命令後の第1命令やイン
タラプトに影響を与える。CMD_DISコマンドはRTTを使
用不可とする。CMD_EN_コマンドはRTTをイネーブルと
する。CMD_TRIGコマンドはRTTをトリガーする。CMD_E
N_TRIGコマンドはRTTをイネーブル及びトリガーする。
CMD_NSコマンドは次の非遅延スロット命令またはイ
ンタラプト後に新しいセグメントの開始である。CMD_C
Bコマンドはバッファのコンテンツを消去する。これは
テストの目的のために提供されている。CMD_SET_IR
QコマンドはARCに送信されるインタラプト要求信号を
セットする。これはテストの目的のために提供される。
CMD_CLR_IRQコマンドはコアに送信されたインタラ
プト要求信号を消去する。これはノーマル動作で使われ
る。
【0366】RTT_CK_CTLレジスタ
RTT_CK_CTLはRTTクロックを制御する。
CK_ENビットは1にセットされてRTTをイネーブルと
し、ゼロにセットされてこれを使用不可とする。これは
リセット時にゼロにセットされる。RTTクロックが使用
不可であれば、RTT_CK_CTL、RTT_LOCK及びRTT_HOST
_CTLレジスタを除いて全ての動作は停止する。RTTクロ
ックはRTTが要求されない時、節電のために使用不可と
することもできる。
し、ゼロにセットされてこれを使用不可とする。これは
リセット時にゼロにセットされる。RTTクロックが使用
不可であれば、RTT_CK_CTL、RTT_LOCK及びRTT_HOST
_CTLレジスタを除いて全ての動作は停止する。RTTクロ
ックはRTTが要求されない時、節電のために使用不可と
することもできる。
【0367】RTT_ LOCKレジスタ
コアが或る他のRTTレジスタの書き込みを許すに先立っ
て、これは必ずRTT_LOCKレジスタに対する以下に示す
値への書き込みによりRTTを先ずアンロックしなければ
ならない。これはRTTレジスタを誤って書き込むように
なる過誤コードの可能性を大きく減少させるために行わ
れる。RTT_ロックレジスタの書き込みの後に、コアは
他の一つのRTTレジスタの書き込みが許容される。RTT_
LOCKレジスタの書き込みの後に、RTTは次の命令がある
レジスタで実行されるまでアンロック状態にある。書き
込まれるRTT_LOCKに対するSRとRTTに対するSR間にイン
タラプトが生じてインタラプトハンドラーがSR命令を実
行させれば、インタラプトハンドラーはある命令を実行
するに先立ってRTT_STAT.ULビットを読み取らなければ
ならなく、最終SRの実行後にはRTT_LOCKレジスタに対
してSRを実行させなければならない。RTT_HOST_CTLの
時、レジスタのNAWビットが1にセットされると、コア
は何らのRTTレジスタの書き込みも許さない。
て、これは必ずRTT_LOCKレジスタに対する以下に示す
値への書き込みによりRTTを先ずアンロックしなければ
ならない。これはRTTレジスタを誤って書き込むように
なる過誤コードの可能性を大きく減少させるために行わ
れる。RTT_ロックレジスタの書き込みの後に、コアは
他の一つのRTTレジスタの書き込みが許容される。RTT_
LOCKレジスタの書き込みの後に、RTTは次の命令がある
レジスタで実行されるまでアンロック状態にある。書き
込まれるRTT_LOCKに対するSRとRTTに対するSR間にイン
タラプトが生じてインタラプトハンドラーがSR命令を実
行させれば、インタラプトハンドラーはある命令を実行
するに先立ってRTT_STAT.ULビットを読み取らなければ
ならなく、最終SRの実行後にはRTT_LOCKレジスタに対
してSRを実行させなければならない。RTT_HOST_CTLの
時、レジスタのNAWビットが1にセットされると、コア
は何らのRTTレジスタの書き込みも許さない。
【0368】RTT_HOST_CTL レジスタ
RTT_HOST_CTLレジスタはホストに対してだけイネーブ
ルなオプションを含む。 NAWビットはRTTレジスタに対するコア書き込みのアクセ
スを制御する。このビットが1であれば、RTTレジスタ
に対する全てのSR命令は無視される。このビットが0で
あれば、SR命令はRTTレジスタを書き込む。ブロッキン
グコアはコアで実行されるプログラムがRTT動作を変更
出来ないように保証するためにRTTレジスタに書き込
む。NAWが0であれば、コアはコアで実行されるプログ
ラムが誤ってRTT動作を変更させる可能性を最小化する
ために使用する。NAWビットはリセット時にゼロにセッ
トされる。
ルなオプションを含む。 NAWビットはRTTレジスタに対するコア書き込みのアクセ
スを制御する。このビットが1であれば、RTTレジスタ
に対する全てのSR命令は無視される。このビットが0で
あれば、SR命令はRTTレジスタを書き込む。ブロッキン
グコアはコアで実行されるプログラムがRTT動作を変更
出来ないように保証するためにRTTレジスタに書き込
む。NAWが0であれば、コアはコアで実行されるプログ
ラムが誤ってRTT動作を変更させる可能性を最小化する
ために使用する。NAWビットはリセット時にゼロにセッ
トされる。
【0369】RTT_PKT_CTL レジスタ
RTT_PKT_CTL(パケットコントロール)レジスタはデコ
ーダのためにパケットストリームに記録されなければな
らない実行時間RTTオプションを制御する。 各ビットは1にセットされてイネーブルとなり、ゼロに
セットされて使用不可となる。ビットの意味は次の表に
よって与えられる。 ダイナミックエネイブルな全てのビットはリセット時に
ゼロにセットされる。命令タイミングトレースがダイナ
ミックエネイブルであれば、命令トレースもダイナミッ
クエネイブルにならなければならない。UPC(Use Pass C
ounts)ビットは後方向条件付きブランチパスカウンタ、
ゼロオーバーヘッドループパスカウンタ及び関連パケッ
ト(BCBPC、LPPC、BCBPCOV、LPPCOV)のイネーブル/使用
不可になる。このビットはRTTの使用不可の時にのみ変
更できる。UPCビットはリセット時にゼロにセットされ
る。LCMビットはゼロにセットされて動機命令トレース
の記録のための高圧縮モードを使用し、1にセットされ
て底圧縮モードを使用する。このビットはRTTの使用不
可の時にのみ変更できる。これはリセット時にゼロにセ
ットされる。STRビットはSTALLパケットがストール理
由フィールドを含んでいるかを制御する。STRはリセッ
ト時にゼロにセットされる。LDビットが1であれば、AD
V及びDAビットのうち、一つまたは二つ全て1にならな
ければならない。もしST、LR、またはSRビットのいずれ
かが1であれば、SDV及びDAビットの一つまたは二つ全
て1にならなければならない。ADV、SDV、またはDAビッ
トのいずれかが1であれば、データトレースはイネーブ
ルとなる。もし、データトレースまたは命令タイミング
トレースがイネーブルとなれば、命令トレースやはりト
レースデコードがトレースをデコードできるようにする
ためにイネーブルとならなければならない。RTT_USE
R、RTT_PKT_CTL、LPSTART、及びLPNEDレジスタへのSR
命令のためにSDV、DA、及びSRビットは無視される。RTT
_USER及びRTT_PKT_CTLレジスタへの格納はRTT_HOST
_CTL.NAWビットが1でなければ、常に書き込まれる。L
PSTART及びLPENDへの格納は命令トレースが静的にイネ
ーブルになる時にのみ書き込まれる。これらの全てのレ
ジスタへの格納はSRSPECパケットを使用して書き込まれ
る。RTT_PKT_CTLレジスタ値は各SEGSTARTパケットに
も書き込まれる。DTOビットはDATAパケットがセグメン
ト命令オフセット(Segment Instruction Offset)フィ
ールドを含むかを制御する。このフィールドはデータフ
ィルターリングの活性時に必ず存在することにより、ト
レースデコーダがロード/格納命令の記録を決定できな
ければならない。これはリセット時にゼロにセットされ
る。RTT_PKT_CTLレジスタはRTTの使用不可の時にのみ
書き込まれることができる。これはたとえSR命令により
RTT_PKT_CTLレジスタに書き込むことができるとして
も一旦RTTがイネーブルとなれば、必ずホストインター
フェースにより書き込まれる必要はない。この後者の場
合はパケット生成及びフォーマットを制御できるように
コア上の実行プログラムに対するトレースを可能にす
る。
ーダのためにパケットストリームに記録されなければな
らない実行時間RTTオプションを制御する。 各ビットは1にセットされてイネーブルとなり、ゼロに
セットされて使用不可となる。ビットの意味は次の表に
よって与えられる。 ダイナミックエネイブルな全てのビットはリセット時に
ゼロにセットされる。命令タイミングトレースがダイナ
ミックエネイブルであれば、命令トレースもダイナミッ
クエネイブルにならなければならない。UPC(Use Pass C
ounts)ビットは後方向条件付きブランチパスカウンタ、
ゼロオーバーヘッドループパスカウンタ及び関連パケッ
ト(BCBPC、LPPC、BCBPCOV、LPPCOV)のイネーブル/使用
不可になる。このビットはRTTの使用不可の時にのみ変
更できる。UPCビットはリセット時にゼロにセットされ
る。LCMビットはゼロにセットされて動機命令トレース
の記録のための高圧縮モードを使用し、1にセットされ
て底圧縮モードを使用する。このビットはRTTの使用不
可の時にのみ変更できる。これはリセット時にゼロにセ
ットされる。STRビットはSTALLパケットがストール理
由フィールドを含んでいるかを制御する。STRはリセッ
ト時にゼロにセットされる。LDビットが1であれば、AD
V及びDAビットのうち、一つまたは二つ全て1にならな
ければならない。もしST、LR、またはSRビットのいずれ
かが1であれば、SDV及びDAビットの一つまたは二つ全
て1にならなければならない。ADV、SDV、またはDAビッ
トのいずれかが1であれば、データトレースはイネーブ
ルとなる。もし、データトレースまたは命令タイミング
トレースがイネーブルとなれば、命令トレースやはりト
レースデコードがトレースをデコードできるようにする
ためにイネーブルとならなければならない。RTT_USE
R、RTT_PKT_CTL、LPSTART、及びLPNEDレジスタへのSR
命令のためにSDV、DA、及びSRビットは無視される。RTT
_USER及びRTT_PKT_CTLレジスタへの格納はRTT_HOST
_CTL.NAWビットが1でなければ、常に書き込まれる。L
PSTART及びLPENDへの格納は命令トレースが静的にイネ
ーブルになる時にのみ書き込まれる。これらの全てのレ
ジスタへの格納はSRSPECパケットを使用して書き込まれ
る。RTT_PKT_CTLレジスタ値は各SEGSTARTパケットに
も書き込まれる。DTOビットはDATAパケットがセグメン
ト命令オフセット(Segment Instruction Offset)フィ
ールドを含むかを制御する。このフィールドはデータフ
ィルターリングの活性時に必ず存在することにより、ト
レースデコーダがロード/格納命令の記録を決定できな
ければならない。これはリセット時にゼロにセットされ
る。RTT_PKT_CTLレジスタはRTTの使用不可の時にのみ
書き込まれることができる。これはたとえSR命令により
RTT_PKT_CTLレジスタに書き込むことができるとして
も一旦RTTがイネーブルとなれば、必ずホストインター
フェースにより書き込まれる必要はない。この後者の場
合はパケット生成及びフォーマットを制御できるように
コア上の実行プログラムに対するトレースを可能にす
る。
【0370】RTT_EN_DIS_CTL レジスタ
RTT_EN_DIS_CTLレジスタはRTTのイネーブルまたは使
用不可の時にパケットストリームに記録されてはならな
いし、また変更が可能な実行時間RTTオプションを制御
する。 FT(Full Trace)ビットが1であれば、フルトレースモ
ードは活性である。フルトレースモードの活性時に、こ
のRTTは命令が段階4に到達する時にコアのストールリ
ングを開始し、パケットパイプラインにより受け取られ
た(或る)命令により全てのパケットが潜在的に生成さ
れる時、これのストールを消去する。フルトレースが活
性でならば、命令タイミングトレース及びイベントタイ
ミングトレースは使用不可になる(RTT_PKT_CTLのITT
及びETTビットは0になる)。FTビットはリセット時にゼ
ロにセットされる。
用不可の時にパケットストリームに記録されてはならな
いし、また変更が可能な実行時間RTTオプションを制御
する。 FT(Full Trace)ビットが1であれば、フルトレースモ
ードは活性である。フルトレースモードの活性時に、こ
のRTTは命令が段階4に到達する時にコアのストールリ
ングを開始し、パケットパイプラインにより受け取られ
た(或る)命令により全てのパケットが潜在的に生成さ
れる時、これのストールを消去する。フルトレースが活
性でならば、命令タイミングトレース及びイベントタイ
ミングトレースは使用不可になる(RTT_PKT_CTLのITT
及びETTビットは0になる)。FTビットはリセット時にゼ
ロにセットされる。
【0371】RTT_SEG_CTL レジスタ
RTT_SEG_CTLレジスタは最大命令カウントに基づいて
新しいセグメントの生成を制御する。 SEGMAXフィールドはセグメント命令オフセットに対す
る最大値を含む。この最大値はRTT内のパイプリングに
より2個の命令を超過する場合があり、遅延スロット内
の各命令を超過する場合がある(セグメントは遅延スロ
ットで開始されることができない)。ノーマルコアコー
ドは遅延スロットに命令を出さないので、遅延スロット
はセグメント内で1までだけ最大命令が増加される効果
がある。したがって、カウンタのオーバーフローを避け
ることができるSEGMAXに対する最大リガール値Sは0×
7ffcである。SEGMAXはリセット時にこの値にセッ
トされる。SEGMAXフィールドが現在のセグメント命令
オフセットより大きいならば、SEGMAX限界は次のセグ
メントの開始時まで影響を与えないようになる。
新しいセグメントの生成を制御する。 SEGMAXフィールドはセグメント命令オフセットに対す
る最大値を含む。この最大値はRTT内のパイプリングに
より2個の命令を超過する場合があり、遅延スロット内
の各命令を超過する場合がある(セグメントは遅延スロ
ットで開始されることができない)。ノーマルコアコー
ドは遅延スロットに命令を出さないので、遅延スロット
はセグメント内で1までだけ最大命令が増加される効果
がある。したがって、カウンタのオーバーフローを避け
ることができるSEGMAXに対する最大リガール値Sは0×
7ffcである。SEGMAXはリセット時にこの値にセッ
トされる。SEGMAXフィールドが現在のセグメント命令
オフセットより大きいならば、SEGMAX限界は次のセグ
メントの開始時まで影響を与えないようになる。
【0372】RTT_DIS_CTL レジスタ
RTT_DIS_CTLレジスタはパケットストリップ内で記録
されてはならないし、RTTの使用不可の時にだけセット
できる実行時間RTTオプションを制御する。このレジス
タはRTTのイネーブル時に記録されてはならない。 MM(最小モード)ビットはキャプチャ装置が“以後”トリ
ガーに対してセットアップされた時に使われる。もしMM
が1でRTTがトリガーされなければ、FT(RTT_EN_DIS_
RTTレジスタ内の)、EXT、APT及びRTT_PKT_CTLレジス
タ内の静的なイネーブルの値は無視され、ITT及びETTを
除いては0に処理される。もしITT及び/またはETTが1
であれば、タイムスタンプはイネーブルであり、タイム
スタンプオーバーフローは記録されない。もしITTが1
であれば、ストールパケットは生成されない。EXT及びA
PTのオーバーランは記録されない。TSOVパケット以外
に、最小モード時に他の何らのパケットも生成されない
ので、バッファのオーバーフローは実質的に除去され
る。RTTがトリガーされると、FT、EXT、APT及びRTT_PK
T_CTLレジスタ内の静的なイネーブルの値はこれ以上無
視されない。MMビットはリセット時にゼロにセットされ
る。INT(Interrupt)ビットはINTパケットの生成に対し
て静的にイネーブルである。命令トレースが静的及びダ
イナミックエネイブルであれば(RTT_PKT_CTLのITビッ
トは1であり、モニターからの動的なイネーブルは1で
ある)、INTビットは無視される。これはリセット時にゼ
ロにセットされる。MD(Manual Disable)ビットが0で
あれば、RTTはコアの使用不可の後に(すなわち、状態レ
ジスタ内のホールトビットが0から1に変換)RTTは1周
期使用不可となる。これはリセット時にゼロにセットさ
れる。EXT(外部信号)ビットはEXTSIGパケットの生成に
対して静的にイネーブルである。これはリセット時にゼ
ロにセットされる。APT(Actionpoint Event)ビットはA
PEパケットの生成に対して静的にイネーブルである。こ
れはリセット時にゼロにセットされる。
されてはならないし、RTTの使用不可の時にだけセット
できる実行時間RTTオプションを制御する。このレジス
タはRTTのイネーブル時に記録されてはならない。 MM(最小モード)ビットはキャプチャ装置が“以後”トリ
ガーに対してセットアップされた時に使われる。もしMM
が1でRTTがトリガーされなければ、FT(RTT_EN_DIS_
RTTレジスタ内の)、EXT、APT及びRTT_PKT_CTLレジス
タ内の静的なイネーブルの値は無視され、ITT及びETTを
除いては0に処理される。もしITT及び/またはETTが1
であれば、タイムスタンプはイネーブルであり、タイム
スタンプオーバーフローは記録されない。もしITTが1
であれば、ストールパケットは生成されない。EXT及びA
PTのオーバーランは記録されない。TSOVパケット以外
に、最小モード時に他の何らのパケットも生成されない
ので、バッファのオーバーフローは実質的に除去され
る。RTTがトリガーされると、FT、EXT、APT及びRTT_PK
T_CTLレジスタ内の静的なイネーブルの値はこれ以上無
視されない。MMビットはリセット時にゼロにセットされ
る。INT(Interrupt)ビットはINTパケットの生成に対し
て静的にイネーブルである。命令トレースが静的及びダ
イナミックエネイブルであれば(RTT_PKT_CTLのITビッ
トは1であり、モニターからの動的なイネーブルは1で
ある)、INTビットは無視される。これはリセット時にゼ
ロにセットされる。MD(Manual Disable)ビットが0で
あれば、RTTはコアの使用不可の後に(すなわち、状態レ
ジスタ内のホールトビットが0から1に変換)RTTは1周
期使用不可となる。これはリセット時にゼロにセットさ
れる。EXT(外部信号)ビットはEXTSIGパケットの生成に
対して静的にイネーブルである。これはリセット時にゼ
ロにセットされる。APT(Actionpoint Event)ビットはA
PEパケットの生成に対して静的にイネーブルである。こ
れはリセット時にゼロにセットされる。
【0373】RTT_BUF_CTLレジスタ
RTT_BUF_CTL(バッファ制御)レジスタは、バッファを
制御する。このレジスタは、RTTがイネーブルになった
時には記録されてはならない。 DFR(デセイブルFIFO RAM)ビットが1ならば、FIFO RAM
に対するアクセスは、読み取り/書き込み命令をRTT_FI
FO_CMDレジスタに記録することによって開始される。
このモードは、BISTのように他の構造を必要とする代わ
りに、ただFIFORAMがテストされることを許容するため
に提供される。ノーマル動作のあいだ、DFRビットは、
0にならなければならない。リセット時には、0にセッ
トされる。仮りにIO(インタラプトオーバーフロー)ビッ
トが1であり、かつバッファオーバーフローが発生すれ
ば、コアは、インタラプトされる。IOビットに0が記録
され、かつインタラプトが活性ならば、インタラプト
は、活性のまま維持される。インタラプトは、命令をRT
T_CMDレジスタに記録することによって消去される。IO
ビットは、リセット時に0にセットされる。MFFE(最大
フルFIFOエントリー)フィールドは、RTTがバッファオー
バーフローを消去する前に、完全にフルとなるように許
容されたFIFOエントリーの最大数を指定する。FIFOエン
トリーの全体数と同一の値は、FIFOが完全に分析され、
バッファオーバーフローが消去されるように許容する。
0値は、バッファオーバーフローが消去される前に、FI
FOが強制的に空きになるようにする。MFFE値は、リセッ
ト時に、0にセットされる。
制御する。このレジスタは、RTTがイネーブルになった
時には記録されてはならない。 DFR(デセイブルFIFO RAM)ビットが1ならば、FIFO RAM
に対するアクセスは、読み取り/書き込み命令をRTT_FI
FO_CMDレジスタに記録することによって開始される。
このモードは、BISTのように他の構造を必要とする代わ
りに、ただFIFORAMがテストされることを許容するため
に提供される。ノーマル動作のあいだ、DFRビットは、
0にならなければならない。リセット時には、0にセッ
トされる。仮りにIO(インタラプトオーバーフロー)ビッ
トが1であり、かつバッファオーバーフローが発生すれ
ば、コアは、インタラプトされる。IOビットに0が記録
され、かつインタラプトが活性ならば、インタラプト
は、活性のまま維持される。インタラプトは、命令をRT
T_CMDレジスタに記録することによって消去される。IO
ビットは、リセット時に0にセットされる。MFFE(最大
フルFIFOエントリー)フィールドは、RTTがバッファオー
バーフローを消去する前に、完全にフルとなるように許
容されたFIFOエントリーの最大数を指定する。FIFOエン
トリーの全体数と同一の値は、FIFOが完全に分析され、
バッファオーバーフローが消去されるように許容する。
0値は、バッファオーバーフローが消去される前に、FI
FOが強制的に空きになるようにする。MFFE値は、リセッ
ト時に、0にセットされる。
【0374】RTT_MON_CTLレジスタ
RTT_MON_CTLレジスタは、一つ以上のモニターに影響
を及ぼす動作を制御する。このレジスタは、RTTがイネ
ーブルになる時、記録されてはならない。RTT_MON_CT
Lレジスタの内容は、次の通りである。 DYEN(ダイナミックイネーブル)フィールドは、各ダイナ
ミックイネーブルの現在値を含む。これらは、リセット
時、0にセットされる。DYENフィールド内の各ビットの
意味は、次の通りである。 仮りにタイミングトレースが設計上になければ、ビット
1は0になる。仮りにデータトレースが設計上になけれ
ば、ビット2は0になる。STARTEN(開始イネーブル)フ
ィールドは、許容または防止フィルターが活性でない時
に使われる各ダイナミックイネーブルの値を含む。これ
らは、リセット時、0にセットされる。PAIRSフィール
ドは、4ビットのアレイ(array)である。仮りにビットn
が1ならば、モニター(2nと2n+1)に対する条件の結
果が共にAND演算され、二つのモニターに対する条件と
なる。PAIRSフィールドは、リセット時、0にセットさ
れる。QUADSフィールドは、2ビットのアレイ(array)で
ある。仮りにビットnが1ならば、モニター(4n、4n+
1、4n+2及び4n+3)に対する条件の結果が共にAND演
算され、これら4つの全てのモニターに対する条件とな
る。QUADSフィールドは、リセット時、0にセットされ
る。
を及ぼす動作を制御する。このレジスタは、RTTがイネ
ーブルになる時、記録されてはならない。RTT_MON_CT
Lレジスタの内容は、次の通りである。 DYEN(ダイナミックイネーブル)フィールドは、各ダイナ
ミックイネーブルの現在値を含む。これらは、リセット
時、0にセットされる。DYENフィールド内の各ビットの
意味は、次の通りである。 仮りにタイミングトレースが設計上になければ、ビット
1は0になる。仮りにデータトレースが設計上になけれ
ば、ビット2は0になる。STARTEN(開始イネーブル)フ
ィールドは、許容または防止フィルターが活性でない時
に使われる各ダイナミックイネーブルの値を含む。これ
らは、リセット時、0にセットされる。PAIRSフィール
ドは、4ビットのアレイ(array)である。仮りにビットn
が1ならば、モニター(2nと2n+1)に対する条件の結
果が共にAND演算され、二つのモニターに対する条件と
なる。PAIRSフィールドは、リセット時、0にセットさ
れる。QUADSフィールドは、2ビットのアレイ(array)で
ある。仮りにビットnが1ならば、モニター(4n、4n+
1、4n+2及び4n+3)に対する条件の結果が共にAND演
算され、これら4つの全てのモニターに対する条件とな
る。QUADSフィールドは、リセット時、0にセットされ
る。
【0375】RTT_TRIG_SRCレジスタ
RTT_TRIG_SRCレジスタは、可能なソース中のどれがト
リガーを引き起こしたかを指定する。このレジスタは、
RTTが以前にトリガーされない場合にだけ、セットされ
る。RTT_TRIG_SRCレジスタの内容は、次の通りであ
る。 MONフィールドは、設計上に存在する各モニターに対す
るビットを含む。モニターがRTTをトリガーすれば、対
応するMONビットは、1にセットされる。MONフィールド
は、リセット時、0にセットされる。CMDビットは、RTT
_CMDレジスタに対する記録がRTTをトリガーすれば、1
にセットされる。CMDフィールドは、リセット時、0に
セットされる。SIGビットは、仮りに入力信号(rtt_tri
g_on)がRTTをトリガーすれば、1にセットされる。SIG
フィールドは、リセット時、0にセットされる。
リガーを引き起こしたかを指定する。このレジスタは、
RTTが以前にトリガーされない場合にだけ、セットされ
る。RTT_TRIG_SRCレジスタの内容は、次の通りであ
る。 MONフィールドは、設計上に存在する各モニターに対す
るビットを含む。モニターがRTTをトリガーすれば、対
応するMONビットは、1にセットされる。MONフィールド
は、リセット時、0にセットされる。CMDビットは、RTT
_CMDレジスタに対する記録がRTTをトリガーすれば、1
にセットされる。CMDフィールドは、リセット時、0に
セットされる。SIGビットは、仮りに入力信号(rtt_tri
g_on)がRTTをトリガーすれば、1にセットされる。SIG
フィールドは、リセット時、0にセットされる。
【0376】RTT_USERレジスタ
RTT_USERレジスタに記録される時、トレース内の値を
記録するために、SRSPECパケットが生成される。これ
は、トレースされるプログラムが“cookies”(クッキ
ー)をトレース内に挿入するように許容する。 RTT_FIFO_STATレジスタ RTT_FIFO_STATレジスタは、FIFOの状態を表す。 FMTビットは、FIFOが空きになると、1であり、そうで
ない場合、0である。このビットは、リセット時、0に
セットされる。FHD及びFTLフィールドは、FIFOヘッドと
FIFOテール(tail)ポインタを各々含む。ポインタは、FI
FOメモリに対するアドレスである。FIFOは、ポインタが
同一であり、FMTビットが0ならば、フルとなる。この
ポインタは、リセット時、0にセットされる。
記録するために、SRSPECパケットが生成される。これ
は、トレースされるプログラムが“cookies”(クッキ
ー)をトレース内に挿入するように許容する。 RTT_FIFO_STATレジスタ RTT_FIFO_STATレジスタは、FIFOの状態を表す。 FMTビットは、FIFOが空きになると、1であり、そうで
ない場合、0である。このビットは、リセット時、0に
セットされる。FHD及びFTLフィールドは、FIFOヘッドと
FIFOテール(tail)ポインタを各々含む。ポインタは、FI
FOメモリに対するアドレスである。FIFOは、ポインタが
同一であり、FMTビットが0ならば、フルとなる。この
ポインタは、リセット時、0にセットされる。
【0377】RTT_FIFO_CMDレジスタ
RTT_FIFO_CMDレジスタは、FIFO RAMと、RTT_FIFO_D
ATA0、RTT_FIFO_DATA1及びRTT_FIFO_DATASレジス
タ間のデータ伝達をトリガーする。このレジスタは、RT
T_BUF_CTL.DFRビットが1である時にだけ、記録され
る。RTT_FIFO_CMDレジスタは、ただテストのために提
供され、ノーマル動作時に、RTT_FIFO_CMDレジスタは
記録されてはならない。このレジスタは、RTTがアネー
ブルされる時、記録されてはならない。 WRビットは、FIFO RAMが記録されるか(WR=1)、または
読み取られるか(WR=1)を制御する。FIFO RAMが記録さ
れる時、RTT_FIFO_ADDRレジスタにより指定されたア
ドレスのRAM内容がRTT_FIFO_DATA0、RTT_FIFO_DAT
A1及びRTT_FIFO_DATASレジスタの内容で記録され
る。FIFO RAMが読み取られる時、RTT_FIFO_DATA0、R
TT_FIFO_DATA1及びRTT_FIFO_DATASレジスタは、RT
T_FIFO_ADDRレジスタにより指定されたアドレスのRAM
内容でロードされる。 RTT_FIFO_ADDRレジスタ RTT_FIFO_ADDRレジスタは、読み取りまたは書き込み
命令がRTT_FIFO_CMDレジスタに記録される時、記録さ
れたり読み取られるアドレスを提供する。このレジスタ
は、RTTがイネーブルされる時、記録されてはならな
い。
ATA0、RTT_FIFO_DATA1及びRTT_FIFO_DATASレジス
タ間のデータ伝達をトリガーする。このレジスタは、RT
T_BUF_CTL.DFRビットが1である時にだけ、記録され
る。RTT_FIFO_CMDレジスタは、ただテストのために提
供され、ノーマル動作時に、RTT_FIFO_CMDレジスタは
記録されてはならない。このレジスタは、RTTがアネー
ブルされる時、記録されてはならない。 WRビットは、FIFO RAMが記録されるか(WR=1)、または
読み取られるか(WR=1)を制御する。FIFO RAMが記録さ
れる時、RTT_FIFO_ADDRレジスタにより指定されたア
ドレスのRAM内容がRTT_FIFO_DATA0、RTT_FIFO_DAT
A1及びRTT_FIFO_DATASレジスタの内容で記録され
る。FIFO RAMが読み取られる時、RTT_FIFO_DATA0、R
TT_FIFO_DATA1及びRTT_FIFO_DATASレジスタは、RT
T_FIFO_ADDRレジスタにより指定されたアドレスのRAM
内容でロードされる。 RTT_FIFO_ADDRレジスタ RTT_FIFO_ADDRレジスタは、読み取りまたは書き込み
命令がRTT_FIFO_CMDレジスタに記録される時、記録さ
れたり読み取られるアドレスを提供する。このレジスタ
は、RTTがイネーブルされる時、記録されてはならな
い。
【0378】RTT_FIFO_DATA0レジスタ
RTT_FIFO_DATA0レジスタは、パケット部分0を維持
する。最下位ニブルは、ビットオフセット0で始まる。
仮りに読み取り命令がRTT_FIFO_CMDレジスタに記録さ
れれば、このレジスタは、次の週期でRAMからロードさ
れる。仮りに書き込み命令がRTT_FIFO_CMDレジスタに
記録されれば、このレジスタは、次の週期にRAMに記録
される。コアまたはホストがこのレジスタに記録しよう
と試みると同時に、このレジスタがRAMからロードされ
るならば、コアまたはホストは無視される。このレジス
タは、RTTがイネーブルになる時、記録されてはならな
い。 RTT_FIFO_DATA1レジスタ RTT_FIFO_DATA1レジスタは、RTT_FIFO_DATA1レジ
スタがパケット部分1を含むことを除いて、RTT_FIFO
_DATA0レジスタと同一に作用する。このレジスタは、
RTTがイネーブルになる時、記録されてはならない。
する。最下位ニブルは、ビットオフセット0で始まる。
仮りに読み取り命令がRTT_FIFO_CMDレジスタに記録さ
れれば、このレジスタは、次の週期でRAMからロードさ
れる。仮りに書き込み命令がRTT_FIFO_CMDレジスタに
記録されれば、このレジスタは、次の週期にRAMに記録
される。コアまたはホストがこのレジスタに記録しよう
と試みると同時に、このレジスタがRAMからロードされ
るならば、コアまたはホストは無視される。このレジス
タは、RTTがイネーブルになる時、記録されてはならな
い。 RTT_FIFO_DATA1レジスタ RTT_FIFO_DATA1レジスタは、RTT_FIFO_DATA1レジ
スタがパケット部分1を含むことを除いて、RTT_FIFO
_DATA0レジスタと同一に作用する。このレジスタは、
RTTがイネーブルになる時、記録されてはならない。
【0379】RTT_FIFO_DATASレジスタ
RTT_FIFO_DATASレジスタは、RTT_FIFO_DATASレジス
タが状態ビットを含むことを除いて、RTT_FIFO_DATA
0レジスタと同一に作用する。このレジスタは、RTTが
イネーブルになる時、記録されてはならない。 SIZE0及びSIZE1フィールドは、パケット部分0及び1
サイズに各々対応する。これらは、各々次の通りエンコ
ーディングされる。
タが状態ビットを含むことを除いて、RTT_FIFO_DATA
0レジスタと同一に作用する。このレジスタは、RTTが
イネーブルになる時、記録されてはならない。 SIZE0及びSIZE1フィールドは、パケット部分0及び1
サイズに各々対応する。これらは、各々次の通りエンコ
ーディングされる。
【0380】RTT_MON_COND0ないしRTT_MON_COND7
レジスタ 各RTT_MON_CONDレジスタは、単一モニターの条件をセ
ットアップするために使われる。仮りに関連モニターが
RTT内に存在しないならば、読み取りは、0をリターン
し、記録は無視される。これらのレジスタは、RTTがイ
ネーブルされる時、記録されてはならない。各RTT_MON
_CONDレジスタの内容は、次の通りである。 DYEN(ダイナミックイネーブル)フィールドは、フィルタ
ーとして構成される時、モニターによりどのダイナミッ
クイネーブルが影響を受けるかを指定する。仮りにビッ
トが1ならば、対応するダイナミックイネーブル(RTT_
NON_CTLレジスタ内のDYENフィールドを参照)がフィル
ターにより影響を受ける。影響は、モニターと関連した
アクション(ACTフィールド)により決定される。DYENフ
ィールドは、リセットされる時、0にセットされる。SR
C(条件ソース)フィールドは、モニター条件評価のため
に使われたパイプラインからソース値を指定する。この
フィールドは、リセットされる時、0にセットされる。
データトレースが設計上に存在しない時、SRCフィール
ドは、0である。フィールドの意味は、次の通りであ
る。
レジスタ 各RTT_MON_CONDレジスタは、単一モニターの条件をセ
ットアップするために使われる。仮りに関連モニターが
RTT内に存在しないならば、読み取りは、0をリターン
し、記録は無視される。これらのレジスタは、RTTがイ
ネーブルされる時、記録されてはならない。各RTT_MON
_CONDレジスタの内容は、次の通りである。 DYEN(ダイナミックイネーブル)フィールドは、フィルタ
ーとして構成される時、モニターによりどのダイナミッ
クイネーブルが影響を受けるかを指定する。仮りにビッ
トが1ならば、対応するダイナミックイネーブル(RTT_
NON_CTLレジスタ内のDYENフィールドを参照)がフィル
ターにより影響を受ける。影響は、モニターと関連した
アクション(ACTフィールド)により決定される。DYENフ
ィールドは、リセットされる時、0にセットされる。SR
C(条件ソース)フィールドは、モニター条件評価のため
に使われたパイプラインからソース値を指定する。この
フィールドは、リセットされる時、0にセットされる。
データトレースが設計上に存在しない時、SRCフィール
ドは、0である。フィールドの意味は、次の通りであ
る。
【0381】LD、ST、LR及びSRビットは、パスするため
の条件に対してどの方向及びどのメモリ空間が観測され
るかを指定する。仮りにソースが命令アドレスならば、
これらのビットは、無視される。仮りにソースがデータ
アドレスまたはデータ値ならば、これらの4ビットのう
ち少なくともひとつは、セットされなければならない。
ビットの意味は、次の通りである。 REL(条件関係)フィールドは、モニター条件評価のため
に使われた関係を指定する。このフィールドは、リセッ
トされる時、0にセットされる。このフィールドの意味
は、次の通りである。
の条件に対してどの方向及びどのメモリ空間が観測され
るかを指定する。仮りにソースが命令アドレスならば、
これらのビットは、無視される。仮りにソースがデータ
アドレスまたはデータ値ならば、これらの4ビットのう
ち少なくともひとつは、セットされなければならない。
ビットの意味は、次の通りである。 REL(条件関係)フィールドは、モニター条件評価のため
に使われた関係を指定する。このフィールドは、リセッ
トされる時、0にセットされる。このフィールドの意味
は、次の通りである。
【0382】ACT(アクション)は、モニター条件が真に
なる時、モニターの動作を指定する。このフィールド
は、リセットされる時、0にセットされる。このフィー
ルドの意味は、次の通りである。 モニター条件が発生する時、仮りにTRIGフィールドが
(に)1ならば、RTTはトリガーなることだ(既にトリガ
ーなったとすれば無視される)。 RTT_MON_REF0ないしRTT_MON_REF7レジスタ RTT_MON_REFレジスタは、一つのモニターに対して3
2ビット基準値を含む。仮りに関連モニターがRTT内に
存在しないならば、読み取りは、0をリターンし、記録
は無視される。これらのレジスタは、RTTがイネーブル
される時、記録されてはならない。各RTT_MON_REFレ
ジスタの内容は、次の通りである。 VALUE(値)フィールドは、正確にモニターに対する32
ビット基準値を含む。このフィールドは、長い(long)-
ワードで整列された命令アドレス、1バイトで整列され
たデータアドレスまたはデータ値を含むことができる。
このフィールドは、リセットされる時、0にセットされ
る。仮りにデータトレースが設計上に存在しないなら
ば、値フィールドの最上位8ビットが0であり、その理
由は、唯一の基準値は、ただ24ビットの命令アドレス
であるからである。
なる時、モニターの動作を指定する。このフィールド
は、リセットされる時、0にセットされる。このフィー
ルドの意味は、次の通りである。 モニター条件が発生する時、仮りにTRIGフィールドが
(に)1ならば、RTTはトリガーなることだ(既にトリガ
ーなったとすれば無視される)。 RTT_MON_REF0ないしRTT_MON_REF7レジスタ RTT_MON_REFレジスタは、一つのモニターに対して3
2ビット基準値を含む。仮りに関連モニターがRTT内に
存在しないならば、読み取りは、0をリターンし、記録
は無視される。これらのレジスタは、RTTがイネーブル
される時、記録されてはならない。各RTT_MON_REFレ
ジスタの内容は、次の通りである。 VALUE(値)フィールドは、正確にモニターに対する32
ビット基準値を含む。このフィールドは、長い(long)-
ワードで整列された命令アドレス、1バイトで整列され
たデータアドレスまたはデータ値を含むことができる。
このフィールドは、リセットされる時、0にセットされ
る。仮りにデータトレースが設計上に存在しないなら
ば、値フィールドの最上位8ビットが0であり、その理
由は、唯一の基準値は、ただ24ビットの命令アドレス
であるからである。
【0383】付録IV
レジスタ定義(バッファ/パケットパイプライン)
RTT_STATレジスタ
唯1ビット状態レジスタがパケットパイプラインに該当
する。これは、オーバーフロービットOVである。RTT_S
TATレジスタは、RTTの状態を表す。仮りにRTT_STATレ
ジスタがコアまたはホストにより記録されるならば、IR
Qビットが0にセットされ、他のすべてのビットは変化
しない。 ENビットは、RTTがイネーブルになると、1である。こ
のビットは、リセットされる時、0にセットされる。TR
ビットは、RTTがトリガーされると、1である。このビ
ットは、リセットされる時、0にセットされる。IRQビ
ットは、RTTがインタラプト信号をARCに断定(assert)す
れば、1である。このビットは、リセットされる時、0
にセットされる。OVビットは、RTTバッファがオーバー
フロー状態である時、1である。このビットは、リセッ
トされる時、0にセットされる。このフィールドは、テ
スト用途として提供される。TSO(タイムスタンプオーバ
ーラン)、APO(アクションポイントオーバーラン)及びES
O(外部信号オーバーラン)ビットは、これらの対応メカ
ニズムがオーバーランされる時、1にセットされる。こ
れらは、リセットされる時、0にセットされる。一つの
オーバーランは、イベントが損失される時に引き起こさ
れるが、なぜなら以前のイベントがパケットに記録され
る前に、さらに発生するからである。PMTビットは、RTT
バッファ内のパケットパイプラインが空きになったら、
1であり、そうでない場合は、0である。このビット
は、リセットされる時、0にセットされる。このフィー
ルドは、テスト用途として提供される。TMTビットは、
パケットポートがアンロックされると、1であり、そう
でない場合は、0である。このビットは、リセットされ
る時、0にセットされる。このフィールドは、テスト用
途として提供される。ULビットは、RTTがアンロックさ
れると、1である。RTTは、RTT_LOCKレジスタが特定値
で書き込まれる時、アンロックされ、次のSR命令後に、
さらにロックされる。BCBPCは、後方向条件付き分岐パ
スカウンタの値を含む。このフィールドは、リセットさ
れる時、0にセットされる。このフィールドは、テスト
用途として提供される。LPPCは、ゼロ-オーバーヘッド
ループパスカウンタの値を含む。このフィールドは、テ
スト用途として提供される。
する。これは、オーバーフロービットOVである。RTT_S
TATレジスタは、RTTの状態を表す。仮りにRTT_STATレ
ジスタがコアまたはホストにより記録されるならば、IR
Qビットが0にセットされ、他のすべてのビットは変化
しない。 ENビットは、RTTがイネーブルになると、1である。こ
のビットは、リセットされる時、0にセットされる。TR
ビットは、RTTがトリガーされると、1である。このビ
ットは、リセットされる時、0にセットされる。IRQビ
ットは、RTTがインタラプト信号をARCに断定(assert)す
れば、1である。このビットは、リセットされる時、0
にセットされる。OVビットは、RTTバッファがオーバー
フロー状態である時、1である。このビットは、リセッ
トされる時、0にセットされる。このフィールドは、テ
スト用途として提供される。TSO(タイムスタンプオーバ
ーラン)、APO(アクションポイントオーバーラン)及びES
O(外部信号オーバーラン)ビットは、これらの対応メカ
ニズムがオーバーランされる時、1にセットされる。こ
れらは、リセットされる時、0にセットされる。一つの
オーバーランは、イベントが損失される時に引き起こさ
れるが、なぜなら以前のイベントがパケットに記録され
る前に、さらに発生するからである。PMTビットは、RTT
バッファ内のパケットパイプラインが空きになったら、
1であり、そうでない場合は、0である。このビット
は、リセットされる時、0にセットされる。このフィー
ルドは、テスト用途として提供される。TMTビットは、
パケットポートがアンロックされると、1であり、そう
でない場合は、0である。このビットは、リセットされ
る時、0にセットされる。このフィールドは、テスト用
途として提供される。ULビットは、RTTがアンロックさ
れると、1である。RTTは、RTT_LOCKレジスタが特定値
で書き込まれる時、アンロックされ、次のSR命令後に、
さらにロックされる。BCBPCは、後方向条件付き分岐パ
スカウンタの値を含む。このフィールドは、リセットさ
れる時、0にセットされる。このフィールドは、テスト
用途として提供される。LPPCは、ゼロ-オーバーヘッド
ループパスカウンタの値を含む。このフィールドは、テ
スト用途として提供される。
【0384】RTT_CMDレジスタ
RTT_CMDレジスタに対する消去バッファ命令は、パケッ
トパイプライン上で同期リセットを效果的に行う。RTT
_CMDレジスタは、次の命令中のひとつをRTTに伝達する
のに使われる。 RTT_CMDレジスタのフォーマットは、次の通りである。 CMD_NS命令は、次の非−遅延スロット命令またはイン
タラプト後、新しいセグメントを開始する。仮りにSR命
令により書き込まれると、新しいセグメントは、SR命令
以後に始まる。CMD_CB命令は、バッファの内容を消去
する。このフィールドは、テスト用途として提供され
る。
トパイプライン上で同期リセットを效果的に行う。RTT
_CMDレジスタは、次の命令中のひとつをRTTに伝達する
のに使われる。 RTT_CMDレジスタのフォーマットは、次の通りである。 CMD_NS命令は、次の非−遅延スロット命令またはイン
タラプト後、新しいセグメントを開始する。仮りにSR命
令により書き込まれると、新しいセグメントは、SR命令
以後に始まる。CMD_CB命令は、バッファの内容を消去
する。このフィールドは、テスト用途として提供され
る。
【0385】付録V
例示的な平滑ユニットテストコードシナリオ
DF1 ストールを発生させたり回避するために命令及び
データキャッシュを使用。 DF2 パイプラインストールが生成せず、命令が毎周期
に実行されるようにするために、単一の周期命令を連続
的に実行。 DF3 一つのステージが次のステージからの結果に依存
するパイプラインのステージ間依存性。例えば、非演算
子ベチは、以前命令の再書き込みステージに依存する。 DF4 二つの命令が隣接し、第2の命令は、第1の命令
から生成された結果を使用し、第2の命令は、第1の命
令が結果を発生させる時まで待機する、一対の命令に対
する検査。これは、連続的なループで行われなければな
らない。メモリ及びコアレジスタアクセスの両方のため
に、これを使用。第1の結果をリターンさせるにあたっ
て遅延を保障するために、第1の命令は、ld.diでなけ
ればならない。演算を含む命令の範囲が使われなければ
ならず、分岐及び特別なこと(flag,swi, blk, sleep)
が第2の命令として使われることができる。また、ld及
びld. di命令の異なる組合を試みる。
データキャッシュを使用。 DF2 パイプラインストールが生成せず、命令が毎周期
に実行されるようにするために、単一の周期命令を連続
的に実行。 DF3 一つのステージが次のステージからの結果に依存
するパイプラインのステージ間依存性。例えば、非演算
子ベチは、以前命令の再書き込みステージに依存する。 DF4 二つの命令が隣接し、第2の命令は、第1の命令
から生成された結果を使用し、第2の命令は、第1の命
令が結果を発生させる時まで待機する、一対の命令に対
する検査。これは、連続的なループで行われなければな
らない。メモリ及びコアレジスタアクセスの両方のため
に、これを使用。第1の結果をリターンさせるにあたっ
て遅延を保障するために、第1の命令は、ld.diでなけ
ればならない。演算を含む命令の範囲が使われなければ
ならず、分岐及び特別なこと(flag,swi, blk, sleep)
が第2の命令として使われることができる。また、ld及
びld. di命令の異なる組合を試みる。
【0386】DF5 連続ループでロードのシーケンス。
DF6 第3の命令は、第1命令からの再書き込み結果に
依存する。 DF7 パイプラインのステージ1、2及び3でストール
を発生させる。 DF8 ステージ1でのlimm値ストールを発生させる。 DF9 近接データによる命令の実行と同様に、2-周期
命令の連続的な実行。 DF10 単一及びマルチ周期命令の組合。 DF11 再書き込み及びALU短縮が条件フェイルによっ
てデセイブルされ、その次の命令の非演算子ベチステー
ジが再書き込みに依存するループ。 DF12 無効遅延スロットを有するか有しない分岐/ジ
ャンプループ内からサブルーチンを呼出。 DF13 一方のレジスタが以前ロードから更新されるた
めに待機し、前記レジスタは、ステージ2で命令の被演
算子中のひとつである、ロード動作。この状況で、パイ
プラインは停止する。 DF14 いろいろな最悪の場合のシナリオに対する完全
な命令セットをカバーするためのものである。テストコ
ードを参照。 DF15 平滑ブロックのアクションポイントと外部信号
の使用。 DF16 ジャンプがインタラプトからの知られた位置に
なる自己−変更コード。 DF17 ゼロオーバーヘッドループに適用される全ての
ストールテスト。 DF18 このようなストールテストコードは、タイミン
グトレースに使われる時、生成ブロックから適切なスト
ール理由を提供しなければならない。 DF19 コアパイプラインをフラッシュし、その後、RT
Tを非イネーブルとする。
依存する。 DF7 パイプラインのステージ1、2及び3でストール
を発生させる。 DF8 ステージ1でのlimm値ストールを発生させる。 DF9 近接データによる命令の実行と同様に、2-周期
命令の連続的な実行。 DF10 単一及びマルチ周期命令の組合。 DF11 再書き込み及びALU短縮が条件フェイルによっ
てデセイブルされ、その次の命令の非演算子ベチステー
ジが再書き込みに依存するループ。 DF12 無効遅延スロットを有するか有しない分岐/ジ
ャンプループ内からサブルーチンを呼出。 DF13 一方のレジスタが以前ロードから更新されるた
めに待機し、前記レジスタは、ステージ2で命令の被演
算子中のひとつである、ロード動作。この状況で、パイ
プラインは停止する。 DF14 いろいろな最悪の場合のシナリオに対する完全
な命令セットをカバーするためのものである。テストコ
ードを参照。 DF15 平滑ブロックのアクションポイントと外部信号
の使用。 DF16 ジャンプがインタラプトからの知られた位置に
なる自己−変更コード。 DF17 ゼロオーバーヘッドループに適用される全ての
ストールテスト。 DF18 このようなストールテストコードは、タイミン
グトレースに使われる時、生成ブロックから適切なスト
ール理由を提供しなければならない。 DF19 コアパイプラインをフラッシュし、その後、RT
Tを非イネーブルとする。
【0387】DF20 パイプラインのステージ4で命令
が存在する時、RTTを非イネーブルとする。他の全ての
パイプラインステージに対しても同一に繰り返し。 DF21 パイプラインのステージ4では何らの命令がな
いが、他のステージが命令を有する時、RTTを非イネー
ブルとする。他の全てのパイプラインステージに対して
も同一に繰り返し。 DF22ISR内からのループをネストさせるテストコード
を実行させる。 DF23RTTからプロセッサストールを発生させる。 DF24 ISR内の第1の命令が直接ジャンプ/分岐/条件
付き分岐などのテストコードを書き込む。 DF25 命令1がステージ4パイプラインで存在し、同
時に命令2がステージ3で止める場合を書き込み、平滑
機の最も古くなった命令アドレス信号を検査する。 DF26 命令がステージ4で存在し、次の命令2がステ
ージ1(i-ベチ)で存在する場合、すなわちそれらの間に
2周期のストールが存在する場合、この場合、平滑機の
最も古くなった命令アドレス信号が正確な値を有するか
を確認。 DF27 インタラプトシーケンスを実行し、且つ高い優
先順位インタラプトを発生させるコード。 DF28 所定の同一時間に次の状況、すなわちinst1が
ステージ4に存在し、inst2は、ステージ3で止め、in
st3は、ステージ1に存在する状況を発生させ、この場
合、平滑機の最も古くなった命令アドレス信号が正確な
値を有するかを確認。
が存在する時、RTTを非イネーブルとする。他の全ての
パイプラインステージに対しても同一に繰り返し。 DF21 パイプラインのステージ4では何らの命令がな
いが、他のステージが命令を有する時、RTTを非イネー
ブルとする。他の全てのパイプラインステージに対して
も同一に繰り返し。 DF22ISR内からのループをネストさせるテストコード
を実行させる。 DF23RTTからプロセッサストールを発生させる。 DF24 ISR内の第1の命令が直接ジャンプ/分岐/条件
付き分岐などのテストコードを書き込む。 DF25 命令1がステージ4パイプラインで存在し、同
時に命令2がステージ3で止める場合を書き込み、平滑
機の最も古くなった命令アドレス信号を検査する。 DF26 命令がステージ4で存在し、次の命令2がステ
ージ1(i-ベチ)で存在する場合、すなわちそれらの間に
2周期のストールが存在する場合、この場合、平滑機の
最も古くなった命令アドレス信号が正確な値を有するか
を確認。 DF27 インタラプトシーケンスを実行し、且つ高い優
先順位インタラプトを発生させるコード。 DF28 所定の同一時間に次の状況、すなわちinst1が
ステージ4に存在し、inst2は、ステージ3で止め、in
st3は、ステージ1に存在する状況を発生させ、この場
合、平滑機の最も古くなった命令アドレス信号が正確な
値を有するかを確認。
【0388】DF29 全ての命令がステージ3で止め、
いずれも完了しない状況。 DF30 inst1がステージ4で止め、第2の命令がベチ
ステージにある場合。(inst1ベチ以後の2周期ストー
ル)、この場合、平滑機の最も古くなった命令アドレス
信号が正確な値を有するかを確認。 DF31 データトレースが実行される状態で、LD+LDB+L
DW+LD.DI、ST+STW+STB+LR+SRを連続的なシーケンス及び
他の組合に使用する。生成されたデータアドレス及び値
が正確であるかを検査する。RTT特定レジスタに書き込
むために、それをまた使用する。生成された状態レジス
タ値をまた検査する。インタラプト及びストールをまた
発生させる。 DF32 ループでの最終命令がlimmデータを有し、最終
命令がlimmであるが、前記limmデータがループ外に位置
するゼロオーバーヘッドループを記録する。 DF33 pc_plus_oneがLP_ENDと同一になる時のゼロ
オーバーヘッドループ;最終ループ終了命令が次の周期/
周期でベチされないように、ストールを発生させる。ま
た、ゼロオーバーヘッドループでlimmデータを有するか
有しない最終命令が実行されている時、3種類のパイプ
ラインストールすべてを発生させる。 DF34 1にセットされたループカウントレジスタを有
するゼロオーバーヘッドループを実行させる。 DF35 次の事項を有するゼロオーバーヘッドループを
具現させる。すなわち DF35-1 ループをセットアップさせ、ループ内でた
だ一つの命令を持つために、LP命令を使用すること。 DF35-2 lp_countレジスタのセッティングとループ
の最終命令との間にあるただ2つの命令。 DF36 最終命令は、無条件ジャンプ命令であり、ルー
プをトリガーし、ループにさらにリターンしない、ゼロ
オーバーヘッドループ。また、ループ内の最終及び第2
の最終命令としての全ての形態のジャンプに対するコー
ド。 DF37 タイミング及びデータトレースが実行される状
態で、非常に厳格なゼロオーバーヘッドループ内でスト
ールを発生させる。また、ゼロオーバーヘッドループ内
で他の全てのパケットタイプを発生させる。 DF38 ゼロオーバーヘッドループにおいて、ループト
リガー、セグスタート(Segstart)、タイムスタンプオー
バーフロー及び全ての可能なパケットを同一の周期内に
発生させようとする。 DF39 同一の形態のジャンプ及び他の形態のジャンプ
をシーケンスに伴って、他の形態のジャンプ及びリンク
命令で終了する、条件付き及び無条件のゼロオーバーヘ
ッドループ。
いずれも完了しない状況。 DF30 inst1がステージ4で止め、第2の命令がベチ
ステージにある場合。(inst1ベチ以後の2周期ストー
ル)、この場合、平滑機の最も古くなった命令アドレス
信号が正確な値を有するかを確認。 DF31 データトレースが実行される状態で、LD+LDB+L
DW+LD.DI、ST+STW+STB+LR+SRを連続的なシーケンス及び
他の組合に使用する。生成されたデータアドレス及び値
が正確であるかを検査する。RTT特定レジスタに書き込
むために、それをまた使用する。生成された状態レジス
タ値をまた検査する。インタラプト及びストールをまた
発生させる。 DF32 ループでの最終命令がlimmデータを有し、最終
命令がlimmであるが、前記limmデータがループ外に位置
するゼロオーバーヘッドループを記録する。 DF33 pc_plus_oneがLP_ENDと同一になる時のゼロ
オーバーヘッドループ;最終ループ終了命令が次の周期/
周期でベチされないように、ストールを発生させる。ま
た、ゼロオーバーヘッドループでlimmデータを有するか
有しない最終命令が実行されている時、3種類のパイプ
ラインストールすべてを発生させる。 DF34 1にセットされたループカウントレジスタを有
するゼロオーバーヘッドループを実行させる。 DF35 次の事項を有するゼロオーバーヘッドループを
具現させる。すなわち DF35-1 ループをセットアップさせ、ループ内でた
だ一つの命令を持つために、LP命令を使用すること。 DF35-2 lp_countレジスタのセッティングとループ
の最終命令との間にあるただ2つの命令。 DF36 最終命令は、無条件ジャンプ命令であり、ルー
プをトリガーし、ループにさらにリターンしない、ゼロ
オーバーヘッドループ。また、ループ内の最終及び第2
の最終命令としての全ての形態のジャンプに対するコー
ド。 DF37 タイミング及びデータトレースが実行される状
態で、非常に厳格なゼロオーバーヘッドループ内でスト
ールを発生させる。また、ゼロオーバーヘッドループ内
で他の全てのパケットタイプを発生させる。 DF38 ゼロオーバーヘッドループにおいて、ループト
リガー、セグスタート(Segstart)、タイムスタンプオー
バーフロー及び全ての可能なパケットを同一の周期内に
発生させようとする。 DF39 同一の形態のジャンプ及び他の形態のジャンプ
をシーケンスに伴って、他の形態のジャンプ及びリンク
命令で終了する、条件付き及び無条件のゼロオーバーヘ
ッドループ。
【0389】DF40 limmデータを有する最終命令を備
える非常に厳格なゼロオーバーヘッドループ、ループが
LPよりはSR命令を使用して生成される時、このようなル
ープを使用。最終命令がlimmデータである時、同一の周
期で他のすべての可能なパケットを生成する。 DF41 ゼロオーバーヘッドループ内で、ただLP_END
レジスタのみをセッティングし、LP_STARTレジスタを
セッティングしないために、SR命令を使用する。ゼロオ
ーバーヘッドループを実行させる。 DF42 ロード/格納命令、遅延されたロードによって
引き起こされたストール、及び以前ロード命令からの結
果を待機するその次の命令を使用する。ゼロオーバーヘ
ッドループでロード格納命令を使用する。遅延スロット
内でロード/格納命令を使用する。ゼロオーバーヘッド
ループで第2の最終命令、ロード命令及び最終命令を構
成するが、最終命令は、以前ロードの結果に依存する。 DF43 ゼロオーバーヘッドループ内のブレーキ及び休
止(sleep)命令を使用する。
える非常に厳格なゼロオーバーヘッドループ、ループが
LPよりはSR命令を使用して生成される時、このようなル
ープを使用。最終命令がlimmデータである時、同一の周
期で他のすべての可能なパケットを生成する。 DF41 ゼロオーバーヘッドループ内で、ただLP_END
レジスタのみをセッティングし、LP_STARTレジスタを
セッティングしないために、SR命令を使用する。ゼロオ
ーバーヘッドループを実行させる。 DF42 ロード/格納命令、遅延されたロードによって
引き起こされたストール、及び以前ロード命令からの結
果を待機するその次の命令を使用する。ゼロオーバーヘ
ッドループでロード格納命令を使用する。遅延スロット
内でロード/格納命令を使用する。ゼロオーバーヘッド
ループで第2の最終命令、ロード命令及び最終命令を構
成するが、最終命令は、以前ロードの結果に依存する。 DF43 ゼロオーバーヘッドループ内のブレーキ及び休
止(sleep)命令を使用する。
【0390】付録VI
定義:モニター構成:本テストでどんなモニターが構成
され使用されるかを決定;対と4対は、“&”で表され
る。ソース:ソース比較バスは、アドレス(IA)、デー
タアドレス(DA)又はデータ値(DV)になり得る。 関係:各モニターに対して行われる比較動作を選択す
る。 データ命令:仮にソースがDA又はDVならば、モニター比
較が行われる命令を選択。 トリガー:モニター条件レジスタ内のトリガービットを
セット、RTTは、モニター条件が真である時、トリガー
するはずである。 アクション:モニターがダイナミックイネーブル等にど
のくらい影響を及ぼすかを決定。
され使用されるかを決定;対と4対は、“&”で表され
る。ソース:ソース比較バスは、アドレス(IA)、デー
タアドレス(DA)又はデータ値(DV)になり得る。 関係:各モニターに対して行われる比較動作を選択す
る。 データ命令:仮にソースがDA又はDVならば、モニター比
較が行われる命令を選択。 トリガー:モニター条件レジスタ内のトリガービットを
セット、RTTは、モニター条件が真である時、トリガー
するはずである。 アクション:モニターがダイナミックイネーブル等にど
のくらい影響を及ぼすかを決定。
【0391】付録VII
例示的な生成ユニットテストコードシナリオ
DG1 命令トレース、データトレース、タイミングトレ
ース、アクショントレース、アクションポイント及び外
部信号のためのパケットの生成。このような形態のトレ
ースは、個別的に且つ他の組合で生成されなければなら
ない。 DG2 RTT生成ブロックは、所定の時間に制御、命令実
行、ループトリガー、及び遅延されたロードデータパケ
ットを生成できる。テストコードは、そのようなもの等
を同時に生成しようとする。生成されたデータパケット
がホール(hole)を全く持たないかをまた検査する。 DG3 各クロック周期で、任意のカテゴリーの新しい形
態のパケットと、且つ各周期で一つ以上の形態のパケッ
トを生成しなければならないテストコード。 DG4 全てのトレース形態に対するld及びld.di命令の
組合を使用して、メモリコントローラーの他のチャンネ
ルをアクセスする。 DG5 データトレースセグメントオフセットアドレスに
対する検査、3ビット及び15ビットアドレスの両方が
データパケットに記録される。 DG6 生成ブロックから出力されるパケットが制御、命
令実行、ループトリガー及び遅延されたロードのシーケ
ンスを維持させなければならないため、連続ループで定
められた時間にコードがそのようなもの等を生成するよ
うに実行させ、シーケンスを検査する。また、それと共
にオーバーフロー条件を生成しようとする。
ース、アクショントレース、アクションポイント及び外
部信号のためのパケットの生成。このような形態のトレ
ースは、個別的に且つ他の組合で生成されなければなら
ない。 DG2 RTT生成ブロックは、所定の時間に制御、命令実
行、ループトリガー、及び遅延されたロードデータパケ
ットを生成できる。テストコードは、そのようなもの等
を同時に生成しようとする。生成されたデータパケット
がホール(hole)を全く持たないかをまた検査する。 DG3 各クロック周期で、任意のカテゴリーの新しい形
態のパケットと、且つ各周期で一つ以上の形態のパケッ
トを生成しなければならないテストコード。 DG4 全てのトレース形態に対するld及びld.di命令の
組合を使用して、メモリコントローラーの他のチャンネ
ルをアクセスする。 DG5 データトレースセグメントオフセットアドレスに
対する検査、3ビット及び15ビットアドレスの両方が
データパケットに記録される。 DG6 生成ブロックから出力されるパケットが制御、命
令実行、ループトリガー及び遅延されたロードのシーケ
ンスを維持させなければならないため、連続ループで定
められた時間にコードがそのようなもの等を生成するよ
うに実行させ、シーケンスを検査する。また、それと共
にオーバーフロー条件を生成しようとする。
【0392】DG7 生成された低/高圧縮パケットの両
方に対して、またトレースがそれらから再生成できるか
を検査する。実行時間に低/高圧縮モードの間をスイッ
チングする。 DG8 デルタエンコーディングは、部分的な命令及びデ
ータアドレスを格納させる。互い異なる部分にマッピン
グされた命令/データを有するテストコードを連続的に
実行させると、これらの部分へのジャンプは、命令/デ
ータで全部6/8ニブルの変化を引き起こす。生成され
た全てのパケットは、完全な24/32ビットアドレス
を持たなければならない。これをまたインタラプト生成
と組合して使用する。 DG9 完全な24及び32ビット間接ジャンプ及びロー
ドに対して、IAパケットと共に同一の周期でSEGSTARTを
生成する。同一の周期でSEGSTART及びインタラプトを発
生させると、ISR内の第1の命令は、完全な24/32ビ
ットアドレス変化を有する間接ジャンプ/ロード/格納で
ある。 DG10 セグメント毎に指定された命令制限値をもって
コードを実行させようとする。それぞれの命令制限値上
で、トレースの新しいセグメントが始まらなければなら
ない。その間にまたRTTを非イネーブルとし、これも新
しいセグメントを開始するようにする。それぞれの命令
実行は、新しいセグメントが開始するようにするため
に、命令制限値を1まで減少させることができる。 DG11 指定されたバッファサイズに対して、バッファ
オーバーフローを引き起こすテストコードを連続的に実
行させる。それぞれのオーバーフローに対して新しいセ
グメントの消去が始まらなければならない。バッファサ
イズを最小値まで減少させれば、各オーバーフローが消
去される時、新しいトレースセグメントを生成する。 DG12 コードが実行中の時、トレースの新しいセグメ
ントを生成するために、外部信号を使用する。
方に対して、またトレースがそれらから再生成できるか
を検査する。実行時間に低/高圧縮モードの間をスイッ
チングする。 DG8 デルタエンコーディングは、部分的な命令及びデ
ータアドレスを格納させる。互い異なる部分にマッピン
グされた命令/データを有するテストコードを連続的に
実行させると、これらの部分へのジャンプは、命令/デ
ータで全部6/8ニブルの変化を引き起こす。生成され
た全てのパケットは、完全な24/32ビットアドレス
を持たなければならない。これをまたインタラプト生成
と組合して使用する。 DG9 完全な24及び32ビット間接ジャンプ及びロー
ドに対して、IAパケットと共に同一の周期でSEGSTARTを
生成する。同一の周期でSEGSTART及びインタラプトを発
生させると、ISR内の第1の命令は、完全な24/32ビ
ットアドレス変化を有する間接ジャンプ/ロード/格納で
ある。 DG10 セグメント毎に指定された命令制限値をもって
コードを実行させようとする。それぞれの命令制限値上
で、トレースの新しいセグメントが始まらなければなら
ない。その間にまたRTTを非イネーブルとし、これも新
しいセグメントを開始するようにする。それぞれの命令
実行は、新しいセグメントが開始するようにするため
に、命令制限値を1まで減少させることができる。 DG11 指定されたバッファサイズに対して、バッファ
オーバーフローを引き起こすテストコードを連続的に実
行させる。それぞれのオーバーフローに対して新しいセ
グメントの消去が始まらなければならない。バッファサ
イズを最小値まで減少させれば、各オーバーフローが消
去される時、新しいトレースセグメントを生成する。 DG12 コードが実行中の時、トレースの新しいセグメ
ントを生成するために、外部信号を使用する。
【0393】DG13 コードが実行中の時、新しいトレ
ースセグメントを生成するために、命令レジスタを使用
する。また、RTTをイネーブル及び非イネーブルとする
ことで、セグメントを生成する。 DG14 RTTをトリガーさせ、命令トレースをイネーブ
ルにすることで、新しいセグメントを生成し、また、こ
れを遂行するためにフィルターを使用する。このような
方法を使用する時には、バッファサイズを減少させ、命
令制限値を最小値まで減少させる。新しいセグメントを
開始するために、外部信号を使用しようと試みる。これ
は、非イネーブルになった後、イネーブルにし、その次
にトリガーさせるか、又は同時にイネーブル及びトリガ
ーさせることにより達成することができる。 DG15 遅延スロットで命令が実行される時、前述した
全ての方法を使用して新しいセグメントを生成する。ま
た、遅延スロット命令が実行される時、RTTを非イネー
ブルとする。 DG16 他のトレース形態をダイナミックにイネーブル
/非イネーブルとするように、書き込む。 DG17 データトレースに対しても、上記の全ての新し
いセグメント生成方法を生成する。 DG18 ループの終端で分岐を有し、BCBPCオーバーフ
ローとLPPCカウンタオーバーフローを発生させるコード
を書き込む。 DG19 他の周期でもまた生成される新しいセグメント
とインタラプト、または命令アドレスを同一の周期で生
成するコードを連続的に実行させる。新しいセグメント
が同一の周期で生成されないならば、命令アドレスは、
SEGSTARTに記録された命令アドレスを使用しなければな
らない。データトレースに対しても同一に繰り返す。[D
G9]
ースセグメントを生成するために、命令レジスタを使用
する。また、RTTをイネーブル及び非イネーブルとする
ことで、セグメントを生成する。 DG14 RTTをトリガーさせ、命令トレースをイネーブ
ルにすることで、新しいセグメントを生成し、また、こ
れを遂行するためにフィルターを使用する。このような
方法を使用する時には、バッファサイズを減少させ、命
令制限値を最小値まで減少させる。新しいセグメントを
開始するために、外部信号を使用しようと試みる。これ
は、非イネーブルになった後、イネーブルにし、その次
にトリガーさせるか、又は同時にイネーブル及びトリガ
ーさせることにより達成することができる。 DG15 遅延スロットで命令が実行される時、前述した
全ての方法を使用して新しいセグメントを生成する。ま
た、遅延スロット命令が実行される時、RTTを非イネー
ブルとする。 DG16 他のトレース形態をダイナミックにイネーブル
/非イネーブルとするように、書き込む。 DG17 データトレースに対しても、上記の全ての新し
いセグメント生成方法を生成する。 DG18 ループの終端で分岐を有し、BCBPCオーバーフ
ローとLPPCカウンタオーバーフローを発生させるコード
を書き込む。 DG19 他の周期でもまた生成される新しいセグメント
とインタラプト、または命令アドレスを同一の周期で生
成するコードを連続的に実行させる。新しいセグメント
が同一の周期で生成されないならば、命令アドレスは、
SEGSTARTに記録された命令アドレスを使用しなければな
らない。データトレースに対しても同一に繰り返す。[D
G9]
【0394】DG20 条件付き/無条件、順次分、ジャ
ンプ、ループ、短い/遠いジャンプ、直接/間接ジャンプ
及びこれらの命令の他の最悪-場合の組合を遂行するテ
ストコードを使用して命令トレースを生成する。 DG21 後方向条件付き分岐命令(BCBPC)のためのPF及
びカウンタ値のパケットの両方を、コードを使用して生
成する。 DG22 BCBPCのためのカウンタ方法と、その間のルー
プを使用し、IA、PF、DATASRSPEC、LPTRIG、他の全ての
パケット形態を生成し、BCBPCループにさらにリターン
させる。 DG23 BCBPC命令で、カウンタが決して更新されない
条件を検査する。すなわち前記条件は、第1の瞬間にフ
ェイルすることになる。DG22で具現。 DG24 他の制御パケット生成と結合されたこのような
BCBPCカウンタに対する最大オーバーフローと、タイマ
ーなどのような他のカウンタオーバーフローを発生させ
る。 DG25 ネストされたループの多数レベルを生成し、こ
れら内の分岐及びゼロオーバーヘッドループを使用。 DG26 各命令実行に対して、バッファサイズまたは命
令制限値/セグメントを減少させることによって、新し
いセグメントを生成し、BCBIを使用してカウンタオーバ
ーフローと、第1の実行上でのフェイルを生成し、且つ
これらの間にIA、PF、DATA SRSPEC、LPTRIGパケットを
生成する。 DG27 BCBIループ及びカウンタ/PF方法で、インタラ
プトを発生させる。 DG28 BCBIループ内で、一つのセグメントと、同一の
周期内でBCBPC、LPPCパケット中のひとつを生成する。 DG29 ゼロオーバーヘッドループに対する全てのBCBI
カバレッジ場合を繰り返す。 DG30 SEGSTARTSと共に、全てのオーバーフロー、SIC
OV、BCBPCOV、LPPCOV、TSOVを生成する。
ンプ、ループ、短い/遠いジャンプ、直接/間接ジャンプ
及びこれらの命令の他の最悪-場合の組合を遂行するテ
ストコードを使用して命令トレースを生成する。 DG21 後方向条件付き分岐命令(BCBPC)のためのPF及
びカウンタ値のパケットの両方を、コードを使用して生
成する。 DG22 BCBPCのためのカウンタ方法と、その間のルー
プを使用し、IA、PF、DATASRSPEC、LPTRIG、他の全ての
パケット形態を生成し、BCBPCループにさらにリターン
させる。 DG23 BCBPC命令で、カウンタが決して更新されない
条件を検査する。すなわち前記条件は、第1の瞬間にフ
ェイルすることになる。DG22で具現。 DG24 他の制御パケット生成と結合されたこのような
BCBPCカウンタに対する最大オーバーフローと、タイマ
ーなどのような他のカウンタオーバーフローを発生させ
る。 DG25 ネストされたループの多数レベルを生成し、こ
れら内の分岐及びゼロオーバーヘッドループを使用。 DG26 各命令実行に対して、バッファサイズまたは命
令制限値/セグメントを減少させることによって、新し
いセグメントを生成し、BCBIを使用してカウンタオーバ
ーフローと、第1の実行上でのフェイルを生成し、且つ
これらの間にIA、PF、DATA SRSPEC、LPTRIGパケットを
生成する。 DG27 BCBIループ及びカウンタ/PF方法で、インタラ
プトを発生させる。 DG28 BCBIループ内で、一つのセグメントと、同一の
周期内でBCBPC、LPPCパケット中のひとつを生成する。 DG29 ゼロオーバーヘッドループに対する全てのBCBI
カバレッジ場合を繰り返す。 DG30 SEGSTARTSと共に、全てのオーバーフロー、SIC
OV、BCBPCOV、LPPCOV、TSOVを生成する。
【0395】DG31 BCBPC/LPPCカウント値を生成し、
かつこれら間のDLDDを生成するが、カウンタは、DLDDパ
ケットが入力される時、リセットされなければならな
い。LPPCと共にBCBPCOVパケットを生成し、その逆にも
生成する。また、BCBPC及びLPCCカウンタ値を両方とも
消去させようとする。 DG32 アドレス空間(メモリ及び補助レジスタ)にまた
依存し、データアドレス及びデータ値に対するトレース
を発生させる。(メモリ/補助及び特定レジスタからまた
はここにLD/ST)。(DATA/DLDD/SRSPECパケット)。静的な
/ダイナミックなイネーブルを使用するか使用せず、USE
R/PKT_CTLレジスタに書き込むことによってSRSPECを生
成する。命令イネーブルを使用するか使用せず、LPSTAR
T/LPENDに書き込む。 DG33 データトレースと一緒データフィルターを使用
し、データパケット内のセグメント命令で、生成された
全てのパケット(DATA/DLDD/SRSPECパケット)に対してト
レースが生成されることができるかを検査する。 DG34 データパケットに対するセグメント命令オフセ
ットがイネーブルされる時、同一の周期でSEGSTART及び
DATAまたはSRSPECまたはINTを生成しようとする。 DG35 タイムスタンプを有するか有しないイベントト
レースを生成するために、外部信号及びアクションポイ
ントを使用する。命令とデータトレースと共にイベント
トレースを結合。 DG36 命令及び遅延ロードデータのためのタイムスタ
ンプ、イベント(ap、ext信号、インタラプト及びSEGSTA
RTS)を生成するために、命令及びイベントタイミング
トレースを使用する。より頻繁なSEGSTARTSがこのよう
なトレースと共に生成されるように、バッファサイズを
減少させる(またはSR命令を使用)。タイムスタンプオー
バーフローを発生させるために、これを連続的に実行さ
せる。同一の周期でオーバーフロー及びイベントを生成
しようとする。 DG37 タイミングトレースがイネーブルされた状態
で、いかなるストールパケットも生成されないテストコ
ードを実行する。 DG38 ステージR1がタイムスタンプオーバーフロー
を記録し、同時にバッファオーバーフローが発生してタ
イムスタンプオーバーフローが記録されない状況を生成
する。 DG39 イベントタイミングトレースと共に命令-タイ
ミングトレースをイネーブルにすることで、ストールパ
ケットを生成する。ストールオーバーフローを生成しよ
うとし、同時にデセイブル/イネーブル命令トレースを
ダイナミックに生成しようとする。ストールオーバーフ
ロー/ストールパケットと共にINT及び多数のSEGSTARTS
を生成する。また、ストールパケットが生成される時、
外部イベントをトリガーしようとする。ストール/オー
バーフローパケットが生成される時、BCBPCOV、LPPCO
V、TSOVを生成する。また、ストール生成と共に他の全
ての形態のパケットを生成する。
かつこれら間のDLDDを生成するが、カウンタは、DLDDパ
ケットが入力される時、リセットされなければならな
い。LPPCと共にBCBPCOVパケットを生成し、その逆にも
生成する。また、BCBPC及びLPCCカウンタ値を両方とも
消去させようとする。 DG32 アドレス空間(メモリ及び補助レジスタ)にまた
依存し、データアドレス及びデータ値に対するトレース
を発生させる。(メモリ/補助及び特定レジスタからまた
はここにLD/ST)。(DATA/DLDD/SRSPECパケット)。静的な
/ダイナミックなイネーブルを使用するか使用せず、USE
R/PKT_CTLレジスタに書き込むことによってSRSPECを生
成する。命令イネーブルを使用するか使用せず、LPSTAR
T/LPENDに書き込む。 DG33 データトレースと一緒データフィルターを使用
し、データパケット内のセグメント命令で、生成された
全てのパケット(DATA/DLDD/SRSPECパケット)に対してト
レースが生成されることができるかを検査する。 DG34 データパケットに対するセグメント命令オフセ
ットがイネーブルされる時、同一の周期でSEGSTART及び
DATAまたはSRSPECまたはINTを生成しようとする。 DG35 タイムスタンプを有するか有しないイベントト
レースを生成するために、外部信号及びアクションポイ
ントを使用する。命令とデータトレースと共にイベント
トレースを結合。 DG36 命令及び遅延ロードデータのためのタイムスタ
ンプ、イベント(ap、ext信号、インタラプト及びSEGSTA
RTS)を生成するために、命令及びイベントタイミング
トレースを使用する。より頻繁なSEGSTARTSがこのよう
なトレースと共に生成されるように、バッファサイズを
減少させる(またはSR命令を使用)。タイムスタンプオー
バーフローを発生させるために、これを連続的に実行さ
せる。同一の周期でオーバーフロー及びイベントを生成
しようとする。 DG37 タイミングトレースがイネーブルされた状態
で、いかなるストールパケットも生成されないテストコ
ードを実行する。 DG38 ステージR1がタイムスタンプオーバーフロー
を記録し、同時にバッファオーバーフローが発生してタ
イムスタンプオーバーフローが記録されない状況を生成
する。 DG39 イベントタイミングトレースと共に命令-タイ
ミングトレースをイネーブルにすることで、ストールパ
ケットを生成する。ストールオーバーフローを生成しよ
うとし、同時にデセイブル/イネーブル命令トレースを
ダイナミックに生成しようとする。ストールオーバーフ
ロー/ストールパケットと共にINT及び多数のSEGSTARTS
を生成する。また、ストールパケットが生成される時、
外部イベントをトリガーしようとする。ストール/オー
バーフローパケットが生成される時、BCBPCOV、LPPCO
V、TSOVを生成する。また、ストール生成と共に他の全
ての形態のパケットを生成する。
【0396】DG40 SICOVパケットと共に、同一周期
及びその以前周期でPC値を提供する他の全てのパケット
を生成する。また、PC値を生成しないパケットを生成す
る。 DG41 次の理由によってストール及びオーバーフロー
を生成する。ベチ遅延(例えば、I-キャッシュ損失)、ロ
ード-使用、ロード-リターン(ただ3ポートレジスタフ
ァイル/4ポートレジスタファイルと共に)、ロード/格
納待ち行列 フル、マルチ-周期命令、依存度(例えば、
非−短縮レジスタ、条件付きジャンプ/分岐を伴うフラ
ッグセッティング等)、インタラプト、長い-近接デー
タ、中止された遅延-スロット命令、拡張命令、ブレー
キ命令またはアクションポイントトリガー、単一-段階
や命令-段階モードにあるプロセッサ。他の全ての制御
パケットによりストールオーバーフローをまた生成す
る。 DG42 単一/多数のタイムスタンプオーバーフローが
生成された後にだけ、同一周期でのバッファオーバーフ
ローを通じてタイムスタンプオーバーフローを生成した
り、バッファオーバーフローを消去させる。これは、タ
イムスタンプオーバーラン(overrun)を生成しなければ
ならない。また、タイムスタンプオーバーフローと共に
全ての制御パケットを生成する。 DG43 同一周期でSEGSTART、命令トレースダイナミッ
クイネーブル、外部信号イベント、アクションポイント
及びタイムスタンプオーバーフローを生成する。パケッ
トの順序は、生成ブロックにより維持される。連続的な
ループで実行。 DG44 RTTをイネーブルにし、一つの命令をも実行さ
れずに、RTTを使用不可にする。いかなるセグメント開
始も生成されてはならない。 DG45 RTTイネーブルが1である状態で、トリガーを
1とする。SEGSTARTは、REASON_TRIGGEREDのような理
由を持たなければならない。トリガーが1であり、イネ
ーブルが1になった時には同様である。 DG46 トリガーが'0'であり、RTTイネーブルが'0'
から'1'に変わった時、REASON_ENABLEDが生成されな
ければならない。 DG47 REASON_BUF_OV_CLR_AND_TRIGGERED、REAS
ON_BUF_OV_CLRをSEGSTARTに対する理由として生成す
る。 DG48 同一の周期で8個の可能なSEGSTART理由の全部
又はその一部を生成し、優先順位が維持されることを観
測する。
及びその以前周期でPC値を提供する他の全てのパケット
を生成する。また、PC値を生成しないパケットを生成す
る。 DG41 次の理由によってストール及びオーバーフロー
を生成する。ベチ遅延(例えば、I-キャッシュ損失)、ロ
ード-使用、ロード-リターン(ただ3ポートレジスタフ
ァイル/4ポートレジスタファイルと共に)、ロード/格
納待ち行列 フル、マルチ-周期命令、依存度(例えば、
非−短縮レジスタ、条件付きジャンプ/分岐を伴うフラ
ッグセッティング等)、インタラプト、長い-近接デー
タ、中止された遅延-スロット命令、拡張命令、ブレー
キ命令またはアクションポイントトリガー、単一-段階
や命令-段階モードにあるプロセッサ。他の全ての制御
パケットによりストールオーバーフローをまた生成す
る。 DG42 単一/多数のタイムスタンプオーバーフローが
生成された後にだけ、同一周期でのバッファオーバーフ
ローを通じてタイムスタンプオーバーフローを生成した
り、バッファオーバーフローを消去させる。これは、タ
イムスタンプオーバーラン(overrun)を生成しなければ
ならない。また、タイムスタンプオーバーフローと共に
全ての制御パケットを生成する。 DG43 同一周期でSEGSTART、命令トレースダイナミッ
クイネーブル、外部信号イベント、アクションポイント
及びタイムスタンプオーバーフローを生成する。パケッ
トの順序は、生成ブロックにより維持される。連続的な
ループで実行。 DG44 RTTをイネーブルにし、一つの命令をも実行さ
れずに、RTTを使用不可にする。いかなるセグメント開
始も生成されてはならない。 DG45 RTTイネーブルが1である状態で、トリガーを
1とする。SEGSTARTは、REASON_TRIGGEREDのような理
由を持たなければならない。トリガーが1であり、イネ
ーブルが1になった時には同様である。 DG46 トリガーが'0'であり、RTTイネーブルが'0'
から'1'に変わった時、REASON_ENABLEDが生成されな
ければならない。 DG47 REASON_BUF_OV_CLR_AND_TRIGGERED、REAS
ON_BUF_OV_CLRをSEGSTARTに対する理由として生成す
る。 DG48 同一の周期で8個の可能なSEGSTART理由の全部
又はその一部を生成し、優先順位が維持されることを観
測する。
【0397】DG49 他のパケットを連続的に生成する
ためにテストコードを使用し、パケットが相変らず生成
ブロック内で係留中の時、RTTを非イネーブルにする。
生成ブロックに係留中の全てのパケットは、フラッシュ
されなければならないし、その後、SEGSTARTパケットが
生成されなければならない。いかなる場合にも、SEGSTA
RTは、損失されてはならない。また、DATAトレース及び
タイミングトレースに対しても同一に繰り返す。 DG50 SEGSTARTパケットがRTTを非イネーブルにする
ことは別の全ての可能な理由で生成されるべきテストコ
ードを連続的なループで実行する。このようなテストコ
ードは、次のような場合を有すること: DG50-1 全てのSEGSTART理由後、いかなる遅延スロ
ット命令も無い。 DG50-2 全てのSEGSTART理由後の遅延スロット命
令。 DG50-3 SEGSTART後の多数の遅延スロット命令。 DG50-4 SEGSTART理由後のインタラプト。 DG50-5 SEGSTART理由後の遅延スロットで可能なイ
ンタラプト。 DG50-6 遅延スロットにない命令やインタラプトを
伴う遅延スロット内の多数の命令。 DG50-7 SEGSTART後の遅延スロット内のlimm。 DG51 全ての外部信号パケットが生成されないよう
に、多数の外部信号トリガーを連続的に生成する。 DG52 同一周期での他の制御パケット生成を使用する
か使用せずに多数のアクションポイントパケットを生成
する。また、APEパケットが連続的に生成されることよ
り早くアクションポイントイベントを生成する。 DG53 同一周期での他の制御パケットを使用するか使
用せずに多数のタイムスタンプオーバーフローを生成す
る。
ためにテストコードを使用し、パケットが相変らず生成
ブロック内で係留中の時、RTTを非イネーブルにする。
生成ブロックに係留中の全てのパケットは、フラッシュ
されなければならないし、その後、SEGSTARTパケットが
生成されなければならない。いかなる場合にも、SEGSTA
RTは、損失されてはならない。また、DATAトレース及び
タイミングトレースに対しても同一に繰り返す。 DG50 SEGSTARTパケットがRTTを非イネーブルにする
ことは別の全ての可能な理由で生成されるべきテストコ
ードを連続的なループで実行する。このようなテストコ
ードは、次のような場合を有すること: DG50-1 全てのSEGSTART理由後、いかなる遅延スロ
ット命令も無い。 DG50-2 全てのSEGSTART理由後の遅延スロット命
令。 DG50-3 SEGSTART後の多数の遅延スロット命令。 DG50-4 SEGSTART理由後のインタラプト。 DG50-5 SEGSTART理由後の遅延スロットで可能なイ
ンタラプト。 DG50-6 遅延スロットにない命令やインタラプトを
伴う遅延スロット内の多数の命令。 DG50-7 SEGSTART後の遅延スロット内のlimm。 DG51 全ての外部信号パケットが生成されないよう
に、多数の外部信号トリガーを連続的に生成する。 DG52 同一周期での他の制御パケット生成を使用する
か使用せずに多数のアクションポイントパケットを生成
する。また、APEパケットが連続的に生成されることよ
り早くアクションポイントイベントを生成する。 DG53 同一周期での他の制御パケットを使用するか使
用せずに多数のタイムスタンプオーバーフローを生成す
る。
【0398】DG54 第1のセグメントでLPSTART及びL
PEND信号が記録されるように、ゼロオーバーヘッドルー
プコードを連続的に実行し、同一のセグメント内で数回
ループを形成するようにそのコードを実行する。他の新
しいセグメントで続いてループを連続させるが、これが
LPTRIGパケットを生成しなければならない。また、ルー
プトリガー及びSEGSTARTが同一周期で発生するさらに他
のゼロオーバーヘッドループメカニズムを実行する。LP
ENDが第1のセグメントに記録され、LPSTARTが次にセグ
メントに記録されたり、またその逆に記録される時、同
一に繰り返す。 DG55 状態レジスタ機能テスト。 DG56 RTT_PKT_CTLレジスタ機能テスト。 DG57 FTモードでRTTをテスト。 DG58 全ての形態のパケットに対して他のパケットサ
イズを生成及びカバーするテストコードを書き込む。 DG59 ステージr3、r2及びr1にパケットが存在す
る時、バッファオーバーフローを引き起こし、生成ブロ
ックで検出された一部のパケットを有するコードを書き
込む。このような全てのものは、廃棄されなければなら
ない。また、バッファオーバーフローが生成された後、
パケット生成を継続し、これらのパケットも廃棄されな
ければならない。 DG60 同一の周期でバッファオーバーフロー消去及び
他の全てのパケットを生成する。そして、同一の周期で
多数のパケットをまた生成する。また、パケットのカテ
ゴリーによってオーバーフロー瞬間に他のパケットを生
成する。 DG61 またパケットパイプラインが空いている時、オ
ーバーフローが消去されるように、バッファ臨界値を変
え、同一の周期で全体及び多数のパケットを生成する。
PEND信号が記録されるように、ゼロオーバーヘッドルー
プコードを連続的に実行し、同一のセグメント内で数回
ループを形成するようにそのコードを実行する。他の新
しいセグメントで続いてループを連続させるが、これが
LPTRIGパケットを生成しなければならない。また、ルー
プトリガー及びSEGSTARTが同一周期で発生するさらに他
のゼロオーバーヘッドループメカニズムを実行する。LP
ENDが第1のセグメントに記録され、LPSTARTが次にセグ
メントに記録されたり、またその逆に記録される時、同
一に繰り返す。 DG55 状態レジスタ機能テスト。 DG56 RTT_PKT_CTLレジスタ機能テスト。 DG57 FTモードでRTTをテスト。 DG58 全ての形態のパケットに対して他のパケットサ
イズを生成及びカバーするテストコードを書き込む。 DG59 ステージr3、r2及びr1にパケットが存在す
る時、バッファオーバーフローを引き起こし、生成ブロ
ックで検出された一部のパケットを有するコードを書き
込む。このような全てのものは、廃棄されなければなら
ない。また、バッファオーバーフローが生成された後、
パケット生成を継続し、これらのパケットも廃棄されな
ければならない。 DG60 同一の周期でバッファオーバーフロー消去及び
他の全てのパケットを生成する。そして、同一の周期で
多数のパケットをまた生成する。また、パケットのカテ
ゴリーによってオーバーフロー瞬間に他のパケットを生
成する。 DG61 またパケットパイプラインが空いている時、オ
ーバーフローが消去されるように、バッファ臨界値を変
え、同一の周期で全体及び多数のパケットを生成する。
【0399】付録VIII
例示的なバッファ/パケットポートテストコードシナリ
オ DB1 最大/最小値から勧告される値にバッファのサイ
ズを変え、他のユーザーが構成可能なバッファオーバー
フローシナリオ(オーバーフロー状態で、バッファ放出
のためにキャプチャーを直ちに消去したり非イネーブル
とする)と共に生成ブロックからの最大出力のための処
理量を獲得する。パケットを生成するために低/高圧縮
を両方とも使用する。バッファオーバーフローインタラ
プトを処理すべきテストコードを実行し、また頻繁なイ
ンタラプト生成をテストし、それと同一に処理する。 DB2 レジスタアレイの幅/深さを変更させるために、
パケットパイプラインを構成し、開発されたテストコー
ドを実行する。 DB3 頻繁なオーバーフローが発生するように、バッフ
ァサイズを減少させる。 DB4 パケットを7またはこれより小さいニブル幅で、
毎周期にひとつ及び毎周期に4個を連続的に生成する。 DB5 パケットを8ニブル幅で、毎周期にひとつ及び毎
周期に4個を連続的に生成する。 DB6 パケットを9ニブル以上の幅で、毎周期にひとつ
及び毎周期に4個を連続的に生成する。 DB7 全てのカテゴリーの最大サイズのパケットを各周
期にひとつ、そして同一の周期にこれらのうち4個を連
続的に生成する。 DB8 パイプラインに進入する時、全てのパケット部分
を占有しないように、パケットを生成する。パイプライ
ンは、その部分をありのままにパスさせなければならな
いが、ポートは、その部分から不必要なビットを除去し
なければならない。 DB9 続いて何らのデータをも印加しない。すなわち全
部ゼロを印加する。
オ DB1 最大/最小値から勧告される値にバッファのサイ
ズを変え、他のユーザーが構成可能なバッファオーバー
フローシナリオ(オーバーフロー状態で、バッファ放出
のためにキャプチャーを直ちに消去したり非イネーブル
とする)と共に生成ブロックからの最大出力のための処
理量を獲得する。パケットを生成するために低/高圧縮
を両方とも使用する。バッファオーバーフローインタラ
プトを処理すべきテストコードを実行し、また頻繁なイ
ンタラプト生成をテストし、それと同一に処理する。 DB2 レジスタアレイの幅/深さを変更させるために、
パケットパイプラインを構成し、開発されたテストコー
ドを実行する。 DB3 頻繁なオーバーフローが発生するように、バッフ
ァサイズを減少させる。 DB4 パケットを7またはこれより小さいニブル幅で、
毎周期にひとつ及び毎周期に4個を連続的に生成する。 DB5 パケットを8ニブル幅で、毎周期にひとつ及び毎
周期に4個を連続的に生成する。 DB6 パケットを9ニブル以上の幅で、毎周期にひとつ
及び毎周期に4個を連続的に生成する。 DB7 全てのカテゴリーの最大サイズのパケットを各周
期にひとつ、そして同一の周期にこれらのうち4個を連
続的に生成する。 DB8 パイプラインに進入する時、全てのパケット部分
を占有しないように、パケットを生成する。パイプライ
ンは、その部分をありのままにパスさせなければならな
いが、ポートは、その部分から不必要なビットを除去し
なければならない。 DB9 続いて何らのデータをも印加しない。すなわち全
部ゼロを印加する。
【0400】DB10 7個の周期に対して1周期毎にSE
GSTARTSを生成する。 DB11 全てのパケットがカバーされる時まで、2、3
の他のカテゴリーパケットを有するSEGSTARTが同一の方
式で他の制御カテゴリーパケットをまた結合する。 DB12 3個の連続的なゼロニブルと3個以上の連続的
なゼロニブルを有するパケットを生成し、パケットを詰
める大部分の可能なニブルをまた生成しようとする。 DB13 出力されるパケットシーケンスが維持されなけ
ればならないし、同一の周期での他のパケットカテゴリ
ーを変更する。 DB14 FIFOをフルとした後、データを損失することな
く放出するか、正確な臨界値でデータを受け入れるかを
検査する。 DB15 間に任意の他の制御カテゴリーパケット無し
に、32個以上連続的に生成されたIE及びDLDDパケット
によるパケットパイプラインのカウンタがオーバーフロ
ーする場合を書き込む。
GSTARTSを生成する。 DB11 全てのパケットがカバーされる時まで、2、3
の他のカテゴリーパケットを有するSEGSTARTが同一の方
式で他の制御カテゴリーパケットをまた結合する。 DB12 3個の連続的なゼロニブルと3個以上の連続的
なゼロニブルを有するパケットを生成し、パケットを詰
める大部分の可能なニブルをまた生成しようとする。 DB13 出力されるパケットシーケンスが維持されなけ
ればならないし、同一の周期での他のパケットカテゴリ
ーを変更する。 DB14 FIFOをフルとした後、データを損失することな
く放出するか、正確な臨界値でデータを受け入れるかを
検査する。 DB15 間に任意の他の制御カテゴリーパケット無し
に、32個以上連続的に生成されたIE及びDLDDパケット
によるパケットパイプラインのカウンタがオーバーフロ
ーする場合を書き込む。
【図1】本発明によってプロセッサコアとRTTユニット
を具備する集積回路デバイスの一つの例示的な構造を示
す機能ブロック図である。
を具備する集積回路デバイスの一つの例示的な構造を示
す機能ブロック図である。
【図2】本発明によってデータトレース情報を格納する
ためのもので、内部ホスト格納装置が提供された装置の
例示的な一実施形態を示す機能ブロック図である。
ためのもので、内部ホスト格納装置が提供された装置の
例示的な一実施形態を示す機能ブロック図である。
【図3】本発明によってデータトレース情報を格納する
ためのもので、外部格納装置が仲介デバイス内に提供さ
れた装置の第2の例示的な実施形態を示す機能ブロック
図である。
ためのもので、外部格納装置が仲介デバイス内に提供さ
れた装置の第2の例示的な実施形態を示す機能ブロック
図である。
【図4】本発明によってデルタエンコードを使用するト
レース圧縮の一般的な方法論を示す論理フローチャート
である。
レース圧縮の一般的な方法論を示す論理フローチャート
である。
【図5】aは、本発明に係るパケット形態のエンコード
(第1のニブル)の一実施形態をグラフィックで表現し
た図であり、bは、本発明に係るパケット形態のエンコ
ード(第2のニブル)の一実施形態をグラフィックで表現
した図である。
(第1のニブル)の一実施形態をグラフィックで表現し
た図であり、bは、本発明に係るパケット形態のエンコ
ード(第2のニブル)の一実施形態をグラフィックで表現
した図である。
【図6】aは、条件付き/無条件の分岐、ジャンプ及び
他の動作に関する本発明の最大圧縮同期命令トレースの
動作を示す図であり、bは、条件付き/無条件の分岐、ジ
ャンプ及び他の動作に関する本発明の外部モニター同期
命令トレースの動作を示す図である。
他の動作に関する本発明の最大圧縮同期命令トレースの
動作を示す図であり、bは、条件付き/無条件の分岐、ジ
ャンプ及び他の動作に関する本発明の外部モニター同期
命令トレースの動作を示す図である。
【図7】本発明によってプロセッサコアとRTTユニット
を具備する集積回路デバイスの第2の例示的な構造を示
す機能ブロック図である。
を具備する集積回路デバイスの第2の例示的な構造を示
す機能ブロック図である。
【図8】aは、本発明のRTT構造のパケットパイプライ
ンの第1の実施形態を示す機能ブロック図であり、b
は、本発明のRTT構造のパケットパイプラインの第2の
実施形態を示す機能ブロック図である。
ンの第1の実施形態を示す機能ブロック図であり、b
は、本発明のRTT構造のパケットパイプラインの第2の
実施形態を示す機能ブロック図である。
【図9】本発明に係る一つの例示的なパケットパイプラ
インFIFO装置を示す機能ブロック図である。
インFIFO装置を示す機能ブロック図である。
【図10】本発明に係る一つの例示的なパケット部の配
列をグラフィックで表現した図である。
列をグラフィックで表現した図である。
【図11a】本発明に係る例示的なソフトウェアドライ
バーインターフェースと構成を示す機能ブロック図であ
る。
バーインターフェースと構成を示す機能ブロック図であ
る。
【図11b】本発明のRTTドライバーに用いられるトレ
ースセットを構成するためのダイアローグGUIの例示的
な一実施形態を示す図である。
ースセットを構成するためのダイアローグGUIの例示的
な一実施形態を示す図である。
【図11c】フィルタエディターダイアローグGUIの例
示的な一実施形態を示す図である。
示的な一実施形態を示す図である。
【図11d】本発明のソフトウェアドライバーに用いら
れるコード及び可変ブラウジング(browsing)の例を示
す図である。
れるコード及び可変ブラウジング(browsing)の例を示
す図である。
【図11e】本発明のソフトウェアドライバーに用いら
れるコード及び可変ブラウジング(browsing)の例を示
す図である。
れるコード及び可変ブラウジング(browsing)の例を示
す図である。
【図11f】トレース結果を分析するための一つの例示
的なGUIを示す図である。
的なGUIを示す図である。
【図12】本発明に係る一つの例示的なソフトウェアド
ライバー構造を示す機能ブロック図である。
ライバー構造を示す機能ブロック図である。
【図13】本発明に係る一つの例示的なモニターバス構
造を示す機能ブロック図である。
造を示す機能ブロック図である。
【図14】本発明に係る一つの例示的なRTTモニターユ
ニット構造を示す機能ブロック図である。
ニット構造を示す機能ブロック図である。
【図15】本発明に係る例示的なモニター結合(たとえ
ば、1対、4対)を示す機能ブロック図である。
ば、1対、4対)を示す機能ブロック図である。
【図16】結合されたモニターとダイナミックイネーブ
ルの相互作用を示す機能ブロック図である。
ルの相互作用を示す機能ブロック図である。
【図17】本発明に係る一つの例示的なパケットポート
構造を示す機能ブロック図である。
構造を示す機能ブロック図である。
【図18】本発明に係る一つの例示的な“ニブルスタッ
フィング”方法をグラフィックで表現した図面である。
フィング”方法をグラフィックで表現した図面である。
【図19】パケットポートクロックの例示的な一実施形
態の動作を示すタイミング図である。
態の動作を示すタイミング図である。
【図20】本発明に係る一つの例示的なテストベンチ装
置の機能ブロック図である。
置の機能ブロック図である。
【図21】本発明のRTTユニットのテストと関連して用
いられる一つの例示的なディレクトリ構造をグラフィッ
クで表現した図である。
いられる一つの例示的なディレクトリ構造をグラフィッ
クで表現した図である。
【図22】多重プロセッサコアとRTTユニットを具備し
た集積回路デバイスの第2の例示的な構造を示す機能ブ
ロック図である。
た集積回路デバイスの第2の例示的な構造を示す機能ブ
ロック図である。
【図23】ダイの一般的な配置を示す、図1の集積回路
デバイスの平面図である。
デバイスの平面図である。
【図24a】本発明に係るプロセッサからトレースデー
タを獲得する一般的な方法論を示す論理フローチャート
である。
タを獲得する一般的な方法論を示す論理フローチャート
である。
【図24b】内部格納モードを使用する図24aの方法
を示す論理フローチャートである。
を示す論理フローチャートである。
【図24c】外部格納モードを使用する図24aの方法
を示す論理フローチャートである。
を示す論理フローチャートである。
100 装置
101 集積回路ディバイス
102 RTTユニット
105 プロセッサコアユニット
107 デバッグポート/インターフェース
109 パケットポート
112 共有バッファ
131 プロセッサコアユニットコア
140 トレースキャプチャユニット
142 モニターユニット
144 生成ユニット
146 制御ユニット
148 アクションポイントトリガー生成器
152 トレース信号
160 外部入力インターフェース
702 RTTユニット
709 パケットポート
712 パケットバッファ
742 モニターユニット
744 生成ユニット
─────────────────────────────────────────────────────
フロントページの続き
(51)Int.Cl.7 識別記号 FI テーマコート゛(参考)
G06F 15/177 678 G06F 15/177 678H
15/78 510 15/78 510K
Fターム(参考) 5B042 GA11 GA33 GC08 HH30 MA15
MA19 MC40
5B045 JJ02 JJ08 JJ49
5B048 AA12 BB02 DD08 FF03
5B062 CC01 JJ08
5B083 CC10
Claims (60)
- 【請求項1】 複数の命令を実行するように適用され
る、少なくとも一つのデジタルプロセッサコアと、 前記命令のうち、少なくとも一部の実行に関連して前記
少なくとも一つのプロセッサから複数のデータを受信
し、それに関連する複数のデータパケットを生成するよ
うに適用される、少なくとも一つのトレースユニット
と、 前記少なくとも一つのトレースユニットとのデータ通信
を行い、前記複数のパケットのうち少なくとも一部を格
納するように適用された、少なくとも一つの格納ディバ
イスと、 前記少なくとも一つの格納ディバイスとのデータ通信を
行い、前記データパケットのうち少なくとも一部を一つ
の処理ディバイスに伝送するように構成される少なくと
も一つのポートとを含む装置。 - 【請求項2】 前記プロセッサコアは、少なくとも一つ
の拡張命令を有するパイプライン型縮小命令セット・コ
ンピュータ(RISC)を含み、前記命令のうち少なくとも一
部は、前記少なくとも一つの拡張命令を含む請求項1に
記載の装置。 - 【請求項3】 前記コアプロセッサコア、トレースユニ
ット、及び格納ディバイスは、単一集積回路ダイを含む
請求項1に記載の装置。 - 【請求項4】 前記複数のデータパケットは、データ圧
縮技術を使用して少なくとも一部が圧縮される請求項1
に記載の装置。 - 【請求項5】 前記圧縮技術は、前記データのデルタ・
エンコーディング(delta-encoding)を含む請求項4に記
載の装置。 - 【請求項6】 前記圧縮技術は、前記データの可変サイ
ズエンコーディングを含む請求項4に記載の装置。 - 【請求項7】 ランダムアクセスメモリー(RAM)と、 前記RAMと前記少なくとも一つのプロセッサコアとに作
動的に接続されるメモリーコントローラとをさらに含
み、 前記RAMは前記複数の命令の中から少なくとも一部を格
納する請求項1に記載の装置。 - 【請求項8】 前記少なくとも一つのトレースユニット
は、 前記少なくとも一つのプロセッサコアとのデータ通信を
行い、プロセッサコアのトレースデータを観測してキャ
プチャーするように適用された、少なくとも一つのキャ
プチャーユニットと、 前記少なくとも一つのキャプチャーユニットから前記ト
レースデータを受信し、これをフィルターリングするよ
うに適用された、少なくとも一つのモニターユニット
と、 前記少なくとも一つのモニターユニットからデータを受
信し、前記少なくとも一つのトレースユニットからの伝
送のための前記データパケットを生成するように適用さ
れた、少なくとも一つの生成ユニットとを含む請求項1
に記載の装置。 - 【請求項9】 複数のデジタルプロセッサコアとして、
これらのうち少なくとも二つのコアはこれらの間に関連
したトレースユニットを有する複数のデジタルプロセッ
サと、 第1ポートと、 前記少なくとも二つのトレースユニットと前記第1ポー
トとのデータ通信を行う仲裁ユニットを含む第1インタ
ーフェースユニットとして、前記仲裁ユニットは前記ト
レースユニットの間で前記第1ポートに対するアクセス
を仲裁するように適用された、第1インターフェースユ
ニットを含むデータ処理装置。 - 【請求項10】 前記第1インターフェースユニットは
共有バッファをさらに含み、前記共有バッファは前記第
1ポートと前記仲裁ユニットとのデータ通信を行い、前
記共有バッファは前記トレースユニットにより生成され
た複数のデータパケットを格納するように適用された、
請求項9に記載のデータ処理装置。 - 【請求項11】 前記プロセッサコアとのデータ通信を
行う第2インターフェースユニットと、 前記第2インターフェースユニットとのデータ通信を行
う第2ポートとをさらに含み、 前記第2ポートとインターフェースユニットは、前記プ
ロセッサコアと外部ホストコンピューターとの間でデー
タを伝達するように動作する請求項9に記載のデータ処
理装置。 - 【請求項12】 前記プロセッサコアとのデータ通信を
行う第2インターフェースユニットと、 前記第2インターフェースユニットとのデータ通信を行
う第2ポートをさらに含み、 前記第2ポートとインターフェースユニットは、前記プ
ロセッサコアと外部ホストコンピューターとの間でデー
タの伝達を行うように動作する請求項10に記載のデー
タ処理装置。 - 【請求項13】 前記共有バッファは、前記第1ポート
を介して外部キャプチャーディバイスにリアルタイムに
パケットを放出する請求項10に記載のデータ処理装
置。 - 【請求項14】 前記それぞれのトレースユニットは、 関連プロセッサコアとのデータ通信を行い、プロセッサ
コアのトレースデータを観測してキャプチャーするよう
に適用された、少なくとも一つのキャプチャーユニット
と、 前記少なくとも一つのキャプチャーユニットから前記ト
レースデータを受信し、これをフィルターリングするよ
うに適用された、少なくとも一つのモニターユニット
と、 前記少なくとも一つのモニターユニットからデータを受
信し、前記トレースユニットからの伝送のために複数の
パケットを生成するように適用された、少なくとも一つ
の生成ユニットをさらに含む請求項9に記載のデータ処
理装置。 - 【請求項15】 前記それぞれのトレースユニットは、 関連プロセッサコアとのデータ通信を行い、プロセッサ
コアのトレースデータを観測してキャプチャーするよう
に適用された、少なくとも一つのキャプチャーユニット
と、 前記少なくとも一つのキャプチャーユニットから前記ト
レースデータを受信し、これをフィルターリングするよ
うに適用された、少なくとも一つのモニターユニット
と、 前記少なくとも一つのモニターユニットからデータを受
信し、前記共有バッファへの伝送のために前記仲裁ユニ
ットの少なくとも部分的な制御下で前記データパケット
を生成するように適用された、少なくとも一つの生成ユ
ニットをさらに含む請求項10に記載のデータ処理装
置。 - 【請求項16】 前記第2インターフェースユニットと
通信し、前記プロセッサコアを、前記第2インターフェ
ースユニットを介して前記第2ポートに選択的に接続さ
せるように動作する制御ユニットをさらに含む請求項1
1に記載のデータ処理装置。 - 【請求項17】 前記制御ユニットは、少なくとも一つ
の前記プロセッサコアのレジスタを読み取り、かつ書き
込む請求項16に記載のデータ処理装置。 - 【請求項18】 前記第2インターフェースユニットと
の通信を行い、前記プロセッサコアを、前記第2インタ
ーフェースユニットを介して前記第2ポートに選択的に
接続させるように動作する制御ユニットをさらに含む請
求項12に記載のデータ処理装置。 - 【請求項19】 デジタルプロセッサトレースの少なく
とも一部を表すデータパケットを形成するために、複数
のデータバイトを圧縮する方法であって、 前記複数のデータバイト内で発生する値の第1頻度を表
す第1コーディングを提供するステップと、 前記複数のデータバイト内で発生する値の第2頻度を表
す第2コーディングを提供するステップと、 前記第1及び第2コーディングを使用して前記データパ
ケットを生成して、前記データパケットを圧縮するステ
ップを含み、前記第1及び第2コードは、複数のデータ
ニブルを含む圧縮方法。 - 【請求項20】 第1及び第2コーディングを提供する
前記ステップは、前記値の予想確率分布を決定するステ
ップを含む請求項19に記載の圧縮方法。 - 【請求項21】 複数のデータバイトを有するトレース
データを処理する方法であって、 複数のデータニブルを有する前記複数のデータバイトを
圧縮するステップとして、(i) 第1値の少なくとも一部
を格納するステップと、 (ii)前記第1値の前記少なくとも一部を以前にエンコー
ドされた第2値に対して参照するステップを含み、 前記少なくとも第1部分は、前記第2値と他のデータニ
ブルだけを含む圧縮ステップと、 前記圧縮データバイトを使用して複数のデータパケット
を形成するステップと、 前記複数のデータパケットを格納ディバイスに格納する
ステップとを含むデータ処理方法。 - 【請求項22】 前記第1及び第2値は、識別可能な命
令アドレスを含む請求項21に記載のデータ処理方法。 - 【請求項23】 前記第1及び第2値は、識別可能なデ
ータアドレスを含む請求項21に記載のデータ処理方
法。 - 【請求項24】 デジタルプロセッサトレースユニット
内でデータパケットを処理する方法であって、 所定の第1サイズを有する少なくとも一つの第1アドレ
スを提供するステップと、 可変的な第2サイズを有する少なくとも一つの第2アド
レスを提供するステップと、 少なくとも一つの第1パケット内で前記少なくとも一つ
の第1アドレスをエンコーディングするステップとし
て、第1サイズのフィールド値を含む第1アドレスのエ
ンコーディングステップと、 少なくとも一つの第2パケット内で前記少なくとも一つ
の第2アドレスをエンコーディングするステップとし
て、前記第1サイズのフィールド値に等しくないような
第2サイズのフィールド値を含む第2アドレスのエンコ
ーディングステップとを含み、 前記少なくとも一つの第1パケットは、前記第1サイズ
フィールドに基づいてプールパケットとして処理し、 前記少なくとも一つの第2パケットは、前記第2サイズ
フィールドに基づいて部分サイズパケットとして処理す
るデータパケットの処理方法。 - 【請求項25】 少なくとも一つの第1アドレスを提供
する前記ステップは、少なくとも一つの24ビット命令
アドレスを提供するステップを含み、前記第2サイズフ
ィールド値は、前記第1サイズフィールド値より小さい
請求項24に記載のデータパケットの処理方法。 - 【請求項26】 前記少なくとも一つの第1アドレスを
対応のレジスタに格納するステップと、 前記少なくとも一つの第1及び第2パケットを格納ディ
バイスに格納するステップと、 前記レジスタに格納した前記第1アドレスの少なくとも
一部に基づいて前記格納ディバイス内の前記少なくとも
一つの第2パケットに関連したプールアドレスを決定す
るステップとを含む、請求項24に記載のデータパケッ
トの処理方法。 - 【請求項27】 前記プールアドレスを決定する前記ス
テップは、プールアドレスを有する同一な形態の最も古
くなったパケットよりもっと古い、少なくとも一つの第
2パケットのアドレスだけに関連したプールアドレスを
決定するステップを含む請求項26に記載のデータパケ
ットの処理方法。 - 【請求項28】 デジタルプロセッサトレースに関連し
たデータを圧縮する方法であって、 少なくとも第1及び第2形態のデータの複数の発生を識
別するために前記データを分析するステップとして、前
記第1形態のデータはソースコードの表現から誘導で
き、前記第2形態のデータは前記表現から誘導できな
い、データ分析ステップと、 前記第2形態のデータの前記発生だけを格納ディバイス
に格納するステップとを含み、 圧縮解除中の、前記第1形態のデータの前記発生は前記
ソースコードの表現から誘導され、前記第2形態のデー
タの前記発生は前記格納ディバイスから検索されるデー
タ圧縮方法。 - 【請求項29】 動作中の少なくとも一つのデジタルプ
ロセッサからトレースデータを獲得する方法であって、 前記少なくとも一つのプロセッサからデータを受信する
ように適用された、トレースユニットを提供するステッ
プと、 受信したデータに基づいて前記プロセッサの動作に関連
する複数のパケットを生成するステップと、 前記複数のパケットのうち少なくとも一部を格納ディバ
イスに格納するステップと、 前記格納ディバイスから、それらとのデータ通信を行う
一つのポートを介して、前記パケットを除去するステッ
プとを含むデータ獲得方法。 - 【請求項30】 前記パケットを生成する前記ステップ
の中で前記データを圧縮するステップをさらに含む請求
項29に記載のデータ獲得方法。 - 【請求項31】 前記データは複数のニブルを有する複
数のデータバイトを含み、前記データ圧縮ステップは、 (i) 第1値の少なくとも一部を格納するステップと、 (ii)前記第1値の少なくとも一部を以前にエンコードさ
れた第2値に参照するステップを含み、 前記少なくとも第1部分は、前記第2値と他のデータニ
ブルだけを含む請求項30に記載のデータ獲得方法。 - 【請求項32】 前記圧縮ステップは、 少なくとも第1及び第2形態のデータの複数の発生を識
別するために前記データを分析するステップとして、前
記第1形態のデータはソースコードの表現から誘導で
き、前記第2形態のデータは前記表現から誘導できな
い、データ分析ステップと、 前記第2形態のデータの前記発生だけを格納ディバイス
に格納するステップを含み、圧縮解除中の前記第1形態
のデータの前記発生は前記ソースコードの表現から誘導
され、前記第2形態のデータの前記発生は前記格納ディ
バイスから検索される請求項30に記載のデータ獲得方
法。 - 【請求項33】 前記パケットの中で、対応のパケット
を生成する以前に前記少なくとも一つのプロセッサから
受信した前記データをフィルターリングするステップを
さらに含む請求項30に記載のデータ獲得方法。 - 【請求項34】 前記少なくとも一つのプロセッサは、
それぞれのトレースユニットを有する複数のプロセッサ
を含み、前記方法は、 前記それぞれのトレースユニット内で複数のパケットを
生成するステップと、 前記プロセッサの前記各トレースユニット間で前記格納
ディバイスに対するアクセスを仲裁するステップをさら
に含む請求項30に記載のデータ獲得方法。 - 【請求項35】 前記生成ステップは、前記少なくとも
一つのプロセッサの動作に関連する複数の識別可能なト
レースを生成するステップを含み、前記トレースは、命
令トレース、データトレース、及びタイミングトレース
を含むグループから選択される請求項29に記載のデー
タ獲得方法。 - 【請求項36】 トレースユニットとキャプチャーディ
バイスとの間で、データの伝送を行うのに有用なパケッ
トポートの構造であって、 少なくとも一時的に複数のパケットデータを格納するよ
うに適用された、格納ディバイスと、 複数の入力と少なくとも一つの出力とを有する複数ノー
マルチプレクサとして、前記それぞれの入力は前記格納
ディバイスから前記パケットデータの少なくとも一部を
受信するように適用される、複数ノーマルチプレクサ
と、 前記キャプチャーディバイスと前記複数ノーマルチプレ
クサの少なくとも一つの各出力とのデータ通信を行う複
数のターミナルと、 前記マルチプレクサの動作を制御する信号を生成するよ
うに構成された、少なくとも一つの制御回路とを含むパ
ケットポートの構造。 - 【請求項37】 デジタルプロセッサに関連したトレー
スユニットと共に使用するように適用されたモニターユ
ニットであって、 複数の入力に論理的に関連した信号を出力するように適
用された論理ユニットと、 一つの入力と、前記論理ユニットへの前記入力のうち一
つを含む出力と、を有する命令デコーダと、 複数の入力と、前記論理ユニットへの前記入力のうち一
つを含む一つの出力と、を有する第1マルチプレクサ
と、 それぞれ複数の入力と、前記第1マルチプレクサの前記
複数の入力のうち少なくとも二つを含む一つの出力と、
を有する第1及び第2演算ユニットと、 複数のデータを格納するように適用され、前記第1及び
第2演算ユニットの前記入力の中で、少なくとも一つと
のデータ通信を行う一つの出力を有するレジスタと、 複数の入力と、前記第1及び第2演算ユニットのそれぞ
れの前記複数の入力のうち少なくとも一つとの通信を行
う一つの出力と、を有する第2マルチプレクサとを含む
モニターユニット。 - 【請求項38】 前記命令デコーダと前記第2マルチプ
ルレとの前記入力は、平滑ユニットにより生成される信
号に、少なくとも部分的に関連する請求項37に記載の
モニターユニット。 - 【請求項39】 前記平滑ユニットは、 (i) プロセッサパイプラインから複数の信号を受信し、 (ii)前記パイプライン内の特定命令に関連する全ての信
号を処理して、これらが同一なクロック周期で有効にな
るように適用される、請求項38に記載のモニターユニ
ット。 - 【請求項40】 デジタルプロセッサ用トレースユニッ
トで使われる多重モニターユニットの構造であって、 複数の第1入力に論理的に関連した出力を生成するよう
に適用された第1論理ユニットと、 複数の入力と、前記第1論理ユニットの前記複数の第1
入力のうち一つを含む一つの出力と、を有する第1モニ
ターユニットと、複数の入力と、前記第1論理ユニット
の前記複数の第1入力のうち一つを含む一つの出力と、
を有する第2モニターユニットと、 少なくとも(i)前記論理ユニットの前記出力、及び(ii)
前記第1モニターユニットの前記出力を含む複数の入力
を、少なくとも一つノーマルチプレクサ出力に多重化す
るように適用された、マルチプレクサとを含む多重モニ
ターユニット構造。 - 【請求項41】 複数の第2入力に論理的に関連する出
力を生成するように適用された第2論理ユニットとし
て、前記第2入力のうち少なくとも一つは前記第1論理
ユニットの前記出力を含む第2論理ユニットと、 複数の入力と一つの出力とを有する第3モニターユニッ
トとして、前記第3モニターの前記出力は、前記第2論
理ユニットの前記複数の第2入力のうち一つを含む第3
モニターユニットとを含む請求項40に記載の多重モニ
ター構造。 - 【請求項42】 前記第3モニターユニットは、一双の
モニターユニットを含む請求項41に記載の多重モニタ
ー構造。 - 【請求項43】 前記第1または第2モニターユニット
は、 複数の入力に論理的に関連した信号を出力するように適
用された、モニター論理ユニットと、 一つの入力と、前記論理ユニットの前記入力のうち一つ
を含む一つの出力とを有する、命令デコーダと、 複数の入力と、前記論理ユニットの入力のうち一つを含
む一つの出力とを有する、第1モニターマルチプレクサ
と、 複数の入力と、前記第1モニターマルチプレクサの前記
複数の入力のうち少なくとも二つを含む一つの出力とを
有する、第1及び第2演算ユニットと、 複数のデータを格納するように適用され、前記第1及び
第2演算ユニットと前記入力の中で少なくとも一つとの
データ通信を行う出力を有するレジスタと、 複数の入力と、前記それぞれの第1及び第2演算ユニッ
トの前記複数の入力のうち少なくとも一つと通信を行う
一つの出力とを有する、第2モニターマルチプレクサと
を含む請求項40に記載の多重モニター構造。 - 【請求項44】 デジタルプロセッサに関連したトレー
スユニットで使用するためのもので、複数の入力と少な
くとも一つの出力を有する回路であって、 複数の前記入力と複数の出力を有する優先順位論理回路
と、 第1出力信号を生成するように適用された、第1フリッ
プ・フロップと、 第2出力信号を生成するように適用された、第2フリッ
プ・フロップと、 複数の入力と一つの出力を有する第1信号セレクタとし
て、前記第1信号セレクタの前記出力は前記第1フリッ
プ・フロップの一つの入力を含み、前記優先順位論理回
路の前記出力のうち少なくとも一つは、前記第1セレク
タの一つの入力を含む第1信号セレクタと、 複数の入力と一つの出力とを有する第2信号セレクタと
して、前記第2信号セレクタの前記出力は前記第2フリ
ップ・フロップの一つの入力を含み、前記優先順位論理
回路の前記出力のうち少なくとも一つは、前記第2セレ
クタの少なくとも一つの入力を含む、第2信号セレクタ
とを含む回路。 - 【請求項45】 前記第1及び第2フリップ・フロップ
の前記出力は、それぞれ前記第1及び第2信号セレクタ
の入力を含む請求項44に記載の回路。 - 【請求項46】 前記第1フリップ・フロップの前記出
力は、前記第2信号セレクタの入力も含む請求項45に
記載の回路。 - 【請求項47】 前記セレクタは、マルチプレクサを含
む請求項46に記載の回路。 - 【請求項48】 前記優先順位論理回路の前記複数の入
力は、各モニターユニットの出力を含む請求項44に記
載の回路。 - 【請求項49】 プロセッサトレースユニットと共に使
用するもので、第1データ幅及び第1クロック領域を有
する少なくとも一つのパイプラインと第1クロック領域
を有するパケットポートとの間で複数のデータパケット
をバッファリングするように適用された、格納ディバイ
スであって、 前記第1データ幅より小さな第2データ幅を有するデュ
アルポートRAMを有し、(i)前記データパケットの前記RA
Mへの書き込みは前記第1クロック領域に実質的に同調
され、 (ii)前記RAMから前記データパケットの読み取りは前記
第2クロック領域に実質的に同調される格納ディバイ
ス。 - 【請求項50】 前記第1クロック領域は、前記トレー
スユニットのクロックを含む請求項49に記載の格納デ
ィバイス。 - 【請求項51】 前記RAMは深さをさらに含み、前記第
2データ幅は固定されるが、前記深さは前記プロセッサ
とトレースユニットの構築時にユーザーが構成可能な請
求項50に記載の格納ディバイス。 - 【請求項52】 プロセッサコアと、 前記コアとのデータ通信を行うトレースユニットと、 ホストユニットと、 前記コアと前記ホストユニットとの間でデータ通信を提
供するホストインターフェースと、 前記トレースユニットにより生成された複数のデータパ
ケットをキャプチャーし、前記パケットのうち少なくと
も一部を前記ホストユニットに伝達するように適用され
た、キャプチャーディバイスを含むプロセッサ観測シス
テム。 - 【請求項53】 前記トレースユニット、プロセッサコ
ア、及びホストインターフェースは、単一の集積回路ダ
イの上に配置される請求項52に記載のプロセッサ観測
システム。 - 【請求項54】 前記トレースユニットは、前記コアか
ら受信したパイプラインデータを平滑させるように適用
された、平滑ユニットと、 前記平滑ユニットに作動的に接続され、前記平滑ユニッ
トからデータを選択的にパスさせるように適用された、
モニターと、 前記モニターからの前記パスデータに基づいて複数のデ
ータパケットを生成するように適用された、生成ユニッ
トと、 前記生成ユニットとのデータ通信を行なうものとして、
前記キャプチャーディバイスに対する後続の伝送のため
に、前記複数のデータパケットの少なくとも一部をバッ
ファリングするように適用される、バッファを含む請求
項52に記載のプロセッサ観測システム。 - 【請求項55】 前記バッファと前記キャプチャーディ
バイスとの間におけるデータ通信を行うパケットポート
をさらに含む請求項54に記載のプロセッサ観測システ
ム。 - 【請求項56】 前記ホストユニットは、 ユーザーインターフェースと、 前記ユーザーインターフェースと作動的に通信するデバ
ッガプログラムと、 前記デバッガプログラムと作動的に通信するホストドラ
イバーと、 前記ホストドライバーと前記キャプチャーディバイスと
作動的に通信する第1通信ドライバーモジュールとを含
み、 少なくとも前記ユーザーインターフェース、デバッガプ
ログラム、ホストドライバー及び第1通信ドライバーモ
ジュールは、ユーザーが前記コアに関連して前記トレー
スユニットにより生成されたデータの観測ができるよう
に動作する請求項52に記載のプロセッサ観測システ
ム。 - 【請求項57】 前記デバッガプログラムと前記ホスト
インターフェースと作動的に通信する第2通信ドライバ
ーをさらに含む請求項56に記載のプロセッサ観測シス
テム。 - 【請求項58】 デジタルプロセッサの動作に関連し
て、関連プロセッサ観測ユニットにより少なくとも部分
的に生成されるデータを観測するように適用されたホス
トユニットであって、 ユーザーインターフェースと、 前記ユーザーインターフェースと作動的に通信するデバ
ッガプログラムと、 前記デバッガプログラムと作動的に通信するホストドラ
イバーと、 前記ホストドライバーと前記プロセッサ観測ユニットと
作動的に通信する第1通信ドライバーモジュールとを含
み、 少なくとも前記ユーザーインターフェース、デバッガプ
ログラム、ホストドライバー及び第1通信ドライバー
は、ユーザーが前記観測ユニットにより生成される前記
プロセッサとの関連データを観測できるように動作す
る、ホストユニット。 - 【請求項59】 前記ホストドライバーと前記デジタル
プロセッサとの間でデータ通信を行うように動作する第
2通信ドライバーをさらに含む請求項58に記載のホス
トユニット。 - 【請求項60】 パイプラインプロセッサコアと、 前記コアから受信したパイプラインデータを平滑させる
ように適用された、平滑ユニットと、 前記平滑ユニットに作動的に接続されて、前記平滑ユニ
ットからデータを選択的にパスさせるように適用された
モニターと、 前記モニターからの前記パスデータに基づいて複数のデ
ータパケットを生成するように適用された生成ユニット
と、 前記生成ユニットとのデータ通信を行い、外部ディバイ
スに対する後続の伝送のために、前記複数のデータパケ
ットのうち少なくとも一部をバッファリングするように
適用されたバッファとを含む集積回路。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US33886901A | 2001-11-06 | 2001-11-06 | |
US338869 | 2001-11-06 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2003150403A true JP2003150403A (ja) | 2003-05-23 |
Family
ID=23326490
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002132057A Pending JP2003150403A (ja) | 2001-11-06 | 2002-05-07 | データプロセッサの観測方法及び装置 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2003150403A (ja) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2009110284A (ja) | 2007-10-30 | 2009-05-21 | Fujitsu Ltd | 信号処理装置、カード型デバイス及び障害再現方法 |
WO2011024330A1 (ja) * | 2009-08-24 | 2011-03-03 | パナソニック株式会社 | アイドル状態検出回路、半導体集積回路、信号処理装置、アイドル状態検出方法 |
KR20140006861A (ko) * | 2011-01-13 | 2014-01-16 | 에이알엠 리미티드 | 처리 장치, 추적 유닛 및 진단 장치 |
US8902694B2 (en) | 2012-09-12 | 2014-12-02 | International Business Machines Corporation | Integrity check of measured signal trace data |
US10089212B2 (en) | 2015-07-20 | 2018-10-02 | Toshiba Memory Corporation | Memory system, information processing system, and host device outputting debugging information through a host interface |
CN110825312A (zh) * | 2018-08-10 | 2020-02-21 | 北京百度网讯科技有限公司 | 数据处理装置、人工智能芯片及电子设备 |
JP2021531530A (ja) * | 2018-04-03 | 2021-11-18 | ザイリンクス インコーポレイテッドXilinx Incorporated | デバッグコントローラ回路 |
CN115510788A (zh) * | 2022-11-10 | 2022-12-23 | 山东云海国创云计算装备产业创新中心有限公司 | 一种编码的方法、***、设备和存储介质 |
JP7509565B2 (ja) | 2019-04-16 | 2024-07-02 | シーメンス インダストリー ソフトウェア インコーポレイテッド | 命令実行のトレース |
-
2002
- 2002-05-07 JP JP2002132057A patent/JP2003150403A/ja active Pending
Cited By (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2009110284A (ja) | 2007-10-30 | 2009-05-21 | Fujitsu Ltd | 信号処理装置、カード型デバイス及び障害再現方法 |
WO2011024330A1 (ja) * | 2009-08-24 | 2011-03-03 | パナソニック株式会社 | アイドル状態検出回路、半導体集積回路、信号処理装置、アイドル状態検出方法 |
US10379989B2 (en) | 2011-01-13 | 2019-08-13 | Arm Limited | Processing apparatus, trace unit and diagnostic apparatus |
KR20140006861A (ko) * | 2011-01-13 | 2014-01-16 | 에이알엠 리미티드 | 처리 장치, 추적 유닛 및 진단 장치 |
JP2014507710A (ja) * | 2011-01-13 | 2014-03-27 | アーム・リミテッド | 処理装置、トレースユニット、および診断装置 |
KR102025556B1 (ko) * | 2011-01-13 | 2019-09-26 | 에이알엠 리미티드 | 처리 장치, 추적 유닛 및 진단 장치 |
US8902694B2 (en) | 2012-09-12 | 2014-12-02 | International Business Machines Corporation | Integrity check of measured signal trace data |
US8913458B2 (en) | 2012-09-12 | 2014-12-16 | Lenovo Enterprise Solutions (Singapore) Pte. Ltd. | Integrity check of measured signal trace data |
US10089212B2 (en) | 2015-07-20 | 2018-10-02 | Toshiba Memory Corporation | Memory system, information processing system, and host device outputting debugging information through a host interface |
JP2021531530A (ja) * | 2018-04-03 | 2021-11-18 | ザイリンクス インコーポレイテッドXilinx Incorporated | デバッグコントローラ回路 |
JP7247213B2 (ja) | 2018-04-03 | 2023-03-28 | ザイリンクス インコーポレイテッド | デバッグコントローラ回路 |
CN110825312A (zh) * | 2018-08-10 | 2020-02-21 | 北京百度网讯科技有限公司 | 数据处理装置、人工智能芯片及电子设备 |
CN110825312B (zh) * | 2018-08-10 | 2023-06-23 | 昆仑芯(北京)科技有限公司 | 数据处理装置、人工智能芯片及电子设备 |
JP7509565B2 (ja) | 2019-04-16 | 2024-07-02 | シーメンス インダストリー ソフトウェア インコーポレイテッド | 命令実行のトレース |
CN115510788A (zh) * | 2022-11-10 | 2022-12-23 | 山东云海国创云计算装备产业创新中心有限公司 | 一种编码的方法、***、设备和存储介质 |
CN115510788B (zh) * | 2022-11-10 | 2023-02-28 | 山东云海国创云计算装备产业创新中心有限公司 | 一种编码的方法、***、设备和存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9798645B2 (en) | Embedding stall and event trace profiling data in the timing stream | |
JP4233893B2 (ja) | データ処理システムにおける命令のトレーシング | |
US6009270A (en) | Trace synchronization in a processor | |
US7080283B1 (en) | Simultaneous real-time trace and debug for multiple processing core systems on a chip | |
US6154857A (en) | Microprocessor-based device incorporating a cache for capturing software performance profiling data | |
EP0974094B1 (en) | Trace cache for a microprocessor-based device | |
US5978902A (en) | Debug interface including operating system access of a serial/parallel debug port | |
KR100517679B1 (ko) | 컴팩트한 트레이스 기록 기억장치를 포함하는 디버그 인터페이스 | |
US6175914B1 (en) | Processor including a combined parallel debug and trace port and a serial port | |
US7437619B2 (en) | Trace reporting method and system | |
US6145100A (en) | Debug interface including timing synchronization logic | |
US6154856A (en) | Debug interface including state machines for timing synchronization and communication | |
KR20190121378A (ko) | 디버깅 시스템 및 방법 | |
US20060031662A1 (en) | Processor implementing conditional execution and including a serial queue | |
US7607047B2 (en) | Method and system of identifying overlays | |
US7278073B2 (en) | Diagnostic data capture within an integrated circuit | |
JP2003150403A (ja) | データプロセッサの観測方法及び装置 | |
US7334114B2 (en) | Real-time monitoring, alignment, and translation of CPU stalls or events | |
EP1184790B1 (en) | Trace cache for a microprocessor-based device | |
JP2003345472A (ja) | 電力プロファイリング方法及び電力プロファイリング用システム | |
Li et al. | A readback based general debugging framework for soft-core processors | |
US20060259664A1 (en) | Real-time prioritization of stall or event information | |
Weingarten | Hardware Accelerated Trace Analysis for Compiler Optimizations | |
Melear | Emulation techniques for microcontrollers with internal caches and multiple execution units | |
JPH1011112A (ja) | システム用のファームウェアの開発及びテスト用のモニタ装置、開発方法、及び、汎用回路内エミュレータ装置 |