なひたふJTAG日記

本郷へ移転すると決めたので、まず今入居しているビルのオーナーさんに退去の旨を伝えました。退去の通知をしてから3か月分は家賃が発生するので、何事も早めに動かねばなりません。

そうしたら、「会社大きくなったでしょ。このビルに入った人はみんな大きくなって出ていくんです。次もきっといいところが見つかりますよ」と言ってくれました。

こんな気持ちいい送り出し方をしてくれる大家さん、初めてです。このビルに入っていてよかったと心から思えました。

狙っている場所は、下記の地図のとおり。本郷三丁目か東大前の間のどこかです。

夕方、神田明神にお参りしてから向かおうとしたら、神田明神の前の道はこの本郷通りだったのですね。知りませんでした。神田明神の前の坂を上ってずっとずっと行くと、目的地に着きました。

まず自転車で銀杏臭い道をゆっくり走りながら東大前駅まで行きます。

東大前だと住所は向丘や西片になるようです。このあたりには、オフィス用のビルが全くありません。本郷通りの個人商店ばかりでオフィスビルはなく、大通りの１つ裏側には一軒家が立ち並ぶ広大な住宅街のようでした。

再び南下して戻ってくると、立派なビルが・・。本郷郵便局のようです。さらに南下して赤門を越えたあたりからオフィスビルが見つかります。

見ると不動産屋さんがあって、そのビルの８階（100㎡）が空いているとのこと。内見させてもらうと確かに広い。そして、景色もきれい。

賃料が予算オーバーなので即決はできませんでしたが、赤門の南には良い物件がいっぱいありそうだということがわかってきたので、これからはエリアを絞って探すことができそうです。

帰りに老舗のお菓子やさんで、お菓子を何個か買って帰りました。

ET2015に向けて、MITOUJTAG Onlineの開発を進めています

MITOUJTAG Onlineとは、Webブラウザの中で動くJTAGバウンダリスキャンツールです。

ブラウザでMITOUJTAG Onlineのメインページを開くと、サーバの中のMITOUJTAGサーバプロセスが起動し、WebSocket経由で通信が行って友達機能とか満載のSNSみたいになる予定です。

今日はツールバーを作りました。

「ケーブル」と書かれたボタンを押すと、ダイアログが出ます。

これはJavaScriptで作っているのですが、ダイアログとか出せるようになったのが精いっぱいで、慣れないデバッグはなかなか大変。

明日にはデバイスの追加ができるようにして、絵が出るようにしたい。

Kintex-7のXC7K160T FGG484は、GTXのBankが1個しかありません。

このGTX Bankには4つのGTXのチャネルが入っていますが、それぞれのチャネルを異なるプロトコルにできるでしょうか？

答えはYESです。

実際にどういうことかというと、例えば、Kintex-7にPCI Expressをインプリメントすると、CoreGenではGTXと内蔵EndPointを使うデザインが作られます。PCI Expressをx1にすればあと3個のGTXチャネルは自由に使えるはずです。

残った3個のGTXを使うにはどうしたらよいでしょうか。

やり方は簡単。まずはCoreGenでGTXのコアを作ります。

作ったコアをgtx_transceiverという名前にしておくと、ipcore/ディレクトリにgtx_transceiver.vhdとgtx_transceiver_gt.vhdというファイルが生成されます。

ここで、プロジェクトからCoreGenの.xcoを外します。

そして、gtx_transceiver.vhdとgtx_transceiver_gt.vhdを手動で追加します。

ポイントはCoreGenの.xcoを外して、.vhdを見つけてきて手動で追加する、ということです。

PCI Expressとオリジナルプロトコルを両方追加するとこんな感じになります。

CoreGenのプロジェクトではなく、ただのVHDファイルになっています。

基本的にはこれでよいのですが、PCI ExpressのGTXと、自分で作ったGTXの両方でGTXE2_COMMONというプリミティブを内部でインスタンシエートしているので、リソースが競合してしまい、インプリメントでエラーとなります。

