5. avalon インタフェース対応...5–2 altera corporation quartus ii ハンドブックvolume...

Altera Corporation 5–12006年 5月

この資料は英語版を翻訳したもので、内容に相違が生じる場合には原文を優先します。こちらの日本語版は参考用としてご利用ください。設計の際には、最新の英語版で内容をご確認ください。

5. Avalonインタフェース対応JTAG UARTコア

コアの概要 Avalon® インタフェース対応の JTAG UART（Universal AsynchronousReceiver/Transmitter）コアは、ホスト PCとアルテラ FPGA上の SOPCBuilderシステムとの間で、キャラクタ・ストリームをシリアル通信する手段を実装しています。多くのデザインで、JTAG UART コアにより、キャラクタ I/Oのためにホスト PCへの RS-232シリアル接続を別途用意する必要はありません。このコアは、レジスタにマップされたシンプルな Avalonインタフェースを提供します。このインタフェースにより、エンベデッド・ソフトウェア・プログラマは JTAG インタフェースの詳細を意識する必要はありません。マスタ・ペリフェラル（Nios® IIプロセッサなど）は、コントロール・レジスタとデータ・レジスタに読み出しおよび書き込みを行って、コアと通信します。

JTAG UARTコアは、アルテラ FPGAに組み込まれた JTAG回路を使用し、FPGA上の JTAGピンを介してホスト・アクセスを提供します。ホスト PCは、USB-Blaster™ケーブルなどのアルテラ JTAGダウンロード・ケーブルを介して、FPGA に接続できます。JTAG UART コアのソフトウェア・サポートはアルテラによって提供されます。Nios IIプロセッサの場合、デバイス・ドライバが HAL システム・ライブラリに用意されているため、ソフトウェアは ANSI C 標準ライブラリの stdio.h ルーチンを使用してコアにアクセスできます。ホスト PC に対しては、アルテラは、ターゲットへの接続、JTAG データ・ストリームのデコード、および画面へのキャラクタ表示を管理する JTAGターミナル・ソフトウェアを提供しています。

JTAG UARTコアは、SOPC Builderへの対応が可能で、SOPC Builderで生成されたあらゆるシステムに容易に統合できます。

機能の説明図 5–1は、JTAG UARTコアおよび JTAG UARTコアとアルテラ FPGA内部の JTAG回路との接続を示すブロック図です。以下のセクションでは、コアのコンポーネントについて説明します。

NII51009-6.0.0

5–2 Altera CorporationQuartus IIハンドブック Volume 5 2006年 5月

機能の説明

図 5-1. JTAG UARTコアのブロック図

Avalonスレーブ・インタフェースとレジスタJTAG UARTコアは、アルテラ FPGA上の JTAG回路へのAvalonスレーブ・インタフェースを提供します。JTAG UART コアへのユーザが認識可能なインタフェースは、Avalon スレーブ・ポートを介してアクセスされる 2つの 32ビット・レジスタ、dataおよび controlで構成されています。Nios IIプロセッサなどの Avalonマスタは、レジスタにアクセスしてコアを管理し、さらに JTAG接続によってデータを転送します。コアは一度に 8 ビット単位のデータを操作します。つまり、data レジスタの 8ビットが 1キャラクタのペイロードとして機能します。

JTAG UART コアは、リード・データが利用可能になるか、またはライト FIFO がデータ操作可能になると、割り込みを要求できるアクティブHigh 割り込み出力を供給します。詳細については、5–15 ページの「割り込み動作」を参照してください。

オンチップ・ロジックへの

Avalon スレーブ・

インタフェース

JTAG UARTコア

レジスタ

JTAGハブ・インタフェース

IRQ

アルテラFPGAの内蔵機能

書き込みFIFO

読み出しFIFO

Data

ControlJTAGハブ

ホストPCへのJTAG接続

アルテラFPGA

JTAGインタフェースを使用するその他ノード（別のJTAG UARTなど）

