2019.09.17

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

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

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

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

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

Czv1

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

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

Czv2

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

 

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

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

2

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

Csz5

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

 

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

まずは矩形波。

Csv4

それから正弦波。

Csv3

1 

問題なさそうです。

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

 

| | コメント (0)

2019.09.07

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があります。

Top

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

Cpu

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

Signalprocess

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

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

Dac

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

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

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

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

After

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

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

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

Before

なんと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のプロジェクトを管理し、最小限のソースのみでやりくりできるようになりました。

Git

NahiVivaは

https://github.com/tokuden/NahiViva

から取得できます。

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

 

| | コメント (0)

2019.09.06

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

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

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

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

Param2

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

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

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

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

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

Param6

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

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

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

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

Param7

そして、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

Param3

さきほどのadcblock_0は、

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

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

Param4

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

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

Param5

ソースはこちら↓

 

» 続きを読む

| | コメント (0)

2019.09.05

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ファイルも不要になり、本当に最低限の必要なテキストファイルのみを管理すればよくなります。

 

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

Cz1

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

Cz1_iprepo

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

Cz1_src

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

Cz2

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

Cz3

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

Cz4

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

Cz5

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

Cz6

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

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

Cz8

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

Cz9

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

Cz11

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

Cz12

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

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

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

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

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

| | コメント (0)

2019.08.29

本物のオシロが壊れた

愛用していたAgilentのオシロが壊れてしまいました。

久しぶりに電源を入れたら、ボタンに埋め込まれたLEDが一瞬だけ点灯して消灯します。

画面は映りません。

Keysightのサポートに修理依頼をしてシリアル番号を伝えたら、「2019年10月まで保証期間がありますから、無償で修理いたします」と折り返し電話が来ました。保証書をなくしてしまったのに、メーカーさんのほうでシリアル番号から調べてくれたようです。

しかも、サービスマンの方が事務所まで引き取りに来てくれました。

まさに、神対応!

次もAgilentを買いたくなります。

| | コメント (0)

2019.08.28

WebCanvasオシロをリリースしました

HTML5で動くオシロアプリをリリースします。

当面の間は、Cosmo-Z Mini用です。

Cszmini

なぜならば、Cosmo-ZにはADCの分解能や電圧フルスケールの設定を機器ごとに記録しておく仕組みがまだないからです。

Cosmo-Z Miniなら14bit精度で±0.5Vフルスケールと決めてあるので、そのスケールに合うようにプログラムをハードコー@℃してしまっているからなのです。

アップデートのやり方はとても簡単です。

下記のページにある

http://www.cosmoz.jp/update.html

update-cszminiというファイルを作り、実行するだけです。

今年出荷したCosmo-Z Miniはupdate-cszminiは/rootに入っているので、起動したら/root/update-cszminiを実行するだけでOKです。

root@cszmini:~# /update-cszmini
Check and download system firmware...
Check and download libraries...
Check and download Web interface update...
Check and download project source.
アプリケーションをアップデートしました
BOOT.BINを置き換えますか?
実行する場合は yes と入力して下さい.
ここで何も書かずにENTERを押す
更新は行われませんでした。

これでWebSocketの波形サーバやライブラリなどがインストールされ、システム起動時に自動的に実行されます。

Webosc

ユーザはhttp://cszmini/にアクセスするだけで、現在の波形がすぐに見られるようになりました。

 

| | コメント (0)

2019.08.27

時間軸の拡大・縮小もできるようになった

ZYNQ+高速ADCで動くHTML5 Webオシロアプリで、時間軸スケールと、プレトリガの長さ変更できるようにしました。

下の図は正弦波。80MHzでサンプリングしていることが画面真ん中の上に書かれています。

Ev10

時間軸スケールを変えて長時間見ていくと・・・

Ev11

サンプリングレートが切り替わります。

Ev12

どうせWebの画面は横1000ピクセルくらいなので、何万ポイントも送っても表示しきれません。

確かめたところ、WebSocketのライブラリ「libwebsockets」では巨大なデータを送信しても問題なく転送してくれるようですが、長時間(といっても100μのオーダーでも)見る場合には自動的にサンプリングレートを下げてデータ量を削減するようにしています。

だんだんオシロっぽくなってきたぞ。

今まで難解だったCosmo-Zの使い方が滅茶苦茶わかりやすくなって、我ながら驚いています。

やはり計測ツールのユーザインタフェースは標準的な「オシロスコープ」に似せて作るのが一番良いですね。

オシロ互換UIなら説明書がいらないし。

| | コメント (0)

2019.08.26

トリガの操作がスムーズにできるようにした

昨日、トリガをWebから操作できるようにしたのですが、カクカクとうごいてスムーズではありませんでした。

Chromeのログを見てみると、頻繁にWebSocketが切れている模様です。

Connect_error

信号が入らなくてトリガ待ちになっている状態で、別のコマンド(例えばトリガ設定)が入るとこのように接続が切れるということがわかってきました。

おそらく、libweboscketsがWRITEの処理中に次のパケットを受信すると、受信したコマンドを保持している変数が書き変わってしまうのでしょう。私のプログラムの作り方の問題です。

そこで、即興でキューの仕組みを作って、受信したコマンドをキューに入れて順番に処理するようにしたら解決しました。

これでトリガ電圧を変更しても接続が切れることなく、スムーズにできます。

Ev9

| | コメント (0)

«Webからトリガの設定が一応できるようになった