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 、またはその両方に反応する場合があります。ここでの議論では、簡単にするためにこれらすべてを無視します。

また、 synchronous element Xの clock input が clock Yに接続されていることを表すために、「X は 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 には timing requirementsがあります。 data input (D) は、 @clk2の rising edgeの前に安定した t_su ( setup time) でなければならず、この edgeの後も安定した t_hold ( hold time) のままでなければなりません。

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

たとえば、上の図と t_suの timing requirement を見てみましょう。 @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 には常に timing constraintsが含まれており、 design ツールに clocksの周波数に関する情報を提供します。この情報に基づいて、ツールは2つの timing requirements (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 に接続され、もう 1 つの clock が pathの末尾で flip-flop に接続されている場合はどうなるでしょうか。言い換えると、 @clk1 が @clk2と同じでない場合はどうなるでしょうか。それでもタイミング計算を行って timing requirementsを確保することは可能ですか。まあ、それは状況によります。このページの残りの部分では、それについて説明します。

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 にすぎません。したがって、最悪のケースの timing requirement は、想像上の x6 clkに相当します。その理由は、 x2 clk の 2 番目の rising edge と x3 clkの 3 番目の rising edge の間の時間差です。

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

したがって、この例のポイントは、一般的にも正しいことを言うことです。 related clocksを使用すると、これらの clocks間の paths に timing constraints を適用することで、同じ clock domain内の paths と同様に timing を保証することができます。これは、 FPGA ツールが意図的に clock edges が揃っていることを確認する場合に可能になります。例で示されているように、 timing requirements は多くの場合、個々の 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 signal」と書きました。単に「特定の clock」と書いたわけではありません。「特定の clock」とは、たとえば、 FPGAの 2 つの異なる input pins に接続されている、 board上の同じ clock を意味します。一方、「特定の clock signal」は、上記の例の @clk1 や @clk2 のように、 Verilog 内の wire または designの netlist 内の clock signalを表します。これは、 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 つのオプションがあります。 1 つ目は、 resynchronization logicなしで unrelated clocks の clock domains の間に path を作成することです。これは、これらの pathsの宛先で timing が時々違反される可能性があることを意味します。 timingのすべての間違いと同様に、目に見える問題は非常に誤解を招く可能性があります。ツールは、 timing constraints から 2 つの clocks が related clocksであると推測し、そのため pathsに不必要に timing constraints を適用すると、混乱を増す可能性があります。これらの timing constraints は、 unrelated clocks間の paths では意味を持ちませんが、これらの paths は、適切に処理されたかのように reports に表示されます。これにより、 timing reports を読む人間が混乱し、すべてが正常であると考えたり、 clocks が実際には related clocksであると考えたりする可能性があります。

2 つ目の有害な誤りは、2 つの clocks が related clocks であり、 logicによってそのように扱われるが、ツールではそのように見なされない場合です。その結果、 clock domains間の paths に timing constraints は適用されません。その結果、宛先で timing requirements が満たされるという保証はありません。この場合も、信頼性の低い動作につながる可能性があります。ただし、 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 に注意を払うことが重要です。 おそらく、 clock domains から別の clock domains にかけて、 paths に timing constraints が強制されます。 resynchronization logic は timing violationsから保護するため、この強制には利点がありません。一方、これらの 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 で timing requirements が保証されているかのように表示されるため、無意味かつ混乱を招きます。すでに説明したように、 unrelated clocksに属する clock domains 間の path の timing を保証することは不可能です。

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で、どれがそうでないかに関する正しい情報を持っていることが重要です。より正確には、 FPGA ツールが、 resynchronization logic によって保護されていないすべての paths ( clock domains内の paths も含まれますが、ここでは関係ありません) に timing constraints を適用します。

ただし、ツールが 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 を生成して、必要な場所では timing requirements が正しく、不要な場所では存在しないことを確認することです。これは困難な作業ですが、努力する価値はあります。

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