なひたふJTAG日記

3年前、本郷のオフィスに引っ越したのは優秀な学生アルバイトを採用してCosmo-Zを開発を手伝ってもらおうと思っていたからなのですが、そのアイデアは失敗でした。

東大の学生さんは忙しいので、本当に週2、4時間ぴったりしか来ません。FPGAの開発というのは良くも悪くも成果がでるまで徹夜してでもやらなければならないもので、時間で切れる仕事ではありません。

週2・4時間とぴったり決めてしまうと、効率が悪いのです。

また、自分はCosmo-Zを一から作ってきたので気が付かなかったのですが、Cosmo-Zはすでに複雑になりすぎていて、「FPGAの勉強がしたい」という学生さんが「勉強できるバイト」として扱えるレベルをはるかに超えたものになっていたのです。

きつい思いをさせていたかもしれません。

ただ、Cosmo-Zを完全に理解した学生さんもいたことは事実です。

それなら、Cosmo-Zの開発ができるスキルを持った正社員を雇えばよいと考える人がいるかもしれませんが、それも不可能です。

Cosmo-Zの開発に必要なスキルは

• 計測器が作れる程度のFPGAスキル
• 高速アナログ・ディジタル回路に対する知識
• Vivadoに対する理解
• ZYNQに対する理解
• ZYNQ Linuxに対する理解
• Javascript、WebAPI、jQuery、CGI、HTML5、CSS3に対する理解
• 放射線、素粒子など物理学の知識

が必要であるからです。

こういう人材の年収は1000万円は超えるし、一人だけ採用してもすぐにやめてしまうので、同レベルの人を3人くらい雇って競わせたり協力させたりしなければいけません。普通の転職市場で人を探すとなると、周辺のサポートする人(330万円)も含めて6人くらいセットで雇わないといけない事案なのです。年間4000万円の余剰利益があって、はじめてCosmo-Zの開発を安定して回していけます。

そもそも、いくらお金を積んだとしても一般の求人ではFPGA＋放射線という人材は集まらないでしょう。

本当にそれでCosmo-Zが年間1000台とか1万台とか売れるとしたら、このモデルでも回っていくのでしょうが、回り始めるまでに投資するお金が多くなりすぎてリスクが大きいのです。

まとめると、もはやCosmo-Zは複雑になりすぎていて、学生アルバイトはもちろん正社員であっても、普通の求人で集めた人で開発するのは不可能ということです。

しばらくは私一人で開発をするしかありませんが、それだと遅すぎます。

今考えているのは、Cosmo-Zをオープンソースにして、物理学の研究者でFPGAが使える世界中の人に協力してもらうことです。

突然ですが、今月（今週？）で特電の本郷オフィスでの業務を閉じることにいたしました。

家賃が高いとかいろいろ理由はあるのですが、広がりすぎた業務を整理して本当に必要な業務に注力したいというのが理由です。

FPGAが好きで起業して14年やってきましたが、最近は如何に売るかということばかり考えていた気がします。

本来のFPGAの楽しさを感じる開発ができずに、広告や間接業務にばかり時間を取られてしまうようになっている自分に気が付きました。

特電のスタッフのほとんどは学生のアルバイトさんで、来年3月に卒業して就職する人が多かったので、タイミング的には幸いだったかもしれません。社会人のデザイナーさんもいますが、次が見つかるまでサポートしたいと思います。

なお、特電の移転先は決まっていません。

復活の時期も未定です。それまで荷物はどこかの安い倉庫にしまっておきます。

一度、従業員ゼロのミニマムな会社に戻して、どこかのコワーキングスペースを借りて、これまでご購入いただいたお客様へのサポートと、面白みのある受託開発案件に注力したいと思います。その中でFPGAやJTAGの楽しさを再発見していきたいと思います。

そして、いままでに特電のスタッフさんが作ってくれた技術や製品のタネを育てながら、半年か１年くらい充電期間を取りたいと思います。

