2019.11.09

RTLを語る会16に行ってきた

RTLを語る会16に参加してきました。

まず気になったのは、ReGenというコントロール・ステータス・レジスタを自動生成する話。Excelの表からVerilogのコードを出力してくれるのは便利そう。

 

一番気になったのはひでみさんの、RISC-Vをデバッグする話。

デバッグのコアにはOpenOCDを使い、JTAGケーブルはFT2232で、ユーザインタフェースはVSCodeのプラグインを作ったとのこと。RISC-Vのデバッグ仕様書を読んでデバッグ関係のレジスタをちゃんと実装すれば動きそうですね。これはぜひ試してみたい。

 

調べてみたらOpenOCDはARM7、ARM9、XScale、Cortex、ARMv7、ARMv8だけではなくRISC-Vにも対応しているようですね。OpenOCDのソースを見てみると、確かにデバッガのコードらしきものがあります。足回りもJ-LinkやSegger、ST-LINK、CMSIS-DAPなどいろいろなUSB-JTAGに対応している。うーむすごい。

一方、MITOUJTAGのCPUデバッグ機能は、ARM7の他は、MIPS、SH2、SH2A、SH4、SH4A、RX62くらいにしか対応してこなかったので、このOpenOCDのCPUデバッグ対応品種は魅力的に映ります。

しかしながら今からARMv8アーキテクチャとかCMSIS-DAPとか勉強するには時間がないので、MITOUJTAGからOpenOCDに接続して、うまいことデバッグ機能を拡張できないかどうかを考えることにします。

つまり、OpenOCDの上位にあるコマンドの受け付ける部分をMITOUJTAGからリモート接続して発行し、OpenOCDの足回り -JTAGケーブルの部分- を追加してMITOUJTAGに制御を戻して操作するというわけです。これならOpenOCDの豊富なCPUデバッグ機能を、MITOUJTAG経由で操作できるようになるはずです。

CPUのデバッガは逆アセンブラを内蔵させるのがとても大変だったのですが、うまいことgdbとも連携し、VSCodeとも連携させれば、RX、SHから最新のARMまですべてに対応したデバッガができるんじゃないかなと妄想しています。来年時間があれば試してみたい。

| | コメント (0)

2019.11.08

Cosmo-Zの16bit版をVivadoに移行

Cosmo-Zの16bit版を作り、その設計をISEからVivadoへ移行しました。

Csz16

今回のCosmo-Zはトリガボード付きです。

Csz16_1

ADCの分解能を12bit、14bit、16bitと切り替えるには上の赤で囲ったVivadoのコメントの部分を書き換えればよいようにTCLスクリプトを組みました。

125MHz 16bitだとAD変換結果は完全には止まらず、下の図のような正規分布となります。

16bit_bunpu

1LSBが30μVで半値幅は7LSBくらいなので、入力換算ノイズはざっと210μVppとなります。

正弦波を入れたときのスペクトラムを見ると、極めて綺麗で、高調波などは見当たりません。

16bit_fft

歪率は-80dB以下といってよいでしょう。

Cosmo-Zの16bit版は原価がすごくかかるので、失敗すると大きな痛手となります。これまでのところCosmo-Zは100台ほど作りましたが、
実装屋さんが良いのか、こんなにたくさんの部品があるのに実装ミスは0です。今回も十分満足な性能に仕上がりました。

 

| | コメント (0)

2019.11.06

ZYNQのスタンバイモード中にPLは動いているか

ZYNQのスタンバイモード時に何が起きているかを詳しく調べてみました。

まず、JTAGバウンダリスキャンを使ってUARTとDDR3の信号を見たところ、/sys/power/stateドライバを操作されてから実際にスタンバイするまでの時間は150msくらいと推定されます。復帰はさらに早く数十ms以内でした。

Linuxのコンソールに戻れるので、完全にシャットダウンするよりも圧倒的に早く戻れます。

Stdby3

スタンバイモードでは、DDR3の信号はRAS=L、CAS=L、WE=H、CS=H、CKE=Lで停止しているようです。

 

気になるのはPLも一緒に停止しているかどうかです。

PLが停止してしまったらEMIOを通したUARTからの復帰ができないのでそんなことはないと思うのですが・・

念のため、PLから各部のクロック信号を出してみたところ、MMCMを経由したクロックは停止していて、それ以外のクロックは極端に遅くなっていました。

Stdby4

実際にオシロで測ってみると、PSからPLへ送られるクロックが100MHzのものは3.33MHzになり、250MHZのものは8.33MHzになっていました。

スタンバイ前↓

Stdby5

スタンバイ後↓

Stdby6

つまり、FCLKが30分の1の速度になってしまっているのです。3.3MHzではMMCMはロックできないから動作を停止したのでしょう。

結論を言うと、

  • スタンバイモードにしてもPLは停止しない
  • PSからのクロックが怪しくなるので、PSクロックを使わない設計にするべし
  • 当然ながらPLからもDDR3メモリは使えないと心得るべし

です。

