(57)【要約】機能バスを通して内部接続される複数の機能回路を持った集積回路が、機能バス上でバストランザクションを用いて診断動作を実行する診断バスマスター回路と共に提供される。これらの診断動作は、集積回路の通常の速度動作の間に実時間で実行して、より正確な診断結果を作り出すことができる。診断バスマスター回路は、特に、メモリからデータ値を読み出したり、データ値をメモリへ診断動作の一部として書き込んだりするのに便利である。
2006514375.tif 000002
【特許請求の範囲】
【請求項１】
集積回路において、
データ処理動作を実行することのできる複数の機能回路と、
前記複数の機能回路間の通信を提供することのできる少なくとも１つの機能バスと、
前記複数の機能回路の実時間動作中に、前記少なくとも１つの機能バスを通して、前記複数の機能回路の内の１つ或いは２つ以上へバストランザクション要求を発することによって、前記複数の機能回路の少なくとも１つにおいて、診断動作を実行することのできる診断バスマスター回路と
を備えることを特徴とする集積回路。
【請求項２】
前記診断バスマスター回路は、
デバッグ動作と、
製造試験動作と、
製造プログラミング動作と、
製造構成動作と、
フィールドプログラミング動作と、
フィールド構成動作と
の内の１つ或いは２つ以上を実行することができることを特徴とする請求項１記載の集積回路。
【請求項３】
前記診断バスマスター回路は、前記診断マスター回路が少なくとも１つの診断動作を実行し前記機能バスにアクセスすることを認可する、認証動作を実行することができることを特徴とする請求項１または２のいずれか１つに記載の集積回路。
【請求項４】
前記少なくとも１つの機能バスに接続される認証回路を備え、前記認証動作は、前記認証回路へ認証要求を発する前記診断バスマスター回路を備え、前記認証回路は、前記認証要求が所定の基準に一致するかどうかによって前記診断バスマスター回路を選択的に認可することができることを特徴とする請求項３記載の集積回路。
【請求項５】
前記診断バスマスター回路を、前記複数の機能回路の内の少なくとも１つに接続する専用の診断バスを備え、前記専用の診断バスは、前記少なくとも１つの機能バスを通してアクセスができないデータへのアクセスを提供することを特徴とする請求項１乃至４のいずれか１つに記載の集積回路。
【請求項６】
異なるバスプロトコルを持った複数の機能バスを備え、前記診断バスマスター回路は、それぞれ前記各機能バスに対するバスプロトコルを用いて各機能バスと通信するための複数のバスインターフェイス回路を備えることを特徴とする請求項１乃至５のいずれか１つに記載の集積回路。
【請求項７】
前記診断バスマスター回路は、各外部信号プロトコルを用いて各外部診断機器と通信するための外部インターフェイス回路を備えることを特徴とする請求項１乃至６のいずれか１つに記載の集積回路。
【請求項８】
前記診断バスマスター回路は、前記集積回路のクロック領域と、前記診断バスマスター回路に結合された外部診断機器のクロック領域との間で信号を転送することができることを特徴とする請求項１乃至７のいずれか１つに記載の集積回路。
【請求項９】
前記診断バスマスター回路は、
前記少なくとも１つの機能バスに結合される装置からデータ値をロードすることと、
前記少なくとも１つの機能バスに結合される装置にデータ値を記憶することと、
前記少なくとも１つの機能バスに結合される装置間でデータ値をコピーすることと、
前記少なくとも１つの機能バスに結合される装置に記憶されるデータ値を検証することと
の内の少なくとも１つ或いは２つ以上を実行ことができることを特徴とする請求項１乃至８のいずれか１つに記載の集積回路。
【請求項１０】
フラッシュメモリが前記少なくとも１つの機能バスに結合され、前記診断バスマスター回路は、フラッシュメモリプログラミングプロトコルを用いて前記フラッシュメモリをプログラムすることができることを特徴とする請求項１乃至９のいずれか１つに記載の集積回路。
【請求項１１】
前記集積回路は、システムオンチップの集積回路であることを特徴とする請求項１乃至１０のいずれか１つに記載の集積回路。
【請求項１２】
前記少なくとも１つの機能バスは、前記集積回路の外部バスであることを特徴とする請求項１乃至１１のいずれか１つに記載の集積回路。
【請求項１３】
前記少なくとも１つの機能バスは、ＡＭＢＡバスであることを特徴とする請求項１乃至１２のいずれか１つに記載の集積回路。
【請求項１４】
データ処理動作を実行することができる複数の機能回路と、前記複数の機能回路間の通信を提供することができる少なくとも１つの機能バスとを持った集積回路上で実時間診断動作を実行する方法において、前記方法は、前記複数の機能回路の実時間動作中に、前記少なくとも１つの機能バスを通して、診断バスマスター回路から前記複数の機能回路の内の１つ或いは２つ以上へバストランザクション要求を発する段階を備えることを特徴とする方法。
【請求項１５】
前記診断バスマスター回路は、
デバッグ動作と、
製造試験動作と、
製造プログラミング動作と、
製造構成動作と、
フィールドプログラミング動作と、
フィールド構成動作と
の内の１つ或いは２つ以上を実行することができることを特徴とする請求項１記載の方法。
【請求項１６】
前記診断バスマスター回路は、前記診断マスター回路が少なくとも１つの診断動作を実行し前期機能バスにアクセスすることを認可する、認証動作を実行することができることを特徴とする請求項１４または１５のいずれか１つに記載の方法。
【請求項１７】
認証回路が前記少なくとも１つの機能バスに接続され、前記認証動作は、前記診断バスマスター回路が、前記認証回路に認証要求を発する前記診断バスマスター回路を備え、前記認証回路は、前記認証要求が所定の基準に一致するかどうかによって前記診断バスマスター回路を選択的に認可することができることを特徴とする請求項１６記載の方法。
【請求項１８】
専用の診断バスが、診断バスマスター回路を前記複数の機能回路の内の少なくとも１つに接続し、前記専用の診断バスは、前記少なくとも１つの機能バスを通してアクセスができないデータへのアクセスを提供することを特徴とする請求項１４乃至１７のいずれか１つに記載の方法。
【請求項１９】
前記集積回路は、異なるバスプロトコルを持った複数の機能バスを備え、前記診断バスマスター回路は、それぞれ前記各機能バスに対するバスプロトコルを用いて各機能バスと通信するための複数のバスインターフェイスを持つことを特徴とする請求項１４乃至１８のいずれか１つに記載の方法。
【請求項２０】
前記診断バスマスター回路は、各外部信号プロトコルを用いて各外部診断機器と通信するための外部インターフェイス回路を備えることを特徴とする請求項１４乃至１９のいずれか１つに記載の方法。
【請求項２１】
前記診断バスマスター回路は、前記集積回路のクロック領域と、前記診断バスマスター回路に結合された外部診断機器のクロック領域との間で信号を転送することができることを特徴とする請求項１４乃至２０のいずれか１つに記載の方法。
【請求項２２】
前記診断バスマスター回路は、
前記少なくとも１つの機能バスに結合される装置からデータ値をロードすることと、
前記少なくとも１つの機能バスに結合される装置にデータ値を記憶することと、
前記少なくとも１つの機能バスに結合される装置間でデータ値をコピーすることと、
前記少なくとも１つの機能バスに結合される装置に記憶されるデータ値を検証することと
の内の少なくとも１つ或いは２つ以上を実行ことができることを特徴とする請求項１４乃至２１のいずれか１つに記載の方法。
【請求項２３】
フラッシュメモリが前記少なくとも１つの機能バスに結合され、前記診断バスマスター回路は、フラッシュメモリプログラミングプロトコルを用いて前記フラッシュメモリをプログラムすることができることを特徴とする請求項１４乃至２２のいずれか１つに記載の方法。
【請求項２４】
前記集積回路は、システムオンチップの集積回路であることを特徴とする請求項１４乃至２３のいずれか１つに記載の方法。
【請求項２５】
前記少なくとも１つの機能バスは、前記集積回路の内部バスであることを特徴とする請求項１４乃至２４のいずれか１つに記載の方法。
【請求項２６】
前記少なくとも１つの機能バスは、ＡＭＢＡバスであることを特徴とする請求項１４乃至２５のいずれか１つに記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、集積回路の分野に関する。より詳細には、本発明は、集積回路のための搭載型診断回路に関する。
【背景技術】
【０００２】
集積回路のために搭載型診断回路を提供することは既知のことである。その種の既知の回路の一例は、英国ARM Limited of Cambridge社が自社のいくつかのマイクロプロセッサの設計で使用する、JTAG型の制御器で制御される直列スキャンチェインである。既知のスキャンチェイン型診断回路での問題は、データの直列のスキャンインおよびスキャンアウトが、実時間の及び／または効率的な診断動作が可能なほど十分に高速でないことである。特に、直列の診断データが直列のスキャンチェインをスキャンインとスキャンアウトするように、下記の集積回路の通常の動作速度を遅くするか、止める必要があるだろう。下記の集積回路を通常の動作速度で動作させることで、実行される診断動作は、真に集積回路の実際の機能動作を表すものではなくなる。ある不良のみが全速の動作で表れ、回路が診断の直列スキャンチェインの使用に合わせて動作しなくてはならないような遅い速度では不良が分からないだろう。さらに、デバッグのためにプロセッサへの通信にＪＴＡＧを使用することで、システム資源へアクセスする少なくとも２段階の方法が作られる。
【発明の開示】
【課題を解決するための手段】
【０００３】
本発明の一態様によると、集積回路は、
データ処理動作を実行可能な複数の機能回路と、
前記複数の機能回路間の通信を提供する動作が可能な、少なくとも１つの機能バスと、
前記複数の機能回路の実時間動作中に、バストランザクション要求を、前記少なくとも１つのバスを通して１つあるいは２つ以上の前記複数の機能回路へ発することによって、前記複数の機能回路の少なくとも１つにおいて診断動作を実行することが可能な診断バスマスター回路と
を備える。
【０００４】
本発明は、集積回路の機能バスに結合された診断バスマスター回路を提供する。この診断バスマスター回路は、診断動作を実行するために、バストランザクションを機能バス上へ発するのに使用することができる。これらのバストランザクションは、あるデータで機能回路を活性化したり、機能回路もしくはその組み合わせたものから、あるいは他の作用によってデータを取得する役に立つ。この手法は、診断信号の活性化のための挿入位置を提供し、直列スキャンチェインの周囲でデータを計測して回路中に分散しているラッチに値をロードする必要がないために実時間で動作することが可能なものを取得する。機能バスを通しての診断アクセスは、実用面から制限があると考えるかも知れないが、実際には、現在のシステムオンチップ型集積回路内部で実行を希望する診断試験の種類の大部分は、ＡＭＢＡ或いはＡＨＢバスのような標準的なバスを通して様々な機能回路間の適正な通信を調べることを中心に展開する。異なる機能回路が既に別々に試験されており、独立した個々のものとして正当であることが確認されているだろうことも多く、新しい集積回路の設計で重要なことは、それらの個々のものの内部接続と、機能バスを通した適切な通信である。本手法は、そのような種類の診断動作を、それほど押し付けがましくなく、オーバーヘッドを少なく、そして素早く提供するのに適している。
【０００５】
診断バスマスター回路は、デバッグ或いは製造試験型動作の形態で、診断動作を実行することができる。加えて、診断バスマスター回路は、製造プログラムや製造構成やフィールドプログラムあるいはフィールド構成型の動作を実行するのにも使用することができる。これによって、診断バスマスター回路は、純粋な診断以外の分野で有益な効果を持って再利用し、それによって関連するオーバーヘッドを償却することができる。
【０００６】
本発明の実施形態において、診断バスマスター回路は、診断動作を実行する前に、自身を認証するために認可動作を実行するように準備されるだろう。この特徴は、診断の特徴が、安全なデータへのアクセスを得るのに不適切に使用することができる安全システムにおいて、非常に有利である。診断バスマスター回路が使用前に自身を確実に認証しなくてはならないことによって、この機構を不適切に使用することを制限することができる。特に、認証は、診断バスマスター回路が機能回路要素にアクセスすることができる前に必要である、秘密鍵（外部供給源によって提供される）を含むような所定の基準に合致する認証要求を診断バスマスター回路が発するよう要求する形をとることができる。
【０００７】
機能バスへのアクセスを提供することに加えて、本発明の実施形態には、診断バスマスター回路が機能バスを通じて通常はアクセスしないデータへアクセスできる専用診断バスが含まれる。よって、専用診断バスは、通常動作の間に機能回路間で通常は転送する必要のないものとして、通常は機能バスを通してアクセスできない機能回路内部の状態にアクセスするように用意することができる。この特徴は、特に、上述した認証手法と結合させたときに有用であり、そこでは、この専用診断バスへのアクセスは認証された動作に限定することができる。さらに、そのようなバスを分離することで、これら追加データの値／レジスタの、悪意のある不慮の使用を避けることができる。
【０００８】
いくつかの集積回路には、異なるバスプロトコルを持っているだろう多数の機能バスが利用されていることは理解されよう。実施形態では、診断バスマスター回路に、それら独自のバスプロトコルを用いて各々の機能バスで通信して応答可能な複数のバスインターフェイス回路を提供することで、この問題に応じる。選択機構によって、どのバスにアクセスするかを選択することができる。
【０００９】
診断バスマスター回路は、例えば適切なインターフェイスカードを備えたコンピュータのような外部診断機器と、外部信号プロトコルを用いて通信する。そのような通信を利用するために診断バスマスター回路には、この通信リンクを提供して通信プロトコル間に必要によって適用するための外部インターフェイス回路が含まれる。
【００１０】
本発明の実施形態において、診断バスマスター回路は、外部診断環境を集積回路のクロックの環境から効果的に切り離すやり方で、クロックドメイン間で信号を転送するようにも動作可能である。
【００１１】
診断バスマスター回路は、メモリや周辺装置や他の機器内部に記憶されたデータ値のような、機能バスに結合された機器内部に記憶されたデータ値を走査するのに特に適している。これらのデータ値は、診断バスマスター回路を用いて、ロードしたり記憶したりコピーしたり、検証したりすることができる。
【００１２】
その種の使用の中で特に有用な例は、集積回路がバスに結合したフラッシュメモリを含み、診断バスマスター回路がフラッシュメモリのプログラミングプロトコルを用いてそのフラッシュメモリにプログラムするのに使用される時である。そのようなフラッシュメモリへのプログラムは、通常、実行時間動作であり、集積回路の汎用機能回路を用いることは効率的でも効果的でもないだろう。
【発明を実施するための最良の形態】
【００１３】
本発明の実施形態が、例示の目的のみで、添付の図面を参照して説明される。
【００１４】
図１は、外部診断機器４に接続された集積回路２を示している。外部診断機器４と集積回路２の間の接続は、ＪＴＡＧあるいはＳＷＪのような双方向の直列インターフェイス経由である。集積回路２内部では、インターフェイス回路６が双方向信号を受信する。直列信号から復号されたデータと、その直列信号から復号された制御信号は、それらの制御信号とでとによって決まる集積回路２の他の要素上で診断動作を実行する診断回路８に渡される。データ信号と制御信号は、集積回路２から外部診断機器４へ双方向の直列信号を介して送り返されるだろう。集積回路２は、典型的には、システムオンチップ（ＳｏＣ）集積回路であろう。
【００１５】
集積回路２内部の機能回路には、プロセッサコア１０と、コプロセッサ１２と、メモリ１４と、ＵＡＲＴ装置１６とが含まれる。これらの機能回路は、機能バス１８（例えば、ＡＭＢＡ，ＡＨＢ或いは機能回路を接続するための他のバス）によって接続される。診断回路８は、集積回路２内部の１つのブロックとして図示されている。この診断回路は、様々な形態を取ることができ、例えば、集積回路２、あるいは或る機能要素の周辺の回り、あるいはある機能要素内部に延びる直列のスキャンチェインを必要に応じて含むことができる。診断回路８は、ＢＩＳＴ装置等のような他の形態を取ることもできる。
【００１６】
使用に当たって、外部診断機器を使用する技術者は、双方向直列インターフェイスに沿ってインターフェイス回路６を通って集積回路２に渡される制御信号とデータに応答して集積回路２上で実行されるある診断動作を命令するだろう。結果としてのデータは、インターフェイス回路６を通り双方向インターフェイスに沿って外部診断機器４へ送り返される。
【００１７】
図２は、プロセッサコア５４と、コプロセッサ５６と、フラッシュメモリ５８と、入出力回路６０と、メモリ６２を含む複数の機能回路を組み込んだ集積回路５２（例えば、ＳｏＣ集積回路）を図示している。プロセッサコア５４と、フラッシュメモリ５８と、入出力回路６０と、メモリ６２は、共通機能バス６４を通して接続され、これは、例えば、ＡＲＭ  ＡＭＢＡ  ＡＨＢバスあるいは他のシステムバスであろう。この共通機能バス６４には、関連するバスプロトコルがあり、機能回路間でデータと制御のトランザクションを渡すための通常のマスター／スレーブ型装置内で使用される。
【００１８】
診断バスマスター回路６６が、バストランザクションを用いて診断動作を実行するために提供される。これらのバストランザクションは、データあるいは制御値を機能回路に与えるか、機能回路からデータを取り戻すためのものである。診断バスマスター回路６６は、任意の認証回路６８を経由して機能バス６４へ接続される。診断バスマスター回路６６は、本例ではプロセッサコア５４とコプロセッサ５６とに専用診断アクセスを提供する専用診断バス７０（例えば、個別（private）ＡＭＢＡバスあるいは特製の個別バス）にも接続する。この専用診断バス７０は、通常は機能バス６４に結合せず、純粋に診断の目的で専用診断バス７０上に露出されるデータ値へのアクセスを提供することができる。
【００１９】
インターフェイス回路７２と診断回路７４が、診断バスマスター回路６６を外部診断機器（図示せず）に結合するべく提供される。インターフェイス回路７２は、外部診断機器が使用する外部プロトコル、例えば上述した双方向の直列通信を支援する。診断バスマスター回路６６は、トランザクションが診断の目的で発せられるそれぞれのバスのバス信号プロトコルを支援する責任を持つ。
【００２０】
選択可能な認証回路６８は、診断バスマスター回路６６に機能バスあるいはバス６４の一部に、認証段階を通過したらアクセスさせるだけの機能を働く。この認証段階は、所定の秘密鍵に適合する適切な鍵を診断バスマスター回路６６から認証回路６８へ与えるものである。そうして、秘密鍵を持ち適切に認可された人のみが診断バスマスター回路６６を、認証回路６８を通って機能バス６４にアクセスすることができるようなやり方で活性化するだろう。従って、秘密のデータあるいは他の重要な資料は、機能回路内で保護することができる。認証は、特権的なスレーブへのアクセスのような、いくつかのバスアクセスを制御して、他のバスアクセスを自由に利用可能にするのに使用することができる。
【００２１】
集積回路５２と外部診断機器は、異なるクロックの領域で動作することができるのは理解されよう。インターフェイス回路７２は、これら２つのクロックの領域間での橋渡し手段を効果的に提供する。
【００２２】
診断バスマスター回路６６は、データ値をメモリや周辺装置や他の装置のような装置へロードしたり、データ値をそれらの装置から戻して記憶したり、データ値をそれらの装置間で複写したり、それらの装置間で記憶したデータを検証したりするのに使うバストランザクションを発するのに使用することができる。
【００２３】
診断バスマスター回路６６は、フラッシュメモリプログラミングプロトコルに応じてフラッシュメモリにプログラムするのに使用することもできる。これは、集積回路５２内のフラッシュメモリ５８にプログラムするためにいくつかの機構を提供する必要があるので、提供に関連するオーバーヘッドを償却する診断バスマスター回路６６の非診断的な使用である。
【００２４】
実施形態の詳細な説明を以下に掲げる。
以下の説明は、次の用語と省略形を用いる。
【００２５】
【表１】
2006514375.tif 000003
【００２６】
〈導入部〉
ＤＢＴ（デバッグバスタップ）は、小さいＪＴＡＧ  ＴＡＰであり、ＡＭＢＡバスに接続する。ＤＢＴは、ホストから、ＴＪＡＧやＳＷＪや直通ポートや他の手段を用いてアクセスされようし、ＡＭＢＡバス以外のバス上で動作するだろう。システム設計によっては、バス接続は多数マスターバス設計にとってバスマスターブロックであろうし、或いは、調停器によって管理されるならばＡＭＢＡ  Ｌｉｔｅブロックであろう。
【００２７】
メモリＴＡＰによって、ＡＲＭコアが実行中であれ、デバッグで停止中であれ、リセットでホールドされていても、メモリシステム（Ｌ１キャッシュ以上の）へのアクセスが可能になる。これによって、ＴＡＰを以下の多くの目的のためにシステム中でより広く使用することが可能になる。
・コアブーツの前にシステムを停止して試験する。これは、フラッシュシステムでは特に重要であるが、チップレベルの試験のための意味もある。
・プロセッサＪＴＡＧモデルを使用した際に可能なものよりも、ダウンロードとメモリ読み出しがより高速。
・実行中のシステムにおいて、コアを止めずにメモリと周辺装置へ読み出し／書き込みアクセスする。これには邪魔があるが、それは一定のものであり小さなものである（なぜならメモリへのアクセスは一定のものではないが、ＪＴＡＧ  ＴＣＫのタイミングで区切られているから）。
・コアクロック速度（低速スリープ）の変化に無関係に、メモリにアクセスできる。
・バスに現れる時に、フラッシュにプログラムするのに使用することができる（しかし、いくつかのＦＰＧＡブートフラッシュには、ＡＭＢＡスレーブでなければ、達することがないだろう）
・デバッグレジスタの構成／制御がコアの一部ではない。これによって、多数のＴＡＰが異なるデバッグブロックを支援する必要がなくなる。デバッグレジスタは、コアによって内部機構の必要性を排除するためにエクスポートされ得る−これによって、実行中のアクセスが可能になり、よりすっきりとした設計が可能になる。
【００２８】
メモリＴＡＰは、極めて最適化されていて、連続的（ダウンロードのような）と非連続的の、非常に高速なアクセスが可能になる。また、単一の場所を繰り返してポーリングするために最適化され、そのポーリング上で時間計測を支援するエミュレータによって時間の刻印を提供することができる（なぜならバス動作は決定性のものだから）。速いフラッシュダウンロードも、バスラッパー内にフラッシュプログラミングアルゴリズムを部分的に少し埋め込むことで促進される。
【００２９】
〈デバッグシステムのバスタップ部品〉
メモリＴＡＰは、以下の７つの基本的な問題を解決することを目的としている。
１．非常に速いメモリダウンロード（及びアップロード）を可能にする。１０ＭＨｚにおいて、３Ｍバイト／秒のダウンロードが高速のエミュレータには妥当であり、低速ならば６００Ｋバイト／秒が妥当である。
２．ＡＲＭコアが停止している間（デバッグ中）や、実行中や、スリープ時や、リセット中や、他の何らかの状態の時のアクセスを可能にする。これは、この部品が、より以上のシステム観点（system view）を可能にすることを意味する。
【００３０】
３．バス上での読み出しと書き込み時の不良をより完全に取り扱うことを可能にする。この機構は、アボートを完全に扱い、結果としてProcessor State（プロセッサの状態）を変えない。メモリアクセスがプロセッサコアを通して行われる時、その状態は全ての動作によって影響されるが、故障によってさらに影響される。ＤＢＴは、バスの不良の後でその状態を変えることはなく、定められたように信号で伝えるだけである。
【００３１】
４．フラッシュに直接プログラムすることを可能にする。これは、フラッシュへ最大速度でプログラムすることを可能にするだけでなく、プロセッサが依然としてリセット中の間に、フラッシュにプログラムすることを可能にする（よって臨界的ブートコードをプログラムするのに使用することができる）。もしＦＰＧＡビットルートフラッシュあるいはフラッシュを使った他の装置が、バス上に現れるなら、さらにそれらの要素をプログラムするのに使用することができる。選択的なフラッシュのサポート無しでも、ＤＢＴは、エミュレータがアクセス間の予測可能な時間遅延を生成できる限り、直接フラッシュにプログラムしたり、或いは、強制検証（pushed-verify）付きの１ワードごとのバッチ式で書き込むのに使用することができる。
【００３２】
５．デバッグ専用に取っておいたローカルセグメントにアクセスするのに使用することができる。すなわち、ＤＢＴは、デバッグ用の個別バスに合わせることができる（また、一般的用途のためにシステムバスに合わせることもできる）。デバッグ部品と一般用部品の両方に対してＡＳＩＣ専用デバッグレジスタをエクスポートするのに使用することもでき、従って、ＣＡＮバス周辺装置は、いくつかのレジスタをこのセグメントにエクスポートしてデバッグを促進することができる。
【００３３】
６．対象となるＳＷ（モニターやＲＴＯＳエージェントなど）との通信のパスとして使用することができる。５とは異なり、これは、さらにメインバス上で行うことができる。従って、ＲＴＯＳ  Ｄｅｂｕｇ  Ａｇｅｎｔは、これをアクセスのために使用することができる（例えば、ＤＳＰ上で実行中のＲＴＯＳでさえも）。ＤＣＣ（ＡＲＭ  Debug Communication Channel レジスタ）と異なり、これはバッファリングが可能である。割り込みの駆動とメモリ位置で一致したいくつかによって、ホストと対象のＳＷは、簡単なハンドシェークを用いて互いに通信する。メッセージの大きさは、必要なだけの長さが許され、対象のＳＷは、ＲＡＭに書いた後に他の動作に向かうので、遅れることはない（例えば、ＣＰ１４で待つ）。
【００３４】
７．トレースデータを高速でアンロードするのに使用することができる。ＡＨＢ上にマップされたオンチップのトレースバッファは、この方法を用いて非常に高速でアンロードすることができる。さらに、満たしている間も排出することができるトレースバッファによって、（３−４メガバイト／秒程度の帯域制限で）連続的に集めることができる。
【００３５】
〈エージェント／モニターの通信（AttentionとＡＣＫ）〉
ＤＢＴは、実行中に対象のエージェントと通信するだけでなく、プロセッサコアが実行中にダウンロードとアクセスのために直接メモリアクセス（モニター無し）するのに有用であろうと考えられる。エージェントの通信は、パケットをＲＡＭに書き、完了をAttentionビットで知らせ、ＡＣＫ信号／ビットがアサートされるのを待つことによって動作する。その後、読み返すことができる。このモデルの利点は、パケットごとに割り込みを受けるだけでよいことである（その時でさえ、パケットごとではあるがポールすることができ、−バッファすることは自由である）。パケットの大きさは一定ではないが、プロトコルおよび、エージェントもしくはモニターの選択によって決まる。
【００３６】
Attention信号をコアへ（割り込みとして）接続することの選択と、ＡＣＫ信号をコアから（ＧＰＩＯとして）接続し返すことの選択は、システム設計次第である。これはプロセッサの種類とアプリケーションの使用に対して大きく促進されると思われる。
【００３７】
通信する主なエージェントは、ＲＴＯＳデバッグ（Running System Debug(RSD)mode）に対するスレッドだけでなく、普通のデバッグに対するモニターであろう。
【００３８】
〈フラッシュメモリの支援〉
選択可能なフラッシュメモリの支援は、システムに埋め込まれたフラッシュの高速プログラミングを可能にするべく提供される。その機構は、マスクＲＯＭ定数を事前書き込みアドレス／データと、おそらく事後書き込みアドレス／データに対して加えることによって動作する。必要に応じて、急いで検証をすることもできる（しかし、一般に、ブロック全体に書き込み、その後戻って検証する方が望ましく−この方が早くて安全である）。強制検証で、検証の段階は非常に速くなる。
【００３９】
フラッシュモデルによって、（エンジン制御に対してプログラミング定数を更新する自動車修理工のような）外部機構から、域内のフラッシュ再プログラムも可能になるだろう。これは、フラッシュ自身を決して変更しないアプリケーションに対しては、有用であろう。
【００４０】
ＤＢＴ内にフラッシュ支援を持つ一般的な理由は、それによって、大小にかかわらず、非常に高速のフラッシュプログラミングが可能になることである。これによって、デバッグ時間が速くなる。多くのフラッシュ装置にとって、事前書き込みとデータ書き込みの間の時間は、ある時間以内でなくてはならず、さもないと時間切れになるだろうことには注意したい。これは、ＪＴＡＧエミュレータを通して直接にプログラムすることは、不可能だということである。ＤＢＴフラッシュ支援によって、これは問題では無い。
【００４１】
〈キャッシュ問題とＴＣＭ〉
ＤＢＴは、バス上を見ることができるだけである。二次セグメントモデルに対する準備はあるが、Ｌ１キャッシュの中を見ることはできない。もし、ＤＢＴがその前に置かれると、Ｌ２キャッシュを見ることができるのみであろう。Tightly Coupled Memory（ＴＣＭ）は、問題も提起する。
【００４２】
Ｌ１キャッシュにとって、問題は、ある環境下でのみ発生する。
・コードをダウンロードするとき、“Ｉ”キャッシュは消去するか、無効にして、新しいデータを再ロードしなくてはならない。ダウンロードに対して、これは、通常は問題とはならない（なぜなら、コアは停止させられ、エミュレーション／実行−制御がキャッシュの消去を扱うから）。
【００４３】
・データをダウンロードするとき、“Ｄ”キャッシュは前もってフラッシュ（一気に消去）するか、ライトスルーなら前か後に無効にしなくてはならない（あるいはコアによって変更されない）。ダウンロードに対して、これは通常は問題とならない（概略は上述した）。
【００４４】
・対象が実行中に位置をポーリングする時、その位置は、もしライトバック（write back）キャッシュラインでないならば見えない（従って、その位置は非キャッシュ領域或いはライトスルー領域の中にあるだろう）。もしライトバックが使用されると、その位置は、次のキャッシュフラッシュまで更新されないだろう（アプリケーションビヘイビアあるいは実行制御支援から）。従って、ライトバックでポール（poll）することは依然として可能であるが、（アプリケーションによって使われないせいで、キャッシュがフラッシュされるまでどの位かかるのかによっての）非決定期間の遅延はあるだろう。
【００４５】
・対象が実行中に位置を変更する時、その位置は、キャッシュされるならアプリケーションに影響しないだろう。その変化は、キャッシュが消去されるまで取り上げられないだろう（もし、ライトバックとキャッシュが変化すると、ＤＢＴの変更は失われるだろう）。
【００４６】
ＴＣＭに対して、何らかの形でデュアルポートで無い限り、メモリはＤＢＴから全く見えないだろう。例えば、もしＴＣＭもＡＭＢＡでアルゴリズムか、もし外部ＤＭＡポートを含んでいれば、それはＡＨＢスレーブとしてラップされ、その後ＤＢＴはＴＣＭにアクセスすることができる。代替案は、システムモデルを介して支援することであり、それは、以下の３つの内の１つの方法でアクセスを提供する。
【００４７】
１．ＴＣＭラッパー（wrapper）は、ＤＢＴに利用可能になる外部ポート（例えば、ＤＭＡポート）を含む。これは、ＡＭＢＡバス上で見えるようにするか、ＤＢＴ内部の代わりのメモリコンセプトを用いることで、行うことができる。
【００４８】
２．ＴＣＭは、ＡＲＭと共にＤＢＴに多重化される。これには、調停はないため、ＡＲＭコードが停止した時に使用することができるだけだろう。パス問題を避けるために、そのインターフェイスを登録する必要があるだろう。このモデルは、アクセスを低価格で提供するが、プロセッサが実行中はメモリは、アクセスできないだろう。
【００４９】
３．ＴＣＭは何らかの形態の調停でＤＢＴに多重化される（ＤＢＴがアクセスすることになれば、コアの待ち状態）。これは、上記の２と同じだが、コアが実行中にアクセスができる点は異なる。もしこのモデルの価格がＤＢＴ使用に対して正当化されるかどうかは明らかでない。
【００５０】
ＣＢＴ支援が無ければ、ＴＣＭは、コアを止めて、そのＪＴＡＧ機構を通してアクセスすることによってのみ、アクセスできる。
【００５１】
〈ＭＭＵ／ＭＰＵと仮想アドレス〉
ＤＢＴ部品は、物理アドレス（バスアドレス）のみを見る。デバッガは、仮想アドレスと物理アドレスの間の必要なマッピングを行う責任がある。保護とキャッシュ制御のためにＭＭＵ／ＭＰＵを使用するアプリケーションにとって、これは問題ではない（コア内のアドレスＸは、どれもバス上のアドレスＸでもある）。ＭＭＵを使って、仮想アドレスが物理アドレスに合致しない状況を作るアプリケーションにとって、以下の４つの状況がある。
【００５２】
１）位置を動的に再マッピングする（マッピングが実行中に変化するという意味である）。仮想位置は、“処理”のために別の物理的位置にマップされる。これは、処理モデルＯＳによって、処理（別名、タスク）間の接触を避けるために使用される。この場合、デバッガは、通常これをＯＳ自身からか、ページテーブルから見付けることができる。しかし、マッピングは、いずれ変化するかも知れず、従って、これらの位置をコアが実行を許されている間にアクセスするのは危険である。
【００５３】
２）静的な／一度のみのマッピングをする（マッピングがブート時間に設定され、そのまま置かれることを意味する）。仮想位置は、周辺装置や他のバスオブジェクトを“普通の”場所にマップする。これは、ページテーブル検査によってのみ決定できる。これは、あまり普通ではないが、デバッガは、これらのテーブルを読むことで支援しなくてはならないだろう。ＡＲＭコアによっては、コアが実行中（スキャンチェインでＣＰ１５を読む）にページテーブルがどこにあるかを決定することができるだろう。もし、ページテーブルがバス上で見られるならば（ＴＣＭの説明を参照）、ＤＢＴによってデバッガは、ページテーブルを読んでマッピングを決定することができる。オブジェクトファイルが、このマッピングに関する情報を備えていることもありうる。
【００５４】
３）ページ不良領域が作られる。これらは、様々な目的に対して使われ、その中には、読み出し時の複写、疎行列、マップ済みファイル（或いは等化物）、フラッシュからのコードのロードの要求等々が含まれる。これらの考えは、何が望まれ何が必要かによって、全て変わる。デバッガは、メモリの扱いの事情を理解して、適切な動作かを知る必要がある（デバッガからページ不良を起こすことは、しばしば不適切である）。ある場合には、デバッガは、データがどこから来たか（例えばフラッシュ）を知っており、従って、ＤＢＴはデータに直接にアクセスするのに使用することができる。一般的に、この種のメモリは、コアが停止した時にのみ扱うことができる。
【００５５】
４）より広いアドレスを作る。この方法の最も普通の使用法（ＡＳＩＤあるいはドメインあるいは他の拡張モデル）は、仮想アドレスと物理アドレスが異なる必要は無いが、この機構は、スワップインブロック及びその同等物を作るのに使用することができる。繰り返すと、デバッガは、これらのマップすることのできる規則を知る必要がある。
【００５６】
２の場合のみが、コアを基にしたアクセスモデル（ＪＴＡＧあるいはモニター）に取って問題では無いことに注目すべきである。残りの問題は存続しており、どのようなアクセス方法が使用されていてもデバッガが取り組まなくてはならない。
【００５７】
さらに、現在、殆どの設計が、システムレベルでの再マッピング（チップイネーブルとチップセレクタ及び等々）を使用することは注目に値する。新しいＡＲＭコアは、ＭＭＵの特徴をより直接的に支援するので、さらなる設計がこの効果に対してコアに頼る可能性がある。従って、デバッガがこれらの問題に取り組まなくてはならず、コアは、停止すること無く可能な情報にアクセスをする必要があり得る。
【００５８】
〈アクセス〉
ＤＢＴは、ＪＴＡＧ或いは等化物内の一組のＩＲ／ＤＲ処理を用いてアクセスされる。
ＩＲは、異なる全ての使用法から選択するのに使用される。
・様々なＪＴＡＧ：ＢＹＰＡＳＳ（０ｘＦ），ＩＤＣＯＤＥ（０ｘ０Ａ），対策に必要なＪＴＡＧ（それらに対して無視されるだろう）
・ＴＡＰがローカルセグメント（０ｘ１１）上にある時のローカルメモリアクセス
・使用されるバス接続の種類に係わらず、通常のバス視認性に対するグローバルメモリアクセス（０ｘ０２）
・ＡＲＭコア内の古いスキャンモデルへのアクセスのためのスキャン（０ｘ３と０ｘ４）。これは、ＡｒｇｏｎとＶ６の種類のコアに対して取って置かれる。Ａｒｇｏｎのようなモデルを提供するＡＲＭ７／９／１０／１１上のラッパーとして使用することができる。ＳＷＪをもっと速くするために、古いコアでの共通のアクセスをラップするのにも使用することができる。これを境界のスキャン試験（デバッグ関連ではない）に使用することも可能である。
【００５９】
全てのメモリ動作は、１つのＩＲ（グローバルかローカル）を用いてアクセスされ、従って全ての動作はＤＲを基にしている。モデルは、ＤＲまで４種の要求に分けられるはずである；制御と、アドレスと、読み出しと、書き込みである。全体のＤＲは、常に３４ビットである。
【００６０】
ＤＲ動作は、一度に読み出しと書き込みができるように動作する。CaptureDRサンプルされたデータは、通常、前の動作の結果である。UpdateDRで書かれたデータは、４つの要求の種類の１つを扱う。
【００６１】
〈モジュール方式〉
ＤＢＴ部品は、いくつかの部分に分けられるが、それらの殆どは選択性のものである。図１は、この考えを示したものである。命令ブロックのみが実際に必要である。選択的なブロックは、如何に使われるかによって決定される。
・もし他の手段を用いてアクセスするなら、ＴＡＰは必要ない。例えば、ＳＷＪと組み合わせると、ＳＷＪ部品がＤＢＴを駆動するように導かれるので、ＴＡＰのいずれも必要ではない。
【００６２】
・既存のＡＲＭ  EmbeddedICE論理回路（事前Ａｒｇｏｎコア内のデバッグモニターを実施するために提案するモデル）、あるいは試験スキャンチェインをラップする時にのみ、スキャンチェインＴＡＰレジスタが必要である。
・様々なバスの調整は必要な時にのみ使用される。マルチマスター（完全なＡＭＢＡ）は、マルチマスターシステムで使用される。簡単なＡＭＢＡ  Ｌｉｔｅは、調停器を持ったＭＣＵの中で使用される。ＡＭＢＡ  Ｌｉｔｅと簡単な調停器は、調停器無しのＭＣＵの中で使用することができる（簡単なバス信号を待ち状態と多重化してＡＲＭアクセスを調停／持続させる）。
【００６３】
・特別な特徴を含めることも含めないこともできる。この中には：フラッシュプログラミング、Attention信号の出力、ＡＣＫ信号入力、広いバス（wide bus）アクセス、二者択一バスアクセス（ローカル対システム）等が含まれる。ホストは、インターフェイスから直接に存在する便宜には何があるかを分かっている（ＩＤＣＯＤＥや制御レジスタや他の選択的なサイドレジスタを通して）。いくつかの特徴は、それらをイネーブルして、イネーブルすることで読み返すかどうかを知ることで、検出する；他のものはＩＤＣＯＤＥ部品番号の中でマークされる。
【００６４】
あまりにもモジュラー性を持ちすぎないように十分注意をしたという点に気付くことが重要である。すなわち、複雑さ（組み合わせの可能性が多すぎること）とオーバーヘッド（互いに違う部品を埋め込む）ことに関するモジュール性への代償がある。一般的な方法は、モジュール性はＤＢＴの中で、以下の５種類に分かれる。
・自然ブロック。ＤＢＴは、図１に示すように３レベルのブロックに分かれる。従って、最上位のブロック（ＴＡＰ）をＳＷＪに対して除いたり、そのバスラッパーを選択したりすることは、自然に適合する。
【００６５】
・コアの種類とバスの種類とに基づく。例えば、６４ビットを支援することで、６４ビットデータを支援するコア／バスを持つことによってのみ可能となる。
・フラッシュのようなシステム特有の細部に基づく。選択的なフラッシュブロックは、もしシステムにフラッシュがあり、モデルと互換性がある場合にのみ含まれるだろう。
【００６６】
・経路の選択に基づく。もしAttentionあるいはＡＣＫ信号が経路選択されないと、それらは中止される。これらのものは、互換性に対して勧められる。しかし、その内のいくつかは意味がない。例えば、ローカルデバッグセグメントは、特定の設計にのみ適している。
・安全性やＪＴＡＧ試験スキャンチェインのような、システム拡張／問題による。これらの拡張によって、ＤＢＴはより広い目的に使うことができる。
【００６７】
〈ＩＤＣＯＤＥ  ＪＴＡＧスキャン〉
ＩＤＣＯＤＥの中には、ＡＲＭ製造者ＩＤコードと、ＤＢＴ用の特別な部品番号と、改訂の情報が含まれる。
【００６８】
部品番号は、基本の形態情報として“ｘｘ”部を持ったＤＢＴ用の（多分３ｘｘ）独自の接頭辞に分けられる。形態情報によって、ＤＢＴ全体の性能の素早い分析が可能になる（ローカル対グローバルメモリアクセス、フラッシュ支援、試験スキャンチェイン支援、安全性等）。
【００６９】
〈メモリアクセス命令インターフェイス〉
ＤＲは３４ビットである。それらのビットは、最後の２ビットがＴＤＩ（ホストから対象へ）を通って入る時には種類であり、ＴＤＯを通って出る時には状態であるようにパックされる。従って、ＴＤＩ−＞３２ビットデータ−＞２ビット制御／状態−＞ＴＤＯとなる。
送出フォーマットは：
［種類として１：０］［値として３１：０］
応答フォーマットは：
［状態として１：０］［戻りデータとして３１：０］
【００７０】
応答は１つの処理によってスキューされることに注意したい（従って、種類／値からUpdateDRを通して送られる応答は、次のCaptureDRの中で答えがあるだろう）。さらに、シフトの無いCapture->UpdateDRは、書き込みモードにおいて特殊な場合であり、それによって充填（自動インクリメントの時）、あるいは再書き込み（自動インクリメントで無いとき）が可能となる。
【００７１】
種類は、次の中の１つである：
【表２】
2006514375.tif 000004
状態は、２つのビットからなる：
・ビット０（ＬＳＢ）は、完了。
・ビット１（ＭＳＢ）は、誤り。
【００７２】
状態の組み合わせは、（ビット１，ビット０）である。
【表３】
2006514375.tif 000005
【００７３】
〈制御要求〉
［００ｂ］［制御語］
制御語は、ＬＳＢからＭＳＢへの以下のビットから成る。
＞ビット０：データの読み出し或いは書き込み時の、自動インクリメントアドレス。現在の処理が完了した時のみインクリメント。これは、誤りがあって停止したり、新しい要求が余りにも早く（完了する前に）来たりすると、インクリメントしないことを意味する。注意：下位の１２ビットのみがインクリメントする。従って、ａ２＾１２ページ以内でインクリメントする。
【００７４】
＞ビット１−３：以下のような動作の大きさ：
０＝８ビット
１＝１６ビット
２＝３２ビット
３＝６４ビット（データバスが対応する時のみ）
Ｎ＝４−７予備用
【００７５】
＞ビット４−７：以下のようなフラッシュ制御：
０＝フラッシュ無し−通常のＡＨＢ動作
１＝フラッシュ書き込みイネーブル。これは、全ての書き込みが、必要に応じて、値の前／後にフラッシュ制御動作を送出することを意味している。このビットは、フラッシュ支援が利用可能でなければ、設定したままにはならない。
【００７６】
２＝フラッシュ無し、強制検証。これは、後に続く全ての書き込みが、実際の書き込みを実行しないが、バス上の現在の位置を読んで、結果を過去の値と比較することを意味している。もし比較して一致すれば、‘書き込み’は成功したと扱われる。もし比較が失敗すれば、状態は誤りを示す。
３＝読み返しイネーブルのフラッシュ書き込み。これは、書き込みの後に、データは読み返されて設定の正しさが確認されることを意味している。フラッシュ書き込みが確実な動作であるための規則が完了したかに注意する。
４＝４−１５予備用。
【００７７】
＞ビット８−１１：動作無効のための予備。これは、後で、“代わりの”メモリとバスにアクセスすることができるようになるだろう。０が通常のバス動作用である。
＞ビット１２：Attention信号。有効な時は、これによって、ＡＲＭコアに送られる割り込みが起きる。これによって、メールボックス型の信号伝達が可能になる（ＡＣＫも参照）。これは自己消去型の信号である。従って、Assertを書き込むことで、ＡＲＭの信号伝達をし、その後に消去される。Attention／ＡＣＫ拡張モードが、どの信号を駆動するかを変更するのに使用することができる（システムが多数のAttention信号を提供する時に）。
【００７８】
＞ビット１３：ＡＣＫ戻り信号。有効な時は、これによってＡＲＭコアが、メールボックス処理（送られたパケット）に応答したか受けたと信号を送ることができる。これは、自己消去型の信号である。従って、一度だけ読み出しアサートされ、その後に次のAssertまで読み出しデアサートされるだろう。Attention/ＡＣＫ拡張モードが、どの信号が標本抽出されるかの変更をするのに使用することができる（システムが多数のＡＣＫ信号を提供する時に）。
【００７９】
＞ビット３０：膠着（sticky）状態。もし誤りあるいは未完了が発生すると、次の要求は、Controlが再び読み出されるまで無視される。すなわち、もしデータの読み出し／書き込みの要求があり、その要求がバス上で待っている間に、それが失敗するか、他の要求があると、その要求及びその後の全ての要求は、制御要求が割り込むまで無視される。これによって、ホストは確実に何が起こったかを知ることができる。このビットが設定されると、全ての無視された命令に戻ってくる状態も失敗を示す。設定されると、システムは消去を実行しない。
【００８０】
＞ビット３１：実行（commit）制御変更。このフラグは、制御設定に書き込まれる制御語に対して設定されなくてはならない。もし設定されないと、制御語は無視される（これによって、読み出しのみが可能になり（膠着状態を抜けることを含む）、単純なＮＯＰを生み出す）。
【００８１】
応答（次のスキャンの結果）は、現在ラッチされる制御設定である。これは、膠着状態を調べるのに使用することができ（実行するか否か）、動作が許可されるかどうかを決定するのに使用することができる：例えば、もし大きさが６４に（大きさは、３）設定され、しかし、３２（２）のように読み返すなら、６４ビット動作はこのＴＡＰによって支援されていない。同様に、フラッシュ動作と動作は無効になる。
【００８２】
〈アドレス〉
［０１ｂ］［アドレス］
アドレスはバスアドレス（物理）であり、動作無効は、通常のバス動作に対する時である（詳細な説明を参照）。
書き込まれるアドレスは、将来のデータの読み出しと書き込み動作に対して保存される。自動インクリメントモードは、このアドレスが、後に続く読み出し／書き込み動作のうち成功した全てをインクリメントする（データの大きさによって）ことを意味することに注意したい。
応答（次のスキャンの結果）は、この要求に書かれたアドレスと同じである。
【００８３】
〈データ書き込み〉
［１０ｂ］［書き込む値］
この動作は、８，１６，３２あるいは、記憶されたアドレスセット内の現在のアドレスの中に渡された値（Value）から６４ビット値の最初の半分／後の半分を書き込む（アドレス要求を参照）。アドレスは、もし成功すれば、その後、１あるいは２あるいは４あるいは８だけ（インクリメントできるビット数の範囲内で）インクリメントする。
応答（次のスキャンの結果）は、もし書き込みが誤りによって失敗したか、成功したかを示す。
【００８４】
〈データ読み出し〉
［１１ｂ］［無視された値］
外へ向かう値は、無効になる動作が通常のバス動作に対して設定される時には、無視される（アドレスによって指定されたスキャンチェインに対してレジスタを指定するスキャン動作に使うことができる）。
この動作は、８，１６，３２あるいは、記憶されたアドレスセット内の現在のアドレスからの６４ビット値の最初の半分／後の半分を読み出す（アドレス要求を参照）。アドレスは、もし成功すれば、その後、１あるいは２あるいは４あるいは８だけ（インクリメントできるビット数の範囲内で）インクリメントする。
応答（次のスキャンの結果）は、状態がＯＫならば、値の読み込みであり、そうでなく、もし誤りならば誤り情報であろう。（注意：ＡＭＢＡ制御器は、もし誤りビットが設定されると、ReadDATAバス上で誤りコードを戻すことが課せられている。）
【００８５】
〈例〉
これらの例は、このインターフェイスを如何に使用しようとしているかを示している。殆どのエミュレータにとって、スキャンをバッファの中に作って、それらをすぐに実行させるのが、より実際的であることに注意したい。これは、多数の単独動作とダウンロードに発展する。戻りデータは、最後に、全てが成功したかどうかを否かを決定するために調べることができる。
【００８６】
〈単一の値を書き込む〉
以下は、単一の値が書き込まれる様子を示している。CotrolとAddressへの書き込みは、もし既に正しい値を備えていれば必要ないことに注意したい。
ScanOut(Control,SIZE(2)|COMMIT)  --大きさを３２ビットに設定する
ScanOut(Address,addr)            --アドレスを書き込みに設定する
ScanOut(DataWrite,value)         --値を書き込みに設定する
ScanIO(Control,0,&results)       --確実に動作した結果を得る
If(!results[status])
Succeeded
Else
Failed
【００８７】
〈単一の値を読み出す〉
以下は、単一の値が読み出される様子を示している。CotrolとAddressからの読み出しは、もし既に正しい値を備えていれば必要ないことに注意したい。
ScanOut(Control,SIZE(2)|COMMIT)  --大きさを３２ビットに設定する
ScanOut(Address,addr)            --アドレスを読み出しに設定する
ScanOut(DataRead,value)          --値を読み出しに設定する
ScanIO(Control,0,&results)       --結果を得る
If(!results[status])
Data_read=results[value]
Else
Failed
【００８８】
〈多数の値を書き込む（ダウンロードする）〉
以下は、単一の値が書き込まれる様子を示している。CotrolとAddressへの書き込みは、もし既に正しい値を備えていれば必要ないことに注意したい。このアルゴリズムは、４Ｋの制限（バイトアドレスの制約）を越えてラッピングする場合を扱うことに注意したい。すなわち、自動インクリメントの特徴は、下から１２ビットでのみ動作する。従って、アドレスが４Ｋに合わせた位置を超えると、再書き込みしなくてはならない。我々は、やってくるアドレスが４Ｋの境界に合わせられているかを知らないので、単に、次の境界へ変わるときに書き込む。また、膠着（sticky）ビットを用いて、各ブロックの終わりで集まった誤りを調べることに注意したい。もし誤りが検出されると、ループは、より遅いスキャン（例えば、RunTestIdleで、スピンを増やす）を用いて再度試すことができる。
【００８９】
ScanOut(Control,AUTO_INC|SIZE(2)|COMMIT)    --大きさ＝３２，インクリメント
ScanOut(Address,addr)                       --開始アドレスを書き込みに設定する
for(index=0;index<length;index++)
{
ScanOut(DataWrite, value[index])          --次の値を書き込みに設定する
addr+=4;
If(!(addr& 0xFFF))                        --注意：addr incは１２ビット
Only
{                                         --次のページにラップする
ScanOut(DataWrite,value[index])         --確実に動作した結果を得る
ScanIO(Address, addr, &results)         --次の合わせたアドレスを設定する
If(results[data]&STICKY_STATUS)         --制御要求からの要求
Failed                                --集まった誤り
）
（
【００９０】
〈多数の値をフラッシュに書き込む〉
フラッシュに書き込むことは、通常のメモリ動作と基本的に同じであるが、以下の点が異なる。
Bit４（フラッシュプログラミング）が設定されると、フラッシュプログラミング命令もデータと共にバスインターフェイスへ発せられる。フラッシュプログラミングは、ＳＲＡＭよりもずっと長い時間がかかり、一旦、命令がＲＴＩ遅延（UpdateDRとCaptureDRの間）で受け取られると、プログラムされた次の語が時間の節約のために待ち行列に入り、PauseDR内で調整された遅延が続く。すなわち、ある書き込みの後に他の書き込みが続き、そしてFlash書き込み（そして選択によっては読み戻し）が完了するのに十分なスピンが続く。その後、状態は通常その書き込みを開始するUpdateDRを通して進められる。再び、さらに待ち行列と入ることもある。これら１ブロック後に、動作が成功裏に完了したかを見るために、呼出側は膠着状態を調べるはずである。
【００９１】
〈様々な結果〉
ＲＶＩ−ＭＥ付き積分器（Integrator）／ＡＰと（４−８ＭＨｚ  ＴＣＫ）
ダウンロード  ５００ｋＢ／秒（ＲＡＭ）
フラッシュプログラム  １８０ｋＢ／秒（ｘ１６において２チップで３２ビットを形成）
メモリ充填  ３７００ｋＢ／秒
【００９２】
〈設計手法〉
ＤＢＴは、例えば、例えば問題と解決において、上で概説したようなモデルを中心に作られた。より詳細には、この項で、なぜ別の部品が構成されたかを説明する。
【００９３】
〈全体の設計〉
ＤＢＴの全体の設計は、チップのメモリ／周辺装置システムへ高速かつ簡単にアクセスすることのできる機構を提供することである。これは、大きさ或いはＩＲとＤＲのスキャンチェインと使われ方の全てが、デバッガと試験ツールによる典型的な使用、つまりダウンロードや位置の抽出や実行中のシステム内のホットパッチやモニター或いはエージェントとの通信やフラッシュプログラミングやメモリ検証などに対する性能を最適化するように設計されたことを意味している。
【００９４】
ＤＢＴは、他の種類のデバッグ使用法を直接に網羅するように設計されていない。すなわち、簡便なＡＨＢ／ＡＨＢ−Ｌｉｔｅメモリアクセス部品なのである。他の種類のデバッグは、システムバス或いは個別デバッグバス（セグメント）であれ、バスモデルを用いて自身を公開するならば、ＤＢＴを用いて容易になり得る。この限定された使用法のモデルは、ＤＢＴが、広範囲の装置で使用できることを目指している。さらに、これは、他のメモリアクセス可能な部品が追加されたので、ＤＢＴが利用可能で無い時、あるいはＤＢＴを使う時に、従来のＪＴＡＧを通してアクセスすることができることを意味している。これは、最も無害の相互接続性を保証する役に立つ。バスモデル（システム或いはローカル）を用いて“結合”される装置の例は、ＥＴＭ（トレース）、ＥＴＢ（トレースバッファ）、デバッグモニター、ＳＯＣ内のＡＳＩＣ，（情報収集）、ＣＴＩ／ＣＴＭ（相互トリガー）、ＦＰＢ（フラッシュパッチと切断点）である。
【００９５】
ＤＢＴ設計は、ＪＴＡＧエミュレータがデータ受信よりデータ送信が良好になりやすいという考えに基づいていることに注意したい（ＳＷＪ（単線ＪＴＡＧ）は、使用されるエミュレータにかかわらず、この極端な例である）。両方とも、通信モデルのせいであり、後処理の成果に必要な情報のせいである。検証と誤りの集合は、この良い例である。これは、非常に強力なエミュレータ（ＡＲＭ  ＲＶＩなどの）ならば、双方向の手段とローカル分析を使用することを選ばないということではなく、それらのエミュレータでさえ、殆どの処理を実行するのに必要なＴＣＫの数を減らすという理由で、近接して結合された解決から得るものがあるということである。
【００９６】
〈バスインターフェイス〉
バスインターフェイスモデルは、異なるシステム設計を提供するようなモジュール製品であるように設計された。ＡＨＢ−Ｌｉｔｅが望むものである場合に、フルＡＨＢマルチマスターモデルを使用するのにマイクロコントローラを考えるのは不適当である。同様に、単一のセグメントを仮定して、システム設計者にマスタリングブリッジ（mastering bridge）を作るように期待するのは不適当である。
【００９７】
ローカル対グローバルのモデル（２種のバス調整を即座にできる）は、明らかに異なるアクセスモデルを持つ必要があるシステム設計を提供するように設計された。これが必要な主なものは、デバッグモニターローカルメモリ対システムメモリである。デバッグモニターメモリを特別なセグメント（その上、この中にはデバッグメモリのマップされたレジスタが含まれよう）として定義することで、ローカルアクセスをする際には、バスマスタリングおよび／または調停は、必要ない；これによって、全体のシステムは、デバッグ動作中の割り込みが少ない状態で実行できる。さらに、ローカルバスモデルは、バス上の他の部品がデータにエラーを起こしたり改悪したりしないように保証する。最後にローカルセグメントによって、スヌーピング（snooping）の選択をすることなく、安全な情報管理ができる。
【００９８】
〈フラッシュ〉
フラッシュモデルは、殆どのフラッシュ部品は、値の前の書き込みと値と選択的にその後のいくつかの書き込みの一組を用いて、プログラムすることができるという考えに基づいていた。最良の速度を得るのに、多くのフラッシュ装置は、いつ行われたかを決定するための状態検査ができる。ＤＢＴモデルはこれを通常行わない。代わりに、ＪＴＡＧインターフェイスに、通常のフラッシュ書き込みを提供するのに十分な時間を使い果たさせることで、動作する。事後書き込み検証は、いずれかのセルが正しく書かれなかったかどうかを検出する。この方法は、使用するアプリケーションに対しては適切ではないが、ホストされたモデルにとって最善の速度の安全な方法（とゲート費用）を提供する。最悪のシナリオは、単に、超過した時に、フラッシュを再書き込みしなくてはならないというものである。
【００９９】
フラッシュが即座に検証されなくてはならない場合、選択の、検証付きフラッシュ書き込み法を使用することができる。これによって、ＪＴＡＧエミュレータは、バイトかワードを書き込んだ後にすぐに失敗の検査をすることができ、それでいて、マルチワード書き込みをブロック転送にバッチ処理することを利用することができる。
【０１００】
〈強制検証〉
検証モデルは、非直感的な“強制”モデルに基づいている。これは、書き込みが送られるが、書き込みとして実行されないことを意味している。代わりに、位置が読み出され（バスから）、強制的な値に対して比較される。この結果は、２ビットで返ってきて（誤り／状態）、同様に集められた誤りモデルと共に動作する。送信モデルがより好まれることから、これが行われる。代わりのものは、読み出し中に送信し、ホスト上で比較される結果を送り返すものである。多くの動作が続く強制比較が続くブロック書き込みを行うことで、ホストは、全体の性能が最良になるような最大数の動作を１回にまとめて処理できる。もし検証が失敗すると、残りの処理は、無視されるが、これは適切である（誤りの処置に対して）。これによって、ホストと対象との間の往復が避けられる。
【０１０１】
強制検証は、フラッシュ検証と、ＳＲＡＭダウンロード検証と、一般的な書き込み検証と、値の変更抽出に使用することができる。後者は、ホストが、変更する位置（或いは組になった位置）を見ていて、変化した時に、おおよその時刻を得るものである。期待値は、下げられて、動作は何回も繰り返される。状態ビット（２）をしばしば見ることで、ホストは、値の変化するときを決定することができる（検証して、強制された値と異なる時に、誤りを返す）。
【０１０２】
〈AttentionとＡＣＫ〉
AttentionとＡＣＫモデルは、メールボックスモデルを使用する者にとって分かり易い。それは対象によるポーリングを回避し、ＤＢＴ装置によるバスポーリングを回避する（煩わしいものである）。AttentionとＡＣＫ拡張モデルによって、多数のAttention及び／またはＡＣＫの信号（異なるコアへというような）を持つＤＢＴ部品を考慮するが、簡単な場合の速度を下げない。即ち、拡張モデルは、どのAttention信号を（１つあるいは２つ以上）駆動し、どのＡＣＫ信号を（１つあるいは２つ以上）抽出するかを選択する別々の制御要求を用いることができ、Controlを用いて現在の設定を駆動する通常のモデルを使用することができる。これは、AttentionとＡＣＫは、より高速の直列モードで、選択した設定を変更する時に必要な特別なスキャンとのみ共に使用することができることを意味している。
【０１０３】
図６は、ScanTAPからMemTAPへ（メモリアクセスに近いやり方でスキャンを支援する方法）の関係と、いかに両者がＤＢＴの中に適合するかを示しており、同様に、実行モデル／構造モデルを示している。ScanTAPに対して提示したモデルは、４つのタスクを遂行するよう設計される。
・クロック領域の境界ですっきりと分離すること。これによって、可能な限り最小の登録されたインターフェイスが提供され、クロック領域間のハンドシェークが管理され、特に、スキャンニングにおける伝搬のオーバーヘッドが扱われる。
【０１０４】
・多くのスキャンチェインを扱うことができるような、簡単なＭＵＸモデル。
・スキャンチェインを扱うための簡易な実施−それらは、もし、ScanTAPインターフェイスを使用することを望まなければ、ScanTAPインターフェイスを支援する簡単なVerilogでラップすることができる（ブリッジ支援とクロッキング）。
・大きなスキャンチェインでの挿入／抽出に対して最適化すること。
【０１０５】
ScanTAP法は、４つの異なったブロックを作り、それらの１つだけが、システム設計者が実行しなくてはならないものである（恐らく既に持っている）。これらのブロックは、図７に示されている。
【０１０６】
１．プロトコルブロック。このブロックは、MemTAP下位部品と同じ基本プロトコルを使用する。ＴＡＰブロックか（直接的なＪＴＡＧ）、ＳＷＪ用のオンチップの実行制御ブロックを通してアクセスすることができる。簡単な３４ビットレジスタモデルを管理するが、それは、４つの３２ビットレジスタへのアクセスを提供する。４つのレジスタは、MemTAPの４つのレジスタと一致するが、少し異なる使用法のために使われる：
【０１０７】
・制御：セレクタ（スキャンチェイン用）と要求とデータカウンタ。状態を返す（もし動作が完了すれば）。要求の示すものは：事前のみと、事後のみと、データ挿入のみと、データ抽出のみと、事前そしてデータ挿入そして事後と、事前そしてデータ抽出そして事後。
【０１０８】
・アドレス：事前カウンタと事後カウンタ（それぞれ１６ビット）。制御によってイネーブルされると、これらは、挿入と抽出で望まれるものへ届くのにスキャンセルを飛ばす。
・特別：未使用。現在のスキャンチェインの大きさを読み返すのに使用できる。
・データ：データ値を挿入し抽出する。これらは、スキャンチェインの現在の位置内にデータを設定／取得するのに使用される。使用当たり１−３２ビットの動作を支援する。このレジスタへ繰り返しアクセスすることで、各回制御の中で与えられる大きさに対して、現在要求されている動作を実行する。従って、３２ビットの動作４つのそれぞれが、１２８ビットのスキャンを処理するのに使用することができる。わずか２ビットのオーバーヘッドしかないので、この機構を使用する費用は低いことを意味している。
【０１０９】
２．ShiftIFブロック。このブロックはクロック領域境界の反対側にある。これによって、スキャンセルが、プロトコルブロックの中への要求が行うよりもずっと速いクロック速度で動作することができる。このブロックは、｛モード｝と、｛計数｝＋｛データ｝（２０ビットレジスタ）とＭＵＸ｛選択｝とを管理する。同じ３つのレジスタが、全てのモードで使用される。ShiftIF｛モード｝は、どの動作を取るべきかを示す：セレクタを設定することと、計数を設定してその後排出することと（事前或いは事後の前に）、データ＋計数を設定してから挿入のために排出することと、計数を設定してその後データレジスタ内へ抽出するために排出すること。ShiftIFへのインターフェイスは、ハンドシェイクを用いて、完了したのを確認する。｛セレクタ｝と｛計数｝＋｛データ｝は、登録されたインターフェイスであり、これは、モードを要求（作用）しなければ、書き込んだり読み出したりすることができる。挿入は、次の様である：｛データ｝＋｛計数｝（作用）（２０ビット）を書き込み、その後｛モード｝を書き込み、その後ハンドシェイクを待つ。抽出は、次の様である：｛計数｝を書き込み（上位４ビット）、｛モード｝を書き込み、ハンドシェイクを待ち、｛データ｝を読み出す（16ビット）。
【０１１０】
３．セレクタＭＵＸ。ShiftIFは、ＭＵＸに、現在選択しているスキャンを切り替えるように要求する。これは、｛セレクタ｝レジスタが書き込まれて、｛モード｝がセレクタ設定に設定された時に、行われる。ＭＵＸは、もし受け取られれば、ハンドシェイクと示そうとするＡＣＫ／Error信号を用いる。（読み返しで）受け取られたかどうかをプロトコルブロックが検出できるように、誤り応答は、ShiftIFブロック内の｛セレクタ｝レジスタの内容を消去するだろう。これによって、エミュレーションＳＷは、スキャンチェインがその特定の装置に対して存在するかどうかを決定することができる。
【０１１１】
４．直列シフタ。SoC/ASIC供給元は、直列シフタを提供する。直列シフタは、５つの信号インターフェイスを使用するか、あるいは提供されたラッパーを使用する。５つの信号インターフェイスは、３つの入力からできている：“クロック”（早期の）と、“ブリッジ”要求と、ＳＩ（Shift-in：シフト入力）である。５つの信号インターフェイスは、２つの出力も備えている：ハンドシェイク（ＡＣＫ）と、ＳＯ（Shift-out：シフト出力）である。クロックは、各早期要求（どのような様式でも）時にパルス出力され、直列シフタは、シフトが完了するとハンドシェイク信号を駆動する（信号は全スキャンチェインを通って伝搬する）。ＳＯ信号がＳＩ入力にゲートされるはずの時に、ブリッジ信号は、アサートされて保持される。これによって、スキャンは、前進し、同じ内容を保つ（もし全てのビットがシフトして回れば）。
【０１１２】
４．ShiftIFブロックは、ブリッジ信号を保持し、｛計数｝回だけ（プロトコルブロックによってロードされる）パルス出力することによって、事前と事後のスキップを実行する。ハンドシェイクは、可能な速度を決定する。ShiftIFブロックは、終わるまで、プロトコルブロックへ戻る自らのハンドシェイクをアサートしないので、行き過ぎることは無い。ShiftIFブロックは、ブリッジ信号を保持してクロックを｛計数｝回だけパルス出力することで、データ“抽出”動作を実行する。各ＳＯは、｛データ｝レジスタの中へシフトされる。プロトコルブロックは、その後、ハンドシェイクがアサートされると、データを読み出す。ShiftIFブロックは、ブリッジ信号を保持せずクロックを｛計数｝回だけパルス出力しないことによって、データ“挿入”動作を実行する。各ＳＩは、その後シフトされる｛データ｝レジスタの下のビットを使って駆動される。プロトコルブロックは、前もってロードされた｛データ｝（および｛計数｝）を持っているだろう。
【図面の簡単な説明】
【０１１３】
【図１】外部診断機器に接続された搭載型診断システムを含む集積回路の図である。
【図２】集積回路上で診断動作を実行するためにバストランザクションを発するための診断バスマスター回路を組み込む集積回路の図である。
【図３】診断バスマスター回路の態様を示した図である。
【図４】診断バスマスター回路の態様を示した図である。
【図５】診断バスマスター回路の態様を示した図である。
【図６】診断バスマスターと境界チェイン制御の形態を示す図である。
【図７】診断バスマスターと境界チェイン制御の形態を示す図である。
【符号の説明】
【０１１４】
２，５２…集積回路
４…外部診断機器
６，７２…インターフェイス回路
８，７４…診断回路
１０，５４…プロセッサコア
１２，５６…コプロセッサ
１４，６２…メモリ（ＲＡＭ）
１６…ＵＡＲＴ装置
１８…機能バス
５８…フラッシュメモリ
６０…入出力回路
６６…診断バスマスター回路
６８…認証回路
７０…専用診断バス
【図１】
2006514375.tif 000006
【図２】
2006514375.tif 000007
【図３】
2006514375.tif 000008
【図４】
2006514375.tif 000009
【図５】
2006514375.tif 000010
【図６】
2006514375.tif 000011
【図７】
2006514375.tif 000012
【国際調査報告】
2006514375.tif 000013
2006514375.tif 000014