2025年2月、AccelleraからUVM-MS 1.0がリリースされました。UVMをアナログ／ミックスドシグナル検証へ広げるための正式な標準で、UVMからアナログ信号を駆動・観測する方法や、再利用可能な検証部品を作るための仕組みが定義されています。MS Bridge、MS Proxy、Bridge Coreといった構成も、この標準で明確になりました。[1]

ただし、UVM-MSという名前自体はもっと前から使われていました。CadenceとLSIがDVCon 2011で発表した「Metric Driven Verification of Mixed-Signal Designs」には、次の記述があります。

We have named the new methodology Universal Verification Methodology – Mixed-Signal, or UVM-MS.

現在のUVM-MS 1.0とは別物で、当時CadenceとLSIが提案していた検証手法につけた名前です。それでも、UVMが登場した早い時期から、アナログ検証への適用も並行して考えられていたことが分かります。[2]

2011年のUVM-MS

論文の内容を見ると、名前だけが同じだったわけでもありません。当時すでに、現在のAMS検証でも見かける内容が多く含まれていました。

  • アナログ入力も含めてランダムに条件を振る
  • 結果を自動判定し、カバレッジを集める
  • SPICEでは大量のテストを回せないため、AMSモデルやRNMを使う
  • 抽象モデルは元の回路と比較して確認する
  • ブロックで作った検証環境をSoCでも再利用する

当時のアナログ検証では、人がシミュレーション波形を確認するやり方がまだ一般的でした。論文では、そこへデジタル検証で使われていたランダムテストや自動判定、カバレッジを持ち込み、実際のLSI設計で試しています。テストベンチも、シーケンスなどを扱う上位の検証コードと、アナログ信号を生成・観測する処理を分けた構成でした。下側にはVerilog-AMSが使われています。[2]

現在のUVM-MS 1.0とは実装が大きく異なります。それでも、AMSでUVMを使うときに何をしたいかは、この頃には具体化されていました。

標準がないまま、それぞれ使われていた

2017年のDVConでは「Connecting UVM with Mixed-Signal Design」という論文が発表されました。この時点でUVMを使ったAMS検証手法はすでに複数存在していましたが、UVM環境とミックスドシグナル設計を接続する標準方式はありませんでした。[3]

RNMならUVMと比較的そのまま接続できますが、Verilog-AMSでelectricalポートを使う場合は別の仕組みが必要です。この論文でも、UVMとVerilog-AMSモデルを接続するいくつかの方法が扱われていました。[3]

2019年にAccelleraがUVM-AMSの標準化を始めた際も、既存方式には似た機能がある一方で実装が異なると説明していました。SystemVerilogとVerilog-AMSを一緒に使う際の制約に対し、それぞれが異なる方法で対応していたためです。標準化前にAMS向けUVMが存在しなかったのではなく、似た機能を持つ方式がすでに複数並立していた状態でした。[4]

経緯を簡単に並べると、次のようになります。

年 内容
2011 Cadence/LSIが「UVM-MS」を提案
2017 AMS向けUVMは複数あるものの、接続方法に標準がないと報告
2019 AccelleraがUVM-AMSの標準化を開始
2025 UVM-MS 1.0をリリース

ここでいう14年間は、標準化作業そのものにかかった時間ではありません。Accelleraが標準化に動いたのは2019年で、それ以前は各社が自分たちの環境に合わせてAMS向けのUVM検証を作り、使っていた時期です。Working Groupも、UVMからミックスドシグナルのnetを駆動・観測する方法や、再利用可能な検証部品を作る枠組みの標準化を目的としていました。[4]

2025年に共通化された接続部分

UVM-MS 1.0では、UVMとアナログ側の間にMS Bridgeを置き、UVMからはMS Proxyを介して操作します。実際の信号操作やデータ型の変換はBridge Coreが受け持つため、RNMとVerilog-AMSでモデルの作りが違っても、その差をUVM側まで持ち込まずに済む構成です。[1]

それまで各社で作られていたものと比べると、違いはこの辺りです。

標準化前 UVM-MS 1.0
接続部分を環境ごとに実装 MS Bridgeとして共通の構成を定義
RNMやVerilog-AMSごとの差を個別に処理 モデル側の処理をBridge Coreで扱う
UVMからの操作方法も実装に依存 MS Proxyを介したAPIを用意

この部分が環境ごとの実装になりやすかったのは、両側で扱っているものが大きく異なるためです。

  • UVM側ではクラス、シーケンス、トランザクションを扱う
  • アナログ側では電圧、電流、連続値を扱う
  • モデルもRNM、Verilog-AMS、SPICEで事情が変わる

2011年の時点でも、上位の検証コードとアナログ信号を扱う処理は分けられていました。2017年には、その接続方法が標準化されていないことが明示的な課題として取り上げられます。その後、2019年にAccelleraが既存方式の整理を始め、2025年のUVM-MS 1.0ではMS BridgeやMS Proxyとして共通化されました。[2]

UVM-MS 1.0で揃ったもの

2011年のUVM-MSと2025年のUVM-MS 1.0は同じものではありません。ただ、ランダムテストやカバレッジ、RNMを使った回帰テストなど、AMSでUVMを使うための基本的な考え方は早い時期からありました。その後も各社は、それぞれのツールやモデルに合わせた実装を続けていました。[2]

一方で、UVMの検証環境とアナログ回路を接続する部分は、RNM、Verilog-AMS、SPICEなどの違いの影響を直接受けます。2017年になっても接続方法には標準がなく、2019年のAccelleraも、似た機能を持つ方式の実装が異なる状態から標準化を始めました。[3]

UVM-MS 1.0は、2025年になって初めてAMSでUVMを使えるようにした標準ではありません。AMS検証でやりたいこと自体は早い時期から共有されており、長く各社ごとの実装として残っていた接続部分を共通化したのがUVM-MS 1.0です。[1]