大量のコントロール・ステータス・レジスタをVivadoで作る方法

FPGAの中に機能をコントロールするためのレジスタを作り、そのレジスタをCPU(PL)から操作するようなシステムを効率的に作るにはどうしたらよいでしょうか。

つまり、

if(wr_en(0) = '1') then
    reg0 <= axi_wdata;
end if;
if(wr_en(1) = '1') then
    reg1 <= axi_wdata;
end if;
if(wr_en(2) = '1') then
    reg2 <= axi_wdata;
end if;
if(wr_en(3) = '1') then
    reg3 <= axi_wdata;
end if;
・・・

こういう場合です。

作られたレジスタの値をIPインテグレータの別のモジュールで使いたい場合、IPIのブロックから大量のレジスタの線が出ていくことになり、ごちゃごちゃになってしまいます。

書き込みだけではなく、読み出し用のステータスレジスタもたくさんある場合を考えてみてください。

こういうレジスタがたくさんある場合、VivadoのIPインテグレータではどうするのがベストでしょうか。

AXI Liteのバスを作って、各モジュールのコントロールレジスタはモジュール内に作るというのも一つの手段だと思います。

別の解決方法としては、インタフェースを作って、その中にすべてのレジスタを放り込むこむというのも良いのではないかと思います。

次の図は、Cosmo-Zの内部回路のものです。

CSRと書かれたバスが、このようなレジスタをまとめたインタフェースとなっています。
※CSRはControl Status Registerの意味

広げてみると・・

と、画面に収まりきらないほどのレジスタが含まれています。

Cosmo-Zは、32bit×64本のコントロール・ステータス・レジスタがあるので、128個のポートが存在しているわけです。

これらのたくさんのレジスタを纏めて「インタフェース」化して、ADCやCAPTURE、DSPなどの各モジュールに分配しようというわけです。

ただ、Vivadoでポート数の多いインタフェースを作るのはとても面倒です。標準的なInterface Editor（下の画面。File→Open IP-XACT Fileで開ける)で編集するのはしんどいし、テキストエディタで編集しようにもXMLなので、かえって面倒になります。

特電のアルバイトさんが、64種32bit×2のレジスタをインタフェースとして登録してくれました。

実際にやってみたところ、Vivadoのインタフェースは単一の信号とは違って分岐できないという問題に当たりましたが、CSR InterconnectというIPコアを作ってこのCSRバスを分岐させるようにして解決してくれました。

これで、Cosmo-ZデザインをVivado化する上での困難がすべて解消できました。

感謝感謝です。

Artix-7ボード用のHDMI/CSI入出力ボード

Artix-7ボード用のHDMI/CSI入出力ボードを、アルバイトさんが設計してくれました。

Arduinoの形状をしていますが、特に意味はありません。このボードの上に特電Artix-7ボード

を乗せると、Artix-7ボードからHDMIを出力したり入力したりする実験が行えるというものです。また、このボードにはCSIという汎用のカメラ用インタフェースが乗っているので、RaspberryPiのカメラなどをつなげることができるようになります。

基板は4層で、部品は表面だけに実装しています。

XILINXの7シリーズは、IO規格でTMDS33をサポートしているので、FPGAの端子からHDMIに直結することができるため、このように基板自体はとてもすっきりとしています。

FPGAの中身の回路はどうするのかという問題がありますが、最近はArtix-7ボード用のサンプルデザインをVivadoのIPインテグレータで書こうとしています。

上の図の赤い枠で囲った部分に注目していただきたいのですが、EZ-USB FX3コアと、AXIデータソースがInterconnectで2:1にマルチプレクスされて、MIGへとつながっています。

特電のサンプルアプリはAXIを使うようになったので、XILINXの標準のHDMIコアがさくっとつなげられるようになるのではないかと思います。

この基板を、実装費用も含めて低コストで提供できれば、Artix-7ボードの「おまけ」として頒布したいと思います。

VivadoのAXI Interconnectでいろいろハマる

ついに、Artix-7上で、DDR3コントローラとUSB3.0コントローラをAXIでつなぎ、横からInterconnect経由でいろいろメモリの内容を操作するためのサンプルデザインができました。

これを実現するには、かなーり苦労しました。

先週「できた！」と喜んでいたのは、AXIインターコネクトが1:1で接続されているものだったので実は、n:1接続にするとうまく動かなかったりします。USBからDDR3メモリに読み書きするだけなので、あまり役に立ちませんでした。

今日、公開するサンプルデザインは、AXIインタコネクトが2:1なので、何かの役には立つと思います。

このインタコネクトは、EZ-USB FX3 IPコアとAXIトラフィックジェネレータを2:1でブレンドして、MIGメモリコントローラに渡しています。トラフィックジェネレータが32bitデータバスなので、インタコネクトの内部はかなり複雑なものが入ってきています。