TC

K

TD

I

TD

O

TM

S

TR

ST

JTAG コントローラ

Quartus IIによって自動的に生成

Altera Corporation 5–32006年 5月 Quartus IIハンドブック Volume 5

Avalonインタフェース対応 JTAG UARTコア

リードおよびライト FIFOJTAG UARTコアは双方向 FIFOを提供し、JTAG接続での帯域幅を改善しています。FIFOの深さは、利用可能なオンチップ・メモリに応じてパラメータ化可能です。FIFOはメモリ・ブロックまたはレジスタで構成でき、設計者は必要に応じてロジック・リソースとメモリ・ブロックのトレードオフを図ることができます。

JTAGインタフェースアルテラ FPGAには、デバイスの JTAGピンをデバイス内部のロジックにインタフェースする JTAG コントロール回路が内蔵されています。JTAG コントローラは、FPGA に実装される「ノード」と呼ばれるユーザ定義回路に接続できます。JTAG インタフェースを介した通信を必要とするノードが複数存在する可能性があるため、JTAGハブ（つまり、マルチプレクサ）が必要になります。ロジックの合成およびフィッティングの中に、Quartus® IIソフトウェアは JTAGハブ・ロジックを自動的に生成します。デバイス内部の JTAG回路への接続に、デザインを手作業で仕上げる必要はありません。ここでは、説明を明確にするために取り上げています。

ホスト・ターゲット接続

図 5-2に、ホスト PCと、SOPC Builderで生成された JTAG UARTコア搭載のシステムとの接続を示します。


機能の説明

図 5-2. JTAG UARTコアを使用するシステムの例

FPGA 上の JTAG コントローラとホスト PC上のダウンロード・ケーブル・ドライバによって、ホストとターゲット間にシンプルなデータ・リンク・レイヤが実装されます。FPGA内部のすべての JTAGノードは、1つの JTAG接続によって多重化されます。ホスト PC上の JTAGサーバ・ソフトウェアは、JTAG データ・ストリームの制御とデコードを行い、FPGA内部のノードとの接続を識別可能な状態に維持します。

図 5-2 に示すシステム例には、1 つの JTAG UART コアと Nios II プロセッサが含まれています。どちらのエージェントも、1 本のアルテラ・ダウンロード・ケーブルを介してホスト PC と通信します。JTAG サーバ・ソフトウェアによって、各ホスト・アプリケーションは独立してターゲットに接続することができます。アルテラは、JTAG UART コアとの通信に必要な JTAGサーバ・ドライバとホスト・ソフトウェアを提供しています。

複数の JTAG UARTコアを搭載したシステムを構築することも可能で、すべてのコアは同じ JTAGインタフェースを介して通信します。一貫性のあるデータ・ストリームを維持するには、1 つのプロセッサのみが各JTAG UARTコアと通信する必要があります。

デバッグ・データ

PC インタフェース JTAG

ホストPC

アルテラFPGA

JTA

G

コントローラ

JTA

G

ハブJTAG

サーバ

ダウンロード・ケーブル・ドライバ

アルテラ・ダウンロード・ケーブル

JTAG デバッグ・モジュール

JTAGUART

Avalon スイッチ・ファブリック

キャラクタ・ストリーム

デバッガ

C

JTAGターミナル

Nios II プロセッサ

オンチップ・メモリ

M

S S

M

S

Avalonマスタ・ポート

Avalonスレーブ・ポート



デバイスおよびツールのサポート

JTAG UARTコアは、Stratix®、Stratix II、Cyclone™および Cyclone IIデバイス・ファミリをサポートしています。JTAG UART コアは、Nios IIHAL（Hardware Abstraction Layer）システム・ライブラリによってサポートされます。第 1 世代の Nios プロセッサに対しては、ソフトウェア・サポートは提供されません。

