Nios II EDS には、次の 2 つの密接に関連するソフトウェア開発ツールフローが含まれています。

• Nios II SBT
• Eclipse 用 Nios II SBT

両方のツールフローは、GNU C/C ++ コンパイラーに基づいています。Eclipse 用 Nios II SBT ™ は、ソフトウェア開発で使い慣れ、かつ確立された環境を提供します。Eclipse 用 Nios II SBT を使用すると、Nios II ソフトウェア・アプリケーションの開発とシミュレーションをすぐに開始することができます。

また、Nios II SBT はコマンドライン・インターフェイスも提供します。

アルテラの開発キットに付属の Nios II ハードウェア・リファレンス・デザインを使用すると、カスタム・ハードウェア・プラットフォームを構築する前にボード上で動作するアプリケーションをプロトタイプ作成できます。

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

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

• ボードデザインがより簡単になるようにチップのピンを再配置できます。例えば、外部 SDRAM メモリー用のアドレスピンとデータピンをチップの任意の側面に移動させ、ボードトレースを短くすることができます。
• チップの余分なピンとロジックリソースをプロセッサーに関係のない機能に使用できます。余分なリソースは、ボードデザイン用のグルーロジックとしてゲートやレジスターに利用するか、システム全体を実装することも可能です。例えば、Nios II プロセッサー・システムは大規模なアルテラ FPGA の 5％ しか消費しない場合、残りのチップリソースを利用して他の機能を実装することができます。
• チップの余分なピンとロジックは、Nios II プロセッサー・システム用の追加ペリフェラルの実装に使用できます。アルテラは、Nios II プロセッサー・システムに容易に接続可能な多数のペリフェラル・ライブラリーを提供しています。

新しいデザインごとに新たな Nios II プロセッサー・コンフィグレーションを作成する必要はありません。アルテラは、ユーザーがそのまま使用できる既成の Nios II システムデザインを提供しています。これらのデザインがシステム要求を満たす場合は、デザインをそれ以上構成する必要はありません。また、最終的なハードウェア・コンフィグレーションが確定する前に、Nios II 命令セット・シミュレーターを使用して、Nios II アプリケーションの記述とデバッグを開始することができます。

アルテラは、アドレス位置に関係なく、一般的にメモリーやペリフェラルにアクセスできるソフトウェアの構造を提供しています。したがって、アプリケーション開発者がペリフェラル・セットとアドレスマップの柔軟性を考慮する必要はありません。

ペリフェラルには、標準ペリフェラルとカスタム・ペリフェラルの 2 つのクラスがあります。

Nios II プロセッサー・システムでカスタム・コンポーネントを作成し、それらを統合することができます。大部分の CPU サイクルがコードの特定のセクションの実行に消費される性能重視のシステムの場合、一般的な方法はハードウェアで同じ機能を実行するカスタム・ペリフェラルを作成することです。

この方法は、性能面で二重の利点が得られます。

• ハードウェアでの実行がソフトウェアよりも高速である
• カスタム・ペリフェラルがデータを操作する間に、プロセッサーが並行して他の機能を実行できる

カスタムロジックは、Nios II プロセッサーの算術論理ユニット (ALU) に統合することができます。Nios II 固有の命令と同様、カスタム命令ロジックは、最大 2 個のソースレジスターから値を取得し、結果をデスティネーション・レジスターに書き込むことができます。

プロセッサーは再プログラム可能なアルテラ FPGA に実装されるため、ソフトウェア・エンジニアとハードウェア・エンジニアが連携して作業を進め、繰り返しハードウェアの最適化を行い、実際のハードウェア上でのソフトウェアの実行結果をテストできます。

ソフトウェアの観点では、カスタム命令はマシンで生成されたアセンブリー・マクロまたは C 関数のようなものなので、プログラマーがカスタム命令を使用するのにアセンブリー言語を理解する必要はありません。

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

• システム内の Nios II プロセッサーの動作をシミュレーション
• デザインの機能の検証と同様にサイズやスピードの迅速かつ簡単な評価
• Nios II プロセッサーを含むデザインへの時間制限付デバイス・プログラミング・ファイルの生成
• ハードウェア上でのデバイスのプログラミングとデザインの検証

機能および性能が十分満足できて、Nios II プロセッサーを製品に組み込む場合にのみ、ライセンスを購入していただく必要があります。

Nios II アーキテクチャーの機能ユニットは Nios II 命令セットの基礎を形成します。ただし、いずれかのユニットがハードウェアに実装されているという意味ではありません。Nios II アーキテクチャーは、特定のハードウェア実装ではなく、命令セットを記述します。機能ユニットは、ハードウェアに実装するか、ソフトウェアでエミュレートするか、あるいは完全に省略することができます。

Nios II 実装とは、特定の Nios II プロセッサー・コアで実現されるデザインの選択セットです。すべての実装が、命令セット・リファレンスで定義される命令セットをサポートします。

各実装は、コア・サイズの小型化や高性能化など、特定の目的を達成します。これにより、Nios II アーキテクチャーは、多様なターゲット・アプリケーションの要求に適合します。

実装の変数は、一般に 3 つのトレードオフ・パターン ( 機能の増強または削減、機能の追加または除外、機能のハードウェア実装またはソフトウェア・エミュレーション ) のいずれかに当てはまります。

• 機能の増強または削減—例えば、性能を微調整するために、命令キャッシュメモリー容量を増減できます。キャッシュの容量が増えると大規模なプログラムの実行速度が向上し、キャッシュの容量が減るとオンチップ・メモリー・リソースを節約できます。
• 機能の追加または除外—例えば、コストを削減するために、JTAG デバッグモジュールの省略が選択できます。これにより、オンチップ・ロジックとメモリーリソースを節約できますが、ソフトウェア・デバッガーを使用してアプリケーションをデバッグする機能もなくなります。
• ハードウェア実装またはソフトウェア・エミュレーション—例えば、複雑な演算を殆ど実行しない制御アプリケーションでは、除算命令をソフトウェアでエミュレートするように選択できます。除算用のハードウェアをなくすとオンチップ・リソースを節約できますが、除算演算の実行時間が増大します。

Nios II コアがサポートする機能について詳しくは、「Nios II プロセッサー・リファレンス・ハンドブック」の「Nios II コア実装の詳細」の章を参照してください。

ユーザー選択可能な Nios II プロセッサーのパラメーターについて詳しくは、「Nios II プロセッサー・リファレンス・ハンドブック」の「Nios II プロセッサーのインスタンス化」の章を参照してください。

Nios II プロセッサーには、オプションで 1 つ以上のシャドー・レジスター・セットがあります。シャドー・レジスター・セットは、Nios II 汎用レジスターの完全なセットです。シャドー・レジスター・セットが実装される場合、statusレジスターのCRSフィールドはどのレジスターセットが現在使用中であるかを示します。汎用レジスターへの命令アクセスは、アクティブなレジスターセットを使用します。

シャドー・レジスター・セットの一般的な使用方法は、コンテキスト切り替えを高速化することです。シャドー・レジスター・セットが実装されている場合、Nios II プロセッサーには、レジスターセット間でデータを移動するための 2 つの特殊なrdprs命令とwrprs命令があります。シャドー・レジスター・セットは、通常、オペレーティング・システム・カーネルによって操作され、アプリケーション・コードに対して透過的です。Nios II プロセッサーは、最大 63 個のシャドー・レジスター・セットを有することができます。

Nios II アーキテクチャーは後から浮動小数点レジスターを追加できます。

シャドー・レジスター・セットの実装および使用法について詳しくは、「Nios II プロセッサー・リファレンス・ハンドブック」の「プログラミング・モデル」の章の「レジスター」と「例外処理」を参照してください。

アセンブリー言語の命令の詳細については、「Nios II プロセッサー・リファレンス・ハンドブック」の「命令セット・リファレンス」の章を参照してください。

プロセッサーは、未実装命令を発行すると必ず例外を生成し、例外ハンドラーがその演算をソフトウェアでエミュレートするルーチンを呼び出します。プログラマーは未実装命令によるプロセッサーへの影響を意識する必要はありません。

潜在的な未実装命令のリストは、「Nios II プロセッサー・リファレンス・ハンドブック」の「プログラミング・モデル」の章を参照してください。

• 浮動小数点ハードウェア 2—このコンポーネントは IEEE 標準規格 754-2008 で規定される浮動小数点命令をサポートしますが、単純化された非標準丸めモードを使用しています。浮動小数点カスタム命令の基本セットには、単精度浮動小数点加算、減算、乗算、除算、平方根、整数から浮動小数点への変換、浮動小数点から整数への変換、最小、最大、否定、絶対および比較が含まれます。
• 浮動小数点ハードウェア—このコンポーネントは IEEE 標準規格 754-1985 で規定される浮動小数点命令をサポートします。浮動小数点カスタム命令の基本セットには、単精度浮動小数点加算、減算および乗算が含まれます。浮動小数点の除算は基本命令セットの拡張として使用できます。

これらの浮動小数点の命令は命令として実装されます。下のハードウェアの準拠の表に、IEEE 標準規格への準拠の詳細な説明を記載します。

• 加算
• 減算
• 乗算
• 除算
• 平方根
• 比較
• 整数変換
• 最小
• 最大
• 否定
• 絶対

その他の浮動小数点演算 ( 倍精度演算を含む ) は、ソフトウェア・エミュレーションで実装されています。コンポーネントには、次のデバイスリソースを必要とします。

• 最大 2,500 個の 4 入力 LE
• 9 x 9 ビット 乗算器
• 3x M9K メモリー

次の表は、a と b が単精度浮動小数点値とみなされています。

サイクル列は、命令を実行するのに必要なサイクル数を指定します。組み合わせカスタム命令は 1 サイクルかかります。マルチサイクルのカスタム命令には少なくとも 2 サイクルが必要です。Nios II プロセッサーはカスタム命令からの結果を登録し、ソースオペランド・バイパス・マルチプレクサーの g 線遅延のための別のサイクルを可能にするため、N サイクル・マルチサイクル・カスタム命令はカスタム命令内にN - 2 レジスターステージを待機します。サイクル数には、命令が 2 サイクル以内に結果を使用する場合、マルチサイクル・カスタム命令に続く命令が Nios II/f によってストールされる余分なサイクル ( 最大 2 つ ) は含まれません。これらの余分なサイクルはマルチサイクル命令が遅延命令であるために発生します。

Qsys では、Floating Point Hardware 2 コンポーネントはComponent LibraryタブのEmbedded Processors にあります。

Nios II ソフトウェア・ビルド・ツール (SBT) には、Floating Point Custom Instruction 2 コンポーネントのソフトウェア・サポートが含まれています。Floating Point Custom Instruction 2 コンポーネントがハードウェアに存在する場合、Nios II コンパイラーは浮動小数点演算のカスタム命令と newlib 算術ライブラリーを使用するようにコードをコンパイルします。

Qsys では、Floating Point HardwareコンポーネントはComponent LibraryタブのEmbedded Processors にあります。

Nios II 浮動小数点カスタム命令は Altera^®浮動小数点メガファンクション (ALTFP_MULT, ALTFP_ADD_SUB, and ALTFP_DIV) に基づいています。

Nios II ソフトウェア開発ツールは、プロセッサー・コアに存在する浮動小数点命令の利点から C コードを認識します。ターゲットハードウェアに浮動小数点カスタム命令が存在する場合、Nios II コンパイラーは浮動小数点演算のカスタム命令と newlib 算術ライブラリーを使用するようにコードをコンパイルします。

Nios II プロセッサーへのリセット信号の追加に関する詳しい情報は、「Nios II プロセッサー・リファレンス・ハンドブック」の「Nios II プロセッサーのインスタンス化」の章の「Advanced Features タブ」を参照してください。

Nios II プロセッサーへのデバッグ信号のブレークベクターおよび追加に関する詳しい情報は、「Nios II プロセッサー・リファレンス・ハンドブック」の「Nios II プロセッサーのインスタンス化」の章にある「JTAG Debug Module タブ」を参照してください。

例外アドレスは、Qsys の Nios II Processor パラメーター・エディターで指定します。

すべての例外は正確です。正確とは、プロセッサーがフォールトする命令に先行するすべての命令の実行を完了し、フォールトする命令に続く命令の実行を開始していないことを意味します。正確な例外により、例外ハンドラーが例外をクリアーすると、プロセッサーはプログラムの実行を再開できます。

Nios II プロセッサーは EIC インターフェイスを介して EIC に接続します。EIC が存在する場合、内部割り込みコントローラーは実装されません。つまり、Qsys は割り込みを EIC に接続します。

EIC はアクティブ割り込みの中から選択し、割り込みハンドラーアドレスとレジスターセット選択情報とともに Nios II プロセッサーに 1 つの割り込みを提供します。割り込み選択のアルゴリズムは EIC の実装に特有であり、一般的には割り込みの優先順位に基づいています。Nios II プロセッサーは、EIC の特定の割り込み優先順位付けスキームに依存しません。　

外部割り込みごとに、EIC は割り込みレベルを示します。Nios II プロセッサーは割り込みレベルを使用して、いつ割り込みを処理するかを決定します。

どの外部割り込みは NMI として設定できます。NMI はstatus.PIEビットでマスクされず、割り込みレベルもありません。

EIC はソフトウェアで設定可能です。

EIC の一般例について詳しくは、「Embedded Peripherals IP User Guide」の「Vectored Interrupt Controller」の章を参照してください。

EIC 使用法について詳しくは、「Nios II プロセッサー・リファレンス・ハンドブック」の「プログラミング・モデル」の章の「例外処理」を参照してください。

このソフトウェアでは、各 IRQ 入力用の割り込みイネーブルビットを備えたienableコントロール・レジスターを介して、割り込みソースを個別にイネーブルおよびディスエーブルできます。また、statusコントロール・レジスターの PIE ビットを介して、割り込みをグローバルにイネーブルおよびディスエーブルできます。ハードウェア割り込みは、以下の3 つの条件がすべて満たされた場合にのみ生成されます。

• statusレジスターの PIE ビットが 1 である
• 割り込み要求入力irq<n> がアサートされている
• ienableレジスターの対応するビット n が 1 である

割り込みベクトルカスタム命令は、アルテラのベクトル割り込みコントローラー・コンポーネントで EIC インターフェイスを使用する場合よりも非効率的なため、Qsys では非推奨です。アルテラは EIC インターフェイスの使用を推奨しています。

Nios II のメモリーおよび I/O 構成の柔軟性は、Nios II プロセッサー・システムと従来型のマイクロコントローラーの違いを最も顕著に示すものです。Nios II プロセッサー・システムはコンフィグレーション可能なため、メモリーとペリフェラルはシステムごとに異なります。その結果、メモリーと I/O 構成もシステムごとに異なります。

Nios II コアは、以下の 1 つまたは複数を使用してメモリーおよび I/O アクセスを提供します。

• 命令マスター・ポート—システム・インタコネクト・ファブリックを介してインストラクション・メモリーに接続される Avalon^®メモリーマップド (Avalon-MM) マスターポート
• 命令キャッシュ—Nios II コアに内蔵されている高速キャッシュメモリー
• データ・マスター・ポート—システム・インタコネクト・ファブリックを介してデータメモリーとペリフェラルに接続される Avalon-MM マスターポート
• データキャッシュ—Nios II コアに内蔵されている高速キャッシュメモリー
• 密結合命令またはデータメモリー・ポート—Nios II コアの外部にある高速オンチップ・メモリーへのインターフェイス

Nios II アーキテクチャーでは、プログラマーのハードウェアの詳細を処理するため、プログラマーはハードウェア実装を意識することなく、Nios II アプリケーションを開発できます。

プログラミングへの影響について詳しくは、「Nios II プロセッサー・リファレンス・ハンドブック」の「プログラミング・モデル」の章を参照してください。

Nios II アーキテクチャーは、独立した命令バスとデータバスをサポートしているため、Harvard アーキテクチャーに分類されます。命令バスとデータバスはともに、Avalon-MM インターフェイス仕様に準拠する Avalon-MM マスターポートとして実装されます。データ・マスター・ポートは、メモリー・コンポーネントとペリフェラル・コンポーネントの両方に接続されますが、命令マスターポートはメモリー・コンポーネントにのみ接続されます。

Nios II アーキテクチャーは、メモリーとペリフェラルの使用に関して何も規定していないため、メモリーとペリフェラルの数量、タイプ、および接続はシステムに依存します。通常、Nios II プロセッサー・システムは、高速オンチップ・メモリーと低速オフチップ・メモリーを組み合わせて搭載しています。ペリフェラルは一般にオンチップにも搭載されていますが、オフチップ・ペリフェラルへのインターフェイスも存在します。

命令マスターポートはパイプライン化された Avalon-MM マスターポートです。パイプライン化された Avalon-MM 転送のサポートにより、パイプライン・レイテンシーを伴う同期メモリーの影響が最小になり、システムの全体的なf_MAXが上昇します。命令マスターポートは、前の要求からデータが返される前に連続リード要求を発行することができます。Nios II プロセッサーは、シーケンシャル命令をプリフェッチして分岐予測を実行し、命令パイプラインを可能な限りアクティブに保持します。.

命令マスターポートは、常に 32 ビットのデータを取得します。命令マスターポートは、システム・インターコネクト・ファブリックに含まれるダイナミック・バス・サイジング・ロジックに依存します。ダイナミック・バス・サイジングによって、ターゲットメモリーの幅に関係なく、すべての命令フェッチがフル命令ワードを返します。結果的に、プログラムは Nios II プロセッサー・システムにおけるメモリー幅を意識する必要はありません。

Nios II アーキテクチャーは、低速メモリーにアクセスするときの平均命令フェッチ性能を改善するために、オンチップ・キャッシュ・メモリーをサポートしています。詳細は、この章の「キャッシュメモリー」の項を参照してください。

Nios II アーキテクチャーは、オンチップ・メモリーへの確実な低レイテンシー・アクセスを提供する密結合メモリーをサポートします。詳細は、この章の「密結合メモリー」を参照してください。

データ・マスター・ポートおよび命令マスターポートによって、一方のポートが他方のポートを枯渇させるグリッドロック状態が発生することはありません。最高の性能を実現するには、命令マスターポートとデータ・マスター・ポートの両方が共有するメモリー上で、データ・マスター・ポートに高いアビトレーション・プライオリティーを割り当てる必要があります。

命令キャッシュとデータキャッシュは、実行時には常にイネーブルされますが、ペリフェラル・アクセス時にキャッシュされたデータが返されないように、ソフトウェアによってデータキャッシュをバイパスする手段が用意されています。キャッシュ管理とキャッシュ・コヒーレンシーは、ソフトウェアで処理されます。Nios II 命令セットにはキャッシュ管理用の命令があります。

Nios II プロセッサー・コアには、キャッシュメモリーの一方または両方を搭載するか、あるいはどちらも搭載しないことが可能です。さらに、データキャッシュと命令キャッシュの両方またはいずれか一方を備えたコアの場合、キャッシュメモリーのサイズはユーザーが設定 / 構成可能です。キャッシュメモリーを搭載してもプログラムの機能には影響はありませんが、プロセッサーが命令をフェッチする速度とデータを読み出し / 書き込みする速度は影響を受けます。

• 通常のメモリーがオフチップで配置され、オンチップ・メモリーと比較してアクセス時間が長い
• 性能が重視される最大命令ループが命令キャッシュよりも小さい
• 性能が重視されるデータの最大ブロックがデータキャッシュよりも小さい

対象となるアプリケーションにおける効果は設計者が判断できますが、最適なキャッシュ構成はアプリケーションによって異なります。例えば、Nios II プロセッサー・システムに、高速オンチップ・メモリーしかない ( つまり、低速オフチップ・メモリーにはアクセスしない ) 場合、命令キャッシュまたはデータキャッシュによる性能向上は期待できません。別の例では、プログラムの重要なループが 2 KB でも、命令キャッシュのサイズが 1 KB であれば、命令キャッシュによって実行速度が向上することはありません。実際には、性能は低下すると考えられます。

性能上の理由から、特定のデータまたはコードセクションがキャッシュメモリーに存在することをアプリケーションが要求する場合、密結合メモリー機能によってより適切なソリューションが提供されることがあります。詳しくは「密結合メモリー」の項を参照してください。

ldioやstioなどのロードおよびストアー I/O 命令は、データキャッシュをバイパスして、Avalon-MM データを指定アドレスに強制的に転送します。

データマスター・ポートのビット 31 のキャッシュバイパス手法では、プロセッサーがキャッシュとの間でデータ転送を行うかキャッシュをバイパスするかを示すタグとしてアドレスのビット 31 を使用します。これは特定のアドレスをキャッシュし、その他をバイパスする必要があるソフトウェアにとって便利です。ソフトウェアは、アドレス指定されたデータをキャッシュするかどうかに関する追加情報を指定しなくても、ファンクション間でアドレスをパラメーターとして渡すことができます。

コアが実装するキャッシュバイパス手法を決定するには、「Nios II プロセッサー・リファレンス・ハンドブック」の「Nios II コアの実装の詳細」の章を参照してください。

Gen2 コアは、オプションでキャッシャビリティーを示す新しいペリフェラル領域のメカニズムをサポートします。ペリフェラル領域のキャッシャビリティー・メカニズムにより、Qsys 生成時にユーザーがキャッシュ不能として扱われるアドレス空間の領域を指定することができます。ペリフェラル領域は、最小 4096 バイトから最大 2 GB までの 2 のべき乗バイトの任意の整数であり、ペリフェラル領域のサイズに揃えられたベースアドレスに配置する必要があります。ペリフェラル領域は MMU が存在しない限り使用可能です。

• キャッシュメモリーに類似した性能
• ソフトウェアにより、密結合メモリー内での性能重視のコードまたはデータの存在の保証が可能
• ローディング、無効化、またはメモリーのフラッシュなどのリアルタイムでのキャッシュによるオーバーヘッドがない

物理的には、密結合メモリーポートは Nios II プロセッサー・コア上の独立したマスターポートで、命令またはデータ・マスター・ポートに類似しています。Nios II コアは、ゼロ、1 つ、または複数の密結合メモリーを持つことができます。Nios II アーキテクチャーは、命令アクセスとデータアクセスの両方に対して密結合メモリーをサポートします。各密結合メモリーポートは、保証された固定低レイテンシーにより 1 つのメモリーにのみ直接接続されます。メモリーは Nios II コアの外部にあり、通常はチップ上に存在します。

ソフトウェアは通常のロードおよびストアー命令を使用して、密結合メモリーにアクセスします。ソフトウェアの観点からは、密結合メモリーへのアクセスと他のメモリーへのアクセスの違いはありません。

