Clock domains、 related clocks 、 unrelated clocks

このページは、 clock domainsに関する 3 つのシリーズの最初のページです。

序章

非常に些細な FPGA designsを除いて、複数の clock が synchronous elements (flip-flops、 block RAMs、 shift registers など) と共に使用されます。ただし、 logic design 内のほとんどの機能ユニットは 1 つの clock に基づいているため、ほとんどの場合、複数の clocks のトピックについて特別な注意を払う必要はありません。ある clock をベースにした logic が、別の clockをベースにした logic に接続されると、事態はさらに難しくなります。この一連のページでは、 designで複数の clocks を操作する方法について説明します。

異なる clocksに依存する logic を接続する場合、最初に答える最も重要な質問は、 resynchronization logic が必要かどうかです。これは、2 つの clocks が related clocks であるかどうかを尋ねることと同じです。このページでは、この質問とその回答方法、およびその他の関連トピックについて説明します。以下の議論の多くは、 timing constraints と、それらを logicの特定の要素に適用する可能性に関連しています。そのため、まず timingについて簡単に要約します。

この一連のページでの議論は、 positive edge triggered flip-flops、つまり clock inputsの rising edges に反応する flip-flops に限定されています。もちろん、他の synchronous elements も存在します。つまり、 clockに基づいて信号をサンプリングして生成する logic elements です。 Shift registers、 block RAMs 、およびその他の多くの機能要素。これらの要素の一部は、 clockの falling edge 、またはその両方に反応する場合があります。ここでの議論では、簡単にするためにこれらすべてを無視します。

また、「X は Yと同期している」という表現を使用して、 synchronous element Xの clock input が clock Yに接続されていることを表現します。したがって、この synchronous element は、この clockでその input (または inputs) をサンプリングし、それで outputs も更新します。

timingの基本について簡単に

これは、 timingの理論の簡単な要約です。より詳しい説明は、別のページにあります。

LUTを介して、ある flip-flop から別の signal path への signal path を示す次の図を検討してください。

この図の LUT (Look-Up Table) は、 combinatorial logicの任意のグループを表します。 I1、 I2、 I3 、または I4 が変更されると、 output Oが propagation delayの量で即座に変更されます。

したがって、 signal path は次のようになります。 @fooとラベル付けされた左側の flip-flopの Q outputは、 input clock、 @clk1で rising edge の後に変更されます。この output は I1に接続されているため、 LUTの output O は少し遅れて変更される可能性があります。これは、 Dである右側の flip-flopの data inputに入ります。 @clk2上の rising edge の後、 flip-flop は D を Q ( @barというラベルが付いています) にコピーします。

しかし、それはそれほど単純ではありません。すべての flip-flops にはタイミング要件があります。 data input (D) は、 @clk2の rising edgeの前に安定した t_su ( setup time) でなければならず、この edgeの後も安定した t_hold ( hold time) のままでなければなりません。

FPGA 内の signal paths の大部分は単一の clockに関連しているため、 @clk1 と @clk2 はまったく同じ clock 信号です ( clock skewは無視します)。このような pathsの場合、これら 2 つのタイミング要件が保証されるかどうかを計算することができます。

たとえば、上の図と t_suのタイミング要件を見てみましょう。 @clk1 の rising edge から、右側の flip-flop の D input が更新されて安定するまでに、どれくらいの時間がかかるかを調べるという考え方です。これは、この pathのすべての遅延の合計です。 @clk1 の rising edge から @foo が更新されるまでの遅延 (「clock to output」) から始まり、右側の flip-flop の D input まですべての遅延が続きます。これには、 LUT の遅延だけでなく、 logic elements (routing delays) 間の配線の遅延も含まれます。

@clk1 と @clk2 は同じ clockであるため、両方の flip-flops で次の rising edge がいつ発生するかがわかります。 これは clock period の 1 つ後のものです (たとえば、 100 MHz clockの場合は 10 ns )。したがって、 pathの総遅延は、 t_suのマージンで、 clock periodよりも低くなければなりません。これが保証できる場合、 t_su が必要とするものを保証します。 右側の flip-flop の D input が、 @clk2の rising edge よりも前に時間マージン (t_su) で安定していること。数値の例については、 timing 理論に関するページを参照してください。

