01signal.com

SDC 構文のI/O timing constraints

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

このページは、 timingに関する一連のページに属しています。前のページでは、 timing 計算の背後にある理論を説明し、いくつかの timing constraints を記述する方法を示し、 timing closureの原理について説明しました。前のページでは、 I/O timing constraintsに関するいくつかの基本原則について説明しました。このページでは、このトピックの実際的な側面について説明します。

序章

I/O timing constraints の目的は、外界との信頼できるインターフェイスを確保することです。 それらは、外界からの各 signal が FPGA上の関連する flip-flop に確実に到着することを保証します。同様に、 FPGA から外界への各 signal が外部コンポーネントの flip-flop に確実に到達するようにします。

I/O timing constraints は、 timing constraintsの中で最も難しい種類です。 timing parameters の一部は、 boardの外部電子部品に依存します。通常、正しい timing requirementsを決定するには、これらの外部部品の datasheets を読み取る必要があります。正しい timing constraintを取得するには、多くの場合、ペンと紙による計算が必要です。

この複雑なタスクをスキップして、単純な代替手段を好むのは魅力的です。 試行錯誤。このショートカットは、ツールに必要なことをさせ、それが機能するかどうかを確認することで構成されています。 input portに問題がある場合は、 input signalを受け取る flip-flop で反対の clock edge を使用します。同様に、 output がうまく機能しない場合は、 output flip-flopで反対の clock edge を使用します。この方法では、通常、電子機器がすばやく簡単に機能します。

このアプローチの問題点は、 timing の動作が温度とともに変化することです。また、半導体部品の製造工程による不確実性もあります。これは、 FPGA だけでなく、外部電子機器にも当てはまります。したがって、不適切な timing constraints は「 Black Magic モード」につながる可能性があります。これはすべての timing constraintsに当てはまりますが、 I/O timing constraintsではより多く発生します。

紙とペンでの計算を省略することの最も悪い点は、 board designのせいで timing requirements を保証できないことがあることです。 board designのプロセス中にこのような状況が見つかった場合、多くの場合、簡単な解決策があります ( FPGA への配線を変更するか、 clocksの配布を再検討する)。しかし、 PCB が製造された後にこの種の欠陥が見つかった場合、修正する方法がない可能性があります。つまり、電子機器が確実に動作することを保証できなくなります。

このページの内容

このページでは、 I/O portsの基本的な timing constraints の概要を説明します。ここで示す構文は SDCであり、 Vivado および Quartus、およびその他の FPGA toolsで使用されます。

このページは、 I/O専用の timing constraints から始まります。 set_input_delay と set_output_delay。これらの constraints の意味を説明します。これに続いて、 Vivado および Quartusによる timing reports の例を示す 2 つの別個のページへの参照が続きます。

timing constraints を set_max_delay および set_min_delayで定義することもできます。これらの commands は、いくつかのシナリオではより適しています。 FPGA内の paths に関して、すでにそれらに遭遇しました。 I/O timing constraints としての意味も以下で説明します。

このページでは、これらの I/O timing constraintsに関する技術的な側面のみを説明します。理論的な部分については、 I/O portsに対して false paths を定義する方法も示されている前のページを参照してください。

set_input_delay と set_output_delayの意味

これら2つの commands は、外部コンポーネントとのインターフェースがsystem synchronousの場合に適しています。つまり、

これらの定義は、次の 2 つの条件が満たされている場合にのみ正しいことに注意してください。

これら 2 つの条件は、 clock delays が正しく計算されるようにするために必要です。

また、 -min も -max も使用されていない場合は、 command は 2 つの commandsがあるかのように解釈されることに注意してください。 1 つの command と -min attribute、そして 2 つ目の command と -max attribute。これはおそらく、必要な組み合わせではありません。

