注：以R起頭的是對編寫Verilog代碼的IP設計者所做的強制性規定，以G起頭的條款是建議采用的規范。每個設計者遵守本規范可鍛煉命名規范性。

4 注釋(Comments)

注釋可用于描述 Verilog HDL代碼的功能，特別需要提醒設計者注意的是，只依靠讀代碼很難理解的設計意圖必須在代碼中添加注釋加以說明。

4.1 文件頭(File Headers)

每一個可綜合的Verilog RTL級電路模塊、虛擬器件和測試模塊文件必須具有下面格式的文件頭。設計規范規定：文件頭的格式必須與下面的格式一致，以便于將來可用軟件對模塊代碼進行分析處理。文件頭中大寫的關鍵詞可以用來檢索。下面的這個模板可以保證文件頭的一致性。下面所示的文件頭只是最小要求。在“REUSE ISSUE”段之后，還可以再添加其他的文件頭.另外，有關版權的文件頭也應該包括在文件頭中。

// +FHEADER-----------------------------------------------------------------

// Optional Copyright (c)

// Optional Company Confidential

// ----------------------------------------------------------------------

// FILE NAME :

// DEPARTMENT :

// AUTHOR:

// AUTHOR’S EMAIL :

// --------------------------------------------------------------------

// RELEASE HISTORY

// VERSION DATE AUTHORDESCRIPTION

// 1.0 YYYY-MM-DD name

// ---------------------------------------------------------------------

// KEYWORDS : General file searchinGkeywords, leave blank if none.

//-----------------------------------------------------------------------

// PURPOSE : Short description of functionality

// ----------------------------------------------------------------------

// PARAMETERS

// PARAM NAME  RANGE : DESCRIPTION : DEFAULT : UNITS

// e.g.DATA_WIDTH [32,16] : width of the data : 32 :

// ----------------------------------------------------------------------

// REUSE ISSUES

// Reset Strategy :

// Clock Domains :

// Critical TiminG:

// Test Features :

// Asynchronous I/F :

// Scan Methodology :

// Instantiations :

// Synthesizable (y/n) :

// OtheR:

// -FHEADER-------------------------------------------------------------

R 4.1 每個文件必須有文件頭(header)

每一個文件必須包括如上面代碼段所示的文件頭。其中，所有的區域都必須包括在內，甚至空的數據段。

原因：按照規范編寫的標準文件頭便于建立公司內部的設計信息查詢系統。

R 4.2 使用文件頭界定標記 [+FHEADER & -FHEADER]

標簽+FHEADER& -FHEADER一定要用來定義頭信息的界限。(the boundary of the 文件頭
information)

原因：這是識別文件頭的簡單方法，標明該頭是文件頭，便于用文本工具自動地查詢存檔的資料。

R 4.3 文件頭內必須包含文件名

文件頭中必須包含文件名

原因：這樣做提供了一種簡單的方法以便用文本處理工具自動地查詢相關的設計文件。

R 4.4 文件頭中必須包含聯系方式

文件頭中必須包含有關本代碼的多種信息，其中包括開發小組的名稱、作者名、版本歷史、作者電話、電子郵件和郵寄地址。

原因：必要時可以找到原作者詢問只從設計文檔無法理解的問題。

R 4.5 文件頭包含發布歷史

文件頭必須要包含進入虛擬器件(VC)庫的修改歷史，最近的修改列于最后。日期格式必須采用YYYY-MM-DD。這個信息對于集成器是有用的。本地的修改歷史不應該包含其中。

原因：要求去記錄設計的修改歷史。

R 4.6 文件頭包含一個關鍵字段

文件頭必須包含便于搜索的關鍵字段。該字段應該包含有關本模塊功能的簡要說明，或是能與本模塊配合運行的總線和系統的名稱。

原因：關鍵字可提供快速的搜索機制，便于自動文本處理工具在龐大的虛擬器件 (VC)庫中搜索合適的器件。如果沒有關鍵字，該條目應該空著。

例子：sdram, address decoder, coldfire, sbus, amba,usb2.0

R 4.7 文件頭必須包含一段描述模塊功能的說明

文件頭必須包含一段描述本模塊功能的說明，而不是如何操作或運行方式的說明。

原因：有助于對模塊功能的理解。

R 4.8 文件頭必須包含參數描述文件的名和路徑

文件頭必須包含描述本模塊代碼所使用的參數文件的名和路徑。缺省值必須都在參數文件中列出。有效值域也必須標出。

原因：有助于對Verilog HDL代碼的理解

R 4.9 復位策略必須在頭文件中說明

在頭文件中必須詳細說明復位策略。包括說明是同步復位還是異步復位，是內部復位還是外部上電復位，是硬復位還是軟復位，以及該模塊是否能用單個復位來調試。

原因：改善代碼的可讀性，突出重點和必需的綜合步驟。

R 4.10 對時鐘域(clock domain)的說明

在頭文件中必須詳細說明所有的時鐘和時鐘策略。

原因：說明內部生成的時鐘或是分頻的時鐘，便于對代碼和時鐘策略的理解。

R 4.11 對關鍵布線路徑的說明

包括外部時機關系的決定性的時機必須記錄。文件頭的位置可以包含含有決定性的時機的文件名(如creation guide)

原因：建立時機和輸出時機關系突出了必需的綜合和測試。

R 4.12 記錄測試的特點

任何具體的代碼中的用于提高測試速度的測試特色必須記錄。

原因：一旦可視化部件被集成，這點可用來改善對代碼的理解和測試。

例子：parallel clocking, BIST

R 4.13 需要詳細的異步接口

異步接口必須包括時間關系和相關頻率

原因：有助于對設計的理解，并且有助于決定是否需要額外的同步的stages用于一個不同目標的應用。

R 4.14 標明掃描方法的風格

有關于掃描風格的標注必不可缺

原因：有助于設計的集成

例子：Mux-D oRLSSD

R 4.15 文檔實例化

文件頭必須包括有關于文檔內每一個單元、模塊、函數調用、任務是如何實例化的部分。(參考R 4.30, R 7.4, G 10.23)

原因：標明必須用于重定義技術的區域，并且幫助理解設計層次。

例子：實例化 mux2s cell, decode task

原因：絕大部分由實例組成的模塊。

R4.16 標明可綜合能力

綜合結構的能力必須以指定的YES或NO標明

原因：直接標明模塊的使用路徑(如：是否該模塊可被用于仿真)

G 4.17 其他頭文檔(OtheRheadeRdocumentation)

建議文件頭包含額外的相關信息——這些信息用于集成器或可以使代碼更易理解。這一部分信息有助于設計者的判斷，并可保持附加信息點的位置連續性。