01signal.com

timing closureの戦略

中文 | 日本語 | 한국어 | English

このページは、 timingに関する一連のページに属しています。前のページでは、 timing 計算の背後にある理論を説明し、 clock period constraintについて説明し、 timing closureを紹介しました。しかし、正しく設定しようとしても、 timing に問題がある場合はどうでしょうか?このページでは、その質問に答えようとします。

序章

前のページでは、 timing closure の問題を解決する方法は 1 つだけではないことを説明しました。 critical pathに注目するのが正しい場合もあれば、そうでない場合もあります。ツールの設定を変更するだけで問題を簡単に解決できる場合もあれば、それよりもはるかに難しい場合もあります。問題の根本原因にたどり着くには、持てるすべての経験と知恵を活用することに勝るものはありません。チェックリストで timing closure を要約する方法はありません。

それでも、可能な戦略のリストがあると役立つことがよくあります。そこで、このページでは、 timingで問題に直面したときに考慮すべきトピックをいくつか集めました。特定の timing の問題を解決する必要があるためにこれを読んだ場合、これらのアイデアの 1 つが解決策につながる可能性があります。ただし、解決策がここで詳しく説明されるとは思わないでください。

また、この一連のページはここで終わりではないことに注意してください。動機付けのために、他の多くのトピックの前に timing closure について説明することにしました。ただし、以降のページの情報も関連しています。

同じ理由で、 I/O timing constraints に関する議論は後で延期されます。とりあえず、 FPGAで始まり FPGAで終わる paths に注目。

そこで、 timing closureに関して考慮すべきいくつかのアイデアを紹介します。

アイデア #1: logic designを修正

これは常に最も魅力のないソリューションです。これは特に、 design が適切に動作することが既にわかっている場合に当てはまります。機能するものを変更したくありません。それでも、多くの場合、問題の根本的な理由は、必要なパフォーマンスに対して Verilog コードが十分に書かれていないことです。 logic design の変更は、進行中の問題に直面する代わりに、問題を完全に解決します。

前のページに、高速な logic を記述するためのいくつかの提案があります。そして、これを繰り返す価値があります： 開発プロセス中は常に timing を念頭に置いてください。 Verilog コードを最初から適切に記述するよりも、 timing の問題を修正する方がはるかに困難です。

アイデア #2: fan-outを減らす

net の fan-outが高い場合、 propagation delay は次の 2 つの主な理由で増加します。

designで synchronous reset が使用されている場合、この signal は fan-outが高い可能性があります。このトピックについては、別のページで説明します。

ただし、 logic elements に大きく達するすべての signal は、高い fan-outのために timing の問題を引き起こす可能性があります。この高い fan-out は明らかな場合もあれば (例: clock enable signals)、高い fan-outを予想するのはそれほど簡単ではない場合もあります。 FPGA tools は、通常、最も高い fan-outsを持つ nets をリストすることで役立ちます。

fan-out を低く保つ方法は 2 つあります。

明らかに、両方の方法で同じ結果が得られます。 fan-out が高い register は、いくつかの registersに複製されます。したがって、これがツールによって (最初の方法で) 自動的に実行できるのであれば、わざわざ手動で (2 番目の方法のように) 行う必要はありません。

2 番目の方法はより多くの労力を必要としますが、大きな利点が 1 つあります。 賢明な方法で register を複製することは可能です。目標は fan-outを削減することだけではないことに注意してください。各 register の output が、 logic fabric上の小さな領域に配置された logic elements に分散されることも重要です。それ以外の場合、物理的な距離のために、結果は routing delays と大きくなります。したがって、 Verilog コードが fan-out を念頭に置いて記述されている場合、 logic elements間の短い接続を確保することが可能です。これは、別のページで synchronous reset signal について示されています。

対照的に、 FPGA tools が registersの複製を担当する場合、結果はそれほど効率的ではない可能性があります。 routing delay の改善は、複製された各 register の使用方法を決定するアルゴリズムに依存します。結果の品質は、どの FPGA tool が使用されるかによって異なります。

