01signal: クロックドメイン、関連クロック、無関係クロック

はじめに

ごく単純な FPGA 設計を除けば、複数のクロックが同期要素(フリップフロップ、ブロックRAM、シフトレジスタなど)を駆動します。しかし、ロジック設計内の大半の機能ユニットは単一のクロックで動作するため、複数のクロックが話題になることはほとんどなく、特別な注意は必要ありません。あるクロックに基づくロジックと、別のクロックに基づくロジックを接続するときになって、話は難しくなります。このシリーズでは、設計の中で複数のクロックをどう扱うかを解説します。

異なるクロックに依存するロジック同士を接続するとき、最初に答えるべき最も重要な問いは、再同期ロジック(resynchronization logic)が必要かどうかです。これは2つのクロックが関連クロック(related clocks)であるかどうかを問うことにほかなりません。このページでは、この問いとその答え方、および関連する話題を説明します。以下の議論の多くは、タイミング制約(timing constraints)と、それをロジックの特定の要素に適用できるかどうかに関係します。そこでまず、タイミングについて簡単に復習します。

このシリーズの解説は、ポジティブエッジトリガのフリップフロップ、つまりクロック入力の立ち上がりエッジに反応するフリップフロップに限定します。もちろん、クロックに基づいて信号をサンプリング(sampling)して生成する同期要素も他にあります。シフトレジスタ、ブロックRAM、その他多数の機能要素です。中にはクロックの立ち下がりエッジや、その両方のエッジで反応するものもありますが、ここでは簡単のためそれらはすべて無視します。

また、「X は Y に同期している」という表現は、同期要素 X のクロック入力がクロック Y に接続されていることを意味するものとして使います。したがって、この同期要素は、そのクロックで入力(複数の場合もある)をサンプリングし、出力もそのクロックで更新します。

タイミングの基礎を簡単に

ここではタイミング理論の要点を簡単にまとめます。より詳しい説明は別のページにあります。

次の図は、LUT を経由して、あるフリップフロップから別のフリップフロップへと信号が伝わる信号パス(path)を示しています。

この図の LUT(Look-Up Table、ルックアップテーブル)は、任意の組み合わせロジック(combinatorial logic)のまとまりを表しています。I1、I2、I3、I4 のいずれかが変化すると、出力 O は伝搬遅延(propagation delay)を伴ってすぐに変化します。

この信号パスは次のように動作します。左のフリップフロップの Q 出力(@foo)は、入力クロック @clk1 の立ち上がりエッジの後に変化します。この出力は I1 に接続されているので、LUT の出力 O は少しの遅延の後に変化します。この O は右のフリップフロップのデータ入力 D に入ります。右のフリップフロップは @clk2 の立ち上がりエッジの後に D を Q(@bar)へコピーします。

しかし、それほど単純ではありません。すべてのフリップフロップにはタイミング要件があります。データ入力 D は、@clk2 の立ち上がりエッジの前に t_su(セットアップ時間)だけ安定していなければならず、このエッジの後も t_hold(ホールド時間)だけ安定していなければなりません。

FPGA 内の信号パスの大部分は単一クロックに関係しています。したがって、@clk1 と @clk2 は正確に同じクロック信号です(ここではクロックスキュー(clock skew)は無視します)。そのようなパスでは、2つのタイミング要件を保証できるかどうかを計算できます。

たとえば、上の図の t_su に関する要件を考えてみましょう。ここでは、@clk1 の立ち上がりエッジから、右のフリップフロップの D 入力が更新されて安定するまでにどれだけの時間がかかるかを求めます。これはこのパス上のすべての遅延の合計です。まず、@clk1 の立ち上がりエッジから @foo が更新されるまでの遅延(clock to output)があり、その後、右のフリップフロップの D 入力に届くまでの遅延がすべて続きます。これには LUT の遅延だけでなく、ロジック要素間の配線遅延(routing delay)も含まれます。

