01signal: タイミング制約が正しいことを検証する

このページは、タイミングに関する連載ページの最後のページです。これまでのページでは、タイミング計算の背後にある理論を説明し、いくつかのタイミング制約(timing constraints)の書き方を示し、タイミングクロージャ(timing closure)の原則について述べてきました。

はじめに

FPGA の開発では、機能を追加し、動作しないものを修正し、それを繰り返すというやり方がよく取られます。その際、間違っている可能性はあるものの、目に見える問題を引き起こしていない設計の部分を軽視してしまいがちです。

タイミング制約が正しく適用されていなくても、また、その制約が達成されていなくても、FPGA 設計が完全に正常に動作することがあり得るということを理解することは極めて重要です。タイミング制約を正しく使うことは、FPGA の安定かつ正確な動作を保証するための重要な要素の 1 つです。しかし、このトピックを軽視しても、直ちに障害が発生するとは限りません。むしろ、不適切なタイミングは、非常に混乱させられる断続的な誤動作を引き起こす可能性があります。

このページは、このタイミング制約に関する連載ページで述べた提案の多くを要約し、繰り返します。目的は、不適切なタイミングが原因の問題を探すときに留意すべきいくつかのトピックに焦点を当てることです。これらのトピックを時折、点検するだけの分別を持ちたいものですが、現実には、ほとんどの場合、まるで魔術のように思える問題を解決するためにこの作業を行うのです。

タイミングレポートを読む

FPGA 設計ツールはすべてタイミングレポートを生成します。私たちがそれを開く最も一般的な理由は、ツールがタイミング制約を達成できなかったときです。そこには、要件を満たせなかったパス(path)が載っており、それらのパスに対して何ができるかを、うまくいけば見極められます。

しかし、タイミングレポートを調べる理由は、それだけに留まりません。ツールがタイミング制約を意図どおりに解釈し、正しく適用していることを検証するという、同じくらい重要な理由があります。特に新しいタイミング制約を追加した後は、時折この検証を行うのが良い習慣です。

FPGA 設計ツールごとにレポートの構造や形式は異なるため、各レポートの各部分が正確に何を言っているのかに言及することは不可能です。そこで、このページでは、すべてのツールに共通する原則を概説します。ご自身のタイミングレポートの形式や機能については、時間を取って学んでおくことをお勧めします。

タイミングレポートの点検には、もう 1 つ潜在的な利点があります。ロジックの誤った使われ方が明らかになる可能性があるのです。たとえば、設計に誤って使われた非同期ロジックが含まれている場合や、タイミング制約を適用できないクロックに依存している場合、それはタイミングレポートに現れることがあります。このロジックにタイミング制約を適用することは不可能なため、制約なしパスとしてレポートに表示される可能性があります。

また、設計に含まれる IP が、ユーザーが提供する制約に加えて、IP 自身のタイミング制約を追加することが多い点にも触れておく価値があります。通常、これらの制約に関連するパスを点検する必要はありませんが、それらの制約によってタイミングレポートがかなり重くなることがあります。

制約なし内部パス

ここでの議論では、同期エレメント(synchronous element)とは、フリップフロップ、ブロック RAM、シフトレジスタ、またはクロックの立ち上がりエッジまたは立ち下がりエッジでデータ入力をサンプリングしたり、データ出力を変更したりするその他の論理エレメントを指します。

同期エレメントのデータ出力から別の同期エレメントのデータ入力へ至るすべてのパスは、タイミング制約の対象とする、つまり、タイミング制約を適用しなければなりません。唯一の例外は、宛先の同期エレメントで、無関係クロックドメインの場合のように、タイミング違反の可能性が適切に処理されている場合です。

言い換えれば、設計ツールが入力信号を予測可能な方法でサンプリングする責任を負わないことを補う明示的な再同期化機構が存在する場合を除き、すべての同期エレメントへのパスにはタイミング制約を適用しなければなりません。

基準クロックを定義する1 行のタイミング制約で十分なこともあれば、FPGA ツールが残りを処理してくれる場合もあります。それ以上が必要な場合もあります。本当に悪いケースでは、いくつかの内部パスが誤って制約なしのまま残されることがあります。その理由は、次のようないくつか考えられます。

タイミング制約を追加し忘れている。
パスが誤ってフォールスパス(false path)として定義されている。
関連クロック(related clocks)間のクロックドメイン横断(clock domain crossing)であるのに、ツールがそれらを無関係クロック(unrelated clocks)として扱っている(これについては後述)。
タイミング制約がクロックリソース要素を通して伝播されていない。たとえば、基準クロックが FPGA の PLL に接続されている場合、タイミング制約は通常 FPGA の入力ピンに対して与えられます。ツールは、PLL の出力クロックに対しタイミング制約を自動的に生成することが期待されます。通常はそうなりますが、時には驚きがあります。
クロックがロジックによって生成されている(たとえば、ロジックファブリックで実装された分周器を使う場合)ことがあり、タイミング制約で明示的にカバーされていない。

