ELECOMのWDC-150SU2MをZYNQのLinuxから使う

Zynqberryスタータキットで使っていたPlanexのGW-USNANO2Aが販売終了になってしまいました。

GW-USNANO2AのチップはRealtekのRTL8192CUというもので、ファームウェアもドライバもあり、ARM系Linuxで唯一使えていたWiFiアダプタだったのですが、これはちょっとダメージ大きいですね。

RTL8192CUを使ったUSB-WiFiが他にないかと探したのですが、無そうでした。

現時点で入手性が良くて価格も安くコンパクトなものは、WDC-150SU2MBKまたはWDC-150SU2MWです。最後のBKとWはおそらく色なので、正式名称はWDC-150SU2Mでしょう。

このUSB-WiFiが搭載しているチップは、RealTekのRTL8188EUSというものです。

残念なことにLinux用のドライバは正式にはリリースされていませんが、有志の人が作ってくれているようなので、それをダウンロードしてコンパイルすることにします。

以下、クロスビルド用のデスクトップPCで作業します。このPCはLinuxカーネルをコンパイルしたPCで、カーネルのソースが/home/naitou/linux-xlnxにあると仮定します。

まず、lwfingerさんのgitからrtl8188eu用のドライバをcloneしてきます。

$ git clone https://github.com/lwfinger/rtl8188eu.git

これをコンパイルする前にあらかじめCROSS_COMPILEのエクスポートや、Xilinx SDKの環境設定スクリプトを呼んでおきます。

$ export CROSS_COMPILE=arm-linux-gnueabihf-
$ source /opt/Xilinx/SDK/2017.4/settings64.sh ← 環境に応じて変えよ

ビルドは以下のコマンドで行います。

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- KSRC=/home/naitou/linux-xlnx

KSRCでLinuxカーネルのソースが入ったディレクトリを指示するのがポイントです。

ビルドが終わると以下のようなファイルが出来上がっていまｓ。

naitou@ubuntu:~/rtl8188eu$ ls -al
合計 2072
drwxrwxr-x  9 naitou naitou   4096  9月 30 23:25 .
drwxrwxrwx 56 naitou naitou   4096  9月 30 23:18 ..
-rw-rw-r--  1 naitou naitou    226  9月 30 23:25 .8188eu.ko.cmd
-rw-rw-r--  1 naitou naitou  20765  9月 30 23:25 .8188eu.mod.o.cmd
-rw-rw-r--  1 naitou naitou   2711  9月 30 23:25 .8188eu.o.cmd
drwxrwxr-x  8 naitou naitou   4096  9月 30 23:18 .git
-rw-rw-r--  1 naitou naitou   1106  9月 30 23:18 .gitignore
drwxrwxr-x  2 naitou naitou   4096  9月 30 23:25 .tmp_versions
-rw-rw-r--  1 naitou naitou 983892  9月 30 23:25 8188eu.ko
-rw-rw-r--  1 naitou naitou   8061  9月 30 23:25 8188eu.mod.c
-rw-rw-r--  1 naitou naitou  10864  9月 30 23:25 8188eu.mod.o
-rw-rw-r--  1 naitou naitou 973736  9月 30 23:25 8188eu.o
-rw-rw-r--  1 naitou naitou  18693  9月 30 23:18 COPYING
-rw-rw-r--  1 naitou naitou   4088  9月 30 23:18 Makefile
-rw-rw-r--  1 naitou naitou      0  9月 30 23:25 Module.symvers
-rw-rw-r--  1 naitou naitou   1491  9月 30 23:18 README.md
-rwxrwxr-x  1 naitou naitou   4199  9月 30 23:18 control_ap
drwxrwxr-x  2 naitou naitou   4096  9月 30 23:24 core
-rw-rw-r--  1 naitou naitou    208  9月 30 23:18 dkms.conf
drwxrwxr-x  2 naitou naitou   4096  9月 30 23:25 hal
drwxrwxr-x  4 naitou naitou   4096  9月 30 23:18 hostapd-0.8
drwxrwxr-x  2 naitou naitou   4096  9月 30 23:18 include
-rw-rw-r--  1 naitou naitou     40  9月 30 23:25 modules.order
drwxrwxr-x  2 naitou naitou   4096  9月 30 23:25 os_dep
-rw-rw-r--  1 naitou naitou  13904  9月 30 23:18 rtl8188eufw.bin
-rw-rw-r--  1 naitou naitou   1820  9月 30 23:18 rtl_hostapd.conf

この中の8188eu.koがドライバで、rtl8188eufw.binがファームウェアです。

この2つのファイルをターゲットボードにコピーします。8188eu.koをターゲットボードの/lib/modules/4.9.0-xilinx-00027-g9c2e29b/kernel/drivers/にコピーし、rtl8188eufw.binを/lib/firmware/と/lib/firmware/rtlwifi/にコピーします。

そうしたら

insmod /lib/modules/4.9.0-xilinx-00027-g9c2e29b/kernel/drivers/8188eu.ko

でインストールできます。

ifconfigまたはip addrで無線LANが存在していることを確認します。

iwlist scanでも確認します。

ただ、WDC-150SU2Mとwpa_supplicantの相性は悪いようで、Ubuntu 18でNetworkManagerを使わないとその後の通信には成功しませんでした。

wpa_supplicantを使って接続する場合は、

wpa_supplicant -iwlan1 -D wext -c/etc/wpa_supplicant/wpa_supplicant.conf

と指定しなければなりませんでしたが、これでも接続には成功していません。nl80211ではなくwextという別のドライバを使うという意味であるようです。

ZYNQ Linuxの/lib/modulesフォルダやmodules.dep等の作り方

これまでZynqberry用のUbuntu Linuxを提供してまいりましたが、恥ずかしながら今まで/lib/modules/($uname -r)/フォルダの作り方がわからなかったので、このフォルダを提供できず、modprobeなどができませんでした。

mkdirで空の/lib/modules/$(uname -r)を作っておけば様々なエラーの回避はできるのですが、正しいmodules.dep等がないとカーネルモジュールが使えません。

今、ようやく/lib/modules/$(uname -r)/フォルダの作り方を理解したので紹介します。

まず、前提として/lib/modules/$(uname -r)/というフォルダは、Linuxのカーネルコンパイルの際に一緒に作られます。したがって、Linuxをコンパイルしたときのソースフォルダがが必要です。

しかし、今更そのようなフォルダはないとか、コンフィグを変えて再コンパイルしてしまったなどで、当時のフォルダがないことも多々あるでしょう。

そのような場合でも心配はいりません。過去のLinuxのソースはいつでもダウンロードできるし、コンパイルの際のコンフィグは動作中のLinuxから得ることができるからです。

Zynqberryの場合、XILINX用Linuxカーネル4.9.0なので、Xilinxのgitからダウンロードしてきます。

以下、クロスビルド用のホストPCでの作業です。

$ git clone -b xlnx_rebase_v4.9 git://github.com/Xilinx/linux-xlnx.git
$ cd linux-xlnx

Linuxのコンパイルに使用したコンフィグは、オプションで無効にしていなければ/proc/config.gzにあります。動作中のZynqberryの/procからconfig.gzをコピーしてきて、解凍して.configを作ります。

$ scp ユーザ名@IPアドレス:/proc/config.gz .
$ gunzip -c < config.gz > .config

これで、コンパイル当時のLinuxのソースフォルダが再構成できました。

そうしたらCROSS_COMPILEのマクロを設定したり、Xilinx SDKの初期化コマンドを実行して環境を整えたら、Linuxカーネルをコンパイルします。

$ export CROSS_COMPILE=arm-linux-gnueabihf-
$ source /opt/Xilinx/SDK/2017.4/settings64.sh ← 環境に応じて変えよ
$ make ARCH=arm UIMAGE_LOADADDR=0x8000 uImage

