オートモーティブ機能安全マニュアル Cyclone V FPGAおよびCyclone V SoC用

(1)

オートモーティブ機能安全マニュアル

Cyclone V FPGA

_{および Cyclone V SoC 用}

更新情報 フィードバック

MNL-1079

2015.07.14 101 Innovation DriveSan Jose, CA 95134

(2)

オートモーティブの機能安全について...1-1

システム障害の管理... 2-1

アルテラの開発フロー...2-1 ユーザー開発フロー...2-3 FPGA 要件の仕様化...2-5 FPGA アーキテクチャの生成... 2-6 ロジック・モジュール・デザインに向けた設計記述の作成... 2-7 ロジック・モジュール・デザインに向けたテスト記述の作成...2-8 ロジック・モジュール・デザインのコーディング...2-9 ロジック・モジュール・デザイン設計のテスト... 2-10 ロジック・モジュール・デザインへの障害の注入...2-11 FMEDA の実行... 2-12 ロジック・モジュール統合に向けた設計記述の作成... 2-13 ロジック・モジュール統合に向けたテスト記述の作成...2-13 ロジック・モジュール統合のコーディング...2-13 ロジック・モジュール統合のテスト... 2-14 合成の実行... 2-15 配置配線の実行...2-16 スタティック・タイミング解析の実行...2-16 ゲート・レベル・シミュレーションの実行...2-17 ビットストリームの生成...2-19 デザインの検証...2-19 オートモーティブの機能安全向けのアルテラ・ツール...2-20 アルテラ IP コア...2-22 Nios II プロセッサ... 2-23

偶発ハードウェア障害の管理に向けた Cyclone V アーキテクチャ...3-1

Cyclone V の概要...3-1 Cyclone V がターゲットとするアプリケーション... 3-1 Cyclone V ハードウェアのアーキテクチャ...3-1 Cyclone V の診断メカニズムおよび使用にあたっての前提条件... 3-2 電源...3-3 クロック...3-3 リセット...3-6 入力/出力... 3-7

目次-2 オートモーティブ機能安全マニュアル Cyclone V FPGA および Cyclone V SoC 用

(3)

Cyclone V FPGA のコンフィギュレーション... 3-8 FPGA ユーザ・メモリ...3-10

偶発ハードウェア障害の管理に向けた Cyclone V SoC アーキテクチャ...4-1

Cyclone V の概要...4-1 Cyclone V SoC がターゲットとするアプリケーション... 4-3 Cyclone V SoC ハードウェアのアーキテクチャ... 4-3 Cyclone V SoC の診断メカニズムおよび使用にあたっての前提条件...4-5 電源...4-5 クロック...4-6 リセット...4-12 入力/出力... 4-14 Cyclone V SoC における FPGA のコンフィギュレーション ... 4-16 FPGA ユーザ・メモリ...4-18 HPS インタコネクト...4-19 HPS-FPGA 間のインタコネクト... 4-22 HPS Cortex-A9 MPU のサブシステム... 4-25 HPS のデバッグとトレース... 4-34 HPS SDRAM コントローラ... 4-36 HPS オンチップ RAM...4-38 HPS オンチップ・ブート ROM...4-40 HPS NAND フラッシュ・コントローラ...4-41 HPS SD/MMC コントローラ...4-43 HPS Quad SPI フラッシュ・コントローラ...4-45 HPS FPGA マネージャ... 4-47 HPS システム・マネージャ... 4-48 HPS スキャン・マネージャ... 4-49 HPS DMAC...4-51 HPS イーサネット・メディア・アクセス・コントローラ... 4-53 HPS USB 2.0 OTG コントローラ...4-56 HPS SPI コントローラ...4-58 HPS I2C コントローラ... 4-60 UART コントローラ...4-62 HPS タイマ... 4-64 HPS ウォッチドッグ・タイマ...4-65 HPS CAN コントローラ...4-67

ISO26262 に特化した FPGA デザイン用のテクニックと方法...5-1

デザイン入力...5-1 Structured Description（構造化記述）... 5-1 Design description in HDL（HDL によるデザインの記述）... 5-2 回路図入力... 5-2

(4)

ブール式を使用したデザインの記述... 5-3 モジュール化...5-3 Proven in Use（使用実績のある）デザイン環境の適用...5-4 HDL シミュレーション... 5-5 モジュール・レベルでの機能テスト... 5-6 トップレベル・モジュールでの機能テスト...5-6 Restricted use of asynchronous constructs（非同期構文の使用制限）... 5-7 プライマリ入力の同期およびメタスタビリティの管理... 5-7 機能的および構造的カバレッジ・ドリブン検証... 5-8 コーディング・ガイドラインの順守... 5-8 コード・チェッカの適用... 5-9 検査コードまたはウォークスルー...5-9 検証済みのソフト・コアの適用...5-10 ソフト IP コアの検証...5-12 シミュレーション結果のドキュメンテーション... 5-13 合成... 5-13 内部整合性のチェック... 5-13 ゲート・ネットリスト・シミュレーション...5-14 伝播遅延のスタティック・タイミング解析（STA）...5-14 シミュレーションによるリファレンス・モデルに対するゲート・ネットリストの検証 ... 5-15 リファレンス・モデルとゲート・ネットリストの比較（フォーマル等価性検証)5-16 IC ベンダの要件と制約の確認... 5-16 合成の制約、結果、ツールのドキュメンテーション... 5-17 Proven in Use（使用実績のある）合成の適用... 5-18 Proven in Use（使用実績のある）ライブラリ/CPLD テクノロジの適用...5-20 スクリプト・ベースの手順...5-20 適切なタイミング・マージン... 5-21 テストの挿入とテスト・パターンの生成... 5-23 テスト容易化設計（DFT）... 5-23 配置、配線、レイアウトの生成...5-24 使用実績のある適用されたハード・コアの正当性...5-24 検証済みのハード・コアの適用...5-24 レイアウト後のゲート・ネットリスト・シミュレーション... 5-25 パワー・ネットワークの解析... 5-26 リファレンス・モデルとレイアウト後のゲート・ネットリストの比較... 5-26 デザイン・ルール・チェック... 5-26 Layout Versus Schematic（LVS）チェック... 5-27 チップ生産段階の安全性に関連する特殊な特性... 5-27 Proven in Use（使用実績のある）プロセス・テクノロジの適用... 5-28 Proven in Use（使用実績のある）デバイス・シリーズ...5-28 使用実績のある製造工程の適用...5-28 製造工程における品質管理...5-29

目次-4 オートモーティブ機能安全マニュアル Cyclone V FPGA および Cyclone V SoC 用

(5)

システム内の FPGA プロトタイプの最終的な確認および検証...5-30 最終的な検査と検証...5-30

アルテラ・ツールおよびソフトウェアの既知の問題... 6-1

Development Interface Agreement（開発協働契約書）...7-1

安全管理者... 7-1 安全性ライフサイクル...7-2 アルテラが行う活動およびお客様の責任... 7-2 アルテラが提供する情報... 7-3 活動の責任当事者... 7-4 目標値についての情報交換...7-4 サポートのプロセスとツール... 7-4