t_holdについても同様の計算を行うことができます。 t_suとは異なり、要件は、右側の flip-flop の D input が、 @clk2の rising edge の後、一定時間 (t_hold) 安定したままであることです。したがって、 clock period は無関係であり、考慮されません ( @clk1 と @clk2 が同じ場合)。重要なのは、次の clock cycleではなく、同じ clock cycleで何が起こるかです。

この種の計算は、 @clk1 の rising edge と @clk2の rising edge の間の時間差を知っているからこそ可能であることに注意してください。特に、 @clk1 と @clk2 が同じ clockである場合、 t_su を計算するために使用されるこの時間差は、その clockの clock period です。ただし、この 2 つの clocks の時差が不明な場合、 t_su と t_holdのどちらも保証できません。

t_su または t_hold の要件は、すべての flip-flopで必要です。これには、もちろん、 FPGA上のすべての flip-flops が含まれますが、外部 devices 上の flip-flops (つまり、 FPGA の output pin から clockで信号をサンプリングする外部 device まで) も含まれます。したがって、システム内の各 flip-flop について、これら 2 つの要件が満たされていることが保証されているかどうかを自問する必要があります。これを保証できない flip-flops については、それにもかかわらず信頼できる動作を保証するメカニズム (つまり resynchronization logic) を確保する必要があります。これは、一言で言えば crossing clock domains のトピックです。

もう一度： timing はいつ保証されますか?

前のセクションで迷子になった場合に備えて、主なポイントは次のとおりです。

FPGA design には、 clocksの周波数について design ツールに通知する timing constraintsが常に含まれていることを思い出してください。この情報に基づいて、ツールは 2 つのタイミング要件 (t_su および t_hold) が満たされています。または、ツールがこれらの要件を達成できない場合、この失敗が報告されます。

前述のとおり、 t_suを保証することが可能です。 path の先頭にある clock の rising edges と、 pathの末尾にある clock の時間差を知っている場合のみ、 t_hold 。 logic design の大部分は、同じ clockと同期している他の registers に依存する registers で構成されているため、これはほとんどの場合に当てはまります。

しかし、2 つの異なる clocks を使用するとどうなるでしょうか? 1 つの clock が pathの先頭で flip-flop に接続され、別の clock が pathの最後で flip-flop に接続されている場合は?言い換えれば、 @clk1 が @clk2と同じでない場合はどうなるでしょうか?タイミング計算を行い、タイミング要件を満たすことはまだ可能ですか?まあ、それは依存します。それが、このページの残りの部分です。

Clock domains および clock domain crossing

clock domain は、特定の clock signalと同期しているすべての synchronous elements (つまり、 flip-flops など) で構成されます。

次の単純な Verilog コード スニペットを検討してください。

reg foo, bar;

always @(posedge clk1)
  foo <= !foo;

always @(posedge clk2)
  bar <= foo;

この例では、 @foo は @clk1と同期しており、 @bar は @clk2によって同期しています。明らかに、 @foo と @bar は (それぞれ @clk1 と @clk2の) 異なる clock domains に属します。

@fooについて心配する必要はありません。 それはそれ自体にのみ依存します。ただし、 @bar は @clk2 と同期しており、 @clk1と同期している @fooに依存しています。では、 @bar はどの registerとしても使用できますか? @bar は常に正当なタイミングで @foo の値を取得するため、その動作は既知で再現可能であると仮定できますか?

この質問に答える前に、ここで起こったことに名前を付けましょう。 clock domain crossingです。 @foo と @bar は、異なる clocksと同期する 2 つの flip-flops として実装されます。したがって、 @foo から @bar への path は、ある clock domain から別の clock domain に移動します。

より一般的には、 clock domain crossing は、1 つの clock domain に属する synchronous element の output が、別の clock domainに属する synchronous element の input で終了する場合を指します。これら 2 つの synchronous elementsの間に combinatorial logic があることがよくあります。

したがって、 @bar が次のように定義されていたとしても、

always @(posedge clk2)
  bar <= !foo || !bar;

ここにはまだ clock domain crossing があります。この場合、上の図に示すように、 @fooで開始し、 logic functionを実装する LUT を経由して @barで終了します。

Related clocks 対 unrelated clocks

related clocks という用語は、 rising edges と falling edges の間の予測可能な時間差を保証する方法で、同じ reference clock から派生した clocks を指します (既知の不正確さと jitterを除く)。

「related clocks」の代わりに「synchronous clocks」という用語がよく使用されます。同様に、「unrelated clocks」の代わりに「asynchronous clocks」が一般的に使用されます。