デフォルトでは、 synthesizer がまったく同じ動作をする 2 つの registers を検出すると、これらの registers は自動的に 1 つの registerにマージされることに注意してください。したがって、 register が Verilog コードでレプリケートされる場合、 synthesizer はすべてのレプリカを 1 つの registerに置き換えます。これは、これらの同等の registers が異なる modulesで定義されている場合でも当てはまります。このマージを回避するには、この機能を明示的に無効にする必要があります。これを実現する一般的な方法は、 synthesis attributes、たとえば「dont_touch」、「dont_merge」、または「keep」を使用することです。

アイデア #3: floorplanningをチェック

デフォルトでは、 logic fabric 上の logic elements の配置は、 FPGA tools (より正確には placer) によって自動的に決定されます。ただし、特定の logic elements を FPGA上の特定の領域に配置するように要求することは可能です。また、特定の logic element を特定の位置に配置するように要求することもできます。この種の要求はfloorplanningと呼ばれます。これらの要求は placement constraintsによって行われ、多くの場合、 timing constraintsに類似した構文を持つ Tcl commands です。

ほとんどの場合、 placement constraints を使用すると、 timing constraintsを実現することが難しくなります。最初の理由は明らかです。 placerの選択肢が限られている場合、制限がない場合よりも結果が悪化する可能性があります。ただし、これにはより具体的な理由があります。

ほとんどの designsでは、 floorplanning を避けて、 placer に logic elementsの配置を最適化する自由を与えるのが最善です。ただし、 placement constraints が一般的に使用される場合があります。たとえば、次のとおりです。

timing closureの目的のために、問題の潜在的な理由として placement constraints を認識することが重要です。特に、 routing delays が予想よりも大きい場合、根本的な原因は、 placerが logic elementsの位置を最適化できないことにある可能性があります。 floorplanning は、配置が制限されている logic elements とは関係のない paths に悪影響を与える可能性があることに注意してください。

アイデア #4: timing constraintsをチェック

timing constraints は、 FPGAの信頼性の高い動作に不可欠です。したがって、プロジェクトの implementation の前に検証する必要があります。ただし、 timing constraints がとにかく間違っている場合があります。 timing closure プロセス中に間違いが明らかになることがあります。これは発生するべきではありませんが、発生した場合は、もちろん問題を修正することをお勧めします。

timing constraintsのチェックに関するページが丸ごとあります。ここでは、 timing closureで問題を引き起こす可能性のある 2 つのよくある間違いについてのみ説明します。

まず、 unrelated clocksについて: clock domain crossings のトピックは、以前に既に議論されています。 timing constraints がどの clocks が related clocks でどの related clocks でないかを反映することが重要である理由はいくつかあります。最も重要な理由は、 logicの適切な動作を確保することですが、 timing closure も影響を受けます。 clocks のペアがツールによって不必要に related clocks として扱われると、これら 2 つの clocksの間で paths に timing 要件が不必要に適用されます。その結果、ツールはこれらの paths に対する労力を無駄にし、本当にこれらの労力を必要とする paths を犠牲にします。

この問題を修正した timing constraint については、この一連のページの後半で説明します。

asynchronous resetsについて： ほとんどの場合、 asynchronous resetで終わる path に timing constraints を適用する必要があります。しかし、場合によっては、これが必要ないこともあります。たとえば、 reset が非アクティブに変化したときに clock がアクティブにならないという保証がある場合。もう 1 つの可能性は、 asynchronous reset を受け取る flip-flop が、 clock domain crossingと同様に、 timing violationsに対する保護メカニズムを備えている場合です。このような状況では、 timing の要件を満たすためのツールの努力は無意味です。

この種の問題が timing closureの達成を困難にしていることを認識するのは難しい場合があります。 critical path は、不必要に related clocksとして扱われる 2 つの clocks とは関係がない場合があります。 asynchronous reset がツールの労力をそらす場合、それを認識するのはさらに困難です。このような状況では、 timing を改善するために critical path に集中しようとしても無駄です。

もちろん、 timing constraints は他のさまざまな点で間違っている可能性があります。ここで説明する状況は、1 つの可能性にすぎません。したがって、 timing の問題は、 timing constraints 全般を見直す良い機会になる可能性があります。

アイデア #5: もう一度お試しください

place and route プロセスは、 logic fabric上で logic elements を任意に分散させることから始まることを思い出してください。その後、ツールは試行を繰り返して timing の改善を試みます。したがって、このプロセスの成功は、ある程度の運に依存しています。論理的な説明がなくても、 place and route アルゴリズムのわずかに異なる動作がより良い結果をもたらす可能性もあります。

したがって、 timing constraints が失敗し、負の slack が比較的小さい場合 (合計 delayの約 10-20% )、再試行するだけで十分な場合があります。しかし、 implementation を再実行するだけでは、おそらく何の役にも立ちません。 ほとんどの FPGA ソフトウェアは、同じ inputで実行した場合に結果を正確に繰り返すように設計されています。したがって、再実行する前に何かを変更する必要があります。この変更は、 critical pathに関連している必要はありません。ポイントは、以前の implementationの正確な繰り返しを回避することだけです。

たとえば、 Vivado では、各 run に「strategy」と呼ばれる attribute があります。名前が示すように、この attribute は、ツールが implementation中に適用する戦略を制御します。この attribute を変更すると、次の implementation が前の implementation と同じにならないことが保証されます。特定の logic designに関連して、別の戦略の方が理にかなっている可能性もあります。

すべての FPGA tools は、 implementation プロセスのパラメータを変更する同様の可能性を提供します。 designの目標を達成するために、より高いレベルの労力を要求することがしばしば可能です。より高い労力が本当に必要な場合もありますが、多くの場合、より高いレベルの労力を要求することは、ツールが他のことを行うという理由だけで役立ちます。

繰り返しを避けるもう 1 つの方法は、 Verilog コードを変更することです。繰り返しますが、変更は critical pathに関連する必要はありません。以前のものとは十分に異なる implementation を取得するために、 register の名前を変更するだけで十分な場合があります。

この考え方は、極端に言えば次のようになります。 implementation を複数のコンピューターで並行して実行できるため、各 implementation のパラメーターはわずかに異なります。 FPGA の価格が重要な場合、これは理にかなっています。このシナリオでは、 timing constraints がより安価な FPGAで実現されるように、コンピューターを一生懸命働かせる価値があります。

要約すると、この方法は運に大きく依存しています。それに応じて、期待は次のようになります。 再試行は、ツールが timing constraintsを達成できない場合にのみ役立ちます。ただし、可能であれば、他の方法で timing を改善することをお勧めします。

アイデア #6: FPGA はいっぱいですか？

timing constraints の問題は、 FPGAの充填レベルが約 70%に達したときに始まることがよくあります。これが発生する主な理由は 3 つあります。

上記の 3 つの理由のうち、何らかの解決策があるのは 3 番目の理由だけです。 たとえば、どの logic が FPGAの block RAMs および他の同様のリソースを使用するかを手動で決定することが役立つ場合があります。これ以外では、フルサイズの FPGA に対する唯一の解決策は、より大きなものを選択することです。ただし、これは常にオプションであるとは限りません。したがって、 logic が追加されるにつれて、 timing closure がより難しくなることを予測することが重要です。

アイデア #7: たぶん、別の FPGAが必要ですか?

時には、 FPGA がその役割を果たしていないことを認めざるを得ないこともあります。上位の speed gradeで同じ FPGA を使用できる場合、解決策は、より高速な FPGAにアップグレードすることです。もちろん、この決定は購入コストを増加させますが、別の予想外の結果をもたらす可能性もあります。 上位の speed gradeで FPGAs が不足する可能性があります。これらのより高速な FPGAs が特定の時期に豊富にある場合でも、通常、需要が供給を上回ったときに、より高速な FPGAs が最初に市場から姿を消します。

これは非常に自然です。 より高速な FPGAs はテストに合格したものであり、低速の FPGAsの代わりにいつでも使用できます。メーカーがより高速な FPGAsの製造に失敗することもあれば、動作可能なすべてのものを購入する大規模な消費者が存在することもあります。

