ISEのCore Generator相当はvivadoでManage IPとなっている。
Common Clock Builtin FIFOを使う。
First Word Fall Through(FWFT)モードにする。REと同時にリードデータが出力され、レイテンシ0となるモード。
FIFOのサイズは32bit×512Byte (4KByte空間)とする。
リセットは同期リセットとする。
FFIOの端子は最小でclk, srst(オプション), full, din, wr_en, empty, dout, rd_en。
fullとemptyは任意にスレッショルドを設定できる。
”Multiple Programable Full Threshold Input Port”は、ポートでドライブされた値によってprog_full信号をアサートするタイミングを決める。
"Full Threshold Assert Value", "Full Threshold Negative Value"が自動で入力されるが、(ポート設定モードなので)グレーアウトされていて入力できない(設定不可)。代わりにprog_full_thresh_assert、prog_full_thresh_negate端子が追加される。
Emptyは”Single Programmable Empty Threshold Constant”を使ってみる。
"Empty Threshold Assert Value"のみ入力可能で、Empty Threshold Negate Valueはグレーアウトされている。prog_emptyの閾値はポート設定ではなく、固定値としてカプセル化される。
アドレスを出力することも可能。 (Data Count)
サマリーをチェックする。
Generateする。
Progress=100%で生成完了。
fifo_generator_0_stub.vは外部ツールでコンパイルする際のブラックボックスモジュールとして使う。
xciファイルはxml形式のファイルで、すべての情報を含んでいる。
FPGA
2019年1月21日月曜日
XilinxのIP作成(MMCM)
ISEのCore Generator相当はvivadoでManage IPとなっている。
Input Clock Informationでソースクロックのクロック名、周波数を指定できる。
生成するクロックを指定する。20MHzのクロックを作ってみる。
ここは自動で設定される。850となっている。これは3分周クロックを42.5逓倍した値。この値はツールが自動で決めている。
60 / 3 * 42.5 / 42.5 = 20MHzという計算になる。なぜ42.5なのかは不明。あくまでツールが都合の良い値を自動で設定している。
さらに45MHzを追加すると、60 * 16.5 (=990) / 22 = 45MHzという計算になる。
さらに180MHzを追加する。
60 * 18 (=1080) / 6 = 180MHzという計算になる。
続いてバッファータイプの指定をする。デフォルトはBUFG(BUFGCTRL)。
20MHzはそのままBUFG、45MHzはBUFGCE(停止制御付き)、180MHzはローカルインターコネクト(非推奨)としている。
続いてここまでのサマリーを確認する。
最終的にMultiplyは18となったので、20MHz,45MHzもそれに合わせたM/D数に変更されている。
この条件でIPを作成する。
MMCM0.vは作成したIPをインスタンスする際のサンプルになっている。
MMCM0_stub.vは、MMCM0をvivado以外のコンパイラで使う際のブラックボックスモジュール。vivadoではxciファイルをプロジェクトに読み込んでいれば自動で認識される。
MMCM0.xciはvivadoで使われるMMCM0モジュール本体。xmlフォーマットで全てのマクロ情報を含んでいる。
わかりにくいが、VLNV列のxilinx.com:ip:clk_wiz:6.0をダブルクリックするとウィザードが起動する。
Show disabled portsのチェックボックスを外すと、使わない端子が見えなくなる。
クロックウィザードにはMMCMとPLLがある。今回はMMCMを選択する。
Input Clock Informationでソースクロックのクロック名、周波数を指定できる。
生成するクロックを指定する。20MHzのクロックを作ってみる。
ここは自動で設定される。850となっている。これは3分周クロックを42.5逓倍した値。この値はツールが自動で決めている。
60 / 3 * 42.5 / 42.5 = 20MHzという計算になる。なぜ42.5なのかは不明。あくまでツールが都合の良い値を自動で設定している。
さらに45MHzを追加すると、60 * 16.5 (=990) / 22 = 45MHzという計算になる。
さらに180MHzを追加する。
60 * 18 (=1080) / 6 = 180MHzという計算になる。
続いてバッファータイプの指定をする。デフォルトはBUFG(BUFGCTRL)。
20MHzはそのままBUFG、45MHzはBUFGCE(停止制御付き)、180MHzはローカルインターコネクト(非推奨)としている。
続いてここまでのサマリーを確認する。
最終的にMultiplyは18となったので、20MHz,45MHzもそれに合わせたM/D数に変更されている。
この条件でIPを作成する。
Out of Contextで生成。
Globalはプロジェクトモード。プロジェクトをコンパイルする際にIPも毎回コンパイルする。
Out of ContextではIPはIPのネットリストとして独立し、プロジェクトのコンパイル時には再コンパイルせずにネットリストを使用する。
MMCM0.vは作成したIPをインスタンスする際のサンプルになっている。
MMCM0_stub.vは、MMCM0をvivado以外のコンパイラで使う際のブラックボックスモジュール。vivadoではxciファイルをプロジェクトに読み込んでいれば自動で認識される。
MMCM0.xciはvivadoで使われるMMCM0モジュール本体。xmlフォーマットで全てのマクロ情報を含んでいる。
2019年1月20日日曜日
STA (Static Timing Analysis) レポートのみかた
STAの計算式には作法があり、Setup/Holdのタイミング計算をあたりまえに理解していても、
STAのレポートの計算手順と一致しているとは限らない。
基本的な考え方をリマインダしておく。
タイミングレポートは、コーナー条件(Fast Corner, Slow Corner)×Max/Min条件の数(=2x2=4)だけ種類がある。基本的にセットアップはSlow/Max、ホールドはFast/Min。チップ内ばらつき(On Die Variation)は最も厳しい条件で評価するので、データ到達時間Max、所要時間(概ねディスティネーションクロック遅延)Minということになるが、タイミングレポート上はそこまで詳細に表現されない。このあたりはXilinxのISEのときから正確な値を得ることができずグレーなところがあった(あるタイミングパスを個別のパス遅延のレポートで積み上げて手動で計算したとき、タイミングパスのレポートと手動の結果が微妙に一致しなかった)。vivadoはISEと異なり、現状見れないパスというのはなさそうだが、個々の積み上げとタイミングレポートが微妙にことなるところは変わっていない。この辺りはガードバンド(ディレーティング)としてツール内部で何かしらの計算をしていると思われる。
例えばセットアップのレポートをみると、パスタイプとして”Max at Slow Corner”のようにあるが、このMaxが何を指しているのか不明瞭なところがある。結論として(多分)、チップ内ばらつきはMax条件でみて、Min条件でみるほうが厳しい箇所(概ねディスティネーションクロック遅延)についてはCPRというパラメータで補正している。Xilinxのサポートアンサー情報に、このことに関する記事があった。(ワーストケース セットアップのシナリオを見つけ出すため、最大のデータ パスと最小のクロックパスがツールで使用されます。デスティネーション パスは最小のパス遅延、ソース パスには最大遅延が適用されます。この共通パスの場合、最小遅延と最大遅延の両方を適用することはできません。CPR は、この問題措置のため、最大値と最小値の差を利用します。この差はスラック計算に考慮されます。)
Rise/Fall解析はとくにきにしなくてもツールで自動的に考慮される。制約としてこれらのパス条件を付けることも可能。
ツールによって扱いは異なると思うが、Xilinxのvivado世代ではこのSkewをある程度除去できるらしく、CPR(クロック・ペシミズムの除去)というパラメータがある。このペシミズム除去は、その名の通りQoRにとって都合の良い極性を持つ。
STAのレポートの計算手順と一致しているとは限らない。
基本的な考え方をリマインダしておく。
内部同期パスのSlack計算式
Setup Slack = <setup data required time> - <data arrival time>
Hold Slack = <data arrival time> - <hold data required time>
Setup Slack = <setup data required time> - <data arrival time>
Hold Slack = <data arrival time> - <hold data required time>
Point
- スラックの計算は所要(の計算)と結果(の計算)の2つにまとめて表される
- タイミングレポートはこの形式で表現される
- Skewはサマリー情報として使われるがタイミングパス計算には使われない
Slackの計算式
<setup data required time> # セットアップ所要時間
= <destination clock arrival time> # クロック到着時間(受信側FF)
+- <clock pessimism> # Clock Pessimism
- <clock uncertatinty> # Clock Uncertainty
- <setup time> # セットアップ時間
<hold data required time> # ホールド所要時間
= <destination clock arrival time> # クロック到着時間(受信側FF)
+- <clock pessimism> # Clock Pessimism
+ <clock uncertainty> # Clock Uncertainty
+ <hold time> # ホールド時間
<data arrival time> # データ到着時間
= <sorce clock arrival time> # クロック到着時間(送信側FF)
+ <data delay> # データ遅延
Point
タイミング解析には動作条件があり、タイミングモデルとして使用される。- セットアップ解析の受信エッジは送信エッジの次の有効エッジ
- ホールド解析の受信エッジは送信エッジと同じ
- セットアップ解析の受信エッジは送信エッジの次の有効エッジ
- ホールド解析の受信エッジは送信エッジと同じ
- ワースト条件で見る
- パスがセット/クリアのときはリカバリー/リムーバルと呼ぶ。セットアップ=リカバリー、ホールド=リムーバル
デバイスの動作条件
・コーナー条件(プロセスばらつき、電圧、温度) # Slow or Fast
・Max/Min解析(チップ内ばらつき) # MaxかMinのモデルが使われPessimismで調整される
・Rise/Fall解析 # STAでは自動で考慮される(ガードバンドが緩和される)
・コーナー条件(プロセスばらつき、電圧、温度) # Slow or Fast
・Max/Min解析(チップ内ばらつき) # MaxかMinのモデルが使われPessimismで調整される
・Rise/Fall解析 # STAでは自動で考慮される(ガードバンドが緩和される)
タイミングレポートは、コーナー条件(Fast Corner, Slow Corner)×Max/Min条件の数(=2x2=4)だけ種類がある。基本的にセットアップはSlow/Max、ホールドはFast/Min。チップ内ばらつき(On Die Variation)は最も厳しい条件で評価するので、データ到達時間Max、所要時間(概ねディスティネーションクロック遅延)Minということになるが、タイミングレポート上はそこまで詳細に表現されない。このあたりはXilinxのISEのときから正確な値を得ることができずグレーなところがあった(あるタイミングパスを個別のパス遅延のレポートで積み上げて手動で計算したとき、タイミングパスのレポートと手動の結果が微妙に一致しなかった)。vivadoはISEと異なり、現状見れないパスというのはなさそうだが、個々の積み上げとタイミングレポートが微妙にことなるところは変わっていない。この辺りはガードバンド(ディレーティング)としてツール内部で何かしらの計算をしていると思われる。
例えばセットアップのレポートをみると、パスタイプとして”Max at Slow Corner”のようにあるが、このMaxが何を指しているのか不明瞭なところがある。結論として(多分)、チップ内ばらつきはMax条件でみて、Min条件でみるほうが厳しい箇所(概ねディスティネーションクロック遅延)についてはCPRというパラメータで補正している。Xilinxのサポートアンサー情報に、このことに関する記事があった。(ワーストケース セットアップのシナリオを見つけ出すため、最大のデータ パスと最小のクロックパスがツールで使用されます。デスティネーション パスは最小のパス遅延、ソース パスには最大遅延が適用されます。この共通パスの場合、最小遅延と最大遅延の両方を適用することはできません。CPR は、この問題措置のため、最大値と最小値の差を利用します。この差はスラック計算に考慮されます。)
Rise/Fall解析はとくにきにしなくてもツールで自動的に考慮される。制約としてこれらのパス条件を付けることも可能。
タイミングレポートの構造
①サマリー情報 ②詳細情報 ②-1 到着時間 ②-2 所要時間 ②-3 結果
サマリー情報
ソース ディスティネーション パスグループ パスタイプ 所要時間 データ遅延 ロジック段数 クロックパススキュー DCD(Destination Clock Delay) SCD(Source Clock Delay) CPR(Clock Pessimism Removal)
サマリー情報
タイミングパスの概要。詳細情報とはまとめ方が異なり、クロックの遅延はスキューで表現する。クロックパススキュー
Skew=DCD-SCDツールによって扱いは異なると思うが、Xilinxのvivado世代ではこのSkewをある程度除去できるらしく、CPR(クロック・ペシミズムの除去)というパラメータがある。このペシミズム除去は、その名の通りQoRにとって都合の良い極性を持つ。
Point
- セットアップ解析でDCD-SCD>0:CPR=0(有利なのでそのまま使う)
- セットアップ解析でDCD-SCD<0:CPR>0,で最大でSkewを0にする値
- ホールド解析でDCD-SCD>0:CPR<0,最小でSkewを0にする値
- ホールド解析でDCD-SCD<0:CPR=0(有利なのでそのまま使う)
タイミングレポート(セットアップサマリー)
Slack (<Met>|<Violation>) : <Slack値> (required time - arrival time) Source: <Source F/F> (clock edge) Destination: <Destination F/F> (clock edge) Pass Group: <クロックグループなどのタイミンググループ> Pass Type: <Setup>|<Hold> (<動作条件>) Requirement: <所要時間> Data Path Delay <データ遅延> Clock Path Skew: <クロックスキュー値> (DCD - SCD + CPR) Clock Uncertainty: <Uncertainty値>
タイミングレポート(セットアップサマリー)
Max Delay Paths -------------------------------------------------------------------- Slack (MET) : 15.568ns (required time - arrival time) Source: clk_gen/A_reg/C (rising edge-triggered cell FDRE clocked by BASECK {rise@0.000ns fall@8.333ns period=16.665ns}) Destination: clk_gen/Reset_reg/D (rising edge-triggered cell FDRE clocked by BASECK {rise@0.000ns fall@8.333ns period=16.665ns}) Path Group: BASECK Path Type: Setup (Max at Slow Process Corner) Requirement: 16.665ns (BSSECK rise@16.665ns - BASECK rise@0.000ns) Data Path Delay: 1.093ns (logic 0.580ns (53.085%) route 0.513ns (46.915%)) Logic Levels: 1 (LUT2=1) Clock Path Skew: 0.000ns (DCD - SCD + CPR) Destination Clock Delay (DCD): 4.861ns = ( 21.526 - 16.665 ) Source Clock Delay (SCD): 5.158ns Clock Pessimism Removal (CPR): 0.296ns Clock Uncertainty: 0.035ns ((TSJ^2 + TIJ^2)^1/2 + DJ) /2 +PE Total System Jitter (TSJ): 0.071ns Total Input Jitter (TIJ): 0.000ns Discrete Jitter (DJ): 0.000ns Phase Error (PE): 0.000ns
詳細情報
タイミングレポート(到着時間)
Location Delay type Incr(ns) Path(ns) Netlist Resource(s) ---------------------------------------- ------------------- <ソースクロックパス遅延の詳細> 0.000 0.000 ソースクロックのスタート地点 ・・・ 5.158 ソースF/Fのクロック(/C) ---------------------------------------- ------------------- <データパス遅延の詳細> 0.456 5.614 ソースF/Fの出力(/Q) ・・・ 6.250 Desti.F/Fの入力(/D) ---------------------------------------- -------------------
タイミングレポート(所要時間&結果)
Location Delay type Incr(ns) Path(ns) Netlist Resource(s) ---------------------------------------- ------------------- <ディスティネーションクロックパス遅延の詳細> 16.665 16.665 Desti.クロックのスタート地点 ・・・ 1.510 21.526 DestiF/Fのクロック(/C) pessimism 0.296 21.823 uncertainty -0.035 21.787 setup 0.031 21.818 ---------------------------------------- ------------------- required time 21.818 arrival time -6.250 ------------------------------------------------------------- slack 15.568
Point
サマリーではクロックスキューを使ってクロックの関係を表現しているが、詳細情報ではクロックの遅延とクロック・ペシミズムを使って計算している。式をみればわかる通り、スキューはペシミズム・リムーバルで補正したあとの値(補正しない、補正しきれない場合もある)。詳細パスでは実際に補正する分のペシミズムをパス遅延に加算している。
サマリーではクロックスキューを使ってクロックの関係を表現しているが、詳細情報ではクロックの遅延とクロック・ペシミズムを使って計算している。式をみればわかる通り、スキューはペシミズム・リムーバルで補正したあとの値(補正しない、補正しきれない場合もある)。詳細パスでは実際に補正する分のペシミズムをパス遅延に加算している。
CPRでSkewを0にできなかった例
タイミングレポート
Max Delay Paths ------------------------------------------------------------- Slack (MET) : 6.487ns (required time - arrival time) Source: jtag/B_reg[1]/C (rising edge-triggered cell FDCE clocked by clk100m {rise@0.000ns fall@4.999ns period=9.999ns}) Destination: common/B_reg[15]/D (rising edge-triggered cell FDCE clocked by clk100m {rise@0.000ns fall@4.999ns period=9.999ns}) Path Group: clk100m Path Type: Setup (Max at Slow Process Corner) Requirement: 9.999ns (clk100m rise@9.999ns - clk100m rise@0.000ns) Data Path Delay: 3.085ns (logic 1.724ns (55.890%) route 1.361ns (44.109%)) Logic Levels: 4 (CARRY4=4) Clock Path Skew: -0.035ns (DCD - SCD + CPR) Destination Clock Delay (DCD): 1.420ns = ( 11.419 - 9.999 ) Source Clock Delay (SCD): 1.533ns Clock Pessimism Removal (CPR): 0.078ns Clock Uncertainty: 0.104ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE Total System Jitter (TSJ): 0.071ns Discrete Jitter (DJ): 0.196ns Phase Error (PE): 0.000ns Location Delay type Incr(ns) Path(ns) Netlist Resource(s) ---------------------------------------- ------------------- <ソースクロックパス遅延の詳細> 0.000 0.000 ソースクロックのスタート地点 ・・・ 1.553 ソースF/Fのクロック(/C) ---------------------------------------- ------------------- <データパス遅延の詳細> 0.518 2.051 ソースF/Fの出力(/Q) ・・・ 4.618 Desti.F/Fの入力(/D) ---------------------------------------- ------------------- <ディスティネーションクロックパス遅延の詳細> 9.999 9.999 Desti.クロックのスタート地点 ・・・ 1.420 11.419 DestiF/Fのクロック(/C) pessimism 0.078 11.419 uncertainty -0.104 11.393 setup -0.288 11.105 ---------------------------------------- ------------------- required time 11.105 arrival time -4.618 ------------------------------------------------------------- slack 6.487
登録:
投稿 (Atom)