ひでみのアイデア帳

くだらないことなんだけど、忘れないために・・・

SystemVerilogのお勉強(2−1)

Vivado 2017.2のSystemVerilogについて、いらぬところまで勉強してみよう。

コマンド実行のおさらい

コマンドは次の順番で実行する。

xvlog -sv file.sv
xelab TOP -dpiheader dpi.h
xsc function.c
xelab TOP -sv_lib dpi -R

SystemVerilogで実行するコマンドをもう少し深堀してみました。

xvlog

xvlog -sv file.sv

SystemVerilogを読込み、デフォルトでxsim.dirフォルダを作成してシミュレーションの準備を行います。 デフォルトでworkというシミュレーション用のライブラリを作成し、この場合はfile.svの内容をライブラリに展開します。 次のようにtopという名前のモジュールがあれば、xsim.dir/work.TOPというライブラリを生成します。 また、xsim.dir/work/@t@o@p.sdbというワークファイルも生成するようです。 このファイルのファイル名はモジュール名の1文字毎に@を追加してライブラリファイルとしています。 ここで気が付いたのはモジュール名に大文字があっても、ファイル名は小文字で生成しているところです。 特に問題ではないですが、大文字小文字を区別してモジュール名を作る場合は中止する必要がありそうです。 (そんなひといないと思うけど・・・)

module TOP(
  ...
)

xelab

xelab TOP -dpiheader dpi.h

デフォルトではxsim.dir/workライブラリにあるモジュール(この場合はTOPを指定している)のexportとimportのヘッダファイルを生成し、dpi.hとして出力します。 "-dpiheader"の引数がヘッダを生成する引数になります。

xsc

xsc function.c

function.cをシミュレータで実行できるシェアードオブジェクトとして、コンパイルします。 デフォルトではxsim.dir/xscにdpi.soとして生成されます。 また、function.cではxelabで生成したdpi.hを使用します。

xsim.dir/xsc/dpi.so xsim.dir/xsc/function.lnx64.o

xelab

xelab TOP -sv_lib dpi -R

シミュレーションの実行になります。 "-R"の引数はrunallの意味です。

いろいろやってみたい

DPI-CでCのアプリを実行できるのでSystemVerilogでいろいろやってみたいですよね。 ちなみに画像屋なので、できるならこういうことをやってみたい。

OpenCVやgstreamerをSystemVerilogから呼び出して、画像を読み込ませてしまいたいのです。

Xilinxのシミュレーション環境にOpenCVやGstreamerを追加してしまえばできるのですが・・・

ここからは少しXilinxの実行環境の解析です。

SystemVerilogのコマンドでコンパイルするのはxscコマンドで、このコマンドはgccとclangが選択できるようになっています。

これらのツールチェーンは次のフォルダにいるようです。

/opt/Xilinx/Vivado/2017.2/tps

つまり、ここのツールチェーンを使用して、OpenCVやGstreamerを組み込んでしまえば、SystemVerilogのテストベンチから直接、OpenCVやGstreamerを使えるようにできます。

ただ、Xilinxのツールって4ヶ月に1度で更新されるのでそのたびに、組込みを実施するのは面倒なのと、ツールチェーンのバージョンが変わってOpenCVやGstreamerが組み込めなくなるとそこで余計なデバッグが発生する可能性があります。

それなら、いっそうのことOpenCVやGstreamerはUbuntu側のツールチェーンでライブラリを生成して、Ubuntu側にソケットで通信するプロセスを作成し、SystemVerilogとソケットで通信する環境にしてしまえば、OpenCVやGstreeamerは別管理にして対応できるのでは?

他のライブラリにも対応しやすくなるのでは?

それにソケットはデフォルトで使用できるはずだからXilinxの環境も下手にいぢらなくても構わないし・・・

と、書くと必ずプロセス間通信でいいじゃないか?が出てきます。

それでいいと思いますよ。

私はPC内に閉じた環境ではなくネットワークで飛ばせる環境も作りたいのでソケットにするだけなので・・・

ソケットにして何が楽しいか?

ネットワーク越しでSystemVerilogが実行できるようになれば、SystemVerilogで遠隔で結果を見せることが可能になってきます。

ある意味、SystemVerilogでIPの動作を確認できるデモなんかも作れそうだなぁ〜なんて、考えています。

まぁ、そんなの面倒な仕組みを作るくらいなら実機シミュレーション環境作ってしまえばいいんだけど・・・

どうして、ツールチェーンにこだわっているのか?

Xilinxのツールチェーンはgcc 6.2で、一方、Ubuntu 16.04.2LTSのgccはデフォルト5.4です。

それぞれ、対応しているライブラリもバージョンも違うのでもし、UbuntuのgccでコンパイルしたアプリをXilinxのライブラリで動作させると環境違いによって不具合が発生する可能性があります。

下手なことをして不具合を増やして、デバッグの工数を増やしても仕方ないので「なにをどれで構築する」というのはこだわっています。