ホスト PC 上でキャラクタ・ストリームを確認するには、JTAG UARTコアをアルテラが提供する JTAGターミナル・ソフトウェアと連携して使用する必要があります。Nios IIプロセッサ・ユーザは、Nios II IDEまたは nios2-terminalコマンドライン・ユーティリティを使用して JTAGUARTにアクセスします。

詳細については、「Nios IIソフトウェア開発ハンドブック」またはNios IIIDEのオンライン・ヘルプを参照してください。

SOPC Builderでのコアのインスタンス化

設計者は、JTAG UARTコアの SOPC Builderコンフィギュレーション・ウィザードを使用して、コアの機能を指定します。以下のセクションでは、コンフィギュレーション・ウィザードで選択可能なオプションについて説明します。

Configurationタブこのタブのオプションは、JTAG UART コアのハードウェア・コンフィギュレーションを制御します。デフォルト設定は、アルテラ提供のデバイス・ドライバおよび JTAGターミナル・ソフトウェアと併用すれば最適に動作するように、事前にコンフィギュレーションされています。ほとんどの場合、Construct using registers instead of memory blocksオプションを除いて、デフォルト設定を変更する必要はありません。

ライト FIFO設定

ライト FIFOは、Avalonインタフェースからホストに流れるデータをバッファリングします。以下の設定が選択できます。

■ Depth－ライトFIFOの深さは、8バイトから32,768バイトの間で設定できます。許容値は 2 のべき乗のみです。値を大きくすれば、オンチップ・メモリ・リソースの消費も増大します。一般に、深さ 64が性能面で最適であり、これより大きな値が必要になるケースはほとんどありません。


SOPC Builderでのコアのインスタンス化

■ IRQ Threshold－書き込み IRQスレッショルドは、FIFOが空になったとき、それに応答してコアが IRQ をアサートする方法を管理します。JTAG回路がライト FIFOからデータを消去するときに、FIFOに残っているキャラクタ数がこのスレッショルド値に達すると、コアは対応する IRQ をアサートします。帯域幅の効率を最大にするために、プロセッサはより多くのデータを書き込み、ライト FIFOが完全に空にならないようにして、割り込みを処理する必要があります。一般に、この値は 8 が最適です。詳細については、5–15 ページの「割り込み動作」を参照してください。

■ Construct using registers instead of memory blocks－このオプションをオンにすると、FIFO はメモリ・リソースなしで構成されます。このオプションはメモリ・リソースが限定される場合に役立ちます。各バイトは 11 個程度のロジック・エレメント（LE）を消費するため、FIFOの深さを 8（バイト）にすると、約 88個のLEが消費されます。

リード FIFO設定

リード FIFOは、ホストから Avalonインタフェースに流れるデータをバッファリングします。FIFOの深さと割り込み生成を制御する設定が用意されています。

■ Depth－リードFIFOの深さは、8バイト～32,768バイトに設定できます。許容値は 2のべき乗のみです。値を大きくすれば、オンチップ・メモリ・リソースの消費も増大します。一般に、深さ 64が性能面で最適であり、これより大きな値が必要なことはほとんどありません。

■ IRQ Threshold－ IRQスレッショルドは、FIFOが満杯になったとき、それに応答してコアが IRQをアサートする方法を管理します。JTAG回路がリード FIFO にデータを満たすときに、FIFO の空き容量がこのスレッショルドに達すると、コアは対応する IRQ をアサートします。帯域幅の効率を最大にするために、プロセッサはデータを読み出し、リード FIFOが完全に満杯にならないようにして、割り込みを処理する必要があります。一般に、この値は 8 が最適です。詳細については、5–15ページの「割り込み動作」を参照してください。

■ Construct using registers instead of memory blocks－このオプションをオンにすると、FIFO はメモリ・リソースなしで構成されます。このオプションはメモリ・リソースが限定される場合に役立ちます。各バイトは 11個程度の LEを消費するため、FIFOの深さを 8（バイト）にすると、約 88個の LEが消費されます。



シミュレーション設定

