ultrascale architecture soft error mitigation …ultrascale architecture sem controller v3.1 6 pg187...

UltraScale Architecture Soft Error Mitigation Controller v3.1LogiCORE IP 製品ガイド

Vivado Design Suite

PG187 2019 年 5 月 22 日

この資料は表記のバージョンの英語版を翻訳したもので、内容に相違が生じる場合には原文を優先します。資料によっては英語版の更新に対応していないものがあります。日本語版は参考用としてご使用の上、最新情報につきましては、必ず最新英語版をご参照ください。

UltraScale Architecture SEM Controller v3.1 2

PG187 2019 年 5 月 22 日 japan.xilinx.com

目次

IP の概要

第 1章: 概要メモリタイプ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

エラー軽減のアプローチ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

信頼性の推定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

機能概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

アプリケーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

SEM IP の導入に関する主な考慮事項. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

パーシャルリコンフィギュレーションのサポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

暗号化と認証のサポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

サポートされていない機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

ライセンスおよび注文情報 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

第 2章: 製品仕様機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

規格 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

パフォーマンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

リソース使用状況 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

ポートの説明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

第 3章: コアを使用するデザイン一般的なデザインガイドライン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

構造オプション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

インターフェイス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

システム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

コンフィギュレーションメモリのマスク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

リセット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

第 4章: デザインフローの手順コアのカスタマイズおよび生成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

コアへの制約 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

シミュレーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

合成およびインプリメンテーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

統合およびバリデーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

第 5章: サンプルデザイン機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

ポートの説明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

インプリメンテーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

外部メモリプログラミングファイル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

https://japan.xilinx.com

https://japan.xilinx.com/about/feedback/document-feedback.html?docType=Product_Guide&docId=PG187&Title=UltraScale%20Architecture%20Soft%20Error%20Mitigation%20Controller%20v3.1%20LogiCORE%20IP%20%26%2335069%3B%26%2321697%3B%26%2312460%3B%26%2312452%3B%26%2312489%3B%20%28PG187%29&releaseVersion=3.1&docPage=2



第 6章: テストベンチ

付録 A: 検証、互換性、相互運用性検証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

バリデーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

適合性検査 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

付録 B: アップグレードVivado Design Suite でのアップグレード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

付録 C: 評価ボードを使用した SEM Controller の動作デモビットストリームの生成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

ハードウェアとソフトウェアのセットアップ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

付録 D: UART ログの例初期化レポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

ステータスレポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

挿入コマンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

監視ステートへの移行コマンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

アイドルステートへの移行コマンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

検出ステートへの移行コマンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

ソフトウェアリセットコマンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

フレームアドレス変換コマンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Query コマンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

外部メモリ読み出し (Xmem) コマンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Peek コマンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

監視ステートのエラーレポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

検出ステートのエラーレポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

診断スキャン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

付録 E: エラー挿入のガイダンス

付録 F: IP デザインのチェックリスト

付録 G: SPI バスタイミングバジェットSPI バスクロックの波形およびタイミングバジェット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

SPI バス送信の波形およびタイミングバジェット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

SPI バス受信の波形およびタイミングバジェット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

SPI バスタイミングバジェットのまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

付録 H: モニターインターフェイスのシグナリングとプロトコルモノリシックおよび UltraScale+ SSI デバイス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

UltraScale SSI デバイス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

付録 I: フェッチインターフェイスのシグナリングとプロトコル

付録 J: デバッグザイリンクスウェブサイト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

デバッグツール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

ハードウェアデバッグ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

インターフェイスのデバッグ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162





その他のエラー挿入オプション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

クロッキング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

デバイスへの依存性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

デザインのプロパティおよび制約 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

付録 K: その他のリソースおよび法的通知ザイリンクスリソース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Documentation Navigator およびデザインハブ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

参考資料 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

改訂履歴 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

お読みください: 重要な法的通知 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173




PG187 2019 年 5 月 22 日 japan.xilinx.com Production 製品仕様

はじめにLogiCORE™ IP UltraScale™ Architecture Soft Error Mitigation (SEM) Controller (以下、 SEM Controller またはコントローラー ) は、ザイリンクス FPGA のコンフィギュレーションメモリで発生したソフトエラーを検出および訂正するための事前検証済みソリューションで、自動的に設定されます。ソフトエラーとは、ステートエレメントに格納した値が電離放射線によって変化してしまうことをいいます。

SEM Controller はソフトエラーを防ぐのではなく、ソフトエラーのシステムレベルでの影響をより適切に管理するための手段を提供します。これらイベントを適切に管理することで信頼性と可用性が向上し、システムメンテナンスとダウンタイムのコストを削減できます。

機能• KU040 において標準的な検出レイテンシは 13ms。

• FPGA 内蔵のエラー検出機能を完全に利用しつつさらに発展させたビルトインシリコンプリミティブを統合。

• 用途に応じた 6 つのモード

° 軽減 + テスト (Mitigation and Testing) モード

° 軽減 (Mitigation only) モード

° 検出 + テスト (Detect and Testing) モード

° 検出 (Detect only) モード

° エミュレーション (Emulation) モード

° モニター (Monitoring) モード

• 隣接フレームにまたがる複数ビットエラーを高速に訂正する ECC (エラー訂正符号) アルゴリズムベースのエラー訂正機能 (オプション)。

• ザイリンクスのエッセンシャルビットテクノロジを利用したオプションのエラー分類機能により、ソフトエラーがユーザーデザインの機能に影響したかどうかを判定。

° デザインの動作に影響しないエラーについては、動作を中断してリカバリを実行する必要がなくなるため、アップタイムが向上。

° 実効 FIT (Failures In Time) が改善。

• オプションのエラー挿入および便利なデバッグ機能により、 SEM Controller のアプリケーションの評価をサポート。

• ICAP (内部コンフィギュレーションアクセスポート ) プリミティブの共有を容易にする ICAP アービトレーションインターフェイス。

• コンフィギュレーションメモリを継続的にスキャンして、初に検出された ECC または CRC (巡回冗長検査) エラーを報告する機能 (訂正なし ) (検出スキャン)。

• コンフィギュレーションメモリに対して診断スキャンを実行し、フレームレベル ECC によって検出されたすべてのエラーを報告する機能 (診断スキャン)。

• SEM Controller の使用および統合を支援するための「IP デザインのチェックリスト」あり。

IP の概要

この LogiCORE IP について

コアの概要

サポートされる

デバイスファミリ (1)

UltraScale+™ (1)、 UltraScale


ユーザーインターフェイス

RS-232、 SPI

リソース表 2-12 ～表 2-13 を参照

コアに含まれるもの

デザインファイル暗号化された RTL (Register Transfer Level)

サンプルデザイン Verilog

テストベンチ N/A

制約ファイルザイリンクスデザイン制約ファイル (.xdc)

シミュレーションモデル

N/A


ソフトウェアドライバー

N/A

テスト済みデザインフロー (2)

デザイン入力 Vivado® Design Suite

シミュレーション N/A

合成 Vivado 合成

サポート

ザイリンクスサポートウェブページで提供

注記:1. サポートされているデバイスの一覧は、 AR 63609 を参照してく

ださい。

2. サポートされているツールのバージョンは、『Vivado Design Suite ユーザーガイド : リリースノート、インストールおよびラ

イセンス』を参照してください。

https://japan.xilinx.com/support

https://japan.xilinx.com/support/answers/63609.html

https://japan.xilinx.com/cgi-bin/docs/rdoc?t=vivado+release+notes







第 1章

概要ほとんどのシリコンデバイスは、電離放射線から望ましくない影響を受ける可能性があります。 1 回のイベントで生じる望ましくない影響を、シングルイベント効果 (SEE) と総称します。ほとんどの場合、このイベントによってシリコンデバイスが恒久的な損傷を受けることはありません。このように、デバイスに恒久的な損傷を与えない SEE をソフトエラーと呼びます。ただしソフトエラーによって信頼性が低下する可能性があります。

ザイリンクスのデバイスはソフトエラーの影響を受けにくいように設計されています。ただし、商業性などを考慮した現実的な制約の中でソフトエラーを完全になくすのは不可能であることもザイリンクスは認識しています。このため、ザイリンクスの多くのデバイスファミリはソフトエラーの検出/訂正機能を内蔵しています。

ソフトエラーは多くのアプリケーションで無視できます。特に高い信頼性が要求されるアプリケーションでは、UltraScale™ Architecture SEM Controller を使用することでこの要求を満たすことができます。

SEM コントローラーを使用した方がよいアプリケーションでは、付録 F の「IP デザインのチェックリスト」に記載されたガイダンスおよび考慮事項に従って SEM Controller を使用および統合してください。

メモリタイプ

ソフトエラーが発生すると、 1 ビットまたは複数ビットのメモリ内容が破損します。ソフトエラーがデバイスのコンフィギュレーションメモリで発生するとデザインの動作が影響を受け、デザインのメモリ素子で発生するとデザインのステートが影響を受けます。デバイスには、主に次の 4 種類のメモリがあります。

• コンフィギュレーションメモリ – このストレージ素子を使用して、デバイスに読み込まれるデザインの機能を設定します。これには、ファンクションブロックの動作および接続がそれぞれ含まれます。このメモリはデバイス全体に物理的に分散しており、デバイス内でもビット数の多いメモリです。ただし、デバイスに読み込まれるデザインの実際の動作に影響するエッセンシャルビットは全体のごく一部です。

• ブロックメモリ – デザインステートの格納に使用する大容量のストレージ素子です。名前が示すように、これらのビットは物理的なブロックにまとめられており、デバイス全体にいくつかのブロックが分散しています。ブロックメモリはデバイス内で 2 番目にビット数の多いメモリです。

• 分散メモリ – デザインステートの格納に使用する中容量のストレージ素子です。分散メモリは一部のコンフィギャラブルロジックブロック (CLB) に存在し、デバイス全体に分散しています。分散メモリはデバイス内で 3 番目にビット数の多いメモリです。

• フリップフロップ – デザインステートの格納に使用する小容量のストレージ素子です。このメモリはすべての CLB に存在し、デバイス全体に分散しています。フリップフロップはデバイス内で 4 番目にビット数の多いメモリです。

これ以外のメモリとして、内部デバイス制御レジスタおよびステートエレメントがありますが、これらのビット数はごくわずかです。これらのメモリ領域でソフトエラーが発生すると、局所的またはデバイス全体に障害が起こることがあり、これをシングルイベントファンクショナルインタラプト (SEFI) と呼びます。これらのメモリはビット数が少ないため、ここでは SEFI イベントの発生確率は無視できるものと見なします。また、ほとんど発生することのないこれらのイベントには SEM Controller は対処しません。





第 1 章:概要

エラー軽減のアプローチ

ブロックメモリ、分散メモリ、フリップフロップに格納したデザインステートに対するソフトエラーは、エラー検出/訂正コードや冗長性などの標準的な手法を用いてデザイン自体で軽減策を実行できます。未使用のデザインステートリソース、すなわちデバイスに物理的に存在していてもデザインが使用していないリソースで発生したソフトエラーは無視されます。特に信頼性が重視されるデザインではリスクエリアを評価し、保証内容に応じてデザインステートに対するエラー軽減手法を採用する必要があります。

コンフィギュレーションメモリに格納されたデザイン機能に対するソフトエラーは、エラー検出および訂正コードを使用して軽減を図ります。

コンフィギュレーションメモリは幅の広いスタティック RAM のようにフレームの配列として構成されます。各フレームは多くのデバイスファミリで ECC によって保護されており、フレームの配列全体はすべてのデバイスファミリで CRC によって保護されています。これら 2 つの手法は補完的な関係にあり、 CRC はエラー検出性能が非常に高く、 ECC はエラー位置を高精度で特定します。

SEM Controller はデバイス内蔵ロジックの強力な機能をさらに発展させ、コンフィギュレーションメモリのエラーをエッセンシャルと非エッセンシャルに分類するオプション機能を備えています。この機能は、実際のデザインの動作に影響するエッセンシャルビットがコンフィギュレーションメモリビット全体のごく一部であることを利用しています。

エラー分類を無効にした場合、コンフィギュレーションメモリのすべてのエラーをエッセンシャルと見なす必要があります。エラー分類を有効にするとほとんどのエラーが非エッセンシャルと判定されるため、実害のないエラーに対する警告を防ぐことができ、システムレベルでの動作中断を伴うエラー軽減策の実行頻度が低下します。

また、 SEM Controller はデバイス内蔵の訂正機能を拡張してエラー検出を高速化すると共に、オプションで複数ビットエラーの処理にも対応します。

信頼性の推定

システム信頼性に関する仕様を決定するには、まずシステムデザイン全体のうち特に重要なセクションを特定し、セクションごとに必要な信頼性の値を決定していく必要があります。一般に、信頼性の要件は FIT (Failures In Time) で表します。これは、 109 時間 (約 114,155 年) あたりに予想されるデザインの故障回数です。

同じデザインを複数出荷する場合、いずれか 1 つのデザインがソフトエラーの影響を受ける確率は出荷台数に比例して大きくなります。たとえばあるデザインを製品として 1,000 個出荷した場合、出荷全数の公称 FIT は 1,000 倍になります。出荷全数の公称 FIT が大きくなると保守/メンテナンスの負担が増大することが考えられます。

出荷全数の公称 FIT は、個々のデザインが影響を受ける確率とは異なります。また、ある特定のデザインで 2 回目のエラーが発生する確率は、出荷全数の FIT ではなくデザイン個体の FIT によって決まります。これは、個々のアプリケーションに適したソフトエラー軽減方針を検討する際に考慮すべき重要な点です。

ソフトエラーに関する FIT と製品の推定耐用年数に関連する FIT は区別して考える必要があります。後者はシステムの部品の一部交換または物理的な修理が必要になる故障を想定したものです。

ザイリンクスデバイスの FIT データは『ザイリンクスデバイス信頼性レポート』 (UG116) [参照 1] に記載しています。このデータは、全体的にソフトエラーがほとんど発生しないことを示しています。

ヒント : 故障率は非常に低いため、ほとんどのデザインでソフトエラー軽減策は必要ありません。

フリップフロップは数が少なく FIT の値も非常に小さいため、デザイン全体の FIT にはほとんど影響しません。とはいえ、フリップフロップに格納されたデザインステートを保護することの重要性は変わりません。フリップフロップに格納されたステートがデザインの動作にとってきわめて重要な場合、ソフトエラーを検出および訂正してエラーから回復するためのロジックをアプリケーションに適した形でデザインに実装する必要があります。





第 1 章:概要

分散メモリやブロックメモリを多用するデザインでは、これらリソースがデザイン全体の FIT に大きく影響する可能性があります。前述のとおり、デザインでソフトエラー軽減策をとることで、デザイン全体の FIT への影響を大幅に抑えることができます。たとえばブロックメモリリソースにはエラー検出/訂正回路が内蔵されており、ブロックメモリのコンフィギュレーションによってはこの軽減機能を利用できます。プログラマブルロジックリソースを使用したソフトエラー軽減手法は、コンフィギュレーションに依存せずすべてのブロックメモリと分散メモリに使用できます。

コンフィギュレーションメモリはデザイン全体の FIT に大きく影響します。エラー分類機能を使用しない場合、コンフィギュレーションメモリで発生したソフトエラーはすべてエッセンシャルと見なす必要があります。その場合、コンフィギュレーションメモリによる FIT への影響がその他の要因による影響より圧倒的に大きくなります。

エラー分類機能を使用するとソフトエラーのほとんどを故障と見なす必要がなくなるため、デザイン全体の FIT への影響を抑えることができます。実害のないソフトエラーは、動作を中断せず訂正できます。

高レベルの信頼性が要求されるデザインでは、コンフィギュレーションメモリで発生したソフトエラーの分類が必須です。 SEM Controller はこの機能を提供します。

機能概要

SEM Controller は、デザインの要件に応じて 6 種類のモードのいずれかで生成できます。

• 軽減 + テスト (Mitigation and Testing) モード

• 軽減 (Mitigation only) モード

• 検出 + テスト (Detect and Testing) モード

• 検出 (Detect only) モード

• エミュレーション (Emulation) モード

• モニター (Monitoring) モード

軽減 (+ テスト ) モードではエラー検出、エラー訂正、およびオプションでエラー分類が可能です。軽減モードではエラー挿入はできません。

検出 (+ テスト ) モードではエラー検出が可能で、エラーの訂正と分類はできません。検出モードではエラー挿入はできません。

残りの 2 つのモード (エミュレーションモードとモニターモード ) では、シングルイベントアップセット (SEU) イベントが発生した場合のシステム動作を評価および観察できます。これらのモードには、エラー検出、エラー訂正、およびエラー分類の機能はありません。モニターモードではエラーは挿入できません。

いずれのモードでも、 SEM Controller はまず初期化を実行します。この初期化により、 FPGA がユーザーモードになった後、 FPGA 内蔵のソフトエラー検出機能が既知のステートに移行します。この初期化後の SEM Controller の動作は、選択したモードによって異なります。軽減 (+ テスト ) モードおよび検出 (+ テスト ) モードの場合、 SEM Controller は内蔵のソフトエラー検出ステータスを監視します。エミュレーションおよびモニターモードの場合はアイドルステートに移行し、コマンドまたはモニターインターフェイスからのコマンド入力を待ちます。

軽減 (+ テスト ) モードで ECC または CRC エラーを検出すると、 SEM Controller は状況を評価してエラーの発生したコンフィギュレーションメモリ位置を特定します。

メモリ位置を特定できた場合、 SEM Controller はソフトエラーを訂正します。訂正にはアクティブパーシャルリコンフィギュレーションを使用し、 Read-Modify-Write によってコンフィギュレーションメモリを部分的に訂正します。この方法は、アルゴリズムを使用して訂正の必要なエラーを特定します。

SEM Controller には、ルックアップテーブルを使用してソフトエラーがエッセンシャルかそうでないかを分類するオプション機能があります。エラー分類の実行中、必要に応じて情報がフェッチされます。このデータもインプリメンテーションツールによって提供され、 SEM Controller の外部に格納されます。





第 1 章:概要

ヒント : そのまま使用可能なソリューションでエラー分類機能を利用するには、外部 SPI フラッシュにエッセンシャルビットデータを格納する必要がありますが、分類機能は IP 外部に実装することもできます。この場合、エッセンシャルビットデータをシステムメモリに格納し、 SEM Controller のモニター /UART インターフェイスで報告されるエラー位置に基づいてルックアップを実行してください。

検出 (+ テスト ) モードで ECC または CRC エラーを検出すると、 SEM Controller は状況を評価してエラーの発生したコンフィギュレーションメモリ位置を特定し、可能であればそのメモリ位置を報告します。エラー検出レポートの出力が終わると、 SEM Controller はアイドルステートに遷移します。

軽減 + テスト、検出 + テスト、およびエミュレーションモードでは、 SEM Controller がアイドルステートの場合にユーザーがコマンドを入力してコンフィギュレーションメモリにエラーを挿入できます。軽減 + テストモードおよび検出 + テストモードでこの機能を使用すると、より大規模なシステムデザインに統合した SEM Controller をテストするのに役立ちます。

エミュレーションモードでこの機能を使用すると、システムデザインに対する SEU イベントの影響を評価するのに役立ちます。システム検証/バリデーションエンジニアはエラー挿入機能を使用してテストケースを構築し、システム全体がソフトエラーイベントに想定どおりの応答を示すかどうかを確認できます。

エラー挿入以外にも、アイドルステートではフレーム読み出し、コンフィギュレーションレジスタ読み出し、外部メモリ読み出し、フレームアドレス変換などテストやデバッグに役立つ機能を実行できます。

これ以外に、検出スキャンと診断スキャンという 2 種類のエラー検出機能があります。これらのコマンドは、どのモードでもアイドルステート時に SEM Controller に発行できます。

• 検出スキャン – このコマンドを実行すると SEM Controller は ECC または CRC エラーを検出するまでコンフィギュレーションメモリのスキャンを継続します。エラーを検出すると、 SEM Controller はエラーレポートを出力してアイドルステートに移行します。軽減 (+ テスト ) モードとは異なり、この機能にはエラー訂正は含まれません。

• 診断スキャン – このコマンドを実行すると SEM Controller はコンフィギュレーションメモリを 1 回スキャンして、検出されたすべての ECC エラーを報告します。 1 回のスキャンが完了すると、 SEM Controller はアイドルステートに戻ります。この機能で使用するエラー検出メカニズムは、デバイス内蔵のエラー検出機能を使用しません。このタイプのスキャンでは、エラー訂正は実行されません。

ほとんどの場合、 SEM Controller は軽減 + テストモードでデフォルトのコンフィギュレーションのまま使用します。この場合、 SEU イベントの検出と訂正に加え、エラー挿入機能も利用でき、アイドルステートでその他の便利な機能をすべて利用できます。量産段階で軽減モードに変更して、エラー挿入機能を無効にすることもできます。

その他のモードおよび機能は、ユーザー制御によるものなど高度な SEU 軽減ソリューションを必要とするシステム向けに用意されています。

ユーザー制御による軽減ソリューションを必要とする軽減ストラテジの一例として、訂正は行わずエラーログのみを記録するというものがあります。このような軽減ストラテジは、 SEM Controller を検出モードでコンフィギュレーションして実装できます。

たとえば SEM Controller を検出モードでコンフィギュレーションして使用すると、コントローラーは初期化完了後すぐに検出スキャンを自動で実行します。エラーが検出された場合、そのエラーに対してユーザーはデバイスのリコンフィギュレーションやロジックのリセットなど任意の措置をとることができます。

初のエラーまたは初の訂正不能エラーが検出された時点でデバイスに対する診断スキャンを周期的に実行し、デバイスに累積したすべての ECC エラーのログを記録します。ログに記録された検出済みフレームレベル ECC エラーを使用して、後でオフラインポストプロセスを実行できます。

重要: 診断スキャン機能は軽減用には設計されていないため、リアルタイムの軽減には使用しないでください。コンフィギュレーションメモリでエラーが発生したまま動作させた場合、ザイリンクスは FPGA の機能を保証しません。この機能は検出モードや軽減モードに比べエラー検出レイテンシがはるかに大きいため、診断目的の使用にとどめてください。





第 1 章:概要

アプリケーション

SEM Controller は自律動作が可能ですが、ほとんどのアプリケーションではこのソリューションをアプリケーションレベルの監視機能と組み合わせて使用します。この監視機能は SEM Controller からのイベント報告を監視し、デバイスのリコンフィギュレーションやアプリケーションのリセットなど、何らかの追加措置が必要かどうかを判断します。

システムを設計する際は、各デザインの信頼性要件、および各種情報に基づいて判断を下すシステムレベルの監視機能を慎重に検討してください。

そもそも、エラー軽減ソリューションが必要なのかを検討します。 SEM Controller が必要な場合は、どの機能を使用するかを検討します。

アプリケーション要件を考慮して SEM Controller が善の選択肢であると判断した場合、外部デバイスとの接続に使用するシステムレベルデザインのヘルパーブロックを含め、 SEM Controller を提供された状態のままで使用することを推奨します。ただし必要であれば、これらのインターフェイスをアプリケーションに合わせて変更することも可能です。

推奨: ザイリンクスは、 SEM IP コアをなるべく早い段階で (理想的にはプロジェクトの初から ) 統合することを推奨しています。詳細は、 102 ページの「統合およびバリデーション」を参照してください。

SEM IP の導入に関する主な考慮事項

このセクションでは、出荷後の製品におけるソフトエラー軽減の目標達成に SEM IP が役立つかどうか、そしてソフトエラー発生時にどのような軽減アプローチを選択すべきかを評価する方法を示します。以下の説明では、ここまでのセクションで取り上げた基本概念を使用します。

主に考慮すべき事項は、次の 2 つです。

• 個々のデザインについて、ソフトエラー軽減に関する要件を理解する。

• ソフトエラー発生時にどのような措置を実行する必要があるか。

ソフトエラー軽減に関する要件を理解する

出荷後の製品においてソフトエラーの影響が懸念される場合、通常はシステムデザイン内のコンポーネントごとに FIT バジェットが必要となります。ザイリンクス FPGA の FIT を計算するには、 SEU ラウンジで提供される SEU FIT レートエスティメーターを使用します。 FIT レートエスティメーターの使用方法は、 XAPP472 を参照してください。

出荷全数に対する FIT を計算するには、少なくとも次の情報が必要です。

• ターゲットデバイス

• デバイスの予想出荷数

SEU FIT レートエスティメーターは、デバイスの推定 FIT レートのほか、ある一定期間内に予想されるソフトエラーの数も提示します。

インプリメンテーション後のデザインでは、より正確に FIT を見積もることができます。より正確な見積もりには、使用するブロック RAM の数、ソフトエラーの検出と訂正にブロック RAM の ECC 機能を使用するかどうか、およびデザインに含まれるエッセンシャルビットの割合を入力する必要があります。エッセンシャルビットとは、FPGA の機能を定義するために使用するコンフィギュレーション RAM のビットをいいます。ソフトエラーによってエッセンシャルビットが意図せず変化した場合、 FPGA の機能が正しく動作しなくなる可能性があります。


https://japan.xilinx.com/member/seu.html




第 1 章:概要

これに対し、エッセンシャルビット以外のビットが変化しても、機能には影響しません。デザインに含まれるエッセンシャルビットの割合 (%) は、次の手順で調べることができます。

1. Vivado で次のプロパティを設定します。

set_property bitstream.seu.essentialbits yes [current_design]

2. デザインのビットストリームを再生成します。

3. エッセンシャルビットの割合は Vivado Tcl コンソールに表示され、ビットストリームおよびエッセンシャルビットデータの生成時に Vivado ログにも記録されます。次に例を示します。

Writing bitstream ./sem_ultrap_v3_1_example.bit...Creating bitstream...Writing bitstream ./sem_ultrap_v3_1_example.ebc...Creating essential bits data...This design has 707717 essential bits out of 143015456 total (0.49%).

FIT の見積もりが完了したら、出荷全数に対する FIT の要件が満たされているかどうかを確認する必要があります。FIT を軽減するには、その他の設計アプローチの導入が必要になることもあります。

FIT の目標値がないと、 SEM IP を使用することにメリットがあるかどうかを含め、ソフトエラーの影響を軽減するためにどのような設計変更 (およびそれに伴うトレードオフ) が必要かが明確になりません。このような場合は、SEM IP を統合する前に、 SEM IP を使用して得られるメリットを明らかにしておくことが重要です。

ソフトエラー発生時に考慮すべき措置

SEM IP は、ソフトエラーの検出のみを実行するか、検出して訂正するかを設定できます。したがって、ソフトエラー発生時にシステムレベルでどのような措置が必要かを検討する必要があります。デザインでソフトエラーが検出されても何も措置を講じない場合、デザインに SEM IP を統合することに利点があるかどうかを評価し、把握する必要があります。そのようなユースケースも可能ですが、ソフトエラーがデザインに与える影響を洗い出し、このような軽減アプローチでソフトエラー軽減の目標が達成されるかどうかを十分に理解する必要があります。

推奨: デザインで SEM IP を使用する場合は、モニターインターフェイスの出力をログに記録することを強く推奨します。

図 1-1 に、ソフトエラー発生時にシステムがどのような措置を講じるかを判定する決定木の例を示します。さまざまな可能性とシステムレベルの考慮事項を理解することにより、 SEM IP をデザインで使用するかどうかを決定できます。

注記: この図は一例であり、これ以外にも考慮事項が存在する可能性があります。





第 1 章:概要

X-Ref Target - Figure 1-1

図 1‐1: ソフトエラー検出時の決定木

Use SEM IP with correction and essential bit classification enabled.Detects and corrects soft errors occurring in configuration RAM

Has a soft error been detected?

Soft error corrected(~99.7% of events)

Soft errorcannot be corrected(< 0.3% of events)

Upset was a non-essential bit(typically > 50% of events1)

Upset was an essential bit(typically < 50% of events1)

Error did not affect the design’s function

Consider Action Dependent on Design and System

Error was transient but present on the device for some amount of time and could affect the design’s functionality.

Possible options:Internal reset on programmable logic design (or

module)Rely on other device or design-level detection of

any functional error ratesSet alert to system and continue to operate until

at a point where reset makes sense or until outside reset commanded

Do nothing and log errorOther actions (dependent on system design)

Functional error rate for a full device is about 2 to 10% of events. This is the typical percentage of configuration memory bits that are critical to the function’s behavior.

Consider Action Dependent on Design and System

Unclear what the error affected, but since it is not corrected, it continues to be present in the device.

Possible options:Reconfigure deviceRely on other device or design-level

detection of any function error ratesSet alert to system, and continue to

operate until at a point where reconfiguration makes sense

Do nothing and log errorOther actions (dependent on system

design)

The design’s integrity maybe compromised but only in about 2% to 10% of events.

After encountering an uncorrectable event, the SEM IP will stop scanning for errors and soft errors

can accumulate on the device (as if SEM IP is not present).

Legend:1 Percentages can be replaced with actual percentage of essential bits for a design.

X20044-022218





第 1 章:概要

パーシャルリコンフィギュレーションのサポート

UltraScale デバイスでは、 SEM IP とパーシャルリコンフィギュレーション (PR) の組み合わせはモノリシックデバイスを使用する場合のみサポートされます。スタックドシリコンインターコネクト (SSI) デバイスでは、 SEM IP とパーシャルリコンフィギュレーションの組み合わせはサポートされません。

UltraScale+ デバイスでは、SEM IP とパーシャルリコンフィギュレーションの組み合わせはモノリシックデバイスと SSI デバイスの両方でサポートされます。

SEM IP とパーシャルリコンフィギュレーションを含むデザインのインプリメンテーションは、この製品ガイドではなく、アプリケーションノートで詳しく説明しています。『モノリシックデバイスでの Soft Error Mitigation IP およびパーシャルリコンフィギュレーションのデモ』 (XAPP1261) [参照 6] を参照してください。 XAPP1261 は SEM IP とモノリシックデバイスの互換性についてのデモを取り上げていますが、 UltraScale+ SSI デバイスにも同じガイダンスが使用できます。

暗号化と認証のサポート

UltraScale デバイスでは、 SEM IP で AES-GCM-256 (自己認証 AES アルゴリム) を使用したビットストリームの秘密キー暗号化がサポートされます。 RSA-2048 を使用した公開キー認証も SEM IP でサポートされます。

UltraScale+ FPGA では、 SEM IP で AES-GCM-256 (自己認証 AES アルゴリム) を使用したビットストリームの秘密キー暗号化がサポートされます (検証済み)。 RSA-2048 を使用した公開キー認証も SEM IP でサポートされます (検証済み)。

UltraScale+ MPSoC では、 SEM IP で AES-GCM-256 (自己認証 AES アルゴリム) を使用したビットストリームの秘密キー暗号化がサポートされます (検証済み)。 RSA-4096 を使用した公開キー認証も SEM IP でサポートされます (検証済み)。





第 1 章:概要

サポートされていない機能

SEM Controller は、ブロックメモリ、分散メモリ、またはフリップフロップで発生したソフトエラーに対しては動作しません。これらメモリリソースで発生したソフトエラーは、冗長性またはエラー検出/訂正コードなどの予防手段を用いてユーザーロジックで軽減策をとる必要があります。

デザインで SEM Controller を使用する際は、次の点にも注意してください。

• SEM Controller は、 FPGA シリコンに内蔵されたソフトエラー軽減機能を初期化および管理します。これをデザインに含める場合は、内蔵の検出機能を有効にするようなデザイン制約またはオプションを含めないでください。たとえば POST_CRC、 POST_CONFIG_CRC、またはこれらに関連する制約を設定しないでください。同様に、 GLUTMASK を変更するオプションは指定しないでください。

• ソフトウェアで計算した ECC および CRC 値はサポートされません。

• コントローラーをインスタンシエートしたデザインのシミュレーションがサポートされます。ただしシミュレーションではコントローラーの動作は観察できません。コントローラーを含むデザインのシミュレーションはコンパイルできますが、コントローラーは初期化ステートから遷移しません。コントローラーの動作はハードウェアで評価する必要があります。

• コントローラーは SelectMAP の persist をサポートしていません。

• UltraScale アーキテクチャでは、デバイスの各ダイまたは SLR (Super Logic Region) ごとに SEM Controller と ICAP のインスタンスが 1 つ必要です。 ICAP はそのダイの物理的に上位の位置に配置する必要があります。別のロジックが ICAP 経由でコンフィギュレーションメモリにアクセスする必要がある場合、マルチプレクサーを使用して ICAP へのアクセスを共有する必要があります。 BITSTREAM.Readback_ICAP_Select および ICAP_AUTO_SWITCH は使用しないでください。これらは ICAP を Top と Bottom の間で切り替えるための手段です。これらを使用しても、ほかのロジックとの間でマルチプレクサーを使用した共有はできません。

• コンフィギュレーションエラーが発生し、 SPI/BPI フラッシュからゴールデン (フォールバック ) ビットストリームが読み込まれた場合、 SEM Controller は動作しません。 AR 67645 を参照してください。

• 複数のロジックがコンフィギュレーションメモリにアクセスする場合、このメモリへのアクセスを管理するアービトレーションロジックを作成する必要があります。詳細は、第 3 章の「ICAP アービトレーションインターフェイス」を参照してください。

• SEM IP の開発およびテストでは、宇宙放射線環境での使用は想定していません。したがって、このような環境での使用に対するサポートや、質問への回答は行っていません。宇宙放射線環境における SEM IP の使用は、使用者の自己責任となります。

ライセンスおよび注文情報

このザイリンクス LogiCORE™ IP モジュールは、ザイリンクスエンドユーザーライセンス規約のもとザイリンクス Vivado® Design Suite を使用して追加コストなしで提供されています。

その他のザイリンクス LogiCORE IP モジュールに関する情報は、ザイリンクス IP コアのページから入手できます。その他のザイリンクス LogiCORE IP モジュールおよびツールの価格や提供状況については、ザイリンクス販売代理店にお問い合わせください。



https://japan.xilinx.com/cgi-bin/docs/rdoc?t=eula

https://japan.xilinx.com/products/intellectual-property.html

https://japan.xilinx.com/about/contact.html

https://japan.xilinx.com/about/contact.html




第 2章

製品仕様この章では、LogiCORE™ IP UltraScale™ Architecture Soft Error Mitigation (SEM) Controller の仕様について説明します。コンフィギュレーションメモリ内のソフトエラーを緩和するこの設定可能なコントローラーには、実際のシステムでの使用例を示したシステムレベルのサンプルデザインも付属します。

機能

SEM Controller はデバイスへの依存性があり、次の機能を備えています。

• SEU 軽減の用途に応じた 6 つの IP モード

° 軽減 + テスト (Mitigation and Testing) モード

° 軽減 (Mitigation only) モード

° 検出 + テスト (Detect and Testing) モード

° 検出 (Detect only) モード

° エミュレーション (Emulation) モード

° モニター (Monitoring) モード

• 軽減 (+ テスト ) モード専用の機能

° 軽減 (+ テスト ) モードではデバイス内蔵のエラー検出機能を利用するシリコン機能を統合。

° ソフトエラーの訂正をサポートしたエラー訂正機能を実装。

° 大 4 ビットのエラーを含むコンフィギュレーションメモリフレームの訂正をサポートした ECC アルゴリズムベースの訂正機能。

° 1 回の SEU イベントによって隣接する複数のフレームで発生した複数ビットエラーを小限のレイテンシで検出および訂正。

° 訂正したエラーが実際のデザインの機能に影響するコンフィギュレーションメモリ位置で発生したかどうかを判定するエラー分類機能を実装。

° コントローラーの検証およびコントローラーのアプリケーション評価に役立つエラー挿入機能をサポート。

° SEM Controller に対してソフトエラーの検出スキャン実行を命令するコマンド。このステートでは、エラーが検出されるまで SEM Controller がコンフィギュレーションメモリのスキャンを続けます。エラーを検出すると、 SEM Controller はエラーレポートを出力してアイドルステートに移行します。このコマンドにはエラー訂正機能は含まれません。





第 2 章:製品仕様

• アイドルステートで実行可能な各種デバッグおよびテスト機能

° コンフィギュレーションフレーム読み出し (Query コマンド )。

エラー挿入の前後にコンフィギュレーションフレームを読み出して、ビットがマスクされておらずエラーが正しく挿入されたことを確認することを推奨します。

° コンフィギュレーションレジスタ読み出し (Peek コマンド )。

° 物理フレームアドレス (PFA) とリニアフレームアドレス (LFA) のコンフィギュレーションを双方向に変換するフレームアドレス変換 (Translate コマンド )。

° 外部 SPI フラッシュメモリ読み出し (Xmem コマンド )。このコマンドを利用できるのはエラー分類機能を有効にした場合のみです。

• エラー訂正は行わず、エラーのスキャンとレポートを継続実行するオプション機能 (検出 (+ テスト ) モードおよび検出スキャンコマンド )。このステートでは、 SEM Controller は 1 つのエラーを検出するとレポートを出力してアイドルステートに移行します。

• SEM Controller に対して診断スキャンの実行を命令するコマンド。このステートでは、 SEM Controller はコンフィギュレーションメモリ全体に対してスキャンを 1 回実行し、検出したすべての ECC エラーを報告します。1 回のコンフィギュレーションメモリスキャンが完了すると、 SEM Controller はアイドルステートに戻ります。この機能で使用するエラー検出メカニズムは、デバイス内蔵のエラー検出機能を使用しません。このタイプのスキャンでは、エラー訂正は実行されません。

• コントローラーと外部ストレージを接続するインターフェイスを提供する SPI フラッシュマスターヘルパーブロック。コントローラーの設定でエラー分類を有効にした場合、このインターフェイスが必要です。

• コントローラーと外部プロセッサを接続するためのインターフェイスを提供する UART ヘルパーブロック。コントローラーステータスのログを記録する場合や、エラー挿入を実行する場合の使い勝手が向上します。

• ヘルパーブロックとコンフィギュレーションプリミティブはコアまたはサンプルデザインのいずれかに柔軟に配置可能。

• ほかのブロックとの ICAP 共有を簡単にし、安全なハンドオフを可能にする ICAP アービトレーションインターフェイス。






表 2-1 に各モードの機能をまとめます。

表 2-2 に、サポートされるすべてのデバイスでスキャン対象となるコンフィギュレーションフレームの大数を示します。この値は、ステータスコマンドで報告される大リニアフレーム数 (MF {8-digit hex value}) と同じものです。

表 2‐1:各モードの機能

機能モード

軽減 + テスト軽減検出 + テスト検出エミュレーションモニター

初期化後の IP ステート監視 OBSV DETECT DETECT IDLE IDLE

訂正 (修復) ありあり N/A N/A N/A N/A

分類オプションオプション N/A N/A N/A N/A

エラー挿入あり N/A あり N/A あり N/A

デバッグ機能

• アイドルステートへの遷移

• コンフィギュレーションフレームおよびレジスタ読み出し

• 外部メモリ読み出し

• アドレス変換

ありありありありありあり

オンデマンド検出機能

• 検出

• 診断スキャン

ありありありありありあり

表 2‐2: コンフィギュレーションフレームの最大数

デバイス MF (10 進数) MF (16 進数)

UltraScale

XCKU035 26179 00006643

XCKU040 26179 00006643

XCKU060 37651 00009313

XCKU085 37651 00009313

XCKU095 54559 0000D51F

XCKU115 37651 00009313

XCVU065 37706 0000934A

XCVU080 54559 0000D51F

XCVU095 54559 0000D51F

XCVU125 37706 0000934A

XCVU160 37706 0000934A

XCVU190 37706 0000934A

XCVU440 78555 000132DB






UltraScale+

XCKU3P 31287 00007A37

XCKU5P 31287 00007A37

XCKU9P 48054 0000BBB6

XCKU11P 49127 0000BFE7

XCKU13P 57532 0000E0BC

XCKU15P 75283 00012613

XCVU3P 56601 0000DD19

XCVU5P 56601 0000DD19

XCVU7P 56601 0000DD19

XCVU9P 56601 0000DD19

XCVU11P 61963 0000F20B

XCVU13P 61963 0000F20B

XCVU27P 61963 0000F20B

XCVU29P 61963 0000F20B

XCVU31P 61929 0000F1E9

XCVU33P 61929 0000F1E9

XCVU35P (SLR0) 61929 0000F1E9

XCVU35P (SLR1) 61963 0000F20B

XCVU37P (SLR0) 61929 0000F1E9

XCVU37P (SLR1 および SLR2) 61963 0000F20B

XCZU2 10373 00002885

XCZU3 10373 00002885

XCZU4 17907 000045F3

XCZU5 17907 000045F3

XCZU6 48054 0000BBB6

XCZU7 44273 0000ACF1

XCZU9 48054 0000BBB6

XCZU11 49127 0000BFE7

XCZU15 57532 0000E0BC

XCZU17 75283 00012613

XCZU19 75283 00012613

XCZU21DR 68119 00010A17

XCZU25DR 68119 00010A17

XCZU27DR 68119 00010A17

XCZU28DR 68119 00010A17

XCZU29DR 68119 00010A17

表 2‐2: コンフィギュレーションフレームの最大数 (続き)

デバイス MF (10 進数) MF (16 進数)






規格

このコアが対象となる、業界標準の適合性検査または認証試験は定義されていません。 SEM Controller は、加速粒子の照射を含む大規模なハードウェアバリデーションを受けています。

パフォーマンス

SEM Controller のパフォーマンスメトリクスはシリコン仕様および実測に基づいて求めたものであり、事前の見積もり以外の用途には使用しないでください。実際のパフォーマンスは異なる場合があります。

最大周波数

SEM Controller の大動作周波数は保証されていません。いかなる場合も、使用するデバイスのデータシートでコンフィギュレーションインターフェイスの AC タイミングパラメーター FICAPCK として定義されている ICAP の FMax を大動作周波数が上回ることはできません。表 2-3 に、 ICAP の FMax の値をまとめます。

大周波数には、その他の制限が適用されることもあります。 SEM Controller の大動作周波数の決定方法の詳細は、第 3 章の「システムクロックインターフェイス」を参照してください。

表 2‐3: ICAP の最大周波数

デバイス ICAP FMax (MHz)

UltraScale

Kintex 200

Virtex 200

Kintex SSI 200

Virtex SSI 200

すべてのデバイス (0.9V、 -1L) 175

UltraScale+

Kintex 200

Virtex 200

Virtex SSI 125

Zynq UltraScale+ デバイス 200

すべてのデバイス (0.72V、 -1L、 -2L) 150






ソリューションの信頼性

ここからはシステムレベルサンプルデザインを解析し、FPGA にインプリメントしたソリューション自体の FIT の推定値を求めます。この解析手法は、 FPGA にインプリメントしたほかの回路の FIT を推定する際にも利用できます。

この解析では、すべての機能を有効にしてすべての信号を I/O ピンに接続した場合を想定しています。 Virtual Input Output (VIO) コアは解析には含めていません。このような対話型のデバッグおよび実験機能を含めたままデザインを出荷する可能性は低いためです。このため、この推定値は上限を表しています。

SEM IP を含むデザインの信頼性を設計前に推定するには、スプレッドシート形式の SEU FIT Estimator を使用してください。表 2-4 に、 SEM IP ソリューションの大推定 FIT レート (すべての機能を有効にし、すべてのヘルパーブロックを含めた場合) を示します。

上記の推定値は、 SEM Controller およびそのシステムレベルサンプルデザインで使用するコンフィギュレーション RAM とブロック RAM を含めて計算しています。

ソリューションのレイテンシ

このソリューションのエラー軽減レイテンシは、エラー条件が発生してからエラー軽減プロセスが完了するまでの時間と定義されます。エラー軽減プロセスは、エラー検出、訂正、分類から成ります。

推定データ

このソリューションの動作の基本は、 FPGA コンフィギュレーションメモリのフレーム処理にあります。 1 ビットエラーは常に 1 つのフレームで発生します。 N ビットエラーの発生方法はいくつかあり、すべてのビットエラーが 1 つのフレームで発生することもあれば、 N 個のフレームでそれぞれ 1 ビットエラーが発生することもあります。複数のフレームでエラーが発生している場合、検出、訂正、分類のシーケンスをそのフレームの数だけ繰り返します。

このソリューションは任意の数のエラーを適切に軽減します。任意の数のエラーの場合、エラー軽減レイテンシの推定は複雑です。このセクションでは、一般的な例として 1 フレームのみのエラーを取り上げますが、この例を通じて理解したコントローラーの動作はほかのケースにも応用がききます。

表 2‐4:最大推定 FIT レート

デバイス FIT

UltraScale モノリシックデバイス 9

UltraScale KU115 (SSI の例) 23

UltraScale+ モノリシックデバイス 3

UltraScale+ SSI デバイス 6






スタートアップレイテンシ

スタートアップレイテンシとは、FPGA のコンフィギュレーションが完了してから SEM Controller の初期化が完了するまで (すなわち SEM Controller が監視ステートに遷移するまで) の遅延をいいます。このレイテンシは FPGA のサイズ (フレーム数) およびソリューションのクロック周波数によって変わります。

スタートアップレイテンシは一度だけ加算されます。これはエラー軽減プロセスの一部ではありません。表 2-5 と表 2-6 に示すように、スタートアップレイテンシはブート時間と初期化時間で構成されます。

表 2‐5: UltraScale デバイスの最大スタートアップレイテンシ (ICAP FMax の場合)

デバイスブート時間 (ICAP FMax、 ms) 初期化時間 (ICAP FMax、 ms)

UltraScale

XCKU035 127 52

XCKU040(1) 127 52

XCKU060 127 75

XCKU085 127 75

XCKU095 127 109

XCKU115 127 75

XCVU065 127 75

XCVU080 127 109

XCVU095 127 109

XCVU125 127 75

XCVU160 127 75

XCVU190 127 75

XCVU440 127 156

注記:1. ハードウェアで計測されています。このアーキテクチャのほかのデバイスのデータは、この計測値を元に外挿で求めます。






表 2‐6: UltraScale+ デバイスの最大スタートアップレイテンシ (ICAP FMax の場合)

デバイスブート時間 (ICAP FMax、 ms) 初期化時間 (ICAP FMax、 ms)

UltraScale+

XCKU3P 127 46

XCKU5P 127 46

XCKU9P 127 71

XCKU11P 127 73

XCKU13P 127 85

XCKU15P 127 111

XCVU3P(1) 127 84

XCVU5P 204 137

XCVU7P 204 137

XCVU9P(1) 204 137

XCVU11P 204 150

XCVU13P 204 153

XCVU27P 204 150

XCVU29P 204 150

XCVU31P 127 97

XCVU33P 127 97

XCVU35P 204 150

XCVU37P 204 150

XCZU2 127 16

XCZU3 127 16

XCZU4 127 27

XCZU5 127 27

XCZU6 127 71

XCZU7 127 66

XCZU9 127 71

XCZU11 127 73

XCZU15 127 85

XCZU17 127 111

XCZU19 127 111

XCZU21DR 127 106

XCZU25DR 127 106

XCZU27DR 127 106

XCZU28DR 127 106

XCZU29DR 127 106

注記:1. ハードウェアで計測されています。このアーキテクチャのほかのデバイスのデータは、この計測値を元に外挿で求めます。






ブート時間と初期化時間の合計がスタートアップレイテンシです。実際の動作周波数でのスタートアップレイテンシは、表 2-5 および表 2-6 のデータと式 2-1 から見積もることができます。

式 2‐1

エラー検出レイテンシ

エラー軽減レイテンシ全体に占める割合がも大きいのが、エラー検出レイテンシです。このレイテンシは FPGA のサイズ (フレーム数) およびソリューションのクロック周波数によって変わります。また、エラーのタイプ、およびシリコンリードバックプロセスの位置を基準としたエラーの相対位置によっても変わります。

表 2-7 と表 2-8 に、 IP のエラー検出時間を示します。これらの数値は、 IP が軽減 (+ テスト ) モード (検出および訂正)、検出 (+ テスト ) モード、および検出ステートの場合のものです。

表 2‐7: UltraScale デバイスの最大 IP エラー検出時間 (ICAP FMax の場合)

デバイス検出時間 (ICAP FMax、 ms)

UltraScale

XCKU035 22

XCKU040(1) 22

XCKU060 30

XCKU085 30

XCKU095 41

XCKU115 30

XCVU065 30

XCVU080 41

XCVU095 41

XCVU125 30

XCVU160 30

XCVU190 30

XCVU440 58

注記:1. ハードウェアで計測されています。このアーキテクチャのほかのデバイスのデータは、

この計測値を元に外挿で求めます。

S tartUpLatencyACTUAL S tartUpLatencyICAP_FMaxICAP_FMax

FrequencyACTUAL----------------------------------------=






表 2‐8: UltraScale+ デバイスの最大 IP エラー検出時間 (ICAP FMax の場合)

デバイス検出時間 (ICAP FMax、 ms)

UltraScale+

XCKU3P 19

XCKU5P 19

XCKU9P 28

XCKU11P 29

XCKU13P 33

XCKU15P 42

XCVU3P(1) 32

XCVU5P 52

XCVU7P 52

XCVU9P(1) 52

XCVU11P 57

XCVU13P 57

XCVU27P 57

XCVU29P 57

XCVU31P 37

XCVU33P 37

XCVU35P 57

XCVU37P 57

XCZU2 9

XCZU3 9

XCZU4 13

XCZU5 13

XCZU6 28

XCZU7 26

XCZU9 28

XCZU11 29

XCZU15 33

XCZU17 42

XCZU19 42

XCZU21DR 40

XCZU25DR 40

XCZU27DR 40

XCZU28DR 40

XCZU29DR 40

注記:1. ハードウェアで計測されています。このアーキテクチャのほかのデバイスのデータは、

この計測値を元に外挿で求めます。






実際の動作周波数でのターゲットデバイスの IP エラー検出時間は、表 2-7 および表 2-8 のデータと式 2-2 から見積もることができます。

式 2‐2

エラー検出レイテンシには次の制限があります。

• ECC による検出の場合、大エラー検出レイテンシは DetectionTimeACTUAL

• CRC のみによる検出の場合、絶対大エラー検出レイテンシは 2.0 × DetectionTimeACTUAL

1 回の SEU イベントで 4 つの隣接するフレームにまたがる複数ビットエラーが発生した場合、SEM Controller のアルゴリズムは 2 フレーム目以降のエラー検出時間が小限に抑えられるように適化されています。このアルゴリズムにより、コントローラーは 4 つの隣接したフレームにまたがる大 16 ビットのエラーを 1 回のスキャンで検出および訂正できます。 1 ビットエラーのワーストケースの検出時間に 1 ビットエラーの数を掛けたものが、複数ビットエラー全体のワーストケースの検出時間となります。

診断スキャン機能を使用した場合のエラー検出レイテンシは軽減 (+ テスト ) モード、検出 (+テスト ) モード、または検出スキャンよりもはるかに大きく、その値はデバイス、検出されるエラーの数、および実際の動作周波数によって異なります。

たとえば KU040 のコンフィギュレーションメモリに 3 つのエラーが存在する場合、クロック周波数 90MHz で診断スキャンを実行すると、すべてのエラーを検出して報告するのに 70 秒かかります。

エラー訂正レイテンシ

エラーを検出すると、このソリューションは訂正を試みます。エラーが訂正可能かどうかは、選択した訂正モードとエラータイプによって決まります。表 2-9 に、コンフィギュレーションフレームが反転した場合のエラー訂正レイテンシを示します。これらの値は、モニターインターフェイスでスロットリングが発生していないことを前提としています。

表 2‐9: エラー訂正レイテンシ (モニターインターフェイスでのスロットリングなし )

デバイス訂正モード訂正可能/不能エラー訂正レイテンシ

(ICAP_FMax、 µs)

UltraScale修復

訂正可能(1) 41(2)

訂正不能 21(2)

すべて CRC のみ (訂正不能) 9

UltraScale+ モノリシック修復

訂正可能(1) 44(3)

訂正不能 22(3)


UltraScale+ SSI修復

訂正可能(1) 99(4)

訂正不能 38(4)


注記:1. 物理的に隣接している場合、フレーム内の大 4 ビットを訂正できます。

2. XCKU040 デバイスはハードウェアで計測されています。

3. XCVU3P デバイスはハードウェアで計測されています。


Detec tionT imeACTUAL Detec tionT imeICAP_FMaxICAP_FMax

F requencyACTUAL----------------------------------------=






実際の動作周波数でのエラー訂正レイテンシは、表 2-9 のデータと式 2-3 から見積もることができます。

式 2‐3

エラー分類レイテンシ

エラーの訂正を試みた後、このソリューションはエラーを分類します。分類結果は、訂正モード、エラータイプ、エラー位置、および選択した分類モードによって異なります。表 2-10 に、コンフィギュレーションフレームが反転した場合のエラー分類レイテンシを示します。これらの値は、モニターインターフェイスでスロットリングが発生していないことを前提としています。

実際の動作周波数でのエラー分類レイテンシは、表 2-10 のデータと式 2-4 から見積もることができます。

式 2‐4

エラー挿入レイテンシ

表 2-11 に、 1 ビットのコンフィギュレーションフレームが反転した場合のエラー挿入レイテンシを示します。これらの値は、モニターインターフェイスでスロットリングが発生していないことを前提としています。

表 2-11 に示したエラー挿入レイテンシの値は、クロック周波数およびデバイスのコンフィギュレーションフレーム数によって変化します。

表 2‐10: エラー分類レイテンシ (モニターインターフェイスでのスロットリングなし )

デバイスファミリフレーム内のエラー (訂正可能/不能)

分類モードエラー分類レイテンシ

(ICAP_FMax、 µs)

UltraScale訂正可能有効 185(1)

訂正不能すべて 5(1)

UltraScale+ モノリシック

訂正可能有効 154(2)


UltraScale+ SSI訂正可能有効 247(3)


注記:1. XCKU040 デバイスはハードウェアで計測されています。



表 2‐11: LFA を使用した場合のエラー挿入レイテンシ (モニターインターフェイスでのスロットリングなし )

デバイスファミリエラー挿入レイテンシ (ICAP_FMax、 µs)

UltraScale KU040 50(1)

UltraScale+ VU3P 81(1)

UltraScale+ SSI VU9P 164(1)

注記:1. ハードウェアで計測されています。

Correc tionLatencyACTUAL Correc tionLatencyICAP_FMaxICAP_FMax

F requencyACTUAL----------------------------------------=

Class ificationLatencyACTUAL Clas s ificationLatencyICAP_FMaxICAP_FMax

FrequencyACTUAL----------------------------------------=






その他の要因によるレイテンシ

モニターインターフェイスでのスロットリングは全体的なエラー軽減レイテンシを増大させるため、極力避けてください。

• エラーの訂正を試みた後、コントローラーはモニターインターフェイスから検出/訂正レポートを出力してから、エラー訂正ステートを終了します (このとき、 status_uncorrectable フラグが更新される )。このレポート生成中に UART ヘルパーブロックの送信 FIFO がフルになると、コントローラーは UART ヘルパーブロックの送信 FIFO にレポート全体の書き込みが完了するまでこのステートを終了できません。この場合、エラー訂正レイテンシが増大します。

• エラーの分類を試みた後、コントローラーはモニターインターフェイスから分類レポートを出力してから、エラー分類ステートを終了します (このとき、 status_essential フラグが更新される)。このレポート生成中に UART ヘルパーブロックの送信 FIFO がフルになると、コントローラーは UART ヘルパーブロックの送信 FIFO にレポート全体の書き込みが完了するまでこのステートを終了できません。この場合、エラー分類レイテンシが増大します。

ボトルネックの発生が問題になるヘルパーブロックまたはペリフェラルの場合、回避策をとることができます。予想される大バースト長のステータスメッセージを格納できるように送信 FIFO のサイズを調整すると、エラー軽減中に送信 FIFO がフルになることを回避できます。

送信 FIFO がフルになった場合、全体的なエラー軽減レイテンシのおおよその増加分は、式 2-5 で見積もることができます。

式 2‐5

式 2-5 で、「MessageLength – BufferDepth」はメッセージバイト数、「Transmission Rate」は単位時間あたりのバイト数です。

LFA を使用してエラー挿入を実行した場合も、コントローラーがまず LFA を PFA に変換する必要があるため、レイテンシが増大します。この変換のレイテンシも、エラー発生場所により異なり、アドレスが大きいほど変換に時間がかかります。

レイテンシの見積もり例

初の例は、 XCKU40 (90MHz クロック ) にソリューションをインプリメントした場合の、 1 ビットエラーの軽減レイテンシを見積もります。このソリューションは、軽減 + テストモードおよびエラー分類無効でコンフィギュレーションしています。ここでは、モニターインターフェイスのスロットリングは発生しないものと仮定します。

式 2‐6

式 2‐7

式 2‐8

式 2‐9

AdditionalLatency MessageLength BufferDepth–Transmis s ionRate---------------------------------------------------------------------=

Detec tionLatency 22ms 200MHz90MHz----------------- 48.889ms= =

Correc tionLatency 41s 200MHz90MHz----------------- 0.091ms= =

Class ificationLatency 5s 200MHz90MHz----------------- 0.011ms= =

MitigationLatency 48.889ms 0.091ms 0.011ms+ + 48.991ms= =






次に、モニターインターフェイスでスロットリングが発生した場合に追加されるレイテンシの見積もり例を示します。先の例で、メッセージ長を約 80 バイト、 UART ヘルパーブロックのバッファー深さを 32 バイトと仮定します。また、 UART ヘルパーブロックのビットレートを 9,600 ボーから 460,800 ボーへ変更しています。標準 8-N-1 プロトコルを使用しており、 1 バイトのペイロードをシリアルリンクで送信するのに 10 ビット時が必要です。

式 2‐10

この結果が示すように、特にデータ送信がシリアライズされデータレートが低い場合、モニターインターフェイスのスロットリングによってレイテンシは非常に大きくなります。

スループット

SEM Controller のスループットメトリクスは仕様で定義されていません。

消費電力

SEM Controller の電力メトリクスは仕様で定義されていません。

リソース使用状況

SEM Controller のリソース使用量のメトリクスは合成後レポートから求めたものであり、事前の見積もり以外の用途には使用しないでください。実際のリソース使用量は異なることがあります。

AdditionalLatency 80bytes 32bytes–

460800bittimess--------------------------------- byte

10bittimes----------------------- s1000ms----------------

--------------------------------------------------------------------------------------- 1.042ms= =

表 2‐12:デバイスのリソース使用量 – モノリシック Kintex および Virtex UltraScale/UltraScale+ デバイス (非 SSI)(1)(2)

デバイス IP コアのコンフィギュレーション LUT FF I/O ブロック RAM DSP48

UltraScale (全デバイス)完全ソリューション (軽減 + テストモード、オプション機能なし )。

425 490 59 4 RAMB36 1

UltraScale+ モノリシック (全デバイス)

完全ソリューション (軽減 + テストモード、オプション機能なし )。

430 530 64 4 RAMB36 1

注記:1. 完全ソリューションとは、 SEM Controller とサポートラッパー階層に含まれるロジックを組み合わせたものをいいます。これらは併用を

想定しています。 IP は Vivado® IDE のデフォルトオプション (軽減 + テストモード、エラー分類無効) でコンフィギュレーションしてい

ます。

2. 上位のサンプルデザインに含まれる Vivado Design Suite のデバッグ機能 IP は含めていません。 Vivado Design Suite のデバッグ機能を使

用すると LUT/FF の使用量が増えますが、 I/O の使用量は減少します。






表 2‐13:デバイスのリソース使用量 – マルチ SLR UltraScale および UltraScale+ デバイス (SSI)(1)(2)

デバイス IP コアのコンフィギュレーション LUT FF I/O ブロック RAM DSP48

KU115 完全ソリューション (軽減 + テストモード、オプション機能なし )。

1,060 1,280 70 8 RAMB36、2 RAMB18

2

VU9P 完全ソリューション (軽減 + テストモード、オプション機能なし )。

514 653 66 6 RAMB36 1

注記:1. 完全ソリューションとは、 SEM Controller とサポートラッパー階層に含まれるロジックを組み合わせたものをいいます。これらは併用を想

定しています。 IP は Vivado IDE のデフォルトオプション (軽減 + テストモード、エラー分類無効) でコンフィギュレーションしています。

2. 上位のサンプルデザインに含まれる Vivado Design Suite のデバッグ機能 IP は含めていません。 Vivado Design Suite のデバッグ機能を使

用すると LUT/FF の使用量が増えますが、 I/O の使用量は減少します。






ポートの説明

SEM Controller は、ソフトエラー軽減ソリューションの中心的な役割を果たします。コントローラーをデザインに統合する際は、コンフィギュレーションプリミティブ、 UART および SPI フラッシュマスターヘルパーブロック (必要な場合) などで構成されるシステムレベルデザインを含め、 SEM Controller を提供された状態のままで使用することを推奨します。

図 2-1 に、UltraScale およびモノリシック UltraScale+ デバイスの SEM Controller とシステムレベルサンプルデザインのポートを示します。グレーで示したポートグループはエラー分類を有効にした場合のみ存在します。特に記載のない限り、ポートはコアレベルおよびサンプルデザインのすべての階層レベルで利用できます (図 5-1 参照)。


図 2‐1: UltraScale およびモノリシック UltraScale+ デバイスの SEM Controller ポート

Legend: 1 Ports only available on the SEM controller.2 Ports on the system-level example design solution.3 command_code port width depends on target architecture. For UltraScale devices, the port width is 40 and for all other architecture, it is 44.4 fecc_far port width depends on target architecture. For UltraScale devices, the port width is 26 and for all other architecture it is 27.

command_strobe

command_code[w:0]3status_heartbeat

status_initialization

status_observation

status_correctionstatus_classification

status_injection

status_uncorrectablestatus_essential

icap_o[31:0]

icap_clk

icap_csib

icap_rdwrb

icap_i[31:0]

fecc_eccerrornotsingle

fecc_eccerrorsingle

fecc_endofframe

fecc_endofscan

fecc_crcerror

fecc_far[w:0]4

monitor_txdata[7:0]

monitor_txwrite

monitor_txfull

monitor_rxdata[7:0]

monitor_rxread

monitor_rxempty

fecc_farsel[1:0]

fetch_txdata[7:0]

fetch_txwrite

fetch_txfull

fetch_rxdata[7:0]

fetch_rxread

fetch_rxempty

fetch_tbladdr[31:0]

aux_error_cr_ne

aux_error_cr_es

aux_error_uc

icap_prerror

icap_prdone

icap_avail

command_busy

uart_rxuart_tx

spi_c

spi_d

spi_s_n

spi_q

cap_rel

cap_gnt

cap_req

Command Interface

Status Interface

ICAP

Interface 1

ICAP ArbitrationInterface

Auxiliary Interface

Monitor

Interface 1

UART Interface 2

Fetch

Interface 1

Master SPI Flash

Interface 2

clkMaster ClockInterface 2

status_detect_onlystatus_diagnostic_scan

FRAME_ECC Interface

X16280-012617






図 2-2 に、 UltraScale+ SSI デバイスの場合の SEM Controller とシステムレベルサンプルデザインのポートを示します。グレーで示したポートグループはエラー分類を有効にした場合のみ存在します。特に記載のない限り、ポートはコアレベルおよびサンプルデザインのすべての階層レベルで利用できます (図 5-1 参照)。

UltraScale と UltraScale+ では SSI の実装が異なります。 UltraScale では、ソフトエラー軽減機能はそれぞれの SLR で個別に実行されます。各 SLR に SEM Controller が 1 つずつあり、それが同じ SLR の ICAP と FRAME_ECC に接続されます。 UltraScale+ デバイスでは、この機能は 1 つのコントローラーに集約されます。デバイスの SLR の数にかかわらず、 SEM Controller は 1 つだけです。 SEM Controller は、マスター SLR に存在する 1 つの ICAP、および各 SLR の FRAME_ECC に接続されます。第 5 章「サンプルデザイン」を参照してください。


図 2‐2: UltraScale+ SSI デバイスの SEM Controller ポート

Legend: 1 Ports only available on the SEM controller.2 Ports on the system-level example design solution.3 There is a status_heartbeat port for each SLRs in a target device.4 SSI implementation has a FRAME_ECC interface for each SLR.

command_strobe

command_code[43:0]

slr#_status_heartbeat3

status_initialization

status_observation

status_correctionstatus_classification

status_injection

status_uncorrectablestatus_essential

icap_o[31:0]

icap_clk

icap_csib

icap_rdwrb

icap_i[31:0]

slr#_fecc_eccerrornotsingle4

slr#_fecc_eccerrorsingle4

slr#_fecc_endofframe4

slr#_fecc_endofscan4

slr#_fecc_crcerror4

slr#_fecc_far[26:0]4

monitor_txdata[7:0]

monitor_txwrite

monitor_txfull

monitor_rxdata[7:0]

monitor_rxread

monitor_rxempty

slr#_fecc_farsel[1:0]4

fetch_txdata[7:0]

fetch_txwrite

fetch_txfull

fetch_rxdata[7:0]

fetch_rxread

fetch_rxempty

fetch_tbladdr[31:0]

aux_error_cr_ne

aux_error_cr_es

aux_error_uc

icap_prerror

icap_prdone

icap_avail

command_busy

uart_rxuart_tx

spi_c

spi_d

spi_s_n

spi_q

cap_rel

cap_gnt

cap_req

Command Interface

Status Interface

ICAP

Interface 1

ICAP ArbitrationInterface

Auxiliary Interface

Monitor

Interface 1

UART Interface 2

Fetch

Interface 1

Master SPI Flash

Interface 2

clkMaster ClockInterface 2

status_detect_onlystatus_diagnostic_scan

FRAME_ECC Interface

X18677-012617






表 2-14 に各インターフェイスおよびそのインターフェイスが外部に現れる階層レベルを一覧にまとめます。一部のインターフェイスは、 IP の機能によっては存在しないことがあります。 IP 階層とそのインターフェイス接続を含むサンプルデザインのブロック図は、図 5-1 を参照してください。階層レベルの詳細は、第 3 章の「構造オプション」を参照してください。

表 2‐14: インターフェイスと階層レベル

インターフェイス説明

階層レベル

コンフィギュレーションプリミティブを

サンプルデザインに配置

コンフィギュレーションプリミティブをコアに配置

コマンド小限のコマンドセットで SEM

Controller と通信するためのインターフェイス。

SEM Controller SEM Controller

ICAP コンフィギュレーションメモリシステムにアクセスするための ICAP へのインターフェイス。

SEM Controller。 ICAP インターフェイスはサポートレベルでプリミティブに接続。

外部には現れません。ICAP インターフェイスはコア内部でプリミティブに接続。

システムクロックシステムクロックをソリューションに供給するためのインターフェイス。

サポートラッパーレベルサポートラッパーレベル

FRAME_ECC

シリコン内蔵のコンフィギュレーションリードバックメカニズムからの情報にアクセスするための FRAME_ECC へのインターフェイス。

UltraScale+ SSI デバイスでは、デバイスの各 SLR に FRAME_ECC インターフェイスがあります。

SEM Controller。 FRAME_ECC インターフェイスはサポートレベルでプリミティブに接続。

外部には現れません。FRAME_ECC インターフェイスはコア内部でプリミティブに接続。

ICAP アービトレーション

ほかのブロックとの ICAP 共有を管理するためのインターフェイス。 ICAP へのアクセスの安全なハンドオフと SEM Controller による ICAP へのアクセス再開を簡単に実装できます。


補助

コントローラーから直接監視できないソフトエラーイベントをコントローラーに通知する手段として使用するインターフェイス。


ステータス

コントローラーが正常動作しているかどうかを含め、コントローラーの現在のステートを知らせるためのインターフェイス。

UltraScale+ SSI デバイスでは、 SLR ごとに個別の status_heartbeat 信号があります。


モニター

コントローラーとの通信手段としてのほか、コントローラーの動作と現在のステートについての詳細な情報を得る手段としても使用可能なインターフェイス。システムとコントローラーの通信にはこのインターフェイスの使用を推奨します。







SEM Controller にはリセット入出力はありません。 GSR (グローバルセット / リセット ) 信号のディアサートから生成した内部同期リセットによって自動的に自己初期化します。

SEM Controller は、 icap_clk を唯一のクロックとして使用する完全同期デザインです。すべてのステートエレメントはこのクロックの立ち上がりエッジに同期します。このため、インターフェイスもすべてこのクロックの立ち上がりエッジに同期します。

ICAP インターフェイス

ICAP インターフェイスは SEM Controller と ICAP プリミティブをポイントツーポイントで接続します。 ICAP プリミティブにより、 FPGA コンフィギュレーションシステム内のレジスタへの読み出しおよび書き込みアクセスが可能になります。 ICAP プリミティブおよびこのインターフェイスの信号の動作は、『UltraScale アーキテクチャコンフィギュレーションユーザーガイド』 (UG570) [参照 2] を参照してください。

IP が使用するコンフィギュレーションプリミティブ (ICAP および FRAME_ECC) をサンプルデザインに配置した場合、このインターフェイスはコアレベルで外部に現れます。

UART

モニターインターフェイスで使用するバイトストリーム ASCII コードのシリアライズとデシリアライズを実行する UART ヘルパーブロックへのインターフェイス。システムとコントローラーの通信にはこのインターフェイスの使用を推奨します。

サポートレベルサポートラッパーレベル

フェッチ

コントローラーが外部ソースからデータを要求する手段として使用するインターフェイス。

注記: エラー分類機能を有効にした場合のみ

利用できます。


SPI

外部 SPI フラッシュからエッセンシャルビットのデータを取得する SPI フラッシュマスターヘルパーブロックへのインターフェイス。

注記: エラー分類機能を有効にした場合のみ

利用できます。

サポートレベルサポートラッパーレベル

表 2‐14: インターフェイスと階層レベル (続き)

インターフェイス説明

階層レベル

コンフィギュレーションプリミティブを

サンプルデザインに配置


表 2‐15: ICAP インターフェイスの信号

名前センス方向説明

icap_o[icap_width – 1:0] High 入力 ICAP の O 出力を受信します。変数 icap_width は 32 です。

icap_csib Low 出力 ICAP の CSIB 入力を駆動します。

icap_rdwrb Low 出力ICAP の RDWRB 入力を駆動します。読み出し (アクティブ High) または書き込み (アクティブ Low) セレクト入力。

icap_i[icap_width – 1:0] High 出力 ICAP の I 入力を駆動します。変数 icap_width は 32 です。

icap_clk エッジ入力

デザインのクロックを受信します。この同じクロックを ICAP の CLK 入力とする必要があります。このクロック周波数は、ターゲットデバイスのデータシートに記載された ICAP 入力クロックの要件を満たしている必要があります。






システムクロックインターフェイス

システムクロックインターフェイスは、 ICAP および SEM Controller にシステムレベルクロックを供給するために使用します。クロック信号は内部でグローバルクロックバッファーを経由してすべての同期ロジックセルへ分配されます。このインターフェイスはサポートラッパーレベルで利用できます。

このインターフェイスの詳細は、第 3 章の「システムクロックインターフェイス」を参照してください。

ICAP アービトレーションインターフェイス

ICAP アービトレーションインターフェイスは、 SEM Controller から ICAP へのアクセスの管理、および ICAP をほかのブロックと共有する際のアクセスの安全なハンドオフを簡単に実装できるようにするためのものです。このインターフェイスは、ユーザー定義の ICAP アービタと併用するのが理想です。

このインターフェイスの詳細は、第 3 章の「ICAP アービトレーションインターフェイス」を参照してください。

icap_prdone Low 入力 ICAP の PRDONE 出力を受信します。

icap_prerror High 入力 ICAP の PRERROR 出力を受信します。

icap_avail High 入力 ICAP の AVAIL 出力を受信します。

表 2‐16: システムクロックインターフェイスの信号


clk High 入力 ICAP および SEM Controller を駆動するクロック入力。

表 2‐17: ICAP アービトレーションインターフェイスの信号


cap_gnt High 入力

ICAP アービタに接続して使用します。この信号をアービタでアサートして、 SEM Controller に ICAP へのアクセス許可が与えられたことを通知します。いったんアサートした cap_gnt は、 cap_req がディアサートされるまでアサートしたままにしてください。

アービトレーションが必要ない場合は、この信号を常に 1 に接続します。

cap_rel High 入力

ICAP アービタに接続して使用します。この信号は、別のコンポーネントが ICAP へのアクセスを要求しているすべてのクロックサイクルで、アービタによってアサートされます。 1 にセットされた場合、 cap_req が 0 に戻るまで、この信号は 1 を保持する必要があります。

この信号は、できるだけ早期の安全なタイミングで ICAP の制御を放棄する必要があることを IP に示します。

アービトレーションが必要ない場合は、この信号を常に 0 に接続します。

cap_req High 出力ICAP アービタに接続して使用します。この信号は、 ICAP に転送するデータがあるすべてのクロックサイクルで、 IP によってアサートされます。

表 2‐15: ICAP インターフェイスの信号 (続き)







FRAME_ECC インターフェイス

FRAME_ECC インターフェイスは、 SEM Controller と FRAME_ECC プリミティブをポイントツーポイントで接続します。 FRAME_ECC プリミティブを通じて FPGA コンフィギュレーションシステムのソフトエラー検出機能を監視できます。 UltraScale+ SSI デバイスでは、 FRAME_ECC インターフェイスはデバイスの各 SLR に 1 つずつあります。この場合、 FRAME_ECC インターフェイスの信号名には、接頭辞「slr<#>_」が付きます。この SLR 番号は、FRAME_ECC プリミティブをどのハードウェア SLR に配置するかを示します。

ステータスインターフェイス

ステータスインターフェイスは、現在のコントローラーの動作を抽象度の高い形式にデコードした各種信号を出力します。

UltraScale+ SSI デバイスでは、 SLR ごとに個別の status_heartbeat 信号があります。これらの信号名には、接頭辞「slr<#>_」が付きます。

このインターフェイスの詳細は、第 3 章の「ステータスインターフェイス」を参照してください。

表 2‐18: FRAME_ECC インターフェイスの信号


fecc_eccerrornotsingle High 入力 FRAME_ECC の ECCERRORNOTSINGLE 出力を受信します。

fecc_eccerrorsingle High 入力 FRAME_ECC の ECCERRORSINGLE 出力を受信します。

fecc_endofframe High 入力 FRAME_ECC の ENDOFFRRAME 出力を受信します。

fecc_endofscan High 入力 FRAME_ECC の ENDOFSCAN 出力を受信します。

fecc_crcerror High 入力 FRAME_ECC の CRCERROR 出力を受信します。

fecc_farsel[1:0] High 出力 FRAME_ECC の FARSEL 入力を送信します。

fecc_far[far_width – 1:0] High 入力FRAME_ECC の FAR 出力を受信します。 UltraScale デバイスをターゲットとする場合、変数 far_width の値は 26 です。それ以外のアーキテクチャでは、変数 far_width の値は 27 です。

表 2‐19: ステータスインターフェイスの信号


status_heartbeat High 出力

この信号は、 status_observation、 status_detect_only、status_diagnostic_scan のいずれかがアサートされている間有効です。コンフィギュレーションフレームを 1 フレーム読み出すたびに 1 サイクルの High パルスが出力されます。この信号を使用して外部ウォッチドッグタイマーを実装すると、ソフトエラーによるコントローラーまたはクロック分配の動作停止を検出できます。 status_observation、 status_detect_only、status_diagnostic_scan がすべてディアサートされている場合、このハートビート信号の動作は未定義です。

UltraScale+ SSI ソリューションの場合、 status_observation、status_detect_only、または status_diagnostic_scan がアサートされている間のみすべての SLR の status_heartbeat がアクティブです。これは、モノリシックソリューションの場合の動作と同じです。

status_initialization High 出力この信号は、デザインが動作を開始した後に 1 回だけ発生するコントローラー初期化の間アクティブです。






status_heartbeat 出力は、コントローラーがアクティブであることを示します。コントローラーはソフトエラーを軽減するためのものですが、それ自体もソフトエラーの影響を受ける可能性があります。たとえば、コントローラーのクロックがソフトエラーによって停止する可能性もあります。このような場合、ユーザーは status_heartbeat 信号の停止を検出して対策をとることができます。アイドルステートでは、すべての status_heartbeat が停止します。監視、診断スキャン、および検出ステートでは、すべての status_heartbeat がトグルします。

ヒント : コントローラー自体がソフトエラーの影響を受けた場合の実行可能な対策の詳細は、第 3 章の「システム」を参照してください。

status_observation High 出力

この信号は、コントローラーがビットアップセットを監視している間アクティブです。エラー検出後、コントローラーがハードウェアに情報を問い合わせている間もこの信号はアクティブのままです。

status_correction High 出力この信号は、コントローラーがエラーを訂正している間アクティブです。訂正を無効にした場合も、コントローラーが訂正ステートを遷移中はアクティブになります。

status_classification High 出力この信号は、コントローラーがエラーを分類している間アクティブです。エラー分類を無効にした場合も、コントローラーが分類ステートを遷移中はアクティブになります。

status_injection High 出力

この信号は、コントローラーがエラーを挿入している間アクティブです。エラー挿入が完了し、コントローラーが次のエラーを挿入できる状態または監視ステートに復帰可能な状態になると、この信号は非アクティブに戻ります。

status_detect_only High 出力

この信号は、コントローラーが検出スキャンを実行している間アクティブです。エラーが検出されてスキャンが中断すると、コントローラーはアイドルステートに移行し、この信号は非アクティブに戻ります。

status_diagnostic_scan High 出力

この信号は、コントローラーが診断スキャンを実行している間アクティブです。デバイスのコンフィギュレーションメモリ全体に対して 1 回の診断スキャンが完了すると、コントローラーはアイドルステートに移行し、この信号は非アクティブに戻ります。この機能はリアルタイムのソフトエラー軽減には使用せず、診断ツールとしてのみ使用してください。

status_essential High 出力

この信号は、エラー分類ステータス信号です。分類ステート終了前に、コントローラーはエラーがエッセンシャルビットで発生したかどうかをこの信号で示します。その後、コントローラーは分類ステートを終了します。

この信号はスティッキーで、コントローラーが次にエラーを検出して分類するまで更新されません。

status_uncorrectable High 出力

この信号は、エラー訂正ステータス信号です。訂正ステート終了前に、コントローラーはエラーが訂正可能かどうかをこの信号で示します。その後、コントローラーは訂正ステートを終了します。

表 2‐19: ステータスインターフェイスの信号 (続き)







status_initialization、 status_observation、 status_correction、 status_detect_only、status_diagnostic_scan、 status_classification、 status_injection 出力はコントローラーの現在の状態を示します。 status_uncorrectable および status_essential 出力は、検出したエラーの性質を示します。

上記の 7 つのコントローラーステート出力から、さらに 2 つのコントローラーステートをデコードできます。 7 つの信号すべてが Low の場合、コントローラーはアイドルステート (いつでも動作を再開可能な非アクティブ状態) です。7 つの信号すべてが High の場合、コントローラーは重大エラーのため非アクティブになり動作を停止しています。

コマンドインターフェイス

コマンドインターフェイスには、コンフィギュレーションメモリにビットエラーを挿入するようコントローラーにコマンドを送信するための入力があります。

このインターフェイスの詳細は、第 3 章の「コマンドインターフェイス」を参照してください。

コマンドインターフェイスを使用すると、エラー挿入やソフトウェアリセットを簡単に実行できます。このインターフェイスの使用方法と有効なコマンドコードの詳細は、第 3 章の「コマンドインターフェイス」を参照してください。

注記: ユーザーとコントローラーの通信には、より高機能なモニターインターフェイスの使用を推奨します。第 3 章の「モニターインターフェイス」を参照してください。

このインターフェイスの使用は完全に任意です。使用しない場合は、すべての入力を Low に接続できます。

表 2‐20: コマンドインターフェイスの信号


command_strobe High 入力

コマンド要求を示すコマンド制御信号です。command_busy が Low のとき、 command_strobe 信号を icap_clk に同期して 1 サイクルだけ High にパルスすると同時に、 command_code 入力に有効なコマンドを入力します。

command_code[width – 1:0] High 入力

コントローラーが実行するコマンドを指定します。command_strobe がアクティブとしてサンプルされると同時にこのバスの値が取り込まれます。 command_code ポートの幅はターゲットアーキテクチャにより異なります。 UltraScale デバイスでは、幅は 40 です。それ以外のアーキテクチャでは、幅は 44 です。

command_busy High 出力コントローラーがコマンドを処理できる状態かどうかを示します。 command_strobe は command_busy が Low の場合のみアサートしてください。






モニターインターフェイス

モニターインターフェイスはコントローラーの詳細なステータスを受信する手段としてのほか、コントローラーとの通信手段としても使用できます。コントローラーがモニターインターフェイスから読み出すコマンド、およびモニターインターフェイスに書き込むステータス情報はいずれも ASCII 文字列です。モニターインターフェイスは、ステータスインターフェイスおよびコマンドインターフェイスのステータスおよびコマンド機能を含みます。このインターフェイスは、コアレベルで常に利用可能です。サンプルデザインでは、このインターフェイスは UART ヘルパーブロックに接続されます。

後で必要になったときに IP の動作を簡単にデバッグできるように、少なくともこのインターフェイスで送信されるステータスを FIFO に格納することを推奨します。詳細は、第 3 章の「モニターインターフェイス」を参照してください。

UART インターフェイス

ユーザーの便宜のため、システムレベルサンプルデザインにおけるモニターインターフェイスは UART ヘルパーブロックに接続されており、モニターインターフェイスを UART インターフェイス経由でプロセッサブロックに簡単に統合できます。この UART インターフェイスは、コントローラーからのステータス情報の受信、コントローラーへのエラー挿入コマンドの送信、および挿入したエラーがコントローラーによって検出および訂正されたことの確認に使用できます。

UART ヘルパーブロックは、コントローラーが生成したステータス情報 (1 バイトの ASCII コード ) をシリアライズしてシリアル送信します。同様に、 UART ヘルパーブロックは入力されたコマンド情報 (ASCII コードのビットストリーム) をデシリアライズしてパラレルデータとしてコントローラーに送信します。

UART ヘルパーブロックは標準のシリアル通信プロトコルを使用します。このヘルパーブロックは同期およびオーバーサンプリングロジックを備えており、同じ公称ボーレートで動作する非同期シリアルデバイスをサポートします。詳細は、第 3 章の「UART インターフェイス」を参照してください。

このヘルパーブロックが提供するインターフェイスには、エンベデッドマイクロコントローラーからデスクトップコンピューターまで幅広いデバイスを直接接続できます。システム要件によっては外部レベル変換器が必要です。

表 2‐21: モニターインターフェイスの信号


monitor_txdata[7:0] High 出力コントローラーからのパラレル送信データ。

monitor_txwrite High 出力パラレル送信データが有効であることを示す書き込みストローブ。

monitor_txfull High 入力この信号で、ヘルパーブロックからコントローラーに対する送信チャネルのフロー制御を実装します。

monitor_rxdata[7:0] High 入力ヘルパーブロックからのパラレル受信データ。

monitor_rxread High 出力パラレル受信データの受信完了を通知する読み出しストローブ。

monitor_rxempty High 入力この信号で、ヘルパーブロックからコントローラーに対する受信チャネルのフロー制御を実装します。

表 2‐22: UART インターフェイスの信号


uart_tx Low 出力シリアル送信データ。

uart_rx Low 入力シリアル受信データ。






フェッチインターフェイス

フェッチインターフェイスは、コントローラーが外部ソースからデータを要求する手段として使用します。

エラー分類中、コントローラーは 1 フレーム分のエッセンシャルビットデータを必要とすることがあります。コントローラーは、必要なデータを記述したコマンドをバイナリ形式でフェッチインターフェイスに書き込むよう設計されています。外部ソースはこの情報を使用してデータをフェッチし、フェッチインターフェイスに返す必要があります。

エラー分類を有効にすると、このインターフェイスは常にコアレベルで利用できます。サンプルデザインでは、このインターフェイスは SPI フラッシュマスターヘルパーブロックに接続されており、このインターフェイスを SPI インターフェイスを経由してエッセンシャルビットデータが格納された外部 SPI フラッシュに接続します。

このインターフェイスの詳細は、第 3 章の「フェッチインターフェイス」を参照してください。

SPI インターフェイス

ユーザーの便宜のため、システムレベルサンプルデザインにおけるフェッチインターフェイスは SPI フラッシュマスターヘルパーブロックに接続されており、 SPI インターフェイス経由で外部 SPI フラッシュからエッセンシャルビットデータを取得します。このインターフェイスが存在する場合、システムレベルサンプルデザインの SPI フラッシュマスターヘルパーブロックの機能は SPI バスマスターに固定されます。

このヘルパーブロックは、アドレスとバイトカウントで構成されるフェッチインターフェイス経由でコントローラーからコマンドを受け取ります。このヘルパーブロックは、要求されたデータを外部 SPI フラッシュからフェッチするための SPI バストランザクションを生成します。フェッチしたデータは、コントローラーが受信できるフォーマットにヘルパーブロックによって変換されます。

このヘルパーブロックは標準 SPI バスプロトコルを使用し、「モード 0」と呼ばれるも一般的なモード (CPOL = 0、CPHA = 0) を実装します。SPI バスのクロック周波数はシステムレベルサンプルデザインのシステムクロックの 1/2 に固定されます。詳細は、第 3 章の「SPI インターフェイス」を参照してください。

表 2‐23: フェッチインターフェイスの信号


fetch_txdata[7:0] High 出力コントローラーからのパラレル送信データ。

fetch_txwrite High 出力パラレル送信データが有効であることを示す書き込みストローブ。

fetch_txfull High 入力この信号で、ヘルパーブロックからコントローラーに対する送信チャネルのフロー制御を実装します。

fetch_rxdata[7:0] High 入力ヘルパーブロックからのパラレル受信データ。

fetch_rxread High 出力パラレル受信データの受信完了を通知する読み出しストローブ。

fetch_rxempty High 入力この信号で、ヘルパーブロックからコントローラーに対する受信チャネルのフロー制御を実装します。

fetch_tbladdr[31:0] High 入力この信号で、外部ソースにあるコントローラーデータテーブルの開始アドレスを指定します。






このヘルパーブロックが提供するインターフェイスには、幅広い種類の標準 SPI フラッシュを直接接続できます。システム要件によっては外部レベル変換器が必要です。

補助インターフェイス

補助インターフェイスは、コンフィギュレーションメモリのスキャンではコントローラーが直接監視できない場所で発生したソフトエラーイベントをコントローラーに通知する手段として使用します。詳細は、第 3 章の「補助インターフェイス」を参照してください。

表 2‐24: SPI インターフェイスの信号


spi_c エッジ出力外部 SPI フラッシュの SPI バスクロック。

spi_d High 出力外部 SPI フラッシュの SPI バス「マスター出力、スレーブ入力」信号。

spi_s_n Low 出力外部 SPI フラッシュの SPI バスセレクト信号。

spi_q High 入力外部 SPI フラッシュの SPI バス「マスター入力、スレーブ出力」信号。

表 2‐25:補助インターフェイスの信号


aux_error_cr_ne High 入力訂正可能な非エッセンシャルエラーを示す補助入力。

aux_error_cr_es High 入力訂正可能なエッセンシャルエラーを示す補助入力。

aux_error_uc High 入力訂正不能エラーを示す補助入力。





第 3章

コアを使用するデザインこの章では、コアを使用した設計をより容易にするためのガイドラインおよび追加情報を紹介します。

一般的なデザインガイドライン

このセクションでは、 UltraScale™ Architecture SEM Controller とユーザーアプリケーションロジックを組み合わせて完全に機能するデザインを作成する手順を説明します。

重要: この章に記載するすべての設計手順がすべてのインプリメンテーションで必要とは限りません。このマニュアルのロジックデザインガイドラインに注意深く従ってください。

スターティングポイントとしてサンプルデザインを使用

SEM Controller コアに付属するサンプルデザインを FPGA にインプリメントして、コントローラーの動作の理解に役立てることができます。

システムレベルサンプルデザインは SEM Controller と各種プリミティブおよびヘルパーブロックをカプセル化しており、これらのプリミティブとヘルパーブロックが SEM Controller とほかのデバイスを接続するインターフェイスとしての役割を果たします (106 ページの図 5-1 参照)。

スタックドシリコンインターコネクト (SSI) デバイスをターゲットにしたデザインの場合、各 SLR でソフトエラーを軽減する方法の例がシステムレベルサンプルデザインに含まれています。少なくとも、このサンプルを参考にしてください。コアに付属するサンプルデザインの詳細は第 5 章「サンプルデザイン」を参照してください。システムレベルのポートソリューションについては第 2 章の「ポートの説明」を参照してください。

ヒント : <component_name>_support_wrapper.v にはソフトエラー軽減ソリューションに必須のロジックがすべて含まれているため、すべてのサブモジュールと一緒にユーザーデザインに統合することを推奨します。このソリューションは、完全に検証済みの状態で提供されています。 43 ページの「構造オプション」を参照してください。





第 3 章: コアを使用するデザイン

難易度を把握

SEM Controller デザインのインプリメントは困難なこともありますが、その難易度は次の要因によっても変化します。

• 大システムクロック周波数

• ターゲットデバイスアーキテクチャ

• アプリケーションの性質

• デバイスの密集度

すべての SEM インプリメンテーションでは、システム性能の要件に注意を払う必要があります。このため、設計サイクルの早期段階で IP を統合することを強く推奨します。パイプライン処理、ロジックマップ、配置制約、およびロジック複製は、システム性能を向上させる適な手段です。

重要: SEM Controller と ICAP および FRAME_ECC プリミティブの間にパイプラインレジスタを追加すると SEM Controller の動作に悪影響が及ぶため、この追加は避けてください。

レジスタの使用

FPGA デザインのタイミングをシンプルにしたり、システム性能を向上させるには、ユーザーアプリケーションとコア間のすべての入力と出力にレジスタを使用してください。つまり、ユーザーアプリケーションからのすべての入力と出力はフリップフロップを介すことになります。信号のレジスタへの格納はすべてのパスで可能とは限りませんが、これによってタイミング解析が容易になり、またザイリンクスツールでのデザインの配置配線も簡単になります。

タイミングクリティカルな信号を認識

コアのサンプルデザインに付属する XDC ファイルは、クリティカルな信号を識別して適用すべきタイミング制約を特定するのに役立ちます。詳細は、第 4 章の「コアへの制約」を参照してください。

許可された変更のみ実行

SEM Controller コアをユーザーが変更することはできません。これは、システムタイミングへの違反を防ぐためです。ユーザー設定が可能なのは、 SEM Controller コアの生成時に Vivado® Design Suite のオプションで指定可能なコンフィギュレーションのみです。第 4 章の「コアのカスタマイズおよび生成」を参照してください。

早期の統合およびバリデーション

SEM IP コアはプログラマブルロジックのフットプリントをわずかしか占有しませんが、プログラマブルロジックのコンフィギュレーションメモリシステムを活性化します。できるだけ早期にシステムの統合とバリデーションを行い、可能な限り多くの機能を段階的に追加していくと、代表的なワークロードでのシステム評価の時間を大限に確保できます。この手法は、デザイン再利用と IP ベース設計を促進する一般的なボトムアップ設計アプローチを補完するものとして推奨されます。

詳細は、 102 ページの「統合およびバリデーション」を参照してください。

IP チェックリストの確認

SEM IP を使用する際の注意点をチェックリスト形式でわかりやすくまとめたものを用意しています。付録 F 「IP デザインのチェックリスト」を参照してください。






構造オプション

コンフィギュレーションプリミティブおよび利用可能なヘルパーブロックをどこに配置するかは、 [Customize IP] ダイアログボックスの [Structural Options] で選択できます。これらのオプションで IP 境界の順列を変更し、提供される IP ソリューションをシンプルなインターフェイスのスタンドアロンコアとして動作させるか、大規模なデザインの一部として動作させて SEM Controller のインターフェイスへのアクセスを容易にするかを選択できます。これらのオプションにより、 IP コアをさまざまな用途に柔軟に利用できるようになると同時に、ソリューションをユーザーデザインに統合する際の HDL 修正範囲が小限に抑えられます。

階層レベルには次の 2 つがあります。

• <component_name>_support

• <component_name>_support_wrapper

図 3-1 および図 3-2 に、コンフィギュレーションプリミティブをコアに含めた場合とサンプルデザインに含めた場合の 2 つの階層を示します。図中の <component_name> には生成されたコアの名前が入ります。

これら 2 つの階層の違いは、コアの境界およびヘルパーブロックがインスタンシエートされる場所にあります。これは、 Vivado 統合設計環境 (IDE) で SEM Controller をカスタマイズする際に [Structural Options] で設定します。

注記: UltraScale SSI デバイスをターゲットにしたインプリメンテーションでは、サンプルデザインに含まれるコンフィギュレーションプリミティブのみがサポートされます。


図 3‐1: コンフィギュレーションプリミティブをコアに配置

Support Layer (<component_name>, DCP)

System-Level Solutions (<component_name>_support_wrapper)

System-Level Design Example

VIO

VIO

VIO

VIO

BUFGCE

UART Helper Block

SPI Flash Master Helper Block

SEM Controller

Configuration Logic

ICAP FRAMEECC






ヒント : <component_name>_support_wrapper には全体的なソフトエラー軽減ソリューションに必須のロジックがすべて含まれており、完全に検証済みのものが提供されているため、この階層レベルをデザインに統合することを推奨します。

重要: このサンプルデザインを統合しない場合は、後述する各インターフェイスのシステムレベル要件および推奨事項に従ってください。


ICAP および FRAME_ECC プリミティブへのアクセスを必要とするロジックがほかに存在しない場合はこのオプションを選択します。この場合、これらのプリミティブはコアに配置され、プリミティブと SEM Controller は自動的に接続されるため、コアポートとしては外部に現れません。

注記: UltraScale SSI デバイスをターゲットにしたデザインの場合、このオプションは利用できません。

コンフィギュレーションプリミティブをサンプルデザインに配置

ICAP および FRAME_ECC プリミティブへのアクセスを必要とするロジックがほかに存在する場合はこのオプションを選択します。この場合、これらのプリミティブはサンプルデザイン階層にインスタンシエートされます。

ユーザーデザインと SEM Controller で ICAP を共有する方法の詳細は、ザイリンクスにお問い合わせください。


図 3‐2: コンフィギュレーションプリミティブをサンプルデザインに配置

Support layer (<component_name>_support)

System-Level Solutions (<component_name>_support_wrapper)


VIO

VIO

VIO

VIO

BUFGCE

UART Helper Block


SEM Controller(<component_name>, DCP)

Configuration Logic

ICAP FRAMEECC






インターフェイス

このセクションでは、コアをデザインに統合する方法を各インターフェイス別に説明します。各セクションでは、インターフェイスの目的、使用方法、動作、およびシステム全体への統合方法について説明します。

ICAP インターフェイス

ICAP インターフェイスは第 2 章の「ICAP インターフェイス」の説明に従って ICAP プリミティブに接続します。このインターフェイスの icap_clk ポートは IP への主要な入力クロックです。このクロックの要件については、次のセクションで説明します。

システムクロックインターフェイス

ここでは、システム入力クロックに関する推奨事項について説明します。これらの推奨事項は、 FPGA データシートに記載された FPGA コンフィギュレーションシステムに使用されるクロック信号の要件に基づいて決定しています。

• デューティサイクル: 45% 以上、 55% 以下

入力クロックの周波数が高いほど、ソリューションのエラー軽減レイテンシは小さくなります。したがって、周波数はなるべく高い方が理想です。入力クロックの大周波数を決定する際には、いくつかの重要な要因を考慮する必要があります。

• FPGA コンフィギュレーションシステム (ICAP) の大クロック周波数を超えないこと。具体的な数値は、ターゲットデバイスのデータシートを参照してください。

• スタティックタイミング解析ツールで報告された大クロック周波数を超えないこと。通常、この条件が制限となることはありません。

システムレベルサンプルデザインを使用する場合、完全同期設計手法に基づき、クロック周波数を選択する際には外部インターフェイスのタイミングとの関係も考慮する必要があります。

• 専用の SPI フラッシュを使用して分類データを格納する分類機能をそのまま使用する場合:

° SPI バスの大クロック周波数を決定するには、 SPI バスタイミングバジェットの評価が必要です。解析例は付録 G 「SPI バスタイミングバジェット」を参照してください。

° SPI バスクロックは入力クロックの 1/2 です。したがって、入力クロックは SPI バスの大クロック周波数の 2 倍以下とする必要があります。

• UART ヘルパーブロックと UART インターフェイスを使用してコントローラーと通信する場合:

° 入力クロックとシリアルインターフェイスのボーレートは、 16 の整数倍の関係です。標準ボーレートが必要な場合、非常に高いボーレートまたは非常に低い入力クロック周波数では解空間が限られることがあります。

° 解析例は「スイッチング動作」を参照してください。






システムレベル要件

システムクロックはコントローラーにとって非常に重要であるため、なるべく信頼性の高いクロックソースから供給する必要があります。大限の信頼性を確保するには、クロックソースとコントローラーをできるだけ直接接続します。つまり、目的の周波数の外部オシレーターを使用し、グローバルクロックバッファーに直接関係するピンに直接接続します。

このクロックパスにその他のロジックやインターコネクトを含めると、クロックとコントローラーの接続を制御するために使用するコンフィギュレーションメモリの数が増大します。この結果、コントローラーの推定 FIT に悪影響が及びます。この影響はそれほど大きくはありませんが、設計負担がそれほど増えないのであれば、信頼性向上のために実行しておくことを推奨します。

このクロックパスにクロック管理ブロックやロジックベースのクロック分周器などの余分なロジックが存在する場合、過渡中を含め FPGA コンフィギュレーションシステムの大クロック周波数とシステムレベルサンプルデザインおよびコントローラーの大クロック周波数の要件に違反しないようにデザインで保証する必要があります。

たとえば遅延ロックループ (DLL) や位相ロックループ (PLL) のクロック出力は、これらの機能がロックするまでの間、仕様外の値となることがあります。この問題に対処するには、イネーブル信号を備えたグローバルクロックバッファー (BUFGCE) を使用し、ロックが完了した後でグローバルクロックバッファーを有効にするという方法があります。たとえばサンプルデザインのシステムレベルクロックは BUFGCE のクロックイネーブルを High に接続して分配しています。

システムレベルサンプルデザイン、コントローラー、およびコンフィギュレーションシステムはすべてスタティックです。つまり、 FPGA コンフィギュレーションシステムの仕様上の大許容周波数、またはシステムレベルサンプルデザインおよびコントローラーの大クロック周波数のいずれか低い方まで任意のクロック周波数を使用できます。ただしクロックレートは高い方がエラー軽減を高速に実行できるという利点があります。

これらの要因を考慮して、すべての条件を満たす入力クロック周波数を選択します。

FRAME_ECC インターフェイス

FRAME_ECC インターフェイスは「FRAME_ECC インターフェイス」の説明に従って FRAME_ECC プリミティブに接続します。

UltraScale+™ SSI デバイスには、各 SLR に専用の FRAME_ECC インターフェイスがあります。これらのインターフェイスは、同じ SLR に配置された FRAME_ECC プリミティブに接続する必要があります。






ICAP アービトレーションインターフェイス

このインターフェイスは、 ICAP プリミティブをシステムの複数のファンクションで共有する場合や、 SEM Controller から ICAP へのアクセスを管理する必要がある場合に使用すると便利です。複数のファンクションから ICAP へのアクセスを制御し、 SEM Controller から ICAP へのアクセスタイミングを管理するにはこのインターフェイスをユーザー定義の ICAP アービタで駆動するのが理想です。 SEM Controller で ICAP を共有する方法の詳細は、ザイリンクスにお問い合わせください。

図 3-3 に、ICAP アービトレーションインターフェイスの信号を変化させた場合の SEM Controller の動作を示します。開始点は次の 2 つがあります。

• コントローラーが監視、検出、診断スキャンステートの場合 (図の開始点 1)

• コンフィギュレーション後にコントローラーが初めて起動した場合 (図の開始点 2)

白のブロックは、コントローラーが独占的に ICAP にアクセスするステートを示します。グレーのブロックはコントローラーが ICAP にアクセスしないステートを示します。


図 3‐3: ICAP アービトレーションのスイッチング動作フローチャート

Starting point 1: Controller in Observation or Detect only or

Diagnostic ScanStateb

Arbiter setscap_rel = 1?

Controller in Idle Statea

Controllers checks (cap_gnt = 0 and cap_rel = 0)?

a

Controller Start Boot Processa

Arbiter sets (cap_gnt = 1 and cap_rel = 0)?a

Controller in Initialization State

Controller in State After Initializationb

True,

Controller transitions to Idle state

True

True, Controller transitions to

Initialization state

False

False

False

Notes:a SEM controller continues to be Idle state. Now, the controller has no access to the ICAP primitive. b See Table 2-1.c When IP is configured in "Detect-only" mode, cap_rel should not be asserted when the IP is transitioning from Initialization to Detect-only state. If this occurs, the IP does not release it's access to ICAP correctly. To workaround this limitation, do not assert cap_rel when the IP is in Idle and the previous state is Initialization.

Arbiter continues to assert cap_rel = 1

Controller sets

cap_req = 0a

Controller sets cap_req = 1a

Arbiter should now set cap_gnt = 0

Starting point 2: Clock provided to IP after

configurationa

Limitations to cap_rel

assertion c

X16281-111517






ICAP アービトレーションインターフェイスの cap_rel および cap_gnt 信号を操作してコントローラーから ICAP へのアクセスを解放した場合、アクセスが再び許可されるとコントローラーは再起動して初期化を実行します (ソフトウェアリセットと同じ動作)。コントローラーから ICAP へのアクセスが停止されている間にコンフィギュレーションメモリまたは設定が変更されたかどうかをコントローラーは知ることができないため、コントローラーから ICAP へのアクセスが再び許可された後にコントローラーの正常動作を保証するには、これがも安全な方法となります。

この動作が好ましくない場合は、次の手順を手動で実行してコントローラーから ICAP へのアクセスを停止できます。

1. コントローラーをアイドルステートへ移行させるコマンドを実行します。

2. ICAP へのアクセス権を取得して目的の動作を実行します。

3. 目的の動作を完了して ICAP へのアクセス権を解放したら、コントローラーを監視ステートや検出ステートなど目的のステートへ移行させるコマンドを実行します。

注記:上記の手順を実行してもコントローラーは再起動/初期化されませんが、 ICAP にアクセスして処理を実行中、コンフィギュレーションメモリおよび設定が変更されないようにユーザーが責任を持つ必要があります。これは、 SEM Controller の正常動作を継続する上で非常に重要です。

ICAP 共有機能を使用しない場合は、このインターフェイスの入力を次のように接続します。

• cap_gnt = High

• cap_rel = Low

スイッチング動作

図 3-4 にスイッチ特性を示します。初にコントローラーがブートします。次に、コントローラーが cap_req 信号をアサートして ICAP へのアクセスを要求します。コントローラーは、 ICAP にアクセスする必要がある間、この信号をアサートし続けます。その後、外部 ICAP アービタによって cap_gnt 信号がアサートされ、コントローラーに ICAP の制御が与えられたことを通知します。 cap_gnt がアサートされるとコントローラーは初期化ステートへ移行します。初期化が完了すると、コントローラーは監視ステートへ移行します。

コントローラーが監視ステートへ移行した後、 ICAP アービタは cap_rel 信号をアサートし、コントローラーに対して ICAP を解放するよう要求します。その後、コントローラーは自動的にアイドルステートへ移行し、 cap_req 信号をディアサートします。次に、 ICAP アービタは cap_gnt および cap_rel 信号をディアサートします。次に、コントローラーは cap_req 信号をアサートしてブートプロセスを開始します。 cap_gnt がアサートされると、コントローラーは初期化ステートへ移行します。初期化が完了すると、コントローラーは監視ステートへ移行します。



第 3 章

:コア

を使用

するデザ

イン

UltraScale Architecture SEM

Controller v3.1

49

PG187

2019 年

5 月

22 日

japan

.xilinx.com

シス

テム

レベル

要件

この

イン

ター

フェ

イスは、

ICA

P に

アクセ

スす

る必要

のあ

るブ

ロックが複数存在す

るシ

ステ

ムで使用

して

くだ

さい。

この

ようなシ

ステ

ムでは、複数

のブ

ロック間

で I

CA

P のハ

ンドオ

フを管理お

よび制御す

るための

アー

ビタを設計す

る必要

があ

ります。

X-Re

f Tar

get -

Figu

re 3-

4

図 3‐4:ICAP ア

ービ

トレー

ションの

スイ

ッチ

ング動作

Boo

tIn

itial

izat

ion

Obs

erva

tion

Idle

Boo

tIn

itial

izat

ion

Obs

erva

tion

icap

_clk

cap_

req

cap_

gnt

cap_

rel

stat

us_i

nitia

lizat

ion

stat

us_o

bser

vatio

n

Boot

Initi

aliz

atio

nO

bser

vatio

nId

leBo

otIn

itial

izat

ion

Obs

erva

tion







ステータスインターフェイスからは、ロジック信号に基づくイベントレポートが直接出力されます。ステータスインターフェイスは多くの用途に利用できますが、その使用は必須ではありません。このインターフェイスで報告される情報は、次の 3 つの種類に分類されます。

• ステート – コントローラーの現在の動作を示します。

• フラグ – 検出したエラーのタイプを特定します。

• ハートビート – コンフィギュレーションメモリのスキャンが動作中であることを示します。

システムレベルサンプルデザインを UltraScale SSI デバイスにインプリメントした場合、各 SLR に 1 つずつコントローラーインスタンスがあるため、ステータスインターフェイスも SLR ごとに個別に存在します。

システムレベルサンプルデザインを UltraScale+ SSI デバイスにインプリメントした場合、コントローラーインスタンスは 1 つだけで、これがマスター SLR の ICAP と各 SLR の FRAME_ECC プリミティブに接続されます。このため、ステータスインターフェイスは 1 つしかありませんが、コンフィギュレーションメモリは各 SLR で並列にスキャンされるため、ハートビート信号は n 数だけ存在します (n は SLR の数)。

インプリメンテーションにかかわらず、ほとんどの場合、ステータスインターフェイスの信号は必要なものだけを FPGA の I/O ピンに接続します。システムレベルサンプルデザインでは、すべての信号を I/O ピンに接続しています。

ステータス信号は外部でインジケーターに接続して表示することも、別のデバイスに接続して観測することもできます。別のデバイスに接続してイベント報告を正しく取り込むには、ステータスインターフェイスのスイッチング動作を考慮する必要があります。

特に UltraScale SSI デバイスへのインプリメンテーションでは信号の数が多くなるため、ステータスインターフェイスは複雑になりがちです。ただしステータスインターフェイスでしか取得できないのはハートビートイベントのみです。それ以外の情報はモニターインターフェイスでも得られます。

ステータスインターフェイスの信号は、システムレベルサンプルデザインに供給されるクロックを使用してコントローラー内部の順次ロジック処理で生成されます。このため、パルス幅は常にクロックサイクルの整数倍です。

ステート

SEM Controller には 9 つの有効なステートがあります。

• 初期化

• 監視

• 訂正

• 分類

• アイドル

• 挿入

• 検出

• 診断スキャン

• 重大エラー






図 3-5 ～図 3-7 に、各 IP モードにおける有効なステートとステート遷移を示します。


図 3‐5:軽減 (+ テスト ) モードの場合の有効なステート遷移図

Notes:a status_* consists of status_observation, initialization, correction, injection, classification, detect only, and diagnostic_scan (omitting the signal that has already been defined in the state).b Only available in Mitigation and testing mode.c Only SC flag is updated before IP exits a state.d This is a true Idle state where the IP is not scanning any configuration frames.Transition to Fatal Error state is not shown.

Initializationstatus_initialization = 1,

status_* = 0 a

Observationstatus_observation = 1,

status_* = 0 a

Correctionstatus_correction = 1,

status_* = 0 a

Set FC flag before exiting

Classificationstatus_classification = 1,

status_* = 0 a

Set FC flag before exiting

Error Injectionb

status_injection = 1, status_* = 0 a

Error detected Classify error

Correctable Error

Uncorrectable Error

Error injection commandc

True

Idle commandObservation

commandSoftware reset

Complete Initialization

All other commands

All other commands

Diagnostic Scanstatus_diagnostic_scan = 1,

status_* = 0 a

Diagnostic Scan Command

True(after a single device sweep

completes)

Detect-only Command

Idle Command

or Error Detected

Idled

status_* = 0 a

Detect Onlystatus_detect_only= 1,

status_* = 0 a

Set FC flag = 60 before exiting (when error is detected)


図 3‐6:検出 (+ テスト ) モードの場合の有効なステート遷移図

Notes:a status_* consist of status_observation, initialization, correction, injection, classification, detect_only, and diagnostic_scan (omitting the signal that has already been defined in the state).b Only available in Detect and Testing mode.c This is a true Idle state where the IP is not scanning any configuration frames.SC flag is updated before IP exits a state


status_* = 0 a

Idlec

status_* = 0 aError Injectionb

status_injection = 1, status_* = 0 a

Complete initialization

Softwarereset True

Inject error

Detect Onlystatus_detect_only = 1,

status_* = 0 a


Detect-only Command

Idle Command

or Error Detected


completes)

Diagnostic Scan

Command


status_* = 0 a

X15990-030416






これらステートの遷移に関しては、モニターインターフェイスからのレポートの方が詳細な情報が得られます。詳細は、「モニターインターフェイス」を参照してください。

以降のセクションでは、各ステートの詳細について説明します。

初期化

コントローラーは FPGA のグローバルセット / リセット信号によって非アクティブな状態に置かれます。コンフィギュレーションが完了すると、 FPGA コンフィギュレーションシステムがグローバルセット / リセット信号をディアサートし、コントローラーがブートします。ブートプロセスの間、コントローラーはステータスインターフェイスの 7 つのステートビットをすべてディアサートしたまま維持します。

コントローラーはブート中に cap_gnt および cap_rel 入力をポーリングし、初期化ステートへ移行して ICAP の使用を開始できるかどうかを確認します。外部 ICAP アービタでこれら信号を駆動しない場合は、 cap_gnt 信号を High、 cap_rel を Low に接続します。

初期化ステートの間、 status_initialization は High にアサートされます。初期化ステートでは、モニターインターフェイスから出力される初期化レポートなど直接観測可能なイベント以外に、内部のハウスキーピング処理もいくつか実行されます。具体的には、次の処理が実行されます。

• 1 回目のリードバックサイクルでフレームレベルの ECC チェックサムを計算。

• 2 回目のリードバックサイクルでデバイスレベルの CRC チェックサムを計算。

初期化が完了すると、コントローラーは IP のモードに応じて監視、検出、アイドルのいずれかのステートへ移行します。


図 3‐7: その他のモードの場合の有効なステート遷移図

Notes:a status_* consist of status_observation, initialization, correction, injection, classification, detect_only, and diagnostic_scan (omitting the signal that has already been defined in the state).b Only available in Emulation mode.c This is a true Idle state where the IP is not scanning any configuration frames.SC flag is updated before IP exits a state


status_* = 0 a

Idlec

status_* = 0 aError Injectionb

status_injection = 1,

status_* = 0 aComplete

initialization

Softwarereset True

Inject error

All other commands

Detect Onlystatus_detect_only = 1,

status_* = 0 a


Detect-only Command

Idle Command

or Error Detected


completes)

Diagnostic Scan

Command


status_* = 0 a






Zynq UltraScale+ MPSoC の注意事項

Zynq® UltraScale+ MPSoC デバイスを使用するインプリメンテーションでは、 SEM Controller から ICAP インターフェイスへアクセスできるようにする必要があります。そのためには、 PS コンフィギュレーションセキュリティユニット (CSU) の pcap_ctrl レジスタの PCAP PR ビットをクリアします。

Zynq UltraScale+ MPSoC のプロセッシングシステム (PS) のブート中、PS は PCAP (プロセッサコンフィギュレーションアクセスポート ) を通じてデバイス内のコンフィギュレーションロジックにアクセスできます。このパスを利用して、 PS ブートローダーはビットストリームを Zynq UltraScale+ MPSoC のプログラマブルロジック (PL) にダウンロードします。 PS ブートローダーが完了すると、 PS による PL のパーシャルリコンフィギュレーションをサポートするために PS と PCAP がコンフィギュレーションロジックを常時制御します。

ただし、 PS と PCAP がコンフィギュレーションロジックを制御している間、 PL と ICAP はコンフィギュレーションロジックにロックしません。 SEM Controller が正しく機能するには、 ICAP 経由でコンフィギュレーションロジックにアクセスする必要があります。そのためには、 PS CSU pcap_ctrl レジスタ (pcap_ctrl、アドレス 0xFFCA3008) の pcap_pr (ビット [0]) をクリアします。 PCAP の詳細は、『Zynq UltraScale+ MPSoC テクニカルリファレンスマニュアル』 (UG1085) [参照 3] を参照してください。

PS 上で動作するソフトウェアは、必要な PCAP アクティビティをすべて完了すると PCAP_PR をクリアした後、コントローラーの icap_grant 入力に接続された GPIO をセットします。これによって、コントローラーは初期化ステートに進むことができます。 icap_grant 入力への信号は、 icap_clk 信号に正しく同期している必要があります。

この動作をソフトウェアでインプリメントする方法は、この製品ガイドでは説明しません。 SEM Controller を PS に統合する方法については、 2 つのアプリケーションノートで説明しています。『Zynq UltraScale+ デバイスへの LogiCORE SEM IP の統合』 (XAPP1298) [参照 4] および『AXI を使用した Zynq UltraScale+ デバイスへの LogiCORE SEM IP の統合』 (XAPP1303) [参照 5] を参照してください。

ベアメタルおよび Linux 環境におけるソフトウェア開発の詳細は、『Zynq UltraScale+ MPSoC ソフトウェア開発者向けガイド』 (UG1137) [参照 7] および『OS およびライブラリ資料コレクション』 (UG643) [参照 8] を参照してください。

監視 (軽減 (+ テスト ) モードのみ)

コントローラーはほとんどすべての時間を監視ステートで費やします。監視ステートの間、status_observation は High にアサートされ、コントローラーは FPGA コンフィギュレーションシステムを監視してエラーの発生を検出します。また、 ECC ベースの ROM エラーと補助インターフェイスからのエラーも監視します。

エラーが存在しておらず、コマンドインターフェイスまたはモニターインターフェイスからコマンドを受信すると、コントローラーはそのコマンドを処理します。監視ステートでサポートされるコマンドは Enter Idle と Status Report の 2 つのみです。コントローラーはそれ以外のコマンドをすべて無視します。

• Enter Idle – このコマンドはコマンドインターフェイスとモニターインターフェイスのいずれからも入力できます。これは、コントローラーをアイドル状態にしてほかのコマンドを実行できるようにするためのものです。このコマンドを実行するとコントローラーはアイドルステートへ移行します。

• Status Report – このコマンドは診断情報を取得するためのコマンドで、コントローラーに対する「ping」のような働きをします。このコマンドはモニターインターフェイスからのみ入力できます。

エラーが検出された場合、コントローラーは訂正を試みるために必要な情報をコンフィギュレーションロジックから読み出します。情報の収集が完了すると、コントローラーは訂正ステートへ移行します。






訂正 (軽減 (+ テスト ) モードのみ)

訂正ステートでは、コントローラーはエラーの訂正を試みます。訂正に失敗した場合も、コントローラーは必ず訂正ステートを通過します。訂正ステートの間、 status_correction は High にアサートされます。

エラーが CRC のみのエラーの場合、コントローラーは status_uncorrectable をセットしてモニターインターフェイスにレポートを出力します。その後、コントローラーは分類ステートへ移行します。エラーが CRC のみのエラーでない場合、コントローラーはアルゴリズムを用いてエラーの訂正を試みます。

エラーが訂正可能な場合、コントローラーはアクティブパーシャルリコンフィギュレーションを実行してフレームを訂正後の内容で書き換え、 status_uncorrectable をクリアします。エラーが訂正不能な場合、コントローラーは status_uncorrectable をセットします。どちらの場合も、コントローラーはモニターインターフェイスに訂正レポートを出力した後、分類ステートへ移行します。

ヒント : status_uncorrectable は status_correction の立ち下がりエッジでサンプルしてください。

分類 (軽減 (+ テスト ) モードのみ)

分類ステートでは、コントローラーはエラーを分類します。エラー分類機能を有効にしていない場合も、コントローラーは必ず分類ステートを通過します。分類ステートの間、 status_classification は High にアサートされます。

訂正ステート中に訂正不能と報告されたエラーはすべてエッセンシャルとして報告されます。エラーを訂正できないのは、エラーの場所を特定できないのが唯一の理由です。この場合、コントローラーはエラーがエッセンシャルかどうかをルックアップテーブルで判定できません。コントローラーは status_essential をアサートし、モニターインターフェイスに分類レポートを出力した後、アイドルステートへ移行します。訂正不能エラーが 1 つ検出されると、コントローラーはその時点でエラーの検出を中止します。この場合、 FPGA のリコンフィギュレーションが必要です。

ヒント : status_essential は status_classification の立ち下がりエッジでサンプルしてください。この信号はスティッキーで、コントローラーが次にエラーを訂正して分類するまで更新されません。

訂正ステートで訂正可能と報告されたエラーの取り扱いは、コントローラーのオプション設定により異なります。エラー分類が無効な場合、訂正可能エラーはすべて無条件でエッセンシャルとして報告されます。エラー分類が有効な場合、コントローラーはエッセンシャルビットデータの要求をフェッチインターフェイスに出力します。

システムレベルサンプルデザインでは、 SPI フラッシュマスターヘルパーブロックによってこの要求が外部メモリの読み出しに変換されます。読み出したデータは、 SPI フラッシュマスターヘルパーブロックを経由してコントローラーに返されます。このデータに基づき、コントローラーはエラーがエッセンシャルかどうかを判定します。判定が完了するとコントローラーは分類レポートをモニターインターフェイスに出力し、 status_essential を適宜変更した後、監視ステートへ移行してエラーの監視を続けます。

アイドル

アイドルステートへ移行すると、コントローラーは内蔵のコンフィギュレーションメモリスキャンおよびチェック機能を無効にします。したがって、コントローラーは SEU イベントを検出も訂正もしません。このステートはテストおよびデバッグの目的で使用します。アイドルステートでは、ステータスインターフェイスの 7 つのステートビットがすべてディアサートされます。アイドルステートで利用可能なコマンドと、そのコマンドを入力可能なインターフェイスを次の表にまとめます。






上記コマンドの生成方法の詳細は、「コマンドインターフェイス」および「モニターインターフェイス」を参照してください。

表 3‐1: アイドルステートで利用可能なコマンド

コマンド説明入力可能なインターフェイス

監視ステートへの移行

コントローラーを監視ステートに戻してエラーの検出を再開する場合に使用します。このコマンドは IP が軽減 (+ テスト ) モードにコンフィギュレーションされている場合のみ有効です。 IP がその他のモードの場合、このコマンドは無視されます。

コマンドおよびモニターインターフェイス

検出ステートへの移行

コントローラーはコンフィギュレーションメモリを継続的にスキャンしてエラーを検出します。エラーが検出されるとモニターインターフェイスからレポートが出力され、コントローラーはアイドルステートへ移行します。


診断スキャンステートへの移行

デバイスのコンフィギュレーションメモリ全体に対してスキャンを 1 回実行し、検出したすべてのフレームレベル ECC エラーのレポートをモニターインターフェイスから出力するようコントローラーに指示します。 1 回のコンフィギュレーションメモリスキャンが完了すると、コントローラーは自動的にアイドルステートへ移行します。


エラー挿入コントローラーに対してエラー挿入を実行するよう命令します。複数ビットエラーは、 1 ビットエラーの挿入を複数回繰り返して挿入します。


ソフトウェアリセットソフトウェアリセット (コントローラーの再起動と再初期化) を実行するようコントローラーに指示します。


完全なステータスレポート

詳細な診断情報を取得するためのコマンドで、コントローラーに対する「ping」のような働きをします。このコマンドはモニターインターフェイスからのみ入力できます。

モニターインターフェイスのみ

コンフィギュレーションフレーム読み出し

(Query コマンド )

コンフィギュレーションメモリの内容を読み出します。コンフィギュレーションアドレスにエラーを挿入する前後に Query コマンドを実行してエラーが正しく挿入されたことを確認することを推奨します。詳細は、「コンフィギュレーションメモリのマスク」を参照してください。


コンフィギュレーションレジスタ読み出し

(Peek コマンド )

コンフィギュレーションレジスタの内容を読み出します。


フレームアドレス変換

(Translate コマンド )

リニアフレームアドレス (LFA) と物理フレームアドレス (PFA) を双方向に変換します。


外部メモリ読み出し

(Xmem コマンド )外部メモリデバイスの内容を読み出します。モニターインターフェイスのみ






検出スキャン

検出ステートでは、コントローラーはエラー検出スキャンを実行します。このステートでは、コントローラーはデバイスのコンフィギュレーションメモリ全体を継続的に監視してエラー (フレームレベル ECC およびデバイスレベル CRC) を検出します。また、 ECC ベースの ROM エラーと補助インターフェイスからのエラーも監視します。エラーが検出されると、コントローラーはモニターインターフェイス経由でエラーを報告します。その後、コントローラーはアイドルステートへ移行します。

検出ステートでサポートされるコマンドは Enter Idle のみです。コントローラーはそれ以外のコマンドをすべて無視します。

• Enter Idle – このコマンドはコマンドインターフェイスとモニターインターフェイスのいずれからも入力できます。これは、コントローラーをアイドル状態にしてほかのコマンドを実行できるようにするためのものです。このコマンドを実行するとコントローラーはアイドルステートへ移行します。

コントローラーが検出ステートへ移行するのは次の 2 つの場合のみです。

• ケース 1 – 検出 (+ テスト ) モードにコンフィギュレーションしたコントローラーが初期化を完了した場合。

• ケース 2 – アイドルステートのコントローラーに対して検出ステートへの移行コマンドを実行した場合。このコマンドは、コマンドまたはモニターインターフェイスから入力できます。

診断スキャン

このステートでは、コントローラーは診断スキャンを実行します。このステートでは、コントローラーはデバイスのコンフィギュレーションメモリ全体に対してスキャンを 1 回実行し、検出したすべてのフレームレベル ECC エラーのレポートをモニターインターフェイスから出力します。 1 回のコンフィギュレーションメモリスキャンが完了すると、コントローラーはアイドルステートへ移行します。

診断スキャンステートでは、コントローラーはコマンドを受け付けません。

コントローラーが診断スキャンステートへ移行するのは、アイドルステートで診断スキャンステートへの移行コマンドを実行した場合のみです。このコマンドは、コマンドまたはモニターインターフェイスから入力できます。

挿入 (軽減 + テスト、検出 + テスト、エミュレーションモードのみ)

挿入ステートでは、コントローラーはエラーを挿入します。エラー挿入が有効な場合、コントローラーはアイドルステートで有効なエラー挿入コマンドを受信した場合のみ挿入ステートへ移行します。エラー挿入が無効な場合、または有効なエラー挿入コマンドでない場合は、コントローラーは挿入ステートへ移行しません。挿入ステートの間、 status_injection は High にアサートされます。

エラー挿入プロセスは、エラー挿入コマンドで指定したコンフィギュレーションメモリアドレスの 1 ビットをシンプルな Read-Modify-Write によって反転させます。コントローラーは、挿入ステートの次は必ずアイドルステートへ移行します。

エラー挿入コマンドを繰り返し実行すると、 1 回のコマンド実行のたびに挿入ステートへ移行して複数ビットエラーを挿入できます。

重大エラー

コントローラーは、内部で何らかの不整合性を検出すると重大エラーステートへ移行します。確率は非常に低いものの、コントローラーに関係するコンフィギュレーションメモリまたはコントローラーのデザインステートエレメントがソフトエラーの影響を受けてコントローラーの動作が停止する可能性があります。重大エラーステートになると、ステータスインターフェイスの 7 つのステートビットがすべてアサートされ、場合によっては重大エラーレポートメッセージ (HLT) も出力されます。このエラー条件は回復不能であるため、 FPGA をもう一度コンフィギュレーションする必要があります。







図 3-8 に、ステート信号 status_initialization、 status_observation、 status_correction、status_classification、 status_injection、 status_detect_only、および status_diagnostic_scan の全体的なスイッチング動作を示します。この図で、 status_[state] 信号は 7 つのステート信号をグループとして表したもので、これによってコントローラーのステートが示されます。


コントローラーが正常に動作していることを確認するには、初期化ステート完了後にモードに応じて監視/アイドル/検出ステートへ移行したかどうか、重大エラーが発生したかどうかをステータス信号を監視して確認することを推奨します。コントローラーの正常動作とステートをシステムレベルで監視する際のその他の推奨事項は、「システム」を参照してください。

フラグ

status_uncorrectable および status_essential 信号は、検出したエラーが訂正可能かどうか、エッセンシャルかどうかを示すフラグです。分類機能が無効な場合、初のエラーが検出および訂正された後で status_essential 信号がアサートされてそのままの状態を維持します。これらの信号は軽減 (+ テスト ) モードの場合のみ有効で、コントローラーが訂正ステート (status_uncorrectable) または分類ステート (status_essential) へ移行すると更新されます。検出 (+ テスト ) モードでは、これらのフラグはエラーが検出されるとアサートされます。


軽減 (+ テスト ) モードでは、フラグ信号 status_uncorrectable および status_essential はステート終了時に更新されます。図 3-9 と図 3-10 に、ステート終了時点を基準としたスイッチング動作を示します。これらの図は、コントローラーがステートを終了する時点を基準としてフラグが有効な期間を示しており、この期間内にフラグを更新できます。この波形には特定のフラグ値は示していません。


図 3‐8: ステータスインターフェイスのステート信号のスイッチ特性

clk

status_[state]

8 Tclk


図 3‐9: ステータスインターフェイスの uncorrectable フラグのスイッチ特性 (軽減 (+ テスト ) モード )






検出 (+ テスト ) モードでは、これらフラグはどちらもエラーを検出してコントローラーがアイドルステートへ移行する直前にアサートされます。


コントローラーによって訂正不能エラーが検出された場合、どのように対応するかをシステムレベルデザインで評価する必要があります。分類機能が有効な場合、エッセンシャルエラーが検出および訂正された場合の対応もシステムレベルデザインで検討する必要があります。システムレベルでどのような対応を実行するかは、デザインの全体的な SEU 軽減目標によって異なります。少なくとも、これらの条件が発生したことを示すシステムログを生成することを推奨します。

ヒント : コントローラーは、訂正ステートで訂正不能エラーを検出するとコンフィギュレーションメモリの監視による SEU 検出を停止し、アイドルステートへ移行します。

コントローラーの正常動作とステートをシステムレベルで監視する際のその他の推奨事項は、「システム」を参照してください。

ハートビート

この信号は、コンフィギュレーションリードバックシステム ( リードバック CRC) またはコントローラーがコンフィギュレーションメモリに対して実行するいずれかの手動スキャンのステータスを監視する目的で使用します。この信号はリードバックプロセスから直接出力され、監視、検出、および診断ステートの間のみ有効です。監視、検出、または診断スキャンステートへ移行後、リードバックプロセスがエラーのスキャンを開始すると、このハートビート信号が有効になります。監視、検出、および診断スキャンステート中に検出した初のハートビートパルスを使用して、ハートビートの停止を監視する回路を起動する必要があります。監視ステート以外では、ハートビート信号の動作は定義されていません。


図 3-11 に、ハートビート信号 status_heartbeat のスイッチング動作を示します。

このパルス幅は非常に小さいため、エンベデッドプロセッサの汎用 I/O (GPIO) を利用してソフトウェアポーリングでステータスインターフェイス信号をサンプリングする方法は正しく動作しないことが考えられます。この方法ではなく、カウンター /タイマー入力、エッジセンス割り込み入力、またはイベントキャプチャ機能を備えた入力などを使用してください。


図 3‐10: ステータスインターフェイスの essential フラグのスイッチ特性 (軽減 (+ テスト ) モード )


図 3‐11: ステータスインターフェイスのハートビートのスイッチ特性

N1 clk cycles

1. N = 250K for UltraScale and UltraScale+ devices when controller is in Observation or Detect only state.







コントローラーが監視、検出、または診断スキャンステートの間、ハートビート信号を監視することでコントローラーの全体的な正常動作と機能を確認できます。デバイスの種類、システムクロック、 ICAP クロック、およびコントローラーの現在のステートによってハートビート信号の間隔が異なるため、ハートビート信号が停止して 1 秒が経過してからエラーと判定することを推奨します。コントローラーの正常動作とステートをシステムレベルで監視する際のその他の推奨事項は、「システム」を参照してください。

コマンドインターフェイス

コマンドインターフェイスを使用すると、アイドル、監視、検出、または診断スキャンステートへの移行、エラー挿入、またはソフトウェアリセットを簡単に実行できます。コマンドインターフェイスは入力コマンド、入力ストローブ、および出力ビジー信号で構成され、これらを使用してビジー出力を備えたシンプルなパラレル入力ポートを実装します。このインターフェイスはオプションです。使用しない場合は、すべての入力を Low に接続できます。

このインターフェイスは次に示す種類のコマンドを受け付けます。

• アイドルステートへ移行するためのコマンド (通常のスキャンを中断)

• 監視ステートへ移行するためのコマンド (通常のスキャンを再開)

• 検出ステートへ移行するためのコマンド (訂正機能なしで通常のスキャンを再開)

• 診断スキャンステートへ移行するためのコマンド (デバイスのすべてのコンフィギュレーションメモリに対して診断スキャンを実行し、すべてのフレームレベル ECC エラーを報告)

• ソフトウェアリセット (再起動と初期化) を実行するためのコマンド

• フレームアドレスを指定してエラーを挿入するためのコマンド

これらコマンドの一部はコントローラーが監視、アイドル、検出ステートでないと実行できないため、コマンドを実行する際はステータスインターフェイスを監視する必要があります。

コマンドインターフェイスからコマンドを入力すると、モニターインターフェイスにも反映されてレポートが出力されます。

推奨: ユーザーとコントローラーの通信には、より高機能なモニターインターフェイスの使用を推奨します。「モニターインターフェイス」を参照してください。

システムレベルサンプルデザインを UltraScale SSI デバイスにインプリメントした場合、各 SLR に 1 つずつコントローラーインスタンスがあり、すべてのコントローラーインスタンスがコマンドインターフェイスからの信号を受信します。システムレベルサンプルデザインを UltraScale+ SSI デバイスにインプリメントした場合は、モノリシックデバイスと同様にコントローラーインスタンスはデバイス全体に 1 つだけです。多くの場合、コマンドインターフェイスからの信号は FPGA の I/O ピンに接続できます。

このインターフェイスは、 Vivado Design Suite のデバッグ機能に接続するなど FPGA 内部から駆動することも、別のデバイスに接続して I/O ピンから制御することもできます。後者の場合、別のデバイスに接続して入力したコマンドを正しく取り込むには、コマンドインターフェイスのタイミング要件を考慮する必要があります。「スイッチング動作」を参照してください。






コマンド

コマンドを入力するには、 command_code バスに値を与えた後、 command_strobe 信号をパルスします。コマンドを入力すると command_busy 信号がアサートされ、コマンドがキューに格納されるまでアサートされたままとなります。 command_busy 信号がディアサートされるまで次のコマンドを入力しないでください。表 3-2 に、コマンドの一覧とその生成方法を示します。その後で、各モードの詳細を説明します。

表 3‐2: コマンドのフォーマットと使用方法

コマンドcommand_code[n – 1:0] のフォーマット

UltraScale デバイスでは n = 40、 UltraScale+ デバイスでは n = 44

アイドルステートへの移行

UltraScale = 1110 xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx

UltraScale+ = 1110 xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx

x = Don’t Care

コントローラーが監視および検出ステートの場合に有効。

LFA を使用したエラー挿入

UltraScale = 1100 0000 0ssL LLLL LLLL LLLL LLLL wwww wwwb bbbb

UltraScale+ = 1100 0000 0000 ssLL LLLL LLLL LLLL LLLL wwww wwwb bbbb

コントローラーがアイドルステートの場合に有効。軽減 + テスト、検出 + テスト、エミュレーションモードの場合のみ有効。エラー挿入を利用してデザインをテストする方法の詳細は、付録 E 「エラー挿入のガイダンス」を参照してください。




x = Don’t Care

コントローラーがアイドルステートの場合に有効。軽減 (+ テスト ) モードの場合のみ有効。




x = Don’t Care

コントローラーがアイドルステートの場合に有効。


UltraScale = 1101 xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxxUltraScale+ = 1101 xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx

x = Don’t Care


ソフトウェアリセット



x = Don’t Care


2 進数の値説明

ssハードウェア slr 番号 (2 ビット ) 有効な範囲: 0 ～ 3

LLLLLLLLLLLLLLLLL

または LLLLLLLLLLLLLLLLLL

リニアフレームアドレス (UltraScale では 17 ビット、UltraScale+ では 18 ビット )有効な範囲: 0 ～ Max Frame – 2

wwwwwww

ワードアドレス (7 ビット )UltraScale の有効な範囲: 0 ～ 122それ以外の有効な範囲: 0 ～ 92

bbbbbビットアドレス (5 ビット )有効な範囲: 0 ～ 31






アイドルステートへの移行

このコマンドは、コントローラーが監視または検出ステートの場合のみ有効です。このコマンドを実行する前に status_observation および status_detect_only 信号を確認してください。


このコマンドは、コントローラーがアイドルステートの場合のみ有効です。コントローラーがアイドルステート (status_* 信号がすべて Low) でない場合、アイドルステートへの移行命令を実行してコントローラーをアイドルステートに遷移させる必要があります。アイドルステートへ移行したらこのコマンドを実行できます。

エラー挿入を利用してデザインをテストする方法の詳細は、付録 E 「エラー挿入のガイダンス」を参照してください。


このコマンドは、コントローラーがアイドルステートの場合のみ有効です。コントローラーがアイドルステート (status_* 信号がすべて Low) でない場合、アイドルステートへの移行命令を実行してコントローラーをアイドルステートに遷移させる必要があります。アイドルステートへ移行したらこのコマンドを実行できます。


このコマンドは、コントローラーがアイドルステートの場合のみ有効です。このコマンドを実行するとコントローラーは監視ステートへ移行し、コンフィギュレーションメモリのスキャンとソフトエラーの検出、訂正、分類を継続します。


このコマンドは、コントローラーがアイドルステートの場合のみ有効です。コントローラーがアイドルステート (status_* 信号がディアサート、つまり Low) でない場合、アイドルステートへの移行命令を実行してコントローラーをアイドルステートに遷移させる必要があります。アイドルステートへ移行したらこのコマンドを実行できます。


このコマンドは、コントローラーがアイドルステートの場合のみ有効です。コントローラーがアイドルステート (status_* 信号がディアサート、つまり Low) でない場合、アイドルステートへの移行命令を実行してコントローラーをアイドルステートに遷移させる必要があります。アイドルステートへ移行したらこのコマンドを実行できます。

コマンドが無効な場合の動作

command_busy は command_strobe を 1 回パルスしてコマンドを入力するとアサートされ、コマンドが処理されるとディアサートされます。しかし入力したコマンドが無効な場合、コマンドは実行されずステータス信号も変化しません。また、無効なコマンドがモニターまたは UART インターフェイスにエコーバックすることもありません。







コマンドインターフェイスの信号は、入力レジスタを有効にするストローブを使用してコントローラー内部の順次ロジック処理により受信します。データを正しく取り込むには、図 3-12 に示したタイミング要件に従う必要があります。 command_strobe は icap_clk に同期しており、コマンドを発行するたびに 1 クロックサイクルだけパルスする必要があります。

マスクしたフレーム、あるいはデバイスまたは SEU でカバーされないアドレス空間にあるフレームにエラーを挿入した場合、エラー挿入コマンドは無視され、監視ステートでエラーは検出されません。


このインターフェイスにはシステムレベル要件はありません。


モニターインターフェイスはコントローラーとの通信手段としてのほか、コントローラーの動作と現在のステートについての詳細な情報を得る手段としても使用できます。このインターフェイスは、コマンドインターフェイスとステータスインターフェイスを合わせたよりも多くのコマンドと情報をサポートしています。

コントローラーがモニターインターフェイスから読み出すコマンド、およびモニターインターフェイスに書き込むステータス情報はいずれも ASCII 文字列です。このインターフェイスのポートの一覧および定義については、表 2-21 を参照してください。

コントローラーのステート、ステート遷移、およびコントローラーによって検出されたエラーはステータスインターフェイスでも監視できますが、モニターインターフェイスの方がコントローラーのステートおよびコントローラーが検出したエラーについてより詳細な情報 (コンフィギュレーションフレームのアドレスなど) が得られます。コントローラーのステートおよびステート遷移の詳細は、「ステータスインターフェイス」を参照してください。

検出および診断スキャンなどの検出機能の場合、コントローラーが検出したエラーに関する情報はモニターインターフェイスからのみ出力されます。したがって、これらの機能を使用する場合はこのインターフェイスからエラー情報を取得する必要があります。

特定ステートへの移行およびエラー挿入コマンドに加え、このインターフェイスからはコンフィギュレーションレジスタおよびフレームの内容の読み出し、物理コンフィギュレーションフレームアドレス (PFA) とリニアフレームアドレス (LFA) の双方向変換、およびデザインに接続した外部メモリの読み出しコマンドも実行できます。コマンドインターフェイスとモニターインターフェイスで利用できるコマンドの比較は、表 3-1 を参照してください。

モニターインターフェイスのシグナリングの詳細は、付録 H 「モニターインターフェイスのシグナリングとプロトコル」を参照してください。

このインターフェイスには、主に 3 つの利用方法があります。

• モニターおよびデバッグ

• コントローラーとユーザーデザインのテスト

• 対話型のソフトエラー軽減

次に、それぞれの利用方法について説明します。


図 3‐12: コマンドインターフェイスのスイッチ特性






モニターおよびデバッグ

推奨: このインターフェイスは、コントローラーのステートと動作についても多くの情報を提供します。少なくともこのインターフェイスを FIFO に接続してインターフェイスの出力を格納することを推奨します。得られた情報は、デザイン内部の動作を理解する上で欠かせないほか、ザイリンクスのテクニカルサポートでケースを開く際にも必要になることがあります。

FIFO のサイズは用途により異なります。 FIFO データをデバッグに使用するだけで周期的にデータを取得するのでなければ、少なくとも 1 回分の初期化レポートと 2 回分のエラーレポートを完全に格納できる FIFO サイズを推奨します。この場合、必要な小 FIFO サイズは 512 × 8 です。

診断スキャン機能を使用する場合、モニターインターフェイスはコントローラーに対して診断スキャンの実行命令を送信する手段としてだけでなく、検出されたエラーのタイプと位置を記録する手段としても使用できます。この場合、 FIFO サイズは N 回のエラーレポート (N は軽減措置を実行するまでに取得するエラーレポートの数) を追加で格納できる大きさとする必要があります。

この情報を周期的に受信する場合、 FIFO サイズはデータ取得頻度によって決定します。

この使用方法では、インターフェイスの入力を次のように接続してコントローラーへの書き込みコマンドを無効にしてください。

monitor_txfull = 0 or to the FIFO full flagmonitor_rxdata = to all 0smonitor_rxempty = 1

モニターおよびデバッグ用にモニター TX インターフェイスを FIFO に接続する方法は、図 3-13 のブロック図の例を参照してください。

モニターポートからは、検出したエラーのアドレスやタイムスタンプなどの詳細情報が得られます。これらの詳細なエラー情報は、システムで発生した SEU イベントのログを記録する際に役立ちます。

コントローラーとユーザーデザインのテスト

このインターフェイスをプロセッサブロックに簡単に統合できるように、システムレベルサンプルデザインのモニターインターフェイスには UART ヘルパーブロックが接続されています。 UART インターフェイスは、コントローラーからのステータス情報の受信、コントローラーへのエラー挿入コマンドの送信、および挿入したエラーがコントローラーによって検出および訂正されたことの確認に使用できます。


図 3‐13: モニター TX インターフェイスと FIFO の接続

monitor_txdata[7:0]

monitor_txwrite

monitor_txfull

monitor_rxdata[7:0]

monitor_rxread

monitor_rxempty

FIFO18E1

‘1'

“0000000”

DIN

WRCLK

WREN

DOUT

RDCLK

RDENFULL

EMPTY

Not connected

ERROR

DATA[7:0]

RDEN

INTERRUPT

SEM Controller






対話型のソフトエラー軽減

モニター、テスト以外に、モニターインターフェイスはデザイン要件に合わせてカスタマイズした対話型のソフトエラー軽減ソリューションの実装にも使用できます。モニターインターフェイスを使用すると、コントローラーが検出したすべてのソフトエラーについてのログを取得できます。この情報を使用することで、 IP に内蔵の機能 (すなわち軽減 (+ テスト ) モードでの訂正機能) を利用するのではなく、発生したエラーのタイプに応じた措置が可能です。

たとえばソフトエラー軽減ストラテジとしてエラーのログのみを記録し、約 10 回のエラーが累積した時点でデバイスのリコンフィギュレーションを実行する場合を考えます。

これを実装するには、たとえば SEM Controller をエミュレーションモードにコンフィギュレーションし、モニターインターフェイス経由で異なるタイプのエラー検出コマンド (検出スキャンまたは診断スキャン) を発行します。初期化が完了したら直ちにコントローラーにコマンドを発行して検出スキャンを実行します。エラーを検出してレポートを出力すると、コントローラーはアイドルステートへ移行します。これとは別に、 1 日に 1 回など定期的に診断スキャンを実行し、エラーの累積数を追跡してログに記録します。エラーの累計数が 10 に達したら、システムが停止してデバイスをリコンフィギュレーションし、再起動します。また、 SEM Controller を検出 (+ テスト ) モードにコンフィギュレーションし、初のエラーが検出された時点でコマンドを発行して診断スキャンを実行するという方法でも同じ軽減ストラテジを実装できます。

注記: ソフトエラーを累積させたままで、デバイスを元のステートにリコンフィギュレーションしない場合、ザイリンクスはデバイスの機能を保証しません。

次のセクションでは、 UART インターフェイスの動作について説明します。

UART インターフェイス

UART インターフェイスは、モニターインターフェイスで使用するバイトストリーム ASCII コードのシリアライズとデシリアライズを実行する UART ヘルパーブロックです。このヘルパーブロックは標準シリアル通信プロトコルを使用しており、標準 RS-232 ポートに接続できるほか、 USB-UART ブリッジを介して USB にも接続できます。詳細は、第 2 章の「UART インターフェイス」を参照してください。

次に、このインターフェイスで利用可能なメッセージとコマンドについて説明します。

UART インターフェイスのメッセージ

ここでは、コントローラーが UART インターフェイスから出力するメッセージについて説明します。これらのメッセージの一部は、ステータスインターフェイスから出力されるレポートと同じものです。

初期化レポート

コントローラーが初期化シーケンスを実行中、初期化レポートが生成されます。このレポートには診断情報が含まれ、コントローラーの初回起動時およびソフトウェアリセット時に生成されます。

SEM_ULTRA_V3_1 Name and versionSC 01 State transition to Initialization stateFS {2 digit hex value} Core Configuration InformationAF {2 digit hex value} Additional Core Configuration InformationICAP OK Status: ICAP AvailableRDBK OK Status: Readback ActiveINIT OK Status: Completed SetupSC {00, 02, 20} State transition to Idle, Observation, or Detect only state






コマンドプロンプト

コントローラーから出力されるコマンドプロンプト文字は、コントローラーのステートに応じて 3 種類あります。コントローラーが監視ステート (軽減 (+ テスト ) モードで初期化完了後のデフォルトステート ) の場合は、コマンドプロンプト O> が出力されます。

コントローラーがアイドルステート (モニターまたはエミュレーションモードで初期化完了後のデフォルトステート ) の場合は、コマンドプロンプト I> が出力されます。コントローラーが検出ステート (検出 (+ テスト ) モードで初期化完了後のデフォルトステート ) の場合は、コマンドプロンプト D> が出力されます。

ステート変化レポート

コントローラーステートが変化すると、必ずステート変化レポートが出力されます。このレポートは 1 行で、フォーマットは次のとおりです。

SC {2-digit hex value}

2 桁の 16 進数値でステータスインターフェイスの出力を表現します。

重大エラーステートへの移行はいつでも起こる可能性があります。また、ステート変更レポートが明示的に出力されない場合もあります。重大エラーステートへ移行した際、コントローラーは可能であれば次の重大エラーメッセージを出力します。

HLT

フラグ変化レポート

コントローラーは、フラグを変更すると必ずフラグ変化レポートを出力します。このレポートは 1 行で、フォーマットは次のとおりです。

FC {2-digit hex value}

表 3‐3: ステート変化レポートのデコード

レポートの文字列ステート名

SC 00 アイドル

SC 01 初期化

SC 02 監視

SC 04 訂正

SC 20 検出

SC 40 診断スキャン

SC 08 分類

SC 10 エラー挿入

SC 9F 重大エラー






2 桁の 16 進数値でステータスインターフェイスの出力を表現します。

コントローラーが診断スキャンステートの場合、フラグ変化レポートは出力されません。

エラー検出レポート – 軽減 (+ テスト ) モード (訂正機能有効)

エラー条件を検出すると、コントローラーはなるべく短時間でエラーを訂正しようと試みます。したがって、エラーが訂正可能であるという前提に立ち、初に訂正を実行してからレポート情報が生成されます。次のようなレポートが出力されます。

診断: CRC エラーのみ (エラービットの位置または数を特定できない)。

RI XX Reserved informationSC 04 State Transition to Correction stateCRC CRC error detectedTS {8-digit hex value} Timestamp

診断: ECC ベースのエラー – 訂正不能

RI XX Reserved informationSC 04 State Transition to Correction stateECC ECC Error DetectedTS {8-digit hex value} TimestampPA {n-digit hex value} PFA of Detected Error. n = 7 for UltraScale and 8 for UltraScale+.LA {n-digit hex value} LFA of Detected Error. n = 7 for UltraScale and 8 for UltraScale+.

検出レポートの PA には SLR 番号と PFA アドレスの両方が含まれます。 PA のフォーマットは、 PFA エラー挿入コマンドからワードおよびビットフィールドを取り除いたものとなります。詳細は、表 J-1 の「PFA を使用したエラー挿入」を参照してください。

UltraScale PA = 0sst trrr rrrc cccc cccc cmmm mmmmUltraScale+ PA = 00ss 0ttt rrrr rrcc cccc cccc mmmm mmmm

検出レポートの LA には SLR 番号と LFA アドレスの両方が含まれます。LA のフォーマットは、LFA エラー挿入コマンドからワードおよびビットフィールドを取り除き、上位ニブルをすべて 0 にしたものとなります。詳細は、表 3-5 の「LFA を使用したエラー挿入」を参照してください。

UltraScale = 0000 0000 0ssL LLLL LLLL LLLL LLLLUltraScale+ = 0000 0000 0000 ssLL LLLL LLLL LLLL LLLL

表 3‐4: フラグ変化レポートのデコード

レポートの文字列条件名

FC 00 訂正可能、非エッセンシャル

FC 20 訂正不能、非エッセンシャル

FC 40 訂正可能、エッセンシャル

FC 60 訂正不能、エッセンシャル






診断: ECC ベースのエラー – 訂正可能

RI XX Reserved informationSC 04 State Transition to Correction stateECC ECC error detectedTS {8-digit hex value} TimestampPA {n-digit hex value} PFA of Detected Error. n = 7 for UltraScale and 8 for UltraScale+.LA {n-digit hex value} LFA of Detected Error. n = 7 for UltraScale and 8 for UltraScale+.





診断: 補助インターフェイスの入力によって検出されたエラー。補助エラーのレポートはコントローラーが訂正ステート時に出力されます。

RI XX Reserved informationSC 04 State Transition to Correction stateAUX AUX ErrorTS {8-digit hex value} Timestamp

診断: ECC ベースの ROM エラー – 訂正可能。前述のとおり、コントローラーが使用するブロック RAM の大半は ECC で保護されています。このロジックによって訂正可能エラー (1 ビットエラー ) が検出されると、次のエラーメッセージが出力されます。このエラーは、コントローラーが訂正ステートの場合に報告されます。

このエラーが検出されても、 1 ビット ECC エラーの読み出し出力はブロック RAM によって自動的に訂正されるため、ブロック RAM から実際に読み出されるデータにエラーは含まれません。このメモリ空間でエラーが蓄積されるのを防ぐため、訂正後のデータが同じアドレスに書き戻されます。

RI XX Reserved informationSC 04 State Transition to Correction stateROMTS (8-digit hex value) Timestamp

エラー検出レポート – 検出ステート

コントローラーが検出ステートの場合にエラーを検出すると、レポートが出力されます。エラー検出レポートの出力が終わると、コントローラーはアイドルステートへ移行します。次のようなレポートが出力されます。

診断: CRC エラーのみ (エラービットの位置または数を特定できない)。

RI XX Reserved informationCRC CRC error detectedTS (8-digit hex value) Timestamp






診断: ECC ベースのエラー – 訂正不能

RI XX Reserved InformationECC ECC error detectedTS {8-digit hex value} TimestampPA {n-digit hex value} PFA of Detected Error. n = 7 for UltraScale and 8 for UltraScale+.LA {n-digit hex value} LFA of Detected Error. n = 7 for UltraScale and 8 for UltraScale+.






RI XX Reserved InformationECC ECC error detectedTS {8-digit hex value} TimestampPA {n-digit hex value} PFA of Detected Error. n = 7 for UltraScale and 8 for UltraScale+.LA {n-digit hex value} LFA of Detected Error. n = 7 for UltraScale and 8 for UltraScale+.WD {2-digit hex value} BT {2-digit hex value} Word and Bit of the Detected Error





訂正可能な ECC エラーの場合、コントローラーはエラーが検出されたすべてのワードおよびビット位置を報告します。このレポートでは、 1 フレーム内で大 4 つのエラーが報告されます。

診断: 補助インターフェイスの入力によって検出されたエラー。

RI XX Reserved InformationAUX AUX errorTS {8-digit hex value} Timestamp

診断: ECC ベースの ROM エラー – 訂正可能。前述のとおり、コントローラーが使用するブロック RAM の大半は ECC で保護されています。このロジックによって訂正可能エラー (1 ビットエラー ) が検出されると、次のエラーメッセージが出力されます。






このエラーが検出されても、 1 ビット ECC エラーの読み出し出力はブロック RAM によって自動的に訂正されるため、ブロック RAM から実際に読み出されるデータにエラーは含まれません。このメモリ空間でエラーが蓄積されるのを防ぐため、訂正後のデータが同じアドレスに書き戻されます。

RI XX Reserved informationROMTS (8-digit hex value) Timestamp

エラー検出レポート – 診断スキャン

コントローラーが診断スキャンステートの場合、エラー条件が検出されるとすぐにコントローラーはエラーレポートを出力します。エラーを検出するとコントローラーはスキャンを中断し、モニターインターフェイスへエラーレポートを出力します。現在のフレームのすべてのエラーが報告されると、コントローラーはスキャンを再開します。したがって、この機能を実行する際はモニターインターフェイスでなるべくバックプレッシャーが発生しないように注意が必要です。次のようなレポートが出力されます。

診断: ECC ベースのエラー – 訂正不能 (エラービットの位置または数を特定できない)

RI XX Reserved InformationECC ECC error detectedTS {8-digit hex value} TimestampPA {n-digit hex value} PFA of Detected Error. n = 7 for UltraScale and 8 for UltraScale+.LA {n-digit hex value} LFA of Detected Error. n = 7 for UltraScale and 8 for UltraScale+.






RI XX Reserved InformationECC ECC error detectedTS {8-digit hex value} TimestampPA {n-digit hex value} PFA of Detected Error. n = 7 for UltraScale and 8 for UltraScale+.LA {n-digit hex value} LFA of Detected Error. n = 7 for UltraScale and 8 for UltraScale+.WD {2-digit hex value} BT {2-digit hex value} Word and Bit of the Detected Error










訂正可能エラーの場合、コントローラーは検出したすべてのエラー (1 フレームにつき 4 つまで) のワード位置とビット位置をすべて報告します。

エラー訂正レポート – 軽減 (+ テスト ) モードのみ

エラー訂正プロセスは、コントローラーの設定、検出されたエラーのタイプ、およびエラーが訂正可能かどうかにより異なります。

訂正不能エラーの場合のレポートのフォーマットは次のとおりです。

COREND

この後に、次の行が続きます。

FC 20 Bit 5, uncorrectable set (stale essential flag)

または

FC 60 Bit 5, uncorrectable set (stale essential flag)

訂正可能エラーの場合のレポートのフォーマットは次のとおりです。

COR{correction list}END

この後に、次の行が続きます。

FC 00 Bit 5, uncorrectable cleared (stale essential flag)

または

FC 40 Bit 5, uncorrectable cleared (stale essential flag)

{correction list} には、 1 件の訂正されたビットにつきフレーム内のワード位置とワード内のビット位置が 1 行で表示されます。この記法は、エラー検出レポートの場合と同じです。リストの各行は次のフォーマットで表示されます。

WD {2-digit hex value} BT {2-digit hex value}

エラー分類レポート – 軽減 (+ テスト ) モードのみ

エラー分類プロセスでは、フレーム内で発生したエラーの中にエッセンシャルなものがあるかどうかをルックアップテーブルで判定します。 1 つまたは複数のエラーがエッセンシャルと判定された場合、イベント全体がエッセンシャルと見なされます。

エラー分類が有効な場合、訂正可能な非エッセンシャルイベントのレポートのフォーマットは次のとおりです。

SC 08CLAENDFC 00 Bit 6, essential is cleared






エラー分類が有効な場合、訂正可能なエッセンシャルイベントのレポートのフォーマットは次のとおりです。

SC 08CLA{classification list}ENDFC 40 Bit 6, essential is set

{classification list} には、 1 件のエッセンシャルビットにつきフレーム内のワード位置とワード内のビット位置が 1 行で表示されます。この記法は、エラー検出レポートの場合と同じです。リストの各行は次のフォーマットで表示されます。

WD {2-digit hex value} BT {2-digit hex value}

エラー分類を無効にした場合は、詳細な分類リストは出力されません。この場合、コントローラーはエラーがエッセンシャルでないと判定する根拠を持たないため、すべてのエラーをエッセンシャルと見なす必要があります。訂正可能イベントの場合のレポートのフォーマットは次のとおりです。

SC 08FC 40 Bit 6, essential is set

エラーが訂正不能な場合、コントローラーはエラーがエッセンシャルでないと判定する根拠を持たないため、すべての訂正不能エラーをエッセンシャルと見なす必要があります。訂正不能イベントの場合のレポートのフォーマットは次のとおりです。

SC 08FC 60 Bit 6, essential is set

ステータスレポート

ステータスレポートからは、コントローラーのステートに関するより詳細な情報が得られます。このレポートは、コントローラーが監視、検出、またはアイドルステートのときに S コマンドを入力すると、複数行のレポートとして出力されます。

ステータスレポートの分量はコントローラーの現在のステートにより異なります。コントローラーがアイドルステートの場合は完全なステータスレポートが出力されます。監視および検出ステートでは、短縮版のレポートが出力されます。非 SSI デバイスの場合、アイドルステートで出力されるステータスレポートのフォーマットは次のとおりです。

SN {2-digit hex value} SLR Number SC {2-digit hex value} Current StateFC {2-digit hex value} Current FlagsRI {2-digit hex value} Reserved informationMF {8-digit hex value} Maximum Linear Frame Count TS {8-digit hex value} TimestampTB {8-digit hex value} Table Base (valid when error classification is enabled; otherwise X's)CB {8-digit hex value} Classification Base (valid when error classification is enabled; otherwise X's)CL {3-digit hex value} Classification Level

非 SSI デバイスの場合、監視および検出ステートで出力されるステータスレポートには MF ( 大リニアフレーム数)、TS (タイムスタンプ)、 TB (テーブルベース)、 CB (分類ベース)、 CL (分類レベル) の項目はありません。

CL の値は分類機能が有効かどうかにより異なります。分類機能が有効な場合、 CL = 02 (2 段階分類) です。分類機能が無効な場合は CL = 01 (1 段階分類) で、すべてのエラーがエッセンシャルとして分類されます。

SSI デバイスのステータスレポートも基本的なフォーマットは非 SSI デバイスと同じですが、SLR ごとにサブレポートが出力されます。サブレポートはハードウェア SRL 番号の順に出力されます。






たとえば 3 つの SLR で構成されるデバイスの場合、ステータスレポートのフォーマットは次のとおりです。

SN 00 SLR NumberSC {2-digit hex value} Current StateFC {2-digit hex value} Current FlagsRI {2-digit hex value} Reserved informationMF {8-digit hex value} Maximum Linear Frame Count TS {8-digit hex value} TimestampTB {8-digit hex value} Table Base (valid when classification is enabled; otherwise X's)CB {8-digit hex value} Classification Base (valid when classification is enabled; otherwise X's)CL {3-digit hex value} Classification LevelSN 01 SLR NumberSC {2-digit hex value} Current StateFC {2-digit hex value} Current FlagsRI {2-digit hex value} Reserved informationMF {8-digit hex value} Maximum Linear Frame Count TS {8-digit hex value} TimestampTB {8-digit hex value} Table Base (valid when classification is enabled; otherwise X's)CB {8-digit hex value} Classification Base (valid when classification is enabled; otherwise X's)CL {3-digit hex value} Classification LevelSN 02 SLR NumberSC {2-digit hex value} Current StateFC {2-digit hex value} Current FlagsRI {2-digit hex value} Reserved informationMF {8-digit hex value} Maximum Linear Frame Count TS {8-digit hex value} TimestampTB {8-digit hex value} Table Base (valid when classification is enabled; otherwise X's)CB {8-digit hex value} Classification Base (valid when classification is enabled; otherwise X's)CL {3-digit hex value} Classification Level

UltraScale+ SSI デバイスのステータスレポートには、コントローラーは 1 つしかありません。したがって、ステート変化 (SC)、フラグ変化 (FC)、および分類レベル (CL) の情報はすべての SLR で共通です。

UART インターフェイスのコマンド

ここでは、モニターインターフェイスからユーザーがコントローラーに送信できるコマンドについて説明します。これらのコマンドの一部は、コマンドインターフェイスで利用できるコマンドと同じです。

注記: UART インターフェイスのコマンドは、すべて大文字で入力する必要があります。

表 3‐5: UART コマンドと使用方法

コマンド UART コマンドセット

特定ステートへの移行

「O」 = 監視ステートへの移行。軽減 (+テスト ) モードでアイドルステートの場合のみ有効。

「I」 = アイドルステートへの移行。監視および検出ステートの場合に有効。

「D」 = 検出ステートへの移行。アイドルステートの場合に有効。

「U」 = 診断スキャンステートへの移行。アイドルステートの場合に有効。

ステータスレポート「S」

アイドルおよび監視ステートの場合に有効。







「N {n-digit hex value}」

UltraScale では n = 10、 UltraScale+ では n = 11。

UltraScale = 1100 0000 0ssL LLLL LLLL LLLL LLLL wwww wwwb bbbb

UltraScale+ = 1100 0000 0000 ssLL LLLL LLLL LLLL LLLL wwww wwwb bbbb

アイドルステートの場合に有効。軽減 + テスト、検出 + テスト、エミュレーションモードの場合のみ有効。エラー挿入を利用してデザインをテストする方法の詳細は、付録 E 「エラー挿入のガイダンス」を参照してください。

コンフィギュレーションフレーム読み出し

(Query コマンド )

「Q {n-digit hex value}」

「n-digit hex value」はエラー挿入コマンドで使用する PFA または LFA アドレスフォーマット。

注記: フレームアドレスのワードおよびビットフィールドは無視されます。このコマンドを実行すると、

常にフレームの内容全体が返されます。


アイドルステートの場合に有効。

コンフィギュレーションレジスタ読み出し

(Peek コマンド )

「P {2-digit hex value}」

2 進数の値 = 0ssr rrrr

75 ページの「コンフィギュレーションレジスタ読み出し (Peek コマンド )」を参照してください。


外部メモリ読み出し

(Xmem コマンド )

「X {8-digit hex value}」

「8-digit hex value」は、外部メモリから 1 バイトを読み出すために使用するアドレス。

エラー分類が有効でアイドルステートの場合に有効。


「R xx」

xx = Don’t care


フレームアドレス変換

LFA <-> PFA

(Translate コマンド )

「T {n-digit hex value}」

「n-digit hex value」はエラー挿入コマンドで使用する PFA または LFA アドレスフォーマット。UltraScale では n = 10、 UltraScale+ では n = 11。


表 3‐5: UART コマンドと使用方法 (続き)



ssハードウェア slr 番号 (2 ビット )有効な範囲: 0 ～ 3

LLLLLLLLLLLLLLLLL

または

LLLLLLLLLLLLLLLLLL

リニアフレームアドレス (UltraScale では 17 ビット、 UltraScale+ では 18 ビット )有効な範囲: 0 ～ Max Frame – 2

wwwwwww

ワードアドレス (7 ビット )UltraScale の有効な範囲: 0 ～ 122それ以外の有効な範囲: 0 ～ 92

bbbbbビットアドレス (5 ビット )有効な範囲: 0 ～ 31


ss ハードウェア slr (2 ビット )

rrrrr レジスタアドレス (5 ビット )






特定ステートへの移行

特定ステートへの移行コマンド「O」、「I」、「D」、「U」を実行すると、コントローラーのステートを監視、アイドル、検出、診断スキャンへとそれぞれ移行させることができます。

コンフィギュレーションフレーム読み出し (Query コマンド )

このコマンドを実行すると、コンフィギュレーションフレームの内容が読み出されます。エラー挿入コマンドで使用するのと同じアドレス値を 16 進数で指定します (表 3-5 参照)。このコマンドのフォーマットは次のとおりです。

Q {n-digit hex value}


注記: フレームアドレスのワードおよびビットフィールドは無視されます。このコマンドを実行すると、常にフレームの内容全体が返されます。

UltraScale デバイスで Query コマンドを実行すると、コントローラーは 123 行 (ワード 0 からワード 122 の順) の 16 進数データ (31:0) を返します。次に示すデータはすべて 0 ですが、必ずしもそうとは限りません。

I> Q C000000000000000000000000000000000...000000000000000000000000I>

UltraScale+ デバイスで Query コマンドを実行すると、コントローラーは 93 行 (ワード 0 からワード 92 の順) の 16 進数データ (31:0) を返します。次に示すデータはすべて 0 ですが、必ずしもそうとは限りません。

I> Q C0000000000 000000000000000000000000...000000000000000000000000I>

エラー挿入を実行する際にコンフィギュレーションメモリの内容を読み出すと、コントローラーの動作のデバッグに役立ちます。

推奨: エラー挿入を実行する際は、その前後でコンフィギュレーションメモリの内容を読み出すことを推奨します。これにより、エラー挿入によってコンフィギュレーションメモリの内容が変化したかどうか、そして挿入したエラーをコントローラーが検出および訂正したかどうかを確認できます。






コンフィギュレーションレジスタ読み出し (Peek コマンド )

このコマンドを実行すると、指定したコンフィギュレーションレジスタが読み出され、その内容が報告されます。このコマンドのフォーマットは次のとおりです。

P {2-digit hex value}

表 3-6 に、コントローラーによる読み出しがサポートされているレジスタの一覧を示します。

Peek コマンドを実行すると、コントローラーは次のような 16 進数フォーマットでデータを返します。

I> P 0020BD8EDEI>

このコマンドおよび返されるデータのフォーマットは、 UltraScale デバイスと UltraScale+ デバイスで共通です。

このレジスタの詳細は、『UltraScale アーキテクチャコンフィギュレーションユーザーガイド』 (UG570) [参照 2] を参照してください。

外部メモリ読み出し (Xmem コマンド )

このコマンドを実行すると、外部メモリの内容が読み出されます。 1 つのアドレスを読み出すと、 1 バイトのデータが返されます。このコマンドのフォーマットは次のとおりです。

X {8-digit hex value}

外部メモリ読み出しコマンドを実行すると、コントローラーは次のような 16 進数フォーマットでデータを返します。

I> X 0000000094I>

このコマンドおよび返されるデータのフォーマットは、 UltraScale デバイスと UltraScale+ デバイスで共通です。

表 3‐6: Peek コマンドで読み出し可能なコンフィギュレーションレジスタ

名前アドレス

CRC 00000

FAR 00001

CMD 00100

CTL0 00101

MASK 00110

STAT 00111

COR0 01001

IDCODE 01100

AXSS 01101

COR1 01110

WBSTAR 10000

TIMER 10001

BOOTSTS 10110






エラー挿入

「N」コマンドを実行すると、 LFA を使用してエラー挿入が実行されます。このコマンドは、コントローラーがアイドルステートの場合のみ実行できます。このコマンドのフォーマットは次のとおりです。

N {n-digit hex value}


このコマンドは、コマンドインターフェイスのエラー挿入コマンドと同じ働きをします。このコマンドで指定する 16 進数値は、表 3-5 で説明しています。エラー挿入を利用してデザインをテストする方法の詳細は、付録 E 「エラー挿入のガイダンス」を参照してください。また、付録 C 「評価ボードを使用した SEM Controller の動作デモ」の例も参照してください。


「S」コマンドはコントローラーに対してステータスレポートの出力を要求します。ステータスレポートのフォーマットは、コントローラーから出力されるステータスレポートについて説明したセクションを参照してください。このコマンドは、コントローラーがアイドルステートまたは監視ステートの場合のみ実行できます。

フレームアドレス変換 (Translate コマンド )

このコマンドは LFA アドレスと PFA アドレスを双方向に変換するコマンドで、デバッグに役立ちます。エラー挿入コマンドで使用するのと同じ値を 16 進数で指定します (表 3-5 参照)。このコマンドのフォーマットは次のとおりです。

T {n-digit hex value}


UltraScale デバイスでフレームアドレス変換コマンドを実行すると、コントローラーは次のような 16 進数フォーマットでデータを返します。

I> T C0000000000000000000I>

UltraScale+ デバイスでフレームアドレス変換コマンドを実行すると、コントローラーは次のような 16 進数フォーマットでデータを返します。

I> T C000000000000000000000I>


「R」コマンドはソフトウェアリセットを実行します。このコマンドは、コントローラーがアイドルステートの場合のみ実行できます。このコマンドのフォーマットは次のとおりです。

R {2-digit hex value}

このコマンドの使用方法の詳細は、表 3-5 を参照してください。

このコマンドが正しく実行されると、コントローラーは初期化レポートを出力します。詳細は、このレポートについて説明したセクションを参照してください。

コマンドが無効な場合の動作

無効なコマンドを発行しても実行されません。ステータス信号は変化せず、コマンドのエコーバックもありません。不完全なコマンド (引数が不完全または誤ったコマンド ) はエコーバックされますが、コントローラーによって実行されることはありません。







モニターインターフェイスは 2 つの信号で構成され、これらを使用してコマンドおよびステータス情報を交換するための RS-232 プロトコル互換の全二重シリアルポートを実装します。次の設定を使用します。

• ボー : 115200

• 設定: 8-N-1

• フロー制御: なし

• 端末設定: VT100

° TX 改行: CR (改行コードとして CR [0x0D] を端末から送信)

° RX 改行: CR+LF (改行コードとして CR [0x0D] を端末が受信し、 CR+LF [0x0D, 0x0A] に展開)

° ローカルエコー : なし

UART インターフェイスに接続する外部デバイスは、この設定をサポートしている必要があります。図 3-14 に、送信および受信のスイッチング動作を示します。

送信および受信タイミングは、システムレベルサンプルデザイン内部でカウンターを使用して生成される 16x ビットレートイネーブル信号から求めます。このカウンターの動作は 0 からカウントを開始し、ターミナルカウント (カウンターを同期的にリセットするために検出および使用する条件) までカウントします。ターミナルカウント出力は、送信および受信プロセスにもタイムベースとして供給されます。

115200 ボーは標準ビットレートであり、さまざまな入力クロック周波数から生成できるため、互換性には優れています。このため、システムレベルサンプルデザインでもこのボーレートを使用しています。

実際には、データレートとレイテンシの両方を考慮して必要な通信パフォーマンスが得られるようにボーレートを選択してください。通信パフォーマンスが低いとコントローラーでスロットリングが発生する可能性があります。このため、より高いビットレートの使用を強く推奨します。 9,600、 230,400、 460,800、 921,600 ボーなどの標準ビットレートを含め、さまざまな設定が可能です。

システムレベルサンプルデザインの UART ヘルパーブロックでは、パラメーター V_ENABLETIME で通信ビットレートを設定します。 V_ENABLETIME の値は次の式で求めます。

V_ENABLETIME= round to integer 式 3‐1

上の式で V_ENABLETIME を求めると、大で ±0.5 の丸め誤差が発生します。この誤差により、公称ビットレートとは若干異なるビットレートが生成されます。 RS-232 デバイス間での許容誤差が 2% とすると、デバイスあたりのビットレートの許容誤差は ±1% までとなります。

例: 入力クロックが 66MHz、目的のビットレートが 115200 ボートの場合。

V_ENABLETIME= round to integer =35 式 3‐2

実際に得られるビットレートは約 114583 ボーで、公称ビットレートの 115200 ボーに対する誤差は -0.54% です。これは、誤差が ±1% 以内であるため許容範囲内です。

公称ビットレートに対する誤差が ±1% を超える場合、誤差が小さくなるようにビットレートと入力クロック周波数の組み合わせを変えてください。それ以外のスイッチ特性は定義されていません。

ヒント : システムレベルサンプルデザインに付属する UART ヘルパーブロックのターゲットボーレートは 115,200 ボーです。ほとんどのクロック周波数では、実際に得られるビットレートの誤差が ±1% 以内に抑えられますが、クロック周波数が低い場合はこの許容誤差を超える可能性があります。この場合、ボーレートと入力クロック周波数を変更する必要があります。


図 3‐14: UART インターフェイスのスイッチ特性

uart_txuart_rx start d0 d1 d2 d3 d4 d5 d6 d7 stop

input c lock frequency16 nominal bitrate

------------------------------------------------------------ 1–

6600000016 115200------------------------------ 1–






電気的に、 UART インターフェイスが使用する I/O ピンは LVCMOS 信号で、ほかのデバイスとの接続に適しています。特別な I/O モードは必要ありません。 RS-232 との完全な電気的互換性が必要な場合は、外部レベル変換器を使用する必要があります。


これまで説明した以外に特別なシステムレベル要件はありません。

フェッチインターフェイス

フェッチインターフェイスは、コントローラーが外部ソースからデータを要求する手段として使用します。このインターフェイスは、エラー分類機能を有効にした場合のみ存在します。このインターフェイスのポートの一覧および定義については、表 2-23 を参照してください。

表 2-23 で説明したように、 fetch_tbladdr 入力を使用して外部メモリソース内のコントローラーデータテーブルの開始アドレスを指定します。図 3-15 は、これを視覚的に表現したものです。


図 3‐15: fetch_tbladdr 入力

SPI Flash Memory

Memory Addr

y-1y-2..

CB0[31:0]

First byte for EB data for SLR 0

CB1[31:0]CB2[31:0]

CB0

CB1

CB2

0x



.

.

.21

Fetch_tbladdr = 0






コントローラーは、fetch_tbladdr (TB) アドレスの下位 31 ビットに SLR0 のエッセンシャルビットデータの初のバイトのアドレスを指し示す分類ベース (CB0) ポインターが含まれるものと見なします。ターゲットデバイスがマルチ SLR デバイスの場合、次の fetch_tbladdr の 32 ビットに SLR1 のエッセンシャルビットデータの初のバイトのアドレスを指し示す分類ベース (CB1) ポインターが含まれます (以降同様)。ターゲットがモノリシックデバイスの場合、必要な分類ベースポインターは 1 つです。

fetch_tbladdr (TB) と分類ベースポインター (CBn) をユーザーが定義できるため、 SPI フラッシュメモリにほかのデータを格納し、必要に応じてメモリの内容を構成可能です。

コントローラーが正しい TB および CB 値を使用していることを確認できるように、これらの値はモニターインターフェイスから出力されるステータスレポートでも報告されます。「ステータスレポート」を参照してください。

SPI フラッシュプログラミングファイルを生成する付属の makedata.tcl スクリプトは fetch_tbladdr の値が 0 と仮定しており、 TB および CB 値をカスタマイズする場合はスクリプトを変更する必要があります。 TB および CB 値を変更する場合、 SEM Controller が必要とするデータ (分類ベースポインターとエッセンシャルビットデータ ) を終的にはユーザーの責任で適切なアドレス空間に定義および配置する必要があります。

ユーザーの便宜のため、システムレベルサンプルデザインにはサンプルとして SPI フラッシュマスターヘルパーブロックが用意されており、フェッチインターフェイスはこのヘルパーブロックを経由して外部 SPI フラッシュからデータを取得します。次のセクションでは、 SPI インターフェイスにおける SPI フラッシュマスターヘルパーブロックの動作について説明します。

SPI 以外のインターフェイスが必要な場合、 SPI フラッシュマスターヘルパーブロックを別の機能に置き換えることができます。たとえば、パラレルフラッシュメモリコントローラーや、プロセス間通信をサポートする別の方式にこの SPI フラッシュマスターヘルパーブロックを置き換えることができます。このようなカスタマイズをする場合は、付録 I 「フェッチインターフェイスのシグナリングとプロトコル」のフェッチインターフェイスのシグナリングについての説明を参照してください。

SPI インターフェイス

SPI インターフェイスは 4 つの信号で構成され、これらを使用して SPI バスプロトコル互換の全二重シリアルポートを実装します。このインターフェイスは、エラー分類機能を有効にした場合のみ存在します。この機能を実装するには、外部ストレージが必要です。システムレベルサンプルデザインでは、 SPI バスマスターに機能が固定された SPI フラッシュマスターヘルパーブロックを使用して外部 SPI フラッシュデバイスからデータをフェッチします。表 3-7 に、サポートされる各 FPGA で必要な SPI フラッシュの容量を示します。

表 3‐7:外部ストレージの要件

デバイスエラー分類に必要なストレージ容量 (Mb)

UltraScale

XCKU035 128

XCKU040 128

XCKU060 256

XCKU085 512

XCKU115 512

XCVU065 256

XCVU080 256

XCVU095 256

XCVU125 512

XCVU160 1,024

XCVU190 1,024

XCVU440(1) 1,024






UltraScale+

XCKU3P 128

XCKU5P 128

XCKU9P 256

XCKU11P 256

XCKU13P 256

XCKU15P 256

XCVU3P 256

XCVU5P 512

XCVU7P 512

XCVU9P 512

XCVU11P 1024

XCVU13P 1024

XCVU27P 1024

XCVU29P 1024

XCVU31P 256

XCVU33P 256

XCVU35P 512

XCVU37P 1024

XCZU2 32

XCZU3 32

XCZU4 64

XCZU5 64

XCZU6 256

XCZU7 256

XCZU9 256

XCZU11 256

XCZU15 256

XCZU17 256

XCZU19 256

表 3‐7:外部ストレージの要件 (続き)







SPI フラッシュマスターヘルパーブロックは高速読み出しコマンド (0x0B) を使用します。また、何種類かある SPI フラッシュファミリの 1 つをサポートするように設定できます。デフォルトでサポートされるファミリは、表 3-7 に示した外部ストレージの要件によって異なります。システムレベルサンプルデザインの SPI フラッシュマスターヘルパーブロックには、 SPI フラッシュデバイスに送信するコマンドシーケンスを制御するためのパラメーターが 3 つあります。

• B_ISSUE_WREN – デバイスの動作を変更するコマンドの前に書き込みイネーブルコマンド (0x06) を発行する必要があるかどうかを示します。通常は「0」に設定し、 N25Q および MT25Q デバイスの場合のみ「1」に設定します。

• B_ISSUE_WVCR – 高速読み出しダミーサイクル数を明示的に 8 サイクルに設定するために揮発性コンフィギュレーションレジスタへの書き込みコマンド (0x81) を発行する必要があるかどうかを示します。 SPI フラッシュマスターヘルパーブロック内部のステートマシンはバイト指向のため、高速読み出しダミーサイクル数を 8 に設定する必要があります。揮発性コンフィギュレーションレジスタのデータは上書きされます (0x8B)。通常は「0」に設定し、 N25Q および MT25Q デバイスの場合のみ「1」に設定します。

• B_ISSUE_EN4B – 4 バイトアドレス指定モードに明示的に移行するために 4 バイトアドレス指定イネーブルコマンド (0xB7) を発行する必要があるかどうかを示します。 128Mb を超えるデバイスでは「1」に設定します。

ストレージ要件が 128Mb 以下の場合、 SPI フラッシュマスターヘルパーブロックはデフォルトで M25P デバイスをサポートします (B_ISSUE_WREN = 0、 B_ISSUE_WVCR = 0、 B_ISSUE_EN4B = 0)。これらのデバイスは 4 バイトアドレス指定モードには対応しません。

ストレージ要件が 128Mb を超える場合、 SPI フラッシュマスターヘルパーブロックはデフォルトでより大容量の N25Q および MT25Q デバイスをサポートします (B_ISSUE_WREN = 1、 B_ISSUE_WVCR = 1、B_ISSUE_EN4B = 1)。これらのデバイスは 4 バイトアドレス指定モードに対応します。

これ以外に、ストレージ要件が 128Mb 以下の場合は小容量の N25Q デバイス (B_ISSUE_WREN = 1、B_ISSUE_WVCR = 1、 B_ISSUE_EN4B = 0)、ストレージ要件が 128Mb を超える場合は大容量の MX25 デバイス (B_ISSUE_WREN = 0、 B_ISSUE_WVCR = 0、 B_ISSUE_EN4B = 1) もサポートされます。

注記: SPI フラッシュマスターヘルパーブロックのインプリメンテーションがサポートする SPI フラッシュ読み出しコマンドは、 1 つの SPI フラッシュデバイスに対する SPI モード 0 (CPOL = 0、 CPHA = 0) の高速読み出しのみです。

UltraScale+ (続き )

XCZU21DR 256

XCZU25DR 256

XCZU27DR 256

XCZU28DR 256

XCZU29DR 256

注記:1. XCVU440 では、1 回のコマンドでダイ境界をまたいでシームレスに読み出しが可能な

SPI フラッシュメモリデバイス (MT25Q など) を使用する必要があります。

表 3‐7:外部ストレージの要件 (続き)







図 3-16 に、 FPGA と SPI フラッシュデバイスの接続を示します。「LT」はレベル変換器を表しています。一般的な SPI フラッシュデバイスは 3.3V I/O を使用しますが、 FPGA または I/O バンク電圧によってはこの電圧を利用できないことがあるため、レベル変換器が必要です。

SPI バスの性能を大化するには、伝搬遅延の小さいレベル変換器を使用する必要があります。 SPI バスの性能がシステムレベルサンプルデザイン全体の大動作周波数に影響することがあります。

注記: スイッチング動作、システムレベル要件、および SPI バスタイミングバジェット例については、付録 G 「SPI バスタイミングバジェット」を参照してください。

エラー分類機能を使用する場合、コントローラーは外部に格納したデータにアクセスする必要があります。このデータは、 write_bitstream によって FPGA のプログラミングファイルと同時に作成されます。

FPGA デザインを変更して新しいプログラミングファイルを作成する際は、コントローラーが使用する外部データファイルも更新する必要があります。ハードウェアデザインを新しいプログラミングファイルで更新する際に、外部に格納するデータも更新する必要があります。

重要: データの整合性が失われると、不正確な値の分類レポートが出力され、誤った軽減措置が実行されることがあります。プログラミングファイルと外部データファイルが常に同期するような更新方法を採用することを推奨します。

補助インターフェイス

このインターフェイスは、コンフィギュレーションメモリのスキャンではコントローラーが直接監視できない場所で発生したソフトエラーイベントをコントローラーに通知する手段として使用します。たとえばブロック RAM に ECC 機能を使用しているデザインの場合、 ECC 機能によって検出したエラーをこのインターフェイスの入力にできます。コントローラーが監視または検出ステートの場合、このインターフェイス経由で通知されたエラーが検出され、それに応じてモニターおよびステータスインターフェイスの出力が変化します。同じエラーが複数回報告されるのを防ぐため、 1 つのエラーを報告する際は 1 クロックサイクルのみパルスしてください。

このインターフェイスを使用しない場合は、インターフェイスの入力を Low に接続する必要があります。


図 3‐16: SPI フラッシュデバイスの接続 (レベル変換器を含む)

FPGA

spi_d

spi_q

spi_c

spi_s_n

SPI Flash

LT

LT

d q

s_n

c







図 3-17 にスイッチ特性を示します。波形の前半で、補助インターフェイスによって訂正可能なエッセンシャルエラーが報告され、その結果、 status_essential 信号が High にアサートされています。

これにより、コントローラーが監視ステートの場合は次のようなエラーレポートがモニターインターフェイスに出力されます。

aux_error_cr_esSC 04AUXTS {8-digit hex value}FC 00SC 08FC 40SC 02

aux_error_cr_neSC 04AUXTS {8-digit hex value}FC 40SC 08FC 00SC 02

これらのエラーが報告されるのは、コントローラーが監視または検出ステートの場合のみです。

波形の後半では、補助インターフェイスによって訂正不能エラーが報告されています。この結果、コントローラーはアイドルステートへ移行し、コントローラー自身が訂正不能エラーを検出した場合と同じ動作をします。エラー状態はモニターインターフェイスとステータスインターフェイスの両方に反映されます。これにより、コントローラーが監視ステートの場合は次のようなエラーレポートがモニターインターフェイスに出力されます。

aux_error_ucSC 04AUXTS {8-digit hex value}FC 20SC 08FC 60SC 00


図 3‐17:補助インターフェイスのスイッチング動作







このインターフェイスは、 SEM Controller を使用してデバイスで発生したソフトエラーイベントのすべてのレポートを統合し、ステータスおよびモニターインターフェイスをシステムレベルで使用してエラーに対する措置を実行する場合に使用します。または、このような機能を IP 外部に作成し、これらエラーに対するシステム応答を独立して管理することもできます。

システム

このソフトエラー軽減ソリューションは自律動作が可能ですが、多くのアプリケーションではこのソリューションをシステムレベルの監視機能と組み合わせて使用します。システムレベルの監視機能を実装すべきかどうか、そしてこの監視機能にどれだけの役割を持たせるかは、個々のシステムにより異なります。

注記:次に示す参照事項は、各インターフェイスのシステムレベル要件の欄で説明した内容も含みます。

システムレベルの監視機能を用いてソフトエラー軽減ソリューションを監視する方法には、次のものがあります。

• ソフトエラー軽減ソリューションを監視し、ソフトエラーイベントへの応答としてシステムレベルでの追加措置が必要かどうかを判定する。これには、検出したすべてのソフトエラーイベントのログを記録するといった単純なものから、エラー分類値やエラーが訂正可能かどうかなどの要因に基づいてシステムレベルで適切な応答を決定するといった複雑な措置までさまざまなものがあります。これらの各種要因を解析して、デザインのリセット、 FPGA のリコンフィギュレーション、システムの再起動などシステムレベルの措置を実行します。

軽減 (+ テスト ) モードでソフトエラー軽減ソリューションのイベントレポートを監視するには、ステータスインターフェイスの status_correction および status_uncorrectable 信号、ステータスインターフェイスの status_classification および status_essential 信号、または UART インターフェイスの uart_tx 信号によるエラー検出、訂正、分類レポートを使用します。

検出 (+ テスト ) モードでソフトエラー軽減ソリューションのイベントレポートを監視するには、ステータスインターフェイスの status_uncorrectable、または UART インターフェイスの uart_tx 信号によるエラー検出レポートを使用します。

• ソフトエラー軽減ソリューションを監視し、ソリューション自体に問題がないかを確認する。第 2 章の「ソリューションの信頼性」数値を示して説明したとおり、ごくわずかながらソフトエラー軽減ソリューション自体が障害を起こす可能性があります。統計的に、この障害はコントローラーのすべてのステートで発生する可能性があります。

° ブートおよび初期化ステート – ソフトエラー軽減ソリューションがブートおよび初期化の後、選択したモードに応じて監視、検出、アイドルステートのいずれかに正しく移行するかを監視します。ザイリンクスは、ソフトエラー軽減ソリューションがブートおよび初期化を実行して上記いずれかのステートへ移行する時間を表 2-5 および式 2-1 で定義しています。ただしこれは cap_gnt 信号がアサートされており、ソフトエラー軽減ソリューションが ICAP プリミティブ経由で FPGA コンフィギュレーションロジックを利用でき、モニターインターフェイスでスロットリングが発生していない場合の値です。

ソフトエラー軽減ソリューションが初期化に失敗または正しいステートへの移行に失敗する主な理由は、ソフトエラーイベントではなくデザインエラーです。これには、未使用ポートの接続の誤り、cap_grant 信号の制御の誤り、 ICAP 共有の実装の誤りなどがあります。また、ソフトエラー軽減ソリューションが ICAP プリミティブ経由で FPGA コンフィギュレーションロジックを利用できないことが原因となることもあります。この問題が発生する理由としては、ソフトエラー軽減ソリューションと互換性のないビットストリームオプションを使用した、 JTAG 経由で FPGA に発行された FPGA コンフィギュレーション命令をシステムレベルの JTAG コントローラーが正しく完了またはクリアできなかった、などが考えられます。

ソリューションが初期化を完了して正しいステートへ移行したことを確認するには、システムレベルの監視機能でステータスインターフェイスの status_initialization および該当する status_* 信号がアサートされるのを監視するか (図 3-5 ～図 3-7 参照)、 UART インターフェイスの uart_tx 信号から出力される初期化レポートを監視します。

このステートでは、 CRC エラーステータス信号の INIT_B は無視できます。






° 監視ステート (軽減 (+ テスト ) モードの場合) – コントローラーはほとんどすべての時間をこのステートで費やします。このステートのコントローラーを監視する方法は少なくとも 3 つあり、コントローラーの状態に関して得られる情報がそれぞれ少しずつ異なります。

- コントローラーのハートビート信号 status_heartbeat – この信号は、ソフトエラー軽減ソリューションから直接出力されます。この信号は、リードバックプロセスが動作中であることを示すパルスです (仕様の詳細は「ステータスインターフェイス」参照)。監視ステート中にこのパルスが仕様から逸脱した場合、システムレベルの監視機能はリードバックプロセスに障害が発生したものと判定できます。これは訂正不能なエッセンシャルエラーです。

UltraScale および UltraScale+ SSI へのインプリメンテーションでは SLR ごとに status_heartbeat 出力があるため、すべての SLR からのハートビート信号を監視する必要があります。

status_heartbeat はほかのコントローラーステートでは未定義のため、監視ステートでのみ監視するようにしてください。

第 3 章「ハートビート」を参照してください。

- CRC エラーステータス信号 INIT_B – この信号は、リードバックプロセスから直接出力されます。リードバックプロセスで CRC エラーが検出されると、 INIT_B がアサートされます。監視ステート中に INIT_B がアサートされてから 1 秒以内に訂正ステートへ移行しない場合、コントローラーに障害が発生しています。ステートの移行は、ステータスインターフェイスの status_correction 信号またはモニターインターフェイスのステート変化レポートで確認できます。これは訂正不能なエッセンシャルエラーです。

UltraScale および UltraScale+ SSI デバイスへのインプリメンテーションでは SLR ごとに内部 CRC エラーステータス信号があるため、これらの信号を OR を介して 1 つの INIT_B デバイスピンに接続します。 UltraScale デバイスへのインプリメンテーションでは、ステータスインターフェイスの status_correction 信号は各 SLR に 1 つずつあります。

CRC エラーステータス信号 INIT_B は監視および検出ステートでのみ監視するようにしてください。それ以外のステートでは、この信号は未定義です。

- コントローラーのステータスコマンドおよびレポート – UART インターフェイスの uart_rx および uart_tx 信号を使用してシステムレベルの監視機能から周期的にステータスコマンドを送信し、予想されるステータスレポートが出力されるかを確認します。コントローラーのステートが変化していない場合、 1 秒以内に予想されるステータスレポートが出力されなければ、システムレベルの監視機能はコントローラーに障害が発生したものと判定できます。これは訂正不能なエッセンシャルエラーです。

この方法を使用する場合、「コントローラー応答なし」条件を検出する時間を許容範囲内としつつ、ステータスコマンドの送信間隔をなるべく長くする必要があります。

ステータスコマンドとレポートをコントローラーで処理する方法は、レイテンシを増大させる要因となることがあります。たとえばステータスコマンドを 60 秒ごとに送信するのは、全般的な動作のレイテンシをそれほど増やすことなく、ほとんど発生しない「コントローラー応答なし」条件を防ぐことができるため、妥当なトレードオフといえます。これに対し、ステータスコマンドを 1 秒ごとに送信するのは賢明な選択とはいえません。この場合、ステータスレポートによって UART ヘルパーブロックの送信バッファーが空になることがほとんどなく、モニターインターフェイスでスロットリングが発生してエラー検出、訂正、および分類のレイテンシが増大します。

コントローラーのステータスコマンドおよびレポートを使用する方法は、監視およびアイドルステートでしか利用できない点に注意が必要です。ほかのステート中にステータスコマンドを送信した場合、UART ヘルパーブロックの受信バッファーがオーバーフローしなければコマンドはバッファー内に残り、監視またはアイドルステートへ移行した時点で処理されます。






° 訂正および分類ステート – モニターインターフェイスでスロットリングが発生していなければ、ソフトエラー軽減ソリューションは訂正および分類ステートに表 2-9/式 2-3 および表 2-10/式 2-4 に示した時間内に遷移します。ソフトエラーが発生する確率は非常に低いため、コントローラーがこれらのステートで費やす時間は非常に短く、通常はすぐに監視ステート (またはごくまれにアイドルステート ) に戻ります。

ステータスインターフェイスの status_correction および status_classification 信号、またはモニターインターフェイスのステート変化レポートを監視して、コントローラーが訂正または分類ステートにとどまる時間が 1 秒を超えたことが確認されると、システムレベルの監視機能はコントローラーに障害が発生したものと判定できます。これは訂正不能なエッセンシャルエラーです。

これとは別に、ソフトエラー軽減ソリューションが同じアドレスを繰り返し訂正していないかをシステムレベルの監視機能で監視することもできます。このような症状が起こることはほとんどありませんが、その原因はコントローラーのソフトエラーやデバイス自体のハードエラーなどいくつか考えられます。

° 検出モードまたはステート – コントローラーは、初期化後またはコマンドで移行後、ほとんどすべての時間をこのステートで費やします。このステートのコントローラーを監視する方法は少なくとも 2 つあり、コントローラーの状態に関して得られる情報がそれぞれ少しずつ異なります。

- コントローラーのハートビート信号 status_heartbeat – この信号は、ソフトエラー軽減ソリューションから直接出力されます。この信号は、リードバックプロセスが動作中であることを示すパルスです (仕様の詳細は「ステータスインターフェイス」参照)。検出ステート中にこのパルスが仕様から逸脱した場合、システムレベルの監視機能はリードバックプロセスに障害が発生したものと判定できます。これは訂正不能なエッセンシャルエラーです。



- CRC エラーステータス信号 INIT_B – この信号は、リードバックプロセスから直接出力されます。リードバックプロセスで CRC エラーが検出されると、 INIT_B がアサートされます。検出ステート中に INIT_B がアサートされてから 1 秒以内にアイドルステートへ移行しない場合、コントローラーに障害が発生しています。アイドルステートへ移行したかどうかは、ステータスインターフェイスまたはモニターインターフェイスのステート変化レポートで確認できます。これは訂正不能なエッセンシャルエラーです。

UltraScale および UltraScale+ SSI デバイスへのインプリメンテーションでは SLR ごとに内部 CRC エラーステータス信号があるため、これらの信号を OR を介して 1 つの INIT_B デバイスピンに接続します。ただしステータスインターフェイスは SLR ごとにアイドルステートのステータスインターフェイスを個別に監視してアイドルステートへの移行を確認する必要があります。

CRC エラーステータス信号 INIT_B は監視および検出ステートでのみ監視するようにしてください。それ以外のステートでは、この信号は未定義です。

° 診断スキャンステート – コマンドによってこのステートへ移行すると、コントローラーはデバイスのすべてのコンフィギュレーションメモリをスキャンし、検出したすべての ECC エラーを報告します。このステートのコントローラーを監視するには、次の方法を推奨します。

- コントローラーのハートビート信号 status_heartbeat – この信号は、ソフトエラー軽減ソリューションから直接出力されます。この信号は、リードバックプロセスが動作中であることを示すパルスです (仕様の詳細は「ステータスインターフェイス」参照)。診断スキャンステート中にこのパルスが仕様から逸脱した場合、システムレベルの監視機能はリードバックプロセスに障害が発生したものと判定できます。これは訂正不能なエッセンシャルエラーです。








° アイドルおよび挿入ステート – コントローラーがアイドルステートへ移行するのは、訂正不能エラーが発生した場合かアイドルステートへの移行コマンドが実行された場合のみです。訂正不能エラーによってアイドルステートへ移行した場合は、イベントレポートの監視に関するセクションを参照してください。アイドルステートへの移行コマンドは、主にエラー挿入や ICAP 共有などほかのコマンドを発行するために使用します。「監視ステート」の「コントローラーのステータスコマンドおよびレポート」で説明した方法をアイドルステートで実装するのは、アプリケーションレベルでほかのプロセスによって発行されたコマンドと競合する可能性があるため推奨しません。発行済みのコマンドが完了して 1 秒以内に応答が生成されることをアプリケーションレベルプロセスで確認する方法を推奨します。 1 秒以内に応答が生成されない場合は訂正不能なエッセンシャルエラーが発生しており、アプリケーションからシステムに報告する必要があります。

° 重大エラーステート – コントローラーは、内部ステートに不整合性が検出された場合のみこのステートへ移行します。このステートへ移行すると、ステータスインターフェイスの 7 つのステート信号がすべてアサートされます。モニターインターフェイスから HLT メッセージが出力されることもあります。 UltraScale SSI デバイスへのインプリメンテーションでは複数のコントローラーインスタンスが存在しており、少なくとも 1 つのコントローラーインスタンスが動作を停止するか、または訂正不能エラーイベントによってアイドルステートへ移行するとソリューション全体が重大エラーステートと見なされます。これは訂正不能なエッセンシャルエラーです。

ここまでに説明したシステムレベル監視機能の実装は任意ですが、軽減 (+テスト ) モードで IP を使用する場合は、コントローラーの正常動作を確認するために少なくとも次のシステムレベル監視機能を実装することを推奨します。

1. コントローラーがブートおよび初期化ステートを完了し、選択したモードに応じて監視、アイドル、または検出ステートに正しく移行したことを確認してください。ブートおよび初期化ステートでは INIT_B 信号は監視対象ではありません。

2. 監視、検出、診断スキャンステートでは status_heartbeat 信号を監視し、「ハートビート」に示した仕様値を満たしていることを確認してください。この監視ロジックの例は、サンプルデザインに含まれています。第 5 章の「機能」を参照してください。

3. 軽減 (+ テスト ) および検出 (+ テスト ) モードの場合、コントローラーが停止またはアイドルステートへ移行していないことを確認してください。コントローラーが停止またはアイドルステートへ移行すると軽減機能が実行されず、 SEU が発生しても検出、訂正されません。これは、 status_* 信号を監視して確認できます。コントローラーの動作停止を検出するロジックの例は、サンプルデザインに含まれています。第 5 章の「機能」を参照してください。

4. 監視および検出ステートでは、 INIT_B 信号を監視してください。 INIT_B がアサートされてから 1 秒以内にコントローラーが監視ステートから訂正ステート、または検出ステートからアイドルステートへ移行しない場合、訂正不能エラーが発生したかエラーに対してコントローラーの軽減機能が応答していない ( 「CRC エラーステータス信号 INIT_B」参照) ことを示します。

5. 後で必要になったときに IP の動作を簡単にデバッグできるように、 monitor_txdata[7:0] 出力を FIFO バッファーに格納してください。これは、特にシステムがモニターインターフェイスを使用していない場合に推奨します。「モニターインターフェイス」を参照してください。






コンフィギュレーションメモリのマスク

デザインによっては、動作中にコンフィギュレーションメモリの一部のビット値が変化することがあります。よくあるのは、分散 RAM やシフトレジスタなどの LUTRAM 機能を実装するようにロジックスライスリソースを設定した場合です。また、ダイナミックリコンフィギュレーションポートを持つその他のタイプのリソースがデザインの動作中に更新される場合にもこのような状況が発生します。

エラーの誤検出を防ぐには、これらリソースに関連するメモリビットはマスクしておき、 CRC および ECC 計算から除外しておく必要があります。ザイリンクスの FPGA デバイスには、このようなエラー誤検出を防ぐためにコンフィギュレーションメモリのマスク機能が実装されています。マスクを有効にするかどうかは、グローバル制御信号の GLUTMASK_B で選択します。コントローラーはコンフィギュレーションメモリのマスクを常に有効にします。

UltraScale デバイスはリソースレベルで細粒度のマスクをインプリメントしています。つまり、個々のリソースをダイナミック動作に設定すると、そのリソースのコンフィギュレーションメモリビットがマスクされます。無関係なメモリビットには影響せず、必要なメモリビットのみがマスクされます。マスクしたビットは、コントローラーによる監視を受けません。

マスクしたリソースに関係するコンフィギュレーションメモリビットを読み出すと、定数値 (論理 1 または論理 0) が返されます。これにより、エラーの誤検出を防ぎます。マスクされたリソースに関係するコンフィギュレーションメモリビットへの書き込みは破棄されます。これにより、ダイナミックステートエレメントの内容を古いデータで上書きするのを防ぎます。ただしその副作用として、マスクしたリソースにエラーを挿入してもエラーが検出されません。

LUTRAM 機能など多くの場合には、ユーザーデザインでこれらのビットに対するデータ保護を実装してソフトエラーを軽減できます。または、ユーザーデザインを変更してコンフィギュレーションメモリのマスクを必要とするような機能を使用しないようにする方法もあります。

リセット

デバイスのコンフィギュレーション全体をリセットすることはできないため、コントローラーにはリセットがありません。このコントローラーは、デバイスのコンフィギュレーション完了から電源停止またはリコンフィギュレーションまでの間、デバイスのコンフィギュレーションを監視します。また、オリジナルのコンフィギュレーションステートを監視および維持することを役割とし、エラーを含む可能性が高い暫定ステートからは再起動しません。





第 4章

デザインフローの手順この章では、コアのカスタマイズと生成、制約、およびシミュレーション/合成/インプリメンテーションの手順について説明します。一般的な Vivado® デザインフローおよび Vivado IP インテグレーターの詳細は、次の Vivado Design Suite ユーザーガイドを参照してください。

• 『Vivado Design Suite ユーザーガイド : IP を使用した設計』 (UG896) [参照 11]

• 『Vivado Design Suite ユーザーガイド : 入門』 (UG910) [参照 13]

• 『Vivado Design Suite ユーザーガイド : ロジックシミュレーション』 (UG900) [参照 9]

コアのカスタマイズおよび生成

ここでは、ザイリンクスツールを使用し、 Vivado Design Suite でコアをカスタマイズおよび生成する方法について説明します。 SEM Controller はデバイスへの依存性があるため、 SEM IP をサポートしたデバイスを選択する必要があります。コアをカスタマイズして生成するには、まず Vivado IP カタログで [FPGA Features and Design] → [Soft Error Mitigation] を展開し、その下にある [UltraScale Soft Error Mitigation] をクリックして選択します。 [Project Manager] ウィンドウの [Details] エリアにこのソリューションに関する重要な情報が表示されます。この内容を確認してから次の手順に進みます。

Vivado IP カタログでこの IP コアをダブルクリックすると、 [Customize IP] ダイアログボックスが開きます (図 4-1)。

注記: この章には Vivado 統合設計環境 (IDE) のスクリーンショットを掲載していますが、新バージョンの画面は異なる場合があります。

Vivado IDE の SEM Controller IP カスタマイズ画面は、次に示す 3 つのタブで構成されます。

• [Basic] – IP モード、ターゲットクロック周期、コンフィギュレーションプリミティブとヘルパーブロックの配置場所など、基本的な SEU 軽減機能のオプションを設定します。

• [Advanced Mitigation] – エラー分類など、より高度な SEU 軽減機能のオプションを設定します。

• [Summary] – [Basic] および [Advanced Mitigation] タブで選択した IP コンフィギュレーションの内容が表示されます。 IP を生成する前に、ここで設定内容を確認してください。

SEM Controller ソリューションが終的に組み込まれるプロジェクト全体の要件が満たされるように、ここで各オプションの設定を確認し、必要に応じて変更します。次に、各オプションの詳細について説明します。

注意: SEM Controller は、生成時にターゲットとしたデバイスでしか使用できません。あるデバイスに対して生成したコントローラーのデザインチェックポイント (DCP) を別のデバイスおよびハードウェアをターゲットにしたより大規模なデザインで使用した場合、コントローラーはブートおよび初期化プロセスを完了しても正しく動作しません。





第 4 章:デザインフローの手順

[Basic] タブX-Ref Target - Figure 4-1

図 4‐1: SEM Controller の [Basic] タブ






[Component Name] およびシンボル

[Component Name] では、生成されるコンポーネントの名前を設定します。この例では、「sem_ultra_0」を使用しています。このダイアログボックスの左側にはコンポーネントシンボルが表示されます。ここには、現在のオプション設定でコンポーネントに存在するポートが視覚的に表示されます。オプション設定を変更すると、この図は自動的に更新されます。

モード

SEM Controller IP は 6 つのモードで利用できます。

• 軽減 + テスト (Mitigation and Testing) モード

• 軽減 (Mitigation only) モード

• 検出 + テスト (Detect and Testing) モード

• 検出 (Detect only) モード

• エミュレーション (Emulation) モード

• モニター (Monitoring) モード

モードは、 IP の用途およびアプリケーションに応じて選択します。各モードの機能の違いについては、 [Mode description] に表示される一覧表で確認できます。

エラー訂正機能が必要な場合は、軽減 + テストまたは軽減モードのいずれかを選択します。これらのモードでは、コントローラーはエラー検出回路を監視し、エラー条件を報告します。また、エラーが検出された場合はコントローラーが訂正を試みます。一般的にほとんどのエラーは訂正可能で、訂正に成功するとコントローラーは訂正可能なエラーが発生して訂正されたことを報告します。訂正不能なエラーの場合、コントローラーは訂正不能なエラーが発生したことを報告してアイドルステートに移行します。

エラー訂正では、 ECC シンドロームを使用してフレーム内の正確なエラー位置を特定します。エラーを含むフレームを読み出し、該当するビットを反転してフレームを書き戻します。このエラーは訂正可能エラーとして報告されます。

内蔵のエラー訂正機能が不要な場合は、検出 (+ テスト )、エミュレーション、モニターモードのいずれかを選択します。検出 (+ テスト ) モードでは、コントローラーは初期化が完了すると検出ステートに移行し、 SEU エラーが検出されるまでコンフィギュレーションメモリのスキャンを継続します。エラーが検出されるとエラーレポートを出力し、訂正は実行せずアイドルステートに戻ります。

エミュレーションおよびモニターモードでは、コントローラーは初期化が完了するとアイドルステートに移行します。監視ステートには移行しないため、コンフィギュレーションメモリを継続的にスキャンして SEU エラーを検出および訂正することはできません。

どのモードを選択した場合も、アイドルステートでコントローラーにコマンドを送信してエラー検出/レポート機能 (検出および診断スキャン) を開始できます。

エラー挿入はデザインを検証するための機能で、ソフトエラーイベントを模したエラーをユーザーがコンフィギュレーションメモリに発生させることができます。この機能は、統合またはシステムレベルテストの際にコントローラーがシステムレベルの監視ロジックと正しく接続されているか、そしてソフトエラーイベントが発生した場合にシステムが正しく応答するかを検証する際に使用します。エラー挿入機能は軽減、検出、モニターモードでは利用できません。

ヒント : エラー挿入機能を無効にした場合、コントローラーはエラー挿入コマンドを無視し、エラー挿入ステートには移行しません。

各モードで利用可能な機能の一覧は、 17 ページの表 2-1 を参照してください。






[Controller Clock Period (ps)]

コントローラーのクロック周期を設定します。コントローラーのクロック周期を短くする (すなわちクロック周波数を引き上げる ) と、エラー軽減時間が短縮されます。したがって、クロック周期はなるべく短くすることを推奨します。目的の周期がターゲットデバイスの能力を超える場合、警告が表示されます。

エラー分類のために外部データをフェッチするデータ取得インターフェイスが必要なデザインでは、さらに別の考慮事項が存在します。サンプルデザインはコントローラーに同期した外部メモリインターフェイスをインプリメントします。このため、外部メモリのサイクル時間もコントローラーのクロック周波数によって決まります。外部メモリの小サイクル時間がコントローラーの大クロック周波数を制限する要因になるため、外部メモリシステムを解析してこの小サイクル時間を決定する必要があります。

この解析の実行方法は、第 3 章の「インターフェイス」で説明しています。ただしこの解析には、インプリメンテーション結果から得たタイミングデータが必要です。したがって、ザイリンクスでは次の手順を推奨しています。

1. 目的の周波数またはクロック周期設定でソリューションを生成する。

2. インプリメンテーション結果から必要なタイミングデータを抽出する。

3. タイミングバジェット解析を実行して大周波数を決定する。

4. 計算で求めた大動作周波数と同じかそれ以下の周波数でソリューションを再生成する。

注記:評価ボードをターゲットにした場合、 [Controller Clock Period] のデフォルト値にはサンプルデザインのピン配置に基づいたクロック周波数が自動的に選択されます。

[Structural Options]

必要な ICAP および FRAME_ECC プリミティブを IP に対してどこに位置させるかを決定します。コンフィギュレーションプリミティブブロックを IP サンプルデザインに含める (IP のサンプルデザインと一緒に生成する ) か、 IP の範囲に含める (アウトオブコンテキスト (OOC) デザインチェックポイントに含める ) かを選択できます。

SEM Controller IP は、付属する IP ヘルパーブロックおよびプリミティブを使用して検証されています。詳細は、第 3 章の「構造オプション」を参照してください。






[Advanced Mitigation] タブ


図 4‐2: SEM Controller の [Advanced Mitigation] タブ






[Enable Error Classification]

エラー分類機能の有効/無効をこのチェックボックスで設定します。エラー分類は、軽減 (+ テスト ) モードでエラー訂正を有効にした場合に利用できます。

エラー分類機能は、検出および訂正されたソフトエラーがユーザーデザインの機能に影響したかどうかをザイリンクスのエッセンシャルビットテクノロジを利用して判定します。

エッセンシャルビットとは、デザインの回路に関係するビットをいいます。エッセンシャルビットが変化すると、デザインの回路が変化します。しかし必ずしもデザインの機能に影響するとは限りません。

どのビットがエッセンシャルかが不明な場合、システムは検出したソフトエラーのすべてがデザインの正確さに影響したと見なす必要があります。多くの場合、システムレベルでエラー軽減を実行すると、 FPGA コンフィギュレーションが修復されてデザインのリセットまたは再起動が完了するまでサービスが中断または低下します。

しかし Vivado Bitstream Generator のレポートでデザインの動作に影響するエッセンシャルビットがコンフィギュレーションメモリ全体の 20% であると報告された場合、システムレベルのエラー軽減が必要なのは 10 回のソフトエラーのうち平均 2 回しかありません。エラー分類機能は、ソフトエラーイベントがコンフィギュレーションメモリのエッセンシャルビット位置で発生したかどうかをルックアップテーブルを利用して判定します。この機能を使用するとデザインの実効 FIT が改善します。ただしエラー分類を有効にすると、ルックアップテーブルを格納するための外部ストレージが必要になります。

エラー分類を有効にすると、コントローラーが外部データを取得するためのインターフェイスとしてフェッチインターフェイスが生成され、コンポーネントシンボルにも表示されます。付属のサンプルデザインでは、フェッチインターフェイスを外部 SPI フラッシュに接続するブリッジが必要です。このため、サンプルデザインには SPI フラッシュマスターヘルパーブロックが含まれています。

エラー分類を有効にした場合、検出したエラーの訂正が完了すると、コントローラーはルックアップテーブルを参照してエラー位置を特定します。このテーブルの情報に基づき、コントローラーはエラーがエッセンシャルか非エッセンシャルかを報告します。検出したエラーを訂正できないのは、エラー位置を特定できないためです。したがって、訂正不能なエラーはエッセンシャルかどうかをルックアップテーブルで判定できないため、安全のためにすべてのエラーをエッセンシャルとして報告します。

同様に、エラー分類を無効にした場合もコントローラーはエラーがエッセンシャルかどうかを判定できないため、すべてのエラーを無条件にエッセンシャルとして報告します。

注記:評価ボードがターゲットの場合、このオプションは利用できません。

ヒント : エラー分類は必ずしもコントローラーで実行する必要はありません。コントローラーによるエラー分類を無効にし、インプリメンテーションツールによって提供されるエッセンシャルビットデータとエラー位置情報を利用してシステム内の別のブロックでエラー分類を実行することもできます。エラー位置情報は、コントローラーがモニターインターフェイスから出力するエラーレポートに含まれます。






[Summary] タブ

[Summary] タブで IP コンフィギュレーションのサマリをチェックし、各オプションが正しく設定されているかを確認します。設定が正しくない場合は前のタブに戻って設定を変更します。すべてのオプション設定が正しいことを確認したら、 [OK] をクリックして IP のカスタマイズを終了します。


図 4‐3: SEM Controller の [Summary] タブ






ユーザーパラメーター

表 4-1 に、 Vivado IDE のフィールドとユーザーパラメーターの対応関係を示します。ユーザーパラメーターは Tcl コンソールで表示できます。

出力ファイルの生成

詳細は、『Vivado Design Suite ユーザーガイド : IP を使用した設計』 (UG896) [参照 11] を参照してください。

コアへの制約

このセクションでは、このコアに適用される制約について説明します。

必須の制約

SEM Controller とシステムレベルサンプルデザインがパフォーマンス要件を満たした機能結果を得るには、物理的なインプリメンテーション制約を指定する必要があります。これらの制約は、システムレベルサンプルデザイン生成時に XDC ファイルとして作成されます。

UltraScale+™ サンプルデザインの場合、タイミング制約を含む XDC 制約 (*_synth.xdc) と配置制約を含む XDC 制約 (*_impl.xdc) の 2 つが生成されます。 UltraScale™ サンプルデザインの場合、タイミング制約と配置制約を含む XDC 制約が 1 つだけ生成されます。生成される XDC ファイルの数にかかわらず、 XDC ファイル内の制約のタイプは同じです。

一貫したインプリメンテーション結果を得るには、ソリューションに付属の XDC ファイルを使用する必要があります。 XDC または特定の制約の定義および使用法については、 Vivado Design Suite の資料ページにある『制約ガイド』を参照してください。

このソリューションをより大規模なプロジェクトに統合する場合、またはシステムレベルサンプルデザインに変更を加えた場合、制約の変更が必要となることがあります。制約の変更は、各制約を十分に理解したうえで行ってください。また、提供されている制約を規定から逸脱した形で使用したデザインに対してはサポートを提供しておりません。

表 4‐1: Vivado IDE のパラメーターとユーザーパラメーターの対応表

Vivado IDE のパラメーターユーザーパラメーターデフォルト値

モード c_feature_set、 c_has_error injection Mitigation and Testing

[Controller Clock Period] N/A 125,000ps

[ICAP and FRAME_ECC placement] c_config_prim_loc Example design

[Enable Error Classification] c_feature_set FALSE


https://japan.xilinx.com/cgi-bin/docs/rdoc?v=latest;t=vivado+docs





XDC (ザイリンクスデザイン制約) ファイルの内容

XDC ファイルはソリューションを生成するたびに作成されます。 XDC ファイルの全体的な構造と制約シーケンスは毎回同じですが、その内容は生成時に設定したオプションにより異なります。ここからは、 Kintex™ UltraScale™ デバイスへのインプリメンテーションを例に、 XDC ファイルの構造と制約シーケンスについて説明します。

コントローラーの制約

コントローラーは、単体で考えた場合、生成時のオプション設定にかかわらず完全同期デザインです。基本的に、必要な制約はシステムクロック入力に対するクロック周期制約のみです。ジェネリック XDC では、この制約はシステムレベルサンプルデザインクロック入力に適用され、コントローラーに伝搬します。この制約については、「サンプルデザインの制約」で説明します。

コントローラーと FPGA コンフィギュレーションシステムプリミティブの間の信号パスは同期パスと見なす必要があります。デフォルトでは、 ICAP または FRAME_ECC プリミティブとコントローラーの間のパスはシステムクロックに対するクロック周期制約の一部として解析されます。これは、 ICAP および FRAME_ECC クロックピンを同じシステムクロック信号に接続する必要があるためです。

ただし ICAP ポートの非同期出力信号の PRERROR、 PRDONE、および AVAIL ピンは例外です。これらの信号は内部で IP に同期しており、これらのタイミングパスを無視するには追加の制約が必要です。「サンプルデザインの制約」の set_false_path 制約のリストを参照してください。

一般に、コントローラーと接続する ICAP はその SLR の上位 ICAP に配置する必要があります。モノリシックデバイスの場合、指示子なしでツールが ICAP と FRAME_ECC を正しく配置するため、特別な配置制約は必要ありません。

SSI デバイスの場合、 ICAP と FRAME_ECC を正しい SLR に配置するにはツールで制約を指定する必要があります。「サンプルデザインの制約」の set_property 制約のリストを参照してください。

サンプルデザインの制約

サンプルデザインの制約は制約のタイプとインターフェイスごとにまとめられています。

タイミング制約

このグループの初の制約は、デザイン全体に対するシステムクロック入力への制約です。 PERIOD 制約の値は、生成時に設定したオプションにより異なります。

create_clock -name clk -period 125.0 [get_ports clk]

この次に、 ICAP ポートの非同期出力信号を無視するための制約が続きます。

set_false_path -from [get_pins {example_support_wrapper/example_support/example_cfg/cfg_icape3/CLK}] -to [get_pins {example_support_wrapper/example_support/sem_controller/inst/controller/controller_synchro_icap_prerror/sync_a/D}]set_false_path -from [get_pins {example_support_wrapper/example_support/example_cfg/cfg_icape3/CLK}] -to [get_pins {example_support_wrapper/example_support/sem_controller/inst/controller/controller_synchro_icap_prdone/sync_a/D}]set_false_path -from [get_pins {example_support_wrapper/example_support/example_cfg/cfg_icape3/CLK}] -to [get_pins {example_support_wrapper/example_support/sem_controller/inst/controller/controller_synchro_icap_avail/sync_a/D}]

このグループの 2 番目の制約は UART ヘルパーブロックに関するもので、インターフェイスに I/O タイミング制約を適用します。 I/O タイミング制約は 1 クロック周期に設定します。

set_input_delay -clock clk -max -125.0 [get_ports uart_rx] set_input_delay -clock clk -min 250.0 [get_ports uart_rx] set_output_delay -clock clk -125.0 [get_ports uart_tx] -max set_output_delay -clock clk 0 [get_ports uart_tx] -min






このグループの 3 番目の制約は SPI フラッシュマスターヘルパーブロックに対するものです。これらの制約は、エラー分類機能を有効にしてこのヘルパーブロックを生成した場合のみ存在します。これらの制約は、インターフェイスに I/O タイミング制約を適用します。SPI バスタイミングバジェットの解析では実際のタイミングを使用する必要があるため、 I/O タイミングは非常に重要です。ただしインプリメントした FPGA の I/O タイミングに対するハード要件はありません。これらの要件は選択したデバイスおよびスピードグレードにより異なります。

このため、 I/O タイミング制約は暫定的に PERIOD 制約の 2 倍に設定します。 IOB フリップフロップを使用する制約を追加すると、制約の値が示すよりも I/O タイミングが大幅に改善します。 SPI バスタイミングバジェットの解析では、制約の値ではなくタイミングレポートから取得した実際のタイミングを使用します。

set_input_delay -clock clk -max -125.0 [get_ports spi_q]set_input_delay -clock clk -min 250.0 [get_ports spi_q]

set_output_delay -clock clk -125.0 [get_ports spi_c] -maxset_output_delay -clock clk 0 [get_ports spi_c] -min

set_output_delay -clock clk -125.0 [get_ports spi_d] -maxset_output_delay -clock clk 0 [get_ports spi_d] -min

set_output_delay -clock clk -125.0 [get_ports spi_s_n] -maxset_output_delay -clock clk 0 [get_ports spi_s_n] -min

set_property IOB TRUE [get_cells example_support_wrapper/example_support/example_spi/example_spi_byte/spi_c_ofd]set_property IOB TRUE [get_cells example_support_wrapper/example_support/example_spi/example_spi_byte/spi_d_ofd]set_property IOB TRUE [get_cells example_support_wrapper/example_support/example_spi/example_spi_byte/spi_q_ifd]set_property IOB TRUE [get_cells example_support_wrapper/example_support/example_spi/spi_s_ofd]

配置制約

次のグループは、システムレベルサンプルデザインの一部を選択したデバイスの特定領域に配置する Pblock を実装します。 Pblock に含まれるインスタンスは、生成時に設定したオプションにより異なります。範囲の値は、使用するデバイスにより異なります。

Pblock により、ソフトエラー軽減ロジックはデバイスの ICAP サイトに物理的に隣接した領域にパックして配置されます。特に重要な点として、これによりタイミング結果の再現性が維持されます。また、 Pblock はよりコンパクトなパックが可能なためリソース使用量が抑えられます。

付属の Pblock はサンプルとして提供されています。この Pblock のサイズをさらにコンパクトにしてリソース使用量を抑え、 SEM Controller の物理的フットプリントを削減することを推奨します。

create_pblock semresize_pblock [get_pblocks sem] -add {SLICE_X82Y75:SLICE_X87Y89}resize_pblock [get_pblocks sem] -add {RAMB36_X8Y14:RAMB36_X8Y17}resize_pblock [get_pblocks sem] -add {DSP48E2_X15Y30:DSP48E2_X15Y35}add_cells_to_pblock -pblock sem -cells [get_cells example_support_wrapper/example_support/example_spi/*]add_cells_to_pblock -pblock sem -cells [get_cells example_support_wrapper/example_support/example_uart/*]add_cells_to_pblock -pblock sem -cells [get_cells example_support_wrapper/example_support/sem_controller/*]






また、 FRAME_ECC と ICAP の配置を上位 ICAP に強制するために次の制約も含まれていますが、これはモノリシックデバイスの場合は不要です (指示子なしでツールが正しく配置する )。

# Force FRAME_ECC to the site in this SLR.set_property LOC CONFIG_SITE_X0Y0 [get_cells example_support_wrapper/example_support/example_cfg/cfg_frame_ecce3]# Force ICAP to the site in this SLR.set_property LOC CONFIG_SITE_X0Y0 [get_cells example_support_wrapper/example_support/example_cfg/cfg_icape3]

SSI デバイスへのインプリメンテーションでデザインの機能を正しく動作させるには、 FRAME_ECC および ICAP の配置制約に従う必要があります。

ピン制約

次のグループは、 I/O ピンロケーションをシステムレベルサンプルデザインの上位ポートに割り当てるためのテンプレートです。これらの割り当てはボードごとに異なるため、自動的には生成できません。ただしサポートされる評価ボードをターゲットにしてデザインを生成した場合はこの限りではありません。付録 C 「評価ボードを使用した SEM Controller の動作デモ」を参照してください。この場合、ピンロケーションはターゲットボードと互換性があります。

それ以外の場合は、ターゲットボードに合わせて有効な I/O ピンロケーションおよび規格を割り当て、次に示す制約を適用してください。

set_property IOSTANDARD <io standard> [get_ports clk]set_property PACKAGE_PIN <package pin> [get_ports clk]

set_property IOSTANDARD <io standard> [get_ports uart_rx]set_property PACKAGE_PIN <package pin> [get_ports uart_rx]

set_property IOSTANDARD <io standard> [get_ports uart_tx]set_property PACKAGE_PIN <package pin> [get_ports uart_tx]

set_property IOSTANDARD <io standard> [get_ports spi_q]set_property PACKAGE_PIN <package pin> [get_ports spi_q]

set_property IOSTANDARD <io standard> [get_ports spi_c]set_property PACKAGE_PIN <package pin> [get_ports spi_c]

set_property IOSTANDARD <io standard> [get_ports spi_d]set_property PACKAGE_PIN <package pin> [get_ports spi_d]

set_property IOSTANDARD <io standard>8 [get_ports spi_s_n]set_property PACKAGE_PIN <package pin> [get_ports spi_s_n]

タイミングクロージャの達成を容易にするため、 UART または SPI フラッシュインターフェイスに使用する I/O ピンは、 SEM Controller にも近い I/O バンクにあるピンを選ぶ必要があります。

エッセンシャルビット情報の生成

エッセンシャルビット情報を生成するには次の制約が必要です。エラー分類を有効にした場合のみ、この制約が含まれます。

set_property bitstream.seu.essentialbits yes [current_design]






UltraScale SSI デバイスの制約

システムレベルサンプルデザインでは、デバイスによって 2 ～ 3 個のコントローラーインスタンスが生成されます。これらのコントローラーインスタンスには、 0 ～ 2 の ID 番号を含む名前が付けられます。コントローラーインスタンスの番号は、ハードウェア SLR 番号と同じです。

ICAP および FRAME_ECC プリミティブがツールによって各 SLR に正しく配置されるようにするには、次の制約を適用する必要があります (この例は SLR2 の場合のもの)。

## Force FRAME_ECC to the site in SLR 2.set_property LOC CONFIG_SITE_X0Y2 [get_cells example_support_wrapper/example_support/slr2_example_cfg/cfg_frame_ecce3]## Force ICAPs to the site in SLR 2.set_property LOC CONFIG_SITE_X0Y2 [get_cells example_support_wrapper/example_support/slr2_example_cfg/cfg_icape3]

各コントローラーは、各 SLR の関連するコンフィギュレーションロジックプリミティブの近くに集中して配置されるようにエリア制約が適用されます。これは非 SSI デバイスの制約とほぼ同じもので、これらをすべての SLR に繰り返し適用します。

タイミングクロージャの達成を容易にするため、 UART および SPI フラッシュマスターヘルパーブロックなどの共有ブロックにも、デバイス中央のマスター SLR に配置されるようにエリア制約が適用されることがあります。

UART または SPI フラッシュインターフェイスに使用する I/O ピンは、マスター SLR (コントローラーのインスタンス 0) 内の I/O バンクに配置された I/O ピンのうち、コントローラーインスタンスにも近いものを選択することを推奨します。

UltraScale+ SSI デバイスの制約

システムレベルサンプルデザインでは、コントローラーインスタンスは 1 つだけ生成され、 FRAME_ECC インスタンスはデバイスによって 2 ～ 4 個が生成されます。これらの FRAME_ECC インスタンスには、 0 ～ 3 の ID 番号を含む名前が付けられます。コントローラーインスタンスの番号は、ハードウェア SLR 番号と同じです。

ICAP および FRAME_ECC プリミティブがツールによって正しく配置されるようにするには、次の制約を適用する必要があります (この例は SLR が 2 つのデバイスの場合のもの)。

# Force FRAME_ECC to the site in this SLR.set_property LOC CONFIG_SITE_X0Y1 [get_cells example_support_wrapper/example_support/example_cfg/slr1_cfg_frame_ecce4]set_property LOC CONFIG_SITE_X0Y0 [get_cells example_support_wrapper/example_support/example_cfg/slr0_cfg_frame_ecce4]# Force ICAP to the site in this SLR.set_property LOC CONFIG_SITE_X0Y0 [get_cells example_support_wrapper/example_support/example_cfg/cfg_icape3]

コントローラーが関連する ICAP の近くに配置されるように、コントローラーにエリア制約を適用してマスター SLR に配置します。

タイミングクロージャの達成を容易にするため、 UART および SPI フラッシュマスターヘルパーブロックなどの共有ブロックにも、デバイス中央のマスター SLR に配置されるようにエリア制約が適用されることがあります。

UART または SPI フラッシュインターフェイスに使用する I/O ピンは、マスター SLR 内の I/O バンクに配置された I/O ピンのうち、コントローラーにも近いものを選択することを推奨します。






デバイス、パッケージ、スピードグレード

このセクションは、この IP コアには適用されません。

クロック周波数


クロック管理


クロック配置


シミュレーション

Vivado シミュレーションコンポーネントについて、またサポートされているサードパーティツールについては、『Vivado Design Suite ユーザーガイド : ロジックシミュレーション』 (UG900) [参照 9] を参照してください。

コントローラーをインスタンシエートしたデザインのシミュレーションがサポートされます。つまり、コントローラーを大規模なプロジェクトに統合した場合、コントローラーに関係しない機能のシミュレーションは通常どおり実行できます。ただしシミュレーションではコントローラーの動作は観察できません。コントローラーを含むデザインのシミュレーションはコンパイルされますが、コントローラーは初期化ステートを終了しません。コントローラー動作のハードウェアベースの評価が必要です。

合成およびインプリメンテーション

SEM コアは付属のサンプルデザインと一緒に合成およびインプリメントしてください。詳細は、第 5 章の「インプリメンテーション」を参照してください。

Vivado Design Suite を使用した合成およびインプリメンテーションの詳細は、『Vivado Design Suite ユーザーガイド : IP を使用した設計』 (UG896) [参照 11] を参照してください。






統合およびバリデーション

複雑なシステムを開発する場合のベストプラクティスとして、主要なファンクションブロックとインターフェイスをなるべく早い段階で統合し、継続的にバリデーションを実行することが重要です。開発サイクルの終盤になってデザインを大幅に変更すること (統合の遅れ) や、システムパフォーマンスの計測を先延ばしすること (バリデーションの遅れ) は、リスクを増大させます。

統合とバリデーションの主要なスケジュールはプロジェクトのプランニング段階で決定しておくこと、そして開発サイクル全体を通じてシステムの機能とパフォーマンスを計画的にチェックしてこれらのスケジュールをサポートすることが重要です。できるだけ早期に統合を開始し、可能な限り多くの機能を段階的に追加していくと、代表的なワークロードでのシステム評価の時間を大限に確保できます。この手法は、デザイン再利用と IP ベース設計を促進する一般的なボトムアップ設計アプローチを補完するものとして推奨されます。

SEM IP コアの統合

SEM IP コアはプログラマブルロジックのフットプリントをわずかしか占有しませんが、プログラマブルロジックのコンフィギュレーションメモリシステムを活性化します。コンフィギュレーションメモリシステムの動作は通常の SRAM とほとんど同じですが、プログラマブルロジックアレイ全体に物理的に分散している点が異なります。デバイス内のほかのデジタルスイッチングアクティビティ同様、コンフィギュレーションメモリシステムのアクティビティも電力ノイズを発生させます。

SEM IP コアがサポートするデバイスファミリでは、インプリメンテーション要件と設計ガイダンスを守っていれば、コンフィギュレーションメモリシステムから発生する電力ノイズはわずかです。

推奨: SEM IP コアをシステムに統合する際は、新バージョンのコアを使用すると共に、 SEM IP ソリューションに関するマスターアンサーを参照して SEM IP コアに関するデザインアドバイザリや既知の問題など新の情報を入手することを強く推奨します。

SEM IP コアはなるべく早い段階で (理想的にはプロジェクトの初から ) 統合してください。SEM IP コアは自動的に初期化できるため、初の統合はコアをインスタンシエートしてクロックを接続し、それ以外の入力ポートを特定の値に接続するだけで完了します。この早期インフラストラクチャの一部として SEM IP コアのプロビジョニング制御を実装し、システムが SEM IP コアクロックおよび SEM IP コアの icap_grant のイネーブル/ディスエーブルを行えるようにすることを推奨します。 SEM IP コアのシステムプロビジョニングにより導入の柔軟性が向上すると同時に、 SEM IP コアの統合のデバッグも容易になります。

その後、システムと SEM IP コアの間でコマンド /ステータス情報を交換するためのインターフェイスを定義および実装して統合を拡張できます。このインターフェイスには、 SEM IP コアのモニターインターフェイスを利用した ASCII 通信を推奨します。 UART ヘルパーブロックはシリアル接続の場合のみ使用し、通信 FIFO を用いたパラレル接続の場合には使用しません。

SEM IP コアによって報告されたイベントのログをシステムで記録して解析するだけならステータス情報を交換するだけで十分ですが、エラー挿入をサポートするにはコマンドを交換する必要があります。放射線試験施設での加速粒子テスト以外では、 SEM IP コアの統合および SEM IP コアのイベントレポートに対するシステム応答を完全にテストできる現実的な方法はエラー挿入しかありません。エラー挿入は、継続的なバリデーションにおいても一部の用途で役立ちます。


https://japan.xilinx.com/search/support-keyword-search.html?searchKeywords=soft+error+mitigation

https://japan.xilinx.com/search/support-keyword-search.html?searchKeywords=soft+error+mitigation





SEM IP コアのバリデーション

SEM IP コアを統合したシステムでは、 SEM IP コアの初期化ステート中のコンフィギュレーションメモリシステムの動作は読み出しと書き込みが混在しています。その後の監視ステートでは、 SEU を検出するためにコンフィギュレーションメモリを常時スキャンするため、読み出し動作が 100% となります。地上環境におけるザイリンクスのコンフィギュレーションメモリの反転率は非常に低く (たとえばニューヨーク市の海抜 0m 地点では平均反転間隔は数十年)、 SEM IP コアが監視ステートから訂正ステート (書き込み動作が発生するステート ) に遷移することはほとんどありません。

SEM IP コアを統合したシステムの継続的なバリデーションでは、 SEM IP コアの代表的なワークロードを使用して実環境のシステムに即したバリデーション結果が得られるようにする必要があります。システムプロビジョニングによって SEM IP コアが初期化を完了して監視ステートに移行する場合、デフォルトのワークロードではコンフィギュレーションメモリをスキャンしてもソフトエラーはありません。これは作業が簡単であるだけでなく、バリデーションに適した代表的なワークロードともいえます。

必要であれば、 SEM IP コアのエラー挿入機能を使用して散発的にエラー検出および訂正をワークロードに組み入れることもできます。

重要: 頻繁にエラーを挿入して大量のエラー検出および訂正イベントを発生させるような「ストレステスト」は推奨しません。このようなスティミュラスは現実に即しておらず、システムの動作信頼性とは無関係なバリデーション結果となるためです。

システムバリデーションは研究開発段階だけでなく量産テストでも継続的に実施してください。 SEM IP コアの場合、量産テストでのシステムプロビジョニングは SEM IP コアを有効にするだけでよいため、作業負担の増加はほとんどまたはまったくありません。





第 5章

サンプルデザインこの章では、 UltraScale™ Architecture SEM Controller のシステムレベルサンプルデザインの概要と、そのインターフェイスについて説明します。システムレベルサンプルデザインはコントローラーと各種ヘルパーブロックをカプセル化しており、これらのヘルパーブロックがコントローラーとほかのデバイスを接続するインターフェイスとしての役割を果たします。ヘルパーブロックには、 I/O ピン、 I/O インターフェイス、メモリコントローラー、アプリケーション固有のシステム管理インターフェイスなどがあります。

システムレベルサンプルデザインはコントローラーと一緒に検証されています。付属するシステムレベルサンプルデザインはリファレンスデザインではありませんが、ソリューション全体を構成する必須要素です。システムレベルサンプルデザインはユーザーが自由に変更できますが、そのまま使用することを推奨します。

機能

システムレベルサンプルデザインは大きく次の 2 つの機能グループに分けられます。

• サポートレイヤー (<component_name>_support)

• サンプルレイヤー (<component_name>_example_design)

サポートレイヤーとそのサブレイヤーには、ソフトエラー軽減ソリューションに必須のロジックがすべて含まれます。これには、次のロジックのインスタンシエーションが含まれます。

• コントローラーを外部デバイスに接続するために必要なヘルパーブロック

° UART ヘルパーブロック : コントローラーと標準 RS-232 ポートを接続するブリッジの役割を果たします。このブロックが提供するインターフェイスを使用して、コントローラーとの間でコマンドとステータス情報を交換します。このインターフェイスは、プロセッサと接続するように設計されています。

° SPI フラッシュマスターヘルパーブロック : コントローラーと標準 SPI バスを接続するブリッジの役割を果たします。このブロックが提供するインターフェイスを使用して、コントローラーは外部からデータをフェッチします。このヘルパーブロックは標準 SPI フラッシュに接続するためのもので、分類機能を有効にした場合のみ存在します。

• コントローラーが必要とするコンフィギュレーションシステムプリミティブのインスタンシエーション。

• コアシステムクロックを分配するためのクロッキングプリミティブ。

SEM Controller IP はこれらのブロックを含めて検証されています。このロジックをデザインに統合することが完全にサポートされており、推奨されます。

サンプルレイヤーには、サポートレイヤーおよびいくつかの VIO コアがインスタンシエートされています。 VIO コアを使用すると IP のステータスを視覚的に観察でき、外部デバイスに接続する必要のない IP の入力を動的に駆動できます。





第 5 章:サンプルデザイン

また、このサンプルレイヤーにはステータスインターフェイスを監視して IP の正常動作を確認するためのサンプルロジックも含まれます。次のステータスエラー信号が提供されます。

• heartbeat_timeout – この信号は、 SEM Controller が正しいステートにあるにもかかわらずハートビート信号がトグルを停止して 1 秒を経過するとアサートされます。

• heartbeat_timeout_sticky – heartbeat_timeout 信号の動作をスティッキーにしたものです。この信号は、一度アサートされるとデザインを次にコンフィギュレーションするまでアサートされたままです。

• status_irregular_sticky – 同じクロックサイクルで複数のステータス信号がアサートされるとアサートされるスティッキー信号です。

• status_halt – この信号は、重大エラー (すべてのステータス信号がアサート ) によってコントローラーが停止するとアサートされます。

ステータス信号の監視方法については、第 3 章の「システム」を参照してください。

モノリシックデバイスの場合、 4 つの VIO IP コアがインスタンシエートされています。

• <component_name>_vio_si14 – SEM Controller のステータスインターフェイスとステータスエラー信号を表示します。

• <component_name>_vio_so32 – フェッチインターフェイスの fetch_tbladdr 入力を定義します。エラー分類を有効にした場合のみ利用できます。

• <component_name>_vio_si1_so5 – ICAP アービトレーションおよび補助インターフェイスの出力を表示し、入力を定義します。

• <component_name>_vio_si1_so41 または so45 – コマンドインターフェイスの出力を表示し、入力を定義します。

UltraScale SSI デバイスの場合、各 SLR に VIO コアが 1 つずつと、すべての SLR で共通の入力を駆動する VIO コアが 1 つあります。

• <component_name>_vio_slr_si16_so2 – 個々の SLR のステータスおよび ICAP アービトレーションインターフェイスのすべての出力を表示し、入力を定義します。

• <component_name>_vio_generic_so44 または so76 – すべての SRL に共通する補助、コマンド、およびフェッチインターフェイスへの入力を駆動します。フェッチインターフェイスへの入力はエラー分類を有効にした場合のみ利用可能で、その場合出力プローブの数は 44 から 76 に増えます。

UltraScale+™ SSI デバイスの場合、 4 つの VIO IP コアがインスタンシエートされています。

• <component_name>_vio_si17 または si20 または si23 – SEM Controller のステータスインターフェイスとステータスエラー信号を表示します。

• <component_name>_vio_so32 – フェッチインターフェイスの fetch_tbladdr 入力を定義します。エラー分類を有効にした場合のみ利用できます。

• <component_name>)_vio_si1_so5 – ICAP アービトレーションおよび補助インターフェイスの出力を表示し、入力を定義します。

• <component_name>_sio_si1_so45 – コマンドインターフェイスの出力を表示し、入力を定義します。

サポートレイヤーとサンプルレイヤーを組み合わせたものを完全な SEU 軽減ソリューションとして評価できます。システムレベルサンプルデザインは、システムレベルのインターフェイスに柔軟性をもたせるために提供しています。このため、コントローラーとは異なりシステムレベルサンプルデザインは RTL ソースコードとしても提供されています。

図 5-1 に、非 SSI デバイスのシステムレベルサンプルデザインのブロック図を示します。グレーで示したブロックは、一部のコンフィギュレーションにのみ存在します。







図 5‐1:サンプルデザインのブロック図 (非 SSI デバイスの場合)

Support Layer (support)

System-Level Solutions (support_wrapper)


VIO

VIO

VIO

VIO

BUFGCE

UART Helper Block


SEM Controller(DCP)

Configuration Logic

ICAP FRAMEECC

UART

Interface

SPI

Interface

System Clock Interface

Command

Interface

Auxiliary and

ICAP Arbitration

Interfaces

Fetch_tbladdr

Status

Interface and

Status Error

Signals

Fetch Interface

Monitor Interface

FRAME_ECC

InterfaceICAP Interface

X16178-022316






図 5-2 に、 UltraScale SSI デバイスのシステムレベルサンプルデザインのブロック図を示します。グレーで示したブロックは、一部のコンフィギュレーションにのみ存在します。


図 5‐2:サンプルデザインのブロック図 (UltraScale SSI デバイスの場合)

SPI Interface

UART Interface

System Clock Interface

SLR(Master, Required)

SLR(Slave, Optional)


Controller Netlist

Controller Netlist

Controller Netlist

Configuration Logic

ICAP FRAME ECC

Configuration Logic

ICAP FRAME ECC

Configuration Logic

ICAP FRAME ECC


SLR(Slave, Optional)

Support Layer (support)

Status and ICAP Arbitration Signals



Auxiliary, Command, and fetch_tbladdr Signals

Shared VIO

BUFGCE

SLRVIO

SLRVIO

SLRVIO

UART Helper Block SSI

SPI Flash Master Helper Block SSI

Input Pipeline






図 5-3 に、 UltraScale+ SSI デバイスのシステムレベルサンプルデザインのブロック図を示します。グレーで示したブロックは、一部のコンフィギュレーションにのみ存在します。


図 5‐3:サンプルデザインのブロック図 (UltraScale+ SSI デバイスの場合)

Support Layer (Support), Netlist

ICAP FRAME ECC

SEM Controller

UART Helper Block


SPI Flash Master Helper

Block

UART

Interface

SPI

Interface

Clock Input

Configuration Logic

BUFGCE

VIO

VIO


Command

Interface

Auxiliary and

ICAP Arbitration

Interface

Fetch_tbladdr

Status

Interface

FRAME ECC

Configuration Logic

FRAMEECC

FRAMEECC

Configuration Logic

Configuration Logic

SLR(Master)

SLR(Slave)

SLR(Slave)

SLR (Slave)

VIO

VIO

X18678-012617






ポートの説明

図 5-4 に、すべてのデバイスのサンプルデザインのポートを示します。ポートは 3 つのグループにまとめられています。グレーで示したグループは、エラー分類機能を有効にした場合のみ存在します。

SSI デバイスでは、各 SLR に番号が付けられます。これには、ハードウェア SLR 番号とソフトウェア SLR 番号の 2 種類があります。

ハードウェア SLR 番号は、デバイス内で SLR がコンフィギュレーションされる順番を表します。マスター SLR は常に存在し、ハードウェア SLR 番号は 0 です。それ以外のスレーブ SLR のハードウェア SLR 番号は、基本的にマスター SLR からの距離が近いものから順に番号が割り当てられます。

UltraScale デバイスの場合、 SLR に配置されたコントローラーインスタンスは、実行時にその SLR の ICAP 経由で IDCODE レジスタを読み出してハードウェア SLR 番号を確認します。 SSI デバイスにインプリメントされたコントローラーとコマンドおよびステータス情報を交換する際は、必ずハードウェア SLR 番号を使用します。

ソフトウェア SLR 番号は、デバイスの下位から上位に向かって SLR の物理的な順番を表します。マスター SLR は常に存在しますが、そのソフトウェア SLR 番号はデバイスにより異なります。ソフトウェア SLR 番号はザイリンクス開発ツールのデバイスビューに表示されます。

表 5-1 に、ハードウェア SLR 番号とソフトウェア SLR 番号の対応関係を示します。


図 5‐4:サンプルデザインのポート (非 SSI デバイスの場合)

表 5‐1:デバイスの SLR 番号

デバイスソフトウェア SLR 番号ハードウェア SLR 番号 SLR タイプ

KU1151 1 スレーブ

0 0 マスター

VU1251 1 スレーブ

0 0 マスター

VU190

2 2 スレーブ

1 0 マスター

0 1 スレーブ

VU440

2 2 スレーブ

1 0 マスター

0 1 スレーブ

VU5P/VU7P/VU35P1 1 スレーブ

0 0 マスター

uart_rxuart_tx UART

Interface

spi_c

spi_d

spi_s_n

spi_q

clkSystem ClockInterface

SPI Interface






ヒント : SLR 番号の詳細および変換方法を知らなくてもコントローラーを SSI デバイスにインプリメントするのに支障はありません。しかし特定の SLR にエラーを挿入したい場合はこの情報が役立ちます。

UltraScale SSI デバイスのサンプルデザインのポートは、モノリシックデバイスの場合と同じです。これは、付属する UART および SPI フラッシュマスターヘルパーブロックが各 SLR のコントローラーのフェッチおよびモニターインターフェイスをすべて 1 つのインターフェイスにまとめて IP の管理および IP との通信に使用するためです。ただし support_wrapper 階層のポートに関しては、ステータスインターフェイスなど一部のインターフェイスポートがバスとなっています (バス幅は SSI デバイスを構成する SLR の数)。

システムレベルサンプルデザインにはリセットポートはありません。コントローラーが自動的に自己初期化を実行します。次に、コントローラーは必要に応じてヘルパーブロックを初期化します。

システムレベルサンプルデザインは、 clk を唯一のクロックとして使用する完全同期デザインです。すべてのステートエレメントはこのクロックの立ち上がりエッジに同期します。このため、インターフェイスもすべてこのクロックの立ち上がりエッジに同期します。

システムレベルサンプルデザインで利用可能なすべてのインターフェイス、およびそれぞれのシステム要件は第 2 章「製品仕様」および第 3 章「コアを使用するデザイン」で詳しく説明しています。詳細は次のリンク先を参照してください。

• システムクロックインターフェイス – ポートの説明 (第 2 章の「システムクロックインターフェイス」 ) および使用法 (第 3 章の「システムクロックインターフェイス」 )。

• ステータスインターフェイス – ポートの説明 (第 2 章の「ステータスインターフェイス」 ) および使用法 (第 3 章の「ステータスインターフェイス」 )。

• コマンドインターフェイス – ポートの説明 (第 2 章の「コマンドインターフェイス」 ) および使用法 (第 3 章の「コマンドインターフェイス」 )。

• UART インターフェイス – ポートの説明 (第 2 章の「UART インターフェイス」 ) および使用法 (第 3 章の「UART インターフェイス」 )。

• SPI インターフェイス – ポートの説明 (第 2 章の「SPI インターフェイス」 ) および使用法 (第 3 章の「SPI インターフェイス」 )。

VU9P

2 2 スレーブ

1 0 マスター

0 1 スレーブ

VU11P/VU37P

2 2 スレーブ

1 1 スレーブ

0 0 マスター

VU13P

3 3 スレーブ

2 2 スレーブ

1 0 マスター

0 1 スレーブ

VU27P/VU29P

3 3 スレーブ

2 2 スレーブ

1 0 マスター

0 1 スレーブ

表 5‐1:デバイスの SLR 番号 (続き)

デバイスソフトウェア SLR 番号ハードウェア SLR 番号 SLR タイプ






インプリメンテーション

このサンプルデザインはデフォルトでは生成されません。これはユーザーからの要求によって生成され、 Vivado® の新規インスタンスで開くことができます。このためユーザーデザインはそのままで、使用されている各種コアのサンプルのみを表示および変更できます。サンプルデザインを生成するには、 [Design Sources] の下の XCI ファイルを右クリックして [Open IP Example Design] をクリックします。

合成およびインプリメンテーションの実行

合成とインプリメンテーションは、 Flow Navigator の該当するオプションをクリックしてそれぞれ個別に実行できます。

ビットストリームの生成

オプションのエラー分類機能を有効にした場合、ビットストリームを生成する前にエッセンシャルビットを有効にする Tcl プロパティを次のように設定する必要があります。 Tcl プロパティの構文については、第 4 章の「エッセンシャルビット情報の生成」を参照してください。

この場合、ビットストリームの生成には大容量のシステム RAM が必要です。

外部メモリプログラミングファイルの作成

エラー分類をサポートするために外部データストレージが必要な場合、特別な write_bitstream 出力ファイルを SPI フラッシュプログラミングファイルにポストプロセスするための Tcl スクリプトを実行します。

サンプルプロジェクトでは makedata.tcl スクリプトが生成されます。ビットストリームの生成が完了したら、スクリプトの場所を指定して Tcl コンソールでこのスクリプトを source コマンドで実行します。

source <path to component_name>_ex/imports/makedata.tclsource sem_ultra_0_ex/imports/makedata.tcl

次に、インプリメンテーション結果のディレクトリを見つけます。 [Design Runs] ウィンドウをクリックし、実行したインプリメンテーションを選択し、 [Implementation Run Properties] ウィンドウに表示される Run ディレクトリを確認します。 Tcl コンソールでインプリメンテーション結果のディレクトリに移動し、 write_bitstream 出力ファイルに対して makedata スクリプトを実行します。

cd <path to component_name>_ex/<component_name>_ex.runs/impl_1cd sem_ultra_0_ex/sem_ultra_0_ex.runs/impl_1

次に、後述のコマンドを実行します。モノリシックデバイスの場合、 write_bitstream によって *.ebd ファイルが 1 つだけ生成されます。このファイル名を引数として渡します。 UltraScale SSI デバイスの場合、デバイスのすべての SLR に対して *.ebd ファイルが 1 つずつ生成されます。

注記: 2017.1 では、分類機能は UltraScale+ デバイスではサポートされません。

これら *.ebd ファイルのエッセンシャルビットデータを 1 つの SPI フラッシュデータファイルにまとめるには、すべての *.ebd ファイル名をスペースで区切って引数として渡します。

makedata -ebd <ebd filename(s)> datafile

モノリシックデバイスの場合の例:

makedata -ebd sem_ultra_0_example_design.ebd datafile






SSI デバイス (SLR が 3 つ) の場合の例:

makedata -ebd sem_ultra_0_example_design_0.ebd sem_ultra_0_example_design_1.ebd sem_ultra_0_example_design_2.ebd datafile

このコマンドを実行すると VMF、 BIN、および MCS ファイルが生成されます。

推奨: makedata.tcl ファイルはターゲットデバイスおよび必要な SPI フラッシュデバイス (表 3-7 参照) に応じて 2 種類が提供されています。異なる SPI フラッシュプログラミングファイルを生成する必要があるため、write_bitstream 出力ファイルも異なるポストプロセスが必要です。 makedata.tcl ファイルは別のプロジェクトのものを再利用するのではなく、ターゲットデバイスのサンプルデザイン用に生成した makedata.tcl ファイルを使用することを推奨します。

外部メモリプログラミングファイル

エラー分類を有効にした場合は、エッセンシャルビットのルックアップテーブルのイメージが必要です。このデータセットのサイズは、ターゲットデバイスによって異なります。データセットは write_bitstream アプリケーションによって生成されます。

データのフォーマットはバイナリで、 write_bitstream によって生成されたすべてのデータセットを使用する必要があります。外部ストレージはバイトアドレス指定可能なものが必要です。 fetch_tbladdr[31:0] によって SEM Controller に指定されたアドレスには、小規模なテーブルが必要です。デフォルトでは、fetch_tbladdr[31:0] は 0 です。

非 SSI デバイスのテーブルフォーマットは次のとおりです。

• バイト 0 – エッセンシャルビットデータバイト 0 (LSB) の先頭を示す 32 ビットポインター

• バイト 1 – エッセンシャルビットデータバイト 1 の先頭を示す 32 ビットポインター

• バイト 2 – エッセンシャルビットデータバイト 2 の先頭を示す 32 ビットポインター

• バイト 3 – エッセンシャルビットデータバイト 3 (MSB) の先頭を示す 32 ビットポインター

• 残りの 124 バイトは予約で、すべて 1 を書き込みます。

SSI デバイスのテーブルフォーマットは次のとおりです。

• バイト 0 – ハードウェア SLR0 (マスター) エッセンシャルビットデータバイト 0 (LSB) の先頭を示す 32 ビットポインター

• バイト 1 – ハードウェア SLR0 (マスター ) エッセンシャルビットデータバイト 1 の先頭を示す 32 ビットポインター

• バイト 2 – ハードウェア SLR0 (マスター ) エッセンシャルビットデータバイト 2 の先頭を示す 32 ビットポインター

• バイト 3 – ハードウェア SLR0 (マスター) エッセンシャルビットバイト 3 (MSB) の先頭を示す 32 ビットポインター

• バイト 4 – ハードウェア SLR1 エッセンシャルビットデータバイト 0 (LSB) の先頭を示す 32 ビットポインター

• バイト 5 – ハードウェア SLR1 エッセンシャルビットデータバイト 1 の先頭を示す 32 ビットポインター


• バイト 7 – ハードウェア SLR1 エッセンシャルビットバイト 3 (MSB) の先頭を示す 32 ビットポインター














• 残りの 112 バイトは予約で、すべて 1 を書き込みます。

データブロックが存在しない場合はポインターの値を 0xFFFFFFFF とします。エッセンシャルビットデータは任意のアドレスに配置できますが、各データブロックを連続して配置してバースト読み出しできるようにしておく必要があります。

デバイス境界を越えた読み出しバーストをサポートしない SPI フラッシュの場合、デバイス境界をまたがないようにデータブロックを配置する必要があります。たとえば集積度 256Mb を超える SPI フラッシュの多くは、 256Mb 境界を越えた読み出しバーストをサポートしていません。

write_bitstream 出力ファイルをポストプロセスする Tcl スクリプトにより、次の 3 つのファイルが生成されます。

• SPI フラッシュデバイスプログラミング用の Intel Hex データファイル (MCS)

• SPI フラッシュデバイスプログラミング用のバイナリデータファイル (BIN)

• SPI フラッシュシミュレーションモデルをロードするための初期化ファイル (VMF)





第 6章

テストベンチこの章では、 Vivado® Design Suite で提供されているテストベンチについて説明します。

サンプルデザインにはシミュレーションテストハーネスが付属します。このため、 UltraScale™ Architecture SEM Controller を含むデザインの機能およびタイミングシミュレーションを標準のザイリンクスシミュレーションフローを利用して実行できます。ただしシミュレーションでは SEM Controller の動作は観察できません。これにはハードウェアベースの評価が必要です。





付録 A

検証、互換性、相互運用性SEM Controller とサンプルデザインは、自動ハードウェアテストベンチなどいくつかの方法で一緒に検証されています。これらは、加速粒子を照射してバリデーションが行われ、自然に発生したランダムエラーイベントにソリューションが正しく対処できることも確認されます。

検証

SEM Controller の検証目標は、製品の機能仕様を元に決定しています。高い製品品質を確保するため、検証にはハードウェア検証メソドロジを使用します。使用した手法とツールは次のとおりです。

• ハードウェアテストベンチによるダイナミックチェック。期待されるビヘイビアーと実際のデザインのビヘイビアーを機能カバレッジで比較。

• 次に示すチェックツールスイートによるスタティックチェック。

° リント

° クロックドメインクロッシング (クロック乗せ換え)

ハードウェア検証プラットフォームで使用した SPI フラッシュデバイスは次のとおりです。

• 読み出し境界 256Mb のデバイス

° M25P128 (ST Microelectronics/Numonyx)

° M25L25635E (Macronix)

° N25Q512 (Micron)

° N25Q00 (Micron)

• 読み出し境界のないデバイス

° MT25QL01GB (Micron)

° MT25QL02GC (Micron)





付録 A:検証、互換性、相互運用性

バリデーション

ハードウェアバリデーションは、製品リリース前の後の関門となる重要なテストの 1 つです。ハードウェアバリデーションでは次のテストを実施して付加価値を高めます。

• 外部インターフェイスの評価 – 外部メモリシステムに対するタイミングバジェット評価

• 統合およびインプリメンテーション – 生成される可能性のあるすべてのコアネットリストのハードウェアテスト

• 動作環境の堅牢性 – サポートされるデバイスリストのすべてのサブファミリのサンプルテスト

適合性検査

業界標準の認証試験は定義されていません。生成したコアネットリストは、加速粒子を照射した状態で検査します。この検査には、次の目的があります。

• 挿入以外の方法で発生したエラーを正しく検出、訂正、分類できるかどうかを確認する。検証ではソリューション自体のエラー挿入機能を使用しており、挿入以外の方法で発生したエラーの検出、訂正、分類プロセスはテストされません。加速粒子照射テストでは、ソリューション自体の挿入機能を使用せずエラーを発生させることができます。

• エラーの検出、訂正、分類を含め、ソリューションが通常の予想される動作を示すかどうかを確認する。





付録 B

アップグレードこの付録では、新版 IP コアへのアップグレードについて説明します。 Vivado® Design Suite でアップグレードする場合のポート変更およびユーザーロジックへの影響といった重要な情報もここに記載されています。

Vivado Design Suite でのアップグレード

このセクションでは、コアバージョン間でのユーザーロジックまたはポートの変更点について説明します。

このコアは v3.0 でいくつかの変更が加えられた結果、それ以前のバージョンのコアとのピン互換性が失われました。これらの変更は、新しいエラー検出機能 (検出および診断スキャン) をサポートするために加えられたものです。

v2.0 から v3.0 への変更点

廃止されたパラメーター

コア v3.0 では、次の未使用 IP パラメーターが削除されました。

• INTERFACE

• ENABLE_CONFIG_SCAN

• MEMORY_TYPE

• MEMORY_IO_TYPE

• LOCATE_HELPER_BLOCKS





付録 B: アップグレード

追加されたポート

表 B-1 に、コントローラーに追加された 2 つの新しい出力ポート status_detect_only および status_diagnostic_scan を示します。

その他の変更点

コア v3.0 では、エラー検出レポートの先頭に次の 1 行が追加されています。

RI XX Reserved Information

UltraScale デバイスから UltraScale+ デバイスへの移行

SEM IP は、デバイスへの依存性があります。 UltraScale™ デバイスから UltraScale+™ デバイスへデザインを移行する場合、 IP を新規に生成し直すことを推奨します。動作やポート幅が異なるため、それに応じて周辺ロジックと RTL を変更する必要があります。

表 B‐1: v3.0 で追加されたポート

I/O ポート名説明機能

O status_detect_only この信号は、コントローラーが検出スキャンを実行している間アクティブです。

コントローラーが通常動作を継続していることを確認するために、 status_* ステート信号を監視するユーザーロジックにこの信号を統合する必要があります。

O status_diagnostic_scan この信号は、コントローラーが診断スキャンを実行している間アクティブです。

コントローラーが通常動作を継続していることを確認するために、 status_* ステート信号を監視するユーザーロジックにこの信号を統合する必要があります。





付録 C

評価ボードを使用した SEM Controller の動作デモ

SEM Controller IP は、デバイスへの依存性があります。 SEM Controller IP を生成する際、ターゲットとして評価ボードを選択できます。次の評価ボードをターゲットとした場合、生成された IP およびシステムレベルサンプルデザインをそのまま使用してハードウェアをブリングアップできます (ボードを選択するとデバイスも選択される )。

• Kintex® UltraScale™ KCU105 評価プラットフォーム

• Virtex® UltraScale™ VCU108 評価プラットフォーム

これらのデザインを使用すると、 IP の動作に対する理解を深めると共に、特性評価も可能です。

Zynq® UltraScale+ MPSoC ZCU102 評価プラットフォーム上で SEM Controller の動作デモを実施する方法は、『Zynq UltraScale+ デバイスへの LogiCORE SEM IP の統合』 (XAPP1298) [参照 4] および『AXI を使用した Zynq UltraScale+ デバイスへの LogiCORE SEM IP の統合』 (XAPP1303) [参照 5] を参照してください。





付録 C:評価ボードを使用した SEM Controller の動作デモ

ビットストリームの生成

サポートされる評価ボードをターゲットとした場合、 IP コンフィギュレーション、生成されるシステムレベルサンプルデザイン、制約はデフォルト設定のままでターゲットのデバイスおよびプラットフォームで使用できるようにコンフィギュレーションされます。ビットストリームを生成するには、次の手順を実行します。

1. 新規 Vivado® RTL プロジェクトを作成し、サポートされている評価ボードのいずれか 1 つを選択します (図 C-1)。X-Ref Target - Figure C-1

図 C‐1: ビットストリームの生成

X15916-012816






2. Vivado IP カタログで [UltraScale Soft Error Mitigation] IP を選択してコアを生成します。パラメーターはすべてターゲットプラットフォームに合わせたデフォルト値となっているため、変更の必要はありません。

X-Ref Target - Figure C-2

図 C‐2: SEM Controller の [Basic] タブ






3. [Out-of-Context Module Runs] が終了した後、 IP の生成が完了します。生成した IP を選択し、 [Open IP Example Design] をクリックします。


図 C‐3: SEM Controller の [Open IP Example Design]

X15914-012816






4. 次に、サンプルデザインを合成およびインプリメントしてビットストリームを生成します。このビットストリームを使用して、評価プラットフォーム上のデバイスをプログラムします。


図 C‐4: SEM Controller の [Generate Bitstream]

X15915-012816






ハードウェアとソフトウェアのセットアップ

ビットストリームを生成したら、プラットフォーム USB (または Digilent®) ケーブルと USB UART ケーブルでコンピューターとボードを接続します。ケーブルが正しく接続されると、 [コントロールパネル] の [デバイスとプリンター ] に次の項目が表示されます。

• Silicon Labs CP210x USB to UART Bridge

• Xilinx (プラットフォーム USB ケーブル名が表示)

SEM Controller の UART インターフェイスを利用してコマンドを発行およびステータス情報を受信するには、シリアルポート接続をサポートした Tera Term などのターミナルエミュレーターを正しく設定して使用する必要があります。ターミナルエミュレーターの設定方法の詳細は、第 3 章の「スイッチング動作」を参照してください。

ビットストリームおよび VIO コア用の debug_nets.ltx ファイルをプログラムしたら、 [Hardware Manager] に hw_vio_* ウィンドウを表示させて SEM Controller の信号を表示および操作します。


図 C‐5: SEM Controller の [Hardware Manager]

X16179-022316






UART インターフェイス経由での SEM Controller との通信デモ

このセクションでは、ターミナルエミュレーターを使用して UART インターフェイス経由で SEM Controller と通信し、基本的なエラー挿入を実行する手順および SEM Controller から出力されるステータスについて説明します。コマンドの送信およびステータスの受信はすべてターミナルエミュレーターで行います。ここでは初期化レポート、ステータスレポート、アイドルステートと監視ステート、エラー挿入、訂正レポートについて説明します。この例では、 Vivado 統合設計環境 (IDE) のデフォルト設定 (軽減 + テストモード、エラー分類無効) で IP をコンフィギュレーションしています。

この例でコントローラーのステートがどのように遷移するかを理解するには、 51 ページの図 3-5 のステート遷移図を参照してください。このデモで使用するコマンドとそのフォーマット、およびレポートの詳細は、第 3 章の「UART インターフェイスのメッセージ」および第 3 章の「UART インターフェイスのコマンド」を参照してください。

生成したビットストリームをデバイスにプログラムすると、ターミナルエミュレーターに初期化レポートが表示されます。次に、このレポートの例を示します。

SEM_ULTRA_V3_1 Name and versionSC 01 State transition to Initialization stateFS 04 Core Configuration InformationAF 01 Additional Core Configuration InformationICAP OK ICAP AvailableRDBK OK Status: Readback ActiveINIT OK Status: Completed SetupSC 02 State transition to ObservationO> Observation prompt

これでコントローラーは初期化を完了し、エラー条件の発生を検出するために FPGA コンフィギュレーションシステムの監視を開始します。 VIO ウィンドウで status_observation 信号がアサートされます。

コンフィギュレーションメモリで発生するエラーをエミュレートするには、コントローラーをアイドルステートに遷移させる必要があります。ターミナルエミュレーターから次のコマンドを UART インターフェイスに送信します。

O> I Enter Idle CommandSC 00 State change into Idle stateI> Idle prompt

これで、すべてのステータスフラグ (status_essential と status_uncorrectable を除くすべての status_*) がディアサートされ、コントローラーがアイドルステートに遷移したことを示します。

コントローラーがアイドルステートに遷移すると、内蔵のメモリスキャンおよびチェックが無効になります。このステートで利用可能なコマンドは、 55 ページの表 3-1 を参照してください。

UART インターフェイスに「S」コマンドを送信すると、次のような完全なステータスレポートが出力されます。

I> S Status request command ("S")SN 00 SLR numberSC 00 Current StateFC 00 Current FlagsRI 00 Reserved InformationMF 00006643 Maximum Linear Frame CountTS XXXXXXXX TimestampTB XXXXXXXX Table BaseCB XXXXXXXX Classification BaseCL 001 Classification LevelI> Idle Prompt






完全なステータスレポートが出力されると、再びアイドルステートのプロンプトが表示され、コマンドを実行可能な状態になります。

コンフィギュレーションメモリで発生するエラーをエミュレートするには、エラー挿入を実行します。この場合、通常はフレームの ECC ワードにエラーを挿入することを推奨します。 ECC ワードにエラーを挿入すると、コンフィギュレーションしたデザインに影響を与えずにコンフィギュレーションエラーが検出された場合の動作を観察できます。

また、エラー挿入の前後に Query コマンドを実行してエラー挿入フレームの内容を読み出すことを推奨します。これにより、エラー挿入によってコンフィギュレーションメモリの内容が変化したかどうか、そして挿入したエラーをコントローラーが検出および訂正するかどうかを確認できます。

次に示す例は、 UltraScale デバイスの ECC ワード内の 1 ビット (フレーム 0、ワード 61、ビット 0) にエラーを挿入しています。

まず、 Query コマンドを実行してフレーム 0 の内容を読み出します。

I> Q C000000000 Query command using LFA{61 lines of 00000000}00000000 Location we will inject an error {61 lines of 00000000}I>

次に、フレーム 0、ワード 61、ビット 0 にエラーを挿入します。

I> N C0000007A0 Error injection command using LFASC 10 State transition to Error InjectionSC 00 State transition to IdleI> Idle Prompt

エラー挿入を実行するとコントローラーは短時間だけエラー挿入ステートに遷移します。エラー挿入ステートの間、status_injection 信号がアサートされます。

後に、もう一度 Query コマンドを実行して選択した位置にエラーが挿入されたことを確認します。

I> Q C000000000 Query command by LFA{61 lines of 00000000}00000001 Location we have injected an error{61 lines of 00000000}I>

エラー挿入コマンドで指定した挿入先ビットの値が変化しているので、エラーが正しく挿入されたことがわかります。

コントローラーのエラー検出および訂正機能を試すには、コマンドを発行してコントローラーを監視ステートに戻し、 FPGA コンフィギュレーションメモリの監視を再開させる必要があります。

監視ステートに移行するには、次のコマンドを実行します。

I> O Enter Observation CommandSC 02 State transition to ObservationO> Observation promptRI XX Reserved information SC 04 State transition to CorrectionECC ECC error detectedTS 0000245D TimestampPA 0000000 PFA of detected errorLA 0000000 LFA of detected errorCOR Error correction report beginsWD 3D BT 00 Corrected word and bit valuesEND Error correction report endFC 00 Flag updated with correctability






SC 08 State transition to ClassificationFC 40 Flag updated with essentialness (if classification is disabled, it is always essential)SC 02 State transition to ObservationO> Observation prompt

これを見るとわかるように、コントローラーは監視ステートに移行した後エラーを検出し、訂正ステートに移行した後にエラー検出レポートと訂正レポートを出力しています。

エラー訂正が完了すると、コントローラーは分類ステートに移行した後に監視ステートに戻り、 FPGA コンフィギュレーションシステムの監視を再開してエラー条件の発生を検出します。

注記:分類機能を無効にしている場合、エッセンシャルフラグが常にアサートされます。

フラグ変化 (FC) レポートにより、次の 2 種類の情報が得られます。

• エラーが訂正可能かどうか (status_uncorrectable 信号の状態)

• エラーがエッセンシャルかどうか (status_essential 信号の状態)。

訂正可能かどうかのフラグは訂正レポート出力後に更新され、エッセンシャルかどうかのフラグは分類ステート終了前に更新されます。次にこれらの動作が行われるまで、フラグ変化レポートの値は変化しません。フラグ変化レポートの文字列とその意味は、 66 ページの表 3-4 を参照してください。

注記: UART インターフェイスから出力されるステート変化レポートおよびフラグ変化レポートの内容は、 VIO ウィンドウの status_* 信号でも確認できます。

コンフィギュレーションメモリで発生するエラーのエミュレーションの詳細は、付録 E 「エラー挿入のガイダンス」を参照してください。

このデモでは、コントローラーに対するコマンドはすべてターミナルエミュレーターから UART インターフェイス経由で入力しています。これらのコマンドは、 VIO ウィンドウを使用してコマンドインターフェイス経由でも実行できます。コマンドインターフェイスから有効なコマンドを入力すると UART インターフェイスにエコーバックされ、上記と同じステータスおよびレポートが出力されます。コマンドインターフェイス経由でのコマンド実行方法の詳細は、第 3 章の「コマンドインターフェイス」を参照してください。





付録 D

UART ログの例ここでは、 UltraScale+ FPGA のログの例を示します。特に記載のない限り、これらは SEM IP を軽減 + テストモード、エラー分類機能なしでコンフィギュレーションした場合の UART ログで、これによってコアの動作を観察できます。

初期化レポートSEM_ULTRA_V3_1SC 01FS 04AF 01ICAP OKRDBK OKINIT OKSC 02O>


非 SSI、アイドルステートの場合

I> SSN 00SC 00FC 00RI 00MF 0000BBB6TS 00000877TB XXXXXXXXCB XXXXXXXXCL 001I>





付録 D: UART ログの例

非 SSI、監視ステートの場合

O> SSN 00SC 02FC 00RI 00O>

SSI、アイドルステートの場合

I> SSN 00SC 00FC 00RI 00MF 0000DD19TS 00000020TB XXXXXXXXCB XXXXXXXXCL 001SN 01SC 00FC 00RI 00MF 0000DD19TS 00000020TB XXXXXXXXCB XXXXXXXXCL 001SN 02SC 00FC 00RI 00MF 0000DD19TS 00000020TB XXXXXXXXCB XXXXXXXXCL 001I>

SSI、監視ステートの場合

0> SSN 00SC 02FC 40RI 00SN 01SC 02FC 40RI 00SN 02SC 02FC 40RI 00






挿入コマンド

挿入が有効

I> N C000A098000 SC 10SC 00I>

挿入が無効

I> N C000A098000 SC 00I>

監視ステートへの移行コマンドI> OSC 02O>

アイドルステートへの移行コマンドO> ISC 00I>

検出ステートへの移行コマンドI> DSC 20D>






ソフトウェアリセットコマンドI> R 04SEM_ULTRA_V3_1 SC 01 FS 04 AF 01 ICAP OK RDBK OK INIT OKSC 02O>

フレームアドレス変換コマンドI> T C00051A090D0008000090DI>

Query コマンドI> Q C00051A090D(word 0 - 8-digit hex value)(word 1 - 8-digit hex value)...(word 92 - 8-digit hex value)I>

外部メモリ読み出し (Xmem) コマンドI> X 0000000094 I>

Peek コマンドI> P 0100000001I>






監視ステートのエラーレポート

1 ビット訂正可能 ECC – エラー分類無効

O> RI 00SC 04ECCTS 00000971PA 00180200LA 0000A098CORWD 22 BT 10ENDFC 00SC 08FC 40SC 02O>

2 ビット訂正可能 ECC、 1 つはエッセンシャルビット – エラー分類有効

O> RI 00SC 04ECCTS 00000971PA 00180200LA 0000A098CORWD 00 BT 01WD 00 BT 03ENDFC 00SC 08CLAWD 00 BT 03 LV 01ENDFC 40SC 02O>






訂正不能 ECC

O> RI 00SC 04ECCTS 00000971PA 00180200LA 0000A098CORENDFC 20SC 08FC 60SC 00I>

CRC エラー

O> RI 00SC 04CRCTS 00000B4FFC 20SC 08FC 60SC 00I>

AUX エラー

O> RI 00SC 04AUXTS 00000B4FFC 00SC 08FC 00SC 02O>

ROM エラー

O> RI 00SC 04ROMTS 00000B4FFC 40SC 08FC 00SC 02O>






検出ステートのエラーレポート

初にエラーを 1 つ検出すると、アイドルステートに戻ります。

訂正可能 ECC

検出モードでは、このエラーは訂正されません。

D>RI 00ECCTS 00001034PA 00000000LA 00000000WD 00 BT 00FC 60SC 00I>

訂正不能 ECC

D>RI 00ECCTS 0000328DPA 00000000LA 00000000FC 60SC 00I>

CRC エラー

D>RI 00CRCTS 00001866FC 60SC 00I>

ROM エラー

D> RI 00ROMTS 000002C6FC 60SC 00I>






AUX エラー

D>RI 00AUXTS 00001BACFC 60SC 00I>

診断スキャン

すべてのエラーについて、デバイスを 1 回スキャンします。検出したすべてのエラーを報告して、アイドルステートに戻ります。

訂正可能 1 ビット ECC

診断スキャンでは、報告されたエラーは訂正されません。

I> USC 40RI 00ECCTS 0000108DPA 00000000LA 00000000WD 00 BT 00SC 00I>

訂正不能 ECC

I> USC 40RI 00ECCTS 000032EBPA 00000000LA 00000000SC 00I>






訂正不能 ECC の後に訂正可能 ECC

I> USC 40RI 00ECCTS 000032EBPA 00000000LA 00000000RI 00ECCTS 00003E08PA 018C0400LA 0000D500WD 00 BT 00SC 00I>

エラー検出なし

I> USC 40SC 00I>





付録 E

エラー挿入のガイダンスSEM IP には、コントローラーの検証およびコントローラーのアプリケーション評価に役立つエラー挿入機能があります。一般に、どのようなタイプのエラー挿入を実行するかはその目的によって決まります。

目的: 基本的なエラー挿入テスト

このエラー挿入を実行するのは、その目的が次に該当する場合です。

• コントローラーがエラーを検出および訂正できているかを確認する。

• 検出および訂正されたエラーのログをシステムが正しく記録できているかを確認する。

• エラーによってデザインの機能が影響を受けた場合のシステムの動作はテスト対象に含めない。

エラー挿入位置は次のとおりです。

• フレームの ECC ワードにエラーを挿入します。

• UltraScale™ アーキテクチャの場合、 ECC ワードは各フレームのワード 60 と 61 にあります。ザイリンクスは、ワード 61 の下位バイトにエラーを挿入することを推奨しています。

• UltraScale+™ FPGA および MPSoC の場合、 ECC ワードは各フレームのワード 45 と 46 にあります。ザイリンクスは、ワード 46 の下位バイトにエラーを挿入することを推奨しています。 UltraScale+ デバイスの多くは、プロセッシングシステムが存在するかどうかや、使用するかどうかにかかわらず、コンフィギュレーションメモリにプロセッシングシステムの統合をサポートするために予約されたアドレス範囲が存在します。これらの予約アドレスに挿入されたエラーは検出されません。一般的な指針として、物理的に実装されたコンフィギュレーションメモリにマップするアドレスを選択するには、 (2/3 x 大リニアフレーム) より大きいリニアフレームアドレス (LFA) を使用することを推奨します。

この位置にエラーを挿入すると、コントローラーやデザインの機能に影響を与えずにエラーを挿入できます。

エラー挿入の目的が上記に当てはまらない場合は、サポートケースを開いて問い合わせてください。





付録 E: エラー挿入のガイダンス

次に、コントローラーのモニターまたはコマンドインターフェイスを使用してエラーを挿入する際の一般的な注意点をまとめます。

• リニアフレームアドレス (LFA) を使用してエラー挿入を実行します。有効なアドレス範囲は 0 ～ ( 大 LFA 値 – 2) です。たとえば XCKU040 の場合、大フレームは 26,179 です。したがって、エラー挿入の有効なアドレス範囲は 0 ～ 26,177 (26,179 – 2) です。各デバイスの大 LFA 値は表 2-2 に示してあります。また、コントローラーから出力されるステータスレポートにも「MF {8-digit hex value}」として表示されます。

• エラー挿入の前後には必ず Query コマンドを実行してエラー挿入が正しく実行されたこと、およびビットの読み出し /書き込みがマスクされていないことを確認してください。

• エラーは一度に 1 つのみ挿入します。コントローラーが挿入ステートを経由してアイドルステートに戻ったことを確認してから、次のエラー挿入を実行してください。アイドルステート以外でエラー挿入命令はドロップされるか失われます。

• エラー挿入の際は、も包括的な情報が得られるモニター /UART インターフェイスを使用してコマンドの送信およびステータスの監視を実行することを推奨します。

• コマンドインターフェイスを使用する場合は、コントローラーがアイドルステートに移行したことをステータスインターフェイスで確認してからエラーを挿入してください。また、エラー挿入コマンドを実行後にコントローラーがエラー挿入ステートに移行することもステータスインターフェイスで確認してください。

• 挿入した 1 ビットエラーがコントローラーによって検出されない場合、別のビットにエラーを挿入する前にもう一度同じビットへのエラー挿入を試みてください。

• 一度に複数ビットのエラーを挿入する場合、訂正されなかったエラービットをすべて元に戻してから次のエラー挿入を実行してください。または、デバイスをプログラムし直してからエラー挿入テストを再開してください。

次に、エラー挿入で特に注意が必要な点をまとめます。

• フレームがマスクされているか未実装のために、挿入したエラーが検出 (および訂正) されない場合があります。エラー挿入の前後に Query コマンドを実行しておくと、エラーが正しく挿入されたかどうかを確認できます。

• 通常、マスクされているのはダイナミックメモリ (DRP、 SRL など) に関係するフレームです。

• エラーを挿入してコントローラーから訂正不能エラーが報告された場合、いったんリコンフィギュレーションしてからテストを再開してください。





付録 F

IP デザインのチェックリストSEM Controller IP を使用および統合する際の注意点をチェックリスト形式にまとめます。

SEM IP を使用する際は、サポートされていない機能 (第 1 章の「サポートされていない機能」を参照) をチェックしてデザインとの互換性を確認します。

IP で利用できる機能の違いを理解し、どのような SEU 軽減アプローチをとるかを決定します。「SEM IP の導入に関する主な考慮事項」を参照してください。

ほとんどの場合、SEM Controller は軽減 + テストモードでデフォルトのコンフィギュレーションのまま使用します。この場合、 SEU イベントの検出と訂正に加え、エラー挿入機能も利用でき、アイドルステートではその他の便利な機能をすべて利用できます。量産段階で軽減モードに変更して、エラー挿入機能を無効にすることもできます。

コントローラーから報告されるエラーの種類 (訂正可能エラー、訂正不能エラー、訂正可能なエッセンシャルエラーなど) に応じてシステムの対応を変える必要があるかどうかを検討します。たとえばエッセンシャルでない訂正可能エラーが検出された場合は何もせず、エッセンシャルな訂正可能エラーが検出された場合はデバイスをリコンフィギュレーションするなどの対応が考えられます。少なくとも、モニターまたは UART インターフェイスを使用して検出されたすべてのエラーのログを記録してください。

SEM IP を含むデザインの出荷全数の信頼性推定値を設計前にスプレッドシート形式の SEU FIT Estimator で計算し、どの程度の頻度でエラーログを記録すべきかを把握します。設計前に使用するスプレッドシート形式の SEU FIT Estimator は、ザイリンクスの「品質と信頼性」ウェブページからダウンロードできます。

コントローラーに供給されるシステムクロックが、推奨ガイドラインに従っていることを確認します。第 3 章の「システムクロックインターフェイス」を参照してください。 SEM Controller とコンフィギュレーションプリミティブには、安定したクロック (グリッチがなく FMax に違反しない) 入力が必要です。初のクロックが不安定な場合は、クロックに BUFGCE バッファーを使用し、クロックが安定してから

バッファーを有効にしてください。

cap_gnt 信号の初の入力を 0 にして、この信号にマスター制御スイッチを追加してコントローラーが初期化するタイミングを制御することを検討します。 cap_gnt は、 ICAP の準備が完了してから 1 にします。

コントローラーへの入力クロックにマスター制御スイッチを追加することを検討します。このスイッチにより、クロックが安定してからコントローラーに供給するようにします。

未使用の入力ポートはすべて特定の値に接続します (詳細は、第 3 章の「インターフェイス」の各インターフェイスのセクションを参照)。これらのポートを正しく接続しない場合、コントローラーの初期化が完了しないことがあります。

使用するすべてのインターフェイスについて、システムレベル要件を確認します (詳細は、第 3 章の「インターフェイス」の各インターフェイスのセクションを参照)。

後でデバッグが行えるように、少なくともモニターインターフェイスの出力を FIFO バッファーに格納することを推奨します。この情報は、後で問題が発生した場合のデバッグに必要となります。第 3 章の「モニターインターフェイス」を参照してください。

後でデバッグが行えるように、デザイン合成後の DCP を保存しておくことを推奨します。

エラーおよびエラー発生フレームの位置をログに記録する際は、モニターまたは UART インターフェイスを使用します。第 3 章の「モニターインターフェイス」および第 3 章の「UART インターフェイス」を参照してください。 FRAME_ECC インターフェイスを監視することは推奨しません。

https://japan.xilinx.com/seu





付録 F: IP デザインのチェックリスト

UART インターフェイスでメッセージの文字化けや文字抜けが発生するなどの問題が発生する場合は、V_ENABLETIME の設定値が選択したボーレートおよびクロック周波数に適しているかどうかを確認します。また、 UART インターフェイスに接続している外部デバイスやターミナルエミュレーターの設定が正しいことを確認してください。第 3 章の「スイッチング動作」を参照してください。

SEM Controller は生成時にターゲットとしたデバイス専用です。あるデバイスに対して生成した SEM Controller を別のデバイスに使用しないでください。

コントローラーの制約が正しいことを確認してください (第 4 章の「コアへの制約」を参照)。

• コントローラーの icap_clk に対するクロック周期制約

• コントローラーと ICAP の間の一部の非同期パスに対するフォルスパス制約

• 適切な配置には、 ICAP および FRAME_ECC 制約の適用が必要となることがあります。

シミュレーションではコントローラーの動作を観察できませんが、コントローラーをインスタンシエートしたデザインのシミュレーションはサポートされます。第 4 章の「シミュレーション」を参照してください。

コントローラーと FRAME_ECC/ICAP プリミティブの間には、サンプルデザインで提供されているものを除きパイプラインレジスタを配置しないでください。

第 3 章の「システム」を参照して、 SEM ソリューションをシステムレベルで監視する機能が必要かどうかを検討してください。

デザインの推定 FIT が目標レベルに達しない場合は、 SEU からブロック RAM を ECC で保護するなど、ソフトエラーに対するデザインの耐性を高める各種手法の採用を検討してください。

SEM IP を早期段階でデザインに統合し、 SEM IP の機能を有効にしてハードウェアでデザインのバリデーションを実行してください。第 4 章の「統合およびバリデーション」を参照してください。

デバッグ手順の詳細は、付録 J 「デバッグ」を参照してください。

コントローラーの動作に関するクイックリファレンスとして、図 3-5 ～図 3-7 に示したコントローラーの有効なステート遷移図を参照してください。

エラー挿入を実行する際は、挿入の前後に Query コマンドを実行してエラーが正しく挿入されたことを確認してください。付録 E 「エラー挿入のガイダンス」を参照してください。





付録 G

SPI バスタイミングバジェット

SPI バスクロックの波形およびタイミングバジェット

SPI フラッシュデバイスには、入力クロックのスイッチ特性に関する要件があります。ここでは、システムレベルサンプルデザインによって生成される SPI フラッシュデバイス用のクロック信号について解析します。この解析を実行するには、ボードレベルのシグナルインテグリティシミュレーション機能が必要です。

図 G-1 に示したように、SPI フラッシュデバイスの入力クロックの要件として次のパラメーターが定義されています。

• Tclch = SPI バスクロックの大立ち上がり時間

• Tchcl = SPI バスクロックの大立ち下がり時間

• Tcl = SPI バスクロックの小 Low 時間

• Tch = SPI バスクロックの小 High 時間

SPI バスの物理的な構成、 FPGA の I/O 特性、およびレベル変換器を使用する場合はその I/O 特性により、 FPGA から送信される SPI バスクロック信号の立ち上がり時間 (Trise) と立ち下がり時間 (Tfall) は、 SPI フラッシュデバイスに到達した時点で大となります。 Trise と Tfall がそれぞれ Tclch と Tchcl の要件を満たしていることを検証する必要があります。 Tclch と Tchcl の要件が満たされていない場合、次のような対策をとることができます。

• システムレベルサンプルデザインの SPI バスクロック出力に対する I/O スルーレートを変更する。

• システムレベルサンプルデザインの SPI バスクロック出力に対する I/O 駆動能力を変更する。

• I/O 特性の適したレベル変換器に交換する。

一般に、 Tclch と Tchcl の要件は容易に満たすことができます。これらの要件が存在するのは、システムレベルサンプルデザインで使用しているポイントツーポイント方式ではなく、多くの負荷を接続したバスで立ち上がり時間と立ち下がり時間が極端に長くなるのを防ぐためです。

システムレベルサンプルデザインによって生成される SPI バスクロックは、入力クロックを 2 分周したものです。したがって、SPI バスクロックの High および Low 時間は名目上は Tclk と同じです。ただし実際の Trise および Tfall を考慮して、次の要件も満たす必要があります。

• Tclk Trise + Tch

• Tclk Tfall + Tcl

X-Ref Target - Figure G-1

図 G‐1: SPI フラッシュデバイスの入力クロック要件

c

Tclch

Tchcl

Tcl

Tch

X22336-022019





付録 G: SPI バスタイミングバジェット

例:

• Tclch = 33ns (SPI フラッシュのデータシートより )

• Tchcl = 33ns (SPI フラッシュのデータシートより )

• Tcl = 3.375ns (SPI フラッシュのデータシートより )

• Tch = 3.375ns (SPI フラッシュのデータシートより )

• Trise = 2ns (PCB シミュレーションより )

• Tfall = 2ns (PCB シミュレーションより )

これらのデータより、次の解析を実行します。

1. チェック : Tclch Trise であるか。すなわち 33ns 2ns であるか。 Yes

2. チェック : Tchcl Tfall であるか。すなわち 33ns 2ns であるか。 Yes

3. 計算: Tclk Trise + Tch より、 Tclk 2ns + 3.375ns、すなわち Tclk 5.375ns

4. 計算: Tclk Tfall + Tcl より、 Tclk 2ns + 3.375ns、すなわち Tclk 5.375ns

立ち上がり時間の要件は満たされています。 Tclk に対するこれらの要件により、 SPI バスクロックの波形およびタイミングバジェットではシステムレベルサンプルデザインの入力クロックサイクル時間が 5.375ns 以上に制限されます。

SPI バス送信の波形およびタイミングバジェット

SPI フラッシュデバイスには、入力クロックを基準とした入力データのスイッチ特性に関する要件があります。ここでは、システムレベルサンプルデザインから受信したデータを SPI フラッシュデバイスでキャプチャする場合について解析します。

図 G-2 に示したように、 SPI フラッシュデバイスがデータを正しく取り込むための要件として次のパラメーターが定義されています。

• Tdvch = クロックを基準とした SPI フラッシュの小データセットアップ時間

• Tchdx = クロックを基準とした SPI フラッシュの小データホールド時間

この解析は、小伝搬遅延を 0 と仮定しています。また、次に示すスキューが無視できるものと仮定しています。

• FPGA 出力フリップフロップへの入力クロック分配のスキュー。

• FPGA 出力フリップフロップから FPGA ピンへの出力信号パスのスキュー。

• PCB レベル変換器のチャネル遅延のスキュー。この条件を満たすには、クロックとデータパスのレベル変換器の遅延が一致していなければなりません。


図 G‐2: SPI フラッシュデバイスの入力データキャプチャ要件

Tdvch

c

d

Tchdx

X22337-022019






• PCB トレースセグメント遅延のスキュー。この条件を満たすには、クロックとデータパスのトレース遅延が一致していなけばなりません。

• デューティサイクルの歪み。

SPI フラッシュマスターヘルパーブロックと PCB のインプリメンテーションパラメーターとして次のパラメーターが定義されています。

• Tclk = 入力クロックサイクル時間 (icap_clk)

• Tqfpga = icap_clk を基準とした FPGA 出力遅延

• Tw1 = FPGA からレベル変換器までの PCB トレース遅延

• Tw2 = レベル変換器から SPI フラッシュまでの PCB トレース遅延

• Tdly = レベル変換器のチャネル遅延

図 G-3 に、SPI フラッシュマスターヘルパーブロックインプリメンテーションによって生成されるメモリシステムの信号を示します。

前述の仮定により、クロックとデータパスの遅延はどちらも同じで、 PVT (プロセス、電圧、温度) ばらつきの影響も同じです。次の関係が成り立ちます。

• Tclk Tdvch

• Tclk Tchdx

例:

• Tdvch = 1.75ns (SPI フラッシュのデータシートより )

• Tchdx = 2ns (SPI フラッシュのデータシートより )

1. 計算: Tclk Tdvch、すなわち Tclk 1.75ns

2. 計算: Tclk Tchdx、すなわち Tclk 2ns

Tclk に対するこれらの要件により、 SPI バス送信の波形およびタイミングバジェットではシステムレベルサンプルデザインの入力クロックサイクル時間が 2ns 以上に制限されます。


図 G‐3:入力データキャプチャのタイミング

icap_clk

spi_c

spi_d

c

d

Tdvch Tchdx

Tqfpga

Tclk Tclk

Tw1+Tdly+Tw2

X15965-021116






SPI バス受信の波形およびタイミングバジェット

SPI フラッシュデバイスは、入力クロックを基準とした出力データの出力スイッチ特性が決まっています。ここでは、 SPI フラッシュデバイスから受信したデータをシステムレベルサンプルデザインでキャプチャする場合について解析します。

図 G-4 に示したように、 SPI フラッシュデバイスの出力スイッチ動作として次のパラメーターが定義されています。

• Tclqv = クロックを基準とした SPI フラッシュの大出力 Valid 時間

• Tclqx = クロックを基準とした SPI フラッシュの小出力ホールド時間

この解析は、小伝搬遅延を 0 と仮定しています。また、次に示すスキューが無視できるものと仮定しています。

• FPGA 出力および入力フリップフロップへの入力クロック分配のスキュー。

• PCB レベル変換器のチャネル遅延のスキュー。この条件を満たすには、クロックとデータパスのレベル変換器の遅延が一致していなければなりません。

• デューティサイクルの歪み。

SPI フラッシュマスターヘルパーブロックと PCB のインプリメンテーションパラメーターとして次のパラメーターが定義されています。

• Tclk = 入力クロックサイクル時間 (icap_clk)

• Tqfpga = icap_clk を基準とした FPGA 出力遅延

• Tsfpga = icap_clk を基準とした FPGA 入力セットアップ時間

• Thfpga = icap_clk を基準とした FPGA 入力ホールド時間

• Tw1 = FPGA からレベル変換器までの PCB トレース遅延

• Tw2 = レベル変換器から SPI フラッシュまでの PCB トレース遅延

• Tw3 = SPI フラッシュからレベル変換器までの PCB トレース遅延

• Tw4 = レベル変換器から FPGA までの PCB トレース遅延

• Tdly = レベル変換器のチャネル遅延

このタイミングパスは SPI フラッシュマスターヘルパーブロックに対しては 2 サイクルパスですが、SPI フラッシュデバイスに対しては 1 サイクルパスです。タイミング解析では、 SPI フラッシュデバイスの Clock-to-Out を組み合わせ遅延としてモデル化します。 FPGA 側でのセットアップとホールドの両方の要件を考慮する必要があります。


図 G‐4: SPI フラッシュデバイスの出力データスイッチ特性

Tclqx

c

q

TclqvTclqv

TclqxX22338-022019






図 G-5 と図 G-6 に、SPI フラッシュマスターヘルパーブロックインプリメンテーションによって生成されるメモリシステムの信号を示します。

ホールドパス解析は合否判定です。ホールドパス解析は小値の遅延を使用して計算し、次の関係が成り立つかを確認する必要があります。

Thfpga Tqfpga,min + Tw1 + Tdly + Tw2 + Tclqx + Tw3 + Tdly + Tw4

遅延 Tw1、 Tw2、 Tw3、 Tw4、および Tdly に安全な小値として 0 を代入すると、次式が得られます。

Thfpga Tqfpga,min + Tclqx

セットアップパス解析は大値の遅延を使用して計算する必要があります。

Tclk 0.5 × (Tqfpga,max + Tw1 + Tdly + Tw2 + Tclqv + Tw3 + Tdly + Tw4 + Tsfpga)


図 G‐5:出力データキャプチャタイミング (ホールド解析)


図 G‐6:出力データキャプチャタイミング (セットアップ解析)

TqfpgaTw1+Tdly+Tw2

TclqxTw3+Tdly+Tw4

Thfpga

icap_clk

spi_c

spi_q

c

q

X15967-021116

Tqfpga

Tclk Tclk

Tw1+Tdly+Tw2

TclqvTw3+Tdly+Tw4

Tsfpga

icap_clk

spi_c

spi_q

c

q

X15968-021116






例: Vivado Design Suite、 Kintex UltraScale FPGA

• Tclqv = 6ns (SPI フラッシュのデータシートより )

• Tclqx = 1ns (SPI フラッシュのデータシートより )

• Tdly = 2.8ns (レベル変換器のデータシートより )

• Tw1 = 1ns (ボードシミュレーションより )




FPGA タイミングパラメーターは、アプリケーションで使用するターゲット FPGA にインプリメントしたシステムレベルサンプルデザインでのタイミングレポートから取得する必要があります。必要なレポートを生成するには、report_timing_summary に min_max オプションを付けて実行します。

次に示す例は、 Kintex® UltraScale™ デバイスにインプリメントしたシステムレベルサンプルデザインで生成したタイミングレポートの抜粋です。これは、タイミングレポートから必要な情報を得るための例として示しています。レポート内に必要な情報が見つからない場合は、レポートに含めるパスの大数を増やしてください。

タイミングレポートの「Destination: spi_c」と表示された場所で、「Max at Slow Process Corner」にあるフリップフロップからパッドまでのパス解析を参照し、 Tqfpga の値を確認します。

• Tqfpga = I/O データパス遅延 (spi_c)

• Tqfpga = 1.856ns、大

Slack (MET): 15.037ns (required time - arrival time) Source: example_support_wrapper/example_support/example_spi/example_spi_byte/spi_c_ofd/C (rising edge-triggered cell FDRE clocked by clk {[email protected] [email protected] period=11.111ns}) Destination: spi_c (output port clocked by clk {[email protected] [email protected] period=11.111ns}) Path Group: clk Path Type: Max at Slow Process Corner Requirement: 11.111ns (clk [email protected] - clk [email protected]) Data Path Delay: 1.856ns (logic 1.476ns (79.523%) route 0.380ns (20.477%)) Logic Levels: 1 (OBUF=1) Output Delay: -11.111ns Clock Path Skew: -5.294ns (DCD - SCD + CPR) Destination Clock Delay (DCD): 0.000ns = ( 11.111 - 11.111 ) Source Clock Delay (SCD): 5.294ns Clock Pessimism Removal (CPR): 0.000ns Clock Uncertainty: 0.035ns ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE Total System Jitter (TSJ): 0.071ns Total Input Jitter (TIJ): 0.000ns Discrete Jitter (DJ): 0.000ns Phase Error (PE): 0.000ns Clock Net Delay (Source): 2.304ns (routing 0.335ns, distribution 1.969ns)






Location Delay type Incr(ns) Path(ns) Netlist Resource(s) ------------------------------------------------------------------- ------------------- (clock clk rise edge) 0.000 0.000 r K20 0.000 0.000 r clk (IN) net (fo=0) 0.000 0.000 example_ibuf/I K20 r example_ibuf/INBUF_INST/PAD K20 INBUF (Prop_INBUF_HRIO_PAD_O) 0.805 0.805 r example_ibuf/INBUF_INST/O net (fo=1, routed) 0.092 0.897 example_ibuf/OUT K20 r example_ibuf/IBUFCTRL_INST/I K20 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O) 0.043 0.940 r example_ibuf/IBUFCTRL_INST/O net (fo=1, routed) 1.967 2.907 example_support_wrapper/clk BUFGCE_X1Y24 r example_support_wrapper/example_bufg/I BUFGCE_X1Y24 BUFGCE (Prop_BUFCE_BUFGCE_I_O) 0.083 2.990 r example_support_wrapper/example_bufg/O X2Y1 (CLOCK_ROOT) net (fo=1742, routed) 2.304 5.294 example_support_wrapper/example_support/example_spi/example_spi_byte/clk BITSLICE_RX_TX_X0Y172 FDRE r example_support_wrapper/example_support/example_spi/example_spi_byte/spi_c_ofd/C ------------------------------------------------------------------- ------------------- BITSLICE_RX_TX_X0Y172 FDRE (Prop_OUT_FF_BITSLICE_COMPONENT_RX_TX_C_Q) 0.626 5.920 r example_support_wrapper/example_support/example_spi/example_spi_byte/spi_c_ofd/Q net (fo=1, routed) 0.380 6.300 spi_c_OBUF AC23 r spi_c_OBUF_inst/I AC23 OBUF (Prop_OUTBUF_HPIOB_I_O) 0.850 7.150 r spi_c_OBUF_inst/O net (fo=0) 0.000 7.150 spi_c AC23 r spi_c (OUT) ------------------------------------------------------------------- -------------------

(clock clk rise edge) 11.111 11.111 r clock pessimism 0.000 11.111 clock uncertainty -0.035 11.076 output delay 11.111 22.187 ------------------------------------------------------------------- required time 22.187 arrival time -7.150 ------------------------------------------------------------------- slack 15.037






タイミングレポートの「Destination: spi_c」と表示された場所で、「Min at Fast Process Corner」にあるフリップフロップからパッドまでのパス解析を参照し、 Tqfpga の値を確認します。

• Tqfpga = I/O データパス遅延 (spi_c)

• Tqfpga = 0.919ns、小

Slack (MET): 3.227ns (arrival time - required time) Source: example_support_wrapper/example_support/example_spi/example_spi_byte/spi_c_ofd/C (rising edge-triggered cell FDRE clocked by clk {[email protected] [email protected] period=11.111ns}) Destination: spi_c (output port clocked by clk {[email protected] [email protected] period=11.111ns}) Path Group: clk Path Type: Min at Fast Process Corner Requirement: 0.000ns (clk [email protected] - clk [email protected]) Data Path Delay: 0.919ns (logic 0.752ns (81.829%) route 0.167ns (18.171%)) Logic Levels: 1 (OBUF=1) Output Delay: 0.000ns Clock Path Skew: -2.308ns (DCD - SCD - CPR) Destination Clock Delay (DCD): 0.000ns Source Clock Delay (SCD): 2.308ns Clock Pessimism Removal (CPR): -0.000ns Clock Net Delay (Source): 1.077ns (routing 0.127ns, distribution 0.950ns)

Location Delay type Incr(ns) Path(ns) Netlist Resource(s) ------------------------------------------------------------------- ------------------- (clock clk rise edge) 0.000 0.000 r K20 0.000 0.000 r clk (IN) net (fo=0) 0.000 0.000 example_ibuf/I K20 r example_ibuf/INBUF_INST/PAD K20 INBUF (Prop_INBUF_HRIO_PAD_O) 0.418 0.418 r example_ibuf/INBUF_INST/O net (fo=1, routed) 0.025 0.443 example_ibuf/OUT K20 r example_ibuf/IBUFCTRL_INST/I K20 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O) 0.015 0.458 r example_ibuf/IBUFCTRL_INST/O net (fo=1, routed) 0.746 1.204 example_support_wrapper/clk BUFGCE_X1Y24 r example_support_wrapper/example_bufg/I BUFGCE_X1Y24 BUFGCE (Prop_BUFCE_BUFGCE_I_O) 0.027 1.231 r example_support_wrapper/example_bufg/O X2Y1 (CLOCK_ROOT) net (fo=1742, routed) 1.077 2.308 example_support_wrapper/example_support/example_spi/example_spi_byte/clk BITSLICE_RX_TX_X0Y172 FDRE r example_support_wrapper/example_support/example_spi/example_spi_byte/spi_c_ofd/C ------------------------------------------------------------------- -------------------






BITSLICE_RX_TX_X0Y172 FDRE (Prop_OUT_FF_BITSLICE_COMPONENT_RX_TX_C_Q) 0.268 2.576 r example_support_wrapper/example_support/example_spi/example_spi_byte/spi_c_ofd/Q net (fo=1, routed) 0.167 2.743 spi_c_OBUF AC23 r spi_c_OBUF_inst/I AC23 OBUF (Prop_OUTBUF_HPIOB_I_O) 0.484 3.227 r spi_c_OBUF_inst/O net (fo=0) 0.000 3.227 spi_c AC23 r spi_c (OUT) ------------------------------------------------------------------- -------------------

(clock clk rise edge) 0.000 0.000 r clock pessimism 0.000 0.000 output delay -0.000 0.000 ------------------------------------------------------------------- required time -0.000 arrival time 3.227 ------------------------------------------------------------------- slack 3.227

タイミングレポートの「Source: spi_q」と表示された場所で、「Setup (Max at Fast Process Corner)」にあるパッドからフリップフロップまでのパス解析を参照し、 Tsfpga の値を確認します。

• Tsfpga = I/O データパス遅延 (spi_q)

• Tsfpga = 0.658ns、大

Slack (MET): 23.825ns (required time - arrival time) Source: spi_q (input port clocked by clk {[email protected] [email protected] period=11.111ns}) Destination: example_support_wrapper/example_support/example_spi/example_spi_byte/spi_q_ifd/D (rising edge-triggered cell FDRE clocked by clk {[email protected] [email protected] period=11.111ns}) Path Group: clk Path Type: Setup (Max at Fast Process Corner) Requirement: 11.111ns (clk [email protected] - clk [email protected]) Data Path Delay: 0.658ns (logic 0.495ns (75.210%) route 0.163ns (24.790%)) Logic Levels: 2 (IBUFCTRL=1 INBUF=1) Input Delay: -11.111ns Clock Path Skew: 2.318ns (DCD - SCD + CPR) Destination Clock Delay (DCD): 2.318ns = ( 13.429 - 11.111 ) Source Clock Delay (SCD): 0.000ns Clock Pessimism Removal (CPR): 0.000ns Clock Uncertainty: 0.035ns ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE Total System Jitter (TSJ): 0.071ns Total Input Jitter (TIJ): 0.000ns Discrete Jitter (DJ): 0.000ns Phase Error (PE): 0.000ns Clock Net Delay (Destination): 1.087ns (routing 0.127ns, distribution 0.960ns)






Location Delay type Incr(ns) Path(ns) Netlist Resource(s) ------------------------------------------------------------------- ------------------- (clock clk rise edge) 0.000 0.000 r input delay -11.111 -11.111 U21 0.000 -11.111 r spi_q (IN) net (fo=0) 0.000 -11.111 spi_q_IBUF_inst/I U21 r spi_q_IBUF_inst/INBUF_INST/PAD U21 INBUF (Prop_INBUF_HPIOB_PAD_O) 0.495 -10.616 r spi_q_IBUF_inst/INBUF_INST/O net (fo=1, routed) 0.047 -10.569 spi_q_IBUF_inst/OUT U21 r spi_q_IBUF_inst/IBUFCTRL_INST/I U21 IBUFCTRL (Prop_IBUFCTRL_HPIOB_I_O) 0.000 -10.569 r spi_q_IBUF_inst/IBUFCTRL_INST/O net (fo=1, routed) 0.116 -10.453 example_support_wrapper/example_support/example_spi/example_spi_byte/spi_q BITSLICE_RX_TX_X0Y186 FDRE r example_support_wrapper/example_support/example_spi/example_spi_byte/spi_q_ifd/D ------------------------------------------------------------------- -------------------

(clock clk rise edge) 11.111 11.111 r K20 0.000 11.111 r clk (IN) net (fo=0) 0.000 11.111 example_ibuf/I K20 INBUF r example_ibuf/INBUF_INST/PAD K20 INBUF (Prop_INBUF_HRIO_PAD_O) 0.418 11.529 r example_ibuf/INBUF_INST/O net (fo=1, routed) 0.025 11.554 example_ibuf/OUT K20 IBUFCTRL r example_ibuf/IBUFCTRL_INST/I K20 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O) 0.015 11.569 r example_ibuf/IBUFCTRL_INST/O net (fo=1, routed) 0.746 12.315 example_support_wrapper/clk BUFGCE_X1Y24 BUFGCE r example_support_wrapper/example_bufg/I BUFGCE_X1Y24 BUFGCE (Prop_BUFCE_BUFGCE_I_O) 0.027 12.342 r example_support_wrapper/example_bufg/O X2Y1 (CLOCK_ROOT) net (fo=1742, routed) 1.087 13.429 example_support_wrapper/example_support/example_spi/example_spi_byte/clk BITSLICE_RX_TX_X0Y186 FDRE r example_support_wrapper/example_support/example_spi/example_spi_byte/spi_q_ifd/C clock pessimism 0.000 13.429 clock uncertainty -0.035 13.394 BITSLICE_RX_TX_X0Y186 FDRE (Setup_IN_FF_BITSLICE_COMPONENT_RX_TX_C_D) -0.022 13.372 example_support_wrapper/example_support/example_spi/example_spi_byte/spi_q_ifd ------------------------------------------------------------------- required time 13.372 arrival time 10.453 ------------------------------------------------------------------- slack 23.825






タイミングレポートの「Source: spi_q」と表示された場所で、「Hold (Min at Slow Process Corner)」にあるパッドからフリップフロップまでのパス解析を参照し、 Thfpga の値を確認します。

• Thfpga = I/O データパス遅延 (spi_q)

• Thfpga = 0.468ns、小

Slack (MET): 17.334ns (arrival time - required time) Source: spi_q (input port clocked by clk {[email protected] [email protected] period=11.111ns}) Destination: example_support_wrapper/example_support/example_spi/example_spi_byte/spi_q_ifd/D (rising edge-triggered cell FDRE clocked by clk {[email protected] [email protected] period=11.111ns}) Path Group: clk Path Type: Hold (Min at Slow Process Corner) Requirement: 0.000ns (clk [email protected] - clk [email protected]) Data Path Delay: 0.468ns (logic 0.242ns (51.750%) route 0.226ns (48.250%)) Logic Levels: 2 (IBUFCTRL=1 INBUF=1) Input Delay: 22.222ns Clock Path Skew: 5.302ns (DCD - SCD - CPR) Destination Clock Delay (DCD): 5.302ns Source Clock Delay (SCD): 0.000ns Clock Pessimism Removal (CPR): -0.000ns Clock Net Delay (Destination): 2.312ns (routing 0.335ns, distribution 1.977ns)

Location Delay type Incr(ns) Path(ns) Netlist Resource(s) ------------------------------------------------------------------- ------------------- (clock clk rise edge) 0.000 0.000 r input delay 22.222 22.222 U21 0.000 22.222 r spi_q (IN) net (fo=0) 0.000 22.222 spi_q_IBUF_inst/I U21 r spi_q_IBUF_inst/INBUF_INST/PAD U21 INBUF (Prop_INBUF_HPIOB_PAD_O) 0.242 22.464 r spi_q_IBUF_inst/INBUF_INST/O net (fo=1, routed) 0.050 22.514 spi_q_IBUF_inst/OUT U21 r spi_q_IBUF_inst/IBUFCTRL_INST/I U21 IBUFCTRL (Prop_IBUFCTRL_HPIOB_I_O) 0.000 22.514 r spi_q_IBUF_inst/IBUFCTRL_INST/O net (fo=1, routed) 0.176 22.690 example_support_wrapper/example_support/example_spi/example_spi_byte/spi_q BITSLICE_RX_TX_X0Y186 FDRE r example_support_wrapper/example_support/example_spi/example_spi_byte/spi_q_ifd/D ------------------------------------------------------------------- -------------------

(clock clk rise edge) 0.000 0.000 r K20 0.000 0.000 r clk (IN) net (fo=0) 0.000 0.000 example_ibuf/I K20 INBUF r example_ibuf/INBUF_INST/PAD K20 INBUF (Prop_INBUF_HRIO_PAD_O) 0.805 0.805 r example_ibuf/INBUF_INST/O net (fo=1, routed) 0.092 0.897 example_ibuf/OUT






K20 IBUFCTRL r example_ibuf/IBUFCTRL_INST/I K20 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O) 0.043 0.940 r example_ibuf/IBUFCTRL_INST/O net (fo=1, routed) 1.967 2.907 example_support_wrapper/clk BUFGCE_X1Y24 BUFGCE r example_support_wrapper/example_bufg/I BUFGCE_X1Y24 BUFGCE (Prop_BUFCE_BUFGCE_I_O) 0.083 2.990 r example_support_wrapper/example_bufg/O X2Y1 (CLOCK_ROOT) net (fo=1742, routed) 2.312 5.302 example_support_wrapper/example_support/example_spi/example_spi_byte/clk BITSLICE_RX_TX_X0Y186 FDRE r example_support_wrapper/example_support/example_spi/example_spi_byte/spi_q_ifd/C clock pessimism 0.000 5.302 BITSLICE_RX_TX_X0Y186 FDRE (Hold_IN_FF_BITSLICE_COMPONENT_RX_TX_C_D) 0.054 5.356 example_support_wrapper/example_support/example_spi/example_spi_byte/spi_q_ifd ------------------------------------------------------------------- required time -5.356 arrival time 22.690 ------------------------------------------------------------------- slack 17.334

チェック :

• Thfpga ≤ Tqfpga,min + Tclqx であるか。

• すなわち 0.468ns ≤ 0.919ns + 1ns であるか。

• すなわち 0.468ns ≤ 1.919ns であるか。 Yes

計算:

Tclk ≥ 0.5 × (Tqfpga,max + Tw1 + Tdly + Tw2 + Tclqv + Tw3 + Tdly + Tw4 + Tsfpga)

すなわち

Tclk ≥ 0.5 × (1.856ns + 1ns + 2.8ns + 1ns + 6ns + 1ns + 2.8ns + 1ns + 0.658ns)

すなわち

Tclk ≥ 9.057ns

ホールド要件は満たされています。また、 Tclk に対する要件により、 SPI バス受信の波形およびタイミングバジェットではシステムレベルサンプルデザインの入力クロックサイクル時間が 9.057ns 以上に制限されます。






SPI バスタイミングバジェットのまとめ

SPI フラッシュマスターヘルパーブロックと外部メモリシステムが存在する場合、インプリメンテーションの堅牢性を確保するには SPI バスタイミングバジェットを解析する必要があります。この解析結果により、外部メモリシステムが正しく機能することが確認され、システムレベルサンプルデザインの入力クロックの大周波数に対する制約がわかります。

Kintex UltraScale にインプリメントした SEM IP コアの Vivado Design Suite タイミングレポートで報告されたサンプルデータにより、メモリインターフェイスが正しく機能することが確認されます。メモリインターフェイスは入力クロック周波数が 110.412MHz 以下でないと動作しないため、Tclk に対するも厳しい要件は Tclk ≥ 9.057ns です。ICAP の大クロック周波数やシステムレベルサンプルデザインの大クロック周波数など、ほかの入力クロック周波数の制限も考慮する必要があります。





付録 H

モニターインターフェイスのシグナリングとプロトコル

この付録では、モニターインターフェイスの信号とプロトコルについて説明します。 UART ヘルパーブロックを別の機能で置き換えて SEM Controller のメッセージを解析し、エラー位置などの情報を得るには、この説明を参考にしてください。

モノリシックおよび UltraScale+ SSI デバイス

図 H-1 に、モニターインターフェイスの送信プロトコルを示します。 1 バイトのデータを送信する場合、コントローラーはまず monitor_txfull 信号をサンプリングして送信バッファーに 1 バイトのデータを格納できる空きがあるかを調べます。 monitor_txfull が Low の場合、コントローラーは monitor_txdata[7:0] にデータを与えし、 monitor_txwrite を 1 クロックサイクルだけアサートして 1 バイトのデータを送信します。

コントローラーは、 monitor_txdata[7:0] に一連のデータを与え、 monitor_txwrite を複数サイクル続けてアサートすることでバースト書き込みを実行できます。ただしコントローラーは monitor_txfull を監視することにより、送信バッファーオーバーランを防いでいます。

データ受信側のペリフェラルは、バッファーの空きを正しく追跡して monitor_txfull で報告します。ペリフェラルは、 monitor_txwrite = High をサンプリングした次のサイクルで、データの書き込みによってバッファーが完全にフルである場合は monitor_txfull をアサートする必要があります。

また、ペリフェラルはコントローラーからの monitor_txwrite への応答としてのみ monitor_txfull をアサートする必要があります。ペリフェラル内部のイベントに基づいて monitor_txfull をアサートすることはできません。これは、コントローラーが書き込みを実行する何サイクルか前に monitor_txfull をサンプリングすることがあるためです。

ペリフェラルが monitor_txfull をアサートしている間、コントローラーは送信待ちのデータがある場合でも動作を停止します。これにより、コントローラーのエラー軽減パフォーマンスが低下します。たとえばエラー訂正が発生してコントローラーがエラーを正しく訂正 (または処理) した場合、コントローラーはステータスレポートを送信します。ペリフェラルがこのメッセージを完全に受信するまでコントローラーは動作を停止し、監視ステートに戻ることができません。したがって、カスタムペリフェラルを設計する際はバッファー深さとデータ消費レートのバランスを考慮する必要があります。

X-Ref Target - Figure H-1

図 H‐1: モニターインターフェイスの送信プロトコル

icap_clk

monitor_txdata[7:0]

monitor_txwrite

monitor_txfull

d0 d1 d2 d3 d4

write burst write 3 bytes write

data buffer full





付録 H: モニターインターフェイスのシグナリングとプロトコル

図 H-2 に、モニターインターフェイスの受信プロトコルを示します。 1 バイトのデータを受信する場合、コントローラーはまず monitor_rxempty 信号をサンプリングして受信バッファーに 1 バイトのデータが格納されているかを調べます。 monitor_rxempty が Low の場合、コントローラーは monitor_rxdata[7:0] から 1 バイトのデータを受信し、 monitor_rxread を 1 クロックサイクルだけアサートして受信完了を通知します。

コントローラーは、 monitor_rxdata[7:0] からデータシーケンスを取得し、 monitor_rxread を複数サイクル続けてアサートすることでバースト読み出しを実行できます。ただしコントローラーは monitor_rxempty を監視することにより、受信バッファーアンダーランを防いでいます。

データ送信側のペリフェラルは、バッファーのステータスを正しく追跡して monitor_rxempty で報告します。ペリフェラルは、 monitor_rxread = High をサンプリングした次のサイクルで、バッファーが空の場合は monitor_rxempty をアサートする必要があります。

また、ペリフェラルはコントローラーからの monitor_rxread への応答としてのみ monitor_rxempty をアサートする必要があります。ペリフェラル内部のイベントに基づいて monitor_rxempty をアサートすることはできません。これは、コントローラーが読み出しを実行する何サイクルか前に monitor_rxempty をサンプリングすることがあるためです。

モニターインターフェイスで送受信するデータのフォーマットは、バイトストリーム ASCII コードです。各 ASCII コードは、 1 バイトのデータで表されます。トランザクションはすべて 1 バイトずつ実行されます。

たとえば、エラー挿入コマンド N C0000007A4 を送信する場合、ペリフェラルは monitor_rxempty を Low に駆動してデータの準備ができていることを通知した後、 ASCII コードを N (x4E)、スペース (x20)、 C (x43)、 (中略)、4 (x34) の順にモニター RX インターフェイスに送信します。図 H-3 に、このトランザクションを示します。


図 H‐2: モニターインターフェイスの受信プロトコル


図 H‐3: モニター RX インターフェイスを使用してペリフェラルからエラー挿入コマンドを送信

icap_clk

monitor_rxdata[7:0]

monitor_rxread

monitor_rxempty

d0 d1 d2 d3 d4

read burst read 3 bytes read

data buffer empty empty





付録 H: モニターインターフェイスのシグナリングとプロトコル

コマンドを受信すると、コントローラーはモニター TX インターフェイスを使用してコマンドを送り返します (エコーバック )。このエコーバックにより、コントローラーがコマンドを受信し、次のコマンドを受信可能な状態であることがペリフェラルに通知されます。このことは、 monitor_txfull が Low になることによっても示されます。図 H-4 に、このトランザクションを示します。

注記: コントローラーがペリフェラルから受信したデータまたはコマンドが正しくないか無効な場合、コマンドはペリフェラルへエコーバックされません。

UltraScale SSI デバイス

UltraScale™ SSI デバイスの場合、付属のサンプルデザインには SLR ごとに存在する各コントローラーのモニターインターフェイスを 1 つの UART インターフェイスに集約するためのロジックが追加されます。

推奨: 付属のサンプルデザインを使用しない場合は、各コントローラーのモニターインターフェイスを個別に管理する必要があります。この場合、インターフェイスの動作は前のセクションで説明したとおりです。


図 H‐4: SEM Controller がペリフェラルからエラー挿入コマンドを正しく受信した場合





付録 I

フェッチインターフェイスのシグナリングとプロトコル

この付録では、フェッチインターフェイスについて説明します。フェッチインターフェイスは、エラー分類に使用するエッセンシャルビットデータを SEM Controller に供給するために使用します。このインターフェイスが必要なのは、 SEM Controller の分類機能を有効にした場合のみです。また、 SPI フラッシュマスターヘルパーブロックをパラレルフラッシュメモリコントローラーなど別の機能で置き換える場合も、この付録の内容を参照してください。

UltraScale™ SSI デバイスの場合、サンプルデザインの SPI フラッシュマスターは複数の SLR のフェッチインターフェイスを使用して 1 つの SPI フラッシュを管理します。その他のデバイスでは、サンプルデザインの SPI フラッシュマスターは 1 つのフェッチインターフェイスで 1 つの SPI フラッシュを管理します。

図 I-1 に、フェッチインターフェイスの送信プロトコルを示します。 1 バイトのデータを送信する場合、コントローラーはまず fetch_txfull 信号をサンプリングして送信バッファーに 1 バイトのデータを格納できる空きがあるかを調べます。 fetch_txfull が Low の場合、コントローラーは fetch_txdata[7:0] にデータを与え、fetch_txwrite を 1 クロックサイクルだけアサートして 1 バイトのデータを送信します。

コントローラーは、 fetch_txdata[7:0] に一連のデータを与え、 fetch_txwrite を複数サイクル続けてアサートすることでバースト書き込みを実行できます。ただしコントローラーは fetch_txfull を監視することにより、送信バッファーオーバーランを防いでいます。

データ受信側のペリフェラルは、バッファーの空きを正しく追跡して fetch_txfull で報告します。ペリフェラルは、 fetch_txwrite = High をサンプリングした次のサイクルで、データの書き込みによってバッファーが完全にフルである場合は fetch_txfull をアサートする必要があります。

また、ペリフェラルはコントローラーからの fetch_txwrite への応答としてのみ fetch_txfull をアサートする必要があります。ペリフェラル内部のイベントに基づいて fetch_txfull をアサートすることはできません。これは、コントローラーが書き込みを実行する何サイクルか前に fetch_txfull をサンプリングすることがあるためです。

ペリフェラルが fetch_txfull をアサートしている間、コントローラーは送信待ちのデータがある場合でも動作を停止します。これにより、コントローラーのエラー軽減パフォーマンスが低下します。

X-Ref Target - Figure I-1

図 I‐1: フェッチインターフェイスの送信プロトコル

icap_clk

fetch_txdata[7:0]

fetch_txwrite

fetch_txfull

d0 d1 d2 d3 d4

write burst write 3 bytes write

data buffer full full






図 I-2 に、フェッチインターフェイスの受信プロトコルを示します。 1 バイトのデータを受信する場合、コントローラーはまず fetch_rxempty 信号をサンプリングして受信バッファーに 1 バイトのデータが格納されているかを調べます。 fetch_rxempty が Low の場合、コントローラーは fetch_rxdata[7:0] から 1 バイトのデータを受信し、 fetch_rxread を 1 クロックサイクルだけアサートして受信完了を通知します。

コントローラーは、 fetch_rxdata[7:0] からデータシーケンスを取得し、 fetch_rxread を複数サイクル続けてアサートすることでバースト読み出しを実行できます。ただしコントローラーは fetch_rxempty を監視することにより、受信バッファーアンダーランを防いでいます。

データ送信側のペリフェラルは、バッファーのステータスを正しく追跡して fetch_rxempty で報告します。ペリフェラルは、 fetch_rxread = High をサンプリングした次のサイクルで、バッファーが空の場合は fetch_rxempty をアサートする必要があります。

また、ペリフェラルはコントローラーからの fetch_rxread への応答としてのみ fetch_rxempty をアサートする必要があります。ペリフェラル内部のイベントに基づいて fetch_rxempty をアサートすることはできません。これは、コントローラーが読み出しを実行する何サイクルか前に fetch_rxempty をサンプリングすることがあるためです。

データは 2 進数で交換され、コマンド /応答ペアを表します。データフォーマットはリトルエンディアンです。data[7:0] の場合、 0 が LSB で 7 が MSB です。 32 ビットワードの場合、バイト 0 が LSB でバイト 3 が MSB です。分類ステート (status_classification = 1) では、コントローラーはフェッチインターフェイスを使用してコマンドを送信し、外部メモリから分類データを読み出します。アドレスはすべてバイトアドレスで、トランザクションはすべて 1 バイトずつ実行されます。

コントローラーが fetch_tx インターフェイスを使用して 6 バイトのコマンドシーケンスを送信すると、データフェッチが開始します。このコマンドシーケンスは次のとおりです。

• バイト 1: ADD[31:24]

• バイト 2: ADD[23:16]

• バイト 3: ADD[15:8]

• バイト 4: ADD[7:0]

• バイト 5: LEN[15:8]

• バイト 6: LEN[7:0]

ADD フィールドはアドレスで、 LEN フィールドはコントローラーがペリフェラルから受信するデータバイト数を表します。通常、コマンドタイプは「開始アドレス ADD から長さ LEN バイトを読み出す」です。コントローラーが送信する ADD フィールドの値は、ユーザーが定義した分類ベースポインターによって異なります。 78 ページの「フェッチインターフェイス」を参照してください。


図 I‐2: フェッチインターフェイスの受信プロトコル

icap_clk

fetch_rxdata[7:0]

fetch_rxread

fetch_rxempty

d0 d1 d2 d3 d4

read burst read 3 bytes read

data buffer empty empty






図 I-3 に、このコマンドシーケンスを示します。

これに応答して、ペリフェラルは ADD[31:0] で指定されたアドレスを先頭に LEN[15:0] で指定されたバイト数のデータをフェッチして、このデータをコントローラーに返す必要があります。コントローラーがコマンドを発行した後、ペリフェラルは fetch_rx インターフェイスに要求された正確なバイト数を返してコマンドを完了する必要があります。図 I-4 に、 LEN = 4 の場合のトランザクションを示します。

注記: ブートまたは初期化ステートでは、 SEM Controller は fetch_rxread ポートに対して 2 つの特殊な読み出しシーケンスを実行して、このインターフェイスをリセットします。この読み出しシーケンスはデータの取得が目的ではないため、データは無視できます。


図 I‐3: SEM Controller からペリフェラルへコマンドを送信する


図 I‐4: ペリフェラルから SEM Controller へデータを返す





付録 J

デバッグこの付録では、ザイリンクスサポートウェブサイトより入手可能なリソースおよびデバッグツールについて説明します。

ザイリンクスウェブサイト

UltraScale Architecture SEM Controller を使用した設計およびデバッグでヘルプが必要な場合は、ザイリンクスサポートウェブページから製品の資料、リリースノート、アンサーなどを参照するか、テクニカルサポートでサービスリクエストを作成してください。

資料

この製品ガイドは SEM Controller に関する主要資料です。このガイド、並びに設計プロセスで使用する各製品の関連資料はすべて、ザイリンクスサポートウェブページ (https://japan.xilinx.com/support) またはザイリンクス Documentation Navigator から入手できます。

ザイリンクス Documentation Navigator は、ダウンロードページからダウンロードできます。このツールの詳細および機能は、インストール後にオンラインヘルプを参照してください。

アンサー

アンサーには、よく発生する問題についてその解決方法、およびザイリンクス製品に関する既知の問題などの情報が記載されています。アンサーは、ユーザーが該当製品の新情報にアクセスできるよう作成および管理されています。

このコアに関するアンサーの検索には、ザイリンクスサポートウェブページにある検索ボックスを使用します。より的確な検索結果を得るには、次のようなキーワードを使用してください。

• 製品名

• ツールに表示されるメッセージ

• 問題の概要

検索結果は、フィルター機能を使用してさらに絞り込むことができます。

UltraScale Architecture SEM Controller に関するマスターアンサー :

AR 63609





https://japan.xilinx.com/support/download.html






付録 J:デバッグ

テクニカルサポート

ザイリンクスは、製品資料の説明に従って使用されている LogiCORE™ IP 製品に対するテクニカルサポートをザイリンクスサポートウェブページで提供しています。ただし、次のいずれかに該当する場合、タイミング、機能、サポートは保証されません。

• 資料で定義されていないデバイスにソリューションをインプリメントした場合。

• 資料で定義されている許容範囲を超えてカスタマイズした場合。

• 「DO NOT MODIFY」とされているデザインセクションに変更を加えた場合。

ザイリンクステクニカルサポートへのお問い合わせは、ザイリンクスサポートウェブページを参照してください。

デバッグツール

SEM Controller デザインの問題に対応できるツールは多数あります。さまざまな状況をデバッグするのに有益なツールを理解しておくことが重要です。

Vivado Design Suite のデバッグ機能

Vivado® Design Suite のデバッグ機能は、Logic Analyzer および Virtual I/O コアをユーザーデザインに直接挿入します。デバッグ機能を使用すると、トリガー条件を設定して、ハードウェアでアプリケーションおよび統合ブロックのポート信号をハードウェアに取り込むことができます。取り込まれた信号は、その後解析できます。 Vivado IDE のこの機能は、ザイリンクスデバイスで実行されるデザインの論理デバッグおよび検証に使用されます。

Vivado ロジック解析は次の LogiCORE IP ロジックデバッグコアと共に使用されます。

• ILA 2.0 (およびそれ以降のバージョン)

• VIO 2.0 (およびそれ以降のバージョン)

詳細は、『Vivado Design Suite ユーザーガイド : プログラムおよびデバッグ』 (UG908) [参照 12] を参照してください。

リファレンスボード

SEM Controller コアはさまざまなザイリンクス開発ボードでサポートされています。これらのボードを使用してデザインのプロトタイプを作成し、コアがシステムと通信できるようにします。 UltraScale アーキテクチャ評価ボードは KCU105 を使用しています。









ハードウェアデバッグ

ハードウェアの問題は、リンク立ち上げ時の問題から、テスト後に生じる問題までさまざまです。ここでは、一般的な問題のデバッグ手順を説明します。 Vivado Design Suite のデバッグ機能は、ハードウェアデバッグに有益なリソースです。次の各セクションに示す信号を Vivado Design Suite のデバッグ機能でプローブすることで、個々の問題をデバッグできます。

汎用チェック

コアに対するタイミング制約がサンプルデザインからすべて適切に取り込まれていること、さらにインプリメンテーション時にこれらの制約がすべて満たされていることを確認します。

クロック管理ブロックを使用するデザインでは、ブロックのステータスを監視してロックが完了したか確認してください。

推奨: ザイリンクスは、 SEM IP コアをなるべく早い段階で (理想的にはプロジェクトの初から ) 統合することを推奨しています。詳細は、 102 ページの「統合およびバリデーション」を参照してください。

インターフェイスのデバッグ


モニターインターフェイスの使用は必須ではありませんが、モニターインターフェイスを接続する手段を確保しておくことを強く推奨します。モニターインターフェイスからは、潜在的な問題のデバッグやトラブルシューティングに役立つ重要な情報が得られます。システムレベルサンプルデザインに含まれる UART ヘルパーブロックは、標準 RS232 ポートに接続するか、 USB-to-UART ブリッジを介して USB に接続できる UART です。

システムでこの接続を利用できない場合は、少なくともモニターインターフェイスの出力を FIFO バッファーに格納し、デバッグ用にデータをポストプロセスできるようにすることを強く推奨します。

どちらの方法も不可能な場合、コントローラーの初期化を正しく完了させるには、モニターインターフェイスを適切な値に接続しておく必要があります。詳細は、第 3 章の「モニターインターフェイス」を参照してください。この接続を正しくしておかないと、コントローラーは初期化ステートでハングしてしまいます。

SEM Controller が正しく動作しているかは、 SEM Controller がモニターインターフェイスから出力する初期化レポートで確認します。通常、このレポートのフォーマットは次のとおりです。

SEM_ULTRA_V3_1SC 01FS 03AF 01ICAP OKRDBK OKINIT OKSC 02O>

1 行目はコアバージョンを示しています。 3 行目は SEM Controller の機能セットを示しており、コア生成時に選択した SEM コントローラーコアのオプションの要約が表示されます。






UART ヘルパーブロックを使用していて初期化レポートに正常な文字が表示されない場合は、「スイッチング動作」と第 3 章の「UART インターフェイス」を参照して端末プログラムの通信設定が正しいかどうか確認してください。

また、実際に SEM Controller に供給されるクロック周波数と UART ヘルパーブロックの V_ENABLETIME パラメーター値の組み合わせで標準ボーレートが得られるか、また端末プログラムの通信設定がビットレートと一致しているかを確認してください。詳細は式 3-1 および式 3-2 を参照してください。

SEM Controller が ICAP プリミティブ経由で FPGA コンフィギュレーションロジックと通信できない場合、初期化レポートは「ICAP」の行で止まり、「OK」が表示されません。これは、 SEM Controller が FPGA コンフィギュレーションロジックと通信できないためです。この場合、次のような初期化レポートが表示されます。

SEM_ULTRA_V3_1SC 01FS 03AF 01ICAP

この場合、 ICAP が応答しない理由を特定する必要があります。一般的な確認事項は次のとおりです。

• 使用するデバイスに合わせて ICAP が正しくインスタンシエートされているか確認する。

• ほかのプロセスによって ICAP がブロックされていないか確認する。

JTAG アクセスが発生していないこと、 SelectMAP の persist を設定していないことを確認する。

• ICAP 共有を使用しない場合、 SEM Controller と ICAP を直接接続する必要があります。 SEM Controller と ICAP の間にパイプライン処理を追加することは避けてください。

第 1 章の「サポートされていない機能」で説明したように、 SEM Controller を POST_CRC、 POST_CONFIG_CRC、またはその他の関連する制約と併用することはできません。初期化レポートが ICAP、 RDBK、または INIT の行で止まる場合、これらが使用中でないことを確認してください。


モニターインターフェイスをデバッグに使用できない場合も、コントローラーが初期化ステートを正しく完了して通常動作していることを確認する必要があります。コントローラーの有効なステート遷移については、図 3-5 ～図 3-7 を参照してください。






その他のエラー挿入オプション

リニアフレームアドレス (LFA) 以外にも、物理フレームアドレス (PFA) を使用してエラーを挿入できます。このフォーマットによるエラー挿入コマンドは、モニター (または UART) インターフェイスとコマンドインターフェイスのいずれからも実行できます。

表 J‐1: PFA を使用したエラー挿入の UART コマンド


PFA を使用したエラー挿入

「N {10-digit hex value}」

UltraScale = 2 進数の値 = 0sst trrr rrrc cccc cccc cmmm mmmm wwww wwwb bbbb

UltraScale+ = 2 進数の値 = 00ss 0ttt rrrr rrcc cccc cccc mmmm mmmm wwww wwwb bbbb

アイドルステートの場合に有効。軽減 + テスト、検出 + テスト、エミュレーションモードの場合のみ有効。


ss ハードウェア slr 番号 (2 ビット )

tt

または

ttt

ブロックタイプ (UltraScale では 2 ビット、 UltraScale+ では 3 ビット )

rrrrrr 行アドレス (6 ビット )

cccccccccc 列アドレス (10 ビット )

mmmmmmm マイナーアドレス (UltraScale では 7 ビット、 UltraScale+ では 8 ビット )

wwwwwww ワードアドレス (7 ビット )

bbbbb ビットアドレス (5 ビット )

表 J‐2: PFA を使用したエラー挿入のコマンドフォーマット

コマンドCommand_code[n – 1:0] のフォーマット

UltraScale では n = 40、 UltraScale+ では n = 44

PFA を使用したエラー挿入

UltraScale = 2 進数の値 = 0sst trrr rrrc cccc cccc cmmm mmmm wwww wwwb bbbb

UltraScale+ = 2 進数の値 = 00ss 0ttt rrrr rrcc cccc cccc mmmm mmmm wwww wwwb bbbb

コントローラーがアイドルステートの場合に有効。軽減 + テスト、検出 + テスト、エミュレーションモードの場合のみ有効。


ss ハードウェア slr 番号 (2 ビット )

tt

または

ttt

ブロックタイプ (UltraScale では 2 ビット、 UltraScale+ では 3 ビット )

rrrrrr 行アドレス (6 ビット )

cccccccccc 列アドレス (10 ビット )

mmmmmmm マイナーアドレス (UltraScale では 7 ビット、 UltraScale+ では 8 ビット )

wwwwwww ワードアドレス (7 ビット )

bbbbb ビットアドレス (5 ビット )






クロッキング

SEM Controller のクロックはオシレーターからピンを経由して直接 SEM Controller へ供給することを推奨します。内部の PLL またはミックスドモードクロックマネージャー (MMCM) でクロックを生成すると、クロック生成に関係するコンフィギュレーションセルが SEU イベントの影響を受ける可能性があります。その確率は非常にわずかですが、信頼性を低下させる要因はなるべく排除しておく必要があります。どうしても PLL/MMCM 出力またはその他のロジックを使用してクロックを生成する必要がある場合は、デザインのスタートアップ中や PLL/MMCM がロックするまでの間を含め、クロックが SEM Controller の小周期要件に違反しないよう注意が必要です。

クロック管理ブロックを使用する場合、クロックが安定するまで SEM Controller へのクロックのトグルを抑制してください。たとえば BUFGMUX または BUFGCE を使用して、 PLL/MMCM がロックするまで SEM Controller のクロックがトグルしないようにします。

IP に供給されるクロックが安定していない場合、 SEM Controller が次のような動作を示すことがあります。

• ブートおよび初期化シーケンスが完了しない

• 初期化を完了して監視ステートに移行後、すぐに重大エラーレポートが出力される

デバイスへの依存性

SEM Controller は生成時にターゲットとしたデバイス専用です。あるデバイスに対して生成したコントローラーのデザインチェックポイント (DCP) を別のデバイスおよびハードウェアをターゲットにしたより大規模なデザインで使用した場合、コントローラーはブートおよび初期化プロセスを完了しても正しく動作しません。

デザインのプロパティおよび制約

SEM Controller は、 FPGA シリコンに内蔵されたソフトエラー軽減機能を初期化および管理します。これをデザインに含める場合は、内蔵の検出機能を有効にするようなデザイン制約またはオプションを含めないでください。たとえば POST_CRC、 POST_CONFIG_CRC、またはこれらに関連する制約を設定しないでください。同様に、GLUTMASK を無効にするようなオプションも使用しないでください。 SEM Controller によるエラーの誤検出を防ぐには、デフォルト値の YES としておく必要があります。





付録 K

その他のリソースおよび法的通知

ザイリンクスリソース

アンサー、資料、ダウンロード、フォーラムなどのサポートリソースは、ザイリンクスサポートサイトを参照してください。

Documentation Navigator およびデザインハブ

ザイリンクス Documentation Navigator (DocNav) では、ザイリンクスの資料、ビデオ、サポートリソースにアクセスでき、特定の情報を取得するためにフィルター機能や検索機能を利用できます。 DocNav を開くには、次のいずれかを実行します。

• Vivado IDE で [Help] → [Documentation and Tutorials] をクリックします。

• Windows で [スタート ] → [すべてのプログラム] → [Xilinx Design Tools] → [DocNav] をクリックします。

• Linux コマンドプロンプトに「docnav」と入力します。

ザイリンクスデザインハブには、資料やビデオへのリンクがデザインタスクおよびトピックごとにまとめられており、これらを参照することでキーコンセプトを学び、よくある質問 (FAQ) を参考に問題を解決できます。デザインハブにアクセスするには、次のいずれかを実行します。

• DocNav で [Design Hubs View] タブをクリックします。

• ザイリンクスウェブサイトのデザインハブページを参照します。

注記: DocNav の詳細は、ザイリンクスウェブサイトの Documentation Navigator ページを参照してください。

注意: DocNav からは、日本語版は参照できません。ウェブサイトのデザインハブページをご利用ください。



https://japan.xilinx.com/cgi-bin/docs/ndoc?t=design+hubs

https://japan.xilinx.com/cgi-bin/docs/rdoc?t=docnav




付録 K: その他のリソースおよび法的通知

参考資料

次の資料は、この製品ガイドの補足資料として役立ちます。

注記:日本語版のバージョンは、英語版より古い場合があります。

1. 『ザイリンクスデバイス信頼性レポート』 (UG116)

2. 『UltraScale アーキテクチャコンフィギュレーションユーザーガイド』 (UG570: 英語版、日本語版)

3. 『Zynq UltraScale+ MPSoC テクニカルリファレンスマニュアル』 (UG1085: 英語版、日本語版)

4. 『Zynq UltraScale+ デバイスへの LogiCORE SEM IP の統合』 (XAPP1298: 英語版、日本語版)

5. 『AXI を使用した Zynq UltraScale+ デバイスへの LogiCORE SEM IP の統合』 (XAPP1303: 英語版、日本語版)

6. 『モノリシックデバイスでの Soft Error Mitigation IP およびパーシャルリコンフィギュレーションのデモ』 (XAPP1261: 英語版、日本語版)

7. 『Zynq UltraScale+ MPSoC ソフトウェア開発者向けガイド』 (UG1137: 英語版、日本語版)

8. 『OS およびライブラリ資料コレクション』 (UG643)

9. 『Vivado Design Suite ユーザーガイド : ロジックシミュレーション』 (UG900: 英語版、日本語版)

10. 『Vivado Design Suite ユーザーガイド : インプリメンテーション』 (UG904: 英語版、日本語版)

11. 『Vivado Design Suite ユーザーガイド : IP を使用した設計』 (UG896: 英語版、日本語版)

12. 『Vivado Design Suite ユーザーガイド : プログラムおよびデバッグ』 (UG908: 英語版、日本語版)

13. 『Vivado Design Suite ユーザーガイド : 入門』 (UG910: 英語版、日本語版)


https://japan.xilinx.com/support/documentation/user_guides/ug116.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug570-ultrascale-configuration.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug570-ultrascale-configuration.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug1085-zynq-ultrascale-trm.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=application_notes;d=xapp1298-integrating-sem-ip.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=application_notes;d=j_xapp1298-integrating-sem-ip.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=application_notes;d=xapp1303-integrating-sem-ip-with-axi.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=application_notes;d=j_xapp1303-integrating-sem-ip-with-axi.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=application_notes;d=xapp1261-demo-sem-pr.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=application_notes;d=j_xapp1261-demo-sem-pr.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1137-zynq-ultrascale-mpsoc-swdev.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug1137-zynq-ultrascale-mpsoc-swdev.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=oslib_rm.pdf

https://www.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug900-vivado-logic-simulation.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug900-vivado-logic-simulation.pdf

https://www.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug904-vivado-implementation.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug904-vivado-implementation.pdf

https://japan.xilinx.com/support/index.html/content/xilinx/en/supportNav/design_tools.html

https://www.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug896-vivado-ip.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug896-vivado-ip.pdf

https://www.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug908-vivado-programming-debugging.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug908-vivado-programming-debugging.pdf

https://www.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug910-vivado-getting-started.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug910-vivado-getting-started.pdf





改訂履歴

次の表に、この文書の改訂履歴を示します。

日付バージョン内容

2019 年 5 月 22 日 3.1 • 表 2-2、表 2-6、および表 2-8 に XCVU27P と XCVU29P を追加。

• 「エラー検出レポート – 軽減 (+ テスト ) モード (訂正機能有効)」、「エラー検出レポート – 検出ステート」、および「エラー検出レポート – 診断スキャン」に検出レポートの説明を追加。

• 「UART インターフェイスのコマンド」に UART に関する注記を追加。

• 表 3-7 に XCVU27P と XCVU29P を追加。

• 表 5-1 に VU27P/VU29P を追加。

• 「フェッチインターフェイスのシグナリングとプロトコル」の見出しを削除。

2018 年 11 月 14 日 3.1 • 「パーシャルリコンフィギュレーションのサポート」を追加。

• 「サポートされていない機能」に宇宙放射線に関する説明を追加。

2018 年 4 月 4 日 3.1 • 「概要」の章の「サポートされていない機能」セクションを更新。

• 「製品仕様」の章の「ソリューションの信頼性」セクションを更新。

• 「コアを使用するデザイン」の章の「システムクロックインターフェイス」セクションを更新。

• 付録「フェッチインターフェイスのシグナリングとプロトコル」の初の段落を更新。

• 付録「フェッチインターフェイスのシグナリングとプロトコル」にブートステートに関する注記を追加。

2017 年 12 月 20 日 3.1 • 「概要」の説明を更新。

• 「概要」に「SEM IP の導入に関する主な考慮事項」を追加。

• 「暗号化と認証のサポート」セクションを更新。

• 「UltraScale+ デバイスの大スタートアップレイテンシ (ICAP FMax の場合)」および「UltraScale+ デバイスの大 IP エラー検出時間 (ICAP FMax の場合)」の表の XCVU9P に脚注を追加。

• 「エラー訂正レイテンシ」セクションの UltraScale+ モノリシックと UltraScale+ SSI に脚注を追加。

• 「エラー分類レイテンシ」セクションの UltraScale+ モノリシックと UltraScale+ SSI に脚注を追加。

• 「エラー挿入レイテンシ」セクションの UltraScale+ VU3P と UltraScale+ SSI VU9P に脚注を追加。

• KU040 の「ステータスインターフェイスのハートビートのスイッチ特性」の図を更新。

• 「モニターインターフェイス」セクションにモニターインターフェイスの付録に関する説明を追加。

• 「UART インターフェイスのメッセージ」の「初期化レポート」セクションの SC コードを更新。

• 「ステート変化レポートのデコード」の表の重大エラーを 9F に変更。

• 「ステータスレポート」セクションに検出機能の説明を追加。

• 「フェッチインターフェイス」セクションにフェッチインターフェイスの付録に関する説明を追加。

• モニターインターフェイスとフェッチインターフェイスに関する付録を追加。






2017 年 10 月 4 日 3.1 • 「IP の概要」の章を更新。

• 「UltraScale+ デバイスのサポート」セクションを削除。

• 「製品仕様」の章に XCVU31P ～ XCVU37P、および XCZU21DR ～ XCZU29DR を追加。

• 「エラー分類レイテンシ (モニターインターフェイスでのスロットリングなし」の表に UltraScale+ SSI の説明を追加。

• 「LFA を使用した場合のエラー挿入レイテンシ (モニターインターフェイスでのスロットリングなし」の表に UltraScale+ SSI VU3P の説明を追加。

• 「デバイスのリソース使用量 – マルチ SLR UltraScale および UltraScale+ デバイス (SSI)」の表に VU9P の説明を追加。

• 「ステータスインターフェイスの信号」の表に status_essential の説明を追加。

• 「分類 (軽減 (+ テスト ) モードのみ)」のセクションに status_essential の説明に関するヒントを追加。

• 「フェッチインターフェイス」セクションに説明を追加。

• 「外部ストレージの要件」の表の UltraScale+ の説明を更新。

• 「コアを使用するデザイン」の章の「必須の制約」セクションに説明を追加。

• 「外部メモリプログラミングファイル」セクションに SSI デバイスの説明を追加。

• ステータスレポートに関する付録に SSI デバイスの説明を追加。







2017 年 4 月 5 日 3.1 • 「IP の概要」の表に新しくサポートされたデバイスを追加。

• 「UltraScale+ デバイスのサポート」セクションを更新。

• 「サポートされていない機能」セクションにゴールデン/フォールバックの説明を追加。

• 「コンフィギュレーションフレームの大数」から「エラー訂正レイテンシ (モニターインターフェイスでのスロットリングなし)」の表にデバイスを追加。

• 「リソース使用状況」セクションの説明を更新。

• 「ポートの説明」セクションの説明を更新。

• 「FRAME_ECC インターフェイス」および「ステータスインターフェイス」セクションに説明を追加。

• 「一般的なデザインガイドライン」セクションの説明を更新。

• 「システム」セクションの説明を更新。

• 「構造オプション」セクションに注記を追加。

• 「コアを使用するデザイン」の章の「FRAME_ECC インターフェイス」および「ステータスインターフェイス」セクションに説明を追加。

• 「Zynq UltraScale+ MPSoC の注意事項」セクションを追加。

• 「コマンドインターフェイス」セクションに説明を追加。

• 「コンフィギュレーションプリミティブをコアに配置」セクションに注記を追加。

• 「外部ストレージの要件」の表に UltraScale+ を追加。

• 「コアのカスタマイズおよび生成」セクションの説明を更新。

• 「配置制約」および「ピン制約」セクションに説明を追加。

• 「UltraScale SSI デバイスの制約」および「UltraScale+ SSI デバイスの制約」セクションに説明を追加。

• 「機能」セクションに説明を追加。

• 「ポートの説明」セクションの説明を更新。

• 「外部メモリプログラミングファイルの作成」セクションのコードを更新。

• 付録「評価ボードを使用した SEM Controller の動作デモ」に Zynq UltraScale+ および Virtex UltraScale+ を追加。

• 付録「エラー挿入のガイダンス」に UltraScale+ の説明を追加。

• 付録「IP デザインのチェックリスト」に説明を追加。

• 「外部メモリプログラミングファイルの作成」セクションのコードを更新。

• 付録「評価ボードを使用した SEM Controller の動作デモ」に Zynq UltraScale+ および Virtex UltraScale+ を追加。

• 付録「エラー挿入のガイダンス」に Zynq UltraScale+ および UltraScale+ の説明を追加。

• 付録「IP デザインのチェックリスト」に説明を追加。







2016 年 10 月 05 日 3.1 • 「IP の概要」の表の注記を更新。

• 「概要」の章に「暗号化と認証のサポート」セクションを追加。

• 「サポートされていない機能」セクションの説明を更新。

• 「機能」セクションを更新し、「コンフィギュレーションフレームの大数」の表に UltraScale+ デバイスを追加。

• 「大推定 FIT レート」の表の UltraScale+ デバイスを更新。

• 「大スタートアップレイテンシ (ICAP FMax の場合)」の表に UltraScale+ デバイスを追加。

• 「大 IP エラー検出時間 (ICAP FMax の場合)」の表に UltraScale+ デバイスを追加。

• 「エラー訂正レイテンシ (モニターインターフェイスでのスロットリングなし )」、「エラー分類レイテンシ (モニターインターフェイスでのスロットリングなし )」、および「LFA を使用した場合のエラー挿入レイテンシ (モニターインターフェイスでのスロットリングなし )」の表に UltraScale+ デバイスを追加。

• 「SEM Controller のポート」の図を更新。

• 「コアを使用するデザイン」の章の「初期化」セクションに説明を追加。

• 「コアを使用するデザイン」、「デザインフローの手順」、および「サンプルデザイン」の章に UltraScale+ SSI デバイスに関する説明を追加。

• monitor_rx/tx を uart_rx/tx へ変更。

• 付録「UART ログの例」を追加。

2016 年 4 月 6 日 3.1 • UltraScale+ ファミリのサポートを追加。

• 文書全体に検証 (+ テスト ) モードを追加。

• 図 2-1 「SEM Controller のポート」を更新。

• 表 3-2 「コマンドのフォーマットと使用方法」を更新。

• 「エラー検出レポート – 軽減 (+ テスト ) モード (訂正機能有効)」セクションを更新。

• 「エラー検出レポート – 検出ステート」セクションを更新。

• 「エラー検出レポート – 診断スキャン」セクションを更新。

• 表 3-5 「UART コマンドと使用方法」を更新。

• 「デザインフローの手順」の章を更新。

• 「外部メモリプログラミングファイルの作成」セクションを更新。

• 付録 A 「検証、互換性、相互運用性」の「検証」セクションを更新。

• 付録 B 「移行およびアップグレード」に UltraScale+ の説明を追加。

• 付録 C 「SPI バスタイミングバジェット」と付録 D 「評価ボードを使用した SEM Controller の動作デモ」を追加。

• 付録 F 「IP デザインのチェックリスト」に合成後の DCP に関する項目を追加。







2015 年 9 月 30 日 3.0 • 文書全体に検出および診断スキャンステートを追加。

• 「IP の概要」セクションを更新。

• 「機能概要」セクションに説明を追加。

• 「機能」セクションに検出機能の説明を追加。

• 表 2-2 「コンフィギュレーションフレームの大数」を追加。

• 表 2-5 「大スタートアップレイテンシ (ICAP FMax の場合)」を更新。

• 表 2-6 「大 IP エラー検出時間 (ICAP FMax の場合)」を更新。

• 表 2-9 「LFA を使用した場合のエラー挿入レイテンシ (モニターインターフェイスでのスロットリングなし )」を更新。

• 「その他の要因によるレイテンシ」セクションに説明を追加。

• 「リソース使用状況」セクションを更新。

• 図 2-1 「SEM Controller のポート」を更新。

• 「ステータスインターフェイス」セクションの説明を更新。

• 「一般的なデザインガイドライン」セクションに「早期の統合およびバリデーション」の説明を追加。

• 「ICAP アービトレーションインターフェイス」セクションを更新。

• 図 3-4 ～図 3-6 を更新。

• 検出および診断スキャンステートへの移行命令を追加。

• 「ハートビート」セクションの説明と図を更新。

• 「UART インターフェイス」セクションを更新。

• 「システム」セクションを更新。

• 図 4-1 ～図 4-3 の GUI を更新。

• 「ユーザーパラメーター」セクションを更新。

• 「機能」セクションを更新。

• 「コントローラーの制約」、「サンプルデザインの制約」、「SSI デバイスの制約」セクションに説明を追加。

• 「デザインフローの手順」に「統合およびバリデーション」のセクションを追加。

• 表 5-1 「デバイスの SLR 番号」を更新。

• 付録 B 「移行およびアップグレード」を更新。

• 付録 E 「エラー挿入の手引き」と付録 F 「IP デザインのチェックリスト」を追加。

• 付録 G 「デバッグ」に「PFA を使用したエラー挿入」、「デバイスへの依存性」を追加。「その他の非互換性」を削除。

2015 年 4 月 1 日 2.0 初版







お読みください: 重要な法的通知本通知に基づいて貴殿または貴社 (本通知の被通知者が個人の場合には「貴殿」、法人その他の団体の場合には「貴社」。以下同じ ) に開示される情報 (以下「本情報」といいます) は、ザイリンクスの製品を選択および使用することのためにのみ提供されます。適

用される法律が許容する大限の範囲で、 (1) 本情報は「現状有姿」、およびすべて受領者の責任で (with all faults) という状態で提

供され、ザイリンクスは、本通知をもって、明示、黙示、法定を問わず (商品性、非侵害、特定目的適合性の保証を含みますがこ

れらに限られません)、すべての保証および条件を負わない (否認する ) ものとします。また、 (2) ザイリンクスは、本情報 (貴殿ま

たは貴社による本情報の使用を含む) に関係し、起因し、関連する、いかなる種類・性質の損失または損害についても、責任を負

わない (契約上、不法行為上 (過失の場合を含む)、その他のいかなる責任の法理によるかを問わない) ものとし、当該損失または損

害には、直接、間接、特別、付随的、結果的な損失または損害 (第三者が起こした行為の結果被った、データ、利益、業務上の信

用の損失、その他あらゆる種類の損失や損害を含みます) が含まれるものとし、それは、たとえ当該損害や損失が合理的に予見可

能であったり、ザイリンクスがそれらの可能性について助言を受けていた場合であったとしても同様です。ザイリンクスは、本情

報に含まれるいかなる誤りも訂正する義務を負わず、本情報または製品仕様のアップデートを貴殿または貴社に知らせる義務も負

いません。事前の書面による同意のない限り、貴殿または貴社は本情報を再生産、変更、頒布、または公に展示してはなりませ

ん。一定の製品は、ザイリンクスの限定的保証の諸条件に従うこととなるので、 https://japan.xilinx.com/legal.htm#tos で見られるザ

イリンクスの販売条件を参照してください。 IP コアは、ザイリンクスが貴殿または貴社に付与したライセンスに含まれる保証と補

助的条件に従うことになります。ザイリンクスの製品は、フェイルセーフとして、または、フェイルセーフの動作を要求するアプ

リケーションに使用するために、設計されたり意図されたりしていません。そのような重大なアプリケーションにザイリンクスの

製品を使用する場合のリスクと責任は、貴殿または貴社が単独で負うものです。 https://japan.xilinx.com/legal.htm#tos で見られるザ

イリンクスの販売条件を参照してください。

自動車用のアプリケーションの免責条項

オートモーティブ製品 (製品番号に「XA」が含まれる ) は、 ISO 26262 自動車用機能安全規格に従った安全コンセプトまたは余剰性

の機能 ( 「セーフティ設計」 ) がない限り、エアバッグの展開における使用または車両の制御に影響するアプリケーション ( 「セー

フティアプリケーション」 ) における使用は保証されていません。顧客は、製品を組み込むすべてのシステムについて、その使用

前または提供前に安全を目的として十分なテストを行うものとします。セーフティ設計なしにセーフティアプリケーションで製品

を使用するリスクはすべて顧客が負い、製品の責任の制限を規定する適用法令および規則にのみ従うものとします。

© Copyright 2015-2019 Xilinx, Inc. Xilinx、 Xilinx のロゴ、 Alveo、 Artix、 Kintex、 Spartan、 Versal、 Virtex、 Vivado、 Zynq、およびこの

文書に含まれるその他の指定されたブランドは、米国およびその他各国のザイリンクス社の商標です。すべてのその他の商標は、

それぞれの保有者に帰属します。

この資料に関するフィードバックおよびリンクなどの問題につきましては、 [email protected] まで、または各ページ

の右下にある [フィードバック送信] ボタンをクリックすると表示されるフォームからお知らせください。フィードバックは日本語

で入力可能です。いただきましたご意見を参考に早急に対応させていただきます。なお、このメールアドレスへのお問い合わせは

受け付けておりません。あらかじめご了承ください。


https://japan.xilinx.com/legal.htm#tos

https://japan.xilinx.com/legal.htm#tos

mailto:[email protected]


ultrascale architecture soft error mitigation …ultrascale architecture sem controller v3.1 6 pg187...

Documents