Intel Stratix 10 高性能デザイン・ハンドブック...このドキュメントの章では、 HyperFlex FPGAアーキテクチャーを素早く使用するために特定のデザイ

Intel® Stratix® 10 高性能デザイン・ハンドブック

更新情報フィードバック

S10HPHB | 2017.05.08

新版をウェブからダウンロード: PDF | HTML

https://www.altera.com/bin/rssdoc?name=jbr1444752564689

mailto:[email protected]?subject=%20Intel%20Stratix%2010%E9%AB%98%E6%80%A7%E8%83%BD%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%BB%E3%83%8F%E3%83%B3%E3%83%89%E3%83%96%E3%83%83%E3%82%AF%20(S10HPHB%202017.05.08)%20%E3%83%95%E3%82%A3%E3%83%BC%E3%83%89%E3%83%90%E3%83%83%E3%82%AF%E3%83%BB%E3%82%AA%E3%83%B3&body=%E5%BC%8A%E7%A4%BE%E3%81%AF%E5%BE%A1%E7%A4%BE%E3%81%AE%E3%83%95%E3%82%A3%E3%83%BC%E3%83%89%E3%83%90%E3%83%83%E3%82%AF%E3%81%AB%E6%84%9F%E8%AC%9D%E3%81%84%E3%81%9F%E3%81%97%E3%81%BE%E3%81%99%E3%80%82%E3%82%B3%E3%83%A1%E3%83%B3%E3%83%88%E3%81%AE%E4%B8%AD%E3%81%A7%E3%80%81%E3%83%9A%E3%83%BC%E3%82%B8%E7%95%AA%E5%8F%B7%E3%81%BE%E3%81%9F%E3%81%AF%E6%AE%B5%E8%90%BD%E3%82%92%E6%8C%87%E5%AE%9A%E3%81%97%E3%81%A6%E3%81%8F%E3%81%A0%E3%81%95%E3%81%84%E3%80%82%E3%81%82%E3%82%8A%E3%81%8C%E3%81%A8%E3%81%86%E3%81%94%E3%81%96%E3%81%84%E3%81%BE%E3%81%99%E3%80%82

https://www.altera.com/ja_JP/pdfs/literature/hb/stratix-10/s10_hp_hb_j.pdf

https://www.altera.com/content/altera-www/global/ja_jp/index/documentation/jbr1444752564689.html

目次

1 Intel® HyperFlex FPGA アーキテクチャーの概要...................................................................... 41.1 Stratix 10 基本的なデザインコンセプト...........................................................................5

2 RTL デザイン・ガイドライン....................................................................................................... 62.1 高速デザイン手法...................................................................................................... 6

2.1.1 高速ターゲットを設定する.................................................................................62.1.2 実験と反復.................................................................................................. 82.1.3 独自にコンポーネントをコンパイルする................................................................. 82.1.4 サブモジュールの適化...................................................................................92.1.5 ブロードキャスト信号を避ける............................................................................9

2.2 Hyper-Retiming（レジスター移動を容易にする）................................................................112.2.1 リセット戦略...............................................................................................122.2.2 クロックイネーブルの戦略............................................................................... 172.2.3 合成属性................................................................................................... 182.2.4 タイミングの検討事項....................................................................................182.2.5 クロック同期の戦略...................................................................................... 192.2.6 メタステーブル・シンクロナイザ.........................................................................212.2.7 初期のパワーアップ条件.................................................................................21

2.3 Hyper-Pipelining（パイプライン・レジスターの追加）........................................................... 252.3.1 従来のパイプライン化と Hyper-Pipelining 処理の比較............................................ 262.3.2 パイプライニングとレイテンシー........................................................................272.3.3 マルチサイクル例外の代わりにレジスターの使用.................................................... 27

2.4 Hyper-Optimization （RTL の適化）...........................................................................282.4.1 一般的な適化手法..................................................................................... 282.4.2 特定のデザイン構造の適化........................................................................... 35

3 Stratix 10 デザインのコンパイル........................................................................................... 533.1 Hyper-Aware のデザインフローの実行...........................................................................54

3.1.1 ステップ 1：レジスターのリタイミングを実行する.....................................................563.1.2 ステップ 2：リタイミング結果を確認する...............................................................583.1.3 ステップ 3：Fast Forward コンパイルと Hyper-Retiming の実行............................... 603.1.4 ステップ 4：Hyper-Retiming の結果を確認する.....................................................623.1.5 ステップ 5：Fast Forward 推薦を実装する........................................................... 65

4 HyperFlex の移植のガイドライン............................................................................................884.1 デザインの移行とパフォーマンスの調査........................................................................... 88

4.1.1 Verilog HDL モジュールのブラックボックス化.......................................................894.1.2 VHDL モジュールのブラックボックス化............................................................... 894.1.3 クロック管理...............................................................................................914.1.4 ピン･アサインメント......................................................................................914.1.5 トランシーバー・コントロール・ロジック................................................................ 924.1.6 期限の切れた IP コアのアップグレード................................................................ 93

4.2 トップレベル・デザインの考慮事項..................................................................................93

目次

Intel® Stratix® 10 高性能デザイン・ハンドブック2

5 デザイン例ウォークスルー.......................................................................................................955.1 メジアンフィルタのデザイン例...................................................................................... 95

5.1.1 ステップ 1：プロジェクトを設定する.................................................................... 965.1.2 ステップ 2：Fast Forward コンパイルを実行する....................................................975.1.3 ステップ 3：Fast Forward 推奨を表示する........................................................... 975.1.4 ステップ 4：Fast Forward 推奨を実装する........................................................... 97

6 適化の例...................................................................................................................... 1046.1 ラウンド・ロビン・スケジューラ.....................................................................................104

7 付録...............................................................................................................................1107.1 付録 A：パラメーター化可能パイプライン・モジュール..........................................................1117.2 付録 B：クロックの有効化とリセット.............................................................................. 113

7.2.1 同期リセットと制限..................................................................................... 1137.2.2 クロックイネーブルを使用したリタイミング......................................................... 1177.2.3 ショートパスの解決.................................................................................... 121

8 改訂履歴......................................................................................................................... 123

目次


1 Intel® HyperFlex FPGA アーキテクチャーの概要

このドキュメントでは、 Intel® HyperFlex™ FPGA アーキテクチャーで大のパフォーマンスを達成するためのデザイン手法について説明します。このアーキテクチャーは、 Intel Stratix® 10 デバイスに新しい Hyper-Retiming、Hyper-Pipelining、および Hyper-Optimization のデザイン手法をサポートします。

「Registers everywhere」は、 HyperFlex FPGA アーキテクチャーの重要な革新です。 Stratix 10デバイスはすべての機能ブロック入力でデバイスコアのあらゆるルーティング・セグメントにバイパス可能な Hyper-Register をパックします。

図 -1: Registers Everywhere

ALM ALM ALM

ALM ALM ALM

ALM ALM ALM

Registers at Block Inputs

Registers in Routing

Stratix 10 バイパス可能な Hyper-Register により、ルーティング信号はレジスターを初に通過するか、レジスターをマルチプレクサに直接バイパスすることができます。 FPGA コンフィグレーション・メモリ（CRAM）の 1 ビットはこのマルチプレクサを制御します。

図 -2: バイパス可能な Hyper-Register

clk CRAMConfig

S10HPHB | 2017.05.08

Intel Corporation.無断での引用、転載を禁じます。Intel、インテル、Intel ロゴ、Altera、ARRIA、CYCLONE、ENPIRION、MAX、NIOS、QUARTUS および STRATIX の名称およびロゴは、アメリカ合衆国および/ またはその他の国における Intel Corporationの商標です。インテルは FPGA 製品および半導体製品の性能がインテルの標準保証に準拠することを保証しますが、インテル製品およびサービスは、予告なく変更される場合があります。インテルが書面にて明示的に同意する場合を除き、インテルはここに記載されたアプリケーション、または、いかなる情報、製品、またはサービスの使用によって生じるいっさいの責任を負いません。インテル製品の顧客は、製品またはサービスを購入する前、および、公開済みの情報を信頼する前には、デバイスの仕様を新のバージョンにしておくことをお勧めします。*その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

ISO9001:2008登録済

http://www.altera.com/support/devices/reliability/certifications/rel-certifications.html



このドキュメントの章では、 HyperFlex FPGA アーキテクチャーを素早く使用するために特定のデザイン・ガイドライン、ツールフロー、および実際の例を示します。

• RTL Design Guidelines— Stratix 10 デザインのための基本的な高性能 RTL デザイン手法を提供します。

• Compiling Stratix 10 Designs— Stratix 10 デバイスで高のパフォーマンスを得るためにIntel Quartus® Prime Pro v17.1 Stratix 10 ES エディションを使用する方法について説明しています。

• HyperFlex Porting Guidelines— Stratix 10 デバイスへのデザイン移行のガイダンスを提供します。

• Design Example Walk-Through, Optimization Example, Appendices —実際のデザイン・サンプルを使用したパフォーマンス改善手法を示しています。

1.1 Stratix 10 基本的なデザインコンセプト

表 1. 用語集

ターム/フレーズ説明

クリティカル・チェインレジスターのリタイミングを防止するデザイン条件はすべてクリティカル・チェインです。制限要因には、チェイン内に複数のレジスター間パスが含まれる場合があります。クリティカル・チェインとそれに関連するクロックドメインの fMAX は、レジスター間パスの平均遅延およびルーティング・ワイヤなどの不可分な回路エレメントの量子化遅延によって制限されます。Fast Forward コンパイルはクリティカル・チェインを破ります。

Fast Forward のコンパイルデザイン固有のタイミング収束の推奨事項を生成し、各タイミング制約を削除した後に将来のパフォーマンス結果を生成します。

ハイパー・アウェア・デザイン・フロー Hyper-Retiming、Hyper-Pipelining、Fast Forward Compilation、および Hyper-Optimization を介して Stratix 10 デバイスで高のパフォーマンスを実現するデザインフローです。

HyperFlex FPGA アーキテクチャーコアファブリック全体のあらゆる位置に Hyper-Register と呼ばれる追加のレジスターを含む Stratix 10 デバイスのコアアーキテクチャーをサポートします。Hyper-Register は帯域幅を増やし、面積と電力効率を向上させます。

Hyper-Optimization ロング・コンビネーション・フィードバックパスではなく、機能的に同等のフィードフォワードまたはプリー・コンピュート・パスを使用するようにロジックを再構築するなどのFast Forward コンパイルで推奨される主要な RTL 変更を介したデザイン・パフォーマンスを向上させるデザインプロセスです。

Hyper-Pipelining ALM レジスター間の相互接続にパイプライン・ステージを追加することにより、長い配線遅延を排除したデザインプロセスです。この技術により、より高速なクロック周波数でデザインを実行することができます。

Hyper-Retiming Fast Forward コンパイル時に、Hyper-Retiming はレジスターから信号を投機的に取り除き、リタイミング用ネットリストのモビリティを可能にします。

Multi-Corner Timing Analysis デザインの電圧、プロセス、温度の動作条件を検証するための複数の「タイミング・コーナー・ケース」の分析です。高速コーナー解析は、良のタイミング条件を前提としています。

関連情報• 11 ページの Hyper-Retiming（レジスター移動を容易にする）

• 25 ページの Hyper-Pipelining（パイプライン・レジスターの追加）

• 28 ページの Hyper-Optimization （RTL の適化）

1 Intel® HyperFlex FPGA アーキテクチャーの概要S10HPHB | 2017.05.08


2 RTL デザイン・ガイドライン

この章では、 Stratix 10 デバイスで高のクロックレートを達成するための RTL デザイン手法について説明します。 Stratix 10 アーキテクチャーは、従来の FPGA 世代よりも大幅に高い高クロックレートをサポートします。

2.1 高速デザイン手法

Stratix 10 アーキテクチャーへデザインを移行することにより、も効果的で機能を維持するために、高速デザインのベスト・プラクティスを実装する必要があります。 Stratix 10 の高速デザイン手法は、追加のパイプライン・ステージをサポートし、性能制限ループを回避するレイテンシーに敏感なデザインを生成します。次の高速デザインのベスト・プラクティスから、 Stratix 10 ザインにとって大の利益が生成されます。

• 高速ターゲットの設定

• 実験と反復

• デザイン・コンポーネントの個別コンパイルデザイン

• サブモジュールの適化

• ブロードキャスト信号の回避

以下のセクションでは、 Quartus Prime ソフトウェアで Hyper-Retiming、Hyper-Pipelining、Hyper-Optimization をイネーブルする特定の RTL デザインテクニックについて説明します。

2.1.1 高速ターゲットを設定する

シリコンの効率を上げるには、スピード目標を可能な限り高く設定します。 Stratix 10 LUT は本質的に、毎秒 10 億回のルックアップが可能な小さな ROM です。 Stratix 10 156MHz で LUT を動作することは、容量の 15％しか使用しません。

高速ターゲットを設定するときは、タイミングを閉じることができるスピードと必要な実際のシステムスピードの間の快適なガードバンドも維持する必要があります。初にマージンを使用してタイミング収束を扱う方がはるかに簡単です。

2.1.1.1 速度とタイミング収束

実際の回路性能がデザインの fMAX の要件よりも低い場合、タイミングを閉じることができません。ターゲット FPGA デバイスがロジック配置に使用可能なリソースが多数ある場合、タイミング収束が簡単で、処理時間も少なります。

低速回路のタイミング収束は、通常、高速回路のタイミング収束よりも本質的に容易ではありません。なぜなら、遅い回路は通常、レジスター間でより多くの組合せロジックを含むからです。パス上に多数のノードがある場合、Fitter はノードを互いに離して配置する必要があり、その結果、ルーティング遅延が大きくなります。対照的に、パイプラインの多い回路は配置に依存することが少なく、タイミング収束が簡単になります。

S10HPHB | 2017.05.08






図 -3: 許容されるルーティング遅延

Acceptable Slow SlowGood

デザインを作成する際に現実的なタイミングマージンを使用します。ロジックがシステムに追加されると、デザインの一部が接触して歪みます。システムにストレスを加えることは、通常、速度に有害であります。デザインプロセスの開始時にタイミングマージンを増加することで、この問題を軽減できます。

2.1.1.2 スピードとレイテンシー

高いクロックレートで FPGA を実行すると、同じリソースでより多くの作業が可能になります。次の表は、バス幅の増加による各種回路の成長率を示しています。回路機能は、バス幅の関数としてエリアのビッグオー記法で、準線形である log（N）から、超線形である N * N まで、インターリーブします。

表 2. バス幅がエリアに及ぼす影響

回路機能

バス幅ログ N マルチプレクサリップル加算 N * log N バレル・シフタクロスバー N * N

16 4 5 16 64 64 80 256

32 5 11 32 160 160 352 1024

64 6 21 64 384 384 1344 4096

128 7 43 128 896 896 5504 16384

256 8 85 256 2048 2048 21760 65536

通常、回路部品はバス幅が 2 倍になると 2 倍以上の面積を使用します。マルチプレクサのような単純な回路の場合、バス幅が増加するにつれて、エリアは部分的に直線的に増加します。マルチプレクサのバス幅を半分にすると、リニアエリアのメリットがわずかに低下します。リップル加算器は、バス幅が増加すると直線的に増加します。

バレルシフタやクロスバーなどのより複雑な回路は、バス幅が増加するにつれて超直線的に成長します。バレルシフタ、クロスバー、またはその他の複雑な回路のバス幅を半分にカットすると、エリアのメリットは半分よりも大幅に改善され、二次的な速度に近づきます。すべての入力がすべての出力に影響を及ぼすコンポーネントの場合、バス幅を大きくすると二次的な成長が起こる可能性があります。そのため、ハーフ幅のバスで作業するスピードアップを利用すると、元のエリアの半分以下のデザインが生成されることが期待されます。

ストリーミング・データパスを扱う場合、レジスターの数はパイプラインのレイテンシーをビット単位で公平に近似したものです。幅を半分にすると、レイテンシーに悪影響を与えずにパイプライン・ステージの数を 2 倍にすることができます。一般に、より速く進むために必要な追加のレジスターの量は、2 倍より大幅に少なく、レイテンシーの性能を生み出します。

2 RTL デザイン・ガイドラインS10HPHB | 2017.05.08


2.1.2 実験と反復

デザインのパフォーマンスが初にパフォーマンス要件を満たしていない場合、設定とデザインの変更を試してみてください。 Intel FPGA の再プログラム機能は、目標を達成するまで実験を可能にします。一般に、技術要求が時間の経過と共に増加するにつれて、デザイン性能は徐々に不十分になります。例えば、既存のデザインエレメントを新しいコンテキストに適用すると、速度のパフォーマンスは低下する可能性があります。

回路のタイミングを実験するとき、一時的に回路を破壊してデータポイントを収集するという実験による恒久的なリスクはありません。不正な位置にレジスターを追加して、全体的なタイミングへの影響を判断します。予定されている回路がタイミング目標を満たしている場合、配置を合法化するためにさらに投資を行うことができます。

レジスターが自由に挿入されていても、回路が遅すぎる場合、デザインのより基本的な要素を再考してください。地域にスピードグレードを上下にすること、または LogicLock® Plus 領域の回路を圧縮することにより、スピードの調査に役立ちます。

2.1.3 独自にコンポーネントをコンパイルする

スタンド・アロン・エンティティとしてデザイン・サブコンポーネントをコンパイルして、パフォーマンスのボトルネックを迅速に特定して適化します。リソースと物理的制約（例えば、ピン配置）の競争は、全体的なデザイン・パフォーマンスを低下させます。

コンポーネントがより高いレベルに組み込まれたとき、ブロック速度は同じ可能性があります。しかし、ほかのコンポーネントと一緒の時に、独立していた時と比較して、スピードが速くなることは決してありません。安全のマージンとして、必要なコンポーネントの速度に対する明確なルールを確立します。例えば、20％のタイミングマージンを目標とする場合、19.5％のマージンを持つコンポーネントは失敗です。コンテキスト・マージンの目標はコンテキストに基づいています。例えば、チップの半分を代表するハイ・レベル・コンポーネントのタイミングマージンを 10％にすることができます。ただし、ルールが明示的でない場合、マージンの 10％は 9％に、次に 6％などに低下します。

Chip Planner を使用して、システムレベルのビューを視覚化します。次のフロアプランでは、デバイスのロジックの 5％（中央オレンジ）と M20K ブロックの 25％（赤いストライプ）を使用するコンポーネントを示します。



図 -4: チッププランナーの M20K スプレッド

システム・レベル・ビューには、リソースの比率に関する警告は表示されません。しかし、重要なルーティング輻輳が明らかです。オレンジ色のメモリーコントロール・ロジックは、大きな物理スパンにわたってファンアウトし、すべてのメモリーブロックに接続します。デザインはうまく機能しますが、無関係のロジックセルが介在領域を占有するときに苦労します。このブロックを再構成して、コントロール・ロジックを物理的に分散させると、より高度な問題が改善されます。

個々のモジュールのコンパイルにより、後続のハードウェア・デバッグ・サイクルの準備が整います。デザインの部分の独立した、一貫した動作は有益です。この条件では、システム全体の実行時間と複雑さがなく、それらのセクションのみのテストと変更が可能です。

2.1.4 サブモジュールの適化

デザインの適化中に、1 つまたは 2 つのサブモジュールのクリティカルな部分を大きなデザインから分離し、サブモジュールをコンパイルすることができます。デザインの一部をコンパイルすることでコンパイル時間が短縮され、クリティカルな部分の適化に集中できます。

2.1.5 ブロードキャスト信号を避ける

可能な限りブロードキャスト信号を使用しないでください。ブロードキャスト信号は、高いファンアウト制御ネットであり、パス間のレイテンシー差が大きくなります。パス・レイテンシーの差異は、レジスターの適切な位置を見つける Compiler の能力を複雑にし、その結果、不均衡な遅延パスが発生します。パイプラインを使用してこの問題に対処し、レジスターを複製してブロードキャスト信号を駆動します。

ブロードキャスト信号は、個々のレジスターに到達するために大きな距離を移動します。これらのファンアウト・レジスターはフロアプランに広がっている可能性があるため、手動レジスターの複製を使用して配置を改善してください。パイプライン・ステージの正しい配置は、パフォーマンスに大きな影響を与えます。



図 -5: ブロードキャスト信号の準適パイプライニング黄色いボックスは、タイミングを助けるためにモジュールに挿入されたレジスターを強調表示します。このブロックは、出力を複数のトランシーバ・チャネルにブロードキャストします。これらの余分なレジスターは、終レジスターステージがデバイスの広範囲の宛先にファンアウトするため、タイミングを十分に改善できないことがあります。

D Q

Channel 0

D Q

Channel 1

D Q

Channel n

D Q D Q D Q

パイプライン化のより良いアプローチは、後のパイプライン・レジスターを複製し、レジスターのコピーを宛先モジュール（この例ではトランシーバ・チャネル）に配置することです。この方法はより良い配置とタイミングをもたらします。各チャネルのパイプライン・レジスターの配置が、必要に応じて黄色のモジュールの後のレジスターステージとトランシーバのレジスター間の距離をカバーするのに役立つため、この改善が生じます。

後のパイプライン・レジスターを複製するだけでなく、 dont_merge合成属性を適用して、合成中に重複レジスターをマージすることを回避します。Compiler はパイプライン・ステージを自動的に追加し、可能であればレジスターを Hyper-Register に移動します。手動パイプライニングを使用して、より良い配置結果を実現することもできます。

図 -6: ブロードキャスト信号の適なパイプライン化

D Q

Channel 0

D Q

Channel 1

D Q

Channel n

D Q

D Q D Q D Q

D Q



2.2 Hyper-Retiming（レジスター移動を容易にする）

Fitter の Retime ステージでは、ALM レジスターをルーティング・ファブリック内の Hyper-Registerにリタイミング（移動）することにより、レジスターチェインのバランスをとることができます。また、Retime ステージでは、レジスターを組み合わせロジック全体で前後に移動させることでシーケンシャルな適化を実行します。一連のレジスター内の各ステージ間の伝搬遅延を平衡させることにより、リタイミング・プロセスはクリティカル・パスを短くし、クロック周期を短くし、動作周波数を増加させます。

その後、レジスターを理想的な Hyper-Register 位置に移動するために、Retime ステージが Fitter 処理中に自動的に実行されます。従来の高性能 FPGA と比較して、この Hyper-Retiming プロセスでは小限の労力しか必要とせず、 Stratix 10 で結果として 1.1〜1.3 倍のパフォーマンスが得られます。

図 -7: LUT 間のレジスターの移動リタイミングの前に左にレジスターを設定し、悪の場合は 2 つの LUT を遅延します。 1 つの LUT の悪の場合の遅延で、リタイミング後に右にレジスターします。

LUT

LUT

LUT

LUT

LUT

LUT

LUT

LUT

LUT

LUT

LUT

LUT

BackwardRetiming

ForwardRetiming

Compiler がレジスターをリタイムすることができない場合、これはリタイミング制約です。このような制限により、デザインの fMAX が制限されます。パフォーマンスを重視するデザインのリタイミング制約を小限に抑えて、高のパフォーマンスを実現します。

パフォーマンスを制限するさまざまなデザイン条件があります。制限は、ハードウェアの特性、ソフトウェアの動作、またはデザインの特性に関連する可能性があります。レジスターのリタイミングを容易にし、リタイミングの制限を回避するには、次のデザイン手法を使用します。

• 必要な場合を除いて非同期リセットは回避します。「リセット戦略」のセクションを参照してください。

• 同期クリアを回避します。同期クリアは通常、リタイミングには役立たないブロードキャスト信号です。

• タイミングの制約と例外で、ターゲットとなるワイルドカードまたは名前を使用します。「タイミング制約の考慮事項」のセクションを参照してください。

• シングルサイクル（停止/開始）フロー制御は回避します。例として、クロックイネーブルと FIFO フル/エンプティー信号があります。有効信号とオールモスト・フル/エンプティーを使用することを検討してください。



• Preserve レジスター属性を使用しないでください。「リタイミングの制限と回避策」のセクションを参照してください。

• パイプライン・レジスターの追加については、 Hyper-Pipelining（パイプライン・レジスターを追加）セクションを参照してください。

• リタイミングのためのループのアドレス指定や他の RTL 制限については、「 Hyper-Optimization（RTL の適化）」セクションを参照してください。

以下のセクションでは、特定のデザイン環境におけるレジスターの移動を容易にするためのデザイン手法について説明します。

関連情報• 12 ページのリセット戦略

• 18 ページのタイミングの検討事項


• 85 ページのリタイミングの制限と対処方法

2.2.1 リセット戦略

このセクションでは、リセットで大のパフォーマンスを達成するための手法を推奨します。高のパフォーマンスを得るには、必要な場合を除き、リセット（非同期および同期）を回避してください。Hyper-Register には非同期クリアがないので、非同期クリアを持つレジスターを Hyper-Register 位置に移動することはできません。

非同期クリアの代わりに同期クリアを使用すると、レジスターをリタイミングすることができます。同期クリアを持つレジスターのリタイミング動作の詳細については、「同期リセットと制限」のセクションを参照してください。デザイン内の一部のレジスターでは、同期クリアまたは非同期クリアが必要ですが、パフォーマンスを適化するにはその数を小限に抑える必要があります。

関連情報113 ページの同期リセットと制限

2.2.1.1 非同期クリアの削除

リセットが長く保持され、フル・リセットと同等の定常状態と同様になり、回路が自然とリセットされるのであれば、非同期クリアを削除します。



図 -8: Verilog HDL および VHDL 非同期クリアの例

always @(posedge clk, aclr) if (aclr) begin reset_synch <= 1'b0; aclr_int <= 1’b0; end else begin reset_synch <= 1'b1; aclr_int <= reset_synch; end

always @(posedge clk, aclr_int) if (aclr_int) begin a <= 1'b0; b <= 1'b0; c <= 1'b0; d <= 1'b0; out <= 1'b0; end else begin a <= in; b <= a; c <= b; d <= c; out <= d; end

PROCESS(clk, aclr) BEGIN IF (aclr = '1') THEN reset_synch <= '0'; aclr_int <= '0'; ELSIF rising_edge(clk) THEN reset_synch <= '1'; aclr_int <= reset_synch; END IF;END PROCESS;

PROCESS(clk, aclr_int) BEGIN IF (aclr_int = '1') THEN a <= '0'; b <= '0'; c <= '0'; d <= '0'; output <= '0'; ELSIF rising_edge(clk) THEN a <= input; b <= a; c <= b; d <= c; output <= d; END IF;END PROCESS;

Verilog HDL VHDL

Asynchronous clear clears all registers in the pipeline.They cannot be placed in Hyper-Registers.

