このページは、タイミングに関する連載ページの一部です。前のページでは、タイミング制約(timing constraints)の背後にある理論の基礎を説明しました。次のステップは、その理論をどのように適用するかを見ることです。
概要
このページでは、クロックの周波数を定義する最も重要なタイミング制約を紹介します。続いて、タイミングレポートに含まれるパス(path)解析の詳細な例を見ていきます。
タイミングレポートの解析内容を詳しく見ることは、高度な話題のように思えるかもしれません。しかし、実際はそうではありません。タイミング制約の目的は、ツールによる回路設計のタイミング解析を制御し、満たす必要のある正確な要件を設定することです。つまり、タイミング制約を理解するには、タイミング解析の中身を見る必要があります。そして、タイミング解析の結果はタイミングレポートに表示されます。
また、タイミング制約を書くだけではまったく不十分です。それらの制約が設計上で正しく機能しているかを検証できることが重要です。そのような検証は、タイミングレポートを深く理解していなければできません。この理解がないと、本来の目的を果たしていないタイミング制約を誤って信頼してしまい、論理設計がなぜ正しく動作しないのかと疑問に思うことになりかねません。
すべての FPGA ツールはタイミングレポートをテキストファイルとして生成し、ここで示すのはそのレポートです。ツールには、まったく同じ情報を表示するグラフィカルインターフェースもあります。このグラフィカルインターフェースは、役に立つこともあれば、かえって混乱を招くこともあります。そのため、まずはテキストベースのレポートを扱うことが重要な第一歩です。
周期制約
最も有用なタイミング制約は周期制約(period constraint)です。これは、ツールにクロック信号の周波数を伝えます。
たとえば、論理設計が次の Verilog モジュールだけで構成されているとします。
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
この Verilog から、clk がクロックとして使われており、この信号が外部ポート(つまり FPGA の物理ピンに接続されている)であることがわかります。
clk の周波数が 250 MHz(周期 4 ns)であれば、次のようなタイミング制約が必要です。
create_clock -period 4 -name clk [get_ports clk]
このコマンドの意味は次のとおりです。「clk と呼ばれる I/O ポートにクロックがあります。このクロックの周期は 4 ns です。このクロックを参照する他のタイミング制約がある場合、その制約では名前「clk」を使います」。
注記:
- 「period」パラメータには、クロックの周期を指定します。「余分な安全策」として小さい値を選んではいけません(過度な制約、overconstraining)。そうする理由は決してありません。もしそれが役に立つ場合には、解決すべき別の問題があります。
- 非同期リセット(asynchronous reset)を使っている場合、create_clock は、そのリセット信号に関するタイミング要件の違反からフリップフロップを保護しません。これについては別のページで説明しています。
タイミング解析
それでは、foo_reg で始まり bar で終わるパスについて、Vivado のセットアップ要件(setup requirement)のタイミング解析を見てみましょう。言い換えると、次の Verilog 式で生成されるパスです。
bar <= !foo_reg;
ここで示すタイミング解析は、次の 3 つの部分からなり、タイミングレポートにもこの順序で現れます。
- ヘッダー。パスのタイミング解析結果の要約と、いくつかの追加情報が含まれます。
- クロックエッジから、2 番目のフリップフロップ(この例では bar)の入力に安定した論理状態が現れるまでにかかる時間の計算。
- タイミング要件を満たすために、2 番目のフリップフロップの入力がいつまでに安定していればよいかを求める計算。
これらの 3 つの部分は、以下でそれぞれ示しながら説明します。タイミングレポートでは、各部分の間に目に見える区切りはないことに注意してください。特に、2 番目の部分がどこで終わり、3 番目の部分がどこから始まるのかは、レポートを見ただけではわかりません。3 番目の部分の始まりは、その内容から読み手が判断する必要があります。
ここでは Vivado のタイミングレポートを示していますが、Quartus や他のいくつかの FPGA ツールも同じ方法を採用しています。他のツールのタイミングレポートに記載される情報は、通常少し異なる形式で表示されます。ただし、その背後にある理論は同じです。したがって、この例を追ってみることは、他の FPGA ツールを使う場合にも役立ちます。
タイミングレポートの最初の部分はひとまず飛ばし、最初の 2 つの部分を説明してから、また戻ることにします。説明をこの順序で行うほうがわかりやすいからです。その前に、いくつか一般的な説明をしておきます。
タイミング解析の進め方
前のページで示した単純な静的タイミング解析とは異なり、実際のタイミング解析ではクロックの不完全さを考慮しなければなりません。そのため、遅延の計算はクロックの発生元、たとえばクロックの物理入力ピンから始めます。これは、データパスの遅延だけを考慮する単純なデータパス遅延の計算(前のページで示したもの)とは異なります。
ここでの理論的な実験は次のとおりです。クロックの発生元で、あるクロックエッジと同時にストップウォッチをスタートさせます。このクロックエッジが最初のフリップフロップまで伝わり、フリップフロップを動作させる間、ストップウォッチを進め続けます。このフリップフロップが出力を更新する時間も引き続き測定し、更新された信号を目的地まで追いかけます。その信号が 2 番目のフリップフロップに到達したところでストップウォッチを止めます。
次のステップは、結果が問題ないかを確認することです。tsu 要件の場合、これは、次のクロックエッジに対して信号が十分早く到着したかを意味します。
ただし、これは 2 番目のフリップフロップに届くクロックエッジです。それはいつ到着するのでしょうか。
それを調べるために、クロックの発生元で次のクロックエッジと同時に、もう一度ストップウォッチをスタートさせます。この 2 番目のクロックエッジが 2 番目のフリップフロップに到達したとき、ストップウォッチを止めます。出発点は同じですが、クロックエッジは後で発生し、さらにクロックエッジの目的地も異なります。
この理論的な実験の後、2 番目のフリップフロップにクロックエッジがいつ到着するかがわかります。tsu 要件を満たすには、このフリップフロップの入力が、このクロックエッジに対して十分早く安定している必要があります。
最初の理論的な実験のストップウォッチは、2 番目のフリップフロップでデータがいつ安定するかを示します。2 番目の実験のストップウォッチは、同じフリップフロップにクロックエッジがいつ到着するかを示します。残りは、この 2 つの数値を比較し、その差が tsu の要求より大きいかを確認するだけです。
この方法では、クロックに関連する不確実性を考慮に入れることができます。両方の理論的な実験に最悪ケースのシナリオを適用できるからです。セットアップ時間の計算では、最初のストップウォッチの実験にすべての遅延の上限値を使います。その結果、信号が 2 番目のフリップフロップの入力に到達し得る最も遅い時刻が計算に示されます。一方、2 番目のストップウォッチの実験では、すべての遅延の下限値を使います。その結果は、2 番目のクロックエッジが 2 番目のフリップフロップに到達し得る最も早い時刻です。
つまり、計算は、信号ができるだけ遅く到着し、クロックエッジができるだけ早く到着するシナリオに対して行われます。この条件でセットアップ時間の要件が満たされれば、この要件が常に満たされることは間違いありません。
ホールド時間(hold time)の計算では、その逆になります。最初の実験には最小遅延を使い、2 番目の実験には最大遅延を使います。
ソースパスの計算
前述のように、タイミングレポートの最初の部分は後で示します。それでは、タイミング解析の 2 番目の部分、つまりソースパス(source path)の計算を見ていきましょう。これは、次の 2 つの区間から構成されます。
- ソースクロックパス(Source Clock Path)は、FPGA のクロック入力ピンの立ち上がりエッジから始まり、その立ち上がりエッジが foo_reg のクロック入力に到達したところで終わります。
- データパスは、bar のデータ入力が新しい値に更新されるまで旅を続けます。この区間は、前のページで示した単純な静的タイミング解析に相当します。
この 2 つの区間を合わせると、FPGA の外部クロックピンでの立ち上がりエッジから、データが 2 番目のフリップフロップに到達するまでの時間が計算されます。
タイミングレポートの該当部分は次のとおりです。
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
------------------------------------------------------------------- -------------------
この部分の各行は、論理エレメントまたは配線を表します。「Delay type」が「net」のとき、その行は配線に対応します。この種の遅延はすべて配線遅延(routing delay)です。つまり、信号がある論理エレメントから別の論理エレメントまで伝わるのにかかる時間です。
「Incr」という列は、パス内の各エレメントがどれだけの遅延に寄与するかを示します。「Path」列は、その時点までの合計遅延を示します。
中央の水平線は、ソースクロックパスの終わりとデータパスの始まりを示しています。それでは、この 2 つのパスの遅延をもう少し詳しく見てみましょう。
最初の 7 つの遅延は、入力ピン AG12(このピンの物理的な位置)に関連しています。このレポートによると、入力ピンと、このピンに関連するロジックは、合計 1.731 ns の遅延に寄与しています。
グローバルクロックバッファは、入力から出力までさらに 0.101 ns を追加します。その後に、グローバルクロックの配線遅延が続きます。これは比較的大きな値で、1.389 ns です。これは、クロック信号が foo_reg のクロック入力に到達するまでの時間です。この遅延が大きい理由は、この信号を分配するためにグローバルクロックバッファとクロックツリー(clock tree)が使われるからです。これらの配線リソースは、FPGA の広い範囲へ、すべての宛先に同じ遅延でクロックを分配するためのものです。したがって、この例のようにクロックが到達する宛先が少数(クロックのファンアウト(fan-out)はわずか 3)であっても、遅延は大きくなります。
ここまでで、クロックはついに、フリップフロップを含むスライス(slice)に到達します。この例では、それは SLICE_X49Y58 です。これがソースクロックパスの終わりです。レポート内の水平線は、データパスの始まりを示します。前のページの例では、ここから単純な静的タイミング解析が始まります。
右側の Netlist Resources 列を見ると、水平線の上の行に「foo_reg_reg/C」、そのすぐ後の行に「foo_reg_reg/Q」とあります。したがって、水平線の次の行は、確かに foo_reg のフリップフロップのクロックから出力までの遅延(C から Q まで)です。この遅延は 0.138 ns です。「FDRE」は、Data、Reset、Enable を備えたフリップフロップ(Flip-flop with Data, Reset and Enable)を意味します。
その後に、LUT までの配線遅延(0.241 ns)、LUT 内部の伝搬遅延(propagation delay、0.244 ns)、2 番目のフリップフロップまでの配線遅延(0.046 ns)が続きます。すべてが単一のスライスに詰め込まれているため、配線遅延は非常に小さくなっています。
この部分をまとめると、外部ピンから最初のフリップフロップのクロック入力までクロックエッジが伝わるのに 3.221 ns かかりました。その後、更新された信号が 2 番目のフリップフロップの入力に届くまでに 0.669 ns かかりました(3.890 − 3.221 = 0.669 ns)。つまり、外部ピンのクロックエッジから、最終目的地(2 番目のフリップフロップのデータ入力)に信号が安定するまでの合計時間は 3.890 ns です(これは最悪ケースの計算であり、最大でこの値です)。
では、ここで「これは間に合ったのか?」と問いかけるときです。セットアップ時間の要件は満たされているでしょうか。
宛先クロックパス
この 2 番目の計算の目的は、外部ピンから 2 番目のフリップフロップのクロック入力まで、クロックエッジがどれだけ速く伝わるかを求めることです。
ここで注意:このクロックパスの宛先は2 番目のフリップフロップです。前の計算のクロックパスの宛先が最初のフリップフロップだったのと混同しないようにしてください。
他にも注目すべき違いがあります。
- クロックパスのみが計算されます。言い換えると、前の計算と比べて、水平線までの区間だけが考慮されます。
- 理論上のストップウォッチは 0 ではなく 4 ns からスタートします。これは、この計算の目的が、データ信号がセットアップ時間の要件を満たすのに十分早く到着するかを調べることだからです。したがって、計算は 2 番目のクロックエッジ、つまり上に示した clk のタイミング制約(create_clock コマンド)によれば 4 ns の時点から始まります。
- この区間の各コンポーネントの遅延は小さくなっています。この特定の例では、両方のフリップフロップが同じスライス上にあるため、両方の計算のクロックパスがまったく同じ経路であることがわかりやすいでしょう(通常はそうではありません)。これについては後で詳しく説明します。
- この計算の最後の 3 行(クロック悲観性(clock pessimism)、クロック不確かさ(clock uncertainty)、Setup_DFF2_SLICEL_C_D)は、論理コンポーネントではなくタイミングパラメータです。
タイミング解析の 3 番目の部分(宛先クロックパス、Destination Clock Path)は次のとおりです。
(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 を同じスライスに配置することを選んだため、この特定のケースでは、この解析のクロックパスは最初の解析と同じです。したがって、水平線までの論理エレメントの並びは、前の解析とまったく同じであることが容易にわかります。この並びの後には、計算を調整する 2 つのタイミングパラメータ、すなわちクロック悲観性とクロック不確かさがあります。これらについては、このページの後半で個別に説明します。
この計算の最後から 1 行前で、2 番目のクロックエッジが到達し得る最も早い時刻が得られます:最初のクロックエッジから 7.138 ns 後です。セットアップ時間の要件は、データ信号がこのクロックエッジより前に安定していなければならないというものです。どれだけ前かを指定するのが tsu です。したがって、データが安定していなければならない最も遅い時刻を求めるには、クロックの到着時刻から tsu を引きます。
上の例では、tsu は負の値で、−0.067 ns です。したがって、最終結果は 7.138 −(−0.067)= 7.205 ns です。言い換えると、データは最初のクロックエッジから遅くとも 7.205 ns 後までには、2 番目のフリップフロップで安定していなければなりません。
前の計算では、データはこのクロックエッジから遅くとも 3.890 ns 後には安定するという結果でした。つまり、十分間に合っています。要件と保証される値の差は 7.205 − 3.890 = 3.315 ns です。言い換えれば、スラック(slack)は 3.315 ns です。
タイミング解析のまとめ
ここで、このパスのタイミングレポートの最初の部分に戻りましょう。この部分は、上に示した計算の前にあり、主な結果をまとめています。さらに、このヘッダーは、計算に現れるいくつかの値の意味も明確にします。
つまり、次に示すものが、パスのタイミング解析の先頭部分です。
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)
これは、タイミング制約が満たされた(met)こと、そして時間に余裕(スラック)が 3.315 ns あったことを示しています。
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})
これらの行は、どのデータパスを調べているかを示します。これは、パスの開始位置と終了位置(Source と Destination)によって定義されます。データパスは、foo_reg のクロック入力である foo_reg_reg/C から始まります。このパスは、bar_reg__0/D のデータ入力で終わります。
もう 1 つ、ここでは「clk」という名前が現れ、その波形が記述されています。この「clk」は、create_clock でクロックに付けた名前を指していることに注意してください。この例では「clk」はクロック信号の名前でもあります。しかし、タイミング制約の「-name」パラメータで別の名前を使った場合は、信号の名前に関係なく、その別の名前がタイミングレポートに表示されます。このことは、このタイミングレポートの例で「clk」と書かれているすべての箇所に当てはまります。
Path Group: clk
ここで Path Group は「clk」です。これは、このパスを調べている理由が、同じ名前のタイミング制約であることを示します。
Path Type: Setup (Max at Slow Process Corner)
Path Type は Setup です。これは、セットアップ時間の要件を調べていることを意味します。「Max at Slow Process Corner」は、データパスの計算(最初の計算)で最大遅延が使われたことを意味します。ここでの Corner の意味については、後で説明します。
Requirement: 4.000ns (clk rise@4.000ns - clk rise@0.000ns)
上記の 2 つの理論的な実験では、それぞれ仮想的なストップウォッチをスタートさせるのでしたね。「Requirement」は、そのストップウォッチがスタートする時刻の差です。この場合、タイミング制約によって要求されるクロック周期、つまり 4 ns です。
Data Path Delay: 0.669ns (logic 0.382ns (57.100%) route 0.287ns (42.900%))
Data Path Delay は、最初の計算の水平線より後にあるすべての遅延(つまりデータパスの遅延)の合計です。
この行では、遅延がロジックと配線に分けて示されています。論理エレメントにどれだけ時間がかかり、論理エレメント間の配線にどれだけ時間がかかるかがわかります。一般的な目安は、遅延の約 60% がロジックで、残りが配線であるというものです。したがって、この例のパスは正常な状態を示しています。
配線遅延の割合が大幅に大きい場合、何らかの問題を示唆している可能性があります。特に、そのパスがタイミング制約を満たせない場合にはそうです。詳細は、次のページの thold の解析を説明している節で述べます。
Logic Levels: 1 (LUT1=1)
データパスは単一の LUT で構成されているため、論理レベル数は 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 skew)は、同じクロックエッジが 2 つのフリップフロップに到着する時刻の差です。これは計算上の最悪ケースであり、一方のクロックパスには最大遅延が、もう一方のクロックパスには最小遅延が使われることを考慮しています。これらの行の計算の詳細については、後述の「クロック悲観性の除去」の節を参照してください。
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
「クロック不確かさ」の節を参照してください。これらの行は、クロック不確かさがどのように計算されたかを示しています。この計算結果の 0.035 ns は、非現実的に楽観的な値です。これは、タイミング制約でジッタ(jitter)が指定されなかったため、ツールがジッタをゼロと仮定したからです。さらに、外部クロックを直接使用している(つまり FPGA 内部の PLL を経由しない)ため、考慮すべきジッタの発生源がほとんどありません。
タイミング制約に外部クロックのジッタを指定しないのは誤りですが、実際には通常そうされています。ジッタは通常、タイミング計算で考慮される他の要素と比べて小さいため、これが問題になることはほとんどありません。
Clock Net Delay (Source): 1.389ns (routing 0.002ns, distribution 1.387ns) Clock Net Delay (Destination): 1.218ns (routing 0.002ns, distribution 1.216ns)
これらは、クロックバッファの出力から各フリップフロップのクロック入力までの、クロック信号自体の遅延です。この例では、これらの数値から読み取れる情報はあまりありません。
マルチコーナータイミング解析
すべての論理エレメントの遅延は、温度や電源電圧などのいくつかの未知のパラメータに依存します。また、FPGA の製造過程におけるばらつきを指して「プロセス(process)」という用語が使われます。すべての FPGA はデータシートに適合することを保証するためにテストされていますが、個々の論理エレメントの挙動には依然として不確実性があります。
FPGA ツールは、パスごとに「コーナー(corner)」と呼ばれるいくつかの極端なシナリオでタイミング解析を実行します。たとえば、1 つ目のシナリオは、許容される最低温度と最速プロセス(つまり、たまたま遅延が小さい FPGA として製造された場合)を組み合わせたものです。2 つ目のシナリオは、最高温度と最速プロセスを組み合わせたものです。3 つ目と 4 つ目のシナリオは、これを最遅プロセスで繰り返します。
つまり、この例では、温度とプロセスの 2 つのパラメータの極端な条件に対してタイミング解析が行われます。これは 4 コーナータイミング解析と呼ばれます。ただし、これはマルチコーナータイミング解析の多くの方法の 1 つにすぎません。FPGA ツールごとに、タイミング解析の実行方法は異なります。
しかし、ツールがどのコーナーを調べることを選んでも、最悪ケースが常にタイミング解析の結果と見なされます。言い換えれば、ツールは各コーナーについてスラックを計算し、最も低いスラックが判定対象になります。
ツールは、各 FPGA に適したマルチコーナータイミング解析を実行するようにプログラムされているため、このテーマを深く理解する必要はありません。しかし、タイミングレポートを読むとき、それが 1 つのコーナーに関するものなのか、それとも全コーナーの要約(つまり最悪ケース)なのかを確認することが重要です。混乱する可能性があります。特に Quartus では。
次に、クロック悲観性の除去とクロック不確かさについて説明します。これらは比較的高度な話題です。タイミング計算の細かい部分に興味がなければ、この連載の次のページへ進んでもかまいません。
クロック悲観性の除去
偶然、両方のフリップフロップが同じスライス上にあるため、クロックパス遅延の計算(つまり、クロックエッジがスライスに到達するまでの時間)を比較できます。2 番目の計算では、4 ns から始まり 6.646 ns で終わるため、この時間は 6.646 − 4 = 2.646 ns です。前の計算では、結果は 3.221 ns でした。差は 0.575 ns です。
この差は、最初の計算では最大遅延が使われ、2 番目の計算では最小遅延が使われたために生じます。最小遅延と最大遅延の差は、製造プロセスに起因する自然なばらつきにより、遅延が正確にはわからないという事実を表しています。したがって、最初のフリップフロップへのクロックパスと 2 番目のフリップフロップへのクロックパスが完全に異なる場合、最悪ケースを考慮しなければなりません。その最悪ケースとは、最初のパスのすべての遅延が許容最大値で、2 番目のパスのすべての遅延が許容最小値である場合です。これをクロック悲観性(clock pessimism)と呼びます。
ここで注意:これは温度や、FPGA の個体差とは関係ありません。両方の計算は、同じ温度と製造プロセスに対して行われています。この差は、区間内の各遅延に、FPGA の仕様内の許容範囲があるために生じます。
しかし、両方のクロックパスが同一であるのに、なぜクロック悲観性が計算に含まれるのでしょうか。答えは、そうするのは誤りだからです。このため、宛先クロックパスの計算には「clock pessimism」というタイトルの行があります。この行は、その誤りを補正するために遅延に 0.527 ns を追加しています。実際には、このタイトルは「clock pessimism removal」(CPR)とすべきでしょう。
クロック悲観性の除去の背後にある考え方は、両方の計算で共通しているクロックパスの部分について、最小遅延と最大遅延の不必要な差を取り除くことです。ツールは 2 つの計算のクロックパスを比較し、両方に共通する区間を見つけます。その共通区間内の遅延差の合計が、除去すべきクロック悲観性です。
前述のように、クロックパスの差は 0.575 ns でした。しかし、実際に適用されたクロック悲観性は 0.527 ns だけでした。つまり、除去量は 0.048 ns 小さくなっています。その理由は、スライス内部に 2 つの計算で共通しないわずかなクロックパス区間があるためです。スライス内部の一方の配線は最初のフリップフロップへ、もう一方の配線は 2 番目のフリップフロップへ向かっており、この 2 本の配線の遅延は異なり得ます。
クロック不確かさ
タイミング計算では、クロックパスの計算結果から 0.035 ns が差し引かれました。これにより、タイミング計算はより厳しくなっています。
クロック不確かさは、2 つのクロックエッジの間隔に関するランダムな要素をすべて考慮するためのものです。このランダム性はクロックジッタ(clock jitter)と呼ばれ、さまざまなノイズ源や電子回路のランダムな挙動によって生じます。
計算から 0.035 ns を差し引くことは、タイミング制約(create_clock)でクロック周期が 4 ns と定義されていても、実際にはその周期がランダムに変動するという事実を表しています。その結果、2 つのクロックエッジの間隔は短くなることがあります。どれだけ短くなるのか。この計算では、2 つのクロックエッジの間隔が 3.965 ns(4 − 0.035 = 3.965 ns)より短くなることはないと仮定されています。
この仮定には根拠があるのでしょうか。それは難しい質問です。クロックジッタの見積もりは複雑なテーマであり、タイミング制約に関するこの議論の範囲をはるかに超えます。とはいえ、クロックジッタはタイミング制約とは無関係に、論理設計にさまざまな問題を引き起こす可能性があるため、このテーマをさらに勉強することをお勧めします。
これで、クロック周期制約に関する 2 ページ構成の最初のページを終わります。学ぶべきことはまだ次のページにもあります...