HDL編碼風格與編碼指南

作者：徐欣 博士 孫廣富 博士
原文出自e元素科技網站

Rev. 0.1
June 30，2002

第一部分：說明 

1.準則的重要程度分三個層次：

好的經驗 -- 表明這條規則是一般情況下比較好的經驗，在大多數的情況下

要遵循,在特殊情況下可以突破這一規則。

推薦 -- 推薦這一規則，在遵循這一規則的條件下，一般不會出現問題；

強烈推薦 -- 表示嚴格規定，除非出現特別特殊的情況，否則要嚴格遵守。　

2．斜體部分一般表明不按照規則執行，會出現的問題和現象，或一些相關註釋。　

3．版本及修訂工作　

姓名 徐欣，孫廣富
修訂 規範的最初發布

日期 2002-6-30
聯繫方式 Dr.xuxin@163.net

第二部分：HDL編碼風格

1. 文件頭和修訂列表

作為好的源代碼，其中必須包含所有需要的信息。因此源代碼中要

包含文件頭和修訂列表（以獲得修改情況）。

1．1 文件頭包含以下內容：

·模塊名

·文件名

·需要的庫

·模塊描述

·使用的模擬器--其運行平台和版本

·使用的綜合工具，其運行平台和版本

·作者名字和e-mail

1．2 修訂列表包含以下內容：

·修訂版本號

·改動的數據

·修訂者名字和e-mail

·改動的詳細描述

下面是一個例子：

Example Header

-------------------------------------------------------------------------------------------

-- Module : MAC (Multiply Accumulate Unit)

-- File : mac.vhd

-- Library : ieee,.......

-- Description : It is a general Purpose Multiply Accumulate Unit capable of

-- Simulator : Modelsim 5.2 / Windows 95

-- Synthesizer : Synplify / Windows95

-- Author / Designer : Harish Y S (harish@opencores.org)

-------------------------------------------------------------------------------------------

Example Revision List

-------------------------------------------------------------------------------------------

-- Revision Number : 1

-- Date of Change : 20th March 2000

-- Modifier : Harish Y S (harish@opencores.org)

-- Description : Initial Design

-------------------------------------------------------------------------------------------

-- Revision Number : 2

-- Date of Change : dd mm yyyy

-- Modifier : XYZ (email)

-- Description : Modified the ????.to improve ????..

-------------------------------------------------------------------------------------------

文件頭的標準模式：

-------------------------------------------------------------------------------

-- Title :

-- Project :

-------------------------------------------------------------------------------

-- File :

-- Author : name <email>

-- Organization:

-- Created :

-- Last update :

-- Platform :

-- Simulators :

-- Synthesizers:

-- Targets :

-- Dependency :

-------------------------------------------------------------------------------

-- Description:

-------------------------------------------------------------------------------

-- Copyright (c) notice

-------------------------------------------------------------------------------

-- Revisions :

-- Revision Number :

-- Version :

-- Date :

-- Modifier : name <email>

-- Desccription :

------------------------------------------------------------------------------

2．聯機註釋

每一個重要的操作和定義后都要加上註釋，描述操作和聲明的使用。

 

3．命名規則

3．1 實體和結構

規則：

·實體名要確切描述其功能；

·實體名只能用小寫字母，不超過10個字元；

推薦：每個實體最好有一個3-4個字母的縮略名，可以將其應用在其內部的

構造模塊（component）和信號名中。

3．2 埠

規則：

·埠名應和信號相對應，以大寫字母開頭；

·若埠是標準設備，可包含標準名，不超過15個字元；

·埠聲明后要有詳細註釋。

3．3 結構體

結構體定義系統行為，可從不同方面對其進行描述，結構體和實體是

一致的，其名字要表明系統描述的方法。

規則：

·構造體名可用“behavioural”表示行為描述，“structural”表示

結構描述，“RTL”表示寄存器描述等；

·由綜合出來的結構體要有“_syn”後綴，並且在開始和結束出

要註明採用的技術；

·在“ARCHITECTURE”語句前要有一行註釋，說明其功能，