図 -9: フル非同期リセットを使用する回路次の図は、非同期クリアの例と同じロジックを回路図形式で示しています。

X0

X0

X0

X0

X0Reset

1Feeds ACLR

Reset



図 -10: 部分非同期リセット部分リセットの後、修正された回路が元の回路と同じ定常状態に落ち着く場合、修正は機能的に同等です。次の図は、回路の中央からの非同期クリアの削除を示しています。

X

0

X

X

X

X

X

X

X

0Reset

Feeds ACLRReset

Add Enough Stages

Feeds SCLR or ACLR

00

00

X0

XX

00

0 0 0 0 0

1

図 -11: レジスターチェイン内のインバータを備えた回路反転ロジックを含む回路では、通常、次の図に示すように、パイプラインに追加の同期クリアが必要です。

1

0

0

1

1

1

0

1

0

0

X0

X0

X0

X0

X0Reset

Feeds ACLRReset

1

Inverter

Operation



図 -12: 非同期クリア付きレジスターチェイン内のインバータ回路リセットを解除してクロックを印加した後、レジスター出力はリセット状態に落ち着きません。反転レジスターは、リセット解除後に上記の回路と等価になるように非同期クリアを削除することはできません。

X

0

X

X

X

X

X

X

X

0Reset

Feeds ACLRReset

Add Enough Stages

Feeds SCLR or ACLR

00

00

X1

XX

00

0 0 1 1 0

1

1 0 1 1 10 1 1 1 1

OperationSteady State Is Not Correct

This Register Requiredto Keep Its Clear

図 -13: リセットと同期するための出力の検証反転機能による不適切なリセットロジックを回避するには、リセット解除と同期するように出力を検証します。次に、検証パイプラインが計算パイプラインの有効なときに出力を有効にできる場合、その動作はリセット解除と同等です。このプロセスは、回路の計算部分が自然にリセットされない場合であっても適切です。

Feeds ACLRreset

Add Enough Stages

Feeds SCLR or ACLR

1

valid

次の図は、ページ 14 の Verilog HDL および VHDL の例を示しています。この例をデザインに適用して、不要な非同期リセットを削除してください。



図 -14: ゼロまたは低限の非同期クリアを使用した Verilog HDL の例次の図は、ページ 14 の Verilog HDL および VHDL の例を示しています。この例をデザインに適用して、不要な非同期リセットを削除してください。

always @(posedge clk, posedge aclr) if (aclr) begin reset_synch_1 <= 1'b0; reset_synch_2 <= 1'b0; aclr_int <= 1'b0; end else begin reset_synch_1 <= 1'b1; reset_synch_2 <= reset_synch_1; aclr_int <= reset_synch_2; end

always @(posedge clk, posedge aclr_int) if (aclr_int) out <= 1'b0; else out <= d; always @(posedge clk) if (reset_synch_2) a <= 1'b0; else a <= in; always @(posedge clk) begin b <= a; c <= b; d <= c;end

Verilog HDL

Asynchronous Clear forOutput Register Only

Synchronous Clear forInput Register Only

Naturally Resetting Registers

図 -15: ゼロまたは低限の非同期クリアを使用する VHDL の例

PROCESS (clk, aclr) BEGIN IF (aclr = '1') THEN reset_synch_1 <= '0'; reset_synch_2 <= '0'; aclr_int <= '0'; ELSIF rising_edge(clk) THEN reset_synch_1 <= '1'; reset_synch_2 <= reset_synch_1; aclr_int <= reset_synch_2; END IF;END PROCESS;

PROCESS (clk, aclr_int) BEGIN IF (aclr_int = '1') THEN output <= '0'; ELSIF rising_edge(clk) THEN output <= d; END IF;END PROCESS;

Asynchronous Clear forOutput Register Only

Synchronous Clear forInput Register Only

Naturally Resetting Registers

PROCESS (clk) BEGIN IF rising_edge(clk) THEN IF (reset_synch_2 = '1') THEN a <= '0'; ELSE a <= input; END IF; END IF;END PROCESS;

PROCESS (clk) BEGIN IF rising_edge(clk) THEN b <= a; c <= b; d <= c; END IF;END PROCESS;



2.2.1.2 グローバル・クロック・ツリーでの同期クリア

グローバル・クロック・ツリーを使用して同期クリアを配信すると、リタイミング性能が向上する可能性があります。グローバル・クロック・ツリーには Hyper-Register はありません。そのため、ルーティング・ファブリックと比較して、グローバル・クロック・ツリーを介してファンアウトするレジスターをリタイミングする柔軟性は低くなります。

2.2.1.3 I/O ポートの同期リセット

Compiler は、出力ポートを駆動するレジスターまたは入力ポートによって駆動されるレジスターをリタイムしません。同期クリアがこれらの I/O レジスターの 1 つにある場合、レジスターをリタイムすることはできません。この制限は、リセットをドライブするロジックを含む実用的なデザインの典型ではありません。しかし、この問題は、I/O ポートからのリセットが発生する可能性のある、より小さなロジックのベンチマークで明らかになります。この場合、リセットが駆動するレジスターのいずれもリタイムすることはできません。同期リセットパスにいくつかのレジスターを追加すると、この状態が修正されます。

2.2.1.4 重複およびパイプライン同期リセット

同期クリア信号がタイミングの問題を引き起こす場合、ソースとデスティネーションのレジスター間で同期クリア信号を複製すると、タイミングの問題を解決できます。フォワードされたレジスターは、プッシュバックされたレジスターのように Hyper-Register の位置を主張する必要はありません。デザインの小さなロジックブロックの場合、この方法はタイミングを改善する有効な戦略です。

2.2.2 クロックイネーブルの戦略

高いファンアウト・クロック・イネーブル信号は、リタイミングによって達成可能な性能を制限する可能性があります。このセクションでは、クロックイネーブルを適切に使用するための推奨事項を示します。

2.2.2.1 ローカライズされたクロック・イネーブル

ローカライズされたクロックイネーブルには小さなファンアウトがあります。ローカライズされたクロックイネーブルは、多くの場合、クロックされたプロセスまたは ALWAYS ブロックで発生します。このような場合、信号の動作は、条件 caseまたは ifステートメントの特定の分岐の下では定義されません。その結果、信号は前の値を保持します。これがクロックイネーブルです。

デザインにクロックイネーブルが設定されているかどうかを確認するには、Fitter Report > PlanStage > Control Signals Compilation レポートを表示し、Usage 列を確認します。ローカライズされたクロックイネーブルにはファンアウトが小さいため、リタイミングは簡単で、通常はタイミングの問題は発生しません。

2.2.2.2 高ファンアウト・クロック・イネーブル

可能な限り、ファンアウト信号を回避してください。高ファンアウト・クロック・イネーブルは、大量のロジックを供給します。ロジックの量が非常に多いため、リタイミングするレジスターは、レジスターを特定のニーズに合わせてクロック・イネーブル・パスの上下にプッシュまたはプルします。このプッシュおよびプルは、クロック・イネーブル・ラインに沿って競合を引き起こす可能性があります。この状態は、「同期リセットの概要」セクションの積極的なリタイミングに似ています。イネーブルロジックを複製するなどのそのセクションで説明した方法の一部は、クロック・イネーブル・ラインに沿った競合の解決にも役立ちます。



通常、これらの高ファンアウト信号を使用して、大量のロジックが動作しないようにします。これらの信号は、FIFO のフル・フラグがハイになると発生する可能性があります。多くの場合、これらの信号の周りにデザインすることができます。例えば、FIFO のオルモスト・フル数クロックサイクル前に指定するようにデザインし、クロック・イネーブルを吸うクロック間有効にし、ディセーブルするロジックに伝搬させることができます。必要に応じてこれらの余分なレジスターをロジックでリタイムすることができます。

関連情報116 ページの同期リセットのサマリ

2.2.2.3 タイミング例外を使用したクロックイネーブル

Compiler は、マルチサイクルまたはフォールス・パス・タイミング例外のエンドポイントであるレジスターをリタイムすることはできません。クロックイネーブルは、メインクロックのレートの半分または四分の一で動作するサブドメインを作成するために使用されることがあります。場合によっては、これらのクロックによって、1 サイクルおきに変化するロジックを持つ単一パスを制御することができます。通常、タイミング例外を使用してタイミングを緩和するため、このケースはあまり問題になりません。クロックイネーブルが長いデータパスと遅いデータパスを検証し、パスがまだタイミングを満たしていない場合、レジスターステージをデータパスに追加します。パス上のマルチサイクル・タイミング制約を削除します。Hyper-Aware CAD フローにより、Retimer はタイミングを改善するためにパスをリタイミングできます。

2.2.3 合成属性

デザインには、 preserveや dont_touchなどの合成属性を持つレジスターが含まれている場合があります。Compiler は、適化を妨げる指令を尊重するため、 preserveまたは dont_touch属性を持つレジスターをリタイムしません。ディレクティブを削除し、Compiler が影響を受けるレジスターをリタイムできるようにするかどうかを検討してください。デバッグでの観測性を得るためにレジスターを保持するには、 preserve属性を保持します。レジスターの複製を管理するためにレジスターを保持する場合、代わりに dont_mergeを使用します。

関連情報58 ページの合成中にレジスターを保持する

Quartus Prime Synthesis Preserve オプションに関する詳細情報を提供します。

2.2.4 タイミングの検討事項

タイミング制約を使用すると、コンパイル結果に影響します。タイミング制約は、Fitter がロジックをどのように配置するかに影響します。このセクションでは、デザインのパフォーマンスを大化するタイミング制約手法について説明します。

2.2.4.1 マルチサイクル･パスの適化

Compiler は、マルチサイクルまたはフォールス・パス・パスタイミング制約を含む.sdcタイミング制約のエンドポイントであるレジスターをリタイムしません。したがって、リタイミング制約を回避するために、可能な限り具体的にタイミング制約または例外を割り当ててください。

マルチサイクル制約ではなく、実際のレジスターステージを使用することで、Compiler はパフォーマンスを向上させるためにも柔軟に対応できます。例えば、組合せロジックに 3 のマルチサイクル例外を指定せずに、マルチサイクル例外を削除し、組み合わせロジックの前または後に 2 つの余分なレジスターステージを挿入します。この変更により、Compiler は余分なレジスター段のロジックを適にバランスさせることができます。



2.2.4.2 過剰制約

過剰制約は、デザインの特定の部分を適化するためにより多くの時間を費やすように指示します。いくつかの状況では、パフォーマンスを向上させるために過剰制約が適切な場合があります。しかしながら、従来の過剰制約方法はリタイミング適化を制限するので、 Stratix 10 デバイスは、リタイミングを可能にする新しい is_post_route関数をサポートします。 is_post_route関数を使用すると、Fitter はタイミング適化のためにスラック遅延を調整できます。

例-1: Stratix 10 超過制約構文（Hyper-Retiming を可能にする）

if { ! [is_post_route] } { # Put overconstraints here}

例-2: レガシー過剰制約の例（Hyper-Retiming を防止する）

### Over Constraint #### if {$::quartus(nameofexecutable) == "quartus_fit"} {# set_min_delay 0.050 -from [get_clocks {CPRI|PHY|TRX*|*|rx_pma_clk}] -to [get_clocks {CPRI|PHY|TRX*|*|rx_clkout}]# }

2.2.5 クロック同期の戦略

簡単な同期化戦略を使用して、 Stratix 10 アーキテクチャの高速度に到達します。単純なシンクロナイザーのクロッシング・パスにレイテンシーを追加するのは簡単です。しかし、他のクロッシングにレイテンシーを追加することはより複雑です。

図 -16: 単純なクロック・ドメイン・クロッシングこの例では、初のドメインの 1 つのレジスター（青色）から次のドメインのレジスター（赤色）へのパスを持つ単純な同期スキームを示します。

図 -17: レイテンシーを追加した後の単純なクロック・ドメイン・クロッシングリタイミングのために赤い領域にレイテンシーを追加するには、図のようにレジスターを追加します。

次の図は、ドメイン横断構造を示しています。 Stratix 10 他のデバイスファミリを対象としたデザインに存在する可能性があります。デザインには、青のクロックドメインと赤のクロックドメインの間にいくつかの組み合わせロジックが含まれています。このロジックは正しく同期されておらず、レジスターを柔軟に追加することはできません。青のクロックドメインは組み合わせロジックを駆動し、ロジックには赤のドメインで起動されるパスが含まれます。



図 -18: 複数の位置でのクロック・ドメイン・クロッシング

レッド・クロック・ドメインの境界にレイテンシーを追加しますが、レッドからレッドのドメインパスにはレジスターを追加しないでください。それ以外の場合、パスは不均衡になり、潜在的にデザイン機能が変化します。可能であったとしても、このシナリオでレイテンシーを追加するのは危険です。レイテンシーを追加する前に、さまざまなパスを完全に分析します。

図 -19: レイテンシーを追加した後の複数の位置でのクロック・ドメイン・クロッシング

Stratix 10 デザインの場合、組み合わせロジックに入る前にクロック・クロッシング・パスを同期化します。前の例と比較してレイテンシーを追加する方が簡単です。青のドメインレジスターは、組合せロジックに入る前に赤のドメインに同期します。この方法は、誤って赤パスから赤パスに接触せずに、同期レジスターの前にパイプライン・レジスターを安全に追加することができます。このアプローチは、 Stratix 10アーキテクチャーのパフォーマンスを大限に活用するための推奨される同期方法です。



図 -20: 改善されたクロックドメイン同期

2.2.6 メタステーブル・シンクロナイザ

Compiler はシンクロナイザ・チェインの一部であるレジスターを検出します。Compiler は、シンクロナイザ・チェイン内のレジスターをリタイムすることはできません。シンクロナイザ・チェイン内のレジスターのリタイミングを可能にするには、クロック・ドメイン境界にパイプライン・レジスターを追加します。

メタステーブル・シンクロナイザに必要なレジスターは、Critical Chain レポートでは REG（Metastability required）とマークされます。

2.2.7 初期のパワーアップ条件

電源投入時のデザインの初期状態は、クロックサイクル 0 でのデザインの状態を表します。初期状態は、デバイスの基本技術に大きく依存します。デザインが初期状態を離れると、その状態に戻る自動化された方法はありません。つまり、初期状態は、機能状態ではなく過渡的状態です。さらに、他のデザイン・コンポーネントが初期状態の有効性に影響を与える可能性があります。例えば、パワーアップ時にまだロックされていない PLL は、初期状態に影響を与える可能性があります。

したがって、 Stratix 10 FPGA のためにデザインする時、初期条件に依存しないでください。したがって、単一のリセット信号を使用して、すべてのインターフェイスの電源が投入、ロック、トレーニングされるまでに、デザインを既知の状態にします。

2.2.7.1 初期条件の指定

RTL コードの推論によって初期パワーアップ条件を指定できます。 Quartus Prime 合成は、レジスターされた信号のデフォルト値をパワーアップ・レベルの制約に自動的に変換します。あるいは、Power-Up Level 制約を手動で指定します。

例-3: 初期パワーアップ条件の構文（Verilog HDL）

reg q = 1’b1; //q has a default value of ‘1’always @ (posedge clk)begin q <= d;end



例-4: 初期パワーアップ条件構文（VHDL）

SIGNAL q : STD_LOGIC := '1'; -- q has a default value of '1'PROCESS (clk, reset)BEGIN IF (rising_edge(clk)) THEN q <= d; END IF;END PROCESS;

2.2.7.2 初期条件とリタイミング

初期パワーアップ条件は、Compiler の次の能力を制限します。

• 合成中に論理適化を実行する

• リタイミング中にレジスターを Hyper-Register に移動する

次の例は、初期状態を既知の状態に設定することによって、回路がリタイミング後に機能的に等価であることを保証する方法を示しています。

図 -21: リタイミング前の回路このサンプル回路は、パワーアップ時のレジスター F1が状態「 0 」または状態「 1 」のいずれかを持つことができることを示しています。ロジックの塊が純粋に組み合わせであると仮定すると、回路 C1 (F1=‘0’ or F1=‘1’)には 2 つの可能な状態があります。

D Q

F1

図 -22: リタイミング後の回線Retimer がレジスター F1を前方に押すと、Retimer は F1が駆動する各分岐のレジスターを複製する必要があります。

F12

D Q

F11

D Q

F12

D QF12

リタイミングおよびレジスターの複製の後、回路は電源投入時に 4 つの可能な状態を持つようになります。リタイミング後に回路内に 2 つの電位状態を追加すると、デザイン機能が変化する可能性があります。



表 3. リタイミング後の可能なパワーアップ状態

F11 の状態 F12 の状態

0 0

0 1

1 0

1 1

C サイクル等価

c サイクルは、機能上の同等性を保証するためにパワーアップ後にデザインが必要とするクロックサイクルの数を指します。 c サイクル値は、デザインのリセットシーケンスを構成する際の重要な考慮事項です。リタイミング後にデザインの同等機能を保証するには、電源投入後に余分なクロックサイクルを適用します。この余分なクロックサイクルにより、 F11と F12の状態は常に同じになります。この手法は、組合せロジックが両方の経路上で非反転であると仮定して、レジスター 0/0 または 1/1 の 2 つの可能な状態のみをもちます。

後方へのリタイミング

レジスターの逆方向のリタイミングは、常に安全な動作であり、c サイクルの値は 0です。このシナリオでは、Compiler は F11と F12をマージします。 F11と F12の初期条件を指定しないと、Compiler は常にマージを許可します。初期条件を指定すると、Compiler は F11と F12の初期状態を考慮します。この場合、リタイミング変換は変換が初期状態を保持する場合にのみ実行されます。

Compiler 変換が F11と F12の初期状態を保持できない場合、Compiler でリタイミング操作を実行できません。リタイミング中に回路機能を変更しないようにするには、電源投入後に余分なクロックサイクルを適用して、 F11と F12の内容が常に同一であることを確認してください。

2.2.7.3 トランシーバ・リセット・シーケンス

特定の条件下では、Retime ステージは、0 より大きい C サイクル値を持つレジスターの変換を実行します。この機能は、デザインの大頻度を向上させるのに役立ちます。しかし、ゼロより大きい c サイクル等価値を有するレジスター・リタイミングは、リタイミング後に機能的等価性を保証するために余分な予防措置を必要とします。既存のリセットシーケンスを活用し、以下に説明するように適切な数のクロックサイクルを追加して機能的同等性を保持します。

リセット動作のリセット

リセットのタイミングを変更すると、Compiler の動作は次のようになります。

• リセット付きバックワード・りタイミングは安全であり、初期状態を考慮して実行します。

• リセット付きフォワードリタイミングは、常に初期条件を保持します。

• レジスターのリタイミングは、リタイミングのために、初期条件なしのレジスターにパワー・アップ時に 0 の初期条件がないことを前提とします。リタイミングはこの初期条件を保持します。

初期条件の無視

レジスターの初期条件を無視して、必要に応じてより多くのレジスターをリタイムします。ALLOW_POWER_UP_DONT_CAREオプションを指定して、初期リセット条件を無視し、リタイミングを続行します。

set_global_assignment -name USE_DLL_FREQUENCY_FOR_DQS_DELAY_CHAIN ON



ALLOW_POWER_UP_DONT_CAREを使用する場合、リセットシーケンスの対象となるレジスターにRTL コードの初期条件がないことを確認してください。

リセットシーケンスの変更

リタイミング中にリセットの動作周波数を大にするには、次の推奨事項に従ってください。

• 自然にリセットされるすべてのレジスターから sclr信号を除去します。これにより、リタイミング中にレジスターが自由にロジック内を移動することができます。

• リセットシーケンスによってカバーされるレジスターのパワーアップ状態を注意しないように割り当てます。これらのレジスターの初期条件は無視してください。

• ALLOW_POWER_UP_DONT_CAREグローバル割り当てを ONに設定します。この設定はレジスターの移動を大限にします。

• c サイクルの等価性に起因する余分なクロックサイクルを計算し、リセットシンクロナイザに追加します。

リセットにクロックサイクルの追加

Compiler は、デザインのリタイミング変換の c サイクル値を報告しません。ただし、デザイン内のパイプラインの数と長さを評価してください。次に、リセットシーケンスを終了するときにデザインの機能的同等性を保証するのに十分なクロックサイクルを追加します。

注意を必要とする変換の多くは、1 の c サイクルを持ちます。例えば、複数のブランチに重複をレジスターすると、この c サイクルが実行されます。重複レジスターの数にかかわらず、レジスターは常に元のソースから 1 つの接続先にあります。 1 クロックサイクル後、すべてのブランチは再び同じ値を持ちます。

次の例は、リセットシーケンスにクロックサイクルを追加することにより、リセットシーケンス後のリタイミングされたデザインの機能的同等性を保証する方法を示しています。

図 -23: パイプライニングとレジスターの複製

この例は、順方向リタイミングが可能なパイプライン型のレジスターセットを示しています。 c サイクル値は 0 に等しいです。

D Q

F4

D Q

F3

D Q

F2

D Q

F1



図 -24: 1 つのレジスター移動の影響

この例は、1 つのレジスターの順方向リタイミング後のパイプライン・セットのレジスターを示しています。 c サイクル値が 1 に等しいので、この回路のリセットシーケンスは、リセット後の機能的等価性のために 1 つの追加クロックサイクルを必要とします。

D Q

F4

D Q

F3

D Q

F2

D Q

F11

D Q

F12

図 -25: 2 つのレジスター移動の影響

この例は、2 つのレジスターの順方向リタイミング後にパイプラインされたレジスターセットを示しています。 c サイクル値は 2 に等しいので、この回路のリセットシーケンスには、リセット後の機能的等価性のために 2 つの追加のクロックサイクルが必要です。

D Q

F4

D Q

F3

D Q

F21

D Q

F22

D Q

F11

D Q

F12

パイプラインからのレジスターをロジックに移動するたびに、レジスターの複製とデザインの C サイクル値が 1 ずつ増加します。

2.3 Hyper-Pipelining（パイプライン・レジスターの追加）

Hyper-Pipelining は、ALM 間の相互接続にパイプライン・ステージを追加することにより、長いルーティング遅延を排除するデザインプロセスです。この技術により、より高速なクロック周波数でデザインを実行することができます。初に Fast-Forward コンパイルを実行して、パイプライン・ステージを追加することで期待できる高の位置と予想されるパフォーマンスを判断します。このプロセスは小限の労力しか必要とせず、従来の高性能 FPGA と比較して、 Stratix 10 デバイスでは 1.3〜1.6 倍の性能向上をもたらします。

RTL にレジスターを追加することは、あらかじめデザインのレイテンシーを追加することを計画していれば、はるかに簡単です。も基本的なレベルでレイテンシーを追加することを計画することは、デザイン内のクロックドメインの入力と出力でパラメータ化可能なパイプラインを使用することを意味します。Verilog HDL、VHDL、および SystemVerilog で事前に書かれたパラメーター化可能なパイプライン・モジュールについては、付録：パイプラインの例を参照してください。

レイテンシーの変更は、パイプライン・ステージを追加する場合より複雑です。後で到着するデータで適切に動作するように、コントロール・ロジックやデザイン・ソフトウェアやシステム・ソフトウェアの他の部分を修正する必要があります。既存の RTL でこのような変更を加えることはは困難ですが、デザインの新しい部分ではより簡単になる可能性があります。ブロックのレイテンシーをコントロール・ロジックにハー



ド・コーディングせずに、いくつかのレイテンシーをパラメーターとして実装します。いくつかのタイプのシステムでは、データが有効な時の高レベルの固定コンセプトに頼るのではなく、様々な計算をトリガーするために、処理パイプラインのパイプライン・ステージに「valid data」フラグを追加することができます。

追加レイテンシーには、テストベンチの変更が必要な場合もあります。テストベンチを作成するときは、レイテンシーを考慮しないデザインを作成するのと同じテクニックを使用します。所定のクロックサイクル数で結果が得られることを期待しないでください。そして、「valid data」または「valid result」フラグをチェックしてください。

レイテンシーを考慮しないデザインは、システムのあらゆる部分に適切であるわけではありません。データが準備完了またはイネーブルになるためのクロックサイクル数を指定するインターフェイス・プロトコルは、これらの要件に準拠する必要があり、遅延の変更に対応できない可能性があります。

RTL を変更し、所定の数のパイプライン・ステージを各クロックドメインの境界に配置すると、Retime ステージはクロックドメイン内のレジスターを適な位置に自動的に配置してパフォーマンスを大化します。 Hyper-Retiming と Fast-Forward コンパイルの組み合わせは、従来のパイプライニングと比較してプロセスを自動化するのに役立ちます。

関連情報• 111 ページの付録 A：パラメーター化可能パイプライン・モジュール

• 33 ページの事前計算

2.3.1 従来のパイプライン化と Hyper-Pipelining 処理の比較

このセクションでは、Hyper-Pipelining がこのような従来のパイプライン化を簡素化する方法について説明します。

従来のパイプライン化には、次のようなデザイン変更が含まれます。

• ロジック群の間に 2 つのレジスターを追加します。

• Logic Cloud 2 としたデザインのロジッククラウドに第 3 のレジスター（またはパイプライン・ステージ）を挿入するように HDL を変更します。このレジスター挿入により、Logic Cloud 2a と LogicCloud 2b が効果的に HDL に作成されます。

図 -26: 従来のパイプライン化ユーザーの変更

LogicCloud1

LogicCloud2

Reg1 Reg2 Reg3

LogicCloud1

LogicCloud2b

Reg2Reg1 Reg3

LogicCloud2a

Pipe1 Pipe2 Pipe3

図 -27: Hyper-Pipelining によるユーザーの変更Hyper-Pipelining は、レジスターを追加するプロセスを簡素化します。デザイン RTL の 1 つの位置で、レジスター（Pipe 1、Pipe 2、Pipe 3）を集計して追加します。Compiler は回路全体のレジスターをリタイムして、パスに沿った適な配置を見つけます。この適化によりパス遅延が減少し、デザインの動作周波数が大になります。

LogicCloud1

LogicCloud2

Reg1 Reg2 Reg3 Reg1 Reg2 Reg3Pipe1 Pipe2 Pipe3

LogicCloud1

LogicCloud2



図 -28: Hyper-Pipelining と Hyper-Retiming の実装次の図は、リタイミング・ステージが適化を完了した後の追加レジスターの実装を示しています。

LogicCloud2a

Reg1 Reg2 Reg3Pipe1 Pipe2 Pipe3 Reg1 Reg2 Reg3Pipe1 Pipe2 Pipe3

LogicCloud1

LogicCloud2

LogicCloud1

LogicCloud2b

Hyper-Pipelining フローにおける結果の実装は、Pipe 3 レジスターの位置による従来のパイプライン・フローとは異なります。Compiler はルーティングを含む現在の回路実装を認識しているため、デザインの大動作周波数を満たすように、追加された集約レジスターをより効果的に見つけることができます。Hyper-Pipelining では、レジスターをデータパスの便利な位置に配置することができるため、従来のパイプライン手法よりも大幅に労力が軽減され、Compiler はレジスターの配置を自動的に適化します。

2.3.2 パイプライニングとレイテンシー

パス内にパイプライン・レジスターを追加すると、信号値がパスに沿って伝搬するのに必要なクロックサイクル数が増加します。クロック周波数を上げるとレイテンシーが向上します。

図 -29: Hyper-Pipeline による低減レイテンシーこの例では、275MHz fMAX 要件の前世代 Intel FPGA を示します。左のパスは 3.5ns の遅延によって制限されるため、286MHz の達成となっています。データはレジスター・パイプラインを伝播するのに 3 サイクルが必要です。 275Mhz での 3 サイクルは、パイプラインを通して伝搬するために 10.909 ns です。

1.5 ns 3.5 ns 1.5 ns 1.7 ns 1.8 ns

Stratix 10 デバイスをリターゲティングすることにより fMAX 要件を 550MHz に倍増すると、図の右側のパスは、追加のパイプライン・ステージがどのようにリタイムするかを示しています。このパスは555MHz を達成し、1.8 ns の遅延で制限されています。データはレジスター・パイプラインを伝播するのに 4 サイクルが必要です。 550 MHz で 4 サイクルは 7.273 ns に等しく、これがパイプラインを通過するのに必要な時間です。

3 段と比べて、4 段のパイプラインを通過売るのにかかる時間を維持するために、初のバージョンの10.909 ns の遅延を維持するために、2 つ目のバージョンの fMAX を 367 MHz にあげます。このテクニックにより 275 MHz から 33%の上昇となります。

2.3.3 マルチサイクル例外の代わりにレジスターの使用

多くの場合、デザインには複数のクロックサイクルが必要な複雑な組合せロジック（CRC やその他の算術機能など）を持つモジュールが含まれています。これらのモジュールはタイミング要件を緩和するマルチサイクル例外を使用して制約します。 Stratix 10 デバイスをターゲットとするデザインでは、これらのモジュールと制約を使用できます。詳細については、「マルチサイクルパスのデザインに関する考慮事項」セクションを参照してください。

あるいは、モジュールの 1 つの便利な位置に多数のレジスターステージを挿入することができます。Compiler はそれらを自動的にバランスさせます。例えば、パイプライン化を行う CRC 機能を備えている場合、適な分解と中間期間をレジスターする必要はありません。入力または出力にレジスターを追加すると、Compiler はそれらをバランスさせます。



関連情報• 18 ページのマルチサイクル･パスの適化

• 111 ページの付録 A：パラメーター化可能パイプライン・モジュール

2.4 Hyper-Optimization （RTL の適化）

Hyper-Retiming、Fast Forward コンパイル、および Hyper-Pipelining でデータパスを高速化した後も、デザインには長いフィードバックループやステートマシンなどのコントロール・ロジックの限界があります。

このような限界を克服するには、長い組合せフィードバックパスではなく、機能的に同等のフィードフォワード・パスまたはプリコンピュート・パスを使用します。以下のセクションでは、さまざまなデザイン構造に対する特定の Hyper-Optimization について説明します。このプロセスは、以前の世代の高性能FPGA と比較して、 Stratix 10 デバイスの 2 倍の性能向上をもたらします。

2.4.1 一般的な適化手法

次の一般的な RTL テクニックを使用して HyperFlex FPGA アーキテクチャーのためのデザインの適化を行います。

2.4.1.1 シャノン分解

シャノン分解は Hyper-Optimization での役割を果たします。シャノン分解、すなわちシャノン展開は、ブール式を因数分解する方法です。関数を F = x.Fx + x′Fx′と表すことができます。ここで、x.Fx と x′Fx′は、関数 F の x に対する正と負の補因子です。次の図に示すように、(a, b, c, x) = x.(a, b, c, 1)+ x′.F(a, b, c, 0)という 4 つの入力を持つ関数を因数分解することができます。Hyper-Optimization では、シャノン分解は、x 信号を入力ロジックのコーンのヘッドにプッシュし、x 信号をロジックのコーンを通る速のパスにします。 x 信号は、他のすべての信号を犠牲にして速の経路になります。シャノン分解を使用すると、元の関数からの面積コストも 2 倍になります。

図 -30: シャノン分解

abcx

F

abc1

F

abc0

F

x

10



図 -31: シャノン分解のロジック削減ロジック・シンセシスでは、次の図に示すように、定数駆動入力を使用し、補因子をわずかに削減することができます。

abc1

F

abc0

F

x

10

abc F X

abc F X

x

10

図 -32: 繰り返したシャノン分解次の図は、シャノン分解を繰り返し使用して、複数の重要な入力信号を持つ関数を分解する方法を示しています。これにより面積コストは増加します。

abc F X

abc F X

x

10

ab

F X

ab

F X

x

10

ab

F X

ab

F X

x

10

c

10

シャノン分解はループのための効果的な適化テクニックである場合があります。ループ内のロジックに対してシャノン分解を実行すると、ループ内のロジックがループ外に移動します。Compiler は、ループ外に移動されたロジックをパイプラインできるようになります。



図 -33: シャノン分解前のループの例この図は、1 つのレジスター、4 レベルの組み合わせロジック、および追加の入力を含むループを示しています。ループ内にレジスターを追加すると機能が変更されますが、シャノン分解を実行することによって組み合わせロジックをループ外に移動することができます。

Cannot Be Pipelined

ループ内のレジスターの出力は 0 または 1 です。ループにレジスターを供給する組み合わせロジックを複製し、1 つのコピーの入力を 0 に、もう 1 つのコピーの入力を 1 に割り当てます。

図 -34: シャノン分解後のループの例そして、ループ内のレジスターは、次の図に示すように、2 つのコピーの 1 つを選択します。

Can Be Pipelined

0

1

0

1

Cannot Be Pipelined

ループ内のロジックに対してシャノン分解を実行すると、ループ内のロジックの量が減ります。Compiler は、ループから削除されたロジックにレジスターのリタイミングまたは Hyper-Pipeliningを実行し、回路のパフォーマンスを向上させることができます。

2.4.1.1.1 シャノン分解例

サンプル回路は、 internal_total値の入力値をターゲット値との関係に基づいて加算または減算します。回路のコアは、次の例に示す target_loopモジュールです。

例-5: シャノン分解前のソースコード

module target_loop (clk, sclr, data, target, running_total);parameter WIDTH = 32;

input clk;input sclr;input [WIDTH-1:0] data; input [WIDTH-1:0] target; output [WIDTH-1:0] running_total;

reg [WIDTH-1:0] internal_total;

always @(posedge clk) begin if (sclr) begin internal_total <= 0; end else begin internal_total <= internal_total + ((( internal_total > target) ? -data:data)* target/4)); end



