このページは、 timingに関する一連のページに属します。前のページでは、 timing 計算の背後にある理論を説明し、 clock period constraintについて議論し、 timing closureの原理を示し、いくつかの重要な Tcl commandsを紹介しました。このページでは、特定の 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 構文におけるこれらの目的のための commands は主に次のとおりです。
- set_false_path: 選択した pathsに timing 要件を適用しないことをツールに通知します。
- set_max_delay: tsetupの実施要件を定義します。
- set_min_delay: tholdの実施要件を定義します。
- set_multicycle_path: clock enable signalによって制御される logic の要件を緩和します。
異なる構文を使用するツールは、同様の commandsを持つ可能性があります。
これらの commandsの arguments は、(他のものとともに) どの paths が影響を受けるかを定義します。これについては以下で説明します。
他のページで説明されている 2 つの関連トピックがあります。
- I/O timing constraintsについては別のページがあります。したがって、以下の説明は、これらの commands を内部 paths (つまり、 logic fabric内の sequential logic element との間で移動する paths ) と併用する場合に限定されます。
- 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 requirements が必要ない場合は、 false pathとして宣言する必要があります。
clock domain crossingsと関連して set_false_path を使用するのはよくある間違いです。このトピックについては、後で詳しく説明します。実際、 I/O portsを除いて、 set_false_pathを使用するのが正しい状況はあまりありません。
set_false_pathに paths を選択する
command が適用される paths を選択する方法は多数あります。可能性は多岐にわたりますが、 paths の選択は通常、2 つの argumentsで行われます。 -from と -to。例えば：
set_false_path -from [get_cells source_reg] -to [get_cells dest_reg]
この例では、 set_false_path command は、 @source register で始まり、 @dest registerで終わる path に適用されます。
get_cells は、 logic elementsを表す objects とともに -from と -to を提供することに注意してください。前のページで説明した他の commands も使用できます。 get_pins、 get_nets、 get_ports 、 get_clocks。ただし、各 FPGA tool には、 -from および -toでの使用が許容される内容に関する独自のルールがあります。
ツールは、当然予想されるように objects への参照を解釈しない可能性があることに注意してください。ツールは、警告を出さずに objects の一部またはすべてを無視することもあります。実際、 get_* command によって objects が見つからない場合 (たとえば、 search patternの間違いのため)、 timing exceptionに path は含まれません。これも警告なしで発生する可能性があります。
したがって、 timing report を使用して、 timing exceptions が意図したとおりに適用されていることを確認することが重要です。これは、正しい paths が影響を受け、 timing analysis が正確な目的を果たしていることを意味します ( timing requirementsは強制されません)。
pathsを選択するための別の便利な argument があります。 -through.その名前が示すように、この argument は、特定の logic elementsを通過する paths を選択します。
すべての機能を把握するために、時間をかけて公式ドキュメントを読む価値があります。たとえば、 command の効果を rising clock edges または falling clock edgesのみに制限することもできます。別の可能性としては、 command を tsetup のみまたは tholdのみの分析に制限することです。
set_false_path command には、 argument (または同様の意味を持つ別の argument ) として、 -from、 -to 、または -through の少なくとも 1 つが必要です。 argumentが複数ある場合、 timing exception はすべての argumentsの条件を満たす paths にのみ適用されます。
set_false_pathの危険性
false paths の問題点は、間違いを犯しやすいことです。特に、意図したよりも多くの paths を含めるリスクがあります。これが発生すると、正しく動作しない可能性がある sequential elements があります。 私たちは、ツールが tsu と tholdの要件を保証すると誤って期待しています。しかし、実際には、ツールは、これらの sequential elements に対する paths が false pathsであるかのように動作します。そのため、ツールはそれらのために timing analysis を作成しません。これは危険な状況です。ツールが timing constraints が達成されたと言っているときに、すべてが正常であるという幻想を生み出すからです。しかし、実際には、 flip-flops やその他の sequential elements が、何の保護もなく timing violations にさらされています。
さらに悪いことに、 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 requirements を削除する false pathsについて説明しました。多くの場合、 timing requirementsをキャンセルするのではなく、指定する必要があります。これは、 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
では、これらの commandsの意味は何でしょうか? まず、 set_max_delayから始めましょう。この timing exception を簡単に説明すると、特定の paths のみを対象とした clock period constraint (create_clock) に似ているということです。
clock period constraint が定義されると、ツールは必要な timing requirementsを自動的に適用することを思い出してください。 関連する paths の最大 delays は、 tsetup 要件を満たすために制限されています。同様に、最小限の delays は tholdに代わって制限されます。
上記の例では、 set_max_delay command に表示される値は 3です。これは、 3 nsに等しい clock period の create_clock command に相当します。ただし、 set_max_delayの影響は、 pathsの特定のグループに限定されます。これが違いです。
set_min_delayに関しては、もう少し複雑なので、以下で詳しく説明します。
set_max_delay command という名前は誤解を招く可能性があることに注意してください。 この command は、 path 自体の最大 delay を直接定義するものではありません。影響を受ける paths の delay は、上記の例の command によって 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 の時間を調整できます。たとえば、上記の command により、この clock edge は 2 番目の flip-flopで 1 ns 遅れて到着します。これにより、 thold の timing 要件を満たすことが難しくなります。 以下の timing report の例を参照してください。
set_min_delay と set_max_delayを使用する理由として、次の 2 つが考えられます。
- ツールが強制する timing 要件が、特定の pathsのグループには不十分な場合。たとえば、 metastability guardで始まる paths に対して timing requirement をより厳密にする必要がある場合などです。
- pathsに関連する timing constraint がない場合。この目的で set_max_delay を使用する場合は、代わりに clock period constraint またはmulti-cycle pathsが必要ないかどうかを自問してください。
これら 2 つの commands を使用する場合は、 timing reports内の paths の timing analysis を常に注意深く確認してください。特に、 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 tools では、これらのニーズに対するソリューションが提供されていません。たとえば、 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 command で指定された数値よりも小さくする必要があります (以下の timing report の例を参照)。
したがって、 set_max_delay を datapath_onlyと一緒に使用すると、その意味はこの command's の名前が示すものに近くなります。ただし、 path は依然として synchronous elementで始まり、終わる必要があることに注意してください。
また、 datapath_only にはいくつかの特徴があります。 これを使用すると、ツールは関連する pathsの thold に関して timing requirement を強制しません。つまり、ツールは、 thold シナリオにのみ適用された false path constraint があるかのように動作します。関連する pathsに set_min_delay command が追加されても、この command は無視されます。 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 tool が使用されているかによって異なります。要件に一致する paths がないため、ツールはそのような constraintsを黙って無視する場合があります。ただし、結果は当然予想されるものとは異なりますが、 Vivado はそのような constraintsを無視しません。 Vivado はこの状況を「path segmentation」と見なし、応答として critical warning を発行します。ほとんどの場合、この機能を使用する価値はありません。詳細については、ドキュメントを参照してください。
そして、誤解を招く可能性のある別の機能を次に示します。 Quartus には、 set_net_delayと呼ばれる command があります。これにより、 design内の異なる logic elements 間の最小および最大の delay を定義できます。ただし、ツールは implementation中にこれらの timing requirements を達成しようとしないようです。代わりに、「report_net_delay」(または GUI) を使用して report を生成することができます。したがって、 set_net_delay で定義された条件が満たされたかどうかをこの report から推測できます。したがって、 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 の主な問題は、複数の constraintの影響を受ける paths が頻繁に存在することです。これらの constraints は通常、これらの pathsと矛盾する timing requirements を持ちます。では、どの constraint が勝つのでしょうか?
各 FPGA tool には、この種の競合を解決するための独自のルールがあります。通常、これは主に constraintのタイプによって決まります。他の要因、特に pathsの選択の特殊性が影響する場合もあります。
SDCに基づく timing constraints の場合、優先順位は constraintのタイプによって異なります。たとえば、 Vivado は、この優先順位に従って競合を解決します。 commands は、優先順位の高いものから低いものの順にリストされています。
- 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 つの commands (set_clock_groups と set_false_path) は false pathsを作成し、最も高い優先度を持っていることに注意してください。したがって、これらの commandsによって path が誤って影響を受けないようにすることが非常に重要です。このような間違いは、関連する pathsに対する timing 要件のすべての強制を暗黙的に無効にします。
同じ pathに同じ command が複数回使用されている場合、最も具体的な command が優先されます。たとえば、1 つの command に「-from」と「-to」があり、2 番目の command に「-from」しかない場合、最初の command が優先されます。別の例: 1 つの command が logic elements に基づいて (たとえば get_cellsとともに) paths を定義し、2 番目の command が clocks に基づいて ( get_clocksとともに) paths を定義する場合、最初の command が優先されます。
2 つの commands が非常に類似していて優先順位に違いがない場合は、出現順序によって競合が解決されます。 最後の command が勝利。
Quartus および SDCに基づくその他のツールでは、同様の優先規則が使用されます。
ただし、使用するツールに関係なく、 timing constraints 間の矛盾を避けるのが最善です ( create_clockを覆す場合を除く)。複雑な timing constraints は、壊滅的なバグが発生しやすい場所です。
一部の FPGA toolsでは、優先ルールを回避することが可能です。 -reset_path attributeを使用すると、この attribute を使用する command は、適用されるすべての paths 上の以前の timing exceptions を無効にします。例:
set_max_delay -reset_path -from [get_cells source_reg] 2
結論
このページは、 timing constraints は短く、シンプルで、簡潔であるべきだということから始めました。 timing exceptionsを追加することで、 timing constraints は長くなるだけでなく、より複雑でわかりにくくなります。したがって、必要に応じて timing exceptions を使用しますが、注意して書き、整頓してください。
timing exception commands は、その目的を反映し、その背後にあるアイデアを表現する方法で記述するようにしてください。 FPGA tools は通常、 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 です。
上記を思い出してください。これらの 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用の report :
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 commandの結果です。 ツールは、 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 command がない場合 (つまり、 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_min_delayは存在しません。いずれにせよ無視されるからです ( set_max_delay commandの後に書き込まれたとしても)。
tsetup の report は現在:
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 requirement が存在しないため、 tholdの timing report は表示されません (最小の delay は false pathとして扱われます)。
これで、 timing exceptionsに関する一般的な説明を終了します。次のページでは、 clock domain crossingに必要な timing exceptions について説明します。