オートモーティブ機能安全マニュアル cyclone v...
TRANSCRIPT
オートモーティブ機能安全マニュアルCyclone V FPGAおよび Cyclone V SoC用
更新情報
フィードバック
MNL-10792015.07.14
101 Innovation DriveSan Jose, CA 95134www.altera.com
目次
オートモーティブの機能安全について...........................................................1-1
システム障害の管理.......................................................................................... 2-1アルテラの開発フロー.............................................................................................................................2-1ユーザー開発フロー.................................................................................................................................2-3
FPGA要件の仕様化...................................................................................................................... 2-5FPGAアーキテクチャの生成.................................................................................................... 2-6ロジック・モジュール・デザインに向けた設計記述の作成.......................................... 2-7ロジック・モジュール・デザインに向けたテスト記述の作成...................................... 2-8ロジック・モジュール・デザインのコーディング ............................................................2-9ロジック・モジュール・デザイン設計のテスト.............................................................. 2-10ロジック・モジュール・デザインへの障害の注入..........................................................2-11FMEDAの実行............................................................................................................................. 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-22Nios IIプロセッサ....................................................................................................................... 2-23
偶発ハードウェア障害の管理に向けた Cyclone Vアーキテクチャ.............3-1Cyclone Vの概要........................................................................................................................................3-1Cyclone Vがターゲットとするアプリケーション.......................................................................... 3-1Cyclone Vハードウェアのアーキテクチャ ........................................................................................3-1Cyclone Vの診断メカニズムおよび使用にあたっての前提条件................................................ 3-2
電源....................................................................................................................................................3-3クロック...........................................................................................................................................3-3リセット...........................................................................................................................................3-6入力/出力......................................................................................................................................... 3-7
目次-2 オートモーティブ機能安全マニュアル Cyclone V FPGAおよび Cyclone V SoC用
Altera Corporation
Cyclone V FPGAのコンフィギュレーション........................................................................ 3-8FPGAユーザ・メモリ................................................................................................................3-10
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ.....4-1Cyclone Vの概要........................................................................................................................................4-1Cyclone V SoCがターゲットとするアプリケーション.................................................................. 4-3Cyclone V SoCハードウェアのアーキテクチャ ............................................................................... 4-3Cyclone V SoCの診断メカニズムおよび使用にあたっての前提条件........................................4-5
電源....................................................................................................................................................4-5クロック...........................................................................................................................................4-6リセット.........................................................................................................................................4-12入力/出力....................................................................................................................................... 4-14Cyclone V SoCにおける FPGAのコンフィギュレーション .......................................... 4-16FPGAユーザ・メモリ................................................................................................................4-18HPSインタコネクト...................................................................................................................4-19HPS-FPGA間のインタコネクト............................................................................................. 4-22HPS Cortex-A9 MPUのサブシステム .................................................................................... 4-25HPSのデバッグとトレース..................................................................................................... 4-34HPS SDRAMコントローラ....................................................................................................... 4-36HPSオンチップ RAM.................................................................................................................4-38HPSオンチップ・ブート ROM...............................................................................................4-40HPS NANDフラッシュ・コントローラ............................................................................... 4-41HPS SD/MMCコントローラ.....................................................................................................4-43HPS Quad SPIフラッシュ・コントローラ...........................................................................4-45HPS FPGAマネージャ............................................................................................................... 4-47HPSシステム・マネージャ..................................................................................................... 4-48HPSスキャン・マネージャ..................................................................................................... 4-49HPS DMAC.....................................................................................................................................4-51HPSイーサネット・メディア・アクセス・コントローラ............................................ 4-53HPS USB 2.0 OTGコントローラ..............................................................................................4-56HPS SPIコントローラ................................................................................................................ 4-58HPS I2Cコントローラ............................................................................................................... 4-60UARTコントローラ....................................................................................................................4-62HPSタイマ.................................................................................................................................... 4-64HPSウォッチドッグ・タイマ................................................................................................. 4-65HPS CANコントローラ.............................................................................................................4-67
ISO26262に特化した FPGAデザイン用のテクニックと方法......................5-1デザイン入力.............................................................................................................................................. 5-1
Structured Description（構造化記述）..................................................................................... 5-1Design description in HDL（HDLによるデザインの記述）.............................................. 5-2回路図入力...................................................................................................................................... 5-2
オートモーティブ機能安全マニュアル Cyclone V FPGAおよび Cyclone V SoC用 目次-3
Altera Corporation
ブール式を使用したデザインの記述...................................................................................... 5-3モジュール化.................................................................................................................................. 5-3Proven in Use（使用実績のある）デザイン環境の適用.....................................................5-4HDLシミュレーション............................................................................................................... 5-5モジュール・レベルでの機能テスト...................................................................................... 5-6トップレベル・モジュールでの機能テスト......................................................................... 5-6Restricted 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-16ICベンダの要件と制約の確認................................................................................................ 5-16合成の制約、結果、ツールのドキュメンテーション..................................................... 5-17Proven in Use（使用実績のある）合成の適用.................................................................... 5-18Proven 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-26Layout Versus Schematic（LVS）チェック............................................................................. 5-27
チップ生産段階の安全性に関連する特殊な特性.......................................................................... 5-27Proven in Use（使用実績のある）プロセス・テクノロジの適用................................. 5-28Proven in Use（使用実績のある）デバイス・シリーズ...................................................5-28使用実績のある製造工程の適用.............................................................................................5-28製造工程における品質管理......................................................................................................5-29
目次-4 オートモーティブ機能安全マニュアル Cyclone V FPGAおよび Cyclone V SoC用
Altera Corporation
システム内の 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-1Qsysを使用した Nios IIシステムの作成............................................................................................8-1Nios IIシステム用のボート・サポート・パッケージの作成...................................................... 8-1アプリケーション・フレームワークの作成..................................................................................... 8-2アプリケーション・ソフトウェアの開発......................................................................................... 8-3ソフトウェアとハードウェアの統合.................................................................................................. 8-3ISO26262規格に含まれるツールとライブラリ................................................................................8-3ISO26262規格に含まれないサードパーティー製ツールとライブラリ....................................8-4
サポートされる（V）HDLのバージョン ...................................................... 9-1
改訂履歴............................................................................................................ 10-1
オートモーティブ機能安全マニュアル Cyclone V FPGAおよび Cyclone V SoC用 目次-5
Altera Corporation
オートモーティブの機能安全について 12015.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 ofIntel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to currentspecifications 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 expresslyagreed to in writing by Intel. Intel customers are advised to obtain the latest version of device specifications before relying on any published informationand before placing orders for products or services.*Other names and brands may be claimed as the property of others.
ISO9001:2008登録済
www.altera.com101 Innovation Drive, San Jose, CA 95134
システム障害の管理 22015.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 ofIntel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to currentspecifications 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 expresslyagreed to in writing by Intel. Intel customers are advised to obtain the latest version of device specifications before relying on any published informationand before placing orders for products or services.*Other names and brands may be claimed as the property of others.
ISO9001:2008登録済
www.altera.com101 Innovation Drive, San Jose, CA 95134
図 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 アルテラの開発フローMNL-1079
2015.07.14
Altera Corporation システム障害の管理
フィードバック
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-10792015.07.14 ユーザー開発フロー 2-3
システム障害の管理 Altera Corporation
フィードバック
図 2-2: ユーザーによる Vモデル開発フロー
Validate DesignPlan Tests
PerformFMEDA
InjectFaults
Specify FPGARequirements
Generate FPGAArchitecture
GenerateBitstream
Perform Gate-Level Simulation
Perform Static Timing Analysis
Perform Placeand Route
Perform Synthesis
Create DesignDescription
Create Test Plan
Test
Code
Create DesignDescription
Create Test Plan
Test
Code
Logical Module Design
Logical Module Integration
各 Vモデル・ステップの記述には以下の情報が含まれます。• Vモデル・ステップの記述。• 入力。 Vモデル・ステップへの入力のリスト。これには、プロジェクトのドキュメントやデザイン・ファイルなどが含まれます。
• 出力。Vモデル・ステップの出力のリスト—入力を処理する際の最終的な結果。これには、出力ネットリスト、検証パス、成功しなかったステータスなどが含まれます。
• 検証。 Vモデル・ステップが正しく行われていることを検証します。アルテラでは例を提供していますが、独自の方法を用いることも可能です。検証または Vモデルステップ中にツールを使用する場合は、検証を補助するためにツールの出力を評価しなければなりません。ツールが生成したエラー、警告、およびレポート・ファイルを評価する必要があります。
• 推奨ツール。特定の Vモデル・ステップを実装するにあたって、このソフトウェア・ツールのリストを使用することができます。1つのツールのみが利用可能なケースもありますが、ほとんどのは場合多くのオプションが利用可能です。
• 特定のテクニックと方法。このリストは、各ステップに適用される標準で明示的な参照を示しています。本資料中のトピックには、これらのテクニックと方法を満たすことができる手法を解説するアルテラ固有の情報が含まれます。
2-4 ユーザー開発フローMNL-1079
2015.07.14
Altera Corporation システム障害の管理
フィードバック
注意: 開発段階で要件のトレーサビリティに向けての何らかの手段を用いることを推奨しています。アルテラはこの過程を全体の安全性要件の一部であると考えており、各 Vモデル・ステップはこれについて明示的に言及していません。
FPGA要件の仕様化このステップでは、FPGAサブシステムの全体的な機能性を明確に記述します。この記述には高レベルの仕様項目とデバイス全体の機能性の詳細が含まれます。高レベルのシステム要件を分析し、FPGAが実行する機能を引き出します。FPGA要件の仕様には以下が含まれます：• 高レベルの機能要件• サブシステムの性能• 必要な外部インタフェースこの段階で仕様化が可能なアイテム：• FPGAデバイス・ファミリ。• パフォーマンス。例：デバイスの動作クロックの周波数• パフォーマンスとシンセシスの設定。例：フィジカル・シンセシスの使用• IPコアの使用およびソフトウェアの仕様。• デザイン言語とバージョン。• 外部 I/Oの制約（速度、電圧、分離）。この Vモデルのステップに適用できるアルテラのプロセスまたはツールはありません。入力：• アイテム要件の仕様• 安全コンセプト出力：• 詳細な FPGA要件の仕様• 検証報告書検証：• 入力ドキュメントに対する詳細な FPGA要件の仕様の手続き型クロスチェック。例：番号付きアイテムの使用
• 相互評価の詳細な FPGA要件の仕様推奨ツール：• 要件管理ツール（例：IBM DOORSまたは TechnoSolutions TopTeamなど）特定のテクニックと方法：• なし
MNL-10792015.07.14 FPGA要件の仕様化 2-5
システム障害の管理 Altera Corporation
フィードバック
要件の仕様と管理に関するより具体的な情報については、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アーキテクチャの生成MNL-1079
2015.07.14
Altera Corporation システム障害の管理
フィードバック
検証：• 入力ドキュメント・アイテムに対する出力ドキュメント・アイテムの手続き型クロスチェック。例：番号付きアイテムの使用
• アーキテクチャのピアレビュー。推奨ツール：• 標準的な作図パッケージ（例：Microsoft Visio）• 標準的な文書作成パッケージ（例：Microsoft Word）• 要件管理ツール（例：IBM DOORSまたは TechnoSolutions TopTeamなど）特定のテクニックと方法；• なしハードウェア・アーキテクチャの設計に関する詳細な要件については、ISO26262 -5:2011 clause7.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-10792015.07.14 ロジック・モジュール・デザインに向けた設計記述の作成 2-7
システム障害の管理 Altera Corporation
フィードバック
• 詳細なデザインの設計記述• モジュール・レベルのビヘイビア・モデル• 検証報告書検証• 出力デザイン・ドキュメントを持つ入力仕様の手続き型クロスチェック。例：番号付きアイテムの使用
• ドキュメントのピアレビュー。推奨ツール• 標準的な文書作成パッケージ（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 ロジック・モジュール・デザインに向けたテスト記述の作成MNL-1079
2015.07.14
Altera Corporation システム障害の管理
フィードバック
特定のテクニックと方法• なしハードウェアの設計に関する詳細な要件については、ISO26262-5:2011 clause 7.4.4を参照してください。
ロジック・モジュール・デザインのコーディングこのステップでは、詳細なモジュールの機能の記述を合成可能なデザインの記述に変換します。これは通常、回路機能の（V）HDL記述の形式をとり、デザイン入力に対しては標準的なテキスト・エディタを使用します。注意: この資料内の（V）HDLという用語は、Verilog HDLまたは VHDLのいずれかを意味しま
す。デザイン入力には様々な方法を選択することができます。デザインの実装に適した方法を決定するには、数多くある特定のテクニックと方法（5－1ページの ISO26262に特化した FPGAデザイン用のテクニックと方法）の中から、各デザイン入力の方法の適正を評価します。参照先のISO26262には、アルテラ・ツールを使用したこのようなテクニックと方法の実装方法が詳細に記載されています。この Vモデル・ステップは、アルテラのツールやプロセスを必要としません。ただし、QuartusIIソフトウェアを使用しているのであれば、正しい言語構文および精緻化エラーをチェックするには、解析およびエラボレーション機能を使用することができます。解析およびエラボレーションは、デザインに正しいソース・コードの構文と接続が使用されているかどうかをチェックする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-10792015.07.14 ロジック・モジュール・デザインのコーディング 2-9
システム障害の管理 Altera Corporation
フィードバック
解析およびエラボレーションの詳細については、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 ロジック・モジュール・デザイン設計のテストMNL-1079
2015.07.14
Altera Corporation システム障害の管理
フィードバック
• テストのパス/フェイル・ステータス• （デバッグで使用する）テストのパス/フェイル診断検証• ツールの使用• テスト結果のピアレビュー• 有効なシミュレータ出力を手動でチェックします• レポート・ファイルの存在、およびタイム・スタンプあるいはデート・スタンプのチェック• シミュレーション・ライブラリ・ファイルのタイム・スタンプあるいはデート・スタンプのチェック
推奨ツール• サードパーティー製シミュレーション・ツール。これらの解説は本資料には含まれません。
• 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-10792015.07.14 ロジック・モジュール・デザインへの障害の注入 2-11
システム障害の管理 Altera Corporation
フィードバック
検証• ツールの使用• テスト結果のピアレビュー推奨ツール• サードパーティ製の故障注入ツール• サードパーティ製のシュミレーション・ツール• アルテラのシミュレーション・ライブラリ（オプション）特定のテクニックと方法• 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の実行MNL-1079
2015.07.14
Altera Corporation システム障害の管理
フィードバック
• 適用されません
ロジック・モジュール統合に向けた設計記述の作成このステップでは、抽象化レベルがモジュール統合レベルである点を除き、ロジック・モジュール・デザインに向けた設計記述の作成と同じテクニックを使用します。各モジュール間の統合を記述するための基礎として、FPGAアーキテクチャのドキュメントを使用することができます。
関連情報2-7ページの ロジック・モジュール・デザインに向けた設計記述の作成
ロジック・モジュール統合に向けたテスト記述の作成このステップでは、テストがより高いレベルのブロックおよびサブシステムに特化されているという点を除き、ロジック・モジュール・デザインに向けたテスト記述の作成と同じテクニックを使用します。このテスト記述はフルチップのテスト時にターゲットとすることができます。関連情報2-7ページの ロジック・モジュール・デザインに向けた設計記述の作成
ロジック・モジュール統合のコーディングこのステップでは、前の段階で開発した個々のモジュールを統合します。この時点で、これらのモジュールを組み合わせることで、より高いレベルの機能と最終的なトップレベルの FPGAの設計を作成します。 Quartus IIソフトウェアはモジュールの統合を簡易化するコード生成ツール（Qsys）を搭載しており、特にアルテラ IPコアと Nios IIプロセッサを使用する場合はモジュール統合を非常に簡単に実行することができます。入力• モジュール・デザイン・ファイル• ロジック・モジュール・デザイン—機能の記述• FPGAアーキテクチャ出力• チップ・レベルまたはサブシステム・レベルのデザイン・ファイル検証• 自動化されたステップのレポート・ファイルの出力を分析する（これは Nios IIソフトウェア・ビルド・ツールにも適用されます）
• VHDLソース・ファイルのタイム・スタンプとデート・スタンプを確認する（これは Nios IIソフトウェア・ビルド・ツールにも適用されます）
• Qsysが生成した階層を検査する（Qsyｓを使用した場合）推奨ツール• 標準的なテキスト・エディタ• Quartus II Qsys
特定のテクニックと方法
MNL-10792015.07.14 ロジック・モジュール統合に向けた設計記述の作成 2-13
システム障害の管理 Altera Corporation
フィードバック
• モジュール化を参照してください。• 検証済みのソフト・コアの適用を参照してください。• ソフト 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 ロジック・モジュール統合のテストMNL-1079
2015.07.14
Altera Corporation システム障害の管理
フィードバック
合成の実行このステップでは FPGA合成ツールを使用します。合成ツールは指定した入力デザイン・ファイルを受け取り、ロジック・ファンクションを Quartus IIソフトウェアがターゲットとするアルテラ FPGAのロジック・セルのストラクチャ内に実装できるフォーマットに変換します。QuartusIIソフトウェアには 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-10792015.07.14 合成の実行 2-15
システム障害の管理 Altera Corporation
フィードバック
• 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 配置配線の実行MNL-1079
2015.07.14
Altera Corporation システム障害の管理
フィードバック
FPGAの全体的なシステム・パフォーマンスを FPGA要件のドキュメントで指定することができます。 FPGAアーキテクチャのドキュメントでは、デザイン内のサブシステムのタイミングを指定することができます。アルテラは、Quartus IIソフトウェアに TimeQuestタイミング解析ツールを搭載しています。ユーザー提供のタイミング制約のセットに対してタイミング・パフォーマンスを検証するには、この包括的なツールを使用してください。タイミング制約は、全体的な FPGAデザインの重要な部分であるため、慎重に設計し、管理する必要があります。FPGAデザイン・サイクルの初期段階でタイミング制約を開発します。QuartusIIソフトウェアは合成とフィッティングの際にタイミング制約を使用します。例えば、合成と配置配線のステップでタイミング制約を使用すれば、速度や面積の最適化でより良い結果が得られます。入力：• タイミング制約• FPGAアーキテクチャ• FPGA要件の仕様• デバイスのタイミング・モデル• 配置配線後のネットリスト出力：• タイミング・レポート・ファイル検証：• タイミング障害のツール出力ファイルを見直す• ツールからの有効な結果を確認する
• ツールが正しい制約（.sdc）ファイルを読み出していることを確認する• クロック・サマリ・レポートを確認する• マクロが生成するすべてのサマリのレポートを確認する
• レポート・ファイルの存在とタイム・スタンプおよびデート・スタンプを確認する• レポート・ファイル内で制約されていないパスを確認する推奨ツール：• Quartus II TimeQuest Timing Analyzer
特定のテクニックと方法：• 合成の制約、結果、ツールのドキュメンテーションを参照してください。• 伝播遅延のスタティック・タイミング解析（STA）を参照してください。• 適切なタイミング・マージンを参照してください。使用期間が 3年以下のプロセス・テクノロジのデバイス・ファミリを使用する場合のタイミング制約を変更するにあたっての特定の要件についての詳細な情報は、適切なタイミング・マージンを参照してください。
ゲート・レベル・シミュレーションの実行このステップでは、前段階のプロセスを検証します。配置配線ステップの出力であるネットリストでデザインをシミュレーションします。ツールは論理合成を実行することでこのネットリストを生成するだけなので、合成ツールの動作も検証します。
MNL-10792015.07.14 ゲート・レベル・シミュレーションの実行 2-17
システム障害の管理 Altera Corporation
フィードバック
ロジック・モジュール・デザイン設計のテストとロジック・モジュール統合のテストで生成するシミュレーション・テストベンチを再利用することが一般的ですが、この段階で開発に追加のテストを提供することを決定することができます。この要件は、FPGA要件の仕様または FPGAアーキテクチャのドキュメント内で記述します。ロジック・シミュレータに関連するすべてのタイミング情報を提供するという点を除いては、タイミングが正確なゲート・レベルのシミュレーションは、通常のゲート・レベルのシミュレーションと同じです。このプロセスでは、デザインないのタイミング違反が表示されることがあります。機能ゲート・レベル・シミュレーションに加えて、このステップを実行することができます。または、機能ゲート・レベル・シミュレーションはこのステップを置き換えることができます。使用期間が 3年以下のプロセス・テクノロジのデバイス・ファミリを使用する場合のタイミング制約を変更するにあたっての特定の要件についての詳細な情報は、適切なタイミング・マージンを参照してください。入力• 配置配線後のネットリスト• ロジック・モジュール・テストの記述とテストベンチ• ロジック・モジュール統合テストの記述とテストベンチ出力• テストのパス/フェイル・ステータス• （デバッグで使用する）テストのパス/フェイル診断検証• テスト結果のピアレビュー• 有効なシミュレータの出力を手動で確認する
• 手動で波形を確認する• ポート・ファイルのパス/フェイル・ステータスを手動で確認する
• レポート・ファイルの存在とタイム・スタンプおよびデート・スタンプを確認する推奨ツール• サードパーティー製シミュレーション・ツール。これらの解説は本資料には含まれません。
• Mentor ModelSim• Cadence NCSIM• Synopsys VCS
• アルテラのシミュレーション・ライブラリ特定のテクニックと方法• Proven in Use（使用実績のある）ライブラリ/CPLDテクノロジの適用• シミュレーションによるリファレンス・モデルに対するゲート・ネットリストの検証• リファレンス・モデルとゲート・ネットリストの比較（フォーマル等価性検証)
関連情報• 2-10ページの ロジック・モジュール・デザイン設計のテスト• 2-14ページの ロジック・モジュール統合のテスト
2-18 ゲート・レベル・シミュレーションの実行MNL-1079
2015.07.14
Altera Corporation システム障害の管理
フィードバック
ビットストリームの生成このステップでは、（ビットストリーム生成としても知られている）プログラミング・ファイルを生成します。この手順は、コンパイル済みのデザインでデバイスをプログラミングする前に実行します。 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-10792015.07.14 ビットストリームの生成 2-19
システム障害の管理 Altera Corporation
フィードバック
• デバイス・プログラミング・ファイル（例：.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 オートモーティブの機能安全向けのアルテラ・ツールMNL-1079
2015.07.14
Altera Corporation システム障害の管理
フィードバック
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」、つまりデザインが機能安全に関与している場合は、SignalTapIIロジック・アナライザは使用しないでください。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」、つまりデザインが機能安全に関与している場合は、NiosIIデバッガは使用しないでください。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-10792015.07.14 オートモーティブの機能安全向けのアルテラ・ツール 2-21
システム障害の管理 Altera Corporation
フィードバック
ちます。このインシステム機能を有効にするよう設計時に設定した場合にのみ、オンチップ・メモリにアクセスすることができます。安全関連アプリケーションが「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コアMNL-1079
2015.07.14
Altera Corporation システム障害の管理
フィードバック
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-10792015.07.14 Nios IIプロセッサ 2-23
システム障害の管理 Altera Corporation
フィードバック
偶発ハードウェア障害の管理に向けたCyclone Vアーキテクチャ 3
2015.07.14
MNL-1079 更新情報 フィードバック
Cyclone Vの概要Cyclone Vは Cycloneプロダクトの第 5世代であり、28nm LPプロセスで製造されています。デバイス・ファミリは主に、FPGAファブリック内で使用できるロジック・エレメント（LE）の個数で区別されます。
Cyclone VがターゲットとするアプリケーションAltera® Cyclone® Vデバイスは産業およびオートモーティブ分野において機能安全を重視するアプリケーションでの使用を含む多様なアプリケーション要件を満たします。これには以下が含まれます。• 先進運転支援システム• ハイブリッド車や電気自動車向けモータ制御および DC-DCコンバー タ• インフォテインメント ･ システムアルテラは、Cyclone Vの開発にあたって SEooC（Safety Element out of Context）方法論を採用しています。FPGAは、標準的なコンポーネント（例：マイクロ・コントローラ）の使用と比較してユーザに一定の責任をシフトするユーザ定義のロジック IPとアプリケーションの統合に高度な柔軟性を提供します。コンポーネント・レベルのみでは ISO26262:2011-2012の機能安全の達成は不可能です。むしろ、アイテムの全体的な安全コンセプトとして機能します。アルテラの Cyclone V製品は、アイテムに対しターゲットとする ASILレベルの達成の簡易化を可能にします。
Cyclone VハードウェアのアーキテクチャCyclone Vデバイスのアーキテクチャは、必要に応じてアプリケーション実行中に使用可能なクロック、電源、メモリなどを継続して動作させる診断手法を含みます。アプリケーションは、アプリケーションを実行する安全性が重要な部分にこれらの機構を使用する前に、正しく動作することを確認しておく必要があります。
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks ofIntel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to currentspecifications 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 expresslyagreed to in writing by Intel. Intel customers are advised to obtain the latest version of device specifications before relying on any published informationand before placing orders for products or services.*Other names and brands may be claimed as the property of others.
ISO9001:2008登録済
www.altera.com101 Innovation Drive, San Jose, CA 95134
図 3-1: Cyclone Vの上位レベルのブロック図
次の図は、Cyclone Vアーキテクチャの上位レベルのブロック図を示します。
Altera FPGA Device
ControlBlock
UserI/O
HSSITransceivers
FPGA Fabric(LUTs, RAMs, Multipliers & Routing)
PLLs HardPCIe
Hard MemoryControllers
FPGAは柔軟性に富むため、独自のハードウェア・アクセラレータを実装できるオプションがあります。また、システムあるいはチップ内の障害を検出する目的で、カスタムの診断機能を作成することも可能です。Cyclone Vデバイス上の一部のモジュールは、あらかじめハードウェア診断が組み込まれていますが、。他のモジュールは、偶発ハードウェア障害を検出するにあたって、システム・レベルの概念に依存しています。
Cyclone Vの診断メカニズムおよび使用にあたっての前提条件この項では、潜在的な障害を検出する目的でアプリケーション内の IPコアまたは機能に実装された診断メカニズムおよびアプリケーション内の IPコアまたは機能の使用にあたっての前提条件について説明します。この項では、該当する場合は ISO26262:2011-2012をはじめとするドキュメントを参照します。特定の IPコアまたは機能の前提条件の表は、以下の推奨レベルがあります。• Mは必須を表します• ++は強く推奨を表します• +は推奨を表します• Oはオプションを表します各表には、ISO26262:2011-2012による潜在的な診断メカニズムを示しています。
3-2 Cyclone Vの診断メカニズムおよび使用にあたっての前提条件MNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone Vアーキテクチャ
フィードバック
電源
内部電圧モニタ
Cyclone Vデバイスは、いくつかの電源レールに向けて内部電圧モニタを実装します。特定のレールの電圧が仕様以外であれば、デバイスは内部リセットを発行します。アルテラは、モニタされていない電圧レールに向けて異なる電圧モニタがアイテムによって実装されていると想定しています。Cyclone V Device Handbookを参照してください。• Volume 1：デバイスのインタフェースおよび統合• 第 10章：Cyclone Vデバイスの電源管理
電源レールCyclone V FPGAはコア・ロジックおよび I/Oに対し、FPGAファブリックの電圧レールをサポートします。供給電圧の影響に関係する FPGAファブリック内の一般的な障害を効率的に軽減することができます。アルテラは、アプリケーションが FPGAファブリックに専用の電源を提供することを想定しています。詳細については、「Cyclone V Device Family Pin Connection Guidelines」の資料番号 PCG-01014を参照してください。
Cyclone V FPGAの電源の使用前提
表 3-1: 電源の使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
PWR1 内部電圧モニタ M 外部電圧モニタ
PWR2 外部電圧スーパーバイザー
++ 内部電圧モニタ
クロック
クロック入力Cyclone V FPGAは、クロックに関連する一般的な障害を防ぐことができる複数のクロック入力をサポートしています。複数の入力クロックによって FPGAファブリック内のクロックを駆動することが可能です。また、複数の独立したクロック・ネットワークによって FPGAファブリック内のロジックを駆動することも可能です。Cyclone V Device Handbookを参照してください。
MNL-10792015.07.14 電源 3-3
偶発ハードウェア障害の管理に向けた Cyclone Vアーキテクチャ Altera Corporation
フィードバック
• Volume 1：デバイスのインタフェースおよび統合• 第 4章：Cyclone Vデバイスのクロック・ネットワークおよび PLL
FPGAのクロッキングFPGAファブリックは、異なる PLLを持つクロックを個別に生成可能な非常に柔軟なクロック・ネットワーク・トポロジを提供します。異なるクロック・ネットワークによって駆動されるロジックを分離することが可能です。詳細は、Cyclone V Device Handbookを参照してください。• Volume 1：デバイスのインタフェースおよび統合• 第 4章：Cyclone Vデバイスのクロック・ネットワークおよび PLL
PLL数PLLは、デバイス・クロックの理、外部システム・クロックの管理、および高速 I/Oインタフェースに向けて堅牢なクロック管理および合成機能を提供します。 Cyclone Vデバイス・ファミリは、フラクショナル PLLあるいは整数 PLLとしても機能できるフラクショナル PLLが含まれています。Cyclone Vデバイスの出力カウンタは、整数またはフラクショナル周波数合成をサポートする各フラクショナル PLLに使用されます。
クロック・スイッチオーバー機能Cyclone Vのクロック・スイッチオーバー機能により、PLLは 2つの基準入力クロックを切り換えることができます。この機能はクロック冗長性のために、あるいは前のクロックが停止した場合に冗長クロックがオンになるシステムであるデュアル・クロック・ドメイン・アプリケーションに使用します。クロックがそれ以上トグルしないとき、またはユーザーのコントロール信号に応じて、デザインは自動的にクロック・スイッチオーバーを実行することができます。
PLLクロックの出力Cyclone Vのほとんどの PLLは、PLLごとに専用クロック出力もドライブすることができます。外部チェック・ロジックはこれを使用して PLLに関連するクロックの問題を検知することが可能です。
FPGA PLLロック信号Cyclone V FPGAファブリック内の PLLは、PLLが入力クロックにロックされていることを示すロック信号も提供します。 入力クロックに対して正しい周波数で PLLが実行されていることを確認するには、この信号を使用します。詳細は、Cyclone V Device Handbookを参照してください。• Volume 1：デバイスのインタフェースおよび統合• 第 4章：Cyclone Vデバイスのクロック・ネットワークおよび PLL
コンフィギュレーション・レジスタの定期的なリード・バック
コンフィギュレーション・レジスタが正確であることを確認するには、レジスタの内容をリード・バックし、その内容と意図した値と比較します。その値をレジスタに書き込み、このリード・バックを定期的に繰り返し実行します。
3-4 FPGAのクロッキングMNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone Vアーキテクチャ
フィードバック
注意: 一部のレジスタは、レジスタをリードする際に自動でクリアするビットを実装することができます。アプリケーションのビヘイビアが変更されることがあるので、リードが一部のビットのステータスに影響を与えることがないようにします。
表 3-2: ISO26262リファレンス：Configuration Register Test
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
Clock Checker Diagnostic IPコア
この IPコアを使用すると、安定したリファレンス・クロックに対し入力クロックの周波数と存在のオンライン・チェッキングを提供することで、デザインの診断カバレッジを拡大することができます。また、FPGAデバイス内の PLLの正しい機能を確認したり、安全性に関連するデザイン内の他のシステム・クロックを確認するには、この IPコアを使用することができます。高周波数と低周波のしきい値は指定可能です。テストするクロックが指定したしきい値を超える場合は、IPコアはシステムにエラー信号を生成し、警告します。
表 3-3: ISO26262リファレンス：Comparator
ソース 参照先
ISO26262-5:2011 Annex D Table D.2 Comparator
ISO26262-5:2011 Annex D Section D.2.1.2
Cyclone V FPGAのクロックの使用前提
表 3-4: Cyclone V FPGAのクロックの使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
CLK1 FPGAファブリックに向けた個別の外部クロック入力の使用
+ 1. クロック・グループを FPGAファブリックへ配線するClock CheckerDiagnostic IPコア
2. ウォッチドッグ3. 外部ピンのクロック・ドメイン出力
MNL-10792015.07.14 Clock Checker Diagnostic IPコア 3-5
偶発ハードウェア障害の管理に向けた Cyclone Vアーキテクチャ Altera Corporation
フィードバック
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
CLK2 FPGAファブリック内でインスタンス化されるClock Checker DiagnosticIPコアを使用したクロック領域の管理
++ 1. ウォッチドッグ2. 外部ピンのクロック・ドメイン出力
CLK5 FPGAファブリック内のウォッチドッグ
++ 1. 外部のウォッチドッグ
2. SWテスト・コンフィギュレーション・レジスタと意図する機能
CLK6 外部のウォッチドッグ ++ 1. 内部のウォッチドッグ
2. SWテスト・コンフィギュレーション・レジスタと意図する機能
CLK7 FPGAファブリックのPLLが欠如したクロック検出とセカンダリ・クロックへの自動切り替え
++ 1. Clock CheckerDiagnostic IPコア
2. クロック出力3. SWテストのコンフィギュレーション・レジスタ
CLK8 FPGA fabric PLL clockoutput
O 1. Clock CheckerDiagnostic IPコア
2. PLLが欠如した入力クロックの検出
CLK9 FPGAファブリック PLL固定信号
O 1. Clock CheckerDiagnostic IPコア
2. PLLが欠如した入力クロックの検出
関連情報3-5ページの Clock Checker Diagnostic IPコア
リセットCyclone V FPGAは、FPGAの柔軟なリセット処理を提供します。
3-6 リセットMNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone Vアーキテクチャ
フィードバック
FPGAのリセット
電源投入時に、FPGAのコンフィギュレーションに必要な電圧モニタする内部リセット電圧スーパーバイザーが、内部パワー・オン・リセット（POR）を生成します。リセットの継続時間は、ユーザにて選択が可能です。nSTATUS信号と CONF_DONE信号がコンフィギュレーションの完了を表します。INIT_DONE信号は適切な初期化を表し、この信号を Highにプルアップした後デザインが実行されます。FPGAファブリックにプログラミングするロジックに適切なリセットを設定する必要があります。詳細は、Cyclone V Device Handbookを参照してください。• Volume 1：デバイスのインタフェースおよび統合• 第 7章：Cyclone Vデバイスのコンフィギュレーション、デザイン・セキュリティ、およびリモート・システム・アップグレード
コンフィギュレーション・レジスタの定期的なリード・バックコンフィギュレーション・レジスタが正確であることを確認するには、レジスタの内容をリード・バックし、その内容と意図した値と比較します。その値をレジスタに書き込み、このリード・バックを定期的に繰り返し実行します。注意: 一部のレジスタは、レジスタをリードする際に自動でクリアするビットを実装することが
できます。アプリケーションのビヘイビアが変更されることがあるので、リードが一部のビットのステータスに影響を与えることがないようにします。
表 3-5: ISO26262リファレンス：Configuration Register Test
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
入力/出力
FPGAファブリックの I/O
FPGAファブリックの I/Oストラクチャは非常に柔軟であり、多くのアプリケーションの要件を満たすよう設定することができます。Cyclone Vデバイスは各シングルエンド I/Oを双方向ピンとして実装しているため、入力バッファを介して出力として設定されたピンのステータスをリード・バックすることが可能です。詳細は、Cyclone V Device Handbookを参照してください。• Volume 1：デバイスのインタフェースおよび統合• 第 5章：Cyclone Vデバイスの I/O機能
MNL-10792015.07.14 FPGAのリセット 3-7
偶発ハードウェア障害の管理に向けた Cyclone Vアーキテクチャ Altera Corporation
フィードバック
コンフィギュレーション・レジスタの定期的なリード・バックコンフィギュレーション・レジスタが正確であることを確認するには、レジスタの内容をリード・バックし、その内容と意図した値と比較します。その値をレジスタに書き込み、このリード・バックを定期的に繰り返し実行します。注意: 一部のレジスタは、レジスタをリードする際に自動でクリアするビットを実装することが
できます。アプリケーションのビヘイビアが変更されることがあるので、リードが一部のビットのステータスに影響を与えることがないようにします。
表 3-6: ISO26262リファレンス：Configuration Register Test
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
Cyclone V FPGAの I/Oの使用前提
表 3-7: I/O：Cyclone V FPGAでの使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
IO1 入力バッファを経由した出力ピン・ステータスの FPGAファブリックI/Oリード・バック
++ 1. 専用の独立したチェック・ロジック
IO3 コンフィギュレーション・レジスタの定期的なリード・バック
+ 1. Cortex-A9を使用したレジスタ内容のリード・バック
Cyclone V FPGAのコンフィギュレーション電源投入時に、FPGAはコンフィギュレーション内容をロードし、アプリケーション回路を作成します。コンフィギュレーション・シーケンス中、外部モニタを使用して進捗をモニタするにはステータス信号（nSTATUS、nCONFIG、CONF_DONE、INIT_DONE）を使用することができます。詳細は、Cyclone V Device Handbookを参照してください。• Volume 1：デバイスのインタフェースおよび統合• 第 7章：Cyclone Vデバイスのコンフィギュレーション、デザイン・セキュリティ、およびリモート・システム・アップグレード
CRCバックグラウンド・チェック
FPGAファブリックのコンフィギュレーション内容は CRAM（Configuration RAM）に格納されます。CRAMに格納されたコンフィギュレーション・フレーム別に CRCを計算する連続バックグ
3-8 コンフィギュレーション・レジスタの定期的なリード・バックMNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone Vアーキテクチャ
フィードバック
ラウンド・チェックをイネーブルすることができます。CRCは、シングルとマルチビット障害を検出し、CRC_ERRORピンを介して検出された問題を表示することができます。このバックグラウンド・チェックが実装した回路の通常の機能に影響を与えることはありません。CRC回路が検出した障害に間違いがないことを検証するには、CRC計算に障害を注入し CRAMの変化をエミュレートします。
センシティビティ・マップデザインは SRAMセルをすべて使用するわけではありません。使用しているセルに障害が発生する場合にのみ、回路のビヘイビアに影響が現れます。Quartus IIソフトウェアは、検出された障害が「care」ビットあるいは「don’t care」 ビットで発生したものであるかの判断に使用できるセンシティビティ・マップを生成します。
図 3-2: センシティビティ・マップ
CRCEngine
SensitivityProcessor
(Soft Logic)
MemoryAccess Logic
ExternalSerial/Parallel
Flash
CRC Error
CRITICAL_ERRORLocationInformation
FPGA
この深刻なエラー検出ソリューションの手順は、以下のとおりです。1. 内蔵のソフト・エラー検出回路がコンフィギュレーション・ソフト・エラーを検出・特定し、
CRC_ERRORピンをアサートします。2. 次に、ソフト・ロジックがエラー情報を受け取り、その情報を使用して、コンフィギュレーション・ビットのどれが「care」で、どれが「don’t care」であるかを示すマップを含むファイル内のアドレスを算出します。
3. 次に、ソフト・ロジックは、アクティブ・シリアル・コンフィギュレーション・ポートなどのユーザー指定メモリ・インタフェースを使用して、センシティビティ・マップ・ファイル内の該当ビットにアクセスし、FPGAに現在コンフィギュレーションされているデザインにとって、そのコンフィギュレーション・ソフト・エラーが重大かどうかを判定します。
4. コンフィギュレーション・ソフト・エラーが「don’t care」である場合、FPGAは動作エラー無しで機能し続けることができます。コンフィギュレーション・ソフト・エラーが「care」で、動作に影響を与える可能性がある場合は、Cyclone V FPGAまたは FPGAが CRITICAL_ERRORピンをアサートするため、システム上の適切な動作を実行することができます。
詳細は、Cyclone V Device Handbookを参照してください。• Volume 1：デバイスのインタフェースおよび統合• 第 8章：Cyclone Vデバイスでの SEUの緩和
MNL-10792015.07.14 センシティビティ・マップ 3-9
偶発ハードウェア障害の管理に向けた Cyclone Vアーキテクチャ Altera Corporation
フィードバック
冗長ロジックの実装FPGAファブリックのコンフィギュレーションにて障害を検出しやすくするには、デザインに冗長ロジックを含めた後、冗長ロジックの出力を比較します。
Cyclone V FPGAの FPGAコンフィギュレーションの使用前提
表 3-8: FPGAコンフィギュレーションの使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
FPGA_CONF1 外部モニタによるコンフィギュレーション・ステータス信号のモニタ
+ 1. ウォッチドッグ
FPGA_CONF3 CRAMコンフィギュレーションの継続的なCRCバックグラウンド・チェック
++ 1. バックグラウンド・チェックでの定期的な障害の注入
FPGA_CONF4 センシティビティ・マップの決定
O 1. 冗長の実行
FPGA_CONF5 冗長ロジック + 1. テスト・パターン
FPGAユーザ・メモリCyclone Vデバイスの FPGAファブリックは、M10KブロックまたはMLAB内でユーザ・メモリを提供します。これらのブロックにはそれぞれ、エラー検出コードおよびエラー訂正コード（ECC）に対し特別なユーザ機能が使用できる専用パリティ・ビットを実装しています。この機能は、Quartus IIソフトウェアのソフト IPによってサポートされています。詳細は、Cyclone V Device Handbookを参照してください。• Volume 1：デバイスのインタフェースおよび統合• 第 2章：Cyclone Vデバイスのエンベデッド・メモリ・ブロック
FPGAメモリの使用前提
表 3-9: FPGAメモリ：使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
FPGA_UM1 ユーザー・メモリ向けECC
++ 1. フォールト・インジェクション・テスト
3-10 冗長ロジックの実装MNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone Vアーキテクチャ
フィードバック
偶発ハードウェア障害の管理に向けたCyclone V SoCアーキテクチャ 4
2015.07.14
MNL-1079 更新情報 フィードバック
Cyclone Vの概要Cyclone Vは Cycloneプロダクトの第 5世代であり、28nm LPプロセスで製造されています。Cyclone Vは、HPSとユーザによるプログラムが可能なロジック・ファブリックを装備しています。デバイス・ファミリは主に、FPGAファブリック内で使用できるロジック・エレメント（LE）の個数で区別されます。デバイス・ファミリ間の HPSは同一のものを使用しています。
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks ofIntel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to currentspecifications 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 expresslyagreed to in writing by Intel. Intel customers are advised to obtain the latest version of device specifications before relying on any published informationand before placing orders for products or services.*Other names and brands may be claimed as the property of others.
ISO9001:2008登録済
www.altera.com101 Innovation Drive, San Jose, CA 95134
図 4-1: Cyclone V SoCのブロック図
FPGA Fabric
HPS
HPS-to-FPGALightweight
HPS-to-FPGAFPGA-to-HPS FPGA-to-HPS SDRAMConfiguration
Controller
FPGAManager
64 KBOn-Chip
RAM
64 KBBootROM
Level 3Interconnect
EthernetMAC (2x)
USBOTG (2x)
NAND Flash Controller
SD/MMC/SDIO Controller
DMAController
ETR(Trace)
DebugAccess Port
ARM Cortex-A9 MPCore
CPU0(ARM Cortex-A9with NEON/FPU,
32 KB Instruction Cache,32 KB Data Cache, and
Memory Management Unit)
CPU1(ARM Cortex-A9with NEON/FPU,
32 KB Instruction Cache,32 KB Data Cache, and
Memory Management Unit)
SCUACP
L2 Cache (512 KB)
MultiportDDR SDRAM
Controllerwith
Optional ECC
Low Speed Peripherals(Timers, GPIOs, UART, SPI, I2C, CAN, Quad SPI Flash Controller, System Manager, Clock Manager, Reset Manager, and Scan Manager)
マイクロ・プロセッサ・ユニット（MPU）サブシステムは、独自の L1命令キャッシュとデータ・キャッシュで ARM® Cortex®-A9プロセッサを 2個統合します。両方のプロセッサは、インストラクションをフェッチする L2キャッシュと L3インターコネクトを経由するデータ、または直接 DDR SDRAMコントローラに接続します。MPUサブシステムは、プロセッサが最新のデータを使用していることを確認するため、アクセラレータ・コヒーレンシ・ポート（ACP）を介して、システム内の他のマスターからトランザクションをスヌープします。データは、L3インタコネクトに接続されたオンチップ RAMに格納することができます。 L3インタコネクトを使用すれば、柔軟なマルチマスタ（MPU、ダイレクト・メモリ・アクセス・コントローラ（DMAC）、または EMACなど）によるスレーブ・モジュールへのアクセス（UART、タイマ、または I2Cなど）が可能となります。別々のスレーブ・モジュールにアクセスする場合、転送は同時に実行が可能です。FPGA-HPS間（F2H）ブリッジ、HPS-FPGA間（H2F）ブリッジ、ライトウェイトHPS-PGA（LH2F）ブリッジ間でデータを交換することができます。
4-2 Cyclone Vの概要MNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
Cyclone V SoCがターゲットとするアプリケーションAltera Cyclone V SoCデバイスは産業およびオートモーティブ分野において機能安全を重視するアプリケーションでの使用を含む多様なアプリケーション要件を満たします。これには以下が含まれます。• 先進運転支援システム• ハイブリッド車や電気自動車向けモータ制御および DC-DCコンバー タ• インフォテインメント ･ システムアルテラは、Cyclone V SoCの開発にあたって SEooC（Safety Element out of Context）方法論を採用しています。FPGAは、標準的なコンポーネント（例：マイクロ・コントローラ）の使用と比較してユーザに一定の責任をシフトするユーザ定義のロジック IPとアプリケーションの統合に高度な柔軟性を提供します。コンポーネント・レベルのみでは ISO26262:2011-2012の機能安全の達成は不可能です。むしろ、アイテムの全体的な安全コンセプトとして機能します。アルテラの Cyclone V SoC製品は、アイテムに対しターゲットとする ASILレベルの達成の簡易化を可能にします。
Cyclone V SoCハードウェアのアーキテクチャCyclone V SoCデバイスのアーキテクチャは、必要に応じてアプリケーション実行中に使用可能なクロック、電源、メモリなどを継続して動作させる診断手法を含みます。アプリケーションは、アプリケーションを実行する安全性が重要な部分にこれらの機構を使用する前に、これらの機構が正しく動作することを確認しておく必要があります。
図 4-2: Cyclone V SoCの上位レベルのブロック図
この図は、Cyclone V SoCアーキテクチャの上位レベルのブロック図を示し、HPSと FPGA間の専用インタフェースを持つ HPSと FPGAを示しています。
Altera SoC FPGA Device
HPS Portion
FlashControllers
SDRAM ControllerSubsystem
Cortex-A9 MPU Subsystem
On-ChipMemories
SupportPeripherals
PLLs InterfacePeripherals
Debug
HPS-FPGAInterfaces
ControlBlock
UserI/O
HSSITransceivers
FPGA Fabric(LUTs, RAMs, Multipliers & Routing)
PLLs HardPCIe
Hard MemoryControllers
FPGA Portion
MNL-10792015.07.14 Cyclone V SoCがターゲットとするアプリケーション 4-3
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
HPS部と FPGA部は、それぞれ独自の専用コア電源、クロック、I/Oストラクチャを持ち、物理的に 2つに分かれているため、実質的には互いに独立しています。HPSは、対称型マルチ・プロセッシング（SMP）と非対称型マルチプロセッシング（AMP）コンフィギュレーションで動作可能な 2個の Cortex-A9プロセッサを含んでいます。Cortex-A9プロセッサは多くの場合、アプリケーションのメイン・コントローラとして使用されます。FPGAは、その柔軟性により、独自のハードウェア・アクセラレータを実装することができるオプションを提供します。また、システム内またはチップ上の障害を検出するためのカスタム診断機能を作成することも可能です。
図 4-3: Cyclone V SoCの詳細なブロック図
次の図は、Cyclone V SoCのより詳細なブロック図を示します。
DAP
ETR
SD/MMC
EMAC(2)
USBOTG(2)
NANDFlash
CAN(2)
Timer(4)
WatchdogTimer
(2)
UART(2)
GPIO(3)
SPI(4)
ClockManager
ResetManager
I C(4)
ScanManager
SystemManager
L4, 32-Bit Bus
32-Bit
32-Bit
32-Bit
32-Bit
32-Bit
L3 Interconnect(NIC-301)
L3 MasterPeripheral
Switch 32-Bit
32-Bit
64-Bit
64-Bit
32-Bit
32-Bit
64-Bit
32-Bit
32-Bit32-Bit
32-Bit
32-Bit 64-Bit
L3 Slave Peripheral Switch
ACP
CPU0 CPU1
SCU
ARM Cortex-A9MPCore
MPU Subsystem
ACP IDMapper
SDRAMControllerSubsystem
STM
Boot ROM
On-Chip RAM
DMA
QuadSPI
Flash
FPGAManager
FPGA-to-HPSBridge
HPS-to-FPGABridge
LightweightHPS-to-FPGA Bridge
L4, 32-Bit Bus32-Bit AXI
2
32-Bit 64-Bit AXI 64-Bit AXI
L3 MainSwitch
FPGA Portion
ControlBlock
Masters Slaves Slaves
32-, 64-, 128-Bit AXI 32-, 64-, 128-Bit AXI 32-Bit AXI
1 - 6Masters
FPGA to HPS HPS to FPGA Lightweight HPS to FPGA
32-Bit
L2Cache
4-4 Cyclone V SoCハードウェアのアーキテクチャMNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
Cyclone V SoCデバイス上の一部のモジュールは、あらかじめハードウェア診断が組み込まれていますが、。他のモジュールは、偶発ハードウェア障害を検出するにあたって、システム・レベルの概念に依存しています。
Cyclone V SoCの診断メカニズムおよび使用にあたっての前提条件この項では、潜在的な障害を検出する目的でアプリケーション内の IPコアまたは機能に実装された診断メカニズムおよびアプリケーション内の IPコアまたは機能の使用にあたっての前提条件について説明します。この項では、該当する場合は ISO26262:2011-2012をはじめとするドキュメントを参照します。特定の IPコアまたは機能の前提条件の表は、以下の推奨レベルがあります。• Mは必須を表します• ++は強く推奨を表します• +は推奨を表します• Oはオプションを表します各表には、ISO26262:2011-2012による潜在的な診断メカニズムを示しています。
電源
電源レールCyclone V SoCはコア・ロジックおよび I/Oに対し、HPSと FPGAファブリックの異なる電圧レールをサポートします。供給電圧の影響に関係する HPSと FPGAファブリック内の一般的な障害を効率的に軽減することができます。アルテラは、アプリケーションが HPSおよび FPGAファブリックに専用の電源を提供することを想定しています。詳細については、「Cyclone V Device Family Pin Connection Guidelines」の資料番号 PCG-01014を参照してください。
内部電圧モニタ
Cyclone Vデバイスは、いくつかの電源レールに向けて内部電圧モニタを実装します。特定のレールの電圧が仕様以外であれば、デバイスは内部リセットを発行します。アルテラは、モニタされていない電圧レールに向けて異なる電圧モニタがアイテムによって実装されていると想定しています。Cyclone V Device Handbookを参照してください。• Volume 1：デバイスのインタフェースおよび統合• 第 10章：Cyclone Vデバイスの電源管理
MNL-10792015.07.14 Cyclone V SoCの診断メカニズムおよび使用にあたっての前提条件 4-5
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
Cyclone V SoCの電源の使用前提
表 4-1: 電源の使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
PWR1 内部電圧モニタ M 外部電圧モニタ
PWR2 外部電圧スーパーバイザー
++ 内部電圧モニタ
PWR3 HPSと FPGAファブリックへの別々の電源
++ 外部電圧モニタ
クロック
クロック入力Cyclone V SoCは複数のクロック入力をサポートしているため、HPSと FPGAファブリックを別々にクロックすることが可能です。クロック入力を複数にすることで、クロックに関連する一般的な障害を防ぐことができます。HPSは、HPS内で異なるクロック領域を駆動するために 2つのクロック入力を提供します。また、FPGAファブリック内のクロックは複数の入力クロックで駆動が可能であり、FPGAファブリック内のロジックは複数の独立したクロック・ネットワークで駆動することができます。Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 2章：クロック・マネージャCyclone V Device Handbookを参照してください。• Volume 1：デバイスのインタフェースおよび統合• 第 4章：Cyclone Vデバイスのクロック・ネットワークおよび PLL
FPGAのクロッキング
別々の PLLが HPS内の異なるクロック領域を駆動します。異なる入力クロックは、FPGAファブリックからルーティングされたクロックを含む、このような PLLを駆動することができます。 PLLの出力は、異なるクロック領域と FPGAファブリックに接続します。Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 2章：クロック・マネージャ
4-6 Cyclone V SoCの電源の使用前提MNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
Clock Checker Diagnostic IPコア
FPGAファブリック内で Clock Checker Diagnostic IPコアをインスタンス化し、独立リファレンス・クロックを Diagnostic IPコアにフィードすることで PLL出力クロックの正確さを判断することができます。関連情報3-5ページの Clock Checker Diagnostic IPコア
HPS内のウォッチドッグ
HPSでは、クロックの基本的な管理に使用できる数個のウォッチドッグを利用可能です。Cortex-A9 MPUは各 Cortex-A9プロセッサに対し 1個のウォッチドッグを提供しています。HPSは 2個のシステム・ウォッチドッグを提供しています。詳細は、「Cortex-A9 MPCore TechnicalReference Manual ARM DDI 0407」と Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 24章：ウォッチドッグ・タイマ
FPGAファブリック内のウォッチドッグ
HPSクロックから独立したクロックがドライブする FPGAファブリックに向けてウォッチドッグを作成することができます。アルテラでは、ウォッチドッグの実装に関する推奨事項は特にはありません。ISO26262-5:2011 Annex D Table D.10は、ウォッチドッグの実装に関するいくつかの推奨事項を提示しています。HPSから十分に独立していることを示すことができるのであれば、FPGAファブリック内にウォッチドッグを実装します。
表 4-2: ISO26262リファレンス：Watchdog with separate time base without time-window
ソース 参照先
ISO26262-5:2011 Annex D Table D.10 Watchdog with separate time base without time-window
ISO26262-5:2011 Annex D Section D.2.9.1
表 4-3: ISO26262リファレンス：Watchdog with separate time base and time-window
ソース 参照先
ISO26262-5:2011 Annex D Table D.10 Watchdog with separate time base and time-window
ISO26262-5:2011 Annex D Section D.2.9.2
MNL-10792015.07.14 Clock Checker Diagnostic IPコア 4-7
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
表 4-4: ISO26262リファレンス：Temporal and Logical Monitoring of Program Sequence
ソース 参照先
ISO26262-5:2011 Annex D Table D.10 Combination of temporal and logical monitoring ofprogram sequences
ISO26262-5:2011 Annex D Section D.2.9.4
外部のウォッチドッグ
外部ウォッチドッグを実装すると、独立したクロッキング、電源およびリセットが一般的な障害の影響を受けにくくなるという利点をもたらします。アルテラでは、ウォッチドッグの実装に関する推奨事項は特にはありません。ISO26262-5:2011 Annex D Table D.10は、ウォッチドッグの実装に関するいくつかの推奨事項を提示しています。HPSから十分に独立していて FPGAファブリック内にウォッチドッグが実装できない場合、外部ウォッチドッグを実装します。
表 4-5: ISO26262リファレンス：Watchdog with separate time base without time-window
ソース 参照先
ISO26262-5:2011 Annex D Table D.10 Watchdog with separate time base without time-window
ISO26262-5:2011 Annex D Section D.2.9.1
表 4-6: ISO26262リファレンス：Watchdog with separate time base and time-window
ソース 参照先
ISO26262-5:2011 Annex D Table D.10 Watchdog with separate time base and time-window
ISO26262-5:2011 Annex D Section D.2.9.2
表 4-7: ISO26262リファレンス：Temporal and Logical Monitoring of Program Sequence
ソース 参照先
ISO26262-5:2011 Annex D Table D.10 Combination of temporal and logical monitoring ofprogram sequences
ISO26262-5:2011 Annex D Section D.2.9.4
4-8 外部のウォッチドッグMNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
FPGAのクロッキングFPGAファブリックは、異なる PLLを持つクロックを個別に生成可能な非常に柔軟なクロック・ネットワーク・トポロジを提供します。異なるクロック・ネットワークによって駆動されるロジックを分離することが可能です。詳細は、Cyclone V Device Handbookを参照してください。• Volume 1：デバイスのインタフェースおよび統合• 第 4章：Cyclone Vデバイスのクロック・ネットワークおよび PLL
Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 2章：クロック・マネージャ
PLL数PLLは、デバイス・クロックの理、外部システム・クロックの管理、および高速 I/Oインタフェースに向けて堅牢なクロック管理および合成機能を提供します。 Cyclone Vデバイス・ファミリは、フラクショナル PLLあるいは整数 PLLとしても機能できるフラクショナル PLLが含まれています。Cyclone Vデバイスの出力カウンタは、整数またはフラクショナル周波数合成をサポートする各フラクショナル PLLに使用されます。
クロック・スイッチオーバー機能Cyclone Vのクロック・スイッチオーバー機能により、PLLは 2つの基準入力クロックを切り換えることができます。この機能はクロック冗長性のために、あるいは前のクロックが停止した場合に冗長クロックがオンになるシステムであるデュアル・クロック・ドメイン・アプリケーションに使用します。クロックがそれ以上トグルしないとき、またはユーザーのコントロール信号に応じて、デザインは自動的にクロック・スイッチオーバーを実行することができます。
PLLクロックの出力Cyclone Vのほとんどの PLLは、PLLごとに専用クロック出力もドライブすることができます。外部チェック・ロジックはこれを使用して PLLに関連するクロックの問題を検知することが可能です。
FPGA PLLロック信号Cyclone V FPGAファブリック内の PLLは、PLLが入力クロックにロックされていることを示すロック信号も提供します。 入力クロックに対して正しい周波数で PLLが実行されていることを確認するには、この信号を使用します。詳細は、Cyclone V Device Handbookを参照してください。• Volume 1：デバイスのインタフェースおよび統合• 第 4章：Cyclone Vデバイスのクロック・ネットワークおよび PLL
コンフィギュレーション・レジスタの定期的なリード・バック
コンフィギュレーション・レジスタが正確であることを確認するには、レジスタの内容をリード・バックし、その内容と意図した値と比較します。その値をレジスタに書き込み、このリード・バックを定期的に繰り返し実行します。
MNL-10792015.07.14 FPGAのクロッキング 4-9
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
注意: 一部のレジスタは、レジスタをリードする際に自動でクリアするビットを実装することができます。アプリケーションのビヘイビアが変更されることがあるので、リードが一部のビットのステータスに影響を与えることがないようにします。
表 4-8: ISO26262リファレンス：Configuration Register Test
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
Clock Checker Diagnostic IPコア
この IPコアを使用すると、安定したリファレンス・クロックに対し入力クロックの周波数と存在のオンライン・チェッキングを提供することで、デザインの診断カバレッジを拡大することができます。また、FPGAデバイス内の PLLの正しい機能を確認したり、安全性に関連するデザイン内の他のシステム・クロックを確認するには、この IPコアを使用することができます。高周波数と低周波のしきい値は指定可能です。テストするクロックが指定したしきい値を超える場合は、IPコアはシステムにエラー信号を生成し、警告します。
表 4-9: ISO26262リファレンス：Comparator
ソース 参照先
ISO26262-5:2011 Annex D Table D.2 Comparator
ISO26262-5:2011 Annex D Section D.2.1.2
Cyclone V SoCのクロックの使用前提
表 4-10: Cyclone V SoCのクロックの使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
CLK1 HPSと FPGAファブリックに向けた個別の外部クロック入力の使用
+ 1. HPSクロック・グループを FPGAファブリックにルーティングするClock CheckerDiagnostic IPコア
2. ウォッチドッグ3. 外部ピンのクロックド・メイン出力
4-10 Clock Checker Diagnostic IPコアMNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
CLK2 FPGAファブリック内でインスタンス化されるClock Checker DiagnosticIPコアを使用した HPSクロック領域の管理
++ 1. ウォッチドッグ2. 外部ピンのクロックド・メイン出力
CLK3 を使用した HPSクロック領域の管理
O 1. FPGAファブリック内のウォッチドッグ
2. 外部のウォッチドッグ
3. SWテスト・コンフィギュレーション・レジスタと意図する機能
CLK4 HPSシステム・ウォッチドッグ
O 1. FPGAファブリック内のウォッチドッグ
2. 外部のウォッチドッグ
3. SWテスト・コンフィギュレーション・レジスタと意図する機能
CLK5 FPGAファブリック内のウォッチドッグ
++ 1. 外部のウォッチドッグ
2. SWテスト・コンフィギュレーション・レジスタと意図する機能
CLK6 外部のウォッチドッグ ++ 1. 内部のウォッチドッグ
2. SWテスト・コンフィギュレーション・レジスタと意図する機能
CLK7 FPGAファブリックのPLLが欠如したクロック検出とセカンダリ・クロックへの自動切り替え
++ 1. Clock CheckerDiagnostic IPコア
2. クロック出力3. SWテストのコンフィギュレーション・レジスタ
MNL-10792015.07.14 Cyclone V SoCのクロックの使用前提 4-11
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
CLK8 FPGAファブリック PLLクロック出力
O 1. Clock CheckerDiagnostic IPコア
2. PLLが欠如した入力クロックの検出
CLK9 FPGAファブリック PLL固定信号
O 1. Clock CheckerDiagnostic IPコア
2. PLLが欠如した入力クロックの検出
CLK10 コンフィギュレーション・レジスタの定期的なリード・バック
+ 1. Cortex-A9プロセッサを使用したレジスタ内容のリード・バック
関連情報3-5ページの Clock Checker Diagnostic IPコア
リセットCyclone V SoCは、FPGAと HPSの柔軟なリセット処理を提供します。
FPGAのリセット
電源投入時に、FPGAのコンフィギュレーションに必要な電圧モニタする内部リセット電圧スーパーバイザーが、内部パワー・オン・リセット（POR）を生成します。リセットの継続時間は、ユーザにて選択が可能です。nSTATUS信号と CONF_DONE信号がコンフィギュレーションの完了を表します。INIT_DONE信号は適切な初期化を表し、この信号を Highにプルアップした後デザインが実行されます。FPGAファブリックにプログラミングするロジックに適切なリセットを設定する必要があります。詳細は、Cyclone V Device Handbookを参照してください。• Volume 1：デバイスのインタフェースおよび統合• 第 7章：Cyclone Vデバイスのコンフィギュレーション、デザイン・セキュリティ、およびリモート・システム・アップグレード
HPSリセット
HPSには、3つのリセット・ソースがあります。• コールド・リセット（パワー・オン・リセット）• ウォーム・リセット• デバッグ・リセット
4-12 リセットMNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
デバイスの電源投入シーケンス中はコールド・リセットを使用してください。nPOR入力ピンと他の内部リセット要求信号はコールド・リセットを制御します。電源電圧が範囲外である場合は、外部電圧スーパーバイザーを使用して nPORリセット入力を駆動してください。HPSが既にコールド・リセット・シーケンスを完了している場合、無反応の状態からリカバリするにはウォーム・リセットを使用してください。ウォーム・リセットはすべての領域をリセットするわけではありません。nRSTピン、ソフトウェア、ウォッチドッグによってウォーム・リセットを開始してください。nRSTピンは、HPSの状態を把握するために、外部ロジックを使用してモニタが可能な双方向ピンです。アプリケーションのデバッグ中はデバッグ・リセットを使用してください。デバッグ・アクセス・ポート（DAP）または FPGAファブリックからの要求によってデバッグ・リセットを開始してください。リセット・マネージャは HPSシステムへのリセットを制御します。また、リセット・マネージャはウォッチドッグ、スキャン・マネージャ、および FPGAファブリックからの入力といった他のリセット・ソースも処理します。リセット・マネージャはさらに、FPGAロジックへコールド・リセットとウォーム・リセットをエクスポートすることができます。アプリケーション・ソフトウェアは、リセット・マネージャ・ステータス・レジスタで最後にリセットされたソースをリードすることができます。詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 3章：リセット・マネージャ
コンフィギュレーション・レジスタの定期的なリード・バックコンフィギュレーション・レジスタが正確であることを確認するには、レジスタの内容をリード・バックし、その内容と意図した値と比較します。その値をレジスタに書き込み、このリード・バックを定期的に繰り返し実行します。注意: 一部のレジスタは、レジスタをリードする際に自動でクリアするビットを実装することが
できます。アプリケーションのビヘイビアが変更されることがあるので、リードが一部のビットのステータスに影響を与えることがないようにします。
表 4-11: ISO26262リファレンス：Configuration Register Test
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
MNL-10792015.07.14 コンフィギュレーション・レジスタの定期的なリード・バック 4-13
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
ソース 参照先
ISO26262-5:2011 Annex D Section D.2.3.7
HPSリセットの使用前提
表 4-12: リセット：使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
RST1 Power On Reset（POR） M 1. nSTATUS、CONF_
DONE、および INIT_
DONE信号の外部モニタ
RST2 FPGAユーザー・ロジック・リセット
+ 1. リセット信号出力の外部モニタ
RST3 HPSコールド・リセットのモニタ
O 1. FPGAファブリック内の専用スーパーバイザー
RST4 HPSコールド・リセットのモニタ
O 1. 外部のウォッチドッグ
2. FPGAファブリック内の専用スーパーバイザー
RST5 最後のリセットのソフトウェア・チェック
++ 1. リード結果と比較したステータス・レジスタの冗長リード
RST6 コンフィギュレーション・レジスタの定期的なリード・バック
+ 1. Cortex-A9プロセッサを使用したレジスタ内容のリード・バック
入力/出力
FPGAファブリックの I/O
FPGAファブリックの I/Oストラクチャは非常に柔軟であり、多くのアプリケーションの要件を満たすよう設定することができます。Cyclone Vデバイスは各シングルエンド I/Oを双方向ピンとして実装しているため、入力バッファを介して出力として設定されたピンのステータスをリード・バックすることが可能です。
4-14 HPSリセットの使用前提MNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
詳細は、Cyclone V Device Handbookを参照してください。• Volume 1：デバイスのインタフェースおよび統合• 第 5章：Cyclone Vデバイスの I/O機能
HPSの I/O
Cyclone V SoCは、異なるペリフェラル間の HPSシングル・エンド I/Oをマルチプレクサ化します。システム・マネージャおよびスキャン・マネージャは、ピンのマルチプレクサ化とコンフィギュレーションを実行します。詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 5章：システム・マネージャ詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 6章：スキャン・マネージャ
ピン・インタフェースのテストピン・インタフェースをテストするには、最初にピンを GPIOモードに設定し、これらのピンをトグルし、そのピンのステータスをリードバックします。テスト完了後は、ピンの多重化を適切なアプリケーションのコンフィギュレーションに変更可能です。詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 22章：汎用 I/Oインタフェース
コンフィギュレーション・レジスタの定期的なリード・バックコンフィギュレーション・レジスタが正確であることを確認するには、レジスタの内容をリード・バックし、その内容と意図した値と比較します。その値をレジスタに書き込み、このリード・バックを定期的に繰り返し実行します。注意: 一部のレジスタは、レジスタをリードする際に自動でクリアするビットを実装することが
できます。アプリケーションのビヘイビアが変更されることがあるので、リードが一部のビットのステータスに影響を与えることがないようにします。
表 4-13: ISO26262リファレンス：Configuration Register Test
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
MNL-10792015.07.14 HPSの I/O 4-15
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
ソース 参照先
ISO26262-5:2011 Annex D Section D.2.3.7
Cyclone V SoCの I/Oの使用前提
表 4-14: I/O：Cyclone V SoCでの使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
IO1 入力バッファを経由した出力ピン・ステータスの FPGAファブリックI/Oリード・バック
++ 1. 専用の独立したチェック・ロジック
IO2 ピン接続をテストするために HPS I/Oを GPIOとして設定
++ 1. リード結果と比較した入力ステータスの冗長リード
IO3 コンフィギュレーション・レジスタの定期的なリード・バック
+ 1. Cortex-A9を使用したレジスタ内容のリード・バック
Cyclone V SoCにおける FPGAのコンフィギュレーション電源投入時に、FPGAはコンフィギュレーション内容をロードし、アプリケーション回路を作成します。ブート HPSおよび FPGAがそれぞれ独立して、HPSから FPGAあるいは FPGAからHPSの順でブートするようブート機構を実装することが可能です。コンフィギュレーション・シーケンス中は、ステータス信号（nSTATUS、nCONFIG、CONF_DONE、INIT_DONE）を使用することで、HPSあるいは外部モニタによる進捗のモニタが可能です。詳細は、Cyclone V Device Handbookを参照してください。• Volume 1：デバイスのインタフェースおよび統合• 第 7章：Cyclone Vデバイスのコンフィギュレーション、デザイン・セキュリティ、およびリモート・システム・アップグレード
CRCバックグラウンド・チェック
FPGAファブリックのコンフィギュレーション内容は CRAM（Configuration RAM）に格納されます。CRAMに格納されたコンフィギュレーション・フレーム別に CRCを計算する連続バックグラウンド・チェックをイネーブルすることができます。CRCは、シングルとマルチビット障害を検出し、CRC_ERRORピンを介して検出された問題を表示することができます。このバックグラウンド・チェックが実装した回路の通常の機能に影響を与えることはありません。CRC回路が検出した障害に間違いがないことを検証するには、CRC計算に障害を注入し CRAMの変化をエミュレートします。
4-16 Cyclone V SoCの I/Oの使用前提MNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
センシティビティ・マップデザインは SRAMセルをすべて使用するわけではありません。使用しているセルに障害が発生する場合にのみ、回路のビヘイビアに影響が現れます。Quartus IIソフトウェアは、検出された障害が「care」ビットあるいは「don’t care」 ビットで発生したものであるかの判断に使用できるセンシティビティ・マップを生成します。
図 4-4: センシティビティ・マップ
CRCEngine
SensitivityProcessor
(Soft Logic)
MemoryAccess Logic
ExternalSerial/Parallel
Flash
CRC Error
CRITICAL_ERRORLocationInformation
FPGA
この深刻なエラー検出ソリューションの手順は、以下のとおりです。1. 内蔵のソフト・エラー検出回路がコンフィギュレーション・ソフト・エラーを検出・特定し、
CRC_ERRORピンをアサートします。2. 次に、ソフト・ロジックがエラー情報を受け取り、その情報を使用して、コンフィギュレーション・ビットのどれが「care」で、どれが「don’t care」であるかを示すマップを含むファイル内のアドレスを算出します。
3. 次に、ソフト・ロジックは、アクティブ・シリアル・コンフィギュレーション・ポートなどのユーザー指定メモリ・インタフェースを使用して、センシティビティ・マップ・ファイル内の該当ビットにアクセスし、FPGAに現在コンフィギュレーションされているデザインにとって、そのコンフィギュレーション・ソフト・エラーが重大かどうかを判定します。
4. コンフィギュレーション・ソフト・エラーが「don’t care」である場合、FPGAは動作エラー無しで機能し続けることができます。コンフィギュレーション・ソフト・エラーが「care」で、動作に影響を与える可能性がある場合は、Cyclone V FPGAまたは FPGAが CRITICAL_ERRORピンをアサートするため、システム上の適切な動作を実行することができます。
詳細は、Cyclone V Device Handbookを参照してください。• Volume 1：デバイスのインタフェースおよび統合• 第 8章：Cyclone Vデバイスでの SEUの緩和
MNL-10792015.07.14 センシティビティ・マップ 4-17
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
冗長ロジックの実装FPGAファブリックのコンフィギュレーションにて障害を検出しやすくするには、デザインに冗長ロジックを含めた後、冗長ロジックの出力を比較します。
Cyclone V SoCの FPGAコンフィギュレーションの使用前提
表 4-15: FPGAコンフィギュレーションの使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
FPGA_CONF1 HPSあるいは外部モニタを使用したコンフィギュレーション・ステータス信号のモニタ
+ 1. ウォッチドッグ
FPGA_CONF2 ピン接続をテストするために HPS I/Oを GPIOとして設定
++ 1. リード結果と比較した入力ステータスの冗長リード
FPGA_CONF3 CRAMコンフィギュレーションの継続的なCRCバックグラウンド・チェック
++ 1. バックグラウンド・チェックでの定期的な障害の注入
FPGA_CONF4 センシティビティ・マップの決定
O 1. 冗長の実行
FPGA_CONF5 冗長ロジック + 1. テスト・パターン
FPGAユーザ・メモリCyclone Vデバイスの FPGAファブリックは、M10KブロックまたはMLAB内でユーザ・メモリを提供します。これらのブロックにはそれぞれ、エラー検出コードおよびエラー訂正コード（ECC）に対し特別なユーザ機能が使用できる専用パリティ・ビットを実装しています。この機能は、Quartus IIソフトウェアのソフト IPによってサポートされています。詳細は、Cyclone V Device Handbookを参照してください。• Volume 1：デバイスのインタフェースおよび統合• 第 2章：Cyclone Vデバイスのエンベデッド・メモリ・ブロック
4-18 冗長ロジックの実装MNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
FPGAメモリの使用前提
表 4-16: FPGAメモリ：使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
FPGA_UM1 ユーザー・メモリ向けECC
++ 1. フォールト・インジェクション・テスト
HPSインタコネクトHPSは１個の L3インタコネクトと数個の L4インタコネクトを実装しています。L4セグメントは様々なペリフェラルに接続しているため、同時に複数のトランザクションが実行可能です。
トランスミッション冗長
後続するデータを比較するために同じ情報を複数回リードする、あるいは書き込み動作中にデータが変更されていないことを確認するためにライト・データをリードバックすることができます。
表 4-17: ISO26262リファレンス：Transmission Redundancy
ソース 参照先
ISO26262-5:2011 Annex D Table D.8 Transmission redundancy
ISO26262-5:2011 Annex D Section D.2.7.5
情報冗長
大量のデータの CRCあるいはチェックサムを計算することができますが、使用する前にあらかじめ設定されたチェックサムを使用してチェックする必要があります。
表 4-18: ISO26262リファレンス：Information Redundancy
ソース 参照先
ISO26262-5:2011 Annex D Table D.8 Information redundancy
ISO26262-5:2011 Annex D Section D.2.7.6
ウォッチドッグの使用タイムアウトやコードの暴走につながる障害が発生したトランザクションを検出するには、内部または外部のウォッチドッグを使用してください。
MNL-10792015.07.14 FPGAメモリの使用前提 4-19
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
表 4-19: ISO26262リファレンス：Program Sequence Monitoring and Clock
ソース 参照先
ISO26262-5:2011 Annex D Table D.10 クロックをモニタするシーケンスのプログラム
ソフトウェアのセルフテスト
インタコネクトの機能性を確認するには、トランザクション・テストをもとに基本的なソフトウェアを実行します。このテストは、アプリケーションの起動時あるいはアプリケーションの実行時に行います。
表 4-20: ISO26262リファレンス：Test Pattern
ソース 参照先
ISO26262-5:2011 Annex D Table D.14 テスト・パターン
ISO26262-5:2011 Annex D Section D.2.6.1
コンフィギュレーション・レジスタの定期的なリード・バックコンフィギュレーション・レジスタが正確であることを確認するには、レジスタの内容をリード・バックし、その内容と意図した値と比較します。その値をレジスタに書き込み、このリード・バックを定期的に繰り返し実行します。注意: 一部のレジスタは、レジスタをリードする際に自動でクリアするビットを実装することが
できます。アプリケーションのビヘイビアが変更されることがあるので、リードが一部のビットのステータスに影響を与えることがないようにします。
表 4-21: ISO26262リファレンス：Configuration Register Test
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
4-20 ソフトウェアのセルフテストMNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
ソース 参照先
ISO26262-5:2011 Annex D Section D.2.3.7
インタコネクトの使用前提
表 4-22: インタコネクトの使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
HPS_BUS1 HPSの内部のウォッチドッグ
O 1. 外部のウォッチドッグ
2. エラー・レスポンスを使用したウォッチドッグのソフトウェア・テスト
HPS_BUS2 HPSの内部のウォッチドッグ
+ 1. 外部のウォッチドッグ
2. エラー・レスポンスを使用したウォッチドッグのソフトウェア・テスト
HPS_BUS3 外部のウォッチドッグ ++ 1. 内部のウォッチドッグ
2. エラー・レスポンスを使用したウォッチドッグのソフトウェア・テスト
HPS_BUS4 外部のウォッチドッグ ++ 1. CRCエンジンのテスト
HPS_BUS5 トランスミッション冗長
++ 1. 相互にクロスチェックするために、両方の Cortex-A9プロセッサを使用
HPS_BUS6 SWセルフテスト ++ 1. 2つめの Cortex-A9プロセッサによる監視
HPS_BUS7 コンフィギュレーション・レジスタの定期的なリード・バック
+ 1. Cortex-A9プロセッサを使用したレジスタ内容のリード・バック
MNL-10792015.07.14 インタコネクトの使用前提 4-21
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
HPS-FPGA間のインタコネクトHPSと FPGAファブリックを接続している AXIは 3つあり、そのうち 2つは相互に通信が可能です。また、他の信号もそれぞれの IP（FPGAから HPSへの割り込みや HPSから FPGAへの割り込みなど）に直接接続されています。詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 8章：HPS-FPGA間のブリッジ
トランスミッション冗長
後続するデータを比較するために同じ情報を複数回リードする、あるいは書き込み動作中にデータが変更されていないことを確認するためにライト・データをリードバックすることができます。
表 4-23: ISO26262リファレンス：Transmission Redundancy
ソース 参照先
ISO26262-5:2011 Annex D Table D.8 Transmission redundancy
ISO26262-5:2011 Annex D Section D.2.7.5
情報冗長
大量のデータの CRCあるいはチェックサムを計算することができますが、Cyclone V SoCはそれらを使用する前に確認ｎする必要があります。表 25：ISO26262リファレンス：Information Redundancy
表 4-24: ソース 参照先
ソース 参照先
ISO26262-5:2011 Annex D Table D.8 Information redundancy
ISO26262-5:2011 Annex D Section D.2.7.6
ウォッチドッグの使用タイムアウトやコードの暴走につながる障害が発生したトランザクションを検出するには、内部または外部のウォッチドッグを使用してください。
4-22 HPS-FPGA間のインタコネクトMNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
表 4-25: ISO26262リファレンス：Program Sequence Monitoring and Clock
ソース 参照先
ISO26262-5:2011 Annex D Table D.10 クロックをモニタするシーケンスのプログラム
ソフトウェアのセルフテスト
バスあるいは信号接続の機能性を確認するには、トランザクション・テストをもとに基本的なソフトウェアを実行します。このテストは、アプリケーションの起動時あるいはアプリケーションの実行時に行います。
表 4-26: ISO26262リファレンス：Test Pattern
ソース 参照先
ISO26262-5:2011 Annex D Table D.14 テスト・パターン
ISO26262-5:2011 Annex D Section D.2.6.1
コンフィギュレーション・レジスタの定期的なリード・バックコンフィギュレーション・レジスタが正確であることを確認するには、レジスタの内容をリード・バックし、その内容と意図した値と比較します。その値をレジスタに書き込み、このリード・バックを定期的に繰り返し実行します。注意: 一部のレジスタは、レジスタをリードする際に自動でクリアするビットを実装することが
できます。アプリケーションのビヘイビアが変更されることがあるので、リードが一部のビットのステータスに影響を与えることがないようにします。
表 4-27: ISO26262リファレンス：Configuration Register Test
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
MNL-10792015.07.14 ソフトウェアのセルフテスト 4-23
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
ソース 参照先
ISO26262-5:2011 Annex D Section D.2.3.7
インタコネクトの使用前提
表 4-28: インタコネクトの使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
HPS_FPGA_BUS1 HPSの内部のウォッチドッグ
O 1. 外部のウォッチドッグ
2. エラー・レスポンスを使用したウォッチドッグのソフトウェア・テスト
HPS_ FPGA_BUS2 FPGAファブリックの内部のウォッチドッグ
+ 1. 外部のウォッチドッグ
2. エラー・レスポンスを使用したウォッチドッグのソフトウェア・テスト
HPS_ FPGA_BUS3 外部のウォッチドッグ ++ 1. 内部のウォッチドッグ
2. エラー・レスポンスを使用したウォッチドッグのソフトウェア・テスト
HPS_ FPGA_BUS4 情報冗長 ++ 1. CRCエンジンのテスト
HPS_ FPGA_BUS5 トランスミッション冗長
++ 1. 相互にクロスチェックするために、両方の Cortex-A9プロセッサを使用
HPS_ FPGA_BUS6 SWのセルフセット ++ 1. 2つめの Cortex-A9プロセッサによる監視
HPS_ FPGA_BUS7 コンフィギュレーション・レジスタの定期的なリード・バック
+ 1. Cortex-A9プロセッサを使用したレジスタ内容のリード・バック
4-24 インタコネクトの使用前提MNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
HPS Cortex-A9 MPUのサブシステムCyclone V SoCは汎用的な処理に対して Cortex-A9 MPUサブシステムを統合します。デバイスのコンフィギュレーションによって、単一の Cortex-A9プロセッサあるいはデュアル Cortex-A9プロセッサがが実装されています。MPUサブシステム内のプロセッサは、単一のインスタンスです。したがって、Cyclone V SoCがエラーをチェックする目的では冗長なロジックを実装していません。Cyclone V SoCがソフトウェアで診断メカニズムを実装するかどうかはユーザーに任せられます。詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 9章：Cortex-A9マイクロプロセッサ・ユニット・サブシステムアボート処理の詳細については、ARM Cortex-A9 and ARM v7A Architecture Reference Manualsを参照してください。
メモリ・アクセス
Cortex-A9プロセッサはメモリの特定のセクションへの不正アクセスを検出するメカニズムを提供しており、このメカニズムはMMUで定義することが可能です。この場合、Cyclone V SoCはデータ・アボートを生成します。また、Cyclone V SoCは内部バス上の AXIトランザクション・エラーを検出するために、限定的なハードウェア機能をいくつか実装しています。Cyclone VSoCは、プロセッサへアボートとしてトランザクション・エラーを示します。
表 4-29: ISO26262リファレンス：Integrated Hardware Consistency Monitoring
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Integrated Hardware consistency monitoring
ISO26262-5:2011 Annex D Section D.2.3.9
プロセッサの恒久的な障害のテストシリコン内の恒久的な障害をテストするには、ソフトウェアでテスト・パターンを実行してテストを実装します。このテストはアプリケーション起動時およびアプリケーションを実行中に実行します。
表 4-30: ISO26262リファレンス：Self-test by Software
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Self-test by software
ISO26262-5:2011 Annex D Section D.2.3.1
MNL-10792015.07.14 HPS Cortex-A9 MPUのサブシステム 4-25
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
両方の Cortex-A9プロセッサでテストパターンを実行し、両方のプロセッサで結果を比較します。同じパワー・レールがプロセッサを供給し、また同じクロック信号がそれらをクロッキングするため、同一のクロック信号がそれらをクロックするので、共通の原因による故障を考慮するために、わずかにずらしてテストを実行します。
表 4-31: ISO26262リファレンス：Self-test by Software Cross Exchanged Between Two Independent Units
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Self-test by software cross exchanged between twoindependent units
ISO26262-5:2011 Annex D Section D.2.3.3
プロセッサの過渡故障のテスト
過渡故障をテストするには、以下を実行します。1. 単一の Cortex-A9プロセッサあるいは 2つのプロセッサの間で実行可能な多様なソフトウェアを重複して実装します。
2. システム動作を実行する前に、多様なソフトウェアを実行した結果を確認します。
表 4-32: ISO26262リファレンス：Software Diversified Redundancy
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Software diversified redundancy
ISO26262-5:2011 Annex D Section D.2.3.4
あるいは、両方の Cortex-A9でソフトウェア・アルゴリズムの最終結果、中間結果、テスト・データをソフトウェアを実行し比較します。
表 4-33: ISO26262リファレンス：Reciprocal Comparison by Software in Separate Processing Units
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Reciprocal comparison by software in separateprocessing units
ISO26262-5:2011 Annex D Section D.2.3.5
プロセッサ割り込みの処理割り込みの処理にあたって特別な方法を構築します。場合によっては、割り込みを回避し、通常一度だけ実行されるソフトウェアに対してポーリング・モードを実装することが可能です。
4-26 プロセッサの過渡故障のテストMNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
両方の Cortex-A9プロセッサ上で同じプログラムが実行される場合、メモリ内の異なる箇所にプログラムのコピーを 2つ保存します。 1つのコピーから Cortex-A9プロセッサを実行させ、もう1つの別のコピーからもう一方の Cortex-A9プロセッサを実行させます。こうすることで、メモリに関連する潜在的な問題、および Cyclone V SoCがキャッシュにデータを 2度保存するためにメモリから L2キャッシュへのデータ転送が生じるという潜在的な障害に対処することができます。
表 4-34: ISO26262リファレンス：Software Architectural Design
ソース 参照先
ISO26262-6:2011 Software architectural design
ISO26262-6:2011 Table 3 Restricted use of interrupts
ウォッチドッグの使用タイムアウトやコードの暴走につながる障害が発生したトランザクションを検出するには、内部または外部のウォッチドッグを使用してください。
表 4-35: ISO26262リファレンス：Program Sequence Monitoring and Clock
ソース 参照先
ISO26262-5:2011 Annex D Table D.10 クロックをモニタするシーケンスのプログラム
L1キャッシュ
各 Cortex-A9プロセッサには、パリティ保護を備えた専用の L1命令とデータ・キャッシュが含まれています。この保護はキャッシュ TAGメモリもカバーしています。パリティ検出ロジックは、エラーを検出すると CPUへ不正確なアボートを開始します。詳細については、ARM Cortex-A9の資料を参照してください。
表 4-36: ISO26262リファレンス：Parity Bit
ソース 参照先
ISO26262-5:2011 Annex D Table D.6 Parity bit
ISO26262-5:2011 Annex D Section D.2.5.2
MNL-10792015.07.14 ウォッチドッグの使用 4-27
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
BTAC/GHB
パリティは、各 Cortex-A9プロセッサ内に位置する分岐予測ユニットのグローバル履歴バッファとブランチ・ターゲットのアクセス・キャッシュを保護します。パリティ・エラーが検出されると、プロセッサはパイプラインからそのエラーを削除した後に無効なデータを再フェッチし、パリティ・エラー割り込みを生成します。
表 4-37: ISO26262リファレンス：Parity Bit
ソース 参照先
ISO26262-5:2011 Annex D Table D.6 Parity bit
ISO26262-5:2011 Annex D Section D.2.5.2
L2キャッシュ
L2キャッシュは、両方の Cortex-A9プロセッサが同時に使用できる統一キャッシュです。 ECCは L2キャッシュのデータ・ワードを保護し、パリティは TAG RAMを保護します。
表 4-38: ISO26262リファレンス：Parity Bit
ソース 参照先
ISO26262-5:2011 Annex D Table D.6 Parity bit
ISO26262-5:2011 Annex D Section D.2.5.2
表 4-39: ISO26262リファレンス：Memory Monitoring Using EDC Codes
ソース 参照先
ISO26262-5:2011 Annex D Table D.6 Memory monitoring using error-detection-correction codes（EDC）
ISO26262-5:2011 Annex D Section D.2.4.1
詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 9章：Cortex-A9マイクロプロセッサ・ユニット・サブシステム
汎用割り込みコントローラ
CycloneV SoCはデザイン内で汎用割り込みコントローラを一度インスタンス化し、汎用割り込みコントローラは両方の Cortex-A9プロセッサで機能します。
4-28 BTAC/GHBMNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
テスト・パターンを実行することでアプリケーション起動時に汎用割り込みコントローラの機能性をテストします。
表 4-40: ISO26262リファレンス：Self-test by Software
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Self-test by software
ISO26262-5:2011 Annex D Section D.2.3.1
アプリケーション実行中に、ソフトウェアは定期的な割り込みに向けてタイムアウト監視を実装することができます。
表 4-41: ISO26262リファレンス：Timeout Monitoring
ソース 参照先
ISO26262-5:2011 Annex D Table D.8 Timeout monitoring
ISO26262-5:2011 Annex D Section D.2.7.8
Cyclone V SoCは HPSペリフェラル割り込みを FPGAファブリックにルーティングします。これにより、ファブリック内に専用割り込みウォッチドッグを実装したり、あるいは Nios IIプロセッサが割り込みを処理・監視したりすることが可能となります。
表 4-42: ISO26262リファレンス：Timeout Monitoring
ソース 参照先
ISO26262-5:2011 Annex D Table D.8 Timeout monitoring
ISO26262-5:2011 Annex D Section D.2.7.8
場合によっては、割り込みを回避し、ソフトウェア部分にポーリング・モードを実装することが必要なことがあります。これは通常一度だけ実行します。表 43:
表 4-43: ISO26262リファレンス：Software Architectural Design
ソース 参照先
ISO26262-6:2011 Software architectural design
MNL-10792015.07.14 汎用割り込みコントローラ 4-29
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
ソース 参照先
ISO26262-6:2011 Table 3 Restricted use of interrupts
詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 9章：Cortex-A9マイクロプロセッサ・ユニット・サブシステム
メモリ管理ユニット
Cortex-A9プロセッサ内のメモリ管理ユニット（MMU）は基本的なメモリ保護機能をサポートしています。オペレーティング・システムは、双方からソフトウェア・タスクを分離し、これらのタスクが与える影響を互いに回避するためにモリ保護機能を使用することができます。また、この機能は別々のソフトウェアを 2つの Cortex-A9プロセッサ上で実行する場合にも検討すべきです。MMUの詳細情報は、ARM社ウェブサイトで閲覧可能な Cortex-A9Technical Reference Manual,Revision r3p0のメモリ管理ユニットの章を参照してください。
表 4-44: ISO26262リファレンス：Criteria for Coexistence of Elements
ソース 参照先
ISO26262-9:2011 Section 6 Criteria for coexistence of elements
関連情報infocenter.arm.com
スヌープ制御ユニット
Cortex-A9プロセッサは、2つのプロセッサ間で L2キャッシュとの L1データ・キャッシュ・コヒーレンシを可能にするスヌープ制御ユニット（SCU）を実装しています。Cyclone V SoCは SCUメモリ用にパリティを実装しています。これは、任意のパリティエラーに対して割り込みを生成します。 SCUは、システム内の複数のマスタ間におけるコヒーレンシをソフトウェアが維持したままデフォルト・オフとそのデフォルトオフ状態を維持することができます。
表 4-45: ISO26262リファレンス：Parity Bit
ソース 参照先
ISO26262-5:2011 Annex D Table D.6 Parity bit
ISO26262-5:2011 Annex D Section D.2.5.2
4-30 メモリ管理ユニットMNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
MPCoreタイマ
各 Cortex-A9プロセッサには、オペレーティング・システムのタイムベースに使用できる専用タイマ・モジュールが実装されています。 Cortex-A9プロセッサは、プロセッサのタイマの故障を検出する専用のハードウェア機能は実装していません。アプリケーションは、いずれかのタイマの潜在的な問題を検出するために、それぞれのタイマからのタイマ・イベントのクロスチェックを実行することが可能です。また、妥当性を確認するためにMPUサブシステムないでグローバル・タイマを使用することも可能です。また、HPSシステム内に実装された 2つのタイマを同様のクロスチェックに使用することができます。さらに、プロセッサの割り込みをチェックする目的で FPGAファブリック内に専用タイマ・ブロックを実装することも可能です。その後、一般的な原因による障害を考慮するために、別の電源レールとクロックで FPGAを供給することができます。ウォッチドッグの詳細については、ARM社のウェブサイトで閲覧可能な Cortex-A9 MPCoreテクニカルリファレンス マニュアル リビジョン 3p0のグローバル・タイマ、プライベート・タイマ、ウォッチドッグ・レジスタの章を参照してください。詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 23章：タイマ
関連情報infocenter.arm.com
コンフィギュレーション・レジスタの定期的なリード・バックコンフィギュレーション・レジスタが正確であることを確認するには、レジスタの内容をリード・バックし、その内容と意図した値と比較します。その値をレジスタに書き込み、このリード・バックを定期的に繰り返し実行します。注意: 一部のレジスタは、レジスタをリードする際に自動でクリアするビットを実装することが
できます。アプリケーションのビヘイビアが変更されることがあるので、リードが一部のビットのステータスに影響を与えることがないようにします。
表 4-46: ISO26262リファレンス：Configuration Register Test
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
内部ウォッチドッグと外部ウォッチドッグ
ウォッチドッグは、プログラム・シーケンシングおよびクロック関連の問題を検出することができます。 Cortex-A9プロセッサは、このような問題を検出する際に使用できる専用のウォッチド
MNL-10792015.07.14 MPCoreタイマ 4-31
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
ッグを各プロセッサに実装しています。さらに、HPSは同じタスクに使用できる独立したウォッチドッグを 2個実装しています。これとは別に、FPGAファブリック内にはウォッチドッグを 1個実装します。さらに、1個の外部ウォッチドッグを同じ目的に使用することが可能です。
表 4-47: ISO26262リファレンス：Program Sequence Monitoring Clock
ソース 参照先
ISO26262-5:2011 Annex D Table D.10 Program sequence monitoring clock
ウォッチドッグの詳細については、ARM社のウェブサイトで閲覧可能な Cortex-A9 MPCoreテクニカルリファレンス マニュアル リビジョン 3p0のグローバル・タイマ、プライベート・タイマ、ウォッチドッグ・レジスタの章を参照してください。詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 24章：ウォッチドッグ・タイマ
関連情報• 4-7ページの FPGAファブリック内のウォッチドッグ• infocenter.arm.com
Cortex-A9 MPUの使用前提
表 4-48: Cortex-A9 MPU：使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
CA9_MPU1 ソフトウェアによるプロセッサのセルフテスト
++ 1. ウォッチドッグ
CA9_MPU2 ソフトウェアのクロス・エクスチェンジ
++ 1. ウォッチドッグ
CA9_MPU3 ソフトウェアの様々な冗長
++ 1. ウォッチドッグ
CA9_MPU4 ソフトウェアによる相互比較
++ 1. ウォッチドッグ
CA9_MPU5 プログラムの 2つのコピーの保存と実行
+ 1. メモリの CRCチェック
4-32 Cortex-A9 MPUの使用前提MNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
CA9_MPU6 プログラムの 2つのコピーの保存と実行
+ 1. ウォッチドッグ2. 両方の Cortex-A9プロセッサの冗長実行
CA9_MPU7 レジスタ・テストの設定 + 1. 両方の Cortex-A9プロセッサの冗長実行
CA9_MPU8 L1キャッシュのパリティ
++ 1. 両方の Cortex-A9プロセッサの冗長実行
CA9_MPU9 BTACと GHBのパリティ
++ 1. 両方の Cortex-A9プロセッサの冗長実行
CA9_MPU10 L2キャッシュの ECC/パリティ
++ 1. ウォッチドッグ
CA9_MPU11 L2キャッシュの ECC/パリティ
++ 1. ウォッチドッグ
CA9_MPU12 ソフトウェアを経由した割り込みタイムアウトのモニタ
+ 1. 両方の Cortex-A9プロセッサの冗長実行
CA9_MPU13 FPGAファブリック・ウォッチドッグを経由した割り込みタイムアウトのモニタ
+ 1. タイムアウト監視機能をチェックするテスト・パターン
CA9_MPU14 周期的なコンフィギュレーション・レジスタのテスト
+ 1. 2つ目の Cortex-A9プロセッサのレジスタ設定のリードバックと結果の比較
CA9_MPU15 メモリ管理ユニット（MMU）の使用
++ 1. 機能をチェックするテスト・パターン
2. 他の Cortex-A9からのMMUで 1個のMMUの機能をチェック
MNL-10792015.07.14 Cortex-A9 MPUの使用前提 4-33
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
CA9_MPU16 内部のウォッチドッグ O 1. 外部ウォッチドッグ
2. FPGAファブリック内のウォッチドッグ
CA9_MPU17 外部のウォッチドッグ ++ 1. 内部ウォッチドッグ
2. FPGAファブリック内のウォッチドッグ
CA9_MPU18 外部のウォッチドッグ ++ 1. 内部ウォッチドッグ
2. 外部ウォッチドッグ
CA9_MPU19 OSタイマ・クロスチェックのグローバル・タイマ
+ 1. HPSタイマ2. FPGAタイマ3. ウォッチドッグ
CA9_MPU20 HPSイマ + 1. Globalタイマ2. FPGAタイマ3. ウォッチドッグ
CA9_MPU21 FPGAタイマ ++ 1. Globalタイマ2. ウォッチドッグ
HPSのデバッグとトレースHPSのデバッグ・インフラストラクチャは、FPGAファブリックに実装された HPSモジュール、ARM Cortex-A9 MPUサブシステム、およびユーザ・ロジックに可視性と制御を提供します。デバッグ・システム・デザインには、ARMの CoreSight™コンポーネントが組み込まれています。CoreSightコンポーネントは、システムに通常のデバッグ・アクセスを提供するだけでなく、異なるコンポーネント間のトレース・サポートとクロストリガを提供します。 コンポーネントへのアクセスには JTAGインタフェースしますが、Cyclone V SoCはこれをすべてのデバッグ通信が実行される APBバスへ内部で変換します。また、マスタは JTAGインタフェースも提供するDAPのスレーブ・ポートを経由してデバックおよびトレース・コンポーネントに直接アクセスすることが可能です。
JTAG信号のタイオフアプリケーション実行中にデバッグおよびトレース・ロジックの悪影響を回避するには、以下の信号をタイオフします。
4-34 HPSのデバッグとトレースMNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
• HPS_TRST to GND• HPS_TMS to VCCIO_HPS• HPS_TCK to GND
デバッグおよびトレース・ロジックのリセットリセット・マネージャの miscmodrstレジスタで dbgビットを設定することで、デバッグおよびトレース・ロジックの残りの部分をリセット状態に維持することができます。詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル
コンフィギュレーション・レジスタの定期的なリード・バックコンフィギュレーション・レジスタが正確であることを確認するには、レジスタの内容をリード・バックし、その内容と意図した値と比較します。その値をレジスタに書き込み、このリード・バックを定期的に繰り返し実行します。注意: 一部のレジスタは、レジスタをリードする際に自動でクリアするビットを実装することが
できます。アプリケーションのビヘイビアが変更されることがあるので、リードが一部のビットのステータスに影響を与えることがないようにします。
表 4-49: ISO26262リファレンス：Configuration Register Test
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
デバッグおよびトレースの使用前提
表 4-50: デバッグおよびトレースの使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
DBG1 JTAG信号のタイオフ ++ 1. リセット・マネージャの miscmodrst
レジスタで dbgビットを設定します
DBG2 リセット・マネージャのmiscmodrstレジスタでdbgビットを設定
++ 1. FPGAファブリックを使用しているリセット・マネージャのレジスタをリードします
MNL-10792015.07.14 デバッグおよびトレース・ロジックのリセット 4-35
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
DBG3 定期的なコンフィギュレーション・レジスタのテスト
+ 1. 2つ目の Cortex-A9プロセッサのレジスタ設定のリードバックと結果の比較
HPS SDRAMコントローラHPS SDRAMコントローラ・サブシステムは、ARM Cortex-A9 MPUサブシステム、レベル 3（L3）インタコネクト、および FPGAファブリックに対して外部 SDRAMへの効率的なアクセスを提供します。 SDRAMコントローラは、FPGAファブリックと HPSとの間のインタフェースを提供します。インタフェースは、アドバンスト・マイクロコントローラ・バス・アーキテクチャ（AMBA®）Advanced eXtensible Interface（AXIの™）と Avalon®メモリ・マップド（Avalon-MM）トランザクションを受け入れ、これらのコマンドを SDRAMに向けて正しいコマンドに変換し、SDRAMアクセスの詳細を管理します。
SECDED
HPS SDRAMコントローラは、16ビットと 32ビットのメモリ幅の ECCをサポートしています。Cyclone V SoCは ECCパリティ・ビットの格納には別々のメモリを使用します。 ECCは、シングル・ビット・エラー訂正とダブル・ビット・エラー検出（SECDED）をサポートし、障害を検出した場合は割り込みを生成します。シングルとダブル・ビット・エラー用の別々のエラー・カウンタは、訂正および検出の数をカウントします。エラー・アドレス・レジスタは最新のエラーのアドレスを保持します。アプリケーションを実行する前に、メモリにシングル・ビットおよびダブル・ビットの障害を挿入し、ECCロジックをテストします。ECCビットはメモリ・マップされていないため、直接 HPSを経由してビット障害を挿入することはできません。代わりに、FPGAファブリックを介して、ECCビットを格納する別のメモリのアドレスを指定します。Avalon-MMインタフェースを使用して、通常のデータ・メモリとして ECCメモリを使用します。したがって、32ビットのデータ・コンフィギュレーションでは、Cyclone V SoCは、通常の 40ビット・データ・ワードとして40ビット（32ビット・データと ECCのデータ 8ビット）を扱います。 ECCロジックがオフの間は、SoCのロジックはメモリに 40ビット・データ・ワードを書き込むことができます。SoCが書き込むデータは完全に制御できるため、シングル・ビットまたはダブル・ビットの障害を導入することができます。メモリへの書き込み完了後、SoCが ECCロジックをイネーブルし、HPSまたは FPGAファブリックを介してデータを読み込みます。この手順では、ECCロジックのデコーダをテストします。通常動作は、エンコーダをテストします。デコーダはエンコーダから独立したロジックであるため、エンコーダに障害があればデコーダはその障害を検出します。
4-36 HPS SDRAMコントローラMNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
表 4-51: ISO26262リファレンス：Memory Monitoring Using EDC Codes
ソース 参照先
ISO26262-5:2011 Annex D Table D.6 Memory monitoring using error-detection-correction codes（EDC)
ISO26262-5:2011 Annex D Section D.2.4.1
メモリ保護の使用指定のマスタによるアクセスに対して特定のメモリ領域を分離するには、メモリ保護機能を使用します。別々の領域に対してアクセス許可を定義するには、SDRAMコントローラ内に最大 20の異なるルールを設定することができます。
表 4-52: ISO26262リファレンス：Criteria for Coexistence of Elements
ソース 参照先
ISO26262-9:2011 Section 6 Criteria for coexistence of elements
詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 11章：SDRAMコントローラ・サブシステム
CRCの実行アプリケーション（例：命令メモリ、定数）を実行中に変化しないデータについては、CRCチェックサムを使用してデータの整合性を確認します。、CRCチェックサムは、アプリケーションの起動時またはアプリケーション実行中に定期的に実行します。
表 4-53: ISO26262リファレンス：Running Checksum/CRC
ソース 参照先
ISO26262-5:2011 Annex D Table D.6 Running checksum/CRC
ISO26262-5:2011 Annex D Section D.2.5.4
コンフィギュレーション・レジスタの定期的なリード・バックコンフィギュレーション・レジスタが正確であることを確認するには、レジスタの内容をリード・バックし、その内容と意図した値と比較します。その値をレジスタに書き込み、このリード・バックを定期的に繰り返し実行します。
MNL-10792015.07.14 メモリ保護の使用 4-37
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
注意: 一部のレジスタは、レジスタをリードする際に自動でクリアするビットを実装することができます。アプリケーションのビヘイビアが変更されることがあるので、リードが一部のビットのステータスに影響を与えることがないようにします。
表 4-54: ISO26262リファレンス：Configuration Register Test
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
SDRAMの使用前提
表 4-55: SDRAMの使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
SDRAM1 SECDED（ECC） ++ 1. 検出および訂正機能をテストするためのテスト・パターンを実行する
SDRAM2 メモリ保護機能 ++ 1. 検出および訂正機能をテストするためのテスト・パターンを実行する
SDRAM3 メモリ保護機能 + 1. CRCエンジンに向けたテスト・パターン
SDRAM4 定期的なコンフィギュレーション・レジスタのテスト
+ 1. 2つ目の Cortex-A9プロセッサのレジスタ設定のリードバックと結果の比較
HPSオンチップ RAM
オンチップ RAMは、アプリケーション・データ・ストレージ用の汎用不揮発性メモリとして機能します。
SECDED
オンチップ RAMは、別々のメモリ・セルに ECCビットを格納することで、SECDEDをサポートしています。オンチップ RAMは、データ・バイト別に 5 ECCビットを使用します。これは、
4-38 SDRAMの使用前提MNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
ECCをワードに実装する場合と比較して、リード・モディファイ・ライト動作を排除します。したがって、ECCはアプリケーションのパフォーマンスに影響を与えません。システム・マネージャは、ECC機能を制御します。ECCロジックの機能をテストするためにシングル・ビットとダブル・ビットのエラーを注入することができます。ECCがイネーブルの場合、ECCは別の ECCデコーダをテストするために。メモリ・ワードの各バイトにエラーを注入します。
表 4-56: ISO26262リファレンス：Memory Monitoring Using EDC Codes
ソース 参照先
ISO26262-5:2011 Annex D Table D.6 Memory monitoring using EDC
ISO26262-5:2011 Annex D Section D.2.4.1
詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 5章：システム・マネージャ
CRCの実行アプリケーション（例：命令メモリ、定数）を実行中に変化しないデータについては、CRCチェックサムを使用してデータの整合性を確認します。、CRCチェックサムは、アプリケーションの起動時またはアプリケーション実行中に定期的に実行します。
表 4-57: ISO26262リファレンス：Running Checksum/CRC
ソース 参照先
ISO26262-5:2011 Annex D Table D.6 Running checksum/CRC
ISO26262-5:2011 Annex D Section D.2.5.4
コンフィギュレーション・レジスタの定期的なリード・バックコンフィギュレーション・レジスタが正確であることを確認するには、レジスタの内容をリード・バックし、その内容と意図した値と比較します。その値をレジスタに書き込み、このリード・バックを定期的に繰り返し実行します。注意: 一部のレジスタは、レジスタをリードする際に自動でクリアするビットを実装することが
できます。アプリケーションのビヘイビアが変更されることがあるので、リードが一部のビットのステータスに影響を与えることがないようにします。
MNL-10792015.07.14 CRCの実行 4-39
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
表 4-58: ISO26262リファレンス：Configuration Register Test
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
オンチップ RAMの使用前提
表 4-59: オンチップ RAMの使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
OCRAM1 SECDED（ECC) ++ 1. 検出および訂正機能をテストするためのテスト・パターンを実行する
OCRAM2 非変更データの CRCチェック
+ 1. CRCエンジンに向けたテスト・パターン
OCRAM3 定期的なコンフィギュレーション・レジスタのテスト
+ 1. 2つ目の Cortex-A9プロセッサのレジスタ設定のリードバックと結果の比較
HPSオンチップ・ブート ROM
ブート ROMは、システムのみを起動します。 MPUサブシステムのコールド・リセットあるいはウォーム・リセットの場合、MPU0はブート ROMに格納されているプレブートローダ・コードを実行します。 プレブートローダは、アプリケーションをロードするユーザ提供のブートローダをロードします。アルテラは、ブート・プロセス中にいかなる安全機能も実行されないため、ブート・プロセスは安全性が重視されるプロセスではないと前提しています。
CRCの実行アプリケーション（例：命令メモリ、定数）を実行中に変化しないデータについては、CRCチェックサムを使用してデータの整合性を確認します。、CRCチェックサムは、アプリケーションの起動時またはアプリケーション実行中に定期的に実行します。
4-40 オンチップ RAMの使用前提MNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
表 4-60: ISO26262リファレンス：Running Checksum/CRC
ソース 参照先
ISO26262-5:2011 Annex D Table D.6 Running checksum/CRC
ISO26262-5:2011 Annex D Section D.2.5.4
オンチップ・ブート ROMの使用前提
表 4-61: オンチップ・ブート ROMの使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
BROM1 ブート ROMの CRCチェック
O 1. CRCエンジンに向けたテスト・パターン
HPS NANDフラッシュ・コントローラHPS NANDフラッシュ・コントローラは、外部の NANDフラッシュ・メモリとのインタフェースを提供します。外部フラッシュ・メモリを使用すれば、プロセッサのブート・イメージやソフトウェアを格納したり、大規模なアプリケーションあるいはユーザ・データ用の追加の記憶容量をして使用することができます。 HPS NANDフラッシュ・コントローラは、Cadence Design IPNANDフラッシュ・メモリ・コントローラに基づいています。詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 13章：NANDフラッシュ・コントローラ
SECDED
コントローラは異なるセクタ・サイズへの ECCをサポートし、データをライトする際は ECCチェック・ビットを自動的に挿入し、またデータをリードする際は ECCビットを自動的に取り除きます。 ECCは SECDEDをサポートしており、NANDコントローラの内部メモリも SECDEDをサポートする ECCによって保護されています。
表 4-62: ISO26262リファレンス：Memory Monitoring using EDC Codes
ソース 参照先
ISO26262-5:2011 Annex D Table D.6 Memory monitoring using EDC codes
ISO26262-5:2011 Annex D Section D.2.4.1
MNL-10792015.07.14 オンチップ・ブート ROMの使用前提 4-41
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
障害の注入システム・マネージャは、ECC機能を制御します。ECCロジックの機能をテストするためにシングル・ビットとダブル・ビットのエラーを注入することができます。ECCがイネーブルされると、ECCは別の ECCデコーダをテストするために。メモリ・ワードの各バイトにエラーを注入します。詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 5章：システム・マネージャ
CRCの実行アプリケーション（例：命令メモリ、定数）を実行中に変化しないデータについては、CRCチェックサムを使用してデータの整合性を確認します。、CRCチェックサムは、アプリケーションの起動時またはアプリケーション実行中に定期的に実行します。
表 4-63: ISO26262リファレンス：Running Checksum/CRC
ソース 参照先
ISO26262-5:2011 Annex D Table D.6 Running checksum/CRC
ISO26262-5:2011 Annex D Section D.2.5.4
コンフィギュレーション・レジスタの定期的なリード・バックコンフィギュレーション・レジスタが正確であることを確認するには、レジスタの内容をリード・バックし、その内容と意図した値と比較します。その値をレジスタに書き込み、このリード・バックを定期的に繰り返し実行します。注意: 一部のレジスタは、レジスタをリードする際に自動でクリアするビットを実装することが
できます。アプリケーションのビヘイビアが変更されることがあるので、リードが一部のビットのステータスに影響を与えることがないようにします。
表 4-64: ISO26262リファレンス：Configuration Register Test
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
4-42 障害の注入MNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
ソース 参照先
ISO26262-5:2011 Annex D Section D.2.3.7
NANDコントローラの使用前提
表 4-65: NANDコントローラの使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
NAND1 ECC ++ 1. フォールト・インジェクション・テスト
NAND2 CRCチェックサム ++ 1. CRCエンジンに向けたテスト・パターン
NAND3 定期的なコンフィギュレーション・レジスタのテスト
+ 1. 2つ目の Cortex-A9プロセッサのレジスタ設定のリードバックと結果の比較
HPS SD/MMCコントローラHPS Secure Digital/MultiMediaCard（SD/MMC）コントローラは外部 SDフラッシュ・カード、外部MMCフラッシュ・カード、セキュア・デジタル I/O（SDIO）デバイス、Consumer ElectronicsAdvanced Transport Architecture（CE-ATA）ハード・ドライブとインタフェース接続します。詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 14章：SD/MMCフラッシュ・コントローラ
SECDED
HPS SD/MMCコントローラは、統合されたリードおよびライト FIFOに向けて ECCを実装しています。ECCは SECDEDをサポートしています。
表 4-66: ISO26262リファレンス：Memory Monitoring using EDC Codes
ソース 参照先
ISO26262-5:2011 Annex D Table D.6 Memory monitoring using EDC codes
MNL-10792015.07.14 NANDコントローラの使用前提 4-43
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
ソース 参照先
ISO26262-5:2011 Annex D Section D.2.4.1
障害の注入システム・マネージャは、ECC機能を制御します。ECCロジックの機能をテストするためにシングル・ビットとダブル・ビットのエラーを注入することができます。ECCがイネーブルされると、ECCは別の ECCデコーダをテストするために。メモリ・ワードの各バイトにエラーを注入します。詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 5章：システム・マネージャ
CRCの実行アプリケーション（例：命令メモリ、定数）を実行中に変化しないデータについては、CRCチェックサムを使用してデータの整合性を確認します。、CRCチェックサムは、アプリケーションの起動時またはアプリケーション実行中に定期的に実行します。
表 4-67: ISO26262リファレンス：Running Checksum/CRC
ソース 参照先
ISO26262-5:2011 Annex D Table D.6 Running checksum/CRC
ISO26262-5:2011 Annex D Section D.2.5.4
コンフィギュレーション・レジスタの定期的なリード・バックコンフィギュレーション・レジスタが正確であることを確認するには、レジスタの内容をリード・バックし、その内容と意図した値と比較します。その値をレジスタに書き込み、このリード・バックを定期的に繰り返し実行します。注意: 一部のレジスタは、レジスタをリードする際に自動でクリアするビットを実装することが
できます。アプリケーションのビヘイビアが変更されることがあるので、リードが一部のビットのステータスに影響を与えることがないようにします。
表 4-68: ISO26262リファレンス：Configuration Register Test
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
4-44 障害の注入MNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
ソース 参照先
ISO26262-5:2011 Annex D Section D.2.3.7
SD/MMCコントローラの使用前提
表 4-69: SD/MMCコントローラの使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
SDMMC1 ECC ++ 1. フォールト・インジェクション・テスト
SDMMC2 CRCチェックサム ++ 1. CRCエンジンに向けたテスト・パターン
SDMMC3 周期的なコンフィギュレーション・レジスタのテスト
+ 1. 2つ目の Cortex-A9プロセッサのレジスタ設定のリードバックと結果の比較
HPS Quad SPIフラッシュ・コントローラHPSは、シリアル NORフラッシュ・デバイスへのアクセスに向けて QSPI（quad serial peripheralinterface）フラッシュ・コントローラを提供しています。詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 15章：QSPIフラッシュ・コントローラ
SECDED
QSPIコントローラは、ローカル・メモリ・バッファに向けて ECCを実装しています。ECCはSECDEDをサポートしています。
表 4-70: ISO26262リファレンス：Memory Monitoring Using EDC Codes
ソース 参照先
ISO26262-5:2011 Annex D Table D.6 Memory monitoring using error-detection-correction codes（EDC)
MNL-10792015.07.14 SD/MMCコントローラの使用前提 4-45
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
ソース 参照先
ISO26262-5:2011 Annex D Section D.2.4.1
障害の注入システム・マネージャは、ECC機能を制御します。ECCロジックの機能をテストするためにシングル・ビットとダブル・ビットのエラーを注入することができます。ECCがイネーブルされると、ECCは別の ECCデコーダをテストするために。メモリ・ワードの各バイトにエラーを注入します。詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 5章：システム・マネージャ
CRCの実行アプリケーション（例：命令メモリ、定数）を実行中に変化しないデータについては、CRCチェックサムを使用してデータの整合性を確認します。、CRCチェックサムは、アプリケーションの起動時またはアプリケーション実行中に定期的に実行します。
表 4-71: ISO26262リファレンス：Running Checksum/CRC
ソース 参照先
ISO26262-5:2011 Annex D Table D.6 Running checksum/CRC
ISO26262-5:2011 Annex D Section D.2.5.4
コンフィギュレーション・レジスタの定期的なリード・バックコンフィギュレーション・レジスタが正確であることを確認するには、レジスタの内容をリード・バックし、その内容と意図した値と比較します。その値をレジスタに書き込み、このリード・バックを定期的に繰り返し実行します。注意: 一部のレジスタは、レジスタをリードする際に自動でクリアするビットを実装することが
できます。アプリケーションのビヘイビアが変更されることがあるので、リードが一部のビットのステータスに影響を与えることがないようにします。
表 4-72: ISO26262リファレンス：Configuration Register Test
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
4-46 障害の注入MNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
ソース 参照先
ISO26262-5:2011 Annex D Section D.2.3.7
QSPIフラッシュ・コントローラのの使用前提
表 4-73: QSPIフラッシュ・コントローラのの使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
QSPI1 ECC ++ 1. フォールト・インジェクション・テスト
QSPI2 CRCチェックサム ++ 1. CRCエンジンに向けたテスト・パターン
QSPI3 周期的なコンフィギュレーション・レジスタのテスト
+ 1. 2つ目の Cortex-A9プロセッサのレジスタ設定のリードバックと結果の比較
HPS FPGAマネージャHPS FPGAマネージャは、SoCデバイスの FPGA部分を管理し、監視します。FPGAマネージャは、HPSから FPGAファブリックをコンフィギュレーションし、FPGAの状態を監視し、FPGAファブリックへまたは FPGAファブリックから信号を駆動し、サンプルすることができます。FPGAマネージャがエラーを検出することはできませんが、FPGAマネージャは一部のブロックや技術を使用して FPGAファブリックの動作に影響を与える FPGAマネージャ内の潜在的な障害を診断することができます。
モニタ
FPGAマネージャは、FPGAファブリックのステータスと健全性をモニタする FPGAのステータス信号と主要な設定をサンプルするブロックを実装しています。 FPGAマネージャ内の障害は、FPGAファブリックのステータスに影響を与える可能性があります。モニタしている各信号に対し Cortex-A9 MPUへ割り込みを生成することができます。詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 4章：FPGAマネージャ
MNL-10792015.07.14 QSPIフラッシュ・コントローラのの使用前提 4-47
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
コンフィギュレーション・レジスタの定期的なリード・バックコンフィギュレーション・レジスタが正確であることを確認するには、レジスタの内容をリード・バックし、その内容と意図した値と比較します。その値をレジスタに書き込み、このリード・バックを定期的に繰り返し実行します。注意: 一部のレジスタは、レジスタをリードする際に自動でクリアするビットを実装することが
できます。アプリケーションのビヘイビアが変更されることがあるので、リードが一部のビットのステータスに影響を与えることがないようにします。
表 4-74: ISO26262リファレンス：Configuration Register Test
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
FPGAマネージャの使用前提
表 4-75: FPGAマネージャの使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
FMGR1 ブロックのモニタ + 1. FPGAコンフィギュレーション時の信号の監視
FMGR2 定期的なコンフィギュレーション・レジスタのテスト
+ 1. 2つ目の Cortex-A9プロセッサのレジスタ設定のリードバックと結果の比較
HPSシステム・マネージャHPSシステム・マネージャには、HPSのモジュール以外にもメモリ・マップされたコントロール・レジスタとステータス・レジスタ（CSR）、およびシステム・レベル・ファンクションを制御するロジックが含まれています。また、HPSシステム・マネージャはパリティおよび ECC割り込みを Cortex-A9 MPUにルーティングします。HPSシステム・マネージャは、特定の安全機能を実装していませんが、HPSシステム・マネージャは、ECCの機能性をテストするために、いくつかのモジュールの ECCにエラーを注入することが可能です。HPSシステム・マネージャは、データ・ワードのMSBにシングル・ビット・エラーを注入し、データ・ワードのMSBと LSBにはダブル・ビット・エラーを注入します。詳細は、Cyclone V Device Handbookを参照してください。
4-48 コンフィギュレーション・レジスタの定期的なリード・バックMNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 5章：システム・マネージャ
コンフィギュレーション・レジスタの定期的なリード・バックコンフィギュレーション・レジスタが正確であることを確認するには、レジスタの内容をリード・バックし、その内容と意図した値と比較します。その値をレジスタに書き込み、このリード・バックを定期的に繰り返し実行します。注意: 一部のレジスタは、レジスタをリードする際に自動でクリアするビットを実装することが
できます。アプリケーションのビヘイビアが変更されることがあるので、リードが一部のビットのステータスに影響を与えることがないようにします。
表 4-76: ISO26262リファレンス：Configuration Register Test
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
システム・マネージャの使用前提
表 4-77: システム・マネージャの使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
SYSMGR1 定期的なコンフィギュレーション・レジスタのテスト
+ 1. 2つ目の Cortex-A9プロセッサのレジスタ設定のリードバックと結果の比較
HPSスキャン・マネージャHPSスキャン・マネージャは HPS I/Oピンの設定および管理を行い、JTAG TAP（Test AccessPort）コントローラと通信します。 HPSスキャン・マネージャは、HPSのペリフェラルがピンを使用する前に HPS I/Oスキャン・チェインをドライブして I/Oバンクのプロパティをコンフィギュレーションします。また、HPSスキャン・マネージャは、FPGAの制御ブロックが検出する巡回冗長検査（CRC）エラーの管理といった目的のためにコマンドを送信する目的で、FPGAJTAG TAPコントローラと通信することも可能です。
I/OのコンフィギュレーションI/Oは以下の 2通りの方法でコンフィギュレーション可能です。• ソフトウェア• JTAG
MNL-10792015.07.14 コンフィギュレーション・レジスタの定期的なリード・バック 4-49
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
ソフトウェアを介した I/Oのコンフィギュレーションは複数の手順を伴いますが、このコンフィギュレーション方法はピンのコンフィギュレーションに直接的な影響を持つ単一障害点を防止することが可能です。コンフィギュレーションが変更可能となる前に、必要な手順の一つはスキャン・チェーンを有効にすることです。FPGA JTAG TAPを介した I/Oのコンフィギュレーションにも複数の手順が伴います。1. TAPが CONFIG_IO JTAG命令を受信し、その後 JTAGポートを経由してデータを受信することを確認します。
2. 正しいタイムでに複数の JTAG信号がトグルされるよう、JTAG TAPステート・マシンの異なる段階を経るようにします。ランダム・イベントの正しいシーケンスが状態の変化や意味のあるデータの変更につながる可能性はほとんどありません。
3. JTAGインタフェースを介して I/Oのコンフィギュレーションが変更されるリスクをさらに低減させるために、GNDか VCCIOのどちらかに JTAG信号を接続します。
詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 6章：スキャン・マネージャ
JTAG信号のタイオフアプリケーション実行中にデバッグおよびトレース・ロジックの悪影響を回避するには、以下の信号をタイオフします。• TMS to VCCIO• TCK to GND
コンフィギュレーション・レジスタの定期的なリード・バックコンフィギュレーション・レジスタが正確であることを確認するには、レジスタの内容をリード・バックし、その内容と意図した値と比較します。その値をレジスタに書き込み、このリード・バックを定期的に繰り返し実行します。注意: 一部のレジスタは、レジスタをリードする際に自動でクリアするビットを実装することが
できます。アプリケーションのビヘイビアが変更されることがあるので、リードが一部のビットのステータスに影響を与えることがないようにします。
表 4-78: ISO26262リファレンス：Configuration Register Test
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
4-50 JTAG信号のタイオフMNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
ソース 参照先
ISO26262-5:2011 Annex D Section D.2.3.7
スキャン・マネージャの使用前提
表 4-79: スキャン・マネージャの使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
SCMGR1 タイオフ JTAG信号 ++ 1. リセット・マネージャの miscmodrst
レジスタで dbgビットを設定します
SCMGR2 定期的なコンフィギュレーション・レジスタのテスト
+ 1. 2つ目の Cortex-A9プロセッサのレジスタ設定のリードバックと結果の比較
HPS DMAC
DMACは、メモリやペリフェラルをはじめとするシステム内のメモリ・ロケーション間でデータを転送します。DMACは、ARM®Corelink™DMAC（DMA-330）のインスタンスです。HPSには、メモリ・マップされたペリフェラルとメモリ間におけるデータ転送の処理に向けて 1個の DMACが提供されおり、MPUサブシステムからこの処理による負荷を軽減します。DMACは、メモリ-メモリ間、メモリ-ペリフェラル間、ペリフェラル-メモリ間の転送をサポートしています。詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 16章：DMAコントローラ
SECDED
DMACには、DMA転送中に DMACがリードおよびライトするデータの格納に使用するマルチFIFO（MFIFO）データ・バッファが含まれています。 ECCはこのバッファを保護し、SECDEDをサポートします。 DMACは、両方のエラー・ケースに対し Cortex-A9 MPUへの割り込みを生成し、システム・マネージャはこの割り込みを制御します。DMACにエラーを注入して、検出と訂正の機能を評価することができます。
MNL-10792015.07.14 スキャン・マネージャの使用前提 4-51
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
表 4-80: ISO26262リファレンス：Memory Monitoring Using EDC Codes
ソース 参照先
ISO26262-5:2011 Annex D Table D.6 Memory monitoring using EDC codes.
ISO26262-5:2011 Annex D Section D.2.4.1
詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 5章：システム・マネージャ
アボート処理
DMACはまた、DMACがロックアップされた状態でのウォッチドッグのアボートを含む、異なるソースからのエラーを検出した場合は正確なアボートまたは不正確はアボートを生成します。
表 4-81: ISO26262リファレンス：Integrated Hardware consistency monitoring
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Integrated Hardware consistency monitoring
ISO26262-5:2011 Annex D Section D.2.3.9
詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 16章：DMAコントローラ
コンフィギュレーション・レジスタの定期的なリード・バックコンフィギュレーション・レジスタが正確であることを確認するには、レジスタの内容をリード・バックし、その内容と意図した値と比較します。その値をレジスタに書き込み、このリード・バックを定期的に繰り返し実行します。注意: 一部のレジスタは、レジスタをリードする際に自動でクリアするビットを実装することが
できます。アプリケーションのビヘイビアが変更されることがあるので、リードが一部のビットのステータスに影響を与えることがないようにします。
表 4-82: ISO26262リファレンス：Configuration Register Test
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
4-52 アボート処理MNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
ソース 参照先
ISO26262-5:2011 Annex D Section D.2.3.7
DMAコントローラの使用前提
表 4-83: DMAコントローラの使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
DMA1 SECDED（ECC) ++ 1. 検出および訂正機能をテストするためのテスト・パターンを実行する
DMA2 アボート処理 M 1. Cortex-A9プロセッサによるタイムアウト・モニタリングの監視
DMA3 周期的なコンフィギュレーション・レジスタのテスト
+ 1. 2つ目の Cortex-A9プロセッサのレジスタ設定のリードバックと結果の比較
HPSイーサネット・メディア・アクセス・コントローラHPSは、2個のイーサネット・メディア・アクセス・コントローラ（EMAC）ペリフェラルを提供します。 IEEE 802.3規格に準拠したイーサネット接続を経由して 10/100/1000 Mbpsでデータを送受信するには、各 EMACを使用してください。EMACは Synopsys® DesignWare® 3504-0Universal 10/100/1000 Ethernet MAC（DWC_gmac）のインスタンスです。詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 17章：イーサネット・メディア・アクセス・コントローラ
SECDED
ECCは送信および受信データ FIFOバッファを保護します。 ECCは SECDEDをサポートしています。 ECCは、両方のエラーケースに対し Cortex-A9 MPUへの割り込みを生成し、システム・マネージャはこの割り込みを制御します。EMACにエラーを注入して、検出と訂正の機能を評価することができます。
MNL-10792015.07.14 DMAコントローラの使用前提 4-53
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
表 4-84: ISO26262リファレンス：Memory Monitoring Using EDC Codes
ソース 参照先
ISO26262-5:2011 Annex D Table D.6 Memory monitoring using EDC codes.
ISO26262-5:2011 Annex D Section D.2.4.1
詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 17章：イーサネット・メディア・アクセス・コントローラ詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 5章：システム・マネージャ
I/Oインタフェースのテスト多くのイーサネット PHYは、EMACと PHY間の物理的なピン接続の検証を可能にするループバック・モードをサポートしていますアプリケーション起動時に。このループバック・テストを実行します。
表 4-85: ISO26262リファレンス：Test Pattern
ソース 参照先
ISO26262-5:2011 Annex D Table D.7 Test Pattern
ISO26262-5:2011 Annex D Section D.2.6.1
情報冗長の実装送信データに対しては、冗長化手法を実装する必要があります。具体的には、送信されるデータのブロック上の追加 CRC、送信データのリードバック、Questionあるいは Answerプロトコルなどがあります。適切な方法を使用すると、内部バスを介して、Cyclone V SoCの内部ストレージからのデータ送信のパス全体、内部バス、通信モジュール、外部インタフェースとエンドポイントの診断能力を提供することができます。
表 4-86: ISO26262リファレンス：Information Redundancy
ソース 参照先
ISO26262-5:2011 Annex D Table D.8 Information redundancy
4-54 I/OインタフェースのテストMNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
ソース 参照先
ISO26262-5:2011 Annex D Section D.2.7.6
コンフィギュレーション・レジスタの定期的なリード・バックコンフィギュレーション・レジスタが正確であることを確認するには、レジスタの内容をリード・バックし、その内容と意図した値と比較します。その値をレジスタに書き込み、このリード・バックを定期的に繰り返し実行します。注意: 一部のレジスタは、レジスタをリードする際に自動でクリアするビットを実装することが
できます。アプリケーションのビヘイビアが変更されることがあるので、リードが一部のビットのステータスに影響を与えることがないようにします。
表 4-87: ISO26262リファレンス：Configuration Register Test
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
イーサネット MACの使用前提
表 4-88: イーサネット MACの使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
EMAC1 SECDED（ECC) ++ 1. 検出および訂正機能をテストするためのテスト・パターンを実行する
EMAC2 I/Oインタフェース・テスト
++ 1. 2つ目の Cortex-A9プロセッサのステータスのリードバックと結果の比較
EMAC3 情報冗長 ++ 1. テスト・パターン
EMAC4 定期的なコンフィギュレーション・レジスタのテスト
+ 1. 2つ目の Cortex-A9プロセッサのレジスタ設定のリードバックと結果の比較
MNL-10792015.07.14 コンフィギュレーション・レジスタの定期的なリード・バック 4-55
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
HPS USB 2.0 OTGコントローラHPSは、デバイスとホスト機能の両方をサポートする USB On-The-Go（OTG）コントローラの2つのインスタンスを提供します。詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 18章：USB 2.0 OTGコントローラ
SECDED
USB OTGコントローラに接続されたシングル・ポート RAM（SPRAM）は、ホストとデバイス・モードの両方に対し USBデータ・パケットを格納します。Cyclone V SoCは、USBリンク上の受信および送信データ・パケットに向けた FIFOバッファとして SPRAMをコンフィギュレーションします。 ECCは、この RAMを保護します。 また、ECCは SECDEDをサポートしており、両方のエラーケースに対し Cortex-A9 MPUへの割り込みを生成し、システム・マネージャはこの割り込みを制御します。USBコントローラにエラーを注入して、検出と訂正の機能を評価することができます。
表 4-89: ISO26262リファレンス：Memory Monitoring Using EDC Codes
ソース 参照先
ISO26262-5:2011 Annex D Table D.6 Memory monitoring using EDC codes.
ISO26262-5:2011 Annex D Section D.2.4.1
詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 18章：USB 2.0 OTGコントローラ詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 5章：システム・マネージャ
I/Oインタフェースのテストアプリケーションで USBを使用する前に、I/Oインタフェースのテストを実行します。外部トランシーバがループバック・モードをサポートしているのであれば、送信テストは、Cyclone V SoCとトランシーバ間のインタフェースをテストすることができます。また、定義済のハンドシェイク・プロトコルをエンドポイント間に実装し、アプリケーション起動時に接続をテストすることも可能です。
4-56 HPS USB 2.0 OTGコントローラMNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
表 4-90: ISO26262リファレンス：Test Pattern
ソース 参照先
ISO26262-5:2011 Annex D Table D.7 テスト・パターン
ISO26262-5:2011 Annex D Section D.2.6.1
情報冗長の実装送信データに対しては、冗長化手法を実装する必要があります。具体的には、送信されるデータのブロック上の追加 CRC、送信データのリードバック、Questionあるいは Answerプロトコルなどがあります。適切な方法を使用すると、内部バスを介して、Cyclone V SoCの内部ストレージからのデータ送信のパス全体、内部バス、通信モジュール、外部インタフェースとエンドポイントの診断能力を提供することができます。
表 4-91: ISO26262リファレンス：Information Redundancy
ソース 参照先
ISO26262-5:2011 Annex D Table D.8 Information redundancy
ISO26262-5:2011 Annex D Section D.2.7.6
コンフィギュレーション・レジスタの定期的なリード・バックコンフィギュレーション・レジスタが正確であることを確認するには、レジスタの内容をリード・バックし、その内容と意図した値と比較します。その値をレジスタに書き込み、このリード・バックを定期的に繰り返し実行します。注意: 一部のレジスタは、レジスタをリードする際に自動でクリアするビットを実装することが
できます。アプリケーションのビヘイビアが変更されることがあるので、リードが一部のビットのステータスに影響を与えることがないようにします。
表 4-92: ISO26262リファレンス：Configuration Register Test
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
MNL-10792015.07.14 情報冗長の実装 4-57
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
ソース 参照先
ISO26262-5:2011 Annex D Section D.2.3.7
USB 2.0 OTGコントローラの使用前提
表 4-93: USB 2.0 OTGコントローラの使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
USB1 SECDED（ECC) ++ 1. 検出および訂正機能をテストするためのテスト・パターンを実行する
USB2 I/Oインタフェース・テスト
++ 1. 2つ目の Cortex-A9プロセッサのステータスのリードバックと結果の比較
USB3 情報冗長 ++ 1. テスト・パターン
USB4 定期的なコンフィギュレーション・レジスタのテスト
+ 1. 2つ目の Cortex-A9プロセッサのレジスタ設定のリードバックと結果の比較
HPS SPIコントローラHPSは、2個のシリアル・ペリフェラル・インタフェース（SPI）マスタと 2個の SPIスレーブを提供します。SPIマスタとスレーブは、Synopsys® DesignWare® Synchronous Serial Interface（SSI）コントローラ（DW_apb_ssi)のインスタンスです。詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 19章：SPIコントローラ
I/Oインタフェースのテストアプリケーションで SPIを使用する前に、I/Oインタフェースのテストを実行します。送信テストは、Cyclone V SoCと他のエンドポイント間のインタフェースをテストすることができます。また、定義済のハンドシェイク・プロトコルをエンドポイント間に実装し、アプリケーション起動時に接続をテストすることも可能です。
4-58 USB 2.0 OTGコントローラの使用前提MNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
表 4-94: ISO26262リファレンス：Test pattern
ソース 参照先
ISO26262-5:2011 Annex D Table D.7 テスト・パターン
ISO26262-5:2011 Annex D Section D.2.6.1
情報冗長の実装送信データに対しては、冗長化手法を実装する必要があります。具体的には、送信されるデータのブロック上の追加 CRC、送信データのリードバック、Questionあるいは Answerプロトコルなどがあります。適切な方法を使用すると、内部バスを介して、Cyclone V SoCの内部ストレージからのデータ送信のパス全体、内部バス、通信モジュール、外部インタフェースとエンドポイントの診断能力を提供することができます。
表 4-95: ISO26262リファレンス：Information Redundancy
ソース 参照先
ISO26262-5:2011 Annex D Table D.8 Information redundancy
ISO26262-5:2011 Annex D Section D.2.7.6
コンフィギュレーション・レジスタの定期的なリード・バックコンフィギュレーション・レジスタが正確であることを確認するには、レジスタの内容をリード・バックし、その内容と意図した値と比較します。その値をレジスタに書き込み、このリード・バックを定期的に繰り返し実行します。注意: 一部のレジスタは、レジスタをリードする際に自動でクリアするビットを実装することが
できます。アプリケーションのビヘイビアが変更されることがあるので、リードが一部のビットのステータスに影響を与えることがないようにします。
表 4-96: ISO26262リファレンス：Configuration Register Test
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
MNL-10792015.07.14 情報冗長の実装 4-59
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
ソース 参照先
ISO26262-5:2011 Annex D Section D.2.3.7
SPIコントローラの使用前提
表 4-97: SPIコントローラの使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
SPI1 I/Oインタフェース・テスト
++ 1. 2つ目の Cortex-A9プロセッサのステータスのリードバックと結果の比較
SPI2 情報冗長 ++ 1. テスト・パターン
SPI3 定期的なコンフィギュレーション・レジスタのテスト
+ 1. 2つ目の Cortex-A9プロセッサのレジスタ設定のリードバックと結果の比較
HPS I2CコントローラI2Cコントローラは、ボード上の集積回路間の通信リンクへのサポートを提供します。I2Cコントローラは、シリアル・データ・ライン（SDA）とシリアル・クロック（SCL）から成るシンプルな 2線式のバスで、温度センサおよび EEPROMへの電圧レベル変換、A/Dおよび D/Aコンバータなどのアプリケーションや多くのマイクロプロセッサに使用されます。ハード・プロセッサ・システム（HPS）は、システム・ソフトウェアによる I2Cバスとのシリアル通信を可能にする 4個の I2Cコントローラを提供しています。この I2Cコントローラは、Synopsys DesignWare APB I2C（DW_apb_i2c）コントローラのインスタンスです。詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 20章：I2Cコントローラ
I/Oインタフェースのテストアプリケーションで I2Cを使用する前に、I/Oインタフェースのテストを実行します。送信テストは、Cyclone V SoCと他のエンドポイント間のインタフェースをテストすることができます。また、定義済のハンドシェイク・プロトコルをエンドポイント間に実装し、アプリケーション起動時に接続をテストすることも可能です。Table 97:ISO26262リファレンス：Test pattern
4-60 SPIコントローラの使用前提MNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
表 4-98: ソース 参照先
ソース 参照先
ISO26262-5:2011 Annex D Table D.7 テスト・パターン
ISO26262-5:2011 Annex D Section D.2.6.1
情報冗長の実装送信データに対しては、冗長化手法を実装する必要があります。具体的には、送信されるデータのブロック上の追加 CRC、送信データのリードバック、Questionあるいは Answerプロトコルなどがあります。適切な方法を使用すると、内部バスを介して、Cyclone V SoCの内部ストレージからのデータ送信のパス全体、内部バス、通信モジュール、外部インタフェースとエンドポイントの診断能力を提供することができます。
表 4-99: ISO26262リファレンス：Information Redundancy
ソース 参照先
ISO26262-5:2011 Annex D Table D.8 Information redundancy
ISO26262-5:2011 Annex D Section D.2.7.6
コンフィギュレーション・レジスタの定期的なリード・バックコンフィギュレーション・レジスタが正確であることを確認するには、レジスタの内容をリード・バックし、その内容と意図した値と比較します。その値をレジスタに書き込み、このリード・バックを定期的に繰り返し実行します。注意: 一部のレジスタは、レジスタをリードする際に自動でクリアするビットを実装することが
できます。アプリケーションのビヘイビアが変更されることがあるので、リードが一部のビットのステータスに影響を与えることがないようにします。
表 4-100: ISO26262リファレンス：Configuration Register Test
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
MNL-10792015.07.14 情報冗長の実装 4-61
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
ソース 参照先
ISO26262-5:2011 Annex D Section D.2.3.7
I2Cコントローラの使用前提
表 4-101: I2Cコントローラの使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
I2C1 I/Oインタフェース・テスト
++ 1. 2つ目の Cortex-A9プロセッサのステータスのリードバックと結果の比較
I2C2 情報冗長 ++ 1. テスト・パターン
I2C3 定期的なコンフィギュレーション・レジスタのテスト
+ 1. 2つ目の Cortex-A9プロセッサのレジスタ設定のリードバックと結果の比較
UARTコントローラハード・プロセッサ・システム（HPS）は、非同期シリアル通信用に 2個の UARTコントローラを提供しています。 UARTコントローラは、業界標準の 16550 UARTコントローラに基づいています。 UARTコントローラは、Synopsys® DesignWare® APB Universal Asynchronous Receiver/Transmitter（DW_apb_uart）ペリフェラルのインスタンスです。詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 21章：UARTコントローラ
I/Oインタフェースのテストアプリケーションで UARTを使用する前に、I/Oインタフェースのテストを実行します。UARTは TXピンと RXピンを内部で接続する内部ループバック・モードをサポートしています。UARTはまた、外部ロジックがループバック・テストの影響を受けないよう、TXピンを非アクティブにコンフィギュレーションします。送信テストは、Cyclone V SoCと他のエンドポイント間のインタフェースをテストすることができます。また、定義済のハンドシェイク・プロトコルをエンドポイント間に実装し、アプリケーション起動時に接続をテストすることも可能です。
4-62 I2Cコントローラの使用前提MNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
表 4-102: ISO26262リファレンス：Test Pattern
ソース 参照先
ISO26262-5:2011 Annex D Table D.7 Test Pattern
ISO26262-5:2011 Annex D Section D.2.6.1
情報冗長の実装送信データに対しては、冗長化手法を実装する必要があります。具体的には、送信されるデータのブロック上の追加 CRC、送信データのリードバック、Questionあるいは Answerプロトコルなどがあります。適切な方法を使用すると、内部バスを介して、Cyclone V SoCの内部ストレージからのデータ送信のパス全体、内部バス、通信モジュール、外部インタフェースとエンドポイントの診断能力を提供することができます。
表 4-103: ISO26262リファレンス：Information Redundancy
ソース 参照先
ISO26262-5:2011 Annex D Table D.8 Information redundancy
ISO26262-5:2011 Annex D Section D.2.7.6
コンフィギュレーション・レジスタの定期的なリード・バックコンフィギュレーション・レジスタが正確であることを確認するには、レジスタの内容をリード・バックし、その内容と意図した値と比較します。その値をレジスタに書き込み、このリード・バックを定期的に繰り返し実行します。注意: 一部のレジスタは、レジスタをリードする際に自動でクリアするビットを実装することが
できます。アプリケーションのビヘイビアが変更されることがあるので、リードが一部のビットのステータスに影響を与えることがないようにします。
表 4-104: ISO26262リファレンス：Configuration Register Test
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
MNL-10792015.07.14 情報冗長の実装 4-63
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
ソース 参照先
ISO26262-5:2011 Annex D Section D.2.3.7
UARTコントローラの使用前提
表 4-105: UARTコントローラの使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
UART1 I/Oインタフェース・テスト
++ 1. 2つ目の Cortex-A9プロセッサのステータスのリードバックと結果の比較
UART2 情報冗長 ++ 1. テスト・パターン
UART3 定期的なコンフィギュレーション・レジスタのテスト
+ 1. 2つ目の Cortex-A9プロセッサのレジスタ設定のリードバックと結果の比較
HPSタイマHPSは、レベル 4（L4）ペリフェラル・バスに接続された 4個の 32ビット汎用タイマを提供します。このタイマには、32ビットのバイナリ・カウント・ダウン・タイマがゼロに達した時点で割り込みを生成するオプションを備えています。タイマは、Synopsys® DesignWare® APBTimers（DW_apb_timers）ペリフェラルのインスタンスです。詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 23章：タイマ
HPSタイマのクロス・チェック
アプリケーションは、いずれかのタイマの潜在的な問題を検出するために、それぞれのタイマからのタイマ・イベントのクロスチェックを実行することが可能です。また、妥当性を確認するためにMPUサブシステムないでグローバル・タイマを使用することも可能です。グローバル・タイマの詳細については、ARM社のウェブサイトで閲覧可能な Cortex-A9 MPCoreテクニカルリファレンス マニュアル リビジョン 3p0のグローバル・タイマ、プライベート・タイマ、ウォッチドッグ・レジスタの章を参照してください。
4-64 UARTコントローラの使用前提MNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
さらに、プロセッサの割り込みをチェックする目的で FPGAファブリック内に専用タイマ・ブロックを実装することも可能です。一般的な原因による障害を考慮するために、別の電源レールとクロックで FPGAを供給することができます。
関連情報infocenter.arm.com
コンフィギュレーション・レジスタの定期的なリード・バックコンフィギュレーション・レジスタが正確であることを確認するには、レジスタの内容をリード・バックし、その内容と意図した値と比較します。その値をレジスタに書き込み、このリード・バックを定期的に繰り返し実行します。注意: 一部のレジスタは、レジスタをリードする際に自動でクリアするビットを実装することが
できます。アプリケーションのビヘイビアが変更されることがあるので、リードが一部のビットのステータスに影響を与えることがないようにします。
表 4-106: ISO26262リファレンス：Configuration Register Test
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
HPSタイマの使用前提
表 4-107: HPSタイマの使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
HTIM1 タイマ・クロスチェック + 1. テスト・パターン
HTIM2 定期的なコンフィギュレーション・レジスタのテスト
+ 1. 2つ目の Cortex-A9プロセッサのレジスタ設定のリードバックと結果の比較
HPSウォッチドッグ・タイマウォッチドッグタイマの主要な役割は、応答不能な状態からシステムを回復する方法を提供することです。ハード・プロセッサ・システム（HPS）は、レベル 4（L4）ペリフェラル・バスに接続されたプログラム可能なウォッチドッグ・タイマを 2個提供します。ウォッチドッグ・タイマは、Synopsys® DesignWare® APB Watchdog Timer（DW_apb_wdt）ペリフェラルのインスタンスです。
MNL-10792015.07.14 コンフィギュレーション・レジスタの定期的なリード・バック 4-65
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
外部オシレータ・クロックが直接ウォッチドッグをドライブします。一旦イネーブルされると、ディセーブルはリセットによってのみ可能です。詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 24章：ウォッチドッグ・タイマ
ウォッチドッグのテストアプリケーションの起動時にウォッチドッグをテストします。ウォッチドッグをコンフィギュレーションし、ウォッチドッグがリセットを確実に生成するようタイムアウトさせます。
表 4-108: ISO26262リファレンス：Test Pattern
ソース 参照先
ISO26262-5:2011 Annex D Section D.2.6.1
コンフィギュレーション・レジスタの定期的なリード・バックコンフィギュレーション・レジスタが正確であることを確認するには、レジスタの内容をリード・バックし、その内容と意図した値と比較します。その値をレジスタに書き込み、このリード・バックを定期的に繰り返し実行します。注意: 一部のレジスタは、レジスタをリードする際に自動でクリアするビットを実装することが
できます。アプリケーションのビヘイビアが変更されることがあるので、リードが一部のビットのステータスに影響を与えることがないようにします。
表 4-109: ISO26262リファレンス：Configuration Register Test
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
HPSウォッチドッグ・タイマの使用前提
表 4-110: HPSウォッチドッグ・タイマの使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
HWD1 テスト・パターン + 1. 外部ウォッチドッグ
2. FPGAファブリック内のウォッチドッグ
4-66 ウォッチドッグのテストMNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
HWD2 周期的なコンフィギュレーション・レジスタのテスト
+ 1. 2つ目の Cortex-A9プロセッサのレジスタ設定のリードバックと結果の比較
HPS CANコントローラHPSは、2つの CANコントローラを提供しています。 CANコントローラは Bosch® D_CANコントローラのインスタンスであり、ISO 11898-1に準拠しています。詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 25章：CANコントローラ
SECDED
ECCは CANメッセージバッファを保護します。 ECCは SECDEDをサポートしています。 ECCは、両方のエラーケースに対し Cortex-A9 MPUへの割り込みを生成し、システム・マネージャはこの割り込みを制御します。CANにエラーを注入して、検出と訂正の機能を評価することができます。
表 4-111: ISO26262リファレンス：Memory Monitoring Using EDC Codes
ソース 参照先
ISO26262-5:2011 Annex D Table D.6 Memory monitoring using EDC codes.
ISO26262-5:2011 Annex D Section D.2.4.1
詳細は、Cyclone V Device Handbookを参照してください。• Volume 3：ハード・プロセッサ・システムのテクニカル・リファレンス・マニュアル• 第 5章：システム・マネージャ
ループバック・モード
多くの CANトランシーバは、CANコントローラとトランシーバ間の物理的なピン接続の検証を可能にするループバック・モードをサポートしています。アプリケーション起動時にこのループバック・テストを実行します。また、CANコントローラはサイレント・モードとループバック・モードをサポートしています。ループバック・モードでは、コントローラは送信されたメッセージをリードバックするために TXピンを RXピンと内部で接続します。ループバック・モードではさらに、CANコントローラは CANトランシーバに TXピンを接続し、CANバス上でメッセ
MNL-10792015.07.14 HPS CANコントローラ 4-67
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
ージを転送します。サイレント・モードとループバック・モードを組み合わせることで、TXピンと RXピン間の内部接続がコンフィギュレーションされるだけでなく、メッセージが CAN TXピンを介して転送されないことが保証されます。
表 4-112: ISO26262リファレンス：Test Pattern
ソース 参照先
ISO26262-5:2011 Annex D Table D.7 Test Pattern
ISO26262-5:2011 Annex D Section D.2.6.1
情報冗長の実装送信データに対しては、冗長化手法を実装する必要があります。具体的には、送信されるデータのブロック上の追加 CRC、送信データのリードバック、Questionあるいは Answerプロトコルなどがあります。適切な方法を使用すると、内部バスを介して、Cyclone V SoCの内部ストレージからのデータ送信のパス全体、内部バス、通信モジュール、外部インタフェースとエンドポイントの診断能力を提供することができます。
表 4-113: ISO26262リファレンス：Information Redundancy
ソース 参照先
ISO26262-5:2011 Annex D Table D.8 Information redundancy
ISO26262-5:2011 Annex D Section D.2.7.6
コンフィギュレーション・レジスタの定期的なリード・バックコンフィギュレーション・レジスタが正確であることを確認するには、レジスタの内容をリード・バックし、その内容と意図した値と比較します。その値をレジスタに書き込み、このリード・バックを定期的に繰り返し実行します。注意: 一部のレジスタは、レジスタをリードする際に自動でクリアするビットを実装することが
できます。アプリケーションのビヘイビアが変更されることがあるので、リードが一部のビットのステータスに影響を与えることがないようにします。
表 4-114: ISO26262リファレンス：Configuration Register Test
ソース 参照先
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
4-68 情報冗長の実装MNL-1079
2015.07.14
Altera Corporation 偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ
フィードバック
ソース 参照先
ISO26262-5:2011 Annex D Section D.2.3.7
CANコントローラの使用前提
表 4-115: CANコントローラの使用前提
識別子 安全または診断機能 推奨度 潜在的な診断メカニズム
CAN1 SECDED（ECC) ++ 1. 検出および訂正機能をテストするためのテスト・パターンを実行する
CAN2 I/Oインタフェース・テスト
++ 1. 2つ目の Cortex-A9プロセッサのステータスのリードバックと結果の比較
CAN3 情報冗長 ++ 1. テスト・パターン
CAN4 周期的なコンフィギュレーション・レジスタのテスト
+ 1. 2つ目の Cortex-A9プロセッサのレジスタ設定のリードバックと結果の比較
MNL-10792015.07.14 CANコントローラの使用前提 4-69
偶発ハードウェア障害の管理に向けた Cyclone V SoCアーキテクチャ Altera Corporation
フィードバック
ISO26262に特化した FPGAデザイン用のテクニックと方法 5
2015.07.14
MNL-1079 更新情報 フィードバック
以下のトピックで、ISO26262-5:2011および他の方法に関連する ISO26262-10:2012 Table A.8に記載された特定のテクニックと方法を紹介します。また、ASICデザインに向けた方法の多くがFPGAデザインにも参照されているため、ASICデザインについても考慮します。
デザイン入力ISO26262-10:2012表 A.8の最初のセクションには、マイクロ・コントローラ・デバイス向けのデザイン入力が記述されていますが、これは一般的に FPGA開発にも適用可能です。これらのトピックでは、表 A.8の各項目を満たす際に、アルテラのツールやプロセスを適用可能であるかどうかについて記述しています。
Structured Description（構造化記述）
表 5-1: デザイン入力：構造化記述
ソース 参照先
ISO26262-10:2012: Table A.8 Ref 1: Structured description
ISO26262-5:2011 Section 7.4.1.6
コンプライアンス・タイプ Procedural: coding guidelines
推奨ツール なし
このようなテクニックを使用することは、デザイン・プロセスおよびコーディング標準の一部です。Quartus IIソフトウェアは階層デザインおよびモジュラー・デザインをサポートします。
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks ofIntel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to currentspecifications 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 expresslyagreed to in writing by Intel. Intel customers are advised to obtain the latest version of device specifications before relying on any published informationand before placing orders for products or services.*Other names and brands may be claimed as the property of others.
ISO9001:2008登録済
www.altera.com101 Innovation Drive, San Jose, CA 95134
Design description in HDL（HDLによるデザインの記述）
表 5-2: デザイン入力：Design description in HDL（HDLによるデザインの記述）
ソース 参照先
ISO26262-10:2012: Table A.8 Ref 2: Design description in HDL
ISO26262-5:2011 Section 7.4.1.6
コンプライアンス・タイプ Technical: tool use
推奨ツール 標準的なテキスト・エディタ
注意: Quartus IIソフトウェアは、広範囲の複数言語のコンパイル・サポートを有しており、同一のデザインで VHDLと Verilog HDLのいずれのモジュールもサポートすることができます。この機能は、異なる（V）HDLでコード化されているサードパーティーの IPを統合する際に使用します。
テキスト形式の（V）HDLデザイン入力は、標準的なテキスト・エディタを使用して実装することが可能です。テキスト・エディタには、（V）HDLデザインに向けた強化機能を有しているテキスト・エディタもあります。例えば、J-Editや Emacsといったツールには、コンテキストのハイライトをはじめとする言語に関連する機能を持つ（V）HDLモードが使用可能です。Quartus IIソフトウェアには、このような言語に関連した多くの機能を持つテキスト・エディタが搭載されており、安全性に関連する開発に使用することができます。Project Settingを調整することで、Quartus IIソフトウェアでコンパイルを実行中にデザインで使用する言語のバージョンを指定することができます。コーディング・サイクルの前に、（V）HDL言語とそのバージョンを選択しておきます。この選択は、Project requirements specificationで指定します。.
回路図入力
表 5-3: デザイン入力：回路図入力
ソース 参照先
ISO26262-10:2012: Table A.8 なし
ISO26262-5:2011 なし
Compliance Type Technical: tool use
Suggested Tool Quartus II schematic entry tool
5-2 Design description in HDL（HDLによるデザインの記述）MNL-1079
2015.07.14
Altera Corporation ISO26262に特化した FPGAデザイン用のテクニックと方法
フィードバック
Quartus IIソフトウェアは、回路図キャプチャ・デザイン入力をサポートしています。今日の高度に複雑化したデザインには、このアプローチは適していません。回路図ベースのデザインを維持し、チェックするには労力を要するため、複雑なデザインには不向きです。注意: アルテラでは、このフローを使用しないよう強く推奨しています。デザインには、.bdf
や bsfファイルが含まれていないことを確認してください。デザイン・レビューの段階で、これらのファイル・タイプをプロジェクト・ディレクトリで確認してください。
ブール式を使用したデザインの記述
表 5-4: デザイン入力：ブール式を使用したデザインの記述
ソース 参照先
ISO26262-10:2012: Table A.8 なし
ISO26262-5:2011 なし
Compliance Type Procedural: coding style
Suggested Tool なし
Quartus IIソフトウェアのフローは、デザイン入力方法としてのブール式の記述をサポートしていません。
モジュール化
表 5-5: デザイン入力：モジュール化
ソース 参照先
ISO26262-10:2012: Table A.8 なし
ISO26262-5:2011 Clause 7.4.1
コンプライアンス・タイプ Procedural: coding style
推奨ツール なし
Quartus IIソフトウェアは、階層およびモジュラー・デザインをサポートしています。コーディングのガイドラインで、デザイン内においてモジュール化を適用する方法を指定する必要があります。 Quartus IIソフトウェアおよびその機能は、モジュールの設計に役立ちます。
MNL-10792015.07.14 ブール式を使用したデザインの記述 5-3
ISO26262に特化した FPGAデザイン用のテクニックと方法 Altera Corporation
フィードバック
Project Navigator
Quartus IIソフトウェアの Project Navigatorペインは、デザイン内のモジュールのデザイン階層を示します。 Project Navigatorは、デザイン・ストラクチャを視覚的に表示します。また、QuartusIIレポート・ファイルは、この同じ階層またはモジュール方式でデータを示します。
デザイン・パーティション
Quartus IIソフトウェアは、デザイン・パーティションとして知られるコードがカプセル化されたブロックを定義することが可能です。このようなパーティションはそれぞれ個別にコンパイルすることができます。以前のコンパイル結果を次の合成と配置配線手順に再利用することができます。この方法が使用される理由を以下に挙げます。• コンパイル時間の短縮• パフォーマンスの向上• チーム・ベースのデザインQuartus IIソフトウェアは、特定のデザイン内のパーティションを視覚的に表示します。このインタフェースは、パーティションの相対的なサイズおよびパーティション間の相互接続の数を示します。デザイン・パーティションおよびチーム・ベースの階層デザインの詳細については、Quartus IISoftware Handbook v14.1の以下のトピックを参照してください。• Volume 1：設計と合成• 第 2章：Quartus IIソフトウェアによるデザイン・プランニング
Proven in Use（使用実績のある）デザイン環境の適用
表 5-6: デザイン入力：Proven in Use（実績による使用）デザイン環境の適用
ソース 参照先
ISO26262-10:2012: Table A.8 なし
ISO26262-8:2011 Clause 14
Compliance Type Technical: tool use
Suggested Tool Quartus II
Quartus IIソフトウェアが上記の項を満たしていることは、以下の点に集約されます。• Quartus IIソフトウェアは、すでに長期間（Quartusソフトウェアとして 2001年より）マーケットに存在しています。
• アルテラは、複数のマーケットにわたり多くのユーザーを持っています。• アルテラによって実行された多くのテストは、ISO26262-8:2011, 11項の要件の多くの部分を満たしています。
5-4 Project NavigatorMNL-1079
2015.07.14
Altera Corporation ISO26262に特化した FPGAデザイン用のテクニックと方法
フィードバック
Quartus IIソフトウェア内の Nios II統合開発環境（IDE）ツールは、GCCコンパイラ・ツール・チェーン（プリプロセッサ、コンパイラ、リンカ）を使用します。Nios II IDEツールは、Nios IIプロセッサをターゲットとする C/C ++ソース・コードをコンパイルします。 GCCの特定のビルドのの完全なバグ・リストは、GNUのウェブサイトから入手可能です。このツールおよびバージョンに関する最新情報については、GCCのウェブサイトを参照してください。コンパイルと配置配線には、Quartus IIソフトウェアを使用する必要があります。論理シミュレータなどのツールを選択する際は、そのツールが確立されたツールの信頼性レベルを満たしていることを確認してください。関連情報GCC, the GNU Compiler Collection Website
HDLシミュレーション
表 5-7: デザイン入力：HDLシミュレーション
ソース 参照先
ISO26262-10:2012: Table A.8 Ref 3: HDL simulation
ISO26262-5:2011 Section 7.4.4
コンプライアンス・タイプ Technical: tool use
推奨ツール サードパーティー製シミュレータによってサポートされます
アルテラの FPGAを使用しているのであれば、開発にサードパーティー製のシミュレータが使用可能です。開発には信頼のおけるツールを使用してください。要件については、ISO26262-8:2011clause 11を参照してください。アルテラは NativeLink機能により一般的に使用される様々なシミュレータとの統合が可能です。サポートしているサードパーティー製シミュレータの詳細については、Quartus II SoftwareHandbook v14.1の以下のトピックを参照してください。• Volume 3：検証• 第 1章：アルテラ・デザインのシミュレーション
MNL-10792015.07.14 HDLシミュレーション 5-5
ISO26262に特化した FPGAデザイン用のテクニックと方法 Altera Corporation
フィードバック
モジュール・レベルでの機能テスト
表 5-8: デザイン入力：モジュール・レベルでの機能テスト
ソース 参照先
ISO26262-10:2012: Table A.8 Ref 4: Functional test on module level
（HDLテストベンチを使用）
ISO26262-5:2011 Section 7.4.4
コンプライアンス・タイプ Technical: testbench coding
推奨ツール なし
この方法は、モジュール・レベルで機能性をテストすることができるテストベンチの適切な記述を解説します。テスト対象のモジュールに向けて作成されたテスト記述を参照してください。テスト記述には個別のテスト・アイテム、カバレッジ・レベル、テスト除外、起こり得る障害などのアイテムを明記しておきます。
トップレベル・モジュールでの機能テスト
表 5-9: デザイン入力：トップレベルでの機能テスト
ソース 参照先
ISO26262-10:2012: Table A.8 Ref 5: Functional test on top level
ISO26262-5:2011 Section 7.4.4
Compliance Type Technical: testbench coding
Suggested Tool なし
この方法は、トップレベルで機能性をテストすることができるテストベンチの適切な記述を解説します。テスト対象のモジュールおよびトップレベルに向けて作成されたテスト記述を参照してください。テスト記述には個別のテスト・アイテム、カバレッジ・レベル、テスト除外、起こり得る障害などのアイテムを明記しておきます。
5-6 モジュール・レベルでの機能テストMNL-1079
2015.07.14
Altera Corporation ISO26262に特化した FPGAデザイン用のテクニックと方法
フィードバック
Restricted use of asynchronous constructs（非同期構文の使用制限）
表 5-10: デザイン入力：Restricted use of asynchronous constructs（非同期構文の使用制限）
ソース 参照先
ISO26262-10:2012: Table A.8 Ref 6: Restricted use of asynchronous constructs
ISO26262-5:2011 Section 7.4.2.4
コンプライアンス・タイプ Procedural: coding style
推奨ツール なし
特に master SETおよび RESETの同期といった非同期構文の使用に制限を加える方法を適用してください。小さなプロセス・ノードであれば、2つ以上のフリップ・フロップ・ステージを含めることができます。メタスタビリティおよび同様のストラクチャが正常に動作することを確認するには、デザインのメタスタビリティ分析を実行します。この動作を実行するには、QuartusIIソフトウェアの metastability reportingツールを使用します。メタスタビリティと同期チェインの長さについての詳細情報は、Quartus II Software Handbookv14.1の以下のトピックを参照してください。• Volume 1: 設計と合成• 第 13章：Quartus IIソフトウェアを使用したメタスタビリティの管理推奨するデザイン・コーディングの詳細については、Quartus II Software Handbook v14.1の以下のトピックを参照してください。• Volume 1: 設計と合成• 第 11章：推奨するデザイン手法
プライマリ入力の同期およびメタスタビリティの管理
表 5-11: デザイン入力：プライマリ入力の同期およびメタスタビリティの管理
ソース 参照先
ISO26262-10:2012: Table A.8 Ref 7: Synchronization of Primary Inputs andControl of Metastability
ISO26262-5:2011 Section 7.4.2.4
Compliance Type Technical: tool use
Suggested Tool タイミング解析
MNL-10792015.07.14 Restricted use of asynchronous constructs（非同期構文の使用制限） 5-7
ISO26262に特化した FPGAデザイン用のテクニックと方法 Altera Corporation
フィードバック
メタスタビリティおよび同様のストラクチャが正常に動作することを確認するには、デザインのメタスタビリティ分析を実行します。この動作を実行するには、Quartus IIソフトウェアのmetastability reportingツールを使用します。メタスタビリティと同期チェインの長さについての詳細情報は、Quartus II Software Handbookv14.1の以下のトピックを参照してください。• Volume 1: 設計と合成• 第 13章：Quartus IIソフトウェアを使用したメタスタビリティの管理
機能的および構造的カバレッジ・ドリブン検証
表 5-12: デザイン入力：機能的および構造的カバレッジ・ドリブン検証
ソース 参照先
ISO26262-10:2012: Table A.8 Ref 8: Functional and Structural coverage-drivenVerification
ISO26262-5:2011 Section 7.4.4
コンプライアンス・タイプ Technical: tool use
推奨ツール コード・カバレッジ・ツール
Quartus IIソフトウェアには、コード・カバレッジの計算が含まれていません。認定の一部としてこの情報を提供したい場合は、適切なツールを選択して使用する必要があります。この機能は通常、論理シミュレータ・ツール内で利用可能です。
コーディング・ガイドラインの順守
表 5-13: デザイン入力：コーディング・ガイドラインの順守
ソース 参照先
ISO26262-10:2012: Table A.8 Ref 9: Observation of coding guidelines
ISO26262-5:2011 Section 7.4.2.4
Compliance Type Procedural: coding style
Suggested Tool Third-party lint checker tool
設計プロセスの一環として、コーディング・ガイドラインをコーディングの規則を順守します。プロジェクトの開始時に任意のガイドラインを指定します。例外を認める場合は、例外はコード・レビュー・プロセスの一部と特別にレビューします。
5-8 機能的および構造的カバレッジ・ドリブン検証MNL-1079
2015.07.14
Altera Corporation ISO26262に特化した FPGAデザイン用のテクニックと方法
フィードバック
Quartus II開発ソフトウェア・ハンドブックに記載されたコーディング・スタイルを使用してください。このような推奨事項は、コーディング・ガイドラインに含めることができます。Quartus II Design Assistantは、デザインの様々な部分の分析に役立ちます。このツールは、デザイン・ルール・チェック・ツールに似た利用方法を持っています。さらに、特定のデザインのパフォーマンスを向上させる提案を提供することができます。コーディング・スタイルの詳細については、Quartus II Software Handbook v14.1の以下のトピックを参照してください。• Volume 1： 設計と合成• 第 12章：推奨 HDLコーディング・スタイル
コード・チェッカの適用
表 5-14: デザイン入力：コード・チェッカの適用
ソース 参照先
ISO26262-10:2012: Table A.8 Ref 10: Application of code checker
ISO26262-5:2011 Section 7.4.4
Compliance Type Procedural: coding style
Suggested Tool Third-party lint checker tool
コード・チェック・ツールは、設計フローで自動的に実行する必要があります。
検査コードまたはウォークスルー
表 5-15: デザイン入力：検査コードまたはウォーク・スルー
ソース 参照先
ISO26262-10:2012: Table A.8 なし
ISO26262-5:2011 Section 7.4.4
コンプライアンス・タイプ Procedural: observation of documented process
推奨ツール なし
検査コードまたはウォーク・スルーは設計と開発プロセスの一部です。このステップのは適切なデザイン・メンバーもしくは検証チームにより実行・記録されるべきです。これはプロセス・ステップの 1つにしか過ぎないため、このアイテムに向けてアルテラが推奨するツールは特にありません。
MNL-10792015.07.14 コード・チェッカの適用 5-9
ISO26262に特化した FPGAデザイン用のテクニックと方法 Altera Corporation
フィードバック
検証済みのソフト・コアの適用
表 5-16: デザイン入力：検証済みのソフト・コアの適用
ソース 参照先
ISO26262-10:2012: Table A.8 なし
ISO26262-5:2011 なし
コンプライアンス・タイプ Technical: tool
推奨ツール なし
Quartus IIソフトウェアを使用することで、デザインに IPコアを含めることが可能です。このような IPコアはアルテラの広範な IPコアのポートフォリオ、あるいはサードパーティー各社から入手することができます。一般的には、ソフト IPコアは他のソース・コードと同じ方法でコンパイルされますが、組み込みの手順やパラメータ化の手順は異なることがあります。アルテラでは、IPコアをアルテラ・ツールに実装するにあたって様々な方法を提供しています。
安全性に関連するデザインに Nios IIプロセッサを組み込むNios IIプロセッサは、安全性に関連するデザインに組み込むことが可能です。ただし、ISO26262:2011-2012規格の要件を十分に考察し、関連するすべての項に対応するよう、使用するシステム・アーキテクチャを特別に構築する必要があります。関連情報Nios II Classic Processor Reference Guide
Nios IIデータ・キャッシュ
データ・キャッシュのストラクチャが、コードを実行する際に特定の変動性をもたらす場合があります。キャッシュ・コヒーレンシを維持するには複雑さが伴うため、安全性に関連するデザインでデータ・キャッシュを使用することが適切ではないことがあります。このデータ・キャッシュを使用するかどうかの決定はデザインごとに行うべきです。また、これらの解説は本資料には含まれません。データ・キャッシュ・ストラクチャを使用するかどうかの決定は、認定アセッサーと確認してください。Qsysで Nios IIプロセッサをコンフィギュレーションする際、特定のプロセッサ・インスタンスに対してデータとアドレスのキャッシュ・サイズをそれぞれ選択することができます。 Nios IIプロセッサ内のキャッシュ・サイズ設定に関する詳細は、Nios IIプロセッサのマニュアルを参照してください。
Nios IIプロセッサの割り込み
ソフトウェアの開発で安全性に関連する部分に割り込みを使用するには、慎重に検討する必要があります。割り込みの使用が適さないアプリケーションも存在します。プロジェクト・チームが
5-10 検証済みのソフト・コアの適用MNL-1079
2015.07.14
Altera Corporation ISO26262に特化した FPGAデザイン用のテクニックと方法
フィードバック
この決定を判断し、設計者は FPGAあるいはや一般的な要件仕様書でこのことを指定する必要があります。Nios IIプロセッサを Qsysシステムに組み込む場合、プロセッサ・コアに割り込みを接続するかどうかを選択することができます。要件仕様書でデザインに割り込みを使用してはならないことが記載されている場合は、これらの接続は未接続にしておきます。
Quartus IIおよび Nios IDEのバージョン
Nios IIプロセッサは、Nios II IDEツールがコンパイルするコードを実行します。このツールは、Quartus IIソフトウェアの一部ですが、個別のインストール・プロセスがあります。 安全性に関連する開発を行うには、Nios II IDEバージョンは Quartus IIソフトウェアのバージョンと一致していなければいけません。一部バージョンには Quartus IIソフトウェアと Nios II IDEとの間にクロスの互換性が存在しますが、アルテラでは Quartus IIソフトウェアとの Nios IDEツールが同じバージョンを使用している場合にのみテスト・データを提供します（アルテラは関連する NDAの認証機関にこのテスト・データを提示します）。注意: アルテラの一部の資料では、Nios II IDEは Nios IIエンベデッド・デザイン・スイートと
して記載されていますが、どちらも同じ開発ツールのことを指します。
Nios II GNUツール
The Nios II IDEは、業界標準の GNUツールを使用しています。
表 5-17: GNUのバージョン
次の表は、特定の Nios II IDEビルドに含まれる GNUバージョンを示しています。Nios IIエンベデッド・デザイン・スイートのバージョン
とビルドGNU GCCのバージョンとビルド
14.1.1 build 190 GCC build 4.8.3
The Nios II IDEは、GNUツールの以下の部分を使用します。• Make（GNU make v3.8）• Compiler（GCC）• Linker（GCC）• Binutils（GCC）• Assembler（GCC）• Debugger（GCC）GCCツールによる開発は、アルテラの開発プロセスの管理外となるため、GCCツールのバグ修正や正誤表の最新情報については、GNUウェブサイトにて確認してください。GNU makeに関しては、GNUウェブサイトから最新のバグ修正と正誤表を取得する必要があります。
MNL-10792015.07.14 Quartus IIおよび Nios IDEのバージョン 5-11
ISO26262に特化した FPGAデザイン用のテクニックと方法 Altera Corporation
フィードバック
これらの情報を評価し、GCCおよび GNUツールが ISO26262-8:2011の 11項を満たしているいう証拠を提供する必要があります。Nios II IDEは、Eclipse開発環境エディタを使用しています。Eclipseツールによる開発は、アルテラの開発プロセスの管理外となるため、Eclipseツールのバグ修正や正誤表の最新情報については、Eclipseウェブサイトにて確認してください。
関連情報• http://gcc.gnu.org/gcc-4.8/changes.html• http://www.gnu.org/software/make/• http://www.eclipse.org/platform/
Nios IIプロセッサのオンライン診断カバレッジ
Nios IIプロセッサとそれを取り巻くソフトウェアおよびハードウェア・システムの正確なコンフィギュレーションは複雑です。 ISO26262:2011-2012の様々な部分が関係します。。 Nios IIプロセッサの使用が十分に受け入れられるためには、一定のオンライン診断カバレッジをコアに提供する必要がある場合があります。ISO26262-5:2011 Annex D Table D.4は、診断カバレッジ手法を実装する際の考慮事項を示しています。
サードパーティー製ソフト IPコアの組み込み場合によっては、サードパーティー製 IPコアを Quartus IIソフトウェアに統合することが可能です。サードパーティー製 IPコアはアルテラ提供の IPコアと同じ方法でデザインに組み込むことが可能です。注：サードパーティ製 IPコアをインストールおよび使用するには、必要となるすべての手順を実行しなければなりません。このような要件は各 IPコアのドキュメントに記載されているため、本資料には詳細な解説は含まれません。
ソフト IPコアの検証
表 5-18: デザイン入力：ソフト IPコアの検証
ソース 参照先
ISO26262-10:2012: Table A.8 なし
ISO26262-5:2011 なし
コンプライアンス・タイプ Procedural: design and validation processes
推奨ツール なし
検証がなされていない安全性に関するデザインに IPコアを含めるのであれば、このような IPコアはデザイン・ソース・コードとして扱う必要があります。つまり、このような IPコアは他のデザイン・ソースと同様に検証すべきです。この処理にはツールあるいは Quartus IIのステップは不要です。
5-12 Nios IIプロセッサのオンライン診断カバレッジMNL-1079
2015.07.14
Altera Corporation ISO26262に特化した FPGAデザイン用のテクニックと方法
フィードバック
シミュレーション結果のドキュメンテーション
表 5-19: デザイン入力：シミュレーション結果のドキュメンテーション
ソース 参照先
ISO26262-10:2012: Table A.8 Ref 11: Documentation of simulation results
ISO26262-5:2011 Section 7.4.4
コンプライアンス・タイプ Procedural: documentation steps
推奨ツール なし
このアイテムに関連するアルテラ・ツールはありません。
合成ISO26262-10:2012表 A.8の以下のセクションには、プログラマブル・デバイス使用の合成の手順が記述されています。これらのトピックでは、表 A.8の各項目を満たす際に、アルテラのツールやプロセスを適用可能であるかどうかについて記述しています。
内部整合性のチェック
表 5-20: 合成：内部整合性のチェック
ソース 参照先
ISO26262-10:2012: Table A.8 なし
ISO26262-5:2011 なし
コンプライアンス・タイプ Technical: tool use
推奨ツール Quartus IIソフトウェア、サードパーティ製合成ツール
Quartus IIソフトウェアの合成プロセスには整合性チェックがデフォルトで含まれています。ドキュメンテーションで指定された合成手順を実行するのであれば、特別なアクションは必要ありません。サードパーティ製の合成ツールを使用する場合、内部整合性チェックが含まれているかどうかを確認するには、そのツールに付属するマニュアルを参照してください。詳細については、Quartus II Software Handbook v14.1の以下のトピックを参照してください。• Volume 1: 設計と合成
MNL-10792015.07.14 シミュレーション結果のドキュメンテーション 5-13
ISO26262に特化した FPGAデザイン用のテクニックと方法 Altera Corporation
フィードバック
ゲート・ネットリスト・シミュレーション
表 5-21: 合成：ゲート・ネットリスト・シミュレーション
ソース 参照先
ISO26262-10:2012: Table A.8 Ref 12: Simulation of the gate netlist
ISO26262-5:2011 Section 7.4.4
Compliance Type Technical: tool use
Suggested Tool Supported third-party simulator
この手法では、デザインのすべてのタイミング・コーナーにてシミュレーションをゲート・レベル・ネットリスト上で実行する必要があります。これにより、回路の重要なタイミング状況がシミュレーションされ、シミュレーション・ミスマッチによりエラーがハイライトされます。アルテラは直接的にはこの方法をサポートしていません。また、デザインのスタティック・タイミング解析を実行するという別の方法もあります。この解析には、アルテラの TimeQuest Timing Analyzerツールを使用することができます。シミュレータが動作するためには、正しいアルテラ・ライブラリが存在し、そのライブラリをシミュレータのサーチ・パスに含める必要があります。ライブラリへ含める方法についてはそれぞれのシミュレータの資料を参照してください。各種シミュレータを使用したネットリストの生成やシミュレーションの詳細については、Quartus II Software Handbook v14.1の以下のトピックを参照してください。• Volume 3：検証
伝播遅延のスタティック・タイミング解析（STA）
表 5-22: 合成：伝播遅延の STA
ソース 参照先
ISO26262-10:2012: Table A.8 なし
ISO26262-5:2011 なし
コンプライアンス・タイプ Technical: tool use
推奨ツール Quartus II TimeQuest
Quartus IIソフトウェアは、TimeQuest Timing Analyzerを搭載しており、このツールは、スタティック・タイミングを実行します。この包括的なツールは、タイミング制約と適切な回路の遅延モデルを使用して完全なチップ・デザインを解析します。ハードウェアに実装されるタイミング
5-14 ゲート・ネットリスト・シミュレーションMNL-1079
2015.07.14
Altera Corporation ISO26262に特化した FPGAデザイン用のテクニックと方法
フィードバック
制約は、回路の正しい動作に重要な役割を持ちます。アルテラは回路遅延のモデルを提供しており、これらは Quartus IIソフトウェアの特定のインストールに含まれています。一部のデザイン・フローとサインオフは、TimeQuestレポート・ファイルが「timing clean」なデザイン（制約に違反がないデザイン）であることを確実にします。TimeQuestツールの詳細な解説は本資料には含まれません。注意: 本資料で記述される Quartus IIソフトウェアには、Classic Timing Analyzerが含まれていま
す。適切である場合に使用することが可能ですが、アルテラでは Classic Timing Analyzerの開発は終了しており、TimeQuest Timing Analyzerツールの使用を推奨しています。
TimeQuest Timing Analyzerの詳細については、Quartus II Software Handbook v14.1の以下のトピックを参照してください。• Volume 3：検証
シミュレーションによるリファレンス・モデルに対するゲート・ネットリストの検証
表 5-23: 合成：シミュレーションによるリファレンス・モデルに対するゲート・ネットリストの検証
ソース 参照先
ISO26262-10:2012: Table A.8 Ref 13: Comparison of gate netlist to referencemodel
ISO26262-5:2011 7.4.4
コンプライアンス・タイプ Technical: tool use
推奨ツール Quartus IIシミュレータ
合成およびコンパイル・フローの配置配線の出力を確認するには、ゲート・ネットリストをシミュレーションすることができます。Quartus IIソフトウェアは EDA Netlist Writerを提供しており、EDA Netlist Writerはこの目的のためにシミュレーションに互換性のあるゲート・ネットリストを生成します。EDA Netlist Writerは、配置配線およびタイミング解析のステップからの入力を取り込み、シミュレーションに向けてタイミングが調整されたゲート・ネットリストを生成します。この理由により、これらのステップはゲート・ネットリストの生成前に実行します。シミュレータが動作するためには、正しいアルテラ・ライブラリが存在し、そのライブラリをシミュレータのサーチ・パスに含める必要があります。ライブラリへ含める方法についてはそれぞれのシミュレータの資料を参照してください。各種シミュレータを使用したネットリストの生成やシミュレーションの詳細については、Quartus II Software Handbook v14.1の以下のトピックを参照してください。• Volume 3：検証
MNL-10792015.07.14 シミュレーションによるリファレンス・モデルに対するゲート・ネットリストの検
証5-15
ISO26262に特化した FPGAデザイン用のテクニックと方法 Altera Corporation
フィードバック
リファレンス・モデルとゲート・ネットリストの比較（フォーマル等価性検証)
表 5-24: 合成：リファレンス・モデルとゲート・ネットリストの比較（フォーマル等価性検証)
ソース 参照先
ISO26262-10:2012: Table A.8 Ref 13: Comparison of gate netlist to referencemodel
ISO26262-5:2011 Section 7.4.4
コンプライアンス・タイプ Technical: tool use
推奨ツール サードパーティー製フォーマル等価性検証ツール
Quartus IIソフトウェアは、フォーマル等価性チェック機能を備えていません。この機能を使用するには、サードパーティ製のフォーマル等価性検証ツールを使用する必要があります。このフローでは合成の最適化をオフにする必要があり、Quartus IIソフトウェア内のサポートが限定的であるため、アルテラではこの機能の使用は推奨していません。代わりに、ゲート・レベルのネットリスト・シミュレーションを使用することで、このアイテムを満たすようにします。EDANetlist Writerは、配置配線およびタイミング解析のステップからの入力を取り込み、シミュレーションに向けてタイミングが調整されたゲート・ネットリストを生成します。この理由により、ゲート・ネットリスト生成前にこれらのステップを実行します。フォーマル等価性検証およびサードパーティー製ツールの詳細については、Quartus II SoftwareHandbook v14.1の以下のトピックを参照してください。• Volume 3：検証
ICベンダの要件と制約の確認
表 5-25: 合成：ICベンダの要件と制約の確認
ソース 参照先
ISO26262-10:2012: Table A.8 Ref 14: Documentation of Synthesis Constraints,Results and Tools
ISO26262-5:2011 Section 7.4.1.6
Compliance Type Procedural: document check
Suggested Tool なし
安全性に関するデザインには入手可能な最新データおよび情報が使用されていることを確認してください。Quartus IIソフトウェアの特定のバージョンではデザイン・ライブラリおよびバイナリはスタティックですが、以下の項目には特に注意を払う必要があります。
5-16 リファレンス・モデルとゲート・ネットリストの比較（フォーマル等価性検証)MNL-1079
2015.07.14
Altera Corporation ISO26262に特化した FPGAデザイン用のテクニックと方法
フィードバック
• 製品仕様変更通知（PCN）。この資料には、ユーザーのデザインに影響を与える可能性のあるFPGAの変更点が記載されています。この資料は安全関連のデザインに特化して作成されるものではなく、一般的なデザインに向けて作成されます。安全関連のデザインへの影響を理解するには、こうした変更点を分析する必要があります。PCNのリストについては、アルテラまで問い合わせください。
• シリコン信頼性レポート。このパッケージに含まれるアルテラのシリコン信頼性レポートは、レポート公開時のものです。レポートの数値は、デザインに必要な計算の基礎として使用することができます。ただし、認定を目的としてデザインを提出する前に、最新の数値についてはアルテラまでお問い合わせください。このデータは通常、年 2回更新されます。
注意: アルテラは、一定の信頼レベルを持って信頼性レポートのデータを計算しています。プロジェクトで使用する信頼性レベルの計算を再度実行します。
• SEU（Single Event Upset）データ。システムの安全性の計算には、この情報が使用されます。この情報をリリースする前に秘密保持契約(NDA）を結ぶ必要があります。認定を目的としてデザインを提出する前に、最新の数値についてはアルテラまで問い合わせください。
合成の制約、結果、ツールのドキュメンテーション
表 5-26: 合成：合成の制約、結果、ツールのドキュメンテーション
ソース 参照先
ISO26262-10:2012: Table A.8 Ref 14: Documentation of Synthesis Constraints,Results and Tools
ISO26262-5:2011 Section 7.4.1.6
コンプライアンス・タイプ Procedural: document check
推奨ツール なし
タイミング制約の適用正確なタイミング制約の生成と維持は、FPGAデザインと ASICデザインにおいて重要です。Quartus IIソフトウェアは Synopsys Design Constraints（.sdc）ファイルのタイミング制約をサポートしています。 FPGAと ASIC業界では、この業界標準の制約の形式が広く採用されています。以下の段階でタイミング制約を適用します。• 合成。タイミング制約は、デザインの重要な領域のタイミングに重点を置くよう Quartus IIの合成を駆動します。これはフローのオプション部分ですが、パフォーマンスを向上させ、デザインのロジック使用率を低下させます。
• タイミング解析。 Quartus IIフローのタイミング解析部は（TimeQuestで）、タイミング制約を使用しいます。フロー内のこの重要な局面で、デザインの仕様要件で指定されるタイミング・パラメータをデザインが満たしていることを確認します。デザインが制約を満たしていない場合は、ハードウェアで実行する際にデザインが正常に動作しない場合があります。
MNL-10792015.07.14 合成の制約、結果、ツールのドキュメンテーション 5-17
ISO26262に特化した FPGAデザイン用のテクニックと方法 Altera Corporation
フィードバック
標準的なテキストエディタを使用して、.sdcファイルの生成と編集を実行することができます。TimeQuestツールは、制約の生成に役立つツールを備えています。通常、デザインには特定のモジュールへの情報を含む.sdcファイルが複数含まれています。TimeQuest Timing Analyzerツールおよび制約の生成方法の詳細については、Quartus II SoftwareHandbook v14.1の以下のトピックを参照してください。• Volume 3：検証TimeQuest Timing Analyzer: Native SDC Support for Timing Analysis of FPGA-Based Designs White Paperも参照してください。
一般的なデザイン制約の適用The Quartus II設定ファイル（.qsf）内には一般的なデザイン制約が格納されています。デザインの制約は、デザインの動作および性能に大きな影響を与えます。制約は、デザイン・ソース・ファイルと同じく、慎重に制約を適用する必要があります。以下の操作を.qsfファイルあるいは.sdcファイルで必ず実行してください。• プロジェクト・リビジョン・コントロール・システムに制約を含めます。• デザイン・ソース・ファイルで制約のデザイン・レビューを実行します。.
合成結果のドキュメンテーションQuartus IIソフトウェアは、コンパイル・フローの様々な段階で有用なレポート・ファイルを多数生成します。これらのプレーン・テキスト・ファイルは、様々なツールでそれぞれの手順が実行されると上書きされます。中間レポート・ファイルをアーカイブしたい場合は、プレース・プロシージャに保存します。レポート・ファイルを含む、すべてのプロジェクト・ファイルの出力場所を指定することができます。この設定は、他のプロジェクトに関連するファイルから生成されたファイルを分離する場合に役立ちます。Quartus IIソフトウェアでこのオプションを設定するには、Assignments >Settings > Compilation Process Settingsの順でクリックします。
Proven in Use（使用実績のある）合成の適用
表 5-27: 合成：Proven in Use（使用実績のある）の適用
ソース 参照先
ISO26262-10:2012: Table A.8 なし
ISO26262-5:2011 なし
コンプライアンス・タイプ Procedural: tool specification
推奨ツール Quartus IIの統合合成
分析と合成プロセスにより、FPGAロジック・エレメントにマッピングされるエレメントにロジック・ファンクションが変換されます。合成プロセスは、以下の機能を実行します。
5-18 一般的なデザイン制約の適用MNL-1079
2015.07.14
Altera Corporation ISO26262に特化した FPGAデザイン用のテクニックと方法
フィードバック
1. すべてのデザイン・ソース・ファイルの構文をチェックします2. デザイン階層を詳細に調査し、展開します3.（V）HDLロジックを FPGAロジック・エレメントへ変換します4. FPGAロジック・エレメント内の完全なデザインとロジック接続を表現するデザイン・データベースを作成します
注意: ステップ 1）と 2）は、Quartus II Analysis and Elaborationプロセスを構成しますが、これは Vモデルのコーディング・ステップの一部を形成します。
分析と合成により、デザイン・エンティティもしくはプロジェクト階層内のすべてのデザイン・ファイルを統合する単一のプロジェクト・データベースが構築されます。Quartus IIソフトウェアはこのデータベースを使用し、残りのプロジェクト処理を実行します。その他のコンパイラ・モジュールは、データベースに充分に最適化されたプロジェクトが含まれるまでデータベースを更新します。合成プロセスが（V）HDLソースコードを変換するため、安全性の開発において使用する言語とそのバージョンをデザインの要求の仕様で定義する必要があります。アルテラでは、開発者が言語とバージョンを定義する際、プロジェクト全体を通してそれらを使用することを想定しています。Quartus IIソフトウェアは混合言語をサポートするため、異なる言語が使用されるデザイン・ファイルのサポートが可能です。例えば、サードパーティ製の IPコアが使用可能です。選択する言語は、ロジック・シミュレータといったサードパーティー製ツールにおいてもサポートされていることを確認しておく必要があります。Quartus II開発フロー内では、多くのサードパーティ合成ツールが使用可能です。アルテラは、安全性に関連するデザインにおいてこれらのツールの適合性は評価していません。このため、サードパーティー製ツールに対しては独自の評価を実行する必要があります。proven-in-use合成の特定の要件に関しては、アルテラは論理合成テクノロジの開発で長い歴史を持っています。アルテラは、内部モジュールと完全なデザイン・フローに数多くのテストを実行しています。また、アルテラは、proven in use claimをサポートするにあたって十分な使用データとマーケット・データを有しています。注意: 合成や配置配線ステージの結果を表示するには、Quartus II Netlist Viewerを使用します。
Netlist Viewerはツールの出力をグラフィカルに表示するため、ツールの出力を視覚的に確認することができます。
標準の Quartus IIフローにサードパーティ合成ツールを統合する方法については、Quartus IISoftware Handbook v14.1の以下のトピックを参照してください。• Volume 1： 設計と合成Netlist Viewerテクノロジの詳細については、Quartus II Software Handbook v14.1の以下のトピックを参照してください。• Volume 1： 設計と合成• 第 19章：Quartus II Netlist Viewerを使用したデザインの解析
MNL-10792015.07.14 Proven in Use（使用実績のある）合成の適用 5-19
ISO26262に特化した FPGAデザイン用のテクニックと方法 Altera Corporation
フィードバック
Proven in Use（使用実績のある）ライブラリ/CPLDテクノロジの適用
表 5-28: 合成：Proven in Use（使用実績のある）ライブラリ/CPLDテクノロジの適用
ソース 参照先
ISO26262-10:2012: Table A.8 なし
ISO26262-5:2011 なし
コンプライアンス・タイプ Procedural: tool specification
推奨ツール Quartus IIの統合合成
Quartus IIソフトウェアには、アルテラ CPLDベースと FPGAベースのプロダクトの両方のコンパイルに必要な合成ライブラリがすべて含まれています。このようなアルテラ・プロダクトをターゲットとするデザインのコンパイルには、必ず Quartus IIソフトウェアを使用してください。アルテラは、Quartus IIソフトウェア proven-in-useのエビデンスとして使用可能なテスト・データおよび使用データを十分に有しています。
スクリプト・ベースの手順
表 5-29: 合成：スクリプト・ベースの手順
ソース 参照先
ISO26262-10:2012: Table A.8 Ref 15: Script based procedures
ISO26262-5:2011 Section 7.4.1.6
コンプライアンス・タイプ Technical: tool use
推奨ツール Quartus II Tclスクリプティング・フロー
Quartus IIソフトウェアは、Tcl（ツール制御言語）スクリプトを幅広くサポートしています。アルテラはコンパイル・プロセスのそれぞれの部分でスクリプト制御を提供しています。堅牢で繰り返し実行が可能なコンパイルが可能であるため、スクリプト化されたフローを使用してください。以下に挙げる特有の適用性があります• Quartus IIプロジェクトの管理• 制約の定義（タイミングおよびデバイス・レベル）• コンパイル・フローの実行• タイミング解析
5-20 Proven in Use（使用実績のある）ライブラリ/CPLDテクノロジの適用MNL-1079
2015.07.14
Altera Corporation ISO26262に特化した FPGAデザイン用のテクニックと方法
フィードバック
• レポートの生成と解析• テストの実行• テストの出力の解析とレポートさらに、Quartus IIソフトウェアは Tclコマンド実行のためのインタラクティブ・モードをサポートします。Altera FPGAデザイン・フローの一部としての Tclスクリプティングについての情報は、QuartusII Software Handbook v14.1の以下のトピックを参照してください。• Volume 2：デザインの実装と最適化• 第 3章：Tclスクリプト
適切なタイミング・マージン
表 5-30: 合成：適切なタイミング・マージン
ソース 参照先
ISO26262-10:2012: Table A.8 Ref 16: Adequate time margin for processtechnologies in use for less than 3 years
ISO26262-5:2011 Section 7.4.2.4
コンプライアンス・タイプ Technical: tool use
推奨ツール Quartus II TimeQuest
クロック不確実性の制約をデザインへ適用することで、この条項を満たさなければなりません。デザインへのクロック制約は project.sdcファイル内に存在します。• 最大のタイミングにマージンを適用するために、セットアップ不確実性の制約はサイクルの早い段階で効果的なクロック・ラッチ・エッジをもたらします。
• 最小のタイミングにマージンを適用するために、ホールド不確実性の制約はサイクルの遅い段階で効果的なクロック・ラッチ・エッジをもたらします。
どちらの制約も効果的なデータ有効ウィンドウ（Effective data valid window）を減少させる、必要とされる追加のマージンを提供します。
MNL-10792015.07.14 適切なタイミング・マージン 5-21
ISO26262に特化した FPGAデザイン用のテクニックと方法 Altera Corporation
フィードバック
図 5-1: データ有効ウィンドウでのクロック不確実性の効果
D a ta
Hold uncertainty100 ps
Setup uncertainty(>20% of clock cycle)
Clock
Effective data valid window
Nominal/Perfect clock edge Effective clock edge
クロック不確実性制約の適用1. セットアップ・タイミングには、クロックのセットアップ・タイムに対し 20%のクロック不確実性の制約を適用します。set_clock_uncertainty –to {<user clock>} –setup
<uncertainty>
2. ホールド・タイミングには、ホールド・タイミングはクロックの周波数に依存していないため、クロック周期の 20%の追加は適用されません。安全性を確保するには、100 psのホールド・タイムを追加します。
3. ベース・クロックには以下の設定を適用します。set_clock_uncertainty –to {<user clock>} –hold <original hold uncertainty + 0.1>
4. 派生 PLLクロックには以下の設定を適用します。set_clock_uncertainty –to {<user clock>} –hold 0.1 -add
例：• Clock name = pllclk[1]• Frequency = 100 MHz• Period = 10 ns• Setup uncertainty = 10 nsの 20% = 2 ns• Hold uncertainty = 100 ps = 0.1 ns• set_clock_uncertainty -to { u_alt_pll|altpll_component|pll|clk[1] } - setup 2
• set_clock_uncertainty -to { u_alt_pll|altpll_component|pll|clk[1] } - hold 0.1
5. デザインにスラックの追加が必要であるかを判断します。a. 選択したデバイスのプロセス・テクノロジを把握します。対象のデバイス・ファミリがリリースされた日付は、アルテラがこのテクノロジ・ノードの最初のサンプルを受け取った日付を反映しています。
b. このプロセスが生産段階で最初に使用された日付を検索します。c. 検索した日付から数えて、使用する認定が 3年以内のものであるかを確認し、使用するプロセス・テクノロジに対し、追加のスラック（>20%）を適用するかどうかを決定します。
5-22 クロック不確実性制約の適用MNL-1079
2015.07.14
Altera Corporation ISO26262に特化した FPGAデザイン用のテクニックと方法
フィードバック
タイミング解析およびクロック不確実性の適用に関する詳細情報については、Quartus IISoftware Handbook v14.1の以下のトピックを参照してください。• Volume 3：検証
関連情報5-23ページの アルテラ・デバイス・ファミリのリリース年度表
アルテラ・デバイス・ファミリのリリース年度表
表 5-31: Cycloneファミリのリリース
デバイス・ファミリ リリース年度 プロセス・テクノロジ（nm）
Cyclone VE 2012（3月） 28LP
Cyclone V SX 2012（12月） 28LP
表 5-32: 最初に使用されたプロセス
プロセス・テクノロジ（nm） 最初に使用された年度
28HP/LP 2011（4月）
テストの挿入とテスト・パターンの生成
テスト容易化設計（DFT）
表 5-33: テストの挿入：DFT
ソース 参照先
ISO26262-10:2012: Table A.8 Ref 17: Design for testability（depending on the testcoverage in percent）
ISO26262-5:2011 Section 7.4.1.6
Compliance Type Procedural: coding style
Suggested Tool なし
テストできないストラクチャおよび完全でないテスト・ストラクチャを低減させる方法をデザイン内に採用すべきです。
MNL-10792015.07.14 アルテラ・デバイス・ファミリのリリース年度表 5-23
ISO26262に特化した FPGAデザイン用のテクニックと方法 Altera Corporation
フィードバック
Quartus IIソフトウェアは、テストすることが困難な特定のストラクチャを含むデザインの解析に役立ちます。例えば、Quartus IIソフトウェアはデザイン・ファイルのラッチ推測に警告を示します。詳細については、Quartus II Software Handbook v14.1の以下のトピックを参照してください。• Volume 1: 設計と合成• 第 14章：推奨 HDLコーディング・スタイル
配置、配線、レイアウトの生成ISO26262-10:2012表 A.8の 3つ目のセクションには、配置、配線、レイアウトの手順について記載されています。これらのトピックでは、表 A.8の各項目を満たす際に、アルテラのツールやプロセスを適用可能であるかどうかについて記述しています。アルテラは、FPGAの開発段階でこれらの項目の多くを実行しており、これらのプロダクトのユーザーとは低い関連性を持ちます。
使用実績のある適用されたハード・コアの正当性
表 5-34: 使用実績のある適用されたハード・コアの正当性
ソース 参照先
ISO26262-10:2012: Table A.8 なし
ISO26262-5:2011 なし
コンプライアンス・タイプ Procedural: data collection
推奨ツール なし
アルテラは広範囲に及ぶ検証とテストの後でのみ FPGA製品を製造工程へとリリースします。アルテラはまた、市場で期間や販売台数の結果として生産に関する広範な経験を持っています。
検証済みのハード・コアの適用
表 5-35: 検証済みのハード・コアの適用
ソース 参照先
ISO26262-10:2012: Table A.8 なし
ISO26262-5:2011 なし
コンプライアンス・タイプ Procedural: core specification
推奨ツール なし
5-24 配置、配線、レイアウトの生成MNL-1079
2015.07.14
Altera Corporation ISO26262に特化した FPGAデザイン用のテクニックと方法
フィードバック
アルテラは広範囲に及ぶ検証とテストの後でのみ FPGA製品を製造工程へとリリースします。アルテラはまた、市場で期間や販売台数の結果として生産に関する広範な経験を持っています。
レイアウト後のゲート・ネットリスト・シミュレーション
表 5-36: レイアウト後のゲート・ネットリスト・シミュレーション
ソース 参照先
ISO26262-10:2012: Table A.8 Ref 21: Simulation of the gate netlist after layout, tocheck timing constraints, or static analysis of thepropagation delay（STA）
ISO26262-5:2011 Section 7.4.4
Compliance Type Technical: tool use
Suggested Tool サードパーティー製シミュレータによってサポートされます
表 5-37: 伝播遅延の STA
ソース 参照先
ISO26262-10:2012: Table A.8 Ref 21: Simulation of the gate netlist after layout, tocheck timing constraints, or STA of the propagationdelay
ISO26262-5:2011 Section 7.4.4
Compliance Type Technical: tool use
Suggested Tool Quartus II TimeQuest
Quartus IIソフトウェアは、TimeQuest Timing Analyzerを搭載しており、このツールは、STAを実行します。この包括的なツールは、タイミング制約と適切な回路の遅延モデルを使用して完全なチップ・デザインを解析します。ハードウェアに実装されるタイミング制約は、回路の正しい動作に重要な役割を持ちます。アルテラは回路遅延のモデルを提供しており、これらは QuartusIIソフトウェアの特定のインストールに含まれています。一部のデザイン・フローとサインオフは、TimeQuestレポート・ファイルが「timing clean」なデザイン（制約に違反がないデザイン）であることを確実にします。TimeQuestツールの詳細な解説は本資料には含まれません。TimeQuest Timing Analyzerの詳細については、Quartus II Software Handbook v14.1の以下のトピックを参照してください。• Volume 3：検証
MNL-10792015.07.14 レイアウト後のゲート・ネットリスト・シミュレーション 5-25
ISO26262に特化した FPGAデザイン用のテクニックと方法 Altera Corporation
フィードバック
パワー・ネットワークの解析
表 5-38: パワー・ネットワークの解析
ソース 参照先
ISO26262-10:2012: Table A.8 Ref 22: Analysis of power network
ISO26262-5:2011 Section 7.4.4
Compliance Type Technical: tool use
Suggested Tool Quartus II PowerPlayパワー・アナライザ
Quartus IIの PowerPlayパワー・アナライザは、初期のデザイン・コンセプトの初期からデザインの実装段階までの消費電力の見積もりを可能とします。
リファレンス・モデルとレイアウト後のゲート・ネットリストの比較
表 5-39: リファレンス・モデルとレイアウト後のゲート・ネットリストの比較
ソース 参照先
ISO26262-10:2012: Table A.8 Ref 23: Comparison of the gate netlist after layoutwith the reference model（formal equivalencecheck）
ISO26262-5:2011 Section 7.4.4
Compliance Type Technical: tool use
Suggested Tool サードパーティー製フォーマル等価性検証ツール
デザイン・ルール・チェック
表 5-40: デザイン・ルール・チェック
ソース 参照先
ISO26262-10:2012: Table A.8 Ref 24: Design rule check（DRC）
ISO26262-5:2011 Section 7.4.4
Compliance Type Procedural
5-26 パワー・ネットワークの解析MNL-1079
2015.07.14
Altera Corporation ISO26262に特化した FPGAデザイン用のテクニックと方法
フィードバック
ソース 参照先
Suggested Tool なし
この項目では、アルテラが FPGAデザインに実行するデザイン・ルール・チェッキングについて記載しています。この項目に対するユーザーによる操作は不要です。uired for this item.
Layout Versus Schematic（LVS）チェック
表 5-41: CRCチェック
ソース 参照先
ISO26262-10:2012: Table A.8 Ref 25: LVS check
ISO26262-5:2011 Section 7.4.4
Compliance Type Procedural
Suggested Tool Quartus II
FPGAのエレメント間に存在する接続はすべてアルテラによるルーティングおよびチェックが実行済です。コンフィギュレーションだけがデータの実際のパスを決定します。アルテラは LVDSチェックをサポートしていません。Quartus IIソフトウェアの Chip Plannerは、チップ上の異なるエレメント間の接続を視覚化することが可能であるため、正確であることを手動で分析することができます。このツールには、デザイン内のパスの探索など、様々なタスクに向けてのコンフィギュレーション・オプションが含まれています。Chip Plannerの詳細については、Quartus II Software Handbook v14.1の以下のトピックを参照してください。• Volume 2：デザインの実装と最適化• 第 15章：Chip Plannerを使用したデザイン・フロアプランの解析および最適化
チップ生産段階の安全性に関連する特殊な特性ISO26262-10:2012表 A.8の次のセクションには、生産アイテムについて記載されています。アルテラは、FPGAの生産段階でこれらの項目の多くを実行しており、これらのプロダクトのユーザーとは低い関連性を持ちます。以下のトピックでは、アルテラの生産プロセスについて紹介します。
MNL-10792015.07.14 Layout Versus Schematic（LVS）チェック 5-27
ISO26262に特化した FPGAデザイン用のテクニックと方法 Altera Corporation
フィードバック
Proven in Use（使用実績のある）プロセス・テクノロジの適用
表 5-42: 製造：Proven in Use（使用実績のある）プロセス・テクノロジの適用
ソース 参照先
ISO26262-10:2012: Table A.8 なし
ISO26262-5:2011 なし
Compliance Type Procedural: device selection specification
Suggested Tool なし
アルテラは広範囲に及ぶ検証とテストの後でのみ FPGA製品を製造工程へとリリースします。アルテラはまた、市場で期間や販売台数の結果として製造に関する広範な経験を持っています。また、アルテラは同様に広範な顧客ベースを持つ TSMCへ製造を委託しています。
Proven in Use（使用実績のある）デバイス・シリーズ
表 5-43: 製造：Proven in Use（使用実績のある）デバイス・シリーズ
ソース 参照先
ISO26262-10:2012: Table A.8 なし
ISO26262-5:2011 なし
Compliance Type Procedural: selection of appropriate design team
Suggested Tool なし
この実行には、FPGAユーザのアプリケーションに関する十分な経験を必要とします。セーフティ・プロジェクト・チームを編成する際は、この手続き型手法を考慮してください。
使用実績のある製造工程の適用
表 5-44: 製造：使用実績のある製造工程の適用
ソース 参照先
ISO26262-10:2012: Table A.8 なし
ISO26262-5:2011 なし
5-28 Proven in Use（使用実績のある）プロセス・テクノロジの適用MNL-1079
2015.07.14
Altera Corporation ISO26262に特化した FPGAデザイン用のテクニックと方法
フィードバック
ソース 参照先
Compliance Type Procedural: device selection specification
Suggested Tool なし
アルテラは広範囲に及ぶ検証とテストの後でのみ FPGA製品を製造工程へとリリースします。アルテラはまた、市場で期間や販売台数の結果として生産に関する広範な経験を持っています。また、アルテラは同様に広範な顧客ベースを持つ TSMCへ生産を委託しています。
製造工程における品質管理
表 5-45: 生産： 製造工程における品質管理
ソース 参照先
ISO26262-10:2012: Table A.8 なし
ISO26262-5:2011 なし
Compliance Type Procedural: device selection specification
Suggested Tool なし
アルテラは、ISO 9001:2008規格を満たす品質システムを有しており、 アイルランド規格協会（NSAI）による定期的な監査を受けています。この認証のコピーについては、アルテラのウェブサイトを参照してください。品質の証明書の他にも、アルテラは当社のサプライヤーが業界で認知されている規格に適合していることを確認しています。アルテラは、当社の主要サプライヤーの品質プロセスとパフォーマンスの年次評価を行っています。アルテラは、アルテラの最終製品がこの品質を継続的に維持していることを確認するために定期的（毎週または毎月）に検討会を開催しています。アルテラは、コンピュータ化された是正措置システムにてこの評価結果と進行中のアイテムを記録します。アルテラ社員は通常、ウェハーおよびパッケージング下請け業者の現場におり、また TSMCおよび Amkor Technology社の社員も週労働時間中に複数回アルテラに来社します。アルテラが提携するシリコン・プロバイダ（TSMC）は、以下の規格の認証を取得しています。• ISO 9001:2008• ISO 14001:2004• ISO/TS 16949:2009
アルテラが提携するパッケージング・サプライヤ（AMKOR Technology）は以下に挙げる品質認証を取得しています。• ISO 9001:2008• ISO 14001:2004• ISO/TS 16949:2009
MNL-10792015.07.14 製造工程における品質管理 5-29
ISO26262に特化した FPGAデザイン用のテクニックと方法 Altera Corporation
フィードバック
アルテラが提携するパッケージング・サプライヤ（ASE Group）は以下に挙げる品質認証を取得しています。• ISO 9001:2008• ISO 14001:2004• ISO/TS 16949:2009• IECQ QC 080000:2005
関連情報• Altera reliability certificate• TSMC quality and reliability web page• Amkor Technology quality management web page• ASE Group quality policy web page
システム内の FPGAプロトタイプの最終的な確認および検証
表 5-46: 生産： 製造工程における品質管理
ソース 参照先
ISO26262-10:2012: Table A.8 なし
ISO26262-5:2011 なし
Compliance Type Procedural: Running of hardware validation
Suggested Tool なし
このユーザーによる手続き型手法に対して、アルテラが推奨するツールもしくはプロセスはありません。
最終的な検査と検証
表 5-47: 生産： 製造工程における品質管理
ソース 参照先
ISO26262-10:2012: Table A.8 なし
ISO26262-5:2011 なし
コンプライアンス・タイプ Procedural
推奨ツール なし
このユーザーによる手続き型手法に対して、アルテラが推奨するツールもしくはプロセスはありません。
5-30 システム内の FPGAプロトタイプの最終的な確認および検証MNL-1079
2015.07.14
Altera Corporation ISO26262に特化した FPGAデザイン用のテクニックと方法
フィードバック
アルテラ・ツールおよびソフトウェアの既知の問題 6
2015.07.14
MNL-1079 更新情報 フィードバック
Quartus IIソフトウェア、IPコア、および Nios IIソフトウェア・ビルド・ツールに関する既知の問題については、アルテラ・ナレッジベースのページを参照してください。Quartus IIソフトウェアに関する既知の問題については、http://www.altera.com/support/kdb/kdb-search.jspを参照してください。IPコア、および Nios IIソフトウェア・ビルド・ツールに関する既知の問題については、http://www.altera.com/support/kdb/kdb-search.jspを参照してください。
関連情報Altera Knowledge Base
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks ofIntel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to currentspecifications 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 expresslyagreed to in writing by Intel. Intel customers are advised to obtain the latest version of device specifications before relying on any published informationand before placing orders for products or services.*Other names and brands may be claimed as the property of others.
ISO9001:2008登録済
www.altera.com101 Innovation Drive, San Jose, CA 95134
Development Interface Agreement（開発協働契約書） 7
2015.07.14
MNL-1079 更新情報 フィードバック
Development Interface Agreementには、アイテムおよびエレメントの配布された開発に対するカスタマーおよびサプライヤの責任と行動が記載されています。Cyclone VデバイスおよびCyclone Vのアプリケーションの開発に使用されるツールは、Safety Element out of Context（SEooC）として開発され、特定のユース・ケースに向けたものではありません。このトピックでは、商用オフザシェルフ（COTS）製品を使用する際に、アルテラが提供する成果物について説明します。
安全管理者Altera Automtoive Safety Manualに記載されたツールは、その基本的な形を変えず長年にわたって存在しており、新しい機能や修正によってのみ定期的に更新されます。このようなツールは以前から IEC61508:2010で評価されており、今後は ISO26262:2011-2012による評価が計画されています。ツールの開発に特化して選定された安全管理者は存在しません。IEC61508:2010の評価で示されているように、決定論的原因フォールトの回避に向けて適切なプロシージャが用意されています。これらの処理方法への順守は、部門責任者と品質組織によって管理されます。Cyclone Vデバイスは、 ISO26262規格が 2011年 11月に公開される前に開発が開始されました。ツール開発に関しては、アルテラの FPGA製品が安全性を重視するアプリケーションでの使用に適合していることが IEC61508の評価により示されています。Cyclone Vデバイスの製品開発中に安全管理者は選任されていません。決定論的原因フォールトの回避とは、アルテラの標準的な開発プロセスの一部であり、それぞれの部門責任者は定義された処理方法の順守に関して責任を負います。アルテラは、製造および残りの製品ライフサイクルの公開について安全管理者を選任しています。Cyclone Vおよび専用ツールを使用する予定がある新規カスタマーの開発であれば、アルテラはアプリケーション開発段階でカスタマーの安全管理者と協働して開発を行う安全管理者をアルテラから選任することができます。
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks ofIntel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to currentspecifications 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 expresslyagreed to in writing by Intel. Intel customers are advised to obtain the latest version of device specifications before relying on any published informationand before placing orders for products or services.*Other names and brands may be claimed as the property of others.
ISO9001:2008登録済
www.altera.com101 Innovation Drive, San Jose, CA 95134
安全性ライフサイクルアルテラ製品は、SEooCとして開発されています。開発に使用されるプロセスは、IEC61508:2010に準拠しています。アルテラは要件や機能を確立する目的で、安全性を重視する特定のアプリケーションに数年にわたって製品を出荷することで得られた経験から、製品の意図される使用方法を理解しています。アルテラは、業界の数社のカスタマーと共にこうした前提を確立しました。アルテラは、FMEDAで提示されている質的な失敗の分析を実行しています。信頼性の予測は、アルテラの内部評価と業界標準のモデルの両方を使用して作成されています。
アルテラが行う活動およびお客様の責任このトピックでは、アルテラが安全性ライフサイクルで実行する活動、アルテラがカスタマーに提供可能なサポート、およびアルテラがカスタマーによって実行されることが期待される活動を定義します。
表 7-1: 安全性ライフサイクル活動の責任の定義
安全性ライフサイクル活動 アルテラ 顧客側の作業
機能安全のマネジメント あり あり
アイテムの定義 なし あり
危害分析およびリスク分析 なし あり
機能安全コンセプト SEooC あり
システム・レベルでの製品開発
なし あり
技術的な安全要件の仕様 SEooC あり
アイテムの設計 なし あり
HPSのハードウェア要件の仕様
あり なし
FPGAのハードウェア要件の仕様
なし あり
HPSハードウェア設計 あり なし
FPGAハードウェア設計 サポート提供 あり
7-2 安全性ライフサイクルMNL-1079
2015.07.14
Altera Corporation Development Interface Agreement（開発協働契約書）
フィードバック
安全性ライフサイクル活動 アルテラ 顧客側の作業
HPSハードウェア設計の検証 あり なし
FPGAハードウェア設計の検証
なし あり
HPSアーキテクチャ・メトリクスの評価
サポート提供 あり
FPGAアーキテクチャ・メトリクスの評価
サポート提供 あり
安全目標違反の評価 なし あり
ソフトウェア開発 サポート提供 あり
アイテムの統合とテスト なし あり
安全性評価 サポート提供 あり
生産の開始 サポート提供 あり
生産、保守、廃棄 サポート提供 あり
使用されるソフトウェア・ツールの認証
サポート提供 あり
アルテラが提供する情報次の表は、カスタマーが行う安全性の開発に向けてアルテラが提供する情報を示しています。
表 7-2: アルテラが提供する情報
アルテラの情報 利用の可否
安全マニュアル（本書） 公開情報
FMEDAの要約 公開情報
FMEDAの詳細情報 NDA：要購入
評価認証 NDA：要購入
MNL-10792015.07.14 アルテラが提供する情報 7-3
Development Interface Agreement（開発協働契約書） Altera Corporation
フィードバック
活動の責任当事者アルテラは、アルテラが行う活動およびお客様の責任で定義された活動を実行するために、アイテム開発中に顧客と緊密に連携することができます。責任当事者と交流は、カスタマーと定義することが可能です。
目標値についての情報交換アルテラは、FMEDAの定量的安全解析の値を提供します。カスタマーは、独自のコンポーネントの統合に基づいて、これらの目標値を調整することができます。アルテラは、カスタマーに対してアイテム・レベルのハードウェア・アーキテクチャ・メトリクスを達成するためのストラテジーに関するサポートを提供することができます。
サポートのプロセスとツールアルテラは以下のツールをカスタマーに提供します。
表 7-3: プロセスとツール 出力形式
プロセスとツール 出力形式
安全マニュアル PDF
FMEDAの要約 PDF
FMEDAの詳細情報 Microsoft Excel
Quartus IIソフトウェア 各種
7-4 活動の責任当事者MNL-1079
2015.07.14
Altera Corporation Development Interface Agreement（開発協働契約書）
フィードバック
Nios IIプロセッサを使用したソフトウェア開発 8
2015.07.14
MNL-1079 更新情報 フィードバック
以下のトピックでは、安全アプリケーションに向けて Nios IIプロセッサを使用してソフトウェアを開発するにあたって必要な手順の概要を紹介します。安全ソフトウェア開発のための完全な要件については、ISO26262-6:2011を参照してください。
Qsysを使用した Nios IIシステムの作成この段階では、カスタマーのシステム・デザインで必要となるコンポーネントに Nios IIプロセッサを接続することで、Nios IIプロセッサ・システムを作成します。この段階では Qsyｓを使用して、ポーネント間に接続を作成し、コンポーネント・ベース・アドレスを設定します。システムの作成が成功すると、Qsyｓは.sopcinfoファイルで Nios IIシステムの記述を提供します。このタスクは、ハードウェア・デザインのロジック・モジュール統合ステップの一部として実行します。このタスクは、詳細なモジュール要求の仕様を持つ FPGAアーキテクチャの記述からの情報を使用しています。推奨ツール：• Qsys
Qsysで Nios IIシステム作成の完全な記述方法については、Quartus II Software Handbook v14.1の以下のトピックを参照してください。• Volume 1： 設計と合成• 第 7章：Qsysを使用したシステムの作成
Nios IIシステム用のボート・サポート・パッケージの作成このステップでは、Nios IIシステム用にボード・サポート・パッケージ（BSP）を作成します。BSPには、Nios IIシステム内のハードウェア・コンポーネントに関する情報が含まれています。また、ソフトウェア・プログラマが Nios IIシステムのハードウェア・コンポーネントにアクセスすることが可能となります。BSPには、Nios IIシステムが必要とする HALコンポーネント、ソフトウェア・ドライバ、システム・ヘッダ・ファイルが含まれています。さらに、このステップでは正しい依存関係を持つmakefileが作成されます。この makefileにより、必要に応じて、BSPを再度構築することが可能となります。
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks ofIntel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to currentspecifications 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 expresslyagreed to in writing by Intel. Intel customers are advised to obtain the latest version of device specifications before relying on any published informationand before placing orders for products or services.*Other names and brands may be claimed as the property of others.
ISO9001:2008登録済
www.altera.com101 Innovation Drive, San Jose, CA 95134
アルテラが提供するライブラリから Nios IIシステムに含めるコンポーネント用のソフトウェア・ドライバを選択します。別の安全性に関する認証が必要となるため、ドライバの変更、もしくは他のドライバの使用は避けてください。推奨ツール：• Nios IIソフトウェア・ビルド・ツール GUI• Nios IIソフトウェア・ビルド・ツール BSPウィザード• Nios IIソフトウェア・ビルド・ツール・ビルド・スクリプト検証手順• 生成された system.hファイルが正しいベース・アドレスを持っていることを確認します。
• Qsys GUIでクロス・チェックするか、あるいは.sopcinfoファイルを設計します。• 生成された system.hファイルがすべてのコンポーネントに対してヘッダ・コードを持っていることを確認します。• Qsys GUIでクロス・チェックするか、あるいは.sopcinfoファイルを設計します。• コンポーネントのドキュメント（Qsyｓコンポーネント GUI内の記述）を参照して、コンポーネント設定は正しいことを確認します。
• 生成された alt_sys_init.cファイルを確認します。ファイルに誤りがないことを確認するために手動で検査を行います（このファイル内の設定が持つ影響については、Nios II関連資料を参照して下さい）。
BSP作成の詳細については、Nios II Classic Software Developer's Handbook 2015.05.14の以下のトピックを参照してください。• 第 2章：グラフィカル・ユーザー・インタフェースのガイドライン• 第 4章：Nios IIソフトウェア・ビルド・ツール
アプリケーション・フレームワークの作成このステップでは、前のステップで作成した BSPに接続するソフトウェア・アプリケーション・フレームワークを作成します。このフレームワークには、ターゲットとする Nios IIシステムに向けたソフトウェアのビルドに必要なすべてのソースへのリファレンスを含む makefileの例およびアプリケーション・コードが最終的に含まれます。アプリケーション・テンプレートを選択する場合は、不要なコードまたは識別できないコード（例：オペレーティング・システム）を含むテンプレートは選択しないでください。アプリケーションに対しては、空白のテンプレートを選択します。推奨ツール：• Nios IIソフトウェア・ビルド・ツール GUI• Nios IIソフトウェア・ビルド・ツール・ビルド・スクリプト検証手順• 生成された makefileを確認します。
• makefileに必要なソースがすべて含まれていることを手動で検査します。• BSPエディタ GUIを使用して、アプリケーションに含まれているソースとライブラリを確認します。
8-2 アプリケーション・フレームワークの作成MNL-1079
2015.07.14
Altera Corporation Nios IIプロセッサを使用したソフトウェア開発
フィードバック
詳細については、Nios II Classic Software Developers Handbook 2015.05.14を参照してください。• 第 1章：Nios II Embedded Developmentの概要• 第 2章：グラフィカル・ユーザー・インタフェースのガイドライン
アプリケーション・ソフトウェアの開発このステップでは、安全アプリケーションのコードを開発します。このコードは、Nios II SBTEclipse環境で実装可能で、ビルトイン・エディタといったアイテムを使用することができます。推奨ツール• Nios IIソフトウェア・ビルド・ツール GUI：Integrated editor
詳細については、Nios II Classic Software Developers Handbook 2015.05.14を参照してください。• 第 1章：Nios II Embedded Developmentの概要• 第 2章：グラフィカル・ユーザー・インタフェースのガイドライン
ソフトウェアとハードウェアの統合Nios Iiソフトウェア・ビルド・ツール環境を使用すれば、ターゲット・デバイスで動作するソフトウェアをデバッグすることができます。これにより、code breakpoint、step into function、stepover functionの設定が可能となります。これとは別に、ハードウェアのロード可能なプログラミング・ファイルの作成も可能であり、デバッガを接続しなくてもソフトウェアの検証が可能です。推奨ツール：• Nios IIソフトウェア・ビルド・ツール GUI：Integrated editor
詳細については、Nios II Classic Software Developer's Handbook 2015.05.14を参照してください。• 第 2章：グラフィカル・ユーザー・インタフェースのガイドライン
ISO26262規格に含まれるツールとライブラリ
表 8-1: ISO26262規格に含まれるツールとライブラリ次の表は、ISO26262:2011-2012規格の一部としてアルテラが認定しているツールおよびライブラリを示しています。ツール名 説明 ツール・タイプ コード・ベース
BSP Wizard GUIベース。Qsys .sopcinfoファイルより BSPを作成。
TCL3 アルテラ
BSP Editor GUIベース。BSP設定を調整。
TCL3 アルテラ
MNL-10792015.07.14 アプリケーション・ソフトウェアの開発 8-3
Nios IIプロセッサを使用したソフトウェア開発 Altera Corporation
フィードバック
ツール名 説明 ツール・タイプ コード・ベース
Nios II SW drivers Qsysコンポーネント用のソフトウェア・ドライバのライブラリ。
ライブラリ アルテラ
Nios II HAL Nios IIプロセッサのハードウェア・アブストラクション・レイヤ（HAL）。
ライブラリ アルテラ
Conversion Utilities 最終出力をフラッシュ・プログラミング・ファイルに変換。 例：.hex形式など
TCL3 アルテラ
Build Scripts コマンド・ライン。Qsys .sopcinfoファイルより BSPを作成。
TCL3 アルテラ
Debug Utilities システム・デバッグを支援。例：Nios2 terminal、gdb serverなど
TCL2 アルテラ
ISO26262:2011-2012規格には、ハードウェア、ソフトウェア・デバイス・ドライバ、HAL APIレイヤのみが含まれます。Nios II Classic Software Developer's Handbook 2015.05.14の図 7-1、LayeredSoftware Modelを参照してください。ISO26262:2011-2012規格にはこれ以外のレイヤは含まれません。使用に関する特定の制限については、第 7章：Developing Device Drivers for the HardwareAbstraction Layerを参照してください。
ISO26262規格に含まれないサードパーティー製ツールとライブラリNios IIソフトウェア・ビルド・ツールは、以下のサードパーティー製ツールに依存していますが、これらはアルテラの認定対象外です。製品の認証の一部としてこれらのツール（および特定のバージョン）に関する適合性のエビデンスを提供する必要があります。
表 8-2: ISO26262規格に含まれないツール
ツール名 ツール・タイプ コード・ベース
Eclipse Environment TCL2 / TCL1 Eclipse
GNU Make TCL3 GNU
GNU Compiler TCL3 GNU
8-4 ISO26262規格に含まれないサードパーティー製ツールとライブラリMNL-1079
2015.07.14
Altera Corporation Nios IIプロセッサを使用したソフトウェア開発
フィードバック
ツール名 ツール・タイプ コード・ベース
GNU Linker TCL3 GNU
GNU Binutils TCL2 GNU
Assembler TCL3 GNU
デバッガ TCL2 GNU
Newlib ライブラリ GNU
MNL-10792015.07.14 ISO26262規格に含まれないサードパーティー製ツールとライブラリ 8-5
Nios IIプロセッサを使用したソフトウェア開発 Altera Corporation
フィードバック
サポートされる（V）HDLのバージョン 92013.11.19
MNL-1079 更新情報 フィードバック
アルテラのツールは、（V）HDLの以下のバージョンをサポートしています。• VHDL 1987• VHDL 1993• VHDL 2008（IEEE Standard 1076-2008）• Verilog HDL 1995• Verilog HDL 2001• SystemVerilog HDL 2005（合成サブセットのみ）
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks ofIntel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to currentspecifications 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 expresslyagreed to in writing by Intel. Intel customers are advised to obtain the latest version of device specifications before relying on any published informationand before placing orders for products or services.*Other names and brands may be claimed as the property of others.
ISO9001:2008登録済
www.altera.com101 Innovation Drive, San Jose, CA 95134
改訂履歴102015.07.14
MNL-1079 更新情報 フィードバック
表 10-1: 改訂履歴
日付 内容2015.06.30 • Cyclone V FPGAの情報を追加
• Quartus IIソフトウェア v14.1のための更新• 古いデバイスを削除• 新しくサポートされるデバイスを追加
20.13.11.01 初版
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks ofIntel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to currentspecifications 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 expresslyagreed to in writing by Intel. Intel customers are advised to obtain the latest version of device specifications before relying on any published informationand before placing orders for products or services.*Other names and brands may be claimed as the property of others.
ISO9001:2008登録済
www.altera.com101 Innovation Drive, San Jose, CA 95134