システムは密結合メモリーを使用して、コードまたはデータの特定セクションへのアクセスに対して最大性能を達成できます。例えば、割り込みを多用するアプリケーションは、例外ハンドラーコードを密結合メモリーに配置して、割り込みレイテンシーを最小化することがきます。同様に、計算量の多いデジタル信号処理 (DSP) アプリケーションは、データバッファーを密結合メモリー内に配置して、可能な限り高速なデータアクセスを達成できます。

アプリケーションのメモリー要件がチップ内に完全に収まるほど小さい場合は、密結合メモリーをコードおよびデータ専用に使用できます。より大規模なアプリケーションでは、密結合メモリー内に何を配置するかを選択して、コストと性能のトレードオフを最大化する必要があります。

プロセッサーの一部である言及すべきアドレスは次の 3 つのアドレスです。

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

プログラマーはマクロとドライバーを使用して、メモリーおよびペリフェラルにアクセスします。したがって、アプリケーション開発者がアドレスマップの柔軟性を考慮する必要はありません。

• 仮想アドレス から物理アドレスへのマッピング
• メモリー保護
• 32 ビットの仮想および物理アドレス。4 GB の物理メモリーへの 4 GB の仮想アドレス空間のマッピングが可能
• 4 KB のページおよびフレームサイズ
• 直接アクセスに使用可能なわずか 512 MB の物理アドレス空間
• ハードウェア変換索引バッファー (TLB) によるアドレス変換の高速化
  • 命令アクセスおよびデータアクセス用の独立した TLB
  • 読み出し、書き込み、および実行の許可をページ単位で制御
  • デフォルトのキャッシュ動作をページ単位で制御
  • ソフトウェア・ページ・テーブル用の n 方向セット連想キャッシュとして動作する TLB
  • Nios II Processor パラメーター・エディターで設定可能な TLB サイズと関連性
• システム・ソフトウェアで決定されるページテーブル ( または同等なデータ構造 ) のフォーマット
• システム・ソフトウェアで決定される TLB エントリーの置換方式
• システム・ソフトウェアで決定される TLB エントリーの書き込みポリシー

MMU 実装ついて詳しくは、「Nios II プロセッサー・リファレンス・ハンドブック」の「プログラミング・モデル」の章を参照してください。

Nios II ハードウェア・システムで Nios II プロセッサーをインスタンス化する際は、オプションで MMU を含めることができます。MMU は存在するときは常にイネーブルされ、データキャッシュおよび命令キャッシュは VIPT ( 仮想インデックス物理タグ ) 方式のキャッシュです。いくつかのパラメーターを使用でき、システムニーズに合わせて MMU を最適化することができます。

ユーザー選択可能な Nios II MMU のパラメーターについて詳しくは、「Nios II プロセッサー・リファレンス・ハンドブック」の「Nios II プロセッサーのインスタンス化」の章を参照してください。

• メモリー保護
• 最大 32 の命令領域と 32 のデータ領域
• 可変命令およびデータ領域サイズ
• サイズまたは上位アドレス制限により定義される領域メモリー量
• データ領域に対する読み出しおよび書き込みアクセス許可
• 命令領域に対するアクセス許可の実行
• オーバラップ領域

MPU 実装ついて詳しくは、「Nios II プロセッサー・リファレンス・ハンドブック」の「プログラミング・モデル」の章を参照してください。

Nios II ハードウェア・システムで、Nios II プロセッサーをインスタンス化する場合は、オプションで MPU を含めることができます。MPU が存在する際は常にイネーブルになります。いくつかのパラメーターが使用可能で、システムニーズに合わせて MPU を最適化することができます。

ユーザー選択可能な Nios II MPU のパラメーターについて詳しくは、「Nios II プロセッサー・リファレンス・ハンドブック」の「Nios II プロセッサーのインスタンス化」の章を参照してください。

• メモリーへのプログラムのダウンロード
• 実行の開始および停止
• ブレークポイントおよびウォッチポイントの設定
• レジスターおよびメモリーの解析
• リアルタイム実行トレースデータの収集

デバッグモジュールは、アルテラの FPGA の JTAG 回路に接続されます。これにより、外部デバッグプローブから FPGA 上の標準 JTAG インターフェイスを介してプロセッサーにアクセスできます。プロセッサー側では、デバッグモジュールがプロセッサー・コア内部の信号に接続されます。デバッグモジュールには、プロセッサーに対してマスク不能な制御を行い、テスト中のアプリケーションにリンクされたソフトウェア・スタブは不要です。スーパーバイザー・モードでプロセッサーが認識可能なすべてのシステムリソースは、デバッグモジュールで使用できます。トレースデータ収集の場合、デバッグモジュールはオンチップまたはデバッグプローブ内のメモリーにトレースデータを格納します。

デバッグモジュールは、ハードウェア・ブレーク信号をアサートするか、実行するプログラムメモリー内にブレーク命令を書き込むことによって、プロセッサーの制御を取得します。どちらの場合も、プロセッサーはブレークアドレスに配置されるルーチンに実行を移します。ブレークアドレスは、Qsys の Nios II Processor パラメーター・エディターで指定します。

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

次の項では、Nios II JTAG デバッグモジュール・ハードウェアの機能について説明します。すべてのハードウェア機能の使用は、Eclipse用 Nios II ソフトウェア・ビルド・ツールのように、ターゲット・プロセッサーへの接続を管理し、デバッグプロセスを制御するホスト・ソフトウェアに依存します。

ハードウェア・ブレークポイントは、JTAG デバッグモジュールのハードウェア・トリガー機能を使用して実現されます。

ハードウェア・トリガー条件は、命令バスまたはデータバスのいずれかに基づきます。同一バス上のトリガー条件は論理積をとることができるため、例えば JTAG デバッグモジュールをライトサイクルでのみ特定のアドレスにトリガーさせることができます。

プロセッサーの実行中にトリガー条件が満たされると、JTAG デバッグモジュールは、実行の停止やトレース・キャプチャーの開始などの動作をトリガーします。下の表は、Nios II JTAG デバッグモジュールでサポートされるトリガー動作を示しています。

JTAG デバッグモジュールには、アーム付きトリガーと呼ばれる 2 つのレベルの機能があります。アーム付きトリガーにより、JTAG デバッグモジュールは、イベント A の発生時にのみイベント B でトリガーできます。この例では、イベント A によって、イベント B のトリガーをイネーブルするトリガー動作が発生します。

JTAG デバッグモジュールは、データバス上のデータまたはアドレス値の範囲でトリガーすることができます。このメカニズムは、2 つのハードウェア・トリガーを併用し、指定範囲内において、ある値の範囲でアクティブになるトリガー情報を作成します。

• 実行トレース ( 命令バスサイクル ) をキャプチャーする
• データトレース ( データバス・サイクル ) をキャプチャーする
• 各データバス・サイクルで、アドレス、データ、またはその両方をキャプチャーする
• トリガーに基づいて、リアルタイムでのトレース・キャプチャーを開始および停止する
• ホスト制御のもとで手動でトレースを開始および停止する。
• トレースバッファーが満量になったときに、オプションでトレース・キャプチャーを停止して、プロセッサーを実行させたままにする
• JTAG デバッグモジュールのオンチップメモリー・バッファーにトレースデータを格納する ( このメモリーは、JTAG接続でのみアクセス可能)
• トレースデータをオフチップ・デバッグ・プローブの大規模バッファーに格納する

一部のトレース機能には、サードパーティーのデバッグ・プロバイダーが提供する追加ライセンスまたはデバッグツールが必要です。例えば、オンチップ・トレース・バッファーは、Nios II プロセッサーの標準機能ですが、オフチップ・トレース・バッファーを使用するには、Imagination Technologies™、LCC または Lauterbach GmbH が提供する別のデバッグ・ソフトウェアとハードウェアが必要です。

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

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

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

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

• スーパーバイザー・モード
• ユーザーモード

次の項では、モード、システム・ソフトウェアとアプリケーション・コードとの関係、Nios II MMU および Nios II MPU との関係を定義します。

オペレーティング・システムおよびその他のシステム・ソフトウェアはスーパーバイザー・モードで実行されます。MMU を搭載したシステムでは、アプリケーション・コードはユーザーモードで実行され、スーパーバイザー・モードで動作するオペレーティング・システムは、メモリーとペリフェラルへのアプリケーションのアクセスを制御します。MPU を搭載したシステムでは、システム・ソフトウェアがアプリケーション・コードの実行モードを制御します。MMU または MPU のない Nios II システムでは、すべてのアプリケーションおよびシステムコードがスーパーバイザー・モードで実行されます。

プロセッサーへの直接アクセスとプロセッサーの制御を必要とするコードは、スーパーバイザー・モードで実行されます。例えば、プロセッサーの例外 ( プロセッサーのリセットまたはブレークを含む ) が発生するたびに、プロセッサーはスーパーバイザー・モードに入ります。ソフトウェア・デバッグ・ツールは、スーパーバイザー・モードを使用してブレークポイントやウォッチポイントなどの機能を実装します。

オペレーティング・システムは、ユーザーモード・アプリケーションがアクセス可能なメモリーアドレスを決定します。ユーザーアクセスを有効にせずにユーザーモード・アプリケーションがメモリー位置へアクセスすることはできず、例外が発生します。ユーザーモードで実行するコードは、システムコールを使用して、I/O 動作の実行、メモリーの管理、およびスーパーバイザー・メモリーの他のシステム機能へのアクセスをオペレーティング・システムに要求します。

Nios II MMU は、32 ビットの仮想アドレス空間をユーザー・パーティションとスーパーバイザー・パーティションに静的に分割します。MMU メモリー・パーティションの詳細については、「アドレス空間およびメモリー・パーティション」の項を参照してください。MMU はページ単位でオペレーティング・システムのアクセス許可を提供します。MMU ページの詳細については、「仮想アドレッシング」を参照してください。

Nios II MPU のスーパーバイザーとユーザメモリーの分割は、オペレーティング・システムまたはランタイム環境で決定します。MPU は、領域でユーザーアクセス許可を提供します。MPU 領域の詳細については、「メモリー領域」を参照してください。

多くの Nios II システムでは、最小限のシステム・ソフトウェアまたは小フットプリント・オペレーティング・システム ( アルテラ^® ハードウェア抽象化ライブラリー (HAL) やサードパーティーのリアルタイム・オペレーティング・システムなど) で十分です。このようなソフトウェアは、MMU ベースの Nios II プロセッサーを搭載したハードウェア・システムでは正しく機能しない可能性があります。Nios II システムのオペレーティング・システムが MMUを必要としない限り、MMU を含めないでください。

システムにメモリー保護が必要で、仮想メモリー管理が必要ない場合は、「メモリー保護ユニット」の項を参照してください。

• 仮想アドレッシング—仮想アドレス空間の物理メモリーへのマッピング
• メモリー保護—特定の条件下での特定のメモリーのみへのアクセス許可

MMU は、ハードウェア変換索引バッファー (TLB) によるアドレス変換の高速化を含んでいます。オペレーティング・システムは、メモリー内にページテーブル ( または同等のデータ構造 ) を作成し、保持する役割を担っています。ハードウェア TLB は、ページテーブルでソフトウェア管理キャッシュとして機能します。MMU は、ハードウェア・テーブル・ウォークといった、ページテーブル上の動作を実行しません。したがって、オペレーティング・システムは、任意の適切な方法でページテーブルを自由に実装できます。

20 ビットの仮想ページナンバー (VPN) と 12 ビットのページオフセットがあります。

入力として、TLB は VPN とプロセス識別子を取ります ( 一意性を保証するため )。出力として、TLB は対応する物理フレームナンバー (PFN) を提供します。