FPGA 設計ツールは、制約なしパスのリストを生成するタイミングレポートを作成できます。制約なしパスとは、タイミング制約が適用されなかったパスのことです。原則として、このリストは空であるべきです。制約が不要なパスは、タイミング制約ファイル内でフォールスパスとして明示的に定義すべきです。そのような制約は、もともとタイミング対象ではなかったパスに対して機能的な変更を加えませんが、タイミングレポート内の制約なしパスのリストを空に保つことができます。これにより、意図せず除外されたパスを簡単に見つけられます。さらに、このリストのパス数には限りがあるため、無害なパスがリストに載ることで、本来このリストにあってはならないパスが隠れてしまう可能性があります。

しかし残念ながら、タイミングレポートによっては、制約なしパスの欄に、タイミング制約を適用する理由のないパスも含まれることがあります。たとえば、クロックバッファの出力から別のクロックリソースの入力へのパスです。その結果、タイミングレポートには非常に多くのパスが制約なしとしてリストされることがありますが、それで問題ありません。これにより、タイミングレポートから状況を推測することが少し難しくなりますが、そのようなパスは通常、フリップフロップのデータ入力やその他の同期エレメントで終わるパスとは別にリストされるため、実際には問題になりません。つまり、レポートを注意深く読み、リストアップされた各パスのグループが何を意味するのかに注意を払うことに尽きます。

デフォルトで作成されるタイミングレポートは、この情報を含むには十分に詳細でないことがあります。まともな FPGA 設計ツールであれば、制約なしパスをリストアップするオンデマンドのタイミングレポートを作成でき、各グループについてリストアップするパス数を選択できます(該当するリストは完全に空であるべきなので、10 が妥当な数です)。

クロックドメイン間のパス

内部パスのソースと宛先で異なるクロックに同期している場合、そのクロックが関連クロック(より正確には、ロジックがそれらを関連クロックとして扱っている場合)であれば、そのパスにタイミング制約を適用しなければなりません。そうでなければ、適用すべきではありません。この不要な制約は、高品質の配線リソースを浪費し、タイミング制約の未達を引き起こす可能性があるからです。関連クロックと無関係クロックについてはこのページを参照してください。

各ツールセットには、2 つのクロックを関連クロックと見なすかどうかを自動的に決定する独自の方法があります。タイミング制約ファイルで SDC 構文を使うツール(Vivado や Quartus など)には、set_clock_groups コマンドがあり、関連クロックのグループと無関係クロックのグループを定義できます。また、特にフォールスパスのタイミング制約を使って、ツールをこの点で導く他の方法もあります。

では、ツールがクロックを関連クロックと見なしているかどうかを確認するにはどうすればよいのでしょうか。残念ながら、その方法はツールセットごとに異なります。たとえば Vivado には Clock Interaction Report があり、各クロックペアの状況を示す色付きの図が表示されます。

あるクロックから別のクロックへのパスにタイミング制約が適用されている(つまり、ツールがそれらのクロックを関連クロックと見なしている)。
あるクロックから別のクロックへのパスにタイミング制約が適用されていない(「ユーザー無視パス」)。
一部のパスにはタイミング制約が適用されている。

あるいは、特定のパスのグループに限定したカスタムタイミングレポートを使って、この問題を調べることもできます。パスは、関与するクロックに従って選択できます。これは、あるクロックに同期する論理エレメントから始まり、別のクロックで終わるパスを選択することによって行えます。また、クロックドメイン横断に関与することが分かっているパスのグループを特に調べることも有益です。

難しいかもしれませんが、ツールがどのクロックドメイン横断に制約を適用しているか、そしてそれが正しいかを包括的にレビューすることが極めて重要です。同時に、論理設計に必要な場所に再同期化ロジックがあるかをレビューする機会にもなります。各信号にどのクロックが使われているかについて混乱すると、安全でないクロックドメイン横断を簡単に作り出してしまいます。

このレビューは、各クロックの性質を念頭に行うことが重要です。たとえば、異なる発振器からの 2 つのクロックが同じ意図した周波数を持ち、タイミング制約ファイル内で同様の定義を持つ場合、ツールはそれらを誤って関連クロックと見なし、一方のクロックから他方のクロックへ渡るパスのタイミングを計算するかもしれません。そのようなパスに制約を適用しても意味がありません。2 つのクロックの位相関係については、まったく保証がないからです。不要なタイミング制約はそれ自体では、ツールがタイミングを達成するのを難しくするだけで、かなり無害です。本当の問題は、タイミングレポートが、それらのクロックが実際には関連クロックであると思い込ませる可能性があることです。つまり、制約とタイミングレポートだけを見ると、それらの間のパスは安全であるように見えるかもしれません(つまり、タイミング違反に対する保護が不要であるように見える)が、実際にはそうではありません。2 つのクロックは、ほぼ同じ周波数であること以外に何の共通点もないのです。この種の誤りを避ける唯一の方法は、各クロックがどのように生成されるかを理解することです。

