このページは、 timingに関する一連のページに属しています。 timing constraints の背後にある理論と clock period constraintに関する最初のページを簡単に紹介した後、この constraintでいくつかの現実的なシナリオを見てみましょう。
次のステップ: PLLの使用
前のページで示した例では、外部の clock pin が logicに直接接続されていました。ほとんどの実際の designsでは、 logicで使用される clock を作成するために、ある種の PLL が使用されます。これを行う最も明白な理由は、 logic が外部 clockの周波数とは異なる周波数を必要とすることです。ただし、 PLL を使用すると、外部 clock 、特に jitterの欠陥を取り除くことにも役立ちます。
PLL は、次のように Verilog コードを使用して design に追加できます。
module top(
input clk,
input foo,
output reg bar_reg
);
reg foo_reg;
reg bar;
wire pll_clk;
clk_wiz_0 pll_i
(.clk_in1(clk),
.clk_out1(pll_clk));
always @(posedge pll_clk)
begin
foo_reg <= foo;
bar <= !foo_reg;
bar_reg <= bar;
end
endmodule
これは前の例と同じですが、今回は flip-flopsの clock が @clkではなく @pll_clk です。 PLL は Vivadoの Clocking Wizard IPによって生成され、 Verilog コードで clk_wiz_0という名前の module として使用されます。
この例では、 Clocking Wizard は 250 MHz reference clockを受け入れ、 output port (つまり @clk_out1) で 125 MHz clock を作成するように構成されています。例を単純にするために、 clk_wiz_0 には reset input または "locked" outputがありません。ほとんどの実際の designs では、これらの ports を有効にして使用することをお勧めします。
clk_wiz_0 のもう 1 つの点は、 phase alignment オプションが有効になっているため、 @pll_clkの clock edges を @clkの clock edges に合わせることです。このオプションは、 design に外部 clockと同期する I/O ports がある場合に役立ちます。 外部 clock と内部 clock の間の timing の関係は、有効な phase alignmentのおかげで予測可能になります。これは、外部 clockに関連する timing 要件を満たす必要がある I/O ports で役立ちます。
Xilinxの用語について正確に言うと、 Xilinxの FPGAs には 2 種類の PLLsがあります。 1 つのタイプは PLL と呼ばれ、2 つ目のタイプは MMCMと呼ばれます。この例では、違いは関係ありません。 clk_wiz_0 は MMCMですが、わかりやすくするために PLLという用語を使用します。
PLL についてここで述べられていることはすべて、市場に出回っているすべての FPGAs に適用されることを再度言及する価値があります。この例は Vivadoで示されていますが、 clk_wiz_0 とまったく同じことを行う PLL は、すべての FPGAsに対して生成できます。
PLLを搭載した timing constraint
timing constraints と PLL について知っておくべき最も重要なことは、それについて特別なことは何もないということです。 timing constraint は、外部 pin (この例では@clk ) との関係で記述されており、 PLL が別の周波数で clock を生成する場合、それを考慮するのはツールの仕事です。
もう一度言う価値があります： PLL が使用されているため、追加の timing constraint を作成する必要はありません。そうする必要があると感じた場合は、 designに問題がある可能性が高く、 timing constraint を追加して問題を「修正」しても、実際の問題は解決されません。
以前と同様に、 timing constraint は次のとおりです。
create_clock -period 4.000 -name clk [get_ports clk]
Quartus を使用する人は、このページで説明されている落とし穴に注意する必要があります。
PLLを搭載した timing report
前のページの例と同じ path の timing report を見てみましょう。唯一の違いは、上記のように PLL が追加されたことです。ここでは、関連する path の分析が、 timing reportに表示されるのと同じ順序で表示されます。まず、分析の概要は次のとおりです。
Slack (MET) : 7.288ns (required time - arrival time) Source: foo_reg_reg/C (rising edge-triggered cell FDRE clocked by clk_out1_clk_wiz_0 {rise@0.000ns fall@4.000ns period=8.000ns}) Destination: bar_reg__0/D (rising edge-triggered cell FDRE clocked by clk_out1_clk_wiz_0 {rise@0.000ns fall@4.000ns period=8.000ns}) Path Group: clk_out1_clk_wiz_0 Path Type: Setup (Max at Slow Process Corner) Requirement: 8.000ns (clk_out1_clk_wiz_0 rise@8.000ns - clk_out1_clk_wiz_0 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): -0.715ns = ( 7.285 - 8.000 ) Source Clock Delay (SCD): -0.616ns Clock Pessimism Removal (CPR): 0.051ns Clock Uncertainty: 0.062ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE Total System Jitter (TSJ): 0.071ns Discrete Jitter (DJ): 0.103ns 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)
いくつかの顕著な違いがあります。まず、 Requirement は以前の 4 ns ではなく 8 nsです。 PLLの output は 125 MHzであるため、これは予期されることです。ツールは、 8 nsに等しい clock period を使用して、この output用に追加の timing constraint を自動的に作成しました。 clock period が 4 ns 分長くなり、 data path は変わらないので、 slack は約 4 ns長くなりました。
自動 timing constraint のもう 1 つの特徴は、 Path Group がこの reportで「clk_out1_clk_wiz_0」と表記していることです。以前は「clk」でした。実際、この report では、以前は「clk」だったすべての箇所で「clk_out1_clk_wiz_0」と表記されています。 timing report での自動 timing constraints の表記については、複数の clocksのコンテキストで以下で説明します。
PLL のより小さな結果は、 Clock Uncertainty が 0.062 nsになったことです。 前の例では 0.035 ns でした。これは、 Discrete Jitter がゼロではなく 0.103 nsになったためです。
さて、 timing analysis 自体に移りましょう。今回は、 Source Clock Path、 Data Path 、 Destination Clock Path が、実際の reportとまったく同じように一緒に表示されます。
Location Delay type Incr(ns) Path(ns) Netlist Resource(s)
------------------------------------------------------------------- -------------------
(clock clk_out1_clk_wiz_0 rise edge)
0.000 0.000 r
AG12 0.000 0.000 r clk (IN)
net (fo=0) 0.000 0.000 pll_i/inst/clkin1_ibuf/I
AG12 INBUF (Prop_INBUF_HRIO_PAD_O)
0.738 0.738 r pll_i/inst/clkin1_ibuf/INBUF_INST/O
net (fo=1, routed) 0.105 0.843 pll_i/inst/clkin1_ibuf/OUT
AG12 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O)
0.049 0.892 r pll_i/inst/clkin1_ibuf/IBUFCTRL_INST/O
net (fo=1, routed) 0.975 1.867 pll_i/inst/clk_in1_clk_wiz_0
MMCME3_ADV_X1Y0 MMCME3_ADV (Prop_MMCME3_ADV_CLKIN1_CLKOUT0)
-4.474 -2.607 r pll_i/inst/mmcme3_adv_inst/CLKOUT0
net (fo=1, routed) 0.501 -2.106 pll_i/inst/clk_out1_clk_wiz_0
BUFGCE_X1Y0 BUFGCE (Prop_BUFCE_BUFGCE_I_O)
0.101 -2.005 r pll_i/inst/clkout1_buf/O
X2Y0 (CLOCK_ROOT) net (fo=3, routed) 1.389 -0.616 pll_clk
SLICE_X49Y58 FDRE r foo_reg_reg/C
------------------------------------------------------------------- -------------------
SLICE_X49Y58 FDRE (Prop_EFF2_SLICEL_C_Q)
0.138 -0.478 f foo_reg_reg/Q
net (fo=1, routed) 0.241 -0.237 foo_reg
SLICE_X49Y58 LUT1 (Prop_D5LUT_SLICEL_I0_O)
0.244 0.007 r bar__0_i_1/O
net (fo=1, routed) 0.046 0.053 p_0_in
SLICE_X49Y58 FDRE r bar_reg__0/D
------------------------------------------------------------------- -------------------
(clock clk_out1_clk_wiz_0 rise edge)
8.000 8.000 r
AG12 0.000 8.000 r clk (IN)
net (fo=0) 0.000 8.000 pll_i/inst/clkin1_ibuf/I
AG12 INBUF (Prop_INBUF_HRIO_PAD_O)
0.515 8.515 r pll_i/inst/clkin1_ibuf/INBUF_INST/O
net (fo=1, routed) 0.066 8.581 pll_i/inst/clkin1_ibuf/OUT
AG12 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O)
0.034 8.615 r pll_i/inst/clkin1_ibuf/IBUFCTRL_INST/O
net (fo=1, routed) 0.873 9.488 pll_i/inst/clk_in1_clk_wiz_0
MMCME3_ADV_X1Y0 MMCME3_ADV (Prop_MMCME3_ADV_CLKIN1_CLKOUT0)
-3.934 5.554 r pll_i/inst/mmcme3_adv_inst/CLKOUT0
net (fo=1, routed) 0.422 5.976 pll_i/inst/clk_out1_clk_wiz_0
BUFGCE_X1Y0 BUFGCE (Prop_BUFCE_BUFGCE_I_O)
0.091 6.067 r pll_i/inst/clkout1_buf/O
X2Y0 (CLOCK_ROOT) net (fo=3, routed) 1.218 7.285 pll_clk
SLICE_X49Y58 FDRE r bar_reg__0/C
clock pessimism 0.051 7.336
clock uncertainty -0.062 7.274
SLICE_X49Y58 FDRE (Setup_DFF2_SLICEL_C_D)
0.067 7.341 bar_reg__0
-------------------------------------------------------------------
required time 7.341
arrival time -0.053
-------------------------------------------------------------------
slack 7.288
前の例と比較すると、 pathsの違いは 1 つだけです。 PLL ( reportでは MMCME3_ADV_X1Y0 として表示されます) は、外部 clock pin と global clock bufferの間に挿入されています。
この PLL には劇的な効果があります。 source clock pathでは PLLの delay が −4.474 ns、 destination clock path では同じ delay が −3.934 nsです。この負の delay は、 input pinで global clock が clock よりわずかに早くなるように、 PLL が clock edge を調整したことを表しています。 global clock buffer の output での clockの合計 delay は、 source clock pathでは −0.616 ns であることに注意してください。同じ delay が destination clock pathの 7.285 ns です。これは、2 番目の clock edge ( 8 ns) より 0.715 ns 前です。
つまり、外部 clock pin と global clock ( logicに配信される) は、両方の clock pathsでほぼ同じ時間差を持っています。 1 つの clock path は最大の delaysで計算され、2 つ目の clock path は最小の delaysで計算されましたが、合計の結果はほぼ同じです。
これは偶然ではありません: PLL は global clock output を referenceとして使用しているため、 global clock bufferの input の phase を調整して clock input pinとの関係を確保しています。最小の delays と最大の delays の違いは、 PLLによって補正されます。 timing の計算は、最速のケースと最も遅いケースの差がちょうど 0.1 nsであるという事実によってこれを反映しています。前の例では、 PLL (0.575 ns、前ページの「Clock pessimism removal」を参照) がなかったため、この違いはさらに大きくなりました。
global clock が外部 inputの前に約 0.6 ns に調整され、他の値が調整されない理由は別の話です。これにより、多くの場合 I/O pins に関連する timing constraints の実現が容易になるため、ツールはこの選択を自動的に行います。それにもかかわらず、すべての FPGAs には、この delayを操作するオプションがあります。
2 つの related clocks
多くの場合、 logic design には複数の clockが必要です。 FPGA design に複数の clocks が存在することは、それ自体がトピックであり、 clock domainsの紹介で説明されています。 clock domains と timingの 2 つのトピックは切り離すことができないため、ここで先に進む前に、その概要を (場合によっては簡単に) 読んでおくことをお勧めします。これら 2 つのトピックは密接な関係にあるため、その紹介とこの一連のページには重複部分があります。
以下の説明では、「 signal X は @clkと同期しています」などの表現をよく使用します。これは、 X が、「clk」という名前を持つ clock の rising edge に応答してのみ値を変更する flip-flop の output であることを意味します ( asynchronous resetsを除きますが、それは無関係です)。当然、2 つの signals が同じ clockに応答する flip-flops の outputs である場合、この 2 つの signals は「同じ clockと同期」します。
ここで、同じ PLLによって生成された 2 つの clocks を見ていきます。ほとんどの場合、これら 2 つの clocks は related clocksと見なされるため、これは興味深いことです。これが興味深い理由を理解するために、これらの clocksの 1 つと同期している 1 つの flip-flop があり、別の flip-flop が 2 番目の clockと同期しているとしましょう。この場合、同じ clockと同期しているかのように、これら 2 つの flip-flops の間に signals を接続しても問題ありません。この場合、 FPGA ツールは、 timing の要件が満たされていることを確認します。
複数の clocksを操作する方法をよりよく理解するために、 related clocks と unrelated clocksに関する別のページがあります。そのページは clock domain crossingの紹介です。ここでは、 related clocksの timing の側面、特にそのような clocksに関連する timing report に焦点を当てます。
以下の timing reports を生成するために、この例では別の PLL (つまり Clocking Wizard IP) が使用されています。この新しい PLL の名前は clk_wiz_1です。次の Verilog コードが使用されました。
module top(
input clk,
input foo,
output reg bar_reg
);
reg foo_reg;
reg bar;
wire pll_clk_8, pll_clk_6;
clk_wiz_1 pll_i
(.clk_in1(clk),
.clk_out1(pll_clk_8),
.clk_out2(pll_clk_6));
always @(posedge pll_clk_8)
foo_reg <= foo;
always @(posedge pll_clk_6)
begin
bar <= !foo_reg;
bar_reg <= bar;
end
以前のように、この PLL (つまり @clk) の input は 250 MHzですが、2 つの outputsがあります。 1 つは 125 MHz で実行される @pll_clk_8に接続されます (つまり、 clock period は 8 nsであるため、 signalの名前です)。これは、前の例の @pll_clkとまったく同じです。 2 番目の output は @pll_clk_6に接続されており、 clock period は 6 nsと等しく、これはおよそ 166.67 MHzです。
@pll_clk_8 と @pll_clk_6 は同じ PLLによって生成されるため、 related clocksです。
clk_wiz_1 では、特に前の例との一貫性を保つために、 phase alignment オプションも有効になっています。そして、それについて疑問があった場合： 以前と同じ timing constraintが 1 つだけあります。
create_clock -period 4.000 -name clk [get_ports clk]
clock summaryを理解する
すべての clocks に関する情報は、 timing reportの冒頭にまとめられています。ここでこのことを取り上げたのは、 clock summary は複数の clockがあるとより興味深いものになるからです。すべての FPGA ツールは、 reportでこの種の要約を生成するので、この部分を確認するのは常に良い考えです。
-------------------------------------------------------------------------
| Clock Summary
| -------------
-------------------------------------------------------------------------
Clock Waveform(ns) Period(ns) Frequency(MHz)
----- ------------ ---------- --------------
clk {0.000 2.000} 4.000 250.000
clk_out1_clk_wiz_1 {0.000 4.000} 8.000 125.000
clk_out2_clk_wiz_1 {0.000 3.000} 6.000 166.667
clkfbout_clk_wiz_1 {0.000 2.000} 4.000 250.000
この部分の主な利点は、理解しやすいことと、 timing constraintsに関する最も一般的な間違いを簡単に確認できることです。 clock の周波数が正しい場合。
この clock summary は、 timing constraint が正しく解釈されたことを示しています。 clkという名前で定義された 1 つの外部 clock があり、その clock period は 4 nsです。さらに、次の 3 つの派生 clocksがあります。 clk_out1_clk_wiz_1、 clk_out2_clk_wiz_1 、 clkfbout_clk_wiz_1。それらの名前が示すように、 clk_wiz_1という名前の PLL のために、それらは自動的に生成されました。
最初の 2 つの clocks (clk_out1_clk_wiz_1 と clk_out2_clk_wiz_1) は、 PLLの 2 つの outputs です。 3 番目の clock (clkfbout_clk_wiz_1) は、 PLL によって使用され、 global clocks の phase を外部 clockに調整します。 clkfbout_clk_wiz_1 は @clkと同じ周波数です。
phase alignment オプションを有効にすると、 PLLの feedback clock (clkfbout_clk_wiz_1) が global clock bufferに接続されます。 PLLs は常に input clock と feedback clock の間で同期するため (これらの clocksを整列させるか、それらの間で固定の delay を維持することによって)、 clkfbout_clk_wiz_1 が global clock であるという事実は、 input clock と他の output clocksの間の既知の delay も保証します。
clk_out1_clk_wiz_1、 clk_out2_clk_wiz_1 、および clkfbout_clk_wiz_1 は、実際に存在する clocks を定義していないことに注意することが重要です。これらは、ソフトウェアが timing の計算に使用する clocks の単なるシンボルです。これらの clocks が理論上のものであることを示す 1 つのことは、 clock summaryに示されている waveformsです。 これらの waveforms は、これらの clocksのそれぞれの duty cycle を反映しています。しかし、4 つの clocks (clk と 3 つの理論上の clocks) のすべてが正確に 0 nsに rising edge を持っているということは何の意味もありません。特に、この 4 台の clocks が完全に揃っているわけではありません。位置合わせされていても、 timing の計算で表示され、実際の位置合わせは完全ではありません。
これらの理論上の clocks がどのように使用されるかについては、これらの clocksのうちの 2 つを含む timing 計算に関連して以下で説明します。
これらの理論上の clocks に関するもう 1 つの重要な点は、それらを作成するための明示的な timing constraint がないことです。 clk_out1_clk_wiz_* の作成は、 designの sources またはツールによって作成されたファイルのどこにも存在しません。ほとんどの場合、 clock path の delays はこの方法では正しく説明されないため、そのような timing constraintを書き込もうとするのは正しくありません。このような constraints を記述すると、 clocks 間の相対 timing がツールによって正しく計算されず、 related clock domains 間の paths が正しく計算されません。
したがって、1 つの timing constraint だけが、すべての PLLの output clocksに対して timing constraints を自動的に生成する必要があります。
2 つの related clocksを備えた timing report
上記の Verilog コードから明らかなように、 @foo_reg は @pll_clk_8と同期しており、 @bar は @pll_clk_6と同期しています。したがって、 @bar を更新するステートメントには clock domain crossingが含まれます。
bar <= !foo_reg;
2 つの clocks は related clocksであるため、ツールは、この計算によって @barの timing 要件が満たされていることを確認します ( tsuの場合)。
Slack (MET) : 0.475ns (required time - arrival time)
Source: foo_reg_reg/C
(rising edge-triggered cell FDRE clocked by clk_out1_clk_wiz_1 {rise@0.000ns fall@4.000ns period=8.000ns})
Destination: bar_reg__0/D
(rising edge-triggered cell FDRE clocked by clk_out2_clk_wiz_1 {rise@0.000ns fall@3.000ns period=6.000ns})
Path Group: clk_out2_clk_wiz_1
Path Type: Setup (Max at Slow Process Corner)
Requirement: 2.000ns (clk_out2_clk_wiz_1 rise@18.000ns - clk_out1_clk_wiz_1 rise@16.000ns)
Data Path Delay: 1.160ns (logic 0.307ns (26.466%) route 0.853ns (73.534%))
Logic Levels: 1 (LUT1=1)
Clock Path Skew: -0.250ns (DCD - SCD + CPR)
Destination Clock Delay (DCD): -0.681ns = ( 17.319 - 18.000 )
Source Clock Delay (SCD): -0.600ns = ( 15.400 - 16.000 )
Clock Pessimism Removal (CPR): -0.169ns
Clock Uncertainty: 0.182ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE
Total System Jitter (TSJ): 0.071ns
Discrete Jitter (DJ): 0.103ns
Phase Error (PE): 0.120ns
Clock Net Delay (Source): 1.369ns (routing 0.002ns, distribution 1.367ns)
Clock Net Delay (Destination): 1.208ns (routing 0.002ns, distribution 1.206ns)
Location Delay type Incr(ns) Path(ns) Netlist Resource(s)
------------------------------------------------------------------- -------------------
(clock clk_out1_clk_wiz_1 rise edge)
16.000 16.000 r
AG12 0.000 16.000 r clk (IN)
net (fo=0) 0.000 16.000 pll_i/inst/clkin1_ibuf/I
AG12 INBUF (Prop_INBUF_HRIO_PAD_O)
0.738 16.738 r pll_i/inst/clkin1_ibuf/INBUF_INST/O
net (fo=1, routed) 0.105 16.843 pll_i/inst/clkin1_ibuf/OUT
AG12 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O)
0.049 16.892 r pll_i/inst/clkin1_ibuf/IBUFCTRL_INST/O
net (fo=1, routed) 0.975 17.867 pll_i/inst/clk_in1_clk_wiz_1
MMCME3_ADV_X1Y0 MMCME3_ADV (Prop_MMCME3_ADV_CLKIN1_CLKOUT0)
-4.438 13.429 r pll_i/inst/mmcme3_adv_inst/CLKOUT0
net (fo=1, routed) 0.501 13.930 pll_i/inst/clk_out1_clk_wiz_1
BUFGCE_X1Y1 BUFGCE (Prop_BUFCE_BUFGCE_I_O)
0.101 14.031 r pll_i/inst/clkout1_buf/O
X2Y0 (CLOCK_ROOT) net (fo=1, routed) 1.369 15.400 pll_clk_8
SLICE_X49Y58 FDRE r foo_reg_reg/C
------------------------------------------------------------------- -------------------
SLICE_X49Y58 FDRE (Prop_EFF_SLICEL_C_Q)
0.139 15.539 f foo_reg_reg/Q
net (fo=1, routed) 0.807 16.346 foo_reg
SLICE_X49Y58 LUT1 (Prop_D5LUT_SLICEL_I0_O)
0.168 16.514 r bar__0_i_1/O
net (fo=1, routed) 0.046 16.560 p_0_in
SLICE_X49Y58 FDRE r bar_reg__0/D
------------------------------------------------------------------- -------------------
(clock clk_out2_clk_wiz_1 rise edge)
18.000 18.000 r
AG12 0.000 18.000 r clk (IN)
net (fo=0) 0.000 18.000 pll_i/inst/clkin1_ibuf/I
AG12 INBUF (Prop_INBUF_HRIO_PAD_O)
0.515 18.515 r pll_i/inst/clkin1_ibuf/INBUF_INST/O
net (fo=1, routed) 0.066 18.581 pll_i/inst/clkin1_ibuf/OUT
AG12 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O)
0.034 18.615 r pll_i/inst/clkin1_ibuf/IBUFCTRL_INST/O
net (fo=1, routed) 0.873 19.488 pll_i/inst/clk_in1_clk_wiz_1
MMCME3_ADV_X1Y0 MMCME3_ADV (Prop_MMCME3_ADV_CLKIN1_CLKOUT1)
-3.890 15.598 r pll_i/inst/mmcme3_adv_inst/CLKOUT1
net (fo=1, routed) 0.422 16.020 pll_i/inst/clk_out2_clk_wiz_1
BUFGCE_X1Y0 BUFGCE (Prop_BUFCE_BUFGCE_I_O)
0.091 16.111 r pll_i/inst/clkout2_buf/O
X2Y0 (CLOCK_ROOT) net (fo=2, routed) 1.208 17.319 pll_clk_6
SLICE_X49Y58 FDRE r bar_reg__0/C
clock pessimism -0.169 17.150
clock uncertainty -0.182 16.967
SLICE_X49Y58 FDRE (Setup_DFF2_SLICEL_C_D)
0.067 17.034 bar_reg__0
-------------------------------------------------------------------
required time 17.034
arrival time -16.560
-------------------------------------------------------------------
slack 0.475
前述のように、 timing の計算は架空の実験であり、架空のストップウォッチが clock edgesと共に開始されます。前の例では、このストップウォッチは 0 nsで開始されました。しかし、この計算では、 16 nsで clock edge から始まります。これは、2 つの clocks の clock periods が等しくないためです。計算は、最初の clock と 2 番目の clockの間の最悪の組み合わせで行われます。
最初の clockの rising edges は、 0 ns、 8 ns、 16 ns、 24 ns などにあります。 2 番目の clockの rising edges は、 0 ns、 6 ns、 12 ns、 18 ns、 24 ns などにあります。したがって、最初の clock と 2 番目の clock の間の最小の時間差は、最初の clockの 16 ns と 2 番目の clockの 18 nsです。これが、この timing 計算が調べる状況です。
これは、 data path が 500 MHzと同様に 2 ns程度に制限されていることを意味します。これは非常に厳しい要件ですが、 data pathには LUT が 1 つしかなく、両方の flip-flops が同じ slice上にあるため、この目標を達成するのは簡単でした。ただし、この例は、 related clocksでうまく機能する周波数を選択することが重要である理由を示しています。多くの場合、一方の clockの周波数は、他方の clockの周波数の倍数として選択されます。これを行うと、この例の 2 ns ギャップのようなシナリオが回避されます。
ちなみに、相性の良い周波数を選べない場合は、 clocks を unrelated clocksとして扱うのが解決策です。
派生した clocks
clk_out1_clk_wiz_1 と clk_out2_clk_wiz_1 は理論上の clocksであると前述しましたが、この事実が timing reportに反映されているのは次のとおりです。 どちらの paths も、外部 pin (AG12) を開始点として計算されることに注意してください。それはどのように理にかなっていますか？実際には、この pin の signal は reference clockであり、これら 2 つの clocksのいずれでもありません。
では、 clk_out1_clk_wiz_1 を例にとってみましょう。 計算の背後にある考え方は、外部 pinに 125 MHz を持つ clock があるかのように装うことです。実際には、 125 MHz を持つ clock は、 PLLの output 、つまり MMCME3_ADV_X1Y0の output にのみ存在します。ただし、 timing の計算に PLLの周波数操作を含める代わりに、理論上の clock が使用されます。この clock には、 0 nsから始まる理想的な waveform があります。 PLL は、 clockの周波数を変更せず、 delaysを追加するだけであるかのように扱われます。
したがって、理論上の clock (たとえば clk_out1_clk_wiz_1) は、 clock の waveform (周波数、 duty cycle、 jitter など) を定義します。ただし、この理論上の clock は、 FPGA上に実際の signals として存在する他の clocks との timing の関係を定義していません。
では、 @pll_clk_6 と @pll_clk_8 が実際に整列していることをどのように確認できますか?その答えは、これらの clocksの実際の timing と理想的な timing を比較することにあります。たとえば、 clk_out1_clk_wiz_1の理論上の clock edge は、上記の計算では 16 ns にあります。一方、 clk_out2_clk_wiz_1の clock edge は 18 nsにあり、これは 2 nsによって後になります。次に、 global clock treeの outputs の clock edges を比較してみましょう。 最初の clockの clock edge は、 timing reportによると 15.400 nsに到着します。2 番目の clock edgeの場合、 report は 17.319 nsを示します。したがって、計算によると、時間差は 2 nsではなく 1.919 ns です。これは、理想的な差より 0.081 ns だけ少ないです。したがって、 clocks は確実に揃っています。
clockが 1 つしかない前の例と比較してみましょう。 2 つの clock edges 間の理想的な時間差は、 clock period、つまり 8 nsでした。しかし、関連する timing report (上記参照) によると、最初の clock edge は −0.616 nsに到着し、2 番目の clock edge は 7.285 nsに到着しました。理想の時差は 8 nsでしたが、実際は 7.901 nsでした。したがって、2 番目の clock edge は、 0.099 nsの予想よりも早かったのです。
ということで、 related clocks2台で理想の時差からの流用は 0.081 ns。 clockが 1 台だけの場合、この流用は 0.099 nsとほぼ同じでした。どちらの場合も、この転用の理由は、最初の clock edge の計算が最大 delaysで行われ、最小 delays が 2 番目の clock edgeに使用されるためです。
したがって、結論として、 @pll_clk_6 と @pll_clk_8 は、1 つの clockであるかのようにほぼ同じ精度で位置合わせされます。
これらの clocks は、 PLLの phase alignmentを有効にするオプションがなくても相互に調整されていることに注意してください。 PLL の outputs は、通常、とにかく整列されます。このアライメントは、 fanoutに関係なく、ほぼ同じ delaysを持つ global clock buffers を使用することによって保証されます。つまり、これらの clock buffers がそれぞれ何台の logic elements に接続されていても、 PLLの output から宛先までの delay はほぼ同じです。
related clocksについて学んだこと
この timing report の分析は、2 つの related clock domains 間の path が、 clock domain内の path とほぼ同等であることを示しています。それでも、まったく同じではありません。特に、 Clock Uncertainty は 0.062 ns から 0.182 nsになりました。各 clock には独自の jitterがあり、アライメントも完璧ではありません。
この timing report は、2 台の clocks の位置合わせが timing の計算にどのように反映されるかも示しました。
FPGA designに clock domain crossings がある場合、 timing reportでこれらの clocks 間の相互作用を調べることをお勧めします。目的は、ツールが clocks を期待どおりに処理することを確認することです。以下の 2 点を確認してください。
- logic が 2 つの clocks を related clocksと見なす場合: これらの clocks間のすべての paths で timing 計算があることを確認します。
- logic が 2 つの clocks を unrelated clocksと見なす場合: これら 2 つの clocksの間の paths で timing 計算が行われていないことを確認します。
Vivado は、 designの clock domain crossingsをグラフィカルに表示する Clock Interaction Reportを作成し、そのような各 crossing がツールによってどのように処理されるかを示します。 Quartus Proの CDC Viewerなど、他の FPGA ツールにも同様の機能があります。可能であれば、このレポートを作成して調べることをお勧めします。
clocks がアラインされているかどうかも確認する必要があります。 design がアラインされていない clockを誤って使用すると、 timing constraintsを達成する際に不要な問題が発生する可能性があります。たとえば、 @clk と @pll_clk_8の間に path がある場合、ツールは timing constraintsを強制するため、この path が確実に動作するようになります。ただし、 @clk は PLLに入る reference clock であり、 @pll_clk_8 はこの PLLの output であることに注意してください。したがって、これら 2 つの clocks は整列していません。その結果、この pathの timing constraints を実現するために、ツールが不必要にハードに動作する可能性があります。他の paths は、この不必要な努力のために timing constraints を達成できない可能性があります。
繰り返しますが、 clock domains のトピックは、この一連のページでカバーされています。
thold も重要
これまでに示したすべての timing 計算は、 tsu 要件に関連していました。ツールが timing constraintsを達成できない場合、ほとんどの場合、少なくとも 1 つの path が tsuの要件を達成できなかったことが原因であるため、この要件に注目するのは自然なことです。
それにもかかわらず、 thold を念頭に置いておくことが重要です。 この要件を満たすために、ツールは routing delayを追加することで data path を人為的に遅くすることがあります。そのため、 thold 要件が timing constraintsの達成に失敗した理由として言及されることはめったにありませんが、この要件が失敗の隠れた理由である可能性があります。
実際、2 つの flip-flopsを接続する wire の routing delay にも関連する出来事がありました。 1 つの clockのみが関与するすべての timing reports では、この wire は同じ slice (SLICE_X49Y58) 内にあります。したがって、この wire の delay は、これらすべての reportsでは 0.241 ns でした。ただし、2 つの clocks が pathに関与すると、この delay は 0.807 nsまで上がります。
説明によると、 0.241 ns は、同じ sliceに配置された 2 つの flip-flops 間で達成できる最小の delay です。より長い delay (0.807 ns) は、この wireの異なる routing の結果です。これは偶然に起こったわけではありません。 ツールは、 thold の要件を満たすために、意図的にこの routing を長くしました。これは、 reportの「Data Path Delay」行にも反映されています。 logic の delay は 26.5%だけで、残りは routingです。それだけでも、何かが起こったというサインです。これについては、以下で詳しく説明します。
thold 要件の分析
この一連のページの理論的なページから、 thold は 2 番目の flip-flop 上の data input が clock edgeの後に安定していなければならない時間の長さであることを思い出してください。 thold に違反している状況を説明しましょう。 clock edge が最初の flip-flopに到達し、2 番目の flip-flop もほぼ同時に clock edge を受信します (これらの clock edges は、同じ clock または異なる clocksから発信される可能性があることに注意してください)。 clock edgeに応答して、最初の flip-flop は delay (clock-to-output) の後に output を更新します。しかし、更新された値が 2 番目の flip-flop に到達するのが早すぎます。その結果、この flip-flop は以前の値を確実にサンプリングしません。 2 番目の flip-flop が clock edgeへの反応を完了する前に、新しい値が到着しました。つまり、 thold 要件に違反しています。
同じ clock が両方の flip-flopsで使用されている場合、これは主に clock skewが原因で発生する可能性があります。 clock edge が最初の flip-flopより早く到着した場合、最初の flip-flop が output を変更するのが早すぎる可能性があります。これにより、更新された signal が 2 番目の flip-flop に到達して thold の要件に違反する可能性が生じます。両方の flip-flopsに到達するのは同じ clock edge であるため、 clockの頻度や clock jitterの量のいずれにも意味がないことに注意してください。別の delay (つまり clock skew) だけが役割を果たします。
ただし、以下の timing analysis については、2 つの clocksを含む最後の例を使用します。 @pll_clk_8 と @pll_clk_6。 1 つの clock を備えた timing analysis も同様ですが、1 つの clockで thold の要件を満たすのは簡単すぎるため、それほど興味深いものではありません。
したがって、これから検討する timing report は、2 つの related clocks用に作られています。この 2 つの clocks は周波数が異なり、以前と同様に、1 番目の clockの clock edge と 2 番目の clockの clock edgeの時間の組み合わせが異なります。ただし、 tsuの計算とは異なり、 thold の最悪のケースは、両方の clock edges が 0 nsにある場合です。 thold の違反は、2 つの clock edges がほぼ同時に発生した場合に発生するため、これより悪い組み合わせは他にありません。
これらの洞察を手元に置いて、 timing reportを見てみましょう。
Slack (MET) : 0.093ns (arrival time - required time) Source: foo_reg_reg/C (rising edge-triggered cell FDRE clocked by clk_out1_clk_wiz_1 {rise@0.000ns fall@4.000ns period=8.000ns}) Destination: bar_reg__0/D (rising edge-triggered cell FDRE clocked by clk_out2_clk_wiz_1 {rise@0.000ns fall@3.000ns period=6.000ns}) Path Group: clk_out2_clk_wiz_1 Path Type: Hold (Min at Fast Process Corner) Requirement: 0.000ns (clk_out2_clk_wiz_1 rise@0.000ns - clk_out1_clk_wiz_1 rise@0.000ns) Data Path Delay: 0.458ns (logic 0.104ns (22.707%) route 0.354ns (77.293%)) Logic Levels: 1 (LUT1=1) Clock Path Skew: 0.127ns (DCD - SCD - CPR) Destination Clock Delay (DCD): -0.542ns Source Clock Delay (SCD): -0.248ns Clock Pessimism Removal (CPR): -0.421ns Clock Uncertainty: 0.182ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE Total System Jitter (TSJ): 0.071ns Discrete Jitter (DJ): 0.103ns Phase Error (PE): 0.120ns Clock Net Delay (Source): 0.495ns (routing 0.002ns, distribution 0.493ns) Clock Net Delay (Destination): 0.576ns (routing 0.002ns, distribution 0.574ns) Location Delay type Incr(ns) Path(ns) Netlist Resource(s) ------------------------------------------------------------------- ------------------- (clock clk_out1_clk_wiz_1 rise edge) 0.000 0.000 r AG12 0.000 0.000 r clk (IN) net (fo=0) 0.000 0.000 pll_i/inst/clkin1_ibuf/I AG12 INBUF (Prop_INBUF_HRIO_PAD_O) 0.339 0.339 r pll_i/inst/clkin1_ibuf/INBUF_INST/O net (fo=1, routed) 0.025 0.364 pll_i/inst/clkin1_ibuf/OUT AG12 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O) 0.015 0.379 r pll_i/inst/clkin1_ibuf/IBUFCTRL_INST/O net (fo=1, routed) 0.405 0.784 pll_i/inst/clk_in1_clk_wiz_1 MMCME3_ADV_X1Y0 MMCME3_ADV (Prop_MMCME3_ADV_CLKIN1_CLKOUT0) -1.721 -0.937 r pll_i/inst/mmcme3_adv_inst/CLKOUT0 net (fo=1, routed) 0.167 -0.770 pll_i/inst/clk_out1_clk_wiz_1 BUFGCE_X1Y1 BUFGCE (Prop_BUFCE_BUFGCE_I_O) 0.027 -0.743 r pll_i/inst/clkout1_buf/O X2Y0 (CLOCK_ROOT) net (fo=1, routed) 0.495 -0.248 pll_clk_8 SLICE_X49Y58 FDRE r foo_reg_reg/C ------------------------------------------------------------------- ------------------- SLICE_X49Y58 FDRE (Prop_EFF_SLICEL_C_Q) 0.049 -0.199 f foo_reg_reg/Q net (fo=1, routed) 0.343 0.144 foo_reg SLICE_X49Y58 LUT1 (Prop_D5LUT_SLICEL_I0_O) 0.055 0.199 r bar__0_i_1/O net (fo=1, routed) 0.011 0.210 p_0_in SLICE_X49Y58 FDRE r bar_reg__0/D ------------------------------------------------------------------- ------------------- (clock clk_out2_clk_wiz_1 rise edge) 0.000 0.000 r AG12 0.000 0.000 r clk (IN) net (fo=0) 0.000 0.000 pll_i/inst/clkin1_ibuf/I AG12 INBUF (Prop_INBUF_HRIO_PAD_O) 0.595 0.595 r pll_i/inst/clkin1_ibuf/INBUF_INST/O net (fo=1, routed) 0.042 0.637 pll_i/inst/clkin1_ibuf/OUT AG12 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O) 0.022 0.659 r pll_i/inst/clkin1_ibuf/IBUFCTRL_INST/O net (fo=1, routed) 0.457 1.116 pll_i/inst/clk_in1_clk_wiz_1 MMCME3_ADV_X1Y0 MMCME3_ADV (Prop_MMCME3_ADV_CLKIN1_CLKOUT1) -2.474 -1.358 r pll_i/inst/mmcme3_adv_inst/CLKOUT1 net (fo=1, routed) 0.209 -1.149 pll_i/inst/clk_out2_clk_wiz_1 BUFGCE_X1Y0 BUFGCE (Prop_BUFCE_BUFGCE_I_O) 0.031 -1.118 r pll_i/inst/clkout2_buf/O X2Y0 (CLOCK_ROOT) net (fo=2, routed) 0.576 -0.542 pll_clk_6 SLICE_X49Y58 FDRE r bar_reg__0/C clock pessimism 0.421 -0.121 clock uncertainty 0.182 0.061 SLICE_X49Y58 FDRE (Hold_DFF2_SLICEL_C_D) 0.056 0.117 bar_reg__0 ------------------------------------------------------------------- required time -0.117 arrival time 0.210 ------------------------------------------------------------------- slack 0.093
まず、明らかな違いがいくつかあります。 Path Type は Holdであり、以前の Setup ではありません。それは予想されます。次に、「Min at Fast Process Corner」と表示されます。これは、 setup pathの場合とは反対です。 この計算では、 data pathの最大 delays ではなく、最小 delaysを使用します。これは、 data input の変更が早すぎる状況に関する最悪のケースの計算に適しています。
Requirement は hold pathの典型である 0 nsです。 clocks の周波数は、ここでは役割を果たしません。 調査されるシナリオは、両方の clocks が同時に rising edge を持っている場合です。
clock pathsに関しては、 source clock path の各コンポーネントの delays は、 destination clock path の同じ delays より一貫して短い (長くない) ことに注意してください。繰り返しになりますが、これはこの計算の目的と一致しています。最悪のケースは、 clock edge が 2 番目の flip-flopに到着するのに比べて、 data の変更が早すぎる場合です。 Multi-corner timing analysis については前ページで説明しました。
しかし、この timing report で最も重要なことは、 slack が小さいことです。 0.093 nsのみ。これは多くの場合、要件を満たすためにツールが努力をしなければならなかったことを示しています。ただし、小さな slack は、必ずしも解決が必要な問題があったことを示しているわけではないことに注意してください。
timing analysis が thold用に作られている場合、小さな slack は非常に一般的です。では、なぜこの path が疑わしいのでしょうか?上記のように、主に、同じ slice (SLICE_X49Y58) 上の 2 つの flip-flops 間の routing delay が大きいためです。 place and routeの初期段階で、ソフトウェアがこれら 2 つの flip-flops間の thold 要件を満たしていないことを検出した可能性があります。では、これはどのように修正されたのでしょうか。
thold の要件を満たしていないということは、2 番目の flip-flopの clock edge に比べて、 data signal の到着が早すぎることを意味します。これは、 data pathに delay を人為的に追加することで修正されます。その結果、 data input は少し遅れて 2 番目の flip-flopで値を変更します。ツールにより、2 つの flip-flops 間の配線が長くなったと思われます。これにより、 routing delayが増加し、 tholdの問題が解決されます。このような delay の増加は、 tsu の要件を満たすために問題を引き起こす可能性がありましたが、この場合、そのような問題はありませんでした。 この pathに対して timing constraint を実現しました。 (つまり、 tsu と thold の両方の要件が満たされました)。
それにもかかわらず、この例は、 thold の問題を解決する必要性が、 tsuとは一見関係のない問題を引き起こす可能性があることを示しています。 logic delay と routing delay の間の pathの比率が非常に低い場合、これは心に留めておくべきことです。もちろん、大きな routing delay、特に高い fan-outには他の理由が考えられます。しかし、 fan-out が低い場合 (この場合、 fan-out が 1の場合)、 thold の問題を解決するためにツールによって大きな routing delay が意図的に挿入されたかどうかを尋ねる価値があります。
しかし、なぜ clocksが 2 台の場合にのみ thold に問題があったのでしょうか。答えは、2 台の clocksを使用すると、 clock edges が 2 台の flip-flopsのそれぞれにいつ到着するかについて、より大きな不確実性があるということです。この不確実性には、いくつかの要因、特に clock skew と jitterが関係しています。 thold の計算は 0 ns から 0 nsまで行われるため、この計算は clock edges がいつ到着するかについての小さな不確実性により敏感です。
したがって、2 台の related clocks に関連する不確実性は、 thold の要件を満たすために、多くの場合、是正措置を必要とします。もちろん、これらの修正はツールによって自動的に行われます。ただし、 timing constraintsを達成するのに問題がある場合は、これらの修正に注意することが重要です。
概要
このシリーズの最後の 2 ページでは、すべて特定の timing constraintの結果である timing reports の例をいくつか示しました。これらすべての timing reports は、 logicの具体的で単純な例にも関連していました。これらの例が、 timingの基本を理解するのに役立つことを願っています。
この時点で、複数の LUTを含む paths に同じ原則がどのように適用されるかを確認するために、独自の designの timing reports を調べることをお勧めします。
次のページでは、 timing の問題とその解決方法について説明します。