†ビヘイビャーレベルのテストベンチ記述の際に自分で使っている典型的なイディオムを紹介してみます。確認するというような処理。テストベンチではステートマシンを書く必要は無い。バグが入りやすくなってしまってテストベンチを書いている意味がない。テストベンチにする、とかものすごく意味がないのでダメダメです)で、どうするかというとなるべくソフト開発っぽく逐次処理で書く。$stop;endこれなら、上記の仕様通りのテストベンチになっているのが一目瞭然です。大変ですし、後からタイミングを変更するとか、かなり考えたくないです。上記では、モジュールに与える信号線への代入はすべて「ノンブロッキング代入」で行っています。評価するのはノンブロッキング代入が行われたさらに後)実行されることです。信号が1クロック分遅れる動作をします。同時に変化してしまいます。シミュレーションが行えていないことになります。endendmoduleこのコードは思った通り上記前者のコードと同様の動作します。おきるイベントの評価順が結果に影響してしまう形になっています。右辺の評価とどちらが先に起きるかという点ですね。ns***として、実機と同じ動作が保証されます。「テストされるモジュールに渡す信号線への代入はノンブロッキング代入とすべし」は無条件に覚えておいて良い格言なのではないかと思います。ブロッキング代入を使うことになります。ノンブロッキング代入を使う、というのが正しい使い方になりますね。上記のノンブロッキング代入の話題と関連するのでここに書いておきます。違いは以下の例を見ると一目瞭然です。直後に値を出力するという違いに起因しています。実行の順で処理されます。後で値を表示していることの理由がこれで理解できたと思います。使うべきかをよく考える必要がありますね。実機に近く、間違いの生じにくい使い方ではないかと思います。取るビットが含まれている場合に動作が異なります。†ソフト開発っぽく逐次処理で書いたコードの10行目。信号にグリッチが乗ると誤検出してしまいます。clk);とした方が良い場合が多いかもしれません。効果もそれほど無いだろうから、ほぼすべての場合に上の案で十分だと思う。異なる入力を与えて繰り返し呼び出せばいい。ソフトウェアと同様に考えると、とても簡単。乱数で入力データを与えることで、網羅的なテストを行うことが有効な場合もありますね。異なるので注意が必要です。返ってきて悩むことになります。仕様をちゃんと読まない私みたいな人が必ず1度ははまる落とし穴になっています。-2147138048となります。初期値とする乱数が得られることになるわけです。同じテストベンチを繰り返し実行すれば、常に同じ結果が得られます。信頼の置けるテストを刷るためにはこのこともとても重要ですね。被テストモジュールに繋いで使ったりしますよね。全ての場合に正しい結果が得られるかを検証したくなります。テストベンチ本体からそれらを呼び出す形です。行目がその呼び出しを行っている部分です。モジュール外部に対して内部の実装を隠蔽できます。そこは各自のコーディング規約で何とかするしかないですね。上記のようにするとそこそこオブジェクト指向っぽい書き方ができるわけです。継承を用いたコードの再利用ができないところがちょっと不満です。書くには次のようにしなければなりません。endfunctionendmoduleこういう実装方法を、オブジェクト指向プログラミングの世界では「委譲」と言います。呼び出しているから「委譲」ですね。呼び出すだけの無意味な実装コードがたくさん必要になってしまいます。書くことができるんじゃないでしょうか?という話でした。無いのが苦しく感じられました。クラス間の依存関係を減少させることができます。容易に変更や再利用ができないコードになってしまいがちです。それ用のプロトコルを決めて、それを実装しなければならなくなります。今のところあまり良い案がない状況です。本来なら呼び出す際に引数は必要ないのです。inputというコンパイルエラーが出てしまいます。具体的な入力を与えなくても問題ないようでした。このあたり、どういう設計思想なのか謎な感じです。立ち上がりませんでした。書き忘れている場所があったとのこと。して報告すべきだと思うのだけれど???ネットで調べてみると、http://forums.xilinx.com/t5/Simulation-and-Verification/ISim-Simulator-Unable-to-elaborate-instantiated-module-lt-module/td-p/104451少なくとも1年半くらい前にも同様の問題で悩んだ人がいたみたいですね。デッドロックしますね。ありがとうございました。