システム生成時に SOPC Builderが JTAG UARTコアのロジックを生成する場合は、同時にシミュレーション・モデルも構築されます。シミュレーション・モデルを利用すれば、JTAG UART コアを使用するシステムのシミュレーションが簡略化されます。シミュレーション設定を変更しても、ハードウェアのコアの動作には影響ありません。設定は機能シミュレーションにのみ作用します。

入力キャラクタ・ストリームのシミュレート

ユーザはシミュレートされたシステム・リセットで、リード FIFO への入力がシミュレートされるキャラクタ・ストリームを入力することができます。コンフィギュレーション・ウィザードは任意のキャラクタ文字列を受け取り、後でこの文字列がテスト・ベンチに送られます。リセット後、このキャラクタ文字列はリード FIFO 内で事前に初期化され、外部 JTAGターミナル・プログラムが JTAG UARTコアにキャラクタ・ストリームを送信している状況を作り出します。

インタラクティブ・ウィンドウの準備

システム生成時に JTAG UARTコア・ジェネレータは、シミュレーション中にインタラクティブ・ウィンドウを開くModelSimマクロを作成できます。これらのウィンドウにより、ユーザはコンソール経由で ASCIIキャラクタを送受信できるため、ハードウェア内で実行中のシステムとのターミナル・セッション状況が作られます。以下のオプションが用意されています。

■ Do not generate ModelSim aliases for interactive windows－このオプションを選択すると、キャラクタ I/O用の ModelSimマクロは作成されません。

■ Create ModelSim alias to open a window showing output as ASCIItext－このオプションを選択すると、ライト FIFOからの出力を表示するコンソール・ウィンドウを開く ModelSim マクロが作成されます。Avalon インタフェースを介してライト FIFO に書き込まれる値は、ASCIIキャラクタとしてコンソールに表示されます。


ハードウェア・シミュレーションの考慮点

■ Create ModelSim alias to open an interactive stimulus/responsewindow－このオプションを選択すると、コアと入力および出力の相互作用を可能にするコンソール・ウィンドウを開く ModelSim マクロが作成されます。Avalon インタフェースを介してライト FIFOに書き込まれる値は、ASCII キャラクタとしてコンソールに表示されます。コンソールに入力した値は、リード FIFOに送られ、Avalonインタフェースを介して読み出すことができます。このオプションをオンにすると、シミュレートされたキャラクタ入力ストリーム・オプションは無視されます。

ハードウェア・シミュレーションの考慮点

シミュレーション機能は、ModelSim シミュレータの使用時に、Nios IIプロセッサ・システムを簡単にシミュレーションするためのものです。シミュレーション・モデルは JTAG UARTコアのトップレベルHDLファイルに実装されます。合成可能な HDL およびシミュレーション HDLは、同じファイルに実装されます。一部のシミュレーション機能は、HDLコードの特定のセクションを合成ツールに対してのみ開示する「translate on/off」合成オプションを使用して実装されます。

Nios IIシステムでの JTAG UARTコアのシミュレーションの詳細については、「AN 351: Simulating Nios II Processor Designs」を参照してください。

その他のシミュレータも使用できますが、その場合はユーザがカスタム・シミュレーション・プロセスを作成する必要があります。自動生成されたModelSimスクリプトを参考にして、その他のシミュレータの類似機能を作成することができます。

アルテラの推奨シミュレーション手順を使用する場合は、シミュレーション・オプションを編集しないでください。シミュレーション・オプションを変更してカスタム・シミュレーション・フローを作成する場合は、SOPC Builderがシステム生成時に既存のファイルを上書きすることに留意する必要があります。変更内容が上書きされないよう注意してください。

ソフトウェア・プログラミング・モデル

以下のセクションでは、ハードウェアにアクセスするためのレジスタ・マップやソフトウェア宣言など、JTAG UART コアのソフトウェア・プログラミング・モデルについて説明します。アルテラは、Nios II プロセッサ・ユーザ向けに printf()や getchar()などの ANSI C標準ライブラリ関数を使用して、JTAG UARTへのアクセスを可能にするHALシステム・ライブラリ・ドライバを提供しています。