そのため、生産を目的とした製品を長期間にわたって使用する場合は、 design が動作する最も低い speed grade を優先してください。これは、お金が問題ではない場合でも当てはまります。

まったく異なるタイプのアップグレードは、最新の FPGA ファミリから FPGA を選択することです。または、別のベンダーの FPGA を選択することもできます。この変更はより劇的ですが、プロジェクトが初期段階にある場合は考慮する必要があります。私たちは皆、使い慣れたツールやコンポーネントに恋をする傾向があります。しかし、すべてが慣れすぎていると感じたら、代替案を探す良い機会です.

とはいえ、経験豊富な FPGA engineers ユーザーは、最新の FPGA とそのツールを選択するのは危険な賭けであることを知っています。しかし、現在の FPGAの選択よりもはるかに優れた、確立された代替品が存在することがよくあります。このような状況では、快適な領域を離れて新しいものを試す方がよいでしょう。

アイデア #8: 温度範囲を下げる

この可能性をほぼ最後に置いたのには理由があります。 これは、それらすべての中で最も醜い解決策です。しかし、他に選択肢がない場合もあります。

デフォルトでは、ツールによる timing constraints の強制により、 FPGA が datasheetで定義されている温度範囲全体で確実に動作することが保証されます。一部の FPGA tools では、プロジェクトに別の温度範囲を選択できます (たとえば、 Quartus にはこの目的のために「MAX_CORE_JUNCTION_TEMP」と呼ばれる attribute があります)。これを使用して、完全な温度範囲をサポートする必要がないことをツールに通知できます。

一般的に言えば、 FPGAs の logic elements の delays は、温度が上昇するにつれて増加します。最大温度が低下すると、 timing の計算で delays の値が小さくなります。これにより、ツールが tsetup 要件を達成しやすくなります。ツールで timing constraintsを実現するには、これが唯一の方法である場合があります。

この方法を使用するリスクを理解することが重要です。特に、 junction temperatureについて話していることに注意してください。つまり、これは FPGAの silicon の温度です。これは周囲温度ではありません。

したがって、最高温度が 85°Cであっても、 FPGA がその温度のオーブンで動作するという意味ではありません。この温度は、特に FPGAに heatsink がない場合、室温 (25°C) でも到達できます。 junction の温度と周囲温度には常に差があります。この差の大きさは、 FPGA と冷却ソリューションの消費電力に依存します。

商用製品で作業する場合は、 FPGA の周囲温度が室温よりもかなり高くなる可能性があることに注意してください。特に、 FPGA が空気の流れの悪いボックス内にある場合、ボックス内の温度がボックス外の温度よりもはるかに高くなる可能性があります。さらに悪いことに、ほとんどの電子製品は、 0°C と 40°C の間の温度で動作することが期待されています (おおよそ、これらの数値は製品によって異なります)。最終製品が最高温度でテストされ、 FPGA が製品の筐体内にある場合、 junctionの温度は?それが質問です。 timing の計算は、その温度 (またはそれ以上) に基づいている必要があります。

つまり、 timing constraints を達成するために最高温度を下げて、ラボですべてが正常に機能する場合、それは何の意味もありません。 timing constraintsに関して言えば、 FPGA design がラボで機能することは常に意味がないことを思い出してください。しかし、最高温度を下げることは、この点でさらに悪いことです。むやみに温度範囲を狭めることは、実際の問題を招きかねません。 最高温度で行われる生産前の製品最終テストが失敗する可能性があり、温度範囲を修正すると timing constraints を実現できなくなります。この問題を解決するには、 FPGA design を最初から書き直すしかありません。

したがって、 timing closureのために温度範囲を変更する前に、安全であることを確認してください。 考えられるすべての作業条件で、 junction の温度範囲を厳密に評価してください。

implementationのパラメータを変更することによって、デフォルトを超えて温度範囲を拡張することは不可能であることに注意してください。ツールのデフォルトの温度範囲は、 datasheetに記載されているものと常に同じです。したがって、このデフォルトの温度範囲を超えて FPGA の信頼できる動作を保証することはできません。

アイデア 9: アラインされていない related clocks

これはかなり難解な状況であり、理解するのも少し難しいです。そのため、このトピックを最後に置きました。

