仮想インターフェース　(Virtual interface)

概要

名前からするとC++仮想関数の類と想起されますが、それとは全く関係ありません。

-もし私が名前をつけるとするなら、実行時インターフェースインスタンス参照/変数、というネーミングにするでしょう。　

ハードウェアは、生まれたり死んだりしない、コンパイル時に全てが決まる静的な（Static)世界です。

-それ故に論理合成可能とも言えます。

一方、オジェクト指向下の検証環境では、クラスを中心とする動的（Dynamic)な世界になります。これは、C++やJAVA等の、オブジェクト指向プログラミング言語の世界と同じです。これを、つなぐ唯一の橋が、Virtual　Interfaceという構図になっています。

Verilog　HDL下においては、テストベンチの側もStaticに作っていました。つまり、テストベンチの側を取り替えて別なコンフィグレーションで走らせたいときは、別なプロジェクトにして、`ifdef や、$value$plusargs等を使い、ソースを書き換えながら対応していました。逆に言うと、接続を変えるには、何らかのソースの書き換えが必要となっていました。この問題の本質は、コンパイル時に全ての接続が決まってしまうことにあります。もし、テストベンチとハードウェアを切り離し、テストベンチの側は、対象のハードウェアとは別に、独立した形で開発できれば、全てのコンフィグレーションを自由に接続して、一回のRUNでテストを網羅できることになります。加えて、オブジェクト指向で開発することによって、ハードウェアに依存しないあるいは、依存度が少ない検証部品を活用することができます。次回の別プロジェクトでは、再利用できる部分が多く、結果として、効率アップが期待できる..テストベンチの側をダイナミックにする要請は、こんな背景ではないかと思います。

ですから、一回限りのハードウェア検証で今後、検証の機会がない、ということであれば、UVM等の検証メソドロジーの上に検証環境を構築する必要はないかもしれません。新しいパラダイムで、検証環境を構築するのは、パラダイムの理解を含めて時間のかかることですから。

virtual interface の例- コンパイル時と実行時の違い

下14,15行目で、interfaceのインスタンス化を行っています。
このインスタンス名を、30,31行目で、virtual interface変数にコピーしています。このvirtual interface変数は、10行目で
宣言していますが、初期状態はnull です。interfaceのインスタンス名を代入して、初めて使えるようになります。

10行目の宣言は、interfaceを省略して、　virutal if1 v1,v2 だけでも可能です。ここで注意がいるのは、innterface型名、ここでは、if1　が必要になることです。これは、virtual が付かない宣言と決定的に違うので注意してください。つまり指定interface型だけが代入できるということです。

30、31行目では、実は、スコープIF1/IF2が指す内部オブジェクトのポインタが渡されます。moduleポートで、interfaceのインスタンスを渡していたのとの違いは何でしょうか？決定的に異なるのは、moduleポートは、静的な結合でありどのスコープが渡されたかは、コンパイル時に決定され実行時に変更することはできないことです。一方v1/v2は、コンパイル時は、null 状態で初期化されていて実行時に変更することが出来ます。

33行目で、これをさらにtaskに渡していますが、渡された側のtaskにとっては、もはや特定のインスタンスではないことに注意してください。一旦virtual interface変数にコピーされれば、後は、例えば、taskで、汎用的な処理を書くことが出来ます。

module top;

        bit clk=0;//CLOCK元
        always #10 clk=~clk;

        interface if1(input clk);
                int counter=0;
                bit enable=0;
                always @(posedge clk) begin
                        if (enable) counter<=counter+1;
                end
        endinterface:if1

        if1 IF1(clk);//interfaceのインスタンス化
        if1 IF2(clk);//interfaceのインスタンス化


        program ;//暗黙インスタンス化
                virtual interface if1 v1,v2;//初期状態はnull

                task automatic random_walk(virtual interface if1 V,int rep);//automatic上書き防止
                        repeat(rep) begin
                                #($urandom_range(7,1)*100);//program 領域なのでraceの心配無用
                                V.enable=~V.enable;//program 領域なのでraceの心配無用
                        end

                endtask

                initial begin
                        v1=IF1;//インスタンス名を代入 代入して初めて使える
                        v2=IF2;//インスタンス名を代入 代入して初めて使える

                        //シーケンシャル
                                random_walk(v1,10);
                                random_walk(v2,10);

                        //Go パラレル   
                        fork 
                                random_walk(v1,20);
                                random_walk(v2,10);
                        join
                        //implicit $finish call
                end                                     

        endprogram      


endmodule :top;

ここで、上記をクラスを使ったものに書き換えてみましょう。一旦、virtual interface変数にコピーしまえば、後は、それを参照するだけの処理が多いのでクラス生成時に引数として渡してしまうのが常套手段です。

module top;

        bit clk=0;//CLOCK元
        always #10 clk=~clk;

        interface if1(input clk);
                int counter=0;
                bit enable=0;
                always @(posedge clk) begin
                        if (enable) counter<=counter+1;
                end
        endinterface:if1

        if1 IF1(clk);//interfaceのインスタンス化
        if1 IF2(clk);//interfaceのインスタンス化


        program ;//暗黙インスタンス化

                
        
                test_driver td1,td2;//クラスハンドル宣言

                initial begin
                        td1=new(IF1);//クラス生成
                        td2=new(IF2);//クラス生成
                        $monitor("IF1.enable =%b IF2.enable=%b %t",IF1.enable,IF2.enable,$time);
        

                        //シーケンシャル
                                td1.random_walk(4);
                                td2.random_walk(4);

                        //Go パラレル   
                        fork 
                                td1.random_walk(3);
                                td2.random_walk(6);
                        join
                        //implicit $finish call
                end                                     

        endprogram      


endmodule :top

少しだけ、上よりも読み易くなりました。22行目で、クラスtest_driver のハンドル　td1,td2を宣言しています。
クラス生成時、25/26行目で、インスタンス名を渡しています。

クラスの定義は、下です。このクラスは、インターフェース型 if1を指定してはいますが、特定のインスタンスについての処理ではありません。
このようにして、ハードウェアとテストベンチの分離を行うのがSVスタイルです。

	class test_driver;
			virtual interface if1 v1;//初期状態はnull

			function new(virtual interface if1 v_);//class コンストラクタで初期化するのが常套
				v1=v_;
			endfunction
		

			task  random_walk(int rep);//class のtask/functionは、default automatic
				repeat(rep) begin
					#($urandom_range(7,1)*100);//program domain なのでraceの心配無用
					v1.enable=~v1.enable;//program domain なのでraceの心配無用
				end

			endtask

	endclass :test_driver

***** Veritak SV32 Engine Version 435 Build Feb  9 2013*****

IF1.enable =0 IF2.enable=0                    0
IF1.enable =1 IF2.enable=0                  500
IF1.enable =0 IF2.enable=0                  600
IF1.enable =1 IF2.enable=0                 1000
IF1.enable =0 IF2.enable=0                 1300
IF1.enable =0 IF2.enable=1                 1600
IF1.enable =0 IF2.enable=0                 2300
IF1.enable =0 IF2.enable=1                 2900
IF1.enable =0 IF2.enable=0                 3300
IF1.enable =1 IF2.enable=1                 3500
IF1.enable =0 IF2.enable=1                 3600
IF1.enable =0 IF2.enable=0                 3700
IF1.enable =1 IF2.enable=0                 3800
IF1.enable =1 IF2.enable=1                 4300
IF1.enable =1 IF2.enable=0                 5000
IF1.enable =1 IF2.enable=1                 5200

---------- シミュレーションを終了します。time=5700ns

上のinitial の部分は、さらにwrapper クラスを作ることで、少しだけ読み易く出来ます。

上をもう少し、ジェネリックな形にしてみましょう。インターフェースのインスタンス数をNUM_OF_INSTANCESとして、
トップmoduleは、以下のようになります。SVらしい体裁になってきました。　

program側に立ってみると、クラスにテストは、押し付けて（委譲して）、クラスのインスタンス宣言化と生成、テストの起動だけを行っています。自分がテストの流れをコントロールすることはありません。

クラス側は、仕事をどんどん押し付けられる側です。仕様変更が来ることは、予想できるので、できるだけ汎用化しておいて、変更に耐えられるように構築しておこう、という考え方です。このため、クラスの中身は、抽象化の方向にあり読む側からみると難しくなるように感じられます。

クラスは、以下のようにまとめられます。

これで、階層トップのパラメータNUM_OF_INSTANCESを変えることで、インスタンス数によらず、テストが可能になりました。

ところで、まだトップレベルmoduleとインターフェース周りが整理されていません。インターフェースには、動作と信号を全て書いてしまっているので、次のように、動作のカウンタモジュールと信号インターフェースに分けます。

カウンタをアレー化する部分とprogramは、次のように書きました。

トップレベルモジュールは、以下になります。大分すっきりしました。

しかし、未だインターフェースの部分が合成可能ではありません。これを合成可能とするために、リセット信号を追加します。

テストベンチクラスに制御信号をリセットするtaskを追加します。

program ドメンインなので、その必要はないですが、インターフェース中の信号は、automatic 属性ではないので、ノンブロッキング文が可能です。

-virtual interfaceを通して見る信号は、static　属性になります。なお、LRM2012で、クラスメンバーに対するノンブロッキング禁止の制限はなくなりました。しかしながら、真にダイナミックなオブジェクトdynamic arrayや、queueは、依然として禁止です。

と書いてもOKです。核になるハードウェアの制御信号を追加したのですが、変更した部分は、これが殆どで、煩わしいポート接続の記述変更は全く必要ありません。

-VerilogHDLでは、論理階層の深い部分の変更は、ポート接続変更という仕事が発生していました。

また、counter という信号を　次のようにint(32bit) からbyte(8bit)にしても、
　

変更部は、そこだけで済みポートビット幅の記述変更は不要です。

また、テストベンチも、機械的にタスクを追加する作業だけで済みました。全体ソースと結果は、以下です。

これで、クラスへの移植作業は終わりました。テストベンチをクラスにすると、仮想メソッドが使えます。また、SVクラスだけ導入されている変数のランダム化という技も使えるようになります。　仮想メソッドの使用は、差分プログラミング、変数のランダム化は、セルフチェックテストベンチの開発において威力を発揮します。

Checkerを追加する

ここでは、簡単にカウンタの機能をチェックするテストベンチ(checker）を追加してみましょう。

検証対象（Device Under Test) は、カウンタモジュールで、その機能は、

たったこれだけの機能ですが、この機能を検証するテストベンチを書いてみましょう。期待値と異なる場合は、Failを$displayするものとします。

追加したクラスは、次のようになります。

12,13,14行が並列プロセスで、checkerは、無限ループ、ドライバは、テストが終わったら返ってきますが、何らかのトラブルで処理が滞っているとタイムアウトのスレッドが先に終了して、タイムアウトで終了します。join_anyにより、一つでも子スレッドが終わるとinitialの最後まで行くので、programの終了＝全体の処理終了となります。

このように、クラスは、テストベンチの部品となります。部品を差し替えるように、クラスを交換すれば、簡単に別なシナリオで動かすこと可能になります。

さらにジェネリックにする

counter の型をトップで指定できるようにしてみました。下のソース206行目で、指定しています。