@clk1 と @clk2 が同じクロックであれば、両方のフリップフロップの次の立ち上がりエッジがいつ来るかは明らかです。1クロック周期後です(たとえば 100 MHz クロックなら 10 ns)。したがって、パスの合計遅延は、t_su のマージンを確保したうえで、クロック周期より短くなければなりません。これを保証できれば、t_su の要件、つまり右のフリップフロップの D 入力が @clk2 の立ち上がりエッジの前に t_su のマージンを持って安定していることが保証されます。数値を使った例はタイミング理論のページを参照してください。

t_hold についても同様の計算ができます。t_su と異なり、右のフリップフロップの D 入力が @clk2 の立ち上がりエッジの後も一定時間(t_hold)安定し続けることが要件です。したがって、クロック周期は無関係であり、計算には入りません(@clk1 と @clk2 が同じ場合)。重要なのは、次のクロックサイクルではなく、同じクロックサイクルの中で何が起こるかです。

この種の計算が可能なのは、@clk1 と @clk2 の立ち上がりエッジの時間差が分かっているからです。特に、@clk1 と @clk2 が同じクロックなら、t_su の計算に使う時間差は、そのクロックの周期になります。しかし、2つのクロックの時間差が不明なら、t_su も t_hold も保証できません。

t_su と t_hold は、すべてのフリップフロップに適用されます。これはもちろん、FPGA 上のすべてのフリップフロップだけでなく、外部デバイス上のフリップフロップにも当てはまります(たとえば FPGA の出力ピンから、クロックで信号をサンプリングする外部デバイスへの経路)。したがって、システム内の各フリップフロップについて、これら2つの要件を満たすことを保証できているかどうかを確認する必要があります。保証できないフリップフロップについては、それを補って確実に動作させる仕組み(つまり再同期ロジック)を用意しなければなりません。これが、要するにクロックドメインをまたぐ話の核心です。

では、もう一度:タイミングはいつ保証されるのか?

前の節で混乱してしまった場合に備え、要点をまとめます。

FPGA 設計には、クロックの周波数を設計ツールに知らせるタイミング制約が必ず含まれていることを思い出してください。ツールはこの情報に基づいて、2つのタイミング要件(t_su と t_hold)が満たされるようにします。あるいは、ツールがこれらの要件を達成できない場合は、その失敗をレポートします。

前述のとおり、t_su と t_hold を保証できるのは、パスの始点にあるクロックの立ち上がりエッジと、パスの終点にあるクロックの立ち上がりエッジの時間差が分かっている場合だけです。この条件は、ほとんどの場合に成立します。ロジック設計の大部分は、同じクロックに同期した別のレジスタに依存するレジスタで構成されているからです。

しかし、2つの異なるクロックを使う場合はどうでしょう。パスの始点にあるフリップフロップには一方のクロックが接続され、終点にあるフリップフロップには別のクロックが接続されているとしたら?言い換えれば、@clk1 と @clk2 が同じでない場合は?それでもタイミング計算をして、タイミング要件を保証できるのでしょうか?それは場合によります。このページの残りでは、まさにこの問題を扱います。

クロックドメインとクロックドメインクロッシング

クロックドメイン(clock domain)とは、特定のクロック信号に同期するすべての同期要素(フリップフロップなど)の集まりのことです。

次の簡単な Verilog コードを見てください。

reg foo, bar;

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

always @(posedge clk2)
  bar <= foo;

この例では、@foo は @clk1 に同期し、@bar は @clk2 に同期しています。したがって、@foo と @bar は、それぞれ @clk1 と @clk2 という別々のクロックドメインに属します。

@foo については心配する必要はありません。@foo は自分自身にだけ依存しています。一方 @bar は @clk2 に同期し、@clk1 に同期する @foo に依存しています。では、@bar を普通のレジスタとして使ってよいのでしょうか。@bar は常にタイミング的に正しい状態で @foo の値を取り込むので、その動作は既知で再現可能だと仮定できるでしょうか?

この質問に答える前に、いま起きたことを名前で呼んでおきましょう。これはクロックドメインクロッシング(clock domain crossing)です。@foo と @bar は、互いに異なるクロックに同期する2つのフリップフロップとして実装されています。つまり、@foo から @bar へのパスは、あるクロックドメインから別のクロックドメインへとまたがっています。