異なるプロセスは同じ仮想アドレス空間を使用できます。プロセス識別子は、仮想アドレスと連結され、別々のプロセスで同一の仮想アドレスを区別します。Nios II MMU は VPN を PFN に変換して PFN をページオフセットと連結させることで物理アドレスを決定します。ページオフセットのビットは変換されません。

メモリー保護

Nios II MMU は、ページごとに読み出し、書き込み、および実行許可を維持します。TLB は、VPN の変換時に許可情報を提供します。オペレーティング・システムは各プロセスが各特定のページのデータの読み出し、書き込み、または実行命令が可能かどうかを制御できます。MMU は、デフォルトで各データページへのアクセスをキャッシュ可能またはキャッシュ不能にするかどうかも制御します。

命令が TLB マッピングがないページ、または適切な許可がないページにアクセスしようとするたびに、MMU は例外を生成します。Nios II プロセッサーの厳密な例外により、システム・ソフトウェアは TLB を更新し、必要に応じて命令を再実行できます。

Nios II MMU は、ページごとに読み出し、書き込み、および実行許可を維持します。TLB は、VPN の変換時に許可情報を提供します。オペレーティング・システムは各プロセスが各特定のページのデータの読み出し、書き込み、または実行命令が可能かどうかを制御できます。MMU は、デフォルトで各データページへのアクセスをキャッシュ可能またはキャッシュ不能にするかどうかも制御します。

命令が TLB マッピングがないページ、または適切な許可がないページにアクセスしようとするたびに、MMU は例外を生成します。Nios II プロセッサーの厳密な例外により、システム・ソフトウェアは TLB を更新し、必要に応じて命令を再実行できます。

各パーティションには、TLB への特定のサイズ、目的、および関係があります。

• ペリフェラルへのアクセスを提供する 512 MB の I/O パーティション
• オペレーティング・システム・カーネルでの領域を提供する 512 MB のカーネル・パーティション
• TLB ミスハンドラーとカーネルプロセスにより使用される 1 GB カーネルの MMU パーティション
• アプリケーション・プロセスにより使用される 2 GB のユーザー・パーティション

I/O とカーネル・パーティションは TLB をバイパスします。カーネル MMU とユーザー・パーティションは TLB を使用します。すべてのソフトウェアがカーネル・パーティションで実行されると、MMU は実質的に無効になります。

高物理メモリーは、TLB を介してのみアクセスできます。低メモリー (29 ビット以下 ) の物理アドレスは、TLB を介して、または TLB をバイパスすることでアクセスできます。TLB をバイパスする場合、32 ビットの仮想アドレスの上位 3 ビットをクリアーすることで、29 ビットの物理アドレスが計算されます。

非 I/O ロード命令およびストアー命令は、デフォルトのデータ・キャッシャビリティー・プロパティーを使用します。I/O ロード命令とストアー命令は常にキャッシュ不能なので、デフォルトのデータ・キャッシャビリティー・プロパティーは無視されます。

TLB は、n ウェイ・セット・アソシアティブ方式のキャッシュとして編成されています。ソフトウェアは、新しいエントリーをロードするときのウェイ ( セット ) を指定します。

オペレーティング・システム・ソフトウェアは、複数の TLB エントリーが同じ仮想アドレスをマッピングしないことを保証する役割があります。複数のエントリーが同じ仮想アドレスをマップする場合、ハードウェアの動作は未定義です。

各 TLB エントリーは、タグとデータ部分で構成されます。これは、命令キャッシュとデータキャッシュのタグとデータ部分に類似しています。

命令キャッシュおよびデータキャッシュについて詳しくは、「Nios II プロセッサー・リファレンス・ハンドブック」の「Nios II コア実装の詳細」の章を参照してください。

TLB エントリーのタグ部分は、仮想アドレスを TLB エントリーに一致させる際に使用される情報を含みます。

TLB データ部分は、一致する仮想アドレスから物理アドレスへの変換方法を決定します。

TLB 例外については、「命令関連の例外」を参照してください。

MPU は、すべての Nios II の命令フェッチとデータ・メモリー・アクセスを監視し、誤ったソフトウェアの実行を防止します。MPU は、システム・ソフトウェアがメモリー領域とそれに関連するアクセス許可を定義するために使用するハードウェア機能です。ソフトウェアが許可に反してメモリー領域にアクセスを試みると、MPUは例外をトリガーし、これにより、例外に応じて例外を処理して処理できます。 正確な例外は、メモリーへの不正アクセスを効果的に防止します。

MPU は Nios II プロセッサーを拡張してユーザーモードとスーパーバイザー・モードをサポートします。通常、システム・ソフトウェアはスーパーバイザー・モードで実行され、エンドユーザー・アプリケーションはユーザーモードで実行されますが、必要に応じてすべてのソフトウェアをスーパーバイザー・モードで実行できます。システム・ソフトウェアは、スーパーバイザー・モードに属する MPU 領域とユーザモードに属する MPU 領域を定義します。

• ベースアドレス
• 領域タイプ
• 領域インデクス
• 領域サイズまたは上位アドレス制限
• アクセス許可
• デフォルト・キャッシャビリティー ( データ領域のみ )

領域がサイズによって定義される場合、次の MPU 領域のアドレス範囲の一致を容易にするために、サイズはバイナリーマスクとしてエンコードされます。

(address & region_mask) == region_base_address

領域が制限によって定義されている場合、次の MPU 領域のアドレス範囲の一致を容易にするために、制限は符号なし整数としてエンコードされます。

(address >= region_base) && (address < region_limit)

領域の制限は、less-than がより効率的な実装を提供するため、less-than-or-equal-to 比較の代わりに less-than を使用します。制限値はアドレスよりも 1 ビット大きいため、完全なアドレス範囲が範囲内に含まれる可能性があります。制限で領域域を定義すると、サイズでの定義よりもアドレス範囲の一致ロジックが遅くなり大きくなりますが、領域サイズはより緻密な粒度になります。

特定のアクセスが複数の領域に一致するように領域が重複する場合、最も高いプライオリティー ( 最も低いインデックス ) を持つ領域がアクセス許可とデフォルト・キャッシャビリティーを決定します。

Nios II アーキテクチャーは、32 個の 32 ビット汎用レジスターr0~r31を提供します。一部のレジスターにはアセンブラーで認識される名前があります。例えば、zeroレジスター (r0) は常にゼロの値を返し、zeroへの書き込みは無効です。raレジスター (r31) は、プロシージャー・コールで使用される戻りアドレスを保持し、call、callr、およびret命令によって暗黙的にアクセスされます。C および C++ コンパイラーは、共通のプロシージャー・コール規約を使用して、レジスターr1~r23およびr26~r28に特定の意味を割り当てます。

詳しくは、「Nios II プロセッサー・リファレンス・ハンドブック」の「アプリケーション・バイナリー・インターフェイス」の章を参照してください。

コントロール・レジスターはステータスをレポートし、プロセッサーの動作を変更します。コントロール・レジスターは、汎用レジスターとは異なる方法でアクセスされます。特殊な命令のrdctlとwrctlは、コントロール・レジスターを読み出しと書き込みをする唯一の手段を提供し、スーパーバイザー・モードでのみ使用できます。

Nios II アーキテクチャーは最大 32 個のコートロール・レジスターをサポートしています。すべての予約されていないコントロール・レジスターは、アセンブラーで認識される名前を有します。

次の項では予約されていないコントローラー・レジスターを説明します。

コントロール・レジスターはステータスをレポートし、プロセッサーの動作を変更します。コントロール・レジスターは、汎用レジスターとは異なる方法でアクセスされます。特殊な命令のrdctlとwrctlは、コントロール・レジスターを読み出しと書き込みを行う唯一の手段を提供し、スーパーバイザー・モードでのみ使用できます。

Nios II アーキテクチャーは最大 32 個のコートロール・レジスターをサポートしています。すべての予約されていないコントロール・レジスターは、アセンブラーで認識される名前を有します。

次の項では、予約されていないコントロール・レジスターについて説明します。

estatusレジスターのすべてのフィールドは読み出しと書き込みへのアクセスがあります。すべてのフィールドは 0 にリセットされます。

Nios II プロセッサーが割り込みを取ると、status.ehがゼロの場合 ( つまり MMU が非例外モード時 ) は、プロセッサーはstatusレジスターのコンテンツをestatusに複写します。

sstatusレジスターについて詳しくは、「sstatus レジスター」の項を参照してください。

例外ハンドラーはプロセッサーの例外前のステータスを判断するためにestatusを調査できます。例外から値を返す際、eret命令はstatusの例外前の値を復元します。この命令は、status.CRSの値に応じて、estatusまたはsstatusのいずれかをstatusに返すことによって例外前の値に復元します。

詳しくは、「例外処理」の項を参照してください。

bstatusレジスターのすべてのフィールドは、読み出しと書き込みのアクセスがあります。すべてのフィールドは 0 にリセットされます。

ステータス・コントロール・レジスター・フィールドの説明の表に、bstatusレジスターに定義されているフィールドの詳細が記載されています。

ブレークが発生すると、statusレジスターの値がbstatusレジスターに複写されます。bstatusレジスターを使用すると、デバッガーはstatusレジスターをブレーク前の値に復元させます。bret命令は、プロセッサーにbstatusレジスターの値をstatusレジスターに返させます。詳しくは、「ブレークの処理」の項を参照してください。

ipendingレジスターは、プロセッサー内で駆動されるイネーブル割り込み信号の値を示します。ビット n が 1 の値とは、対応するirq入力がアサートされ、ienableレジスターで有効になっていることを意味します。ipendingレジスターに値を書き込んでも、影響はありません。

余分な例外情報の制御のオプションについて詳しくは、「Nios II プロセッサー・リファレンス・ハンドブック」の「Nios II プロセッサーのインスタンス化」の章を参照してください。

ソフトウェアは、プロセスが切り替えられるとPTBASEフィールドに書き込みます。ハードウェアはPTBASEフィールドに決して書き込みを実行しません。

ソフトウェアは、TLB エントリーを書き込むとVPNフィールドに書き込みます。ハードウェアは高速 TLB ミス例外、TLB 許可違反例外、TLB 読み出しオペレーションでのVPNフィールドに書き込みます。VPNは、例外がすでにアクティブである場合、つまりstatus.EHがすでに 1 である場合に行われる例外では書き込まれません。

tlbaccレジスターへのwrctl命令の発行は、tlbaccレジスターに指定された値が書き込まれます。tlbmisc.WE = 1 の場合、wrctl命令も TLB 書き込み動作を開始し、TLB 書き込み動作は TLB エントリーを書き込みます。書き込まれる TLB エントリーは、pteaddr.VPNのラインの部分とtlbmisc.WAYフィールドで指定されます。書き込まれる値は、tlbaccレジスターに書き込まれた値とpteaddr.VPNおよびtlbmisc.PIDの値によって指定されます。また、TLB 書き込み動作では、tlbmisc.WAYがインクリメントされ、ソフトウェアは TLB エントリーを迅速に変更できます。

tlbaccレジスターへのrdctl命令の発行は、tlbaccレジスターの値が返されます。tlbaccレジスターは、ソフトウェアが TLB 読み取り操作をトリガーする際 ( つまり、wrctlがtlbmisc.RDを 1 に設定する場合 ) にハードウェアによって書き込まれます。

tlbaccレジスター・フォーマットはオペレーティング・システムのページテーブルのエントリーで推奨されるフォーマットです。IGビットはwrctlからtlbaccへのハードウェアで無視され、tlbaccからのrdctlでゼロとして読み出されます。オペレーティング・システムは、IGビットを使用して、TLB 書き込み動作でこれらのビットをゼロにクリアーすることなく、オペレーティング・システム固有の情報を保持することができます。

