このページは、 timingに関する一連のページに属しています。前のページでは、 timing constraintsの背後にある理論の基本について説明しました。次のステップは、この理論がどのように適用されるかを確認することです。
概要
このページでは、 clockの周波数を定義する最も重要な timing constraintを紹介します。これに続いて、 pathの timing reportによる分析の詳細な例が続きます。
timing reportの分析の詳細は高度なトピックのように見えるかもしれませんが、そうではありません。 timing constraints の目的は、 designのツールの timing 分析を制御し、満たす必要がある正確な要件を設定することです。したがって、 timing constraintsを理解するには、 timing analysisを調べる必要があります。 timing analysis は timing reportsに表示されます。
また、 timing constraints を書くだけでは十分ではありません。これらの constraints が designで正しく動作することを確認できることが重要です。このような検証は、 timing reportを深く理解している場合にのみ可能です。そのような理解がなければ、目的を果たさない timing constraints に誤って依存し、なぜ logic design が正しく動作しないのか疑問に思うことは非常に簡単です。
すべての FPGA ツールは timing reports をテキスト ファイルとして生成します。ここで示すのは reports です。ツールには、まったく同じ情報を表示するためのグラフィカル インターフェイスもあります。このグラフィカル インターフェイスは役立つ場合もあれば、わかりにくい場合もあります。そのため、テキスト形式の reports を操作することが重要な最初のステップとなります。
period constraint
最も便利な timing constraint は period constraintです。 clock signalの周波数についてツールに通知します。
たとえば、 logic design が次の Verilog moduleだけで構成されているとします。
module top(
input clk,
input foo,
output reg bar_reg);
reg foo_reg;
reg bar;
always @(posedge clk)
begin
foo_reg <= foo;
bar <= !foo_reg;
bar_reg <= bar;
end
endmodule
@clk が clockとして使用されていること、およびこの signal が外部 port であること (つまり、 FPGA上の物理 pin に接続されていること) は、 Verilog から明らかです。
@clkの周波数が 250 MHz (4 ns) の場合、次のような timing constraint が必要です。
create_clock -period 4 -name clk [get_ports clk]
この command は次の意味を持ちます。 「 I/O port には @clkと呼ばれる clock があります。この clockの period は 4 nsです。この clockを参照する他の timing constraints がある場合、この目的のために「clk」という名前を使用します。
ノート：
- 「period」パラメータの値は、 clockの clock period である必要があります。 「余分な安全性」 (overconstraining) のために小さい値を選択しないでください。これを行う理由があってはなりません。これが役立つ場合は、解決する必要がある別の問題があります。
- asynchronous reset が使用されている場合、 create_clock は、この reset signalでの timing 要件の違反から flip-flop を保護しない場合があります。これは別のページで説明されています。
Timing analysis
ここで、 @foo_reg で始まり @barで終わる path の setup 要件について、 Vivadoの timing analysis を見てみましょう。言い換えると、これはこの Verilog expressionの結果である path です。
bar <= !foo_reg;
ここに示されている timing analysis は、次の順序で timing report に表示される 3 つの部分で構成されています。
- pathの timing analysisの概要といくつかの追加情報を含む header。
- clock edge から安定した logic state が2 番目の flip-flop (この例では@bar ) の input に存在するまでにかかる時間の計算。
- timing 要件を満たすために、2 番目の flip-flop の input が安定していなければならない時期を見つける計算。
これら 3 つの部分は、以下で個別に示され、説明されています。 timing reportでは、これらの部分の間に目に見える区切りがないことに注意してください。特に、 timing report では、2 番目の部分がどこで終了し、3 番目の部分が始まるかは明らかではありません。この report の読者は、その内容から 3 番目の部分の開始を認識する必要があります。
ここでは Vivadoの timing report を示していますが、同じ方法論が Quartus および他のいくつかの FPGA ツールにも採用されています。他のツールの timing reports に記述されている情報は、通常、若干異なる方法で提示されます。ただし、これらの reports の背後にある理論は同じです。したがって、この例を確認することは、他の FPGA ツールにも役立ちます。
timing reportの最初の部分はスキップし、最初の 2 つの部分について説明してからこの部分に戻ります。この順序で report を説明する方が簡単です。しかし、まずは一般的な言葉をいくつか述べます。
timing analysisの戦略
前のページで示した単純な static timing analysis とは異なり、実際の timing analysis では clockの不完全性を考慮する必要があります。そのために、 delay の計算は clockの起点、たとえば clockの物理的な input pin から開始されます。これは、 data pathの delay のみを考慮する単純な data path delay の計算 (前のページで示したもの) とは異なります。
したがって、理論的な実験は次のようになります。 clockの原点で clock edge と一緒にストップウォッチを開始します。この clock edge が最初の flip-flop に移動してアクティブになるまで、このストップウォッチを続けます。この flip-flop が outputを更新するまでの時間を測定し続け、更新された signal を目的地まで追跡します。この signal が 2 番目の flip-flopに到達したら、ストップウォッチを停止します。
次のステップは、結果が良好かどうかを確認することです。 tsu 要件の場合、これは、次の clock edgeに比べて、 signal が十分に早く到着したことを意味します。
しかし、これは 2 番目の flip-flop上の clock edge です。いつ届きますか？
それを見つけるために、 clockの原点にある次の clock edge とともに、ストップウォッチが再び開始されます。この 2 番目の clock edge が 2 番目の flip-flopに達すると、ストップウォッチは停止します。つまり、出発点は同じですが、 clock edge は後で、 clock edge の目的地は異なります。
この理論的な実験の後、 clock edge が 2 番目の flip-flopにいつ到達するかがわかります。 tsu の要件を満たすには、この flip-flopの input が、この clock edgeとの関係で十分早く安定している必要があります。
最初の理論実験のストップウォッチは、 data が 2 番目の flip-flopで安定しているときを示しています。 2 番目の実験のストップウォッチは、 clock edge が同じ flip-flopに到着したときを示しています。あとは、これら 2 つの数値を比較して、その差が tsuで必要とされるよりも大きいかどうかを確認するだけです。
clock に関連する不確実性は、両方の理論的実験で最悪のシナリオを適用できるため、この方法で考慮することができます。 setup time の計算では、すべての delays の上限がストップウォッチでの最初の実験の計算に使用されます。その結果、計算は、 signal が 2 番目の flip-flopの input に到着できる可能性のある最も遅い時間を示します。ただし、ストップウォッチを使用した 2 番目の実験では、すべての delays の下限が使用されます。結果は、2 番目の clock edge が 2 番目の flip-flopに到達できる最も早い時間です。
したがって、 signal ができるだけ遅く到着し、 clock edge ができるだけ早く到着するというシナリオで計算が行われます。これらの条件下で setup time の要件が満たされている場合、この要件が常に満たされていることに疑いの余地はありません。
hold time 計算の場合は、逆になります。 最初の実験では最小の delays を使用し、2 番目の実験では最大の delays を使用します。
source path の計算
前述のように、 timing report の最初の部分は後で示します。 timing analysisの 2 番目の部分を見てみましょう。 source path 計算。 2 つの segmentsで構成されています。
- Source Clock Path は、 FPGAの clock input pinの rising edge で始まり、この rising edge が @foo_regの clock input に達したときに終了します。
- @barの data input の signal が新しい値で更新されるまで、 Data Path は旅を続けます。この segment は、前のページで示した単純な static timing analysis に対応します。
これら 2 つの segments を合わせて、 FPGAの外部 clock pin で rising edge から data が 2 番目の flip-flopに到達するまでの時間を計算します。
これは、 timing reportの関連部分です。
Location Delay type Incr(ns) Path(ns) Netlist Resource(s)
------------------------------------------------------------------- -------------------
(clock clk rise edge) 0.000 0.000 r
AG12 0.000 0.000 r clk (IN)
net (fo=0) 0.000 0.000 clk_IBUF_inst/I
AG12 INBUF (Prop_INBUF_HRIO_PAD_O)
0.738 0.738 r clk_IBUF_inst/INBUF_INST/O
net (fo=1, routed) 0.105 0.843 clk_IBUF_inst/OUT
AG12 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O)
0.049 0.892 r clk_IBUF_inst/IBUFCTRL_INST/O
net (fo=1, routed) 0.839 1.731 clk_IBUF
BUFGCE_X1Y0 BUFGCE (Prop_BUFCE_BUFGCE_I_O)
0.101 1.832 r clk_IBUF_BUFG_inst/O
X2Y0 (CLOCK_ROOT) net (fo=3, routed) 1.389 3.221 clk_IBUF_BUFG
SLICE_X49Y58 FDRE r foo_reg_reg/C
------------------------------------------------------------------- -------------------
SLICE_X49Y58 FDRE (Prop_EFF2_SLICEL_C_Q)
0.138 3.359 f foo_reg_reg/Q
net (fo=1, routed) 0.241 3.600 foo_reg
SLICE_X49Y58 LUT1 (Prop_D5LUT_SLICEL_I0_O)
0.244 3.844 r bar__0_i_1/O
net (fo=1, routed) 0.046 3.890 p_0_in
SLICE_X49Y58 FDRE r bar_reg__0/D
------------------------------------------------------------------- -------------------
この部分の各行は、 logic element または wireを表します。「Delay type」が「net」の場合、行は wireに対応します。この種のすべての delays は routing delaysです。つまり、 signal が 1 つの logic element から別の logic element に伝播するのにかかる時間です。
「Incr」という名前の列は、 path の各要素がどれだけ delay に寄与するかを示しています。 「Path」列には、その時点までの合計 delay が表示されます。
中央の水平線は、 Source Clock Path の終わりと Data Pathの始まりを示しています。では、この 2 つの pathsのうち、 delays について詳しく見ていきましょう。
最初の 7 つの delays は input pinに関連しており、 AG12 です (これがこの pinの物理的な位置です)。この reportによると、この pin に関連する input pin と logic は、合計 delay の 1.731 nsに寄与します。
global clock buffer は、 input から outputに別の 0.101 ns を提供します。これに global clockの routing delay が続き、これは比較的大きな数です。 1.389 ns.これは、 clock signal が @foo_regの clock inputに到達するのにかかる時間です。この大きな delay の理由は、 global clock buffer と clock tree がこの signalの配布に使用されているためです。これらの routing resources は、 clock を FPGA の大部分に配布し、同じ delay をすべての宛先に配布することを目的としています。したがって、この例のように、 clock が少数の宛先にしか到達しない場合でも、大きな delayが存在します ( clock の fan-out は 3です)。
この時点で、 clock は最終的に flip-flop(この例では SLICE_X49Y58 ) を含む slice に到達しています。つまり、これが Source Clock Pathの終わりです。 report の水平線は Data Pathの始まりを示しています。前のページの例では、ここが単純な static timing analysis の始まりです。
右側の Netlist Resources 列では、水平線の上の行に「foo_reg_reg/C」と表示され、この行の直後に「foo_reg_reg/Q」と表示されます。したがって、水平線の後の行は、間違いなく @foo_regの flip-flop の clock to output delay ( C から Qへ) です。この delay が 0.138 nsです。 「FDRE」は、 Data、 Reset 、および Enableを含む Flip-flop を意味します。
これに続いて、 routing delay から LUT (0.241 ns)、 LUT 内の propagation delay (0.244 ns)、および routing delay から 2 番目の flip-flop (0.046 ns) が続きます。すべてが単一の sliceに詰め込まれているため、 routing delays は非常に小型です。
この部分を要約すると、 clock edge が外部 pin から最初の flip-flopの clock input に移動するのに 3.221 ns が必要でした。その後、更新された signal が 2 番目の flip-flopの input (3.890 − 3.221 = 0.669 ns) に到達するまで、 0.669 ns を要しました。合計で、外部 pin 上の clock edge から最終目的地 (2 番目の flip-flopの data input) の安定した signal までの時間は 3.890 ns でした (これは最悪の場合の計算です)。
ですから、これで十分かどうかを尋ねる時が来ました。 setup time の要件は満たされていますか?
Destination Clock Path
この 2 番目の計算の目的は、 clock edge が外部 pin から 2 番目の flip-flopの clock inputにどれだけ速く移動できるかを調べることです。
clock pathの宛先は2 番目の flip-flopであることに注意してください。これを、目的地が最初の flip-flopであった、前の計算の clock pathと混同しないでください。
他にも注目すべき違いがあります。
- clock path のみが計算されます。つまり、前回の計算と比べて、横線までの segment のみを考慮しています。
- 理論上のストップウォッチはゼロではなく、 4 nsから始まります。これは、この計算の目的が、 data signal が setup time の要件を満たすのに十分早く到着するかどうかを調べることだからです。したがって、計算は秒 clock edgeから開始します。これは、 clk の timing constraint に従って 4 ns です (つまり、上記の create_clock command )。
- この segment の各コンポーネントの delays は小さくなっています。この特定の例では、両方の flip-flops が同じ slice上にあり、 clock paths は両方の計算でまったく同じであるため、これは簡単に確認できます (通常はそうではありません)。これについては、以下で詳しく説明します。
- この計算の最後の 3 行 (clock pessimism、 clock uncertainty 、および Setup_DFF2_SLICEL_C_D) は、 logic コンポーネントではなく、 timing parametersコンポーネントです。
timing analysis (Destination Clock Path) の 3 番目の部分は次のとおりです。
(clock clk rise edge) 4.000 4.000 r
AG12 0.000 4.000 r clk (IN)
net (fo=0) 0.000 4.000 clk_IBUF_inst/I
AG12 INBUF (Prop_INBUF_HRIO_PAD_O)
0.515 4.515 r clk_IBUF_inst/INBUF_INST/O
net (fo=1, routed) 0.066 4.581 clk_IBUF_inst/OUT
AG12 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O)
0.034 4.615 r clk_IBUF_inst/IBUFCTRL_INST/O
net (fo=1, routed) 0.722 5.337 clk_IBUF
BUFGCE_X1Y0 BUFGCE (Prop_BUFCE_BUFGCE_I_O)
0.091 5.428 r clk_IBUF_BUFG_inst/O
X2Y0 (CLOCK_ROOT) net (fo=3, routed) 1.218 6.646 clk_IBUF_BUFG
SLICE_X49Y58 FDRE r bar_reg__0/C
clock pessimism 0.527 7.173
clock uncertainty -0.035 7.138
SLICE_X49Y58 FDRE (Setup_DFF2_SLICEL_C_D)
0.067 7.205 bar_reg__0
-------------------------------------------------------------------
required time 7.205
arrival time -3.890
-------------------------------------------------------------------
slack 3.315
ツールは @foo_reg と @bar を同じ sliceに配置することを選択したため、この特定のケースでは、この分析の clock path は最初の分析と同じです。したがって、 logic elements のシーケンスは、水平線まで、以前の分析とまったく同じであることが簡単にわかります。このシーケンスの後、計算を調整する 2 つの timing parameters があります。 Clock pessimism と clock uncertainty。これらについては、このページの下部で個別に説明します。
この計算の最後の行の 1 行前に、 2 番目の clock edge が到着できる最も早い時刻があります。 最初の clock edgeの後に 7.138 ns 。 setup time の要件は、この clock edgeの前に data signal が安定している必要があるということです。 tsu はその量を指定します。したがって、 data が安定していなければならない最新の時刻を取得するために、 tsu は clockの到着時刻から差し引かれます。
上記の例では、 tsu は負であり、 −0.067 nsに等しくなります。したがって、最終結果は 7.138 − (−0.067) = 7.205 nsです。つまり、 data は、最初の clock edgeの後の 7.205 ns までに、2 番目の flip-flop で安定している必要があります。
前回の計算では、最悪でもこの clock edgeの次は data が安定している 3.890 ns という結果でした。それで、余裕を持って、それで十分です： 要件と保証されるものの違いは 7.205 − 3.890 = 3.315 nsです。つまり、 slack は 3.315 nsです。
timing analysisのまとめ
pathの timing reportの最初の部分に戻る時が来ました。この部分は、上に示した計算の前にあり、主な結果を要約しています。さらに、この header は、この計算に現れるいくつかの値を明確にします。
したがって、これが path の timing analysis の開始方法であることに注意してください。
Slack (MET) : 3.315ns (required time - arrival time)
Source: foo_reg_reg/C
(rising edge-triggered cell FDRE clocked by clk {rise@0.000ns fall@2.000ns period=4.000ns})
Destination: bar_reg__0/D
(rising edge-triggered cell FDRE clocked by clk {rise@0.000ns fall@2.000ns period=4.000ns})
Path Group: clk
Path Type: Setup (Max at Slow Process Corner)
Requirement: 4.000ns (clk rise@4.000ns - clk rise@0.000ns)
Data Path Delay: 0.669ns (logic 0.382ns (57.100%) route 0.287ns (42.900%))
Logic Levels: 1 (LUT1=1)
Clock Path Skew: -0.048ns (DCD - SCD + CPR)
Destination Clock Delay (DCD): 2.646ns = ( 6.646 - 4.000 )
Source Clock Delay (SCD): 3.221ns
Clock Pessimism Removal (CPR): 0.527ns
Clock Uncertainty: 0.035ns ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
Total System Jitter (TSJ): 0.071ns
Total Input Jitter (TIJ): 0.000ns
Discrete Jitter (DJ): 0.000ns
Phase Error (PE): 0.000ns
Clock Net Delay (Source): 1.389ns (routing 0.002ns, distribution 1.387ns)
Clock Net Delay (Destination): 1.218ns (routing 0.002ns, distribution 1.216ns)
この部分はさまざまな情報で構成されているので、1 つずつ説明します。したがって、最初の行から始めます。
Slack (MET) : 3.315ns (required time - arrival time)
これは、 timing constraint が達成された (met) ことと、 3.315 nsという時間が残っていること (slack) を示しています。
Source: foo_reg_reg/C
(rising edge-triggered cell FDRE clocked by clk {rise@0.000ns fall@2.000ns period=4.000ns})
Destination: bar_reg__0/D
(rising edge-triggered cell FDRE clocked by clk {rise@0.000ns fall@2.000ns period=4.000ns})
これらの行は、どの data path が検査されたかを示しています。これは、この path ( Source および Destination) の開始位置と終了位置によって定義されます。 data path は、 @foo_regの clock input である foo_reg_reg/Cから始まります。この path は、 bar_reg__0/Dの data input で終了します。
もう一つは、「clk」が言及され、その waveform が説明されていることです。「clk」は、 create_clockとともに clock に与えられた名前を参照していることに注意してください。この例では、「clk」は clock signalの名前でもあります。ただし、 timing constraintの "-name" parameter で別の名前が使用されている場合、その名前は signalの名前に関係なく、 timing reportに表示されます。これは、この timing reportの例で「clk」が言及されているすべての場所に当てはまります。
Path Group: clk
ここでの Path Group は「clk」であり、この path を調べる理由が同名の timing constraint であることを示しています。
Path Type: Setup (Max at Slow Process Corner)
Path Type は Setupです。これは、 setup time の要件が検討されていることを意味します。 「Max at Slow Process Corner」は、 data path の計算 (最初の計算) で最大の delays が使用されたことを意味します。このコンテキストでの Corner の意味を以下に説明します。
Requirement: 4.000ns (clk rise@4.000ns - clk rise@0.000ns)
上記の 2 つの理論的実験のそれぞれで開始される架空のストップウォッチがあることを思い出してください。 「Requirement」は、このストップウォッチをスタートさせたときの時差です。この場合、 4 nsである timing constraintが必要とするのは clock period です。
Data Path Delay: 0.669ns (logic 0.382ns (57.100%) route 0.287ns (42.900%))
Data Path Delay は、最初の計算の水平線の後のすべての delays の合計です (つまり、 data pathの delays )。
この行では、 delay は logic と routeに対しても個別に表示されます。これは、 logic elements に費やされた時間と、これらの logic elements間の wires に費やされた時間を示しています。一般的な経験則では、 delay のうちおよそ 60% が logicに、残りが routingに費やされるはずです。したがって、この例の path は通常の状況を示しています。
routingの delay の割合が非常に大きい場合、特に path が timing constraintを達成できない場合、これは問題を示している可能性があります。これについては、次のページの tholdの分析について説明するセクションで詳しく説明します。
Logic Levels: 1 (LUT1=1)
data path は単一の LUTで構成されているため、 logic levels の数は 1 です。
Clock Path Skew: -0.048ns (DCD - SCD + CPR)
Destination Clock Delay (DCD): 2.646ns = ( 6.646 - 4.000 )
Source Clock Delay (SCD): 3.221ns
Clock Pessimism Removal (CPR): 0.527ns
Clock Path Skew は、同じ clock edge が 2 つの flip-flopsに到達する時間差です。これは、最大の delays が 1 つの clock pathで使用され、最小の delays が他の clock pathで使用されるという事実を含む、計算された最悪のケースです。以下の「Clock pessimism removal」という名前のセクションを参照してください。これらの行の背後にある演算について説明しています。
Clock Uncertainty: 0.035ns ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
Total System Jitter (TSJ): 0.071ns
Total Input Jitter (TIJ): 0.000ns
Discrete Jitter (DJ): 0.000ns
Phase Error (PE): 0.000ns
以下の「Clock uncertainty」という名前のセクションを参照してください。これらの行は、 clock uncertainty がどのように計算されたかを示しています。この計算結果 0.035 nsは非現実的なほど楽観的です。これは、 timing constraintで jitter が指定されていないために発生したため、ツールは jitter がゼロであると想定していました。それに加えて、外部の clock が直接使用される (つまり、 FPGA内に PLL がない) ため、考慮すべき jitter のソースはほとんどありません。
timing constraintで外付け clockの jitter を指定しないのは間違いですが、通常はこのように行われます。 jitter は通常、 timing の計算で考慮される他のものと比較して小さいため、これが問題の原因になることはめったにありません。
Clock Net Delay (Source): 1.389ns (routing 0.002ns, distribution 1.387ns) Clock Net Delay (Destination): 1.218ns (routing 0.002ns, distribution 1.216ns)
これらは、 clock buffer の output から flip-flopsの clock inputsのそれぞれまで、 clock signal 自体の delays です。この例では、これらの数値から得られる情報はあまりありません。
Multi-corner timing analysis
すべての logic elements の delay は、温度や supply voltageなど、いくつかの不明なパラメーターに依存します。また、「process」という用語は、 FPGAの製造中の不正確さを指すために使用されます。すべての FPGA が datasheetに準拠していることを確認するためにテストされていますが、各 logic elementの動作に関してはまだ不確実性があります。
FPGA ツールは、「corners」と呼ばれるいくつかの極端なシナリオで、 path ごとに timing analysis を実行します。たとえば、1 つのシナリオとして、許容される最低温度と最速の process を組み合わせることができます (つまり、 FPGA がたまたま低い delaysで製造された場合)。 2 番目のシナリオは、最速の processと組み合わせた最高温度です。 3 番目と 4 番目のシナリオでは、これを最も遅い processで繰り返します。
したがって、この例では、 timing analysis は 2 つのパラメーターの極端な条件に対して実行されます。 温度と process。これは four-corner timing analysisと呼ばれます。しかし、これは multi-corner timing analysisを実行する多くの可能性の 1 つにすぎません。各 FPGA ツールは、異なる方法で timing analysis を実行します。
しかし、ツールがどの corners を検査することを選択したかに関係なく、最悪のケースは常に timing analysisの結果と見なされます。つまり、ツールは cornerごとに slack を計算し、カウントされるのは最も低い slack です。
ツールは、 FPGAごとに適切な multi-corner timing analysis を実行するようにプログラムされているため、このトピックを深く理解する必要はありません。しかし、 timing reportを読み取るときは、それが単一の cornerに関連するものなのか、それともすべての corners の要約なのか (つまり、最悪の場合) を確認することが重要です。特に Quartusと混同する可能性があります。
Clock pessimism removal と Clock uncertainty については次に説明します。これらは比較的高度なトピックです。 timing 計算の詳細に興味がない場合は、このシリーズの次のページにスキップしてもかまいません。
Clock pessimism removal
両方の flip-flops が同じ slice上にあるという偶然の一致により、 clock path delays の計算 (つまり、 clock edge が sliceに到達するまでの時間) を比較することができます。 2 番目の計算では、この時間は 2.646 nsです。計算は 4 ns で開始し、 6.646 nsで終了するため、 6.646 − 4 = 2.646 nsです。前の計算では、結果は 3.221 nsでした。この 0.575 nsの違い。
この違いの理由は、最大の delays が最初の計算で使用され、最小の delays が 2 番目の計算で使用されたためです。最小の delays と最大の delays の違いは、製造プロセスにおける自然な不正確さのために、 delays が正確に知られていないという事実を表しています。したがって、最初の flip-flop への clock path が、2 番目の flip-flopへの clock path と完全に異なる場合は、最悪のケースを考慮する必要があります。この最悪のケースは、最初の path のすべての delays が最大許容値であり、2 番目の path のすべての delays が最小許容値である場合です。これは clock pessimismと呼ばれます。
これは、物理的な FPGA 間の温度や違いとは何の関係もないことに注意してください。 両方の計算は、同じ温度と製造プロセスに対して行われます。この違いは、 segment の各 delay に、 FPGAの仕様内にある tolerance があるためです。
しかし、 clock path が両方の pathsで同一であるのに、なぜ clock pessimism が計算の一部になるのでしょうか?答えは、これを行うのは間違いだということです。これが、 Destination Clock Pathに「clock pessimism」というタイトルの行がある理由です。この行は、この間違いを補うために delay に 0.527 ns を追加します。タイトルは実際には "clock pessimism removal" (CPR) である必要があります。
したがって、 clock pessimism removal の背後にある考え方は、最小 delay と最大 delay の間の不必要な違いを、両方の計算で同一である clock path の部分で排除することです。ツールは両方の計算の clock paths を比較し、両方の pathsに共通する segment を見つけます。 delays (共有 segment内) のすべての違いの合計は、削除する必要がある clock pessimism です。
前述の通り、 clock paths との違いは 0.575 nsでした。しかし、適用された clock pessimism は 0.527 nsだけでした。 0.048 nsの方が減りは少なかったです。その理由は、 slice 内に clock path の小さな segment があり、両方の計算に共通ではないためです。 slice 内の 1 つの wire は最初の flip-flop に接続され、2 番目の wire は 2 番目の flip-flopに接続されます。これら 2 つの wires の delays は異なる場合があります。
Clock uncertainty
timing の計算では、 0.035 ns が clock pathの計算から削減されました。これにより、 timing の計算がより厳密になります。
Clock uncertainty は、各 2 つの clock edges間の時間についてランダムなすべてを説明します。このランダム性は clock jitterと呼ばれ、さまざまなノイズ源と電子機器のランダムな動作の結果です。
計算からの 0.035 ns の削減は、 clock period が timing constraint (create_clock) で 4 ns として定義されているにもかかわらず、この clock period が実際にはランダムであるという事実を表しています。その結果、2 台の clock edges 間の時間を短縮できます。どれくらい短い？この計算では、2 つの clock edges 間の時間が 3.965 ns (4−0.035 = 3.965 ns) よりも小さくなることはないと想定されています。
この仮定は立証されていますか？ clock jitter の推定は複雑な問題であり、 timing constraintsに関するこの議論の範囲をはるかに超えているため、これは難しい質問です。それでも、 timing constraintsに関係なく、 clock jitter は logic designのさまざまな問題の原因となる可能性があるため、このトピックをさらに調査することをお勧めします。
これで、 clock period constraintに関する 2 ページのうちの最初のページを終了します。次のページで学ぶことがもっとあります...