当時の状況でLinuxカーネルがコンパイルされ、arch/arm/bootにuImageが出来上がっているはずです。

そうしたら、次に以下のコマンドを入力します。

$ make ARCH=arm INSTALL_MOD_PATH=./modroot modules
$ make ARCH=arm INSTALL_MOD_PATH=./modroot modules_install

これで、linux-xlnx/modroot配下にlibフォルダが作られ、その中にモジュール一式が入っているというわけです。

見てみましょう

naitou@ubuntu:~/linux-xlnx/modroot/lib/modules/4.9.0-xilinx$ ls -al
合計 92
drwxrwxr-x 3 naitou naitou  4096  9月 29 11:34 .
drwxrwxr-x 3 naitou naitou  4096  9月 29 11:34 ..
lrwxrwxrwx 1 naitou naitou    23  9月 29 11:34 build -> /home/naitou/linux-xlnx
drwxrwxr-x 5 naitou naitou  4096  9月 29 11:34 kernel
-rw-r--r-- 1 naitou naitou   353  9月 29 11:34 modules.alias
-rw-r--r-- 1 naitou naitou   455  9月 29 11:34 modules.alias.bin
-rw-rw-r-- 1 naitou naitou 16780  9月 29 11:34 modules.builtin
-rw-r--r-- 1 naitou naitou 19538  9月 29 11:34 modules.builtin.bin
-rw-r--r-- 1 naitou naitou   832  9月 29 11:34 modules.dep
-rw-r--r-- 1 naitou naitou  1647  9月 29 11:34 modules.dep.bin
-rw-r--r-- 1 naitou naitou    52  9月 29 11:34 modules.devname
-rw-rw-r-- 1 naitou naitou   426  9月 29 11:34 modules.order
-rw-r--r-- 1 naitou naitou   131  9月 29 11:34 modules.softdep
-rw-r--r-- 1 naitou naitou  3613  9月 29 11:34 modules.symbols
-rw-r--r-- 1 naitou naitou  4529  9月 29 11:34 modules.symbols.bin
lrwxrwxrwx 1 naitou naitou    23  9月 29 11:34 source -> /home/naitou/linux-xlnx

そうしたらこれをtgzで固めて、Zynqberryに転送します。

$ tar -zcvf module.tgz lib/
$ scp module.tgz ユーザ名@IPアドレス:/home/share

受け取ったZynqberryではこれを解凍し、($uname -r)以下に移動します。

# tar -zxvf module.tgz
# mv lib/modules/4.9.0-xilinx/ /lib/modules/4.9.0-xilinx-00027-g9c2e29b/

lsで様子を見てみます。

これでカーネルモジュールに対応でき、lsmodやinsmod、modprobeなどが使えるようになりました。

作成したmodulesと、カーネルヘッダは下記のURLからダウンロードできます。

http://trenz.jp/download.html

なお、上の図のとおりbuildフォルダとsourceフォルダがクロスコンパイルに使ったホストPCのフォルダ名のシンボリックリンクを参照してしまっているのと、カーネルコンパイルが終わった状態でlinux-xlnxフォルダは3.3GByteもあるので、容易には配布できません。そのため、ソース一式の配布はいたしません。必要な場合は上記の手順で作りなおした方が早いと思います。

ZynqberryのQSPI ROMにXILINX SDK 2018.2以降で書き込むには

昨日、XILINX SDK 2018.3でZynqberryのROMに書き込もうとしたところ、見事に失敗しました。

XILINXが用意したu-bootが何やら動かないようです。

Trenz社のWebサイトにはVivado2018.2用のリファレンスデザインが用意されていたので、zynqberrydemo1をダウンロードし、中にあるprogram_flash_binfile.cmd で書き込んでみました。

設定の変更は以下の4か所です。

@set XILDIR=D:/Xilinx
@set VIVADO_VERSION=2018.3
@set PARTNUMBER=te0726-03m
@set SWAPP=u-boot
@set DO_NOT_CLOSE_SHELL=1

すると、見事に書き込み成功したのですが、そのときのTeraTermに表示されていた画面は、

最初の行に怪しげなことが書かれているのが見えるでしょうか。

Zynq> Xilinx Zynq First Stage Boot Loader to write QSPI Flash (TE modified)
Release 2018.2 Nov 20 2018-14:52:03

つまり、読み込まれたFSBLはQSPI Flashに書き込むためにTE社が修正したものだったのです。

これでようやく理解しました。

Vivado 2017.4以降で行われたフラッシュROM書き込み時にFSBLのELFファイルを必要とするというのは、SPI ROMに書き込まれるboot.binに含まれるFSBLのELFを要求しているのではなく、XILINXが用意したフラッシュ書き込み用U-Bootを起動するための一時的なFSBLのELFを要求していたのだと思われます。

その証拠に、Trenz社のスクリプトではプロジェクト名に関わらずelfファイルの所在が常に/prebuilt/software/m/zynq_fsbl_flash.elfなのです。

そして、2018版のzynqberrydemo1のプロジェクト構成を見てみると、\sw_lib\sw_appsディレクトリにzynq_fsblとzynq_fsbl_flashの2つのFSBLのソースがありました。比較してみると・・

この違いは３つです。

• 通常版fsblはDDRメモリを使う。QSPI用fsblはDDRInitCheck()などがコメントアウトされている
• main()で、QSPI版は
  BootModeRegister = JTAG_MODE;
  というのを実行し、起動モードを書き換えている。
• 通常版はVideo関係の初期化を行っている

おそらくBootModeRegisterを書き換えているのがポイントなのだと思います。

実際にSDKが生成したFSBLのソースに

BootModeRegister = JTAG_MODE

を書き加えてみると、なんと、フラッシュROM書き込みに成功しました。

全ログを出します。

cmd /C program_flash -f C:\Users\user\Desktop\zynqberry_bootbin\boot.bin -offset 0 \
-flash_type qspi-x1-single -fsbl D:\zynqberrydemo1\swtest\fsbl\Debug\fsbl.elf -cable type \
xilinx_tcf url TCP:127.0.0.1:3121 
****** Xilinx Program Flash
****** Program Flash v2018.3 (64-bit)
  **** SW Build 2405991 on Thu Dec  6 23:38:27 MST 2018
    ** Copyright 1986-2018 Xilinx, Inc. All Rights Reserved.
Connected to hw_server @ TCP:127.0.0.1:3121
Available targets and devices:
Target 0 : jsn-JTAG-ONB4-251633001266A
	Device 0: jsn-JTAG-ONB4-251633001266A-4ba00477-0