位置合わせされていない 2 つの related clocks の間に clock domain crossing があるとします。つまり、2 つの clocks は同じ reference clockから派生していますが、これらの clocksの間に clock skew を制御するメカニズムはありません。

その結果、ツールがこれら 2 つの clocksの間で paths の timing 要件を満たすことがより困難になります。次の 2 種類の困難が考えられます。 ( tsetup と thold は以前に説明したことを思い出してください)

これらの問題を克服するためにツールが通常よりもハードに動作する必要がある場合、他の pathsの最適化が犠牲になる可能性があることに注意することが重要です。

しかし、アラインされていない related clocks はエラーではなく、避けられない場合もあります。この状況は、ツールがより多くの作業を行う必要があることを意味するだけです。 timing constraints を達成していれば、 designでも問題ありません。ただし、これは合理的な努力で可能な限り回避する必要があります。

上記の「アイデア #5」で言及されている間違いは異なることに注意してください。ただし、どちらの間違いもツールにとって不必要に困難であり、両方とも clock domain crossingに関連しています。

related clocks がアライメントされていない状況を解決する最善の解決策は、これらの clocksをアライメントすることです。これは通常、 PLL を追加するか、既存の PLLに clock output を追加することによって行われます。目標は、問題の両方の clocks が同じ PLLの outputs であることです。

別の可能な解決策は、 clocks を unrelated clocksとして扱うことです。これには、 timing constraintsの変更だけでなく、 logic design 自体の変更も必要です。これがそれほど難しくない場合は、努力する価値があるかもしれません。このトピックについては後で詳しく説明します。

ここで、アラインされていない related clocks 間の clock domain crossing の例を見ていきます。

wire       pll_clk;

   reg [24:0] result;
   reg [11:0] x, y, x1, y1;

   clk_wiz_0 pll_i
   (.clk_in1(clk),
    .clk_out1(pll_clk));

   always @(posedge clk)
     begin
	x1 <= x;
	y1 <= y;
     end

   always @(posedge pll_clk)
     result <= x1 * y1;

PLL (clk_wiz_0) があることに注意してください。この PLL は、 250 MHzの周波数を持つ reference clockとして @clk を使用します。前のページの上部の例で示した PLL と同じです。 @pll_clk の周波数は 125 MHzです。

この例の重要な部分は、2 つの related clocks (@clk と @pll_clk) の間の clock domain crossing です。 PLLによって生成されるのは @pll_clk のみであるため、これら 2 つの clocks は整列していません。したがって、 paths から @result ( @x1 および @y1から) には clock skew があります。この clock skewにもかかわらず、 clocks は依然として related clocksであり、ツールは timing の要件を満たそうとします。

@clk を使用する唯一の理由が 250 MHz 周波数の clock の必要性である場合、正しい解決策は PLLで別の clock を生成することです。 reference clockと同じ周波数の clock を製造することは、リソースの無駄ではありません。それどころか、これを行うと、ツールの労力が大幅に節約されます。例に示すように、 @clk を直接使用する正当な理由は 1 つだけです。 PLL が使用可能な clocksを生成する前に、 @clk を使用する logic が動作する必要がある場合。

Vivado で生成された timing report は次のとおりです。この特定のケースでは、 tsetup 要件に問題があっただけです。

