JP2002014837A

JP2002014837A - 信号オーバーレイを許容する時分割多重化機能を備えたスキャン・インタフェース

Info

Publication number: JP2002014837A
Application number: JP2001109235A
Authority: JP
Inventors: Gary L Swoboda; エル、スウォボダゲーリー
Original assignee: Texas Instruments Inc
Current assignee: Texas Instruments Inc
Priority date: 2000-03-02
Filing date: 2001-03-02
Publication date: 2002-01-18
Also published as: JP5328000B2; JP2002049503A; JP5519060B2; JP2001356930A; JP2001356935A; JP2013211046A; JP4551019B2

Abstract

(57)【要約】【課題】高集積実時間オンチップシステムにおいて、
透明性が高く使い易いデバック能力を提供する。【解決手段】通常はスキャン・インタフェースの対応
する信号経路によって運ばれる制御信号（ＴＲＳＴ、Ｔ
ＭＳ、ＴＣＫ）およびデータ信号（ＴＤＩ、ＴＤＯ）を
含むスキャン・インタフェースは、スキャン・インタフ
ェースの信号以外の信号を運ぶためにも使用できる。通
常は信号の一方を運ぶ信号経路上で、第１信号（ＴＭ
Ｓ）と第２信号（ＴＤＯ）を時分割多重化でき、それに
よって他方の信号を運ぶ信号経路がフリーとなってスキ
ャン・インタフェースの信号以外の信号を運ぶことがで
きるようになる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は一般的に電子式デー
タ処理に関するものであって、更に詳細には電子式デー
タ処理を行なうデバイスおよびシステムのエミュレーシ
ョン、シミュレーション、およびテスト機能に関する。

【０００２】

【従来の技術】ウエハ・リソグラフィおよび表面搭載パ
ッケージング技術の進歩に伴って、電子的設計において
益々多くの複雑な機能がシリコンおよびプリント基板の
両方に集積されるようになってきた。設計の高密度化お
よび相互接続ピッチの縮小の結果として、残念ながら物
理的アクセスは減少する。設計時に組み込まれるテスト
機能が必要とされるようになり、それによって、完成品
はテストおよびデバッグ間にも制御および観察すること
が可能となる。製造時に生ずる欠陥は、製品出荷前の最
終的なテストで検出できることが望ましい。設計が複雑
なため、自動試験機器がその製品をテストできるように
論理設計段階でのテスタビリティを考慮することなくし
ては、このような基本的な要請を実現することは困難で
ある。

【０００３】性能および製造時欠陥のテストに加えて、
アプリケーション・ソフトウエアの開発においても、そ
のシステムあるいはサブシステムの設計段階で同様なレ
ベルのシミュレーション、透明性、および制御可能性が
必要とされる。設計のエミュレーション段階では、ＩＣ
（集積回路）あるいはＩＣ群が、ソフトウエア・プログ
ラムとリンクした時に、最終製品の機器またはアプリケ
ーションの中で正しく機能することを確かめることが必
要である。

【０００４】自動車産業、電気通信、防衛システム、お
よび生命維持システムで益々多くのＩＣが使用されるよ
うになり、完璧なテストおよび拡張的な実時間デバッグ
が絶対的に必要とされるようになった。

【０００５】仕様に適合していることを保証するための
テスト・ベクタを設計者が生成する性能試験方式は、今
でも広く採用されているが、非常に大規模のシステムに
対してこの方法は広範囲の欠陥を検出できないことから
不適切なことが分かっている。完全なテストができるた
めには自動的なテスト・パターンの生成が望ましく、テ
ストの全階層（システム・レベルからトランジスタ・レ
ベルまで）をカバーする制御可能性および透明性が重要
な鍵である。

【０００６】大規模設計の別の問題点は長時間と過大な
コストを要することである。再利用を考慮した設計概念
に適したテスト用の回路、システム、および方法が望ま
しい。このように、以下のデバイスおよびシステムは、
初期デバイスに組み込まれたテスタビリティ、シミュレ
ーション、およびエミュレーションの回路、システム、
および方法を再利用することによって、低い設計コスト
でテスタビリティ、シミュレーション、およびエミュレ
ーションを実現する。先行するテスタビリティ、シミュ
レーション、およびエミュレーションの方式がなけれ
ば、テスト・パターンの生成および更新のために大きな
設計時間が費やされることになる。

【０００７】再利用すべきモジュールを設計し、それの
完全なテスト・パターンを生成および更新するために膨
大な投資を行ったとしても、そのモジュールを再び利用
する場合にそれを特定用途論理回路に埋め込んで、それ
へのアクセスを困難または不可能なものとするかもしれ
ない。従って、このような落とし穴は避けることが望ま
しい。

【０００８】ＩＣ設計の進歩には、例えば、内部透明性
および制御の低下、欠陥網羅の縮小、および状態切換能
力の低下、テスト開発および検証問題の増加、設計シミ
ュレーションの複雑化、および連続的に増大するＣＡＤ
（コンピュータ支援設計）ツールのコストが伴う。ボー
ド設計での副産物には、レジスタ透明性および制御の低
下、設計検証でのデバッグおよびシミュレーションの複
雑化、１つのパッケージに多くの回路を実装することに
よって物理的アクセスが失われることによる従来エミュ
レーションのロス、基板上でのルーティングの複雑化、
設計ツールのコスト増、混在モード（mixed-mode）での
実装、および生産容易な設計が含まれる。アプリケーシ
ョン開発での副産物には、状態の透明性低下、高速エミ
ュレーション困難、スケーリングされた時間シミュレー
ション、デバッグ複雑化、およびエミュレータのコスト
増が含まれる。製品の副産物には、透明性および制御の
低下、テスト・ベクタおよびモデルの複雑化、テストの
複雑化、混在モードでの実装、７桁（１００万ドルのオ
ーダー）領域にまで連続的に増大する自動試験機器のコ
スト増、および厳しさを増す許容度が含まれる。

【０００９】スキャン方式のエミュレーションおよび複
数処理デバッグを採用したエミュレーション技術は１０
年以上昔に導入された。１９８８年に、設計サイクル時
間からの要求およびエミュレーションに利用できるオン
チップ空間の制約が動機となって従来の回路エミュレー
ションからスキャン方式のエミュレーションへ変化が起
こった。設計サイクル時間の要求は３つの因子によって
発生した。すなわち、オンチップ・メモリなどのより高
度な集積レベル；増大するクロック・レート−エミュレ
ーションをサポートする論理によって引き起こされる電
気的介入；およびより複雑なパッケージングによって生
ずるエミュレータ接続性の問題である。

【００１０】今日、これらの同じ因子が新しい展開を伴
って問題化しており、今日の複雑でより高いクロック・
レートで高密度に集積された設計において必要とされる
システム・デバッグ機能を供給するスキャン方式のエミ
ュレータ機能に対して課題となっている。その結果、シ
ステムはより小型で高速な低コストのものとなる。それ
らは益々高密度化する床面積で高い性能を示すものであ
る。これらの建設的な各システム・トレンドは、逆に高
速なシステム開発にとって重要な要因であるシステム活
動の透明性に悪影響を及ぼす。この効果は“透明性消
滅”と呼ばれる。

【００１１】アプリケーション開発者は関連するすべて
のシステム活動のうちで透明性および制御を優先する。
集積レベルの着実な進歩とクロック・レートの増大は、
利用できる透明性および制御を時間とともに着実に減少
させている。これらの因子は透明性および制御のギャッ
プ、すなわち望ましい透明性および制御と実際に利用で
きるレベルとの差を生ずる。時間とともにこのギャップ
は拡大している。アプリケーション開発ツールの提供業
者はこのギャップの拡大率を最小に留めようとする。開
発ツールのソフトウエアおよび関連するハードウエア・
コンポネントは、より少ないもので、また異なるやり方
でより多くのことを成し遂げなければならない。利用の
利便さへの挑戦はこれらの力によって増幅される。

【００１２】

【発明の解決しようとする課題】今日の高密度集積され
たシステム・オンチップ（ＳＯＣ）技術は透明性および
制御のギャップを劇的に拡大した。ロジック・アナライ
ザや区分化されたプロトタイプ・システムなどの伝統的
なデバッグ・オプションは今日のシステムの集積レベル
や益々増大するクロック・レートに追随できない。

【００１３】集積レベルの増大とともに、数多くのサブ
システム・コンポネントをつなぐシステム・バスがチッ
プ上を移動し、伝統的なロジック・アナライザがこれら
のバスへアクセスできなくなっている。バスの透明性が
限定されるかほとんどない状況で、ロジック・アナライ
ザなどのツールはシステム活動を観察したり、開発中の
システムを制御するために必要なトリガー機構を提供し
たりすることができない。アクセスできないものを制御
するのが困難であるように、この透明性の消失には制御
の消失が伴う。

【００１４】この傾向に挑むために、システム設計者は
それらのバスを露出させ、露出したバスでプロトタイプ
・システムを構築できるようにシステム・コンポネント
を構築しようとしている。この方式もまた、システム・
クロック・レートの更なる増大傾向によって包囲されて
しまった。ＣＰＵクロック・レートが増大するほどに
は、チップとチップとの間のインタフェース速度は増大
できない。開発者は、区分化されたシステムの性能はチ
ップとチップ間の通信速度の遅延を保証するために加え
られるインタフェース待ち状態のために、集積化された
場合よりも劣ることを見出した。この性能劣化は或る時
点で許容できないレベルに達し、区分化プロトタイプ・
システムはもはや実行可能なデバッグ・オプションでは
なくなった。我々は製品デバイスがアプリケーション開
発のためのプラットフォームとして用いられるべき時代
に突入している。

【００１５】増大するＣＰＵクロック・レートはまた、
他の簡便な透明性機構の終了を加速する。ＣＰＵクロッ
ク・レートは最大のＩ／Ｏ状態速度を超えることができ
るため、元々の形で情報を出力している透明性ポートは
もはやＣＰＵに追随できない。オンチップのサブシステ
ムもＣＰＵクロック・レートより遅いクロック・レート
で動作する。この方式はシステム設計を簡略化し電力消
費を減らすために用いられよう。これらの開発はＣＰＵ
活動を明瞭に観察するために、簡便な透明性ポートはも
はや、あてにできないことを意味する。

【００１６】透明性および制御が失われるとともに、ア
プリケーションを開発するために使用される開発ツール
はより非生産的なものとなる。ツールはまた透明性およ
び制御を維持するために要求されるツールの複雑化のせ
いで使い難いものとなっている。システム・オンチップ
によって発生した透明性、制御、および使い易さの問題
は製品開発サイクルを長期化する問題を孕んでいる。

【００１７】集積化の傾向が開発者に困難なデバッグ環
境を提供するとは言っても、一方で、デバッグ問題に対
する新たな方式が出現する期待もある。開発サイクル時
間の問題をもたらす密度およびクロック・レートの増大
はまた、その問題を解決する機会を生むことにもなっ
た。

【００１８】オンチップのデバッグ機能は従来に増して
入手し易いものとなっている。高速、高性能のチップが
益々大規模メモリ構造によって支配されるようになる
と、ＣＰＵおよびメモリ・サブシステムに付随するラン
ダム・ロジックのシステム・コストは全システム・コス
トのパーセントで下降する。数千ゲートのコストはこれ
までで最も低く、或る場合には今日のチップ設計の中で
は無視されよう。今日の高密度パッケージにおけるピン
当りコストもまた下降しており、デバッグ用に多くのピ
ンを割り当てることがより容易になっている。ゲートお
よびピンの入手が容易になることで、システム・オンチ
ップによって発生した課題に対処するために必要な新し
いオンチップのエミュレーション機能の展開が可能とな
る。

【００１９】製品デバイスがアプリケーションをデバッ
グするためのプラットフォームとしても使用されるとき
には、それらは製品を市場に出す時間をサポートするの
に十分なデバッグ能力を提供する必要がある。デバッグ
への要求はアプリケーション毎に変化するので、市場化
までの時間と必要なコストとの間でバランスを取るよう
にオンチップ・デバッグ機能を調節できることが非常に
望ましい。

【００２０】これらのオンチップ機能はチップの循環コ
ストに影響するので、どの方法でもスケーリングできる
ことが最も重要である。オンチップ・ツールの展開にお
ける指導原理は“必要なものだけに金を使え”である。
この新しいパラダイムで、システム設計者はオンチップ
・デバッグ機能について、残りの機能と一緒に、チップ
・コスト制約と製品開発チームのデバッグ要請とのバラ
ンスを取りながら仕様を定めよう。

【００２１】

【課題を解決するための手段】本発明のエミュレーショ
ン技術は上に述べたデバッグの前向きの機会を利用し
て、開発者に対して制御および透明性のギャップを狭め
ることを狙ったデバッグ能力の蓄積を提供する。

【００２２】本エミュレーション技術は今日の高度に集
積された埋め込み式の実時間システムの複雑なデバッグ
問題に対して解答を提供する。この技術は、前節で述べ
た透明性、制御および使い易さの喪失の問題に取り組
み、同時に現状のエミュレータの特徴を拡張する。

【００２３】本発明のオンチップ・デバッグ・コンポネ
ントはコストおよびデバッグ能力を最適化するための手
段を提供する。その構造はシステム・コストおよび市場
化の時間という制約に合致するように調整されたエミュ
レーション・コンポネントまたは周辺機器の柔軟な組合
せを許容する。スケーリング可能という特徴によって、
それらを可能なコストおよび限られた性能オーバーヘッ
ドで製品デバイスに含めることが可能となる。

【００２４】

【発明の実施の形態】ここで本発明のエミュレーショ
ン、デバッグ、およびシミュレーション・ツールについ
て説明する。ここに述べるエミュレーションおよびデバ
ッグ・ツールは次のような前提に基づいている。すなわ
ち、従来、オフチップで実行されているデバッグ機能の
すべてでなくてもいくつかのものは、もしそれらが開発
者のデバッグ倉庫に残すべきものであれば、いつの日に
か製品デバイスに集積されるようになるであろうという
ことである。デバッグ機能をチップ上へ移動する手助け
のために、本発明はオンチップ展開のための強力でスケ
ーリング可能なデバッグ機能の一覧表を提供する。この
技術は、透明性消滅傾向によって生じた透明性、制御、
および使い易さの問題に直接的に対処する能力を付加す
るとともに、初期のＪＴＡＧ技術の利益すべてを継承し
ている。

【００２５】最初に述べた制御および透明性のギャップ
への取り組みへの先鋒となる４つの重要な構造的インフ
ラストラクチャ・コンポネントは次のものである。１．実時間エミュレーション（ＲＴＥ）２．実時間データ交換（ＲＴＤＸ）３．トレース４．高度解析

【００２６】これらのコンポネントは表１に示すように
透明性および制御の要請に対処する。

【００２７】

【表１】