より一般的には、クロックドメインクロッシングとは、あるクロックドメインに属する同期要素の出力が、別のクロックドメインに属する同期要素の入力に届く状況を指します。この2つの同期要素の間には、組み合わせロジックが入っていることもよくあります。

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

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

そこにはやはりクロックドメインクロッシングがあります。この場合、パスは @foo から始まり、論理関数を実装する LUT を通って @bar で終わります。先ほどの図と同じです。

よくある誤り

複雑な設計では、信号がさまざまなモジュールにまたがって配線されるため、どの信号がどのクロックに同期しているかを見落としがちです。その結果、気づかないうちにあるクロックドメインから別のクロックドメインへ移ってしまうことがあります。

有害な誤りには2つのタイプがあります。1つ目は、無関係クロック同士のクロックドメイン間に、再同期ロジックなしでパスを作ってしまうことです。これは、そのようなパスの終点でタイミング違反が時折発生する可能性があることを意味します。タイミングに関する誤りは、目に見える問題が非常に誤解を招きやすいという特徴があります。さらに、ツールがタイミング制約から2つのクロックは関連クロックだと推定し、そのパスに不要なタイミング制約を適用すると、混乱に拍車がかかります。無関係クロック間のパスにそのような制約は意味を持ちませんが、レポート上ではあたかも適切に処理されたかのように表示されます。そのため、タイミングレポートを読む人間が、すべて問題ないと思い込んだり、あるいはそれらのクロックが本当に関連クロックだと誤解したりする恐れがあります。

2つ目の有害な誤りは、2つのクロックが実際には関連クロックであり、ロジックもそのように扱っているのに、ツールが関連クロックとして認識しない場合です。その結果、クロックドメイン間のパスにはタイミング制約が適用されず、終点でタイミング要件が満たされる保証がありません。これもまた、信頼性の低い動作につながる可能性があります。ただし、この種の誤りは、設計のタイミング妥当性の検証で見つけられる可能性があります。

クロックドメインクロッシングに気づかないことが本当に無害なのは、クロック同士が関連クロックであり、FPGA ツールもそのようにみなしている場合だけです(その場合、関連するパスにはタイミング制約が適用されます)。クロックの周波数が異なるのにロジックがそれを考慮していなければ、機能的なバグは依然として起こり得ます。ただし、それは通常のロジックのバグと同じです。

不要なタイミング制約を避ける

1つの PLL から異なる周波数のクロックを生成し、それぞれを異なる機能ユニットで使うことはよくあります。設計者の視点では、それらは無関係クロックですが、実際には関連クロックであり、ツールも通常は関連クロックとして扱います。

たとえば、PLL が 10 MHz の基準クロックから2つのクロックを生成するとしましょう。1つは 90 MHz、もう1つは 100 MHz です。これらはプロジェクトの異なる部分で使うつもりなので、概念的には無関係クロックです。ところが、あるフリップフロップが一方のクロックに同期し、別のフリップフロップがもう一方のクロックに同期するような接続があったらどうなるでしょうか?

最初のクロックの周期は 11.11 ns、2番目のクロックの周期は 10 ns なので、立ち上がりエッジ間の時間差の最悪値は 1.11 ns です(可能なすべての位相の組み合わせを考慮した場合)。これは 900 MHz のクロック周期に相当します。したがって、これら2つのフリップフロップ間のパスのタイミングは非常に厳しく、たとえ要件を達成できる場合でも、ツールにとっては難題です。特に、そのようなパスが多数ある場合はなおさらです。

これは理論上の話ではありません。よくある落とし穴は、クロックが関連クロックかどうかに注意を払わず、デュアルクロック FIFO を使ってクロックドメイン間を接続することです。この誤りに機能的な問題はありません。ただし、デュアルクロック FIFO には常に再同期ロジックがあるため、2つのクロックドメイン間のパスにタイミング制約を適用するようツールに強いるのは無意味です。ツールは、無意味なタイミング制約を達成しようと苦労するかもしれません。