DBL、BAD、およびPERMフィールドでは、exception.CAUSEを使用してこれらの例外を判断することもできます。

次の項では、tlbmiscフィールドについてより詳しく説明します。

• pteaddr.VPNのタグ部分
• tlbmisc.PID
• tlbaccレジスター

読み出す TLB エントリーは、次の値により指定されます。

• pteaddr.VPNのライン部分
• tlbmisc.WAY

システム・ソフトウェアが TLB エントリーを指定するフィールドを変更する際、pteaddr.VPN、tlbmisc.PID、またはtlbaccレジスターへの影響はありません。レジスターは、次の TLB 読み出し動作が開始されるまで以前の値を保持します。例えば、オペレーティング・システムがpteaddr.VPNを新しい値に設定すると、tlbaccのコンテンツは以前の TLB エントリーを続けて反映させます。tlbaccには、明示的な TLB 読み出し後まで新しい TLB エントリーが含まれません。

ハードウェアは、TLB 許可違反例外ではWE flagを 1 にセットし、status.EH = 0 の場合は TLB ミス例外に設定します。TLB 書き込み動作がtlbaccレジスターに書き込むと、書き込み動作はWE = 1 の際に TLB エントリーに書き込みます 。

tlbmisc.PIDには TLB タグからのPIDフィールドが含まれています。オペレーティング・システムは、プロセスの切り替え時および各 TLB 書き込み動作の前に、PIDフィールドを設定する必要があります。

MMU は、TLB 読み出し動作にtlbmisc.PIDを設定します。ソフトウェアが TLB 読み出しをトリガーする際、 tlbmisc.RDをwrctl命令で 1 に設定することにより、TLB から読み出されたPID値がwrctl命令によって書き込まれた値よりも優先されます。

PIDフィールドのサイズは、システム生成時に Qsys で設定され、8 ~ 14 ビットです。システム・ソフトウェアがPIDフィールドより小さいプロセス識別子を定義する場合、未使用の上位ビットはゼロとして書き込む必要があります。

DBLフラグは、最新の例外がダブル TLB ミス状態であるかどうかを示します。一般的な例外が発生すると、MMU はダブル TLB ミスが検出された場合にDBLを 1 に設定し、そうでない場合はDBLを 0 にクリアーします。

• スーパーバイザー専用命令アドレス
• スーパーバイザー専用データアドレス
• ミスアライメント・データアドレス
• ミスアライメント・デスティネーション・アドレス

これらの例外の詳細については、例外の概要のセクションの Nios II の例外 ( プライオリティー順 ) の表を参照してください。

次の例外はDフラグを 1 に設定します。

• 高速 TLB ミス ( データ )
• ダブル TLB ミス ( データ )
• TLB 許可違反 ( 読み出しまたは書き込み )
• ミスアライメント・データアドレス
• スーパーバイザー専用データアドレス

Nios II/f プロセッサーで例外が発生すると、badaddrレジスターには、例外が発生した際に特定の例外に関連するバイト命令またはデータアドレスが格納されます。Nios II の例外の表には、badaddrレジスターに書き込まれた値とともに書き込まれる例外がリストされています。

BADDRフィールドは、最大 32 ビットの命令アドレスまたはデータアドレスを許可します。MMU または MPU が存在する場合、MMU および MPU の命令およびデータアドレスは常に完全な 32 ビット値のため、BADDRフィールドは 32 ビットです。MMU が存在する場合、BADDRフィールドには仮想アドレスがあります。

MMU または MPU がなく、Nios II のアドレス空間が 32 ビット未満の場合、未使用の上位ビットが書き込まれ、ゼロとして読み出されます。MMU が存在しない場合、データアドレスのビット 31 ( データキャッシュのバイパスに使用される ) は、BADDRフィールドでは常にゼロです。

configレジスターは、例外処理中に (statusレジスターの情報とは対照に )、保存が不必要な Nios II のランタイム動作を設定します。

mpubaseレジスターはmpuaccレジスターとともに MPU 領域情報を設定および取得し、MPU を備えたシステムでのみ使用できます。

BASEフィールドは、MPU 領域のべースアドレスを指定します。25 ビットのBASEフィールドはベースアドレスのビット 6~30 に対応し、ベースアドレスは常に 64 バイトの倍数になります。生成時に Qsys に設定された最小領域サイズが 64 バイトより大きい場合、BASEフィールドの未使用の下位ビットはゼロとして書き込まれ、ゼロとして読み出されます。例えば、最小の領域サイズが 1024 バイトの場合、BASEフィールドの 4 つの最下位ビット (mpubaseレジスターのビット 6~9) はゼロである必要があります。同様に、Nios II のアドレス空間が 31 ビット未満の場合、未使用の上位ビットもゼロとして書き込まれ、ゼロとして読み出される必要があります。

INDEXおよびDフィールドは、MPU 領域の読み出しまたは書き込み動作が実行され際にアクセスする領域情報を指定します。Dフィールドは領域がデータ領域か命令領域かを指定します。INDEXフィールドは、アクセスする 32 のデータまたは命令領域のいずれかを指定します。32 個以下の命令または 32 個のデータ領域がある場合、未使用の上位ビットはゼロとして書き込まれ、ゼロとして読み出されます。

MPU 領域の読み出しおよび書き込み動作の詳細については、「MPU 領域の読み出しおよび書き込み動作」の項を参照してください。

mpuaccレジスターはmpubaseレジスターとともに MPU 領域情報を設定および取得し、MPU を搭載したシステムでのみ使用できます。mpuaccレジスターは、MPU 領域を定義するために設定されるか検索される属性で構成されています。mpuaccレジスターは、MPU 領域を定義する属性の一部のみを保持します。MPU 領域を定義する残りの部分は、mpubaseレジスターのBASEフィールドで保持されます。

Qsys 生成時のオプションは、mpuaccレジスターにMASKまたはLIMITフィールドが含めるかどうかを制御します。

MASKとLIMITフィールドは相互に排他的です。MASK 変数と LIMIT 変数については mpuacc コントロール・レジスター・フィールドの表を参照してください。

次の項ではmpuaccフィールドについて詳しく説明します。

領域に予約されているメモリー量がサイズで定義されている場合、MASKフィールドはメモリー領域のサイズを指定します。MASKフィールドは、mpubaseレジスターのBASEフィールドと同じビット数です。

MASK 領域サイズ・エンコーディングの表は、完全な 31 ビットのバイトアドレス空間でのすべての可能な領域サイズのMASKフィールド・エンコーディングをリストしています。

MASKフィールドは次の値を有し、region_sizeはバイト単位です。

MASK = 0x1FFFFFF << log2(region_size >> 6)

領域に予約されているメモリー量が上位アドレス制限で定義されている場合、LIMITフィールドはメモリー領域の上位アドレス + 1 を指定します。例えば、256 バイトの最小領域サイズを有するバイトアドレス0x4000~0x4fffのメモリー範囲を達成するには、mpubaseレジスターのBASEフィールドは0x40 (0x4000 >> 6) に設定され、LIMITフィールドは0x50 (0x5000 >> 6) に設定されます。LIMITフィールドは、mpubaseレジスターのBASEフィールドのビット数より 1 ビット多いため、mpuaccレジスターのビット 31 はLIMITフィールドで使用できます。

Cフラグは、MPU 領域のデフォルト・データ・キャッサブルを決定します。Cフラグはデータ領域にのみ適用されます。命令領域では、Cビットは 0 で書き込まれ、常に 0 として読み出される必要があります。

データ領域でデータ・キャッシャビリティーが有効の際、システムにデータキャッシュが存在する場合、その領域へのデータアクセスをキャッシュできます。デフォルト・キャッシャビリティーをオーバーライドし、アドレスをldio命令またはstio命令でキャッシュ不能にできます。

Mtフラグはフラグは MPU データ領域のデフォルト・メモリータイプを決定します。MTフラグはデータ領域でのみ適用されます。命令領域では、MTビットは命令領域で 0 で書き込まれ、常に 0 として読みだされる必要があります。

データ・キャッシャビリティーがデータ領域で有効の際に、システムにデータキャッシュが存在する場合、その領域へのデータアクセスをキャッシュできます。デフォルト・キャッシャビリティーをオーバーライドし、アドレスをldio命令またはstio命令でキャッシュ不能にできます。MT フィールドのエンコーディングは、MPUACC のビット 5 がキャッシュ可能ビット (0 = キャッシュ不能、1 = キャッシュ可能 ) で、ビット 6 がゼロである、Nios II Classic コア MPU と下位互換性があるようにセットアップされています。

eccinjレジスターは ECC をサポートする Nios II プロセッサーの内蔵 RAM ブロックに 1 および 2 ビット・エラーを注入します。エラーを注入すると、ソフトウェアは ECC エラー例外処理コードをテストできます。エラーは、パリティービットではなくデータビットに注入されます。eccinjレジスターは、ECC が存在する場合にのみ使用できます。

シャドー・レジスター・セットが実装されていると、status.CRSは現在使用中のレジスターセットを表示します。Nios II コアは最大 63 個のシャドー・レジスター・セットを有することができます。シャドー・レジスター・セット数を n に設定した場合、シャドー・レジスター・セットは 1 ~ n の数になります。レジスターセット 0 は通常のレジスターセットです。

シャドー・レジスター・セットはまさに通常のレジスターセットと同様に動作します。現在使用中のレジスターセットは、status.CRSを調べることでのみ決定できます。

シャドー・レジスター・セットは一般的に EIC インターフェイスと組み合わせて使用されます。この組み合わせにより、実質的に割り込みレイテンシーが短縮されます。

EIC インターフェイスの使用の詳細については、「例外プロセス」項を参照してください。

システム・ソフトウェアは、status.PRSの設定およびrdprs命令とwrprs命令の使用により、任意のシャドー・レジスター・セットからの読み出しおよびシャドー・レジスター・セットへの書き込みができます。

rdprs命令とwrprs命令の詳細については、「Nios II プロセッサー・リファレンス・ハンドブック」の「命令セット・リファレンス」の章を参照してください。

The sstatusレジスターは各シャドー・レジスター・セットの汎用レジスターr30に物理的に格納されます。通常のレジスターセットにはsstatusレジスターがありませんが、各シャドー・レジスター・セットには個別のsstatusレジスターがあります。

EIC インターフェイスとシャドー・レジスター・セットの両方が実装されている場合は、Nios II コアにはsstatusレジスターが存在します。が存在します。各シャドー・レジスター・セットには、sstatusレジスターのコピーが 1 つあります。

Nios II プロセッサーが割り込みを受け取る際、シャドー・レジスター・セットが要求され (RRS = 0)、MMU が例外ハンドラーモード (status.EH = 0) にない場合、プロセッサーはstatusレジスターをsstatusレジスターにコピーします。

RRS について詳しくは、「要求されるレジスターセット」を参照ししてください。

status.EHについて詳しくは、例外を受け取った後の Nios II プロセッサー・ステータスの表を参照してください。

• プロセッサーが現在通常のレジスターセットで実行している場合、estatus.CRSに新しいレジスターセットの番号を挿入し、eretを実行します。
• プロセッサーが現在通常のシャドー・レジスター・セットで実行している場合、sstatus.CRSに新しいレジスターセットの番号を挿入し、eretを実行します。