【００２８】実時間エミュレーション（ＲＴＥ）は実時
間実行制御（ラン、ステップ、ホールト等）およびレジ
スタ／メモリ透明性に関する基本的な固定機能セットを
提供する。このコンポネントはユーザがアプリケーショ
ン・コードをデバッグすることを許容すると同時に、実
時間の割込みもサポートする。レジスタおよびメモリは
割込み処理に影響せずに実時間でアクセスされよう。ユ
ーザは実時間と非実時間の割込みを区別し、実時間での
メモリへのデバッグ・アクセスによって乱されるべきで
ないコードにマークを付ける。この基本エミュレーショ
ン機能には、２個のシングルポイント・ハードウエア・
ブレークポイント、シングル・データ・ウォッチポイン
ト、イベント・カウンタ、あるいはデータ・ログ機構と
して構成可能なハードウエアが含まれる。ＥＭＵピン機
能には、マルチプロセッサ・イベント処理および一方向
性（目標からホストへ）のデータ・ログ機構用のトリガ
ーＩ／Ｏが含まれる。

【００２９】ＲＴＤＸ（登録商標）はエミュレータ・ホ
ストと目標アプリケーションとの間で実時間データ転送
を提供する。このコンポネントはエミュレータによって
促進される双方向性および一方向性の両方のＤＳＰ目標
／ホスト転送を提供する。ＤＳＰ（または目標）アプリ
ケーションはホストへ転送すべき目標データを収集する
か、あるいはホストからデータを受信し、他方でエミュ
レーション・ハードウエア（ＤＳＰおよびエミュレータ
の内部にある）が実際の転送を管理する。いくつかのＲ
ＴＤＸ転送機構がサポートされており、その各々は異な
るレベルの帯域幅およびピン利用を提供することによっ
てゲートおよびピン利用性と帯域幅との間で要求のバラ
ンスを図っている。

【００３０】トレースはアプリケーション活動の透明性
を提供する非命令的機構である。トレースは、プログラ
ム・フローおよびメモリ・アクセスのようなＣＰＵに関
連する活動、およびＡＳＩＣ状態機械、データの流れ、
およびＣＰＵ収集データのようなシステム活動を監視す
るために使用される。歴史的なトレース技術はまた製品
デバイスよりも多くのピンを有するロジック・アナライ
ザ的な収集および特殊エミュレーション（ＳＥ）デバイ
スを使用していた。ロジック・アナライザあるいは同様
なデバイスは、状態機械的なプログラミング・インタフ
ェース（フィルタ機構）を使用して元々の表現でデータ
を処理していた。このトレース・モデルは、記憶し、観
察し、解析する必要のあるデータを選択する外部トリガ
ーでエクスポートされるすべての活動に依存していた。

【００３１】しかし、既存のロジック・アナライザ的な
技術は、より高レベルの集積化、増大するクロック・レ
ート、およびより複雑化するパッケージングによる透明
性低下に対する解答を提供しない。このモデルでは、製
品デバイスは限られた数のピンを通して透明性を提供し
なければならない。エクスポートされるデータは必要な
エクスポート帯域幅を小さくするようにエンコードまた
は圧縮される。記録機構は純粋な記録デバイスになり、
エクスポートされたデータを深いトレース・メモリに詰
め込む。記録されたデータをシステム活動の記録へ変換
するためにトレース・ソフトウエアが使用される。

【００３２】高速シリアル・データ・エクスポートを備
えたオンチップ・トレースは高度解析と組み合わせてＳ
ＯＣ設計に対する解答を提供する。トレースは、プログ
ラム・フローおよびメモリ・アクセスのようなＣＰＵに
関連する活動、およびＡＳＩＣ状態機械、データの流れ
等、およびＣＰＵ収集データのようなシステム活動を監
視するために使用される。これは４つの異なる種別のト
レース・データを生成する。・ＤＳＰコアによって提供されるプログラム・フローお
よびタイミング（ＰＣトレース）・ＤＳＰコアまたはチップ・レベルの周辺機器によって
行なわれるメモリ・データ参照（データの読み書き）・用途特定信号およびデータ（ＡＳＩＣ活動）・ＣＰＵ収集データ

【００３３】４種類のトレース・データに関する収集機
構は、機能性と、望ましい帯域幅要求に合致するために
必要なゲートおよびピンとのトレードオフを許容するモ
ジュール構成になっている。

【００３４】ＲＴＤＸおよびトレース関数は同様である
が異なる形の透明性を提供する。それらはデータ収集方
法およびそれらの最も効率的環境が異なる。理解を助け
るために以下に簡単な説明を行なう。

【００３５】ＲＴＤＸ（実時間データ交換）はＣＰＵの
支援を受けて情報交換を行なう方法である。ここで、交
換すべきデータはプログラム・フローに対して正しく定
義された振る舞いをする。例えば、ＲＴＤＸはＤＳＰア
ルゴリズムから入力および出力バッファを記録するため
に使用できる。ＲＴＤＸはデータ収集にＣＰＵの支援を
要求し、従ってそれを実行するために明確だが少しのＣ
ＰＵ帯域幅を必要とする。このように、ＲＴＤＸは、少
ない循環オーバーヘッド・コストで以って透明性を提供
するアプリケーション介入機構である。

【００３６】トレースは非介入的なハードウエア支援収
集機構（バス監視器のような）であり、非常に高い帯域
幅（ＢＷ）のデータ・エクスポートを備えている。トレ
ースは非常に高いデータ・レートでデータをエクスポー
トしなければならないとき、あるいはトレースすべき情
報の振る舞いが分からないか、あるいは本質的にランダ
ムであるか、アドレスに付随する場合に使用される。プ
ログラム・フローは振る舞いを予め知ることができない
場合の典型例である。この種の情報をエクスポートする
ために要する帯域幅は高い。指定されたアドレスのデー
タ・トレースは別の例である。データ・トレースをエク
スポートするために要する帯域幅は非常に高い。

【００３７】トレース・データは一方向性で、目標から
ホストへ向かう。一方向性のＲＴＤＸもサポートされて
いるが（データ・ログ）、ＲＴＤＸはどちらの方向へも
データ交換を行なうことができる。トレース・データ経
路もまた、非常に高速の一方向性ＲＴＤＸを提供するた
めに使用できる（ＣＰＵ収集されたトレース・デー
タ）。

【００３８】トレースおよびＲＴＤＸの高レベルな機能
について概略を表２に示す。

【００３９】

【表２】

【００４０】高度解析は非介入的なオンチップ・イベン
ト検出およびトリガー発生機構を提供する。高度解析に
よって生成されるトリガー出力はトレースおよびＲＴＤ
Ｘなどの他のインフラストラクチャ・コンポネントを制
御する。歴史的なトレース技術は、ロジック・アナライ
ザへエクスポートされたバス活動を使用してロジック・
アナライザ中でトレースを制御するトリガーを発生した
り、あるいは実行を停止させるためのトリガーを発生さ
せてデバイスへ供給したりした。通常、これには製品デ
バイスよりも多くのピンを有するチップが含まれていた
（ＳＥまたは特殊エミュレーション・デバイス）。この
解析モデルはシステム・オンチップ（ＳＯＣ）時代には
うまく動作しない。その理由は、今日のデバイスの集積
レベルおよびクロック・レートが完全な透明性を有する
バス・エクスポートを排除するためである。

【００４１】高度解析は入手可能なオンチップ命令およ
びデータバス比較器、シーケンサおよび状態機械、およ
びイベント・カウンタを提供して、オフチップで用いら
れた歴史的なトリガー機能の最も重要な部分を再現す
る。高度解析は、トレース、ＲＴＤＸ、および実時間エ
ミュレーションに対してデバッグ・トリガー機構の制御
部分を提供する。この構成コンポネントはイベントを識
別し、イベント・シーケンスを追跡し、それらの発生に
基づいてアクションを割り当てる（ブレイク実行、トレ
ース・イネーブル／ディスエーブル、カウント、ＲＴＤ
Ｘイネーブル／ディスエーブル等）。この機能に関する
モジュール構築ブロックには、バス比較器、外部イベン
ト発生器、状態機械あるいは状態シーケンサ、およびト
リガー発生器が含まれる。高度解析システムのモジュー
ル構成によって、機能性とゲートとのトレードオフが可
能となる。

