このページは、 timingに関する一連のページに属しています。前のページでは、 timing 計算の背後にある理論を説明し、 clock period constraintについて説明し、 timing closureの原理を示し、いくつかの重要な Tcl コマンドを紹介しました。このページでは、特定の pathsに対して timing constraints を定義する方法について説明します。
序章
timing constraints を作成する目的は、短く、簡潔で、理解しやすいものにすることです。これにより、混乱や間違いのリスクが軽減されます。可能であれば、 FPGAの内部 paths 用の timing constraints は、次の 2 つのタイプのみで構成する必要があります。 clock period constraints (例: create_clock) および clock group constraints (例: set_clock_groups )。
しかし、多くの場合、特定の paths には特定のルールが必要です。これらの特定の規則は Timing Exceptionsと呼ばれます。その名前が示すように、これらの timing constraints は主に既存の timing constraintsをオーバーライドすることを目的としています。また、 paths の timing 要件を指定するために使用することもできます。
SDC 構文でのこれらの目的のためのコマンドは、主に次のとおりです。
- set_false_path: 選択した pathsに timing 要件を適用しないことをツールに通知します。
- set_max_delay: tsetupの実施要件を定義します。
- set_min_delay: tholdの実施要件を定義します。
- set_multicycle_path: clock enable signalによって制御される logic の要件を緩和します。
異なる構文を使用するツールには、同様のコマンドがある可能性があります。
これらのコマンドの arguments は、(とりわけ) どの paths が影響を受けるかを定義します。これについては以下で説明します。
他のページで説明されている 2 つの関連トピックがあります。
- I/O timing constraintsの別ページがあります。したがって、以下の説明は、これらのコマンドを内部 paths で使用することに限定されます (つまり、logic fabric上の logic element との間)。
- set_multicycle_path については、別のページで説明しています。
False Paths
false pathは、これを要求する timing constraint の結果としてツールが無視する path です。言い換えれば、ツールは false pathに timing の要件を意図的に強制しません。
これをunconstrained pathsと混同しないでください: これらは、ツールに timing constraint がない paths です。 false pathsと同様に、ツールはこれらの pathsに timing 要件を適用しませんが、理由は異なります。 この強制の欠如は選択ではありませんが、ツールは適用する要件を認識していません。
FPGA designには unconstrained paths があってはなりません。そうは言っても、ツールに無視させたい paths がしばしばあります。これらの paths は、 timing constraintsのおかげで false path としてマークする必要があります。根拠: timing reportを読み取ると、 unconstrained paths の数が常にゼロであることがわかります。この数値がゼロでない場合は、間違いを探す必要があります。 unconstrained pathsのゼロ以外の数を受け入れることに慣れると、 timing constraintsの問題を見落としやすくなります。
したがって、 false pathsを宣言する理由として、次の 2 つが考えられます。
- それ以外の場合、ツールが pathで timing 要件を強制する場合、 false path は代わりに path を無視するようにツールに指示します。
- pathに関連する timing constraint がない場合。この場合、 false path の目的は、 unconstrained paths の数をゼロに保つことだけです。
実際には、これらのシナリオのどれが有効かは問題ではありません。 pathで timing 要件が必要ない場合は、 false pathとして宣言する必要があります。
clock domain crossingsと関連して set_false_path を使用するのはよくある間違いです。このトピックについては、後で詳しく説明します。実際、 I/O portsを除いて、 set_false_pathを使用するのが正しい状況はあまりありません。
set_false_pathに paths を選択する
コマンドを適用する paths を選択するには、さまざまな方法があります。幅広い可能性にもかかわらず、 paths の選択は通常、2 つの argumentsで行われます。 -from と -to。例えば：
set_false_path -from [get_cells source_reg] -to [get_cells dest_reg]
この例では、 set_false_path コマンドは、 @source という名前の register で始まり、 @destという名前の register で終わる path に適用されます。
get_cells は、 logic elementsを表す objects とともに -from および -to を提供することに注意してください。前のページで説明した他のコマンドも使用できます。 get_pins、 get_nets、 get_ports 、 get_clocks。ただし、各 FPGA ツールには、 -from および -toで使用できるものに関する独自のルールがあります。
ツールは objects への参照を当然のように解釈しない場合があることに注意してください。ツールは、 warningを発行せずに、 objects の一部またはすべてを無視する場合もあります。実際、 get_* コマンドで objects が見つからない場合 (たとえば、 search patternの誤りにより)、 path は timing exceptionに含まれません。これは warningがなくても起こりえます。
したがって、 timing report を使用して、 timing exceptions が意図したとおりに適用されていることを確認することが重要です。これは、正しい paths が影響を受け、 timing 計算がその正確な目的を満たしていることを意味します ( timing 要件の強制はありません)。
pathsを選択するための別の便利な argument があります。 -through.その名前が示すように、この argument は、特定の logic elementsを通過する paths を選択します。
すべての機能を理解するために、時間をかけて公式ドキュメントを読む価値があります。たとえば、コマンドの効果を rising clock edges または falling clock edgesのみに制限することもできます。もう 1 つの可能性は、コマンドを tsetup または tholdのみの分析に限定することです。
set_false_path コマンドには、 argument (または同様の意味を持つ別の argument ) として、 -from、 -to 、または -through の少なくとも 1 つが必要です。 argumentが複数ある場合、 timing exception はすべての argumentsの条件を満たす paths にのみ適用されます。
set_false_pathの危険性
false paths の問題点は、間違いを犯しやすいことです。特に、意図したよりも多くの paths を含めるリスクがあります。これが発生すると、正しく動作しない可能性がある sequential elements があります。 ツールが tsu と tholdの要件を保証していると誤解しています。しかし実際には、ツールは paths からこれらの sequential elements を false pathsと見なします。したがって、ツールは timing 計算を行う必要はありません。 timing constraints が達成されたとツールが言うと、すべてが正常であるという錯覚が生じるため、これは危険な状況です。しかし実際には、 flip-flops やその他の sequential elements が、何の保護もなく timing 違反にさらされています。
さらに悪いことに、 path が false pathとして宣言されている場合、通常、この宣言が最も優先されます。したがって、 path が誤って false pathとして宣言された場合、これはおそらく、反対を必要とする他の timing constraints を無効にします。これは通常、 set_false_path が他の timing constraintより前に表示される場合でも当てはまります。したがって、 set_false_path は、「以前に必要だったものや後で必要なものに関係なく、これらは false pathsです」と解釈されます。
set_min_delay および set_max_delay
選択した pathsのグループに対する timing 要件を排除する false pathsについての議論から始めました。多くの場合、 timing 要件をキャンセルするのではなく、要件を指定する必要があります。これは、 set_min_delay と set_max_delayで行われます。たとえば、次の Verilog コードを考えてみましょう。
reg x, y;
always @(posedge clk)
y <= x;
timing constraints:
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から始めましょう。この timing exception の簡単な説明は、特定の paths のみを対象とした clock period constraint (create_clock) に似ているということです。
clock period constraint が定義されると、ツールは必要な timing 要件を自動的に適用することを思い出してください。 関連する paths の最大 delays は、 tsetup 要件を満たすために制限されています。同様に、最小限の delays は tholdに代わって制限されます。
上記の例では、 set_max_delay コマンドに表示される値は 3です。これは、 3 nsに等しい clock period に対する create_clock コマンドと同等です。しかし、 set_max_delayの影響は pathsの特定のグループに限られています。それが違いです。
set_min_delayに関しては、もう少し複雑なので、以下で詳しく説明します。
set_max_delay コマンドの名前は誤解を招くことに注意してください。 このコマンドは、 path 自体の最大 delay を直接定義しません。影響を受ける paths の delay は、上記の例のコマンドによって 3 ns に限定されません。 3 ns 値は、 clock edges間の許容時間差として適用されます。そして、この時間差は、 synchronous elementsの clock inputsではなく、これらの clocksの原点で測定されています。これは、 PLLs、 clock buffers 、および clock routing の delays が計算に含まれることを意味します。 clock period constraintと同様に、 clock delays は timing analysisで考慮されます。
-from、 -to、 -through 、その他の arguments の意味は set_false_pathと同じです。しかし、一般的に言えば、 set_min_delay と set_max_delay は clock period constraintの調整を目的としています。したがって、通常、 pathの両側に sequential elements があると想定されます。したがって、 -from と -to は synchronous elementsを表す必要があります。これらを参照するには多くの方法があります。 synchronous element 自体を表す cell object 、 clock objectなど。
set_min_delayに関しても、同様の話があります。 clock period constraint のもう 1 つの影響は、ツールが thold の要件を満たす必要があることです。この目的のために、ツールは、同じ clock 間またはrelated clocks間のすべての paths に最小限の delays を適用します。 path の timing 計算が create_clock のみの結果である場合 (両側に同じ clock がある場合)、これは値ゼロの set_min_delay と同等です。これは、同じ clock edge が両方の sequential elementsに到達するという考えを反映しています。ただし、これは、この clock edge がこれらの sequential elementsに同時に到着するという意味ではありません。むしろ、各 sequential element の clock edges は、 clockの原点で同時に開始します。各 clockの原点から sequential element までの delay が計算で考慮されます ( tsetupの計算方法と同様)。
set_min_delay は、2 番目の sequential elementに到着する clock edge の時間を調整することができます。たとえば、上記のコマンドは、この clock edge が 2 番目の flip-flopで 1 ns によって遅れて到着するようにします。これにより、 thold の timing 要件を満たすことが難しくなります。 以下の timing report の例を参照してください。
set_min_delay と set_max_delayを使用する理由として、次の 2 つが考えられます。
- ツールが他の方法で強制する timing 要件が、特定の pathsのグループには不十分な場合。たとえば、 metastability guardで始まる paths で timing 要件をより厳しくする必要がある場合。
- pathsに関連する timing constraint がない場合。この目的で set_max_delay を使用する場合は、代わりに clock period constraint またはmulti-cycle pathsが必要ないかどうかを自問してください。
この 2 つのコマンドを使用する場合は、 timing reportsで paths の timing 計算を常に注意深く確認してください。特に、 clock path が計算でどのような役割を果たすかに注意してください。
このページの下部に timing reports の例があり、 set_min_delay と set_max_delayの結果を示しています。
delayのより正確な制御
set_max_delay および set_min_delay によって提供される制御のレベルは、 clock period constraint よりも大幅に優れているわけではありません (これまでに説明したとおり)。しかし、 clock path delay が delayの定義に干渉したくない場合はどうすればよいでしょうか? pathの特定の segment の delay を制御したい場合はどうすればよいでしょうか?
一部の FPGA ツールは、これらのニーズに対するソリューションを提供していません。たとえば、 Quartus ではそのような可能性はありません (私の知る限り)。一方、 Vivadoにはいくつかの機能があり、簡単に説明します。
そのような機能の 1 つが datapath_only オプションです。 timing の計算に clock pathsが含まれないように、 set_max_delay を使用することが望ましい場合があります。たとえば、 path が unrelated clocksの間にある場合、 clock paths を考慮しても意味がありません。
datapath_only が使用される場合、 timing は、両方の synchronous elements の clock path delay がゼロであるかのように計算されます。したがって、計算は pathの logic elements の delays のみで構成されます。これらの delays の合計は、 set_max_delay コマンドで指定された数値よりも小さい必要があります (以下の timing report の例を参照)。
したがって、 set_max_delay を datapath_onlyと共に使用すると、その意味はこのコマンドの名前が意味するものに近くなります。ただし、 path は synchronous elementで開始および終了する必要があることに注意してください。
また、 datapath_only にはいくつかの特徴があります。 これを使用すると、ツールは、関連する pathsの thold に関する timing 要件を強制しません。つまり、ツールは、 thold シナリオにのみ適用された false path constraint があるかのように動作します。該当する pathsに対して set_min_delay コマンドを追加しても、このコマンドは無視されます。 Vivado が、 datapath_onlyの影響を受ける paths に最小限の delay を強制することを拒否する理由は明らかではありません。
datapath_only は、どのシナリオでも argument から set_min_delay として使用することはできません。
誤解を招く機能
このセクションのタイトルが示すように、これらは何の役にも立たない可能性がいくつかあります。次のセクションに進んでください。
Vivado ではさらに高度な制御が可能です。 pathの特定の segment の delay に制限を適用することができます。たとえば、 sequential elements ではない logic elements を -from と -toで使用するとどうなりますか? pins と netsはどうですか? set_min_delay と set_max_delay は何をしますか?
もちろん、それはどの FPGA ツールが使用されているかによって異なります。要件に一致する paths がないため、ツールはそのような constraintsを黙って無視する場合があります。しかし、 Vivado はそのような constraintsを無視しませんが、結果は自然に期待されるものではありません: Vivado はこの状況を「path segmentation」と見なし、応答として critical warning を発行します。ほとんどの場合、この機能を使用する価値はありません。詳細については、ドキュメントを参照してください。
そして、誤解を招く可能性のある別の機能を次に示します。 Quartus には set_net_delayというコマンドがあります。 design内の異なる logic elements 間で最小および最大の delay を定義できます。ただし、ツールは implementation中にこれらの timing 要件を達成しようとしていないようです。代わりに、"report_net_delay" (または GUI) を使用してレポートを生成することができます。したがって、このレポートから、 set_net_delay で定義された条件が満たされているかどうかを推測できます。したがって、 set_net_delay を使用して情報を取得することはできますが、 timing constraintとしては役に立ちません。言い換えると： set_max_delay と set_min_delay は timing constraintsとして有効ですが、 set_net_delay は有効ではありません。
要約すると、 set_max_delay と set_min_delayを使用する単純な方法よりもはるかに優れているわけではありません。一見、興味深い機能は Vivadoの datapath_onlyだけです。
timing constraintsの優先順位
複雑な timing constraints の主な問題は、 paths が複数の constraintの影響を受けることが多いことです。これらの constraints には通常、これらの pathsに対する timing の要件が矛盾しています。では、どの constraint が勝つのでしょうか?
各 FPGA ツールには、この種の競合を解決する方法に関する独自のルールがあります。通常、主に constraintのタイプに依存します。他の要因、特に pathsの選択の特異性も影響している可能性があります。
SDCに基づく timing constraints の場合、優先順位は constraintのタイプによって異なります。たとえば、 Vivado は、この優先順位に従って競合を解決します。コマンドは、優先順位の高いものから順にリストされています。
- set_clock_groups ( related clocks と unrelated clocksのグループ)
- set_false_path (false path)
- set_min_delay および set_max_delay (minimum delays および maximum delays)
- set_multicycle_path (multicycle path)
- create_clock (clock period)
最初の 2 つのコマンド (set_clock_groups と set_false_path) は false pathsを作成し、それらのコマンドの優先度が最も高いことに注意してください。したがって、 path がこれらのコマンドによって誤って影響を受けないことを確認することが非常に重要です。このような間違いは、関連する pathsでの timing 要件のすべての強制を暗黙のうちにオフにします。
同じ pathに対して同じコマンドが複数回使用された場合、最も具体的なコマンドが優先されます。たとえば、1 つのコマンドに「-from」と「-to」があり、2 番目のコマンドに「-from」しかない場合、最初のコマンドが優先されます。もう一つの例： 1 つのコマンドが logic elements に基づいて paths を定義し (たとえば、 get_cellsを使用)、2 番目のコマンドが clocks に基づいて paths を定義する場合 ( get_clocksを使用)、最初のコマンドが優先されます。
2 つのコマンドが類似しており、優先順位に違いがない場合は、出現順序によって競合が解決されます。 最後のコマンドが勝ちます。
Quartus および SDCに基づくその他のツールでは、同様の優先規則が使用されます。
ただし、使用するツールに関係なく、 timing constraints 間の矛盾を避けるのが最善です ( create_clockを覆す場合を除く)。複雑な timing constraints は、壊滅的なバグが発生しやすい場所です。
一部の FPGA ツールでは、優先度ルールを回避できます。 -reset_path オプションを使用すると、現在のコマンドは、それが適用されるすべての paths で以前の timing exceptions を無効にします。例えば：
set_max_delay -reset_path -from [get_cells source_reg] 2
結論
このページは、 timing constraints は短く、シンプルで、簡潔であるべきだということから始めました。 timing exceptionsを追加することで、 timing constraints は長くなるだけでなく、より複雑でわかりにくくなります。したがって、必要に応じて timing exceptions を使用しますが、注意して書き、整頓してください。
timing exception コマンドは、その目的を反映し、その背後にあるアイデアを表現する方法で記述するようにしてください。 FPGA ツールは通常、 timing constraintsを作成するための GUI wizards を提供します。それらは出発点として役立ちます。ただし、慎重に検討する前に、 wizard によって作成された timing constraint を使用しないでください。この constraint が作成時に正しくても、 logic design が進化し、新しい logic が追加されても、引き続き忠実に動作しますか?
timing exceptionの影響を受ける paths については、常に timing reports をお読みください。 pathに対して複数の timing constraints がある場合、これはさらに重要です。また、 timing 要件が正しくない可能性がある paths 用の特定の timing reports を作成します。
覚えて： timing reports の作成と読み取りは時間の無駄ではありません。ドキュメントをどれだけ注意深く読んでも (これは常に良い考えです)、間違いを犯す可能性は常にあります。特に、 false paths は予想外の場所で発生する可能性があります。
ボーナス： timing reportsの例
set_min_delay と set_max_delayの理解を助けるために、これらは Vivadoで作成されたいくつかの timing reports です。
上記から、これらのレポートの背後にある Verilog コードは次のとおりであることを思い出してください。
always @(posedge clk)
y <= x;
timing constraints:
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
delayの値 (3 ns) は、2 番目の flip-flopの clock path の開始時間として使用されることに注意してください。つまり、 3 nsに対して period constraint があったかのようです。
また、 data path の net には巨大な delayがあることに注意してください。 2.478 ns.これは、 set_min_delay コマンドの結果です。 ツールは、 thold の要件を満たすために、この net に長い delay を挿入する必要があります。
そういえば、これは thold用の timing report です。
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
ここでも、 delayの値 (1 ns) が 2 番目の flip-flopの clock path の開始時間として使用されることに注意してください。 set_min_delay コマンドがない場合 (つまり、 clock period constraintのみ)、これは 0 nsです。
data path の net の delay は 1.092 nsです。これは、 thold の要件を満たすのに十分です。なぜ以前は 2.478 ns だったのですか? tsetup のワーストケースの計算が「Max at Slow Process Corner」に対して行われたためです。したがって、 2.478 ns は関連する netの可能な最長の delay であり、 1.092 ns は可能な限り短い delay (「Min at Fast Process Corner」) です。これについての詳細は、 Multi-corner timing analysisに関する議論を参照してください。
3 番目の例は datapath_onlyを示しているため、 constraint は次のようになります。
set_max_delay -datapath_only -from [get_cells x_reg] -to [get_cells y_reg] 3
とにかく無視されるため（ set_max_delay コマンドの後に書き込まれたとしても）、 set_min_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
この timing report の構造は以前と同じですが、 clock paths に関連するすべてが削除されていることに注意してください。
ツールには長い delayを挿入する理由がなかったため、 net の delay は小さいです。 thold 要件はありません。
また、 timing の要件がないため (最小の delay は false pathとして扱われます)、 tholdの timing report は示していません。
これで、 timing exceptionsに関する一般的な説明を終了します。次のページでは、 clock domain crossingに必要な timing exceptions について説明します。