Ultra96でUbuntuのXウィンドウ表示に挑戦してみた

FPGAの部屋の@marsee101さんがUltra96でDebianとWLANが動かせたということでほったらかしにしていたUbuntuでのWLANを確認したら動作した。

何に引っかかってたか？

よくわからな良いけどwpa_supplicantの設定をミスってたようで・・・

ただ、それだけでした。

Xorgを立ち上げてみるか・・・

WLAN繋がればaptできるので、インストールできる手間が一気に解消される。

そこで、XorgをインスコしてGUIを表示できないか挑戦してみた。

Ultra96のUbuntu環境は16.04.5LTSをベースファイルから構築している。

Xorgインスコしたけどarmsocドライバが無い

インスコしているUbuntuはarm64版でXorgはインスコできるんだけど、armsocドライバがない。

armsocドライバは探してみるとarmhf版しかない。

？？？

64bit版でドライバが変わったのかな？

apt sourceでソースコードをダウンロードしてビルドしようとしても64bitではサポートしていないというエラーが発生。

どうしたものかな・・・

Xilinxのデモイメージ

ソースコード解析職人の@VengineerからXilinxの「OpenGLWESのデモ」でX-Windowのデモがあると教えてもらったのでUltra96で試してみたら・・・

• Ubuntu 15.04
• とにかく、GUIの操作が重い！
• xorg.confの設定はarmsocドライバを使用

深くは追いかけなかったがUbuntuでarmsocドライバできるのは現時点でarmhfしか選択肢がない。

じゃぁ、YoctoでX-Windowビルドしたら？

Yoctoもcore-image-satoでX-Windowを構築できるので試してみると、Xorgのドライバはarmsocだった。

ただし、Yoctoはフルビルド環境なのでarmsocドライバもビルドしていたので特に問題ない。

まとめ

Ubuntu 64bit環境にはXorgのarmsocドライバが無いので64bit環境でX-Windowを立ち上げるのはほぼ不可能なのかな？

XilinxのようにOpenGLESを使用するためだけdのGUI表示だけであれば、32bit環境でも良いのだけど、ウィンドウ操作が重いのを見るだけで、無理に32bit環境使う必要もないんじゃない？

と、諦めた。

Vivado 2018.2でDPI-C

前に書いたのがVivado 2017.2版だったのでVivado 2018.2で良いこと起こってないか確認してみました。

でも、特に変わってなかった・・・

参照

• Vivado デザイン ハブ - ロジック シミュレーション
• UG900: Vivado Design Suite ユーザーガイド ロジックシミュレーション

Vivado 2018.2のDPI-C

　Vivado 2018.2のDPI-Cの対応状況はユーザーガイド（UG900）の「Vivadoシミュレータのダイレクトプログラミングインターフェイス(DPI)」を参照して下さい。

　DPI-Cを使用するにはxscコンパイラを使用し、xscがclang、GNUリンカを呼び出しコンパイルすることができます。

SystemVerilogの合成可能なセット

　ユーザーガイド（UG900）の「付録B:Vivado シミュレータのSystemVerilogサポート」でVivadoのシミュレータがサポートしているSystemVerilogの合成可能なセットの一覧が「表B-1:SystemVerilog 1800-2009の合成可能なセット」として示されています。

　また、「表B-2:サポートされるダイナミック タイプ コンストラクト」でシミュレーションでよく使用されるテストベンチの機能の一部がサポートされています。

xsc

xscはシミュレーションで使用するCソースコードをコンパイルするコンパイラです。

一撃コンパイル

$ xsc function.c
$ xelab -svlog file.sv -sv_lib dpi

二段階コンパイル

$ xsc -compile function.c -work sample
$ xsc -link sample/function.lnx64.o -work sample

CとSysnemVerilogの境界で使用可能なデータ型

svdpi.hを使用した場合で使用可能なデータ型

シミュレーション環境の生成

export_ip_user_files

　プロジェクトからIP/IP Integraterファイルを生成及びエクスポートします。

export_ip_user_files -of_objects [get_files ./Zynq7000.srcs/sources_1/bd/Zynq7000/Zynq7000.bd] -no_script -force -quiet

シミュレーション環境のエクスポート

　ターゲットシミュレータのシミュレーションスクリプトをエクスポートします。

export_simulation  -export_source_files -force -directory "../exportsim" -simulator xsim  -ip_user_files_dir "./Zynq7000.ip_user_files" -ipstatic_source_dir "./Zynq7000.ip_user_files/ipstatic" -use_ip_compiled_libs

vlog.prj、vhdl.prjの修正

exportsim/xsimnに生成されたvlog.prjとvhdl.prjのパスが間違えて生成されているので次のように修正します。

tb_Zynq7000.shへ追加

エクスポート後の実行スクリプトは単にシミュレーションするだけの内容になっているので修正が必要です。

修正前