Retrieving Flash info...
Initialization done, programming the memory
===== mrd->addr=0xF800025C, data=0x00000001 =====
BOOT_MODE REG = 0x00000001
WARNING: [Xicom 50-100] The current boot mode is QSPI.
If flash programming fails, configure device for JTAG boot mode and try again.
===== mrd->addr=0xF8007080, data=0x30800100 =====
===== mrd->addr=0xF8000B18, data=0x00000000 =====
Downloading FSBL...
Running FSBL...
Finished running FSBL.
===== mrd->addr=0xF8000110, data=0x000FA220 =====
READ: ARM_PLL_CFG (0xF8000110) = 0x000FA220
===== mrd->addr=0xF8000100, data=0x00028008 =====
READ: ARM_PLL_CTRL (0xF8000100) = 0x00028008
===== mrd->addr=0xF8000120, data=0x1F000200 =====
READ: ARM_CLK_CTRL (0xF8000120) = 0x1F000200
===== mrd->addr=0xF8000118, data=0x000FA240 =====
READ: IO_PLL_CFG (0xF8000118) = 0x000FA240
===== mrd->addr=0xF8000108, data=0x00030008 =====
READ: IO_PLL_CTRL (0xF8000108) = 0x00030008
Info:  Remapping 256KB of on-chip-memory RAM memory to 0xFFFC0000.
===== mrd->addr=0xF8000008, data=0x00000000 =====
===== mwr->addr=0xF8000008, data=0x0000DF0D =====
MASKWRITE: addr=0xF8000008, mask=0x0000FFFF, newData=0x0000DF0D
===== mwr->addr=0xF8000910, data=0x000001FF =====
===== mrd->addr=0xF8000004, data=0x00000000 =====
===== mwr->addr=0xF8000004, data=0x0000767B =====
MASKWRITE: addr=0xF8000004, mask=0x0000FFFF, newData=0x0000767B
U-Boot 2018.01-00073-g63efa8c-dirty (Oct 04 2018 - 08:24:48 -0600)
Model: Zynq CSE QSPI Board
Board: Xilinx Zynq
Silicon: v3.1
DRAM:  256 KiB
WARNING: Caches not enabled
Using default environment
In:    dcc
Out:   dcc
Err:   dcc
Zynq> sf probe 0 0 0
SF: Detected s25fl128s_64k with page size 256 Bytes, erase size 64 KiB, total 16 MiB
Zynq> Sector size = 65536.
f probe 0 0 0
Performing Erase Operation...
sf erase 0 190000
SF: 1638400 bytes @ 0x0 Erased: OK
Zynq> Erase Operation successful.
INFO: [Xicom 50-44] Elapsed time = 5 sec.
Performing Program Operation...
0%...sf write FFFC0000 0 20000
device 0 offset 0x0, size 0x20000
SF: 131072 bytes @ 0x0 Written: OK
Zynq> sf write FFFC0000 20000 20000
device 0 offset 0x20000, size 0x20000
SF: 131072 bytes @ 0x20000 Written: OK
Zynq> sf write FFFC0000 40000 20000
device 0 offset 0x40000, size 0x20000
SF: 131072 bytes @ 0x40000 Written: OK
Zynq> sf write FFFC0000 60000 20000
device 0 offset 0x60000, size 0x20000
SF: 131072 bytes @ 0x60000 Written: OK
Zynq> sf write FFFC0000 80000 20000
device 0 offset 0x80000, size 0x20000
SF: 131072 bytes @ 0x80000 Written: OK
Zynq> sf write FFFC0000 A0000 20000
device 0 offset 0xa0000, size 0x20000
SF: 131072 bytes @ 0xa0000 Written: OK
Zynq> 50%...sf write FFFC0000 C0000 20000
device 0 offset 0xc0000, size 0x20000
SF: 131072 bytes @ 0xc0000 Written: OK
Zynq> sf write FFFC0000 E0000 20000
device 0 offset 0xe0000, size 0x20000
SF: 131072 bytes @ 0xe0000 Written: OK
Zynq> sf write FFFC0000 100000 20000
device 0 offset 0x100000, size 0x20000
SF: 131072 bytes @ 0x100000 Written: OK
Zynq> sf write FFFC0000 120000 20000
device 0 offset 0x120000, size 0x20000
SF: 131072 bytes @ 0x120000 Written: OK
Zynq> sf write FFFC0000 140000 20000
device 0 offset 0x140000, size 0x20000
SF: 131072 bytes @ 0x140000 Written: OK
Zynq> sf write FFFC0000 160000 20000
device 0 offset 0x160000, size 0x20000
SF: 131072 bytes @ 0x160000 Written: OK
Zynq> 100%
sf write FFFC0000 180000 B520
device 0 offset 0x180000, size 0xb520
SF: 46368 bytes @ 0x180000 Written: OK
Zynq> Program Operation successful.
INFO: [Xicom 50-44] Elapsed time = 9 sec.
Flash Operation Successful

予想どおりでした。

SDKでのフラッシュ書き込みは、Zynq CSE QSPI Boardという名前のu-bootを起動して、u-bootのアプリとしてフラッシュROMに書き込みを行っていたのです。

そもそもこの現象を調べるきっかけになったのは、お客様からZynqberryのTE0726-02Mでは書き込みできたのに03Mでは書き込みできなくなったという問い合わせからでした。

Zynqberryの02Mと03Mの違いを探したのですが、Trenz社のページを見てもPCN(プロダクト変更通知)がリンク切れなので回路図を見比べてみたところ、ブートモードや回路上の違い、部品の変更は見つかりませんでした。02Mと03Mの主な違いはピンヘッダの有無くらいでした。

☀

XILINX SDKで書き込めないという問題のヒントは昨日の記事の、SDKのログにありました。

If flash programming fails, configure device for JTAG boot mode and try again.

フラッシュのプログラミングに失敗するならばJTAGモードを試せ、ということです。

結論を言うと原因は、

• ZynqberryのブートモードはQSPI(x4)モードになっている
• BootROMはモードピンをモニタしてBootModeをQSPIに設定する
• SDKからのプログラミング時はJTAGを通じてテンポラリFSBLとU-Bootがダウンロードされる
  
  • このとき、実際のROMはx1モードになっている
  • BootModeは（JTAGからダウンロードされたことがわからないので）QSPIを示してx4でアクセスしようとする

ということではないかと思われます。

なぜSDK 2017.2以前ではうまくいったのかというと、昔のテンポラリFSBLはx1モードでアクセスするようになっていたのかもしれません。

本当の原因はよくわかりませんが、解決策としては、テンポラリFSBLのソースに

BootModeRegister = JTAG_MODE;

の一行を付け加えるのがベストです。

この問題はZynqberryに関してだけではなく、ZYNQでQSPIブートを行うすべてのシステムに共通して起こっている問題のようです。

ZynqberryをXILINX SDKで開発する

ZynqberryをXILINX SDKで開発する、というと何を当たり前のことを・・と思うかもしれません。

ZynqberryはXILINX SDKを直接使うのではなくTrenz社のTclスクリプトを介して操作するべきものなのです。

では、明示的にXILINX SDKで開発するとどうなるでしょうか。

　☀

まずはXILINX SDK 2017.2で実行してみましょう。

Trenz社のサンプルプロジェクトにあるVivado 2017.1用に作られたZynqberrydemo1をダウンロードします。

これを解凍し、中にあるprebuilt\hardware\te0726_mフォルダを見てみます。

中にはzynqberrydemo1.bitとzynqberrydemo1.hdfがあります。hdfファイルというのはHardware Definition Fileのことで、実体はZIPファイルです。解凍すると、ps7_initやドライバファイル、BlockDesignを作り出すTclファイル、それからハードウェアの設定の定義などが入っています。

このhdfをSDKに食わせてFSBLを作ると、BSPとhw_platformいうのが作られますが、詳しいやり方は割愛します。

下の図は、FSBLを作った時のXILINX SDK 2017.2の画面です。hw_platformの中にps7_init.cがいます。

今SDK 2017.2で作ったFSBLと、Trenzが用意した(sw_lib\sw_apps\zynq_fsbl\src)FSBLのプログラムを見比べてみると、本質的にはfsbl_hooks.cのFsblHookBeforeHandoff()の中で、VTC(Video Timing Controler)やカメラ用、ビデオ出力用のVDMAの設定をしているだけの違いでした。

この結果からわかることは、Zynqberryに関しては、「ビデオ入出力を使用しなければ、SDKが作るFSBLでも問題ない」ということです。(FSBLの中にTrenz社独自の拡張は入りません)。

☀

本来ならばこの後FSBLをビルドしてU-BootやBitStreamと結合してboot.binを作るのですが、割愛してTrenz社が作ったU-bootの入ったboot.binを書き込むことにします。

