高位合成、最近の流行りですね。
ただ、今の高位合成は単にハードウェア屋さんが高級言語を使ってFPGAやASICの論理を作れるようになっただけに過ぎないと思う。
ハードウェアを意識してソフトウェアを書かなければいけない部分も多々あり、今の高位合成はソフトウェア屋さんがFPGAやASICを作れるようになったわけではない。
これってあまり嬉しくない。
本当に高位合成のメリットが出てくるのはソフトウェア屋が使えるようになったと言われた時だと思う。
複雑なソースコードを別にターゲットがFPGAやASCI、CPUで動作させるものというのは意識しないで作れるようになった時なんだと思う。
その時、初めて高位合成が使えるようになったと言えるんだろう。
たぶん、その時はもう、高位合成ってコンパイラの一部と化しているんだろうと思うけど・・・。
Verilog HDLやVHDLの敷居が高いというのを聞いたりすることがあるけど、言語なんてなんでも良いと思う。
最終的にハードウェアになれば、C/C++であったり、Javaであったり、rubyやpythonでもなんでも良いわけで。
Verilog HDLやVHDLで書いてる側とすれば、別にCやJavaに置き換えても単にそれで書くだけで何が変わるかって言われても何も変わらない。
「書いてるソースコードの行数が減って、工数減るよ」とか、メリットとして聞くことがあるがそういう観点だけで見てしまうと、高位合成ってあまりメリットになっていないような気がする。
実際のところ、ソースコード書いている書いている工数より、シミュレーションなどのデバッグ環境を構築したり、デバッグコードを書いている工数のほうが格段と大きい。
高位合成に適用するソースコード本体は微々たる範囲である。
デバッグコードに論理合成は使わないし、Verilog HDLやVHDLでなければいけないわけではないのでここに高位合成のメリットは出ない。
比較として、Cソースとアセンブラでソースを書く速さは違うでしょとかいう人もいるけど、そのレベルで見れば明らかにかけ離れた言語だから書く速さは違うでしょ。
でも、Verilog HDLとC言語、Javaってそんなにかけ離れた言語ではないと思う。
別にわざわざ高位合成に直さなくても・・・
なんて、思うこともしばしば・・・
まぁ、万能な言語があればいいんだけど、そんなのあるわけないし・・・。
当分、Cソース⇒RTLトランスコードを手動でやってんだろうなぁ。
とかいいつつ・・・
