アルテラ CPLD における Agilent 3070 テスタを使用したイン・システム・ プログラミング この資料は英語版を翻訳したもので、内容に相違が生じる場合には原文を優先します。こちらの日本語版は参考用としてご利用ください。設計の際 には、最新の英語版で内容をご確認ください。 アプリケーション・ノート AN-628-1.0 このアプリケーション・ノートでは、Agilent 3070 テスト・システムを使用して、ア ルテラの MAX® II および MAX V デバイスのプログラミング時間を短縮する方法につ いて説明します。また、このアプリケーションノートでは、Agilent Technologies の PLD（プログラマブル・ロジック・デバイス（PLD））ISP（イン・システム・プログ ラミング）ソフトウェアを使用する場合としない場合における Agilent 3070 テスタ の開発フローについて説明します。 ISP は、PLD の中心的な機能であり、システム設計者およびテスト・エンジニアは、 PLD プログラミングをボード・レベル・テストに統合して、コスト面で大きなメ リットを享受することができます。これらのメリットには、事前にプログラムされ たデバイスの在庫削減、コスト低減、取り扱い時のデバイスの損傷の減少、技術変 更における柔軟性の向上などがあります。 アルテラは、他の ISP 対応のデバイスと共に Agilent 3070 テスト・システムを使用 して、MAX II および MAX V デバイスをプログラムするソリューションを提供して います。 1 Agilent 3070 テスタを使用して、MAX II および MAX V デバイスを他のファミリのデバ イス・ファミリと共にプログラムする場合は、Agilent 3070 テスタでチェイン内にあ るすべてのデバイスがプログラムできるように確認してください。 この章は、以下の項で構成されています。 101 Innovation Drive San Jose, CA 95134 www.altera.com ■ 2 ページの「PLD ISP ソフトウェアを使用しない Agilent 3070 テスタの開発フ ロー」 ■ 9 ページの「PLD ISP ソフトウェアを使用した Agilent 3070 テスタの開発フロー」 ■ 10 ページの「プログラミング時間」 ■ 10 ページの「ガイドライン」 © 2010 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, HARDCOPY, MAX, MEGACORE, NIOS, QUARTUS and STRATIX are Reg. U.S. Pat. & Tm. Off. and/or trademarks of Altera Corporation in the U.S. and other countries. All other trademarks and service marks are the property of their respective holders as described at www.altera.com/common/legal.html. Altera warrants performance of its semiconductor products to current specifications in accordance with Altera’s standard warranty, but reserves the right to make changes to any products and services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly agreed to in writing by Altera. Altera customers are advised to obtain the latest version of device specifications before relying on any published information and before placing orders for products or services. 2010 年 12 月 Altera Corporation Subscribe PLD ISP ソフトウェアを使用しない Agilent 3070 テスタの開発フロー 2 PLD ISP ソフトウェアを使用しない Agilent 3070 テスタの開発 フロー 図 1 に、PLD ISP ソフトウェアを使用せずに Agilent 3070 テスタでデバイスをプロ グラムする（（Serial Vector Format「.svf」ファイルを使用）のに必要なステップを 示します。 次の項では、図 1 に示す各ステップについて説明します。 図 1. SVF ファイルを使用した ISP に対する Agilent 3070 開発フロー（PLD ISP は不使用） Start Step 1 Create a PCB and Test Fixture Step 2 Create a .svf File Step 3 Convert the .svf File to a .pcf File Step 4 Create Executable Tests from the Files Step 5 Compile Executable Tests Designer Test Engineer Debug the Test Programming Successful? Step 6 No Yes Done アルテラ CPLD における Agilent 3070 テスタを使用したイン・システム・プログラミング 2010 年 12 月 Altera Corporation PLD ISP ソフトウェアを使用しない Agilent 3070 テスタの開発フロー 3 ステップ 1: PCB およびテスト冶具の作成 ISP を使用する場合、最初のステップはボードのレイアウトおよびテスト冶具の作 成です。 PCB およびテスト冶具の作成 以下の情報は、PCB デザインの問題における重要事項に関するものです。 ■ TCK 信号配線パターンをクロック・ツリーとして慎重に扱う必要があります。 TCK は、デバイスの JTAG チェイン全体に対するクロックです。これらのデバイス は TCK 信号でエッジ・トリガされるため、この信号を高周波ノイズから保護し、 良好なシグナル・インテグリティを確保する必要があります。信号が該当するデ バイス・ファミリのデータシートに記載されたパルス立ち上がり時間（tR）およ びパルス立ち下がり時間（tF）パラメータに適合することを確認してください。 ■ TCK 信号にプルダウン抵抗を追加します。TCK 信号は、パターン・キャプチャ・ フォーマット（.pcf）ダウンロード間では、プルダウン抵抗を介して Low に保持 する必要があります。Agilent 3070 ドライバは、テスト間ではハイ・インピーダ ンスになり、次の .pcf が適用されると短時間だけ Low にドライブするため、 TCK は Low に保持しなければなりません。TCK ラインがフロートすると、プログ ラミング・データ・ストリームが破壊され、デバイスは正しくプログラムされま せん。 f .pcf ファイルのダウンロードについて詳しくは、 「ステップ 2: .svf ファ イルの作成」を参照してください。 ■ テスト冶具のネイルに対して、VCC および GND テスト・アクセス・ポイント （TAP）を設けます。動作中には、PCB 動作が乱れないように、十分な TAP が必 要です。TAP が足りないと、システムのノイズが増大し、JTAG スキャンが中断 する可能性があります。 ■ システム・ノイズを低減するために、オンボード・オシレータをオフにします。 プログラミング中に、オンボード・オシレータを電気的にオフにする機能が必要 です。 ■ プログラミング中に外部抵抗を追加して、定義済みロジック・レベルに出力をプ ルします。 1 プログラミング中に、出力ピンははトライ・ステートになり、内部ウィー ク抵抗でプルアップされます。ただし、アルテラは定義済みレベルを必要 とする信号は、外部抵抗を使用して外部から強制的に適切なレベルに設定 することを推奨しています。 f ISP 用ボード・デザインについて詳しくは、「AN 100: In-System Programmability Guidelines」を参照してください。 冶具の作成 ISP を成功させるには、クリーンなインタフェースを提供するために、テスト冶具 内で短いワイヤを使用して、TCK の接続性を向上させます。ワイヤを長くすると、 システム内部に誘導ノイズが誘発され、プログラミングが中断することがあります。 TCK を接続するワイヤは 1 インチ未満にしてください。テスト冶具のレイアウトと作 成を管理するには、Agilent Fixture Consultant を使用します（Agilent Board Test Family Manual を参照）。 2010 年 12 月 Altera Corporation アルテラ CPLD における Agilent 3070 テスタを使用したイン・システム・プログラミング PLD ISP ソフトウェアを使用しない Agilent 3070 テスタの開発フロー 4 ステップ 2: .svf ファイルの作成 Quartus® II ソフトウェアは、1 つまたは複数のデバイスをプログラムするための .svf f ファイルを生成します。複数の MAX II および MAX V デバイス・ファミリを ターゲットとする場合、Quartus II ソフトウェアは、デバイスを同時にプログラムす るための 1 つの .svf ファイルを自動的に生成します。したがって、すべてのデバイ スのプログラミング時間は、IEEE Std. 1149.1 JTAG チェイン内の最大の CPLD デバ イスのプログラミング時間とほぼ等しくなります。 図 2 に、.svf ファイルの生成に使用する Create JAM, SVF, or ISC File ダイアログ・ ボックス（File メニュー）を示します。 図 2. Create JAM, SVF, or ISC File ダイアログ・ボックス .svf ファイルを作成する前に、Quartus II Programmer を開いて、チェイン内のすべ てのデバイス用の Programmer Object File（.pof）をプログラマに追加します。各 .pof は、それぞれのターゲット・デバイスに対応します。 Create JAM, SVF, or ISC File ダイアログ・ボックスで、TCK frequency ボックス 内の値は、TCK がテスト中に動作する周波数と一致する必要があります。テストで 使用される値と異なる周波数を入力すると、プログラミングが失敗したり、プログ ラミング時間が極端に長くなることがあります。 また、プログラム操作および検証操作のどちらを実行するかを選択でき、さらにオ プションで Programming options をオンにすることにより、デバイスの検証およ びブランク・チェックを選択できます。アルテラは、検証ベクタを含む .svf ファイ ルの生成を推奨しています。これによって、プログラミングの失敗が識別され、限 定された追加プログラミング時間が使用されます。必要な .svf ファイルは、プログ ラミング対象となるボードおよびアルテラ・デバイスのスキャン・チェイン・トポ ロジーに基づいて生成できます。svf ファイルが生成された後、テスト・エンジニア はこれを開発に使用できます。 デバイスを個別にプログラムする場合、チェイン内のアルテラ・デバイスごとに、 個別に .svf ファイルを生成できます。チェイン内の 1 つのデバイス用に SVF ファイ ルを作成する場合は、そのデバイスに .pof を指定し、Programmer での Add Device を選択することで残りのデバイスは <none> に設定したままにします。これ らのデバイスはプログラミング中にはバイパスされます。ターゲットとするすべて のデバイスに対する .svf ファイルを作成するまで、このプロセスを繰り返します。 アルテラ CPLD における Agilent 3070 テスタを使用したイン・システム・プログラミング 2010 年 12 月 Altera Corporation PLD ISP ソフトウェアを使用しない Agilent 3070 テスタの開発フロー 5 ステップ 3: .svf ファイルを .pcf ファイルに変換 Agilent 3070 テスタで使用するには、アルテラ svf2pcf 変換ユーティリティで .svf ファイルを .pcf ファイルに変換します。svf2pcf ユーティリティは、1 つのデバイ ス・チェインに対して複数の .pcf ファイルを作成できます。このユーティリティを 実行すると、ファイルごとにベクタ数を指定できます。結果として得られたファイ ルで使用されるメモリ容量は、データによって異なります。 Agilent 3070 デジタル・コンパイラはベクタの繰り返しパターンを検索し、ディレク トリを最適化します。さらに、テスタ・コントロール・カード上の RAM に順番を付 けて、ファイルを再ロード前のベクタの最大数を適用します。コンパイル済み .pcf ファイル内のベクタ数は、ターゲット・デバイスのサイズと集積度によって、10 万 ～ 100 以上になります。 f svf2pcf 変換ユーティリティは、アルテラ・ウェブサイトの Agilent ISP Support の ページからダウンロードできます。 ステップ 4: ファイルからの実行可能テストの作成 Agilent 3070 テスタを使用して、デバイスのチェインをプログラムするためのデジタ ル・テストを作成するには、次の項で説明するステップに従ってください。 a. 5 ページの「ターゲット・デバイスまたはスキャン・チェインのライブラリの 作成」 b. 6 ページの「Test Consultant の実行」 c. 6 ページの「デジタル・テストの作成」 d. 6 ページの「テスト用ワイヤリスト情報の作成」 e. 7 ページの「テスト・プランの修正」 ターゲット・デバイスまたはスキャン・チェインのライブラリの作成 ボード用の初回プログラム開発では、ISP バウンダリ・スキャン・チェイン・イン タフェース用のセットアップ専用ノード・テスト・ライブラリを作成します。テス ト・ライブラリにより、ターゲット・デバイスをプログラムするためのテスト冶具 に、Agilent 3070 テスタ・リソースが確実に予約されます。ボード上に 1 つのター ゲット・デバイスしかなく、かつそのデバイスが分離されているバウンダリ・ス キャン・チェインの一部分でない場合はピン・ライブラリを使用し、それ以外の場 合はノード・ライブラリを使用します。ピン・ライブラリを使用する場合は、すべ てのデバイス・ピンを記述する必要があります。テスト・ライブラリにはテスト・ ベクタを含めないでください。 2010 年 12 月 Altera Corporation アルテラ CPLD における Agilent 3070 テスタを使用したイン・システム・プログラミング PLD ISP ソフトウェアを使用しない Agilent 3070 テスタの開発フロー 6 以下のコード例は、セットアップ専用ノード・テスト・ライブラリを示します。 !Setup only test for the boundary scan chain assign TCK to nodes "TCK"! Node name for assign TMS to nodes "TMS"! Node name for assign TDI to nodes "TDI"! Node name for assign TDO to nodes "TDO"! Node name for inputs TCK, TMS, TDI outputs TDO pcf order is TCK, TMS, TDI, TDO! The order is that ! generates the PCF files. 1 the the the the TCK TMS TDI TDO pin pin pin pin defined by the program TCK および TMS バウンダリ・スキャン・ノードを Board Consultant で CRITICAL としてマークします。このクリティカル属性は、テスト冶具で のノードのワイヤ長を最小にします。 Test Consultant の実行 Test Consultant を実行して、新しいボード開発用のすべてのファイルを作成します。 Test Consultant は、このセットアップ専用テスト・ライブラリを使用して実行を終 了すると、正しい冶具配線情報とともに実行可能テスト（ベクタなし）を作成しま す。このファイルをテンプレートとして使用して、実行可能テストのソース・コー ドを作成します。 デジタル・テストの作成 実行可能テンプレートを希望のプログラム名にコピーすることで、デバイスのプロ グラムに必要なデジタル・テストを作成します。例えば、svf2pcf が 4 つの .pcf ファイルを作成した場合は、デジタル・ディレクトリ内の 4 つの実行可能テスト （prog_a、prog_b、prog_c、prog_d など）にテンプレート・ファイルをコピー します。 これらのテスト名を testorder ファイルに追加し、以下の構文を使用してこれらに permanent マークを付けます。 test test test test digital digital digital digital "prog_a"; "prog_b"; "prog_c"; "prog_d"; permanent permanent permanent permanent テスト用ワイヤリスト情報の作成 これらの実行可能テストをコンパイルして、テストのセットアップ専用バージョン 用にオブジェクト・ファイル（「テスト・プランの修正」を参照）を生成します。 Module Pin Assignment を実行して、必要なエントリを wirelist ファイル内に作成 します。 次に、ターゲット・デバイスをプログラムするためのベクタが含まれるように、実 行可能テストを修正します。実行可能テストで include ステートメントを使用する か、ベクタをファイルにマージできます。include ステートメントには以下の構文 を使用します。これは、実行可能テストの最後のステートメントでなければなりま せん。 include "pcf1" アルテラ CPLD における Agilent 3070 テスタを使用したイン・システム・プログラミング 2010 年 12 月 Altera Corporation PLD ISP ソフトウェアを使用しない Agilent 3070 テスタの開発フロー 7 .pcf ファイルは、デジタル・ディレクトリに存在し、またデジタル・ファイルでな ければなりません。デジタル・ファイルが正しいディレクトリに存在するように、 BT-Basic コマンド・ラインで以下のコマンドを実行します。 load digital "digital/pcf1" | re-save また、シェル・プロンプトで chtype コマンドを使用して、ファイルの位置を確認す ることもできます。 chtype -n6 digital/pcf1 各 .pcf ファイルについて、このステップを繰り返します。 テスト・プランの修正 以下の構文を使用して、テスト・プランにテスト・ステートメントを追加します。 test test test test "digital/prog_a" "digital/prog_b" "digital/prog_c" "digital/prog_d" ! ! ! ! First program file Second program file Third program file Fourth program file テストの実行は、svf ファイルが分割された順番と同じにします。例えば、svf ファ イルが 4 つのファイル（pcf1、pcf2、pcf3、pcf4）に分割された場合、テストを分 割の順番で実行しなければなりません（prog_a、prog_b、prog_c、prog_d の 順）。この順序に従わなければ、デバイスは正しくプログラムできません。 ステップ 5: 実行可能テストのコンパイル アルテラは、BT-Basic または UNIX シェルを使用したバッチ起動式コンパイルを推 奨しています。BT-Basic で以下のバッチ・ファイル・コードを参照してください （ターゲット・デバイスをプログラムするための 4 つの実行可能テストとデバッグ・ オブジェクト・コードの生成を仮定しています）。 compile compile compile compile "digital/prog_a" "digital/prog_b" "digital/prog_c" "digital/prog_d" ; ; ; ; debug debug debug debug 後で技術的変更が発生しても対応できるように、このファイルはボード・ディレク トリに保存してください。対応するシェル・スクリプトを参照してください（D オ プションでデバッグ情報を生成）。 dcomp dcomp dcomp dcomp 1 -D -D -D -D digital/prog_a digital/prog_b digital/prog_c digital/prog_d ソース・ファイルに含まれる .pcf ベクタ数、コントローラのタイプ、およびコント ローラの負荷によっては、コンパイル時間が長くなることがあります。アルテラは、 バッチ・ファイルを使用して、ISP テストのコンパイルを自動化することを推奨し ています。 定義されているアルテラ・デバイスを含むバウンダリ・スキャン・チェインを使用 する場合、.pcf ファイルのベクタが JTAG インタフェースに適用されている後に、 定義済みのアルテラ・デバイスのみプログラムされます。 2010 年 12 月 Altera Corporation アルテラ CPLD における Agilent 3070 テスタを使用したイン・システム・プログラミング PLD ISP ソフトウェアを使用しない Agilent 3070 テスタの開発フロー 8 ステップ 6: テストのデバッグ 実行可能テストが作成されると、テスト･システムのデバッグが可能になります。適 用されたベクタ・セットにより、デバイスのコンテンツを検証するとデバイスが正 しくプログラムされていることが確認できます。プログラミング・アルゴリズムは、 TDO ピンを使用してデバイスからのビットストリームをチェックします。どのベクタ も予想値に一致しない場合にはテストは失敗し、以下の 2 つのうちのいずれかを示 します。 ■ デバイス ID が予想された ID と一致しない。最初のテストの開始時に失敗する場合 は、明らかにこれが原因です。 ■ デバイスのプログラミングが失敗した。 各ベクタを調べて失敗の原因を特定すること必要はありません。デバイスのプログ ラミングが失敗する場合は、以下のトラブルシューティング・ガイドラインに従っ てください。 ■ テスト冶具のプルダウン抵抗をチェックします。ボード上で TCK ピンにプルアッ プ抵抗を配置した可能性があります。プルダウン抵抗が大きすぎる場合、TCK ピ ンはロジック Low に対するデバイスのスレッショルドを超えることがあります。 抵抗値を適切に調整します。入力ロジック･レベルの仕様については、該当する デバイス・ファミリのデータシートを参照してください。 ■ TCK ピンで過電力エラーが発生した場合は、抵抗値をチェックします。抵抗値が 小さすぎるために、テスト・システムが長い間バック・ドライブできないことが 原因と考えられます。 ■ テストの実行順序が正しいことを確認します。順序がバラバラでテストを実行す ると、プログラミング情報が不正になります。また、同じテストを連続 2 回実行 すると、ターゲット・デバイスが順不同になり、正しいプログラミング情報を受 け入れません。 ■ 実際のベクタが入力ピン（TCK、TMS、および TDI）の予想値と一致するように します。予想値が一致しない場合は、テストを再コンパイルする必要があります。 ■ テストにおける .pcf の順序のステートメントが、4 ページの「ステップ 2: .svf ファイルの作成」で生成された .pcf コードの順序に一致するようにします。一致 しない場合は、順序を変更してテストを再コンパイルしなければなりません。 ■ 可能な場合は、Quartus II ソフトウェア、ByteBlasterTM II ダウンロード・ケーブ ル、および .svf ファイルの生成に使用した .pof ファイルを使用して、デバイス が正しくプログラムされていることを確認します。この処置は、製造時に実用的 ではありませんが、テスト開発およびデバッグ中に役立ちます。 ■ 個々のデバイスを分離する必要がある場合、チェイン内のターゲットとするアル テラ・デバイスごとに個別の .svf ファイルを生成できます（4 ページの「ステッ プ 2: .svf ファイルの作成」を参照）。検証エラーが発生し、チェイン内の複数 のアルテラ・デバイスがプログラムされる場合、このプロセスを使用してくださ い。 ■ デバイスのプログラミングが失敗する場合は、ウンダリ・スキャン・チェインの 定義を調べます。命令レジスタのビット数がチェイン内の各デバイスに対して正 しく指定されていることを確認します。チェイン内のいずれかのデバイスに対し て不正なビット数が定義されている場合、プログラミング・テストは失敗しま す。 アルテラ CPLD における Agilent 3070 テスタを使用したイン・システム・プログラミング 2010 年 12 月 Altera Corporation PLD ISP ソフトウェアを使用した Agilent 3070 テスタの開発フロー 9 テストが正しく動作すると、ボードは製造プログラミングが可能な状態になります。 アルテラは、.pcf ファイルとオブジェクト・コードをバックアップのために保存し ておくことを推奨しています。圧縮プログラムを使用して、保存するバイナリおよ びファイルのサイズを最小にします。 PLD ISP ソフトウェアを使用した Agilent 3070 テスタの開発フ ロー PLD ISP ソフトウェアを使用した Agilent 3070 テスタによるデバイスのプログラミ ングは、2 ページの図 1 のステップとは多少異なります。 図 3 に、Agilent オプションの PLD ISP ソフトウェアと Agilent 3070 テスタを使用し た開発フローを示します。 次のセクションでは、図 3 に示す各ステップについて説明します。 図 3. Agilent の PLD ISP ソフトウェアを使用したイ ISP に対する Agilent 3070 開発フロー Start Step 1 Create a PCB and Test Fixture Step 2 Create a .svf, .jam, or .jbc File Step 3 Create Executable Tests from the Files Step 4 Compile Executable Tests Designer Test Engineer Debug the Test Programming Successful? Step 5 No Yes Done 2010 年 12 月 Altera Corporation アルテラ CPLD における Agilent 3070 テスタを使用したイン・システム・プログラミング プログラミング時間 10 Agilent PLD ISP ソフトウェアを使用すると、デバイス・プログラミングに対する svf2pcf フローと比較して、以下の利点が得られます。 ■ テスタは、.svf、Jam STAPL（.jam）、または .jbc ファイル・フォーマットを直接 使用した（つまり、.pcf や VCL に変換しない）デバイスのプログラミングをサ ポートできます。 ■ デバイスをプログラムする Agilent 3070 デジタル・テストは、1 つのファイルにな ります。 ■ デバイス・プログラミングが 1 つのテストとして実行されるため、TCK ラインと TMS ラインにプルアップ抵抗とプルダウン抵抗は必要ありません。 ■ デジタル・テストのソース・ファイル、およびコンパイル済みのオブジェクト・ ファイルのサイズが svf2pcf ソリューションの場合よりも、はるかに小さくなり ます。 ■ 1 つのデジタル・テスト・ファイルのみ実行されるため、大規模な CPLD およびコ ンフィギュレーション・デバイスに対する実行時間が高速化されます。 Jam Byte-Code Player Agilent の PLD ISP ソフトウェアを使用すると、Jam Byte-Code Player はテスタの Control XTP カードに実装されます。これにより、Quartus II ソフトウェアで生成さ れた .jbc ファイルを使用してデバイスをプログラムすることができます。また、テ スタはこれらのプログラミング用ファイルをコンパイルする JBC コンパイラを備え ているため、.jam ファイルや .svf ファイルにも対応します。Jam Byte-Code Player は、Control XTP カード上のマイクロコントローラを介して実行され、それによっ て、ベクタのシーケンスを実行するのではなく、アルゴリズム的にベクタを適用す ることが可能になります。 プログラミング時間 Agilent 3070 テスタにおけるプログラミング時間は、極めて一貫しています。唯一の 変数は TCK 周波数で、これはプログラミング時間に影響を及ぼします。プログラミ ング時間は、TCK クロック・レートの関数であるためです。クロックを高速にする と、データをデバイスにシフトする時間が短くなります。MAX II および MAX V デ バイスは、最大 18 MHz の TCK クロック・レートをサポートしています。 ガイドライン Agilent 3070 テスタをプログラミングに使用するときには、以下のガイドラインに 従ってください。 ■ ピン・ライブラリを使用して、スタンドアロンのバウンダリ・スキャン・チェイ ン内のターゲット・デバイスを記述する場合は注意が必要です。アルテラは、 ISP デバイスのすべての I/O ピンを双方向として記述することは推奨していませ ん。この手法では多数のハイブリッド・カード・チャネルが使用されるため、テ ストの開発時に冶具のオーバーフロー・エラーが発生する原因となる可能性があ ります。 アルテラ CPLD における Agilent 3070 テスタを使用したイン・システム・プログラミング 2010 年 12 月 Altera Corporation 改訂履歴 11 ■ テスト・ライブラリには .pcf ベクタを含めないでください。セットアップ専用 ノード・ライブラリを使用してください。.pcf ベクタを含むテスト・ライブラリ を作成すると、おおきなライブラリ・オブジェクト・ファイルが作成され、テス ト開発時間が大幅に長くなります。このような遅延が発生するのは、統合プログ ラム・ジェネレータがライブラリ・オブジェクトのベクタ・セット全体を調べ、 競合回避のためにベクタをコメント・アウトする必要があるか判断するからで す。ライブラリ・オブジェクト・コンパイルは、実行可能コンパイルとは異なり ます。さらに、ライブラリ・オブジェクト・ファイルが大きいために、統合プロ グラム・ジェネレータが失敗することがあります。 ■ 時間とディスク・スペースを節約するには、プログラミング動作での検証を含む .svf ファイルを生成します。このプロセスでは、検証ベクタは 1 つのステップに 統合されるため、テスト開発プロセスでの作業量が減少します。この統合化され た検証は、プログラミング・エラーを性格にキャプチャするため、テスト・シー ケンスに付加的なスタンドアロン検証を追加する必要はありません。 ■ 本書では、テストを生成してプログラミング用のデバイスにベクタを適用する方 法を説明していますが、デバイスの機能をテストするにはバウンダリ・スキャン 記述言語（BSDL）ファイルが必要です。バウンダリ・スキャン・テストまたは 機能テストを実行する場合は、ピン・コンフィギュレーション情報（どのピンが 入力ピン、出力ピン、双方向ピンであるかなど）を含むターゲット・デバイスの プログラム済み状態に対応する BSDL ファイルを生成します。テストの生成に は、Agilent 3070 バウンダリ・スキャン・ソフトウェアを使用します。 f バウンダリ・スキャン・テストのサポートについて詳しくは、「MAX II デバイス・ハ ンドブック」の 「IEEE 1149.1 (JTAG) Boundary-Scan Testing for MAX II Devices」 の章または「MAX V デバイス・ハンドブック」の 「JTAG Boundary-Scan Testing for MAX V Devices」の章を参照してください。 改訂履歴 表 1 に、このアプリケーション・ノートの改訂履歴を示します。 表 1. 改訂履歴 日付 2010 年 12 月 2010 年 12 月 Altera Corporation バージョン 1.0 変更内容 初版 アルテラ CPLD における Agilent 3070 テスタを使用したイン・システム・プログラミング 12 アルテラ CPLD における Agilent 3070 テスタを使用したイン・システム・プログラミング 改訂履歴 2010 年 12 月 Altera Corporation