Plan-Based Analog Verification Methodology

アナログ検証について論じると、しばしば、SPICEソルバーのパフォーマンスや、または、微小な形状や位置情報に関する統計ばらつきの詳細な内容の議論に入り込むことがあります。他には、アナログ設計者のメインの作業コックピットとして、シミュレーション環境（Virtuoso Analog Design Environment）への議論になることがあります。しかし、より本質的な視点からの課題、例えば、「アナログ検証がいつ完了したのか」や、「検証ゴールは何か」、もしくは、「検証リソースが適切に分けられているのか」、などの課題についてほとんど議論がされません。

近年の設計で用いられるアナログ・ブロックの種類は、どちらかというと限られた種類となっています。例えば、PLL、ADC、DAC、フィルター、LDO、および、大半のアナログ動作をカバーする他の少数の関数ブロックといえます。その一方で、これらのブロックの関数とパフォーマンスの複雑さや、起こりうるインプリメンテーションの変化は、年を追って顕著に増加しています。実質的に、すべてのアナログ・デザインは、今ではミックスシグナルとなっています。微細化プロセス・ノードでは、デジタル・ロジックは、ほとんど無料の一方で、アナログは、その物理的位置情報の制約から費用のかかる部分となっています。そのため、キャリブレーションやモードの変更は、デジタル領域で行われます。

同時に、アナログ・デザインの検証の要望が高まっています。標準化、例えばオートモーティブ向けのISO26262（参考資料1）では、デザイン・フロー全般に対する資料化のみならず、標準化を保障するものとして、追跡可能である事も求められます。アナログ・ブロックの深刻な問題は、製品のライフ・サイクル中のファームウェアの更新では修正することができないので、今日、アナログ領域の不具合がシステム・オン・チップ（SoC）の致命的な問題をしばしば生じるのと同じくして、消費者市場において、この要求が大幅に増加しています。  

ケイデンスは、Virtuoso ADE L/XL/GXLのプロダクトと並行してVirtuoso ADE ExplorerとVirtuoso ADE Assembler をリリースしました。そして、ADE ファミリーの第 3 のプロダクトとして、Virtuoso ADE Verifier をリリースしました。Virtuoso ADE Verifier は、より形式が整えられた検証手法の要求に取り組むためのプロダクトです。そして、ADE ファミリーの第 3 のプロダクトとして、Virtuoso ADE Verifier をリリースしました。Virtuoso ADE Verifier は、より形式が整えられた検証手法の要求に取り組むためのプロダクトです。

Virtuoso ADE ファミリーのVirtuoso ADE L、XL、Explorerや、Assemblerは、インタラクティブな作業スタイルに対し申し分のない設計環境です。けれども、この検証の重要な部分は、アナログ設計者が検証のゴールを知っていて、設計者がそれらのゴールを満たすようにインタラクティブに作業することを目的として実行されます。これは、特定の標準規格に従っているものではなく、一連の作業は、手作業で実証されていますリグレッションのセットアップにおいて課題の限られた一部のみが自動化され定期的に繰り返されます。特に、デジタルの分野でここ数年にわたり導入されたような、ハイレベルなアナログ検証のプランニングを、ツールによって実施する発想がありませんでした。アナログ検証戦略とそのツールは、人々の要求に応じるために、年とともに開発され改善されています。では、今、なぜこのメソドロジーが伸びていないのでしょうか。

Functional safety and first time right

現代の生活のすべての場面への電子機器の急速な拡がりから、電子機器の安全性の要望は、ますます大きくなっています。最も知られている例としては、自動車産業（参考資料2）におけるISO 26262 標準規格が挙げられます。さらに、同様の標準規格は、医療デバイスなどの他の分野でも見ることができます。これらは、USのFDA（参考資料3）や他国の類似の機関により厳格に規制されています。事実上、これらは設計や検証フローのすべてにわたって、リスクや安全性が示されていることを求めます。

これらの要求は、アナログの設計や検証を含むフロー全体にわたります。アナログ領域への履歴の追跡を含む検証フローの文書化は、この要求のために即時に生み出されたものです。問題を生じる動作不良のリスクを最小限にすることは、すべての動作条件や制御環境の可能性のあるシナリオについて、アナログ・ブロックの完全な検証を必要とします。機能不全の検出や測定の集計を考慮することが求められます。