eretを実行してレジスターセットを変更する前に、システム・ソフトウェアはシャドー・レジスター・セット内のレジスターが破損しないように、個々の外部割り込みマスクを正しく設定する必要があります。割り込みがレジスターセットに割り当てられている場合、システム・ソフトウェアは次のいずれかの条件を満たしてる必要があります。　　

• ISR がレジスター内容を保持するために書き込まれている
• 個々の割り込みが無効になる。個々の外部割り込みへの無効化の方法は EIC の実装に固有である。

システム要件に応じて、システム・ソフトウェアは、各レジスターセットに対して専用スタックを作成したり、いくつかのレジスターセット間でスタックを共有したりすることができます。スタックが共有されている場合、システム・ソフトウェアはレジスターセットが変更されるたびに、スタックポインターをコピーする必要があります。rdprs命令を使用して、現在のレジスターセットと別のレジスターセットの間に、スタックレジスターをコピーします。

• gpレジスターを通常のレジスターセットで初期化した後、それをすべてのシャドー・レジスター・セットにコピーし、すべてのコードが小さなデータセクションを正しくアドレス指定できるようにします。
• wrprs命令を使用して、zeroレジスターを通常のレジスターセットからすべてのシャドー・レジスター・セットにコピーします。

MPU 領域の読み出し動作は、領域の属性での現在の値を取得します。各 MPU 領域読み出し動作は、次の動作から成ります。

• mpubase.INDEXとmpubase.Dフィールドが MPU 領域を識別する設定ように設定された状態でのmpubaseレジスターへのwrctl命令の実行
• mpuacc.RDフィールドを 1 に設定し、mpuacc.WRフィールドをゼロにクリアーした状態でのmpuaccレジスターへのwrctl命令の実行。この動作はmpubaseレジスターとmpuaccレジスターの値をロードする
• mpubaseレジスターへのrdctl命令を実行し、ロードしたmpubaseレジスター値を読み出す
• mpuaccレジスターへのrdctl命令を実行し、ロードしたmpuaccレジスター値を読み出す

MPU 領域の読み出し動作ではmpubase.BASE、mpuacc.MASKまたはmpuacc.LIMIT、mpuacc.C、およびmpuacc.PERMの値を取得します。

MPU 領域の書き込み動作は領域の属性の新しい値を設定します。各 MPU 領域の書き込み動作は、次の動作から成ります。

• mpubase.INDEXとmpubase.Dフィールドが MPU 領域を識別する設定ように設定された状態でのmpubaseレジスターへのwrctl命令の実行
• mpuacc.WRフィールドを 1 に設定し、mpuacc.RDフィールドをゼロにクリアーした状態でのmpuaccレジスターへのwrctl命令の実行

MPU 領域の書き込み動作では、MPU 領域での新しい属性としてmpubase.BASE、mpuacc.MASKまたはmpuacc.LIMIT、mpuacc.C、およびmpuacc.PERMの値を設定します。

通常、wrctl命令はパイプラインをフラッシュし、コントロール・レジスターの書き込みによる影響がwrctl命令実行の完了直後に発生することを保証します。ただし、wrctl命令はmpubaseとmpuaccコントロール・レジスターが自動的にパイプラインをフラッシュしないように指示します。代わりに、システム・ソフトウェアは、必要に応じて ( パイプラインをフラッシュするレジスターにflushp命令またはwrctl命令を使用して ) パイプラインをフラッシュする役割があります。コンテクストスイッチは、通常、新しいスレッド用に MPU 領域を再プログラミングする必要があるため、各wrctl命令でパイプラインをフラッシュすると不要なオーバーヘッドが発生します。

システムリセット時に MPU は無効になります。MPU を使用可能にする前に、アルテラはすべての MPU 領域を初期化することを推奨します。目的の命令およびデータ領域を有効にするには、この章の「MPU 領域の読み出しおよび書き込み動作」の項に記載のとおりに、各領域の属性をmpubaseおよびmpuaccレジスターに書き込みます。未使用領域も無効にする必要があります。領域サイズを使用する場合、mpuacc.MASKをゼロにクリアーします。制限を使用する場合は、mpubase.BASEをゼロ以外の値に設定し、 mpuacc.LIMITを 0 にクリアーします。

コンテキスト・スイッチを実行するには、wrctlを使用してconfigレジスターのPEフィールドにゼロを書き込んで MPU を無効にし、新しいスレッドのデータ構造からすべての MPU 領域を定義し、別のwrctlを使用してconfig.PEMPUを有効にします。

この章の「MPU領域の読み出しおよび書き込み動作」で説明のある、wrctl命令のペアを使用して各領域を定義します。必要なすべての領域が定義されるまで、このデュアルwrctl命令シーケンスを繰り返します。

Nios II プロセッサーは、命令キャッシュ RAM を初期化する各キャッシュラインでINITI命令を実行します。ラインが無効の場合は検出された ECC エラーが無視されるため、RAM は特別な初期化を必要としません。つまり、INITI命令がタグ RAM を初期化した後に、ラインは無効になります。

すべてのレジスター ( レジスター 0 を除く ) に書き込む Nios II プロセッサーの命令は、レジスターファイルの RAM ブロックを初期化します。シャドー・レジスター・セットが存在する場合、このステップは、WRPRS命令を使用してシャドー・レジスター・セット内のすべてのレジスターに対して実行されます。

すべての TLB RAM の位置を書き込む Nios II プロセッサーの命令は、MMU TLB RAM を初期化します。この RAM は特別な初期化が必要ありません。

ソフトウェアの ECC を無効にするには、CONFIG.ECCENに 0 を書き込みます。ソフトウェアは、ECC が無効になっても ECC パリティービットが RAM ブロックに書き込まれるため、ECC が保護する RAM の再初期化なしで ECC を無効にすることができます。

通常、TLB はメインメモリー ( SDRAM など ) に格納されたオペレーティング・システムのページテーブルのソフトウェア管理のキャッシュであるため、ソフトウェアは回復不可能な MMU TLB ECC エラー (2 ビット・エラー ) から回復することができます。ソフトウェアは TLB エントリーを無効にでき、ECC エラーの例外から受け取った命令に戻って、ページテーブルから TLB エントリーをロードするために TLB の誤ったコードを実行します。

一般に、レジスターファイルの正しい値が分からないため、ソフトウェアはレジスターファイルの ECC エラー (2 ビット・エラー ) から回復できません。例外ハンドラーが関連する 2 ビット ECC エラーのあるレジスターを読み出すと、別の ECC エラーが発生し例外ハンドラーループが起こる可能性があります。

例外ハンドラーループは、ネスト式例外処理の準備が整う前に例外ハンドラーに ECC エラーの例外が発生することで起こります。発生または例外ハンドラーループを最小限に抑えるには、 ECC エラー例外ハンドラーコードを通常のキャッシュ可能メモリーに配置し、すべてのデータアクセスがキャッシュ不能なメモリーにあることを確認し、レジスターの読み出しを最小限にします。

ECC エラー信号 (ecc_event_bus) は、可能なハンドラーループの検出や Nios II プロセッサーのリセットのための外部ロジックのEEH信号を提供します。

この項では、ECC が有効になり、割り込みがコードシーケンスの期間に無効になると仮定して、各 ECC 保護の RAMに ECC エラーを注入するためのコードシーケンスについて説明します。

1. JMP 命令までのすべてのコードが同じ命令キャッシュラインにあるか、ITCM に配置されているかを確認します。
2. FLUSHI命令を使用して、実行中のコードを含むライン以外の命令キャッシュラインをフラッシュします。
3. FLUSHP命令を使用してパイプラインをフラッシュします。
4. WRCTL命令を使用して、ECCINJ.ICTAGをINJSまたはINJDに設定します。この設定により、ECC エラーは次のラインフィルの開始時に発生します。
5. JMP命令を使用して、フラッシュフィルの命令アドレスにジャンプします。
6. ECC エラーは、ラインフィルの開始時にタグ RAM を書き込む際に注入されます。
7. RDCTL命令を使用して、ECCINJ.ICTAGの値がNOINJであることを確認します。
8. ECC エラーは、JMP命令のターゲットの後にトリガーされます。

1. JMP 命令までのすべてのコードが同じ命令キャッシュラインにあるか、ITCM に配置されているかを確認します。
2. FLUSHI命令を使用して、実行中のコードを含むライン以外の命令キャッシュラインをフラッシュします。
3. FLUSHP命令を使用してパイプラインをフラッシュします。
4. WRCTL命令を使用して、ECCINJ.ICDATをINJSまたはINJDに設定します。この設定により、ECC エラーは次のラインフィルの開始時に発生します。
5. JMP命令を使用して、フラッシュされたラインの命令アドレスにジャンプします。
6. ECC エラーは、ラインフィルの開始時にタグ RAM を書き込む際に注入されます。
7. RDCTL命令を使用して、ECCINJ.ICDATの値がNOINJであることを確認します。
8. JMP命令のターゲットを 2 回 (1 回目は ECC エラーを挿入し、2 回目はトリガーされます ) 実行します。

Nios II で実行中のソフトウェアは、Nios II が ECC エラーの訂正時にITCMのみを書き込むため、直接ITCMに ECC エラーを注入できません。ITCMに ECC を注入するには、TCM RAM もDTCMマスターに接続する必要があります。Nios II が提供するDTCMエラーの注入メカニズム ( つまり、ECCINJレジスター ) は、TCM RAM にエラーを注入するために次のように使用されます。

1. WRCTL命令を使用してECCINJを設定し、ITCMに接続されたDTCMに ECC エラーを注入するようにします。
2. STW命令を使用してDTCMを書き込みます。
3. RDCTL命令を使用して、WRCTLによって書き込まれたECCINJフィールドの値がNOINJであることを確認します。
4. JMP命令を使用して、ITCM の命令アドレスにジャンプします。
5. ECC エラーはJMP命令のターゲットでトリガーされる必要があります。

1. WRCTL命令を使用して、ECCINJ.RFをINJSまたはINJD( 必要に応じて) 設定します。
2. R0以外の任意のレジスターを書き込む任意の命令を実行します。
3. RDCTL命令を使用して、ECCINJ.RFの値がNOINJであることを確認します。
4. 命令を使用して、OR rd, r0, rx ( このrxは前のステップで書き込まれたレジスターを指します ) といった rA から目的のレジスターを読み出します。この動作により、ECC エラーがトリガーされます。
5. 命令を使用して、OR rd, rx, r0 ( このrxは前のステップで書き込まれたレジスターを指します ) といった rB から目的のレジスターを読み出します。

1. データアドレスからのLOAD命令を使用して、キャッシュ内のラインを得ます。このラインはクリーンされる必要があります。
2. WRCTL命令を使用して、ECCINJ.DCTAGをINJSまたはINJDに設定します。
3. そのラインにマップされたデータアドレスからSTORE命令を使用します。STORE命令はデータキャッシュ内でヒットし、ダーティービットをセットするタグ RAM を書き込む必要があります。
4. ECC エラーはタグ RAM が書き込まれる際に注入されます。
5. RDCTL命令を使用して、ECCINJ.DCTAGの値がNOINJであることを確認します。ECCINJを回避するために、RDCTLの前にFLUSHP命令を使用します。
6. 同じラインに別のLOADまたはSTORE命令を実行します。
7. ECC エラーはこの 2 番目のLOAD/STORE命令でトリガーされる必要があります。