Nios II プロセッサを使用したソフトウェア開発...8-1

Qsys を使用した Nios II システムの作成...8-1 Nios II システム用のボート・サポート・パッケージの作成... 8-1 アプリケーション・フレームワークの作成...8-2 アプリケーション・ソフトウェアの開発... 8-3 ソフトウェアとハードウェアの統合... 8-3 ISO26262 規格に含まれるツールとライブラリ...8-3 ISO26262 規格に含まれないサードパーティー製ツールとライブラリ...8-4

サポートされる（V）HDL のバージョン ...9-1

改訂履歴... 10-1

(6)

オートモーティブの機能安全について

1

2015.07.14

MNL-1079 _更新情報 フィードバック

本資料は、機能安全を重視するシステムの実装についての情報を提供し、アイテム・レベルでの ISO26262:2011-2012 コンプライアンスを満たすことを可能とします。

TÜV Rheinland 社は前世代の Altera FPGA とツールが SIL3 レベルまで IEC61508:2010 規格を満たすこと承認しています。この高い技術と作業は、継続して ISO26262:2011-2012 規格も満たしています。アルテラは ISO26262 USTAG の積極的なメンバーであり、半導体メーカーに関する標準の明確化を目的とする ISO26262 半導体メーカーのサブグループに参画しています。 注意: アルテラのコンポーネント、ソフトウェア、およびツールのユーザーはすべての規制およ び安全性の要件を満たしている必要があります。この資料に記載されているすべての情報は参照を目的としており、安全機能を重視するシステムにおいてアルテラ・コンポーネントの使用に起因するいかなる損害、クレーム、スイートまたは費用に対し、アルテラは一切責任を負いかねます。

Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. Intel 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 Intel. Intel 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.

*Other names and brands may be claimed as the property of others.

ISO 9001:2008

登録済

www.altera.com

(7)

システム障害の管理

2

2015.07.14 MNL-1079 _更新情報 フィードバック アイテムあるいはエレメント内での障害のリスクを最小限に抑えるには、系統的な故障の可能性を低減させます。堅牢な開発フローを使用することで、この目標が達成可能となります。 2-1 ページのアルテラの開発フロー

このフローは TÜV Rheinland 社により、2010 年から最新の 2015 年（No.: 968/EL 850.00/12）の認定に至るまで SIL3 までの IEC61508:2010 規格への順守に必要なアプリケーションでの使用に適していることが承認されています。 2-3 ページのユーザー開発フロー TÜV Rheinland 社は、モデル・フローが IEC61508:2010 規格を満たすことを承認しています。また、TÜV Rheinland 社はこのフローが機能安全を重視するシステムのデザインに適していると判断しています。アルテラは、ISO26262:2011-2012 規格を満たすようこのフローを修正しています。

アルテラの開発フロー

アルテラは開発フローで使用するツール、デバイス、IP コアを提供しています。このフローは TÜV Rheinland 社により、2010 年から最新の 2015 年（No.: 968/EL 850.00/12）の認定に至るまで SIL3 までの IEC61508:2010 規格への順守に必要なアプリケーションでの使用に適していることが承認されています。アルテラは、 EN ISO9001:2008（certificate: NAIS 19.1804）の認証を取得しています。

Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. Intel 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 Intel. Intel 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.

*Other names and brands may be claimed as the property of others.

ISO 9001:2008

(8)

図 2-1: アルテラの開発フロー 次の図はいくつかの段階を経るアルテラの開発フローを表しています。 Discovery Review? no yes Concept Review? no yes Plan Review? no yes Design Review? no yes Rollout Review? no yes Production Review? no yes End of Life Review? no アルテラは、各段階の終了時に全段階を再度評価し、次の段階に進むかどうかを判断します。 Discovery_段階 Discovery 段階では、アルテラは市場機会とアルテラ・デバイスの潜在的な適合性を評価します。 Concept段階 Concept 段階では、アルテラは特定の市場に対処するためのソリューションを定義し、次の段階に向けたプランを作成します。 2-2 _{アルテラの開発フロー} _2015.07.14MNL-1079 Altera Corporation システム障害の管理 フィードバック

(9)

Plan_段階 Plan 段階ではアルテラは、様々な機能的グループのインプットをもとにプロジェクト・プランを開発します。アルテラは、実行可能性の調査を行い、高水準の仕様を作成します。 Design_段階 Design 段階ではアルテラは、高水準の仕様をより詳細な仕様に改良します。これは製品を実装するために使用されます。アルテラはテスト・プランを作成し、デザインが詳細な仕様を満たすことを検証します。 Rollout_段階 Rollout 段階では、アルテラはその製品がデバイスである場合、製品を特定し、それを検証します。アルテラは異常を把握し、それらを記録し、潜在的にそのような問題点を修正します。 Production_段階 Production 段階では、アルテラは製造準備が整ったデバイス、ツール、および IP コアを作成します。お客様は、製造に向けてアルテラの成果物を使用することができます。 End-of-Life_段階 End-of-Life 段階では、アルテラは製品寿命の終了時に、製品を市場から撤収させることをカスタマーに通知します。お客様は、定義された期間中に新しいアルテラ製品に変更することができます。

ユーザー開発フロー

アルテラ・プロダクトは、ハードウェアのプログラムが可能です。ユーザーは独自の回路を設計し、FPGA にプログラムすることが可能です。これには、通常はシリコン・プロバイダによって行われる多くの設計ステップをユーザーが実行しなければいけません。IP コアおよび回路の作成には、V モデル・フローを使用することができます。 TÜV Rheinland 社は、モデル・フローが IEC61508:2010 規格を満たすことを承認しています。また、TÜV Rheinland 社はこのフローが機能安全を重視するシステムのデザインに適していると判断しています。アルテラは、 ISO26262:2011-2012 規格を満たすようこのフローを修正しています。 MNL-1079 2015.07.14 ユーザー開発フロー 2-3 システム障害の管理 Altera Corporation

(10)

図 2-2: ユーザーによる V モデル開発フロー Validate Design Plan Tests Perform FMEDA Inject Faults Specify FPGA Requirements Generate FPGA Architecture Generate Bitstream Perform Gate-Level Simulation Perform Static Timing Analysis Perform Place and Route Perform Synthesis Create Design Description Create

Test Plan Test

Code

Create Design Description

Create

Test Plan Test

Code Logical Module Design

Logical Module Integration