HALシステム・ライブラリ・サポートアルテラが提供するドライバは、Nios II システム用の HAL システム・ライブラリに統合される HAL キャラクタ・モード・デバイス・ドライバを実装します。HALユーザは、JTAG UARTレジスタにアクセスせずに使い慣れた HAL API および ANSI C 標準ライブラリを介して JTAGUARTにアクセスすることができます。HALユーザによる JTAG UARTのハードウェア依存部分の制御を可能にする、ioctl()要求が定義されています。

ユーザ・プログラムで、アルテラ提供の HAL デバイス・ドライバを使用して JTAG UART ハードウェアにアクセスする場合、デバイス・レジスタに直接アクセスすると、ドライバの正常な動作が妨害されます。

Nios IIプロセッサ・ユーザ向けに、HALシステム・ライブラリ APIは、JTAG UARTコアの機能への完全なアクセスを提供します。Nios IIプログラムは、JTAG UART コアをキャラクタ・モード・デバイスとして扱い、getchar()や printf()などの ANSI C標準ライブラリ関数を使用して、データを送受信します。

JTAG UARTコアへの stdoutとしてのキャラクタの出力に、printf()を使用してstdoutにメッセージを出力する最もシンプルな使用法を示します。この例では、SOPC Builderシステムに JTAG UARTコアが搭載され、HALシステム・ライブラリは、この JTAG UARTデバイスを stdoutに使用するようにコンフィギュレーションされています。

JTAG UARTコアへのコアへのコアへのコアへの stdoutとしてのキャラクタの出力としてのキャラクタの出力としてのキャラクタの出力としてのキャラクタの出力

#include <stdio.h>int main (){ printf("Hello world.\n"); return 0;}

5–10ページの「JTAG UARTコアへのキャラクタの転送」は、C標準ライブラリを使用して、JTAG UART コアからキャラクタを読み出す方法と、JTAG UART コアへメッセージを送信する方法を示します。この例では、SOPC Builder システムには、jtag_uart という名前の JTAGUARTコアが搭載されていますが、これは必ずしも stdoutデバイスとしてコンフィギュレーションされるとは限りません。この場合、プログラムはこのデバイスを HAL ファイル・システムの他のノードと同じように扱います。



JTAG UARTコアへのキャラクタの転送コアへのキャラクタの転送コアへのキャラクタの転送コアへのキャラクタの転送

/* キャラクタ「t」と「v」を認識するシンプルなプログラム */#include <stdio.h>#include <string.h>int main (){ char* msg = "Detected the character 't'.\n"; FILE* fp; char prompt = 0;

fp = fopen ("/dev/jtag_uart", "r+"); // 読み出しと書き込み用にファイルを開く。 if (fp) { while (prompt != 'v')

{ // 「v」を受信するまでループする。 prompt = getc(fp); // JTAG UARTからキャラクタを取得する。 if (prompt == 't')

{ // キャラクタが「t」なら、メッセージを出力する。 fwrite (msg, strlen (msg), 1, fp); }

if (ferror(fp))// ファイル・ポインタにエラーが発生していないかどうかチェックする。 clearerr(fp);// エラーがあればクリアする。 }

fprintf(fp, "Closing the JTAG UART file handle.\n"); fclose (fp); } return 0;}

この例では、JTAG 接続の切断など、JTAG UART 接続でエラーが発生していないかどうかをチェックするために、ferror(fp)を使用しています。この場合、ドライバは JTAG接続が切断されたことを検出し、エラー（EIO）をレポートし、以降のトランザクション用のデータを破棄します。このエラーが発生すると、Cライブラリはユーザがclearerr()

関数を使用して明示的にクリアするまで、この値をラッチします。