【００４２】

【実施例】エミュレータ機能は４つのエミュレータ・コ
ンポネントの相互作用によって生まれる。１．デバッガ・アプリケーション・プログラム２．ホスト・コンピュータ３．エミュレーション・コントローラ４．オンチップ・デバッグ機能

【００４３】これらのコンポネントは図１に示すように
つながれる。ホスト・コンピュータ１０はエミュレーシ
ョン・コントローラ１２（ホストに対して外部にある）
へつながれ、エミュレーション・コントローラ（ここで
はエミュレータまたはコントローラとも呼ばれる）はま
た目標システム１６へつながれる。ユーザは、望ましく
は、例えばテキサス・インスツルメンツ社のプログラム
“ＣｏｄｅＣｏｍｐｏｓｅｒＳｔｕｄｉｏ”のよう
な、ホスト・コンピュータ上で走っているデバッガ・ア
プリケーション・プログラムを介して、目標アプリケー
ションを制御する。

【００４４】典型的なデバッグ・システムが図１に示さ
れている。このシステムはエミュレータ１２を介してデ
バッグ機能へアクセスするために、ホスト・コンピュー
タ１０（一般にはＰＣ）を使用する。デバッガ・アプリ
ケーション・プログラムはホスト・コンピュータを介し
て、使用者に使い易いかたちでデバッグ機能を提供す
る。デバッグ資源は必要に応じてデバッグ・ソフトによ
って割り振られ、この作業をユーザが行わなくてもよく
なっている。ソース・レベルでのデバッグではデバッグ
資源を利用するが、それの複雑な部分はユーザから見え
ないようになっている。デバッガは、オンチップのトレ
ースおよびトリガー機能と一緒に、興味の対象であるチ
ップ活動を選択、記録、および表示するための手段を提
供する。トレースのディスプレイは、そのトレース・ロ
グを発生したソース・コードに対して自動的に関連づけ
られる。エミュレータはデバッグ制御とトレース記録機
能の両方を提供する。

【００４５】デバッグ機能は、目標チップのＪＴＡＧま
たは同様なシリアル・デバッグ・インタフェースを介す
る標準的なエミュレータ・デバッグ・アクセスを用いて
プログラムされる。ピンは貴重なので、この技術ではト
レース、トリガー、およびその他のデバッグ機能でデバ
ッグ用ピンのプールを共有するようにしてシリコン・コ
ストの上昇を少なくしている。固定ピン・フォーマット
もサポートされている。ピンを共有するオプションを採
用するときには、デバッグ・ピンの利用は各デバッグ・
セッションの最初に（チップがアプリケーション・プロ
グラムを走らせるように命令される前に）トレース・エ
クスポート帯域幅を最大化するように決められる。トレ
ース帯域幅は最大数のピンをトレースに割り当てること
によって最大化される。

【００４６】システム内でのデバッグ能力および構築ブ
ロックは変動しよう。従って、エミュレータ・ソフトウ
エアは実行時に構成を決める。この方式は、コンフィギ
ュレーションおよびレジスタ組織化と取引する制約群に
合致するハードウエア・ブロックを必要とする。他のコ
ンポネン群は、ブロックおよび他の周辺機器をシステム
のメモリ・マップ上で位置決めするように設計されたハ
ードウエア検索能力を提供する。エミュレータ・ソフト
ウエアは資源を位置決めするために検索機能を使用す
る。モジュールの見つかったアドレスおよびタイプＩＤ
が、見出された各ブロックを一義的に同定する。一旦Ｉ
Ｄが見出されると、設計データベースを用いて正確なコ
ンフィギュレーションおよびすべてのシステム入出力が
確認される。

【００４７】ホスト・コンピュータは、一般に少なくと
も６４メガバイトのメモリを持ち、少なくともＷｉｎｄ
ｏｗｓ（登録商標）９５、ＳＲ−２、ＷｉｎｄｏｗｓＮ
Ｔ、あるいはＷｉｎｄｏｗｓの後継バージョンを走らせ
ることのできるＰＣである。ＰＣはエミュレータが要求
する通信インタフェースの１つをサポートしなければな
らない。例えば、・イーサネット（登録商標）１０Ｔおよび１００Ｔ、Ｔ
ＣＰ／ＩＰプロトコル・ユニバーサル・シリアル・バス（ＵＳＢ）、ｒｅｖ
１．ｘ・ファイヤワイヤ、ＩＥＥＥ１３９４・パラレル・ポート（ＳＰＰ、ＥＰＰ、およびＥＣＰ）

【００４８】エミュレーション・コントローラ１２はホ
スト・コンピュータ１０と目標システム１６との橋渡し
をし、ホスト・コンピュータ上で走るデバッガ・アプリ
ケーションとＤＳＰ（あるいはその他の目標プロセッ
サ）１４上で実行される目標アプリケーションとの間で
渡されるすべてのデバッグ情報を取り扱う。

【００４９】エミュレータ構成例の１つは以下の能力す
べてをサポートする。・実時間エミュレーション・ＲＴＤＸ・トレース・高度解析

【００５０】これに加えて、エミュレータから目標への
インタフェースは次をサポートする。・入力および出力トリガー・ビットＩ／Ｏ・特殊な拡張動作モードの管理

【００５１】エミュレーション・コントローラ１２は
３、４、または５ビットのスキャンをベースとするイン
タフェースを介して実時間エミュレーション機能（実行
制御、メモリ、およびレジスタ・アクセス）にアクセス
する。ＲＴＤＸ機能は、スキャンによって、あるいはス
キャン以外の目標からエミュレータへの直接的な接続を
使用するより高帯域幅の３つのＲＴＤＸフォーマットを
使用することによってアクセスできる。入出力トリガー
は他のシステム・コンポネントがそのチップに対してあ
るいはその逆に、デバッグ・イベント時に信号供給する
ことを許容する。

【００５２】エミュレータ１２は通信セクションとエミ
ュレーション・セクションとに区分される。通信セクシ
ョンはホスト通信リンク上でホスト１０との通信をサポ
ートし、他方エミュレーション・セクションは目標への
インタフェースとなって、目標デバッグ機能およびデバ
イス・デバッグ・ポートを管理する。エミュレータ１２
は、１５に示す、例えば、上述の工業標準の通信リンク
の１つを用いてホスト・コンピュータ１０と交信する。
ホストからエミュレータへの接続は規格のケーブル技術
を用いて確立できる。ホストとエミュレータとの間の分
離は、使用するインタフェースに適用される標準規格に
よって支配される。

【００５３】エミュレーション・コントローラ１２は１
７に示す１本または複数の目標ケーブルを通して目標シ
ステム１６と交信する。デバッグ、トレース、トリガ
ー、およびＲＴＤＸ機能は目標ケーブルを共有し、或る
場合には、同じデバイス・ピンを共有する。目標システ
ムが１本のケーブルに収納しきれないトレース幅で展開
するときには、２本以上の目標ケーブルが必要とされよ
う。すべてのトレース、ＲＴＤＸ、およびデバッグ通信
はこのリンク上で発生する。

