HDLの規約の解釈の仕方により、シミュレータだったり、論理合成ツールの実装に違いが見られるところを幾つか発見したので、まとめて見ます。原因はVerilogの言語仕様に於いて曖昧なところがあるからなんですが、それを回避してどのツールでも正しくデザインを認識してもらうことを目的とします。検証済みでわかっていることを書いていますが、間違っていることがあれば指摘してください。noneと書くと、それ以降のすべてのモジュールにおいて、暗黙のwireを禁止し、エラーを出すようになります。それにより、あまやって信号名を間違えて、未定義のwireと認識され、意図しない回路が生成されることを防止することができます。以下のサンプルは、D-FFのモジュールです。なんの意味もないwireを経由したり、あと、これは今回の`default_nettypeの挙動を見るためにあえて誤った記述(oud_dataが暗黙のwireにより1bitのwireと解釈されるため)をしています。指定して、暗黙のwireを許可(つまりデフォルトの状態)するようにしたほうが良いです。始めに書いたように、上のモジュールでは、1つ(または複数)のエラーが出ます。noneにより、wire宣言されていないout_dataがあるからです。このように、意図しないミスを防ぐことができ便利です。wireと解釈されてしまいます。noneがない場合、はこのように期待するデザインでないのにエラーを防げません。noneでどこまで適用させるかというのがシミュレータによって、実装が異なるようです。input/outputにおいても、wire宣言の省略をエラーと捉えるか、捉えないかがシミュレータ・合成ツール依存になっています。ターミナルリストのみ適用されるもので、port宣言においては適用されないとのこと認識しているとのこと。エラー無しということで、上に上げたVerilogファイルでは、ModelSimにおいて、エラーが出ることになります。directionは無視しているようです。directionでもwireの宣言を省略しないほうが良いかと思います。wirewire/reg宣言の位置についてどうやら、wire/reg宣言をする前(Verilogファイル上)にその信号にassignしたり、その信号を用いようとした時、ツールによってerrorとなったりならなかったりするようです。エラーなしVeritakとQuartusII意外は全てエラーになるようです。@*を用いて表現する場合、Xilinxのツールでおかしな解釈があったのでメモ。1'b0;endend上記のようなコードは、Xilinxのツールではエラー(エラーコード20391)となる。@*では2次元配列を認識しないらしい。解決策としては以下のように普通にセンシティビティリストに全て書くしか無いとのこと。デバイスではこの問題は起きないとのこと。基本的にメモリ宣言したものを組み合わせ回路に入れるのは気持ち悪いのであまり推奨されない書き方だとは思います。