並說明是否可綜合，或僅可模擬。

推薦：當一個設計中包含多個文件時，通過加“_arch”後綴來加以區分。

3．4 元件 component

元件 component在VHDL設計的層次結構中使用。

規則：其名稱以包或實體的縮略名作開頭；

可取有實際意義的單詞，大小寫可混用，最好不要超過8個字元。

3．5 配置

配置是用來說明邏輯模塊和其構造體間的關係。

規則：配置名中要包含頂層設計名；以大寫字母開頭，不超過15個字元。

推薦：加“_cfg”後綴區分多個文件。

3．6包、函數和過程

3．6．1 包

規則：

·包中要包含系統所需定義的所有常量，數據類型，模塊，過程和函數；

·包名以大寫字母開頭，不超過15個字元。

推薦：加“_pkg”後綴區分多個文件，為包定義一個3-4個字元的縮略名，

加在其中的常量，過程和函數名中，用以區分不同包中的內容。

3．6．2 函數和過程

規則：

·以大寫字母開頭，不超過10個字母；

·要體現其功能，用前綴“l_”表示局部變數；

·局部信號應有其特徵域。

推薦：加入包的縮略名於其中。

3．7 常量和類屬說明

規則：用大寫字母，要明確描述常量的用法。

推薦：加入包的縮略名於其中。

3．8 枚舉（enumeration），數據類型，記錄和數組

規則：用大寫字母，新數據類型要加後綴“_typ”。

3．9 信號和變數

3．9．1 信號

規則：

·第一個符號必須是字母，信號名要描述其功能，不超過15個字元；

·頭三個字母要顯示說明驅動模塊的類型，要把其驅動實體，模塊或進程縮略名加在前面：如控制單元--“ctl”，算術邏輯運算單元--“alu”，乘法器--“mac”，數據地址發生器--“dag”；

·如果信號只是在僅有時鐘的進程中獲得其值的，則加“_q”，若是匯流排則加“_reg” 信號定義語句后要有一行註釋描述其功能；

·信號名要表明信號的極性：高電平有效/正邏輯（P），低電平有效/負邏輯（N）

·全局信號“G”，局部信號“L”；若是三態信號，加Z；

·後續字元要說明信號的內容。