FPGAやJTAG製品の販売は、在庫がある分については発送します。

Cosmo-ZやCosmo-Z Mini、Cosmo-K、HyperFADCについては、今までよりは納期が多少かかるようになるかもしれませんが、受注生産で製造していきたいと思います。

在庫が尽きた後はどうするかは未定ですが、FPGA基板の製造を丸ごとアウトソーシングできる実装会社さんを探すとか、出荷業務をアウトソーシングできる商社さんを探すとかして、できるだけ滞りなく出荷できるようしていきたいと思います。製造や出荷のやり方についても、もっと手がかからない抜本的な改善方法を考えるいい機会ではないかと思っています。

お客様、スタッフの皆様、応援してくれた皆様、ありがとうございました。

繰り返しになりますが、サポート業務や製品の販売は続けていきますのでご安心ください。

SDSoCでAXI Streamからバッファに入れる回路が動きました。

どのような回路かというと、基本はコレです。

void pf_read_stream(unsigned long *rbuf) {}
void pf_write_stream(unsigned long *wbuf) {}

int s2mm_data_copy(unsigned long *fifo, unsigned long buf[BUF_SIZE])
{
#pragma HLS interface axis port=fifo
    do  {
    } while ((*fifo & 30) == 0);

    for(int i=0; i<BUF_SIZE; i++) {
#pragma HLS pipeline
        unsigned long tmp = *fifo;
        buf[i] = tmp;
     }
     return 0;
}

void s2mm_data_copy_wrapper(unsigned long *buf) {
    unsigned long rbuf0[1];
    pf_read_stream(rbuf0);
    s2mm_data_copy(rbuf0,buf);
}

SDSoCのチュートリアルでよく見るサンプルコードですが、バスの幅がunsigned longになっています。

このコードをmain.cppとは別のCPPファイルに保存しておき、Hファイルに

#pragma SDS data sys_port (fifo:axis_data_fifo_0_M_AXIS)
#pragma SDS data zero_copy(buf)
int s2mm_data_copy(unsigned long *fifo, unsigned long buf[BUF_SIZE]);
void s2mm_data_copy_wrapper(unsigned long *buf);

と書いておきます。main.cppと、ハードウェア関数が入るソースを分けておいたほうがいいでしょう。分けておくと、main.cppの中のコードを書き換えてからビルドをしても論理合成が走らないので早く出来上がります。

ハードウェア化するのはs2mm_data_copy関数であって、s2mm_data_copy_wrapperではありません。wrapperのほうが何をやっているのかいまだによくわかりませんが、ダミーの配列rbuf0[1]というのがハードウェアの配線に相当するようで、この記述を書くことによってAXI-4 Streamからハードウェア関数へつながります。

ポインタで指定された

また、#pragma SDS data sys_port の記述を使うことで、ハードウェアプラットフォームで定義されたAXI Streamのどこの部分に、この回路がつながるかを指定することができます。

本日、JTAGチャレンジ基板を使った初めてのセミナーを開催しました。

JTAGチャレンジ基板とは

わざと間違いを作りこんだFPGA基板。正常に動作せず、FPGAメーカー純正のツールでもデバッグできない。

この基板はそのままでは動作しませんが、MITOUJTAGというツールを使うと、FPGAが起動しない理由や、FPGA間の断線の発見などができるというものです。

アンケートを集計したところ、5人中3人の方が「とても満足」ごご記入くださいました。

お寄せいただいた感想やご意見はこのような感じでした。

• セミナーの内容とは別の不明点も教えてもらえて、勉強になった。
• 実際に不具合のある基板を実践的にチェック出来たことは良かったと思います。
• JTAGはメーカーの独自拡張が跋扈する深い魔窟というイメージでしたが、怖がらずに挑戦できる気がしてきました。
• Basic版でかなりの事ができることが分かった
• ALTERAのFPGAは使った事は無かったのですが興味のあるMAX10に触れられた事、SVFプレーヤーが何であるかも分かった