endassign running_total = internal_total;end module

このモジュールでは、Hyper-Retiming をイネーブルにするための推奨事項に基づいて、同期クリアを使用します。

次の図は、レジスター・リングでインスタンス化された target_loopモジュールの Fast ForwardCompile レポートを示しています。

図 -35: シャノン分解の前の Fast Forward Compile のレポート

Hyper-Retiming は、Fast Forward Compile でパイプライン・ステージを追加することで約 248MHz をレポートします。Limiting Reason カラムは、クリティカル・チェインがループであることを示します。クリティカル・チェイン・レポートを調べると、チェインセグメントに繰り返した構造があることがわかります。Optimizing Loops のセクションに、繰り返しの構造を示します。

次の図は、前のサンプルコードの式を実装したときの構造を示しています。機能ブロックは、比較演算、加算演算、および乗算演算に対応します。各算術ブロックの名前のゼロは、ネットリストの合成名の一部です。ゼロは、ブロックが合成によって作成された演算子の初のゼロ・インデックス付きインスタンスであるためです。

図 -36: クリティカル・チェインのサブループの要素

internal_total

LessThan0 Add0

Mult0

この式はシャノン分解の候補です。データの正または負の値で 1 回の加算だけを実行する代わりに、次の 2 つの計算を同時に実行できます。

• internal_total - （data * target / 4）• internal_total +（data * target / 4）

次に、比較 internal_total> targetの結果を使用して、使用する計算結果を選択することができます。次の例では、シャノン分解を使用して internal_total計算を実装するコードの修正版を示します。

例-6: シャノン分解後のソースコード

module target_loop_shannon (clk, sclr, data, target, running_total); parameter WIDTH = 32;

input clk;input sclr;input [WIDTH-1:0] data;input [WIDTH-1:0] target;output [WIDTH-1:0] running_total;



reg [WIDTH-1:0] internal_total;wire [WIDTH-1:0] total_minus;wire [WIDTH-1:0] total_plus;

assign total_minus = internal_total - (data * (target / 4));assign total_plus = internal_total + (data * (target / 4));

always @(posedge clk) begin if (sclr) begin internal_total <= 0; end else begin internal_total <= (internal_total > target) ? total_minus:total_plus); endend

assign running_total = internal_total;endmodule

次の図に示すように、コードを変更してデザインをリコンパイルすると、パフォーマンスはほぼ倍増します。

図 -37: シャノン分解後の Fast Forward Summary のレポート

2.4.1.1.2 シャノン分解のための回路の特定

シャノン分解は、後の選択ステージを制御するために多くの入力を並べ替えることが許される回路に適しています。ロジックを再構成して、入力のサブセットを使用して選択ステージを制御するときに、新しいロジック深度を考慮します。理想的には、選択信号に対するロジックの段数は、セレクタ入力に対する論理深さに類似しています。実際には、ロジックの段数には違いがあります。これは、ロジックの各クラウドに供給される入力の数を完全にバランスさせることが難しいためです。

シャノン分解は、ロジックのコーン内に本当に重要な信号が 1 つか 2 つだけで、ほかのものはスタティックであるか、または明らかに低い優先順位である回路にとっては良い解決差です。

シャノン分解は、特に関数が複雑な場合には、かなりのエリアコストを招くことがあります。このドキュメントで説明されているように、エリアコストが低い他の適化手法があります。

2.4.1.2 タイムドメインの多重化

タイムドメインの多重化は、複数の計算スレッドを使用して回路スループットを向上させます。このテクニックは、C-slow リタイミング、またはマルチスレッドとも呼ばれます。

タイムドメインの多重化は、回路内の各レジスターを一連の C レジスターのセットと直列に置き換えます。追加されたレジスターのコピーごとに新しい計算スレッドが作成されます。変更されたデザインによる 1 回の計算では、元の回路の C 倍のクロックサイクルが必要です。ただし、Compiler は追加のレジスターをリタイムして、fMAX を C 倍に向上させることができます。例えば、400 MHz で動作する 2 つのモジュールをインスタンス化する代わりに、800 MHz で動作する 1 つのモジュールをインスタンス化できます。

次の図は、初期回路から始まる C-slow リタイミングのプロセスを示しています。



図 -38: C-slow リタイミング・スタート・ポイント

RTL デザインを編集して、ループ内のレジスターを含むすべてのレジスターを、独立した計算スレッドごとに 1 つのレジスターを含む C レジスターのセットに置き換えます。

図 -39: C-slow リタイミング中間点この例では、各レジスターを 2 つのレジスターに置き換える方法を示します。

この時点で回路をコンパイルします。Compiler が回路を適化すると、追加のレジスターでリタイミングを実行する柔軟性が向上します。

図 -40: C-Slow リタイミング終了ポイント

すべてのレジスターをレジスターのセットに置き換えるだけでなく、複数の入力データストリームをブロックに多重化し、出力ストリームをブロックから逆多重化する必要があります。デザインに複数の並列スレッドが含まれており、それぞれがループによって制限されている場合、時間領域の多重化を使用します。適化するモジュールは、レイテンシーに敏感であってはなりません。

2.4.1.3 ループ・アンローリング

ループ・アンローリングは、ロジックをループからフィード・フォワード・フローに移動させます。追加のパイプライン・ステージでロジックをさらに適化することができます。

2.4.1.4 事前計算

事前計算は、全体のデザイン速度を適化するも簡単でも有益な手法の 1 つです。クリティカルなロジックに直面した場合、計算が意味する信号が以前に使用可能かどうかを検証します。これらの計算をクリティカルなロジックの外に保つためには、常に信号をできるだけ早く計算してください。

クリティカルなロジックをループの外に置こうとするときは、まず事前計算を試してください。Compilerは、リタイミングのみを使用して簡単にループ内のロジックを適化することはできません。Compilerは、ループ内のレジスターをループの外側に移動することはできません。Compiler はループ外のレジスターをループにリタイムすることはできません。したがって、ループ内のロジックをできるだけ小さくして、fMAX に悪影響を与えないようにしてください。

事前計算後、ループ内でロジックが小化され、デザインはエンコードを事前計算します。計算はループの外にあり、パイプライン化またはリタイミング化で適化することができます。ループを削除することはできませんが、ループのデザインスピードへの影響をより適切に制御できます。



図 -41: 高価なループによるデザインの再構築

FIFO

readenExpensive

Calculation

Payload

Before Precomputation

FIFO

readenSimpleLogic

Payload

After Precomputation

SimpleLogic

Port Count

PrecomputeNew Encoding

次のコード例は、同様の問題を示しています。元のループには比較演算子が含まれています。

StateJam:if (RetryCnt <=MaxRetry&&JamCounter==16) Next_state=StateBackOff; else if (RetryCnt>MaxRetry) Next_state=StateJamDrop; else Next_state=Current_state;

RetryCnt<=MaxRetryおよび JamCounter==16の値を事前に計算すると、StateJam ループから高価な計算が削除され、単純なブール演算で置き換えられます。変更されたコードは次のとおりです。

reg RetryCntGTMaxRetry;reg JamCounterEqSixteen; StateJam:if (!RetryCntGTMaxRetry && JamCounterEqSixteen) Next_state=StateBackOff; else if (RetryCntGTMaxRetry) Next_state=StateJamDrop; else Next_state=Current_state; always @ (posedge Clk or posedge Reset) if (Reset) JamCounterEqSixteen <= 0; else if (Current_state!=StateJam) JamCounterEqSixteen <= 0; else JamCounterEqSixteen <= (JamCounter == 15) ? 1:0; always @ (posedge Clk or posedge Reset) if (Reset) RetryCntGTMaxRetry <= 0; else if (Current_state==StateSwitchNext) RetryCntGTMaxRetry <= 0; else if (Current_state==StateJam&&Next_state==StateBackOff) RetryCntGTMaxRetry <= (RetryCnt >= MaxRetry) ? 1: 0;



2.4.2 特定のデザイン構造の適化

このセクションでは、一般的なパフォーマンスのボトルネック構造、および各ケースの fMAX 性能を改善するための推奨事項について説明します。

2.4.2.1 高速クロック・ドメイン

Stratix 10 デバイスは非常に高速のクロックドメインをサポートしています。Compiler は、クロック挿入の遅延を小限に抑え、ダイナミック消費電力を低減、またデバイスコアでクロックの柔軟性を提供するためにプログラマブル・クロック・ツリー合成を使用します。

デバイスの小パルス幅の制約は、 Stratix 10 クロックの高性能を制限する可能性があります。与えられたクロックパス上のリソースの数が増えると、クロックパルス上で不確実性とスキューが増加します。クロックの不確実性がターゲットデバイスの小パルス幅を超えると、実行可能な小クロック周期が短くなります。この効果は、パス上の全クロック挿入遅延の関数です。高速クロックドメインのこの影響に対処するには、Chip Planner および TimeQuest レポートを使用して、デザイン内のクロックソース配置を適化します。

レポートに長いクロックルートからの制限が示されている場合、クロックピンの割り当てを調整するか、Clock Region および/または LogicLock Plus Region の割り当てを使用してクロックソースに近いファンアウト・ロジックを制限します。クロック領域の割り当てを使用してクロックセクタを指定し、クロックツリーのサイズを適化します。

割り当てを変更した後、デザインをリコンパイルし、クロックルートの長さとクロックツリーのサイズを確認します。Compilation Report を確認して、クロック・ネットワークがデザインのパフォーマンスを制限していないことを確認します。

2.4.2.1.1 クロック・ネットワークの視覚化

フィッターを実行した後、Chip Planner でクロック・ネットワークの実装を視覚化します。 ChipPlanner は、ソースクロックピンの位置、クロック配線、クロックツリーサイズ、およびクロックセクタの境界を示します。これらのビューを使用して調整を実行し、合計クロックツリーサイズを縮小します。

Chip Planner でデザイン・クロック・ネットワークを視覚化するには：

1. プロジェクトを開きます。

2. Compilation Dashboard で、Fitter、Early Place、Place、Route、または Retime をクリックして Fitter を実行します。

3. Tasks ペインで、Chip Planner をダブルクリックします。 Chip Planner はデバイス情報をロードし、カラーコード化されたチップリソースを表示します。

4. Chip Planner Tasks ペインで、Report Clock Details をクリックします。 Chip Planner は、クロックピンの位置、配線、およびセクタの境界を強調表示します。Clock Details Report の下の要素をクリックすると、要素の一般的な詳細とファンアウトの詳細が表示されます。

5. クロックセクタの境界を視覚化するには、 Layers Setting タブをクリックし、 Clock SectorRegion をイネーブルにします。緑色の線は各セクタの境界線を示します。



図 -42: Chip Planner でのクロック・ネットワーク

Source Clock Pin

Clock Routing Path

Clock Tree Region

図 -43: Chip Planner のクロック・セクタ境界層



2.4.2.1.2 Fitter Report でのクロックネットワークの表示

Compilation Report には、Fitter 配置後のクロック・ネットワーク実装に関する詳細情報が記載されています。Global & Other Fast Signals Details レポートを表示して、ソースクロックピンからクロックツリーまでのクロックパスの長さと深さを表示します。

Fitter レポートでクロックネットワークの実装を表示するには：


2. Compilation Dashboard で、Fitter、Place、Route をクリックして、Fitter を実行します。

3. Compilation Dashboard で、完了したステージの Report アイコンをクリックします。

4. Global & Other Fast Signals Details をクリックします。この表には、ソースからクロックツリーまでのクロックルートの長さとクロック領域深度が表示されます。

図 -44: Fitter Report におけるクロック・ネットワークの詳細

2.4.2.1.3 TimeQuest でのクロックの表示

TimeQuest タイミング・アナライザは、長いクロック・パスによって制限される高速クロックをレポートします。Fmax Summary レポートを開いて、小パルス幅違反（tCH）が高いか小パルス幅違反（tCL）が低いかによって制限されるクロック fMAX を表示します。

TimeQuest のトップ・ビュー・クロック・ネットワークの・データ：


2. Compilation Dashboard で、TimeQuest Timing Analysis をクリックします。TimeQuest の分析が完了すると、 TimeQuest Timing Analyzer のフォルダがCompilation Report に表示されます。

3. Slow 900mV 100C Model フォルダの下で、 Fmax Summary レポートをクリックします。

4. 小パルス幅違反のパス情報の詳細を表示するには、Compilation Report で、 MinimumPulse Width Summary レポートを右クリックし、 Generate Report in TimeQuest をクリックします。 TimeQuest はタイミングネットリストをロードします。

5. Reports > Custom Reports > Report Minimum Pulse Width をクリックします。

6. Report Minimum Pulse Width ダイアログボックスで、レポート出力をカスタマイズするオプションを指定して、OK をクリックします。

7. Slow 900mV 100C Model レポートで、長いクロックルートのレポートのデータパスの詳細を確認します。



図 -45: 小パルス幅の詳細が長いクロックルートを表示する

Reports show a long clock delay

2.4.2.2 ループの再構築

ループは、パフォーマンスを根本的に制限するため、リストラ技術の主なターゲットです。ループは、回路内のフィードバック経路です。ループはシンプルで短くてもよく、フィードバック経路上に少量の組み合わせロジックを持つことができます。ループは非常に複雑で、元のレジスターに戻る前に複数のレジスターを通過する可能性があります。有用な回路にはすべてループが含まれています。

ループにパイプライン・ステージを追加すると機能が変更されるため、Compiler はレジスターをループに決してリタイムしません。ただし、ループを再構成してパフォーマンスを向上させるには、RTL を手動で変更してください。 Fast Forward コンパイルを使用してパフォーマンスのボトルネックを分析した後、ループ適化を実行します。また、これらの手法をデザイン内の新しい RTL に適用します。

2.4.2.3 コントロール信号のバックプレッシャー

このセクションでは、信号バックプレッシャを制御する RTL デザイン手法について説明します。 Stratix10 アーキテクチャーはデータを効率的にストリームします。アーキテクチャーは非常に高いクロックレートをサポートしているため、フィードバック信号を送信して 1 クロックサイクルで大量のロジックに到達することは困難です。余分なパイプライン・レジスターを挿入すると、コントロール信号のバックプレッシャも増加します。データは可能な限り前方に流れる必要があります。



単一クロックサイクルコントロール信号は、パイプライン化およびレジスター・リタイミングの有効性を防止または低減するループを生成します。この例は、データを消費する準備ができていることを上流レジスターに通知する準備完了信号を示しています。準備完了信号は、複数のデータソースを同時に凍結する必要があります。

図 -46: コントロール信号のバックプレッシャー

I Am Not Ready for the Next Data

元の RTL を修正して上流の圧力を緩和する小さな FIFO バッファを追加するのは簡単なプロセスです。このブロックの下流のロジックがデータを使用する準備ができていない場合、FIFO はデータを格納します。

図 -47: FIFO バッファーによるバックプレッシャの制御

This Is Valid Data

FIFOBuffer

Please Try to Slow Down Soon

目標は、データがクロック・サイクルごとに FIFO バッファに到達することです。情報の余分なビットは、データが有効であるかどうかを決定し、FIFO バッファに格納する必要があります。クリティカル信号は、FIFO バッファとデータを消費する下流レジスターとの間に存在するようになります。このループははるかに小さくなります。パイプライン化とレジスター・リタイミングを使用して、FIFO バッファの上流部分を適化できるようになります。

2.4.2.4 FIFO ステータス信号によるフロー・コントロール

フロー・コントロール信号を扱うときは、高いクロックレートが考慮されなければなりません。この考慮事項は、複数の位置で同時にデータパスをゲートする信号で特に重要です。例えば、クロックイネーブルまたは FIFO フル/エンプティ信号です。即時コントロール信号で作業する代わりに、遅延信号を使用してください。 FIFO ブロック内にバッファを構築することができます。コントロール信号は、アップストリーム・データパスがオールモスト・フルであることを示し、アップストリーム・データがそれらのゲート信号を受信するために数クロックサイクルを残します。このアプローチは、コントロール信号上のタイミング収束の困難性を緩和します。

FIFO フル信号とエンプティー信号を使用する場合、オーバーフローやアンダーフローを防止するために、これらの信号を 1 クロック・サイクルで処理する必要があります。



図 -48: FIFO フロー・コントロール・ループループは、FIFO からコントロール信号を読み込む時に形成されます。

FIFO

readempty

data

read_reqempty

オールモスト・フルまたはオールモスト・エンプティの信号を使用する場合、フロー・コントロール・ループにパイプライン・レジスターを追加できます。オールモスト・フルのスレッショルドが低く、エンプティーのスレッショルドが高いほど、信号に追加できるレジスターが増えます。

図 -49: フルの代わりにオールもスト・フルを使用した FIFO の FIFO フロー・コントロール・ループの改善次の例は、フルコントロールフロー信号の 2 つの追加のレジスターを示しています。 FIFO ブロックがオールモスト・フルになったことを知らせると、回路はデータフローを停止するために 2 クロックサイクルを必要とします。追加の有効なデータを適切に格納できるように、FIFO ブロックのサイズを調整します。制御パス内の追加の 2 本のパイプライン・レジスターは、ルーティングに役立ち、従来のシングルサイクル FIFO 制御スキームよりも高速を可能にします。

DataProducer

FIFO

FIFO Full

DataProducer

FIFO

FIFO Almost Full

スキッドバッファを使用して FIFO をパイプライン化することができます。必要に応じて、スキッドバッファをカスケードできます。スキッドバッファを挿入すると、FIFO コントロール信号を含むループが展開されます。スキッドバッファはフローコントロール・ロジックのループを除去しませんが、ループは一連の短いループに変換されます。一般に、スキッドバッファを使用する代わりに、オルモスト・エンプティーとオルモスト・フル信号に切り替えます。

図 -50: リード・コントロール・ループ内の 2 つのスキッドバッファを有する FIFO フロー・コントロール・ループ

FIFO

empty

data

empty

readread_req

FIFO コントロール信号を含むループがあり、フロー制御用の多数の宛先にブロードキャストされている場合、ブロードキャスト信号を除去できるかどうかを検討してください。パイプラインのブロードキャスト・コントロール信号を使用し、FIFO のオルモスト・フルとオルモスト・エンプティー信号を使用します。



例-7: スキッドバッファの例

/ synopsys translate_off//`timescale 1 ps / 1 ps// synopsys translate_on

module singleclock_fifo_lowell#(

parameter DATA_WIDTH = 8, parameter FIFO_DEPTH = 16, parameter SHOWAHEAD = "ON", // "ON" = showahead mode ('pop' is an acknowledgement); "OFF" = normal mode ('pop' is a request). parameter RAM_TYPE = "AUTO", // "AUTO" or "MLAB" or "M20K". // Derived parameter ADDR_WIDTH = $clog2(FIFO_DEPTH) + 1 // e.g. clog2(64) = 6, but 7 bits needed to store 64 value) ( input wire clk, input wire rst, input wire [DATA_WIDTH-1:0] in_data, // write data input wire pop, // rd request input wire push, // wr request output wire out_valid, // not empty output wire in_ready, // not full output wire [DATA_WIDTH-1:0] out_data, // rd data output wire [ADDR_WIDTH-1:0] fill_level); wire scfifo_empty; wire scfifo_full; wire [DATA_WIDTH-1:0] scfifo_data_out; wire [ADDR_WIDTH-1:0] scfifo_usedw;

logic [DATA_WIDTH-1:0] out_data_1q; logic [DATA_WIDTH-1:0] out_data_2q; logic out_empty_1q; logic out_empty_2q; logic e_pop_1; logic e_pop_2; logic e_pop_qual; assign out_valid = ~out_empty_2q; assign in_ready = ~scfifo_full; assign out_data = out_data_2q; assign fill_level = scfifo_usedw + !out_empty_1q + !out_empty_2q;

// add output pipe assign e_pop_1 = out_empty_1q || e_pop_2; assign e_pop_2 = out_empty_2q || pop; assign e_pop_qual = !scfifo_empty && e_pop_1; always_ff@(posedge clk) begin if(rst == 1'b1) begin out_empty_1q <= 1'b1; // empty is 1 by default out_empty_2q <= 1'b1; // empty is 1 by default end else begin if(e_pop_1) begin out_empty_1q <= scfifo_empty; end if(e_pop_2) begin out_empty_2q <= out_empty_1q; end end end always_ff@(posedge clk)