PSが動いていることが確認できたので、例えばEMIO経由のGPIOで起こすようにしておけば、CPUは常にスタンバイモードにしてPLだけで計測しておいて、1分ごとにCPUを起こしてちょっと統計とか通信をしてまた眠るというアプリが作れそうです。

| | コメント (0)

2019.11.05

ZYNQの低消費電力モードを試してみた

ZYNQを使った高速ADCのシステムを特注で作っていて、消費電力を半分しなければならないという課題に直面しました。

Cszminics

ADCや周辺回路の消費電力を細かくチェックして、あとはZYNQ自体の消費電力をどこまで減らすことができるかという先の見えないチャレンジとなりました。

ZYNQ自体には各部のクロックを止めたりしてこまめに消費電力を削減する機能はあるようなのですが、究極的にはWFIという命令を実行してスタンバイモードに入れるのが最強のようです。たどり着いたのがXILINX Wikiのページです。

ユーザアプリからWFI命令をいきなり実行するのではなく、ZYNQ版Linuxには最初からパワーマネジメントの機能が入っているようです。

使い方はとても簡単で、

echo mem > /sys/power/state

とやるだけです。

ここでmemって何?と疑問に思うでしょう。この/sys/power/stateというのはデバイスドライバになっていて、可能な引数にはmem、standby、diskの3つがあるようです。standbyというのは単純に低消費電力モードに入るもので、diskはノートPCのハイバネーションモードのようなものだそうですが、ZYNQではサポートしていません。

3つの引数のうちZYNQでサポートしているのはmemだけで、DDR3メモリが停止してPSがスタンバイモードに入ります。DDR3は停止するのでプログラムをOCMに退避してからスタンバイモードに入るそうです。

下の図はmem、standby、diskの3つの低消費電力モードを試してみた結果です。

Stdby1

スタンバイモードからの復帰にはUARTによる方法と、GPIOによる方法、デバッガによる方法の3つがあります。

何もせずに使えるのはUARTによる方法だと思います。やり方は、

echo enabled > /sys/devices/soc0/amba/e0000000.serial/tty/ttyPS0/power/wakeup

をあらかじめ実行しておくこと。これだけです。

その後、

echo mem > /sys/power/state

で、ZYNQはスタンバイモードに入り、何かキーを押すと復旧します。

どのくらい消費電力が減ったかといえば、大本の5V電源で890mAあった消費電流が560mAに減りました。約1.6Wの電力削減です。PSが完全に停止するのと、DDR3メモリを止めるのでこれくらいの削減ができるのでしょう。

DDR3メモリの内容を安全に退避しているはずなのですが、スタンバイに入るのも復帰するのも一瞬で、復帰したら何事もなかったのように計測が続きました。

スタンバイに入るときと出た後でFPGAがどう動いているのかをMITOUJTAGを使ってみてみました。

Stdby2

驚くべきことに、スタンバイ中でもJTAGバウンダリスキャンは動きました

で、復帰するとすぐに元の動作に戻るはずなのですが、どうやらディゼーブルにしていたADCのチャネルも復旧しています。

スタンバイ中にPLがどうなっているのかは、もう少し解析したほうがよいかもしれません。

なお、Linuxのカーネルを構築する際に

  • CONFIG_CPU_IDLE
  • CONFIG_CPU_IDLE_GOV_LADDER
  • CONFIG_CPU_IDLE_GOV_MENU

というオプションを有効にしておけばcpuidleドライバが働いてIDLE時にWFI命令を実行して低消費電力モードに入るという情報もありましたが、全く効果は実感できませんでした。

 

| | コメント (0)

2019.11.02

Cosmo-Zのトリガボード対応アクリルケース

実装の上がってきたCosmo-Zをアクリルケースに納めました。

アクリルの保護フィルムはもったいないので剥がしていません。出荷時にはがすことにします。

Csz_case_1

どういうわけかFANが在庫切れだったので、FAN付きはとりあえず1台のみです。

Csz_case_3

今回はトリガボードを装着した状態でフロントパネルを閉じられるよう、トリガボード用のフロントパネルも設計しました。

Csz_case_2

 

 

| | コメント (0)

2019.10.29

Cosmo-Z 6台の実装が上がってきた

Cosmo-Z 6台の実装が上がってきました。

Csz_6pcs

これから出荷検査をし、今月中に3台出荷するのが目標です。

| | コメント (0)

2019.10.14

ZYNQのLinuxにおける無線LANの速度を測ってみた

先日の検証でElecomのWDC-150SU2MがZYNQ Linuxから動くようになったので、ZYNQのLinuxから無線LANを使った場合どのくらいの速度が出るのかを、様々なWiFiアダプタで調査してみました。

使ったボードはZynqberryで、OSはUbuntu Linux 18.04です。

Zb_wifis

現状、ARM版Linuxで動くUSB-Wifiアダプタというと正直あまり多くないのが事実です。

上の写真のWiFiアダプタは、左から順にGW-USNano2、WDC-150SU2M、TL-WN725N、WLI-UC-GNM2です。入手できてARM版Liunxから使えるアダプタは現時点でこのくらいしかありません。