これらの commands の定義は少しわかりにくいです: set_input_delay は、 clock edgeの後で data signal がその値をいつ変更できるかを定義します。ただし、 set_output_delay は、 data signal がその値を変更した後にいつ clock edge が許可されるかを定義します。おそらく、これらの定義の背後にある理論的根拠は、 datasheet の数値を timing constraintsで直接使用できるということです。

set_input_delay と set_output_delay commands には、ここでは説明されていないいくつかのオプションがあります。特に、 falling clock edge は時間基準として選択できます。詳細については、ツールのドキュメントを参照してください。

常に min と maxの両方を使用する

timing constraintごとに -min と -max の両方を使用することを主張するのは無意味に思えるかもしれません。例えば、外部コンポーネントの tsetup が 8 nsの場合、これの何が問題になっていますか?

set_output_delay -clock theclk 8 [get_ports test_out]

これにより、 setup time が正しく定義されます。 hold timeに関しては、意図せず –8 nsと定義されています。これにより、 output port は clockの前に値 8 ns を変更できます。しかし、誰が気にしますか？そんなことありえませんよね？

実際、それは可能です。 input pin から clock に基づいて内部 clockを生成するための PLL の使用法については既に説明しました (つまり、 boardで表示される clock )。これにより、 PLL は FPGAの内部 clock を input clockに合わせることができます。 PLL は、 clock distribution networkの delay を補正するために clock をわずかに移動 (shifting) することでこれを行います。

実際、 FPGA tools は、 timing constraintを実現するために、 clock を boardの clockより少し前に移動してもかまいません。 FPGA 内の clock を外部 clockの前に移動すると、外部コンポーネントによって認識される clock-to-output が小さくなります。これは、 FPGA 内の flip-flop が内部 clockと同期しているが、可視 timing は外部 clockに関連しているためです。

ただし、 FPGAの内部 clock が board上の clock よりも古い場合、 FPGAの output は、外部 clockの clock edge の前に変更できます。これにより、これらの outputsを受け取るコンポーネントで hold time 違反が発生する可能性があります。

set_output_delay command が hold time を –8 nsとして定義する場合、 output が clockより前にその値 8 ns を変更するということではありません。ただし、これにより、ツールは thold の要件に違反する方法で内部 clock を移動できます。 set_output_delay を -min と正しく組み合わせると、このような事態は発生しません。

trace delayによる調整

ツールは PCBの trace delay を考慮していないことに注意してください。ツールにはこの情報がありません。したがって、 set_input_delay と set_output_delayの timing 計算を行うとき、この delay はゼロであると仮定します。修正は、 clock-to-output と tsuの datasheetの値に trace delay を追加することです。

clock skew を考慮する必要がある場合もあります。 完璧な PCBでは、 clock は同じ delayを持つすべてのコンポーネントに届きます。実際には、 FPGA と外部コンポーネントの間に clock skew が存在する可能性があります。このような clock skew は、ツールの timing 計算では考慮されません。

したがって、 clock が FPGA よりも早く到着した場合 (外部コンポーネントと比較して)、次の修正が必要です。

同様に、 clock が FPGAに遅れて到着した場合は、次の修正が必要です。

timing report は、ここで概説されている調整に関係なく、ゼロではない clock skew を表示する場合があることに注意してください。ただし、 timing report に表示される clock skew は、 PCBではなく、 FPGA内の clock delays に関連しています。

timing reportsの例

例は次の Verilog codeに基づいています。

module top(
    input test_clk,
    input test_in,
    output reg test_out
);

   reg test_samp;

   always @(posedge test_clk)
     begin
	test_samp <= test_in;
	test_out <= test_samp;
     end
endmodule

@test_clk は input clock、 @test_in は input pin、 @test_out は output pinです。内部 clock を boardの clockと位置合わせするために PLL は使用されないため、重要な clock delayが存在することに注意してください。

timing constraints は次のとおりです。

