セクション I. Nios II プロセッサ Corporation セクション I–1 セクションI. Nios II プロセッサこのセクションには、Nios® II プロセッサに関する情報が記載されてい

Altera Corporation

セクション I. Nios IIプロセッサ

このセクションには、Nios® II プロセッサに関する情報が記載されています。

このセクションは、以下の章で構成されています。

■ 第 1章　概要

■ 第 2章　プロセッサ・アーキテクチャ

■ 第 3章　プログラミング・モデル

■ 第 4章　SOPC Builder でのNios IIプロセッサの実装

セクション I–1

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 初版

セクション I–2 Altera Corporation

Altera Corporation 2004年 9月

この資料は更新された最新の英語版が存在し設計の際には、最新の英語版で内容をご確認

NII51001-1.0

1. 概要

ます。こちらの日本語版は参考用としてご利用ください。ください。

はじめにこの章では、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プロセッサ・システムは一貫した命令セットとプログラミング・モデルを使用しています。

1–1

はじめに

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

オフチップ・メモリへのトライステート・ブリッジ

Ava

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

JTAG デバッグ・モジュール

SDRAM メモリ

フラッシュ・メモリ

SRAM メモリ

UART

タイマ1

タイマ2

LCDディスプレイ・ドライバ

汎用I/O

イーサネット・インタフェース

CompactFlash インタフェース

LCD 画面

イーサネット MAC/PHY

コンパクト・フラッシュ

ボタン、 LEDなど

送信受信

ソフトウェア・デバッガとのJTAG接続

クロック

リセット

データ

命令

1–2 Altera CorporationNios II プロセッサ・リファレンス・ハンドブック 2004年 9月

概要

アルテラ提供のリファレンス・デザインを使用して、プロトタイプ・システムがデザイン要件を十分に満たす場合は、そのリファレンス・デザインをコピーして、最終ハードウェア・プラットフォームでそのまま使用できます。そうでない場合でも、設計者はコストや性能の要求を満たすように、Nios IIプロセッサ・システムをカスタマイズできます。

Nios IIプロセッサ・デザインのカスタマイズアルテラ FPGAは、プロセッサ・システムの機能の追加と性能強化を可能にする柔軟性を実現しています。一方で、不要なプロセッサ機能とペリフェラルを削除して、デザインをより小型で低コストのデバイスに適合させることが可能です。

アルテラ・デバイスのピンおよびロジック・リソースは変更可能なため、以下のような多数のカスタマイズを実行できます。

■ ボード・デザインがより簡単になるようにチップのピンを再配置できます。例えば、外部 SDRAMメモリ用のアドレス・ピンとデータ・ピンをチップの任意の側面に移動して、ボード・トレースを短くすることができます。

■ チップの余分なピンとロジック・リソースは、プロセッサに関係のない機能に使用できます。余分なリソースはボード・デザイン用の「グルー・ロジック」として何個かのゲートやレジスタに利用したり、あるいはシステム全体を実装することも可能です。例えば、Nios IIプロセッサ・システムは大規模なアルテラ FPGA の 5% しか消費しないため、残りのチップ・リソースを利用して他の機能を実装することができます。

■ チップの余分なピンとロジックは、Nios II プロセッサ・システム用の追加ペリフェラルの実装に使用できます。アルテラは、Nios II プロセッサ・システムに容易に接続可能な多数のペリフェラル・ライブラリを提供しています。

実際に、大部分の FPGAデザインでは、Nios IIプロセッサ・システムに加えて、何らかのロジックが実装されています。プログラマが Nios IIプロセッサを使用する場合、追加ロジックに配慮する必要はありません。

Altera Corporation 1–32004年 9月 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 プロセッサ・システムに簡単に統合することが可能です。

システム生成の後、デザインをボードにプログラムし、ソフトウェアをボードで実行しながらデバッグできます。デザインをボードにプログラムすると、プロセッサ・アーキテクチャは固定されます。ソフトウェア開発は、コンフィギュレーションが不可能な従来型のプロセッサと同様に進められます。




NII51002-1.2

ます。こちらの日本語版は参考用としてご利用ください。

2. プロセッサ・アーキテクチャ

ください。

はじめにこの章では、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 ]

2–1

プロセッサの実装

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 IICustom 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 SpecificationReference Manual」を参照してください。

メモリ・アクセスとペリフェラル・アクセス

Nios IIアーキテクチャでは、メモリ・マップド I/Oアクセスが利用できます。データ・メモリとペリフェラルはともに、データ・マスタ・ポートのアドレス空間にマップされます。Nios IIアーキテクチャはリトル・エンディアンです。ワードとハーフワードは、上位アドレスを上位バイトとしてメモリに格納されます。

プログラム・カウンタ

Nios IIプロセッサ・コア

データ・キャッシュ

命令キャッシュ

メモリ・アクセス

ペリフェラル・アクセス

命令フェッチ

汎用レジスタ・ファイル

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

M M

M

S

Avalon マスタ・ポート

Avalon スレーブ・ポートS

メモリ

SAvalon スレーブ・ペリフェラル



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の一部であり特に注意が必要です。

■ リセット・アドレス■ 例外アドレス■ ブレーク・ハンドラ・アドレス

プログラマは、標準的なプログラム構成を使用してメモリとペリフェラルにアクセスします。したがって、アプリケーション開発者がこの柔軟なアドレス・マップを意識する必要はありません。


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デバッグ・モジュールのハードウェア・トリガ機能を使用して実現されます。

ハードウェア・トリガ

ハードウェア・トリガは、リアルタイム・プログラム実行中の命令バスまたはデータ・バスの状態に基づいて、デバッグ動作をアクティブにします。トリガは単にプロセッサの実行を停止するだけではありません。例えば、リアルタイム・プロセッサ実行中のトレース・データ収集をイネーブルするのにも使用できます。