まず、Xilinx Toolsの中にあるProgram Flashを行います。

以下のダイアログが開くので、

Trenz社によって作られたboot.bin(zynqberrydemo1\prebuilt\boot_images\te0726_m\u-boot\BOOT.bin)を指定し、Programボタンを押します。

Consoleと書かれたタブにコマンド実行結果が出ます。

実行結果をテキストで貼り付けます。

cmd /C program_flash -f D:\zynqberrydemo1\prebuilt\boot_images\te0726_m\u-boot\BOOT.bin \
-offset 0 -flash_type qspi_single -cable type xilinx_tcf url TCP:127.0.0.1:3121 
****** Xilinx Program Flash
****** Program Flash v2017.2 (64-bit)
  **** SW Build 1909853 on Thu Jun 15 18:39:09 MDT 2017
    ** Copyright 1986-2017 Xilinx, Inc. All Rights Reserved.
Connecting to hw_server @ TCP:127.0.0.1:3121
Connected to hw_server @ TCP:127.0.0.1:3121
Available targets and devices:
Target 0 : jsn-JTAG-ONB4-251633001266A
	Device 0: jsn-JTAG-ONB4-251633001266A-4ba00477-0
Retrieving Flash info...
Initialization done, programming the memory
BOOT_MODE REG = 0x00000001
WARNING: [Xicom 50-100] The current boot mode is QSPI.
If flash programming fails, configure device for JTAG boot mode and try again.

f probe 0 0 0
Performing Erase Operation...
Erase Operation successful.
INFO: [Xicom 50-44] Elapsed time = 5 sec.
Performing Program Operation...
0%...90%...100%
Program Operation successful.
INFO: [Xicom 50-44] Elapsed time = 10 sec.
Flash Operation Successful

という結果となり、無事に書き込みができました。

これでTrenz社が用意したU-bootとFSBLの入ったboot.binが書き込まれました。

☀

では、次に同じことをXILINX SDK 2018.3で行ってみます。

SDK 2017.4以降での大きな違いは、Flash ROMに書き込む際にfsblのファイルを指定する必要が出てきたことです。

ここでFSBLを指定して、boot.binを書き込もうとしてみると・・

cmd /C program_flash -f D:\zynqberrydemo2\prebuilt\boot_images\te0726_m\myboot\BOOT.bin \
-offset 0 -flash_type qspi-x1-single -fsbl D:\zynqberrydemo2\swtest\fsbl\Debug\fsbl.elf \
-cable type xilinx_tcf url TCP:127.0.0.1:3121

****** Xilinx Program Flash
****** Program Flash v2018.3 (64-bit)
  **** SW Build 2405991 on Thu Dec  6 23:38:27 MST 2018
    ** Copyright 1986-2018 Xilinx, Inc. All Rights Reserved.


WARNING: Failed to connect to hw_server at TCP:127.0.0.1:3121
Attempting to launch hw_server at TCP:127.0.0.1:3121
Connected to hw_server @ TCP:127.0.0.1:3121
Available targets and devices:
Target 0 : jsn-JTAG-ONB4-251633001266A
	Device 0: jsn-JTAG-ONB4-251633001266A-4ba00477-0

Retrieving Flash info...

Initialization done, programming the memory
===== mrd->addr=0xF800025C, data=0x00000001 =====
BOOT_MODE REG = 0x00000001
WARNING: [Xicom 50-100] The current boot mode is QSPI.
If flash programming fails, configure device for JTAG boot mode and try again.
===== mrd->addr=0xF8007080, data=0x30800100 =====
===== mrd->addr=0xF8000B18, data=0x00000000 =====
Downloading FSBL...
Running FSBL...
Finished running FSBL.
===== mrd->addr=0xF8000110, data=0x000FA220 =====
READ: ARM_PLL_CFG (0xF8000110) = 0x000FA220
===== mrd->addr=0xF8000100, data=0x00028008 =====
READ: ARM_PLL_CTRL (0xF8000100) = 0x00028008
===== mrd->addr=0xF8000120, data=0x1F000200 =====
READ: ARM_CLK_CTRL (0xF8000120) = 0x1F000200
===== mrd->addr=0xF8000118, data=0x001452C0 =====
READ: IO_PLL_CFG (0xF8000118) = 0x001452C0
===== mrd->addr=0xF8000108, data=0x0001E008 =====
READ: IO_PLL_CTRL (0xF8000108) = 0x0001E008
Info:  Remapping 256KB of on-chip-memory RAM memory to 0xFFFC0000.
===== mrd->addr=0xF8000008, data=0x00000000 =====
===== mwr->addr=0xF8000008, data=0x0000DF0D =====
MASKWRITE: addr=0xF8000008, mask=0x0000FFFF, newData=0x0000DF0D
===== mwr->addr=0xF8000910, data=0x000001FF =====
===== mrd->addr=0xF8000004, data=0x00000000 =====
===== mwr->addr=0xF8000004, data=0x0000767B =====
MASKWRITE: addr=0xF8000004, mask=0x0000FFFF, newData=0x0000767B
Problem in running uboot
Flash programming initialization failed.

ERROR: Flash Operation Failed

見てみると、ubootの実行で問題があったと書かれていますね。

推測ですが、SDKからフラッシュROMにプログラミングする際には「XILINXが用意したFPGAとU-bootを書き込んで、U-BootアプリとしてSPI ROM書き込みプログラムを実行している」のではないかと思われます。

そのROM書き込み用のu-bootの実行で失敗したのではないかと思われます。

新しいオフィスで仕事

新しいオフィスで少しずつ仕事を始めています。

Trenz社から大量にボードが届きました。ほぼZYNQで少しだけUltraScale+です。

このまま荷造りして発送できればいいのですが、プリンタなどの環境がまだ整っていません。

オフィスの状況はこんな感じです。結局、製品を荷造り梱包した箱を現オフィス(R&D部)に行って、伝票印刷して、チャリでクロネコヤマトへ・・。この移動時間が無駄でたまりません。

現オフィスではCosmo-Zのアルミケース入りを作り、こちらも出荷です。

ようやく波形整形回路とMCAができたので、出荷できます。

バウンダリスキャン研究会に参加してきました

バウンダリスキャン研究会というのがあるそうなので、参加してきました。

13時開会だったのですが、会場の最寄り駅に着いたところで財布を忘れてきたことに気が付き、家に取りに帰るというハプニングが・・

おかげで2時間近くロスしてしまい、入れたのが15時ごろでした。

内容としては、半導体関係の情勢だったり、産総研のミニマルファブの話だったり、コネクタの話だったり、基板をX線CT検査で見て不良ビアや不良じゃないけど良でもないビアの話だったりで、どこをどうとってもJTAGやバウンダリスキャンとは関係がない話題ばかりでした。

「バウンダリスキャンと連携できたらいいな」という程度のつながりを持たせた感じです。（それはそれで興味深かったので良いのですが。）

昨年行われた会でバウンダリスキャンによる基板検査はほとんど出尽くしたのでしょう。この会はバウンダリスキャンを実装検査に利用した普及を目的としていて、組み込みの開発に用いるという考えはないのでしょう。JTAG-ICEの原理さえ知らない人ばかりかもしれません。メンバーを見てもICEメーカーが一社もない。

ただ、産総研のミニマルファブの話は面白かった・・・。小さな1/2インチのシリコンウェハにICを作るという話で、「とうとう世の中ここまで来たか」という感じでしたね。この研究会が好きそうな実装検査に使う古いJTAGでは、テストパターンの作りこみに何日もの工数がかかるので、1つや2つしか作らないICや基板ではコスト的に全然ペイしないのですが、こういった分野にこそリアルタイムなバウンダリスキャン可視化を活用していただけると嬉しいですね。