1. FLUSHDA命令を使用してラインがデータキャッシュにないことを確認します。
2. LOAD命令を使用してデータ・キャッシュ・ラインをロードします。
3. WRCTL命令を使用して、ECCINJ.DCDATフィールドをINJSまたはINJDに設定します。
4. LOAD命令を使用して、データ・キャッシュ・ラインのアドレスにエラーを注入します。
5. RDCTL命令を使用して、ECCINJへのWRCTLによって書き込まれたフィールドの値がNOINJであることを確認します。ECCINJの RAW ハザードを回避するために、RDCTLの前にFLUSHPを使用します。
6. 同一アドレスからのLOAD命令を使用します。
7. ECC エラーはLOAD命令でトりがーされる必要があります。

1. LOAD命令を使用してデータ・キャッシュ・ラインをロードします。
2. WRCTLを使用して、ECCINJ.DCDATフィールドをINJSまたはINJD ( 必要に応じて ) を設定します。
3. データ・キャッシュ・ラインのアドレスにSTORE命令を使用します。
4. RDCTL命令を使用して、ECCINJへのWRCTLによって書き込まれたフィールドの値がNOINJであることを確認します。ECCINJの RAW ハザードを回避するために、RDCTLの前にFLUSHPを使用します。
5. 同一アドレスからのLOAD命令を使用するか、ダーティーラインのライトバック ( FLUSHDA命令など ) をトリガーします。
6. ECC エラーは、ダーティーラインのライトバック中に検出されない限り、LOAD命令でトリガーする必要があります。ダーティラインののライトバックでは、ECC エラーは後に未定義数の命令をトリガーします。

1. LOAD命令を使用してデータ・キャッシュ・ラインをロードします。
2. WRCTL命令を使用して、ECCINJ.DCWBフィールドをINJSまたはINJD ( 必要に応じて ) に設定します。
3. データ・キャッシュ・ラインのアドレスにSTORE命令を使用します。
4. RDCTL命令を使用して、ECCINJへのWRCTLによって書き込まれたフィールドの値がNOINJであることを確認します。ECCINJRAW ハザードを回避するために、RDCTLの前にFLUSHPを使用します。
5. 同一アドレスからのLOAD命令を使用するか、ダーティーラインのライトバック ( FLUSHDA命令など ) をトリガーします。
6. ECC エラーは、ダーティーラインのライトバック中に検出されない限り、LOAD命令でトリガーする必要があります。ダーティラインののライトバックでは、ECC エラーは後に未定義数の命令をトリガーします。

1. WRCTL命令を使用して、目的のDTCMのためにECCINJ.DTCMフィールドをINJSまたはINJDに設定します。　
2. STW命令を使用してDTCMのアドレスを書き込みます。
3. RDCTL命令を使用して、ECCINJへのWRCTLによって書き込まれたフィールドの値がNOINJであることを確認します。
4. DTCMの同一アドレスからLOAD命令を使用します。
5. ECC エラーはLOAD命令でトリガーされる必要があります。

1. WRCTL命令を使用して、ECCINJ.TLBをINJSまたはINJDに設定します。
2. WRCTL命令を使用して TLB エントリーを書き込みます。ECC エラーはこの時点で注入され、任意の関連する uTLB エントリーがフラッシュされます。
3. RDCTL命令を使用して、ECCINJ.TLBの値がNOINJであることを確認します。
4. ハードウェアに (uTLB にコピーされた ) TLB エントリーを読み出させる命令 / データアクセスを実行し、この時点で ECC デコーダーが ECC エラーを検出するひつようがあります。あるいは、TLB のソフトウェア読み出しを (TLBMISC.RDを 1 に書き込むことによって ) 開始します。　　　
5. ソフトウェア読み出しが開始されると、TLBMISC.EEフィールドはソフトウェア読み出しをトリガーしたWRCTLの後の任意の命令で、 1 に設定される必要があります。
6. ハードウェアの読み出しが開始されると、ハードウェアの読み出し後に最初の命令で ECC エラーがトリガーされます。

すべての Nios II の例外は正確です。例外を処理した後、正確な例外は必要に応じてシステムソフトウェアが命令を再実行できるようにします。

• 例外 — プロセッサーの内部または外部のいずれかにイベントによって引き起こされる、例外のプログラムの通常フローからの制御の転送で、即時の注意が必要である。
• 割り込み — 外部デバイスからの明示的な要求信号によって引き起こされる例外。ハードウェア割り込み
• 割り込みコントローラー — 外部デバイスからの要求信号を割り込むためにプロセッサーをインターフェイスするハードウェア
• 内部コントローラー — Nios II プロセッサーに内蔵されている非ベクター割り込みコントローラー。内部割り込みコントローラーは Nios II プロセッサーのすべてのリビジョンで使用できる。
• ベクター割り込みコントローラー (VIC) — アルテラが提供する外部割り込みコントローラー
• 例外 ( 割り込み ) レイテンシー — 例外を発生させるイベント ( 割り込み要求の挿入 ) とハンドラーアドレスでの最初の命令の実行との間の経過時間
• 例外 ( 割り込み ) 応答時間 — 例外を発生させるイベント ( 割り込み要求の挿入 ) とノンオーバーヘッド例外コードの実行、つまり例外タイプ ( デバイス) に特化したものとの間の経過時間
• グローバル割リ込み — 内部割り込みおよびマスク可能外部割り込みを含むが、マスク不能割り込みは含まない Nios II プロセッサーのすべてのマスク可能な例外
• ワーストケース・レイテンシー — 最大無効時間または最大のマスクされた時間と仮定する、また、マスク時間 / 無効時間の開始時に例外 ( 割り込み ) が発生したと仮定した、例外 ( 割り込み ) レイテンシーの値
• 最大無効時間 — システムが無効になったマスク可能割り込みを使用して費やす最大連続時間
• 最大マスク時間 — システムがマスクされるシングル割り込みを使用して費やす最大連続時間
• シャドー・レジスター・セット — Nios II 汎用レジスターの完全な代替セットで、ISR 用の別のランタイム・コンテキストを維持するために使用される。

それぞれの Nios II の例外は、次のいずれかに分類されます。

• リセット例外—Nios II プロセッサーがリセットされると発生します。制御は、Nios II プロセッサーの IP コア・セットアップ・パラメーターで指定するリセットアドレスに転送されます。
• ブレーク例外—JTAG デバッグモジュールが制御を要求すると発生します。制御は、Nios II ロセッサーの IP コア・セットアップ・パラメーターで指定するブレークアドレスに転送されます。
• 割り込み例外—ペリフェラルがサービスを必要とする状態を通知すると発生します。
• 命令関連例外—Nios II の例外の表に記載されているように、いくつかの内部条件が発生すると、発生します。制御は Nios II プロセッサーの IP コア・セットアップ・パラメーターで指定した例外アドレスに転送されます。

次の表の列で、例外についての情報を特定しています。

• 例外—例外の名前を表します。
• タイプ—例外タイプを指定します。
• 可能—例外サポートが存在するのがいつかを指定します。
• 原因—exception.CAUSEフィールドを書き込む例外のexceptionレジスターのCAUSEフィールドの値を指定します。
• アドレス—命令か例外に関連するデータアドレスかを指定します。
• ベクター—例外が発生した際に、プロセッサーが制御を渡す例外ベクターアドレスを指定します。

例外レイテンシーはシステムがどの位迅速に例外に応答できるかを指定します。例外レイテンシーは例外のタイプ、ソフトウェアとハードウェア・コンフィグレーション、およびプロセッサー・ステートにより異なります。

割り込みコントローラーは割り込みを個別にマスクできます。各割り込みは異なる最大マスク時間を有します。割り込み i でのワーストケース割り込みレイテンシーは割り込みの最大マスク時間または最大無効時間の大きい方で決定されます。

1. status.RSIEを 1 に設定し、statusレジスターのその他のフィールドすべてをクリアーします。
2. リセットベクターに関連付けられた命令キャッシュラインを無効にします。
3. リセットベクターにあるリセットハンドラーの実行を開始します。

status.PIEフィールドをクリアーすると、マスク可能割り込みが無効になります。MMU または MPU が存在する場合、status.Uフィールドをクリアーすると、プロセッサーは強制的にスーパーバイザー・モードに入ります。

リセット・キャッシュ・ラインの無効化は、リセットコードの命令フェッチがキャッシュされないメモリーから行われることを保証します。

リセットベクターに関連する命令キャッシュラインとは別に、キャッシュメモリーの内容はリセット後に不確定になります。リセット後にキャッシュ・コヒーレンシーを確保するには、リセットベクターで配置したリセットハンドラーが命令キャッシュを直ちに初期化する必要があります。次に、リセットハンドラーまたは後続のルーチンのいずれか、データキャッシュを初期化する必要があります。

リセット状態は、他のすべてのシステム・コンポーネントでは定義されません。

• 通常のレジスターセットのzero (r0) を除く汎用レジスター。これは永続的にゼロです。
• statusを除くコントロール・レジスター。status.RSIEはリセット 1 で、保持されるフィールドは 0 にリセットされます。
• 命令およびデータメモリー
• リセットベクターに関連する命令キャッシュライン以外のキャッシュメモリー
• ペリフェラル。適切なペリフェラル・データシートまたはリセット条件の仕様を参照してください。
• カスタム命令ロジック
• Nios II C-to-Hardware (C2H) アクセレーション・コンパイラー・ロジック

詳しくは、「Nios II Custom Instruction User Guide」の「reset conditions」を参照してください。

ブレーク処理とは、ソフトウェア・デバッグ・ツールがブレークポイントやウォッチポイントなどのデバッグおよび検証機能を実装する方法です。ブレーク処理は例外処理の一つの種類ですが、ブレーク・メカイズムは一般的な例外処理とは独立しています。ブレークは例外処理中に発生し、例外ハンドラーをデバッグするためにデバッグツールを有効にします。

プロセッサーは次のいずれかの条件下でブレーク処理ステートを入力します。

• プロセッサーはbreak命令を実行する ( ソフトウェア・ブレークと呼ばれる )
• JTAG デバッグはハードウェア・ブレークをアサートする

1. statusレジスターの内容をbstatusに格納します。
2. status.PIEをゼロにクリアーし、マスク可能割り込みを無効にします。

通常のレジスターセットのbstatusコントロール・レジスターおよび汎用レジスターbt (r25) とba (r30) は、デバッグ用に予約されています。コードはこれらのレジスターへの書き込みを妨げられませんが、デバッグコードで値が上書きされる可能性があります。ブレークハンドラーは、bt (r25) を使用して追加レジスターを節約します。

ブレークの処理後、ブレークハンドラーはbret命令を実行することでプロセッサーの制御を解除します。bret命令は、bstatusの内容をコピーしてstatusを復元し、通常のレジスターセットのbaレジスター (r30) のアドレスにプログラムの実行を戻します。btとbaのほかに、すべてのレジスターはブレークハンドラーから復帰してブレーク前の状態に戻されることが保証されています。

• 外部割り込みコントローラー・インターフェイス
• 内部割り込みコントローラー

Nios II プロセッサーは EIC の特定の実装に依存しません。EIC 構成の程度と EIC 構成の方法は実装固有のものです。この項では、EIC インターフェイスと EIC の一般的な機能について説明します。使用方法の詳細については、システムの特定の EIC の資料を参照してください。

IRQ がアサートされると、EIC は次の情報を Nios II プロセッサーに提供します。

• 要求されるハンドラーアドレス (RHA)—この項の「要求されるハンドラーアドレス」のセクションを参照してください。
• 要求される割り込みレベル (RIL)—この項の「要求される割り込みレベル」のセクションを参照してください。
• 要求されるレジスターセット (RRS)—この項の「要求されるレジスターセット」のセクションを参照してください。
• 要求されるマスク不能割り込み (RNMI) モード—この項の「要求される NMI モード」のセクションを参照してください。