表 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 接続によってのみアクセス可能）

■ トレース・データをオフチップ・デバッグ・プローブの大規模バッファに格納する。

一部のトレース機能には、サードパーティのデバッグ・プロバイダが提供する追加ライセンスまたはデバッグ・ツールが必要です。例えば、オンチップ・トレース・バッファは Nios II プロセッサの標準機能ですが、オフチップ・トレース・バッファを使用するには、First Silicon Solutions（FS2）が提供する別のデバッグ・ソフトウェアとハードウェアが必要です。詳細については、www.fs2.comをご覧ください。

実行とデータ・トレース

JTAG デバッグ・モジュールは、命令バスのトレース（実行トレース）、データ・バスのトレース（データ・トレース）、あるいは同時にその両方のトレースをサポートしています。実行トレースでは、実行された命令のアドレスのみが記録されるため、設計者はメモリ内のどの場所（すなわち、どの関数）でコードが実行されたかを解析できます。データ・トレースでは、データ・バス上の各ロードおよびストア操作に関連するデータが記録されます。

JTAG デバッグ・モジュールは、リアルタイムでデータ・バス・トレースをフィルタして、以下のキャプチャを実行できます。

■ ロード・アドレスのみ■ ストア・アドレスのみ■ ロード・アドレスとストア・アドレスの両方■ ロード・データのみ■ ロード・アドレスとロード・データ■ ストア・アドレスとストア・データ■ ロードとストア両方のアドレスとデータ■ トリガ・イベント時のデータ・バスのシングル・サンプル



フレームのトレース

「フレーム」とは、トレース・データの収集用に割り当てられたメモリ単位です。ただし、フレームはトレースの深さを示す絶対的な尺度ではありません。

リアルタイムで動作中のプロセッサを追跡するために、実行トレースは、分岐、呼び出し、トラップ、割り込みなど、選択したアドレスのみを保存するように最適化されています。これらのアドレスから、ホスト側のデバッグ・ソフトウェアは、厳密な命令ごとの実行トレースを後で再構築することができます。さらに、実行トレース・データは、1つのフレームが複数の命令を表すような圧縮形式で保存されます。これらの最適化によって、実行中におけるトレース収集の実際の開始点と停止点は、ユーザが指定した開始点および停止点とわずかに異なる場合があります。

データ・トレースでは、要求されたロードおよびストアの 100% がリアルタイムでトレース・バッファに格納されます。トレース・バッファへの格納時には、データ・トレース・フレームの優先順位は実行トレース・フレームより低くなります。したがって、データ・フレームは常に古いものから順に格納されますが、実行トレースとデータ・トレースが互いに正確に同期しているかどうかは保証されません。






NII51003-1.2

3. プログラミング・モデル

ます。こちらの日本語版は参考用としてご利用ください。ください。

はじめにこの章では、アセンブリ言語レベルでのプロセッサ機能を中心に、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ページの「動作モード」を参照してください。

3–1

汎用レジスタ

表 3–1. Nios IIレジスタ・ファイル

汎用レジスタ

レジスタ名称機能レジスタ名称機能

r0 zero 0x00000000 r16

r1 at 一時的なアセンブラ r17

r2 戻り値 r18

r3 戻り値 r19

r4 レジスタ引数 r20




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 0ctl0 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の場合は、対応する割り込みがディセーブルされていることを意味します。


ipending (ctl4)

ipendingレジスタの値は、どの割り込みがペンディング中であるかを示します。ビット nの値が 1の場合は対応する irqn入力がアサートされ、対応する割り込みが ienable レジスタでイネーブルされていることを意味します。ipendingレジスタに値を書き込んだ場合の影響は不定です。



cpuid (ctl5)

cpuidレジスタは、マルチプロセッサ・システムでプロセッサを一意に識別するスタティック値を保持します。cpuidの値はシステム生成時に決定されます。cpuidレジスタに値を書き込んでも無効となります。


動作モード 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 章「例外処理」を参照してください。

例外タイプ

Nios IIの例外は以下のカテゴリに分類されます。

■ ハードウェア割り込み■ ソフトウェア・トラップ■ 未実装命令■ その他

各例外タイプについては、以下のセクションで詳細に説明します。

ハードウェア割り込み

ペリフェラル・デバイスなどの外部ソースは、プロセッサの 32個の割り込み要求入力、irq0から irq31のいずれかをアサートすることによって、ハードウェア割り込みを要求できます。ハードウェア割り込みは、以下の 3つの条件がすべて満たされた場合にのみ生成されます。

■ statusレジスタ（ctl0）の PIEビットが 1■ 割り込み要求入力 irqnがアサートされている■ ienableレジスタ（ctl3）の対応するビット nが 1

ハードウェア割り込み時に PIEビットは 0に設定され、以降の割り込みをディセーブルします。ipendingレジスタ（ctl4）の値は、どの割り込み要求（IRQ）がペンディングされているかを示します。ペリフェラル・デザインによって、プロセッサが明示的にペリフェラルに応答するまで、IRQビットは必ずアサートされたままです。図 3-2に、ipending、ienable、PIE、および割り込みの生成の関係を示します。


例外処理

図 3-2. ienable、ipending、PIEおよびハードウェア割り込みの関係

ソフトウェア例外ルーチンは、ペンディング中の割り込みでどれが最も優先順位が高いかを判定し、適切な割り込みサービス・ルーチン（ISR）に制御を移します。ISRは、復帰前または PIEを再イネーブルする前に、割り込みを認識できないようにする（ソースでクリアするか、ienableを使用してマスクする）必要があります。また ISR は、PIE を再イネーブルする前に、estatus（ctl1）と ea（r29）を保存しなければなりません。