begin if(e_pop_1) out_data_1q <= scfifo_data_out; if(e_pop_2) out_data_2q <= out_data_1q; end

scfifo scfifo_component ( .clock (clk), .data (in_data),

.rdreq (e_pop_qual), .wrreq (push),

.empty (scfifo_empty), .full (scfifo_full), .q (scfifo_data_out), .usedw (scfifo_usedw),// .aclr (rst), .aclr (1'b0), .almost_empty (), .almost_full (), .eccstatus (), //.sclr (1'b0) .sclr (rst) // switch to sync reset ); defparam scfifo_component.add_ram_output_register = "ON", scfifo_component.enable_ecc = "FALSE", scfifo_component.intended_device_family = "Stratix", scfifo_component.lpm_hint = (RAM_TYPE == "MLAB") ? "RAM_BLOCK_TYPE=MLAB" : ((RAM_TYPE == "M20K") ? "RAM_BLOCK_TYPE=M20K" : ""), scfifo_component.lpm_numwords = FIFO_DEPTH, scfifo_component.lpm_showahead = SHOWAHEAD, scfifo_component.lpm_type = "scfifo", scfifo_component.lpm_width = DATA_WIDTH, scfifo_component.lpm_widthu = ADDR_WIDTH, scfifo_component.overflow_checking = "ON", scfifo_component.underflow_checking = "ON", scfifo_component.use_eab = "ON";

endmodule

2.4.2.5 リード・モディファイ・ライトのメモリー

Stratix 10 M20K メモリー・ブロックは、コヒーレント・リードをサポートし、リード・モディファイ・ライト・メモリーの実装を簡素化します。リード・モディファイ・ライトのメモリーは、ネットワーク統計カウンターなどのアプリケーションで役立ちます。リード・モディファイ・ライト・メモリーは、1 サイクルでインクリメントとリライティングを必要とするメモリーに値を格納するアプリケーションでも役に立ちます。

Stratix 10 M20K メモリーブロックは、手書きキャッシング回路の必要性を排除して実装を簡素化します。高いクロックレートまたは大きなカウンターのために、複数のクロックサイクルにわたって修正動作をパイプライン化しなければならないキャッシング回路は複雑になります。

コヒーレントのリード機能を使用するには、出力データポートをレジスターするかどうかに応じてメモリーを接続します。出力データポートをレジスターする場合、メモリーをインスタンス化するときに、ライト・イネーブル・ラインおよびライト・アドレス・ラインに 2 つのレジスターステージを追加します。



図 -51: レジスターされた出力データには 2 つのレジスター・ステージが必要

M20K Memorywith CoherentRead Feature

operand

readaddress

wen

writeaddress

writedata

readdata

出力データポートをレジスターしない場合、メモリーをインスタンス化する際に、ライト・イネーブル・ラインおよびライト・アドレス・ラインに 1 つのレジスターステージを追加します。

図 -52: 未レジスターの出力データには 1 つのレジスター段が必要

M20K Memorywith CoherentRead Feature

operand

readaddress

wen

writeaddress

writedata

readdata



コヒーレント・リードの使用には次の制限があります。

• リードとライトに同じクロックを使用する必要があります。

• リード・ポートおよびライト・ポートには同じ幅を使用する必要があります。

• ECC は使用できません。

• バイトイネーブルを使用できません。

図 -53: リード・モディファイ・ライト・メモリーのパイプライン化次の図は、近のアクティビティを追跡するためのキャッシュを維持せずに、パフォーマンスを向上させるリード・モディファイ・ライト・メモリーのパイプライン化方法を示しています。コヒーレント・リードと互換性のない M20K の機能を必要とするか、コヒーレント・リードを使用したくない場合、メモリーの fMAX 性能を向上させるために次の代替アプローチを使用してください。

• 1 つのクロックサイクルで完了することができる小さなブロックに変更操作を分解します。

• 各チャンクが 1 つの M20K メモリーブロックより広くないことを確認してください。データワードは複数の n ビット・チャンクに分割され、各チャンクは 1 クロックサイクルで効率的に処理できるほど十分に小さいです。

• f MAX を大きくするには、メモリーブロックの数を増やし、より狭いメモリーブロックを使用し、レイテンシーを増やします。レイテンシーを小さくするには、使用メモリーブロックを少なくし、パイプライン・ステージを適切に削除します。回路の性質のため、リード・モディファイ・ライトの回路上のループは避けられませんが、このソリューションのループは小さく、短くなっています。パイプライン・ステージの数に関係なく、基本構造が変更されないため、このソリューションは拡張性がありま。

2.4.2.6 カウンターとアキュムレータ

パフォーマンス制限ループは、小さな、単純なカウンターではめったに発生しません。不自然なロールオーバー条件（2 の累乗ではない）を持つカウンター、または不規則な増分を伴うカウンターは、パフォーマンスを制限するクリティカル・チェインを持つ可能性が高くなります。小さなカウンター（約 8 ビット以下）でパフォーマンス制限ループが発生する場合、カウンターを制御するすべての入力に応じて、完全にデコードされたステートマシンとしてカウンターを書き込みます。カウンターにはまだループが含まれていますが、パフォーマンスが制限されているわけではありません。カウンターが小さい場合（約 8 ビット以下）、フィッタは単一の LAB にカウンターを実装します。この実装は、すべてのロジックが近接して配置されるため、カウンターを高速化します。

ループ展開を使用してカウンターのパフォーマンスを向上させることもできます。



図 -54: カウンターおよびアキュムレータ・ループカウンターおよびアキュムレータ・ループでは、レジスターの新しい値は古い値に依存します。これには、LFSR（リニア・フィードバック・シフト・レジスター）やグレー・コード・カウンターなどのバリエーションが含まれます。

Counter

+1

Accumulator

2.4.2.7 ステートマシン

ステートマシンに関連するループは、適化するのが難しい場合があります。次のステートロジックで使用される信号を事前に計算できるかどうかを判断するために、ステートマシンロジックを注意深く調べます。

ステート・マシン・ループを効果的にパイプライン化するには、スキップステートをステートマシンに追加することを検討してください。スキップ状態は、隣接する 2 つの状態間の遷移時間を長くするために追加された状態です。

ステート・マシン・ループを適化するために、新しいステートマシンを書く必要が生じることがあります。

図 -55: ステート・マシン・ノードステート・マシン・ループでは、次の状態は回路の現在の状態に依存します。

S0

S1

S2S3

S4

関連情報• 111 ページの付録 A：パラメーター化可能パイプライン・モジュール

• 33 ページの事前計算

2.4.2.8 メモリー

このセクションでは、 Stratix 10 デバイスのハード・メモリー・ブロックの適化に関するさまざまなトピックについて説明します。



2.4.2.8.1 全二重デュアル・ポート・メモリー

Stratix 10 デバイスは真のデュアル・ポート・メモリー構造をサポートしています。真のデュアル・ポート・メモリーでは、2 回の書き込みと 2 回の読み出しが同時にできます。

Stratix 10 エンベデッド・メモリー・コンポーネント（M20k）は、リード/ライト・アクセス用の混在幅を含む従来の Intel FPGA テクノロジと比較して、動作モードがわずかに異なります。

Stratix 10 デバイスは、独立したクロックモードで真のデュアル・ポート・メモリーをサポートしていません。しかしながら、 Stratix 10 デバイスは、大 1GHz の動作周波数で、シングル・クロック・モードで真のデュアル・ポート・メモリーを完全にサポートします。

2.4.2.8.2 シンプル・デュアル・ポート・メモリー

Stratix 10 デザインを元のデザインに各ポートで異なるクロックを使用するデュアル・ポート・メモリーが含まれているかどうかを検討します。デザインが実際に両方の書き込みポートで同じクロックを使用している場合、2 つのシンプルなデュアル・クロック・メモリーを使用して再構成します。

この方法の利点は、シンプルなデュアルポートブロックが 1GHz までの周波数をサポートすることです。欠点は、メモリーを実装するのに必要なメモリーブロック数が倍増することです。

図 -56: Arria® 10 トゥルー・デュアル・ポート・メモリーのコンフィグレーション以前のバージョンの Quartus Prime プロ・エディションソフトウェアは、 Arria® 10 デバイスの真のデュアル・ポート・メモリー構造を生成します。。

例-8: デュアル・ポート、デュアル・クロック・メモリー実装

module true_dual_port_ram_dual_clock#(parameter DATA_WIDTH=8, parameter ADDR_WIDTH=6)( input [(DATA_WIDTH-1):0] data_a, data_b, input [(ADDR_WIDTH-1):0] addr_a, addr_b, input we_a, we_b, clk_a, clk_b, output reg [(DATA_WIDTH-1):0] q_a, q_b);

// Declare the RAM variable reg [DATA_WIDTH-1:0] ram[2**ADDR_WIDTH-1:0];

always @ (posedge clk_a) begin // Port A if (we_a) begin ram[addr_a] <= data_a; q_a <= data_a;



end else begin q_a <= ram[addr_a]; end end

always @ (posedge clk_b) begin // Port B if (we_b) begin ram[addr_b] <= data_b; q_b <= data_b; end else begin q_b <= ram[addr_b]; end end

endmodule

異なる書き込みクロックを使用するデュアル・ポート・メモリーを同期させることは困難です。両方のポートが同時に指定のアドレスに書き込まれないようにしてください。多くのデザインでは、デュアル・ポート・メモリーは、ポートの 1 つで書き込み動作を実行し、その後に両方のポート（1W2R）を使用して 2 つのみ出し動作を実行します。この動作は、2 つのシンプル・デュアル・ポート・メモリーを使用してモデル化できます。シンプル・デュアル・ポート・メモリーでは、書き込み動作は常に両方のメモリーに書き込み、読み出し動作はポートに依存します。

シンプル・デュアル・ポート・メモリーの例

2 つのシンプル・デュアル・ポート・メモリーを使用すると、デバイスの M20K ブロックを 2 倍にすることができます。しかしながら、このメモリー構造は 1GHz までの周波数で実行することができます。Stratix 10 デバイスで独立したクロックを持つ真のデュアル・ポート・メモリーを使用している場合、この周波数は不可能です。

図 -57: シンプル・デュアル・ポート・メモリーの実装



GUI のインスタンシエーションではなく、単純なデュアル・ポート・メモリーを RTL で推測することで、同様の周波数結果を得ることができます。

例-9: シンプル・デュアル・ポート RAM

module simple_dual_port_ram_with_SDPs#(parameter DATA_WIDTH=8, parameter ADDR_WIDTH=6)( input [(DATA_WIDTH-1):0] wrdata, input [(ADDR_WIDTH-1):0] wraddr, rdaddr, input we_a, wrclock, rdclock, output reg [(DATA_WIDTH-1):0] q_a);

// Declare the RAM variablereg [DATA_WIDTH-1:0] ram[2**ADDR_WIDTH-1:0];

always @ (posedge wrclock)begin // Port A is for writing only if (we_a) begin ram[wraddr] <= wrdata; endend

always @ (posedge rdclock)begin// Port B is for reading onlybeginq_a <= ram[rdaddr];endendendmodule

例-10: トゥルー・デュアル・ポート RAM の動作エミュレーション

module test (wrdata, wraddr, rdaddr_a, rdaddr_b, clk_a, clk_b, we_a, q_a, q_b); input [7:0] wrdata; input clk_a, clk_b, we_a; input [5:0] wraddr, rdaddr_a, rdaddr_b; output [7:0] q_a, q_b; simple_dual_port_ram_with_SDPs myRam1 ( .wrdata(wrdata), .wraddr(wraddr), .rdaddr(rdaddr_a), .we_a(we_a), .wrclock(clk_a), .rdclock(clk_b), .q_a(q_a) );

simple_dual_port_ram_with_SDPs myRam2 ( .wrdata(wrdata), .wraddr(wraddr), .rdaddr(rdaddr_b), .we_a(we_a), .wrclock(clk_a), .rdclock(clk_a), .q_a(q_b) ); endmodule



メモリー混合ポート幅比制限Stratix 10 デバイスブロック RAM は大 1GHz のクロックレートを可能にします。新しい RAM ブロックのデザインは、混合ポートデータ幅の使用に関してより制限的です。 Stratix 10 デバイスブロックRAM は 1/32、1/16、または 1/8 の混合ポート比をサポートしていません。有効な比率は、1、1/2、および 1/4 混合ポート比のみです。は無効な混合ポート比率を実装するためのエラー・メッセージを生成します。

Stratix 10 のために無効なポート幅比率を使用するデザインを移行する場合、RTL を変更して希望の比率を作成します。

図 -58: 1/8 混在ポート比との無効なデュアル・ポート・メモリー

Stratix 10 のために機能的に同等のデザインを作成するには、有効な混合ポート幅比を持つより小さいメモリーを作成し、組み合わせることができます。例えば、次の手順で混合ポート幅の比率を実装します。

1. IP Catalog から 2-Ports メモリー IP コアをインスタンス化することにより、1/4 の混合ポート幅比を持つ 2 つのメモリーを作成します。

2. 2 つのメモリー間のピンポン書き込みライト・イネーブル。・ロジックを定義します。

3. メモリーの出力をインターリーブして、1/8 比の出力を再構築します。

図 -59: 1/8 幅比の例

この例は、2 つのメモリーのインタリーブと書き込みロジックを示しています。選択された書き込みロジックは、書き込みアドレスの下位ビットを使用して、書き込むメモリーを決定します。偶数アドレスはメモリー mem_Aに書き込み、奇数アドレスはメモリーmem_Bに書き込みます。

メモリーへの書き込みを制御する方式のため、書き込み中に完全な 64 ビット出力を慎重に再構築します。 2 つのメモリー内の個々の 8 ビットワードのインターリーブを考慮する必要があります。



図 -60: メモリー出力デスクランブルの例

この例では、アドレス 0h0を読み出すときのデスクランブルされた出力を示しています。

次の RTL の例では、読み出し側のメモリーからデータをデスクランブルする余分なステージを実装しています。

例-11: トップレベル・デスクランブル RTL コード

module test #( parameter WR_DATA_WIDTH = 8, parameter RD_DATA_WIDTH = 64, parameter WR_DEPTH = 64, parameter RD_DEPTH = 4, parameter WR_ADDR_WIDTH = 6, parameter RD_ADDR_WIDTH = 4)( data, wraddress, rdaddress, wren, wrclock, rdclock, q);

input [WR_DATA_WIDTH-1:0] data;input [WR_ADDR_WIDTH-1:0] wraddress;input [RD_ADDR_WIDTH-1:0] rdaddress;input wren;input wrclock;input rdclock;output [RD_DATA_WIDTH-1:0] q;

wire wrena, wrenb;wire [(RD_DATA_WIDTH/2)-1:0] q_A, q_B;

memorySelect memWriteSelect ( .wraddress_lsb(wraddress[0]), .wren(wren), .wrena(wrena), .wrenb(wrenb));

myMemory mem_A ( .data(data), .wraddress(wraddress), .rdaddress(rdaddress), .wren(wrena), .wrclock(wrclock), .rdclock(rdclock), .q(q_A));



myMemory mem_B ( .data(data), .wraddress(wraddress), .rdaddress(rdaddress), .wren(wrenb), .wrclock(wrclock), .rdclock(rdclock), .q(q_B));

descrambler #( .WR_WIDTH(WR_DATA_WIDTH), .RD_WIDTH(RD_DATA_WIDTH)) outputDescrambler ( .qA(q_A), .qB(q_B), .qDescrambled(q));

endmodule

例-12: サポートされている RTL コード

module memorySelect (wraddress_lsb, wren, wrena, wrenb); input wraddress_lsb; input wren; output wrena, wrenb;

assign wrena = !wraddress_lsb && wren; assign wrenb = wraddress_lsb && wren;endmodule

module descrambler #( parameter WR_WIDTH = 8, parameter RD_WIDTH = 64) ( input [(RD_WIDTH/2)-1 : 0] qA, input [(RD_WIDTH/2)-1 : 0] qB, output [RD_WIDTH:0] qDescrambled);

genvar i; generate for (i=WR_WIDTH*2; i<=RD_WIDTH; i += WR_WIDTH*2) begin: descramble assign qDescrambled[i-WR_WIDTH-1:i-(WR_WIDTH*2)] = qA[(i/2)-1:(i/2)-WR_WIDTH]; assign qDescrambled[i-1:i-WR_WIDTH] = qB[(i/2)-1:(i/2)-WR_WIDTH]; end endgenerate

endmodule

2.4.2.8.3 レジスターされない RAM 出力

高の性能を達成するには、任意の組み合わせロジックでデータを使用する前に、メモリーブロックの出力をレジスターします。レジスターされていないメモリー出力を組み合わせロジックを直接駆動すると、不十分なレジスターによって特徴づけられるクリティカル・チェインが発生する可能性があります。

リード・ライト・ライトの新しいデータ・モードを使用して RAM をインプリメントすると、レジスターされないメモリー出力とコンビネーション・ロジックを無意識に使用できます。このモードは、読み出しおよび書き込みアドレスを比較するメモリーブロックの外部にあるソフトロジックで実装されます。このモードは、書き込みデータを出力に直接マルチプレクシングします。高のパフォーマンスを達成したい場合、read-during-write 新しいデータモードを使用しないでください。



2.4.2.9 DSP ブロック

DSP ブロックは 1GHz までの周波数をサポートします。ただし、入力レジスター、パイプライン・レジスターの 2 つのステージ、および出力レジスターを含むすべてのレジスターを使用する必要があります。

2.4.2.10 一般ロジック

構造的に健全な間に複数レベルのロジックを生成する 1 行のロジック関数を使用しないでください。唯一の例外は、どちらの側にも 2 つのパイプライン・レジスターを追加することで、Hyper-Retiming はロジックのクラウドを介してリタイミングできます。

2.4.2.11 モジュラスと除算

モジュラス演算子と除算演算子は、2 の累乗を使用しない限り、デバイス面積と速度性能の面でコストがかかります。可能であれば、モジュラス演算または除算演算子を避ける実装を使用してください。ラウンド・ロビンス・ケジューラのトピックでは、モジュラス演算子を単純なシフトに置き換えることで、パフォーマンスが大幅に向上しています。

関連情報104 ページのラウンド・ロビン・スケジューラ

2.4.2.12 リセット

エラー条件を検出し、リセット条件をパイプラインするために、監視ロジック内のループを持つ回路のリセットを使用します。

2.4.2.13 ハードウェアの再利用

ハードウェアの再利用によるループを解決するには、ループを展開します。

2.4.2.14 アルゴリズム要件

これらのループは改善するのが難しいかもしれませんが、「一般的な適化テクニック」のセクションで説明した適化手法を組み合わせることで恩恵を受けることがあります。

関連情報28 ページの一般的な適化手法

2.4.2.15 FIFO

FIFO には常にループが含まれます。優れた性能を提供する内部 FIFO ロジックを実装する効率的な方法があります。

一部の FIFO の 1 つの機能は、FIFO がエンプティーのときにデータが内部メモリーを完全にバイパスするバイパスモードです。いずれかの FIFO にこのモードを実装する場合、レジスターされていないメモリー出力に内在する可能性のあるパフォーマンス上の制限に注意してください。

関連情報51 ページのレジスターされない RAM 出力



3 Stratix 10 デザインのコンパイル

この章では、 Stratix 10 デバイスで Intel HyperFlex FPGA アーキテクチャを大限に活用するために Quartus PrimeCompiler を使用する方法について説明します。

Hyper-Aware のデザイン・フロー

Hyper-Aware のデザインフローを使用して、デザインサイクルを短縮し、パフォーマンスを適化します。 Hyper-Aware デザインフローでは、自動レジスターリタイミングと、目標とするタイミングクロージャーの推奨（Fast Forward のコンパイル）の実装を組み合わせて、Hyper-Register の使用を大限にし、 Stratix 10 デザインで高のパフォーマンスを実現します。

図 -61: Hyper-Aware のデザイン・フロー

Synthesis Plan EarlyPlace Place Route Retime*

Fast Forward*(Hyper-Retiming)RTL

*Stratix 10 only

optimizeoptimize optimize optimize optimize optimize

Finalize (Hold Fixup)

レジスターのリタイミング

Stratix 10 アーキテクチャの主な革新は、すべてのルーティング・セグメントとブロック入力に複数のHyper-Register タを追加することです。Hyper-Register の使用を大限にすると、デザインのパフォーマンスが向上します。Hyper-Register の蔓延は、レジスター間の時間遅延のバランスを改善し、クリティカル・パスの遅延を緩和します。Compiler の Retime ステージでは、レジスターを ALM から移動して、Hyper-Register にリタイミングします。レジスター・リタイミングは、Fitter 中に自動的に実行され、小限の労力を要し、大幅なパフォーマンス改善をもたらす可能性があります。リタイミング後、Finalize ステージでホールド違反による接続が修正されます。

Fast Forward のコンパイル

単純なレジスター・リタイミングよりも適化が必要な場合、Fast Forward コンパイルを実行して、タイミング収束の推奨事項を生成して、Hyper-Register へのさらなる移動を防ぐ重要なパフォーマンスのボトルネックを解消します。例えば、Fast Forward では、特定のリタイミング制約を削除して、Hyper-Register にさらにリタイミングすることを防ぐことを推奨しています。 Fast Forward Compilationは、RTL の変更にも大きな影響を与える位置を正確に示し、制限を解除して Hyper-Register（Hyper-Retiming）にリタイミングすることによる予測パフォーマンスのメリットを報告します。Fitterは、RAM ブロックと DSP ブロックのレジスターを自動的にリタイムしません。ただし、Fast Forward 分析では、この適化によるパフォーマンス上のメリットが示されます。

S10HPHB | 2017.05.08






図 -62: Hyper-Register のアーキテクチャー

ALM ALM

ALM ALM

New Hyper-Registers throughout the core fabricPotential routing path

clk ConfigurationSetting (CRAM)

Hyper-Register Detail

Fast-Forward のコンパイルは、パイプライン・ステージ（Hyper-Pipelining）を追加する適な位置と、それぞれのケースで期待されるパフォーマンスの利点を示します。各クロックドメインの境界にパイプライン・ステージを配置するように RTL を変更すると、 Retime ステージはクロックドメイン内のレジスターを適な位置に自動的に配置してパフォーマンスを大化します。同様の結果を得るために、RTLで推奨事項を実装します。変更を実装した後、結果がパフォーマンス要件およびタイミング要件を満たすまで、 Retime ステージを再実行します。

表 4. 適化のステップ

適化ステップ手法説明

ステップ 1: Register Retiming Retime ステージでは、既存のレジスターを Hyper-Register に移動します。

ステップ 2: Fast Forward Compile Compiler は、デザイン固有のタイミング収束の推奨事項を生成し、Hyper-Register（Hyper-Retiming）に対するすべての障壁を除去してパフォーマンスの向上を予測します。

ステップ 3: Hyper-Pipelining RTL で新しいレジスターとパイプライン・ステージを追加する位置を指定するには、Fast Forward コンパイルを使用します。

ステップ 4: Hyper-Optimization ループの再構築、コントロール・ロジックの制限の解除、ロングパスに沿った遅延の削減などの Hyper-Retiming や Hyper-Pipelining を超えたデザイン適化です。

注意: Stratix 10 Hyper-Optimization Advisor は、Fast Forward のコンパイルを実行し、Hyper-Optimization を実装するためのステップ・バイ・ステップの手順を提供します。Tools > Advisors >Stratix 10 Hyper-Optimization Advisor をクリックして、がアドバイスを表示します。

3.1 Hyper-Aware のデザインフローの実行

Hyper-Aware のデザインフローでは、レジスターのリタイミング機能と Fast Forward のコンパイルを組み合わせて、使用可能な Stratix 10 Hyper-Register の使用を大限に高めます。

3 Stratix 10 デザインのコンパイルS10HPHB | 2017.05.08


図 -63: Hyper-Aware のデザイン・フロー

No

Yes

Run Fitter with Retime Stage

AnalyzeTiming

FitterFinalize

Review Retiming Results

Performance Met?

Run Fast Forward Compile

Performance Met?

Recompile the Design

Yes No

Register Retiming

Fast Forward Compile

Run Design Synthesis

Review Recommendations

Modify RTL

Hyper-Aware のデザインフローには、この章で詳しく説明する次の上位レベルの手順が含まれています。

1. Fitter 中に Retime ステージを実行して、ALM レジスターを Hyper-Register に自動的にリタイムします。

2. コンパイルレポートのリタイミング結果を確認します。

3. さらにパフォーマンスの適化が必要な場合、Fast Forward のコンパイルを実行します。

4. Fast Forward タイミング収束の推奨事項を確認します。

5. RTL に適切な Fast Forward の推奨事項を実装します。

6. Retime ステージでデザインをリコンパイルします。

関連情報• 56 ページのステップ 1：レジスターのリタイミングを実行する

• 58 ページのステップ 2：リタイミング結果を確認する

• 60 ページのステップ 3：Fast Forward コンパイルと Hyper-Retiming の実行

• 62 ページのステップ 4：Hyper-Retiming の結果を確認する



• 65 ページのステップ 5：Fast Forward 推薦を実装する

3.1.1 ステップ 1：レジスターのリタイミングを実行する

レジスターのリタイミングは、 Stratix 10 デバイス・インタコネクトでレジスターを ALM から移動させてデザインのパフォーマンスを向上させ、レジスターを ALM から Hyper-Register にリタイムします。

Fitter は、 Stratix 10 デバイスをターゲットとしたときに位置とルートに沿って Retime ステージを自動的に実行します。または、Compilation Dashboard で個々の Retime ステージを開始または停止します。レジスターのリタイミングを実行した後、残りのクリティカルパスを適化するために Fitterレポートを表示します。

レジスターのリタイミングを実行するには：

1. デザイン合成とフィッティングの準備が整った Quartus Prime プロジェクト作成または開きます。

2. レジスターのリタイミングを実行するには、Compilation Dashboard で Retime をクリックします。Compiler は、必要に応じて自動的に前提条件ステージを実行します。Compiler は、各ステージの詳細なレポートとタイミング解析データを生成します。 Report または TimeQuest アイコンをクリックして、各ステージの結果を確認します。任意の設定やデザインの変更を適用するために、任意のステージを再実行します。

3. レジスターのリタイミングがデザインのすべてのパフォーマンス目標を達成した場合、コンパイルのFitter（Finalize）および TimeQuest タイミング解析段階に進みます。デザインにさらに適化が必要な場合、 Fast Forward Timing Closure Recommendations を実行します。

図 -64: Compilation Dashboard でのリタイミング・ステージ

Click to Run Flow



表 5. フィッター・ステージ・コマンド

コマンド説明

Fitter (Implement) Plan、Early Place、Place、Route および Retime ステージを実行します。このステージの後に隣接する TimeQuest アイコンをクリックして、タイミング収束に必要なタイミングコーナーのサブセットを分析します。

Start Fitter (Plan) 合成されたペリフェラル配置データと制約をロードし、ペリフェラル要素をデバイス I/O リソースに割り当てます。この段階の後、タイミング制約を検証し、ペリフェラル・タイミングをチェックし、クロス・クロックのタイミング・ウィンドウを検証するために、ポスト・プランのタイミング解析を実行できます。このコマンドは、Planned スナップショットを作成します。

Start Fitter (Early Place) コア・デザイン・ロジックをデバイスリソースに割り当てる作業を開始します。この段階の後、ChipPlanner は、デザイン要素の初期の高位配置を表示することができます。フロアプランの決定を導くためにこの情報を使用してください。このコマンドは、Early Placed スナップショットを作成します。Early Place は、完全なコンパイルフロー中に実行されません。

Start Fitter (Place) コア・デザイン・ロジックの配置をデバイスリソースに割り当てることができます。このコマンドは、配置されたスナップショットを作成します。

Start Fitter (Route) コア・ルーティングを実行します。この段階では、完全に配線されたデザインが作成され、遅延チェインの設定を検証し、ルーティング・リソースを分析します。この段階の後、TimeQuest TimingAnalyzer で詳細なセットアップおよびホールドタイミング収束を実行し、Chip Planner 経由でルーティングの輻輳を表示します。このコマンドは、Routed スナップショットを作成します。

Start Fitter (Retime) デザイン内の既存のレジスターを Hyper-Register にリタイミングして、リタイミング制約を削除し、クリティカル・パスを排除してパフォーマンスを向上させます。Compiler は、Retime ステージの後のショートパスのホールド違反を報告することがあります。Fitter は、パスに沿って配線ワイヤを追加することで、Fitter (Finalize)ステージでホールド違反のあるショートパスを特定して修正します。

Start Fitter (Finalize) タイミング収束後の位置と経路のプロセスを確定します。このコマンドは、Final スナップショットを作成します。また、Fitter は、経路変更を実行して、リタイミングから残っているショート・パス・ホールド違反を修正します。

3.1.1.1 レジスター・リタイミングの防止

デザイン・パフォーマンスの向上のためにレジスターの自動リタイミングをグローバルに防止する場合は、Prevent register retiming オプションをイネーブルにします。無効にすると、Compiler はレジスター境界を越えて組み合わせロジックを移動するレジスター・リタイミング適化を自動的に実行します。コンパイラは、デザイン・コンポーネントの全体的なロジックを維持し、各レジスタ間のデータパス遅延のバランスをとります。必要に応じて、Allow Register Retiming をデザインエンティティまたはインスタンスに割り当てて、デザインの特定の部分に対して Prevent register retiming をオーバーライドします。Assignments > Assignment Editor をクリックしてエンティティ・レベルおよびインスタンス・レベルの割り当てを指定するか、次の構文を使用して.qsf内で直接割り当てを実行します。

例-13: エンティティ abc のレジスター・リタイミングのディセーブル

set_global_assignment –name ALLOW_REGISTER_RETIMING ON

set_instance_assignment –name ALLOW_REGISTER_RETIMING OFF –to “abc|”

set_instance_assignment –name ALLOW_REGISTER_RETIMING ON –to “abc|def|”

例-14: エンティティ abc 内のレジスターを除く、デザイン全体のレジスターリタイミングを無効にする

set_global_assignment –name ALLOW_REGISTER_RETIMING OFF

set_instance_assignment –name ALLOW_REGISTER_RETIMING ON –to “abc|”

set_instance_assignment –name ALLOW_REGISTER_RETIMING OFF –to “abc|def|”



3.1.1.2 合成中にレジスターを保持する

Quartus Prime ゲートカウントを小化し、冗長ロジックをマージし、デバイスリソースの効率的な使用を保証します。合成処理によって特定のレジスターを保持する必要がある場合、次のエンティティ・レベルの割り当てを指定できます。 Preserve Resisters in Synthesis または Fan-Out FreeRegister Node を使用すると、保存されたレジスターの Fitter 適化が可能になります。Preserve Resisters は、保存されたレジスターの Fitter 適化を制限します。 .qsfファイルでのAssignments > Assignment Editor、または RTL の合成属性をクリックして、合成保存の割り当てを指定します。

表 6. 合成保存オプション

割り当て説明フィッターの適化の可用性

割り当ての構文

PreserveRegisters inSynthesis

合成時のレジスターの削除を防止します。この設定は、リッターやフィッターの他の適化には影響しません。

はい • PRESERVE_REGISTER_SYN_ONLY ON|Off-to <entity> (.qsf)

• preserve_syn_onlyまたはsyn_preservesyn_only （合成属性）

PreserveFan-Out FreeRegisterNode

合成中にファンアウトなしで割り当てられたレジスターの削除を防止します。

はい • PRESERVE_REGISTER_FANOUT_FREE_NODEON|Off -to <entity> (.qsf)

• no_prune on （合成属性）

PreserveResisters

合成中に割り当てられたレジスターの削除および順次適化を防止します。シーケンシャル・ネットリストの適化により、冗長レジスターとレジスターを一定のドライバで削除することができます。

いいえ • PRESERVE_REGISTER ON|Off -to<entity> (.qsf)

• preserve、 syn_preserve、または keep on（合成属性）

3.1.2 ステップ 2：リタイミング結果を確認する

Fitter は、Retime ステージの結果を示す詳細レポートを生成します。次の手順に従って、結果を確認し、レジスターのリタイミングを使用してパフォーマンスをさらに向上させます。

1. Retiming Limit Details レポートを開くには、Compilation Dashboard の Retime テージの Report アイコンをクリックします。リ Retiming Limit Details には、移動したレジスターの数、関連するパス、およびそれ以上のリタイミングを防止する制限理由が一覧表示されます。

2. さらに適化するには、デザインの Limiting Reason を解決し、必要に応じて Retime ステージを再実行します。

3. レジスターのリタイミングがデザインのすべてのパフォーマンス目標を達成すると、コンパイルのFitter（Finalize）および TimeQuest Timing Analysis のステージに進みます。

4. デザインにさらに適化が必要な場合、Fast Forward コンパイルを実行します。

表 7. リタイミング制限の詳細レポートデータ

レポートデータ説明

Clock Transfer デザイン内の各クロックドメインを一覧表示します。ドメインをクリックすると、各エントリに関するデータが表示されます。

Limiting Reason 更なるレジスター・リタイミング改善を防止する次のいずれかのデザイン条件を指定します。continued...



レポートデータ説明

• Insufficient Registers—リタイミング・チェインの両端に不十分な数のレジスターを示します。より多くのレジスターを追加すると、パフォーマンスが向上します。.

• Short Path/Long Path—クリティカル・チェインに、特性が相反する依存パスがあることを示します。たとえば、1 つのパスでより多くのレジスターでパフォーマンスを向上させて、別のパスで追加のレジスタを配置する位置がありません。

• Path Limit—クリティカル・パスで使用可能なハイパー・レジスターの位置がないこと、またはデザインが現在の位置とルートのパフォーマンス制限に達していることを示します。

• Loops—回路内のフィードバック経路を示します。クリティカル・チェインがフィードバック・ループを含む場合、リタイミングは、機能を変更することなくループ内のレジスターの数を変更することはできません。Compiler は機能を変更することなくループの周りをリタイムすることができますが、追加のレジスターをループに入れることはできません。

Critical Chain Details リタイミング制限に関連するレジスター・タイミング・パスを一覧表示します。Locate Critical Chain inTechnology Map Viewer の任意のパスを右クリックします。

図 -65: リタイミング制限の詳細

Reason Pathis Limited

Critical chainpath details

Right-click to locate in viewer

注意:

Compiler は、Retime ステージの後のショートパスのホールド違反を報告することがあります。Fitter は、パスに沿って配線ワイヤを追加することで、 Fitter (Finalize)ステージでホールド違反のあるショートパスを特定して修正します。

3.1.2.1 クリティカル・チェインの検索

Retiming Limit Details は、さらにレジスター・リタイミングを制限するデザインパスを報告します。任意のパスを右クリックして、Technology Map Viewer - Post-fitting のビューでパスに移動します。このビューアは、配置、配線、およびレジスター・リタイミング後に、完全なデザインの略図を表示します。Technology Map Viewer でリタイミングされたネットリストを表示するには、次の手順を実行します。

1. Retiming Limit Details レポートを開くには、Compilation Dashboard の Retime ステージの横にある Report アイコンをクリックします。

2. Retiming Limit Report レポートで任意のパスを右クリックし、Locate Critical Chain inTechnology Map Viewer をクリックします。ネットリストは、Technology Map Viewer のスケマティックとして表示されます。



図 -66: Technology Map Viewer

Schematic Viewof Design Netlist

レジスター・リタイミングは、レジスター・バンクを Hyper-Register に転送します。

図 -67: リタイミングした後の Post-Fit ViewerHyper-RegisterBypassed ALM Registers

Used ALM Register

3.1.3 ステップ 3：Fast Forward コンパイルと Hyper-Retiming の実行

Fast Forward コンパイルを実行すると、Compiler はレジスターから信号を予測的に削除し、後続のリタイミング用にネットリスト内のモビリティを許可します。Fast Forward コンパイルでは、デザイン固有のタイミング収束の推奨事項が生成され、すべてのタイミング制約が取り除かれて大のパフォーマン



スが予測されます。Fast Forward の調査を完了したら、も効果的なものを提供するために実装できる推奨事項を決定します。 RTL に適切な推奨事項を実装し、Fast Forward レポートのパフォーマンス・レベルを実現するためにデザインをリコンパイルします。

図 -68: Fast Forward コンパイルの実行

Fast Forward Flow

Fast Forward タイミング収束の推奨事項を生成するには、次の手順を実行します。

1. Compilation Dashboard で、Fast Forward Timing Closure Recommendations をクリックします。Compiler は、必要に応じて前提条件合成または Fitter ステージを自動的に実行し、Compilation Report でタイミング収束の推奨事項を生成します。

2. Compilation Report でタイミング収束の推奨事項を表示して、デザイン・パフォーマンスを評価し、重要な RTL パフォーマンスの改善を実装します。

3. 必要に応じて、Fast Forward 分析を自動化または詳細化する場合、次のオプションのいずれかを指定します。

• フフルコンパイル中に Fast Forward コンパイルを実行する場合は、Assignments >Settings > Compiler Settings > HyperFlex をクリックし、Run Fast ForwardTiming Closure Recommendations during compilation.をイネーブルにします。

• Fast Forward コンパイルが特定の I/O とブロックタイプをどのように解釈するかを変更する場合、 Assignments > Settings > Compiler Settings > HyperFlex >Advanced Settings をクリックします。



図 -69: HyperFlex の設定Run Fast ForwardDuring Compilation

Fast ForwardAdvanced Options

3.1.3.1 高度な HyperFlex 設定

Advanced HyperFlex Settings は、 Stratix 10 デザインで Fast Forward Compilation が特定のロジック構造の結果を分析し報告する方法を制御します。設定にアクセスするには、Assignments > Settings > HyperFlex > Advanced Settings をクリックします。

表 8. 高度な HyperFlex 設定

オプション説明

Fast Forward CompileAsynchronous Clears

Fast Forward 解析が非同期クリア信号を持つレジスターの占める割合を指定します。• Auto— Compiler は、Fast Forward Compilation 中にタイミング・パフォーマンスを制限するまで、非

同期クリアが非同期であるとみなし、その時点で削除されると見なします。• Preserve— Compiler は、Fast Forward 解析のために非同期クリアを削除または変換できると仮定し

ません。

Fast Forward CompileFully Registered DSPBlocks

Fast Forward 分析がパフォーマンスを制限する DSP ブロックをどのように考慮するかを指定します。このオプションをイネーブルにすると、すべての DSP ブロックが完全にレジスターされているかのように結果が生成されます。

Fast Forward CompileFully Registered RAMBlocks

Fast Forward 分析がパフォーマンスを制限する RAM ブロックをどのように考慮するかを指定します。完全にレジスターされたブロックを分析するには、このオプションをイネーブルにします。

Fast Forward CompileMaximum AdditionalPipeline Stages

Fast Forward コンパイルで探検するパイプライン・ステージの大数を指定します。

Fast Forward CompileUser Preserve Directives

Fast Forward コンパイルがユーザー保持ディレクティブの制限を処理する方法を指定します。

3.1.4 ステップ 4：Hyper-Retiming の結果を確認する

Fast Forward Compilation を実行した後、レポートをレビューして、デザイン機能とパフォーマンス目標に適しているかどうかを判断します。



3.1.4.1 Clock Setup Summary レポート

Clock Fmax Summary レポートは、Hyper-Retiming、Hyper-Pipelining、および Hyper-Optimization の各ステップの後、各クロックドメインで達成可能な現在の fmax および潜在的なパフォーマンスを報告します。 Clock Fmax Summary データを確認して、それぞれの潜在的な性能向上がデザイン RTL のさらなる調査と潜在的な適化を必要とするかどうかを判断します。

図 -70: Clock Fmax Summary での現在および潜在的なパフォーマンスPredicts Optimized Performance After

Hyper-Retiming, Hyper-Pipelining, and Hyper-Optimization

3.1.4.2 Fast Forward Details レポート

Fast Forward Details レポートでは、Fast Forward コンパイルのパフォーマンスレベルを達成するために必要なデザイン変更を推奨します。いくつかの推奨事項は、機能的に不可能であるか、またはデザインにとって実用的でない場合があります。同様のパフォーマンス向上を達成するために、RTL で実装できる推奨事項を検討してください。適化 Step をクリックすると、そのステップの実装の詳細とパフォーマンスの計算が表示されます。

図 -71: Fast Forward Details レポート



表 9. Fast Forward Details のレポートデータ

レポートフィールド説明

Step あらかじめ適化された Base Performance fMAX、推奨される Fast Forward 適化ステップ、およびさらに適化を妨げる Fast Forward Limit クリティカル・パスを表示します。

Fast Forward Optimizations Analyzed 各適化ステップを実装するために必要な適化を要約します。

Estimated Fmax すべての Fast Forward 適化ステップを実装した場合の潜在的な fMAX パフォーマンスを指定します。

Optimizations Analyzed For FastForward Step

選択した Step のデザイン推奨事項を階層的に一覧表示します。テキストをクリックすると、レポートが展開され、クロックドメイン、影響を受けるモジュール、変更が必要なバスとビットが表示されます。

Optimizations Analyzed (Cumulative) 選択した Step に達するのに必要なすべてのデザイン変更の累積リスト。

Fast Forward Limit 時のクリティカル・チェイン

Fast Forward のすべてのステップを適用した後でも Hyper-Retiming を制限し続けるパスに関する情報を表示します。クリティカル・チェインとは、それ以降の Hyper-Retiming を制限するパスのことです。このフィールドを表示するには、Fast Forward Limit ステップをクリックします。

クリティカル・チェインのための推奨事項リタイミング制限に関連するレジスタータイミングパスを一覧表示します。LocateCritical Chain in Fast Forward Viewer の任意のパスを右クリックします。

任意のパスを右クリックして、Fast Forward Viewer でクリティカル・チェインを探します。 FastForward Viewer には、すべての Fast Forward の推奨事項の実装後に、完全なデザインの予測表現が表示されます。

図 -72: クリティカル・チェインのための推奨事項

Remove remaining retiming restrictions



図 -73: Fast Forward Viewer でクリティカル・チェインの検索

Locate Critical Chain in Fast Forward Viewer

図 -74: Fast Forward Viewer で予測結果の表示

3.1.5 ステップ 5：Fast Forward 推薦を実装する

デザイン RTL で Fast Forward タイミング収束の推奨事項を実装し、 Retime ステージを再実行して、予測パフォーマンスの向上を実現します。



実装する変更の量と種類は、パフォーマンス目標に応じて異なります。例えば、単純な非同期クリア除去または変換を使用してターゲット fMAX を達成できる場合、変更を行った後にデザインの適化を停止できます。ただし、追加のパフォーマンスが必要な場合、次の手法のような Fast Forward の推奨事項を実装してください。

• 長いフィードバック・ループやステートマシンなど、コントロール・ロジックの制限を取り除きます。

• 長い組み合わせパフィードバックパスの代わりに、機能的に同等のフィードフォワードパスまたはプリコンピュートパスを使用するようにロジックを再構築します。

• チェイン内の「ロングパス」の遅延を削減します。遅延を削減するために標準のタイミング収束技術を使用してください。過度の組み合わせロジック、準適配置、ルーティング輻輳により、パスの遅延が発生します。

• チェイン内の「ロングパス」にさらにパイプライン・ステージを挿入します。ロングパスは、クリティカル・チェイン内のレジスター間でも遅延があります。

• 遅延を増加する（または、パイプライン・ステージをチェインの「ショートパス」に追加する）。

目的のパフォーマンス目標に達するまで、パフォーマンスを調査し、RTL のコード変更を実装します。

3.1.5.1 クリティカル・チェイン・レポートの解釈

Compiler は、デザイン内のレジスターチェインを識別し、Hyper-Retiming によるさらに適化を制限します。Compiler は、これらの関連するレジスター間パスをクリティカル・チェインと呼びます。クリティカル・チェインとそれに関連するクロックドメインの fMAX は、レジスター間パスの平均遅延と、ルーティング・ワイヤなどの不可分な回路エレメントの量子化遅延によって制限されます。 Retiming LimitDetails に、リタイミングをさらに防止する制限理由と、チェインを構成するレジスターおよび組み合わせノードが報告されています。Fast Forward の推奨事項には、重要なチェインを削除して追加のレジスターのタイミングを変更できる手順が記載されています。

図 -75: クリティカル・チェインのサンプルこの図では、赤い線は同じクリティカル・チェインを表しています。タイミング制限により、レジスター A のリタイミングが防止されます。タイミング制限により、レジスター B の逆方向のリタイミングも防止されます。ループは、レジスター A とレジスター B が同じレジスターである場合に発生します。

A B

Fast Forward の推奨事項は次のとおりです。

• チェイン内の「ロングパス」の遅延を減らします。遅延を削減するために標準的なタイミング収束ー技術を使用しますが、他の推奨事項も見るとより効果的です。パスは、あまりにも多くの組み合わせロジックから、または適ではない配置から、または他の理由の中でルーティング輻輳から遅延する可能性があります。

• チェイン内の「ロングパス」にさらにパイプライン・ステージを挿入します。ロングパスは、レジスター間の遅延がも大きいクリティカル・チェインの部分です。

• 遅延を増加します（または、パイプライン・ステージをチェインの「ショートパス」に追加する）。

クリティカル・チェインの特定のレジスターは、他の多くの理由でパフォーマンスを制限する可能性があります。



Compiler は、リタイミングによってさらに適化を制限する以下のタイプの理由を分類します。

• Insufficient Registers

• Loop

• Short path/long path

• Path limit

特定のクリティカル・チェインがデザインのパフォーマンスを制限する理由を理解したら、RTL を変更してボトルネックを解消し、パフォーマンスを向上させることができます。

3.1.5.1.1 不十分なレジスター

チェインの端にもないレジスターをリタイムすることができ、さらにレジスターを追加するとパフォーマンスが向上する可能性がある場合、報告される制限理由は Insufficient Registers です。

図 -76: Insufficient Registers として報告される制限理由

Insufficient Registers の例

以下のスクリーンショットは、Retiming Limit Details レポートとクリティカル・チェインに含まれるロジックの関連部分を示しています。

リタイミング制限の詳細レポートは、 clkという名前のクロックドメインのパフォーマンスが 1ns（1GHz fMAX ）のタイミング要件を満たしていないことを示しています。スラックは-1.311ns で、432.7MHz の fMAX に対応します。

図 -77: Retiming Limit Details



この回路は、入力レジスターの 1 ステージ、出力レジスターの 1 ステージ、および信号を経路指定する純粋に組み合わせロジックで実現される非効率なクロスバースイッチがあります。入力レジスターと出力レジスターには、非同期リセットがあります。クロスバーのマルチプレクサはパイプライン化されていないため、実装は非効率的であり、パフォーマンスは限られています。

図 -78: ポストフィット Technology Map Viewer のクリティカル・チェインクリティカル・チェインは、入力レジスターから組み合わせロジッククラウドを経て出力レジスターに送られます。クリティカル・チェインには、レジスター間パスが 1 つしかありません。

次の図の 1 行目は、Path Info カラムのタイミング制限を示しています。 37 行目にはリタイミング制限も記載されています。 2 つのレジスターの非同期リセットにより、リタイミング制約が発生します。

図 -79: Hyper-Retiming 時に不十分なレジスターが報告されたクリティカル・チェイン

次の表は、クリティカル・チェイン要素と Technology Map Viewer の例との間の相関関係を示しています。



表 10. Critical Chain Elements および Technology Map Viewer の相関

クリティカル・チェインレポートの行番号 Technology Map Viewer の回路要素

1-3. din_reg[33][0] source register and its output

4-14. FPGA routing fabric between din_reg[33][0] and Mux0~85, the first stage of mux inthe crossbar

15-17. Combinational logic implementing Mux0~85

18-20. Routing between Mux0~85 and Mux0~17, the second stage of mux in the crossbar


24-27. Routing between Mux0~17 and Mux0~33, the third stage of mux in the crossbar


30-33. Routing between Mux 0~33 and Mux0~68, the fourth stage of mux in the crossbar


36-37. dout_reg[76][0] destination register

重要なチェインレポートのページ 68 Register カラムにバイパス Hyper-Register をリストする 17行があります。バイパスされた Hyper-Register は、チェイン内にさらに多くのレジスターがある場合、またはエンドポイントに制限がない場合に使用する Hyper-Register の位置を示します。エンドポイントに制限がない場合、Compiler はエンドポイント・レジスターをリタイムするか、クリティカル・チェイン外の他のレジスターをクリティカル・チェインにリタイムすることができます。 RTL デザインにクロスバスイッチを介してさらに多くのレジスターが含まれている場合、リタイムすることができるレジスターがさらにあります。また、Fast Forward Compile プロセスは、より多くのレジスターを挿入してパフォーマンスを向上させることができます。

クリティカル・チェインレポートでは、2〜36 行目に Path Info カラムに「Long Path (Critical)」と表示されます。これは、パスが長すぎてリストされた周波数を超えることができないことを示します。「Long Path」の指定は、Short Path/Long Path タイプのクリティカル・チェインにも関連しています。詳細については、 Short Path/Long Path セクションを参照してください。 (Critical)指定は、クリティカル・チェインの 1 つのレジスター間セグメントに存在します。(Critical)指定は、レジスター間パスがクロックドメイン内でもクリティカルなタイミングパスであることを示します。

Join カラムには、1 行目に「＃1」、29 行目に「＃2」が含まれています。 Join カラムの情報は、より複雑なクリティカル・チェインの解釈に役立ちます。詳細は、Complex Critical Chains のセクションを参照してください。

Element カラムには、クリティカル・チェインの各ステップでの回路要素またはルーティング・リソースの名前が表示されます。次の図に示すように、名前を右クリックしてコピーするか、Locate オプションを使用しての他の部分にクロスプローブすることができます。



図 -80: クリティカルチェイン・レポートからのクロスプローブ

関連情報• 71 ページのショートパス/ロングパス

• 79 ページの複雑なクリティカル・チェイン

• 11 ページの Hyper-Retiming（レジスター移動を容易にする）

Insufficient Registers の適化

報告された不十分なレジスターによって制限されるクリティカル・チェインを解決するには、このドキュメントで説明する Hyper-Pipelining 技術を使用してください。

関連情報• 11 ページの Hyper-Retiming（レジスター移動を容易にする）


デュアル・クロック・メモリーを備えたクリティカル・チェイン

Hyper-Retiming は、デュアル・クロック・メモリーを介してレジスターをリタイムしません。したがって、デザイン上、2 つのデュアル・クロック FIFO またはメモリーの間にある機能ブロックが、Fast Forwardコンパイル後であっても不十分なレジスターの制限の理由でクリティカル・チェインとして報告される可能性があります。

限定理由が Insufficient Registers でチェインがデュアル・クロック・メモリー間にある場合、パイプライン・ステージを機能ブロックに追加できます。または、RTL にレジスターのバンクを追加し、Compilerでレジスターのバランスをとることができます。重要なチェインにソフトウェア設定でレジスターを導入する方法については、Pipeline Stages のセクションを参照してください。

FIFO メモリーが単一クロックであるため、2 つの単一クロック FIFO 間の機能ブロックはこの動作の影響を受けません。Compiler は、単一クロックメモリーにレジスターをリタイムすることができます。さらに、デュアルクロック FIFO とレジスターデバイス I/O 間の機能ブロックは、この動作の影響を受けません。これは、Fast Forward Compile がデバイス I/O のレジスターを介して機能ブロックにレジスターをプルできるためです。

関連情報111 ページの付録 A：パラメーター化可能パイプライン・モジュール



3.1.5.1.2 ショートパス/ロングパス

クリティカル・チェインに、競合する特性を持つ関連するパスがあり、1 つのパスがより多くのレジスターでパフォーマンスを向上させ、別のパスに追加のレジスターを配置できない場合、ショートパス/ロングパスが報告されます。

クリティカル・チェインは、Hyper-Retiming の適化の目標が競合している場合、ショートパス/ロングパスに分類されます。ショートパスとロングパスは、常に少なくとも 1 つの共通ノードを使用して何らかの方法で接続されています。リタイミングされたレジスターは機能上の正確さを維持し、両方のクリティカル・チェインを通じて同一の相対レイテンシーを保証する必要があります。この要件によって、適化の目標が競合する可能性があります。したがって、1 つのセグメント（ロングパス）はリタイミング移動を受け入れることができますが、もう 1 つのセグメント（ショートパス）はリタイミング移動を受け入れることができません。リタイミング動作は通常、追加のレジスターをショートパスとロングパスにリタイミングします。

クリティカル・チェインは、以下の理由により、ショートパス/ロングパスに分類されます。

• Hyper-Register の位置がショートパスで使用可能でなく、タイムアウトする場合。

• ロングパスのパフォーマンスを向上させるためにレジスターを両方のパスにリタイミングすると、ショートパスでの保持時間の要件を満たしません。ブロードキャスト・コントロール信号、同期クリア、およびクロックイネーブルなど、デザインで使用される回路構造の結果として、ショートパス/ロングパス・クリティカル・チェインが存在することがあります。

ショートパス/ロングパス・クリティカル・チェインは、ポストフィット・リタイミングに関連する新しい適化フォーカスです。従来のリタイミングでは、ネットリストの構造を合成または配置配線中に変更することができる。ただし、Hyper-Retiming 時には、ネットリスト構造、配置配線を変更できないため、ショートパス/ロングパスが発生する可能性があります。

Hyper-Register の位置が使用不可能

Fitter は、非常に近くにある重要なチェインセグメントに要素を配置するか、使用可能な Hyper-Register の位置がないように要素をルーティングします。クリティカル・チェイン・セグメント内のすべての Hyper-Register の位置が使用されている場合があります。

次の例では、ショートパスには 2 つの Hyper-Register の位置が含まれていますが、どちらも使用されています。 1 つはライン 38 に示され、もう 1 つはライン 41 に示される。ライン 38 および 41 はRegister カラムに REG を示します。Element カラムの名前は_dffで終わり、その位置の Hyper-Register が使用中であることを示します。 _dffは D フリップフロップを表します。そのチェインセグメントで使用できる他の Hyper-Register 位置はありません。使用可能な Hyper-Register の位置は、Register カラムにバイパスされた Hyper-Register のエントリがあることを示します。 45 行目はHyper-Register ではありません。これは ALM レジスターです。

図 -81: 使用可能な Hyper-Register 位置を持たないクリティカル・チェイン・ショートパス・セグメント



保留適化の例

次の例の 3 行目で、Register カラムに使用できないことが示されます（ホールド）。3 行目に示されているように、rmm|Mux4~0 の組み合わせノードに対して、dataeの LUT 入力に使用可能な Hyper-Register 位置があります。ただし、3 行目に示すようにホールド時間要件を満たしていないため、それは使用できません。1 行目のレジスターを前方にリタイムすることはできず、7 行目のレジスタを後方にリタイムすることはできません。

図 -82: ショートパス/ロングパスのクリティカル・チェイン

ショートパス/ロングパスの適化Fast Forward の推奨事項を評価して、ショートパス/ロングパスの制約によるパフォーマンスの制限を適化します。

レジスターの追加

クリティカル・チェインで余分なレイテンシーを調整できる場合、ショートパスとロングパスの両方にレジスターを手動で追加すると便利です。

図 -83: 交替するショートパス/ロングパスを持つクリティカル・チェイン

Cannot RetimeForwards Dueto Short Path

Long Path (LP)

Short Path (SP)

Legend

Cannot RetimeBackwards Dueto Short Path



4 つのチェインセグメントにレジスターを追加すると、Compiler はクリティカル・チェインを適化できます。 RTL で追加のレジスターを使用できる場合、Compiler はその位置を適化できます。

図 -84: 追加のレイテンシー付きのショートパス/ロングパスの例

Long Path (LP)

Short Path (SP)

Legend

Manually Added

重複する共通ノード

ショートパス/ロングパス・クリティカル・チェインに同じレジスターから発生する共通セグメントが含まれている場合、レジスターを複製して、1 つの複製がショートパスを送り、1 つの複製がロングパスをフィードするようにできます。

図 -85: 交替するショートパス/ロングパスを持つクリティカル・チェイン

Cannot RetimeForwards Dueto Short Path

Long Path (LP)

Short Path (SP)

Legend

Cannot RetimeBackwards Dueto Short Path



図 -86: 2 つの重複ノードを有するショートパス/ロングパス

Long Path (LP)

Short Path (SP)

Legend

Duplicated Nodes

Fitter は、新しく独立したセグメントを個別に適化することができます。複製されたレジスターは共通のソース自体を持っているため、完全に独立しているわけではありませんが、クリティカル・チェインの各部に独立したレジスターを追加すれば、適化が容易になります。

大ファンアウト合成ディレクティブを共通ソースレジスターに適用することができます。値が 1 より大きい場合、回避しようとした同じソースノードを持つショートパス・セグメントとロングパス・セグメントが発生する可能性があるため、値を 1 に設定します。

あるいは、ショートパス/ロングパス・クリティカル・チェインで共通ソースレジスターを手動で複製する場合、合成命令を使用して複製レジスターを保持してください。そうしない場合、合成中に複製がマージされることがあります。合成命令を使用して重複レジスターを保持すると、予期しないリタイミング制限が発生する可能性があるため、大ファンアウト命令を使用する方がよい場合があります。

データとコントロール・プレーン

場合によっては、ロングパスがデータプレーンにあり、ショートパスがコントロール・プレーンにあることがあります。データパスにレジスターを追加する場合、コントロール・ロジックを変更してください。これは時間のかかるプロセスになります。コントロール・ロジックがデータパスのクロックサイクル数に基づいている場合、増加したデータを処理するために使用されるサイクル数に対応するために、データパスにレジスターを追加し（ロングパス）、コントロール・ロジック（ショートパス）のカウンター値を変更することができます。

3.1.5.1.3 Fast Forward 制限

クリティカルパスで使用可能な Hyper-Register の位置がなくなり、デザインがより高速に実行されたり、リタイミングされたりすることができない場合、クリティカル・チェインにはパスリミットの制限理由があります。パス制限は、現在の位置とルートの結果のパフォーマンス限界に達したことを示します。

次の図に示すように、クリティカル・チェインは、ハード・メモリー・ブロックから、ハード・メモリー・ブロック外で使用可能な初の Hyper-Register に移動します。ソースがハード・メモリー・ブロックであるという事実は、ライン 1、2 および 3 上の名前の一部から推論することができます。ライン 1 および 2 は、ram_block1a0を参照します。そして、ライン 3 には、メディアが埋め込まれたアレイブロック配線エレメントを参照する MEDIUM_EAB_REが含まれています。メディアが埋め込まれたアレイブロッククは、 Stratix 10 デバイスのハード・メモリー・ブロックの 1 つです。



図 -87: Fast Forward 制限時のクリティカル・チェイン

クリティカル・チェインがパスリミットの場合、Path Info カラムにロングパスが表示されます。これは、チェインが長すぎることを示し、Hyper-Retiming がレジスターをチェインにリタイムすることができれば速くなる可能性があります。 Register カラムにバイパスされた Hyper-Register とマークされたエントリーは、使用可能な Hyper-Register の位置がないことを示します。

Path Limit の制限理由は、クリティカル・チェインが固有のシリコン性能限界に達したことを意味するものではありません。現在の位置とルートの結果に報告されたパフォーマンスの制限があることを意味します。別のコンパイルでは、Hyper-Retiming が特定のクリティカル・チェインでより優れたパフォーマンスを達成できるように異なる配置が行われる可能性があります。パス制限の一般的な理由の 1 つは、レジスターがハード DSP または RAM ブロックの専用入力または出力レジスターにパックされていない場合です。

パス制限の適化

Fast Forward 推薦を評価します。クリティカル・チェインが Path Limit の制限理由を持っていて、コアロジックと配線エレメントに完全に含まれている場合、Intel FPGA ファブリックでは、コア・ファブリックの大パフォーマンスでデザインを実行できます。クリティカル・チェインが Path Limit の理由が限定されており、DSP ブロックまたはハード・メモリー・ブロックを経由する場合、パス制限を適化することによってパフォーマンスを向上させることができます。

パスリミットを適化するには、DSP ブロックとハード・メモリー・ブロック用のオプションの入出力レジスターをイネーブルにします。オプションの入出力レジスターを DSP ブロックおよびメモリーブロックに使用しない場合、オプションのレジスターの位置は Hyper-Retiming には使用できず、クリティカル・チェインにバイパスされた Hyper-Register として表示されません。パス制限は、オプションの入力または出力レジスターを使用しないパスのシリコン限界です。オプションの入力レジスターと出力レジスターをイネーブルにすることで、パフォーマンスを向上させることができます。

オプションのレジスターをオンにして、IP パラメーターエディタを使用して、ハード DSP またはメモリーブロックのパラメーターを設定します。 DSP またはメモリー機能が RTL から推測される場合、ハードブロックのオプションの入力および出力レジスターが使用されるように、 Recommended HDL CodingStyles スタイルで説明されている推奨コーディング・スタイルに従ってください。Compiler は、DSP およびハード・メモリー・ブロック・レジスターとの間でリタイムしません。したがって、パフォーマンスを大にするためにオプションのレジスターをインスタンス化することが重要です。

重要なチェインが真のデュアル・ポート・メモリーが含まれている場合、技術を適化するための TrueDual-Port Memory を参照してください。

関連情報• 推奨 HDL コーディング・スタイル

• 46 ページの全二重デュアル・ポート・メモリー



https://www.altera.co.jp/documentation/mwh1409960181641.html#mwh1409959570946

3.1.5.1.4 ループ

ループは、回路内のフィードバック経路です。回路がパイプライン化されている場合、ループはレジスターのリタイミングによってデザイン fMAX を増加させるための限定理由になることがよくあります。ループは非常に短い (単一のレジスターのみを含む) または (多数のレジスタとの組合せロジック雲を含む)非常に長い可能性があります。1/2 分周のコンフィグレーションのレジスターは短いループです。

図 -88: シンプルループ

ToggleFlipFlop

クリティカル・チェインがフィードバック・ループである場合、ループ内のレジスターの数は、機能を変更せずにレジスターのリタイミングによって変更することはできません。リタイミングは機能を変更することなくループの周りで実行できますが、追加のレジスターをループに入れることはできません。パフォーマンスの向上を探求するため、Fast Forward Compile プロセスは、クロックドメインの境界など、回路の特定の境界にレジスターを追加します。

図 -89: FIFO フロー・コントロール・ループFIFO フロー・コントロール・ループでは、FIFO が満杯になると上流処理が停止し、FIFO が空になると下流処理が停止します。

DataProducer

FIFO

FIFO Full

図 -90: カウンターおよびアキュムレータ・ループカウンターおよびアキュムレータ・ループでは、レジスターの新しい値は古い値に依存します。これには、LFSR（リニア・フィードバッ・シフト・レジスター）やグレーコードカウンターなどのバリエーションが含まれます。

Counter

+1

Accumulator



図 -91: ステート・マシン・ノードステート・マシン・ループでは、次の状態は回路の現在の状態に依存します。

S0

S1

S2S3

S4

図 -92: リセット回路ループリセット回路ループでは、エラー状態になった場合にリセットするための監視ロジックが含まれています。

CombinationalLogic

ループを使用して、ハードウェアの再使用によって領域を節約します。数サイクルにわたって再使用されるコンポーネントには、通常、ループが含まれます。例えば、再使用されるコンポーネントには、CRC 計算、フィルター、浮動小数点除算、ワードアライナなどがあります。ループは、IIR フィルターやリモート・ラジオヘッドのデザインにおけるトランスミッター電力のオート・ゲイン・コントロールなどの閉ループ・フィードバック・デザインでも使用されます。

制限理由としてのループを持つクリティカル・チェインの例

次のスクリーンショットは、Fast Forward Details レポートとクリティカル・チェインに含まれるロジックの関連パネルを示しています。



図 -93: Hyper-Optimization の限定理由を示す Fast Forward Details レポートはループである

次の図では、開始点と終了点の結合 ID は同じです（＃1）。この場合、チェインの開始点と終了点が同じであることを示し、ループを作成します。

図 -94: Hyper-Retiming 中にループが報告されたクリティカル・チェイン

図 -95: Technology Map Viewer のクリティカル・チェインRetryCnt [0]レジスターの出力は、2 つのレベルの組み合わせロジックを介してイネーブル入力にフィードバックされます。RetryCnt [0]レジスターのロジックコーンへの他の入力は明確には示されていませんが、次のソースコードは MAC_tx_ctrlソースの一部と RetryCntレジスターへの入力の一部を示しています。

例-15: クリティカル・チェインのソースコード

StateJam:if (RetryCnt<=MaxRetry&&JamCounter==16) Next_state=StateBackOff;else if (RetryCnt>MaxRetry)



Next_state=StateJamDrop;else Next_state=Current_state;

always @ (posedge Clk or posedge Reset) if (Reset) JamCounter <=0; else if (Current_state!=StateJam) JamCounter <=0; else if (Current_state==StateJam) JamCounter <=JamCounter +1;

always @ (posedge Clk or posedge Reset) if (Reset) RetryCnt <=0; else if (Current_state==StateSwitchNext) RetryCnt <=0; else if (Current_state==StateJam&&Next_state==StateBackOff) RetryCnt <=RetryCnt +1;

3.1.5.2 クリティカル・チェインレポートの詳細

以下のトピックは、あらゆるタイプのクリティカル・チェインに適用されます。

3.1.5.2.1 クロックドメインごとに 1 つのクリティカル・チェイン

Hyper-Retiming は、Critical Chains in Related Clock Groups でカバーされている特殊なケースを除いて、クロックドメインごとに 1 つのクリティカル・チェインをレポートします。Fast Forward コンパイルを実行する場合、Hyper-Retiming レポートには、Fast Forward 適化ステップごとにクロックドメインごとに 1 つのクリティカル・チェインが表示されます。 Hyper-Retiming では、1 つのチェインだけがクリティカル・チェインであるため、クロックドメインごとに複数のクリティカル・チェインは報告されません。

潜在的な適化については、デザイン内の他のチェインで検討してください。Fast Forward コンパイルレポートの各ステップで他のチェインを表示します。レポートの各ステップは、非同期クリアの削除や変換、パイプライン・ステージの追加などの一連の変更をテストし、その変更に基づいてパフォーマンスをレポートします。

関連情報79 ページの関連するクロックグループのクリティカル・チェイン

3.1.5.2.2 関連するクロックグループのクリティカル・チェイン

2 つ以上のクロックドメインがまったく同じタイミング要件を持ち、ドメイン間にパスがあり、クロックドメイン境界のレジスターに Do not Touch 属性がない場合、Hyper-Retiming は Related ClockGroup のためにクリティカル・チェインを報告します。クリティカル・チェインタイプの適化手法は、関連するクロックグループのクリティカル・チェインにも適用されます。

3.1.5.2.3 複雑なクリティカル・チェイン

複雑なクリティカル・チェインは、複数のジョインポイントで接続された複数のセグメントで構成されています。結合点は、Fitter レポートの結合列に正の整数で示されます。結合点は、クリティカル・チェインのセグメントの端にリストされ、セグメントが発散または収束する位置を示します。結合点は、チェインがテキストベースの行指向のレポートにリストされているときにチェインセグメント間の接続を示します。結合点は、回路内の要素に対応し、他の要素にどのように接続してクリティカル・チェインを形成しているかを示します。



次の例は、次の表のサンプルクリティカル・チェインを使用して、結合ポイントが回路接続にどのように対応しているかを示しています。

表 11. サンプルクリティカル・チェイン

Path Info Register Join Element

REG #1 a

b

REG #2 c

------------ ------------ ------------ ------------

REG #3 d

e

REG #2 c

------------ ------------ ------------ ------------

REG #3 d

f

REG #4 g

------------ ------------ ------------ ------------

g

h

a

図 -96: サンプル・クリティカル・チェインの視覚的表現図の各円には、要素名とクリティカル・チェインテーブルからのジョインポイント番号が含まれています。

d#3

g#4

a#1

c#2



図 -97: 複雑なクリティカル・チェインクリティカル・チェインには、数十の結合点が含まれます。以下に示す複雑なクリティカル・チェインには 35 の結合点があります。

長いクリティカル・チェインでは、適化のためにクリティカル・チェインの小さな部分を特定します。デザインをリコンパイルし、クリティカル・チェインの変更を分析します。クリティカル・チェインの一部に適化作業を集中させる他の方法については、 Optimizing Loops を参照してください。

3.1.5.2.4 配置可能ノードの拡張

クリティカル・チェインでは、「検索可能ノードに拡張する」というパス情報エントリが表示される場合があります。これは、クリティカル・チェインのノードと RTL のデザイン名を関連付けることができる便利な機能です。

クリティカル・チェイン・レポートのすべてのラインが RTL ファイルのデザインエントリ名に対応するわけではありません。例えば、個々のルーティング・ワイヤは、RTL 内の名前と相関関係がありません。通常、これは問題ではありません。なぜかというと、近くまたは隣接する行の別の名前が RTL ファイル内の名前に対応し、その名前に移動可能なためです。クリティカル・チェイン・レポートの行に、RTL ファイル内で検索できる近接または近接の行がない場合があります。これはジョインポイントでも頻繁に発生します。これが起こると、クリティカル・チェイン・セグメントは、必要に応じて RTL ファイルに配置できるラインに到達するまで拡張されます。

3.1.5.2.5 ドメイン境界エントリとドメイン境界出口

Path Info カラムには、クリティカル・チェインのドメイン境界エントリまたはドメイン境界出口が表示されます。ドメイン境界エントリおよびドメイン境界出口は、制約されていないパス、非同期クロックドメイン間のパス、またはクロックドメインと上位レベルのデバイス入出力間のパスを指します。一部のフォールス・パスについても、ドメイン境界のエントリと終了を示すことができます。



ドメイン境界エントリは、Hyper-Pipelining がイネーブルになっている場合、Hyper-Retiming がレジスターステージ（レイテンシーがクロックドメインに入ることができる位置）を挿入できるクロックドメイン境界のデザイントポロジ内のポイントを指します。ドメイン境界エントリの概念は、データフローの方向とは無関係です。Hyper-Retiming は、モジュールの入力にレジスターステージを挿入し、順方向リタイミングプッシュを実行し、モジュールの出力にレジスターステージを挿入し、逆方向リタイミングを実行することができます。これらの挿入は、ドメイン境界エントリポイントで行われます。

ドメイン境界出口とは、クロックドメインの境界でデザイントポロジ内のポイントを指します。Hyper-Retiming によってレジスターステージが削除され、Hyper-Pipelining がイネーブルになっている場合、レイテンシーがクロックドメインを終了できます。レジスターを削除することは、直感的ではないかもしれません。ただし、Hyper-Retiming によって実行される他の適化に応じて、機能上の正確さを保持する必要があります。

次の図に示すように、レジスターされていない I/O に組合せロジックを提供するレジスター間パスがある場合、クリティカル・チェインがドメイン境界のエントリまたは出口を示すことがあります。

図 -98: レジスターされていない入出力を持つドメイン境界

CombinationalLogic

レジスター間パスは、Hyper-Retiming の制限方法に応じて、ドメイン境界エントリまたはドメイン境界出口を持つクリティカル・チェインセグメントとして表示される場合があります。レジスターされていない入力は、入力がレジスターされていないため、Hyper-Retiming がドメイン境界にレジスターステージを挿入することを防止します。同様に、レジスターされていない入力は、Hyper-Retiming がドメイン境界でレジスター段を削除するのを防ぐこともできます。

ドメイン境界出口を持つクリティカル・チェインは、クロックドメインからレジスターをリタイミングすることを防止する要因を特定するための完全な情報を提供しません。レジスターがリタイムできない理由を識別するには、デザインを見直して、ドメイン境界出口に関連するレジスターの反対側に接続する信号を識別します。

ドメイン境界エントリおよびドメイン境界出口は、クリティカル・チェインで独立して現れることがあります。これらは、ドメイン境界エントリのないドメイン境界出口、またはクリティカル・チェインの始めと終わりのドメイン境界エントリなどの組み合わせでも表示できます。

次のクリティカル・チェインは、ドメイン境界の入力を開始して終了します。ドメイン境界エントリは、上位のデバイス I/O に接続する入出力レジスターです。入力レジスターはround_robin_mod_last_rで、出力レジスターは round_robin_mod_nextです。

図 -99: ドメイン境界を持つクリティカル・チェイン回路図

ベースコンパイルの制限理由は、Insufficient Registers です。



図 -100: Insufficient Registers で Fast Forward コンパイルレポート

クリティカル・チェインレポートの次の部分では、エンドポイントにドメイン境界エントリのラベルが付けられています。

図 -101: ドメイン境界エントリを持つクリティカル・チェイン

Hyper-Pipelining がイネーブルになっている場合、Fast Forward Compile によってこれらの境界にレジスターステージが挿入される可能性があるため、入力レジスターと出力レジスターの両方がDomain Boundary Entry として示されます。ベースコンパイルのクリティカル・チェインには、FastForward 適化が含まれていないため、チェインへの入力またはチェインの出力のいずれにも、追加のレジスターステージは挿入されません。

同じ回路内の同様のパスには、Fast Forward 適化の 2 つのステップの後に報告されたクリティカル・チェインの Domain Boundary Exit として示されているエンドポイントがあります。次のスクリーンショットは、Fast Forward ステップ＃2 の制限理由が Short path / Long path であることを示しています。

図 -102: ショートパス/ロングパスによる Fast Forward コンパイルレポート



3.1.5.2.6 デュアル・クロック・メモリーを備えたクリティカル・チェイン

Hyper-Retiming は、デュアル・クロック・メモリーを介してレジスターをリタイムしません。したがって、デザイン上、2 つのデュアル・クロック FIFO またはメモリーの間にある機能ブロックが、Fast Forwardコンパイル後であっても不十分なレジスターの制限の理由でクリティカル・チェインとして報告される可能性があります。

限定理由が Insufficient Registers でチェインがデュアル・クロック・メモリー間にある場合、パイプライン・ステージを機能ブロックに追加できます。または、RTL にレジスターのバンクを追加し、Compilerでレジスターのバランスをとることができます。重要なチェインにソフトウェア設定でレジスターを導入する方法については、Pipeline Stages のセクションを参照してください。

FIFO メモリーが単一クロックであるため、2 つの単一クロック FIFO 間の機能ブロックはこの動作の影響を受けません。Compiler は、単一クロックメモリーにレジスターをリタイムすることができます。さらに、デュアルクロック FIFO とレジスターデバイス I/O 間の機能ブロックは、この動作の影響を受けません。これは、Fast Forward Compile がデバイス I/O のレジスターを介して機能ブロックにレジスターをプルできるためです。


3.1.5.2.7 クリティカル・チェインビットとバス

デザインのクリティカル・チェインには、一般に、より広いバスまたはレジスターバンク内の単一ビットであるレジスターが含まれています。このような重要なチェインを分析するときは、単一ビットに関連する構造を分析せずに、バス全体に焦点を合わせます。例えば、512 ビットバスのビット 10 を参照するクリティカル・チェインは、おそらく、バス内のすべてのビットについて同様の構造に対応します。このアプローチに役立つテクニックは、[10]のような各ビット・インデックスを[*]に精神的に置き換えることです。

クリティカル・チェインが異なるスライスが異なるロジックを通過するバス内のレジスターを含む場合、クリティカル・チェインでどのレジスターが報告されるかに基づいて、適切なスライスに分析を集中させます。

3.1.5.2.8 ディレイライン

いくつかのクロックサイクルでバスを遅延させるパラメーター化されたモジュールがあるかもしれません。この種の構造は、合成中に ALTSHIFT_TAPS Megafunction に変換されることもあります。次のスクリーンショットは、遅延モジュールが ALTSHIFT_TAPS Megafunction に変換されたクリティカル・チェインの一部を示しています。右端の強調表示されたセクションは、 altshift_taps：r_rtl_0のデザイン階層を示し、合成がレジスターバンクを ALTSHIFT_TAPS IP コアで置き換えることを示します。 ALTSHIFT_TAPS IP コアの一部が、クリティカル・チェインセグメントの分類をショートパスにします。

図 -103: 遅延線によるクリティカル・チェイン・レポート



Fitter は、レジスターのチェインを互いに近づけて配置するので、Fitter が中間の Hyper-Register のいずれかの位置を使用する場合、ホールド時間に達することができません。レジスターのバンクのAuto Shift Register Replacement をオフにすると、合成が ALTSHIFT_TAPSMegafunction を使用できなくなり、おそらくそのクリティカル・チェインのショートパス部分を解決することになります。

RAM ベースの FIFO 実装がレジスター遅延線の代用として許容されるかどうかを検討してください。ディレイラインの 1 つの機能が、信号をチップ全体にわたって遠くに移動させるためのパイプライン配線である場合、RAM ベースの実装は、一般的に許容可能な代替ではありません。 RAM ベースの実装は、チップ間で長距離移動する必要がなければ、データバスを遅延させるコンパクトな方法です。

3.1.5.3 リタイミングの制限と対処方法

このセクションでは、リタイミング制約を回避するために使用できる RTL デザイン手法について説明します。リタイミング制限を引き起こすさまざまな状況があります。リタイミング制約は、ハードウェア特性、ソフトウェア動作のために存在するか、またはデザインに固有のものです。

表 12. さまざまなデザイン条件に対する Hyper-Register のサポート

デザイン条件 Hyper-Register のサポート

Initial conditions that cannot be preserved Hyper-Register は初期条件をサポートしています。ただし、すべてのレジスターの初期条件ステージ（つまり、Hyper-Register のマージおよび複製）を保持しながら、リタイミング操作を実行することはできません。このような状況がデザインで発生した場合、関係するレジスターはリタイムされません。これにより、レジスターのリタイミングがデザイン機能に影響を与えないことが保証されます。

Register has an asynchronous clear Hyper-Register は、データおよびクロック入力のみをサポートします。Hyper-Register には、非同期クリア、プリセット、イネーブルなどのコントロール信号がありません。非同期クリアを持つレジスターは、Hyper-Register にリタイムすることはできません。非同期クリアは、ステートマシンやコントロール・ロジックなど、必要なときにのみ使用してください。多くの場合、データパスの大部分から非同期クリアを回避または削除することができます。

Register drives an asynchronous signal このデザイン条件は、非同期リセットを使用するデザインに固有のものです。非同期クリアでリセットされるレジスターの数を削減することに重点を置いてください。

Register has don’t touch or preserveattributes

Compiler は、これらの属性を持つレジスターをリタイムしません。 Preserve 属性を使用して高いファンアウト信号のレジスター複製を管理する場合、preserve 属性を削除してみてください。Compiler は、それぞれの宛先への各ルーティング・パスに沿って高いファンアウトレジスターをリタイムすることができます。あるいは、 dont_merge属性を使用します。Compiler は、ALM、DDIO、シングルポート RAM、および DSP ブロックにレジスターをリタイムします。

Register is a clock source このデザイン条件は一般的ではありません。特に、デザインのパフォーマンスに重大な影響を与える部分については、まれです。このリタイミング制限が必要な性能を達成できない場合、PLL がレジスターではなくクロックを生成できるかどうかを検討してください。

Register is a partition boundary この条件は、デザインパーティションを使用するデザインに固有です。このリタイミング制約により、必要なパフォーマンスを達成できない場合、Hyper-Retiming のパーティション境界内にレジスターを追加してください。

Register is a block type modified by anECO operation

この制限は一般的ではありません。 ECO を実行するのではなく、デザインソースの機能的な変更を行い、リコンパイルすることによって制限を回避してください。

Register location is an unknown block この制限は一般的ではありません。指定したブロックタイプに隣接して余分なレジスターを追加することで、この条件を回避することができます。

Register is described in the RTL as a latch Hyper-Register はラッチを実装できません。 RTL コーディングの問題（不完全な割り当てなど）のために、ラッチが推測されることがあります。ラッチを実装しない場合、RTL を変更してください。

Register location is at an I/O boundary すべてのデザインに I/O が含まれていますが、Hyper-Retiming の I/O 境界の隣にパイプライン・ステージを追加することができます。

continued...



デザイン条件 Hyper-Register のサポート

Combinational node is fed by a specialsource

この状態は珍しく、特にデザインの性能重視の部分では珍しいことです。

Register is driven by a locally routed clock Hyper-Register は、専用のクロックネットワークによってのみクロックされます。ルーティング・ファブリックを使用してクロック信号を配信することは珍しいことですが、特にデザインのパフォーマンス重視の部品です。代わりに小さなクロック領域を実装することを検討してください。

Register is a timing exception end-point Compiler は、SDC 制約のソースまたはデスティネーションであるレジスターをリタイムしません。

Register with inverted input or output この状態はまれです。

Register is part of a synchronizer chain Fitter はシンクロナイザ・チェインを適化して平均故障間隔（MTBF）を増加させます。そして、Compiler はシンクロナイザ・チェインの一部として検出またはマークされたレジスターをリタイムしません。シンクロナイザー・チェインに隣接するクロックドメインの境界にさらにパイプライン・ステージを追加して、Hyper Retimer に柔軟性を提供します。

Register with multiple period requirementsfor paths that start or end at the register(cross-clock boundary)

この状況は、レジスターが 1 つの周波数でクロックのデータをラッチし、別の周波数で動作するレジスターにファンアウトする任意のクロスクロック境界で発生します。Compiler は、クロスクロック境界でレジスターをリタイムしません。リタイミングに柔軟性を持たせるために、クロックドメイン境界の一方の側または他方の側にパイプライン・ステージを追加することを検討してください。

関連情報18 ページのタイミングの検討事項

3.1.5.4 Finalize ステージのレポート

Finalize ステージのレポートには、次のような終的な配置とルーティング操作が記述されています。

• ディレイチェインのサマリー情報

• ポストルートは修正データを保持します。Compiler は、Retime ステージの後のショートパスのホールド違反を報告することがあります。Fitter は、パスに沿って配線ワイヤを追加することで、Fitter (Finalize)段階でホールド違反のあるショートパスを特定して修正します。



図 -104: Finalize ステージのレポート



4 HyperFlex の移植のガイドライン

この章では、 Stratix V または Arria 10 デザインを HyperFlex FPGA アーキテクチャに移行するためのガイドラインを示します。これらのガイドラインを使用すると、デザインの機能上の意思を維持しながら、 Stratix 10 HyperFlex アーキテクチャでのデザイン適化の利点を迅速に評価できます。

移植では、デザインを少し変更する必要がありますが、デザイン上も重要なモジュールのパフォーマンスを大幅に向上させることができます。

パフォーマンスの調査を試すには、ペリフェラル IP（トランシーバー、メモリーなど）を含まない大規模な第 2 レベルのモジュールを移行用に選択します。パフォーマンスの調査中に、報告されたパフォーマンスの改善をレビューします。

4.1 デザインの移行とパフォーマンスの調査

Stratix V または Arria 10 デザインを Stratix 10 デバイスに移行して、パフォーマンスの改善を評価することができます。 Stratix 10 デバイスのデザインを移行するには、マイナーな変更が必要です。ただし、追加の不要な変更は、劇的なパフォーマンスの改善に役立ちます。この速度の向上は、タイミングを短縮したり、柔軟性を提供してデザインに機能を追加するのに役立ちます。

必要なデザインは、デバイスのアップグレードと同様に変更されます。これらの変更には、PLL、高速 I/Oピン、およびその他のデバイス・リソースの更新が含まれます。これらの Stratix 10 コンポーネントのバージョンは同じ一般的な機能を持ちます。しかし、 Stratix 10 コンポーネントには、より高い動作速度を可能にする機能が含まれています。

• DSP ブロックはパイプライン・レジスターを追加し、浮動小数点モードをサポートしています。

• メモリーブロックは、コヒーレンシーのための追加のロジックと、幅に関連するいくつかの制限を持っています。

移行プロセスの上位レベルの手順は次のとおりです。

1. 特別な IP を使用せずに、デザイン内の下位ブロックを移行するために選択します。

2. 特別な IP コンポーネントをブラックボックスに入れ、選択した現在のレベルに必要なコンポーネントだけを保持します。コア性能評価のために、次の主要ブロックのみを保持してください。

• PLLs for generating clocks

• コア・ブロック（ロジック、レジスター、メモリー、DSP）

1. • 注意:

Quartus Prime ソフトウェアの以前のバージョンからデザインを移行する場合、現在のソフトウェア・バージョンと互換性がないか、または使用できない場合、いくつかのコンポーネントを交換する必要があります。

S10HPHB | 2017.05.08






1. コンポーネントのブラックボックス化する場合、モジュールのポート定義を維持します。単にプロジェクトからソースファイルを削除しないでください。

2. デザインで使用するすべてのコンポーネントのポート定義と方向を合成ソフトウェアに指定します。ポートの定義に失敗すると、コンパイルエラーが発生します。

3. デザインの合成中に、エラーメッセージを確認し、不足しているポート/モジュール定義を修正します。

モジュールをブラックボックス化するも簡単な方法は、機能的なコンテンツを空にすることです。以下は、Verilog HDL または VHDL のどちらを使用しているかに応じてブラックボックスのコンテンツの例です。

4.1.1 Verilog HDL モジュールのブラックボックス化

Verilog HDL のブラックボックス化では、モジュールの定義は保持しますが、機能の説明は削除してください。

変更前：

// k-bit 2-to-1 multiplexermodule mux2tol (V, W, Sel, F); parameter k = 8; input [k-1:0] V, W; input Sel; output [k-1:0] F; reg [k-1:0] F;

always @(V or W or Sel) if (Sel == 0) F = V; else F = W;endmodule

変更後：

// k-bit 2-to-1 multiplexermodule mux2tol (V, W, Sel, F); parameter k = 8; input [k-1:0] V, W; input Sel; output [k-1:0] F;endmodule

4.1.2 VHDL モジュールのブラックボックス化

VHDL のブラックボックス化では、エンティティをそのまま保ちますが、アーキテクチャーは削除してください。複数のアーキテクチャーを使用している場合、それらをすべて削除してください。

変更前：

-- k-bit 2-to-1 multiplexerLIBRARY ieee ;USE ieee.std_logic_1164.all ;

ENTITY mux2tol ISGENERIC ( k : INTEGER := 8) ; PORT ( V, W : IN STD_LOGIC_VECTOR(k-1 DOWNTO 0) ; Sel : IN STD_LOGIC ; F : OUT STD_LOGIC_VECTOR(k-1 DOWNTO 0) ) ;END mux2tol ;

4 HyperFlex の移植のガイドラインS10HPHB | 2017.05.08


ARCHITECTURE Behavior OF mux2to1 ISBEGIN PROCESS ( V, W, Sel ) BEGIN IF Sel = '0' THEN F <= V ; ELSE F <= W ; END IF ; END PROCESS ;END Behavior ;

変更後：

-- k-bit 2-to-1 multiplexerLIBRARY ieee ;USE ieee.std_logic_1164.all ;

ENTITY mux2tol ISGENERIC ( k : INTEGER := 8) ; PORT ( V, W : IN STD_LOGIC_VECTOR(k-1 DOWNTO 0) ; Sel : IN STD_LOGIC ; F : OUT STD_LOGIC_VECTOR(k-1 DOWNTO 0) ) ;END mux2tol ;

ARCHITECTURE Behavior OF mux2to1 ISBEGINEND Behavior ;

ブラックボックス・モジュールに加えて、モジュールを空のデザインパーティションに割り当てる必要があります。パーティションは、合成中にブラックボックス化されたモジュールに接続されたロジックが適化されないようにします。

新しいパーティションを作成するには：

1. Project Navigator Hierarchy タブで、ブラックボックス化されたモジュールを右クリックし、Design Partition > Set as Design Partition をクリックします。

2. Empty の場合は Yes を選択します。

3. すべてのブラックボックスモジュールをこのパーティションに追加します。

図 -105: 新しい空のパーティションの作成



4.1.3 クロック管理

適切なロジックをブラックボックス化した後、デザイン内のすべてのレジスターにクロック信号が受信されていることを確認します。すべての PLL はまだ存在していなければなりません。ブラックボックス化されたモジュールが存在するクロックを特定します。これがデザインで発生した場合、このクロックを再作成してください。クロックを再作成しないと、ダウンストリームのすべてのレジスターがクロック解除されたものとしてマークされます。クロックを受信しないレジスターは合成によって削除できるため、デザインのロジック機能が変更されます。 .sdcファイルのクロック定義を調べて、ブラックボックス化されたモジュールのいずれかにクロックが作成されているかどうかを調べます。特定のモジュールでは、いくつかのケースを起こる可能性があります。

• そのモジュールにはクロック定義があります。

— Does the clock signal reach the primary output of the module and a clock pinof a register downstream of the module?

• No: このクロックは完全に内部的なものであり、何の処置も必要ありません。

• Yes: そのモジュールの出力ピンに.sdcの定義に一致するクロックを作成してください。

• そのモジュールにはクロック定義がありません。

— Is there a clock feedthrough path in that module?

• No: 必要な処置はありません。

• Yes: モジュールのフィードスルー出力ピンに新しいクロックを作成してください。

4.1.4 ピン･アサインメント

ブラック・ボックスグ・ロジックは、ピン配置の問題を引き起こす可能性があります。ピンの割り当てを解決するには、次のガイドラインを使用してください。

• 高速通信入力ピンの再割り当て

は、高速ピンの状態をチェックし、これらのピンがデザイン内で接続されていないとエラーを生成します。トランシーバをブラックボックス化すると、このような状況に陥ることがあります。これらのエラーに対処するには、HSSI ピンを標準 I/O ピンに再割り当てします。必要に応じて I/O バンクを確認して変更してください。

図 -106: 高速ピン・エラー・メッセージ

.qsfファイルの場合、次のように変換されます。

set_instance_assignment –name IO_STANDARD “2.5 V” –to hip_serial_rx_in1set_instance_assignment –name IO_STANDARD “2.5 V” –to hip_serial_rx_in2set_instance_assignment –name IO_STANDARD “2.5 V” –to hip_serial_rx_in3set_location_assignment IOBANK_4A –to hip_serial_rx_in1set_location_assignment IOBANK_4A –to hip_serial_rx_in2set_location_assignment IOBANK_4A –to hip_serial_rx_in3



図 -107: ピンのエラーメッセージ

ぶら下がりピン

ブラックボックス化コンポーネントのために高速 I/O ピンが垂れている場合、それらを仮想ピンに設定します。以下のように、この割り当てをアサインメント・エディタまたは qsfファイルに直接入力することができます。

set_instance_assignment –name VIRTUAL_PIN ON –to hip_serial_tx_in1set_instance_assignment –name VIRTUAL_PIN ON –to hip_serial_tx_in2set_instance_assignment –name VIRTUAL_PIN ON –to hip_serial_tx_in3

GPIO ピン

GPIO ピンがある場合、この qsf割り当てを使用して仮想ピンにします。

set_instance_assignment VIRTUAL_PIN –to *

4.1.5 トランシーバー・コントロール・ロジック

デザインには、ロジックを制御するいくつかのコンポーネントがあります。例えば、トランシーバのリセット機能を制御する小さなデザインがあります。これらのブロックは上位デザインのままにしておき、そのロジックを適化することができます。



4.1.6 期限の切れた IP コアのアップグレード

Quartus Prime ソフトウェアはデザイン時に時代遅れの IP コンポーネントを警告します。ブラックボックス化されていない限り、すべての古い IP コンポーネントを新バージョンにアップグレードします。

1. 新バージョンにコンポーネントをアップグレードするには、Project > Upgrade IPComponents をクリックしてください。

2. 自動アップグレードをサポートする 1つまたは複数の IP コアをアップグレードするには、IP コアのAuto Upgrade]オプションをオンにし、Perform Automatic Upgrade をクリックします。アップグレードが完了すると、Status と Version カラムが更新されます。任意の IP コアで提供されるデザインの例は、IP コアをアップグレードするたびに自動的に再生成されます。