最近ではGW-USNano2も入手できなくなってきたので、これらのWiFiアダプタの実力を測り、GW-USNano2の後継となる品番を選定するのが目的です。

無線LAN親機にはTP-Linkを使いました。

Tplink

(画像はAmazonより)


まず、GW-USNANO2Aです。nmcliで接続の状況を確かめます。

root@zynqberry:~# nmcli device wifi
IN-USE SSID MODE CHAN RATE SIGNAL BARS SECURITY
* TP-Link_XXXX Infra 8 405 Mbit/s 72 *** WPA1 WPA2

速度の測定方法ですが、LANはFTPサーバを使いますが、今回はWANへの通信速度も測ることにしました。

Windowsではhttp://fast.com/jaとか回線速度測定サイトがいっぱいあるのですが、Linuxにはspeedtestという回線速度を測るアプリがあるので、これを使ってみます。

使い方は、speedtest --server サーバ番号 です。

サーバ番号はspeedtest --list | grep Japanとすれば日本にあるサーバの一覧が取得できるので、近くて速そうなサーバを選んでテストします。

Serverlist

SINETに20Gで接続されたOPEN Projectというのが強そうなので、これを使ってみます。

root@zynqberry:~# speedtest --server 15047
Retrieving speedtest.net configuration...
Testing from Fujitsu (124.26.42.4)...
Retrieving speedtest.net server list...
Retrieving information for the selected server...
Hosted by OPEN Project (via 20G SINET) (Tokyo) [6.34 km]: 14.114 ms
Testing download speed................................................................................
Download: 4.21 Mbit/s
Testing upload speed......................................................................................................
Upload: 30.11 Mbit/s

WANへのダウンロードは4.21Mbit/sで、アップロードは30.11Mbit/sと出ました。

LAN上でのFTPの速度はPUTが4.9MbpsでGETが5.9Mbpsでした。WANのほうが速いですね。パケットがロスしているとか、再送とかのタイミングの問題なのでしょうか。


次に、切り替え候補本命のWDC-150SU2Mを試します。

Hosted by OPEN Project (via 20G SINET) (Tokyo) [6.34 km]: 15.966 ms
Testing download speed................................................................................
Download: 23.55 Mbit/s
Testing upload speed......................................................................................................
Upload: 27.19 Mbit/s

上り下りとも25Mbps前後出ていました。

FTPもPUTが28Mbps、GETが21Mbpsと4つの中では最優秀でした。


次はTL-WN725Nです。筐体金属部分が金色に光っていて格好いいのですが、その実力は如何に。

root@zynqberry:/ramdisk# nmcli device wifi
IN-USE SSID MODE CHAN RATE SIGNAL BARS SECURITY
* TP-Link_5D26 Infra 8 44 Mbit/s 93 **** WPA1 WPA2
Hosted by OPEN Project (via 20G SINET) (Tokyo) [6.34 km]: 19.176 ms
Testing download speed................................................................................
Download: 18.48 Mbit/s
Testing upload speed......................................................................................................
Upload: 22.74 Mbit/s

speedtestでは20Mbps前後を叩き出しています。

FTPの速度はPUTが26Mbps、GETが21Mbps前後でした。


最後はWLI-UC-GNM2。Ralink RT3070を使っているようです。

このWiFiアダプタではなぜかspeedtestツールがうまく動きませんでした。

FTPはPUTが14Mbps、GETが23Mbpsと中間の性能でした。

結論としては、私の手元にあった4種類のWiFiアダプタの中ではWDC-150SU2Mがベストでした。

WDC-150SU2Mで使われているWiFiチップ「RTL8188EUS」のドライバがwpa_supplicantに対応していないらしく、Ubuntu 14の頃はなかなかうまく動かなかったのですが、Ubuntu 18になってNetworkManager(nmcli)を使うようになってからはすんなりと動くようになりました。

私の環境ではZynqberry + Ubuntu18なのでWDC-150SU2Mが素直に動きましたが、PetaLinuxやDebianを使っている方はどうなるかはわかりません。やはり、Ubuntu 18最高です!

 

| | コメント (0)

2019.10.12

台風到来

台風が来ました!

15:00~16:00ごろにかけて、錦糸町駅前~隅田川沿いまで自転車で走ってきました。

いつもは人通りと、違法駐車でいっぱいの錦糸町駅前ですが、閑散としています。

Taifu2

Taifu1

人っ子一人、違法駐車1台もいません。

空いているお店はコンビニとハナマサくらいでした。ありがたいことにハナマサは開いていたので、昨日のうちに食材を調達できなかった場合でも飢えずにすむかもしれませんね。(なひたふは前日におでんの具材を買っておいたので大丈夫ですよ。)

本当にどのお店もみんな臨時休業。

隅田川まで来てみると、見たことがないほどの水量。ただ、川の様子を見に来たひとが結構います。

Taifu4

普段はランナーがジョギングしている隅田川テラスもすっかり冠水。

Taifu6

階段の下まで降りられません。

Taifu3

ベンチも水没。

Taifu5

荒川と隅田川の堤防が持ってくれることを祈ります。

| | コメント (0)

«台風への備え