各 V モデル・ステップの記述には以下の情報が含まれます。 • V モデル・ステップの記述。 • 入力。 V モデル・ステップへの入力のリスト。これには、プロジェクトのドキュメントやデザイン・ファイルなどが含まれます。 • 出力。V モデル・ステップの出力のリスト—入力を処理する際の最終的な結果。これには、出力ネットリスト、検証パス、成功しなかったステータスなどが含まれます。 • 検証。 V モデル・ステップが正しく行われていることを検証します。アルテラでは例を提供していますが、独自の方法を用いることも可能です。検証または V モデルステップ中にツールを使用する場合は、検証を補助するためにツールの出力を評価しなければなりません。ツールが生成したエラー、警告、およびレポート・ファイルを評価する必要があります。 • 推奨ツール。特定の V モデル・ステップを実装するにあたって、このソフトウェア・ツールのリストを使用することができます。1 つのツールのみが利用可能なケースもありますが、ほとんどのは場合多くのオプションが利用可能です。 • 特定のテクニックと方法。このリストは、各ステップに適用される標準で明示的な参照を示しています。本資料中のトピックには、これらのテクニックと方法を満たすことができる手法を解説するアルテラ固有の情報が含まれます。 2-4 _{ユーザー開発フロー} _2015.07.14MNL-1079 Altera Corporation システム障害の管理 フィードバック

(11)

注意: 開発段階で要件のトレーサビリティに向けての何らかの手段を用いることを推奨してい ます。アルテラはこの過程を全体の安全性要件の一部であると考えており、各 V モデル・ステップはこれについて明示的に言及していません。

FPGA

_{要件の仕様化}

このステップでは、FPGA サブシステムの全体的な機能性を明確に記述します。この記述には高レベルの仕様項目とデバイス全体の機能性の詳細が含まれます。高レベルのシステム要件を分析し、FPGA が実行する機能を引き出します。 FPGA 要件の仕様には以下が含まれます： • 高レベルの機能要件 • サブシステムの性能 • 必要な外部インタフェースこの段階で仕様化が可能なアイテム： • FPGA デバイス・ファミリ。 • パフォーマンス。例：デバイスの動作クロックの周波数 • パフォーマンスとシンセシスの設定。例：フィジカル・シンセシスの使用 • IP コアの使用およびソフトウェアの仕様。 • デザイン言語とバージョン。 • 外部 I/O の制約（速度、電圧、分離）。この V モデルのステップに適用できるアルテラのプロセスまたはツールはありません。入力： • アイテム要件の仕様 • 安全コンセプト出力： • 詳細な FPGA 要件の仕様 • 検証報告書検証： • 入力ドキュメントに対する詳細な FPGA 要件の仕様の手続き型クロスチェック。例：番号付きアイテムの使用 • 相互評価の詳細な FPGA 要件の仕様推奨ツール：

• 要件管理ツール（例：IBM DOORS または TechnoSolutions TopTeam など）特定のテクニックと方法：

• なし

MNL-1079

2015.07.14 FPGA要件の仕様化 2-5

(12)

要件の仕様と管理に関するより具体的な情報については、ISO26262-8:2011 clause 6 および ISO26262-5:2011 clause 6 を参照してください。

FPGA

_{アーキテクチャの生成}

1. 適切な FPGA アーキテクチャを生成します。 2. 一般的に、FPGA デザイン内の主要なブロックについて記述し、その中でも主要なブロックと その他のブロック、FPGA デザイン内および外部インタフェースとの相互接続と相互作用について記述します。 3. 通常、主要なブロックおよびそれらの相互接続を示すブロック図を生成します。 4. FPGA システムすべての要件を考慮し、必要な機能をサブモジュールへパーティション化しま す。 5. このようなサブモジュールは別々に定義し境界を設定することで、個別に開発およびテスト することが可能となります。 6. サードパーティ製の IP コアまたは標準インタフェースを指定することができます。 7. 安全性を考慮した設計が正常に動作することを確認するために必要となるアーキテクチャの 機能を指定する必要があります。この段階では、以下の項目を指定することもできます： • デザイン入力の方法 • FPGA ファミリ内の特定のデバイス • 完全なツールのリスト • テキスト・エディタ • サポートされるサードパーティー製シミュレータ・ツール • 合成エンジン • スクリプトを必要とするツールの部分の仕様 • アーカイブされたファイルや結果の要件 • Qsys • IP コア • 総合的な診断テクニック • サブモジュール・レベルでの診断テクニック • Nios II エンベデッド・ソフト・プロセッサ • 標準の内部インタフェース（例：Avalon®メモリ・マップド（Avalon-MM）インタフェースまたは Avalon ストリーミング（Avalon-ST）インタフェース）入力： • アイテムの安全要件の仕様（Item SRS） • FPGA 要件の仕様 • FPGA の安全要件の仕様（FPGA SRS） • エラッタと既知の問題出力： • FPGA 機能アーキテクチャ図とその記述 • FPGA 診断アーキテクチャの詳細 • 詳細なモジュール要件の仕様および診断あるいはストラテジーのコンセプト • 検証報告書 2-6 _FPGA_{アーキテクチャの生成} _2015.07.14MNL-1079 Altera Corporation システム障害の管理 フィードバック

(13)

検証： • 入力ドキュメント・アイテムに対する出力ドキュメント・アイテムの手続き型クロスチェック。例：番号付きアイテムの使用 • アーキテクチャのピアレビュー。推奨ツール： • 標準的な作図パッケージ（例：Microsoft Visio） • 標準的な文書作成パッケージ（例：Microsoft Word）

• 要件管理ツール（例：IBM DOORS または TechnoSolutions TopTeam など）特定のテクニックと方法；

• なし

ハードウェア・アーキテクチャの設計に関する詳細な要件については、ISO26262 -5:2011 clause

7.4.1 を参照してください。

詳細については、Quartus II Software Handbook v14.1 の以下のトピックを参照してください。 • Volume 1：設計と合成 • 第 2 章：Quartus II ソフトウェアによるデザイン・プランニング

ロジック・モジュール・デザインに向けた設計記述の作成

このステップでは、FPGA アーキテクチャのステップが指定する各モジュールの設計段階の説明を記述します。記述には、モジュール要件を達成する方法について記載します。この文書は、ステート・マシンの機能、演算機能、詳細なモジュール I/O の定義を指定するレベルとすることができます。FPGA アーキテクチャの検証および最終的なモジュール実装を確認する手法が実行可能となるよう、モジュールのビヘイビアをモデル化することが望ましい場合もあります。このモデルは、SystemC や MathWorks 社の MATLAB M などの高レベルのモデリング言語で実装可能です。ドキュメントには、優秀なエンジニアが診断を含む各モジュールを FPGA デバイス内に問題なく実装できるように、十分な詳細を含める必要があります。各モジュールに関連する機能、パフォーマンス、安全性を明確に定義します。さらに、インタコネクトとチップ全体におよぶリソースも明確に定義します。以下は、このステップへ FPGA デザインに関連する具体的な考慮事項です。 • RAM 使用量と構成 • クロッキング・リソース（PLL は、ルーティング）と構成 • モジュールの I/O 接続、バスの種類この V モデルのステップに適用できるアルテラのプロセスまたはツールはありません。入力 • FPGA アーキテクチャのドキュメント • 詳細なモジュール要件の仕様出力 MNL-1079 2015.07.14 ロジック・モジュール・デザインに向けた設計記述の作成 2-7 システム障害の管理 Altera Corporation

(14)

• 詳細なデザインの設計記述 • モジュール・レベルのビヘイビア・モデル • 検証報告書検証 • 出力デザイン・ドキュメントを持つ入力仕様の手続き型クロスチェック。例：番号付きアイテムの使用 • ドキュメントのピアレビュー。推奨ツール • 標準的な文書作成パッケージ（Microsoft Word）

• 要件管理ツール（例：IBM DOORS または TechnoSolutions TopTeam など） • ビヘイビアのモデル化用の System-C • ビヘイビアのモデル化用の MathWorks 社の MATLAB 特定のテクニックと方法 • なし ハードウェアの設計に関する詳細な要件については、ISO26262-5:2011 clause 7.4.2 を参照してくだ さい。

ロジック・モジュール・デザインに向けたテスト記述の作成

この V モデルのステップでは、モジュール・レベルの機能を説明し、テスト仕様やテストの記述を生成します。実行する場合、デザインの要件を満たすにあたってテストの記述が十分なテスト・カバレッジを提供する必要があります。システム全体の安全要件とターゲットの ASIL が要件を導きます。各仕様のポイントまたは機能要件を分析します。正しい機能と起こり得る障害の両方の条件でテストするために特別なテストを記述します。また、モジュール内で診断機能の能力をチェックするテストも開発します。この V モデルのステップに適用できるアルテラのプロセスまたはツールはありません。入力 • アイテム要件の仕様（すべての安全要件向け） • FPGA 要件の仕様（FPGA レベルの要件向け） • ロジック・モジュール・デザイン—機能の記述出力 • ロジック・モジュール・デザイン—テストの記述 • 検証報告書検証 • テストの記述でデザイン・ドキュメントから番号付きのテストまでのテスト可能なアイテムのクロスチェック • テスト・ストラテジーと範囲のピアレビュー推奨ツール • 標準的な文書作成パッケージ（Microsoft Word）

• 要件管理ツール（例：IBM DOORS または TechnoSolutions TopTeam など）

2-8 _{ロジック・モジュール・デザインに向けたテスト記述の作成} _2015.07.14MNL-1079

Altera Corporation システム障害の管理

(15)

特定のテクニックと方法 • なしハードウェアの設計に関する詳細な要件については、ISO26262-5:2011 clause 7.4.4 を参照してください。

ロジック・モジュール・デザインのコーディング

このステップでは、詳細なモジュールの機能の記述を合成可能なデザインの記述に変換します。これは通常、回路機能の（V）HDL 記述の形式をとり、デザイン入力に対しては標準的なテキスト・エディタを使用します。 注意: この資料内の（V）HDL という用語は、Verilog HDL または VHDL のいずれかを意味しま す。デザイン入力には様々な方法を選択することができます。デザインの実装に適した方法を決定するには、数多くある特定のテクニックと方法（5－1 ページの ISO26262 に特化した FPGA デザ イン用のテクニックと方法）の中から、各デザイン入力の方法の適正を評価します。参照先の ISO26262 には、アルテラ・ツールを使用したこのようなテクニックと方法の実装方法が詳細に記載されています。この V モデル・ステップは、アルテラのツールやプロセスを必要としません。ただし、Quartus II ソフトウェアを使用しているのであれば、正しい言語構文および精緻化エラーをチェックするには、解析およびエラボレーション機能を使用することができます。解析およびエラボレーションは、デザインに正しいソース・コードの構文と接続が使用されているかどうかをチェックする Analysis and Synthesis プロセスの一部を構成します。

入力： • ロジック・モジュール・デザイン—機能の記述出力： • 合成可能なデザイン・ファイル（通常は（V)HDL）検証 • lint ツールの使用（可能な場合） • 検査コードまたはウォークスルー • シミュレーション推奨ツール • 標準的なテキスト・エディタ

• Qartus II 開発ソフトウェアの Analysis and Elaboration 機能特定のテクニックと方法

• _{Structured Description（構造化記述）}を参照してください。

• _{Design description in HDL（HDL によるデザインの記述）}を参照してください。

• _{Restricted use of asynchronous constructs（非同期構文の使用制限）}_{を参照してください。}

• _{検査コードまたはウォークスルー}_{を参照してください。}

詳細については、Quartus II Software Handbook v14.1 の以下のトピックを参照してください。 • Volume 1：設計と合成

• 第 1 章：Quartus II プロジェクトの管理

MNL-1079

2015.07.14 ロジック・モジュール・デザインのコーディング 2-9

(16)

解析およびエラボレーションの詳細については、Quartus II Software Handbook v14.1 の以下のトピ ックを参照してください。 • Volume 1：設計と合成 • 第 16 章：Quartus II ソフトウェアの統合合成関連情報 5-1 ページの ISO26262 に特化した FPGA デザイン用のテクニックと方法

ロジック・モジュール・デザイン設計のテスト

このステップでは、デザインを生成し、テスト・コードあるいはテストベンチを実行します。以前に生成されたテストの記述から個々のアイテムを実行可能なテストへと変換します。このステップで開発するテストはそれぞれ、テスト記述アイテムに直接リファレンスされます。テストのパス/フェイル・ステータスは、開発者およびプロジェクト・マネージャーが簡単にアクセスできるようにします。このステップには多くのテクニックが使用できますが、開発中の安全性に関するデザインに基も適したテクニックを選択します。このステップには、以下のような方法が用いられることが一般的です。 • 標準的なテキスト・エディタを使用して（V）HDL テストベンチをコーディングします • 適切なロジック・シミュレータ内でこのテストベンチを実行します • テストの成功/不成功をキャプチャします • 不成功だった内容を分析し、デザインのソース・コードを修正しますこのステップでテストを実行するには、スクリプトを使用します。高い信頼性と再現性を持つテストを実行する目的で、アルテラは EDA コミュニティによって広くサポートされ、使用されている Tcl スクリプト言語をサポートしています。サードパーティのシミュレータを慎重に選択します。ISO26262:2011-2012 では、ツールの信頼性レベル（ISO26262-8:2011 clause 11）の確立についての要件が定義されています。このステップでは通常、標準的な（V）HDL によってデザインが記述されるため、選択した言語をサポートするサードパーティーのシミュレータだけが必要となります。デザインに Altera IP コアのインスタンスが含まれる場合、適切な Altera のシミュレーション・ライブラリを使用するようにします。このようなライブラリは、Quartus II ソフトウェアで提供されています。シミュレーションでのコンフィギュレーションが（この資料で指定する特定の Quartus II ソフトウェアのバージョンから）正しいアルテラ・ライブラリをターゲットとしていることを確認する必要があります。検証には、System Verilog HDL 言語を使用する方法を実装に選択することができます。選択するツールと方法が、安全性に関するデザインと検証に対して適切であることを確認する必要があります。このステップでは、デザインを合成し、同じシミュレーション・テストベンチを使用してげーどレベルのコードを実行することが可能です。生成したコードがターゲット・デバイスに合成されたかを早い段階で知ることができるため、アルテラではこのステップを推奨しています。入力 • デザイン・ソース・ファイル

• Logical Module Design Test Description ドキュメント 出力

2-10 _{ロジック・モジュール・デザイン設計のテスト} _2015.07.14MNL-1079

Altera Corporation システム障害の管理

(17)