割り込みは、PIEビットに 1を書き込むと再イネーブルでき、それによって現在の ISR への割り込みを発生させることが可能です。通常、例外ルーチンは ienableを調整して、割り込みを再イネーブルする前に、優先順位が同じまたは低い IRQがディセーブルされるようにします。

3–13ページの「ネスト式例外」を参照してください。

IPE

ND

ING

0

IPE

ND

ING

1

IPE

ND

ING

2

ipendingレジスタ

IPE

ND

ING

3

irq0

irq1

irq2

irq3

31 0

IEN

AB

LE0

IEN

AB

LE1

IEN

AB

LE2

31 0

ienableレジスタ

外部ハードウェア割り込み要求入力

irq[31..0]

. . .

. . .

. . .

PIEビット

ハードウェア割り込みの生成



ソフトウェア・トラップ

プログラムで trap 命令を発行すると、ソフトウェア・トラップ例外が生成されます。通常、プログラムはオペレーティング・システムによる処理を必要とするときに、ソフトウェア・トラップを発行します。オペレーティング・システム用の例外ハンドラは、トラップの原因を特定し、適切に応答します。

未実装命令

プロセッサがハードウェアで実装されていない有効な命令を発行すると、未実装命令例外が生成されます。例外ハンドラは例外を生成した命令を特定します。その命令がハードウェアで実装されていない場合は、ソフトウェアで動作をエミュレートする例外ルーチンに制御が渡されます。

詳細については、3–24ページの「未実装の可能性がある命令」を参照してください。

「未実装命令」は「無効な命令」を意味するものではないことに注意してください。未定義つまり無効な命令ワードに対するプロセッサの動作は、Nios IIコアによって異なります。大部分のNios IIコア実装では、無効な命令を実行したときの結果は不定です。詳細については、第17章の「Nios IIコア実装の詳細」を参照してください。

その他の例外

ここまでのセクションでは、本書の発行時点で Nios II アーキテクチャによって定義されているすべての例外タイプについて説明しています。ただし、一部のプロセッサ実装では、上記のカテゴリに分類されない例外が生成される可能性があります。例えば、今後の実装では、アクセス違反例外を生成するメモリ管理ユニット（MMU）が搭載される可能性があります。したがって、例外ハンドラの堅牢なものにするには、例外の原因を正確に特定できない場合は安全な応答（警告を発行するなど）を提供することが必要です。

例外の原因の特定

例外ハンドラは、各例外の原因を特定し、適切な例外ルーチンに制御を移すことが必要です。図 3-3 に、例外のソースを特定するのに使用されるプロセスの例を示します。


例外処理

図 3-3.例外の原因を特定するプロセス

estatusレジスタ（ctl1）の EPIEビットが 1で、ipendingレジスタ（ctl4）の値がゼロでない場合、例外は外部ハードウェア割り込みによって発生しています。そうでない場合、例外はソフトウェア・トラップまたは未実装命令によって発生した可能性があります。ソフトウェア・トラップと未実装命令を区別するには、アドレス ea–4の命令を読み出します（このアドレスを読み出すには、Nios IIデータ・マスタがコード・メモリにアクセスできることが必要です）。命令が trapであれば、例外はソフトウェア・トラップです。アドレス ea-4の命令が、ソフトウェアで実装された可能性のある命令の場合、例外は未実装命令によって発生しています。詳細については、3–24ページの「未実装の可能性がある命令」を参照してください。上記のいずれの状態にも該当しない場合、例外タイプは認識されないため、例外ハンドラはその状態を報告する必要があります。

例外ハンドラへ移動

(EPIE == 1)&(ipending != 0)?

（ea-4）の命令はトラップか?

（ea-4）の命令は、 div、mul、mulxuuなどか?

はい

はい

はい

いいえ

ハードウェア割り込みの処理

ソフトウェア・トラップの処理

未実装命令の処理

いいえ

その他の例外

いいえ



ネスト式例外

例外ルーチンでは、以下を実行する前に、特別な対策が必要です。

■ trap命令の発行■ 未実装命令の発行■ ハードウェア割り込みの再イネーブル

これらの動作を許可する前に、例外ルーチンは estatus（ctl1）および ea（r29）を保存して、復帰前にこれらを正しく復元できるようにしておく必要があります。

例外からの復帰

eret 命令は、例外発生前のアドレスから実行を再開するのに使用されます。et レジスタ（r24）を除いて、例外処理中に変更されるレジスタは、例外処理から復帰する前に例外ルーチンで復元する必要があります。

eret命令の実行時に、プロセッサは以下を行います。

1. estatus（ctl1）の内容を status（ctl0）にコピーする

2. プログラムの実行を eaレジスタ（r29）のアドレスに移す

戻りアドレス

戻りアドレスについては、例外処理ルーチンから復帰する場合に多少の考慮が必要です。例外が発生すると、eaには、例外が生成された位置より後の命令のアドレスが格納されます。

ソフトウェア・トラップおよび未実装命令例外から復帰するときには、ソフトウェア・トラップまたは未実装命令に続く命令から実行を再開する必要があります。したがって、eaには正しい戻りアドレスが格納されています。

それに対して、ハードウェア割り込み例外では、割り込みを受けた命令自体から実行を再開することが必要です。この場合、例外ハンドラは割り込みを受けた命令を指すように、eaから4を減算する必要があります。


ブレーク処理

ブレーク処理ブレークとは、break命令または JTAGデバッグ・モジュールによって、プログラムの通常の実行フローから制御を移すことです。ソフトウェア・デバッグ・ツールでは、JTAGデバッグ・モジュールを介してNios IIプロセッサを制御することができます。デバッグ・モードで実行する場合は、デバッグ・ツールのみがプロセッサを制御し、アプリケーションとシステム・コードはこのモードでは実行できません。