消費者向けの産業であっても、十分に文書化されていることや、構造化されたアナログ検証のアプローチの要望は、会社の要求する一定の検証ステップやフローに従うところまでに増加しています。これは、何故でしょうか。SoCの複雑度は、年々増し、そして、依然として一回の設計で動作することが重要とされています。このとき、アナログの問題に起因して、大規模なミックスシグナルチップが動作不良することは許されることではありません。デジタル部やソフトウェアの問題は、ファームウェアの更新によって回避できるかもしれません。アナログ・コンポーネントでの動作不良は、そのままデザイン全体の動作不良にもなりかねません。同時に、物理サイズのシュリンクは、堅牢性をもったアナログ設計をより難しくしています。

デジタル・アシステッド・アナログのような、デジタル領域に多くの機能を持たせることは、問題のいくつかを打開するには良い戦略といえます。しかし、その見返りとして、アナログとデジタルの間の接続が増えることは、十分に構築されたミックスシグナル検証の必要性を生じます。

Functional verification vs. performance verification

多くの場合、検証のタスクは、機能に基づくタスクかパフォーマンスに基づくタスクかのどちらかに分類されます。増幅器のオープン・ループ利得や乗算器のタイミング・パフォーマンスなど、回路のパフォーマンスは、低いパフォーマンスが機能性をだめにするというハードリミットを持ちます。より大きな利得やより高速なスイッチングが、常に良いとされます。その一方で、機能検証は、本質的な振る舞いを見ることです。例えば、レジスタが初期化の後に正しい値が代入されているか、パワーダウン・ピンがハイになったときにバンドギャップがオフに変化しているか、などを観測します。これらの機能検証の問いの回答は、ブーリアンとなります。

現在のデジタル検証フローは、明確に機能検証とパフォーマンス/タイミング検証に分かれています。アナログ検証のプロセスは、大抵、パフォーマンスを見ることに重きが置かれ、機能検証は過小評価されています。アナログ領域でのデジタル制御が増えていることから、機能検証の見地が、これからは絶対に無視できません。

しばしば、プランベースやメトリックドリブン検証（MDV, Metric-Driven Verification）の手法は、機能検証に完全に結び付けられます。これは、デジタル検証でも有益です。アナログ検証が増加するとき、この前提は、もはや正しいものとはいえません。パフォーマンス検証は、アナログ・フロントエンドの設計や検証プロセスの本質的な一部であり、考慮されなければなりません。さらに、検証メソドロジーを機能のみに制限する理由がありません。そのコンセプトは、パフォーマンス検証でも有効に利用できます。これについては、次のセクションにて紹介します。

デジタル検証はこの10年から15年の間に大きく変化し発展してきました。検証効果を向上させるために、機能性の複雑度が向上するのと同じ比率で、新しい言語、ツール、メソドロジーが考案されています。

MDV

メトリックドリブン検証(MDV)のメソドロジーは、今日、デジタル機能検証のデファクト・スタンダードとなっています。ユニバーサル・ベリフィケーション・メソドロジー（UVM [Universal Verification Methodology]）でさえも、標準のメソドロジー・フレームワーク（参考資料4）を定義します。核となる考え方は、検証ゴールがどれだけ達成されているのかを測定する、検証メトリックの分類と、実行されるそれら検証タスク自身です。検証メトリックと検証ゴールが、正しくかつすべて揃っていれば、特定の検証のタスクは、それほど重要ではありません。

検証メトリックとタスクの分類は、フォーマル検証や、アサーション・ベース検証（ABV）、エミュレーションなど、ランダム入力や異なる検証技術の組み合わせの可能性を広げます。いずれの検証アプローチを用いることにしても、メトリックは、検証ゴール全体と結び付けて、どれだけプロセスが達成しているかを示します。

MDVメソドロジーの1つの本質的な前提は、検証要求のすべてについて完全にかつ詳細な検証プランが定義されていることが必要となります。メトリックは、ゴールを定義する事と同じです。

UVM-MS

UVM メソドロジーは、デジタル機能検証を明確に対象としている一方で、このコンセプトは、ミックスシグナル・デザインにも拡張することが考えられます（参考資料5）。SystemVerilogとe言語の両方とも実数を扱い、それらを乱数化し、実数値のカバレッジを測定する機能を備えています。これは、デジタル検証をアナログ/ミックスシグナル領域に拡張するための1つの優れた手法といえます。

このアプローチは、検証タスクやチームが主にデジタル・セントリックで、かつ、いくつかのアナログ機能が含まれている場合に有効です。なるべくならば、パフォーマンスが得られる Real Number Model（RNM）を適用することが望ましいです。しかし、このアプローチは、アナログ・ツールや作業環境、さらに方法論が根本的に異なるため、アナログ・セントリックの検証をカバーするには適しているとは言えません。それゆえに、アナログ検証の問題も異なります。