XILINXのAXIインタコネクトコアは良くできていて、前後につながるバスの特性を理解して、いろいろなモジュールを自動で追加していくようです。バス幅変換がある場合は、カプラの中にauto_usというコアが入るようです。

この１～２週間、相当ハマっていたことを以下に述べます。

• 自作のマスタとスレーブ(インタコネクト)で、アドレスの範囲の一致させなければならない
• マスタが先にarvalidを立ち上げるべし。arreadyはスレーブが後から出すので、arrreadyが来たらarvalidを上げようなんて控えめな考え方をしているといつまでたってもトランザクションが開始しないなんてことに。
• インタコネクトが入ると、ARID、AWIDなどのバス幅が変わる。そのため、自作コアはAXIのIDの幅を可変させられるようにしなければならない。
• MIGのMMCM_LOCKEDなどの信号は、XILINXが用意しているリセットコアを使う。
• AXIインタコネクトのRESETは2種類あって、リセットコアが出すインタコネクトリセットとペリフェラルリセットを使い分けてつなぐこと

リセットのつなぎ方などは、上の図を参考にしてください。

アドレスエディタというのは、これです。

それから、XILINXのAXI Traffic Generatorコアですが、詳しいことはわかりませんが、テスト用トラフィックを生成してくれるものなのでしょう。添付の図のような設定で使ったら、

↓こういうデータを出力してくれました。

これでようやくVivadoがわかってきました。

AXIやVivadoの勉強に最適なArtix-7ボードはこちらです。USB3.0で通信するためのコアが付いているので、画像キャプチャや、HDMI出力なんかに便利に使えると思います。

青函トンネルでのミューオン測定結果

やっぱ青函トンネルに潜ったら、宇宙線を測りたくなりますよね。

先週の日曜日に、５台のプラスチックシンチレータ＆MPCCで測った結果の解析をしてみました。

まず、奥津軽いまべつ駅を出てから１分ごとのカウント数を測ってみた結果が下のグラフですが、昨日のブログで書いたとおり、このままでは青函トンネルは全然見えていません。

奥津軽いまべつ駅を出てから3分くらいでトンネルに入り、30分弱くらいで北海道に出るのですが・・・全然わからないですね。

さて、プラスチックシンチレータが発光する原因は、だいたいはγ線かβ線かミューオンです。そこで会社で、K40の線源（塩化カリウム。要するに減塩しお）を使って、K40の有無によるスペクトラムの違いを見てみると・・

この検出器では、およそ680以下の部分でK40からのγ線が見えているということになります。逆に、700以上を高さのパルスだけを測れば、ガンマ線やβ線の影響は受けにくく、ミューオンだけが見えるだろうと考えられます。

次の図は、新幹線の中で奥津軽いまべる～函館新北斗間で測ったスペクトラム全体です。

まぁ、このグラフを見ても特にわからないですが、700以上の高エネルギー成分と、700未満の低エネルギー成分に分けて、1分ごとのカウント数の推移を見てみようというわけです。

まずは、低エネルギーの成分。青函トンネルの中のほうがむしろ多いという結果になりました。これはコンクリートに由来するカリウムから出ているガンマ線を見ているものと思われます。

次は高エネルギーの成分。これこそが見たかったミューオンと思われるものです。

青函トンネルを越えてからも２回ほどミューオンが減っている場所があります。Googleマップで見てみると、青函トンネルを出てから「知床信号所」というところで一度地上に出て、再びトンネルに入っているようです。

その後、木古内町で地上に出て駅に停車。再びトンネルに潜って出て、函館新北斗駅というわけです。

地図と、線量をプロットしてみると・・

青函トンネルと、その続くトンネル内でミューオンが減る効果を見ることができました。ミューオンの数は地表からの深さを示しているので、知床信号所と木古内の間のトンネルの深さは地下100mくらいかな・・なんてこともわかります。

面白いのは、トンネル内ではむしろガンマ線と思われる低エネルギーの成分が増えていることです。トンネルの上にある山の高さと一致しているような形を示しています。

これは何を意味しているのでしょう。カリウムやウランが見えているのでしょうか！？

青函トンネルで宇宙線を測定してきました

家族旅行で、「はやぶさ」に乗って北海道へいってきました。

青函トンネルをくぐるので、せっかくなので宇宙線を測定してきました。

このとおり、新幹線の座席テーブルの上にZYNQ搭載ADCボード「Cosmo-Z」と、5台のシンチレーション検出器が乗っています。

この5台の検出器でガンマ線や宇宙線のミューオンを測ろうというものです。ミューオンは上空から降ってきているので、地下深くでは数が減るはずです。

ならば、青函トンネルのような深いところではより一層数が減っているはず・・と思い、この旅行に検出器を持っていくことを計画していたのです。

