妄想族の憂鬱とHLSとOpenCL

妄想族という言葉は埼玉のFM放送局の番組が発祥のように思うが私もそれに当たるかも知れない。よく妄想をする。っていうか、昔々、3つ4つの毛色の違うモジュールの設計を同時に行っていたことがあり、その時は波形ツールを３つ4つ開いて同時というか時分割的にデバッグ・検証をするという滅茶苦茶なことをやっていた。それ以来のような気がしているが、一つの事に集中できなくなってしまい、何かをやっていても頭は別のことを考える癖がついてしまった。それが仕事でない場合は妄想的なものになったりする訳だ。その上、悪いことに私は考えていることが顔に出るようだ。これの何が問題かというと、例えば電車なんかにのっていてうっかり変な事を妄想しちゃったりすると、それが自分でも気づかない内に表情に現れてしまう。私の場合、妄想といっても大抵は下らないギャグとかだから、自分でも気づかない内に顔がニヤけていたりすることになり、周囲に怪訝な顔をされたりすることになる訳だ。そんなときに限って前方に若い女性とかいたりしたらもうバツが悪いことこの上ない。　お、お、オジサンは変態じゃねー！！　ワシゃノーマルじゃー!、、、と心の中でそっと呟いたりして。。。　あーん、普通のオジサンに戻りたーい。

それはさておき、

Electric Engineering Journal （旧 FPGA Journal）というサイトをたまに見るが、久しぶりにみたら 3/12日の記事に興味深いのがあった。

HLS versus OpenCL
Xilinx and Altera Square Off on the Future

http://www.eejournal.com/archives/articles/20130312-highlevel/

この記事によるとXilinxはHLS（高位合成）を推していて、ALTERAはOpenCLを推しているようだ。
へー、そうなのか。　記事では、抽象レベルというキーワードで回路図、そして言語記述（ゲートレベル、RTLレベル、Behaviorレベル、…）への変遷を説明してもいる（と読めた）。　うん、そう、抽象化なんだよね。　進化の方向としては、RTL記述からBehavior記述、そして機能記述へと向かうんだろうが、つまんねーだろうなー、そんな未来。　しかし、本当に高位合成とかCベース開発っていうのが主流になるのかね将来は。　記事に有るようにデータパスへの適用は可能かも知れないが、コントロールパス系は・・・。　結局はCがHDLの仲間入りしただけっていうことになったりして。

死んだ爺ちゃんが言ってた。
「いいか○坊、よーく考えるんじゃぞ。
　アヒルはな、喋らないんじゃ。　ふぉっ、ふぉっ、ふぉっ、ふぉっ、・・・」　って

よーく考えよー、アヒルは喋らないー、グァー！
ア＊%÷×＊＊＊・・・自主規制・・・

嘘です。すべて私の妄想です。
ハイ。 -_-);

fpga_story

F男：たしかに僕は回路情報がなければ只の石さ。
        でもね、それは君も同じだ。プログラムが無ければ只の石だ。
        ねっ！、ぼくたちうまくいくって！！

～ 手を取り互いに見つめ合うF男とA子であった。～

M子：F男さんったら。大丈夫よN子、私たちには分身の術があるわ。
         リソースさえあれば10個でも20個でも何個でも分身できるのよ。
         それにN子にはCustom Instructionだってあるじゃない。
         あんな融通の聞かないA子なんかに負けやしないわ。

A子：はんっ！、このソフトマクロ風情が！！
        貴方達に800MHzで動作することができるのかしら？

D  : 要は適材適所なんじゃね？

M,N子：あなたはDS...P子先輩！

A子：はんっ！、アンタなんか只の乗算器と加算器の集合体じゃないのよ！
         DSPなんて名乗ってるけど、コードフェッチとか出来るのかしら？
         この、名前倒れがっ！！
         おーほっほっほっほ・・・

～ 勝ち誇ったように高笑いをするA子であった。～

つづく。たららてぃららららん…（渡鬼のテーマ）

そんな妄想をする春の夜であった。

な～んてな。

はぁ～～、だりぃ orz

