01signal.com

timing constraints が正しいことの検証

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

このページは、 timingに関する一連のページの最後のページです。前のページでは、 timing 計算の背後にある理論を説明し、いくつかの timing constraints を記述する方法を示し、 timing closureの原理について説明しました。

序章

多くの場合、 FPGA 開発の戦術は、機能を追加し、機能しないものを修正し、繰り返すことです。 design の間違っている可能性のある部分を無視するのは簡単ですが、目に見える問題はありません。

timing constraints が正しく適用されていない場合や、達成されていない場合でも、 FPGA design は完全に正常に動作する可能性があることを理解することが重要です。 timing constraints を適切に使用することは、 FPGAを安定して正しく動作させるための重要な要素の 1 つです。それでも、このトピックを無視しても、すぐに失敗するわけではありません。むしろ、不適切な timing は、非常に混乱を招く可能性のある時折の誤動作につながる可能性があります。

このページでは、 timing constraintsに関するこの一連のページからの提案の多くを要約し、繰り返します。この目的は、不適切な timingの結果である問題を探す際に留意すべきいくつかのトピックを強調することです。時折、これらのトピックについて調べてみる知恵が欲しいと思う人もいるかもしれませんが、実際にはほとんどの人がこれを行って、魔法のように見える問題を解決しています。

timing reportを読む

すべての FPGA design ツールは timing reportsを出力します。それらを開く最も一般的な理由は、ツールが timing constraintsを達成できない場合です。 ここで、失敗した pathsを見つけて、うまくいけば、それらに対して何ができるかを見つけ出すことができます。

ただし、 timing reportsを調べる重要な理由があります。 timing constraints がツールによって意図したとおりに解釈され、適切に適用されていることを確認します。特に新しい timing constraintsを追加した後は、このチェックを時々行うことをお勧めします。

各 FPGA design ツールはこれらのレポートをさまざまな構造と形式で生成するため、各レポートの各部分が何を示しているかを正確に関連付けることは不可能です。したがって、このページでは、すべてのツールに共通する原則を概説します。自分の timing reportsのフォーマットと機能については、時間を取って学習することをお勧めします。

timing report チェックのもう 1 つの利点は、 logicの誤った使用法が明らかになる可能性があることです。たとえば、 design に誤って使用された非同期 logic が含まれている場合、または timing constraints を適用できない clocks に依存している場合、これは timing reportで明らかになる可能性があります。 この logic に timing constraints を適用することは不可能であるため、 unconstrained pathsとしてレポートに表示される場合があります。

別の注意として、 design に含まれる IPs は、多くの場合、独自の timing constraints に貢献し、ツールが提供するものの上に追加することに言及する価値があります。通常、これらの constraintsに関連する paths をチェックする意味はありませんが、 timing reportにかなりの重みを加えることができます。

Unconstrained internal paths

この説明のために、 synchronous element は flip-flop、 block RAM、 shift register 、または data input をサンプリングし、 clockの rising edge または falling edge で data output を変更するその他の logic elements です。

synchronous elementの data output から別の synchronous elementの data input に移動するすべての paths は、タイミングを合わせる必要があります。つまり、 timing constraintsに従います。唯一の例外は、 unrelated clock domainsの場合のように、 timing violation の可能性が宛先の synchronous elementで適切に処理される場合です。

つまり、 path から任意の synchronous element へのタイミングは、 design ツールが予測可能な方法で input signal をサンプリングする責任を負わないという事実を隠蔽するための明示的な resynchronization メカニズムがない限り、時間を計る必要があります。

reference clockを定義する単一行の timing constraintで十分な場合があり、残りは FPGA tools が処理します。それ以外の場合は、それ以上のものが必要です。非常に悪いケースでは、一部の内部 paths が誤って unconstrained のままになっています。これにはいくつかの理由が考えられます。

FPGA design ツールは、 timing constraint が適用されていない paths である unconstrained pathsをリストする timing reports の作成をサポートします。原則として、このリストは空にする必要があります。 constraints を必要としない paths は、 timing constraint ファイルで false paths として明示的に定義する必要があります。このような constraints は、 paths のように機能的に何も変更せず、いずれにせよタイミングを合わせていませんが、 timing report 内の unconstrained paths のリストを空のままにしておくことができます。これにより、意図せず除外された paths を簡単に見つけることができます。さらに、このリストの paths の数は限られているため、このリストに絶対に含まれてはならない paths が非表示になる可能性があります。代わりに無害な paths がリストされます。