• テストのパス/フェイル・ステータス • （デバッグで使用する）テストのパス/フェイル診断検証 • ツールの使用 • テスト結果のピアレビュー • 有効なシミュレータ出力を手動でチェックします • レポート・ファイルの存在、およびタイム・スタンプあるいはデート・スタンプのチェック • シミュレーション・ライブラリ・ファイルのタイム・スタンプあるいはデート・スタンプのチェック推奨ツール • サードパーティー製シミュレーション・ツール。これらの解説は本資料には含まれません。 • Mentor ModelSim® simulator

• Cadence NCSIM • Synopsys VCS • アルテラのシミュレーション・ライブラリ（オプション）特定のテクニックと方法 • _{HDL シミュレーション}を参照してください。 • モジュール・レベルでの機能テストを参照してください。 • _{機能的および構造的カバレッジ・ドリブン検証}_{を参照してください。} • _{シミュレーション結果のドキュメンテーション}_{を参照してください。} • _{Proven in Use（使用実績のある）ライブラリ/CPLD テクノロジの適用}を参照してください。 詳細については、Quartus II Software Handbook v14.1 の以下のトピックを参照してください。 • Volume 3：検証

• 第 1 章：アルテラ・デザインのシミュレーション

Tcl スクリプトの詳細については、Quartus II Software Handbook v14.1 の以下のトピックを参照し てください。 • Volume 2：デザインの実装と最適化 • 第 3 章：Tcl スクリプト

ロジック・モジュール・デザインへの障害の注入

このステップはオプションであり、モジュール・デザインに障害検出機能が内蔵されている場合のみ適用されます。このステップでは、検出された障害の数を決定するために、デザインのネットリストに障害を注入して実装された手法が診断する範囲を分析します。モジュール・デザインよりも高いレベルで診断測定を実施することができます。モジュール・デザインの統合において障害注入テストを実行して、より高いレベルの測定で診断する範囲を決定し、モジュール間の依存関係を分析する必要があります。入力 • デザインのネットリスト出力 • テスト診断カバレッジ MNL-1079 2015.07.14 ロジック・モジュール・デザインへの障害の注入 2-11 システム障害の管理 Altera Corporation

(18)

検証 • ツールの使用 • テスト結果のピアレビュー推奨ツール • サードパーティ製の故障注入ツール • サードパーティ製のシュミレーション・ツール • アルテラのシミュレーション・ライブラリ（オプション）特定のテクニックと方法 • _{HDL シミュレーション}を参照してください。 • _{シミュレーション結果のドキュメンテーション}_{を参照してください。} • _{Proven in Use（使用実績のある）ライブラリ/CPLD テクノロジの適用}_{を参照してください。} • _{ロジック・モジュール統合のテスト}_{を参照してください。} 詳細は以下を参照してください。 • ISO26262-5:2011, Section 7.4.4.1 • ISO26262-5:2011, Section 10.4.5

FMEDA

_の実行

このステップでは、診断能力を決定し、デザインで達成されたメトリクスを評価します。実装された診断手法の Failure モード、Failure モードの分布、Failure 率、および診断の範囲についての情報を、Failure モード、効果、診断解析、（FMEDA）への入力として考慮する必要があります。最も正確な情報で製品開発サイクル間に FMEDA を微調整します。入力 • Failure モード • Failure モードの分布 • 回路の故障率 • 診断手法の診断カバレッジ出力 • FMEDA 検証 • 結果のピアレビュー推奨ツール • アルテラ FMEDA スプレッドシート特定のテクニックと方法 2-12 _FMEDA_の実行 _2015.07.14MNL-1079 Altera Corporation システム障害の管理 フィードバック

(19)

• 適用されません

ロジック・モジュール統合に向けた設計記述の作成

このステップでは、抽象化レベルがモジュール統合レベルである点を除き、ロジック・モジュール・デザインに向けた設計記述の作成と同じテクニックを使用します。各モジュール間の統合を記述するための基礎として、FPGA アーキテクチャのドキュメントを使用することができます。関連情報 2-7 ページのロジック・モジュール・デザインに向けた設計記述の作成

ロジック・モジュール統合に向けたテスト記述の作成

このステップでは、テストがより高いレベルのブロックおよびサブシステムに特化されているという点を除き、ロジック・モジュール・デザインに向けたテスト記述の作成と同じテクニックを使用します。このテスト記述はフルチップのテスト時にターゲットとすることができます。関連情報 2-7 ページのロジック・モジュール・デザインに向けた設計記述の作成

ロジック・モジュール統合のコーディング

このステップでは、前の段階で開発した個々のモジュールを統合します。この時点で、これらのモジュールを組み合わせることで、より高いレベルの機能と最終的なトップレベルの FPGA の設計を作成します。 Quartus II ソフトウェアはモジュールの統合を簡易化するコード生成ツール（Qsys）を搭載しており、特にアルテラ IP コアと Nios II プロセッサを使用する場合はモジュール統合を非常に簡単に実行することができます。入力 • モジュール・デザイン・ファイル • ロジック・モジュール・デザイン—機能の記述 • FPGA アーキテクチャ出力 • チップ・レベルまたはサブシステム・レベルのデザイン・ファイル検証 • 自動化されたステップのレポート・ファイルの出力を分析する（これは Nios II ソフトウェア・ビルド・ツールにも適用されます） • VHDL ソース・ファイルのタイム・スタンプとデート・スタンプを確認する（これは Nios II ソフトウェア・ビルド・ツールにも適用されます） • Qsys が生成した階層を検査する（Qsy ｓを使用した場合）推奨ツール • 標準的なテキスト・エディタ • Quartus II Qsys 特定のテクニックと方法 MNL-1079 2015.07.14 ロジック・モジュール統合に向けた設計記述の作成 2-13 システム障害の管理 Altera Corporation

(20)

• _{モジュール化}_{を参照してください。} • _{検証済みのソフト・コアの適用}_{を参照してください。} • ソフト IP コアの検証を参照してください。

ロジック・モジュール統合のテスト

このステップでは、モジュール・レベルの V モデルのステップと同じテクニックを使用しています。ただし、検証の焦点は、より高いレベルのブロックおよびフルチップのテストにあります。入力： • デザイン・ソース・ファイル

• Logical Module Design Test Description ドキュメント 出力： • テストのパス/フェイル・ステータス • （デバッグで使用する）テストのパス/フェイル診断検証： • ツールの使用 • テスト結果のピアレビュー • 有効なシミュレータ出力を手動でチェックします • レポート・ファイルの存在、およびタイム・スタンプあるいはデート・スタンプのチェック • シミュレーション・ライブラリ・ファイルのタイム・スタンプあるいはデート・スタンプのチェック推奨ツール： • サードパーティー製シミュレーション・ツール。これらの解説は本資料には含まれません。 • Mentor: ModelSim • Cadence: NCSIM • Synopsys: VCS • アルテラのシミュレーション・ライブラリ（オプション）特定のテクニックと方法： • _{HDL シミュレーション}を参照してください。 • _{モジュール・レベルでの機能テスト}_{を参照してください。} • _{機能的および構造的カバレッジ・ドリブン検証}_{を参照してください。} • シミュレーション結果のドキュメンテーションを参照してください。 • _{Proven in Use（使用実績のある）ライブラリ/CPLD テクノロジの適用}を参照してください。 詳細については、Quartus II Software Handbook v14.1 の以下のトピックを参照してください。 • Volume 3：検証関連情報 2-10 ページのロジック・モジュール・デザイン設計のテスト 2-14 _{ロジック・モジュール統合のテスト} _2015.07.14MNL-1079 Altera Corporation システム障害の管理 フィードバック