【００５４】図２は図１のエミュレーション・システム
の実施の形態例の関連部分を示す回路図である。図２は
エミュレータ１２と目標チップ１4との間のケーブル１
７に設けられたスキャン・インタフェースを含んでい
る。図２に示すように、エミュレータ１２はスキャン・
インタフェースの複数の動作モードのうちの任意のもの
を選ぶことができる。ここに開示する例では、スキャン
・インタフェースは標準的なＪＴＡＧスキャン・インタ
フェースであるが、本発明はその他のタイプのスキャン
・インタフェースにも適用可能である。ここで、モード
Ｊ＿５は標準的なＪＴＡＧ形式を表し、それは目標チッ
プの５本のピンを使用する。モードＪ＿４およびＪ＿３
はスキャン動作のモードを示しているが、そこでは時分
割多重化が用いられており、スキャン・インタフェース
の１本のピンに対して５個のＪＴＡＧ信号のうちの複数
のものを組み合わせるようになっており、それによって
通常は標準的なＪ＿５動作に関連する５本のピンのうち
の１または複数本をフリーにすることができる。モード
Ｊ＿４は単一ピンへ２つのＪＴＡＧ信号を多重化し、従
ってスキャン動作のために４本のピンを必要とする。こ
れによって１本のピンがフリーとなって他のデバッグ機
能などの他の目的で使用できる。モードＪ＿３は３個の
ＪＴＡＧ信号を１本のピンに多重化し、従ってスキャン
動作用には３本のピンしか必要とせず、従って２本のピ
ンがフリーとなって他のデバッグ機能などの他の目的に
使用できる。Ｊ＿１モードでは多重化は行われないが、
スキャン・インタフェース専用としてＴＲＳＴ（テスト
論理リセット）信号のみが残され、４本のピンがフリー
となってデバッグ機能などの他の目的で使用できる。

【００５５】図３はスキャン動作の上述の各モードを説
明している。Ｊ＿１、Ｊ＿４、およびＪ＿３モードがエ
ミュレータと１個の目標デバイスとの間の点と点を結ぶ
接続に限定され、他方Ｊ＿５はスキャン・チェーンでつ
ないだ任意の数の目標デバイスに適用可能であることは
もちろんである点に注意されたい。

【００５６】再び図２を参照すると、目標チップは、Ｊ
＿５、Ｊ＿４、またはＪ＿３の任意のモードに従ってエ
ミュレータから受信した信号を、この例では５ピンのＪ
ＴＡＧインタフェースであるＪ＿５形式と等しい５信号
インタフェースへ変換するスキャン・インタフェース・
アダプタ２１を含む。言い換えれば、信号ＭＳＣＡＮＩ
ＮはＪ＿５インタフェースのＴＤＩに対応する。信号Ｍ
ＴＲＳＴはＪ＿５インタフェースの信号ＴＲＳＴに対応
する。信号ＭＴＣＫはＪ＿５インタフェースの信号ＴＣ
Ｋに対応する。信号ＭＴＭＳはＪ＿５インタフェースの
信号ＴＭＳに対応し、信号ＭＳＣＡＮＯＵＴはＪ＿５
インタフェースの信号ＴＤＯに対応する。このように、
エミュレータ１２によって利用されるインタフェース・
モードＪ＿５、Ｊ＿４、またはＪ＿３のどれであって
も、スキャン・インタフェース・アダプタ２１はこのイ
ンタフェースを、この例では目標チップ内に埋め込まれ
た複数コアのテスト制御用の５信号ＪＴＡＧインタフェ
ースへ変換する。逆に、スキャン・インタフェース・ア
ダプタ２１はチップ内で使用される５信号インタフェー
スを、エミュレータ側で選ばれたスキャン・インタフェ
ース・モードに必要とされる信号形式へ変換する。

【００５７】図４は、Ｊ＿４で動作中のエミュレーショ
ンと目標チップとの間のスキャン・インタフェース信号
接続を模式的に示す。Ｊ＿４構成では、エミュレータか
らのＴＭＳ信号およびエミュレータからのＴＤＯ信号の
両方を多重化するために、“エミュレータＴＤＯからチ
ップＴＤＩへ”の接続が用いられる。これらの時分割多
重化された（ＴＤＭ）信号は目標デバイスのＴＤＩピン
に受信される。次に、目標デバイス中のスキャン・イン
タフェース・アダプタは、図２に関して上述したよう
に、４ピン・インタフェースから標準的な５信号ＪＴＡ
Ｇ形式への変換を行なう。図４に示すように、目標デバ
イスとエミュレータとの間のＴＭＳ信号経路はフリーと
なって、デバッグ機能のような他の目的で使用できる。

【００５８】図５はＪ＿３スキャン・インタフェースを
使用した場合の、エミュレータと目標チップとの間のス
キャン・インタフェース接続を示す。Ｊ＿３構成では、
“エミュレータＴＤＩからチップＴＤＯへ”の接続が双
方向的信号として使用され、その上でエミュレータから
のＴＭＳ信号、エミュレータからのＴＤＯ信号、および
目標チップからのＴＤＩ信号が時分割多重化される。図
５に示すように、この構成ではエミュレータと目標チッ
プとの間の２本の接続（ＴＭＳおよび“目標ＴＤＩから
エミュレータＴＤＯへ”）がフリーとなってデバッグ機
能などの他の目的で使用できる。

【００５９】上述のＪ＿１構成は５スキャン・インタフ
ェース接続のうちの４本をデバッグ機能などの他の目的
に使用することを許容し、スキャン・インタフェースは
ＴＲＳＴ接続のみを制御できるため、エミュレータはス
キャン・インタフェース・アダプタ２１をスキャン動作
（これはＪ＿１構成ではもちろん不可能である）用に選
択的に構成することが可能である。特に、エミュレータ
によるＴＲＳＴのアサーションは、スキャン・インタフ
ェース・アダプタ２１にスキャン・インタフェースを例
えばＪ＿３、Ｊ＿４、あるいはＪ＿５のようなデフォル
トのスキャン・インタフェース設定にセットさせる。デ
フォルト設定はチップ構造によって指定でき、エミュレ
ータ・ソフトウエアを任意のデフォルト動作選択と互換
なものとすることは容易である。

【００６０】図６はＪ＿４モードにおいてスキャン・イ
ンタフェース・アダプタおよびエミュレータによって実
行可能な動作例を示す。図６に示すように、エミュレー
タ中の状態機械はＪ＿４インタフェース構成に関する入
出力シーケンスを制御する。状態機械はＪ＿４入出力を
制御するための９個の状態を含む。状態シーケンスはス
タート・ビットで開始され、その後に、４個のＴＭＳ値
が続き、４個のＴＤＩ値が続く。目標デバイス中のスキ
ャン・インタフェース・アダプタもまた状態機械を含
み、それはＪ＿４インタフェースをＪ＿５インタフェー
スへ変換するように動作し、９個の状態シーケンス中の
４個の状態（０ｘ４、０ｘ５、０ｘ６、および０ｘ７）
のみで図２の信号ＭＴＣＫをイネーブルすることを含
み、これらの４個の状態は目標からエミュレータへのＴ
ＤＯ出力およびスキャン・インタフェース・アダプタか
らコアへのＴＭＳ／ＴＤＩ並列出力用に使用される。