```txt:修正前 elaborate() { xelab --relax --debug typical --mt auto -L axi_lite_ipif_v3_0_4 -L lib_cdc_v1_0_2 -L interrupt_control_v3_1_4 -L axi_gpio_v2_0_19 -L xil_defaultlib -L proc_sys_reset_v5_0_12 -L axi_infrastructure_v1_1_0 -L smartconnect_v1_0 -L axi_protocol_checker_v2_0_3 -L axi_vip_v1_1_3 -L processing_system7_vip_v1_0_5 -L xlconstant_v1_1_5 -L xlconcat_v2_1_1 -L xilinx_vip -L unisims_ver -L unimacro_ver -L secureip -L xpm --snapshot tb_Zynq7000 xil_defaultlib.tb_Zynq7000 xil_defaultlib.glbl -log elaborate.log }

### 修正後

```txt
elaborate()
{
  cp ../../function.c .
  cp ../../socket.c .
  xsc function.c socket.c
  xelab -sv_lib dpi -dpiheader dpi.h --relax --debug typical --mt auto -L axi_lite_ipif_v3_0_4 -L lib_cdc_v1_0_2 -L interrupt_control_v3_1_4 -L axi_gpio_v2_0_19 -L xil_defaultlib -L proc_sys_reset_v5_0_12 -L axi_infrastructure_v1_1_0 -L smartconnect_v1_0 -L axi_protocol_checker_v2_0_3 -L axi_vip_v1_1_3 -L processing_system7_vip_v1_0_5 -L xlconstant_v1_1_5 -L xlconcat_v2_1_1 -L xilinx_vip -L unisims_ver -L unimacro_ver -L secureip -L xpm --snapshot tb_Zynq7000 xil_defaultlib.tb_Zynq7000 xil_defaultlib.glbl -log elaborate.log
}

実行

$ ./tb_Zynq7000.sh

プロジェクトデータ

github置いてます。

今回はsocket通信も追加してみました。

ラズパイストリーミングをUltra96でメモリに保存する

昨日は次のコマンドにてラズパイのカメラ映像をストリーミングしてPC上で表示させた。

gst-launch-1.0 -v rtspsrc location=rtsp://192.168.1.204:9000/ ! rtph264depay ! avdec_h264 ! videoconvert ! autovideosink

ライズパイのストリーミングをUltra96で受信して、メモリにブチ込むためにappsinkでgstreamerのプログラムを組むことを考えたけど、それはそれで面倒でしょ。

たかが、FPGAの画像処理モジュールの検証環境を作るためにgstreamerの開発から作るのも面倒だしね。

そこでfdsinkで横着する。

つまり、コマンドは次のようにする。

gst-launch-1.0 -v rtspsrc location=rtsp://192.168.1.204:9000/ ! rtph264depay ! avdec_h264 ! videoconvert ! capsfilter caps="video/x-raw,format=RGBx" ! fdsink fd=1

FPGAの回路はRGBAの32bitなので処理にしているのでfdsinkで出力させるのはRGBxで32bitにする。

横着して次のプログラムを組む。

fdsinkで標準出力に出した画像データを標準入力で読み込んでメモリに保存する。

#define WIDTH 640
#define HEIGHT 480
int main() {
  size_t frame_size = WIDTH*HEIGHT*sizeof(unsigned int);
  unsigned int *frame = malloc(frame_size);
  unsigned int *buf;

  fd = open( "/dev/mem", O_RDWR | O_SYNC );
  if( fd == -1 ){
    printf( "Can't open /dev/mem.\n" );
    return 0;
  }
 buf = mmap( NULL, MAP_LENG,
               PROT_READ | PROT_WRITE,
                           MAP_SHARED, fd,
                           offset & 0xFFFF0000);
  if( buf == MAP_FAILED ){
    printf( "Error: mmap()\n" );
    return 0;
  }

  while(fread(frame, frame_size, 1, stdin) == 1) {
    fwrite(buf, frame, frame_size);
  }

  return 0;
}

転送コストがかかるけど、検証用の環境だから良いのよ。

これでFPGAモジュールの実機検証ができたら、４カメラ入力のボードをどうするか本格的に考えることにしよう。

Raspi Camera + Ultra96

ちょっと、忘れないうちに・・・

今、下図の構成でラズパイZERO-Wのカメラ映像をWiFiでUltra96へ飛ばす。

ラズパイ側

ラズパイのカメラからストリームでUltra96で映像を飛ばす。

ストリームを送信するのはVLCを使う。

$ sudo apt install vlc

gstreamerでも良いんだけど、VLCだと下記のコマンドで送信する。

$  raspivid -n -o - -t 0 -w 640 -h 480 -fps 15 | clvc -vvv stream:///dev/stdio --sout '#rtp{sdp=rtsp://:9000}' :demux=h264-fps=15

Ultra96側

Ultra96はgstreamerで受信して、H264を解いてからバッファに入れられるように組む。

Yocto Projectでgstreamerを組み込んでいるのでビルドできたら試そう

PC

その前にPCでストリーミングしてみよう。

gst-launch-1.0 -v rtspsrc location=rtsp://192.168.1.204:9000/ ! rtph264depay ! avdec_h264 ! videoconvert ! autovideosink

これでPCでラズパイカメラの映像を表示することができた。

9年ぶりの母艦更新

　Zynq MPSoCを合成するようになって、顕著にメモリ不足で処理能力低下が発生するようになり耐えきれなくなったので母艦を更新した。

　私の場合、母艦での作業は基本的に時間がかかる処理用に使っている。

　例えば、Yocto Projectのbitbakeを流すとか2日かかっててもいいようなものを流すとかが主な使用方法だ。

　Vivadoはタブレットで使っているけど、実はタブレットの方で遅くなったのだ。

　タブレットのメモリは8GBなんだけど、まぁ、Swap Outしちゃんだな。

　そこでZynq MPSoC系は母艦で処理することにして、X-Windowでタブレットに飛ばしてくればいいかなぁと、今回の母艦更新に繋がったわけです。

下表は左が更新前、右が更新後の母艦です。

9年も経てば、CPUも様変わりしますわな。

母艦といえど、設置面積は取りたくなかったのでMiniITXで小さめのケースを探したけど、Tsukumoのケースが一番気に入ったのでそのままBTOで購入した。

これでZynq MPSoCとYocto Projectの同時進行をタブレットのUbuntu 18.04LTS上で行えるぞ。