(21)

合成の実行

このステップでは FPGA 合成ツールを使用します。合成ツールは指定した入力デザイン・ファイルを受け取り、ロジック・ファンクションを Quartus II ソフトウェアがターゲットとするアルテラ FPGA のロジック・セルのストラクチャ内に実装できるフォーマットに変換します。Quartus II ソフトウェアには Quartus II 統合合成機能ツールが含まれています。これは他の開発フローの部分と統合する高性能な合成ツールです。安全性に関連するフローには他の合成ツールを使用することも可能です。 Quartus II ソフトウェアは、VHDL および Verilog HDL 言語の特定のバージョンをサポートしています。使用するデザイン・ソースが、これらの規格に適合していることを確認する必要があります。使用する言語のバージョンは、FPGA 要件の仕様書あるいはコーディング・ガイドラインのドキュメント内で指定しておくことが理想的です。 Quartus II ソフトウェアは構文の正確性という点からデザイン・ソースを確認した後、そしてデザイン階層を詳細に調査した後で、FPGA コンパイル・フローのロジック合成を実行します。合成エンジンの動作に関しては多くのオプションが存在します。Quartus II 合成エンジンは合成の制約によって制御されます。入力 • デザイン・ファイル。例：（V）HDL モジュールおよび統合ファイル • プロジェクトの制約。例：ターゲットとするファミリあるいはデバイス • タイミング制約（推奨。タイミング・ドリブンの最適化が可能となります）出力 • 合成後のデータベース（内部ツール・ファイル）検証 • 生成されたレポート・ファイルを見直す（例：警告や重度の警告） • 内部プロジェクト・データベース・タイムとデート・スタンプを確認する • 入力ファイル・リストを確認する推奨ツール • Quartus II 統合合成ツール • サードパーティー製合成ツール。これらの解説は本資料には含まれません。 • Synopsys Synplify

• Mentor Graphics Precision Synthesis • Mentor Graphics LeonardoSpectrum 特定のテクニックと方法： • _{内部整合性のチェック}_{を参照してください。} • _{合成の制約、結果、ツールのドキュメンテーション}_{を参照してください。} • _{Proven in Use（使用実績のある）合成の適用}を参照してください。 • _{Proven in Use（使用実績のある）ライブラリ/CPLD テクノロジの適用}を参照してください。 • _{スクリプト・ベースの手順}_{を参照してください。} Quartus II ソフトウェアが統合した合成を呼び出す方法およびそれらが持つ制約と効果について は、Quartus II Software Handbook v14.1 の以下のトピックを参照してください。

MNL-1079

2015.07.14 合成の実行 2-15

(22)

• Volume 1：設計と合成関連情報 9-1 ページの サポートされる（V）HDL のバージョン

配置配線の実行

このステップでは、論理合成の結果から各ロジック・セルの特定の配置が含まれるネットリストを作成します。さらに、ロジック・セルとその他のデバイス・リソースとの間の正確な配線を導き出します。配置配線プロセスを実行するために、システムのタイミング制約を使用するよう配置配線ツールを設定することが可能です。アルテラは、Quartus II ソフトウェアの多くのバージョンを通じて、複雑な内部アルゴリズムを開発してきました。技術の詳細については、本資料には含まれません。配置配線プロセスでは、合成ネットリスト・アイテムを配置配線するだけではなく、合成データベースを大幅に変更することが可能です。プロジェクト全体のレベルといった設計サイクルの初期段階で、Quaruts II Fitter の設定と制約を決定します。入力： • 合成後のデータベース • プロジェクトの制約。例：ターゲットとするファミリあるいはデバイス • タイミング制約（オプション、タイミング・ドリブンの配置配線用）出力： • 配置配線後のネットリスト（内部ツール・ファイル）検証： • ツールが生成したレポート・ファイルの解析（警告、重大な警告などをチェック） • 内部プロジェクト・データベース・タイムとデート・スタンプを確認する • 有効なゲート・レベルでのシミュレーション結果を確認する推奨ツール： • Quartus II Fitter 特定のテクニックと方法： • 使用実績のある適用されたハード・コアの正当性を参照してください。 • 検証済みのハード・コアの適用を参照してください。

詳細については、Quartus II Software Handbook v14.1 の以下のトピックを参照してください。 • Volume 2：デザインの実装と最適化 • 第 12 章：タイミング・クロージャと最適化 • 第 14 章：エリアの最適化

スタティック・タイミング解析の実行

このステップでは、タイミング解析を実行します。タイミング解析を実行することで、デザインのタイミングに関するパフォーマンスの正確な情報が得られ、回路が問題なく動作するかどうかを把握することができます。 2-16 _{配置配線の実行} _2015.07.14MNL-1079 Altera Corporation システム障害の管理 フィードバック

(23)

FPGA の全体的なシステム・パフォーマンスを FPGA 要件のドキュメントで指定することができます。 FPGA アーキテクチャのドキュメントでは、デザイン内のサブシステムのタイミングを指定することができます。アルテラは、Quartus II ソフトウェアに TimeQuest タイミング解析ツールを搭載しています。ユーザー提供のタイミング制約のセットに対してタイミング・パフォーマンスを検証するには、この包括的なツールを使用してください。タイミング制約は、全体的な FPGA デザインの重要な部分であるため、慎重に設計し、管理する必要があります。FPGA デザイン・サイクルの初期段階でタイミング制約を開発します。Quartus II ソフトウェアは合成とフィッティングの際にタイミング制約を使用します。例えば、合成と配置配線のステップでタイミング制約を使用すれば、速度や面積の最適化でより良い結果が得られます。入力： • タイミング制約 • FPGA アーキテクチャ • FPGA 要件の仕様 • デバイスのタイミング・モデル • 配置配線後のネットリスト出力： • タイミング・レポート・ファイル検証： • タイミング障害のツール出力ファイルを見直す • ツールからの有効な結果を確認する • ツールが正しい制約（.sdc）ファイルを読み出していることを確認する • クロック・サマリ・レポートを確認する • マクロが生成するすべてのサマリのレポートを確認する • レポート・ファイルの存在とタイム・スタンプおよびデート・スタンプを確認する • レポート・ファイル内で制約されていないパスを確認する推奨ツール：

• Quartus II TimeQuest Timing Analyzer 特定のテクニックと方法： • _{合成の制約、結果、ツールのドキュメンテーション}_{を参照してください。} • 伝播遅延のスタティック・タイミング解析（STA）を参照してください。 • 適切なタイミング・マージンを参照してください。使用期間が 3 年以下のプロセス・テクノロジのデバイス・ファミリを使用する場合のタイミング制約を変更するにあたっての特定の要件についての詳細な情報は、適切なタイミング・マージンを参照してください。