3Dレンダリングパイプライン 3

以前はこのブログを検索エンジンで検索出来る設定にしていたのだが、2ヶ月位前に検索できない設定に変更した。そうしたのにはとくに理由はないが、別にアフィリエイトで稼ぎたいわけでもないのでこのブログの存在を知ってる人だけみればいいかな見たいな感じだ。
設定変更したら毎日のページビューの数も見事に減少した。まぁ、もともと多くなかったが。
本当はページビューは殆ど０になるかとも思っていたのだが、数人（数件？）が参照しているようだ。
固定客がついたか？

さて、レンダリングパイプラインIPの作成に挑戦しようとしていたが、以下の理由により一旦中止することにした。

・  昨年の年末から年明けにかけてDFT IPの作成を行っていたが、頑張りすぎたせいかburnout気味で、中々レンダリングパイプラインIPに集中できなくなってしまった。（歳はとりたくないもんじゃ）
　ジオメトリエンジンの方は、やることは行列演算で、基本的にはメモリ上にあるモデルの頂点リストを読込み、変換行列を掛け算すればいいんだと思う。変換行列の値はグローバル座標に配置するモデル毎に異なるので、頂点リストの上位にコマンドリストのようなものがあり、（それをメモリ上に配置し、）そこに変換行列の値と頂点リストのアドレス、長さの情報を書く。それを専用のDMACで処理するというイメージになると思う。　ここまでは、難易度としてもそれほど高くなく、動作的にもレイテンシーは一定のものが作れそうな気がする。　が、難しいのはその後のレンダリングパイプラインだ。レンダリングパイプラインではジオメトリパイプラインで算出した頂点座標で構成される平面（群）に対してテクスチャを貼ったり、色を塗ったりしなければならない。その際には光源とオブジェクトの光の反射率などから明るさも計算しなければならないし、ピクセルの補間演算も必要になるだろう。最終的に描画する対象（VRAM）の解像度が低い場合は、簡略化できるかも知れないがせっかくやるからにはdvi_encで出力できるXGA(1024x768)を対象にしたいが、そうすると恐らく１年位の時間をかけてじっくり取り組まなければ出来そうに無い気がする。趣味でやるというよりは業務としてやるべきレベルのような気がする。

・  とある事情で、知り合いのシステム開発をちょっと手伝う（というか相談にのるというか）ことになり、マイコンについて調査する必要がでてきた。仕様次第ではFPGAの方が良いという結論になる可能性もあるが、現状聞いている限りではマイコンでも実現可能だしその方がコストも断然安くすみそうだ。この件に関しては今後このブログに書くつもりはないが、３～４月はこれに注力することになりそうだ。

以上の理由で、レンダリングパイプラインIPは一旦中止させて頂く。
匿名の方には、「ダメ元で」とこたえたのであまり期待はしていないと思うが、以上の理由なのでご了承願いたい。

最近、このブログの更新も滞りがちだが、しばらくこの状態が続きそうだ。
気が向いたら下らない話とか書くかも知れないし、小規模なIPの作成に着手するかも知れない。

３月

うかうかしてたら３月になってしまった。　早いなー
前にも書いたが、よく、fpgaを検索ワードにしてそれに引っかかる Twitter の呟きを眺めている。2月は２名の新キャラクター登場といった感じだった。もしかすると以前からもfpga関連の呟きをされていたのかも知れないが私が気づいたのは2月からだ。お一人はアイコンがドランクドラゴンの塚地さん似の方で、もう一方はアイコンがアンガールズの山根さん似の方だ。Twitterでfpgaに関して呟く方のアイコンは何故か多くが少女趣味なアニメ風なのだが、その二方は写真を使われている。お二人とも、かなり聡明な方のようで、呟く文章から聡明さがひしひしと伝わってくる感じがする。で、その内の御一方の呟きが発端となりワサワサと呟きが広がる様を興味深く見ていた。また、色々と考えさせられたりもしたが、そんなこんなしていたら3月になってしまった。

さぁー、いい加減サボってないで私は私の課題に取り組むことにしよう。
人は人、自分は自分だ。

