O HAI THIS BLOG PURPZIEZ 2 B UZED AZ MAH PLESIOUS MEM. :)

2008/08/21

I CAN HAS VHDL? #2

VHDLについて、テキトーに書いてみるべす、第二回。

合成可能なVHDLモデルを設計するスタイルのうち、恐らく一番割合を占めているモノはdataflow的スタイルと呼ばれているモノである。つまり、所望の機能を実装する為に、膨大な数のsignalで繋がりを持った小さなprocessな文とconcurrentな文でコーディングするスタイル。

どんな言語でもウンコなコードを作ることが出来るけど、dataflow的スタイルで書かれた出来の悪いVHDLモデルは、読むことも中身を理解することもマジ苦痛れす。その苦痛の一端に加担しているのは、「processな文とconcurrentな文は書かれている順序では実行されず、特定の入力信号が変化した時にこれが実行される」と言う、trombikせんせーがPOEやErlangがやばいとか何故か今更騒いでいらっしゃる様な”いう゛ぇんとどりう゛ん”なkarmaをVHDL自身が持っているからとも言える。

dataflow的スタイルで書かれたコードが記述する機能を紐解くには、データの流れとして描かれたブロック、文と文との依存関係を見極める必要があるから、言っちゃなんだが、コイツぁあまり一般的なモノではない。で、「その可読性は?」と言えば、実際のところ、単なる回路図にも劣ると言う始末だったりする。どういう事なのかがあまり想像出来ないと思うけど、小分けにされたprocessな文やconcurrentな文が小さな機能を持ったブロックで、そのブロックの入出力がsignalの名前でラベルされていて、しかもそのブロック間の接続を知るには、signalの名前でsignalの接続先/接続元を探すしかないので、普通の回路図にならあるハズのwireが描かれていないと言うイメージ。

コードの書き方やそのデザインが何の目的で開発されたのかにも依るけど、dataflow的なスタイルで書くと1k越えのprocessな文を書くなんてのはザラにある訳で、コードを書いた本人以外が中身を理解することや”めんてなんす”的なことを考えると頭が痛くなることウケアイ。更には、コードを書いた本人に「このprocessな文が何を意図しているのか?」とか訊いても、「バカめ、覚えてねぇYO!!1」とか、いやマジで。

dataflow的スタイルでコーディングされると、抽象化レベルは当然低くなるし、ブロックに納められる機能は必要以上にシンプルになる傾向がある。dataflow的スタイルを貫くcoder自身が持つ、抽象化レベルの低いコードを書くっつう癖は、論理合成ツールの頭が良くなって行きつつある今においては、既に腐臭を放ち始めていると思ふ。マルチプレクサ、bitwise演算、条件代入文の様なprimitiveなモノが彼方此方に独立したprocessな文として散乱しているコードから、そのコード全体が意図するアルゴリズム的なモノ、例えば、「離散時間最適レギュレータとして構成されるブツの状態フィードバックゲインベクトルをセルフチューニングする為に離散時間リカッチ行列方程式を”りあるたいむ”で逐次計算するヒュアーの方法を実装したハードウェア行列演算回路」とか読み取るとかデバッグするとかは、そーとー難しいんじゃなかろうか。

そして、dataflow的スタイルのもう一つの注目すべき欠点は、シミュレーションが激しく遅い事だったりする。signalのassignmentはvariableのそれと比べて100倍くらい計算時間が必要だったりする。「そんなカバな?」と思うかもしれないが、signalには更新すべきattribute、つまり属性というモノが憑いているし、駆動イベントはイベントキューに突っ込まれる。結果、膨大なデルタ遅延がそのままシミュレーションに必要な時間を長ーくするのであーる。大量のconcurrentな文とprocessな文で構成されるdataflow的スタイルでコーディングされたブツはシミュレーションに要する時間の大部分をsignalの管理とprocessな文/concurrentな文の実行スケジューリングに費やしていたりする。回路規模、テストベンチの構成とスティミュラスの具合にもよるが、msオーダーのブツのシミュレーションにdayオーダーのシミュレーション時間が必要になる事だって珍しくなかったりする。

勿論、頭の良いシミュレータの最適化機能の一つとして、問題の無い範囲でsignalをvariableに変換してシミュレーションを高速化するなんてのも考えられるけれど、今のところ、頭の良いシミュレータは目玉が飛び出る位のお値段だったりする。一方で、FPGAベンダが自社デバイスの需要拡大を目的に、synthesize/translate/map/parまでやってくれる様なお得な論理合成ツールセットをほとんどタダの様な値段でバラ撒いているし、サポート無しならタダだったりするトコの方が多かったりする。そういうモノは、かなりbuggyなbin blobだったりすることもあるが、それはまた別問題。

で、二回に渡ってdataflow的スタイルを貶し続けてきた訳だが、「じゃあ、どうすりゃいいんよ?」と言う問題についてはちっとも案が提出されていないままなので、次回に続くのであったのであった。 :P
# 英語無しだと楽で良いなー。 :P

0 件のコメント: