挺久沒有更新，今天更新一篇小文章。最近正在整理一個SDRAM控制器的教程（VHDL），現在更新的小文章是想為后續的SDRAM教程以及其它比較大的教程做鋪墊。本文主要講關于VHDL編碼風格（Verilog也可以用同樣的思想），這篇文章的核心思想就是：設計中的所有狀態都應該被明確聲明在寄存器中。

這句話什么意思先不談，直接上兩段代碼，第一段如下：

library ieee;use ieee.std_logic_1164.all;use ieee.std_logic_unsigned.all;use work.ff.all; -- 一些常用的元件包，這里面是可以自己寫的

-- 這篇文章主要就調用了基本的D觸發器，里面還有什么可以先忽略

entity Bad_Counter is generic（ n： integer ：= 4 ）; port（ clk， rst： in std_logic;

output： buffer std_logic_vector（n-1 downto 0） ）;end Bad_Counter;

architecture impl of Bad_Counter issignal nxt： std_logic_vector（n-1 downto 0）;begin process（clk） begin

if rising_edge（clk） then

if rst then

output 《= （others =》 ‘0’）;

else

output 《= output + 1;

end if;

end if; end process;end impl;

一個4位計數器，能實現設計的功能，但其中output 《= output + 1存在一點問題，這種寫法非常C語言化，這也是很多人習慣的寫法。為什么說這種寫法不好，因為它混淆了當前狀態和下一狀態。先不多解釋，看下一段代碼如下：

library ieee;use ieee.std_logic_1164.all;use ieee.std_logic_unsigned.all;use work.ff.all; -- 一些常用的元件包，這里面是可以自己寫的

-- 這篇文章主要就調用了基本的D觸發器，里面還有什么可以先忽略

entity Good_Counter is generic（ n： integer ：= 4 ）; port（ clk， rst： in std_logic;

output： buffer std_logic_vector（n-1 downto 0） ）;end Good_Counter;

architecture impl of Good_Counter is signal nxt： std_logic_vector（n-1 downto 0）;begin nxt 《= （others=》‘0’） when rst else output+1;

count： vDFF generic map（n） port map（clk， nxt， output）;end impl;

這段代碼同樣的是4位計數器，為什么用這兩段代碼做比較，非常典型，第一段代碼的思想就是C語言的思想來寫的，很多人可能沒有注意自己在寫“數字電路”，也沒有特別關注寫出來的代碼綜合出來是什么樣子。第二段代碼明確表明nxt是下一狀態，并且nxt是通過當前狀態output得到的，這很重要，與此同時還調用了一個D觸發器元件，這個D觸發器為什么用，之前在異步FIFO（二）中有談到：在實現所有的狀態變量都應該被明確的聲明位D觸發器，不要讓編譯器去推斷應該用什么觸發器。

講到這里，可能還是不懂這兩份代碼有什么具體的差別，我做了一個實驗，把兩份代碼都綜合了一遍，使用了兩個不同的版本，Quartus20.3和Quartus13.1（不同版本的軟件，無論是效率還是開發便捷程度還是有一定差別的）

先看Quartus13.1綜合出的兩份原理圖

這幅原理圖是第一份代碼綜合出來了，大概看一下沒什么問題，代碼也是這樣寫的。

再看第二份代碼綜合出來的原理圖

區別來了，很明顯，第一份代碼因為用output <= output + 1的原因，左右兩端使用了相同的信號，混淆當前狀態和下一狀態，下一狀態被隱藏起來。但第二份代碼綜合出來的很明顯，nxt是下一狀態，并且nxt是通過當前狀態output得到的。當然還要個比較好的地方，第二份代碼直接調用D觸發器元件（在package里面寫了），告訴編譯器狀態變量要聲明為D觸發器，而不是讓編譯器自己判斷（盡管它可以）。

再看Quartus20.3綜合出來的原理圖

這個原理圖是第一份代碼Bad_Counter 綜合出來的，很顯然現在的EDA真行，可以把不那么優秀的代碼綜合出優秀代碼才能綜合出的原理圖了。當然這是很簡單代碼的情況下。

這個原理圖是第二份代碼Good_Counter綜合出來的，除了下一狀態的命名和位數區間不一樣外，其它的兩個代碼綜合出來的沒有區別！

小結：從上面的四幅原理圖看，盡管隨著EDA的發展讓不那么優秀的代碼綜合出和優秀代碼一樣的原理圖，但良好編碼風格的代碼仍然非常必要，即使是13.1和20.3巨大版本差異的情況下，良好編碼風格的代碼綜合出來的原理圖也是一樣的。但在代碼風格不好的情況下，13.1和20.3卻有比較大的差距。人作為設計的主體，不能完全依靠EDA的優化，編譯器也不是萬能的，有些其它地方未必會優化的那么好，在大型復雜項目中不太好的編碼風格可能編譯器也未必能夠給出比較好的優化，好的編碼風格可以讓我們更好的理解一些底層的設計，也能知道代碼會如何綜合。更重要的是需要知道自己數字設計師！用數字的思想去設計FPGA。這些只是自己的意見，大家可以做一個參考，有不對的地方也歡迎批評指正。

審核編輯 ：李倩