Slack (VIOLATED) :        -1.456ns  (required time - arrival time)
  Source:                 x1_reg[7]/C
                            (rising edge-triggered cell FDRE clocked by clk  {rise@0.000ns fall@2.000ns period=4.000ns})
  Destination:            result_reg/DSP_OUTPUT_INST/ALU_OUT[10]
                            (rising edge-triggered cell DSP_OUTPUT clocked by clk_out1_clk_wiz_0  {rise@0.000ns fall@4.000ns period=8.000ns})
  Path Group:             clk_out1_clk_wiz_0
  Path Type:              Setup (Max at Slow Process Corner)
  Requirement:            4.000ns  (clk_out1_clk_wiz_0 rise@8.000ns - clk rise@4.000ns)
  Data Path Delay:        3.012ns  (logic 2.677ns (88.878%)  route 0.335ns (11.122%))
  Logic Levels:           5  (DSP_A_B_DATA=1 DSP_ALU=1 DSP_M_DATA=1 DSP_MULTIPLIER=1 DSP_PREADD_DATA=1)
  Clock Path Skew:        -2.192ns (DCD - SCD + CPR)
    Destination Clock Delay (DCD):    0.998ns = ( 8.998 - 8.000 )
    Source Clock Delay      (SCD):    3.202ns = ( 7.202 - 4.000 )
    Clock Pessimism Removal (CPR):    0.012ns
  Clock Uncertainty:      0.148ns  ((TSJ^2 + DJ^2)^1/2) / 2 + PE
    Total System Jitter     (TSJ):    0.071ns
    Discrete Jitter          (DJ):    0.103ns
    Phase Error              (PE):    0.086ns
  Clock Net Delay (Source):      1.414ns (routing 0.002ns, distribution 1.412ns)
  Clock Net Delay (Destination): 1.184ns (routing 0.002ns, distribution 1.182ns)
  Clock Domain Crossing:  Inter clock paths are considered valid unless explicitly excluded by timing constraints such as set_clock_groups or set_false_path.

    Location             Delay type                Incr(ns)  Path(ns)    Netlist Resource(s)
  -------------------------------------------------------------------    -------------------
                         (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.738     4.738 r  clk_IBUF_inst/INBUF_INST/O
                         net (fo=1, routed)           0.105     4.843    clk_IBUF_inst/OUT
    AG12                 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O)
                                                      0.049     4.892 r  clk_IBUF_inst/IBUFCTRL_INST/O
                         net (fo=1, routed)           0.795     5.687    clk_IBUF
    BUFGCE_X1Y2          BUFGCE (Prop_BUFCE_BUFGCE_I_O)
                                                      0.101     5.788 r  clk_IBUF_BUFG_inst/O
    X2Y0 (CLOCK_ROOT)    net (fo=62, routed)          1.414     7.202    clk_IBUF_BUFGCE
    SLICE_X52Y45         FDRE                                         r  x1_reg[7]/C
  -------------------------------------------------------------------    -------------------
    SLICE_X52Y45         FDRE (Prop_HFF_SLICEM_C_Q)
                                                      0.138     7.340 f  x1_reg[7]/Q
                         net (fo=1, routed)           0.335     7.675    result_reg/A[7]
    DSP48E2_X8Y18        DSP_A_B_DATA (Prop_DSP_A_B_DATA_DSP48E2_A[7]_A2_DATA[7])
                                                      0.396     8.071 r  result_reg/DSP_A_B_DATA_INST/A2_DATA[7]
                         net (fo=1, routed)           0.000     8.071    result_reg/DSP_A_B_DATA.A2_DATA<7>
    DSP48E2_X8Y18        DSP_PREADD_DATA (Prop_DSP_PREADD_DATA_DSP48E2_A2_DATA[7]_A2A1[7])
                                                      0.182     8.253 r  result_reg/DSP_PREADD_DATA_INST/A2A1[7]
                         net (fo=1, routed)           0.000     8.253    result_reg/DSP_PREADD_DATA.A2A1<7>
    DSP48E2_X8Y18        DSP_MULTIPLIER (Prop_DSP_MULTIPLIER_DSP48E2_A2A1[7]_U[10])
                                                      0.994     9.247 f  result_reg/DSP_MULTIPLIER_INST/U[10]
                         net (fo=1, routed)           0.000     9.247    result_reg/DSP_MULTIPLIER.U<10>
    DSP48E2_X8Y18        DSP_M_DATA (Prop_DSP_M_DATA_DSP48E2_U[10]_U_DATA[10])
                                                      0.164     9.411 r  result_reg/DSP_M_DATA_INST/U_DATA[10]
                         net (fo=1, routed)           0.000     9.411    result_reg/DSP_M_DATA.U_DATA<10>
    DSP48E2_X8Y18        DSP_ALU (Prop_DSP_ALU_DSP48E2_U_DATA[10]_ALU_OUT[10])
                                                      0.803    10.214 r  result_reg/DSP_ALU_INST/ALU_OUT[10]
                         net (fo=1, routed)           0.000    10.214    result_reg/DSP_ALU.ALU_OUT<10>
    DSP48E2_X8Y18        DSP_OUTPUT                                   r  result_reg/DSP_OUTPUT_INST/ALU_OUT[10]
  -------------------------------------------------------------------    -------------------

                         (clock clk_out1_clk_wiz_0 rise edge)
                                                      8.000     8.000 r
    BUFGCE_X1Y2          BUFGCE                       0.000     8.000 r  clk_IBUF_BUFG_inst/O
                         net (fo=62, routed)          1.078     9.078    pll_i/inst/clk_in1
    MMCME3_ADV_X1Y0      MMCME3_ADV (Prop_MMCME3_ADV_CLKIN1_CLKOUT0)
                                                     -1.777     7.301 r  pll_i/inst/mmcme3_adv_inst/CLKOUT0
                         net (fo=1, routed)           0.422     7.723    pll_i/inst/clk_out1_clk_wiz_0
    BUFGCE_X1Y0          BUFGCE (Prop_BUFCE_BUFGCE_I_O)
                                                      0.091     7.814 r  pll_i/inst/clkout1_buf/O
    X2Y0 (CLOCK_ROOT)    net (fo=6, routed)           1.184     8.998    result_reg/CLK
    DSP48E2_X8Y18        DSP_OUTPUT                                   r  result_reg/DSP_OUTPUT_INST/CLK
                         clock pessimism              0.012     9.010
                         clock uncertainty           -0.148     8.862
    DSP48E2_X8Y18        DSP_OUTPUT (Setup_DSP_OUTPUT_DSP48E2_CLK_ALU_OUT[10])
                                                     -0.104     8.758    result_reg/DSP_OUTPUT_INST
  -------------------------------------------------------------------
                         required time                          8.758
                         arrival time                         -10.214
  -------------------------------------------------------------------
                         slack                                 -1.456