Nios II プロセッサーの EIC インターフェイスは単一の EIC に接続しますが、EIC はデイジーチェーン・コンフィグレーションをサポートできます。デイジーチェーン・コンフィグレーションでは、複数の EIC が割り込みを監視して優先順位を付けることができます。プロセッサーに直接接続された EIC は、デイジーチェーン内のすべての EIC からの優先度の高い割り込みをプロセッサーに提示します。

EIC コンポーネントは任意のレベルのデイジーチェーンをサポートすることができ、Nios II プロセッサーは任意の数の優先順位付き割り込みを処理することができます。

一般的な EIC の実装について詳しくは、「Embedded Peripherals IP User Guide」の「Vectored Interrupt Controller」の章を参照してください。

各割り込みの RHA は、通常、ソフトウェアで設定可能です。RHA の指定方法は特定の EIC 実装により異なります。

Nios II プロセッサーが MMU で実装されている場合、プロセッサーはハンドラーアドレスを仮想アドレスとして扱います。

RIL はマスク不能割り込みでは無視されます。

レジスターセットを割り込みに割り当てる方法は、特定の EIC の実装に依存します。 レジスターセット割り当てはソフトウェアで設定可能です。

複数の割り込みを設定してレジスターセットを共有することができます。この場合、レジスターの破損を避けるために割り込みハンドラーを書き込む必要があります。例えば、次のいずれかの条件が満たされている必要があります。

• 割り込みは互いにあらかじめ行うことはできません。例えば、すべての割り込みは同じレベルにあります。
• レジスターはソフトウェアに保存されます。例えば、各割り込みハンドラーは、独自のレジスターをエントリーに保存し、終了時にそれらのレジスターを復元します。

通常、Nios II プロセッサーは割り込みを受け取ると、同じレジスターセット内の他の割り込みが無効になるように構成されています。レジスターセット内の割り込みプリエンプションが必要な場合、割り込みハンドラーはレジスターセット内の割り込みを再度有効にできます。

デフォルトでは、Nios II プロセッサーは割り込み要求を受け取るとマスク可能な割り込みを無効にします。ネスト型割り込みを有効にするには、システム・ソフトウェアまたは ISR 自体が割り込みが発生した後に割り込みを再度有効にする必要があります。

status.ILと RIL はマスク不能割り込みで無視されます。

最高の割り込み性能を得るには、最も重要な各割り込みに専用レジスターセットを割り当てます。この章の「要求されるレジスターセット」のセクションの説明のように、ISR がレジスターの破損から保護されている場合、あまり重要でない割り込みはレジスターセットを共有できます。

割り込みをレジスターセットにマッピングする方法は、特定の EIC の実装に固有です。

• statusコントロール・レジスターのPIEビットが 1 の場合
• 割り込み要求入力IRQ n がアサートされている場合
• ienableコントロール・レジスターの対応するビット n が 1 の場合

ハードウェア割り込みが発生すると、プロセッサーはPIEビットを 0 にクリアーし、割り込みを無効にして、この章の「例外処理フロー」に記載されている他のステップを実行します。

Ipendingコントロール・レジスターの値は、どの割り込み要求コントロール・レジスターの値は、どの割り込み要求 (IRQ) が保留中であるかを示します。ペリフェラルの設計により、IRQ ビットはプロセッサーがペリフェラルに明示的に応答するまでアサートされたままであることが保証されます。

Nios II プロセッサーは次の命令関連の例外を生成します。

• トラップ命令
• ブレーク命令
• 未実装命令
• 不正命令
• スーパーバイザー専用命令
• スーパーバイザー専用命令アドレス
• スーパーバイザー専用データアドレス
• ミスアライメント・データ・アドレス
• ミスアライメント・デスティネーション・アドレス
• 除算エラー
• 高速 TLB ミス
• ダブル TLB ミス
• TLB 許可違反
• MPU 領域違反

詳細については、この章の「潜在的な未実装命令」を参照してください。

このオプションの制御に関する情報は、「Nios II プロセッサー・リファレンス・マニュアル・ハンドブック」の「Nios II プロセッサーのインスタンス化」の章を参照してください。

プロセッサーが未定義のオペコードまたはオペコード拡張のフィールドで命令を発行し、不正命令例外チェックがオンになると、不正命令例外を生成します。

未使用のオペコードおよびオペコード拡張子については、「Nios II プロセッサー・リファレンス・ハンドブック」の「命令セット・リファレンス」の章にある R 型の命令の OP エンコードおよび OPX エンコードを参照してください。

各特定の Nios II コアについて詳しくは、「Nios II プロセッサー・リファレンス・ハンドブック」の「Nios II コア実装の詳細」の章を参照してください。

この例外は、スーパーバイザー・モードとユーザーモードを使用するように設定された Nios II プロセッサーでのみ実装されます。詳細については、この章の「動作モード」を参照してください。

この例外は、MMU を含む Nios II プロセッサーでのみ実装されています。

この例外は MMU を含む Nios II プロセッサーでのみ実装されます。

このオプションの制御については、「Nios II プロセッサー・リファレンス・ハンドブック」の「Nios II プロセッサーのインスタンス化」の章を参照してください。

バイトアドレスがロードまたはストアー命令のデータ幅 ( データの場合は 4 バイト、ハーフワードの場合は 2 バイト）の幅の倍数でない場合 、データアドレスはミスアライメントとみなされます。バイトのロードおよびストア命令は常にアライメントしていますので、ミスアライメント・アドレス例外は発生しません。

このオプションの制御については、「Nios II プロセッサー・リファレンス・ハンドブック」の「Nios II プロセッサーのインスタンス化」の章を参照してください。

命令のターゲット・バイト・アドレスが 4 の倍数でない場合、デスティネーション・アドレスはミスアライメントとみなされます。

除算エラー例外は、表現できない商を生成する除算命令を検出します。この 2 つの場合は、ゼロで割ったものと負の最大値 -2147483648 (0x80000000) を -1 (0xffffffff) で割った符号付き除算です。除算命令がハードウェアでサポートされている場合にのみ除算エラー検出が可能です。

高速 TLB ミス例外には 2 種類あります。

• 高速 TLB ミス ( 命令 )—命令フェッチによりこの例外が発生する可能性があります。
• 高速 TLB ミス ( データ )—ロード、ストアー、initda、およびflushda命令によりこの例外が発生する可能性があります。

高速 TLB ミス例外ハンドラーはtlbmisc.Dフィールドを検査して、どのような種類の高速 TLB ミス例外が発生したかを判定できます。

がブル TLB ミス例外には 2 種類あります。

• ダブル TLB ミス ( 命令 )—命令フェッチによりこの例外が発生する可能性があります。
• ダブル TLB ミス ( データ )—ロード、ストアーinitda、およびflushda命令によりこの例外が発生する可能性があります。

一般的な例外ハンドラーは、exception.CAUSEまたはtlbmisc.Dフィールドのいずれかを検査し、どちらの種類のダブル TLB ミス例外が発生したかを判断することができます。

TLB 許可違反例外には 3 種類あります。

• TLB 許可違反 ( 実行 )—命令フェッチによりこの例外が発生する可能性があります。
• TLB 許可違反 ( リード )—ロード命令によりこの例外が発生する可能性があります。
• TLB 許可違反 ( ライト )—ストアー命令によりこの例外が発生する可能性があります。

一般的な例外ハンドラーは、exception.CAUSEフィールドを例外を検査し、どの許可が違反されたかを判断します。

• 命令フェッチまたはデータアドレスが領域と一致するが、その領域での許可がアクションの完了を許可しません。
• 命令フェッチまたはデータアドレスがどの領域とも一致しません。

一般的な例外ハンドラーは、MPU 領域の属性を読み取って、アドレスがどの領域にも一致しないか、違反があったかどうかを判断します。

MPU 領域違反の例外には 2 種類あります。

• MPU 領域違反 ( 命令 )—命令フェッチによりこの例外が発生する可能性があります。
• MPU 領域違反 ( データ )—ロード、ストアー、initda、およびflushda命令によりこの例外が発生する可能性があります。

一般的な例外ハンドラはexception.CAUSEフィールドを検査し、どの種類の MPU 領域違反例外が発生したかを判断することができます。

高速 TLB ミス例外ハンドラーは、高速 TLB ミス例外のみを処理します。これは、TLB ミスを迅速に処理するために構築されています。Qsys の Nios II Processor パラメーター・エディターで指定された高速 TLB ミス例外ハンドラーアドレスは、Nios II プロセッサー・パラメーター・エディターで高速 TLB ミス例外ベクターと呼ばれます。

• RHA—要求された割り込みに割り当てられた割り込みハンドラーの要求されたハンドラーアドレス
• RRS—要求されたレジスターは、割り込みハンドラーが実行される際に使用されるように設定される。シャドー・レジスター・セットが実装されていない場合、RRS は常に 0 の必要があります。
• RIL—要求される割り込みレベルは、割り込みの優先順位を指定します。
• RNMI—要求された NMI フラグは、割り込みをマスク不能として扱うかどうかを指定します。

  RHA、RRS、RIL、RNMI の詳細については、「Nios IIプロセッサ・リファレンス・ハンドブック」の「Nios II コア実装の詳細」の章の「Nios II/f コア」を参照してください。

EIC インターフェイスが Nios II プロセッサーに割り込みがある場合、プロセッサーは次のようないくつかの基準を使用して割り込みを取るかどうかを決定します。

• マスク不能割り込み—プロセッサーは、前の NMI を処理していない限り、任意の NMI を受け取ります。
• マスク可能割り込み—マスク可能割り込みが有効になり、要求される割り込みレベルが現在処理されている割り込み ( 存在する場合 ) のレベルより高い場合、プロセッサーはマスク可能割り込みを受け取ります。しかしながら、シャドー・レジスター・セットが実装されている場合、割り込みが現在のレジスターセットと異なるレジスターセットを要求する場合か、レジスターセットが割り込みイネーブルフラグ (status.RSIE) を設定される場合にのみ、プロセッサーは割り込みを受け取ります。

  表 45.  外部割り込みを受け取るために必要な条件

  RNMI == 1		RNMI == 0
  status.NMI == 0	status.NMI == 1	status.PIE == 0	status.PIE == 1
  			RIL <= status.IL	RIL > status.IL
  				プロセッサーにシャドー・レジスター・セットが存在する場合			シャドー・レジスター・セットが存在しない場合
  				RRS == status.CRS		RRS != status.CRS
  				status.RSIE == 0	status.RSIE == 1
  有	無	無	無	無17	有	有	有

Nios II プロセッサーは、この章の「シャドー・レジスター・セット」のセクションの説明のように、シャドー・レジスター・セットによる高速ネスト割り込みをサポートしています。

status.PIEを設定すると、割り込みハンドラーがstatus.PIEを 1 に設定することなく、上位レベルの割り込みを即座に実行できます。

プロセッサーは、シャドー・レジスター・セットなしの場合と同様に、例外を取る際にマスク可能割り込みを無効にします。個々の割り込みハンドラーは、必要に応じてstatus.PIEを 1 に設定して割り込みを再び有効にできます。

割り込みは、PIEビットに 1 を書き込むことで再びイネーブルにでき、それによって現在の ISR を割り込ませることができます。通常、例外ルーチンは割り込みを再度有効にする前に、優先度が等しいかそれより低い IRQ が無効になるようにienableを調整します。

詳細は、「ネスト式例外の処理」を参照してください。