3. 個別の IP コアを手動でアップグレードするには、IP コアを選択して Upgrade in Editor（または単に IP コア名をダブルクリック）をクリックします。パラメーター・エディタが開き、パラメーターを調整して IP コアの新バージョンを再生成することができます。

注意:

Stratix 10 デバイスにはいくつかの IP コンポーネントでアップグレードできません。これらのコンポーネントがクリティカルな場合（例えば、PLL）、デザインを変更して、 Stratix 10 互換性のある IP コンポーネントで置き換えてください。

4.2 トップレベル・デザインの考慮事項

I/O 制約

レジスターのリタイミングから大限のパフォーマンスを引き出すには、レジスターリングに上位レベルをラップし、SDC ファイルから次の制約を削除します。

• set_input_delay

• set_output_delay

これらの制約は、与えられたクロック周期のどれくらいの時間がブロック自体の外部で使用されるかをモデル化します。デザイン適化の効果を分析する目的で、ブロック自体の中で使用可能なすべての余裕を使用することができます。これは、モジュールレベルでのパフォーマンスを大限にするのに役立ちます。これらの制約は、フルチップタイミング収束に移行するときに追加することができます。

リセット

リセット生成をデザインから削除する場合、デザインの入力ピンに直接接続して置換信号を提供してください。このコンフィグレーションは、 Stratix 10 アーキテクチャーのリタイミング機能に影響を与える可能性があります。リセット信号にいくつかのパイプライン・ステージを追加します。これにより、Compilerがリセット入力とレジスタの初のレベルを適化することができます。