【００６１】１つの実施の形態では、図４の目標チップ
のＴＲＳＴピンに対して０が供給されるときに、チップ
のスキャン・インタフェース・アダプタ中の状態機械は
強制的にスタート状態（０ｘＦ）にされる。状態機械は
また、ＴＣＫが連続して走っているときに、もしＴＣＫ
の少なくとも９個の引き続くサイクルに対してエミュレ
ータのＴＤＯ信号が論理１であれば、いくつかの実施の
形態でも強制的にスタート状態にされよう。スキャン・
インタフェース・アダプタがスタート状態にあるとき
に、もしそれのＴＤＩ入力に論理１が検出されれば、そ
れは目標チップのコアに対してテスト・リセットをアサ
ートし、スタート状態に留まる。スタート状態中にスキ
ャン・インタフェース・アダプタがそれのＴＤＩ入力に
０を検出すれば、状態機械は図６に示す状態進行を開始
して、状態０ｘ０から状態０ｘ７へ逐次的に進行し、次
にスタート状態０ｘＦへ戻り、そこで再びそれのＴＤＩ
入力において論理０のチェックを行なう。

【００６２】図７は、図６に示すＪ＿４動作に対応する
タイミング図である。

【００６３】図８はＪ＿３スキャン・モードにおいてエ
ミュレータおよびスキャン・インタフェース・アダプタ
が実行できる動作例を示す。このモードで、スキャン・
インタフェース・アダプタは、エミュレータが少なくと
も１６個のクロック（ＴＣＫ）を供給し、他方、目標デ
バイスのＴＤＯピンに対してエミュレータによって論理
１が供給されるときに、それの状態機械をリセット状態
へ初期化する。エミュレータ中の状態機械はアダプタ状
態機械と共同して、１６個の状態を用いてＪ＿３スキャ
ン動作を管理する。状態シーケンスは、エミュレータが
それのＴＤＩピンから目標デバイスのＴＤＯピンへスタ
ート・ビット（０）とそれに続く４個のＴＭＳ値、更に
それに続く４個のＴＤＩ値を送ることから始まる。次の
ＴＣＫパルスでは、エミュレータは目標デバイスのＴＤ
Ｏピンを駆動することをやめる。この時点で、図８に８
１として示すように、エミュレータも目標デバイスも目
標デバイスのＴＤＯピンを駆動しない。

【００６４】８２の次のＴＣＫパルスで、目標デバイス
はＴＣＫの５サイクルの最初のものに関してそれのＴＤ
Ｏピンを駆動する。これらＴＣＫサイクルの最初の４サ
イクルの間、目標デバイスは目標デバイスのスキャン・
データＴＤＯ＿０−ＴＤＯ＿３を駆動出力する。図２の
信号ＭＴＣＫはこれらの４サイクル間だけスキャン・イ
ンタフェース・アダプタからコアへのＴＭＳ／ＴＤＩ並
列出力をイネーブルされる。５番目のＴＣＫサイクルの
間は、目標デバイスは８３に示されるように、それのＴ
ＤＯピン値を論理１へ駆動する。

【００６５】８４における次のＴＣＫパルスで、目標デ
バイスはエミュレータへのそれのＴＤＯピンの制御を放
棄して、エミュレータが論理１を駆動する。制御が８４
で交換されるときに、エミュレータも目標デバイスも両
方とも論理１を駆動するため、この制御の交換の間にバ
スの衝突は発生しない。次のＴＣＫサイクルの間に、エ
ミュレータは再び図８のシーケンスを開始するためにス
タート・ビットを供給する。

【００６６】もしスキャン・インタフェース・アダプタ
に関するデフォルト・モードがＪ＿３であれば、目標デ
バイスの状態機械は、ＴＲＳＴピンが０へ駆動されると
きは強制的に状態０ｘＦにされる。ＴＲＳＴの動作によ
るかあるいは図８に示す状態シーケンスに従って目標デ
バイスの状態機械が状態０ｘＦにあるとき、目標デバイ
スの状態機械はエミュレータが論理０のスタート・ビッ
トを供給することを期待する。スタート・ビットの検出
に失敗することはエミュレータと目標が同期を失うか、
エミュレータが存在しないか、あるいはエミュレータと
目標とが異なるスキャン・インタフェース・モードで動
作しているかのいずれかを意味する。もし目標デバイス
の状態機械が０ｘＦ状態中に論理１を検出すれば、目標
デバイスの状態機械は目標デバイスの内部コアに対して
ＭＴＲＳＴをアサートし、状態０ｘＦに留まる。目標デ
バイスの状態機械が状態０ｘＦにあって、目標デバイス
のＴＤＯ入力に０が検出されたときは、目標デバイス状
態の機械がそれの状態進行を開始して、状態０ｘ０から
０ｘＥへと状態が順次進行して再び状態０ｘＦに進み、
そこにおいて目標デバイスの状態機械はそれのＴＤＯピ
ン上で論理０スタート・ビットに関する上述のチェック
を実行する。エミュレータが連続して走るＴＣＫを供給
し、目標デバイスのＴＤＯピンが論理１へプル・アップ
されるときは、目標デバイスのスキャン・インタフェー
ス・アダプタ中の状態機械は、ＴＣＫが連続して走って
いる状態でＴＤＯが論理１へプル・アップされる期間に
ＴＲＳＴがアサートされないときは、１６個のＴＣＫサ
イクルのうちのテスト・リセット状態へ初期化される。

【００６７】図９は図８のＪ＿３動作に対応するタイミ
ング図である。

【００６８】選ばれたスキャン・インタフェース・モー
ド、例えばＪ＿５、Ｊ＿４、Ｊ＿３、あるいはＪ＿１
は、エミュレータから目標デバイスへ、例えばＴＤＩデ
ータ・ストリーム中の、ＬＳＢにＭＳＢが続くビット対
のようなＴＤＩ情報として送信できる。いくつかの実施
の形態では、一旦、モード情報のＬＳＢが送信されてし
まえば、モード情報のＭＳＢは常に次のＴＤＩ情報スロ
ット中で送信される。ＪＴＡＧ実施の形態を例に取れ
ば、モード・ビット対の送信を次のような条件によって
開始できる。ＴＲＳＴ、ＩＲ＿ＵＰＤＡＴＥ、あるいは
ＤＲ＿ＵＰＤＡＴＥ状態に続くＩＤＬＥ状態、その間に
モードのＬＳＢが送信されたＩＤＬＥ状態に続くＩＤＬ
Ｅ状態、ＩＲ＿ＳＣＡＮ状態に続くＩＲ＿ＥＸＩＴ状
態、ＤＲ＿ＳＣＡＮ状態に続くＤＲ＿ＥＸＩＴ状態、Ｄ
Ｒ＿ＣＡＰＴＵＲＥ状態に続くＤＲ＿ＰＡＵＳＥ状態、
ＩＲ＿ＣＡＰＴＵＲＥ状態に続くＩＲ＿ＰＡＵＳＥ状
態、その間にモードのＬＳＢが送信されたＤＲ＿ＰＡＵ
ＳＥ状態に続くＤＲ＿ＰＡＵＳＥ状態、その間にモード
のＬＳＢが送信されたＩＲ＿ＰＡＵＳＥ状態に続くＩＲ
＿ＰＡＵＳＥ状態。

【００６９】図１０はモード・ビットの所望のスキャン
・インタフェース・プロトコルへのマッピング例を示
す。

【００７０】図１１は図１０のモード・ビットに関する
送信コントローラの実施の形態例を模式的に示す。信号
１１１が活性なときにモードＬＳＢが送信され、また信
号１１２が活性なときにモードＭＳＢが送信される。

【００７１】図１４−１６はＪ＿５から他のモードへの
モード切替例を示すタイミング図である。図１７−１９
はモードＪ＿４から他のモードへのモード切替例を示す
タイミング図である。図２０−２２はモードＪ＿３から
他の他のモードへのモード切替例を示すタイミング図で
あり、図２３−２５はモードＪ＿１から他のモードへの
モード切替例を示すタイミング図である。これらの例
で、ＪＭ（０）およびＪＭ（１）はそれぞれ、モード・
ビットＬＳＢおよびＭＳＢである。