related clock の一般的な例は、単一の FPGA PLL を使用して複数の clocksを生成する場合で、それらの周波数間の既知の関係があります。このシナリオでは、 FPGA ツールは通常、 clock edges が可能な範囲で整列するように clock buffers を配置します。

たとえば、 reference clock を 2 と 3 で乗算すると、次のようになります。

この例では、 x1 clk、 x2 clk 、および x3 clk は related clocksです。これらの clocks の各ペア間の timing は予測可能です。

一般的なケースでは、 reference clock は、これらの他の clocksのいずれかに関連して unrelated clock です。 reference clockの edges と他の clocks の間の timing は、温度やその他の要因によって変化する場合があります。ただし、 PLL が reference clock と PLLの outputsの間の予測可能なアライメントを保証するように構成されている場合、 reference clock でさえ related clockです。

clocks 間の時間関係の知識により、 clock domains間で行われる paths のタイミング計算が可能になります。たとえば、 x1 clk の domains と x2 clk の間の path のタイミングは、 x2 clk とそれ自体の間の path と同じ要件で計算されます。これは、これら 2 つの clocks 間の最短時間差が、 x2 clkの 2 つの rising edges 間の時間と同じであるためです。

同様に、 x2 clk と x3 clk の間の path を計算できますが、最短の時間差は x1 clkの periodのわずか 6 分の 1 です。したがって、最悪の場合のタイミング要件は、想定される x6 clkの要件に対応します。その理由は、 x2 clk の 2 番目の rising edge と x3 clkの 3 番目の rising edge の間の時間差です。

timing の計算方法の詳細については、このページを参照してください。

したがって、この例のポイントは、一般的にも正しいことを言うことです。 related clocksでは、同じ clock domain内の paths のように、これらの clocksの間の paths に timing constraints を適用することで、タイミングを保証することができます。これは、 FPGA ツールが意図的に clock edges が整列されていることを確認する場合に可能です。例に示されているように、タイミング要件は clocks を個別に個別に設定するよりも厳密であることが多く、場合によってははるかに厳密です。

ただし、2 つの clocks が同じ reference clock から派生したからといって、必ずしもそれらが related clocksになるわけではないことに注意してください。特に、これらの clocks 間の skew が制御されていないか不明な場合 (これは、 design ツールが clock distribution リソースを等しい遅延で明示的に使用していない場合に当てはまります)、 unrelated clocksとして扱う必要があります。

また、 clk x1 でさえ、周波数がまったく同じであっても、必ずしも reference clockと関連しているわけではありません。これらの clocks が意図的に相互に整列されていない限り、それらの phase relation は不明です。

phaseに関するこのトピックのために、上記の clock domain の定義では、単に「特定の clock」ではなく、「特定の clock signal」と書きました。 「特定の clock」とは、たとえば、ボード上の同じ clock が FPGAの 2 つの異なる input pins に接続されていることを意味します。一方、「特定の clock signal」は、 Verilog または designの netlist 内の wire を指し、上記の例の @clk1 および @clk2 のように、 clock 信号を表します。これは、 instantiations での ports の接続によって、または単純な "assign" ステートメントを使用して、 Verilog design で配布されます。

clock が Verilog とまったく同じ信号であるという事実は、ツールが、ハードウェア上で低い clock skew を保証するリソースを確実に使用することを意味します。また、ツールが clocks を related clocks と見なすかどうかにも影響します (これについては以下で詳しく説明します)。

Related clocks、 timing constraints 、 resynchronization logic

元の質問に戻りましょう。 上記の例の @bar は、他の registerと同じように使用できますか?または、より一般的に言えば、ある clock domain から別の clock domain に移動する path の宛先が flip-flop である場合、その output を flip-flopの outputと同じように確実に使用できますか?これは、 data input に到達する少なくとも 1 つの path が別の clockと同期している場合、この flip-flopの setup time と hold time を確保できるかどうかを尋ねることと同じです。

答えは簡単で短いです。 両側の clocks (例では@clk1 と @clk2 ) が related clocksである場合、宛先の flip-flopの output は完全に問題なく、この path に適切な timing constraint が達成されている場合、任意の registerのように使用できます。そうしないと、宛先の timing を保証できず、その事実に対処するために resynchronization logic を追加する必要があります。

このページは、2 つの related clocks間の path の完全な timing analysis を示しています。

上記の長い議論の後、これをいくつかの簡単なルールにまとめる時が来ました:

