FPGA の検証について

FPGA 開発における検証の問題

FPGA に集積される回路規模の増大と FPGA の性能/機能の向上により FPGA 開発における検証工数の増大が問題になっています。
検証工数が多くなった主な要因は下記の 3つです。

1. デザインの規模と複雑さが 1人で把握できる範囲を越えた

2. RTL修正⇔検証”の繰り返し（イタレーション）回数が増加した

3. FPGA のコンパイル（論理合成と配置配線）時間が長くなった

1. により不具合原因の特定が困難になると 2. のイタレーションが増えます。悪い事に 2. と 3. は相乗（コンパイル時間 x 回数）されるので、検証工数は指数関数的に増大します。

高位合成などにより FPGA の設計が効率化されると更に回路が大規模になるので、検証工数は益々増えて行きます。

では、検証工数を削減するための方法として、実機検証とシミュレーションをうまく組み合わせる方法、それらとは異なる新しい検証手法について紹介します。

実機検証とシミュレーション

FPGA 設計者の中には未だにシミュレーションを行わない方がいます。

実機検証とシミュレーションは下記のように正反対の特徴を持っていますので、うまく組み合わせると検証工数を減らすことができます。

	実機検証	シミュレーション
長所	・検証速度が非常に高速・広い範囲（システム全体）を検証できる	・RTL を修正した後、すぐに検証を行える・デバッグ機能を使って不具合の原因箇所がすぐに分かる・システムが完成する前の小さな回路から検証できる・想定外の動作による検証ができる
短所	・RTL を修正してから、実機検証するまでのステップが多い・不具合の原因箇所を探すのが非常に困難・システムが一通り完成しないと検証できない	・検証速度が遅い・狭い範囲（論理とタイミング)しか検証できない・テストベンチを作成する必要がある

表1．実機検証とシミュレーションの長所と短所

実機検証は FPGA だけでなく、システム全体を高速に動作させてすばやく不具合を見つけることができます。ところが、せっかく見つけた不具合でも、その原因となった箇所を探して修正する作業（デバッグ）は苦手です。RTL を修正してから実機検証を 1回行うだけで数日もかかる事があります。また、検証が不十分のままで実機を動かすと、大事な基板を壊すことがあります。

逆に、シミュレーションはデバック作業が得意です。最近のシミュレータは期待値を照合するだけではなく、シミュレーション中に内部状態の不具合を見つけたり、不定（X）になった原因を自動検索したり、RTL とシミュレーション波形と自動リンクするなど、デバックに役立つ機能を豊富に備えています。シミュレーションの速度は実機よりもかなり遅いのですが、問題個所だけ切り抜いて検証するなら1日で数十ターン以上も検証できます。もちろん、ソフトウェア上での検証なので基板を壊すこともないので思いっきり検証できます。

ステップに応じた検証手法

検証専門の技術者がいる場合は、バグを見つけるための視点　からテストベンチを作成します。このテストベンチを使ってシミュレーションで検証しながら、並行して別チームが実機検証を徹底的に行いながら、完成度の高いデザインとテストベンチを作成します。検証工数はかかりますが、複数の担当者が並行して作業するので検証期間は短くなります。

回路設計と検証設計が同じ場合は、回路を動かす視点からテストベンチを作成するのでバグを見つけるのが遅れがちです。この場合は下記のフローで開発するとイタレーションを減らして全体の検証時間を短くできます。

ステップ	目的	検証手法
RTL設計時	仕様書に書かれた実現したい機能の確認	シミュレーション（論理検証）
	懸念される(想定内の)バグの検証	シミュレーション（論理検証）
	想定外のバグの検証	シミュレーション（ランダム検証）
論理合成後	タイミング検証、性能の検証	スタティック・タイミング解析（タイミング検証）
プログラミング後	環境条件を含んだシステム全体の検証	実機検証（システム検証）
	想定外のバグの検証	実機検証（システム検証）
	不具合発見後のデバッグ	シミュレーション（論理&タイミング検証）

表2．ステップ別の検証手法

RTL 設計時

「仕様書に書かれた実現したい機能」をブロック単位でシミュレーションで確認します。この「実現したい機能」のバグは実機検証まで引きずらないようにします。「実現したい機能」のテストベンチはシミュレータの「コードカバレッジ」を使って最低限の検証をしている事を確認します。

「懸念される(想定内の)バグの検証」は、回路設計者とは別の視点で検討できる検証者が、バグを見つけるためのテストベンチを作成してシミュレーションで確認します。

「想定外のバグ検証」は設計者から見て危ない箇所、ステートマシンなどの「既知の検証ポイント」、「各ブロックの入力条件」、「実機検証で新たに見つかった検証ポイント」などをアサーション制約で規定し、テストベンチは制約付ランダムテストを使って、予想もつかないパターンを自動発生させてシミュレーションで検証します。また、このようなシミュレーションやテストベンチを使わずに検証できるフォーマル検証は実機検証をメインとするFPGA設計者にお勧めする手法です。フォーマル検証は別途説明します。

論理合成後

タイミング検証は検証時間が短いスタティック・タイミング検証用のツールを使います。
アルテラ社のスタティック・タイミング検証用ツール「TimeQuest」は無料で使うことができます。
論理合成の結果が不安であれば、論理の等価性検証ツールで論理を比較するか、シミュレータで論理を確認します。

プログラミング後

FPGA を含めてシステム全体の協調検証は実機を使って高速に検証します。

FPGA 内部の不具合を見つけた場合は論理とタイミングを考慮したシミュレーションを使ってデバッグするので、できるだけ高速なシミュレータを使用してください。ここでのデバックは製品出荷直前なので、デバック時間が製品出荷時期に大きく影響します。

実機検証で新たに見つかった検証ポイントは「既知の検証ポイント」としてアサーション制約を設定しておくと、デザインを流用しても忘れずに検証できます。