【００７２】図１２は図２のエミュレータの実施の形態
例の関連部分を示しており、図６−１１に関して上で説
明した動作を実行できる状態機械を含んでいる。図１２
に示すように、ＴＣＫ、ＴＤＩ、ＴＤＯ、およびＴＭＳ
接続を用いてエミュレータと目標チップとの間で非スキ
ャン情報を交信することができる。状態機械は、ＴＭ
Ｓ、ＴＤＯ、およびＴＣＫラインが非スキャンのために
使用されるときは、それらを適正に３状態化することが
できる。

【００７３】図１３は図２、４、および５の目標デバイ
スの実施の形態例の関連部分を模式的に示す。図１３に
示すように、目標チップのスキャン・インタフェース・
アダプタは、エミュレータから受信した時分割多重化情
報を適切に遅延させて時分割多重化信号を逆多重化する
遅延ラインと一緒に、図６−１１に関して上述した動作
を実行できる状態機械１３２を含む。これらの逆多重化
された信号は次に、図２に示すように目標デバイスのコ
アへつながるそれぞれの信号ライン上へ出力できる。図
１３に示すように、状態機械１３２は目標デバイスのＴ
ＤＯ出力を、この接続が非スキャン目的に使用されると
きは３状態化できる。

【００７４】図１３はまた、１３５として構成スイッチ
を示しており、それはエミュレータが、例えばデバッグ
情報を取得するために目標デバイス内の所望の目標ノー
ドにアクセスすることを許容する。選ばれたスキャン・
インタフェース・モードに依存して、ＴＣＫ、ＴＤＯ、
ＴＤＩ、およびＴＭＳに関する信号接続をデバッグ動作
などの非スキャン目的に用いることができる。目標デバ
イスのデータ・スキャン・パスには、エミュレータがス
イッチ１３５の構成を制御して目標デバイス中の所望ノ
ードへアクセスできるようにするための構成情報をその
中へスキャン・インできるように、構成レジスタ１３７
が設けられている。状態機械はまた、関連するエミュレ
ータ接続がスキャン目的のために使用されるときに必要
とされるような構成スイッチ・セクション１３５の出力
を３状態化できる３状態制御ライン１３１を含んでい
る。

【００７５】再び図１０、１１、および１４−２５を参
照すると、エミュレータの状態機械が非スキャン状態に
なったときには、目標デバイスのＴＤＩピン（Ｊ＿５ま
たはＪ＿４動作の場合）、あるいは目標デバイスのＴＤ
Ｏピン（Ｊ＿３動作の場合）のいずれかを通って新しい
モード情報が目標デバイスに送られる。上述のように、
いくつかの実施の形態では、一旦ＬＳＢが送信されてし
まえば、ＭＳＢは常に次に利用できるエミュレータから
目標デバイスへのスキャン情報スロット中で、エミュレ
ータのＴＤＩピンから標的デバイスのＴＤＯピンへのス
キャン（モードＪ＿４およびＪ＿５の場合）、あるいは
エミュレータのＴＤＩピンから目標デバイスにＴＤＯピ
ンへのスキャン（Ｊ＿３動作の場合）のいずれかにおい
て送信できよう。

【００７６】更に注意すべきことは、図１４−２５のタ
イミング図において、ＤＬＹ１信号は図１３の遅延ライ
ンの出力であり、例えば、モードＪ＿３およびＪ＿４で
ＴＭＳ値を遅延させるためには４ビットの遅延ラインが
必要である（図６および８も参照）。信号ＧＴＣＫは、
図６および７のＪ＿４動作の間、および図８および９の
Ｊ＿３動作の間に図２の信号ＭＴＣＫを駆動するために
状態機械１３２によって生成されるようなＴＣＫのゲー
トされたものである。

【００７７】本発明の他の実施の形態に従うスキャン・
インタフェース・アダプタはＪ＿３とＪ＿５の間、ある
いはＪ＿４とＪ＿５の間でのみ変換を行なう。そのよう
な実施の形態例では、エミュレータはどの変換（もしあ
れば）がサポートされているかを、目標デバイスとまず
Ｊ＿３プロトコルに従って、次にＪ＿４プロトコル、そ
して次にＪ＿５プロトコルに従って交信を試みることに
よって自動検出できる。目標デバイスは、エミュレータ
が使用するプロトコルが正しい場合にのみ正しく応答す
る。

【００７８】Ｊ＿１スキャン・インタフェース・モード
に関しては、スキャン・インタフェースは実際にはこの
モードで禁止される。エミュレータは、通常はＴＣＫ、
ＴＭＳ、ＴＤＩ、およびＴＤＯに割り当てられるピンが
デバッグ機能などの他の機能に割り当てられることを期
待する。スキャン・インタフェース・アダプタ中の状態
機械は、モードがＪ＿１である間は強制的に状態０ｘＦ
にされる（図６および８も参照）。エミュレータによる
ＴＲＳＴのアサートによって、図２３−２５に示すよう
に、モードはＪ＿１からデフォルト・モード（Ｊ＿３、
Ｊ＿４、あるいはＪ＿５のいずれか）へ同期変化する。

【００７９】上で示したように、スキャン・インタフェ
ース中の時分割多重化を用いることによって、更にスキ
ャン・インタフェースを禁止することによって、本発明
は、通常はスキャン・インタフェースに割り当てられる
エミュレータから目標デバイスへの接続を、他の所望の
機能、例えばデバッグ機能に選択的に割り当てることが
できる。従って、これらの他の機能は通常のスキャン・
インタフェース機能にオーバーレイされる。これによっ
て、より多くの目標デバイス・ピンをエミュレータとの
所望の非スキャン通信のために有利に提供できる。

【００８０】以上のように、本発明の実施の形態例につ
いて詳細に説明してきたが、これは本発明のスコープを
制限するものではない。本発明のスコープは多様な実施
の形態に具体化できる。

【００８１】関連出願へのクロスリファレンス本出願は３５Ｕ．Ｓ．Ｃ．１１９（ｅ）（１）のもと
で、下記の暫定的同時係属米国出願、すなわち２０００
年３月２日付けの第６０／１８６，３２６（事件番号Ｔ
Ｉ−３０５２６）および、元々非暫定米国出願第０９／
５１５，０９３号として２０００年３月２日付けで出願
され、その後２０００年８月１８日に申請が認可されて
暫定出願形式に変更された第６０／２１９，３４０号
（事件番号ＴＩ−３０４９８）の優先権を請求する。

【図面の簡単な説明】

【図１】本発明に従うエミュレーション・システムの実
施の形態例を示す回路図。

【図２】本発明に従う図１のシステムの実施の形態例の
関連部分を示す回路図。

【図３】本発明に従う図１および図２のエミュレータと
目標デバイスとの間の複数のスキャン・インタフェース
の定義を示す表。

【図４】本発明に従う図１および図２のエミュレータと
目標デバイスとの間のスキャン・インタフェースの実施
の形態例を示す回路図。

【図５】本発明に従う図１および図２のエミュレータと
目標デバイスとの間のスキャン・インタフェースの別の
実施の形態例を示す回路図。

【図６】図４のスキャン・インタフェースによって実行
できる動作例を示す表。

【図７】図６に示される動作に対応するタイミング図。

【図８】図５のスキャン・インタフェースによって実行
できる動作例を示す表。

【図９】図８の動作に対応するタイミング図。

【図１０】図２に示すスキャン・インタフェースの対応
するモードを選ぶために図２、図４、および図５の目標
デバイス中へスキャンできるモード・ビット例を示す
表。