create_clock -name theclk -period 20 [get_ports test_clk]
set_output_delay -clock theclk -max 8 [get_ports test_out]
set_output_delay -clock theclk -min -3 [get_ports test_out]
set_input_delay -clock theclk -max 4 [get_ports test_in]
set_input_delay -clock theclk -min 2 [get_ports test_in]

timing reports はかなり長いので、別のページに表示されます。

set_max_delay と set_min_delayの使用

外部コンポーネントとのインターフェースがsource synchronousの場合、 set_input_delay と set_output_delay の使用は不自然です。 このような状況には、 set_max_delay と set_min_delay の方が適しています。前のページでは、これら 2 つの commands は、 clock period constraintsの補足または調整 (timing exceptions) としてのみ言及されていました。 paths はすべて内部的なものでした。 これらは sequential elementで始まり、終わりました。これらの commands が I/O timing constraintsとして使用される場合、 path の始まりまたは終わりのいずれかが I/O portになります。この状況で timing analysis はどのように実行されますか?

実のところ、これらの commandsの timing analysis を詳しく調べるのは無意味な場合が多いです。 これらの目的は通常、ツールがほとんど満たせない timing constraints を記述することでツールの動作を制限することです。したがって、これらの timing constraints の数値は、これらの constraints をより厳密にするための繰り返しの試行によって求められます。この方法論では、 timing analysis 自体は重要ではありません。

そうは言っても、 set_max_delay と set_min_delayの背後にある計算を理解することは依然として良い考えです。

timing analysis には次の2 つの部分があることを思い出してください。 最初の部分は source pathです。 clock edge (外部 clock pinで) から、2 番目の flip-flopの data input で更新された有効な値までの時間を計算します。この部分は、次の 3 つの要素の合計です。

  1. clock edge が最初の flip-flop ( clock path) に到達するのにかかる時間
  2. この flip-flop がその値を更新するのにかかる時間
  3. この新しい値が 2 番目の flip-flopに到達するまでにかかる時間

2 番目の部分は destination pathで、 clock edge が 2 番目の flip-flopに到達するのにかかる時間のみで構成されます。この flip-flopの input が ( source pathから) いつ更新されるかは既にわかっているため、必要に応じて tsu または tholdとの時間差を比較できます。

しかし、それは 2 つの sequential elementsについても当てはまりました。片側が I/O portの場合はどうなりますか? timing analysisのために、 port は架空の flip-flopであるかのように扱われます。この flip-flop への clock path delay はゼロです。

通常の状況を考えてみましょう。 clock は、 get_ports に依存する create_clock command で定義されます (ほとんどすべての例で示されています)。 clock path delay がゼロであるということは、この仮想 flip-flopの clock input が clock pinに直接接続されていることを意味します。したがって、 clock pin とこの仮想 flip-flopの間には delay はありません。

この flip-flop のすべての timing parameters はゼロです。 tsu、 thold 、 clock-to-output。これは現実的な電子部品を反映したものではありませんが、 output portと組み合わせて使用する場合、 set_max_delay と set_min_delay に意味を与えます。 portの clock-to-output。例えば：

set_max_delay -to [get_ports test_out] 7
set_min_delay -to [get_ports test_out] 0

これら 2 つの timing constraints では、 @test_outの clock-to-output が 0 ns と 7 nsの間にある必要があります。

理由を説明しましょう： 通常、特定の flip-flops間の paths については、 set_max_delay command は period constraint と類似していることを思い出してください。では、 Destination Clock Pathはどうなるでしょうか。計算は 2 番目の clock edge、つまり 7 nsの時点から始まります。しかし、2 番目の flip-flop に対する clock path delay はゼロであり、この flip-flop の tsu もゼロです。したがって、 Destination Clock Path の計算結果は 7 nsになります。これは、通常どおり計算される Source Pathに許容される最大値です。 Source Clock Path と Data Pathを合わせたものです。要約すると、要件は、最初の clock edgeの後に data output が有効な 7 ns であることです。これは、 output portの clock-to-output の定義とまったく同じです。関連する clock の create_clock command が get_portsに基づいている場合、この clock-to-output は PCBの clock に関連しています。