(Wikipediaより)

最大深度は海底下100mということなので、240m分の厚みがあります。

以前にも地下鉄大江戸線や東海道新幹線で測ったことはあったのですが、今回は検出器が5台に増え、もしかしたら飛来方向も少しはわかるようになったかもしれません。

「奥津軽いまべつ駅」を出てから50分間のカウント数を1分ごとに計測しました。

このグラフはミューオンだけではなくコンクリート由来のγ線とか、MPPCのダークカウントとかも相当含まれています。

それらを含んで測定しているので、最初の30分間（つまりトンネルの中）のほうが、若干、カウント数が多いという結果になりました。ダークカウントの量は変わらないでしょうから、ガンマ線の数がミューオンよりもかなり多いのでしょう。

下のグラフは、測定した結果から再現したスペクトラムです。

ミューオンによるパルスは、このスペクトラムの右のほうにごくわずかにいるのでしょう。

Cosmo-Zは、ただのデジタルMCAや、カウント数計とは異なり、観測された波形の1つ1つを記録しています。

パルスの形とともに計測開始後何ns目に起きたイベントかというのを全て記録しているので、後日、データ処理して1分ごとのミューオント数を取り出せるでしょう。

MPPCとFPGAで宇宙線検出器を作った

持ち運びに便利な宇宙線検出器ができました。

この積みあがった黒い箱の中にプラスチックシンチレータとMPPCと高速アンプが入っていて、

そこから出た同軸ケーブルがZYNQ搭載のADCボード「Cosmo-Z」へとつながっています。

プラスチックシンチレータというのは、β線やミューオンなどの荷電粒子が入ると光るやつで、MPPCというのは微弱光用のセンサです。これらを組み合わせると、宇宙線などの荷電粒子センサになるというわけです。(検出しているのはミューオンだけじゃないけど)

基板を輪ゴムで止めているのかと思うかもしれませんが、この輪ゴムというのが絶妙な力加減を発揮してくれる弾性体であることに気が付きました。

真ん中に基板を寄せてくれるし、振動からやさしく保護してくれるし、MPPCのガラス面をぴたっとシンチレータに押し付けてくれるし、輪ゴム最高！です。

MPPCからの信号は、下の図のような感じで10μ秒に10～20発くらい出てくるのですが、ほとんどがダークカウントという偽のイベントです。

よく見ると、濃さが段になっているのがわかると思います。この1つの段が、フォトン1個分の電圧に相当します。

この信号をFPGAで処理したいのですが、Cosmo-Z（コスモゼット）には最大125MHzサンプリングの高速ADCが乗っているので、高速な信号をキャプチャしてFPGAで処理するにはたいへん便利です。

FPGAといっても、ARMプロセッサ搭載のZYNQなので、波形の統計処理までオンチップでやってくれます。

125MHzのADCはメイン基板に8ch(最大32ch)乗っているので、5個のMPPC箱をそのままつなげて、同時に処理できます。

5台のMPPCで少しずつゲインが違っているようですね。Cosmo-Zではリアルタイムにこういうのが見えるので、ゲインのずれが一瞬でわかるので便利です。

上のスペクトルを見ると、横軸0～50くらいまでのところは急に減衰して、50以上では閑散としているのがわかります。

試しにシンチレータを取り外してMPPCだけで測ってみると、

シンチレータを外したら大きいパルスが全くなくなりました。、高さ50くらいまでの信号はダークカウント（偽のイベント）だったようです。50以上のものはMPPCの発光（つまりミューオンとかβ線とかγ線とか）のようです。

スペクトルを長時間溜めていくと、こうなります。

左の方(ダークカウントの1p.e.に相当)では、10^9を超えるカウント数が記録されています。毎秒10^6回くらいのイベントが発生しているわけなのですが、

FPGAのハードウェアで処理しているので取りこぼすことはありません。

まぁ、本当はMPPCでスペクトラムがみたいわけではなく、イベントが発生した時刻とチャネル番号の情報を集めたいので、これからがFPGAの本領の発揮となります。

そもそも、なんで5chかというと、シンチレータがたくさんあれば宇宙線の飛来した方向がわかるからです。本当は16chで作りたかったのですが、うまくいかないリスクも考えてMPPCを5個しか買っていなかったためです。残りの11個は近々追加購入することになるでしょう。

持ち運び可能な宇宙線検出器ができました。とりわけミューオンを対象にしています。今のところ消費電力はトータル15Wくらいですから、モバイルバッテリでも動かせないことはありません。

いやー、ZYNQって本当にすばらしい。

おれデバ 第3話がついに完結しました

回路マンガ「おれデバ」　第3話がようやく完結しました。

第3話はアナログ回路設計の話で、どうやってノイズや歪を減らすかというお話です。

