このページは、 timingに関する一連のページの最初のページです。
報酬は心の平和
timing、特に timing constraints のトピックは、 FPGA designerにとって大きな課題です。 timing が理解しにくいというだけではありません。本当の課題は、 FPGA designで作業している間、このトピック全体を無視したくなる誘惑に打ち勝つことです。なぜなら、すべてが適切に機能するからです。目に見える問題がないのに、 design に満足しているという罠に陥りがちです。
FPGA designers が、 timingに関して design が不足していることを認識していると言うのを聞くのは珍しいことではありませんが、それとは別に、電子機器は時計仕掛けのように機能します。実際、 timing が適切に行われていることを確認することは、その時点では時間の無駄に思えるかもしれません。新しい機能の開発を続けたいと熱望しているマネージャーは、プロジェクトに明確な進展が見られない数週間に満足することはまずありません。実際、 designの timing を適切に検査すると、解決が困難な問題を発見できる場合があります。側から見ると、これは存在しない問題を発明し、それらを解決するために貴重な時間を浪費しているように見えるかもしれません。
真実は、多くの場合、 timing を無視する戦略が短期間で報われるということです。しかし、多くの場合、このトピックに適切に注意を払わないと、最も厄介な問題が発生し、最も厄介な瞬間に発生する傾向があります.たとえば、システムが全温度範囲でテストされている場合など、最終受け入れテスト中に電子機器が数時間に 1 回故障することがあります。またはそれよりもさらに悪い： お客様からのクレームは、商品が発売されてから数年後に届き始めます。これらの苦情の理由を突き止めるための必死の努力の結果、これらの製品の FPGAs は別のバッチで製造されたことが判明しました。したがって、すべての FPGAs が datasheetの要件を満たしている場合でも、シリコンの違いにより、新しい FPGAs の動作はわずかに異なります。
FPGAs は、この種の事件が原因で悪評を得ています。ただし、 timing が適切に処理されている場合、この種のことは起こらないと確信できます。 design が正しく行われた場合、 FPGAs は非常に信頼性が高くなります。
ですから、 timingのトピックについて時間をかけて学び、常にこの知識を十分に活用してください。これを行うことで、何かを変更した場合に design に予期せぬ事態が発生するという絶え間ない恐怖から解放されます。また、現れたり消えたりする bugs の果てしない追跡から解放されます。そして何よりも、 FPGA を信頼できる堅牢なコンポーネントとして考えることに慣れるでしょう。
timing constraintsの重要性
FPGA の logic は、 FPGA designのすべての synchronous element で timing の要件が満たされている場合にのみ、確実に動作します。これを確認するには、考えられるすべての paths を調べる必要があります。単純な logic designでも、これらすべての計算を手作業で行うことは不可能です。
したがって、すべての timing 要件が満たされていることを確認するのは、ツールの義務です。これを可能にするには、必要な計算を行うために必要なすべての情報をツールが受け取っている必要があります。たとえば、ツールはすべての clocks の周波数と、 timingに関して外部コンポーネントがどのように動作するかを知る必要があります。この情報は、通常、特殊な構文を持つテキスト ファイルで構成される timing constraintsのツールに提供されます。
timing constraints が正しく書かれていない場合、または必要なすべての情報が網羅されていない場合、ツールは logic designの信頼できる動作を保証する方法がありません。ツールは、 timing constraintsで提供される情報に依存しているため、この情報が正しくないか部分的である場合、ツールが行う timing の計算も同様です。 timing constraints の不適切な記述は、 FPGAの信頼性の低い動作の一般的な理由です。
したがって、ツールとの書面による合意は次のようになります。 timingについて知っておく必要があるすべてのことをツールに伝えると、ツールは designに timing violations がないことを確認します。
しかし、ツールが timing violationsを回避できない場合もあります。その場合、ツールからその旨の警告メッセージが表示されます。これは単なる警告であり、 errorではないため、 FPGA ツールは FPGAにロードできる bitstream ファイルの作成を続行します。したがって、ツールが timing constraints が達成されたことを確認していることを常に確認することが重要です。この確認は通常、「All timing constraints are met」のようなメッセージの形式をとります。
でも timing constraintsだけじゃない
あなたと FPGA ソフトウェアとの間の書面による合意は、実際にはさらに広範囲に及びます。 FPGA design がどのように見えるべきかについて、いくつかのルールに従います。ツールは、 FPGA が失敗しないことを確認します。しかし、ルールを破ると、ツールが報復します。
timing を正しく使用することは、これらのルールの重要な部分です。そして、 timing は単に timing constraintsを書くだけの問題ではありません。注意すべき点が 3 つあります。
最初の側面は、 logic design 自体、つまり Verilog (または VHDL) コードです。もちろん、 logic が十分に「高速」であること (より正確には、 logic design は clock が目的の周波数で動作できるようにする必要があること) という明らかな要件があります。それに加えて、他にも注意すべき点がいくつかあります。
- 適切な Verilog (または VHDL) の基本的なルール、特に RTL paradigmに従う必要があります。そうしないと、ツールは、 synthesizer が生成する logic に timing constraints を適用できなくなります。
- clock domain crossings では適切なテクニックが使用されています (詳細はこちら)。
- 混乱を避けるために、 clocks を整理する必要があります。特に、意図しない clock domain crossingsを避けることが重要です。
2 番目の側面は、 timing constraintsを記述することです。この部分は非常に簡単な場合もあれば、慎重な作業が必要な場合もあります。 timing constraints を別の design (特に period constraintの 1 つだけ) からコピーして、作業が完了したと考えるのはよくある間違いです。
3 番目の側面は、 design が確実に機能することを保証するために、ツールが目的を達成したことを確認するために、 timing reports を生成して読み取ることです。 FPGA が内部でどのように動作するかを理解する必要があるため、これが最も難しい部分です。 timing reports は、 FPGAの最小のビルディング ブロックの観点から記述されています。したがって、 FPGAについての十分な理解がなければ、これらのレポートから有用な結論に達することは困難です。
人々は通常、問題を解決するために timing reports を読みます。特に、ツールが timing constraintsの要件を満たせない場合にそうします。このような問題を解決するプロセスは timing closureと呼ばれます。最も一般的な問題は、 clockの周波数が logic design に対して高すぎることです (同様に、 logic が clockに対して遅すぎるとも言えます)。
すでに述べたように、 timing constraints が達成され、すべてが完全に動作する場合でも、 FPGA designの timingを時々調べることを強くお勧めします。これは、特に timing reportsをチェックすることを意味しますが、 timing constraints が logicのニーズを正確に反映していることを確認することも意味します。難しいのは、そのような検査は短期的には報われないということです: この点検には手間がかかり、結果が出ないか、問題が発見されるかのどちらかで終わります。したがって、検査が実りあるものであった場合、それは実際には、誰も見ることができない問題を解決するためのより多くの作業を意味します.
timing に関するこれらのページの構成
これらのページは、あなたと FPGA ツールの間の書面による合意の 2 番目と 3 番目の側面に焦点を当てています。 timing constraints の書き込みと timing reportsの読み取り。これらのスキルには、理論的な知識と実践的なツールが必要です。
timing constraints の実用的な側面は、習得が比較的容易です。難しいのは、それらの正確な意味と designへの影響を理解することです。このシリーズの次のページでは、基本的な理論的概念について説明します。以降のページでは、 timing reportsのいくつかの例の助けを借りて、理論に関する議論が続けられます。全体の話は、 timing analysisの細部にあります。
次のページに続く 2 つのページでは、最も重要で最も有用な timing constraintについて説明します。 period constraint。これらの 2 つのページには、 timing reports が重要であるため、 timing reports に関する詳細な説明が含まれています。
次の 2 ページでは、 timing closureについて説明します。このトピックには少し早いかもしれませんが、以下のトピックの目的を説明しています。 logic fabricに関連する timing constraints ( SDC 構文) に関する 5 ページ。この後に、 I/O timing constraintsに関する 2 つのページが続きます。
このシリーズの最後のページは、既存の designの検査に専念しています。そのページには新しいものは何もありません。むしろ、すでに議論されたトピックを繰り返します。しかし、今回は、調べることのリストとして。
トピックは、この一連のページを最初から最後まで読むことができる順序で表示されます。しかし、すべてのトピックは互いに関連しているため、ページ間で多くの参照があります.
ここから続けるのに最適な場所は、次のページです。 timing の理論を調べてみて損はありません。