JP2001356930A - エミュレータ・目標デバイス間接続の自動検出方法および装置 - Google Patents

Abstract

(57)【要約】 【課題】 エミュレーション・コントローラと複数の目
標デバイスとの間の接続を自動検出する。 【解決手段】 目標デバイス（チップ１、チップN）お
よびエミュレーション・コントローラ（１２）がそれの
各端子を３状態化したあとで、目標デバイスの１つがそ
れの上述の各端子に予め定められた論理レベルを順次駆
動し、その間に上述端子の残りを３状態のままに保持す
る。これらの駆動（３３）および保持（３１）動作は、
このあと、残りの各目標デバイスによって順次実行され
る。各駆動工程の間に、全目標デバイスおよびエミュレ
ーション・コントローラはそれら上述端子（３４、４
３）における論理レベルを読み出す。

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

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

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

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

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

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

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

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

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

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

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

【００１２】

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

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

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

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

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

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

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

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

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

【００２１】

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

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

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

【００２４】

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

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

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

【００２７】

【表１】

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

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

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

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

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

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

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

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

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

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

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

【００３９】

【表２】

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

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

【００４２】

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

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

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

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

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

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

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

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

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

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

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

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

【００５４】図２は、図１に示すようなエミュレータ
と、この実施の形態では集積回路チップである複数の目
標デバイスとの間の接続例を示す回路図である。図２に
示すように、エミュレータ２１の目標チップ通信ポート
２０は２２および２３のケーブル接続によってチップ１
へつながれ、また２４および２５のケーブル接続によっ
てチップNへつながれる。ケーブル接続２５はケーブル
接続２３との間で少なくともいくつかの信号経路を共有
する。２２−２５のケーブル接続はチップ１およびチッ
プNのピンにおいて終端し、またチップ１の少なくとも
１本のピンは２６のようにチップNの少なくとも１本の
ピンへつながれる。図２の構成には他のチップも含まれ
るが、それらの或るものはケーブル接続によってエミュ
レータ２１へつながれ、また或るものは互いに相互接続
されよう。エミュレータ２１はまた、一般に２７で示す
従来のスキャン・パスによって複数の集積回路へつなが
れる。スキャン・インタフェースに付随する制御信号
は、これも例えば２３および２５のケーブル接続に含ま
れよう。

【００５５】本発明の実施の形態例に従えば、図２のエ
ミュレータ２１およびチップ１ないしチップNには、エ
ミュレータ２１と各チップとの間の接続、およびチップ
相互の接続を自動検出する機構が備えられている。いく
つかの実施の形態例で、このことは次のような工程に従
って行われる。 （１）各チップの各ピンにプル・アップ用抵抗を備える
こと、（２）各チップがそのすべてのピンで３状態を取
ること（３）エミュレータが、それの目標チップ通信ポ
ートの全端子で３状態を取ること、（４）各個別チップ
がそれの各ピンへ、一時に１チップずつ、一時に１ピン
ずつ論理０を駆動すること、同時に、駆動しているチッ
プ、他の全チップ、およびエミュレータの残り全ピン／
端子を３状態のままに保持すること、（５）各チップお
よびエミュレータがそれの各ピン／端子の論理状態を読
み出すこと、他方、各個別チップが各個別論理０を駆動
すること、

【００５６】上述の動作例の概要が図３および４に示さ
れている。

【００５７】図３は論理０を駆動するチップによって実
行できる動作例を示す。チップはそれの各ピンで順次論
理０を駆動するようになっており、各論理０を駆動する
一方でそれのすべてのピンを読み出す。従って３２にお
いて、チップのすべてのピンは３状態を取る。その後、
３３において与えられたピンが論理０に駆動され、その
後、すべてのピンは３４において読み出される。３５に
示すように、３２−３４の上述の工程は、チップのすべ
てのピンが駆動されるまで繰り返される。

