因為Verilog是一種硬件描述語言，所以在寫Verilog語言時，首先要有所要寫的module在硬件上如何實現的概念，而不是去想編譯器如何去解釋這個module. 比如在決定是否使用reg定義時，要問問自己物理上是不是真正存在這個register, 如果是，它的clock是什么? D端是什么？Q端是什么？有沒有清零和置位？同步還是異步？再比如上面討論的三態輸出問題，首先想到的應該是在register的輸出后面加一個三態門，而不是如何才能讓編譯器知道要“賦值”給一個信號為三態。同樣，Verilog中沒有“編譯”的概念，而只有綜合的概念。

寫硬件描述語言的目的是為了綜合，所以說要想寫的好就要對綜合器有很深的了解，這樣寫出來的代碼才有效率。

有些東西完全是沒有意義的，像有些書上的很多程序，完全是不可綜合的比如產生一個10ms方波什么的程序，用什么#10 ~clk,這樣的語句硬件不可能做的那里面很多程序是用來verification的,不是綜合的。張老師那本書用來當初級教材還是不錯的,但是想通過它來掌握verilog是不夠的。曾經接觸過motorola蘇州設計中心的一位資深工程師,他忠告了一句:就是用verilog描述電路的時候,一定要清楚它實現的電路,很多人只顧學習verilog語言,而不熟悉它實現的電路,這是設計不出好的電路來的

一般寫verilog code時，對整個硬件的結構應該是很清楚了，最好有詳細的電路圖畫出，時序問題等都應該考慮清楚了。可以看著圖直接寫code。

要知道,最初Verilog是為了實現仿真而發明的.不可綜合的Verilog語句也是很重要的.因為在實際設計電路時,除了要實現一個可綜合的module外,你還要知道它的外圍電路是怎樣的,以及我的這個電路與這些外圍電路能否協調工作.這些外圍電路就可以用不可綜合的語句來實現而不必管它是如何實現的.因為它們可能已經實際存在了,我僅是用它來模擬的.所以,在寫verilog的時候應該要先明確我是用它來仿真的還是綜合的.要是用來綜合的話,就必須要嚴格地使用可綜合的語句,而且不同的寫法可能產生的電路會有很大差別,這時就要懂一些verilog綜合方法的知識.就像前面說的,腦子里要有一個硬件的概念.特別是當綜合報錯時,就要想一想我這種寫法能不能用硬件來實現,verilog畢竟還不是C,很多寫法是不可實現的.要是這個module僅是用來仿真的,就要靈活得多了,這時你大可不必太在意硬件實現.只要滿足它的語法,實現你要的功能就行了.

有網友說關于#10 clk=~clk的問題，雖然這種語句是不可綜合的，但是在做simulation和verification是常常用它在estbench中來產生一個clock信號。再比如常常用到的大容量memory, 一般是不會在片上實現的，這個時候也需要一個unsynthesizable module. mengxy所言切中肯罄。

我們設計的module的目的是為了可以綜合出功能正確，符合標準的電路來。我想這是個反復的過程，就像我們在寫design flow中總要注明前仿真，綜合后的仿真，以及后仿真等。仿真是用來驗證我們的設計的非常重要的手段。而verilog里那些看是無聊的語句這個時候就會發揮很大的作用。我想，用過verilog_xl的兄弟應該深有體會。verilog_xl里的操作，可以用verilog里的系統命令來完成。通過最近的應聘我也深有體會，很多公司看中你在寫code時，是否考慮到timing,architecture,DFT等，這也說明verilog中的任何語句都是非常重要的。

要寫代碼前必須對具體的硬件有一個比較清晰的概念但是想一次完成可綜合代碼就太夸張了,verilog的自頂向下設計方法就是從行為建模開始的,功能驗證了以后再轉向可綜合模型.太在意與可綜合令初期設計變得太累

很同意這種看法，在做邏輯結構設計時，綜合的因素是要考慮的，但是有很多東西不能考慮的過于細致，就是在設計的時候不能過于緊卡時延，面積等因素，因為這樣以來綜合后優化的余量就會很小，反而不利與設計的優化，如果在時延和面積要求不是很緊張的情況下，其實代碼寫的行為級，利用綜合工具進行優化也是一種方法。偶就聽說有一家很有名的公司，非常相信綜合工具的優化能力，從來不作綜合后仿真的，hehe.當然，如果面積和時延的要求很高，最好還是把代碼寫的底層一點，調用庫單元時，也要充分考慮其面積和時延的因素。