Cosmo-Z Miniでも等価サンプリングができるようにした

Cosmo-Zで54GHzの等価サンプリング（こちらの記事）を、Cosmo-Z Miniでもできるようにしてみました。

等価サンプリングというのは、ADCのサンプリングするタイミングを少しずつずらしていって、毎秒数GサンプリングのADCのようにすることです。

Cosmo-Z Miniで使用しているADコンバータは125MHzサンプリングですので8nsのサンプリング周期ですが、8nsの間の信号を平均した値が読みだされるわけではありません。ウィンドウが開いている時間はもっと短いのです。

この改良を行うには、まず、アナログフロントエンドの抵抗やコンデンサを取り換えます。コンデンサの容量を小さくするのも大事ですが、抵抗を小さいものに変えると飛躍的に特性が伸びます。その代わり、ノイズやオフセットが悪くなるのでトレードオフですが、今回は限界まで周波数特性に振り切ってみましょう。

その結果を下のグラフに示します。Cosmo-Z Miniは125MHzサンプリングなので、50MHzくらいのところにカットオフ周波数を設定していますが、そのリミットを解除したところ250MHzで-3dBダウン、1GHzでも-30dBという結果となりました。

テスト用の信号源には、FPGAのI/Oをそのまま使います。ここから640MHzで1クロック分のパルスを出し、抵抗を介してアナログ入力に入れます。要するに幅1.5nsのパルスです。

これを等価サンプリングしてみた結果を示します。

今回の1つのサンプリング区間は93psですが、最短で18psまでいけます。1.5nsのパルスですが多少なまって2nsくらいの幅で見えています。

FPGA内に2つのクロックを持ち、片方を基準にしてもう片方を18psの精度で動かしていき、ADCのサンプリングタイミングをずらしクロックに合わせてずらすとこうなります。

今はまだ1クロック期間内(12.5ns)で繰り返す信号しか等価サンプリングできないし、内部クロックに同期していなければならないので実用的ではないのですが、今後は1クロックを超える長さの等価サンプリングや、外部トリガへの同期、「内部クロックと同期していない信号」をサンプリングできるように改良していきたいと思います。

そのキーとなるのが、FPGAで実現するTDC回路になると気が付きました。

MCAの様子をアニメーションGIFにしてみた

HTML5 Canvasの画像を自動的にpngファイルに保存することができたので、300秒ごとに画像を取ってアニメーションGIFにしてみました。

スペクトラムが伸びていくのが見えます。

参考にしたのは、こちらのページです。感謝。

• Canvas上のイメージを画像ファイルとして保存する方法 https://oar.st40.xyz/article/133

FPGAに実装したMulti-Channel-Analyzer (MCA)が動くようになった

放射線の計測で使うMCA(Multi Channel Analyzer)が動くようになりました。

以前、ISE用に作ったものをVivadoに移植したものです。

前に作ったときと比べて、「規定の時間が経過すると自動的に計測終了する」「規定の時刻に達すると自動的に計測終了する」という2つのモードを作りました。

墨田区の某所で4時間測った結果を示します。

飛び出たピークがおそらくカリウム40のもの。(このピークは、塩化カリウムの試薬をNaIの近くの置くと変化するのでわかる)

その他、https://www.nirs.qst.go.jp/information/press/2011/08_05.pdf のページにあるスペクトラムとも見比べてみると、だいたい同じ形をしていて、左のほうにある小さいピークがBi-214、右のほうにある最後のピークがTl-208ではないかと思われます。

毎回Excelにエクスポートしてグラフ化するのは大変なので、HTML5 CanvasオシロにMCA機能を追加することにしました。

その結果が、こちら。

Web MCAとでも名付けましょうか。WebSocketでZYNQと通信し、リアルタイムにスペクトラムが更新されます。

Webオシロとはボタン一発で切り替えることができます。

あとは波形成型回路のパラメータ調整などもWebからできるようにしたいのですが。そのためにはWeb Canvasの描画ライブラリを拡張して、VCLみたいにパネルに乗せたりといった機能を付けないと厳しそうです。現在のJavaScriptのプログラムはコンポーネントの描画座標の足し算だらけになっていて、いよいよわけがわからなくなってきました。

TFAのポールゼロ回路の調整

前回の記事では、入力がステップ関数と仮定してCR-RC回路で整形した結果でした。

しかし、実際には入力は減衰しているのでCRで微分するとアンダーシュートが生じてしまいます。減衰時間が短いほど、アンダーシュートは顕著に出ます。

それを積分した結果の波形にもアンダーシュートは残ります。

アンダーシュートがあるとパルスの高さの誤差となるので、除去しなければなりません。

それを行うのがポールゼロ補償回路です。

具体的には、入力のCR微分回路にRpzという抵抗を付けます。（実際にはFPGAでディジタルフィルタで作ります）

Rpzが付くことで、微分回路の出力は、本来の微分出力と、入力を減衰させた信号の和となります。時間軸で見ればアンダーシュートする量に減衰した入力を足し合わせることで打ち消していることになります。

ラプラス変換で見れば伝達関数の分母が(1+sτ1)(1+sτ2)となっていたのを、うまいことまとめて(1+sτ)の形にしています。

実際にやってみましょう。

Cosmo-ZにNaIシンチレータをつなぎ、TFAをONにします。

茶色の波形が入力信号で、赤がTFAの出力です。パラメータはτd=τi=100ns、ゲインは2.718です。

入力信号の減衰が500nsくらいと速いので、アンダーシュートが出ています。

次の図は、τpz=3usに設定したものでず。全然消えていません。

次の図は、τpz=1usに設定したものでず。まだ消えていません。

τpz=0.5usにしてみました。少し小さくなってきたような気がします。

τpz=0.24usがちょうどアンダーシュートが消えるポイントでした。

逆に、これより短く(τpz=0.1us　↓)すると、だんだんテイルが伸びてきて、

さらに時定数を短くする(τpz=0.05us　↓)と、TFAの出力ゲインが設定より大きくなってしまいます。

そのため、τpzは波形を見ながら調整するのがベストです。

ポールゼロ補償を行うと、TFAの出力にはオフセットが乗ってしまいます。このオフセットを除去するのがBLR(ベースライン回復回路)という回路です。

これを有効にした波形が下の図のオレンジの波形(CH3)です。ベースラインが0Vになっていることがわかります。

τd=τi=40ns、τpd=0.240ns、gain=2.718としてNaIシンチレータからの波形を整形し、いくつかの波形を重ねて描いてみます。

元の入力波形(茶色)のパルスがさらに細くなり、滑らかになって出力されていることがわかります。

また、gain=2.718と設定したことにより、入力波形と出力波形は同じ高さになっています。

設定のコツとしては、

• τpzは最初は99くらいにしておく。
• τd=τi、gain=2.718を保ったまま、入力のパルスを望みの幅に整形する
• τpzを少しずつ小さくして、アンダーシュートが消えるぎりぎりのところに設定する

です。

ディジタルTiming Filter Amp (TFA)のパラメータ

放射線計測用のTFA(Timing Filter Amplifier)をFPGAに実装してみたわけですが、パラメータがτd,τpz,τi,gainと4つもあり、どういう意味かがよくわからなくなってきたので、久々にKnoll本を開いて勉強しなおしました。

TFAの存在意義というのは、下の図のような波形を出す「検出器＋プリアンプ」に対して、パルスの大きさと時間を正確に定めるためです。「検出器＋プリアンプ」は電荷をすべて取りきるために、比較的長い(50～100μs)の時定数で減衰する信号を出力します。

知りたいものは来たパルスの高さなのですが、前の信号のテイルが減衰しきる前に次のパルスが来てパイルアップすることが重大な問題となります。