ブレーク処理は、ソフトウェア・デバッグ・ツールがブレークポイントやウォッチポイントなどのデバッグ機能や診断機能を実現する手段です。ブレーク処理は例外処理と類似していますが、ブレーク・メカニズムは例外処理から独立しています。ブレークは例外処理中でも発生させることができるため、デバッグ・ツールで例外ハンドラのデバッグが可能できます。

ブレークの処理

プロセッサは、以下の条件でブレーク処理状態に入ります。

■ プロセッサが break命令を発行する■ JTAGデバッグ・モジュールがハードウェア・ブレークをアサートする

ブレークが発生すると、プロセッサは以下の処理を自動的に実行します。プロセッサは、

1. statusレジスタ（ctl0）の内容を bstatus（ctl2）に格納します。

2. status レジスタのUビットをクリアして、プロセッサを強制的にスーパバイザ・モードにします。

3. status レジスタの PIE ビットをクリアして、外部プロセッサ割り込みをディセーブルします。

4. ブレークに続く命令のアドレスを ba（r30）レジスタに書き込みます。

5. 実行をブレーク・ハンドラのアドレスに移します。ブレーク・ハンドラのアドレスは、システム生成時に指定されます。

ブレークからの復帰

デバッグ・ツールは、ブレーク処理を実行した後、bret 命令を実行してプロセッサの制御を解放します。bret命令は、statusを復元し、ba内のアドレスにプログラムの実行を戻します。

レジスタの使用

ブレーク・ハンドラは、bt（r25）を使用して、追加レジスタの保存に役立てることができます。btを除くすべてのレジスタは、ブレーク処理ルーチンからの復帰後に必ずブレーク前の状態に戻ります。



メモリ・アクセスとペリフェラル・アクセス

Nios IIのアドレスは 32ビットであり、最大 4ギガバイトのアドレス空間にアクセス可能です。しかし、多くの Nios II コア実装では、アドレスは31ビット以下に制限されています。詳細については、第 17章の「Nios IIコア実装の詳細」を参照してください。ペリフェラル、データ・メモリ、およびプログラム・メモリは同じアドレス空間にマップされます。アドレス空間内のメモリとペリフェラルの位置は、システム生成時に決定されます。メモリまたはペリフェラルにマップされないアドレスに読み書きを行った場合、結果は不定です。

プロセッサのデータ・バスの幅は 32ビットです。バイト、ハーフワード（16ビット）、またはワード（32ビット）データの読み出しと書き込みを実行する命令が用意されています。

Nios IIアーキテクチャはリトル・エンディアンです。9ビット以上の幅のデータがメモリ内に格納される場合、上位ビットが上位アドレスに配置されます。

アドレス指定モード

Nios IIアーキテクチャは以下のアドレス指定モードをサポートしています。

■ レジスタ・アドレス指定■ ディスプレースメント・アドレス指定■ 即値アドレス指定■ レジスタ間接アドレス指定■ 絶対アドレス指定

レジスタ・アドレス指定では、すべてのオペランドがレジスタとなり、結果はレジスタに再格納されます。ディスプレースメント・アドレス指定では、アドレスはレジスタと符号付き 16ビット即値として計算されます。即値アドレス指定では、オペランドは命令自体に含まれる定数です。レジスタ間接アドレス指定は、ディスプレースメント・アドレス指定を使用しますが、ディスプレースメントは定数 0です。限定範囲の絶対アドレス指定は、常に値が 0x00のレジスタ r0によるディスプレースメント・アドレス指定を使用して実行されます。


プロセッサのリセット状態

キャッシュ・メモリ

Nios IIのアーキテクチャと命令セットは、データ・キャッシュ・メモリと命令キャッシュ・メモリの有無に対応しています。キャッシュ管理は、キャッシュ管理命令を使用してソフトウェアで実行されます。キャッシュの初期化、必要に応じたキャッシュのフラッシュ、およびデータ・キャッシュのバイパスによるメモリ・マップド・ペリフェラルへの適切なアクセスを行う命令が用意されています。

一部の Nios II プロセッサ・コアは、アドレスの最上位ビットの値に応じてキャッシュをバイパスする、ビット 31キャッシュ・バイパスと呼ばれるメカニズムをサポートしています。これらのプロセッサの実装アドレス空間は 2 Gバイトで、アドレスの上位ビットはデータ・メモリ・アクセスのキャッシュ処理を制御します。ビット 31キャッシュ・バイパスをサポートするプロセッサ・コアの詳細については、第 17章の「Nios IIコア実装の詳細」を参照してください。

キャッシュ・メモリを搭載したプロセッサ・コア用に記述されたコードは、キャッシュ・メモリを搭載していないプロセッサ・コア上でも正常に動作します。ただし、その逆は成り立ちません。したがって、プログラムがすべてのNios IIプロセッサ・コア実装で正常に動作するには、プログラムは命令キャッシュとデータ・キャッシュが存在するものとして動作する必要があります。キャッシュ・メモリを搭載しないシステムでは、キャッシュ管理命令は動作しないため影響はありません。キャッシュ管理の詳細な説明は、「Nios II ソフトウェア開発ハンドブック」を参照してください。

プロセッサ・リセット後のキャッシュ・コヒーレンシを保証するには、若干の考慮が必要です。詳細については、この章の 3–16ページの「プロセッサのリセット状態」を参照してください。キャッシュ・アーキテクチャおよびメモリ階層の詳細については、第 2章の「プロセッサ・アーキテクチャ」を参照してください。

プロセッサのリセット状態

リセット後に、Nios IIプロセッサは以下を実行します。

1. statusレジスタを 0x0にクリアします。

2. リセット・アドレス、つまりリセット・ルーチンのアドレスに関連付けられた命令キャッシュ・ラインを無効化します。

3. リセット・アドレスから実行を開始します。