Vivadoを使用した timing reportsの例を参照してください。

set_output_delay は、外部コンポーネントの tsu または thold に関連していることに注意してください。 set_max_delay は、 FPGAの output portの clock-to-output を定義します。したがって、これら 2 つのオプションの主な違いは、焦点がどこにあるかです。

input portに関して、 set_max_delay と set_min_delay が何を意味するかについての直感的な説明はありません。 Source Path は、 input signalを受信する flip-flop の input pin と data input の間の delay で構成されます。 Destination Clock Path は、 timing constraint commandで指定された時間に開始されます。この時間に clock path delay が追加されます。これらは意味のない計算です ( timing reportsを参照)。外部コンポーネントの clock-to-output に関連する set_input_delayを使用する方が自然です。

set_max_delay および set_min_delay の代わりに作成される timing analysis は、 clock periodに依存しないことに注意してください。したがって、 clockの frequency が変更された場合、ツールがこれらの constraintsを強制する間、同じ数値が使用されます。対照的に、 set_input_delay および set_output_delay の計算は、 clockの frequencyに依存します。

I/O timing constraints が clockの frequency に依存していることは、状況によっては利点にも欠点にもなり得ます。 timing constraints が外部コンポーネントの timing parameters に基づいて記述されている場合 (インターフェイスはsystem synchronous )、 set_input_delay と set_output_delayに依存する方がおそらくよいでしょう。 これらの constraints は、 clockの frequency が変更されても正しいままです。ただし、 timing constraints の目的がツールに特定の選択を強制することである場合 (例: IOB registersを使用する)、 set_max_delay と set_min_delay の方が適している可能性が高くなります。

-datapath_onlyの使用

timing constraint を使用する理由の 1 つは、 FPGA tools が I/O portとの間で可能な限り最小限の delay を達成するためにあらゆる手段を講じることです。これは通常、 IOB registerを使用することを意味します。また、 input port と flip-flop の間に余分な delay を挿入しないようにすることも意味します (ツールは、 thold 要件をより良いマージンで満たすためにこれを行う場合があります)。

timing constraint をこの目的で使用する場合、目標となる特定の delay はありません。ツールが最良の結果を達成する以外のことを行わないようにすることが目的です。 FPGA tools が -datapath_onlyをサポートしている場合は、このオプションで set_max_delay を使用することをお勧めします。これにより、計算から clock delay path が完全に排除されるため、 I/O port と flip-flop の間の delay のみが考慮されます。このようにして、 timing constraintの要件は目的に正確に対応します。 flip-flop と I/O pinの間で delay を制御します。

これは Vivadoの簡単な例です:

set_max_delay -datapath_only -from [get_ports test_in] 2
set_max_delay -datapath_only -from [all_registers] \
   -to [get_ports test_out] 3

しかし、「-from [all_registers]」と書かれた部品の目的は何でしょうか?「-from」がなぜ必要なのでしょうか? 簡単に答えると、 Vivado は「-from」部品のないこの command を受け入れることを拒否したということです。 input portに関して、 command には同様の要件はありませんでした。

datapath_only を搭載した timing reports は、例とともにページの下部にあります。

概要

set_input_delay と set_output_delay は、多くの場合、 I/O timing constraintsの推奨される commands と見なされます。実際、インターフェイスがsystem synchronousの場合、これは通常正しい選択です。他のシナリオでは、代わりに set_max_delay と set_min_delay の使用を検討する価値があるかもしれません。これらは、 I/O portの timingに必要な制限をより適切に反映している可能性があるためです。

このページで、 timingに関するこの一連のページを終了します。しかし、既存の designを検査するのに便利な方法で多くのトピックをまとめた最後のページが 1 つあります。

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