そこで、CR微分回路を使って波形を鋭くします。

時定数が十分に短ければ、入力に対して出力は下の図のようになります。

元の波形の立ち上がり時間は短いので微分回路では減衰せずに、正しいパルスの立ち上がり幅を出力します。ゆっくりと立ち下がるテイルの部分は微分回路でフィルタされて理想的にはゼロになります。

しかし、微分回路はハイパスフィルタなので、出力はノイズまみれになってS/Nが悪化するのと、出力パルスの幅が鋭すぎて使いにくいという欠点から、微分回路の後ろに積分回路を入れてCR-RCという回路を構成して使います。

これで、幅がコントールできて、テイルの上に乗った影響をキャンセルして、元のパルスの高さを正しく反映したパルスとなります。

CR微分-RC積分回路の応答は次の式となります。

ここで、τdは微分回路の時定数、τiは積分回路の時定数です。

CR微分回路とRC積分回路の時定数を等しく設定した場合、上の式は分子分母が0になるので

となります。

入力がステップ関数だと仮定して、様々な時定数の場合の応答をExcelで計算すると、以下のようになります。

CR微分RC積分回路の時定数を等しい場合（青と黄色の線）、出力電圧は時刻τでピークとなり、ゲインは1/e=0.367となります。

パルスを鋭くしたいのであればτを小さくすればよいのですが、実際の計測波形の立ち上がり時間は0ではないので、立ち上がり時間より短くすると本来のパルスの高さより低くなってしまうので、限界があります。

つまり、時定数を等しくしてゲインを2.718にすれば、入力したステップ関数と同じ高さの整形された波形が出てくるのでしょう。

さて、Cosmo-Z MiniのDACで信号を発生させて、Cosmo-ZでサンプリングしてTFAの実験をしてみましょう。

Cosmo-Z Miniで振幅0.25Vの矩形波を出し、それをCosmo-ZのCH1に入力します。

TFAの設定は、gain=1、τd=2.5us、τi=2.5us、τpz=∞、に設定します。

茶色の波形が入力したステップ波形、赤の波形がTFAを通った波形です。

ゲインを2.718にすると、入力したステップ関数と同じ高さの出力波形となりました。TFAの出力のベースラインも0になっていて、直流が除去されています。

それでは、どこまでパルスを短くできるか試してみましょう。

まずは時定数1us。余裕です。

次は時定数0.5us。まだまだいけます。

時定数100ns。これも問題ありません。

時定数50ns。ディジタルであるがゆえの粗さが見えてきましたが、出力は綺麗な減衰カーブです。

時定数22nsが限度でした。これより短くするとディジタルフィルタの係数がオーバーフローしてしまうので、正確ではなくなってしまいます。

Cosmo-Zの波形成型回路は、ADCクロックが80MHzのとき、入力パルスを22nsまで細くすることができることがわかりました。

ディジタルTFAについてまとめます。

• 検出器の波形の減衰時間が50～100usと遅い場合に、パルスを鋭くして、パイルアップを除去するために使う
• ポールゼロ回路を使わないのであれば、τpz=∞とする
• τd=τiとして使うと、パルスのピークが時刻τに来るようになり、ゲインが1/2.718(=e)になる
• その場合、ゲインを2.718に設定すると、元のパルスの高さと整形後のパルスの高さが同じになる
• クロック80MHzの場合、22nsが正確に計算できる最小の時定数である

さて、このCR-RCフィルタ、放射線計測以外にも使える用途はあるでしょうか。

錦糸町駅前のビルのレンタルオフィスに本社と営業部門を移転しました

昨年12月に本郷の事務所を撤退した後、レンタル倉庫やコワーキングスペース、自宅をフル活用して、ミニマムな状態で事業を継続してまいりました。再び個人事業者に戻ったような気分です。

この9か月間、どうやって生きてきたかの片鱗を紹介します。

①まず、本拠地から遠い、辺鄙な場所にある広くて安い倉庫を借りて、倉庫の奥の方に古いトラ技や帳簿などめったに使用しないものをしまいました。その倉庫の浅いところに、ストックしておくべき段ボールや梱包材、次回の製造で使う電子部品など、月に1回程度取り出すものをしまいました。

この倉庫へは月一回、自転車かレンタカーで荷物を取りに行きます。

ところで、この倉庫は交通規制があって昼の3時以降は車が使えないという難易度の高い地域にあります。だから安いのかもしれませんが。気軽に車では出かけられません。

☀

②次に、近くのレンタル倉庫を2個借りました。普段使う商品発送用のダンボールや、マイナー製品の在庫、ちょっとした資材類は近くにしまっておきます。このレンタル倉庫にはほぼ毎日、何かを取りに行っています。

要するに、遠くて安い倉庫に使用頻度の少ないものを入れ、事業継続に必要な機材と当面の製造に必要な資材を近くのレンタル倉庫に入れ、自宅やコワーキングスペースを利用して製品の製造と開発を一人で行ってきたというわけです。

☀

③荷物の受け取りは「バーチャルオフィス」というサービスを利用し、平日の9:00～18:00までならば受取を代行してもらっていました。これでDigikeyからのUPSの受け取りも逃すことなく完璧に受け取ってくれます。

☀

④ 定型商品の発送はAmazonのFBAを利用して、在庫を置くスペースを省き、さらに1件1件の発送にかかる工数を削減しました。定型じゃない商品は1件1件心をこめて発送しています。

5つの小さな不動産(倉庫)と、様々なアウトソーシングを活用し、トータルの家賃＋サービス料をなんと10万円強に収めることに成功しました。

それに、荷物受取と商品の発送のための人を雇う必要もなくなり、財政的にも非常に楽になりました。

⑤ コワーキングスペースに入居することで「寂しさ」から解放されます。お互いにどんな事業をしているかはわからなくても、挨拶を交わすだけでも人は社会の中にいるような感覚を味わえます。寂しさを紛らわすために従業員を増やさなくてもよいのです。

このような感じで本当の意味でのリストラクチャリングを実行した結果、

• 1年間使わなかったものは今後もゼッタイに使わないという確信が持てた。
• 原材料(電子部品)の在庫は極力持たない。製品の形にして在庫を持つのがよい。
• アウトソーシングを活用すれば、事務員を雇わなくても回していける

という教訓を得ることができ、ミニマムな状態で本業に専念するコツをつかんできました。

皮下脂肪をぎりぎりまでそぎ落としたマッチョな感じで、最低限の経費で事業を回す実験をしてきたのですが、一日の中の多くの時間を倉庫との往復に使うようになり、さすがに疲弊してきたのも事実です。

また、借りている3つの倉庫はすべて1Fで、さらに海抜ゼロメートル地帯なので、洪水があったときに容易に水没してしまいます。安心・安全ではありませんね。

ある程度のコストをかけても良いからもう少し楽に進められないかと思い、バーチャルではなく、リアルなオフィスを借りることにしました。

といってもレンタルオフィスですが。

・・

今日からその部屋に入居しました。

それがこの高層ビル。奥のほうにあるガラス張りのビルです。

2Fのエレベータホールです。エレベータは全部で8基あります。たぶん。

レンタルオフィスの全体の入り口。

特電の部屋。

9㎡とあまり広くはないのですが、海外から輸入した基板や、自社製品、仕掛品、段ボールなどの梱包材などは十分においておける広さがあります。

それに、大雨でも水没しませんし、地震でも倒壊しないでしょう。

空調も完全にコントロールされていて、小さくて高価な「電子回路基板」を扱うには最適な環境といえます。

2重3重のロックがかけられる安心のセキュリティだし、受付を通らないと中に入れないうえ、特電がどこにあるかわからないので、不審者は入りにくい構造です。