したがって、関連クロックでありながら関連クロックとして使われていないクロック、特に同じ PLL から出力されているクロックに注意することが重要です。あるクロックドメインから別のクロックドメインへのパスにタイミング制約が適用されている可能性が高いからです。この適用には利点がありません。再同期ロジックがタイミング違反から守ってくれるからです。その一方で、ツールがそれらのパスのタイミング制約を達成しようと努力するせいで、設計全体のタイミング制約を達成するのが難しくなることがあります。

これを解決するには、クロックを無関係クロックとして宣言するタイミング制約を追加します。あるいは、それらのパスにフォールスパス(false path)または最大遅延を定義します。ただし、場合によってはその必要がないこともあるので、対処する前にこれらのパスについてタイミングレポートを確認する価値があります。たとえば、FPGA ツールが提供するデュアルクロック FIFO を使う場合、クロックドメイン間を接続するパスには、適切なタイミング制約が自動的に追加されることがよくあります。

誤解を招くタイミング制約

FPGA ツールは通常、無関係クロック間のタイミング制約も受け入れ、適用してしまうことを強調しておきます。そのような制約は無意味であるだけでなく、混乱の元です。特に、それらのパスが、あたかもタイミング要件を保証されているかのようにタイミングレポートに現れるからです。すでに述べたとおり、無関係クロックに属するクロックドメイン間のパスのタイミングを保証することは不可能です。

タイミング制約は、FPGA ツールに設計に関する情報を伝える手段にすぎないことを覚えておくことが重要です。設計がタイミング制約を達成できたとしても、その制約が正しい場合にのみ意味があります。したがって、クロックが関連クロックだと確信できないのであれば、タイミング制約を追加するだけでクロックドメインクロッシングを解決しようとしないでください。

繰り返しになりますが、該当する場合には、クロックを無関係クロックと定義するタイミング制約や、フォールスパスを定義するとよいでしょう。それにより FPGA ツールの作業が楽になるだけでなく、混乱も避けられます。

ツールに正しい情報を確実に伝える

上で述べたすべての理由から、FPGA 設計ツールが、どのクロックが関連クロックで、どれがそうでないかについて正しい情報を持っていることが極めて重要です。より正確には、FPGA ツールが、再同期ロジックによって保護されていないすべてのパスにタイミング制約を適用することが重要です(これにはクロックドメイン内のパスも含まれますが、ここでは関係ありません)。

ただし、ツールにロジック設計と同じ認識を持たせるのは難しい場合があります。FPGA 設計ソフトウェアは、それぞれ独自の方法でクロック間の関係を自動推定します。すべてのツールに共通しているように思える唯一の点は、ツール専用のクロッキング IP を使って同じ PLL で2つ以上のクロックを生成した場合、ツールはそれらのクロックを関連クロックとみなす、ということです。それに伴い、関連するクロックドメイン間のパスはタイミング解析され、タイミング制約が適用されます。この適用は通常、基準クロックに対して与えられたタイミング制約に基づきます。しかし、その点さえ当然視してはいけません。

それ以外については、各ツールが独自の方法でクロック間の関係を推定します。同じ FPGA ベンダーの異なるツールでも、状況によっては異なる判断を下すことがあります。特に、Xilinx の Vivado は、Xilinx の旧フラッグシップツールである ISE と比較して、クロックを関連クロックとみなす傾向が強いです。

したがって、すべての FPGA 設計ツールに当てはまる普遍的な原則はありません。特定のツールでさえ、驚くような判断をすることがあります。このテーマに真剣に取り組む唯一の方法は、タイミングレポートを確認し、特定のパスグループについてタイミングレポートを出力して、必要な場所ではタイミング要件が正しく、不要な場所にはタイミング要件が存在しないことを確認することです。これは大変な作業ですが、やる価値はあります。

これで、このシリーズの第1回は終わりです。次のページでは、クロックドメインクロッシングの基礎を解説します。

		クロックは
		関連クロック	無関係クロック
再同期ロジック:	未適用	パスにはタイミング制約が必要	これは誤りです
	適用済み	パスにタイミング制約は不要

クロックドメイン、関連クロック、無関係クロック