次回のセミナーは10月3日(水)に弊社会議室(東京都文京区本郷)にて行います。

ご興味のある方は、ぜひご参加ください。

ZYNQを搭載したRaspberry PiライクなFPGAボード「Zynqberry」で、SDSoCプラットフォームを作り、ニューラルネットワークの計算をハードウェアでアクセラレートするデザインを動かすことができました。

私もいよいよSDSoCデビューです。

使用したニューラルネットワークの構造と学習済みモデルは、オライリーのDeepLearning本のものを使用しています。したがって、隠れ層は2層で、ニューロンの数は50個と100個です。

MNISTの実行結果はというと、認識率が93%程度。これはオライリー本のコードをPythonで実行した場合と同じです。

動作速度は、ZYNQ上のARMで実行するのと比べて約2～3倍にアクセラレートできています。初めて書いたSDSoCのコードですが、まずまずでした。

作られたSDSoCの回路はこんな感じになりました。

multsumという関数をハードウェア化し、それを3回呼び出すようにしています。

#pragma SDS data zero_copy(input[0:row])
#pragma SDS data zero_copy(output[0:col])
#pragma SDS data zero_copy(w[0:row*col])
#pragma SDS data zero_copy(b[0:row])
#pragma SDS data access_pattern(input:SEQUENTIAL)
#pragma SDS data access_pattern(output:SEQUENTIAL)
#pragma SDS data access_pattern(w:SEQUENTIAL)
#pragma SDS data access_pattern(B:SEQUENTIAL)
void multsum(int *input,int *output, int *w, int *b, int row, int col)
{
	for(int i = 0; i < row; i++) {
    	int tmp = 0;
		for(int j=0;j < col;j++) {
#pragma HLS PIPELINE II=1
			tmp += input[j] * *w++;
		}
		tmp += b[i] * 256;
		output[i] = sigmoid(tmp / 65536.) * 256;
	}
}

void hw_predict(int *p, int *y1, int *y2, int *y3,
	int *w1_8b, int *b1_8b,
	int *w2_8b, int *b2_8b,
	int *w3_8b, int *b3_8b,
	int w1r, int w1c, int w2r, int w2c,	int w3r, int w3c) {
	multsum(p, y1    ,w1_8b, b1_8b, w1r, w1c);
	multsum(y1,y2    ,w2_8b, b2_8b, w2r, w2c);
	multsum(y2,y3    ,w3_8b, b3_8b, w3r, w3c);
}

ちょっとワーキング用の配列が多いのと、シグモイド関数を実行するときに浮動小数点になっているのが気になりますが、それでも何も考えずに書いて、動いてしまいました。

パフォーマンスを見てみると、毎回の積和計算が整数化して6クロックで行えているので、自分でHDL書けばもっと最適化できるのにな・・と思えます。

また、シグモイド関数の中身は1/(1+exp(-x))をdouble型でベタに実行していますが、実行時間はというと・・

100クロック以上使っています。

浮動小数点の除算や、exp、加算などを愚直に行っているようでした。これならソフト、というかNEONでやったほうが速いかもしれませんね。

でも、sigmoid関数の計算はニューロン1個に対して1回なので、それほどパフォーマンスに影響はしないのではないかと思われます。

リソース使用量は76%。ほとんどがシグモイド関数だと思われます。

結果はというと、

• オライリー本の第3章のMNIST認識多層パーセプトロンのプログラムをCで書き直してSDSoCに移植
• ZYNQのARMより2～3倍高速
• 何も考えなくても、浮動小数点のシグモイド関数ができてしまった！

私もついにSDSoCデビューできました。

こちらのスタータキットを使って試せるよう、デザインのアップロードを準備中です。

https://www.trenz.jp/product/TE0726-STARTER-KIT

お楽しみに