この report は、ツールが timing constraintsを達成できなかったことを示しています。表示されている path は、 4 nsの @clkの rising edge から始まり、 8 nsの @pll_clkの rising edge で終わります。問題は、 input pin の clock が最初の flip-flopの clock input pinに到達するのにかかる時間です。 3.2 ns.したがって、この clock edge の到着時刻は 7.2 nsです。

しかし、 @pll_clk は PLLによって生成されるため、この clock は @clkの input pinに合わせられます。したがって、 delay は 1.0 nsのみです。したがって、 @pll_clkの 2 番目の flip-flop への到着時間は 9.0 nsです。したがって、 data path に残された時間は 9.0 – 7.2 = 1.8 ns です (およそ、 clock uncertainty などのため)。これは、指定された演算ユニットが使用されている場合でも、算術乗算には十分ではありません。したがって、 timing の要件を満たすことができませんでした。

したがって、この例では、 clock skewが原因で、 clock が最初の flip-flop に遅れて到着します。これにより、 tsetup 要件を満たすことができなくなります。

これは、 @pll_clkの配置を操作することで解決できることに注意してください。たとえば、 PLLの reference clock は、 @clkを配布する global clock buffer の output にすることができます。より良いアライメントを実現するために、 PLL の phase shift を定義することも可能です。ただし、これらは最後の手段としてのみ使用するソリューションです。

概要

繰り返しますが、これらは timing closure の問題を解決するのに役立つかもしれないアイデアのほんの一部です。残念ながら、この種の問題を解決するには、それ以上のことが必要になる場合があります。実際、 FPGAs の分野で timing closureに関係のないトピックは 1 つもありません。

すでに述べたように、最善の戦略は logic design を最初から注意深く書くことです。 timing closure に取り組む最善の方法は、それを避けることです。

この時点まで、この一連のページでは timingについて説明してきましたが、 timing constraintsについてはあまり説明しませんでした。これは変わろうとしています:次のページから、議論はより技術的なものになります。

このページは英語から自動翻訳されています。 不明な点は元のページを参照してください。
Copyright © 2021-2024. All rights reserved. (b4b9813f)