HDL編碼風格與編碼指南

admin @ 2014-03-26 , reply:0

作者:徐欣 博士 孫廣富 博士
原文出自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,一部分作為數據產生和檢驗,另一部分作為時序匯流排介面協議的產生和檢驗。

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




[admin via 研發互助社區 ] HDL編碼風格與編碼指南已經有1776次圍觀

http://cocdig.com/docs/show-post-43463.html