ゲート・レベル・シミュレーションの実行

このステップでは、前段階のプロセスを検証します。配置配線ステップの出力であるネットリストでデザインをシミュレーションします。ツールは論理合成を実行することでこのネットリストを生成するだけなので、合成ツールの動作も検証します。 MNL-1079 2015.07.14 ゲート・レベル・シミュレーションの実行 2-17 システム障害の管理 Altera Corporation

(24)

ロジック・モジュール・デザイン設計のテストとロジック・モジュール統合のテストで生成するシミュレーション・テストベンチを再利用することが一般的ですが、この段階で開発に追加のテ ストを提供することを決定することができます。この要件は、FPGA要件の仕様または FPGAアーキテクチャのドキュメント内で記述します。ロジック・シミュレータに関連するすべてのタイミング情報を提供するという点を除いては、タイミングが正確なゲート・レベルのシミュレーションは、通常のゲート・レベルのシミュレーションと同じです。このプロセスでは、デザインないのタイミング違反が表示されることがあります。機能ゲート・レベル・シミュレーションに加えて、このステップを実行することができます。または、機能ゲート・レベル・シミュレーションはこのステップを置き換えることができます。使用期間が 3 年以下のプロセス・テクノロジのデバイス・ファミリを使用する場合のタイミング制約を変更するにあたっての特定の要件についての詳細な情報は、適切なタイミング・マージンを参照してください。入力 • 配置配線後のネットリスト • ロジック・モジュール・テストの記述とテストベンチ • ロジック・モジュール統合テストの記述とテストベンチ出力 • テストのパス/フェイル・ステータス • （デバッグで使用する）テストのパス/フェイル診断検証 • テスト結果のピアレビュー • 有効なシミュレータの出力を手動で確認する • 手動で波形を確認する • ポート・ファイルのパス/フェイル・ステータスを手動で確認する • レポート・ファイルの存在とタイム・スタンプおよびデート・スタンプを確認する推奨ツール • サードパーティー製シミュレーション・ツール。これらの解説は本資料には含まれません。 • Mentor ModelSim • Cadence NCSIM • Synopsys VCS • アルテラのシミュレーション・ライブラリ特定のテクニックと方法 • _{Proven in Use（使用実績のある）ライブラリ/CPLD テクノロジの適用} • シミュレーションによるリファレンス・モデルに対するゲート・ネットリストの検証 • _{リファレンス・モデルとゲート・ネットリストの比較（フォーマル等価性検証)} 関連情報 • 2-10 ページのロジック・モジュール・デザイン設計のテスト • 2-14 ページのロジック・モジュール統合のテスト 2-18 _{ゲート・レベル・シミュレーションの実行} _2015.07.14MNL-1079 Altera Corporation システム障害の管理 フィードバック

(25)

ビットストリームの生成

このステップでは、（ビットストリーム生成としても知られている）プログラミング・ファイルを生成します。この手順は、コンパイル済みのデザインでデバイスをプログラミングする前に実行します。 Quartus II ソフトウェアのアセンブラは、最終的なネットリストを取り込み、目的の機能に対し FPGA ロジック・セルを設定するプログラミング・シーケンスを生成します。多くの場合、Quartus II ソフトウェアはこの手順を自動的に実行します。ビットストリームとストレージの生成にアセンブラを使用するには、いくつかのオプションがあります。入力 • 配置配線後のネットリスト • FPGA 要件の仕様（ビットストリーム・ストレージ・アプローチを含みます）出力 • デバイス・プログラミング・ファイル（.sof、.pof、.hex など）検証 • ツールが生成したレポート・ファイルを見直す • ハードウェアのチェック • プログラミング・ファイルのタイム・スタンプとデート・スタンプを確認する推奨ツール • Quartus II アセンブラ特定のテクニックと方法 • なし

アセンブラの詳細については、Quartus II Software Handbook v14.1 の以下のトピックを参照してく ださい。 • Volume 3：検証 • 第 18 章：Quartus II プログラマ

デザインの検証

このステップでは、ハードウェア内の最終的なデザインを検証します。プログラミング・ファイルの生成段階で生成されたビットストリームを取り込み、このファイルをハードウェアのデバイスに適用するために適切な手法を使用します。このステップの後、テスト記述のドキュメントが指定さする方法でデバイスの機能性を検証する必要があります。この検証が成功しない場合には、アルテラではデバッグに役立つ様々なイン・システム・デバッグ・ツールを提供しています。 • SignalTap II ロジック・アナライザ • Nios II Debugger • Quartus II PowerPlay パワー・アナライザ • Quartus II In-System Memory Editor

これらのテクニックとツールはデバッグにのみ使用し、最終的なシステムには適用しないでください。入力 MNL-1079 2015.07.14 ビットストリームの生成 2-19 システム障害の管理 Altera Corporation

(26)

• デバイス・プログラミング・ファイル（例：.sof、.pof、.hex）出力 • ハードウェア・テストの結果（ドキュメント）検証 • SignalTap II ロジック・アナライザ： • デバッグ IP コアがフィッタ・レポート・ファイルに含まれているかを確認する • 有効な結果を SignalTap II ロジック・アナライザで確認する • Nios II デバッガ： • 有効な結果をデバッグ・ツールで確認する • SignalTap II ロジック・アナライザを使用してデバッガあるいはメモリ・エディタの一貫性を確認する • ハードウェアの検証を使用してデバッグ・ツールが正しい出力を生成していることを確認する • Quartus II PowerPlay アナライザ： • 有効な結果を手動で確認する • データベースの一貫性を確認する（タイム・スタンプとデート・スタンプ） • レポート・ファイル・タイム、デート・スタンプ、およびモジュールが含まれていることを確認する • ハードウェアの消費電力をモニタする • テスト結果のピアレビュー • デバッグ IP コアがフィッタ・レポート・ファイルに含まれているかを確認する • 有効な結果をデバッグ・ツールで確認する • SignalTap II ロジック・アナライザを使用してデバッガあるいはメモリ・エディタの一貫性を確認する • ハードウェアの検証を使用してデバッグ・ツールが正しい出力を生成していることを確認する推奨ツール • SignalTap II ロジック・アナライザ • Nios II Debugger • Quartus II PowerPlay パワー・アナライザ • Quartus II In-System Memory Editor 特定のテクニックと方法 • _{最終的な検査と検証}

オートモーティブの機能安全向けのアルテラ・ツール

アルテラでは、V モデル・ステップで使用可能なさまざまなツールを提供しています。 Qsys Qsys コード生成ツールには ISO26262:2011-2012 に固有の要件があります。詳細については、 ISO26262-8:2011 の項 10 を参照してください。 2-20 _{オートモーティブの機能安全向けのアルテラ・ツール} _2015.07.14MNL-1079 Altera Corporation システム障害の管理 フィードバック

(27)

