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 tools は timing reportsを放出します。これらを開く最も一般的な理由は、ツールが timing constraintsを達成できない場合です。 ここで、失敗した pathsを見つけて、うまくいけば、それらに対して何ができるかを見つけ出すことができます。

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

各 FPGA design tool は異なる構造と形式でこれらの reports を生成するため、各 reports の各部分が何を意味するかを正確に把握することは不可能です。したがって、このページではすべてのツールに共通する原則を概説します。独自の timing reportsの形式と機能については、いずれにしても時間をかけて学習することをお勧めします。

timing report チェックのもう 1 つの利点は、 logicの誤った使用法が明らかになる可能性があることです。たとえば、 design に誤って使用された非同期 logic が含まれている場合、または timing constraints を適用できない clocks に依存している場合、これは timing reportで明らかになる可能性があります。 この logic に timing constraints を適用することは不可能なので、 report に 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で適切に処理される場合です。

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

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

FPGA design tools は、 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 とは別にリストされるのが一般的であるため、これは実際には問題ではありません。したがって、 report を注意深く読み、リストされている paths の各グループの意味に注意を払うことが重要です。

デフォルトで作成される timing report は、この情報を含めるには詳細が不十分な場合があります。適切な FPGA design tool であれば、 unconstrained pathsをリストするオンデマンド timing report を作成し、各グループにリストする paths の数を選択できます (関連するリストは完全に空である必要がありますが、10 が適切な数です)。

clock domainsの間のPaths

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

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

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

あるいは、 paths の特定のグループに限定されたカスタム timing reports を使用してこの問題を調査することもできます。 paths は、関係する clocks に応じて選択できます。これは、 logic elements で始まり、1 つの clockと同期し、別の clockで終了する pathsを選択することで実行できます。また、 clock domain crossingsに関係することがわかっている paths のグループを具体的に調べることも有益です。

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

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

Unconstrained external paths

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

多くの場合、 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 とそれ以外の緩和された timing

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

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

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

これに対処するもう 1 つの方法は、 timing constraints を記述どおりに確認することです。 SDC constraints は Tclで記述されているため、 constraints ファイル内の logic elements (「from」および「to」を含む) を Tcl expressionsとして選択する式を評価し、エンドポイントのリストを読み取ることができます。

たとえば、次の行が 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 commands (「puts」および「join」) は、各要素が別々の行にリストされるようにし、出力 (非常に長くなる場合があります) を簡単に読み取れるようにします。

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

概要

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

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

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