上記は、プランベース検証がアナログに使えないということでしょうか。全くそのようなことはありません。アナログ・フロー向けに多くの改善が行われています。高位の視点から、異なる検証の問題と可能なソリューションは非常によく似ています。しかし、詳細な検証タスクの作業スタイルや作業環境が異なります。Virtuoso Analog Design Environment（この中には Virtuoso ADE L、XL、GXL、Explorer、Assemblerが含まれます）は、アナログ検証のデファクト・スタンダードな作業環境です。アナログ設計者は、これらの作業環境を用いて、シミュレーションを設定し、メジャーメントを作成し、仕様を与え、波形のデバッグなどを行います。歴史的に、アナログ検証のアプローチは、とても対話的な手法で行われています。アナログ設計の「アート」は、定式化することや境界を示すことで整理するのはしばしば難しいものがあります。経験のあるアナログ設計者は、波形結果が正しいか間違っているかを瞬時に判断することができますが、その一方で、的確な測定としてこの知見を取り出そうとすることは、退屈な作業となりえます。

それでもなお、アナログ検証はますます自動化されています。メジャーメントと仕様の定義は、文字通りすべてのデザインに利用され、アサーションやデバイス・チェックの使用も急速に広がっています。これらのチェック機能は、単純かつ簡単に書式化する作業が設計環境では自動化されながら、アナログ設計者が重要なかつ複雑な問題に注意を促す助けとなります。

Analog verification planning

構造化された検証アプローチの中心部は、検証要求とゴールの定義をする検証プランになります。検証タスク全体にわたって十分に定義されたゴールのみ形式化されたアプローチが可能であり、かつ、大局的な概観が得られます。各ブロックの検証の異なる面やデザインの構造に大まかに従いながら階層的なプランを構築することが効果的です。

検証プランは、次のようなさまざまな要因によって影響を受けます。

検証のすべてのさまざまな局面を取り扱うことが重要で、すべての仕様の値をリストすることでは不十分です。検証プランは、この工程に参加しているすべての関係者たちにより作成されるべき絶えず更新されるドキュメントです。プランの各部は、例えば仕様の値など、極めて明確に定義されるべきものです。同時に、プランのその他の部分は、人間の経験値や共通感覚に非常に依存するところもあります。プランは、検証サイクルの中で変更されることになります。いくつかの要求は、最初の手順の後に不足があるかもしれません。他にあまりにもアグレッシブな設定がある場合に、必要があれば削除や緩めることを後から行うことも考えられます。プランの構築は、プロジェクトの特定のニーズにチームを取り組ませるための有効なプロセスです。

1 つのプロジェクト用に作成されたプランは、少なくとも部分的に次のプロジェクトで再利用される可能性が高いため、再利用は検証プランニングの重要な項目です。

検証プランにおいて主に過小評価されている内容は、コミュニケーションです。純然たる事実として、設計者は同じ部屋の中で作業をしているのではないでしょうか。そして、検証ゴールを形式化するときに、しばしば解釈の違いについて明らかにされていないことがあります。特に、毎日一緒に作業をしていないグループに於いて、コミュニケーションの問題が生じていることがあります。

Virtuoso ADE Verifier

Virtuoso ADE Verifier は、Virtuoso IC6.1.7 から導入された新しい Virtuoso ADE プロダクト群の 1つです（参考資料6）。Virtuoso ADE ExplorerやVirtuoso ADE Assemblerで実施している検証はVirtuoso ADE Verifier で定義された全体をカバーする検証プランと結び付けることができます。Virtuoso ADE Verifier は、Virtuoso ADE Explorer や Virtuoso ADE Assembler で生成される結果情報にアクセスすることができます。これにより、Virtuoso ADE Verifier上でそれらの結果を要求仕様と結び付けます。Virtuoso ADE Verifier を用いることで、チーム全体の検証の具体的な実行状況を確認することができ、早期に問題になりそうな箇所を見つけることが可能となります。さらに、そのプロセスは書式化され、動作不良があればそれらの根本的な原因まで探索することができます。

Virtuoso ADE Verifier requirements

検証の要件は、異なる課題を広い範囲で取り扱います。プロジェクトで検証されるべき、ありとあらゆるものがリストされている必要があります。これらの要件が履行され、そして、それらは自動で追跡されているかどうか、つまり、プランでは手動でチェックされることの必要性は重要ではありません。

アナログに対する要件のプランの作成は、しばしば、温度や供給電圧値、および、プロセスばらつきなど、オペレーションのモードや環境条件にしたがって異なるブロックの仕様の値を決めることから開始されます。検証要件をさらにもっと拡大すると、プランで扱われる可能なことやすべきことといった、検証分野を広げることができます。例えば、歩留まりの目標値、デジタルのバスやレジスタのコンフィグレーション、内部仕様の値、常識的に前提として考えている値（安定性やノイズ・レベルなど）、機能記述モデルの要件、デザイン・フローの要件、ポストレイアウト・シミュレーションなどがあります。これらの要件のすべてがリスト化されている必要があります。