status（ctl0）をクリアすると、プロセッサがスーパバイザ・モードになり、ハードウェア割り込みをディセーブルします。リセット・キャッシュ・ラインを無効化すると、リセット・コードの命令フェッチは必ず非キャッシュ・メモリから行われます。リセット・アドレスは、システム生成時に指定されます。

リセット・アドレスに関連付けられた命令キャッシュ・ラインを除いて、キャッシュ・メモリの内容はリセット後も不定です。リセット後のキャッシュ・コヒーレンシを保証するには、リセット・ルーチンが命令キャッシュを即座に初期化する必要があります。次に、リセット・ルーチンまたは後続のルーチンのいずれかが、データ・キャッシュの初期化を実行することが必要です。

リセット状態は、以下を含む（ただし、これらに限定されない）その他すべてのシステム・コンポーネントに対して不定です。

■ 汎用レジスタ：ただし、永久にゼロである zero（r0）は除きます。■ コントローラ・レジスタ：ただし、0x0にリセットされる status（ctl0）は除きます。

■ 命令およびデータ・メモリ■ キャッシュ・メモリ：ただし、リセット・アドレスに関連付けられた命令キャッシュ・ラインは除きます。

■ ペリフェラル：リセット条件については、該当するペリフェラル・データ・シートまたは仕様を参照してください。

■ カスタム命令ロジック：リセット条件については、カスタム命令の仕様を参照してください。

命令セットのカテゴリ

このセクションでは、実行される処理のタイプ別に、Nios II命令について説明します。

データ転送命令

Nios II アーキテクチャは、ロード / ストア・アーキテクチャの一種です。レジスタ、メモリ、およびペリフェラル間のすべてのデータ移動は、ロード命令とストア命令によって処理されます。メモリとペリフェラルは共通アドレス空間を共有します。一部の Nios IIプロセッサ・コアは、メモリ・キャッシングと書き込みバッファリングの両方または一方を使用して、メモリ帯域幅を向上させています。このアーキテクチャは、キャッシュ・アクセスと非キャッシュ・アクセスの両方に対する命令を提供しています。



表 3–4で、ldw、stw、ldwio、および stwio命令について説明します。

表 3–5のデータ転送命令は、バイト転送とハーフワード転送をサポートしています。

表 3–4.データ転送命令（ldw、stw、ldwioおよび stwio）

命令説明

ldwstw

ldwおよび stw命令はそれぞれ、32ビット・データ・ワードをメモリからロード /メモリに格納します。有効アドレスは、レジスタの内容と命令に含まれる符号付き即値との合計です。メモリ転送をキャッシュまたはバッファリングすると、プログラムの性能を向上させることができます。このキャッシングおよびバッファリングによってメモリ・サイクルの発生が乱れたり、キャッシングによって一部のサイクルが完全に抑制されることがあります。

I/Oペリフェラルのデータ転送では、ldwioおよび stwioを使用する必要があります。

ldwiostwio

ldwioおよび stwio命令はそれぞれ、キャッシングやバッファリングを行わずに、32ビット・データ・ワードをペリフェラルからロード /ペリフェラルに格納します。ldwioおよび stwio命令のアクセス・サイクルは、命令の順番どおり発生することが保証されており、抑制されることはありません。

表 3–5.データ転送命令

命令説明

ldbldbustbldhldhusth

ldb、ldbu、ldh、および ldhu はバイトまたはハーフワードをメモリからレジスタにロードします。ldbおよび ldhは値を 32ビットに符号拡張し、ldbuおよび ldhuは値を 32ビットにゼロ拡張します。 stbおよび sthはそれぞれ、バイト値およびハーフワード値を格納します。メモリ・アクセスをキャッシュまたはバッファして、性能を向上させることができます。データを I/Oペリフェラルに転送するには、後述する命令の「io」バージョンを使用します。

ldbioldbuiostbioldhioldhuiosthio

これらの処理では、キャッシングまたはバッファリングを行わずに、バイトおよびハーフワード・データをペリフェラルからロード /ペリフェラルに格納します。



算術命令と論理命令

論理命令は and、or、xor、および nor演算をサポートしています。算術命令は、加算、減算、乗算、および除算演算をサポートしています。表 3–6を参照してください。

表 3–6.算術命令と論理命令

命令説明

andorxornor

これらは標準的な 32ビット論理演算です。これらの演算は、2つのレジスタ値を受け取り、ビット単位で結合して、第 3のレジスタに対する結果を生成します。

andiorixori

これらの演算は、and、or、および xor 命令の即値バージョンです。16 ビットの即値が 32ビットにゼロ拡張され、レジスタ値と結合されて結果を生成します。

andhiorhixorhi

and、or、および xor のこれらのバージョンでは、16 ビットの即値が論理的に 16 ビット左シフトされ、32ビットのオペランドを生成します。右からゼロがシフト・インされます。

addsubmuldivdivu

これらは標準的な 32ビット算術演算です。これらの演算では、2つのレジスタを入力として受け取り、結果を第 3のレジスタに格納します。

addisubimuli

これらの命令は、add、sub、および mul命令の即値バージョンです。命令ワードには符号付き 16ビット値が含まれます。

mulxssmulxuu

これらの命令は、32x32乗算演算の上位 32ビットへのアクセスを提供します。オペランドを符号付き値または符号なし値のどちらで扱うかに応じて、適切な命令を選択します。これらの命令の前に mulを付ける必要はありません。

mulxsu この命令は、64x64符号付き乗算の 128ビット結果を計算するのに使用されます。



移動命令

これらの命令は、レジスタの値または即値を別のレジスタにコピーする移動操作を実現します。表 3–7を参照してください。

比較命令

Nios IIアーキテクチャは、多数の比較命令をサポートしています。これらの比較命令はすべて、2 つのレジスタまたは 1 つのレジスタと即値を比較し、結果レジスタに 1（真の場合）または 0 を書き込みます。これらの命令はCプログラミング言語の等号演算子および関係演算子をすべて実行します。表 3–8を参照してください。