Qsys は、生成されたモジュールとアルテラの標準 IP コア間における接続をグラフィカルに表示します。これらのブロック間の接続には、以下のアルテラ・バス・プロトコルが使用されます。 • Avalon-MM インタフェース • Avalon-ST インタフェースサブモジュールと IP コアの間で接続が特定されると、コード生成段階が実行されます。この段階では、接続のグラフィカルな表現を取り入れ、モジュール・インスタンスおよびアービトレーション・ロジックやブリッジなどを含む接続の（V)HDL 記述ファイルが生成されます。この（V）HDL ファイルは手動でコード化した（V）HDL ファイルと同じ方法でデザイン内に含めることができます。

Qsys の詳細については、Quartus II Software Handbook v14.1 の以下のトピックを参照してくださ い。

• Volume 1：設計と合成

SignalTap IIロジック・アナライザ

Altera SignalTap® II ロジック・アナライザは、FPGA 内のリアルタイム信号の遷移をキャプチャし、表示します。つまり、デバイス内で関心のあるノードを指定すると、Quartus II コンパイラがそのノードを SignalTap II ブロックに接続し、デバイス内でインスタンス化します。動作中は、 SignalTap ブロックが一定のトリガ条件をもとにオンチップ・メモリへの信号の遷移をキャプチャします。SignalTap II ロジック・アナライザはその後、JTAG 経由でメモリの内容をホスト・コンピュータへ転送し、グラフィカルな形式でそれらを表示します。安全アプリケーションが「online」、つまりデザインが機能安全に関与している場合は、SignalTap II ロジック・アナライザは使用しないでください。

SignalTap II ロジック・アナライザの詳細については、Quartus II Software Handbook v14.1 の以下の トピックを参照してください。 • Volume 3：検証 • 第 13 章：SignalTap II ロジック・アナライザを使用したデザインのデバッグ Nios II_デバッガ Nios II ソフトウェア・デバッガは、ホストコンピュータが JTAG インタフェースを使用して、 FPGA 内の Nios II プロセッサに接続することを可能とします。ブレーク・ポインティング、STD アウト・レポートなどの標準的なソフトウェアのデバッグ方法には Nios II ソフトウェア・デバッガを使用してください。安全関連アプリケーションが「online」、つまりデザインが機能安全に関与している場合は、Nios II デバッガは使用しないでください。

Nios II デバッガの詳細については、Nios II Classic Software Developer's Handbook 2015.05.14 を参照し てください。

Quartus II In-System Memory Editor

Quartus II In-System Memory Editor は、ホスト・コンピュータからのオンチップ・メモリの内容の変更とリードバックを可能とします。このホスト・コンピュータは JTAG 接続を使用してデバイスに接続します。このツールは、デザインの実行動作中にメモリの内容を分析する場合に役立

MNL-1079

2015.07.14 オートモーティブの機能安全向けのアルテラ・ツール 2-21

(28)

ちます。このインシステム機能を有効にするよう設計時に設定した場合にのみ、オンチップ・メモリにアクセスすることができます。

安全関連アプリケーションが「online」、つまりデザインが機能安全に関与している場合は、In-System Memory Editor は使用しないでください。

In-System Memory Editor の詳細については、Quartus II Software Handbook v14.1 の以下のトピック を参照してください。 • Volume 3：検証 • 第 16 章：メモリおよび定数のインシステム修正 Quartus II PowerPlay_{パワー・アナライザ} Quartus II の PowerPlay パワー・アナライザは、デザイン・コンセプトの初期からデザインの実装段階までの消費電力の見積もりを可能とします。見積もり結果を得るには、環境条件とデザインで使用する予定のデバイス・リソース数（クロック、DSP ブロックなど）についての情報を入力します。デザインが部分的に完了している場合は、Quartus II ソフトウェアは、デバイスの電力消費量のより正確な見積もりを提供する PowerPlay early power estimator（初期消費電力量の見積もり）ファイルを生成することができます。

PowerPlay パワー・アナライザの詳細については、Quartus II Software Handbook v14.1 の以下のト ピックを参照してください。 • Volume 3：検証 • 第 8 章：PowerPlay 電力解析

アルテラ IP コア

デザインに様々な機能を実装するには、アルテラ IP コアの使用が適切である場合があります。アルテラは以下の 2 種類の IP コアを提供しています。 • メガファンクション • MegaCore ファンクションアルテラ・メガファンクションは、通常は PLL といった下位レベルのハード IP 機能です。このような機能の多くは、ユーザによる設定が可能です。アルテラでは一般的にこのような IP コアの設定に GUI を提供しており、これらはテキスト・ベースのコンフィギュレーション・ファイルを生成します。アルテラ MegaCore ファンクションは、通常は FPGA の汎用リソース内に実装する上位レベルの機能です。これには、DDR SDRAM コントローラや Ethernet MAC などが挙げられます。

IP コアの詳細については、Quartus II Software Handbook v14.1 の以下のトピックを参照してくださ い。 • Volume 1：設計と合成 • 第 2 章：Quartus II ソフトウェアによるデザイン・プランニング 2-22 _{アルテラ IP コア} _2015.07.14MNL-1079 Altera Corporation システム障害の管理 フィードバック

(29)

Nios II

_{プロセッサ}

アルテラは、Quartus II 開発ソフトウェア以外にも Nios II ソフト・プロセッサを提供しています。Nios II プロセッサは 32 ビット RISC（縮小命令セット・コンピュータ）プロセッサです。 Nios II プロセッサは、一般的な FPGA リソースで構成されており、ユーザが選択できる多数のコンフィギュレーション・オプションを備えています。アルテラは、Quartus II の各リリースで Nios II プロセッサのリグレッション・テストを実行しています。このテストデータ、および多くの使用経験は、安全関連のデザインにおいて Nios II プロセッサ・コアが適しているという証拠となります。Nios II プロセッサを使用する場合、Nios II プロセッサ・ベースのデザインに十分な診断カバレッジが提供されていることを確認します。この診断カバレッジは通常、Nios II プロセッサで動作するソフトウェアに実装します。プロセッサのファームウェアおよびハードウェアが正常に動作しているかを確認するには、これらのルーチンを使用することができます。このようなルーチンの一例としては、巡回冗長検査（CRC）の計算または Nios II プログラム・コードでの署名があります。適切なシステム・アーキテクチャを使用しているのであれば、Nios II プロセッサは独自のプログラム・コードでこの操作を実行することができます。これ以外の診断手法については、ISO26262:2011-2012 を参照してください。 Nios II プロセッサは、ユーザーが設計したソフトウェアを実行します。安全関連のソフトウェアを実行することは、ISO26262-6:2011 も適用可能であることを意味しています。本資料には、ハードウェアの組み込みと Nios II プロセッサの合成についてのガイドラインが含まれていますが、安全性に関連するソフトウェアの設計は ISO26262:2011-2012 の範囲内で実行するようにします。関連情報 • 2-6 ページの FPGA アーキテクチャの生成 • 8-1 ページの Nios II プロセッサを使用したソフトウェア開発 MNL-1079 2015.07.14 Nios IIプロセッサ 2-23 システム障害の管理 Altera Corporation