アナログ、ミックスシグナル設計の黒魔術に光をあてる
第1部: ミックスシグナル検証

今年はミックスシグナル回路の検証という新しくて「古い」問題に取り組んでみましょう。そもそも検証は重要な問題でしたが、高度化した統合やミックスシグナル・チップ設計とシステム設計の接近に伴い、その重要度は増すばかりです。設計リスピンのもっとも一般的な原因は、検証で設計の問題を特定できない点に起因しています。よく引き合いに出されるのが、65nm設計リスピンの50%以上がミックスシグナル機能の不具合によるもので、修正に何億円もかかるといったような話ですが、その結果、ダイ全体に対するミックスシグナル回路の面積は10%程度しかないにもかかわらず、その設計労力はSoC設計全体の50%にもなってしまうことになります。

この記事では、課題の特定と検証メソドロジーが進化しなければならない理由について考察します。検証課題の説明のために、SoC全体の設計ではなく、電源管理IC設計をモチーフとして使用します。電源管理IC (PMIC) 設計とはいったいどのようなものでしょうか。ポータブル機器の設計者は、できるだけ少ないチップ数で製品を実装しようとしますが、熱およびクロストーク対策により、理想的な場合でもRF、アプリケーション・プロセッサー、PMICの3種類のチップが必要となります。ポータブル製品でのPMICは、電力管理機能、バッテリー充電、その他リアルタイム・クロックやデータコンバーターをはじめとするシステム管理機能を統合したものとなっています。これらの機能をすべて一つのダイに統合すると、製品設計者はフォームファクターの縮小、部品数の削減、ロバストな設計といった統合によるあらゆる伝統的メリットを享受することができるようになります。このため、以前は個別であった機能を一つの電源管理ICに統合することは、システム設計者にとって大きなメリットがありますが、このようなPMIC設計はミックスシグナル設計者に課題を突きつけることになります。基板レベルでプロトタイプを用いて行われていたかつてのシステム・レベル検証の多くは、今やミックスシグナル設計者がテープアウト前に実行しなければならなくなっています。ポータブル製品にはディスプレイやカメラも含まれていますので、ミックスシグナル設計者の実際の課題はさらに大きなものとなっています。このような状況ですので、課題の特定と検証メソドロジーが進化しなければならない理由は、端的に言えば設計要件が進化しているからだということになります。

次に、検証課題についての理解を深めるためにもう少し詳しくPMICについて見てみましょう。図1は、ポータブル・アプリケーション向けにPMICに組み込まれるような機能の例です。上述のとおり、従来は一般的なディスクリート・コンポーネントで実装されていたような電源管理機能をはじめとする各種多様な機能があります。

図1: PMICの例図1: PMICの例

PMICには動作検証が必要なモードが100以上あるかも知れませんし、一つの動作モードでも、例えば電源リセット後に参照電圧発生器やバイアス・ブロックがちゃんと起動したかどうか、参照電圧発生器とバイアス・ブロックが起動した場合内部電圧発生器が起動したかどうか、内部電圧発生器が正常起動した場合コントローラーが正常な起動シークエンスをとるかどうか、といったようなことを確認するためにバッテリーの充電チェック、バッテリーの充電、ラジオの起動といったような、複雑なイベント連鎖を発生させる必要がある場合も考えられます。さらに、各モードの正常動作を検証するため、モード間の切り替えについても検証する必要があります。例えば、アプリケーション・プロセッサーが動的電圧・周波数制御 (DVFS) を利用してバッテリー消耗の最小化を図る場合、各モード間の切り替えの検証が必要となります。グラフィックス処理の重いゲームの動作では、2種類のDC-DCコンバーターでCPU速度に対応する必要があるかも知れませんし、テキストメッセージを送信するだけの場合には低電圧出力のDC-DCコンバーターが一つあれば十分かも知れません。このように異なるモード間の切り替えも検証する必要があります。最後に、設計プロセスの後期で見つかった問題は修正コストが高くなってしまうという点を挙げなければいけません。このため、設計に対して早期段階から頻繁に検証を行う必要があります。以上を総括すると、ミックスシグナルの設計者は、以前に比べてはるかに大規模で、より多くの機能が統合された、複雑な動作をする設計の検証を行う必要があるということになります。

ではここで、設計検証手法の現状について考えてみましょう。アナログ、ミックスシグナル設計者は、従来仕様のコンプライアンスマトリックスを用いて検証を管理しようとしてきました。設計プロセス中で、仕様マトリックスは設計レビュー会議で定期的にチェックされ、検証の正しい実行と完全性を保証するようにします。仕様コンプライアンスのチェック・プロセスを自動化するために、2006年のIC61のリリース以来Virtuoso ADE-XLが利用可能となっています。ADE-XLは、仕様コンプライアンスの検証に必要なテストベンチすべての検証を管理しますが、コンピューター資源の効率的利用のためのシミュレーション管理も含みます。シミュレーション結果は仕様値と比較され、仕様値に満たない場合にはハイライト表示されます。仕様が設定されていない項目は、波形が保存されて設計者が目視による結果の確認によって設計が所定動作をしているかどうかを判断することができます。ADE-XLはまた、設計レビュー用に結果をまとめるデータシートを自動生成することもできます。コンプライアンスマトリックス生成プロセスの自動化によって、ADE-XLは設計者の生産性を大幅に向上します。