表 3–7.移動命令

命令説明

movmovhimovimovuimovia

movはあるレジスタの値を別のレジスタにコピーします。moviは 16ビットの符号付き即値をレジスタに移動し、値を 32 ビットに符号拡張します。movui および movhi はそれぞれ、レジスタの下位または上位 16ビットに、16ビットの即値を移動し、残りのビット位置にゼロを挿入します。レジスタにアドレスをロードするには、moviaを使用します。

表 3–8.比較命令 (１ /２ )

命令説明

cmpeq ==

cmpne !=

cmpge 符号付き >=

cmpgeu 符号なし >=

cmpgt 符号付き >

cmpgtu 符号なし >

cmple 符号なし <=

cmpleu 符号なし <=

cmplt 符号付き <



シフト命令と回転命令

シフトおよび回転操作は以下の命令で提供されます。回転またはシフトするビット数は、レジスタ内にまたは即値で指定できます。表 3–9を参照してください。

cmpltu 符号なし <

cmpeqicmpneicmpgeicmpgeuicmpgticmpgtuicmpleicmpleuicmplticmpltui

これらの命令は比較演算の即値バージョンです。レジスタの値と 16 ビットの即値を比較します。符号付き演算では、即値が 32 ビットに符号拡張されます。符号なし演算では上位ビットにゼロが入ります。

表 3–8.比較命令 (２ /２ )

命令説明

表 3–9.シフト命令と回転命令

命令説明

rolrorroli

rol 命令と roli 命令は、左ビット回転を実行します。roli は即値を使用して、回転するビット数を指定します。ror命令は右ビット回転を実行します。 roliを使用して同等の演算が実行できるため、rorの即値バージョンはありません。

sllsllisrasrlsraisrli

これらのシフト命令は、Cプログラミング言語の <<演算子および >>演算子の動作を実現します。sll、slli、srl、srli命令は、左および右論理ビット・シフト操作を実行し、ゼロを挿入します。sraおよび srai命令は、算術右ビット・シフトを実行し、最上位ビットの符号ビットを複製します。slli、srli、および sraiは、即値を使用して、シフトするビット数を指定します。



プログラム制御命令

Nios II アーキテクチャは、表 3–10 に示す無条件ジャンプと呼び出し命令をサポートしています。これらの命令には遅延スロットはありません。

条件付き分岐命令は、レジスタ値を直接比較し、式が真の場合は分岐します。表 3–11を参照してください。条件付き分岐は、Cプログラミング言語の以下の等号比較および関係比較をサポートしています。

■ ==および !=■ <および <=（符号付きおよび符号なし）■ >および >=（符号付きおよび符号なし）

条件付き分岐命令には遅延スロットはありません。

表 3–10.無条件ジャンプと呼び出し命令

命令説明

call この命令は、即値をサブルーチンの絶対アドレスとして使用してサブルーチンを呼び出し、レジスタ raに戻りアドレスを格納します。

callr この命令は、レジスタ内の絶対アドレスに置かれているサブルーチンを呼び出して、戻りアドレスをレジスタ raに格納します。この命令は C関数ポインタを逆参照する役割を果たします。

ret ret 命令は、call または callr で呼び出されたサブルーチンから復帰するために使用されます。retは、レジスタ raのアドレスで指定される命令をロードして実行します。

jmp jmp 命令は、レジスタに格納された絶対アドレスへのジャンプを実行します。jmp は、C プログラミング言語の switch文を実現するのに使用されます。

br 現在の命令に相対的な分岐。符号付き即値で、次に実行する命令のオフセットを設定します。

表 3–11.条件付き分岐命令

命令説明

bgebgeubgtbgtublebleubltbltubeqbne

これらの命令は、2つのレジスタ値を比較する相対分岐を実現し、式が真の場合は分岐します。実装されている関係演算の説明は、3–20 ページの「比較命令」を参照してください。



その他の制御命令

表 3–12に、その他の制御命令を示します。

カスタム命令

custom 命令は、カスタム命令ロジックへの低水準アクセスを提供します。カスタム命令の組み込みはシステム生成時に指定され、カスタム命令ロジックで実装される機能はデザインによって決まります。詳細については、第 2章の「プロセッサ・アーキテクチャ」の 2–4ページの「カスタム命令」および「Nios II Custom Instruction User Guide」を参照してください。

マシン生成された C関数とアセンブリ・マクロを利用すると、カスタム命令へのアクセスが可能になり、実装の詳細がユーザから隠蔽されます。したがって、ほとんどのソフトウェア開発者は、custom アセンブリ命令を直接使用することはありません。

表 3–12.その他の制御命令

命令説明

traperet

trap命令と eret命令は、例外を生成して、例外から戻ります。これらの命令は、call/retのペアと類似していますが、例外に対して使用されます。trap は status レジスタの内容を estatusレジスタに、戻りアドレスを eaレジスタに保存してから例外ハンドラに実行を移します。eretは、estatusから statusを復元し、eaのアドレスで指定された命令を実行して例外処理から復帰します。

breakbret

break 命令はブレークを生成し、bret 命令はブレークから復帰します。break と bretは、ソフトウェア・デバッグ・ツールによって排他的に使用されます。プログラマがアプリケーション・コードでこれらの命令を使用することはありません。

rdctlwrctl

これらの命令は、statusレジスタなどのコントロール・レジスタに読み出しと書き込みを行います。値は 1つの汎用レジスタに読み書きされます。

flushdflushiinitdiniti

これらの命令は、データ・キャッシュ・メモリと命令キャッシュ・メモリの管理に使用されます。

flushp この命令は、プリフェッチされたすべての命令をパイプラインからフラッシュします。この処理は、最近変更された命令メモリにジャンプする前に実行する必要があります。