当面の間は、商品の発送やサポートなどの営業部門をここで行っていこうと思います。

問題点としては、きっちりとした服装をしなければならないこと。Tシャツにサンダルだとさすがにビルに入りづらいでしょう。

無料の会議室を借りることもできるので、来客が来ても対応できます。

また、有料の会議室も借りることができるので、セミナーを開催することもできます。

いままでは雑居ビルを借りてきましたが、レンタルオフィスもなかなかいいかもしれません。

家賃は高めですが、ピッカピカの高級感、ほどほどの高層ビル、人がいるので寂しくない、荷物を受け取ってくれる、空調電気代込み、必要に応じて借りられる会議室、完璧なセキュリティ、コーヒーセットや机を用意しなくてよい、などソフト面が大変充実していると言えます。

ディジタルフィルタでTFAとBLRを組んでみた

ZYNQ搭載のADCボード「Cosmo-Z」はFPGAでリアルタイムに信号処理しながら計測するDAQです。

Cosmo-ZではZYNQのPL部に、リアルタイムなディジタル信号処理を追加することができます。

ディジタル信号処理の例として、放射線計測用のTFAとBLRという回路が動くようにしました。今回の記事は、ISEのころに作成した回路をVivadoへの移植したものとなります。

TFAというのはパルスの幅を鋭くするアンプでCR微分器とRC積分器を合わせたようなものです。

アナログで作るTFAは以下のような回路です。

電荷を検出するタイプの検出器では、基本的には微分波形を得るためにコンデンサを直列に入れたり抵抗でGNDにつないだりして階段状の波形をパルスに整形します。検出器の出力の変化がゆっくりだと、波形が出てきたタイミングが正確にわからないので鋭くする必要があります。コンデンサを2回通ると波形が歪むので、それを補正するポールゼロという補正なども行います。

そういったことを行うのがTFAです。

BLRというのはベースライン回復、つまり信号がないときのレベルを0Vにするための回路です。

FPGAに実装したTFAやBLRの詳細はこちらのページをご覧ください。

これらの「波形成型回路」をディジタルフィルタとして組んでみました。

まず、Cosmo-ZにNaIシンチレータをつなぎ、その辺を飛んでいる放射線の波形を見てみます。

うん。だいたいこんなもんですね。BLRを使うとDCのオフセットが消えるので見やすくなります。

ここでTFAをONにします。

便利なコマンドも作ってみました。

# csz_tfa -d 1 -p 0 -i 0.1 -g 1 on

上のコマンドで、微分時定数が1us、ポールゼロは0、積分時定数も1us、ゲインは1となります。

しかし、これは良いアイデアではありませんでした。3つの時定数とゲインは複雑に絡み合っていて、コマンドで調整するのは至難の業です。オシロで波形を見ながらつまみを回すようにして調整できるユーザインタフェースが必要だと本能的にわかりました。

いろいろ調整してみると、微分時定数が小さければ幅は鋭くなるのですが、小さすぎるとパルスが下がりきらないのに止めようとしてしまってゲインが小さくなります。

いろいろ調整をしてみます。

だいたい良いのですが、うーん、普通はNaIにTFAを使うことはないと思うので、上の結果にあまり意味はないのですが、TFAを入れるとノイズが消えてつるつるになりますね。

次はCFDを移植してみます。

Cosmo-Zの回路も完全Vivado化を達成

ZYNQ搭載の高速ADCボード「Cosmo-Z」の回路も完全にVivado化ができました。

Cosmo-Zは開発してから4年くらいが経ち、様々なお客様向けにカスタマイズを施したバージョンが多々あったのですが、なんとかメインストリームに取り込むことができそうになってきました。

Cosmo-Zの全体構成は下の図のように、CPUブロックとSignalProcessingブロックからできています。

画面に映っているコメントの文字列は、TCLスクリプトで読み取られ、グローバルに様々なIPのパラメータを変更するために使われます。

SignalProcessingブロックを開くと、信号処理の流れが見えます。

高速ADCでの計測データはadcblockというモジュールでデコードされ、AXI Streamとなってフィルタブロック、トリガブロックを経て計測モジュールへ送られます。

ユーザは、フィルタブロックとトリガブロックに自身の回路を追加することで、様々な実験に迅速に適応することができるというわけです。

実際にCosmo-Zにファンクションジェネレータをつないで波形を取ってみました。

まずは100kHzの矩形波をAgilentのオシロで測ったもの。

これをCosmo-Zで測ったもの。

電圧軸も時間軸も正しく表示されているようです。

次に、Cosmo-Z Miniで試してみます。Cosmo-ZはADCが12bit～16bitですが、Cosmo-Z Miniは14bitです。

まずは矩形波。

それから正弦波。

 

問題なさそうです。

ADCの分解能などが変わっても、FPGAの回路やファームウェアが差を吸収してくれました。

Cosmo-Z Miniの回路をNahiViva環境に移行した

VivadoのプロジェクトをNahiViva環境に移行したら、劇的にサイズが減少しました。

NahiVivaというのはTclで書かれたライブラリで、Vivadoのプロジェクト生成や、ビルドなどを楽に行うためのものです。例えば、子IPを変更したらShow IP Status→Run・・のプロセスを行わなければなりませんが、コマンド一発で行えます。

NahiVivaでNahiSaveというコマンドを打つと、プロジェクトをTcl化して保存します。このときBlock DesignはBDファイルではなく、BDファイルを生成するためのTclファイルにして保存するので、他のディレクトリに移行しても矛盾することなく、顧客への配布も楽にできるようになります。

また、Vivadoが生成したプロジェクトフォルダやバイナリファイルはすべて消しても良くなるので、ユーザが作ったコアなソースファイルだけを管理すればよくなり、プロジェクトのサイズが激減します。

☀

さて、御託はこのくらいにして、Cosmo-Z Miniの全回路をNahiViva環境に移行することができました。

Cosmo-Z Miniの現在の全体像を示します。

まず、TOPの回路。CPUと書かれた階層と、SignalProcessと、DACがあります。

CPUの中にはZYNQとAXI Interconnectが入ったCoreという階層、それからレジスタファイルがあります。

下の図がCosmo-Z Miniの信号処理系です。計測されたAD変換データはすべてAXI Streamになっていて、ADCBlockから出力され、フィルタやトリガといったロジックブロックを経由し、オリジナルなDMAコア(capture_top)に入っていきます。

ユーザは、このフィルタブロックとトリガブロックをカスタマイズすることで、オリジナルなFPGA計測器を作ることができるというわけです。

今日移植に成功したのがDACブロックです。

正弦波、パルス、疑似乱数を出すことができるモジュールなのですが、各波形発生かいろが別々に存在しているのですっきりしていません。今後置き換えを考えています。

☀

さて、このような規模だと結構なサイズのプロジェクトになると思います。

いったい、Vivadoのフォルダは何バイトくらいになると思いますか？

答えは、なんと2.2Mバイトでした。

僅か2MバイトでVivadoのこの規模の回路が出来上がってしまうのです。

ZIPで圧縮すれば380kバイト。フロッピーにも収まってしまいます。

NahiVivaに移行する前のプロジェクトフォルダは770MBあったので、

なんと0.28%にまで圧縮できたことになります。

そもそもVivadoのフォルダには不要なバイナリファイルや中間ファイルが多すぎるのです。

コアな状態に圧縮しても、VivadoでRunするときに様々なファイルは復元されるので、初回のビルド時間が2分程度伸びるだけです。

また、Vivadoは使っているうちにだんだんプロジェクトがおかしくなってきて謎のエラーやWarningが出るようになりますが、NahiVivaではいつでもプロジェクトフォルダを削除できるので、壊れたプロジェクトもすぐに戻ります。