例如：“alu{GBaugend”--其驅動的模塊為算術邏輯運算單元，高電平有效全局信號，是算術邏輯運算單元的其中一個操作數的匯流排信號。“macNGWoverflow”--其驅動的模塊是乘法器，低電平有效全局單線信號，其功能是在乘法器溢出時修改狀態寄存器的溢出標誌位。

3．9．2 變數

規則：

·變數名要簡單並能描述其功能；

·變數名可包含各種格式的字母、數字和下劃線；

·變數名要確切的表示其行為。

3．10進程和塊

進程、塊和配置可取有實際意義的單詞，大小寫可混用，最好不超過8個字元。

3．10．1 進程

規則：

·所有進程必須有進程名，用以描述其功能；

·註釋要包含以下內容：組合、時序進程，組合進程要定義所有敏感信號，時序進程要定義時鐘和其邊沿（上升沿或下降沿）， 時序進程還要定義複位信號--如果有的話，其有效與否與時鐘有關。

3．10．2 塊

3．11 測試工作台 test bench

由於測試工作台在設計流程種的重要地位，因此，對其有一些特殊的要求。

規則：

·其名稱要與實體名一致，且加後綴“_TB”；

·結構體、進程、變數和信號同樣遵循上述規則；

·內存組織和模擬生成由過程和函數來實現；

·出錯報告要提供下述信息：實體或模塊名，信號或變數名，過程或函數名，當前時間點，錯誤號或錯誤名，可能的出錯原因，出錯位置（RTL, structural 或 behavioral代碼）；

3．12 文件和目錄結構

現在在目前的集成開發環境中自動管理

3．13 其它

·儘可能使用類書參數說明（Generic）。

·盡量多定義常數，這樣可以增加代碼的可讀性。

·寫代碼之前，要先畫出系統框圖，對自己要做的模塊有一個清楚的認識，這樣可以減少你寫代碼時間，提高效率。

 第三部分：HDL編碼指導

1．複位

1．1 作用

複位使初始狀態可預測，防止出現禁用狀態。

1．2 推薦：

·FPGA和CPLD的複位信號採用非同步低電平有效信號，連接到其全局複位輸入端，使用專用路徑通道。FPGA和CPLD有固定時間延遲線，連接到所有資源上。

·對於目標器件為ASIC的core，非同步時鐘只能局部使用，在頂層設計上要與時鐘同步，這可以防止過長的延時。

·複位時，所有雙向埠要處於輸入狀態。

1．3 強烈推薦：

複位信號必須連接到FPGA和CPLD的全局複位管腳。這是由於這些管腳提供較低的抖動。

 2．時鐘

2．1 好的習慣：

在core中盡可使用小的時鐘域。

2．2 推薦：

·信號穿過時鐘的兩半個周期時，要在前後分別取樣；防止出現半穩定狀態。

·不要用時鐘或複位信號作數據或使能信號，也不能用數據信號作為時鐘或複位信號；HDL綜合時會出現時序驗證問題。

·不要使用門時鐘（don't use gated clock）。

2．3 強烈推薦：

時鐘信號必須連接到全局時鐘管腳上。

 3．匯流排

推薦：

·匯流排要從0位開始；

有些工具不支持不從0位開始的匯流排。

·從高位到低位；

這樣可以避免在不同設計層上產生誤解。

 

4．通用規則

4．1 強烈推薦：

不要使用內部三態信號，否則增加功耗。這樣使後端的調整更困難。

4．2 同步設計和時序優化

4．2．1強烈推薦：

·只使用同步設計；這樣可以避免在綜合、時序驗證和模擬中的出現的一些問題。

·不要使用延時單元；

·所有塊的外部IO必須註冊；這樣可以避免較長的路徑延時

4．2．2 推薦：

·避免使用鎖存器；這樣會產生綜合和時序驗證問題。

·避免使用負延觸發的雙穩態多諧振蕩器（flip flop）。同樣會產生綜合和時序驗證問題。

4．2．3 好的習慣：

塊內部IO要例化。這是設計問題，在大部分情況下推薦使用

 5．verilog編碼指導原則

5．1 一般規則

5．1．1 強烈推薦：

在時鐘驅動的同步進程中不要使用block結構，block結構應用於非同步進程種。Synopsys 希望使用這種格式，有確定的模擬響應。

5．1．2 推薦：

·盡量使用無路徑的“include”命令行；HDL應當與環境無關。

·避免使用“ifdef”命令，盡量用一個全局定義文件做所有的定義；否則容易產生版本和編輯問題

5．1．3 好的習慣：

·盡量在一個文件中只用一個模塊，文件名要和模塊名相同；

·盡量在例化中使用名稱符號，不要用位置符號；有利於調試和增加代碼的易讀性。

·在不同的層級上使用統一的信號名；容易跟蹤信號，網表調試也容易。

·比較匯流排時要有相同的寬度。否則其它位的值不可預測。

5．2 模擬和調試

5．2．1 強烈推薦：

全部的系統模擬任務都應在Synopsys命令“synopsys translate on/off”之中。

5．2．2 好的習慣：

·在全局定義文件中，在開始的時間標度命令中寫“timescale 1n/10p”；不同的“timescale”會導致模擬問題--競爭和過長的路徑

·盡量在“display”命令中使用“%m”（顯示實例名）。

 

6．VHDL 代碼指導原則

6．1 一般規則

6．1．1 強烈推薦：

·外部埠用std_logic類型；

·不要賦未知值“x”或檢查驗證無效的“-”；這些值在模擬和綜合時會產生不可預測的行為。

·不要使用信號和變數的默認值（或初始值），用複位脈衝初始化信號和變數。會在模擬和綜合時出現不匹配。

6．1．2 好的習慣：

·在整個VHDL工程中不要混用編碼準則（i.e. VHDL 87 and VHDL 93）；

·盡量在一個VHDL文件中做一個設計，文件名要和結構名一致；

·盡量在模塊例化中使用名稱符號，不要用位置符號；有利於調試和增加代碼的易讀性。

例如：

wb_if: wb

PORT MAP (

    CLK => CLK_i,

    RST_I => RST_I_i,

    ACK_O => ACK_O_i,

    ADR_I => ADR_I_i,

    CYC_I => CYC_I_i,

    DAT_I => DAT_I_i,

    DAT_O => DAT_O_i,

    RTY_O => RTY_O_i,

    STB_I => STB_I_i,

    WE_I => WE_I_i);

6．1．3 好的習慣：

·在不同的層級上使用統一的信號名；容易跟蹤信號，網表調試也容易。

·盡量用配置（configuration）映射實體、結構體和模塊；改變不同的結構體只要簡單改動一個文件就可以了，這在模擬上很有用，能從高層上改變低層結構體。

·盡量在分開的庫中編譯每個塊；

·使用常量和類屬說明定義緩衝大小，匯流排寬度和其它單元參數。這可增強可讀性和代碼復用性。

6．1．4 推薦：

·在一個最小化的包中定義模塊和常量。

6．1．5 強烈推薦：

·不要在代碼中使用buffer類型的埠讀取輸出數據；要使用out類型，再增加另外變數或信號，以獲取輸出值。這是因為buffer類型的埠不能連接到其他類型的埠上，因此buffer類型就會在整個設計的埠中傳播下去。

例如：

PROCESS (CLK, RST_n)

    variable out_var : std_logic;

BEGIN -- PROCESS

    IF RST_n = '0' THEN

        Outsignal <= '0';

        out_var <'0';

        outsign2 <= '0';

    ELSIF CLK'event AND CLK = '1' THEN

        Outsign2 <= out_var; -- the same as Outsignal

        out_var := input1 and input2;

        Outsignal <= input1 and input2;

    END IF;

END PROCESS;

 

6．2 可綜合編碼

6．2．1 好的習慣：

盡量使用FSM，一個在時序邏輯中，一個在組合邏輯中。這可增加可讀性和預測組合邏輯的大小

6．2．2 推薦：

盡量在一個單獨的時鐘進程中寫時鐘使能，而不要在兩個不同的進程中使用，一個是時鐘驅動的，一個是組合邏輯，如下例所示。這是因為有些綜合工具檢查CE操作，若存在，就將其映射到觸發器的CE端，否則，CE管腳不被使用，隱含使用外部邏輯。這是fpga設計的一般習慣。

PROCESS (CLK, RST_n)

BEGIN -- PROCESS

    IF RST_n = '0' THEN

        Outsignal <= '0';

    ELSIF CLK'event AND CLK = '1' THEN

        IF (CE = '1') THEN

            Outsignal <= '1';

        END IF;

    END IF;

END PROCESS;

 

6．2．3 強烈推薦：

·對變數要先讀後寫；

如果先寫後讀，就會產生長的組合邏輯和鎖存器（或寄存器）。這是因為變數值是立即獲取的。

PROCESS (CLK, RST_n)

    Variable out_var : std_logic;

BEGIN -- PROCESS

    IF RST_n = '0' THEN

        out_var <'0';

        outsign2 <= '0';

    ELSIF CLK'event AND CLK = '1' THEN

        Outsign2 <= out_var; -- read

        out_var := input1 and input2; -- write

    END IF;

END PROCESS;

·在組合邏輯進程中，其敏感向量標中要包含所有要讀取得信號；這是為了防止出現不必要的鎖存器。

·避免使用長的if-then-else語句，而使用case語句來代替；防止出現較大的優先編碼器，使得代碼比較容易讀懂。

6．3 以模擬和調試為目的的編碼

6．3．1 好的習慣：

盡量使用兩部分的test bench，一部分作為數據產生和檢驗，另一部分作為時序匯流排介面協議的產生和檢驗。

這是為了從匯流排握手中分離數據（結果檢驗），為了使操作簡單--改變匯流排握手協議而同時保持內部邏輯不變。