sync この命令を実行すれば、すでに発行されたすべての操作が完了してから、後続のロードおよびストア操作が許可されるようになります。



無動作命令

Nios IIアセンブラでは、無動作命令 nopが利用できます。

未実装の可能性がある命令

Nios IIプロセッサ・コアには、ハードウェアですべての命令をサポートしていないものもあります。その場合、プロセッサは、未実装命令を発行した後で例外を生成します。未実装命令例外を生成できるのは、以下の命令のみです。

■ mul■ muli■ mulxss■ mulxsu■ mulxuu■ div■ divu

その他のすべての命令は、未実装命令例外を生成しないことが保証されています。

例外ルーチンで上記の命令を使用する場合、それまでの例外が適切に処理される前に別の例外が発生する可能性があるため、注意が必要です。未実装命令の処理に関する詳細は、3–11ページの「未実装命令」を参照してください。




NII51004-1.2

ます。こちらの日本語版は参考用としてご利用ください。

4. SOPC Builder でのNios IIプロセッサの実装

ください。

はじめにこの章では、SOPC BuilderでのNios® IIコンフィギュレーション・ウィザードについて説明します。Nios IIコンフィギュレーション・ウィザードにより、特定の Nios II ハードウェア・システムに対してプロセッサ機能を指定することができます。この章では、Nios IIコンフィギュレーション・ウィザードによってコンフィギュレーション可能な Nios II プロセッサの機能についてのみ説明します。本書は、完全な Nios II プロセッサ・システムを作成するためのユーザ・ガイドではありません。

SOPC Builderを使用してカスタム Nios IIシステムの設計を開始するには、Nios II Hardware Development Tutorialを参照してください。また、Nios II 開発キットには、Nios II プロセッサの何種類かの構成の既製のハードウェア・デザイン例が多数用意されています。

Nios II プロセッサ・コンフィギュレーション・ウィザードには、いくつかのタブがあります。以下のセクションでは、各タブで可能な設定について説明します。

Nios II コンフィギュレーション・ウィザードの進化と改良によって、この章で示されている図が SOPC Builder で実際に表示される画面と一致しなくなる可能性があります。

4–1

Nios II Coreタブ

Nios II Coreタブ

Nios II Core タブでは、Nios II プロセッサ・コアをコンフィギュレーションするための主要な設定が表示されます。Nios II Coreタブの例を図 4-1に示します。

図 4-1. Nios IIコンフィギュレーション・ウィザードの Nios II Coreタブ

コアの設定

Nios II Coreタブの主な目的は、プロセッサ・コアを選択することです。このタブで選択するコアによって、このタブやその他のタブで利用できるオプションが変化します。

現在、アルテラは以下の 3つのNios IIコアを提供しています。

■ Nios II/f－ Nios II/fの「高速」コアは、高速性能を達成するように設計されています。そのため、このコアには大部分の構成オプションが提供されており、プロセッサを微調整して性能を高めることができます。

■ Nios II/s－Nios II/sの「標準」コアは、性能を維持しながら小型化を実現するように設計されています。

■ Nios II/e－Nios II/eの「エコノミー」コアは、可能な限り最小のコア・サイズを達成するように設計されています。そのため、このコアの機能セットは限定されており、Nios II/eコアを選択した場合は多数の設定が利用できなくなります。


SOPC Builder での Nios IIプロセッサの実装

4–2ページの図 4-1に示すように、Nios II Coreタブは、各コアの基本プロパティをリストする「Selector Guide」テーブルを表示します。各コアの詳細については、第 17 章の「Nios II コア実装の詳細」を参照してください。

キャッシュ設定

命令キャッシュとデータ・キャッシュの両方または一方をサポートするNios IIコアの場合、Nios II Coreタブでキャッシュ設定をコンフィギュレーションできます。キャッシュが存在する場合は、キャッシュのサイズをコンフィギュレーションできます。キャッシュ・メモリの容量が増えるほど、オンチップ・メモリ・リソースの消費量も増大します。

最適なキャッシュ設定は、ターゲット・アプリケーションによって決まります。一般に、命令キャッシュは、性能重視のソフトウェア・ループよりも大きなサイズにコンフィギュレーションし、データ・キャッシュは性能重視のソフトウェア・ループで使用されるデータ・バッファを十分に格納できるサイズに構成することが必要です。

Nios II キャッシュ・メモリを使用したプログラミングの詳細については、「Nios II ソフトウェア開発ハンドブック」のキャッシュ・メモリの章を参照してください。

乗算および除算の設定

Nios II/sコアと Nios II/fコアは、異なるハードウェア乗算および除算オプションを提供します。エンベデッド乗算器の使用、ロジック・エレメント（LE）の使用、および性能の間でバランスを図るための最良のオプションを選択できます。

Hardware Multiply設定では、以下のオプションを選択できます。

■ エンベデッド乗算器（つまり、Stratixデバイス等の DSPブロック）を論理演算ユニット（ALU）に搭載する。これは、エンベデッド乗算器を搭載したデバイスをターゲットとする場合のデフォルトです。

■ LE ベースの乗算器を ALU に搭載する。このオプションはエンベデッド乗算器リソースを消費しないで高度な乗算器性能を実現します。

■ ハードウェア乗算を省略する。このオプションでは、乗算ハードウェアを削除してロジック・リソースを節約します。乗算演算はソフトウェアでエミュレートされます。

Hardware Divide 設定をオンにすると、LE ベースの除算ハードウェアが ALU ユニットに搭載されます。Hardware Divide オプションでは、ソフトウェア・エミュレーションよりも大幅に高い性能が得られます。


JTAG Debug Moduleタブ

Hardware Multiply オプションおよび Hardware Divide オプションが性能に及ぼす影響の詳細については、本ハンドブックの「Nios IIコア実装の詳細」の章を参照してください。