Zynq-7000ファミリ

昨日（2012/2/26）のマイナビニュースの記事によると、Zynq-7000ファミリのすべてのデバイスが量産に入ったんだそうな。　同記事によると、Zynq-7000ファミリは2011年12月の提供開始以降、2万個以上のデバイスと4000枚を越す開発ボードが出荷されているんだとか。。。でも、これって全世界での数量なんだよな？　それにしてはちょっと少ない印象を受けるが。。。　全デバイスが量産に入ったことで、これから価格も下がるんだろうか？　DigkeyでZynqのデバイスが購入できるようだが一番規模の小さいやつでも1万6千円以上もする。こういう所から1個単位で買う値段と、企業が量産のために仕入れる値段とは全然違うんだろうとは思うが、幾らくらいになるんだろう？
今はDual Core ARM Corte-A9 1.6GHzを積んだタブレットが１万円以下で購入できてしまう。
Zynqのターゲットとしている市場は、車載、産業向け、通信、データセンター、防衛などの市場のようだが、価格次第ではメーカーはタブレット用SOC+安価なFPGAでシステムを構築するようにならないだろうか？  （まぁ、さすがに防衛向けでそれはないと思うが。）  PCIEとかRapidIOみたいな高速シリアルI/Fを持ったSOCがあればそのI/FでFPGAと繋げば広いバンド幅も確保できそうな気がするし、うーん、どうなんでしょう??

ブログを書いている理由

このブログをやっているのは一言では語れないくらい様々な理由があるが、その中の一つに文章力の向上というのがある。ボキャブラリが貧弱なせいか、自分の考えを言葉や文章で表すのが非常に下手で苦手で、いつももどかしい思いをしている。  ブログを書くことで少しでも文章力がつけばと考えた。　頭の中では具体的なイメージが描けているのだが、いざそれを言葉にしようとすると言葉が出てこない。むぐぐぅ、むぎぎぎっ、あ゛ー、このもどかしさを君と分かち合いたいみたいな感じでいつもモガいている。  VerilogやCよりも日本語が一番難しい。  いや、マジで。

3Dレンダリングパイプライン 2

ジオメトリ演算部で行う処理はアフィン変換という行列演算で以下のような演算式になる。
（注. 以降では、さも、知った風に書いているが、書籍等を学習して自分なり解釈したことを書いているのであって、間違っていたり、適当でなかったりする可能性があります。）


