このページは、 timingに関する一連のページに属しています。前のページでは、 timing 計算の背後にある理論を説明し、いくつかの timing constraints を記述する方法を示し、 timing closureの原理について説明しました。このページでは、 clock domainsに関連する timing constraints を定義する方法について説明します。
序章
特定の logic elements を見つける方法と pathsを定義する方法に関する知識を備えたので、この知識を利用する timing constraints を見ていきます。
最初に見ていくのは、 timing constraints と clock domainsの関係です。これら 2 つのトピックは密接に関連しており、一方を含めずに一方を議論することは不可能です。したがって、このトピックが初めての場合は、 clock domainsに関するこの一連のページを読むことをお勧めします。特に、これは以下で使用する用語を理解するために必要です。
logic は、 clocks間の関係を定義します。
この Verilog コードの例を見てみましょう。
module top(
input clk,
input foo,
output reg bar_reg,
output reg baz
);
reg foo_reg;
reg bar;
reg baz_metaguard;
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
always @(posedge clk)
begin
baz_metaguard <= bar;
baz <= baz_metaguard;
end
これは、先ほど見た PLLの例とほぼ同じです。違いは、新しい clock domain crossingがあることです。 @bar の値は、 metastability guardを介して @baz にコピーされます。
したがって、この例には 2 種類の clock domain crossings があります。
- @foo_reg から @barまで、2 つの related clocks の間 ( metastability guardはありません)。
- @bar から @bazまで、2 つの unrelated clocks の間 (@baz_metaguard は metastability guardです)。
clock domain crossingのタイプを決定する基準は 1 つだけです。 metastability guardの有無。 logic が unrelated clocksを想定している場合、必要な安全メカニズムを使用します。したがって、他に問題はありません。 これらの clocksの間の paths で timing 要件を保証することができたとしても、これを行う理由はありません。
およびその逆： logic が related clocksを想定している場合、 timing violationsに対する保護はありません。したがって、これらの clocks間のすべての paths で timing の要件を満たす必要があります。
したがって、結論として、 logic は常に、どの clocks が related clocks であり、どれがそうでないかを想定しています。これらの仮定は、保護メカニズムの有無に反映されます。しかし、これらの仮定が現実になることを確認するのは FPGA ツールです。特に、このツールは、 timing 要件が related clocks間の paths で確実に満たされるようにします。
そのため、ツールが clocksに関する logicの前提を認識していることを確認する必要があります。
上記の例では、ツールは @pll_clk_6 と @clkに関する logicの期待を知る方法がないことに注意してください。 logic は、これらが related clocks であると想定し、その逆を想定する場合があります。実際、 related clocks間の path をデモンストレーションするために、以前に同様の例(「アイデア #9」を参照) を使用しました。上記の例では、これら 2 つの clocks が unrelated clocksとして扱われます。
おそらく、ツールは @baz_metaguardの名前からインテリジェントな推測を行うことができます。 metastability guard の典型的な構造がヒントになるかもしれません。しかし、そのような重要な問題について決定を下すには、それだけでは十分ではありません。
clocksについてツールに伝える
これまでの例では、 timing constraintは 1 つだけでした。
create_clock -period 4.000 -name clk [get_ports clk]
頭に浮かぶ最初の質問は、ツールがデフォルトで @pll_clk_6 から @clk への clock domain crossing をどのように扱うかということです。これが唯一の timing constraintである場合、ツールは @bar と @baz_metaguardの間で path に何かを適用しますか?
答えは、使用する FPGA ツールによって異なります。事実上すべての FPGA ツールが @pll_clk_6 と @pll_clk_8 を related clocksと見なしますが、 clocksの他のペアで何が起こるかは明らかではありません。ツールは通常、デフォルトですべての clocks を related clocks として扱いますが、それに依存するのは安全ではありません。
多くの FPGA ツールが set_clock_groups コマンドをサポートしています。これは、 clocks間の関係を定義するための最良のオプションです。このコマンドは重要であるため、 designで使用する前にツールのドキュメントを参照することをお勧めします。
上記の例では、このコマンドは Vivado で次のように使用できます (または他のツールでも同様です)。
set_clock_groups -asynchronous \
-group [list \
[get_clocks -of_objects [get_pins pll_i/clk_out1] ] \
[get_clocks -of_objects [get_pins pll_i/clk_out2] ] ] \
-group [get_clocks -of_objects [ get_pins pll_i/clk_in1] ]
get_clocks と get_pins のこの使用法は前に説明されました: 各 get_clock コマンドは、 clk_wiz_1 の関連する port の名前に従って clock object を検索します ( clk_wiz_1の instantiation の名前は pll_iであることに注意してください)。たとえば、最後の get_clock コマンドは、 @clkの clock object を取得します。
この例は、 set_clock_groups が clocksのグループを定義する方法を示しています。この場合、1 つのグループは @pll_clk_6 と @pll_clk_8で構成され、2 つ目のグループは @clk のみで構成されます。この constraint は、同じグループに属するすべての clocks が related clocksであることをツールに伝えます。同様に、2 つの clocks が異なるグループに属している場合、ツールはそれらを unrelated clocksと見なします。
つまり、ツールは、 path の両側の clocks が同じグループに属している場合に限り、 path に timing constraints を適用します。
designの timing constraintsでは、複数の set_clock_groups コマンドを使用できます。ただし、1 つの set_clock_groups コマンドを使用してすべての clocks をグループに分割するのが最適です。これは矛盾を回避し、混乱を防ぐのにも役立ちます: このコマンドの主な利点は、 clocks間の関係を簡潔に説明できることです。短く、簡潔で、数学的。それが私たちが望む方法です。
set_clock_groups はすべての create_clock コマンドの後に使用する必要があることに注意してください。これは、前述の clocks objects が既に存在している必要があるためです。
clocks間の一貫性のない関係
clocks が designの一部で related clocks 、別の場所で unrelated clocks と見なされる場合、 set_clock_groupsを使用することはできません。
たとえば、 @clk と @pll_clk_6 は、上記の Verilog コードでは unrelated clocks として扱われます。しかし、理論的には、それらを related clocksとして扱う追加の logic が存在する可能性があります。良い考えではありませんが、この追加の logicに対して @pll_clk_6 と @clk の間に timing constraints を強制することは可能です。
この理由で set_clock_groups を使用できない場合は、まず logicを変更したくないかどうかを自問して、 set_clock_groups を使用できるようにします。このコマンドが優れているからというだけではありません。 どの clocks が related clocks でどれがそうでないかを示す単純なルールがないと、 clock domain crossingsで間違いを犯しやすくなります。それでも logicでそのような変更を行いたくない場合、解決策は false pathsを定義することです。
set_false_path コマンドについて簡単に
false pathsを宣言するための主なコマンドは 2 つあります。 set_clock_groups とset_false_paths 。
set_clock_groups コマンドは上に示されています。 異なるグループに属する 2 つの clocks 間の path は、 false pathと見なされます。ただし、 false pathとして宣言する必要があるすべての paths に対して set_clock_groups を常に使用できるとは限りません。場合によっては、 paths の選択は、 clocksのグループを定義するよりも具体的でなければなりません。 set_false_path コマンドは、 pathsの特定の選択を可能にすることで、この問題を解決します。
たとえば、上記の set_clock_groups コマンドを set_false_path コマンドに置き換えてみましょう。修正が必要なのは、 @bar から @baz_metaguardへの path だけです。他のすべての paths の timing 要件はそのまま正しく適用されます。したがって、これはこの pathに対して set_false_path コマンドを記述する 1 つの方法です。しかし、この例から学ばないでください:
set_false_path -from [get_cells bar_reg__0] -to [get_cells baz_metaguard_reg]
このコマンドは、 get_cells を使用して、 pathの始まりと pathの終わりを選択します。これには、両側の cell objects の名前を知っている必要があります。この場合、「bar_reg__0」という名前があり、名前に依存することの問題を示しています。 この名前は「bar_reg」のはずでしたが、すでに説明したように、偶然にも「bar_reg__0」になりました。
したがって、この例は set_false_pathの問題の 1 つを示しています。 design で logic elements を詳細に選択するには、 objectの名前に頼らざるを得ないことがよくあります。この問題と考えられる解決策については、以前に説明しました。
このコマンドは簡略化できます。 @baz_metaguard は metastability guardであるため、 paths からこの register がどこから来たのかは関係ありません。では、この registerまでのすべての paths を無視してみませんか?
set_false_path -to [get_cells baz_metaguard_reg]
このコマンドの効果はまったく同じです。
set_clock_groupsの代わりにset_false_path
別の可能性は、 clocksに従って paths を定義することです。実際、上記の set_clock_groups コマンドは、次の constraintsに置き換えることができます。
set_false_path -from [get_clocks -of_objects [get_pins pll_i/clk_out1]] \
-to [get_clocks -of_objects [ get_pins pll_i/clk_in1] ]
set_false_path -from [get_clocks -of_objects [get_pins pll_i/clk_out2] ] \
-to [get_clocks -of_objects [ get_pins pll_i/clk_in1] ]
set_false_path -from [get_clocks -of_objects [ get_pins pll_i/clk_in1] ] \
-to [get_clocks -of_objects [get_pins pll_i/clk_out1] ]
set_false_path -from [get_clocks -of_objects [ get_pins pll_i/clk_in1] ] \
-to [get_clocks -of_objects [get_pins pll_i/clk_out2] ]
これは、同じ false pathsを作成するための長く詳細な方法です。 clocks をグループに分割する代わりに、 unrelated clocksの各ペアに対して 2 つの set_false_path コマンドがあります。 方向ごとに 1 つのコマンド。非常に多くの constraintsで間違いを犯しやすいことは明らかです。そして、これは 3 つの clocksを使用した単純な例です。
それにもかかわらず、 set_clock_groupsの代わりに set_false_path がこのように使用されることがよくあります。これはおそらく誰かがどこかから timing constraints をコピーしたためです。
間違いが起こりうる例
考えられる間違いの簡単な例を見てみましょう。 上記の説明から、 false pathとして宣言する必要がある path は 1 つだけであることは明らかです。 @bar から @baz_metaguardへ。したがって、最後の例の 4 つの set_false_path コマンドのうち、重要なのは次の 1 つだけです。
set_false_path -from [get_clocks -of_objects [get_pins pll_i/clk_out2] ] \
-to [get_clocks -of_objects [ get_pins pll_i/clk_in1] ]
他の 3 つの set_false_path コマンドは、 pathsをカバーしていません。でもちょっと待って、 constraint をさらに簡素化してはどうでしょうか?たぶん、 @clk で終わるすべての paths は false pathsである必要がありますか?これはどう？
set_false_path -to [get_clocks -of_objects [ get_pins pll_i/clk_in1] ]
実際には、「clk」を定義する create_clock コマンドは set_false_path コマンドのすぐ上にあるため、代わりに次のように記述できます。
set_false_path -to [get_clocks clk]
この constraint は短くてエレガントです。残念ながら、それはひどく間違っています: 私は、 @clk で終わるすべての paths を false pathにすることを提案しました。しかし、 @baz_metaguard から @bazへの path はどうですか?それは @clk から @clkへの path です。もちろん、この path が false pathであってはなりません。ただし、最後の 2 つの set_false_path コマンドには、 path が @clkで始まる場合でも、 @clkで終わるすべての paths が含まれます。
特に、 false path 用の constraints が数学的な考え方の精度なしで書かれている場合、この種の間違いを犯しやすいです。どの paths が false paths でどの false paths でないかを明らかにできる特別な timing reportsを作成すると役立つ場合があります。
これで、 FPGAの内部にある paths に対する timing constraints に関する実際的な議論を終了します。次のページでは、このトピックに属する multi-cycle pathsについて説明します。ただし、通常、 multi-cycle path constraints は推奨されません。したがって、代わりに I/O constraintsの紹介にスキップしても問題ありません。