制約なし外部パス

I/O ピンで始まるパス、または I/O ピンで終わるパスには、常にタイミング制約を適用すべきです。これを行う方法は別のページで説明しています。唯一の例外は、クロック入力ピンと、特別なインターフェースを持つピンです。たとえばギガビットトランシーバー、FPGA のシリコン上のハードウェアプロセッサに直接接続されるピンなどです。インターフェースが非常に遅い場合は、タイミング制約を定義しなくても許されることもあります。たとえば、LED、押しボタン、I²C 配線などです。しかし、そのようなピンにはフォールスパス制約を割り当てる方がはるかに優れています。これにより、タイミングレポート内の制約なし I/O ピンのリストを空に保てます。

外部パスにタイミング制約を適用することは、多くの場合、無意味に思えるかもしれません。たとえば、同じクロックに同期したいくつかの出力ピンがあり、それらがすべて同時にトグルすることで正しいタイミングが保証されている場合などです。この同時トグルを実装する一般的な方法は、IOB レジスタを使うことです。このフリップフロップは、達成可能な最良のクロックから出力までの遅延と、出力ピン間の驚くほど低いスキューを提供します。

しかし、これは出力ピンへのタイミング制約が重要である良い例です。タイミング制約を厳しく保つことで、これらのピン間の低いスキューが保証されます。IOB レジスタを使う場合、厳しいタイミング制約は、ツールにこのフリップフロップを使わせる方法になります。あるいは、ツールがそうしなかった場合に見逃されないようにする方法になります。ツールがフリップフロップを意図どおりに配置しなければ、タイミングが未達になるからです。

同様の理由で、入力ピンにも厳しいタイミング制約を適用すべきです。

複数のピン間で低いスキューを実現するためにタイミング制約を使う場合、報告されるスラック(slack)がほぼゼロになるまで I/O ピンを制約するのではなく、より厳しいタイミングを要求すると制約の達成に失敗することを確認することが重要です。これは、I/O 信号パスにオプションの遅延線が含まれることがあり、ツールが直感に反する方法でそれを利用する可能性があるためです。たとえば、Intel FPGA の Quartus は、タイミング予算に余裕がある場合、入力パスに遅延を追加することがあります。ツールがこれを行う選択は、望ましくも予期されもしないかもしれません。

誤ったフォールスパスとその他の過度に緩いタイミング

タイミング制約が適用されていても、それが緩すぎる場合があります。これは、関連するパスにはタイミング制約が適用されているものの、要件が間違っているため、検出がはるかに困難です。

この種の事故には、次のようないくつかの考えられる理由があります。

フォールスパス制約が、適用すべきでないパスに誤って適用されている。おそらく、対象となる論理エレメントを定義する式の誤りによるものです。
他の特定のタイミング制約でも同じ問題が発生します。たとえば、マルチサイクルパス(multicycle path)のタイミング要件が誤っている場合などです。
タイミング制約で所望の時間量を指定する値が誤って指定されている。
FPGA 設計ツールが汚い手を使う場合。たとえば Intel FPGA の Quartus は、「derive_pll_clocks」ステートメントが SDC ファイルにないと、パスに誤ったクロック周波数を割り当てることがあります。

この種の問題を見つける簡単な方法はありません。タイミングレポートを最初から最後まで注意深く読むことは確かに良い考えですが、レポートが各グループについて 10 パスを表示していても、問題のあるパスがたまたまそこに現れる保証はありません。あるいは、どのような数のパスを表示したとしても、それは同じです。

もう 1 つの対処法は、書かれたタイミング制約をレビューすることです。SDC 制約は Tcl で書かれているため、制約ファイル内で論理エレメントを選択する式(「from」や「to」)を Tcl 式として評価し、エンドポイントのリストを読み通すことができます。

たとえば、Vivado の .xdc ファイルに次の行が現れた場合、

set_false_path -to [ get_pins -hier -filter {name =~ */pclk_i1_bufgctrl.pclk_i1/S*} ]

実装済み設計を開き、フォールスパスが適用される宛先をリストアップできます。

puts [join [ get_pins -hier -filter {name =~ */pclk_i1_bufgctrl.pclk_i1/S*} ] "\n" ]

Tcl コマンド(「puts」と「join」)により、各要素が別々の行にリストされるため、出力を読みやすくなります(非常に長くなる可能性があります)。

この種の制約のレビューは重要ですが、実際の思考作業が必要なため、同様に困難です。

まとめ

ツールがさまざまなパスに正しいタイミング制限を適用していることを確認することは、厄介な作業です。それは、タイミング制約ステートメントの正確な意味を知ることと、タイミングレポートを調べる方法を知ることの組み合わせであり、それによって誤りを見つける可能性を高めます。

しかし、何よりも重要なのは、設計が正常に動作しているように見えるときに特に、設計を確認し再確認するという自己規律を持つことです。