しかし残念なことに、一部の timing reportsでは、 unconstrained paths のセクションに、 timing constraintsでカバーする理由のない paths も含まれる場合があります。たとえば、 clock buffer の output から別の別の clock resourceの input への path 。その結果、 timing report は paths のすべてを unconstrainedとしてリストする場合がありますが、それでもまったく問題ありません。これにより、 timing reportから状況を推測するのが少し難しくなりますが、このような paths は通常、 flip-flopの data input または他の synchronous elementで終わる paths とは別にリストされているため、これは実際には問題ではありません。したがって、レポートを注意深く読み、リストされている paths の各グループが何を意味するのかに注意を払う必要があります。

デフォルトで作成される timing report は、この情報を含むほど詳細でない場合があります。適切な FPGA design ツールを使用すると、 unconstrained pathsを一覧表示するオンデマンド timing report を作成し、各グループにそのような paths をいくつ一覧表示するかを選択できます (関連する一覧が完全に空であっても、10 は妥当な数です)。

clock domainsの間のPaths

Timing constraints は、 clocks が related clocks である場合 (より正確には、 logic がそれらを関連するものとして扱う場合)、ソースと宛先で異なる clocks と同期している内部 paths で使用する必要があります。そうしないと、この不必要な制限によって高品質の routing resources が無駄になり、 timingの達成に失敗する可能性があるため、そうすべきではありません。 related clocks と unrelated clocksについては、このページを参照してください。

各ツールセットには、 clocks のペアを関連すると見なすかどうかを自動的に決定する独自の方法があります。 timing constraint ファイル (例: Vivado および Quartus) で SDC 構文を使用するツールには、 related clocks および unrelated clocksのグループを定義できるset_clock_groups コマンドがあります。特に false path timing constraintsのおかげで、この問題に関してツールを導く他の方法もあります。

問題は、ツールが clocks を related clocks と見なすかどうかを確認する方法です。残念ながら、ツールセットごとに方法が異なります。たとえば、 Vivadoには Clock Interaction Reportがあり、 clocksの各ペアの状況を示すカラー ダイアグラムがあります。

または、 paths の特定のグループに限定されたカスタム timing reports を使用して、この問題を調査することもできます。 paths は、関連する clocks に従って選択できます。これは、1 つの clockと同期している logic elements で開始し、別の clockで終了する pathsを選択することによって実行できます。 clock domain クロッシングに関与することが知られている paths のグループを具体的に調べることも有益かもしれません。

難しいかもしれませんが、ツールがどの clock domain crossings に constraints を適用し、それらが正しいかどうかを総合的に確認することが重要です。同時に、 logic design に必要な場所に resynchronization logic があるかどうかを確認する機会でもあります。各 signalでどの clock が使用されているかについて混乱するため、安全でない clock domain crossing になってしまうのは簡単です。

各 clockの性質を念頭に置いてこのレビューを行うことが重要です。たとえば、異なる oscillators からの 2 つの clocks が同じ意図された周波数を持ち、したがって timing constraints ファイルで同様の定義を持っている場合、ツールはそれらを関連していると誤って見なし、これらの clocksの間を横切る paths で timing を計算する可能性があります。このような paths に constraints を適用しても意味がありません。2 つの clocks間の phase の関係には何の保証もありません。不要な timing constraints 自体は、ツールが timingを達成するのを難しくするだけであり、これはほとんど無害です。本当の問題は、 timing report によって、 clocks が実際には related clocksであると誤解される可能性があることです。したがって、 constraints と timing reportsを見るだけで、それらの間の paths は安全 (つまり、 timing 違反に対する保護を必要としない) に見えるかもしれませんが、実際にはそうではありません: 2 つの clocks には、周波数がほぼ同じであることを除けば、共通点はありません。この種の間違いを避ける唯一の方法は、各 clock がどのように生成されるかを理解することです。

