ひでみのアイデア帳

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

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環境使う必要もないんじゃない?

と、諦めた。

2018年09月24日 10時00分58秒 - Permament Link

Vivado 2018.2でDPI-C

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

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

参照

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の境界で使用可能なデータ型

SystemVerilog C 備考
byte char
shortint short int
int int
longint long long
real double
shortreal float
chandle void *
string const char *
bit unsigned char sv_0、sv_1

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

SystemVerilog C 備考
logic、reg unsigned char sv_0、sv_1、sv_z、sv_x
bitの配列(パック型) svBitVecVal svdpi.hで定義
logic/regの配列(パック型) svLogicVecVal svdpi.hで定義
enum enum
パック型struct、union 配列として渡される
bit、logicのアンパック型配列 配列として渡される
アンパック型struct structとして渡される
アンパック型unions structとして渡される
配列を開く svOpenArrayHandle

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

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のパスが間違えて生成されているので次のように修正します。

修正前 修正後
srcs/srcs srcs
"srcs/ip/Zynq7000 "srcs/ip/Zynq7000/xil_defaultlib

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通信も追加してみました。

2018年09月20日 21時09分47秒 - Permament Link

ラズパイストリーミングを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モジュールの実機検証ができたら、4カメラ入力のボードをどうするか本格的に考えることにしよう。

2018年08月26日 18時38分51秒 - Permament Link

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でラズパイカメラの映像を表示することができた。

2018年08月25日 22時07分10秒 - Permament Link

9年ぶりの母艦更新

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

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

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

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

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

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

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

Acer Aspire 3935-CF61 Tsukumo AeroMini MI7J-D180T
タイプ ノートPC MiniITX
CPU Core 2 Duo P8600(2.4GHz 2COre) Core i7-8700 (3.2GHz/TB4.6GHz 6Core)
メモリ 4GB 32GB
メモリ規格 DDR3 PC3-8500 PC4-21300)
SSD 200GB 500GB
OS Ubuntu 16.04.5LTS Ubuntu 18.04.1LTS
モニタ

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

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

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

2018年08月23日 21時12分47秒 - Permament Link