特殊ブロック

リタイミングは、一部のコンポーネントを自動的には変更しません。いくつかの例は、DSP ブロックとM20K ブロックです。リタイミングによってより高いパフォーマンスを達成するには、これらのブロックを手動でリコンパイルします。次の条件を探します。

• DSP：パイプラインの深さを監視します。より多くのパイプライン・ステージにより、より高速なデザインが可能になります。リタイミングが DSP ブロックのロジックレベルによって制限されている場合、さらにパイプライン・ステージを追加します。

• M20K：リタイミングはレジスターの存在に大きく依存してロジックを移動します。メモリーを 2 回レジスターすることによって、M20K ブロックを使用すると、を支援することができます。

— 一回目は直接 M20K ブロックの内部に入力する

— 2 回目はブロックのピンでのファブリック内に入力する

ブロックのレジスター

ブロックのすべての入力とすべての出力をレジスターします。このレジスターリングは、完全なデザインに埋め込まれたときにブロックが駆動される方法を模倣します。このリングはまた、入力/出力に接続されたレジスターに関連するリタイミング制約も回避します。レジスターの初と後のレベルは、現実的にリタイムできるようになります。



5 デザイン例ウォークスルー

Median Filter のデザイン例は、Hyper-Retiming と Fast-Forward のコンパイルが実際のデザインでどのようにパフォーマンスを向上させるかを示しています。このウォークスルーでは、プロジェクトのセットアップ、デザインのコンパイル、結果の解釈、および RTL の適化について説明します。

