このセクションには、Nios® II プロセッサに関する情報が記載されてい ます。 このセクションは、以下の章で構成されています。 ■ 第1 章 概要 ■ 第2 章 プロセッサ・アーキテクチャ ■ 第3 章 プログラミング・モデル
Nios II プロセッサ Nios II プロセッサ・リファレンス・ハンドブック
改訂履歴
以下の表に、第1 章∼第 4 章の改訂履歴を示します。これらのバージョン 番号は資料の改訂を追跡しているのもので、Nios II 開発キットや Nios II プロセッサのバージョン番号には関係ありません。 章 日付 / バージョン 変更内容 1 2004 年 9 月、v1.1 Nios II 1.01 リリースのために更新。 2004 年 5 月、 v1.0 初版 2 2004 年 12 月、v1.2 新しいコントロール・レジスタctl5 を追加。 2004 年 9 月、v1.1 Nios II 1.01 リリースのために更新。 2004 年 5 月、v1.0 初版 3 2004 年 9 月、v1.1 ● 新しいコントロール・レジス タctl5の詳細を追加。 ● breakインストラクションの 新しい動作を反映したデバッ グ・モードおよびブレイク・ プロセッシングの詳細を更新。 2004 年 5 月、v1.0 初版 4 2004 年 9 月、v1.1 ● Nios II プロセッサ・バージョ ン 1.1 の新規 GUI オプション を反映した更新。 ●「乗算および除算設定」の項の 新規の詳細説明。 2004 年 5 月、v1.0 初版この資料は更新された最新の英語版が存在します。こちらの日本語版は参考用としてご利用ください。 設計の際には、最新の英語版で内容をご確認ください。
はじめに
この章では、Nios®II エンベデッド・プロセッサ・ファミリについて説 明します。ハードウェア・エンジニアおよびソフトウェア・エンジニア が、Nios II プロセッサと従来型のエンベデッド・プロセッサの類似点と 相違点を理解するのに役立ちます。Nios II プロセッサ・システムの基礎知識
Nios II プロセッサは、以下の機能を備えた汎用 RISC プロセッサ・コア です。 ■ 完全な32 ビット命令セット、データ・パス、およびアドレス空間 ■ 32 個の汎用レジスタ ■ 32 個の外部割り込みソース ■ 32 ビットの演算結果を生成する単一命令の 32×
32 乗算および除算 ■ 乗算の64 ビットおよび 128 ビット積を計算するための専用命令 ■ 単一命令バレル・シフタ ■ 各種オンチップ・ペリフェラルへのアクセスおよびオフチップ・メ モリやペリフェラルへのインタフェース ■ 統合開発環境（IDE）制御のもとで、プロセッサの起動、停止、ス テップ、およびトレースを可能にするハードウェア支援デバッグ・モ ジュール■ GNU C/C++ ツール・チェインおよび Eclipse IDE をベースにしたソ フトウェア開発環境 ■ すべての Nios II プロセッサ・システム間で互換性のある命令セット・ アーキテクチャ（ISA） ■ 150 DMIPS を上回る性能 Nios II プロセッサ・システムは、シングル・チップ上に CPU とペリフェ ラルおよびメモリを組み合わせて搭載したマイクロコントローラまたは コンピュータ・オンチップに相当します。「Nios II プロセッサ・システ ム」という用語は、Nios II プロセッサ・コア、オンチップ・ペリフェラ ルのセット、オンチップ・メモリ、およびオフチップ・メモリへのイン タフェースを意味し、これらはすべて1 個のアルテラ・チップに実装さ れています。マイクロコントローラ・ファミリと同様に、すべてのNios II プロセッサ・システムは一貫した命令セットとプログラミング・モデル を使用しています。 NII51001-1.0
はじめに
Nios II プロセッサの使用開始
Nios II プロセッサの使用開始方法は、他のマイクロコントローラ・ファ ミリの場合とほとんど同じです。既製の評価ボードとNios II ソフトウェ アの作成に必要なすべてのソフトウェア開発ツールを含んだ開発キット をアルテラから購入すれば、最も簡単に効率よく設計を開始することが できます。Nios II ソフトウェア開発環境は、Nios II 統合開発環境（IDE）と呼ばれ ます。Nios II IDE は、GNU C/C++ コンパイラと Eclipse IDE をベース にしており、確立された一般的なソフトウェア開発環境を実現していま す。Nios II IDE を使用すれば、設計者はすぐに Nios II ソフトウェア・ アプリケーションの開発およびシミュレーションを開始することができ ます。アルテラ開発キットに付属の Nios II ハードウェア・リファレン ス・デザインを使用すれば、カスタム・ハードウェア・プラットフォー ムを構築する前に、ボードで動作するアプリケーションのプロトタイプ を作成できます。図 1-1に、アルテラのNios II 開発キットで利用できる Nios II プロセッサ・リファレンス・デザインの例を示します。 図 1-1. Nios II プロセッサ・システムの例 Nios II プロセッサ・コア SDRAM コントローラ オンチップROM オフチップ・メモリへの トライステート・ブリッジ Av a lon スイッチ・ファブリック JTAG デバッグ・ モジュール SDRAM メモリ フラッシュ・ メモリ SRAM メモリ UART タイマ1 タイマ2 LCDディスプレイ・ ドライバ 汎用I/O イーサネット・ インタフェース CompactFlash インタフェース LCD 画面 イーサネット MAC/PHY コンパクト・ フラッシュ ボタン、 LEDなど 送信 受信 ソフトウェア・デバッガ とのJTAG接続 クロック リセット データ 命令
アルテラ提供のリファレンス・デザインを使用して、プロトタイプ・シ ステムがデザイン要件を十分に満たす場合は、そのリファレンス・デザ インをコピーして、最終ハードウェア・プラットフォームでそのまま使 用できます。そうでない場合でも、設計者はコストや性能の要求を満た すように、Nios II プロセッサ・システムをカスタマイズできます。
Nios II プロセッサ・デザインのカスタマイズ
アルテラFPGA は、プロセッサ・システムの機能の追加と性能強化を可 能にする柔軟性を実現しています。一方で、不要なプロセッサ機能とペ リフェラルを削除して、デザインをより小型で低コストのデバイスに適 合させることが可能です。 アルテラ・デバイスのピンおよびロジック・リソースは変更可能なため、 以下のような多数のカスタマイズを実行できます。 ■ ボード・デザインがより簡単になるようにチップのピンを再配置で きます。例えば、外部SDRAM メモリ用のアドレス・ピンとデータ・ ピンをチップの任意の側面に移動して、ボード・トレースを短くす ることができます。 ■ チップの余分なピンとロジック・リソースは、プロセッサに関係の ない機能に使用できます。余分なリソースはボード・デザイン用の 「グルー・ロジック」として何個かのゲートやレジスタに利用したり、 あるいはシステム全体を実装することも可能です。例えば、Nios II プロセッサ・システムは大規模なアルテラFPGA の 5% しか消費し ないため、残りのチップ・リソースを利用して他の機能を実装する ことができます。 ■ チップの余分なピンとロジックは、Nios II プロセッサ・システム用 の追加ペリフェラルの実装に使用できます。アルテラは、Nios II プ ロセッサ・システムに容易に接続可能な多数のペリフェラル・ライ ブラリを提供しています。 実際に、大部分のFPGA デザインでは、Nios II プロセッサ・システムに 加えて、何らかのロジックが実装されています。プログラマがNios II プ ロセッサを使用する場合、追加ロジックに配慮する必要はありません。コンフィギュレーション可能なソフトコア・プロセッサの概念
コンフィギュ
レーション可
能なソフトコ
ア・プロセッ
サの概念
このセクションでは、ディスクリート・マイクロコントローラとは異な る Nios II 特有の概念について説明します。以下に述べる概念は、他の 機能を述べる際の基礎情報となるため、ここで説明しています。 これらの概念の大半は、ハードウェア設計者がシステム実装を微調整す るための柔軟性に関するものです。ソフトウェア・プログラマは、一般 にハードウェア実装の詳細を考慮する必要はなく、またNios II プロセッ サ・コアのコンフィギュレーション可能な特性を意識しなくてもプログ ラムを記述できます。コンフィギュレーション可能なソフトコア・プロセッサ
Nios II プロセッサは、固定された市販のマイクロコントローラとは異な り、コンフィギュレーション可能なソフトコア・プロセッサです。ここ で、「コンフィギュレーション可能」とは、性能目標または価格目標を満 たすためにシステム単位で機能を追加または削除できることを意味しま す。「ソフトコア」とは、CPU コアが「ソフト」デザイン形式（つまり、 シリコンに固定されない）で提供され、どのアルテラFPGA ファミリで もターゲットにできることを意味します。言い換えれば、アルテラは 「Nios II チップ」を販売するのではなく、ブランクの FPGA を販売して います。Nios II プロセッサとペリフェラルを仕様に合わせて構成し、シ ステムをアルテラFPGA にプログラムするのはユーザです。 コンフィギュレーション可能であることは、設計者が新規デザインごと に新しい Nios II プロセッサの構成を作成しなければならないという意 味ではありません。アルテラは、システム設計者がそのまま使用できる 既製の Nios II システムを提供しています。これらのデザインがシステ ム要求を満たす場合は、デザインをそれ以上構成する必要はありません。 また、ソフトウェア設計者は、最終的なハードウェア・コンフィギュレー ションが確定する前に、Nios II インストラクション・セット・シミュ レータを使用して、Nios II アプリケーションの記述とデバッグを開始す ることができます。柔軟なペリフェラル・セットとアドレス・マップ
Nios II プロセッサ・システムと固定マイクロコントローラとの最も顕著 な違いの1 つは、柔軟性に優れたペリフェラル・セットです。Nios II プ ロセッサは本質的にソフトコアなので、ターゲット・アプリケーション に必要なペリフェラル・セットを確実に備えた独自の Nios II プロセッ サ・システムを容易に構築できます。ペリフェラルが柔軟性に優れているため、結果的にアドレス・マップも 柔軟なものになります。ソフトウェアの構造は、アドレス位置に関係な く、総称的にメモリやペリフェラルにアクセスできるように構築されま す。したがって、アプリケーション開発者がペリフェラル・セットとア ドレス・マップの柔軟性を考慮する必要はありません。 ペリフェラルは、標準ペリフェラルとカスタム・ペリフェラルの2 つの 大きなクラスに分類できます。 標準ペリフェラル アルテラは、タイマ、シリアル通信インタフェース、汎用I/O、SDRAM コントローラ、その他のメモリ・インタフェースなど、マクロコントロー ラで広く使用されるペリフェラル・セットを提供しています。アルテラ とサードパーティ・ベンダは随時、新しいソフト・ペリフェラル・コア をリリースしており、利用可能なペリフェラル・リストもますます充実 したものとなっています。 カスタム・ペリフェラル 設計者は、独自のカスタム・ペリフェラルを作成して、Nios II プロセッ サ・システムに統合することもできます。性能が重視され、大部分の CPU サイクルがコードの特定のセクションの実行に消費されるシステ ムの場合、一般的な手法はハードウェアで同じ機能を実行するカスタム・ ペリフェラルを作成することです。この方法では、性能面で二重の利点 が得られます。つまり、ハードウェアでの実行がソフトウェアよりも高 速になること、そしてカスタム・ペリフェラルがデータを操作する間に、 プロセッサは並行して他の機能を実行できることです。
カスタム命令
カスタム・ペリフェラルと同様に、カスタム命令はプロセッサをカスタ ム・ハードウェアで増強することによって、システム性能を向上させる ための手段です。Nios II プロセッサのソフトコア特性により、設計者は カスタム・ロジックを論理演算ユニット（ALU）に統合できます。Nios II 固有の命令と同様に、カスタム命令ロジックは、最大2 個のソース・レ ジスタから値を取得し、選択によって結果をディスティネーション・レ ジスタに書き込むことができます。 カスタム命令を使用して、性能目標に適合するようにシステム・ハード ウェアを微調整することができます。プロセッサは再プログラム可能な アルテラFPGA に実装されるため、ソフトウェア・エンジニアとハード ウェア・エンジニアが連携して作業を進め、繰り返しハードウェアの最 適化を行い、実際のハードウェア上でのソフトウェアの実行結果をテス トできます。コンフィギュレーション可能なソフトコア・プロセッサの概念 ソフトウェアの観点からすれば、カスタム命令はマシンで生成されたア センブリ・マクロまたはC 関数のようなものなので、プログラマがカス タム命令を使用するのにアセンブリを知る必要はありません。
自動システム生成
アルテラのSOPC Builder デザイン・ツールは、プロセッサ機能をコン フィギュレーションするプロセスと、FPGA にプログラム可能なハード ウェア・デザインを生成するプロセスを完全に自動化します。ハードウェ ア設計者は、SOPC Builder のグラフィカル・ユーザ・インタフェース （GUI）を使用して、任意の数のペリフェラルとメモリ・インタフェース を持つ Nios II プロセッサ・システムをコンフィギュレーションするこ とができます。また、回路図やハードウェア記述言語（HDL）によるデ ザイン入力を実行することなく、プロセッサ・システム全体を作成でき ます。SOPC Builder は設計者の HDL デザイン・ファイルをインポート することもできるため、カスタム・ロジックを Nios II プロセッサ・シ ステムに簡単に統合することが可能です。 システム生成の後、デザインをボードにプログラムし、ソフトウェアを ボードで実行しながらデバッグできます。デザインをボードにプログラ ムすると、プロセッサ・アーキテクチャは固定されます。ソフトウェア 開発は、コンフィギュレーションが不可能な従来型のプロセッサと同様 に進められます。この資料は更新された最新の英語版が存在します。こちらの日本語版は参考用としてご利用ください。 設計の際には、最新の英語版で内容をご確認ください。
はじめに
この章では、Nios®II アーキテクチャのすべての機能ユニットおよび Nios II プロセッサ・ハードウェア実装の基礎など、Nios II プロセッサ のハードウェア構造について説明します。 Nios II アーキテクチャは、命令セット・アーキテクチャ（ISA）を記述 します。そのため、ISA は命令を実装する機能ユニットのセットを必要 とします。Nios II プロセッサ・コアとは、Nios II 命令セットを実装し、 本書で説明する機能ユニットをサポートするハードウェア・デザインで す。このプロセッサ・コアには、ペリフェラルや外部との接続ロジック は含まれていません。Nios II アーキテクチャの実装に必要な回路のみ搭 載されています。 図 2-1に、Nios II プロセッサ・コアのブロック図を示します。 図 2-1. Nios II プロセッサ・コアのブロック図 プログラム・ コントローラと アドレス生成 JTAG デバッグ・ モジュール カスタム 命令ロジック 例外 コントローラ 割り込み コントローラ 論理演算ユニット 汎用レジスタ r0からr31 コントロール・ レジスタ ctl0からctl5 命令 キャッシュ データ・ キャッシュ Nios IIプロセッサ・コア リセット クロック 命令 マスタ・ ポート データ・ マスタ・ ポート ソフトウェア・デバッガへの JTAGインタフェース カスタム I/O信号 irq[ 31..0 ] NII51002-1.2プロセッサの実装 Nios II アーキテクチャは、以下のユーザがアクセス可能な機能ユニッ トを定義しています。 ■ レジスタ・ファイル ■ 演算ロジック・ユニット ■ カスタム命令ロジックへのインタフェース ■ 例外コントローラ ■ 割り込みコントローラ ■ 命令バス ■ データ・バス ■ 命令キャッシュおよびデータ・キャッシュ・メモリ ■ JTAG デバッグ・モジュール 以下のセクションでは、各機能ユニットに関するハードウェア実装の詳 細について説明します。
プロセッサの
実装
Nios II アーキテクチャの機能ユニットは、Nios II 命令セットの基礎を 形成します。ただし、いずれかのユニットがハードウェアに実装されて いるという意味ではありません。Nios II アーキテクチャは、特定のハー ドウェア実装ではなく命令セットを記述します。機能ユニットは、ハー ドウェアに実装するか、ソフトウェアでエミュレートするか、あるいは 完全に省略することができます。 Nios II 実装とは、特定の Nios II プロセッサ・コアで実現されるデザイ ンの選択セットです。すべての実装が、「Nios II プロセッサ・リファレ ンス・ハンドブック」で定義される命令セットをサポートします。各実 装はコア・サイズの小型化や高性能化など、特定の目的を達成します。 これにより、Nios II アーキテクチャは様々なターゲット・アプリケー ションの要求に適合できます。 実装の変数は一般に、3 つのトレードオフ・パターン（機能の増強また は削減、機能の追加または除外、機能のハードウェア実装またはソフト ウェア・エミュレーション）のいずれかに当てはまります。各トレード オフの例を以下に示します。 ■ 機能の増強または削減 − 例えば、性能を微調整するために、命令 キャッシュ・メモリ容量を増減できます。キャッシュの容量を増や すと大規模なプログラムの実行速度が向上し、キャッシュの容量を 減らすとオンチップ・メモリのリソースが節約できます。 ■ 機能の追加または除外 − 例えば、コストを削減するために、JTAG デバッグ・モジュールを省略するよう選択できます。これによって、 オンチップ・ロジックとメモリ・リソースが節約できますが、ソフ トウェア・デバッガを使用してアプリケーションをデバッグする機 能もなくなります。■ ハードウェア実装またはソフトウェア・エミュレーション − 例え ば、複雑な演算をほとんど実行しない制御アプリケーションでは、除 算命令をソフトウェアでエミュレートするように選択できます。除 算用のハードウェアをなくすとオンチップ・リソースが節約できま すが、除算演算の実行時間が増大します。 各Nios II コアがサポートする機能の詳細については、第17 章の「Nios II コア実装の詳細」を参照してください。ユーザ選択可能な Nios II プロ セッサのパラメータの詳細については、第 4 章の「SOPC Builder での Nios II プロセッサの実装」を参照してください。
レジスタ・
ファイル
Nios II アーキテクチャは、32 個の 32 ビット汎用整数レジスタ、および 6 個のコントロール・レジスタからなるフラットなレジスタ・ファイル をサポートしています。このアーキテクチャではスーパバイザ・モード とユーザ・モードがサポートされており、システム・コードによって不 正なアプリケーションからコントロール・レジスタを保護することがで きます。 Nios II アーキテクチャでは、後で浮動小数点レジスタを追加できます。論理演算
ユニット
Nios II 論理演算ユニット（ALU）は、汎用レジスタに格納されたデータ に対して演算を実行します。ALU 演算では、1 つまたは 2 つの入力をレ ジスタから受け取り、演算結果をレジスタに格納します。ALU は表 2–1 に示すデータ演算をサポートしています。 その他の演算を実行する場合は、表 2–1に示す基本演算の組み合わせを ソフトウェアで実行して結果を算出します。 表 2–1. Nios II ALU がサポートする演算 カテゴリ 詳細 演算 ALU は、符号付きおよび符号なしオペランドに対する加算、減算、乗算、および除算をサ ポートしています。 関係 ALU は、符号付きおよび符号なしオペランドに対する「等しい」、「等しくない」、「大なり または等しい」、「小なり」の関係演算（==、!=、>=、<）をサポートしています。 論理 ALU は、AND、OR、NOR、および XOR 論理演算をサポートしています。 シフトおよび回転
ALU はシフト演算と回転演算をサポートしており、命令ごとにデータを 0 ビットから 31 ビット位置だけシフト / 回転できます。ALU は算術右シフトおよび論理右 / 左シフトをサ ポートしています。ALU は左 / 右回転をサポートしています。
例外コントローラと割り込みコントローラ
未実装命令
一部の Nios II プロセッサ・コアには、乗算または除算演算を実行する ハードウェアが搭載されていません。このプロセッサ・コアがソフトウェ ア で エ ミ ュ レ ー ト で き る 演 算 は、mul、multi、mulxss、mulxsu、 mulxuu、div、divu 命令のみです。このようなコアでは、これらは未 実装命令と認識されます。その他の命令はすべて、ハードウェアで実装 されます。 プロセッサは未実装命令を発行すると必ず例外を生成し、例外ハンドラ がその演算をソフトウェアでエミュレートするルーチンを呼び出しま す。したがって、プログラマは未実装命令によるプロセッサへの影響を 意識する必要はありません。カスタム命令
Nios II アーキテクチャはユーザ定義のカスタム命令をサポートしてい ます。Nios II ALU はカスタム命令ロジックに直接接続されるため、設 計者はネイティブ命令とまったく同様にアクセスし、使用できるハード ウェア演算にカスタム命令を実装できます。詳細については、「Nios II Custom Instruction User Guide」を参照してください。例外コント
ローラと割り
込みコント
ローラ
例外コントローラ
Nios II アーキテクチャでは、ベクタ化されていないシンプルな例外コン トローラにより、すべての例外タイプを処理できます。ハードウェア割 り込みを含め、どの例外が発生してもプロセッサは1 つの例外アドレス に実行を移します。このアドレスの例外ハンドラは、例外の原因を特定 して、適切な例外ルーチンをディスパッチします。 例外アドレスは、システム生成時に指定されます。統合割り込みコントローラ
Nios II アーキテクチャは、32 の外部ハードウェア割り込みをサポート しています。プロセッサ・コアは、irq0 から irq31 までの 32 レベル の割り込み要求（IRQ）入力を備えており、各割り込みソースに対して 固有の入力を提供します。IRQ の優先順位はソフトウェアで決定されま す。このアーキテクチャは、ネスト型割り込みをサポートしています。このソフトウェアでは、各IRQ 入力用の割り込みイネーブル・ビットを 備えたienable コントロール・レジスタを介して、割り込みソースを個 別にイネーブルおよびディセーブルできます。また、ステータス・コン トロール・レジスタのPIE ビットを介して、割り込みをグローバルにイ ネーブルおよびディセーブルできます。ハードウェア割り込みは、以下 の3 つの条件がすべて満たされた場合にのみ生成されます。 ■ ステータス・レジスタのPIE ビットが 1 ■ 割り込み要求入力irqn がアサートされている ■ ienable レジスタの対応するビット n が 1
メモリおよび
I/O の構成
このセクションでは、Nios II のメモリおよび I/O 構成のハードウェア実 装の詳細を説明します。ここでは、すべての Nios II プロセッサ・シス テムに該当する一般的な概念と、システムごとに異なる機能について解 説します。Nios II のメモリおよび I/O 構成の柔軟性は、Nios II プロセッサ・シス テムと従来型のマイクロコントローラとの違いを最も顕著に示すもので す。Nios II プロセッサ・システムはコンフィギュレーション可能なた め、メモリとペリフェラルはシステムごとに異なります。その結果、メ モリとI/O 構成もシステムごとに異なります。 Nios II アーキテクチャでは、プログラマからはハードウェアの詳細が認 識されないため、プログラマはハードウェア実装を意識することなく Nios II アプリケーションを開発できます。プログラミングへの影響の詳 細については、第3 章の「プログラミング・モデル」で解説します。 図 2-2に、Nios II プロセッサ・コアのメモリおよび I/O 構成の図を示し ます。
メモリおよび I/O の構成 図 2-2. Nios II のメモリおよび I/O 構成
命令バスとデータバス
Nios II アーキテクチャは、独立した命令バスとデータバスをサポートし ているため、Harvard アーキテクチャに分類されます。命令バスとデー タバスはともに、Avalon™ インタフェース仕様に準拠する Avalon マス タ・ポートとして実装されます。データ・マスタ・ポートはメモリ・コ ンポーネントとペリフェラル・コンポーネントの両方に接続されますが、 命令マスタ・ポートはメモリ・コンポーネントにのみ接続されます。 Avalonインタフェースの詳細については、「Avalon Interface Specification Reference Manual」を参照してください。 メモリ・アクセスとペリフェラル・アクセス Nios II アーキテクチャでは、メモリ・マップド I/O アクセスが利用でき ます。データ・メモリとペリフェラルはともに、データ・マスタ・ポー トのアドレス空間にマップされます。Nios II アーキテクチャはリトル・ エンディアンです。ワードとハーフワードは、上位アドレスを上位バイ トとしてメモリに格納されます。 プログラム・ カウンタ Nios IIプロセッサ・コア データ・ キャッシュ 命令 キャッシュ メモリ・ アクセス ペリフェラル・ アクセス 命令 フェッチ 汎用 レジスタ・ ファイル Avalon スイッチ・ ファブリック M M M S Avalon マスタ・ ポート Avalon スレーブ・ ポート S メモリ S Avalon スレーブ・ ペリフェラルNios II アーキテクチャは、メモリとペリフェラルの使用に関して何も規 定していないため、メモリとペリフェラルの数量、タイプ、および接続 はシステムに依存します。通常、Nios II プロセッサ・システムは、高速 オンチップ・メモリと低速オフチップ・メモリを組み合わせて搭載して います。ペリフェラルは一般にオンチップに搭載されていますが、オフ チップ・ペリフェラルへのインタフェースも存在します。 命令マスタ・ポート Nios II 命令バスは 32 ビット Avalon マスタ・ポートとして実装されま す。命令マスタ・ポートは、1 つの機能、つまりプロセッサが実行する フェッチ命令を実行します。命令マスタ・ポートは、書き込み操作は実 行しません。 命令マスタ・ポートは、レイテンシを認識できるため、レイテンシの高 いメモリ・デバイスを使用してパイプライン転送を実行できます。言い 換えれば、命令マスタ・ポートは前の要求からデータが返る前に、連続 して読み出し要求を発行します。Nios II プロセッサは、シーケンシャル 命令のプリフェッチをサポートしているため、分岐予測を実行して、命 令パイプを可能な限りアクティブに維持できます。レイテンシ付き Avalon 転送のサポートによって、レイテンシが高いメモリへの影響が 軽減され、システムの全体的なfMAXが増大します。 命令マスタ・ポートは常に32 ビットのデータを取得します。命令マスタ・ ポートは、プロセッサ、メモリ、およびペリフェラルを連結して一体化す るAvalon スイッチ・ファブリックに搭載されているダイナミック・バス・ サイジング・ロジックを基礎としています。ダイナミック・バス・サイジ ングにより、すべての命令フェッチはターゲット・メモリの幅に関係なく、 完全な命令ワードを返します。その結果、プログラムではNios II プロセッ サ・システム内のメモリ幅を意識する必要はありません。 Nios II アーキテクチャは、低速メモリにアクセスするときの平均命令 フェッチ性能を改善するために、オンチップ・キャッシュ・メモリをサ ポートしています。詳細については、2–8 ページの「キャッシュ・メモ リ」を参照してください。 データ・マスタ・ポート Nios II データ・バスは 32 ビット Avalon マスタ・ポートとして実装さ れます。データ・マスタ・ポートは以下の2 つの機能を実行します。 ■ プロセッサがロード命令を実行するときに、メモリまたはペリフェ ラルからデータを読み込む ■ プロセッサがストア命令を実行するときに、メモリまたはペリフェ ラルにデータを書き込む
メモリおよび I/O の構成 マスタ・ポート上のバイト・イネーブル信号は、ストア操作中に書き込 む4 つのバイト・レーンのいずれかを指定します。データ・マスタ・ポー トはレイテンシ付きAvalon 転送をサポートしていません。これは、デー タ取得前にデータ・アドレスを予測したり、実行を継続しても意味がな いためです。したがって、データ・マスタはメモリ・レイテンシをウェ イト・ステートとして解釈します。データ・マスタ・ポートがゼロ・ウェ イト・ステート・メモリに接続されている場合、ロード操作とストア操 作は1 クロック・サイクルで完了できます。 Nios II アーキテクチャは、低速メモリにアクセスするときの平均データ転 送性能を改善するために、オンチップ・キャッシュ・メモリをサポートし ています。詳細については、「キャッシュ・メモリ」を参照してください。 命令およびデータ用の共有メモリ 通常、命令マスタ・ポートとデータ・マスタ・ポートは、命令とデータ の両方を格納する1 つのメモリを共有します。プロセッサ・コアは独立 した命令バスとデータ・バスを搭載していますが、Nios II プロセッサ・ システム全体としては、外部に対して1 つの共有命令 / データ・バスを 提供することができます。Nios II プロセッサ・システムの外形は、シス テム内のメモリとペリフェラル、およびAvalon スイッチ・ファブリッ クの構造によって異なります。 データ・マスタ・ポートと命令マスタ・ポートによって、一方のポート が他方のポートを枯渇させるグリッドロック状態が発生することはあり ません。最高の性能を実現するには、命令マスタ・ポートとデータ・マ スタ・ポートが共有するメモリ上で、データ・マスタ・ポートに高いアー ビトレーション・プライオリティを割り当てる必要があります。
キャッシュ・メモリ
Nios II アーキテクチャは、命令マスタ・ポート（命令キャッシュ）と データ・マスタ・ポート（データ・キャッシュ）の両方でキャッシュ・ メモリをサポートしています。キャッシュ・メモリは、Nios II プロセッ サ・コアの主要部分として、オンチップに搭載されています。キャッ シュ・メモリを利用すると、プログラムやデータ格納用のSDRAM など の低速オフチップ・メモリを使用する Nios II プロセッサ・システムの 平均メモリ・アクセス時間を改善できます。 命令キャッシュとデータ・キャッシュは、実行時には常にイネーブルさ れますが、ペリフェラル・アクセス時にキャッシュされたデータが返さ れないように、ソフトウェアによってデータ・キャッシュをバイパスす る手段が用意されています。キャッシュ管理とキャッシュ・コヒーレン シは、ソフトウェアで処理されます。Nios II 命令セットには、キャッ シュ管理用の命令があります。コンフィギュレーション可能なキャッシュ・メモリ・オプション キャッシュ・メモリはオプションです。高いメモリ性能（および、それ に伴うキャッシュ・メモリ）が必要かどうかは、アプリケーションによっ て決まります。多くのアプリケーションでは、可能な限り小さなプロセッ サ・コアを必要とし、性能を犠牲にしてサイズを優先させる場合があり ます。 Nios II プロセッサ・コアには、キャッシュ・メモリの一方または両方を 搭載するか、どちらも搭載しないことが可能です。さらに、データ・キャッ シュと命令キャッシュの両方またはいずれか一方を備えたコアの場合、 キャッシュ・メモリのサイズはユーザが設定/構成可能です。キャッシュ・ メモリを搭載してもプログラムの機能には影響はありませんが、プロセッ サが命令をフェッチする速度とデータを読み出し/書き込みする速度は影 響を受けます。 キャッシュ・メモリの効果的な使用法 性能を改善するためのキャッシュ・メモリの効果は、以下の前提に基づ きます。 ■ 通常のメモリがオフチップで配置され、オンチップ・メモリと比較 してアクセス時間が長い ■ 性能が重視される最大命令ループが命令キャッシュよりも小さい ■ 性能が重視されるデータの最大ブロックがデータ・キャッシュより も小さい 対象となるアプリケーションでの効果は設計者が判断できますが、最適 なキャッシュ構成はアプリケーションによって異なります。例えば、 Nios II プロセッサ・システムに、高速オンチップ・メモリしかない（つ まり、低速オフチップ・メモリにはアクセスしない）場合、命令キャッ シュまたはデータ・キャッシュによる性能向上は期待できません。もう 1 つ例を挙げれば、プログラムの重要なループが 2 K バイトでも、命令 キャッシュのサイズが1 K バイトであれば、命令キャッシュによって実 行速度が向上することはありません。実際のところ、性能は低下すると 考えられます。 キャッシュ・バイパス方法
Nios II アーキテクチャでは、ldio や stio のように、データ・キャッ シュをバイパスし、指定されたアドレスへのAvalon データ転送を強制 するロードおよびストアI/O 命令が利用できます。プロセッサ・コア実 装によっては、追加のキャッシュ・バイパス方法を利用することもでき ます。
JTAG デバッグ・モジュール Nios II プロセッサ・コアのいくつかは、アドレスの最上位ビットの値に 応じてキャッシュをバイパスする、ビット31 キャッシュ・バイパスと呼 ばれるメカニズムをサポートしています。詳細については、第 17 章の 「Nios II コア実装の詳細」を参照してください。
アドレス・マップ
Nios II プロセッサ・システムでのメモリおよびペリフェラルのアドレ ス・マップは、デザインによって異なります。アドレス・マップは、シ ステム生成時に設計者が指定します。 以下の3 つのアドレスは、CPU の一部であり特に注意が必要です。 ■ リセット・アドレス ■ 例外アドレス ■ ブレーク・ハンドラ・アドレス プログラマは、標準的なプログラム構成を使用してメモリとペリフェラ ルにアクセスします。したがって、アプリケーション開発者がこの柔軟 なアドレス・マップを意識する必要はありません。JTAG
デバッグ・
モジュール
Nios II アーキテクチャでは、オンチップ・エミュレーション機能を可 能にするJTAG デバッグ・モジュールがサポートされているため、プロ セッサをホストPC からリモートで制御できます。PC ベースのソフト ウェア・デバッグ・ツールは、JTAG デバッグ・モジュールと通信し、 以下のような機能を実現します。 ■ メモリへのプログラムのダウンロード ■ 実行の開始および停止 ■ ブレークポイントおよびウォッチポイントの設定 ■ レジスタおよびメモリの解析 ■ リアルタイム実行トレース・データの収集 デバッグ・モジュールは、アルテラのFPGA の JTAG 回路に接続されま す。これにより、外部デバッグ・プローブからFPGA 上の標準 JTAG イ ンタフェースを介してプロセッサにアクセスできます。プロセッサ側で は、デバッグ・モジュールがプロセッサ・コア内部の信号に接続されま す。デバッグ・モジュールには、プロセッサに対してマスク不能な制御 を行い、テスト中のアプリケーションにリンクされたソフトウェア・ス タブは不要です。スーパバイザ・モードでプロセッサがアクセス可能な すべてのシステム・リソースをデバッグ・モジュールで利用できます。 トレース・データ収集の場合、デバッグ・モジュールはオンチップまた はデバッグ・プローブ内のメモリにトレース・データを格納します。デバッグ・モジュールは、ハードウェア・ブレーク信号をアサートする か、実行するプログラム・メモリ内にブレーク命令を書き込むことによっ て、プロセッサの制御を取得します。どちらの場合も、プロセッサは、 ブレーク・アドレスに配置されるルーチンに制御を移します。ブレーク・ アドレスはシステム生成時に指定されます。 Nios II プロセッサなどのソフトコア・プロセッサでは、従来型の固定プ ロセッサにはない独自のデバッグ機能を利用できます。Nios II プロセッ サのソフトコア特性により、設計者はフル機能のデバッグ・コアを使用 して、開発中のシステムをデバッグし、後でデバッグ機能を削除してロ ジック・リソースを節約することができます。製品のリリース・バージョ ンでは、JTAG デバッグ・モジュール機能は縮小するか完全に取り除く ことができます。 以下のセクションでは、Nios II JTAG デバッグ・モジュール・ハードウェ アの機能について説明します。すべてのハードウェア機能の使用は、 Nios II IDE のように、ターゲット・プロセッサへの接続を管理し、デ バッグ・プロセスを制御するホスト・ソフトウェアに依存します。
JTAG ターゲット接続
JTAG ターゲット接続とは、アルテラ FPGA 上の標準 JTAG ピンを介し て CPU に接続することを意味します。この機能によって、プロセッサ の実行開始および停止、レジスタおよびメモリの確認/ 編集が可能にな ります。また、JTAG ターゲット接続は、Nios II IDE Flash Programmer を利用するための最低要件でもあります。
ダウンロードおよび実行ソフトウェア
ソフトウェアのダウンロードとは、JTAG 接続を介して、実行可能コー ドとデータをプロセッサのメモリにダウンロードすることです。ソフト ウェアをメモリにダウンロードすると、JTAG デバッグ・モジュールは デバッグ・モードを終了して、実行可能コードの先頭に実行を移すこと ができます。ソフトウェア・ブレークポイント
ソフトウェア・ブレークポイントでは、RAM 内の命令にブレークポイ ントを設定できます。ソフトウェア・ブレークポイント・メカニズムは、 RAM に格納されている実行可能コードにブレーク命令を書き込みます。 プロセッサがブレーク命令を実行すると、制御は JTAG デバッグ・モ ジュールに移されます。JTAG デバッグ・モジュール
ハードウェア・ブレークポイント
ハードウェア・ブレークポイントでは、フラッシュ・メモリなどの不揮 発性メモリ内の命令にブレークポイントを設定できます。ハードウェア・ ブレークポイント・メカニズムは、プロセッサの現在の命令アドレスを 継続的にモニタします。命令アドレスがハードウェア・ブレークポイン ト・アドレスと一致すると、JTAG デバッグ・モジュールがプロセッサ を制御します。 ハードウェア・ブレークポイントは、JTAG デバッグ・モジュールのハー ドウェア・トリガ機能を使用して実現されます。ハードウェア・トリガ
ハードウェア・トリガは、リアルタイム・プログラム実行中の命令バス またはデータ・バスの状態に基づいて、デバッグ動作をアクティブにし ます。トリガは単にプロセッサの実行を停止するだけではありません。 例えば、リアルタイム・プロセッサ実行中のトレース・データ収集をイ ネーブルするのにも使用できます。 表 2–2に、トリガが発生するすべての条件を示します。ハードウェア・ トリガ条件は、命令バスまたはデータ・バスのいずれかに基づきます。 同一バス上のトリガ条件は論理積をとることができるため、例えば、 JTAG デバッグ・モジュールをライト・サイクルでのみ特定のアドレス にトリガさせることができます。 表 2–2. トリガ条件 条件 バス (1) 説明 特定のアドレス D、I バスが特定のアドレスにアクセスしたときにトリガ。 特定のデータ値 D バス上に特定のデータ値が現れたときにトリガ。 リード・サイクル D リード・バス・サイクルでのトリガ。 ライト・サイクル D ライト・バス・サイクルでのトリガ。 アーム条件 D、I アーム付きトリガ・イベント後にのみトリガ。2–13 ページの「アーム付きト リガ」を参照してください。 範囲 D アドレス値、データ値、またはその両方の範囲でのトリガ。2–13 ページの 「値の範囲でのトリガ」を参照してください。 注 : (1) 「I」は命令バス、「D」はデータ・バスを示します。プロセッサ実行中にトリガ条件が満たされると、JTAG デバッグ・モ ジュールは、実行の停止やトレース・キャプチャの開始などの動作をト リガします。表 2–3に、Nios II JTAG デバッグ・モジュールでサポート されているトリガ動作を示します。 アーム付きトリガ JTAG デバッグ・モジュールには、アーム付きトリガと呼ばれる 2 つの レベルの機能があります。アーム付きトリガにより、JTAG デバッグ・ モジュールは、イベントA の発生後にのみイベント B でトリガできま す。この例では、イベントA によってイベント B のトリガをイネーブル するトリガ動作が発生します。 値の範囲でのトリガ JTAG デバッグ・モジュールは、データ・バス上のデータまたはアドレ ス値の範囲でトリガすることができます。このメカニズムは、2 つのハー ドウェア・トリガを併用し、指定範囲内においてある値の範囲でアクティ ブになるトリガ条件を作成します。
トレース・キャプチャ
トレース・キャプチャとは、プロセッサがリアルタイムでコードを実行 中に、プロセッサの1 命令ごとの実行を記録することです。JTAG デバッ グ・モジュールには、以下のトレース機能があります。 ■ 実行トレースをキャプチャする（命令バス・サイクル）。 ■ データ・トレースをキャプチャする（データ・バス・サイクル）。 表 2–3. トリガ動作 動作 説明 ブレーク 実行を停止し、制御を JTAG デバッグ・モジュールに移します。 外部トリガ トリガ信号出力をアサートします。このトリガ出力を使用して、例えば外部ロジック・ アナライザをトリガすることができます。 トレース・オン トレース収集をオンにします。 トレース・オフ トレース収集をオフにします。 トレース・サンプル(1) バスの 1 つのサンプルをトレース・バッファに格納します。 アーム アーム付きトリガをイネーブルします。 注 : (1) データ・バス上の状態によってのみこの動作がトリガされます。JTAG デバッグ・モジュール ■ 各データ・バス・サイクルでアドレス、データ、またはその両方を キャプチャする。 ■ トリガに基づいて、リアルタイムでのトレースのキャプチャを開始 および停止する。 ■ ホストの制御のもとで手動でトレースを開始および停止する。 ■ トレース・バッファがいっぱいになったときに、オプションにより トレースのキャプチャを停止して、プロセッサを実行させたままに する。 ■ JTAG デバッグ・モジュールのオンチップ・メモリ・バッファにトレー ス・データを格納する。（このメモリはJTAG 接続によってのみアク セス可能） ■ トレース・データをオフチップ・デバッグ・プローブの大規模バッ ファに格納する。 一部のトレース機能には、サードパーティのデバッグ・プロバイダが提 供する追加ライセンスまたはデバッグ・ツールが必要です。例えば、オ ンチップ・トレース・バッファはNios II プロセッサの標準機能ですが、 オフチップ・トレース・バッファを使用するには、First Silicon Solutions （FS2）が提供する別のデバッグ・ソフトウェアとハードウェアが必要で す。詳細については、www.fs2.com をご覧ください。 実行とデータ・トレース JTAG デバッグ・モジュールは、命令バスのトレース（実行トレース）、 データ・バスのトレース（データ・トレース）、あるいは同時にその両方 のトレースをサポートしています。実行トレースでは、実行された命令 のアドレスのみが記録されるため、設計者はメモリ内のどの場所（すな わち、どの関数）でコードが実行されたかを解析できます。データ・ト レースでは、データ・バス上の各ロードおよびストア操作に関連するデー タが記録されます。 JTAG デバッグ・モジュールは、リアルタイムでデータ・バス・トレー スをフィルタして、以下のキャプチャを実行できます。 ■ ロード・アドレスのみ ■ ストア・アドレスのみ ■ ロード・アドレスとストア・アドレスの両方 ■ ロード・データのみ ■ ロード・アドレスとロード・データ ■ ストア・アドレスとストア・データ ■ ロードとストア両方のアドレスとデータ ■ トリガ・イベント時のデータ・バスのシングル・サンプル
フレームのトレース 「フレーム」とは、トレース・データの収集用に割り当てられたメモリ単 位です。ただし、フレームはトレースの深さを示す絶対的な尺度ではあ りません。 リアルタイムで動作中のプロセッサを追跡するために、実行トレースは、 分岐、呼び出し、トラップ、割り込みなど、選択したアドレスのみを保 存するように最適化されています。これらのアドレスから、ホスト側の デバッグ・ソフトウェアは、厳密な命令ごとの実行トレースを後で再構 築することができます。さらに、実行トレース・データは、1 つのフレー ムが複数の命令を表すような圧縮形式で保存されます。これらの最適化 によって、実行中におけるトレース収集の実際の開始点と停止点は、ユー ザが指定した開始点および停止点とわずかに異なる場合があります。 データ・トレースでは、要求されたロードおよびストアの100% がリア ルタイムでトレース・バッファに格納されます。トレース・バッファへ の格納時には、データ・トレース・フレームの優先順位は実行トレース・ フレームより低くなります。したがって、データ・フレームは常に古い ものから順に格納されますが、実行トレースとデータ・トレースが互い に正確に同期しているかどうかは保証されません。
この資料は更新された最新の英語版が存在します。こちらの日本語版は参考用としてご利用ください。 設計の際には、最新の英語版で内容をご確認ください。
はじめに
この 章で は、アセン ブリ 言語 レベル での プロ セッサ 機能 を中 心に、 Nios®II プログラミング・モデルについて説明します。以下の機能をプ ログラマ向けに解説しています。 ■ 汎用レジスタ、3–1 ページ ■ コントロール・レジスタ、3–3 ページ ■ スーパバイザ・モードでの権限とユーザ・モードでの権限、3–5 ページ ■ ハードウェア支援デバッグ処理、3–14 ページ ■ 例外処理、3–8 ページ ■ ハードウェア割り込み、3–9 ページ ■ 未実装命令、3–11 ページ ■ メモリおよびペリフェラルの構成、3–15 ページ ■ キャッシュ・メモリ、3–16 ページ ■ プロセッサのリセット状態、3–16 ページ ■ 命令セットのカテゴリ、3–17 ページ ■ カスタム命令、3–23 ページ 高水準ソフトウェア開発ツールについては、ここでは説明していません。 ソフトウェアの開発については、Nios II ソフトウェア開発ハンドブック を参照してください。汎用レジスタ
Nios II アーキテクチャは、r0 から r31 までの 32 個の 32 ビット汎用レジ スタを提供します。3-2 ページの表 3–1を参照してください。一部のレジス タにはアセンブラで認識される名前が付いています。zero レジスタ（r0） は常に値0 を返すため、zero に書き込んでも無効です。ra レジスタ（r31） は、プロシージャ・コールで使用された戻りアドレスを保持しており、 call 命令と ret 命令によって暗黙的にアクセスされます。C および C++ コンパイラは共通のプロシージャ・コール規則を使用して、レジスタ r1 からr23 および r26 から r28 に特定の目的を割り当てます。この規則は、 第19 章の「アプリケーション・バイナリ・インタフェース」に記載されて います。 et（r24）、bt（r25）、ea（r29）、および ba（r30）など、一部のレ ジスタへのアクセスは、特定の実行モードに限定されます。詳細につい ては、3–5 ページの「動作モード」を参照してください。 NII51003-1.2汎用レジスタ 表 3–1. Nios II レジスタ・ファイル 汎用レジスタ レジスタ 名称 機能 レジスタ 名称 機能 r0 zero 0x00000000 r16 r1 at 一時的なアセンブラ r17 r2 戻り値 r18 r3 戻り値 r19 r4 レジスタ引数 r20 r5 レジスタ引数 r21 r6 レジスタ引数 r22 r7 レジスタ引数 r23 r8 呼び出し元保存レジスタ r24 et 一時的な例外(1) r9 呼び出し元保存レジスタ r25 bt 一時的なブレークポイント(2) r10 呼び出し元保存レジスタ r26 gp グローバル・ポインタ r11 呼び出し元保存レジスタ r27 sp スタック・ポインタ r12 呼び出し元保存レジスタ r28 fp フレーム・ポインタ r13 呼び出し元保存レジスタ r29 ea 例外戻りアドレス(1) r14 呼び出し元保存レジスタ r30 ba ブレークポイント戻りアドレス (2) r15 呼び出し元保存レジスタ r31 ra 戻りアドレス 表 3–1の注： (1) このレジスタはユーザ・モードでは使用できません。 (2) このレジスタはユーザ・モードまたはスーパバイザ・モードでは使用できません。JTAG デバッグ・モ ジュールで排他的に使用されます。
コントロール・
レジスタ
ctl0 から ctl5 までの 6 個の 32 ビット・コントロール・レジスタがあ ります。すべてのコントロール・レジスタには、アセンブラで認識され る名前が付いています。 コントロール・レジスタは、汎用レジスタとは異なる方法でアクセスさ れます。特殊命令のrdctl および wrctl によってのみ、コントロール・ レジスタの読み出しと書き込みが可能です。コントロール・レジスタは スーパバイザ・モードでのみアクセス可能で、ユーザ・モードではアク セスできません。詳細については、3–5 ページの「動作モード」を参照 してください。 コントロール・レジスタの詳細は、表3–2に示します。コントロール・レ ジスタと例外処理の関係についての詳細は、3–10 ページの図 3-2を参照し てください。 status (ctl0) status レジスタの値によって、Nios II プロセッサの状態を制御します。 プロセッサのリセット後に、すべてのステータス・ビットがクリアされ ます。3–16 ページの「プロセッサのリセット状態」を参照してください。 表3–3に示すように、PIE と U の 2 ビットが定義されています。 表 3–2. コントロール・レジスタとビット レジスタ 名称 31…2 1 0 ctl0 status 予約済み U PIE ctl1 estatus 予約済み EU EPIE ctl2 bstatus 予約済み BU BPIE ctl3 ienable 割り込みイネーブル・ビット ctl4 ipending 割り込みペンディング・ビット ctl5 cpuid 固有のプロセッサ識別子 表 3–3. ステータス・レジスタ・ビット ビット 説明PIE ビット PIE はプロセッサ割り込みイネーブル・ビットです。PIE が 0 の場合、外部割込みは無視さ れます。PIEが1の場合、ienableレジスタの値に応じて、外部割込みの受け入れが可能です。 U ビット U はユーザ・モード・ビットです。1 はユーザ・モード、0 はスーパバイザ・モードを示します。
コントロール・レジスタ estatus (ctl1) estatus レジスタは、例外処理中の status レジスタの保存されたコ ピーを保持します。EPIE と EU の 2 ビットが定義されています。これら は、表3–3で定義するとおり、PIE と U の値を保存したものです。 例外ハンドラで estatus を調べて、例外発生前のプロセッサのステータ スを確認できます。プロセッサは、割り込みからの復帰時にeret 命令に よって、estatus を status にコピーし、例外発生前の status の値を復元 します。 詳細については、3–8 ページの「例外処理」を参照してください。 bstatus (ctl2) bstatus レジスタは、デバッグ・ブレーク処理中の status レジスタ の保存されたコピーを保持します。EPIE と BU の 2 ビットが定義されて います。これらは、3–3 ページの表 3–3で定義するとおり、PIE と U の 値を保存したものです。 ブレークが発生すると、status レジスタの値が bstatus にコピーさ れます。bstatus を使用すると、status レジスタをブレーク発生前の 値に復元することができます。 詳細については、3–7 ページの「デバッグ・モード」を参照してください。 ienable (ctl3) ienable レジスタは、外部ハードウェア割り込みの処理を制御します。 ienable レジスタの各ビットは、irp0 から irp31 までの割り込み入 力の1 つに対応します。ビット値が 1 の場合は対応する割り込みがイネー ブルされていることを意味し、ビット値が0 の場合は、対応する割り込 みがディセーブルされていることを意味します。 詳細については、3–8 ページの「例外処理」を参照してください。 ipending (ctl4) ipending レジスタの値は、どの割り込みがペンディング中であるかを 示します。ビットn の値が 1 の場合は対応するirqn 入力がアサートさ れ、対応する割り込みが ienable レジスタでイネーブルされているこ とを意味します。ipending レジスタに値を書き込んだ場合の影響は不 定です。
cpuid (ctl5) cpuid レジスタは、マルチプロセッサ・システムでプロセッサを一意に 識別するスタティック値を保持します。cpuid の値はシステム生成時に 決定されます。cpuid レジスタに値を書き込んでも無効となります。 詳細については、3–8 ページの「例外処理」を参照してください。
動作モード
Nios II プロセッサには、以下の 3 つの動作モードがあります。 ■ スーパバイザ・モード ■ ユーザ・モード ■ デバッグ・モード 以下のセクションでは、モードおよびモード間の移行について説明しま す。この説明では、システム・コードとアプリケーション・コードを区 別しています。 ■ システム・コードは、オペレーティング・システム（OS）や低水準 ハードウェア・ドライバなど、システム・レベルの機能を実行する ルーチンで構成されています。一般に、システム・コードはランタ イム・ライブラリまたはOS カーネルの一部分として提供されます。 通常、システム・コードはスーパバイザ・モードで実行されます。 ■ アプリケーション・コードは、システム・コードで提供されるサー ビス上で動作するルーチンで構成されています。アプリケーション・ コードは、一般にターゲット・アプリケーションを作成するプログ ラマが記述します。スーパバイザ・モード
スーパバイザ・モードでは、すべての定義済みのプロセッサ機能が利用で き制約はありません。一般に、システム・コードはスーパバイザ・モード で実行されます。ただし、オペレーティング・システムを使用しないシン プルなプログラムは無限にスーパバイザ・モードのままで、アプリケー ション・コードはスーパバイザ・モードのもとで正常に実行できます。 汎用レジスタbt（r25）および ba（r30）は、スーパバイザ・モードで は利用できません。プログラムがこれらのレジスタに値を格納しないよ うにすることはできませんが、値が格納された場合、その値はデバッグ・ モードで変更できます。また、bstatus レジスタ（ctl2）もスーパバ イザ・モードでは利用できません。 プロセッサがスーパバイザ・モードの場合、U ビットは 0 です。プロ セッサは、リセット直後はスーパバイザ・モードになります。動作モード
ユーザ・モード
ユーザ・モードは、スーパバイザ・モード機能の限定されたサブセット を提供します。ユーザ・モードでは、複数のタスクを監視するオペレー ティング・システムに対して高い信頼性が実現されます。システム・コー ドは、ユーザ・モードに切り替えてからアプリケーション・コードに制 御を渡すことを選択できます。 ユーザ・モードでは、一部のプロセッサ機能にはアクセスできず、アク セスを試みると例外が発生します。コントロール・レジスタはユーザ・ モードでは利用できません。さらに、汎用レジスタの et（r24）、bt （r25）、ea（r29）、および ba（r30）も利用できません。ユーザ・モー ドで実行しているプログラムがこれらのレジスタに値を格納しないよう にすることはできませんが、格納された値はスーパバイザ・モードの例 外ルーチンまたはデバッグ・モードで変更できます。 プロセッサがユーザ・モードの場合、以下の命令のいずれかを発行する と例外が発生します。 ■ rdctl ■ wrctl ■ bret ■ eret ■ initd ■ initi プロセッサがユーザ・モードの場合、U ビットは 1 です。 プロセッサ実装とユーザ・モード・サポート 一部の Nios II プロセッサ実装では、ユーザ・モードはサポートされて いません。これらのコアでは、すべてのコードがスーパバイザ・モード で実行され、U ビットは常に 0 になります。したがって、正しく実行さ せるには、U ビットの特定の値に動作が左右されないようにアプリケー ション・コードを記述する必要があります。 アプリケーション・コードは、ユーザ・モードとスーパバイザ・モード のどちらでも正常に実行されます。ユーザ・モードをサポートしていな い Nios II プロセッサ・コアでは、システム・コードからユーザ・モー ドまたは制限されたリソース保護のためのアクセス違反例外を利用する ことはできません。 ユーザ・モードをサポートするプロセッサの詳細については、第17 章の 「Nios II コア実装の詳細」を参照してください。デバッグ・モード
デバッグ・モードは、ブレークポイントやウォッチポイントなどの機能 を実現するために、ソフトウェア・デバッグ・ツールで使用されていま す。システム・コードとアプリケーション・コードはデバッグ・モード では実行できません。プロセッサは、break 命令後、または JTAG デ バッグ・モジュールがハードウェアでブレークを強制した場合にのみ、 デバッグ・モードに移行します。 デバッグ・モードでは、ソフトウェア・デバッグ・ツールからすべてのプ ロセッサ機能が無制限に利用できます。デバッグ・モードではU ビットは 0 です。詳細については、3–14 ページの「ブレーク処理」 を参照してくだ さい。モードの変更
図 3-1 は、ユーザ・モード、スーパバイザ・モード、およびデバッグ・ モード間の移行を示します。 図 3-1. 動作モード間の遷移 プロセッサは、リセット後にスーパバイザ・モードで起動します。 プログラムは、eret（例外復帰）命令を使用してスーパバイザ・モード からユーザ・モードに切り替えることができます。eret は、estatus レジスタ（ctl1）の値を status レジスタ（ctl0）にコピーし、ea （r29）レジスタのアドレスに制御を移します。プロセッサをリセットし てから最初にユーザ・モードに入るには、システム・コードはestatus レジスタとeaレジスタを設定し、eret命令を実行する必要があります。 ブレーク条件 デバッグ （U = = 0） リセット bret eret bret 例外 ブレーク条件 ユーザ （U = = 1） スーパバイザ （U = = 0）例外処理
プロセッサは例外処理が発生するまでユーザ・モードで維持され、例外 処理が発生した時点でスーパバイザ・モードに再入します。すべての例 外処理で、U ビットは 0 にクリアされ、status の内容は estatus に 保存されます。例外処理ルーチンが estatus レジスタを変更しないと 仮定すれば、eret を使用して例外処理から復帰すると、例外処理発生 前のモードに復元されます。 プロセッサは、ソフトウェア・デバッグ・ツールで指示された場合のみ、 デバッグ・モードに入ります。システム・コードとアプリケーション・ コードは、プロセッサがデバッグ・モードに移行するタイミングを制御 することはできません。プロセッサはデバッグ・モードを終了すると、 必ず前の状態に戻ります。 詳細については、3–8 ページの「例外処理」と3–14 ページの「ブレーク 処理」を参照してください。
例外処理
例外は、プログラムの通常の実行フローから制御を移すことであり、こ れはプロセッサの内部または外部のイベントによって発生し、即時の対 処が求められます。例外処理とは、例外に反応して動作し、その後で例 外が発生する前の実行状態に戻ることをいいます。 例外が発生すると、プロセッサは自動的に以下のステップを実行します。 プロセッサは、 1. status レジスタ（ctl0）の内容を estatus レジスタ（ctl1）に コピーして、例外発生前のプロセッサの状態を保存します。 2. status レジスタの U ビットをクリアして、プロセッサを強制的にスー パバイザ・モードにします。 3. status レジスタの PIE ビットをクリアして、外部プロセッサ割り込 みをディセーブルします。 4. 例外発生後の命令のアドレスをea レジスタ（r29）に書き込みます。 5. 割り込みの原因を特定する例外ハンドラのアドレスに実行を移します。 例外ハンドラのアドレスは、システム生成時に指定されます。このアド レスは実行時に確定され、ソフトウェアでは変更できません。プログラ マが例外ハンドラのアドレスに直接アクセスすることはなく、アドレス を意識しないでプログラムを記述できます。 例外ハンドラは各例外の原因を特定し、適切な例外ルーチンをディス パッチして割り込みに応答します。例外と割り込み処理を利用するプログラムの記述に関する詳細な説明は、 「Nios II ソフトウェア開発ハンドブック」の第 6 章「例外処理」を参照 してください。