したがって、PCI Expressか、自分プロトコルか、どちらかのGTXからGTXE2_COMMONを外さなければなりません。

当然、自分プロトコルの方から外します。CoreGenが作ったPCI Expressのコードはさわらぬ神にたたりなしというほど複雑なので、いじりたくありません。

素性のわかっているgtx_transceiver_GT.vhdを開きます。そして、GTXE2_COMMONをコメントアウトします。

--    gtxe2_common_0_i : GTXE2_COMMON
--    generic map
--    (
--            -- Simulation attributes
--            SIM_RESET_SPEEDUP    => WRAPPER_SIM_GTRESET_SPEEDUP,
--            SIM_QPLLREFCLK_SEL   => ("001"),
--            SIM_VERSION          => "4.0",
--
--
--       ------------------COMMON BLOCK Attributes---------------
--        BIAS_CFG                                =>     (x"0000040000001000"),
--        COMMON_CFG                              =>     (x"00000000"),
--        QPLL_CFG                                =>     (x"0680181"),
・・・中略・・・
--        BGPDB                           =>      tied_to_vcc_i,
--        BGRCALOVRD                      =>      "00000",
--        PMARSVD                         =>      "00000000",
--        RCALENB                         =>      tied_to_vcc_i
--
--    );

GTXE2_COMMONはデバイスに1個しかないから、これをコメントアウトしないとPCI Expressのものと競合してしまうのです。

そもそもCOMMONが何をしているかというと、QPLLとクロックのルーティングくらいのようです。

CPLLを使うようにしておけば、QPLLは使わないので、PCI Expressのほうのデザインにお任せしてしまってもいいわけなのです。

これで、PCI Expressと独自プロトコルのGTXが1つのGTX Bankに同居できました。

速度や形式の異なる2つ以上のプロトコルを同居させる際のご参考にしてください。

特殊電子回路は長年住み慣れた秋葉原を出て、本郷三丁目に引っ越すことにしました。

東京大学の隣です。

だいたいこのあたりで物件を探すことにします。来週から物件探しを始めます。

今の神田のあたりと比べて、同じ家賃で2倍くらいの広さになります。

人をいっぱい集めて、FPGAのこととか、粒子の検出のこととか、技術的・科学的な議論がしたいですね。

こんな会社ならアルバイトしてみたいよ、という学生さん、ぜひお越し下さい。

今作っているKintex-7のPCI Expressボードは、SFP+という10Gbpsの光モジュールが乗っています。

使ったのは、アバゴテクノロジーのAFBR-709SMZという光モジュールです。

SFPの使い方は、基本的にはXILINXのGTXのコネクタに直結するだけでよいです。SFPのTX+/TX-とRX+/RX-には0.1uFのコンデンサが入っているので、結合用のコンデンサは不要ですが、基板上にはGTXとSFP+の間に0.1uFのコンデンサか0Ω抵抗を入れておくと、トラブルシュートの際に役立ちます。

また、SFP+にはTXDIS、ABS、LOSという信号があります。これらはFPGAとSFPの間の低速信号で、通信を行うものではありません。

TXDISがHまたはオープンの時には光は出ません。光を出したくない時に使います。

ABSとLOSは、SFP→FPGAへ行く低速信号で、数キロΩでプルアップしておきます。ABSはモジュールが刺さっていないことを示す信号で、LOSは光を受信していないことを示す信号です。何らかの光を受けるとLOSがディアサートされます。これらの信号を使って、モジュールがささったことや、光を受けたことを検知するのに使います。

今回作るプロトコルは、CERNの中で使われる●●●●●(伏字)という超マイナーな規格なのですが、だいたいどんなプロトコルでも同じようなものでしょう。

SFP+を使う上で、GTXは以下のように設定しました。

