このページは、タイミングに関する連載ページの一部です。これまでのページでは、タイミング計算の背後にある理論、クロック周期制約、タイミングクロージャ(timing closure)の原則を説明し、重要ないくつかの Tcl コマンドを紹介しました。このページでは、特定のパス(path)に対してタイミング制約(timing constraints)を定義する方法を説明します。
はじめに
タイミング制約を書くときの目標は、それが短く、簡潔で、理解しやすいことです。そうすれば、混乱や誤りのリスクを減らせます。可能であれば、FPGA 内部のパスに関するタイミング制約は、クロック周期制約(create_clock など)とクロックグループ制約(たとえばset_clock_groups)の 2 種類だけにすべきです。
しかし、特定のパスには特定の規則が必要なこともよくあります。このような特定の規則をタイミング例外(Timing Exceptions)と呼びます。その名前が示すとおり、これらのタイミング制約は主に、既存のタイミング制約を上書きすることを目的としています。また、そうでなければ何のタイミング要件も持たないパスに対して、タイミング要件を指定するためにも使えます。
SDC 構文でこの目的に使われるコマンドは、主に次のとおりです。
- set_false_path:選択されたパスにタイミング要件を適用しないようツールに指示します。
- set_max_delay:tsetup の適用に関する要件を定義します。
- set_min_delay:thold の適用に関する要件を定義します。
- set_multicycle_path:クロックイネーブル(clock enable)信号によって制御されるロジックに対する要件を緩和します。
異なる構文を使うツールにも、同様のコマンドがあるはずです。
これらのコマンドの引数は、どのパスを対象にするかなどを定義します。これについては以下で説明します。
関連する 2 つのトピックが、他のページで説明されています。
- I/O タイミング制約については専用ページがあります。したがって、以下の説明は、これらのコマンドを内部パス(ロジックファブリック上の順序論理エレメントから順序論理エレメントへ渡るパス)に使う場合に限定します。
- set_multicycle_path については、別の専用ページで説明します。
フォールスパス
フォールスパス(false path)とは、それを要求するタイミング制約の結果として、ツールが無視するパスのことです。言い換えれば、ツールはフォールスパスにタイミング要件を意図的に課しません。それは、私たちがそうするよう指示したからです。
これは無拘束パス(unconstrained paths)と混同しないでください。無拘束パスとは、ツールが何のタイミング制約も持たないパスです。フォールスパスと同様、ツールはこれらのパスにいかなるタイミング要件も課しません。しかし、その理由は異なります。この非適用は選択ではなく、ツールがどの要件を適用すればよいかを知らないのです。
FPGA 設計内に無拘束パスがあってはなりません。とはいえ、ツールに無視させたいパスはよくあります。そのようなパスは、タイミング制約によってフォールスパスと宣言すべきです。その論拠はこうです。タイミングレポートを読むとき、無拘束パスの数が常にゼロであることを確認すべきです。この数がゼロでなければ、どこかに誤りがないか探すべきです。無拘束パスの数がゼロでないことを受け入れる習慣がつくと、タイミング制約の問題を見落としやすくなります。
フォールスパスを宣言する理由は、次の 2 つが考えられます。
- ツールがそうでなければパスにタイミング要件を課す場合、フォールスパスは、代わりにそのパスを無視するようツールに指示します。
- そのパスに関するタイミング制約が存在しない場合。この場合、フォールスパスの目的は、無拘束パスの数をゼロに保つことだけです。
実際上は、どちらのシナリオが当てはまるかは重要ではありません。パスにタイミング要件が不要なら、フォールスパスとして宣言すべきです。
set_false_path をクロックドメイン横断(clock domain crossing)に関連して使うのは、よくある誤りです。このトピックは後で詳しく説明します。実際には、I/O ポートを除けば、set_false_path を使うのが正しい状況はそれほど多くありません。
set_false_path の対象パスを選択する
コマンドを適用するパスを選択する方法は多数あります。可能性が広いにもかかわらず、パスの選択は通常、-from と -to という 2 つの引数で行われます。たとえば、次のとおりです。
set_false_path -from [get_cells source_reg] -to [get_cells dest_reg]
この例では、set_false_path コマンドは、source レジスタで始まり dest レジスタで終わるパスに適用されます。
get_cells が -from と -to に論理エレメントを表すオブジェクトを渡していることに注意してください。前のページで説明した他のコマンド(get_pins、get_nets、get_ports、get_clocks)も使えます。ただし、-from と -to に何を使ってもよいかについては、FPGA ツールごとに独自の規則があります。
ツールがオブジェクトへの参照を、人が自然に期待するように解釈しない可能性があることに注意してください。また、ツールは警告を発せずに、オブジェクトの一部または全部を無視することもあります。実際、get_* コマンドが(たとえば検索パターンの誤りによって)オブジェクトを 1 つも見つけられなかった場合、タイミング例外にはどのパスも含まれません。これも警告なしに起こり得ます。
したがって、タイミング例外が意図したとおりに適用されていることを、タイミングレポートで検証することが重要です。つまり、正しいパスが影響を受けていること、そしてタイミング解析がその正確な目的(タイミング要件の非適用)を果たしていることを確認します。
パスを選択するためのもう 1 つの便利な引数があります。-through です。その名前が示すとおり、この引数は特定の論理エレメントを通過するパスを選択します。
すべての機能を把握するために、公式ドキュメントを読む時間を取る価値があります。たとえば、コマンドの効果を立ち上がりクロックエッジだけ、または立ち下がりクロックエッジだけに限定することも可能です。また、コマンドを tsetup の解析だけ、または thold の解析だけに限定することもできます。
set_false_path コマンドは、引数として -from、-to、-through の少なくとも 1 つ(または同様の意味の別の引数)を必要とします。引数が複数ある場合、タイミング例外は、すべての引数の条件を満たすパスにのみ適用されます。
set_false_path の危険性
フォールスパスの問題は、誤りを犯しやすいことです。特に、意図したよりも多くのパスを含めてしまうリスクがあります。これが起こると、正しく動作しない可能性のある順序エレメントが生じます。私たちは、ツールがそれらの tsu 要件と thold 要件を保証すると誤って期待しています。しかし実際には、ツールはそれらの順序エレメントへのパスがあたかもフォールスパスであるかのように振る舞います。したがって、ツールはそれらに対してタイミング解析をしようとしません。これは危険な状況です。ツールがタイミング制約を達成したと言ったとき、すべてがうまくいっているかのような錯覚を生むからです。しかし実際には、タイミング違反にさらされているフリップフロップや他の順序エレメントが、何の保護もなく存在しているのです。
さらに悪いことに、パスがフォールスパスとして宣言されると、その宣言は通常、最優先されます。したがって、パスが誤ってフォールスパスとして宣言されると、その宣言はおそらく、反対を要求する他のタイミング制約を上書きします。これは、set_false_path が他のタイミング制約より前に現れた場合でも、通常は当てはまります。つまり、set_false_path は「前に要求したことや、後で要求することに関係なく、これらはフォールスパスである」と解釈されます。
set_min_delay と set_max_delay
まず、選択したパスのグループからタイミング要件を排除するフォールスパスについて説明しました。多くの場合、必要なのはタイミング要件を打ち消すことではなく、指定することです。これは set_min_delay と set_max_delay で行います。たとえば、次の Verilog コードを考えます。
reg x, y;
always @(posedge clk)
y <= x;
そして、タイミング制約は次のとおりです。
set_max_delay -from [get_cells x_reg] -to [get_cells y_reg] 3 set_min_delay -from [get_cells x_reg] -to [get_cells y_reg] 1
では、これらのコマンドの意味は何でしょうか。set_max_delay から始めましょう。このタイミング例外を短く説明すると、特定のパスだけを対象としたクロック周期制約(create_clock)に似ているということです。
思い出してください。クロック周期制約を定義すると、ツールは必要なタイミング要件を自動的に適用します。tsetup 要件を満たすために、関連するパスの最大遅延が制限されます。同様に、thold のために最小遅延が制限されます。
上の例では、set_max_delay コマンドに現れる値は 3 です。これは、クロック周期が 3 ns に等しい create_clock コマンドに相当します。しかし、set_max_delay の影響は特定のパスのグループに限定されます。それが違いです。
set_min_delay については、もう少し複雑なので、以下で詳しく説明します。
set_max_delay という名前は誤解を招くことに注意してください。このコマンドは、パス自体の最大遅延を直接定義するものではありません。上の例のコマンドによって、影響を受けるパスの遅延が 3 ns に制限されるわけではありません。3 ns という値は、クロックエッジ間の許容時間差として適用されます。そして、この時間差は順序エレメントのクロック入力で測定されるのではなく、これらのクロックの発生元で測定されます。つまり、PLL、クロックバッファ、クロック配線の遅延が計算に含まれます。クロック周期制約と同様に、クロック遅延がタイミング解析で考慮されるのです。
-from、-to、-through およびその他の引数の意味は、set_false_path と同じです。しかし、一般的に、set_min_delay と set_max_delay はクロック周期制約の調整として意図されています。したがって、通常、パスの両側に順序エレメントがあることが前提です。そのため、-from と -to は順序エレメントを表すべきです。これらを参照する方法は多数あります。順序エレメント自体を表すセルオブジェクト、クロックオブジェクトなどです。
set_min_delay についても同様の話があります。クロック周期制約のもう 1 つの結果として、ツールは thold 要件を満たさなければなりません。この目的のために、ツールは同じクロック間または関連クロック(related clocks)間のすべてのパスに最小遅延を適用します。あるパスのタイミング計算が create_clock だけの結果である場合(両側が同じクロック)、これは値ゼロの set_min_delay に相当します。これは、同じクロックエッジが両方の順序エレメントに到着するという考えを反映しています。しかし、これはこのクロックエッジがこれらの順序エレメントに同時に到着することを意味するものではありません。むしろ、各順序エレメントへのクロックエッジは、クロックの発生元で同時に開始します。クロックの発生元から順序エレメントまでの遅延は、tsetup の計算と同様に、計算に考慮されます。
set_min_delay を使うと、2 番目の順序エレメントに到着するクロックエッジの時刻を調整できます。たとえば、上のコマンドは、このクロックエッジを 2 番目のフリップフロップに 1 ns 遅く到着させます。これにより、thold のタイミング要件を満たすのが難しくなります。下のタイミングレポートの例を参照してください。
set_min_delay と set_max_delay を使う理由は、次の 2 つが考えられます。
- ツールがそうでなければ適用するタイミング要件が、特定のパスのグループにとって不適切な場合。たとえば、メタスタビリティガードから始まるパスでは、タイミング要件をより厳しくする必要がある場合です。
- パスに関連するタイミング制約が存在しない場合。この目的で set_max_delay を使いたいなら、代わりにクロック周期制約やマルチサイクルパス(multicycle path)が必要ではないか、自分に問いかけてみてください。
これら 2 つのコマンドを使うときは、常にタイミングレポートで対象パスのタイミング解析を注意深く確認してください。特に、クロックパスが計算の中でどのような役割を果たしているかに注目してください。
このページの最後に、set_min_delay と set_max_delay の結果を示すタイミングレポートの例があります。
遅延をもっと正確に制御する
set_max_delay と set_min_delay が提供する制御の程度は、クロック周期制約(これまでに示したもの)と比べて、それほど大きく変わりません。しかし、クロックパス遅延に私たちの遅延定義を邪魔されたくない場合はどうでしょうか。パスの特定の区間の遅延だけを制御したい場合はどうでしょうか。
一部の FPGA ツールは、これらのニーズに対する解決策をまったく提供していません。たとえば Quartus は、そのような可能性を提供していません(私の知る限り)。一方 Vivado にはいくつかの機能があり、それらを簡単に説明します。
そのような機能の 1 つが datapath_only オプションです。タイミング計算にクロックパスを含めないようにするため、set_max_delay でこのオプションを使いたいことがあります。たとえば、パスが無関係クロック(unrelated clocks)間にある場合、クロックパスを考慮しても意味がありません。
datapath_only を使うと、両方の順序エレメントのクロックパス遅延がゼロであるかのようにタイミングが計算されます。したがって、計算はパスの論理エレメントの遅延だけで構成されます。これらの遅延の合計は、set_max_delay コマンドで与えられた数値より小さいことが要求されます(下のタイミングレポートの例を参照)。
つまり、set_max_delay を datapath_only と一緒に使うと、その意味は、このコマンドの名前が示唆するものにかなり近くなります。ただし、パスは依然として順序エレメントで始まり、順序エレメントで終わらなければならないことに注意してください。
また、datapath_only にはいくつかの特異な点があります。これを使うと、ツールは関連するパスの thold に関して、いかなるタイミング要件も適用しません。つまり、ツールは thold のシナリオにのみ適用されるフォールスパス制約があったかのように振る舞います。関連するパスに set_min_delay コマンドを追加しても、このコマンドは無視されます。Vivado が datapath_only の影響を受けるパスに最小遅延を適用することを拒否する理由は明らかではありません。
datapath_only は、いかなるシナリオでも set_min_delay の引数として使うことはできません。
誤解を招く機能
この節のタイトルが示すとおり、これらはおそらく何の役にも立たない可能性が高い機能です。次の節に読み飛ばしてもかまいません。
Vivado はさらに高いレベルの制御を可能にします。パスの特定の区間の遅延に制限を課すことが可能です。たとえば、順序エレメントではない論理エレメントを -from と -to で使うとどうなるでしょうか。ピンやネットではどうでしょうか。set_min_delay と set_max_delay は何をするでしょうか。
もちろん、それは使用する FPGA ツールによって異なります。ツールは、要件に一致するパスがないため、そのような制約を黙って無視することがあります。しかし Vivado はそのような制約を無視しません。もっとも、その結果は人が自然に期待するものではありません。Vivado はこの状況を「パスセグメンテーション」と見なし、それに応じてクリティカル警告(critical warning)を発行します。ほとんどの場合、この機能を使う価値は、それが引き起こす複雑さに見合いません。詳細についてはドキュメントを参照してください。
もう 1 つ、誤解を招く可能性のある機能があります。Quartus には set_net_delay というコマンドがあります。これは、設計内の異なる論理エレメント間の最小遅延と最大遅延を定義できます。しかし、ツールはインプリメンテーション中にこれらのタイミング要件を達成しようとはしないようです。代わりに、「report_net_delay」(または GUI)でレポートを生成できます。したがって、set_net_delay で定義した条件が満たされたかどうかを、このレポートから推測できます。つまり、set_net_delay は情報を得るために使えますが、タイミング制約としては役に立ちません。言い換えれば、set_max_delay と set_min_delay はタイミング制約として有効ですが、set_net_delay は有効ではありません。
要約すると、set_max_delay と set_min_delay を普通に使う以上に良い方法は、あまりありません。どうやら、興味深い唯一の機能は Vivado の datapath_only です。
タイミング制約の優先順位
複雑なタイミング制約の主な問題は、複数の制約の影響を受けるパスがしばしば存在することです。これらの制約は、通常、それらのパスに対して矛盾するタイミング要件を持ちます。では、どの制約が勝つのでしょうか。
各 FPGA ツールには、この種の競合を解決するための独自の規則があります。通常、それは主に制約のタイプに依存します。他の要因、特にパス選択の具体性も影響することがあります。
SDC に基づくタイミング制約の場合、優先順位は制約のタイプに依存します。たとえば Vivado は、次の優先順位で競合を解決します。コマンドを優先度の高い順に示します。
- set_clock_groups(関連クロックと無関係クロックのグループ)
- set_false_path(フォールスパス)
- set_min_delay と set_max_delay(最小遅延と最大遅延)
- set_multicycle_path(マルチサイクルパス)
- create_clock(クロック周期)
最初の 2 つのコマンド(set_clock_groups と set_false_path)はフォールスパスを作成し、最優先であることに注意してください。したがって、これらのコマンドによって誤って影響を受けるパスがないかを検証することは、とりわけ重要です。そのような誤りは、関連するパスに対するタイミング要件の適用を、静かに無効にしてしまいます。
同じコマンドが同じパスに複数回使われる場合、最も具体的なコマンドが優先されます。たとえば、一方のコマンドに「-from」と「-to」があり、もう一方のコマンドに「-from」だけがある場合、最初のコマンドが優先されます。別の例として、一方のコマンドが論理エレメントに基づいてパスを定義し(get_cells など)、もう一方のコマンドがクロックに基づいてパスを定義する場合(get_clocks)、最初のコマンドが優先されます。
2 つのコマンドが非常によく似ていて優先順位に差がない場合、出現順序で競合が解決されます。最後のコマンドが優先されます。
Quartus やその他の SDC ベースのツールも、同様の優先順位規則を使用します。
しかし、どのツールを使う場合でも、タイミング制約間の矛盾は避けるのが最善です(create_clock を上書きする場合を除く)。複雑なタイミング制約は、壊滅的なバグが繁殖し得る場所です。
一部の FPGA ツールでは、優先順位規則を回避することが可能です。-reset_path 属性を使うと、この属性を使うコマンドが、それが適用されるすべてのパスに対して、以前のタイミング例外を上書きします。たとえば、次のとおりです。
set_max_delay -reset_path -from [get_cells source_reg] 2
まとめ
このページの冒頭で、タイミング制約は短く、単純で、簡潔であるべきだと述べました。タイミング例外を追加すると、タイミング制約は長くなるだけでなく、より複雑になり、理解しにくくなります。したがって、タイミング例外は必要なときに使い、注意深く書き、整然と保ってください。
タイミング例外コマンドは、その目的を反映し、背後にある考えを表現するように書くよう心がけてください。FPGA ツールは通常、タイミング制約を作成するための GUI ウィザードを提供しています。それらは出発点として役立ちます。しかし、ウィザードが作成したタイミング制約を、注意深く考えずに使わないでください。たとえその制約が作成時点で正しくても、論理設計が発展し、新しいロジックが追加されたときに、それは忠実に機能し続けるでしょうか。
タイミング例外の影響を受けるパスについては、必ずタイミングレポートを読んでください。パスに複数のタイミング制約がある場合は、なおさら重要です。また、タイミング要件が誤っている可能性のあるパスについては、専用のタイミングレポートも作成してください。
覚えておいてください。タイミングレポートの作成と閲覧は時間の無駄ではありません。どれだけ注意深くドキュメントを読んでも(それは常に良い考えですが)、誤りの可能性は常にあります。特に、フォールスパスは、最も予期しない場所で発生することがあります。
おまけ:タイミングレポートの例
set_min_delay と set_max_delay の理解を助けるために、Vivado で作成したいくつかのタイミングレポートを示します。
上記の説明から、これらのレポートの背後にある Verilog コードは次のとおりです。
always @(posedge clk)
y <= x;
そして、タイミング制約は次のとおりです。
set_max_delay -from [get_cells x_reg] -to [get_cells y_reg] 3 set_min_delay -from [get_cells x_reg] -to [get_cells y_reg] 1
tsetup のレポート:
Slack (MET) : 0.360ns (required time - arrival time)
Source: x_reg/C
(rising edge-triggered cell FDRE clocked by clk {rise@0.000ns fall@2.000ns period=4.000ns})
Destination: y_reg/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: 3.000ns (MaxDelay Path 3.000ns)
Data Path Delay: 2.617ns (logic 0.139ns (5.311%) route 2.478ns (94.689%))
Logic Levels: 0
Clock Path Skew: -0.053ns (DCD - SCD + CPR)
Destination Clock Delay (DCD): 2.644ns
Source Clock Delay (SCD): 3.224ns
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.392ns (routing 0.002ns, distribution 1.390ns)
Clock Net Delay (Destination): 1.216ns (routing 0.002ns, distribution 1.214ns)
Timing Exception: MaxDelay Path 3.000ns
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=4, routed) 1.392 3.224 clk_IBUF_BUFG
SLICE_X49Y57 FDRE r x_reg/C
------------------------------------------------------------------- -------------------
SLICE_X49Y57 FDRE (Prop_DFF_SLICEL_C_Q)
0.139 3.363 r x_reg/Q
net (fo=2, routed) 2.478 5.841 x
SLICE_X49Y57 FDRE r y_reg/D
------------------------------------------------------------------- -------------------
max delay 3.000 3.000
AG12 0.000 3.000 r clk (IN)
net (fo=0) 0.000 3.000 clk_IBUF_inst/I
AG12 INBUF (Prop_INBUF_HRIO_PAD_O)
0.515 3.515 r clk_IBUF_inst/INBUF_INST/O
net (fo=1, routed) 0.066 3.581 clk_IBUF_inst/OUT
AG12 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O)
0.034 3.615 r clk_IBUF_inst/IBUFCTRL_INST/O
net (fo=1, routed) 0.722 4.337 clk_IBUF
BUFGCE_X1Y0 BUFGCE (Prop_BUFCE_BUFGCE_I_O)
0.091 4.428 r clk_IBUF_BUFG_inst/O
X2Y0 (CLOCK_ROOT) net (fo=4, routed) 1.216 5.644 clk_IBUF_BUFG
SLICE_X49Y57 FDRE r y_reg/C
clock pessimism 0.527 6.171
clock uncertainty -0.035 6.136
SLICE_X49Y57 FDRE (Setup_EFF2_SLICEL_C_D)
0.065 6.201 y_reg
-------------------------------------------------------------------
required time 6.201
arrival time -5.841
-------------------------------------------------------------------
slack 0.360
遅延の値(3 ns)が、2 番目のフリップフロップのクロックパスの開始時刻として使われていることに注意してください。つまり、これはあたかも 3 ns の周期制約があったかのようです。
また、データパス内のネットの遅延が非常に大きいことにも注意してください。2.478 ns です。これは set_min_delay コマンドの結果です。ツールは、thold 要件を満たすために、このネットに長い遅延を挿入せざるを得なかったのです。
ところで、これは thold のタイミングレポートです。
Slack (MET) : 0.057ns (arrival time - required time)
Source: x_reg/C
(rising edge-triggered cell FDRE clocked by clk {rise@0.000ns fall@2.000ns period=4.000ns})
Destination: y_reg/D
(rising edge-triggered cell FDRE clocked by clk {rise@0.000ns fall@2.000ns period=4.000ns})
Path Group: clk
Path Type: Hold (Min at Fast Process Corner)
Requirement: 1.000ns (MinDelay Path 1.000ns)
Data Path Delay: 1.141ns (logic 0.049ns (4.294%) route 1.092ns (95.706%))
Logic Levels: 0
Clock Path Skew: 0.029ns (DCD - SCD - CPR)
Destination Clock Delay (DCD): 1.684ns
Source Clock Delay (SCD): 1.258ns
Clock Pessimism Removal (CPR): 0.398ns
Clock Net Delay (Source): 0.502ns (routing 0.002ns, distribution 0.500ns)
Clock Net Delay (Destination): 0.585ns (routing 0.002ns, distribution 0.583ns)
Timing Exception: MinDelay Path 1.000ns
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.339 0.339 r clk_IBUF_inst/INBUF_INST/O
net (fo=1, routed) 0.025 0.364 clk_IBUF_inst/OUT
AG12 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O)
0.015 0.379 r clk_IBUF_inst/IBUFCTRL_INST/O
net (fo=1, routed) 0.350 0.729 clk_IBUF
BUFGCE_X1Y0 BUFGCE (Prop_BUFCE_BUFGCE_I_O)
0.027 0.756 r clk_IBUF_BUFG_inst/O
X2Y0 (CLOCK_ROOT) net (fo=4, routed) 0.502 1.258 clk_IBUF_BUFG
SLICE_X49Y57 FDRE r x_reg/C
------------------------------------------------------------------- -------------------
SLICE_X49Y57 FDRE (Prop_DFF_SLICEL_C_Q)
0.049 1.307 r x_reg/Q
net (fo=2, routed) 1.092 2.399 x
SLICE_X49Y57 FDRE r y_reg/D
------------------------------------------------------------------- -------------------
min delay 1.000 1.000
AG12 0.000 1.000 r clk (IN)
net (fo=0) 0.000 1.000 clk_IBUF_inst/I
AG12 INBUF (Prop_INBUF_HRIO_PAD_O)
0.595 1.595 r clk_IBUF_inst/INBUF_INST/O
net (fo=1, routed) 0.042 1.637 clk_IBUF_inst/OUT
AG12 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O)
0.022 1.659 r clk_IBUF_inst/IBUFCTRL_INST/O
net (fo=1, routed) 0.409 2.068 clk_IBUF
BUFGCE_X1Y0 BUFGCE (Prop_BUFCE_BUFGCE_I_O)
0.031 2.099 r clk_IBUF_BUFG_inst/O
X2Y0 (CLOCK_ROOT) net (fo=4, routed) 0.585 2.684 clk_IBUF_BUFG
SLICE_X49Y57 FDRE r y_reg/C
clock pessimism -0.398 2.286
SLICE_X49Y57 FDRE (Hold_EFF2_SLICEL_C_D)
0.055 2.341 y_reg
-------------------------------------------------------------------
required time -2.341
arrival time 2.399
-------------------------------------------------------------------
slack 0.057
繰り返しますが、遅延の値(1 ns)が、2 番目のフリップフロップのクロックパスの開始時刻として使われています。set_min_delay コマンドがない場合(つまりクロック周期制約だけの場合)、これは 0 ns です。
データパス内のネットの遅延は 1.092 ns です。これは thold 要件を満たすのにちょうど十分です。なぜ以前は 2.478 ns だったのでしょうか。tsetup の最悪ケース計算が「Max at Slow Process Corner」で行われたからです。つまり、2.478 ns は関連するネットの取り得る最大遅延であり、1.092 ns は取り得る最小遅延(「Min at Fast Process Corner」)です。詳細はマルチコーナータイミング解析の説明を参照してください。
3 つ目の例は datapath_only を示すので、制約は次のとおりです。
set_max_delay -datapath_only -from [get_cells x_reg] -to [get_cells y_reg] 3
set_min_delay はありません。とにかく無視されるからです(set_max_delay コマンドの後に書いても同じです)。
tsetup のレポートは次のようになります。
Slack (MET) : 2.482ns (required time - arrival time)
Source: x_reg/C
(rising edge-triggered cell FDRE clocked by clk {rise@0.000ns fall@2.000ns period=4.000ns})
Destination: y_reg/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: 3.000ns (MaxDelay Path 3.000ns)
Data Path Delay: 0.583ns (logic 0.139ns (23.842%) route 0.444ns (76.158%))
Logic Levels: 0
Timing Exception: MaxDelay Path 3.000ns -datapath_only
Location Delay type Incr(ns) Path(ns) Netlist Resource(s)
------------------------------------------------------------------- -------------------
SLICE_X49Y57 0.000 0.000 r x_reg/C
SLICE_X49Y57 FDRE (Prop_DFF_SLICEL_C_Q)
0.139 0.139 r x_reg/Q
net (fo=2, routed) 0.444 0.583 x
SLICE_X49Y57 FDRE r y_reg/D
------------------------------------------------------------------- -------------------
max delay 3.000 3.000
SLICE_X49Y57 FDRE (Setup_EFF2_SLICEL_C_D)
0.065 3.065 y_reg
-------------------------------------------------------------------
required time 3.065
arrival time -0.583
-------------------------------------------------------------------
slack 2.482
このタイミングレポートの構造は以前と同じですが、クロックパスに関連するすべてが削除されていることに注意してください。
ネットの遅延は小さくなっています。ツールには長い遅延を挿入する理由がなかったからです。thold 要件が存在しないのです。
thold のタイミングレポートは示しません。タイミング要件が存在しないからです(最小遅延はフォールスパスとして扱われます)。
これで、タイミング例外に関する一般的な議論は終わりです。次のページでは、クロックドメイン横断のために必要なタイミング例外について説明します。