【００５８】図４は、現在はピンを駆動していない図２
の各チップと図２のエミュレータとによって実行できる
動作を示す。４２において、すべてのピンを３状態にす
る。その後、４３においてすべてのピンが読み出され
る。４４に示すように、４３における読み出し動作は駆
動チップがそれのすべてのピンを駆動するまで繰り返さ
れる。

【００５９】図５は、実施の形態例である図２の集積回
路チップの関連部分を示す回路図である。図５の構成は
図３および４に関して上述した動作を実行することがで
きる。図５には書き込みレジスタ６１が含まれており、
その中へエミュレーション・コントローラは適切な機能
コードを書き込むことができ、それによって、マルチプ
レクサ６２および６３の動作によってピン６５を３状態
にするか、あるいは論理０を駆動することができる（図
６の表も参照）。読み出しレジスタ６４には（エミュレ
ーション・コントローラの制御によって）ピンの値をロ
ードできる。レジスタ６１へ書き込まれるデータと、レ
ジスタ６１および６４のＬＯＡＤ信号はエミュレーショ
ン・コントローラによって従来のやり方で提供でき、レ
ジスタ６４からのデータは任意の従来のやり方でエミュ
レーション・コントローラによって読み出すことができ
る。図５のマルチプレクサおよびバッファの構成はチッ
プの各ピンについて同じものにできる。

【００６０】上述のように、本発明は、エミュレータの
エミュレーション目標デバイスであり互いに接続される
であろう複数の集積回路チップとエミュレータとの間お
よびそれら相互間での接続を自動検出できるようになっ
ている。自動検出過程で決定される接続情報は容易にエ
ミュレータに提供でき、それを使用して接続に関するデ
ータベースが構築できる。このデータベースは、エミュ
レータと目標チップとの間のエミュレーション共同作業
の中で、エミュレータによって便利に活用できる。

【００６１】自動接続点検には全チップの全ピンが含ま
れる必要はなく、任意のものでも、すべてでも構わない
ことを理解されよう。

【００６２】本発明の実施の形例態について以上のよう
に詳細に説明してきたが、これは本発明の範囲を限定す
るものではない。本発明の範囲は多様な実施の形態で実
現することができる。

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

【図面の簡単な説明】

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

【図２】エミュレータと複数の目標チップとの間の接続
例を示す回路図。

【図３】図２の目標チップによって実行できる動作例。

【図４】図２のエミュレータおよび目標チップによって
実行できる動作例。

【図５】図２のチップの実施の形態例の関連部分を示す
回路図。

【図６】図５のピンに関連する機能および機能コード
例。

【符号の説明】

２０ 通信ポート ２２−２６ ケーブル接続 ２７ スキャン・パス ６１ 書き込みレジスタ ６２，６３ マルチプレクサ ６４ 読み出しレジスタ