この回路対決の行方は如何に！？

↓のURLから無料で読めます。

http://www.tokudenkairo.co.jp/manga/

どうぞお楽しみください。

VivadoとArtix-7でハマったバグ!?仕様!?

今ごろからVivadoの勉強をしている私ですが、Artix-7でハマったこと３つ挙げます。

使っているボードは「特電Artix-7ボード」。小さなサイズにUSB3.0とDDR3メモリが乗っているので便利です。

① DDR3メモリコントローラを作ろうとするとクラッシュする

MIGを使ってArtix-7用のDDR3メモリコントローラを作ろうとしたとき、既存のXDCファイルを読み込んでピン配置をインポートしようとすると、クラッシュしてしまいます。

ここでRead XDC/UCFを押すと、

Failed to generate IP 'main_mig_7series_0_0'. Failed to generate 'Custom UI' outputs:

フォーラム等を見ると同じ悩みの人がいるみたいで、

https://forums.xilinx.com/t5/Installation-and-Licensing/2014-1-windows-8-1-MIG-IP-generator-fails-to-run/td-p/450554/page/2

-m32オプションを付けると良いとかいろいろ書かれていますが、どれも駄目。

どうやら、Windows8 64bit版 Vivadoを使うとだめみたいです。

結局、プロジェクトを作るたびに手作業でポチポチと入力することになります。

↓これを再度設定するべし！

② コンフィグオプションの件

BitStreamを作ると、デフォルトではSPI ROMから1bit×3MHzで読み出す設定になってしまいます。これだとXC7A100Tの読み出しに10秒近くかかるので、遅すぎます。

速くするにはコンフィグオプションでプロパティ

set_property BITSTREAM.CONFIG.CONFIGRATE 66 [current_design]

をセットすると良いと書かれているのですが、VivadoのTclコンソールでやってもうまくいかない。しかもISEのようにGUIで設定できない・・と悩んでいたのですが、解決策は簡単でした。

XDCファイルに書けばよいのです。

set_property CONFIG_VOLTAGE 1.8 [current_design]
set_property BITSTREAM.CONFIG.CONFIGRATE 66 [current_design]
set_property BITSTREAM.CONFIG.SPI_BUSWIDTH 2 [current_design]
set_property BITSTREAM.CONFIG.UNUSEDPIN PULLUP [current_design]
set_property CFGBVS GND [current_design]

これで、コンフィギュレーションが66MHzの2bitと高速になります。

ちなみに、GUIからやるには、Implementationが終わったらImplemented Designを押してインプリ済みのデザインをロードします。

そうすると、BitStream Settingsに「Configure additional bitstream settings.」が押せるようになるので、

ここを押せばBitStreamの設定をGUIからできるようになります。

これはなかなか見つけられなかった。(ﾟДﾟ)ﾉ

なお、CONFIG_VOLTAGEを1.8Vにしたら、CFGBVSはGNDと書かなければなりません。
CONFIG_VOLTAGEを3.3Vにしたら、CFGBVSはVCCOです。

③ XDCのピン定義は大文字小文字を区別する

いざ回路をインプリメントすると、CriticalWarningが山ほど出ました。

どうやらxdcのピン定義で出ているようなのですが、いろいろ実験していってわかりました。

このXDCでのピン定義は大文字小文字を区別している。

試しにDDR3_*という部分の1か所を小文字にしてみたら、そこでCriticalWarningが出てくれました。

結構律儀なやつですね。

まだ解決していない悩み

IPカタログの中にあるXILINX FIFOの中で

[Common 17-55] 'get_property' expects at least one object.

というCriticalWarningが出てしまいます。

XDCのこの部分

set wr_clock          [get_clocks -of_objects [get_ports wr_clk]]
set rd_clock          [get_clocks -of_objects [get_ports rd_clk]]
set_max_delay -from [get_cells inst_fifo_gen/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gcx.clkx/rd_pntr_gc_reg[*]] -to [get_cells inst_fifo_gen/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gcx.clkx/gsync_stage[*].wr_stg_inst/Q_reg_reg[*]] -datapath_only [get_property -min PERIOD $rd_clock]
set_max_delay -from [get_cells inst_fifo_gen/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gcx.clkx/wr_pntr_gc_reg[*]] -to [get_cells inst_fifo_gen/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gcx.clkx/gsync_stage[*].rd_stg_inst/Q_reg_reg[*]] -datapath_only [get_property -min PERIOD $wr_clock]

が原因のようなのですが、フォーラムとかアンサーとかを見ると、create_clockでクロックを作成するとよいということが書いてあるのですが、よくわからないですね。

VivadoのIPインテグレータでRTLソースをIP化せずに、モジュールとして追加する

RTLで書いたソースをIPインテグレータで使うため、IP化するのは面倒です。

