Embedded Design Handbook
エンベデッド・デザイン
ハンドブック
101 Innovation Drive
San Jose, CA 95134
www.altera.com
ED_HANDBOOK-2.9
© 2011 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, HARDCOPY, MAX, MEGACORE, NIOS, QUARTUS and STRATIX are Reg. U.S. Pat.
& Tm. Off. and/or trademarks of Altera Corporation in the U.S. and other countries. All other trademarks and service marks are the property of their respective
holders as described at www.altera.com/common/legal.html. Altera warrants performance of its semiconductor products to current specifications in accordance
with Altera’s standard warranty, but reserves the right to make changes to any products and services at any time without notice. Altera assumes no responsibility or
liability arising out of the application or use of any information, product, or service described herein except as expressly agreed to in writing by Altera. Altera
customers are advised to obtain the latest version of device specifications before relying on any published information and before placing orders for products or
services.
エンベデッド・デザイン・ハンドブック
2011 年 7 月 Altera Corporation
目次
章の改訂日付 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
第 1 章 . 初めての設計者向けのガイド
初めての設計者向けのガイドについて . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1‒1
FPGA およびソフト・コアのプロセッサ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1‒1
エンべデッド・システム・デザイン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1‒2
FPGA のハードウェア・デザイン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1‒4
FPGA デザインとハードウェアの接続 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1‒4
SOPC Builder システムへの信号の接続 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1‒5
FPGA ベースのデザインの制約 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1‒5
SOPC Builder を使用するハードウェア・デザイン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1‒6
SOPC Builder のデザイン複製 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1‒7
FPGA デザインのカスタマイズおよびアクセラレーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1‒8
Nios II ソフトウェアのデザイン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1‒10
Nios II のツールの概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1‒10
NiosII ソフトウェアのビルド・ツール・フロー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1‒12
Nios II IDE フロー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1‒13
ソフトウェアのデバッグ・オプション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1‒13
ボード・デザインの検討事項 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1‒16
コンフィギュレーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1‒16
ブート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1‒17
追加のエンベデッド・デザインの検討事項 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1‒18
エンベデッド・デザイン・リソース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1‒19
アルテラのエンベデッド・サポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1‒19
アルテラ・エンベデッドのトレーニング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1‒19
アルテラ・エンベデッドの資料 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1‒19
サードパーティの IP（Intellectual Property） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1‒20
アルテラ・エンベデッドの用語集 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1‒20
まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1‒22
改訂履歴 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1‒22
第 2 章 . Nios II ソフトウェアの開発
はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒1
ソフトウェア開発サイクル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒2
アルテラの SOPC ソリューション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒2
Nios II ソフトウェア開発プロセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒4
ソフトウェア・プロジェクトの仕組み . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒5
ソフトウェア・ツールのバックグランド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒6
開発フローのガイドライン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒7
Nios II ソフトウェア・ビルド・ツール・フロー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒7
Eclipse 用の Nios II ソフトウェア・ビルド・ツール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒8
Nios II ソフトウェア・ビルド・ツールのコマンドライン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒8
BSP プロジェクトおよびアプリケーション・プロジェクトのコンフィギュレーション . . . . . . . . 2‒8
ソフトウェアのデザイン例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒9
オペレーティング・システムの選択（HAL 対 MicroC/OS-II RTOS）. . . . . . . . . . . . . . . . . . . . . . . 2‒10
BSP プロジェクトのコンフィギュレーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒10
Nios II BSP エディタとの Tcl スクリプトの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒16
アプリケーション・プロジェクトのコンフィギュレーション . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒18
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
iv
目次
Makefile および Eclipse 用の Nios II ソフトウェア・ビルド・ツール . . . . . . . . . . . . . . . . . . . . . 2‒19
Eclipse 用の Nios II ソフトウェア・ビルド・ツールでのソフトウェアの構築および実行 . . . 2‒20
ソフトウェア・プロジェクトのコヒーレンシの確保 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒21
ハードウェア・アブストラクション・レイヤ（HAL）を使用した開発 . . . . . . . . . . . . . . . . . . . . . . . . 2‒26
HAL の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒26
HAL のコンフィギュレーション・オプション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒26
HAL ベースのアプリケーションでのシステムのスタートアップ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒27
システムの初期化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒27
crt0 の初期化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒28
HAL の初期化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒29
HAL ペリフェラル・サービス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒31
タイマ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒31
キャラクタ・モード・デバイス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒34
フラッシュ・メモリ・デバイス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒36
ダイレクト・メモリ・アクセス・デバイス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒38
ファイルおよびファイル・システム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒41
イーサネット・デバイス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒42
非サポートのデバイス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒43
Nios II プロセッサを使用したメモリへのアクセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒43
一般的な C/C++ アプリケーションの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒43
ペリフェラルへのアクセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒44
非キャッシュ・メモリの共有 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒44
キャッシュ性能の利点を使用したメモリの共有 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒45
例外の処理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒46
例外ハンドラの変更 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒47
アプリケーションの最適化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒47
パフォーマンス調整のバックグランド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒48
システム・プロセス処理タスクの迅速化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒48
問題の解析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒48
アプリケーションのアクセラレーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒49
割り込みサービス・ルーチンのアクセラレーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒51
問題の解析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒51
割り込みサービス・ルーチンのアクセラレーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒51
コード・サイズの低減 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒52
問題の解析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒52
コード・フットプリントの低減 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒52
アプリケーションのリンク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒53
バックグランド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒54
リンカ・セクションおよびアプリケーションのコンフィギュレーション . . . . . . . . . . . . . . . . . . . . 2‒54
HAL のリンク動作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒54
デフォルトの BSP リンク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒54
ユーザー制御の BSP リンク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒55
アプリケーション・ブート・ロードおよびプログラミング・システム・メモリ . . . . . . . . . . . . . . . . 2‒55
デフォルト BSP のブート・ロード・コンフィギュレーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒55
ブート・コンフィギュレーション・オプション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒56
フラッシュ・メモリからのブートおよび実行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒56
フラッシュ・メモリからのブートおよび揮発性メモリからの実行 . . . . . . . . . . . . . . . . . . . . . . . 2‒57
揮発性メモリからのブートおよび実行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒58
アルテラの EPCS メモリからのブートおよび揮発性メモリからの実行 . . . . . . . . . . . . . . . . . . . . 2‒59
FPGA メモリからのブートおよび実行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒59
システム・メモリ・イメージの生成およびプログラミング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒60
Nios II ソフトウェア・ビルド・ツールのコマンドラインを使用した FPGA メモリのプログラミン
グ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒60
Eclipse 用の Nios II ソフトウェア・ビルド・ツールのフラッシュ・メモリのコンフィギュレー
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
目次
v
ションおよびプログラミング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒61
コマンドラインからのフラッシュ・メモリのコンフィギュレーションおよびプログラミング . . . .
2‒61
まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒63
改訂履歴 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2‒64
第 3 章 . Nios II デザインのデバッグ
デバッガ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3‒1
NiosII ソフトウェア開発ツール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3‒1
Nios II のシステム ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3‒2
プロジェクト・テンプレート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3‒3
コンフィギュレーション・オプション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3‒4
Nios II GDB コンソールおよび GDB コマンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3‒7
Nios II のコンソール・ビューおよび stdio ライブラリ・ファンクション . . . . . . . . . . . . . . . . . . 3‒8
Nios II ソフトウェア・ビルド・ツールを使用して作成されたプロジェクトのインポート . . . . 3‒8
複数のプロセッサ・デザインでのプロセッサ・インスタンスの選択 . . . . . . . . . . . . . . . . . . . . . . 3‒9
FS2 コンソール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3‒10
SignalTap II エンベデッド・ロジック・アナライザ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3‒11
Lauterbach の Trace32 デバッガおよび PowerTrace ハードウェア . . . . . . . . . . . . . . . . . . . . . . . . . 3‒11
Insight デバッガおよびデータ・ディスプレイ・デバッガ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3‒12
ランタイム解析のデバッグ手法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3‒12
ソフトウェアのプロファイリング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3‒12
ウォッチポイント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3‒13
スタック・オーバーフロー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3‒13
ハードウェア・アブストラクション・レイヤ（HAL） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3‒14
ブレークポイント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3‒14
デバッガ・ステップおよび No 最適化の使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3‒15
まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3‒16
参考資料 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3‒16
改訂履歴 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3‒17
第 4 章 . Nios II コマンド・ライン・ツール
はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4‒1
ボードの立ち上げと診断ためのアルテラのコマンド・ライン・ツール . . . . . . . . . . . . . . . . . . . . . . . . . 4‒1
jtagconfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4‒1
jtagconfig 使用方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4‒2
nios2-configure -sof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4‒3
nios2-configure-sof 使用する方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4‒3
system-console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4‒3
ハードウェア開発のためのアルテラのコマンド・ライン・ツール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4‒4
quartus_cmd and sopc_builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4‒4
フラッシュ・プログラミング用のアルテラのコマンド・ライン・ツール . . . . . . . . . . . . . . . . . . . . . . . 4‒6
nios2-flash-programmer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4‒6
nios2-flash-programmer の使用例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4‒6
elf2flash, bin2flash, および sof2flash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4‒7
bin2flash の使用例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4‒9
ソフトウェア開発およびデバッグするためのアルテラのコマンド・ライン・ツール . . . . . . . . . . . . . 4‒9
nios2-terminal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4‒9
nios2-download . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4‒9
nios2-download の使用例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4‒9
nios2-stackreport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4‒10
nios2-stackreport の使用例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4‒10
validate_zip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4‒10
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
vi
目次
validate_zip の使用例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-ide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Linux ラッパ・スクリプト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Windows ラッパ・スクリプト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-gdb-server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-gdb-server の使用例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-debug の使用例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
アルテラ Nios II ソフトウェア・ビールドのツール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BSP に関するツール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
アプリケーションに関するツール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GNU コマンド・ラインのツール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-elf-addr2line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-elf-addr2line の使用例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-elf-gdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-elf-readelf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-elf-readelf の使用例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-elf-ar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-elf-ar の使用例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
リンカ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
リンカの使用例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-elf-size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-elf-size の使用例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-elf-strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-elf-strings の使用例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-elf-strip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-elf-strip の使用例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-elf-strip Usage Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-elf-gdbtui . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-elf-gprof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-elf-insight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-elf-gcc and g++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
コマンドのコンパイル の使用例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
より複雑なコンパイルの例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-elf-c++filt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-elf-c++filt の使用例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
より複雑な nios2-elf-c++filt の例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-elf-nm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-elf-nm の使用例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
より複雑な nios2-elf-nm の例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-elf-objcopy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-elf-objcopy の使用例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-elf-objdump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-elf-objdump 使用方法の説明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nios2-elf-ranlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
改訂履歴 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4‒10
4‒11
4‒11
4‒11
4‒11
4‒12
4‒13
4‒13
4‒13
4‒14
4‒14
4‒15
4‒15
4‒15
4‒15
4‒15
4‒16
4‒16
4‒16
4‒17
4‒17
4‒17
4‒17
4‒18
4‒18
4‒18
4‒18
4‒18
4‒18
4‒19
4‒19
4‒19
4‒19
4‒19
4‒19
4‒20
4‒20
4‒20
4‒20
4‒20
4‒20
4‒21
4‒21
4‒21
4‒22
4‒22
第 5 章 . Nios II C2H コンパイラの結果の最適化
前提条件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
コストおよび性能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C2H 最適化プロセスの概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
使用法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
反復最適化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
コストとパフォーマンス目標の達成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
エンベデッド・デザイン・ハンドブック
2011 年７月
5‒1
5‒1
5‒2
5‒2
5‒3
5‒3
Altera Corporation
目次
vii
C2H の結果に影響する要因 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒3
メモリのアクセスおよび変数 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒4
演算および論理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒5
ステートメント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒6
コントロール・フロー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒7
If ステートメント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒7
ループ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒8
サブファンクションの呼び出し . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒8
リソース共有 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒9
データ依存 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒9
メモリ・アーキテクチャ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒10
DRAM アーキテクチャ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒11
効率指標 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒12
Cycles Per Loop Iteration (CPLI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒12
FPGA リソースの使用率 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒12
Avalon-MM マスタ・ポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒13
エンベデッド乗算器数 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒13
エンベデッド・メモリ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒14
データ・ツループット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒14
最適化手法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒14
パイプライン化の計算 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒14
メモリ効率の増加 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒15
ワイド・メモリ・アクセスの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒16
メモリ・アーキテクチャのセグメンテーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒18
ローカル化されるデータの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒19
データ依存を減らす . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒20
__restrict__ の使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒20
ロジック使用率を減らす . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒24
"while" の代わりに "do-while" を使用する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒24
定数の使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒25
ループがロール・アップの状態で置く . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒27
順次アレイをアクセスする ++ の使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒28
過剰なポインタの参照の回避 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒29
乗算の回避 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒29
任意の除算を回避する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒30
マスクの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒31
多次元アレイの 2 の乗数の使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒31
狭いローカル変数の使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒32
メモリ接続の最適化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒32
メモリ・スレーブ・ポートへの不要な接続の削除 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒32
#pragma の使用で Avalon-MM インターコネクトの削減 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒33
Nios II プロセッサに不要なメモリの接続の削除 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒35
周波数対レイテンシの最適化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒35
条件レイテンシの改善 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒36
条件周波数の改善 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒37
スループットの改善 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒38
短いネストされたループの回避 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒38
イン・プレース計算の削除 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒39
アレイの交換 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒41
ポーリングされるアクセラレータの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒42
割り込みベースのアクセラレータの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒43
用語集 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒43
改訂履歴 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5‒45
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
viii
目次
第 6 章 . SOPC Builder デザインの 最適化
ハードウェア・アーキテクチャの選択 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒1
バス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒2
フル・クロスバー・スイッチ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒2
部分的なクロスバー・スイッチ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒3
ストリミング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒5
ダイナミック・バス・サイジング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒7
並行処理の理解 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒7
複数のマスタの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒7
個別のデータパスの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒8
DMA エンジンの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒9
複数のマスタまたはスレーブ・ポートを含む . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒10
個別のサブシステムの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒11
転送スループットの増加 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒12
パイプライン化された転送の使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒13
最大保留リード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒13
保留リードの最大値の選択 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒13
保留リードの最大値の過大評価または過小評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒13
パイプライン化されたリード・マスタ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒14
要件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒14
スループットの向上 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒14
パイプライン化されたリード・マスタの例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒16
アービトレーション・シェアおよびバースト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒17
アービトレーション・シェアおよびバーストの違い . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒17
インタフェース・タイプの選択 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒18
バースト・マスタの例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒20
増加されるシステム周波数 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒21
パイプライン・ブリッジの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒21
マスタ・ツー・スレーブのパイプライン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒21
スレーブ・ツー・マスタのパイプライン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒22
waitrequest のパイプライン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒23
クロック・クロッシング・ブリッジの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒23
コンポーネント周波数の増加 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒24
優先順位の低い周波数の低減 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒24
ブリッジを使用した結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒24
レイテンシの増加 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒24
制限された並列性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒26
アドレス・スペース変換 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒28
アドレスのシフト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒28
アドレス・コヒーレンシ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒29
システム・インタコネクト・ロジックの最小化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒30
一意のアドレス・ビットの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒30
専用のマスタとスレーブの接続の作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒31
不要な接続の削除 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒31
ロジックの使用率の低減 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒32
コンポーネントを統合することによるアービトレーション・ロジックの最小化 . . . . . . . . . . . . . 6‒32
ロジック統合のトレードオフ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒32
複合コンポーネントの例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒32
システム・インタコネクト・ファブリック・ロジックを最小化するブリッジの使用 . . . . . . . . . 6‒34
SOPC Builder の速度の 最適化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒34
並列性の低減 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒35
アダプタ・ロジックを最小限に抑えるブリッジの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒36
ブリッジの効果的な配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒37
コンパクトなシステム例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6‒38
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
目次
ix
電力の使用率の削減 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
非クリティカル・ロジックのクロック速度の減少 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
クロック・クロッシング・ブリッジ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
クロック・クロッシング・アダプタ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
トグル・レートの最小化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
コンポーネントの境界のレジスタ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
クロックのイネーブル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ブリッジの挿入 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ロジックのディセーブル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ソフトウェア制御のスリープ・モード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ハードウェア制御のスリープ・モード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ドライブされる waitrequest のスリープ・モード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
改訂履歴 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6‒39
6‒40
6‒40
6‒41
6‒42
6‒43
6‒43
6‒44
6‒44
6‒44
6‒45
6‒45
6‒46
第 7 章 . メモリ・システム・デザイン
概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒1
揮発性メモリ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒1
不揮発性メモリ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒1
オンチップ・メモリ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒2
利点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒2
欠点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒2
ベスト・アプリケーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒3
キャッシュ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒3
密結合メモリ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒3
ルック・アップ・テーブル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒3
FIFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒3
悪いアプリケーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒3
オンチップ・メモリのタイプ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒4
ベスト・プラクティス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒4
外部 SRAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒4
利点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒4
欠点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒5
ベスト・アプリケーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒5
悪いアプリケーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒5
外部 SRAM タイプ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒5
ベスト・プラクティス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒6
フラッシュ・メモリ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒6
利点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒6
欠点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒7
一般的なアプリケーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒7
悪いアプリケーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒8
フラッシュ・タイプ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒8
SDRAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒9
利点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒9
欠点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒10
ベスト・アプリケーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒10
悪いアプリケーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒10
SDRAM タイプ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒11
アルテラからの使用可能な SDRAM コントローラのタイプ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒11
ベスト・プラクティス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒12
ハーフ・レート・モード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒12
フール・レート・モード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒12
シーケンシャル・アクセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒13
バースト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7‒13
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
x
目次
SDRAM の最小周波数 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SDRAM のデバイス・スピード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
メモリの最適化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
重要なメモリ接続の分離 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
マスタとスレーブのデータ幅と一致 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
並列性を利用するために別々のメモリを使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Nios II 命令のマスタ・アドレス · スペースを理解 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
テスト・メモリ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ケース・スタディ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
アプリケーションの説明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
初期メモリ・パーティショニング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
最適化されたメモリのパーティショニング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
入力バッファ用の外部 SRAM を追加 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ビデオ · ライン · バッファ用のオンチップ · メモリを追加 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
参考資料 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
改訂履歴 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
........................................................................................
7‒13
7‒14
7‒14
7‒14
7‒14
7‒15
7‒15
7‒15
7‒15
7‒16
7‒17
7‒18
7‒18
7‒19
7‒20
7‒20
7‒20
第 8 章 . ハードウェア・アクセラレーションおよびコプロセッシング
ハードウェア・アクセラレーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8‒1
CRC（Cyclic Redundancy Checking）のアクセラレーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8‒1
I/O 帯域幅のマッチング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8‒3
パイプライン化するアルゴリズム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8‒3
Nios II カスタム命令の作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8‒4
C2H コンパイラの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8‒8
コプロセッシング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8‒9
マルチコア・デザインの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8‒10
前処理および後処理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8‒12
ステート・マシンの交換 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8‒13
低速ステート・マシン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8‒14
高速ステート・マシン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8‒15
細分化ステート・マシン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8‒15
改訂履歴 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8‒15
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8‒15
第 9 章 . 検証およびボード立ち上げ
はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9‒1
検証方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9‒1
前提条件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9‒1
FS2 コンソール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9‒2
SOPC Builder のテスト統合 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9‒3
FS2 コンソールの機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9‒3
システム・コンソール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9‒6
SignalTap II エンベデッド・ロジック・アナライザ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9‒8
外部インスツルメンテーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9‒8
SignalProbe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9‒9
ロジック・アナライザ・インタフェース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9‒9
スティミュラスの生成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9‒10
ボード立ち上げ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9‒11
ペリフェラルのテスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9‒11
データ・トレースの障害 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9‒11
アドレス・トレースの障害 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9‒12
デバイスの分離 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9‒13
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
目次
xi
JTAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ボード・テスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
最小限のテスト・システム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
システム検証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
検証を考慮したデザイン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
検証の高速化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ハードウェアを確認するためのソフトウェアの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
環境テスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
改訂履歴 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9‒13
9‒15
9‒15
9‒18
9‒18
9‒18
9‒20
9‒22
9‒22
第 10 章 . アルテラ FPGA への外部プロセッサの接続
コンフィギュレーション・オプション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10‒2
RapidIO インタフェース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10‒5
PCI Express インタフェース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10‒7
PCI インタフェース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10‒8
PCI Lite インタフェース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10‒9
SPI（シリアル・プロトコル・インタフェース）. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10‒10
カスタム・ブリッジ・インタフェース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10‒11
結論 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10‒13
改訂履歴 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10‒13
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10‒13
第 11 章 . Avalon-MM のバイト・オーダリングの考慮事項
エンディアンネス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11‒1
ハードウェア・エンディアンネス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11‒1
ソフトウェア・エンディアンネス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11‒2
Avalon-MM インタフェースの順序 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11‒2
ダイナミック・バス・サイジングの DMA 例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11‒3
Nios II プロセッサのデータ・アクセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11‒6
プロセッサ · マスタの Avalon-MM 準拠への適応 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11‒8
PowerPC のバス・バイト・オーダリング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11‒10
ARM BE-32 のバス・バイト・オーダリング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11‒11
ARM BE-8 のバス・バイト・オーダリング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11‒12
他のプロセッサのビットとバイト・オーダリング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11‒12
演算バイトのリ・オーダリング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11‒13
システム・ワイドのデザインの推奨事項 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11‒15
システム・ワイドの演算バイト・オーダリング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11‒15
ソフトウェアにおけるシステム・ワイドの演算バイトのリ・オーダリング . . . . . . . . . . . . . . . . . 11‒16
改訂履歴 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11‒17
アルテラへのお問い合わせ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Info‒1
表記規則 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Info‒1
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
xii
エンベデッド・デザイン・ハンドブック
目次
2011 年７月
Altera Corporation
章の改訂日付
本書では、エンベデッド・デザイン・ハンドブックの各章は、次の日付に改訂され
ました。章が別々に入手可能である場合には、部品番号が記載されています。
第1章.
初めての設計者向けのガイド
改訂日付 :
2011 年 7 月
部品番号 :
ED51001-2.3
第2章.
Nios II ソフトウェアの開発
改訂日付 :
2011 年 7 月
部品番号 :
ED51002-1.4
第3章.
Nios II デザインのデバッグ
改訂日付 :
2009 年 12 月
部品番号 :
ED51003-1.3
第4章 .
Nios II コマンド・ライン・ツール
改訂日付 :
2011 年 7 月
部品番号 :
ED51004-2.2
第5章.
Nios II C2H コンパイラの結果の最適化
改訂日付 :
2011 年 7 月
部品番号 :
ED51005-1.2
第6章.
SOPC Builder デザインの 最適化
改訂日付 :
2011 年 7 月
部品番号 :
ED51007-1.2
第7章.
メモリ・システム・デザイン
改訂日付 :
2010 年 2 月
部品番号 :
ED51008-1.2
第8章.
ハードウェア・アクセラレーションおよびコプロセッシング
改訂日付 :
2011 年 7 月
部品番号 :
ED51006-1.2
第9章.
検証およびボード立ち上げ
改訂日付 :
2011 年 7 月
部品番号 :
ED51010-1.3
第 10 章 .
アルテラ FPGA への外部プロセッサの接続
改訂日付 :
2011 年 7 月
部品番号 :
ED51011-1.1
第 11 章 .
Avalon-MM のバイト・オーダリングの考慮事項
改訂日付 :
2011 年 7 月
部品番号 :
ED51012-1.1
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
xiv
エンベデッド・デザイン・ハンドブック
章の改訂日付
2011 年 7 月 Altera Corporation
1. 初めての設計者向けのガイド
July 2011
ED51001-2.3
ED51001-2.3
アルテラは、エンベデッド・システム用のハードウェアおよびソフトウェアの開発
のために、さまざまなツールを提供しています。このハンドブックでは、ツールの
最も効果的な使用方法を説明することによって、それらのツールの一次資料を補完
します。Eclipse 用のソフトウェア・ビルド・ツールおよび SOPC Builder などのアル
テラが提供するツールを使用するエンベデッド・システムを開発、デバッグ、およ
び最適化するためのデザイン・スタイルおよびデザイン手法が推奨されます。この
ハンドブックは、アルテラのエンベデッド・ソリューションの新しいユーザーにコ
ンセプトを紹介し、経験豊富なユーザーのデザイン効率の向上を支援します。
このハンドブックは、包括的なリファレンス・ガイドではありません。一般的なリ
ファレンスおよび詳しい情報については、このハンドブックで引用される一次資料
を参照してください。
このハンドブックの第 1 章は、初めての設計者のために、Altera® エンベデッド開発
のプロセスおよび手順を説明します。その他の章では、アルテラ FPGA でのエンベ
デッド開発における特定の側面に焦点を当てます。
このハンドブックは、Qsys システムの統合ツールに関する情報は提供しません。
初めての設計者向けのガイドについて
この章は、ハードウェアおよびソフトウェアの開発のためのアルテラのエンベデッ
ド開発ツールを初めて使用するユーザーを対象としています。この章では、デザイ
ン・フローおよび開発ツール・インタラクションに関する情報を提供し、Nios® II プ
ロセッサ・フローおよび標準的なディスクリート・マイクロコントローラのデザイ
ン・フローの間の違いを説明します。
しかし、この章は、Nios II Processor Reference Handbook、Nios II Software Developer’s
Handbook、SOPC Builder User Guide、Embedded Peripherals User Guide、および Nios II Flash
Programmer User Guide などの一次資料と置き換わるものではありません。
FPGA およびソフト・コアのプロセッサ
FPGA は、多くの柔軟性のオプションを提供すると同時に、完全なマイクロプロセッ
サとしての機能のロジックを実装することができます。
ディスクリート・マイクロプロセッサおよび FPGA の間の重要な違いは、FPGA がパ
ワー・アップの時にロジックを含まないということです。Nios II ベースのシステム
でソフトウェアを動作させる前に、ユーザーは Nios II プロセッサを含むハードウェ
ア・デザインを使用して FPGA をコンフィギュレーションする必要があります。
FPGA をコンフィギュレーションするとは、特定のロジック・デザインを使用して
FPGA を電子的にプログラムするということです。Nios II プロセッサは、ソフト・コ
ア・プロセッサです。これは、デザインの他の要求に応じて、FPGA 上のどこにでも
配置することができます。それぞれ柔軟性に富んだ機能を持つプロセッサの 3 つの
異なるサイズが使用可能です。
© 2011 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, HARDCOPY, MAX, MEGACORE, NIOS, QUARTUS and STRATIX are Reg. U.S. Pat. & Tm. Off.
and/or trademarks of Altera Corporation in the U.S. and other countries. All other trademarks and service marks are the property of their respective holders as described at
www.altera.com/common/legal.html. Altera warrants performance of its semiconductor products to current specifications in accordance with Altera’s standard warranty, but
reserves the right to make changes to any products and services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Altera. Altera customers are advised to obtain the latest version of device
specifications before relying on any published information and before placing orders for products or services.
エンベデッド・デザイン・ハンドブック
2011 年７月
Subscribe
1‒2
第 1 章 : 初めての設計者向けのガイド
エンべデッド・システム・デザイン
ディスクリート・マイクロプロセッサ・ベースのシステムとして動作させるために
FPGA ベースのエンベデッド・システムをイネーブルするには、システムに次の要素
を含める必要があります。
■
FPGA のコンフィギュレーション、ハードウェアおよびソフトウェアのデバッグを
サポートする JTAG インタフェース
■
パワー・アップの FPGA のコンフィギュレーション・メカニズム
デザインがこれらの機能を持っている場合、デザインの調整は、FPGA にロードされ
た事前テスト済みハードウェア・デザインから開始することができます。また、
FPGA の使用は、問題の解決または新しい機能の追加といったデザインの修正を迅速
に行うことを可能にします。システムの JTAG インタフェースを使用して FPGA をリ
コンフィギュレーションすることによって、これらの新しいハードウェア・デザイ
ンを簡単にテストすることができます。
JTAG インタフェースは、ハードウェアおよびソフトウェア開発をサポートします。
JTAG インタフェースを使用して、以下のタスクを実行することができます。
■
FPGA のコンフィギュレーション
■
ソフトウェアのダウンロードおよびデバッグ
■
UART のようなインタフェースを経由する FPGA 使用の通信（JTAG UART）
■
ハードウェアのデバッグ（SignalTap® II エンベデッド・ロジック・アナライザを使
用）
■
フラッシュ・メモリのプログラム
Nios II プロセッサ・ベースのデザインを使用する FPGA のコンフィギュレーションの
後、ソフトウェア開発フローはディスクリート・マイクロコントローラのデザイン
に似ています。
エンべデッド・システム・デザイン
アルテラの FPGA 上でのエンベデッド・システムのデザインの学習を開始する場合、
読者がハードウェア設計者であるかソフトウェア設計者であるかに応じて、Nios II
Hardware Development Tutorial を読んでください。
「Nios II システム開発フロー」の項
は、アルテラのエンベデッド・ハードウェアおよびソフトウェアの開発ツールを使
用するシステム・デザインへのアプローチ方法を決める上で特に有益です。アルテ
ラは、初めてのデザイン・プロジェクトを開始する前に、このチュートリアルを読
むことを推奨します。このチュートリアルでは、Nios II プロセッサ・ベースのシス
テムを開発するためのハードウェアおよびソフトウェアの基本的なフローを説明し
ています。
FPGA を使用するデザインは、ディスクリート・システム・コンポーネント、ソフト
ウェア、および FPGA ベースのハードウェアにそれぞれいくつかの機能を実装する柔
軟性を与えます。この柔軟性は、デザイン・プロセスをより複雑にします。この複
雑さを取り扱う上では、SOPC Builder のシステム・デザイン・ツールが役立ちます。
ソフト・コア・プロセッサがアプリケーションの必要性に見合わないと判断する場
合でも、SOPC Builder は、システム内でペリフェラル拡張またはプロセッサ・オフ
ロードのメカニズムを提供するという重要な役割を担います。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 1 章 : 初めての設計者向けのガイド
エンべデッド・システム・デザイン
1‒3
図 1–1 に、ハードウェアおよびソフトウェア開発の両方を含む Nios II システムのデ
ザイン・フロー全体を示します。この図は、実際よりもはるかに簡略化されていま
す。Nios II システムを生成するためのアルテラのツールの正しい使用方法は多数あ
ります。
図 1‒1. 一般的な Nios II のシステム・デザイン・フロー
System Concept
Nios II
Cores
and
Standard
Components
Custom
Instruction
and
Peripheral
Logic
Analyze System
Requirements
Define and Generate
System in SOPC Builder
Hardware Flow:
Integrate and compile
Quartus II project (1)
Software Flow:
Develop and build
Nios II software (2)
Download FPGA Design
to Target Board
Software Flow:
Test and Debug
Nios II Software (3)
Yes
Yes
Hardware
Meets
Spec?
Software
Meets
Spec?
No
No
System Complete
図 1–1 の注：
(1) ハードウェア・フローについて詳しくは、図 1–2 を参照してください。
(2) ソフトウェア開発フローについて詳しくは、図 1–4 を参照してください。
(3) ソフトウェアのデバッグ・フローについて詳しくは、図 1–5 を参照してください。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
1‒4
第 1 章 : 初めての設計者向けのガイド
エンべデッド・システム・デザイン
FPGA のハードウェア・デザイン
図 1–2 に、Nios II システムのための標準的な FPGA のハードウェア・デザイン・プロ
セスを示します。
図 1‒2. Nios II システムのハードウェア・デザイン・フロー
Start
Custom
Hardware
Modules
Integrate SOPC Builder System
with Quartus II Project
Assign Pin Locations,
Timing Requirements,
and Other Design Constraints
Compile Hardware
for Target
Ready to Download
FPGA ベースのデザインを SOPC Builder で開発しますが、ユーザーは他のツールで以
下のタスクを実行する必要があります。
■
FPGA ベースのデザインからボード・レベル・デザインへの信号の接続
■
SOPC Builder システムから FPGA ロジック内の信号への信号の接続
■
デザインの制約
FPGA デザインとハードウェアの接続
FPGA ベースのデザインとボード・レベル・デザインを接続するには、以下の 2 つの
タスクを実行します。
1. FPGA デザインのトップ・レベルを識別すること。
2. アルテラ・ウェブサイトの Altera I/O Management, Board Development Support, and
Signal Integrity Analysis Resource Center のページで説明されている任意の方法を使
用して、FPGA デザインのトップ・レベルにある信号を FPGA 上のピンに割り当て
ること。
1
FPGA ベースのデザインのトップ・レベルは、SOPC Builder である可能性があります。
しかし、FPGA は追加のデザイン・ロジックを含むことができます。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 1 章 : 初めての設計者向けのガイド
エンべデッド・システム・デザイン
1‒5
SOPC Builder システムへの信号の接続
ユーザーは、SOPC Builder システム用にクロックおよびリセット・ピンを定義する必
要があります。また、適切なシステム動作に必要とされる各 I/O 信号も定義する必要
があります。図 1–3 に、Nios II プロセッサを含む SOPC Builder システムのトップ・レ
ベル・ブロック図を示します。トップ・レベルの図で std_1s40 のラベルが付けられ
た大きなシンボルは、SOPC Builder システムであることを表します。この図の中でフ
ラグの形をしたピン・シンボルは、オフチップ（オフ FPGA）接続であることを表し
ます。
f FPGA ピンの接続について詳しくは、アルテラ・ウェブサイトの Altera I/O Management,
Board Development Support, and Signal Integrity Analysis Resource Center のページを参照し
てください。
図 1‒3. トップ・レベル・ブロック図
FPGA ベースのデザインの制約
デザインがタイミングおよび他の要求を満たすようにするためには、ユーザーは
Quartus® II ソフトウェアで提供されるツールを使用して、またはサードパーティの
EDA プロバイダによって、デザインを明示的に制約する必要があります。Quartus II ソ
フトウェアは、デザイン・コンパイルの間、アルテラの可能な最良の結果を達成す
るために、ユーザーの制約情報を使用します。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
1‒6
第 1 章 : 初めての設計者向けのガイド
エンべデッド・システム・デザイン
f それらが提供するアルテラのサードパーティ EDA のパートナーおよびツールは、ア
ルテラ・ウェブサイトの Third-Party EDA Software のページに一覧で示されています。
SOPC Builder を使用するハードウェア・デザイン
SOPC Builder は、FPGA 上で複雑なハードウェア・システムを構築するタスクを簡略
化します。SOPC Builder は、グラフィカル・ユーザー・インタフェース（GUI）を使
用して、システムのトポロジーを示すことを可能にして、その後、そのシステム用
にハードウェア記述言語（HDL）ファイルを生成することを可能にします。Quartus II
ソフトウェアは、SRAM オブジェクト・ファイル（.sof）を生成するために HDL ファ
イルをコンパイルします。
f SOPC Builder について詳しくは、SOPC Builder User Guide を参照してください。
SOPC Builder は、各 Nios II プロセッサ用のキャッシュ、デバッグ、およびカスタム機
能のプロセッサ・コアのタイプとレベルを選択することを可能にします。デザイン
は、メモリ、PLL、DSP 機能、および高速トランシーバなどのオンチップ・リソース
を使用することができます。SOPC Builder を使用して、デザイン用の最適なプロセッ
サを構築することができます。
SOPC Builder を使用するシステム構築の後、トップ・レベル・デザインを完成させる
上で要求されるカスタム・ロジックを追加した後に、Quartus II ソフトウェアを使用
してピン・アサインメントを生成する必要があります。FPGA の外部ピンは柔軟性に
富む機能を持っており、ピンの範囲はクロック、コントロール信号、および I/O 信号
に接続する上で使用可能です。
f ピン・アサインメントの生成方法について詳しくは、Quartus II Help および Volume 2:
Design Implementation and Optimization of the Quartus II Handbook の I/O Management の章
を参照してください。
アルテラは、プリテスト済みの小さなプロジェクトからデザインを開始し、インク
リメンタルに構築することを推奨します。アルテラ・ウェブサイトの Nios II
Embedded Processor Design Examples のウェブ・ページにある多くの SOPC Builder デザ
イン例のうちの使用可能な 1 つのデザイン例を使用するか、または Nios II Hardware
Development Tutorial のデザイン例を使用して開始してください。
SOPC Builder は、コンポーネント・エディタを使用してユーザー独自のカスタム・コ
ンポーネントを生成することを可能にします。コンポーネント・エディタでは、
ユーザー独自のソース・ファイルのインポート、さまざまなインタフェースへの信
号の割り当て、さまざまなコンポーネントおよびパラメータ・プロパティの設定が
可能です。
カスタム・コンポーネントのデザイン前に、ユーザーは SOPC Builder で使用可能なイ
ンタフェースおよび信号のタイプを理解しておく必要があります。
1
ネイティブ・アドレッシングは推奨されていません。そのため、すべての新しいコ
ンポーネント上でスレーブ・インタフェース用のダイナミック・アドレッシングを
使用する必要があります。ダイナミックにアドレス可能なスレーブ・ポートには、
リードおよびライト・サイクルの間にアクセスされるバイト・レンズを規定するバ
イト・イネーブルが含まれています。ダイナミックにアドレス可能なスレーブ・イ
ンタフェースは、データ切捨てまたは副作用なしで任意のデータ幅でのアクセスが
可能であるという利点があります。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 1 章 : 初めての設計者向けのガイド
エンべデッド・システム・デザイン
1‒7
f SOPC Builderで使用可能なインタフェースおよび信号タイプについて詳しくは、Avalon
Interface Specifications を参照してください。コンポーネント・エディタの使用につい
ては、SOPC Builder User Guide の章を参照してください。
1
システムに各ハードウェア・コンポーネントを追加する場合は、それをソフトウェ
アでテストします。新しいハードウェア・コンポーネントをテストするためのソフ
トウェアの開発方法が分からない場合、アルテラは、コンポーネントをテストする
ためにはソフトウェア・エンジニアと協力することを推奨します。
Nios II EDS には、<Nios II EDS install dir>\examples\software の Nios II EDS インストー
ル・ディレクトリ（nios2eds）にいくつかのソフトウェア例が含まれています。シン
プルなソフトウェア・デザイン — 最もシンプルな例 Hello World Small など — の動作
後、システムが要求する追加のインタフェースまたはカスタム・オプションをテス
トするために、このデザインに基づいて個別のシステムを構築します。アルテラは、
JTAG デバッグ・モジュール、オンチップ・メモリ・コンポーネント、および JTAG
UART コンポーネントを持つプロセッサを含むシンプルなシステムで開始することを
推奨します。また、未テストの新しいコンポーネントをインクリメンタルに追加す
るのではなく、未テストの新しい各コンポーネント用には新しいシステムを作成す
ることを推奨します。
新しい各ハードウェア・コンポーネントがそれぞれ個別のシステムで正しく機能す
ることを確認した後、ユーザーはシングル SOPC Builder システムに新しいコンポーネ
ントをインクリメンタルに組み合わせることができます。SOPC Builder は、コンポー
ネントの追加およびプロジェクトの簡単な再生成を可能にすることで、このデザイ
ン方法を十分にサポートします。
f 推奨されるインクリメンタル・デザイン・プロセスの実装方法について詳しくは、
Embedded Design Handbook の Verification and Board Bring-Up の章を参照してください。
SOPC Builder のデザイン複製
推奨されるデザイン・フローでは、いくつかの小さな SOPC Builder システムがそれぞ
れ、新しいハードウェアをテストするために使用する Quartus II プロジェクトおよび
ソフトウェアを持っている必要があります。SOPC Builder デザインは、以下のファイ
ルおよびフォルダを必要とします。
■
Quartus II プロジェクト・ファイル（.qpf）
■
Quartus II 設定ファイル（.qsf）
.qsf ファイルには、Quartus II プロジェクトのためのデバイス、ピン、タイミン
グ、およびコンパイル設定がすべて含まれています。
■
トップレベル・デザイン・ファイルの以下のタイプの 1 つです。
■
ブロック・デザイン・ファイル（.bdf）
■
Verilog デザイン・ファイル（.v）
■
VHDL デザイン・ファイル（.vhd）
SOPC Builder がトップレベル・デザイン・ファイルを生成する場合、ユーザーは
別のトップレベル・ファイルを保持する必要はありません。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
1‒8
第 1 章 : 初めての設計者向けのガイド
エンべデッド・システム・デザイン
1
SOPC Builder は、システム用のほとんどの HDL ファイルを生成するため、プ
ロジェクトを維持しているときはそれらを保持する必要はありません。
ユーザーは、デザインに直接追加する HDL ファイルのみを保持する必要が
あります。
f デザイン・ファイル・タイプについて詳しくは、Quartus II Help を参照して
ください。
■
SOPC Builder デザイン・ファイル（.sopc）
■
DOPC 情報ファイル（.sopcinfo）
このファイルには、SOPC Builder システムの XML の説明が含まれます。Nios II ソ
フトウェア・ビルド・ツール（SBT）を含む SOPC Builder およびダウンストリー
ム・ツールは、このファイルからユーザーのシステムに関する情報を生成しま
す。
■
ユーザーのソフトウェア・アプリケーション・ソース・ファイル
プロジェクト全体（ハードウェアおよびソフトウェア両方）を複製するには、必要
なファイルを別のディレクトリにコピーするだけです。コピー・プロセスを自動化
するためにスクリプトを作成することができます。ファイルのコピー後、ユーザー
は、Quartus II ソフトウェア、SOPC Builder、Eclipse 用の SBT、コマンド・シェル内の
SBT、または Nios II 統合開発環境（IDE）などの適切なツールで新しいプロジェクト
の修正に進むことができます。
f これらすべてのファイルについて詳しくは、SOPC Builder User Guide の Archiving SOPC
Builder Projects の章を参照してください。
FPGA デザインのカスタマイズおよびアクセラレーション
FPGA ベースのデザインは、容易にデザインを修正できて、デザインのハードウェア
およびソフトウェア実装の間の最良のバランスを判断する実験ができるという柔軟
性を提供します。ディスクリート・マイクロプロセッサ・ベースのデザイン・プロ
セスでは、ユーザーはデザインの最終段階に到達する前にプロセッサ・リソース —
例えばキャッシュ・サイズやビルトイン・ペリフェラルなど — を判断する必要があ
ります。ユーザーが最終的なプロセッサの要求を知る前に、これらのリソースを決
定せざるを得ない可能性があります。ユーザーのシステムのクリティカルなデザイ
ン・コンポーネントのいくつかまたはすべてを FPGA 内に実装する場合、最終的な製
品ニーズを明確にするためにユーザーは容易にデザインを再設計することができま
す。Nios II プロセッサを使用する場合、ユーザーのニーズに合わせてシステムを最
適化するために、プロセッサ・リソースの正しいバランスで実験することができま
す。SOPC Builder は、システム・コンポーネントの追加および修正とプロジェクトの
容易な再生成を可能にすることで、この柔軟性を容易にします。
パフォーマンスおよびリソース使用率のトレードオフで実験するには、以下のハー
ドウェアの最適化のテクニックが使用可能です。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 1 章 : 初めての設計者向けのガイド
エンべデッド・システム・デザイン
■
プロセッサ・パフォーマンス — 以下の方法で、Nios II プロセッサのパフォーマンス
を向上させることができます。
■
■
1‒9
計算効率 — 最も計算効率の良い Nios II プロセッサのコアは、アプリケーショ
ン・パフォーマンス全体を向上させる最も速い方法です。パフォーマンスの
高い順に並べた以下の Nios II プロセッサ・コアが使用可能です。
■
Nios II/f— 速度に最適化されます。
■
Nios II/s— オンチップ・リソースの使用に対して速度がバランスされます。
■
Nios II/e— 速度を犠牲にしてオンチップ・リソースが節約されます。
■
メモリ帯域幅 — ロー・レイテンシを使用する場合、高速メモリはプロセッサ
が命令をフェッチしてデータを移動させるのに必要とする時間を短縮します。
更に、メモリのプロセッサのアービトレーション・シェアは、他の Avalon マ
スタ・ポートがメモリのコントロールを想定できるようになる前に Nios II プ
ロセッサがさらに多くのトランザクションをメモリに実行することを可能に
することで、プロセッサのパフォーマンスを向上させます。
■
命令およびデータのキャッシュ — 命令およびデータ・キャッシュを追加する
ことは、SDRAM またはダブル・データ・レート（DDR）SDRAM などの低速メ
モリを持つシステムでは特に、Nios II プロセッサが操作を実行するのに費や
す時間を短縮する効果的な方法です。一般的に、Nios II プロセッサ用に選択
するキャッシュ・サイズが大きくなればなるほど、パフォーマンスはより向
上します。
クロック周波数 — プロセッサのクロックの速度が速くなれば、単位時間当たりに
実行される命令がより多くなります。可能な最良のパフォーマンスを得るには、
クロック・クロッシング FIFO バッファの使用を避けるために、プロセッサの実行
メモリがプロセッサと同じクロック・ドメインである必要があります。
プロセッサおよびメモリ・ペリフェラルの動作クロック周波数を高くする最も簡
単な方法の 1 つは、FIFO ブリッジの IP コアを使用してシステムのさらに低速な
ペリフェラルを分離することです。例えば、ブリッジ・ペリフェラルを使用し
て、ブリッジの 1 つのサイドでプロセッサ、メモリ、およびイーサネット・デバ
イスに接続することができます。また、パフォーマンスがブリッジの他方のサイ
ドに依存しないすべてのペリフェラルに接続することができます。
同様に、FPGA 内にシステムを実装している場合、ユーザーは最良のバランスのハー
ドウェアおよびソフトウェアのリソース使用量で実験することができます。アプリ
ケーションの一部でソフトウェアのボトルネックを見つけた場合、ユーザーは関連
するアルゴリズムのアクセラレーションを、ソフトウェアのかわりにハードウェア
にそれを実装することで考慮することができます。SOPC Builder は、ソフトウェアお
よびハードウェアの実装のバランスを使用する実験を容易にします。特定のシステ
ム・タスクのカスタム・ハードウェア・アクセラレータをデザインすることもでき
ます。
システム・パフォーマンスの問題を解決する上で、以下のアクセラレーション手法
が使用可能です。
2011 年７月
■
カスタム・ペリフェラル
■
カスタム命令
■
Nios II C からハードウェア（C2H）へのアクセラレーション・コンパイラ
Altera Corporation
エンベデッド・デザイン・ハンドブック
1‒10
第 1 章 : 初めての設計者向けのガイド
エンべデッド・システム・デザイン
ユーザーが選択するアクセラレーションの方法は、ユーザーがアクセラレーション
する動作に依存します。大量のデータ上でのストリーミングの動作をアクセラレー
ションするには、カスタム・ペリフェラルが良い解決策である可能性があります。
また、ハードウェア・インタフェース（イーサネットの実装またはシリアル・ペリ
フェラル・インタフェース（SPI）プロトコルの実装）は、カスタム・ペリフェラル
として効率的に実装される可能性があります。現在の浮動小数点のカスタム命令は、
カスタム命令を使用して標準的に最高のアクセラレーションがなされた動作タイプ
の良い例です。
ソフトウェアまたはシステム・エンジニアと協力して、潜在的なハードウェア・ア
クセラレーション・ゲインを決定する高度なアルゴリズムを解析するために C2H コ
ンパイラを使用します。任意のハードウェア・アクセラレーション手法として、
ユーザーはパフォーマンスおよびリソース消費の間のトレードオフを図る必要があ
ります。C コンパイラが最適化の高レベルを使用してコードをコンパイルする場合、
動作可能なプログラムは通常、より高速に動作しますが、最適化の低レベルでコン
パイルされた同じようなコードよりも多量のメモリを消費することがよくあります。
同様に、C2H コンパイラを使用して構成されたアクセラレータは、通常、アクセラ
レーション不可能なコードよりも速く動作しますが、それらは FPGA のリソースをよ
り多量に消費します。
f ハードウェア・アクセラレーションについて詳しくは、Embedded Design Handbook の
Hardware Acceleration and Coprocessing の章を参照してください。C2H コンパイラの使
用方法について詳しくは、Nios II C2H Compiler User Guide および Embedded Design
Handbook の Optimizing Nios II C2H Compiler Results の章を参照してください。カスタム
命令について詳しくは、Nios II Custom Instruction User Guide を参照してください。カ
スタム・ペリフェラルの作成について詳しくは、SOPC Builder User Guide の SOPC
Builder Component Development Walkthrough の章を参照してください。
Nios II ソフトウェアのデザイン
この項では、Nios II SBT 開発フローおよび Nios II IDE 開発フローを含む、Nios II EDS
で提供されるソフトウェアのデザイン・ツールを簡単に説明します。
Nios II のツールの概要
Nios II EDS は、ソフトウェア開発用として以下のツールを提供します。
■
GNU 系ツール：GNU バイナリ・ユーティリティを持つ GCC ベースのコンパイラ
f アルテラ提供のこれらのユーティリティおよび他のユーティリティについ
ては、Embedded Design Handbook の Nios II Command-Line Tools の章を参照し
てください。
■
newlib C ライブラリの Nios II プロセッサ特有のポート
■
ハードウェア・アブストラクション・レイヤ（HAL）
HAL は、基本となるハードウェアと通信するためのプログラム用のシンプルなド
ライバ・インタフェースを提供します。POSIX のようなアプリケーション・プロ
グラム・インタフェース（API）およびバーチャル・デバイス・ファイル・シス
テムなど、多くの役立つ機能を提供します。
f アルテラの HAL について詳しくは、Nios II Software Developer’s Handbook の
The Hardware Abstraction Layer の項を参照してください。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 1 章 : 初めての設計者向けのガイド
エンべデッド・システム・デザイン
■
1‒11
Nios II SBT
Nios II SBT 開発フローは、スクリプト可能な開発フローです。以下のユーザー・
インタフェースが含まれています。
■
Eclipse 用の Nios II SBT—Nios II プログラムの生成、修正、構築、実行、およびデ
バッグをサポートする GUI です。Eclipse オープン開発プラットフォームおよ
び Eclipse C/C++ 開発ツールキット（CDT）plug-in に基づいています。
■
Nios II SBT コマンドライン・インタフェース — このインタフェースから、ユー
ザーは SBT コマンド・ユーティリティを実行することができます。また、ス
クリプト（またはその他のツール）により、多くの有効な方法でコマンド・
ユーティリティを結合できます。
f Nios II SBT フローについて詳しくは、Embedded Design Handbook の
Developing Nios II Software の章を参照してください。
■
Nios II IDE—Nios II プログラムの生成、修正、構築、動作、デバックが可能な代替
GUI 環境です。Nios II IDE フローは、Nios II SBT を使用しません。このフローは、
カスタマイズされたスクリプトのサポートなしにビルド・プロセスおよびプロ
ジェクトの設定に制限されたコントロールを提供します。Nios II IDE プロジェク
トには、SBT プロジェクトとの互換性がありません。
1
ほとんどの場合、ユーザーは Nios II SBT を使用してコマンド・ラインまた
は Eclipse から新しいプロジェクトを作成する必要があります。IDE サポー
トは、以下の状況で役立ちます。
■
既存の Nios II IDE ソフトウェア・プロジェクトでの作業
■
Nios II C2H コンパイラ用の新しいプロジェクトの作成
■
FS2 コンソールでのデバッグ
f Nios II IDE について詳しくは、Nios II Software Developer’s Handbook の Appendix A. Using
the Nios II Integrated Development Environment を参照してください。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
1‒12
第 1 章 : 初めての設計者向けのガイド
エンべデッド・システム・デザイン
図 1–4 に、使用可能な Nios II ソフトウェアの開発フローを示します。
図 1‒4. Nios II ソフトウェアの開発フロー：ソフトウェアの開発
Start
Yes
Develop Software in the
SBT for Eclipse
Develop Software in the
Command Shell
Build the Application and BSP
in the SBT for Eclipse
Build the Application and BSP
in the Command Shell
SBT
Flow?
No
Altera
Hardware
Abstraction
Layer
and
Peripheral
Drivers
User C/C++
Application
Code and
Custom
Libraries
Develop Software with the
Nios II IDE
Build the System Library
and Application Projects
with the Nios II IDE
Ready to Download
アルテラは、Nios II EDS でインストールされる使用可能なソフトウェア例の 1 つを参
考にしてデザインを開始することを推奨します。単純な「Hello, World」プログラム
からネットワークおよび RTOS ベースのソフトウェアまでのこれらの例は、ユーザー
独自のソフトウェア開発プロジェクトに良い参照ポイントおよび出発点を与えます。
Hello World の小さなプログラム例は、HAL のすべての利便性を失うことなくコード・
サイズを低減させる方法を示しています。
1
アルテラは、ソフトウェアの開発およびデバッグにおいて、アルテラの開発キット
またはカスタム・プロトタイプ・ボードを使用することを推奨します。多くのペリ
フェラルおよびシステム・レベルの機能は、ソフトウェアが実際のボード上で実行
する場合のみに使用可能です。
f 詳しくは、Nios II Software Developer's Handbook を参照してください。
NiosII ソフトウェアのビルド・ツール・フロー
Nios II SBT フローでは、柔軟性が高く、ポータブルで、スクリプト可能なソフトウェ
ア・ビルド環境を提供するソフトウェア・ビルド・ツールを使用します。アルテラ
は、ここで説明するフローの使用を推奨します。SBT にはコマンドライン環境が含
まれており、好みのソフトウェアまたはシステム開発環境に容易に適合します。
Nios II SBT は、アルテラの将来の開発のための基礎です。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 1 章 : 初めての設計者向けのガイド
エンべデッド・システム・デザイン
1‒13
SBT フローは、ユーザーのシステム用に .sopcinfo ファイルを必要とします。このフ
ローには、システム用のソフトウェアを生成するための以下のステップが含まれま
す。
1. ユーザーのシステム用にボード・サポート・パッケージ（BSP）を作成します。
BSP は、ユーザーの開発システムと交信するソフトウェアのレイヤです。これ
は、makefile ベースのプロジェクトです。
2. ユーザーのアプリケーション・ソフトウェアを作成します。
a. ユーザーのコードを入力します。
b. ユーザーのコードが含まれる makefile ベースのプロジェクトを生成します。
3. デザインが完成するまで、これらのステップの 1 つまたは両方の処理が繰り返さ
れます。
f 詳しくは、Nios II EDS のリリースごとに添付されたソフトウェアのデザイン例を参照
してください。これらの例について詳しくは、次のいずれかの項を参照してくださ
い。
■
■
Nios II Software Developer’s Handbook の Getting Started with the Graphical User Interface
の章の「Getting Started」
Nios II Software Developer’s Handbook の Nios II Software Build Tools Reference の章の
「Nios II Example Design Scripts」
Nios II IDE フロー
Nios II IDE については、Nios II ソフトウェア開発のチュートリアルを参照してくださ
い。
f このチュートリアルは、Nios II IDE Help システムに含まれています。この Help システ
ムを開くには、Nios II IDE にある Help メニューの Welcome をクリックします。アル
テラ・ウェブサイトの PDF 形式の Nios II IDE Help System も参照してください。
ソフトウェアのデバッグ・オプション
Nios II EDS は、ハードウェアおよびソフトウェア・システムのデバッグに役立つ以下
のプログラムを提供します。
2011 年７月
■
Eclipse デバッガ用の Nios II SBT
■
Nios II IDE デバッガ
■
GNU デバッガへのいくつかの個別のインタフェース
■
First Silicon Solutions 社 FS2 のコンソール（Windows プラットフォームの Nios II IDE お
よびコマンドライン SBT でのみ使用可能）の Nios II 特有の実装
■
システム・デバッグ・コンソールのシステム・コンソール
Altera Corporation
エンベデッド・デザイン・ハンドブック
1‒14
第 1 章 : 初めての設計者向けのガイド
エンべデッド・システム・デザイン
図 1–5 に、Nios II ソフトウェアのデバッグに一般的に使用される 2 つのツール・フ
ローを示します。
図 1‒5. Nios II ソフトウェアの開発フロー：ソフトウェアのテスト
Start
Yes
SBT
Flow?
No
Download Software to Nios II
System with SBT for Eclipse
Download Software to Nios II
System with the Command Shell
Download Software to Nios II
System with the Nios II IDE
Run or Debug Software
from SBT for Eclipse
Run Software
from the Command Shell (1)
Run or Debug Software
from the Nios II IDE
Ready to Evaluate
図 1–5 の注：
(1) コマンドライン・プロジェクトをデバッグするには、これを Eclipse 用の SBT にインポートします。
Eclipse デバッガ用のビルトイン Nios II SBT を使用して、ソフトウェアのデバッグを
すぐに開始することができます。このデバッグ環境には、トレース、ウォッチポイ
ント、およびハードウェア・ブレークポイントなどの高度な機能が含まれています。
Nios II EDS には、GDB デバッガへの以下の 3 つのインタフェースが含まれています。
■
GDB コンソール（Eclipse および Nios II IDE 用の Nios II SBT を経由してアクセス可能）
■
スタンダード GDB クライアント（nios2-elf-gdb）
■
インサイト GDB インタフェース（GUI ベースの Tcl/Tk）
データ・ディスプレイ・デバッガ（DDD）や Curses GDB（CGDB）などの追加の GDB
インタフェースも、GDB デバッガの Nios II バージョンと共に機能します。
f GDB デバッガへのこれらのインタフェースについて詳しくは、Embedded Design
Handbook の Nios II Command-Line Tools の章および Debugging Nios II Designs の章を参
照してください。FS2 コンソールについて詳しくは、
<Nios II EDS install dir>\bin\fs2\doc ディレクトリの中の資料および Embedded Design
Handbook の Verification and Board Bring-Up の章を参照してください。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 1 章 : 初めての設計者向けのガイド
エンべデッド・システム・デザイン
1‒15
システム・コンソールは、システムまたは個別のコンポーネントのテストを実行す
るための Tcl ベースでスクリプト可能なコマンドライン・インタフェースを持つ
SOPC Builder デザイナを提供するシステム・デバッグ・コンソールです。
f システムコンソールについて詳しくは、Quartus II Handbook の volume 3 の中にある
Analyzing and Debugging Designs with the System Console の章を参照してください。オン
ライン・トレーニングは、アルテラ・ウェブサイトの Altera Training のページで使用
可能です。
サードパーティのデバッグ環境も、Lauterbach Datentechnik GmBH および First Silicon
Solution 社などのベンダから使用可能です。
コマンドラインからのソフトウェアの再構築
マイナーなソース・コードの編集後にソフトウェアを再構築する場合、GUI は必要あ
りません。ユーザーは、アプリケーションの makefile を使用して、Nios II コマンド・
シェルからプロジェクトを再構築することができます。ソフトウェアを構築または
再構築するには、次のステップに従います。
1. ユーザーの環境に応じて、以下のステップのうち 1 つを実行して Nios II コマン
ド・シェルを開きます。
■
Windows のオペレーティング・システムでは、Start メニューの Programs >
Altera > Nios II EDS をポイントして、Nios II Command Shell をクリックします。
■
Linux のオペレーティング・システムでは、コマンドシェルで以下のコマンド
のシーケンスを入力します。
cd <Nios II EDS install path>
./nios2_command_shell.sh
2. makefile があるディレクトリに変更します。開発に Nios II IDE を使用している場
合、makefile がある場所は、ソフトウェア・プロジェクト・ディレクトリの
Debug または Release サブディレクトリであることがよくあります。
3. コマンド・シェルで、以下のコマンドのうち 1 つを入力します。
make r
または
make -s r
例 1–1 に、サンプル・システム上での make コマンド動作の出力を示します。
例 1‒1. make -s コマンドからのサンプル出力
[SOPC Builder]$ make -s
Creating generated_app.mk...
Creating generated_all.mk...
Creating system.h...
Creating alt_sys_init.c...
Creating generated.sh...
Creating generated.gdb...
Creating generated.x...
Compiling src1.c...
Compiling src2.c...
Compiling src3.c...
Compiling src4.c...
Compiling src5.c...
Linking project_name.elf...
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
1‒16
第 1 章 : 初めての設計者向けのガイド
エンべデッド・システム・デザイン
1
プロジェクトに新しいファイルを追加する場合、または重要なハードウェアを変更
する場合、オリジナルのツール（Nios II SBT または Nios II IDE）を使用してプロジェ
クトを再生成します。プロジェクトを再生成するとは、変更の後にシステムの新し
いバージョン用の makefile を再生成するということです。
ボード・デザインの検討事項
ユーザーは、FPGA をコンフィギュレーションまたはプログラムする方法、および
Nios II プロセッサをブートする方法を選択する必要があります。
コンフィギュレーション
ここでは、多数の FPGA コンフィギュレーション・オプションが使用可能です。最も
一般的に使用される 2 つのオプションでは、FPGA をフラッシュ・メモリからコン
フィギュレーションします。FPGA をコンフィギュレーションするとき、1 つのオプ
ションでは CPLD および CFI フラッシュ・デバイスが使用され、もう 1 つのオプショ
ンではシリアル・フラッシュ EPCS コンフィギュレーション・デバイスが使用されま
す。Nios II の開発キットは、デフォルトの状態でこれら 2 つのコンフィギュレー
ション・オプションを使用します。
以下の場合、CPLD および CFI 対応のフラッシュ・メモリを使用する最初のオプショ
ンを選択します。
■
FPGA が大規模である
■
複数の FPGA をコンフィギュレーションする必要がある
■
ソフトウェア・ストレージ用に大容量のフラッシュ・メモリが必要である
■
複数の FPGA ハードウェア・イメージ（安全なファクトリ・イメージおよびユー
ザー・イメージ）または複数のソフトウェア・イメージがデザインに必要である
多くの場合、EPCS コンフィギュレーション・デバイスは、小さな単一の FPGA シス
テムをコンフィギュレーションするために使用されます。
1
デフォルト状態の Nios II ブート・ローダは、EPCS デバイス内の複数の FPGA イメージ
をサポートしません。
f 特定のデバイスのコンフィギュレーションについて詳しくは、アルテラ・ウェブサ
イトの Altera Devices のページにあるデバイス・ファミリ情報を参照してください。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 1 章 : 初めての設計者向けのガイド
エンべデッド・システム・デザイン
1‒17
図 1–6 に、Cyclone® II Edition の Nios II 開発キットで使用されるコンフィギュレーショ
ン・コントローラのブロック図を示します。このコントローラ・デザインは旧式の開
発キットで使用されるもので、ユーザーのデザインにとって良い出発点となります。
図 1‒6. Cyclone II デバイス用のコンフィギュレーション・コントローラ
A[23..0]
DATA[7..0]
CONTROL
MAX EPM7256AE
Configuration Controller
A[23..0]
DATA[7..0]
reset_n
Configuration
Clock
Generator
Configuration
Control
Logic
ASD0
CONTROL
Flash Parallel
to Serial Data
Converter
CS_n
External
Flash
Drive
Flash
Address and
Control-Logic
Generator
EPCS64
Configuration
Device
DATA0
DCLK
MSEL[1..0]
CONF_DONE
Reset
Distribution
Logic
Configuration
Status
Monitor
Cyclone II
EP2C35
STATUS_n
CONFIG_n
Reconfig_Request
PROTO2 RST
PROTO1 RST
ENET RST
Status LEDs
f コントローラのデザインについて詳しくは、AN346: Using the Nios II Configuration
Controller Reference Designs を参照してください。
altremote_update のメガファンクション・ベースのコンフィギュレーション
Cyclone III、Stratix® II や今後のデバイスなど、より新しいデバイスには、FPGA のコン
フィギュレーションに役立つビルトイン ALTREMOTE_UPDATE メガファンクションが
含まれています。これらの新しいデバイスでは、追加のプログラマブル・ロジック・
デバイス（PLD）はコンフィギュレーション・コントロールに必要ありません。しか
し旧式のデバイスでは、図 1–6 に示すようなコンフィギュレーション・コントロー
ラが必要です。
ALTREMOTE_UPDATE メガファンクションについて詳しくは、Remote System Upgrade
(ALTREMOTE_UPDATE) Megafunction User Guide を参照してください。アプリケーショ
ン・セレクタ例では、Cyclone III Edition の Nios II エンベデッド評価キット（NEEK）の
中のこのメガファンクションを使用します。
ブート
Nios II の多くのブート・オプションが使用可能です。以下のオプションは、最も一
般的に使用されます。
2011 年７月
■
CFI フラッシュからのブート
■
EPCS からのブート
Altera Corporation
エンベデッド・デザイン・ハンドブック
1‒18
第 1 章 : 初めての設計者向けのガイド
エンべデッド・システム・デザイン
■
オンチップ RAM からのブート
Nios II EDS に含まれるデフォルト状態のブート・ローダは、CFI フラッシュ・メモリ
からのブートおよび EPCS フラッシュ・メモリからのブートをサポートします。RAM
の M4K および M9K タイプなど初期化をサポートするオンチップ RAM を使用する場
合、ブート・ローダなしでオンチップ RAM からブートすることが可能です。
f Nios II のブート方法について詳しくは、AN458: Alternative Nios II Boot Methods を参照し
てください。
追加のエンベデッド・デザインの検討事項
システムをデザインする上で、以下のトピックを検討する必要があります。
■
JTAG のシグナル・インテグリティ
■
プロトタイピング用の余分なメモリ・スペース
■
システム検証
JTAG のシグナル・インテグリティ
システム上の JTAG のシグナル・インテグリティは、非常に重要です。ユーザーは、
JTAG インタフェースを経由してハードウェアおよびソフトウェアをデバッグし、
FPGA をプログラムする必要があります。JTAG インタフェース上の不適切なシグナ
ル・インテグリティは、JTAG 接続を介したデバッグを妨げる、または矛盾したデ
バッガの動作を引き起こす可能性があります。
ユーザーは、JTAG チェインを検証するためにシステム・コンソールを使用すること
ができます。
1
JTAG のシグナル・インテグリティの問題は、診断するのが極めて困難です。これら
の問題を回避するために、またこれらの問題が生じた場合に診断するために、アル
テラは、ボードをデザインするときに AN428: MAX II CPLD Design Guidelines および
Embedded Design Handbook の Verification and Board Bring-Up の章に示すガイドラインに
従うことを推奨しています。
f システム・コンソールについて詳しくは、Quartus II Handbook の volume 3 の Analyzing
and Debugging Designs with the System Console の章を参照してください。
システムのプロトタイピング用のメモリ・スペース
最終的にオンチップ・メモリを含まない場合でも、アルテラは、プロトタイプ・
ボードにオフチップ・メモリの領域への接続を含めることを推奨します。システム
内のこのコンポーネントは、コード・サイズを心配せずにコード機能の改良に専念
できる追加のメモリ容量を提供します。デザイン・プロセスの後の方で、ユーザー
は、ソフトウェアを格納するためのより小さなメモリ・デバイスに置き換えること
ができます。
エンベデッド・システムの検証
f エンベデッド・システムのデザイン手法について詳しくは、Embedded Design
Handbook の Verification and Board Bring-Up の章を参照してください。アルテラは、デ
ザインを開始する前にこの章を読むことを推奨します。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 1 章 : 初めての設計者向けのガイド
エンベデッド・デザイン・リソース
1‒19
エンベデッド・デザイン・リソース
この章は、デザイン・ヘルプを見つけるときに役立つリソースのリストを含んでい
ます。リソース・オプションには、ウェブ・ベースのフォーラムおよび Wiki と同様
に、オンライン資料、トレーニング、My Support などの追加のアルテラ・ベースの
サポートが含まれています。最良のオプションは、ユーザーの質問およびデザイン・
サイクルでの現在のステージによります。
アルテラのエンベデッド・サポート
アルテラは、以下の手順でサポートを検索することを推奨しています。
1. アルテラ・ウェブサイトの Literature and Technical Documentation のページ、特に
Literature: Nios II Processor のページおよび Literature: SOPC Builder のページで関連
文献を探します。
2. 日本アルテラまたは販売代理店、もしくはフィールド・アプリケーション・エン
ジニア（FAE）に問い合わせます。
3. アルテラ・ウェブサイトの myAltera のページを経由してテクニカル・サポートに
問い合わせ、アルテラからの直接的なサポートを得ます。
4. 以下のコミュニティに属するリソースのうち 1 つに問い合わせます。
■
■
アルテラ・フォーラムのウェブサイトで使用可能な Nios フォーラム
（www.alteraforum.com）
アルテラ Wiki のウェブサイト（www.alterawiki.com）
1
アルテラは、外部団体による Nios フォーラムおよびアルテラ Wiki のウェブ
サイトの内容については、責任を負いません。
アルテラ・エンベデッドのトレーニング
ツール同士がどのように動作するか、またそれらがインストラクタ主導の環境でど
のように使用するか、ということを学ぶには、トレーニングにご登録ください。い
くつかのトレーニング・オプションが使用可能です。一般的なトレーニングについ
て詳しくは、アルテラ・ウェブサイトの Training & Events を参照してください。
使用可能なコースおよび場所について詳しくは、アルテラ・ウェブサイトの
Embedded SW Designer Curriculum のページを参照してください。このページには、オ
ンライン・トレーニングおよびインストラクタ主導のトレーニングの両方について
の情報があります。
アルテラ・エンベデッドの資料
ユーザーは、<Nios II EDS install dir>\documents\index.htm にある Nios II EDS インストー
ル・ディレクトリから Nios II プロセッサおよびエンベデッド・デザインについての
資料にアクセスすることができます。Windows プラットフォームでこのページに直
接アクセスするには、Start メニューの All Programs をクリックします。All Programs
メニューの Altera サブメニューにある Nios II EDS <version> サブメニューの Nios II
<version> Documentation をクリックします。このウェブページには、Nios II の最新資
料へのリンクが含まれています。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
1‒20
第 1 章 : 初めての設計者向けのガイド
アルテラ・エンベデッドの用語集
アルテラ・ウェブサイトの Literature: Nios II Processor のページには、使用可能な資料
のリストおよびリンクがあります。このページの下に、Nios II プロセッサのオンラ
イン資料およびエンベデッド・デザインの情報を含むさまざまな製品のページへの
リンクがあります。
Nios II IDE を実行している場合、初めてのユーザー向けの情報が Welcome ページに表
示されます。このページは、インストール後に初めて Nios II IDE を開いたときに表示
されます。ユーザーは、Help メニューにある Welcome をクリックすることで、いつ
でもこれを開くことができます。
Embedded Design Handbook の他の章は、エンベデッド・ハードウェアおよびソフト
ウェアのデザイン、検証、およびデバッグに関する情報の貴重な情報源です。各章
には、関連する内容の概要が書かれた資料へのリンクがあります。
サードパーティの IP（Intellectual Property）
これまでに多くのサードパーティが、アルテラ AMPPSM プログラムを通してアルテ
ラ FPGA を使用するエンベデッド・デザインのための開発ソリューションに参加しま
した。Nios II プロセッサに使用可能なサードパーティ・ソリューションの最新情報に
ついては、アルテラ・ウェブサイトの Embedded Processing のページにある Altera
Embedded Alliance Partners をクリックしてください。
いくつかのコミュニティ・フォーラムもまた使用可能です。これらのフォーラムは、
アルテラによるものではありません。アルテラ・フォーラムの市場は、サードパー
ティのハードおよびソフトのエンベデッド・システム関連の IP を提供します。ま
た、フォーラムには、便利なデザイン例の非サポート・プロジェクト・レポジトリ
も含まれています。是非これらのフォーラムのページを確認してください。
従来のサポートは、サポート・センタから、またはアルテラのフィールド・アプリ
ケーション・エンジニア（FAE）を通して得ることができます。アルテラ・フォーラ
ム（www.alteraforum.com）の Nios フォーラム・セクションまたはアルテラ Wiki
（www.alterawiki.com）に含まれる情報を閲覧することで、さらに非公式サポートを得
ることができます。アルテラやその他からの多くの経験豊富な開発者は、Wiki の内
容や Nios フォーラムでの質疑応答に定期的に関わっています。
アルテラ・エンベデッドの用語集
以下の定義では、SOPC Builder および Nios II プロセッサ・ベースのシステムで使用さ
れるいくつかの固有の用語を説明しています。
■
コンポーネント — 関連するハードウェアにアクセスする上で必要なハードウェア
およびソフトウェアを含み、SOPC Builder の中で名づけられたモジュールです。
■
カスタム命令 —Nios II プロセッサの ALU と統合されたカスタム・ハードウェア処理
です。Nios II プロセッサおよび SOPC Builder ベースのデザインのプログラマブル
な性質は、このソフトウェア・アルゴリズムのカスタム・ハードウェア内での実
装をサポートします。カスタム命令は、一般的な動作を加速します。（Nios II プ
ロセッサの浮動小数点の命令は、カスタム命令として実装されます。）
■
カスタム・ペリフェラル — ハードウェア内に実装されたアクセラレータです。カ
スタム命令とは異なり、カスタム・ペリフェラルは CPU の ALU には接続されま
せん。これらは、システム・インタコネクト・ファブリックを経由してアクセス
されます。（システム・インタコネクト・ファブリックを参照してください。）カ
スタム・ペリフェラルは、データ・ストリーミング・アプリケーション中のプロ
セッサからのデータ送信動作をオフロードします。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 1 章 : 初めての設計者向けのガイド
アルテラ・エンベデッドの用語集
2011 年７月
1‒21
■
ELF（実行可能なリンク・フォーマット）—Nios II プロセッサにより使用される実
行可能なフォーマットです。このフォーマットは、使用可能で実行可能なフォー
マットのうち、おそらく最も一般的です。これは、今日人気のある Linux/BSD 動
作システムのほとんどで使用されます。
■
HAL（ハードウェア・アブストラクション・レイヤ）— 基本となるハードウェア
と通信するためのプログラム用にシンプルなデバイス・ドライバ・インタフェー
スを提供する軽量のランタイム環境です。newlib C ライブラリへの POSIX のよう
なソフトウェア・レイヤおよびラッパです。
■
Nios II C からハードウェアへのアクセラレーション（C2H）コンパイラ — エンベ
デッド・システム内でアルゴリズム・アクセラレーションおよびデザイン・ス
ペース・オプションを検索できるようにするための、プッシュボタンの ANSI C か
らハードウェアへのコンパイラです。
■
Nios II コマンド・シェル —Nios II および SOPC Builder のコマンドライン・ユーティ
リティにアクセスするために使用するコマンド・シェルです。
■
Windows プラットフォームでは、Nios II コマンド・シェルは、コマンドライ
ン・ユーティリティにアクセスうるために適切に実装された環境を持つ
Cygwin bash です。
■
Linux プラットフォームでは、適切に実装された bash を実行するために、次を
入力します。
<Nios II EDS install path>/nios2_command_shell.shr
■
Nios II エンベデッド開発スイート（EDS）—Nios II プロセッサ用のソフトウェア・
アプリケーションを構築およびデバッグするために必要な完全なソフトウェア環
境です。EDS には、Nios II IDE が含まれています。（Nios II IDE を参照してくださ
い。）
■
Nios II IDE— コントロールが制限されたソフトウェア・ビルド・プロセスでのコン
トロールが制限された Nios II エンベデッド・デザイン用の Eclipse ベースの開発
環境です。
■
Nios II ソフトウェア・ビルド・ツール（SBT）— ソフトウェア・ビルド・プロセス
でのコントロールが詳細な Nios II ソフトウェア・プロジェクトを作成できるよう
にするソフトウェアです。
■
Eclipse 用の Nios II ソフトウェア・ビルド・ツール — プロジェクト生成用、および
詳細なコントロールのソフトウェア・ビルド・プロセス用の SBT を使用する、
Nios II エンベデッド・デザイン用の Eclipse ベースの開発環境です。Eclipse 用の
SBT では、ソフトウェア・プロジェクトの管理、構築、およびデバッグ機能を提
供します。
■
SOPC Builder— プロセッサ付きまたはプロセッサなしの FPGA ベースのサブシステ
ム生成用の GUI ベースのシステム・ビルダおよび関連するビルド・ツールを提供
するソフトウェアです。
■
システム・インタコネクト・ファブリック —Nios II プロセッサがオンチップおよ
びオフチップ・ペリフェラルと通信するときに経由するインタフェースです。こ
のファブリックは、多くの利便性とパフォーマンス向上のための機能を提供しま
す。
Altera Corporation
エンベデッド・デザイン・ハンドブック
1‒22
第 1 章 : 初めての設計者向けのガイド
まとめ
まとめ
この章は、初めてのユーザー向けのアルテラのエンベデッド開発プロセスおよび
ツールの基本概要です。この章では、これらのツールの使用方法および詳細情報の
入手方法に焦点を絞っています。この章は、個別のツールおよび使用手順について
詳しく記載されているアルテラの他の資料を必要に応じて参照します。この章では、
ハードウェアおよびソフトウェア開発用のアルテラのエンベデッド開発ツールを初
めて使用するユーザー向けに、リソースおよび用語集があります。
改訂履歴
表 1–1 に、本資料の改訂履歴を示します。
表 1‒1. 改訂履歴
日付
バー
ジョン
変更内容
■
このハンドブックには Qsys に関する情報を含まない、ということの明確化。
■
ハードウェア・デザイン例の場所の更新。
■
ハードウェアの最適化に関する情報の追加。
■
参照先の更新。
2011 年 7 月
2.3
2010 年 3 月
2.2
Eclipse 用の SBT の更新。
2009 年 1 月
2.1
Nios Wiki のハイパーリンクの更新。
2008 年 11 月
2.0
システム・コンソールの追加。
2008 年 3 月
1.0
初版。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
2. Nios II ソフトウェアの開発
July 2011
ED51002-1.4
ED51002-1.4
はじめに
この章では、Altera® Nios® II プロセッサのソフトウェア開発に関する詳細情報を提供
します。以下の追加情報によって、Nios II Software Developer’s Handbook を補完します。
■
■
■
推奨されるデザイン手法 —Nios II ソフトウェアのデザイン、開発、および展開の
ための最良の手法についての情報です。
実装についての情報 — アプリケーション・プログラミング・インタフェース
（APIs）の実装および各トピックのソース・コードについての追加の詳細情報で
す（使用可能な場合）。
トピックへのポインタ — 有益なバックグランドおよび各トピックのリソース情報
です（使用可能な場合）。
この資料を読む前に、ユーザーは、Nios II ソフトウェア・ビルド・ツール開発フ
ローを使用するシンプルなボード・サポート・パッケージ（BSP）およびアプリケー
ション・プロジェクトの生成プロセスを十分に理解する必要があります。ソフト
ウェア・ビルド・ツール・フローは、Nios II コマンド・シェルと同様に Eclipse™ 用の
Nios II ソフトウェア・ビルド・ツールによってサポートされています。この資料で
は、Eclipse 用の Nios II ソフトウェア・ビルド・ツールに焦点を絞りますが、ほとん
どの情報はコマンド・シェルのプロジェクト開発にも適用可能です。
f 以下のリソースは、Nios II ソフトウェア・ビルド・ツール開発フローのトレーニング
です。
■
アルテラ・ウェブサイトの Embedded SW Designer Curriculum のページにあるオン
ライン・トレーニングのデモンストレーション。
■
Nios II プロセッサ用のソフトウェア開発：ツールの概要
■
Nios II プロセッサ用のソフトウェア開発：デザイン・フロー
■
Nios II プロセッサ用のソフトウェア開発：ソフトウェア・ビルド・フロー（そ
の 1）
■
Nios II プロセッサ用のソフトウェア開発：ソフトウェア・ビルド・フロー（そ
の 2）
■
アルテラ・ウェブサイトの Literature: Nios II Processor のページにある資料、特に
Nios II Software Developer's Handbook の Getting Started from the Command Line の章お
よび Getting Started with the Graphical User Interface の章。
■
Nios II のエンベデッド・デザイン・スイート（EDS）を使用するデザイン例。オン
ライン・トレーニングのデモンストレーションでは、そのままの状態で使用でき
るソフトウェア・デザイン例、または、より複雑なデザインの基礎としてのソフ
トウェア・デザイン例を説明しています。
この章は、Nios II ソフトウェア開発プロセスに従って構成されています。各項では、
特定のタスクを達成するためにアルテラが推奨するデザイン手法を説明しています。
© 2011 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, HARDCOPY, MAX, MEGACORE, NIOS, QUARTUS and STRATIX are Reg. U.S. Pat. & Tm. Off.
and/or trademarks of Altera Corporation in the U.S. and other countries. All other trademarks and service marks are the property of their respective holders as described at
www.altera.com/common/legal.html. Altera warrants performance of its semiconductor products to current specifications in accordance with Altera’s standard warranty, but
reserves the right to make changes to any products and services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Altera. Altera customers are advised to obtain the latest version of device
specifications before relying on any published information and before placing orders for products or services.
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Subscribe
2‒2
第 2 章 : Nios II ソフトウェアの開発
ソフトウェア開発サイクル
この章は、以下の項で構成されています。
■
1
「ソフトウェア開発サイクル」
■
2–5 ページの「ソフトウェア・プロジェクトの仕組み」
■
2–26 ページの「ハードウェア・アブストラクション・レイヤ（HAL）を使用した
開発」
■
2–47 ページの「アプリケーションの最適化」
■
2–53 ページの「アプリケーションのリンク」
■
2–55 ページの「アプリケーション・ブート・ロードおよびプログラミング・シス
テム・メモリ」
Nios II EDS をインストールする場合、Quartus II ソフトウェアと同じディレクトリにイ
ンストールされます。例えば、Quartus II ソフトウェアが Windows オペレーティン
グ・システムでインストールされて Quartus II ソフトウェアのルート・ディレクトリ
が c:\altera\<version>\quartus にある場合、Nios II EDS のルート・ディレクトリは
c:\altera\<version>\nios2eds にあります。簡単にするために、このハンドブックでは
nios2eds ディレクトリを <Nios II EDS install dir> として表示します。
ソフトウェア開発サイクル
Nios II EDS には、Nios II プロセッサ用の C/C++ ソフトウェア開発ツールの完全なセッ
トが含まれています。更に、一連のサードパーティのエンベデッド・ソフトウェア・
ツールも Nios II EDS で提供されます。このセットには、MicroC/OS-II のリアルタイ
ム・オペレーティング・システムおよび NicheStack TCP/IP のネットワーキング・ス
タックが含まれています。この章では、Nios II ソフトウェア生成用のアルテラ作成
のツールの使用に焦点を絞ります。また、サードパーティのツールについても説明
します。
Nios II EDS は、Nios II プロセッサ用のソフトウェアを生成、管理、および展開する
ツールの集合です。ツールチェインには、低レベルのタスクを実行するツール、お
よび低レベルのツールを使用して高レベルのタスクを実行するツールが含まれてい
ます。
この項には、以下のサブセクションが含まれています。
■
■
「アルテラの SOPC ソリューション」
2–4 ページの「Nios II ソフトウェア開発プロセス」
アルテラの SOPC ソリューション
Nios II ソフトウェア開発プロセスを理解するには、SOPC Builder システムの定義を理
解する必要があります。SOPC Builder は、プロセッサ、ペリフェラル、およびメモリ
を含むシステムを生成するためのシステム開発ツールです。このツールは、すべて
の SOPC を非常に効率よく定義および生成することを可能にします。SOPC Builder
は、システムで Nios II プロセッサを統合するための完全なサポートを提供しますが、
システムに Nios II プロセッサが含まれることを必要としません。
SOPC Builder システムは、従来のエンベデッド・システムに多くの点で類似していま
すが、両者は同じシステムではありません。両者の違いを十分に理解することで、
SOPC Builder システムをデザインするときの効率が向上します。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
ソフトウェア開発サイクル
2‒3
アルテラの SOPC Builder のソリューションでは、ハードウェア・デザインは FPGA デ
バイスの中に実装されます。FPGA デバイスは、揮発性（電源が切断されると内容が
失われる性質）であり再プログラム可能です。FPGA がプログラムされる場合、その
内部にあるロジック・セルは、Nios II プロセッサ、メモリ、ペリフェラル、および
他の構造を含むことができる SOPC システムを生成するために、コンフィギュレー
ションされて接続されます。システム・コンポーネントは、Avalon® インタフェース
と接続されます。FPGA が Nios II プロセッサを実装するためにプログラムされた後、
システム上でシステム・ソフトウェアをダウンロード、実行、デバッグすることが
できます。
以下に示す FPGA および Nios II プロセッサの基本的な特徴を理解することは、Nios II
ソフトウェア・アプリケーションを効率よく開発する上で必要不可欠です。
■
■
2011 年 7 月
FPGA デバイスおよび SOPC Builder— 基本的な機能：
■
揮発性 —FPGA は、コンフィギュレーションの後のみに機能して、いつでもリ
コンフィギュレーションすることができます。
■
デザイン — 多くのアルテラ SOPC システムがSOPC Builder およびQuartus® II ソフ
トウェアを使用してデザインされて、複数のペリフェラルおよびプロセッサ
を含むことがあります。
■
コンフィギュレーション —FPGA コンフィギュレーションは、Nios II ソフトウェ
アのデバッグ動作でも使用される USB-Blaster™ ケーブルなどのプログラミン
グ・ケーブルを経由して実行することができます。
■
ペリフェラル — ペリフェラルは、FPGA のリソースから作成されて、Avalon メ
モリ・スペースの中の任意の場所に表示することができます。これらのペリ
フェラルのほとんどは、内部でパラメータ化可能です。
Nios II プロセッサ — 基本的な機能：
■
揮発性 —Nios II プロセッサは揮発性であり、FPGA のコンフィギュレーションの
後のみに与えられます。これはシステム・コンポーネントとして FPGA 内に実
装される必要があり、他のシステム・コンポーネントと同じように実装され
ない限り FPGA 内には存在しません。
■
パラメータ化 —Nios II プロセッサの多くの機能は、とりわけコア・タイプ、
キャッシュ・メモリ・サポート、およびカスタム命令を含む SOPC Builder の中
でパラメータ化可能です。
■
プロセッサ・メモリ —Nios II プロセッサは、内部または外部メモリ・デバイス
にロードされたコードからブートして実行する必要があります。
■
デバッグ・サポート — ソフトウェア・デバッグ・サポートをイネーブルする
には、デバッグ・コアを使用して Nios II プロセッサをコンフィギュレーショ
ンする必要があります。デバッグ通信は、USB-Blaster ケーブルなどのプログ
ラミング・ケーブルを経由して実行されます。
■
リセット・ベクタ — リセット・ベクタ・アドレスは、任意のメモリ位置にコ
ンフィギュレーションすることができます。
■
例外ベクタ — 例外ベクタ・アドレスは、任意のメモリ位置にコンフィギュ
レーションすることができます。
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒4
第 2 章 : Nios II ソフトウェアの開発
ソフトウェア開発サイクル
Nios II ソフトウェア開発プロセス
この項では、Nios II ソフトウェア開発プロセスの概要を説明して、用語を紹介しま
す。この章の残りの部分では、この項の内容を詳しく説明します。
Nios II ソフトウェアの生成プロセスには、以下のステージおよびメインのハード
ウェア・コンフィギュレーション・ツールが含まれています。
1. ハードウェア・コンフィギュレーション
■
SOPC Builder
■
Quartus II ソフトウェア
2. ソフトウェア・プロジェクト管理
■
BSP コンフィギュレーション
■
アプリケーション・プロジェクト・コンフィギュレーション
■
ソフトウェア・プロジェクトの編集および構築
■
ターゲットを使用した実行、デバッグ、および通信
■
ハードウェアおよびソフトウェアのコヒーレンシの確保
■
プロジェクト管理
3. ソフトウェア・プロジェクト開発
■
ハードウェア・アブストラクション・レイヤ（HAL）を使用した開発
■
メモリにアクセスするための Nios II プロセッサのプログラミング
■
例外ハンドラの書き込み
■
パフォーマンスおよびサイズのためのアプリケーションの最適化
4. アプリケーション展開
■
リンク（ランタイム・メモリ）
■
システム・アプリケーションのブート・ロード
■
フラッシュ・メモリのプログラミング
ステージおよびツールに関するこのリストでは、ソフトウェア・プロジェクト管理
のトピックの下のサブトピックであるソフトウェア・プロジェクト管理、およびア
プリケーション展開は、その章の項に密接に関連しています。
ユーザーは、Quartus II および SOPC Builder ソフトウェアを使用してシステム用の
ハードウェアを作成します。システム用のハードウェアの作成によって生成される
メイン出力は、システムのハードウェア・イメージである SRAM オブジェクト・
ファイル（.sof）、およびハードウェア・コンポーネントと接続を表示する SOPC 情
報ファイル（.sopcinfo）です。
1
アプリケーション・ソフトウェアを生成する上で必要なキー・ファイルは、.sopcinfo
ファイルです。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
ソフトウェア・プロジェクトの仕組み
2‒5
ソフトウェア作成ツールは、BSP プロジェクトを生成する上で .sopcinfo ファイルを
使用します。BSP プロジェクトは、C ソース・ファイル、ヘッダ・ファイルと初期化
ファイル、およびシステム内でハードウェア用のカスタム・ライブラリを構築する
ための makefile のコレクションです。このカスタム・ライブラリは、BSP ライブラ
リ・ファイル（.a）です。BSP ライブラリ・ファイルは、システム用に実行可能バイ
ナリ・ファイルを生成するアプリケーション・プロジェクト（アプリケーション・
イメージと呼ばれます）とリンクしています。BSP プロジェクトおよびアプリケー
ション・プロジェクトの組み合わせは、ソフトウェア・プロジェクトと呼ばれます。
アプリケーション・プロジェクトは、アルテラが提供するツールを実行することで
作成できるアプリケーションの C ソース・ファイルとヘッダ・ファイル、および
makefile です。ユーザーは、makefile を使用してこれらのファイルの編集、コンパイ
ルおよび BSP ライブラリ・ファイルとのリンク作成をすることができます。アプリ
ケーション・ソースは、BSP ライブラリ・ファイルによって提供されるすべてのリ
ソースを照会することができます。BSP ライブラリ・ファイルには、アプリケー
ション・ソースが照会可能な HAL 提供のサービスが含まれています。アプリケー
ション・イメージの構築の後、ユーザーはターゲット・システムにそれをダウン
ロードすることが可能で、ターミナル・アプリケーションを経由してそれと通信す
ることが可能です。
1
Eclipse フレームワーク用の Nios II ソフトウェア・ビルド・ツール内のプロジェクトを
作成した後、ユーザーは Eclipse Project Explorer ビューの中の makefile にアクセスする
ことができます。
ソフトウェア・プロジェクトは柔軟性が高く、システム・ハードウェアの変更時に
再生成すること、機能への追加または機能からの削除のために修正すること、また
は特定のシステム用に修正することが可能です。また、ユーザーは、リード・オン
リー zip ファイル・システムまたは TCP/IP ネットワーキング・スタック（NicheStack
TCP/IP スタック）などの追加のアルテラ提供のソフトウェア・パッケージを含める
ために、BSP ライブラリ・ファイルを変更することができます。BSP ライブラリ・
ファイルおよびアプリケーション・プロジェクトの両方は、コンパイラの最適化や
リンカ設定などの異なるパラメータを使用して構築するためにコンフィギュレー
ションすることができます。
1
ハードウェア・システムを変更する場合、ライブラリ・ヘッダ・ファイルの更新を
維持するために BSP プロジェクトを再作成、更新または再生成する必要があります。
f ハードウェアを使用して BSP の更新を維持する方法について詳しくは、Nios II
Software Developer's Handbook の Nios II Software Build Tools の章の「Revising Your BSP」
の項を参照してください。
ソフトウェア・プロジェクトの仕組み
この項では、主に Eclipse 用の Nios II ソフトウェア・ビルド・ツールを使用する場合
にソフトウェア・アプリケーションを編集、構築、ダウンロード、およびデバッグ
する上で推奨される方法を示します。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒6
第 2 章 : Nios II ソフトウェアの開発
ソフトウェア・プロジェクトの仕組み
Nios II ソフトウェア・ビルド・ツール・フローは、Nios II プロセッサを含むハード
ウェア・デザイン用に推奨されるデザイン・フローです。この項では、BSP および
アプリケーション・プロジェクトのコンフィギュレーション方法を示します。また、
Nios II プロセッサを含むシステム用のソフトウェア・プロジェクトの開発プロセス
を、ソフトウェアおよびハードウェアのデザインの間のコヒーレンシを確保するこ
とも含めて説明します。
この項には、以下のサブセクションが含まれています。
■
「ソフトウェア・ツールのバックグランド」
■
2–7 ページの「開発フローのガイドライン」
■
2–7 ページの「Nios II ソフトウェア・ビルド・ツール・フロー」
■
2–8 ページの「BSP プロジェクトおよびアプリケーション・プロジェクトのコン
フィギュレーション」
■
2–21 ページの「ソフトウェア・プロジェクトのコヒーレンシの確保」
ソフトウェア・ツールのバックグランド
Nios II EDS は、アプリケーション・イメージを構築するためのソフトウェア・プロ
ジェクト生成ツールの高度なセットを提供します。プロジェクト作成には、Nios II
ソフトウェア・ビルド・ツール・フローおよび Nios II 統合開発環境（IDE）フロー
の、2 つの独立したソフトウェア開発方法が使用可能です。Nios II ソフトウェア・ビ
ルド・ツール・フローには、ソフトウェア・ビルド・ツールのコマンドライン・イ
ンタフェースおよび Eclipse 用の Nios II ソフトウェア・ビルド・ツールが含まれてい
ます。
Eclipse 用の Nios II ソフトウェア・ビルド・ツールは、推奨されるフローです。しか
し、Eclipse 用の Nios II ソフトウェア・ビルド・ツールは、以下の Nios II IDE 機能をサ
ポートしません。
■
FS2 コンソールで使用可能なトレース機能は、システム・コンソール・デバッガ
とは正しく動作しません。
■
RS-232 UART への stdio 出力は、システム・コンソールで表示することはできませ
ん。システム・コンソールで stdio 出力を表示するには、hal.stdout の BSP 設
定を使用して、stdout 用に JTAG UART ペリフェラルを使用するための BSP をコ
ンフィギュレーションします。ハードウェア・システムで使用可能な JTAG UART
がない場合、stdio 出力をキャプチャするために独立した Nios II コマンド・シェ
ルの中の nios2-terminal を実行します。
Nios II ソフトウェア・ビルド・ツール開発フローは、ソフトウェア・アプリケー
ションの作成、管理、およびコンフィギュレーション用として、簡単に制御可能な
開発環境を提供します。Nios II ソフトウェア・ビルド・ツールには、コマンドライ
ン・ユーティリティ、スクリプト、および Tcl スクリプト用のツールが含まれていま
す。Nios II EDS のバージョン 9.1 で開始する場合、アルテラはソフトウェア・ビル
ド・ツール・フローの使いやすいグラフィカル・ユーザー・インタフェース（GUI）
ベースのバージョンである Eclipse 用の Nios II ソフトウェア・ビルド・ツールを提供
します。
1
アルテラは、新規のソフトウェア・プロジェクトを作成する上で、Eclipse 用の Nios II
ソフトウェア・ビルド・ツールを使用することを推奨します。Nios II ソフトウェア・
ビルド・ツールは、アルテラの今後の開発にとっての基礎です。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
ソフトウェア・プロジェクトの仕組み
2‒7
f Nios II IDE プロジェクトから Nios II ソフトウェア・ビルド・ツール・フローへの移行に
ついて詳しくは、Nios II Software Developer's Handbook の付録の Using the Nios II
Integrated Development Environment にある「Porting Nios II IDE Projects to the Software
Build Tools」の項を参照してください。
1
Nios II IDE デザイン・フローでは、BSP プロジェクトはシステム・ライブラリと呼ば
れます。
Nios II BSP エディタと呼ばれる BSP ライブラリのコンフィギュレーション用のグラ
フィカル・ユーザー・インタフェース（GUI）もまた使用可能です。BSP エディタ
は、Eclipse 用の Nios II ソフトウェア・ビルド・ツールと共に統合されます。また、
独立して使用することもできます。
開発フローのガイドライン
Nios II ソフトウェア・ビルド・ツール・フローは、多くのサービスと機能を提供し
ます。それらのサービスと機能を十分に理解するまでは、アルテラは、ユーザーに
とっての開発の労力を軽減させるために以下のガイドラインに準拠することを推奨
します。
■
既知のハードウェア・デザインでの開始 — アルテラ・ウェブサイトの Nios II
Embedded Processor Design Examples のウェブ・ページには、デザインの出発点と
して最適なハードウェアのデザイン例と呼ばれる一連の既知の作業デザインが含
まれています。更に、Nios II Hardware Development Tutorial ではいくつかのデザイン
例を説明しています。
■
既知のソフトウェア・デザイン例での開始 —Nios II EDS には、ユーザーがアプリ
ケーションの出発点として使用するためにあらかじめコンフィギュレーションさ
れた一連のアプリケーション・プロジェクトが含まれています。ユーザーのアプ
リケーションの目標に合わせて、これらのデザインのうち 1 つを使用してそれを
パラメータ化します。
■
資料へのポインタの準拠 — 多くのアプリケーションおよび BSP プロジェクト・
ソース・ファイルには、追加情報を提供するインライン・コメントが含まれてい
ます。
■
インクリメンタルな変更 — 最終アプリケーションの目標にかかわらず、ソフト
ウェア開発プロセスを区分するために、インクリメンタルでテスト可能な変更を
することによってソフトウェア・アプリケーションを開発します。アルテラは、
ソース・ファイルの個別のバージョンをユーザーが開発したプロジェクトの状態
に保持するために、バージョン・コントロール・システムを使用することを推奨
します。
以下の項では、これらのガイドラインの活用方法を示します。
Nios II ソフトウェア・ビルド・ツール・フロー
Nios II ソフトウェア・ビルド・ツールは、コマンドライン・ユーティリティおよび
スクリプトの集合です。これらのツールによって、アプリケーション・イメージを
作成するための BSP プロジェクトおよびアプリケーション・プロジェクトを構築で
きるようになります。BSP プロジェクトは、パラメータ化可能なライブラリであり、
システム内のハードウェア機能およびペリフェラル用にカスタマイズされています。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒8
第 2 章 : Nios II ソフトウェアの開発
ソフトウェア・プロジェクトの仕組み
BSP ライブラリ・ファイルを BSP プロジェクトから作成する場合、ユーザーは特定
のパラメータ値のセットを使用して作成することになります。アプリケーション・
プロジェクトは、アプリケーション・ソース・ファイルおよびアプリケーション
makefile で構成されています。ソース・ファイルは、BSP ライブラリ・ファイルに
よって提供されるサービスを照会することができます。
f Nios II ソフトウェア・ビルド・ツール・フローのユーティリティおよびスクリプトの
完全なリストについて詳しくは、Nios II Software Developer's Handbook の Nios II
Software Build Tools の章の「Altera-Provided Embedded Development Tools」の項を参照し
てください。
Eclipse 用の Nios II ソフトウェア・ビルド・ツール
Eclipse 用の Nios II ソフトウェア・ビルド・ツールは、すべての Nios II プロセッサ・
システムで動作する一貫した開発プラットフォームを提供します。プログラムの作
成、編集、構築、実行、デバッグ、およびプロファイルを含めて Eclipse 用の Nios II
ソフトウェア・ビルド・ツールでのほとんどのソフトウェア開発タスクを実行する
ことができます。
Eclipse 用の Nios II ソフトウェア・ビルド・ツールは、人気のある Eclipse™ フレーム
ワークおよび Eclipse C/C++ 開発ツールキット（CDT）プラグインに基づいています。
簡単に言えば、Eclipse 用の Nios II ソフトウェア・ビルド・ツールは、Nios II ソフト
ウェア・ビルド・ツール・ユーティリティおよびスクリプトを水面下で実行する GUI
を提供します。
f Eclipse 用の Nios II ソフトウェア・ビルド・ツールについて詳しくは、Nios II Software
Developer's Handbook の Getting Started with the Graphical User Interface の章を参照してく
ださい。Eclipse について詳しくは、Eclipse Foundation のウェブサイトを参照してくだ
さい（www.eclipse.org）。
Nios II ソフトウェア・ビルド・ツールのコマンドライン
Nios II ソフトウェア・ビルド・ツールのコマンドライン開発フローでは、コマンド
ラインにタイプされたまたはスクリプトにエンベデッドされた Nios II ソフトウェ
ア・ビルド・ツール・コマンドを使用して Nios II プログラムを作成、修正、構築、
そして実行します。
プログラムをデバッグするには、ソフトウェア・ビルド・ツール・プロジェクトを
Eclipse にインポートします。ユーザーは、さらに Eclipse にインポートしたプロジェ
クトを編集、再構築、実行、そしてデバッグすることができます。
f Nios II ソフトウェア・ビルド・ツールおよび Nios II コマンド・シェルについて詳しく
は、Nios II Software Developer's Handbook の Getting Started from the Command Line の章を
参照してください。
BSP プロジェクトおよびアプリケーション・プロジェクトのコン
フィギュレーション
この項では、ユーザーがソフトウェアのデザイン例を使用してソフトウェア開発を
開始できるように、ソフトウェア・アプリケーションにある BSP プロジェクトおよ
びアプリケーション・プロジェクトをコンフィギュレーションするためのいくつか
の方法を示します。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
ソフトウェア・プロジェクトの仕組み
2‒9
f バージョン・コントロールの使用について、BSP プロジェクトのコピー、移動、名前
変更について、および BSP プロジェクトの他人への転送について詳しくは、Nios II
Software Developer's Handbook の Nios II Software Build Tools の章にある「Common BSP
Tasks」の項を参照してください。
ソフトウェアのデザイン例
Nios II ソフトウェア・ビルド・ツール・フローを詳しく理解して Nios II プロセッサ
用のソフトウェア開発を開始する最良の方法は、Nios II EDS と共に提供される既存の
ソフトウェアのデザイン例の 1 つを使用することです。ソフトウェアのデザイン例
は、あらかじめコンフィギュレーションされたソフトウェア・アプリケーションで
あり、ソフトウェア開発用の基礎として使用することができます。ソフトウェアの
デザイン例は、Nios II のインストール・ディレクトリにあります。
f Nios II EDS で提供されるソフトウェアのデザイン例について詳しくは、Nios II Software
Developer’s Handbook の Overview of Nios II Embedded Development の章の「Nios II
Embedded Design Examples」の項を参照してください。
ソフトウェアのデザイン例を使用するには、これらのステップに従います。
1. .sopcinfo のシステム・ファイルを含むシステム・ハードウェアがある作業ディレ
クトリを設定します。
1
.sof および .sopcinfo の更新ファイルを作成するために、Quartus II ソフトウェ
アを使用してシステム・ハードウェアを既にコンパイルしていることを確
認します。
2. 以下のように、Eclipse 用の Nios II ソフトウェア・ビルド・ツールを開始します。
■
Windows のオペレーティング・システムでは、Start メニューにおいて、
Programs > Altera > Nios II EDS <version> とポイントして、Nios II <version>
Software Build Tools for Eclipse をクリックします。
■
Linux のオペレーティング・システムでは、コマンド・シェルに
eclipse-nios2r と入力します。
3. Project Explorer ビューの任意の場所で右クリックして、New をポイントして
Nios II Application and BSP from Template をクリックします。
4. Templates リストから適切なソフトウェアのデザイン例を選択します。
1
ユーザーは、システム・ハードウェアが Template description にリストされ
るソフトウェア・デザイン例の要求を満たすことを確認する必要がありま
す。アルテラの Nios II 開発キットを使用する場合、キットと共に供給され
るソフトウェアのデザイン例によって、キットと共に含まれるハードウェ
アのデザイン例と動作することが保証されます。
5. SOPC Information File Name の横から作業ディレクトリに移動し、システムに関連
する .sopcinfo ファイルを選択します。
6. マルチプロセッサ・デザインでは、ソフトウェア・プロジェクトを実行するプロ
セッサを選択する必要があります。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒10
第 2 章 : Nios II ソフトウェアの開発
ソフトウェア・プロジェクトの仕組み
1
デザインにシングルの Nios II プロセッサが含まれる場合、プロセッサ名は
自動的に入力されます。
7. プロジェクト名を入力します。
8. Next をクリックします。
9. Create a new BSP project based on the application project template を選択します。
10. Finish をクリックします。Nios II ソフトウェア・ビルド・ツールは、アルテラ
HAL BSP をユーザー用に統合します。
1
自動的に BSP を作成するための Eclipse 用のソフトウェア・ビルド・ツールが必要ない
場合、ステップ 9 で Select an existing BSP project from your workspace を選択します。
そして、以下のいくつかのオプションがあります。
■
Import をクリックすることで、既存の BSP をインポートすることができます。
■
以下のようにして、HAL または MicroC/OS-II BSP を作成することができます。
a. Create をクリックします。Nios II Board Support Package ダイアログ・ボックス
が表示されます。
b. Operating System の横にある Altera HAL または Micrium MicroC/OS-II のいずれか
を選択します。
1
ユーザーは、BSP を作成するときのみにオペレーティング・システムを選
択することができます。オペレーティング・システムを変更するには、新
規の BSP を作成する必要があります。.
オペレーティング・システムの選択（HAL 対 MicroC/OS-II RTOS）
BSP ライブラリ・ファイルに組み込むランタイム環境（オペレーティング・システ
ム）には、以下の選択肢があります。
1
■
Nios II HAL— 多くのアプリケーションに十分な、軽量で POSIX のようなシングル・
スレッド・ライブラリです。
■
MicroC/OS-II RTOS— リアルタイムのマルチ・スレッド環境です。MicroC/OS-II の
Nios II 実装は HAL に基づいており、すべての HAL サービスが含まれています。
HAL または MicroC/OS-II の選択の後、この BSP プロジェクト用のオペレーティング・シ
ステムは変更不可能です。
BSP プロジェクトのコンフィギュレーション
BSP プロジェクトは、コンフィギュレーション可能なライブラリです。ユーザー作
成のカスタム・ライブラリでサイズ、速度、または他の機能に最適化された設定に
組み込むために BSO プロジェクトをコンフィギュレーションすることができます。
このカスタム・ライブラリは、アプリケーション・プロジェクトで使用される BSP
ライブラリ・ファイル（.a）です。
BSP プロジェクトを作成すると、BSP ライブラリ・ファイル・ソースと共にター
ゲット・ディレクトリが入力され、ファイル・スクリプトが構築されます。これら
のファイルのいくつかは他のディレクトリからコピーされたものであり、BSP プロ
ジェクトを再作成するときに上書きされません。その他は、BSP プロジェクトを作
成するときに生成されます。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
ソフトウェア・プロジェクトの仕組み
2‒11
BSP をコンフィギュレーションする最も基本的なツールは、BSP 設定です。この章
を通じてユーザーが作成可能なプロジェクト変更の多くは、BSP 設定に基づいてい
ます。この章では、それぞれのケースにおいて対応する設定の名前を挙げ、その設
定の正しい値の選択方法を説明します。ユーザーは、いくつかの方法で BSP 設定の
値をコントロールすることが可能です。その方法とは、コマンドラインで Tcl スクリ
プトと共に BSP エディタを使用して直接設定を調節することで変更する、または Tcl
スクリプトを BSP エディタにインポートすることで変更する、というものです。
BSP をコンフィギュレーションするための他の強力なツールは、ソフトウェア・
パッケージです。ソフトウェア・パッケージは、複雑な機能を BSP に追加すること
になります。BSP 設定で動作するときのように、コマンドラインで Tcl スクリプトと
共に BSP エディタを使用して、または Tcl スクリプトを BSP エディタにインポート
することで、ユーザーはソフトウェア・パッケージを追加および削除することがで
きます。
アルテラは、BSP プロジェクトをコンフィギュレーションするために、Nios II BSP エ
ディタを使用することを推奨します。Eclipse 用の Nios II ソフトウェア・ビルド・
ツールから Nios II BSP エディタを開始するには、BSP のところで右クリックして
Nios II をポイントし、BSP Editor をクリックします。
f BSP 設定の操作方法、ソフトウェア・パッケージを BSP エディタを使用して追加およ
び削除する方法について詳しくは、Nios II Software Developer's Handbook の Getting
Started with the Graphical User Interface の章の「Using the BSP Editor」の項を参照してく
ださい。また、この章では、BSP エディタでの Tcl スクリプトの使用方法を説明しま
す。コマンドラインでの BSP 設定の操作およびソフトウェア・パッケージのコント
ロールについて詳しくは、Nios II Software Developer's Handbook の Nios II Software Build
Tools Reference の章の「Nios II Software Build Tools Utilities」の項を参照してください。
使用可能な BSP 設定について詳しくは、Nios II Software Developer's Handbook の Nios II
Software Build Tools Reference の章の「Settings Managed by the Software Build Tools」の項
を参照してください。Tcl スクリプトの説明について詳しくは、Nios II Software
Developer's Handbook の Nios II Software Build Tools Reference の章の「Software Build Tools
Tcl Commands」の項を参照してください。
1
次回の BSP 生成のときにソフトウェア・ビルド・ツールによって BSP ファイルが上書
きされるため、BSP ファイルは編集しないでください。
MicroC/OS-II RTOS コンフィギュレーションのヒント
MicroC/OS-II RTOS 環境を使用する場合、この環境の以下の機能を理解しておく必要
があります。
■
MicroC/OS-II BSP 設定 —MicroC/OS-II RTOS は、多くのコンフィギュレーション・オ
プションをサポートします。これらのオプションはすべて、BSP 設定でイネーブ
ルおよびディセーブルできます。いくつかのオプションは、デフォルト状態でイ
ネーブルされています。MicroC/OS-II 用の BSP 設定の全リストは、Nios II BSP エ
ディタの Settings タブに表示されます。
f また、MicroC/OS-II BSP 設定は、Nios II Software Developer's Handbook の Nios II
Software Build Tools Reference の章の「Settings Managed by the Software Build
Tools」にも説明されています。
■
2011 年 7 月
MicroC/OS-II 設定の変更 —MicroC/OS-II オプションの変更によって、BSP ライブラ
リ・ファイルをコンパイルするために使用される system.h ファイルが変更されま
す。
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒12
第 2 章 : Nios II ソフトウェアの開発
ソフトウェア・プロジェクトの仕組み
■
MicroC/OS-II の初期化 — コアの MicroC/OS-II RTOS は、C ランタイム初期化（crt0）
コード・ブロックの実行中に初期化されます。crt0 コード・ブロックの実行後、
MicroC/OS-II RTOS のリソースはアプリケーションに使用可能です。詳しくは、
2–28 ページの「crt0 の初期化」を参照してください。
ユーザーは、BSP エディタを使用して MicroC/OS-II をコンフィギュレーションするこ
とができます。図 2–1 に、MicroC/OS-II タイマおよびキュー・コードをイネーブルす
る方法を示しています。2–13 ページの図 2–2 に、MicroC/OS-II と使用するための 4 つ
のタイマの最大値を指定する方法を示します。
図 2‒1. BSP エディタでの MicroC/OS-II タイマおよびキューのイネーブル
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
ソフトウェア・プロジェクトの仕組み
2‒13
2–13 ページの例 2–1 の MicroC/OS-II コンフィギュレーション・スクリプトは、図 2–1
および図 2–2 と同じように MicroC/OS-II コンフィギュレーションを実行します。つま
り、タイマおよびキュー・コードをイネーブルして 4 つのタイマの最大値を指定し
ます。
図 2‒2. 4 つのタイマ用の MicroC/OS-II の BSP エディタでのコンフィギュレーション
例 2‒1. MicroC/OS-II Tcl のコンフィギュレーション・スクリプトの例（ucosii_conf.tcl）
#enable code for UCOSII timers
set_setting ucosii.os_tmr_en 1
#enable a maximum of 4 UCOSII timers
set_setting ucosii.timer.os_tmr_cfg_max 4
#enable code for UCOSII queues
set_setting ucosii.os_q_en 1
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒14
第 2 章 : Nios II ソフトウェアの開発
ソフトウェア・プロジェクトの仕組み
HAL コンフィギュレーションのヒント
HAL 環境を使用する場合、この環境の以下の機能を理解しておく必要があります。
■
HAL BSP 設定 — オプションの全リストは、Nios II BSP エディタの Settings タブに表
示されます。これらのオプションには、コンパイルされる C または C++ ファイル
用、および適用される各ファイル用またはアーカイブされる各ファイル用に実行
する前処理および後処理を指定する設定が含まれています。
f BSP 設定について詳しくは、Nios II Software Developer's Handbook の Nios II
Software Build Tools Reference の章の「Settings Managed by the Software Build
Tools」を参照してください。
■
HAL 設定の変更 —HAL の変更によって、BSP ライブラリ・ファイルをコンパイルす
るために使用される system.h ファイルが変更されます。
■
HAL の初期化 —HAL は、C ランタイム初期化（crt0）コード・ブロックの実行中に
初期化されます。crt0 コード・ブロックの実行後、HAL のリソースはアプリケー
ションに使用可能です。詳しくは、2–28 ページの「crt0 の初期化」を参照してく
ださい。
ユーザーは、BSP エディタで HAL をコンフィギュレーションすることができます。
2–15 ページの図 2–3 に、stdio デバイスとして使用される UART の指定方法を示しま
す。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
ソフトウェア・プロジェクトの仕組み
2‒15
2–15 ページの例 2–2 の Tlc スクリプトは、図 2–3 と同じようにコンフィギュレー
ションを実行します。つまり、stdio デバイスとして使用される UART を指定しま
す。
図 2‒3. HAL stdio デバイスの BSP エディタでのコンフィギュレーション
例 2‒2. HAL Tcl のコンフィギュレーション・スクリプトの例（hal_conf.tcl）
#set up stdio file handles to point to a UART
set default_stdio uart1
set_setting hal.stdin $default_stdio
set_setting hal.stdout $default_stdio
set_setting hal.stderr $default_stdio
ソフトウェア・パッケージの追加
アルテラは、Nios II EDS でいくつかのアドオン・ソフトウェア・パッケージを提供し
ます。これらのソフトウェア・パッケージは、ユーザーの使用するアプリケーショ
ンに使用可能であり、Software Packages タブからの BSP エディタでのコンフィギュ
レーションが可能です。Software Packages タブによって、BSP 内にソフトウェア・
パッケージを挿入および削除することができて、また、ソフトウェア・パッケージ
設定をコントロールすることができます。このタブの先頭のソフトウェア・パッ
ケージ・テーブルに、使用可能な各ソフトウェア・パッケージのリストが表示され
ます。このテーブルでは、ソフトウェア・パッケージのバージョンを選択すること
が可能であり、また、ソフトウェア・パッケージをイネーブルおよびディセーブル
することができます。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒16
第 2 章 : Nios II ソフトウェアの開発
ソフトウェア・プロジェクトの仕組み
1
オペレーティング・システムは、どのソフトウェア・パッケージが使用可能である
か決定します。
以下のソフトウェア・パッケージは、Nios II EDS と共に提供されます。
■
ホスト・ファイル・システム —Nios II システムがワークステーション上に存在す
るファイル・システムにアクセスできるようにします。詳しくは、2–41 ページの
「ホスト・ベースのファイル・システム」を参照してください。
■
リード・オンリー Zip ファイル・システム — フラッシュ・メモリに格納されるシ
ンプルなファイル・システムへのアクセスを与えます。詳しくは、2–42 ページの
「リード・オンリー Zip ファイル・システム」を参照してください。
■
NicheStack TCP/IP スタック – Nios II Edition—NicheStack TCP/IP のネットワーキング・
スタックのサポートをイネーブルします。
f NicheStack TCP/IP のネットワーキング・スタックについて詳しくは、Nios II
Software Developer's Handbook の Ethernet and the TCP/IP Networking Stack Nios II Edition の章を参照してください。
Nios II BSP エディタとの Tcl スクリプトの使用
Nios II BSP エディタは、Tcl スクリプトをサポートします。Nios II BSP エディタ内の
Tcl スクリプトはシンプルなツールですが、1 つの BSP からもう 1 つの BSP に設定を
容易に移行できる強力なツールです。この機能は、互いに同じような BSP 設定を使
用する複数のソフトウェア・プロジェクトがある場合に特に便利です。BSP エディ
タ内の Tck スクリプトによって、以下のタスクが実行可能となります。
■
コマンドラインからの BSP の再生成
■
新規の BSP 用の出発点としての、既存の BSP からの TCL スクリプトのエクスポート
■
異なるハードウェア・プラットフォーム上での BSP の再作成
■
Tclコマンド使用およびBSP 設定のユーザーの理解を向上するためのTclスクリプト
の検索
ユーザー独自の手動作成の Tcl スクリプトのインポート、または Nios II BSP エディタ
からエクスポートされる Tcl スクリプトの使用、これらのうちいずれかによって BSP
をコンフィギュレーションすることができます。
1
ユーザーは、BSP を作成するときのみに Tcl スクリプトを適用することができます。
Tcl スクリプトのエクスポート
Tcl スクリプトをエクスポートするには、これらのステップに従います。
1. Nios II BSP エディタを使用して、既存の BSP プロジェクト内の BSP 設定をコン
フィギュレーションします。
2. Tools メニューの Export Tcl Script をクリックします。
3. Tcl スクリプトを格納したい所望のディレクトリに移動します。
4. Tcl Script 用のファイル名を選択します。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
ソフトウェア・プロジェクトの仕組み
2‒17
Tcl スクリプトを作成する場合、Nios II BSP エディタは、BSP のデフォルト値と異な
る設定のみをエクスポートします。例えば、BSP 内のデフォルトではない設定のみ
が 2–15 ページの図 2–3 に示されるものである場合、BSP エディタは例 2–3 に示すス
クリプトをエクスポートします。
例 2‒3. BSP エディタによってエクスポートされる Tcl スクリプト
######################################################################
#
# This is a generated Tcl script exported
# by a user of the Altera Nios II BSP Editor.
#
# It can be used with the Altera 'nios2-bsp' shell script '--script'
# option to customize a new or existing BSP.
#
######################################################################
######################################################################
#
# Exported Setting Changes
#
######################################################################
set_setting hal.stdout uart1
set_setting hal.stderr uart1
set_setting hal.stdin uart1
f デフォルト状態の BSP 設定について詳しくは、Nios II Software Developer's Handbook の
Nios II Software Build Tools の章の「Specifying BSP Defaults」の項を参照してください。
新規の BSP を作成するための Tcl スクリプトのインポート
以下の例では、インポートされた Tcl スクリプトを使用する新規の BSP のコンフィ
ギュレーション方法について示します。ユーザーは、新規の BSP 設定のファイルを
作成する場合、Nios II BSP エディタを使用して Tcl スクリプトをインポートします。
1
この例では、テキスト・エディタを使用して手動で Tcl スクリプトを作成します。ま
た、ユーザーは、「Tcl スクリプトのエクスポート」に示すように、他の BSP からエ
クスポートされた Tcl スクリプトを使用することもできます。
新規の BSP を Tcl スクリプトを使用してコンフィギュレーションするには、以下のス
テップに従います。
1. 任意のテキスト・エディタを使用して、example.tcl と呼ばれる新規のファイルを
作成します。
2. ファイルに例 2–4 の内容を挿入します。
例 2‒4. BSP コンフィギュレーションの Tcl スクリプトの example.tcl
set_setting
set_setting
set_setting
set_setting
hal.enable_reduced_device_drivers true
hal.enable_sim_optimize true
hal.enable_small_c_library true
hal.enable_gprof true
3. Nios II BSP エディタで、File メニューの New BSP をクリックします。
4. BSP Settings File Name ボックスで、新規の BSP 設定のファイルを保存するフォル
ダを選択します。デフォルト設定のファイル名 settings.bsp を受け取ります。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒18
第 2 章 : Nios II ソフトウェアの開発
ソフトウェア・プロジェクトの仕組み
5. Operating System リストの Altera HAL を選択します。
6. Additional Tcl script ボックスの example.tcl に移動します。
7. SOPC Information File Name ボックスの .sopcinfo ファイルを選択します。
8. OK をクリックします。BSP エディタが、新規の BSP を作成します。example.tcl
によって変更された設定は、図 2–4 のように表示されます。
図 2‒4. example.tcl を使用してコンフィギュレーションされた Nios II BSP 設定
1
アルテラの HAL の Tcl スクリプトを MicroC/OS-II BSP へ、またはその逆にインポートし
ようとしないでください。そのようにすると、設定が失われるなどの予期しない動
作が発生する恐れがあります。いくつかの BSP 設定は OS 特有であり、異なる OS で
作成されるスクリプトと互換性がありません。
f BSP の Tcl スクリプトに表示できるコマンドについて詳しくは、Nios II Software
Developer's Handbook の Nios II Software Build Tools Reference の章の「Software Build Tools
Tcl Commands」の項を参照してください。
アプリケーション・プロジェクトのコンフィギュレーション
ユーザーは、nios2-app-generate-makefile または nios2-app-update-makefile コ
マンドへの他のコマンドライン・オプションに沿ってソース・ファイルおよびバ
リッド BSP プロジェクトを指定することによって、アプリケーション・プロジェク
トをコンフィギュレーションします。
アプリケーション・コンフィギュレーションのヒント
アプリケーション・プロジェクトのデザイン効率を向上させるために、以下のヒン
トを使用します。
■
ソース・ファイルの搭載 — ソース・ファイルをプロジェクトに追加するには、
Windows Explorer などのファイル・ブラウザからそれらをドラッグして、Eclipse
用の Nios II ソフトウェア・ビルド・ツールの中の Project Explorer ビューにドロッ
プします。
コマンドラインから、アプリケーション・プロジェクトのソース・ファイルを指
定する上でいくつかのオプションが使用可能です。すべてのソース・ファイルが
同じディレクトリにある場合、--src-dir コマンドライン・オプションを使用し
ます。すべてのソース・ファイルが単一のディレクトリおよびそのサブディレク
トリに含まれる場合、--src-rdir コマンドライン・オプションを使用します。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
ソフトウェア・プロジェクトの仕組み
■
2‒19
Makefile の変数 — 新規のプロジェクトが Eclipse 用の Nios II ソフトウェア・ビルド・
ツール内に作成される場合、makefile は自動的にソフトウェア・プロジェクト・
ディレクトリ内に生成されます。ユーザーは、Nios II アプリケーション・ウィ
ザードを使用してアプリケーションの makefile の変数を変更することができます。
アプリケーション・プロジェクトのコンフィギュレーション中に、コマンドライ
ンから、--set <var> <value> コマンドライン・オプションを使用して makefile
変数を設定します。ユーザーが設定できる変数には、アプリケーション構築の前
および後にコマンドを実行するように指定する前処理設定の BUILD_PRE_PROCESS
および後処理設定の BUILD_POST_PROCESS が含まれています。現在の設定とデ
フォルト状態の設定をユーザーが理解していることを確認するため、生成された
アプリケーションの makefile を検証します。
■
トップ・レベル生成スクリプトの作成 — コンフィギュレーションをコントロール
するトップ・レベル・シェル・スクリプトの作成によって、コマンドラインか
ら、アプリケーション・プロジェクトのパラメータ化を簡略化します。Nios II
Embedded Processor Design Examples のウェブ・ページから使用可能なエンベデッ
ド・プロセッサのデザイン例にある create-this-app スクリプトは、コンフィギュ
レーション・スクリプトの良いモデルです。
ユーザー・ライブラリのリンク
ユーザーは、Nios II ソフトウェア・ビルド・ツールでユーザー・ライブラリを作成
および使用することができます。Eclipse 用の Nios II ソフトウェア・ビルド・ツール
には、GUI 環境でユーザー・ライブラリの作成を可能にする Nios II ライブラリ・
ウィザードが含まれています。
また、以下に従って Nios II コマンド・シェルでもユーザー・ライブラリを作成する
ことができます。
1. nios2-lib-generate-makefile コマンドを使用してライブラリを作成します。このコ
マンドは、public.mk ファイルを生成します。
2. --use-lib-dir オプションを使用して nios2-app-generate-makefile コマンドを実行
して、新規ライブラリと共にアプリケーション・プロジェクトをコンフィギュ
レーションします。オプション用の値は、ライブラリの public.mk ファイルへの
パスを指定します。
Makefile および Eclipse 用の Nios II ソフトウェア・ビルド・ツール
Eclipse 用の Nios II ソフトウェア・ビルド・ツールは、Nios II ソフトウェア・プロ
ジェクト用の makefile を作成して管理します。プロジェクトを作成する場合、Nios II
ソフトウェア・ビルド・ツールは、ユーザーが選択したパラメータおよび設定に基
づいて makefile を作成します。パラメータおよび設定を変更する場合、Nios II ソフト
ウェア・ビルド・ツールは、それらに合わせて makefile を更新します。BSP makefile
は、オペレーティング・システム、BSP 設定、選択されたソフトウェア・パッケー
ジ、および選択されたドライバに基づきます。
Nios II BSP makefile は、アプリケーションおよびユーザー・ライブラリの makefile と
異なる処理がなされます。Nios II アプリケーションおよびユーザー・ライブラリの
makefile は、ユーザーが直接指定したソース・ファイルに基づきます。アプリケー
ションまたはユーザー・ファイルに対する以下の変更によって、対応する makefile の
内容も変更されます。
2011 年 7 月
■
アプリケーションまたはユーザー・ライブラリ名の変更
■
ソース・ファイルの追加または削除
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒20
第 2 章 : Nios II ソフトウェアの開発
ソフトウェア・プロジェクトの仕組み
■
関連する BSP へのパスの指定
■
関連するユーザー・ライブラリへのパスの指定
■
コンパイラ・オプションのイネーブル、ディセーブルまたは変更
f BSP および makefile について詳しくは、Nios II Software Developer's Handbook の Getting
Started with the Graphical User Interface の章の「Makefiles and the Nios II Software Build
Tools for Eclipse」を参照してください。
Eclipse 用の Nios II ソフトウェア・ビルド・ツールでのソフトウェア
の構築および実行
プロジェクトの構築
BSP の設定および機能を編集し、BSP（makefile を含む）を生成した後、ユーザーは
プロジェクトを構築することができます。Project Explorer ビューのプロジェクトを右
クリックして、Build Project をクリックします。
ソフトウェアのダウンロードおよび実行
プログラムをダウンロードおよび実行またはデバッグするには、Project Explorer
ビューのプロジェクトを右クリックします。プログラムを実行するには、Run As を
ポイントして Nios II Hardware をクリックします。
1
ターゲットのアプリケーションを実行する前に、.sof ファイル内のターゲットのハー
ドウェア・イメージと共に FPGA がコンフィギュレーションされていることを確認し
てください。
ターゲットとの通信
Eclipse 用の Nios II ソフトウェア・ビルド・ツールは、システムで通信できるコン
ソール・ウィンドウを提供します。ターゲットと通信するために Eclipse 用の Nios II
ソフトウェア・ビルド・ツールを使用する場合、入力する文字は 1 行ずつターゲッ
トに送信されます。これらの文字は、キーボードの Enter キーを押した後のみター
ゲットに表示されます。
UART または JTAG UART インタフェースで stdio ファンクションを使用するためにア
プリケーションをコンフィギュレーションした場合、ターゲットのサブシステムと
通信するための nios2-terminal アプリケーションを使用することができます。しか
し、Eclipse 用の Nios II ソフトウェア・ビルド・ツールおよび nios2-terminal アプリ
ケーションは、非常に異なる方法で入力文字を処理します。
コマンドラインにおいて、ユーザーはターゲットと通信するための nios2-terminal ア
プリケーションを使用する必要があります。アプリケーションを開始するには、以
下のコマンドを入力します。
nios2-terminal r
nios2-terminal アプリケーションを使用する場合、シェル内に入力する文字はター
ゲットに 1 つずつ送信されます。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
ソフトウェア・プロジェクトの仕組み
2‒21
Eclipse 用の Nios II ソフトウェア・ビルド・ツールでのソフトウェアのデバッグ
この項では、Eclipse 用の Nios II ソフトウェア・ビルド・ツールを使用して Nios II プ
ログラムをデバッグする方法について説明します。ユーザーは、Nios 開発ボードな
どの Nios II ハードウェア上で Nios II プログラムをデバッグすることができます。ソ
フトウェア・プロジェクトをデバッグするには、アプリケーションのプロジェクト
名を右クリックして、Debug As をポイントして Nios II Hardware をクリックします。
1
Local C/C++ Application を選択してはいけません。Nios II プロジェクトは、Nios II 実行コ
ンフィギュレーションを使用して実行およびデバッグのみ可能です。
f アプリケーションをデバッグするための Eclipse 用の Nios II ソフトウェア・ビルド・
ツールの使用について詳しくは、Embedded Design Handbook の Debugging Nios II
Designs の章を参照してください。
デバッグ目的では、hal.enable_runtime_stack_checking の BSP 設定を使用してラ
ンタイム・スタック・チェックをイネーブルすると便利です。適切に使用される場
合、この設定は、スタックがヒープまたはメモリ内にスタティックに割り当てられ
たデータと衝突したときにデバッガをイネーブルします。
f ランタイム・スタック・チェックの使用方法について詳しくは、Embedded Design
Handbook の Debugging Nios II Designs の章の「Run-Time Analysis Debug Techniques」を
参照してください。この設定および他の BSP コンフィギュレーション設定について
詳しくは、Nios II Software Developer's Handbook の Nios II Software Build Tools Reference
の章の「Settings Managed by the Software Build Tools」を参照してください。
ソフトウェア・プロジェクトのコヒーレンシの確保
エンジニアリング環境によって、ソフトウェアおよびシステム・ハードウェアのプ
ロジェクトの間のコヒーレンシを維持することが困難な場合があります。例えば、
ハードウェア・エンジニアリング・チームは、ソフトウェア・エンジニアリング・
チームの独立したハードウェアの新規バージョンを作成する混合チーム環境では、
システム・ハードウェアの特定のバージョンに誤ったソフトウェアのバージョンを
使用する可能性が高くなります。このようなエラーは、エンジニアにとってファン
トム問題をデバッグするのに時間を要する可能性があります。この項では、このよ
うな問題を回避する助けとなるいくつかのデザインおよびソフトウェア・アーキテ
クチャの手法を説明します。
推奨される開発手法
ソフトウェア・コヒーレンシ問題を回避するための最も安全なソフトウェア開発手
法は、厳密なハードウェアおよびソフトウェアのプロジェクト階層に従うこと、そ
してアプリケーションおよび BSP のプロジェクトを生成するためのスクリプトを使
用することです。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒22
第 2 章 : Nios II ソフトウェアの開発
ソフトウェア・プロジェクトの仕組み
最良の手法は、パラレル・アプリケーション・プロジェクトおよび BSP プロジェク
ト・フォルダを使用してアプリケーション階層を構築することです。図 2–5 のトッ
プ・レベルのハードウェア・プロジェクト・フォルダには、Quartus II プロジェク
ト・ファイル、SOPC Builder によって生成されたファイル、およびソフトウェア・プ
ロジェクト・フォルダが含まれています。ソフトウェア・プロジェクト・フォルダ
には、アプリケーション・プロジェクト用のサブフォルダおよび BSP プロジェクト
用のサブフォルダが含まれています。アプリケーション・プロジェクト・フォルダ
には create-this-app スクリプトが含まれており、BSP プロジェクト・フォルダには
create-this-bsp スクリプトが含まれています。
図 2‒5. 推奨されるディレクトリ構造
hardware project folder
<system_name>.sopcinfo
<system_name>.sof
software project folder
application project folder
create-this-app
clean-this-app
application software source files
BSP project folder
create-this-bsp
clean-this-bsp
bsp_settings.tcl (optional) (1)
図 2–5 の注：
(1) bsp_settings.tcl は、Tcl コンフィギュレーション・ファイルです。Tcl コンフィギュレーション・ファ
イルについて詳しくは、2–10 ページの「BSP プロジェクトのコンフィギュレーション」を参照してく
ださい。
コマンドラインからソフトウェア・プロジェクトを構築するには、ユーザー独自の
create-this-app および create-this-bsp のスクリプトを作成します。アルテラは、
clean-this-app および clean-this-bsp のスクリプトも作成することを推奨します。これ
らのスクリプトは、以下のタスクを実行します。
■
create-this-app— この bash スクリプトは、ユーザーのプロジェクト用のアプリケー
ション・ソフトウェア・ソース・ファイルを使用してアプリケーション・プロ
ジェクトを作成するために nios2-app-generate-makefile コマンドを使用します。
スクリプトは、BSP プロジェクトが適切にコンフィギュレーションされているこ
と（settings.bsp ファイルは BSP プロジェクト・ディレクトリにあります）を確
認して、必要な場合には create-this-bsp スクリプトを実行することを確認します。
アルテラ・ウェブサイトの Nios II Embedded Processor Design Examples のウェブ・
ページのエンベデッド・デザイン例に含まれるアルテラ提供の create-this-app ス
クリプトは、このスクリプトの良いモデルを提供します。
■
clean-this-app— この bash スクリプトは、以下を含むプロジェクト全体に必要なす
べてのクリーンアップ・タスクを実行します。
■
クリーンオール・ターゲットを使用したアプリケーション makefile を呼び出し
ます。
■
clean-this-bsp のシェル・スクリプトを呼び出します。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
ソフトウェア・プロジェクトの仕組み
2‒23
■
create-this-bsp— この bash スクリプトは、BSP プロジェクトを生成します。このス
クリプトは、オプションとしてコンフィギュレーション・スクリプトの
bsp_settings.tcl を呼び出すことができる nios2-bsp コマンドを使用します。
nios2-bsp コマンドは、ハードウェア・プロジェクト・フォルダにある
<system_name>.sopcinfo ファイルを照会します。このスクリプトを実行すること
で、BSP プロジェクトが作成されて、システム用の BSP ライブラリ・ファイルが
構築されます。
■
clean-this-bsp— この bash スクリプトは、BSP プロジェクト makefile のクリーン・
ターゲットを呼び出して、settings.bsp ファイルを削除します。
ハードウェアから BSP およびアプリケーション・プロジェクトへの全システムの生
成プロセスは、SOPC Builder のシステムを変更するときに毎回繰り返す必要がありま
す。そのため、create-this-bsp スクリプトのすべての設定を定義することは、Nios II
BSP エディタを使用するよりも効率よくプロジェクトをカスタマイズすることがで
きます。システム生成プロセスは、以下の通りです。
1. ハードウェア・ファイルの生成 —SOPC Builder を使用して、更新されたシステム
説明を <system_name>.sopcinfo ファイルに書き込みます。
2. BSP プロジェクトの再生成 —create-this-bsp スクリプトを使用して BSP プロジェ
クトを生成します。
3. アプリケーション・プロジェクトの再生成 —create-this-app スクリプトを使用し
てアプリケーション・プロジェクトを生成します。このスクリプトは、BSP ライ
ブラリ・ファイルを生成する makefile を作成および実行することによって BSP プ
ロジェクトを構築する create-this-bsp スクリプトを標準的に実行します。
4. システムの構築 — アプリケーションおよび makefile のスクリプトを使用して BSP
システム・ソフトウェアを構築します。create-this-app スクリプトは、アプリ
ケーション・プロジェクトおよび BSP ライブラリの両方を構築する make を実行
します。
このシステム生成プロセスを実装するために、アルテラは、ハードウェアおよびソ
フトウェアのグループの間の責任をハンドオフするために以下のチェックリストを
使用することを推奨します。
1
この方法は、ハードウェア・エンジニアリング・グループが Nios II EDS をインストー
ルすることを前提としています。その場合、ハードウェアおよびソフトウェアのエ
ンジニアリング・グループは、Nios II EDS のツールチェインと同じバージョンを使用
する必要があります。
ハードウェア・グループからソフトウェア・グループにプロジェクトをハンドオフ
するには、以下のステップを実行します。
1. ハードウェア・プロジェクトのハンドオフ — ハードウェア・グループは、
<system_name>.sopcinfo および <system_name>.sof のコピーを提供します。ソフト
ウェア・グループは、これらのファイルをソフトウェア・グループのハードウェ
ア・プロジェクト・フォルダにコピーします。
2. ソフトウェア・プロジェクトの再作成 — ソフトウェア・チームは、
create-this-app スクリプトの実行によって新規のハードウェア用のソフトウェア・
アプリケーションを再生成します。このスクリプトは、create-this-bsp スクリプ
トを実行します。
3. 構築 — ソフトウェア・チームは、ソフトウェア・アプリケーションを再生成す
るためにアプリケーション・プロジェクト・ディレクトリの make を実行します。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒24
第 2 章 : Nios II ソフトウェアの開発
ソフトウェア・プロジェクトの仕組み
ソフトウェア・グループからハードウェア・グループにプロジェクトをハンドオフ
するには、以下のステップを実行します。
1. プロジェクト・ディレクトリのクリーン — ソフトウェア・グループは、
clean-this-app スクリプトを実行します。
2. ソフトウェア・プロジェクト・フォルダのハンドオフ — ソフトウェア・グルー
プは、ハードウェアの最新バージョン用に生成されたソフトウェア・プロジェク
ト・フォルダ構造を持つハードウェア・グループを提供します。ソフトウェア・
プロジェクト・フォルダが、アプリケーション・プロジェクト・ファイル、アプ
リケーション・プロジェクト・スクリプトおよび BSP 生成のスクリプトのみを含
んでいるのが理想的です。
3. ソフトウェア・プロジェクトのリコンフィギュレーション — ハードウェア・グ
ループは、グループのアプリケーションおよび BSP プロジェクトをリコンフィ
ギュレーションするために create-this-app スクリプトを実行します。
4. 構築 — ハードウェア・グループは、ソフトウェア・アプリケーションを再生成
するためにアプリケーション・プロジェクト・ディレクトリの make を実行しま
す。
推奨されるアーキテクチャ手法
アプリケーション・ソフトウェアの作成時に発生するハードウェアおよびソフト
ウェアのコヒーレンシの問題の多くは、誤って配置されたペリフェラル・アドレス
の問題です。SOPC Builder によって提供される柔軟性のために、システムのほとんど
のペリフェラルは、任意のアドレスの割り当て、またはシステム作成時に変更され
たアドレスを持つことができます。ソフトウェア・アプリケーションの作成時のこ
のタイプのコヒーレンシ問題を回避するためには、以下の手法を実装します。
■
ペリフェラルおよびメモリのアドレッシング —Nios II ソフトウェア・ビルド・
ツールは、システムのすべてのペリフェラル用の一連の #define シンボルを定義
するシステム・ヘッダ・ファイルの system.h を自動的に生成します。これらの定
義は、ペリフェラル名、ベース・アドレスの位置、およびアドレス・スパンを指
定します。メモリ・マネージメント・ユニット（MMU）が Nios II システムでイ
ネーブルされる場合、すべてのペリフェラル用のアドレス・スパンが MMU に
よって管理されるアドレス範囲外の直接マップされたメモリに位置していること
を確認します。
コヒーレンシ問題から保護するには、system.h 名およびアドレス・スパン・シン
ボルを持つすべてのシステムのペリフェラルおよびメモリ・コンポーネントにア
クセスします。コヒーレンシ問題から保護するには、system.h 名およびアドレ
ス・スパン・シンボルを持つすべてのシステムのペリフェラルおよびメモリ・コ
ンポーネントにアクセスします。この方法は、ペリフェラルのアドレス可能な位
置の変更後であってもペリフェラル・レジスタのアクセスが成功することを保証
します。
例えば、システムに UART1 と名づけられた UART ペリフェラルが含まれる場合、
アドレスの 0x1000 に位置して、アドレス（iowr_32(UART1_BASE, 0x0,
0x10101010)）ではなく system.h のアドレス・シンボル（iowr_32(0x1000, 0x0,
0x10101010)）を使用して UART1 レジスタにアクセスします。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
ソフトウェア・プロジェクトの仕組み
■
2‒25
プリプロセッサを使用したペリフェラル値のチェック — ユーザーが大規模なチー
ム環境で作業して、またソフトウェアが特定のハードウェア・アドレスに依存性
がある場合、ユーザーは、ソフトウェア・コンパイル・プロセス時にハードウェ
アを確認する一連の C プリプロセッサの #ifdef ステートメントを作成すること
ができます。これらの #ifdef ステートメントは、各ペリフェラル用の system.h
ファイルの #define 値を確認します。
例えば、ペリフェラル UART1 では、system.h の #define 値は以下のような表示が
想定されます。
#define
#define
#define
#define
. . .
UART1_NAME "/dev/uart1"
UART1_BASE 0x1000
UART1_SPAN 32
UART1_IRQ 6
C/C++ ソース・ファイルでは、ユーザーの期待するペリフェラル設定がハード
ウェア・コンフィギュレーションに変更されていないことを確認するプリプロ
セッサ・マクロを追加します。例えば、以下のコードは、UART1 のベース・アド
レスが期待される値を保持していることをチェックします。
#if (UART1_BASE != 0x1000)
#error UART should be at 0x1000, but it is not
#endif
■
システム ID コアを使用したコヒーレンシの確認 — システム ID コアを使用します。
システム ID コアは、生成されたハードウェア・システム用に固有の識別子を提
供する SOPC Builder のペリフェラルです。この識別子は、Nios II プロセッサに
よって読み出し可能なハードウェア・レジスタに格納されます。また、この固有
の識別子は、後にシステム用の BSP プロジェクトを生成するときに使用される
sopcinfo ファイルにも格納されます。ユーザーは、以下のいずれかの方法によっ
てハードウェアおよびソフトウェアの間のコヒーレンシを確認するために、シス
テム ID コアを使用することができます。
■
第 1 の方法は、実行可能なリンク・フォーマット（.elf）ファイルが Nios II ター
ゲットにダウンロードされる場合、システム・ソフトウェア開発時にオプ
ションとして実装されます。ソフトウェアのダウンロード・プロセス時に、
システム ID コアの値は BSP ライブラリ・ファイルの値と照合されます。2 つ
の値が一致しない場合、そのことが通知されます。システム ID の違いが関連
していないことを知っていれば、ダウンロードを強制するためにシステム ID
のチェックをオーバーライドすることができます。ハードウェアおよびソフ
トウェアの間のミスマッチによって、存在しないバグを解決するのにユー
ザーが時間を浪費することになる可能性があるため、この無効を特別な注意
と共に使用します。
■
システム ID ペリフェラルを使用するための第 2 の方法は、Nios II デバッグ・
ポートを持たないシステム、または Nios II ソフトウェアのダウンロード・
ユーティリティが実用的でない状況に便利です。この方法では、C ファンク
ションの alt_avalon_sysid_test() を使用します。このファンクションは、
ハードウェアおよびソフトウェアのシステム ID が一致しているかどうか通知
します。
f システム ID コアについて詳しくは、Embedded Peripherals IP User Guide の
System ID Core の章を参照してください。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒26
第 2 章 : Nios II ソフトウェアの開発
ハードウェア・アブストラクション・レイヤ（HAL）を使用した開発
ハードウェア・アブストラクション・レイヤ（HAL）を使用した開発
Nios II プロセッサ用の HAL は、基本となるハードウェアと通信するプログラム用の
シンプルなデバイス・ドライバ・インタフェースを提供する軽量のランタイム環境
です。HAL API は、ANSI C 標準ライブラリと統合されます。HAL API によって、ユー
ザーは使い慣れた C ライブラリ・ファンクションを使用してデバイスおよびファイ
ルにアクセスできるようになります。
この項は、以下のサブセクションで構成されています。
■
2–26 ページの「HAL の概要」
■
2–27 ページの「HAL ベースのアプリケーションでのシステムのスタートアップ」
■
2–31 ページの「HAL ペリフェラル・サービス」
■
2–43 ページの「Nios II プロセッサを使用したメモリへのアクセス」
■
2–46 ページの「例外の処理」
■
2–47 ページの「例外ハンドラの変更」
HAL の概要
この項では、Nios II ソフトウェアの HAL サービスの使用方法について説明します。
HAL のコンフィギュレーション・オプションについて、また、HAL ベースのアプリ
ケーションでのシステムのスタートアップおよび HAL サービスについて詳しく説明
します。
HAL のコンフィギュレーション・オプション
Nios II ソフトウェア開発フローをサポートするために、HAL BSP ライブラリはある程
度自分自身でコンフィギュレーションします。デザインによって、HAL は、システ
ム・ハードウェアに存在するペリフェラルに基づいてできるだけ多くのサービスを
イネーブルしようと試みます。この手法は、製品開発およびボード立ち上げサイク
ル時に便利な機能である可能な最低制限環境をアプリケーションに提供します。
HAL は、BSP プロジェクトの作成時に呼び出される Tcl コマンドによって決定された
値を持つ設定のグループと共にコンフィギュレーションされます。2–10 ページの
「BSP プロジェクトのコンフィギュレーション」で説明しているように、アルテラ
は、HAL コンフィギュレーション設定が含まれる独立した Tcl ファイルを作成するこ
とを推奨します。
HAL コンフィギュレーション設定は、ブート・ロード・プロセスを制御して、初期
化プロセス、システム最適化、そしてペリフェラルおよびサービスのコンフィギュ
レーションでの詳しい制御を提供します。これらの各トピックについて、この項で
は、この章の他の場所の関連資料へのポインタを提供します。
ブート環境のコンフィギュレーション
ユーザーの特定のシステムは、ブート・ローダがアプリケーションの実行開始前に
アプリケーション・イメージをコンフィギュレーションする必要がある可能性があ
ります。例えば、アプリケーション・イメージがフラッシュ・メモリに格納されて
いて、実行用に揮発性メモリコピーされる必要がある場合、ブート・ローダは揮発
性メモリのアプリケーション・イメージをコンフィギュレーションする必要があり
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
ハードウェア・アブストラクション・レイヤ（HAL）を使用した開発
2‒27
ます。このコンフィギュレーション・プロセスは、HAL BSP ライブラリのコンフィ
ギュレーション・ルーチンの実行前、および crt0 コード・ブロックの実行前になさ
れます。ブート・ローダは、このプロセスを実装します。詳しくは、2–53 ページの
「アプリケーションのリンク」および 2–55 ページの「アプリケーション・ブート・
ロードおよびプログラミング・システム・メモリ」を参照してください。
HAL 初期化の制御
2–29 ページの「HAL の初期化」で説明しているように、ほとんどのアプリケーショ
ン・デバッグが main() ファンクションで開始しても、デバッグ・デバイス・ドライ
バの初期化などのいくつかのタスクは、crt0 初期化ルーチン実行後および main() の
呼び出し前にシステム初期化全体を制御する能力を必要とします。
アプリケーションのこの種類の例について詳しくは、Nios II EDS のインストールと共
に提供される hello_alt_main ソフトウェア・デザイン例を参照してください。
コード・フットプリントの最小化とパフォーマンスの向上
アプリケーションのパフォーマンスの向上またはコード・フットプリントの最小化
について詳しくは、2–47 ページの「アプリケーションの最適化」を参照してくださ
い。
ペリフェラルおよびサービスのコンフィギュレーション
HAL サービスのコンフィギュレーションおよび使用について詳しくは、2–31 ページ
の「HAL ペリフェラル・サービス」を参照してください。
HAL ベースのアプリケーションでのシステムのスタートアップ
HAL ベースのアプリケーションでのシステムのスタートアップは、3 段階のプロセス
です。まず、システムの初期化をして、次に crt0 コード・セクションを実行し、最
後に HAL サービスの初期化をします。以下の項では、システム・スタートアップの
これらの 3 つのステージについて説明します。
システムの初期化
システム初期化シーケンスは、システムのパワー・アップのときに開始します。Nios
II プロセッサを含む FPGA デザイン用の初期化シーケンス・ステップは、以下の通り
です。
1. ハードウェア・リセット・イベント — ボードは、FPGA をリセットするパワー・
オン・リセット信号を受信します。
2. FPGA コンフィギュレーション —FPGA は、特定のコンフィギュレーション・メモ
リまたは外部ハードウェア・マスタから .sof ファイルと共にプログラムされま
す。外部ハードウェア・マスタとして、CPLD デバイスまたは外部プロセッサを
使用することができます。
3. システム・リセット —1 つ以上の Nios II プロセッサおよび他のペリフェラルから
構成される SOPC Builder システムは、ハードウェア・リセット信号を受信して、
コンポーネントの組み合わせリセット・ステートを入力します。
4. Nios II プロセッサ — 各 Nios II プロセッサは、プリコンフィギュレーションされ
たリセット・アドレスにジャンプして、このアドレスで確認される命令の実行を
開始します。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒28
第 2 章 : Nios II ソフトウェアの開発
ハードウェア・アブストラクション・レイヤ（HAL）を使用した開発
5. ブート・ロードまたはプログラム・コード — システム・デザインに応じて、リ
セット・アドレス・ベクタには、パッケージされたブート・ローダ、呼び出され
たブート・イメージ、またはアプリケーション・イメージが含まれています。ア
プリケーション・イメージがプログラム実行のために非揮発性メモリから揮発性
メモリにコピーされる必要がある場合、ブート・ローダを使用します。例えば、
プログラムがフラッシュ・メモリに格納されていて SDRAM から実行される場合、
このケースとなります。ブート・ローダが存在しない場合、リセット・ベクタは
直接アプリケーション・イメージの .crt0 セクションにジャンプします。プログ
ラムが非揮発性メモリまたは事前にプログラミングされたメモリからその場で実
行する場合、ブート・ローダを使用しません。これらの両方のケースについて詳
しくは、2–55 ページの「アプリケーション・ブート・ロードおよびプログラミン
グ・システム・メモリ」を参照してください。
6. crt0 実行 — ブート・ローダの実行の後、プロセッサは、プログラミングの初期
化ブロックの最初の部分の .crt0 コード・セクションにジャンプします。crt0
コード・ブロックのファンクションは、次の項で詳しく説明します。
crt0 の初期化
crt0 コード・ブロックには、C または C++ アプリケーションの実行をイネーブルする
のに必要なソフトウェア命令の C ランタイム初期化コードが含まれています。crt0
コード・ブロックは、ユーザー定義のアセンブリ言語の手順でも同様に潜在的に使
用することができます。アルテラ提供の crt0 ブロックは、以下の初期化ステップを
実行します。
1. alt_load マクロの呼び出し — アプリケーションがフラッシュ・メモリ（.text セ
クションはフラッシュ・メモリから実行します）から実行するようにデザインさ
れている場合、残りのセクションは揮発性メモリにコピーされます。詳しくは、
2–26 ページの「ブート環境のコンフィギュレーション」を参照してください。
2. 命令キャッシュの初期化 — プロセッサが命令キャッシュを持っている場合、こ
のキャッシュは初期化されます。すべての命令キャッシュ・ラインは、initi 命
令と共にゼロになります（フラッシュせずに）
。
1
SOPC Builder は、プロセッサが命令キャッシュを持つこと、またこれらの
キャッシュをシステム生成時にコンフィギュレーションすることを決定し
ます。必要な場合、Nios II ソフトウェア・ビルド・ツールは、命令キャッ
シュ初期化のコード・ブロックを挿入します。
3. データ・キャッシュの初期化 — プロセッサがデータ・キャッシュを持っている
場合、このキャッシュは初期化されます。すべてのデータ・キャッシュ・ライン
は、initd 命令と共にゼロになります（フラッシュせずに）。命令キャッシュのよ
うに、このコードは、プロセッサがデータ・キャッシュを持っている場合にイ
ネーブルされます。
4. スタック・ポインタの設定 — スタック・ポインタは初期化されます。ユーザー
は、スタック・ポインタ・アドレスを設定することができます。詳しくは、2–54
ページの「HAL のリンク動作」を参照してください。
5. .bss セクションのクリア —.bss セクションは、すべてゼロに初期化されます。
ユーザーは、.bss セクション・アドレスを設定することができます。詳しくは、
2–54 ページの「HAL のリンク動作」を参照してください。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
ハードウェア・アブストラクション・レイヤ（HAL）を使用した開発
2‒29
6. スタック・オーバーフロー保護の初期化 — スタック・オーバーフロー・チェッ
クは、初期化されます。詳しくは、2–21 ページの「Eclipse 用の Nios II ソフト
ウェア・ビルド・ツールでのソフトウェアのデバッグ」を参照してください。
7. alt_main() へのジャンプ — プロセッサは、HAL BSP ランタイム・ライブラリの
初期化を開始する alt_main() ファンクションにジャンプします。
1
BSP ライブラリ・ファイルにサードパーティの RTOS または環境を使用する
場合、alt_main() ファンクションは、Nios II EDS によって提供されるもの
と異なる可能性があります。
サードパーティのコンパイラまたはライブラリを使用する場合、C ランタイム初期
化の動作は、この説明と異なる可能性があります。
crt0 コードには、デザインのハードウェア・シミュレーションを実行する場合のみ
に初期化のショートカットが含まれています。ユーザーは、
hal.enable_sim_optimizeのオンまたはオフへの切り替えによってこれらの最適化を
制御することができます。
f hal.enable_sim_optimize の BSP 設定について詳しくは、Nios II Software Developer's
Handbook の Nios II Software Build Tools Reference の章の「Settings Managed by the
Software Build Tools」を参照してください。
crt0.S のソース・ファイルは、
<Altera tools installation>/ip/altera/nios2_ip/altera_nios2/HAL/src ディレクトリにありま
す。
HAL の初期化
他の C プログラムのように、HAL の初期化の最初の部分は、Nios II プロセッサの
crt0.S ルーチンによって実装されます。詳しくは、2–28 ページの「crt0 の初期化」を
参照してください。crt0.S は、C ランタイム初期化の後に HAL BSP ランタイム・ラ
イブラリおよびサブシステムを初期化する HAL alt_main() ファンクションを呼び出
します。
HAL alt_main() ファンクションは、以下のステップを実行します。
1. 割り込みの初期化 —Nios II プロセッサ用の割り込みサポートを設定します
（alt_irq_init() ファンクションと共に）。
2. MicroC/OS-II の開始 — この RTOS が実行のためにコンフィギュレーションされる
場合、MicroC/OS-II RTOS を開始します（ALT_OS_INIT および ALT_SEM_CREATE
ファンクションと共に）。MicroC/OS-II の使用および初期化について詳しくは、
2–10 ページの「オペレーティング・システムの選択（HAL 対 MicroC/OS-II RTOS）
」
を参照してください。
3. デバイス・ドライバの初期化 — デバイス・ドライバを初期化します
（alt_sys_init() ファンクションと共に）。Nios II ソフトウェア・ビルド・ツール
は、HAL でサポートされるすべてのペリフェラルを自動的に見つけて、
alt_sys_init() コードの各ペリフェラル用のデバイス・コンフィギュレーショ
ン・ファンクションへの呼び出しを自動的に挿入します。この動作をオーバーラ
イドするために、Drivers タブの Nios II BSP エディタを使用してデバイス・ドライ
バをディセーブルすることができます。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒30
第 2 章 : Nios II ソフトウェアの開発
ハードウェア・アブストラクション・レイヤ（HAL）を使用した開発
f デバイス・ドライバのイネーブルおよびディセーブルについて詳しくは、
Nios II Software Developer's Handbook の Getting Started with the Graphical User
Interface の章の「Using the BSP Editor」を参照してください。
Nios II コマンド・シェルからドライバをディセーブルするには、nios2-bsp スクリ
プトに対して以下のオプションを使用します。
--cmd set_driver <peripheral_name> none
デバイス・コンフィギュレーション・ファンクションの削除について、および
BSP ライブラリ・サイズを低減させる他の方法について詳しくは、2–53 ページの
表 2–1 を参照してください。
4. stdio ファンクションのコンフィギュレーション —stdin、stderr、および
stdout 用の stdio サービスを初期化します。これらのサービスによって、アプリ
ケーションは GNU の newlib stdio ファンクションを使用することが可能となり、
サポートされているキャラクタ・デバイスにファイル・ポインタをマップしま
す。stdio サービスのコンフィギュレーションについて詳しくは、2–34 ページの
「キャラクタ・モード・デバイス」を参照してください。
5. C++ CTORS および DTORS の初期化 —C++ コンストラクタおよびデストラクタの
ファンクションの初期化を処理します。アプリケーションが C++ プログラミング
言語で書き込まれている場合、これらのファンクション・コールが必要です。デ
フォルトの状態では、HAL コンフィギュレーションのメカニズムは、C++ プログ
ラミング言語のサポートをイネーブルします。2–47 ページの「アプリケーション
の最適化」で説明しているように、この機能のディセーブルによってアプリケー
ションのコード・フットプリントは低減されます。
1
Nios II C++ 言語サポートは、GCC ツール・チェインによって決まります。
Nios II GCC 4 C++ ツール・チェインは、ポリモーフィズム、フレンドシップ
およびインヘリタンス、マルチプル・インヘリタンス、バーチャル・ベー
、mutable タイプ・クオリ
ス・クラス、ランタイム・タイプ情報（typeid）
ファイヤ、ネームスペース、テンプレート、新規および削除スタイル・ダ
イナミック・メモリ割り当て、オペレータ・オーバーローディング、およ
び標準テンプレート・ライブラリ（STL）をサポートします。例外および
新規スタイル・ダイナミック・キャストはサポートされません。
6. main() の呼び出し — ファンクションの main()、またはアプリケーション・プロ
グラムを呼び出します。ほとんどのアプリケーションは、main() ファンクション
宣言を使用して構築されており、このファンクションで実行を開始します。
1
HAL に基づいておらずcrt0.Sルーチン動作の後に初期化する必要のあるBSP を使用す
る場合、ユーザー自身の alt_main() ファンクションを定義します。例えば、
<Nios II EDS install dir>\examples\software\hello_alt_main の hello_alt_main.c ファイルに
ある main() および alt_main() のファンクションを参照してください。
BSP プロジェクトの生成の後、alt_main.c ソース・ファイルは HAL/src ディレクトリ
にあります。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
ハードウェア・アブストラクション・レイヤ（HAL）を使用した開発
2‒31
HAL ペリフェラル・サービス
HAL は、標準的にはサービスをサポートするハードウェア・ペリフェラルの存在に
応じて一連のサービスをアプリケーションに提供します。デフォルトの状態では、
nios2-bsp スクリプトの実行によってコマンドラインから HAL BSP プロジェクトをコ
ンフィギュレーションする場合、システムの各ペリフェラルは初期化されて、動作
状態となり、C/C++ アプリケーション（main()）のエントリ・ポイントでのサービス
として使用可能となります。
この項では、アプリケーション用として提供される一連のアルテラ提供のコア、HAL
アクセス可能なペリフェラルおよびサービスについて説明します。また、提供され
るサービスを使用するための適切なアプリケーション・デザイン・ガイドライン、
バックグラウンドおよびコンフィギュレーション情報についても説明します。
f HAL ペリフェラル・サービスについて詳しくは、Nios II Software Developer's Handbook
の Developing Programs Using the Hardware Abstraction Layer の章を参照してください。
HAL BSP コンフィギュレーション設定について詳しくは、Nios II Software Developer's
Handbook の Nios II Software Build Tools Reference の章を参照してください。
タイマ
HAL は、システム・クロック・タイマおよびタイムスタンプ・タイマの 2 つのタイ
プのタイマ・サービスを提供します。システム・クロック・タイマは、システムイ
ベントを制御、モニタ、およびスケジュールするために使用されます。タイムスタ
ンプ・バリアントは、タイミング測定のパフォーマンスを向上させるために使用さ
れます。これらの各タイマ・サービスは、それぞれシングル・アルテラ Avalon タイ
マ・ペリフェラルに割り当てられます。
f このペリフェラルについて詳しくは、Embedded Peripherals IP User GuideのInterval Timer
Core の章を参照してください。
システム・クロック・タイマ
システム・クロック・タイマ・リソースは、周期的イベント（アラーム）をトリガ
するために使用され、また、システム・クロック・チック数をカウントするタイム・
キーピング・デバイスとして使用されます。システム・クロック・タイマ・サービ
スは、タイマ・ペリフェラルが SOPC Builder システムに存在していることを必要とし
ます。このタイマ・ペリフェラルは、HAL システムのクロック・タイマ・サービス
専用である必要があります。
1
1 つのシステム・クロック・タイマ・サービスのみが BSP ライブラリで識別される可
能性があります。このタイマは、HAL 提供のルーチンのみによってアクセスされる
必要があります。
hal.sys_clk_timer 設定は、システム・クロック・タイマ用の BSP プロジェクト・コ
ンフィギュレーションを制御します。この設定は、SOPC Builder デザインでシステ
ム・クロック・タイマとして使用可能なタイマのうち 1 つをコンフィギュレーショ
ンします。
アルテラは、アプリケーション・レベルのシステム・クロック機能用およびアラー
ム生成用に独立した API を提供します。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒32
第 2 章 : Nios II ソフトウェアの開発
ハードウェア・アブストラクション・レイヤ（HAL）を使用した開発
アプリケーション・レベルのシステム・クロック機能は、Nios II 特有のクラスおよ
び他の Unix のようなクラスの 2 つの独立した API のクラスによって提供されます。
アルテラのファンクションの alt_nticks は、経過したクロック・チック数を返しま
す。alt_ticks_per_second() ファンクションによって返された値で除算することに
より、この値を秒に換算することができます。ほとんどのエンベデッド・アプリ
ケーションでは、このファンクションは初歩のタイム・キーピングに十分です。
POSIX のような gettimeofday() ファンクションは、HAL では Unix ワークステーショ
ンでの動作と異なる動作をします。ワークステーションでは、バッテリーのバック
アップを使用して、リアルタイム・クロックのこのファンクションは、値ゼロが
1970 年 1 月 1 日の 00:00 と表示される世界標準時（UTC）の絶対時間値を返します。
一方 HAL では、このファンクションは、システムのパワー・アップの時点から測定
を開始する時間値を返します。デフォルトの状態では、ファンクションは、システ
ムのパワーアップが 1970 年 1 月 1 日になされたものと仮定します。HAL の
gettimeofday() の応答を訂正するためには、settimeofday() ファンクションを使用
します。times() ファンクションは、同じ動作の違いを示します。
システム・クロック・タイマを実装する前に、以下の共通する問題および重要な点
を考えてください。
■
システム・クロックの分解能 — タイマの周期値は、HAL BSP プロジェクトがシス
テム・クロック・カウンタ用の内部変数をインクリメントするときのレートを指
定します。システム・クロックのインクリメントがアプリケーションにとって極
めて遅い場合、ユーザーは SOPC Builder のタイマ周期を短くすることができます。
■
ロールオーバー — システム・クロックのカウント数（リセット以降のカウント
数）を格納する内部のグローバル変数は、32 ビットの符号なし整数です。ロール
オーバー保護は、この変数に提供されません。そのため、ユーザーは、システム
でロールオーバー・イベントが起きる時刻、およびそれに応じてアプリケーショ
ンを計画する時刻を計算する必要があります。
■
パフォーマンスに与える影響 — すべてのクロック・チック数は、割り込みサービ
ス・ルーチンの実行の原因になります。このルーチンの実行は、マイナーなパ
フォーマンス低下をもたらします。システム・ハードウェアが短いタイマ周期を
指定する場合、累積割り込みレイテンシは、システム・パフォーマンス全体に影
響を与える可能性があります。
アラーム API によって、ユーザーは、アラーム・クロックの動作と同じ方法でシス
テム・クロック・タイマに基づいてイベントをスケジュールすることができるよう
になります。API は、アラームを登録する alt_alarm_start() ファンクション、およ
び登録されたアラームをディセーブルする alt_alarm_stop() ファンクションで構成
されています。
アラームを実装する前に、以下の一般的な問題および重要な点を考えてください。
■
割り込みサービス・ルーチン（ISR）コンテクスト — 割り込みのイネーブルに応
じたサービスを呼び出すためにアラーム・コールバック・ファンクションをプロ
グラムすることは、よくある間違いです（printf() ファンクションなど）。この
間違いは、割り込みがディセーブルしている時にアラーム・コールバック・ファ
ンクションが割り込みコンテクストで起きるために、システムがデッドロックす
る原因となります。
■
アラームのリセット — コールバック・ファンクションは、ゼロ以外の値を返すこ
とでアラームをリセットすることができます。内部では、alt_alarm_start()
ファンクションは、この値と共にコールバック・ファンクションによって呼び出
されます。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
ハードウェア・アブストラクション・レイヤ（HAL）を使用した開発
1
2‒33
■
チェイン —alt_alarm_start() ファンクションは、登録された 1 つ以上のイベント
を、アラームへのコールバック・ファンクションおよびシステム・クロック・
チック数を使用してイベント毎に処理することができます。
■
ロールオーバー — アラーム API は、登録されたアラーム用のクロックのロール
オーバー状態をシームレスに処理します。
ほとんどのエンベデッド・システムにとって良好なタイマ周期は、50 ms です。この
値は、ほとんどのシステム・イベントにとって十分な分解能を与えますが、パ
フォーマンスに深刻な影響を与えることはなく、また、極端に速いシステム・ク
ロック・カウンタをロールオーバーすることもありません。
タイムスタンプ・タイマ
タイムスタンプ・タイマは、システム内のイベントの継続期間を測定する精度のよ
い方法をアプリケーションに提供します。タイムスタンプ・タイマ・サービスは、
タイマ・ペリフェラルが SOPC Builder システム内に存在することを必要とします。こ
のタイマ・ペリフェラルは、HAL のタイムスタンプ・タイマ・サービス専用である
必要があります。
1
BSP ライブラリ・ファイルでは、1 つのタイムスタンプ・タイマ・サービスのみ識別
する可能性があります。このタイマは、HAL 提供のルーチンのみによってアクセス
される必要があります。
hal.timestamp_timer 設定は、タイマ用の BSP コンフィギュレーションを制御しま
す。この設定は、SOPC Builder デザイン内でタイムスタンプ・タイマとして使用可能
なタイマのうち 1 つをコンフィギュレーションします。
アルテラは、タイムスタンプ API を提供しています。タイムスタンプ API は、非常に
シンプルです。これには、タイマを動作状態にする alt_timestamp_start() ファン
クション、および現在のタイマ・カウント数を返す alt_timestamp() ファンクショ
ンが含まれています。
タイムスタンプ・タイマを実装する前に、以下の一般的な問題と重要な点を考えて
ください。
■
タイマ周波数 — タイムスタンプ・タイマは、SOPC Builder システムに供給されるク
ロックのクロック・レートを減分します。ユーザーは、SOPC Builder でこの周波
数を変更することができます。
■
ロールオーバー — タイムスタンプ・タイマには、ロールオーバー・イベントがあ
りません。alt_timestamp() ファンクションが値ゼロを返す場合、タイマはラ
ン・ダウンしたことを意味します。
■
最長時間 — タイマ・ペリフェラルは、タイマの値の格納に使用可能な 32 ビットを
持っています。したがって、タイムスタンプ・タイマがカウントできる最長の継
続時間は、（(1/timer frequency) × 232）秒です。
f タイムスタンプおよびシステム・クロック・タイマのサービスを制御する API につい
て詳しくは、Nios II Software Developer's Handbook の HAL API Reference の章を参照して
ください。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒34
第 2 章 : Nios II ソフトウェアの開発
ハードウェア・アブストラクション・レイヤ（HAL）を使用した開発
キャラクタ・モード・デバイス
stdin、stdout、および stderr
HAL は、GNU newlib ライブラリで提供される stdio ファンクションをサポートする
ことができます。stdio ライブラリを使用することによって、printf() および
scanf() などのファンクションを使用してアプリケーションと通信することができま
す。
現在では、アルテラは、stdio ライブラリ、UART および JTAG UART のコンポーネン
トをサポートすることが可能な 2 つのシステム・コンポーネントを提供しています。
これらのデバイスは、標準 I/O デバイスとして機能させることができます。
この機能をイネーブルするには、Nios II BSP のコンフィギュレーション中
に--default_stdio <device> オプションを使用します。また、stdin キャラクタ入
力ファイルの変数、stdout および stderr キャラクタ出力ファイルの変数も、HAL
BSP 設定の hal.stdin、hal.stdout、および hal.stderr を使用して個別にコンフィ
ギュレーションすることができます。
使用する stdin、stdout、および stderr ファイルのそれぞれの変数に、ユーザーが
個別に値を割り当てることを確認してください。
stdin、stdout、および stderr ファイルの変数を使用するために UART または JTAG
UART ペリフェラルを使用してターゲットのシステムをコンフィギュレーションした
後、ユーザーは、Nios II EDS 開発ツールを使用してターゲットの Nios II システムと通
信することができます。このタスクの実行について詳しくは、2–20 ページの「ター
ゲットとの通信」を参照してください。
f --default_stdio <device> オプションについて詳しくは、Nios II Software
Developer's Handbook の Nios II Software Build Tools Reference の章の「Nios II Software
Build Tools Utilities」を参照してください。
I/O のブロッキングとノン・ブロッキング
キャラクタ・モード・デバイスは、ブロッキング・モードまたはノン・ブロッキン
グ・モードで動作するためにコンフィギュレーションすることができます。モード
は、デバイスのファイル・ディスクリプタで指定されます。ブロッキング・モード
では、デバイスから読み出すためのファンクション・コールは、デバイスが新しい
データを受信するまで待機します。ノン・ブロッキング・モードでは、新しいデー
タを読み出すためのファンクション・コールは、すぐに返され、新しいデータが受
信されたかどうか通知します。ユーザーがファイル動作を読み出すために使用する
ファンクションに応じて、エラー・コードが返されて新しいデータが到着している
かどうか特定します。
UART および JTAG UART のコンポーネントは、ブロッキング・モードで初期化されま
す。しかし、各コンポーネントでは、fnctl または ioctl() ファンクションを使用し
てノン・ブロッキングを作成することが可能です。以下の open システム・コールに
示す通り、これは、開いているデバイスがノン・ブロッキング・モードで機能する
ように指定します。
fd = open ("/dev/<your uart name>", O_NONBLOCK | O_RDWR);
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
ハードウェア・アブストラクション・レイヤ（HAL）を使用した開発
2‒35
例 2–5 に示す fnctl() システム・コールは、既に開いているデバイスがノン・ブ
ロッキング・モードで機能することを指定します。
例 2‒5. fnctl() システム・コール
/* You can specify <file_descriptor> to be
* STDIN_FILENO, STDOUT_FILENO, or STDERR_FILENO
* if you are using STDIO
*/
fnctl(<file_descriptor>, F_SETFL, O_NONBLOCK);
例 2–6 のコードの一部分は、ノン・ブロッキング・デバイスの使用を示しています。
例 2‒6. ノン・ブロッキング・デバイスのコードの一部分
input_chars[128];
return_chars = scanf("%128s", &input_chars);
if(return_chars == 0)
{
if(errno != EWOULDBLOCK)
{
/* check other errnos */
}
}
else
{
/* process received characters */
}
また、UART および JTAG UART のペリフェラルの動作も、ioctl() ファンクション・
コールを使用して変更することができます。ioctl() ファンクションは、以下のパラ
メータをサポートします。
■
■
UART ペリフェラル用
■
TIOCMGET（UART のボー・レートを通知します）
■
TIOCMSET（UART のボー・レートを設定します）
JTAG UART ペリフェラル用
■
TIOCSTIMEOUT（ワークステーションへの接続のタイムアウト値）
■
TIOCGCONNECTED（ホストが接続されているかどうか検出します）
altera_avalon_uart_driver.enable_ioctl の BSP 設定は、UART ペリフェラル用の
ioctl() ファンクションをイネーブルおよびディセーブルします。ioctl() ファンク
ションは、JTAG UART ペリフェラルに自動的にイネーブルされます。
1
ioctl() ファンクションは、altera_avalon_uart_driver.enable_small_driver およ
び hal.enable_reduced_driver の BSP 設定とは互換性がありません。これらの設定
のうちいずれか一方がイネーブルされる場合、ioctl() は実装されません。
ユーザー独自のキャラクタ・モード・デバイスの追加
キャラクタ・モード動作が可能なカスタム・デバイスを持っている場合、ユーザー
は、stdio ライブラリ・ファンクションで使用することができるカスタム・デバイ
ス・ドライバを作成することができます。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒36
第 2 章 : Nios II ソフトウェアの開発
ハードウェア・アブストラクション・レイヤ（HAL）を使用した開発
f デバイス・ドライバの開発方法について詳しくは、AN459: Guidelines for Developing a
Nios II HAL Device Driver を参照してください。
フラッシュ・メモリ・デバイス
HAL BSP ライブラリは、パラレル・コモン・フラッシュ・インタフェース（CFI）メ
モリ・デバイスおよびアルテラの EPCS（消去可能、プログラム可能、コンフィギュ
レーション可能なシリアル）フラッシュ・メモリ・デバイスをサポートします。統
一 API は、リード、ライトおよび消去の機能を提供する両方のフラッシュ・メモリ・
タイプに使用可能です。
メモリの初期化、照会、およびデバイスのサポート
すべてのフラッシュ・メモリ・デバイスは、管理に必要なフラッシュ・メモリおよ
びファンクションの種類を決定するためにシステム初期化中に HAL によって照会さ
れます。このプロセスは、デバイス・ドライバが明示的に省略されずに小さなドラ
イバ・コンフィギュレーションが設定されていない場合、alt_sys_init() ファンク
ションによって自動的に実行します。
初期化の後、ユーザーは、ステータス情報用のフラッシュ・メモリを
alt_flash_get_flash_info() ファンクションを使用して照会することができます。
このファンクションは、フラッシュ領域構造（struct flash_region タイプの C 構
造）の矢印へのポインタ、およびフラッシュ・デバイス上の領域の数を返します。
1
struct flash_region 構造について詳しくは、BSP プロジェクト・ディレクトリの
ソース・ファイルの HAL/inc/sys/alt_flash_types.h を参照してください。
フラッシュ・メモリへのアクセス
alt_flash_open() ファンクションは、フラッシュ・メモリ・デバイスを開いて、フ
ラッシュ・メモリ・デバイス用のディスクリプタに返します。フラッシュ・メモリ
への読み出しおよび書き込みが完了した後、フラッシュ・メモリを安全に閉じるた
めに alt_flash_close() ファンクションを呼び出します。
HAL フラッシュ・メモリ・デバイス・モデルは、シンプルなものおよびきめ細やか
なものを 1 つずつ、所望の 2 つのフラッシュ・アクセス API を提供します。シンプ
ルな API は、必要に応じてセクタを消去して、データのバッファを取り込み、それ
をフラッシュ・メモリ・デバイスに書き込みます。きめ細やかな API は、ブロック
ごとのフラッシュ・デバイスの管理を可能にします。
両方の API は、システム内で使用することができます。ユーザーが格納するデータ
のタイプによって、アプリケーションにとって最も便利な API が決定されます。以
下の一般的なデザイン・ガイドラインは、ユーザーのデータ・ストレージの必要性
に応じて使用する API を決定する上で役立ちます。
シンプルな API— この API は、正確なフラッシュ・セクタの位置が重要ではない場
合、バイトの任意のストリームを格納する上で便利です。このタイプのデータの例
は、ランタイム中にシステムによって生成されるログまたはデータのファイルです。
これらのファイルは、後でフラッシュ・メモリ内のどこかに連続ストリームでアク
セスされる必要があります。
きめ細やかな API— この API は、絶対セクタ境界上にアラインメントする必要がある
データのユニットまたはデータ・セットを格納する上で便利です。このタイプの
データの例には、与えられたフラッシュ・セクタに格納されてアクセスされる必要
がある永続的なユーザーのコンフィギュレーション値、FPGA ハードウェア・イメー
ジ、およびアプリケーション・イメージが含まれています。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
ハードウェア・アブストラクション・レイヤ（HAL）を使用した開発
2‒37
f NAPI の使用を示す例について詳しくは、Nios II Software Developer's Handbook の
Developing Programs Using the Hardware Abstraction Layer の章の「Using Flash Devices」を
参照してください。
コンフィギュレーションおよび使用の制限
システム内でフラッシュ・メモリを使用する場合、このメモリの以下の機能を理解
する必要があります。
■
コード・ストレージ — アプリケーションが直接フラッシュ・メモリからコードを
実行する場合、フラッシュ操作ファンクションはディセーブルされます。この設
定は、実行中のコードを保持するメモリをプロセッサが消去するのを回避しま
す。この場合、ALT_TEXT_DEVICE, ALT_RODATA_DEVICE、および
ALT_EXCEPTIONS_DEVICE のすべてのシンボルは、フラッシュ・メモリ・ペリフェ
ラルとは異なる値を持つ必要があります（これらの #define の各シンボルは、メ
モリ・デバイスの中のアドレスではなくメモリ・デバイスを命名することに注意
してください）。
■
小さなドライバ — 小さなドライバのフラグがソフトウェア用に設定されている場
合（hal.enable_reduced_device_drivers の設定がイネーブルされている場合）、
フラッシュ・メモリ・ペリフェラルは自動的に初期化されます。この場合、アプ
リケーションは、明示的に初期化ルーチンを呼び出す必要があります。
■
スレッド・セーフティ — フラッシュ・アクセス・ルーチンのほとんどは、スレッ
ド・セーフではありません。これらのルーチンを使用する場合、システムの 1 つ
のスレッドのみがこれらのファンクションにアクセスできるようにアプリケー
ションを構築します。
■
EPCS フラッシュ・メモリ制限 — アルテラの EPCS メモリは、シリアル・インタ
フェースを持っています。そのため、Nios II の命令を実行することはできず、ま
た、標準ランダム・アクセス・メモリ・デバイスとして Nios II プロセッサを確認
することはできません。このデバイスからデータを読み出すには、アルテラ提供
のフラッシュ・メモリ・アクセス・ルーチンを使用します。
■
ファイル・システム —HAL フラッシュ・メモリ API は、旧式のファイル処理を使用
してデータを格納して保持することができるフラッシュ・ファイル・システムを
サポートしません。しかし、リード・オンリー zip ファイル・システムおよび
Nios II フラッシュ・プログラマ・ユーティリティを使用して、アプリケーション
を実行する前にフラッシュ・メモリ内のデータを格納することができます。リー
ド・オンリー zip ファイル・システムについて詳しくは、2–42 ページの「リー
ド・オンリー Zip ファイル・システム」を参照してください。
f フラッシュ・メモリのコンフィギュレーションおよび使用の制限について詳しくは、
Nios II Software Developer's Handbook の Developing Programs Using the Hardware
Abstraction Layer の章の「Using Flash Devices」を参照してください。フラッシュ・メ
モリ・アクセス・ルーチン用の API について詳しくは、Nios II Software Developer’s
Handbook の HAL API Reference の章を参照してください。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒38
第 2 章 : Nios II ソフトウェアの開発
ハードウェア・アブストラクション・レイヤ（HAL）を使用した開発
ダイレクト・メモリ・アクセス・デバイス
HAL のダイレクト・メモリ・アクセス（DMA）モジュールは、DMA 送信チャネルお
よび DMA 受信チャネルを使用します。DMA 動作は、チャネル上のトランザクショ
ン・リクエストを配置します。DMA ペリフェラルは、送信チャネル、受信チャネル、
またはそれらの両方を持つことができます。この項では、3 つの可能な DMA ペリ
フェラル用のハードウェア・コンフィギュレーションについて説明し、HAL メモリ・
アクセス・ファンクションを使用して DMA チャネルのそれぞれの種類をアクティブ
にする方法を示します。
DMA ペリフェラルは、alt_sys_init() ファンクション・コールによって初期化され
て、nios2-bsp スクリプトによって自動的にイネーブルされます。
DMA コンフィギュレーションおよび使用モデル
以下の例では、システムの DMA 送信チャネルおよび DMA 受信チャネルの使用につ
いて示します。ここでの情報は、Nios II Software Developer's Handbook の Developing
Programs Using the Hardware Abstraction Layer の章の「Using DMA Devices」を補完しま
す。
システム内の DMA ペリフェラル接続にかかわらず、alt_dma_txchan_open() ファン
クションの実行によって送信チャネルを初期化し、また、alt_dma_rxchan_open()
ファンクションの実行によって受信チャネルを初期化します。以下の項では、いく
つかの特定の場合での使用モデルを示します。
RX のみの DMA コンポーネント
標準的な RX のみの DMA コンポーネントは、別のコンポーネントから受信するデー
タをメモリに移動します。この場合、DMA ペリフェラルの受信チャネルは、他のペ
リフェラルのデータ・レジスタのメモリ内の固定位置から連続して読み出します。
以下に示す動作のシーケンスは、DMA ペリフェラルへの指示です。
1. DMA ペリフェラルを開く —alt_dma_rxchan_open() ファンクションを呼び出し
て、受信 DMA チャネルを開きます。
2. DMA の ioctl 動作をイネーブルする —alt_dma_rxchan_ioctl() ファンクション
を呼び出して、ALT_DMA_RX_ONLY_ON フラグを設定します。
ALT_DMA_SET_MODE_<n> フラグを使用して、データ幅を設定して他のペリフェラ
ル・データ・レジスタに一致させます。
3. 実行する他のペリフェラルをコンフィギュレーションする —Nios II プロセッサ
は、データ・レジスタ内の新しいデータのロードを開始する他のペリフェラルを
コンフィギュレーションします。
4. DMA トランザクション・リクエストをキューする —alt_avalon_dma_prepare()
ファンクションを呼び出して DMA 動作を開始します。ファンクション・コール
では、トランザクションの完了時に、DMA 受信チャネル、他のペリフェラルの
データ・レジスタ・アドレス、転送するバイト数、および実行するコールバッ
ク・ファンクションを指定します。
TX のみの DMA コンポーネント
標準的な TX のみの DMA コンポーネントは、メモリから他のコンポーネントにデー
タを移動します。この場合、DMA ペリフェラルの送信チャネルは、他のペリフェラ
ルのデータ・レジスタのメモリ内の固定位置に連続して書き込みます。以下に示す
動作のシーケンスは、DMA ペリフェラルへの指示です。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
ハードウェア・アブストラクション・レイヤ（HAL）を使用した開発
2‒39
1. DMA ペリフェラルを開く —alt_dma_txchan_open() ファンクションを呼び出し
て、送信 DMA チャネルを開きます。
2. DMA の ioctl 動作をイネーブルする —alt_dma_txchan_ioctl() ファンクション
を呼び出して、ALT_DMA_TX_ONLY_ON フラグを設定します。
ALT_DMA_SET_MODE_<n> フラグを使用して、データ幅を設定して他のペリフェラ
ル・データ・レジスタに一致させます。
3. 実行する他のペリフェラルをコンフィギュレーションする —Nios II プロセッサ
は、データ・レジスタ内の新しいデータのロードを開始する他のペリフェラルを
コンフィギュレーションします。
4. DMA トランザクション・リクエストをキューする —alt_avalon_dma_send()
ファンクションを呼び出して DMA 動作を開始します。ファンクション・コール
では、トランザクションの完了時に、DMA 送信チャネル、他のペリフェラルの
データ・レジスタ・アドレス、転送するバイト数、および実行するコールバッ
ク・ファンクションを指定します。
RX および TX の DMA コンポーネント
標準的な RX および TX の DMA コンポーネントは、メモリ・トゥ・メモリのコピー動
作を実行します。アプリケーションは、DMA チャネルを開いてコンフィギュレー
ションし、両方の DMA チャネルに明示的にトランザクション・リクエストを割り当
てる必要があります。以下に示す動作のシーケンスは、DMA ペリフェラルへの指示
です。
1. DMA RX チャネルを開く —alt_dma_rxchan_open() ファンクションを呼び出し、
DMA 受信チャネルを開きます。
2. DMA RX の ioctl 動作をイネーブルする —alt_dma_rxchan_ioctl() ファンク
ションを呼び出して、ALT_DMA_RX_ONLY_OFF フラグを設定します。
ALT_DMA_SET_MODE_<n> フラグを使用して、データ幅をメモリ転送用の正しい値に
設定します。
3. DMA TX チャネルを開く —alt_dma_txchan_open() ファンクションを呼び出して、
DMA 送信チャネルを開きます。
4. DMA TX の ioctl 動作をイネーブルする —alt_dma_txchan_ioctl() ファンクショ
ンを呼び出して、ALT_DMA_TX_ONLY_OFF フラグを設定します。
ALT_DMA_SET_MODE_<n> フラグを使用して、データ幅を転送メモリ用の正しい値に
設定します。
5. DMA RX トランザクション・リクエストをキューする —
alt_avalon_dma_prepare() ファンクションを呼び出して、DMA RX 動作を開始し
ます。ファンクション・コールでは、トランザクションの完了時に、DMA 受信
チャネル、読み出しを開始するアドレス、転送するバイト数、および実行する
コールバック・ファンクションを指定します。
6. DMA TX トランザクション・リクエストをキューする —alt_avalon_dma_send()
ファンクションを呼び出し、DMA TX 動作を開始します。ファンクション・コー
ルでは、トランザクションの完了時に、DMA 送信チャネル、書き込みを開始する
アドレス、転送するバイト数、および実行するコールバック・ファンクションを
指定します。
1
2011 年 7 月
DMA ペリフェラルは、DMA TX トランザクション・リクエストが発行されるまでトラ
ンザクションを開始しません。
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒40
第 2 章 : Nios II ソフトウェアの開発
ハードウェア・アブストラクション・レイヤ（HAL）を使用した開発
f DMA デバイス使用の例について詳しくは、Nios II Software Developer's Handbook の
Developing Programs Using the Hardware Abstraction Layer の章の「Using DMA Devices」を
参照してください。
DMA データ幅のパラメータ
DMA データ幅のパラメータは、サポートされる幅を指定するために SOPC Builder 内
でコンフィギュレーションされます。ソフトウェア・アプリケーションの書き込み
では、ユーザーは、特定のトランザクション用に使用する幅を指定する必要があり
ます。転送するデータの幅は、コンポーネントのハードウェア機能に一致させる必
要があります。
DMA ペリフェラルを実装する前に、データ幅パラメータについての以下の点を考え
てください。
■
ペリフェラル幅 —DMA コンポーネントが他のペリフェラルからデータを移動させ
る場合、DMA コンポーネントは、ペリフェラル・データ・レジスタと同じ幅のシ
ングル動作の転送サイズを使用する必要があります。
■
転送長 —DMA ペリフェラルに指定するバイト転送長は、指定される複数のデータ
幅である必要があります。
■
奇数転送サイズ —DMA コンポーネントを使用してメモリおよびペリフェラルの間
で奇数のバイト数を転送する必要がある場合、ユーザーは、データ転送の動作を
分割する必要があります。DMA コンポーネントで転送可能な最長のバイト数を実
装して、残りのバイトを Nios II プロセッサを使用して転送します。例えば、32
ビットのデータ・レジスタを使用してメモリからペリフェラルに 1023 バイトの
データを転送する必要がある場合、255 の 32 ビットを DMA を使用して転送を実
行して、その後、残りの 3 バイトを Nios II プロセッサを使用して書き込みます。
コンフィギュレーションおよび使用の制限
システムに DMA コンポーネントを使用する場合、これらのコンポーネントの以下の
機能を理解する必要があります。
■
ハードウェア・コンフィギュレーション —DMA ペリフェラルのハードウェア・コ
ンフィギュレーションの以下の側面によって、HAL サービスが決定されます。
■
メモリ以外のペリフェラルに接続される DMA コンポーネントは、HAL API の半
分のみをサポートします（受信または送信の機能）。アプリケーション・ソフ
トウェアが使用不可能な API ファンクションの呼び出しを試みないようにす
る必要があります。
■
DMA コンポーネントのハードウェアのパラメータ化では、アプリケーション・
ソフトウェアが考慮する必要がある値として転送データ幅が決定されます。
■
IOCTL 制御 —DMA の ioctl() ファンクション・コールは、シングル・フラグの設定
のみをイネーブルします。DMA チャネル用の複数のフラグを設定するには、ユー
ザーは、ioctl() を複数回呼び出す必要があります。
■
DMA トランザクション・スロット — 現在のドライバは、4 つのトランザクション・
スロットに制限されています。トランザクション・スロットの数を増やす必要が
ある場合、ユーザーはマクロ ALT_AVALON_DMA_NSLOTS を使用してスロットの数を
指定することができます。このマクロの値は、2 の累乗である必要があります。
■
割り込み —HAL DMA サービスは、DMA ペリフェラルの割り込みラインがシステム
内に接続されていることを必要とします。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
ハードウェア・アブストラクション・レイヤ（HAL）を使用した開発
■
2‒41
ユーザー制御の DMA アクセス — デフォルト状態の HAL DMA アクセス・ルーチがア
プリケーションにとって極めて扱いにくい場合、ユーザーは、独自のアクセス
ファン・クションを作成することができます。デフォルト状態の HAL DMA ドラ
イブ・ルーチンを削除する方法について詳しくは、2–52 ページの「コード・サイ
ズの低減」を参照してください。
f DMA ドライブへのアクセス用の HAL API について詳しくは、Nios II Software Developer's
Handbook の Developing Programs Using the Hardware Abstraction Layer の章の「Using DMA
Devices」、および Nios II Software Developer's Handbook の HAL API Reference の章を参照
してください。
ファイルおよびファイル・システム
HAL は、2 つのシンプルなファイル・システムおよびファイル・データを扱うための
1 つの API を提供します。HAL は、ファイルへのアクセスを提供するために、file.h
にある GNU newlib ライブラリのファイル・アクセス・ルーチンを使用します。更に、
HAL は、以下のファイル・システムを提供します。
■
ホスト・ベースのファイル・システム — ホスト・ワークステーションのファイ
ル・システムにアクセスするために Nios II システムをイネーブルします。
■
リード・オンリー zip ファイル・システム —Nios II システム・メモリ内のあらかじ
めコンフィギュレーションされたデータへのシンプルなアクセスをイネーブルし
ます。
f リードおよびライトの両方の動作をサポートするさらにいくつかの従来のファイル・
システムは、サードパーティ・ベンダを経由して使用可能です。Nios II プロセッサ
に使用可能なファイル・システム・ソリューションの最新情報について詳しくは、
アルテラ・ウェブサイトの Embedded Processing のページで Altera Embedded Alliance
Partners をクリックしてください。
アプリケーションに対するこれらのソフトウェア・パッケージのどちらかの機能を
確認するには、BSP 内でパッケージをイネーブルする必要があります。ユーザーは、
ソフトウェア・パッケージを BSP エディタ、またはコマンドラインからイネーブル
することができます。ホスト・ベースのファイル・システムおよびリード・オン
リー zip ファイル・システムのパッケージを指定する名前は、それぞれ
altera_hostfs および altera_ro_zipfs です。
ホスト・ベースのファイル・システム
ホスト・ベースのファイル・システムは、JTAG 接続を経由してワークステーション
上でファイルを操作するために、Nios II システムをイネーブルします。API は、デー
タ・ファイルにアクセスするための透過的な方法です。このシステムは、物理ブ
ロック・デバイスを必要としません。
これを使用する前に、ホスト・ベースのファイル・システムについて以下の点を考
えてください。
2011 年 7 月
■
通信スピード — このファイル・システムを使用した Nios II システムへの大規模
ファイルの読み出しおよび書き込みは、遅いです。
■
デバッグ使用モード —Nios II デバッグの観点から、ホスト・ベースのファイル・
システムは、デバッグ・セッション中のみに使用可能です。そのため、ホスト・
ベースのファイル・システムは、システム・デバッグおよびプロトタイピング動
作中のみに使用する必要があります。
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒42
第 2 章 : Nios II ソフトウェアの開発
ハードウェア・アブストラクション・レイヤ（HAL）を使用した開発
■
ダイレクト・ドライバとの非互換性 — ホスト・ベースのファイル・システムは、
ディセーブルされたダイレクト・ドライバ・モードを使用して HAL BSP ライブラ
リがコンフィギュレーションされる場合のみに動作します。しかし、このモード
のイネーブルによって、アプリケーション・イメージのサイズが低減します。詳
しくは、2–47 ページの「アプリケーションの最適化」を参照してください。
f ホスト・ファイル・システムについて詳しくは、Nios II Software Developer’s Handbook
の Developing Programs Using the Hardware Abstraction Layer の章の「Using File
Subsystems」を参照してください。
リード・オンリー Zip ファイル・システム
リード・オンリー zip ファイル・システムは、フラッシュ・メモリをターゲットにす
る Nios II プロセッサ用の軽量のファイル・システムです。
これを使用する前に、リード・オンリー zip ファイル・システムについての以下の点
を考えてください。
■
リード・オンリー — リード・オンリー zip ファイル・システムは、ファイル・シ
ステムへの書き込みを実装しません。
■
ファイル・システムのコンフィギュレーション — リード・オンリー zip ファイル・
システムを作成するには、ユーザーは、ワークステーション上でバイナリ・ファ
イルを作成して、Nios II フラッシュ・プログラマ・ユーティリティを使用して
Nios II システム内でそれをプログラムする必要があります。
■
ダイレクト・ドライバとの非互換性 — リード・オンリー zip ファイル・システム
は、ディセーブルされたダイレクト・ドライバ・モードを使用して HAL BSP ライ
ブラリがコンフィギュレーションされる場合のみに動作します。しかし、この
モードのイネーブルによって、アプリケーション・イメージのサイズが低減しま
す。詳しくは、2–47 ページの「アプリケーションの最適化」を参照してくださ
い。
f 詳しくは、Nios II Software Developer's Handbook の Read-Only Zip File System の章および
Developing Programs Using the Hardware Abstraction Layer の章、また、Nios II Software
Developer’s Handbook の Nios II Software Build Tools Reference の章の「Nios II Design
Example Scripts」に示されるリード・オンリー zip ファイル・システムの Nios II ソフ
トウェア・デザイン例を参照してください。
イーサネット・デバイス
イーサネット・デバイスは、HAL サービス・モデル用の特別なケースです。それら
をアプリケーションにアクセス可能にするために、これらのデバイスは、追加ソフ
トウェア・ライブラリの TCP/IP スタックを必要とします。アルテラは、NicheStack
と呼ばれる TCP/IP ネットワーキング・スタックを提供しています。これは、イーサ
ネット・ネットワークを介する通信用のソケット・ベースのインタフェースをアプ
リケーションに提供します。
f 詳しくは、Nios II Software Developer’s handbook の Ethernet and the NicheStack TCP/IP Stack
– Nios II Edition の章を参照してください。
ネットワーキングを使用するためにアプリケーションをイネーブルするには、BSP
ライブラリ内の NicheStack ソフトウェア・パッケージをイネーブルします。
NicheStack ソフトウェア・パッケージを指定する Tcl コマンド引数は、altera_iniche
です。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
ハードウェア・アブストラクション・レイヤ（HAL）を使用した開発
2‒43
非サポートのデバイス
HAL は、アルテラ提供のペリフェラル用の幅広いネイティブ・デバイス・サポート
を提供します。しかし、システムは、アルテラ提供ではないデバイスまたはペリ
フェラルを必要とすることがあります。この場合、以下の 2 つのオプションの一方
または両方が使用可能である可能性があります。
■
アルテラのサードパーティ・プログラムを経由してデバイスを得る。
■
ユーザー独自のデバイスを取り込む。
f アルテラのサードパーティ・プログラムの情報は、Nios II エンベデッド・ソフトウェ
ア・パートナのページで使用可能です。アルテラ・ウェブサイトの Embedded
Processing ページを参照し、Altera Embedded Alliance Partners をクリックしてくださ
い。
ユーザー独自のカスタム・ペリフェラルの取り込みは、2 段階のプロセスです。ま
ず、ユーザーはペリフェラルをハードウェアに取り込む必要があり、次にデバイス・
ドライバを開発する必要があります。
f 新規のペリフェラルをハードウェアに取り込む方法について詳しくは、Nios II
Hardware Development Tutorial を参照してください。デバイス・ドライバの開発方法に
ついて詳しくは、Nios II Software Developer's Handbook の Developing Device Drivers for
the Hardware Abstraction Layer の章、および AN459: Guidelines for Developing a Nios II HAL
Device Driver を参照してください。
Nios II プロセッサを使用したメモリへのアクセス
ペリフェラルおよびメモリへの読み出しと書き込みの時、データと命令キャッシュ
を正しく通信するために Nios II プロセッサをプログラムするソフトウェア・アプリ
ケーションを作成することが困難な場合があります。また、Nios II プロセッサ・コ
アのこれらの動作の処理にも、Nios II プロセッサ・コアから別のコアに移行する場
合に問題となる可能性のある微妙な違いがあります。
この項は、最も一般的な落とし穴を回避する上で役立ちます。ここでは、Nios II プ
ロセッサがどのようにペリフェラルおよびメモリを読み出して書き込むかというこ
とを理解する上で重要なバックグランドを説明し、これらのリードおよびライト動
作のプログラミングでのより一般的な問題を回避する助けとなる一連の命令と共に、
使用可能な一連のソフトウェア・ユーティリティを説明します。
一般的な C/C++ アプリケーションの作成
ユーザーは、プロセッサのリードおよびライト動作がデータ・キャッシュをバイパ
スするかどうかを心配せずに、ほとんどの C/C++ アプリケーションを書き込むこと
ができます。しかし、ユーザーは、以下のケースでは動作がデータ・キャッシュを
バイパスしないことを確認する必要があります。
2011 年 7 月
■
アプリケーションが、リードまたはライト・トランザクションが実際にペリフェ
ラルまたはメモリに達することを保証する必要がある場合。この保証は、例え
ば、デバイス・ドライバ割り込みサービス・ルーチンを正しく機能させる上で重
要です。
■
アプリケーションが、メモリのブロックを他のプロセッサまたは Avalon インタ
フェース・マスタ・ペリフェラルと共有する場合。
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒44
第 2 章 : Nios II ソフトウェアの開発
ハードウェア・アブストラクション・レイヤ（HAL）を使用した開発
ペリフェラルへのアクセス
アプリケーションがペリフェラル・レジスタにアクセスする場合、または小さな一
連のメモリ・アクセスのみを実行する場合、アルテラは、ユーザーがデフォルト状
態の HAL I/O マクロ、IORD および IOWR を使用することを推奨します。これらのマク
ロは、アクセスがデータ・キャッシュをバイパスすることを保証します。
1
2 つのタイプのキャッシュ・バイパス・マクロが使用可能です。_32DIRECT、_16
DIRECT、および _8 DIRECT という接尾辞の HAL アクセス・ルーチンは、オフセット
をバイト・アドレスとして認識します。他のルーチンは、Nios II プロセッサおよび
システム・インタコネクト・ファブリックの間の 32 ビット接続でのバイト数の 4 バ
イトで乗算されるカウントとしてこのオフセットを扱います。_32DIRECT、
_16DIRECT、および _8DIRECT のルーチンは、メモリ領域にアクセスするために、他
のルーチンはペリフェラル・レジスタにアクセスするためにデザインされます。
例 2–7 に、ハーフ・ワード値のシリーズをメモリの中に書き込む方法を示します。
ターゲット・アドレスがすべて 32 ビット境界上にあるわけではないため、このコー
ド・サンプルは IOWR_16DIRECT マクロを使用します。
例 2‒7. ハーフ・ワード位置の書き込み
/* Loop across 100 memory locations, writing 0xdead to */
/* every half word location... */
for(i=0, j=0;i<100;i++, j+=2)
{
IOWR_16DIRECT(MEM_START, j, (unsigned short)0xdead);
}
例 2–8 に、ペリフェラル・レジスタへのアクセス方法を示します。この場合、書き
込みは 32 ビット境界アドレスになされ、コード・サンプルは IOWR マクロを使用し
ます。
例 2‒8. ペリフェラル・レジスタ・アクセス
unsigned int control_reg_val = 0;
/* Read current control register value */
control_reg_val = IORD(BAR_BASE_ADDR, CONTROL_REG);
/* Enable "start" bit */
control_reg_val |= 0x01;
/* Write "start" bit to control register to start peripheral */
IOWR(BAR_BASE_ADDR, CONTROL_REG, control_reg_val);
1
アルテラは、外部ペリフェラルおよび外部メモリにアクセスする場合には HAL 提供の
マクロを使用することを推奨します。
非キャッシュ・メモリの共有
アプリケーションがいくつかのメモリを割り当ててそのメモリ上で動作し、その後
にメモリ領域を他のペリフェラル（またはプロセッサ）と共有する必要がある場合、
HAL 提供の alt_uncached_malloc() および alt_uncached_free() ファンクションを
使用します。これらの両方のファンクションは、キャッシュされたメモリをバイパ
スするポインタ上で動作します。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
ハードウェア・アブストラクション・レイヤ（HAL）を使用した開発
2‒45
非キャッシュ・メモリを Nios II プロセッサおよびペリフェラルの間で共有するには、
以下のステップを実行します。
1. malloc メモリ —alt_uncached_malloc() ファンクションを実行して、ヒープから
メモリのブロックを要求します。この動作が成功すると、ファンクションは、
データ・キャッシュをバイパスするポインタを返します。
2. メモリ上での動作 — ポインタを使用してメモリを読み出すまたは書き込む
Nios II プロセッサを使用します。アプリケーションは、このポインタ上で通常の
ポインタ演算動作を実行することができます。
3. ポインタの変換 —alt_remap_cached() ファンクションを実行して、ポインタを
外部ペリフェラルに認識されるメモリ・アドレスに変換します。
4. ポインタのパス — 変換されたポインタを外部ペリフェラルに渡して、メモリ領
域上で動作を実行できるようにそれをイネーブルします。
キャッシュ性能の利点を使用したメモリの共有
プロセッサのパフォーマンスを犠牲にすることなく、データ・キャッシュがイネー
ブルされた Nios II プロセッサおよび他の外部ペリフェラルの間でメモリを安全に共
有する他の方法は、遅延データ・キャッシュ・フラッシュ方法です。この方法では、
Nios II プロセッサは、標準的な C または C++ 動作を使用して、メモリが外部ペリ
フェラルと共有される必要があるまでメモリ上で動作を実行します。
1
アプリケーションは、外部マスタがメモリ上で動作できるようになる前に
alt_dcache_flush() ファンクションを実行する場合、非キャッシュのバイパスされ
たメモリ領域を外部マスタと共有することができます。
遅延データ・キャッシュ・フラッシュを実装する場合、アプリケーション・イメー
ジは、以下のこれらのステップに従って Nios II プロセッサをプログラムします。
1. プロセッサがメモリ上で動作する —Nios II プロセッサは、メモリ領域へのリード
およびライトを実行します。これらのリードおよびライトは、C/C++ ポインタ、
またはデータ構造、変数、またはメモリの malloc された領域へのアレイ・ベー
ス・アクセスまたはアクセスです。
2. プロセッサがキャッシュを消去する —Nios II プロセッサがリードまたはライト動
作を完了した後、Nios II プロセッサは、消去されるメモリ領域の位置および長さ
と共に alt_dcache_flush() 命令を呼び出します。その後、プロセッサは、この
メモリ上で動作する他のメモリ・マスタ・ペリフェラルを送信できるようになり
ます。
3. プロセッサがメモリ上で再び動作する — 他のペリフェラルが動作を完了してい
る場合、Nios II プロセッサは、メモリ上でもう一度動作することができます。
データ・キャッシュが以前に消去されているため、追加のリードまたはライト
は、キャッシュを正しく更新します。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒46
第 2 章 : Nios II ソフトウェアの開発
ハードウェア・アブストラクション・レイヤ（HAL）を使用した開発
例 2–9 に、構造の C アレイへのメモリ・アクセス用の遅延データ・キャッシュの消
去の実装について示します。この例では、Nios II は、アレイ中の各構造の 1 つの
フィールドを初期化し、データ・キャッシュを消去して、アレイを使用する可能性
のある他のマスタに送信し、他のマスタがアレイ上での動作を完了するのを待機し、
その後、他のマスタを設定すると期待されている値を合計します。
例 2‒9. 構造のアレイを使用したデータ・キャッシュの消去
struct input foo[100];
for(i=0;i<100;i++)
foo[i].input = i;
alt_dcache_flush(&foo, sizeof(struct input)*100);
signal_master(&foo);
for(i=0;i<100;i++)
sum += foo[i].output;
例 2–10 に、malloc() を使用して Nios II プロセッサが取得したメモリ領域へのメモ
リ・アクセス用の遅延データ・キャッシュ消去の実装について示します。
例 2‒10. malloc() によって取得したメモリを使用したデータ・キャッシュの消去
char * data = (char*)malloc(sizeof(char) * 1000);
write_operands(data);
alt_dcache_flush(data, sizeof(char) * 1000);
signal_master(data);
result = read_results(data);
free(data);
1
alt_dcache_flush_all() ファンクション・コールは、データ・キャッシュ全体を消
去しますが、このファンクションは効率がよくありません。アルテラは、他のマス
タ・ペリフェラルを使用可能にするメモリ領域のエントリのみをキャッシュから消
去することを推奨しています。
例外の処理
HAL インフラストラクチャは、堅牢な割り込み処理サービス・ルーチンおよび例外
処理用の API を提供します。Nios II プロセッサは、ハードウェア割り込み、未実装の
命令、およびソフトウェア・トラップによる例外を処理することができます。
1
この項では、Nios II 内部割込みコントローラを使用した例外処理について説明しま
す。また、Nios II プロセッサは、割り込みに優先順位をつけて他のパフォーマンス
を向上させるために使用することができる外部割込みコントローラ（EIC）をサポー
トします。
f EIC について詳しくは、Nios II Processor Reference Handbook の Programming Model の章
を参照してください。例外ハンドラ・ソフトウェア・ルーチン、HAL 提供のサービ
ス、API、およびソフトウェア・サポートについて詳しくは、Nios II Software
Developer's Handbook の Exception Handling の章を参照してください。
HAL 提供の例外ハンドラを使用する前に、次の一般的な問題および重要な点を考え
てください。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
アプリケーションの最適化
2‒47
■
割り込みの優先順位付け —Nios II プロセッサは、32 の割り込みベクタを優先順位
付けしませんが、HAL 例外ハンドラは低い番号の割り込みに高い優先順位を割り
当てます。ユーザーは、SOPC Builder 内のペリフェラルの割り込みリクエスト
（IRQ）の優先順位付けを変更する必要があります。
■
割り込みのネスティング —HAL インフラストラクチャは、割り込みをネストする
ことで、高い優先順位の割り込みが低い優先順位の割り込みにサービスする例外
ハンドラからのプロセッサ・コントロールを先取りできるようにします。しか
し、アルテラは、関連するパフォーマンス・ペナルティのため割り込みをネスト
しないことを推奨しています。
■
例外ハンドラ環境 — 例外ハンドラを作成する場合、ユーザーは、デッドロックを
引き起こす可能性のある割り込み依存ファンクションおよびサービスをハンドラ
が実行しないことを確認する必要があります。例えば、例外ハンドラは、
printf() ファンクションの IRQ でドライブするバージョンを呼び出してはいけま
せん。
例外ハンドラの変更
いくつかの非常に特殊なケースでは、既存の HAL 例外ハンドラ・ルーチンを変更す
る、または Nios II プロセッサ用の割り込みハンドラを挿入する場合があります。し
かし、ほとんどの場合、ユーザーは Nios II プロセッサ用の割り込みハンドラ・ルー
チンをソフトウェア・アプリケーション用に変更する必要はありません。
HAL 提供の例外ハンドラを変更または交換する前に、以下の一般的な問題および重
要な点を考えてください。
■
割り込みベクタ・アドレス — 各 Nios II プロセッサ用の割り込みベクタ・アドレス
は、FPGA デザインのコンパイル中に設定されます。SOPC Builder 内でのハード
ウェアのコンフィギュレーション中にそれを変更することができます。
■
例外ハンドラの変更 —HAL 提供の例外ハンドラは、非常に堅牢で信頼性が高く、
効率的です。例外ハンドラの変更は、HAL 提供の割り込み処理 API を破壊する可
能性があり、UART および JTAG UART などの割り込みを使用する他のペリフェラ
ル用のデバイス・ドライバ内で問題を発生させる可能性があります。
パフォーマンス全体を向上させるために、例外ハンドラの動作を変更する場合があ
ります。例外ハンドラのパフォーマンスを向上させるガイドラインについて詳しく
は、2–51 ページの「割り込みサービス・ルーチンのアクセラレーション」を参照し
てください。
アプリケーションの最適化
この項では、ソフトウェア・アプリケーションのパフォーマンスを向上させて、そ
のサイズを低減させる手法を説明します。
この項は、以下のサブセクションで構成されています。
■
2011 年 7 月
「パフォーマンス調整のバックグランド」
■
2–48 ページの「システム・プロセス処理タスクの迅速化」
■
2–51 ページの「割り込みサービス・ルーチンのアクセラレーション」
■
2–52 ページの「コード・サイズの低減」
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒48
第 2 章 : Nios II ソフトウェアの開発
アプリケーションの最適化
パフォーマンス調整のバックグランド
ソフトウェアのパフォーマンスとは、一定のタスクまたは一連のタスクをシステム
内で実行できるスピードのことです。ソフトウェアのパフォーマンスを向上させる
には、ユーザーは、必要な処理時間でのコード・セクションを最初に決定する必要
があります。
アプリケーションのタスクは、割り込みタスクおよびシステム処理タスクに分割す
ることができます。割り込みタスク性能とは、外部イベントまたは外部状態を処理
するためにプロセッサが割り込みサービス・ルーチンを完了するスピードのことで
す。システム処理タスク性能とは、システムがアプリケーション・コードで明示的
に記述されたタスクを実行するスピードのことです。
アプリケーションのパフォーマンスの完全な解析は、フットプリントと同じように、
ソフトウェア・イメージのシステム処理タスクおよび割り込みタスクのパフォーマ
ンスを決定します。
システム・プロセス処理タスクの迅速化
アプリケーションのパフォーマンスを向上させるために、実行するシステム処理タ
スクを迅速化できる方法を決定します。まず、現在のパフォーマンスを解析してシ
ステムで最も遅いタスクを識別し、その後、プロセッサ効率の向上、ハードウェア・
アクセラレータの作成、またはデータ移動のためのアプリケーションの方法の向上
によって、アプリケーションの任意部分をアクセラレーションできるかどうかを決
定します。
問題の解析
システム処理をアクセラレーションする最初のステップは、システム内で最も遅い
タスクを識別することです。アルテラは、アプリケーションをプロファイルするた
めの以下のツールを提供しています。
■
GNU プロファイラ —Nios II EDS ツールチェインには、GNU プロファイラを使用して
アプリケーションをプロファイリングする方法が含まれています。このプロファ
イリングの方法は、アプリケーションで様々なファンクションを実行する時間を
通知します。
■
高精度タイマ — インターバル・タイマ・ペリフェラルは、サブルーチンの実行に
与えられる時間を決定することができるシンプルなタイム・カウンタです。
■
パフォーマンス・カウンタ・ペリフェラル — パフォーマンス・カウンタ・ユニッ
トは、カウンタのコレクションを使用して、いくつかの異なるコード・セクショ
ンをプロファイルすることができます。このペリフェラルには、Nios II プロセッ
サの stdio サービスを経由してこれらのカウンタの結果を印刷できるようにする
シンプルなソフトウェア API が含まれています。
これらのツールを 1 つ以上使用して、アプリケーションが最も処理時間を費やすタ
スクを決定します。
f ソフトウェア・アプリケーションをプロファイルする方法について詳しくは、
AN391: Profiling Nios II Systems を参照してください。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
アプリケーションの最適化
2‒49
アプリケーションのアクセラレーション
この項では、アプリケーションをアクセラレーションするいくつかの手法を説明し
ます。FPGA の柔軟性のため、これらの手法のほとんどは、プロセッサ実行のパ
フォーマンスを向上させるためにシステム・ハードウェアを変更します。この項で
は、以下のパフォーマンス向上の手法を説明します。
■
プロセッサ効率を向上させる手法
■
ハードウェア・アクセラレータを使用してセレクト・ソフトウェア・アルゴリズ
ムをアクセラレーションする方法
■
DMA ペリフェラルを使用してシーケンシャル・データ移動動作の効率を向上させ
る方法
プロセッサ効率の向上
ソフトウェア・アプリケーションのパフォーマンスを向上させる簡単な方法は、ア
プリケーションが要求する命令の数を低減させるために、Nios II プロセッサの
フェッチおよびプロセス命令のレートを向上させることです。以下の手法によって、
アプリケーションの実行中にプロセッサの効率を向上させることができます。
■
プロセッサ・クロック周波数 —SOPC Builder を使用して、プロセッサ・クロック周
波数を変更します。プロセッサの実行スピードが速くなれば、命令の処理がより
迅速になります。
■
Nios IIプロセッサの改善—Nios IIプロセッサの最も効率のよいバージョンを選択し
て、適切にパラメータ化します。以下のプロセッサ設定は、SOPC Builder を使用
して変更することができます。
■
プロセッサ・タイプ — 可能な最速の Nios II プロセッサ・コアを選択します。最
高速から最低速へパフォーマンスの順に並べると、プロセッサには、Nios II/f、
Nios II/s、および Nios II/e のコアがあります。
■
命令およびデータ・キャッシュ — 特にコードの実行のために選択するメモリ
（アプリケーション・イメージおよびデータが格納されるメモリ）のアクセス
時間またはレイテンシが高速である場合、命令またはデータ・キャッシュが
含まれています。
■
マルチプライヤ — ハードウェア・マルチプライヤを使用して、関連する数学
的動作の効率を向上させます。
f プロセッサ・コンフィギュレーション・オプションについて詳しくは、
Nios II Processor Reference Handbook の Instantiating the Nios II Processor の章を
参照してください。
■
2011 年 7 月
Nios II の命令およびデータ・メモリのスピード — メイン・プログラムの実行用に
アクセス時間およびレイテンシが Low のメモリを選択します。メイン・プログラ
ムの実行用に選択するメモリは、特に Nios II キャッシュがイネーブルされていな
い場合、パフォーマンス全体に影響を与えます。Nios II プロセッサは、プログラ
ム命令およびデータをフェッチするときに停止します。
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒50
第 2 章 : Nios II ソフトウェアの開発
アプリケーションの最適化
■
密結合メモリ — メイン・プログラムの実行用に密結合メモリを選択します。密結
合メモリは、直接 Nios II プロセッサの命令パスまたはデータ・パス、あるいは両
方に接続されて、任意のキャッシュにバイパスする高速汎用メモリです。密結合
メモリへのアクセスは、キャッシュ・メモリへのアクセスと同じスピードになり
ます。密結合メモリは、シングル・サイクル・アクセス時間を保証する必要があ
ります。そのため、通常、これは FPGA メモリ・ブロックに実装されます。
f 密結合メモリについて詳しくは、Using Tightly Coupled Memory with the Nios II
Processor Tutorial および Nios II Software Developer's Handbook の Cache and
Tightly-Coupled Memory の章を参照してください。
■
コンパイラの設定 — より効率的なコードの実行は、コンパイラの最適化を使用す
ることで達成することができます。コンパイラの最適化の設定を最速の-03 まで
向上させて、より効率的なコードの実行を実現します。アプリケーション用の最
適化設定とは独立して、BSP プロジェクト用の C コンパイラの最適化設定を設定
します。
f BSP プロジェクトのコンパイラ最適化レベルのコンフィギュレーションに
ついて詳しくは、Nios II Software Developer’s Handbook の Nios II Software
Build Tools Reference の章の hal.make.bsp_cflags_optimization の BSP 設
定を参照してください。
ハードウェアのアクセラレーション
低速のソフトウェア・アルゴリズムは、カスタム命令の使用、専用のハードウェア・
アクセラレータ、および C-to-Hardware（C2H）コンパイラ・ツールの使用によってア
クセラレーションすることができます。以下の手法によって、アプリケーションの
実行中にプロセッサの効率を向上させることができます。
■
カスタム命令 — カスタム命令を使用して、タスク特有の演算動作をアクセラレー
ションするユーザー定義の専用ハードウェアのブロックと共に、Nios II プロセッ
サの演算およびロジック・ユニット（ALU）を機能強化します。このハードウェ
ア・アクセラレータは、アプリケーション・ソフトウェアで呼び出すことができ
るユーザー定義の動作コードに関連付けられています。
f カスタム命令の作成方法について詳しくは、Using Nios II Floating-Point
Custom Instructions Tutorial を参照してください。
■
ハードウェア・アクセラレータ —Nios II プロセッサとは独立して実行することが
できる一括処理動作用のハードウェア・アクセラレータを使用します。ハード
ウェア・アクセラレータは、特定のシステム・タスクの処理を高速化するために
デザインされたユーザー定義のカスタム・ペリフェラルです。これらは、Nios II
プロセッサとは独立して実行する動作の効率を向上させます。
f ハードウェア・アクセラレーションについて詳しくは、Embedded Design
Handbook の Hardware Acceleration and Coprocessing の章を参照してくださ
い。
■
C2H コンパイラ —C2H コンパイラを使用して、それらを専用ハードウェア・ブ
ロックに変換することで標準 ANSI C ファンクションをアクセラレーションしま
す。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
アプリケーションの最適化
2‒51
f C2H コンパイラについて詳しくは、Nios II C2H Compiler User Guide および
Embedded Design Handbook の Optimizing Nios II C2H Compiler Results の章を参
照してください。
データ移動の向上
アプリケーションが多くのシーケンシャル・データ移動動作を実行する場合、DMA
ペリフェラルは、これらの動作の効率を上げる可能性があります。アルテラは、以
下の 2 つの DMA ペリフェラルを提供しています。
■
DMA— プロセッサによってサービスが提供される前に単一の動作を実行すること
ができる、シンプルな DMA ペリフェラルです。DMA ペリフェラルの使用につい
て詳しくは、2–31 ページの「HAL ペリフェラル・サービス」を参照してくださ
い。
f DMA ペリフェラルについて詳しくは、Embedded Peripherals IP User Guide の
DMA Controller Core の章を参照してください。
■
Scatter-Gather DMA (SGDMA)— プロセッサによってサービスが提供される前に複数
の動作を実行することができる、ディスクリプタ・ベースの DMA ペリフェラル
です。
f 詳しくは、Embedded Peripherals IP User Guide の Scatter-Gather DMA Controller
Core の章を参照してください。
割り込みサービス・ルーチンのアクセラレーション
割り込みサービス・ルーチンの効率を向上させるには、実行するタスクをどのよう
に高速化させることができるか決定します。まず、現在のパフォーマンスを解析し
て、割り込みディスパッチおよびハンドラの時間の最低速の部分を特定し、その後、
割り込み処理の任意の部分をアクセラレーションできるかどうか決定します。
問題の解析
割り込みサービス・ルーチンによって消費される合計時間は、HAL 割り込みディス
パッチャのレイテンシおよび割り込みハンドラの実行時間の合計に等しくなります。
以下の方法を使用して、割り込みハンドラをプロファイルします。
■
割り込みディスパッチ時間 — アルテラの資料ページの Using Nios II Tightly Coupled
Memory Tutorial 付属のデザイン・ファイルにある方法を使用して、割り込みハン
ドラ・エントリ時間を計算します。
f アルテラ・ウェブサイトの Literature: Tutorials のページから、デザイン・
ファイルをダウンロードすることができます。
■
割り込みサービス・ルーチン時間 — タイマを使用して、エントリからサービス・
ルーチンの終了ポイントまでの時間を測定します。
割り込みサービス・ルーチンのアクセラレーション
次の手法によって、アプリケーションを実行しているときに割り込み処理の効率を
向上させることができます。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒52
第 2 章 : Nios II ソフトウェアの開発
アプリケーションの最適化
■
一般的なソフトウェア・パフォーマンスの機能強化 —ISR および ISR ハンドラに対
するアプリケーションのパフォーマンスを向上させる一般的な手法を適用しま
す。密結合メモリなどの高速メモリ領域に .exception コード・セクションを配
置します。
■
IRQ の優先順位 —ハードウェア割り込みに対して適切な優先順位を割り当てます。
割り込み優先順位を割り当てるための方法は、割り込みコントローラによって決
まります。
■
■
内部の割り込みコントローラを使用して、使用可能な最低番号に対するハー
ドウェア・デバイスの割り込み優先順位を設定します。HAL ISR サービス・
ルーチンは、最低番号の割り込みが最高の優先順位を持っているシステム・
ベースの優先順位を使用します。
■
外部の割り込みコントローラ（EIC）を使用して、優先順位のコンフィギュ
レーションのための方法は、ハードウェアによって決まります。詳しくは、
EIC の資料を参照してください。
カスタム命令および密結合メモリ — 割り込みベクタのカスタム命令および密結合
メモリの領域を使用することで、割り込みハンドラで費やされる時間を短縮しま
す。
f Nios II の例外ハンドラのパフォーマンスを向上させる方法について詳しくは、Nios II
Software Developer's Handbook の Exception Handling の章を参照してください。
コード・サイズの低減
アプリケーション・イメージで必要とされるメモリ・スペースを低減することも、
パフォーマンスの機能を強化することになります。この項では、コード・フットプ
リントを測定して低減する方法を説明します。
問題の解析
アプリケーションのコード・フットプリントを解析する最も簡単な方法は、GNU バ
イナリ・ユーティリティ・ツールの nios2-elf-size を使用することです。このツール
は、.text、.data、および .bss のコード・セッションの小計と同じように、コンパ
イルされた .elf のバイナリ・ファイルを解析してアプリケーションの合計サイズを
通知します。例 2–11 に、nios2-elf-size のコマンド応答を示します。
例 2‒11. nios2-elf-size コマンドの使用例
> nios2-elf-size -d application.elf
text data bss dec hex filename
203412 8288 4936 216636 34e3c application.elf
コード・フットプリントの低減
以下の方法は、コード・フットプリントを低減させる上で役立ちます。
■
コンパイラ・オプション —GCC 用の-Os フラグを設定することで、コード・サイズ
低減のためのサイズの最適化を適用するようにコンパイラに指示します。
hal.make.bsp_cflags_optimization の BSP 設定を使用して、このフラグを設定し
ます。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
アプリケーションのリンク
■
2‒53
HAL フットプリントの低減 —HAL BSP ライブラリ・コンフィギュレーション設定を
使用して、BSP ライブラリ・ファイルの HAL コンポーネントのサイズを低減させ
ます。しかし、HAL BSP ライブラリ用にサイズ低減の設定をイネーブルすると、
システムの柔軟性およびパフォーマンスに影響を与える場合がよくあります。
表 2–1 に、サイズの最適化のためのコンフィギュレーション設定を示します。シ
ステムでこれらの設定を可能な限り多く使用して、BSP ライブラリ・ファイルの
サイズを低減させます。
表 2‒1. ライブラリ・サイズを低減させるための BSP 設定
BSP 設定名
値
hal.max_file_descriptors
4
hal.enable_small_c_library
true
hal.sys_clk_timer
none
hal.timestamp_timer
none
hal.enable_exit
false
hal.enable_c_plus_plus
false
hal.enable_lightweight_device_driver_api
true
hal.enable_clean_exit
false
hal.enable_sim_optimize
false
hal.enable_reduced_device_drivers
true
hal.make.bsp_cflags_optimization
\"-Os\"
表 2–1 に示すように BSP 設定を調整することで、HAL フットプリントを低減させ
ることができます。
■
未使用の HAL デバイス・ドライバの削除 — アプリケーションで使用するシステ
ム・ペリフェラルのみへのサポートを使用して、HAL をコンフィギュレーション
します。
■
デフォルトの状態では、HAL コンフィギュレーションのメカニズムには、既存
のすべてのシステム・ペリフェラル用のデバイス・ドライバ・サポートが含
まれています。HAL デバイス・ドライバを使用してこれらすべてのペリフェ
ラルにアクセスするわけではない場合、ユーザーは、BSP プロジェクトをコ
ンフィギュレーションするときに set_driver コマンドを使用して、HAL BSP
ライブラリのコンフィギュレーション中にそれらの省略を選択できます。
■
HAL は、アプリケーションのフットプリント全体を向上させる NicheStack ネッ
トワーキング・スタックおよびリード・オンリー zip ファイル・システムなど
のさまざまなソフトウェア・モジュールを含めるためにコンフィギュレー
ションすることができます。しかし、HAL は、デフォルトの状態でこれらの
モジュールをイネーブルしません。
アプリケーションのリンク
この項では、デフォルトのリンカ・スクリプトを Nios II ソフトウェア開発ツールで
作成する方法を説明し、このスクリプトは何をどのようにしてそのデフォルトの動
作をオーバーライドするのか説明します。また、この項には、いくつかの一般的な
リンカの動作を制御する命令、およびそれらが必要となる可能性のある状況につい
ての説明が含まれています。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒54
第 2 章 : Nios II ソフトウェアの開発
アプリケーションのリンク
この項には、以下のサブセクションが含まれています。
■
「バックグランド」
■
「リンカ・セクションおよびアプリケーションのコンフィギュレーション」
■
「HAL のリンク動作」
バックグランド
プロジェクトを生成する場合、Nios II ソフトウェア・ビルド・ツールは、linker.x お
よび linker.h の 2 つのリンカ関連ファイルを生成します。linker.x は、生成されたア
プリケーションの makefile が .elf バイナリ・ファイルを作成するために使用するリン
カ・コマンド・ファイルです。HAL BSP プロジェクトに対するすべてのリンカ設定
の変更は、これらの 2 つのファイルの内容に影響を与えます。
リンカ・セクションおよびアプリケーションのコンフィギュレーション
すべての Nios II アプリケーションには、.text、.rodata、.rwdata、.bss、.heap、
および .stack セクションが含まれています。追加のセクションは、カスタム・コー
ドおよびデータを保持する .elf ファイルに追加することができます。
これらのセクションは、命名されたメモリ領域に位置し、物理メモリ・デバイスお
よびアドレスに関連付けて定義されます。デフォルトの状態では、これらのセク
ションは、自動的に HAL によって生成されます。しかし、ユーザーは、これらを特
定のアプリケーション用に制御することができます。
HAL のリンク動作
この項では、BSP 生成ツールのデフォルトのリンク動作、および明示的にリンクを
制御する方法を説明します。
デフォルトの BSP リンク
BSP のコンフィギュレーション中に、これらのツールは、以下のステップを自動的
に実行します。
1. メモリ領域名の割り当て — 各システム・メモリ・デバイスに名前を割り当てて、
それぞれの名前をメモリ領域としてリンカ・ファイルに追加します。
2. 最大容量のメモリの検索 — リンカ・ファイル内の最大容量のリードおよびライ
ト・メモリ領域を識別します。
3. セクションの割り当て — 前のステップで識別されたメモリ領域にデフォルトの
セクション（.text、.rodata、.rwdata、.bss、.heap、および .stack）を配置し
ます。
4. ファイルの書き込み —linker.x および linker.h ファイルを書き込みます。
通常、メモリが十分に大きな容量のときアプリケーションの機能を保証するために、
このセクション割り当てスキームは、ソフトウェア開発プロセス中に動作します。
1
HAL のデフォルト・リンク動作のルールには、<Nios II EDS install dir>/sdk2/bin ディレク
トリにあるアルテラ生成の Tcl スクリプトの bsp-set-defaults.tcl および
bsp-linker-utils.tcl が含まれています。これらのスクリプトは、
nios2-bsp-create-settings のコンフィギュレーション・アプリケーションによって呼び
出されます。これらのスクリプトを直接変更しないでください。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
アプリケーション・ブート・ロードおよびプログラミング・システム・メモリ
2‒55
ユーザー制御の BSP リンク
ユーザーは、デフォルト・リンク動作を Nios II BSP エディタの Linker Script タブ内で
管理することができます。以下の方法によってリンカ・スクリプトを操作すること
ができます。
■
メモリ領域の追加 — メモリ領域名を物理メモリ・デバイスにマップします。
■
セクション・マッピングの追加 — セクション名をメモリ領域にマップします。
Nios II BSP エディタによって、変更の前後にメモリ・マップを表示させることが
できるようになります。
f リンカ関連の BSP コンフィギュレーション・コマンドについて詳しくは、Nios II
Software Developer's Handbook の Getting Started with the Graphical User Interface の章の
「Using the BSP Editor」を参照してください。
アプリケーション・ブート・ロードおよびプログラミング・システム・メモリ
ほとんどの Nios II システムでは、プロセッサがアプリケーション・プログラムの動
作を開始できるようになる前に、システム・メモリ内でハードウェアおよびソフト
ウェアのイメージをコンフィギュレーションするためのいくつかの方法を必要とし
ます。この項では、システム（揮発性および非揮発性の両方）用のさまざまな可能
なメモリ・トポロジーについて、それらの使用方法、それらの要件、およびそれら
のコンフィギュレーションについて説明します。システム・ソフトウェアがフラッ
シュ・メモリ内に格納されているにもかかわらず揮発性メモリから実行するために
コンフィギュレーションされる場合、Nios II ソフトウェア・アプリケーションは、
システム・メモリをコンフィギュレーションするためのブート・ローダ・アプリ
ケーションを必要とします。Nios II プロセッサがフラッシュ・メモリから実行する
、ブート・ローダではな
場合（.text セクションはフラッシュ・メモリにあります）
くコピー・ルーチンは、他のプログラム・セクションを揮発性メモリにロードしま
す。システム・アプリケーションが内部 FPGA を占領する場合や他のプロセッサに
よって外部メモリにプリロードされる場合などのいくつかのケースでは、システム・
メモリのコンフィギュレーションは必要ありません。
この項には、以下のサブセクションが含まれています。
■
「デフォルト BSP のブート・ロード・コンフィギュレーション」
■
2–56 ページの「ブート・コンフィギュレーション・オプション」
■
2–60 ページの「システム・メモリ・イメージの生成およびプログラミング」
デフォルト BSP のブート・ロード・コンフィギュレーション
nios2-bsp スクリプトは、システムがブート・ローダを必要とするかどうか、および
デフォルトのセクションのコピーをイネーブルするかどうか決定します。
デフォルトの状態では、nios2-bsp スクリプトは、以下のルールを使用してこれらを
決定します。
■
2011 年 7 月
ブート・ローダ —nios2-bsp スクリプトは、以下の条件のときにブート・ローダが
使用されていることを前提とします。
■
Nios II プロセッサのリセット・アドレスが .text セクションに存在しない。
■
Nios II プロセッサのリセット・アドレスがフラッシュ・メモリ内にある。
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒56
第 2 章 : Nios II ソフトウェアの開発
アプリケーション・ブート・ロードおよびプログラミング・システム・メモリ
■
デフォルト・セクションのコピー —nios2-bsp スクリプトは、Nios II プロセッサの
リセット・アドレスが .text セクション内のアドレスに設定されている場合、デ
フォルトの揮発性セクションのコピーをイネーブルします。
デフォルトのブート・ローダ動作がシステムに適切である場合、ブート・ロード・
プロセスを介在させる必要はありません。
ブート・コンフィギュレーション・オプション
ユーザーは、以下の設定を使用して、アプリケーション・ロード用のデフォルトの
nios2-bsp スクリプト動作を変更することができます。
■
hal.linker.allow_code_at_reset
■
hal.linker.enable_alt_load
■
hal.linker.enable_alt_load_copy_rwdata
■
hal.linker.enable_alt_load_copy_exceptions
■
hal.linker.enable_alt_load_copy_rodata
これらの設定をイネーブルする場合、ブート・ロード用の BSP のデフォルト動作を
オーバーライドすることができます。ユーザーは、Nios II BSP エディタの Settings タ
ブでアプリケーション・ロード動作を変更することができます。
あるいは、BSP エディタにインポートする設定を Tcl スクリプトにリストすることが
できます。
インポートされる Tcl スクリプトの使用について詳しくは、2–16 ページの「Nios II
BSP エディタとの Tcl スクリプトの使用」を参照してください。
1
これらの設定は、デフォルトの BSP 生成動作をオーバーライドするかどうか
settings.bsp コンフィギュレーション・ファイルの中に作成されます。しかし、ユー
ザーは、それらのデフォルト値をオーバーライドすることになる可能性があります。
f BSP コンフィギュレーション設定について詳しくは、Nios II Software Developer's
Handbook の Nios II Software Build Tools Reference の章の「Settings Managed by the
Software Build Tools」の項を参照してください。ブート・ロード・オプションおよび
高度なブート・ローダ例について詳しくは、AN458: Alternative Nios II Boot Methods を
参照してください。
フラッシュ・メモリからのブートおよび実行
プログラムがフラッシュ・メモリにロードされてフラッシュ・メモリから実行され
る場合、アプリケーションの .text セクションはコピーされません。しかし、C ラ
ンタイム初期化（crt0 コード・ブロックの実行）中に、いくつかのほかのコード・
セクションは、アプリケーションの実行の準備として揮発性メモリにコピーされる
場合があります。
crt0 コードの動作について詳しくは、2–28 ページの「crt0 の初期化」を参照してくだ
さい。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
アプリケーション・ブート・ロードおよびプログラミング・システム・メモリ
1
2‒57
アルテラは、コンパイルされたアプリケーションのダウンロードではフラッシュ・
メモリの再プログラミングが必要となるため、通常の開発サイクルではこのコン
フィギュレーションを回避することを推奨しています。更に、ソフトウェアのブ
レークポイント機能は、このコンフィギュレーションを使用する場合、ハードウェ
アのブレークポイントが Nios II プロセッサ用にイネーブルされていることを必要と
します。
これらのステップに従って BSP コンフィギュレーションを準備して、フラッシュ・
メモリからブートおよび実行するアプリケーションをコンフィギュレーションしま
す。
1. Nios II プロセッサのリセット・アドレス —Nios II プロセッサのリセット・アドレ
スがフラッシュ・メモリ内にあることを確認します。リセット・アドレスおよび
フラッシュ・メモリ・アドレスを SOPC Builder でコンフィギュレーションします。
2. テキスト・セクションのリンカ設定 —.text セクションがフラッシュ・メモリ・
アドレス領域にマップしていることを確認してください。BSP エディタの Linker
Script タブ内でセクションのマッピングを検証および変更することができます。
あるいは、以下の Tcl コマンドを使用します。
add_section_mapping .text ext_flash
3. 他のセクションのリンカ設定 — 他のすべてのセクションが、.rodata セクション
の可能な例外と共に揮発性メモリ領域にマップされていることを確認します。
.rodata セクションは、フラッシュ・メモリ領域にマップすることができます。
4. HAL C ランタイム・コンフィギュレーション設定 — 表 2–2 に示すように BSP 設
定をコンフィギュレーションします。
表 2‒2. フラッシュ・メモリからブートおよび実行するための BSP 設定
BSP 設定名
値
hal.linker.allow_code_at_reset
1
hal.linker.enable_alt_load
1
hal.linker.enable_alt_load_copy_rwdata
1
hal.linker.enable_alt_load_copy_exceptions
1
hal.linker.enable_alt_load_copy_rodata
1
アプリケーションにカスタム・メモリ・セクションが含まれている場合、ユーザー
は、手動でカスタム・セクションをロードする必要があります。
alt_load_section() ライブラリ・ファンクションを使用して、これらのセクション
がプログラムの実行前にロードされていることを確認します。
1
HAL BSP ライブラリは、アプリケーション・イメージの誤った上書きを回避するため
に、フラッシュ・メモリ・ライト機能をディセーブルします。
フラッシュ・メモリからのブートおよび揮発性メモリからの実行
アプリケーション・イメージがフラッシュ・メモリに格納されているにもかかわら
ずブート・ローダ・プログラムからの支援を使用して揮発性メモリから実行する場
合、これらのステップに従って BSP コンフィギュレーションの準備をします。
1. Nios II プロセッサのリセット・アドレス —Nios II プロセッサのリセット・アドレ
スがフラッシュ・メモリ内のアドレスであることを確認します。SOPC Builder を
使用してこのオプションをコンフィギュレーションします。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒58
第 2 章 : Nios II ソフトウェアの開発
アプリケーション・ブート・ロードおよびプログラミング・システム・メモリ
2. テキスト・セクションのリンカ設定 —.text セクションがシステム・メモリの揮
発性の領域にマップしていて、フラッシュ・メモリにはマップしていないことを
確認します。
3. 他のセクションのリンカ設定 — 他のすべてのセクションが、.rodata セクション
の可能な例外と共に揮発性メモリ領域にマップされていることを確認します。
.rodata セクションは、フラッシュ・メモリ領域にマップすることができます。
4. HAL C ランタイム・コンフィギュレーション設定 — 表 2–3 に示すように BSP 設
定をコンフィギュレーションします。
表 2‒3. フラッシュ・メモリからブートして揮発性メモリから実行するための BSP 設定
BSP 設定名
値
hal.linker.allow_code_at_reset
0
hal.linker.enable_alt_load
0
hal.linker.enable_alt_load_copy_rwdata
0
hal.linker.enable_alt_load_copy_exceptions
0
hal.linker.enable_alt_load_copy_rodata
0
揮発性メモリからのブートおよび実行
このコンフィギュレーションは、Nios II プロセッサのメモリが他のプロセッサまた
はインタコネクタ・スイッチ・ファブリック・マスタ・ポートによって外部でロー
ドされる場合に使用されます。このケースでは、プロセッサが最初に動作するコー
ドを保持するメモリに対して Nios II プロセッサのリセット・アドレスの変更が必要
な場合を除いて、「フラッシュ・メモリからのブートおよび揮発性メモリからの実
行」と同じステップの実行によって BSP コンフィギュレーションの準備をします。
これらのステップに従って、BSP コンフィギュレーションを準備します。
1. Nios II プロセッサのリセット・アドレス —Nios II プロセッサのリセット・アドレ
スが揮発性メモリにあることを確認します。SOPC Builder を使用してこのオプ
ションをコンフィギュレーションします。
2. テキスト・セクションのリンカ設定 —.text セクションがリセット・アドレス・
メモリにマップされていることを確認します。
3. 他のセクションのリンカ設定 —.rodata セクションを含む他のすべてのセクショ
ンも、リセット・アドレス・メモリにマップされていることを確認します。
4. HAL C ランタイム・コンフィギュレーション設定 — 表 2–4 に示すように BSP 設
定をコンフィギュレーションします。
表 2‒4. 揮発性メモリからブートおよび実行するための BSP 設定
BSP 設定名
値
hal.linker.allow_code_at_reset
1
hal.linker.enable_alt_load
0
hal.linker.enable_alt_load_copy_rwdata
0
hal.linker.enable_alt_load_copy_exceptions
0
hal.linker.enable_alt_load_copy_rodata
0
このタイプのブート・ロードおよびシーケンスは、この章の範囲外の追加のハード
ウェア変更へのサポートを必要とします。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
アプリケーション・ブート・ロードおよびプログラミング・システム・メモリ
2‒59
アルテラの EPCS メモリからのブートおよび揮発性メモリからの実行
このコンフィギュレーションは、2–57 ページの「フラッシュ・メモリからのブート
および揮発性メモリからの実行」に示されているコンフィギュレーションの特別な
ケースです。しかし、このコンフィギュレーションでは、プロセッサは最初のブー
ト・ロード動作を実行しません。EPCS フラッシュ・メモリは、FPGA のハードウェ
ア・イメージおよびアプリケーション・イメージを格納します。システムのパワー・
アップの時に、FPGA は、EPCS メモリから自身をコンフィギュレーションします。
そして Nios II プロセッサは、EPCS メモリ・コントローラ内の小規模の FPGA メモ
リ・リソースへの制御をリセットして、EPCS メモリからアプリケーションのランタ
イム位置にアプリケーションをコピーする小さなブート・ローダ・アプリケーショ
ンを実行します。
1
このコンフィギュレーションを動作させるためには、システム・ハードウェア内の
EPCS デバイス・コントローラ・コアをインスタンス化する必要があります。
SOPC Builder を使用してコンポーネントを追加します。
これらのステップに従って BSP コンフィギュレーションを準備します。
1. Nios II プロセッサのリセット・アドレス —Nios II プロセッサのリセット・アドレ
スが EPCS メモリ・コントローラ内にあることを確認します。SOPC Builder を使用
してこのオプションをコンフィギュレーションします。
2. テキスト・セクションのリンカ設定 —.text セクションがシステム・メモリの揮
発性の領域にマップしていることを確認します。
3. 他のセクションのリンカ設定 —.rodata セクションを含む他のすべてのセクショ
ンが揮発性メモリにマップしていることを確認します。
4. HAL C ランタイム・コンフィギュレーション設定 — 表 2–5 に示すように BSP 設
定をコンフィギュレーションします。
表 2‒5. EPCS からブートおよび揮発性メモリから実行するための BSP 設定
BSP 設定名
値
hal.linker.allow_code_at_reset
0
hal.linker.enable_alt_load
0
hal.linker.enable_alt_load_copy_rwdata
0
hal.linker.enable_alt_load_copy_exceptions
0
hal.linker.enable_alt_load_copy_rodata
0
FPGA メモリからのブートおよび実行
このコンフィギュレーションでは、プログラムは内部の FPGA メモリ・リソースに
ロードされてそのメモリ・リソースから実行します。FPGA メモリ・リソースは、
FPGA デバイスがコンフィギュレーションされる場合、自動的にコンフィギュレー
ションされるため、追加のブート・ロード動作は必要ありません。
これらのステップに従って BSP コンフィギュレーションを準備します。
1. Nios II プロセッサのリセット・アドレス —Nios II プロセッサのリセット・アドレ
スが FPGA の内部メモリにあることを確認します。SOPC Builder を使用してこのオ
プションをコンフィギュレーションします。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒60
第 2 章 : Nios II ソフトウェアの開発
アプリケーション・ブート・ロードおよびプログラミング・システム・メモリ
2. テキスト・セクションのリンカ設定 —.text セクションが内部の FPGA メモリに
マップしていることを確認します。
3. 他のセクションのリンカ設定 — 他のすべてのセクションが内部の FPGA にマップ
していることを確認します。
4. HAL C ランタイム・コンフィギュレーション設定 — 表 2–6 に示すように BSP 設
定をコンフィギュレーションします。
表 2‒6. FPGA メモリからブートおよび実行するための BSP 設定
1
BSP 設定名
値
hal.linker.allow_code_at_reset
1
hal.linker.enable_alt_load
0
hal.linker.enable_alt_load_copy_rwdata
0
hal.linker.enable_alt_load_copy_exceptions
0
hal.linker.enable_alt_load_copy_rodata
0
このコンフィギュレーションは、ユーザーが FPGA イメージへのコンパイル用として
16 進数の FPGA メモリ（Intel フォーマット）ファイル（.hex）を生成することを必要
とします。このステップは、以下の項で説明します。
システム・メモリ・イメージの生成およびプログラミング
リンカ設定およびブート・ローダ・コンフィギュレーションのコンフィギュレー
ション、およびアプリケーション・イメージの .elf ファイルの構築の後、ユーザー
は、メモリ・プログラミング・ファイルを作成する必要があります。メモリ・プロ
グラミング・ファイルを作成するフローは、FPGA、フラッシュ、または EPCS メモ
リの選択によって決まります。
システム用のメモリ・ファイルを生成する最も簡単な方法は、アプリケーション生
成の makefile ターゲットを使用することです。
f 使用可能な mem_init.mk ターゲットは、Nios II Software Developer's Handbook の Nios II
Software Build Tools の章の「Common BSP Tasks」の項にリストされています。以下の
項に示すように、同じプロセスを手動で実行することもできます。
例えば、開発およびデバッグのサイクル中にターゲット・システム上でアプリケー
ションをダウンロードして実行する場合は、メモリ・プログラミング・ファイルを
生成する必要はありません。
Nios II ソフトウェア・ビルド・ツールのコマンドラインを使用した
FPGA メモリのプログラミング
ソフトウェア・アプリケーションが内部の FPGA メモリ・リソースから実行するため
にデザインされる場合、ユーザーは、アプリケーション・イメージの .elf ファイル
を 1 つ以上の .hex メモリ・ファイルに変換する必要があります。Quartus II ソフト
ウェアは、これらの .hex メモリ・ファイルを .sof ファイルにコンパイルします。こ
のイメージが FPGA 内にロードされる場合、内部メモリ・ブロックを初期化します。
.elf ファイルから .hex メモリ・ファイルを作成するには、以下のコマンドを入力し
ます。
elf2hex <myapp>.elf <start_addr> <end_addr> --width=<data_width> <hex_filename>.hex r
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
アプリケーション・ブート・ロードおよびプログラミング・システム・メモリ
2‒61
このコマンドは、<data_width> の幅のメモリ用にフォーマットされた <start_addr> お
よび <end_addr> の間のデータを使用して、アプリケーション・イメージの
<myapp>.elf から .hex メモリ・ファイルを作成します。コマンドは、
<hex_filename>.hex ファイルに出力を配置します。elf2hex コマンドラインの引数につ
いて詳しくは、elf2hex --help を入力してください。
Quartus II ソフトウェアを使用して、.hex メモリ・ファイルを FPGA イメージにコン
パイルします。FPGA メモリ・リソースを初期化するには、SOPC Builder および
Quartus II ソフトウェアの知識が必要です。
Eclipse 用の Nios II ソフトウェア・ビルド・ツールのフラッシュ・メ
モリのコンフィギュレーションおよびプログラミング
Eclipse 用の Nios II ソフトウェア・ビルド・ツールは、フラッシュ・メモリの内容を
管理およびプログラムする上で役立つフラッシュ・プログラマ・ユーティリティを
提供します。
フラッシュ・プログラマによって、ソフトウェア、ハードウェア、およびバイナリ・
データの任意の組み合わせをフラッシュ・メモリに 1 回の動作でプログラムできる
ようになります。
「コマンドラインからのフラッシュ・メモリのコンフィギュレーションおよびプログ
ラミング」では、コマンドライン・モードでのフラッシュ・プログラマで実行する
ことができるいくつかの一般的なタスクが説明されています。また、これらのタス
クのほとんどは、Eclipse 用の Nios II ソフトウェア・ビルド・ツールのフラッシュ・
プログラマ GUI を使用して実行することができます。
f フラッシュ・プログラマの使用について詳しくは、Nios II Software Developer's
Handbook の Getting Started with the Graphical User Interface の章の「Programming Flash in
Altera Embedded Systems」を参照してください。
コマンドラインからのフラッシュ・メモリのコンフィギュレーション
およびプログラミング
BSP プロジェクトおよびアプリケーション・イメージの .elf ファイルをコンフィ
ギュレーションして構築した後、ユーザーは、フラッシュ・プログラミング・ファ
イルを生成する必要があります。nios2-flash-programmer ツールは、USB-Blaster ケー
ブルなどのプログラミング・ケーブルを経由してフラッシュ・メモリ・デバイスを
コンフィギュレーションするためにこのファイルを使用します。
フラッシュ・イメージ・ファイルの作成
ブート・ローダ・アプリケーションがシステムで必要な場合、まず、システム用の
フラッシュ・イメージ・ファイルを作成する必要があります。この項では、フラッ
シュ・イメージ・ファイルを作成するための Nios II ソフトウェア・ビルド・ツール
のコマンドラインにあるいくつかの標準的なコマンドを示します。この項では、フ
ラッシュ・メモリからの FPGA のプログラミングおよびコンフィギュレーションの
ケースについては説明しません。
以下の標準的なコマンドは、フラッシュ・メモリ・デバイス用のフラッシュ・イ
メージ・ファイルを作成します。
■
2011 年 7 月
ブート・ローダ必須および EPCS フラッシュ・デバイス使用 —EPCS フラッシュ・
デバイス・イメージを作成するには、以下のコマンドを入力します。
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒62
第 2 章 : Nios II ソフトウェアの開発
アプリケーション・ブート・ロードおよびプログラミング・システム・メモリ
elf2flash --epcs --after=<standard>.flash --input=<myapp>.elf \
--output=<myapp>.flash r
このコマンドは、<myapp>.elf ファイル内のアプリケーション・イメージをフ
ラッシュ・レコード・フォーマットに変換して、<standard>.flash 内の FPGA ハー
ドウェア・イメージに付加される新規のフラッシュ・レコードが含まれている新
規の <myapp>.flash ファイルを作成します。
■
ブート・ローダ必須および CFI フラッシュ・メモリ使用 —CFI フラッシュ・メモ
リ・イメージを作成するには、以下のコマンドを入力します。
elf2flash --base=0x0 --reset=0x0 --end=0x1000000 \
--boot=<boot_loader_cfi>.srec \
--input=<myapp>.elf --output=<myapp>.flash r
このコマンドは、<myapp>.elf ファイル内のアプリケーション・イメージをフラッ
シュ・レコード・フォーマットに変換して、<boot_loader_cfi>.srec 内の CFI ブー
ト・ローダに付加される新規のフラッシュ・レコードが含まれている新規の
<myapp>.flash ファイルを作成します。フラッシュ・レコードは、Nios II プロセッ
サの 0x0 のリセット・アドレスにダウンロードされて、フラッシュ・デバイスの
エース・アドレスは 0x0 です。アルテラ提供のブート・ローダを使用する場合、
ユーザー作成のプログラム・セクションも、フラッシュ・メモリからそれらのラ
ンタイムの位置にロードされます。
■
ブート・ローダ不要および CFI フラッシュ・メモリ使用 — ブート・ローダが必要
ない場合、CFI フラッシュ・メモリ・イメージを作成するには、以下のコマンド
を入力します。
elf2flash --base=0x0 --reset=0x0 --end=0x1000000 \
--input=<myapp>.elf --output=<myapp>.flash r
このコマンドおよびその影響は、ブート・ローダが必要なときのフラッシュ・メ
モリ・イメージを作成するコマンドとほとんど同じです。このケースでは、ブー
ト・ローダが必要ないため、--boot コマンドラインのオプションは存在しませ
ん。
Nios II EDS には、CFI フラッシュ・デバイス用および EPCS フラッシュ・デバイス用
の、プリコンパイルされた 2 つのブート・ロードが含まれています。これらのブー
ト・ローダ用のソース・コードは、
<Nios II EDS install dir>/components/altera_nios2/boot_loader_sources/ ディレクトリにあ
ります。
フラッシュ・メモリのプログラミング
システム・フラッシュ・メモリをプログラムする最も簡単な方法は、program-flash
と呼ばれるアプリケーション生成の makefile ターゲットを使用することです。この
ターゲットは、JTAG ダウンロード・ケーブルを経由して、フラッシュ・イメージ・
ファイルを開発ボードに自動的にダウンロードします。また、
nios2-flash-programmer ユーティリティを使用して、このプロセスを手動で実行する
こともできます。このユーティリティは、フラッシュ・ファイルおよびいくつかのコ
マンドライン引数を受け取り、システムのフラッシュ・メモリをプログラムします。
以下のコマンドラインの例は、システムのフラッシュ・メモリをプログラムする
nios2-flash-programmer ユーティリティの使用について示しています。
■
CFI フラッシュ・メモリのプログラミング — フラッシュ・イメージ・ファイルを
使用して CFI フラッシュ・メモリをプログラムするには、以下のコマンドを入力
します。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 2 章 : Nios II ソフトウェアの開発
まとめ
2‒63
nios2-flash-programmer --base=0x0 <myapp>.flash r
このコマンドは、<myapp>.flash と呼ばれるフラッシュ・イメージ・ファイルを使
用して 0x0 のベース・アドレスに位置するフラッシュ・メモリをプログラムしま
す。
■
EPCS フラッシュ・メモリのプログラミング — フラッシュ・イメージ・ファイルを
使用して EPCS フラッシュ・メモリをプログラムするには、以下のコマンドを入
力します。
nios2-flash-programmer --epcs --base=0x0 <myapp>.flash r
このコマンドは、<myapp>.flash と呼ばれるフラッシュ・イメージ・ファイルを使
用して 0x0 のベース・アドレスに位置する EPCS フラッシュ・メモリをプログラ
ムします。
nios2-flash-programmer ユーティリティは、FPGA がシステム・ハードウェア・イメー
ジを使用して既にコンフィギュレーションされていることを必要とします。ユー
ザーは、nios2-flash-programmer ユーティリティを実行する前に、nios2-configure-sof
コマンドを使用して .sof ファイルをダウンロードする必要があります。
f フラッシュ・メモリ・デバイスをコンフィギュレーション、プログラム、および管
理する方法について詳しくは、Nios II Flash Programmer User Guide を参照してくださ
い。
まとめ
アルテラは、Nios II ソフトウェア・ビルド・ツール・フローを使用して Nios II プロ
セッサを含むハードウェア・デザイン用のソフトウェアを開発することを推奨して
います。ソフトウェア・ビルド・ツールを使用する最も簡単な方法は、Eclipse 用の
Nios II ソフトウェア・ビルド・ツールおよび Nios II BSP エディタを使用することで
す。
この章では、Nios II ソフトウェア・ビルド・ツール・フローについて、Nios II
Software Developer’s Handbook を補完する情報を提供しています。ここでは、推奨され
るデザイン手法および実装の情報を説明して、より詳しい情報の関連トピックへの
ポインタを提供しています。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
2‒64
第 2 章 : Nios II ソフトウェアの開発
改訂履歴
改訂履歴
表 2–7 に、本資料の改訂履歴を示します。
表 2‒7. 改訂履歴
日付
2011 年 7 月
バージョン
1.4
変更内容
■
Eclipse 用の Nios II SBT の GCC ツールチェインに関する情報を更新。
■
アプリケーションおよび BSP の makefile での前処理と後処理の可用性を追加。
■
参照先を更新。
■
2009 年 12 月
1.3
Eclipse 用の Nios II ソフトウェア・ビルド・ツールを更新。
■
すべての Nios II IDE 命令を削除。
■
Nios II IDE 命令のすべてのインスタンスを、Eclipse 用の Nios II ソフトウェア・ビ
ルド・ツールのための命令と置き換え。
2009 年 7 月
1.2
Nios II BSP エディタを追加。
2008 年 6 月
1.1
表の内容を訂正。
2008 年 3 月
1.0
初版。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
3. Nios II デザインのデバッグ
December 2009
ED51003-1.3
ED51003-1.3
この章では、Nios® II プロセッサのソフトウェア・デザインをデバッグする最良の手
法を説明します。これらのデザインのデバッグには、複数の制約条件への十分な理
解が必要なハードウェアおよびソフトウェアの両方のデバッグが含まれています。
デバッグを成功させるには、ボード・レイアウト、FPGA コンフィギュレーション、
および Nios II ソフトウェア・ツールとアプリケーション・ソフトウェアの専門技術
が必要です。この章には、困難なエンベデッド・デザイン問題に対応するデバッグ
の手法およびツールについて説明する以下の項が含まれています。
■
■
「デバッガ」
3–12 ページの「ランタイム解析のデバッグ手法」
デバッガ
Nios II 開発環境は、Nios II ソフトウェア・ツールをデバッグするためのいくつかの
ツールを提供します。この項では、以下の開発環境で使用可能なデバッグ機能を説
明します。
■
「NiosII ソフトウェア開発ツール」
■
3–10 ページの「FS2 コンソール」
■
3–11 ページの「SignalTap II エンベデッド・ロジック・アナライザ」
■
3–11 ページの「Lauterbach の Trace32 デバッガおよび PowerTrace ハードウェア」
■
3–12 ページの「Insight デバッガおよびデータ・ディスプレイ・デバッガ」
NiosII ソフトウェア開発ツール
Eclipse™ 用の Nios II ソフトウェア・ビルド・ツールは、Nios II プログラムの作成、変
更、構築、実行およびデバッグをサポートするグラフィカル・ユーザー・ツール
（GUI）です。コマンドライン用の Nios II ソフトウェア・ビルド・ツールは、Nios II
コマンド・シェルから使用可能なコマンドライン・ユーティリティです。Eclipse 用
の Nios II ソフトウェア・ビルド・ツールは、コマンドライン用の Nios II ソフトウェ
ア・ビルド・ツールと同じ基本となるユーティリティおよびスクリプトを使用しま
す。ソフトウェア・ビルド・ツールを使用することで、構築プロセスおよびプロ
ジェクト設定を細かく制御できます。
SOPC Builder は、プロセッサ、ペリフェラル、およびメモリを含むシステムを作成す
るためのシステム開発ツールです。そのツールによって、完全な FPGA システムを非
常に効率よく定義および生成することができるようになります。SOPC Builder は、シ
ステムが Nios II を含んでいることを必要としません。しかし、システム内に Nios II
プロセッサを統合するための、いくつかのクリティカルなデバッグ機能を含むサ
ポートが含まれています。
以下の項では、Nios II ソフトウェア開発ツールで使用可能なデバッグ・ツールおよ
びサポート機能を説明します。
■
「Nios II のシステム ID」
© 2009 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, HARDCOPY, MAX, MEGACORE, NIOS, QUARTUS and STRATIX are Reg. U.S. Pat. & Tm. Off.
and/or trademarks of Altera Corporation in the U.S. and other countries. All other trademarks and service marks are the property of their respective holders as described at
www.altera.com/common/legal.html. Altera warrants performance of its semiconductor products to current specifications in accordance with Altera’s standard warranty, but
reserves the right to make changes to any products and services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Altera. Altera customers are advised to obtain the latest version of device
specifications before relying on any published information and before placing orders for products or services.
エンベデッド・デザイン・ハンドブック
2009 年 12 月
Subscribe
3‒2
第 3 章 : Nios II デザインのデバッグ
デバッガ
■
「プロジェクト・テンプレート」
■
3–4 ページの「コンフィギュレーション・オプション」
■
3–7 ページの「Nios II GDB コンソールおよび GDB コマンド」
■
3–8 ページの「Nios II のコンソール・ビューおよび stdio ライブラリ・ファンクショ
ン」
■
3–8 ページの「Nios II ソフトウェア・ビルド・ツールを使用して作成されたプロ
ジェクトのインポート」
■
3–9 ページの「複数のプロセッサ・デザインでのプロセッサ・インスタンスの選
択」
Nios II のシステム ID
システム識別子（ID）機能は、SOPC Builder のシステム・コンポーネントと同じよう
に使用可能です。コンポーネントは、異なる SOPC Builder システム用に生成された
BSP プロジェクトを使用して、デバッガがソフトウェア・プロジェクトのダウン
ロードの試みを識別できるようにします。この機能は、Nios II ハードウェア・デザ
イン用に構築されて FPGA で現在ロードされていない実行可能なリンク・フォーマッ
ト（.elf）ファイルを誤って使用することからユーザーを保護します。アプリケー
ション・イメージがコンパイルされたハードウェア実装上でそれが実行しない場合、
その結果は予期できません。
この基本的なセーフティ・ネットを使用してデザインを開始するには、Eclipse 用の
Nios II ソフトウェア・ビルド・ツールの Debug Configurations ダイアログ・ボックス
の Target Connection タブで、Ignore mismatched system ID がオンになっていないこと
を確認します。
エンベデッド・デザイン・ハンドブック
2009 年 12 月
Altera Corporation
第 3 章 : Nios II デザインのデバッグ
デバッガ
3‒3
システム ID 機能は、SOPC Builder デザインがシステム ID コンポーネントを含んでい
ることを必要とします。図 3–1 に、システム ID コンポーネントを持っている SOPC
Builder システムを示します。
図 3‒1. システム ID コンポーネントを持っている SOPC Builder システム
f システム ID コンポーネントについて詳しくは、Quartus II Handbook の volume 5 の
System ID Core の章を参照してください。
プロジェクト・テンプレート
Eclipse 用の Nios II ソフトウェア・ビルド・ツールは、新規のボードをテストするた
めのシンプルで小さなテスト済みソフトウェア・プロジェクトを作成する上で役立
ちます。
Eclipse 用の Nios II ソフトウェア・ビルド・ツールは、プロジェクト・テンプレート
を使用して新規のソフトウェア・プロジェクトを作成するメカニズムを提供します。
新規のボードをテストするためのシンプルなテスト・プログラムを作成するには、
以下のステップを実行します。
1. Nios II の画面で、File メニューの New をポイントして、Nios II Application and BSP
from Template をクリックします。
Nios II C/C++ アプリケーション・プロジェクト用の New Project wizard が表示され
ます。
2. デザイン用の SOPC 情報（.sopcinfo）ファイルを指定します。このファイルがあ
るフォルダは、プロジェクト・ディレクトリです。
3. ハードウェア・デザインに複数の Nios II プロセッサが含まれている場合、CPU リ
ストでこのアプリケーション・ソフトウェアを実行する所望のプロセッサをク
リックします。
2009 年 12 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
3‒4
第 3 章 : Nios II デザインのデバッグ
デバッガ
4. プロジェクト名を指定します。
5. Templates リストの Hello World Small をクリックします。
6. Next をクリックします。
7. Finish をクリックします。
Hello World Small テンプレートは、非常にシンプルで小さいアプリケーションです。
シンプルで小さいアプリケーションを使用することは、新しいハードウェアを立ち
上げるときに発生する可能性がある潜在的な失敗を最小にします。
ユーザーが既に持っているソース・コード用に新規のプロジェクトを作成するには、
以下の例外を踏まえながら上記のステップを実行します。
■
ステップ 5 で、Blank Project をクリックします。
■
ステップ 7 の実行後、以下のステップを実行します。
a. 新規のディレクトリの <your_project_directory>/software/<project_name>/source
を作成します（<project_name> はステップ 4 でユーザーが指定したプロジェク
ト名です）。
b. ソース・コード・ファイルを新規の
<your_project_directory>/software/<project_name>/source ディレクトリにコピーす
ることで、それらを新規のプロジェクトにコピーします。
c. Project Explorer タブのアプリケーション・プロジェクト名を右クリックして、
Refresh をクリックします。新規の source フォルダがアプリケーション・プロ
ジェクト名の下に表示されます。
コンフィギュレーション・オプション
以下の Eclipse 用の Nios II ソフトウェア・ビルド・ツールのコンフィギュレーショ
ン・オプションは、アプリケーション・イメージの .elf ファイルに使用可能なデ
バッグ情報を豊富にします。
■
Objdump ファイル
■
Make コマンドの表示
■
行番号の表示
エンベデッド・デザイン・ハンドブック
2009 年 12 月
Altera Corporation
第 3 章 : Nios II デザインのデバッグ
デバッガ
3‒5
Objdump ファイル
ユーザーは、オブジェクト・ダンプ・テキスト・ファイル（.objdump）内の .elf につ
いて役立つ情報を生成するために、Nios II ビルド・プロセスに指示することができ
ます。.objdump ファイルには、メモリ・セクションおよびそれらのレイアウト、
ファンクションのアドレス、およびアセンブリ・コードとインタリーブされた元の
C ソース・コードが含まれています。例 3–1 に、Nios II ビルドイン Hello World Small
プロジェクト用の .objdump の C コード・セクションおよびアセンブリ・コード・セ
クションの一部を示します。
例 3‒1. Hello World Small プロジェクトからの .objdump ファイルのコードの一部
06000170 <main>:
include "sys/alt_stdio.h"
int main()
{
6000170:deffff04 addisp,sp,-4
alt_putstr("Hello from Nios II!\n");
6000174:01018034 movhir4,1536
6000178:2102ba04 addir4,r4,2792
600017c:dfc00015 stwra,0(sp)
6000180:60001c00 call60001c0 <alt_putstr>
6000184:003fff06 br6000184 <main+0x14>
06000188 <alt_main>:
* the users application, i.e. main().
*/
void alt_main (void)
{
6000188:deffff04 addisp,sp,-4
600018c:dfc00015 stwra,0(sp)
static ALT_INLINE void ALT_ALWAYS_INLINE
alt_irq_init (const void* base)
{
NIOS2_WRITE_IENABLE (0);
6000190:000170fa wrctlienable,zero
NIOS2_WRITE_STATUS (NIOS2_STATUS_PIE_MSK);
6000194:00800044 movir2,1
6000198:1001703a wrctlstatus,r2
Eclipse 用の Nios II ソフトウェア・ビルド・ツールのこのオプションをイネーブルす
るには、以下のステップを実行します。
1. Project Explorer ウィンドウのアプリケーション・プロジェクトを右クリックして、
Properties をクリックします。
2. 左のリストの Nios II Application Properties をクリックします。
3. Nios II Application Properties のページの Create object dump をオンにします。
4. Apply をクリックします。
5. OK をクリックします。
次回の構築の後、.objdump ファイルは、新規に構築される .elf ファイルと同じ
ディレクトリ内にあります。
2009 年 12 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
3‒6
第 3 章 : Nios II デザインのデバッグ
デバッガ
次回の構築によって .elf ファイルが生成された後、生成された .elf ファイル上
で--disassemble-all、--source、および--all-headers のオプションを使用して
nios2-elf-objdump コマンドを実行します。
Nios II ユーザー管理ツール・フローで、ユーザーは、nios2-elf-objdump コマンドで実
行するオプションを決定するアプリケーション makefile 内の設定を編集することがで
きます。create-this-app スクリプト、または nios2-app-generate-makefile スクリプト
の実行によって、アプリケーション makefile 内に以下のラインを作成します。
#Options to control objdump.
CREATE_OBJDUMP := 1
OBJDUMP_INCLUDE_SOURCE :=0
OBJDUMP_FULL_CONTENTS := 0
プロジェクトへのユーザーの好みに応じて、これらのオプションを編集して
.objdump ファイルを制御します。
1
■
CREATE_OBJDUMP— 値 1 は、nios2-elf-objdump に対し
て、--disassemble、--syms、--all-header、および--source を使用して実行する
ように指示します。
■
OBJDUMP_INCLUDE_SOURCE—値1は、オプションの--sourceを nios2-elf-objdumpコマ
ンドラインに追加します。
■
OBJDUMP_FULL_CONTENTS— 値 1 は、オプションの--full-contents を
nios2-elf-objdump コマンドラインに追加します。
それぞれのコマンドライン・オプションの生成について詳しくは、Nios II コマンド・
シェルに以下のコマンドを入力します。
nios2-elf-objdump --help r
Make コマンドの表示
make コマンド用の冗長モードをイネーブルするには、Eclipse 用の Nios II ソフトウェ
ア・ビルド・ツールのディスプレイに実行中として表示される個別の Makefile コマン
ドで、以下のステップを実行します。
1. Project Explorer ウィンドウのアプリケーション・プロジェクトを右クリックして、
Properties をクリックします。
2. 左のリストの C/C++ Build をクリックします。
3. C/C++ Build ページの Use default build command をオフにします。
4. Build command では、make -d を入力します。
5. Apply をクリックします。
6. OK をクリックします。
行番号の表示
Eclipse 用の Nios II ソフトウェア・ビルド・ツールの C ソース・コードの行番号の表
示をイネーブルするには、これらのステップに従います。
1. Window メニューの Preferences をクリックします。
2. 左のリストで、General の Editors の Text Editors を選択します。
3. Text Editors ページの Show line numbers をオンにします。
4. Apply をクリックします。
エンベデッド・デザイン・ハンドブック
2009 年 12 月
Altera Corporation
第 3 章 : Nios II デザインのデバッグ
デバッガ
3‒7
5. OK をクリックします。
Nios II GDB コンソールおよび GDB コマンド
Nios II GNU デバッガ（GDB）コンソールによって、GDB コマンドを Nios II プロセッサ
に直接送信することができるようになります。
ユーザーが独自の GDB コマンドを入力できるようにするこのコンソールを表示する
には、Nios II デバッグの画面の右下のコーナーにある青のモニタ・アイコンをク
リックします。（Nios II デバッガの画面が表示されない場合、Window メニューの
Open Perspective をクリックし、使用可能な画面を表示するために Other をクリック
します。）複数のコンソールが接続されている場合、使用可能なコンソールをリスト
するために、青のモニタ・アイコンの隣にある黒の矢印をクリックします。リスト
の GDB コンソールを選択します。図 3–2 に、GDB コンソールを表示できるようにす
るコンソール・リスト・アイコン（青のモニタ・アイコンおよび黒の矢印）を示し
ます。
図 3‒2. コンソール・リスト・アイコン
Console
list
icon
GDB コンソールに進むことができる便利なコマンドの 1 つ例は、以下の通りです。
dump binary memory <file> <start_addr> <end_addr> r
このコマンドは、メモリ内の指定されたアドレス範囲の内容をホスト・コンピュー
タ上のファイルにダンプします。ファイル・タイプは、バイナリです。HexEdit ウェ
ブサイト（www.expertcomsoft.com）から使用可能な HexEdit の 16 進形式エディタを
使用して作成されたバイナリ・ファイルを表示することができます。
2009 年 12 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
3‒8
第 3 章 : Nios II デザインのデバッグ
デバッガ
Nios II のコンソール・ビューおよび stdio ライブラリ・ファンクション
I/O 動作をデバッグする場合、Nios II ソフトウェア・アプリケーションの出力文字が
stdio ライブラリからの printf() ファンクションを使用するのか、あるいは
alt_log_printf() ファンクションを使用するのか、ということを十分に理解する必
要があります。2 つのファンクションは、異なるシステムおよび I/O ブロック動作の
結果として、多少異なる振る舞いをします。
alt_log_printf() ファンクションは、HAL デバイス・ドライバをバイパスして、コ
ンポーネント・デバイス・レジスタに直接書き込みます。また、2 つのファンクショ
ンの動作は、低減ドライバ・オプションをイネーブルしたかどうか、UART または
jtag_uart を使用するために Eclipse 用の Nios II ソフトウェア・ビルド・ツールの
nios2-terminal セッションまたは Nios II コンソール・ビューを標準出力デバイスとし
て設定したかどうか、および O_NONBLOCK コントロール・コードを設定したかどう
か、ということによって異なる可能性があります。一般に、低減ドライバ・オプ
ションをイネーブルすると、jtag_uart デバイスのブロックに影響を与える可能性のあ
る割り込みがイネーブルされます。
低減ドライバ・オプションをイネーブルするには、以下のステップを実行します。
1. Eclipse 用の Nios II ソフトウェア・ビルド・ツールで、Project Explorer ウィンドウ
の BSP プロジェクトを右クリックします。
2. Nios II をポイントして BSP Editor をクリックします。BSP エディタが表示されま
す。
3. BSP エディタにある Settings タブの Common の hal で、
enable_reduced_device_drivers をクリックします。
4. Generate をクリックします。
f alt_log_printf() ファンクションについて詳しくは、Nios II Software Developer’s
Handbook の Developing Programs Using the Hardware Abstraction Layer の章の「Using
Character-Mode Devices」を参照してください。
Nios II ソフトウェア・ビルド・ツールを使用して作成されたプロジェ
クトのインポート
プロジェクトの作成および構築に Eclipse 用の Nios II ソフトウェア・ビルド・ツール
が使用されるのか、それとも Nios II ソフトウェア・ビルド・ツールのコマンドライ
ンが使用されるのか、ということによって、Eclipse 用の Nios II ソフトウェア・ビル
ド・ツールで結果の .elf イメージ・ファイルをデバッグすることができます。
f Nios II ソフトウェア・ビルド・ツールのコマンドラインを使用して作成されたプロ
ジェクトを Eclipse 用の Nios II ソフトウェア・ビルド・ツールにインポートする方法
について詳しくは、Nios II Software Developer's Handbook の Getting Started with the
Graphical User Interface の章の「Importing a Command-Line Project」を参照してくださ
い。
エンベデッド・デザイン・ハンドブック
2009 年 12 月
Altera Corporation
第 3 章 : Nios II デザインのデバッグ
デバッガ
3‒9
複数のプロセッサ・デザインでのプロセッサ・インスタンスの選択
複数の Nios II プロセッサを使用するデザインでは、ユーザーは、各プロセッサ用に
異なるソフトウェア・プロジェクトを作成する必要があります。アプリケーション・
プロジェクトを作成する場合、Eclipse 用の Nios II ソフトウェア・ビルド・ツールは、
ボード・サポート・パッケージ（BSP）プロジェクトの指定を必要とします。アプリ
ケーション・プロジェクト用の BSP がまだ存在していない場合、ユーザーは、それ
を 1 つ作成することができます。BSP 生成では、アプリケーション・プロジェクト
がターゲットとする CPU を指定する必要があります。
図 3–3 に、Eclipse 用の Nios II ソフトウェア・ビルド・ツールで BSP 用の CPU を指定
する方法を示します。New Project wizard の Nios II Board Support Package のページに、
BSP 作成で必要となる情報があります。このページでは、システム用に .sopcinfo
ファイルから選択される使用可能な CPU のリストを提供します。
図 3‒3. Eclipse 用の Nios II ソフトウェア・ビルド・ツールのボード・サポート・パッケージのページ ̶CPU
の選択
2009 年 12 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
3‒10
第 3 章 : Nios II デザインのデバッグ
デバッガ
Nios II コマンド・シェルから、jtagconfig –n コマンドは、使用可能な JTAG デバイス
および各 JTAG デバイスに接続されたサブシステム内の CPU の数を識別します。
例 3–2 に、jtagconfig -n コマンドへのシステム応答を示します。
例 3‒2. jtagconfig コマンドへの 2 つの FPGA システム応答
[SOPC Builder]$ jtagconfig -n
1) USB-Blaster [USB-0]
120930DD EP2S60
Node 19104600
Node 0C006E00
2) USB-Blaster [USB-1]
020B40DD EP2C35
Node 19104601
Node 19104602
Node 19104600
Node 0C006E00
例 3–2 に示す応答は、実行中の JTAG サーバに異なる USB-Blaster™ ケーブルを経由し
て接続された 2 つの異なる FPGA をリストしています。USB-0 ポートに接続している
ケーブルは、1 つの Nios II コアを持っている SOPC Builder サブシステム内の JTAG
ノードに接続されます。USB-1 ポートに接続しているケーブルは、3 つの Nios II コア
を持っている SOPC Builder サブシステム内の JTAG ノードに接続されます。ノード番
号は、FPGA 内部の JTAG ノードを表しています。応答の 0x191046xx というノード番
号の表示は、FPGA 実装が JTAG デバッグ・モジュール付きの Nios II プロセッサを
持っていることを確認します。応答の 0x0C006Exx というノード番号の表示は、FPGA
実装が JTAG UART コンポーネントを持っていることを確認します。CPU インスタン
スは、191 で始まるノードの最下位バイトで識別されます。JTAG UART インスタンス
は、0C で始まるノードの最下位バイトで識別されます。インスタンス ID は 0 で始ま
ります。
JTAG デバッグ・モジュールを持っている CPU のみ、リストに表示されます。このリ
ストを使用して、目的の Nios II プロセッサ用の JTAG デバッグ・モジュールを作成し
たことを確認します。
FS2 コンソール
Windows プラットフォームでは、First Silicon Solutions、Inc.(FS2) コンソールの Nios II
互換バージョンを使用することができます。FS2 コンソールは、ロー・レベルのシス
テム・デバッグにとって、特にシステムの立ち上げまたは新規のボードの場合に非
常に便利です。ロー・レベル・レジスタおよびメモリ・アクセスからデバッグする
ソフトウェア（トレース、ブレークポイント、およびシングル・ステップ）に対し
て、TCL ベースのスクリプト環境およびシステムをテストするための多数の機能が
提供されます。
Nios II ソフトウェア・ビルド・ツールのコマンドラインを使用して FS2 コンソール
を実行するには、nios2-console コマンドを使用します。
f FS2 コンソールの Nios II 互換バージョンについて詳しくは、<Nios II EDS install
dir>\bin\fs2\doc にある Nios II EDS インストールでの FS2 提供の資料を参照してくださ
い。
FS2 コンソールでは、sld info コマンドは、システム・レベル・デバッグ（SLD）ハブ
（FPGA あたり 1 つの SLD ハブ）に接続された JTAG ノードに関する情報を返します。
誤った応答を受信する場合、詳しくは、FS2 提供の資料を参照してください。
エンベデッド・デザイン・ハンドブック
2009 年 12 月
Altera Corporation
第 3 章 : Nios II デザインのデバッグ
デバッガ
3‒11
システム・コンフィギュレーションを確認するために sld info コマンドを使用しま
す。通信が確立した後、ユーザーは、基本的なシステムの機能を確認するためにシ
ンプルなメモリのリードおよびライトを実行することができます。Avalon® メモリ・
マップ（Avalon-MM）のインタフェースの byteenable 信号が存在する場合、FS2 コ
ンソールは、バイトまたはワードを書き込むことができます。対照的に、Eclipse 用
の Nios II ソフトウェア・ビルド・ツールのメモリ・ウィンドウは、取得された値の
8 ビットまたは 16 ビットの幅にかかわらず、32 ビットのみの読み出しおよび書き込
みが可能です。問題が発生する場合、メモリ・アクセス・パスでのハードウェア・
レベルの問題を診断するために、ユーザーは、これらの読み出しおよび書き込みを
実行して、関連するハードウェア信号の SignalTap® II エンベデッド・ロジック・アナ
ライザ・トレースをキャプチャすることができます。
1
FS2 コンソールは、Eclipse 用のソフトウェア・ビルド・ツールではサポートされませ
ん。
SignalTap II エンベデッド・ロジック・アナライザ
SignalTap II エンベデッド・ロジック・アナライザは、割り込み信号を適切にクリア
しない割り込みサービス・ルーチンなどのソフトウェア関連の問題をキャッチする
上で役立ちます。
f SignalTap II エンベデッド・ロジック・アナライザについて詳しくは、Quartus II
Handbook の volume 3 の Design Debugging Using the SignalTap II Embedded Logic Analyzer
の章および AN323: Using SignalTap II Embedded Logic Analyzers in SOPC Builder Systems、
Embedded Design Handbook の Verification and Board Bring-Up の章を参照してください。
SignalTap II エンベデッド・ロジック・アナライザ用の Nios II プラグインは、Nios II プ
ロセッサのプログラム実行のキャプチャを可能にします。
f SignalTap II エンベデッド・ロジック・アナライザ用の Nios II プラグインについて詳し
くは、AN446: Debugging Nios II Systems with the SignalTap II Logic Analyzer を参照してく
ださい。
Lauterbach の Trace32 デバッガおよび PowerTrace ハードウェア
Lauterbach Datentechnik GmBH（Lauterbach）（www.lauterbach.com）は、Nios II プロセッ
サ用の Trace32 ICD デバッガを提供します。この製品には、ハードウェアおよびソフ
トウェアの両方が含まれています。アルテラの USB-Blaster ケーブルに使用される 10
ピンの JTAG コネクタ用のコネクションに加えて、PowerTrace ハードウェアは、38 ピ
ンの mictor コネクション・オプションを持っています。
また、Lauterbach は、オフチップ・トレース・キャプチャ用のモジュール、および
Nios II システム用の命令セットのシミュレータを提供します。
デバイスのパワー・アップの順序は、非常に重要です。FPGA ハードウェアの電源を
接続または切断する場合、Lauterbach PowerTrace ハードウェアは、常に電源が供給さ
れている必要があります。Lauterbach PowerTrace ハードウェアの保護回路は、モ
ジュールのパワー・アップ後にイネーブルされます。
f Lauterbach PowerTrace ハードウェアおよび必要なパワー・アップのシーケンスについ
て詳しくは、AN543: Debugging Nios II Software Using the Lauterbach Debugger を参照して
ください。
2009 年 12 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
3‒12
第 3 章 : Nios II デザインのデバッグ
ランタイム解析のデバッグ手法
Insight デバッガおよびデータ・ディスプレイ・デバッガ
Tcl/Tk ベースの Insight GDB GUI は、Nios II エンベデッド・デザイン・スイート（EDS）
の一部であるアルテラ特有の GNU GDB の分配と共にインストールします。Nios II コ
マンド・シェルから Insight デバッガを起動するには、以下のコマンドを入力します。
nios2-debug <file>.elf r
Insight デバッガには Eclipse 用の Nios II ソフトウェア・ビルド・ツールよりも少ない
機能しかありませんが、このデバッガは、ホストおよびターゲットの間のより高速
の通信をサポートするため、より応答性に優れたデバッグ経験を提供します。
他の代替デバッガは、データ・ディスプレイ・デバッガ（DDD) です。このデバッガ
は、GDB コマンド（GDB デバッガへのユーザー・インタフェース）と互換性がある
ため、Nios II ソフトウェア・デザインをデバッグするために使用することができま
す。DDD は、データ構造をグラフとして表示することができます。
ランタイム解析のデバッグ手法
この項では、実行中のソフトウェア・システムを解析する上で使用可能な手法およ
びツールを説明します。
ソフトウェアのプロファイリング
アルテラは、ソフトウェア・システムのランタイム動作をプロファイルするための
以下のツールを提供しています。
■
GNU プロファイラ —Nios II EDS ツールチェインには、アプリケーションをプロファ
イリングするための gprof ユーティリティが含まれています。このプロファイリ
ング手法は、アプリケーションで実行しているさまざまなファンクションの所要
時間を通知します。
■
高精度タイマ —SOPC Builder タイマ・ペリフェラルは、与えられたサブルーチンま
たはコード・セグメントを実行する時間を決定することができるシンプルなタイ
マ・カウンタです。ユーザーは、タイマ・サンプル間の経過時間を計算するため
に、ソース・コード内のさまざまなポイントでそれを読み出すことができます。
■
パフォーマンス・カウンタ・ペリフェラル —SOPC Builder のパフォーマンス・カウ
ンタ・ペリフェラルは、一連のカウンタ・ペリフェラルを持っているコードのい
くつかの異なるセクションをプロファイルすることができます。このペリフェラ
ルには、これらのタイマの結果を Nios II プロセッサの stdio サービスを経由して
印刷できるようにするシンプルなソフトウェア API が含まれています。
f ソフトウェア・アプリケーションをプロファイルする方法について詳しくは、
AN391: Profiling Nios II Systems を参照してください。
f SOPC Builder のタイマ・ペリフェラルについて詳しくは、Quartus II Handbook の volume
5 の Timer Core の章、および Embedded Design Handbook の Developing Nios II Software の
章を参照してください。
f SOPC Builder のパフォーマンス・カウンタ・ペリフェラルについて詳しくは、
Quartus II Handbook の volume 5 の Performance Counter Core の章を参照してください。
エンベデッド・デザイン・ハンドブック
2009 年 12 月
Altera Corporation
第 3 章 : Nios II デザインのデバッグ
ランタイム解析のデバッグ手法
3‒13
ウォッチポイント
ウォッチポイントは、破壊されていると表示されるグローバル変数へのすべてのラ
イトをキャプチャする強力な方法を提供します。Eclipse 用の Nios II ソフトウェア・
ビルド・ツールは、ウォッチポイントを直接サポートします。
ウォッチポイントについて詳しくは、Nios II のオンライン・ヘルプを参照してくだ
さい。Eclipse 用の Nios II ソフトウェア・ビルド・ツールで、Help メニューの Search
をクリックします。search フィールドにおいて、watchpoint を入力し、トピックの
Adding watchpoints を選択します。
ウォッチポイントをイネーブルするには、ユーザーは、SOPC Builder 内の Nios II プロ
セッサのデバッグ・レベルをデバッグ・レベル 2 以上にコンフィギュレーションす
る必要があります。SOPC Builder 内の Nios II プロセッサのデバッグ・レベルを適切な
レベルにコンフィギュレーションするには、以下のステップを実行します。
1. SOPC Builder の System Contents タブで、目的の Nios II プロセッサ・コンポーネン
トを右クリックします。オプションのリストが表示されます。
2. リストの Edit をクリックします。Nios II プロセッサのコンフィギュレーションの
ページが表示されます。
3. 3–15 ページの 図 3–4 に示されているように JTAG Debug Module タブをクリックし
ます。
4. Level 2、Level 3、または Level 4 を選択します。
5. Finish をクリックします。
選択するデバック・レベルに応じて、最大 4 つのウォッチポイントまたはデータ・
トリガが使用可能です。3–15 ページの 図 3–4 に、各デバッグ・レベルで使用可能な
データ・トリガの数を示します。デバッグ・レベルが高いほど、FPGA で使用するロ
ジック・リソースが多くなります。
f Nios II プロセッサのデバッグ・レベルについて詳しくは、Nios II Processor Reference
Handbook の Instantiating the Nios II Processor in SOPC Builder の章を参照してください。
スタック・オーバーフロー
エンベデッド・システムの限られたメモリは、アプリケーションが限られたスタッ
ク・サイズを持つことを必要とするため、スタック・オーバーフローは、エンベ
デッド・システムの一般的な問題です。システムがリアルタイム動作システムを実
行する場合、実行中の各タスクは、スタック・オーバーフローの状態になる可能性
が高くなる独自のスタックを持っています。この状態が発生する例として、階乗の
値を計算するファンクションなどの再帰的なファンクションを考えます。このファ
ンクションの標準的な実装では、factorial(n) は、値 n を階乗ファンクションの
factorial(n-1) の他の呼び出しによって乗算した結果です。n が大きな値の場合、こ
の再帰的なファンクションは、最終のファンクション戻り値を計算する前に結果的
にオーバーフローするまで多数のコール・スタック・フレームをスタック上に格納
する原因になります。
Eclipse 用の Nios II ソフトウェア・ビルド・ツールを使用して、スタック・オーバー
フローをチェックするための HAL をイネーブルすることができます。スタック・
オーバーフローのチェックをイネーブルして命令関連の例外ハンドラをレジスタす
る場合、スタック・オーバーフロー上で、HAL は、命令関連の例外ハンドラを呼び
出します。スタック・オーバーフローのチェックをイネーブルして命令関連の例外
2009 年 12 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
3‒14
第 3 章 : Nios II デザインのデバッグ
ランタイム解析のデバッグ手法
ハンドラをレジスタせずに Nios II プロセッサ用の JTAG デバッグ・モジュールをイ
ネーブルする場合、スタック・オーバーフロー上で、デバッガがブレークポイント
を検出するときとまったく同じように、デバッガ内で動作が停止します。スタック・
オーバーフローのチェックをイネーブルするには、BSP エディタ内にある Settings タ
ブの Advanced の hal で、enable_runtime_stack_checking をクリックします。
f 命令関連の例外ハンドラについて詳しくは、Nios II Software Developer’s Handbook の
Exception Handling の章の「The Instruction-Related Exception Handler」を参照してくださ
い。
ハードウェア・アブストラクション・レイヤ（HAL）
アルテラの HAL は、ほとんどの SOPC Builder システム・ペリフェラル用としてデバ
イス・ドライバによって必要とされるインタフェースおよびリソースを提供します。
ユーザーは、これらのドライバを独自の SOPC Builder システム用にカスタマイズおよ
びデバッグすることができます。HAL デバイス・ドライバおよび SOPC Builder ペリ
フェラルについて詳しくは、AN459: Guidelines for Developing a Nios II HAL Device Driver
を参照してください。
ブレークポイント
ユーザーは、ハードウェア・ブレークポイントをフラッシュ・メモリなどの読み出
し専用メモリにあるコード上に設定することができます。読み出し専用のメモリ領
域にブレークポイントを設定する場合、ソフトウェア・ブレークポイントではなく
ハードウェア・ブレークポイントが自動的に選択されます。
ハードウェア・ブレークポイントをイネーブルするには、SOPC Builder 内の Nios II プ
ロセッサのデバッグ・レベルをデバッグ・レベル 2 以上にコンフィギュレーション
する必要があります。SOPC Builder 内の Nios II プロセッサのデバッグ・レベルを適切
なレベルにコンフィギュレーションするには、以下のステップを実行します。
1. SOPC Builder の System Contents のタブで、目的の Nios II プロセッサ・コンポーネ
ントを右クリックします。
2. 右ボタンのポップアップ・メニューの Edit をクリックします。Nios II プロセッサ
のコンフィギュレーションのページが表示されます。
3. 図 3–4 に示されるように JTAG Debug Module タブをクリックします。
4. Level 2、Level 3、または Level 4 を選択します。
5. Finish をクリックします。
エンベデッド・デザイン・ハンドブック
2009 年 12 月
Altera Corporation
第 3 章 : Nios II デザインのデバッグ
ランタイム解析のデバッグ手法
3‒15
選択するデバッグ・レベルに応じて、最大 4 つのハードウェア・ブレークポイント
が使用可能です。図 3–4 に、各デバッグ・レベルで使用可能なハードウェア・ブ
レークポイントの数を示します。デバッグ・レベルが高いほど、FPGA 上でしようす
るロジック・リソースは多くなります。
図 3‒4. Nios II プロセッサ ̶JTAG デバッグ・モジュール ̶SOPC Builder コンフィギュレーション・ページ
f Nios II プロセッサのデバッグ・レベルについて詳しくは、Nios II Processor Reference
Handbook の Instantiating the Nios II Processor in SOPC Builder の章を参照してください。
デバッガ・ステップおよび No 最適化の使用
None （–O0）最適化レベル・コンパイラ・スイッチを使用して、デバッグ用の最適
化をディセーブルします。他の方法では、デバッガのブレークポイントおよびス
テップの動作は、書き込まれたソース・コードに一致しない可能性があります。こ
の動作のコード実行およびハイ・レベルの元のソース・コードの間のミスマッチは、
アセンブラ命令レベルで命令ステップ・モードを使用するために i ボタンをクリック
する場合でも発生する可能性があります。このミスマッチは、コンパイラによる最
適化およびインライニングが元のソース・コードのいくつかを排除したために発生
します。
Eclipse 用の Nios II ソフトウェア・ビルド・ツール内で None （–O0）最適化レベル・
コンパイラ・スイッチを設定するには、以下のステップを実行します。
1. Nios II の画面で、アプリケーション・プロジェクトを右クリックします。オプ
ションのリストが表示されます。
2. リストの Properties をクリックします。Properties for <project name> ダイアログ・
ボックスが表示されます。
2009 年 12 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
3‒16
第 3 章 : Nios II デザインのデバッグ
まとめ
3. 左のペインにある Nios II Application Properties をクリックします。
4. Optimization Level リストの Off を選択します。
5. Apply をクリックします。
6. OK をクリックします。
まとめ
Nios II デザインのデバッグを成功させるには、ボード・レイアウト、FPGA コンフィ
ギュレーション、および Nios II のソフトウェア・ツールとアプリケーション・ソフ
トウェアについての専門技術が必要です。アルテラおよびサードパーティのツール
は、Nios II アプリケーションをデバッグする上で役立ちます。この章では、エンベ
デッド・デザインの困難な問題に対応するデバッグの手法およびツールを説明して
います。
参考資料
この章では以下のドキュメントを参照しています。
■
AN323: Using SignalTap II Embedded Logic Analyzers in SOPC Builder Systems
■
AN391: Profiling Nios II Systems
■
AN446: Debugging Nios II Systems with the SignalTap II Logic Analyzer
■
AN459: Guidelines for Developing a Nios II HAL Device Driver
■
AN543: Debugging Nios II Software Using the Lauterbach Debugger
■
Quartus II Handbook の volume 3 の Design Debugging Using the SignalTap II Embedded
Logic Analyzer の章
■
Embedded Design Handbook の Developing Nios II Software の章
■
Nios II Software Developer’s Handbook の Developing Programs Using the Hardware
Abstraction Layer の章
■
Nios II Software Developer’s Handbook の Exception Handling の章
■
Nios II Processor Reference Handbook の Instantiating the Nios II Processor in SOPC Builder
の章
■
Nios II Software Developer's HandbookのGetting Started with the Graphical User Interfaceの
章
■
Quartus II Handbook の volume 5 の Performance Counter Core の章
■
Quartus II Handbook の volume 5 の System ID Core の章
■
Quartus II Handbook の volume 5 の Timer Core の章
■
Embedded Design Handbook の Verification and Board Bring-Up の章
エンベデッド・デザイン・ハンドブック
2009 年 12 月
Altera Corporation
第 3 章 : Nios II デザインのデバッグ
改訂履歴
3‒17
改訂履歴
表 3–1 に、本資料の改訂履歴を示します。
表 3‒1. 改訂履歴
バー
ジョン
日付
2009 年 12 月
1.3
変更内容
■
Eclipse 用の Nios II ソフトウェア・ビルド・ツールの更新。
■
すべての Nios II IDE 命令を削除。Nios II IDE 命令のすべてのインスタンスを
Eclipse 用の Nios II ソフトウェア・ビルド・ツールの命令に置き換え。
■
新しいアプリケーション・ノートの AN543: Debugging Nios II Software Using the
Lauterbach Debugger を参照先として追加。
■
新しいアプリケーション・ノートによって生じた冗長な情報を「Lauterbach の
Trace32 デバッガおよび PowerTrace ハードウェア」の項から削除。
2009 年 4 月
1.2
2008 年 6 月
1.1
目次の訂正。
2008 年 3 月
1.0
初版。
2009 年 12 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
3‒18
エンベデッド・デザイン・ハンドブック
第 3 章 : Nios II デザインのデバッグ
改訂履歴
2009 年 12 月
Altera Corporation
4. Nios II コマンド・ライン・ツール
July 2011
ED51004-2.2
ED51004-2.2
はじめに
この章では、Nios II Embedded Development Suite（EDS）付きの Nios® II コマンド・ラ
イン・ツールについて説明します。章では、Altera® ツールと、GNU ツールの両方に
ついて説明します。コマンドのほとんどは、Nios II EDS トのインストールの bin およ
び sdk2 サブディレクトリにあります。
アルテラのコマンド・ライン・ツールは、ボードおよびシステム・レベルのデバッ
グから FPGA コンフィギュレーション・ファイル（.sof）をプログラミングするさま
ざまな活動のために有用です。これらのツールについては、例は Nios II Software
Developer’s Handbook の Nios II Software Build Tools の章の 「Altera-Provided Embedded
Development Tools」での Nios II プログラムを開発するアルテラが提供するコマンド・
ライン・ツールの簡単な説明に展開します。Nios II GCC ツールチェインでは、GNU
Compiler Collection、GNU Binary Utilities （binutil）、および newlib C ライブラリが含まれ
ています。
1
すべてのこの章で説明するコマンドは、Nios II コマンド・シェルで提供さ
れています。ほとんどのコマンドは、以下のように入力してこのシェルで
ヘルプを入手することができます。
<command name> --help r
Windows プラットフォーム上で Nios II コマンド・シェルを起動するには、
Start メニューの All Programs をクリックします。All Programs メニューの
アルテラのサブメニューで、Nios II EDS に <version> のサブメニューで、
Nios II <version> Command Shell をクリックします。
<Nios II EDS install path>/nios2_command_shell.shr
コマンド・シェルは、事前にコンフィギュレーションされた環境との
Bourne-Again シェル（bash）のです。
ボードの立ち上げと診断ためのアルテラのコマンド・ライン・
ツール
この項では、Nios 開発ボードの立ち上げおよびデバッグに役立ちアルテラのコマン
ド・ライン・ツールについて説明します。
jtagconfig
このコマンドは、デバッグやプログラミングで使用するための JTAG インタフェース
を介してホスト PC に接続されたデバイスに関する情報を返します。正しく FPGA を
構成しているかどうかを確認するには、このコマンドを使用します。
他のコマンドの多くは、成功した JTAG 接続によって異なります。他のコマンドを使
用できない場合、JTAG チェーンは、この章での例として使用される単純なシング
ル・デバイスのチェーンと異なっているかどうかを確認してください。
© 2011 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, HARDCOPY, MAX, MEGACORE, NIOS, QUARTUS and STRATIX are Reg. U.S. Pat. & Tm. Off.
and/or trademarks of Altera Corporation in the U.S. and other countries. All other trademarks and service marks are the property of their respective holders as described at
www.altera.com/common/legal.html. Altera warrants performance of its semiconductor products to current specifications in accordance with Altera’s standard warranty, but
reserves the right to make changes to any products and services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Altera. Altera customers are advised to obtain the latest version of device
specifications before relying on any published information and before placing orders for products or services.
エンベデッド・デザイン・ハンドブック
2011 年７月
Subscrib
Chapter 4: Nios II コマンド・ライン・ツール
ボードの立ち上げと診断ためのアルテラのコマンド・ライン・ツール
4–2
オプションのリストと簡単な使用方法の説明文を表示する Nios II コマンド・シェル
から jtagconfig --help を入力します。
jtagconfig 使用方法
jtagconfig コマンド使用するには、以下のステップを実行してください。
1. Nios II のコマンド・シェルを開きます。
2. コマンド・シェルで、以下のコマンドを入力します。
jtagconfig -n r
例 4–1 には、jtagconfig -n コマンドの典型的なシステムの応答を示します。
例 4‒1. jtagconfig 応答の例
[SOPC Builder]$ jtagconfig -n
1) USB-Blaster [USB-0]
020050DD
EP1S40/_HARDCOPY_FPGA_PROTOTYPE
Node 11104600
Node 0C006E00
応答内の情報は、そのコンフィギュレーションおよび JTAG 接続ケーブルの種類特定
の FPGA によって異なります。表 4–1 には、例 4–1 での応答に表示される情報を示し
ます。
表 4‒1. jtagconfig コマンド応答のインタプリテイション
値
説明
USB-Blaster [USB-0]
ケーブルのタイプ。ワークステーションに接続された複数の
ケーブルを持つことができます。
EP1S40/_HARDCOPY_FPGA_PROTOTYPE
シリコン識別番号によって識別されるデバイス名。
Node 11104600
FPGA 内部の JTAG ノードのノード番号。11104600 と 11046FF 間
のノード数の外観は、包括的にこのシステムの応答に JTAG デ
バッグ・モジュールを搭載した Nios II プロセッサを持っている
ことを確認します。
Note 0C006E00
FPGA 内部の JTAG ノードのノード番号。包括的にこのシステム
の応答における 0C006E00 と 0C006EFF 間のノード番号の外観
は、JTAG UART コンポーネントを持っていることを確認します。
デバイス名は Quartus® II のインストールでテキスト・ファイルの pgm_parts.txt から
読み込まれます。例 4–1 には、名前の EP1S40<device-specific name> をマップする
FPGA デバイスの JTAG チェーン上のシリコン識別番号は 020050DD であるため、スト
リングの _HARDCOPY_FPGA_PROTOTYPE で終了します。内部ノードは、システム・
レベルのデバッグ（SLD）のハブのノードです。アルテラの FPGA へのすべての JTAG
通信は、SignalTap® II エンベデッド・ロジック・アナライザおよび Nios II EDS のデ
バッグ機能などの高度なデバッグ機能を含めて、このハブを通過します。
例 4–1 は、シングル・デバイスの JTAG チェーンに接続されたシングル・ケーブルを
示します。ただし、お使いのコンピュータは、異なるシステムに接続された複数の
JTAG ケーブルを持つことができます。これらの各システムには、その JTAG チェイ
ン内の複数のデバイスを持つことができます。各デバイスには、複数の JTAG デバッ
グ・モジュールは、JTAG UART モジュール、および JTAG ノードの他の種類を持つこ
とができます。ホスト PC への JTAG 接続でデバイスを理解し、それらにアクセスす
ることができますどのように支援する jtagconfig -n コマンドを使用します。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
Chapter 4: Nios II コマンド・ライン・ツール
ボードの立ち上げと診断ためのアルテラのコマンド・ライン・ツール
4–3
nios2-configure-sof
このコマンドは、指定された .sof をダウンロードし、その内容に応じて FPGA をコン
フィギュレーションします。Nios II コマンド・シェルのプロンプトで
nios2-configure-sof --help を入力して使用可能なコマンド・ライン・オプション
のリストが表示されます。
1
接続されるお使いのコンピュータに複数の JTAG ケーブル（USB-Blaster™ または
ByteBlaster™ ケーブル）を持っている場合、または JTAG チェイン内の複数のデバイス
（FPGA）を持っている場合、ケーブルとデバイスを指定する必要があります。この目
的のために--cable および --device のオプションを使用します。
nios2-configure-sof 使用する方法
nios2-configure-sof コマンドを使用するには、以下のステップを実行します。
1. Nios II コマンド・シェルを開きます。
2. コマンド・シェルで、.sof が配置されているディレクトリに変更します。デフォ
ルトで、正しい場所はトップ・レベルの Quartus II プロジェクト・ディレクトリ
です。
3. コマンド・シェルで、次のコマンドを入力します。
nios2-configure-sof r
Nios II EDS は .sof の現在のディレクトリを検索し、指定された JTAG ケーブルを
介して、プログラムします。
system-console
system-console コマンドでは、低レベルの JTAG チェーンの検証およびフル・システ
ム・レベルの検証をサポートする Tcl ベースのコマンドシェルを起動します。この
ツールは、バージョン 8.0 で開始する Nios II EDS で提供されています。
このアプリケーションは、特にシステムを起動する場合に、低レベルのシステムの
デバッグのために非常に有用です。これは、Tcl ベースのスクリプト環境やご使用の
システムをテストするための多くの機能を提供します。
次の重要なコマンド・ラインのオプションは、system-console コマンドのために使
用可能です：
2011 年７月
■
--script=<your script>.tcl オプションは、Tcl スクリプトを実行する System Console
をダイレクトします。
■
--cli オプションは、新しいウィンドウを開かずに既存のシェルで開くように
System Console をダイレクトします。
■
--debug オプションは、stderr. に追加のデバッグ出力をリダイレクトするように、
System Console をダイレクトします。
■
-project-dir=<project dir> オプションは、ハードウェア・プロジェクトの場所に
System Console をダイレクトします。JTAG チェーンの詳細およびその他の情報
は、特定のプロジェクトに依存しているため、意図したプロジェクトで作業して
いることを確認します。
■
--jdi=<JDI file> オプションは、プロジェクト内の JTAG チェーン要素の
name-to-node マッピングを指定します。
Altera Corporation
エンベデッド・デザイン・ハンドブック
Chapter 4: Nios II コマンド・ライン・ツール
ハードウェア開発のためのアルテラのコマンド・ライン・ツール
4–4
f System Console の使用例およびシステム・コンソール・コマンドの包括的なリストに
ついて詳しくは、「Quartus II ハンドブック Volume 3 」の「 Analyzing and Debugging
Designs with the System Console」を参照してください。オンライン・トレーニングは
http://www.altera.com/training で提供されています。
ハードウェア開発のためのアルテラのコマンド・ライン・ツール
このセクションでは、ハードウェアのプロジェクト開発のための有用なアルテラの
コマンド・ライン・ツールについて説明します。プロジェクトは Nios II プロセッサ
が有っても無くても、SOPC Builder で作成したすべてのプロジェクトのために有用で
す。
quartus_cmd and sopc_builder
これらのコマンドは、SOPC Builder システムとそれに対応する Quartus II プロジェク
トのコンパイルの生成を自動化するスクリプトを作成します。
Quartus II プロジェクトをビルドするために必要な最小限のソース・ファイルを保持
するフローを作成するためにこれらのコマンドを使用できます。新規プロジェクト
の開発のための基礎として使用する既存のプロジェクトをコピーする場合は、ソー
ス・ファイルの最小セットだけをコピーする必要があります。同様に、バージョン・
コントロール・システムにファイルをチェックインするとき、プロジェクトを再構
築するために必要な最小限のセットを確認します。
SOPC Builder システムを再構成するには、以下のファイルが必要です：
■
<project>.qpf（Quartus II のプロジェクトファイル）
■
<project>.qsf（Quartus II の設定ファイル）
■
<SOPC Builder system>.sopc（SOPC Builder システムの説明）
■
既存のプロジェクトでの追加 HDL、BDF、または BSF ファイル
Quartus II のインストールで提供されているハードウェアのデザイン例を使用して作
業する場合、一次ソース・ファイルを不注意に修正しないようにするために、作業
ディレクトリにソース・ファイルの各セットをコピーすることを推奨します。新し
い作業ディレクトリ上でスクリプトを実行してください。
最低限のソース・ファイルを保持するフローを作成するには、以下のステップを実
行します。
1. 他の場所でそれぞれのソース・ファイルの正確なコピーを維持し、作業ディレク
トリに必要なソース・ファイルをコピーします。
2. この作業ディレクトリに移動します。
3. FPGA を構成する .sof を生成するには、次のコマンド・シーケンスを入力します。
sopc_builder –-no_splash –s –-generate r
quartus_cmd <project>.qpf -c <project>.qsf r
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
Chapter 4: Nios II コマンド・ライン・ツール
ハードウェア開発のためのアルテラのコマンド・ライン・ツール
4–5
例 4–2 のシェル・スクリプトは、これらのコマンドを示しています。このスクリプ
トは、SOPC Builder システムを生成し、サブディレクトリの任意の数を越えて
Quartus II プロジェクトをコンパイルするプロセスを自動化します。スクリプトは、
あくまで一例であり、プロジェクトのために変更が必要かもしれません。Quartus II
プロジェクトをコンパイルする場合は、1 にスクリプトで COMPILE_QUARTUS の変数
を設定します。
例 4‒2. システムを生成するスクリプトおよび Quartus II プロジェクトをコンパイルするスクリプト ( その
１)
#!/bin/sh
COMPILE_QUARTUS=0
#
# Resolve TOP_LEVEL_DIR, default to PWD if no path provided.
#
if [ $# -eq 0 ]; then
TOP_LEVEL_DIR=$PWD
else
TOP_LEVEL_DIR=$1
fi
echo "TOP_LEVEL_DIR is $TOP_LEVEL_DIR"
echo
#
# Generate SOPC list...
#
SOPC_LIST=`find $TOP_LEVEL_DIR -name "*.sopc"`
#
# Generate Quartus II project list.
#
PROJ_LIST=`find $TOP_LEVEL_DIR -name "*.qpf" | sed s/\.qpf//g`
#
# Main body of the script. First "generate" all of the SOPC Builder
# systems that are found, then compile the Quartus II projects.
#
#
# Run SOPC Builder to "generate" all of the systems that were found.
#
for SOPC_FN in $SOPC_LIST
do
cd `dirname $SOPC_FN`
if [ ! -e `basename $SOPC_FN .sopc`.vhd -a ! -e `basename $SOPC_FN .sopc`.v ]; then
echo; echo
echo "INFO: Generating $SOPC_FN SOPC Builder system."
sopc_builder -s --generate=1 --no_splash
if [ $? -ne 4 ]; then
echo; echo
echo "ERROR: SOPC Builder generation for $SOPC_FN has failed!!!"
echo "ERROR: Please check the SOPC file and data " \
"in the directory `dirname $SOPC_FN` for errors."
fi
else
echo; echo
echo "INFO: HDL already exists for $SOPC_FN, skipping Generation!!!"
fi
cd $TOP_LEVEL_DIR
done
#
# Continued...
#
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
Chapter 4: Nios II コマンド・ライン・ツール
フラッシュ・プログラミング用のアルテラのコマンド・ライン・ツール
4–6
例 4‒2. システムを生成するスクリプトおよび Quartus II プロジェクトをコンパイルするスクリプト ( その
２)
#
# Now, generate all of the Quartus II projects that were found.
#
if [ $COMPILE_QUARTUS ]; then
for PROJ in $PROJ_LIST
do
cd `dirname $PROJ`
if [ ! -e `basename $PROJ`.sof ]; then
echo; echo
echo "INFO: Compiling $PROJ Quartus II Project."
quartus_cmd `basename $PROJ`.qpf -c `basename $PROJ`.qsf
if [ $? -ne 4]; then
echo; echo
echo "ERROR: Quartus II compilation for $PROJ has failed!!!."
echo "ERROR: Please check the Quartus II project “ \
“in `dirname $PROJ` for details."
fi
else
echo; echo
echo "INFO: SOF already exists for $PROJ, skipping compilation."
fi
cd $TOP_LEVEL_DIR
done
fi
c 例 4–2 のコマンドやスクリプトは例えばだけです。特定の用途のための機能を保証す
るものではありません。
フラッシュ・プログラミング用のアルテラのコマンド・ライン・
ツール
このセクションでは、フラッシュ・メモリに Nios II プロセッサ・ベースのデザイン
ンをプログラミングするためのコマンド・ライン・ツールについて説明します。
プログラム・フラッシュ・メモリに Nios II EDS を使用すると、Nios II EDS は、フラッ
シュ変換コマンドとプログラミング・コマンドを含むシェル・スクリプトを生成し
ます。コマンド・ラインのフラッシュ・プログラミング・フローを開発するための
基礎として、このスクリプトを使用することができます。
f Nios II EDS や Nios II フラッシュ・プログラマおよび関連ツールのコマンド・ラインの
使用方法について詳しくは、Nios II Flash Programmer User Guide を参照してください。
nios2-flash-programmer
このコマンドは、コモン・フラッシュ・インタフェース（CFI）メモリをプログラム
します。Nios II フラッシュ・プログラマは JTAG インタフェースを使用しているので、
nios2-flash-programmer コマンドはこのインタフェースに同じオプションを持って
います（他のコマンドと同じ）。--help オプションを指定してこのコマンドのコマン
ド・ライン・オプションに関する情報を入手することができます。
nios2-flash-programmer の使用例
CFI デバイスをプログラムするには、以下のステップを実行することができます。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
Chapter 4: Nios II コマンド・ライン・ツール
フラッシュ・プログラミング用のアルテラのコマンド・ライン・ツール
4–7
1. または CFI デバイスに正常にインタフェースするデザインで FPGA をプログラム
するために、4–9 ページの「nios2-download」でのステップに従うか、または
Nios II EDS を使用しています。
2. フラッシュ・デバイスが正しく検出されていることを確認するために次のコマン
ドを入力します
nios2-flash-programmer –debug –base=<base address>r
ここで、<base address> はフラッシュ・デバイスのベース・アドレス。各コン
ポーネントのベース・アドレスは SOPC Builder に表示されます。フラッシュ・デ
バイスが検出された場合、フラッシュ・メモリの CFI テーブルの内容が表示され
ます。
3. 「elf2flash, bin2flash, および sof2flash」のセクションで説明されているユーティリ
ティの elf2flash, bin2flash, または sof2flash のいずれかを使用してフラッ
シュ・フォーマット（.flash）を変換します。
4. CFI デバイスに生じた .flash ファイルをプログラムするために次のコマンドを入
力します。
nios2-flash-programmer –base=<base address> <file>.flashr
5. 必要に応じて、そのリセット・アドレスにプロセッサをリセットして起動するに
は、次のコマンドを入力します。
nios2-download –g –rr
elf2flash, bin2flash, および sof2flash
これら 3 つのコマンドは、常に nios2-flash-programmer コマンドで使用されていま
す。結果の .flash ファイルは標準の .srec ファイルです。
以下の 2 つの重要なコマンド・ライン・オプションが elf2flash コマンドで使用で
きます：
■
-boot=<boot copier file>.srec オプションは、変換された ELF ファイルにブートロー
ダの S レコード・ファイルを前付加する elf2flash コマンドに指示します。
■
-after=<flash file>.flash オプションは、生成された .flash ファイルを配置します。
変換された ELF ファイルはフラッシュ・メモリに指定されたフラッシュ・ファイ
ルに従います。
-after オプションは、一般的にすぐに Erasable、Programmable、Configurable Serial
（EPCS）フラッシュ・デバイスに .sof の次に .elf ファイルを配置するために使用
されます。
c EPCS デバイスを使用する場合は、ソフトウェア・イメージをプログラムする前に、
デバイス内のハードウェア・イメージをプログラムする必要があります。このルー
ルを無視した場合、ソフトウェア・イメージが破損します。
例 4–3 にはサンプル自動生成スクリプトを示します。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
Chapter 4: Nios II コマンド・ライン・ツール
フラッシュ・プログラミング用のアルテラのコマンド・ライン・ツール
4–8
任意のフラッシュ・デバイスに書き込む前に、書き込みを期待する Nios II フラッ
シュ・プログラマはセクター全体を消去します。しかし、EPCS デバイスでは、
elf2flash -after オプションを使用してソフトウェア・イメージを生成する場合、
Nios II フラッシュ・プログラマは直接ハードウェア・イメージに続くソフトウェア・
イメージを配置します（次のフラッシュ・セクタ境界ではなく）。したがって、この
場合に、Nios II フラッシュ・プログラマはソフトウェア・イメージを配置する前に、
現在のセクタを消去しません。ただし、ハードウェア・イメージを配置する前に、
現在のセクタを消去します。
Nios II IDE を介してフラッシュ・プログラマを使用するときは、自動的にこれらのコ
マンドのいくつかを含むスクリプトを作成します。フラッシュ・ライタを実行する
と、プロジェクトの Debug または Release ターゲット・ディレクトリ内のシェル・
スクリプト（.sh）を作成します。このスクリプトは、フラッシュ・メモリをプログ
ラムするために使用するコマンドの詳細なステップが含まれています。
例 4–3 は、サンプル自動生成されたスクリプトを示しています。
例 4‒3. 自動生成スクリプトのサンプル
#!/bin/sh
#
# This file was automatically generated by the Nios II IDE Flash Programmer.
#
# It will be overwritten when the flash programmer options change.
#
cd <full path to your project>/Debug
# Creating .flash file for the FPGA configuration
#"<Nios II EDS install path>/bin/sof2flash" --offset=0x400000 \
--input="full path to your SOF" \
--output="<your design>.flash"
# Programming flash with the FPGA configuration
#"<Nios II EDS install path>/bin/nios2-flash-programmer" --base=0x00000000 \
--sidp=0x00810828 --id=1436046714 \
--timestamp=1169569475 --instance=0 "<your design>.flash"
#
# Creating .flash file for the project
"<Nios II EDS install path>/bin/elf2flash" --base=0x00000000 --end=0x7fffff \
--reset=0x0 \
--input="<your project name>.elf" --output="ext_flash.flash" \
--boot="<path to the bootloader>/boot_loader_cfi.srec"
# Programming flash with the project
"<Nios II EDS install path>/bin/nios2-flash-programmer" --base=0x00000000 \
--sidp=0x00810828 --id=1436046714 \
--timestamp=1169569475 --instance=0 "ext_flash.flash"
# Creating .flash file for the read only zip file system
"<Nios II EDS install path>/bin/bin2flash" --base=0x00000000 --location=0x100000\
--input="<full path to your binary file>" --output="<filename>.flash"
# Programming flash with the read only zip file system
"<Nios II EDS install path>/bin/nios2-flash-programmer" --base=0x00000000 \
--sidp=0x00810828 --id=1436046714 \
--timestamp=1169569475 --instance=0 "<filename>.flash"
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
Chapter 4: Nios II コマンド・ライン・ツール
ソフトウェア開発およびデバッグするためのアルテラのコマンド・ライン・ツール
4–9
自動生成スクリプト内のパス、ファイル名、およびアドレスは、変換されファイル
の名前と場所、そしてハードウェア・デザインのコンフィギュレーションに応じて
変更します。
bin2flash の使用例
フラッシュ・メモリへの任意のバイナリ・ファイルをプログラムするには、以下の
ステップを実行します。
1. .flash フラッシュ・ファイルを生成するには、以下のコマンドを入力します。
bin2flash --location=<offset from the base address> \
-input=<your file> --output=<your file>.flash r
2. フラッシュ・メモリに新しく作成したファイルをプログラムするために以下のコ
マンドを入力します。
nios2-flash-programmer -base=<base address> <your file>.flash r
ソフトウェア開発およびデバッグするためのアルテラのコマン
ド・ライン・ツール
このセクションでは、ソフトウェア開発およびデバッグのために有用であるアルテ
ラのコマンド・ライン・ツールについて説明します。
nios2-terminal
このコマンドでは、Nios II プロセッサ・サブシステム内の stdin、stdout、および
stderr との接触を確立します。stdin、stdout、および stderr は、このシステム内の
UART（標準 UART または JTAG UART）のモジュールを介して配線されます。
nios2-terminal コマンドを使用すると、stdout、stderr、またはその両方を監視し、
stdin 経由で、Nios II プロセッサ・サブシステムへの入力を提供することができます。
このコマンドは、JTAG ケーブルやデバイスに対して 4–3 ページの
「nios2-configure-sof」で説明される nios2-configure-sof コマンドと同じ動作をしま
す。しかし、複数の JTAG UART モジュールがシステムに存在する可能性があるため、
nios2-terminalコマンドは正しいJTAG UARTモジュールのインスタンスに適用するた
めの明示的な方向性を必要とします。-instance コマンド・ライン・オプションを使
用してインスタンスを指定します。デザインでの最初のインスタンスは 0
（-instance "0"）です。追加のインスタンスは 1（-instance "1"）で始まって、
徐々に番号が付けられています。
nios2-download
のコマンドは Nios II .elf ファイルを解析し、機能する Nios II プロセッサにそれらをダ
ウンロードし、任意に .elf ファイルを実行します。
他のコマンドについては、--help オプションを使用して、コマンド・ライン・オプ
ション情報を入手することができます。nios2-download コマンドは、複数の JTAG
ケーブルと Nios II プロセッサ・サブシステムを扱うする nios2-terminal コマンドと
同じオプションがあります。
nios2-download の使用例
Nios II .elf プログラムをダウンロードする（そして実行する）には、
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
Chapter 4: Nios II コマンド・ライン・ツール
ソフトウェア開発およびデバッグするためのアルテラのコマンド・ライン・ツール
4–10
1. Nios II コマンド・シェルを開きます。
2. .elf ファイルが配置されているディレクトリを変更します。開発のための Nios II
IDE を使用する場合、正しい場所はいつもトップ・レベルのプロジェクトの
Debug または Release サブディレクトです。Nios II SBT を使用すると、正しい場
所は app フォルダです。
3. プログラムをダウンロードとスタートするには、コマンド・シェルで、次のコマ
ンドを入力します。
nios2-download -g <project name>.elf r
4. 必要に応じて、任意の出力を表示したり、実行中のプログラムへの入力を提供す
るために接続する nios2-terminal コマンドを使用します。
nios2-stackreport
このコマンドは、プロジェクトの .elf ファイルからスタックとヒープにまだ使用可
能なメモリの量についての簡単なレポートをリターンします。
このコマンドを使用すると、スタックやコードは、ランタイムに消費するヒープ・
スペースの量を決定するためには役立ちませんが、動作するコードのスペースを知
らせます。
例 4–4 に、このコマンドが提供する情報を示します。
例 4‒4. nios2-stackreport のコマンドと応答
[SOPC Builder]$ nios2-stackreport <your project>.elf
Info: (<your project>.elf) 6312 KBytes program size (code + initialized data).
Info:
10070 KBytes free for stack + heap.
nios2-stackreport の使用例
nios2-stackreport コマンドを使用するには、以下のステップを実行します。
1. Nios II コマンド・シェルを開きます。
2. .elf ファイルが置かれているディレクトリに変更します。
3. コマンド・シェルで、以下のコマンドを入力します。
nios2-stackreport <your project>.elf r
validate_zip
Nios II EDS は、Read Only Zip Filing System のために使用するファイルが圧縮されてい
ないことを検証するこのコマンドを使用します。同じ目的のためにそれを使用する
ことができます。
validate_zip の使用例
validate_zip コマンドを使用するには、以下のステップを実行します。
1. Nios II コマンド・シェルを開きます。
2. .zip ファイルが配置されているディレクトリに変更します。
3. コマンド・シェルで、次のコマンドを入力します。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
Chapter 4: Nios II コマンド・ライン・ツール
ソフトウェア開発およびデバッグするためのアルテラのコマンド・ライン・ツール
4–11
validate_zip <file>.zip r
応答が表示されない場合、.zip ファイルは圧縮されなくなります。
nios2-ide
Linux および Windows システムでは、Nios II IDE を起動するコマンド・シェルで
nios2-ide を入力することができます。また、Windows システムでは、SOPC Builder で
の Nios II IDE の起動アイコンを使用できます。
nios2-ide コマンドを直接実行可能ファイルを呼び出すことはありません。代わり
に、nios2-ide 実行可能ファイルを呼び出す単純な Bourne シェルのラッパ・スクリプ
トを実行します。ラッパ・スクリプトの Linux および Windows プラットフォームの
バージョンは以下のとおりです。
Linux ラッパ・スクリプト
#!/bin/sh
# This is the linux-gtk version of the nios2-ide launcher script
# set the default workspace location for linux
WORKSPACE="$HOME/nios2-ide-workspace-7.2"
WORKSPACE_ARGS="-data $WORKSPACE"
# if -data is already passed in, we can't specify it
# again when calling nios2-ide
for i in $*
do
if [ "x$i" = "x-data" ]; then
WORKSPACE_ARGS=""
fi
done
exec <Nios II EDS install path>/bin/eclipse/nios2-ide -configuration
$HOME/.nios2-ide-6.1 $WORKSPACE_ARGS "$@"
Windows ラッパ・スクリプト
#!/bin/sh
# This is the win32 version of the nios2-ide launcher script
# It simply invokes the binary with the same arguments as
# passed in.
# By doing this, the user will default to the same workspace as
# when launched using the Windows shortcut, as "persisted"
# in the configuration/.settings/org.eclipse.ui.ide.prefs file.
cd "<Nios II EDS install path>/bin/eclipse"
exec ./nios2-ide-console "$@"
nios2-gdb-server
このコマンドは、たとえば nios2-elf-gdb のクライアントの GDB クライアントから
の接続のために指定した TCP ポートをリッスンする GNU Debugger （GDB）JTAG コン
ジットを開始します。
GDB サーバー・セッションを終了する必要がある場合があります。GDB サーバー・
セッションを開始して Nios II コマンド・シェル・セッションへのアクセス不可能な
場合、または問題 GDB サーバー・プロセスは誤った Nios II IDE デバッガ・セッショ
ンから結果する場合、Windows プラットフォーム上で nios2-gdb-server.exe のプロセ
スを停止する、または Linux プラットフォーム上で次のコマンドを入力します。
pkill -9 -f nios2-gdb-server r
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
Chapter 4: Nios II コマンド・ライン・ツール
ソフトウェア開発およびデバッグするためのアルテラのコマンド・ライン・ツール
4–12
nios2-gdb-server の使用例
Nios II IDE および他の使用可能なデバッガのほとんどは、デバッグ用する
nios2-gdb-server および nios2-elf-gdb コマンドを使用します。この低レベルでこれ
らのツールを使用する必要はまったくありません。但し、そうすることを好むと、
このセクションでは、これらのコマンドを使用して GDB デバッガ・セッションを開
始する手順および GDB デバッグ・セッションの例が含まれています。
GDB デバッガ・セッションを開始するには、以下のステップを実行することができ
ます。
1. Nios II コマンド・シェルを開きます。
2. デバッグする Nios II システムに JTAG インタフェースを介して接続されたマシン
上での GDB サーバーを起動するには、コマンド・シェルで以下のコマンドを入力
します。
nios2-gdb-server --tcpport 2342 --tcppersist r
転送コントロール・プロトコル・ポートの 2342 が既に使用されている場合、別
のポートを使用します。
以下は、システム応答です。
Using cable "USB-Blaster [USB-0]", device 1, instance 0x00
Pausing target processor: OK
Listening on port 2342 for connection from GDB:
サーバー（ローカルまたはリモートで）に接続してデバッグを開始できるように
なります。
3. .elf ファイルをターゲットする GDB のクライアントを起動するには、次のコマン
ドを入力します。
nios2-elf-gdb <file>.elf r
例 4–5 にはセッションのサンプルを示します。
例 4‒5. デバッグ・セッションのサンプル
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-cygwin --target=nios2-elf"...
(gdb) target remote <your_host>:2342
Remote debugging using <your_host>:2342
OS_TaskIdle (p_arg=0x0) at sys/alt_irq.h:127
127
{
(gdb) load
Loading section .exceptions, size 0x1b0 lma 0x1000020
Loading section .text, size 0x3e4f4 lma 0x10001d0
Loading section .rodata, size 0x4328 lma 0x103e6c4
Loading section .rwdata, size 0x2020 lma 0x10429ec
Start address 0x10001d0, load size 281068
Transfer rate: 562136 bits/sec, 510 bytes/write.
(gdb) step
.
.
.
(gdb) quit
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
Chapter 4: Nios II コマンド・ライン・ツール
アルテラ Nios II ソフトウェア・ビールドのツール
4–13
使用可能なコマンドは、標準のデバッガ・コマンドの負荷、load、step、continue、
run、および quit が含まれています。Ctrl + C を押して GDB サーバー・セッションを終
了させることができます。
nios2-debug
このコマンドでは、Nios II EDS の一部であるアルテラ固有の GNU GDB ディストリ
ビューションと一緒にインストールする Tcl/Tk ベースの Insight GDB GUI のラッパで
す。
コマンド・ライン・オプションの-save-gdb-script はセッション・スクリプトを保
存し、オプションの-command=<GDB script name> は以前に保存された GDB のスクリプ
トを実行して、以前の GDB セッションを復元します。ブレーク・ポイントとウォッ
チ・ポイントを復元するには、このオプションを使用します。
f Insight GDB GUI について詳しくは、sources.redhat.com で入手できる Insight のドキュメ
ントを参照してください。
nios2-debug の使用例
手動で .elf ファイルを生成した後、または Nios II ISBT または Nios II IDE を使用して
生成した後、Insight デバッガ・セッションを開くには、以下のステップを実行しま
す。
1. Nios II コマンド・シェルを開きます。
2. .elf ファイルが配置されているディレクトリに変更します。
開発のための Nios II IDE を使用する場合、正しい場所はいつもトップ・レベルの
プロジェクトの Debug または Release サブディレクトです。
3. コマンド・シェルで、次のコマンドを入力します。
nios2-debug <file>.elf r
.elf ファイルが解析され、Nios II プロセッサ・サブシステム内にメモリにダウン
ロードされ、強調表示された main() ファンクションで実行可能な最初のライン
でメイン・デバッガ・ウィンドウが開きます。このデバッガ・ウィンドウには、
Insight のデバッグ・セッションを表示します。試用に単にコードを実行するため
に Continue メニュー項目をクリックするか、またはいくつかのブレーク・ポイン
トを設定します。
アルテラ Nios II ソフトウェア・ビールドのツール
Nios II ソフトウェア・ビルド・ツールを使用すると、特定の Nios II ハードウェア・
システムのためのアプリケーション、ボード・サポート・パッケージ（BSP）
、およ
びライブラリ・ソフトウェアを作成することができる Nios II コマンド・シェルから
使用可能なコマンド・ライン・ユーティリティです。簡単に自分のビルド・フロー
に合わせて後で変更することができるポータブルの内蔵型メイクファイル・ベース
のプロジェクトを作成するためにこれらのツールを使用してください。
Nios II IDE のベース・フローとは異なり、これらのツールの熟練した使用は GNU メイ
ク・ベースのソフトウェア・ビルド・フローにいくつかの専門知識を必要とします。
これらのツールを使用する前に、「Nios II Software Developer's Handbook」の
「Introduction to the Nios II Software Build Tools」の章および「Nios II Software Developer's
Handbook」の章を参照してください。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
Chapter 4: Nios II コマンド・ライン・ツール
アルテラ Nios II ソフトウェア・ビールドのツール
4–14
以下のセクションでは、ハードウェア設計のために、アプリケーションソフトウェ
アを生成するための BSP を生成するために使用可能なコマンドを要約します。多く
の追加オプションは、Nios II ソフトウェア・ビルド・ツールで提供されています。
f このセクションでのツールの概要については、「Nios II Software Developer's Handbook」
の「 Introduction to the Nios II Software Build Tools」の章を参照してください。
f Nios II ソフトウェア・ビルド・ツールで使用可能な多くの追加オプションについて詳
しくは、「Nios II Software Developer's Handbook」の「 Introduction to the Nios II Software
Build Tools」
、「 Using the Nios II Software Build Tools」、および「 Nios II Software Build
Tools Reference」の章、また「Embedded Design Handbook」の「 Developing Nios II
Software」の章を参照してください。
BSP に関するツール
ハードウェア・デザインのために BSP を作成するには、次のコマンド・ライン・
ツールを使用します。
■
nios2-bsp-create-settings は BSP 設定ファイルを作成します。
■
nios2-bsp-update-settings は BSP 設定ファイルを更新します。
■
nios2-bsp-query-settings は既存の BSP 設定ファイルを 照会します。
■
nios2-bsp-generate-files は提供される BSP 設定ファイルに関するすべてのファ
イルを作成します。
■
nios2-bsp は 前のコマンドのほとんどの機能が含まれているスクリプトです。
■
create-this-bsp は特定のハードウェア・デザイン例のための BSP を作成する高
レベルのスクリプトです。
アプリケーションに関するツール
Nios II アプリケーションとライブラリ・プロジェクトを作成して操作するには、次
のコマンドを使用します。
■
nios2-app-generate-makefile はアプリケーションのメイクファイルを作成しま
す。
■
nios2-lib-generate-makefile はアプリケーション・ライブラリのメイクファイ
ルを作成します。
■
nios2-c2h-generate-makefile は C2H コンパイラのメイクファイル・フラグメン
トを作成します。
■
create-this-app は、特定のハードウェア・デザイン例のアプリケーションを構
築するハイ・レベルのスクリプトです。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
Chapter 4: Nios II コマンド・ライン・ツール
GNU コマンド・ラインのツール
4–15
GNU コマンド・ラインのツール
Nios II GCC ツールチェーンの Nios II GCC は GNU Compiler Collection、GNU binutils、と
newlib C ライブラリが含まれています。Nios II EDS にディストリビューションに含ま
れる Nios II EDS のドキュメント Launchpad から詳細なドキュメントへのリンクをたど
ることができます。Windows プラットフォームでランチパッドを開始するには Start
メニューの All Programs をクリックします。All Programs メニューのアルテラのサブ
メニューの Nios II EDS <version> のサブメニューで、Literature をクリックします。
Linux プラットフォームでは、eb ブラウザで
<Nios II EDS install dir>/documents/index.htm をオープンしてください。また、GNU GCC
ツールチェーンについて詳しくは、World Wide Web 上で入手可能です。
nios2-elf-addr2line
このコマンドは、特定のメモリアドレスに対応したソースコードの行番号をリター
ンします。コマンドは、4–21 ページの「nios2-elf-objdump」で説明される
nios2-elf-objdump コマンドおよび 4–20 ページの「nios2-elf-nm」で説明される
nios2-elf-nm コマンドに類似していますが、それよりもっと具体的です。
特定のメモリ・アドレスに格納されるべきコードを検証するために nios2-elfaddr2line コマンドを使用します。例 4–6 には、その使用方法と結果を示していま
す。
例 4‒6. nios2-elf-addr2line Utility の使用例
[SOPC Builder]$ nios2-elf-addr2line --exe=<your project>.elf 0x1000020
<Nios II EDS install path>/components/altera_nios2/HAL/src/alt_exception_entry.S:99
nios2-elf-addr2line の使用例
nios2-elf-addr2line コマンドを使用するには、以下のステップを実行します。
1. Nios II コマンド・シェルを開きます。
2. コマンド・シェルで、次のコマンドを入力します。
nios2-elf-addr2line <your project>.elf <your_address_0>,\
<your_address_1>,...,<your_address_n> r
プロジェクト・ファイルにこのアドレスにソース・コードが含まれている場合、
ライン番号が表示されます。
nios2-elf-gdb
このコマンドでは、コマンドやスクリプト機能を内蔵したシンプルなシェル・イン
タフェースを提供する GDB のクライアントです。このコマンドの一般的な使用はセ
クション 4–11 ページの「nios2-gdb-server」で示されています。
nios2-elf-readelf
プロジェクトの .elf ファイルから情報を解析するためにこのコマンドを使用します。
このコマンドは、.elf ファイルから特定の情報を抽出するための grep、sed、または
awk で使用するときに便利です。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
Chapter 4: Nios II コマンド・ライン・ツール
GNU コマンド・ラインのツール
4–16
nios2-elf-readelf の使用例
.elf ファイル内の特定の関数名のすべてのインスタンスに関する情報を表示するに
は、以下のステップを実行します。
1. Nios II コマンド・シェルを開きます。
2. コマンド・シェルで、次のコマンドを入力します。
nios2-elf-readelf -symbols <project>.elf | grep <function name> r
例 4–7 には .elf ファイルの http_read_line() ファンクションの検索を示します。
例 4‒7. ios2-elf-readelf で http_read_line ファンクションを検索
[SOPC Builder]$ nios2-elf-readelf.exe –s my_file.elf | grep http_read_line
1106: 01001168
160 FUNC
GLOBAL DEFAULT
3 http_read_line
表 4–2 には例 4–7 での各列の意味を示します。
表 4‒2. nios2-elf-readelf コマンド応答の解釈
値
説明
1106
シンボルのインスタンス番号
0100168
メモリ・アドレス（16 進形式で）
160
シンボルのサイズ（バイトで）
FUNC
シンボルのタイプ（関数で）
GLOBAL
結合（値 : GLOBAL, LOCAL, および WEAK）
DEFAULT
可視性（値 : DEFAULT, INTERNAL, HIDDEN, および PROTECTED）
3
インデックス
http_read_line
シンボル名
ELF ファイル・フォーマットのオンラインについての更なる情報を入手することがで
きます。ELF 形式のユーティリティのそれぞれが独自の man ページがあります。
nios2-elf-ar
このコマンドは、オブジェクトのライブラリ（.o）ファイルを含むアーカイブ（.a）
ファイルを生成します。Nios II IDE は、このコマンドを使用して、System Library プロ
ジェクトをアーカイブします。
nios2-elf-ar の使用例
nios2-elf-ar コマンドでオブジェクト・ファイルをアーカイブするには、以下のス
テップを実行します。
1. Nios II コマンド・シェルを開きます。
2. オブジェクト・ファイルが置かれたディレクトリに変更します。
3. コマンド・シェルで、次のコマンドを入力します。
nios2-elf-ar q <archive_name>.a <object files>
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
Chapter 4: Nios II コマンド・ライン・ツール
GNU コマンド・ラインのツール
4–17
例 4–8 には、現在のディレクトリ内のすべてのオブジェクト・ファイルのアーカイ
ブを作成する方法を示します。例 4–8 で、q オプションはアーカイブの最後に検出し
た各オブジェクト・ファイルを追加するコマンドを指示します。アーカイブ・ファ
イルが作成されたら、長いオブジェクト・ファイル・リストの代わりに、リンカ・
コマンドの引数として使用するために配布し、含めることができます。
例 4‒8. nios2-elf-ar コマンド応答
[SOPC Builder]$ nios2-elf-ar q <archive_name>.a *.o
nios2-elf-ar: creating <archive_name>.a
リンカ
最終的な実行可能に ELF にオブジェクト・ファイルとアーカイブをリンクするため
に nios2-elf-g++ のコマンドを使用します。
リンカの使用例
オブジェクト・ファイルとアーカイブを .elf ファイルにリンクするには、Nios II コマ
ンド・シェルを開いて、適切な引数で nios2-elf-g++ を呼び出します。次のコマン
ド・ラインの例では、リンカを呼び出します。
nios2-elf-g++ -T'<linker script>' -msys-crt0='<crt0.o file>' \
-msys-lib=<system library> -L '<The path where your libraries reside>' \
-DALT_DEBUG -O0 -g -Wall -mhw-mul -mhw-mulx -mno-hw-div \
-o <your project>.elf <object files> -lm r
実行可能ファイルをリンクするための正確なリンカのコマンド・ラインでは異なる
場合があります。Nios II SBT または Nios II IDE でプロジェクトをビルドすると、アプ
リケーションをリンクするために使用されるコマンド・ラインを見ることができま
す。Nios II IDE でこのオプションをオンにするには、Window メニューの Preferences
をクリックします。そして、Nios II タブを選択し、Show command lines when running
make をイネーブルします。また、Nios II コマンド・シェルから -s オプションを指定
せずに make を実行することによって、コマンド・ラインを表示させます。
1
プログラムをリンクするためにネイティブ・リンカの nios2-elf-ld を使用しないこ
とを推奨します。Nios II プロセッサの場合、すべてのソフトコア・プロセッサ用と同
じく、リンク・フローが複雑です。g++ （nios2-elf-g++）コマンドのオプションは、
このフローを簡素化します。オプションのほとんどは、-m コマンド・ライン・オプ
ションで指定されましたが、使用可能なオプションは、選択されたプロセッサに依
存しています。
nios2-elf-size
このコマンドは、プログラムとその基本的なコード・セクションの合計サイズが表
示されます。
nios2-elf-size の使用例
プログラムのサイズ情報を表示するには、以下のステップを実行します。
1. Nios II コマンド・シェルを開きます。
2. .elf ファイルが置かれているディレクトリーに変更します。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
Chapter 4: Nios II コマンド・ライン・ツール
GNU コマンド・ラインのツール
4–18
3. コマンド・シェルで、次のコマンドを入力します。
nios2-elf-size <project>.elf
例 4–9 には、このコマンドが提供されたサイズ情報を示します。
例 4‒9. nios2-elf-size のコマンドの使用率
[SOPC Builder]$ nios2-elf-size my_project.elf
text
data
bss
dec
hex filename
272904
8224 6183420 6464548 62a424 my_project.elf
nios2-elf-strings
このコマンドは、.elf ファイル内のすべての文字列が表示されます。
nios2-elf-strings の使用例
コマンドは、単一の必須の引数があります。
nios2-elf-strings <project>.elf
nios2-elf-strip
このコマンドは、オブジェクト・ファイルからシンボルをすべて除去します。ELF
ファイル、オブジェクト・ファイル（.o）、およびアーカイブ・ファイル（.a）を含
めて、すべてのオブジェクト・ファイルがサポートされています。
nios2-elf-strip の使用例
nios2-elf-strip <options> <project>.elf
nios2-elf-strip Usage Notes
nios2-elf-strip コマンドは .elf ファイルのサイズが小さくなります。
このコマンドは Nios II プロセッサがネイティブの ELF をサポートするオペレーティ
ング・システムを実行している場合にのみ便利です。ELF はネイティブの実行形式で
ある場合、全体の .elf ファイルはメモリにに格納されており、サイズの節約の問題
である。それ以外の場合、ファイルが解析され、命令とデータは、いかなる場合で
もシンボルなしで直接メモリに格納されています。
Linux はネイティブに ELF をサポートするオペレーティング・システムですが、
uClinux は別です。uClinux は、ELF から直接変換されるフラット（FLT）の実行可能形
式を使用しています。
nios2-elf-gdbtui
このコマンドでは、端末が典型的な GDB コンソールに次にソース・コードを表示す
る GDB セッションを開始します。
nios2-elf-gdbtui コマンドのシンタックスは、4–15 ページの「nios2-elf-gdb」で説明
される ios2-elf-gdb コマンドの場合と同じです
1
二つの追加 GDB のユーザー・インタフェースでは、Nios II GDB デバッガで使用するた
めに用意されます。カーソル・ベースの GDB UI の CGDB は、www.sourceforge.net で入
手可能です。Data Display Debugger（DDD）が強く推奨されます。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
Chapter 4: Nios II コマンド・ライン・ツール
GNU コマンド・ラインのツール
4–19
nios2-elf-gprof
このコマンドでは、Nios II システムをプロファイリングすることができます。
f このコマンドおよび Nios II EDS ベースの結果の GUI について詳しくは、
「Nios システム
のプロファイリング」を参照してください。
nios2-elf-insight
4–13 ページの「nios2-debug」に記載される nios2-debug コマンドは、指定された
.elf ファイル上の Insight デバッガ・セッションを開始するには、このコマンドを使
用しています。
nios2-elf-gcc and g++
これらのコマンドは、Nios II プロセッサ用にそれぞれ GNU C および C++ コンパイラ
を実行します。
コマンドのコンパイル の使用例
次の簡単な例では、GNU C または C++ コンパイラを実行するコマンド・ラインを示
します。
nios2-elf-gcc(g++) <options> -o <object files> <C files>
より複雑なコンパイルの例
例 4–10 は、多くのディレクトリ内の複数のファイル内に C のコードをコンパイルす
る Nios II EDS に生成されたコマンド・ラインです。
例 4‒10. nios2-elf-gcc コマンド・ラインの例
nios2-elf-gcc -xc -MD -c \
-DSYSTEM_BUS_WIDTH=32 -DALT_NO_C_PLUS_PLUS -DALT_NO_INSTRUCTION_EMULATION \
-DALT_USE_SMALL_DRIVERS -DALT_USE_DIRECT_DRIVERS -DALT_PROVIDE_GMON \
-I.. -I/cygdrive/c/Work/Projects/demo_reg32/Designs/std_2s60_ES/software/\
reg_32_example_0_syslib/Release/system_description \
-I/cygdrive/c/altera/70_b31/ip/sopc_builder_ip/altera_avalon_timer/HAL/inc \
-I/cygdrive/c/altera/70_b31/ip/sopc_builder_ip/altera_avalon_timer/inc \
-I/cygdrive/c/altera/70_b31/ip/sopc_builder_ip/altera_avalon_jtag_uart/HAL/inc \
-I/cygdrive/c/altera/70_b31/ip/sopc_builder_ip/altera_avalon_jtag_uart/inc \
-I/cygdrive/c/altera/70_b31/ip/sopc_builder_ip/altera_avalon_pio/inc \
-I/cygdrive/c/altera/70_b31/ip/sopc_builder_ip/altera_avalon_lcd_16207/HAL/inc \
-I/cygdrive/c/altera/70_b31/ip/sopc_builder_ip/altera_avalon_lcd_16207/inc \
-I/cygdrive/c/altera/70_b31/ip/sopc_builder_ip/altera_avalon_sysid/HAL/inc \
-I/cygdrive/c/altera/70_b31/ip/sopc_builder_ip/altera_avalon_sysid/inc \
-I/cygdrive/c/altera/70_b31/nios2eds/components/altera_nios2/HAL/inc \
-I/cygdrive/c/altera/70_b31/nios2eds/components/altera_hal/HAL/inc \
-DALT_SINGLE_THREADED -D__hal__ -pipe -DALT_RELEASE -O2 -g -Wall\
-mhw-mul -mhw-mulx -mno-hw-div -o obj/reg_32_buttons.o ../reg_32_buttons.c
nios2-elf-c++filt
このコマンドは、C++ マングルされた名をデマングルします。C++ は、自分のパラ
メータ・リストが異なる場合、複数の関数に同じ名前を付けることができます。そ
れぞれのユニークな機能を追跡するために、コンパイラは関数名をマングルまたは
修飾します。各コンパイラは特定の関数で機能を符号化します。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
Chapter 4: Nios II コマンド・ライン・ツール
GNU コマンド・ラインのツール
4–20
f 異なるコンパイラが C++ の関数名のマングルを含む完全な説明については、C++ 言語
のコンパイラの標準的なレファランス・ソースを参照してください。
nios2-elf-c++filt の使用例
特定のシンボル名に対応するオリジナル、デマングル関数名を表示するには、次の
コマンドを入力することができます。
nios2-elf-c++filt -n <symbol name> r
たとえば、
nios2-elf-c++filt -n _Z11my_functionv r
より複雑な nios2-elf-c++filt の例
次の例でのコマンド・ラインは、ファイル全体のすべてのデマングル関数名の表示
を引き起こします。
nios2-elf-strings <file>.elf | grep ^_Z | nios2-elf-c++filt -n
この例で、nios2-elf-strings の動作は .elf ファイル内のすべての文字列を出力しま
す。この出力は、Z で始まるすべての文字列を識別する grep の動作にパイプされま
す。（GCC は常に Z でマングルされた関数名の前に付加）。grep コマンドの出力は
nios2-elf-c++filt のコマンドにパイプされます。結果は、GCC C++ .elf ファイル内の
すべてのデマングル関数のリストです。
nios2-elf-nm
このコマンドは、.elf ファイル内のシンボルをリストアップします。
nios2-elf-nm の使用例
以下の 2 つの簡単な例では、nios2-elf-nm コマンドの使用例を示します。
■
nios2-elf-nm <project>.elf r
■
nios2-elf-nm <project>.elf | sort -n r
より複雑な nios2-elf-nm の例
アドレスの昇順に .elf ファイルからシンボルのリストを生成するには、次のコマン
ドを使用します。
nios2-elf-nm <project>.elf | sort -n > <project>.elf.nm
<project>.elf.nm ファイルには、アドレスの昇順に記載されている実行可能ファイル
内のシンボルのすべてが含まれています。この例で、nios2-elf-nm コマンドは、シ
ンボルのリストを作成します。このテキスト・リストでは、各シンボルのアドレス
は新しいラインの最初のフィールドです。sort コマンドの-n オプションは、シンボ
ルがデフォルトのアルファベット順の代わりに番号順にアドレスによってソートさ
れるように指定されます。
nios2-elf-objcopy
必要に応じてプロセスのバイナリ・データを変更し、1 バイナリ・オブジェクト
フォーマットから別のフォーマットにコピーするには、このコマンドを使用します。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
Chapter 4: Nios II コマンド・ライン・ツール
GNU コマンド・ラインのツール
4–21
典型的な使用方法は、ELF ファイルから（または ELF ファイルへの）変換しています
が、objcopy コマンドが ELF ファイルから（または ELF ファイルへの）変換に限定さ
れるものではありません。あなたから変換して、には、表 4–3 に記載されている
フォーマットから（またはそのフォーマットに）このコマンドを使用することがで
きます。
表 4‒3. -objcopy バイナリ・フォーマット
コマンド
(...-objcopy)
説明
elf32-littlenios2,
elf32-little
リトル・エンディアンのヘッダ、リトル・エンディアンのデータ、デ
フォルト、および最も一般的に使用される形式
elf32-bignios2,
elf32-big
ビッグ・エンディアンのヘッダ、ビッグ・エンディアンのデータ
srec
S-Record（SREC）出力フォーマット
symbolsrec
SREC データに先行するファイル・ヘッダに記載されているすべての
シンボルと SREC フォーマット
tekhex
Tektronix hexadecimal（TekHex）フォーマット
binary
Raw Binary Format
エンベデッド・システムのフラッシュのストレージ用のバイナリ・イ
メージを作成するのに便利
ihex
Intel hexadecimal（ihex）フォーマット
f TekHex、ihex、および World Wide Web 上の他のテキスト・ベースのバイナリ表現の
ファイル・フォーマットに関する情報を得ることができます。このハンドブックの
最初の出版のについては、ファイル形式の www.sbprojects.com の知識ベースのエント
リを参照することができます。
nios2-elf-objcopy の使用例
ELF ファイルから SREC ファイルを作成するには、次のコマンドを使用します。
nios2-elf-objcopy –O srec <project>.elf <project>.srec
何もリストされていない場合、ELF はバイナリ形式として想定されます。Nios II コマ
ンド・シェルで異なるバイナリ・フォーマットを指定する方法について詳しくは、
次のコマンドを入力します。
nios2-elf-objcopy --help r
nios2-elf-objdump
通常、オブジェクト・ファイルは、ELF ファイルに関する情報を表示するには、この
コマンドを使用します。
nios2-elf-objdump コマンドは nios2-elf-objcopy コマンドがサポートされているバ
イナリ・フォーマットのすべてをサポートしていますが、ELF はすべてのコマンド・
ライン・オプションに有用な出力を生成する唯一のフォーマットです。
nios2-elf-objdump 使用方法の説明
Nios II EDS は、次のコマンド・ラインを使用してオブジェクト・ダンプ・ファイルを
生成します。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
Chapter 4: Nios II コマンド・ライン・ツール
改訂履歴
4–22
nios2-elf-objdump -D -S -x <project>.elf > <project>.elf.objdump
nios2-elf-ranlib
nios2-elf-ranlib を呼び出すと、-s（nios2-elf-ar -s）オプション付きの nios2elf-ar を呼び出すことと同等です。
このコマンドについて詳しくは、4–16 ページの「nios2-elf-ar」を参照してください。
または、Nios II コマンド・シェルに nios2-elf-ar --help を入力します。
改訂履歴
表 4–4 に、本資料の改訂履歴を示します。.
表 4‒4. 改訂履歴
日付
バー
ジョン
変更内容
■
旧態依然レファランスを修正。
■
jtagconfig -n の結果ノード番号は、デバイスやシステム・コンフィギュレー
ションなどによって異なることを明らかにされた。
2011 年 7 月
2.2
2009 年 4 月
2.1
旧態依然レファランスを修正。
2008 年 11 月
2.0
システム・コンソールを追加。
2008 年 3 月
1.0
初版。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
5. Nios II C2H コンパイラの結果の最
適化
July 2011
ED51005-1.2
ED51005-1.2
Nios® II C2H コンパイラは、ソフトウェアの機能のためのハードウェア・アクセラ
レータを生成する強力なツールです。ハードウェアにソフトウェ・アアルゴリズムを
加速するコンパイラを使用することにより、C2H コンパイラはデザインの作り出す
をを向上させます。すぐに C のハードウェア機能変更のプロトタイプを作成し、効
率や反復的なプロセスでハードウェアとソフトウェアのデザインのトレードオフを
探索することができます。C2H コンパイラは、メモリのスループットと同じく計算の
帯域幅を改善することによく適しています。これで、小さなエンジニアリングの努
力でで大幅なパフォーマンスの向上を達成することが可能です。
C コードの構造は、C2H コンパイラから得られる結果に影響を与えます。C2H コンパ
イラは、ほとんどの ANSI C コードを加速させることができますが、リソースの使用
状況と性能要件を満たすように C コードを変更する必要があります。このドキュメ
ントでは、C2H 固有の最適化付きの C コードをリファクタリングすることによって、
ハードウェア・アクセラレータのパフォーマンスを改善する方法について説明しま
す。
前提条件
この章の有効利用を可能にするには、以下のトピックについて理解しておく必要が
あります。
■
SOPC Builder で Nios II ハードウェア・システムの定義および生成
■
Altera® Quartus® II 開発ソフトウェアによる Nios II ハードウェア・システムのコン
パイル
■
Nios II ソフトウェア・プロジェクトの作成、コンパイル、および実行
■
Nios II C2H コンパイラのオペレーション理論
■
データ・キャッシュ
f C2H コンパイラの基本について詳しくは、「Nios II C2H Compiler User Guide」を参照し
てください。Nios II システムの定義、生成、およびコンパイルについて詳しくは
「Nios II Hardware Development Tutorial」を参照してください。データ・キャッシュにつ
いて詳しくは、
「NiosII ソフトウェア開発ハンドブック」の「 Cache and Tightly-Coupled
Memory」の章を参照してください。
コストおよび性能
C2H コンパイラの C コードを記述するときは、複数の最適化の基準に応じて、それ
が相対的最適化することができます。多くの場合は、以下に記載されるこれらの基
準の間のトレードオフを実行する必要があります。
© 2011 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, HARDCOPY, MAX, MEGACORE, NIOS, QUARTUS and STRATIX are Reg. U.S. Pat. & Tm. Off.
and/or trademarks of Altera Corporation in the U.S. and other countries. All other trademarks and service marks are the property of their respective holders as described at
www.altera.com/common/legal.html. Altera warrants performance of its semiconductor products to current specifications in accordance with Altera’s standard warranty, but
reserves the right to make changes to any products and services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Altera. Altera customers are advised to obtain the latest version of device
specifications before relying on any published information and before placing orders for products or services.
エンベデッド・デザイン・ハンドブック
2011 年７月
Subscrib
5‒2
第 5 章 : Nios II C2H コンパイラの結果の最適化
C2H 最適化プロセスの概要
■
ハードウェア・コスト —C2H アクセラレータは、LE、乗算器、およびオンチッ
プ・メモリなどの LE などのハードウェア・リソースを消費します。このドキュ
メントでは、C 言語の構造とハードウェア・コストを記述するために次の用語を
使用します：
■
Free— 構造は、ハードウェア・リソースを消費しません。
■
Cheap— 構造は、いくつかのハードウェア・リソースを消費します。得られた
アクセラレータは、常にコストに見合います。
■
Moderate— 構造は、一部のハードウェア・リソースを消費します。得られたア
クセラレータは、通常にコストに見合います。
■
Expensive— 構造は、かなりのハードウェア・リソースを消費します。得られ
たアクセラレータは、アプリケーションの性質に応じて、時にコストに見合
います。
■
アルゴリズムの性能 —C2H アクセラレータは、
Nios II プロセッサで実行される元の
C のソフトウェアと同じアルゴリズムを実行します。一般的にアクセラレータ
は、ソフトウェア実装より少ないクロック・サイクルを使用しています。このド
キュメントは、高速または低速 C 構造のアルゴリズムの性能を説明します。アル
ゴリズムの性能の概念はレイテンシとスループットの概念が含まれています。こ
れらの概念は、5–12 ページの「Cycles Per Loop Iteration (CPLI)」に定義されていま
す。
■
ハードウェアの性能の影響 — 特定の C 言語構造は、
C2H コンパイラによってロジッ
クに変換したとき、システム全体または C2H アクセラレータを含むクロック・ド
メインの fMAX を低下させる長いタイミング・パスになることがあります。このド
キュメントでは、明白にそのような状況を示し、それらの回避のために戦略を提
示します。
C2H 最適化プロセスの概要
一回の反復で最適化の目標のすべてを満たすことができることはほとんどありませ
ん。代わりに、コストとパフォーマンスの問題に最も関連性の高い 1 つか 2 つの最
適化を行うことを計画してください。最適化されたアクセラレータを使用してシス
テムをプロファイルするときには、さらなる最適化が必要かどうかを判断すること
ができます。そして、アドレスの次に最も重要な最適化の問題を識別することがで
きます。アクセラレータが一度にワン・ステップを最適化することで、目標を達成
するために必要なときだけ最適化を適用します。
使用法
最も重要な最初のステップは、明確なパフォーマンス目標を決定することです。ア
プリケーションに応じて、アルゴリズムから特定のパフォーマンス・レベルを必要
とするかもしれません。すでにターゲット・デバイスを選択した場合、そして、シ
ステム内の他のハードウェアが十分に定義されていれば、特定のハードウェア・コ
ストの制約がある場合があります。あるいは、開発の初期段階にある場合、節約
ハードウェア・リソースのためのいくつかの一般的なガイドラインを示す可能性が
あります。最後に、デザインのニーズと既存のデザインの fMAX に応じて、使用可能
な fMAX の低下に関係している可能性があります。コストとパフォーマンスの基準に
ついて詳しくは、5–3 ページの「コストとパフォーマンス目標の達成」を参照してく
ださい。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 5 章 : Nios II C2H コンパイラの結果の最適化
C2H の結果に影響する要因
5‒3
次のステップは、C 言語でアルゴリズムを開発し、そして、可能であれば、Nios II プ
ロセッサでテストすることです。このステップでは、正しい機能性を確立し、維持
するときに非常に便利です。Nios II プロセッサは、高速化されていないアルゴリズム
のインサーキット・テストのために十分な速さでない場合、テストのためにシミュ
レーション・オプションを検討してください。
アルゴリズムの正しさに自信があるとき、アクセラレータが開始されます。この最
初の試みは、ベース・アクセラレーション・メトリックのセットが用意されていま
す。これらのメトリックは、最適化プロセスの全体的な成功を評価するのに役立ち
ます。
並行して、アルゴリズムは 2 つのコピーを維持することを推奨します：1 つはアクセ
ラレータされたアルゴリズム、もう一方は非アクセラレータされたアルゴリズムで
す。アクセラレータされたアルゴリズムと非アクセラレータされたアルゴリズムの
結果を比較することによって、コードを最適化するときに、誤って紹介する可能性
のあるエラーがすぐに発見されます。
反復最適化
C2H コンパイラの最適化の反復フェーズは、以下のステップで構成されています。
1. 高速化されたシステムをプロファイリングします。
2. 最も深刻なパフォーマンスのボトルネックを識別します。
3.
5–14 ページの「最適化手法」のセクションからの適切な最適化を識別します。
4. 最適化を適用し、高速化されたシステムを再構築します。
f Nios II システムのプロファイリング方法について詳しくは、AN391: Profiling Nios II
Systems を参照してください。
コストとパフォーマンス目標の達成
最適化の目標の明確なセットを持つことによって、最適化を停止する時期を決定す
るのに役立ちます。高速化されたシステムをプロファイリングするたびに、目標と
結果を比較してください。関連するすべての最適化を適用していない場合でも、コ
ストとパフォーマンスの目標に達している場合もあります。
最適化の目標が柔軟な場合、ベースライン・アクセラレーション・メトリック、お
よび各最適化ステップで達成されたアクセラレーション・メトリックを追跡するこ
とを検討してください。収穫逓減のポイントに到達すると停止するようにしたいこ
とがあるかも知れません。
C2H の結果に影響する要因
このセクションでは、C コンパイラおよび Nios II C2H コンパイラによって C 構造の
マッピングの主な違いを説明します。効率的なハードウェアを作成するために、こ
れらの違いを理解する必要があります。
プロセッサ上で実行するように当初書き込まれた C コードは、必ずしも効率的な
ハードウェアを生成しません。C コンパイラと Nios II C2H コンパイラは、C コードを
実行するために、加算器、乗算器、レジスタ、およびメモリなどのハードウェア・
リソースを使用します。しかし、C コンパイラがコンピューティングの逐次モデルを
想定しながら、C2H コンパイラは、コンピューティングの同時モデルを前提として
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
5‒4
第 5 章 : Nios II C2H コンパイラの結果の最適化
C2H の結果に影響する要因
います。C コンパイラは、共有ハードウェア・リソースをアクセスする命令に C
コードをマッピングします。ハードウェア・C2H コンパイラは、リソース固有にア
クセスする 1 つ以上のステート・マシンに C コードをマッピングします。C2H コンパ
イラはデータ・スループットを向上させる計算をパイプラインします。例 5–1 には、
この点を示します。
例 5‒1. パイプラインされた計算
int sumfunc(int a, int b, int c, int d)
{
int sum1 = a + b;
int sum2 = c + d;
int result = sum1 + sum2;
return result;
}
sumfunc() 関数は、4 つの整数引数を取り、それらの和をリターンします。C コンパイ
ラは 1 つの加算器を共有する 3 つの add 命令に関数をマッピングします。プロセッ
サは、順次 3 つの加算を実行します。C2H コンパイラは、1 ステートマシンと 3 つの
加算器に機能をマッピングします。アクセラレータは sum1 と同時に sum2 のための
加算、そして result ための加算を実行します。result の加算は、sum1 と sum2 変数
でデータ依存のため sum1 と sum2 の加算と同時に実行することはできません。
異なるアルゴリズムは最適なハードウェアの形質転換のために別の C の構造を必要
とします。この章では、C コードで識別することが可能な最適化を示しています。
各 C シナリオはリング C コードをリファクタする最善の方法について説明します。
「最適化手法」のセクションでは、次の潜在的な問題領域に対処する方法について説
明します。
■
メモリのアクセスおよび変数
■
演算および論理
■
ステートメント
■
コントロール・フロー
■
サブファンクションの呼び出し
■
リソース共有
■
データ依存
■
メモリ・アーキテクチャ
メモリのアクセスおよび変数
C コードが変数の値を読み込むまたは書き込むときにメモリ・アクセスが発生する
可能性があります。表 5–1 は、C コンパイラと C2H コンパイラの間でメモリ・アク
セスのマッピングにおける主な相違点の要約を提供します。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 5 章 : Nios II C2H コンパイラの結果の最適化
C2H の結果に影響する要因
5‒5
一般的に、C コンパイラは、データ・メモリ内の変数の多くのタイプが割り当てら
れます。これらはスカラー、アレイ、およびローカルな静的、またはグローバルな
構造が含まれています。メモリに割り当てられた場合、変数はメモリのビット当た
りの低コスト化（特に外部メモリ）のため、また比較的アクセスするために使用さ
れるロードまたはストア命令のオーバーヘッドが発生するため、遅く比較的に安い
です。いくつかの状況では、C コンパイラは、ローカル変数のためのプロセッサの
レジスタを使用することが可能です。プロセッサのレジスタに割り当てられた場合、
これらの変数は、比較的に高速かつ高価です。
C2H コンパイラは、適度なコストを持っており、高速であるロジック・エレメント
（LE）を使用して実装レジスタのローカル・スカラー変数を割り当てます。
C コンパイラは、少数の命令にポインタの逆参照およびアレイへのアクセスをマッ
ピングして、データ・メモリへのアドレス計算とアクセスを実行します。ポインタ
の参照やアレイ・アクセスは比較的に安くて遅いです。
C2H コンパイラは、少数のロジックへのポインタの逆参照およびアレイのアクセス
をマッピングして、アドレス計算の実行してユニークな Avalon® Memory-Mapped
（Avalon-MM）マスタ・ポートを作成します。このマッピングは、ロジックが AvalonMM マスタ・ポートを作成する必要であるため、高価になります。そのポートに接
続されているメモリの種類に応じて、低速または高速です。C2H コンパイラは、オン
チップ・メモリとして実装されるため、ローカル・アレイは高速です。
表 5‒1. メモリ・アクセス
C 構造
C コンパイラの実装
C2H の実装
ローカル・スカラ変数
メモリで割り当てられた（安価、 ロジック・エレメント（LE）に基
低速）
、またはプロセッサ・レジス づいくレジスタに割り当てられた
タに割り当てられた（高価、高速）（適度なコスト、高速）
初期化されていないローカル・ア
レイ変数
メモリに割り当てた（安価、低速）
オンチップ・メモリに割り当てら
れた （高価、高速）
初期化されたローカルアレイ変数
メモリに割り当てた（安価、低速）
オンチップ・メモリに割り当てら
れた （安価、低速）
変数の他のすべてのタイプ
メモリに割り当てた（安価、低速）
オンチップ・メモリに割り当てら
れた （安価、低速）
ポインタの参照とノン・ローカ
ル・アレイ・アクセス
通常のデータ・メモリのアクセス
（安価、低速）
Avalon-MM マスタ・ポート （高価、
低速または高速）
演算および論理
表 5–2 にはCコンパイラとC2Hコンパイラ間の演算および論理動作のマッピングの主
な相違点の要約を提供します。
AC コンパイラは 1 つ以上の命令に演算および論理動作をマッピングします。多くの
場合、1 つの命令にマッピングすることができます。他の例では、動作を実装する関
数を呼び出す必要があるかもしれません。ハードウェア乗算または除算器なしの
Nios II プロセッサは、乗算演算を実行したときに後者の例が発生します。
C2H コンパイラは全く任意のロジックを消費することなく、単にワイヤとして次の
論理動作を実装します。
2011 年７月
■
定数によるシフト
■
2 つの固定の定数による乗算と除算
■
定数でビット単位の AND と OR
Altera Corporation
エンベデッド・デザイン・ハンドブック
5‒6
第 5 章 : Nios II C2H コンパイラの結果の最適化
C2H の結果に影響する要因
結果として、これらの動作は、高速かつ無料です。以下は、これらの動作のいずれ
かの例です：
int result = some_int >> 2;
C コンパイラは右シフト命令にこのステートメントをマッピングします。C2H コンパ
イラはシフトを実行するワイヤにステートメントをマッピングします。
表 5‒2. 演算および論理動作
C 構造
2 のべき乗の定数、逓倍または分
周によるシフト (1)
例 : y = x/2;
変数によるシフト
例 : y = x >> z;
2 のべき乗ではない値を逓倍（定
数または変数）
C コンパイラの実装
シフト・インストラクション （安
価、高速）
ワイヤ（無料、高速）
シフト・インストラクション （安
価、高速）
バレル・シフタ（高価、高速）
乗算（安価、低速）
Quartus II ソフトウェアは最適化さ
れた逓倍回路を生成することがで
きた場合（安価、高速）；それ以外
の場合は 逓倍回路 （高価、高速）
除算演算（安価、低速）
ディバイダ回路（高価、低速）
例 : y = x × z;
2 のべき乗ではない値を分周（定
数または変数）
C2H の実装
例 : y = x/z;
定数付きのビットワイス AND また
はビットワイス OR
例 : y = x | 0xFFFF;
変数付きのビットワイス AND また
はビットワイス OR
例 : y = x & z;
AND または OR インストラクション
（安価、高速）
ワイヤ（無料、高速）
AND または OR インストラクション
（安価、高速）
ロジック（安価、高速）
表 5‒2 の注 :
(1) 2 の負のパワーで除算するは高価です。
ステートメント
C コンパイラは命令に長い表現（多くの動作を持つ）をマッピングします。C2H コン
パイラは長いタイミング・パスを作成するロジックに長い表現をマッピングします。
以下は、長い表現の例を次に示します。
C コンパイラは、結果を計算するには、add 命令のシリーズを作成します。C2H コン
パイラは、一緒に連鎖いくつ加算器を作成します。結果の計算は、1 データ・クロッ
ク・サイクル当たりの転送と 1 サイクルのレイテンシのスループットがあります。
C コンパイラは多数の命令に巨大な関数にマッピングします。C2H コンパイラは高価
であり、ロジックの大量に大きな関数をマッピングして、潜在的に fMAX を低下しま
す。可能であれば、関数から加速する必要のない任意の C コード削除します。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 5 章 : Nios II C2H コンパイラの結果の最適化
C2H の結果に影響する要因
5‒7
C コンパイラはストア命令またはプロセッサ・レジスタ・ライトとしてローカル変
数への相互に排他的および複数の割り当てでマッピングします（両方は比較的安価
で高速である）。しかし、C2H コンパイラは、選択した変数に使用可能な割り当ての
間に多重化するためのロジックを作成します。例 5–2 はそのようなケースを示しま
す。
例 5‒2. シングル変数への複数の割り当て
int result;
if (a > 100)
{
result = b;
}
else if (a > 10)
{
result = c;
}
else if (a > 1)
{
result = d;
}
C コンパイラは条件分岐命令と関連した表現の評価の命令の一連にこの C コードを
マッピングします。C2H コンパイラは result に正しい値を代入するには条件および
3 つの入力マルチプレクサを評価するロジックへこの C コードはをマッピングしま
す。result に対するそれぞれの割り当ては、マルチプレクサへの別の入力を追加し
ます。割り当ては、ロジックの量を増加させ、長いタイミング・パスを作成するこ
とがあります。表 5–3 には C の構造体を処理することでの C コンパイラと C2H コン
パイラの主な違いをまとめたものです。
表 5‒3. ステートメント
C 構造
C コンパイラの実装
C2H の実装
長い表現
いくつかのインストラクション （安
価、低速）
ロジック （安価、fMAX を劣化
する）
大きな関数
多くのインストラクション（安価、
低速）
ロジック （高価、fMAX を劣化
する）
インストラクションまたはプロセッ
サ・レジスタ・ライトを格納する
（安価、高速）
ロジック （安価、fMAX を劣化
する）
ローカル変数への複数の割り当て
コントロール・フロー
表 5–4 には C コンパイラと C2H コンパイラ間のコントロール・フローのマッピングの
違いの概要を提供します。
If ステートメント
C2H コンパイラは if のステートメントの表現をロジックを制御するためにマッピン
グします。ステートメントは、if のステートメントの部分で制御されます。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
5‒8
第 5 章 : Nios II C2H コンパイラの結果の最適化
C2H の結果に影響する要因
ループ
ループでは for のループ、do のループ、および while の ループが含まれています。C
コンパイラと C2H コンパイラは、if のステートメントの表現の評価のようなループ
の表現の評価の部分を扱います。しかし、C2H コンパイラは、サイクル当たり 1 イ
テレーションのスループットを達成するためにパイプラインに各ループの繰り返し
を試みます。それはループの本体と同時にループ・コントロールを実行するための
しばしば C2H アクセラレータ内の各ループの繰り返しのためのオーバーヘッドがあ
りません。データ・パスとコントロール・パスのパイプライン化は、コントロール・
パスに対しては、データ・パスを制御することができます。コントロール・パス
（ループ式）ループ内で計算された変数に依存している場合は、コントロール・パス
が別のループの繰り返しを許可する前に、データ・パスが完了する必要があるため、
スループットが低下します。
while (++a < 10) { b++ } の表現はデータの依存関係が存在しないため、すべての
サイクルを実行します。一方、while (a < 10) { a++ } は <a> がループ内で計算さ
れるため、実行に 2 サイクルを要します。
C コンパイラは switch のステートメントと同等の if ステートメントにまたは多分
ジャンプ・テーブルへマッピングします。C2H コンパイラは同等の if ステートメン
トに switch ステートメントをマッピングします。
表 5‒4. コントロール・フロー
C 構造
C コンパイラの実装
C2H の実装
If のステートメント
多少のインストラクション （安価、低速）
ロジック（安価、高速）
ループ
ループ反復当たりのオーバーヘッドに対する多少のイ
ンストラクション（安価、低速）
ロジック（中等、高速）
Switch のステートメ
ント
多少のインストラクション （安価、低速）
ロジック （中等、高速）
ターナリ動作
多少のインストラクション （安価、低速）
ロジック （安価、高速）
サブファンクションの呼び出し
C コンパイラ・サブファンクションはササブファンクションに引数を渡す（または
サブファンクションから引数を渡す）いくつかの命令とサブファンクションを呼び
出すためのいくつかの命令を呼び出します。C コンパイラは、インライン・コードに
サブファンクションを変換する可能性がある C2H コンパイラは新しいアクセラレー
タにトップレベルの加速された関数の中で作られたサブファンクションの呼び出し
をマッピングします。この技術は高価であり、トップレベルの加速された関数の内
でパイプラインをストールさせます。それは、深刻なパフォーマンスの低下が発生
する場合があります。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 5 章 : Nios II C2H コンパイラの結果の最適化
C2H の結果に影響する要因
5‒9
しかし、サブファンクションが固定確定的な実行時間がある場合は、外側のファン
クションは、パフォーマンスの低下を回避し、パイプラインにサブファンクション
の呼び出しを試みます。例 5–3 には、サブファンクションの呼び出しがパイプライン
化されます。
例 5‒3. パイプライン・ストール
int abs(int a)
{
return (a < 0) ? –a : a;
}
int abs_sum(int* arr, int num_elements)
{
int i;
int result = 0;
for (i = 0; i < num_elements; i++)
{
result += abs(*arr++);
}
return result;
}
リソース共有
デフォルトでは、C2H コンパイラは C コードで遭遇動作ごとにハードウェア・リ
ソースの一意のインスタンスを作成します。この翻訳があまりにも多くのリソース
を消費する場合には、リソースを共有するために C コードを変更することができま
す。リソースを共有する一つのメカニズムは、C コードで共有サブファンクション
を使用することです。単にサブファンクションで共有されるようにコードを配置し、
メインの加速された関数から呼び出します。C2H コンパイラは、すべての関数呼び出
し元によって共有機能でハードウェアの 1 つのインスタンスのみを作成します。
例 5–4 には 2 乗算演算の間に 1 つの乗算器を共有するサブファンクションを使用し
ます。
例 5‒4. 共有乗算
int mul2(int x, int y)
{
return x * y;
}
int muladd(int a, int b, int c, int d)
{
int prod1 = mul2(a, b);
int prod2 = mul2(c, d);
int result = prod1 + prod2;
return result;
}
データ依存
データの依存関係は、C コードの値が他の変数の値に依存している変数があるとき
発生されます。データ依存性は、一般にマイナーなパフォーマンス低下の原因とな
るいくつかの最適化を行うことから、C コンパイラを防ぎます。ハードウェアへの
C2H コンパイラ・コードをマッピングすると、データ依存性は劇的なパフォーマン
スの低下を引き起こす可能性があり、同時に連続する代わりに動作をスケジュール
することが原因となります。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
5‒10
第 5 章 : Nios II C2H コンパイラの結果の最適化
C2H の結果に影響する要因
例 5–4 のアルゴリズムでは、データの依存関係を示しています。
例 5‒5. データ依存
int sum3(int a, int b, int c)
{
int sum1 = a + b;
int result = sum1 + c;
return result;
}
C2H コンパイラは、sum1 への依存による sum1 と resul のための追加をスケジュール
します。
メモリ・アーキテクチャ
メモリの種類は、C2H アクセラレータなどを含むどのようにシステムに接続される
メモリ・システム・アーキテクチャを定義します。多くのアルゴリズムについては、
適切なメモリ・アーキテクチャは C2H コンパイラを使用して最高パフォーマンスを
達成するために重要です。不適切なメモリ・アーキテクチャでは、加速されたアル
ゴリズムは、プロセッサ上で実行される同じアルゴリズムよりもパフォーマンスが
低下することができます。
C2H アクセラレータ内に可能な並行性のため、計算制限アルゴリズムでは、データ
制限アルゴリズムになる場合もあります。最高レベルのパフォーマンスを達成するた
めにアルゴリズムに最適なメモリ・アーキテクチャを考慮し、メモリ帯域を増やす
ために C コードを変更します。
以下の説明では、初期のメモリ・アーキテクチャは、DDR SDRAM などのオフチッ
プ・メモリに接続されたデータ・キャッシュを持つプロセッサであると仮定してく
ださい。
src と dst を逆参照が両方とも同じ Avalon-MM スレーブ・ポートにアクセスする AvalonMM マスタ・ポートを作成するため、C2H コンパイラによって加速されたときに、
例 5–6 の C コードはデータ制限となります。Avalon-MM スレーブ・ポートは、1 つの
任意の時点で動作の読み出しまたは書き込みを処理することができます。その結果、
アクセスはメモリ帯域幅のスループットを制限し、インターリーブされています。
例 5‒6. メモリ帯域幅の制限
void memcpy(char* dst, char* src, int num_bytes)
{
while (num_bytes-- > 0)
{
*dst++ = *src++;
}
}
コードが変更された場合、そして適切なメモリ・アーキテクチャが使用可能な場合、
C2H コンパイラは、クロック・サイクルごとに 1 つのデータ転送のスループットを
達成することができます。この目標を達成するための必要な変更が 5–12 ページの
「効率指標」で覆われています。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 5 章 : Nios II C2H コンパイラの結果の最適化
C2H の結果に影響する要因
5‒11
C2H アクセラレータがメモリにアクセスするときに、Nios II データ・キャッシュをバ
イパスし、独自の Avalon-MM マスタ・ポートを使用します。アクセルを呼び出す前
に、データが潜在的にキャッシュに格納される場合、Nios II プロセッサは典型的な
キャッシュ・コヒーレンシの問題を回避するメモリに書き込む必要があります。こ
のキャッシュ・コヒーレンシの問題は、ハードウェア・キャッシュ・コヒーレンシ・
プロトコルをサポートしていないすべてのマルチマスタ・システムで発見されます。
加速された関数を呼び出すたびに、C2H アクセラレータを設定するときは、Nios II プ
ロセッサ・フラッシュするかどうかにかかわらず、データ・キャッシュを選択しま
す。このオプションを有効にした場合、それはアクセルを呼び出すオーバーヘッド
が増えるとデータ・キャッシュをリロードする必要があるため、プロセッサ上の C
コードの残りの部分は一時的に速度が低下します。
全体のデータ・キャッシュをフラッシュを避けることができます。プロセッサはア
クセラレータによってアクセスされるデータを共有しない場合、データ・キャッ
シュをフラッシュする必要はありません。多くの場合のように、プロセッサとアク
セラレータ間でデータをパスするためにメモリを使用すると、共有データへのアク
セスはキャッシュ不可を使用するプロセッサ上で動作する C コードを変更すること
があります。この場合、プロセッサは、データ・キャッシュをフラッシュする必要
はありませんが、共有データへのアクセス速度は低速です。あるいは、共有データ
のサイズがデータ・キャッシュのサイズよりも実質的に小さくなければ、プロセッ
サは、アクセラレータを呼び出す前に、共有データをフラッシュする必要がありま
す。
別のオプションは、データ・キャッシュなしでプロセッサを使用することです。
キャッシュなしで実行すると、すべてのプロセッサは遅くなりますが、メモリへの
アクセスが、C2H アクセラレータが提供する全体的な加速が最速の解決策をもたら
すのに十分な実質的であるかもしれません。
DRAM アーキテクチャ
シングル DRAM で構成されるメモリ・アーキテクチャは、一般的 C2H アクセラレー
タのパフォーマンスを最大化するために変更が必要です。DRAM アーキテクチャの一
つの問題は、それへのアクセスが連続していないかどうかによって、メモリのパ
フォーマンスが低下するということです。DRAM には 1 つのポートしかないため、ア
クセスする複数の Avalon-MM マスタ・ポートは、同時に順次アクセスを発生する前
に 1 つの Avalon-MM マスタによる順次アクセスを防ぐことができます。
SOPC Builder システム内のアービタのデフォルトの動作では、ラウンド・ロビンで
す。Altera Avalon SDRAM コントローラなどの DRAM コントローラは、一度に一つのメ
モリ・バンクを開いたままにしておくことができれば、マスタ・ポートは、長いス
トールを経験し、高いスループットを実現しません。ストールは、複数のマスタ・
アクセスまたはノンシーケンシャル・アドレッシングのため、順不同にメモリにア
クセスした場合に C2H コンパイラを使用して加速し、任意のアルゴリズムの性能を
引き起こす可能性があります。
「Nios II ソフ
f Nios II システム内のメモリ・アーキテクチャの最適化について詳しくは、
トウェア・ハンドブック」の「 Cache and Tightly-Coupled Memory 」を参照してくださ
い。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
5‒12
第 5 章 : Nios II C2H コンパイラの結果の最適化
効率指標
効率指標
C2H アクセラレータの効率を測定する方法はいくつかあります。これらのメトリッ
クの相対的重要性は、アプリケーションの性質によって異なります。このセクショ
ンでは、詳細に各メトリックの効率を説明しています。
Cycles Per Loop Iteration (CPLI)
C2H レポートのセクションは、加速された関数内のループごとに CPLI 値が含まれて
います。CPLI 値はループの各反復は初期レイテンシが克服されれば完了するのに要
するクロック・サイクル数を表します。目標は、データのスループットを向上させ
るための各ループの CPLI 値を最小にすることです。それは最も頻繁に実行されるた
め、関数の最も内側のループが可能な限り低い CPLI を持っていることは特に重要で
す。
CPLI 値は考慮に発生する可能性のあるハードウェアのストールを取ることはありま
せん。使用可能でない場合、メモリなどの共有リソースはループをストールさせま
す。結果としてネストループ構造外側のループストールなどをした場合、それらの
CPLI が 1 に等しい場合でも、外側のループのスループットが低下します。5–14 ペー
ジの「最適化手法」のセクションでは、C2H コンパイラで加速ループのスループット
を最大化するためのメソッドを提供しています。
CPLI を支援することができる最適化は次のとおりです。
■
データ依存の還元
■
connect_variable プラグマでシステム・インタコネクト・ファブリックの還元
fMAX はハードウェア・デザインが実行できる最大周波数です。最長のレジスタ間の
遅延またはクリティカルパスは、fMAX を決定します。Quartus II ソフトウェアはコンパ
イルするたびにデザインの fMAX を報告します。
デザインにアクセラレーション機能を追加すると、潜在的に 2 つの方法で fMAX が影
響する可能性があります：Quartus II フィッタは、パスの前の遅延を維持するために
お互いに十分近いクリティカル・パスのエレメントが失敗するデザインに新しいク
リティカル・パスを追加、または十分なロジックを追加します。fMAX を支援すること
ができる最適化は次のとおりです。
■
パイプラインの計算
■
除算の回避
■
connect_variable プラグマでシステム・インタコネクト・ファブリックの還元
■
Nios II プロセッサに不要なメモリ接続の還元
FPGA リソースの使用率
加速された機能は FPGA ハードウェアで実装されるので、このようなロジック・エレ
メントおよびメモリなどの FPGA リソースを消費します。時には、アクセラレータは
所望のまたは予想されるより多くの FPGA リソースを消費します。予期していなかっ
たリソースの使用状況は、他のロジックのために必要とされ、またシステム fMAX が
低下する可能性がリソースを消費するという欠点があります。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 5 章 : Nios II C2H コンパイラの結果の最適化
効率指標
5‒13
Avalon-MM マスタ・ポート
アクセラレータ上の Avalon-MM マスタ・ポートの数は重くロジック使用率に影響を
与えることができます。Nios II IDE の機能を加速した後で表示される C2H 報告書で
は、ポートがどのように生成される多くの Avalon-MM 報告します。複数のマスタ・
ポートは、別々のメモリに接続されるロジックの並列化を高めることができます。
しかし、図 5–1 に示すように、ロジックのコストを持っており、同じメモリ・ポー
トに接続しても過度のアービトレーション・ロジックの作成を促進することができ
ます。
図 5‒1. 複数のマスタ・ポート
CPU
Arbiter
SDRAM
Arbiter
On-Chip
RAM
C2H
Accelerator
Master
Master
Master
Master
Master
Master
Master
エンベデッド乗算器数
乗算ロジックが頻繁に専用ハードウェアとして FPGA 上で使用可能であるか、または
ロジック・エレメントを使用して作成されています。専用のハードウェアを使用す
る場合、乗算ロジックを大量に持つと、フィッタは乗算器のカラムがより良い
フィット感を実現するために配置することはできませんので、デザインのルーティ
ングを低下させる可能性があることに注意してください。ロジック・エレメントか
ら掛け算ロジックを作成する場合、リソースの使用率が高価であることを認識すべ
きであると fMAX が低下する可能性があります。
乗算のオペランドのいずれかが一定の場合、Quartus II ソフトウェアは、最も効率的
な実装を決定します。例 5–7 には、Quartus II ソフトウェアは潜在的な最適化を示し
ています。
例 5‒7. 定数による乗算の Quartus II ソフトウェアの最適化
/* C code mulitplication by a constant */
c = 7 × a;
/* Quartus II software optimization */
c = (4 × a) + (2 × a) + a;
最適化された方程式が 2 の一定の係数による乗算が含まれているため、Quartus II ソ
フトウェアは、2 シフト・プラス・アドに変えます。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
5‒14
第 5 章 : Nios II C2H コンパイラの結果の最適化
最適化手法
エンベデッド・メモリ
エンベデッド・メモリは、その高速性と固定レイテンシのために多くのハードウェ
ア・アクセラレータのための貴重なリソースです。組み込みメモリのもう一つの利
点は、それが二重のポートを使用して構成することができるということです。デュ
アル・ポート・メモリは、潜在的にメモリの帯域幅が倍増し、2 つの同時アクセスが
発生することができます。C2H コンパイラは、コードが加速関数内で初期化されて
いないローカル・アレイを宣言するたびに、その内容を保持するために組み込みメ
モリをインスタンス化します。それが適切な場合にのみ組み込みメモリを使用しま
す。その高い性能の恩恵を受けない動作で無駄にしないでください。
FPGA リソースの使用を削減することができる最適化のヒントは次のとおりです。
■
広いメモリ・アクセス
■
ループがロールアップされることの保持
■
狭いローカル変数の使用
データ・ツループット
加速された機能のためのデータ・スループットは、定量化が困難です。アルテラの
開発ツールは、直接データ・スループットに対応する任意の値を報告しません。唯
一報告された真のデータ・スループットの　測定基準は、加速機能が完了するまで
クロック・サイクル数およびクロック・サイクル数の平均値です。データ・スルー
プットを測定する 1 つの方法は、これを実行するために必要な時間の量によって処
理されるデータの量を使用して分割することです。Nios II プロセッサを使用すると、
アクセラレータがデータを処理するのに要する時間を測定して、アクセラレータ・
スループットの正確な測定値を作成することができます。
最も時間を消費するアルゴリズムのセクションを検索する機能は、ソース・コード
を加速する前にプロファイルします。可能であれば、コードを加速させていながら、
所定の位置にプロファイリング機能を残しているので、簡単アクセラレータを使用
することの利点を判断することができます。次の一般的な最適化が加速された関数
のスループットを最大にできます。
■
広いメモリ・アクセスの使用
■
ローカライズされたデータの使用
f Nios II システムについて詳しくは ｍ AN391: Profiling Nios II Systems を参照してくださ
い。
最適化手法
パイプライン化の計算
C 例 5–8 に示すように、コードのシングル・ラインに複数の数学的な動作を凝縮じ
ますが、アサインメントのレイテンシを減らすことができます。また、デザイン全
体のクロック速度を減らすことができます。
例 5‒8. 非パイプライン化された計算（低レイテンシ、劣化 fMAX）
int result = a + b + c + d + e + f + g + h;
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 5 章 : Nios II C2H コンパイラの結果の最適化
最適化手法
5‒15
図 5–2 には、例での生成されたハードウェアを示します。
図 5‒2. パイプライン化されていない計算
a
b
c
d
e
f
g
result
h
多くの場合、例 5–9 で示されるように、小さなステップに割り当てを解除すること
ができます。小さなステップはループのレイテンシを増加して、fMAX の劣化を回避
します。
例 5‒9. パイプライン化される計算（高レイテンシ、fMAX の劣化なし）
int result_abcd = a + b + c + d;
int result_efgh = e + f + g + h;
int result = result_abcd + result_efgh;
図 5–3 は例 5–9 に対して生成されたハードウェアを示します。
図 5‒3. パイプライン化される計算
a
b
c
d
e
result
f
g
h
メモリ効率の増加
次のセクションでは、C2H パフォーマンスを向上させるコーディング手法について
説明します。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
5‒16
第 5 章 : Nios II C2H コンパイラの結果の最適化
最適化手法
ワイド・メモリ・アクセスの使用
プロセッサ上でソフトウェアがデータ・キャッシュで実行されると、DRAM へのバ
イトおよびハーフワードのアクセスはメモリ帯域幅の効率的な利用を保証するため
にキャッシュから（またキャッシュへ）のフルワードの転送になります。対照的に、
例 5–10 に示されるように C2H アクセラレータでのバイトおよびハーフワード DRAM
のアクセスを行うと、DRAM への接続される Avalon-MM マスタ・ポートは狭いアク
セスを使用し、メモリの完全なデータ幅を活用していません。
例 5‒10. 狭いメモリ・アクセス （低速メモリ・アクセス）
unsigned char narrow_array[1024];
char a, b, c, d;
for(i = 0; i < 1024; i+=4)
{
a = narrow_array[i];
b = narrow_array[i+1];
c = narrow_array[i+2];
d = narrow_array[i+3];
}
図 5–4 には、例 5–10 に対して生成されたハードウェアを示します。
図 5‒4. 狭いメモリ・アクセス
State 0
a = 8-bit read
State 1
b = 8-bit read
State 2
c = 8-bit read
State 3
d = 8-bit read
i+=4
i < 1024?
true
false
複数の狭いメモリ・アクセスが必要とされる状況では、例 5–11 に示されるように、
単一のより広いアクセスにそれらの複数の狭アクセスを組み合わせることが可能で
あるかもしれません。アクセスを組み合わせることにより、同じ量のデータにアク
セスするために少ないメモリ・クロック・サイクルの使用率に影響します。1 つの 32
ビット・アクセスに 4 つの連続 8 ビット・アクセスを統合することで効果的に因数
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 5 章 : Nios II C2H コンパイラの結果の最適化
最適化手法
5‒17
の 4 によってこれらのアクセスのパフォーマンスが向上されます。しかし、
Nios IIgcc コンパイラはシングル・バイト境界に正しくデータにアクセスすることを
確保するために、C2H コンパイラは、データがより長いデータ・ワードでのアライ
ンメントに従ってアクセスされていることを確認するために、一貫して例 5–11 に示
すように、シフト動作を実行する必要があります。
例 5‒11. ワイド・メモリ・アクセス（高速メモリ・アクセス）
unsigned int *wide_array = (unsigned
unsigned int temp;
for(i = 0; i < 256; i++)
{
temp = wide_array[i];
a = (char)( temp and 0x000000FF);
b = (char)( (temp and 0x0000FF00)
c = (char)( (temp and 0x00FF0000)
d = (char)( (temp and 0xFF000000)
}
int *) narrow_array;
>> 8);
>> 16);
>> 24);
図 5–5 には例 5–11 に対して生成されたハードウェアを示します。
図 5‒5. ワイド・メモリ・アクセス
State 0
State 1
temp = 32-bit read
a = temp & 0x000000FF
b = temp & 0x0000FF00 >> 8
c = temp & 0x00FF0000 >> 16
d = temp & 0xFF000000 >> 24
i++
i < 256?
true
false
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
5‒18
第 5 章 : Nios II C2H コンパイラの結果の最適化
最適化手法
メモリ・アーキテクチャのセグメンテーション
メモリのセグメンテーションは、アクセレータのスループットを向上させるための
重要な戦略です。メモリのセグメンテーションはメモリのスループットを向上させ、
同時メモリ・アクセスにつながっています。通常、メモリをセグメントにする複数
の方法と使用方法は、特定のアプリケーションです。メモリ分割の最適化の以下の
議論について詳しくは、例 5–12 を参照してください。
例 5‒12. メモリ・コピー
void memcpy(char* dst, char* src, int num_bytes)
{
while (num_bytes-- > 0)
{
*dst++ = *src++;
}
}
src と dst のメモリ領域は、DRAM からオンチップまたはオフチップ SRAM に移動する
ことができれば、より優れたパフォーマンスが可能です。オンチップ・メモリを追
加するには、32 ビット幅の Avalon-MM スレーブ・ポートとオンチップ・メモリ・コ
ンポーネント（この例では onchip_mem_0 と呼ばれる）をインスタンス化するため
に、SOPC Builder を使用しています。memcpy の前に C コードに次のプラグマを追加し
ます。
#pragma altera_accelerate connect_variable memcpy/dst to onchip_mem_0
#pragma altera_accelerate connect_variable memcpy/src to onchip_mem_0
プラグマは、dst と src だけ onchip_mem_0 コンポーネントに接続することを提示し
ます。SRAM は DRAM のような大規模なバーストが効率的に動作する必要がなく、そ
してオンチップ・メモリは非常に低いレイテンシで動作するため、このメモリ・
アーキテクチャは、優れたパフォーマンスを提供します。図 5–6 にはデータは内蔵
RAM に常駐している例 5–12 のために生成されたハードウェアを示します。
図 5‒6. オンチップ・メモリの使用 - より良い帯域幅のためのパーティション・メモリ
CPU
SDRAM
*src
C2H
Accelerator
Arbiter
onchip_mem_0
*dst
ただし、両方のマスタ・ポートは、まだ 1 ループの繰り返し毎に 2 クロック・サイ
クル（2 つの CPLI）の最大スループットにつながることができ、シングル・ポート
の SRAM の onchip_mem_0 を共有します。この問題に対する解決策は 2 つあります：
各 Avalon-MM マスタ・ポートは、専用のメモリを持っているように、別の SRAM を
作成すること、またはデュアル・ポートとのメモリを設定します。後者の解決策に
ついては、SOPC Builder でシステムを開け、2 つのポートを持っている
onchip_mem_0 コンポーネントを変更します。この変更は、接続プラグマは次のよう
にそれぞれのメモリ・ポートを使用できるように、s1 と s2 というスレーブ・ポート
を作成します。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 5 章 : Nios II C2H コンパイラの結果の最適化
最適化手法
5‒19
#pragma altera_accelerate connect_variable memcpy/dst to onchip_mem_0/s1
#pragma altera_accelerate connect_variable memcpy/src to onchip_mem_0/s2
これらのプラグマは、dst が onchip_mem_0 コンポーネントのスレーブ・ポートの s1
のみをアクセスし、そして src が onchip_mem_0 コンポーネントの s2 のスレーブ・
ポートのみをアクセスします。改善されたメモリ・アーキテクチャと共に memcpy の
この新しいバージョンでは、サイクルごとに 1 ループの繰り返し（1 つの CPLI）の
最大スループットを実現しています。図 5–7 には、デュアル・ポート・オンチップ
RAM に格納されたデータと例 5–12 のために生成されたハードウェアを示します。
図 5‒7. デゥアル・ポートのオンチップ・メモリの使用
CPU
SDRAM
*src
C2H
Accelerator
Arbiter
s1
onchip_mem_0
*dst
s2
*src and *dst can access memory concurrently
ローカル化されるデータの使用
加速された関数でのポインタのディレファランスおよびアレイ・アクセスは常に
Avalon-MM マスタ・ポートのメモリ・トランザクションにつながっています。した
がって、例 5–13 のように、アルゴリズムの内側一時データを格納するためのポイン
タを使用する場合、パイプラインを停止する可能性がある一時的なデータが必要と
されるたびに、メモリ・アクセスがあります。
例 5‒13. メモリでの一時データ（低速）
for(i = 0; i < 1024; i++)
{
for(j = 0; j < 10; j++)
{
/* read and write to the same location */
AnArray[i] += AnArray[i] * 3;
}
}
多くの場合、例 5–14 のようにローカル変数に一時的なデータを格納することによっ
て、メモリへの Avalon-MM のアクセスをしなければならない回数を減らすアクセラ
レータの性能を向上させます。ローカル変数は加速された関数の中でストレージの
最速タイプであり、一時的なデータを格納するための非常に効果的です。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
5‒20
第 5 章 : Nios II C2H コンパイラの結果の最適化
最適化手法
ローカル変数は、パフォーマンスを向上できますが、あまりにも多くのローカル変
数は、過度のリソースの使用状況につながることができます。これは、C2H コンパ
イラを使用して関数を加速するときに試すトレードオフです。
例 5‒14. レジスタでの一時データ（高速）
int temporary;
for(i = 0; i < 1024; i++)
{
temporary = AnArray[i]; /* read from location i */
for(j = 0; j < 10; j++)
{
/* read and write to a registered value */
temporary += temporary * 3;
}
AnArray[i] = temporary; /* write to location i */
}
データ依存の減少
次の各項では、データの依存関係を減少することについての情報を提供します。
__restrict__ の使用
デフォルトで、リードおよびライトの動作が同じメモリ位置で発生するかもしれな
いので、C2H コンパイラはリードおよびライトのポインタ・アクセスをパイプライ
ンすることができません。src と dst のメモリ領域が重複していない場合、例 5–15
に示されているように、ポインタ宣言に __restrict__ キーワードを追加します。
例 5‒15. __restrict__ の使用
void memcpy(char* __restrict__ dst, char* __restrict__ src, int
num_bytes)
{
while (num_bytes-- > 0)
{
*dst++ = *src++;
}
}
ポインタでの __restrict__ 宣言は、そのポインタ経由のアクセスが他のポインタで
アクセスされた任意のメモリ・アドレスをエイリアスしないことを指定します。
__restrict__ なしで、C2H コンパイラは、パフォーマンスが大幅に低下することが書
き込まれたようにポインタへのアクセスを厳密にスケジュールする必要があります。
__restrict__ を使用するとき、加速した場合にこのオプションでシーケンシャル・
コードが失敗する可能性があるので、アルゴリズムが正しく動作することを確認す
ることが非常に重要です。ファンクションがソフトウェアの中で実行するときに、
プロセッサが一度に 1 つのアクセスだけを実行する可能性があるため、このような
状況を検出しないことがあります。しかし、__restrict__ を使用することにより、
C2H コンパイラは、潜在的に同時に発生しているように 2 つのポインタのリードお
よびライトのアクセスをスケジュールするために許可しています。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 5 章 : Nios II C2H コンパイラの結果の最適化
最適化手法
5‒21
データ依存性の最も一般的なタイプは、スカラ・データ変数の間にあります。割り
当ては、1 つ以上の割り当てに依存すると、スカラ・データ依存関係が発生します。
例 5–16 での C コードは sum1 と result の間のデータの依存関係を示します。
例 5‒16. スカラ・データの依存性
int sum3(int a, int b, int c)
{
int sum1 = a + b;
int result = sum1 + c;
return result;
}
C コンパイラは、プロセッサ・パイプラインが停止するのを防止するために指示を
開始しようとします。C2H コンパイラを使用して活用することができる同時動作の
数に制限はありません。例 5–17 に示すように、1 つの割り当てにすべての 3 つの整
数を追加すると、データの依存関係を削除します。
例 5‒17. スカラ・データの依存性を除去する
int sum3(int a, int b, int c)
{
int result = a + b + c;
return result;
}
データの依存関係の他の一般的なタイプは、データのアレイの要素の間にあります。
C2H コンパイラは、1 つのデータとしてアレイを扱って、アレイへのすべてのアクセ
スが重複することを想定します。たとえば、例 5–18 での swap01 ファンクションは
<p> でポイントされるアレイ内のインデックス 0 とインデックス 1 をスワップします。
例 5‒18. アレイ・データの依存性
void swap01(int* p)
{
int tmp = p[0];
p[0] = p[1];
p[1] = tmp;
}
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
5‒22
第 5 章 : Nios II C2H コンパイラの結果の最適化
最適化手法
C2H コンパイラは、p[0] および p[1] のアクセスが別の場所にあることを検出するこ
とができないため、p[0] および p[1] に割り当てを順次にスケジュールされます。同
時に、これらの割り当てをスケジュールする C2H コンパイラを強制するには、
例 5–19 に示すように、ポインタの宣言を __restrict__ を追加します。
例 5‒19. アレイ・データの依存性を除去する
void swap01(int* p)
{
int* __restrict__ p0 = andp[0];
int* __restrict__ p1 = andp[1];
int tmp0 = *p0;
int tmp1 = *p1;
*p0 = tmp1;
*p1 = tmp0;
}
さて、C2H コンパイラは、p[0] および p[1] に割り当てを同時に実行しようとしま
す。この例では、p[0] および p[1] を含むメモリが 2 以上のライト・ポートを備えて
いる場合、唯一の大幅な性能向上があります。メモリがシングルポートの場合、1 つ
のアクセスは別のアクセスを停止させて、少しいの良い性能、あるいはまったく性
能のないのが発生します。
スカラまたはアレイ・データ依存性の形態は、スコープ内のデータ依存性です。
例 5–20 は、それは、2 つのアレイとそのサイズへのポインタを取り、両方のアレイ
の内容の合計をリターンするので、スコープ内の依存性を示します。
例 5‒20. イン・スクープ・データの依存性
int sum_arrays(int* arr_a, int* arr_b,
int size_a, int size_b)
{
int i;
int sum = 0;
for (i = 0; i < size_a; i++)
{
sum += arr_a[i];
}
for (i = 0; i < size_b; i++)
{
sum += arr_b[i];
}
return sum;
}
連続して二つのループを実行する C2H アクセラレータを引き起こす変数の合計に依
存関係があります。アルゴリズムは第 2 のループの先頭に 0 に <i> を再割当てので、
2 つのループ間のループ・インデックス変数 <i> への依存性はありません。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 5 章 : Nios II C2H コンパイラの結果の最適化
最適化手法
5‒23
例 5–21 には、スコープ内の依存関係を削除する sum_arrays の新しいバージョンを
示します。
例 5‒21. イン・スクープ・データの依存性を除去する
int sum_arrays(int* arr_a, int* arr_b,
int size_a, int size_b)
{
int i;
int sum_a = 0;
int sum_b = 0;
for (i = 0; i < size_a; i++)
{
sum_a += arr_a[i];
}
for (i = 0; i < size_b; i++)
{
sum_b += arr_b[i];
}
return sum_a + sum_b;
}
各ループ内で別々の変数の合計を使用すると、スコープ内の依存関係を削除します。
アクセラレータは、最終的な合計を生成するファンクションの最後に一緒に 2 つの
独立した合計を追加します。最長のループが実行時間を決定しますが、それぞれの
ループが同時に実行されます。最高のパフォーマンスを得るには、2 回のリード・
ポートまたは 2 つの別々のメモリに arr_a および arr_b を接続します。
時には C コードに簡単な変更によりデータ依存関係を削除することはできません。
代わりに、同じ機能を実装する別のアルゴリズムを使用する必要があるかもしれま
せん。例 5–22 には、コードはリンクされたリスト内の値を検索し、検出されたら値
の 1 をリターンしますが、検出されていなかったら値の 0 をリターンします。検索
機能への引数は、リンクされたリストと照合する値の先頭へのポインタです。
例 5‒22. ポイント・ベース・データの依存性
struct item
{
int value;
struct item* next;
};
int search(struct item* head, int match_value)
{
struct item* p;
for (p=head; p != NULL; p=p->next)
{
if (p->value == match_value)
{
return 1; // Found a match
}
}
return 0; // No match found
}
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
5‒24
第 5 章 : Nios II C2H コンパイラの結果の最適化
最適化手法
C2H コンパイラは、p=p->next <p> により 1 つのサイクル当たり 1 つの比較の処理能
力が達成可能であり、次のポインタ位置がメモリから書き込まれ、ループ状態機械
が C コードのこのラインに到着するごとに、そのレイテンシのペナルティを発生す
るまで発生しません。より良いパフォーマンスを実現するためには、より多くの並
列処理をサポートする別のアルゴリズムを使用しています。たとえば、例 5–23 のよ
うに、値が代わりにリンクされたリストのアレイに格納されていることを前提とし
ています。新しい検索関数の引数は、アレイ、アレイのサイズ、および照合する値
へのポインタです。
例 5‒23. ポイント・ベース・データの依存性の除去
int search(int* arr, int num_elements, int match_value)
{
for (i = 0; i < num_elements; i++)
{
if (arr[i] == match_value)
{
return 1; // Found a match
}
}
return 0; // No match found
}
この新しい検索機能は arr のアレイを格納するメモリが競合が存在しないと仮定す
る 1 サイクルあたりの比較のスループットを実現しています。変更はアルゴリズム
の機能に影響を及ぼすので、コードを加速する前に、ソフトウェアでこのような変
化をプロトタイプしてください。
ロジック使用率の減少
次の各項では、ロジック使用率を減少するために採用可能なコーディング手法につ
いて説明します。
"while" の代わりに "do-while" の使用
ループのある繰り返しが実行された後に、アクセラレータはループ条件をチェック
するため、do のループのオーバーヘッドが同等の while と for のループのものより
も低くなっています。C2H コンパイラは、if のステートメントにネストされた do
ループのような while ループを扱います。例 5–24 に、C2H コンパイラが do ループ
に変換して、if のステートメントの場合にネストされることを示します。
例 5‒24. while ループ
int sum(int* arr, int num_elements)
{
int result = 0;
while (num_elements-- > 0)
{
result += *arr++;
}
return result;
}
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 5 章 : Nios II C2H コンパイラの結果の最適化
最適化手法
5‒25
例 5–25 に、C2H コンパイラが if のステートメントと do ループに while ループに変
換する方法を示すために書き換えられた同じ関数です。例 5–25 には、C2H コンパイ
ラが if のステートメントおよび do のループに while のループを変換する方法を示
すために書き直した同じ機能です。
例 5‒25. 変換される while ループ
int sum(int* arr, int num_elements)
{
int result = 0;
if (num_elements > 0)
{
do
{
result += *arr++;
} while (--num_elements > 0);
}
return result;
}
doのループの外側の余分なifのステートメントはdoループにwhileループを変換する
ために必要とされることに注意してください。sum のファンクションは空のアレイと
呼ばれることはないことがわかっている場合、num_elements の初期値は常に 0 より
大きい場合、最も効率的な C2H コードが元の while ループの do ループを使用しま
す。例 5–26 には、この最適化を示します。
例 5‒26. do ループ
int sum(int* arr, int num_elements)
{
int result = 0;
do
{
result += *arr++;
} while (--num_elements > 0);
return result;
}
定数の使用
定数は、プロセッサ用にコンパイルされた C コードのマイナーなパフォーマンス上
の利点を提供します。しかし、C2H アクセラレータの大幅なパフォーマンスの向上
を提供することができます。
例 5–27 には、通常の追加とラウンド関数を示します。
例 5‒27. 変数シフト値と追加とラウンド
int add_round(int a, int b, int sft_amount)
{
int sum = a + b;
return sum >> sft_amount;
}
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
5‒26
第 5 章 : Nios II C2H コンパイラの結果の最適化
最適化手法
上に述べられるように、C2H コンパイラは、右シフト演算のためのバレルシフタを
作成します。add_round は常に sft_amount に同じ値を指定して呼び出された場合、
#define の値に sft_amount 関数のパラメータを変更し、関数にすべてのコールを変更
することによって加速された機能の効率を向上させることができます。例 5–28 に
は、最適化の例です。
例 5‒28. 定数シフト値での追加とラウンド
#define SFT_AMOUNT 1
int add_round(int a, int b)
{
int sum = a + b;
return sum >> SFT_AMOUNT;
}
あるいは、add_round が sft_amount のためのいくつかの可能な値で呼び出された場
合、マルチプレクサおよび制御ロジックの少量を作成する switch のステートメント
を使用してバレル・シフタを避けることができます。例 5–29 には、最適化の例で
す。
例 5‒29. シフト値の有限数での追加とラウンド
int add_round(int a, int b, int sft_amount)
{
int sum = a + b;
switch (sft_amount)
{
case 1:
return sum >> 1;
case 2:
return sum >> 2;
}
return 0; // Should never be reached
}
また、乗算器または分圧器を作成するのを避けるために、これらの技術を使用する
ことができます。この技術は、部門の責任ハードウェアが大きく、比較的低速であ
るため、除算演算のために有益です。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 5 章 : Nios II C2H コンパイラの結果の最適化
最適化手法
5‒27
ループがロール・アップの状態で配置
開発者は C コンパイラを使用してより良い結果を達成するためにループをアンロー
ルする場合もあります。C2H コンパイラは、パイプラインのすべてのループをしよう
としているため、C2H コードのループのアンロールは不要です。実際には、ループ
のアンロールは C2H コンパイラが余分なロジックを作成するので、悪い結果を生成
する傾向があります。これは、ループがロールアップしておくことを推奨します。
例 5–30 には、プロセッサ上で高速に実行するためにアンロールされたアキュムレー
タのアルゴリズムを示します。
例 5‒30. アンロール・ループ
int sum(int* arr)
{
int i;
int result = 0;
for (i = 0; i < 100; i += 4)
{
result += *arr++;
result += *arr++;
result += *arr++;
result += *arr++;
}
return result;
}
この関数は、100 個の整数のアレイが渡され、それぞれの要素を蓄積し、合計をリ
ターンします。プロセッサ上でより高いパフォーマンスを実現するために、開発者
はプロセッサ上で実行されたときに 4 つの要因により、ループのオーバーヘッドを
低減し、内側のループを 4 回アンロールしています。アクセラレータがループ本体
と同時にループのオーバーヘッド・ステートメントを実行するため、C2H コンパイ
ラは、ハードウェアにこのコードをマッピングした場合、ループのオーバーヘッド
はありません。
コードをアンロールした結果、C2H コンパイラは 4 つの別々の割り当てが使用され
るので、4 倍以上のロジックを作成します。C2H コンパイラは、ループ内の 4 つの
Avalon-MM マスタ・ポートを作成します。しかし、任意の時点で Avalon-MM マスタ・
ポートは 1 つだけのリードまたはライト動作を実行することができます。4 マスタ・
ポートは、複数のマスタを持っていることのすべての利点を避けて、アクセスをイ
ンターリーブする必要があります。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
5‒28
第 5 章 : Nios II C2H コンパイラの結果の最適化
最適化手法
例 5–30 に、リソースの共有（メモリ）は並列処理が無効化される可能性がある方法
を示しています。4 割り当てを使用する代わりに、例 5–31 に示されているように、
このループをロール・アップします。
例 5‒31. ロール・アップのループ
int sum(int* arr)
{
int i;
int result = 0;
for (i = 0; i < 100; i++)
{
result += *arr++;
}
return result;
}
この実装では、このループが潜在的にクロック・サイクルごとに繰り返すことがで
きるので、以前のアンロールされた例と同じスループットを実現します。アンロー
ルのアルゴリズムは、メモリのストールに起因するすべての 4 クロック・サイクル
を反復します。これらの 2 つのアルゴリズムが同じスループットを実現するので、
ローリング最適化の利点は、Avalon-MM マスタ・ポートと追加の蓄積ロジックなどの
ロジック・リソースの節約です。
順次アレイをアクセスする ++ の使用
例 5–30 での sum の関数のアンロールのバージョンは、*arr++ を使用して、順次アレ
イのすべての要素にアクセスします。この手順では、例 5–30 に示す変化をもたらす
よりも効率的です。
例 5‒32. インデックス付きアレイの横断
int sum(int* arr)
{
int i;
int result = 0;
for (i = 0; i < 100; i++)
{
result += arr[i];
}
return result;
}
C2H コンパイラは、arr[i] および *arr++ にポインタのディレファランスを作成する
必要があります。しかし、インスタンス化されたロジックは、それぞれのケースで
異なります。*arr++* の場合、アドレス・メモリに使用される値はインクリメントが
可能なポインタ値です。arr[i] の場合、アクセラレータはカウンタ値 i にベースア
ドレス arr を追加する必要があります。両方のカウンタを必要としますが、arr[i]
の場合には加算器ブロックが必要であり、より多くのロジックを作成します。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 5 章 : Nios II C2H コンパイラの結果の最適化
最適化手法
5‒29
過剰なポインタの参照の回避
ディレファランス・オペレータの * またはアレイのインデックスを介して任意のポ
インタ・ディレファランスは、Avalon-MM マスタ・ポートを作成する場合がありま
す。彼らはデザインの fMAX が低下する可能性があり、追加のロジックにつながるの
で、過渡のポインタのディレファランス動作を使用しないでください。
1
加速された関数内の任意のローカル・アレイは、オンチップ・メモリ・リソースを
インスタンス化します。過度の使用は、オンチップ・メモリの量は限られており、
デザインのルーティングに影響を与えるため、大規模なローカル・アレイを宣言し
ないでください。
乗算の回避
エンベデッド・マルチプライヤは、FPGA の標準機能となっていますが、まだ制限さ
れた資源があります。乗算関数を使用してソース・コードを加速すると、C2H アク
セラレータは乗数をインスタンス化します。エンベデッド・マルチプライヤ・ブ
ロックは使用されるデータの幅に応じてより小さい乗算ユニットに分割するように、
様々なモードがあります。さらに、乗算を実行し、かつ機能性を蓄積する能力を
持っています。
加速されたコードで乗算器を使用する場合、ロジックを削減するために乗算器の
データ幅を検証します。エンベデッド・マルチプライヤ・ブロックは、最大幅の入
、
力の大きさに応じて設定されている 9 × 9（char *char）、18 × 18（short *short）
および 36 × 36（long *long）モードを処理します。乗算器ブロックが固定された資
源であるため、乗算の入力幅を小さくすると、リソースを節約するだけでなく、設
計のルーティングも向上させます。乗算器ブロックが使用できなかったり、デザイ
ンがあまりにも多くの乗算を必要とする場合、Quartus II ソフトウェアは、乗算ハー
ドウェアを作成するロジック・エレメントを使用します。可能であれば、ロジック・
エレメントに実装乗数がリソースとデザイン・スピードの面で高価であるため、こ
のような状況は回避してください。
アクセラレータが左シフト演算で実装することができるので、2 の累乗による乗算は
乗算ロジックをインスタンス化しません。C2H コンパイラは自動的にこの最適化を実
行しますので、<< 演算子を使用する必要はありません。乗算が必要な場合には、ロ
ジック・リソースを節約すると、この動作用に作成した高速ロジックの恩恵を受け
るためには、2 の累乗を使用してください。2 の累乗による乗算を使用する割り当て
はデータがシステム・インタコネクト・ファブリックにシフトされたレジスタ間パ
スになります。
定数を乗算するとき、Quartus II ソフトウェアは、メモリやロジックの最適化のどち
らかを使用して LE を最適化します。例 5–33 には、定数による乗算のための最適化
を示します。
例 5‒33. 定数による乗算
/* This multiplication by a constant is optimized */
y = a × 3;
/*The optimization is shift and add: (2*a + a = 3*a) */
y = a << 1 + a
可能な場合は、C2H は正しいことを行うために、Quartus II の合成に乗算、除算、お
よびモジュロの知性をオフロードします。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
5‒30
第 5 章 : Nios II C2H コンパイラの結果の最適化
最適化手法
任意の除算を回避する
可能なすべての場合は、モジュラス％演算子を含むアクセラレーション機能は、任
意の分割での使用は回避してください。除数はコンパイル時には不明であるとき任
意の分割が発生します。ハードウェアでの真の除算は、高価で遅いです。
例 5‒34. 任意の除算（高価、低速）
z = y / x;
/* x can equal any value */
この規則の例外は、2 の累乗である正のディノミネータによる除算です。2 の正列強
による除算は単にバイナリの右シフトオペレーションとなります。2 で除算された値
が 1 ビット右シフトすることによって達成することができます。4 による除算は右に
2 ビットなどにシフトすることによって行われます。加速された関数は、除算演算子
を使用して、右側の引数が 2 のべき乗の定数である場合は、C2H コンパイラは、固
定ビット・シフト演算を分割して変換します。ハードウェアでは、固定ビット・シ
フト演算はフリーのワイヤーにのみ影響します。
加速された関数で除算演算は常に 2 の累乗であるディノミネータを使用し、2 の様々
な倍数を使用する場合、例 5–35 に示されるように、適切な固定ビット・シフトに分
割して変換する三項演算を使用することができます。
例 5‒35. 三項演算子でシフトを使用する除算（安価、高速）
z = (x == 2)? y >> 1:((x == 4)? y >> 2: y >> 4);
図 5–8 には、例 5–35 での生成されたハードウェアを示しています。
図 5‒8. 三項演算子シフトの除算
y
>> 1 (zero logic)
>> 2 (zero logic)
D
Q
z
>> 4 (zero logic)
x
この最適化によって作成されたロジックは、マルチプレクサと最小限のコントロー
ル・ロジックから成る比較的安価で高速です。z への割り当てはちょうど y のコピー
をシフトしているので、マルチプレクサは、レジスタ間パスにたった 1 つのロジッ
クです。多くの可能なディノミネータの値がある場合、5–37 ページの「条件周波数
の改善」で議論されたレイテンシと周波数の間のトレードオフを検討してください。
高価で低速な除算回路の生成を回避するために他の可能な最適化は、シリアル・
ディバイダを実装することです。シリアル・ディバイダは、高遅延を持っています
が、fMAX を劣化させない傾向があります。シリアル除算を使用するもう 1 つの利点
は、動作はビットの代わりにワードで実行されるため、生成されたハードウェアの
比較的低コストになります。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 5 章 : Nios II C2H コンパイラの結果の最適化
最適化手法
5‒31
自身のシステムにシリアル除算またはモジュロ演算を実装するために c2h_division.h
および c2h_modulo.h でマクロを使用することができます。これらのファイルは、
Nios II 資料ページで入手できます。ソフトウェア・ファイルへのハイパーリンクは
www.altera.com/literature/lit-nio2.jsp での Optimizing Nios II C2H Compiler Results（本書）
の横に表示されます。2 つのヘッダ・ファイルは、zip ファイルで配布されています。
マスクの使用
32 ビットプロセッサ用の C コンパイラと C2H コンパイラの両方が 32 ビット整数に
整数以外のデータ型を小さく変換します。ロジックを保存してこのデフォルトの動
作をオーバーライドする場合、そしてデザインの fMAX の劣化を回避する場合、マス
クでビットワイスの AND を追加します。例 5–36 のように、ハードウェアの 32 ビッ
ト加算器をインスタンス化加算を行うとき、C2H コンパイラは、b1 と b2 を 32 ビッ
ト整数に推進します。ただし、b1 と b2 が符号なしの文字であるため、b1 と b2 の合
計は 9 ビットに収まることが保証されているので、ビットを保存する加算をマスク
することができます。C2H コンパイラは、32 ビット加算器をインスタンス化します
が、Quartus II の合成では、ハードウェアで 9 ビット加算器となる不要なビットを削
除します。
例 5‒36. マスクとのビットワイスの使用
unsigned int add_chars(unsigned char b1, unsigned char b2)
{
return (b1 + b2) & 0x1ff;
}
1
この最適化は、必要なデータの解像度が失われたように、誤って計算の幅を狭くし
ている場合、故障の原因となります。別のよくある間違いは、署名されたデータと
ビット・マスクを使用することです。2 の補数形式を使用して格納された署名された
データは、アクセラレータが保存して、マスキング動作によって符号ビットを拡張
することが必要です。
多次元アレイの 2 の乗数の使用
従来の C コンパイラは、ロウ優先順に保存されている 1 次元のアレイとして多次元
のアレイを実装しています。たとえば、2 次元のアレイは次のように表示されること
があります。
#define NUM_ROWS 10
#define NUM_COLS 12
int arr2d[NUM_ROWS][NUM_COLS];
アレイの最初のインデックスはロウであり、2 番目のアレイ・インデックスはカラム
です。従来の C コンパイラは NUM_ROWS x NUM_COLS 要素を持つ 1 次元アレイとし
て実装します。コンパイルされたコードは、以下の式を用いて一次元アレイへのオ
フセットを計算します。
offset = row * NUM_COLS + col;
C2H コンパイラは、多次元アレイのこの実装に従います。多次元アレイに C コード
をインデックスするたびに、それぞれ追加のディメンションごとに暗黙の乗算が作
成されます。乗算が 2 の累乗である場合は、C2H コンパイラは無料で有線シフトと
の乗算を実装しています。2 の累乗にアレイのその次元を増やすことができる場合
は、乗数を保存します。この最適化は安価でいくつかのメモリのコストがかかりま
す。この例では、単に次のように変更します。
#define NUM_COLS 16
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
5‒32
第 5 章 : Nios II C2H コンパイラの結果の最適化
最適化手法
<n> 次元の多次元アレイ・アクセスのためのすべての乗算を回避するには、最終的の
<n-1> 次元にそれぞれ 2 つのアレイのサイズの整数乗を使用する必要があります。そ
れはインデックスを作成するために乗算器をインスタンス化する C2H コンパイラに
よる決定に影響を及ぼしていないため、最初の次元は、任意の長さを持つことがで
きます。
狭いローカル変数の使用
必要以上に大きいデータ・タイプであるローカル変数を使用すると、アクセラレー
タでハードウェア・リソースを無駄にすることができます。例 5–37 では、値の 0 ～
229 を含む変数のみ含まれています。この変数で long int の変数のタイプを使用す
ると、必要とされるよりもはるかに大きい変数を作成します。このタイプの最適化
は、通常のポインタ変数には適用されません。ポインタは、常にタイプに関係なく、
32 ビットをコストしています。ポインタ変数のタイプ・サイズを小さくすると、ポ
インタが指しているデータのサイズではなく、ポインタ自体に影響を与えます。こ
れは、一般的に広いメモリ・アクセスを活用するために大規模なポインタ・タイプ
を使用するのが最適です。詳細は 5–16 ページの「ワイド・メモリ・アクセスの使
用」を参照してください。
例 5‒37. ワイド・ローカル変数 i は 32 ビットをコストする
int i;
int var;
for(i = 0; i < 230; i++)
{
var += *ptr + i;
}
例 5–38 に示すように、unsigned char の変数のタイプは、255 までの値を格納し、
ロジックの 8 ビットのみをコストするので、十分な大きいですが、long int のタイ
プがロジックの 32 ビットをコストします。過度のロジック使用率は FPGA リソース
を浪費し、システム fMAX が低下することがあります。
例 5‒38. 狭いローカル変数 i は 8 ビットをコストする
unsigned char i;
int var;
for(i = 0; i < 230; i++)
{
var += *ptr + i;
}
メモリ接続の最適化
以下のセクションでは、メモリの接続を最適化する方法について説明します。
メモリ・スレーブ・ポートへの不要な接続の削除
例 5–39 に、src と dst のポインタに関連付けられた Avalon-MM マスタ・ポートは、
プロセッサのデータ・マスタに接続されている Avalon-MM スレーブ・ポートのすべ
てに接続されています。典型的に、アクセルは、すべてのスレーブ・ポートにアク
セスする必要はありません。この余分な接続は、ハードウェア・リソースが増加し、
システム・インタコネクト・ファブリックへの不必要なロジックを追加し、潜在的
に長いタイミング・パスを作成し、fMAX を劣化します。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 5 章 : Nios II C2H コンパイラの結果の最適化
最適化手法
5‒33
C2H コンパイラは、各ポインタがアクセラレータにアクセスするどれのスレーブ・
ポートが C2H コンパイラに知らせるために C コードに追加されたプラグマをサポー
トしています。たとえば、src と dst のポインタは　DRAM にしかアクセスできない
場合（これは dram_0 と呼ばれていると仮定する）、C コードで memcpy の前にこれら
のプラグマを追加します。
#pragma altera_accelerate connect_variable memcpy/dst to dram_0
#pragma altera_accelerate connect_variable memcpy/src to dram_0
例 5‒39. メモリ・インターコネクト
void memcpy(char* dst, char* src, int num_bytes)
{
while (num_bytes-- > 0)
{
*dst++ = *src++;
}
}
これらのプラグマで、dst と src は dram_0 コンポーネントのみアクセスできます。
C2H コンパイラは dram_0 コンポーネントにのみ関連付けられている Avalon-MM ポー
トを接続します。
#pragma の使用で Avalon-MM インターコネクトの削減
加速された関数は、C コードのポインタに関連するデータにアクセスするための
Avalon-MM ポートを使用します。デフォルトでは、生成された各マスタは、Nios II
データ・マスタ・ポートに接続されるすべてのメモリのスレーブ・ポートに接続し
ます。高価であり、システム fMAX が低下する可能性がある SOPC Builder システムを
生成するときに、この接続は、アービトレーション・ロジックに大量になることが
あります。ほとんどの場合、ポインタは、システム内のすべてのメモリにアクセス
する必要はありません。
明示的にポインタ参照が接続する必要があるメモリを指定することにより、SOPC
Builder システムのマスタ・スレーブ・ポート接続の数を減らすことができます。
例 5–40 に示すように、connect_variable プラグマ指令を使用するとポインタとメ
モリ間の接続を行うことができます。図 5–9 には、3 つのポインタの output_data、
input_data1、および input_data2 はそれぞれ sdram、onchip_dataram1、および
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
5‒34
第 5 章 : Nios II C2H コンパイラの結果の最適化
最適化手法
onchip_dataram2 というメモリに接続されています。connect_variable プラグマの
ディレクティブを使用すると、加速された関数の 3 つの Avalon-MM マスタ・ポート
のそれぞれが単一のメモリ・スレーブ・ポートに接続することを保証します。それ
は、不要なマスタ・スレーブ・ポート接続を持っていないので、結果は全体的によ
り効率的になります。
例 5‒40. メモリ・インターコネクトの削減
#pragma altera_accelerate connect_variable my_c2h_function/output_data to sdram
#pragma altera_accelerate connect_variable my_c2h_function/input_data1 to onchip_dataram1
#pragma altera_accelerate connect_variable my_c2h_function/input_data2 to onchip_dataram2
void my_c2h_function( int *input_data1,
int *input_data2,
int* output_data )
{
char i;
for( i = 0; i < 52; i++ )
{
*(output_data + i) = *(input_data1 + i) + *(input_data2 + i);
}
}
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 5 章 : Nios II C2H コンパイラの結果の最適化
最適化手法
5‒35
図 5‒9. プラグマの接続
CPU
Arbiter
SDRAM
Arbiter
onchip_dataram_1
Arbiter
onchip_dataram_2
C2H
Accelerator
All connections (unnecessary arbitration logic)
CPU
Arbiter
SDRAM
Arbiter
onchip_dataram_1
Arbiter
onchip_dataram_2
C2H
Accelerator
Only necessary connections (less arbitration logic)
Nios II プロセッサに不要なメモリの接続の削除
最適化の一部として、システムへのオンチップメモリを 5–18 ページの「メモリ・
アーキテクチャのセグメンテーション」のように、並列に複数のポインタに加速され
た機能へのアクセスを許可するように追加した可能性があります。実装とデバッグ
時には、それがこれらのオンチップ・メモリは、適切なアクセルの Avalon-MM マス
タ・ポートの両方へ Nios II データ・マスタ・ポートに接続することが重要であり、
関数は加速と非加速モードの両方で実行できるようになります。しかし、いくつか
のケースでは、デバッグが実行された後、関数が加速されているときにプロセッサ
がメモリにアクセスしない場合、Nios II データ・マスタにメモリの接続を削除する
ことができます。接続を削除すると、コストを削減し、システム fMAX の低下を回避
することができます。
周波数対レイテンシの最適化
以下のセクションでは、性能を向上させるために周波数とレイテンシの間に作成可
能なトレードオフについて説明します。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
5‒36
第 5 章 : Nios II C2H コンパイラの結果の最適化
最適化手法
条件レイテンシの改善
加速時に、if または case のステートメントが含まれているアルゴリズムは、レジス
タされるコントロール・パスを使用します。このように、C2H コンパイラは、
例 5–41 に示すコードショーを加速します。
例 5‒41. レジスタされたコントロール・パス
if(testValue < Threshold)
{
a = x;
}
else
{
a = y;
}
コントロール・パスのレイテンシを低減するためには、例 5–42 のように三項演算子
（?:）を使用するためにソフトウェアを変更することができます。三項演算子は、コ
ントロール・パス上の信号をレジスタしていないので、fMAX を犠牲にして低レイテ
ンシでこの最適化が起こる可能性があります。この最適化は、主にデータの依存関
係が完全にパイプラインになる条件文を防ぐ時アクセレータの CPLI を減らすのに役
立ちます。条件文を含むループの CPLI がすでに 1 に等しい場合には、この最適化を
使用しないでください。
例 5‒42. レジスタされていないコントロール・パス
a = (testValue < Threshold)? x : y;
図 5–10 には、例 5–42 に生成されたハードウェアを示します。
図 5‒10. 条件レイテンシの改善
1 clock cycle
D
Q
x
1
1
エンベデッド・デザイン・ハンドブック
D
Q
D
Q
D
Q
y
testValue
0
0
D
Q
a
<
Threshold
2011 年７月
Altera Corporation
第 5 章 : Nios II C2H コンパイラの結果の最適化
最適化手法
5‒37
条件周波数の改善
レイテンシの増加と引き換えに fMAX の劣化を回避する場合は、三項演算子を削除す
ることを検討してください。三項演算子のを交換するために if のステートメントや
case のステートメントを使用すると、条件のントロール・パスはレジスタ済みとな
り、加速器のその部分にタイミング・パスを短縮することができます。頻繁に実行さ
れている条件文の場合には（ループの外）、この最適化は、ハードウェア・デザイン
の全体的な周波数を増加する証明することがあります。
例 5–43 および 例 5–44 には、if のステートメントとして三項演算子を書き換えるこ
とができる方法を示しています。
例 5‒43. レジスタされていない条件文
a = (testValue < Threshold)? x : y;
例 5‒44. レジスタされた条件文
if(testValue < Threshold)
{
a = x;
}
else
{
a = y;
}
図 5–11 には、C2H コンパイラが例 5–44 のための生成ハードウェアを示します。
図 5‒11. 条件周波数の改善
1 clock cycle
D
Q
x
1
1
2011 年７月
Altera Corporation
D
Q
D
Q
D
Q
y
testValue
0
0
D
Q
a
<
Threshold
エンベデッド・デザイン・ハンドブック
5‒38
第 5 章 : Nios II C2H コンパイラの結果の最適化
最適化手法
スループットの改善
計算のスループットを向上させるには、2 つの主要分野に焦点を当ててください：低
CPLI を達成すること、および 1 ループの繰り返しの中で多くの動作を実行すること。
短いネストされたループの回避
反復が発生する前にループが固定レイテンシを持っているので、ループ構造のネス
ティングは不必要な遅延が発生することもあります。アクセラレータは、ループの
レイテンシ・ペナルティにループに入るたびに発生します。ループにソフトウェア
をローリングすると、パイプライン化に便利であり、このパイプラインの利益は、
通常のループ構造に関連したレイテンシを上回しています。通常、レイテンシは
CPLI の反復回数の最大値よりも大きい場合、ループ実装が遅くなります。ループは
広げ残すと、ハードウェア・アクセラレータのリソース使用量を増加させることを
考慮する必要があります。
例 5‒45. ネストされたループ
for(loop1 = 0; loop1 < 10; loop1++) /* Latency = 3, CPLI = 2 */
{
/* statements requiring two clock cycles per loop1 iteration */
for(loop2 = 0; loop2 < 5; loop2++) /* Latency = 10, CPLI = 1 */
{
/* statements requiring one clock cycle per loop2 iteration */
}
}
次のようにメモリのストールが発生しないと仮定して、クロック・サイクルの合計
数は、次のとおりです。
Innerloop = latency + ( iterations – 1 ) ( CPLI + innerlooptime )
Innerloop = 10 + 4 ( 1 + 0 )
Innterloop = 14cycles
Outerloop = 3 + 9 ( 2 + 14 )
Outerloop = 147cycles
内側のループの高レイテンシのため、この例の合計時間は、147 クロック・サイクル
です。
例 5‒46. シングル・ループ
for(loop1 = 0; loop1 < 10; loop1++) /* Latency = 3, CPLI = 7 */
{
/* statements requiring two clock cycles per loop1 iteration */
/* statements that were previously contained in loop2 */
}
次のようにメモリのストールが発生しないと仮定して、クロック・サイクルの合計
数は、次のとおりです。
Outerloop = latency + ( iterations – 1 ) ( CPLI + innerlooptime )
Outerloop = 3 + 9 ( 7 + 0 )
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 5 章 : Nios II C2H コンパイラの結果の最適化
最適化手法
5‒39
Outerloop = 66cycles
内側のループ（loop2）を除去し、その結果、これらの式で 0 になります。外側の
ループと内側のループを組み合わせることで、飛躍的に同じ外側のループを完了す
る合計時間が短縮されます。この最適化は、内側のループをアンロールすると、外
側のループに繰り返しごとに 5 サイクルを追加することになったことを前提として
います。ループの組み合わせは、ハードウェアの使用率の増加に影響するので、考
慮に入れる必要があります。
イン・プレース計算の削除
いくつかのソフトウェア・アルゴリズムは配置済みの計算（それらが計算されると
ともに、結果はその中で入力データに上書きする）を実行します。この技術はメモ
リを節約できますが、C2H アクセラレータにコンパイルした場合に最適のパフォー
マンスを生成します。例 5–47 にこのようなアルゴリズムを示しています。残念なが
ら、配置済みアルゴリズムが同じメモリ位置に読み出して書き込むので、このアプ
ローチでは、メモリのストールにつながります。
例 5‒47. 同じメモリを使用した 2 つの Avalon-MM ポート
for(i = 0; i < 4; i++)
{
for(j = 0; j < 1024; j++)
{
AnArray[j] = (AnArray[j] * 3) >> 1;
}
}
図 5–12 には例 5–47 のための生成されたハードウェアでのデータフローを示してい
ます。
図 5‒12. イン・プレース計算
(AnArray[j]*3) >> 1
AnArray
2011 年７月
Altera Corporation
Four
iterations
エンベデッド・デザイン・ハンドブック
5‒40
第 5 章 : Nios II C2H コンパイラの結果の最適化
最適化手法
この問題を解決するには、例 5–48 に示すように、システムに 「影」のメモリを追加
することで、アルゴリズムの配置済みの動作を削除してください。同じメモリに常
駐している入力と出力の代わりに、独立したメモリを使用します。入力と出力の
データが別々のメモリに常駐するため、この最適化はメモリ・ストールを防止しま
す。
例 5‒48. 別々のメモリを使用した 2 つの Avalon-MM ポート
int * ptr;
for(i = 0; i < 4; i++)
{
for(j = 0; j < 1024; j++)
{
/* In from one memory and out to the other */
AnArrayOut[j] = (AnArrayIn[j] * 3) >> 1;
}
/* Swap the input and output pointers and do it all over again */
ptr = AnArrayOut;
AnArrayOut = AnArrayIn;
AnArrayIn = ptr;
}
図 5–13 には例 5–48 のための生成されたハードウェアでのデータフローを示してい
ます。
図 5‒13. イン・プレース計算
Outer Loop
Variable 'i'
Memory A
0
AnArrayIn
Memory B
(AnArrayIn[j]*3) >> 1
Pointer
1
AnArrayOut
AnArrayIn
AnArrayOut
エンベデッド・デザイン・ハンドブック
AnArrayIn
Po
Swap
AnArrayOut
Swap
Pointer
(AnArrayIn[j]*3) >> 1
Pointer
Done
Swap
AnArrayIn
ap
inter Sw
(AnArrayIn[j]*3) >> 1
Pointer
3
P
(AnArrayIn[j]*3) >> 1
Pointer
2
Swap
AnArrayOut
wap
ointer S
Swap
AnArrayIn
Swap
Pointer
AnArrayOut
2011 年７月
Altera Corporation
第 5 章 : Nios II C2H コンパイラの結果の最適化
最適化手法
5‒41
また、データはオンチップ・メモリに常駐する場合、この最適化を使用することが
できます。ほとんどのオンチップ・メモリは、同時にリードおよびライト・アクセ
スを可能にし、デュアル・ポートすることができます。デュアル・ポート・メモリ
を使用すると、アクセラレータが書き込まれるように、他のポートを待たずに、1
ポートからのデータを読み込むことができます。この最適化を使用する場合は、そ
のデータの破損になる可能性があるため、リードおよびライト・アドレスは重複し
てはいけません。同じアドレスに同時に発生し、リードおよびライトを防止するた
めの方法は、ライトが発生する前に、変数にデータを読み取ることです。
アレイの交換
多くの場合、ソフトウェアでは、例 5–49 に示すように、その場所からベース・ポイ
ンタの位置とオフセットを介してアクセスされるデータ構造を使用します。ハード
ウェア・アクセラレータが構造体のデータにアクセスすると、メモリが結果にアク
セスします。
例 5‒49. 個人のメモリ・アクセス
int
int
int
int
a
b
c
d
=
=
=
=
Array[0];
Array[1];
Array[2];
Array[3];
例 5–50 のように、単一のポインタおよびレジスタを使用して、これらのメモリをア
クセスに置き換えることができます。作成したハードウェアの全体的な構造は、FIFO
に似ています。
例 5‒50. FIFO のメモリ・アクセス
/* initialize variables */
int a = 0;
int b = 0;
int c = 0;
int d = 0;
for(i = 0; i < 4; i++)
{
d = Array[i];
c = d;
b = c;
a = b;
}
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
5‒42
第 5 章 : Nios II C2H コンパイラの結果の最適化
最適化手法
図 5–14 には例 5–50 のための生成されたハードウェアを示します。
図 5‒14. アレイの交換
Array
(Avalon-MM
Master)
Memory
D
Q
D
d(Array[3])
Q
D
c(Array[2])
Q
D
b(Array[1])
Q
a(Array[0])
ポーリングされるアクセラレータの使用
C2H コンパイラを使用して、ハードウェア・アクセラレータを作成すると、同じ関
数名を使用してアルゴリズムのソフトウェアとハードウェアのバージョンを呼び出
すためのメイン・プログラムを可能にするように、コンパイル時にリンクされてい
るラッパ・ファイルを作成します。ラッパ・ファイルには、次の 3 つのタスクを実
行します。
■
アクセレータに渡されたパラメータを書き込みます。
■
計算が完了したことを決定するアクセラレータをポーリングします。
■
呼び出し元に戻り値を送信します。
ラッパ・ファイルはアクセラレータのステータスを決定する責任があるので、Nios II
プロセッサは、完了までにラッパ・コードを待たなければなりません。この動作は、
ブロッキングと呼ばれています。
ハードウェア・アクセラレータは加速器の完成に達するまで Nios II プロセッサの進
歩すをブロックします。ラッパ・ファイルには、このブロック・アクションを担当
しています。割り込みを含むファイルを作成するために同じプラグマのステートメ
ントを使用すると、定義されたマクロにアクセスして、リアルタイム・オペレー
ティング・システムを使用していないシステムでカスタム・ポーリング・アルゴリ
ズムを実装することができます。
アクセルが計算が完了したことを Nios II プロセッサに警告するために、割り込みを
使用するのではなく、ソフトウェアがアクセルに関連付けられている busy 値をポー
リングします。手動でそれが完了したかどうかを判断するためにアクセルをポーリ
ングするための必要なマクロは、アプリケーション・プロジェクトの Debug または
Release ディレクトリのいずれかに作成される include ファイル内にあります。これ
らのマクロは表 5–5 に示されています。
表 5‒5. C2H アクセラレータの ポーリング・マクロ
目的
マクロ名
ビジーの値
ACCELERATOR_< プロジェクト名 >_< 機能名 >_BUSY()
リターンの値
ACCELERATOR_< プロジェクト名 >_< 機能名 >_GET_RETURN_VALUE()
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 5 章 : Nios II C2H コンパイラの結果の最適化
用語集
5‒43
アクセラレータがビジー状態のときに、残りのソフトウェアは、それが無効である
可能性がありますので、戻り値を読み出すことはできません。
割り込みベースのアクセラレータの使用
アクセラレータが動作している間 Nios II プロセッサが実行できるタスクが処理して
いる場合、ポーリング・アクセラレータのブロッキング動作が望ましくない場合が
あります。このケースでは、割り込みベースのアクセラレータを作成することがで
きます。
割り込みが複雑さの余分なレベルを追加するため、最初の標準フローとハードウェ
ア・アクセラレータを作成します。割り込みフローに進む前に、アクセラレータが
正しく動作することを確認するためのシステムをデバッグします。同様に、ポーリ
ング・モードでの機能拡張を追加します。
非ブロッキング・モードでハードウェア・アクセラレータを使用するには、関数の
ソースコードに次のラインを追加します。
#pragma altera_accelerate enable_interrupt_for_function<function name>
次のソフトウェアのコンパイル時に、C2H コンパイラは、加速器やサービス、それ
が生成する割り込みを使用するために必要なすべてのマクロを含む新しいラッパ・
ファイルを作成します。ハードウェア・アクセラレータは、IRQ レベルを持っていな
いので、SOPC Builder でシステムを開き、手動でこの値を割り当てる必要がありま
す。IRQ レベルを割り当てた後、SOPC Builder システムを再生成するために Generate
ボタンをクリックする必要があります。
アクセラレータの割り込みを処理するための必要なマクロは、アプリケーション・
プロジェクトの Debug または Release ディレクトリのいずれかに作成される include
ファイル内にあります。これらのマクロは、表 5–6 で示されています。
表 5‒6. C2H アクセラレータの割り込みマクロ
目的
マクロ名
IRQ レベルの値
ACCELERATOR_< プロジェクト名 >_< 機能名 >_IRQ()
リターンの値
ACCELERATOR_< プロジェクト名 >_< 機能名 >_GET_RETURN_VALUE()
割り込みクリア
ACCELERATOR_< プロジェクト名 >_< 機能名 >_CLEAR_IRQ()
f 割り込みサービス・ルーチンの作成にについて詳しくは「Nios II ソフトウェア開発ハ
ンドブック」の「 Exception Handling」章を参照してください。
用語集
この章では、次の用語を使用しています。
2011 年７月
■
Accelerator throughput— 単呼び出し中 C2H アクセラレータによって達成されるス
ループットです。パイプラインのストールが発生した場合、アクセルのスルー
プットがピーク・スループットよりも小さい場合があります。アクセラレータの
スループットはレイテンシが含まれていません。CPLI、Throughput、Peak
throughput、および Application throughput も参照してください。
■
Application throughput—複数のアクセラレータの呼び出しを伴うとレイテンシのサ
イクル数を含め、アプリケーションのコンテキストで C2H アクセラレータによっ
て達成されるスループットです。
Altera Corporation
エンベデッド・デザイン・ハンドブック
5‒44
第 5 章 : Nios II C2H コンパイラの結果の最適化
用語集
■
Barrel shifter – バイトまたはワード 1 クロック・サイクルで任意のビット数をシフ
トするハードウェアです。バレル・シフタは、高速かつ高価であり、fMAX が劣化
する可能性があります。
■
Cache coherency— キャッシュされたデータの整合性を保つことです。プロセッサ
がキャッシュによってメモリにアクセスし、さらにコプロセサ（例えば C2H アク
セラレータなど）とそのメモリを共有する場合、コプロセサがデータにアクセス
する場合は常に、メモリ中のデータがキャッシュの中でデータと一致することを
保証することを確認する必要があります。コプロセッサがキャッシュから更新さ
れていないメモリ内のデータにアクセスできる場合は、キャッシュ・コヒーレン
シの問題になります。
■
Compute-limited— その速度が速くデータを処理することができる方法によって制
限されているアルゴリズムを説明します。アルゴリズムが計算量の制限されてい
るときは、メモリまたは他のハードウェアの効率を高めることから便益はありま
せん。また、Data-limited を参照してください。
■
Control path— マルチプレクサの出力を制御するロジックの連鎖です。
■
CPLI— ループの反復ごとのサイクルです。クロック・サイクル数は 1 ループの繰
り返しを実行するために必要です。CPLI では、レイテンシが含まれていません。
■
Critical timing path— クロック・ドメイン内の最長タイミング・パスです。クリ
ティカル・タイミング・パスは、fMAX または全体のクロック・ドメインを制限し
ます。また、タイミング・パスを参照してください。
■
Data dependency— 例 5–5 に示すように、代入の結果は、
1 つ以上の他のアサインメ
ントの結果に依存する状況です。
■
Data-limited— その速度が速く、データがメモリまたは他のハードウェアから、ま
たは転送することができる方法によって制限されているアルゴリズムを説明しま
す。アルゴリズムは、データが限られている場合、増加の処理能力から便益はあ
りません。また、Compute-limited を参照してください。
■
DRAM— ダイナミック・ランダム・アクセス・メモリです。それがランダムにア
クセスされたときにタイム・ペナルティがあるので、連続して DRAM にアクセス
するのが最も効率的です。SDRAM は DRAM の一般的なタイプです。
■
Latency— アクセルがループに入るたびに発生するペナルティの時間です。
■
Long timing path—fMAX を劣化させるクリティカル・タイミング・パスです。
■
Peak throughput—パイプラインのストールと無視レイテンシがないと仮定するC2H
アクセラレータによって達成されるスループットです。指定されたループの場
合、ピーク・スループットは CPLI に反比例します。また、スループット、アク
セル・スループット、アプリケーション・スループット、CPLI、およびレイテン
シを参照してください。
■
Rolled-up loop— プロセッサの反復ごとに 1 アルゴリズムの反復処理を実装する通
常の C ループです。また、アンロールされるループを参照してください。
■
SDRAM— 同期ダイナミック・ランダム・アクセス・メモリです。DRAM を参照し
てください。
■
SRAM— スタティック・ランダム・アクセス・メモリです。SRAM はタイミング・
ペナルティなしでランダムにアクセスできます。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 5 章 : Nios II C2H コンパイラの結果の最適化
改訂履歴
5‒45
■
Subfunction— 加速された関数によって呼び出される関数です。apple() が関数
だったら、apple() は orange() を呼び出した場合、orange() が apple() のサブ
ファンクションです。orange() が banana() を呼び出した場合、banana() も
apple() のサブファンクションです。
■
Throughput— 単位時間当たりに処理されるデータの量です。また、加速器のス
ループット、アプリケーションのスループット、およびピークスループットを参
照してください。
■
Timing path— 次のハードウェア・レジスタの入力にハードウェア・レジスタの出
力を接続する論理の鎖です。
■
Unrolled loop—例 5–30に示すように、ループの繰り返しごとに1アルゴリズムの反
復よりも多くを実装することが脱構築される C のループです。また、Rolled-up
loop を参照してください。
改訂履歴
表 5–7 に、本資料の改訂履歴を示します。
表 5‒7. 改訂履歴
バー
ジョン
日付
変更内容
2011 年 7 月
1.2
5–16 ページの「ワイド・メモリ・アクセスの使用」のレファランスと情報を更
新。
2008 年 6 月
1.1
目次を更新。
2008 年 3 月
1.0
初版。この章では、以前 AN420: Optimizing Nios II C2H Compiler Results としてリ
リースされた。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
5‒46
エンベデッド・デザイン・ハンドブック
第 5 章 : Nios II C2H コンパイラの結果の最適化
改訂履歴
2011 年７月
Altera Corporation
6. SOPC Builder デザインの 最適化
July 2011
ED51007-1.2
ED51007-1.2
Avalon® Memory-Mapped（Avalon-MM）システム・インタコネクト・ファブリックは、
マスタとスレーブのコンポーネントを接続する柔軟な部分的なクロスバー・ファブ
リックです。このシステム・インタコネクト・ファブリックを理解と最適化するこ
とで、より高いパフォーマンスのデザインを作成するのに役立ちます。Altera® の
System-On-a-Programmable-Chip（SOPC）デザイン・ツールを使用する場合、SOPC
Builder は自動的に時間がかかるタスクやエラーが発生しやすいタスクから回避し、
仕様に合わせて最適化されたインタコネクト・ロジックを生成します。
この章では、使用する Avalon-MM デザインのパフォーマンス、リソース使用率、お
よび消費電力を最適化するための推奨事項を提供しています。内容は次のとおりで
す。
■
ハードウェア・アーキテクチャの選択
■
並行処理の理解
■
転送スループットの増加
■
増加されるシステム周波数
■
ロジックの使用率の低減
■
電力の使用率の削減
システム・デザインのための FPGA の主要な利点の 1 つはパラレル・リソースの高可
用性です。SOPC Builder は、並行性を最大化するために、FPGA ファブリックに内在す
る並列リソースを使用します。デザインのブロック間の接続を指定するには、SOPC
Builder GUI を使用します。SOPC Builder は自動的に仕様から最適な HDL を生成します。
ハードウェア・アーキテクチャの選択
ハードウェア・システムは、典型的にデザイン・ブロックを接続するための 4 つの
アーキテクチャのいずれかを使用します。
■
バス
■
フル・クロスバー・スイッチ
■
部分的なクロスバー・スイッチ
■
ストリミング
すべてのシステムのために効率的に使用する単一のアーキテクチャはありません。
以下の項では、これらの相互接続アーキテクチャのそれぞれの特徴、長所と短所を
説明します。
© 2011 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, HARDCOPY, MAX, MEGACORE, NIOS, QUARTUS and STRATIX are Reg. U.S. Pat. & Tm. Off.
and/or trademarks of Altera Corporation in the U.S. and other countries. All other trademarks and service marks are the property of their respective holders as described at
www.altera.com/common/legal.html. Altera warrants performance of its semiconductor products to current specifications in accordance with Altera’s standard warranty, but
reserves the right to make changes to any products and services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Altera. Altera customers are advised to obtain the latest version of device
specifications before relying on any published information and before placing orders for products or services.
エンベデッド・デザイン・ハンドブック
2011 年７月
Subscrib
6‒2
第 6 章 : SOPC Builder デザインの 最適化
ハードウェア・アーキテクチャの選択
バス
バス・アーキテクチャは、少しの並列性、あるいは全くの並列性のないときに比較
的に高いクロック周波数を達成することができます。バス・アーキテクチャでは、
一般的なアービトレーション・ユニットを使用してマスタとスレーブを接続します。
データ転送が発生する前にアービタがバスへのマスタ・アクセスを許可する必要が
あります。すべてのマスタが直接に各スレーブ・デバイスにアクセスする代わりに、
共有バスへのアクセスを奪い合うので、共有バス・アーキテクチャでは、多くのバ
ス・マスタ付きのシステムで大したパフォーマンス・ペナルティになる可能性があ
ります。
図 6‒1. バス・アーキテクチャ
Shared Bus
Slave 1
Master A
Slave 2
Slave 3
Master B
Slave 4
Granted B
Request B
Granted A
Request A
Arbiter
Granted 4
Granted 3
Granted 2
Granted 1
フル・クロスバー・スイッチ
クロスバー・スイッチは、バス・アーキテクチャとは異なり、同時トランザクショ
ンをサポートしています。クロスバー・スイッチはスレーブの任意の数に接続する
ためのマスタの任意の数を可能にします。ネットワーキングとハイ・パフォーマン
スのコンピューティング・アプリケーションでは、通常柔軟であり、高スループッ
トを提供するため、クロスバーを使用します。クロスバーは大きなマルチプレクサ
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 6 章 : SOPC Builder デザインの 最適化
ハードウェア・アーキテクチャの選択
6‒3
で実装されています。クロスバー・スイッチは、アービトレーション機能が含まれ
ています。クロスバーは、高度な並列性を提供します。より多くのマスタとスレー
ブが追加されると、ハードウェア・リソースの使用率も指数関数的に増加します。
ロジック使用率を最適化する必要があるため、その結果、FPGA デザインは、大きな
クロスバー・スイッチを回避します。
図 6‒2. クロスバー・スイッチ
M
M
M
M
M
M
M
M
S
S
S
S
Inactive connection
S
S
S
S
Active connection
部分的なクロスバー・スイッチ
部分的なクロスバー・スイッチが最適な接続性を提供するように、多くのエンベ
デッド・システムでは、個々のマスタ・スレーブのサブセットへの接続のみが必要
です。部分的なクロスバー・スイッチには 2 つの大きな利点があります。
2011 年７月
■
接続の縮小により、システム・インタコネクト・ファブリックはより高いクロッ
ク周波数で動作します。
■
システム・インタコネクト・ファブリックは、より少ないリソースを消費しま
す。
Altera Corporation
エンベデッド・デザイン・ハンドブック
6‒4
第 6 章 : SOPC Builder デザインの 最適化
ハードウェア・アーキテクチャの選択
これら 2 つの利点は、ASIC や FPGA インタコネクト構造の部分的なクロスバー・ス
イッチに最適です。図 6–3 は、部分的なクロスバー・スイッチで接続されたマスタ
とスレーブ付きの SOPC Builder システムを示しています。
図 6‒3. 部分的なクロスバー・スイッチ ‒ SOPC Builder システムのインタコネクト
Program
Memory
System CPU
Master A
I/O 1
Arbiter
DSP
Master B
Switch
Fabric
Custom HW
Accelerator
Arbiter
IO CPU
Master C
Data
Memory
Data
Memory
I/O 2
Program
Memory
SOPC Builder は、スレーブ側のアービトレーションを使用して部分的なクロスバーの
システム・インタコネクト・ファブリックを実装するロジックを生成します。シス
テム・インタコネクト・ファブリックに含まれているアービタがスレーブ側のアー
ビトレーションを実行しています。このアーキテクチャでは、大幅に共有バス・
アーキテクチャに内在しているリソースの競合を低減することができます。2 つ以上
のマスタが同じサイクルでのアクセスを要求されない限り、アービタは、すべての
要求のマスタの中から選択します。したがって、競合がないようになります。対照
的に、共有バス・アーキテクチャでは、すべてのマスタに関係なくマスタがアクセ
スを必要とする実際のスレーブデバイスのバスのアービトレーションをする必要が
あります。
図 6–3 では、システム CPU は独自のプログラム・メモリを持っております。これら
二つのスレーブ・リソースに対する競合が決してありません。システム CPU は、
DSP マスタとメモリを共有しています。ここで、アクセスを制御するスレーブ側の
アービターがあります。DSP は、カスタム・ハードウェア・アクセラレータにアクセ
スする唯一のマスタであり、このデバイスの競合はありません。DSP や I/O CPU マス
タはメモリを共有しており、アクセスはスレーブ側アービタによって制御されます。
I/O CPU マスタは、独自のプログラム・メモリと I/O デバイスがあります。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 6 章 : SOPC Builder デザインの 最適化
ハードウェア・アーキテクチャの選択
6‒5
SOPC Builder で生成される部分的なクロスバースイッチは、FPGA デザインに最適で
す。SOPC Builder は互いに通信するマスタとスレーブを接続するために必要なロジッ
クを生成するためです。SOPC Builder を使用すると、自動的に生成された相互接続
アーキテクチャの柔軟性でスイッチ・ファブリックのパフォーマンスを得ることが
できます。SOPC Builder は自動的にシステム・インタコネクト・ファブリックを生成
するため、システム・デザインが変更された場合、自動的にシステム・インタコネ
クト・ファブリックを再生成することができます。
ストリミング
高速データ転送を必要とするアプリケーションは、ストリーミング・インタコネク
トを使用します。SOPC Builder は、ソースおよびシンク・コンポーネント間のポイン
ト・ツー・ポイント接続を作成し、Avalon Streaming （Avalon-ST）インタフェースを
サポートしています。各ストリーミング接続は、アービトレーションを排除し、単
一のソースおよびシンク・ペアが含まれています。SOPC Builder は部分的なクロス
バーとストリーミング接続の両方をサポートしているため、通常、レジスタをプロ
グラムして、データ転送そ設定するためのコントロール・プレーン、そして通常の
高速データ転送に使用されるデータ・プレーンのストリーミングの接続の部分的な
クロスバーを必要とするシステムをデザインすることができます。
完全および部分クロスバ・スイッチとストリーミング・アーキテクチャは、通常の
データ・プレーンを実装するために使用されています。通常、コントロール・プ
レーンはデータのフローをコントロールするプロセッサまたはステートマシンが含
まれています。完全または部分的なクロスバー・スイッチ、または共有バス・アー
キテクチャは、コントロール・プレーンを実装します。
SOPC Builder は、データ・プレーンとコントロール・プレーンの両方にインタコネク
ト・ロジックを生成します。システム・インタコネクト・ファブリックは自動的に
提供する接続情報に基づいての Avalon-MM および Avalon-ST インタフェースを接続し
ます。図 6–4 は、SOPC Builder でデザインされたビデオ処理アプリケーションしてい
ます。このアプリケーションは、コントロールのために Avalon-MM インタフェース
を使用していますが、データを転送するために Avalon-ST インタフェースを使用して
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
6‒6
第 6 章 : SOPC Builder デザインの 最適化
ハードウェア・アーキテクチャの選択
います。ビデオ・イメージング・パイプラインでは、5 つの Avalon-ST インタフェー
スを備えたハードウェアブロックが含まれています：ビデオ・デコーダ、フレーム・
バッファ、2 次元フィルタ、圧縮エンジン、およびダイレクト・メモリ・アクセス
（DMA）マスタ。ビデオ・デコーダは例外として、ハードウェアのすべてのブロック
も、コントロールのために Avalon-MM インタフェースが含まれています。
図 6‒4. ビデオ・データおよびコントロール・プレーン
Nios II
Processor
M
DDR
SDRAM
Flash
UART
USB 2.0
S
S
S
S
M
Serial Rapid IO
S
M
S
SOPC Builder Avalon Memory-Mapped System Interconnect Fabric
M
M
Video
src
Decoder
S
snk
Video src
Decoder
snk
Video src
Decoder
Frame
Buffer
Manager
(DMA)
src
S
S
M
2D Filter
Compression
DMA
snk
src
snk
src
snk
snk
SOPC Builder Avalon Streaming
System Interconnect Fabric
Video src
Decoder
snk
M
Avalon-MM Master Port
src
Avalon-ST Source Port
Data Plane
S
Avalon-MM Slave Port
snk
Avalon-ST Sink Port
Control Plane
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 6 章 : SOPC Builder デザインの 最適化
並行処理の理解
6‒7
ダイナミック・バス・サイジング
システム・デザインにおける一般的な問題は、異なるデータ幅のハードウェア・ブ
ロックの統合です。SOPC Builder は、異なる幅のマスタと複数のスレーブ間で正しい
アダプタ・ロジックを挿入することにより、Avalon-MM コンポーネントでの混合幅を
自動的に適合させます。例えば、16 ビットのスレーブへの 32 ビットのマスタを接続
する場合、システム・インタコネクト・ファブリックは、2 つの独立した 16 ビット
の転送に 32 ビット転送を分離するアダプタを作成します。アダプタを作成すると
き、システム・インタコネクト・ファブリックは、各バイト・レーンを修飾するバ
イト・イネーブルを採用しています。
f ダイナミック・バス・サイジングおよびアドレスのアラインメントについて詳しく
は、SOPC Builder User Guide を参照してください。
並行処理の理解
FPGA でデザインするの主な利点の一つは、再プログラム可能なパラレルのハード
ウェアです。基礎となる FPGA 構造は大規模な並列処理をサポートしているため、シ
ステム・インタコネクト・ファブリックは、並列ハードウェアを使用するために調
整されています。いくつかの計算プロセスが同時に実行されるように、同時並列性
を作成するために並列ハードウェアを使用できます。
次の項では、お使いのシステムで同時並列性を高めるために行うことができる他の
デザインの選択肢を概説しています。
複数のマスタの作成
お使いのシステムには、システム・インタコネクト・ファブリックでサポートされ
る並行性を活用するために複数のマスタを持っている必要があります。Nios® II プロ
セッサが独立した命令およびデータ・マスタが含まれているため、Nios II プロセッ
サを含むシステムには、少なくとも 2 つのマスタが含まれています。マスタ・コン
ポーネントは、通常、次の 3 つの主要なカテゴリに分類されます。
2011 年７月
■
Nios II プロセッサなどの汎用プロセッサ
■
DMA エンジン
■
PCI Express 仕様に準拠されるインタフェースなどの通信インタフェース
Altera Corporation
エンベデッド・デザイン・ハンドブック
6‒8
第 6 章 : SOPC Builder デザインの 最適化
並行処理の理解
SOPC Builder はスレーブ側のアービトレーションにシステム・インタコネクト・ファ
ブリックを生成するので、システム内のすべてのマスタが同時に転送を発行するこ
とができます。2 つ以上のマスタが単一のスレーブに転送をポストしない限り、マス
タのストールがありません。システム・インタコネクト・ファブリックは、ウェイ
ト・ステートを決定し、スレーブがストールしなければならないときにマスタに
waitrequest 信号をドライブするアービトレーション・ロジックが含まれています。
図 6–5 は 3 つのマスタを使用したシステムを示しています。この図でのボルド・ワ
イヤは、同時にアクティブにできる接続を示しています。
図 6‒5. マルチ・マスタのパラレル・アクセス
Nios II
Processor
M
S
DMA
Engine
M
M
M
Avalon Master Port
S
Avalon Slave Port
M
S
M
Arbiter
Arbiter
S
S
External Memory
Controller
External Memory
Controller
S
Dual-Port On-Chip
Memory
PCI Express
Interface
concurrent access possible
個別のデータパスの作成
システム・インタコネクト・ファブリックでは、スレーブ側のアービトレーション
を使用しているため、同時並列性は、任意の特定のスレーブを共有するマスタの数
によって制限されます。システム・デザインは、より高いデータ・スループットを
必要とする場合、同時に発生した転送の数を増やすためにマスタとスレーブの数を
増やすことができます。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 6 章 : SOPC Builder デザインの 最適化
並行処理の理解
6‒9
DMA エンジンの使用
DMA エンジンは、データ・スループットを向上させます。DMA エンジンが任意のプ
ログラミングの介入なしにプログラムされた開始アドレスと終了アドレスの間のす
べてのデータを転送するため、データ・スループットは、DMA に接続された部品に
より決定されます。データ・スループットに影響する要因は、データ幅とクロック
周波数です。より多くの DMA エンジンを含めることによって、図 6–6 が示すように
システムがより多くのリードおよびライトの動作を維持することができます。
図 6‒6. シングルまたはデゥアル DMA チャンネル
Single DMA Channel
DMA
Engine
M
M
S
S
S
S
Read
Buffer 1
Read
Buffer 2
Write
Buffer 1
Write
Buffer 2
Maximum of one read and one write per clock cycle
Dual DMA Channels
DMA
Engine 2
DMA
Engine 1
M
M
M
M
S
S
S
S
Read
Buffer 1
Write
Buffer 1
Read
Buffer 2
Write
Buffer 2
Maximum of two read and two writes per clock cycle
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
6‒10
第 6 章 : SOPC Builder デザインの 最適化
並行処理の理解
複数のマスタまたはスレーブ・ポートを含む
図 6‒7. スレーブ分離の前と後
Single Channel Access
Channel Processor
Host 1
M
Compute
Engine 1
Data Channel 1
Host 2
M
Compute
Engine 2
Data Channel 2
Arbiter
S
Host 3
M
Compute
Engine 3
Data Channel 3
Host 4
M
Compute
Engine 4
Data Channel 4
Quad Channel Access
Channel Processor
Host 1
M
S
Compute
Engine 1
Data Channel 1
Host 2
M
S
Compute
Engine 2
Data Channel 2
Host 3
M
S
Compute
Engine 3
Data Channel 3
Host 4
M
S
Compute
Engine 4
Data Channel 4
特定の機能に対して複数のスレーブ・ポートを作成すると、デザインで同時並列性
を向上させます。図 6–7 は 2 チャンネル処理システムを示しています。最初のチャ
ンネル処理システムで、4 つのホストは、チャネル・プロセッサの単一スレーブ・
ポートのアービトレーションを行う必要があります。第二番目のチャンネル処理シ
ステムで、各ホストは、すべてのマスタが同時にコンポーネントのスレーブ・ポー
トにアクセス可能な専用のスレーブ・ポートを駆動します。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 6 章 : SOPC Builder デザインの 最適化
並行処理の理解
6‒11
個別のサブシステムの作成
より小さく管理可能なサブシステムに分割する階層を使用できます。並行処理のこ
の形式は、特定のマスタが接続するスレーブの数を制限することによって実装され
ています。単一の SOPC Builder システム内のサブシステムが複数の独立を作成するこ
とができます。サブシステム間の通信が必要になったとき、情報を転送するために
共有メモリ、メッセージ・パッシング、または FIFO を使用できます。
f 詳細については、Creating Multiprocessor Nios II Systems Tutorial および Embedded
peripherals IP User Guide を参照してください。
図 6‒8. メッセージ・パッシング
Nios II
Processor
M
Nios II
Processor
M
M
Arbiter
M
Arbiter
Arbiter
Arbiter
S
S
S
S
S
S
S
S
On-Chip
Memory
PIO
UART
Mutex
Shared
On-Chip
Memory
On-Chip
Memory
PIO
UART
Shared memory for message passing
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
6‒12
第 6 章 : SOPC Builder デザインの 最適化
転送スループットの増加
代わりに、サブシステムが同一である場合、単一の SOPC Builder システムをデザイン
し、FPGA デザインに複数回インスタンス化することができます。このアプローチ
は、異種のシステムよりも保守が容易であるという利点があります。また、このよ
うなシステムでは、単一のインスタンスのロジック使用率と効率を決定した後、複
数のサブシステムにどのぐらいロジックが必要であることを見積もることができる
ので、拡張が容易です。複数のデータ・チャンネルをプロセスするシステムは、　チャネルごとに同一のサブシステムをインスタンス化することによってデザインさ
れています。
図 6‒9. マルチ・チャンネル・システム
Input Data Stream
Channel 1 System
Output Data Stream
Input Data Stream
Channel 2 System
Output Data Stream
Input Data Stream
Channel N System
Output Data Stream
Nios II
Processor
M
M
Arbiter
S
S
S
On-Chip
Memory
Input Data
Stream
Input Data
Stream
転送スループットの増加
システム内のマスタとスレーブ・ポートの転送効率を増加させると、デザインのス
ループットが向上します。安価や低周波デバイスを使用することができるため、厳
密なコストや電力要件を持つデザインは、転送効率を高めることの恩恵を受けます。
周波数が制限されるハードウェアの性能を向上させるため、スペクトルのもう一方
の端では、高性能を必要とするデザインも増加転送効率の恩恵を受けます。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 6 章 : SOPC Builder デザインの 最適化
転送スループットの増加
6‒13
パイプライン化された転送の使用
パイプライン化された転送は、マスタが以前のリードからデータをリターンする前
に複数のリードをポストすることにより、リードの効率を高めることができます。
パイプライン化された転送をサポートするマスタは、　継続的に転送を転送して、　有効データを表示する readdatavalid 信号に依存します。スレーブは、
readdatavalid 信号を含めること、または固定リード・レイテンシで稼動することに
よりパイプライン化された転送をサポートしています。
最大保留リード
SOPC Builder は、システム・インタコネクト・ファブリックを生成したときに保留中
の最大保留リードのプロパティを更新します。リードをサポートしているスレーブ・
ポートを使用してカスタム・コンポーネントを作成する場合、コンポーネント・エ
ディタでは、この値を指定する必要があります。この値は、パイプライン化された
スレーブ・コンポーネントが処理できるリード転送の最大数を表します。スレーブ・
ポートに提示された最大保留リードのパラメータを超えた場合、コンポーネントは
waitrequest をアサートする必要があります。
保留リードの最大値の選択
保留リードの最大の値のパラメータを最適化することは、カスタム・コンポーネン
トのレイテンシを十分に理解する必要があります。このパラメータは、コンポーネ
ントの最長遅延に基づくべきです。例えば、パイプライン化されたコンポーネント
は 2 つのモードがあり、最初のモードは 2 つのクロック・サイクルを必要として、
そしてもう一つのモードは 5 つクロック・サイクルを必要とする場合、保留リード
の最大値が 5 に設定します。そうすることで、コンポーネントが 5 転送をパイプラ
インすることができます。そして、最初の 5 サイクル・レイテンシ後にデッド・サ
イクルを排除することもできます。
保留リードの最大値のパラメータに正しい値を決定するもう一つの方法は、実際に
システムのシミュレーション中に、または実際のハードウェアの実行中に保留する
リードの数を監視することです。この方法を使用するには、最大保留リードを非常
に高い値に設定して、クロック毎にリードの要求を発行するマスタを使用します。
データが頻繁に waitrequest をアサートしない位置に書き込まれている限り、この
タスクのために DMA を使用できます。実際のハードウェアを使用してこの実験を実
行する場合、ロジック・アナライザ、またはコンポーネントを観察するためのビル
トイン監視ハードウェアを使用できます。
保留リードの最大値の過大評価または過小評価
カスタムのパイプライン化されたコンポーネントのための保留リードの最大値を正
確に選択することは非常に重要です。保留リードの最大値を過小評価する場合、
データが失われたり、マスタ・ポートが無期限に停止させる可能性があります。シ
ステム・インタコネクト・ファブリックは、長い遅延を処理するためのタイムアウ
ト・メカニズムがありません。
保留リードの最大値はスレーブに接続される各マスタのためのシステム・インタコ
ネクト・ファブリックに挿入される readdatavalid FIFO の深さを指示します。この
FIFO は 1 ビット幅だけなので、かなりのハードウェア・リソースを消費しません。
カスタム・コンポーネントでの保留リードの最大値を過大評価する場合、ハード
ウェアの使用率がわずかに増加します。これらの理由によって、最適な値がわから
ない場合、この値を過大評価することを推奨します。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
6‒14
第 6 章 : SOPC Builder デザインの 最適化
転送スループットの増加
パイプライン化されたリード・マスタ
パイプライン化されたリード・マスタは、データがリターンされる前に複数のリー
ドをポストすることができます。パイプライン化されたリード・マスタは、頻繁に
クロック・サイクルごととしてリードをポストすることにより、リード動作のレイ
テンシを隠蔽します。データの依存関係が存在しないときにパイプライン化された
リード・マスタがデータをプリフェッチすることができます。一般的なパイプライ
ン化されたリード・マスタの例としては次の通りです。
■
DMA エンジン
■
Nios II プロセッサ（4 バイトより大きいのキャッシュ・ライン・サイズ）
■
C2H リード・マスタ
要件
パイプライン化されたリード・マスタのコントロールとデータパスの論理は慎重に
デザインする必要があります。waitrequest 信号がアサートされると、制御ロジック
は、リード・サイクルを拡張する必要があります。このロジックは、マスタの
address、byteenable、および read 信号をコントロールする必要があります。最大ス
ループットを達成するために、イプライン化されたリード・マスタは waitrequest
がデアサートされている限り、連続的にリードをポストする必要があります。read
がアサートされている間、システム・インタコネクト・ファブリックに提示された
アドレスが格納されます。
データパス・ロジックは、readdata および readdatavalid 信号が含まれています。
マスタは、クロック・サイクルごとにデータをリターンすることができる場合、イ
ネーブル・ビットとして readdatavalid を使用してデータをレジスタすることがで
きます。マスタは、リード・データの連続ストリームを扱うことができない場合、
FIFO 内のデータをバッファリングする必要があります。FIFO が所定のフィル・レベル
に達したとき、コントロール・ロジックはリードを発行することを停止しなければ
なりません。
f パイプライン化されたリード・マスタを実装する信号について詳しくは、Avalon
Interface Specifications を参照してください。
スループットの向上
通常、パイプライン化されたリード・マスタを使用することによって達成するス
ループットは、スレーブ・ポートのレイテンシに直接比例します。例えば、リード・
レイテンシは 2 サイクルである場合、スレーブ・ポートは、パイプライン転送をサ
ポートしていると仮定し、パイプライン化されたリード・マスタを使用してスルー
プットを倍増させることができます。マスタまたはスレーブのどちらかがパイプラ
イン化されたリード転送をサポートしていない場合、転送が完了するまで、システ
ム・インタコネクト・ファブリックは waitrequest をアサートします。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 6 章 : SOPC Builder デザインの 最適化
転送スループットの増加
6‒15
マスタとスレーブの両方のポートはパイプライン化されたリード転送をサポートす
る場合、初期レイテンシの後ろに連続ストリームでデータをフローしています。
図 6–10 には、リードがパイプライン化されていない場合を示します。システムには
それぞれのリードのために 3 サイクルのレイテンシのペナルティがあり、全体的に
スループットの 25 パーセントとなります。図 6–11 には、リードがパイプライン化さ
れている場合を示します。3 サイクルのレイテンシの初期ペナルティの後、データが
連続してフローしています。
図 6‒10. 低効率のリード転送
Read Latency
Read Latency
Overhead
Overhead
clk
address
A0
A1
read
waitrequest
readdata
D0
D1
図 6‒11. 高効率のリード転送
Read Latency
Overhead
clk
address
A0
A1
A2
A3
A4
A5
A6
A7
A8
A9
A10 A11 A12
D0
D1
D2
D3
D4
D5
D6
read
waitrequest
readdatavalid
readdata
2011 年７月
Altera Corporation
D7
D8
エンベデッド・デザイン・ハンドブック
6‒16
第 6 章 : SOPC Builder デザインの 最適化
転送スループットの増加
パイプライン化されたリード・マスタの例
図 6–12 は、カスタム DMA、ハードウェア・アクセラレータ、またはオフチップの通
信インタフェースを実装するために使用できる FIFO にデータを格納するパイプライ
ン化されたリード・マスタを示しています。デザインを簡素化するために、コント
ロールとデータ・ロジックが分離されています。マスタはワード・アラインされた
ワード・アクセス、およびシーケンシャル・メモリ・アドレスからのリードを実行
します。転送長は、ワード・サイズの倍数になります。
図 6‒12. レイテンシを考慮したマスタ
Nios II
Processor
M
DMA
M
M
M
Arbiter
Arbiter
S
S
Memory
CRC Hardware
Accelerator
go ビットがアサートされると、マスタは start_address と transfer_length 信号をレ
ジスタします。マスタは次のクロックでのリードの発行を開始し、length レジスタ
がゼロになるまで停止しません。この例では、ワード・サイズは 4 バイトです。し
たがって、アドレスは常に 4 ずつ増加し、長さは常に 4 ずつ減少しています。FIFO
が所定のレベルに埋めない限り read 信号がアサートされたままにあります。length
が 0 に達していない場合、また read が掲示される場合、address レジスタを増加し
て、length を減少します。
read 信号がアサートされるたびに、そして waitrequest がデアサートされるたびにマ
スタはリード転送をポストしています。バッファ全体が読み込まれるまで、または
waitrequest がアサートされるまでマスタはリードを発行します。オプションのト
ラッキング・ブロックは、done ビットを調節します。length レジスタが 0 に到達し
た場合、いくつかのリードは、未処理のままになります。トラッキング・ロジック
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 6 章 : SOPC Builder デザインの 最適化
転送スループットの増加
6‒17
は、最後の read が完了するまで done がアサートされていないことを保証します。
トラッキング・ロジックは readdata FIFO に残っている容量を超えないように、シス
テム・インタコネクト・ファブリックにポストされたリードの数を監視します。こ
のロジックは、以下の条件が満たされる場合にカウントするカウンタが含まれてい
ます。
■
read がポストされており、readdatavalid がをディアサートされた場合、カウン
タが増加される。
■
read がポストされていない場合、
そして readdatavalid がをアサートされた場合、
カウンタが減少される。
length レジスタおよびトラッキング・ロジック・カウンタが 0 に達すると、すべての
リードが完了し、done ビットがアサートされます。第二のマスタは、パイプライン
化されたリード・マスタがアクセスするメモリ位置を上書きしてしまった場合、完
了ビットが重要です。このビットは、元のデータが上書きされる前にすべてのリー
ドが完了していることを保証します。
Avalon-MM マスタを作成する方法の詳細については、次のデザイン例とマニュアルを
参照してください。
■
Nios II Embedded Processor Design Examples web page of the Altera website アルテラの
ウェブサイトのウェブページ
■
SOPC Builder User Guide での Component Editor の章
アービトレーション・シェアおよびバースト
アービトレーション・シェアはアービトレーション・プロセスの制御を提供します。
デフォルトでは、アービトレーション・アルゴリズムでは、1 つのシェアを受信する
すべてのマスタを持つ同等の公平性を提供します。高いスループットを必要とする
マスタに多くのシェアを割り当てることによって、システムの要件にアービトレー
ション・プロセスを調整することができます。アービトレーション・シェアが大き
いほど、より多くの転送はスレーブにアクセスするためのマスタに割り当てられて
います。
マスタが転送をポストすることができない場合、そして他のマスタが特定のスレー
ブへのアクセスを得るために待っている場合、アービタはラウンド・ロビン方式で
別のマスタのアクセスを許可します。バック・ツー・バック転送をポストすること
ができない場合、このメカニズムは、マスタがアービトレーション・サイクルを使
用することを防ぐことができます。
バーストはシングル・ワード転送以上のスレーブへのアクセスを維持するためのマ
スタを可能にします。バースト長の 8 付きのバースト・マスタがライト転送をポス
トした場合、8 のライト・サイクルのためのアービトレーションが保証されていま
す。
アービトレーション・シェアおよびバーストの違い
次の 3 つの主要な特性は、アービトレーション・シェアおよびバーストの違いを説
明します。
2011 年７月
■
アービトレーション・ロック
■
シーケンシャル・アドレッシング
■
バース・アダプタ
Altera Corporation
エンベデッド・デザイン・ハンドブック
6‒18
第 6 章 : SOPC Builder デザインの 最適化
転送スループットの増加
アービトレーション・ロック
マスタがバースト転送をポストすると、アービトレーションは、そのマスタのため
にロックされます。結果として、バースト・マスタがロック期間の間、転送を維持
することができるべきです。第 4 の書き込みの後、マスタは 50 サイクルの write 信
号をディアサートした場合、他のすべてのマスタは、この停滞期間中のアクセスを
待ち続けます。
帯域幅の浪費を回避するには、フル・バースト転送は、十分なバースト転送がス
レーブ・デバイスへのアクセスを求める前に準備ができているまで、マスタ・デザ
インは待つべきです。また、準備ができているデータの量に等しいバースト・カウ
ントをポストすることにより、帯域幅の浪費を回避することができます。例えば、
最大バースト・カウントの 8 で、データの 3 ワードしかないカスタム・バーストの
ライト・マスタを作成した場合、単に 3 バースト・カウントを提示することができ
ます。この戦略は、システム帯域幅の最適使用にはなりませんが、システム内の他
のマスタのために飢餓を防ぐことができます。
シーケンシャル・アドレッシング
定義により、バースト転送は、ベース・アドレスとバースト・カウントが含まれて
います。バースト・カウントは、ベース・アドレスから開始し、順次増加転送する
データのワード数を表します。バースト転送は、プロセッサ、DMA、およびバッ
ファ処理アクセラレータに共通ですが、マスタが非連続したアドレスにアクセスし
なければならない機会があります。その結果、バースト・マスタはシーケンシャル・
アドレスの数にバースト・カウントを設定し、次の場所のために、バースト・カウ
ントをリセットする必要があります。
アービトレーション・シェア・アルゴリズムはアドレスに制限がないので、カスタ
ム・マスタはすべてのリードまたはライト・トランザクションのためのシステム・
インタコネクト・ファブリックにプレゼント・アドレスを更新することができます。
バース・アダプタ
SOPC Builder は、バーストと非バースト・マスタ・ポートとスレーブ・ポートを混在
させるシステムを作成することができます。それはまた、別の最大バースト長をサ
ポートするバースト・マスタ・ポートとスレーブ・ポートを接続することができま
す。これらすべてのケースをサポートするために、適切な場合、SOPC Builder はバー
スト・アダプタを生成します。
マスタ・ポート・バースト長がスレーブ・ポートのバースト長を超過する場合は常
に、SOPC Builder は、バースト・アダプタを挿入します。SOPC Builder は、非バース
ト・マスタとスレーブ・ポートに 1 のバースト長を割り当てます。バースト・アダ
プタは、短いバーストに長いバーストを分割します。その結果、バースト・アダプ
タは、マスタとスレーブ・ポート間のアドレスとバーストカウント・パスにロジッ
クを追加します。
インタフェース・タイプの選択
非効率的な転送を回避するには、カスタム・マスタまたはスレーブ・ポートが適切
なインタフェースを使用する必要があります。シンプルなパイプライン、およびバー
スト・インタフェースが使用可能です。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 6 章 : SOPC Builder デザインの 最適化
転送スループットの増加
6‒19
シンプルなインタフェース
シンプルなインタフェースは、リードまたはライト用のパイプラインまたはバース
トをサポートしていません。その結果、パフォーマンスには限界があります。シン
プルなインタフェースは、マスタと、使用頻度の低いスレーブ・ポート間の転送に
適しています。SOPC Builder では、PIO、UART、および Timer は、単純な転送を使用し
て最大効率で動作するスレーブ・ポートが含まれています。
カスタム・コンポーネントをデザインする場合、簡単なインタフェースで開始する
ことを推奨します。パフォーマンスが問題になる場合、パイプライン化されたリー
ドやバーストのいずれかをサポートするコンポーネントを変更することができます。
パイプライン・インタフェース
シンプルなリードが使用されている場合、多くのシステムでは、リードのスルー
プットが不十分になります。お使いのシステムが高いリード・スループットを必要
とし、リード・レイテンシに過度に敏感でない場合、コンポーネントがパイプライ
ン化された転送を実装することができます。固定リード・レイテンシを持つコン
ポーネントを定義する場合、SOPC Builder は自動的にパイプライン化されたリードを
サポートするために必要なロジックを提供します。コンポーネントが可変レイテン
シの応答時間がある場合、有効なデータを示すために readdatavalid 信号を使用し
ています。SOPC Builder は、未処理のリード要求の最大数を処理するため
readdatavalid FIFO を実装しています。
効率的にパイプライン化されたリード転送をサポートするコンポーネントを使用す
るために、システムには、パイプライン・マスタを含める必要があります。パイプ
ライン化されたリード・マスタの例については 6–16 ページの「パイプライン化され
たリード・マスタの例」を参照してください。
バースト・インタフェース
バースト転送は、一般的に高レイテンシ・メモリおよびオフチップの通信インタ
フェースとの通信に使用されます。効率的にバースト対応スレーブ・ポートを使用
するには、バースト・マスタに接続する必要があります。効率的に動作するように
バーストが必要とするコンポーネントは、通常、短いバーストまたは非バースト転
送に伴うオーバーヘッド・ペナルティを持っています。
効率的に動作するためにコンポーネントにシーケンシャル転送が必要な場合、バー
スト対応スレーブ・ポートをデザインすることをお薦めします。バンクやロウを切
り替える際に、DDR SDRAM メモリはペナルティを受けているので、バーストを使用
して連続してアクセスされたと、パフォーマンスが改善されます。
任意の共有アドレス・バスとデータ・バス・アーキテクチャもバーストからの利点
を期待します。アドレスは共有アドレスバスとデータバスを介して転送されるたび
に、データ転送のスループットが低下します。アドレス・フェーズではオーバー
ヘッドが追加されるため、大規模なバーストを使用すると、バスのスループットが
向上します。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
6‒20
第 6 章 : SOPC Builder デザインの 最適化
転送スループットの増加
バースト・マスタの例
図 6–13 は、FIFO からデータを受信し、メモリに内容を書き込むバースト・ライト・
マスタのアーキテクチャを示しています。独自のバースト・コンポーネントのため
の出発点として、このマスタを使用できます。例えば、カスタム DMA、ハードウェ
ア・アクセラレータ、またはオフチップの通信インタフェースなどです。図 6–13 で
は、マスタはワード・アクセスを実行し、シーケンシャル・メモリの配置に書き込
みます。
図 6‒13. ライト・マスタのバースト
start_address[31:0] d
q
go load
1
Up
Counter
master_address[31:0]
0 s
D
increment_address count enable
Q
Vcc
byteenable[3:0]
EN
burst_begin
done
transfer_length[31:0] d
go
load
q
length[31:0]
master_burstcount[2:0]
Down
Counter
increment_address count enable
Tracking Logic/
State Machine
burst_begin
burst_count[2:0]
fifo_used[]
write
increment_address
waitrequest
user_data[31:0]
q
user_data_full
full
user_data_write
write
used[]
Look-Ahead FIFO
d
read acknowledge
writedata[31:0]
increment_address
go がアサートされると、address と length がレジスタされています。そして、次のク
ロック・サイクルで、制御ロジックは burst_begin をアサートします。システム・
インタコネクト・ファブリックに提示される master_address と master_burstcount
に加えて、burst_begin 信号は、内部コントロール信号を同期させます。ライト転送
の address、byteenable、および burstcount はバースト全体のために一定に保たな
ければなりませんので、これらの 2 つの信号のタイミングがバースト時に重要です。
非効率的なライトを回避するには、マスタは十分なデータが FIFO にバッファリング
されているときにのみバーストをポストします。スレーブは waitrequest をアサー
トすると、バーストの効率を最大化するためにマスタはストールする必要がありま
す。この例では、FIFO の used 信号は、FIFO に格納されているデータのワード数を追
跡し、十分なデータがバッファリングされることを確認します。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 6 章 : SOPC Builder デザインの 最適化
増加されるシステム周波数
6‒21
各ワード転送の後、address レジスタを増加し、length レジスタを減分します。ア
ドレスは、バースト内では一定です。転送がバースト境界で完了することが保証さ
れていないため、追加のロジックが短いバーストの完了を認識する必要があります。
アルテラ・ウェブサイトでの Accelerated FIR with Built-in Direct Memory Access Example
のウェブページは、図 6–13 で使用されるものと同様のパイプライン化されたリー
ド・マスタとバースト・ライト・マスタが含まれています。
増加されるシステム周波数
SOPC Builder で、SOPC Builder で生成されるロジックの量を減分し、クロック周波数
を上げるためにブリッジを導入することができます。
SOPC Builder で、システム・インタコネクト・トポロジを制御するためにブリッジを
使用できます。ブリッジでは、パイプラインとクロック・クロッシングの機能のよ
り詳細に制御を与え、システム・インタコネクト・ファブリックを細分化すること
ができます。
f この項では、ユーザーがすでに SOPC Builder User Guide での Avalon Memory-Mapped
Bridges の章を読んだことを前提としています。ブリッジを含むデザインの例を参照
するには、アルテラ・ウェブサイトの Nios II High-Performance Example With Bridges の
ウェブページを参照してください。
パイプライン・ブリッジの使用
パイプライン・ブリッジでは、Avalon-MM マスタ・ポートとスレーブ・ポートが含ま
れています。ブリッジのスレーブ・ポートへの転送は、ブリッジからコンポーネン
トのダウンストリームに接続するマスタ・ポートに伝播されます。ブリッジ・ポー
トの間に、次のパイプライン機能を追加するオプションがあります。
■
マスタ・ツー・スレーブのパイプライン
■
スレーブ・ツー・マスタのパイプライン
■
waitrequest のパイプライン
パイプライン・ブリッジのオプションは、ロジック使用率とリード・レイテンシを
増加することができます。結果として、その影響を慎重に、考慮する必要がありま
す。以下の項では、これらのオプションについて説明します。
マスタ・ツー・スレーブのパイプライン
複数のマスタがスレーブ・デバイスを共有する場合、マスタ・ツー・スレーブへの
パイプラインは有利です。スレーブ・ポートのためのアービトレーション・ロジッ
クは、address、writedata、および burstcount 信号をマルチプレックスする必要が
あります。単一のスレーブ・ポートに接続するマスタの数を増加すると、マルチプ
レクサ幅も増加します。これにより、タイミングの問題を引き起こす可能性があり
ます（スレーブ・コンポーネントが入力信号をレジスタしない場合）。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
6‒22
第 6 章 : SOPC Builder デザインの 最適化
増加されるシステム周波数
waitrequest 信号がクリティカル・タイミング・パスの一部となる場合、このオプ
ションは便利です。マスタ・アドレスによってドライブされ、waitrequest がアービ
トレーション・ロジックに依存しているため、マスタ・ツー・スレーブのパイプラ
インをイネーブルすると、このパスをパイプライン化するのに役立ちます。
waitrequest 信号がクリティカル・タイミング・パスの一部に残っている場合、パイ
プライン化されたブリッジの waitrequest のパイプライン機能を使用して検討して
ください。
単一のパイプライン・ブリッジが十分な改善を提供できない場合、図 6–14 が示すよ
うに、パイプライン処理を向上させるためにバイナリ・ツリーの構造でこのブリッ
ジを複数回インスタンス化し、スレーブ・ポートでマルチプレクサの幅を低減する
ことができます。
図 6‒14. ブリッジのツリー
Master 1
Master 2
Master 3
Master 4
M
M
M
M
arb
arb
S
S
Pipeline Bridge
Pipeline Bridge
M
M
arb
S
Shared
Slave
read data
write data and
control signals
スレーブ・ツー・マスタのパイプライン
スレーブ・ツー・マスタのパイプラインは、リード転送をサポートする多くのス
レーブに接続するマスタのために有利です。システム・インタコネクト・ファブ
リックは、マスタにすべてのリード・データパスにマルチプレクサを挿入します。
マスタの増加に接続するリード転送をサポートしているスレーブの数につれ、リー
ド・データ・マルチプレクサの幅がありません。パフォーマンスの向上が不十分な
場合、マスタ・ツー・スレーブのパイプラインと同様に、バイナリ・ツリー構造を
使用して fMAX を向上させるために複数のブリッジを使用できます。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 6 章 : SOPC Builder デザインの 最適化
増加されるシステム周波数
6‒23
waitrequest のパイプライン
waitrequest のパイプラインは、単一のマスタは多くのスレーブに接続する場合に有
利です。スレーブ・コンポーネントとシステム・インタコネクト・ファブリックが
waitrequest をドライブするので、ロジックの深さは、マスタに接続されているス
レーブの数が増加すると大きくなります。また、waitrequest はアービトレーショ
ン・ロジックをパイプラインするため、複数のマスタが単一のスレーブに接続した
ときにも便利です。
多くのケースでは、waitrequest 信号が read または write トランザクションポスト
されると同じサイクルの間にアサートする必要があるため、waitrequest 信号が組み
合わせ信号となります。waitrequest がマスタ read または write 信号上の一般的に
依存しているため、マスタ・ツー・スレーブおよびスレーブ・ツー・マスタのタイ
ミング・パスを作成します。図 6–15 は、厚いワイヤでこの往復のパスを示していま
す。
お使いのシステムの fMAX にこの往復のパスを防ぐためには、マスタ・ツー・スレー
ブのパイプラインを使用してパスの長さを短くすることができます。waitrequest 信
号がクリティカル・タイミング・パスの一部に残っている場合、waitrequest のパイ
プライン機能を使用して検討することができます。もう一つの可能性は
waitrequest 信号をレジスタして、スレーブが選択されていなくても、アサートして
おくことです。スレーブが選択されている場合、それはすぐに応答できるかどうか
を判断するための完全なサイクルを持っています。
図 6‒15. 典型的な低速の Waitrequest パス
Avalon-MM
Master Port
Avalon-MM
Slave Port
read
address
write
arbiter
read
write
chipselect
waitrequest
waitrequest
user_logic_busy
waitrequest from
other slave ports
or waitrequest
logic
クロック・クロッシング・ブリッジの使用
クロック・クロッシング・ブリッジには、Avalon-MM マスタ・ポートと Avalon-MM
スレーブ・ポートが含まれています。スレーブ・ポートへの転送は、マスタ・ポー
トに伝播されます。クロック・クロッシング・ブリッジは、独立した非同期クロッ
ク・ドメイン内のマスタとスレーブ・インタフェースを分離する FIFO のクロック・
クロッシングのペアが含まれています。
FIFO がクロック・ドメインのクロッシングに使用されるため、クロック・クロッシ
ング・ブリッジを使用する場合、データのバッファリングの付加的な利点を得るこ
とができます。バッファリングは、ブリッジからのダウンストリームされるスレー
ブがパイプライン化された転送をサポートしていない場合でも、パイプライン化さ
れたリード・マスタが複数のリードをポストすることができます。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
6‒24
第 6 章 : SOPC Builder デザインの 最適化
増加されるシステム周波数
コンポーネント周波数の増加
クロック・クロッシング・ブリッジの最も一般的な用途の 1 つは、別のクロック・
ドメインで、高周波数および低周波数コンポーネントを配置することです。高いパ
フォーマンスを必要とするデザインの一部に高速クロック・ドメインを制限する場
合、デザインのこの部分のためのより高い fMAX を達成することができます。
優先順位の低い周波数の低減
エンベデッド・デザインに含まれるコンポーネントの大半はより高い周波数で動作
するの恩恵はありません。高い周波数を必要としないコンポーネントの例としては
タイマ、UART、および JTAG コントローラです。
Quartus II デザイン・ソフトウェアを使用してデザインをコンパイルすると、フィッ
タは、FPGA の領域にロジックを配置します。システムのクロック周波数が高くなる
と、コンパイルは時間がかかります。フィッタは、必要な fMAX を達成するためにレ
ジスタを配置するより多くの時間を必要とするため、コンパイルは時間がかかりま
す。フィッタは低い優先順位と低パフォーマンスのコンポーネントに使用される作
業量を削減するには、フィッタは、より高い優先順位と高い周波数のデータパス上
に配置される作業を深めることができるように、低い周波数で動作するクロック・
クロッシング・ブリッジの後ろに配置することができます。
ブリッジを使用した結果
デザインでブリッジを渡るパイプラインやクロックを使用する前に、慎重に効果を
考慮する必要があります。ブリッジでは、デザインに以下のような影響の任意の組
み合わせを含めることができます。
■
レイテンシの増加
■
制限された並列性
■
アドレス・スペース変換
システムによっては、これらの効果は、正または負である可能性があります。効果
を決定するために挿入するブリッジの前と後にお使いのシステムをテストするベン
チマークを使用できます。以下の項では、ブリッジを追加した場合の効果を説明し
ます。
レイテンシの増加
デザインへのブリッジのどちらかのタイプを追加すると、マスタとスレーブ間リー
ド・レイテンシに影響を及ぼします。システム要件およびマスタとスレーブのタイ
プに応じて、このレイテンシ増加は、デザインに許容されない場合があります。
許容されるレイテンシの増加
パイプライン・ブリッジは、レイテンシのサイクルがイネーブルされるパイプライ
ンの各オプションに追加されます。クロック・クロッシング・ブリッジでのバッ
ファリングは、レイテンシが追加されます。多くのリード転送をポストするパイプ
ライン・マスタまたはバースト・マスタを使用する場合は、データ転送の長さに比
べて非常に小さいので、レイテンシの増加が著しい程度にパフォーマンスに影響を
与えません。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 6 章 : SOPC Builder デザインの 最適化
増加されるシステム周波数
6‒25
例えば、シングルのワード転送しか実行していない 4 クロック・サイクルの固定
リード・レイテンシがあるコンポーネントからデータを読み出すためにパイプライ
ン化されたリード・マスタ（例えば、DMA コントローラなど）を使用する場合、
オーバーヘッドは 4 クロック・サイクルのうちに 3 になります。リードのスルー
プットはわずか 25％です。
図 6‒16. 低効率のリード転送
Read Latency
Read Latency
Overhead
Overhead
clk
address
A0
A1
read
waitrequest
readdata
D0
D1
一方、データの 100 ワードは中断せずに転送される場合、オーバーヘッドは合計の
103 クロック・サイクルのうちに 3 サイクルとなり、約 97％のリード効率に対応し
ます。このリード・パスにパイプライン・ブリッジを追加すると、レイテンシの 2
つの余分のクロック・サイクルを追加します。転送が約 94％の効率に相当完了する
ために 105 サイクルが必要です。効率が 3％で減少しましたが、ブリッジを追加する
と fMAX が 5％で増加します。全体のスループットが向上します。転送されるワード
数を増加させると、効率がパイプライン・ブリッジが存在しているかどうかにかか
わらず、100％に近づくように増加します。
図 6‒17. 高効率のリード転送
Read Latency
Overhead
clk
address
A0
A1
A2
A3
A4
A5
A6
A7
A8
A9
A10 A11 A12
D0
D1
D2
D3
D4
D5
D6
read
waitrequest
readdatavalid
readdata
D7
D8
許容されていないレイテンシの増加
プロセッサは、高レイテンシ・リード時間に敏感です。通常、計算に続行できない
データを到着するまでフェッチします。プロセッサの命令またはデータ・マスタの
データパスへのブリッジを追加する前に、クロック周波数の増加が追加レイテンシ
を正当化するかどうかを決定します。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
6‒26
第 6 章 : SOPC Builder デザインの 最適化
増加されるシステム周波数
次のデザイン例ではこの点を示しています。オリジナルのデザインは、Nios II プロ
セッサおよび 100 MHz で動作するメモリが含まれています。Nios II プロセッサの命令
マスタは 4 サイクルのリード・レイテンシを持つキャッシュ・メモリがあります。
各リードには、データの 8 シーケンシャル・ワードがリターンされています。
100 MHz で、最初のリードが完了するまでに 40 ns かかります。それぞれの成功した
ワードは 10 ns がかかります。したがって、8 リードは 110 ns で完了します。
図 6‒18. 4 サイクル・レイテンシを持つ 8 リード
110 ns
40 ns
clk
address
A0
A1
A2
A3
A4
A5
A6
A7
D0
D1
D2
D3
read
waitrequest
readdatavalid
readdata
D4
D5
D6
D7
クロックを追加すると、クロッシング・ブリッジは、メモリが 125MHz で動作させる
ことができます。しかし、周波数の増加は、次のような理由でレイテンシの増加に
よって否定されます。クロック・クロッシング・ブリッジは、100 MHz でのレイテン
シ 6 クロック・サイクルを追加することを想定しています。メモリはまだ 4 クロッ
ク・サイクルのリード・レイテンシで動作します。リードは、プロセッサの周波数
の 100 MHz で着くので、その結果として、メモリからの最初のリードには 100 ns か
かり、それぞれの連続したワードは 10 ns かかります。合計としては、170 ns で 8
リードを完了できます。メモリはより高いクロック周波数で動作しますが、マスタ
が動作する周波数は、スループットを制限します。
図 6‒19. 10 サイクル・レイテンシを持つ 8 リード
170 ns
100 ns
clk
address
A0 A1 A2 A3 A4 A5 A6 A7
read
waitrequest
readdatavalid
readdata
D0 D1 D2 D3 D4 D5 D6 D7
制限された並列性
複数の Avalon-MM マスタとスレーブ・ポート間の Avalon ブリッジを配置すると、シ
ステムが開始することができる同時転送の数を制限します。この制限は、単一のス
レーブ・ポートに複数のマスタ・ポートを接続するよりも違いはありません。ブ
リッジのスレーブ・ポートは、すべてのマスタによって共有されます。結果として、
アービトレーショ・ンロジックが作成されます。ブリッジの後ろに配置されたコン
ポーネントが頻繁にアクセスしている場合、この並行性の制限は許容できるかもし
れません。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 6 章 : SOPC Builder デザインの 最適化
増加されるシステム周波数
6‒27
ブリッジでは、不適切に使用すると、システムのパフォーマンスに深刻な悪影響を
及ぼす可能性があります。例えば、複数のメモリを複数のマスタによって使用され
ている場合、ブリッジの後ろにすべてを配置しないようにしてください。ブリッジ
は同時メモリ・アクセスを防止することにより、メモリのパフォーマンスが制限さ
れます。ブリッジの後ろに複数のメモリ・コンポーネントを配置すると、別のス
レーブ・インタフェースはブリッジにアクセスするマスタへの 1 つのモノリシック・
メモリとして表示されます。それらはすべての同じスレーブ・ポートにアクセスす
る必要があります。図 6–20 は、このコンフィギュレーションを示しています。
図 6‒20. 悪いメモリ・パイプライン
Nios II
Processor
M
DMA
M
M
M
Arbiter
S
bottleneck
Bridge
M
2011 年７月
Altera Corporation
S
S
S
S
DDR
SDRAM
DDR
SDRAM
DDR
SDRAM
DDR
SDRAM
エンベデッド・デザイン・ハンドブック
6‒28
第 6 章 : SOPC Builder デザインの 最適化
増加されるシステム周波数
メモリ・インタフェースの fMAX が低い場合、図 6–21 が示すように、並行性を犠牲せ
ずに、システムの fMAX を増加させる独自のブリッジの後ろに各メモリを配置するこ
とができます。
図 6‒21. 効率的なメモリ・パイプライン
Nios II
Processor
M
DMA
M
M
M
Arbiter
Arbiter
Arbiter
Arbiter
S
S
S
S
Bridge
Bridge
Bridge
Bridge
M
M
M
M
S
S
S
S
DDR
SDRAM
DDR
SDRAM
DDR
SDRAM
DDR
SDRAM
アドレス・スペース変換
パイプラインやクロック・クロッシング・ブリッジのスレーブ・ポートは、ベース・
アドレスとアドレスのスパンがあります。ベース・アドレスを設定したり、SOPC
Builder が自動的に設定することができます。スレーブ・ポートのアドレスは、ブ
リッジに接続されているすべてのコンポーネントのベース・オフセット・アドレス
です。ブリッジに接続されたコンポーネントのアドレスはベース・オフセットとそ
のコンポーネントのアドレスの合計です。接続されたすべてのコンポーネントのア
ドレス範囲に基づいて、ブリッジのアドレス・スパンは自動的に SOPC Builder で計算
されます。
アドレスのシフト
ブリッジのマスタ・ポートは、ブリッジのスレーブ・ポートのベース・アドレスか
らのオフセットを表すアドレスビットをドライブします。Avalon-MM マスタがブリッ
ジを介してスレーブにアクセスする任意の時間では、両方のアドレスは一緒に追加
される必要があります。そうでなければ、転送が失敗する可能性があります。SOPC
Builder での Address Map ボタンをクリックすると、各マスタに接続されたスレーブ
のアドレスが表示されます。それは、システム内のブリッジによって生じるいかな
るアドレス変換を考慮します。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 6 章 : SOPC Builder デザインの 最適化
増加されるシステム周波数
6‒29
図 6–22 はアドレス変換を示しています。この例で、Nios II プロセッサは、ベース・
アドレス 0x1000 にあるブリッジに接続されています。スレーブは 0x20 のオフセッ
トでマスタでブリッジ・ポートに接続し、プロセッサはスレーブ内の 4 番目の 32
ビット・ワードにライト転送を実行します。Nios II プロセッサはシステム・インタコ
ネクト・ファブリックへのブリッジのアドレス範囲内にあるアドレスの 0x102C をド
ライブします。ブリッジ・ポートはマスタ・スレーブのアドレス範囲内にあるレジ
スタの 0x2C をドライブし、転送が完了します。
図 6‒22. Avalon ブリッジ・アドレスの変換
Nios II Processor
M
Bridge
0x102C
S
0x2C
Peripheral
M
0x2C
S
baseAddr = 0x1000
0xC
Addr
Decoder
baseAddr = 0x20
Address Translation
Address Translation
アドレス・コヒーレンシ
ソフトウェア内の不要な合併症を避けるために、すべてのマスタが同じ位置でス
レーブをアクセスする必要があります。多くのシステムでは、プロセッサは、DMA
コントローラなどの他のマスタリング・コンポーネントにバッファ位置を渡します。
プロセッサと DMA コントローラが同じ位置にスレーブにアクセスしない場合、ソフ
トウェアが相違点を補正する必要があります。
次の例では、Nios II プロセッサと DMA コントローラは、アドレスの 0x20 に位置する
スレーブ・ポートをアクセスします。プロセッサは、スレーブ・ポートに直接接続
します。DMA コントローラは、スレーブ・ポートに接続するアドレスの 0x1000 に位
置するパイプライン・ブリッジに接続されています。DMA コントローラは、最初の
パイプライン・ブリッジをアクセスするので、スレーブ・ポートの最初の位置にア
クセスするために 0x1020 をドライブする必要があります。プロセッサは別の位置か
らスレーブにアクセスするため、ソフトウェア開発者は、スレーブ・デバイスに 2
つのベース・アドレスを保持する必要があります。
図 6‒23. ソフトウェアを複雑する異なるアドレスでのスレーブ
Nios II Processor
M
0x20
Peripheral
masters drive
different addresses
DMA
Arbiter
0x1020
S
0x20
0x0
Addr
Decoder
0x20
Bridge
M
S
M
0x20
0x1000
Address Translation
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
6‒30
第 6 章 : SOPC Builder デザインの 最適化
増加されるシステム周波数
この問題を回避するには、デザインへの追加ブリッジを追加して、0x1000 にその
ベース・アドレスを設定することができます。それは、システムのタイミングおよ
びリソース使用率への影響は最小限に抑えられているように、この第二のブリッジ
内のすべてのパイプラインのオプションをディセーブルすることができます。この
第二のブリッジは DMA コントローラが接続するブリッジと同じベース・アドレスが
あるため、プロセッサと DMA コントローラは同じアドレス範囲でスレーブ・ポート
をアクセスします。
図 6‒24. ブリッジによる補正されるアドレス変換
Address Translation
Nios II Processor
M
Bridge
0x1020
S
0x20
M
0x20
Base = 0x1000
Peripheral
Arbiter
M
0x1020
S
0x20
0x0
Addr
Decoder
Base = 0x20
Bridge
DMA
S
M
0x20
Base = 0x1000
Address Translation
システム・インタコネクト・ロジックの最小化
SOPC Builder で、システムのアドレス・スペースのコントロールと同様に、マスタと
スレーブ間の接続を持っています。このコントロールを使用すると、システム全体
のパフォーマンスを向上させるために、システムに若干の変更をすることができま
す。次の項では、システムの fMAX を向上させるために実行可能なデザインの変更を
説明します。
■
一意のアドレス・ビットの使用
■
専用のマスタとスレーブの接続の作成
■
不要な接続の削除
一意のアドレス・ビットの使用
システム内のすべてのスレーブは、SOPC Builder はスレーブを選択するアービタをド
ライブするために比較ロジックを挿入します。マスタが提示されたアドレスがス
レーブ・ポートのアドレス範囲内にあるかどうかを決定することにより、スレーブ・
ポートへのアクセスを実行している場合、この比較ロジックを決定します。この結
果は、転送がスレーブ・ポートのために運命づけられているかどうかを決定するた
めにマスタのリードとライト信号で AND されています。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 6 章 : SOPC Builder デザインの 最適化
増加されるシステム周波数
6‒31
結果は、スレーブ・ポートをドライブするために使用されるため、比較ロジックは
失敗タイミング・パスの一部になることができます。このパスの長さを短縮するに
は、比較のためにユニークな MSB を使用するスレーブ・ポートのベース・アドレス
を移動することができます。他のスレーブ・ポートと共有する MSB のベース・アド
レスを使用しないようにした場合、頻繁に、単一のロジック・エレメントに比較ロ
ジックを低減することができます。
それぞれ単一のマスタに接続されている 0x10 バイトのアドレス範囲を有する 4 ス
レーブ・ポート付きのデザインを検討してみてください。SOPC Builder での自動
Auto-Assign Base Addresses オプションを使用する場合、二進数の 6b'000000、
6b'010000、6'b100000、および 6b'110000 に対応する 4 スレーブのためのベース・ア
ドレスは、0x0、0x10、0x20、および 0x30 に設定されています。2 つの MSB は、転
送がスレーブ・ポートのいずれかのために運命づけられていることを決定するため
にデコードする必要があります。
アドレスは 0x10、0x20、0x40、および 0x80 に配置される場合、比較ロジックは必要
ありません。これらのバイナリの場所は次のとおりです：6'b00010000、
6b'00100000、6b'01000000、と 6b'10000000。シングル・アサートされたアドレス・
ビットがスレーブ転送が行われているかどうかを決定する比較ロジックを置き換え
るため、この手法はワン・ホットのエンコーディングと呼ばれています。この例に
おいて、アドレスを移動させることにより獲得された実行は最小である可能性があ
ります。ただし、マスタに別のアドレス・スパンの多くのスレーブ・ポートを接続
したときにこのテクニックはかなりの改善をもたらすことができます。
専用のマスタとスレーブの接続の作成
いくつかの状況では、マスタ・ポートが単一のスレーブ・ポートに接続するように
システムを変更することが可能です。このコンフィギュレーションでは、アドレス
のデコード、アービトレーション、およびリターン・データのマルチプレックスが
排除され、大幅にシステム・インタコネクト・ファブリックを簡素化します。専用
のマスタ・ツー・スレーブの接続は、Avalon-MM が提供する利点を付きの Avalon-ST
の接続と同じようにクロック周波数を達成します。
通常、これらの 1 対 1 の接続は、Avalon-MM ブリッジまたはハードウェア・アクセラ
レータが含まれています。例えば、スレーブと他のすべてのマスタ・ポート間のパ
イプライン・ブリッジを挿入した場合、ブリッジ・マスタとスレーブ・ポート間の
ロジックは、ワイヤに低減されます。図 6–21 にはこの方法を示します。ハードウェ
ア・アクセラレータが専用メモリに接続する場合、システム・インタコネクト・ロ
ジックは、マスタとスレーブのペア間で生成されません。
不要な接続の削除
マスタとスレーブ・ポート間の接続の数は、システムの fMAX に大きな影響を与えて
います。スレーブ・ポートに接続しているすべてのマスタ・ポートはマルチプレク
サ選択の幅が増加します。マルチプレクサの幅が増加するにつれて、FPGA 内のマル
チプレクサを実装するロジックの深さと幅も増加します。システムのパフォーマン
スを改善するために、マスタと複数のスレーブは、必要なときにのみ接続します。
多くのスレーブ・ポートに接続するマスタ・ポートの場合、readdata 信号用のマル
チプレクサも増加します。図 6–14 が示すように、マルチプレクサのこの深さを制御
するために、ブリッジを使用します。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
6‒32
第 6 章 : SOPC Builder デザインの 最適化
ロジックの使用率の低減
ロジックの使用率の低減
システム・インタコネクト・ファブリックは、Avalon-MM および Avalon-ST インタ
フェースをサポートしています。Avalon-ST インタフェースのためのシステム・イン
タコネクト・ファブリックは軽量ですが、その同一は、Avalon-MM インタフェースに
対して常に真ではありません。この項では、システム・インタコネクト・ファブ
リックのロジック・フットプリントを削減することができるデザインの変更点につ
いて説明します。
コンポーネントを統合することによるアービトレーション・ロジッ
クの最小化
デザインでのコンポーネントの数が増加すると、システム・インタコネクト・ファ
ブリックを実装する必要なロジックの増加します。アービトレーション・ブロック
の数は、複数のマスタ・ポートで共有されているすべてのスレーブ・ポートに増加
します。readdata マルチプレクサの幅がマスタ・ポート・ベースの当たりに read 転
送の増加をサポートするスレーブ・ポートの数が増加します。これらの理由から、
システム・インタコネクト・ファブリックのロジック使用率を削減するための単一
のコンポーネントとしてロジックの複数のブロックを実装することを検討してくだ
さい。
ロジック統合のトレードオフ
お使いのシステムまたはコンポーネントに任意の変更を実行する前に、次の 2 のト
レードオフを考慮してください。まず、統合コンポーネントが持っている並行性の
影響を考慮してください。システムに 4 つのマスタ・コンポーネントと 4 つのス
レーブ・コンポーネントを持っているとき、4 つの並行性アクセスを開始することが
できます。単一のコンポーネントにすべての 4 つのスレーブ・コンポーネントを統
合する場合、4 つすべてのマスタがアクセスするために競争する必要があります。し
たがって、組み合わせがパフォーマンスに影響しない優先順位の低いコンポーネン
ト（例えば、低速パラレル I/O デバイスなど）を組み合わせる必要があります。
第二に、統合がシステム・インタコネクト・ファブリックが以前に含まれている
レーブ・ポートのための新しいデコードおよび多重化ロジックを紹介することを決
定します。コンポーネントが複数のリードとライトのアドレス位置が含まれている
場合、必要な復号化および多重化ロジックが含まれています。コンポーネントを統
合するとき、通常、デコーダを再使用し、マルチプレクサ・ブロックは既に元のコ
ンポーネントのいずれかに存在します。ただし、重複をなくすよりも、複合コン
ポーネントはデコーダおよびマルチプレクサ・ロジックを単に移動する可能性があ
ります。
複合コンポーネントの例
図 6–25 に、ソフトウェアのリードバックをサポートする 4 つの出力レジスタの設定
を示します。レジスタは、SOPC Builder で 4 つの PIO のコンポーネントを使用して実
装することが可能ですが、この例では、同じロジックのより効率的な実装を提供し
ます。メモリ位置にマップされる複数のレジスタを含むすべてのコンポーネントを
実装するために、この例をテンプレートとして使用することができます。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 6 章 : SOPC Builder デザインの 最適化
ロジックの使用率の低減
6‒33
リードおよびライトを実装するコンポーネントは、3 つの主要なビルディング・ブ
ロックが必要とします：アドレス・デコーダ、レジスタ・ファイル、およびリード・
マルチプレクサ。この例では、リード・データはレジスタ・ファイルの出力のコ
ピーです。リードバック機能は冗長に見えるかもしれませんが、それは検証のため
に有用です。
図 6‒25. 4 つの PIO
Avalon-MM
Slave Port
Read Back
Multiplexer
readdata[31:0]
Q
D
s
EN
read
address[1:0]
Exported
Signals
Register File
D
Decode
2:4
0
Q
EN
D
Q
EN
1
D
Q
EN
2
D
write
Q
EN
EN
3
writedata[31:0]
デコーダはライトための適切な 32 ビットの PIO レジスタがイネーブルします。リー
ドのために、アドレスビットは、マルチプレクサの選択ビットをドライブします。
コンポーネントが高いクロック周波数を達成できるように、read 信号は、マルチプ
レクサからのデータをレジスタします。SOPC Builder コンポーネント・エディタで
は、このコンポーネントは 0 のライト・ウェイト・ステートと 1 の リード・ウェイ
ト・ステートがあるものとして説明されます。また、このコンポーネントは、パイ
プライン化リードをサポートしているため、リードとライト・ウェイト・ステート
の両方が 0 に設定して、1 のリード・レイテンシを指定することができます。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
6‒34
第 6 章 : SOPC Builder デザインの 最適化
ロジックの使用率の低減
システム・インタコネクト・ファブリック・ロジックを最小化する
ブリッジの使用
ブリッジは、SOPC Builder によって生成されたアービトレーションおよびマルチプレ
クサ・ロジックの量を低減することにより、システム・インタコネクト・ファブ
リック・ロジックを低減します。ブリッジが発生する同時転送数を制限するため、
この減少が発生します。次の項では、SOPC Builder によって生成されたロジックを最
小限にして、システムのパフォーマンスを最適化するためにブリッジを使用する方
法について説明します。
SOPC Builder の速度の 最適化
システム・インタコネクト・ファブリックの SOPC Builder は、スレーブ側のアービト
レーションのサポートを生成します。結果として、SOPC Builder は、複数の AvalonMM マスタ・ポートで共有されるすべての Avalon-MM スレーブ・ポートのアービト
レーション・ロジックを作成します。SOPC Builder は、両方のポートがリード・デー
タパスをサポートする場合、多数のスレーブ・ポートへ接続するマスタ・ポートの
間にマルチプレクサ・ロジックを挿入します。システム・インタコネクト・ファブ
リック用に生成されるロジックの量は、システムの増加に合わせて増加します。
インタコネクト・ファブリックは、複数の同時転送をサポートしていますが、シス
テムのマスタとスレーブ・ポートは一度に一つの転送を処理することができます。4
つのマスタが単一のスレーブに接続している場合、アービタはラウンド・ロビンの
シーケンス内の各アクセスを付与します。すべての 4 つのマスタは、Avalon ブリッ
ジとブリッジ・マスタとスレーブ・ポートに接続する場合、アービトレーション・
ロジックはブリッジのスレーブ・ポートから移動します。
図 6‒26. スレーブへの 4 つのマスタ対ブリッジへの 4 つのマスタ
M
M
M
M
Arbiter
M
M
M
M
Arbiter
Bridge Inserted
S
S
Bridge
M
S
図 6–26 では、パイプライン・ブリッジは address と writedata を含むアービトレー
ション・ロジックの出力信号をレジスタします。アービトレーション・ブロックの
マルチプレクサは、これらの信号をドライブします。ロジック・エレメント（LE）
では組み合わせロジックおよびレジスタ・ロジックの両方が含まれているため、こ
の追加のパイプラインは、ロジック・フットプリントにはわずかな効果、あるいは
まったく効果のないようになります。また、追加のパイプライン・ステージは、シ
ステムのパフォーマンスを向上させるレジスタ間のロジックの量を低減します。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 6 章 : SOPC Builder デザインの 最適化
ロジックの使用率の低減
6‒35
デザインの fMAX を増加させることができる場合、Quartus II ソフトウェアの Settings
ダイアログ・ボックスで Physical Synthesis Optimizations ページに Perform register
duplication をオフにすることができます。レジスタ重複は、レジスタ間の遅延を低
減するための試みで、FPGA 内の 2 つ以上の物理的な位置にジックを重複ロします。
また、Quartus II ソフトウェアの Settings ダイアログ・ボックスの Analysis & Synthesis
Settings ページで Optimization Technique の速度を選択しないようにすることができ
る。通常、この設定により、ハードウェア・フットプリントが大きくなります。
Avalon-MM ブリッジで使用可能なレジスタまたは FIFO を使用することによって、デ
ザイン速度を増加させ、不必要なロジックの重複や速度の最適化を回避することが
できます。それより、デザインのロジック使用率を低減することができます。
並列性の低減
ほとんどのエンベデッド・デザインは、高いデータ・スループットをサポートする
コンポーネント、または単に頻繁にアクセスする必要のないコンポーネントのいず
れかが含まれています。これらのコンポーネントは、Avalon-MM マスタまたはスレー
ブ・ポートを含めることができます。システム・インタコネクト・ファブリックは、
同時アクセスをサポートしているので、アービトレーションおよび生成されたマル
チプレクサ・ロジックの量を制限するために、データパスにブリッジを挿入するこ
とで、この並列性を制限することができます。例えば、システムがすべての相互接
続されている 3 つのマスタおよび 3 つのスレーブ・ポートが含まれている場合、
SOPC Builder は、リード・データパスのための 3 つのアービタと 3 つのマルチプレク
サを生成します。
これらのマスタがスループットのかなりの量を必要としないことを仮定して、単純
にパイプライン・ブリッジへのすべての 3 つのマスタを接続することができます。
ブリッジ・マスタの 3 つのすべてのスレーブ・ポートは、効果的にバス構造にシス
テム・インタコネクト・ファブリックを低減します。SOPC Builder は、ブリッジと 3
つのマスタ間の 1 アービトレーション・ブロックを作成し、ブリッジと 3 つのス
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
6‒36
第 6 章 : SOPC Builder デザインの 最適化
ロジックの使用率の低減
レーブ間のシングル・リード・データパスのマルチプレクサを作成します。この
アーキテクチャは、標準的なバス構造と同じように、並列性を防止します 。した
がって、この方法は、高スループットのデータパスのために使用すべきではありま
せん。図 6–27 は、パイプライン・ブリッジがある場合とない場合のシステム間の
アーキテクチャの違いを示しています。
図 6‒27. バスへのファブリックのスイッチ
Concurrency
M
M
No Concurrency
M
M
M
M
M
Arbiter
S
Bridge
M
Arbiter
Arbiter
Arbiter
S
S
S
S
S
S
Writedata and Control Signals
Readdata
アダプタ・ロジックを最小限に抑えるブリッジの使用
マスタとスレーブのポートのペアのクロック・ドメインまたはバースト機能の間に
ミスマッチがある時、SOPC Builder は、クロック・クロッシングとバーストをサポー
トするためにアダプタ・ロジックを生成します。バースト・アダプタはマスタの最
大バースト長がスレーブのマスタ・バースト長を超えているときに作成されます。
アダプタ・ロジックは、余分なロジック・リソースを作成します。お使いのシステ
ムが同じ特性を共有していない多くのコンポーネントに接続される Avalon-MM マス
タ・ポートが含まれている場合、このアダプタ・ロジックが大幅になることがあり
ます。デザインにブリッジを配置することによって、SOPC Builder で生成されるアダ
プタ・ロジックの量を低減することができます。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 6 章 : SOPC Builder デザインの 最適化
ロジックの使用率の低減
6‒37
ブリッジの効果的な配置
まず、接続されたスレーブ・デバイスが異なるバースト機能をサポートしているこ
と、または異なるクロック・ドメインで動作するかどうかを判断するシステム内の
各マスタを分析します。デバイスの最大のバースト数は、GUI で burstcount パラメー
タとして表示されることがあります。そうでない場合、コンポーネントの HDL ファ
イルで burstcount 信号の幅を確認してください。最大バースト長は 2 （width
（burstcount）-1） であり、burstcount の値は 8 ～ 15 の場合（burstcount の幅は 4 ビットであ
ることを含む）、最大バースト長が 8 になります。burstcount 信号が存在しない場
合、コンポーネントはバーストをサポートしていないこと、または 1 のバースト長
さがあることを示します。
クロック・クロッシング・アダプタは、マスタとスレーブのポート間で必要とされ
るかどうかを判断するには、SOPC Builder でマスタ・ポートとスレーブ・ポートの横
に clock カラムをチェックします。示されるクロックがマスタとスレーブ・ポートの
クロックと異なる場合、SOPC Builder はそれらの間にクロック・クロッシング・アダ
プタをの挿入します。アダプタが 1 つのみ作成されるようにブリッジの後ろにス
レーブ・ポートを含むコンポーネントを配置することができます。それにより、複
数のアダプタが作成されるのを回避することができます。ブリッジの後ろに同じ
バーストまたはクロック特性を持つ複数のコンポーネントを配置することで、並列
性およびアダプタの数を制限します。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
6‒38
第 6 章 : SOPC Builder デザインの 最適化
ロジックの使用率の低減
コンパクトなシステム例
図 6–28 には異なるバースト機能を持つ混在されたコンポーネントのシステムを示し
ます。それでは、Nios II/e コア、Nios II/f コア、および Nios II/f コアにいくつかの処理
するタスクをオフロードする外部プロセッサが含まれています。Nios II/e コアは、
Nios II/f コアと外部プロセッサ間の通信を維持します。Nios II/f コアは、8 つの最大
バーストサイズをサポートしています。外部プロセッサ・インタフェースは、最大
バースト長の 64 をサポートしています。Nios II/e コアは、バーストをサポートしてい
ません。システムでの唯一のメモリは最大バースト長の 2 を持つ Avalon 付きの DDR
SDRAM です。
図 6‒28. 混合バースト・システム
Nios II/e Core
Nios II/f Core
M
M
M
M
8
8
64
8
B
1
M
8
8
B
Host Processor
Interface
B
8
64
B
1
1
8
B
B
1
1
8
B
2
64
B
2
Arbiter
Arbiter
Arbiter
Arbiter
Arbiter
S
S
S
S
S
PIO
System ID
Timer
Mutex
DDR
SDRAM
2
2
B
Burst Adapter
8
Maximum Burst Count
SOPC Builder はバースト長のミスマッチを補正するバースト・アダプタを自動的に挿
入します。アダプタは、2 つまたはシングル転送の長さにバーストを低減します。
DDR SDRAM に接続する外部プロセッサ・インタフェースは、64 ワードのバーストは
32 のバースト転送（それぞれ 2 のバースト長）に分かれています。
システム生成時に、SOPC Builder は最大のバースト・カウントの値に基づいて、バー
スト・アダプタを挿入します。その結果、マスタがバーストに対応している場合、
システム・インタコネクト・ファブリックは、マスタとバースト必要としないス
レーブ・ペア間のバースト・アダプタが含まれています。図 6–28 では、SOPC Builder
は Nios II プロセッサとタイマ、システム ID、および PIO ペリフェラルの間のバース
ト・アダプタを挿入します。これらのコンポーネントはバーストをサポートしてい
ないため、Nios II プロセッサは、これらのデバイスへのシングル・ワードのリード
およびライト・アクセスのみ実行します。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 6 章 : SOPC Builder デザインの 最適化
電力の使用率の削減
6‒39
アダプタの数を削減するには、図 6–29 が示すようにパイプライン・ブリッジを追加
することができます。バーストをサポートしていない Nios II/f コアとペリフェラルの
間のパイプライン・ブリッジは、図 6–28 に示される 3 バースト・アダプタを排除し
ます。最大バースト・サイズの 8 の Nios II/f コアと DDR SDRAM の間の第 2 のパイプ
ライン・ブリッジは、次のバースト・アダプタを排除します。
図 6‒29. ブリッジ付きの混合バースト・システム
Nios II/e Core
Nios II/f Core
M
M
M
Host Processor
Interface
M
M
8
8
64
8
64
64
B
1
B
B
1
8
8
S
S
Bridge
Bridge
M
M
2
8
B
2
Arbiter
Arbiter
Arbiter
Arbiter
Arbiter
2
S
S
S
S
S
PIO
System ID
Timer
Mutex
DDR
SDRAM
B
Burst Adapter
8
Maximum Burst Count
電力の使用率の削減
SOPC Builder は低消費電力モードをサポートする特定の機能を提供していませんが、
システムの消費電力を削減するための方法があります。この項では、システム・イ
ンタコネクト・ファブリックと、カスタム・コンポーネントの消費電力を削減する
ための様々な低消費電力のデザイン変更を説明します。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
6‒40
第 6 章 : SOPC Builder デザインの 最適化
電力の使用率の削減
非クリティカル・ロジックのクロック速度の減少
クロック周波数を下げると、消費電力を低減します。SOPC Builder がクロック・ク
ロッシングをサポートしているので、消費電力を削減できるように、高い周波数の
クロックを必要としないロジックのクロック周波数を低減することができます。別
のクロック・ドメインにクロック・クロッシング・ブリッジまたはクロック・ク
ロッシング・アダプタのいずれかを使用できます。
クロック・クロッシング・ブリッジ
より低い周波数で動作しているスレーブ・ポートには高い周波数で動作する AvalonMM マスタ・ポートを接続するために、クロック・クロッシング・ブリッジを使用
できます。低スループットまたは優先順位の低いコンポーネントだけ縮小したク
ロック周波数で動作するクロック・クロッシング・ブリッジの後ろに配置する必要
があります。効果的に遅いクロックド・メインに配置することができる代表的なコ
ンポーネントの例としては、以下のとおりです。
■
PIO
■
UART （JTAG または RS-232）
■
System identification （SysID）
■
タイマ
■
PLL（SOPC Builder でインスタンスかされる）
■
シリアル・ペリフェラル・インタフェース（SPI）
■
EPCS コントローラ
■
トライ・ステート・ブリッジとブリッジに接続されたコンポーネント
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 6 章 : SOPC Builder デザインの 最適化
電力の使用率の削減
6‒41
図 6–30 はクロック・クロッシング・ブリッジを含む SOPC Builder システムを示して
います。
図 6‒30. クロック・クロッシング・ブリッジを使用した低消費電力
Nios II
M
Arbiter
Arbiter
S
S
DDR
SDRAM
On-Chip
Memory
M
Arbiter
S
200 MHz
Clock
Crossing
Bridge
M
5 MHz
S
S
S
S
S
S
S
PIO
UART
System ID
Timer
PLL
SPI
EPCS
Controller
S
Tristate
Bridge
M
S
Flash
クロック・クロッシング・ブリッジの後ろにこれらのコンポーネントを配置すると、
リード・レイテンシが増加します。ただし、コンポーネントは、デザインのクリ
ティカル項の一部ではない場合でも、増加されるレイテンシは問題ではありません。
ブリッジに接続されているコンポーネントのクロック周波数を低減することによっ
て、デザインのダイナミック消費電力が削減します。ダイナミック消費電力は、ト
グル・レートの機能であり、クロック周波数を下げるとトグル・レートを低下させ
ます。
クロック・クロッシング・アダプタ
SOPC Builder は異なるクロック周波数で動作する Avalon-MM マスタとスレーブ・ポー
ト間のクロック・クロッシング・アダプタを自動的に挿入します。クロック・ク
ロッシング・アダプタは、クロック・ドメイン間でデータを転送するためにハンド
シェーク・ステート・マシンを使用しています。クロック・クロッシング・アダプ
タを定義する HDL コードは、他の SOPC コンポーネントと似ています。アダプタを
挿入していないため、SOPC Builder の Connection カラムに表示されません。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
6‒42
第 6 章 : SOPC Builder デザインの 最適化
電力の使用率の削減
クロック・クロッシング・ブリッジやクロック・クロッシング・アダプタの違いは、
デザインに適しているかを判断するのに役立ちます。次の項では、違いについて説
明します。
スループット
クロック・クロッシング・ブリッジがクロック・クロッシング・ロジックを実装す
るために FIFO を使用しているので、転送やデータをバッファリングします。クロッ
ク・クロッシング・アダプタは、データをバッファリングしていません。その結果、
完了するまで各トランザクションがブロックされています。トランザクションをブ
ロックすると、実質的にスループットが低下します。その結果、スループットを制
限せずに大幅に消費電力を削減したい場合、クロック・クロッシング・ブリッジを
使用する必要があります。デザインは単にシングルのリード転送を必要とする場合、
レイテンシがクロック・クロッシング・ブリッジよりも低くなるので、クロック・
クロッシング・アダプタを使用するほうが良いです。
リソースの使用率
クロック・クロッシング・ブリッジは、オンチップ・メモリに加えて実に少ないロ
ジック・リソースを必要とします。使用されるオンチップ・メモリ・ブロックの数
は、アドレス・スパン、データ幅、バッファリングの深さ、およびブリッジの機能
に比例します。クロック・クロッシング・アダプタは、任意のオンチップ・メモリ
を使用すると、ロジック・リソースの適度な数を必要としません。クロック・ク
ロッシング・アダプタのアドレス・スパン、データ幅、およびバースト機能はデバ
イスのリソース使用率を決定します。
スループットとメモリのトレードオフ
クロック・クロッシング・ブリッジとクロック・クロッシング・アダプタの間の選
択は、スループットとメモリの使用率の選択と言えます。オンチップ・メモリ・リ
ソースが制限されている場合、クロック・クロッシング・アダプタを選択すること
が余儀なくされることがあります。シングルのコンポーネントの消費電力を削減す
るクロック・クロッシング・ブリッジを使用すると、必要な追加のリソースを正当
化しないことがあります。単一のクロック・クロッシング・ブリッジの後ろにある
すべての優先順位の低いコンポーネントを配置すると、デザインの消費電力が低減
します。対照的に、異なる周波数で動作すること各マスタとスレーブ・ペア間にク
ロック・クロッシング・ブリッジを含めていない場合、SOPC Builder はクロック・ク
ロッシング・アダプタを挿入し、デザイン内のロジック使用率が増加します。
トグル・レートの最小化
デザインは、ロジックがオンとオフ・ステートの間ロジックに遷移するときに電力
を消費しています。ステートがクロック・エッジ間一定に保持されたとき、充電ま
たは放電が発生していません。この項では、システムのトグル・レートを低減する 3
つのデザイン手法を説明します。
■
コンポーネントの境界のレジスタ
■
クロックのイネーブル
■
ブリッジの挿入
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 6 章 : SOPC Builder デザインの 最適化
電力の使用率の削減
6‒43
コンポーネントの境界のレジスタ
アダプタまたはブリッジが存在しない場合、システム・インタコネクト・ファブ
リックは純粋な組み合わせとなります。スレーブ・ポートはマスタで選択されてい
ない場合、様々な信号がトグルし、コンポーネントに伝播する可能性があります。
Avalon-MM マスタまたはスレーブ・インタフェースでコンポーネントの境界をレジス
タすることには、システム・インタコネクト・ファブリックとコンポーネントのト
グルを最小限に抑えることができます。ポート・レベルで信号をレジスタするとき
には、コンポーネントは、Avalon-MM 仕様の範囲内で動作し続けることを確認する必
要があります。
通常、waitrequest はコンポーネントにレジスタを追加したときに同期するための最
も困難な信号です。waitrequest はマスタが転送を延長するためにリードやライトを
アサートする同じクロック・サイクルの間でアサートする必要があります。マスタ・
インタフェースは早すぎる waitrequest 信号を読み、多くのポストリード s と
xwrites 尚早かもしれません。マスタ・インタフェースは、waitrequest 信号をあま
りにも早く読み込んで、より多くのリードおよびライトを時期尚早にポストします。
スレーブ・インタフェースでは、システム・インタコネクト・ファブリックは任意
read または write 転送の最初のクロック・サイクルの間アサートされる
begintransfer 信号を管理します。waitrequest は 1 クロック・サイクルで遅く場合、
適切に同期化された新しい waitrequest 信号を形成するために論理的に
waitrequest と begintransfer 信号を OR にすることができます。
図 6‒31. 可変レイテンシ
Avalon-MM
Slave Port
Remainder of
Component
Logic
writedata
write
readdata
read
waitrequest
ready
(synchronous)
begintransfer
または、コンポーネントが選択される前に waitrequest をアサートできます。それ
により、転送の最初のクロック・サイクルの間に waitrequest がすでにアサートさ
れていることを保証します。
クロックのイネーブル
クロックが安定した状態でロジックを保持するには使用することができます。
Avalon-MM スレーブ・コンポーネントのためにクロック・イネーブルとして write
および read 信号を使用できます。コンポーネントの境界にレジスタを追加しても、
インタフェースは、潜在的にクロック・イネーブルを使用せずにトグルすることが
できます。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
6‒44
第 6 章 : SOPC Builder デザインの 最適化
電力の使用率の削減
また、コンポーネントの組み合わせ部分をディセーブルするためにクロック・イ
ネーブルを使用できます。例えば、コンポーネントがアクティブでないとき、トグ
ルから防ぐために組合せロジックへの入力をマスクするためにアクティブ High のク
ロック・イネーブルを使用できます。トグルから非アクティブ・ロジックを防止す
る前に、マスキングは、回路が異なる方法で動作をさせる場合に決定する必要があ
ります。このマスクは、機能障害を引き起こす場合、クロック・サイクル間の組み
合わせロジックを一定に保持するためのレジスタ・ステージを使用することは可能
です。
ブリッジの挿入
境界レジスタやクロック・イネーブルでコンポーネントを変更したくない場合、ト
グル・レートを低減するためにブリッジを使用できます。ブリッジは、スレーブ・
ポートへの転送がマスタ・ポート上で繰り返されているリピータとして機能します。
ブリッジがアクセスされていない場合、そのマスタ・ポートに接続されているコン
ポーネントもアクセスされていません。マスタがブリッジのスレーブ・ポートにア
クセスするまで、ブリッジのマスタ・ポートはアイドル状態のままです。
また、ブリッジは他のマスタ・ポートに入力される信号のトグル・レートを低減す
ることができます。通常、これらの信号は readdata、readdatavalid、および
waitrequest です。リード・アクセスをサポートするスレーブ・ポートは、これらの
信号をドライブにします。ブリッジを使用すると、マスタ入力信号のトグル・レー
トを低減させるためのにスレーブ・ポートとマスタの間のレジスタやクロック・ク
ロシング FIFO を挿入することができます。
ロジックのディセーブル
低消費電力モードの 2 つのタイプが一般的にあります：揮発性および非揮発性。揮
発性の低電力モードがリセット状態のコンポーネントを保持しています。ロジック
が再活動化されるときに、以前の動作状態は失われます。不揮発性の低消費電力
モードでは、以前の動作状態を復元します。この項では、ソフトウェアまたはハー
ドウェア制御のスリープ・モードのいずれかを使用して消費電力を低減するために
コンポーネントをディセーブルする 2 つの方法を説明しています。
ソフトウェア制御のスリープ・モード
ソフトウェア制御のスリープ・モードをサポートするコンポーネントをデザインす
るには、0 または 1 を書き込むことによって、ロジックがイネーブルとディセーブル
するにシングルのメモリ・マップされた配置を作成します。コンポーネントが非揮
発性の要件があるかどうかに応じてクロック・イネーブル信号またはリセットとし
てレジスタの出力を使用します。スレーブ・ポートは、コンポーネントをアクティ
ブにする必要がある場合、enable ビットがセットできるようにスリープ・モード時
にアクティブなままにする必要があります。
複数のマスタがスリープ・モードをサポートするコンポーネントにアクセスできる
場合、コンポーネントに相互排他的なアクセスを提供するために、SOPC Builder で使
用可能な Mutex コアを使用できます。また、システム内の任意のマスタが最初のア
クセス時にコンポーネントを再イネーブルするにはロジックで構築することができ
ます。コンポーネントが再アクティブ化するために複数のクロック・サイクルを必
要とする場合、スリープ・モードが終了すると転送を長引かせる waitrequest をア
サートする必要があります。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
第 6 章 : SOPC Builder デザインの 最適化
電力の使用率の削減
6‒45
f Mutex コアについて詳しくは、Embedded Peripherals IP User Guide の Mutex コアの章を参
照してください
ハードウェア制御のスリープ・モード
リードまたはライト・アクセスの間のクロック・サイクルで指定されたタイムアウ
ト値に基づいて、カスタム・コンポーネントが自動的にスリープ・モードに入るよ
うにタイマを実装することができます。各アクセスは、タイムアウト値にタイマー
をリセットします。アクセスなしの各サイクルは、1 でタイムアウト値に減分しま
す。カウンタが 0 になった場合、ハードウェアが次のアクセスまでスリープ・モー
ドに入ります。図 6–32 は、このロジックの回路図を提供しています。アクティブ・
ステートにコンポーネントを復元するとき時間がかかる場合、コンポーネントが連
続的にスリープ・モードを出入りしないように、長いタイムアウト値を使用します。
コンポーネントの残りの部分はスリープ・モードになっているとき、スレーブ・
ポート・インタフェースが機能している必要があります。コンポーネントがスリー
プ・モードを終了すると、リードまたはライト・アクセスの準備が整うまで、
waitrequest 信号をアサートする必要があります。
図 6‒32. ハードウェア制御のスリープ・コンポーネント
Timeout Value
d
count
q
reset
= 0?
Down
Counter
read
write
waitrequest
wake
load
count enable
sleep_n
busy
ドライブされる waitrequest のスリープ・モード
低消費電力、不揮発性、非アクティブ・モードに Nios II プロセッサ（またはマス
タ・ポート付の他の非カスタム・コンポーネント）を強制するには、Nios II プロ
セッサに接続し、Nios II プロセッサ・パイプラインをストールさせる waitrequest
をアサートするカスタム・コンポーネントを実装することができます。プロセッサ
を進行させるために、カスタム・コンポーネントは waitrequest 信号をデアサート
します。
2011 年７月
Altera Corporation
エンベデッド・デザイン・ハンドブック
6‒46
第 6 章 : SOPC Builder デザインの 最適化
改訂履歴
図 6–33 には、SOPC Builder システムでの Nios II プロセッサおよびカスタム・ストー
リング・コンポーネントの高レベルのブロック図を示します。Nios II プロセッサを
ストールするには、カスタム・コンポーネントへのリード要求を発行するプロセッ
サでが割り込みを発行します。そして、カスタム・コンポーネントは waitrequest
信号をアサートし、Nios II プロセッサをストールさせます。
図 6‒33. 非アクティブ・モードでドライブされる waitrequest
q
irq
stall request
Custom
Stalling
Component
Nios II
Processor
S
M
System Interconnect Fabric
f 電力利用を削減する方法について詳しくは、Quartus II ハンドブック Volume 2 の Power
Optimization に参照してください。
改訂履歴
表 6–1 に、本資料の改訂履歴を示します。
表 6‒1. 改訂履歴
日付
2011 年 7 月
バー
ジョン
変更内容
■
章がQsysシステム統合ツールについて説明していないことを明確にするため
に、章のタイトルを Avalon-MM Design Optimizations から SOPC Builder Design
Optimizations に変更。
■
ドライブされる waitrequest のスリープ・モードの項を追加。
■
参照を更新。
1.2
2008 年 6 月
1.1
目次を訂正。
2008 年 3 月
1.0
初版。
エンベデッド・デザイン・ハンドブック
2011 年７月
Altera Corporation
7. メモリ・システム・デザイン
2? 2010?
ED51008-1.2
ED51008-1.2
概要
このドキュメントでは、SOPC Builder エンベデッド・システムにおけるメモリの効率
的な使用方法について説明します。効率的なメモリ使用は、FPGA ベースのエンベ
デッド・システムの性能が向上します。エンベデッド・システムは、ソフトウェア・
コードのストレージおよびハードウェア・アクセラレータ用のルックアップ・テー
ブル（LUT）などのタスクの範囲のためのメモリを使用します。
ユーザーのシステムのメモリ要件は、システム上で実行する予定のアプリケーショ
ンの性質に大きく依存しています。メモリの性能と容量の要件は、シンプルで低コ
ストのシステムのために小さいです。これとは対照的に、メモリ・スループットは
複雑で高性能なシステムの中で最も重要な要件とすることができます。次のメモリ
の一般的なタイプは、エンベデッド・システムで使用することができます。
揮発性メモリ
メモリ・タイプの主な違いは、揮発性です。電源がメモリ・デバイスに適用されて
いる間に揮発性メモリだけその内容を保持します。電源が除去されるとすぐに、メ
モリがその内容を失います。その結果、メモリをオフにしたときのデータが保持さ
れなければならない場合、揮発性メモリは許容されません。揮発性メモリの例とし
ては、スタティック RAM（SRAM）、同期スタティック RAM（SSRAM）、同期ダイナ
ミック RAM（SDRAM）、および FPGA のオンチップ・メモリです。
不揮発性メモリ
電源をオフにしたときに、不揮発性メモリにはその内容を保持します。これによっ
て、システム・パワー・サイクル後に取得しなければならない情報を格納するため
に優れた選択肢となっています。プロセッサのブートコード、永続的なアプリケー
ション設定、および FPGA コンフィギュレーション・データは、典型的に不揮発性メ
モリに格納されています。不揮発性メモリは電源が除去されるときに、そのデータ
を保持するという利点がありますが、それは一般的に揮発性メモリより書き込みが
はるかに遅く、プロシージャに書き込みと消去手順をより複雑持っています。不揮
発性メモリは、通常、失敗する可能性があることで、何回の消去可能な与えられた
数になるように保証されています。不揮発性メモリの例としては、フラッシュ、
EPROM、EEPROM のすべての種類が含まれています。最近のほとんどのエンベデッ
ド・システムでは、不揮発性ストレージにフラッシュ・メモリのいくつかのタイプ
を使用します。
揮発性と不揮発性の両方の 2 メモリ・タイプはユニークかつ排他的な目的を果たす
ため、多くの組込みアプリケーションでは、両方のメモリを必要とします。以下の
セクションでは、エンベデッド・システムにおけるメモリの特定タイプの使用につ
いて説明します。
© 2010 年 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, HARDCOPY, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and
logos are trademarks of Altera Corporation and registered in the U.S. Patent and Trademark Office and in other countries. All other words and logos identified as
trademarks or service marks are the property of their respective holders as described at www.altera.com/common/legal.html. Altera warrants performance of its
semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to any products and
services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any information, product, or service
described herein except as expressly agreed to in writing by Altera. Altera customers are advised to obtain the latest version of device specifications before relying
on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
エンベデッド・デザイン・ハンドブック
2010 年 2 月
Feedback Subscribe
7‒2
第 7 章： メモリ・システム・デザイン
オンチップ・メモリ
オンチップ・メモリ
オンチップ・メモリは、FPGA ベースのエンベデッド・システムで使用するためのメ
モリの最も単純なタイプです。メモリは FPGA 自体に実装されます。その結果、外部
接続は回路基板上の必要はありません。デザイン内のオンチップ・メモリを実装す
るには、単純に SOPC Builder の System Contents タブで Component Library から On-Chip
Memory を選択します。次に、サイズ、幅、およびデュアル・ポート・アクセスなど
の特殊なオンチップ・メモリ機能とするオンチップ・メモリのタイプを指定するこ
とができます。
f On-Chip Memory SOPC Builder コンポーネントについて詳しくは、Quartus II ハンドブッ
クの Volume 4: SOPC Builder の 「SOPC Builder Memory Subsystem Development
Walkthrough」の章を参照してください。
利点
オンチップ・メモリは、最高のスループットであり、FPGA ベースのエンベデッド・
システムで可能な限り最低レイテンシのメモリです。それは通常、1 クロック・サイ
クルのレイテンシがあります。メモリ・トランザクションはパイプライン化される
ことができます。また、通常の 1 クロック・サイクルごとに 1 トランザクションの
スループットを作成します。
オンチップ・メモリのいくつかのバリエーションは、リードとライトのトランザク
ション用に別のポートを備えたデュアル・ポート・モードでアクセスすることがで
きます。デュアル・ポート・モードでは、メモリは同時に第 2 のポートを介して読
み出されている間に第 1 ポートを介して書き込むことができるように、効果的にメ
モリの潜在的な帯域幅を倍増します。
もう 1 つの利点は、オンチップ・メモリが直接 FPGA に実装されているので、追加の
ボード・スペースまたは回路基板の配線を必要としないことです。メモリ・チップ
上で使用すると、常に開発時間とコストを節約することができます。
最後に、オンチップ・メモリのいくつかのバリエーションが自動的に FPGA のコン
フィギュレーション中にカスタム内容を使用して初期化することができます。この
メモリは、リセット時に存在する必要があるブート・コードまたは LUT データの小
さなビットを保持するのに便利です。
f FPGA コンフィギュレーション時に初期化できるオンチップ・メモリの種類について
詳しくは、Quartus II ハンドブックの Volume 4:SOPC Builder の 「SOPC Builder Memory
Subsystem Development Walkthrough」の章を参照してください。
欠点
オンチップ・メモリは非常に高速である場合、それは多少容量に制限されています。
FPGA 上の使用可能なオンチップ・メモリの量は、単独で使用されている特定の
FPGA デバイスに依存しますが、容量が最小の Cyclone II デバイスの約 15 K バイトか
ら最大の Stratix III デバイスの 2 M バイトまでの範囲です。
ほとんどのオンチップ・メモリは揮発性であるため、電源が切断された時に内容が
消えます。しかし、FPGA がコンフィギュレーションされる場合、オンチップ・メモ
リのいくつかの種類によって自動的に初期化することができます。そして、本質的
に非揮発性関数の種類を提供します。詳細は、特定の使用している FPGA ファミリ用
のデバイス・ハンドブックのエンベデッド・メモリの章または Quartus® II Help を参
照してください。
エンベデッド・デザイン・ハンドブック
2010 年 2 月
Altera Corporation
第 7 章： メモリ・システム・デザイン
オンチップ・メモリ
7‒3
ベスト・アプリケーション
以下のセクションでは、オンチップ・メモリの最適な使用方法を説明します。
キャッシュ
ロー・レイテンシのため、オンチップ・メモリはマイクロプロセッサ用のキャッ
シュ・メモリとして非常によく機能します。Nios II プロセッサは、命令キャッシュ
とデータ · キャッシュ用にオンチップ・メモリを使用します。キャッシュは一般的に
比較的小さいので、オンチップ・メモリの限られた容量は通常に問題ではありませ
ん。
密結合メモリ
オンチップ・メモリのロー・レイテンシ・アクセスも密結合メモリ用に適していま
す。密結合メモリは通常のアドレス・スペースにマッピングされているメモリであ
るが、マイクロプロセッサに専用のインタフェースを持っており、キャッシュ・メ
モリの高速、ロー・レイテンシ特性を持っています。
f 密結合メモリについて詳しくは、「Using Tightly Coupled Memory with the Nios II
Processor Tutorial」を参照してください。
ルック・アップ・テーブル
特に数学関数のいくつかのソフトウェアのプログラミング関数に対しては、ソフト
ウェアで関数を計算することよりも、関数のすべての可能な結果を格納するために
LUT を使用することが最速です。オンチップ・メモリは、可能な結果の数が使用可
能なオンチップ・メモリの容量に対して適度にフィットする限り、この目的が良好
に機能します。
FIFO
常にエンベデッド・システムは、1 つのシステム・ブロックから別のシステム・ブ
ロックまでデータのフローを調節する必要があります。FIFO は異なる速度で最も効率
的に実行する処理ブロックの間でデータをバッファリングすることができます。ア
プリケーションが必要とする FIFO のサイズに応じてオンチップ・メモリが非常に迅
速かつ便利な FIFO ストレージとして機能することができます。
f FIFO バッファについて詳しくは、Quartus II ハンドブックの Volume 5: Embedded
Peripherals の 「On-Chip FIFO Memory Core」の章を参照してください。
悪いアプリケーション
オンチップ・メモリが大容量メモリーを必要とするアプリケーションに不十分に適
しています。オンチップ・メモリは比較的容量が限られているため、大量のデータ
を格納するために使用することは避けますが、いくつかのタスクは他のものよりも、
オンチップ・メモリのより良い活用することができます。アプリケーションが複数
の小さいデータ・ブロックに収まられ、すべてがオンチップ・メモリにフィットし
ない場合、オンチップ・メモリでどのブロックを実装するかを考慮する必要があり
ます。高いシステム性能が目標である場合は、オンチップ・メモリに最も頻繁にア
クセスされるデータを配置します。
2010 年 2 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
7‒4
第 7 章： メモリ・システム・デザイン
外部 SRAM
オンチップ・メモリのタイプ
使用している FPGA の種類に応じて、オンチップ・メモリのいくつかの種類が用意さ
れています。使用可能なオンチップ・メモリのさまざまな種類について詳しくは、
使用している特定の FPGA ファミリのデバイス・ハンドブックを参照してください。
ベスト・プラクティス
システムではオンチップ・メモリの使用を最適化するには、次のガイドラインに従
います。
■
一次システム・マスタのデータ幅と一致するように、オンチップ・メモリ・デー
タ幅を設定します。例えば、Nios II プロセッサのデータ・マスタにオンチップ・
メモリを接続している場合、Nios II データ・マスタのデータ幅と同様に、オン
チップ・メモリのデータ幅を 32 ビットに設定する必要があります。それ以外の
場合は、システム・インタコネクト・ファブリックが幅の変換を実行するため、
アクセス・レイテンシは 1 サイクルよりも長くなる可能性があります。
■
複数のマスタがオンチップ・メモリ・コンポーネントに接続している場合、オン
チップ・メモリのデュアルポート機能をイネーブルすることを検討します。デュ
アルポートの機能は、2 つのマスタが同じオンチップ・メモリにアクセスすると
きに、アービトレーション・ロジックの必要性を取り除きます。また、デュアル
ポート・メモリは、メモリが 2 つ以上のマスタによってアクセスされたときに劇
的に効率性とパフォーマンスを向上させることができ、両方のポートからの同時
アクセスを可能にします。しかし、マスタとの間で慎重な調整がない場合、RAM
の両方のスレーブ・ポートへの書き込みはデータが破損する可能性があります。
FPGA ロジックとメモリの使用率を最小限に抑えるために、次のガイドラインに従い
ます。
■
アプリケーション用のオンチップ・メモリの最適なタイプを選択します。いくつ
かの種類は大容量であり、他の種類はより広いデータ幅をサポートしています。
適切な FPGA ファミリのデバイス・ハンドブックのエンベデッド・メモリ・セク
ションには、オンチップ・メモリの機能について説明します。
■
2 バイトの累乗であるオンチップ・メモリ・サイズを選択します。2 の累乗でない
サイズの実装メモリは、非効率的なメモリとロジックの使用になる可能性があり
ます。
外部 SRAM
「外部 SRAM」は、FPGA の外部に接続する任意のスタティック RAM（SRAM）デバイ
スを示します。外部 SRAM デバイスのいくつかの品種があります。外部 SRAM とそ
のタイプの選択は、アプリケーションの性質によって異なります。SRAM メモリを使
用してデザインすることで利点と欠点の両方を提示します。
利点
外部 SRAM デバイスは、オンチップ・メモリよりも大きなストレージ容量を提供し、
オンチップ・メモリの高速ではないものとしても速度がかなり速いです。典型的な
外部 SRAM デバイスは、約 128 K バイトから 10 M バイトまでの容量を持っています。
特殊 SRAM デバイスは、さらに小さい容量と大容量で見つけることができます。
SRAM は典型的には、共有、双方向バスを介して FPGA に接続するため、オンチッ
エンベデッド・デザイン・ハンドブック
2010 年 2 月
Altera Corporation
第 7 章： メモリ・システム・デザイン
外部 SRAM
7‒5
プ・メモリよりも遅く、非常にロー・レイテンシと高スループットのデバイスです。
SRAM インタフェースは、FPGA シンプルなデザイン・タスクから SRAM に接続する
こと、非常にシンプルです。また、他の外部 SRAM デバイスと、あるいはそのよう
なフラッシュまたは SDRAM のような他の種類の外部メモリと外部 SRAM バスを共有
することができます。
f 共用外部バスについて詳しくは、Quartus II ハンドブックの Volume 4: SOPC Builder の
「SOPC Builder Memory Subsystem Development Walkthrough」の章を参照してください。
欠点
FPGA ベースのエンベデッド・システムの外部 SRAM の主な欠点は、コストとボード
面積です。SRAM デバイスは SDRAM などの他の高容量メモリ・タイプより M バイト
あたりより高価です。また、none を消費する SDRAM と FPGA オンチップ・メモリの
両方よりも M バイトあたりのボード・スペースを消費します。
ベスト・アプリケーション
外部 SRAM はデータの中規模のブロックに対して高速バッファとして非常に効果的
です。ユーザーは、オンチップ・メモリに収まらないと、SDRAM が提供するものよ
りも低いレイテンシを必要とするデータをバッファリングするために外部 SRAM を
使用することができます。また、容量を向上させるために複数の SRAM メモリをグ
ループ化することができます。
SRAM はランダム・データへのアクセスに最適です。多くの SRAM デバイスは、連続
したアドレスのロー・レイテンシと同じで（SDRAM のパフォーマンスが低下する領
域）、連続したアドレスにあるデータにアクセスすることができます。SRAM は、例
えば、オンチップ・モリに収まらない大きさの色変換アルゴリズム用のデータを保
持している大規模な LUT に対して理想的なメモリ・タイプです。
ノー・キャッシュを持つプロセッサのための実行用メモリとして使用した場合、外
部 SRAM は比較的よく実行されます。プロセッサがメモリの他のタイプの高いレイ
テンシをマスクするためにキャッシュを持っていない場合、外部 SRAM のロー・レ
イテンシ・プロパティはプロセッサのパフォーマンスを向上させます。
悪いアプリケーション
外部 SRAM の悪い用途はコスト重視のストレージとステムを大量に必要とするシス
テムがあります。ユーザーのシステムが 10 M バイトより大きいメモリ・ブロックが
必要な場合、安価の SDRAM などのメモリの異なるタイプを討する必要があります。
外部 SRAM タイプ
SRAM デバイスのいくつかの種類があります。以下の種類が最も普及しています。
2010 年 2 月
■
非同期 SRAM— それはクロックに依存しないため、これは SRAM の最も遅いタイプ
です。
■
同期 SRAM (SSRAM)— 同期 SRAM はクロックに同期して動作します。これは、非同
期 SRAM より高速だけでなく、より高価です。
■
擬似 SRAM— 擬似 SRAM（PSRAM）は SSRAM インタフェースを持つダイナミック
RAM（DRAM）のタイプです。
Altera Corporation
エンベデッド・デザイン・ハンドブック
7‒6
第 7 章： メモリ・システム・デザイン
フラッシュ・メモリ
■
ZBT SRAM—ZBT（ゼロ・バス・ターンアラウンド）SRAM は、ゼロ・ターンアラ
ウンド・サイクルでリード・トランザクションからライト・トランザクションに
切り替えることができ、非常にロー・レイテンシになります。通常、ZBT SRAM は
ロー・レイテンシ機能を利用するための特殊なコントローラを必要とします。
ベスト・プラクティス
外部 SRAM デバイスから最高のパフォーマンスを得るには、次のガイドラインに従
います。
■
メモリにアクセスする一次システム・マスタのデータ幅と同じデータ幅を持つ
SRAM インタフェースを使用します。
■
ピンの使用率やボード面積はシステムのパフォーマンスより大きい問題になる場
合、FPGA のピン数とおそらく PCB 上のメモリ・デバイス数を減らすために、マ
スタのデータ幅よりも小さいデータ幅の SRAM デバイスを使用することができま
す。しかし、これにより、SRAM インタフェースのパフォーマンスを低下させま
す。
フラッシュ・メモリ
フラッシュ・メモリは、エンベデッド・システムで頻繁に使用される不揮発性メモ
リの一種です。FPGA ベースのエンベデッド・システムでは、FPGA はフラッシュ・メ
モリが含まれていないため、フラッシュ・メモリは常に外部にあります。電源が除
去された後にフラッシュ・メモリの内容は保持されているので、電源障害が発生し
た場合に保存される必要がある任意のデータと同様に、それは一般的にマイクロプ
ロセッサのブート・コードを保持するために使用されています。フラッシュ・メモ
リは、パラレルまたはシリアル・インタフェースのいずれかを用意しています。パ
ラレルおよびシリアル・フラッシュ・デバイス用の基礎的なトレージ技術は同じで
す。
SRAM とは異なり、フラッシュ・メモリは、単純なライト・トランザクションで更新
することはできません。フラッシュ・デバイスへのすべてのライトは、連続したラ
イトとリード・ランザクションの一定の配列からなるライト・コマンドを使用して
います。フラッシュ・メモリを書き込むことができる前に、それを消去する必要が
あります。すべてのフラッシュ・デバイスは、フラッシュ・ベンダとデバイスのサ
イズに応じて、サイズが異なる消去ブロック、またはセクタのいくつかに分割され
ています。フラッシュのセクション全体を単位として消去されなければなりません；
個々の単語は消去できません。これらの要件は、時々フラッシュ・デバイスの使用
が困難になります。
利点
フラッシュ・メモリの主な利点は、非揮発性であるということです。現代のエンベ
デッド・システムは、ブート・コードと設定だけでなく、オーディオやビデオ・ス
トリームなどのデータの大きなブロック保存するために広範囲にフラッシュ・メモ
リを使用します。多くのエンベデッド・システムでは、ハード・ドライブのための
低消費電力、高信頼性の代用としてフラッシュ・メモリを使用します。
メモリの他の不揮発性タイプのうち、フラッシュ・メモリには、以下の 4 つの理由
で最も人気です。
■
耐久性があります。
エンベデッド・デザイン・ハンドブック
2010 年 2 月
Altera Corporation
第 7 章： メモリ・システム・デザイン
フラッシュ・メモリ
■
消去可能です。
■
消去サイクルの多数を可能にします。
■
低コストです。
7‒7
他のフラッシュ・デバイス、あるいは外部 SRAM または SDRAM のような外部メモリ
とフラッシュ・スを共有することができます。
f 共用外部バスについて詳しくは、Quartus II ハンドブックの Volume 4: SOPC Builder の
「SOPC Builder Memory Subsystem Development Walkthrough」の章を参照してください。
欠点
フラッシュの主な欠点は、そのライト速度です。別なコマンドを使用してフラッ
シュ・バイスに書き込むことができるので、複数のバス・トランザクションは各フ
ラッシュ・ライトが必要になります。さらに、実際のライト時間は、ライト・コマ
ンドが送信された後、数マイクロ秒とすることができます。クロック速度に応じて、
実際のライト時間はクロック・サイクルの数百にすることができます。セクタ消去
の制限のため、フラッシュ内のデータ・ワードを変更する必要がある場合、次の手
順を完了する必要があります。
1. 一時バッファにセクタの内容全体をコピーします。
2. セクタを消去します。
3. 一時バッファ内の単一のデータ・ワードを変更します。
4. フラッシュ・メモリ・デバイスに一時的なバッファを書き戻します。
この手順では、フラッシュ・メモリ・デバイスの不適切なライト速度に貢献してい
ます。不適切なライト速度により、フラッシュ・メモリは通常、電源を切った後保
存しなければならないデータを格納するためにのみ使用されます。
一般的なアプリケーション
フラッシュ・メモリは、電源がシステムから削除された場合、保存する任意のデー
タを格納するために効果的です。フラッシュ・メモリの一般的な用途は、次のタイ
プのデータのストレージが含まれています。
2010 年 2 月
■
マイクロプロセッサのブート・コード
■
システムの起動時に RAM にコピーされるマイクロプロセッサ・アプリケーショ
ン・コード
■
次のタイプを含む永続的なシステム設定
■
ネットワークの MAC アドレス
■
キャリブレーション・データ
■
ユーザー・プリファレンス
■
FPGA のコンフィギュレーション・イメージ
■
メディア（オーディオ、ビデオ）
Altera Corporation
エンベデッド・デザイン・ハンドブック
7‒8
第 7 章： メモリ・システム・デザイン
フラッシュ・メモリ
悪いアプリケーション
フラッシュ・メモリのライト速度が遅いため、パワーオフ後に保持する必要がない
ものに使用する必要はありません。揮発性メモリはオプションである場合、SRAM は
はるかに良い代替手段です。フラッシュ・メモリを使用するシステムでは、通常、
いくつかの SRAM が含まれています。
フラッシュの 1 つの特定の不適切な使用は、マイクロプロセッサ・アプリケーショ
ン・コードを直接実行することです。コードの書き込み可能セクションのいずれか
がフラッシュ・メモリに配置されている場合、フラッシュ・メモリがその特殊なラ
イト・コマンドを使用せずに書き込むことができないため、このソフトウェアは単
に動作しません。フラッシュ・メモリ内のシステムを格納するアプリケーション・
コードは、通常、それを実行する前に、SRAM にアプリケーションをコピーします。
フラッシュ・タイプ
フラッシュ・デバイスのいくつかの種類があります。以下の種類が最も普及してい
ます。
■
CFI フラッシュ – これは、フラッシュ・メモリの最も一般的なタイプです。これは
パラレル・インタフェースを持っています。CFI は、すべての CFI フラッシュ・デ
バイスが付着するための標準のコモン・フラッシュ・インタフェースを表しま
す。SOPC Builder と Nios II プロセッサは、CFI フラッシュ用のビルトイン・サポー
トがあります。
f 詳細は、Quartus II ハンドブックの Volume 5: Embedded Peripherals の
「Common Flash Interface Controller Core」の章および「Nios II Flash Programmer
User Guide」参照してください。
■
シリアル・フラッシュ – このフラッシュは、デバイス・ピンおよびボード・ス
ペースを維持するためにシリアル・インタフェースを備えています。多くのシリ
アル・フラッシュ・デバイスは独自の特定のインタフェース・プロトコルを持っ
ているので、徹底的にシリアル・フラッシュ・デバイスのデータシートを選択す
る前に、それを読むのがベストです。アルテラ EPCS コンフィギュレーション・
デバイスは、シリアル・フラッシュの一種です。
f EPCS コンフィギュレーション・デバイスについて詳しくは、アルテラのコ
ンフィギュレーション・ハンドブックの Volume 2 の 「FPGA コンフィギュ
レーション・デバイス 」のセクションを参照してください。
■
NAND フラッシュ – NAND フラッシュは、デバイスごとに複数の G バイトにまで、
非常に高い能力を達成することができます。NAND フラッシュへのインタフェー
スは、CFI フラッシュのそれよりも少し複雑です。それは特別なコントローラや
インテリジェントな低レベルのドライバ・ソフトウェアのいずれかが必要です。
ユーザーはアルテラの FPGA を使用した NAND フラッシュを使用することもでき
ますが、アルテラは、任意のビルトイン・サポートを提供していません。
エンベデッド・デザイン・ハンドブック
2010 年 2 月
Altera Corporation
第 7 章： メモリ・システム・デザイン
SDRAM
7‒9
SDRAM
SDRAM は揮発性メモリの別のタイプです。それは動的であり、その内容を維持する
ために定期的にリフレッシュしなければならないことを除いて、SRAM と同様です。
SDRAM でのダイナミック・メモリ・セルは、SRAM で使用される静的メモリ・セル
よりも小さいです。サイズのこの差は、非常に大容量で低コストのメモリデバイス
に変換します。
リフレッシュの要件に加え、SDRAM は、通常、特別なコントローラ・ハードウェア
の使用を必要とする他の特定のインタフェース要件があります。アドレス・ライン
の静的なセットを持っている SRAM と異なり、SDRAM はバンク、ロウ、およびカラ
ムにそのメモリ・スペースを分割します。バンクとロウの間の切り替えは、SDRAM
の効率的な使用がアクセスの順序を慎重に含まれるように、いくつかのオーバー
ヘッドが発生します。また、SDRAM には、SDRAM の与えられたサイズを実装するた
めに、必要なピン・カウントを低減する同じアドレス・ライン上のロウとカラムの
アドレスを多重化します。DDR、DDR2、および DDR3 などの SDRAM の高速品種は、
PCB のデザイン時に検討する必要がある厳格なシグナル・インテグリティ要件があ
ります。
SDRAM デバイスは、利用可能な RAM のデバイスの中で最も安価かつ最大容量タイ
プの一つであり、最も人気の一つとなります。最近のほとんどのエンベデッド・シ
ステムは、SDRAM を使用しています。SDRAM インタフェースの大部分は SDRAM コ
ントローラです。SDRAM コントローラは、システムの残りの部分はその内部のアー
キテクチャの知識がなくても、SDRAM にアクセスできるように、すべてのアドレス
多重化、リフレッシュ、ロウとバンク切り替えのタスクを管理します。
f アルテラの FPGA で使用可能な SDRAM コントローラについて詳しくは、外部メモリ・
インタフェース・ハンドブックの Volume 3 の 「DDR and DDR2 SDRAM HighPerformance Controllers and ALTMEMPHY IP User Guide」のセクションおよび 「DDR3
SDRAM High-Performance Controller and ALTMEMPHY IP User Guide のセクションを参照し
てください。
利点
SDRAM の最も重要な利点は、容量とコストです。RAM がそれ以外のタイプは、
SDRAM の低コストと大容量を組み合わせて、非常に人気のある選択肢となります。
また、SDRAM には、ピンを効率的に使用できます。ロウとカラムのアドレスが同じ
アドレス・ピン上で多重化されているので、与えられたメモリの容量を実装するた
めに少ないピンが必要です。最後に、SDRAM は、一般的に同等の SRAM デバイスよ
りも消費電力が少ないです。
また、いくつかのケースでは、複数の SDRAM デバイス、あるいはそのような外部
SRAM やフラッシュ・メモリなどの他の種類の外部メモリとの間で、SDRAM のバス
を共有することができます。
f 共用外部バスについて詳しくは、Quartus II ハンドブックの Volume 4: SOPC Builder の
「SOPC Builder Memory Subsystem Development Walkthrough」の章を参照してください。
2010 年 2 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
7‒10
第 7 章： メモリ・システム・デザイン
SDRAM
欠点
SDRAM の高容量と低コストに加えて、付加的な複雑さとレイテンシがあります。
SDRAM インタフェースの複雑さは、常に SDRAM のリフレッシュ・サイクル、アド
レス多重化、およびインタフェースのタイミングを管理するために、SDRAM コント
ローラを使用する必要があります。このようなコントローラは、通常、他のロジッ
クで利用できるようになるの FPGA ロジック・エレメントを消費します。
SDRAM は、アクセス・レイテンシのかなりの量の欠点があります。ほとんどの
SDRAM コントローラは、レイテンシを最小限にするための措置を講じますが、
SDRAM のレイテンシは常に定期的な外部の SRAM または FPGA のオンチップ・メモ
リに比べて大きいです。しかし、最初のアクセス・レイテンシが High の間に、連続
してアクセスがパイプライン化することができるので、初期アクセス・レイテンシ
が克服された後、SDRAM のスループットは実際には非常に高くなることがありま
す。SDRAM の種類によっては、さらにスループットを向上させ、SRAM より高いク
ロック周波数を達成することができます。また、SDRAM インタフェース仕様では、
全体のスループットを向上させるためにバースト機能を採用しています。
ベスト・アプリケーション
SDRAM は、次のような状況では一般的に良い選択です。
■
データの大きなブロックを格納 —SDRAM の大容量は、そのようなネットワーク・
パケット、ビデオ・フレーム・バッファ、およびオーディオ・データなどのデー
タの大きなブロックをバッファリングするための最善の選択肢となります。
■
マイクロプロセッサ・コードを実行 —SDRAM は、一般的に、実行中のプログラム
が大きい場合は特に、マイクロプロセッサ・ソフトウェア用の命令とデータを格
納するために使用されています。命令とデータ・キャッシュは、大規模なプログ
ラムのパフォーマンスを向上させます。使用するシステム・トポグラフィや
SDRAM コントローラに応じて、キャッシュ・ライン・フィルの代表的なシーケ
ンシャル・リード・パターンが潜在的に SDRAM のパイプラインおよびバースト
機能を利用することができます。
悪いアプリケーション
SDRAM は、次のような状況で最善の選択ではない場合があります。
■
ロー・レイテンシのメモリ・アクセスが必要となったとき — 高スループットが
SDRAM を使用しても可能ですが、その最初のアクセス・レイテンシが非常に高
いです。データの特定のブロックへのロー・レイテンシのアクセスがアプリケー
ションの要件である場合、SDRAM は、おそらくそのデータのブロックを格納す
るための良い選択ではありません。
■
データの小さなブロック — ストレージの少量が必要になったとき、
SDRAM は不要
場合があります。オンチップ・メモリは、PCB に別のメモリ・デバイスを追加す
ることなく、ユーザーのメモリ要件を満たすことができる場合があります。
■
小型でシンプルなエンベデッド・システム — ユーザーのシステムは、ロジック・
リソースが不足していると、アプリケーションは SDRAM が提供する容量を必要
としないで小型の FPGA を使用している場合、SDRAM コントローラに FPGA のロ
ジック・エレメントを捧げるのではなく、小型の外部 SRAM またはオンチップ・
メモリを使用します。
エンベデッド・デザイン・ハンドブック
2010 年 2 月
Altera Corporation
第 7 章： メモリ・システム・デザイン
SDRAM
7‒11
SDRAM タイプ
SDRAM デバイスのいくつかの種類があります。次のタイプが最も一般的です。
■
SDR SDRAM— シングル・データ・レート（SDR）SDRAM は、SDRAM の元の型で
す。これは、新しい、ダブル・データ・レート（DDR）型と区別するために、
SDRAM または SDR SDRAM と呼ばれています。「シングル・データ・レート」の
名前は、最大の 1 ワードのデータがクロック・サイクルごとに転送できるという
事実を指します。DDR SDRAM の新しいタイプは、より一般的になってきている
ものの、SDR SDRAM は、まだ広く使用しています。
■
DDR SDRAM— ダブル・データ・レート（DDR）SDRAM はクロックの立ち上がり
エッジと立ち下がりエッジの両方でデータ・ワードを転送することにより、高い
データ・スループットをサポートする SDRAM の新しいタイプです。DDR SDRAM
は 2.5 V SSTL シグナリングを使用しています。DDR SDRAM の使用は、カスタム・
メモリ・コントローラが必要です。
■
DDR2 SDRAM—DDR2 SDRAM は、このような低消費電力 1.8 V SSTL シグナリングお
よびオンチップ信号終端としてわずかに改善インタフェース要件を実装すること
により、DDR の成功に基づいて標準の DDR SDRAM メモリの新しいバリエーショ
ンです。
■
DDR3 SDRAM—DDR3 は、シグナル・インテグリティを向上させ、クロック周波数
を増加させることによって、さらにメモリの潜在的な帯域幅を向上させる、DDR
SDRAM の別の変形例です。
アルテラからの使用可能な SDRAM コントローラのタイプ
表 7–1 に、アルテラが提供する SDRAM コントローラを示します。これらの SDRAM
コントローラは、ライセンスなしで使用できます。
表 7‒1. アルテラからの使用可能なメモリ・コントローラ ( その １ )
コントローラ名
SDR SDRAM コントローラ
説明
このコントローラは、アルテラがオファーする SDR SDRAM コントローラの
みです。それは、最も利用可能な SDR SDRAM デバイスで機能し、シンプル
で使いやすいコントローラです。
詳細は、Quartus II ハンドブックの Volume 5: Embedded Peripherals の 「SDRAM
Controller Core」の章を参照してください。
DDR/DDR2 コントローラ
Megacore ファンクション
2010 年 2 月
Altera Corporation
このコントローラは、既存のデザインのために維持されているレガシー・コ
ンポーネントです。アルテラは、新規設計用にそれを推奨しません。
エンベデッド・デザイン・ハンドブック
7‒12
第 7 章： メモリ・システム・デザイン
SDRAM
表 7‒1. アルテラからの使用可能なメモリ・コントローラ ( その ２ )
コントローラ名
説明
このコントローラは、アルテラが新規設計用に推奨されている DDR/DDR2 コ
ントローラです。それはフル・レートおよびハーフ・レートの 2 つの主要な
クロッキング・モードをサポートします。
高性能 DDR/DDR2 コントロー
ラ
■
フル・レート・モードでは、SOPC Builder システムに対して実際の DDR
SDRAM デバイスの 2 倍の幅で、フル SDRAM クロック・レートでデータを
供給します。
■
ハーフ・レート・モードでは、SOPC Builder システムに対してハーフ
SDRAM クロック・レートのネイティブ SDRAM デバイスの 4 倍のデータ幅
でデータを供給します。
このコントローラについて詳しくは、「DDR and DDR2 SDRAM
High-Performance Controllers and ALTMEMPHY IP User Guide」を参照してくださ
い。
高性能 DDR3 コントローラ
このコントローラは、アルテラが新規設計用に推奨されているの DDR3 コン
トローラです。それは高性能 DDR/DDR2 コントローラに似ています。また、
フルとハーフ・レートのクロッキング・モードをサポートします。
このコントローラについて詳しくは、「DDR3 SDRAM High-Performance
Controller and ALTMEMPHY IP User Guide」を参照してください。
ベスト・プラクティス
高性能 DDR または DDR2 SDRAM コントローラを使用する時には、フル・レートまた
はハーフ・レートのクロック・モードでは、アプリケーションに最適であるかどう
かを判断することが重要です。
ハーフ・レート・モード
ハーフ・レート・モードでは、可能な最高の SDRAM クロック周波数が必要な場合、
またはシステム・ロジックの複雑さ（DDR SDRAM に必要なクロック周波数を達成す
ることができないことを意味する）が必要な場合には最適です。ハーフ・レート・
モードでは、SDRAM コントローラへの内部 Avalon インタフェースは外部 SDRAM の
周波数の半分で動作します。
ハーフ・レート・モードでは、SDRAM コントローラのローカル・データ幅
（SOPC Builder システム内部のデータ幅）はフィジカル DDR SDRAM デバイスの 4 倍の
データ幅です。例えば、ユーザーの SDRAM デバイスは 8 ビット幅である場合、
SDRAM コントローラの内部 Avalon データ・ポートは 32 ビットになります。このデ
ザイン上の選択は、SDRAM デバイスへの 4 つのアクセスのバーストを容易にしま
す。
フール・レート・モード
フル・レート・モードでは、SDRAM コントローラへの内部 Avalon インタフェース
は、完全な外部の DDR SDRAM のクロック周波数で動作します。ユーザーのシステ
ム・ロジックは簡単に DDR SDRAM のクロック周波数を達成できる時、または
SDRAM インタフェースのクロック・レートの半分でシステム・ロジックを実行する
と、ユーザーの要件については遅すぎる場合、フル・レート・モードを使用します。
エンベデッド・デザイン・ハンドブック
2010 年 2 月
Altera Corporation
第 7 章： メモリ・システム・デザイン
SDRAM
7‒13
フル・レート・モードを使用する場合、SDRAM コントローラのローカル・データ幅
はフィジカル DDR SDRAM の 2 倍のデータ幅です。例えば、ユーザーの SDRAM デバ
イスは 16 ビット幅である場合、フル・レート・モードの SDRAM コントローラの内
部 Avalon データ・ポートは 32 ビット幅になります。また、この選択は SDRAM デバ
イスへのバーストを容易にします。
シーケンシャル・アクセス
SDRAM のパフォーマンスはシーケンシャル・アクセスから利益を得ます。アクセス
は連続していると、データが連続したアドレスから読み書き、それがバーストを使
用してスループットを高めることができます。また、SDRAM コントローラはロウと
バンク切り替えを減らすためのアクセスを最適化することができます。各ロウまた
はバンクの変化が増加のスループットをスイッチング削減できるように、遅延が発
生します。
バースト
SDRAM デバイスはスループットを向上させるためにバーストを採用します。バース
トの連続したアドレスへのグループのトランザクション数を、データが個々のトラ
ンザクションのための要求のオーバーヘッドを発生させずにバック・ツー・バック
転送することができます。高性能 DDR/DDR2 SDRAM コントローラを使用する場合、
システム・インタコネクト・ファブリックでバーストを活用することができる場合
があります。バーストは、トランザクションに関与してマスタとスレーブの両方が
バースト・イネーブルである場合にのみ有用です。バーストがサポートされている
かどうかを確認するための質問でマスタするマニュアルを参照してください。
高性能 DDR/DDR2 SDRAM コントローラのバースト・サイズを選択すると、コント
ローラを使用しているモードによって異なります。ハーフ・レート・モードでは、
Avalon データ・ポートは、実際の SDRAM デバイスの幅の 4 倍です。その結果、4 つ
のトランザクションは、システム・インタコネクト・ファブリック内の各シングル
転送のために SDRAM デバイスに開始されます。4 のバースト・サイズは、SDRAM へ
のそれらの 4 つのトランザクションに使用されます。これは、高性能 DDR/DDR2
SDRAM コントローラでサポートされているバーストの最大サイズです。その結果、
システム・インタコネクト・ファブリックはすでにそれぞれの単一のトランザク
ションを実行するためにサポートされる最大バースト・サイズが使用されているた
め、ハーフ・レート・モードで高性能 DDR/DDR2 SDRAM コントローラのバーストを
使用すると、パフォーマンスが向上することはありません。
しかし、フル・レート・モードでは、高性能 DDR/DDR2 SDRAM コントローラと 2 の
バースト・サイズを使用することができます。フル・レート・モードでは、サポー
トされる最大 4 つの SDRAM コントローラのバースト・サイズに到達する前に、2 の
Avalon トランザクションはバーストで組み合わせることができるように、各 Avalon
のトランザクションは 2 つの SDRAM デバイスのトランザクションになります。
SDRAM の最小周波数
多くの SDRAM デバイス、特に、DDR、DDR2、および DDR3 デバイスは、クロック周
波数の最小要件があります。最小クロック・レートは、特定の SDRAM デバイスに依
存します。デバイスの最小クロック周波数を見つけるために使用している SDRAM デ
バイスのデータシートを参照してください。
2010 年 2 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
7‒14
第 7 章： メモリ・システム・デザイン
メモリの最適化
SDRAM のデバイス・スピード
SDR と DDR の SDRAM デバイスの両方には、いくつかのスピード・グレードで発生
します。FPGA と SDRAM を使用する場合は、FPGA システムの動作周波数は、通常、
SDRAM デバイスの最大能力より低いです。したがって、それは一般的に速いスピー
ド・グレードの SDRAM デバイスを使用するために余分な費用価値はありません。特
定 SDRAM デバイスにコミットする前に、システムの予想される SDRAM の周波数、
および特定の SDRAM デバイスの最大値と最小動作周波数の両方を検討します。
メモリの最適化
このセクションでは、SOPC Builder システムに任意のタイプのメモリを実装する際
に、役立つことができるヒントとトリックを提示します。これらの手法は、システ
ムのパフォーマンスと効率性を向上させることができます。
重要なメモリ接続の分離
多くのシステムでは、特に複雑なものについては、パフォーマンスが重要なメモリ
接続の分離が有益です。メモリからの最大スループットの可能性を達成するために、
可能性のあるマスタの最も少ない数に接続し、可能性のあるスレーブの最も少ない
数とそれらのマスタを共有します。接続を最小化すると、必要なデータ・マルチプ
レクサのサイズを縮小し、潜在的なクロック速度を増加させ、そして、メモリにア
クセスするのに必要なアービトレーションの量を減らします。
f メモリの接続を分離するためにブリッジを使用することができます。効率的なシス
テム・トポロジーについて詳しくは、次のドキュメントを参照してください。
■
■
Quartus II ハンドブックの Volume 4: SOPC Builder の「Avalon Memory-Mapped Bridges」
の章。
エンベデッド・デザイン・ハンドブックの「Avalon Memory-Mapped Design
Optimizations」の章。
マスタとスレーブのデータ幅と一致
SOPC Builder でマスタとスレーブのペアのデータ幅を一致させることは有利です。マ
スタ・ポートは異なるデータ幅のスレーブに接続されている場合は常に、SOPC
Builder はそれらの間で変換するアダプタ・ロジックを挿入します。このロジックは、
スループットが低下し、各トランザクションに追加のレイテンシを追加することが
できます。可能であれば、パフォーマンスが重要なマスタとスレーブの接続用に
データ幅の一貫性を保つようにします。マスタが複数のスレーブに接続されて、そ
してスレーブが複数のマスタに接続される場合では、すべてのマスタとスレーブの
接続は同じデータ幅を持つことは不可能場合があります。これらのケースでは、シ
ステムのパフォーマンスに最も影響を与えるマスタからスレーブへの接続に専念し
なければなりません。
例として、Nios II プロセッサのパフォーマンスはシステム全体のパフォーマンスに
重要であり、プロセッサが SDRAM デバイスからすべてのソフトウェアを実行するよ
うに設定されている場合は、Nios II プロセッサのネイティブ・データ幅であるため、
そして、それは最高のパフォーマンスを提供することができるので、32 ビット
SDRAM デバイスを使用する必要があります。狭いまたは広い SDRAM デバイスを使
エンベデッド・デザイン・ハンドブック
2010 年 2 月
Altera Corporation
第 7 章： メモリ・システム・デザイン
ケース・スタディ
7‒15
用すると、大きいレイテンシとスループット低下のため、プロセッサのパフォーマ
ンスに悪影響を与える可能性があります。しかし、SDRAM へのおよびからのデータ
を移動するための 64 ビット DMA を使用する場合、システム全体のパフォーマンス
は DMA のパフォーマンスにもっと依存する可能性があります。この場合、64 ビット
SDRAM インタフェースを実装することが有利です。
並列性を利用するために別々のメモリを使用
システムに複数のマスタが同じメモリにアクセスすると、各マスタは、時間の一部
だけにアクセスが許可されます。マスタがデータにスターブされる場合、共有アク
セス・システムのスループットを不正になる可能性があります。
各マスタのために別々のメモリ・インタフェースを作成する場合、それらは、メモ
リ帯域幅のボトルネックを除去し、フル・スピードで同時にメモリにアクセスでき
ます。別々のインタフェースは、DMA を使用するシステムで、または並列処理の可
能性が重要であるマルチプロセッサ・システムでは非常に便利です。
SOPC Builder では、それは別々のメモリ・ンタフェースを作成することは容易です。
単に 1 の代わりに、複数のオンチップ・メモリ・コンポーネントをインスタンス化
します。また、ボードに、おそらく小さい、メモリ・デバイスを複数追加し、
SOPC Builder で別々のインタフェースに接続することで、このような外部 SRAM や
SDRAM などの外部メモリ・デバイスでこのテクニックを使用することができます。
複数のメモリ・デバイスを追加すると、ボード面積、FPGA ピン、および FPGA ロ
ジック・リソース間のトレードオフを示しますが、確かにシステムのスループット
を向上させることができます。システム・トポロジーは、システム要件を反映する
必要があります。
f トポロジー・トレードオフについて詳しくは、エンベデッド・デザイン・ハンド
ブック 「Avalon Memory-Mapped Design Optimizations」の章を参照してください。
Nios II 命令のマスタ・アドレス · スペースを理解
この Nios II プロセッサの命令マスタはメモリの 256 M バイトのスパンよりも対処す
ることはできません。その結果、Nios II ソフトウェアを実行するために 256 M バイ
ト以上を提供すると、メモリ・リソースを浪費します。この制限は、多くの 2 ギガ
バイトなどに対処することができる Nios II データ・マスタには適用されません。
テスト・メモリ
ユーザーは、厳密にシステム内のメモリが実際のアプリケーションに頼る前に物理
的に接続され、正しく設定されていることを確認するには、そのメモリをテストす
る必要があります。Nios II エンベデッド・デザイン・スイートは、システムの徹底的
なメモリ・テストを構築するための良い出発点であるメモリ・テストの例が付属し
ています。
ケース・スタディ
このセクションでは、このドキュメントの前半で説明した概念を説明するためのビ
デオ処理アプリケーションにおけるメモリのパーティショニングの最適化について
説明します。
2010 年 2 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
7‒16
第 7 章： メモリ・システム・デザイン
ケース・スタディ
アプリケーションの説明
このビデオ処理アプリケーションは、ライン毎のビデオ・データのフル・フレーム
で動作するアルゴリズムを採用しています。アルゴリズムの他の詳細は、メモリ・
サブシステムのデザインに影響を与えません。データ・フローは、次の手順が含ま
れています。
1. 専用の DMA エンジンはバッファにビデオ・ソースからの入力データをコピーし
ます。
2. Nios II プロセッサは、ビデオ処理アルゴリズムを実行し、別のバッファに結果を
書き込み、そのバッファ上で動作します。
3. 第 2 の専用 DMA エンジンは、ビデオ出力デバイスにプロセッサの結果バッファ
からの出力をコピーします。
4. 2 つの DMA は、次の入力バッファに入力データをコピーし、以前の出力バッファ
から出力データをコピーし、同時にプロセッサが現在のバッファ処理しているこ
とで（一般的にピンポンと呼ばれる技術を呼ばれる）、並行性の要素を提供しま
す。
図 7–1 に、システムの基本アーキテクチャを示します。
図 7‒1. アプリケーション・アーキテクチャのサンプル
Input
Device
Input
DMA
System Interconnect Fabric
Buffer
ping pong
Buffer
Nios II
Nios II
Processor
CPU
Buffer
ping pong
Buffer
Output
DMA
Output
Device
エンベデッド・デザイン・ハンドブック
2010 年 2 月
Altera Corporation
第 7 章： メモリ・システム・デザイン
ケース・スタディ
7‒17
初期メモリ・パーティショニング
出発点として、アプリケーションは、一般的に使用されるメモリ・アーキテクチャ、
そのストレージおよびバッファリングのすべての SDRAM を使用します。入力 DMA
は、SDRAM の入力バッファにビデオ・ソースからのデータをコピーします。Nios II
プロセッサは、SDRAM の入力バッファから読み出し、データを処理し、そして、
SDRAM 内の出力バッファに結果を書き込みます。さらに、図 7–2 に示すように、プ
ロセッサは、命令とデータ・メモリの両方に SDRAM を使用しています。
図 7‒2. SDRAM に実装されたすべてのメモリ
Input
DMA
Input
Device
Nios II
Processor
Buffer
SDRAM
Instr
Cache
Nios II
CPU
Data
ping pong
Buffer
Instr Mem
Data Mem
Cache
Buffer
ping pong
Buffer
Output
DMA
Output
Device
機能的には、この実装には何も問題はありません。これは、エンベデッド・システ
ム・アーキテクチャの頻繁に使用される、伝統的なタイプです。また、それは 1 つ
の外部メモリ・デバイスを使用するため、比較的安価ですが、それは特に SDRAM の
その使用に関してやや非効率です。図 7–2 に示すように、データの異なる 6 つの
チャネルは、SDRAM にアクセスされます。
1. プロセッサの命令チャンネル
2. プロセッサのデータ・チャネル
3. DMA からの入力データ
4. プロセッサへの入力データ
5. プロセッサからの出力データ
6. DMA への出力データ
この多くのチャンネルが特にビデオ・アプリケーションに必要な高データ・レート
で、同時に SDRAM のうちに移動すると、SDRAM の帯域幅が容易にデザインで最も
重要なパフォーマンスのボトルネックになっています。
2010 年 2 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
7‒18
第 7 章： メモリ・システム・デザイン
ケース・スタディ
最適化されたメモリのパーティショニング
このデザインは、より効率的に動作するように最適化することができます。これら
の最適化は、以下のセクションで説明されています。
入力バッファ用の外部 SRAM を追加
効率を改善するための最初の最適化は、SDRAM から外部 SRAM デバイスへの入力
バッファリングを移動することです。この手法は、次の 3 つの理由のため、パ
フォーマンスの向上を作成します。
■
ビデオ・データを取り込むために独自の専用外部 SRAM を使用しているため、ア
プリケーションの入力側には、より高いスループットを実現しています。
■
SDRAM からの高帯域幅のチャンネルの 2 つは解消されて、残りの SDRAM チャネル
はより高いスループットを達成することができます。
■
2 チャンネルを排除すると、SDRAM メモリへのアクセス回数を減らして、より高
いスループットにつながり、より少ない SDRAM のロウの変更につながります。
再設計されたシステムは、より複雑かつ高いコストの犠牲で、高速にデータを処理
します。図 7–3 に、再設計されたシステムを示します。
1
ビデオ・フレームは、FPGA のオンチップ・メモリに収まるほど小さい場合は、外部
SRAM デバイスを追加することの費用と複雑さを節約し、入力バッファ用のオンチッ
プ・メモリを使用することができます。
図 7‒3. 外部 SSRAM に移転された入力チャネル
Input
DMA
Input
Device
Nios II
Processor
Buffer
SRAM
Instr
Cache
Nios II
CPU
Data
Cache
ping pong
Buffer
Instr Mem
SDRAM
Data Mem
Buffer
ping pong
Buffer
Output
DMA
Output
Device
4 つのチャネルは、SDRAM に接続したままに注意してください。
1. プロセッサの命令チャンネル
2. プロセッサのデータ・チャネル
3. プロセッサからの出力データ
4. DMA への出力データ
エンベデッド・デザイン・ハンドブック
2010 年 2 月
Altera Corporation
第 7 章： メモリ・システム・デザイン
ケース・スタディ
7‒19
出力チャネル用の第 2 の外部 SRAM を追加することにより、いくつかの追加のパ
フォーマンス上の利点を得ることができますが、その利点は、追加コストおよび複
雑さを上回るのに十分重要である傾向がありません。その理由は、残りの 4 つの
チャネルのうち 2 つだけが、2 つのビデオ出力チャンネルの SDRAM からの重要な帯
域幅を必要とすることです。Nios II プロセッサは命令キャッシュとデータ・キャッ
シュの両方が含まれていることを仮定すると、プロセッサが必要とする SDRAM の帯
域幅は比較的小さい可能性が高いです。したがって、プロセッサ命令、プロセッサ
のデータ、およびビデオ出力チャネル用の SDRAM を共有することは、おそらく許容
されます。必要な場合、プロセッサのキャッシュ・サイズを大きくすると、SDRAM
の帯域幅のプロセッサへの依存をさらに低減することができます。
ビデオ · ライン · バッファ用のオンチップ · メモリを追加
最終的な最適化は、入力と出力のビデオ・ライン用の小さなオンチップ・メモリ・
バッファを追加することです。処理アルゴリズムは一度にビデオ入力の 1 ライン上
で動作するため、オンチップ・メモリに入力データのライン全体をバッファリング
すると、パフォーマンスが向上させます。このバッファは、オンチップ RAM（利用
可能なメモリの中で最速、最低レイテンシ・タイプ）からすべての入力データを読
み出すために Nios II プロセッサをイネーブルします。
DMA は、外部 SRAM に使用される入力フレーム・バッファに類似した方法で、先に
ピンポン方式では、Nios II プロセッサのこれらのバッファを埋めます。同じオン
チップ・メモリ・ライン・バッファリング方式は、プロセッサの出力に使用されま
す。Nios II プロセッサは、オンチップ・メモリ・ライン・バッファへの出力データを
書き込みます。これによって、ピンポン・バッファの入力および出力の両方をフ
リップした後に、DMA で出力フレーム・バッファにコピーされ、プロセッサは次の
ラインの処理を開始します。図 7–4 に、このメモリ・アーキテクチャを示します。
図 7‒4. ラインバッファとしてオンチップ・メモリを追加
Input
Device
Input
DMA
SRAM
Buffer
Nios II Processor
ping pong
Buffer
Line Buffer
DMA
On-Chip
Mem
Instr
Cache
SDRAM
Instr Mem
Data
Cache
Data Mem
On-Chip
Mem
Line Buffer
DMA
Buffer
ping pong
Buffer
Output
DMA
2010 年 2 月
Altera Corporation
Output
Device
エンベデッド・デザイン・ハンドブック
7‒20
第 7 章： メモリ・システム・デザイン
参考資料
参考資料
この章では以下のドキュメントを参照しています。
■
■
Quartus II ハンドブックの Volume 4: SOPC Builder の Avalon Memory-Mapped Bridges の
章
エンベデッド・デザイン・ハンドブックの Avalon Memory-Mapped Design
Optimizations の章
■
Quartus II ハンドブックの Volume 5: Embedded Peripherals の Common Flash Interface
Controller Core
■
外部メモリ・インタフェース・ハンドブックの Volume 3 の DDR and DDR2 SDRAM
High-Performance Controllers and ALTMEMPHY IP User Guide のセクション
■
外部メモリ・インタフェース・ハンドブックの Volume 3 の DDR3 SDRAM HighPerformance Controller and ALTMEMPHY IP User Guide のセクション
■
コンフィギュレーション・ハンドブックの Volume 2 の FPGA Configuration Devices ん
の章
■
Nios II Flash Programmer User Guide
■
Quartus II ハンドブックの Volume 5: Embedded Peripheralsの On-Chip FIFO Memory Core
■
Quartus II ハンドブックの Volume 5: Embedded Peripherals の SDRAM Controller Core
■
Quartus II ハンドブックの Volume 4: SOPC Builder の SOPC Builder Memory Subsystem
Development Walkthrough
■
Using Tightly Coupled Memory with the Nios II Processor Tutorial
改訂履歴
表 7–2 に、このドキュメントの改訂履歴を示します。
表 7‒2. 改訂履歴
日付
バー
ジョン
変更内容
2010 年 2 月
1.2
外部メモリ・インタフェース・ハンドブックの参照資料を更新。
2008 年 6 月
1.1
目次を補正。
2008 年 3 月
1.0
初版。
エンベデッド・デザイン・ハンドブック
2010 年 2 月
Altera Corporation
8. ハードウェア・アクセラレーション
およびコプロセッシング
7? 2011?
ED51006-1.2
ED51006-1.2
この章では、SOPC Builder でより効率的に、高いスループットのデザインを作成する
ために、ハードウェア・アクセラレータやコプロセッシングを使用する方法につい
て説明します。この章では、以下の項目について説明します。:
■
「CRC（Cyclic Redundancy Checking）のアクセラレーション」
■
「Nios II カスタム命令の作成」
■
「C2H コンパイラの使用」
■
「マルチコア・デザインの作成」
■
「前処理および後処理」
■
「ステート・マシンの交換」
ハードウェア・アクセラレーション
FPGA に実装されたハードウェア・アクセラレータは、パフォーマンスが制限された
システム向けのスケーラブルなソリューションを提供します。システムのパフォー
マンスを増加するため、より高いパフォーマンスのコンポーネントを選択したり、
システム・クロック周波数を増加したりすることがあります。これらの別ソリュー
ションとして効率がありますが、多くの場合、コスト、電力、またはデザイン時間
が高くなります。
CRC（Cyclic Redundancy Checking）のアクセラレーション
CRC はソフトウェアよりもハードウェアでかなり効率的です。その結果、CRC のた
めのハードウェア・アクセラレータを実装することによって、システムのスルー
プットを向上させることができます。また、プロセッサが実行する必要があるタス
クから CRC を排除することによって、プロセッサは他のタスクを達成するために、
より多くの帯域幅を持っています。
図 8–1 に、Nios® II プロセッサがハードウェア・アクセラレータへの CRC 処理をオフ
ロードするシステムを示します。このシステムは、Nios II プロセッサは Avalon®
Memory-Mapped (Avalon-MM) のスレーブ・ポートを使用して CRC を制御するためのレ
ジスタの読み出しと書き込みをします。CRC コンポーネントの Avalon-MM マスタ・
ポートは、メモリから CRC チェックのためのデータを読み出します。
f このデザイン例と、それを実現するための HDL ファイルが 「SOPC Builder User Guide」
の「SOPC Builder Component Development Walkthrough」の章で完全に説明されていま
す。
© 2011 年 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, HARDCOPY, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and
logos are trademarks of Altera Corporation and registered in the U.S. Patent and Trademark Office and in other countries. All other words and logos identified as
trademarks or service marks are the property of their respective holders as described at www.altera.com/common/legal.html. Altera warrants performance of its
semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to any products and
services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any information, product, or service
described herein except as expressly agreed to in writing by Altera. Altera customers are advised to obtain the latest version of device specifications before relying
on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Feedback Subscribe
8‒2
第 8 章： ハードウェア・アクセラレーションおよびコプロセッシング
ハードウェア・アクセラレーション
図 8‒1. CRC のハードウェア・アクセラレータ
Nios II
Processor
M
CRC Hardware
Accelerator
M
M
S
Arbiter
S
Memory
別のアプローチでは、Nios II プロセッサに加えて、専用の DMA エンジンが含まれて
います。図 8–2 に、このデザインを示します。このシステムでは、Nios II プロセッ
サは CRC にメモリからのデータを転送する DMA エンジンを プログラムします。
図 8‒2. CRC の DMA およびハードウェア・アクセラレータ
Nios II
Processor
M
M
DMA
M
M
Arbiter
Arbiter
S
S
Memory
CRC Hardware
Accelerator
図 8–2 に、DMA および CRC を個別ブロックとして示しますが、Avalon-MM マスタと
スレーブ・ポートの両方を含むカスタム・コンポーネントとして、それらを組み合
わせることができます。コンポーネント・エディタを使用して、SOPC Builder システ
ムにこのコンポーネントをインポートすることができます。
1
コンポーネント・エディタについて詳しくは、SOPC Builder User Guide の
「Component Editor」の章を参照してください。アルテラの Embedded
Processor Design Examples のウエブ・ページ上でハードウェア・アクセラ
レーションの追加の例を見つけることができます。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 8 章： ハードウェア・アクセラレーションおよびコプロセッシング
ハードウェア・アクセラレーション
8‒3
I/O 帯域幅のマッチング
I/O 帯域幅は、全体的なパフォーマンスに大きな影響を持つことができます。低い
I/O 帯域幅は、専用ハードウェアが I/O サポートできるよりも高いスループットを必
要とする場合、高性能ハードウェア・アクセラレータが十分に実行させることはで
きません。システムの計算ニーズに I/O 帯域幅を一致させることで、システム全体の
パフォーマンスを向上させることができます。
典型的に、メモリ・インタフェースは、複数のプロセッサとハードウェア・アクセ
ラレータを搭載したシステムの中で最も問題を引き起こします。次のインタフェー
ス・デザインの推奨事項は、ハードウェア・アクセラレータのスループットを最大
にすることができます。
■
システムが実行する必要がある最も優先順位の高いタスクに、高性能メモリおよ
びインタフェースを一致します。
■
任意のメモリやインタフェースが共有されている場合、優先度の高いタスクに I/O
帯域幅の大きなシェアを与えます。
■
ユーザーのシステムで複数のプロセッサを持っていますが、プロセッサの一方の
みがリアルタイム機能を提供している場合は、それより高いアービトレーショ
ン・シェアを割り当てます。
パイプライン化するアルゴリズム
複数の Avalon-MM マスタ・ポートを備えたシステムの共通する問題は、共有リソー
スの競合です。アルゴリズムをパイプライン化、および独立したオンチップ・メモ
リに中間結果をバッファリングすることにより、パフォーマンスを向上させること
ができます。図 8–3 に、このアプローチを示します。2 つのハードウェア・アクセラ
レータは、オンチップ・メモリへの中間結果を書き込みます。第 3 のモジュールは、
オフチップ・メモリへの最終的な結果を書き込みます。オンチップ・メモリに中間
結果を格納することにより、オフチップ・メモリの必要な I/O スループットが低下し
ます。また、オンチップ・メモリは固定、ロー・レイテンシのアクセス時間がある
ため、一時的なストレージとしてオンチップ・メモリを使用することにより、リー
ド・レイテンシを削減します。
図 8‒3. 高性能を実現するオンチップ・メモリの使用
FPGA
Dual Port
On-Chip
Memory
Buffer
I/O
2011 年 7 月
Altera Corporation
Processor/
Hardware
Accelerator
Dual Port
On-Chip
Memory
Buffer
Processor/
Hardware
Accelerator
Processor/
Hardware
Accelerator
External
Memory
エンベデッド・デザイン・ハンドブック
8‒4
第 8 章： ハードウェア・アクセラレーションおよびコプロセッシング
ハードウェア・アクセラレーション
f このセクションで説明したトピックについて詳しくは、SOPC Builder User Guide の
「System Interconnect Fabric for Memory-Mapped Interfaces」および「SOPC Builder Memory
Subsystem Development Walkthrough」の章を参照してください。メモリ・デザインの
最適化について詳しくは、エンベデッド・デザイン・ハンドブックの 「メモリ・シ
ステム・デザイン」の章を参照してください。
Nios II カスタム命令の作成
Nios II プロセッサは、カスタム命令で拡張可能な RISC アーキテクチャを採用してい
ます。Nios II プロセッサは、論理演算ユニット（ALU）と並行して独自のカスタム命
令のハードウェアを実装するために使用できる標準的なインタフェースを備えてい
ます。
すべてのカスタム命令は類似した構造があり、最大 2 つのデータ入力と 1 つのデー
タ出力、およびオプションのクロック、リセット、モード、アドレス、およびより
複雑なマルチサイクル動作のステータス信号があります。多数の入力と出力が必要
とするハードウェア・アクセラレーションを追加する必要がある場合、Avalon-MM ス
レーブ・ポートを持つカスタム・ハードウェア・アクセラレータは、より適切なソ
リューションとなります。カスタム命令はカスタム命令が完了するまで、追加の命
令を実行してからプロセッサを防ぐ動作をブロックしています。カスタム命令が実
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 8 章： ハードウェア・アクセラレーションおよびコプロセッシング
ハードウェア・アクセラレーション
8‒5
行されている間に、プロセッサが停止しないようにするには、Avalon-MM スレーブ・
ポートを持つハードウェア・アクセラレータにカスタム命令を変換することができ
ます。そうすると、プロセッサとカスタム・ペリフェラルは、並行して動作させる
ことができます。図 8–4 には、カスタム命令とハードウェア・アクセラレータ間の
実装の違いを示します。
図 8‒4. カスタム命令とハードウェア・アクセラレータ間の実装の違い
Nios II Processor Core
Operand A
General
Purpose
Registers
ALU
Operand B
Custom Instruction Interface
Custom
Instruction
(Operator)
Hardware Accelerator
readdata[31:0]
System
Interconnect
Fabric
writedata[31:0]
Operand A
D
AvalonMM
Slave
Port
E
Operator
Operand B
D
write
Altera Corporation
Q
E
address[0]
2011 年 7 月
Q
decoder
エンベデッド・デザイン・ハンドブック
8‒6
第 8 章： ハードウェア・アクセラレーションおよびコプロセッシング
ハードウェア・アクセラレーション
カスタム命令は Nios II プロセッサの ALU を拡張するため、ロジックはタイミングを
満たす必要があり、またはプロセッサの fMAX が悪くなる可能性があります。プロ
セッサにカスタム命令を追加したように、ALU のマルチプレクサは、図 8–5 で示す
ように幅に生えています。このマルチプレクサは ALU のハードウェア（図 8–5 の
c[31:0]）からの出力を選択します。ユーザーはカスタム命令をパイプライン化できま
すが、自動的に挿入 ALU マルチプレクサを制御することはできません。結果として、
より高いパフォーマンスのためのマルチプレクサをパイプライン化することはでき
ません。
図 8‒5. 個々のカスタム命令
Custom 0
Custom 1
Custom 2
Custom 3
ALU
a[31:0]
+
-
c[31:0]
>>
<<
b[31:0]
エンベデッド・デザイン・ハンドブック
&
|
2011 年 7 月
Altera Corporation
第 8 章： ハードウェア・アクセラレーションおよびコプロセッシング
ハードウェア・アクセラレーション
8‒7
図 8–6 に示すように、いくつかのカスタム命令を追加する代わりに、単一のロジッ
ク・ブロックに機能を組み合わせることができます。カスタム命令を組み合わせる
と、必要な機能を選択するセレクタ・ビットを使用します。組み合わせたカスタム
命令を作成する場合は、手動でのロジックでマルチプレクサを挿入する必要があり
ます。この方法では、出力を生成するマルチプレクサ・ロジックを完全に制御でき
ます。組み合わせたカスタム命令はクリティカル・タイミング・パスの一部となる
ことを防止するためにマルチプレクサをパイプラインク化することができます。
図 8‒6. 組み合わせたカスタム命令
Combined
Custom
Instruction
Custom 0
Custom 1
D Q
Custom 2
Custom 3
select[1:0]
a[31:0]
ALU
+
c[31..0]
>>
<<
b[31:0]
&
|
図 8‒6 の注：
(1) Nios II コンパイラは、マルチプレクサ <n> にセレクト・ワイヤを呼び出します。
ロジック・ブロックに複数のカスタム命令が組み込まれることにより、それはタイ
ミングを失敗した場合に出力をパイプライン化することができます。カスタム命令
を組み合わせるには、それぞれが同一のレイテンシ特性を持っている必要がありま
す。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
8‒8
第 8 章： ハードウェア・アクセラレーションおよびコプロセッシング
ハードウェア・アクセラレーション
カスタム命令は、固定レイテンシまたは可変レイテンシです。ユーザーは、タイミ
ング・ロジックを追加することで、可変レイテンシに固定レイテンシのカスタム命
令を変換することができます。図 8–7 に、<n> のクロック・サイクルで start ビット
をシフトし、論理的にすべて done ビットを OR にすることにより、この変換を実装
するための最も簡単な方法を示します。
図 8‒7. ミックス・レイテンシの組み合わせたカスタム命令のロジックのシーケン
ci_done
Custom Instruction 0
with Variable Latency
n
done_0
done_1
start
D
Q
D
Q
D
done
Q
Custom Instruction 1
with a Fixed Latency
of 3 Clock Cycles
各カスタム命令は ALU に接続する際に経由する少なくとも 1 つのカスタム命令のス
レーブ・ポートが含まれています。カスタム命令のスレーブはそのスレーブ・ポー
トです。このスレーブ・インタフェースは、データ入力信号を受信し、結果をリ
ターンます。カスタム命令マスタは、カスタム命令に接続するプロセッサのマスタ・
ポートです。
f カスタム命令の作成と使用について詳しくは、Nios II Custom Instruction User Guide を参
照してください。
C2H コンパイラの使用
HDL 論理合成可能なソース・コードに C ソース・コードをコンパイルする Nios II C2H
コンパイラを使用することができます。SOPC Builder は、自動的にシステム内のハー
ドウェア・アクセラレータを配置します。SOPC Builder は、自動的に必要なメモリへ
のすべてのマスタ・ポートを接続し、データを転送するために使用されるアクセラ
レータ・スレーブ・ポートに Nios II プロセッサのデータ・マスタ・ポートを接続し
ます。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 8 章： ハードウェア・アクセラレーションおよびコプロセッシング
コプロセッシング
8‒9
アルゴリズムはメモリへのアクセスを必要とする場合、カスタム命令の代わりに、
Nios II C2H コンパイラを選択します。C2H コンパイラは、メモリをアクセスする
Avalon-MM マスタを作成します。アルゴリズムでは、いくつかのメモリをアクセスす
る場合、C2H コンパイラを使用すると、システム・インタコネクト・ファブリック
の同時アクセス機能の恩恵を受けることができ、メモリ・アクセスごとにマスタを
作成します。また、他のソフトウェア機能と並行してアクセラレータを使用できる
ように、ノンブロッキングであるハードウェア・アクセラレータを作成する C2H コ
ンパイラを使用することができます。
図 8‒8. C2H 離散コサイン変換（DCT）のブロック図
DCT Hardware Accelerator
(Generated by C2H)
Nios II Processor
M
M
S
M
M
M
Arbiter
Arbiter
Arbiter
Arbiter
S
S
S
S
Code & Data
Memory
Input Buffer
Memory
Cosine Table
Memory
Output Buffer
Memory
図 8–8 では、2 次元 DCT のアルゴリズムは、Nios II プロセッサをオフロードするため
に加速されます。DCT アルゴリズムは、コサイン・ルックアップ・テーブルと同様に
入力および出力バッファへのアクセスを必要とします。それぞれ別々のメモリにあ
ると前提として、ハードウェア・アクセラレータが同時にすべての 3 つのメモリに
アクセスすることができます。
詳細は、エンベデッド・デザイン・ハンドブックの 「Nios II C2H Compiler User Guide」
および 「Optimizing C2H Compiler Results」の章を参照してください。また、アルテラ
のウエブサイトから C2H examples も入手できます。
コプロセッシング
Nios II プロセッサおよびハードウェア・アクセラレータの間、または FPGA 内の複数
の Nios II プロセッサの間のシステム機能を分割することで、コストを制御するのに
役立ちます。以下のセクションでは、高性能システムを作成するためにコプロセッ
シングを使用する方法を示しています。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
8‒10
第 8 章： ハードウェア・アクセラレーションおよびコプロセッシング
コプロセッシング
マルチコア・デザインの作成
マルチコア・デザインは、より高性能のコンピューティング・システムを作成する
ための単一の FPGA に複数のプロセッサ・コアを組み合わせます。典型的には、マル
チコア・デザインのプロセッサは、相互に通信することができます。Nios II プロセッ
サを含むデザインは、プロセッサ間通信を実装することができます。またはプロ
セッサは、自律的に動作することができます。
デザイン内に複数のプロセッサが含まれている場合、すべてのプロセッサを有効に
利用するために慎重にアルゴリズムをパーティション作成する必要があります。次
の例では、離散 DSP プロセッサにデータを供給するためのネットワーク・インタ
フェースを使用してビデオ・オーバ IP の実行の Nios II ベースのシステムが含まれて
います。当初のデザインでは、Nios II プロセッサをオーバに利用します。システム
は、DSP プロセッサにネットワークからのデータを転送するには、次の手順を実行
します。
1. フル・データ・パケットが受信されたとき、ネットワーク・インタフェースを通
知します。
2. Nios II プロセッサは、オンチップ・メモリ・バッファ上のデュアルポートにパ
ケットを転送する DMA エンジンを使用します。
3. Nios II プロセッサは、オンチップ・メモリ・バッファにパケットを処理します。
4. Nios II プロセッサは、DSP プロセッサにビデオ・データを転送する DMA エンジン
を使用します。
オリジナルのデザインでは、Nios II プロセッサはまた、Avalon-MM スレーブ・ポート
を含め、次のペリフェラルとの通信を担当します。
■
ハードウェア・デバッグ・インタフェース
■
ユーザー・インタフェース
■
パワー・マネージメント
■
リモート・コントロール・レシーバ
図 8–9 に、このデザインを示します。
図 8‒9. 過度に使用されたビデオ・システム
Dual-Port
On-Chip
Memory
Buffer
Nios II/f
Core
Network
Interface
SDRAM
エンベデッド・デザイン・ハンドブック
Hardware
Debug
Interface
Control Plane
External DSP
Interface
DMA
User
Interface
Data Plane
Power
Management
Remote
Control
Receiver
2011 年 7 月
Altera Corporation
第 8 章： ハードウェア・アクセラレーションおよびコプロセッシング
コプロセッシング
8‒11
システムに第 2 の Nios II プロセッサを追加すると、ワークロードが 1 つのプロセッ
サはネットワーク機能と他のコントロール・インタフェースを処理できるように分
割することができます。図 8–10 は、改訂されたデザインを示しています。
改訂されたデザインは、2 つのプロセッサが搭載されているので、2 つのソフトウェ
ア・プロジェクトを作成する必要がありますが、これらのソフトウェア・プロジェ
クトのそれぞれは、より少ないタスクを処理し、作成と維持するために簡単です。
また、プロセッサ間通信のためのメカニズムを作成する必要があります。このシス
テムでのプロセッサ間通信は比較的簡単で、システムの性能向上によって正当化さ
れます。
f プロセッサ間通信のためのハードウェアおよびソフトウェアのデザインについて詳
しくは、「Creating Multiprocessor Nios II Systems Tutorial」および 「Embedded Peripherals
IP User Guide」の「Peripherals」のセクションを参照してください。このソフト・コ
ア・プロセッサについて詳しくは、「Nios II Processor Reference Handbook」を参照して
ください。Nios II Multiprocessor Design Example はアルテラのウエブサイトから入手で
きます。
図 8‒10. 高性能ビデオ・システム
Dual-Port
On-Chip
Memory
Buffer
Nios II/f
Core
Network
Interface
Data Plane
Control Plane
External DSP
Interface
DMA
Nios II/e
Core
SDRAM
Hardware
Debug
Interface
User
Interface
Power
Management
Remote
Control
Receiver
図 8–10 において、システムに追加された第 2 の Nios II プロセッサは、主に低レベル
のメンテナンス・タスクを実行します。その結果、Nios II/e コアが使用されます。
Nios II/e コアは、小さなハードウェア・フットプリントのパフォーマンスをトレー
ド・オフするための努力での最も基本的なプロセッサ機能を実装しています。この
コアは、Nios II/f コアの約 3 分の 1 の大きさです。
f 第 3 の Nios II プロセッサについて詳しくは、Nios II プロセッサのリファレンス・ハン
ドブックの 「Nios II Core Implementation Details」の章を参照してください。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
8‒12
第 8 章： ハードウェア・アクセラレーションおよびコプロセッシング
コプロセッシング
前処理および後処理
図 8–10 に示す高性能ビデオ・システムでは、ハードウェアでコントロール・プレー
ンとデータ・プレーンを分離することでワークロードを分散します。図 8–11 は、異
なるアプローチを示しています。DSP のワークロードのすべての 3 つのステージは、
離散プロセッサ上で実行されているソフトウェアに実装されています。このワーク
ロードは、次のステージがあります。
■
入力処理 — 通常はパケットのヘッダとエラー訂正情報を削除する
■
アルゴリズム処理とエラー訂正 — データを処理する
■
出力処理 — 通常はエラー訂正の追加、パケットにデータ・ストリームの変換、I/O
デバイスへのデータのドライブ
入力または出力のために必要な処理を FPGA にオフ・ロードすることによって、離散
プロセッサがアルゴリズム処理のために集中することが出来るため、より多くの計
算帯域幅を持っています。
図 8‒11. 離散的な処理ステージ
Discrete Processor
Inputs
エンベデッド・デザイン・ハンドブック
Input
Processing
Algorithmic
Processing
Output
Processing
Outputs
2011 年 7 月
Altera Corporation
第 8 章： ハードウェア・アクセラレーションおよびコプロセッシング
コプロセッシング
8‒13
離散プロセッサはアルゴリズムのためのより多くの計算帯域幅を必要とする場合は、
専用のコプロセッシングを追加することができます。図 8–12 に、各ステージの専用
のコプロセッシングの例を示します。
図 8‒12. プリ専用、および後処理
Example 1:
Inputs
Example 2:
Discrete Processor
FPGA Pre-Processing
Inputs
Discrete Processor
Outputs
Outputs
FPGA Dedicated
Processing
Example 3:
Inputs
Discrete Processor
FPGA Post-Processing
Outputs
FPGA
Discrete Processor
ステート・マシンの交換
スケーラブルで効率的なステート・マシンを実装する Nios II プロセッサを使用する
ことができます。ステート・マシンを実装するために専用のハードウェアを使用す
る場合、各追加のステートやステート遷移は、ハードウェアの使用率を向上させま
す。これとは対照的に、Nios II プロセッサ上で実行されるステート・マシンに同じ
機能を追加することで、Nios II プロセッサのメモリ使用率のみが増加します。
ステート・マシンの実装のために Nios II を使用することの主な利点は、ハードウェ
アの代わりにソフトウェアを使用してからの結果の複雑さの低減です。定義により、
プロセッサは、多くのステートが含まれているステート・マシンです。これらのス
テートは、プロセッサ・レジスタ・セットまたはプロセッサへの利用可能なメモリ
に格納することができます。その結果、FPGA のフットプリントに収まらないステー
ト・マシンは、Nios II プロセッサに接続されたメモリを使用して作成できます。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
8‒14
第 8 章： ハードウェア・アクセラレーションおよびコプロセッシング
コプロセッシング
Nios II プロセッサ上で実行するためのステート・マシンをデザインするとき、シス
テムの必要なスループット要件を理解する必要があります。一般に、ステート・マ
シンはスティミュラス（入力）に基づいて意思決定（トランジション）とアクショ
ン（出力）で構成されています。選択したプロセッサは、これらの動作が行われる
速度を決定します。また、ステート・マシンのスピードは実装されているアルゴリ
ズムの複雑さによって異なります。ソフトウェアのモジュールまたは一緒に対話し
て複数の Nios II プロセッサ・コアを使用して、別のステート・マシンにアルゴリズ
ムを分割することができます。
低速ステート・マシン
低速ステート・マシンは、一般的にペリフェラルを制御するために使用されます。
8–11 ページの図 8–10 の Nios II/e プロセッサがペリフェラルを制御するために低速ス
テート・マシンを実装することができます。
1
Nios II/e コアはデータ・キャッシュが含まれていなくても、アルテラは、ペリフェラ
ルにアクセスするソフトウェアがバイパスのデータ・キャッシュを使用することを
推奨します。そうすることで、ソフトウェアは、これまでのデータ・キャッシュを
含む Nios II/f コアで実行されている場合、潜在的なキャッシュ・コヒーレンシの問題
を回避できます。
f データ・キャッシュのバイパス方法について詳しくは、Nios II プロセッサのリファレ
ンス・ハンドブックの 「Processor Architecture」の章を参照してください。
SOPC Builder で実装されたステート・マシンは、次のコンポーネントが必要です。
■
A Nios II プロセッサ
■
プログラムおよびデータ・メモリ
■
スティミュラス・インタフェース
■
出力インタフェース
SOPC Builder でステート・マシンの作成のために使用するビルディング • ブロック
は、手動でステート・マシンを作成していた場合に使用するものとは同様です。
SOPC Builder の環境では 1 つの顕著な違いは、Nios II プロセッサからインタフェース
へのアクセスです。Nios II プロセッサは、ペリフェラルにアクセスする Avalon-MM
マスタ・ポートを使用しています。信号を使用してインタフェースにアクセスする
代わりに、メモリにマップされたインタフェースを介して通信を行います。メモリ
を管理することは、多くの直接接続されたインタフェースを作成するよりも非常に
簡単であるので、メモリにマップされたインタフェースでは、巨大なステート・マ
シンのデザインを簡素化します。
f Avalon-MM インタフェースについて詳しくは、Avalon Interface Specifications を参照して
ください。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 8 章： ハードウェア・アクセラレーションおよびコプロセッシング
改訂履歴
8‒15
高速ステート・マシン
Nios II/f コアを使用して高スループットのステート・マシンを実装する必要がありま
す。パフォーマンスを最大限にするには、I/O インタフェースおよびメモリ・タイプ
に焦点を当てます。メモリの使用に関する次の推奨事項は、ステート・マシンのス
ループットを最大にできます。
■
高速決定の作成のためのロジックを格納するためのオンチップ・メモリを使用。
■
ステート・マシンは確定的レイテンシで動作しなければならない場合、密結合メ
モリを使用します。密結合メモリはキャッシュ・メモリと同じアクセス時間を
持っています。その結果、キャッシュ・メモリおよび可能性があるキャッシュの
一貫性の問題の使用を回避することができます。
f 密結合メモリについて詳しくは、Nios II Software Developer's Handbook の 「Cache and
Tightly-Coupled Memory」の章を参照してください。
細分化ステート・マシン
小さく、より管理しやすい単位にハードウェア・ベースのステート・マシンを細分
化することは難しい場合があります。ハードウェア実装におけるステート・マシン
機能の一部を保持するように選択した場合は、それを支援するために、Nios II プロ
セッサを使用することができます。例えば、高いデータ・スループット機能にハー
ドウェア・ステート・マシン、および低速動作用に Nios II を使用する場合がありま
す。小さい、ハードウェア・ベースのステート・マシンに複雑なステート・マシン
をパーティション作成する場合は、スケジュールについては、Nios II プロセッサを
使用することができます。
改訂履歴
表 8–1 に、このドキュメントの改訂履歴を示します。
表 8‒1. 改訂履歴
バー
ジョン
変更内容
2011 年 7 月
1.2
リファレンスを更新し、「カスタム命令スレーブ」および「カスタム命令マスタ」
のリファレンスの意味を明確化。
2008 年 6 月
1.1
目次をを補正。
2008 年 3 月
1.0
初版。
日付
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
8‒16
エンベデッド・デザイン・ハンドブック
第 8 章： ハードウェア・アクセラレーションおよびコプロセッシング
2011 年 7 月
Altera Corporation
9. 検証およびボード立ち上げ
7? 2011?
ED51010-1.3
ED51010-1.3
はじめに
この章では、エンベデッド・システムの検証と起動に使用できる、Quartus® II ソフト
ウェアおよび Nios® II エンベデッド・デザイン・スイート（EDS）で使用可能なツー
ルの概要を説明します。この章は、以下のトピックスで構成されています。
■
「検証方法」
■
「ボード立ち上げ」
■
「システム検証」
検証方法
エンベデッド・システムは限られたメモリおよび I/O を持っていて、ハードウェアお
よびソフトウェア・コンポーネントが混在しているため、デバッグが困難になる可
能性があります。Altera® は、これらの困難を克服するのに役立つ次のツールと戦略
を提供します：
■
「FS2 コンソール」
■
「システム・コンソール」
■
「SignalTap II エンベデッド・ロジック・アナライザ」
■
「外部インスツルメンテーション」
■
「スティミュラスの生成」
前提条件
この章の有効利用を可能にするには、次のトピックについての知識が必要です。
■
SOPC Builder による Nios II ハードウェア・システムの定義と生成
■
Quartus II 開発ソフトウェアによる Nios II ハードウェア・システムのコンパイル
© 2011 年 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, HARDCOPY, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and
logos are trademarks of Altera Corporation and registered in the U.S. Patent and Trademark Office and in other countries. All other words and logos identified as
trademarks or service marks are the property of their respective holders as described at www.altera.com/common/legal.html. Altera warrants performance of its
semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to any products and
services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any information, product, or service
described herein except as expressly agreed to in writing by Altera. Altera customers are advised to obtain the latest version of device specifications before relying
on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Feedback Subscribe
9‒2
第 9 章： 検証およびボード立ち上げ
検証方法
FS2 コンソール
First Silicon Solution（FS2）が開発した FS2 コンソール（FS2）は、Nios II プロセッサ
の検証機能を拡張します。FS2 のコンソールでは、Nios II プロセッサのすべての 3 つ
のバリエーションで使用可能な Nios II JTAG デバッグ・モジュールと通信します。FS2
は、オプションで Nios II JTAG デバッグ・モジュールに追加のトレース・サポートを
作成する外部システム・アナライザ・ハードウェア・モジュールを使用します。
図 9–1 は、FS2 コンソールおよび SOPC Builder システム間の接続を示しています。
図 9‒1. FS2 コンソールの通信パス
FPGA
SOPC Builder System
Host System
Running FS2
Console
Nios II Processor
Memory
Instruction
Master
Flash
USB Blaster
JTAG
Logic
JTAG
Debug
Module
Data
Master
VGA
PWM
System Interconnect Fabric
SPI
UART
USB
Timer
Nios II JTAG デバッグ・モジュールは、Avalon® Memory-Mapped (Avalon-MM) スレーブ・
ポートを含むコンポーネントと通信するための Nios II データ・マスタ・ポートを使
用しています。Nios II JTAG デバッグ・モジュールは Nios II プロセッサと密接に統合
されていますが、それは、プロセッサによって提供されるどの追加サポートにも依
存しません。その結果、ユーザーはソフトウェアを記述することなく、システムを
検証するために、Nios II JTAG デバッグ・モジュールと FS2 コンソールを使用するこ
とができます。
1
FS2 のコンソールは、Linux オペレーティング・システムを実行するホスト・マシンを
サポートしていません。また、Eclipse からのソフトウェア・ビルド・ツールと互換
性がありません。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 9 章： 検証およびボード立ち上げ
検証方法
9‒3
SOPC Builder のテスト統合
最終的なデザインで、Nios II プロセッサまたは SOPC Builder システムを含める予定の
ない場合でも、アルテラが提供するエンベデッド・ツールを活用するために、デ
バッグ・フェーズで Nios II プロセッサを含めることができます。Nios II プロセッサに
は、ユーザーのハードウェア・ブロックへのリードおよびライト・アクセスを実行
するために使用できるデータ・マスタが含まれています。
システム内に JTAG デバッグ・モジュールを含めるには、次の手順に従います。
1. System Contents タブで、Nios II Processor コンポーネントをダブルクリックしま
す。
2. Nios II プロセッサ・ウィザードでは、JTAG Debug Module をクリックします。
3. Level 1 が選択されていることを確認します。
JTAG デバッグ・モジュールは、システムと FS2 コンソール間の通信のために必要で
す。
FS2 コンソールの機能
ユーザーは、Nios II IDE または Nios II コマンド・シェルから FS2 コンソールを起動し
ますが、Eclipse 用のソフトウェア・ビルド・ツールから FS2 コンソールを起動する
ことはできません。FS2 コンソールが開いた後、ソフトウェアのコマンド・ラインと
スクリプト機能にアクセスすることができます。FS2 コンソール内のコマンド・ライ
ンは、軽量のデバッグにとって十分です。FS2 へのヘルプにアクセスするには、使用
可能なコマンドのリストに単に help を入力します。ヘルプ・システムは階層構造で
す。help を入力すると、ヘルプ・システムには、トップレベルのコマンドの階層が
示されます。使用可能なコマンドについての詳細を学ぶために、help
<command_name> を入力することによって、検索精度を高めることができます。例え
ば、help memory を入力すると、FS2 コンソールには、addr、asm、byte、compare、
copy、dasm、dump、などを含めて、メモリにアクセスするためのすべてのコマンド
のリストが表示されます。
FS2 コンソールを使用すると、任意の Nios II デバッグ・モジュールがあるかどうか
を決定するために FPGA を照会することができます。FS2 コンソールは、JTAG チェイ
ンのどの位置でも Nios II プロセッサ・デバッグ・モジュールにアクセスできます。
ユーザーのデザインが複数の Nios II デバッグ・モジュールを持っている場合がある
ので、好むデバッグ・モジュールを指定することができます。
Nios II プロセッサは、32 ビット・データ・マスタを持っています。FS2 コンソールを
使用すると、任意の Avalon-MM スレーブ・ポートにアクセスするバイト（byte）、
ハーフ・ワード（half）、またはワード（word）のいずれかを実行することができま
す。
FS2 コンソールは、Tcl/Tk のスクリプト言語をサポートしています。テストするハー
ドウェア・ブロックがたくさんある場合、または回帰テストを組み込む必要がある
場合、メモリ・アクセスのスクリプトは特に便利です。Tcl/Tk のリファレンス・ガイ
ドは、FS2 コンソールのヘルプ・メニューに統合されています。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
9‒4
第 9 章： 検証およびボード立ち上げ
検証方法
sld info コマンド
sld info コマンドは、ボード上の使用可能な JTAG チェインを示しています。ボード
にアクセスするために使用されているチェインはコマンドによって、JTAG ケーブル
（hw）、FPGA デバイス、およびデバッグ・モジュール（node）の識別情報を提供して
います。図 9–2 に、このコマンドの一般的な出力を示します。この例では、通信が
Hw 1: USB-Blaster [USB-0] の第 2 の JTAG チェインに発生します。この JTAG チェイン
には、デバイス 1: EP2C35 の単一 FPGA があり、ノード 0: 所有者 : First Silicon Solutions
の単一のデバッグ・モジュールがあります。
config コマンドを使用して、FS2 コンソールにこれらのコンポーネントを指定する必
要があります。図 9–2 に示す JTAG チェインでは、次の 3 つのコマンドを入力する必
要があります。
■
config sldHW 1— 第 2 のプログラミング・ケーブルを選択します。
■
config sldDev 1—JTAG チェインの第 2 のデバイスを選択します。
■
config sldNode 0—FPGA の最初のデバッグ・モジュールを選択します。
図 9‒2. sld info コマンド
異なるデバイスおよびデバッグ・モジュールに別の JTAG ケーブルを介して通信する
ために、このコンフィギュレーション情報を更新することができます。例えば、第 2
の Nios II プロセッサ・デバッグ・モジュールを使用して、第 3 のデバイスに第 4 の
プログラミング・ケーブルを介して通信できるようにするには、次のコマンドを入
力します。
■
config sldHW 3
■
config sldDev 2
■
config sldNode 1
最初に FS2 コンソールを始動すると、第 1 の FPGA 内のデバッグ・モジュールを使用
しながら、第 1 のデバイスに第 1 のケーブルを介して通信するように初期化されま
す。ただし、この情報を更新する場合、変更内容は永続的です。
Quartus II ソフトウェアでデザインをコンパイルした後、プロジェクト・ディレクト
リ内の JTAG デバッグ・インタフェース・ファイル（.jdi）には、デバッグ・モ
ジュールのインスタンス番号が含まれています。ユーザーのデザインが単一の FPGA
内に 2 つの SOPC Builder システムを含む場合、再コンパイルするときに、デバッグ・
モジュールのインスタンス番号が変更されることがあります。各デバッグ・モ
ジュールは、完全な名前とデザインの階層のレベルによって参照されます。デバッ
グ・モジュール番号は、sld_instance_index として格納されます。例えば、デバッ
グ・モジュールが 3 に割り当てられている場合、.jdi ファイルには、次の設定が含ま
れています。
<parameter name="sld_instance_index" type="dec" value="3"/>
これは、sldNode を設定するときに使用する値です。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 9 章： 検証およびボード立ち上げ
検証方法
9‒5
FS2 の例
次の手順では、8 ビット・ハードウェア・ブロックに 0xA5 を続いて 0x5A を書き込み
ます。
1. ハードウェア・イメージ・ファイルの SRAM オブジェクト・ファイル (.sof) をダ
ウンロードします。
2. FS2 コンソールを起動するには、Nios II コマンド・シェルで nios2-console を入力
します。
3. リモート・デバッガとの通信を確立するには、FS2 コンソールで、openport sld
を入力します。
4. Nios II プロセッサを停止するには、halt を入力します。
5. メモリ位置 0x00810880 に 0x5A を書き込むには、byte 0x00810880 0x5A を入力しま
す。
6. メモリ位置 0x00810880 に 0xA5 を書き込むには、byte 0x00810880 0xA5 を入力しま
す。
例 9–1 では、アドレス範囲に繰り返しパターンを書き込みます。この例を試す前に、
有効な場所に書き込みおよび読み出しをするため、SOPC Builder システム内のメモ
リ・デバイス用のベース（アドレス）カラムを確認します。この例では、オンチッ
プ・メモリは 0x02100000 のベース・アドレスを持っています。
例 9‒1. アドレス範囲に繰り返しパターンを書き込む
# write a repeating pattern of 0x5a5a5a5a to an address range
word 0x02100000..0x021000FF 0x5a5a5a5a
# read back the data from the address range
dump 0x02100000..0x021000FF word
FS2 コンソールから JTAG デバッグ・モジュールに送信されるすべてのコマンドは、
FPGA の JTAG インタフェースを使用します。JTAG は、比較的低速な通信媒体です。
メモリ・インタフェースをストレス・テストするために FS2 コンソールに頼ること
はできません。メモリをストレス・テストする戦略について詳しくは、9–11 ページの
「ボード立ち上げ」を参照してください。
f FS2 コンソールについて詳しくは、www.fs2.com における First Silicon Solutions のウェブ
サイトを参照してください。Nios II エンベデッド・デザイン・スイート（EDS）のイ
ンストールには、FS2 コンソールのドキュメントが含まれています。
<Nios II EDS install path>/bin/fs2/doc でこのドキュメントを見つけることができます。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
9‒6
第 9 章： 検証およびボード立ち上げ
検証方法
システム・コンソール
SOPC Builder システムの低レベルのデバッグを実行するシステム・コンソールを使用
することができます。ユーザーは、コマンド・ライン・モードでシステム・コン
ソール機能にアクセスします。ユーザーは、対話形式で作業したり、Tcl スクリプト
を実行することができます。システム・コンソールでは、ターミナル・ウィンドウ
でコマンドへの応答を出力します。システム・コンソールとデバッグを容易にする
ために、システム・コンソールがコマンドを送信し、データを受信するために使用
できるインタフェースを持つ 4 つの SOPC Builder コンポーネントのいずれかを含める
ことができます。表 9–1 に、これらのコンポーネントを示します。
表 9‒1. システム・コンソールとの通信用の SOPC Builder コンポーネント (1)
コンポーネント名
次のインタフェース・タイプを持つデバッグ・コンポーネント
JTAG デバッグ・イネーブルを持つ
Nios® II プロセッサ
Avalon-MM スレーブ・インタフェースを含むコンポーネントです。
また、JTAG デバッグ・モジュールは、プロセッサの開始、停止、
およびステッピングを含めたデバッグ機能用の Nios II プロセッサを
制御することができます。
Avalon マスタ・ブリッジへの JTAG
Avalon-MM スレーブ・インタフェースを含むコンポーネントです。
Avalon Streaming（Avalon-ST）JTAG イン
Avalon-ST インタフェースを含むコンポーネントです。
タフェース
JTAG UART は、バイト・ストリームを送受信するシステム・コン
ソールと組み合わせて使用できる Avalon-MM スレーブ・デバイスで
す。
JTAG UART
表 9–1 の注：
(1) また、システム・コンソールは、アルテラによって提供された SOPC Builder コンポーネント、カスタム・コンポーネント、
または Quartus II プロジェクトの一部でインスタンス化されているかどうか、任意の SLD ノードからバイト・ストリームを
送受信することができます。しかし、このアプローチは、JTAG コマンドの詳細な知識が必要です。
システム・コンソールでは、次のいずれかのタスクを実行できます。
■
メモリとペリフェラルにアクセス
■
Nios II プロセッサを起動または停止
■
ソフトウェアを介して Nios II プロセッサのレジスタ・セットとステップにアクセ
ス
■
JTAG の接続を確認
■
リセット信号にアクセス
■
システム・クロックをサンプリング
システム・コンソールを使用すると、Nios II プロセッサ用のテストベンチを作成し
たり、テスト・コードを記述せずに、実際のハードウェアに独自のカスタム・コン
ポーネントをテストすることができます。Avalon-MM スレーブ・ポートを使用してコ
ンポーネントにアクセスするための Tcl スクリプトをコーディングすることによっ
て、より高いレベルにアクセスする Avalon-MM マスタを抽象化するテストベンチを
作成します。コンポーネント、I/O、または全体のメモリ・マップド・システムを迅
速にテストするためにこの方法を使用することができます。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 9 章： 検証およびボード立ち上げ
検証方法
9‒7
エンベデッド・コントロール・システムには、典型的には、センサなどの入力、ア
クチュエータなどの出力、および入力値に基づいて出力を決定するプロセッサなど
が含まれています。ユーザーは、ハードウェア内にエンベデッド・システムを行使
するための追加のシステムを作成することにより、単独でエンベデッド・コント
ロール・システムをテストすることができます。このアプローチでは、システムへ
の入力をドライブし、出力を測定するためのシステム・コンソールを使用して、
hardware-in-the-loop（HIL）の自動テストを実行することができます。このアプローチ
では、デザインを変更することなく、エンベデッド・システムをテストすることが
できるという利点があります。図 9–3 は、システム・コンソールを使用した HIL テ
ストを示しています。
図 9‒3. システム・コンソールを使用した Hardware-in-the-Loop テスト
Host PC Driving Test
with System Console Display
JTAG to Avalon
Master Bridge
Nios II
Processor
Input
PIO
Output
PIO
Input
PIO
Output
PIO
Input
PIO
Output
PIO
Input
PIO
Output
PIO
Input
PIO
Output
PIO
Input
PIO
Output
PIO
Input
PIO
Output
PIO
Input
PIO
Output
PIO
System Tester
Watchdog
Timer
Memory
Timer
Control System
(Device Under Test)
「Console User Guide」を参照してください。
f システム・コンソールについて詳しくは、
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
9‒8
第 9 章： 検証およびボード立ち上げ
検証方法
SignalTap II エンベデッド・ロジック・アナライザ
SignalTap® II エンベデッド・ロジック・アナライザは、Quartus II ソフトウェアで使用
可能です。これは、FPGA の JTAG ピンを再使用し、Quartus II Fitter の低い優先順位が
あり、それは影響がないものになります。このロジック・アナライザは自動的にデ
ザインに統合されているので、アウトプット・ピン・キャパシタンスや I/O 遅延の望
ましくない副作用を参考せずに、同期された測定を行います。SignalTap II エンベ
デッド・ロジック・アナライザは、外部ロジック・アナライザが提供する機能を複
製し、データ・キャプチャを自動化することができるように、Tcl スクリプトをサ
ポートしています。
このロジック・アナライザは、協調検証を実行できるようにするために、Nios II
JTAG デバッグ・モジュールと JTAG UART を含む他の JTAG コンポーネントを使用し
ている最中の環境で動作させることができます。SignalTap II エンベデッド・ロジッ
ク・アナライザで使用可能なプラグイン・サポートを使用して、次のいずれかでデ
バッグ機能を強化することができます。
■
トリガする命令アドレス
■
トリガに関連するノンプロセッサ
■
ソフトウェア・ディスアセンブリ
■
命令ディスプレイ（16 進数またはシンボリック形式）
また、MathWorks 社の MATLAB ソフトウェアで解析するためのエンベデッド・システ
ムからのデータをキャプチャするために、このロジック・アナライザを使用するこ
とができます。MATLAB ソフトウェアは、JTAG 接続を使用してデータを受信し、ポス
ト処理解析を実行することができます。ループ構造を使用すると、手動で Quartus II
デザイン・ソフトウェアを使用してロジック・アナライザを制御する代わりに、
MATLAB ソフトウェアで自動的に複数のデータ・キャプチャ・サイクルを実行するこ
とができます。
SignalTap II エンベデッド・ロジック・アナライザは FPGA の JTAG 接続を使用するの
で、データを連続的にトリガするとサンプルが失われる可能性があります。例えば、
100 MHz で連続してデータをキャプチャする場合、ユーザーのすべてのサンプルがロ
ジック・アナライザ GUI に表示されることを期待してはいけません。ロジック・ア
ナライザは、100 MHz でデータをバッファリングしますが、JTAG インタフェースが
飽和状態になった場合は、サンプルが失われます。
f SignalTap II エンベデッド・ロジック・アナライザと協調検証について詳しくは、次の
ドキュメントを参照してください：Quartus II ハンドブック の Volume 3 の
「SignalTap II エンベデッド・ロジック・アナライザを使用したデザインのデバッグ」
の章、および 「AN323: Using SignalTap II Embedded Logic Analyzers in SOPC Builder
Systems」。
外部インスツルメンテーション
デザインがトレース・バッファを格納するための十分なオンチップ・メモリを持っ
ていない場合は、デバッグ用の外部ロジック・アナライザを使用することができま
す。次のいずれかを必要とする場合、外部インスツルメンテーションも必要です。
■
ピンの負荷を使用したデータ収集
■
複雑なトリガ
■
非同期データ・キャプチャ
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 9 章： 検証およびボード立ち上げ
検証方法
9‒9
アルテラは、FPGA にオシロスコープ、ロジック・アナライザ、およびプロトコル・
アナライザなどの外部検証デバイスを接続する手順を提供しています。
SignalProbe
SignalProbe インクリメンタル配線機能は、かなりの程度までデザインの既存の
フィットに影響を与えることなく、FPGA の出力ピンに信号をルーティングすること
ができます。ピンにデザイン階層の複数の層を介してそれらを渡すための HDL コー
ドを再書き込みすることなく、内部デバイス信号を調査するために SignalProbe を使
用することができます。手動でそのような改訂を作成すると、時間がかかり、エ
ラーが発生しやすくなります。
検証用の FPGA の内部信号経路のうちに十分なピンがある場合、アルテラは、
SignalProbe を推奨します。FPGA ピンが使用不可能な場合、次の 3 つの選択肢があり
ます。
■
SignalProbe に使用可能なより多くのピンを作るデザインによって使用されるピン
の数を低減。
■
SignalTap II エンベデッド・ロジック・アナライザを使用。
■
ロジック・アナライザ・インタフェースを使用。
検証用として使用可能なピン数を増やすためのデザインを改訂すると、デザイン変
更が必要となり、デザイン・スケジュールに影響を与える可能性があります。高い
レートでの連続サンプリングを必要としない場合、SignalTap II エンベデッド・ロジッ
ク・アナライザの使用は実行可能なソリューションになります。SignalTap II エンベ
デッド・ロジック・アナライザは、追加のピンが配線されている必要はありません
が、それを組み込むためには、デザインに十分な未割り当てロジックおよびメモリ・
リソースを持っている必要があります。これらのアプローチのいずれもが使用可能
である場合には、ロジック・アナライザ・インタフェースを使用することができま
す。
f SignalProbe について詳しくは、Quartus II ハンドブックの Volume 3 の 「Quick Design
Debugging Using SignalProbe」の章を参照してください。
ロジック・アナライザ・インタフェース
Quartus II ロジック・アナライザ・インタフェースは、外部検証のためのピンに対し
て複数のタイムドメイン多重化信号をドライブする JTAG プログラマブル方法です。
ロジカル・アナライザ・インタフェースはピンを多重化するため、ピン数の要件を
最小限に抑えることができます。信号のグループは、バンクに割り当てられていま
す。JTAG を通信チャネルとして使用すると、バンクとの間で切り替えることができ
ます。
SignalTap II エンベデッド・ロジック・アナライザが検証ニーズに不十分である場合、
このアプローチを使用する必要があります。いくつかの外部ロジック・アナライザ・
メーカーは、ロジック・アナライザ・インタフェースをサポートしています。これ
らのロジック・アナライザは、サポートの様々な量を持っています。最も重要な機
能は、自動的に信号バンクを通じて測定ツールを循環する能力です。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
9‒10
第 9 章： 検証およびボード立ち上げ
検証方法
信号バンクを循環する能力は、ロジック・アナライザに限定されません。任意の外
部測定ツールのためにそれを使用することができます。一部の開発者は検証のため
に、LED などの低速インジケータを使用しています。検証 LED の少ない数に多くの
信号のバンクをマッピングするためのロジック・アナライザ・インタフェースを使
用することができます。ユーザーの製品が展開後に低レベルのエラー・コードを作
成することができるように、最終的なデザインでは、この検証のフォームを残した
いことがあります。
f Quartus II ロジック・アナライザ・インタフェースについて詳しくは、Quartus II ハン
ドブックの Volume 3 の 「外部ロジック・アナライザを使用したイン・システム・デ
バッグ」の章を参照してください。
スティミュラスの生成
効果的にシステムをテストするには、できるだけ少ないスティミュラスでテスト・
カバレッジを最大化する必要があります。テスト・カバレッジを最大にするために
は、静的とランダムに生成されたデータを組み合わせて使用する必要があります。
静的データには、システムの標準的な機能とコーナー・ケースをテストするために
使用できる入力の固定セットが含まれています。
ランダム・テストは実行時に生成されますが、失敗事例を分析できるように、失敗
が発生したときにアクセスできる必要があります。ランダム・テストの生成は、特
に静的試験がデザインの基本的な機能を搭載した問題の大部分を同定した後に有効
です。作成したテスト・ケースでは、予期せぬ問題が明らかになることがあります。
ランダムに生成されたテスト入力は、システムの問題を発見するたび、将来のテス
トのために設定する静的なテスト・データにこれらのケースを追加する必要があり
ます。
擬似ランダム数のジェネレータ（PRNG）がパターンを繰り返す傾向にあるため、シ
ステムへの入力として使用するランダム・データを作成することは困難になる可能
性があります。ランダム・テスト・ジェネレータの PRNG を初期化するたびに、異
なるシードを選択してください。ランダム・テスト・ジェネレータが同じ値でシー
ドされている場合、同じデータ・シーケンスを作成します。
シードの生成は高度なトピックであり、本書では詳細に説明されていません。効果
的なシード値の作成の以下の推奨事項は、データ値を繰り返すことを避けるために
役立つはずです。
■
ランダム・ノイズの測定を使用します。これを行う 1 つの方法は、A/D コンバータ
のアナログ出力値を読み出すことです。
■
シード値を作成するための組み合わせで複数の非同期カウンタを使用します。
■
タイマの値をシード（つまり、時間内に定点からの秒数を表したもの）として使
用します。
シード生成のテクニックの組み合わせを使用すると、よりランダムな行動につなげ
ることができます。ランダム・シーケンスを生成する場合、生成されるランダム・
データの分布を理解することが重要です。いくつかのジェネレータは、分布が均等
にランダム数ドメインに分散されたリニア・シーケンスを作成します。他のものは、
必要とするテスト・カバレッジを提供しない場合があるノンリニア・シーケンスを
作成します。システムを検証するためにランダム数のジェネレータの使用を開始す
る前に、いくつかのシーケンス用に作成されたデータを調べます。そうすることで、
作成したパターンを理解し、入力の不適切なセットの使用を回避するのに役立ちま
す。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 9 章： 検証およびボード立ち上げ
ボード立ち上げ
9‒11
ボード立ち上げ
意図的な戦略を採用することによって、ボードの立ち上げ時間を最小限に抑えるこ
とができます。まず、管理しやすい部分にタスクをブレーク・ダウンします。ペリ
フェラルのテストから始めて、全体ではなく、セグメントでデザインを確認します。
ペリフェラルのテスト
ボードの立ち上げプロセスの最初のステップは、ペリフェラルのテストです。デザ
インに、一度に 1 つのインタフェースを追加します。ペリフェラルはユーザーがそ
れのために作成したテストに合格したら、テスト・デザインからそれを削除する必
要があります。設計者は通常、テストに合格したペリフェラルをデザインに残して
おき、他のペリフェラルをテストし続けます。場合によってこれは必要ですが、複
数のペリフェラルはノイズやクロストークに起因する不安定性を作成することがで
きるため、可能であれば、それを避ける必要があります。個別システムのペリフェ
ラルをテストすることにより、特定のインタフェースにデザインでの問題を切り分
けることができます。
任意のシステムでの一般的な障害は、メモリを伴います。最も問題のあるメモリ・
デバイスは、タイミング故障につながることがあり、高速で作動します。また、高
性能メモリは、多くのボード・トレースが正しく配線されていない場合、故障の原
因になり、データ、アドレス、およびコントロール信号を転送する必要があります。
検証ソフトウェアまたは FS2 コンソールなどのデバッガを使用してメモリ・デバイ
スを確認するために Nios II プロセッサを使用することができます。Nios II プロセッサ
は、メモリのストレス・テストに対応しませんが、それをメモリ・アドレスとデー
タ・ラインの問題を検出するために使用することができます。
f デバッグについて詳しくは、エンベデッド・デザイン・ハンドブックの 「Debugging
Nios II Designs」の章を参照してください。
データ・トレースの障害
ボード製造施設がベア・ボード・テストを実行しない場合、これらのテストを実行
する必要があります。メモリ・インタフェースのデータ・トレースの障害を検出す
るために、典型的に「walking ones」として参照されるパターンを使用します。
Walking ones パターンは、FPGA とメモリ・デバイス間のすべてのデータ・トレース
を通して論理 1 をシフトします。パターンを増加または減少させることができます。
重要な要素は、1 つだけデータ信号が、与えられた任意の時点で 1 であるということ
です。次のように、このパターンの増加バージョンがあります：1、2、4、8、16、
など。
このパターンを使用すると、短絡または開回路信号などのデータ・トレースに関す
るいくつかの問題を検出することができます。信号が偶然に別の信号に接続されて
いる場合は短絡です。信号が偶然に未接続の状態である場合は開回路です。プル
アップ抵抗またはプルダウン抵抗がトレースに接続されていない限り、開回路はラ
ンダム信号の動作になることがあります。プルアップ抵抗またはプルダウン抵抗を
使用する場合、信号は 0 または 1 をドライブします。しかし、抵抗がテストによっ
てドライブされている信号に対して相対的に弱いため、そのテスト値は、プルアッ
プ抵抗またはプルダウン抵抗を無効にします。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
9‒12
第 9 章： 検証およびボード立ち上げ
ボード立ち上げ
同じテストにおける混合潜在アドレスとデータ・トレースの問題を回避するには、
一度に 1 つのアドレス位置をテストします。テストを実行するには、メモリにテス
ト値を書き込み、これを読み返します。2 つの値が等しいことを確認した後、パター
ン内の次の値のテストに進みます。検証ステージで書き込みと読み出し値の間の変
動を検出した場合、ビット・エラーが発生しました。表 9–2 には、データ・トレー
スの障害を見つけるために使用されるプロセスの例を示します。ここでは、順次
データ・ビットが PCB 上で連続して配線されるという簡素化を仮定しています。
表 9‒2. Walking Ones の例
書き込み値
読み出し値
検出された障害
00000001
00000001
障害は検出されません。
00000010
00000000
エラー、D[1] の第 2 のデータ・ビットがスタック Low またはグラウンド
に短絡している可能性が最も高いです。
00000100
00000100
障害は検出されません。D[1] がスタック Low またはこの表に記載されて
いない別のトレースに短絡したことを確認しました。
00001000
00001000
障害は検出されません。
00010000
00010000
障害は検出されません。
00100000
01100000
エラー、D[6] および D[5] が短絡している可能性が高いです。
01000000
01100000
エラー、D[6] および D[5] が短絡したことを確認しました。
10000000
10000000
障害は検出されません。
アドレス・トレースの障害
アドレス・トレース・テストは、一つの例外を除いて、データ用に使用される
ウォーキング・テストに似ています。このテストでは、データを読み出す前にすべ
てのテストの位置に書き込む必要があります。2 のべき乗のアドレス位置を使用し
て、回路基板のすべてのアドレス・トレースをすばやく確認することができます。
アドレス・トレース・テストは、短絡または開回路がメモリ・インタフェース上に
持つことができるエイリアシング効果を検出します。このような理由から、アドレ
ス・エイリアシングを検出できるように、異なるデータ値と共にそれぞれの位置に
書き込むことが重要です。システムのアドレス・トレースを確認しながら、1、2、
3、4 などの増加番号を使用することができます。表 9–3 に、アドレス・トレースの
故障を見つけるプロセスで 2 の乗数を使用する方法を示します。
表 9‒3. 2 の累乗の例
アドレス
書き込み値
読み出し値
00000000
1
1
障害は検出されません。
00000001
2
2
障害は検出されません。
00000010
3
1
エラー、A[1] の第 2 のアドレスはスタック Low です。
00000100
4
4
障害は検出されません。
00001000
5
5
障害は検出されません。
00010000
6
6
障害は検出されません。
00100000
7
6
エラー、A[5] および A[4] は短絡です。
01000000
8
8
障害は検出されません。
10000000
9
9
障害は検出されません。
エンベデッド・デザイン・ハンドブック
検出された障害
2011 年 7 月
Altera Corporation
第 9 章： 検証およびボード立ち上げ
ボード立ち上げ
9‒13
デバイスの分離
デバイスの分離技術を使用すると、デザインが失敗する原因となる PCB 上のデバイ
スの機能をディセーブルすることができます。一般的に設計者は、PCB の早期改訂
のためのデバイスの分離を使用し、製品を出荷する前に、これらの機能を削除しま
す。
ほとんどのデザインは、デジタル・ロジックにクロック信号を作成するためにクリ
スタル・オシレータや他のディスクリート部品を使用しています。クロック信号が、
ノイズまたはジッタによって歪められている場合、障害が発生する可能性がありま
す。歪んだクロックを防ぐためには、FPGA に別のクロック・ピンをルーティンする
ことができます。ボード上に SMA コネクタが含まれている場合は、クリーンなク
ロック信号を作成するために、外部クロック・ジェネレータを使用することができ
ます。クロック関連の問題をデバッグする際に別のクロック・ソースを持つことは
非常に便利です。
場合によっては、ボード上の特定のデバイスから発生するノイズにより、他のデバ
イスやインタフェースに問題を引き起こす可能性があります。選択したコンポーネ
ントのノイズ・レベルを減少させる能力を持つことは、デザインで問題を引き起こ
しているデバイスを決定するのに役立ちます。ノイズが多いコンポーネントを分離
する最も簡単な方法は、当該デバイスの電源を除去することです。電源とピンの間
のパスに 0 オームの抵抗が含まれている場合、電源ピンの数が限られているデバイ
ス用に対応します。抵抗を除去することによって、デバイスへの電力供給を遮断す
ることができます。この戦略は、一般的にボードのパワー・プレーンに直接接続し
ている複数の電源ピンが含まれている大型のデバイスでは不可能です。
ノイズの多いデバイスから電源を除去する代わりに、多くの場合、アクティブ状態
にリセットピンをドライブすることによって、リセット状態にデバイスを配置する
ことができます。別のオプションは、それをアイドルの状態にしておくために、単
にデバイスを行使しないことです。
ノイズ電源またはグラウンド・プレーンは、シグナル・インテグリティの問題を発
生させる可能性があります。単一のボルト以下のデジタル・デバイスの代表的な電
圧スイングを頻繁に使用すると、PCB 上のデバイスの電源ノイズ・マージンは 0.2 V
と同様に短時間です。電源ノイズは、デジタル・ロジックの失敗を引き起こす可能
性があります。そのため、ボード上の電源の分離が可能である、ということが重要
です。安定した外部電源は、デザインで一時的に置換することができるように削除
されるヒューズを使用して、電源を分離することができます。
JTAG
FPGA は、プログラミング、通信、および検証用の JTAG インタフェースを使用しま
す。設計者は頻繁に FPGA、ディスクリート・プロセッサ、およびメモリ・デバイス
を含むいくつかのコンポーネントを接続し、単一の JTAG チェインを介してそれらと
通信します。場合によっては、JTAG 信号はデバイスのグループ全体の通信障害の原
因となって、電気ノイズによって歪んでいます。安定した接続を保証するには、同
じ JTAG チェイン内の他のデバイスからテスト対象の FPGA を分離する必要がありま
す。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
9‒14
第 9 章： 検証およびボード立ち上げ
ボード立ち上げ
図 9–4 a は、3 つのデバイスを持つ JTAG チェインを示しています。tdi ピンと tdo ピ
ンの信号は、各デバイス間に 0 オームの抵抗があります。適切な抵抗を除去するこ
とによって、それが図 9–4 b に示すようにチェイン内の単一のデバイスを分離するこ
とが可能です。この技術によって、単一の JTAG チェインを使用しているときに 1 つ
のデバイスを分離することができるようになります。
図 9‒4. JTAG の分離
JTAG Header
tdi
JTAG Header
tdo
tdi
tdo
(de-populated
resistor pads)
R0
tdo
tdo
Device1
Device1
R0*
tdi
tdi
R0
R0
R0*
tdo
tdo
FPGA
FPGA
R0
R0*
tdi
tdi
tdo
tdo
R0
R0*
Device3
Device3
R0
tdi
tdi
Figure 2a
Three Device JTAG Chain
R0
Zero Ohm Resistor
R0* Zero Ohm Resistor Stuff Option
Figure 2b
Device 2 Isolated From JTAG Chain
tdi = test data in
tdo = test data out
Serial Data Flow
f JTAG について詳しくは、「AN39: IEEE 1149.1(JTAG) Boundary-Scan Testing in Altera
Devices」を参照してください。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 9 章： 検証およびボード立ち上げ
ボード立ち上げ
9‒15
ボード・テスト
シミュレーションとハードウェアのバージョンが同じ動作を示すことを確認するた
めに、ハードウェア上で後に実行できるベクトルをテストするための製作前に、IP
（Intellectual Property）を確認するために実行するシミュレーションを変換する必要が
あります。また、製造業は定期的にスケジュールされた品質保証のテストの一環と
して、これらのテストを使用することができます。テストは他の組織のエンジニア
によって運営されていますので、それらは、文書化し、実行しやすくする必要があ
ります。
最小限のテスト・システム
FPGA での最初のエンベデッド・システムを作成している、または複雑な問題をデ
バッグしているかどうかは、常に最小限のシステムで始まらなければなりません。
シグナル・インテグリティの問題の可能性を最小限にするために、システムのピン
数を必要なピンの絶対的な最小限の数まで減らすことができます。Nios II プロセッ
サを含むエンベデッド・デザインでは、最小限のピン数は、クロック信号とリセッ
ト信号になる可能性があります。このようなシステムでは、次のコンポーネントが
含まれている場合があります。
2011 年 7 月
■
Nios II プロセッサ（レベル 1 のデバッグ・コアを持つ）
■
オンチップ・メモリ
■
JTAG UART
■
システム ID コア
Altera Corporation
エンベデッド・デザイン・ハンドブック
9‒16
第 9 章： 検証およびボード立ち上げ
ボード立ち上げ
これらの 4 つのコンポーネントを使用すると、デバッグおよびターミナル・アクセ
スを含むエンベデッド・システムを作成することができます。デバッグ・プロセス
を簡素化するには、データ・キャッシュが含まれていない Nios II プロセッサを使用
する必要があります。Nios II/e と Nios II/s コアには、データ・キャッシュが含まれて
いません。また、Nios II/f コアは、データ・キャッシュなしでコンフィギュレーショ
ンできます。図 9–5 に、最小限のシステムを示します。このシステムでは、JTAG 信
号は Quartus II ソフトウェアによって自動的に接続されているため、クロック・ピン
とリセット・ピンのみ配線する必要があります。
図 9‒5. シンプル・テスト・システム
JTAG
JTAG Debug Module
JTAG
UART
Nios II Processor
System Interconnect Fabric
On-Chip
Memory
SysID
Device Under
Test (DUT)
プロセッサにソフトウェアをダウンロードする Nios II JTAG デバッグ・モジュールを
使用することができます。追加のインタフェースをテストする前に、ユーザーの最
小限のシステムが正常に機能していることを確認するために、ターミナルにメッ
セージを出力する小さなプログラムを実行する必要があります。
シンプル・テスト・システムが正常に機能することを確認した後、デザインをアー
カイブします。このデザインでは、検証が進むにつれて、追加のコンポーネントを
追加することで安定した出発点を提供します。このシステムでは、テストのために
次のいずれかを使用することができます。
■
Nios II プロセッサ
■
Nios II JTAG デバッグ・モジュールおよび FS2 コンソール
■
SignalTap II エンベデッド・ロジック・アナライザ
■
外部ロジック・インタフェース
■
SignalProbe
■
ダイレクト・メモリ・アクセス（DMA）エンジン
■
メモリおよび定数のインシステム・アップデート
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 9 章： 検証およびボード立ち上げ
ボード立ち上げ
9‒17
Nios II プロセッサは、ストレス・テストの高速メモリ・デバイスに対応していませ
ん。アルテラは、メモリをストレス・テストする DMA エンジンを使用することを推
奨します。ストレス・テストは、連続的のリードまたはライトを実行し、可能な限
り頻繁にメモリにアクセスする必要があります。典型的には、高速メモリにとって
最も問題のアクセス・シーケンスには、リードおよびライト・アクセスの間のバス・
ターンアラウンドを伴います。図 9–6 に示すように、DMA のリードおよびライトの
マスタを同じメモリに接続し、ある場所から別の場所まで内容を転送することに
よって、これらのケースをテストすることができます。
図 9‒6. メモリ・デバイスをストレス・テストする DMA の使用
Memory
Read Section
Read
Master
Slave
Port
DMA
Write
Master
Write Section
メモリ接続に対する各マスタのアービトレーション・シェア値を変更することによ
り、シーケンスを制御することができます。リードとライトを交互にするために、
各 DMA マスタ・ポートごとに 1 つのアービトレーション・シェアを使用することが
できます。2 つのライトに続いて 2 つのリードを実行するには、各 DMA マスタ・
ポートに 2 つのアービトレーション値を使用します。より複雑なアクセス・シーケ
ンスを作成するために、カスタム・マスタを作成したり、テストに使用したハード
ウェアを作成する Nios II C2H コンパイラを使用することができます。
f この項で説明されているトピックについて詳しくは、以下のドキュメントを参照し
てください。
2011 年 7 月
■
Nios II Hardware Development Tutorial
■
アルテラ・ウェブサイトの「Quartus II Verification Methods」のウェブ・ページ
■
Quartus II ハンドブック Volume 5 の「DMA コントローラ・コア」の章
■
Quartus II ハンドブック Volume 3 の「メモリおよび定数のインシステム・アップ
デート」の章
Altera Corporation
エンベデッド・デザイン・ハンドブック
9‒18
第 9 章： 検証およびボード立ち上げ
システム検証
システム検証
システム検証は、システム・デザインの最後のステップです。この項では、設計者
がシステム検証とメソッドの時によくやる間違いの修正と回避に焦点を当てていま
す。それは、以下のトピックスで構成されています。
■
「検証を考慮したデザイン」
■
「検証の高速化」
■
「ハードウェアを確認するためのソフトウェアの使用」
■
「環境テスト」
検証を考慮したデザイン
ユーザは、デザインに際して開発タスクおよび検証戦略の両方に焦点を当てる必要
があります。そうすると、デザインが検証のために容易になります。大規模で複雑
なロジックのブロックを作成し、テスト前に HDL コードが完了するまで待機する場
合、一度に 1 セクションのデザイン検証をする場合よりも多くの時間を検証に費や
すことになります。
デザインの個々のセクションが働いている後に検証コードで残しておくことを考慮
します。あまりにも多くの検証ロジックを削除する場合、必要に応じて後でそれを
再導入することが非常に困難になります。システム統合時に問題を発見した場合、
より小さいブロック・デザインのいくつかの再検討が必要な場合があります。小さ
いブロックの 1 つを変更した場合、追加の問題が発生していないことを確認するた
めにそれを再テストする必要があります。
検証を考慮したデザインでは、デザイン内に検証フックを残すことは制限されませ
ん。適切な検証を実行するための十分なハードウェア・リソースを確保することも
重要です。以下の推奨事項は、ハードウェア・リソースの不足を防ぐために役立ち
ます。
■
より大型のピン互換性を持つ FPGA を使用してデザインと検証をします。
■
デザイン計画の検証のためのハードウェア・リソースを予約します。
■
オプションの機能が検証リソースを解放するために除去することができるように
ロジックをデザインします。
最後に、ハードウェアまたはソフトウェアのコンパイルの間にテスト・カバレッジ
を向上させるために、回帰テストを毎晩実施します。
検証の高速化
アルテラは、図 9–7 に示す検証フローを推奨しています。各コンポーネントをそれ
が開発されたように確認します。検証されているロジックの量を最小限に抑えるこ
とによって、デザインをコンパイルしてシミュレーションするのにかかる時間を大
幅に短縮できます。結果的に、デザイン上の問題を修正するための反復時間を最小
限に抑えます。
個々のコンポーネントが検証された後、SOPC Builder システムにそれらを統合するこ
とができます。統合されたシステムには、Avalon-MM または Avalon Streaming
（Avalon-ST）のポートが含まれている必要があります。SOPC Builder から使用可能なコ
ンポーネント・エディタを使用して、既存のコンポーネントに Avalon-MM インタ
フェースを追加し、システムにそれを統合します。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 9 章： 検証およびボード立ち上げ
システム検証
9‒19
システムが SOPC Builder で作成された後、システム全体の検証プロセスを続行するこ
とができます。典型的には、検証プロセスは、次の 2 つのステップがあります。
1. シミュレーションした後に生成します。
2. ハードウェアで生成、コンパイル、そして確認をします。
最初のステップは、システム内の信号への容易なアクセスを提供します。シミュ
レーションが正常に機能しているときは、ハードウェアに検証を移動することがで
きます。ハードウェアがシミュレーションよりも桁違いに高速であるため、実際の
ハードウェア上でテスト・ベクタを実行することで時間を節約できます。
図 9‒7. IP の検証と統合フロー
Hardware Project A
Develop
IP Block
A
Verify IP
Block A
Create SOPC
Builder Ready
Component
Hardware Project B
Develop
IP Block
B
Verify IP
Block B
Main Hardware Project
Create SOPC
Builder Ready
Component
Architect
System
Verify
System
Hardware Project C
Develop
IP Block
C
Verify IP
Block C
Create SOPC
Builder Ready
Component
Fast Compilation, Many Interations
Slow Compilation, Fewer Interations
f コンポーネント・エディタとシステム統合について詳しくは、次のドキュメントを
参照してください。
2011 年 7 月
■
SOPC Builder User Guide の「Component Editor」の章
■
SOPC Builder User Guide の「SOPC Builder Component Development Walkthrough」の章
■
Avalon Interface Specifications
Altera Corporation
エンベデッド・デザイン・ハンドブック
9‒20
第 9 章： 検証およびボード立ち上げ
システム検証
ハードウェアを確認するためのソフトウェアの使用
多くのハードウェア開発者は、シミュレーションでそのロジックを検証するために
テストベンチやテスト・ハーネスを使用しています。これらの戦略は、非常に時間
がかかることがあります。すべての検証作業用のシミュレーションに頼るの代わり
に、図 9–8 で示すように、ソフトウェアまたはスクリプトを使用してロジックをテ
ストすることができます。
このシステムは、システム・インタコネクト・ファブリックに接続されたコンポー
ネントにアクセスしたり、システムのスティミュラスを作成するために、JTAG イン
タフェースを使用しています。また、Quartus II プログラマが提供する JTAG サーバを
使用する場合、このシステムは、ネットワーク上に配置して、リモートでアクセス
することができます。Nios II IDE を使用して、Nios II プロセッサにソフトウェアをダ
ウンロードすることができます。また、ホスト・ファイル・システムを使用して、
エンベデッド・システムとの間でファイルを往復送信する Nios II JTAG デバッグ・コ
アを使用することができます。システム・コンソールを使用すると、システム内の
コンポーネントにアクセスすることができ、自動テストの目的のためにスクリプト
を実行することができます。
Quartus II In-System Memory Content Editor を使用すると、外部ペリフェラルを制御する
2 つのコンポーネントのためのスティミュラスを作成することができます。また、新
しいスティミュラス値がシステムに送信されるときに、リセットでエンベデッド・
システムを配置するために In-System Memory Content Editor を使用することができま
す。In-System Memory Editor は、検証プロセスを自動化するために使用できる Tcl ス
クリプティングをサポートしています。このアプローチでは、システム内のロジッ
クを制御するために、FS2 コンソールを使用するのと同様です。しかし、FS2 のコン
ソールとは異なり、メモリ・マップされていないハードウェアにアクセスするため
に、In-System Memory Content Editor を使用することができます。この章で説明したす
べての検証技術は、多くのテスト・サイクルがユーザーとのやりとりなしで実行で
きるように、スクリプト化できます。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 9 章： 検証およびボード立ち上げ
システム検証
9‒21
f ホスト・ファイル・システムを使用する方法について詳しくは、Nios II EDS で使用可
能な Host File System のソフトウェア・デザイン例を参照してください。エンベデッ
ド・デザイン・ハンドブックの 「Developing Nios II Software」の章では、システムの
ファイル・システムに関する非常に多くの情報が含まれています。
図 9‒8. スクリプト制御の検証
SOPC Builder System
JTAG
Interface
JTAG Debug
Module
Constant
(Reset Hold)
reset_n
JTAG to
Avalon
Master Bridge
Nios II
Processor
SignalTap II
Embedded
Logic Analyzer
System Interconnect Fabric
Onchip
Memory
System Console
A/D
Interface
Temperature
Sensor
or
FS2 Console
or
Nios II IDE
Memory
Based
FIFO
(Stimulus )
or
Quartus II
In-System
Memory
Content Editor
Constant
(Stimulus )
FS2 Console Controlled
In-System Memory Content Editor Controlled
SignalTap II Trace
JTAG Communication Channels
f 上記の例で説明した検証とスクリプトの能力について詳しくは、次のドキュメント
を参照してください。
2011 年 7 月
■
アルテラ・ウェブサイトの「Basic Quartus II Software Tcl Scripting」のトレーニン
グ・コースのウェブ・ページ。
■
Quartus II Scripting Reference Manual
Altera Corporation
エンベデッド・デザイン・ハンドブック
9‒22
第 9 章： 検証およびボード立ち上げ
改訂履歴
環境テスト
検証の最終ステージでは、エンド・ユーザー環境のテストです。ほとんどの検証が
理想的な条件で行われます。エンド・ユーザーの環境の以下の条件では、システム
が失敗する可能性があります。
■
電圧変動
■
振動
■
温度変動
■
電気ノイズ
特定の製品用のすべてのアプリケーションを予測することは困難であるため、製品
をデザインする前に、動作仕様のリストを作成する必要があります。製品を出荷、
または販売する前に、これらの仕様を確認する必要があります。環境テストとの重
要な問題は、テストの進行中に測定値を取得することに関連する難しさです。例え
ば、製品が振動テストを受けている間に外部ロジック・アナライザで信号を測定す
ることは困難です。
早期検証のステージでは、ハードウェア・デザインをテストするためのメソッドを
選択しながら、環境テストのためにそれらを適合させる方法を検討する必要があり
ます。製品が振動の問題の影響を受けやすいと思われる場合、メモリ・インタ
フェースをテストするときには、頑丈なインスツルメンテーションの方法を選択す
る必要があります。あるいは、製品が電気ノイズの影響を受けやすいと思われる場
合、デバッグの目的のための信頼性の高いインタフェースを選択する必要がありま
す。
デザインの早期検証を実行している間、エンド環境テストを開始することもできま
す。そうすることで、デザイン・プロセスの初期段階で潜在的な欠陥を検出するの
に役立ちます。例えば、温度変動をテストする場合、テストしている間に、製品に
ヒート・ガンを使用することができます。電圧変動テストを実行する場合、システ
ム内の電源を分離し、外部電源を使用して電圧を変化させます。これらの検証技術
を使用して、環境テスト中の障害に起因する遅い時期でのデザイン変更を回避する
ことができます。
改訂履歴
表 9–4 に、このドキュメントの改訂履歴を示します。
表 9‒4. 改訂履歴
日付
2011 年 7 月
2008 年 11 月
バー
ジョン
1.3
1.2
変更内容
■
参照先を更新。
■
FS2 コンソールのセクションでは、メモリ・アドレスの範囲を書き読みする sld
info コマンドおよび例を追加。
■
システム・コンソールに入門的議論を追加。
■
図 9–8 に Avalon マスタ・ブリッジへの JTAG を追加。
2008 年 6 月
1.1
目次を補正。
2008 年 3 月
1.0
初版。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
10. アルテラ FPGA への外部プロセッ
サの接続
7? 2011?
ED51011-1.1
ED51011-1.1
この章では、アルテラ FPGA または Hardcopy® デバイスに外部プロセッサを接続する
ために Altera® が提供するオプションの概要について説明します。これらのインタ
フェースのオプションには、PCI Express、PCI、RapidIO®、シリアル・ペリフェラル・
インタフェース（SPI）または独自にデザインできる簡単カスタム・ブリッジが含ま
れています。
システム内に FPGA と市販のプロセッサの両方を含めることで、次の方法で、性能と
コストを最適化するためのデザインをパーティションすることができます。
■
外部プロセッサにデータの前処理および後処理をオフロードします。
■
コプロセッシング・データのために専用の FPGA リソースを作成します。
■
業界標準機能のためのペリフェラル拡張を実装するコンポーネントのアルテラの
ライブラリからの IP を使用して設計時間を短縮します。
■
外部プロセッサの I/O 機能を展開します。
© 2011 年 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, HARDCOPY, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and
logos are trademarks of Altera Corporation and registered in the U.S. Patent and Trademark Office and in other countries. All other words and logos identified as
trademarks or service marks are the property of their respective holders as described at www.altera.com/common/legal.html. Altera warrants performance of its
semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to any products and
services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any information, product, or service
described herein except as expressly agreed to in writing by Altera. Altera customers are advised to obtain the latest version of device specifications before relying
on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Feedback Subscribe
10‒2
第 10 章： アルテラ FPGA への外部プロセッサの接続
MegaWizardTM Plug-In Manager または SOPC Builder デザイン・フローのいずれかを使用
して PCI Express、PCI、および RapidIO MegaCore ファンクションをインスタンス化す
ることができます。PCI Lite と SPI コアは、SOPC Builder デザイン・フローでのみ使用
可能です。SOPC Builder は自動的に指定されたコンポーネントとシステムの接続を含
む HDL デザイン・ファイルを生成します。代わりに、SOPC Builder の外にスタンドア
ロン・コンポーネントを生成するために MegaWizard Plug-In Manager を使用すること
ができます。図 10–1 は、デザイン・フローの両方のコンポーネントをインスタンス
化するための手順を示しています。
図 10‒1. SOPC Builder および MegaWizard Plug-In Manager のデザイン・フロー
Select Design Flow
SOPC Builder
Flow
MegaWizard Plug-in
Manager Flow
Specify Parameters
Specify Parameters
Simulate with
Testbench
Complete SOPC
Builder System
Instantiate MegaCore
Function in Design
Simulate System
Specify Constraints
Compile Design
Program Device
この章の残りの部分では、アルテラ FPGA を外部プロセッサに接続するために使用で
きる MegaCore ファンクションの概要について説明します。それは、次のトピックに
ついて説明します。
■
「コンフィギュレーション・オプション」
■
「RapidIO インタフェース」
■
「PCI Express インタフェース」
■
「PCI インタフェース」
■
「PCI Lite インタフェース」
■
「SPI（シリアル・プロトコル・インタフェース）」
■
「カスタム・ブリッジ・インタフェース」
外部メモリ・インタフェース・ハンドブック
Volume 2：デザイン・ガイドライン
2011 年 7 月
Altera Corporation
第 10 章： アルテラ FPGA への外部プロセッサの接続
コンフィギュレーション・オプション
10‒3
コンフィギュレーション・オプション
図 10–2 は、FPGA 内部の MegaCore ファンクションに外部インタフェースの業界標準
のプロセッサを接続するための高性能な外部バスまたはスイッチを含む、SOPC
Builder システム・デザインを示しています。また、この MegaCore ファンクションに
は、SOPC Builder システム・インタコネクト・ファブリックに接続する Avalon-MM マ
スタ・ポートが含まれています。図 10–2 に示すように、アルテラは、Avalon システ
ム・インタコネクト・ファブリックにシームレスに接続するコンポーネントとして、
通常は Avalon-MM スレーブ・デバイスのライブラリを提供します。
図 10‒2. ペリフェラル拡張用のバスまたはスイッチ・インタフェースのブリッジを搭載した FPGA
Altera FPGA or Hardcopy Device
Processor
Bus or Switch
Interface
Component
(PCIe or RIO)
M
DMA
On-Chip
Memory
M
S
System Interconnect Fabric
M
S
2011 年 7 月
Avalon-MM Master
Avalon-MM Slave
Altera Corporation
S
Memory
Controller
S
S
S
S
UART
User I/O
USB
Timer
外部メモリ・インタフェース・ハンドブック
Volume 2：デザイン・ガイドライン
10‒4
第 10 章： アルテラ FPGA への外部プロセッサの接続
コンフィギュレーション・オプション
図 10–3 は、FPGA 内の PCI Express エンドポイントに接続する外部プロセッサを含む
デザインを示しています。内部のシステム・インタコネクト・ファブリックは、外
部プロセッサに接続するエンドポイントと、イーサネット・カードおよびマーキン
グ・エンジンと接続する 2 つの追加の PCI Express ルート・ポートの間の部分的なク
ロスバー・スイッチを実装します。さらに、このシステムには、いくつかのカスタ
ム・ロジック、外部 DDR SDRAM メモリに接続するメモリ・コントローラ、USB イン
タフェース・ポート、および外部フラッシュ・メモリへのインタフェースが含まれ
ています。SOPC Builder は、システム内のコンポーネントを接続するために自動的に
システム・インタコネクト・ファブリックを生成します。
図 10‒3. ペリフェラル拡張のためのプロセッサ・バスまたは SPI を備えた FPGA
Stratix IV GX Device
PCIe
Hard IP
Custom
Logic
M
M
RP
PCIe
Hard IP
PCIe
Hard IP
Processor
PCI Link
RP
EP
System
Interconnect
Fabric
M
BAR0-1
PCIe
Hard IP
S
M
BAR0-1
BAR2
BAR3
M
S
Avalon-MM Master
Avalon-MM Slave
Ethernet
S
S
RP
S
S
BAR3
Memory
Controller
Marking
Engine
BAR2
S
S
USB
Flash
Cntl
Flash
DDR
SDRAM
外部メモリ・インタフェース・ハンドブック
Volume 2：デザイン・ガイドライン
2011 年 7 月
Altera Corporation
第 10 章： アルテラ FPGA への外部プロセッサの接続
コンフィギュレーション・オプション
10‒5
別の方法としては、SOPC Builder を使用せずに、Verilog HDL または VHDL でロジック
を実装することができます。図 10–4 は、プロセッサへのインタフェースを実装する
ために第 2 のモジュールでコプロセッシング用の FPGA を使用して、モジュラー・デ
ザインを示しています。このオプションを選択した場合、システムにモジュールを
接続するためのすべての HDL を記述する必要があります。
図 10‒4. コプロセッシングを実行する FPGA
Altera FPGA or HardCopy Device
Direct
I/F
Processor
Co-Processing
Implemented in
Verilog HDL or
VHDL
表 10–1 に、外部プロセッサにアルテラ FPGA または HardCopy デバイスを接続するた
めにアルテラが提供するコンポーネントをまとめます。この表が示すように、次の 3
つのコンポーネントは、SOPC Builder に加えて MegaWizard Plug-In Manager のデザイ
ン・フローにも使用可能です。これらのコンポーネントの代替の実装は、Altera
Megafunction Partners Program（AMPPSM）パートナを通じて使用することもできます。
AMPP パートナは、アルテラ・デバイス用に最適化されたメガファンクションの幅広
いポートフォリオを提供しています。
f アルテラ FPGA 用のサードパーティ IP の完全なリストについて詳しくは、アルテラ・
ウェブサイトの 「Intellectual Property & Reference Designs」の Web ページを参照してく
ださい。SOPC Builder コンポーネントについては、IP MegaStore メガファンクション
の検索機能で sopc_builder_ready を検索してください。
.
表 10‒1. アルテラ・デバイスから使用可能なプロセッサ・インターフェイス・ソリュー
ション
SOPC Builder
で使用可能
MegaWizard
Plug-In
Manager で使用
可能
サードパー
ティ・ソ
リューション
使用可能な
OpenCore Plus
評価機能
RapidIO
v
v
v
v
PCI Express
v
v
v
v
PCI
v
v
v
v
PCI Lite
v
—
—
SPI
v
—
—
ライセンスは必
要ありません
プロトコル
2011 年 7 月
Altera Corporation
外部メモリ・インタフェース・ハンドブック
Volume 2：デザイン・ガイドライン
10‒6
第 10 章： アルテラ FPGA への外部プロセッサの接続
RapidIO インタフェース
表 10–2 は、業界標準のプロセッサを含む、SOPC Builder システムにおけるペリフェ
ラル拡張のための最も人気のあるオプションをまとめたものです。これらは、SOPC
Builder で使用可能です。いくつかは、MegaWizard Plug-In Manager も使用可能です。
表 10‒2. SOPC Builder で使用可能なペリフェラル・インタフェースの部分的なリスト
SOPC Builder
で使用可能
MegaWizard
Plug-In Manager
で使用可能
サードパーティ・
ソリューション
使用可能な
OpenCore Plus
評価機能
CAN
v
—
v
v
I2C
v
—
v
v
Ethernet
v
v
v
v
PIO
v
—
—
不要
POS-PHY Level 4 (SPI 4.2)
—
v
—
v
SPI
v
—
v
不要
UART
v
—
v
v
USB
v
—
v
v
プロトコル
f SOPC Builder での使用可能なコンポーネントについて詳しくは、
「Embedded Peripherals
IP User Guide」参照してください。
1
いくつかのケースでは、OpenCore Plus を使用してペリフェラルを評価することがで
きる前に、AMPP のベンダの Web サイトから、サードパーティの IP ソリューション
をダウンロードする必要があります。
「AN343: OpenCore Evaluation
f AMPP プログラムおよび OpenCore Plus について詳しくは、
of AMPP Megafunctions」および 「AN320: OpenCore Plus Evaluation of Megafunctions」を参
照してください。
以下の項では、外部プロセッサへの接続に使用できる高性能なインタフェースにつ
いて説明します。
RapidIO インタフェース
RapidIO は、プロセッサ、メモリ、およびペリフェラルの間のデータと制御情報を転
送する高性能パケット交換プロトコルです。RapidIO MegaCore ファンクションは、
SOPC Builder で使用可能であり、Serial RapidIO トランザクションを Avalon-MM トラン
ザクションに変換する Avalon-MM ポートが含まれています。また、MegaCore ファン
クションには、トランスポート層からシステム・インタコネクト・ファブリックに
直接トランザクションを送信するために使用できるオプションの Avalon Streaming
（Avalon-ST）インタフェースが含まれています。すべてのオプション機能を選択する
と、コアには、次のポートが含まれています。
■
Avalon-MM I/O ライト・マスタ
■
Avalon-MM I/O リード・マスタ
■
Avalon-MM I/O ライト・スレーブ
■
Avalon-MM I/O リード・スレーブ
■
Avalon-MM メンテナンス・マスタ
外部メモリ・インタフェース・ハンドブック
Volume 2：デザイン・ガイドライン
2011 年 7 月
Altera Corporation
第 10 章： アルテラ FPGA への外部プロセッサの接続
RapidIO インタフェース
10‒7
■
Avalon-MM システム・メンテナンス・スレーブ
■
Avalon Streaming シンク・パススルー TX
■
Avalon-ST ソース・パススルー RX
SOPC Builder デザイン・フローを使用すると、SOPC Builder システム内の RapidIO エン
ドポイントを統合することができます。SOPC Builder の System Contents タブを使用
してポートを接続し、SOPC Builder が自動的にシステム・インタコネクト・ファブ
リックを生成します。図 10–5 は、プロセッサと RapidIO MegaCore ファンクションを
含む SOPC Builder システムを示しています。
図 10‒5. RapidIO インタフェースを使用したシステムの例
Processor
Serial RapidIO Switch
FPGA
RapidIO MegaCore Function
Physical Layer
Transport Layer
Logical Layer
Src
M
Snk
S
M
S
M
S
System Interconnect Fabric
2011 年 7 月
M
Avalon-MM Master I/F
M
Avalon-MM Slave I/F
Src
Avalon Streaming Source I/F
Snk
Avalon Streaming Sink I/F
Altera Corporation
Memory
Controller
S
Flash
Cntl
S
S
S
UART
USB
User I/O
外部メモリ・インタフェース・ハンドブック
Volume 2：デザイン・ガイドライン
10‒8
第 10 章： アルテラ FPGA への外部プロセッサの接続
PCI Express インタフェース
f Rapid IO インタフェースをサポートするプロセッサの一覧については、
www.rapidio.org での RapidIO Trade Association の Web サイトの製品リストを参照して
ください。
f RapidIO MegaCore ファンクションの完全な説明について詳しくは、次のドキュメント
を参照してください。
■
RapidIO MegaCore Function User Guide
■
AN513: RapidIO Interoperability With TI 6482 DSP Reference Design
PCI Express インタフェース
SOPC Builder デザイン・フローを使用してコンフィギュレーションされたアルテラの
PCI Express 用の IP コンパイラは、システム・インタコネクト・ファブリックへの
PCI Express 用の IP コンパイラのコンポーネントを接続するために PCI Express 用の IP
コンパイラの Avalon ブリッジ・モジュールを使用しています。ブリッジは AvalonMM インタフェースを使用する PCI Express システムのデザインが SOPC Builder コン
ポーネントに容易にアクセスできるようにします。図 10–6 は、PCI Express 用の IP
Compiler を使用して、SOPC Builder システムに外部プロセッサをリンクするデザイン
を示しています。
また、MegaWizard Plug-In Manager デザイン・フローを使用して PCI Express 用の IP コ
ンパイラを実装することができます。2 つのデザイン・フローのためのコンフィギュ
レーション・オプションが異なります。PCI Express 用の IP コンパイラは、ハード IP
の実装として Stratix IV および Arria II GX デバイスで使用可能で、ルート・ポートまた
はエンドポイントとして使用することができます。Stratix V デバイスでは、アルテラ
は PCI Express 用の Stratix V ハード IP を提供しています。
f PCI Express 用の IP コンパイラの使用方法について詳しくは、
以下のドキュメントを参
照してください。
■
IP Compiler for PCI Express User Guide
■
AN532: An SOPC Builder PCI Express Design with GUI Interface
■
AN456: PCI Express High Performance Reference Design
■
AN443: External PHY Support in PCI Express MegaCore Functions
■
AN431: PCI Express to External Memory Reference Design
外部メモリ・インタフェース・ハンドブック
Volume 2：デザイン・ガイドライン
2011 年 7 月
Altera Corporation
第 10 章： アルテラ FPGA への外部プロセッサの接続
PCI インタフェース
10‒9
図 10–6 に、外部プロセッサは、PCI Express リンクを介してアルテラ FPGA と通信す
るシステムの例を示します。
図 10‒6. PCI Express インタフェースを使用したシステムの例
Processor
PCI Express Link
FPGA
PCI Express MegaCore Function
Physical Layer
Data Link Layer
Transaction Layer
Avalon-MM Adapter
S
M
System Interconnect Fabric
M
Avalon-MM Master I/F
M
Avalon-MM Slave I/F
Memory
Controller
S
S
S
S
Flash
Cntl
UART
USB
User I/O
PCI インタフェース
アルテラは、FPGA にホスト・プロセッサを接続するために使用できる PCI ローカ
ル・バスの幅広いソリューションを提供しています。ユーザーは、MegaWizardPlug-In
Manager または SOPC デザイン・フローを使用して PCI MegaCore ファンクションを実
装することができます。
2011 年 7 月
Altera Corporation
外部メモリ・インタフェース・ハンドブック
Volume 2：デザイン・ガイドライン
10‒10
第 10 章： アルテラ FPGA への外部プロセッサの接続
PCI Lite インタフェース
PCI SOPC Builder フローは、Avalon-MM プロトコルに熟知することなく、システムの
機能を拡張するためのペリフェラルを含む完全な Avalon-MM システムを実装するの
に簡単な方法です。図 10–7 に、PCI MegaCore ファンクションを使用して、SOPC
Builder システムを示します。32 ビットまたは 64 ビットのインタフェース で PCI
MegaCore ファンクションをパラメータ化することができます。
図 10‒7. SOPC Builder システム内の PCI MegaCore ファンクション
Altera FPGA or HardCopy Device
PCI Master/Target
Component
DDR2
SDRAM
MegaCore
Function
PCI
Bus
PCI
MegaCore
Function
PCI-Avalon
Bridge
Logic
DDR2
SDRAM
Memory
Module
System
Interconnect
Fabric
DMA
Engine
f 詳細は、「PCI Compiler User Guide」を参照してください。
PCI Lite インタフェース
PCI Lite のコンポーネントは、ロー・レイテンシと高スループットのデザイン用に最
適化されています。これは、SOPC Builder デザイン・フローのみに使用可能です。PCI
Lite コアは、FPGA でシステム・インタコネクト・ファブリックに接続されたプロ
セッサやその他のペリフェラルへ接続するロー・レイテンシ・パスを取得するため
の PCI MegaCore ファンクション機能セットのサブセットを提供します。このコン
ポーネントは、PCI トランザクションを Avalon-MM トランザクションに変換します。
PCI Lite コアは、システム・インタコネクト・ファブリックに PCI バスを接続するた
めの PCI-Avalon ブリッジを使用して、1 つ以上の SOPC Builder コンポーネントを含む
単純な PCI システムを簡単に作成できるようにします。
f 詳細は、Embedded Peripherals IP User Guide の「PCI Lite Core」の章を参照してください。
また、MegaWizard Plug-In Manager デザイン・フローを使用して、Avalon-MM ブリッ
ジ・モジュールなしで元の PCI マスタ / ターゲットおよびターゲット MegaCore ファ
ンクションを実装することができます。
f 詳細は、「AN223: PCI-to-DDR SDRAM Reference Design」を参照してください。
外部メモリ・インタフェース・ハンドブック
Volume 2：デザイン・ガイドライン
2011 年 7 月
Altera Corporation
第 10 章： アルテラ FPGA への外部プロセッサの接続
SPI（シリアル・プロトコル・インタフェース）
10‒11
SPI（シリアル・プロトコル・インタフェース）
Avalon マスタ・ブリッジ・コンポーネントへの SPI スレーブは、4 線式の業界標準の
シリアル・インタフェースを介してプロセッサと SOPC Builder システムの間の単純な
接続を提供します。ホスト・システムは、コアのシリアル・インタフェースを介し
てバイトの符号化ストリームを送信することによって、Avalon-MM トランザクション
を開始することができます。コアは、メモリ・アクセスとペリフェラル拡張のため
の SOPC Builder システムへのトランザクションのリードとライトをサポートします。
Avalon マスタ・ブリッジへの SPI スレーブは、任意の SOPC Builder システムに容易に
統合する SOPC Builder 対応コンポーネントです。SPI インタフェースを含むプロセッ
サは、Embedded Peripherals IP User Guide の Avalon Master Bridge Cores の章で概説され
ているプロトコルを使用して、リードおよびライトのための Avalon-MM トランザク
ションを簡単にカプセル化することができます。
図 10‒8. Avalon-MM インタフェース・コンポーネントへの SPI を使用したシステムの例
Altera FPGA
Processor
MOSI
SPI
MISO
SPI to
Avalon-MM
SPI IF Component
M
DMA
On-Chip
Memory
M
S
System Interconnect Fabric
M
S
Avalon-MM Master
Avalon-MM Slave
Memory
Controller
S
S
S
S
UART
UART
USB
User I/O
f 各プロトコル・レイヤの詳細は、Embedded Peripherals IP User Guide の次の章に記載さ
れています。
Avalon マスタ・ブリッジ・コアへの SPI スレーブ /JTAG — 外部のホスト・システム
から SOPC Builder システムへの接続を提供します。SPI マスタが Avalon-MM トランザ
クションを開始できるようにします。
パケットへの Avalon-ST バイト、およびバイト・コンバータ・コアへのパケット —
外部のホスト・システムから SOPC Builder システムへの接続を提供します。SPI マス
タが Avalon-ST トランザクションを開始できるようにします。
トランザクション・コンバータ・コアへの Avalon パケット — アップストリーム・コ
ンポーネントからストリーミング・データを受信し、Avalon-MM トランザクションを
開始します。要求するコンポーネントに Avalon-MM トランザクション応答をリター
ンします。
2011 年 7 月
Altera Corporation
外部メモリ・インタフェース・ハンドブック
Volume 2：デザイン・ガイドライン
10‒12
第 10 章： アルテラ FPGA への外部プロセッサの接続
カスタム・ブリッジ・インタフェース
f 「SPI Slave to Avalon Master Bridge Design Example」は、Avalon-MM ホスト・システムとリ
モート SPI システムの間の SPI トランザクションを示しています。
カスタム・ブリッジ・インタフェース
多くのバス・プロトコルは、直接またはインタフェース規格間の違いを補正するた
めにのいくつかのカスタム・ブリッジ・インタフェース・ロジックを使用して、シ
ステム・インタコネクト・ファブリックにマッピングすることができます。SOPC
Builder がサポートする Avalon-MM インタフェース規格は、カスタム・ブリッジを作
成するのが簡単な同期のメモリ・マップされたインタフェースです。
必要な場合は、速やかに Avalon-MM インタフェースまたは Avalon Interfaces
Specifications で定義されている他の標準的なインタフェースに外部プロセッサ・バス
を適応させるカスタム・ブリッジ・コンポーネントを定義するために、SOPC Builder
で使用可能なコンポーネント・エディタを使用することができます。コンポーネン
ト・エディタで使用できる Templates メニューには、カスタム・ブリッジに任意の標
準 Avalon インタフェースを追加するメニュー項目が含まれています。必要な場合は、
Setup、Read Wait、Write Wait および Hold を含むタイミング・パラメータを変更する
ために、コンポーネント・エディタの Interfaces タブを使用することができます。
f コンポーネント・エディタについて詳しくは、SOPC Builder User Guide の「Component
Editor」の章を参照してください。
1
Avalon-MM プロトコルは、すべてのマスタがバイトのアドレスを提供する必要があり
ます。したがって、外部プロセッサ・バス・インタフェースから Avalon-MM インタ
フェースに変換するときに、カスタム・ブリッジ・コンポーネントにアドレス配線
を追加する必要がある場合があります。例えば、プロセッサ・バスが 16 ビットの
ワード・アドレスを持っている場合、1 つの追加の下位アドレス・ビットを追加する
必要があります。プロセッサ・バスが 32 ビットのワード・アドレスをドライブする
場合、2 つの追加の下位アドレス・ビットを追加する必要があります。どちらのケー
スでも、余分なビットは 0 に固定する必要があります。外部プロセッサはバイト・
イネーブル信号を使用して、個々のバイト・レーンにアクセスします。
外部プロセッサおよび Avalon-MM インタフェースとの間を接続してカスタム・ブ
リッジをデザインする場合、次の点を考慮してください。
■
プロセッサ・バス信号は、Avalon Interfaces Specifications で説明するようにトラン
ザクションに使用される信号を遵守するためのロジックに遵守するか、または適
合させる必要があります。
■
外部プロセッサは、スレーブ・コンポーネントのウェイト・ステート・サイクル
を挿入する Avalon waitrequest 信号をサポートする必要があります。
■
システム・バスは、FPGA での SOPC Builder インタフェース・ロジックをドライブ
するバスの基準クロックを持っている必要があります。
■
Avalon-MM インタフェースを使用している場合は、タイムアウト・メカニズムが
用意されていません。
外部メモリ・インタフェース・ハンドブック
Volume 2：デザイン・ガイドライン
2011 年 7 月
Altera Corporation
第 10 章： アルテラ FPGA への外部プロセッサの接続
カスタム・ブリッジ・インタフェース
■
10‒13
システムのタイミング要件を分析する必要があります。外部プロセッサおよび
Avalon-MM インタフェースのためのすべての同期タイミング要件が満たされてい
ることを保証するために、タイミング解析を実行する必要があります。次のタイ
ミング特性を調べます。
■
バスの基準クロックへのデータ tSU、tH 、および tCO の時間。
■
システムの fMAX はバスの基準クロックの性能にマッチする。
■
プロセッサ用の read-to-write 転送または write-to-read 転送のためのターンアラウ
ンド時間が十分に理解されている。
プロセッサは、専用リード・バスおよび専用ライト・バスがある場合、Avalon-MM の
readdata および writedata 信号にそれらのバスをマッピングすることができます。
プロセッサが双方向データ・バスを使用している場合、ブリッジ・コンポーネント
は、FPGA のピンにある双方向データ・バスに readdata および writedata 信号を
マージするために、プロセッサの出力イネーブル信号によって制御されたトライス
テート・ロジックを実装することができます。ほとんどのプロセッサ信号が AvalonMM プロトコルに準拠している場合、それらの信号はブリッジ・コンポーネントを
通過することができます。図 10–9 に、32 ビットの外部プロセッサを搭載したブリッ
ジ・コンポーネントの使用方法を示します。
図 10‒9. Avalon-MM スレーブ・インタフェースへの外部プロセッサを適応させるためのカスタム・ブリッジ
Altera FPGA or HardCopy Device
Custom Bridge
Custom Component
Avalon-MM Slave
ready
waitrequest_n
Wr_n & chipselect
write_n
Rd_n & chipselect
read_n
chipselect
External
Processor
(32-bit)
Wr_n
Rd_n
address[n:2]
BE[3:0]
data[31:0]
address[n:2 || 2b’00]
BE[3:0]
address [n:0]
byteenable[3:0]
writedata[31:0]
readdata[31:0]
OE_n
f Avalon-MM インタフェースを使用したデザインについて詳しくは、Avalon Interfaces
Specifications を参照してください。
2011 年 7 月
Altera Corporation
外部メモリ・インタフェース・ハンドブック
Volume 2：デザイン・ガイドライン
10‒14
第 10 章： アルテラ FPGA への外部プロセッサの接続
結論
結論
アルテラは、外部プロセッサに FPGA を接続するために使用できるさまざまなコン
ポーネントを提供しています。これらのコンポーネントのほとんどを使用すると、
SOPC Builder または MegaWizard Plug-In Manager のデザイン・フローのいずれかを選択
できます。また、外部プロセッサに独自のカスタム・インタフェースを構築するこ
とができます。SOPC Builder の Avalon-MM インタフェースを使用すると、コンポーネ
ントの SOPC Builder のライブラリを活用することによって、システムの機能をプロ
セッサ用に簡単に拡張することができます。
改訂履歴
表 10–3 に、このドキュメントの改訂履歴を示します。
表 10‒3. 改訂履歴
日付
バー
ジョン
変更内容
2011 年 7 月
1.1
参照先を更新。
2009 年 2 月
1.0
初版。
外部メモリ・インタフェース・ハンドブック
Volume 2：デザイン・ガイドライン
2011 年 7 月
Altera Corporation
11. Avalon-MM のバイト・オーダリ
ングの考慮事項
7? 2011?
ED51012-1.1
ED51012-1.1
この章では、Avalon® Memory-Mapped （Avalon-MM）インタフェース・バスのバイト・
オーダリングを説明し、システム内のデータを表すための推奨事項を提供します。
IP（Intellectual Property）の異なる方法でデータを解釈するコアを使用する場合、ハー
ドウェアとソフトウェアの両方のバイト・オーダリングを理解することが重要です。
f アルテラは、先に進む前に、次のドキュメントを理解することを推奨します。
■
SOPC Builder User Guide の「System Interconnect Fabric for Memory-Mapped Interfaces」
の章
■
Avalon Interface Specifications
エンディアンネス
用語「エンディアン」は、ハードウェアとソフトウェアの両方でデータのバイト・
オーダリングを表します。データのバイト・オーダリングの最も一般的な 2 つの形
態は、リトル・エンディアンとビッグ・エンディアンです。リトル・エンディアン
は、値の最下位部分が最初に提示され、メモリ内の最下位アドレスに格納されてい
ることを意味します。ビッグ・エンディアンは、値の最上位部分を最初に提示され、
メモリ内の最下位アドレスに格納されていることを意味します。例えば、値が
0x1234 の場合を検討してみます。リトル・エンディアン形式では、表示または保存
される最初の桁は 4 です。ビッグ・エンディアン形式では、表示または保存される
最初の桁は 1 です。
1
エンディアンネスは、通常、バイト・オーダリングのみを指します。各バイト内の
ビット・オーダリングは、11–10 ページの「PowerPC のバス・バイト・オーダリン
グ」および 11–11 ページの「ARM BE-32 のバス・バイト・オーダリング」で説明され
ており、別の対象となります。
ハードウェア・エンディアンネス
ハードウェア開発者は、任意の順序でインタフェースのデータ・ビットをマッピン
グすることができます。インタフェースのデータ・ビットがインタコネクトに接続
された任意のマスタまたはスレーブ・インタフェース用のアドレス・オフセットに
正しくマッピングするように、開発者間の調整と合意が必要です。インタコネクト
は、マスタとスレーブのインタフェース間のデータ幅変換を実行するため、一貫性
のあるハードウェアのエンディアンネスまたはバス・バイト・オーダリングは、さ
まざまなデータ幅の IP インタフェースを持つシステムでは特に重要です。バス・バ
© 2011 年 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, HARDCOPY, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and
logos are trademarks of Altera Corporation and registered in the U.S. Patent and Trademark Office and in other countries. All other words and logos identified as
trademarks or service marks are the property of their respective holders as described at www.altera.com/common/legal.html. Altera warrants performance of its
semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to any products and
services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any information, product, or service
described herein except as expressly agreed to in writing by Altera. Altera customers are advised to obtain the latest version of device specifications before relying
on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Feedback Subscribe
11‒2
第 11 章： Avalon-MM のバイト・オーダリングの考慮事項
エンディアンネス
イト・オーダリングの簡素化へのキーは、インタコネクトに IP コアを接続する際、
システム全体に一貫性があることです。例えば、システム内の 1 つを除くすべての
IP コアがリトル・エンディアンのバス・バイト・オーダリングを使用する場合、そ
の 1 つのビッグ・エンディアンの IP コア・インタフェースをシステム内の他の部分
に適合させるように変更します。
1
IP コアがインタコネクトにデータを提示する方法は、コア内のデータの内部表現に
依存していません。IP コアは、内部の演算バイト・オーダリングとは独立して、バ
ス・データのバイト・オーダリング仕様に一致するデータ・インタフェースをマッ
ピングすることができます。
ソフトウェア・エンディアンネス
ソフトウェア・エンディアンまたは演算バイト・オーダリングは、IP コア、ソフト
ウェア・コンパイラ、およびペリフェラル・ドライバ内のデータの内部表現です。
プロセッサは、変数のバイト・オフセット 0 をマルチバイト・ワードの最上位バイ
トまたは最下位バイトとして扱うことができます。例えば、複数のバイトにまたが
る値 0x0A0B0C0D は、異なる方法で表現することができます。ビッグ・エンディアン
のプロセッサは、値のバイト 0x0A をメモリ内のオフセットの最下位バイトに配置さ
れているものとして考慮し、一方、リトル・エンディアンのプロセッサは、値のバ
イト 0x0D をメモリ内のオフセットの最下位バイトに配置されているものとして考慮
します。
例 11–1 は、ほとんどのプロセッサで使用されるリトル・エンディアンとビッグ・エ
ンディアンの演算バイト・オーダリングの間の違いを表示する C コード・フラグメ
ントを示しています。
例 11‒1. 32 ビット・ワードのバイト・オフセット 0 の読み出し
long * long_ptr;
char byte_value;
*long_ptr = 0x0A0B0C0D; // 32-bit store to 'long_ptr'
byte_value = *((char *)long_ptr); // 8-bit read from 'long_ptr'
例 11–1 では、プロセッサがメモリに 32 ビット値の 0x0A0B0C0D を書き込み、そし
て、その値の最初のバイトを再度読み出します。メモリ・バイト・オフセット 0 が
ワードの最下位バイトであることを考慮する Nios II プロセッサなどのリトル・エン
ディアン・プロセッサは、ポインタ・ロケーションの long_ptr のバイト・オフセッ
ト 0 にバイト 0x0D を格納します。メモリ・バイト・オフセット 0 がワードの最下位
バイトであることを考慮する PowerPC ® などのプロセッサは、ポインタ・ロケーショ
ンの long_ptr のバイト・オフセット 0 にバイト 0x0A を格納します。その結果、こ
のコードがリトル・エンディアンの Nios II プロセッサ上で実行される場合、変数
byte_value は 0x0D でロードされて、このコードがビッグ・エンディアンの PowerPC
プロセッサ上で実行される場合、変数 byte_value は 0x0A でロードされます。
1
演算バイト・オーダリングは、メモリにアクセスするプロセッサのデータ・マスタ
によって使用されるバス・バイト・オーダリングに依存していません。しかし、
ワードおよびハーフワードのアクセスは、プロセッサによって内部でデータを正し
く解釈するためにソフトウェアでバイト・スワップを必要とすることがあります。
詳細は、11–13 ページの「演算バイトのリ・オーダリング」および 11–16 ページの
「ソフトウェアにおけるシステム・ワイドの演算バイトのリ・オーダリング」を参照
してください。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 11 章： Avalon-MM のバイト・オーダリングの考慮事項
Avalon-MM インタフェースの順序
11‒3
Avalon-MM インタフェースの順序
正しいデータ通信を確保するために、Avalon-MM インタフェース仕様では、システム
内のすべてのコンポーネントの各マスタ・ポートまたはスレーブ・ポートがバイト・
オフセット 0 を表す 7 down to 0 のビット・オーダリングで降順にデータを渡す必要
があります。このバスのバイト・オーダリングはリトル・エンディアンです。ユー
ザーのシステムに追加したすべての IP コアは、Avalon-MM インタフェース仕様に準
拠する必要があります。この順序は、任意のマスタはすべてのスレーブ・ポートの
特定のバイトにアクセスするときに、同じフィジカル・バイト・レーンが一貫した
ビット・オーダリングを使用してアクセスされることを保証します。
f 詳細は、「Avalon Interface Specifications」を参照してください。
一緒に接続されたマスタとスレーブ・ポートの幅が一致しない場合、インタコネク
トは、狭い幅から広い幅への転送、および広い幅から狭い幅への転送のためのダイ
ナミック・バス・サイジングを処理します。広い幅のマスタが狭い幅のスレーブに
アクセスすると、インタコネクトは、最初のスレーブに下位バイトを提示すること
によって、データをシリアライズします。狭いマスタが広いスレーブにアクセスす
ると、インタコネクトは、マスタがスレーブの適切なバイト・レーンにアクセスす
ることを確実にするために、バイト・レーン・リアラインメントを行います。
f 詳細は、「SOPC Builder User Guide」の「System Interconnect Fabric for Memory-Mapped
Interfaces」の章を参照してください。
ダイナミック・バス・サイジングの DMA 例
DMA（ダイレクト・メモリ・アクセス）エンジンは、ソース・ロケーションからデ
スティネーション・ロケーションにメモリの内容を移動します。SOPC Builder はダイ
ナミック・バス・サイジングをサポートするので、例中のソースとデスティネー
ション・メモリのデータ幅は、DMA エンジンの幅に一致させる必要はありません。
DMA エンジンは、ソースのベース・アドレスからデータを読み出し、最後の読み出
しが完了するまでアドレスを順次増加させます。また、DMA エンジンは、デスティ
ネーションのベース・アドレスにデータを書き込み、最後の書き込みが完了するま
でアドレスを順次増加させます。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
11‒4
第 11 章： Avalon-MM のバイト・オーダリングの考慮事項
Avalon-MM インタフェースの順序
図 11–1 、図 11–2 、および図 11–3 は、異なるデータ幅でのメモリからの転送、およ
びメモリへの転送の DMA 転送例を示しています。ソース・メモリは、ベース・アド
レス 0 の値 0 で始まる増加シーケンシャル・パターンが入力されています。DMA エ
ンジンは、ソース・メモリのベース・アドレスから始まって、デスティネーション・
メモリのベース・アドレスへのデータ転送を開始します。任意の幅への適応が行わ
れる場合、インタコネクトは、常に最初の下位バイトを転送します。幅適応はイン
タコネクト内で自動的に行われます。
図 11‒1. 16 ビットから 32 ビットへのメモリ DMA 転送
32-Bit DMA
31
0
Address 0
3
2
1
0
Address 4
7
6
5
4
Address 8
11
10
9
8
Address 12
15
14
13
12
Interconnect
15
0
Address 0
1
0
Address 2
3
2
Address 4
5
4
Address 6
7
6
Address 8
9
8
Address 0
3
2
1
0
Address 10
11
10
Address 4
7
6
5
4
Address 12
13
12
Address 8
11
10
9
8
Address 14
15
14
Address 12
15
14
13
12
16-Bit Source Memory
エンベデッド・デザイン・ハンドブック
31
0
32-Bit Destination Memory
2011 年 7 月
Altera Corporation
第 11 章： Avalon-MM のバイト・オーダリングの考慮事項
Avalon-MM インタフェースの順序
11‒5
図 11‒2. 32 ビットから 64 ビットへのメモリ DMA 転送
32-Bit DMA
31
0
Address 0
3
2
1
0
Address 4
7
6
5
4
Address 8
11
10
9
8
Address 12
15
14
13
12
Interconnect
31
0
Address 0
3
2
1
0
Address 4
7
6
5
4
Address 8
11
10
9
8
Address 0
7
6
5
4
3
2
1
0
Address 12
15
14
13
12
Address 8
15
14
13
12
11
10
9
8
32-Bit Source Memory
2011 年 7 月
Altera Corporation
63
0
64-Bit Destination Memory
エンベデッド・デザイン・ハンドブック
11‒6
第 11 章： Avalon-MM のバイト・オーダリングの考慮事項
Nios II プロセッサのデータ・アクセス
図 11‒3. 128 ビットから 16 ビットへのメモリ DMA 転送
32-Bit DMA
31
0
Address 0
3
2
1
0
Address 0
3
2
1
0
Address 4
7
6
5
4
Address 4
7
6
5
4
Address 8
11
10
9
8
Address 8
11
10
9
8
Address 12
15
14
13
12
Address 12
15
14
13
12
Address 16
19
18
17
16
Address 16
19
18
17
16
Address 20
23
22
21
20
Address 20
23
22
21
20
Address 24
27
26
25
24
Address 24
27
26
25
24
Address 28
31
30
29
28
Address 28
31
30
29
28
Interconnect
15
127
0
Address 0
1
0
Address 2
3
2
Address 4
5
4
Address 8
7
6
0
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
Address 28
29
28
Address 16 31
30
29
28
27
26
25
24 23
22
21
20
19
18
17
16
Address 30
31
30
Address 0
128-Bit Source Memory
16-Bit Destination Memory
Nios II プロセッサのデータ・アクセス
Nios II プロセッサでは、内部演算バイト・オーダリングとバスのバイト・オーダリ
ングバイト・オーダリングの両方はリトル・エンディアンです。内部では、プロ
セッサとそのコンパイラはメモリ内で最も低いバイト・オフセットに値の最下位バ
イトをマップします。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 11 章： Avalon-MM のバイト・オーダリングの考慮事項
Nios II プロセッサのデータ・アクセス
11‒7
例えば、図 11–4 は、変数 Y に 32 ビット値の 0x0A0B0C0D を格納することを示してい
ます。この動作では、変数を格納するために使用されるメモリのオフセット 0 に最
下位バイトの 0x0D をマップします。
図 11‒4. Nios II 32 ビット・バイトのマッピング
Memory Mapping
0A
3
0B
2
0C
1
0D
0
Increasing Addresses
Y = 0x0A0B0C0D;
Offset
Nios II プロセッサは、32 ビットのプロセッサです。32 ビットを超えるデータの場合、
最小のオフセットへの最下位バイトに対して同じマッピングが発生します。例えば、
0x0807060504030201 の値が 64 ビット変数に格納される場合、変数の最下位バイト
0x01 はメモリ内の変数のバイト・オフセット 0 に格納されます。変数の最上位バイ
ト 0x08 は、メモリ内の変数のバイト・オフセット 7 に格納されます。プロセッサ
は、最初のメモリに変数の最下位 4 バイトの 0x04030201 を書き込んだ後に、最上位
4 バイトの 0x08070605 が続きます。
Nios II プロセッサのマスタ・インタフェースは、オフセット 0 を表すビット 7 ～ 0
を使用して降順のビット・オーダリングでインタコネクトにリード・データとライ
ト・データを提供することで、Avalon-MM バスのバイト・オーダリングに準拠してい
ます。Nios II プロセッサは 32 ビット・データ・パスを使用するため、プロセッサは、
7 つの異なる整列アクセスとインタコネクトにアクセスすることができます。
表 11–1 は、Nios II プロセッサがインタコネクトに提示することができる 7 つの有効
なライト・アクセスを示しています。
表 11‒1. Nios II ライト・データ・バイトのマッピング
アクセス・
オフセット
サイズ
（バイト数）
（ビット数）
値
バイト・イ
ネーブル
（ビット 3:0）
ライト・
データ
（ビット
31:24）
ライト・
データ
（ビット
23:16）
ライト・
データ
（ビット
15:8）
ライト・
データ
（ビット
7:0）
8
0
0x0A
0001
—
—
—
0x0A
8
1
0x0A
0010
—
—
0x0A
—
8
2
0x0A
0100
—
0x0A
—
—
8
3
0x0A
1000
0x0A
—
—
—
16
0
0x0A0B
0011
—
—
0x0A
0x0B
16
2
0x0A0B
1100
0x0A
0x0B
—
—
32
0
0x0A0B0C0D
1111
0x0A
0x0B
0x0C
0x0D
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
11‒8
第 11 章： Avalon-MM のバイト・オーダリングの考慮事項
プロセッサ · マスタの Avalon-MM 準拠への適応
例 11–2 に示すコード・フラグメントは、表 11–1 に示す全 7 つのアクセスを表に記
載されている順序に従って生成します（ここで、BASE は、4 バイト境界にアラインメ
ントされたメモリ内の場所です）。
例 11‒2. Nios II ライト・データ・バイトのマッピング・コード
IOWR_8DIRECT(BASE, 0, 0x0A);
IOWR_8DIRECT(BASE, 1, 0x0A);
IOWR_8DIRECT(BASE, 2, 0x0A);
IOWR_8DIRECT(BASE, 3, 0x0A);
IOWR_16DIRECT(BASE, 0, 0x0A0B);
IOWR_16DIRECT(BASE, 2, 0x0A0B);
IOWR_32DIRECT(BASE, 0, 0x0A0B0C0D);
プロセッサ · マスタの Avalon-MM 準拠への適応
Nios II プロセッサがインタコネクトにデータを提示する方法は、Avalon-MM に準拠し
ているため、インタコネクトにプロセッサを接続するために余分な労力を必要とし
ません。この項では、Avalon-MM 準拠を達成するために、Avalon-MM 準拠ではないプ
ロセッサ・マスタを変更する方法について説明します。
一部のプロセッサでは、Nios II プロセッサが使用するものとは異なる演算バイト・
オーダリングを使用し、その結果として、一般的に Avalon-MM インタフェース仕様
がサポートする数より異なるバスのバイト・オーダリングを使用します。Nios II プ
ロセッサなどの他のマスタを含むシステム内のインタコネクトにこれらのプロセッ
サのいずれかを直接に接続する場合、同じアドレスにアクセスすると、スレーブ・
ポートの異なるフィジカル・バイト・レーンにアクセスすることになります。異な
るバスのバイト・オーダリングに準拠してマスタとスレーブ混合すると、システム・
レベルでの管理がほぼ不可能になります。これらの混合されたバスのバイト・オー
ダリングのシステムは、維持とデバッグが困難になります。アルテラは、システム
に追加したプロセッサのマスタ・インタフェースが Avalon-MM に準拠していること
を必要とします。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 11 章： Avalon-MM のバイト・オーダリングの考慮事項
プロセッサ · マスタの Avalon-MM 準拠への適応
11‒9
Nios II プロセッサの実装と反対のビッグ・エンディアンの演算バイト・オーダリン
グを使用するプロセッサは、メモリ内の変数の最低のバイト・オフセットに変数の
最上位バイトをマップします。例えば、図 11–5 に、PowerPC プロセッサ・コアが変
数 Y を含むメモリへの 32 ビットの値 0x0A0B0C0D を格納する方法を示します。
PowerPC は、変数が含まれているメモリのオフセット 0 に 0x0A の最上位バイトを格
納します。
図 11‒5. Power PC の 32 ビット・バイトのマッピング
Memory Mapping
0D
3
0C
2
0B
1
0A
0
Increasing Addresses
Y = 0x0A0B0C0D;
Offset
この演算バイト・オーダリングは、11–6 ページの「Nios II プロセッサのデータ・ア
クセス」に示されているオーダリングの反対です。プロセッサ内部の演算バイト・
オーダリングがプロセッサ外部のデータ・バスのバイト・オーダリングと無関係で
あるので、インタコネクトへの Avalon-MM に準拠したデータを提示するには、
Avalon-MM に準拠していないバスのバイト・オーダリングを使用してプロセッサ・マ
スタを適応させることができます。
以下の項では、Avalon-MM 準拠ではない最も一般的な 2 つのプロセッサのためのバス
のバイト・オーダリングを説明します。
2011 年 7 月
■
「PowerPC のバス・バイト・オーダリング」
■
「ARM BE-32 のバス・バイト・オーダリング」
Altera Corporation
エンベデッド・デザイン・ハンドブック
11‒10
第 11 章： Avalon-MM のバイト・オーダリングの考慮事項
プロセッサ · マスタの Avalon-MM 準拠への適応
PowerPC のバス・バイト・オーダリング
PowerPC のバス・バイト・オーダリングのバイト位置は、Avalon-MM インタフェース
仕様のバイト位置がアラインメントされていますが、各バイト内のビットがずれて
います。PowerPC プロセッサ・コアは、マスタがインタコネクトに接続されている場
合、昇順のビット・オーダリングを使用します。例えば、32 ビットの PowerPC コア
は、0 ～ 31 のバス・データ・ビットをラベリングします。PowerPC コアは、0 ～ 7 の
ビットをバイト・オフセット 0 として見なします。このレイアウトは、バイト・オ
フセット 0 を 7 ～ 0 のデータ・ビットとして定義する Avalon-MM インタフェースの
仕様とは異なります。インタコネクトに PowerPC プロセッサを接続するには、
図 11–6 に示す各バイト・レーンのビット名を変更する必要があります。
図 11‒6. PowerPC ラッパのビット名の 変更
PowerPC Wrapper
PowerPC Processor
Core
WD[0..7]
writedata[0..31] WD[8..15]
WD[16..23]
WD[24..31]
WD[7..0]
WD[15..8]
WD[23..16]
WD[31..24]
RD[0..7]
readdata[0..31] RD[8..15]
RD[16..23]
RD[24..31]
RD[7..0]
RD[15..8]
RD[23..16]
RD[31..24]
byteenable[0..3]
address[a..0]
burstcount[b..0]
read
write
BE[3..0]
BE[0..3]
writedata[31..0]
readdata[31..0]
byteenable[3..0]
System Interconnect
address[a..0]
burstcount[b..0]
read
write
waitrequest
waitrequest
readatavalid
readatavalid
図 11–6 には、ビット 0 はビット 7 に変更され、ビット 1 はビット 6 に変更され、
ビット 2 はビット 5 に変更される、などとなっています。各バイト・レーン内の
ビットの名前を変更することで、バイト・オフセット 0 が下位 8 データ・ビットに
そのままにあります。各バイト・レーンのビット名を個別に変更する必要がありま
す。すべての 32 ビットを反転させてビット名を変更すると、Avalon-MM に準拠して
いない結果が作成されます。例えば、必要に応じて、バイト・オフセット 0 は、7 ～
0 のデータ・ビットではなく、31 ～ 24 のデータ・ビットにシフトします。
1
ビットは単に名前を変更されているので、この追加のハードウェアに対して、追加
の FPGA リソースを占有しないで、データ・インタフェースの fMAX には影響を与えま
せん。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 11 章： Avalon-MM のバイト・オーダリングの考慮事項
プロセッサ · マスタの Avalon-MM 準拠への適応
11‒11
ARM BE-32 のバス・バイト・オーダリング
一部の ARM® コアは、一般的に big endian 32（BE-32）と呼ばれるバス・バイト・
オーダリングを使用します。BE-32 プロセッサ・コアは、マスタがインタコネクトに
接続されている場合、降順のビット・オーダリングを使用します。例えば、ARM
BE-32 プロセッサ・コアは 31 ～ 0 のデータ・ビットをラベリングします。プロセッ
サ・コアは、31 ～ 24 のビットをバイト・オフセット 0 として考慮します。このレイ
アウトは、バイト 0 を 7 ～ 0 のデータ・ビットとして定義する Avalon-MM の仕様と
は異なります。
BE-32 プロセッサ・コアは、表 11–2 に示すバス・マッピングを使用してメモリにア
クセスします。
表 11‒2. ARM BE-32 のライト・データのマッピング
アクセス・
オフセット
サイズ
（バイト数）
（ビット数）
値
バイト・イ
ネーブル
（ビット
3:0）
ライト・
データ
（ビット
31:24）
ライト・
データ
（ビット
23:16）
ライト・
データ
（ビット
15:8）
ライト・
データ
（ビット
7:0）
8
0
0x0A
1000
0x0A
—
—
—
8
1
0x0A
0100
—
0x0A
—
—
8
2
0x0A
0010
—
—
0x0A
—
8
3
0x0A
0001
—
—
—
0x0A
16
0
0x0A0B
1100
0x0A
0x0B
—
—
16
2
0x0A0B
0011
—
—
0x0A
0x0B
32
0
0x0A0B0C0D
1111
0x0A
0x0B
0x0C
0x0D
表 11–2 に示す BE-32 プロセッサのライト・アクセス動作は、表 11–1 に示す Nios II
プロセッサの動作とは大きく異なります。唯一の一貫したアクセスは完全な 32 ビッ
トのライト・アクセスです。他のすべてのケースでは、各プロセッサはインタコネ
クトの異なるバイト・レーンにアクセスします。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
11‒12
第 11 章： Avalon-MM のバイト・オーダリングの考慮事項
プロセッサ · マスタの Avalon-MM 準拠への適応
インターコネクトに BE-32 のバス・バイト・オーダリングを持つプロセッサに接続
するには、図 11–7 に示すように、各バイト・レーンの名前を変更します。
図 11‒7. ARM BE-32 のラッパのバイト名の変更
ARM Wrapper
ARM BE-32
Processor Core
WD[31..24]
writedata[31..0] WD[23..16]
WD[15..8]
WD[7..0]
WD[7..0]
WD[15..8]
WD[23..16]
WD[31..24]
RD[31..24]
readdata[31..0] RD[16..23]
RD[15..8]
RD[7..0]
RD[7..0]
RD[15..8]
RD[23..16]
RD[31..24]
byteenable[3..0]
BE[3]
BE[2]
BE[1]
BE[0]
BE[0]
BE[1]
BE[2]
BE[3]
address[a..0]
burstcount[b..0]
read
writedata[31..0]
readdata[31..0]
byteenable[3..0]
address[a..0]
burstcount[b..0]
read
write
write
1
System Interconnect
waitrequest
waitrequest
readatavalid
readatavalid
PowerPC のラッパ・ロジックのケースと同様に、ARM BE-32 ラッパは、FPGA のロジッ
ク・リソースを消費したり、インタフェースの fMAX が低下することはありません。
ARM BE-8 のバス・バイト・オーダリング
新しい ARM のプロセッサ・コアは big endian 8（BE-8）と呼ばれるモードを提供しま
す。BE-8 プロセッサ・マスタ・インタフェースは、Avalon-MM に準拠しています。内
部では、BE-8 コアはビッグ・エンディアンの演算バイト・オーダリングを使用しま
すが、バス・レベルで、Avalon-MM インタフェース仕様が必要とするリトル・エン
ディアン方向でインタコネクトにデータをマップします。
1
このバイト・オーダリングの変更は、特別な注意が必要な場合があります。詳細は、
11–13 ページの「演算バイトのリ・オーダリング」を参照してください。
他のプロセッサのビットとバイト・オーダリング
プロセッサのマスタ・インタフェースに出入りするデータをオーダする方法は、他
にもたくさんあります。それらの場合でも、Avalon-MM 準拠を達成するためのアプ
ローチは同じです。一般的には、Avalon-MM 準拠を確保するために、任意のプロセッ
サ・コアに、次の 3 つの手順が適用されます。
1. ビット・オーダリングを識別します。
2. マスタのバイト・オフセット 0 の位置を識別します。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 11 章： Avalon-MM のバイト・オーダリングの考慮事項
プロセッサ · マスタの Avalon-MM 準拠への適応
11‒13
3. バイト 0 は 7 ～ 0 のデータに配置されて、バイト 1 は 15 ～ 8 のデータに配置さ
れて、というように配置されるように、データ信号の名前を変更するプロセッ
サ・コアのラッパを作成します。
演算バイトのリ・オーダリング
Avalon-MM バイト・オーダリングに準拠するようにシステムを変更すると、ソフト
ウェアによって見られるようにマルチバイト値の内部演算のバイト・オーダリング
を変更します。例えば、ARM BE-8 プロセッサなどの Avalon-MM 準拠のビッグ・エン
ディアン・プロセッサ・コアは、表 11–3 に示すバス・マッピングを使用してメモリ
にアクセスします。
表 11‒3. ARM BE-8 のライト・データ・マッピング
アクセス・
オフセット
サイズ
（バイト数）
（ビット数）
値
バイト・イ
ネーブル
（ビット
3:0）
ライト・
データ
（ビット
31:24）
ライト・
データ
（ビット
23:16）
ライト・
データ
（ビット
15:8）
ライト・
データ
（ビット
7:0）
8
0
0x0A
0001
—
—
—
0x0A
8
1
0x0A
0010
—
—
0x0A
—
8
2
0x0A
0100
—
0x0A
—
—
8
3
0x0A
1000
0x0A
—
—
—
16
0
0x0A0B
0011
—
—
0x0B
0x0A
16
2
0x0A0B
1100
0x0B
0x0A
—
—
32
0
0x0A0B0C0D
1111
0x0D
0x0C
0x0B
0x0A
ビッグ・エンディアンの ARM BE-8 マッピング（表 11–3 ）は、すべて単一のバイト・
アクセス用のリトル・エンディアンの Nios II プロセッサのマッピング（表 11–1 ）に
一致します。ユーザーのプロセッサが Avalon-MM に準拠していることを保証する場
合は、簡単にビッグ・エンディアンとリトル・エンディアンのプロセッサとペリ
フェラルの間でデータの個々のバイトを共有することができます。
しかし、プロセッサ・データ・マスタが Avalon-MM に準拠していることを確認する
ことで、単一のバイトがスレーブ・ポートの同じフィジカル・バイト・レーンに
マップにアクセスすることのみ保証します。マルチバイト・アクセスの場合に、同
じバイト・レーンは、BE-8 とリトル・エンディアンのプロセッサとの間にアクセス
されていますが、値は一貫して解釈されていません。プロセッサの内部演算のバイ
ト・オーダリングがシステム内の他のペリフェラルやプロセッサと異なる場合のみ、
このミスマッチは重要です。
ミスマッチを修正するには、マルチバイト・アクセス用のソフトウェアで演算バイ
ト・オーダリングを実行する必要があります。プロセッサによるデータの解釈は、
システム内のプロセッサと他のプロセッサによって使用される演算バイト・オーダ
リングおよびペリフェラルに基づいて変化する可能性があります。
例えば、16 ビットのリード・アクセスを実行することによって 16 ビットのリトル・
エンディアンのタイマ・ペリフェラルから読み出す 32 ビットの ARM BE-8 プロセッ
サ・コアを検討してみます。ARM プロセッサは、バイト・オフセット 0 を任意の
ワードの最上位バイトとして扱います。タイマは、バイト・オフセット 0 を 16 ビッ
ト値の最下位バイトとして扱います。プロセッサはタイマからの値を読み出すとき
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
11‒14
第 11 章： Avalon-MM のバイト・オーダリングの考慮事項
プロセッサ · マスタの Avalon-MM 準拠への適応
に、ソフトウェアから見た値のバイトは、スワップされます。図 11–8 に、スワッピ
ングを示します。プロセッサの演算バイト・オーダリングがタイマ・コンポーネン
トの演算バイト・オーダリングと一致しないため、プロセッサによって 0x0800
（2048 クロック・チック）のタイマ・カウンタの値は、0x0008（8 クロック・チッ
ク）として解釈されます。
図 11‒8. リトル・エンディアン・ペリフェラルにアクセスする ARM BE-8 プロセッサ
32-Bit ARM BE-8 Processor
16-Bit Value Read = 0x0008
31
24
0x00
X
23
16
15
0x08
8
7
X
X
0
X
0x08
0x00
0x08
0x00
Interconnect
15
8
0x08
0
7
0x00
Value = 0x0800
Little Endian Timer
正確に解釈される値において、プロセッサは、書くバイト・レーンを個別に読み出
して 2 つのバイト・リードをソフトウェア内のシングルの 16 ビットの値に組み合わ
せるか、シングルの 16 ビットの値を読み出してソフトウェアのバイトにスワップす
る必要があります。
ARM BE-32 または PowerPC コアにバス・レベルの名前を変更するラッパを適用した
場合に、同じ問題が発生します。両方のプロセッサ・コアは、バイト・オフセット 0
を任意の値の最上位バイトとして扱います。その結果、システム内のプロセッサと
ペリフェラルで使用されるデータの演算バイト・オーダリングの間のミスマッチを
処理する必要があります。
一方、図 11–8 にあるタイマが 16 ビット値の最上位バイトをバイト 0（ビッグ・エン
ディアン）として扱った場合、データは、プロセッサによって使用される演算バイ
ト・オーダリングと同じオーダリングでプロセッサ・マスタに到達する可能性があ
ります。プロセッサとコンポーネントが内部で同じ演算バイト・オーダリングを実
装する場合は、バイトのソフトウェア・スワッピングは、マルチバイト・アクセス
に必要ありません。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 11 章： Avalon-MM のバイト・オーダリングの考慮事項
システム・ワイドのデザインの推奨事項
11‒15
図 11–9 には、ビッグ・エンディアン・タイマの値 0x0800 を、プロセッサによって
読み出される方法を示しています。読み出しが完了した後、ソフトウェアで任意の
バイト・スワッピングの実行を必要とすることなく、値が保持されます。
図 11‒9. BE-8 ペリフェラルをアクセスする ARM BE-8 プロセッサ
32-Bit ARM BE-8 Processor
16-Bit Value Read = 0x0800
31
24
0x08
X
23
16
15
0x00
8
7
0
X
X
X
0x00
0x08
0x00
0x08
Interconnect
15
8
0x08
0
7
0x00
Value = 0x0008
BE-8 Timer
システム・ワイドのデザインの推奨事項
前の項では、プロセッサの観点から演算およびバス・バイト・オーダリングを議論
しました。同じ概念が直接システム内の任意のコンポーネントに適用されます。
Avalon-MM スレーブ・ポートを含む任意のコンポーネントは、Avalon-MM 仕様に準拠
する必要があります。これは、データ・ビットが 7 ～ 0 のビットに位置するバイト・
オフセット 0 で降順に定義されることを述べています。コンポーネントのスレーブ・
ポートが Avalon-MM に準拠している限り、コンポーネント内での任意の演算バイト・
オーダリングを使用することができます。
システム・ワイドの演算バイト・オーダリング
通常、1 が存在する場合、システム全体で使用する最も便利な演算バイト・オーダリ
ングは、プロセッサが使用している順序です。プロセッサがシステムの残りの部分
と異なる演算バイト・オーダリングを使用している場合、すべてのマルチバイト・
アクセスの順序を並べ替えるソフトウェアを記述する必要があります。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
11‒16
第 11 章： Avalon-MM のバイト・オーダリングの考慮事項
システム・ワイドのデザインの推奨事項
アルテラが提供する Avalon-MM マスタまたはスレーブ・ポートを含む IP の大半は、
リトル・エンディアンの演算バイト・オーダリングを使用します。ユーザーのシス
テムが主にアルテラ提供のコンポーネントで構成されている場合、システムの残り
の部分を、同じリトル・エンディアンの演算バイト・オーダリングを使用して構築
する方がはるかに簡単です。全体のシステムが同じ演算バイト・オーダリングおよ
び Avalon-MM のバス・バイト・オーダリングを使用するコンポーネントを使用して
いる場合、データ・アクセスを実行するプロセッサまたは任意のコンポーネント内
に演算バイト・オーダリングは必要ありません。
アルテラは、ビッグ・エンディアンとリトル・エンディアンの演算バイト・オーダ
リングの両方を処理するドライバ・コードを書き込むことを推奨します。例えば、
ペリフェラルがリトル・エンディアンである場合、ビッグ・エンディアンとリトル・
エンディアンのプロセッサの両方で実行するためのペリフェラル・ドライバを書き
込みます。リトル・エンディアン・プロセッサでは、バイト・スワッピングは必要
ありません。ビッグ・エンディアン・プロセッサでは、すべてのマルチバイト・ア
クセスはバイト・スワップを必要とします。ドライバ・コードの選択は、アプリ
ケーションとペリフェラルによって、コンパイル時または実行時に制御されます。
ソフトウェアにおけるシステム・ワイドの演算バイトのリ・オーダ
リング
すべてのコンポーネントが同じ演算バイト・オーダリングを使用するようにシステ
ムを変更できない場合は、マルチバイト・アクセス用のソフトウェアでバイト・
オーダリングを実装する必要があります。今日の多くのプロセッサは、この動作を
加速させるための命令が含まれています。ユーザーのプロセッサに専用のバイト・
オーダリングの変更がない場合、例 11–3 には、16 ビットと 32 ビットのデータにマ
クロを活用することにより、ソフトウェアでのバイト・オーダリングの変更を実装
する方法を示しています。
例 11‒3. ソフトウェア演算バイトのリ・オーダリング
/* Perform 16-bit byte reordering */
#define SW_16_BIT_ARITHMETIC_REORDERING (data) ( \
(((data) << 8) & 0xFF00) | \
(((data) >> 8) & 0x00FF) \
)
/* Perform 32-bit byte reordering */
#define SW_32_BIT_ARITHMETIC_REORDERING (data) ( \
(((data) << 24) & 0xFF000000) | \
(((data) << 8) & 0x00FF0000) | \
(((data) >> 8) & 0x0000FF00) | \
(((data) >> 24) & 0x000000FF) \
)
1
演算バイトのリ・オーダリングを必要とする値の幅に基づいて、バイトのリ・オー
ダリングを実行する適切な命令またはマクロを選択します。演算バイト・オーダリ
ングはメモリやペリフェラルに格納された個々の値にのみ適用されるため、隣接す
るメモリ位置に格納されたデータを乱すことなく、値のバイトを逆にする必要があ
ります。例えば、異なる演算バイト・オーダリングを使用するペリフェラルから 16
ビットの値をロードする場合、ソフトウェアの 2 つのバイトをスワップする必要が
あります。パッキングされた 32 ビットのリード・アクセスとして 2 つの 16 ビット
値をロードしようとする場合、個々の 16 ビット値を個別にスワップする必要があり
ます。4 つすべてのバイトを一度にスワップしようとする場合、ソフトウェア開発者
が本来意図していない 2 個の 16 ビット値がスワップされます。
エンベデッド・デザイン・ハンドブック
2011 年 7 月
Altera Corporation
第 11 章： Avalon-MM のバイト・オーダリングの考慮事項
改訂履歴
11‒17
改訂履歴
表 11–4 に、このドキュメントの改訂履歴を示します。
表 11‒4. 改訂履歴
日付
バー
ジョン
変更内容
2011 年 7 月
1.1
Qsys の記述を削除。
2011 年 1 月
1.0
初版。
2011 年 7 月
Altera Corporation
エンベデッド・デザイン・ハンドブック
11‒18
エンベデッド・デザイン・ハンドブック
第 11 章： Avalon-MM のバイト・オーダリングの考慮事項
改訂履歴
2011 年 7 月
Altera Corporation
追加情報
アルテラへのお問い合わせ
アルテラ製品に関する最新の情報については、次の表を参照してください。
お問い合わせ先 ( 注 1)
お問い合わせ
方法
アドレス
技術的なご質問
ウェブサイト
www.altera.com/support
技術トレーニング
ウェブサイト
www.altera.com/training
電子メール
custrain@altera.com
アルテラの資料に関するお問い
合わせ
電子メール
literature@altera.com
一般的なお問い合わせ
電子メール
nacomp@altera.com
ソフトウェア・ライセンスに関
するお問い合わせ
電子メール
authorization@altera.com
注:
(1) 詳しくは、日本アルテラまたは販売代理店にお問い合わせください。
表記規則
本書では、以下の表に示す表記規則を使用しています。
書体
意味
太字かつ文頭が大文字
コマンド名、ダイアログ・ボックス・タイトル、ダイアログ・ボックス・
オプション、およびその他の GUI ラベルを表します。例えば、Save As ダイ
アログ・ボックスです。GUI エレメントの場合、大文字と小文字は、GUI に
マッチします。
太字
ディレクトリ名、プロジェクト名、ディスク・ドライブ名、ファイル名、
ファイルの拡張子、ダイアログ・ボックス・オプション、ソフトウェア・
ユーティリティ、およびその他の GUI ラベル名を表します。例：\qdesigns
ディレクトリ、d: ドライブ、および chiptrip.gdf ファイル
斜体かつ文頭が大文字
資料のタイトルを表します。例えば、「AN 519 : Stratix IV Design Guidelines」
です。
斜体
変数を表します。例：n + 1。
変数名は、山括弧 (< >) で囲んでいます。例えば、<file name> および
<project name>.pof ファイルです。
文頭が大文字
「小見出しタイトル」
エンベデッド・デザイン・ハンドブック
2011 年７月 Preliminary
キーボード・キーおよびメニュー名を表します。例えば、Delete キーおよ
び Options メニューです。
かぎ括弧は、資料内の小見出しおよび Quartus II Help トピックのタイトル
を表します。例えば、「表記規則」です。
インフォ –2
追加情報
表記規則
書体
意味
Courier フォント
信号、ポート、レジスタ、ビット、ブロック、およびプリミティブ名を表
します。例えば、data1、tdi、および input です。アクティブ Low 信号
は、サフィックス n で表示されています ( 例：resetn)。
コマンドライン・コマンド、および表示されているとおりに入力する必要
があるものを表します。例：c:\qdesigns\tutorial\chiptrip.gdf
また、Report ファイルのような実際のファイル、ファイルの構成要素
（例：AHDL キーワードの SUBDESIGN）、ロジック・ファンクション名
（例：TRI）も表します。
1.、2.、3.、および
a.、b.、c.、など
手順など項目の順序が重要なものは、番号が付けられリスト形式で表記さ
れています。
■ ■
箇条書きの黒点などは、項目の順序が重要ではないものに付いています。
1
指差しマークは、要注意箇所を表しています。
c
注意は、製品または作業中のデータに損傷を与えたり、破壊したりするお
それのある条件や状況に対して注意を促します。
w
警告は、ユーザーに危害を与えるおそれのある条件や状況に対して注意を
促します。
r
矢印は、Enter キーを押すよう指示しています。
f
足跡マークは、詳細情報の参照先を示しています。
エンベデッド・デザイン・ハンドブック
2011 年７月
Preliminary
Altera Corporation

Nios II - オンチップ・メモリからのブート手順

VEEK-MT-SoCKit Upgrade Kit - SoCKit 用 MTLC

Cyclone V SoCを使用したビデオアルファブレンダー

マスター タイトルの書式設定

小型 CMOS カメラを搭載した自律制御型ロボットの開発

HALシステム・ライブラリの概要

Nios II IDE によるソフトウェア開発 セクション 2

SB 28: USBホスト・コントローラメガファンクション

ギャラリー高岡 文具トレイ D E N アイスクリームスプーン T T SO+01