1. unrelated clocksに属する clock domains 間で paths に timing constraints を適用することはできません。
2. 2 つの clock domains間のすべての paths に resynchronization logic がある場合、これらの pathsに timing constraints を適用する必要はありません。
3. 2 つの clock domainsの間の path 上に resynchronization logic がない場合、 timing constraints をこの pathに適用する必要があります。

最初のルールは最も単純です。 2 つの clocks が related clocksであることを確認できない場合は、 clock domains 間のすべての paths に resynchronization logic があることを確認してください (次のページでその方法を説明します)。また、これらの pathsに timing constraints が強制されていないことを確認してください。不要な timing constraints は、 FPGA ツールの処理を難しくするだけです。

これらのルールのもう 1 つの結果は、 clocks が related clocksであっても、それらを unrelated clocksとして扱っても問題ないということです。先ほど述べたように、すべての pathsに resynchronization logic があることを確認し、 timing constraints の強制をオフにすることによってそれを行います (これについては以下で詳しく説明します)。

最後に、 clocks が related clocksであることが確実な場合、 resynchronization logicは必要ありませんが、 clock domains間のすべての paths で正しく適用される timing constraints が必要です。

この表は、このセクションをまとめたものです。表の行は、 pathの最後に resynchronization logic があるかどうかであり、その列は、 clocks が related clocks であるかどうかです。表の中央は、 path が timing constraints を必要とするかどうかを示しています。

		clocks は
		related clocks	unrelated clocks
Resynch- ronization logic:	未適用	pathにはTiming constraints が必要です	これは間違いです
	適用	pathではTiming constraints は必要ありません

よくある間違い

信号が異なる modulesに配線されている複雑な designでは、どの信号がどの clockと同期しているかを見落としがちで、知らないうちに 1 つの clock domain から別の clock domain に移動します。

有害な間違いには 2 つのオプションがあります。 最初のものは、 resynchronization logicなしで unrelated clocks の clock domains の間に path を作成することです。これは、これらの pathsの宛先で時折タイミング違反が発生する可能性があることを意味します。タイミングに関するすべての間違いと同様に、目に見える問題は非常に誤解を招く可能性があります。ツールは、 timing constraints から 2 つの clocks が related clocksであると推測し、 timing constraints を pathsに不必要に適用すると、混乱を招く可能性があります。これらの timing constraints は、 unrelated clocks間の paths では意味がありませんが、これらの paths は、適切に処理されたかのようにレポートに表示されます。これは、 timing reports の人間の読者を混乱させて、すべてが正常であると考えさせたり、 clocks が本当に related clocksであると考えさせたりする可能性があります。

2 番目の有害な誤りは、2 つの clocks が related clocks であり、 logicによってそのように扱われるが、ツールはそれらを related clocks と見なさない場合です。その結果、 clock domains間の paths では timing constraints が適用されません。その結果、タイミング要件が宛先で満たされているという保証はありません。繰り返しになりますが、これは信頼できない動作につながる可能性があります。ただし、 designのタイミング検証チェックでこの種の間違いを見つけることは可能です。

clock domain crossing に気付かなかったことが実際に無害である唯一の状況は、 related clocksの間であり、 FPGA ツールもそれらをそのように見なします (したがって、関連する pathsに timing constraints を強制します)。 clocks が異なる周波数を持っている場合、機能的なバグが依然として存在する可能性があり、 logic はこれを考慮していませんが、これは logicのバグと同様です。

不要な constrainingを避ける

多くの場合、単一の PLL を使用して、さまざまな機能ユニットで使用することを目的としたさまざまな周波数の clocks を作成します。設計者の観点からは unrelated clocksですが、実際には related clocksであり、ツールでは通常 related clocksと見なされます。

たとえば、 PLL が 10 MHzを持つ reference clock から 2 つの clocks を生成するとします。 1 つの clock は 90 MHz で、2 番目の clock は 100 MHzです。これらの clocks をプロジェクトのさまざまな部分に使用することを意図しているため、概念的には unrelated clocksです。しかし、2 つの flip-flops間に接続があり、1 つの flip-flop が 1 つの clockと同期し、2 番目の flip-flop がもう 1 つの clockと同期している場合はどうでしょうか?

最初の clock の period は 11.11 ns であり、2 番目の clock の period は 10 nsであるため、 rising edges 間の最悪の場合の時間差は 1.11 ns です (可能なすべての phase の組み合わせを考慮に入れます)。これは、 900 MHzの clock period に相当します。したがって、これら 2 つの flip-flops の間の path の timing はタイトであり、この要件を達成できたとしても、特にそのような pathsが多数ある場合、ツールに問題が生じます。

