回路図は、必要か？
次のような質問をいただきました。
「 ところで，Verilogだけで設計すると，回路図のイメージはないのですが，それは設計者の頭の中の作業としてやるので，必要ないものなので
しょうか。
私は，昔，会社に勤めていた頃，回路図で設計して，Pt板を作っていました。それで，回路図はあった方が良いかと思っています。
しかし，一方で，複雑に配線が入り組んだ回路図を見るより，Verilogのソースを見た方が，慣れてくると，理解しやすくなるのかとも想像します。
回路を，イメージのパターンとして捉えるか，論理として捉えるかに関係しているように思います。 」
Verilog HDL-回路図との違い
筆者は、回路図との違いについては、大きく下の３つあると思います。昔の設計スタイルからの違いで説明します。
1. ベンダによらない回路記述
Verilog HDLでは、下のような書法が可能です。これらは、厳密な区別ではなく渾然とした記述も可能ですが、今日の設計現場では、3手続き構文によるRTL回路の記述が主体で,１は皆無と言ってよく、2については、合成結果の出力時位しか見る機会はないと思います。
昔は、半導体屋さんの回路ライブラリをを呼び出しながら、回路図を記述していました。回路図は、当然ながらそのベンダ固有のライブラリを呼び出すことになるので、他社で２ndソースを作ろうとしたときに、再設計しなければいけませんでした。その点、Verilog HDLでしたら、設計文書は、同じVerilog HDLソースで済むという利点があります。
＊:参考リンク 上の1-3は、設計規模の増大にともなう抽象レベルの変遷と捕らえることができます。
http://thinkit.co.jp/article/156/1
http://www.cadence.co.jp/bana/soc/01_sys.html
2.RTL合成による設計生産性の向上
昔の回路図を書くやり方では、ゲートレベルが主体で設計でした。このようなレベルの設計では、数千ゲート/月 位の設計生産性しかありませんでした。 のちにVerilog HDLのサブセット構文にたいしてRTL合成がサポートされるようになりました。これが、有名なデザインコンパイラで、革新的な設計標準スタイルとなりました。（余談ですが、ネーミングセンスの良さを感じますね。） これにより設計者は、数万-数十万ゲート/月 位に設計生産性が向上したと思います。（筆者の経験的・体感的な数字です。）アーキテクチャ設計、ブロック図や、状態遷移図といったRTLの前に行う上位段階の設計を行う必要性は、回路図設計時と同様に、なんら変わりません。しかしながら、このツールにより、設計者は、いちいち機械的な論理圧縮をしながらゲート回路を書く事から開放され、もっと人間的な（もっと設計的な）仕事に注力できるようになりました。
設計者は、RTLの肝である、クロックで状態が記憶される部分（レジスタ）と、組み合わせ回路だけを意識して設計すればよいことになりました。
参考リンク
http://www.picfun.com/vhdl32.html
このときから、RTLに回路に関しては、回路図を見ることは、無くなったように思います。RTL回路では、レジスタと組み合わせ回路のカスケードに過ぎません。設計者は、そのことだけを頭においておけばよいので、見る必要がなくなったということだと思います。逆に、合成した回路図を見てもゲートに分解された回路は、一見では、とても理解できない代物になるのが普通です。なので、設計者の設計意図と、実際の設計の一致確認は、RTLレベルではRTLシミュレーションで、合成後の一致確認は、ゲートシミュレーション(タイミングシミュレーション）で行います。
Verilog HDLが回路図と比して理解しやすいか？ということに関しては、書くレベルによるかと思います。当然ながら、ゲートレベルで書かれた回路図よりは、RTLで描かれたVerilog HDLの方が理解し易いと思いますが、同じゲートレベル同士の比較でしたら、回路図の方に分があると思います。
一般的には、設計文書とVerilog HDLは、同じにはならないと思います。他人の書いたVerilog HDLは、（他のプログラムミング言語よりもずっと）理解し難いものですし、ブロックダイアグラムの代わりにすらならないと思います。並列で動くために、本質的な難しさがあるのだと思います。
＜回路図をみるときは、どういうとき？＞
合成後、非同期や、タイミングクリティカルで、配線遅延が性能に影響する部分については、FPGA ツールの備わっているEditorや、RTL Viewerで確認することはありますが、それ以外は、あまりないと思います。
3. 回路の検証の記述-テストベンチとは？
もともと、Verilog HDLは、回路検証のためのモデル言語です。この言語が設計されたとき、おそらく論理合成の事は、考えられていません。設計した回路がきちんと動作するか、それを検証するための言語であり、上にも書いたように論理合成の登場は、その後になります。（RTL合成が可能なのは、Verilog HDLの一部の文法（サブセット）のみです。初めてハードを書く人は、合成不能の記述をしてしまうことが多いです。自分で発明しない事を心がけてください。合成可能な書法に則って書かなければなりません。 一方、合成対象にならない記述（テストベンチ側）は、Verilog HDLの文法を自由に駆使しても構いません。）
つまり、Verilog HDLという言語の当初の目的は、回路記述というよりも、回路検証にあります。 回路を記述するだけならば、慣れ親しんでいる使い慣れた回路図エディタを使った方が手間がかからないと思われる人は沢山いると思います。 しかしながら、問題は、回路が所望の通り動作するか検証するとなると、ハード化する部分としない部分がどうしても出てくることです。ハード化する部分は、回路図になりますが、ハード化しない部分は、どうやって書けばよいでしょうか？ ファイルで入出力のベクタを与えて、期待値と比較することが、回路図時代のやりかたでした。しかし、この方法では、実際のシステムのモデル化の自由度や柔軟性がありません。
ハード化する部分のインターフェースには、CPUだったら、DA/ADコンバータだったり、VCMだったり様々なデバイスがつながるはずです。それらを柔軟にモデル化できるのがVerilog HDLの特徴です。さらに、検証能力を向上させたのが、上位互換であるSystemVerilog です。 昔から回路を作ってきた人達は、常に検証を考えてきました。ですから、CやC++を使ってもよいのですが、できれば、同一言語で、回路記述と回路検証をワンセットで行いたい、というのが願望だったと思います。それがVerilog HDLによるテストベンチになります。
参考リンク
デジタル回路設計入門
デザインウェーブコンテスト2006上級問題を解く
http://japanese.sugawara-systems.com/opencores/AES/aes_by_sugawara-systems.pdf
http://japanese.sugawara-systems.com/opencores/sugawara-systems_fm_demodulator_for_web.pdf
http://japanese.sugawara-systems.com/opencores/Veritak_Team_DWM_CONTEST2006.pdf
＜モジュール単位のシミュレーションでビルドアップしていく＞
シミュレータは、遅いので、FPGAで合成して"論よりラン"の方がよい、という人もあるかもしれません。しかし、いきなり合成というのは、趣味は別にして、設計の現場では行われていないと思います。 確かに、規模に比例してシミュレータは、遅くなります。逆に言えば、規模が小さいうちは、HDLシミュレータは、ハードウェア並みに速いのです。状態数が少ないこの段階での十分な論理検証を行うことをお勧めします。ハードウェアの並列状態数は、接続するモジュール数に応じて指数関数的な状態数になります。FPGAの利点は、速いことですが、観測できるノードと、Historyのサイズは、自ずと限りがあります。FPGAでデバッグする場合には、原因箇所が予め特定できていないと難しいでしょう。設計は、トップダウン・ボトムアップの両方ありきだと思いますが、検証に関してはプログラミング言語での検証と同様にボトムアップが基本だと思います。部品が動かないで製品が動くことはありません。
＜検証とデバッグは違う＞
検証とは、見つかっていないバグがないことを保証する行為だと思います。勿論、天文学的状態数を全部検証することは不可能です。例えば、18x18ビットの乗算器のモジュールがあり、それが100個あるとしても天文学的な状態数になります。全検証は不可能なことが分かります。ですが、普通は、それらは、検証されたIPであり、その使い方のモードをユーザが指定する、みたいな形が殆どだと思います。一個のモジュールについてなら、全モードをチェックが可能でしょうし、検証するのにたいしたベンチはいらないでしょう。そういった地道な検証努力の積み重ねが、後々に効いてくるように思います。HDLシミュレータなら、全History、任意のノードが可観測で、規模が小さいうちなら十分に速いです。ですから、モジュール単位で、すばやく論理的な検証を行い、組みあがったところで、FPGAで、実働確認するというのがよいと思います。理想的には、FPGAは、組み上げ後の実機確認で済み、デバッグの必要のないことです。論理的な検証、仮想世界であるシミュレーションで済であるならば、残るは、ハード的な世界、電気的接続、ノイズ耐性、電源品質、信号品質、仕様になるのではないでしょうか？不幸にして動かないときでも、論理検証が済みならば自信を持って、ハード部分に着目して進めればよいことになります。
参考リンク
http://www.cqpub.co.jp/toragi/TRBN/contents/2006/tr0606/0606digi1.pdf
http://www.asic-world.com/verilog/art_testbench_writing1.html#Introduction
＜シミュレーションの高速化＞
部分的にHW化してシミュレータと接続して検証をSpeedUpできないか？という相談を受けることがあります。仮にそれができたとしても、アムダールの法則により、10倍の高速化を達成するには、90%以上のHW化が出来てないといけないことになります。実際には、インターフェース上のロスがありますから、それ以上にHWしないと高速化できません。数倍程度なら速いシミュレータを使った方がコスト的には良いでしょう。10倍以上の高速化を狙うなら、テストベクタのHW化、あるいは、テストベンチそのもののHW化といっ視点が必要になると思います。