図 -108: メジアンフィルター操作図

P1 P2 P3 FilterP4

FilterP1

FilterP2

FilterP3

I(x,y)

P1 P2 P3

FilterP4

O(x,y)

O(x,y)

Stage 1

Stage 2

5.1 メジアンフィルタのデザイン例

このウォークスルーでは、画像処理のメディアン・フィルター・デザインを使用して、Fast Forward コンパイルと Hyper-Retiming を使用する方法を示します。メディアン・フィルターは、画像からインパルス性ノイズを除去する非線形フィルターです。これらのフィルターは高の性能を必要とします。デザイン要件は、ファクトリ・フロアでリアルタイム画像処理を実行することです。 (1)

注意: Intel は、このウォークスルー用のデザイン例とプロジェクトをサポートしています。このドキュメントで使用可能なサポートする median.zipファイルをダウンロードしてください。使用するファイルを解凍し、すべてのプロジェクトファイル、制約ファイル、デザインファイル、RTL の例など、検証済みの完全なデザイン例を参照してください。

(1) このメジアンフィルターのデザインは、2002 年にポルトガル、リスボンで第 10 回地中海コントロールとオートメーションの会議で「An FPGA-Based Implementation for Median Filtering Meeting the Real-TimeRequirements of Automated Visual Inspection Systems」と題された論文で初めて発表されました。フリーソフトウェア財団が公表した GNU General Public License の下で公開されています。

S10HPHB | 2017.05.08






図 -109: メディアン・フィルタリングで処理された画像の前後

5.1.1 ステップ 1：プロジェクトを設定する

次の手順に従って、Median Filter デザイン・サンプル・プロジェクトをセットアップします。デザイン例プロジェクトには、デザインを推進する単一のクロック・シングルを定義する median.sdcファイルが含まれています。デザイン例では、このクロック定義をデザイン全体で使用しています。

1. Median Filter のデザイン例をダウンロードして抽出します。

2. Quartus Prime Pro v17.1 Stratix 10 ES エディションソフトウェアで median.qsfを開きます。

3. Assign > Device をクリックし、次のデバイス割り当て設定を確認します。

• Device family: Stratix 10 (GX/SX).

• Device: 1SG280LN3F43E1VG (Advanced)

4. サンプルデザインのすべての I/O は「仮想」ピンとして設定されています。つまり、実際のデバイスピンに実際には接続しません。これらの仮想ピンの状態を表示するには、 Assignments >Assignment Editor をクリックします。

5. Compiler は、フルコンパイル時にデフォルトで Retime および Fast Forward のコンパイルステージを実行します。これらの設定を確認するには、 Assignments > Settings > HyperFlexをクリックします。

6. Tools > TimeQuest Timing Analyzer をクリックします。すべてのクロックを定義し、1GHz のクロック周波数要件を指定します。 TimeQuest はこれらの設定を Synopsys DesignConstraints（ .sdc ）ファイルに保存します。また、 .sdcファイルを手動で作成することもできます。

7. Assignments > Assignment Editor をクリックし、すべてのピンに Virtual Pin オプションを割り当てます。

5 デザイン例ウォークスルーS10HPHB | 2017.05.08


図 -110: HyperFlex の設定Run Fast ForwardDuring Compilation

Fast ForwardAdvanced Options

5.1.2 ステップ 2：Fast Forward コンパイルを実行する

Fast Forward コンパイルはフルコンパイル中に実行されるか、またはプロセスを個別に実行することができます。 Fast Forward Compile の前に、前のコンパイル段階でデザインを正常に実行する必要があります。

1. 編集ダッシュボードで、Fast Forward Timing Closure Recommendations をクリックします。Compiler は、Fast Forward コンパイルによってすべてのモジュールを順番に実行します。

2. Compilation Report の Fast Forward Timing Closure Recommendations フォルダで分析を表示します。

5.1.3 ステップ 3：Fast Forward 推奨を表示する

Compiler は、レジスターのリタイミングと Fast Forward のコンパイルに続いて詳細なレポートを生成します。Fitter Report の Retime Stage セクションでリタイミングの結果を表示します。 FastForward 分析の結果を Fast Forward Timing Closure Recommendations レポートで表示します。

5.1.4 ステップ 4：Fast Forward 推奨を実装する

Fast Forward コンパイルでは、特定のパスのパフォーマンスを向上させるための手順を推奨します。Fast Forward の推奨事項を検討し、デザインの RTL を適切に変更してから、デザインをリコンパイルしてパフォーマンスを向上させてください。



実装する変更の量と種類は、パフォーマンス目標に応じて異なります。例えば、単純な非同期クリア除去または変換を使用してターゲット MAX を達成できる場合、適化は終了できます。ただし、追加のパフォーマンスが必要な場合、次の手法のような Fast Forward の推奨事項を実装してください。

• ロング・フィードバック・ループやステートマシンなどのコントロール・ロジックの制限を取り除きます。

• ロング・コンビナトリアル・フィードバックパスではなく、機能的に同等のフィードフォワードパスまたはプリコンピュートパスを使用するようにロジックを再構築します。

• チェイン内の「ロングパス」の遅延を削減します。遅延を削減するために標準のタイミング収束技術を使用してください。過度の組み合わせロジック、準適配置、ルーティング輻輳により、パスの遅延が発生します。

• チェイン内の「ロングパス」にさらにパイプライン・ステージを挿入します。ロングパスは、クリティカル・チェイン内のレジスター間でも遅延があります。

• 遅延を増加します（または、パイプライン・ステージをチェインの「ショートパス」に追加する）。

目的のパフォーマンス目標に達するまで、パフォーマンスを調査し、RTL のコード変更を実装します。

デザイン例では、非同期信号の存在（デザインでのリセット）がリタイミング能力に影響します。リセットを渡す開始点として、リセットが同期していることを確認してください。このドキュメントの RTL ガイドラインには、適切なリセット戦略が記載されています。

図 -111: ステートマシン RTL の非同期リセット



図 -112: ステートマシン RTL の非同期リセット

同期リセットが変更された後も、デザイン例にはパイプラインレジスターの追加ステージの恩恵を受けることができます。Fast Forward Details レポートには、これらのレジスターを追加する特定の位置が一覧表示されます。パスのソースまたは宛先のいずれかにレジスターを追加します。 Fitter は自動的に適な配置を選択します。

図 -113: Fast Forward コンパイルの改善

RTL ループは、fMAX 性能に影響を与えるも重要な要因の 1 つです。この制限の詳細については、Fast Forward Details レポートを参照してください。レポートには、ループ内のパスとすべての収束ポイントが一覧表示されます。ループのサイズによっては、レポートから視覚化するのが難しい場合があ



ります。 Right-clicking > Locate Critical Chain をクリックして、クリティカル・チェインを視覚化します。Technology Map Viewer は、コンビネーションロジックを雲のアイコンで抽象化します。「+」の記号をクリックしてこのロジックを展開します。

図 -114: Fast Forward 詳細

報告書に示されているように、ループにはレジスターの window_column_counterが含まれています。 RTL を見直して変更することで、パフォーマンスを向上させることができます。



図 -115: 適化されていない RTL

window_column_counterは、複数の条件文の中でいくつかの算術演算を実行することに注意してください。しかし、条件テストは一定であり、一度計算することができます。また、各クロックでwindow_column_counter + 1をあらかじめ計算することもできます。この手法は、クリティカル・チェインループ内の算術演算を回避し、if-then-else ステートメント内の結果を単に選択します。この戦略は、より効率的な実装をもたらす。



図 -116: 適化された RTL

RTL を変更したら、 Processing > Start Compilation をクリックしてデザインをコンパイルします。非同期リセット条件の修正、パイプライン・ステージの追加、および大きなループの回避は、FastForward ステップ＃2（Hyper-Pipelining）でこのデザイン例のパフォーマンスを 1152 MHz に大幅に向上させます。



図 -117: Fast Forward Details 詳細のレポート



6 適化の例

このセクションには、ラウンド・ロビン・スケジューラ適化の例が含まれています。

6.1 ラウンド・ロビン・スケジューラ

ラウンド・ロビン・スケジューラは基本機能ブロックです。次の例では、モジュラス演算子を使用して、サービスの次のクライアントを決定します。モジュラス演算子は、除算を実行するため、比較的遅く、領域が非効率的です。

例-16: ラウンド・ロビン・スケジューラのソースコード

モジュールはレジスターリングでインスタンス化され、コンパイルされます。

module round_robin_modulo # ( parameter LOG2_CLIENTS = 3, parameter CLIENTS = 7) { // previous client to be serviced input wire [LOG2_CLIENTS -1:0] last,

// Client requests:- input wire [CLIENTS -1:0] requests,

// Next client to be serviced: - output reg [LOG2_CLIENTS -1:0] next,

};

//Schedule the next client in a round robin fashion, based on the previous

always @*begin integer J, K;

begin : find_next next = last; // Default to staying with the previous for (J = 1; J < CLIENTS; J=J+1) begin K = (last + J) % CLIENTS; if (requests[K] == 1'b1) begin next = K[0 +: Log2_CLIENTS]; disable find_next; end end // of 'find_next' end

endmodule

S10HPHB | 2017.05.08






図 -118: ラウンド・ロビン・スケジューラの Fast Forward Compile レポート

Fast Forward Summary レポートは、クリティカル・チェイン上の Hyper-Retiming を制限するレジスターが不十分であることを示しています。チェインは、LPM_DIVIDE IP コアで実装されたモジュラス演算子を介して、後の入力に接続するレジスターから、次の出力に接続されているレジスターまでです。

図 -119: ラウンド・ロビン・スケジューラの基本パフォーマンスのクリティカル・チェイン

上のクリティカル・チェインの 66 個のエレメントは、下の回路図に対応し、13 レベルのロジックを備えています。モジュラス演算子は、低パフォーマンスに大きく貢献します。 13 レベルのロジックのうち 9 つは、モジュラス演算子の実装の一部です。

図 -120: クリティカル・チェインの回路図

Fast Forward コンパイルは、モジュール入力で 2 つのパイプライン・ステージを追加し、ロジッククラウドでリタイミングすることにより、70％のパフォーマンス向上を見積もります。この時点で、クリティカル・チェインはショートパス/ロングパスであり、モジュラス演算子を含みます。

6 適化の例S10HPHB | 2017.05.08


図 -121: ラウンド・ロビン・スケジューラのクリティカル・チェインファストフォワードコンパイル

モジュラス演算の除算器は、RTL 修正が必要なボトルネックです。 Fast Forward コンパイルのすべてのステップでクリティカル・チェインにディバイダのパスが存在します。サービスする次のクライアントを計算し、モジュラス演算子を回避するための代替実装を検討してください。クライアントの数を 2 の累乗として指定する実装に切り替えると、モジュラス演算子は、次に処理するクライアントを決定する必要はありません。 2 n より小さいクライアントでモジュールをインスタンス化するときは、未使用の要求入力をロジック 0 に関連付けます。

例-17: 2 n クライアント入力によるパフォーマンスの向上したラウンド・ロビン・スケジューラのソースコード

module round_robin # ( parameter LOG2_CLIENTS = 3, parameter CLIENTS = 2**LOG2_CLIENTS) { // Previous client to be serviced:- input wire [LOG2_CLIENTS -1:0] last, // Client requests:-

6 適化の例S10HPHB | 2017.05.08


input wire [CLIENTS -1:0] requests, // Next client to be serviced:- output reg [LOG2_CLIENTS -1:0] next };