これは理論的なケースではありません。 一般的な落とし穴は、 clocks が related clocks であるかどうかに注意を払わずに、 dual-clock FIFO を使用して clock domains間のインターフェースをとることです。この間違いによる機能上の問題はありませんが、 dual-clock FIFOs には常に resynchronization logicがあるため、2 つの clock domainsの間で paths に timing constraints を強制するようにツールを強制しても意味がありません。これらのツールは、これらの timing constraints を目的なく実現するのに苦労する場合があります。

したがって、そのように使用されない related clocks 、特に同じ PLLから派生した clocks に注意を払うことが重要です。 timing constraints が、ある clock domains から別の paths に強制される可能性があります。 resynchronization logic はタイミング違反から保護するため、この強制には利点がありません。一方、これらの paths で timing constraints を達成しようとするツールの努力は、 design全体で timing constraints を達成することを困難にする可能性があります。

これを解決するには、 clocks を unrelated clocksとして宣言する timing constraints を追加します。または、これらの pathsに対してfalse paths または maximal delaysを定義します。ただし、場合によってはこれが必要ない場合もあるため、これらの paths について何かを行う前に、 timing report でこれらの paths を確認することをお勧めします。たとえば、 FPGA ツールによって提供される dual-clock FIFO を使用する場合、 clock domains間を接続する paths に対して、適切な timing constraints が自動的に追加されることがよくあります。

誤解を招く timing constraints

FPGA tools は通常、 unrelated clocks間で timing constraints を受け入れて強制することを強調することが重要です。このような constraints は無意味で混乱を招きます。特に、関連する paths が timing report に表示され、あたかもそれらのタイミング要件が保証されているかのように見えるためです。すでに説明したように、 unrelated clocksに属する clock domains 間で path のタイミングを保証することは不可能です。

timing constraints は、 designに関する情報を FPGA tools に提供するための単なる手段であることを覚えておくことが重要です。 design が timing constraintsを達成した場合、それは timing constraints が正しい場合にのみ意味があります。したがって、 clocks が related clocksであるかどうかわからない場合は、 timing constraint を追加するだけで clock domain crossing を解決しようとしないでください。

繰り返しになりますが、関連する場合は、 clocks を unrelated clocksとして定義する timing constraints を追加するか、 false pathsを定義することをお勧めします。これにより、FPGA ツールが使いやすくなるだけでなく、混乱も回避されます。

ツールが正しく通知されていることを確認してください

上記のすべての理由から、 FPGA design ツールが、どの clocks が related clocksで、どの related clocksでないかについての正しい情報を持っていることが重要です。より正確には、FPGA ツールは、 resynchronization logic によって保護されていないすべての paths に timing constraints を適用します ( clock domains内の paths を含みますが、ここでは関係ありません)。

ただし、ツールが logic design と同じ認識を持っていることを確認するのは難しい場合があります。 各 FPGA design software には、 clocks間の関係を自動的に仮定する独自の方法があります。すべてのツールに共通しているように見える唯一の点は、ツールの専用 clocking IP を使用して同じ PLLで 2 つ以上の clocks を生成すると、ツールはこれらの clocks を related clocksと見なすことです。したがって、関連する clock domains 間の paths は時間調整され、 timing constraints はこれらの pathsに適用されます。この強制は、通常、 reference clockに対して指定された timing constraint に基づいています。しかし、それも当たり前だと思わないでください。

それ以外には、各ツールには clocks間の関係を推測する独自の方法があり、同じ FPGA ベンダーの異なるツールであっても、特定の状況では異なる判断を下すことがあります。最も顕著なのは、 Xilinxの Vivado は、 Xilinxの以前の主力ツールである ISEと比較して、 clocks が related clocksであると想定する傾向が強いことです。

したがって、すべての FPGA design ツールに共通する原則はなく、特定のツールでさえ驚くべき決定を下す可能性があります。このトピックに実際に取り組む唯一の方法は、 timing reportsをチェックし、特定の path groups に対して timing reports を作成して、タイミング要件が必要な場合に正しく、不要な場合に存在しないことを確認することです。これは大変な作業ですが、努力する価値はあります。

これで、このシリーズの最初のページは終了です。次のページでは、 crossing clock domainsの基本について説明します。