News and Views 2012 Spring / Vol. 1: 上流設計&組込み

UVM導入のコストを抑えるソリューション - UVM Express

UVMは、標準化団体であるAccellera(2011年にOSCI-Open SystemC Initiativeと統合されAccellera Systems Initiativeと改名)により策定された機能検証のメソドロジ、Universal Verification Methodologyの略称です。メンター・グラフィックスが発表したUVM ExpressはUVM導入の敷居を下げ、専任の検証チームを持たない組織であっても、設計者自らがUVMを導入することが可能となるように構成されています。ここではUVM Expressについて、その背景や段階的に導入するための手順について簡単に説明します。

UVMはあまりにも膨大になっている?

UVMは、まったく何もないところから始まって標準化されたものではありません。標準化にあたっては、既存の検証メソドロジを1つ選択し、それを基盤にするところから手続きを開始しました。その基盤となったメソドロジが、OVM(Open Verification Methodology)です。このOVMもまた、他の検証メソドロジを基準にして開発されています。それがメンター・グラフィックスのAVM(Advanced Verification Methodology)とケイデンス・デザイン・システムズのURM(Unified Reuse Methodology)です。ここで、AVM、OVM、UVMについて、その規模を簡単に比較してみます。

メソドロジ クラス数 ファイル数 行数 印刷ページ数
AVM-3.0-update-4 106 38 6,589 61
OVM-2.1.2- 236 106 37,786 293
UVM-1.1a 316 134 67,298 495

もちろんベースクラスのライブラリ数が多い方が、検証環境の構築方法の選択肢は増えるかも知れません。しかし、あまりに多すぎるベースクラスを覚えて使いこなすのは、時間(コスト)のかかることです。特に試行錯誤を繰り返しながら検証環境を構築していくには、膨大な規模と感じる方も多いことでしょう。機能検証チームが組織されている場合であっても、UVM導入にあたっての時間、工数、コストが大きくなる可能性もあります。

UVM ExpressによるSystemVerilog検証環境の導入

UVM Expressは、UVMの導入のための最初のステップを提供します。事前に学習すべき項目を極力減らし、導入コストを抑えることを目的として開発されています。それによって得られるメリットは、テストシナリオの表現やデバッグにおける抽象度の改善、機能カバレッジや制約付きランダムテスト生成による効率改善です。UVM Expressによる手順を踏むことにより、再利用可能なコードを記述でき、そのステップを繰り返すことによってUVM導入を実現することが出来るようになっています。UVM Expressを使用することはUVMを置換えてしまうわけではありません。むしろUVMの一部として構成され、段階的に導入を進めることにより、それぞれのステップで明確な価値を蓄積していくことができます。

Step-1: BFM内のタスクを使ってテストを記述する

図1. BFM 図1. BFM
図2. BFM実装例

UVM Expressの最初のステップは、BFM(Bus Functional Model)を使います。BFMが行うことは、信号の管理と、テストベンチから信号に対するインタフェース機能の提供です。例えばBFMは、バスを構成するすべての信号を管理し、そして「read(address, data)」というタスクを持ち、実際にタスクが呼出された際にはバスに対して「read」コマンドを発行し、指定したアドレスから読まれたデータを返す、などの処理を実行します。例として以下に部分的なコードを示します。

interface abc_if(input wire CLK);
reg RST;
reg VALID;
reg READY;
reg RW;
reg BURST;
reg [31:0] ADDR;
reg [31:0] DATAI;
wire[31:0] DATAO;
task reset();
task read( bit[31:0] addr, output bit[31:0] data);
task write( bit[31:0] addr, input bit[31:0] data);
task burst_read( bit[31:0] addr, output bit[31:0] data[4]);
task burst_write( bit[31:0] addr, input bit[31:0] data[4]);
task monitor(output bit transaction_ok, output bit rw,
output bit[31:0] addr, output bit[31:0] data[4],
output bit burst);
endinterface

「read」というタスクは時間の消費を伴います。すべてのテストはBFMを介して行われるので、ピンに対して直接操作をすることはありません。BFMは、SystemVerilogの「interface」構文を用いて実装します。「interface」は信号の情報と信号を操作するためのタスクで構成します。

BFM内のタスクはそのインタフェースがサポートするトランザクションを形作るもので、例えば「read()」、「write()」、「burst_read()」、「burst_write()」などがそれに相当します。これらのタスクを呼出すことでテストを生成しますが、BFMの外側から信号に対してアクセスが発生することはありません。