b.信号命名要规范化。
1) 信号名一律小写,参数用大写。
2) 对于低电平有效的信号结尾要用_n标记,如rst_n。
3) 端口信号排列要统一,一个信号只占一行,最好按输入输出及从哪个模块来到哪
个模块去的关系排列,这样在后期仿真验证找错时后 方便很多。如:
module a(
//input
clk,
rst_n, //globle signal
wren,
rden,
avalon_din, //related to avalon bus
sdi, //related to serial port input
//output
data_ready,
avalon_dout, //related to avalon bus
...
);
4) 一个模块尽量只用一个时钟,这里的一个模块是指一个module或者是一个en
tity。在多时钟域的设计中涉及到跨时钟域的设计中最好有专门一个模块做时钟域的隔
离。这样做可以让综合器综合出更优的结果。
5) 尽量在底层模块上做逻辑,在高层尽量做例化,顶层模块只能做例化,禁止
出现任何胶连逻辑(glue logic),哪怕仅仅是对某个信号取反。理由同上。
6) 在FPGA的设计上禁止用纯组合逻辑产生latch,带D触发器的latch的是允许的
,比如配置寄存器就是这种类型。
7) 一般来说,进入FPGA的信号必须先同步,以提高系统工作频率(板级)。
所有模块的输出都要寄存器化,以提高工作频率,这对设计做到时序收敛也
是极有好处的。
9) 除非是低功耗设计,不然不要用门控时钟--这会增加设计的不稳定性,在要
用到门控时钟的地方,也要将门控信号用时钟的下降沿 打一拍再输出与时钟相与。
clk_gate_en -------- ----
-----------------|D Q |------------------| \ gate_clk
_out
| | ---------| )--------
-
------o|> | | | /
clk | -------- | ----
------------------------------------
10)禁止用计数器分频后的信号做其它模块的时钟,而要用改成时钟使能的方式
,否则这种时钟满天飞的方式对设计的可靠性极为不利,也大大增加了静态时序分析的
复杂性。如FPGA的输入时钟是25M的,现在系统内部要通过RS232与PC通信,要以rs232_
1xclk的速率发送数据。
不要这样做:
always (posedge rs232_1xclk or negedge rst_n)
begin
...
end
而要这样做:
always (posedge clk_25m or negedge rst_n)
begin
...
else if ( rs232_1xclk == 1'b1 )
...
end
11)状态机要写成3段式的(这是最标准的写法),即
...
always @(posedge clk or negedge rst_n)
...
current_state <= next_state;
...
always @ (current_state ...)
...
case(current_state)
...
s1:
if ...
next_state = s2;
...
...
always @(posedge clk or negedge rst_n)
...
else
a <= 1'b0;
c <= 1'b0;
c <= 1'b0; //赋默认值
case(current_state)
s1:
a <= 1'b0; //由于上面赋了默认值,这里就不用再对b
、c赋值了(b、c在该状态为0,不会产生锁存器,下同)
s2:
b <= 1'b1;
s3:
c <= 1'b1;
default:
...
...
3.ALTERA参考设计准则
1) Ensure Clock, Preset, and Clear configurations are free of glitch
es.
2) Never use Clocks consisting of more than one level of combinatori
al logic.
3) Carefully calculate setup times and hold times for multi-Clock sy
stems.
4) Synchronize signals between flipflops in multi-Clock systems when
the setup and hold time requirements cannot be met.
5) Ensure that Preset and Clear signals do not contain race conditio
ns.
6) Ensure that no other internal race conditions exist.
7) Register all glitch-sensitive outputs.
Synchronize all asynchronous inputs.
9) Never rely on delay chains for pin-to-pin or internal delays.
10)Do not rely on Power-On Reset. Use a master Reset pin to clear al
l flipflops.
11)Remove any stuck states from state machines or synchronous logic.