ここでPMICに戻って、コンプライアンスマトリックスが設計検証にベストな方法かどうかを考えてみましょう。PMIC中の個々のブロックや機能に対しては、コンプライアンスマトリックスは検証として十分だといえます。この手法は長年にわたって使われ続けており、そのロバスト性は立証済みですが、この手法をPMIC検証に適用するにはいくつかの制限点もあります。PMIC検証にこの手法を適用する際の課題について考えてみましょう。最初の課題としては、仕様のコンプライアンスマトリックスがダイレクテッドテスト・ベースの検証方法である点が考えられます。ここで、ダイレクテッドテストとういことは、設計のコンプライアンスをチェックするのに、既知の仕様から始めるということです。テスト前にすべての起こりうるケースを予見して、これらのすべてに対して仕様を作成できればこの方法には何の問題もありませんが、一般的にはいろいろな理由によってこのようなことはできません。2番目の問題は、従来の検証手法ではトランジスター・レベルのシミュレーションが必要なパラメトリック性能に着目しがちで、すべてをSPICEでシミュレーションすることになり、長時間を要するため手間がかかってしまい経済的とはいえなくなってしまいます。効率性を上げるために、PMIC設計にはスイッチングDC-DCコンバーター、チャージポンプ、スイッチング・レギュレーターを含みますが、性能の特性抽出のためには長時間のトランジェント・シミュレーションが必要となります。これらの要素により、長時間のトランジェント・シミュレーションが必要となる非常に正確なシミュレーションはテープアウト時の検証時間が長くなってしまいます。検証項目の増加とテープアウト時のシミュレーション時間の増大の組み合わせにより、設計者がスケジュールの短縮のために検証項目を省略してしまうことになってしまいます。最後の課題は、性能評価には依然として波形の目視が必要であるという点です。 波形による回路特性を理解するための手操作での検査には長い歴史がある一方、手操作による検査は結果の自動評価を困難なものとします。このため、検証のためのコンプライアンスマトリクス使用はブロックや機能検証には強力なツールではありますが、システム・レベルの検証に適用することは困難です。

検証はデジタル設計者にとっても問題で、この問題に悩まされ続けてきた結果、大規模な数十億にも及ぶゲートの設計を検証するための方法を開発、形式化しました。手法全体の概略は “Mixed-Signal Methodology Guide, Advanced Methodology for AMS IP and SoC Design, Verification, and Implementation” という本で説明されています。ここでは、手法を理解する上で有用ないくつかの主要な概念について触れることにします。最初の理解としては、システム・レベルでは、パラメトリック性能ではなく機能の検証に集中する必要があるということです。言い換えれば、各ブロックが正常に動作する場合、システム全体も期待通りに動作するだろうかということになります。機能検証に集中することにより、抽象化のレベルを上げることとなり、トランジスター・レベルではなくビヘイビア・モデルを用いたシミュレーションを実行することになりますが、ミックスシグナル設計者はアサーション・ベースの検証という新しいツールを手に入れることとなります。

アサーションは、仕様や設計意図のいろいろな局面を実行可能な形式で記録し、エラーを発生源の近くで検出してエラーとカバレッジ情報の両方を報告するシミュレーション中の監視装置として機能します。
- “Mixed-Signal Methodology Guide” より引用

Property Specification language (PSL) やSystem Verilog Assertions (SVA) のような検証言語は、ミックスシグナル設計の検証に対応できるように拡張されました。アサーションを利用できるようになったため、設計者はカバレッジドリブン検証を行うことができるようになりました。カバレッジドリブン検証では、アサーションのトリガーは追跡、測定されます。アサーションがトリガーされないと、テスト条件が追加で必要になることがあり、正常動作しない場合には当然のこととして問題を修正する必要があります。この結果、設計品質と検証の網羅性の両方を客観的に評価するツールを手に入れたことになります。この検証手法をさらに詳しくお知りになりたい場合には、INCISIVE Verification Kitライブラリー中のMixed-Signal Metric Driven Verificationワークショップをご覧ください。以上をまとめると、ビヘイビア・モデルやアサーション等を用いて、ミックスシグナル設計にデジタルの検証手法を適合させることによって、大規模でより複雑な設計の検証が可能となります。

ミックスシグナル検証はコンプライアンスマトリックス・ベースの検証に取って代わるのだろうかと思われる方がいらっしゃるかも知れませんが、答えはノーで、これら2つの手法はお互いに補完関係にあります。アナログやミックスシグナル・ブロックやその機能の検証で、例えばオペアンプやデータコンバーターでは、パラメトリック性能に着目するため、コンプライアンスマトリックス・ベースの検証が適切となります。これに対して、データコンバーターがより大きな設計の一部として組み込まれている場合には、システム全体の機能検証が目的となりますので、ミックスシグナルのメトリクスドリブン検証の出番となります。この2つの手法を組み合わせることにより、設計検証に対してより包括的なソリューションを実現することができます。これは、道具箱から目的に応じてハンマーやねじ回しといった異なる道具を取り出して使うことに似ているといえます。

以上、今回の記事では設計者が直面している設計検証の課題について考察を加え、伝統的なアナログのコンプライアンスマトリックス・ベースの検証メソドロジーおよびパラメトリック検証への応用について述べました。続いてミックスシグナルのメトリクスドリブン検証および機能検証への応用や、シミュレーション高速化のためのビヘイビア・モデリング、検証自動化のためのアサーション、設計回路の動作可否や検証の網羅性を判定するカバレッジ解析といったメソドロジーに関するいくつかの主要なポイントについても触れました。次回はビヘイビア・モデリングについて、検証の高速化という観点とともに考察してみたいと思います。

システムソリューション部
Art Schaldenbrand

Page Top