Unconstrained external paths

Timing constraints は、 I/O pins で開始するか、 I/O pinsで終了する paths に常に適用する必要があります。これを行う方法を説明する別のページがあります。唯一の例外は、 FPGAのシリコン上の hardware processor に直接接続されている gigabit transceivers、 pins など、特別なインターフェイスを備えた clock input pins と pins です。インターフェイスが非常に遅い場合は、 timing constraints が定義されていなくても問題ありません。たとえば、 LEDs、押しボタン、さらには I2C ワイヤを使用します。しかし、 timing reportで unconstrained I/O pins のリストを空のままにしておくため、そのような pinsには false path constraints を割り当てる方がはるかに優れています。

多くの場合、 external pathsに timing constraints を適用することは無意味に思えるかもしれません。たとえば、すべてが同じ clockと同期している複数の output pins があり、それらがすべて同時にトグルするという事実によって正しい timing が保証される場合。この同時トグルを実装する一般的な方法は、 IOB registerを使用することです。この flip-flop は、可能な限り最高の clock-to-output を提供し、 output pinsの間で非常に低い skew も提供します。

ただし、これは output pins 上の timing constraints が重要な場合の良い例です。 timing constraints をタイトに保つことで、これらの pins の間の低い skew が保証されます。 IOB register が使用されている場合、タイトな timing constraints は、ツールがこの flip-flopを使用するように強制する方法である可能性があります。または、ツールが使用に失敗した場合に見過ごされないようにすることもできます。 ツールが flip-flop を希望どおりに配置しない場合、 timing は失敗します。

同様の理由で、 input pins 上のタイトな timing constraints も適用する必要があります。

いくつかの pinsの間で skew を低く抑えるために timing constraints を使用する場合、報告された slack がほぼゼロになるまで I/O pins を制約するだけでなく、より厳密な timing を要求すると constraintの達成に失敗することを確認することが重要です。これは、 I/O signal path にオプションの delay linesが含まれている可能性があり、ツールが直感に反してそれを利用する可能性があるためです。たとえば、 Intel FPGAの Quartus は、 timing budget の余剰がある場合、 input path に delayを追加する場合があります。これを行うためのツールの選択は、望ましくも予想もされない場合があります。

不適切な false paths およびそれ以外の場合は relaxed timing

timing constraints が適用されることもありますが、許容範囲が広すぎます。関連する paths のタイミングが間違っているだけなので、これを検出するのははるかに困難です。

とりわけ、この種の事故にはいくつかの理由が考えられます。

この種の問題を特定する簡単な方法はありません。 timing report を上から下まで注意深く読むことは間違いなく良い考えですが、レポートに各グループに 10 個の paths が表示されていても、問題のある paths がたまたまそこに表示されるという保証はありません。または、表示されている任意の数の pathsの中で、さらに言えば。

これに取り組む別の方法は、書かれている timing constraints をレビューすることです。 SDC constraints は Tclで記述されているため、 constraints ファイル内の logic elements (「from」と「to」) を選択する式を Tcl 式として評価し、エンドポイントのリストを読み取ることができます。

たとえば、次の行が Vivado .xdc ファイルにあるとします。

set_false_path -to [ get_pins -hier -filter {name =~ */pclk_i1_bufgctrl.pclk_i1/S*} ]

implemented design を開いて、 false paths が適用される宛先を一覧表示できます。

puts [join [ get_pins -hier -filter {name =~ */pclk_i1_bufgctrl.pclk_i1/S*} ] "\n" ]

Tcl コマンド "puts" および "join" は、各 element が別々の行にリストされることを確認するため、出力 (非常に長くなる可能性があります) を簡単に読み取ることができます。

このような constraints のレビューは重要ですが、やはり頭脳が必要なため難しいものです。

概要

ツールがさまざまな paths に正しい timing 制限を適用していることを確認するのは、注意が必要な作業です。 timing constraint ステートメントが正確に何を意味するのかを知ることと、 timing reportsをチェックする方法を知ることを組み合わせて、間違いを発見する可能性を高めます。

しかし何よりも、特に問題なく動作しているように見える場合に、 designをチェックおよび再チェックする自己規律を持つことが重要です。

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