第一の画面。クロックはQPLLでもCPLLでも構いません。とりあえず5Gbpsにしておきます。

次の画面。8b/10bエンコードにします。

第三の画面。カンマをK28.5にします。ここで、RXSLIDEは付けてはいけません。RXCOMMADETにはチェックを入れます。

また、Four Byte BoundariesにAlignmentさせます。（自分のロジックでやらずにGTXの機能に任せる）

受信イコライザはLPM-Autoにしておきます。DFEの方が高度なイコライザをしてくれるようなのですが、まぁ、よくわからないですね。

TerminationはSFPの場合は800mVにします。SFPはコンデンサでカップリングされているので受信のバイアスはFPGAで決まります。受信はコンデンサで切る、というのが高速シリアル通信の定石だと思います。

次の画面では特にやることはありませんが、RXVALIDは便利なので出しておきます。

また次の画面はクロック補正のシーケンスなどが書かれているものなのですが、特に現段階では触らないでおきます。

最後は確認画面。

5Gbpsにすると32bit幅で125MHzになるようです。

回路の設計で悩んだのは、まず、リセットの与え方。

	process (refclk125m) begin
		if(refclk125m'event and refclk125m = '1') then
			if(blogana_user(16) = '1') or (GT0_QPLLLOCK_OUT = '0') then
				gtx_state <= "000";
				GT0_GTRXRESET_IN <= '1';
				GT1_GTRXRESET_IN <= '1';
				GT0_RXUSERRDY_IN <= '0';
				GT1_RXUSERRDY_IN <= '0';
				rxresettimer <= (others => '0');
			else
				case gtx_state is
					when "000" =>
						GT0_GTRXRESET_IN <= '1';
						GT1_GTRXRESET_IN <= '1';
						GT0_RXUSERRDY_IN <= '0';
						GT1_RXUSERRDY_IN <= '0';
						rxresettimer <= (others => '0');
						gtx_state <= "001";
					when "001" =>
						GT0_GTRXRESET_IN <= '0';
						GT1_GTRXRESET_IN <= '0';
						rxresettimer <= rxresettimer + 1;
						if(rxresettimer(15) = '1') then
							gtx_state <= "010";
						end if;
					when "010" =>
						GT0_RXUSERRDY_IN <= '1';
						GT1_RXUSERRDY_IN <= '1';
						if(GT0_RXRESETDONE_OUT = '1') then
							gtx_state <= "011";
						end if;
					when others =>
				end case;
			end if;
		end if;
	end process;

つまり、GTRXRESETを'1'→'0'にしてから、一定時間待って、その後でRXUSERRDYを'1'にするようです。RXUSERRDYが0のままだと、RXRESETDONEは'1'になりません。

それからまた悩むのは、TXUSRCLKとRXUSRCLKですが、結局、

	INST_TXUSRCLK0 : BUFG port map
	(
		O   => GT0_TXOUTCLK_OUT_i,
		I   => GT0_TXOUTCLK_OUT
	);

	TXUSRCLK0 <= GT0_TXOUTCLK_OUT_i;

	INST_RXUSRCLK0 : BUFG port map
	(
		O   => GT0_RXOUTCLK_OUT_i,
		I   => GT0_RXOUTCLK_OUT
	);

	RXUSRCLK0 <= GT0_RXOUTCLK_OUT_i;

でいいようです。RXOUTCLKはRXUSERCLKに入れ、TXOUTCLKはTXUSERCLKに入れています。

それから、なぜか、SFP+とGTX間のRXNとRXPが逆になっているとリンクが不安定になります。対称的にできているから大丈夫だと思っていたのですが、そうでもないようです。

Kintex-7のPCI Expressがどうも安定しないので、悩んでいましたが、原因はREFCLKにあることがわかりました。

REFCLKは100MHzのクロックでマザーボードから送られてくるものなのですが、非常に繊細な信号です。

XCM-022は、メザニンコネクタ部分にもピンヘッダ部分にもGTXのクロックを通す端子がないので、ビニール電線で拡張基板とXCM-022の間をつないでいましたが、やはりマザーボードから来た繊細なクロックをビニール電線で送るというのがダメだったのでしょう。

でも、Pericom社のクロックドライバを入れたら、ビニール電線でクロックをつないでも安定して動くようになりました。

（写真は後日差し替え）

本当は、XCM-022も、ベースボードもMMCXの同軸コネクタがあるので、MMCXの同軸ケーブルを使ってクロックを送りたかったのですが、MMCXの同軸ケーブルなんて既製品が売っていないんですね。（イヤホンケーブルならあるけど・・）

そのため、ただのビニル電線でつないでいます。

で、FPGAの中にロジアナコアを入れて、見えた波形がこちら。

PCI Express EndPointに対してPIO Writeを発行したときの波形です。

XILINXのPCI Express EndPointは、TLPのデコードをしてくれているわけではなく、TLP層から上がってきたパケットを全部自分で解読しなければならないようです。

AXIのバスなのですが、AXI StreamでPCI Expressのパケットがそのまま出て来るようです。

結構先が思いやられます。

Kintex-7でPCI Expressが動きました。

作った基板はこんな感じです。ヒューマンデータ社のXCM022を乗せた拡張ボードのようになっています。左上にある同軸コネクタはLEMOというものです。

XCM-022に2本のラッピングワイヤが伸びていますが、これは、PCI Expressのカードエッジから来るクロック信号を与えています。PCI Expressを動かすにはマザーボードからくるクロック(100MHz)を与えなければなりませんが、XCM-022のメザニンコネクタにはGTXのクロックがないので、こうしてラッピングワイヤで飛ばすことにしました。

なお、オンボードの水晶(125MHz)では、どうもうまくいきませんでした。

PCI Expressのクロックはスペクトラム拡散が入っているためか、データの速度とクロックの速度が同じように変化していなければならないようです。ただ、PCI Expressにはシステムのクロックを使わない（つまり、リカバリクロックだけで動く）という深い部分のオプションもあるので、それを有効にすればオンボード水晶だけで動作させられるのかもしれません。

裏面はいたってシンプル。

ほとんど何もありません。

コンフィグROMにデータを書き込んで起動すると、おっ、

何か新しいデバイスが検出されました。

EXPARTAN-6TのデバイスドライバのINFファイルを書き換えて、VID=1bc8、DID=1080で登録すると、ちゃんとドライバもインストールできました。

ハードウェアIDを見ると、VID=1BC8、DID=1080でちゃんと認識されている。

クラスコードが05:80なので、ちょっと予想外。メモリコントローラとして認識されてしまいました。

ちゃんと設定したはず・・と思ったのですが、CoreGenのこの設定画面は、あくまでもAssistantであって、自分でこのコードを入れなければならないのですね・・

FPGAの内部の信号を見てみると、

pt_ltssm_state[5:0]が0x16（L0ステート）なので、リンクが確立された状態で安定している。user_lnk_upやpl_phy_lnk_upも'1'なので、リンクは上がっている。

このようにリンクアップまでうまくいきました。

一昨日のPCI Express基板がひとまず配線完了です。

私としては久しぶりの基板設計なので、えらく時間がかかってしまいました。

高速差動信号を受けるメザニンコネクタ(SIF40)を自分ではんだ付けできるよう、内側のピンはスルーホールにして、裏から半田ごてではんだ付けできるようにしました。

動くといいな。

今年の春ごろから、Kintex-7を使ってPCI Expressと、光ファイバ2本を使うという基板を設計していました。

Kintex-7と、PCI Express Gen2x4と、DDR3と、SFP+ 2個、SATA、万能基板用ピンヘッダ、USB3.0・・夢の基板だったのですが・・・

どうやら、この設計にはまだまだ時間がかかりそうでした。DDR3メモリのところとか、FPGAの裏とか、USB3.0のところとか、かなりの難易度が予想される。

全然基板を設計する時間も取れない・・

でも、納期は迫っている。

そこで、今回はヒューマンデータさんのXCM-022-160Tを使って、まずは要求されている機能であるPCI ExpressとSFPを2個という、動くものを急ぎで作ることにしました。

これなら、すぐに動きそうだ。

ただ、XCM-022はSIF40のメザニンコネクタから高速差動信号が出てきて、そのコネクタは基板の上側に付いています。当社製の拡張ボードに乗せて高速差動信号を使うには、XCM-022を裏向きに搭載する必要があります。

こんな感じになります。

基板をスタックするので2枚合わせて厚さは13mmくらいになりますが、そもそも光ファイバがあるので薄い基板じゃないし、いいかな。

あと、もう一つの問題は、XCM-022はXC7K160T-FGG484を使っているため、GTXのバンクが1しかないこと。PCI Expressと光ファイバ用の任意規格のMGTが同一バンクに同居できるかどうか、という問題についても検証していかなければならないことに気が付きました。

基板の出来上がりは、来週末。10月16日ごろ。超特急で作ります。

これが動いたら、自社製のKintex-7基板を設計はじめます。

「次世代イノベーション創出プロジェクト2020」という助成金に申し込みました。

http://sogyoshien.tokyo/

まだ申請が終わっていない方もいると思うので詳しいテーマはまだ言えませんが、

どういう助成金かというと、

• 東京都が定めたイノベーションマップというテーマに沿ったプロジェクトを支援
• 他の企業や大学、公的研究機関との連携が必要
• 最大8000万円　助成率 2/3まで

というものです。

8000万円もらえるのかすげー、と思うかもしれませんが、実はすごいリスクがあるのです。

助成率2/3というのがポイントで、もし、8000万円の助成金をもらいたいならば1億2000万円かかるプロジェクトを打ち立てて4000万円を自己負担しなければならないのです。その上消費税分は助成されないとか・・。

8000万円の助成金はプロジェクトが達成できたら支払われる、というものなので、助成金が下りるまでの間は金融機関に融資してもらなわなければなりません。

「助成金が下りたらお金を貸してください」という漠然とした融資の相談をすることになります。

そんで、万が一、目標が達成できなければゼロ。1億2000万円の負債を抱え誰も助けてくれないという、助成金なんだか罰ゲームなんだかわからないようなすごいプロジェクトです。

未踏ソフトとはだいぶん違いますね。未踏ソフトがぬるすぎるのかも。

そんな怖いプロジェクトに申し込んできました。

もちろん、もっと安い金額ですが。

金融機関にも融資の話をしてきました。助成金が通ればOKですよ、とのこと。

それから、連携とはいっても、すべては助成金の審査が通ってからの話なので、申請の前に話をするには「助成金が通ったら連携してほしい」という、未来の仮定形で話さなけばならないのがつらいですね。

申請書には目標という項目があって、「●●を達成する」という数値目標を書かなければなりません。この目標は数字で明確に書かなければならないのですが、後から変更はできません。

つまり、プロジェクトが始まる前に最終製品の数値目標を決めて、それを必ず達成しなければならない。で、達成できなければ助成金ゼロ。負債抱えてサヨナラ。目標の設定が甘いと突っ込まれる。

募集要項を見ると「申し込み時点でほぼ完成している研究はダメ」という規定があるので、確実にできるとわかっているものもダメなのです。だからといって、失敗してもダメ。

どうすればいいんだ。

今までに世の中にないような製品を開発するプロジェクトで、研究して、自分で決めた目標（変更不可）を達成して、必ず成功させなければならないという鬼のような助成金のようです。

お待たせしましたが。MITOUJTAGの更新パッチ2.90をリリースしました。

・MITOUJTAG BASIC用
https://www.tokudenkairo.co.jp/login2/getfile.php?target=MJBUpdate290

・MITOUJTAG Pro用
https://www.tokudenkairo.co.jp/login2/getfile.php?target=MJPUpdate290

今回の更新点は、

① ボタンが大きくなった

解像度の高いディスプレイでも操作しやすくなりました。

あまり使われない機能は、ツールボタンのプルダウンの中に隠したので、よく使う機能が迷いにくくなりました。

② ３D表示対応

新しく作られた「新規ウィンドウ」メニューの中から「3Dビューを開きます」を選ぶと、

基板上のFPGAのようすが、3D表示が行われるようになりました。

今までのMITOUJTAGの画面は、「これがBGAの端子で・・」と説明しなければ理解してもらえなかったのですが、3D表示なら説明しなくてもすぐにわかりますね。

ただ、この3D表示機能はまだまだ未完成なので、バグがたくさんあります。まともに使えるようになるには次の更新までお待ちください。

③ BUZZ機能

「その他のバウンダリスキャン」の中にある「EXTESTモード時に触った端子からトグル信号を出します」を選ぶと、

カーソルの形が代わり、触った端子からHLHLHL・・・といった信号が出力されるようになります。

FPGAからコネクタなどが正しくつながっているかどうかを調べるのに便利だと思います。

高速FFT回路をFPGAで作ろうとしています。

18bit 10Mワード/秒の速度で流れてくるADCのデータをつなぎ目無くFFTしたいのですが、どこまでいけるでしょう。

FFT回路の中央にあるのはバタフライ演算という回路ですが、1回のバタフライ演算を2クロックで計算するとして、200MHzで動かすとしたら・・

• 4096ポイントのFFTなら、毎秒4000回 → サンプリングクロック 16MHz迄
• 16384ポイントのFFTなら、毎秒870回 → サンプリングクロック 14MHz迄
• 65536ポイントのFFTなら、毎秒190回 → サンプリングクロック 12.5MHz迄
• 1048576ポイントのFFTなら、毎秒9.5回 → サンプリングクロック 9.9MHz迄

毎秒12～16Mでやってくるデータを「つなぎめなくFFT」できるわけです。

ちなみに、バタフライ演算というのは、

・A×W＋B
・A×W－B

を求める複素数の計算ですが、本当に2クロックでできるでしょうか。

東工大の2年生のアルバイト君にFPGAの回路を設計してもらいました。紙でおおまかな設計図とタイミングチャートを書いてVivadoに落とし込んでいました。

VivadoのRTLシミュレータ上ではちゃんと動いたようです。これから、C言語で同じものを作って様々なタイプの入力信号を入れて、HDLのシミュレーションと、パソコンで計算した結果とが一致するかといったテストを行う予定ですが、Vivado HLSでHDLとCを使いこなせるともう少し楽になるのかもしれません。

今のFPGAは乗算器＋加算器が掃いて捨てるほどある(600個とか)ので、ケチケチした最適化はしなくてもよさそうです。+1と-2した値の加減算のためにわざわざ別のDSPを使ったり、大富豪のようです。。

FFTを行う上でボトルネックになるのはDDR3メモリの読み書き速度でした。200MHzで18bitの信号を読み出してこようとすると、実部・虚部ともに18bitだから64bitのバス幅を使うことになります。

ZYNQのHPポートは250MHz 64bitが最高速度だから、バタフライ演算用データの読み出しと、バタフライ演算結果の書き込みで別のHPポートを使うことになります。

ZYNQの外部DDR3メモリは最高32bit 2GHzで動くとしたら、HPポート4個分の最高性能になります。実際はその半分くらいを見ておいて、2個のHPポートに全力で読み書きしたらいっぱいいっぱいです。

つまり、DSPブロックが余っているのでバタフライ演算自体はいくらでも速くできるけど、DDR3メモリの速度がボトルネックになるということになります。