ゴールは、要件を収集し話し合いを開始させることです。そのため、検証プランの書式は重要ではありません。スプレッドシートや単純なテキスト・ドキュメントも、要件を収集しリスト化するには有効です。その後で、これらの要件は、Virtuoso ADE Verifierに取り込まれたり、直接入力したりすることで与えられます。図 1は、スプレッドシートに作成されたプランの例を表しています。このシートでは種々の要件や仕様の制限がリストされ、オーナーを記載し、コメントや色分けにより進行状況をトレースしています。

このプランと状況の情報を最新の状態に保つことは、大きな課題です。しかし、Virtuoso ADE Verifierならば自動的にこの処理を実行し、要件と実装の間の関係性を持つことができます。検証の状況は、自動的に最新のプロジェクト結果と同期が取られます。

Virtuoso ADE Verifier では、Setup タブから要件を直接入力することができます。組み込まれているエディター（図 2の画面の右側）により、詳細に仕様を規定することができます。画面の左側には、これまでに入力されたすべての要件の階層ツリー構造が表示されています。

要件は、スプレッドシートやCSVのテキストに記述された既存のファイルから取り込むことができます。さらに、要件をボトムアップとして作成することも可能です。これはVirtuoso ADE ExplorerやVirtuoso ADE Assemblerセルビューから、既に与えられている検証要件をVirtuoso ADE Verifierへ取り込みます。これらのセルビューをロードすることで、初期の要件が自動で生成されます。ボトムアップの要件は、取り込んだ後に、検証プラン全体に適合するように、編集や修正することができます。

既に述べているように、プランは常に更新されるドキュメントです。設計の非常に初期では、正しく完全で、かつ、実用的な要件の一群を作成することは殆ど不可能です。プランを変更し時間をかけて改善することを許容することが、より良いアプローチだと考えています。しかし、チーム全体が最新の期待値に対して注意を払うように、いつ、どのように、プランが変更されたのかを制御することは重要です。

Defining the measurement implementations for the requirement plan

一度でも、要件プランの設定が完了や、少なくとも手ごろな状態になったのであれば、次のステップは、これらの要件を実行するように、実装の作成、もしくは、参照を行うことです。ここで述べる実装とは、デザインに対してシミュレーション、測定、検証を行うVirtuoso ADE ExplorerやVirtuoso ADE Assemblerのセルビューのことです。（Virtuoso ADE ExplorerとVirtuoso ADE Assembler の詳細は、参考資料7、8 を参考にして下さい。）ユーザは、質問項目からライブラリ、セル、もしくは、セルビューを単純にブラウズし Virtuoso ADE Verifier に参照した内容をロードすることができます。これは、図 3のSetupタブの右側に示されています。仕様の値についてのテストと出力の測定は、ツリー構造内に表示されます。仕様の値についてのテストと出力の測定は、ツリー構造内に表示されます。

分かりきった手順は、要件と実装の間の関係を与えることです。この手順は、Virtuoso ADE Verifierにおいて、マッピング（mapping）と呼ばれています。ユーザは、1つもしくは複数の要件と1つもしくは複数の実装を選択し、それらをマッピングします。大半の場合は、1対1のマッピングとなります。マッピングにより、選択された実装によって特定の要件が実行されることを示します。

ここまでで、Virtuoso ADE Verifier 上でプランに登録されている仕様の値が実装の値と一致するかをもう一度確認することができます。一致しない場合には、ユーザに問題が伝えられ、対応策をとることができます。例えば、Virtuoso ADE Verifierでは、正しい仕様の値を実装に落とし込むことができます。もし、プランに与えられている仕様の値が正しくなかったのであれば、プランに値を持ち上げて修正することもできます。このコネクションにより、トップダウンの手法として、仕様の値を正式にトラッキングすることができます。その一方、異なる仕様の値を持つことが必要になる場合があるので、ツールの独自性を保っています。例えば、短期の実験をしたい場合や、同じ実装が違うデザインのコンテキストに用いられている場合などです。

Executing implementations

設計者は、既に利用可能な最新の結果を持っていることがあります。この場合には、直接 Virtuoso ADE Verifier からロードされた適切なヒストリー・アイテムを指し示すことができます。その他の場合は、結果が最新のものであることを確実にするために、Virtuoso ADE Verifierの中からシミュレーションを再実行するのが良いと考えられます。Virtuoso ADE Verifierユーザは、図 4に示したRunタブから、現在のシミュレーションを操ることができます。

