2016.08.26

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

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

Axiic

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

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

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

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

Axiic2

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

sun

この1~2週間、相当ハマっていたことを以下に述べます。

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

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

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

Axiic3

sun

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

Axiic5

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

Axiic4

sun

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

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

Arboard

| | コメント (0)

2016.08.23

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

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

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

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

Am1008_okutsugaru_2

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

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

K40

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

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

Spec_all

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

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

Ganma

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

Muon

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

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

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

Total

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

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

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

| | コメント (0)

2016.08.22

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

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

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

Mppcshinkansen

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

sun

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

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

Danmen
(Wikipediaより)

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

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

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

Am1008_okutsugaru

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

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

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

Spec

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

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

Am0700pulse

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

| | コメント (0)

2016.08.18

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

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

Mppc5

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

Mppc_in_case

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

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

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

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

sun

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

Scope_10

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

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

Mppchist_2

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

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

Mppchist5ch

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

sun

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

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

Mppcboxspec

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

sun

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

Mppc6hour

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

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

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

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

sun

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

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

| | コメント (0)

2016.08.16

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

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

Manga

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

この回路対決の行方は如何に!?

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

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

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

| | コメント (0)

2016.08.15

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

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

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

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

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

Mig_error2

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

Mig_error1


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を使うとだめみたいです。

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

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

Mig_error3

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

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.」が押せるようになるので、

Bitstream1

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

Bitstream2

これはなかなか見つけられなかった。(゚Д゚)ノ

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

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

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

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

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

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

Vivado_xdc

結構律儀なやつですね。

まだ解決していない悩み

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

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

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

Criticalwaring

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でクロックを作成するとよいということが書いてあるのですが、よくわからないですね。

| | コメント (0)

2016.08.14

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

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

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

RTLモジュールの作り方

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

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

Addrtl_1

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

Addrtl_2

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

Addrtl_3

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

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が見えています。

Addrtl_4

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

Addrtl_5

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

Addrtl_6

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

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

Addrtl_7

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

Addrtl_8

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

Addrtl_9

このラッパの中身は

--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用のラッパを作り、ビルドすれば完成です。

Addrtl_10

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

Addrtl_11

IP化した場合との違い

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

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

です。

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

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

| | コメント (0)

2016.08.13

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

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

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

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

one VivadoでRTLのIPの作り方

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

Ipirtl_1

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

Ipirtl_2

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

Ipirtl_3

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

Ipirtl_4

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

Ipirtl_5

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

Ipirtl_6

Ipirtl_7

Package IPをクリックします。

Ipirtl_8

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

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

Ipirtl_9

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

Ipirtl_10

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

Ipirtl_11_3

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

Ipirtl_12

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

Ipirtl_25_2

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

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

Ipirtl_13

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

Ipirtl_14

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

Ipirtl_15

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

Ipirtl_16

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

Ipirtl_17

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

Ipirtl_18_2

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

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

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

Ipirtl_19

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

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

ハマったー

three その原因

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

Ipirtl_20

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

four 対策を考えてみた

① main.bdでReset Output Productsを行う

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

Ipirtl_21

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

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

Ipirtl_22

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

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

Ipirtl_23

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

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

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

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

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

six 結論

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

Ipirtl_24

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

| | コメント (0)

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