(原創)關于一點點Verilog的編碼風格問題

     在大家都在注重實際技能的同時,是否有人會注意其實代碼的美觀也是很重要的呢?呵呵...其實筆者最初學習編寫程式的時候,這點也被忽略了.當代碼的規模上了1000行之后,代碼的結構性和美觀就是一個十分重要的問題了.

    曾有編程大師總結說，一個優秀的程序員，能維護的代碼長度大約在1萬行數量級。代碼的整潔程度，很大程度上影響著代碼的維護難度。

     說的直白點,就是在別人看你寫的程式的時候,是否感到一目了然,這個是很重要的.既然說了這么多,我們就開始我們的這次主題:如何編寫規范的代碼!

 

    一,變量和信號命名的問題:

    1).系統級信號的命名-------
   系統級信號指複位信號，置位信號等等這一類的信號，時鐘信號等需要輸送到各個模塊的全局信號；系統信號以字符串Sys開頭。比如在命名一個系統的復位信號是,我可以使用 sysRST_N這樣一個變量名.

   2).低電平有效的信號後一律加下劃線和字母n(或者N)。如：iRST_N；

   3)輸入輸出端口的命名:

     如果端口是input型,則在變量名稱的前面加上一個小寫的字母"i",表示是輸入類型的端口.入:iCLK

     如果端口是output型,則在變量名稱的前面加上一個小寫的字母"o",表示是輸入類型的端口.入:oResult

     如果端口是inout型,則在變量名稱的前面加上一個小寫的字母"io"

   4)經過鎖存器鎖存後的信號，後加下劃線和字母r，與鎖存前的信號區別。如CpuRamRd信號，經鎖存後應命名為CpuRamRd_r

   5)模塊的命名:實際上這里有個很簡單的原則,那就是原則上模塊的名字不要超過3個字母,且模塊的名稱通常取自模塊英文名的開頭字母.

   若模塊的英文名只有一個單詞，可取該單詞的前3個字母。例如：
     Arithmatic Logical Unit模塊，命名為ALU。
     Data Memory Interface模塊，命名為DMI。
     Decoder模塊，命名為DEC。

   6)分節書寫，各節之間加1到多行空格。如每個always,initial語句都是一節。每節基本上完成一個特定的功能，即用於描述某幾個信號的產生。在每節之前有幾行注釋對該節代碼加以描述，至少列出本節中描述的信號的含義。行首不要使用空格來對齊，而是用Tab鍵，Tab鍵的寬度設為4個字符寬度。行尾不要有多餘的空格。

     7)空格的使用：
   不同變量，以及變量與符號、變量與括號之間都應當保留一個空格。
     Verilog關鍵字與其它任何字符串之間都應當保留一個空格。如：
     Always @ (……)
   使用大括號和小括號時，前括號的後邊和後括號的前邊應當留有一個空格。
   邏輯運算符、算術運算符、比較運算符等運算符的兩側各留一個空格，與變量分隔開來；單操作數運算符例 外，直接位於操作數前，不使用空格

    8)同一個層次的所有語句左端對齊；Initial、always等語句塊的begin關鍵詞跟在本行的末尾，相應的end關鍵詞與Initial、always對齊；這樣做的好處是避免因begin獨占一行而造成行數太多

    比如:

    always @ ( posedge iCLK or negedge iRST_N ) begin

         ........

         ........

         ........

    end

    9)不同層次之間的語句使用Tab鍵進行縮進，每加深一層縮進一個Tab.

    對于這點,我要做特別的說明,實際上過多的使用TAB,對程式本身的結構也是一種破壞,我曾在東芝實習的一段時間,那里的技術部門就特別規定:TAB的是喲娜更不能超過5次.為什么要這樣規定呢??實現想來其實很簡單,當一個城市的層次超過5層以上以后,如果我們在每個層次都使用一次TAB,那么到最里層的代碼就過超過我們屏幕的寬度,這樣對于代碼的維護是非常不利的.也許有人會說"我的程式也超過了5層甚至更高,但是卻沒有這樣的現象產生".好,對于這個問題,我是這樣解答的:在實際的商業編寫代碼的過程中,特別是在非常重視后期產品的升級和維護這樣的公司里,在一個程式的變量命名中,變量名稱是很長的,當你使用冗長的變量名時,我想4層左右的結構就已經超過屏幕的寬度了.所以,TAB的使用要更具代碼而定!

   10)

在endmodule，endtask，endcase等標記一個代碼塊結束的關鍵詞後面要加上一行注釋說明這個代碼塊的名稱；
在task名稱前加tsk以示標記。在function的名稱前加func以示標記。例如：

         task    tskResetSystem；
             .......

             .......
          endtask           //of tskResetSystem

      小結:

    以上列出的代碼編寫規範無法覆蓋代碼編寫的方方面面，還有很多細節問題，需要在實際編寫過程中加以考慮。並且有些規定也不是絕對的，需要靈活處理。並不是律條，但是在一個項目組內部、一個項目的進程中，應該有一套類似的代碼編寫規範來作為約束。
    在實際的選擇中,要靈活的使用這些規范,寫出美觀的程式是很有必要的.