Virtuoso ADE Assembler で名前がつけられたヒストリー・アイテムは、どのセットアップが実行されたのか、また、どの結果がロードされているのかの制御を可能にします。デフォルト・オプションは、“active”セットアップです。これは、最新のシミュレーションの設定が有効になることを意味します。設計者が実験をしたく、沢山のシミュレーションをインタラクティブに流すのであれば、activeのセットアップは良い設定とはいえません。この場合、“LatestResults”などのVirtuoso ADE Verifierで用いられているヒストリー・アイテム名にするべきです。Virtuoso ADE Verifier で、このステータスが選択されていれば、active セットアップの任意の変更や、作成された他のヒストリー・アイテムがVirtuoso ADE Verifier のステータスに影響を与えません。設計者がVirtuoso ADE Verifier ビューに追加すべき新しいステータスになったときのみ、それぞれのヒストリー・アイテムが“LatestResults”と呼ばれます。Virtuoso ADE Verifier は、その時にこの新しいステータスを参照します。

Virtuoso ADE Verifier にはコマンドライン・インターフェイスがあります。ユーザは、毎晩など予め決められた時間間隔で実装を実行する自動バッチ・リグレッションのスクリプトの設定が可能です。このアプローチにより、確実にリグレッション内のアナログ・ブロックの動作が期待通りに存在し、そして、間違いにより変更されません。

Virtuoso ADE Verifier に集約されたリグレッション設定によって、どれくらいの実装が実行されているのか、どれくらいの設計者がシミュレーションを実行するのかは、かなり多様と思われるので、明確な推奨を伝えるのは困難です。一般に、熟慮され安定したデザイン・ブロック、テスト、テストベンチに対して一か所にまとめられたリグレッション設定を与えることは理にかなっています。しかし、多くの変更と繰り返しが伴う能動的な設計や検証の段階や、非常に長いシミュレーション実行がある場合、要求に応じ設計者が対話形式でシミュレーションを実行することが、より効果的な場合もあります。

Virtuoso ADE Assembler は、インクリメンタル・シミュレーション（incremental simulation）と呼ばれる機能を持っています。この機能は、夜ごとに実行される不要なシミュレーションを避けるために、Virtuoso ADE Verifier でも利用することが可能です。事実上、デザインとシミュレーション設定のステータスは、シミュレーション結果に取り込まれます。もし、ツールが最新の結果と比較して、何も変化を検出できないときは、結果が最新だと見なして、この特定のシミュレーションをスキップしています。

Verification results

Virtuoso ADE Verifier は、検証のゴール、実装、その2つの間の関係のマッピング、検証を実行した結果にアクセスすることができます。この情報から、検証プロジェクトの詳細なステータスを提示することができます。図 5は、Virtuoso ADE Verifier のResultsタブを示しています。その構造は、前もって入力されている階層プランとなっています。赤と緑のアイコンは、各アイテムの状況を明確に示しています。パーセンテージの数値は、ツリー内の階層的な結果の合計を表しています。

大きな問題が一度見つかったとすれば、それらに対する対抗手段を講じることができます。Virtuoso ADE Verifier のフローは、検証が完了するまで繰り返し利用されます。これは、別名“verification closure”と呼ばれています。

Virtuoso ADE Verifier には、さまざまなレポート機能があります。ステータスをHTMLページとして取り込むことや、テキスト・レポートをメールとして送信することができます。検証ステータスをサードパーティー・ツールに取り込むのであれば、ステータス情報を共有できるようにXMLレポートを生成するか、または、SKILL APIにより使用するトラッキングツールに直接組み込むことが考えられます。

Reuse

すべての検証についてリストし、そして、時間をかけて適用されたすべての変化を取り込むような精密な検証プランを作成する労力は、最初の段階では能率的ではないように思えます。最初のプロジェクトでは、少ない構造化や、少ないフォーマル検証のアプローチが、より高速になります。しかし、検証メソドロジーでは、再利用することは重要な一面といえます。

ほとんどの設計は、繰り返しと変更から構成されます。おそらく、次の検証プロジェクトは、それより前のプロジェクトに類似していることと思います。前のプロジェクトに存在する検証プランは、優れたスタート・ポイントになります。比較的重要では無い様な修正をおこなうことで、有用な検証の仕組みを導入することができます。重要な検証タスクのトップでは、その再利用されたプランが、少量の理解しやすい検証アイテム、特に注目が必要な分野、検証プランニングに関して考えられるリソースのボトルネックについての情報を得ることもできます。