HAL システム・ライブラリの詳細については、「Nios II ソフトウェア開発ハンドブック」で解説しています。Nios II開発キットには、JTAG UARTコアを使用するソフトウェア・デザイン例が多数用意されています。



ドライバ・オプション：高速および小型サイズの実装

多様なタイプのシステムの要件に対応するために、JTAG UART ドライバには高速バージョンと小型バージョンの 2 種類が用意されています。デフォルトでは、高速型動作が使用されます。高速ドライバと小型ドライバのどちらも、C 標準ライブラリ関数と HAL API を完全にサポートしています。

高速ドライバは割り込み駆動で実行されるため、デバイスがデータの送信または受信の準備が整っていないときにも、プロセッサは他のタスクを実行できます。JTAG UART のデータ・レートはプロセッサと比較して低速なため、一時的に他のタスクを実行する可能性があるシステムに対しては、高速ドライバによって大きな性能上の利点が得られます。さらに、アルテラ Avalon JTAG UART の高速バージョンは、ホストへの接続をモニタします。ホストが接続されていない場合、またはホストがI/Oストリームを処理するアプリケーションを実行していない場合、ドライバはキャラクタを破棄します。

小型ドライバは、各キャラクタを送受信する前に JTAG UART ハードウェアを待機するポーリング形式の実装です。小型ドライバの性能は、大容量のデータを送信すると低下します。小型バージョンでは、ホストが常に接続されていること、およびホストがキャラクタを破棄しないことを想定しています。したがって、プログラムがデータを送信または受信している間に、JTAG UART ハードウェアがホストから切断された場合、小型ドライバはシステムのハングアップを引き起こします。スモール・フットプリント・ドライバを有効にするには、以下の 2つの方法があります。

■ HALシステム・ライブラリ・プロジェクトのスモール・フットプリント設定をオンにします。このオプションは、システム内のすべてのデバイスのデバイス・ドライバにも作用します。

■ プリプロセッサ・オプション-DALTERA_AVALON_JATAG_UART_SMALLを指定します。このオプションを使用すると、他のデバイスのドライバに影響を与えずに、小型の JTAG UARTドライバをポーリング形式で実装できます。



ioctl()操作

JTAG UARTドライバの高速バージョンは、ioctl()関数をサポートしているため、HAL ベースのプログラムはデバイス固有の操作を要求できます。具体的には、ioctl() 操作は、タイムアウト周期を制御したり、ホストが接続されているかどうかを検出するために使用できます。高速ドライバでは、ioctl()操作は表 5–1に示すとおり定義されています。

ioctl()関数の詳細については、「Nios IIソフトウェア開発ハンドブック」を参照してください。

ソフトウェア・ファイル

JTAG UART コアには、以下のソフトウェア・ファイルが付属しています。これらのファイルは、ハードウェアへの低水準インタフェースを定義し、HALドライバを提供します。アプリケーション開発者がこれらのファイルを変更してはなりません。

■ altera_avalon_jtag_uart_regs.h－このファイルは、コアのレジスタ・マップを定義し、低水準ハードウェアにアクセスするための記号定数を提供します。このファイル内の記号は、デバイス・ドライバ関数によってのみ使用されます。

■ altera_avalon_jtag_uart.h、altera_avalon_jtag_uart.c－これらのファイルは、HALシステム・ライブラリ・デバイス・ドライバを実装します。

表 5–1.高速ドライバ専用の JTAG UART ioctl()操作

要求意味

TIOCSTIMEOUT ドライバがホストが接続されていないと判断するまでのタイムアウト（秒単位）を設定します。タイムアウトを 0にすると、ターゲットはホストが常時接続されているとみなします。渡される ioctlの argパラメータは、整数へのポインタである必要があります。

TIOCGCONNECTED 整数 argパラメータは、ホストが接続されターミナルとして動作している（1）か、または接続されていない（0）かを示す値に設定します。渡される ioctlの argパラメータには、整数へのポインタである必要があります。