【図１１】図１０のモード・ビットに対する送信コント
ローラの実施の形態例を示す回路図。

【図１２】図１、図２、図４、および図５のエミュレー
タの実施の形態例の関連部分を示す回路図。

【図１３】図１、図２、図４、および図５に示す目標デ
バイスの実施の形態例の関連部分を示す回路図。

【図１４】図２に示すスキャン・インタフェース・モー
ドから図２に示す他のスキャン・インタフェース・モー
ドへの切り替えに付随する動作例を示すタイミング図。

【図１５】図２に示すスキャン・インタフェース・モー
ドから図２に示す他のスキャン・インタフェース・モー
ドへの切り替えに付随する動作例を示すタイミング図。

【図１６】図２に示すスキャン・インタフェース・モー
ドから図２に示す他のスキャン・インタフェース・モー
ドへの切り替えに付随する動作例を示すタイミング図。

【図１７】図２に示すスキャン・インタフェース・モー
ドから図２に示す他のスキャン・インタフェース・モー
ドへの切り替えに付随する動作例を示すタイミング図。

【図１８】図２に示すスキャン・インタフェース・モー
ドから図２に示す他のスキャン・インタフェース・モー
ドへの切り替えに付随する動作例を示すタイミング図。

【図１９】図２に示すスキャン・インタフェース・モー
ドから図２に示す他のスキャン・インタフェース・モー
ドへの切り替えに付随する動作例を示すタイミング図。

【図２０】図２に示すスキャン・インタフェース・モー
ドから図２に示す他のスキャン・インタフェース・モー
ドへの切り替えに付随する動作例を示すタイミング図。

【図２１】図２に示すスキャン・インタフェース・モー
ドから図２に示す他のスキャン・インタフェース・モー
ドへの切り替えに付随する動作例を示すタイミング図。

【図２２】図２に示すスキャン・インタフェース・モー
ドから図２に示す他のスキャン・インタフェース・モー
ドへの切り替えに付随する動作例を示すタイミング図。

【図２３】図２に示すスキャン・インタフェース・モー
ドから図２に示す他のスキャン・インタフェース・モー
ドへの切り替えに付随する動作例を示すタイミング図。

【図２４】図２に示すスキャン・インタフェース・モー
ドから図２に示す他のスキャン・インタフェース・モー
ドへの切り替えに付随する動作例を示すタイミング図。

【図２５】図２に示すスキャン・インタフェース・モー
ドから図２に示す他のスキャン・インタフェース・モー
ドへの切り替えに付随する動作例を示すタイミング図。

【符号の説明】

１２エミュレータ１４目標チップ１７ケーブル２１スキャン・インタフェース・アダプタ１１１，１１２信号１３２状態機械１３５構成スイッチ１３７構成レジスタ

フロントページの続きＦターム(参考） 2G132 AA03 AA08 AA13 AC12 AC14 AE21 AK15 AK23 5B042 GA09 GB08 GB09 GC05 HH03 MA00 MC13 5B046 AA08 CA04 DA05 GA01 HA08 JA05 5B048 AA11 BB02 CC18 DD08

Claims

【特許請求の範囲】

【請求項１】各信号が通常は対応するスキャン・イン
タフェース信号経路によって運ばれる複数信号を使用す
る前記スキャン・インタフェースとの交信をサポートす
る方法であって、前記スキャン・インタフェースに付随する第１信号を供
給する工程、前記スキャン・インタフェースに付随する第２信号を供
給する工程、および前記第１および第２信号を単一の信
号経路上で時分割多重化する工程、を含む方法。
【請求項２】請求項１記載の方法であって、前記第１
信号がデータ信号である方法。
【請求項３】請求項２記載の方法であって、前記第２
信号がデータ信号である方法。
【請求項４】請求項２記載の方法であって、前記第２
信号が制御信号である方法。
【請求項５】請求項１記載の方法であって、前記第１
信号が制御信号である方法。
【請求項６】請求項１記載の方法であって、前記スキ
ャン・インタフェースに付随する別の信号を供給する工
程、および前記別の信号を前記第１および第２信号と一
緒に前記単一の信号経路上で時分割多重化する工程を含
む方法。
【請求項７】請求項６記載の方法であって、前記第１
および第２信号がデータ信号であり、前記別の信号が制
御信号である方法。
【請求項８】請求項７記載の方法であって、前記単一
の信号経路上で前記第１、第２、および別の信号を受信
する工程、および前記対応するスキャン・インタフェー
ス信号経路のそれぞれの上へ前記第１、第２、および別
の信号を逆多重化する工程を含む方法。
【請求項９】請求項１記載の方法であって、前記スキ
ャン・インタフェースがＪＴＡＧインタフェースである
方法。
【請求項１０】請求項１記載の方法であって、前記単
一の信号経路上で前記第１および第２信号を受信する工
程、および前記対応するスキャン・インタフェース信号
経路のそれぞれの上へ前記第１および第２信号を逆多重
化する工程を含む方法。
【請求項１１】スキャン・アダプタ装置であって、第１通信ポートであって、スキャン・インタフェースに
付随し、前記第１通信ポートの単一信号経路上で時分割
多重化された第１および第２信号を介してエミュレータ
と交信するための第１通信ポート、前記スキャン・インタフェースへつながる第２通信ポー
ト、および前記第１と第２通信ポートとの間につながれ
たアダプタであって、前記時分割多重化された第１およ
び第２信号を受信し、それに対応して前記第１および第
２信号を前記対応する第２通信ポート信号経路へ供給す
るためのアダプタ、を含むスキャン・アダプタ装置。
【請求項１２】請求項１１記載の装置であって、前記
アダプタが、前記第１と第２通信ポートとの間のインタ
フェースとなる状態機械を含んでいる装置。
【請求項１３】請求項１１記載の装置であって、前記
アダプタが、前記時分割多重化された第１および第２信
号を逆多重化するための遅延ラインを含んでいる装置。
【請求項１４】請求項１１記載の装置であって、前記
第１信号がデータ信号である装置。
【請求項１５】請求項１４記載の装置であって、前記
第２信号が制御信号である装置。
【請求項１６】請求項１４記載の装置であって、前記
第２信号がデータ信号である装置。
【請求項１７】請求項１１記載の装置であって、前記
第１通信ポートが更に、前記スキャン・インタフェース
に付随し、前記単一の信号経路上で前記第１および第２
信号と一緒に時分割多重化された別の信号を介してエミ
ュレータと交信するようになっており、また前記アダプ
タが更に、前記対応する第２通信ポート信号経路上へ前
記第１、第２、および別の信号を供給する装置。
【請求項１８】請求項１７記載の装置であって、前記
第１および第２信号がデータ信号であり、前記別の信号
が制御信号である装置。
【請求項１９】請求項１１記載の装置であって、前記
スキャン・インタフェースがＪＴＡＧインタフェースで
ある装置。
【請求項２０】集積回路であって、データ処理コア、前記データ処理コアへつながれて、それとのスキャン交
信を許可するためのスキャン・インタフェース、および
スキャン・インタフェース・アダプタであって、第１通
信ポートであって、前記スキャン・インタフェースに付
随し前記第１通信ポートの単一の信号経路上で時分割多
重化された第１および第２の信号を介してエミュレータ
と交信するための第１通信ポート、前記スキャン・イン
タフェースにつながれた第２通信ポート、および前記第
１と第２の通信ポート間につながれたアダプタであっ
て、前記時分割多重化された第１および第２信号を受信
し、それに応答して前記対応する第２通信ポート信号経
路上へ前記第１および第２信号を供給するためのアダプ
タを含むスキャン・インタフェース・アダプタ、を含む
集積回路。