アナログ設計では、回路を最もよく理解している設計者自身がシミュレーションし、結果を確認することが多くあります。動作点や性能を確認するなら合理的ですし、問題があればその場で回路を修正できます。ただ、機能検証まで同じ人が担当すると、その回路知識とは別のところに弱点が生まれます。
2006年、Ken KundertとHenry Changは「Verification of Complex Analog Integrated Circuits」で、アナログ検証を設計から独立させる理由の一つとして、仕様の解釈を挙げています。検証担当は設計者からある程度距離を置き、主に仕様を基準に仕事をします。設計者がテスト追加を提案しても、検証環境を変更するかどうかは検証側が判断する、という役割分担です。[1]
問題になるのは、回路とテストが同じ仕様解釈から作られる場合です。設計者が仕様を誤解し、その解釈が回路にもテストにも入れば、両者を比較しても矛盾は出ません。設計と検証を分けることで、仕様から回路を作る経路とは別に、仕様からモデルやテストを作る経路を持てるようになります。
テストを増やしても見つからない間違いがある
仕様に曖昧な箇所があれば、設計者は何らかの解釈をして回路へ落とします。同じ設計者がテストを書くと、その解釈はテスト側にも入りやすくなります。回路もテストも同じ前提で作られていれば、両方が仕様から外れていても比較結果だけは一致します。
Kundertらは、要求仕様の誤解が設計とテストの両方へ入れば、その不具合は検証で見つからないと指摘しています。[1] 回路の実装を見て期待動作を作るだけではなく、設計者とは別に仕様を読み、モデルやテストへ落とすことで、同じ読み違いが両方へ入る可能性を下げます。
これはカバレッジ不足とは別の問題です。確認していない条件があるならテストを増やせますが、確認の基準そのものが間違っていれば、テストを増やしても解決しません。設計と検証を分けることには、確認する条件を増やすのではなく、仕様を解釈する経路を増やす意味があります。
回路を調整可能にすると、確認する状態も増える
2000年代には、PLLやADCでも10〜30本程度のデジタル制御を持ち、PMUやRFトランシーバでは数百本になる場合がありました。省電力モード、自己キャリブレーション、誤差補正も増えています。ゲイン、帯域、雑音などを確認するだけでなく、設定、起動順序、モード切り替えまで検証しなければならなくなっていました。[1]
当時は、機能を外部から制御できるようにし、抵抗、容量、電流源、電圧源まで調整可能にする設計が使われていました。製造後に設定を変えたり、プロセスばらつきを調整で吸収したり、問題をファームウェアから補正したりできる一方、調整項目を増やすほど制御ビット、モード、状態遷移も増えます。論文でも、この自由度が新しい設計上の不具合を生む余地になると指摘しています。[1]
PLLなら、位相雑音やロック時間に加えて、次のような条件も確認対象になります。
- 起動時にどの設定が有効になるか
- キャリブレーション中の設定変更をどう扱うか
- 動作中に周波数やモードを切り替えられるか
- 省電力状態から正しく復帰できるか
- 複数の制御が重なったときにどう動くか
アナログ回路を調整可能にすることで性能ばらつきや設計余裕を扱いやすくした一方、その自由度を確認する仕事が増えました。アナログ検証の拡大には、回路規模だけでなく、デジタル制御によって仕様の状態空間が広がったことも効いています。
回路ができる前に検証モデルを作る
Kundertらが示した開発手順では、アナログ検証リードが参加するのは回路完成後ではありません。システム側とアナログ設計リードがアーキテクチャを決めると、ブロック設計者より先に検証リードが入り、各ブロックのVerilog-AMSモデルを作ります。この段階では細かな二次効果より、機能、制御の流れ、インターフェースをモデルに入れることが優先されています。[1]
各ブロックのモデルを組み合わせてトップレベルをシミュレーションできる状態になったところで、ブロック設計者が参加します。ブロック設計が始まる前に、仕様を実行できるトップレベルモデルを用意する順序です。論文ではこれをサインオフに使える「実行可能な仕様」と位置付けており、文章の仕様書だけでなく、実際にシミュレーションできるモデルをブロック設計者へ渡しています。[1]
| 段階 | 作るもの | ここで固めるもの |
|---|---|---|
| アーキテクチャ検討 | 仕様、ブロック構成 | 要求、機能分割 |
| 検証リード参加 | Verilog-AMSモデル、トップレベルモデル | 機能、制御、インターフェース |
| ブロック設計 | トランジスタ回路 | 回路性能、実装 |
| 統合 | モデルと回路を組み合わせた構成 | 状態遷移、ブロック間動作 |
この順序では、検証モデルは完成した回路の簡易版ではありません。回路実装とは別に、仕様を具体化した成果物です。回路とモデルが食い違ったときにモデルを回路へ合わせるだけではなく、どちらの仕様解釈が正しいのかを確認する余地が残ります。
同じRNMでも、何から作ったかで役割が変わる
現在のAMS検証では、トランジスタ回路をシミュレーションして振る舞いを調べ、そこからRNMを作ることがあります。重い回路を高速なモデルへ置き換えてチップレベルの回帰テストへ使う場合には有効で、回路とRNMを比較すれば、抽象化の誤差やモデル実装の抜けも確認できます。
ただし、回路に仕様の読み違いがあり、RNMもその回路を観測して作った場合には、両者が同じ読み違いを共有する可能性があります。RNMと回路がよく一致していることは、RNMが回路をよく再現していることを示しますが、その回路が仕様通りであることまでは示しません。2006年の手法でモデルを回路より先に作っていたことは、この点で意味があります。
| モデルの起点 | 主な役割 | 見つけやすい問題 |
|---|---|---|
| トランジスタ回路 | 回路を高速に置き換える | 抽象化の誤差、モデル実装の抜け |
| 仕様 | 機能を実行可能な形にする | 仕様解釈、機能、インターフェースの食い違い |
同じSystemVerilogやVerilog-AMSで書かれたモデルでも、検証上の役割は同じではありません。回路の代用品として作ったモデルは回路を再現することが目的ですが、仕様から作ったモデルは回路とは別の解釈を残すことができます。モデルの精度だけでなく、何を根拠に作ったモデルなのかが、検出できる問題の種類を決めます。
仕様を二つの経路で具体化する
2006年に提案されたアナログ検証では、検証担当をブロック設計より前に参加させ、仕様からモデルとテストを作っていました。回路が完成してからその回路を見て検証環境を作るのではなく、回路とは別に仕様を具体化する経路を先に用意しています。だからこそ、回路とテストが同じ間違いをする可能性を減らせます。
この考え方では、検証の独立性は担当者が別であることだけでは決まりません。設計者と検証者が別の部署にいても、検証側が完成した回路だけを見てモデルと期待値を作れば、情報の流れはほぼ一本です。逆に、仕様から直接モデルや判定条件を作る部分を残せば、回路実装との食い違いを検出する別の経路になります。
アナログ検証エンジニアが必要になった理由を、増えたシミュレーションを設計者から引き受けるためと説明すると、この部分が抜けます。デジタル制御によって状態が増えたアナログ回路に対して、仕様を設計とは別にモデルやテストへ変換し、その結果を回路実装と突き合わせる。テストの本数を増やすだけでは見つからない不具合に対して、仕様の解釈そのものを二重化することが、独立したアナログ検証の役割になっています。