そこで、RTLソースをIP化せずにさくっとモジュールとして使う方法を紹介します。

RTLモジュールの作り方

まず、Vivadoでプロジェクトを作り、ブロックデザインを新規作成します。（この時点では白紙です）

作ったブロックデザインの名前はmain.bdとしておきます。

Design Sourcesで右クリックし、Add Sourcesを行います。

あらかじめ用意しておいたRTLのソースを追加するか、VHDLやVerilogのファイルを新規作成します。

作ったソースはこんな感じ。

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_arith.ALL;
use IEEE.STD_LOGIC_unsigned.ALL;
  
entity ledchika is
	Generic (
		   period : integer := 10000000 
	);
    Port ( clk : in STD_LOGIC;
    		down : in STD_LOGIC;
           led_op : out STD_LOGIC_VECTOR (7 downto 0));
end ledchika;
  
architecture Behavioral of ledchika is
	signal timer : integer range 0 to 1000000000 := 0;
	signal led : std_logic_vector(7 downto 0);
begin
	process(clk) begin
		if(clk'event and clk='1') then
			if(timer = period) then
				timer <= 0;
				if(down = '1') then
					led <= led - 1;
				else
					led <= led + 1;
				end if;
			else
				timer <= timer + 1;
			end if;
		end if;
	end process;
	led_op <= led;
end Behavioral;

ここではledchika.vhdというファイルを追加しました。

main.bdの下にledchika.vhdが見えています。

ブロックデザインの白いところで、右クリックし、Add Moduleを行います。

先ほどのledchika.vhdをプロジェクトに追加したので、Add Moduleで追加する候補に出てきます。これを追加します。

IPコアであるかのように、ブロックデザインにモジュールが追加されました。

IPコアとの違いは、四角の中にRTLと書かれていることです。

適当に入出力ポートをつないで、回路図を完成させます。

Sourcesを見てみると、main.bdの下に直接RTLがつながるのではなく、間に１段、ラッパが被さっているのがわかります。このラッパはシステムが自動的に生成してくれていて、バージョン番号などが書かれています。（↑の図でいうledchika_v1_0など）

このラッパの中身は

--Copyright 1986-2016 Xilinx, Inc. All Rights Reserved.
----------------------------------------------------------------------------------
--Tool Version: Vivado v.2016.2 (win64) Build 1577090 Thu Jun  2 16:32:40 MDT 2016
--Date        : Sun Aug 14 13:48:44 2016
--Host        : nahitafu running 64-bit major release  (build 9200)
--Command     : generate_target main.bd
--Design      : main
--Purpose     : IP block netlist
----------------------------------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
library UNISIM;
use UNISIM.VCOMPONENTS.ALL;
entity main is
  port (
    led_op : out STD_LOGIC_VECTOR ( 7 downto 0 );
    pushsw_ip : in STD_LOGIC;
    xtalclk_ip : in STD_LOGIC
  );
  attribute CORE_GENERATION_INFO : string;
  attribute CORE_GENERATION_INFO of main : entity is "main,IP_Integrator,{x_ipVendor=xilinx.com,x_ipLibrary=BlockDiagram,x_ipName=main,x_ipVersion=1.00.a,x_ipLanguage=VHDL,numBlks=1,numReposBlks=1,numNonXlnxBlks=0,numHierBlks=0,maxHierDepth=0,numSysgenBlks=0,numHlsBlks=0,numHdlrefBlks=1,numPkgbdBlks=0,bdsource=USER,synth_mode=Global}";
  attribute HW_HANDOFF : string;
  attribute HW_HANDOFF of main : entity is "main.hwdef";
end main;
  
architecture STRUCTURE of main is
  component main_ledchika_0_0 is
  port (
    clk : in STD_LOGIC;
    down : in STD_LOGIC;
    led_op : out STD_LOGIC_VECTOR ( 7 downto 0 )
  );
  end component main_ledchika_0_0;
  signal ledchika_0_led_op : STD_LOGIC_VECTOR ( 7 downto 0 );
  signal pushsw_ip_1 : STD_LOGIC;
  signal xtalclk_ip_1 : STD_LOGIC;
begin
  led_op(7 downto 0) <= ledchika_0_led_op(7 downto 0);
  pushsw_ip_1 <= pushsw_ip;
  xtalclk_ip_1 <= xtalclk_ip;
ledchika_0: component main_ledchika_0_0
     port map (
      clk => xtalclk_ip_1,
      down => pushsw_ip_1,
      led_op(7 downto 0) => ledchika_0_led_op(7 downto 0)
    );
end STRUCTURE;

ですが、ユーザは編集できません。

あとは普段の手順どおりmain.bdで右クリックし、Create HDL Wrapperを行い、トップのbd用のラッパを作り、ビルドすれば完成です。

なお、ブロックデザイン上でRTLのアイコンをダブルクリックすると、IPのパラメータではなく、VHDLで書いたGenericのパラメータが編集できます。

IP化した場合との違い

RTLをIP化せずに直接モジュール化した場合との違いは、

• Reset Ourput Productsで中間ファイルが削除されることもない
• 画面上に「RTL」と表示される
• IP化の場合はソースを編集できないが、RTLモジュールならソースを編集できる
• ソースを編集すると、すぐに結果に反映される
• 面倒くさくない
• パラメータの伝搬とかが少し違うかも？
• バージョン番号の管理などがシステム任せになる

です。

特に大きなデメリットはないように思えるので、RTLで書いたソースはIP化するのではなく、RTLモジュールのまま使っていくのがいいのではないかと思います。

最初からIP化するのではなく、それは、プロジェクトが完成してからでいいのだと思います。

Vivadoで、RTLで書いた自作のIPを修正しても更新されない問題について（長文注意）

最近、ようやくVivadoを使い始めました。

私はFPGAの回路をVHDLで書くことが多いのですが、Vivadoのユーザガイドやチュートリアルを見ても、カスタムIPというのは主にXILINXの既存のFIFOやメモリをカスタマイズしたものを指す言葉であって、RTLで一から書くやり方はあまり書かれていないようです。

そこで、手近にあった特電Artix-7ボードを使って、IPインテグレータを使ってRTLのIPを作る方法を練習してみました。

VivadoでRTLのIPの作り方

まず、Vivadoでプロジェクトを作ったら、sources_1ディレクトリの下にnewというフォルダを作って、その下にIP化するフォルダ（ここではledchika）を作ります。その中にVHDLファイルを作ります。

そして、Tools→Create and Package IPを実行します。

Package a specified directoryを選びます。ディレクトリ単位でIP化されるので、AXIバスでも何でもない普通のIPコアの場合は、VHDLのソースディレクトリを分けておかなければなりません。

どのディレクトリをIP化するか聞かれるので、newの下にあるledchikaディレクトリを指定します。

IPを作るための「一時的なプロジェクト」を作るので、その名前を入れます。ここは、デフォルトのedit_ip_projectのままでよいようです。

子プロジェクトでledchika.vhdを編集します。

Package IPをクリックします。

自動的に一時プロジェクトが削除されて、元の親プロジェクトに戻ります。

そうしたらIPカタログの検索ボックスでled・・と打つと、さきほどのledchikaが出てきますので、これをBlockDesignに追加します。

これに適当な入出力ポートを付け回路を完成させます。プロジェクトのHierarchyのところで右クリックし、main.bdのところを右クリックして、Create HDL wrapperを行います。

こうすると、bdのラッパができるので、論理合成、インプリメント、BitStream生成を行います。

Bitファイルが出来上がるので、特電Artix-7ボードに書き込みます。

LEDがチカチカして一安心。

RTLのソースを更新するには

一度作ったIPのソースを変更するには、BlockDesignの上で右クリックし、Edit in IP Packagerを行います。

子プロジェクトが開くので、RTLソースを編集します。

「Package IP」のページを開き、Re-Package IPを押します。（２回目以降だとRe-Packageと出るのが芸が細かいと思います）

親プロジェクトに戻ると、一番上のところに黄色いバーが出て、Report IP Statusと書かれているので、これを押します。

すると、レポートのところにIP Statusというのが開くので、ScanしてUpdate Selectedを行います。つまり、この時点でVivadoはIPが更新されたことを認識しているようです。

Update Selectedを押すと、このようなダイアログが開きます。GlobalかOut of context per IPを選びます。

• Global・・・BD全体を１つのまとまりとして論理合成する。Synthのたびに全IPを再合成するので遅い。
• Out of context per IP・・・個々のIPごとにSynthを行ってデザイン・チェック・ポイントを作成する。こちらの方が論理合成時間が速い。
• Out of context per Block Design・・・サードパーティ製の論理合成ツールを使う場合に選択する？？※未確認

このオプションはどれを選んでも良いです。

すると、IP Statusのところに、現在のリビジョンと更新後のリビジョンが表示されます。

もう一度Rerunを押すと、黄色い状態が直り、IPが最新版に更新されたことがわかります。

しかし、この状態で論理合成してBitStreamを生成しても、IPは更新されないのです！！

ハマったー

その原因

今回作ったledchika.vhdというファイルは、Vivadoによって自動的にコピーがいくつか生成されます。書き換えたオリジナルが10:10という時間のものですが、コピーは9:55で最初にIPを生成した時間を指しています。困ったことに、論理合成にはこのコピーのほうが使われてしまうようです。

このコピーは、子プロジェクトで、Re-Packageをしても、親プロジェクトのIP StatusでUpdate Selectedをしても更新されません。そのため、IPのRTLソースを修正しても更新されないようなのです。

対策を考えてみた

①　main.bdでReset Output Productsを行う

これが一番、正当なやり方のようですね。これを行うと生成されたコピーも消え、更新されたRTLソースで動作するようになります。

②　VHDLのコピーを手動で削除する

この方法でもいけるようです。　

③　子プロジェクトでVersionを意図的に変える

新規のIPを作ったときにはVersion 1.0になっていますが、これを1.0.1とかに変えると、Vivadoは更新されたことを認識するようです。IP StatusのVersionで表示されている（Rev. ●）で、番号が自動でインクリメントしていくやつは更新とは認識されないようです。

逆に、以下の手段では更新したことを認識してくれません。

• 子プロジェクトでSynthやimplを実行する
• IP StatusのUpdate
• IP Chacheの有効無効を切り替える
• Refresh IP Catalogの実行
• Generate Output Productsの実行

いろいろなオプションを変えても、特に効果はないようです。

世界中の悩んでいる人たち

結果的にはReset Output Productsを実行すればよいのですが、世界中には同じようなことで悩んでいる人がいたようです。Reset Output Productsという答えを見つけたので、「"Reset Output Products" vivado」でgoogle検索するといろいろなフォーラムの議論が出てきます。

• VIvado 2014.1: How to update user custom IP from repository
• Vivado IP
• Vivado not synthesising changes to custom IP (self.FPGA)

結論

IPのRTLを修正したら、トップのBDで右クリックして、Reset Output Productsを行わなければならない。

※CoreGenやLogiCoreで作ったIPも全部生成し直しになるけど、仕方ない。

ZynqBerryの新バージョンを入荷しました

お待たせしました。

RaspberryPi形状のZynqボード、ZynqBerryを入荷しました。

今回のZynqBerryから、TE0726-03という新しいバージョンになっています。

TE0726-02とは基板が若干異なっています。トランジスタやコンデンサ等の小物部品の配置やシルクの違いはありますが、ユーザの機能に影響を与えるような大きな変化はないようです。

LEDの位置が変わったこと以外は大きな違いはないようです。

今回の入荷分は、すでに予約いただいていたお客様向けでほぼ出てしまうので、ごくわずかの数量しか余裕はありません。

リファレンスデザインも少しずつ進化していて、SDSoC対応のも出てきているようです。そこで、SDSoCのバウチャーも入荷しました。

ご注文はお早目に！

https://shop.tokudenkairo.co.jp/shopping/detail.php?shpdi=TRENZ0726

MPPCとプラスチックシンチレータで遊んでます(3)

先週までの実験で、シンチレータからの光を効率よくMPPCに導くために、アクリルでいろんな光ガイドを作ってみましたが、どれも駄目でした。

このとんがったところから向こうを見ても、シンチレータ全体が見えるわけではなく、向こうの景色が普通に見えるだけだったので、

光が屈折してガイドに入ってきているということはなかったのでしょう。そこで、光ガイドはあきらめて、直接、シンチレータにMPPCを貼り付けることにしました。

その結果が下の図です。

MPPCはダークカウントが多いので、ディスクリをかけて、ある程度高いパルスのものだけをカウントします。

様々な場所にMPPCを貼り付けて、5分間測ったときのパルスの数は下の図のとおりでした。

シンチレータの側面に付けたときのほうが、真ん中に付けるよりも多いようです。この結果解釈はいろいろできるのですが、とにかく、MPPCが見ているであろうシンチレータの体積はかなり小さいと予想されました。

そこで、MPPCの側面を白い紙やアルミホイルで覆って、端のほうで光ったものを反射や拡散させて、真ん中の穴で見えるようにしました。

5分測った結果、

アルミホイルで囲むと、大きなイベントが有意に増えます。

ROIをかけた範囲のパルスの数を数えてみたところ、こうなりました。

アルミホイルで包んだときが、一番、光量が稼げています。

反射させるのが良いようですね。

PCI-Xが使えるマシンにScientific Linux CERN 6のインストール

案件の都合上、PCI-Xが動くScientific Linux CERN 6のマシンが必要になりました。

PCI-Xというのは、一昔前のパソコンのインタフェースで、PCIより高速なパラレルバスの規格です。パラレルで133MHz 64bitという、今思えばシグナルインテグリティとかが極めて難しそうな規格です。

あの当時、あんな無茶な規格のバスがよく動いていたなあと。しみじみ。

PCI Expressが出てきたころから姿を消していったので、今どきPCI-Xのマシンなど、そうそう見当たりません。だいたい8年くらいの製品にあるかどうかという感じです。

SuperMicro社のX8SAXというものの中古のマザーボードを、「ぱそこん倶楽部」さん(http://www.pasocomclub.co.jp/htmls/1100000220428.html) で辛うじて見つけたので、早速注文しました。Core-i7の900シリーズが動作するようなので、CPUも一緒に注文しました。即日発送してくれたので、とても助かりました。

早速組み立てます。

Scientific Linuxというのは、Redhat Linux Enterpise版をベースにしたフェルミ国立加速器研究所によるディストリビューション。Scientific Linux 6 CERN(SLC6)というのはCERNによるものです。

インストールするには、下記のURLを訪れたら、

http://linux.web.cern.ch/linux/scientific6/

左にあるInstallationのところをクリックし、Scientific Linux CERN 6 (SLC 6) installation instructionsをクリックし、その後、Boot CD image(boot.iso)をダウンロードしてきます。

インストール時の画面が加速器とは・・イカしてますね。

Boot CD imageはブートするだけなので、Linuxの本体は別途メディアを用意しなければなりません。私はWebからダウンロードしてインストールする方法を選びました。

インストールには1時間くらいかかりますが、インストールが終わった後もyumが走って最新版をいろいろ取ってくるので、トータルで3～4時間くらいはかかっていたと思います。

今回、このマシンでは特電が作ったPCI Expressの試作ボードも動かすので、

Linux本体のインストールが終わったらコンソールを開いてlspciをやってみました。

ちゃんとVID=1bc8が出ていて、特電PCI Expressボードが認識されていたので一安心です。

VivadoHLSとCosmo-Zでリアルタイム信号処理

Cosmo-Zで計測したデータに、リアルタイムで信号処理を行う回路を設計しています。

もちろんVHDLで書けなくはないのですが、できれば今回の案件からはC言語で設計したいと思い、FPGAマガジンを読みながら頑張っています。
（実際に頑張っているのは私ではなく、インターンの学生さんだったりする）

その数値計算というのは、ある種のレーダー（軍事ではない）の信号処理回路で、浮動小数点や複素数がたくさん出てくる計算です。

VivadoHLSだと、確かに、複雑な計算回路が簡単に書けます。

しかも、何クロック目にどの部分の計算が行われて、

最終的に何クロックで計算ができるかの見積もりを示してくれるのがスゴイと思います。

Intervalは次のデータを受け入れるまでに必要なクロック数で、6クロック間隔を開けなければならないという意味ですが、このIntervalが必要になるのは浮動小数点数の積和が入っているためではないかと思います。

XILINXのFPGAでの浮動小数点計算は11クロック前後かかると思っていましたので。

クロック100MHzでInterval=6ということなので、およそ16MHzでやってくる信号をリアルタイムで処理できることになります。

DSPブロックやBRAMもほとんど使わず、C言語で書いた回路が本当にこの速さで動くならば有難いですね。

プラシンとMPPCの測定結果

プラシン＋MPPCの信号をCosmo-Zに入れて、MCAでスペクトラムを出してみました。

MPPCはダークカウントが多い（周波数に換算すると1MHzくらい）ので、大きさの小さなパルスはディスクリで落とします。↑のグラフの横軸500未満のところを拡大すると、

ダークカウントによるピークが6p.e.のところまでは見えています。

したがって、250くらいのところでディスクリをかければよいのですが、何も見えないと寂しいので150くらいのところでディスクリをかけておきます。

つまり、高さ150以上のパルスのみがカウントされるようにします。ただし、意味のある信号としてカウントする(ROI)のは250以上にしておきます。

下のスペクトラムは1分間の測定によるものです。

250以下の信号は、カリウムのありなしでほとんど差がないので、250以上の部分だけを見てみます。

1分しか測っていないので、ほとんどのチャネルでカウント数が0か1なので、あまりよくわからないですね。大きさ250以上のパルスはどちらも1分間で20発前後でした。カリウムありのほうが若干カウント数が多いのですが、誤差の範囲です。

プラスチックシンチレータとMPCCのテスト治具

プラスチックシンチレータに光ガイドを付け、MPCCで測るための治具をアルバイトさんが作ってくれました。

まず、60mm×60mm×10mmのプラスチックシンチレータの上に、四角錐型のアクリル製光ガイドを付け、その先にMPPCアンプ基板を乗せます。

光ガイドは様々な形状のものを試すので、高さは変えられるようにしています。

このアルミの箱を閉じて遮光します。コネクタ等から光が漏れてくるので気を付けます。

そして、箱全体をブラックシートで覆います。

そこに置いてある基板がCosmo-Zで、近くに置いてある試薬瓶は、塩化カリウムで、線源として使っています。

オシロで見た感じでは、光ガイドを付けたときも大きなパルスは観察されるけれども、劇的(例えば100p.e.とか1000p.e.とか)な改善はありませんでした。