//Schedule the next client in a round robin fashion, based on the previous always @(next or last or requests) begin integer J,K; begin : find_next next = last; // Default to staying with the previous for (J=1; J<CLIENTS; J = J+1) begin K = last + J; if (requests[k]0 +: LOG2_CLIENTS]] == 1'b1) begin next = K[0 +: LOG2_CLIENTS]; disable find_next; end end end// of 'find_next' end

endmodule

Fast Forward の適化がなくても、このラウンドロビンの実装は、モジュラス演算子を使用した速のFast Forward コンパイル結果よりも約 15％高速に実行されます。

図 -122: 2n クライアント入力によるパフォーマンスの向上したラウンド・ロビン・スケジューラの FastForward Summary レポート

Fast Forward の適化（基本パフォーマンスステップ）がなければ、このバージョンのクリティカル・チェインでは、レジスターが不十分であるというパフォーマンス制限の理由もあります。両方のバージョンのクリティカル・チェインには 2 つのレジスターのみが含まれていますが、2n バージョンのクリティカル・チェインにはモジュラスバージョンの 66 個の要素と比較して 38 個の要素しか含まれていません。

6 適化の例S10HPHB | 2017.05.08


図 -123: パフォーマンスの向上したラウンド・ロビン・スケジューラのクリティカル・チェイン

上のクリティカル・チェインの 38 個の要素は、次の回路図に対応し、論理レベルは 4 つのみです。

図 -124: パフォーマンスが向上したクリティカル・チェインの回路図

入力に 2 つのレジスター段を追加して、ロジッククラウドを介してリタイミングすることにより、FastForward Compile は回路性能を 1 GHz にします。これは Stratix 10 デバイスのアーキテクチャーの限界です。モジュラス・バージョンと同様に、ファスト・フォワード適化後の終的なクリティカル・チェインは、ショートパス/ロングパスという限定理由がありますが、パフォーマンスはモジュラス・バージョンの 2 倍です。

6 適化の例S10HPHB | 2017.05.08


図 -125: 高のパフォーマンスを持つラウンド・ロビン・スケジューラのクリティカル・チェイン

図 -126: 高のパフォーマンスを持つクリティカル・チェインの回路図

モジュラス演算子を削除し、2 のべき乗累乗の実装に切り替えることは非常に小さなデザイン変更であり、劇的なパフォーマンスの向上を提供します。

• 可能な限り、数学演算に 2 の累乗を使用します。

• 一見基本的な機能の代替実装を探索します。

この例では、ラウンドロビンロジックの実装を変更すると、パイプライン・ステージを追加するよりもパフォーマンスが向上します。

6 適化の例S10HPHB | 2017.05.08


7 付録

S10HPHB | 2017.05.08






7.1 付録 A：パラメーター化可能パイプライン・モジュール

次の例は、Verilog HDL、SystemVerilog、および VHDL のパラメーター化可能なパイプライン・モジュールを示しています。トップレベルの I/O およびクロックドメイン境界でこれらのコードブロックを使用して、回路のレイテンシーを変更します。

例-18: パラメーター化可能な Hyper-Pipelining Verilog HDL モジュール

// Hyper-pipelining module HyperPipe Intel Version 2014/08/12(* altera_attribute = "-name AUTO_SHIFT_REGISTER_RECOGNITION off" *)module hyperpipe # ( parameter CYCLES parameter WIDTH, ) ( input clk, input [WIDTH-1:0] din, output [WIDTH-1:0] dout );

generate if (CYCLES==0) begin : GEN_COMB_INPUT assign dout = din; end else begin : GEN_REG_INPUT integer i; reg [WIDTH-1:0] R_data [CYCLES-1:0];

always @(posedge clk) begin R_data[0] <= din; for(i=1;i<CYCLES;i=i+1) R_data[i] <= R_data[i-1]; end assign dout = R_data[CYCLES-1]; end endgenerateendmodule

例-19: パラメーター化可能な Hyper-Pipelining Verilog HDL インスタンス

// Instantiation Template:hyperpipe # ( .CYCLES ( ) .WIDTH ( ), ) hp ( .clk ( ), .din ( ), .dout ( ) );

例-20: パラメーター化可能な Hyper-Pipelining SystemVerilog モジュール

// Hyper-pipelining module HyperPipe Intel Version 2014/08/12(* altera_attribute = "-name AUTO_SHIFT_REGISTER_RECOGNITION off" *)module hyperpipe_2d # ( parameter CYCLES parameter PACKED_WIDTH, parameter UNPACKED_WIDTH, ) ( input clk, input [PACKED_WIDTH-1:0] din [UNPACKED_WIDTH-1:0], output [PACKED_WIDTH-1:0] dout [UNPACKED_WIDTH-1:0] );

generate if (CYCLES==0) begin : GEN_COMB_INPUT assign dout = din; end

7 付録S10HPHB | 2017.05.08


else begin : GEN_REG_INPUT integer i; reg [PACKED_WIDTH-1:0] R_data [CYCLES-1.0][UNPACKED_WIDTH-1:0];

always @(posedge clk) begin R_data[0] <= din; for(i=1; i<CYCLES; i=i+1) R_data[i] <= R_data[i-1]; end assign dout = R_data[CYCLES-1]; end endgenerate

例-21: パラメーター化可能な Hyper-Pipelining SystemVerilog インスタンス

// Instantiation Template:hyperpipe # ( .CYCLES ( ) .PACKED_WIDTH ( ), .UNPACKED_WIDTH ( ), ) hp ( .clk ( ), .din ( ), .dout ( ) );

例-22: パラメーター化可能な Hyper-Pipelining VHDL エンティティ

-- HyperPipe Intel Version 2014/08/12library IEEE;use IEEE.std_logic_1164.all;library altera;use altera.altera_syn_attributes.all;

entity hyperpipe is generic ( CYCLES : integer WIDTH : integer; ); port ( clk : in std_logic; din : in std_logic_vector (WIDTH - 1 downto 0); dout : out std_logic_vector (WIDTH - 1 downto 0) );end hyperpipe;

architecture arch of hyperpipe is

-- Prevent large hyperpipes from going into memory-basedaltshift_taps, -- since that won't take advantage of Hyper-Register attribute altera_attribute of hyperpipe : entity is "-name AUTO_SHIFT_REGISTER_RECOGNITION off";

type hyperpipe_t is array(CYCLES-1 downto 0) of std_logic_vector(WIDTH-1 downto 0); signal HR : hyperpipe_t;

begin wire : if CYCLES=0 GENERATE -- The 0 bit is just a pass-thru, when CYCLES is set to 0 dout <= din; end generate wire;

hp : if CYCLES>0 GENERATE process (clk) begin if (clk'event and clk='1')then HR <= HR(HR'high-1 downto 0) & din;

7 付録S10HPHB | 2017.05.08


end if; end process; dout <= HR(HR'high); end generate hp;

end arch;

例-23: パラメーター化可能な Hyper-Pipelining VHDL インスタンス

-- Template Declarationcomponent hyperpipe generic ( CYCLES : integer WIDTH : integer; ); port ( clk : in std_logic; din : in std_logic_vector(WIDTH - 1 downto 0); dout : out std_logic_vector(WIDTH - 1 downto 0) );end component;

-- Instantiation Template: hp : hyperpipe generic map ( CYCLES => WIDTH => , ) port map ( clk => , din => , dout => );

7.2 付録 B：クロックの有効化とリセット

7.2.1 同期リセットと制限

非同期リセットを同期に変換すると、タイミングを変更するのに役立ちますが、パフォーマンスの制限はあります。 ALM レジスターの専用 LAB ワイド信号は、しばしば同期クリアを実行します。信号のファンアウトにより合成中のこの信号の使用が決まります。ファンアウトが小さい同期クリアは通常ロジックで実行され、ファンアウトが大きければこの専用信号が使用されます。合成で同期クリアの使用が決定されたとしても、Compiler はレジスターを Hyper-Register にリタイミングします。 ALM レジスターのバイパスモードにより、この機能がイネーブルになります。Compiler がレジスターをバイパスすると、sclr信号およびその他のコントロール信号はアクセス可能なままです。

次の例では、LAB 幅の同期クリアが複数の ALM レジスターに供給されます。Hyper-Register は、すべてのレジスターの同期クリアパスに沿って使用できます。

7 付録S10HPHB | 2017.05.08


図 -127: 同期リセットのリタイミング例円は Hyper-Register を表し、長方形は ALM レジスターを表します。塗りつぶされていないオブジェクトは占有されていない位置を表し、青で塗りつぶされたオブジェクトは占有されています。

LAB-WideSynchronous

Clear

a)

b)

c)

LAB-WideSynchronous

Clear

リタイミング中に、ロウ（a)のトップ・レジスターは、右に Hyper-Register にプッシュされます。これは、ALM レジスターをバイパスしても、そのレジスターに供給する SCLR ロジックを使用することで実現されます。 LAB 幅の SCLR 信号を使用する場合、ALM レジスターがデータパス上に存在する必要がありますが、使用する必要はありません。

レジスター・リタイミングは、ロウ（b）のレジスターをそのデータパスにプッシュします。レジスターは、データパスと同期クリアの信号分割をプッシュします。このレジスターは、データパスと同期クリアパスの両方のネットにプッシュする必要があります。これは、各パスに Hyper-Register があるため実装できます。

別のレジスターが ALM に押し込まれると、リタイミングが複雑になります。次の図に示すように、非同期クリアポートのレジスターとデータパスのレジスターをマージする必要があります。

図 -128: リタイミング例 - 2 番目のレジスターが ALM からプッシュされる

LAB-WideClock sclr

LAB-WideClock sclr

BeforeRetiming

AfterRetiming

同期クリア・パス上のレジスターは他のレジスターと共有されるため、レジスターは他の同期クリア・ポートへのパス上で分割されます。

7 付録S10HPHB | 2017.05.08


図 -129: リタイミング例 - 他の同期クリアポートへのパスへのレジスターを分割する

BeforeRetiming

AfterRetiming

次の図では、同期クリアの Hyper-Register が使用中で、別のレジスターを受け入れることができません。Compiler は、このレジスターを 2 回目に ALM でリタイムすることはできません。

図 -130: リタイミング例 - 同期クリア時の競合

Conflict

次の 2 つの主要なアーキテクチャー・コンポーネントにより、ALM レジスターを同期クリアの順方向または逆方向に動かすことができます。

• ALM レジスターをバイパスする機能

• 同期クリアパス上の Hyper-Register

より多くのレジスターをプッシュするには、リタイミングが難しくなります。同期リセットへの変換よりも、非同期リセットの方がパフォーマンスが向上します。同期クリアは、ブロードキャストの性質が広いため、リトライするのが困難なことがよくあります。

7 付録S10HPHB | 2017.05.08


7.2.1.1 同期リセットのサマリ

同期クリアにより、リタイミングの量を制限することができます。リタイミングの問題を引き起こす同期クリアには 2 つの問題があります。

• ショートパスです。通常、ソースレジスターからデスティネーション・レジスターへの直接のロジックはありません。ショートパスは、通常、問題にはなりません。ポジティブなスラックをロングパスにリタイムアウトできるためです。これにより、デザイン全体がより高速に実行されます。しかし、通常、ショートパスは、リタイミングを必要とする長いデータパスに接続します。ロングパスに沿って多くのレジスターをリタイミングすることにより、レジスターはプッシュダウンされるか、またはこのショートパスにプルアップされます。この問題は通常のロジックでは重要ではありませんが、同期消去では一般的にファンアウトが大きいために悪化します。

• 同期クリアには大きなファンアウトがあります。アグレッシブなリタイミングでレジスターを同期クリア・パスの上または下にプッシュする必要がある場合、パスはもはや多くのレジスターを受け入れることができなくなるまで乱雑になることがあります。この状況により、パス長不均衡（ショートパス/ロングパスとも呼ばれる）が発生したり、同期クリアパスからそれ以上のレジスターを引き出すことができません。

積極的なリタイミングは、ALM レジスターを介して第 2 のレジスターをリタイムする必要がある場合に発生します。

図 -131: 積極的なリタイミング

SCLR

ALM Register withSynchronous Clear

SCLR

ALM Register Bypassed toPush Register Forward

SCLR

SCLR HyperRegister Used toPush ALM Register Backward

左の図に示すように、同期クリア信号を持つ ALM レジスターを考えてみましょう。中央の図は、レジスターがリタイミングされ、ALM レジスターがバイパスされていることを示しています。右の図は、レジスターが逆方向にリタイミングされていることを示しています。この場合、レジスターは SCLR パスにプッシュアップする必要があります。 Stratix 10 デバイスには SCLR パス上の専用の Hyper-Register とALM レジスターをバイパスモードにする機能があります。これにより、このレジスターをプッシュしてプルすることができます。前方にプッシュすると、SCLR パスの下にあるレジスターをプルし、2 つをマージする必要があります。プッシュバックされた場合、重複したレジスターを SCLR パスまでプッシュする必要があります。これらのオプションの両方を使用することができます。しかし、ボトルネックは、複数のレジスターが同期クリア・ルーティングを上下にレジスターをプッシュ/プルしているときに作成されます。

7 付録S10HPHB | 2017.05.08


リセットを使用する位置については実用的です。コントロール・ロジックは主に同期リセットが必要です。同期リセットを必要としないロジックは、タイミングに役立ちます。同期リセットを扱うための次のガイドラインを参照してください。

• 新しいコードを高速で実行する必要がある場合、できる限り同期リセットを回避してください。これは、一般に、システムがリセットされている間にフラッシュされるか、またはシステムがリセット解除されたときにその値が無視され、新しい有効な論理フィルタが通過するまで、データパスロジックにあります。

• コントロール・ロジックは、しばしば同期リセットを必要とするため、その状況で回避することはできません。

• 高速で動作する既存のロジックの場合、可能な限りリセットを解除します。ロジックを十分に理解していないか、リセット時にどのように動作するのか自信がない場合、同期リセットをそのままにしておいてください。同期クリアを取り除くことができます。

• 同期クリアをパイプライン化します。これは、レジスターをプッシュバックする必要がある場合に役立ちませんが、レジスターをデータパスに引き込む必要がある場合に役立ちます。

• 異なる階層に対して重複する同期クリアロジックです。これにより、ローカルロジックでリタイミングすることができるように、同期クリアのファンアウトが制限されます。ここでも、ファンアウトを大きくして既存の同期クリアを決定した後で、デザインをリタイムする方法を制限した後でのみ、これを行うことができます。デザイン機能を変更しないため、バックエンドで行うことは困難ではありません。

• 異なるクロックドメインと反転クロックのための重複した同期クリアです。これは、境界条件または複数期間要件の問題によるリタイミング制限を克服することができます。

7.2.2 クロックイネーブルを使用したリタイミング

同期リセットと同様に、クロックは、ALM レジスターの特定の機能に給電する専用の LAB ワイドリソースを使用します。同様に、 Stratix 10 デバイスは、クロックイネーブル付きのリタイミングロジックを簡単にする特別なロジックをサポートしています。しかし、クロックイネーブル（および同期クリア）などの広範なブロードキャストコントロール信号は、リタイミングすることが困難です。

図 -132: クロックイネーブルを表す ALM次の図は、 Synchronous Resets and Limitations セクションの非同期クリアのリタイミング動作のシーケンスがクロックイネーブルコントロール信号に適用されることを示しています。

LAB-WideClock Enable

LAB-WideClock Enable

7 付録S10HPHB | 2017.05.08


上の回路には、クロック・イネーブル・パスに専用の Hyper-Register があります。レジスターをプッシュバックする必要がある場合、別のレジスターがクロックイネーブルパスにプッシュアップされるようにレジスターを分割する必要があります。ここで、Hyper-Register の位置は問題なく吸収することができます。これらの機能により、クロックイネーブル付きの ALM レジスターを、タイミングを改善するために、簡単に前後にリタイミングすることができます（中段回路）。クロックイネーブルの有用な特徴は、そのロジックが通常同期信号によって生成されるため、クロックイネーブルパスがデータパスと一緒にリタイミングされることです。

図 -133: ALM レジスターと関連付けられた Hyper-Register を使用したステップと構造のリタイミング

CLKEN

CLKEN

CLKEN

LUT

Hyper-Register

Used Register

Bypassed Register

Legend

この図は、典型的なブロードキャストタイプのコントロール信号であるクロックイネーブル信号 clkenがどのようにリタイミングされるかを示しています。トップ回路では、リタイミングする前に ALM レジスターが使用されます。クロックイネーブルおよびデータパス上の Hyper-Register も使用されます。中間の回路では、ALM レジスターは、ALM 外の Hyper-Register にルーティングファブリックにリタイミングされています。 ALM レジスターはまだ使用されていますが、ALM を通るデータパスにはありません。これは、レジスターの前の値を保持するために使用されます。クロックイネーブルマルチプレクサは、クロックイネーブルに基づいてこの以前の値と新しい値との間で選択するようになりすた。下の図は、2番目のレジスターがクロックイネーブルおよびデータパスから ALM レジスターにリタイミングされるタイミングを示しています。 ALM レジスターがパスで使用されるようになります。このプロセスは繰り返すことができ、複数のレジスターをイネーブル ALM レジスターを介して繰り返しリタイミングすることができます。

7 付録S10HPHB | 2017.05.08


クロックイネーブル構造は、以下の 3 つのカテゴリに分類することができます。

関連情報113 ページの同期リセットと制限

7.2.2.1 ブロードキャスト・コントロール信号の例

多くの宛先にファンアウトするブロードキャスト・コントロール信号はリタイミングを制限します。非同期クリアは、特定のレジスターコントロール信号のシリコンサポートによるリタイミングを制限する可能性があります。しかし、同期クリアおよびクロックイネーブルなどの同期信号であっても、ショートパス/ロングパス・クリティカル・チェインの一部である場合にリタイミングを制限することができます。同期コントロール信号の使用自体は限定的な理由ではありません。むしろ、特定の配置と組み合わされた回路の構造です。

レジスターをノード上で転送するには、すべてのノードの入力でレジスターを使用できる必要があります。この要件は、従来のリタイミングと Hyper-Retiming と同じです。次の図のレジスター B を介してレジスター A をリタイムするには、クロックイネーブル入力のレジスター C を含むすべての入力からレジスターをプルする必要があります。さらに、レジスターが分岐点の片側にリタイミングされる場合、レジスターのコピーは分岐点のすべての側でリタイミングされなければなりません。この要件は、従来のリタイミングと Hyper-Retiming と同じです。

図 -134: クロックイネーブルによるリタイミング

B

CLKEN

B

CLKEN

A

C

A

レジスター B のクロックイネーブル入力には分岐点があります。分岐点は、クロックイネーブル以外の他のデスティネーションへの追加のファンアウトから構成されています。レジスター A をレジスター B 上でリタイムするには、前の図と同じですが、分岐点が存在するということは、レジスター C のコピーが分岐点の反対側に沿ってリタイミングして C をレジスターする必要があることを意味します。

図 -135: ブランチポイントによるクロックイネーブルによるリタイミング

CLKEN CLKEN

リタイミング例

以下の図は、前の 2 つのステップを組み合わせて、ブロードキャスト・クロック・イネーブル信号または分岐点の存在下での順方向 Hyper-Retiming プッシュのプロセスを示しています。

7 付録S10HPHB | 2017.05.08


図 -136: リタイミング例開始点Hyper-Retiming は、リタイミングされたレジスターを Hyper-Register に移動できます。

CLKEN

Hyper-Register

Combinational logic

各レジスターのクロックイネーブルには、その入力に 1 つの Hyper-Register 位置があります。配置配線のために、レジスター間パスには 3 つの Hyper-Register 位置が含まれます。異なるコンパイルには、より多くのまたはより少ない数の Hyper-Register の位置が含まれる可能性があります。さらに、このチェインへのデータおよびクロックイネーブル入力には、Hyper-Retiming がリタイミングできるレジスターがあります。これらのレジスターは RTL に存在するか、または Pipeline Stages のセクションで説明されているオプションで定義できます。

入力レジスターの 1 つのステージは、2 つのレジスター間の Hyper-Register 位置にリタイムされます。ページ 120 は Hyper-Retiming フォワードプッシュの一部を示しています。クロックイネーブル入力上のレジスターの 1 つは、各クロックイネーブル入力で Hyper-Register 位置にコピーされて、分岐点上でリタイミングされます。

図 -137: リタイミング例中間点

CLKEN

ページ 120 Hyper-Retiming が順方向プッシュを完了した後の回路内のレジスターの位置を示します。左レジスターの入力にある 2 つのレジスターは、Hyper-Register 位置にリタイムされます。この図は、2 つの前の図と機能的に同等です。第 2 のレジスターのクロックイネーブル入力における 1 つのHyper-Register 位置は占有されたままです。 2 番目のレジスターへのクロックイネーブルパスには他の Hyper-Register の位置はありませんが、リタイミングすることができる入力にはまだ 1 つのレジスターがあります。

図 -138: リタイミング例終了点CLKEN

ページ 121 はショートパス/ロングパス・クリティカル・チェインによって制限されない場合、Hyper-Retiming が使用できるレジスターの位置を示しています。ただし、右側のクロックイネーブルパスでHyper-Register を使用できないため、Hyper-Retiming は図のように回路をリタイムすることができません。

7 付録S10HPHB | 2017.05.08


図 -139: リタイミング例リミット条件

CLKEN Short Path LimitsPerformance

2 番目のレジスターへのクロックイネーブルパスには使用可能な Hyper-Register の位置がないため、Compiler はこれをショートパスとして報告します。レジスターからレジスターへのパスが報告されたパフォーマンスより上で動作するには長すぎるため、リタイミングされたレジスターに対してより多くの使用可能な Hyper-Register 位置を有するが、Compiler はこれをロングパスとして報告しまし。

この例では、ショートパス/ロングパス・クリティカル・チェインの構造を意図的に簡単に示しています。実際には、2 ファンアウトの負荷は回路のクリティカル・チェインではありません。ただし、ブロードキャストコントロール信号は、ファンアウトが高いため、クリティカル・チェインになる可能性があります。そのため、構造を回避または書き直すための手順を実行する必要があります。


7.2.3 ショートパスの解決

お互いに近いリタイミング・レジスターは、より高速にホールド違反を引き起こす可能性があります。次の図は、ショートパスがリタイミングを制限する方法を示しています。ショートパスの解決

図 -140: リタイミングを制限するショートパスこの例では、順方向リタイミングはレジスターを 2 つのパスにプッシュしますが、一方のパスはリタイミング用に使用可能なレジスターを持ちますが、もう一方はリタイミングしません。

Unusable Slot Due to Hold

#2#2

Routed Longer to Pick Up Extra Slots

#1#1

Register already used and not available for retiming

Register not used and available for retiming

Legend

左側の回路では、レジスター＃1 を前方にリタイミングする場合、上位パスには使用可能なスロットがあります。しかし、下位のパスは、既に使用中の隣接レジスターに近すぎるため、リタイミングレジスターを受け入れることができず、ホールドタイム違反が発生します。Compiler はこれらのショートパスを検出し、右側の回路に示すようにレジスターをよりロングパスにルーティングします。これにより、リタイミングに十分なスロットが確保されます。

以下の 2 つの例は、シートパスを示しています。

7 付録S10HPHB | 2017.05.08


ケース 1：デザインは 400MHz で動作します。 Fast Forward コンパイルでは、パイプライン・ステージを追加して 500MHz に到達させ、第 2 のパイプライン・ステージで 600MHz のパフォーマンスを達成することを推奨しています。

限定的な理由は、ショートパス/ロングパスです。 600MHz の性能に達するために推奨される 2 段パイプラインを追加してください。その後、制限の理由が再びショートパス/ロングパスである場合、ルータはデザインにおけるショートパスを修正しようとする際に限界に達しています。ただし、この時点で既に目標達成に達している可能性があります。これはもはやクリティカル・パスではありません。

ケース 2：デザインは 400 MHz で動作します。Fast Forward コンパイルでは、パイプライン・ステージを追加するための推奨はありません。

ショートパス/ロングパスがリタイミングの即時限定理由である場合、ルータはショートパスを修正しようとする際に限界に達しています。報告されたパスにパイプライン・ステージを追加することは役に立ちません。デザインを適化する必要があります。

お互いに近いリタイミング・レジスターは、より高速にホールド違反を引き起こす可能性があります。Compiler は、 Path Info のリタイミングレポートにこの状況を報告します。十分な Hyper-Registerが利用できない場合、Compiler はショートパスも報告します。ノードがショートパスとロングパスの両方を含む場合、両方のパスにパイプライン・レジスターを追加すると、リタイミングが役立ちます。

7 付録S10HPHB | 2017.05.08


8 改訂履歴

このドキュメントには、以下の改訂履歴があります。

表 13. 改訂履歴

日付バージョン変更内容

2017.05.08 Quartus Prime Pro v17.1Stratix 10 ES エディション

• Quartus Prime Pro v17.1 Stratix 10 ES エディションにソフトウェア・サポート・バージョンを更新。

• 初期パワーアップ条件を追加。• Retiming Reset Sequences トピックを追加。• 高速クロックドメインのためのガイドラインを追加。• Fitter Overconstraints トピックを追加。• フィッターでホールド・フィックス・アップを説明。• RAM および DSP ブロック間でのリタイミングのための Fast Forward コンパイルサ

ポートに関する声明を追加。• リード・モディファイ・ライト・メモリ記述に対するコヒーレント RAM の詳細を追加。• Fast Forward Viewer と Hyper-Optimization Advisor の説明を追加。• Advanced HyperFlex Settings トピックを追加。• レジスターリタイム防止のトピックを追加た。• 合成中のレジスターの保存を追加た。• フィッターコマンドのトピックを追加た。• ステージレポートの終化を追加た。• コンパイルフローの新しい GUI ステップでコマンドライン命令を置き換え。• コンパイルダッシュボードの並行分析コントロールについて説明。• 重複コンテンツとグループ化された付録をまとめ。• ダイアグラムとスクリーンショットを更新。

2016.08.07 2016.08.07 • クロッククロッシングと初期条件のタイミング制限の詳細を追加。• 真のデュアル・ポート・メモリー・サポートとメモリ幅の比を例で説明。• デザイン例ウォークスルーでコードサンプルとナレーションを更新。• 提供されたデザイン例ファイルへのリファレンスを追加。• Intel を再ブランド化。• ソフトウェアの GUI と機能の新の変更点について更新。

2016.03.16 2016.03.16 初版。

S10HPHB | 2017.05.08






Documents

Intel Stratix 10 高性能デザイン・ハンド ブック...このドキュメントの章では、 HyperFlex FPGAアーキテクチャーを素早く使用するために特定のデザイ

Intel Stratix 10 高性能デザイン・ハンドブック...このドキュメントの章では、 HyperFlex FPGAアーキテクチャーを素早く使用するために特定のデザイ