JTAG Debug Moduleタブには、Nios IIコアの JTAGデバッグ・モジュールをコンフィギュレーションするための設定が表示されます。ターゲット・アプリケーションに適したデバッグ機能を選択することができます。

Nios IIプロセッサなどのソフトコア・プロセッサは、従来型の固定プロセッサにはない独自のデバッグ機能を提供します。Nios IIプロセッサのソフトコア特性により、フル機能を備えたデバッグ・コアを使用して、開発中のシステムをデバッグし、後でデバッグ機能を削除してロジック・リソースを節約することができます。製品のリリース・バージョンでは、JTAG デバッグ・モジュール機能を削減したり、完全に削除するよう選択できます。

表 4–1に、システムのデバッグに使用可能なデバッグ機能を示します。

表 4–1.デバッグ・コンフィギュレーション機能

機能説明

JTAGターゲット接続アルテラ FPGA の標準 JTAG ピンを介して、CPU に接続する機能。この機能によって、プロセッサの開始および停止、レジスタとメモリの確認 /編集が可能になります。

ソフトウェアのダウンロード

JTAG接続を介して実行可能コードをプロセッサのメモリにダウンロードする機能。


RAM内に存在する命令に対してブレークポイントを設定する機能。

ハードウェア・ブレークポイント

フラッシュ・メモリなどの不揮発性メモリ内の命令に対してブレークポイントを設定する機能。

データ・トリガアドレス値、データ値、またはリード・サイクルやライト・サイクルに基づいてトリガする機能。トリガを使用して特定のイベントや条件でプロセッサを停止したり、実行トレースの開始や外部ロジック・アナライザへのトリガ信号の送信など、その他のイベントをアクティブ化することが可能です。2つのデータ・トリガを組み合わせて、一定のデータまたはアドレス範囲でアクティブになるトリガを形成できます。

オンチップ・トレース実行トレース・データをオンチップ・メモリに格納する機能。

オフチップ・トレーストレース・データを外部デバッグ・プローブに格納する機能。オフチップ・トレースには、First Silicon Solutions（FS2）が提供するデバッグ・プローブが必要です。



デバッグ・レベルの設定

図 4-2に示すように、JTAG Debug Moduleタブには 5つのデバッグ・レベルがあります。

図 4-2. Nios IIコンフィギュレーション・ウィザードの JTAG Debug Moduleタブ

4–6ページの表 4–2は、各デバッグ・レベルの特性の詳細なリストです。レベルによって消費されるオンチップ・リソース量が異なります。特定の Nios II コアではデバッグ・オプションが限定されます。また、オプションには、First Silicon Solutions（FS2）が提供するデバッグ・ツールが必要なものもあります。

FS2から使用可能なNios IIデバッグ機能の詳細については、www.fs2.comをご覧ください。



オンチップ・トレース・バッファ設定

デバッグ・レベル 3および 4では、オンチップ・メモリ・バッファ内へのトレース・データ収集がサポートされます。オンチップ・トレース・バッファのサイズは、128から 64Kトレース・フレームに設定できます。

バッファ・サイズが大きくなると、消費されるオンチップM4K RAMブロック数も増加します。すべてのM4K RAMブロックに、最大 128Kのトレース・フレームが格納できます。

表 4–2. JTAGデバッグ・モジュール・レベル

デバッグ機能デバッグなし

Level 1 Level 2 Level 3 Level 4 (1)

ロジック使用 0 300～ 400 LE 800～ 900 LE 2,400～ 2,700 LE 3,000～ 3,200 LE

オンチップ・メモリの使用

0 2個のM4K 2個のM4K 4個の M4K 4個の M4K

必要な外部 I/Oピン数(2)

0 0 0 0 20

JTAGターゲット接続不可可能可能可能可能可能可能可能

ソフトウェアのダウンロード

不可可能可能可能可能可能可能可能


なし無制限無制限無制限無制限無制限無制限無制限

ハードウェア実行ブレークポイント

0 なし 2 2 4

データ・トリガ 0 なし 2 2 4

オンチップ・トレース 0 なしなし最大最大最大最大 64Kフレームフレームフレームフレーム (3)

最大最大最大最大 64Kフレームフレームフレームフレーム

オフチップ・トレース(4)

0 なしなしなし 128Kフレームフレームフレームフレーム

表 4–2の注：の注：の注：の注：(1) Level4を使用するには、FS2からソフトウェア・アップグレードを購入する必要があります。(2) アルテラ FPGAの専用 JTAGピンは含まれません。(3) 16を超えるフレームを使用するには、FS2からの追加ライセンスが必要です。 (4) オフチップ・トレースを使用するには、FS2から追加ハードウェアを購入する必要があります。



Custom Instructionsタブ

Custom Instructionsタブでは、カスタム命令ロジックを Nios II論理演算ユニット（ALU）に接続できます。カスタム命令ロジックを使用して性能重視の処理をハードウェアに実装すれば、場合によっては 10倍から100倍と大幅に性能を改善できます。図 4-3は、Custom Instructionsタブの例を示します。

図 4-3. Nios IIコンフィギュレーション・ウィザードの Custom Instructionsタブ

カスタム命令のハードウェアおよびソフトウェア・デザイン・プロセスの詳細な説明は、この章の対象範囲外です。デザインの実用例など、カスタム命令に関するトピックの詳細については、「Nios II CustomInstruction User Guide」を参照してください。


Custom Instructionsタブ


Documents

セクション I. Nios II プロセッサ Corporation セクション I–1 セクションI. Nios II プロセッサ このセクションには、Nios® II プロセッサに関する情報が記載されてい

セクション I. Nios II プロセッサ Corporation セクション I–1 セクションI. Nios II プロセッサこのセクションには、Nios® II プロセッサに関する情報が記載されてい