ここまでのサイズ低減を行うことができたのは、VivadoにおけるBlock Designの子IPプロジェクトについての知見が得られたからです。

基本的に子プロジェクト(IP)に必要なファイルは、

• component.xml
• ユーザの作ったRTLソース
• xgui/〇〇.tcl
• xciファイル

だということがわかりました。

子IPの中でXILINXのIPを使う場合は.xciが必要ですが、.xcoは古いISEのCoreGenなので適当なVivadoに読み込ませてxciに変換すれば不要だし、vhoやxmlは不要であることがわかりました。xciだけ残しておけば他のファイルはすべて不要です。

こんな感じでgitを使ってVivadoのプロジェクトを管理し、最小限のソースのみでやりくりできるようになりました。

NahiVivaは

https://github.com/tokuden/NahiViva

から取得できます。

ぜひ使ってみてください。

VivadoでユーザIPの設定を一括で変える方法

VivadoのユーザIPは、パラメータを作ってBlock Design上からカスタマイズすることができます。

例えば、こういうBlock Designでadcblock_0をダブルクリックすると、

以下のようなパラメータの設定画面が開きます。

☀

ユーザIPが一つならこれでもよいのですが、ユーザIPが複数ある場合で、すべてのIPのパラメータを全部更新しなければならない場合、ひとつひとつ開いて設定していかなければならないので、大変面倒です。

例えば、Cosmo-Zは非常にたくさんの子IPブロックがあり、ADCの分解能やチャネル数をTCLスクリプトで一括変更できると便利だと思っていました。

そこで、「Block Designのコメントからパラメータを一括設定するTCLスクリプト」を作成しました。TCLのソースは本記事の末尾に書きます。

実は、Block Designにはユーザが任意のコメントを書くことができます。

何もないところで右クリックして、Create Commentを実行します。

するとBlock Designにコメントが書けるのでここに

CONFIGS:key1=value1[,key2=value2[,key3=value3]]...

という形式で設定したいパラメータのキーと値を書いていきます。

コメントは複数に分割しても構いません。

そして、vivadoのtclコンソールに本稿末の関数をコピペしてENTERを押し、

NahiConfigByComments

とタイプします。

すると、すべてのIP（VLNVがxilinx.com以外のもの）がスキャンされて、指定されたユーザ設定パラメータがあれば、その値が順番に変更されていきます。

NahiConfigByComments

ProcessComment:MAX_ADCCH <= 32
change /CPU/reg_files_0 : CONFIG.MAX_ADCCH <= 32
change /SignalProcess/TRIGGER/trigunit_0 : CONFIG.MAX_ADCCH <= 32
change /SignalProcess/adcblock_0 : CONFIG.MAX_ADCCH <= 32
change /SignalProcess/capture_top_0 : CONFIG.MAX_ADCCH <= 32
change /SignalProcess/particledetector_0 : CONFIG.MAX_ADCCH <= 32
change /SignalProcess/trigdelay_0 : CONFIG.MAX_ADCCH <= 32
ProcessComment:ADC_BITS <= 16
change /CPU/reg_files_0 : CONFIG.ADC_BITS <= 16
change /SignalProcess/TRIGGER/trigunit_0 : CONFIG.ADC_BITS <= 16
change /SignalProcess/adcblock_0 : CONFIG.ADC_BITS <= 16
change /SignalProcess/capture_top_0 : CONFIG.ADC_BITS <= 16
change /SignalProcess/particledetector_0 : CONFIG.ADC_BITS <= 16
change /SignalProcess/trigdelay_0 : CONFIG.ADC_BITS <= 16
ProcessComment:FPGA_VERSION <= 0x20190906
change /CPU/reg_files_0 : CONFIG.FPGA_VERSION <= 0x20190906
ProcessComment:USE_UPP <= true
change /CPU/reg_files_0 : CONFIG.USE_UPP <= true

さきほどのadcblock_0は、

CONFIGS:MAX_ADCCH=32,ADC_BITS=16,FPGA_VERSION=0x20190906,USE_UPP=true 

の設定により、以下のようにカスタマイズされました。

16進数のパラメータは0xを付け、チェックボックスはtrue,falseにします。

これで、以下のような項目数の多いIPブロックも自動的に設定できました。

ソースはこちら↓

続きを読む "VivadoでユーザIPの設定を一括で変える方法"

Cosmo-ZのFPGAソースをgitで管理するため再構築した

Cosmo-ZのFPGAには、従来型のCosmo-Z、Cosmo-Z Mini、お客様ごとのカスタマイズ版など、さまざまな版があります。

これらのソースをいままではgitなどのバージョン管理システムで管理していなかったので、フォルダごとの全コピーとdiffでなんとかやりとりしてきました。

ですが、Copy & diffにも限界を感じてきたので、gitで管理するためにNahiVivaを利用することにしました。

NahiVivaでVivadoプロジェクトを管理すると、次のようなメリットがあります

• Vivadoのプロジェクトフォルダはすべて消してしまってもいつでも復活できる
• 管理するのは以下のファイルのみなので、プロジェクトのアーカイブサイズが小さくなる
  
  • 自分で書いたFPGAのソース(VHDL,V)
  • プロジェクトの全体の設定が入ったTCL
  • Block Designを生成するためのTCL
  • 子IPの設定ファイル(component.xmlとxguiフォルダのtclとソース、XILINX IPのxci)

• フォルダの移動が自由にできるので、他人に渡すときにも楽になる
• 任意のバージョンのVivadoが開く

Vivadoのプロジェクトファイルをはじめ、tmpやcacheやhw、ip_user_files、srcsなどVivadoが生成したファイルはすべて消してもよくなります。

メインのプロジェクトのBlock Designに置いたIPは、tclに「生成方法」が取り込まれるので、xciの管理なども一切不要です。

bdファイルも不要になり、本当に最低限の必要なテキストファイルのみを管理すればよくなります。

プロジェクト開始前に、フォルダの状態は以下のようになっています。

ip_repoは子IPのつまったレポジトリです。

srcは細かいRTLや制約ファイルが入っています。

バッチファイルのopen_project_gui.cmdを実行すると、指定されたバージョンのVivadoが起動し、

まず、空のプロジェクトが作成されます。

そして、勝手にBlock Designが追加されて・・・

どんどん子IPや階層が追加されていって・・

勝手に配線がひかれます。

ここまで見ているだけでOKです。

出来上がったTopのデザインです。

この中のCPUモジュール。ZYNQのコアと、その周辺のレジスタファイルや、UARTの送信時にLEDを点滅させる回路などを置いてあります。

CPU Coreと書かれた中身。ZYNQのコアとAXI Interconnect、リセットモジュールがあります。

下の図は信号処理回路の中身。Cosmo-Zユーザは、フィルタとトリガを、自分の実験に合うようにカスタマイズすればよいように階層化しています。

プロジェクトが生成されたら、TclコンソールでNahiRunとコマンドを打てば、自動的にbitStreamが生成され、プロジェクト名.run/impl_1から表にコピーされてきます。

☀

このプロジェクトのサイズは、わずか5.97Mバイトで、ほとんどがテキストファイルです。

ZYNQのコアが入っているデザインでもNahiVivaはうまく動きました。

Vivadoのプロジェクト全体だと300Mバイトくらいになりますが、ユーザが保存するべき本当に必要な部分を抜き出すと6Mバイトくらいに圧縮できるのです。しかも、6Mバイトの大半はXILINXのIPで生成されたXMLなどなので、頑張れば1Mバイトくらいにまで減らせられると思います。

Vivadoのプロジェクトを小さくして管理したいなら、ぜひともNahiVivaをご検討ください。