[x,y,z,1]^t が元の頂点座標、 [x',y',z',1]^t が変換後の頂点座標、左端の4x4の行列が変換行列である。　座標変換には、平行移動（モデルのグローバル座標への配置という表現の方が自分としてはしっくりくる。）や、スケーリングや回転等がある。

また、任意軸のまわりの回転は以下のようになる。

複数の変換を同時に行う場合は、各々の変換行列を掛け合わせて一つの行列にする。この時、変換順序に合わせて掛け算を行う必要がある。（例えば、平行移動してからの回転と、回転してからの平行移動は等価では無い）　ただし、これは変換行列の値を決定するための処理であって、座標変換演算、つまり、ジオメトリパイプラインで行う演算は冒頭の演算で良い筈だ。
しかしながら、この変換行列の値決定のための乗算をソフトウェアで行うと時間が掛かる可能性もあるので、ハードウェアによる外積演算機能も実装したほうがいいかも知れない。

FPGAはハードかソフトか

FPGA（の開発）はハードかソフトかっていう議論をたまに見聞きする。
私がこれまで接してきた人々にしても、年配の技術者（特にアナログ系）にはソフトウェア開発と写るようだし、ソフトウェア技術者には自分たちの分野とは違うと写るようだ。ソフトのようでソフトでなく、ハードのようでハードではなく、その中間的なものだから言ってみればニューハーフみたいなもんか。　いやんっ！ ってな感じだな。  な～んて言うのは勿論冗談だ。　ハードかソフトかなんてどうでもいいよね、そんな議論。　技術をソフトだ、ハードだと区別する事自体間違っていると思う。

開発環境等

今週はジオメトリ演算関係を書籍やインターネットから入手した資料から勉強しながら、PC環境の整備や、Android OSのお勉強も始めようと思ってAndroid OSのビルドに挑戦したりを片手間でやったものだから、色々とハマってしまった。

・開発環境
私は自宅では専らLinux OS (現在は Linux Mint 64bit版）を使っている。当然、FPGAの開発環境やシミュレーション環境もLinux OS上だ。 FPGA開発ツールは、 一応、XilinxのISE（含むplanAhead, Vivado）、ALTERAのQuartus、LatticeのDiamondはインストールしてある。私はどちらかと言えばXilinxのFPGAの愛用派（といっても仕事ではFPGAは触っていないので、あくまで趣味上の話）だが、宗教みたいに特定メーカに拘るのはあまり意味がないと考えていて、ALTERAのデバイスもLatticeのデバイスも使いたいと考えている。それに、実際各社の開発ツールやデバイスを使ってみても、それほど大きな差異を感じた事はない、強いて例えればSpartan3とSpartan6程度の違いじゃないだろうか。もっとも、私の場合、ツールの機能として使用しているのは合成からビットストリーム生成までの必要最小限の機能だけなので、差異を感じにくいのかもしれない。  FPGA Editor等のバックエンド的なツールのお世話になることも滅多にないし（決して使えないわけではない。）、ChipscopeやSignalTap等に頼るようになったら負けだと思っている。。。（なんのこっちゃ）　必要最小限の合成制約とDefaultのツールオプションで最高性能を出せる回路記述を出きるようになることが自分自身のテーマだ。キリッ、（再び、なんのこっちゃ）　

ツール類は、/usr/local/edaというディレクトリ下に配置するようにしており、各ツールとも１～２世代前迄のバージョンは残すようにしている。

これらのツール全てを同時に使うことは無いので、環境変数やパスの設定も必要に応じてそれぞれのツール用に行うようにしている。　具体的には各ツール用の設定スクリプトをscriptディレクトリに配置しておいて、必要な時に必要なスクリプトをsourceするようにしている。


Xilinxの場合はインストールディレクトリ・ISE_DS下に標準のスクリプト settings[32|64].[sh|csh]があるが、以下のように若干の変更を加えて使用している。

具体的な変更点は、オリジナルのスクリプトはスクリプトがインストールディレクトリにあることが前提で作成されていて、XIL_SCRIPT_LOCの決定に面倒くさい処理をしているが、これをコメントアウトして、ベタ書きで値（/usr/local/eda/Xilinx/14.4/ISE_DS）を入れるようにしているのと、最下行にsetenv DISPLAY  :0を追加している点だ。 DISPLAY変数の設定はスタンドアローン環境でFPGA Editorを使用する場合に必要で、これを設定しておかないと起動してくれない。ネットワーク越しで使用する場合は逆に悪さする可能性もあるが、自分の環境ではそんな使い方はしないのでこのようにベタ書きしている。

Latticeの場合もインストールディレクトリ・diamond/x.y/bin/lin64/下に標準のスクリプト setupenvがあるが、これも以下のように若干の変更を加えて使用している。

具体的には、set bindir=`pwd`をコメントアウトして、ベタ書きでパス名を設定している。

ALTERA用のスクリプトは以下のようになっている。


Icarus verilog, gtkwave, gpl-cver用のスクリプトはそれぞれ以下のようになっている。

これらのツールには非常に愛着があり、ツールが公開され出した頃からだから、もう10年以上も使い続けている。  gtkwave等は出始めの頃はnull pointer参照に対するケアがされていなくて頻繁に落ちたりしていたのだが今では非常に安定している。開発は今でも継続しているようで最近バージョンが3.3.43に上がった。 圧縮形式の波形ダンプフォーマットであるFST形式をサポートしてくれているのも非常に有難い。 FST形式はIcarus verilogもサポートしているし、gpl-cverについてはPragmatic C社（現 Tachyon Design Automation社）は開発を終了してしまったが、gtkwaveの作者がFST対応させた版を公開している。
（http://gtkwave.sourceforge.net/gplcver-2.12a_fst.src.tar.gz）
modelsim等の商用シミュレータには独自の圧縮フォーマットがあり、FST形式には対応していないようだ。　gtkwaveのソースツリーを見るとFST dumperのvpiタスクのソースも含まれているのだが、まだ完成形ではないようだ。自分でも色々試行錯誤してコンパイルに成功して、modelsimに組み込んで見たのだが、まともに機能しなかった。（深追いはしていない。）
このvpiタスクが使えるようになると、私としては有難いので、完成版のリリースを楽しみにしている。

Icarus verilogには一つ残念なバグがある。それは、wireネットに対するforceが機能しないというバグだ。 Verilog-HDLにはforce文というのがあって、モジュールを統合した状態で特定のモジュール部のみを検証したい場合や、モジュール間の信号の状態を細かく振りたい場合などに便利な機能だ。例えで言うと、プリント基板に実装された部品の足を浮かせてそこに別の信号をジャンパーで接続する、見たいなことができる。Verilogの規約上はwireに対しても適用可能な筈なのだが、Icarus Verilogはreg属性の信号にしか適用されないようだ。

例えば、上記のコードをmodelsimやgpl-cverでシミュレーションすると以下のような結果になる。

w1をzにforceし、これがw2にまで伝搬しており期待通りの動作だ。
ところが、Icarus verilogの場合は以下のような結果になる。

この問題について、バグレポートを出したところ、暫くして対策版のverilog-20120501が公開されたのだが、その後の公式リリース版であるverilog-0.9.6版では元に戻ってしまった。故に、私は今だに20120501版を使い続けている。バグレポートの提出が最近なのは、それまでforce文は使わないようにしていたのだが最近横着を覚えてしまって、テストベンチのタスク等でforce文を使うようになってしまったからだ。（本業ではFPGAの開発もHDL記述も行っていないのであくまでも趣味上の話だ。）　gpl-cverにはそのようなバグは無く、インタプリタなので手軽にシミュレーションできる点が良いのだが、プログラム自体が古く、verilog-2001等の最近（・・・でもないが）の言語規約への対応が不完全だ。　generate文等に対応していないが、これを使わなくても回路記述はできるので、私はHDLを記述する時はなるべくこれらの構文は使わず、どのシミュレータでもシミュレーション出来るようなレベルで記述するように心がけている。

で、環境整備の何にハマったかと言うと、ALTERAのjtagdをudevを使った自動起動に変えようとしてハマってしまった。これまでは、root権限でjtagdを起動してからユーザ権限に戻り、quartus IIやプログラマを起動していた。  udevによる方法はALTERAのドキュメントにも記載されている方法なのだが、何故か私のPC環境では上手く行かず、OSを起動するとUSBキーボードやマウスが使えなくなってしまう。結局、このサイト（https://help.ubuntu.com/community/QuartusII）を参考にして、OS起動時にjtagdを起動して常駐させておくようにした。

・Android
Androidのビルドでもハマった。 最近AvnetのZynq搭載ボード（ZedBoard)に関心が芽生え始めている。このボードでAndroidを動かして見ようかしら、それが可能ならボードを購入しようかどうしようかと思案している。その前にAndroidのビルドがどんなものか体験しようと思って、Linux上でのビルドに挑戦してみたのだがなかなか成功しない。私はシェルはtcshを使っているのだが、Androidをビルドする場合はbashにする必要がある。が、それだけでは不十分で、環境変数であるSHELLにもbashのパスを設定しておく必要があった。私の場合は、この変数がtcshのままになっていたために、ビルドの途中で32bit版コンパイラでコンパイルしたオブジェクトを64bit版アーカイバ(ar）でアーカイブしようとして失敗するという訳の判らない状態になってしまっていた。　SHELLの設定を修正したら無事ビルドできるようになった。で、Zynqボードだが、高いんだよねー。４万円強だもんなー。どこかがもっと安い奴を出してくれないかな。

だらだらと書いてきたら長くなってしまった。ジオメトリ演算関係は別記事に書くことにしよう。

3Dレンダリングパイプライン

ということで、次は3Dレンダリングパイプライン（3Dレンダラー）の作成に挑戦してみることになった。　匿名の方から3Dレンダリングパイプラインをやったらというコメントを頂いた。　3Dグラフィック関係は本を読んだり、OpenGLで少し遊んだ程度の知識しか無いが、面白そうだし、いつかやってみたいと思っていた。また、数値演算回路ももっと経験したいので、次のテーマとして選んだ。

上に書いたとおり3Dグラフィクスの描画回路というのは経験ないのだが、2Dの超簡単なものなら経験している。dvi_encにはデモ機能として以下のようなスプライトが組み込まれている。
これは、64x64ピクセルのTux(Linuxのマスコット)君の画像が回転しながら画面内を移動するというもので、VRAMやフレームバッファを使わずに動的に座標計算しながら表示している。


以下がその部分のRTLだ。


原点に対する座標(x,y)の回転は、回転後の座標をx', y' とすると、

   x' = x cosΘ - y sinΘ
   y' = x sinΘ + y cosΘ

で求まる。上記RTLでは基本的にこの計算を行っている訳だが、同期信号生成部からは入力として回転後の座標が入ってくるので、イメージ的に逆方向の演算を行っている。つまり、入力された座標値（x', y')からx, yを求め、これがTux画像の範囲に入っているか否かを判定し入っている場合は対応するピクセル値を出力している。

さて、3次元グラフィクスだが、Wikipediaの「グラフィクスパイプライン」やその他サイト等の情報から、3次元グラフィクス描画処理はジオメトリ演算とピクセル演算に大別されるようだ。モデル（描画する物）は個々に幾何的情報（寸法等）と色、質感（光の反射率等）の情報を持つ。これらのモデルを共通の3次元空間（ワールド座標系）に配置し、それらが視線方向に直角な平面（スクリーン座標系）に投影されることで立体的な画像になる。ジオメトリ演算はこれらの座標の演算処理で、モデリング変換（ローカル座標系からワールド座標系への変換→物体をワールド座標に配置）、陰影づけ、視点変換（視点座標系への変換）、投影変換（クリッピング処理）、ビューポート変換等を行うようである。その後のラスタライゼーション処理でピクセル演算処理が行われるらしい。

まずはジオメトリ演算系の検討から始めようと思う。

DFT IPの作成 21

あっ! ....................................................................................................... っと言う間にもう2月だ。


DFT IPの作成を開始したのが昨年の10月27日だからもう４ヵ月近くやってるのか。
前回、固定小数版は32bit版でまっいっか！ということにしたので、後回しにしていたメモリへの書き込み機能をやろうかと考えた。DFTの結果をメモリに書き出してどうしたいかというと、最終的に以下のような3D表示をなるべくリアルタイムに近い速度でやって見たかったからだ。


このDFT IPはサンプリング周期毎に1024@CH分のスペクトル値が算出されるので、これをメモリに書出しておいて、CPUで上記のような3Dグラフに変換して描画できれば面白いかなと考えたのだが、よくよく考えると、Atlysボードのメモリ容量が全然足りない。   Atlysボードには128MByteのDDR2 SDRAMが搭載されている。　スペクトルデータは32bit floatで複素数形式なので、1024点で 4Byte x 2 x 1024 = 8KByteになり、サンプリングレートを最高の48KHzとした場合は秒当たり 8K x 48000 = 375MByteと、かる～く 128MByteを越えてしまう。。。間引くかサンプリングレートを下げるかしないととても無理だ。　また、間引いてメモリに書き込んだとして、今度はメモリのデータをPCにどう転送するかが問題になる。現状USB-Serialは1Mbps(100KByte/sec)弱しか出せていないので、帯域が全然たりない。。。

ということで、メモリ書き込み機能へのモチベーションが失せてしまった。

ここらでDFTネタは一区切りして、他のネタに移ろうかな？　それとも、DFT-IPのALTERA版（DE0への実装）をやってみようか？。。。