カウンタRTLシミュレーション4.2.1のled.vの記述には、テストベンチがありません。Veritakシミュレーションを行うには、テストベンチが必要です。テストベンチを作成しましょう。クロックとリセットがFPGAに供給されれば動くはずです。以下はled_test.vソースです。最初の50nsは、リセットさせます。その後、リセットを解除します。endendmoduleプロジェクトを作成します。プロジェクトの名前は、RTLとVeritakということがわかるようにした方がよろしいでしょう。ファイルを指定します。上で作成したファイルを指定します。ProjectでSaveしておきます。シミュレーション波形リセットが解除になった後、インクリメント動作しています。xilinxcorelibに置き換えてたものと同様です。下の「遅延シミュレーション」の項をご参照ください。INCLUDE_DIR」しておきます。これがないと、プロジェクトのルートフォルダしか探索しないため、mifファイルが読み込まれません。下の例(筆者がDWM設計コンテスト2005に応募したプロジェクトです。オープンコアに設計途中の試行錯誤が載っています。)では、rom4k.vはcoregenで生成したファイルです。このファイルを含むフォルダdwmをINCLUDEしておきます。Webpackで遅延シミュレーション用のVerilogファイルを生成させます。*_timesim.vというファイルが生成されます。遅延シミュレーションでは、それが出来ているフォルダ位置にプロジェクトファイルを構成する必要があります。Xilinxをインストールしたフォルダ\Xilinx\verilog\srcにあります。Xilinxをインストールしたフォルダ\Xilinx\verilog\srcにあります。Dirを使うと便利です。(veritak1.44)です。初期化のファイルらしいです。確かにこれがないとResetされなくてFFは、XXになってしまいます。入っている沢山のファイルは、ゲートシミュレーション用のプリミティブな記述が入っています。プロジェクトと同じドライブ上にないときは、COPYしてプロジェクトと同じドライブ下としてください。Projectします。遅延シミュレーション波形(Veritak1.12B以降)波形を見てみると、ちゃんとインクリメント動作をしていることがわかります。カウンタの初期リセットは、usb_rstoでしたはずなのにカウンタのインクリメント動作は、glbl.vのGSRがHになって初めて行われているようです。glbl.vの記述を見てみると100ns後にHにしていることがわかります。プリミティブライブラリの中身を筆者は全然見てませんが、恐らくこの信号に起因して内部リセットがかかっているのだと思われます。従って、led_test.vを変更し、150nsにリセット解除に変更することにします。ところで、下の上部波形を見ると1−>2、3−>4でハザードらしいものが見えます。REGの出力なのでハザードはないはずです。実際、ビット展開してみるとビット毎でみればハザードは発生していないことがわかります。IO遅延は、カーソル間(クロックを与えてから出力が落ち着くまで)でみると10.912nsあることがわかります。それでも内部の合成結果は、26ビットカウンタで153MHzになっていますからIOは遅くとも内部はそれなりに速いです。下部の波形は、シミュレーション時間100usの全波形をビット展開したものですが、まだ、16ビット目(カウンタ12ビット目)にかかったところです。人間の目でLEDを確認するために、USER[3:0]には、counter[25:22]を割り付けたのですが、まだまだ程遠いことがわかります。実際的に遅延シミュレーションで確認するには、我慢の限界を超えていると思いますし、その必要もないでしょう。(RTLシミュレーションならば可能性はありますが。