ホスト PCを介した JTAG UARTコアへのアクセスPC から JTAG UART コアにアクセスするには、ホスト・ソフトウェアが必要です。Nios II IDEは、JTAG UARTコアをサポートし、コンソール・ウィンドウにキャラクタ I/Oを表示します。また、アルテラは JTAGUARTコアとのターミナル・セッションをオープンする、nios2-terminalと呼ばれるコマンドライン・ユーティリティもサポートしています。

詳細については、「Nios II ソフトウェア開発ハンドブック」と Nios IIIDEのオンライン・ヘルプを参照してください。

レジスタ・マップ

HAL APIを使用するプログラマが、JTAG UARTコアに対応するレジスタを介して直接アクセスすることはありません。一般に、レジスタ・マップはコアのデバイス・ドライバを記述するプログラマにとってのみ有用です。

アルテラが提供する HAL デバイス・ドライバは、デバイス・レジスタに直接アクセスします。デバイス・ドライバを記述する場合に、HALドライバが同じデバイスに対してアクティブであれば、記述したドライバは衝突して、動作できません。

表 5–2に、JTAG UARTコアのレジスタ・マップを示します。デバイス・ドライバは、2つの 32ビット・メモリ・マップド・レジスタを介してコアの制御と通信を行います。

表 5–2. JTAG UARTコアのレジスタ・マップ

オフセット

レジスタ名 R/Wビットの説明

31 ... 16 15 14 ... 11 10 9 8 7 ... 2 1 00 data RW RAVAIL RVALID (1) DATA

1 control RW WSPACE (1) AC WI RI (1) WE RE

表 5–2の注：(1) 予約読み出し値は不定です。ゼロを書き込みます。



dataレジスタ

エンベデッド・ソフトウェアは、dataレジスタを介してリード FIFOおよびライト FIFO にアクセスします。表 5–3 で、各ビットの機能を説明します。

data レジスタからの読み出しでは、FIFO（利用可能な場合）から最初のキャラクタが DATA フィールドに返されます。また、読み出しではFIFOに残ったキャラクタ数に関する情報が RAVAILフィールドに返されます。data レジスタに書き込むと、DATA フィールドの値がライトFIFOに格納されます。ライト FIFOが満杯の場合、キャラクタは失われます。

controlレジスタ

エンベデッド・ソフトウェアは、control レジスタを介して、JTAGUARTコアの割り込み生成と読み出しステータス情報を制御します。表5–4に、各ビットの機能を説明します。

表 5–3. dataレジスタのビット

ビット番号ビット /

フィールド名

読み出し（R）/書き込み（W）/クリア（C）

説明

0 .. 7 DATA R/W JTAGコアとの間で転送する値。書き込みの場合、DATAフィールドはライト FIFO に書き込まれるキャラクタです。読み出しの場合、DATAフィールドはリード FIFOから読み出されるキャラクタです。

15 RVALID R DATAフィールドが有効かどうかを示します。RVALID=1の場合、DATA フィールドは有効、その他の場合は不定です。

16 .. 32 RAVAIL R リード FIFO に残っているキャラクタの数（この読み出し後）。

表 5–4. controlレジスタのビット (１ /２ )


フィールド名


説明

0 RE R/W リード割り込み用の割り込みイネーブル・ビット。

1 WE R/W ライト割り込み用の割り込みイネーブル・ビット。



controlレジスタから読み出すと、リード FIFOおよびライト FIFOのステータスが返されます。レジスタへの書き込みは、割り込みイネーブル /ディセーブル、または ACビットのクリアに使用できます。

REビットとWEビットはそれぞれ、リード FIFOとライト FIFOに対する割り込みをイネーブルします。WIビットと RIビットは、割り込みイネーブル・ビット（WEと RE）の値によって有効になる割り込みソースのステータスを示します。エンベデッド・ソフトウェアは、RIとWIを調べて、どの条件で IRQが生成されたかを判断できます。詳細については、5–15ページの「割り込み動作」を参照してください。

ACビットは、ホスト PC上のアプリケーションが、JTAGインタフェースを介して JTAG UARTコアをポーリングしたことを示します。ACビットは一度設定されると、Avalon インタフェースを介して明示的にクリアされるまで設定状態のままです。AC に 1 を書き込むと、クリアされます。エンベデッド・ソフトウェアは、ACビットを調べてホスト PCへの接続が存在するかどうかを判断できます。接続が存在しない場合、ソフトウェアは JTAGデータ・ストリームを無視するように選択できます。ホスト PC に転送するデータがない場合は、1 秒に 1 回の低い頻度で、JTAG UART コアをポーリングするように選択できます。JTAG ダウンロード・ケーブルを使用するその他のホスト・ソフトウェアによって遅延が発生すると、ポーリング間で最大 10秒間の遅延が発生することがあります。

割り込み動作

JTAG UART コアは、個々の割り込み条件のいずれかがペンディングされイネーブルされると、割り込みを生成します。

8 RI R リード割り込みがペンディング中であることを示します。

9 WI R ライト割り込みがペンディング中であることを示します。

10 AC R/C ビットのクリア以降に、JTAGアクティビティが発生したことを示します。ACに 1を書き込むと、0にクリアされます。

16 .. 32 WSPACE R ライト FIFO内で利用できるスペースの数。

表 5–4. controlレジスタのビット (２ /２ )


フィールド名


説明



デバイス・ドライバのプログラマは、ホスト PCに対する帯域幅性能を重視する場合には、割り込み動作を考慮する必要があります。Nios II 開発キットに付属するデザイン例と JTAG ターミナル・プログラムは、事前に最適な割り込み動作でコンフィギュレーションされています。

JTAG UARTコアには、ライト割り込みとリード割り込みの 2種類の割り込みがあります。controlレジスタのWEビットと REビットは、割り込みをイネーブル /ディセーブルします。

ライト FIFO がほぼ空になると、コアはライト割り込みをアサートできます。「ほぼ空」のスレッショルド値、write_thresholdは、システム生成時に指定され、エンベデッド・ソフトウェアでは変更できません。ライト FIFO に存在するキャラクタの数が write_threshold 以下であれば、ライト割り込み状態が設定されます。この状態は、ライト FIFOにwrite_threshold を超えるキャラクタ数を入れるとクリアされます。エンベデッド・ソフトウェアは、ライト FIFO を充填した後でのみライト割り込みをイネーブルしなければなりません。送信するキャラクタが残っていない場合、エンベデッド・ソフトウェアはライト割り込みをディセーブルする必要があります。

リード FIFO がほぼ満杯になると、コアはリード割り込みをアサートできます。「ほぼ満杯」のスレッショルド値、read_threshold は、システム生成時に指定され、エンベデッド・ソフトウェアでは変更できません。リード FIFOに残っているスペースが、read_threshold以下になると、リード割り込み条件が設定されます。また、リード割り込み条件は、リードFIFOに最低 1つのキャラクタが存在し、それ以上のキャラクタが充填されないと予想される場合にも設定されます。リード割り込みは、リードFIFOからキャラクタを読み出すとクリアされます。

最適な性能を得るには、割り込みスレッショルドがエンベデッド・ソフトウェアの割り込み応答時間に一致しなければなりません。例えば、JTAGクロックが 10 MHzの場合、ホスト PCによって 1µ秒ごとに新しいキャラクタが供給（消費）されます。スレッショルドが 8の場合、割り込み応答時間は 8µより小さくする必要があります。割り込み応答時間が長すぎると性能が低下します。短すぎる場合は、必要以上の頻度で割り込みが発生します。

Nios II プロセッサ・システムの場合、リードおよびライト・スレッショルドは 8が適切なデフォルト値です。

5. avalon インタフェース対応...5–2 altera corporation quartus ii ハンドブックvolume...

Documents