───────────────────────────────────────────────────── フロントページの続き Ｆターム(参考） 2G132 AA00 AA01 AC10 AC11 AC15 AG14 AG15 AK07 AK23 AL09 AL11 5B042 GB08 GB09 HH03 5B048 AA11 BB02 DD08

Claims (17)

【特許請求の範囲】
1. 【請求項１】 エミュレーション・コントローラと複数
   の目標デバイスとの間の接続を自動検出する方法であっ
   て、 各目標デバイスがそれの端子を３状態化すること、 エミュレーション・コントローラがそれの端子を３状態
   化すること、 目標デバイスの１つがそれの前記端子の各々で予め定め
   られた論理レベルを順次駆動することであって、他方そ
   れの前記端子の残りを３状態に保持すること、 残りの目標デバイスの各々が前記１つの目標デバイスの
   後で前記駆動および保持工程を順次実行すること、およ
   び目標デバイスの各々が前記各駆動工程の間にそれの前
   記端子における論理レベルを読み出し、またエミュレー
   ション・コントローラが前記各駆動工程の間にそれの前
   記端子における論理レベルを読み出すこと、の工程を含
   む方法。
2. 【請求項２】 請求項１記載の方法であって、前記目標
   デバイスが前記駆動および保持工程を実行するべき時
   に、前記エミュレーション・コントローラが各目標デバ
   イスに対して情報を提供する工程を含む方法。
3. 【請求項３】 請求項２記載の方法であって、前記情報
   提供工程が、前記エミュレーション・コントローラが各
   目標デバイス中に情報をスキャンする工程を含んでいる
   方法。
4. 【請求項４】 請求項１記載の方法であって、前記目標
   デバイスが、それらの対応する端子において読み出した
   論理レベルを前記エミュレーション・コントローラへス
   キャン出力することを含んでいる方法。
5. 【請求項５】 請求項１記載の方法であって、各目標デ
   バイスの端子を予め定められた論理レベルへプルする工
   程を含む方法。
6. 【請求項６】 請求項１記載の方法であって、前記駆動
   工程が論理０レベルを駆動する工程を含んでいる方法。
7. 【請求項７】 請求項６記載の方法であって、各目標デ
   バイスの端子を論理１レベルへプル・アップする工程を
   含む方法。
8. 【請求項８】 外部エミュレーション・コントローラと
   の接続を自動検出できる集積回路デバイスであって、 外部デバイスと信号を送受信するための複数の端子、 前記端子につながれて、前記端子を選択的に３状態化
   し、予め定められた論理レベルを駆動するための端子制
   御回路、および前記端子制御回路へつながれて、前記予
   め定められた論理レベルを前記端子の各々で順次駆動
   し、同時に前記端子の残りのものを３状態に保持するよ
   うに前記端子制御回路を制御するための制御レジスタ、
   を含む集積回路デバイス。
9. 【請求項９】 請求項８記載の集積回路デバイスであっ
   て、前記端子へつながれて前記端子における論理レベル
   をその中に記憶するための記憶装置であって、各端子が
   前記予め定められた論理レベルで駆動されるそれぞれの
   期間に前記記憶装置中へ前記端子から論理レベルをロー
   ドするための記憶装置を含む集積回路デバイス。
10. 【請求項１０】 請求項９記載の集積回路デバイスであ
    って、別の集積回路デバイスがそれの各端子上に予め定
    められた論理レベルを順次駆動している期間に、前記端
    子における信号活動を記録するために前記端子のすべて
    が３状態にある時に、前記記憶装置が前記端子のすべて
    から論理レベルをロードするようになった集積回路デバ
    イス。
11. 【請求項１１】 請求項１０記載の集積回路デバイスで
    あって、前記記憶装置がレジスタである集積回路デバイ
    ス。
12. 【請求項１２】 請求項９記載の集積回路デバイスであ
    って、前記記憶装置がエミュレーション・コントローラ
    の動作によってロードできる集積回路デバイス。
13. 【請求項１３】 請求項９記載の集積回路デバイスであ
    って、前記記憶装置が外部エミュレーション・コントロ
    ーラから読み出し可能であって、そこに記憶された論理
    レベルを前記エミュレーション・コントローラへ出力す
    ることを許可するようになった集積回路デバイス。
14. 【請求項１４】 請求項８記載の集積回路デバイスであ
    って、前記予め定められた論理レベルが論理０レベルで
    ある集積回路デバイス。
15. 【請求項１５】 請求項８記載の集積回路デバイスであ
    って、前記端子制御回路が、前記制御レジスタへつなが
    れた制御入力を有する一対のマルチプレクサを含んでい
    る集積回路デバイス。
16. 【請求項１６】 請求項８記載の集積回路デバイスであ
    って、前記制御レジスタが前記エミュレーション・コン
    トローラの動作によって制御コードをロードできるよう
    になった集積回路デバイス。
17. 【請求項１７】 請求項８記載の集積回路デバイスであ
    って、前記端子制御回路が、前記端子の１つへつながれ
    た出力および前記制御レジスタへつながれた制御入力を
    有するマルチプレクサを含んでいる集積回路デバイス。